This reverts commit db400ac144. We have
drivers that are still using the .round_rate ops from here. We could
implement both determine_rate and round_rate for these divider ops, but
for now let's just kick out the commit that tried to change it and
convert various drivers properly.
Reported-by: Guenter Roeck <linux@roeck-us.net>
Fixes: db400ac144 ("clk: divider: Switch from .round_rate to .determine_rate by default")
Cc: Jerome Brunet <jbrunet@baylibre.com>
Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20210702011058.77284-1-sboyd@kernel.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
.determine_rate is meant to replace .round_rate. The former comes with a
benefit which is especially relevant on 32-bit systems: since
.determine_rate uses an "unsigned long" (compared to a "signed long"
which is used by .round_rate) the maximum value on 32-bit systems
increases from 2^31 (or approx. 2.14GHz) to 2^32 (or approx. 4.29GHz).
Switch to a .determine_rate implementation by default so 32-bit systems
can benefit from the increased maximum value as well as so we have one
fewer user of .round_rate.
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20210627223959.188139-3-martin.blumenstingl@googlemail.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
These are useful when running on 32-bit systems to increase the upper
supported frequency limit. clk_ops.round_rate returns a signed long
which limits the maximum rate on 32-bit systems to 2^31 (or approx.
2.14GHz). clk_ops.determine_rate internally uses an unsigned long so
the maximum rate on 32-bit systems is 2^32 or approx. 4.29GHz.
To avoid code-duplication switch over divider_{ro_,}round_rate_parent
to use the new divider_{ro_,}determine_rate functions.
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20210627223959.188139-2-martin.blumenstingl@googlemail.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
If a driver registers a divider clock with a parent_hw instead of the
parent_name, the parent_hw is ignored and the clock does not have a
parent.
Fix this by initializing the parents the same way they are initialized
for clock gates.
Fixes: ff25881713 ("clk: divider: Add support for specifying parents via DT/pointers")
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Acked-by: Michal Simek <michal.simek@xilinx.com>
Link: https://lore.kernel.org/r/20210121071659.1226489-3-m.tretter@pengutronix.de
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
After commit fc0c209c14 ("clk: Allow parents to be specified without
string names") we can use DT or direct clk_hw pointers to specify
parents. Create a generic function that shouldn't be used very often to
encode the multitude of ways of registering a divider clk with different
parent information. Then add a bunch of wrapper macros that only pass
down what needs to be passed down to the generic function to support
this with less arguments.
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Link: https://lkml.kernel.org/r/20190830150923.259497-13-sboyd@kernel.org
[sboyd@kernel.org: Export __clk_hw_register_divider]
The clk_init_data struct needs to be initialized to zero for the new
parent_map implementation to work correctly. Otherwise, the member which
is available first will get processed.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Link: https://lkml.kernel.org/r/20191115162901.17456-2-manivannan.sadhasivam@linaro.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
This flag was historically used to indicate that a clk is a "basic" type
of clk like a mux, divider, gate, etc. This never turned out to be very
useful though because it was hard to cleanly split "basic" clks from
other clks in a system. This one flag was a way for type introspection
and it just didn't scale. If anything, it was used by the TI clk driver
to indicate that a clk_hw wasn't contained in the SoC specific clk
structure. We can get rid of this define now that TI is finding those
clks a different way.
Cc: Tero Kristo <t-kristo@ti.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Paul Burton <paul.burton@mips.com>
Cc: James Hogan <jhogan@kernel.org>
Cc: <linux-mips@vger.kernel.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: <linux-pwm@vger.kernel.org>
Cc: <linux-amlogic@lists.infradead.org>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Now that clk_{readl,writel} is just an alias for {readl,writel}, we can
switch all users of clk_* to use the accessors directly and remove the
helpers.
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
[sboyd@kernel.org: Also convert renesas file so that this can be
compile independently]
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Add a clock specific flag to switch register accesses to big endian, to
allow runtime configuration of big endian divider clocks.
Signed-off-by: Jonas Gorski <jonas.gorski@gmail.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
When a divider clock has CLK_DIVIDER_READ_ONLY set, it means that the
register shall be left un-touched, but it does not mean the clock
should stop rate propagation if CLK_SET_RATE_PARENT is set
This is properly handled in qcom clk-regmap-divider but it was not in
the generic divider
To fix this situation, introduce a new helper function
divider_ro_round_rate, on the same model as divider_round_rate.
Fixes: e6d5e7d90b ("clk-divider: Fix READ_ONLY when divider > 1")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Tested-By: David Lechner <david@lechnology.com>
Signed-off-by: Michael Turquette <mturquette@baylibre.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Export clk_div_mask() in clk-provider header so every clock providers
derived from the generic clock divider may share the definition instead
of redefining it.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Michael Turquette <mturquette@baylibre.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
divider_recalc_rate() is an helper function used by clock divider of
different types, so the structure containing the 'hw' pointer is not
always a 'struct clk_divider'
At the following line:
> div = _get_div(table, val, flags, divider->width);
in several cases, the value of 'divider->width' is garbage as the actual
structure behind this memory is not a 'struct clk_divider'
Fortunately, this width value is used by _get_val() only when
CLK_DIVIDER_MAX_AT_ZERO flag is set. This has never been the case so
far when the structure is not a 'struct clk_divider'. This is probably
why we did not notice this bug before
Fixes: afe76c8fd0 ("clk: allow a clk divider with max divisor when zero")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Add a check for error returned by divider value calculation to avoid
writing error code into hw register.
Signed-off-by: Alex Frid <afrid@nvidia.com>
Reviewed-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Reviewed-by: Jon Mayo <jmayo@nvidia.com>
Fixes: bca9690b94 ("clk: divider: Make generic for usage elsewhere")
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
So far, divider_round_rate only considers the parent clock returned by
clk_hw_get_parent.
This works fine on clocks that have a single parents, this doesn't work on
muxes, since we will only consider the first parent, while other parents
may totally be able to provide a better combination.
Clocks in that case cannot use divider_round_rate, so would have to come up
with a very similar logic to work around it. Instead of having to do
something like this, and duplicate that logic everywhere, create a
divider_round_rate parent to allow caller to give an additional parameter
for the parent clock to consider.
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
clk-divider uses clk_readl()/clk_writel() everywhere, except in
clk_divider_round_rate(), where plain readl() is used. Change this to
clk_readl(), as it makes a difference on powerpc.
Fixes: e6d5e7d90b ("clk-divider: Fix READ_ONLY when divider > 1")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: James Hogan <james.hogan@imgtec.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Add registration APIs in the clk divider code to return struct
clk_hw pointers instead of struct clk pointers. This way we hide
the struct clk pointer from providers unless they need to use
consumer facing APIs.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Because _next_div() returns a valid divider, there is no need to
consult _is_valid_div() for the validity of the divider in every
iteration.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
to_clk_*(_hw) macros have been repeatedly defined in many places.
This patch moves all the to_clk_*(_hw) definitions in the common
clock framework to public header clk-provider.h, and drop the local
definitions.
Signed-off-by: Geliang Tang <geliangtang@163.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Commit e6d5e7d90b ("clk-divider: Fix READ_ONLY when divider > 1") removed
the special ops struct for read-only clocks and instead opted to handle
them inside the regular ops.
On the rk3368 this results in breakage as aclkm now gets set a value.
While it is the same divider value, the A53 core still doesn't like it,
which can result in the cpu ending up in a hang.
The reason being that "ACLKENMasserts one clock cycle before the rising
edge of ACLKM" and the clock should only be touched when STANDBYWFIL2
is asserted.
To fix this, reintroduce the read-only ops but do include the round_rate
callback. That way no writes that may be unsafe are done to the divider
register in any case.
The Rockchip use of the clk_divider_ops is adapted to this split again,
as is the nxp, lpc18xx-ccu driver that was included since the original
commit. On lpc18xx-ccu the divider seems to always be read-only
so only uses the new ops now.
Fixes: e6d5e7d90b ("clk-divider: Fix READ_ONLY when divider > 1")
Reported-by: Zhang Qing <zhangqing@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
When we use a clk divider with a divider table, we limit the
maximum divider value in divider_get_val() to the
div_mask(width), but when we calculate the divider in
divider_round_rate() we don't consider that the maximum divider
may be limited by the width. Pass the width along to
_get_table_maxdiv() so that we only return the maximum divider
that is valid. This is useful for clocks that want to share the
same divider table while limiting the available dividers to some
subset of the table depending on the width of the bitfield.
Cc: Rajendra Nayak <rnayak@codeaurora.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
On 32-bit architectures, 'unsigned long' (the type used to hold clock
rates, in Hz) is often only 32 bits wide. DIV_ROUND_UP() (as used in,
e.g., commit b11d282dbe "clk: divider: fix rate calculation for
fractional rates") can yield an integer overflow on clock rates that are
not (by themselves) too large to fit in 32 bits, because it performs
addition before the division. See for example:
DIV_ROUND_UP(3000000000, 1500000000) = (3.0G + 1.5G - 1) / 1.5G
= OVERFLOW / 1.5G
This patch fixes such cases by always promoting the dividend to 64-bits
(unsigned long long) before doing the division. While this patch does
not resolve the issue with large clock rates across the common clock
framework nor address the problems with doing full 64-bit arithmetic on
a 32-bit architecture, it does fix some issues seen when using clock
dividers on a 3GHz reference clock to produce a 1.5GHz CPU clock for an
ARMv7 Brahma B15 SoC.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Reference: http://lkml.kernel.org/g/20150413201433.GQ32500@ld-irv-0074
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
We're removing struct clk from the clk provider API, so switch
this code to using the clk_hw based provider APIs.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Mostly converted with the following snippet:
@@
struct clk_hw *E;
@@
-__clk_get_flags(E->clk)
+clk_hw_get_flags(E)
Acked-by: Tero Kristo <t-kristo@ti.com>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Max Filippov <jcmvbkbc@gmail.com>
Acked-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Coquelin <mcoquelin.stm32@gmail.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
The basic clock types use conditional locking for the register
accessor spinlocks. Add __acquire() and __release() markings in
the right locations so that sparse isn't tripped up on the
conditional locking.
drivers/clk/clk-mux.c:68:12: warning: context imbalance in 'clk_mux_set_parent' - different lock contexts for basic block
drivers/clk/clk-divider.c:379:12: warning: context imbalance in 'clk_divider_set_rate' - different lock contexts for basic block
drivers/clk/clk-gate.c:71:9: warning: context imbalance in 'clk_gate_endisable' - different lock contexts for basic block
drivers/clk/clk-fractional-divider.c:36:9: warning: context imbalance in 'clk_fd_recalc_rate' - different lock contexts for basic block
drivers/clk/clk-fractional-divider.c:68:12: warning: context imbalance in 'clk_fd_set_rate' - different lock contexts for basic block
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
This commit allows certain Broadcom STB clock dividers to be used with
clk-divider.c. It allows for a clock whose field value is the equal
to the divisor, execpt when the field value is zero, in which case the
divisor is 2^width. For example, consider a divisor clock with a two
bit field:
value divisor
0 4
1 1
2 2
3 3
Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
Signed-off-by: Michael Turquette <mturquette@baylibre.com>
Printing an error on kmalloc() failures is unnecessary. Remove
the print and use *ptr in sizeof() for future-proof code.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Similar to the reasoning for the previous commit
DIV_ROUND_CLOSEST(parent_rate, rate)
might not be the best integer divisor to get a good approximation for
rate from parent_rate (given the metric for CLK_DIVIDER_ROUND_CLOSEST).
For example assume a parent rate of 1000 Hz and a target rate of 700.
Using DIV_ROUND_CLOSEST the suggested divisor gets calculated to 1
resulting in a target rate of 1000 with a delta of 300 to the desired
rate. With choosing 2 as divisor however the resulting rate is 500 which
is nearer to 700.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
It's an invalid approach to assume that among two divider values
the one nearer the exact divider is the better one.
Assume a parent rate of 1000 Hz, a divider with CLK_DIVIDER_POWER_OF_TWO
and a target rate of 89 Hz. The exact divider is ~ 11.236 so 8 and 16
are the candidates to choose from yielding rates 125 Hz and 62.5 Hz
respectivly. While 8 is nearer to 11.236 than 16 is, the latter is still
the better divider as 62.5 is nearer to 89 than 125 is.
Fixes: 774b514390 (clk: divider: Add round to closest divider)
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
The rate provided at the output of a clk-divider is calculated as:
DIV_ROUND_UP(parent_rate, div)
since commit b11d282dbe (clk: divider: fix rate calculation for
fractional rates). So to yield a rate not bigger than r parent_rate
must be <= r * div.
The effect of choosing a parent rate that is too big as was done before
this patch results in wrongly ruling out good dividers.
Note that this is not a complete fix as __clk_round_rate might return a
value >= its 2nd parameter. Also for dividers with
CLK_DIVIDER_ROUND_CLOSEST set the calculation is not accurate. But this
fixes the test case by Sascha Hauer that uses a chain of three dividers
under a fixed clock.
Fixes: b11d282dbe (clk: divider: fix rate calculation for fractional rates)
Suggested-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
Commit bca9690b94 ("clk: divider: Make generic for usage elsewhere")
returned only the divider value for read-only dividers instead of the
actual rate.
Fixes: bca9690b94 ("clk: divider: Make generic for usage elsewhere")
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: James Hogan <james.hogan@imgtec.com>
Tested-by: James Hogan <james.hogan@imgtec.com>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
Some devices don't use mmio to interact with dividers. Split out the
logic from the register read/write parts so that we can reuse the
division logic elsewhere.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Tested-by: Kenneth Westfield <kwestfie@codeaurora.org>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
The common clk_register_{divider,gate,mux} functions allocated memory
for internal data which wasn't freed anywhere. Drivers using these
helpers could only unregister clocks but the memory would still leak.
Add corresponding unregister functions which will release all resources.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
Commit 79c6ab5095 (clk: divider: add CLK_DIVIDER_READ_ONLY flag) in
v3.16 introduced the CLK_DIVIDER_READ_ONLY flag which caused the
recalc_rate() and round_rate() clock callbacks to be omitted.
However using this flag has the unfortunate side effect of causing the
clock recalculation code when a clock rate change is attempted to always
treat it as a pass-through clock, i.e. with a fixed divide of 1, which
may not be the case. Child clock rates are then recalculated using the
wrong parent rate.
Therefore instead of dropping the recalc_rate() and round_rate()
callbacks, alter clk_divider_bestdiv() to always report the current
divider as the best divider so that it is never altered.
For me the read only clock was the system clock, which divided the PLL
rate by 2, from which both the UART and the SPI clocks were divided.
Initial setting of the UART rate set it correctly, but when the SPI
clock was set, the other child clocks were miscalculated. The UART clock
was recalculated using the PLL rate as the parent rate, resulting in a
UART new_rate of double what it should be, and a UART which spewed forth
garbage when the rate changes were propagated.
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Thomas Abraham <thomas.ab@samsung.com>
Cc: Tomasz Figa <t.figa@samsung.com>
Cc: Max Schwarz <max.schwarz@online.de>
Cc: <stable@vger.kernel.org> # v3.16+
Acked-by: Haojian Zhuang <haojian.zhuang@gmail.com>
Signed-off-by: Michael Turquette <mturquette@linaro.org>
Commit c686078 ("clk: divider: Add round to closest divider") introduced
a helper function to check whether given divisor is the best one instead
of direct check. However due to int type used instead of unsigned long
for passing calculated rates to this function in certain cases an
overflow could occur, for example when trying to obtain maximum possible
clock rate by calling clk_round_rate(..., UINT_MAX).
This patch fixes this issue by changing the type of rate, now and best
arguments of the function to unsigned long, which is the type that
should be used for clock rates.
Signed-off-by: Tomasz Figa <t.figa@samsung.com>
Acked-by: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
Commit 1d9fe6b97 ("clk: divider: Fix best div calculation for power-of-two and
table dividers") introduces a regression in its _table_round_up function.
When the divider passed to this function is greater than the max divider
available in the table, this function returns table's max divider.
Problem is that it causes an infinite loop in clk_divider_bestdiv() because
_next_div() will never return a value greater than maxdiv.
Instead of returning table's max divider, this patch returns INT_MAX.
Reported-by: Fabio Estevam <festevam@gmail.com>
Reported-by: Shawn Guo <shawn.guo@freescale.com>
Tested-by: Fabio Estevam <festevam@gmail.com>
Tested-by: Shawn Guo <shawn.guo@freescale.com>
Signed-off-by: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
From: Heiko Stuebner <heiko@sntech.de>
Similar to muxes which already have a read-only flag there sometimes
exist dividers which should not be changed by the clock framework
but whose value still should be readable.
Therefore add a READ_ONLY flag similar to the mux-one to clk-divider
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[changed flag bit to BIT(5) as suggested by Tomasz Figa]
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
Acked-by: Tomasz Figa <t.figa@samsung.com>
Acked-by: Max Schwarz <max.schwarz@online.de>
Tested-by: Max Schwarz <max.schwarz@online.de>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
Currently, the for-loop used to try all the different dividers to find the
one that best fit tries all the values from 1 to max_div, incrementing by one.
In case of power-of-two, or table based divider, the loop isn't optimal.
Instead of incrementing by one, this patch provides directly the next divider.
Signed-off-by: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
In some cases, we want to be able to round the divider to the closest one,
instead than rounding up.
This patch adds a new CLK_DIVIDER_ROUND_CLOSEST flag to specify the divider
has to round to closest div, keeping rounding up as de default behaviour.
Signed-off-by: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
The divider returned by clk_divider_bestdiv() is likely to be invalid in case
of power-of-two and table dividers when CLK_SET_RATE_PARENT flag isn't set.
Fixes boot on STiH416 platform.
Signed-off-by: Maxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
[mturquette@linaro.org: trivial merge conflict & updated changelog]
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
864000000 Hz. With dividers 6, 7 and 8 the theoretical rates are:
6: 144000000
7: 123428571.428571...
8: 108000000
Calling clk_round_rate() with the rate in the first column will give the
rate in the second column:
144000000 -> 144000000
143999999 -> 123428571
123428572 -> 123428571
123428571 -> 108000000
Note how clk_round_rate() returns 123428571 for rates from 123428572 to
143999999, which is mathematically correct, but when clk_round_rate() is
called with 123428571, the returned value is surprisingly 108000000.
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 108000000, 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:
144000000 -> 144000000
143999999 -> 123428572
123428572 -> 123428572
123428571 -> 108000000
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
Commit 6d9252bd9a (clk: Add support for power of two type dividers)
merged in v3.6 added the _get_val function to convert a divisor value to
a register field value depending on the flags. However it used the type
u8 for the div field, causing divisors larger than 255 to be masked
and the resultant clock rate to be too high.
E.g. in my case an 11bit divider was supposed to divide 24.576 MHz down
to 32.768KHz. The divisor was correctly calculated as 750 (0x2ee). This
was masked to 238 (0xee) resulting in a frequency of 103.26KHz.
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Rajendra Nayak <rnayak@ti.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: stable@vger.kernel.org
Signed-off-by: Mike Turquette <mturquette@linaro.org>
the common clock drivers were motivated/initiated by ARM development
and apparently assume little endian peripherals
wrap register/peripherals access in the common code (div, gate, mux)
in preparation of adding COMMON_CLK support for other platforms
Signed-off-by: Gerhard Sittig <gsi@denx.de>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
clk_register_divider() needs to be exported so that it could be used
in a module driver, otherwise we get the following error:
ERROR: "clk_register_divider" [sound/soc/mxs/snd-soc-mxs.ko] undefined!
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
[mturquette@linaro.org: also export clk_register_divider_table]
In both Hisilicon & Rockchip Cortex-A9 based chips, they don't use the
paradigm of reading-changing-writing the register contents.
Instead they use a hiword mask to indicate the changed bits.
When b01 should be set as setting divider, it also needs to indicate
the change by setting hiword mask (b11 << 16).
The patch adds divider flag for this usage.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
If the current rate of parent clock is sufficient to provide child a
requested rate with a proper divider setting, the rate change request
should not be propagated. Instead, changing the divider setting is good
enough to get child clock run at the requested rate.
On an imx6q clock configuration illustrated below,
ahb --> ipg --> ipg_per
132M 66M 66M
calling clk_set_rate(ipg_per, 22M) with the current
clk_divider_bestdiv() implementation will result in the rate change up
to ahb level like the following, because of the unnecessary/incorrect
rate change propagation.
ahb --> ipg --> ipg_per
66M 22M 22M
Fix the problem by trying to see if the requested rate can be achieved
by simply changing the divider value, and in that case return the
divider immediately from function clk_divider_bestdiv() as the best
one, so that all those unnecessary rate change propagation can be saved.
Reported-by: Anson Huang <b20788@freescale.com>
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
Dividers which have CLK_DIVIDER_ONE_BASED set have a redundant state,
being a divider value of zero. Some hardware implementations allow a
zero divider which simply doesn't alter the frequency. I.e. it acts like
a divide by one or bypassing the divider.
This flag is used to handle such HW in the clk-divider model.
Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
