Age | Commit message (Collapse) | Author |
|
The function pointer population and sanity checking logic got a bit ugly
with the advent of the .determine_rate callback. Clean it up.
Signed-off-by: Mike Turquette <mturquette@linaro.org>
|
|
This allows readl-only composite clocks by making mux_ops->set_parent and
divider_ops->round_rate/set_rate optional.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Acked-By: Max Schwarz <max.schwarz@online.de>
Tested-By: Max Schwarz <max.schwarz@online.de>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
|
|
mux_ops->set_parent
In case the rate_hw does not implement determine_rate, but only round_rate
we fallback to best_parent selection if mux_hw is present and support
reparenting.
This also fixes a rate calculation problem when using the standard div and
mux ops, as in this case currently only the mux->determine_rate is used
in the composite rate calculation.
So when for example the composite clock has two parents at 600 and 800MHz,
the requested rate is 75MHz, which the divider could provide, without this
change the rate would be set 600MHz ignoring the divider completely.
This may be way out of spec for the component.
Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
[heiko@sntech.de: fixed output return a rate instead of the diff]
Acked-By: Max Schwarz <max.schwarz@online.de>
Tested-By: Max Schwarz <max.schwarz@online.de>
Tested-by: Gabriel Fernandez <gabriel.fernandez@linaro.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
|
|
The composite clock's .determine_rate implementation can call the
underyling .determine_rate callback corresponding to rate_hw or the
underlying .determine_rate callback corresponding to mux_hw. In both
cases we pass in rate_hw, which is wrong. Fixed by passing mux_hw into
the correct callback.
Reported-by: Lemon Dai <dailemon.gl@gmail.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
|
|
This commit adds .determine_rate support to the composite clock. It will
use the .determine_rate callback from the rate component if available,
and fall back on the mux component otherwise. This allows composite
clocks to enjoy the benefits of automatic clock reparenting.
Signed-off-by: Emilio López <emilio@elopez.com.ar>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
|
|
The composite clock assumes that any clock implementing the .recalc_rate
callback will also implement .round_rate and .set_rate. This is not
always true; the basic fixed-rate clock will only implement .recalc_rate
and a fixed-divider clock may choose to implement .recalc_rate and
.round_rate but not .set_rate.
Fix this by conditionally registering .round_rate and .set_rate
callbacks based on the rate_ops passed in to clk_composite_register.
Signed-off-by: Mike Turquette <mturquette@linaro.org>
Cc: Prashant Gaikwad <pgaikwad@nvidia.com>
Tested-by: Emilio López <emilio@elopez.com.ar>
Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
|
|
Rename all div_hw and div_ops related variables and functions to use
rate_hw, rate_ops, etc. This is to make the rate-change portion of the
composite clk implementation more generic. A patch following this one
will allow for fixed-rate clocks to reuse this infrastructure.
Signed-off-by: Mike Turquette <mturquette@linaro.org>
Reviewed-by: Prashant Gaikwad <pgaikwad@nvidia.com>
Tested-by: Emilio López <emilio@elopez.com.ar>
Cc: Gregory CLEMENT <gregory.clement@free-electrons.com>
|
|
Not all clocks are required to be decomposed into basic clock
types but at the same time want to use the functionality
provided by these basic clock types instead of duplicating.
For example, Tegra SoC has ~100 clocks which can be decomposed
into Mux -> Div -> Gate clock types making the clock count to
~300. Also, parent change operation can not be performed on gate
clock which forces to use mux clock in driver if want to change
the parent.
Instead aggregate the basic clock types functionality into one
clock and just use this clock for all operations. This clock
type re-uses the functionality of basic clock types and not
limited to basic clock types but any hardware-specific
implementation.
Signed-off-by: Prashant Gaikwad <pgaikwad@nvidia.com>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
|