| Age | Commit message (Collapse) | Author |
|---|
|
As the driver is handling all i.MX5 series SoCs inlcuding i.MX50, rather
than just i.MX51 and i.MX53, let's rename it to clk-imx5.c.
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
|
|
Code which initializes the "clk_init_data.ops" checks pll->rate_table
before that field is ever assigned to so it always picks
"clk_pll1416x_min_ops".
This breaks dynamic rate rounding for features such as cpufreq.
Fix by checking pll_clk->rate_table instead, here pll_clk refers to
the constant initialization data coming from per-soc clk driver.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Fixes: 8646d4dcc7fb ("clk: imx: Add PLLs driver for imx8mm soc")
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
The div offset of some clocks are different from their mux offset
and the COMPOSITE clock-type require that div and mux offset are
the same, so add a new COMPOSITE_DIV_OFFSET clock-type to handle that.
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Experimentally it can be seen that going into deep sleep (specifically
setting PMU_CLR_DMA and PMU_CLR_BUS in RK3288_PMU_PWRMODE_CON1)
appears to fail unless "aclk_dmac1" is on. The failure is that the
system never signals that it made it into suspend on the GLOBAL_PWROFF
pin and it just hangs.
NOTE that it's confirmed that it's the actual suspend that fails, not
one of the earlier calls to read/write registers. Specifically if you
comment out the "PMU_GLOBAL_INT_DISABLE" setting in
rk3288_slp_mode_set() and then comment out the "cpu_do_idle()" call in
rockchip_lpmode_enter() then you can exercise the whole suspend path
without any crashing.
This is currently not a problem with suspend upstream because there is
no current way to exercise the deep suspend code. However, anyone
trying to make it work will run into this issue.
This was not a problem on shipping rk3288-based Chromebooks because
those devices all ran on an old kernel based on 3.14. On that kernel
"aclk_dmac1" appears to be left on all the time.
There are several ways to skin this problem.
A) We could add "aclk_dmac1" to the list of critical clocks and that
apperas to work, but presumably that wastes power.
B) We could keep a list of "struct clk" objects to enable at suspend
time in clk-rk3288.c and use the standard clock APIs.
C) We could make the rk3288-pmu driver keep a list of clocks to enable
at suspend time. Presumably this would require a dts and bindings
change.
D) We could just whack the clock on in the existing syscore suspend
function where we whack a bunch of other clocks. This is particularly
easy because we know for sure that the clock's only parent
("aclk_cpu") is a critical clock so we don't need to do anything more
than ungate it.
In this case I have chosen D) because it seemed like the least work,
but any of the other options would presumably also work fine.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Elaine Zhang <zhangqing@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
CLK_SET_RATE_PARENT would be dropped.
Merge two flag setting together to correct the error.
Fixes: 5a1cc4c27ad2 ("clk: mediatek: Add flags to mtk_gate")
Cc: <stable@vger.kernel.org>
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
The USB PHY clock can be configured as (grand) parent of uart0_sclk and
sclk_gpu. It has been observed that UART0 doesn't work reliably in high
speed mode with the PHY clock as input when certain USB devices are
plugged to the USB HOST1 port (see https://crrev.com/c/320543).
Prefix the name of the PHY clock with a '.' in the non-USB muxes to
effectively remove the clock as input from these muxes.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
It appears that there is a typo in the rk3288 TRM. For
GRF_SOC_CON0[7] it says that 0 means "vepu" and 1 means "vdpu". It's
the other way around.
How do I know? Here's my evidence:
1. Prior to commit 4d3e84f99628 ("clk: rockchip: describe aclk_vcodec
using the new muxgrf type on rk3288") we always pretended that we
were using "aclk_vdpu" and the comment in the code said that this
matched the default setting in the system. In fact the default
setting is 0 according to the TRM and according to reading memory
at bootup. In addition rk3288-based Chromebooks ran like this and
the video codecs worked.
2. With the existing clock code if you boot up and try to enable the
new VIDEO_ROCKCHIP_VPU as a module (and without "clk_ignore_unused"
on the command line), you get errors like "failed to get ack on
domain 'pd_video', val=0x80208". After flipping vepu/vdpu things
init OK.
3. If I export and add both the vepu and vdpu to the list of clocks
for RK3288_PD_VIDEO I can get past the power domain errors, but now
I freeze when the vpu_mmu gets initted.
4. If I just mark the "vdpu" as IGNORE_UNUSED then everything boots up
and probes OK showing that somehow the "vdpu" was important to keep
enabled. This is because we were actually using it as a parent.
5. After this change I can hack "aclk_vcodec_pre" to parent from
"aclk_vepu" using assigned-clocks and the video codec still probes
OK.
6. Rockchip has said so on the mailing list [1].
...so let's fix it.
Let's also add CLK_SET_RATE_PARENT to "aclk_vcodec_pre" as suggested
by Jonas Karlman. Prior to the same commit you could do
clk_set_rate() on "aclk_vcodec" and it would change "aclk_vdpu".
That's because "aclk_vcodec" was a simple gate clock (always gets
CLK_SET_RATE_PARENT) and its direct parent was "aclk_vdpu". After
that commit "aclk_vcodec_pre" gets in the way so we need to add
CLK_SET_RATE_PARENT to it too.
[1] https://lkml.kernel.org/r/1d17b015-9e17-34b9-baf8-c285dc1957aa@rock-chips.com
Fixes: 4d3e84f99628 ("clk: rockchip: describe aclk_vcodec using the new muxgrf type on rk3288")
Suggested-by: Jonas Karlman <jonas@kwiboo.se>
Suggested-by: Randy Li <ayaka@soulik.info>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Add clock for the USB Device Controller PHY.
Signed-off-by: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
See similar issue solved by commit 5f2420ed2189
("clk: qcom: Skip halt checks on gcc_usb3_phy_pipe_clk for 8998")
Without this patch, PCIe PHY init fails:
qcom-qmp-phy 1c06000.phy: pipe_clk enable failed err=-16
phy phy-1c06000.phy.0: phy init failed --> -16
Signed-off-by: Marc Gonzalez <marc.w.gonzalez@free.fr>
Reviewed-by: Jeffrey Hugo <jhugo@codeaurora.org>
Fixes: b5f5f525c547 ("clk: qcom: Add MSM8998 Global Clock Control (GCC) driver")
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
The Turing Clock Controller provides resources related to running the
Turing subsystem.
PM runtime is used to ensure that the associated AHB clock is ticking
while the clock framework is accessing the registers in the Turing clock
controller.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Some clocks can only be turned on by resetting the block containing
them, provide a clock type that allow us to reference these clocks and
have the client drivers enable and "disable" them.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Add the clocks and resets need in order to control the Turing
remoteproc.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Some modules may need to change its clock rate before turn on it.
So changing PLL's rate when it is off should be allowed.
This patch removes PLL enabled check before set rate, so that
PLLs can set new frequency even if they are off.
On MT8173 for example, ARMPLL's enable bit can be controlled by
other HW. That means ARMPLL may be turned on even if we (CPU / SW)
set ARMPLL's enable bit as 0. In this case, SW may want and can
still change ARMPLL's rate by changing its pcw and postdiv settings.
But without this patch, new pcw setting will not be applied because
its enable bit is 0.
Signed-off-by: James Liao <jamesjj.liao@mediatek.com>
Acked-by: Michael Turquette <mturuqette@baylibre.com>
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
Reviewed-by: James Liao <jamesjj.liao@mediatek.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Add MT8183 clock support, include topckgen, apmixedsys,
infracfg, mcucfg and subsystem clocks.
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
In previous MediaTek PLL design, it assumes the pcw change control
is always on the CON1 register.
However, the pcw change bit on MT8183 was moved onto CON0 because
the the PCW length of audio PLLs are extended to 32-bit.
Add configurable pcw_chg_reg to set the pcw change control register
address or using the default control register CON1 if without
setting in pll data.
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
Reviewed-by: James Liao <jamesjj.liao@mediatek.com>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
1. pcwibits: The integer bits of pcw for PLLs is extend to 8 bits,
add a variable to indicate this change and
backward-compatible.
2. fmin: The PLL frequency lower-bound is vary from 1GHz to
1.5GHz, add a variable to indicate platform-dependent.
Signed-off-by: Owen Chen <owen.chen@mediatek.com>
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
Acked-by: Sean Wang <sean.wang@kernel.org>
Reviewed-by: James Liao <jamesjj.liao@mediatek.com>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
On both MT8183 & MT6765, there add "set/clr" register for
each clkmux setting, and one update register to trigger value change.
It is designed to prevent read-modify-write racing issue.
The sw design need to add a new API to handle this hw change with
a new mtk_clk_mux/mtk_mux struct in new file "clk-mux.c", "clk-mux.h".
Signed-off-by: Owen Chen <owen.chen@mediatek.com>
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
Reviewed-by: James Liao <jamesjj.liao@mediatek.com>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
[sboyd@kernel.org: Squash in flags=0 to silence warning]
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
PLLs with tuner_en bit, such as APLL1, need to disable
tuner_en before apply new frequency settings, or the new frequency
settings (pcw) will not be applied.
The tuner_en bit will be disabled during changing PLL rate
and be restored after new settings applied.
Fixes: e2f744a82d725 (clk: mediatek: Add MT2712 clock support)
Cc: <stable@vger.kernel.org>
Signed-off-by: Owen Chen <owen.chen@mediatek.com>
Signed-off-by: Weiyi Lu <weiyi.lu@mediatek.com>
Reviewed-by: James Liao <jamesjj.liao@mediatek.com>
Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Most rk3288-based boards are derived from the EVB and thus use a PWM
regulator for the logic rail. However, most rk3288-based boards don't
specify the PWM regulator in their device tree. We'll deal with that
by making it critical.
NOTE: it's important to make it critical and not just IGNORE_UNUSED
because all PWMs in the system share the same clock. We don't want
another PWM user to turn the clock on and off and kill the logic rail.
This change is in preparation for actually having the PWMs in the
rk3288 device tree actually point to the proper PWM clock. Up until
now they've all pointed to the clock for the old IP block and they've
all worked due to the fact that rkpwm was IGNORE_UNUSED and that the
clock rates for both clocks were the same.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
Providing a range for usleep_range() allows the hrtimer subsystem to
coalesce timers - the delay is runtime configurable so a factor 2
is taken to provide the range. With the expected range for
enable_delay_us being milliseconds, the range should lie in the 250us
range which is sufficient for hrtimer optimization.
Signed-off-by: Nicholas Mc Guire <hofrat@opentech.at>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Fix sparse warning:
drivers/clk/tegra/clk-super.c:124:22:
warning: symbol 'tegra_clk_super_mux_ops' was not declared. Should it be static?
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
use PTR_ERR_OR_ZERO inetead of return code
Signed-off-by: Ding Xiang <dingxiang@cmss.chinamobile.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
The firmware sets BIT(13) in clkflag to mark a divider as fractional
divider. The clock driver copies the clkflag straight to the flags of
the common clock framework. In the common clk framework flags, BIT(13)
is defined as CLK_DUTY_CYCLE_PARENT.
Add a new field to the zynqmp_clk_divider to specify if a divider is a
fractional devider. Set this field based on the clkflag when registering
a divider.
At the same time, unset BIT(13) from clkflag when copying the flags to
the common clk framework flags.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
The zynqmp_clk_register_* functions are internal functions of the
driver. Only clkc.c uses these functions to register these clocks.
Therefore, there is no need to export these functions.
The gate and pll already don't export their register_* functions.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
The kerneldoc refers to __zynqmp_clock_get_topology(), but actually
documents __zynqmp_clock_get_parents(). Refer to the correct function
name in the kerneldoc.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Versal EEMI APIs uses clock device ID which is combination of class,
subclass, type and clock index (e.g. 0x8104006 in which 0-13 bits are
for index(6 in given example), 14-19 bits are for clock type (i.e pll,
out or ref, 1 in given example), 20-25 bits are for subclass which is
nothing but clock type only), 26-32 bits are for device class, which
is clock(0x2) for all clocks) while zynqmp firmware uses clock ID
which is index only (e.g 0, 1, to n, where n is max_clock id).
To use zynqmp clock driver for versal platform also, extend use
of QueryAttribute API to fetch device class, subclass and clock type
to create clock device ID. In case of zynqmp this attributes would be
0 only, so there won't be any effect on clock id as it would use
clock index only.
Signed-off-by: Tejas Patel <tejas.patel@xilinx.com>
Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Jolly Shah <jollys@xilinx.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Zero divider is valid and default for some of ZynqMP
clocks. Allow zero divisor when CLK_DIVIDER_ALLOW_ZERO
for the clock is set.
Signed-off-by: Rajan Vaja <rajanv@xilinx.com>
Signed-off-by: Jolly Shah <jollys@xilinx.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
This variable is no longer used and the compiler rightly complains that
it should be removed. Drop it to silence the following:
drivers/clk/renesas/rcar-gen3-cpg.c: In function 'cpg_sd_clk_register':
drivers/clk/renesas/rcar-gen3-cpg.c:386:15: warning: unused variable 'i' [-Wunused-variable]
unsigned int i;
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Fixes: b953eaaeb58e ("clk: renesas: rcar-gen3: Fix cpg_sd_clock_round_rate() return value")
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
Since commit 648e921888ad ("clk: x86: Stop marking clocks as
CLK_IS_CRITICAL"), the pmc_plt_clocks of the Bay Trail SoC are
unconditionally gated off. Unfortunately this will break systems where these
clocks are used for external purposes beyond the kernel's knowledge. Fix it
by implementing a system specific quirk to mark the necessary pmc_plt_clks as
critical.
Fixes: 648e921888ad ("clk: x86: Stop marking clocks as CLK_IS_CRITICAL")
Signed-off-by: David Müller <dave.mueller@gmx.ch>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
|
|
The MBUS clock is used by the MBUS controller, so let's export it so that
we can use it in our DT node.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
Allwinner's BSP for the A83T lists pll-video0 as the first parent to
csi-mclk with index 0. This parent is not listed in the datasheet, but
actually works, and makes more sense considering the index is the
default value out of reset.
Add pll-video0 as a parent to csi-mclk with index 0.
Fixes: 05359be1176b ("clk: sunxi-ng: Add driver for A83T CCU")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
The g12a audio clock controller is largely similar to the existing axg
controller, with the addition of the spdif output B and TDM pad clocks.
This commit extends the existing axg audio clock controller driver
to work with multiple compatibles and add the g12a specific clocks
Signed-off-by: Maxime Jourdan <mjourdan@baylibre.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lkml.kernel.org/r/20190329160649.31603-5-jbrunet@baylibre.com
|
|
Clock inputs should not be exported outside the controller. It is a hack
to have a stable global clock name within the clock controller, even for
clocks external to the controller.
There is an ongoing effort to replace this hack with something better.
The first step is to not register those clocks in the provider anymore,
so we can completely remove them later on.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lkml.kernel.org/r/20190329160649.31603-4-jbrunet@baylibre.com
|
|
The audio clock controller is compatible with axg and g12a SoC family.
Having each clock name prefixed with "axg_" looks weird on the g12a.
This change replace the "axg_" by "aud_" in fron the clock names.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lkml.kernel.org/r/20190329160649.31603-3-jbrunet@baylibre.com
|
|
cpg_sd_clock_round_rate() may return an unsupported clock rate for the
requested clock rate. Therefore, when cpg_sd_clock_set_rate() sets the
clock rate acquired by cpg_sd_clock_round_rate(), an error may occur.
This is not conform the clk API design.
This patch fixes that by making sure cpg_sd_clock_calc_div() considers
only the division values defined in cpg_sd_div_table[].
With this fix, the cpg_sd_clock_round_rate() always return a support
clock rate.
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
Fixes: 90c073e53909da85 ("clk: shmobile: r8a7795: Add SD divider support")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
|
|
Add an explanation why zero width check is needed when generating factor
mask using GENMASK() macro.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
Video related clocks need to set rate as close as possible to the
requested one, so they should be able to change parent clock rate.
When processing 4K video, VPU clock has to be set to higher rate than it
is default parent rate. Because of that, VPU clock should be able to
change parent clock rate.
Add CLK_SET_RATE_PARENT flag to tcon-lcd0, tcon-tv0 and ve.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
The MUX bits for esdhc_{a,c,d}_sel are shifted by one bit within CSCMR1,
because esdhc_b_sel (ESDHC3_CLK_SEL in the Reference Manual) is extended
by one bit.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
i.MX50 does not have a periph_apm clock. Instead, the main bus clock
(a.k.a. periph_clk) comes directly from a MUX between pll1_sw, pll2_sw,
pll3_sw, and lp_apm.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
H6 manual and BSP clock driver both states that hdmi-cec clock has two
possible parents, osc32k and pll-periph0-2x with 36621 predivider.
Because pll-periph0-2x is always 1.2 GHz, both parents give same
hdmi-cec rate - 32768 Hz, which is exactly the rate needed for HDMI CEC
controller to operate correctly.
However, for some reason, HDMI CEC controller doesn't work if default
parent (osc32k) is used. BSP HDMI driver also always use pll-periph0-2x
as hdmi-cec clock parent.
In order to solve the issue, preset hdmi-cec clock parent to
pll-periph0-2x.
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
Sometimes one of the nkmp factors is unused. This means that one of the
factors shift and width values are set to 0. Current nkmp clock code
generates a mask for each factor with GENMASK(width + shift - 1, shift).
For unused factor this translates to GENMASK(-1, 0). This code is
further expanded by C preprocessor to final version:
(((~0UL) - (1UL << (0)) + 1) & (~0UL >> (BITS_PER_LONG - 1 - (-1))))
or a bit simplified:
(~0UL & (~0UL >> BITS_PER_LONG))
It turns out that result of the second part (~0UL >> BITS_PER_LONG) is
actually undefined by C standard, which clearly specifies:
"If the value of the right operand is negative or is greater than or
equal to the width of the promoted left operand, the behavior is
undefined."
Additionally, compiling kernel with aarch64-linux-gnu-gcc 8.3.0 gave
different results whether literals or variables with same values as
literals were used. GENMASK with literals -1 and 0 gives zero and with
variables gives 0xFFFFFFFFFFFFFFF (~0UL). Because nkmp driver uses
GENMASK with variables as parameter, expression calculates mask as ~0UL
instead of 0. This has further consequences that LSB in register is
always set to 1 (1 is neutral value for a factor and shift is 0).
For example, H6 pll-de clock is set to 600 MHz by sun4i-drm driver, but
due to this bug ends up being 300 MHz. Additionally, 300 MHz seems to be
too low because following warning can be found in dmesg:
[ 1.752763] WARNING: CPU: 2 PID: 41 at drivers/clk/sunxi-ng/ccu_common.c:41 ccu_helper_wait_for_lock.part.0+0x6c/0x90
[ 1.763378] Modules linked in:
[ 1.766441] CPU: 2 PID: 41 Comm: kworker/2:1 Not tainted 5.1.0-rc2-next-20190401 #138
[ 1.774269] Hardware name: Pine H64 (DT)
[ 1.778200] Workqueue: events deferred_probe_work_func
[ 1.783341] pstate: 40000005 (nZcv daif -PAN -UAO)
[ 1.788135] pc : ccu_helper_wait_for_lock.part.0+0x6c/0x90
[ 1.793623] lr : ccu_helper_wait_for_lock.part.0+0x48/0x90
[ 1.799107] sp : ffff000010f93840
[ 1.802422] x29: ffff000010f93840 x28: 0000000000000000
[ 1.807735] x27: ffff800073ce9d80 x26: ffff000010afd1b8
[ 1.813049] x25: ffffffffffffffff x24: 00000000ffffffff
[ 1.818362] x23: 0000000000000001 x22: ffff000010abd5c8
[ 1.823675] x21: 0000000010000000 x20: 00000000685f367e
[ 1.828987] x19: 0000000000001801 x18: 0000000000000001
[ 1.834300] x17: 0000000000000001 x16: 0000000000000000
[ 1.839613] x15: 0000000000000000 x14: ffff000010789858
[ 1.844926] x13: 0000000000000000 x12: 0000000000000001
[ 1.850239] x11: 0000000000000000 x10: 0000000000000970
[ 1.855551] x9 : ffff000010f936c0 x8 : ffff800074cec0d0
[ 1.860864] x7 : 0000800067117000 x6 : 0000000115c30b41
[ 1.866177] x5 : 00ffffffffffffff x4 : 002c959300bfe500
[ 1.871490] x3 : 0000000000000018 x2 : 0000000029aaaaab
[ 1.876802] x1 : 00000000000002e6 x0 : 00000000686072bc
[ 1.882114] Call trace:
[ 1.884565] ccu_helper_wait_for_lock.part.0+0x6c/0x90
[ 1.889705] ccu_helper_wait_for_lock+0x10/0x20
[ 1.894236] ccu_nkmp_set_rate+0x244/0x2a8
[ 1.898334] clk_change_rate+0x144/0x290
[ 1.902258] clk_core_set_rate_nolock+0x180/0x1b8
[ 1.906963] clk_set_rate+0x34/0xa0
[ 1.910455] sun8i_mixer_bind+0x484/0x558
[ 1.914466] component_bind_all+0x10c/0x230
[ 1.918651] sun4i_drv_bind+0xc4/0x1a0
[ 1.922401] try_to_bring_up_master+0x164/0x1c0
[ 1.926932] __component_add+0xa0/0x168
[ 1.930769] component_add+0x10/0x18
[ 1.934346] sun8i_dw_hdmi_probe+0x18/0x20
[ 1.938443] platform_drv_probe+0x50/0xa0
[ 1.942455] really_probe+0xcc/0x280
[ 1.946032] driver_probe_device+0x54/0xe8
[ 1.950130] __device_attach_driver+0x80/0xb8
[ 1.954488] bus_for_each_drv+0x78/0xc8
[ 1.958326] __device_attach+0xd4/0x130
[ 1.962163] device_initial_probe+0x10/0x18
[ 1.966348] bus_probe_device+0x90/0x98
[ 1.970185] deferred_probe_work_func+0x6c/0xa0
[ 1.974720] process_one_work+0x1e0/0x320
[ 1.978732] worker_thread+0x228/0x428
[ 1.982484] kthread+0x120/0x128
[ 1.985714] ret_from_fork+0x10/0x18
[ 1.989290] ---[ end trace 9babd42e1ca4b84f ]---
This commit solves the issue by first checking value of the factor
width. If it is equal to 0 (unused factor), mask is set to 0, otherwise
GENMASK() macro is used as before.
Fixes: d897ef56faf9 ("clk: sunxi-ng: Mask nkmp factors when setting register")
Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
Testing has shown that the RPC-IF module clock's parent is the RPCD2
clock, not the RPC one -- the RPC-IF register reads stall otherwise...
Fixes: 94e3935b5756 ("clk: renesas: r8a77980: Add RPC clocks")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
According to the R-Car Gen3 Hardware Manual Errata for Rev. 1.50 of Feb
12, 2019, the DRIF clocks have been renamed as follows:
DRIF0 to DRIF00
DRIF1 to DRIF01
DRIF2 to DRIF10
DRIF3 to DRIF11
DRIF4 to DRIF20
DRIF5 to DRIF21
DRIF6 to DRIF30
DRIF7 to DRIF31
Therefore, this patch renames the DRIF clocks from DRIFn to DRIFmm.
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
|
|
The clock sources of the AXI-bus clock (266.66 MHz) used for Audio-DMAC
DMA transfers are:
Channel R-Car H3 R-Car M3-W R-Car M3-N R-Car E3
---------------------------------------------------------------
Audio-DMAC0 S1D2 S1D2 S1D2 S1D2
Audio-DMAC1 S1D2 S1D2 S1D2 -
As a result, change the parent clocks of the Audio-DMAC{0,1} module
clocks on R-Car H3, R-Car M3-W, and R-Car M3-N to S1D2, and change the
parent clock of the Audio-DMAC0 module on R-Car E3 to S1D2.
NOTE: This information will be reflected in a future revision of the
R-Car Gen3 Hardware Manual.
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
[geert: Update R-Car D3, RZ/G2M, and RZ/G2E]
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
|
|
The clock sources of the AXI BUS clock (266.66 MHz) used for SYS-DMAC
DMA transfers are:
Channel R-Car H3 R-Car M3-W R-Car M3-N
-------------------------------------------------
SYS-DMAC0 S0D3 S0D3 S0D3
SYS-DMAC1 S3D1 S3D1 S3D1
SYS-DMAC2 S3D1 S3D1 S3D1
As a result, change the parent clocks of the SYS-DMAC{1,2} module clocks
on R-Car H3, R-Car M3-W, and R-Car M3-N to S3D1.
NOTE: This information will be reflected in a future revision of the
R-Car Gen3 Hardware Manual.
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
[geert: Update RZ/G2M]
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
|
|
According to the R-Car Gen3 Hardware Manual Rev. 1.00, and the RZ/G2
Hardware Manual Rev. 0.61, the parent clock of the HS-USB module
clocks on R-Car Gen3 and RZ/G2 SoCs is S3D2.
Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
[takeshi: Update R-Car H3, M3-N, and E3]
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
[geert: Update RZ/G2M and RZ/G2E]
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
|
|
According to the R-Car Gen3 Hardware Manual Rev. 1.00, and the RZ/G2
Hardware Manual Rev. 0.61, the parent clock of the EHCI/OHCI module
clocks on R-Car Gen3 and RZ/G2 SoCs is S3D2.
Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
[takeshi: Update R-Car H3, M3-N, and E3]
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
[geert: Update RZ/G2M and RZ/G2E]
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
|
|
Adds support for RZ/G2E (r8a774c0) Z2 clock.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Tested-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Reviewed-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Adds support for R-Car E3 (r8a77990) Z2 clock.
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
[simon: reworked changelog; rebased]
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
|
Support Z and Z2 clocks with parent frequencies greater than UINT32_MAX Hz
(~4.29GHz).
The DIV_ROUND_CLOSEST_ULL() macro accepts a 64bit dividend and 32bit
divisor. This leads to truncation of the divisor, which is the Z or Z2
parent clock frequency in HZ, on platforms where frequency of that clock is
greater than UINT32_MAX Hz.
To resolve this problem the DIV64_U64_ROUND_CLOSEST() macro, which takes
on an unsigned 64bit dividend and divisor, is used.
An earlier version of this patch made use of the existing
DIV_ROUND_CLOSEST() macro, which accepts the prevailing type of the
dividend and divisor. However, this does not compile on 32bit systems, such
as i386 and mips, when called with the types used at this call site, an
unsigned long long dividend and unsigned long divisor.
This work is in preparation for supporting the Z2 clock on the
R-Car Gen3 E3 (r8a77990) SoC which has a 4.8GHz parent clock.
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
|
