For an external clock source, which is gated via a GPIO, the
rate change should typically be propagated to the parent clock.
The situation where we are requiring this propagation, is when an
external clock is connected to override an internal clock (which typically
has a fixed rate). The external clock can have a different rate than the
internal one, and may also be variable, thus requiring the rate
propagation.
This rate change wasn't propagated until now, and it's unclear about cases
where this shouldn't be propagated. Thus, it's unclear whether this is
fixing a bug, or extending the current driver behavior. Also, it's unsure
about whether this may break any existing setups; in the case that it does,
a device-tree property may be added to disable this flag.
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Link: https://lkml.kernel.org/r/20191108071718.17985-1-alexandru.ardelean@analog.com
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>
The current implementation of gpio-gate-clk enables/disables the clock
using the GPIO in the ->enable() and ->disable() clock callbacks. This
requires the GPIO to be configurable in atomic contexts. While it is
the case for most memory-mapped GPIO controllers, it is not the case
for GPIO expanders on I2C or SPI.
This commit extends the gpio-gate-clk to check whether the GPIO calls
require sleeping or not. If sleeping is not required, the current
implementation based on ->enable()/->disable() is kept. However, if
sleeping is needed, we instead implement the logic in the ->prepare()
and ->unprepare() hooks. Thanks to this, a gate clock connected to a
GPIO on a GPIO expander can be controlled with the existing driver.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[sboyd@kernel.org: Mark clk ops static]
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
In preparation to remove the node name pointer from struct device_node,
convert printf users to use the %pOFn format specifier.
Cc: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: linux-clk@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
When changing or retrieving clock parents, the caller is in a sleepable
state (like prepare) so the GPIO operation need not be atomic. Replace
gpiod_{g|s}et_value with gpiod_{g|s}et_value_cansleep in the {g|s}et_parent
calls for the GPIO based clock mux.
This fixes a "slowpath" warning when the GPIO controller is an I2C expander
or something similar.
Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Requesting the GPIOD_OUT_LOW low will make sure the GPIO is
deasserted when requested. The gpiolib core will make sure that
if the GPIO line is active low, it will be logically driven high
when deasserted, see drivers/gpiolib.c gpiod_configure_flags().
Cc: Sergej Sawazki <ce3a@gmx.de>
Cc: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
After som grep:ing it turns out nothing in the kernel is really calling
clk_[hw_]_register_gpio_[gate|mux](). All existing instances are just
created directly from the device tree probe functions at the bottom of
the clk-gpio.c clock provider file.
This means we can change the signature of the function without any
consequences! Everyone should be using GPIO descriptors now, so let's
just go in and enforce that.
This saves a bit of code since GPIO descriptors know inherently if they
are active low so no need for the code keeping track of that.
We leave it to the caller to come up with the GPIO descriptor. It is
nowadays possible to do that even without a corresponding device, so
no excuse not to pass them around. The one in-kernel user lifecycles
it using devm_gpiod_get() in gpio_clk_driver_probe().
Cc: Sergej Sawazki <ce3a@gmx.de>
Cc: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Add registration APIs in the clk gpio 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>
The check for < 0 is impossible now that
of_clk_get_parent_count() returns an unsigned int. Simplify the
code and update the type here.
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
We mis-merged the original patch from Russell here and so the
patch went almost all the way, except that we still failed to
probe when there wasn't a clocks property in the DT node. Allow
that case by making a negative value from
of_clk_get_parent_count() into "no parents", like the original
patch did.
Fixes: 7ed88aa2ef ("clk: fix clk-gpio.c with optional clock= DT property")
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Michael Turquette <mturquette@baylibre.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
clk_get() for DT based clks already returns EPROBE_DEFER when the
OF clk provider is not present. So having all this code in the
clk provider to return EPROBE_DEFER when the gpio isn't ready yet
can be replaced with a platform driver that doesn't add the clk
provider until the gpio can be requested. Get rid of the
OF_CLK_DECLARE and convert this to a platform driver instead.
Tested-by: Jyri Sarha <jsarha@ti.com>
Cc: Sergej Sawazki <ce3a@gmx.de>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Jon Nettleton <jon@solid-run.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
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>
When the clock DT property is not given, of_clk_get_parent_count()
returns -ENOENT, which then tries to allocate -2 x 4 bytes of memory,
which of course fails, causing the whole driver to fail to create
the clock.
This causes the SolidRun platforms to fail probing the SDHCI1 interface
which is connected to the WiFi.
Fix this by detecting errno codes, skipping the allocation, and fixing
of_clk_gpio_gate_delayed_register_get() to handle a NULL parent_names
array.
Fixes: 80eeb1f0f7 ("clk: add gpio controlled clock multiplexer")
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Michael Turquette <mturquette@baylibre.com>
We might make bad memory allocations if we get (e.g.) -ENOSYS from
of_clk_get_parent_count().
Noticed by Coverity.
Fixes: f66541ba02 ("clk: gpio: Get parent clk names in of_gpio_clk_setup()")
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Cc: Jyri Sarha <jsarha@ti.com>
Cc: Sergej Sawazki <ce3a@gmx.de>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Michael Turquette <mturquette@baylibre.com>
If we fail to allocate parent_name then we are returning but we missed
freeing data which has already been allocated.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Signed-off-by: Michael Turquette <mturquette@baylibre.com>
Get parent clk names in of_gpio_clk_setup() and store the names
in struct clk_gpio_delayed_register_data instead of doing it from
the clk provider's get() callback. of_clk_get_parent_name() can't
be called in struct of_clk_provider's get() callback since it may
make a call to of_clk_get_from_provider() and this in turn tries
to recursively lock of_clk_mutex.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Cc: Sergej Sawazki <ce3a@gmx.de>
Fixes: 0a4807c2f9 ("clk: Make of_clk_get_parent_name() robust with #clock-cells = 1")
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Let's encourage const arrays of parent names like other basic
clock types.
Cc: Sergej Sawazki <ce3a@gmx.de>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
We don't unlock the mutex if we fail to allocate the parent names
array. Unlock it and return an error in this case as well.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Acked-by: Julia Lawall <julia.lawall@lip6.fr>
Cc: Sergej Sawazki <ce3a@gmx.de>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
The file clk-gpio-gate.c does not only contain the gate clock, but also
the mux clock. Rename the file to clk-gpio.c.
Cc: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Sergej Sawazki <ce3a@gmx.de>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
