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

Subsystems: clk api, common clk framework, the rest

STALE3483d

19 messages, 6 authors, 2017-02-06 · open the first message on its own page

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

From: Scott Wood <oss@buserror.net>
Date: 2016-06-16 06:21:24

From: Scott Wood <redacted>

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 <redacted>
---
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

From: Scott Wood <oss@buserror.net>
Date: 2016-06-16 06:21:25

From: Scott Wood <redacted>

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 <redacted>
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

From: Yuantian Tang <hidden>
Date: 2016-06-29 05:50:26

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
[off-list ref]; Stephen Boyd [off-list ref];
Viresh Kumar [off-list ref]; Rafael J. Wysocki
[off-list ref]
Cc: linux-clk@vger.kernel.org; linux-pm@vger.kernel.org; linuxppc-
dev@lists.ozlabs.org; Yuantian Tang [off-list ref]; Yang-Leo Li
[off-list ref]; Xiaofeng Ren [off-list ref]; Scott Wood
[off-list ref]
Subject: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible
parent clocks
=20
From: Scott Wood <redacted>
=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

quoted hunk

them as legitimate consumer APIs.
=20
Signed-off-by: Scott Wood <redacted>
---
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=

quoted hunk

--- 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

quoted hunk

--- 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);

quoted hunk

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

From: Rafael J. Wysocki <hidden>
Date: 2016-06-30 01:46:56

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

From: Yuantian Tang <hidden>
Date: 2016-06-30 01:47:09

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

From: Rafael J. Wysocki <hidden>
Date: 2016-06-30 02:24:29

On Thursday, June 30, 2016 01:47:09 AM Yuantian Tang wrote:

quoted

-----Original Message-----
From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
Sent: Thursday, June 30, 2016 9:47 AM
To: Yuantian Tang <redacted>
Cc: Scott Wood <oss@buserror.net>; Russell King <linux@armlinux.org.uk>;
Michael Turquette [off-list ref]; Stephen Boyd
[off-list ref]; Viresh Kumar [off-list ref]; linux-
clk@vger.kernel.org; linux-pm@vger.kernel.org; linuxppc-
dev@lists.ozlabs.org; Yang-Leo Li [off-list ref]; Xiaofeng Ren
[off-list ref]; Scott Wood [off-list ref]
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:

quoted

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

From: Yuantian Tang <hidden>
Date: 2016-06-30 03:01:50

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

From: Scott Wood <hidden>
Date: 2016-06-30 05:46:42

On 06/29/2016 10:02 PM, Yuantian Tang wrote:=0A=

quoted

-----Original Message-----=0A=
From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]=0A=
Sent: Thursday, June 30, 2016 10:24 AM=0A=
To: Yuantian Tang <redacted>=0A=
Cc: Scott Wood <oss@buserror.net>; Russell King <linux@armlinux.org.uk>;=

=0A=

quoted

Michael Turquette [off-list ref]; Stephen Boyd=0A=
[off-list ref]; Viresh Kumar [off-list ref]; linux-=

=0A=

quoted

clk@vger.kernel.org; linux-pm@vger.kernel.org; linuxppc-=0A=
dev@lists.ozlabs.org; Yang-Leo Li [off-list ref]; Xiaofeng Ren=0A=
[off-list ref]; Scott Wood [off-list ref]=0A=
Subject: Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering possi=

ble=0A=

quoted

parent clocks=0A=
=0A=
On Thursday, June 30, 2016 01:47:09 AM Yuantian Tang wrote:=0A=

quoted

-----Original Message-----=0A=
From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]=0A=
Sent: Thursday, June 30, 2016 9:47 AM=0A=
To: Yuantian Tang <redacted>=0A=
Cc: Scott Wood <oss@buserror.net>; Russell King=0A=
[off-list ref]; Michael Turquette=0A=
[off-list ref]; Stephen Boyd [off-list ref];=0A=
Viresh Kumar [off-list ref]; linux- clk@vger.kernel.org;=0A=
linux-pm@vger.kernel.org; linuxppc- dev@lists.ozlabs.org; Yang-Leo=0A=
Li [off-list ref]; Xiaofeng Ren [off-list ref]; Scott=0A=
Wood [off-list ref]=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=

quoted

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=

quoted

=0A=
If not, it will have to be deferred until the [1/2] is merged and then a=

pplied=0A=

quoted

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

From: Rafael J. Wysocki <hidden>
Date: 2016-06-30 13:29:06

On Thursday, June 30, 2016 05:46:42 AM Scott Wood wrote:

On 06/29/2016 10:02 PM, Yuantian Tang wrote:

quoted

-----Original Message-----
From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
Sent: Thursday, June 30, 2016 10:24 AM
To: Yuantian Tang <redacted>
Cc: Scott Wood <oss@buserror.net>; Russell King <linux@armlinux.org.uk>;
Michael Turquette [off-list ref]; Stephen Boyd
[off-list ref]; Viresh Kumar [off-list ref]; linux-
clk@vger.kernel.org; linux-pm@vger.kernel.org; linuxppc-
dev@lists.ozlabs.org; Yang-Leo Li [off-list ref]; Xiaofeng Ren
[off-list ref]; Scott Wood [off-list ref]
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:

quoted

-----Original Message-----
From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
Sent: Thursday, June 30, 2016 9:47 AM
To: Yuantian Tang <redacted>
Cc: Scott Wood <oss@buserror.net>; Russell King
[off-list ref]; Michael Turquette
[off-list ref]; Stephen Boyd [off-list ref];
Viresh Kumar [off-list ref]; linux- clk@vger.kernel.org;
linux-pm@vger.kernel.org; linuxppc- dev@lists.ozlabs.org; Yang-Leo
Li [off-list ref]; Xiaofeng Ren [off-list ref]; Scott
Wood [off-list ref]
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:

quoted

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

From: Scott Wood <oss@buserror.net>
Date: 2016-07-01 06:55:46

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:

quoted

On 06/29/2016 10:02 PM, Yuantian Tang wrote:

quoted

-----Original Message-----
From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
Sent: Thursday, June 30, 2016 10:24 AM
To: Yuantian Tang <redacted>
Cc: Scott Wood <oss@buserror.net>; Russell King <linux@armlinux.org.uk

quoted

Michael Turquette [off-list ref]; Stephen Boyd
[off-list ref]; Viresh Kumar [off-list ref]; linux-
clk@vger.kernel.org; linux-pm@vger.kernel.org; linuxppc-
dev@lists.ozlabs.org; Yang-Leo Li [off-list ref]; Xiaofeng Ren
[off-list ref]; Scott Wood [off-list ref]
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:

quoted

-----Original Message-----
From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
Sent: Thursday, June 30, 2016 9:47 AM
To: Yuantian Tang <redacted>
Cc: Scott Wood <oss@buserror.net>; Russell King
[off-list ref]; Michael Turquette
[off-list ref]; Stephen Boyd [off-list ref];
Viresh Kumar [off-list ref]; linux- clk@vger.kernel.org
;
linux-pm@vger.kernel.org; linuxppc- dev@lists.ozlabs.org; Yang-Leo
Li [off-list ref]; Xiaofeng Ren [off-list ref];
Scott
Wood [off-list ref]
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:

quoted

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

From: Rafael J. Wysocki <hidden>
Date: 2016-07-01 20:53:44

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:

quoted

On Thursday, June 30, 2016 05:46:42 AM Scott Wood wrote:

quoted

On 06/29/2016 10:02 PM, Yuantian Tang wrote:

quoted

-----Original Message-----
From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
Sent: Thursday, June 30, 2016 10:24 AM
To: Yuantian Tang <redacted>
Cc: Scott Wood <oss@buserror.net>; Russell King <linux@armlinux.org.uk

quoted

Michael Turquette [off-list ref]; Stephen Boyd
[off-list ref]; Viresh Kumar [off-list ref]; linux-
clk@vger.kernel.org; linux-pm@vger.kernel.org; linuxppc-
dev@lists.ozlabs.org; Yang-Leo Li [off-list ref]; Xiaofeng Ren
[off-list ref]; Scott Wood [off-list ref]
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:

quoted

-----Original Message-----
From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
Sent: Thursday, June 30, 2016 9:47 AM
To: Yuantian Tang <redacted>
Cc: Scott Wood <oss@buserror.net>; Russell King
[off-list ref]; Michael Turquette
[off-list ref]; Stephen Boyd [off-list ref];
Viresh Kumar [off-list ref]; linux- clk@vger.kernel.org
;
linux-pm@vger.kernel.org; linuxppc- dev@lists.ozlabs.org; Yang-Leo
Li [off-list ref]; Xiaofeng Ren [off-list ref];
Scott
Wood [off-list ref]
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:

quoted

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

From: Scott Wood <oss@buserror.net>
Date: 2016-07-01 20:57:22

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:

quoted

On Thu, 2016-06-30 at 15:29 +0200, Rafael J. Wysocki wrote:

quoted

On Thursday, June 30, 2016 05:46:42 AM Scott Wood wrote:

quoted


On 06/29/2016 10:02 PM, Yuantian Tang wrote:

quoted


-----Original Message-----
From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
Sent: Thursday, June 30, 2016 10:24 AM
To: Yuantian Tang <redacted>
Cc: Scott Wood <oss@buserror.net>; Russell King <linux@armlinux.or
g.uk

quoted

Michael Turquette [off-list ref]; Stephen Boyd
[off-list ref]; Viresh Kumar [off-list ref];
linux-
clk@vger.kernel.org; linux-pm@vger.kernel.org; linuxppc-
dev@lists.ozlabs.org; Yang-Leo Li [off-list ref]; Xiaofeng
Ren
[off-list ref]; Scott Wood [off-list ref]
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:

quoted


-----Original Message-----
From: Rafael J. Wysocki [mailto:rjw@rjwysocki.net]
Sent: Thursday, June 30, 2016 9:47 AM
To: Yuantian Tang <redacted>
Cc: Scott Wood <oss@buserror.net>; Russell King
[off-list ref]; Michael Turquette
[off-list ref]; Stephen Boyd [off-list ref]
;
Viresh Kumar [off-list ref]; linux- clk@vger.kernel
.org
;
linux-pm@vger.kernel.org; linuxppc- dev@lists.ozlabs.org;
Yang-Leo
Li [off-list ref]; Xiaofeng Ren [off-list ref];
Scott
Wood [off-list ref]
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:

quoted


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

From: Michael Turquette <mturquette@baylibre.com>
Date: 2016-07-07 01:30:17

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;
 =

quoted hunk

        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?

quoted hunk

@@ -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.

quoted hunk

@@ -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

From: Scott Wood <oss@buserror.net>
Date: 2016-07-07 04:13:23

On Wed, 2016-07-06 at 18:30 -0700, Michael Turquette wrote:

Quoting Scott Wood (2016-06-15 23:21:25)

quoted

-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?

quoted

@@ -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.

quoted

@@ -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

From: Michael Turquette <mturquette@baylibre.com>
Date: 2016-07-08 02:26:16

Quoting Scott Wood (2016-07-06 21:13:23)

On Wed, 2016-07-06 at 18:30 -0700, Michael Turquette wrote:

quoted

Quoting Scott Wood (2016-06-15 23:21:25)

quoted

-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;

quoted

+=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;

quoted

@@ -112,37 +80,28 @@ static struct device_node *cpu_to_clk_node(int c=

pu)

quoted

=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;

quoted

=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);

quoted

-=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;

quoted

-
+=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

quoted
quoted
=

quoted

@@ -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;

quoted

=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);

quoted

-=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__);

quoted

-=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;

quoted

-=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);

quoted

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.
=

quoted

@@ -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;

quoted

=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)];

quoted

-=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;

quoted

-
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0for (i =3D 0; i < cou=

nt; i++) {

quoted

-=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);

quoted

+=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);

quoted

=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;

quoted

=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);

quoted

-=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/*

quoted

-=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

quoted

-=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.

quoted

-=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*/

quoted

-=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)))

quoted

-=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;

quoted

-=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

quoted

-=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;

quoted

+=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;

quoted

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.
=

quoted

 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

From: Scott Wood <oss@buserror.net>
Date: 2016-07-08 21:06:54

On Thu, 2016-07-07 at 19:26 -0700, Michael Turquette wrote:

Quoting Scott Wood (2016-07-06 21:13:23)

quoted

On Wed, 2016-07-06 at 18:30 -0700, Michael Turquette wrote:

quoted

Quoting Scott Wood (2016-06-15 23:21:25)

quoted


-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

From: Yuantian Tang <hidden>
Date: 2016-07-20 03:02:49

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

From: Leo Li <hidden>
Date: 2017-02-02 18:11:36

On Tue, Jul 19, 2016 at 10:02 PM, Yuantian Tang [off-list ref] wrote:

PING.

Regards,
Yuantian

quoted

-----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
[off-list ref]; Stephen Boyd [off-list ref]; Viresh
Kumar [off-list ref]; Rafael J. Wysocki [off-list ref]
Cc: linux-clk@vger.kernel.org; linux-pm@vger.kernel.org; linuxppc-
dev@lists.ozlabs.org; Yuantian Tang [off-list ref]; Yang-Leo Li
[off-list ref]; Xiaofeng Ren [off-list ref]
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:

quoted

Quoting Scott Wood (2016-07-06 21:13:23)

quoted

On Wed, 2016-07-06 at 18:30 -0700, Michael Turquette wrote:

quoted

Quoting Scott Wood (2016-06-15 23:21:25)

quoted


-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

From: Y.T. Tang <hidden>
Date: 2017-02-06 06:12:40

-----Original Message-----
From: Leo Li [mailto:pku.leo@gmail.com]
Sent: Friday, February 03, 2017 2:12 AM
To: Y.T. Tang <redacted>
Cc: Scott Wood <oss@buserror.net>; Michael Turquette
[off-list ref]; Russell King [off-list ref];
Stephen Boyd [off-list ref]; Viresh Kumar
[off-list ref]; Rafael J. Wysocki [off-list ref]; linux-
clk@vger.kernel.org; linux-pm@vger.kernel.org; linuxppc-
dev@lists.ozlabs.org; Leo Li [off-list ref]; X.F. Ren
[off-list ref]
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 [off-list ref]
wrote:

quoted

PING.

Regards,
Yuantian

quoted

-----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
[off-list ref]; Stephen Boyd [off-list ref];

Viresh

quoted

Kumar [off-list ref]; Rafael J. Wysocki
[off-list ref]
Cc: linux-clk@vger.kernel.org; linux-pm@vger.kernel.org; linuxppc-
dev@lists.ozlabs.org; Yuantian Tang [off-list ref];
Yang-Leo Li [off-list ref]; Xiaofeng Ren
[off-list ref]
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:

quoted

Quoting Scott Wood (2016-07-06 21:13:23)

quoted

On Wed, 2016-07-06 at 18:30 -0700, Michael Turquette wrote:

quoted

Quoting Scott Wood (2016-06-15 23:21:25)

quoted


-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

`h`	back out one level
`j`	next message in thread
`k`	previous message in thread
`l`	drill in
`Esc`	close help / fold thread tree
`?`	toggle this help