Message-ID: <3e6aa4c392ccdd3bac76b556645139536e61e5e6.camel@baylibre.com>
Date:   Fri, 15 Mar 2019 11:01:53 +0100
From:   Jerome Brunet <jbrunet@...libre.com>
To:     Stephen Boyd <sboyd@...nel.org>,
        Michael Turquette <mturquette@...libre.com>
Cc:     linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        Russell King <linux@...linux.org.uk>,
        Jeffrey Hugo <jhugo@...eaurora.org>,
        Chen-Yu Tsai <wens@...e.org>
Subject: Re: [PATCH v2 6/8] clk: Allow parents to be specified without
 string names

On Tue, 2019-02-26 at 14:34 -0800, Stephen Boyd wrote:
> The common clk framework is lacking in ability to describe the clk
> topology without specifying strings for every possible parent-child
> link. There are a few drawbacks to the current approach:
> 
>  1) String comparisons are used for everything, including describing
>  topologies that are 'local' to a single clock controller.
> 
>  2) clk providers (e.g. i2c clk drivers) need to create globally unique
>  clk names to avoid collisions in the clk namespace, leading to awkward
>  name generation code in various clk drivers.
> 
>  3) DT bindings may not fully describe the clk topology and linkages
>  between clk controllers because drivers can easily rely on globally unique
>  strings to describe connections between clks.
> 
> This leads to confusing DT bindings, complicated clk name generation
> code, and inefficient string comparisons during clk registration just so
> that the clk framework can detect the topology of the clk tree.
> Furthermore, some drivers call clk_get() and then __clk_get_name() to
> extract the globally unique clk name just so they can specify the parent
> of the clk they're registering. We have of_clk_parent_fill() but that
> mostly only works for single clks registered from a DT node, which isn't
> the norm. Let's simplify this all by introducing two new ways of
> specifying clk parents.
> 
> The first method is an array of pointers to clk_hw structures
> corresponding to the parents at that index. This works for clks that are
> registered when we have access to all the clk_hw pointers for the
> parents.
> 
> The second method is a mix of clk_hw pointers and strings of local and
> global parent clk names. If the .name member of the map is set we'll
> look for that clk by performing a DT based lookup of the device the clk
> is registered with and the .name specified in the map. If that fails,
> we'll fallback to the .fallback member and perform a global clk name
> lookup like we've always done before.
> 
> Using either one of these new methods is entirely optional. Existing
> drivers will continue to work, and they can migrate to this new approach
> as they see fit. Eventually, we'll want to get rid of the 'parent_names'
> array in struct clk_init_data and use one of these new methods instead.
> 
> Cc: Miquel Raynal <miquel.raynal@...tlin.com>
> Cc: Jerome Brunet <jbrunet@...libre.com>
> Cc: Russell King <linux@...linux.org.uk>
> Cc: Michael Turquette <mturquette@...libre.com>
> Cc: Jeffrey Hugo <jhugo@...eaurora.org>
> Cc: Chen-Yu Tsai <wens@...e.org>
> Signed-off-by: Stephen Boyd <sboyd@...nel.org>
> ---
>  drivers/clk/clk.c            | 260 ++++++++++++++++++++++++++---------
>  include/linux/clk-provider.h |  19 +++
>  2 files changed, 217 insertions(+), 62 deletions(-)

Sorry for the delay.

With the fix you sent to Jeffrey
Tested by porting the aoclk controller of Amlogic g12a SoC.
This allowed to test
 * hws only table
 * parent_data with a mix of hw pointers and fw_name (with different input
controllers and also an input that is optional and never provided)

Tested-by: Jerome Brunet <jbrunet@...libre.com>

With the small comment below

Reviewed-by Jerome Brunet <jbrunet@...libre.com>


> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 937b8d092d17..3d01e8c56400 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -39,6 +39,13 @@ static LIST_HEAD(clk_notifier_list);
>  

[...]

>  
> +static int clk_cpy_name(const char *dst, const char *src, bool must_exist)
> +{
> +	if (!src) {
> +		if (must_exist)
> +			return -EINVAL;
> +		return 0;
> +	}
> +
> +	dst = kstrdup_const(src, GFP_KERNEL);
> +	if (!dst)
> +		return -ENOMEM;
> +
> +	return 0;
> +}
> +
> +static int clk_core_populate_parent_map(struct clk_core *core)
> +{
> +	const struct clk_init_data *init = core->hw->init;
> +	u8 num_parents = init->num_parents;
> +	const char * const *parent_names = init->parent_names;
> +	const struct clk_hw **parent_hws = init->parent_hws;
> +	const struct clk_parent_data *parent_data = init->parent_data;
> +	int i, ret = 0;
> +	struct clk_parent_map *parents, *parent;
> +
> +	if (!num_parents)
> +		return 0;
> +
> +	/*
> +	 * Avoid unnecessary string look-ups of clk_core's possible parents by
> +	 * having a cache of names/clk_hw pointers to clk_core pointers.
> +	 */
> +	parents = kcalloc(num_parents, sizeof(*parents), GFP_KERNEL);
> +	core->parents = parents;
> +	if (!parents)
> +		return -ENOMEM;
> +
> +	/* Copy everything over because it might be __initdata */
> +	for (i = 0, parent = parents; i < num_parents; i++, parent++) {
> +		if (parent_names) {
> +			/* throw a WARN if any entries are NULL */
> +			WARN(!parent_names[i],
> +				"%s: invalid NULL in %s's .parent_names\n",
> +				__func__, core->name);
> +			ret = clk_cpy_name(parent->name, parent_names[i],
> +					   true);
> +		} else if (parent_data) {

While testing, I mistakenly left both parent_names and parent_data. I was
surprised that parent_data did not take precedence of parent_names.

Maybe it should ? (... but I understand we are not supposed to provide both)

> +			parent->hw = parent_data[i].hw;
> +			ret = clk_cpy_name(parent->fw_name,
> +					   parent_data[i].fw_name, false);
> +			if (!ret)
> +				ret = clk_cpy_name(parent->name,
> +						   parent_data[i].name,
> +						   false);
> +		} else if (parent_hws) {
> +			parent->hw = parent_hws[i];
> +		} else {

Maybe there should also some kinda of check to verify if more than one option
(among hws, parent_data and parent_names) was provided and throw a warn ?

Could be useful with drivers move away from parent_names ?

> +			ret = -EINVAL;
> +			WARN(1, "Must specify parents if num_parents > 0\n");
> +		}



> +
> +		if (ret) {
> +			do {
> +				kfree_const(parents[i].name);
> +				kfree_const(parents[i].fw_name);
> +			} while (--i >= 0);
> +			kfree(parents);
> +
> +			return ret;
> +		}
> +	}
> +
> +	return 0;
> +}
> +
> 

Powered by blists - more mailing lists