The pointer div_addr is being assigned a value that is never used, it is
being re-assigned a different value near the end of the function where
it is being read in the next statement. The initialization is redundant
and can be removed.
Cleans up clang scan build warning:
drivers/clk/xilinx/clk-xlnx-clock-wizard.c:501:16: warning: Value stored
to 'div_addr' during its initialization is never read [deadcode.DeadStores]
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Link: https://lore.kernel.org/r/20240223134347.3908301-1-colin.i.king@gmail.com
Reviewed-by: Michal Simek <michal.simek@amd.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
clkdev DEV ID information is limited to an array of 20 bytes
(MAX_DEV_ID). It is possible that the ID could be longer than
that. If so, the lookup will fail because the "real ID" will
not match the copied value.
For instance, generating a device name for the I2C Designware
module using the PCI ID can result in a name of:
i2c_designware.39424
clkdev_create() will store:
i2c_designware.3942
The stored name is one off and will not match correctly during probe.
Increase the size of the ID to allow for a longer name.
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
Link: https://lore.kernel.org/r/20240223202556.2194021-1-michael.j.ruhl@intel.com
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Otherwise when when clk_i2s0 muxes to clk_i2s0_div which requires
setting high divider value on clk_i2s0_div, and then muxes back to
clk_i2s0_frac, clk_i2s0_frac would have no way to change the
clk_i2s0_div's divider ratio back to 1 so that it can satisfy the
condition for m/n > 20 for fractional division to work correctly.
Bug is reproducible by playing 44.1k audio, then 48k audio, and then
44.1k audio again. This results in clk_i2s0_div being set to 49 and
clk_i2s0_frac not being able to cope with such a low input clock rate
and audio playing extremely slowly.
The identical issue is on i2s1 and i2s2 clocks, too.
Signed-off-by: Ondrej Jirman <megi@xff.cz>
Link: https://lore.kernel.org/r/20240217193439.1762213-1-megi@xff.cz
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Currently pclk_vo1grf is not exposed, but it should be referenced
from the vo1_grf syscon, which needs it enabled. That syscon is
required for HDMI RX and TX functionality among other things.
Apart from that pclk_vo0grf and pclk_vo1grf are both linked gates
and need the VO's hclk enabled in addition to their parent clock.
No Fixes tag has been added, since the logic requiring these clocks
is not yet upstream anyways.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://lore.kernel.org/r/20240126182919.48402-5-sebastian.reichel@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Because of legacy reasons, the TI clksel composite clocks can have
overlapping reg properties, and use a custom ti,bit-shift property.
For the clksel clocks we can start using of the standard reg property
instead of the custom ti,bit-shift property.
To do this, let's add a ti_clk_get_legacy_bit_shift() helper, and make
ti_clk_get_reg_addr() populate the clock bit offset.
This makes it possible to update the devicetree files to use the reg
property one clock at a time.
Acked-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
In order to use #address-cells = <1> and start making use of the
standard reg property, let's prepare things to ignore the possible
address in the clock node name.
Unless the clock-output-names property is used, the legacy clocks still
fall back to matching the clock data based on the node name.
We use cleanup.h to simplify the return path for freeing tmp.
Acked-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Implement CPU clock control for Exynos850 SoC. It follows the same
procedure which is already implemented for other SoCs in clk-cpu.c:
1. Set the correct rate for the alternate parent (if needed) before
switching to use it as the CPU clock
2. Switch to the alternate parent, so the CPU continues to get clocked
while the PLL is being re-configured
3. Adjust the dividers for the CPU related buses (ACLK, ATCLK, etc)
4. Re-configure the PLL for the new CPU clock rate. It's done
automatically, as the CPU clock rate change propagates to the PLL
clock, because the CPU clock has CLK_SET_RATE_PARENT flag set in
exynos_register_cpu_clock()
5. Once the PLL is locked, set it back as the CPU clock source
6. Set alternate parent clock rate back to max speed
As in already existing clk-cpu.c code, the divider and mux clocks are
configured in a low-level fashion (using direct register access instead
of CCF API), to avoid affecting how DIV and MUX clock flags are declared
in the actual clock driver (clk-exynos850.c).
No functional change. This patch adds support for Exynos850 CPU clock,
but doesn't enable it per se.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Link: https://lore.kernel.org/r/20240224202053.25313-13-semen.protsenko@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Abstract CPU clock registers by keeping their offsets in a dedicated
chip specific structure to accommodate for oncoming Exynos850 support,
which has different offsets for cluster 0 and cluster 1. This rework
also makes it possible to use exynos_set_safe_div() for all chips, so
exynos5433_set_safe_div() is removed here to reduce the code
duplication. The ".regs" field has to be (void *) as different Exynos
chips can have very different register layout, so this way it's possible
for ".regs" to point to different structures, each representing its own
chip's layout.
No functional change.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Link: https://lore.kernel.org/r/20240224202053.25313-11-semen.protsenko@linaro.org
[krzysztof: drop redundant const for regs in exynos_cpuclk_chip]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Keep chip specific data in the data structure, don't mix it with code.
It makes it easier to add more chip specific data further. Having all
chip specific data in the table eliminates possible code bloat when
adding more rate handlers for new chips, and also makes it possible to
keep some other chip related data in that array.
No functional change.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Link: https://lore.kernel.org/r/20240224202053.25313-10-semen.protsenko@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Use a dedicated enum field to explicitly specify which register layout
should be used for the CPU clock, instead of passing it as a bit flag.
This way it would be possible to keep the chip-specific data in some
array, where each chip structure could be accessed by its corresponding
layout index. It prepares clk-cpu.c for adding new chips support, which
might have different data for different CPU clusters.
No functional change.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Link: https://lore.kernel.org/r/20240224202053.25313-9-semen.protsenko@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
The documentation for struct exynos_cpuclk says .ctrl_base field should
contain the controller base address. There are two different problems
with that:
1. All Exynos clock drivers are actually passing CPU_SRC register offset
via CPU_CLK() macro, which in turn gets assigned to mentioned
.ctrl_base field. Because CPU_SRC register usually already has 0x200
offset from controller's base, all other register offsets in
clk-cpu.c (like DIVs and MUXes) are specified as offsets from CPU_SRC
offset, and not from controller's base. That makes things confusing
and inconsistent with register offsets provided in Exynos clock
drivers, also breaking the contract for .ctrl_base field as described
in struct exynos_cpuclk doc.
2. Furthermore, some Exynos chips have an additional offset for the
start of CPU clock registers block (inside of the CMU). There might
be different reasons for that, e.g.:
- The CMU contains clocks for two different CPUs (like in Exynos5420)
- The CMU contains also non-CPU clocks as well (like in Exynos4)
- The CPU CMU exists as a dedicated hardware block in the SoC layout,
but is modelled as a part of bigger CMU in the driver (like in case
of Exynos3250)
That means the .ctrl_base field is actually not a controller's base,
but instead it's a start address of the CPU clock registers inside of
the CMU.
Rework all register offsets in clk-cpu.c to be actual offsets from the
CPU clock register block start, and fix offsets provided to CPU_CLK()
macro in all Exynos clock drivers. Also clarify the .ctrl_base field
documentation and rename it to just .base, because it doesn't really
contain the CMU base.
No functional change.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Link: https://lore.kernel.org/r/20240224202053.25313-8-semen.protsenko@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reduce the code duplication by making all chips use a single version of
exynos_cpuclk_notifier_cb() function. That will prevent the code bloat
when adding new chips support too.
Also don't pass base address to pre/post rate change functions, as it
can be easily derived from already passed cpuclk param.
No functional change.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Link: https://lore.kernel.org/r/20240224202053.25313-6-semen.protsenko@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Pass CPU clock data structure to exynos_register_cpu_clock() instead of
passing its fields separately there. That simplifies the signature of
exynos_register_cpu_clock() and makes it easier to add more fields to
struct samsung_cpu_clock later. This style follows the example of
samsung_clk_register_pll().
No functional change.
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Link: https://lore.kernel.org/r/20240224202053.25313-5-semen.protsenko@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Add four functions to register clk_hw based on the fw_name field in
clk_parent_data, ie the value in the DT property `clock-names`.
There are variants for devm or not and passing an accuracy or not
passing one:
- clk_hw_register_fixed_factor_fwname
- clk_hw_register_fixed_factor_with_accuracy_fwname
- devm_clk_hw_register_fixed_factor_fwname
- devm_clk_hw_register_fixed_factor_with_accuracy_fwname
The `struct clk_parent_data` init is extracted from
__clk_hw_register_fixed_factor to each calling function. It is required
to allow each function to pass whatever field they want, not only index.
Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
Link: https://lore.kernel.org/r/20240221-mbly-clk-v7-2-31d4ce3630c3@bootlin.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Most of clocks and their parents are defined in contiguous range,
But in few cases, there is gap in clock numbers[0].
Driver assumes clocks to be in contiguous range, and add their clock
ids incrementally.
New firmware started returning error while calling get_freq and is_on
API for non-available clock ids.
In this fix, driver checks and adds only valid clock ids.
[0] https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j7200/clocks.html
Section Clocks for NAVSS0_CPTS_0 Device, clock id 12-15 not present.
Fixes: 3c13933c60 ("clk: keystone: sci-clk: add support for dynamically probing clocks")
Signed-off-by: Udit Kumar <u-kumar1@ti.com>
Link: https://lore.kernel.org/r/20240213082640.457316-1-u-kumar1@ti.com
Reviewed-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
CLK_INFRA_SSPM_32K_SELF has the "f_f26m_ck" clock assigned as its parent.
This is inconsistent as the clock is part of a group that are all gates
without dividers, and this makes the kernel think it runs at 26 MHz.
After clarification from MediaTek engineers, the correct parent is
actually the system 32 KHz clock.
Fixes: 1eb8d61ac5 ("clk: mediatek: mt8183: Add back SSPM related clocks")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20240219105125.956278-1-wenst@chromium.org
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
