[PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks

[PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks

[Scott Wood]

From: Scott Wood <scottwood@freescale.com>

Commit fc4a05d4b0eb ("clk: Remove unused provider APIs") removed
__clk_get_num_parents() and clk_hw_get_parent_by_index(), leaving only
true provider API versions that operate on struct clk_hw.

qoriq-cpufreq needs these functions in order to determine the options
it has for calling clk_set_parent() and thus populate the cpufreq
table, so revive them as legitimate consumer APIs.

Signed-off-by: Scott Wood <scottwood@freescale.com>
---
v2: Add missing 'static inline' to stub functions.

v3: no changes

 drivers/clk/clk.c   | 19 +++++++++++++++++++
 include/linux/clk.h | 31 +++++++++++++++++++++++++++++++
 2 files changed, 50 insertions(+)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index d584004..d61a3fe 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -290,6 +290,12 @@ struct clk_hw *__clk_get_hw(struct clk *clk)
 }
 EXPORT_SYMBOL_GPL(__clk_get_hw);
 
+unsigned int clk_get_num_parents(struct clk *clk)
+{
+	return !clk ? 0 : clk->core->num_parents;
+}
+EXPORT_SYMBOL_GPL(clk_get_num_parents);
+
 unsigned int clk_hw_get_num_parents(const struct clk_hw *hw)
 {
 	return hw->core->num_parents;
@@ -358,6 +364,19 @@ static struct clk_core *clk_core_get_parent_by_index(struct clk_core *core,
 	return core->parents[index];
 }
 
+struct clk *clk_get_parent_by_index(struct clk *clk, unsigned int index)
+{
+	struct clk_core *parent;
+
+	if (!clk)
+		return NULL;
+
+	parent = clk_core_get_parent_by_index(clk->core, index);
+
+	return !parent ? NULL : parent->hw->clk;
+}
+EXPORT_SYMBOL_GPL(clk_get_parent_by_index);
+
 struct clk_hw *
 clk_hw_get_parent_by_index(const struct clk_hw *hw, unsigned int index)
 {
diff --git a/include/linux/clk.h b/include/linux/clk.h
index 0df4a51..acd115f 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -392,6 +392,26 @@ int clk_set_parent(struct clk *clk, struct clk *parent);
 struct clk *clk_get_parent(struct clk *clk);
 
 /**
+ * clk_get_parent_by_index - get a possible parent clock by index
+ * @clk: clock source
+ * @index: index into the array of possible parents of this clock
+ *
+ * Returns struct clk corresponding to the requested possible
+ * parent clock source, or NULL.
+ */
+struct clk *clk_get_parent_by_index(struct clk *clk,
+				    unsigned int index);
+
+/**
+ * clk_get_num_parents - get number of possible parents
+ * @clk: clock source
+ *
+ * Returns the number of possible parents of this clock,
+ * which can then be enumerated using clk_get_parent_by_index().
+ */
+unsigned int clk_get_num_parents(struct clk *clk);
+
+/**
  * clk_get_sys - get a clock based upon the device name
  * @dev_id: device name
  * @con_id: connection ID
@@ -461,6 +481,17 @@ static inline struct clk *clk_get_parent(struct clk *clk)
 	return NULL;
 }
 
+static inline struct clk *clk_get_parent_by_index(struct clk *clk,
+						  unsigned int index)
+{
+	return NULL;
+}
+
+static inline unsigned int clk_get_num_parents(struct clk *clk)
+{
+	return 0;
+}
+
 #endif
 
 /* clk_prepare_enable helps cases using clk_enable in non-atomic context. */
-- 
2.5.0

[PATCH v3 2/2] cpufreq: qoriq: Don't look at clock implementation details

[Scott Wood]

From: Scott Wood <scottwood@freescale.com>

Get the CPU clock's potential parent clocks from the clock interface
itself, rather than manually parsing the clocks property to find a
phandle, looking at the clock-names property of that, and assuming that
those are valid parent clocks for the cpu clock.

This is necessary now that the clocks are generated based on the clock
driver's knowledge of the chip rather than a fragile device-tree
description of the mux options.

We can now rely on the clock driver to ensure that the mux only exposes
options that are valid.  The cpufreq driver was currently being overly
conservative in some cases -- for example, the "min_cpufreq =
get_bus_freq()" restriction only applies to chips with erratum
A-004510, and whether the freq_mask used on p5020 is needed depends on
the actual frequencies of the PLLs (FWIW, p5040 has a similar
limitation but its .freq_mask was zero) -- and the frequency mask
mechanism made assumptions about particular parent clock indices that
are no longer valid.

Signed-off-by: Scott Wood <scottwood@freescale.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
---
v2: no changes

v3: Remove the now-unused pnode and the call to of_node_put()

 drivers/cpufreq/qoriq-cpufreq.c | 141 ++++++++++++----------------------------
 1 file changed, 41 insertions(+), 100 deletions(-)

diff --git a/drivers/cpufreq/qoriq-cpufreq.c b/drivers/cpufreq/qoriq-cpufreq.c
index 53d8c3f..d66b3da 100644
--- a/drivers/cpufreq/qoriq-cpufreq.c
+++ b/drivers/cpufreq/qoriq-cpufreq.c
@@ -37,53 +37,20 @@ struct cpu_data {
 	struct thermal_cooling_device *cdev;
 };
 
+/*
+ * Don't use cpufreq on this SoC -- used when the SoC would have otherwise
+ * matched a more generic compatible.
+ */
+#define SOC_BLACKLIST		1
+
 /**
  * struct soc_data - SoC specific data
- * @freq_mask: mask the disallowed frequencies
- * @flag: unique flags
+ * @flags: SOC_xxx
  */
 struct soc_data {
-	u32 freq_mask[4];
-	u32 flag;
-};
-
-#define FREQ_MASK	1
-/* see hardware specification for the allowed frqeuencies */
-static const struct soc_data sdata[] = {
-	{ /* used by p2041 and p3041 */
-		.freq_mask = {0x8, 0x8, 0x2, 0x2},
-		.flag = FREQ_MASK,
-	},
-	{ /* used by p5020 */
-		.freq_mask = {0x8, 0x2},
-		.flag = FREQ_MASK,
-	},
-	{ /* used by p4080, p5040 */
-		.freq_mask = {0},
-		.flag = 0,
-	},
+	u32 flags;
 };
 
-/*
- * the minimum allowed core frequency, in Hz
- * for chassis v1.0, >= platform frequency
- * for chassis v2.0, >= platform frequency / 2
- */
-static u32 min_cpufreq;
-static const u32 *fmask;
-
-#if defined(CONFIG_ARM)
-static int get_cpu_physical_id(int cpu)
-{
-	return topology_core_id(cpu);
-}
-#else
-static int get_cpu_physical_id(int cpu)
-{
-	return get_hard_smp_processor_id(cpu);
-}
-#endif
-
 static u32 get_bus_freq(void)
 {
 	struct device_node *soc;
@@ -101,9 +68,10 @@ static u32 get_bus_freq(void)
 	return sysfreq;
 }
 
-static struct device_node *cpu_to_clk_node(int cpu)
+static struct clk *cpu_to_clk(int cpu)
 {
-	struct device_node *np, *clk_np;
+	struct device_node *np;
+	struct clk *clk;
 
 	if (!cpu_present(cpu))
 		return NULL;
@@ -112,37 +80,28 @@ static struct device_node *cpu_to_clk_node(int cpu)
 	if (!np)
 		return NULL;
 
-	clk_np = of_parse_phandle(np, "clocks", 0);
-	if (!clk_np)
-		return NULL;
-
+	clk = of_clk_get(np, 0);
 	of_node_put(np);
-
-	return clk_np;
+	return clk;
 }
 
 /* traverse cpu nodes to get cpu mask of sharing clock wire */
 static void set_affected_cpus(struct cpufreq_policy *policy)
 {
-	struct device_node *np, *clk_np;
 	struct cpumask *dstp = policy->cpus;
+	struct clk *clk;
 	int i;
 
-	np = cpu_to_clk_node(policy->cpu);
-	if (!np)
-		return;
-
 	for_each_present_cpu(i) {
-		clk_np = cpu_to_clk_node(i);
-		if (!clk_np)
+		clk = cpu_to_clk(i);
+		if (IS_ERR(clk)) {
+			pr_err("%s: no clock for cpu %d\n", __func__, i);
 			continue;
+		}
 
-		if (clk_np == np)
+		if (clk_is_match(policy->clk, clk))
 			cpumask_set_cpu(i, dstp);
-
-		of_node_put(clk_np);
 	}
-	of_node_put(np);
 }
 
 /* reduce the duplicated frequencies in frequency table */
@@ -198,9 +157,9 @@ static void freq_table_sort(struct cpufreq_frequency_table *freq_table,
 
 static int qoriq_cpufreq_cpu_init(struct cpufreq_policy *policy)
 {
-	struct device_node *np, *pnode;
+	struct device_node *np;
 	int i, count, ret;
-	u32 freq, mask;
+	u32 freq;
 	struct clk *clk;
 	struct cpufreq_frequency_table *table;
 	struct cpu_data *data;
@@ -221,17 +180,12 @@ static int qoriq_cpufreq_cpu_init(struct cpufreq_policy *policy)
 		goto err_nomem2;
 	}
 
-	pnode = of_parse_phandle(np, "clocks", 0);
-	if (!pnode) {
-		pr_err("%s: could not get clock information\n", __func__);
-		goto err_nomem2;
-	}
+	count = clk_get_num_parents(policy->clk);
 
-	count = of_property_count_strings(pnode, "clock-names");
 	data->pclk = kcalloc(count, sizeof(struct clk *), GFP_KERNEL);
 	if (!data->pclk) {
 		pr_err("%s: no memory\n", __func__);
-		goto err_node;
+		goto err_nomem2;
 	}
 
 	table = kcalloc(count + 1, sizeof(*table), GFP_KERNEL);
@@ -240,23 +194,11 @@ static int qoriq_cpufreq_cpu_init(struct cpufreq_policy *policy)
 		goto err_pclk;
 	}
 
-	if (fmask)
-		mask = fmask[get_cpu_physical_id(cpu)];
-	else
-		mask = 0x0;
-
 	for (i = 0; i < count; i++) {
-		clk = of_clk_get(pnode, i);
+		clk = clk_get_parent_by_index(policy->clk, i);
 		data->pclk[i] = clk;
 		freq = clk_get_rate(clk);
-		/*
-		 * the clock is valid if its frequency is not masked
-		 * and large than minimum allowed frequency.
-		 */
-		if (freq < min_cpufreq || (mask & (1 << i)))
-			table[i].frequency = CPUFREQ_ENTRY_INVALID;
-		else
-			table[i].frequency = freq / 1000;
+		table[i].frequency = freq / 1000;
 		table[i].driver_data = i;
 	}
 	freq_table_redup(table, count);
@@ -282,18 +224,13 @@ static int qoriq_cpufreq_cpu_init(struct cpufreq_policy *policy)
 	policy->cpuinfo.transition_latency = u64temp + 1;
 
 	of_node_put(np);
-	of_node_put(pnode);
-
 	return 0;
 
 err_nomem1:
 	kfree(table);
 err_pclk:
 	kfree(data->pclk);
-err_node:
-	of_node_put(pnode);
 err_nomem2:
-	policy->driver_data = NULL;
 	kfree(data);
 err_np:
 	of_node_put(np);
@@ -357,12 +294,20 @@ static struct cpufreq_driver qoriq_cpufreq_driver = {
 	.attr		= cpufreq_generic_attr,
 };
 
+static const struct soc_data blacklist = {
+	.flags = SOC_BLACKLIST,
+};
+
 static const struct of_device_id node_matches[] __initconst = {
-	{ .compatible = "fsl,p2041-clockgen", .data = &sdata[0], },
-	{ .compatible = "fsl,p3041-clockgen", .data = &sdata[0], },
-	{ .compatible = "fsl,p5020-clockgen", .data = &sdata[1], },
-	{ .compatible = "fsl,p4080-clockgen", .data = &sdata[2], },
-	{ .compatible = "fsl,p5040-clockgen", .data = &sdata[2], },
+	/* e6500 cannot use cpufreq due to erratum A-008083 */
+	{ .compatible = "fsl,b4420-clockgen", &blacklist },
+	{ .compatible = "fsl,b4860-clockgen", &blacklist },
+	{ .compatible = "fsl,t2080-clockgen", &blacklist },
+	{ .compatible = "fsl,t4240-clockgen", &blacklist },
+
+	{ .compatible = "fsl,ls1021a-clockgen", },
+	{ .compatible = "fsl,p4080-clockgen", },
+	{ .compatible = "fsl,qoriq-clockgen-1.0", },
 	{ .compatible = "fsl,qoriq-clockgen-2.0", },
 	{}
 };
@@ -380,16 +325,12 @@ static int __init qoriq_cpufreq_init(void)
 
 	match = of_match_node(node_matches, np);
 	data = match->data;
-	if (data) {
-		if (data->flag)
-			fmask = data->freq_mask;
-		min_cpufreq = get_bus_freq();
-	} else {
-		min_cpufreq = get_bus_freq() / 2;
-	}
 
 	of_node_put(np);
 
+	if (data && data->flags & SOC_BLACKLIST)
+		return -ENODEV;
+
 	ret = cpufreq_register_driver(&qoriq_cpufreq_driver);
 	if (!ret)
 		pr_info("Freescale QorIQ CPU frequency scaling driver\n");
-- 
2.5.0

RE: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks

[Yuantian Tang]

Hi,

This patch is acked by clock maintainer. If no comments from anyone else, w=
e will merge it in next week.

Thanks,
Yuantian

> -----Original Message-----
> From: Scott Wood [mailto:oss@buserror.net]
> Sent: Thursday, June 16, 2016 2:21 PM
> To: Russell King <linux@armlinux.org.uk>; Michael Turquette
> <mturquette@baylibre.com>; Stephen Boyd <sboyd@codeaurora.org>;
> Viresh Kumar <viresh.kumar@linaro.org>; Rafael J. Wysocki
> <rjw@rjwysocki.net>
> Cc: linux-clk@vger.kernel.org; linux-pm@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org; Yuantian Tang <yuantian.tang@nxp.com>; Yang-Leo Li
> <leoyang.li@nxp.com>; Xiaofeng Ren <xiaofeng.ren@nxp.com>; Scott Wood
> <scottwood@freescale.com>
> Subject: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible
> parent clocks
>=20
> From: Scott Wood <scottwood@freescale.com>
>=20
> Commit fc4a05d4b0eb ("clk: Remove unused provider APIs") removed
> __clk_get_num_parents() and clk_hw_get_parent_by_index(), leaving only
> true provider API versions that operate on struct clk_hw.
>=20
> qoriq-cpufreq needs these functions in order to determine the options it =
has
> for calling clk_set_parent() and thus populate the cpufreq table, so revi=
ve
> them as legitimate consumer APIs.
>=20
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> v2: Add missing 'static inline' to stub functions.
>=20
> v3: no changes
>=20
>  drivers/clk/clk.c   | 19 +++++++++++++++++++
>  include/linux/clk.h | 31 +++++++++++++++++++++++++++++++
>  2 files changed, 50 insertions(+)
>=20
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index d584004..d61a3fe=
 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -290,6 +290,12 @@ struct clk_hw *__clk_get_hw(struct clk *clk)  }
> EXPORT_SYMBOL_GPL(__clk_get_hw);
>=20
> +unsigned int clk_get_num_parents(struct clk *clk) {
> +	return !clk ? 0 : clk->core->num_parents; }
> +EXPORT_SYMBOL_GPL(clk_get_num_parents);
> +
>  unsigned int clk_hw_get_num_parents(const struct clk_hw *hw)  {
>  	return hw->core->num_parents;
> @@ -358,6 +364,19 @@ static struct clk_core
> *clk_core_get_parent_by_index(struct clk_core *core,
>  	return core->parents[index];
>  }
>=20
> +struct clk *clk_get_parent_by_index(struct clk *clk, unsigned int
> +index) {
> +	struct clk_core *parent;
> +
> +	if (!clk)
> +		return NULL;
> +
> +	parent =3D clk_core_get_parent_by_index(clk->core, index);
> +
> +	return !parent ? NULL : parent->hw->clk; }
> +EXPORT_SYMBOL_GPL(clk_get_parent_by_index);
> +
>  struct clk_hw *
>  clk_hw_get_parent_by_index(const struct clk_hw *hw, unsigned int index)
> { diff --git a/include/linux/clk.h b/include/linux/clk.h index 0df4a51..a=
cd115f
> 100644
> --- a/include/linux/clk.h
> +++ b/include/linux/clk.h
> @@ -392,6 +392,26 @@ int clk_set_parent(struct clk *clk, struct clk *pare=
nt);
> struct clk *clk_get_parent(struct clk *clk);
>=20
>  /**
> + * clk_get_parent_by_index - get a possible parent clock by index
> + * @clk: clock source
> + * @index: index into the array of possible parents of this clock
> + *
> + * Returns struct clk corresponding to the requested possible
> + * parent clock source, or NULL.
> + */
> +struct clk *clk_get_parent_by_index(struct clk *clk,
> +				    unsigned int index);
> +
> +/**
> + * clk_get_num_parents - get number of possible parents
> + * @clk: clock source
> + *
> + * Returns the number of possible parents of this clock,
> + * which can then be enumerated using clk_get_parent_by_index().
> + */
> +unsigned int clk_get_num_parents(struct clk *clk);
> +
> +/**
>   * clk_get_sys - get a clock based upon the device name
>   * @dev_id: device name
>   * @con_id: connection ID
> @@ -461,6 +481,17 @@ static inline struct clk *clk_get_parent(struct clk =
*clk)
>  	return NULL;
>  }
>=20
> +static inline struct clk *clk_get_parent_by_index(struct clk *clk,
> +						  unsigned int index)
> +{
> +	return NULL;
> +}
> +
> +static inline unsigned int clk_get_num_parents(struct clk *clk) {
> +	return 0;
> +}
> +
>  #endif
>=20
>  /* clk_prepare_enable helps cases using clk_enable in non-atomic context=
.
> */
> --
> 2.5.0

RE: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks

[Yuantian Tang]

Hi,

This patch is acked by clock maintainer. If no comments from anyone else, we will merge it in next week.

Thanks,
Yuantian

> -----Original Message-----
> From: Scott Wood [mailto:oss@buserror.net]
> Sent: Thursday, June 16, 2016 2:21 PM
> To: Russell King <linux@armlinux.org.uk>; Michael Turquette
> <mturquette@baylibre.com>; Stephen Boyd <sboyd@codeaurora.org>;
> Viresh Kumar <viresh.kumar@linaro.org>; Rafael J. Wysocki
> <rjw@rjwysocki.net>
> Cc: linux-clk@vger.kernel.org; linux-pm@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org; Yuantian Tang <yuantian.tang@nxp.com>; Yang-Leo Li
> <leoyang.li@nxp.com>; Xiaofeng Ren <xiaofeng.ren@nxp.com>; Scott Wood
> <scottwood@freescale.com>
> Subject: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible
> parent clocks
> 
> From: Scott Wood <scottwood@freescale.com>
> 
> Commit fc4a05d4b0eb ("clk: Remove unused provider APIs") removed
> __clk_get_num_parents() and clk_hw_get_parent_by_index(), leaving only
> true provider API versions that operate on struct clk_hw.
> 
> qoriq-cpufreq needs these functions in order to determine the options it has
> for calling clk_set_parent() and thus populate the cpufreq table, so revive
> them as legitimate consumer APIs.
> 
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> v2: Add missing 'static inline' to stub functions.
> 
> v3: no changes
> 
>  drivers/clk/clk.c   | 19 +++++++++++++++++++
>  include/linux/clk.h | 31 +++++++++++++++++++++++++++++++
>  2 files changed, 50 insertions(+)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index d584004..d61a3fe 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -290,6 +290,12 @@ struct clk_hw *__clk_get_hw(struct clk *clk)  }
> EXPORT_SYMBOL_GPL(__clk_get_hw);
> 
> +unsigned int clk_get_num_parents(struct clk *clk) {
> +	return !clk ? 0 : clk->core->num_parents; }
> +EXPORT_SYMBOL_GPL(clk_get_num_parents);
> +
>  unsigned int clk_hw_get_num_parents(const struct clk_hw *hw)  {
>  	return hw->core->num_parents;
> @@ -358,6 +364,19 @@ static struct clk_core
> *clk_core_get_parent_by_index(struct clk_core *core,
>  	return core->parents[index];
>  }
> 
> +struct clk *clk_get_parent_by_index(struct clk *clk, unsigned int
> +index) {
> +	struct clk_core *parent;
> +
> +	if (!clk)
> +		return NULL;
> +
> +	parent = clk_core_get_parent_by_index(clk->core, index);
> +
> +	return !parent ? NULL : parent->hw->clk; }
> +EXPORT_SYMBOL_GPL(clk_get_parent_by_index);
> +
>  struct clk_hw *
>  clk_hw_get_parent_by_index(const struct clk_hw *hw, unsigned int index)
> { diff --git a/include/linux/clk.h b/include/linux/clk.h index 0df4a51..acd115f
> 100644
> --- a/include/linux/clk.h
> +++ b/include/linux/clk.h
> @@ -392,6 +392,26 @@ int clk_set_parent(struct clk *clk, struct clk *parent);
> struct clk *clk_get_parent(struct clk *clk);
> 
>  /**
> + * clk_get_parent_by_index - get a possible parent clock by index
> + * @clk: clock source
> + * @index: index into the array of possible parents of this clock
> + *
> + * Returns struct clk corresponding to the requested possible
> + * parent clock source, or NULL.
> + */
> +struct clk *clk_get_parent_by_index(struct clk *clk,
> +				    unsigned int index);
> +
> +/**
> + * clk_get_num_parents - get number of possible parents
> + * @clk: clock source
> + *
> + * Returns the number of possible parents of this clock,
> + * which can then be enumerated using clk_get_parent_by_index().
> + */
> +unsigned int clk_get_num_parents(struct clk *clk);
> +
> +/**
>   * clk_get_sys - get a clock based upon the device name
>   * @dev_id: device name
>   * @con_id: connection ID
> @@ -461,6 +481,17 @@ static inline struct clk *clk_get_parent(struct clk *clk)
>  	return NULL;
>  }
> 
> +static inline struct clk *clk_get_parent_by_index(struct clk *clk,
> +						  unsigned int index)
> +{
> +	return NULL;
> +}
> +
> +static inline unsigned int clk_get_num_parents(struct clk *clk) {
> +	return 0;
> +}
> +
>  #endif
> 
>  /* clk_prepare_enable helps cases using clk_enable in non-atomic context.
> */
> --
> 2.5.0

Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks

[Rafael J. Wysocki]

On Wednesday, June 29, 2016 05:50:26 AM Yuantian Tang wrote:
> Hi,
> 
> This patch is acked by clock maintainer. If no comments from anyone else, we will merge it in next week.

There is a cpufreq commit depending on it.  Are you going to handle that one too?

Thanks,
Rafael

RE: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks

[Yuantian Tang]

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBSYWZhZWwgSi4gV3lzb2NraSBb
bWFpbHRvOnJqd0Byand5c29ja2kubmV0XQ0KPiBTZW50OiBUaHVyc2RheSwgSnVuZSAzMCwgMjAx
NiA5OjQ3IEFNDQo+IFRvOiBZdWFudGlhbiBUYW5nIDx5dWFudGlhbi50YW5nQG54cC5jb20+DQo+
IENjOiBTY290dCBXb29kIDxvc3NAYnVzZXJyb3IubmV0PjsgUnVzc2VsbCBLaW5nIDxsaW51eEBh
cm1saW51eC5vcmcudWs+Ow0KPiBNaWNoYWVsIFR1cnF1ZXR0ZSA8bXR1cnF1ZXR0ZUBiYXlsaWJy
ZS5jb20+OyBTdGVwaGVuIEJveWQNCj4gPHNib3lkQGNvZGVhdXJvcmEub3JnPjsgVmlyZXNoIEt1
bWFyIDx2aXJlc2gua3VtYXJAbGluYXJvLm9yZz47IGxpbnV4LQ0KPiBjbGtAdmdlci5rZXJuZWwu
b3JnOyBsaW51eC1wbUB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4cHBjLQ0KPiBkZXZAbGlzdHMub3ps
YWJzLm9yZzsgWWFuZy1MZW8gTGkgPGxlb3lhbmcubGlAbnhwLmNvbT47IFhpYW9mZW5nIFJlbg0K
PiA8eGlhb2ZlbmcucmVuQG54cC5jb20+OyBTY290dCBXb29kIDxzY290dHdvb2RAZnJlZXNjYWxl
LmNvbT4NCj4gU3ViamVjdDogUmU6IFtQQVRDSCB2MyAxLzJdIGNsazogQWRkIGNvbnN1bWVyIEFQ
SXMgZm9yIGRpc2NvdmVyaW5nIHBvc3NpYmxlDQo+IHBhcmVudCBjbG9ja3MNCj4gDQo+IE9uIFdl
ZG5lc2RheSwgSnVuZSAyOSwgMjAxNiAwNTo1MDoyNiBBTSBZdWFudGlhbiBUYW5nIHdyb3RlOg0K
PiA+IEhpLA0KPiA+DQo+ID4gVGhpcyBwYXRjaCBpcyBhY2tlZCBieSBjbG9jayBtYWludGFpbmVy
LiBJZiBubyBjb21tZW50cyBmcm9tIGFueW9uZSBlbHNlLA0KPiB3ZSB3aWxsIG1lcmdlIGl0IGlu
IG5leHQgd2Vlay4NCj4gDQo+IFRoZXJlIGlzIGEgY3B1ZnJlcSBjb21taXQgZGVwZW5kaW5nIG9u
IGl0LiAgQXJlIHlvdSBnb2luZyB0byBoYW5kbGUgdGhhdCBvbmUNCj4gdG9vPw0KPiANClRoYXQg
b25lIGhhcyBiZWVuIGFja2VkIGJ5IGNwdWZyZXEgbWFpbnRhaW5lci4gWW91IGNhbiBnZXQgdGhp
cyBmcm9tIHBhdGNoIGNvbW1lbnRzLg0KDQpSZWdhcmRzLA0KWXVhbnRpYW4NCg0KUmUNCj4gVGhh
bmtzLA0KPiBSYWZhZWwNCg0K

RE: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks

[Yuantian Tang]

> -----Original Message-----
> From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> Sent: Thursday, June 30, 2016 9:47 AM
> To: Yuantian Tang <yuantian.tang@nxp.com>
> Cc: Scott Wood <oss@buserror.net>; Russell King <linux@armlinux.org.uk>;
> Michael Turquette <mturquette@baylibre.com>; Stephen Boyd
> <sboyd@codeaurora.org>; Viresh Kumar <viresh.kumar@linaro.org>; linux-
> clk@vger.kernel.org; linux-pm@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org; Yang-Leo Li <leoyang.li@nxp.com>; Xiaofeng Ren
> <xiaofeng.ren@nxp.com>; Scott Wood <scottwood@freescale.com>
> Subject: Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible
> parent clocks
> 
> On Wednesday, June 29, 2016 05:50:26 AM Yuantian Tang wrote:
> > Hi,
> >
> > This patch is acked by clock maintainer. If no comments from anyone else,
> we will merge it in next week.
> 
> There is a cpufreq commit depending on it.  Are you going to handle that one
> too?
> 
That one has been acked by cpufreq maintainer. You can get this from patch comments.

Regards,
Yuantian

Re
> Thanks,
> Rafael

Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks

[Rafael J. Wysocki]

On Thursday, June 30, 2016 01:47:09 AM Yuantian Tang wrote:
> > -----Original Message-----
> > From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> > Sent: Thursday, June 30, 2016 9:47 AM
> > To: Yuantian Tang <yuantian.tang@nxp.com>
> > Cc: Scott Wood <oss@buserror.net>; Russell King <linux@armlinux.org.uk>;
> > Michael Turquette <mturquette@baylibre.com>; Stephen Boyd
> > <sboyd@codeaurora.org>; Viresh Kumar <viresh.kumar@linaro.org>; linux-
> > clk@vger.kernel.org; linux-pm@vger.kernel.org; linuxppc-
> > dev@lists.ozlabs.org; Yang-Leo Li <leoyang.li@nxp.com>; Xiaofeng Ren
> > <xiaofeng.ren@nxp.com>; Scott Wood <scottwood@freescale.com>
> > Subject: Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible
> > parent clocks
> > 
> > On Wednesday, June 29, 2016 05:50:26 AM Yuantian Tang wrote:
> > > Hi,
> > >
> > > This patch is acked by clock maintainer. If no comments from anyone else,
> > we will merge it in next week.
> > 
> > There is a cpufreq commit depending on it.  Are you going to handle that one
> > too?
> > 
> That one has been acked by cpufreq maintainer. You can get this from patch comments.

I know that it has been ACKed.

My question is whether or not you are going to apply it along the [1/2].

If not, it will have to be deferred until the [1/2] is merged and then applied
which may not be desirable.

Thanks,
Rafael

RE: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks

[Yuantian Tang]

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBSYWZhZWwgSi4gV3lzb2NraSBb
bWFpbHRvOnJqd0Byand5c29ja2kubmV0XQ0KPiBTZW50OiBUaHVyc2RheSwgSnVuZSAzMCwgMjAx
NiAxMDoyNCBBTQ0KPiBUbzogWXVhbnRpYW4gVGFuZyA8eXVhbnRpYW4udGFuZ0BueHAuY29tPg0K
PiBDYzogU2NvdHQgV29vZCA8b3NzQGJ1c2Vycm9yLm5ldD47IFJ1c3NlbGwgS2luZyA8bGludXhA
YXJtbGludXgub3JnLnVrPjsNCj4gTWljaGFlbCBUdXJxdWV0dGUgPG10dXJxdWV0dGVAYmF5bGli
cmUuY29tPjsgU3RlcGhlbiBCb3lkDQo+IDxzYm95ZEBjb2RlYXVyb3JhLm9yZz47IFZpcmVzaCBL
dW1hciA8dmlyZXNoLmt1bWFyQGxpbmFyby5vcmc+OyBsaW51eC0NCj4gY2xrQHZnZXIua2VybmVs
Lm9yZzsgbGludXgtcG1Admdlci5rZXJuZWwub3JnOyBsaW51eHBwYy0NCj4gZGV2QGxpc3RzLm96
bGFicy5vcmc7IFlhbmctTGVvIExpIDxsZW95YW5nLmxpQG54cC5jb20+OyBYaWFvZmVuZyBSZW4N
Cj4gPHhpYW9mZW5nLnJlbkBueHAuY29tPjsgU2NvdHQgV29vZCA8c2NvdHR3b29kQGZyZWVzY2Fs
ZS5jb20+DQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggdjMgMS8yXSBjbGs6IEFkZCBjb25zdW1lciBB
UElzIGZvciBkaXNjb3ZlcmluZyBwb3NzaWJsZQ0KPiBwYXJlbnQgY2xvY2tzDQo+IA0KPiBPbiBU
aHVyc2RheSwgSnVuZSAzMCwgMjAxNiAwMTo0NzowOSBBTSBZdWFudGlhbiBUYW5nIHdyb3RlOg0K
PiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IFJhZmFlbCBKLiBX
eXNvY2tpIFttYWlsdG86cmp3QHJqd3lzb2NraS5uZXRdDQo+ID4gPiBTZW50OiBUaHVyc2RheSwg
SnVuZSAzMCwgMjAxNiA5OjQ3IEFNDQo+ID4gPiBUbzogWXVhbnRpYW4gVGFuZyA8eXVhbnRpYW4u
dGFuZ0BueHAuY29tPg0KPiA+ID4gQ2M6IFNjb3R0IFdvb2QgPG9zc0BidXNlcnJvci5uZXQ+OyBS
dXNzZWxsIEtpbmcNCj4gPiA+IDxsaW51eEBhcm1saW51eC5vcmcudWs+OyBNaWNoYWVsIFR1cnF1
ZXR0ZQ0KPiA+ID4gPG10dXJxdWV0dGVAYmF5bGlicmUuY29tPjsgU3RlcGhlbiBCb3lkIDxzYm95
ZEBjb2RlYXVyb3JhLm9yZz47DQo+ID4gPiBWaXJlc2ggS3VtYXIgPHZpcmVzaC5rdW1hckBsaW5h
cm8ub3JnPjsgbGludXgtIGNsa0B2Z2VyLmtlcm5lbC5vcmc7DQo+ID4gPiBsaW51eC1wbUB2Z2Vy
Lmtlcm5lbC5vcmc7IGxpbnV4cHBjLSBkZXZAbGlzdHMub3psYWJzLm9yZzsgWWFuZy1MZW8NCj4g
PiA+IExpIDxsZW95YW5nLmxpQG54cC5jb20+OyBYaWFvZmVuZyBSZW4gPHhpYW9mZW5nLnJlbkBu
eHAuY29tPjsgU2NvdHQNCj4gPiA+IFdvb2QgPHNjb3R0d29vZEBmcmVlc2NhbGUuY29tPg0KPiA+
ID4gU3ViamVjdDogUmU6IFtQQVRDSCB2MyAxLzJdIGNsazogQWRkIGNvbnN1bWVyIEFQSXMgZm9y
IGRpc2NvdmVyaW5nDQo+ID4gPiBwb3NzaWJsZSBwYXJlbnQgY2xvY2tzDQo+ID4gPg0KPiA+ID4g
T24gV2VkbmVzZGF5LCBKdW5lIDI5LCAyMDE2IDA1OjUwOjI2IEFNIFl1YW50aWFuIFRhbmcgd3Jv
dGU6DQo+ID4gPiA+IEhpLA0KPiA+ID4gPg0KPiA+ID4gPiBUaGlzIHBhdGNoIGlzIGFja2VkIGJ5
IGNsb2NrIG1haW50YWluZXIuIElmIG5vIGNvbW1lbnRzIGZyb20NCj4gPiA+ID4gYW55b25lIGVs
c2UsDQo+ID4gPiB3ZSB3aWxsIG1lcmdlIGl0IGluIG5leHQgd2Vlay4NCj4gPiA+DQo+ID4gPiBU
aGVyZSBpcyBhIGNwdWZyZXEgY29tbWl0IGRlcGVuZGluZyBvbiBpdC4gIEFyZSB5b3UgZ29pbmcg
dG8gaGFuZGxlDQo+ID4gPiB0aGF0IG9uZSB0b28/DQo+ID4gPg0KPiA+IFRoYXQgb25lIGhhcyBi
ZWVuIGFja2VkIGJ5IGNwdWZyZXEgbWFpbnRhaW5lci4gWW91IGNhbiBnZXQgdGhpcyBmcm9tDQo+
IHBhdGNoIGNvbW1lbnRzLg0KPiANCj4gSSBrbm93IHRoYXQgaXQgaGFzIGJlZW4gQUNLZWQuDQo+
IA0KPiBNeSBxdWVzdGlvbiBpcyB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGdvaW5nIHRvIGFwcGx5
IGl0IGFsb25nIHRoZSBbMS8yXS4NCj4gDQo+IElmIG5vdCwgaXQgd2lsbCBoYXZlIHRvIGJlIGRl
ZmVycmVkIHVudGlsIHRoZSBbMS8yXSBpcyBtZXJnZWQgYW5kIHRoZW4gYXBwbGllZA0KPiB3aGlj
aCBtYXkgbm90IGJlIGRlc2lyYWJsZS4NCj4gDQpJIGhvcGUgd2UgY2FuIGFwcGx5IGJvdGggYXQg
c2FtZSB0aW1lLiBTZWVtcyBTY290dCBoYXMgYSBmZXcgY29uY2VybnMuDQoNCldoYXQgeW91IHRo
aW5rIGFib3V0IHRoaXMgcGF0Y2g/IENhbiB5b3UgYXBwbHkgaXQ/DQpJZiB5b3UgaGF2ZSBhcHBs
aWVkIHRoaXMgcGF0Y2gsIHRoZW4gSSBjYW4gcHVzaCBDUFVmcmVxIG1haW50YWluZXIgdG8gYXBw
bHkgYW5vdGhlciBvbmUgd2hpY2ggd2lsbCBiZSBkZWxheWVkLg0KDQpSZWdhcmRzLA0KWXVhbnRp
YW4NCg0KPiBUaGFua3MsDQo+IFJhZmFlbA0KDQo=

RE: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks

[Yuantian Tang]

> -----Original Message-----
> From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> Sent: Thursday, June 30, 2016 10:24 AM
> To: Yuantian Tang <yuantian.tang@nxp.com>
> Cc: Scott Wood <oss@buserror.net>; Russell King <linux@armlinux.org.uk>;
> Michael Turquette <mturquette@baylibre.com>; Stephen Boyd
> <sboyd@codeaurora.org>; Viresh Kumar <viresh.kumar@linaro.org>; linux-
> clk@vger.kernel.org; linux-pm@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org; Yang-Leo Li <leoyang.li@nxp.com>; Xiaofeng Ren
> <xiaofeng.ren@nxp.com>; Scott Wood <scottwood@freescale.com>
> Subject: Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible
> parent clocks
> 
> On Thursday, June 30, 2016 01:47:09 AM Yuantian Tang wrote:
> > > -----Original Message-----
> > > From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> > > Sent: Thursday, June 30, 2016 9:47 AM
> > > To: Yuantian Tang <yuantian.tang@nxp.com>
> > > Cc: Scott Wood <oss@buserror.net>; Russell King
> > > <linux@armlinux.org.uk>; Michael Turquette
> > > <mturquette@baylibre.com>; Stephen Boyd <sboyd@codeaurora.org>;
> > > Viresh Kumar <viresh.kumar@linaro.org>; linux- clk@vger.kernel.org;
> > > linux-pm@vger.kernel.org; linuxppc- dev@lists.ozlabs.org; Yang-Leo
> > > Li <leoyang.li@nxp.com>; Xiaofeng Ren <xiaofeng.ren@nxp.com>; Scott
> > > Wood <scottwood@freescale.com>
> > > Subject: Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering
> > > possible parent clocks
> > >
> > > On Wednesday, June 29, 2016 05:50:26 AM Yuantian Tang wrote:
> > > > Hi,
> > > >
> > > > This patch is acked by clock maintainer. If no comments from
> > > > anyone else,
> > > we will merge it in next week.
> > >
> > > There is a cpufreq commit depending on it.  Are you going to handle
> > > that one too?
> > >
> > That one has been acked by cpufreq maintainer. You can get this from
> patch comments.
> 
> I know that it has been ACKed.
> 
> My question is whether or not you are going to apply it along the [1/2].
> 
> If not, it will have to be deferred until the [1/2] is merged and then applied
> which may not be desirable.
> 
I hope we can apply both at same time. Seems Scott has a few concerns.

What you think about this patch? Can you apply it?
If you have applied this patch, then I can push CPUfreq maintainer to apply another one which will be delayed.

Regards,
Yuantian

> Thanks,
> Rafael

Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks

[Scott Wood]

On 06/29/2016 10:02 PM, Yuantian Tang wrote:=0A=
>> -----Original Message-----=0A=
>> From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]=0A=
>> Sent: Thursday, June 30, 2016 10:24 AM=0A=
>> To: Yuantian Tang <yuantian.tang@nxp.com>=0A=
>> Cc: Scott Wood <oss@buserror.net>; Russell King <linux@armlinux.org.uk>;=
=0A=
>> Michael Turquette <mturquette@baylibre.com>; Stephen Boyd=0A=
>> <sboyd@codeaurora.org>; Viresh Kumar <viresh.kumar@linaro.org>; linux-=
=0A=
>> clk@vger.kernel.org; linux-pm@vger.kernel.org; linuxppc-=0A=
>> dev@lists.ozlabs.org; Yang-Leo Li <leoyang.li@nxp.com>; Xiaofeng Ren=0A=
>> <xiaofeng.ren@nxp.com>; Scott Wood <scottwood@freescale.com>=0A=
>> Subject: Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering possi=
ble=0A=
>> parent clocks=0A=
>>=0A=
>> On Thursday, June 30, 2016 01:47:09 AM Yuantian Tang wrote:=0A=
>>>> -----Original Message-----=0A=
>>>> From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]=0A=
>>>> Sent: Thursday, June 30, 2016 9:47 AM=0A=
>>>> To: Yuantian Tang <yuantian.tang@nxp.com>=0A=
>>>> Cc: Scott Wood <oss@buserror.net>; Russell King=0A=
>>>> <linux@armlinux.org.uk>; Michael Turquette=0A=
>>>> <mturquette@baylibre.com>; Stephen Boyd <sboyd@codeaurora.org>;=0A=
>>>> Viresh Kumar <viresh.kumar@linaro.org>; linux- clk@vger.kernel.org;=0A=
>>>> linux-pm@vger.kernel.org; linuxppc- dev@lists.ozlabs.org; Yang-Leo=0A=
>>>> Li <leoyang.li@nxp.com>; Xiaofeng Ren <xiaofeng.ren@nxp.com>; Scott=0A=
>>>> Wood <scottwood@freescale.com>=0A=
>>>> Subject: Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering=0A=
>>>> possible parent clocks=0A=
>>>>=0A=
>>>> On Wednesday, June 29, 2016 05:50:26 AM Yuantian Tang wrote:=0A=
>>>>> Hi,=0A=
>>>>>=0A=
>>>>> This patch is acked by clock maintainer. If no comments from=0A=
>>>>> anyone else,=0A=
>>>> we will merge it in next week.=0A=
>>>>=0A=
>>>> There is a cpufreq commit depending on it.  Are you going to handle=0A=
>>>> that one too?=0A=
>>>>=0A=
>>> That one has been acked by cpufreq maintainer. You can get this from=0A=
>> patch comments.=0A=
>>=0A=
>> I know that it has been ACKed.=0A=
>>=0A=
>> My question is whether or not you are going to apply it along the [1/2].=
=0A=
>>=0A=
>> If not, it will have to be deferred until the [1/2] is merged and then a=
pplied=0A=
>> which may not be desirable.=0A=
>>=0A=
> I hope we can apply both at same time. Seems Scott has a few concerns.=0A=
> =0A=
> What you think about this patch? Can you apply it?=0A=
> If you have applied this patch, then I can push CPUfreq maintainer to app=
ly another one which will be delayed.=0A=
=0A=
My only concern was getting an ack for this patch (1/2) -- did I miss it=0A=
somewhere?=0A=
=0A=
-Scott=0A=
=0A=

Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks

[Scott Wood]

On 06/29/2016 10:02 PM, Yuantian Tang wrote:
>> -----Original Message-----
>> From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
>> Sent: Thursday, June 30, 2016 10:24 AM
>> To: Yuantian Tang <yuantian.tang@nxp.com>
>> Cc: Scott Wood <oss@buserror.net>; Russell King <linux@armlinux.org.uk>;
>> Michael Turquette <mturquette@baylibre.com>; Stephen Boyd
>> <sboyd@codeaurora.org>; Viresh Kumar <viresh.kumar@linaro.org>; linux-
>> clk@vger.kernel.org; linux-pm@vger.kernel.org; linuxppc-
>> dev@lists.ozlabs.org; Yang-Leo Li <leoyang.li@nxp.com>; Xiaofeng Ren
>> <xiaofeng.ren@nxp.com>; Scott Wood <scottwood@freescale.com>
>> Subject: Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible
>> parent clocks
>>
>> On Thursday, June 30, 2016 01:47:09 AM Yuantian Tang wrote:
>>>> -----Original Message-----
>>>> From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
>>>> Sent: Thursday, June 30, 2016 9:47 AM
>>>> To: Yuantian Tang <yuantian.tang@nxp.com>
>>>> Cc: Scott Wood <oss@buserror.net>; Russell King
>>>> <linux@armlinux.org.uk>; Michael Turquette
>>>> <mturquette@baylibre.com>; Stephen Boyd <sboyd@codeaurora.org>;
>>>> Viresh Kumar <viresh.kumar@linaro.org>; linux- clk@vger.kernel.org;
>>>> linux-pm@vger.kernel.org; linuxppc- dev@lists.ozlabs.org; Yang-Leo
>>>> Li <leoyang.li@nxp.com>; Xiaofeng Ren <xiaofeng.ren@nxp.com>; Scott
>>>> Wood <scottwood@freescale.com>
>>>> Subject: Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering
>>>> possible parent clocks
>>>>
>>>> On Wednesday, June 29, 2016 05:50:26 AM Yuantian Tang wrote:
>>>>> Hi,
>>>>>
>>>>> This patch is acked by clock maintainer. If no comments from
>>>>> anyone else,
>>>> we will merge it in next week.
>>>>
>>>> There is a cpufreq commit depending on it.  Are you going to handle
>>>> that one too?
>>>>
>>> That one has been acked by cpufreq maintainer. You can get this from
>> patch comments.
>>
>> I know that it has been ACKed.
>>
>> My question is whether or not you are going to apply it along the [1/2].
>>
>> If not, it will have to be deferred until the [1/2] is merged and then applied
>> which may not be desirable.
>>
> I hope we can apply both at same time. Seems Scott has a few concerns.
> 
> What you think about this patch? Can you apply it?
> If you have applied this patch, then I can push CPUfreq maintainer to apply another one which will be delayed.

My only concern was getting an ack for this patch (1/2) -- did I miss it
somewhere?

-Scott

Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks

[Rafael J. Wysocki]

On Thursday, June 30, 2016 05:46:42 AM Scott Wood wrote:
> On 06/29/2016 10:02 PM, Yuantian Tang wrote:
> >> -----Original Message-----
> >> From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> >> Sent: Thursday, June 30, 2016 10:24 AM
> >> To: Yuantian Tang <yuantian.tang@nxp.com>
> >> Cc: Scott Wood <oss@buserror.net>; Russell King <linux@armlinux.org.uk>;
> >> Michael Turquette <mturquette@baylibre.com>; Stephen Boyd
> >> <sboyd@codeaurora.org>; Viresh Kumar <viresh.kumar@linaro.org>; linux-
> >> clk@vger.kernel.org; linux-pm@vger.kernel.org; linuxppc-
> >> dev@lists.ozlabs.org; Yang-Leo Li <leoyang.li@nxp.com>; Xiaofeng Ren
> >> <xiaofeng.ren@nxp.com>; Scott Wood <scottwood@freescale.com>
> >> Subject: Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible
> >> parent clocks
> >>
> >> On Thursday, June 30, 2016 01:47:09 AM Yuantian Tang wrote:
> >>>> -----Original Message-----
> >>>> From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> >>>> Sent: Thursday, June 30, 2016 9:47 AM
> >>>> To: Yuantian Tang <yuantian.tang@nxp.com>
> >>>> Cc: Scott Wood <oss@buserror.net>; Russell King
> >>>> <linux@armlinux.org.uk>; Michael Turquette
> >>>> <mturquette@baylibre.com>; Stephen Boyd <sboyd@codeaurora.org>;
> >>>> Viresh Kumar <viresh.kumar@linaro.org>; linux- clk@vger.kernel.org;
> >>>> linux-pm@vger.kernel.org; linuxppc- dev@lists.ozlabs.org; Yang-Leo
> >>>> Li <leoyang.li@nxp.com>; Xiaofeng Ren <xiaofeng.ren@nxp.com>; Scott
> >>>> Wood <scottwood@freescale.com>
> >>>> Subject: Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering
> >>>> possible parent clocks
> >>>>
> >>>> On Wednesday, June 29, 2016 05:50:26 AM Yuantian Tang wrote:
> >>>>> Hi,
> >>>>>
> >>>>> This patch is acked by clock maintainer. If no comments from
> >>>>> anyone else,
> >>>> we will merge it in next week.
> >>>>
> >>>> There is a cpufreq commit depending on it.  Are you going to handle
> >>>> that one too?
> >>>>
> >>> That one has been acked by cpufreq maintainer. You can get this from
> >> patch comments.
> >>
> >> I know that it has been ACKed.
> >>
> >> My question is whether or not you are going to apply it along the [1/2].
> >>
> >> If not, it will have to be deferred until the [1/2] is merged and then applied
> >> which may not be desirable.
> >>
> > I hope we can apply both at same time. Seems Scott has a few concerns.
> > 
> > What you think about this patch? Can you apply it?
> > If you have applied this patch, then I can push CPUfreq maintainer to apply another one which will be delayed.
> 
> My only concern was getting an ack for this patch (1/2) -- did I miss it
> somewhere?

OK, so who's going to apply the series?

Thanks,
Rafael

Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks

[Scott Wood]

On Thu, 2016-06-30 at 15:29 +0200, Rafael J. Wysocki wrote:
> On Thursday, June 30, 2016 05:46:42 AM Scott Wood wrote:
> > 
> > On 06/29/2016 10:02 PM, Yuantian Tang wrote:
> > > 
> > > > 
> > > > -----Original Message-----
> > > > From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> > > > Sent: Thursday, June 30, 2016 10:24 AM
> > > > To: Yuantian Tang <yuantian.tang@nxp.com>
> > > > Cc: Scott Wood <oss@buserror.net>; Russell King <linux@armlinux.org.uk
> > > > >;
> > > > Michael Turquette <mturquette@baylibre.com>; Stephen Boyd
> > > > <sboyd@codeaurora.org>; Viresh Kumar <viresh.kumar@linaro.org>; linux-
> > > > clk@vger.kernel.org; linux-pm@vger.kernel.org; linuxppc-
> > > > dev@lists.ozlabs.org; Yang-Leo Li <leoyang.li@nxp.com>; Xiaofeng Ren
> > > > <xiaofeng.ren@nxp.com>; Scott Wood <scottwood@freescale.com>
> > > > Subject: Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering
> > > > possible
> > > > parent clocks
> > > > 
> > > > On Thursday, June 30, 2016 01:47:09 AM Yuantian Tang wrote:
> > > > > 
> > > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> > > > > > Sent: Thursday, June 30, 2016 9:47 AM
> > > > > > To: Yuantian Tang <yuantian.tang@nxp.com>
> > > > > > Cc: Scott Wood <oss@buserror.net>; Russell King
> > > > > > <linux@armlinux.org.uk>; Michael Turquette
> > > > > > <mturquette@baylibre.com>; Stephen Boyd <sboyd@codeaurora.org>;
> > > > > > Viresh Kumar <viresh.kumar@linaro.org>; linux- clk@vger.kernel.org
> > > > > > ;
> > > > > > linux-pm@vger.kernel.org; linuxppc- dev@lists.ozlabs.org; Yang-Leo
> > > > > > Li <leoyang.li@nxp.com>; Xiaofeng Ren <xiaofeng.ren@nxp.com>;
> > > > > > Scott
> > > > > > Wood <scottwood@freescale.com>
> > > > > > Subject: Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering
> > > > > > possible parent clocks
> > > > > > 
> > > > > > On Wednesday, June 29, 2016 05:50:26 AM Yuantian Tang wrote:
> > > > > > > 
> > > > > > > Hi,
> > > > > > > 
> > > > > > > This patch is acked by clock maintainer. If no comments from
> > > > > > > anyone else,
> > > > > > we will merge it in next week.
> > > > > > 
> > > > > > There is a cpufreq commit depending on it.  Are you going to
> > > > > > handle
> > > > > > that one too?
> > > > > > 
> > > > > That one has been acked by cpufreq maintainer. You can get this from
> > > > patch comments.
> > > > 
> > > > I know that it has been ACKed.
> > > > 
> > > > My question is whether or not you are going to apply it along the
> > > > [1/2].
> > > > 
> > > > If not, it will have to be deferred until the [1/2] is merged and then
> > > > applied
> > > > which may not be desirable.
> > > > 
> > > I hope we can apply both at same time. Seems Scott has a few concerns.
> > > 
> > > What you think about this patch? Can you apply it?
> > > If you have applied this patch, then I can push CPUfreq maintainer to
> > > apply another one which will be delayed.
> > My only concern was getting an ack for this patch (1/2) -- did I miss it
> > somewhere?
> OK, so who's going to apply the series?

Ideally it should go via the cpufreq tree.

-Scott

Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks

[Scott Wood]

On Thu, 2016-06-30 at 15:29 +0200, Rafael J. Wysocki wrote:
> On Thursday, June 30, 2016 05:46:42 AM Scott Wood wrote:
> > 
> > On 06/29/2016 10:02 PM, Yuantian Tang wrote:
> > > 
> > > > 
> > > > -----Original Message-----
> > > > From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> > > > Sent: Thursday, June 30, 2016 10:24 AM
> > > > To: Yuantian Tang <yuantian.tang@nxp.com>
> > > > Cc: Scott Wood <oss@buserror.net>; Russell King <linux@armlinux.org.uk
> > > > >;
> > > > Michael Turquette <mturquette@baylibre.com>; Stephen Boyd
> > > > <sboyd@codeaurora.org>; Viresh Kumar <viresh.kumar@linaro.org>; linux-
> > > > clk@vger.kernel.org; linux-pm@vger.kernel.org; linuxppc-
> > > > dev@lists.ozlabs.org; Yang-Leo Li <leoyang.li@nxp.com>; Xiaofeng Ren
> > > > <xiaofeng.ren@nxp.com>; Scott Wood <scottwood@freescale.com>
> > > > Subject: Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering
> > > > possible
> > > > parent clocks
> > > > 
> > > > On Thursday, June 30, 2016 01:47:09 AM Yuantian Tang wrote:
> > > > > 
> > > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> > > > > > Sent: Thursday, June 30, 2016 9:47 AM
> > > > > > To: Yuantian Tang <yuantian.tang@nxp.com>
> > > > > > Cc: Scott Wood <oss@buserror.net>; Russell King
> > > > > > <linux@armlinux.org.uk>; Michael Turquette
> > > > > > <mturquette@baylibre.com>; Stephen Boyd <sboyd@codeaurora.org>;
> > > > > > Viresh Kumar <viresh.kumar@linaro.org>; linux- clk@vger.kernel.org
> > > > > > ;
> > > > > > linux-pm@vger.kernel.org; linuxppc- dev@lists.ozlabs.org; Yang-Leo
> > > > > > Li <leoyang.li@nxp.com>; Xiaofeng Ren <xiaofeng.ren@nxp.com>;
> > > > > > Scott
> > > > > > Wood <scottwood@freescale.com>
> > > > > > Subject: Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering
> > > > > > possible parent clocks
> > > > > > 
> > > > > > On Wednesday, June 29, 2016 05:50:26 AM Yuantian Tang wrote:
> > > > > > > 
> > > > > > > Hi,
> > > > > > > 
> > > > > > > This patch is acked by clock maintainer. If no comments from
> > > > > > > anyone else,
> > > > > > we will merge it in next week.
> > > > > > 
> > > > > > There is a cpufreq commit depending on it.  Are you going to
> > > > > > handle
> > > > > > that one too?
> > > > > > 
> > > > > That one has been acked by cpufreq maintainer. You can get this from
> > > > patch comments.
> > > > 
> > > > I know that it has been ACKed.
> > > > 
> > > > My question is whether or not you are going to apply it along the
> > > > [1/2].
> > > > 
> > > > If not, it will have to be deferred until the [1/2] is merged and then
> > > > applied
> > > > which may not be desirable.
> > > > 
> > > I hope we can apply both at same time. Seems Scott has a few concerns.
> > > 
> > > What you think about this patch? Can you apply it?
> > > If you have applied this patch, then I can push CPUfreq maintainer to
> > > apply another one which will be delayed.
> > My only concern was getting an ack for this patch (1/2) -- did I miss it
> > somewhere?
> OK, so who's going to apply the series?

Ideally it should go via the cpufreq tree.

-Scott

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks

[Rafael J. Wysocki]

On Friday, July 01, 2016 01:55:46 AM Scott Wood wrote:
> On Thu, 2016-06-30 at 15:29 +0200, Rafael J. Wysocki wrote:
> > On Thursday, June 30, 2016 05:46:42 AM Scott Wood wrote:
> > > 
> > > On 06/29/2016 10:02 PM, Yuantian Tang wrote:
> > > > 
> > > > > 
> > > > > -----Original Message-----
> > > > > From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> > > > > Sent: Thursday, June 30, 2016 10:24 AM
> > > > > To: Yuantian Tang <yuantian.tang@nxp.com>
> > > > > Cc: Scott Wood <oss@buserror.net>; Russell King <linux@armlinux.org.uk
> > > > > >;
> > > > > Michael Turquette <mturquette@baylibre.com>; Stephen Boyd
> > > > > <sboyd@codeaurora.org>; Viresh Kumar <viresh.kumar@linaro.org>; linux-
> > > > > clk@vger.kernel.org; linux-pm@vger.kernel.org; linuxppc-
> > > > > dev@lists.ozlabs.org; Yang-Leo Li <leoyang.li@nxp.com>; Xiaofeng Ren
> > > > > <xiaofeng.ren@nxp.com>; Scott Wood <scottwood@freescale.com>
> > > > > Subject: Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering
> > > > > possible
> > > > > parent clocks
> > > > > 
> > > > > On Thursday, June 30, 2016 01:47:09 AM Yuantian Tang wrote:
> > > > > > 
> > > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> > > > > > > Sent: Thursday, June 30, 2016 9:47 AM
> > > > > > > To: Yuantian Tang <yuantian.tang@nxp.com>
> > > > > > > Cc: Scott Wood <oss@buserror.net>; Russell King
> > > > > > > <linux@armlinux.org.uk>; Michael Turquette
> > > > > > > <mturquette@baylibre.com>; Stephen Boyd <sboyd@codeaurora.org>;
> > > > > > > Viresh Kumar <viresh.kumar@linaro.org>; linux- clk@vger.kernel.org
> > > > > > > ;
> > > > > > > linux-pm@vger.kernel.org; linuxppc- dev@lists.ozlabs.org; Yang-Leo
> > > > > > > Li <leoyang.li@nxp.com>; Xiaofeng Ren <xiaofeng.ren@nxp.com>;
> > > > > > > Scott
> > > > > > > Wood <scottwood@freescale.com>
> > > > > > > Subject: Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering
> > > > > > > possible parent clocks
> > > > > > > 
> > > > > > > On Wednesday, June 29, 2016 05:50:26 AM Yuantian Tang wrote:
> > > > > > > > 
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > This patch is acked by clock maintainer. If no comments from
> > > > > > > > anyone else,
> > > > > > > we will merge it in next week.
> > > > > > > 
> > > > > > > There is a cpufreq commit depending on it.  Are you going to
> > > > > > > handle
> > > > > > > that one too?
> > > > > > > 
> > > > > > That one has been acked by cpufreq maintainer. You can get this from
> > > > > patch comments.
> > > > > 
> > > > > I know that it has been ACKed.
> > > > > 
> > > > > My question is whether or not you are going to apply it along the
> > > > > [1/2].
> > > > > 
> > > > > If not, it will have to be deferred until the [1/2] is merged and then
> > > > > applied
> > > > > which may not be desirable.
> > > > > 
> > > > I hope we can apply both at same time. Seems Scott has a few concerns.
> > > > 
> > > > What you think about this patch? Can you apply it?
> > > > If you have applied this patch, then I can push CPUfreq maintainer to
> > > > apply another one which will be delayed.
> > > My only concern was getting an ack for this patch (1/2) -- did I miss it
> > > somewhere?
> > OK, so who's going to apply the series?
> 
> Ideally it should go via the cpufreq tree.

OK, I'll apply both, then.

Who exactly has ACKed the [1/2] from the clk side?

Thanks,
Rafael

Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks

[Scott Wood]

On Fri, 2016-07-01 at 22:53 +0200, Rafael J. Wysocki wrote:
> On Friday, July 01, 2016 01:55:46 AM Scott Wood wrote:
> > 
> > On Thu, 2016-06-30 at 15:29 +0200, Rafael J. Wysocki wrote:
> > > 
> > > On Thursday, June 30, 2016 05:46:42 AM Scott Wood wrote:
> > > > 
> > > > 
> > > > On 06/29/2016 10:02 PM, Yuantian Tang wrote:
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> > > > > > Sent: Thursday, June 30, 2016 10:24 AM
> > > > > > To: Yuantian Tang <yuantian.tang@nxp.com>
> > > > > > Cc: Scott Wood <oss@buserror.net>; Russell King <linux@armlinux.or
> > > > > > g.uk
> > > > > > > 
> > > > > > > ;
> > > > > > Michael Turquette <mturquette@baylibre.com>; Stephen Boyd
> > > > > > <sboyd@codeaurora.org>; Viresh Kumar <viresh.kumar@linaro.org>;
> > > > > > linux-
> > > > > > clk@vger.kernel.org; linux-pm@vger.kernel.org; linuxppc-
> > > > > > dev@lists.ozlabs.org; Yang-Leo Li <leoyang.li@nxp.com>; Xiaofeng
> > > > > > Ren
> > > > > > <xiaofeng.ren@nxp.com>; Scott Wood <scottwood@freescale.com>
> > > > > > Subject: Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering
> > > > > > possible
> > > > > > parent clocks
> > > > > > 
> > > > > > On Thursday, June 30, 2016 01:47:09 AM Yuantian Tang wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > -----Original Message-----
> > > > > > > > From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> > > > > > > > Sent: Thursday, June 30, 2016 9:47 AM
> > > > > > > > To: Yuantian Tang <yuantian.tang@nxp.com>
> > > > > > > > Cc: Scott Wood <oss@buserror.net>; Russell King
> > > > > > > > <linux@armlinux.org.uk>; Michael Turquette
> > > > > > > > <mturquette@baylibre.com>; Stephen Boyd <sboyd@codeaurora.org>
> > > > > > > > ;
> > > > > > > > Viresh Kumar <viresh.kumar@linaro.org>; linux- clk@vger.kernel
> > > > > > > > .org
> > > > > > > > ;
> > > > > > > > linux-pm@vger.kernel.org; linuxppc- dev@lists.ozlabs.org;
> > > > > > > > Yang-Leo
> > > > > > > > Li <leoyang.li@nxp.com>; Xiaofeng Ren <xiaofeng.ren@nxp.com>;
> > > > > > > > Scott
> > > > > > > > Wood <scottwood@freescale.com>
> > > > > > > > Subject: Re: [PATCH v3 1/2] clk: Add consumer APIs for
> > > > > > > > discovering
> > > > > > > > possible parent clocks
> > > > > > > > 
> > > > > > > > On Wednesday, June 29, 2016 05:50:26 AM Yuantian Tang wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > > This patch is acked by clock maintainer. If no comments from
> > > > > > > > > anyone else,
> > > > > > > > we will merge it in next week.
> > > > > > > > 
> > > > > > > > There is a cpufreq commit depending on it.  Are you going to
> > > > > > > > handle
> > > > > > > > that one too?
> > > > > > > > 
> > > > > > > That one has been acked by cpufreq maintainer. You can get this
> > > > > > > from
> > > > > > patch comments.
> > > > > > 
> > > > > > I know that it has been ACKed.
> > > > > > 
> > > > > > My question is whether or not you are going to apply it along the
> > > > > > [1/2].
> > > > > > 
> > > > > > If not, it will have to be deferred until the [1/2] is merged and
> > > > > > then
> > > > > > applied
> > > > > > which may not be desirable.
> > > > > > 
> > > > > I hope we can apply both at same time. Seems Scott has a few
> > > > > concerns.
> > > > > 
> > > > > What you think about this patch? Can you apply it?
> > > > > If you have applied this patch, then I can push CPUfreq maintainer
> > > > > to
> > > > > apply another one which will be delayed.
> > > > My only concern was getting an ack for this patch (1/2) -- did I miss
> > > > it
> > > > somewhere?
> > > OK, so who's going to apply the series?
> > Ideally it should go via the cpufreq tree.
> OK, I'll apply both, then.
> 
> Who exactly has ACKed the [1/2] from the clk side?

That's the problem.  I'm not sure what ACK Yuantian is referring to.  The last
I've heard from a clock maintainer was https://lkml.org/lkml/2015/9/18/816 des
pite repeated attempts to get Russell King to respond as clock API maintainer.

-Scott

Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks

[Scott Wood]

On Fri, 2016-07-01 at 22:53 +0200, Rafael J. Wysocki wrote:
> On Friday, July 01, 2016 01:55:46 AM Scott Wood wrote:
> > 
> > On Thu, 2016-06-30 at 15:29 +0200, Rafael J. Wysocki wrote:
> > > 
> > > On Thursday, June 30, 2016 05:46:42 AM Scott Wood wrote:
> > > > 
> > > > 
> > > > On 06/29/2016 10:02 PM, Yuantian Tang wrote:
> > > > > 
> > > > > 
> > > > > > 
> > > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> > > > > > Sent: Thursday, June 30, 2016 10:24 AM
> > > > > > To: Yuantian Tang <yuantian.tang@nxp.com>
> > > > > > Cc: Scott Wood <oss@buserror.net>; Russell King <linux@armlinux.or
> > > > > > g.uk
> > > > > > > 
> > > > > > > ;
> > > > > > Michael Turquette <mturquette@baylibre.com>; Stephen Boyd
> > > > > > <sboyd@codeaurora.org>; Viresh Kumar <viresh.kumar@linaro.org>;
> > > > > > linux-
> > > > > > clk@vger.kernel.org; linux-pm@vger.kernel.org; linuxppc-
> > > > > > dev@lists.ozlabs.org; Yang-Leo Li <leoyang.li@nxp.com>; Xiaofeng
> > > > > > Ren
> > > > > > <xiaofeng.ren@nxp.com>; Scott Wood <scottwood@freescale.com>
> > > > > > Subject: Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering
> > > > > > possible
> > > > > > parent clocks
> > > > > > 
> > > > > > On Thursday, June 30, 2016 01:47:09 AM Yuantian Tang wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > -----Original Message-----
> > > > > > > > From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
> > > > > > > > Sent: Thursday, June 30, 2016 9:47 AM
> > > > > > > > To: Yuantian Tang <yuantian.tang@nxp.com>
> > > > > > > > Cc: Scott Wood <oss@buserror.net>; Russell King
> > > > > > > > <linux@armlinux.org.uk>; Michael Turquette
> > > > > > > > <mturquette@baylibre.com>; Stephen Boyd <sboyd@codeaurora.org>
> > > > > > > > ;
> > > > > > > > Viresh Kumar <viresh.kumar@linaro.org>; linux- clk@vger.kernel
> > > > > > > > .org
> > > > > > > > ;
> > > > > > > > linux-pm@vger.kernel.org; linuxppc- dev@lists.ozlabs.org;
> > > > > > > > Yang-Leo
> > > > > > > > Li <leoyang.li@nxp.com>; Xiaofeng Ren <xiaofeng.ren@nxp.com>;
> > > > > > > > Scott
> > > > > > > > Wood <scottwood@freescale.com>
> > > > > > > > Subject: Re: [PATCH v3 1/2] clk: Add consumer APIs for
> > > > > > > > discovering
> > > > > > > > possible parent clocks
> > > > > > > > 
> > > > > > > > On Wednesday, June 29, 2016 05:50:26 AM Yuantian Tang wrote:
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Hi,
> > > > > > > > > 
> > > > > > > > > This patch is acked by clock maintainer. If no comments from
> > > > > > > > > anyone else,
> > > > > > > > we will merge it in next week.
> > > > > > > > 
> > > > > > > > There is a cpufreq commit depending on it.  Are you going to
> > > > > > > > handle
> > > > > > > > that one too?
> > > > > > > > 
> > > > > > > That one has been acked by cpufreq maintainer. You can get this
> > > > > > > from
> > > > > > patch comments.
> > > > > > 
> > > > > > I know that it has been ACKed.
> > > > > > 
> > > > > > My question is whether or not you are going to apply it along the
> > > > > > [1/2].
> > > > > > 
> > > > > > If not, it will have to be deferred until the [1/2] is merged and
> > > > > > then
> > > > > > applied
> > > > > > which may not be desirable.
> > > > > > 
> > > > > I hope we can apply both at same time. Seems Scott has a few
> > > > > concerns.
> > > > > 
> > > > > What you think about this patch? Can you apply it?
> > > > > If you have applied this patch, then I can push CPUfreq maintainer
> > > > > to
> > > > > apply another one which will be delayed.
> > > > My only concern was getting an ack for this patch (1/2) -- did I miss
> > > > it
> > > > somewhere?
> > > OK, so who's going to apply the series?
> > Ideally it should go via the cpufreq tree.
> OK, I'll apply both, then.
> 
> Who exactly has ACKed the [1/2] from the clk side?

That's the problem.  I'm not sure what ACK Yuantian is referring to.  The last
I've heard from a clock maintainer was https://lkml.org/lkml/2015/9/18/816 des
pite repeated attempts to get Russell King to respond as clock API maintainer.

-Scott

Re: [PATCH v3 2/2] cpufreq: qoriq: Don't look at clock implementation details

[Michael Turquette]

Quoting Scott Wood (2016-06-15 23:21:25)
> -static struct device_node *cpu_to_clk_node(int cpu)
> +static struct clk *cpu_to_clk(int cpu)
>  {
> -       struct device_node *np, *clk_np;
> +       struct device_node *np;
> +       struct clk *clk;
>  =

>         if (!cpu_present(cpu))
>                 return NULL;
> @@ -112,37 +80,28 @@ static struct device_node *cpu_to_clk_node(int cpu)
>         if (!np)
>                 return NULL;
>  =

> -       clk_np =3D of_parse_phandle(np, "clocks", 0);
> -       if (!clk_np)
> -               return NULL;
> -
> +       clk =3D of_clk_get(np, 0);

Why not use devm_clk_get here?

> @@ -221,17 +180,12 @@ static int qoriq_cpufreq_cpu_init(struct cpufreq_po=
licy *policy)
>                 goto err_nomem2;
>         }
>  =

> -       pnode =3D of_parse_phandle(np, "clocks", 0);
> -       if (!pnode) {
> -               pr_err("%s: could not get clock information\n", __func__);
> -               goto err_nomem2;
> -       }
> +       count =3D clk_get_num_parents(policy->clk);

We already have of_clk_get_parent_count. This is found in
clk-provider.h, which doesn't fit perfectly here since the cpufreq
driver is not a clock provider, but instead a consumer.

> @@ -240,23 +194,11 @@ static int qoriq_cpufreq_cpu_init(struct cpufreq_po=
licy *policy)
>                 goto err_pclk;
>         }
>  =

> -       if (fmask)
> -               mask =3D fmask[get_cpu_physical_id(cpu)];
> -       else
> -               mask =3D 0x0;
> -
>         for (i =3D 0; i < count; i++) {
> -               clk =3D of_clk_get(pnode, i);
> +               clk =3D clk_get_parent_by_index(policy->clk, i);
>                 data->pclk[i] =3D clk;
>                 freq =3D clk_get_rate(clk);
> -               /*
> -                * the clock is valid if its frequency is not masked
> -                * and large than minimum allowed frequency.
> -                */
> -               if (freq < min_cpufreq || (mask & (1 << i)))
> -                       table[i].frequency =3D CPUFREQ_ENTRY_INVALID;
> -               else
> -                       table[i].frequency =3D freq / 1000;
> +               table[i].frequency =3D freq / 1000;

Hmm, so you change cpu clock rate by selecting different clock sources
from a cpu clock mux, right? I wonder if you can just have a child mux
clock that selects parents from .set_rate (via a .determine_rate
callback)? Then you could just call clk_set_rate() on your cpu mux clock
and maybe skip most of the stuff this driver does?

Regards,
Mike

Re: [PATCH v3 2/2] cpufreq: qoriq: Don't look at clock implementation details

[Michael Turquette]

Quoting Scott Wood (2016-06-15 23:21:25)
> -static struct device_node *cpu_to_clk_node(int cpu)
> +static struct clk *cpu_to_clk(int cpu)
>  {
> -       struct device_node *np, *clk_np;
> +       struct device_node *np;
> +       struct clk *clk;
>  
>         if (!cpu_present(cpu))
>                 return NULL;
> @@ -112,37 +80,28 @@ static struct device_node *cpu_to_clk_node(int cpu)
>         if (!np)
>                 return NULL;
>  
> -       clk_np = of_parse_phandle(np, "clocks", 0);
> -       if (!clk_np)
> -               return NULL;
> -
> +       clk = of_clk_get(np, 0);

Why not use devm_clk_get here?

> @@ -221,17 +180,12 @@ static int qoriq_cpufreq_cpu_init(struct cpufreq_policy *policy)
>                 goto err_nomem2;
>         }
>  
> -       pnode = of_parse_phandle(np, "clocks", 0);
> -       if (!pnode) {
> -               pr_err("%s: could not get clock information\n", __func__);
> -               goto err_nomem2;
> -       }
> +       count = clk_get_num_parents(policy->clk);

We already have of_clk_get_parent_count. This is found in
clk-provider.h, which doesn't fit perfectly here since the cpufreq
driver is not a clock provider, but instead a consumer.

> @@ -240,23 +194,11 @@ static int qoriq_cpufreq_cpu_init(struct cpufreq_policy *policy)
>                 goto err_pclk;
>         }
>  
> -       if (fmask)
> -               mask = fmask[get_cpu_physical_id(cpu)];
> -       else
> -               mask = 0x0;
> -
>         for (i = 0; i < count; i++) {
> -               clk = of_clk_get(pnode, i);
> +               clk = clk_get_parent_by_index(policy->clk, i);
>                 data->pclk[i] = clk;
>                 freq = clk_get_rate(clk);
> -               /*
> -                * the clock is valid if its frequency is not masked
> -                * and large than minimum allowed frequency.
> -                */
> -               if (freq < min_cpufreq || (mask & (1 << i)))
> -                       table[i].frequency = CPUFREQ_ENTRY_INVALID;
> -               else
> -                       table[i].frequency = freq / 1000;
> +               table[i].frequency = freq / 1000;

Hmm, so you change cpu clock rate by selecting different clock sources
from a cpu clock mux, right? I wonder if you can just have a child mux
clock that selects parents from .set_rate (via a .determine_rate
callback)? Then you could just call clk_set_rate() on your cpu mux clock
and maybe skip most of the stuff this driver does?

Regards,
Mike

Re: [PATCH v3 2/2] cpufreq: qoriq: Don't look at clock implementation details

[Scott Wood]

On Wed, 2016-07-06 at 18:30 -0700, Michael Turquette wrote:
> Quoting Scott Wood (2016-06-15 23:21:25)
> > 
> > -static struct device_node *cpu_to_clk_node(int cpu)
> > +static struct clk *cpu_to_clk(int cpu)
> >  {
> > -       struct device_node *np, *clk_np;
> > +       struct device_node *np;
> > +       struct clk *clk;
> >  
> >         if (!cpu_present(cpu))
> >                 return NULL;
> > @@ -112,37 +80,28 @@ static struct device_node *cpu_to_clk_node(int cpu)
> >         if (!np)
> >                 return NULL;
> >  
> > -       clk_np = of_parse_phandle(np, "clocks", 0);
> > -       if (!clk_np)
> > -               return NULL;
> > -
> > +       clk = of_clk_get(np, 0);
> Why not use devm_clk_get here?

devm_clk_get() is a wrapper around clk_get() which is not the same as
of_clk_get().  What device would you pass to devm_clk_get(), and what name
would you pass?

> > 
> > @@ -221,17 +180,12 @@ static int qoriq_cpufreq_cpu_init(struct
> > cpufreq_policy *policy)
> >                 goto err_nomem2;
> >         }
> >  
> > -       pnode = of_parse_phandle(np, "clocks", 0);
> > -       if (!pnode) {
> > -               pr_err("%s: could not get clock information\n", __func__);
> > -               goto err_nomem2;
> > -       }
> > +       count = clk_get_num_parents(policy->clk);
> We already have of_clk_get_parent_count. This is found in
> clk-provider.h, which doesn't fit perfectly here since the cpufreq
> driver is not a clock provider, but instead a consumer.

It's also a device tree function, and the clock parents in question aren't in
the device tree.

> > @@ -240,23 +194,11 @@ static int qoriq_cpufreq_cpu_init(struct
> > cpufreq_policy *policy)
> >                 goto err_pclk;
> >         }
> >  
> > -       if (fmask)
> > -               mask = fmask[get_cpu_physical_id(cpu)];
> > -       else
> > -               mask = 0x0;
> > -
> >         for (i = 0; i < count; i++) {
> > -               clk = of_clk_get(pnode, i);
> > +               clk = clk_get_parent_by_index(policy->clk, i);
> >                 data->pclk[i] = clk;
> >                 freq = clk_get_rate(clk);
> > -               /*
> > -                * the clock is valid if its frequency is not masked
> > -                * and large than minimum allowed frequency.
> > -                */
> > -               if (freq < min_cpufreq || (mask & (1 << i)))
> > -                       table[i].frequency = CPUFREQ_ENTRY_INVALID;
> > -               else
> > -                       table[i].frequency = freq / 1000;
> > +               table[i].frequency = freq / 1000;
> Hmm, so you change cpu clock rate by selecting different clock sources
> from a cpu clock mux, right?

Yes.  You'd think such a simple thing would be more straightforward.

>  I wonder if you can just have a child mux
> clock that selects parents from .set_rate (via a .determine_rate
> callback)? Then you could just call clk_set_rate() on your cpu mux clock
> and maybe skip most of the stuff this driver does?

"Most of the stuff this driver does" is dealing with the cpufreq subsystem
(ask the cpufreq maintainers why it requires so much boilerplate), associating
clock muxes with cpus, etc.  It is also not obvious to me how to use
determine_rate() or that the end result would be any simpler or better.  It
seems like the implementation would just be reimplementing logic that already
exists in cpufreq, and the cpufreq driver would still need to be able to get a
list of possible frequencies, because cpufreq wants a table of them.

After nearly a year of non-response to these patches[1], a request to
completely rearchitect this driver[2] just to avoid exposing a couple
straightforward informational functions to clock consumers[3] was not quite
what I was hoping for.  What is wrong with clock consumers being able to query
the parent list, given that clock consumers have the ability to request a
particular parent?

-Scott

[1] Original versions:
http://www.spinics.net/lists/linux-clk/msg03069.html
http://www.spinics.net/lists/linux-clk/msg03070.html


[2] The only reason I'm touching this driver at all is because it currently
makes bad assumptions about clock provider internals (and clock provider
device tree structure) that are broken by the new bindings enabled by
commit 0dfc86b3173fee ("clk: qoriq: Move chip-specific knowledge into
driver").

[3] I initially discussed adding consumer APIs for this patchset in 
http://lkml.iu.edu/hypermail/linux/kernel/1509.2/02728.html

Re: [PATCH v3 2/2] cpufreq: qoriq: Don't look at clock implementation details

[Michael Turquette]

Quoting Scott Wood (2016-07-06 21:13:23)
> On Wed, 2016-07-06 at 18:30 -0700, Michael Turquette wrote:
> > Quoting Scott Wood (2016-06-15 23:21:25)
> > > =

> > > -static struct device_node *cpu_to_clk_node(int cpu)
> > > +static struct clk *cpu_to_clk(int cpu)
> > > =C2=A0{
> > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0struct device_node *np, *c=
lk_np;
> > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0struct device_node *np;
> > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0struct clk *clk;
> > > =C2=A0
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if (!cpu_present(cpu))
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0return NULL;
> > > @@ -112,37 +80,28 @@ static struct device_node *cpu_to_clk_node(int c=
pu)
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if (!np)
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0return NULL;
> > > =C2=A0
> > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0clk_np =3D of_parse_phandl=
e(np, "clocks", 0);
> > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if (!clk_np)
> > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0return NULL;
> > > -
> > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0clk =3D of_clk_get(np, 0);
> > Why not use devm_clk_get here?
> =

> devm_clk_get() is a wrapper around clk_get() which is not the same as
> of_clk_get(). =C2=A0What device would you pass to devm_clk_get(), and wha=
t name
> would you pass?

I'm fuzzy on whether or not you get a struct device from a cpufreq
driver. If so, then that would be the one to use. I would hope that
cpufreq drivers model cpus as devices, but I'm really not sure without
looking into the code.

Regards,
Mike

> =

> > > =

> > > @@ -221,17 +180,12 @@ static int qoriq_cpufreq_cpu_init(struct
> > > cpufreq_policy *policy)
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0goto err_nomem2;
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}
> > > =C2=A0
> > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0pnode =3D of_parse_phandle=
(np, "clocks", 0);
> > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if (!pnode) {
> > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0pr_err("%s: could not get clock information\n", __f=
unc__);
> > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0goto err_nomem2;
> > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}
> > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0count =3D clk_get_num_pare=
nts(policy->clk);
> > We already have of_clk_get_parent_count. This is found in
> > clk-provider.h, which doesn't fit perfectly here since the cpufreq
> > driver is not a clock provider, but instead a consumer.
> =

> It's also a device tree function, and the clock parents in question aren'=
t in
> the device tree.
> =

> > > @@ -240,23 +194,11 @@ static int qoriq_cpufreq_cpu_init(struct
> > > cpufreq_policy *policy)
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0goto err_pclk;
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}
> > > =C2=A0
> > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if (fmask)
> > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0mask =3D fmask[get_cpu_physical_id(cpu)];
> > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0else
> > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0mask =3D 0x0;
> > > -
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0for (i =3D 0; i < cou=
nt; i++) {
> > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0clk =3D of_clk_get(pnode, i);
> > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0clk =3D clk_get_parent_by_index(policy->clk, i);
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0data->pclk[i] =3D clk;
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0freq =3D clk_get_rate(clk);
> > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0/*
> > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0* the clock is valid if its frequency is not =
masked
> > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0* and large than minimum allowed frequency.
> > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0*/
> > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0if (freq < min_cpufreq || (mask & (1 << i)))
> > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0tab=
le[i].frequency =3D CPUFREQ_ENTRY_INVALID;
> > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0else
> > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0tab=
le[i].frequency =3D freq / 1000;
> > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0table[i].frequency =3D freq / 1000;
> > Hmm, so you change cpu clock rate by selecting different clock sources
> > from a cpu clock mux, right?
> =

> Yes. =C2=A0You'd think such a simple thing would be more straightforward.
> =

> >  I wonder if you can just have a child mux
> > clock that selects parents from .set_rate (via a .determine_rate
> > callback)? Then you could just call clk_set_rate() on your cpu mux clock
> > and maybe skip most of the stuff this driver does?
> =

> "Most of the stuff this driver does" is dealing with the cpufreq subsystem
> (ask the cpufreq maintainers why it requires so much boilerplate), associ=
ating
> clock muxes with cpus, etc. =C2=A0It is also not obvious to me how to use
> determine_rate() or that the end result would be any simpler or better. =
=C2=A0It
> seems like the implementation would just be reimplementing logic that alr=
eady
> exists in cpufreq, and the cpufreq driver would still need to be able to =
get a
> list of possible frequencies, because cpufreq wants a table of them.
> =

> After nearly a year of non-response to these patches[1], a request to
> completely rearchitect this driver[2] just to avoid exposing a couple
> straightforward informational functions to clock consumers[3] was not qui=
te
> what I was hoping for. =C2=A0What is wrong with clock consumers being abl=
e to query
> the parent list, given that clock consumers have the ability to request a
> particular parent?
> =

> -Scott
> =

> [1] Original versions:
> http://www.spinics.net/lists/linux-clk/msg03069.html
> http://www.spinics.net/lists/linux-clk/msg03070.html
> =

> =

> [2] The only reason I'm touching this driver at all is because it current=
ly
> makes bad assumptions about clock provider internals (and clock provider
> device tree structure) that are broken by the new bindings enabled by
> commit=C2=A00dfc86b3173fee ("clk: qoriq: Move chip-specific knowledge into
> driver").
> =

> [3] I initially discussed adding consumer APIs for this patchset in=C2=A0
> http://lkml.iu.edu/hypermail/linux/kernel/1509.2/02728.html
>=20

Re: [PATCH v3 2/2] cpufreq: qoriq: Don't look at clock implementation details

[Michael Turquette]

Quoting Scott Wood (2016-07-06 21:13:23)
> On Wed, 2016-07-06 at 18:30 -0700, Michael Turquette wrote:
> > Quoting Scott Wood (2016-06-15 23:21:25)
> > > 
> > > -static struct device_node *cpu_to_clk_node(int cpu)
> > > +static struct clk *cpu_to_clk(int cpu)
> > >  {
> > > -       struct device_node *np, *clk_np;
> > > +       struct device_node *np;
> > > +       struct clk *clk;
> > >  
> > >         if (!cpu_present(cpu))
> > >                 return NULL;
> > > @@ -112,37 +80,28 @@ static struct device_node *cpu_to_clk_node(int cpu)
> > >         if (!np)
> > >                 return NULL;
> > >  
> > > -       clk_np = of_parse_phandle(np, "clocks", 0);
> > > -       if (!clk_np)
> > > -               return NULL;
> > > -
> > > +       clk = of_clk_get(np, 0);
> > Why not use devm_clk_get here?
> 
> devm_clk_get() is a wrapper around clk_get() which is not the same as
> of_clk_get().  What device would you pass to devm_clk_get(), and what name
> would you pass?

I'm fuzzy on whether or not you get a struct device from a cpufreq
driver. If so, then that would be the one to use. I would hope that
cpufreq drivers model cpus as devices, but I'm really not sure without
looking into the code.

Regards,
Mike

> 
> > > 
> > > @@ -221,17 +180,12 @@ static int qoriq_cpufreq_cpu_init(struct
> > > cpufreq_policy *policy)
> > >                 goto err_nomem2;
> > >         }
> > >  
> > > -       pnode = of_parse_phandle(np, "clocks", 0);
> > > -       if (!pnode) {
> > > -               pr_err("%s: could not get clock information\n", __func__);
> > > -               goto err_nomem2;
> > > -       }
> > > +       count = clk_get_num_parents(policy->clk);
> > We already have of_clk_get_parent_count. This is found in
> > clk-provider.h, which doesn't fit perfectly here since the cpufreq
> > driver is not a clock provider, but instead a consumer.
> 
> It's also a device tree function, and the clock parents in question aren't in
> the device tree.
> 
> > > @@ -240,23 +194,11 @@ static int qoriq_cpufreq_cpu_init(struct
> > > cpufreq_policy *policy)
> > >                 goto err_pclk;
> > >         }
> > >  
> > > -       if (fmask)
> > > -               mask = fmask[get_cpu_physical_id(cpu)];
> > > -       else
> > > -               mask = 0x0;
> > > -
> > >         for (i = 0; i < count; i++) {
> > > -               clk = of_clk_get(pnode, i);
> > > +               clk = clk_get_parent_by_index(policy->clk, i);
> > >                 data->pclk[i] = clk;
> > >                 freq = clk_get_rate(clk);
> > > -               /*
> > > -                * the clock is valid if its frequency is not masked
> > > -                * and large than minimum allowed frequency.
> > > -                */
> > > -               if (freq < min_cpufreq || (mask & (1 << i)))
> > > -                       table[i].frequency = CPUFREQ_ENTRY_INVALID;
> > > -               else
> > > -                       table[i].frequency = freq / 1000;
> > > +               table[i].frequency = freq / 1000;
> > Hmm, so you change cpu clock rate by selecting different clock sources
> > from a cpu clock mux, right?
> 
> Yes.  You'd think such a simple thing would be more straightforward.
> 
> >  I wonder if you can just have a child mux
> > clock that selects parents from .set_rate (via a .determine_rate
> > callback)? Then you could just call clk_set_rate() on your cpu mux clock
> > and maybe skip most of the stuff this driver does?
> 
> "Most of the stuff this driver does" is dealing with the cpufreq subsystem
> (ask the cpufreq maintainers why it requires so much boilerplate), associating
> clock muxes with cpus, etc.  It is also not obvious to me how to use
> determine_rate() or that the end result would be any simpler or better.  It
> seems like the implementation would just be reimplementing logic that already
> exists in cpufreq, and the cpufreq driver would still need to be able to get a
> list of possible frequencies, because cpufreq wants a table of them.
> 
> After nearly a year of non-response to these patches[1], a request to
> completely rearchitect this driver[2] just to avoid exposing a couple
> straightforward informational functions to clock consumers[3] was not quite
> what I was hoping for.  What is wrong with clock consumers being able to query
> the parent list, given that clock consumers have the ability to request a
> particular parent?
> 
> -Scott
> 
> [1] Original versions:
> http://www.spinics.net/lists/linux-clk/msg03069.html
> http://www.spinics.net/lists/linux-clk/msg03070.html
> 
> 
> [2] The only reason I'm touching this driver at all is because it currently
> makes bad assumptions about clock provider internals (and clock provider
> device tree structure) that are broken by the new bindings enabled by
> commit 0dfc86b3173fee ("clk: qoriq: Move chip-specific knowledge into
> driver").
> 
> [3] I initially discussed adding consumer APIs for this patchset in 
> http://lkml.iu.edu/hypermail/linux/kernel/1509.2/02728.html
> 

Re: [PATCH v3 2/2] cpufreq: qoriq: Don't look at clock implementation details

[Scott Wood]

On Thu, 2016-07-07 at 19:26 -0700, Michael Turquette wrote:
> Quoting Scott Wood (2016-07-06 21:13:23)
> > 
> > On Wed, 2016-07-06 at 18:30 -0700, Michael Turquette wrote:
> > > 
> > > Quoting Scott Wood (2016-06-15 23:21:25)
> > > > 
> > > > 
> > > > -static struct device_node *cpu_to_clk_node(int cpu)
> > > > +static struct clk *cpu_to_clk(int cpu)
> > > >  {
> > > > -       struct device_node *np, *clk_np;
> > > > +       struct device_node *np;
> > > > +       struct clk *clk;
> > > >  
> > > >         if (!cpu_present(cpu))
> > > >                 return NULL;
> > > > @@ -112,37 +80,28 @@ static struct device_node *cpu_to_clk_node(int
> > > > cpu)
> > > >         if (!np)
> > > >                 return NULL;
> > > >  
> > > > -       clk_np = of_parse_phandle(np, "clocks", 0);
> > > > -       if (!clk_np)
> > > > -               return NULL;
> > > > -
> > > > +       clk = of_clk_get(np, 0);
> > > Why not use devm_clk_get here?
> > devm_clk_get() is a wrapper around clk_get() which is not the same as
> > of_clk_get().  What device would you pass to devm_clk_get(), and what name
> > would you pass?
> I'm fuzzy on whether or not you get a struct device from a cpufreq
> driver. If so, then that would be the one to use. I would hope that
> cpufreq drivers model cpus as devices, but I'm really not sure without
> looking into the code.

It's not the cpufreq code that provides it, but get_cpu_device() could be
used.

Do you have any comments on the first patch of this set?

-Scott

RE: [PATCH v3 2/2] cpufreq: qoriq: Don't look at clock implementation details

[Yuantian Tang]

UElORy4NCg0KUmVnYXJkcywNCll1YW50aWFuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS0NCj4gRnJvbTogU2NvdHQgV29vZCBbbWFpbHRvOm9zc0BidXNlcnJvci5uZXRdDQo+IFNlbnQ6
IFNhdHVyZGF5LCBKdWx5IDA5LCAyMDE2IDU6MDcgQU0NCj4gVG86IE1pY2hhZWwgVHVycXVldHRl
IDxtdHVycXVldHRlQGJheWxpYnJlLmNvbT47IFJ1c3NlbGwgS2luZw0KPiA8bGludXhAYXJtbGlu
dXgub3JnLnVrPjsgU3RlcGhlbiBCb3lkIDxzYm95ZEBjb2RlYXVyb3JhLm9yZz47IFZpcmVzaA0K
PiBLdW1hciA8dmlyZXNoLmt1bWFyQGxpbmFyby5vcmc+OyBSYWZhZWwgSi4gV3lzb2NraSA8cmp3
QHJqd3lzb2NraS5uZXQ+DQo+IENjOiBsaW51eC1jbGtAdmdlci5rZXJuZWwub3JnOyBsaW51eC1w
bUB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4cHBjLQ0KPiBkZXZAbGlzdHMub3psYWJzLm9yZzsgWXVh
bnRpYW4gVGFuZyA8eXVhbnRpYW4udGFuZ0BueHAuY29tPjsgWWFuZy1MZW8gTGkNCj4gPGxlb3lh
bmcubGlAbnhwLmNvbT47IFhpYW9mZW5nIFJlbiA8eGlhb2ZlbmcucmVuQG54cC5jb20+DQo+IFN1
YmplY3Q6IFJlOiBbUEFUQ0ggdjMgMi8yXSBjcHVmcmVxOiBxb3JpcTogRG9uJ3QgbG9vayBhdCBj
bG9jaw0KPiBpbXBsZW1lbnRhdGlvbiBkZXRhaWxzDQo+IA0KPiBPbiBUaHUsIDIwMTYtMDctMDcg
YXQgMTk6MjYgLTA3MDAsIE1pY2hhZWwgVHVycXVldHRlIHdyb3RlOg0KPiA+IFF1b3RpbmcgU2Nv
dHQgV29vZCAoMjAxNi0wNy0wNiAyMToxMzoyMykNCj4gPiA+DQo+ID4gPiBPbiBXZWQsIDIwMTYt
MDctMDYgYXQgMTg6MzAgLTA3MDAsIE1pY2hhZWwgVHVycXVldHRlIHdyb3RlOg0KPiA+ID4gPg0K
PiA+ID4gPiBRdW90aW5nIFNjb3R0IFdvb2QgKDIwMTYtMDYtMTUgMjM6MjE6MjUpDQo+ID4gPiA+
ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IC1zdGF0aWMgc3RydWN0IGRldmljZV9ub2RlICpjcHVf
dG9fY2xrX25vZGUoaW50IGNwdSkNCj4gPiA+ID4gPiArc3RhdGljIHN0cnVjdCBjbGsgKmNwdV90
b19jbGsoaW50IGNwdSkNCj4gPiA+ID4gPiDCoHsNCj4gPiA+ID4gPiAtwqDCoMKgwqDCoMKgwqBz
dHJ1Y3QgZGV2aWNlX25vZGUgKm5wLCAqY2xrX25wOw0KPiA+ID4gPiA+ICvCoMKgwqDCoMKgwqDC
oHN0cnVjdCBkZXZpY2Vfbm9kZSAqbnA7DQo+ID4gPiA+ID4gK8KgwqDCoMKgwqDCoMKgc3RydWN0
IGNsayAqY2xrOw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gwqDCoMKgwqDCoMKgwqDCoGlmICghY3B1
X3ByZXNlbnQoY3B1KSkNCj4gPiA+ID4gPiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oHJldHVybiBOVUxMOw0KPiA+ID4gPiA+IEBAIC0xMTIsMzcgKzgwLDI4IEBAIHN0YXRpYyBzdHJ1
Y3QgZGV2aWNlX25vZGUNCj4gPiA+ID4gPiAqY3B1X3RvX2Nsa19ub2RlKGludA0KPiA+ID4gPiA+
IGNwdSkNCj4gPiA+ID4gPiDCoMKgwqDCoMKgwqDCoMKgaWYgKCFucCkNCj4gPiA+ID4gPiDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoHJldHVybiBOVUxMOw0KPiA+ID4gPiA+DQo+ID4g
PiA+ID4gLcKgwqDCoMKgwqDCoMKgY2xrX25wID0gb2ZfcGFyc2VfcGhhbmRsZShucCwgImNsb2Nr
cyIsIDApOw0KPiA+ID4gPiA+IC3CoMKgwqDCoMKgwqDCoGlmICghY2xrX25wKQ0KPiA+ID4gPiA+
IC3CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqByZXR1cm4gTlVMTDsNCj4gPiA+ID4gPiAt
DQo+ID4gPiA+ID4gK8KgwqDCoMKgwqDCoMKgY2xrID0gb2ZfY2xrX2dldChucCwgMCk7DQo+ID4g
PiA+IFdoeSBub3QgdXNlIGRldm1fY2xrX2dldCBoZXJlPw0KPiA+ID4gZGV2bV9jbGtfZ2V0KCkg
aXMgYSB3cmFwcGVyIGFyb3VuZCBjbGtfZ2V0KCkgd2hpY2ggaXMgbm90IHRoZSBzYW1lDQo+ID4g
PiBhcyBvZl9jbGtfZ2V0KCkuIMKgV2hhdCBkZXZpY2Ugd291bGQgeW91IHBhc3MgdG8gZGV2bV9j
bGtfZ2V0KCksIGFuZA0KPiA+ID4gd2hhdCBuYW1lIHdvdWxkIHlvdSBwYXNzPw0KPiA+IEknbSBm
dXp6eSBvbiB3aGV0aGVyIG9yIG5vdCB5b3UgZ2V0IGEgc3RydWN0IGRldmljZSBmcm9tIGEgY3B1
ZnJlcQ0KPiA+IGRyaXZlci4gSWYgc28sIHRoZW4gdGhhdCB3b3VsZCBiZSB0aGUgb25lIHRvIHVz
ZS4gSSB3b3VsZCBob3BlIHRoYXQNCj4gPiBjcHVmcmVxIGRyaXZlcnMgbW9kZWwgY3B1cyBhcyBk
ZXZpY2VzLCBidXQgSSdtIHJlYWxseSBub3Qgc3VyZSB3aXRob3V0DQo+ID4gbG9va2luZyBpbnRv
IHRoZSBjb2RlLg0KPiANCj4gSXQncyBub3QgdGhlIGNwdWZyZXEgY29kZSB0aGF0IHByb3ZpZGVz
IGl0LCBidXQgZ2V0X2NwdV9kZXZpY2UoKSBjb3VsZCBiZQ0KPiB1c2VkLg0KPiANCj4gRG8geW91
IGhhdmUgYW55IGNvbW1lbnRzIG9uIHRoZSBmaXJzdCBwYXRjaCBvZiB0aGlzIHNldD8NCj4gDQo+
IC1TY290dA0KDQo=

RE: [PATCH v3 2/2] cpufreq: qoriq: Don't look at clock implementation details

[Yuantian Tang]

PING.

Regards,
Yuantian

> -----Original Message-----
> From: Scott Wood [mailto:oss@buserror.net]
> Sent: Saturday, July 09, 2016 5:07 AM
> To: Michael Turquette <mturquette@baylibre.com>; Russell King
> <linux@armlinux.org.uk>; Stephen Boyd <sboyd@codeaurora.org>; Viresh
> Kumar <viresh.kumar@linaro.org>; Rafael J. Wysocki <rjw@rjwysocki.net>
> Cc: linux-clk@vger.kernel.org; linux-pm@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org; Yuantian Tang <yuantian.tang@nxp.com>; Yang-Leo Li
> <leoyang.li@nxp.com>; Xiaofeng Ren <xiaofeng.ren@nxp.com>
> Subject: Re: [PATCH v3 2/2] cpufreq: qoriq: Don't look at clock
> implementation details
> 
> On Thu, 2016-07-07 at 19:26 -0700, Michael Turquette wrote:
> > Quoting Scott Wood (2016-07-06 21:13:23)
> > >
> > > On Wed, 2016-07-06 at 18:30 -0700, Michael Turquette wrote:
> > > >
> > > > Quoting Scott Wood (2016-06-15 23:21:25)
> > > > >
> > > > >
> > > > > -static struct device_node *cpu_to_clk_node(int cpu)
> > > > > +static struct clk *cpu_to_clk(int cpu)
> > > > >  {
> > > > > -       struct device_node *np, *clk_np;
> > > > > +       struct device_node *np;
> > > > > +       struct clk *clk;
> > > > >
> > > > >         if (!cpu_present(cpu))
> > > > >                 return NULL;
> > > > > @@ -112,37 +80,28 @@ static struct device_node
> > > > > *cpu_to_clk_node(int
> > > > > cpu)
> > > > >         if (!np)
> > > > >                 return NULL;
> > > > >
> > > > > -       clk_np = of_parse_phandle(np, "clocks", 0);
> > > > > -       if (!clk_np)
> > > > > -               return NULL;
> > > > > -
> > > > > +       clk = of_clk_get(np, 0);
> > > > Why not use devm_clk_get here?
> > > devm_clk_get() is a wrapper around clk_get() which is not the same
> > > as of_clk_get().  What device would you pass to devm_clk_get(), and
> > > what name would you pass?
> > I'm fuzzy on whether or not you get a struct device from a cpufreq
> > driver. If so, then that would be the one to use. I would hope that
> > cpufreq drivers model cpus as devices, but I'm really not sure without
> > looking into the code.
> 
> It's not the cpufreq code that provides it, but get_cpu_device() could be
> used.
> 
> Do you have any comments on the first patch of this set?
> 
> -Scott

Re: [PATCH v3 2/2] cpufreq: qoriq: Don't look at clock implementation details

[Leo Li]

On Tue, Jul 19, 2016 at 10:02 PM, Yuantian Tang <yuantian.tang@nxp.com> wrote:
>
> PING.
>
> Regards,
> Yuantian
>
> > -----Original Message-----
> > From: Scott Wood [mailto:oss@buserror.net]
> > Sent: Saturday, July 09, 2016 5:07 AM
> > To: Michael Turquette <mturquette@baylibre.com>; Russell King
> > <linux@armlinux.org.uk>; Stephen Boyd <sboyd@codeaurora.org>; Viresh
> > Kumar <viresh.kumar@linaro.org>; Rafael J. Wysocki <rjw@rjwysocki.net>
> > Cc: linux-clk@vger.kernel.org; linux-pm@vger.kernel.org; linuxppc-
> > dev@lists.ozlabs.org; Yuantian Tang <yuantian.tang@nxp.com>; Yang-Leo Li
> > <leoyang.li@nxp.com>; Xiaofeng Ren <xiaofeng.ren@nxp.com>
> > Subject: Re: [PATCH v3 2/2] cpufreq: qoriq: Don't look at clock
> > implementation details
> >
> > On Thu, 2016-07-07 at 19:26 -0700, Michael Turquette wrote:
> > > Quoting Scott Wood (2016-07-06 21:13:23)
> > > >
> > > > On Wed, 2016-07-06 at 18:30 -0700, Michael Turquette wrote:
> > > > >
> > > > > Quoting Scott Wood (2016-06-15 23:21:25)
> > > > > >
> > > > > >
> > > > > > -static struct device_node *cpu_to_clk_node(int cpu)
> > > > > > +static struct clk *cpu_to_clk(int cpu)
> > > > > >  {
> > > > > > -       struct device_node *np, *clk_np;
> > > > > > +       struct device_node *np;
> > > > > > +       struct clk *clk;
> > > > > >
> > > > > >         if (!cpu_present(cpu))
> > > > > >                 return NULL;
> > > > > > @@ -112,37 +80,28 @@ static struct device_node
> > > > > > *cpu_to_clk_node(int
> > > > > > cpu)
> > > > > >         if (!np)
> > > > > >                 return NULL;
> > > > > >
> > > > > > -       clk_np = of_parse_phandle(np, "clocks", 0);
> > > > > > -       if (!clk_np)
> > > > > > -               return NULL;
> > > > > > -
> > > > > > +       clk = of_clk_get(np, 0);
> > > > > Why not use devm_clk_get here?
> > > > devm_clk_get() is a wrapper around clk_get() which is not the same
> > > > as of_clk_get().  What device would you pass to devm_clk_get(), and
> > > > what name would you pass?
> > > I'm fuzzy on whether or not you get a struct device from a cpufreq
> > > driver. If so, then that would be the one to use. I would hope that
> > > cpufreq drivers model cpus as devices, but I'm really not sure without
> > > looking into the code.
> >
> > It's not the cpufreq code that provides it, but get_cpu_device() could be
> > used.
> >
> > Do you have any comments on the first patch of this set?


Any action on this patch?  This patch is still a dependency for
cpufreq to work on all QorIQ platforms.

Regards,
Leo

RE: [PATCH v3 2/2] cpufreq: qoriq: Don't look at clock implementation details

[Y.T. Tang]

[-- Attachment #1: Type: text/plain, Size: 3593 bytes --]

> -----Original Message-----
> From: Leo Li [mailto:pku.leo@gmail.com]
> Sent: Friday, February 03, 2017 2:12 AM
> To: Y.T. Tang <yuantian.tang@nxp.com>
> Cc: Scott Wood <oss@buserror.net>; Michael Turquette
> <mturquette@baylibre.com>; Russell King <linux@armlinux.org.uk>;
> Stephen Boyd <sboyd@codeaurora.org>; Viresh Kumar
> <viresh.kumar@linaro.org>; Rafael J. Wysocki <rjw@rjwysocki.net>; linux-
> clk@vger.kernel.org; linux-pm@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org; Leo Li <leoyang.li@nxp.com>; X.F. Ren
> <xiaofeng.ren@nxp.com>
> Subject: Re: [PATCH v3 2/2] cpufreq: qoriq: Don't look at clock
> implementation details
> 
> On Tue, Jul 19, 2016 at 10:02 PM, Yuantian Tang <yuantian.tang@nxp.com>
> wrote:
> >
> > PING.
> >
> > Regards,
> > Yuantian
> >
> > > -----Original Message-----
> > > From: Scott Wood [mailto:oss@buserror.net]
> > > Sent: Saturday, July 09, 2016 5:07 AM
> > > To: Michael Turquette <mturquette@baylibre.com>; Russell King
> > > <linux@armlinux.org.uk>; Stephen Boyd <sboyd@codeaurora.org>;
> Viresh
> > > Kumar <viresh.kumar@linaro.org>; Rafael J. Wysocki
> > > <rjw@rjwysocki.net>
> > > Cc: linux-clk@vger.kernel.org; linux-pm@vger.kernel.org; linuxppc-
> > > dev@lists.ozlabs.org; Yuantian Tang <yuantian.tang@nxp.com>;
> > > Yang-Leo Li <leoyang.li@nxp.com>; Xiaofeng Ren
> > > <xiaofeng.ren@nxp.com>
> > > Subject: Re: [PATCH v3 2/2] cpufreq: qoriq: Don't look at clock
> > > implementation details
> > >
> > > On Thu, 2016-07-07 at 19:26 -0700, Michael Turquette wrote:
> > > > Quoting Scott Wood (2016-07-06 21:13:23)
> > > > >
> > > > > On Wed, 2016-07-06 at 18:30 -0700, Michael Turquette wrote:
> > > > > >
> > > > > > Quoting Scott Wood (2016-06-15 23:21:25)
> > > > > > >
> > > > > > >
> > > > > > > -static struct device_node *cpu_to_clk_node(int cpu)
> > > > > > > +static struct clk *cpu_to_clk(int cpu)
> > > > > > >  {
> > > > > > > -       struct device_node *np, *clk_np;
> > > > > > > +       struct device_node *np;
> > > > > > > +       struct clk *clk;
> > > > > > >
> > > > > > >         if (!cpu_present(cpu))
> > > > > > >                 return NULL; @@ -112,37 +80,28 @@ static
> > > > > > > struct device_node *cpu_to_clk_node(int
> > > > > > > cpu)
> > > > > > >         if (!np)
> > > > > > >                 return NULL;
> > > > > > >
> > > > > > > -       clk_np = of_parse_phandle(np, "clocks", 0);
> > > > > > > -       if (!clk_np)
> > > > > > > -               return NULL;
> > > > > > > -
> > > > > > > +       clk = of_clk_get(np, 0);
> > > > > > Why not use devm_clk_get here?
> > > > > devm_clk_get() is a wrapper around clk_get() which is not the
> > > > > same as of_clk_get().  What device would you pass to
> > > > > devm_clk_get(), and what name would you pass?
> > > > I'm fuzzy on whether or not you get a struct device from a cpufreq
> > > > driver. If so, then that would be the one to use. I would hope
> > > > that cpufreq drivers model cpus as devices, but I'm really not
> > > > sure without looking into the code.
> > >
> > > It's not the cpufreq code that provides it, but get_cpu_device()
> > > could be used.
> > >
> > > Do you have any comments on the first patch of this set?
> 
> 
> Any action on this patch?  This patch is still a dependency for cpufreq to work
> on all QorIQ platforms.
> 
This patch can be accepted on condition that the attached patch is accepted.
But unfortunately, the attached patch has been sent for a really long time and no feedback.

Regards,
Yuantian

> Regards,
> Leo

[-- Attachment #2: Type: message/rfc822, Size: 6216 bytes --]

From: Scott Wood <oss@buserror.net>
To: Russell King <linux@armlinux.org.uk>, Michael Turquette <mturquette@baylibre.com>, Stephen Boyd <sboyd@codeaurora.org>, Viresh Kumar <viresh.kumar@linaro.org>, "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: "linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>, "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>, "linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>, "Y.T. Tang" <yuantian.tang@nxp.com>, Leo Li <leoyang.li@nxp.com>, "X.F. Ren" <xiaofeng.ren@nxp.com>, Scott Wood <scottwood@freescale.com>
Subject: [RESEND PATCH 1/2] clk: Add consumer APIs for discovering possible parent clocks
Date: Sun, 12 Jun 2016 03:16:25 +0000
Message-ID: <1465701386-6220-1-git-send-email-oss@buserror.net>

From: Scott Wood <scottwood@freescale.com>

Commit fc4a05d4b0eb ("clk: Remove unused provider APIs") removed
__clk_get_num_parents() and clk_hw_get_parent_by_index(), leaving only
true provider API versions that operate on struct clk_hw.

qoriq-cpufreq needs these functions in order to determine the options
it has for calling clk_set_parent() and thus populate the cpufreq
table, so revive them as legitimate consumer APIs.

Signed-off-by: Scott Wood <scottwood@freescale.com>
---
Previously sent as http://patchwork.ozlabs.org/patch/519803/

Russell, could you please either ACK this or comment, as CLK API
maintainer?

 drivers/clk/clk.c   | 19 +++++++++++++++++++
 include/linux/clk.h | 31 +++++++++++++++++++++++++++++++
 2 files changed, 50 insertions(+)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index d584004..d61a3fe 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -290,6 +290,12 @@ struct clk_hw *__clk_get_hw(struct clk *clk)
 }
 EXPORT_SYMBOL_GPL(__clk_get_hw);

+unsigned int clk_get_num_parents(struct clk *clk)
+{
+       return !clk ? 0 : clk->core->num_parents;
+}
+EXPORT_SYMBOL_GPL(clk_get_num_parents);
+
 unsigned int clk_hw_get_num_parents(const struct clk_hw *hw)
 {
        return hw->core->num_parents;
@@ -358,6 +364,19 @@ static struct clk_core *clk_core_get_parent_by_index(struct clk_core *core,
        return core->parents[index];
 }

+struct clk *clk_get_parent_by_index(struct clk *clk, unsigned int index)
+{
+       struct clk_core *parent;
+
+       if (!clk)
+               return NULL;
+
+       parent = clk_core_get_parent_by_index(clk->core, index);
+
+       return !parent ? NULL : parent->hw->clk;
+}
+EXPORT_SYMBOL_GPL(clk_get_parent_by_index);
+
 struct clk_hw *
 clk_hw_get_parent_by_index(const struct clk_hw *hw, unsigned int index)
 {
diff --git a/include/linux/clk.h b/include/linux/clk.h
index 0df4a51..937de0e 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -392,6 +392,26 @@ int clk_set_parent(struct clk *clk, struct clk *parent);
 struct clk *clk_get_parent(struct clk *clk);

 /**
+ * clk_get_parent_by_index - get a possible parent clock by index
+ * @clk: clock source
+ * @index: index into the array of possible parents of this clock
+ *
+ * Returns struct clk corresponding to the requested possible
+ * parent clock source, or NULL.
+ */
+struct clk *clk_get_parent_by_index(struct clk *clk,
+                                   unsigned int index);
+
+/**
+ * clk_get_num_parents - get number of possible parents
+ * @clk: clock source
+ *
+ * Returns the number of possible parents of this clock,
+ * which can then be enumerated using clk_get_parent_by_index().
+ */
+unsigned int clk_get_num_parents(struct clk *clk);
+
+/**
  * clk_get_sys - get a clock based upon the device name
  * @dev_id: device name
  * @con_id: connection ID
@@ -461,6 +481,17 @@ static inline struct clk *clk_get_parent(struct clk *clk)
        return NULL;
 }

+struct clk *clk_get_parent_by_index(struct clk *clk,
+                                   unsigned int index)
+{
+       return NULL;
+}
+
+unsigned int clk_get_num_parents(struct clk *clk)
+{
+       return 0;
+}
+
 #endif

 /* clk_prepare_enable helps cases using clk_enable in non-atomic context. */
--
2.5.0