Re: AM335x OMAP2 common clock external fixed-clock registration
On Wed, Apr 15, 2015 at 12:47 PM, Michael Welling mwell...@ieee.org wrote:
On Wed, Apr 15, 2015 at 09:43:30PM +0300, Tero Kristo wrote:
On 04/15/2015 05:09 PM, Michael Welling wrote:
On Wed, Apr 15, 2015 at 09:34:48AM +0300, Tero Kristo wrote:
On 04/15/2015 12:17 AM, Michael Welling wrote:
Greetings,
I have developed an AM3354 based SoM and it uses an external SI5351 clock
generator to drive the clock inputs for an external duart and I2S audio
master clock. With the registration according to the documentation the
reference clock is not being detected and hence the clock generator is
not working as expect.
After trying many different things, I started to look around the mailing
lists to find information related to this issue.
I came acrossed post that has the exact same issue:
https://lkml.org/lkml/2013/2/18/468
Seeing as the patch did not land upstream, I am wondering if there is
a solution that I am not seeing.
I am willing to provide a patch given appropriate guidance.
Hi Michael,
The info on the email you referenced is kind of obsolete, TI SoCs
are calling of_clk_init() during boot now, and thus external clock
nodes should be registered fine also. Maybe you can provide the
actual DTS patch you are trying out so we can help better...? Are
See attached patch and console output.
I see a bug in your dt data.
snip
+ clocks {
+ ref27: ref27 {
+ #clock-cells = 0;
+ compatibale = fixed-clock;
This should be compatible, right? DT is annoying in that it doesn't
verify property names.
Ooops.
Now the clock appears in /sys/kernel/debug/clk:
root@som3517-som200:/sys/kernel/debug/clk# cat clk_summary
clock enable_cnt prepare_cntrate
accuracy phase
ref27002700
0 0
...
There is still an issue with the si5351.
I had to comment out the clk_put here for the frequency to show up:
http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1133
Ideas?
What is the most recent upstream commit that you are based on?
Regards,
Mike
+ clock-frequency = 2700;
+ };
+ };
-Tero
you seeing any boot time error / warning prints for your new clock?
With the debug messages on you see that the reference clock is not being
detected.
Whilest debugging I found that the of_clk_get is returning an error no
matter
which clock I pass it:
http://lxr.free-electrons.com/source/drivers/clk/clk-si5351.c#L1131
-Tero
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 08/35] clk: ti: fix ti_clk_get_reg_addr error handling
Quoting Tero Kristo (2015-02-25 11:04:18)
There is a case where NULL can be a valid return value for
ti_clk_get_reg_addr, specifically the case where both the provider index
and register offsets are zero. In this case, the current error checking
against a NULL pointer will fail. Thus, change the API to return a
ERR_PTR value in an error case, and change all the users of this API to
check against IS_ERR instead.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Michael Turquette mturque...@linaro.org
Looks good to me.
Regards,
Mike
---
drivers/clk/ti/apll.c |5 +++--
drivers/clk/ti/autoidle.c |2 +-
drivers/clk/ti/clk.c |7 ---
drivers/clk/ti/divider.c |4 ++--
drivers/clk/ti/dpll.c |6 +++---
drivers/clk/ti/gate.c |4 ++--
drivers/clk/ti/interface.c |2 +-
drivers/clk/ti/mux.c |4 ++--
8 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/clk/ti/apll.c b/drivers/clk/ti/apll.c
index 72d9727..49baf38 100644
--- a/drivers/clk/ti/apll.c
+++ b/drivers/clk/ti/apll.c
@@ -203,7 +203,7 @@ static void __init of_dra7_apll_setup(struct device_node
*node)
ad-control_reg = ti_clk_get_reg_addr(node, 0);
ad-idlest_reg = ti_clk_get_reg_addr(node, 1);
- if (!ad-control_reg || !ad-idlest_reg)
+ if (IS_ERR(ad-control_reg) || IS_ERR(ad-idlest_reg))
goto cleanup;
ad-idlest_mask = 0x1;
@@ -384,7 +384,8 @@ static void __init of_omap2_apll_setup(struct device_node
*node)
ad-autoidle_reg = ti_clk_get_reg_addr(node, 1);
ad-idlest_reg = ti_clk_get_reg_addr(node, 2);
- if (!ad-control_reg || !ad-autoidle_reg || !ad-idlest_reg)
+ if (IS_ERR(ad-control_reg) || IS_ERR(ad-autoidle_reg) ||
+ IS_ERR(ad-idlest_reg))
goto cleanup;
clk = clk_register(NULL, clk_hw-hw);
diff --git a/drivers/clk/ti/autoidle.c b/drivers/clk/ti/autoidle.c
index 8912ff8..e75c64c 100644
--- a/drivers/clk/ti/autoidle.c
+++ b/drivers/clk/ti/autoidle.c
@@ -119,7 +119,7 @@ int __init of_ti_clk_autoidle_setup(struct device_node
*node)
clk-name = node-name;
clk-reg = ti_clk_get_reg_addr(node, 0);
- if (!clk-reg) {
+ if (IS_ERR(clk-reg)) {
kfree(clk);
return -EINVAL;
}
diff --git a/drivers/clk/ti/clk.c b/drivers/clk/ti/clk.c
index e22b956..0ebe5c5 100644
--- a/drivers/clk/ti/clk.c
+++ b/drivers/clk/ti/clk.c
@@ -103,7 +103,8 @@ int __init ti_clk_retry_init(struct device_node *node,
struct clk_hw *hw,
* @index: register index from the clock node
*
* Builds clock register address from device tree information. This
- * is a struct of type clk_omap_reg.
+ * is a struct of type clk_omap_reg. Returns a pointer to the register
+ * address, or a pointer error value in failure.
*/
void __iomem *ti_clk_get_reg_addr(struct device_node *node, int index)
{
@@ -121,14 +122,14 @@ void __iomem *ti_clk_get_reg_addr(struct device_node
*node, int index)
if (i == CLK_MAX_MEMMAPS) {
pr_err(clk-provider not found for %s!\n, node-name);
- return NULL;
+ return ERR_PTR(-ENOENT);
}
reg-index = i;
if (of_property_read_u32_index(node, reg, index, val)) {
pr_err(%s must have reg[%d]!\n, node-name, index);
- return NULL;
+ return ERR_PTR(-EINVAL);
}
reg-offset = val;
diff --git a/drivers/clk/ti/divider.c b/drivers/clk/ti/divider.c
index 6211893..ff5f117 100644
--- a/drivers/clk/ti/divider.c
+++ b/drivers/clk/ti/divider.c
@@ -530,8 +530,8 @@ static int __init ti_clk_divider_populate(struct
device_node *node,
u32 val;
*reg = ti_clk_get_reg_addr(node, 0);
- if (!*reg)
- return -EINVAL;
+ if (IS_ERR(*reg))
+ return PTR_ERR(*reg);
if (!of_property_read_u32(node, ti,bit-shift, val))
*shift = val;
diff --git a/drivers/clk/ti/dpll.c b/drivers/clk/ti/dpll.c
index 81dc469..11478a5 100644
--- a/drivers/clk/ti/dpll.c
+++ b/drivers/clk/ti/dpll.c
@@ -390,18 +390,18 @@ static void __init of_ti_dpll_setup(struct device_node
*node,
#endif
} else {
dd-idlest_reg = ti_clk_get_reg_addr(node, 1);
- if (!dd-idlest_reg)
+ if (IS_ERR(dd-idlest_reg))
goto cleanup;
dd-mult_div1_reg = ti_clk_get_reg_addr(node, 2);
}
- if (!dd-control_reg || !dd-mult_div1_reg)
+ if (IS_ERR(dd-control_reg) || IS_ERR(dd-mult_div1_reg))
goto cleanup;
if (dd-autoidle_mask) {
dd-autoidle_reg = ti_clk_get_reg_addr(node, 3);
- if (!dd-autoidle_reg)
+ if (IS_ERR(dd-autoidle_reg))
goto cleanup;
Re: [PATCH v13 3/6] clk: Make clk API return per-user struct clk instances
Quoting Stephen Boyd (2015-02-06 11:30:18)
On 02/06/15 05:39, Russell King - ARM Linux wrote:
On Thu, Feb 05, 2015 at 05:35:28PM -0800, Stephen Boyd wrote:
From what I can tell this code is
now broken because we made all clk getting functions (there's quite a
few...) return unique pointers every time they're called. It seems that
the driver wants to know if extclk and clk are the same so it can do
something differently in kirkwood_set_rate(). Do we need some sort of
clk_equal(struct clk *a, struct clk *b) function for drivers like this?
Well, the clocks in question are the SoC internal clock (which is more or
less fixed, but has a programmable divider) and an externally supplied
clock, and the IP has a multiplexer on its input which allows us to select
between those two sources.
If it were possible to bind both to the same clock, it wouldn't be a
useful configuration - nothing would be gained from doing so in terms of
available rates.
What the comparison is there for is to catch the case with legacy lookups
where a clkdev lookup entry with a NULL connection ID results in matching
any connection ID passed to clk_get(). If the patch changes this, then
we will have a regression - and this is something which needs fixing
_before_ we do this return unique clocks.
Ok. It seems that we might need a clk_equal() or similar API after all.
My understanding is that this driver is calling clk_get() twice with
NULL for the con_id and then extclk in attempts to get the SoC
internal clock and the externally supplied clock. If we're using legacy
lookups then both clk_get() calls may map to the same clk_lookup entry
and before Tomeu's patch that returns unique clocks the driver could
detect this case and know that there isn't an external clock. Looking at
arch/arm/mach-dove/common.c it seems that there is only one lookup per
device and it has a wildcard NULL for con_id so both clk_get() calls
here are going to find the same lookup and get a unique struct clk pointer.
Why don't we make the legacy lookup more specific and actually indicate
internal for the con_id? Then the external clock would fail to be
found, but we can detect that case and figure out that it's not due to
probe defer, but instead due to the fact that there really isn't any
mapping. It looks like the code is already prepared for this anyway.
8
From: Stephen Boyd sb...@codeaurora.org
Subject: [PATCH] ARM: dove: Remove wildcard from mvebu-audio device clk lookup
This i2s driver is using the wildcard nature of clkdev lookups to
figure out if there's an external clock or not. It does this by
calling clk_get() twice with NULL for the con_id first and then
external for the con_id the second time around and then
compares the two pointers. With DT the wildcard feature of
clk_get() is gone and so the driver has to handle an error from
the second clk_get() call as meaning no external clock
specified. Let's use that logic even with clk lookups to
simplify the code and remove the struct clk pointer comparisons
which may not work in the future when clk_get() returns unique
pointers.
Signed-off-by: Stephen Boyd sb...@codeaurora.org
Russell et al,
I'm happy to take this patch through the clock tree (where the problem
shows up) with an ack.
Regards,
Mike
---
arch/arm/mach-dove/common.c | 4 ++--
sound/soc/kirkwood/kirkwood-i2s.c | 13 -
2 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-dove/common.c b/arch/arm/mach-dove/common.c
index 0d1a89298ece..f290fc944cc1 100644
--- a/arch/arm/mach-dove/common.c
+++ b/arch/arm/mach-dove/common.c
@@ -124,8 +124,8 @@ static void __init dove_clk_init(void)
orion_clkdev_add(NULL, sdhci-dove.1, sdio1);
orion_clkdev_add(NULL, orion_nand, nand);
orion_clkdev_add(NULL, cafe1000-ccic.0, camera);
- orion_clkdev_add(NULL, mvebu-audio.0, i2s0);
- orion_clkdev_add(NULL, mvebu-audio.1, i2s1);
+ orion_clkdev_add(internal, mvebu-audio.0, i2s0);
+ orion_clkdev_add(internal, mvebu-audio.1, i2s1);
orion_clkdev_add(NULL, mv_crypto, crypto);
orion_clkdev_add(NULL, dove-ac97, ac97);
orion_clkdev_add(NULL, dove-pdma, pdma);
diff --git a/sound/soc/kirkwood/kirkwood-i2s.c
b/sound/soc/kirkwood/kirkwood-i2s.c
index def7d8260c4e..0bfeb712a997 100644
--- a/sound/soc/kirkwood/kirkwood-i2s.c
+++ b/sound/soc/kirkwood/kirkwood-i2s.c
@@ -564,7 +564,7 @@ static int kirkwood_i2s_dev_probe(struct platform_device
*pdev)
return -EINVAL;
}
- priv-clk = devm_clk_get(pdev-dev, np ? internal : NULL);
+ priv-clk = devm_clk_get(pdev-dev, internal);
if (IS_ERR(priv-clk)) {
dev_err(pdev-dev, no clock\n);
return PTR_ERR(priv-clk);
@@ -579,14 +579,9 @@ static int kirkwood_i2s_dev_probe(struct platform_device
*pdev)
if
Re: [PATCH 00/11] ARM: OMAP3: legacy clock data move under clk driver
On Tue, Feb 3, 2015 at 11:04 AM, Tony Lindgren t...@atomide.com wrote:
* Arnd Bergmann a...@arndb.de [150203 09:03]:
On Thursday 08 January 2015, Tony Lindgren wrote:
Great, hopefully this will finally allow Mike to make the
generic struct clk private to drivers/clk :)
Seems to boot just fine based on a quick legacy booting test
on n900.
Mike, assuming no other issues, can you please apply these into a
immutable branch against v3.19-rc1 that Paul and I can also merge
in as needed?
Please also feel free to add:
Acked-by: Tony Lindgren t...@atomide.com
The series has arrived in linux-next and promptly triggered a few
randconfig build errors. Here is a patch that fixes it. Feel free
to replace it with a different patch if you don't like this version.
8
Subject: clk: omap: compile legacy omap3 clocks conditionally
The 'ARM: OMAP3: legacy clock data move under clk driver' patch series
causes build errors when CONFIG_OMAP3 is not set:
drivers/clk/ti/dpll.c: In function 'ti_clk_register_dpll':
drivers/clk/ti/dpll.c:199:31: error: 'omap3_dpll_ck_ops' undeclared (first
use in this function)
const struct clk_ops *ops = omap3_dpll_ck_ops;
^
drivers/clk/ti/dpll.c:199:31: note: each undeclared identifier is reported
only once for each function it appears in
drivers/clk/ti/dpll.c:259:10: error: 'omap3_dpll_per_ck_ops' undeclared
(first use in this function)
ops = omap3_dpll_per_ck_ops;
^
drivers/built-in.o: In function `ti_clk_register_gate':
drivers/clk/ti/gate.c:179: undefined reference to
`clkhwops_omap3430es2_dss_usbhost_wait'
drivers/clk/ti/gate.c:179: undefined reference to
`clkhwops_am35xx_ipss_module_wait'
-in.o: In function `ti_clk_register_interface':
drivers/clk/ti/interface.c:100: undefined reference to
`clkhwops_omap3430es2_iclk_hsotgusb_wait'
drivers/clk/ti/interface.c:100: undefined reference to
`clkhwops_omap3430es2_iclk_dss_usbhost_wait'
drivers/clk/ti/interface.c:100: undefined reference to
`clkhwops_omap3430es2_iclk_ssi_wait'
drivers/clk/ti/interface.c:100: undefined reference to
`clkhwops_am35xx_ipss_wait'
drivers/built-in.o: In function `ti_clk_register_composite':
:(.text+0x3da768): undefined reference to `ti_clk_build_component_gate'
In order to fix that problem, this patch makes the omap3 legacy code
compiled only when both CONFIG_OMAP3 and CONFIG_ATAGS are set.
Looks OK to me:
Acked-by: Tony Lindgren t...@atomide.com
Thanks for the fix Arnd and for the Ack Tony. I beautified the commitlog a bit.
Applied to clk-next.
Regards,
Mike
Signed-off-by: Arnd Bergmann a...@arndb.de
diff --git a/drivers/clk/ti/Makefile b/drivers/clk/ti/Makefile
index 14e6686a5eea..105ffd0f5e79 100644
--- a/drivers/clk/ti/Makefile
+++ b/drivers/clk/ti/Makefile
@@ -1,4 +1,3 @@
-ifneq ($(CONFIG_OF),)
obj-y+= clk.o autoidle.o
clockdomain.o
clk-common = dpll.o composite.o divider.o gate.o \
fixed-factor.o mux.o apll.o
@@ -6,10 +5,13 @@ obj-$(CONFIG_SOC_AM33XX)+= $(clk-common)
clk-33xx.o
obj-$(CONFIG_SOC_TI81XX) += $(clk-common) fapll.o clk-816x.o
obj-$(CONFIG_ARCH_OMAP2) += $(clk-common) interface.o clk-2xxx.o
obj-$(CONFIG_ARCH_OMAP3) += $(clk-common) interface.o \
-clk-3xxx.o clk-3xxx-legacy.o
+clk-3xxx.o
obj-$(CONFIG_ARCH_OMAP4) += $(clk-common) clk-44xx.o
obj-$(CONFIG_SOC_OMAP5) += $(clk-common) clk-54xx.o
obj-$(CONFIG_SOC_DRA7XX) += $(clk-common) clk-7xx.o \
clk-dra7-atl.o
obj-$(CONFIG_SOC_AM43XX) += $(clk-common) clk-43xx.o
+
+ifdef CONFIG_ATAGS
+obj-$(CONFIG_ARCH_OMAP3)+= clk-3xxx-legacy.o
endif
diff --git a/drivers/clk/ti/clk.c b/drivers/clk/ti/clk.c
index 546dae405402..e22b95646e09 100644
--- a/drivers/clk/ti/clk.c
+++ b/drivers/clk/ti/clk.c
@@ -186,6 +186,7 @@ void ti_dt_clk_init_retry_clks(void)
}
}
+#if defined(CONFIG_ARCH_OMAP3) defined(CONFIG_ATAGS)
void __init ti_clk_patch_legacy_clks(struct ti_clk **patch)
{
while (*patch) {
@@ -308,3 +309,4 @@ int __init ti_clk_register_legacy_clks(struct
ti_clk_alias *clks)
return 0;
}
+#endif
diff --git a/drivers/clk/ti/composite.c b/drivers/clk/ti/composite.c
index 3a9665fce041..3654f61912eb 100644
--- a/drivers/clk/ti/composite.c
+++ b/drivers/clk/ti/composite.c
@@ -118,6 +118,7 @@ static inline struct clk_hw *_get_hw(struct
clk_hw_omap_comp *clk, int idx)
#define to_clk_hw_comp(_hw) container_of(_hw, struct clk_hw_omap_comp, hw)
+#if defined(CONFIG_ARCH_OMAP3) defined(CONFIG_ATAGS)
struct clk *ti_clk_register_composite(struct ti_clk *setup)
{
struct ti_clk_composite *comp;
@@
Re: [PATCH v13 3/6] clk: Make clk API return per-user struct clk instances
Quoting Tero Kristo (2015-02-02 11:32:01)
On 02/01/2015 11:24 PM, Mike Turquette wrote:
Quoting Tomeu Vizoso (2015-01-23 03:03:30)
Moves clock state to struct clk_core, but takes care to change as little
API as
possible.
struct clk_hw still has a pointer to a struct clk, which is the
implementation's per-user clk instance, for backwards compatibility.
The struct clk that clk_get_parent() returns isn't owned by the caller,
but by
the clock implementation, so the former shouldn't call clk_put() on it.
Because some boards in mach-omap2 still register clocks statically, their
clock
registration had to be updated to take into account that the clock
information
is stored in struct clk_core now.
Tero, Paul Tony,
Tomeu's patch unveils a problem with omap3_noncore_dpll_enable and
struct dpll_data, namely this snippet from
arch/arm/mach-omap2/dpll3xxx.c:
parent = __clk_get_parent(hw-clk);
if (__clk_get_rate(hw-clk) == __clk_get_rate(dd-clk_bypass)) {
WARN(parent != dd-clk_bypass,
here0, parent name is %s, bypass name is
%s\n,
__clk_get_name(parent),
__clk_get_name(dd-clk_bypass));
r = _omap3_noncore_dpll_bypass(clk);
} else {
WARN(parent != dd-clk_ref,
here1, parent name is %s, ref name is
%s\n,
__clk_get_name(parent),
__clk_get_name(dd-clk_ref));
r = _omap3_noncore_dpll_lock(clk);
}
struct dpll_data has members clk_ref and clk_bypass which are struct clk
pointers. This was always a bit of a violation of the clk.h contract
since drivers are not supposed to deref struct clk pointers. Now that we
generate unique pointers for each call to clk_get (clk_ref clk_bypass
are populated by of_clk_get in ti_clk_register_dpll) then the pointer
comparisons above will never be equal (even if they resolve down to the
same struct clk_core). I added the verbose traces to the WARNs above to
illustrate the point: the names are always the same but the pointers
differ.
AFAICT this doesn't break anything, but booting on OMAP3+ results in
noisy WARNs.
I think the correct fix is to replace clk_bypass and clk_ref pointers
with a simple integer parent_index. In fact we already have this index.
See how the pointers are populated in ti_clk_register_dpll:
The problem is we still need to be able to get runtime parent clock
rates (the parent rate may change also), so simple index value is not
sufficient. We need a handle of some sort to the bypass/ref clocks. The
DPLL code generally requires knowledge of the bypass + reference clock
rates to work properly, as it calculates the M/N values based on these.
We can maybe introduce something like of_clk_get_parent_rate, as we have
analogous stuff for getting parent names and indexes. Without
introducing a new helper you could probably just do:
clk_ref = clk_get_parent_by_index(dpll_clk, 0);
ref_rate = clk_get_rate(clk_ref);
clk_bypass = clk_get_parent_by_index(dpll_clk, 1);
bypass_rate = clk_get_rate(clk_bypass);
Currently the semantics around this call are weird. It seems like it
would create a new struct clk pointer but it does not. So don't call
clk_put on clk_ref and clk_bypass yet. That might change in the future
as we iron out this brave new world that we all live in. Probably best
to leave a FIXME in there.
Stephen Tomeu, let me know if I got any of that wrong.
Shall I change the DPLL code to check against clk_hw pointers or what is
the preferred approach here? The patch at the end does this and fixes
the dpll related warnings.
Yes, for now that is fine, but feels a bit hacky to me. I don't know
honestly, let me sleep on it. Anyways for 3.20 that is perfectly fine
but we might want to switch to something like the scheme above.
Btw, the rate constraints patch broke boot for me completely, but sounds
like you reverted it already.
Fixed with Stephen's patch from last week. Thanks for dealing with all
the breakage so promptly. It has helped a lot!
Regards,
Mike
-Tero
Author: Tero Kristo t-kri...@ti.com
Date: Mon Feb 2 17:19:17 2015 +0200
ARM: OMAP3+: clock: dpll: fix logic for comparing parent clocks
DPLL code uses reference and bypass clock pointers for determining
runtime
properties for these clocks, like parent clock rates.
As clock API now returns per-user clock structs, using a global handle
in the clock driver code does not work properly anymore. Fix this by
using the clk_hw instead, and comparing this against the parents.
Signed-off-by: Tero Kristo t-kri...@ti.com
Fixes: 59cf3fcf9baf (clk: Make clk API return per-user struct clk
instances)
diff --git a/arch/arm/mach-omap2
Re: [PATCH v13 3/6] clk: Make clk API return per-user struct clk instances
Quoting Tony Lindgren (2015-02-02 12:44:02)
* Tero Kristo t-kri...@ti.com [150202 11:35]:
On 02/01/2015 11:24 PM, Mike Turquette wrote:
Quoting Tomeu Vizoso (2015-01-23 03:03:30)
AFAICT this doesn't break anything, but booting on OMAP3+ results in
noisy WARNs.
I think the correct fix is to replace clk_bypass and clk_ref pointers
with a simple integer parent_index. In fact we already have this index.
See how the pointers are populated in ti_clk_register_dpll:
The problem is we still need to be able to get runtime parent clock rates
(the parent rate may change also), so simple index value is not sufficient.
We need a handle of some sort to the bypass/ref clocks. The DPLL code
generally requires knowledge of the bypass + reference clock rates to work
properly, as it calculates the M/N values based on these.
Shall I change the DPLL code to check against clk_hw pointers or what is the
preferred approach here? The patch at the end does this and fixes the dpll
related warnings.
Btw, the rate constraints patch broke boot for me completely, but sounds
like you reverted it already.
Thanks Tero, looks like your fix fixes all the issues I'm seeing with
commit 59cf3fcf9baf. That is noisy dmesg, dpll_abe_ck not locking
on 4430sdp, and off-idle not working for omap3.
I could not get the patch to apply, below is what I applied manually.
Mike, If possible, maybe fold this into 59cf3fcf9baf? It applies with
some fuzz on that too. And inn that case, please feel also to add the
following for Tomeu's patch:
Tested-by: Tony Lindgren t...@atomide.com
Done and done. Things look good in my testing. I've pushed another
branch out to the mirrors and hopefully the autobuild/autoboot testing
will give us the green light.
This implementation can be revisited probably after 3.19 comes out if
Tero doesn't like using clk_hw directly, or if we provide a better
interface.
Thanks,
Mike
8
From: Tero Kristo t-kri...@ti.com
Date: Mon, 2 Feb 2015 12:17:00 -0800
Subject: [PATCH] ARM: OMAP3+: clock: dpll: fix logic for comparing parent
clocks
DPLL code uses reference and bypass clock pointers for determining runtime
properties for these clocks, like parent clock rates.
As clock API now returns per-user clock structs, using a global handle
in the clock driver code does not work properly anymore. Fix this by
using the clk_hw instead, and comparing this against the parents.
Fixes: 59cf3fcf9baf (clk: Make clk API return per-user struct clk instances)
Signed-off-by: Tero Kristo t-kri...@ti.com
[t...@atomide.com: updated to apply]
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -410,7 +410,7 @@ int omap3_noncore_dpll_enable(struct clk_hw *hw)
struct clk_hw_omap *clk = to_clk_hw_omap(hw);
int r;
struct dpll_data *dd;
- struct clk *parent;
+ struct clk_hw *parent;
dd = clk-dpll_data;
if (!dd)
@@ -427,13 +427,13 @@ int omap3_noncore_dpll_enable(struct clk_hw *hw)
}
}
- parent = __clk_get_parent(hw-clk);
+ parent = __clk_get_hw(__clk_get_parent(hw-clk));
if (__clk_get_rate(hw-clk) == __clk_get_rate(dd-clk_bypass)) {
- WARN_ON(parent != dd-clk_bypass);
+ WARN_ON(parent != __clk_get_hw(dd-clk_bypass));
r = _omap3_noncore_dpll_bypass(clk);
} else {
- WARN_ON(parent != dd-clk_ref);
+ WARN_ON(parent != __clk_get_hw(dd-clk_ref));
r = _omap3_noncore_dpll_lock(clk);
}
@@ -549,7 +549,8 @@ int omap3_noncore_dpll_set_rate(struct clk_hw *hw,
unsigned long rate,
if (!dd)
return -EINVAL;
- if (__clk_get_parent(hw-clk) != dd-clk_ref)
+ if (__clk_get_hw(__clk_get_parent(hw-clk)) !=
+ __clk_get_hw(dd-clk_ref))
return -EINVAL;
if (dd-last_rounded_rate == 0)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v13 3/6] clk: Make clk API return per-user struct clk instances
Quoting Stephen Boyd (2015-02-02 14:35:59) On 02/02/15 13:31, Julia Lawall wrote: On Mon, 2 Feb 2015, Stephen Boyd wrote: Julia, Is there a way we can write a coccinelle script to check for this? The goal being to find all drivers that are comparing struct clk pointers or attempting to dereference them. There are probably other frameworks that could use the same type of check (regulator, gpiod, reset, pwm, etc.). Probably anything that has a get/put API. Comparing or dereferencing pointers of a particular type should be straightforward to check for. Is there an example of how to use the parent_index value to fix the problem? I'm not sure how to fix this case with parent_index values generically. I imagine it would be highly specific to the surrounding code to the point where we couldn't fix it automatically. For example, if it's a clk consumer (not provider like in this case) using an index wouldn't be the right fix. We would need some sort of clk API that we don't currently have and I would wonder why clock consumers even care to compare such pointers in the first place. Ack. Is there precedent for a Don't do that kind of response? Regards, Mike -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v13 4/6] clk: Add rate constraints to clocks
Quoting Tony Lindgren (2015-02-02 08:12:37)
* Geert Uytterhoeven ge...@linux-m68k.org [150202 00:03]:
On Sun, Feb 1, 2015 at 11:18 PM, Mike Turquette mturque...@linaro.org
wrote:
Quoting Tomeu Vizoso (2015-01-31 10:36:22)
On 31 January 2015 at 02:31, Stephen Boyd sb...@codeaurora.org wrote:
On 01/29, Stephen Boyd wrote:
On 01/29/15 05:31, Geert Uytterhoeven wrote:
Hi Tomeu, Mike,
On Fri, Jan 23, 2015 at 12:03 PM, Tomeu Vizoso
tomeu.viz...@collabora.com wrote:
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2391,25 +2543,24 @@ int __clk_get(struct clk *clk)
return 1;
}
-static void clk_core_put(struct clk_core *core)
+void __clk_put(struct clk *clk)
{
struct module *owner;
- owner = core-owner;
+ if (!clk || WARN_ON_ONCE(IS_ERR(clk)))
+ return;
clk_prepare_lock();
- kref_put(core-ref, __clk_release);
+
+ hlist_del(clk-child_node);
+ clk_core_set_rate_nolock(clk-core, clk-core-req_rate);
At this point, clk-core-req_rate is still zero, causing
cpg_div6_clock_round_rate() to be called with a zero rate
parameter,
e.g. on r8a7791:
Hmm.. I wonder if we should assign core-req_rate to be the same as
core-rate during __clk_init()? That would make this call to
clk_core_set_rate_nolock() a nop in this case.
Here's a patch to do this
---8
From: Stephen Boyd sb...@codeaurora.org
Subject: [PATCH] clk: Assign a requested rate by default
We need to assign a requested rate here so that we avoid
requesting a rate of 0 on clocks when we remove clock consumers.
Hi, this looks good to me.
Reviewed-by: Tomeu Vizoso tomeu.viz...@collabora.com
It seems to fix the total boot failure on OMAPs, and hopefully does the
same for SH Mobile and others. I've squashed this into Tomeu's rate
constraints patch to maintain bisect.
Yes, it fixes shmobile. .round_rate() is now called with a sane value of
rate.
Looks like next-20150202 now produces tons of the following errors,
these from omap4:
next-20150202 is the rolled-back changes from last Friday. I removed the
clock constraints patch and in doing so also rolled back the TI clock
driver migration and clk-private.h removal patches. Those are all back
in clk-next as of last night and it looks as though they missed being
pulled into todays linux-next by a matter of minutes :-/
[ 10.568206] [ cut here ]
[ 10.568206] WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:925
clk_disable+0x28/0x34()
[ 10.568237] Modules linked in:
[ 10.568237] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW
3.19.0-rc6-next-20150202 #2037
[ 10.568237] Hardware name: Generic OMAP4 (Flattened Device Tree)
[ 10.568267] [c0015bdc] (unwind_backtrace) from [c001222c]
(show_stack+0x10/0x14)
[ 10.568267] [c001222c] (show_stack) from [c05d2014]
(dump_stack+0x84/0x9c)
[ 10.568267] [c05d2014] (dump_stack) from [c003ea90]
(warn_slowpath_common+0x7c/0xb8)
[ 10.568298] [c003ea90] (warn_slowpath_common) from [c003eb68]
(warn_slowpath_null+0x1c/0x24)
[ 10.568298] [c003eb68] (warn_slowpath_null) from [c04c1ffc]
(clk_disable+0x28/0x34)
[ 10.568328] [c04c1ffc] (clk_disable) from [c0025b3c]
(_disable_clocks+0x18/0x68)
[ 10.568328] [c0025b3c] (_disable_clocks) from [c0026f14]
(_idle+0x10c/0x214)
[ 10.568328] [c0026f14] (_idle) from [c0855fac] (_setup+0x338/0x410)
[ 10.568359] [c0855fac] (_setup) from [c0027360]
(omap_hwmod_for_each+0x34/0x60)
[ 10.568359] [c0027360] (omap_hwmod_for_each) from [c08563c4]
(__omap_hwmod_setup_all+0x30/0x40)
[ 10.568389] [c08563c4] (__omap_hwmod_setup_all) from [c0008a04]
(do_one_initcall+0x80/0x1dc)
[ 10.568389] [c0008a04] (do_one_initcall) from [c0848ea0]
(kernel_init_freeable+0x204/0x2d0)
[ 10.568420] [c0848ea0] (kernel_init_freeable) from [c05cdab8]
(kernel_init+0x8/0xec)
[ 10.568420] [c05cdab8] (kernel_init) from [c000e790]
(ret_from_fork+0x14/0x24)
[ 10.568420] ---[ end trace cb88537fdc8fa211 ]---
This looks like mis-matched enable/disable calls. We now have unique
struct clk pointers for every call to clk_get. I haven't yet looked
through the hwmod code but I have a feeling that we're doing something
like this:
/* enable clock */
my_clk = clk_get(...);
clk_prepare_enable(my_clk);
clk_put(my_clk);
/* do some work */
do_work();
/* disable clock */
my_clk = clk_get(...);
clk_disable_unprepare(my_clk);
clk_put(my_clk);
The above pattern no longer works since my_clk will be two different
unique pointers, but it really should be one stable pointer across the
whole usage of the clk. E.g:
/* enable clock */
my_clk = clk_get(...);
clk_prepare_enable(my_clk
Re: Clock Regression in next-20150130 caused by cb75a8fcd14e
Quoting Tony Lindgren (2015-01-30 17:04:44) Hi all, Looks like commit cb75a8fcd14e (clk: Add rate constraints to clocks) causes a regression on at least omaps where the serial console either does not show anything, or just prints garbage. Reverting cb75a8fcd14e makes things work again on next-20150130. Any ideas? Stephen posted a patch[0] to fix this. I've squashed that into Tomeu's commit that you reference above and my Panda board is booting fine once again. [0] http://lkml.kernel.org/r/20150131013158.ga4...@codeaurora.org Please let me know if any other issues pop up. There are new WARNs for OMAP3+ boards introduced by a different patch from Tomeu, but this is really because the OMAP DPLL and FAPLL code are dereferencing struct clk pointers when they should not be and is a separate issue from the constraints patch (with a separate email thread). Regards, Mike Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v13 4/6] clk: Add rate constraints to clocks
Quoting Tomeu Vizoso (2015-01-31 10:36:22)
On 31 January 2015 at 02:31, Stephen Boyd sb...@codeaurora.org wrote:
On 01/29, Stephen Boyd wrote:
On 01/29/15 05:31, Geert Uytterhoeven wrote:
Hi Tomeu, Mike,
On Fri, Jan 23, 2015 at 12:03 PM, Tomeu Vizoso
tomeu.viz...@collabora.com wrote:
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2391,25 +2543,24 @@ int __clk_get(struct clk *clk)
return 1;
}
-static void clk_core_put(struct clk_core *core)
+void __clk_put(struct clk *clk)
{
struct module *owner;
- owner = core-owner;
+ if (!clk || WARN_ON_ONCE(IS_ERR(clk)))
+ return;
clk_prepare_lock();
- kref_put(core-ref, __clk_release);
+
+ hlist_del(clk-child_node);
+ clk_core_set_rate_nolock(clk-core, clk-core-req_rate);
At this point, clk-core-req_rate is still zero, causing
cpg_div6_clock_round_rate() to be called with a zero rate parameter,
e.g. on r8a7791:
Hmm.. I wonder if we should assign core-req_rate to be the same as
core-rate during __clk_init()? That would make this call to
clk_core_set_rate_nolock() a nop in this case.
Here's a patch to do this
---8
From: Stephen Boyd sb...@codeaurora.org
Subject: [PATCH] clk: Assign a requested rate by default
We need to assign a requested rate here so that we avoid
requesting a rate of 0 on clocks when we remove clock consumers.
Hi, this looks good to me.
Reviewed-by: Tomeu Vizoso tomeu.viz...@collabora.com
It seems to fix the total boot failure on OMAPs, and hopefully does the
same for SH Mobile and others. I've squashed this into Tomeu's rate
constraints patch to maintain bisect.
Regards,
Mike
Thanks,
Tomeu
Signed-off-by: Stephen Boyd sb...@codeaurora.org
---
drivers/clk/clk.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index a29daf9edea4..8416ed1c40be 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2142,6 +2142,7 @@ int __clk_init(struct device *dev, struct clk
*clk_user)
struct clk_core *orphan;
struct hlist_node *tmp2;
struct clk_core *clk;
+ unsigned long rate;
if (!clk_user)
return -EINVAL;
@@ -2266,12 +2267,13 @@ int __clk_init(struct device *dev, struct clk
*clk_user)
* then rate is set to zero.
*/
if (clk-ops-recalc_rate)
- clk-rate = clk-ops-recalc_rate(clk-hw,
+ rate = clk-ops-recalc_rate(clk-hw,
clk_core_get_rate_nolock(clk-parent));
else if (clk-parent)
- clk-rate = clk-parent-rate;
+ rate = clk-parent-rate;
else
- clk-rate = 0;
+ rate = 0;
+ clk-rate = clk-req_rate = rate;
/*
* walk the list of orphan clocks and reparent any that are
children of
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v13 3/6] clk: Make clk API return per-user struct clk instances
Quoting Tomeu Vizoso (2015-01-23 03:03:30)
Moves clock state to struct clk_core, but takes care to change as little API
as
possible.
struct clk_hw still has a pointer to a struct clk, which is the
implementation's per-user clk instance, for backwards compatibility.
The struct clk that clk_get_parent() returns isn't owned by the caller, but by
the clock implementation, so the former shouldn't call clk_put() on it.
Because some boards in mach-omap2 still register clocks statically, their
clock
registration had to be updated to take into account that the clock information
is stored in struct clk_core now.
Tero, Paul Tony,
Tomeu's patch unveils a problem with omap3_noncore_dpll_enable and
struct dpll_data, namely this snippet from
arch/arm/mach-omap2/dpll3xxx.c:
parent = __clk_get_parent(hw-clk);
if (__clk_get_rate(hw-clk) == __clk_get_rate(dd-clk_bypass)) {
WARN(parent != dd-clk_bypass,
here0, parent name is %s, bypass name is %s\n,
__clk_get_name(parent),
__clk_get_name(dd-clk_bypass));
r = _omap3_noncore_dpll_bypass(clk);
} else {
WARN(parent != dd-clk_ref,
here1, parent name is %s, ref name is %s\n,
__clk_get_name(parent),
__clk_get_name(dd-clk_ref));
r = _omap3_noncore_dpll_lock(clk);
}
struct dpll_data has members clk_ref and clk_bypass which are struct clk
pointers. This was always a bit of a violation of the clk.h contract
since drivers are not supposed to deref struct clk pointers. Now that we
generate unique pointers for each call to clk_get (clk_ref clk_bypass
are populated by of_clk_get in ti_clk_register_dpll) then the pointer
comparisons above will never be equal (even if they resolve down to the
same struct clk_core). I added the verbose traces to the WARNs above to
illustrate the point: the names are always the same but the pointers
differ.
AFAICT this doesn't break anything, but booting on OMAP3+ results in
noisy WARNs.
I think the correct fix is to replace clk_bypass and clk_ref pointers
with a simple integer parent_index. In fact we already have this index.
See how the pointers are populated in ti_clk_register_dpll:
dd-clk_ref = of_clk_get(node, 0);
dd-clk_bypass = of_clk_get(node, 1);
Tony, the same problem affects the FAPLL code which copy/pastes some of
the DPLL code.
Thoughts?
Regards,
Mike
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/11] ARM: OMAP3: legacy clock data move under clk driver
Quoting Tero Kristo (2015-01-30 07:20:36)
On 01/30/2015 02:42 AM, Mike Turquette wrote:
Quoting Tero Kristo (2015-01-29 12:19:29)
On 01/08/2015 01:00 AM, Tony Lindgren wrote:
* Tero Kristo t-kri...@ti.com [141216 08:22]:
Hi,
These patches move the legacy clock data for omap3 under drivers/clk/ti.
After these patches are applied, it should be possible to get rid of
clk-private.h (long pending project for Mike.)
Testing done (on top of 3.18-rc1):
omap3-beagle: boot / suspend-resume (ret/off) / cpuidle (ret/off)
omap3-beagle-xm: boot upto fs mount (see note below)
sdp3430: boot
n900: boot
Note: beagle-xm failed with FS mount on the board I have access to, but
this happens with clean 3.18-rc1 and linux-next also at the
moment.
The board has probably corrupted filesystem image but I am unable
to fix this atm (remote board.)
Test branch:
tree: https://github.com/t-kristo/linux-pm.git
branch: 3.18-rc1-omap3-clk-rework
Great, hopefully this will finally allow Mike to make the
generic struct clk private to drivers/clk :)
Seems to boot just fine based on a quick legacy booting test
on n900.
Mike, assuming no other issues, can you please apply these into a
immutable branch against v3.19-rc1 that Paul and I can also merge
in as needed?
Please also feel free to add:
Acked-by: Tony Lindgren t...@atomide.com
I just rebased these patches on top of 3.19-rc1, and noticed a problem
with dpll5 on beagle-xm (basically a divide-by-zero error + locking
issue during boot.) The extra diff at the end of this email fixes the
problems, I will also send the updated two patches as v2. Updated branch
available in my tree under name 3.19-rc1-omap3-clk-rework.
I've applied these 11 patches on top of v3.19-rc1, including the two V2
patches for #6 and #8 to the clk-omap-legacy branch here:
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-omap-legacy
Let me know if I screwed anything up. I've merged this immutable branch
into clk-next.
In addition I've made some changes to remove clk-private.h permanently.
I'll post those later today. Again, please let me know if I screwed
anything up.
I can't see the clk-omap-legacy merged to clk-next so far, maybe you did
not push it yet? The branch itself is identical copy of mine, so can't
see any issues there so far.
That is correct. There are a lot of unrelated changes in clk-next right
now so I didn't push this OMAP stuff last night. Turns out to be a good
thing since linux-next had some breakage today. Once that is resolved
I'll push this out, but clk-omap-legacy IS merged locally in my tree,
just not on the public git that linux-next pulls.
Regards,
Mike
-Tero
Regards,
Mike
- Tero
-
diff --git a/drivers/clk/ti/clk-3xxx-legacy.c
b/drivers/clk/ti/clk-3xxx-legacy.c
index 81ad510..e0732a4 100644
--- a/drivers/clk/ti/clk-3xxx-legacy.c
+++ b/drivers/clk/ti/clk-3xxx-legacy.c
@@ -136,6 +136,7 @@ static struct ti_clk_dpll dpll3_ck_data = {
.idlest_mask = 0x1,
.auto_recal_bit = 0x3,
.max_divider = 0x80,
+ .min_divider = 0x1,
.recal_en_bit = 0x5,
.max_multiplier = 0x7ff,
.enable_mask = 0x7,
@@ -307,6 +308,7 @@ static struct ti_clk_dpll dpll4_ck_data = {
.idlest_mask = 0x2,
.auto_recal_bit = 0x13,
.max_divider = 0x80,
+ .min_divider = 0x1,
.recal_en_bit = 0x6,
.max_multiplier = 0x7ff,
.enable_mask = 0x7,
@@ -507,6 +509,7 @@ static struct ti_clk_dpll dpll5_ck_data = {
.idlest_mask = 0x1,
.auto_recal_bit = 0x3,
.max_divider = 0x80,
+ .min_divider = 0x1,
.recal_en_bit = 0x19,
.max_multiplier = 0x7ff,
.enable_mask = 0x7,
@@ -1271,6 +1274,7 @@ static struct ti_clk_dpll dpll1_ck_data = {
.idlest_mask = 0x1,
.auto_recal_bit = 0x3,
.max_divider = 0x80,
+ .min_divider = 0x1,
.recal_en_bit = 0x7,
.max_multiplier = 0x7ff,
.enable_mask = 0x7,
@@ -2154,6 +2158,7 @@ static struct ti_clk_dpll dpll2_ck_data = {
.idlest_mask = 0x1,
.auto_recal_bit = 0x3,
.max_divider = 0x80,
+ .min_divider = 0x1,
.recal_en_bit = 0x8,
.max_multiplier = 0x7ff,
.enable_mask = 0x7,
@@ -2513,6 +2518,7 @@ static struct ti_clk_dpll dpll4_ck_omap36xx_data = {
.idlest_mask = 0x2,
.auto_recal_bit = 0x13,
.max_divider = 0x80,
+ .min_divider = 0x1,
.recal_en_bit = 0x6,
.max_multiplier = 0xfff,
.enable_mask = 0x7,
diff --git a/drivers/clk/ti/clock.h b/drivers/clk/ti/clock.h
index 8d9c603..404158d 100644
--- a/drivers/clk/ti/clock.h
+++ b/drivers/clk/ti/clock.h
@@ -148,6
Re: [PATCH 00/11] ARM: OMAP3: legacy clock data move under clk driver
Quoting Tero Kristo (2015-01-29 12:19:29)
On 01/08/2015 01:00 AM, Tony Lindgren wrote:
* Tero Kristo t-kri...@ti.com [141216 08:22]:
Hi,
These patches move the legacy clock data for omap3 under drivers/clk/ti.
After these patches are applied, it should be possible to get rid of
clk-private.h (long pending project for Mike.)
Testing done (on top of 3.18-rc1):
omap3-beagle: boot / suspend-resume (ret/off) / cpuidle (ret/off)
omap3-beagle-xm: boot upto fs mount (see note below)
sdp3430: boot
n900: boot
Note: beagle-xm failed with FS mount on the board I have access to, but
this happens with clean 3.18-rc1 and linux-next also at the moment.
The board has probably corrupted filesystem image but I am unable
to fix this atm (remote board.)
Test branch:
tree: https://github.com/t-kristo/linux-pm.git
branch: 3.18-rc1-omap3-clk-rework
Great, hopefully this will finally allow Mike to make the
generic struct clk private to drivers/clk :)
Seems to boot just fine based on a quick legacy booting test
on n900.
Mike, assuming no other issues, can you please apply these into a
immutable branch against v3.19-rc1 that Paul and I can also merge
in as needed?
Please also feel free to add:
Acked-by: Tony Lindgren t...@atomide.com
I just rebased these patches on top of 3.19-rc1, and noticed a problem
with dpll5 on beagle-xm (basically a divide-by-zero error + locking
issue during boot.) The extra diff at the end of this email fixes the
problems, I will also send the updated two patches as v2. Updated branch
available in my tree under name 3.19-rc1-omap3-clk-rework.
I've applied these 11 patches on top of v3.19-rc1, including the two V2
patches for #6 and #8 to the clk-omap-legacy branch here:
git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-omap-legacy
Let me know if I screwed anything up. I've merged this immutable branch
into clk-next.
In addition I've made some changes to remove clk-private.h permanently.
I'll post those later today. Again, please let me know if I screwed
anything up.
Regards,
Mike
- Tero
-
diff --git a/drivers/clk/ti/clk-3xxx-legacy.c
b/drivers/clk/ti/clk-3xxx-legacy.c
index 81ad510..e0732a4 100644
--- a/drivers/clk/ti/clk-3xxx-legacy.c
+++ b/drivers/clk/ti/clk-3xxx-legacy.c
@@ -136,6 +136,7 @@ static struct ti_clk_dpll dpll3_ck_data = {
.idlest_mask = 0x1,
.auto_recal_bit = 0x3,
.max_divider = 0x80,
+ .min_divider = 0x1,
.recal_en_bit = 0x5,
.max_multiplier = 0x7ff,
.enable_mask = 0x7,
@@ -307,6 +308,7 @@ static struct ti_clk_dpll dpll4_ck_data = {
.idlest_mask = 0x2,
.auto_recal_bit = 0x13,
.max_divider = 0x80,
+ .min_divider = 0x1,
.recal_en_bit = 0x6,
.max_multiplier = 0x7ff,
.enable_mask = 0x7,
@@ -507,6 +509,7 @@ static struct ti_clk_dpll dpll5_ck_data = {
.idlest_mask = 0x1,
.auto_recal_bit = 0x3,
.max_divider = 0x80,
+ .min_divider = 0x1,
.recal_en_bit = 0x19,
.max_multiplier = 0x7ff,
.enable_mask = 0x7,
@@ -1271,6 +1274,7 @@ static struct ti_clk_dpll dpll1_ck_data = {
.idlest_mask = 0x1,
.auto_recal_bit = 0x3,
.max_divider = 0x80,
+ .min_divider = 0x1,
.recal_en_bit = 0x7,
.max_multiplier = 0x7ff,
.enable_mask = 0x7,
@@ -2154,6 +2158,7 @@ static struct ti_clk_dpll dpll2_ck_data = {
.idlest_mask = 0x1,
.auto_recal_bit = 0x3,
.max_divider = 0x80,
+ .min_divider = 0x1,
.recal_en_bit = 0x8,
.max_multiplier = 0x7ff,
.enable_mask = 0x7,
@@ -2513,6 +2518,7 @@ static struct ti_clk_dpll dpll4_ck_omap36xx_data = {
.idlest_mask = 0x2,
.auto_recal_bit = 0x13,
.max_divider = 0x80,
+ .min_divider = 0x1,
.recal_en_bit = 0x6,
.max_multiplier = 0xfff,
.enable_mask = 0x7,
diff --git a/drivers/clk/ti/clock.h b/drivers/clk/ti/clock.h
index 8d9c603..404158d 100644
--- a/drivers/clk/ti/clock.h
+++ b/drivers/clk/ti/clock.h
@@ -148,6 +148,7 @@ struct ti_clk_dpll {
u32 sddiv_mask;
u16 max_multiplier;
u16 max_divider;
+ u8 min_divider;
u8 auto_recal_bit;
u8 recal_en_bit;
u8 recal_st_bit;
diff --git a/drivers/clk/ti/dpll.c b/drivers/clk/ti/dpll.c
index 7d67639..47ebff7 100644
--- a/drivers/clk/ti/dpll.c
+++ b/drivers/clk/ti/dpll.c
@@ -243,6 +243,7 @@ struct clk *ti_clk_register_dpll(struct ti_clk *setup)
dd-sddiv_mask = dpll-sddiv_mask;
dd-dco_mask = dpll-dco_mask;
dd-max_divider = dpll-max_divider;
+ dd-min_divider = dpll-min_divider;
dd-max_multiplier = dpll-max_multiplier;
dd-auto_recal_bit = dpll-auto_recal_bit;
dd-recal_en_bit = dpll-recal_en_bit;
--
To
Re: [PATCH 0/2] Minimal FAPLL clock support for dm816x
Quoting Mike Turquette (2015-01-14 14:06:49) Quoting Tony Lindgren (2015-01-13 14:51:26) Hi all, Here's a minimal support for the FAPLL (Flying Adder PLL) on dm816x which is a omap variant. Tony, Patches look fine to me. I'll give it a few days for Paul or Tero to comment if they have any concerns. Applied to clk-next. Regards, Mike Also, flying adder pll is a pretty badass pll name. Regards, Mike Regards, Tony Tony Lindgren (2): clk: ti: Add support for FAPLL on dm816x clk: ti: Initialize clocks for dm816x .../devicetree/bindings/clock/ti/fapll.txt | 33 ++ drivers/clk/ti/Makefile| 1 + drivers/clk/ti/clk-3xxx.c | 8 +- drivers/clk/ti/clk-816x.c | 53 +++ drivers/clk/ti/fapll.c | 410 + 5 files changed, 498 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/ti/fapll.txt create mode 100644 drivers/clk/ti/clk-816x.c create mode 100644 drivers/clk/ti/fapll.c -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Minimal FAPLL clock support for dm816x
Quoting Tony Lindgren (2015-01-13 14:51:26) Hi all, Here's a minimal support for the FAPLL (Flying Adder PLL) on dm816x which is a omap variant. Tony, Patches look fine to me. I'll give it a few days for Paul or Tero to comment if they have any concerns. Also, flying adder pll is a pretty badass pll name. Regards, Mike Regards, Tony Tony Lindgren (2): clk: ti: Add support for FAPLL on dm816x clk: ti: Initialize clocks for dm816x .../devicetree/bindings/clock/ti/fapll.txt | 33 ++ drivers/clk/ti/Makefile| 1 + drivers/clk/ti/clk-3xxx.c | 8 +- drivers/clk/ti/clk-816x.c | 53 +++ drivers/clk/ti/fapll.c | 410 + 5 files changed, 498 insertions(+), 7 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/ti/fapll.txt create mode 100644 drivers/clk/ti/clk-816x.c create mode 100644 drivers/clk/ti/fapll.c -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regression: Clock changes in next-20141205 break at least omap4
Quoting Paul Walmsley (2014-12-18 11:23:07) On Wed, 17 Dec 2014, Lucas Stach wrote: Maybe I'm thinking about this too lightly, but I think we already have the right abstractions in place. The clock tree in Linux is always modeled along the flow of reference clocks. So typically the root of the tree is something like an oscillator and everything spreads out from this in a parent/child relation. So clearly the reference clock of a PLL is the PLLs parent. If the PLL is running in open-loop mode (isn't this rather direct frequency synthesis?) is has no parent and is the root of a tree itself. If a PLL needs a functional clock to drive some internal logic, that doesn't directly influence the clock synthesis from reference to resulting clock, that clock would be no parent to the PLL. The PLL is merely a consumer of this clock just like every other device in the system. I suspect we're using different terminology. From my point of view, a reference clock is an input clock signal that is used by another clock generator IP block or clock measurement IP block. The use is to measure and (optionally) discipline another oscillator. Thus the clock generator/measurement IP block generally does not electrically propagate the reference clock outside of the block. (Although some of the reference clock's characteristics, like phase noise or frequency stability, may be propagated indirectly.) Only a small number of clock tree entities makes use of reference clocks. By contrast, we could use the term source clock in the SoC context to mean a clock signal that directly drives a downstream IP block, in an electrical sense. These clocks are directly propagated through dividers and muxes. If you're willing to play along with this terminology, then a PLL's source clock would be its internal VCO/DCO, which thus would be the root clock of the PLL. Flipping over from hardware to software, in the Linux clock tree, there's usually not much point to modeling the VCO/DCO directly because it tends not to be under the direct control of the OS, and it is usually tightly integrated into the PLLs from a hardware point of view. But unlike most of the Linux clock tree nodes that are downstream from clock sources, which use clocks that are electrically driven by the clock source, the clock signal that PLLs and PLL-like clocks generate is not directly driven by the reference clock. Hi Paul, This is debatable given that the formula to determine the OMAP DPLL output rate directly depends upon the rate of the input clock (osc, 32Khz, hsd, bypass, etc). I'm not speaking for all PLLs, just for the OMAP ones that I am familiar with. So why is a reference clock listed as a Linux parent clock of an OMAP PLL? At least for OMAP, it was sort of shoehorned in to represent a gating dependency. It was a way of stating that the reference clock had to be enabled for the PLL to generate an output clock. (The off-chip crystal oscillator that drives most of the PLL reference clocks could be disabled when all of its users were idle, to save energy.) But this type of gating dependency is equally true for, say, a separate functional clock that the clock source requires in order to operate. (OMAP PLLs didn't have a separate functional clock, at least not that I was aware of; but that's not true for some similar clock sources used in other SoCs.) Using your terminology above, it is possible to do what you want to do today without any change to the clock framework. Simply make each DPLL a device. That device calls clk_get, clk_prepare_enable on the input reference clock. Coincidentally these new DPLL device are clock providers themselves and they provide root clocks of their own which are the DPLLs and corresponding Mx outputs. This model would treat the reference clock as something that drives the DPLL device's logic, but not as a part of the clock signal chain. I don't personally agree with the idea that the reference clock is not a parent of the DPLL, but I don't oppose any change to the OMAP clock driver along those lines so long as it is done in a sane way. It seems there is never just one correct way to look at these things. The clock framework wasn't re-entrant back then, and we wanted to avoid implementing re-entrancy because we were worried that it could turn into a mess. So we just wound up listing the reference clock as the PLL's Linux parent clock. My original comment was just intended to be a reflection on what it means to be a parent clock in the Linux clock tree sense. If it's intended to represent source clocks as they are defined above, then PLLs and PLL-like clocks should be root nodes, except for the few cases where it's useful to add a node for the underlying source oscillator directly (for example, if open-loop mode is supported). This might be the right way forward for the time being, and I like
Re: [GIT PULL] TI clock driver changes for 3.18 merge window
Quoting Tero Kristo (2014-09-29 09:13:09) Hi Mike, The following changes since commit 7d1311b93e58ed55f3a31cc8f94c4b8fe988a2b9: Linux 3.17-rc1 (2014-08-16 10:40:26 -0600) are available in the git repository at: g...@github.com:t-kristo/linux-pm.git for-v3.18/ti-clk-driver for you to fetch changes up to 04ed831f224d4553682f48e1b4a6b68f2622b68e: clk: ti: dra7-atl-clock: Mark the device as pm_runtime_irq_safe (2014-09-29 11:51:14 +0300) Pulled! Thanks, Mike Mostly fixes, except for the of_clk_init() change for the clock driver. Boot tested on pretty much every board I have access to, also merge tested with latest master to see if there are any conflicts with anything. Behan Webster (1): clk: ti: LLVMLinux: Move __init outside of type definition Peter Ujfalusi (1): clk: ti: dra7-atl-clock: Mark the device as pm_runtime_irq_safe Sebastian Andrzej Siewior (1): clk: ti: consider the fact that of_clk_get() might return an error Tero Kristo (2): clk: ti: change clock init to use generic of_clk_init clk: ti: dra7-atl-clock: fix a memory leak arch/arm/mach-omap2/io.c | 12 +-- arch/arm/mach-omap2/prm_common.c |2 -- drivers/clk/ti/clk-dra7-atl.c|2 ++ drivers/clk/ti/clk.c | 68 -- drivers/clk/ti/clockdomain.c |5 +++ drivers/clk/ti/divider.c |4 +-- include/linux/clk/ti.h |1 + 7 files changed, 63 insertions(+), 31 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clk: prevent erronous parsing of children during rate change
Quoting Tero Kristo (2014-09-29 01:09:24) On 09/27/2014 02:24 AM, Mike Turquette wrote: Quoting Tero Kristo (2014-09-26 00:18:55) On 09/26/2014 04:35 AM, Stephen Boyd wrote: On 09/23/14 06:38, Tero Kristo wrote: On 09/22/2014 10:18 PM, Stephen Boyd wrote: On 08/21, Tero Kristo wrote: /* Skip children who will be reparented to another clock */ if (child-new_parent child-new_parent != clk) continue; Are we not hitting the new_parent check here? I don't understand how we can be changing parents here unless the check is being avoided, in which case I wonder why determine_rate isn't being used. It depends how the clock underneath handles the situation. The error I am seeing actually happens with a SoC specific compound clock (DPLL) which integrates set_rate + mux functionality into a single clock node. A call to the clk_set_rate changes the parent of this clock (from bypass clock to reference clock), in addition to changing the rate (tune the mul+div.) I looked at using the determine rate call with this type but it breaks everything up... the parent gets changed but not the clock rate, in addition to some other issues. Ok. Is this omap3_noncore_dpll_set_rate()? Yes. Can we use determine_rate + clk_set_parent_and_rate()? At least clk_set_parent_and_rate() would allow us to do the mult+div and the parent in the same op call, although I don't understand why setting the parent and then setting the rate is not going to work. Well, setting parent first, then rate later causes problems with the DPLL ending up running with illegal (non-specified) rate, the M+N values are most likely wrong if you just switch from bypass clock to reference clock first without programming the M+N first. I took a quick look and it still seems to me that the OMAP DPLLs are still not modeled properly as mux clocks. Is this correct? Yeah, they are not mux clocks, but rather a compound of mux + DPLL multiplier/divider logic. Changing the DPLL to be a separate mux + DPLL div/mult clock will still have overlapping usage of the DPLL_EN field, I'm not talking about splitting up the clock into two separate clocks. If memory serves the DPLL clock implementation cheats and hides the bypass_clk info from the clock framework. To be explicit, from the perspective of Linux clock framework DPLL clocks only have one parent. In reality a typical DPLL should have at least 2 parents (and in some cases starting with OMAP4, some of the DPLL output clocks should have a second HSD parent). But the implementation does not reflect this. as the DPLL must be in bypass mode during M+N change. Or, should the DPLL rate change only be allowed if the mux is in bypass setting? Several drivers still depend on direct dpll clk_set_rate working 'properly' (there are some other issues currently present also which have nothing to do with the mux behavior.) This issue has been lingering for a long time and we can't use determine_rate unless that clock has multiple parents. Simply hacking knowledge of the parent bypass clock into the .set_rate callback is not enough. If you believe this _must_ be changed, I can take a look at this for next merge window, but this will cause a DT data compatibility break if nothing else (personally I don't care about this as I always rebuild DT blob with kernel, but lots of other people seem to do.) Well I guess the question is how long will we put up with the many small headaches caused by incorrectly modeling the clock? determine_rate and clk_set_parent_and_rate should be sufficient for the OMAP DPLLs but only if they are correctly modeled in the framework. Regards, Mike -Tero Regards, Mike I'm interested in the other issues that you mentioned too. Mostly these were side-effects from the illegal DPLL setup I guess, like boot hang, failed drivers etc. I didn't really investigate this that much as it is much more simpler just to use safe list iteration here. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clk: prevent erronous parsing of children during rate change
Quoting Tero Kristo (2014-09-30 01:48:49) On 09/30/2014 10:07 AM, Mike Turquette wrote: Quoting Tero Kristo (2014-09-29 01:09:24) On 09/27/2014 02:24 AM, Mike Turquette wrote: Quoting Tero Kristo (2014-09-26 00:18:55) On 09/26/2014 04:35 AM, Stephen Boyd wrote: On 09/23/14 06:38, Tero Kristo wrote: On 09/22/2014 10:18 PM, Stephen Boyd wrote: On 08/21, Tero Kristo wrote: /* Skip children who will be reparented to another clock */ if (child-new_parent child-new_parent != clk) continue; Are we not hitting the new_parent check here? I don't understand how we can be changing parents here unless the check is being avoided, in which case I wonder why determine_rate isn't being used. It depends how the clock underneath handles the situation. The error I am seeing actually happens with a SoC specific compound clock (DPLL) which integrates set_rate + mux functionality into a single clock node. A call to the clk_set_rate changes the parent of this clock (from bypass clock to reference clock), in addition to changing the rate (tune the mul+div.) I looked at using the determine rate call with this type but it breaks everything up... the parent gets changed but not the clock rate, in addition to some other issues. Ok. Is this omap3_noncore_dpll_set_rate()? Yes. Can we use determine_rate + clk_set_parent_and_rate()? At least clk_set_parent_and_rate() would allow us to do the mult+div and the parent in the same op call, although I don't understand why setting the parent and then setting the rate is not going to work. Well, setting parent first, then rate later causes problems with the DPLL ending up running with illegal (non-specified) rate, the M+N values are most likely wrong if you just switch from bypass clock to reference clock first without programming the M+N first. I took a quick look and it still seems to me that the OMAP DPLLs are still not modeled properly as mux clocks. Is this correct? Yeah, they are not mux clocks, but rather a compound of mux + DPLL multiplier/divider logic. Changing the DPLL to be a separate mux + DPLL div/mult clock will still have overlapping usage of the DPLL_EN field, I'm not talking about splitting up the clock into two separate clocks. If memory serves the DPLL clock implementation cheats and hides the bypass_clk info from the clock framework. To be explicit, from the perspective of Linux clock framework DPLL clocks only have one parent. In reality a typical DPLL should have at least 2 parents (and in some cases starting with OMAP4, some of the DPLL output clocks should have a second HSD parent). But the implementation does not reflect this. No, this is not the DPLLs are modelled. Each DPLL has currently two parents, ref-clk and bypass-clk, which are both modelled as separate clock nodes, and the DPLL switches parents based on bypass/lock mode. The bypass clock is also usually a mux clock, which further selects separate bypass parent, resulting in 3 or more parents for a certain DPLL. I stand corrected. I thought it was still done the old way where the machine-specific clock struct was holding the pointer to the ref_clk and bypass_clk. I'm glad that is not the case any more. as the DPLL must be in bypass mode during M+N change. Or, should the DPLL rate change only be allowed if the mux is in bypass setting? Several drivers still depend on direct dpll clk_set_rate working 'properly' (there are some other issues currently present also which have nothing to do with the mux behavior.) This issue has been lingering for a long time and we can't use determine_rate unless that clock has multiple parents. Simply hacking knowledge of the parent bypass clock into the .set_rate callback is not enough. If you believe this _must_ be changed, I can take a look at this for next merge window, but this will cause a DT data compatibility break if nothing else (personally I don't care about this as I always rebuild DT blob with kernel, but lots of other people seem to do.) Well I guess the question is how long will we put up with the many small headaches caused by incorrectly modeling the clock? Well, its not kind of incorrectly modelled, it is just modelled in such way that clk_set_rate doesn't cope too well with it. determine_rate and clk_set_parent_and_rate should be sufficient for the OMAP DPLLs but only if they are correctly modeled in the framework. Do we have implementation for clk_set_parent_and_rate someplace? I looked at rc7 and didn't find this. I think this would fix the issues I am seeing combined with determine_rate, if clk_set_rate would internally handle changing both rate + parent. I made it hard for you to find it because I typo'd. It's not a clk api but a clk_op: int (*set_rate_and_parent)(struct clk_hw *hw, unsigned long rate
Re: [PATCH] clk: prevent erronous parsing of children during rate change
Quoting Tero Kristo (2014-09-26 00:18:55) On 09/26/2014 04:35 AM, Stephen Boyd wrote: On 09/23/14 06:38, Tero Kristo wrote: On 09/22/2014 10:18 PM, Stephen Boyd wrote: On 08/21, Tero Kristo wrote: /* Skip children who will be reparented to another clock */ if (child-new_parent child-new_parent != clk) continue; Are we not hitting the new_parent check here? I don't understand how we can be changing parents here unless the check is being avoided, in which case I wonder why determine_rate isn't being used. It depends how the clock underneath handles the situation. The error I am seeing actually happens with a SoC specific compound clock (DPLL) which integrates set_rate + mux functionality into a single clock node. A call to the clk_set_rate changes the parent of this clock (from bypass clock to reference clock), in addition to changing the rate (tune the mul+div.) I looked at using the determine rate call with this type but it breaks everything up... the parent gets changed but not the clock rate, in addition to some other issues. Ok. Is this omap3_noncore_dpll_set_rate()? Yes. Can we use determine_rate + clk_set_parent_and_rate()? At least clk_set_parent_and_rate() would allow us to do the mult+div and the parent in the same op call, although I don't understand why setting the parent and then setting the rate is not going to work. Well, setting parent first, then rate later causes problems with the DPLL ending up running with illegal (non-specified) rate, the M+N values are most likely wrong if you just switch from bypass clock to reference clock first without programming the M+N first. I took a quick look and it still seems to me that the OMAP DPLLs are still not modeled properly as mux clocks. Is this correct? This issue has been lingering for a long time and we can't use determine_rate unless that clock has multiple parents. Simply hacking knowledge of the parent bypass clock into the .set_rate callback is not enough. Regards, Mike I'm interested in the other issues that you mentioned too. Mostly these were side-effects from the illegal DPLL setup I guess, like boot hang, failed drivers etc. I didn't really investigate this that much as it is much more simpler just to use safe list iteration here. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clk: add gpio gated clock
Quoting Jyri Sarha (2014-09-11 01:44:24) On 09/10/2014 01:14 AM, Mike Turquette wrote: Quoting Jyri Sarha (2014-09-05 05:21:34) The added gpio-gate-clock is a basic clock that can be enabled and disabled trough a gpio output. The DT binding document for the clock is also added. For EPROBE_DEFER handling the registering of the clock has to be delayed until of_clk_get() call time. Signed-off-by: Jyri Sarha jsa...@ti.com --- This is my final attempt to get this generic gpio controlled basic clock into mainline. Of course I gladly fix any issues that the patch may have. However, if there is no response, I give up and move it to TI specific clocks. I searched through my archives and found a post from January. You Cc'd me as mturque...@linaro.org. Note that the address is wrapped in chevrons but there is no name string (e.g. Mike Turquette). My mailer doesn't parse this well it was not flagged as to:me in my filters. Maybe other mailers handle this better? If you leave out the name string in the future then it would probably be best to drop the chevrons. Then git send-email adds the chevrons, but in the future I'll put the name string there too. I've been sending this patch as a part of Beaglebone-Black HDMI audio patch series since last autumn. Since the previous version I have done some minor cleanups and changed the clock's compatible property from gpio-clock to gpio-gate-clock. All the file names, comments, etc. have also been changed accordingly. Is your platform the only one to take advantage of this clock type so far? I feel that it is esoteric enough that it shouldn't be made generic. The main reason is that all of the generic clock types needs to be overhauled at some point. E.g. the clk-gate should have its machine-specific logic separated from its machine-independent logic. If the gate clock were to populate .enable and .disable callbacks and then leave the actual register banging, or regmap'ing, or gpio'ing up to your backend driver then that would be a big improvement and would avoid the need to create this new clock type outright. So that's on my todo list, but it's not done yet. For your patch I think that putting this code into drivers/clk/ti would probably be best, unless other folks could use it as-is. Even if others could use it today I would want to remove it eventually for the reasons stated in the paragraph above. Ok, I see. I do not know of anybody else needing a gpio gate clock at the moment. I'll put the driver under drivers/clk/ti unless someone comes forward soon. Well nobody came forward but after thinking about it I've seen this design elsewhere, so it should probably be generic. And the underlying machine-specific ops are less relevant to this type since most of that is abstracted away behind the GPIO api. Applied to clk-next. Let me know if that causes a problem for you if you have merged this into the TI clk stuff. Regards, Mike Thanks, Jyri -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/5] clk: ti: add ti,gpio-gate-clock controlled clock
Quoting Tomi Valkeinen (2014-09-19 06:25:48) On 19/09/14 16:12, Nishanth Menon wrote: On 09/19/2014 08:07 AM, Tomi Valkeinen wrote: On 16/09/14 23:40, Jyri Sarha wrote: The added ti,gpio-gate-clock is a basic clock that can be enabled and disabled trough a gpio output. The DT binding document for the clock is also added. For EPROBE_DEFER handling the registering of the clock has to be delayed until of_clk_get() call time. Signed-off-by: Jyri Sarha jsa...@ti.com --- .../bindings/clock/ti/gpio-gate-clock.txt | 21 ++ drivers/clk/ti/Makefile|2 +- drivers/clk/ti/gpio.c | 202 3 files changed, 224 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt create mode 100644 drivers/clk/ti/gpio.c Why is this a TI clock? Sounds like a generic one to me. Like thread: https://lkml.org/lkml/2014/9/5/284 ? Right, I should've read the earlier versions before making any smart comments =). No supporters cropped up for the generic gpio clock, but the design is common enough to merit a common clock type. And all of that stuff I said about the machine-specific ops isn't that relevant since it is hidden behing the gpio api. Regards, Mike Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] clk: Remove .owner field for driver
Quoting Kiran Padwal (2014-09-24 02:45:29)
There is no need to init .owner field.
Based on the patch from Peter Griffin peter.grif...@linaro.org
mmc: remove .owner field for drivers using module_platform_driver
This patch removes the superflous .owner field for drivers which
use the module_platform_driver API, as this is overriden in
platform_driver_register anyway.
Signed-off-by: Kiran Padwal kiran.pad...@smartplayin.com
Applied to clk-next.
Regards,
Mike
---
drivers/clk/clk-axi-clkgen.c |1 -
drivers/clk/clk-max77686.c |1 -
drivers/clk/clk-max77802.c |1 -
drivers/clk/clk-palmas.c |1 -
drivers/clk/clk-twl6040.c|1 -
drivers/clk/clk-wm831x.c |1 -
drivers/clk/qcom/mmcc-apq8084.c |1 -
drivers/clk/qcom/mmcc-msm8960.c |1 -
drivers/clk/qcom/mmcc-msm8974.c |1 -
drivers/clk/samsung/clk-s3c2410-dclk.c |1 -
drivers/clk/sunxi/clk-sun6i-apb0-gates.c |1 -
drivers/clk/sunxi/clk-sun6i-apb0.c |1 -
drivers/clk/sunxi/clk-sun6i-ar100.c |1 -
drivers/clk/sunxi/clk-sun8i-apb0.c |1 -
drivers/clk/ti/clk-dra7-atl.c|1 -
15 files changed, 15 deletions(-)
diff --git a/drivers/clk/clk-axi-clkgen.c b/drivers/clk/clk-axi-clkgen.c
index 1127ee4..e619285 100644
--- a/drivers/clk/clk-axi-clkgen.c
+++ b/drivers/clk/clk-axi-clkgen.c
@@ -544,7 +544,6 @@ static int axi_clkgen_remove(struct platform_device *pdev)
static struct platform_driver axi_clkgen_driver = {
.driver = {
.name = adi-axi-clkgen,
- .owner = THIS_MODULE,
.of_match_table = axi_clkgen_ids,
},
.probe = axi_clkgen_probe,
diff --git a/drivers/clk/clk-max77686.c b/drivers/clk/clk-max77686.c
index ed0beb4..86cdb3a 100644
--- a/drivers/clk/clk-max77686.c
+++ b/drivers/clk/clk-max77686.c
@@ -73,7 +73,6 @@ MODULE_DEVICE_TABLE(platform, max77686_clk_id);
static struct platform_driver max77686_clk_driver = {
.driver = {
.name = max77686-clk,
- .owner = THIS_MODULE,
},
.probe = max77686_clk_probe,
.remove = max77686_clk_remove,
diff --git a/drivers/clk/clk-max77802.c b/drivers/clk/clk-max77802.c
index 8e480c5..0729dc7 100644
--- a/drivers/clk/clk-max77802.c
+++ b/drivers/clk/clk-max77802.c
@@ -84,7 +84,6 @@ MODULE_DEVICE_TABLE(platform, max77802_clk_id);
static struct platform_driver max77802_clk_driver = {
.driver = {
.name = max77802-clk,
- .owner = THIS_MODULE,
},
.probe = max77802_clk_probe,
.remove = max77802_clk_remove,
diff --git a/drivers/clk/clk-palmas.c b/drivers/clk/clk-palmas.c
index 781630e..8d45992 100644
--- a/drivers/clk/clk-palmas.c
+++ b/drivers/clk/clk-palmas.c
@@ -292,7 +292,6 @@ static int palmas_clks_remove(struct platform_device
*pdev)
static struct platform_driver palmas_clks_driver = {
.driver = {
.name = palmas-clk,
- .owner = THIS_MODULE,
.of_match_table = palmas_clks_of_match,
},
.probe = palmas_clks_probe,
diff --git a/drivers/clk/clk-twl6040.c b/drivers/clk/clk-twl6040.c
index 1ada79a..4a75513 100644
--- a/drivers/clk/clk-twl6040.c
+++ b/drivers/clk/clk-twl6040.c
@@ -112,7 +112,6 @@ static int twl6040_clk_remove(struct platform_device
*pdev)
static struct platform_driver twl6040_clk_driver = {
.driver = {
.name = twl6040-clk,
- .owner = THIS_MODULE,
},
.probe = twl6040_clk_probe,
.remove = twl6040_clk_remove,
diff --git a/drivers/clk/clk-wm831x.c b/drivers/clk/clk-wm831x.c
index b131041..ef67719 100644
--- a/drivers/clk/clk-wm831x.c
+++ b/drivers/clk/clk-wm831x.c
@@ -395,7 +395,6 @@ static struct platform_driver wm831x_clk_driver = {
.probe = wm831x_clk_probe,
.driver = {
.name = wm831x-clk,
- .owner = THIS_MODULE,
},
};
diff --git a/drivers/clk/qcom/mmcc-apq8084.c b/drivers/clk/qcom/mmcc-apq8084.c
index 751eea3..dab988a 100644
--- a/drivers/clk/qcom/mmcc-apq8084.c
+++ b/drivers/clk/qcom/mmcc-apq8084.c
@@ -3341,7 +3341,6 @@ static struct platform_driver mmcc_apq8084_driver = {
.remove = mmcc_apq8084_remove,
.driver = {
.name = mmcc-apq8084,
- .owner = THIS_MODULE,
.of_match_table = mmcc_apq8084_match_table,
},
};
diff --git a/drivers/clk/qcom/mmcc-msm8960.c b/drivers/clk/qcom/mmcc-msm8960.c
index 2e80a21..68da36c 100644
--- a/drivers/clk/qcom/mmcc-msm8960.c
+++ b/drivers/clk/qcom/mmcc-msm8960.c
@@ -2679,7 +2679,6 @@ static struct platform_driver mmcc_msm8960_driver = {
.remove = mmcc_msm8960_remove,
.driver
Re: [PATCH] clk: add gpio gated clock
Quoting Jyri Sarha (2014-09-05 05:21:34)
The added gpio-gate-clock is a basic clock that can be enabled and
disabled trough a gpio output. The DT binding document for the clock
is also added. For EPROBE_DEFER handling the registering of the clock
has to be delayed until of_clk_get() call time.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
This is my final attempt to get this generic gpio controlled basic
clock into mainline. Of course I gladly fix any issues that the patch
may have. However, if there is no response, I give up and move it to TI
specific clocks.
I searched through my archives and found a post from January. You Cc'd
me as mturque...@linaro.org. Note that the address is wrapped in
chevrons but there is no name string (e.g. Mike Turquette).
My mailer doesn't parse this well it was not flagged as to:me in my
filters. Maybe other mailers handle this better? If you leave out the
name string in the future then it would probably be best to drop the
chevrons.
I've been sending this patch as a part of Beaglebone-Black HDMI audio
patch series since last autumn. Since the previous version I have done
some minor cleanups and changed the clock's compatible property from
gpio-clock to gpio-gate-clock. All the file names, comments,
etc. have also been changed accordingly.
Is your platform the only one to take advantage of this clock type so
far? I feel that it is esoteric enough that it shouldn't be made
generic.
The main reason is that all of the generic clock types needs to be
overhauled at some point. E.g. the clk-gate should have its
machine-specific logic separated from its machine-independent logic. If
the gate clock were to populate .enable and .disable callbacks and then
leave the actual register banging, or regmap'ing, or gpio'ing up to your
backend driver then that would be a big improvement and would avoid the
need to create this new clock type outright.
So that's on my todo list, but it's not done yet. For your patch I think
that putting this code into drivers/clk/ti would probably be best,
unless other folks could use it as-is. Even if others could use it today
I would want to remove it eventually for the reasons stated in the
paragraph above.
Regards,
Mike
Best regards,
Jyri
.../devicetree/bindings/clock/gpio-gate-clock.txt | 21 ++
drivers/clk/Makefile |1 +
drivers/clk/clk-gpio-gate.c| 204
include/linux/clk-provider.h | 22 +++
4 files changed, 248 insertions(+)
create mode 100644
Documentation/devicetree/bindings/clock/gpio-gate-clock.txt
create mode 100644 drivers/clk/clk-gpio-gate.c
diff --git a/Documentation/devicetree/bindings/clock/gpio-gate-clock.txt
b/Documentation/devicetree/bindings/clock/gpio-gate-clock.txt
new file mode 100644
index 000..d3379ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/gpio-gate-clock.txt
@@ -0,0 +1,21 @@
+Binding for simple gpio gated clock.
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be gpio-gate-clock.
+- #clock-cells : from common clock binding; shall be set to 0.
+- enable-gpios : GPIO reference for enabling and disabling the clock.
+
+Optional properties:
+- clocks: Maximum of one parent clock is supported.
+
+Example:
+ clock {
+ compatible = gpio-gate-clock;
+ clocks = parentclk;
+ #clock-cells = 0;
+ enable-gpios = gpio 1 GPIO_ACTIVE_HIGH;
+ };
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index f537a0b..5d78710 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_COMMON_CLK)+= clk-gate.o
obj-$(CONFIG_COMMON_CLK) += clk-mux.o
obj-$(CONFIG_COMMON_CLK) += clk-composite.o
obj-$(CONFIG_COMMON_CLK) += clk-fractional-divider.o
+obj-$(CONFIG_COMMON_CLK) += clk-gpio-gate.o
ifeq ($(CONFIG_OF), y)
obj-$(CONFIG_COMMON_CLK) += clk-conf.o
endif
diff --git a/drivers/clk/clk-gpio-gate.c b/drivers/clk/clk-gpio-gate.c
new file mode 100644
index 000..9dde885
--- /dev/null
+++ b/drivers/clk/clk-gpio-gate.c
@@ -0,0 +1,204 @@
+/*
+ * Copyright (C) 2013 - 2014 Texas Instruments Incorporated -
http://www.ti.com
+ * Author: Jyri Sarha jsa...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Gpio gated clock implementation
+ */
+
+#include linux/clk-provider.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/gpio.h
+#include linux/of_gpio.h
+#include linux/err.h
+#include linux/device.h
+
+/**
+ * DOC: basic gpio gated clock which can be enabled and disabled
+ * with gpio output
Re: [PATCH] clk: prevent erronous parsing of children during rate change
Quoting Tero Kristo (2014-08-21 06:47:45)
In some cases, clocks can switch their parent with clk_set_rate, for
example clk_mux can do this in some cases. Current implementation of
clk_change_rate uses un-safe list iteration on the clock children, which
will cause wrong clocks to be parsed in case any of the clock children
change their parents during the change rate operation. Fixed by using
the safe list iterator instead.
The problem was detected due to some divide by zero errors generated
by clock init on dra7-evm board, see discussion under
http://article.gmane.org/gmane.linux.ports.arm.kernel/349180 for details.
Signed-off-by: Tero Kristo t-kri...@ti.com
To: Mike Turquette mturque...@linaro.org
Reported-by: Nishanth Menon n...@ti.com
Applied to clk-fixes.
Thanks!
Mike
---
drivers/clk/clk.c |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index b76fa69..bacc06f 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1467,6 +1467,7 @@ static struct clk *clk_propagate_rate_change(struct clk
*clk, unsigned long even
static void clk_change_rate(struct clk *clk)
{
struct clk *child;
+ struct hlist_node *tmp;
unsigned long old_rate;
unsigned long best_parent_rate = 0;
bool skip_set_rate = false;
@@ -1502,7 +1503,11 @@ static void clk_change_rate(struct clk *clk)
if (clk-notifier_count old_rate != clk-rate)
__clk_notify(clk, POST_RATE_CHANGE, old_rate, clk-rate);
- hlist_for_each_entry(child, clk-children, child_node) {
+ /*
+* Use safe iteration, as change_rate can actually swap parents
+* for certain clock types.
+*/
+ hlist_for_each_entry_safe(child, tmp, clk-children, child_node) {
/* Skip children who will be reparented to another clock */
if (child-new_parent child-new_parent != clk)
continue;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/1] ARM: OMAP: add external clock provider support
Quoting Tero Kristo (2014-08-04 05:36:19) On 08/04/2014 02:37 PM, Peter Ujfalusi wrote: On 08/01/2014 04:15 PM, Tero Kristo wrote: Hi, This patch adds possibility to register external clocks (outside the main SoC) on TI boards through device tree. Clock sources as such include for example twl-6030 / twl-6040 chips and variants which can be used to clock for example audio / WLAN chips. Just one question to Mike and Tero: would it be possible to have generic binding for such an external clocks? We have the palmas clock driver already upstream which handles the 32K clocks from the PMIC. Palmas class of PMICs can be used with TI/nVidia(/Intel?) platforms. We use Palmas on omap5-uevm, DRA7-EVM also uses Palmas compatible PMIC and some nVidia platform also uses this class of devices (and they all need to have control over the 32K clock(s)). Other platforms initialize their clocks in different manner, they can use generic of_clk_init I believe. If they can't use that for some reason, then they need to implement something similar to this. Right. To answer Peter's question, we do have a generic binding, it is the clock binding ;-) Even the idea of having a TI clock provider isn't really a good way to do things. IP blocks that generate clocks are clock providers, not companies. As such if Palmas or Gaia or whatever generate clocks then we don't need any new infrastructure in the clock core to accomodate this. Those drivers simply need to include clk-provider.h and register their clocks with the framework. Some good examples of this are the omap3-isp.c driver, and qcom's hdmi phy driver (sorry, don't have the path handy) which both consume clocks generated by other clock providers, and they provide their own clocks which are generated within their own IP/module. A big part of the design of the ccf (and later, the DT bindings) is that we do not need a centralized place to store every piece of clock generation knowledge and clock routing knowledge. Regards, Mike -Tero This patch can be queued once someone has a use-case + patches that requires usage of such clocks. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clk: ti: clk-7xx: Correct ABE DPLL configuration
Quoting Tero Kristo (2014-07-30 05:27:07) On 07/30/2014 08:53 AM, Peter Ujfalusi wrote: On 07/29/2014 07:12 PM, Mike Turquette wrote: Oh yea, seems this got lost into the myriad of branches I have. I can push this on top of my for-v3.17/ti-clk-drv if you like. That is the easiest thing for me. I think that Peter wanted to take this as a fix for 3.16 though. Peter is that correct? Yes, it would have been better to have it in 3.16 along with the DRA7 ATL clock driver. W/O this patch the ATL will not going to be usable since the ABE DPLL is set too high to be usable for it's purpose. Ok, this is now pushed on top of the for-v3.17/ti-clk-driver branch in my git-repo. Mike, do you want a new pull-req for this just in case? I've picked it manually and applied on top of 3.16-rc7 for a last minute fix. I can add your Ack if you like. Regards, Mike -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clk: ti: clk-7xx: Correct ABE DPLL configuration
Quoting Peter Ujfalusi (2014-07-14 03:10:28) On 05/06/2014 04:39 PM, Peter Ujfalusi wrote: Tero: can I have your ack for this patch or do you have further concerns? Yea looks good to me, except for the fact that there is some work on getting default rate/parent support through DT. I would like a comment from Mike about the estimate when this can get in, and whether we should merge intermediate solutions still like this. Tero, On May 19 you said, Thanks, queued for 3.16/ti-clk-drv. but I never received that as part of the TI clock fixes. :-( I've taken Sylwester's patch in for the DT-based assigned clock rates and parents. You can find it in clk-next. (maybe you are still on vacation? I don't know...) Anyway, you can consider this patch acked by me, I'll let Mike to decide what to do with it though. Do you have anything against this patch? Since right now there is no other ways to fix the ABE DPLL for dra7 it would be great if we could have this in till we have the final solution. Also I'd like to point out that the original frequency the ABE DPLL was not correct and renders the audio to be not usable on the platform. Mike: can we have this patch still pushed for 3.16? I can resend it right away if you lost the original patch. Peter, I have your original patch. No need to resend. Let's see if Tero comments this week, otherwise I can take it with his previously supplied Ack and send it off. Probably needs to be sent by Thursday at the latest. Regards, Mike Thanks, Péter -Tero Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- drivers/clk/ti/clk-7xx.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c index f7e40734c819..19a55bf407dd 100644 --- a/drivers/clk/ti/clk-7xx.c +++ b/drivers/clk/ti/clk-7xx.c @@ -16,7 +16,7 @@ #include linux/clkdev.h #include linux/clk/ti.h -#define DRA7_DPLL_ABE_DEFFREQ361267200 +#define DRA7_DPLL_ABE_DEFFREQ180633600 #define DRA7_DPLL_GMAC_DEFFREQ10 @@ -322,6 +322,11 @@ int __init dra7xx_dt_clk_init(void) if (rc) pr_err(%s: failed to configure ABE DPLL!\n, __func__); +dpll_ck = clk_get_sys(NULL, dpll_abe_m2x2_ck); +rc = clk_set_rate(dpll_ck, DRA7_DPLL_ABE_DEFFREQ * 2); +if (rc) +pr_err(%s: failed to configure ABE DPLL m2x2!\n, __func__); + dpll_ck = clk_get_sys(NULL, dpll_gmac_ck); rc = clk_set_rate(dpll_ck, DRA7_DPLL_GMAC_DEFFREQ); if (rc) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clk: ti: clk-7xx: Correct ABE DPLL configuration
On Tue, Jul 29, 2014 at 1:23 AM, Tero Kristo t-kri...@ti.com wrote: On 07/29/2014 09:27 AM, Mike Turquette wrote: Quoting Peter Ujfalusi (2014-07-14 03:10:28) On 05/06/2014 04:39 PM, Peter Ujfalusi wrote: Tero: can I have your ack for this patch or do you have further concerns? Yea looks good to me, except for the fact that there is some work on getting default rate/parent support through DT. I would like a comment from Mike about the estimate when this can get in, and whether we should merge intermediate solutions still like this. Tero, On May 19 you said, Thanks, queued for 3.16/ti-clk-drv. but I never received that as part of the TI clock fixes. :-( I've taken Sylwester's patch in for the DT-based assigned clock rates and parents. You can find it in clk-next. (maybe you are still on vacation? I don't know...) Anyway, you can consider this patch acked by me, I'll let Mike to decide what to do with it though. Do you have anything against this patch? Since right now there is no other ways to fix the ABE DPLL for dra7 it would be great if we could have this in till we have the final solution. Also I'd like to point out that the original frequency the ABE DPLL was not correct and renders the audio to be not usable on the platform. Mike: can we have this patch still pushed for 3.16? I can resend it right away if you lost the original patch. Peter, I have your original patch. No need to resend. Let's see if Tero comments this week, otherwise I can take it with his previously supplied Ack and send it off. Probably needs to be sent by Thursday at the latest. Oh yea, seems this got lost into the myriad of branches I have. I can push this on top of my for-v3.17/ti-clk-drv if you like. That is the easiest thing for me. I think that Peter wanted to take this as a fix for 3.16 though. Peter is that correct? Regards, Mike -Tero Regards, Mike Thanks, Péter -Tero Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- drivers/clk/ti/clk-7xx.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c index f7e40734c819..19a55bf407dd 100644 --- a/drivers/clk/ti/clk-7xx.c +++ b/drivers/clk/ti/clk-7xx.c @@ -16,7 +16,7 @@ #include linux/clkdev.h #include linux/clk/ti.h -#define DRA7_DPLL_ABE_DEFFREQ361267200 +#define DRA7_DPLL_ABE_DEFFREQ180633600 #define DRA7_DPLL_GMAC_DEFFREQ10 @@ -322,6 +322,11 @@ int __init dra7xx_dt_clk_init(void) if (rc) pr_err(%s: failed to configure ABE DPLL!\n, __func__); +dpll_ck = clk_get_sys(NULL, dpll_abe_m2x2_ck); +rc = clk_set_rate(dpll_ck, DRA7_DPLL_ABE_DEFFREQ * 2); +if (rc) +pr_err(%s: failed to configure ABE DPLL m2x2!\n, __func__); + dpll_ck = clk_get_sys(NULL, dpll_gmac_ck); rc = clk_set_rate(dpll_ck, DRA7_DPLL_GMAC_DEFFREQ); if (rc) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/13] ARM: OMAP2+: clock cleanup series for 3.17
Quoting Tero Kristo (2014-07-02 01:47:34) Hi, This sets cleans up some of the omap specific clock drivers still residing under arch/arm/mach-omap2. This set is done in preparation to migrate these drivers eventually under drivers/clk/ti, where we don't have access to certain board specific functionality. The basic idea of this set is to introduce clk_features struct which contains any SoC specific data / flags within it, and this is used runtime instead of the current cpu_is_? checks. Reviewed-by: Mike Turquette mturque...@linaro.org There are also a couple of bug fixes introduced in this set: - Patch #1 : fix potential overflow in _dpll_test_fint - Patch #8 : embeds a fix for checking omap5/dra7 for the bypass modes also Set tested on following boards: - omap2430-sdp : boot - omap3-beagle : boot / suspend - omap4-panda-es : boot / suspend - omap5-uevm : boot - dra7-evm : boot Branch also available: tree: https://github.com/t-kristo/linux-pm.git branch: for-v3.17/omap2-clk-cleanup -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] clk: ti: set CLK_SET_RATE_NO_REPARENT for ti,mux-clock
Quoting Tero Kristo (2014-07-03 00:41:22)
On 07/01/2014 10:48 PM, Felipe Balbi wrote:
Hi,
On Thu, Jun 19, 2014 at 02:33:14PM +0300, Tero Kristo wrote:
On 06/17/2014 11:04 AM, Tomi Valkeinen wrote:
When setting the rate of a clock, by default the clock framework will
change the parent of the clock to the most suitable one in
__clk_mux_determine_rate() (most suitable by looking at the clock rate).
This is a rather dangerous default, and causes problems on AM43x when
using display and ethernet. There are multiple ways to select the clock
muxes on AM43x, and some of those clock paths have the same source
clocks for display and ethernet. When changing the clock rate for the
display subsystem, the clock framework decides to change the display mux
from the dedicated display PLL to a shared PLL which is used by the
ethernet, and then changes the rate of the shared PLL, breaking the
ethernet.
As I don't think there ever is a case where we want the clock framework
to automatically change the parent clock of a clock mux, this patch sets
the CLK_SET_RATE_NO_REPARENT for all ti,mux-clocks.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/clk/ti/mux.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/ti/mux.c b/drivers/clk/ti/mux.c
index 0197a478720c..e9d650e51287 100644
--- a/drivers/clk/ti/mux.c
+++ b/drivers/clk/ti/mux.c
@@ -160,7 +160,7 @@ static void of_mux_clk_setup(struct device_node *node)
u8 clk_mux_flags = 0;
u32 mask = 0;
u32 shift = 0;
- u32 flags = 0;
+ u32 flags = CLK_SET_RATE_NO_REPARENT;
num_parents = of_clk_get_parent_count(node);
if (num_parents 2) {
Thanks, queued for 3.16-rc fixes.
did you skip a few -rcs by any chance? Looks like this could've been
merged on v3.16-rc3... Just checking.
This goes through Mike's clk tree, so there is extra latency there. Not
sure when he plans to send next pull-req for clk-fixes to linux-master.
Expect it late next week as several new fixes pull requests have come
in. I merge those into clk-fixes, which then gets merged into clk-next
and all of that gets pulled into linux-next. After some cycles there and
testing on my end I send the fixes PR to Linus. So expect it to go
between -rc4 and -rc5.
Regards,
Mike
-Tero
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] clk: ti: add 'ti,round-rate' flag
Quoting Paul Walmsley (2014-06-13 12:53:06) Furthermore, as a general interface principle, allowing clk_set_rate() to silently round rates could lead to unexpected behavior, since the set of rates that clk_set_rate() can round to may change between the call to clk_round_rate() and the call to clk_set_rate(). Rounding the rate will always happen in a call to clk_set_rate. We need to know what rate that clock node can actually support. The real question is what do we do with that rounded rate. There are two options: 1) abort and return an error code if the rounded rate does not exactly match the requested rate 2) use the rounded rate even if it does not match the requested rate #2 has some variations worth considering: a) allow a rounded rate within a specified tolerance (e.g. 10% of the requested rate) b) allow a rounded rate so long as it is rounded down from the requested rate c) same as #b, but rounded up, etc. So again I think that the right way to deal with this is to: 1. avoid silently rounding rates in clk_set_rate() and to return an error if calling clk_set_rate() would result in a rate other than the one desired; and to Let's get consensus on my above question before we solidify the API. It's worth noting that the current behavior of rounding the rate within clk_set_rate is actually what Russell had in mind back in 2010. See this thread[1] for details. Also note that this opens up a can of worms regarding *intended rates*. For example, if you always abort clk_set_rate if the rounded rate does not match the requested rate, then what does that mean for a child clock that will be changed by some parent clock higher up the tree? If that child gets put to a rate that would never be returned by clk_round_rate then is the framework responsible for walking down the tree, checking every child and aborting when the first one is off by a few hertz? That's going to be messy. 2. modify clk_round_rate() such that it returns the closest lowest-or-equal rate match to the target rate requested. I agree that the behavior of clk_round_rate needs to be defined once and for all. I also think that clk_round_ceil, clk_round_floor and clk_round_exact aren't terrible ideas either. I'll kick off a thread on this topic shortly, and we can hopefully gain some consensus. Regards, Mike [1] https://lkml.org/lkml/2010/7/14/330 - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND 2/2] clk: Add driver for Palmas clk32kg and clk32kgaudio clocks
Quoting Peter Ujfalusi (2014-06-29 22:56:55)
Hi Javier,
On 06/27/2014 09:23 PM, Javier Martinez Canillas wrote:
Hello Peter,
On Fri, Jun 27, 2014 at 8:01 AM, Peter Ujfalusi peter.ujfal...@ti.com
wrote:
Palmas class of devices can provide 32K clock(s) to be used by other
devices
on the board. Depending on the actual device the provided clocks can be:
CLK32K_KG and CLK32K_KGAUDIO
or only one:
CLK32K_KG (TPS659039 for example)
Use separate compatible flags for the two 32K clock.
A system which needs or have only one of the 32k clock from
Palmas will need to add node(s) for each clock as separate section
in the dts file.
The two compatible property is:
ti,palmas-clk32kg for clk32kg clock
ti,palmas-clk32kgaudio for clk32kgaudio clock
Apart from the register control of the clocks - which is done via
the clock API there is a posibility to enable the external sleep
control. In this way the clock can be enabled/disabled on demand by the
user of the clock.
See the documentation for more details.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Reviewed-by: Nishanth Menon n...@ti.com
+static unsigned long palmas_clks_recalc_rate(struct clk_hw *hw,
+unsigned long parent_rate)
+{
+ return 32768;
+}
I see that other clock drivers using a constant rate return 0 if the
clock has not been enabled.
and there are examples when similar fixed clock drivers returns only the clock
value, like clk-max77686. I can not find clear guidelines neither in the
documentation or around the header/c files for this.
Mike, what is the appropriate way of handling the recalc_rate?
You are right that there are no guidelines stating, don't do that, but
please, don't do that ;-)
clk_enable and clk_set_rate are entirely unrelated operations from the
perspective of the Linux clock framework, and mixing these two classes
of operations is a recipe for pain.
So maybe is more correct to have something
like the following?
if (__clk_is_enabled(hw-clk))
return 32768;
else
return 0;
So what happens here if this is gateable clock and later on we call
clk_enable on it? The clocks rate will still be zero since
clk_enable/clk_disable do not touch the rate at all.
Regards,
Mike
Best regards,
Javier
--
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND 0/2] clk: Support for Palmas clk32kg and clk32kgaudio clocks
Quoting Peter Ujfalusi (2014-06-26 23:01:09) Hi Mike, This is a resend of the v2 version of the palmas clock driver which seamingly missed the 3.16 merge window. I have added Nishanth's Reviewed-by tag to the patches. Thanks for the resend. Applied to clk-next. Regards, Mike Changes since v1: - binding documentation and driver has been separated based on Nishanth Menon's comment v2 of the series: https://lkml.org/lkml/2014/5/6/323 v1 of the driver can be found: https://lkml.org/lkml/2014/4/3/104 Palmas class of devices can provide 32K clock(s) to be used by other devices on the board. Depending on the actual device the provided clocks can be: CLK32K_KG and CLK32K_KGAUDIO or only one: CLK32K_KG (TPS659039 for example) Use separate compatible flags for the two 32K clock. A system which needs or have only one of the 32k clock from Palmas will need to add node(s) for each clock as separate section in the dts file. The two compatible property is: ti,palmas-clk32kg for clk32kg clock ti,palmas-clk32kgaudio for clk32kgaudio clock Apart from the register control of the clocks - which is done via the clock API there is a posibility to enable the external sleep control. In this way the clock can be enabled/disabled on demand by the user of the clock. Regards, Peter --- Peter Ujfalusi (2): dt/bindings: Binding documentation for Palmas clk32kg and clk32kgaudio clocks clk: Add driver for Palmas clk32kg and clk32kgaudio clocks .../bindings/clock/clk-palmas-clk32kg-clocks.txt | 35 +++ drivers/clk/Kconfig| 7 + drivers/clk/Makefile | 1 + drivers/clk/clk-palmas.c | 307 + include/dt-bindings/mfd/palmas.h | 18 ++ 5 files changed, 368 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/clk-palmas-clk32kg-clocks.txt create mode 100644 drivers/clk/clk-palmas.c create mode 100644 include/dt-bindings/mfd/palmas.h -- 2.0.0 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] clk: ti: set CLK_SET_RATE_NO_REPARENT for ti,mux-clock
Quoting Paul Walmsley (2014-06-17 01:15:09) On Tue, 17 Jun 2014, Tomi Valkeinen wrote: When setting the rate of a clock, by default the clock framework will change the parent of the clock to the most suitable one in __clk_mux_determine_rate() (most suitable by looking at the clock rate). That is just insane. The patch description is insane. The framework has nothing to do with this dynamic re-parenting behavior and certainly the framework does not force this behavior on clock providers. This behavior is specific to users of __clk_mux_determine_rate. Those are: 1) drivers/clk/clk-mux.c 2) drivers/clk/qcom/mmcc-msm8960.c 3) drivers/clk/samsung/clk-s3c2410-dclk.c 4) drivers/clk/ti/mux.c If dynamic re-parenting by default doesn't work for your platform then you have two choices: 1) use the CLK_SET_RATE_NO_REPARENT flag (as this patch does) 2) don't use the basic divider type and write your own If you choose #2 then all you have to do when implementing .determine_rate is ignore the best_parent_rate argument. Finally when the .determine_rate callback was introduced (allowing dynamic re-parenting from a call to clk_set_rate) the CLK_SET_RATE_NO_REPARENT flag was applied to all affected users to maintain prior behavior and prevent regressions. I have some local patches to improve documentation around these areas for 3.17. Regards, Mike This is a rather dangerous default, and causes problems on AM43x when using display and ethernet. There are multiple ways to select the clock muxes on AM43x, and some of those clock paths have the same source clocks for display and ethernet. When changing the clock rate for the display subsystem, the clock framework decides to change the display mux from the dedicated display PLL to a shared PLL which is used by the ethernet, and then changes the rate of the shared PLL, breaking the ethernet. As I don't think there ever is a case where we want the clock framework to automatically change the parent clock of a clock mux, this patch sets the CLK_SET_RATE_NO_REPARENT for all ti,mux-clocks. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Reviewed-by: Paul Walmsley p...@pwsan.com - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] clk: ti: set CLK_SET_RATE_NO_REPARENT for ti,mux-clock
Quoting Tero Kristo (2014-06-17 01:23:31) On 06/17/2014 11:19 AM, Paul Walmsley wrote: On Tue, 17 Jun 2014, Tero Kristo wrote: I am fine with this approach, as it seems pretty much all the other mux-clock users are setting this flag also. The TI clocks have had this way of using mux clocks from the legacy times... might just be a design flaw. The non-CCF clock framework never automatically switched parents on rate changes, AFAIK. That might be true yea, so this must have been introduced with CCF. Correct, which is why the flag exists. The only case that approached this was with PLLs. PLLs would automatically be placed into bypass if the PLL rate was set to the bypass rate. Someone could argue that this is rather strange approach also and would be better to use some other API for the purpose. I have always liked this feature. I had a hack patch on the list a long time ago for testing bypass mode on the OMAP4 MPU when set to 400MHZ or something like that (and chained from dpll_core I think...). The point is to get the rate you ask for when you call clk_set_rate. The method by which the PLL achieves that rate isn't really important, so long as you have glitchless clocks (which OMAP's PRCM does). Regards, Mike .Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] clk: ti: add 'ti,round-rate' flag
Quoting Tomi Valkeinen (2014-05-15 05:25:37) On 15/05/14 09:08, Mike Turquette wrote: Quoting Tomi Valkeinen (2014-05-12 05:13:51) On 12/05/14 15:02, Tero Kristo wrote: On 05/08/2014 12:06 PM, Tomi Valkeinen wrote: The current DPLL code does not try to round the clock rate, and instead returns an error if the requested clock rate cannot be produced exactly by the DPLL. It could be argued that this is a bug, but as the current drivers may depend on that behavior, a new flag 'ti,round-rate' is added which enables clock rate rounding. Someone could probably argue that this flag is not a hardware feature, I fully agree. but instead is used to describe linux-kernel behavior, and would probably be frowned upon by the DT enthusiasts. Othen than that, I like this approach better than a global setting, but would like second opinions here. I think the dpll code should always do rounding. That's what round_rate() is supposed to do, afaik. The current behavior of not rounding and returning an error is a bug in my opinion. From include/linux/clk.h: /** * clk_round_rate - adjust a rate to the exact rate a clock can provide * @clk: clock source * @rate: desired clock rate in Hz * * Returns rounded clock rate in Hz, or negative errno. */ long clk_round_rate(struct clk *clk, unsigned long rate); Definitely not rounding the rate is a bug, with respect to the API definition. Has anyone tried making the new flag as the default behavior and seeing if anything breaks? The v1 of the patch fixed the rounding unconditionally: http://article.gmane.org/gmane.linux.ports.arm.kernel/295077 Paul wanted it optional so that existing drivers would not break. No one knows if there is such a driver, or what would the driver's code look like that would cause an issue. And, as I've pointed out in the above thread, as clk-divider driver doesn't an error code from the dpll driver, my opinion is that such drivers would not work even now. I like v1 more. In any case, I hope we'd get something merged ASAP so that we fix the display AM3xxx boards and we'd still have time to possibly find out if some other driver breaks. Resurrecting this thread. Can we reach a consensus? I prefer V1 as well for the reasons stated above, and also since ti,round-rate isn't really describing the hardware at all in DT. We can always see how it goes and fix it up afterwards when everything explodes. Regards, Mike Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3] arm: dts: am43x-clock: add tbclk data for ehrpwm.
On Mon, May 19, 2014 at 6:20 AM, Tero Kristo t-kri...@ti.com wrote:
On 05/05/2014 10:49 AM, Tero Kristo wrote:
On 05/01/2014 10:00 PM, Mike Turquette wrote:
Quoting Tero Kristo (2014-04-29 07:51:14)
On 04/29/2014 05:15 PM, Sourav Poddar wrote:
We need tbclk clock data for the functioning of ehrpwm
module. Hence, populating the required clock information
in clock dts file.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
Acked-by: Tero Kristo t-kri...@ti.com
Looks good to me.
Tero, just to be clear, are you planning on batching up OMAPish clock
patches and sending a pull request (once they have been reviewed on the
list)?
No, I haven't been planning on sending a pull-req, as I believe you
still want to ack the TI related clock driver patches yourself also. If
you want to change the setup I am of course willing to negotiate the
terms. :)
-Tero
So, based on our discussions, this is now queued for 3.15-rc/clk-dt.
I don't want to cross threads, so we'll work out the details of the
for-3.16 stuff in the Pending clock and hwmod patches thread.
However, after this next merge window I am happy to move to a pull
request-based model for OMAP clock patches, since things should slowly
start to settle down.
Regards,
Mike
-Tero
Thanks,
Mike
---
v2-v3
- correct bitshifting
arch/arm/boot/dts/am43xx-clocks.dtsi | 48
++
drivers/clk/ti/clk-43xx.c|6 +
2 files changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index 142009c..42d7b1f 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -87,6 +87,54 @@
clock-mult = 1;
clock-div = 1;
};
+
+ ehrpwm0_tbclk: ehrpwm0_tbclk {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = dpll_per_m2_ck;
+ ti,bit-shift = 0;
+ reg = 0x0664;
+ };
+
+ ehrpwm1_tbclk: ehrpwm1_tbclk {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = dpll_per_m2_ck;
+ ti,bit-shift = 1;
+ reg = 0x0664;
+ };
+
+ ehrpwm2_tbclk: ehrpwm2_tbclk {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = dpll_per_m2_ck;
+ ti,bit-shift = 2;
+ reg = 0x0664;
+ };
+
+ ehrpwm3_tbclk: ehrpwm3_tbclk {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = dpll_per_m2_ck;
+ ti,bit-shift = 4;
+ reg = 0x0664;
+ };
+
+ ehrpwm4_tbclk: ehrpwm4_tbclk {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = dpll_per_m2_ck;
+ ti,bit-shift = 5;
+ reg = 0x0664;
+ };
+
+ ehrpwm5_tbclk: ehrpwm5_tbclk {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = dpll_per_m2_ck;
+ ti,bit-shift = 6;
+ reg = 0x0664;
+ };
};
prcm_clocks {
clk_32768_ck: clk_32768_ck {
diff --git a/drivers/clk/ti/clk-43xx.c b/drivers/clk/ti/clk-43xx.c
index 67c8de5..527a43d 100644
--- a/drivers/clk/ti/clk-43xx.c
+++ b/drivers/clk/ti/clk-43xx.c
@@ -105,6 +105,12 @@ static struct ti_dt_clk am43xx_clks[] = {
DT_CLK(NULL, func_12m_clk, func_12m_clk),
DT_CLK(NULL, vtp_clk_div, vtp_clk_div),
DT_CLK(NULL, usbphy_32khz_clkmux, usbphy_32khz_clkmux),
+ DT_CLK(48300200.ehrpwm, tbclk, ehrpwm0_tbclk),
+ DT_CLK(48302200.ehrpwm, tbclk, ehrpwm1_tbclk),
+ DT_CLK(48304200.ehrpwm, tbclk, ehrpwm2_tbclk),
+ DT_CLK(48306200.ehrpwm, tbclk, ehrpwm3_tbclk),
+ DT_CLK(48308200.ehrpwm, tbclk, ehrpwm4_tbclk),
+ DT_CLK(4830a200.ehrpwm, tbclk, ehrpwm5_tbclk),
{ .node_name = NULL },
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/17] phy: ti-pipe3: add external clock support for PCIe PHY
Quoting Nishanth Menon (2014-05-15 05:33:13)
On 05/15/2014 07:18 AM, Kishon Vijay Abraham I wrote:
Hi,
On Thursday 15 May 2014 05:42 PM, Nishanth Menon wrote:
On Thu, May 15, 2014 at 6:59 AM, Kishon Vijay Abraham I kis...@ti.com
wrote:
Hi Nishant,
On Thursday 15 May 2014 05:16 PM, Nishanth Menon wrote:
On Thu, May 15, 2014 at 4:25 AM, Roger Quadros rog...@ti.com wrote:
On 05/15/2014 12:15 PM, Kishon Vijay Abraham I wrote:
Hi Nishanth,
On Wednesday 14 May 2014 09:04 PM, Nishanth Menon wrote:
On Wed, May 14, 2014 at 10:19 AM, Kishon Vijay Abraham I
kis...@ti.com wrote:
Hi Roger,
On Wednesday 14 May 2014 06:46 PM, Roger Quadros wrote:
Hi Kishon,
On 05/06/2014 04:33 PM, Kishon Vijay Abraham I wrote:
APLL used by PCIE phy can either use external clock as input or
the clock
from DPLL. Added support for the APLL to use external clock as
input here.
Cc: Rajendra Nayak rna...@ti.com
Cc: Tero Kristo t-kri...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
Documentation/devicetree/bindings/phy/ti-phy.txt |4 ++
drivers/phy/phy-ti-pipe3.c | 75
++
2 files changed, 52 insertions(+), 27 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt
b/Documentation/devicetree/bindings/phy/ti-phy.txt
index bc9afb5..d50f8ee 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -76,6 +76,10 @@ Required properties:
* dpll_ref_m2 - external dpll ref clk
* phy-div - divider for apll
* div-clk - apll clock
+ * apll_mux - mux for pcie apll
+ * refclk_ext - external reference clock for pcie apll
+ - ti,ext-clk: To specifiy if PCIE apll should use external
clock. Applicable
+ only to PCIE PHY.
Instead of specifying both clock sources dpll_ref_clock,
refclk_ext and then specifying a 3rd control option ti,ext-clk
to select one of the 2 sources, why can't the DT just supply one
clock source, i.e. the one that is being used in the board
instance? The driver should then just configure the clock rate that
is needed at that node. Shouldn't the clock framework automatically
take care of muxing and parent rates?
Want the dt to have all the clocks used by the controller.
ti,ext-clk should
go in the board dt file (suggested by Nishanth).
The point is at some point later if some one wants to change the
clock source,
it should be a simple enabling ti,ext-clk flag instead of finding
the clock
phandle etc..
Wonder if that is implicit by the presence of refclk_ext in the
clocks provided?
IMO the presence of refclk_ext is useless unless the board indicates
it
provides the clock source.
refclk_ext holds phandle for *fixed-clock*, so irrespective of whether
the
board provides a clock or not, it can have that handle for configuring
in PRCM.
However if the board does not provide the clock source, configuring
refclk_ext
in PRCM is useless.
I think what Nishant meant is that if refclk_ext is provided it means
that the driver
should use that over dpll_ref_clock so no need of a separate
ti,ext-clk flag.
yes, thank you for clarifying - it does indeed redundant to have
ti,ext-clk. and apologies on being a little obscure in the comment.
Irrespective of whether external reference clock is used or not, all DRA7
(apll) has an input for external reference clock (and also a PRCM
register for
programming it) and it has to be specified in dt no?
Why is that a binding for ti-phy? that is a problem for the APLL clock
driver (selecting it's own source). PHY properties should describe
itself - let the bindings of the APLL describe itself. please dont
mix the two up.
The apll clock node is like this
apll_pcie_in_clk_mux: apll_pcie_in_clk_mux@4ae06118 {
compatible = mux-clock;
clocks = dpll_pcie_ref_m2ldo_ck, pciesref_acs_clk_ck;
#clock-cells = 0;
reg = 0x4a00821c 0x4;
bit-mask = 0x80;
};
The external reference clock is denoted by *pciesref_acs_clk_ck*.
refclk_ext holds the phandle to *pciesref_acs_clk_ck* and is used in
clk_set_parent to set the parent of apll mux.
So, How about this: if refclk_ext is not defined, dont do setparent,
if it is defined, do setparent.
in short:
Optional Properties:
* refclk_ext - external reference clock for pcie apll - if defined,
used as the parent to apll_mux
That said, my problem in general with this approach(which many folks
have taken of describing parent of clock X in hardware block binding
for Y) is the following:
The binding now has dependency on clock tree hierarchy. What if
towmorrow, we have a tree where refclk_ext parent of muxZ parent of
apll_mux? the binding breaks down. Lets not forget that we consider DT
as an ABI - we
Re: [PATCH 0/3] ARM: OMAP5+: Support Duty Cycle Correction(DCC)
Quoting Nishanth Menon (2014-05-16 03:45:57) Hi, This patch series has been carried over in vendor kernel for quiet few years now. Unfortunately, it was very recently re-discovered and upstream kernel is noticed to be broken for OMAP5 1.5GHz - at least we are operating DPLL at frequency higher than what it was intended to be when CPUFreq is enabled. Thankfully, with nominal voltage(we dont use AVS yet in upstream for the mentioned platforms) and margins in trimming, we have so far not crashed - but I strongly suspect this might be some boundary case survival. DCC also exists in OMAP4. In some cases customers used it, in other cases we just ran the PLL way out of spec and the mpu_clk would divide by 2. Is this broken for OMAP4 as well? Regards, Mike Verified on the following impacted platforms using 3.15-rc4 based vendor kernel. Before: OMAP5432: http://slexy.org/view/s20cs0qQFg DRA72x: http://slexy.org/view/s2TXtSa6mH (refused to lock) DRA75x: http://slexy.org/view/s20AW8MU5c After: OMAP5432: http://slexy.org/view/s21iAfWxpu DRA72x: http://slexy.org/view/s2hwsvGLmC (locks properly) DRA75x: http://slexy.org/view/s21ehw8WQn Hopefully, we can get these into some kernel revision in some form. NOTE: Support for 4470(which is the only other platform requiring DCC) is not present in upstream kernel and there are no plans to support that SoC, even if it is added at a later point, support can be extended as needed. Series based on v3.15-rc5 tag. Also available on my tree: https://github.com/nmenon/linux-2.6-playground/ branch: push/clock/dcc weblink: https://github.com/nmenon/linux-2.6-playground/commits/push/clock/dcc Verification: 3.15-rc4 based kernel - DRA75x-evm, 72x-evm, OMAP5uevm 3.15-rc5 - OMAP5uEVM(only one supporting 1.5GHz atm) Andrii Tseglytskyi (1): ARM: OMAP5+: dpll: support Duty Cycle Correction(DCC) Nishanth Menon (2): clk: dpll: support OMAP5 MPU DPLL that need special handling for higher frequencies ARM: dts: OMAP5/DRA7: use omap5-mpu-dpll-clock capable of dealing with higher frequencies .../devicetree/bindings/clock/ti/dpll.txt |1 + arch/arm/boot/dts/dra7xx-clocks.dtsi |2 +- arch/arm/boot/dts/omap54xx-clocks.dtsi |2 +- arch/arm/mach-omap2/dpll3xxx.c |9 + drivers/clk/ti/dpll.c | 21 include/linux/clk/ti.h |4 6 files changed, 37 insertions(+), 2 deletions(-) Regards, Nishanth Menon -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] arm: dts: am33xx-clock: Fix ehrpwm tbclk data.
Quoting Sourav Poddar (2014-04-29 01:34:20)
tbclk does not need to be a composite clock, we can simply
use gate clock for this purpose.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
Looks good.
Regards,
Mike
---
v1-v2:
change compatible string according to mainline.
arch/arm/boot/dts/am33xx-clocks.dtsi | 30 ++
1 file changed, 6 insertions(+), 24 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx-clocks.dtsi
b/arch/arm/boot/dts/am33xx-clocks.dtsi
index 9ccfe50..712edce 100644
--- a/arch/arm/boot/dts/am33xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am33xx-clocks.dtsi
@@ -96,47 +96,29 @@
clock-div = 1;
};
- ehrpwm0_gate_tbclk: ehrpwm0_gate_tbclk {
+ ehrpwm0_tbclk: ehrpwm0_tbclk@44e10664 {
#clock-cells = 0;
- compatible = ti,composite-no-wait-gate-clock;
+ compatible = ti,gate-clock;
clocks = dpll_per_m2_ck;
ti,bit-shift = 0;
reg = 0x0664;
};
- ehrpwm0_tbclk: ehrpwm0_tbclk {
- #clock-cells = 0;
- compatible = ti,composite-clock;
- clocks = ehrpwm0_gate_tbclk;
- };
-
- ehrpwm1_gate_tbclk: ehrpwm1_gate_tbclk {
+ ehrpwm1_tbclk: ehrpwm1_tbclk@44e10664 {
#clock-cells = 0;
- compatible = ti,composite-no-wait-gate-clock;
+ compatible = ti,gate-clock;
clocks = dpll_per_m2_ck;
ti,bit-shift = 1;
reg = 0x0664;
};
- ehrpwm1_tbclk: ehrpwm1_tbclk {
- #clock-cells = 0;
- compatible = ti,composite-clock;
- clocks = ehrpwm1_gate_tbclk;
- };
-
- ehrpwm2_gate_tbclk: ehrpwm2_gate_tbclk {
+ ehrpwm2_tbclk: ehrpwm2_tbclk@44e10664 {
#clock-cells = 0;
- compatible = ti,composite-no-wait-gate-clock;
+ compatible = ti,gate-clock;
clocks = dpll_per_m2_ck;
ti,bit-shift = 2;
reg = 0x0664;
};
-
- ehrpwm2_tbclk: ehrpwm2_tbclk {
- #clock-cells = 0;
- compatible = ti,composite-clock;
- clocks = ehrpwm2_gate_tbclk;
- };
};
prcm_clocks {
clk_32768_ck: clk_32768_ck {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/4] clk: ti: Driver for DRA7 ATL (Audio Tracking Logic)
Quoting Peter Ujfalusi (2014-05-07 03:20:47)
Audio Tracking Logic is designed to be used by HD Radio applications to
synchronize the audio output clocks to the baseband clock. ATL can be also
used to track errors between two reference clocks (BWS, AWS) and generate a
modulated
clock output which averages to some desired frequency.
In essence ATL is generating a clock to be used by an audio codec and also
to be used by the SoC as MCLK.
To be able to integrate the ATL provided clocks to the clock tree we need
two types of DT binding:
- DT clock nodes to represent the ATL clocks towards the CCF
- binding for the ATL IP itself which is going to handle the hw
configuration
The reason for this type of setup is that ATL itself is a separate device
in the SoC, it has it's own address space and clock domain. Other IPs can
use the ATL generated clock as their functional clock (McASPs for example)
and external components like audio codecs can also use the very same clock
as their MCLK.
The ATL IP in DRA7 contains 4 ATL instences.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Looks good to me.
Regards,
Mike
---
drivers/clk/ti/Makefile | 3 +-
drivers/clk/ti/clk-dra7-atl.c | 313
++
2 files changed, 315 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/ti/clk-dra7-atl.c
diff --git a/drivers/clk/ti/Makefile b/drivers/clk/ti/Makefile
index 4319d4031aa3..18e2443224e6 100644
--- a/drivers/clk/ti/Makefile
+++ b/drivers/clk/ti/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_SOC_AM33XX)+= $(clk-common)
clk-33xx.o
obj-$(CONFIG_ARCH_OMAP3) += $(clk-common) interface.o
clk-3xxx.o
obj-$(CONFIG_ARCH_OMAP4) += $(clk-common) clk-44xx.o
obj-$(CONFIG_SOC_OMAP5)+= $(clk-common) clk-54xx.o
-obj-$(CONFIG_SOC_DRA7XX) += $(clk-common) clk-7xx.o
+obj-$(CONFIG_SOC_DRA7XX) += $(clk-common) clk-7xx.o \
+ clk-dra7-atl.o
obj-$(CONFIG_SOC_AM43XX) += $(clk-common) clk-43xx.o
endif
diff --git a/drivers/clk/ti/clk-dra7-atl.c b/drivers/clk/ti/clk-dra7-atl.c
new file mode 100644
index ..97a8992eebb7
--- /dev/null
+++ b/drivers/clk/ti/clk-dra7-atl.c
@@ -0,0 +1,313 @@
+/*
+ * DRA7 ATL (Audio Tracking Logic) clock driver
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Peter Ujfalusi peter.ujfal...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/clk-provider.h
+#include linux/slab.h
+#include linux/io.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/platform_device.h
+#include linux/pm_runtime.h
+
+#define DRA7_ATL_INSTANCES 4
+
+#define DRA7_ATL_PPMR_REG(id) (0x200 + (id * 0x80))
+#define DRA7_ATL_BBSR_REG(id) (0x204 + (id * 0x80))
+#define DRA7_ATL_ATLCR_REG(id) (0x208 + (id * 0x80))
+#define DRA7_ATL_SWEN_REG(id) (0x210 + (id * 0x80))
+#define DRA7_ATL_BWSMUX_REG(id)(0x214 + (id * 0x80))
+#define DRA7_ATL_AWSMUX_REG(id)(0x218 + (id * 0x80))
+#define DRA7_ATL_PCLKMUX_REG(id) (0x21c + (id * 0x80))
+
+#define DRA7_ATL_SWEN BIT(0)
+#define DRA7_ATL_DIVIDER_MASK (0x1f)
+#define DRA7_ATL_PCLKMUX BIT(0)
+struct dra7_atl_clock_info;
+
+struct dra7_atl_desc {
+ struct clk *clk;
+ struct clk_hw hw;
+ struct dra7_atl_clock_info *cinfo;
+ int id;
+
+ bool probed;/* the driver for the IP has been loaded */
+ bool valid; /* configured */
+ bool enabled;
+ u32 bws;/* Baseband Word Select Mux */
+ u32 aws;/* Audio Word Select Mux */
+ u32 divider;/* Cached divider value */
+};
+
+struct dra7_atl_clock_info {
+ struct device *dev;
+ void __iomem *iobase;
+
+ struct dra7_atl_desc *cdesc;
+};
+
+#define to_atl_desc(_hw) container_of(_hw, struct dra7_atl_desc, hw)
+
+static inline void atl_write(struct dra7_atl_clock_info *cinfo, u32 reg,
+u32 val)
+{
+ __raw_writel(val, cinfo-iobase + reg);
+}
+
+static inline int atl_read(struct dra7_atl_clock_info *cinfo, u32 reg)
+{
+ return __raw_readl(cinfo-iobase + reg);
+}
+
+static int atl_clk_enable(struct clk_hw *hw)
+{
+ struct dra7_atl_desc *cdesc = to_atl_desc(hw);
+
+
Re: [PATCH 1/3] clk: ti: add 'ti,round-rate' flag
Quoting Tomi Valkeinen (2014-05-12 05:13:51) On 12/05/14 15:02, Tero Kristo wrote: On 05/08/2014 12:06 PM, Tomi Valkeinen wrote: The current DPLL code does not try to round the clock rate, and instead returns an error if the requested clock rate cannot be produced exactly by the DPLL. It could be argued that this is a bug, but as the current drivers may depend on that behavior, a new flag 'ti,round-rate' is added which enables clock rate rounding. Someone could probably argue that this flag is not a hardware feature, I fully agree. but instead is used to describe linux-kernel behavior, and would probably be frowned upon by the DT enthusiasts. Othen than that, I like this approach better than a global setting, but would like second opinions here. I think the dpll code should always do rounding. That's what round_rate() is supposed to do, afaik. The current behavior of not rounding and returning an error is a bug in my opinion. From include/linux/clk.h: /** * clk_round_rate - adjust a rate to the exact rate a clock can provide * @clk: clock source * @rate: desired clock rate in Hz * * Returns rounded clock rate in Hz, or negative errno. */ long clk_round_rate(struct clk *clk, unsigned long rate); Definitely not rounding the rate is a bug, with respect to the API definition. Has anyone tried making the new flag as the default behavior and seeing if anything breaks? For those users of the omapconf tool I enjoy doing something like the following: boot current, buggy behavior omapconf dump prcm old boot with Tomi's flag enabled for all DPLLs by default omapconf dump prcm new diff -u old new This should reveal any deltas, assuming the board boots and doesn't let magic smoke out. Regards, Mike So, if you ask me, the whole flag is just for the purpose of keeping the current drivers working, which could depend on the broken behavior. But I think we cannot have such drivers (functional, at least) in any case, as the clk-divider driver is broken and doesn't handle the errors the dpll code currently returns for non-exact rates. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3] arm: dts: am43x-clock: add tbclk data for ehrpwm.
Quoting Tero Kristo (2014-04-29 07:51:14)
On 04/29/2014 05:15 PM, Sourav Poddar wrote:
We need tbclk clock data for the functioning of ehrpwm
module. Hence, populating the required clock information
in clock dts file.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
Acked-by: Tero Kristo t-kri...@ti.com
Looks good to me.
Tero, just to be clear, are you planning on batching up OMAPish clock
patches and sending a pull request (once they have been reviewed on the
list)?
Thanks,
Mike
---
v2-v3
- correct bitshifting
arch/arm/boot/dts/am43xx-clocks.dtsi | 48
++
drivers/clk/ti/clk-43xx.c|6 +
2 files changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi
b/arch/arm/boot/dts/am43xx-clocks.dtsi
index 142009c..42d7b1f 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -87,6 +87,54 @@
clock-mult = 1;
clock-div = 1;
};
+
+ ehrpwm0_tbclk: ehrpwm0_tbclk {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = dpll_per_m2_ck;
+ ti,bit-shift = 0;
+ reg = 0x0664;
+ };
+
+ ehrpwm1_tbclk: ehrpwm1_tbclk {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = dpll_per_m2_ck;
+ ti,bit-shift = 1;
+ reg = 0x0664;
+ };
+
+ ehrpwm2_tbclk: ehrpwm2_tbclk {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = dpll_per_m2_ck;
+ ti,bit-shift = 2;
+ reg = 0x0664;
+ };
+
+ ehrpwm3_tbclk: ehrpwm3_tbclk {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = dpll_per_m2_ck;
+ ti,bit-shift = 4;
+ reg = 0x0664;
+ };
+
+ ehrpwm4_tbclk: ehrpwm4_tbclk {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = dpll_per_m2_ck;
+ ti,bit-shift = 5;
+ reg = 0x0664;
+ };
+
+ ehrpwm5_tbclk: ehrpwm5_tbclk {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = dpll_per_m2_ck;
+ ti,bit-shift = 6;
+ reg = 0x0664;
+ };
};
prcm_clocks {
clk_32768_ck: clk_32768_ck {
diff --git a/drivers/clk/ti/clk-43xx.c b/drivers/clk/ti/clk-43xx.c
index 67c8de5..527a43d 100644
--- a/drivers/clk/ti/clk-43xx.c
+++ b/drivers/clk/ti/clk-43xx.c
@@ -105,6 +105,12 @@ static struct ti_dt_clk am43xx_clks[] = {
DT_CLK(NULL, func_12m_clk, func_12m_clk),
DT_CLK(NULL, vtp_clk_div, vtp_clk_div),
DT_CLK(NULL, usbphy_32khz_clkmux, usbphy_32khz_clkmux),
+ DT_CLK(48300200.ehrpwm, tbclk, ehrpwm0_tbclk),
+ DT_CLK(48302200.ehrpwm, tbclk, ehrpwm1_tbclk),
+ DT_CLK(48304200.ehrpwm, tbclk, ehrpwm2_tbclk),
+ DT_CLK(48306200.ehrpwm, tbclk, ehrpwm3_tbclk),
+ DT_CLK(48308200.ehrpwm, tbclk, ehrpwm4_tbclk),
+ DT_CLK(4830a200.ehrpwm, tbclk, ehrpwm5_tbclk),
{ .node_name = NULL },
};
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] clk: dt: add support for default rate/parent
Quoting Tero Kristo (2014-03-05 05:10:17) Ping. Mike, any feedback on this? Hi Tero, Have you seen Sylwester's approach[1]? I prefer it since it is more device-oriented and less centralized. The clock consumer enumerates the default parent or rate of a consumed clock. This can be made to work like your approach by having the clock driver consume these clocks and set them up with default rates or parents. What do you think? Regards, Mike [1] https://lkml.org/lkml/2014/3/3/324 -Tero On 02/13/2014 11:00 AM, Tero Kristo wrote: Hi, This set is a mix-match of new DT properties for generic and TI specific clock drivers. Basically provided for commenting purposes. The patches provide a way to configure clock parents / rates during boot through DT. default-rate : sets rate of a clock during boot, supported for any DT clock type (through generic clock driver) ti,default-parent : selects a default parent for a multiplexer clock, only supported for TI specific mux clock for now, as generic mux clock does not support DT clocks Patch #4 provided as a reference how to move the default rates / parents from kernel code to DT. Default-rate logic in patch #2 looks somewhat complicated, as the clocks need to be sorted based on their parents to avoid cases where a child clock would set its rate first, just to be overridden by its parent changing rate later and resulting in incorrect rate for the child clock. If the default-rate generic property is not going to fly, it can be moved to TI only drivers also. -Tero ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 3/6] PM / Voltagedomain: introduce voltage domain driver support
Quoting Nishanth Menon (2014-03-10 12:25:43) On 03/10/2014 01:01 PM, Mark Brown wrote: On Mon, Mar 10, 2014 at 12:41:05PM -0500, Nishanth Menon wrote: The only other options are: a) Abstract it at a higher level at user drivers, since they are aware of the sequencing needs - but this partially defeats the purpose, unless ofcourse, we do a tricky implementation such as: clk a, b, c - prenotifiers in a, postnotifiers in c (which as you mentioned is a little trickier to get right). b) introduce a higher level generic dvfs function[1] which does not seem very attractive either. I disagree that a higher level DVFS interface is unattractive. I think it has taken a while to get there but people are finally interested in this. A small amount of discussion about this took place at Linaro Connect earlier this month (just hallway talk) but we shouldn't rule out the idea of a general framework for managing DVFS, which frankly is complex enough to merit not being shoved into the clock layer. Any other suggestions other than limiting the usage(and documenting it so) and hoping for a future evolution to take this into consideration? Something might be doable with telling the clock API about maintianing ratios between clocks? I do think we should have an idea where we'd go with such requirements, even if we don't currently handle it, so that we can hopefully avoid another round of refactoring everything but it doesn't seem 100% essential, just very nice to have. This sounds reasonable but I must point out that the clock framework today (based on the existing clk.h api) does not have a single instance of constraint-based logic. For instance there is no clk_set_min_rate or clk_set_max_rate or clk_set_rate_range. These have been discussed before but I feel that pushing something before now would have been premature given that the level of discussion around those features never hit critical mass. So the ratio thing is sensible, but it would be the first constraint-like mechanism in the clock framework so what that looks like bares careful consideration. Mike, Any suggestions about the above? could we use composite clocks in some manner here(even though I think the original intent of the same was not the same)? NACK. Let's just model the hardware in the clock framework, please. If you need to invent fake clocks to represent other constructs then it means the framework is missing something (or we're missing an entire framework, e.g. DVFS). Regards, Mike -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] clk: divider: fix rate calculation for fractional rates
Quoting Tomi Valkeinen (2014-03-17 05:53:03)
On 27/02/14 04:25, Mike Turquette wrote:
Quoting Tero Kristo (2014-02-14 05:45:22)
On 02/13/2014 12:03 PM, Tomi Valkeinen wrote:
clk-divider.c does not calculate the rates consistently at the moment.
As an example, on OMAP3 we have a clock divider with a source clock of
86400 Hz. With dividers 6, 7 and 8 the theoretical rates are:
6: 14400
7: 123428571.428571...
8: 10800
Calling clk_round_rate() with the rate in the first column will give the
rate in the second column:
14400 - 14400
14399 - 123428571
123428572 - 123428571
123428571 - 10800
Note how clk_round_rate() returns 123428571 for rates from 123428572 to
14399, which is mathematically correct, but when clk_round_rate() is
called with 123428571, the returned value is surprisingly 10800.
This means that the following code works a bit oddly:
rate = clk_round_rate(clk, 123428572);
clk_set_rate(clk, rate);
As clk_set_rate() also does clock rate rounding, the result is that the
clock is set to the rate of 10800, not 123428571 returned by the
clk_round_rate.
This patch changes the clk-divider.c to use DIV_ROUND_UP when
calculating the rate. This gives the following behavior which fixes the
inconsistency:
14400 - 14400
14399 - 123428572
123428572 - 123428572
123428571 - 10800
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Mike Turquette mturque...@linaro.org
---
drivers/clk/clk-divider.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 5543b7df8e16..ec22112e569f 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -24,7 +24,7 @@
* Traits of this clock:
* prepare - clk_prepare only ensures that parents are prepared
* enable - clk_enable only ensures that parents are enabled
- * rate - rate is adjustable. clk-rate = parent-rate / divisor
+ * rate - rate is adjustable. clk-rate = DIV_ROUND_UP(parent-rate /
divisor)
* parent - fixed parent. No clk_set_parent support
*/
@@ -115,7 +115,7 @@ static unsigned long clk_divider_recalc_rate(struct
clk_hw *hw,
return parent_rate;
}
- return parent_rate / div;
+ return DIV_ROUND_UP(parent_rate, div);
}
/*
@@ -185,7 +185,7 @@ static int clk_divider_bestdiv(struct clk_hw *hw,
unsigned long rate,
}
parent_rate = __clk_round_rate(__clk_get_parent(hw-clk),
MULT_ROUND_UP(rate, i));
- now = parent_rate / i;
+ now = DIV_ROUND_UP(parent_rate, i);
if (now = rate now best) {
bestdiv = i;
best = now;
@@ -207,7 +207,7 @@ static long clk_divider_round_rate(struct clk_hw *hw,
unsigned long rate,
int div;
div = clk_divider_bestdiv(hw, rate, prate);
- return *prate / div;
+ return DIV_ROUND_UP(*prate, div);
}
static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,
@@ -218,7 +218,7 @@ static int clk_divider_set_rate(struct clk_hw *hw,
unsigned long rate,
unsigned long flags = 0;
u32 val;
- div = parent_rate / rate;
+ div = DIV_ROUND_UP(parent_rate, rate);
value = _get_val(divider, div);
if (value div_mask(divider))
Basically the patch looks good to me, but it might be good to have a
testing round of sort with this. It can potentially cause regressions on
multiple boards if the drivers happen to rely on the broken clock
rates. Same for patch #2 which is a copy paste of this one, but only
impacts TI boards.
Agreed. I've taken patches #1 #2 into clk-next. Let's let them stew in
-next for a while and see if anyone's board catches on fire.
Are these on the way to 3.15?
Yes, they've been in -next for a couple of weeks.
Regards,
Mike
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] CLK: TI: OMAP4/5/DRA7: Remove gpmc_fck from dummy clocks
Quoting Florian Vaussard (2014-02-26 02:38:08)
When arch/arm/mach-omap2/gpmc.c calls clk_get(..., fck), it will
get a dummy clock and try to use it. As the rate is configured to zero,
this will result in several divisions by zero, and misconfigured
timings, with devices on the bus being lost in the La La Land.
It is better to remove gpmc_fck from the dummy clocks, so that gpmc.c
can fail gracefully.
Signed-off-by: Florian Vaussard florian.vauss...@epfl.ch
Looks good to me.
Regards,
Mike
---
drivers/clk/ti/clk-44xx.c | 1 -
drivers/clk/ti/clk-54xx.c | 1 -
drivers/clk/ti/clk-7xx.c | 1 -
3 files changed, 3 deletions(-)
diff --git a/drivers/clk/ti/clk-44xx.c b/drivers/clk/ti/clk-44xx.c
index ae00218..02517a8 100644
--- a/drivers/clk/ti/clk-44xx.c
+++ b/drivers/clk/ti/clk-44xx.c
@@ -222,7 +222,6 @@ static struct ti_dt_clk omap44xx_clks[] = {
DT_CLK(NULL, auxclk5_src_ck, auxclk5_src_ck),
DT_CLK(NULL, auxclk5_ck, auxclk5_ck),
DT_CLK(NULL, auxclkreq5_ck, auxclkreq5_ck),
- DT_CLK(5000.gpmc, fck, dummy_ck),
DT_CLK(omap_i2c.1, ick, dummy_ck),
DT_CLK(omap_i2c.2, ick, dummy_ck),
DT_CLK(omap_i2c.3, ick, dummy_ck),
diff --git a/drivers/clk/ti/clk-54xx.c b/drivers/clk/ti/clk-54xx.c
index 0ef9f58..08f3d1b 100644
--- a/drivers/clk/ti/clk-54xx.c
+++ b/drivers/clk/ti/clk-54xx.c
@@ -182,7 +182,6 @@ static struct ti_dt_clk omap54xx_clks[] = {
DT_CLK(NULL, auxclk3_src_ck, auxclk3_src_ck),
DT_CLK(NULL, auxclk3_ck, auxclk3_ck),
DT_CLK(NULL, auxclkreq3_ck, auxclkreq3_ck),
- DT_CLK(NULL, gpmc_ck, dummy_ck),
DT_CLK(omap_i2c.1, ick, dummy_ck),
DT_CLK(omap_i2c.2, ick, dummy_ck),
DT_CLK(omap_i2c.3, ick, dummy_ck),
diff --git a/drivers/clk/ti/clk-7xx.c b/drivers/clk/ti/clk-7xx.c
index 9977653..f7e4073 100644
--- a/drivers/clk/ti/clk-7xx.c
+++ b/drivers/clk/ti/clk-7xx.c
@@ -262,7 +262,6 @@ static struct ti_dt_clk dra7xx_clks[] = {
DT_CLK(NULL, vip1_gclk_mux, vip1_gclk_mux),
DT_CLK(NULL, vip2_gclk_mux, vip2_gclk_mux),
DT_CLK(NULL, vip3_gclk_mux, vip3_gclk_mux),
- DT_CLK(NULL, gpmc_ck, dummy_ck),
DT_CLK(omap_i2c.1, ick, dummy_ck),
DT_CLK(omap_i2c.2, ick, dummy_ck),
DT_CLK(omap_i2c.3, ick, dummy_ck),
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 06/14] CLK: TI: OMAP3: Get rid of unused USB Host dummy clocks
Quoting Roger Quadros (2014-02-25 01:32:19)
Hi Mike,
On 02/25/2014 10:43 AM, Mike Turquette wrote:
Quoting Roger Quadros (2014-02-20 03:40:01)
The OMAP USB Host MFD driver no longer expects these non-existing
clocks from the OMAP3 platform, so get rid of them.
Looks good to me.
Is it OK if I squash this patch with [1] and take it through the MFD tree?
Keeping them separate could break functionality if both don't go in together.
Acked-by: Mike Turquette mturque...@linaro.org
[1] - http://article.gmane.org/gmane.linux.ports.arm.kernel/303266
cheers,
-roger
CC: Tero Kristo t-kri...@ti.com
CC: Mike Turquette mturque...@linaro.org
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/cclock3xxx_data.c | 4
drivers/clk/ti/clk-3xxx.c | 4
2 files changed, 8 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 3b05aea..4299a55 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -3495,10 +3495,6 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, dss_tv_fck, dss_tv_fck),
CLK(NULL, dss_96m_fck, dss_96m_fck),
CLK(NULL, dss2_alwon_fck, dss2_alwon_fck),
- CLK(NULL, utmi_p1_gfclk,dummy_ck),
- CLK(NULL, utmi_p2_gfclk,dummy_ck),
- CLK(NULL, xclk60mhsp1_ck, dummy_ck),
- CLK(NULL, xclk60mhsp2_ck, dummy_ck),
CLK(NULL, init_60m_fclk,dummy_ck),
CLK(NULL, gpt1_fck, gpt1_fck),
CLK(NULL, aes2_ick, aes2_ick),
diff --git a/drivers/clk/ti/clk-3xxx.c b/drivers/clk/ti/clk-3xxx.c
index d323023..0d1750a 100644
--- a/drivers/clk/ti/clk-3xxx.c
+++ b/drivers/clk/ti/clk-3xxx.c
@@ -130,10 +130,6 @@ static struct ti_dt_clk omap3xxx_clks[] = {
DT_CLK(NULL, dss_tv_fck, dss_tv_fck),
DT_CLK(NULL, dss_96m_fck, dss_96m_fck),
DT_CLK(NULL, dss2_alwon_fck, dss2_alwon_fck),
- DT_CLK(NULL, utmi_p1_gfclk, dummy_ck),
- DT_CLK(NULL, utmi_p2_gfclk, dummy_ck),
- DT_CLK(NULL, xclk60mhsp1_ck, dummy_ck),
- DT_CLK(NULL, xclk60mhsp2_ck, dummy_ck),
DT_CLK(NULL, init_60m_fclk, dummy_ck),
DT_CLK(NULL, gpt1_fck, gpt1_fck),
DT_CLK(NULL, aes2_ick, aes2_ick),
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] clk: divider: fix rate calculation for fractional rates
Quoting Tero Kristo (2014-02-14 05:45:22)
On 02/13/2014 12:03 PM, Tomi Valkeinen wrote:
clk-divider.c does not calculate the rates consistently at the moment.
As an example, on OMAP3 we have a clock divider with a source clock of
86400 Hz. With dividers 6, 7 and 8 the theoretical rates are:
6: 14400
7: 123428571.428571...
8: 10800
Calling clk_round_rate() with the rate in the first column will give the
rate in the second column:
14400 - 14400
14399 - 123428571
123428572 - 123428571
123428571 - 10800
Note how clk_round_rate() returns 123428571 for rates from 123428572 to
14399, which is mathematically correct, but when clk_round_rate() is
called with 123428571, the returned value is surprisingly 10800.
This means that the following code works a bit oddly:
rate = clk_round_rate(clk, 123428572);
clk_set_rate(clk, rate);
As clk_set_rate() also does clock rate rounding, the result is that the
clock is set to the rate of 10800, not 123428571 returned by the
clk_round_rate.
This patch changes the clk-divider.c to use DIV_ROUND_UP when
calculating the rate. This gives the following behavior which fixes the
inconsistency:
14400 - 14400
14399 - 123428572
123428572 - 123428572
123428571 - 10800
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Cc: Mike Turquette mturque...@linaro.org
---
drivers/clk/clk-divider.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 5543b7df8e16..ec22112e569f 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -24,7 +24,7 @@
* Traits of this clock:
* prepare - clk_prepare only ensures that parents are prepared
* enable - clk_enable only ensures that parents are enabled
- * rate - rate is adjustable. clk-rate = parent-rate / divisor
+ * rate - rate is adjustable. clk-rate = DIV_ROUND_UP(parent-rate /
divisor)
* parent - fixed parent. No clk_set_parent support
*/
@@ -115,7 +115,7 @@ static unsigned long clk_divider_recalc_rate(struct
clk_hw *hw,
return parent_rate;
}
- return parent_rate / div;
+ return DIV_ROUND_UP(parent_rate, div);
}
/*
@@ -185,7 +185,7 @@ static int clk_divider_bestdiv(struct clk_hw *hw,
unsigned long rate,
}
parent_rate = __clk_round_rate(__clk_get_parent(hw-clk),
MULT_ROUND_UP(rate, i));
- now = parent_rate / i;
+ now = DIV_ROUND_UP(parent_rate, i);
if (now = rate now best) {
bestdiv = i;
best = now;
@@ -207,7 +207,7 @@ static long clk_divider_round_rate(struct clk_hw *hw,
unsigned long rate,
int div;
div = clk_divider_bestdiv(hw, rate, prate);
- return *prate / div;
+ return DIV_ROUND_UP(*prate, div);
}
static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,
@@ -218,7 +218,7 @@ static int clk_divider_set_rate(struct clk_hw *hw,
unsigned long rate,
unsigned long flags = 0;
u32 val;
- div = parent_rate / rate;
+ div = DIV_ROUND_UP(parent_rate, rate);
value = _get_val(divider, div);
if (value div_mask(divider))
Basically the patch looks good to me, but it might be good to have a
testing round of sort with this. It can potentially cause regressions on
multiple boards if the drivers happen to rely on the broken clock
rates. Same for patch #2 which is a copy paste of this one, but only
impacts TI boards.
Agreed. I've taken patches #1 #2 into clk-next. Let's let them stew in
-next for a while and see if anyone's board catches on fire.
Regards,
Mike
-Tero
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/6] PM / Voltagedomain: Add generic clk notifier handler for regulator based dynamic voltage scaling
Quoting Nishanth Menon (2014-02-26 18:34:55)
+/**
+ * pm_runtime_get_rate() - Returns the device operational frequency
+ * @dev: Device to handle
+ * @rate: Returns rate in Hz.
+ *
+ * Returns appropriate error value in case of error conditions, else
+ * returns 0 and rate is updated. The pm_domain logic does all the necessary
+ * operation (which may consider magic hardware stuff) to provide the rate.
+ *
+ * NOTE: the rate returned is a snapshot and in many cases just a bypass
+ * to clk api to set the rate.
+ */
+int pm_runtime_get_rate(struct device *dev, unsigned long *rate)
Instead of rate, how about we use level and leave it undefined as to
what that means? It would be equally valid for level to represent a
clock rate, or an opp from a table of opp's, or a p-state, or some value
passed to a PM microcontroller.
Code that is tightly coupled to the hardware would simply know what
value to use with no extra sugar.
Generic code would need to get the various supported levels populated
at run time, but a DT binding could do that, or a query to the ACPI
tables, or whatever.
+{
+ unsigned long flags;
+ int error = -ENOSYS;
+
+ if (!rate || !dev)
+ return -EINVAL;
+
+ spin_lock_irqsave(dev-power.lock, flags);
+ if (!pm_runtime_active(dev)) {
+ error = -EINVAL;
+ goto out;
+ }
+
+ if (dev-pm_domain dev-pm_domain-active_ops.get_rate)
+ error = dev-pm_domain-active_ops.get_rate(dev, rate);
+out:
+ spin_unlock_irqrestore(dev-power.lock, flags);
+
+ return error;
+}
+
+/**
+ * pm_runtime_set_rate() - Set a specific rate for the device operation
+ * @dev: Device to handle
+ * @rate: Rate to set in Hz
+ *
+ * Returns appropriate error value in case of error conditions, else
+ * returns 0. The pm_domain logic does all the necessary operation (which
+ * may include voltage scale operations or other magic hardware stuff) to
+ * achieve the operation. It is guarenteed that the requested rate is
achieved
+ * on returning from this function if return value is 0.
+ */
+int pm_runtime_set_rate(struct device *dev, unsigned long rate)
Additionally I wonder if the function signature should include a way to
specify the sub-unit of a device that we are operating on? This is a way
to tackle the issues you raised regarding multiple clocks per device,
etc. Two approaches come to mind:
int pm_runtime_set_rate(struct device *dev, int index,
unsigned long rate);
Where index is a sub-unit of struct device *dev. The second approach is
to create a publicly declared structure representing the sub-unit. Some
variations on that theme:
int pm_runtime_set_rate(struct perf_domain *perfdm, unsigned long rate);
or,
int pm_runtime_set_rate(struct generic_power_domain *gpd,
unsigned long rate);
or whatever that sub-unit looks like. The gpd thing might be a total
layering violation, I don't know. Or perhaps it's a decent idea but it
shouldn't be as a PM runtime call. Again, I dunno.
Regards,
Mike
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] clk: ti: am335x: remove unecessary cpu0 clk node
Quoting Nishanth Menon (2014-01-29 10:19:16)
cpu0 clock node has no functionality, since cpufreq-cpu0 is already
capable of picking up the clock from dts.
Signed-off-by: Nishanth Menon n...@ti.com
Taken into clk-next!
Regards,
Mike
---
drivers/clk/ti/clk-33xx.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/clk/ti/clk-33xx.c b/drivers/clk/ti/clk-33xx.c
index 776ee45..028b337 100644
--- a/drivers/clk/ti/clk-33xx.c
+++ b/drivers/clk/ti/clk-33xx.c
@@ -34,7 +34,6 @@ static struct ti_dt_clk am33xx_clks[] = {
DT_CLK(NULL, dpll_core_m5_ck, dpll_core_m5_ck),
DT_CLK(NULL, dpll_core_m6_ck, dpll_core_m6_ck),
DT_CLK(NULL, dpll_mpu_ck, dpll_mpu_ck),
- DT_CLK(cpu0, NULL, dpll_mpu_ck),
DT_CLK(NULL, dpll_mpu_m2_ck, dpll_mpu_m2_ck),
DT_CLK(NULL, dpll_ddr_ck, dpll_ddr_ck),
DT_CLK(NULL, dpll_ddr_m2_ck, dpll_ddr_m2_ck),
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 06/14] CLK: TI: OMAP3: Get rid of unused USB Host dummy clocks
Quoting Roger Quadros (2014-02-20 03:40:01)
The OMAP USB Host MFD driver no longer expects these non-existing
clocks from the OMAP3 platform, so get rid of them.
Looks good to me.
Regards,
Mike
CC: Tero Kristo t-kri...@ti.com
CC: Mike Turquette mturque...@linaro.org
Signed-off-by: Roger Quadros rog...@ti.com
---
arch/arm/mach-omap2/cclock3xxx_data.c | 4
drivers/clk/ti/clk-3xxx.c | 4
2 files changed, 8 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 3b05aea..4299a55 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -3495,10 +3495,6 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, dss_tv_fck, dss_tv_fck),
CLK(NULL, dss_96m_fck, dss_96m_fck),
CLK(NULL, dss2_alwon_fck, dss2_alwon_fck),
- CLK(NULL, utmi_p1_gfclk,dummy_ck),
- CLK(NULL, utmi_p2_gfclk,dummy_ck),
- CLK(NULL, xclk60mhsp1_ck, dummy_ck),
- CLK(NULL, xclk60mhsp2_ck, dummy_ck),
CLK(NULL, init_60m_fclk,dummy_ck),
CLK(NULL, gpt1_fck, gpt1_fck),
CLK(NULL, aes2_ick, aes2_ick),
diff --git a/drivers/clk/ti/clk-3xxx.c b/drivers/clk/ti/clk-3xxx.c
index d323023..0d1750a 100644
--- a/drivers/clk/ti/clk-3xxx.c
+++ b/drivers/clk/ti/clk-3xxx.c
@@ -130,10 +130,6 @@ static struct ti_dt_clk omap3xxx_clks[] = {
DT_CLK(NULL, dss_tv_fck, dss_tv_fck),
DT_CLK(NULL, dss_96m_fck, dss_96m_fck),
DT_CLK(NULL, dss2_alwon_fck, dss2_alwon_fck),
- DT_CLK(NULL, utmi_p1_gfclk, dummy_ck),
- DT_CLK(NULL, utmi_p2_gfclk, dummy_ck),
- DT_CLK(NULL, xclk60mhsp1_ck, dummy_ck),
- DT_CLK(NULL, xclk60mhsp2_ck, dummy_ck),
DT_CLK(NULL, init_60m_fclk, dummy_ck),
DT_CLK(NULL, gpt1_fck, gpt1_fck),
DT_CLK(NULL, aes2_ick, aes2_ick),
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/6] PM / Voltagedomain: Add generic clk notifier handler for regulator based dynamic voltage scaling
Quoting Nishanth Menon (2014-02-18 12:32:18) From: Mike Turquette mturque...@linaro.org This patch provides helper functions for drivers that wish to scale voltage through the clock rate-change notifiers. The approach taken is that the user-driver(cpufreq/devfreq) do not care about the details of the OPP table, nor does it care about handling the voltage regulator directly. By using the clk notifier flags, we are able to sequence the operations in the right order. The current logic is heavily influenced by implementation done in cpufreq-cpu0. [n...@ti.com: Fixes in logic, and broken out from clk to allow building a generic voltagedomain solution independent of cpufreq] Signed-off-by: Nishanth Menon n...@ti.com Signed-off-by: Mike Turquette mturque...@linaro.org Not-signed-off-by: Mike Turquette mturque...@linaro.org I haven't reviewed this series and it is a pretty big deviation from my original RFC. You can have authorship of the patches if you want. I'm not sure about trying to capture the voltdm as a core concept. It feels a bit unwieldy to me. I have wondered about making an abstract performance domain which is the dvfs analogue to generic power domains. This a reasonable split since gpd are good for idle power savings (e.g. clock gate, power gate, sleep state, etc) and perf domains would be good for active power savings (dvfs). Having a generic container for performance domains might make a good place to stuff all of this glue logic that we keep running into (e.g. CPU and GPU max frequencies that are related), and it might make another nice knob for the thermal folks to use. For the case of the OMAP voltage domains, it would be a place to stuff all of the VC/VP - ABB - Smart Reflex AVS stuff. Anyways, I don't have a real proposal. I just don't want my name on these patches since they are really yours now. I might resurrect them some day in a different context. Regards, Mike -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] ARM: OMAP: clk-next-omap emergency fixes
On Sat, Jan 18, 2014 at 9:50 AM, Tony Lindgren t...@atomide.com wrote: * Mike Turquette mturque...@linaro.org [140117 13:39]: Quoting Tero Kristo (2014-01-17 12:25:37) Hi, Quick emergency band-aid for the build breakages introduced in clk-next by Mike. I didn't have time to test this out (Nishanth will provide some logs) and I will leave the decision whether/how to use these patches or not to Tony + Mike. I also pushed a test branch based on top of clk-next here: tree: https://github.com/t-kristo/linux-pm.git branch: clk-next-omap-fixes Thanks Tero. I force updated the clk tree with the right branch, so these should not be necessary now. Great, and just for reference if I did not do it yet for these: Acked-by: Tony Lindgren t...@atomide.com I applied your Ack to entire series (these fixes, clock drivers and arch/arm changes). Regards, Mike -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
Quoting Tero Kristo (2014-01-17 10:11:06) On 01/17/2014 07:53 PM, Tony Lindgren wrote: * Kevin Hilman khil...@linaro.org [140117 09:48]: Mike Turquette mturque...@linaro.org writes: [...] I took Tony's advice and fast-forwarded clk-next to -rc7 and applied Tero's series. This includes the AM3517 bits now. I've pushed this branch to clk-next-omap (force update) on my Linaro mirror. Can you do a final sanity test before I merge this into clk-next? I think you accidentally merged wrong branch to clk-next-omap with the latest refresh. This is one is missing the build-fixes now, when it earlier had those in. The correct branch to merge was 3.13-rc7-dt-clks-v13-build-fixes. This also causes the build failure below for omap1. You are right. I broke the OMAPs. I force updated clk-next-omap (and clk-next) with the correct branch this time. Regards, Mike -Tero I merged clk-next-omap into next-20140117 and build/boot tested omap2plus_defconfig, multi_v7_defconfig and multi_v7_defconfig+CONFIG_LPAE=y and all passed a basic boot test for omap5uevm. I'll add OMAP5 to the automated boot testing starting with the next linux-next. OK that's good news. Looks like omap1_defconfig build has now started failing though: vers/built-in.o: In function `omap5xxx_dt_clk_init': :(.init.text+0x846c): undefined reference to `omap2_clk_disable_autoidle_all' drivers/built-in.o: In function `am43xx_dt_clk_init': :(.init.text+0x856c): undefined reference to `omap2_clk_disable_autoidle_all' drivers/built-in.o:(.rodata+0xc3c4): undefined reference to `omap3_clkoutx2_recalc' drivers/built-in.o:(.rodata+0xc40c): undefined reference to `omap3_noncore_dpll_enable' drivers/built-in.o:(.rodata+0xc410): undefined reference to `omap3_noncore_dpll_disable' drivers/built-in.o:(.rodata+0xc41c): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0xc420): undefined reference to `omap2_dpll_round_rate' drivers/built-in.o:(.rodata+0xc42c): undefined reference to `omap2_init_dpll_parent' drivers/built-in.o:(.rodata+0xc430): undefined reference to `omap3_noncore_dpll_set_rate' drivers/built-in.o:(.rodata+0xc470): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0xc474): undefined reference to `omap2_dpll_round_rate' drivers/built-in.o:(.rodata+0xc480): undefined reference to `omap2_init_dpll_parent' drivers/built-in.o:(.rodata+0xc4a0): undefined reference to `omap3_noncore_dpll_enable' drivers/built-in.o:(.rodata+0xc4a4): undefined reference to `omap3_noncore_dpll_disable' drivers/built-in.o:(.rodata+0xc4b0): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0xc4b4): undefined reference to `omap2_dpll_round_rate' drivers/built-in.o:(.rodata+0xc4c0): undefined reference to `omap2_init_dpll_parent' drivers/built-in.o:(.rodata+0xc4c4): undefined reference to `omap3_dpll4_set_rate' drivers/built-in.o:(.rodata+0xc4e0): undefined reference to `omap3_noncore_dpll_enable' drivers/built-in.o:(.rodata+0xc4e4): undefined reference to `omap3_noncore_dpll_disable' drivers/built-in.o:(.rodata+0xc4f0): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0xc4f4): undefined reference to `omap2_dpll_round_rate' drivers/built-in.o:(.rodata+0xc500): undefined reference to `omap2_init_dpll_parent' drivers/built-in.o:(.rodata+0xc504): undefined reference to `omap3_noncore_dpll_set_rate' drivers/built-in.o:(.rodata+0xc530): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0xc540): undefined reference to `omap2_init_dpll_parent' drivers/built-in.o:(.rodata+0xc560): undefined reference to `omap3_noncore_dpll_enable' drivers/built-in.o:(.rodata+0xc564): undefined reference to `omap3_noncore_dpll_disable' drivers/built-in.o:(.rodata+0xc570): undefined reference to `omap4_dpll_regm4xen_recalc' drivers/built-in.o:(.rodata+0xc574): undefined reference to `omap4_dpll_regm4xen_round_rate' drivers/built-in.o:(.rodata+0xc580): undefined reference to `omap2_init_dpll_parent' drivers/built-in.o:(.rodata+0xc584): undefined reference to `omap3_noncore_dpll_set_rate' drivers/built-in.o:(.rodata+0xc5b0): undefined reference to `omap3_dpll_recalc' drivers/built-in.o:(.rodata+0xc5b4): undefined reference to `omap2_dpll_round_rate' drivers/built-in.o:(.rodata+0xc5c0): undefined reference to `omap2_init_dpll_parent' drivers/built-in.o:(.rodata+0xc5c4): undefined reference to `omap3_noncore_dpll_set_rate' drivers/built-in.o:(.rodata+0xc63c): undefined reference to `omap2_dflt_clk_enable' drivers/built-in.o:(.rodata+0xc640): undefined reference to `omap2_dflt_clk_disable' drivers/built-in.o:(.rodata+0xc644): undefined reference to `omap2_dflt_clk_is_enabled' drivers/built-in.o:(.rodata+0xc728): undefined reference
Re: [PATCH 0/3] ARM: OMAP: clk-next-omap emergency fixes
Quoting Tero Kristo (2014-01-17 12:25:37) Hi, Quick emergency band-aid for the build breakages introduced in clk-next by Mike. I didn't have time to test this out (Nishanth will provide some logs) and I will leave the decision whether/how to use these patches or not to Tony + Mike. I also pushed a test branch based on top of clk-next here: tree: https://github.com/t-kristo/linux-pm.git branch: clk-next-omap-fixes Thanks Tero. I force updated the clk tree with the right branch, so these should not be necessary now. Regards, Mike -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
Quoting Felipe Balbi (2014-01-14 18:04:21) Hi, On Tue, Jan 14, 2014 at 02:36:13PM -0600, Felipe Balbi wrote: Felipe, care to run your randconfig magic for this? This branch builds just fine so far, I still have omap5 multiplaform and uniplatform builds, but since that was working before i'm assuming it won't break. No build failures in any of my 18 seeds (5 randconfigs of each), I'd attach logs, but it's a 2.8MiB tarball, if anyone cares enough, I can send it. FWIW: Acked-by: Felipe Balbi ba...@ti.com Felipe, That's great to hear. Thanks for testing. Tero Tony, These 40 patches apply very cleanly on top of clk-next with 2 exceptions: 1) I did not apply [PATCH 30/42] ARM: dts: AM35xx: use DT clock data because I do not have arch/arm/boot/dts/am3517.dtsi in clk-next (based on 3.13-rc1). 2) Minor merge conflict in arch/arm/boot/dts/omap3.dtsi which I think I resolved correctly but would like verification. I'd prefer to simply merge these patches into clk-next, which is the most straightforward route. Any ideas on how to handle the missing AM35xx dtsi data? It can always go as a separate fix after this stuff gets merged which, ironically, is how that file was created in the first place. Regards, Mike cheers -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
Quoting Mike Turquette (2014-01-14 19:16:32) Quoting Felipe Balbi (2014-01-14 18:04:21) Hi, On Tue, Jan 14, 2014 at 02:36:13PM -0600, Felipe Balbi wrote: Felipe, care to run your randconfig magic for this? This branch builds just fine so far, I still have omap5 multiplaform and uniplatform builds, but since that was working before i'm assuming it won't break. No build failures in any of my 18 seeds (5 randconfigs of each), I'd attach logs, but it's a 2.8MiB tarball, if anyone cares enough, I can send it. FWIW: Acked-by: Felipe Balbi ba...@ti.com Felipe, That's great to hear. Thanks for testing. Tero Tony, These 40 patches apply very cleanly on top of clk-next with 2 exceptions: 1) I did not apply [PATCH 30/42] ARM: dts: AM35xx: use DT clock data because I do not have arch/arm/boot/dts/am3517.dtsi in clk-next (based on 3.13-rc1). 2) Minor merge conflict in arch/arm/boot/dts/omap3.dtsi which I think I resolved correctly but would like verification. I'd prefer to simply merge these patches into clk-next, which is the most straightforward route. Any ideas on how to handle the missing AM35xx dtsi data? It can always go as a separate fix after this stuff gets merged which, ironically, is how that file was created in the first place. I've pushed my branch. Tero can you take a look and let me know if you see any problems? git://git.linaro.org/people/mike.turquette/linux.git clk-next-omap Thanks! Mike Regards, Mike cheers -- balbi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv13 00/40] ARM: TI SoC clock DT conversion
Quoting Tero Kristo (2014-01-09 06:00:11) Hi, So, bad luck number release for this, as v12 wasn't sufficient still. Changes compared to previous version: - Dropped any changes to generic clock drivers, as it seems impossible to agree anything in short term, this means the patch set shrank in size from 49 patches to 40 (first 9 patches were dropped). - Copy pasted implementation for clk-divider and clk-mux from drivers/clk to drivers/clk/ti, and made the modifications needed to the TI version of the clock drivers only (based on discussions with Mike, this is fine) - Changed name of clk_ll_ops to ti_clk_ll_ops so that this doesn't conflict with any generic implementation we might have at some point, migrating this to the generic version should be easy enough also. - Fixed trace_clk_div_div_ck for omap4, this node was broken in previous versions and resulted into an orphan clock node - Fixed compile problem for omap5 only build reported by Felipe - Fixed a couple of sparse warnings - changed the mach-omap2/clock.c to use readl_relaxed / writel_relaxed instead of __raw_readl / __raw_writel Hi Tero, This approach takes care of all of my concerns with this series. Thanks for your long suffering patience on it. It seems some build errors are cropping up, so once those are fixed then I'll be happy to merge clk-next-dt-clks-v13 into clk-next for 3.14. Regards, Mike Testing done: - omap3-beagle: boot / suspend-resume (RET) / suspend-resume (OFF) - omap4-panda-es: boot / suspend-resume (RET) - omap5-uevm: boot - am335x-bone: boot - dra7-evm: boot Maintainer friendly branches also available: tree: https://github.com/t-kristo/linux-pm.git clk driver only (Mike): clk-next-dt-clks-v13 DTS data only (Benoit): dts_for_3.14-dt-clks-v13 full-branch (Tony/Paul): 3.13-rc7-dt-clks-v13 -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv10 10/41] CLK: TI: add support for clockdomain binding
Quoting Tero Kristo (2013-12-16 00:13:08)
On 12/15/2013 06:23 AM, Mike Turquette wrote:
Quoting Tero Kristo (2013-11-26 00:05:51)
Some OMAP clocks require knowledge about their parent clockdomain for
book keeping purposes. This patch creates a new DT binding for TI
clockdomains, which act as a collection of device clocks.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
.../devicetree/bindings/clock/ti/clockdomain.txt | 21 ++
arch/arm/mach-omap2/clock.h|1 -
drivers/clk/ti/Makefile|3 +-
drivers/clk/ti/clockdomain.c | 70
include/linux/clk/ti.h |3 +
5 files changed, 96 insertions(+), 2 deletions(-)
create mode 100644
Documentation/devicetree/bindings/clock/ti/clockdomain.txt
create mode 100644 drivers/clk/ti/clockdomain.c
diff --git a/Documentation/devicetree/bindings/clock/ti/clockdomain.txt
b/Documentation/devicetree/bindings/clock/ti/clockdomain.txt
new file mode 100644
index 000..45e6f7c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/clockdomain.txt
@@ -0,0 +1,21 @@
+Binding for Texas Instruments clockdomain.
+
+Binding status: Unstable - ABI compatibility may be broken in the future
+
+This binding uses the common clock binding[1]. Every clock on
The patch looks fine to me but I think that the binding description
should capture the fact that you are re-using the common clock binding
but that this binding definition does not define any new clocks or clock
controllers in the way that a typical clock binding would.
This code uses the 'clocks' property the same way that any other
consumer binding definition would, such as an MMC controller or UART.
Those bindings do not say that they are based on the common clock
binding AFAIK.
Ok, will modify the doc accordingly.
Just to clarify: I think it is great to reference clock-bindings.txt,
but somehow make sure that someone reading this doesn't mistake it for a
clock controller binding or a new clock type binding. This ip sort of
consumes clocks in the usual way as an IO controller.
Regards,
Mike
-Tero
Regards,
Mike
+TI SoC belongs to one clockdomain, but software only needs this
+information for specific clocks which require their parent
+clockdomain to be controlled when the clock is enabled/disabled.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be ti,clockdomain
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : link phandles of clocks within this domain
+
+Examples:
+ dss_clkdm: dss_clkdm {
+ compatible = ti,clockdomain;
+ clocks = dss1_alwon_fck_3430es2, dss_ick_3430es2;
+ };
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index bc0f9fc..6bd72b5 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -38,7 +38,6 @@ struct omap_clk {
}
struct clockdomain;
-#define to_clk_hw_omap(_hw) container_of(_hw, struct clk_hw_omap, hw)
#define DEFINE_STRUCT_CLK(_name, _parent_array_name, _clkops_name) \
static struct clk _name = { \
diff --git a/drivers/clk/ti/Makefile b/drivers/clk/ti/Makefile
index 7cba389..67056fb 100644
--- a/drivers/clk/ti/Makefile
+++ b/drivers/clk/ti/Makefile
@@ -1,4 +1,5 @@
ifneq ($(CONFIG_OF),)
obj-y += clk.o dpll.o autoidle.o
divider.o \
- fixed-factor.o gate.o
composite.o
+ fixed-factor.o gate.o
clockdomain.o \
+ composite.o
endif
diff --git a/drivers/clk/ti/clockdomain.c b/drivers/clk/ti/clockdomain.c
new file mode 100644
index 000..f1e0038
--- /dev/null
+++ b/drivers/clk/ti/clockdomain.c
@@ -0,0 +1,70 @@
+/*
+ * OMAP clockdomain support
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Tero Kristo t-kri...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk-provider.h
+#include linux/slab.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/clk/ti.h
+
+#undef pr_fmt
+#define pr_fmt(fmt) %s: fmt, __func__
+
+static void __init of_ti_clockdomain_setup(struct device_node *node
Re: [PATCHv10 01/41] clk: add support for platform specific clock I/O wrapper functions
Quoting Tero Kristo (2013-11-26 00:05:42)
Current clock wrappers assume simple and direct mapped hardware register
access. Improve this support by adding functionality for registering
platform specific clock I/O wrappers, which can be used to support
various features needed like endianess conversions, indexed regmap support,
etc. Default I/O wrapper provided also which uses the existing direct
I/O mapped behavior.
Signed-off-by: Tero Kristo t-kri...@ti.com
There is a separate discussion on removing regmap for reading omap clk
registers. I guess this patch is not needed in that case?
Regards,
Mike
---
drivers/clk/clk.c| 68
++
include/linux/clk-provider.h | 15 +-
2 files changed, 75 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 2cf2ea6..c331386 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -34,6 +34,74 @@ static HLIST_HEAD(clk_root_list);
static HLIST_HEAD(clk_orphan_list);
static LIST_HEAD(clk_notifier_list);
+/**
+ * clk_readl_default - default clock register read support function
+ * @reg: register to read
+ *
+ * Default implementation for reading a clock register.
+ */
+static u32 clk_readl_default(u32 __iomem *reg)
+{
+ return readl(reg);
+}
+
+/**
+ * clk_writel_default - default clock register write support function
+ * @val: value to write
+ * @reg: register to write to
+ *
+ * Default implementation for writing a clock register.
+ */
+static void clk_writel_default(u32 val, u32 __iomem *reg)
+{
+ writel(val, reg);
+}
+
+struct clk_reg_ops clk_reg_ops_default = {
+ .clk_readl = clk_readl_default,
+ .clk_writel = clk_writel_default
+};
+
+static struct clk_reg_ops *clk_reg_ops = clk_reg_ops_default;
+
+/**
+ * clk_register_reg_ops - register access functions for clock registers
+ * @ops: register level ops
+ *
+ * Registers platform or SoC specific operations for reading / writing
+ * clock registers.
+ */
+int clk_register_reg_ops(struct clk_reg_ops *ops)
+{
+ if (!ops)
+ return -EINVAL;
+ clk_reg_ops = ops;
+ return 0;
+}
+
+/**
+ * clk_readl - read a clock register value from hardware
+ * @reg: register to read
+ *
+ * Uses the registered clk_reg_ops to read a hardware clock register value.
+ */
+u32 clk_readl(u32 __iomem *reg)
+{
+ return clk_reg_ops-clk_readl(reg);
+}
+
+/**
+ * clk_writel - write a clock register value to hardware
+ * @val: value to write
+ * @reg: register to write
+ *
+ * Uses the registered clk_reg_ops to write a hardware clock register value.
+ */
+void clk_writel(u32 val, u32 __iomem *reg)
+{
+ clk_reg_ops-clk_writel(val, reg);
+}
+
/*** locking ***/
static void clk_prepare_lock(void)
{
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 7e59253..16e4df2 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -512,15 +512,14 @@ static inline const char *of_clk_get_parent_name(struct
device_node *np,
* for improved portability across platforms
*/
-static inline u32 clk_readl(u32 __iomem *reg)
-{
- return readl(reg);
-}
+struct clk_reg_ops {
+ u32 (*clk_readl)(u32 __iomem *reg);
+ void (*clk_writel)(u32 val, u32 __iomem *reg);
+};
-static inline void clk_writel(u32 val, u32 __iomem *reg)
-{
- writel(val, reg);
-}
+u32 clk_readl(u32 __iomem *reg);
+void clk_writel(u32 val, u32 __iomem *reg);
+int clk_register_reg_ops(struct clk_reg_ops *ops);
#endif /* CONFIG_COMMON_CLK */
#endif /* CLK_PROVIDER_H */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv10 00/41] ARM: TI SoC clock DT conversion
Quoting Tero Kristo (2013-11-26 00:05:41)
Hi,
Changes compared to v9:
- rebased on top of 3.13-rc1
- modified the low level clk register API to provide SoC specific clk_readl
and clk_writel support which can be registered during boot, TI SoC variant
uses regmap on low level
- dropped regmap parameter from clock init calls, instead a helper is used
for getting regmap index along with the register offset from DT
- dropped regmap parameter from clock structs, instead platform specific
clk_readl / clk_writel are used to parse reg parameter according to
platform, for TI SoC:s, this is encoded as:
struct clk_omap_reg {
u16 offset; /* register offset */
u16 index; /* regmap index */
}
- Nishanth's comments to v9 mostly addressed, except for the CLK_OF_DECLARE
tweak which I would actually want some feedback upon, basically the problem
is I need to return status from the clk init functions so I can see if
-EAGAIN is passed, in which case init will be retried later, maybe some of
this can be made generic, like converting all the CLK_OF_DECLARE type
functions to return status
Testing done:
- omap3-beagle : boot + suspend/resume
- omap3-beagle-xm : boot (thanks to Nishanth)
- omap4-panda-es : boot + suspend/resume
A quick note in testing: trace_clk_div_ck ends up as an orphan clock on
my Panda ES.
Regards,
Mike
- omap5-uevm : boot
- dra7-evm : boot
- am335x-bone : boot
Separate branches available at https://github.com/t-kristo/linux-pm.git
- full: 3.13-rc1-dt-clks-v10 (should be merged last, contains everything)
- clk driver only: 3.13-rc1-dt-clks-v10-for-mike
- DT data only: 3.13-rc1-dt-clks-v10-for-benoit
-Tero
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] ARM: OMAP4: dts: Add main and optional clock data into DT
Quoting Rajendra Nayak (2013-12-12 03:38:29)
With support to parse clock data from DT, move all main and optional
clock information from hwmod to DT.
We still retain clocks in hwmod for devices which do not have a DT node.
Signed-off-by: Rajendra Nayak rna...@ti.com
Reviewed-by: Mike Turquette mturque...@linaro.org
---
arch/arm/boot/dts/omap4.dtsi | 100 +++
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 122
2 files changed, 100 insertions(+), 122 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index c2e3993..7eb7920 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -139,6 +139,8 @@
compatible = ti,omap-counter32k;
reg = 0x4a304000 0x20;
ti,hwmods = counter_32k;
+ clocks = sys_32k_ck;
+ clock-names = fck;
};
omap4_pmx_core: pinmux@4a100040 {
@@ -172,6 +174,8 @@
#dma-cells = 1;
#dma-channels = 32;
#dma-requests = 127;
+ clocks = l3_div_ck;
+ clock-names = fck;
};
gpio1: gpio@4a31 {
@@ -184,6 +188,8 @@
#gpio-cells = 2;
interrupt-controller;
#interrupt-cells = 2;
+ clocks = l4_wkup_clk_mux_ck, gpio1_dbclk;
+ clock-names = fck, dbclk;
};
gpio2: gpio@48055000 {
@@ -195,6 +201,8 @@
#gpio-cells = 2;
interrupt-controller;
#interrupt-cells = 2;
+ clocks = l4_div_ck, gpio2_dbclk;
+ clock-names = fck, dbclk;
};
gpio3: gpio@48057000 {
@@ -206,6 +214,8 @@
#gpio-cells = 2;
interrupt-controller;
#interrupt-cells = 2;
+ clocks = l4_div_ck, gpio3_dbclk;
+ clock-names = fck, dbclk;
};
gpio4: gpio@48059000 {
@@ -217,6 +227,8 @@
#gpio-cells = 2;
interrupt-controller;
#interrupt-cells = 2;
+ clocks = l4_div_ck, gpio4_dbclk;
+ clock-names = fck, dbclk;
};
gpio5: gpio@4805b000 {
@@ -228,6 +240,8 @@
#gpio-cells = 2;
interrupt-controller;
#interrupt-cells = 2;
+ clocks = l4_div_ck, gpio5_dbclk;
+ clock-names = fck, dbclk;
};
gpio6: gpio@4805d000 {
@@ -239,6 +253,8 @@
#gpio-cells = 2;
interrupt-controller;
#interrupt-cells = 2;
+ clocks = l4_div_ck, gpio6_dbclk;
+ clock-names = fck, dbclk;
};
gpmc: gpmc@5000 {
@@ -259,6 +275,8 @@
interrupts = GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = uart1;
clock-frequency = 4800;
+ clocks = func_48m_fclk;
+ clock-names = fck;
};
uart2: serial@4806c000 {
@@ -267,6 +285,8 @@
interrupts = GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = uart2;
clock-frequency = 4800;
+ clocks = func_48m_fclk;
+ clock-names = fck;
};
uart3: serial@4802 {
@@ -275,6 +295,8 @@
interrupts = GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = uart3;
clock-frequency = 4800;
+ clocks = func_48m_fclk;
+ clock-names = fck;
};
uart4: serial@4806e000 {
@@ -283,6 +305,8 @@
interrupts = GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = uart4;
clock-frequency = 4800;
+ clocks = func_48m_fclk;
+ clock-names = fck;
};
hwspinlock: spinlock@4a0f6000 {
@@ -298,6 +322,8 @@
#address-cells = 1;
#size-cells = 0;
ti,hwmods = i2c1;
+ clocks = func_96m_fclk;
+ clock-names = fck
Re: [PATCHv10 10/41] CLK: TI: add support for clockdomain binding
Quoting Tero Kristo (2013-11-26 00:05:51)
Some OMAP clocks require knowledge about their parent clockdomain for
book keeping purposes. This patch creates a new DT binding for TI
clockdomains, which act as a collection of device clocks.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
.../devicetree/bindings/clock/ti/clockdomain.txt | 21 ++
arch/arm/mach-omap2/clock.h|1 -
drivers/clk/ti/Makefile|3 +-
drivers/clk/ti/clockdomain.c | 70
include/linux/clk/ti.h |3 +
5 files changed, 96 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/ti/clockdomain.txt
create mode 100644 drivers/clk/ti/clockdomain.c
diff --git a/Documentation/devicetree/bindings/clock/ti/clockdomain.txt
b/Documentation/devicetree/bindings/clock/ti/clockdomain.txt
new file mode 100644
index 000..45e6f7c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/clockdomain.txt
@@ -0,0 +1,21 @@
+Binding for Texas Instruments clockdomain.
+
+Binding status: Unstable - ABI compatibility may be broken in the future
+
+This binding uses the common clock binding[1]. Every clock on
The patch looks fine to me but I think that the binding description
should capture the fact that you are re-using the common clock binding
but that this binding definition does not define any new clocks or clock
controllers in the way that a typical clock binding would.
This code uses the 'clocks' property the same way that any other
consumer binding definition would, such as an MMC controller or UART.
Those bindings do not say that they are based on the common clock
binding AFAIK.
Regards,
Mike
+TI SoC belongs to one clockdomain, but software only needs this
+information for specific clocks which require their parent
+clockdomain to be controlled when the clock is enabled/disabled.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be ti,clockdomain
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : link phandles of clocks within this domain
+
+Examples:
+ dss_clkdm: dss_clkdm {
+ compatible = ti,clockdomain;
+ clocks = dss1_alwon_fck_3430es2, dss_ick_3430es2;
+ };
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index bc0f9fc..6bd72b5 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -38,7 +38,6 @@ struct omap_clk {
}
struct clockdomain;
-#define to_clk_hw_omap(_hw) container_of(_hw, struct clk_hw_omap, hw)
#define DEFINE_STRUCT_CLK(_name, _parent_array_name, _clkops_name) \
static struct clk _name = { \
diff --git a/drivers/clk/ti/Makefile b/drivers/clk/ti/Makefile
index 7cba389..67056fb 100644
--- a/drivers/clk/ti/Makefile
+++ b/drivers/clk/ti/Makefile
@@ -1,4 +1,5 @@
ifneq ($(CONFIG_OF),)
obj-y += clk.o dpll.o autoidle.o divider.o \
- fixed-factor.o gate.o composite.o
+ fixed-factor.o gate.o
clockdomain.o \
+ composite.o
endif
diff --git a/drivers/clk/ti/clockdomain.c b/drivers/clk/ti/clockdomain.c
new file mode 100644
index 000..f1e0038
--- /dev/null
+++ b/drivers/clk/ti/clockdomain.c
@@ -0,0 +1,70 @@
+/*
+ * OMAP clockdomain support
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Tero Kristo t-kri...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk-provider.h
+#include linux/slab.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/clk/ti.h
+
+#undef pr_fmt
+#define pr_fmt(fmt) %s: fmt, __func__
+
+static void __init of_ti_clockdomain_setup(struct device_node *node)
+{
+ struct clk *clk;
+ struct clk_hw *clk_hw;
+ const char *clkdm_name = node-name;
+ int i;
+ int num_clks;
+
+ num_clks = of_count_phandle_with_args(node, clocks, #clock-cells);
+
+ for (i = 0; i num_clks; i++) {
+ clk = of_clk_get(node, i);
+ if (__clk_get_flags(clk) CLK_IS_BASIC) {
+ pr_warn(can't setup clkdm for basic clk %s\n,
+ __clk_get_name(clk));
+ continue;
+ }
+
Re: [PATCHv10 00/41] ARM: TI SoC clock DT conversion
Quoting Tero Kristo (2013-11-26 00:05:41)
Hi,
Hi Tero,
Thanks for your long suffering patience on this series. The clock
patches look very good to me with exception of a few small comments. Let
me know how I can help with the hierarchal DT stuff since I think that
has been the gating factor for this series for the past few revisions.
Changes compared to v9:
- rebased on top of 3.13-rc1
- modified the low level clk register API to provide SoC specific clk_readl
and clk_writel support which can be registered during boot, TI SoC variant
uses regmap on low level
Regarding regmap, will that be dropped for V11? I don't care whether it
stays or goes but the approach you took is probably too top-level. Patch
#1 sets clk_reg_ops system-wide which probably isn't right. Different
clock drivers might compete to set those ops and the last one to write
wins.
A better approach is to support regmap ops on a per-clock basis (for
clocks that use the generic implementations like clk-divider and
clk-gate; obviously this is overkill for entirely hardware-specific
clocks). Stephen Boyd's approach is a better solution[1][2] but
unfortunately that approach dumps crap into struct clk_hw which is bad.
Anyways if you decide against regmap for V11 then the whole issue is
avoided.
Regards,
Mike
[1] http://article.gmane.org/gmane.linux.ports.arm.kernel/273742
[2] http://article.gmane.org/gmane.linux.ports.arm.kernel/273744
- dropped regmap parameter from clock init calls, instead a helper is used
for getting regmap index along with the register offset from DT
- dropped regmap parameter from clock structs, instead platform specific
clk_readl / clk_writel are used to parse reg parameter according to
platform, for TI SoC:s, this is encoded as:
struct clk_omap_reg {
u16 offset; /* register offset */
u16 index; /* regmap index */
}
- Nishanth's comments to v9 mostly addressed, except for the CLK_OF_DECLARE
tweak which I would actually want some feedback upon, basically the problem
is I need to return status from the clk init functions so I can see if
-EAGAIN is passed, in which case init will be retried later, maybe some of
this can be made generic, like converting all the CLK_OF_DECLARE type
functions to return status
Testing done:
- omap3-beagle : boot + suspend/resume
- omap3-beagle-xm : boot (thanks to Nishanth)
- omap4-panda-es : boot + suspend/resume
- omap5-uevm : boot
- dra7-evm : boot
- am335x-bone : boot
Separate branches available at https://github.com/t-kristo/linux-pm.git
- full: 3.13-rc1-dt-clks-v10 (should be merged last, contains everything)
- clk driver only: 3.13-rc1-dt-clks-v10-for-mike
- DT data only: 3.13-rc1-dt-clks-v10-for-benoit
-Tero
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/11] ARM: OMAP3: clock: add API to enable/disable autoidle for a single clock
Quoting Paul Walmsley (2013-10-19 10:16:50)
On Fri, 11 Oct 2013, Tero Kristo wrote:
Some drivers require direct access to the autoidle functionality of the
interface clocks. Added clock APIs for these, so that the drivers do not
need to access CM registers directly.
Signed-off-by: Tero Kristo t-kri...@ti.com
Thanks, queued. Please coordinate with Mike to get
allow_idle/deny_idle-type interfaces into the Common Clock Framework, so
these can be replaced with standard CCF-type allow_idle() deny_idle()
functions. That interface should include use-counting so multiple callers
can use allow_idle() and deny_idle() without stomping on each other.
Where and when are these functions called? IIRC these are only accessed
at boot/init time, though I may be wrong. If they are a boot-time thing
then the .init callback provided in struct clk may be sufficient.
Regards,
Mike
- Paul
---
arch/arm/mach-omap2/clock.c | 38 ++
arch/arm/mach-omap2/clock.h |2 ++
2 files changed, 40 insertions(+)
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index 0c38ca9..c7c5d31 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -543,6 +543,44 @@ int omap2_clk_disable_autoidle_all(void)
}
/**
+ * omap2_clk_deny_idle - disable autoidle on an OMAP clock
+ * @clk: struct clk * to disable autoidle for
+ *
+ * Disable autoidle on an OMAP clock.
+ */
+int omap2_clk_deny_idle(struct clk *clk)
+{
+ struct clk_hw_omap *c;
+
+ if (__clk_get_flags(clk) CLK_IS_BASIC)
+ return -EINVAL;
+
+ c = to_clk_hw_omap(__clk_get_hw(clk));
+ if (c-ops c-ops-deny_idle)
+ c-ops-deny_idle(c);
+ return 0;
+}
+
+/**
+ * omap2_clk_allow_idle - enable autoidle on an OMAP clock
+ * @clk: struct clk * to enable autoidle for
+ *
+ * Enable autoidle on an OMAP clock.
+ */
+int omap2_clk_allow_idle(struct clk *clk)
+{
+ struct clk_hw_omap *c;
+
+ if (__clk_get_flags(clk) CLK_IS_BASIC)
+ return -EINVAL;
+
+ c = to_clk_hw_omap(__clk_get_hw(clk));
+ if (c-ops c-ops-allow_idle)
+ c-ops-allow_idle(c);
+ return 0;
+}
+
+/**
* omap2_clk_enable_init_clocks - prepare enable a list of clocks
* @clk_names: ptr to an array of strings of clock names to enable
* @num_clocks: number of clock names in @clk_names
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index 7aa32cd..82916cc 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -411,6 +411,8 @@ void omap2_clk_dflt_find_idlest(struct clk_hw_omap *clk,
void omap2_init_clk_hw_omap_clocks(struct clk *clk);
int omap2_clk_enable_autoidle_all(void);
int omap2_clk_disable_autoidle_all(void);
+int omap2_clk_allow_idle(struct clk *clk);
+int omap2_clk_deny_idle(struct clk *clk);
void omap2_clk_enable_init_clocks(const char **clk_names, u8 num_clocks);
int omap2_clk_switch_mpurate_at_boot(const char *mpurate_ck_name);
void omap2_clk_print_new_rates(const char *hfclkin_ck_name,
--
1.7.9.5
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Odd behavior with dpll4_m4x2_ck on omap3 + DT
Quoting Paul Walmsley (2013-10-07 01:21:16) On Tue, 10 Sep 2013, Tero Kristo wrote: In theory, DPLLs can also be used in their bypass mode to feed customer nodes clocks. I just think the check in the clkoutx2_recalc is wrong, and should be enhanced to actually check what is the target mode for the clock once it is enabled. Maybe something like this would work properly: diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c index 3a0296c..ba218fb 100644 --- a/arch/arm/mach-omap2/dpll3xxx.c +++ b/arch/arm/mach-omap2/dpll3xxx.c @@ -658,14 +658,12 @@ unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw, dd = pclk-dpll_data; - WARN_ON(!dd-enable_mask); - - v = __raw_readl(dd-control_reg) dd-enable_mask; - v = __ffs(dd-enable_mask); - if ((v != OMAP3XXX_EN_DPLL_LOCKED) || (dd-flags DPLL_J_TYPE)) + if ((dd-flags DPLL_J_TYPE) || + __clk_get_rate(dd-clk_bypass) == __clk_get_rate(pclk)) rate = parent_rate; else rate = parent_rate * 2; + return rate; } [...] Getting comment from someone like Paul would probably help here. Looks like this is a regression from the CCF port. Seems to me that the code above assumes that when the DPLL's rate is set to the same rate as the bypass clock's rate, we can assume that the DPLL is in bypass. I wonder if that's valid in a case where a previous OS or bootloader may have programmed the DPLL. Well it used to be that calling clk_set_rate(dpll, bypass_rate) would put it in bypass, I don't know if that is still the case. But you are right that having the implicit assumption that 'bypass rate' == 'DPLL in bypass' is not safe since a bootloader could lock this PLL to the same rate as it's bypass rate. I hope that the bypass rate stuff does not get swept away in the changes since it is an interesting way to save a little power. Regards, Mike Sounds to me like the best way to fix it would be to test whether this code is intended to return the target rate (when the struct clk representing the DPLL is disabled), versus the current rate (when the struct clk representing the DPLL is enabled). If it's the target rate, then there's no point checking the current state of the hardware. A check similar to the above would probably be fine. Otherwise, seems best to use the existing code that does test the PLL state. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv7 20/36] CLK: TI: DRA7: Add APLL support
Quoting Tero Kristo (2013-09-25 01:48:26)
+
+static const struct clk_ops apll_ck_ops = {
+ .enable = dra7_apll_enable,
+ .disable= dra7_apll_disable,
Looks like .is_enabled is missing?
Also have you thought about using .prepare or .unprepare for these PLLs
which might take some time to lock? The code there doesn't sleep or
schedule, but it does poll for some time while under a spinlock.
Something to think about for a future patch.
Regards,
Mike
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv7 00/36] ARM: OMAP: clock data conversion to DT
Quoting Tero Kristo (2013-09-25 01:48:06) Hi all, Version 7 contains following high level changes: - Dropped support for basic bindings from Mike Turquette, instead using vendor specific bindings for all clocks - Mux clock + divider clock vendor specific bindings get rid of use of the bit-masks, instead these are generated runtime based on parent clock / divider min/max info, see individual patches for details - Added support for dummy_ck nodes, was missing from previous version - Fixed support for omap3630 - Added support for new clock node type: ti,mux-gate-clock (using composite clock type) - OMAP4 / OMAP5 only build fixes (compiler flag checks added to some files) - most of the of_omap_* calls renamed to of_ti_* - Rebased on top of v3.12-rc2 Hi Tero, I had one really minor request for one of the patches, otherwise I'm pretty happy with this series and I can take in the clock parts for 3.13. A few general comments: 1) I think I mentioned some time back that it would be wise to put a disclaimer at the top of each DT binding description stating something to the effect: Binding status: Unstable - ABI compatibility may be broken in the future. Are you OK merging these bindings as-is without that kind of a disclaimer? 2) I hope to see the clockdomain stuff go away in the future. I'm OK to take it for now to aid in this DT transition but I would like some commitment that it will not stay in drivers/clk/omap forever. I guess for clockdomain you'll need to figure out how to handle those in a generic driver way. 3) Same concern as above but for the DT clkdev alias stuff. I guess you'll need to make all of the dependent drivers play nice with DT. Do you plan to remove it within a reasonable timeframe? It would be a nice reduction in LoC and more importantly it would mean that drivers were using clkdev in a more-correct fashion. Regards, Mike Some detailed comments about patch level changes (if no mention, no major changes): - Patch #1: * removed use of reg-names property, instead registers mapped using compatible string * removed ti,modes property, instead uses DPLL mode flags now * separated AM33XX DPLLs under their own compatible strings - Patch #4 #5: new patches - Patch #6: merged basic gate support from Mike to this patch as vendor specific gate clock support - Patch #9 #10: new patches - Patch #11: dummy clocks added, USB / ABE DPLL setup ordering changed - Patch #14: dummy clocks added - Patch #20: dropped usage of reg-names property - Patch #21: dummy clocks added - Patch #22 #23: new patches - Patch #30: AM35XX clock data added to this patch - Patch #31: * dummy clocks added * added missing 3630 clocks Test branch available here: https://github.com/t-kristo/linux-pm.git branch: mainline-3.12-rc2-ti-dt-clks-v7 Testing done: - am335x-bone : boot only - omap5-sevm : boot only - dra7-evm : boot only - omap3-beagle : boot + suspend/resume (ret + off) - omap4-panda-es : boot + suspend/resume Nishanth has also been doing some tests with omap3-beagle-xm with some WIP versions of this branch, but not with this latest one. Nishanth, maybe you can provide test results to this one also? -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/11] omapdss: HDMI: create a HDMI PLL library
Quoting Archit Taneja (2013-09-17 00:06:28)
HDMI PLL is a block common to DSS in OMAP4, OMAP5 and DRA7x. Move the
existing PLL functions from ti_hdmi_4xxx_ip.c and hdmi.c to a separate file.
These funcs are called directly from the hdmi driver rather than hdmi_ip_ops
function pointer calls.
Add the PLL library function declarations to ti_hdmi.h. These will be shared
amongst the omap4/5 hdmi platform drivers. Remove the PLL function pointer ops
from the ti_hdmi_ip_ops struct. These will be shared amongst the omap4/5 hdmi
platform drivers and other libraries.
Signed-off-by: Archit Taneja arc...@ti.com
Would be cool to see this convert to the common clock framework
implementation (include/linux/clk-provider.h). It appears that this PLL
only needs to support .enable, .disable and .recalc_rate callbacks at
first glance.
Regards,
Mike
---
drivers/video/omap2/dss/Makefile | 2 +-
drivers/video/omap2/dss/dss_features.c| 3 -
drivers/video/omap2/dss/hdmi.c| 65 ++--
drivers/video/omap2/dss/hdmi_pll.c| 243
++
drivers/video/omap2/dss/ti_hdmi.h | 25 +--
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 132
6 files changed, 267 insertions(+), 203 deletions(-)
create mode 100644 drivers/video/omap2/dss/hdmi_pll.c
diff --git a/drivers/video/omap2/dss/Makefile
b/drivers/video/omap2/dss/Makefile
index 56ce6bd..5ea65d3 100644
--- a/drivers/video/omap2/dss/Makefile
+++ b/drivers/video/omap2/dss/Makefile
@@ -10,5 +10,5 @@ omapdss-$(CONFIG_OMAP2_DSS_RFBI) += rfbi.o
omapdss-$(CONFIG_OMAP2_DSS_VENC) += venc.o
omapdss-$(CONFIG_OMAP2_DSS_SDI) += sdi.o
omapdss-$(CONFIG_OMAP2_DSS_DSI) += dsi.o
-omapdss-$(CONFIG_OMAP4_DSS_HDMI) += hdmi.o hdmi_wp.o ti_hdmi_4xxx_ip.o
+omapdss-$(CONFIG_OMAP4_DSS_HDMI) += hdmi.o hdmi_wp.o hdmi_pll.o
ti_hdmi_4xxx_ip.o
ccflags-$(CONFIG_OMAP2_DSS_DEBUG) += -DDEBUG
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index db359e8..9ee92e9 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -797,10 +797,7 @@ static const struct ti_hdmi_ip_ops omap4_hdmi_functions
= {
.phy_enable = ti_hdmi_4xxx_phy_enable,
.phy_disable= ti_hdmi_4xxx_phy_disable,
.read_edid = ti_hdmi_4xxx_read_edid,
- .pll_enable = ti_hdmi_4xxx_pll_enable,
- .pll_disable= ti_hdmi_4xxx_pll_disable,
.dump_core = ti_hdmi_4xxx_core_dump,
- .dump_pll = ti_hdmi_4xxx_pll_dump,
.dump_phy = ti_hdmi_4xxx_phy_dump,
#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
.audio_start= ti_hdmi_4xxx_audio_start,
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index f2475fc..f6a2eba 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -42,7 +42,6 @@
#define HDMI_CORE_SYS 0x400
#define HDMI_CORE_AV 0x900
-#define HDMI_PLLCTRL 0x200
#define HDMI_PHY 0x300
/* HDMI EDID Length move this */
@@ -53,9 +52,6 @@
#define EDID_SIZE_BLOCK0_TIMING_DESCRIPTOR 4
#define EDID_SIZE_BLOCK1_TIMING_DESCRIPTOR 4
-#define HDMI_DEFAULT_REGN 16
-#define HDMI_DEFAULT_REGM2 1
-
static struct {
struct mutex lock;
struct platform_device *pdev;
@@ -428,52 +424,6 @@ end: return cm;
}
-static void hdmi_compute_pll(struct omap_dss_device *dssdev, int phy,
- struct hdmi_pll_info *pi)
-{
- unsigned long clkin, refclk;
- u32 mf;
-
- clkin = clk_get_rate(hdmi.sys_clk) / 1;
- /*
-* Input clock is predivided by N + 1
-* out put of which is reference clk
-*/
-
- pi-regn = HDMI_DEFAULT_REGN;
-
- refclk = clkin / pi-regn;
-
- pi-regm2 = HDMI_DEFAULT_REGM2;
-
- /*
-* multiplier is pixel_clk/ref_clk
-* Multiplying by 100 to avoid fractional part removal
-*/
- pi-regm = phy * pi-regm2 / refclk;
-
- /*
-* fractional multiplier is remainder of the difference between
-* multiplier and actual phy(required pixel clock thus should be
-* multiplied by 2^18(262144) divided by the reference clock
-*/
- mf = (phy - pi-regm / pi-regm2 * refclk) * 262144;
- pi-regmf = pi-regm2 * mf / refclk;
-
- /*
-* Dcofreq should be set to 1 if required pixel clock
-* is greater than 1000MHz
-*/
- pi-dcofreq = phy 1000 * 100;
- pi-regsd = ((pi-regm * clkin / 10) / (pi-regn * 250) + 5) / 10;
-
- /* Set the reference clock to sysclk reference */
- pi-refsel = HDMI_REFSEL_SYSCLK;
-
- DSSDBG(M = %d Mf = %d\n, pi-regm,
Re: [PATCH 02/11] omapdss: HDMI: create a HDMI PLL library
On Tue, Sep 17, 2013 at 3:02 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On 17/09/13 12:38, Mike Turquette wrote: Quoting Archit Taneja (2013-09-17 00:06:28) HDMI PLL is a block common to DSS in OMAP4, OMAP5 and DRA7x. Move the existing PLL functions from ti_hdmi_4xxx_ip.c and hdmi.c to a separate file. These funcs are called directly from the hdmi driver rather than hdmi_ip_ops function pointer calls. Add the PLL library function declarations to ti_hdmi.h. These will be shared amongst the omap4/5 hdmi platform drivers. Remove the PLL function pointer ops from the ti_hdmi_ip_ops struct. These will be shared amongst the omap4/5 hdmi platform drivers and other libraries. Signed-off-by: Archit Taneja arc...@ti.com Would be cool to see this convert to the common clock framework implementation (include/linux/clk-provider.h). It appears that this PLL only needs to support .enable, .disable and .recalc_rate callbacks at first glance. We've got a (very) long term plan to use CCF for DSS. And, if I'm not mistaken, the PLL used for HDMI and DSI is the same as used elsewhere in OMAP (I don't remember the PLL type name). I think the main issue with DSS clocks is that we require as exact clocks as possible, and there are multiple dividers/multipliers on the clock path. So we iterate over the divider/multiplier ranges, trying to find as good freq match as possible. So if the clock path is composed from black boxes, and we can only ask for a certain frequency, and get back probably some other frequency, it gets quite difficult to find good clock matches. Well, at least I imagine so, I have not tried to implement that. I hope that the existing CLK_SET_RATE_PARENT flag could help you get the frequency you need; it causes a call to clk_set_rate(leaf_clk, target_rate) to walk up the chain of parents and configure rates as needed. However I have been looking at standardizing a way to define clock rate tables, possibly in DT. In many cases it is a board-specific issue (e.g. different oscillators or other reference clocks that feed into the SoC) and specifying rate tables in DT is one way to store known-good configurations for complex clock subtrees. Regards, Mike Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Odd behavior with dpll4_m4x2_ck on omap3 + DT
Quoting Tero Kristo (2013-09-13 04:34:54) On 09/13/2013 10:51 AM, Stefan Roese wrote: On 11.09.2013 09:21, Tomi Valkeinen wrote: On 10/09/13 16:17, Tero Kristo wrote: In theory, DPLLs can also be used in their bypass mode to feed customer nodes clocks. I just think the check in the clkoutx2_recalc is wrong, and should be enhanced to actually check what is the target mode for the clock once it is enabled. Maybe something like this would work properly: diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c index 3a0296c..ba218fb 100644 --- a/arch/arm/mach-omap2/dpll3xxx.c +++ b/arch/arm/mach-omap2/dpll3xxx.c @@ -658,14 +658,12 @@ unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw, dd = pclk-dpll_data; - WARN_ON(!dd-enable_mask); - - v = __raw_readl(dd-control_reg) dd-enable_mask; - v = __ffs(dd-enable_mask); - if ((v != OMAP3XXX_EN_DPLL_LOCKED) || (dd-flags DPLL_J_TYPE)) + if ((dd-flags DPLL_J_TYPE) || + __clk_get_rate(dd-clk_bypass) == __clk_get_rate(pclk)) rate = parent_rate; else rate = parent_rate * 2; + return rate; } Stefan, are you able to test the above? I'd rather have a proper fix for this, than hack omapdss =). Okay, I finally found some time to test this. The patch above generates this warning: arch/arm/mach-omap2/dpll3xxx.c: In function 'omap3_clkoutx2_recalc': arch/arm/mach-omap2/dpll3xxx.c:663:6: warning: passing argument 1 of '__clk_get_rate' from incompatible pointer type [enabled by default] include/linux/clk-provider.h:423:15: note: expected 'struct clk *' but argument is of type 'struct clk_hw_omap *' Yea sorry about that, I just quickly hacked the patch together without testing it at all. :P I then changed it (not 100% sure if correctly) to this version: + if ((dd-flags DPLL_J_TYPE) || + __clk_get_rate(dd-clk_bypass) == __clk_get_rate(pclk-hw.clk)) And this seems to work. At least the clock rate mismatch warning does not appear with this patch applied (and without the clk_enable) in the bootlog any more. Yea, looks good to me, however I guess I would like second opinion on this also. Looks right to me. Regards, Mike -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Odd behavior with dpll4_m4x2_ck on omap3 + DT
Quoting Tero Kristo (2013-09-10 06:17:45) On 09/10/2013 03:40 PM, Tomi Valkeinen wrote: On 10/09/13 15:24, Tero Kristo wrote: On 09/10/2013 03:19 PM, Tomi Valkeinen wrote: On 10/09/13 15:12, Tero Kristo wrote: If it claims it is not locked, it means the DPLL itself is disabled. You could try clk_enable for the clock before doing clk_set_rate. Hmm, so is it required to enable the clock before setting the rate? If so, I think I'm using the clocks wrong in all the places =). In generic case, it is not. But DPLLs behave strangely if they go to low power stop mode. If there is any downstream clock enabled for a specific DPLL it is enabled and things work okay. One could also argue that the API behavior in OMAP is wrong currently, as the bypass rate is something you are most likely never actually going to use for anything Just try the change and check the results. Ok, so as Stefan said, enabling the clock fixes the issue. How do you suggest we fix this? Changing omapdss to enable the clock before changing its rate is not very difficult, so it can be used as a quick fix. But it doesn't sound like a proper fix if this is not normally required. The quick fix sounds good to me. And, maybe I'm missing something as I don't have good understanding of the PRCM's PLLs, but the current behavior sounds odd. So the DPLL is off, and in bypass mode. When we try to change the rate of the clock provided by the PLL, shouldn't it fail, as bypass mode's rate cannot be changed? Or better, change the non-bypass rate. In theory, DPLLs can also be used in their bypass mode to feed customer nodes clocks. I just think the check in the clkoutx2_recalc is wrong, and should be enhanced to actually check what is the target mode for the clock once it is enabled. Maybe something like this would work properly: diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c index 3a0296c..ba218fb 100644 --- a/arch/arm/mach-omap2/dpll3xxx.c +++ b/arch/arm/mach-omap2/dpll3xxx.c @@ -658,14 +658,12 @@ unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw, dd = pclk-dpll_data; - WARN_ON(!dd-enable_mask); - - v = __raw_readl(dd-control_reg) dd-enable_mask; - v = __ffs(dd-enable_mask); - if ((v != OMAP3XXX_EN_DPLL_LOCKED) || (dd-flags DPLL_J_TYPE)) + if ((dd-flags DPLL_J_TYPE) || + __clk_get_rate(dd-clk_bypass) == __clk_get_rate(pclk)) Two quick asides here: 1) might be nice if the J_TYPE pll was it's own clock type 2) would be nice if the check for bypass used something like: if (clk_get_parent(hw-clk) == dd-bypass_clk) rate = parent_rate; Which implies that the DPLLs become proper mux clocks. Regards, Mike rate = parent_rate; else rate = parent_rate * 2; + return rate; } How is the DPLL4's clock rate 43200 anyway in bypass mode. Isn't bypass mode usually plain sys-clock, or such? This again reflects the rate that the clock has once it is enabled, the clkoutx2 does not. Getting comment from someone like Paul would probably help here. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv6 01/45] CLK: TI: Add DPLL clock support
Quoting Tero Kristo (2013-08-29 06:15:53)
The OMAP clock driver now supports DPLL clock type. This patch also
adds support for DT DPLL nodes.
Signed-off-by: Tero Kristo t-kri...@ti.com
Tero,
Overall this patch is really great. Some minor comments below.
diff --git a/Documentation/devicetree/bindings/clock/ti/dpll.txt
b/Documentation/devicetree/bindings/clock/ti/dpll.txt
new file mode 100644
index 000..83c21c6
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/dpll.txt
@@ -0,0 +1,68 @@
+Binding for Texas Instruments DPLL clock.
+
+This binding uses the common clock binding[1]. It assumes a
+register-mapped DPLL with usually two selectable input clocks
+(reference clock and bypass clock), with digital phase locked
+loop logic for multiplying the input clock to a desired output
+clock. This clock also typically supports different operation
+modes (locked, low power stop etc.) This binding has several
+sub-types, which effectively result in slightly different setup
+for the actual DPLL clock.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be one of:
+ ti,omap4-dpll-x2-clock,
+ ti,omap3-dpll-clock,
+ ti,omap3-dpll-core-clock,
+ ti,omap3-dpll-per-clock,
+ ti,omap3-dpll-per-j-type-clock,
+ ti,omap4-dpll-clock,
+ ti,omap4-dpll-core-clock,
+ ti,omap4-dpll-m4xen-clock,
+ ti,omap4-dpll-j-type-clock,
+ ti,omap4-dpll-no-gate-clock,
+ ti,omap4-dpll-no-gate-j-type-clock,
+
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : link phandles of parent clocks, first entry lists reference clock
+ and second entry bypass clock
+- reg : address and length of the register set for controlling the DPLL.
+ It contains the information of registers in the same order as described by
+ reg-names.
+- reg-names : array of the register names for controlling the device, sorted
+ in the same order as the reg property.
+ control - contains the control register base address
+idlest - contains the idle status register base address
+autoidle - contains the autoidle register base address
+mult-div1 - contains the multiplier / divider register base address
+
+Optional properties:
+- ti,modes : available modes for the DPLL, bitmask of:
+ 0x02 - DPLL supports low power stop mode
+ 0x20 - DPLL can be put to low power bypass mode
+ 0x80 - DPLL can be put to lock mode (running)
Any particular reason to use a bitmask here versus flags/DT properties?
Something like
Optional properties:
low-power-stop : DPLL supports low power stop mode, gating output
low-power-bypass : DPLL output matches rate of parent bypass clock
lock : DPLL locks in programmed rate
Is there ever a time when a DPLL does not support the locked state? We
can probably remove that from binding entirely.
+ Other values currently unsupported.
+- ti,clkdm-name : clockdomain name for the DPLL
What does this mean? I thought that the clockdomain data would not go
into the clock binding?
diff --git a/drivers/clk/ti/dpll.c b/drivers/clk/ti/dpll.c
new file mode 100644
index 000..3f4236d
--- /dev/null
+++ b/drivers/clk/ti/dpll.c
@@ -0,0 +1,476 @@
+/*
+ * OMAP DPLL clock support
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Tero Kristo t-kri...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk-provider.h
+#include linux/slab.h
+#include linux/err.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/clk/ti.h
+
+static const struct clk_ops dpll_m4xen_ck_ops = {
+ .enable = omap3_noncore_dpll_enable,
+ .disable= omap3_noncore_dpll_disable,
+ .recalc_rate= omap4_dpll_regm4xen_recalc,
+ .round_rate = omap4_dpll_regm4xen_round_rate,
+ .set_rate = omap3_noncore_dpll_set_rate,
+ .get_parent = omap2_init_dpll_parent,
+};
+
+static const struct clk_ops dpll_core_ck_ops = {
+ .recalc_rate= omap3_dpll_recalc,
+ .get_parent = omap2_init_dpll_parent,
+};
+
+static const struct clk_ops omap3_dpll_core_ck_ops = {
+ .init = omap2_init_clk_clkdm,
+ .get_parent = omap2_init_dpll_parent,
+ .recalc_rate= omap3_dpll_recalc,
+ .round_rate = omap2_dpll_round_rate,
+};
+
+static const struct clk_ops dpll_ck_ops = {
+
Re: Odd behavior with dpll4_m4x2_ck on omap3 + DT
On Tue, Sep 10, 2013 at 2:17 PM, Mike Turquette mturque...@linaro.org wrote: Quoting Tero Kristo (2013-09-10 06:17:45) On 09/10/2013 03:40 PM, Tomi Valkeinen wrote: On 10/09/13 15:24, Tero Kristo wrote: On 09/10/2013 03:19 PM, Tomi Valkeinen wrote: On 10/09/13 15:12, Tero Kristo wrote: If it claims it is not locked, it means the DPLL itself is disabled. You could try clk_enable for the clock before doing clk_set_rate. Hmm, so is it required to enable the clock before setting the rate? If so, I think I'm using the clocks wrong in all the places =). In generic case, it is not. But DPLLs behave strangely if they go to low power stop mode. If there is any downstream clock enabled for a specific DPLL it is enabled and things work okay. One could also argue that the API behavior in OMAP is wrong currently, as the bypass rate is something you are most likely never actually going to use for anything Just try the change and check the results. Ok, so as Stefan said, enabling the clock fixes the issue. How do you suggest we fix this? Changing omapdss to enable the clock before changing its rate is not very difficult, so it can be used as a quick fix. But it doesn't sound like a proper fix if this is not normally required. The quick fix sounds good to me. And, maybe I'm missing something as I don't have good understanding of the PRCM's PLLs, but the current behavior sounds odd. So the DPLL is off, and in bypass mode. When we try to change the rate of the clock provided by the PLL, shouldn't it fail, as bypass mode's rate cannot be changed? Or better, change the non-bypass rate. In theory, DPLLs can also be used in their bypass mode to feed customer nodes clocks. I just think the check in the clkoutx2_recalc is wrong, and should be enhanced to actually check what is the target mode for the clock once it is enabled. Maybe something like this would work properly: diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c index 3a0296c..ba218fb 100644 --- a/arch/arm/mach-omap2/dpll3xxx.c +++ b/arch/arm/mach-omap2/dpll3xxx.c @@ -658,14 +658,12 @@ unsigned long omap3_clkoutx2_recalc(struct clk_hw *hw, dd = pclk-dpll_data; - WARN_ON(!dd-enable_mask); - - v = __raw_readl(dd-control_reg) dd-enable_mask; - v = __ffs(dd-enable_mask); - if ((v != OMAP3XXX_EN_DPLL_LOCKED) || (dd-flags DPLL_J_TYPE)) + if ((dd-flags DPLL_J_TYPE) || + __clk_get_rate(dd-clk_bypass) == __clk_get_rate(pclk)) Two quick asides here: 1) might be nice if the J_TYPE pll was it's own clock type 2) would be nice if the check for bypass used something like: if (clk_get_parent(hw-clk) == dd-bypass_clk) rate = parent_rate; Which implies that the DPLLs become proper mux clocks. Please disregard the above! I'm reviewing the OMAP v6 CCF series and does these things already. Very cool. Regards, Mike Regards, Mike rate = parent_rate; else rate = parent_rate * 2; + return rate; } How is the DPLL4's clock rate 43200 anyway in bypass mode. Isn't bypass mode usually plain sys-clock, or such? This again reflects the rate that the clock has once it is enabled, the clkoutx2 does not. Getting comment from someone like Paul would probably help here. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 02/31] CLK: TI: Add DPLL clock support
Quoting Tero Kristo (2013-08-19 10:06:39) On 08/19/2013 07:24 PM, Mark Rutland wrote: On Mon, Aug 19, 2013 at 04:09:37PM +0100, Tero Kristo wrote: On 08/19/2013 05:18 PM, Mark Rutland wrote: On Mon, Aug 19, 2013 at 02:34:45PM +0100, Tero Kristo wrote: On 08/13/2013 01:50 PM, Mark Rutland wrote: Hi, On Fri, Aug 02, 2013 at 05:25:21PM +0100, Tero Kristo wrote: The OMAP clock driver now supports DPLL clock type. This patch also adds support for DT DPLL nodes. Signed-off-by: Tero Kristo t-kri...@ti.com --- .../devicetree/bindings/clock/ti/dpll.txt | 70 +++ arch/arm/mach-omap2/clock.h| 144 +- arch/arm/mach-omap2/clock3xxx.h|2 - drivers/clk/Makefile |1 + drivers/clk/ti/Makefile|3 + drivers/clk/ti/dpll.c | 488 include/linux/clk/ti.h | 164 +++ 7 files changed, 727 insertions(+), 145 deletions(-) create mode 100644 Documentation/devicetree/bindings/clock/ti/dpll.txt create mode 100644 drivers/clk/ti/Makefile create mode 100644 drivers/clk/ti/dpll.c create mode 100644 include/linux/clk/ti.h diff --git a/Documentation/devicetree/bindings/clock/ti/dpll.txt b/Documentation/devicetree/bindings/clock/ti/dpll.txt new file mode 100644 index 000..dcd6e63 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti/dpll.txt @@ -0,0 +1,70 @@ +Binding for Texas Instruments DPLL clock. + +This binding uses the common clock binding[1]. It assumes a +register-mapped DPLL with usually two selectable input clocks +(reference clock and bypass clock), with digital phase locked +loop logic for multiplying the input clock to a desired output +clock. This clock also typically supports different operation +modes (locked, low power stop etc.) This binding has several +sub-types, which effectively result in slightly different setup +for the actual DPLL clock. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt + +Required properties: +- compatible : shall be one of: + ti,omap4-dpll-x2-clock, + ti,omap3-dpll-clock, + ti,omap3-dpll-core-clock, + ti,omap3-dpll-per-clock, + ti,omap3-dpll-per-j-type-clock, + ti,omap4-dpll-clock, + ti,omap4-dpll-core-clock, + ti,omap4-dpll-m4xen-clock, + ti,omap4-dpll-j-type-clock, + ti,omap4-dpll-no-gate-clock, + ti,omap4-dpll-no-gate-j-type-clock, + +- #clock-cells : from common clock binding; shall be set to 0. +- clocks : link phandles of parent clocks (clk-ref and clk-bypass) It might be a good idea to use clock-names to clarify which clocks are present (I notice your examples contain only one clock input). All DPLLs have both bypass and reference clocks, but these can be the same. Is it better to just list both always (and hence drop clock-names), or provide clock-names always? If they're separate inputs, it's worth listing both (even if they're fed by the same provider). If it's possible one input might not be wired up, use clock-names. Ref and bypass clocks are used currently by all DPLLs (also the APLL) so I guess I just enforce both to be specified. Ok. It's always possible to add clock-names later if a platform doesn't wire an input. We lose the possibility of future compatibility, but backwards compatibility is easy enough to maintain. +- ti,clkdm-name : clockdomain name for the DPLL Could you elaborate on what this is for? What constitutes a valid name? I'm not sure a string is the best way to define the linkage of several elements to a domain... Well, I am not sure if we can do this any better at this point, we don't have DT nodes for clockdomain at the moment (I am not sure if we will have those either as there are only a handful of those per SoC) but I'll add some more documentation for this. I'll have to see the documentation, but I'd be very wary of putting that in as-is. Does having the clock domain string link this up to domains in platform data? I'm not sure how well we'll be able to maintain support for that in future if it requires other platform code to use now, and we're not sure how the domains themselves will be represented in dt. Hmm so, should I add a stub representation for the clockdomains to the DT then for now or how should this be handled? The stubs could then be mapped to the actual clock domains based on their node names. I'm not sure that this binding should know about the clock domain at all. Maybe the clock domain binding should list the clocks that are within the domain? I unfortunately don't have a good answer here, because
Re: [PATCH] ARM: OMAP4: clock: Lock PLLs in the right sequence
Quoting Rajendra Nayak (2013-08-08 03:14:11) On OMAP4 we have clk_set_rate()s being done for a few DPLL clock nodes, as part of the clock init code, since the bootloaders no longer locks these DPLLs. ... Signed-off-by: Rajendra Nayak rna...@ti.com Taken into clk-next. Thanks for the fix. Besides the annoying prints is there a functional regression fixed by this? If so I can take into clk-fixes as needed. I haven't spent much time thinking about this, but I wonder if representing the DPLLs as proper mux clocks with multiple parents coming in would have helped here? Right now the DPLL implementation sort of manages the mux bits behind the clock framework's back, right? Regards, Mike --- arch/arm/mach-omap2/cclock44xx_data.c | 20 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/arch/arm/mach-omap2/cclock44xx_data.c b/arch/arm/mach-omap2/cclock44xx_data.c index 88e37a4..1d5b529 100644 --- a/arch/arm/mach-omap2/cclock44xx_data.c +++ b/arch/arm/mach-omap2/cclock44xx_data.c @@ -1707,6 +1707,18 @@ int __init omap4xxx_clk_init(void) omap2_clk_disable_autoidle_all(); /* +* A set rate of ABE DPLL inturn triggers a set rate of USB DPLL +* when its in bypass. So always lock USB before ABE DPLL. +*/ + /* +* Lock USB DPLL on OMAP4 devices so that the L3INIT power +* domain can transition to retention state when not in use. +*/ + rc = clk_set_rate(dpll_usb_ck, OMAP4_DPLL_USB_DEFFREQ); + if (rc) + pr_err(%s: failed to configure USB DPLL!\n, __func__); + + /* * On OMAP4460 the ABE DPLL fails to turn on if in idle low-power * state when turning the ABE clock domain. Workaround this by * locking the ABE DPLL on boot. @@ -1718,13 +1730,5 @@ int __init omap4xxx_clk_init(void) if (rc) pr_err(%s: failed to configure ABE DPLL!\n, __func__); - /* -* Lock USB DPLL on OMAP4 devices so that the L3INIT power -* domain can transition to retention state when not in use. -*/ - rc = clk_set_rate(dpll_usb_ck, OMAP4_DPLL_USB_DEFFREQ); - if (rc) - pr_err(%s: failed to configure USB DPLL!\n, __func__); - return 0; } -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 6/8] wlcore: sdio: add wilink clock providers
Quoting Luciano Coelho (2013-07-30 06:04:34)
+static const struct of_device_id wlcore_sdio_of_clk_match_table[] = {
+ { .compatible = ti,wilink-clock },
+};
+
static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device
*dev)
{
struct wl12xx_platform_data *pdata;
struct device_node *np = dev-of_node;
+ struct device_node *clock_node;
if (!np) {
np = of_find_matching_node(NULL, dev-driver-of_match_table);
@@ -241,6 +247,9 @@ static struct wl12xx_platform_data
*wlcore_get_pdata_from_of(struct device *dev)
goto out_free;
}
+ for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
+ of_fixed_clk_setup(clock_node);
Hi Luciano,
Any reason for establishing your own compatible string if you just plan
to use the fixed rate clock? You could just use fixed-clock compatible
in your DTS.
I will be posting patches this week which makes the fixed-rate clock a
proper driver and matches that compatible string to instantiate those
clocks. That means that your driver could probably remove the clock
setup code completely.
Regards,
Mike
+
goto out;
out_free:
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Division by zero caused by CCF
On Tue, Jul 16, 2013 at 6:10 AM, Eduardo Valentin
eduardo.valen...@ti.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
Adding Mike's correct address.
On 16-07-2013 08:37, Felipe Balbi wrote:
Hi,
trying to get USB host verified on OMAP5 uEVM with v3.11-rc1. The
clk_set_rate() call ends up in a division by zero, which is quite
interesting provided the driver will only call clk_set_rate() if the
clock is valid and clk_rate is != 0.
[ 22.009238] Division by zero in kernel.
[ 22.009250] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW
3.11.0-rc1-00081-g3310d44-dirty #118
[ 22.009275] [c001c83c] (unwind_backtrace+0x0/0xf0) from [c0018a1c]
(show_stack+0x10/0x14)
[ 22.009289] [c0018a1c] (show_stack+0x10/0x14) from [c057403c]
(dump_stack+0x70/0x8c)
[ 22.009304] [c057403c] (dump_stack+0x70/0x8c) from [c02e4154]
(Ldiv0+0x8/0x10)
[ 22.009319] [c02e4154] (Ldiv0+0x8/0x10) from [c048d460]
(clk_divider_set_rate+0x10/0xdc)
[ 22.009331] [c048d460] (clk_divider_set_rate+0x10/0xdc) from
[c048c124] (clk_change_rate+0x38/0xb0)
[ 22.009341] [c048c124] (clk_change_rate+0x38/0xb0) from [c048c20c]
(clk_set_rate+0x70/0xa8)
[ 22.009354] [c048c20c] (clk_set_rate+0x70/0xa8) from [c042b244]
(nop_usb_xceiv_probe+0x1fc/0x2f8)
[ 22.009369] [c042b244] (nop_usb_xceiv_probe+0x1fc/0x2f8) from
[c036b47c] (platform_drv_probe+0x18/0x1c)
[ 22.009380] [c036b47c] (platform_drv_probe+0x18/0x1c) from [c0369f44]
(really_probe+0x70/0x1f4)
[ 22.009390] [c0369f44] (really_probe+0x70/0x1f4) from [c036a1dc]
(driver_probe_device+0x30/0x48)
[ 22.009401] [c036a1dc] (driver_probe_device+0x30/0x48) from
[c036a288] (__driver_attach+0x94/0x98)
[ 22.009411] [c036a288] (__driver_attach+0x94/0x98) from [c0368748]
(bus_for_each_dev+0x54/0x88)
[ 22.009420] [c0368748] (bus_for_each_dev+0x54/0x88) from [c036972c]
(bus_add_driver+0xdc/0x29c)
[ 22.009430] [c036972c] (bus_add_driver+0xdc/0x29c) from [c036a760]
(driver_register+0x78/0x190)
[ 22.009440] [c036a760] (driver_register+0x78/0x190) from [c00087b0]
(do_one_initcall+0x34/0x164)
[ 22.009453] [c00087b0] (do_one_initcall+0x34/0x164) from [c07b18f4]
(do_basic_setup+0x90/0xc4)
[ 22.009466] [c07b18f4] (do_basic_setup+0x90/0xc4) from [c07b199c]
(kernel_init_freeable+0x74/0x110)
[ 22.009478] [c07b199c] (kernel_init_freeable+0x74/0x110) from
[c05676c4] (kernel_init+0x8/0xe4)
[ 22.009491] [c05676c4] (kernel_init+0x8/0xe4) from [c0014648]
(ret_from_fork+0x14/0x2c)
I believe the problem is the actual division reaching
clk_divider_set_rate().
drivers/clk/clk-divider.c::clk_divider_set_rate()
| static int clk_divider_set_rate(struct clk_hw *hw, unsigned long rate,
| unsigned long parent_rate)
| {
| struct clk_divider *divider = to_clk_divider(hw);
| unsigned int div, value;
| unsigned long flags = 0;
| u32 val;
|
| div = parent_rate / rate;
right here, but how come rate would zero provided driver checks for it
as below.
drivers/usb/phy/phy-nop.c::nop_usb_xceiv_probe()
| if (!IS_ERR(nop-clk) clk_rate) {
| err = clk_set_rate(nop-clk, clk_rate);
| if (err) {
| dev_err(pdev-dev, Error setting clock rate\n);
| return err;
| }
| }
I've added a few prints around CCF to try and track what's going on:
[ 21.592690] nop_usb_xceiv_probe rate 1920
[ 21.592700] clk_set_rate rate 1920
[ 21.592707] clk_calc_new_rates rate 1920
[ 21.592713] clk_divider_round_rate rate 1920
[ 21.592719] clk_divider_bestdiv rate 1920
[ 21.592726] clk_change_rate best_parent_rate 0
or because we reach:
if (clk-ops-set_rate)
clk-ops-set_rate(clk-hw, clk-new_rate, best_parent_rate);
with clk-new_rate == 0.
Hmm, I'll look into this. We used to have a check which would at least
WARN on division by zero, but looks like that was replaced by some
other code at some point.
Also does your clock have the CLK_SET_RATE_PARENT flag set? If so then
you could be propagating a rate request of zero up to the next parent,
which would be a neat trick... however based on the dump that doesn't
seem to be what is happening.
Regards,
Mike
[ 21.592732] clk_divider_set_rate rate 0
[ 21.592737] Division by zero in kernel.
[ 21.592747] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GW
3.11.0-rc1-00081-g3310d44-dirty #121
[ 21.592773] [c001c83c] (unwind_backtrace+0x0/0xf0) from [c0018a1c]
(show_stack+0x10/0x14)
[ 21.592787] [c0018a1c] (show_stack+0x10/0x14) from [c057400c]
(dump_stack+0x70/0x8c)
[ 21.592803] [c057400c] (dump_stack+0x70/0x8c) from [c02e4154]
(Ldiv0+0x8/0x10)
[ 21.592819] [c02e4154] (Ldiv0+0x8/0x10) from [c048d3e0]
(clk_divider_set_rate+0x2c/0x100)
[ 21.592831] [c048d3e0]
Re: [PATCH 2/4] ARM: OMAP5: clockdomain data: add init file for omap54xx
Quoting Tero Kristo (2013-06-27 01:38:17)
cclock54xx_data.c now contains only init function and the clkdev mapping
that is still needed by some drivers. Eventually most of this file can
be removed, once a common location for the clk init can be found, and
the clkdev mapping is no longer needed.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/cclock54xx_data.c | 80
+
1 file changed, 80 insertions(+)
create mode 100644 arch/arm/mach-omap2/cclock54xx_data.c
diff --git a/arch/arm/mach-omap2/cclock54xx_data.c
b/arch/arm/mach-omap2/cclock54xx_data.c
new file mode 100644
Why not drivers/clk/omap/clk-omap54xx.c?
Regards,
Mike
index 000..f23f44e
--- /dev/null
+++ b/arch/arm/mach-omap2/cclock54xx_data.c
@@ -0,0 +1,74 @@
+/*
+ * OMAP54xx Clock data
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Paul Walmsley (p...@pwsan.com)
+ * Rajendra Nayak (rna...@ti.com)
+ * Benoit Cousson (b-cous...@ti.com)
+ * Mike Turquette (mturque...@linaro.org)
+ * Tero Kristo (t-kri...@ti.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/list.h
+#include linux/clkdev.h
+#include linux/io.h
+#include linux/clk-provider.h
+#include linux/clk/omap.h
+
+#include soc.h
+#include clock.h
+
+#define OMAP5_DPLL_ABE_DEFFREQ 98304000
+
+/*
+ * clkdev
+ */
+static struct omap_dt_clk omap54xx_clks[] = {
+ DT_CLK(NULL,timer_32k_ck, sys_32k_ck),
+ DT_CLK(omap_timer.1, sys_ck, sys_clkin),
+ DT_CLK(omap_timer.2, sys_ck, sys_clkin),
+ DT_CLK(omap_timer.3, sys_ck, sys_clkin),
+ DT_CLK(omap_timer.4, sys_ck, sys_clkin),
+ DT_CLK(omap_timer.9, sys_ck, sys_clkin),
+ DT_CLK(omap_timer.10, sys_ck, sys_clkin),
+ DT_CLK(omap_timer.11, sys_ck, sys_clkin),
+ DT_CLK(omap_timer.5, sys_ck, dss_syc_gfclk_div),
+ DT_CLK(omap_timer.6, sys_ck, dss_syc_gfclk_div),
+ DT_CLK(omap_timer.7, sys_ck, dss_syc_gfclk_div),
+ DT_CLK(omap_timer.8, sys_ck, dss_syc_gfclk_div),
+};
+
+int __init omap5xxx_clk_init(void)
+{
+ struct clk *abe_dpll_ref, *sys_32k_ck, *abe_dpll;
+ int rc;
+
+ /*
+* Must stay commented until all OMAP SoC drivers are
+* converted to runtime PM, or drivers may start crashing
+*
+* omap2_clk_disable_clkdm_control();
+*/
+ dt_omap_clk_init();
+
+ omap_dt_clocks_register(omap54xx_clks, ARRAY_SIZE(omap54xx_clks));
+
+ omap2_clk_disable_autoidle_all();
+
+ abe_dpll_ref = clk_get_sys(NULL, abe_dpll_clk_mux);
+ sys_32k_ck = clk_get_sys(NULL, sys_32k_ck);
+ rc = clk_set_parent(abe_dpll_ref, sys_32k_ck);
+ abe_dpll = clk_get_sys(NULL, dpll_abe_ck);
+ if (!rc)
+ rc = clk_set_rate(abe_dpll, OMAP5_DPLL_ABE_DEFFREQ);
+ if (rc)
+ pr_err(%s: failed to configure ABE DPLL!\n, __func__);
+
+ return 0;
+}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] ARM: DRA7: clockdomain data: add init file for dra7
Quoting Tero Kristo (2013-06-27 01:38:19)
cclock7xx_data.c now contains only init function and the clkdev mapping
that is still needed by some drivers. Eventually most of this file can
be removed, once a common location for the clk init can be found, and
the clkdev mapping is no longer needed.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
arch/arm/mach-omap2/cclock7xx_data.c | 93
++
1 file changed, 93 insertions(+)
create mode 100644 arch/arm/mach-omap2/cclock7xx_data.c
Why not drivers/clk/omap/clk-dra7xx.c?
Regards,
Mike
diff --git a/arch/arm/mach-omap2/cclock7xx_data.c
b/arch/arm/mach-omap2/cclock7xx_data.c
new file mode 100644
index 000..dba528a
--- /dev/null
+++ b/arch/arm/mach-omap2/cclock7xx_data.c
@@ -0,0 +1,83 @@
+/*
+ * DRA7xx Clock data
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Paul Walmsley (p...@pwsan.com)
+ * Rajendra Nayak (rna...@ti.com)
+ * Benoit Cousson (b-cous...@ti.com)
+ * Mike Turquette (mturque...@linaro.org)
+ * Tero Kristo (t-kri...@ti.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/list.h
+#include linux/clk-provider.h
+#include linux/clkdev.h
+#include linux/io.h
+#include linux/clk/omap.h
+
+#include soc.h
+#include clock.h
+
+#define DRA7_DPLL_ABE_DEFFREQ 361267200
+#define DRA7_DPLL_GMAC_DEFFREQ 10
+
+/*
+ * clkdev
+ */
+
+static struct omap_dt_clk dra7xx_clks[] = {
+ DT_CLK(NULL,timer_32k_ck, sys_32k_ck),
+ DT_CLK(4ae18000.timer,timer_sys_ck, sys_clkin2),
+ DT_CLK(48032000.timer,timer_sys_ck, sys_clkin2),
+ DT_CLK(48034000.timer,timer_sys_ck, sys_clkin2),
+ DT_CLK(48036000.timer,timer_sys_ck, sys_clkin2),
+ DT_CLK(4803e000.timer,timer_sys_ck, sys_clkin2),
+ DT_CLK(48086000.timer,timer_sys_ck, sys_clkin2),
+ DT_CLK(48088000.timer,timer_sys_ck, sys_clkin2),
+ DT_CLK(4882.timer,timer_sys_ck,
timer_sys_clk_div),
+ DT_CLK(48822000.timer,timer_sys_ck,
timer_sys_clk_div),
+ DT_CLK(48824000.timer,timer_sys_ck,
timer_sys_clk_div),
+ DT_CLK(48826000.timer,timer_sys_ck,
timer_sys_clk_div),
+ DT_CLK(NULL, sys_clkin,sys_clkin1),
+};
+
+int __init dra7xx_clk_init(void)
+{
+ struct clk *abe_dpll_mux, *sys_clkin2, *dpll_ck;
+ int rc;
+ /*
+* Must stay commented until all OMAP SoC drivers are
+* converted to runtime PM, or drivers may start crashing
+*
+* omap2_clk_disable_clkdm_control();
+*/
+
+ dt_omap_clk_init();
+
+ omap_dt_clocks_register(dra7xx_clks, ARRAY_SIZE(dra7xx_clks));
+
+ omap2_clk_disable_autoidle_all();
+
+ abe_dpll_mux = clk_get_sys(NULL, abe_dpll_sys_clk_mux);
+ sys_clkin2 = clk_get_sys(NULL, sys_clkin2);
+ dpll_ck = clk_get_sys(NULL, dpll_abe_ck);
+
+ rc = clk_set_parent(abe_dpll_mux, sys_clkin2);
+ if (!rc)
+ rc = clk_set_rate(dpll_ck, DRA7_DPLL_ABE_DEFFREQ);
+ if (rc)
+ pr_err(%s: failed to configure ABE DPLL!\n, __func__);
+
+ dpll_ck = clk_get_sys(NULL, dpll_gmac_ck);
+ rc = clk_set_rate(dpll_ck, DRA7_DPLL_GMAC_DEFFREQ);
+ if (rc)
+ pr_err(%s: failed to configure GMAC DPLL!\n, __func__);
+
+ return 0;
+}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 02/11] CLK: use of_property_read_u32 instead of read_u8
On Wed, Jun 19, 2013 at 6:18 AM, Tero Kristo t-kri...@ti.com wrote:
of_property_read_u8 does not work properly because of endianess problem
with its current implementation, and this causes it to always return
0 with little endian architectures. Instead, use property_read_u32
until this is fixed.
Tero,
Thanks for the fix. Heiko Stubner pointed out to me that in order to
read a u8 value the DT node needs to specify /bits/ 8 before the
values. From the of_property_read_u8_array kerneldoc:
/**
...
* dts entry of array should be like:
* property = /bits/ 8 0x50 0x60 0x70;
*
* The out_value is modified only if a valid u8 value can be decoded.
*/
Still I think it is a bit silly to have to do this in all of the
bindings, so I'm going to roll this patch into my next version of the
series if only for the sake of readability. Not only that but it is
slightly more future proof for the binding to use a u32 value. The
fact that the implementation in Linux uses a u8 is of little
consequence to the binding. I'll also add a cast like the following
to your patch:
clk = clk_register_gate(NULL, clk_name, parent_name, 0, reg, (u8) bit_idx,
clk_gate_flags, NULL);
Thanks,
Mike
Signed-off-by: Tero Kristo t-kri...@ti.com
---
drivers/clk/clk-divider.c |4 ++--
drivers/clk/clk-gate.c|4 ++--
drivers/clk/clk-mux.c |4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 17ea475..3413602 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -361,7 +361,7 @@ void of_divider_clk_setup(struct device_node *node)
const char *parent_name;
u8 clk_divider_flags = 0;
u32 mask = 0;
- u8 shift = 0;
+ u32 shift = 0;
struct clk_div_table *table;
of_property_read_string(node, clock-output-names, clk_name);
@@ -375,7 +375,7 @@ void of_divider_clk_setup(struct device_node *node)
return;
}
- if (of_property_read_u8(node, bit-shift, shift)) {
+ if (of_property_read_u32(node, bit-shift, shift)) {
shift = __ffs(mask);
pr_debug(%s: bit-shift property defaults to 0x%x for %s\n,
__func__, shift, node-name);
diff --git a/drivers/clk/clk-gate.c b/drivers/clk/clk-gate.c
index 72cf99d..61b4dc1 100644
--- a/drivers/clk/clk-gate.c
+++ b/drivers/clk/clk-gate.c
@@ -162,7 +162,7 @@ void of_gate_clk_setup(struct device_node *node)
void __iomem *reg;
const char *parent_name;
u8 clk_gate_flags = 0;
- u8 bit_idx = 0;
+ u32 bit_idx = 0;
of_property_read_string(node, clock-output-names, clk_name);
@@ -170,7 +170,7 @@ void of_gate_clk_setup(struct device_node *node)
reg = of_iomap(node, 0);
- if (of_property_read_u8(node, bit-shift, bit_idx)) {
+ if (of_property_read_u32(node, bit-shift, bit_idx)) {
pr_err(%s: missing bit-shift property for %s\n,
__func__, node-name);
return;
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index c9f9f32..e63dd1b 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -170,7 +170,7 @@ void of_mux_clk_setup(struct device_node *node)
int i;
u8 clk_mux_flags = 0;
u32 mask = 0;
- u8 shift = 0;
+ u32 shift = 0;
of_property_read_string(node, clock-output-names, clk_name);
@@ -194,7 +194,7 @@ void of_mux_clk_setup(struct device_node *node)
return;
}
- if (of_property_read_u8(node, bit-shift, shift)) {
+ if (of_property_read_u32(node, bit-shift, shift)) {
shift = __ffs(mask);
pr_debug(%s: bit-shift property defaults to 0x%x for %s\n,
__func__, shift, node-name);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch 1/3] clk: fix clk_mux_get_parent return's signed value
On Mon, Jun 3, 2013 at 11:27 PM, Ambresh K ambr...@ti.com wrote:
clksel is an omap-centric term. How about:
clk_mux_get_parent should return an error if the value read from the
register is erroneous.
Make sense, will fix it.
The general approach looks good to me. Can you submit a V2 which
removes all of the clksel-isms and updates definitions for .get_parent
functions to avoid the warnings you mentioned in the cover letter? You
might find cocinelle useful for that last task.
Thanks!
Will fix them and add your ack to it?
Great, thanks! Don't worry about the Ack. I'll take the patch
through the clk tree so it will have my SoB.
Regards,
Mike
Regards,
Mike
Currently if the value read is greater than the number of
available parents clk_mux_get_parent return's signed error
which will result in NULL pointer dereferencing in the
calling functions.
Signed-off-by: Ambresh K ambr...@ti.com
---
drivers/clk/clk-mux.c|2 +-
drivers/clk/clk.c| 12 +++-
include/linux/clk-provider.h |4 ++--
3 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 25b1734..be0857e 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -29,7 +29,7 @@
#define to_clk_mux(_hw) container_of(_hw, struct clk_mux, hw)
-static u8 clk_mux_get_parent(struct clk_hw *hw)
+static int clk_mux_get_parent(struct clk_hw *hw)
{
struct clk_mux *mux = to_clk_mux(hw);
int num_parents = __clk_get_num_parents(hw-clk);
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 934cfd1..c187321 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1281,7 +1281,7 @@ EXPORT_SYMBOL_GPL(clk_get_parent);
static struct clk *__clk_init_parent(struct clk *clk)
{
struct clk *ret = NULL;
- u8 index;
+ int index;
/* handle the trivial cases */
@@ -1309,6 +1309,11 @@ static struct clk *__clk_init_parent(struct clk *clk)
*/
index = clk-ops-get_parent(clk-hw);
+ if (index 0) {
+ pr_err(%s: clk(%s) invalid parent clk_sel index(%d)\n,
+ __func__, clk-name, index);
+ goto out;
+ }
if (!clk-parents)
clk-parents =
@@ -1632,6 +1637,11 @@ int __clk_init(struct device *dev, struct clk *clk)
hlist_for_each_entry_safe(orphan, tmp2, clk_orphan_list,
child_node) {
if (orphan-ops-get_parent) {
i = orphan-ops-get_parent(orphan-hw);
+ if (i 0) {
+ pr_err(%s: orphan clk(%s) invalid
parent\n,
+ __func__, orphan-name);
+ continue;
+ }
if (!strcmp(clk-name, orphan-parent_names[i]))
__clk_reparent(orphan, clk);
continue;
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 1186098..96337a1 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -80,7 +80,7 @@ struct clk_hw;
* supported by the clock.
*
* @get_parent:Queries the hardware to determine the parent of a
clock. The
- * return value is a u8 which specifies the index
corresponding to
+ * return value which specifies the index corresponding to
* the parent clock. This index can be applied to either the
* .parent_names or .parents arrays. In short, this function
* translates the parent value read from hardware into an array
@@ -127,7 +127,7 @@ struct clk_ops {
long(*round_rate)(struct clk_hw *hw, unsigned long,
unsigned long *);
int (*set_parent)(struct clk_hw *hw, u8 index);
- u8 (*get_parent)(struct clk_hw *hw);
+ int (*get_parent)(struct clk_hw *hw);
int (*set_rate)(struct clk_hw *hw, unsigned long,
unsigned long);
void(*init)(struct clk_hw *hw);
--
1.7.4.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC 3/3] ARM: omap4: register DT clocks remove old data
Now that some of the OMAP4 PRCM clock data has been converted to a
DeviceTree representation it is no longer needed as static clock data.
Register the DT clocks first, followed by the remaining static clocks.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Joel A Fernandes joelag...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Mike Turquette mturque...@linaro.org
---
arch/arm/mach-omap2/cclock44xx_data.c | 54 ---
1 file changed, 6 insertions(+), 48 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index 88e37a4..97fd65c 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -27,6 +27,7 @@
#include linux/clk-private.h
#include linux/clkdev.h
#include linux/io.h
+#include linux/clk/omap.h
#include soc.h
#include iomap.h
@@ -61,18 +62,12 @@
/* Root clocks */
-DEFINE_CLK_FIXED_RATE(extalt_clkin_ck, CLK_IS_ROOT, 5900, 0x0);
-
DEFINE_CLK_FIXED_RATE(pad_clks_src_ck, CLK_IS_ROOT, 1200, 0x0);
DEFINE_CLK_GATE(pad_clks_ck, pad_clks_src_ck, pad_clks_src_ck, 0x0,
OMAP4430_CM_CLKSEL_ABE, OMAP4430_PAD_CLKS_GATE_SHIFT,
0x0, NULL);
-DEFINE_CLK_FIXED_RATE(pad_slimbus_core_clks_ck, CLK_IS_ROOT, 1200, 0x0);
-
-DEFINE_CLK_FIXED_RATE(secure_32k_clk_src_ck, CLK_IS_ROOT, 32768, 0x0);
-
DEFINE_CLK_FIXED_RATE(slimbus_src_clk, CLK_IS_ROOT, 1200, 0x0);
DEFINE_CLK_GATE(slimbus_clk, slimbus_src_clk, slimbus_src_clk, 0x0,
@@ -81,20 +76,6 @@ DEFINE_CLK_GATE(slimbus_clk, slimbus_src_clk,
slimbus_src_clk, 0x0,
DEFINE_CLK_FIXED_RATE(sys_32k_ck, CLK_IS_ROOT, 32768, 0x0);
-DEFINE_CLK_FIXED_RATE(virt_1200_ck, CLK_IS_ROOT, 1200, 0x0);
-
-DEFINE_CLK_FIXED_RATE(virt_1300_ck, CLK_IS_ROOT, 1300, 0x0);
-
-DEFINE_CLK_FIXED_RATE(virt_1680_ck, CLK_IS_ROOT, 1680, 0x0);
-
-DEFINE_CLK_FIXED_RATE(virt_1920_ck, CLK_IS_ROOT, 1920, 0x0);
-
-DEFINE_CLK_FIXED_RATE(virt_2600_ck, CLK_IS_ROOT, 2600, 0x0);
-
-DEFINE_CLK_FIXED_RATE(virt_2700_ck, CLK_IS_ROOT, 2700, 0x0);
-
-DEFINE_CLK_FIXED_RATE(virt_3840_ck, CLK_IS_ROOT, 3840, 0x0);
-
static const char *sys_clkin_ck_parents[] = {
virt_1200_ck, virt_1300_ck, virt_1680_ck,
virt_1920_ck, virt_2600_ck, virt_2700_ck,
@@ -105,16 +86,6 @@ DEFINE_CLK_MUX(sys_clkin_ck, sys_clkin_ck_parents, NULL,
0x0,
OMAP4430_CM_SYS_CLKSEL, OMAP4430_SYS_CLKSEL_SHIFT,
OMAP4430_SYS_CLKSEL_WIDTH, CLK_MUX_INDEX_ONE, NULL);
-DEFINE_CLK_FIXED_RATE(tie_low_clock_ck, CLK_IS_ROOT, 0, 0x0);
-
-DEFINE_CLK_FIXED_RATE(utmi_phy_clkout_ck, CLK_IS_ROOT, 6000, 0x0);
-
-DEFINE_CLK_FIXED_RATE(xclk60mhsp1_ck, CLK_IS_ROOT, 6000, 0x0);
-
-DEFINE_CLK_FIXED_RATE(xclk60mhsp2_ck, CLK_IS_ROOT, 6000, 0x0);
-
-DEFINE_CLK_FIXED_RATE(xclk60motg_ck, CLK_IS_ROOT, 6000, 0x0);
-
/* Module clocks and DPLL outputs */
static const char *abe_dpll_bypass_clk_mux_ck_parents[] = {
@@ -826,7 +797,7 @@ DEFINE_CLK_GATE(dss_sys_clk, syc_clk_div_ck,
syc_clk_div_ck, 0x0,
OMAP4430_CM_DSS_DSS_CLKCTRL,
OMAP4430_OPTFCLKEN_SYS_CLK_SHIFT, 0x0, NULL);
-DEFINE_CLK_GATE(dss_tv_clk, extalt_clkin_ck, extalt_clkin_ck, 0x0,
+DEFINE_CLK_GATE(dss_tv_clk, extalt_clkin_ck, NULL, 0x0,
OMAP4430_CM_DSS_DSS_CLKCTRL,
OMAP4430_OPTFCLKEN_TV_CLK_SHIFT, 0x0, NULL);
@@ -1051,7 +1022,7 @@ DEFINE_CLK_GATE(slimbus2_fclk_0, func_24mc_fclk,
func_24mc_fclk, 0x0,
OMAP4430_OPTFCLKEN_PER24MC_GFCLK_SHIFT, 0x0, NULL);
DEFINE_CLK_GATE(slimbus2_slimbus_clk, pad_slimbus_core_clks_ck,
- pad_slimbus_core_clks_ck, 0x0,
+ NULL, 0x0,
OMAP4430_CM_L4PER_SLIMBUS2_CLKCTRL,
OMAP4430_OPTFCLKEN_SLIMBUS_CLK_SHIFT, 0x0, NULL);
@@ -1442,27 +1413,11 @@ static struct omap_clk omap443x_clks[] = {
* clocks common to omap44xx
*/
static struct omap_clk omap44xx_clks[] = {
- CLK(NULL, extalt_clkin_ck, extalt_clkin_ck),
CLK(NULL, pad_clks_src_ck, pad_clks_src_ck),
CLK(NULL, pad_clks_ck, pad_clks_ck),
- CLK(NULL, pad_slimbus_core_clks_ck,
pad_slimbus_core_clks_ck),
- CLK(NULL, secure_32k_clk_src_ck,secure_32k_clk_src_ck),
CLK(NULL, slimbus_src_clk, slimbus_src_clk),
CLK(NULL, slimbus_clk, slimbus_clk),
CLK(NULL, sys_32k_ck, sys_32k_ck),
- CLK(NULL, virt_1200_ck, virt_1200_ck),
- CLK(NULL, virt_1300_ck, virt_1300_ck),
- CLK(NULL, virt_1680_ck, virt_1680_ck),
- CLK(NULL, virt_1920_ck, virt_1920_ck),
- CLK(NULL
[PATCH RFC 2/3] ARM: dts: omap4 clock data
This is a first pass at creating a unique node for each clock in the
OMAP4 power, reset and clock manager (PRCM). So far I have only
converted mux clocks fixed-rate clocks, which coexist with the current
clock data in the kernel. The rest needs to be done but better to
publish early and often to see what others think of this approach.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Joel A Fernandes joelag...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Mike Turquette mturque...@linaro.org
---
arch/arm/boot/dts/omap4-clocks.dtsi | 128
arch/arm/boot/dts/omap4.dtsi| 2 +
2 files changed, 130 insertions(+)
create mode 100644 arch/arm/boot/dts/omap4-clocks.dtsi
diff --git a/arch/arm/boot/dts/omap4-clocks.dtsi
b/arch/arm/boot/dts/omap4-clocks.dtsi
new file mode 100644
index 000..664e100
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-clocks.dtsi
@@ -0,0 +1,128 @@
+/*
+ * Copyright (C) 2013 Linaro Incorporated - http://www.linaro.org/
+ *
+ * Mike Turquette mturque...@linaro.org
+ *
+ * Data is automatically generated from the OMAP hardware databases. If
+ * changes need to be made, do not edit this file directly. Instead contact
+ * the following developers who will update the code generator:
+ *
+ * Benoit Cousson benoit.cous...@linaro.org
+ * Rajendra Nayak rna...@ti.com
+ * Mike Turquette mturque...@linaro.org
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/* FIXME need to print the address directly */
+/*
+#include ../../mach-omap2/prm44xx.h
+#include ../../mach-omap2/cm2_44xx.h
+#include ../../mach-omap2/cm1_44xx.h
+*/
+
+
+/* Root clocks */
+
+extalt_clkin_ck: extalt_clkin_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 5900;
+};
+
+pad_slimbus_core_clks_ck: pad_slimbus_core_clks_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1200;
+};
+
+secure_32k_clk_src_ck: secure_32k_clk_src_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 32768;
+};
+
+virt_1200_ck: virt_1200_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1200;
+};
+
+virt_1300_ck: virt_1300_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1300;
+};
+
+virt_1680_ck: virt_1680_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1680;
+};
+
+virt_1920_ck: virt_1920_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1920;
+};
+
+virt_2600_ck: virt_2600_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 2600;
+};
+
+virt_2700_ck: virt_2700_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 2700;
+};
+
+virt_3840_ck: virt_3840_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 3840;
+};
+
+sys_clkin_dt: sys_clkin_dt@4a306110 {
+ #clock-cells = 0;
+ compatible = mux-clock;
+ clocks = virt_1200_ck, virt_1300_ck, virt_1680_ck,
virt_1920_ck, virt_2600_ck, virt_2700_ck,
virt_3840_ck;
+ reg = 0x4a306110 0x4;
+ mask = 0x7;
+ shift = 0;
+ index_one;
+};
+
+tie_low_clock_ck: tie_low_clock_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 0;
+};
+
+utmi_phy_clkout_ck: utmi_phy_clkout_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 6000;
+};
+
+xclk60mhsp1_ck: xclk60mhsp1_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 6000;
+};
+
+xclk60mhsp2_ck: xclk60mhsp2_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 6000;
+};
+
+xclk60motg_ck: xclk60motg_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 6000;
+};
+
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 2a56428..70608db 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -106,6 +106,8 @@
ti,hwmods = counter_32k;
};
+ /include/ omap4-clocks.dtsi
+
omap4_pmx_core: pinmux@4a100040 {
compatible = ti,omap4-padconf, pinctrl-single;
reg = 0x4a100040 0x0196;
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
[PATCH RFC 1/3] clk: omap: introduce clock driver
Parses OMAP clock data from DT and registers those clocks with the clock
framework. dt_omap_clk_init must be called early during boot for timer
initialization so it is exported and called from the existing clock code
instead of probing like a real driver.
Cc: Benoit Cousson b-cous...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Joel A Fernandes joelag...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tony Lindgren t...@atomide.com
Signed-off-by: Mike Turquette mturque...@linaro.org
---
This driver simply matches the basic bindings (so far). Eventually it
would match omap-specific bindings for DPLLs, CLKOUTX2 and strange leaf
clocks as well. This doesn't scale well since non-OMAP related clock
data (e.g. a pmic or discrete audio codec) will get grouped into this
driver if it matches on a basic clock type. Suggestions?
drivers/clk/Makefile | 1 +
drivers/clk/omap/Makefile | 1 +
drivers/clk/omap/clk.c| 55 +++
include/linux/clk/omap.h | 24 +
4 files changed, 81 insertions(+)
create mode 100644 drivers/clk/omap/Makefile
create mode 100644 drivers/clk/omap/clk.c
create mode 100644 include/linux/clk/omap.h
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index f51b52b..efd4f2a 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_ARCH_VT8500) += clk-vt8500.o
obj-$(CONFIG_ARCH_ZYNQ)+= clk-zynq.o
obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_PLAT_SAMSUNG) += samsung/
+obj-$(CONFIG_ARCH_OMAP)+= omap/
obj-$(CONFIG_X86) += x86/
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
new file mode 100644
index 000..8195931
--- /dev/null
+++ b/drivers/clk/omap/Makefile
@@ -0,0 +1 @@
+obj-y += clk.o
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
new file mode 100644
index 000..e9e5c95
--- /dev/null
+++ b/drivers/clk/omap/clk.c
@@ -0,0 +1,55 @@
+/*
+ * OMAP PRCM clock driver
+ *
+ * Copyright (C) 2013 Linaro.org - http://www.linaro.org
+ * Mike Turquette mturque...@linaro.org
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk-provider.h
+#include linux/clk/omap.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of_device.h
+#include linux/platform_device.h
+
+/* FIXME - should the OMAP PRCM clock driver match generic types? */
+static const struct of_device_id clk_match[] = {
+ {.compatible = fixed-clock, .data = of_fixed_clk_setup, },
+ {.compatible = mux-clock, .data = of_mux_clk_setup, },
+ {.compatible = fixed-factor-clock,
+ .data = of_fixed_factor_clk_setup, },
+ {},
+};
+
+static int omap_clk_probe(struct platform_device *pdev)
+{
+ of_clk_init(clk_match);
+ return 0;
+}
+
+static struct platform_driver omap_clk_driver = {
+ .probe = omap_clk_probe,
+ .driver = {
+ .name = omap_clk,
+ .of_match_table = of_match_ptr(clk_match),
+ },
+};
+
+/* FIXME - need to initialize early; skip real driver registration probe */
+int __init dt_omap_clk_init(void)
+{
+ return omap_clk_probe(NULL);
+}
+
+MODULE_DESCRIPTION(OMAP Clock driver);
+MODULE_AUTHOR(Texas Instruments Inc.);
+MODULE_LICENSE(GPL v2);
diff --git a/include/linux/clk/omap.h b/include/linux/clk/omap.h
new file mode 100644
index 000..504e838
--- /dev/null
+++ b/include/linux/clk/omap.h
@@ -0,0 +1,24 @@
+/*
+ * Copyright (C) 2010 Broadcom
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#ifndef __LINUX_CLK_OMAP_H_
+#define __LINUX_CLK_OMAP_H_
+
+int __init dt_omap_clk_init(void);
+
+#endif
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More
[PATCH RFC 0/3] first pass converting omap4 clock data to DT
This is a very incomplete conversion of a handful of OMAP4 PRCM clocks from the statically defined clock data in arch/arm/mach-omap2/cclock44xx_data.c to a new dts file in arch/arm/boot/dts/omap4-clocks.dtsi. I am not a DT expert so many of the choices here may be quite disgusting to look at, or may be on the right path. In particular I simply include the new omap4-clocks.dtsi from omap4.dtsi, which feels a bit kludgey. Also this series depends on the basic clock bindings RFC I posted earlier today[1]. I actually have an omap4-clock.dtsi file with many more clocks converted to the mux-clock, divider-clock, fixed-clock, fixed-factor and (unpublished) gate-clock bindings in my local repo, but it is not currently booting. I wanted to get this early preview out regardless. [1] http://article.gmane.org/gmane.linux.kernel/1501216 Mike Turquette (3): clk: omap: introduce clock driver ARM: dts: omap4 clock data ARM: omap4: register DT clocks remove old data arch/arm/boot/dts/omap4-clocks.dtsi | 128 ++ arch/arm/boot/dts/omap4.dtsi | 2 + arch/arm/mach-omap2/cclock44xx_data.c | 54 ++ drivers/clk/Makefile | 1 + drivers/clk/omap/Makefile | 1 + drivers/clk/omap/clk.c| 55 +++ include/linux/clk/omap.h | 24 +++ 7 files changed, 217 insertions(+), 48 deletions(-) create mode 100644 arch/arm/boot/dts/omap4-clocks.dtsi create mode 100644 drivers/clk/omap/Makefile create mode 100644 drivers/clk/omap/clk.c create mode 100644 include/linux/clk/omap.h -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/1] ARM : omap3 : fix wrong container_of in clock36xx.c
Quoting Jean-Philippe Francois (2013-05-30 01:50:27)
omap36xx_pwrdn_clk_enable_with_hsdiv_restore expects the parent hw of the
clock
to be a clk_hw_omap. However, looking at cclock3xxx_data.c, all concerned
clock
have parent defined as clk_divider. Instead of using container_of to
eventually get
to the register and directly mess with the divider, change freq via
clk_set_rate,
and let the clock framework toggle the divider value.
Tested with 3.9 on dm3730.
Signed-off-by: Jean-Philippe Fran��ois jp.franc...@cynove.com
Did you use git-format-patch to create this patch? Its a bit nicer to
use that or if you just use diff then use diff -up or diff -uprN
(taken from Documentation/SubmittingPatches.txt).
Also did you test this to make sure it works? I don't mean a boot test,
but actually disabling/re-enabling an HSDIVIDER on 3630? The previous
code just programmed the clksel field to 1, and this code divides the
rate by 2, then restores it. I just used that as an example in my
previous email and it needs to be verified that it works (though it
should if I remember this errata correctly).
If that testing is done and everything looks good then please add:
Acked-by: Mike Turquette mturque...@linaro.org
Index: b/arch/arm/mach-omap2/clock36xx.c
===
--- a/arch/arm/mach-omap2/clock36xx.c
+++ b/arch/arm/mach-omap2/clock36xx.c
@@ -39,30 +39,25 @@
*/
int omap36xx_pwrdn_clk_enable_with_hsdiv_restore(struct clk_hw *clk)
{
- struct clk_hw_omap *parent;
- struct clk_hw *parent_hw;
- u32 dummy_v, orig_v, clksel_shift;
int ret;
/* Clear PWRDN bit of HSDIVIDER */
ret = omap2_dflt_clk_enable(clk);
- parent_hw = __clk_get_hw(__clk_get_parent(clk-clk));
- parent = to_clk_hw_omap(parent_hw);
-
- /* Restore the dividers */
+ /* kick parent's clksel register after toggling PWRDN bit */
if (!ret) {
- clksel_shift = __ffs(parent-clksel_mask);
- orig_v = __raw_readl(parent-clksel_reg);
- dummy_v = orig_v;
-
- /* Write any other value different from the Read value */
- dummy_v ^= (1 clksel_shift);
- __raw_writel(dummy_v, parent-clksel_reg);
-
- /* Write the original divider */
- __raw_writel(orig_v, parent-clksel_reg);
+ struct clk *parent = clk_get_parent(clk-clk);
+ unsigned long parent_rate = clk_get_rate(parent);
+ ret = clk_set_rate(parent, parent_rate/2);
+ if(ret)
+ goto badfreq;
+ ret = clk_set_rate(parent, parent_rate);
+ if(ret)
+ goto badfreq;
}
+ return ret;
+ badfreq :
+ omap2_dflt_clk_disable(clk);
return ret;
}
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM : omap3 : fix wrong container_of in clock36xx.c
Quoting Jean-Philippe Francois (2013-05-17 08:51:26)
omap36xx_pwrdn_clk_enable_with_hsdiv_restore expects the parent hw of the
clock
to be a clk_hw_omap. However, looking at cclock3xxx_data.c, all concerned
clock
have parent defined as clk_divider.
Fix the function to use clk_divider.
Tested with 3.9 on dm3730.
Signed-off-by: Jean-Philippe Fran��ois jp.franc...@cynove.com
Index: b/arch/arm/mach-omap2/clock36xx.c
===
--- a/arch/arm/mach-omap2/clock36xx.c
+++ b/arch/arm/mach-omap2/clock36xx.c
@@ -20,11 +20,12 @@
#include linux/kernel.h
#include linux/clk.h
+#include linux/clk-provider.h
#include linux/io.h
#include clock.h
#include clock36xx.h
-
+#define to_clk_divider(_hw) container_of(_hw, struct clk_divider, hw)
/**
* omap36xx_pwrdn_clk_enable_with_hsdiv_restore - enable clocks suffering
@@ -39,29 +40,28 @@
*/
int omap36xx_pwrdn_clk_enable_with_hsdiv_restore(struct clk_hw *clk)
{
- struct clk_hw_omap *parent;
+ struct clk_divider *parent;
struct clk_hw *parent_hw;
- u32 dummy_v, orig_v, clksel_shift;
+ u32 dummy_v, orig_v;
int ret;
/* Clear PWRDN bit of HSDIVIDER */
ret = omap2_dflt_clk_enable(clk);
parent_hw = __clk_get_hw(__clk_get_parent(clk-clk));
- parent = to_clk_hw_omap(parent_hw);
+ parent = to_clk_divider(parent_hw);
Peaking inside of clock structures was OK back in the legacy clock days,
and even if the clocks are the same type (clk_hw_omap), but having omap
code dig into clk-divider structures is pretty gross.
How about reentrantly calling clk_set_rate here to achieve the same
effect?
/* kick parent's clksel register after toggling PWRDN bit */
struct clk *parent = clk_get_parent(clk-clk);
unsigned long parent_rate = clk_get_rate(parent);
clk_set_rate(parent, parent_rate/2);
clk_set_rate(parent, parent_rate);
Regards,
Mike
/* Restore the dividers */
if (!ret) {
- clksel_shift = __ffs(parent-clksel_mask);
- orig_v = __raw_readl(parent-clksel_reg);
+ orig_v = __raw_readl(parent-reg);
dummy_v = orig_v;
/* Write any other value different from the Read value */
- dummy_v ^= (1 clksel_shift);
- __raw_writel(dummy_v, parent-clksel_reg);
+ dummy_v ^= (1 parent-shift);
+ __raw_writel(dummy_v, parent-reg);
/* Write the original divider */
- __raw_writel(orig_v, parent-clksel_reg);
+ __raw_writel(orig_v, parent-reg);
}
return ret;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5 1/6] clk: OMAP: introduce device tree binding to kernel clock data
Quoting Nishanth Menon (2013-05-08 12:06:11)
snip
Overall strategy introduced here is simple: a clock node described in
device tree blob is used to identify the exact clock provided in the
SoC specific data. This is then linked back using of_clk_add_provider
to the device node to be accessible by of_clk_get.
FYI, I'm working on moving the OMAP clocks over to DT which is a better
alternative than this patch. I'll share what I have on the list,
hopefully next week.
Regards,
Mike
Based on discussion contributions from Roger Quadros, Grygorii Strashko
and others.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Mike Turquette mturque...@linaro.org
Cc: Paul Walmsley p...@pwsan.com
[t...@atomide.com: co-developed]
Signed-off-by: Tony Lindgren t...@atomide.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Changes in this version:
- review comments incorporated.
Previous version of this patch was discussed in:
http://marc.info/?t=13658075851r=1w=2
.../devicetree/bindings/clock/omap-clock.txt | 40 +
drivers/clk/Makefile |1 +
drivers/clk/omap/Makefile |1 +
drivers/clk/omap/clk.c | 91
4 files changed, 133 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/omap-clock.txt
create mode 100644 drivers/clk/omap/Makefile
create mode 100644 drivers/clk/omap/clk.c
diff --git a/Documentation/devicetree/bindings/clock/omap-clock.txt
b/Documentation/devicetree/bindings/clock/omap-clock.txt
new file mode 100644
index 000..047c1e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/omap-clock.txt
@@ -0,0 +1,40 @@
+Device Tree Clock bindings for Texas Instrument's OMAP compatible platforms
+
+This binding is an initial minimal binding that may be enhanced as part of
+transitioning OMAP clock data out of kernel image.
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be ti,omap-clock
+- #clock-cells : from common clock binding; shall be set to 0.
+NOTE:
+node name should map to clock database in
arch/arm/mach-omap2/cclockSoC_data.c
+Since all clocks are described with _ck, the node name is optimized to drop
the
+usage of _ck. For example, a clock called dpll1_ck will be defined as dpll1.
+
+Example #1: describing clock node for CPU on OMAP34xx platform:
+Ref: arch/arm/mach-omap2/cclock3xxx_data.c
+describes the CPU clock to be as follows
+ CLK(NULL, dpll1_ck, dpll1_ck, CK_3XXX),
+Corresponding binding will be:
+ dpll1: dpll1 {
+ #clock-cells = 0;
+ compatible = ti,omap-clock;
+ };
+And it's usage will be:
+ clocks = dpll1;
+
+Example #2: describing clock node for auxilary clock #3 on OMAP443x platform:
+Ref: arch/arm/mach-omap2/cclock44xx_data.c
+describes the auxclk3 clock to be as follows:
+ CLK(NULL, auxclk3_ck, auxclk3_ck,CK_443X),
+Corresponding binding will be:
+ auxclk3: auxclk3 {
+ #clock-cells = 0;
+ compatible = ti,omap-clock;
+ };
+And it's usage will be:
+ clocks = auxclk3;
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 137d3e7..1d5a2ec 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_ARCH_VT8500) += clk-vt8500.o
obj-$(CONFIG_ARCH_ZYNQ)+= clk-zynq.o
obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_PLAT_SAMSUNG) += samsung/
+obj-$(CONFIG_ARCH_OMAP)+= omap/
obj-$(CONFIG_X86) += x86/
diff --git a/drivers/clk/omap/Makefile b/drivers/clk/omap/Makefile
new file mode 100644
index 000..8195931
--- /dev/null
+++ b/drivers/clk/omap/Makefile
@@ -0,0 +1 @@
+obj-y += clk.o
diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c
new file mode 100644
index 000..5a3c6d9
--- /dev/null
+++ b/drivers/clk/omap/clk.c
@@ -0,0 +1,91 @@
+/*
+ * Texas Instruments OMAP Clock driver
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
+ * Nishanth Menon n...@ti.com
+ * Tony Lindgren t...@atomide.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clkdev.h
+#include linux/clk-provider.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux
Re: [PATCH V4 1/6] clk: OMAP: introduce device tree binding to kernel clock data
Quoting Nishanth Menon (2013-04-14 14:19:17) Overall strategy introduced here is simple: a clock node described in device tree blob is used to identify the exact clock provided in the SoC specific data. This is then linked back using of_clk_add_provider to the device node to be accessible by of_clk_get. Based on discussion contributions from Roger Quadros, Grygorii Strashko and others. Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Mike Turquette mturque...@linaro.org Cc: Paul Walmsley p...@pwsan.com [t...@atomide.com: co-developed] Signed-off-by: Tony Lindgren t...@atomide.com Signed-off-by: Nishanth Menon n...@ti.com I can take this into clk-next after the merge window. Please refresh it for -rc1 as we discussed on irc. As an aside, will Tero's series for migrating to drivers/clk/omap[1] and Rajendra's patch for registering clocks late[2] be refreshed after the merge window? It would be nice to combine these efforts. Thanks, Mike [1] http://article.gmane.org/gmane.linux.ports.arm.omap/95948 [2] http://www.spinics.net/lists/arm-kernel/msg231288.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 0/6] ARM: OMAP3+: Introduce ABB driver
Quoting Andrii Tseglytskyi (2013-04-16 05:40:44)
On 04/16/2013 12:53 AM, Kevin Hilman wrote:
In addition to Mike's comments (which I completely agree with), it would
be very helfpul to see how this is actually used. e.g, how the
regulators are chained together, how the proper ordering is managed,
etc. etc.
We would like to handle voltage scaling in the following way:
I expanded the example below to include the SR AVS regulator.
cpufreq_cpu0
clk_set_rate(cpu0)
|
|--set_voltage(ABB regulator)
|
|--set_voltage(AVS)
|
|--set_voltage(smps123 regulator)
Hi Andrii,
Why was regulator chaining chosen over a simple sequence of calls to
regulator_set_voltage? Instead of nested calls into the regulator
framework, why don't you just make the calls serially? E.g:
regulator_set_voltage(abb_reg, foo_volt);
regulator_set_voltage(avs_reg, bar_volt);
regulator_set_voltage(smps123_reg, baz_volt);
It is still to be determined where these calls originate from; maybe
from clock notifiers, maybe directly from the cpufreq driver's .target()
callback, or maybe somewhere else. Regardless, I do not see why
regulator chaining is truly necessary here. You are just calling
regulator_set_voltage in sequence on a few regulators, right?
I think it would help me a lot to understand why regulator chaining is a
requirement for this to work properly.
Thanks,
Mike
This simple model will be extended to handle AVS as a part of the chain.
smps123 regulator may be changed to VP/VC regulator.
Following example is from integration branch, which already has smps123
regulator.
It demonstrates an example of linkage to chain. ABB regulator is linked
with smps123 and cpu0 inside device tree.
cpu0 calls set_voltage() function for ABB, and then ABB calls
set_voltage() function for smps123 to do actual voltage scaling.
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index bb5ee70..c8cbbee 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -36,7 +36,7 @@
cpus {
cpu@0 {
compatible = arm,cortex-a15;
- cpu0-supply = smps123_reg;
+ cpu0-supply = abb_mpu;
operating-points =
/* kHzuV */
/* Only for Nominal Samples */
@@ -94,6 +94,7 @@
reg = 0x4ae07cdc 0x8,
0x4ae06014 0x4;
ti,tranxdone_status_mask = 0x80;
+ avs-supply = smps123_reg;
operating-points =
/* uV ABB */
88 0
This RFC patch series is verified together with:
https://patchwork.kernel.org/patch/2445091/
Kevin, what do you think about this model in general? Does it fit to
regulator framework?
Thank you.
Regards,
Andrii
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 5/6] ARM: OMAP3+: ABB: introduce ABB driver
Quoting Andrii Tseglytskyi (2013-04-15 06:28:10) Cc: Mike Turquette mturque...@linaro.org Signed-off-by: Andrii.Tseglytskyi andrii.tseglyts...@ti.com Signed-off-by: Mike Turquette mturque...@linaro.org It is very strange to Cc me and include my Signed-off-by. Go ahead and drop my SoB. I'll review these patches this week but I don't think implicitly including my SoB is appropriate. Also why is this limited to LOML? Cc LKML and Mark Brown (regulator maintainer) on the next version. More eyeballs on the code is better. Finally I also suggest that you rename this patch to: regulator: introduce omap abb driver As we move stuff out of arch/arm it's important to loop in wider mailing lists, Cc the appropriate maintainers and title patches more appropriately. Regards, Mike -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
Quoting Nishanth Menon (2013-04-10 10:39:21) diff --git a/drivers/clk/omap/clk.c b/drivers/clk/omap/clk.c new file mode 100644 index 000..63a4cce --- /dev/null +++ b/drivers/clk/omap/clk.c @@ -0,0 +1,94 @@ +/* + * Texas Instruments OMAP Clock driver + * + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/ + * Nishanth Menon + * Tony Lindgren t...@atomide.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed as is WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#include linux/clkdev.h +#include linux/clk-private.h Please use clk-provider.h. Otherwise this looks like an OK transitional solution. Hopefully this will be replaced with a more legitimate clock driver for 3.11. Regards, Mike -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 1/2] ARM: OMAP4: clock: Add device tree support for AUXCLKs
Quoting Nishanth Menon (2013-04-09 13:49:00)
On 10:43-20130409, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [130409 09:54]:
* Roger Quadros rog...@ti.com [130409 03:00]:
On 04/05/2013 06:58 PM, Tony Lindgren wrote:
Can't you just use the clock name there to get it?
In device tree we don't pass around clock names. You can either get
a phandle or an index to the clock.
e.g. Documentation/devicetree/bindings/clock/imx31-clock.txt
Yes I understand that. But the driver/clock/omap driver can just
remap the DT device initially so the board specific clock is
found from the clock alias table. Basically initially a passthrough
driver that can be enhanced to parse DT clock bindings and load
data from /lib/firmware.
Actually probably the driver/clock/omap can even do even less
initially. There probably even no need to remap clocks there.
As long as the DT clock driver understands that a board specific
auxclk is specified in the DT it can just call clk_add_alias() so
the driver will get the right auxclk from cclock44xx_data.c.
Then other features can be added later on like to allocate a
clock entirely based on the binding etc.
I did try to have an implementation for cpufreq using clock nodes.
unfortunately, device tree wont let me have arguments of strings :(
So, I am unable to do clock = clk mpu_dpll;
instead, I am forced to do clock = clk 249;
See http://article.gmane.org/gmane.linux.ports.arm.kernel/229034
Regards,
Mike
Here is an attempt on beagleXM - adds every clock node to the list.
Tons of un-necessary prints added to give an idea - see log:
http://pastebin.com/F9A2zSTr
Would an cleaned up version be good enough as a step #1 of transition?
From 7d373bdb9e9549c1b6ba1775a8dfd96ebe78abfb Mon Sep 17 00:00:00 2001
From: Nishanth Menon n...@ti.com
Date: Tue, 26 Mar 2013 10:23:27 +
Subject: [PATCH] OMAP: add devicetree support for clock nodes.
Dummy patch based on Roger's original idea
Nyet-Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/omap3.dtsi |5 ++
arch/arm/boot/dts/omap34xx.dtsi |2 +
arch/arm/mach-omap2/cclock3xxx_data.c |3 +-
arch/arm/mach-omap2/cclock44xx_data.c |3 +-
arch/arm/mach-omap2/pm.c | 11 +++-
drivers/clk/Kconfig |6 ++
drivers/clk/Makefile |2 +
drivers/clk/ti.c | 100
+
include/linux/clk/ti.h| 30 ++
9 files changed, 157 insertions(+), 5 deletions(-)
create mode 100644 drivers/clk/ti.c
create mode 100644 include/linux/clk/ti.h
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 3344f05..a08990d 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -73,6 +73,11 @@
ti,hwmods = counter_32k;
};
+ clks: clocks {
+ compatible = ti,clock;
+ #clock-cells = 1;
+ };
+
intc: interrupt-controller@4820 {
compatible = ti,omap2-intc;
interrupt-controller;
diff --git a/arch/arm/boot/dts/omap34xx.dtsi b/arch/arm/boot/dts/omap34xx.dtsi
index 75ed4ae..93c2621 100644
--- a/arch/arm/boot/dts/omap34xx.dtsi
+++ b/arch/arm/boot/dts/omap34xx.dtsi
@@ -23,6 +23,8 @@
60 135
;
clock-latency = 30; /* From legacy driver */
+ clocks = clks 249; /* index to cpufreq_ck */
+ clock-names = cpu;
};
};
};
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 4579c3c..d5d5ef5 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -22,6 +22,7 @@
#include linux/clk-private.h
#include linux/list.h
#include linux/io.h
+#include linux/clk/ti.h
#include soc.h
#include iomap.h
@@ -3574,7 +3575,7 @@ int __init omap3xxx_clk_init(void)
for (c = omap3xxx_clks; c omap3xxx_clks + ARRAY_SIZE(omap3xxx_clks);
c++)
if (c-cpu cpu_clkflg) {
- clkdev_add(c-lk);
+ ti_clk_node_add(c-lk);
if (!__clk_init(NULL, c-lk.clk))
omap2_init_clk_hw_omap_clocks(c-lk.clk);
}
diff --git a/arch/arm/mach-omap2/cclock44xx_data.c
b/arch/arm/mach-omap2/cclock44xx_data.c
index 0c6834a..338ef64 100644
--- a/arch/arm/mach-omap2/cclock44xx_data.c
+++ b/arch/arm/mach-omap2/cclock44xx_data.c
@@ -27,6 +27,7 @@
#include linux/clk-private.h
#include linux/clkdev.h
#include linux/io.h
+#include linux/clk/ti.h
#include soc.h
#include iomap.h
@@ -1697,7
Re: [RFC PATCH 5/6] ARM: OMAP3+: ABB: introduce ABB driver
Quoting Nishanth Menon (2013-04-02 19:00:02) On 20:35-20130402, Andrii Tseglytskyi wrote: On 04/02/2013 08:16 PM, Mike Turquette wrote: Quoting Nishanth Menon (2013-04-01 20:35:45) On 17:05-20130401, Mike Turquette wrote: OK, so we're in agreement on what The Future looks like. What does that mean for Andrii's patchset? Unless anyone has an fundamental issue with the approach of an Super regulator controlling sub regulators, I think, in-line with your view, we should probably make ABB as an regulator instead of inventing our own API and hooking it around clock notifiers. ACK. Making the ABB code into a regulator driver is the right thing to do regardless of whether or not we use a Super Regulator(tm) or just chain together Not So Super Regulators(tm). I'm not an expert at the regulator framework, but I encourage Andrii to look into regulator_set_mode(), which might be a more semantically accurate alternative than regulator_set_voltage() for the ABB ldo. Agree. It is a good idea in general. regulator_set_mode() API seems to be good enough for handling ABB mode (FBB/RBB/Bypass). Knowledge about ABB mode on each OPP can be moved from ABB regulator to Super regulator. Thanks a lot for all your comments. Digging a little more on this: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/regulator/consumer.h#n41 If we were to mean usage of mode to mean - usage of PWM/PFM etc mode(like in tps/twl chips), this makes sense. However, if we mean forward, reverse and bypass as modes we might be misusing the original intent of the API. Yeah, I agree that using those modes would probably qualify as abuse. However I still find it tempting to use FAST for FBB and maybe NORMAL or STANDBY for bypass. Instead of using a mode then a voltage could be used. Any Vnom value passed into regulator_set_voltage would result in ABB ldo being bypassed, whereas if 900mV was passed in that would put the ABB ldo into FBB. And that 900mV value isn't really set in stone, it is just more often than not the value observed on OMAP3630 and OMAP4. However that is really a kludge and completely non-intuitive for someone looking at the code for the first time. I haven't gone digging through the regulator stuff concerning this but I hope a good solution can be found. Regards, Mike -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 5/6] ARM: OMAP3+: ABB: introduce ABB driver
Andrii, Sorry to nitpick further but this your replies look very non-standard. Typically a right chevron and a space is used to indent replies instead of a tab. Something like this: https://wiki.openstack.org/wiki/MailingListEtiquette#Reply_Level_Indication Quoting Andrii Tseglytskyi (2013-04-01 03:53:25) In case if VC/VP use clock notifier to scale voltage, there is no guarantee of order. The only option which I see is to create ABB API and call it from OMAP regulator during OPP change. I doubt that is the only option. Do you mean it is the only option to quickly get it working right now? The VC VP code should be converted to the regulator framework if not already. After that is done there are some options for how ABB is handled. The VC VP regulator driver could directly call the api's you list below in their .set_voltage callback. Additionally if the regulator is reentrant then ABB could be modeled as a regulator itself and the VC or VP .set_voltage callback could perhaps call regulator_set_mode(abb_reg, FBB_MODE). Creating a regulator for each ABB instance may be overkill or may not be overkill... that IP has been around since 3630 so several chips use it. omap_abb_pre_scale(struct omap_abb *abb, u32 old_volt, u32 new_volt); omap_abb_post_scale(struct omap_abb *abb, u32 old_volt, u32 new_volt); Mike, do you agree to proceed in this way? Also I need you opinion about files placement. Now it is placed in The above code looks like a quick solution to me. The long-term upstream path for this code needs be decided first. If everything is going to get converted to the regulator framework then I do not agree to proceed that way. Let's figure out what is happening to the VC/VP code first and then figure out what to do about ABB. Regards, Mike drivers/power/avs/abb.c And header will be added to include/linux/power/abb.h Regards, Andrii -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC][PATCH 0/5] Introduce .get_voltage callback into voltdm
On Sat, Mar 30, 2013 at 7:35 PM, Paul Walmsley p...@pwsan.com wrote: Hi Mike, Kevin, On Wed, 3 Oct 2012, Mike Turquette wrote: From: Mike Turquette mturque...@linaro.org This series creates a new callback for struct voltagedomain, .get_voltage. This fetches the voltage from hardware, if possible, and returns it to the caller. We use this call to populate voltdm-nominal_volt at boot time. Just checking on the status of this series. Is this superseded by Andrii's driver? Does it need to be reposted for merging? etc. Hi Paul, Thanks for resurrecting this thread. This series is needed if the ABB transition is triggered by the OMAP VC/VP code. Andrii's approach triggers an ABB transition based on the clock rate-change notifiers but that is still in discussion. So the short answer is I don't know yet. Regards, Mike - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: dpll: enable bypass clock only when attempting dpll bypass
Quoting Rajendra Nayak (2013-03-28 03:59:41)
omap3_noncore_dpll_set_rate() attempts an enable of bypass clk as well
as ref clk for every .set_rate attempt on a noncore DPLL, regardless of
whether the .set_rate results in the DPLL being locked or put in bypass.
Early at boot, while some of these DPLLs are programmed and locked
(using .set_rate for the DPLL), this causes an ordering issue.
For instance, on OMAP5, the USB DPLL derives its bypass clk from ABE DPLL.
If a .set_rate of USB DPLL which programmes the M,N and locks it is called
before the one for ABE, the enable of USB bypass clk (derived from ABE DPLL)
then attempts to lock the ABE DPLL and fails as the M,N values for ABE
are yet to be programmed.
To get rid of this ordering needs, enable bypass clk for a DPLL as part
of its .set_rate only when its being put in bypass, and only enable the
ref clk when its locked.
Hi Rajendra,
Another way to solve this problem would be to model the DPLLs as mux
clocks with a list of possible parents (e.g. clk-parents[2]). Then set
the CLK_SET_RATE_PARENT flag on the USB DPLL which will allow to
propagate the rate request up to the ABE DPLL. This should set the MN
dividers appropriately.
Reported-by: Roger Quadros rog...@ti.com
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/dpll3xxx.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index 3aed4b0..6e9873f 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -480,20 +480,22 @@ int omap3_noncore_dpll_set_rate(struct clk_hw *hw,
unsigned long rate,
if (!dd)
return -EINVAL;
- __clk_prepare(dd-clk_bypass);
- clk_enable(dd-clk_bypass);
- __clk_prepare(dd-clk_ref);
- clk_enable(dd-clk_ref);
Is this safe? I always thought that the programming sequence in the TRM
was to enable both the ref and bypass clocks during DPLL reprogramming.
Maybe I am misremembering or assuming that the code strictly followed
the TRM.
Regards,
Mike
-
if (__clk_get_rate(dd-clk_bypass) == rate
(dd-modes (1 DPLL_LOW_POWER_BYPASS))) {
pr_debug(%s: %s: set rate: entering bypass.\n,
__func__, __clk_get_name(hw-clk));
+ __clk_prepare(dd-clk_bypass);
+ clk_enable(dd-clk_bypass);
ret = _omap3_noncore_dpll_bypass(clk);
if (!ret)
new_parent = dd-clk_bypass;
+ clk_disable(dd-clk_bypass);
+ __clk_unprepare(dd-clk_bypass);
} else {
+ __clk_prepare(dd-clk_ref);
+ clk_enable(dd-clk_ref);
+
if (dd-last_rounded_rate != rate)
rate = __clk_round_rate(hw-clk, rate);
@@ -514,6 +516,8 @@ int omap3_noncore_dpll_set_rate(struct clk_hw *hw,
unsigned long rate,
ret = omap3_noncore_dpll_program(clk, freqsel);
if (!ret)
new_parent = dd-clk_ref;
+ clk_disable(dd-clk_ref);
+ __clk_unprepare(dd-clk_ref);
}
/*
* FIXME - this is all wrong. common code handles reparenting and
@@ -525,11 +529,6 @@ int omap3_noncore_dpll_set_rate(struct clk_hw *hw,
unsigned long rate,
if (!ret)
__clk_reparent(hw-clk, new_parent);
- clk_disable(dd-clk_ref);
- __clk_unprepare(dd-clk_ref);
- clk_disable(dd-clk_bypass);
- __clk_unprepare(dd-clk_bypass);
-
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
