* [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks @ 2016-06-16 6:21 Scott Wood 2016-06-16 6:21 ` [PATCH v3 2/2] cpufreq: qoriq: Don't look at clock implementation details Scott Wood 2016-06-29 5:50 ` [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks Yuantian Tang 0 siblings, 2 replies; 19+ messages in thread From: Scott Wood @ 2016-06-16 6:21 UTC (permalink / raw) To: Russell King, Michael Turquette, Stephen Boyd, Viresh Kumar, Rafael J. Wysocki Cc: linux-clk, linux-pm, linuxppc-dev, yuantian.tang, leoyang.li, xiaofeng.ren, 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 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* [PATCH v3 2/2] cpufreq: qoriq: Don't look at clock implementation details 2016-06-16 6:21 [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks Scott Wood @ 2016-06-16 6:21 ` Scott Wood 2016-07-07 1:30 ` Michael Turquette 2016-06-29 5:50 ` [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks Yuantian Tang 1 sibling, 1 reply; 19+ messages in thread From: Scott Wood @ 2016-06-16 6:21 UTC (permalink / raw) To: Russell King, Michael Turquette, Stephen Boyd, Viresh Kumar, Rafael J. Wysocki Cc: linux-clk, linux-pm, linuxppc-dev, yuantian.tang, leoyang.li, xiaofeng.ren, 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 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [PATCH v3 2/2] cpufreq: qoriq: Don't look at clock implementation details 2016-06-16 6:21 ` [PATCH v3 2/2] cpufreq: qoriq: Don't look at clock implementation details Scott Wood @ 2016-07-07 1:30 ` Michael Turquette 2016-07-07 4:13 ` Scott Wood 0 siblings, 1 reply; 19+ messages in thread From: Michael Turquette @ 2016-07-07 1:30 UTC (permalink / raw) To: Scott Wood, Russell King, Stephen Boyd, Viresh Kumar, Rafael J. Wysocki Cc: linux-clk, linux-pm, linuxppc-dev, yuantian.tang, leoyang.li, xiaofeng.ren, Scott Wood 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v3 2/2] cpufreq: qoriq: Don't look at clock implementation details 2016-07-07 1:30 ` Michael Turquette @ 2016-07-07 4:13 ` Scott Wood 2016-07-08 2:26 ` Michael Turquette 0 siblings, 1 reply; 19+ messages in thread From: Scott Wood @ 2016-07-07 4:13 UTC (permalink / raw) To: Michael Turquette, Russell King, Stephen Boyd, Viresh Kumar, Rafael J. Wysocki Cc: linux-clk, linux-pm, linuxppc-dev, yuantian.tang, leoyang.li, xiaofeng.ren 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v3 2/2] cpufreq: qoriq: Don't look at clock implementation details 2016-07-07 4:13 ` Scott Wood @ 2016-07-08 2:26 ` Michael Turquette 2016-07-08 21:06 ` Scott Wood 0 siblings, 1 reply; 19+ messages in thread From: Michael Turquette @ 2016-07-08 2:26 UTC (permalink / raw) To: Scott Wood, Russell King, Stephen Boyd, Viresh Kumar, Rafael J. Wysocki Cc: linux-clk, linux-pm, linuxppc-dev, yuantian.tang, leoyang.li, xiaofeng.ren 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 > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v3 2/2] cpufreq: qoriq: Don't look at clock implementation details 2016-07-08 2:26 ` Michael Turquette @ 2016-07-08 21:06 ` Scott Wood 2016-07-20 3:02 ` Yuantian Tang 0 siblings, 1 reply; 19+ messages in thread From: Scott Wood @ 2016-07-08 21:06 UTC (permalink / raw) To: Michael Turquette, Russell King, Stephen Boyd, Viresh Kumar, Rafael J. Wysocki Cc: linux-clk, linux-pm, linuxppc-dev, yuantian.tang, leoyang.li, xiaofeng.ren 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: [PATCH v3 2/2] cpufreq: qoriq: Don't look at clock implementation details 2016-07-08 21:06 ` Scott Wood @ 2016-07-20 3:02 ` Yuantian Tang 2017-02-02 18:11 ` Leo Li 0 siblings, 1 reply; 19+ messages in thread From: Yuantian Tang @ 2016-07-20 3:02 UTC (permalink / raw) To: Scott Wood, Michael Turquette, Russell King, Stephen Boyd, Viresh Kumar, Rafael J. Wysocki Cc: linux-clk@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Yang-Leo Li, Xiaofeng Ren 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v3 2/2] cpufreq: qoriq: Don't look at clock implementation details 2016-07-20 3:02 ` Yuantian Tang @ 2017-02-02 18:11 ` Leo Li 2017-02-06 6:12 ` Y.T. Tang 0 siblings, 1 reply; 19+ messages in thread From: Leo Li @ 2017-02-02 18:11 UTC (permalink / raw) To: Yuantian Tang Cc: Scott Wood, Michael Turquette, Russell King, Stephen Boyd, Viresh Kumar, Rafael J. Wysocki, linux-clk@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Yang-Leo Li, Xiaofeng Ren 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: [PATCH v3 2/2] cpufreq: qoriq: Don't look at clock implementation details 2017-02-02 18:11 ` Leo Li @ 2017-02-06 6:12 ` Y.T. Tang 0 siblings, 0 replies; 19+ messages in thread From: Y.T. Tang @ 2017-02-06 6:12 UTC (permalink / raw) To: Leo Li Cc: Scott Wood, Michael Turquette, Russell King, Stephen Boyd, Viresh Kumar, Rafael J. Wysocki, linux-clk@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Leo Li, X.F. Ren [-- 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 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* RE: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks 2016-06-16 6:21 [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks Scott Wood 2016-06-16 6:21 ` [PATCH v3 2/2] cpufreq: qoriq: Don't look at clock implementation details Scott Wood @ 2016-06-29 5:50 ` Yuantian Tang 2016-06-30 1:46 ` Rafael J. Wysocki 1 sibling, 1 reply; 19+ messages in thread From: Yuantian Tang @ 2016-06-29 5:50 UTC (permalink / raw) To: Scott Wood, Russell King, Michael Turquette, Stephen Boyd, Viresh Kumar, Rafael J. Wysocki Cc: linux-clk@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Yang-Leo Li, Xiaofeng Ren, Scott Wood 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks 2016-06-29 5:50 ` [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks Yuantian Tang @ 2016-06-30 1:46 ` Rafael J. Wysocki 2016-06-30 1:47 ` Yuantian Tang 0 siblings, 1 reply; 19+ messages in thread From: Rafael J. Wysocki @ 2016-06-30 1:46 UTC (permalink / raw) To: Yuantian Tang Cc: Scott Wood, Russell King, Michael Turquette, Stephen Boyd, Viresh Kumar, linux-clk@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Yang-Leo Li, Xiaofeng Ren, Scott Wood 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks 2016-06-30 1:46 ` Rafael J. Wysocki @ 2016-06-30 1:47 ` Yuantian Tang 2016-06-30 2:24 ` Rafael J. Wysocki 0 siblings, 1 reply; 19+ messages in thread From: Yuantian Tang @ 2016-06-30 1:47 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Scott Wood, Russell King, Michael Turquette, Stephen Boyd, Viresh Kumar, linux-clk@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Yang-Leo Li, Xiaofeng Ren, Scott Wood > -----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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks 2016-06-30 1:47 ` Yuantian Tang @ 2016-06-30 2:24 ` Rafael J. Wysocki 2016-06-30 3:01 ` Yuantian Tang 0 siblings, 1 reply; 19+ messages in thread From: Rafael J. Wysocki @ 2016-06-30 2:24 UTC (permalink / raw) To: Yuantian Tang Cc: Scott Wood, Russell King, Michael Turquette, Stephen Boyd, Viresh Kumar, linux-clk@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Yang-Leo Li, Xiaofeng Ren, Scott Wood 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks 2016-06-30 2:24 ` Rafael J. Wysocki @ 2016-06-30 3:01 ` Yuantian Tang 2016-06-30 5:46 ` Scott Wood 0 siblings, 1 reply; 19+ messages in thread From: Yuantian Tang @ 2016-06-30 3:01 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Scott Wood, Russell King, Michael Turquette, Stephen Boyd, Viresh Kumar, linux-clk@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Yang-Leo Li, Xiaofeng Ren, Scott Wood > -----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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks 2016-06-30 3:01 ` Yuantian Tang @ 2016-06-30 5:46 ` Scott Wood 2016-06-30 13:29 ` Rafael J. Wysocki 0 siblings, 1 reply; 19+ messages in thread From: Scott Wood @ 2016-06-30 5:46 UTC (permalink / raw) To: Yuantian Tang, Rafael J. Wysocki Cc: Scott Wood, Russell King, Michael Turquette, Stephen Boyd, Viresh Kumar, linux-clk@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Yang-Leo Li, Xiaofeng Ren, 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks 2016-06-30 5:46 ` Scott Wood @ 2016-06-30 13:29 ` Rafael J. Wysocki 2016-07-01 6:55 ` Scott Wood 0 siblings, 1 reply; 19+ messages in thread From: Rafael J. Wysocki @ 2016-06-30 13:29 UTC (permalink / raw) To: Scott Wood Cc: Yuantian Tang, Scott Wood, Russell King, Michael Turquette, Stephen Boyd, Viresh Kumar, linux-clk@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Yang-Leo Li, Xiaofeng Ren, Scott Wood 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks 2016-06-30 13:29 ` Rafael J. Wysocki @ 2016-07-01 6:55 ` Scott Wood 2016-07-01 20:53 ` Rafael J. Wysocki 0 siblings, 1 reply; 19+ messages in thread From: Scott Wood @ 2016-07-01 6:55 UTC (permalink / raw) To: Rafael J. Wysocki, Scott Wood Cc: linux-pm@vger.kernel.org, Viresh Kumar, Michael Turquette, Stephen Boyd, Russell King, Yang-Leo Li, Yuantian Tang, Xiaofeng Ren, linuxppc-dev@lists.ozlabs.org, linux-clk@vger.kernel.org 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks 2016-07-01 6:55 ` Scott Wood @ 2016-07-01 20:53 ` Rafael J. Wysocki 2016-07-01 20:57 ` Scott Wood 0 siblings, 1 reply; 19+ messages in thread From: Rafael J. Wysocki @ 2016-07-01 20:53 UTC (permalink / raw) To: Scott Wood Cc: Scott Wood, Yuantian Tang, Russell King, Michael Turquette, Stephen Boyd, Viresh Kumar, linux-clk@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Yang-Leo Li, Xiaofeng Ren 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks 2016-07-01 20:53 ` Rafael J. Wysocki @ 2016-07-01 20:57 ` Scott Wood 0 siblings, 0 replies; 19+ messages in thread From: Scott Wood @ 2016-07-01 20:57 UTC (permalink / raw) To: Rafael J. Wysocki, Russell King, Michael Turquette, Stephen Boyd Cc: Scott Wood, Yuantian Tang, Viresh Kumar, linux-clk@vger.kernel.org, linux-pm@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Yang-Leo Li, Xiaofeng Ren 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2017-02-06 6:12 UTC | newest] Thread overview: 19+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-06-16 6:21 [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks Scott Wood 2016-06-16 6:21 ` [PATCH v3 2/2] cpufreq: qoriq: Don't look at clock implementation details Scott Wood 2016-07-07 1:30 ` Michael Turquette 2016-07-07 4:13 ` Scott Wood 2016-07-08 2:26 ` Michael Turquette 2016-07-08 21:06 ` Scott Wood 2016-07-20 3:02 ` Yuantian Tang 2017-02-02 18:11 ` Leo Li 2017-02-06 6:12 ` Y.T. Tang 2016-06-29 5:50 ` [PATCH v3 1/2] clk: Add consumer APIs for discovering possible parent clocks Yuantian Tang 2016-06-30 1:46 ` Rafael J. Wysocki 2016-06-30 1:47 ` Yuantian Tang 2016-06-30 2:24 ` Rafael J. Wysocki 2016-06-30 3:01 ` Yuantian Tang 2016-06-30 5:46 ` Scott Wood 2016-06-30 13:29 ` Rafael J. Wysocki 2016-07-01 6:55 ` Scott Wood 2016-07-01 20:53 ` Rafael J. Wysocki 2016-07-01 20:57 ` Scott Wood
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).