Quoting Stephen Boyd (2014-12-22 11:26:42)
> On 12/22/2014 10:38 AM, Stephen Boyd wrote:
> > On 12/22/2014 03:45 AM, Krzysztof Kozlowski wrote:
> >
> >> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> >> index f4963b7d4e17..35079302a650 100644
> >> --- a/drivers/clk/clk.c
> >> +++ b/drivers/clk/clk.c
> >> @@ -1150,6 +1150,12 @@ static int clk_fetch_parent_index(struct clk *clk, struct clk *parent)
> >> {
> >> int i;
> >>
> >> + if (clk->num_parents == 1) {
> >> + if (IS_ERR_OR_NULL(clk->parent))
> >> + clk->parent = __clk_lookup(clk->parent_names[0]);
> >> + return 0;
> >> + }
> >> +
> >> if (!clk->parents) {
> >> clk->parents = kcalloc(clk->num_parents,
> >> sizeof(struct clk *), GFP_KERNEL);
> > This may be a worthwhile optimization, but I wonder why the clk_ops for
> > this clock need to fetch the parent index at all? Which clock are we
> > actually dealing with here?
> >
>
> The clk_set_rate() call should still be fixed, but we can probably do
> this too.
>
> ---8<---
>
> From: Stephen Boyd <sboyd@xxxxxxxxxxxxxx>
> Date: Mon, 22 Dec 2014 11:24:28 -0800
> Subject: [PATCH] clk: Skip fetching index for single parent clocks
>
> We don't need to fetch the parent index for clocks if they only
> have one parent. Doing this also avoid an unnecessary allocation
> for the parent cache.
>
> Signed-off-by: Stephen Boyd <sboyd@xxxxxxxxxxxxxx>
> ---
> drivers/clk/clk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 675f37a7329f..e3a2d36124fd 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -1420,7 +1420,7 @@ static struct clk *clk_calc_new_rates(struct clk *clk, unsigned long rate)
> }
>
> /* try finding the new parent index */
> - if (parent) {
> + if (parent && clk->num_parents > 1) {
> p_index = clk_fetch_parent_index(clk, parent);
> if (p_index < 0) {
> pr_debug("%s: clk %s can not be parent of clk %s\n",
Applied to clk-next.
Regards,
Mike
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html