All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@codeaurora.org>
To: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: linux-kernel@vger.kernel.org,
	"Mike Turquette" <mturquette@linaro.org>,
	"Javier Martinez Canillas" <javier.martinez@collabora.co.uk>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Tony Lindgren" <tony@atomide.com>,
	"Russell King" <linux@arm.linux.org.uk>,
	"Ralf Baechle" <ralf@linux-mips.org>,
	"Boris Brezillon" <boris.brezillon@free-electrons.com>,
	"Emilio López" <emilio@elopez.com.ar>,
	"Maxime Ripard" <maxime.ripard@free-electrons.com>,
	"Tero Kristo" <t-kristo@ti.com>,
	"Manuel Lauss" <manuel.lauss@gmail.com>,
	"Alex Elder" <elder@linaro.org>,
	"Matt Porter" <mporter@linaro.org>,
	"Zhangfei Gao" <zhangfei.gao@linaro.org>,
	"Haojian Zhuang" <haojian.zhuang@linaro.org>,
	"Jaehoon Chung" <jh80.chung@samsung.com>,
	"Bintian Wang" <bintian.wang@huawei.com>,
	"Chao Xie" <chao.xie@marvell.com>,
	linux-doc@vger.kernel.org, linux-omap@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-mips@linux-mips.org
Subject: Re: [PATCH v11 3/4] clk: Add rate constraints to clocks
Date: Wed, 21 Jan 2015 17:46:35 -0800	[thread overview]
Message-ID: <20150122014635.GI27202@codeaurora.org> (raw)
In-Reply-To: <1421847039-29544-4-git-send-email-tomeu.vizoso@collabora.com>

On 01/21, Tomeu Vizoso wrote:
> Adds a way for clock consumers to set maximum and minimum rates. This
> can be used for thermal drivers to set minimum rates, or by misc.
> drivers to set maximum rates to assure a minimum performance level.
> 
> Changes the signature of the determine_rate callback by adding the
> parameters min_rate and max_rate.
> 
> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> 
> ---
> v11:	* Recalculate the rate before putting the reference to clk_core
> 	* Don't recalculate the rate when freeing the per-user clock
> 	in the initialization error paths
> 	* Move __clk_create_clk to be next to __clk_free_clk for more
> 	comfortable reading

Can we do this in the previous patch where we introduce the
function?

> @@ -2143,9 +2314,16 @@ struct clk *__clk_register(struct device *dev, struct clk_hw *hw)
>  	else
>  		clk->owner = NULL;
>  
> +	INIT_HLIST_HEAD(&clk->clks);
> +
> +	hw->clk = __clk_create_clk(hw, NULL, NULL);
> +
>  	ret = __clk_init(dev, hw->clk);
> -	if (ret)
> +	if (ret) {
> +		__clk_free_clk(hw->clk);
> +		hw->clk = NULL;
>  		return ERR_PTR(ret);
> +	}
>  
>  	return hw->clk;
>  }
> @@ -2210,12 +2388,16 @@ struct clk *clk_register(struct device *dev, struct clk_hw *hw)
>  		}
>  	}
>  
> +	INIT_HLIST_HEAD(&clk->clks);
> +
>  	hw->clk = __clk_create_clk(hw, NULL, NULL);
>  	ret = __clk_init(dev, hw->clk);
>  	if (!ret)
>  		return hw->clk;
>  
> -	kfree(hw->clk);
> +	__clk_free_clk(hw->clk);
> +	hw->clk = NULL;

Shouldn't we be assigning to NULL in the previous patch (same
comment for __clk_register)?

>  fail_parent_names_copy:
>  	while (--i >= 0)
>  		kfree(clk->parent_names[i]);
> @@ -2420,7 +2602,14 @@ void __clk_put(struct clk *clk)
>  	if (!clk || WARN_ON_ONCE(IS_ERR(clk)))
>  		return;
>  
> +	clk_prepare_lock();
> +	hlist_del(&clk->child_node);
> +	clk_prepare_unlock();
> +
> +	clk_core_set_rate(clk->core, clk->core->req_rate);
> +
>  	clk_core_put(clk->core);
> +

Sad that we take the lock 3 times during __clk_put(). We should
be able to do it only once if we have a lockless
clk_core_set_rate() function and put the contents of
clk_core_put() into this function. Actually we need to do that to
be thread safe with clk->core->req_rate changing. We can call the
same function in clk_set_rate_range() too so that we don't have
to deal with recursive locking there.

>  	kfree(clk);
>  }
>  

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Boyd <sboyd@codeaurora.org>
To: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: linux-kernel@vger.kernel.org,
	"Mike Turquette" <mturquette@linaro.org>,
	"Javier Martinez Canillas" <javier.martinez@collabora.co.uk>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Tony Lindgren" <tony@atomide.com>,
	"Russell King" <linux@arm.linux.org.uk>,
	"Ralf Baechle" <ralf@linux-mips.org>,
	"Boris Brezillon" <boris.brezillon@free-electrons.com>,
	"Emilio López" <emilio@elopez.com.ar>,
	"Maxime Ripard" <maxime.ripard@free-electrons.com>,
	"Tero Kristo" <t-kristo@ti.com>,
	"Manuel Lauss" <manuel.lauss@gmail.com>,
	"Alex Elder" <elder@linaro.org>,
	"Matt Porter" <mporter@linaro.org>,
	"Zhangfei Gao" <zhangfei.gao@linaro.org>,
	"Haojian Zhuang" <haojian.zhuang@linaro.org>,
	"Jaehoon Chung" <jh80.chung@samsung.com>,
	"Bintian Wang" <bintian.wang@huawei.com>,
	"Chao Xie" <chao.xie@marvell.com>,
	linux-doc@vger.kernel.org, linux-omap@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-mips@linux-m
Subject: Re: [PATCH v11 3/4] clk: Add rate constraints to clocks
Date: Wed, 21 Jan 2015 17:46:35 -0800	[thread overview]
Message-ID: <20150122014635.GI27202@codeaurora.org> (raw)
In-Reply-To: <1421847039-29544-4-git-send-email-tomeu.vizoso@collabora.com>

On 01/21, Tomeu Vizoso wrote:
> Adds a way for clock consumers to set maximum and minimum rates. This
> can be used for thermal drivers to set minimum rates, or by misc.
> drivers to set maximum rates to assure a minimum performance level.
> 
> Changes the signature of the determine_rate callback by adding the
> parameters min_rate and max_rate.
> 
> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> 
> ---
> v11:	* Recalculate the rate before putting the reference to clk_core
> 	* Don't recalculate the rate when freeing the per-user clock
> 	in the initialization error paths
> 	* Move __clk_create_clk to be next to __clk_free_clk for more
> 	comfortable reading

Can we do this in the previous patch where we introduce the
function?

> @@ -2143,9 +2314,16 @@ struct clk *__clk_register(struct device *dev, struct clk_hw *hw)
>  	else
>  		clk->owner = NULL;
>  
> +	INIT_HLIST_HEAD(&clk->clks);
> +
> +	hw->clk = __clk_create_clk(hw, NULL, NULL);
> +
>  	ret = __clk_init(dev, hw->clk);
> -	if (ret)
> +	if (ret) {
> +		__clk_free_clk(hw->clk);
> +		hw->clk = NULL;
>  		return ERR_PTR(ret);
> +	}
>  
>  	return hw->clk;
>  }
> @@ -2210,12 +2388,16 @@ struct clk *clk_register(struct device *dev, struct clk_hw *hw)
>  		}
>  	}
>  
> +	INIT_HLIST_HEAD(&clk->clks);
> +
>  	hw->clk = __clk_create_clk(hw, NULL, NULL);
>  	ret = __clk_init(dev, hw->clk);
>  	if (!ret)
>  		return hw->clk;
>  
> -	kfree(hw->clk);
> +	__clk_free_clk(hw->clk);
> +	hw->clk = NULL;

Shouldn't we be assigning to NULL in the previous patch (same
comment for __clk_register)?

>  fail_parent_names_copy:
>  	while (--i >= 0)
>  		kfree(clk->parent_names[i]);
> @@ -2420,7 +2602,14 @@ void __clk_put(struct clk *clk)
>  	if (!clk || WARN_ON_ONCE(IS_ERR(clk)))
>  		return;
>  
> +	clk_prepare_lock();
> +	hlist_del(&clk->child_node);
> +	clk_prepare_unlock();
> +
> +	clk_core_set_rate(clk->core, clk->core->req_rate);
> +
>  	clk_core_put(clk->core);
> +

Sad that we take the lock 3 times during __clk_put(). We should
be able to do it only once if we have a lockless
clk_core_set_rate() function and put the contents of
clk_core_put() into this function. Actually we need to do that to
be thread safe with clk->core->req_rate changing. We can call the
same function in clk_set_rate_range() too so that we don't have
to deal with recursive locking there.

>  	kfree(clk);
>  }
>  

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

WARNING: multiple messages have this Message-ID (diff)
From: sboyd@codeaurora.org (Stephen Boyd)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v11 3/4] clk: Add rate constraints to clocks
Date: Wed, 21 Jan 2015 17:46:35 -0800	[thread overview]
Message-ID: <20150122014635.GI27202@codeaurora.org> (raw)
In-Reply-To: <1421847039-29544-4-git-send-email-tomeu.vizoso@collabora.com>

On 01/21, Tomeu Vizoso wrote:
> Adds a way for clock consumers to set maximum and minimum rates. This
> can be used for thermal drivers to set minimum rates, or by misc.
> drivers to set maximum rates to assure a minimum performance level.
> 
> Changes the signature of the determine_rate callback by adding the
> parameters min_rate and max_rate.
> 
> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
> 
> ---
> v11:	* Recalculate the rate before putting the reference to clk_core
> 	* Don't recalculate the rate when freeing the per-user clock
> 	in the initialization error paths
> 	* Move __clk_create_clk to be next to __clk_free_clk for more
> 	comfortable reading

Can we do this in the previous patch where we introduce the
function?

> @@ -2143,9 +2314,16 @@ struct clk *__clk_register(struct device *dev, struct clk_hw *hw)
>  	else
>  		clk->owner = NULL;
>  
> +	INIT_HLIST_HEAD(&clk->clks);
> +
> +	hw->clk = __clk_create_clk(hw, NULL, NULL);
> +
>  	ret = __clk_init(dev, hw->clk);
> -	if (ret)
> +	if (ret) {
> +		__clk_free_clk(hw->clk);
> +		hw->clk = NULL;
>  		return ERR_PTR(ret);
> +	}
>  
>  	return hw->clk;
>  }
> @@ -2210,12 +2388,16 @@ struct clk *clk_register(struct device *dev, struct clk_hw *hw)
>  		}
>  	}
>  
> +	INIT_HLIST_HEAD(&clk->clks);
> +
>  	hw->clk = __clk_create_clk(hw, NULL, NULL);
>  	ret = __clk_init(dev, hw->clk);
>  	if (!ret)
>  		return hw->clk;
>  
> -	kfree(hw->clk);
> +	__clk_free_clk(hw->clk);
> +	hw->clk = NULL;

Shouldn't we be assigning to NULL in the previous patch (same
comment for __clk_register)?

>  fail_parent_names_copy:
>  	while (--i >= 0)
>  		kfree(clk->parent_names[i]);
> @@ -2420,7 +2602,14 @@ void __clk_put(struct clk *clk)
>  	if (!clk || WARN_ON_ONCE(IS_ERR(clk)))
>  		return;
>  
> +	clk_prepare_lock();
> +	hlist_del(&clk->child_node);
> +	clk_prepare_unlock();
> +
> +	clk_core_set_rate(clk->core, clk->core->req_rate);
> +
>  	clk_core_put(clk->core);
> +

Sad that we take the lock 3 times during __clk_put(). We should
be able to do it only once if we have a lockless
clk_core_set_rate() function and put the contents of
clk_core_put() into this function. Actually we need to do that to
be thread safe with clk->core->req_rate changing. We can call the
same function in clk_set_rate_range() too so that we don't have
to deal with recursive locking there.

>  	kfree(clk);
>  }
>  

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

  reply	other threads:[~2015-01-22  1:46 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-21 13:30 [PATCH v11 0/4] Per-user clock constraints Tomeu Vizoso
2015-01-21 13:30 ` [PATCH v11 1/4] clk: Remove unneeded NULL checks Tomeu Vizoso
2015-01-21 13:30 ` [PATCH v11 2/4] clk: Make clk API return per-user struct clk instances Tomeu Vizoso
2015-01-21 13:30   ` Tomeu Vizoso
2015-01-21 13:30   ` Tomeu Vizoso
2015-01-22  1:01   ` Stephen Boyd
2015-01-22  1:01     ` Stephen Boyd
2015-01-22 11:15     ` Tomeu Vizoso
2015-01-22 11:15       ` Tomeu Vizoso
2015-01-22 18:59       ` Stephen Boyd
2015-01-22 18:59         ` Stephen Boyd
2015-01-23 10:24         ` Tomeu Vizoso
2015-01-23 10:24           ` Tomeu Vizoso
2015-01-21 13:30 ` [PATCH v11 3/4] clk: Add rate constraints to clocks Tomeu Vizoso
2015-01-21 13:30   ` Tomeu Vizoso
2015-01-22  1:46   ` Stephen Boyd [this message]
2015-01-22  1:46     ` Stephen Boyd
2015-01-22  1:46     ` Stephen Boyd
2015-01-22 14:42     ` Tomeu Vizoso
2015-01-22 14:42       ` Tomeu Vizoso
2015-01-22 14:42       ` Tomeu Vizoso
2015-01-21 13:30 ` [PATCH v11 4/4] clk: Add module for unit tests Tomeu Vizoso
2015-01-22  2:23   ` Stephen Boyd

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=20150122014635.GI27202@codeaurora.org \
    --to=sboyd@codeaurora.org \
    --cc=bintian.wang@huawei.com \
    --cc=boris.brezillon@free-electrons.com \
    --cc=chao.xie@marvell.com \
    --cc=corbet@lwn.net \
    --cc=elder@linaro.org \
    --cc=emilio@elopez.com.ar \
    --cc=haojian.zhuang@linaro.org \
    --cc=javier.martinez@collabora.co.uk \
    --cc=jh80.chung@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=manuel.lauss@gmail.com \
    --cc=maxime.ripard@free-electrons.com \
    --cc=mporter@linaro.org \
    --cc=mturquette@linaro.org \
    --cc=ralf@linux-mips.org \
    --cc=t-kristo@ti.com \
    --cc=tomeu.vizoso@collabora.com \
    --cc=tony@atomide.com \
    --cc=zhangfei.gao@linaro.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.