Move clock parent tables down, after the PLL declarataions, so that we
can use pll hw clock fields in the next commit.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221204124508.1415713-8-dmitry.baryshkov@linaro.org
Use ARRAY_SIZE() instead of manually specifying num_parents. This makes
adding/removing entries to/from parent_data easy and errorproof.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221204124508.1415713-7-dmitry.baryshkov@linaro.org
Convert the clock driver to specify parent data rather than parent
names, to actually bind using 'clock-names' specified in the DTS rather
than global clock names. Use parent_hws where possible to refer parent
clocks directly, skipping the lookup.
Note, the system names for xo clocks were changed from "xo" to
"xo_board" to follow the example of other platforms. This switches the
clocks to use DT-provided "xo_board" clock instead of manually
registered "xo" clock and allows us to drop qcom_cc_register_board_clk()
call from the driver at some point.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221204124508.1415713-6-dmitry.baryshkov@linaro.org
Rearrage clock parent tables and PLL declarations (pull parents down
and gpll4 up), so that we can use pll hw clock fields in the next
commit.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221204124508.1415713-5-dmitry.baryshkov@linaro.org
Use ARRAY_SIZE() instead of manually specifying num_parents. This makes
adding/removing entries to/from parent_data easy and errorproof.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221204124508.1415713-4-dmitry.baryshkov@linaro.org
Switch to using devres-managed version of clk_notifier_register(). This
allows us to drop driver's remove() callback.
Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221205113545.575702-1-robert.marko@sartura.hr
Now that all clocks have individual names, remove the names of SoCs from
the RPMH clock definitions. Replace it with the common clk_rpmh_ prefix.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Alex Elder <elder@linaro.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221202185843.721673-9-dmitry.baryshkov@linaro.org
RPMH VRM clocks are frequently shared between several platforms. It
makes little sense to encode the SoC name into the clock name, if the
same clock is used for other SoCs.
Rework the VRM clock definitions to add resource-specific suffix. Keep
the userspace-visible clock name, but encode the part of cmd resource
and the divider into the variable name. This also make it obvious which
variant is used, making the code less error-prone.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Alex Elder <elder@linaro.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221202185843.721673-8-dmitry.baryshkov@linaro.org
RPMH ARC clocks are frequently shared between several platforms. It
makes little sense to encode the SoC name into the clock name, if the
same clock is used for other SoCs.
Rework the ARC clock definitions to remove the SoC name. Keep the
userspace-visible clock name, but encode the divider into the variable
name. This also makes it obvious which divider is used by the platform,
making the code less error-prone.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Alex Elder <elder@linaro.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221202185843.721673-7-dmitry.baryshkov@linaro.org
Both ARC and VRM clocks have minor differences between platforms.
However using SoC names directly results in duplication, confusion and
occasional errors. Next patches are going to drop the SoC names and
encode these differences into the clock names.
To keep the system clock names (visible to userspace) intact, add
separate symbol names that are used in the code.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Alex Elder <elder@linaro.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221202185843.721673-6-dmitry.baryshkov@linaro.org
There are no platform-specific parts in the BCM clocks, drop the
platform name from the clock definitions, replacing it with clk_rpmh to
have the common prefix.
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221202185843.721673-5-dmitry.baryshkov@linaro.org
In preparation for the further cleanup, remove the active only names,
they can be easily generated from the standard ones.
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Alex Elder <elder@linaro.org>
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221202185843.721673-4-dmitry.baryshkov@linaro.org
After the grouping it is obvious that some of the clock definitions are
pure duplicates. Rename them to use a single common name for the clock.
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221202185843.721673-3-dmitry.baryshkov@linaro.org
In preparations to the further changes, group all RPMH clock definitions
to ease review. Group the clocks by their type to make similar/duplicate
clocks stand out.
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221202185843.721673-2-dmitry.baryshkov@linaro.org
A single clock definition can be used on different platforms. Thus the
platform part of the clock name is not correct (and can be misleading).
Remove the platform-specific part of the defined clock.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221202070814.482470-5-dmitry.baryshkov@linaro.org
Drop the _clk suffix from other clocks too. This does not produce any
user-visible changes, just syntax sugar.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221202070814.482470-4-dmitry.baryshkov@linaro.org
To simplify code reviews remove duplication between normal and
active-only clock names. Get a single clock name and generate both names
internally.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221202070814.482470-3-dmitry.baryshkov@linaro.org
The RPM_FIXED and RPM_XO_BUFFER clocks do not have the active-only
counterparts. Drop corresponding unused arguments.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221202070814.482470-2-dmitry.baryshkov@linaro.org
Add Global Clock controller (GCC) driver for SM8550 SoC,
which includes the gcc resets and gdsc.
This patch is based on an initial downstream driver.
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221130112852.2977816-6-abel.vesa@linaro.org
Add a LUCID_OLE PLL type for SM8550 SoC from Qualcomm.
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221130112852.2977816-5-abel.vesa@linaro.org
The SM8550 GCC GDSCs need a higher timeout value when polling for status,
so increase it to 1500us, while leaving the delay between disable-enable
sequence for votable gdscs to stay the same.
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221130112852.2977816-4-abel.vesa@linaro.org
Similar to msm8916, msm8939 has (at least) 6 "General Purpose" clocks that
can be muxed to SoC pins. These clocks are:
GP_CLK{0, 1} : GPIO_{31, 32} (Belongs to CAMSS according to Linux)
GP_CLK_{1-3}{A, B} : GPIO_{49-51, 97, 12, 13} (Belongs to GCC itself)
GP_MN : GPIO_110 (Doesn't seem to be described in gcc,
ignored in this patch)
Those clocks may be used as e.g. PWM sources for external peripherals.
Add more frequencies to the table for those clocks so it's possible
for arbitrary peripherals to make use of them.
Reference: https://lore.kernel.org/r/20220612145955.385787-5-nikita@trvn.ru
Signed-off-by: Lin, Meng-Bo <linmengbo0689@protonmail.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221117171343.24216-1-linmengbo0689@protonmail.com
Convert platform_get_resource(), devm_ioremap_resource() to a single
call to devm_platform_get_and_ioremap_resource(), as this is exactly
what this function does.
Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn>
Signed-off-by: ye xingchen <ye.xingchen@zte.com.cn>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/202211171403340042731@zte.com.cn
It appears that having only .name populated in parent_data for clocks
which are only globally searchable currently will not work as the clk core
won't copy that name if there is no .fw_name present as well.
So, populate .fw_name for all parent clocks in parent_data.
Fixes: ae55ad32e2 ("clk: qcom: ipq8074: convert to parent data")
Co-developed-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221116214655.1116467-1-robimarko@gmail.com
Modernize the krait-cc driver to parent-data API and refactor to drop
any use of parent_names. From Documentation all the required clocks should
be declared in DTS so fw_name can be correctly used to get the parents
for all the muxes. .name is also declared to save compatibility with old
DT.
While at it also drop some hardcoded index and introduce an enum to make
index values more clear.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221109005631.3189-5-ansuelsmth@gmail.com
Some bootloader may leave the system in an even more undefined state
with the secondary mux of L2 or other cores sourcing out of the acpu_aux
parent. This results in the clk set to the PXO rate or a PLL8 rate.
The current logic to reset the mux and set them to a defined state only
handle if the mux are configured to source out of QSB. Change this and
force a new and defined state if the current clk is lower than the aux
rate. This way we can handle any wrong configuration where the mux is
sourcing out of QSB (rate 225MHz, currently set to a virtual rate of 1),
PXO rate (rate 25MHz) or PLL8 (needs to be configured to run at 384Mhz).
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221109005631.3189-3-ansuelsmth@gmail.com
clk-krait ignore any rate change if clk is not flagged as enabled.
Correctly enable the secondary mux and div clk to correctly change rate
instead of silently ignoring the request.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221109005631.3189-2-ansuelsmth@gmail.com
The secondary mux parent order is swapped.
This currently doesn't cause problems as the secondary mux is used for idle
clk and as a safe clk source while reprogramming the hfpll.
Each mux have 2 or more output but he always have a safe source to
switch while reprogramming the connected pll. We use a clk notifier to
switch to the correct parent before clk core can apply the correct rate.
The parent to switch is hardcoded in the mux struct.
For the secondary mux the safe source to use is the qsb parent as it's
the only fixed clk as the acpus_aux is a pll that can source from pxo or
from pll8.
The hardcoded safe parent for the secondary mux is set to index 0 that
in the secondary mux map is set to 2.
But the index 0 is actually acpu_aux in the parent list.
Fix the swapped parents to correctly handle idle frequency and output a
sane clk_summary report.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221109005631.3189-1-ansuelsmth@gmail.com
Use devm variant for clk notifier register and correctly handle free
resource on driver remove.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221108215827.30475-1-ansuelsmth@gmail.com
Currently div2 value is applied to the wrong bits. This is caused by a
bug in the code where the shift is done only for lpl, for anything
else the mask is not shifted to the correct bits.
Fix this by correctly shift if lpl is not supported.
Fixes: 4d7dc77bab ("clk: qcom: Add support for Krait clocks")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221108215625.30186-1-ansuelsmth@gmail.com
krait-cc use this driver for the secondary mux. Register it as a clk
provider to correctly use this clk in other drivers.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221108211734.3707-1-ansuelsmth@gmail.com
Downstream QCA 5.4 kernel defines networking resets which are not present
in the mainline kernel but are required for the networking drivers.
So, port the downstream resets and avoid using magic values for mask,
construct mask for resets which require multiple bits to be set/cleared.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221107132901.489240-3-robimarko@gmail.com
This patch adds the support for giving the complete bitmask
in reset structure and reset operation will use this bitmask
for all reset operations.
Currently, reset structure only takes a single bit for each reset
and then calculates the bitmask by using the BIT() macro.
However, this is not sufficient anymore for newer SoC-s like IPQ8074,
IPQ6018 and more, since their networking resets require multiple bits
to be asserted in order to properly reset the HW block completely.
So, in order to allow asserting multiple bits add "bitmask" field to
qcom_reset_map, and then use that bitmask value if its populated in the
driver, if its not populated, then we just default to existing behaviour
and calculate the bitmask on the fly.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221107132901.489240-1-robimarko@gmail.com
The two devices managed by lpasscorecc-sc7180.c each had their own
"struct dev_pm_ops". This is not needed. They are exactly the same and
the structure is "static const" so it can't possible change. combine
the two. This matches what's done for sc7280.
This should be a noop other than saving a few bytes.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221104064055.3.I90ba14a47683a484f26531a08f7b46ace7f0a8a9@changeid
The sc7180 lpass clock controller's pm_runtime usage wasn't broken
quite as spectacularly as the sc7280's pm_runtime usage, but it was
still broken. Putting some printouts in at boot showed me this (with
serial console enabled, which makes the prints slow and thus changes
timing):
[ 3.109951] DOUG: my_pm_clk_resume, usage=1
[ 3.114767] DOUG: my_pm_clk_resume, usage=1
[ 3.664443] DOUG: my_pm_clk_suspend, usage=0
[ 3.897566] DOUG: my_pm_clk_suspend, usage=0
[ 3.910137] DOUG: my_pm_clk_resume, usage=1
[ 3.923217] DOUG: my_pm_clk_resume, usage=0
[ 4.440116] DOUG: my_pm_clk_suspend, usage=-1
[ 4.444982] DOUG: my_pm_clk_suspend, usage=0
[ 14.170501] DOUG: my_pm_clk_resume, usage=1
[ 14.176245] DOUG: my_pm_clk_resume, usage=0
...or this w/out serial console:
[ 0.556139] DOUG: my_pm_clk_resume, usage=1
[ 0.556279] DOUG: my_pm_clk_resume, usage=1
[ 1.058422] DOUG: my_pm_clk_suspend, usage=-1
[ 1.058464] DOUG: my_pm_clk_suspend, usage=0
[ 1.186250] DOUG: my_pm_clk_resume, usage=1
[ 1.186292] DOUG: my_pm_clk_resume, usage=0
[ 1.731536] DOUG: my_pm_clk_suspend, usage=-1
[ 1.731557] DOUG: my_pm_clk_suspend, usage=0
[ 10.288910] DOUG: my_pm_clk_resume, usage=1
[ 10.289496] DOUG: my_pm_clk_resume, usage=0
It seems to be doing roughly the right sequence of calls, but just
like with sc7280 this is more by luck than anything. Having a usage of
-1 is just not OK.
Let's fix this like we did with sc7280.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Fixes: ce8c195e65 ("clk: qcom: lpasscc: Introduce pm autosuspend for SC7180")
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221104064055.2.I49b25b9bda9430fc7ea21e5a708ca5a0aced2798@changeid
The pm_runtime usage in lpass-sc7280 was broken in quite a few
ways. Specifically:
1. At the end of probe it called "put" twice. This is a no-no and will
end us up with a negative usage count. Even worse than calling
"put" twice, it never called "get" once. Thus after bootup it could
be seen that the runtime usage of the devices managed by this
driver was -2.
2. In some error cases it manually called pm_runtime_disable() even
though it had previously used devm_add_action_or_reset() to set
this up to be called automatically. This meant that in these error
cases we'd double-call pm_runtime_disable().
3. It forgot to call undo pm_runtime_use_autosuspend(), which can
sometimes have subtle problems (and the docs specifically mention
that you need to undo this function).
Overall the above seriously calls into question how this driver is
working. It seems like a combination of "it doesn't", "by luck", and
"because of the weirdness of runtime_pm". Specifically I put a
printout to the serial console every time the runtime suspend/resume
was called for the two devices created by this driver (I wrapped the
pm_clk calls). When I had serial console enabled, I found that the
calls got resumed at bootup (when the clk core probed and before our
double-put) and then never touched again. That's no good.
[ 0.829997] DOUG: my_pm_clk_resume, usage=1
[ 0.835487] DOUG: my_pm_clk_resume, usage=1
When I disabled serial console (speeding up boot), I got a different
pattern, which I guess (?) is better:
[ 0.089767] DOUG: my_pm_clk_resume, usage=1
[ 0.090507] DOUG: my_pm_clk_resume, usage=1
[ 0.151885] DOUG: my_pm_clk_suspend, usage=-2
[ 0.151914] DOUG: my_pm_clk_suspend, usage=-2
[ 1.825747] DOUG: my_pm_clk_resume, usage=-1
[ 1.825774] DOUG: my_pm_clk_resume, usage=-1
[ 1.888269] DOUG: my_pm_clk_suspend, usage=-2
[ 1.888282] DOUG: my_pm_clk_suspend, usage=-2
These different patterns have to do with the fact that the core PM
Runtime code really isn't designed to be robust to negative usage
counts and sometimes may happen to stumble upon a behavior that
happens to "work". For instance, you can see that
__pm_runtime_suspend() will treat any non-zero value (including
negative numbers) as if the device is in use.
In any case, let's fix the driver to be correct. We'll hold a
pm_runtime reference for the whole probe and then drop it (once!) at
the end. We'll get rid of manual pm_runtime_disable() calls in the
error handling. We'll also switch to devm_pm_runtime_enable(), which
magically handles undoing pm_runtime_use_autosuspend() as of commit
b4060db925 ("PM: runtime: Have devm_pm_runtime_enable() handle
pm_runtime_dont_use_autosuspend()").
While we're at this, let's also use devm_pm_clk_create() instead of
rolling it ourselves.
Note that the above changes make it obvious that
lpassaudio_create_pm_clks() was doing more than just creating
clocks. It was also setting up pm_runtime parameters. Let's rename it.
All of these problems were found by code inspection. I started looking
at this driver because it was involved in a deadlock that I reported a
while ago [1]. Though I bisected the deadlock to commit 1b771839de
("clk: qcom: gdsc: enable optional power domain support"), it was
never really clear why that patch affected it other than a luck of
timing changes. I'll also note that by fixing the timing (as done in
this change) we also seem to aboid the deadlock, which is a nice
benefit.
Also note that some of the fixes here are much the same type of stuff
that Dmitry did in commit 72cfc73f46 ("clk: qcom: use
devm_pm_runtime_enable and devm_pm_clk_create"), but I guess
lpassaudiocc-sc7280.c didn't exist then.
[1] https://lore.kernel.org/r/20220922154354.2486595-1-dianders@chromium.org
Fixes: a9dd26639d ("clk: qcom: lpass: Add support for LPASS clock controller for SC7280")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221104064055.1.I00a0e4564a25489e85328ec41636497775627564@changeid
@pll->rate_table has allocated memory by kmemdup(), if clk_hw_register()
fails, it should be freed, otherwise it will cause memory leak issue,
this patch fixes it.
Fixes: b4cbe606dc ("clk: visconti: Add support common clock driver and reset driver")
Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com>
Link: https://lore.kernel.org/r/20221122152353.204132-1-xiujianfeng@huawei.com
Acked-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
It seems like CLK_INFRA_ADC_FRC_CK always need to be enabled for
CLK_INFRA_ADC_26M_CK to work. Instead of adding this dependency to the
mtk-thermal and mt6577_auxadc drivers, add dependency to the clock
driver clk-mt7986-infracfg.c.
Fixes: ec97d23c8e ("clk: mediatek: add mt7986 clock support")
Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Link: https://lore.kernel.org/r/5e55012567da74870e1fb2edc2dc513b5821e523.1666801017.git.daniel@makrotopia.org
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Use mtk_clk_register_pllfhs() to enhance frequency hopping and
spread spectrum clocking control for MT8186.
Co-developed-by: Edward-JW Yang <edward-jw.yang@mediatek.com>
Signed-off-by: Edward-JW Yang <edward-jw.yang@mediatek.com>
Signed-off-by: Johnson Wang <johnson.wang@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20221121122957.21611-5-johnson.wang@mediatek.com
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
To implement frequency hopping and spread spectrum clocking
function, we introduce new clock type and APIs to handle
FHCTL hardware.
Co-developed-by: Edward-JW Yang <edward-jw.yang@mediatek.com>
Signed-off-by: Edward-JW Yang <edward-jw.yang@mediatek.com>
Signed-off-by: Johnson Wang <johnson.wang@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20221121122957.21611-4-johnson.wang@mediatek.com
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Export PLL operations and register functions for different type
of clock driver used.
Co-developed-by: Edward-JW Yang <edward-jw.yang@mediatek.com>
Signed-off-by: Edward-JW Yang <edward-jw.yang@mediatek.com>
Signed-off-by: Johnson Wang <johnson.wang@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20221121122957.21611-2-johnson.wang@mediatek.com
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Following the changes done to MT8183, MT8192, MT8195, register a
clock notifier for MT8186, allowing safe clockrate updates for the
MFG PLL.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20221024102307.33722-11-angelogioacchino.delregno@collabora.com
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Propagate the rate changes to MFG_BG3D's parent on MT8186 to allow
for proper GPU DVFS.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20221024102307.33722-10-angelogioacchino.delregno@collabora.com
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
The main/univpll clocks are used as clock sources for multiple
peripherals of different kind, some of which are critical (like AXIs);
a rate change on any of these two will produce a rate change on many
devices and that's likely to produce system instability if not done
correctly: this is the reason why we have (a lot of) "fixed factor"
main/univpll divider clocks, used by MUX clocks to provide different
rates based on PLL output dividers.
Following what was done on clk-mt8186-topckgen and also preventing the
same GPU DVFS issue, drop CLK_SET_RATE_PARENT from the aforementioned
clocks.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20221024102307.33722-9-angelogioacchino.delregno@collabora.com
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
The main/univpll clocks are used as clock sources for multiple
peripherals of different kind, some of which are critical (like AXIs);
a rate change on any of these two will produce a rate change on many
devices and that's likely to produce system instability if not done
correctly: this is the reason why we have (a lot of) "fixed factor"
main/univpll divider clocks, used by MUX clocks to provide different
rates based on PLL output dividers.
Following what was done on clk-mt8186-topckgen and also preventing the
same GPU DVFS issue, drop CLK_SET_RATE_PARENT from the aforementioned
clocks.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20221024102307.33722-8-angelogioacchino.delregno@collabora.com
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
The main/sys/univpll clocks are used as clock sources for multiple
peripherals of different kind, some of which are critical (like AXIs);
a rate change on any of these two will produce a rate change on many
devices and that's likely to produce system instability if not done
correctly: this is the reason why we have (a lot of) "fixed factor"
main/sys/univpll divider clocks, used by MUX clocks to provide
different rates based on PLL output dividers.
Following what was done on clk-mt8186-topckgen and also preventing the
same GPU DVFS issue, drop CLK_SET_RATE_PARENT from the aforementioned
clocks.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20221024102307.33722-7-angelogioacchino.delregno@collabora.com
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
The main/sys/univpll clocks are used as clock sources for multiple
peripherals of different kind, some of which are critical (like AXIs);
a rate change on any of these two will produce a rate change on many
devices and that's likely to produce system instability if not done
correctly: this is the reason why we have (a lot of) "fixed factor"
main/sys/univpll divider clocks, used by MUX clocks to provide
different rates based on PLL output dividers.
Following what was done on clk-mt8186-topckgen and also preventing the
same GPU DVFS issue, drop CLK_SET_RATE_PARENT from the aforementioned
clocks.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20221024102307.33722-6-angelogioacchino.delregno@collabora.com
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
The syspll and univpll clocks are used as clock sources for multiple
peripherals of different kind, some of which are critical (like AXIs);
a rate change on any of these two will produce a rate change on many
devices and that's likely to produce system instability if not done
correctly: this is the reason why we have (a lot of) "fixed factor"
sys/univpll divider clocks, used by MUX clocks to provide different
rates based on PLL output dividers.
Following what was done on clk-mt8186-topckgen and also solving the
same GPU DVFS issue, drop CLK_SET_RATE_PARENT from the aforementioned
clocks.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20221024102307.33722-5-angelogioacchino.delregno@collabora.com
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
There's no need to split each FACTOR entry in two lines, as each of
them does fit in one line just fine.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20221024102307.33722-4-angelogioacchino.delregno@collabora.com
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
The mainpll and univpll clocks are used as clock sources for multiple
peripherals of different kind, some of which are critical (like AXIs);
a rate change on any of these two will produce a rate change on many
devices and that's likely to produce system instability if not done
correctly: this is the reason why we have "fixed factor" clocks, used
by MUX clocks to provide different rates based on PLL output dividers.
Though, there's one fundamental issue that must be resolved somehow:
When performing GPU DVFS, we get a rate request that will try to change
the frequency of MAINPLL due to the CLK_TOP_MFG mux having clk26m,
mfgpll (the GPU dedicated PLL), mainpll_d3, mainpll_d5 (fixed factor
dividers) as possible parents.
In order to solve that, there are two ways:
1. Add new "fake" mainpll_d3_fixed, mainpll_d5_fixed clocks, clones
of mainpll_d3, mainpll_d5 clocks, for the only purpose of not
declaring CLK_SET_RATE_PARENT; or
2. Simply drop said flag from the original dividers.
After some careful validation, I cannot see anything calling a rate
change request during runtime for MAINPLL, nor for UNIVPLL (which would,
again, mean that we're reclocking lots of peripherals at once!), so it
is safe *and sane* to simply remove the CLK_SET_RATE_PARENT flag to all
of the main/univpll fixed factor divider clocks.
Besides, if for any (doubtful) reason main/univpll rate change will be
required in the future, it's still possible to call that on the PLL main
clocks, so we're still covered anyway.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20221024102307.33722-3-angelogioacchino.delregno@collabora.com
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Before this change, every mtk_fixed_factor clock forced clock flags to
CLK_SET_RATE_PARENT: while this is harmless in some cases, it may not
be desired in some others, especially when performing clock muxing on
a clock having multiple parents of which one is a dedicated PLL and the
others are not.
This is especially seen on the GPU clocks on some SoCs, where we are
muxing between multiple parents: a fixed clock (crystal), a programmable
GPU PLL and one or more dividers for the MAINPLL, used for a number of
devices; it happens that when a rate change is called for the GPU, the
clock framework will try to satisfy the rate request by using one of the
MAINPLL dividers, which have CLK_SET_RATE_PARENT and will set the rate
on MAINPLL itself - overclocking or underclocking many devices in the
system - and making it to lock up.
Logically, it should be harmless (and would only reduce possible bugs)
to change all of the univpll and mainpll related fixed factor clocks
to not declare the CLK_SET_RATE_PARENT by default but, on some SoCs,
this is also used for dividers of other PLLs for which a rate change
based on the divider may be desired, hence introduce a new FACTOR_FLAGS()
macro to use custom flags (or none) on selected fixed factor clocks.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20221024102307.33722-2-angelogioacchino.delregno@collabora.com
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
The imx_obtain_fixed_clk_hw name was wrong and misleading. Renaming it
to imx_get_clk_hw_by_name clarifies the purpose of the function, and
will allow it to be used not only for fixed rate clocks but also in
wider contexts.
No functional changes intended.
The replacements were made with the following command:
grep -rl 'imx_obtain_fixed_clk_hw' ./ | \
xargs sed -i 's/imx_obtain_fixed_clk_hw/imx_get_clk_hw_by_name/g'
Tested on a BSH SystemMaster (SMM) S2 board.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20221113180839.1625832-1-dario.binacchi@amarulasolutions.com
Unlike audio_pll1 and audio_pll2, there is no video_pll2. Further, the
name used in the RM is video_pll. So, let's rename "video_pll1" to
"video_pll" to be consistent with the RM and avoid misunderstandings.
The IMX8MN_VIDEO_PLL1* constants have not been removed to ensure
backward compatibility of the patch.
No functional changes intended.
Fixes: 96d6392b54 ("clk: imx: Add support for i.MX8MN clock driver")
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Acked-by: Marco Felsch <m.felsch@pengutronix.de>
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20221117113637.1978703-4-dario.binacchi@amarulasolutions.com
There is no occurrence of the hdmi oscillator in the reference manual
(document IMX8MNRM Rev 2, 07/2022). Further, if we consider the indexes
76-81 and 134 of the "Clock Root" table of chapter 5 of the RM, there is
no entry for the source select bits 101b, which is the setting referenced
by "osc_hdmi".
Fix by renaming "osc_hdmi" with "dummy", a clock which has already been
used for missing source select bits.
Tested on the BSH SystemMaster (SMM) S2 board.
Fixes: 96d6392b54 ("clk: imx: Add support for i.MX8MN clock driver")
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Acked-by: Marco Felsch <m.felsch@pengutronix.de>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20221117113637.1978703-3-dario.binacchi@amarulasolutions.com
The IMX8MN platform does not have any video processing unit (VPU), and
indeed in the reference manual (document IMX8MNRM Rev 2, 07/2022) there
is no occurrence of its pll. From an analysis of the code and the RM
itself, I think vpu pll is used instead of m7 alternate pll, probably
for copy and paste of code taken from modules of similar architectures.
As an example for all, if we consider the second row of the "Clock Root"
table of chapter 5 (Clocks and Power Management) of the RM:
Clock Root offset Source Select (CCM_TARGET_ROOTn[MUX])
... ... ...
ARM_M7_CLK_ROOT 0x8080 000 - 24M_REF_CLK
001 - SYSTEM_PLL2_DIV5
010 - SYSTEM_PLL2_DIV4
011 - M7_ALT_PLL_CLK
100 - SYSTEM_PLL1_CLK
101 - AUDIO_PLL1_CLK
110 - VIDEO_PLL_CLK
111 - SYSTEM_PLL3_CLK
... ... ...
but in the source code, the imx8mn_m7_sels clocks list contains vpu_pll
for the source select bits 011b.
So, let's rename "vpu_pll" to "m7_alt_pll" to be consistent with the RM.
The IMX8MN_VPU_* constants have not been removed to ensure backward
compatibility of the patch.
No functional changes intended.
Fixes: 96d6392b54 ("clk: imx: Add support for i.MX8MN clock driver")
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Acked-by: Marco Felsch <m.felsch@pengutronix.de>
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20221117113637.1978703-2-dario.binacchi@amarulasolutions.com
Because of the possible failure of devm_kzalloc(), name might be NULL and
will cause null pointer dereference later.
Therefore, it might be better to check it and directly return -ENOMEM.
Fixes: d39fb17276 ("clk: microchip: add PolarFire SoC fabric clock support")
Signed-off-by: Hui Tang <tanghui20@huawei.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
[claudiu.beznea: s/refrence/reference/, s/possilble/possible]
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/20221119054858.178629-1-tanghui20@huawei.com
-----BEGIN PGP SIGNATURE-----
iQFSBAABCAA8FiEEq68RxlopcLEwq+PEeb4+QwBBGIYFAmN6wAgeHHRvcnZhbGRz
QGxpbnV4LWZvdW5kYXRpb24ub3JnAAoJEHm+PkMAQRiG0EYH/3/RO90NbrFItraN
Lzr+d3VdbGjTu8xd1M+PRTmwh3zxLpB+Jwqr0T0A2gzL9B/D+AUPUJdrCVbv9DqS
FLJAVqoeV20dNBAHSffOOLPsgCZ+Eu+LzlNN7Iqde0e8cyZICFMNktitui84Xm/i
1NgFVgz9OZ6+aieYvUj3FrFq0p8GTIaC/oybDZrxYKcO8ZzKVMJ11swRw10wwq0g
qOOECvV3w7wlQ8upQZkzFxItKFc7EexZI6R4elXeGSJJ9Hlc092dv/zsKB9dwV+k
WcwkJrZRoezYXzgGBFxUcQtzi+ethjrPjuJuM1rYLUSIcfIW/0lkaSLgRoBu8D+I
1GfXkXs=
=gt6P
-----END PGP SIGNATURE-----
Backmerge tag 'v6.1-rc6' into drm-next
Linux 6.1-rc6
This is needed for drm-misc-next and tegra.
Signed-off-by: Dave Airlie <airlied@redhat.com>
If clk_register() fails, @pll->rate_table may have allocated memory by
kmemdup(), so it needs to be freed, otherwise will cause memory leak
issue, this patch fixes it.
Fixes: 90c5902540 ("clk: rockchip: add clock type for pll clocks and pll used on rk3066")
Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com>
Link: https://lore.kernel.org/r/20221123091201.199819-1-xiujianfeng@huawei.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The three UFS reference clocks, gcc_ufs_ref_clkref_clk for external
UFS devices, gcc_ufs_card_clkref_clk and gcc_ufs_1_card_clkref_clk for
two PHYs are all sourced from CXO.
Added parent_data for all three reference clocks described above to
reflect that all three clocks are sourced from CXO to have valid
frequency for the ref clock needed by UFS controller driver.
Fixes: d65d005f9a ("clk: qcom: add sc8280xp GCC driver")
Link: https://lore.kernel.org/lkml/Y2Tber39cHuOSR%2FW@hovoldconsulting.com/
Signed-off-by: Shazad Hussain <quic_shazhuss@quicinc.com>
Tested-by: Johan Hovold <johan+linaro@kernel.org>
Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
Tested-by: Andrew Halaney <ahalaney@redhat.com>
Reviewed-by: Andrew Halaney <ahalaney@redhat.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
Link: https://lore.kernel.org/r/20221115152956.21677-1-quic_shazhuss@quicinc.com
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
For the better maintenance regroup inclusions as follows:
- split CCF related headers in its own group
- order groups from generic to particular
- sort each group alphabetically
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20221122130732.48537-3-andriy.shevchenko@linux.intel.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
There is no SPEAr600 device named "ssp-pl022.x". Instead, the description
of the SSP (Synchronous Serial Port) was recently added to the Device Tree,
and the device name is "xxx.spi", so we should associate the SSP gateable
clock to these device names.
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://lore.kernel.org/r/20221115135814.214388-3-kory.maincent@bootlin.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
There is no SPEAr600 device named "clcd". Instead, the description of the
CLCD (color liquid crystal display controller) name is "fc200000.clcd", so
we should associate the CLCD gateable clock to this device name.
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Link: https://lore.kernel.org/r/20221115135814.214388-2-kory.maincent@bootlin.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
The `parent_names' variable was freed also in case of kzalloc() error.
Instead of modifying the code to perform a proper memory release, I
decided to fix the bug by not allocating memory.
Since only one parent name is referenced, it is not necessary to
allocate this variable at runtime and therefore you can avoid calling
the kzalloc() function. This simplifies the code (even calls to kfree
can be removed) and improves the performance of the routine.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/20221113181147.1626585-2-dario.binacchi@amarulasolutions.com
Tested-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
The ti_clk_register() and ti_clk_register_omap_hw() functions are always
called with the parameter of type "struct device" set to NULL, since the
functions from which they are called always have a parameter of type
"struct device_node". Replacing "struct device" type parameter with
"struct device_node" will allow you to register a TI clock to the common
clock framework by taking advantage of the facilities provided by the
"struct device_node" type. Further, adding the "of_" prefix to the name
of these functions explicitly binds them to the "struct device_node"
type.
The patch has been tested on a Beaglebone board.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Reviewed-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20221113181147.1626585-1-dario.binacchi@amarulasolutions.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
It contains fixes for AT91 SoCs as follows:
- fix the clock ID for USB device port on RM9200 SoCs; along with it the
device tree references to this clocks were fixed in this patch to ease the
backporting and to avoid USB driver probe failure.
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQTsZ8eserC1pmhwqDmejrg/N2X7/QUCY3eAPAAKCRCejrg/N2X7
/V1SAP9Rea8/sqyEUYCI9t8EdG70hSHNGCV2tC+0FvozGe7tnQD9Ew+04JCBnGfk
YejYowKjiVdXiAIyEyt7UgxRAX6cVQ4=
=24dW
-----END PGP SIGNATURE-----
Merge tag 'clk-microchip-fixes-6.1' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into clk-fixes
Pull Microchip clk driver fixes from Claudiu Beznea:
- fix the clock ID for USB device port on AT91 RM9200 SoCs; along with it the
device tree references to this clocks were fixed in this patch to ease the
backporting and to avoid USB driver probe failure.
* tag 'clk-microchip-fixes-6.1' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux:
ARM: at91: rm9200: fix usb device clock id
1. Fix calling of_device_get_match_data() on wrong device (parent's) in
Exynos clock out driver.
2. Correct clock name in bindings of ExynosAutov9 clocks.
3. Correct parents of div4 clock on Exynos7885.
-----BEGIN PGP SIGNATURE-----
iQJEBAABCgAuFiEE3dJiKD0RGyM7briowTdm5oaLg9cFAmN0rG4QHGtyemtAa2Vy
bmVsLm9yZwAKCRDBN2bmhouD18jRD/9Jy7jURI21QFZ2XBtUvC3VYiYkgNEmEf01
/hM8Nlt5LNpbXzwmHqIMq7BtaoX2ub5STufmMrJ/PyM58K3+8gnBK0xrKebJ6mS0
6IzqMfqinYKvF067Hbf5Gq7O0U6yBPiqWdOKpIQwhDq4Z8PXueDAxBuex/MJThlt
wuePxpyrZLsi5qpGNxp4pjhKEg2UeamcctbMKcqM4aaoNoNfbblcbwtR1vfFev5F
Rs7KI2hbQ9Qr1vb8Q37FceCXtPxHDHkEV9vC4bejc1Gr+6m3EwkQSanliLUWi1f1
E69SzPGNcenMuX2IETHmmck3SZpfpNm+eVkRM/czOJo4FM8GzoK+6DbCdMX1R4/g
bkb3c3u1OiAtxLgya+4Zgwz3OcApvafiSZ0PgnMhbVbIKJR7nAM6nF00Hnwhfp9E
qZE1+vgVjDXDpJxrKdEf4CTIYRgNaZ8PwyJaOeYW2JxB4oJm87M291zD34yCbASR
Le0pR/YG8Cu/rMj3xuB9u8cA3vcAjG2nTePaw4sAbNwQWpBV/Gwuqz3xqWGwQFGH
7UOLT0PSELKkkK+c1MM30v0xyPpqnvixFFjEF3QtBbzv4+4k8zHHp/UF8CUBTMuV
RQ/a9TJOC9S97xkPV4R4aOGdk4sGW3TRUPXuWlzr3XWjqvUolA1CBjSgGvoaemE6
v7h3P8Ssrw==
=ObqP
-----END PGP SIGNATURE-----
Merge tag 'samsung-clk-6.2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into clk-fixes
Pull Samsung SoC clk driver fixes from Krzysztof Kozlowski:
- Fix calling of_device_get_match_data() on wrong device (parent's) in
Exynos clock out driver
- Correct clock name in bindings of ExynosAutov9 clocks
- Correct parents of div4 clock on Exynos7885
* tag 'samsung-clk-6.2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux:
clk: samsung: Revert "clk: samsung: exynos-clkout: Use of_device_get_match_data()"
dt-bindings: clock: exynosautov9: fix reference to CMU_FSYS1
clk: samsung: exynos7885: Correct "div4" clock parents
According to the RM, the CCGR101 is shared for the following root clocks:
- AUDIO_AHB_CLK_ROOT
- AUDIO_AXI_CLK_ROOT
- SAI1_CLK_ROOT
- SAI2_CLK_ROOT
- SAI3_CLK_ROOT
- SAI5_CLK_ROOT
- SAI6_CLK_ROOT
- SAI7_CLK_ROOT
- PDM_CLK_ROOT
IMX8MP_CLK_AUDIO_ROOT is same as AUDIO_AHB_CLK_ROOT
which can avoid break any users.
Signed-off-by: Abel Vesa <abel.vesa@nxp.com>
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/1667811007-19222-3-git-send-email-shengjiu.wang@nxp.com
The PLL146x is used to implement SYS_PLL3 on i.MX8MP and can be used
to drive UARTn_ROOT clock. By setting the PLL3 to 320 MHz or 640 MHz,
the PLL3 output can be divided down to supply UARTn_ROOT clock with
precise 64 MHz, which divided down further by 16x oversampling factor
used by the i.MX UART core yields 4 Mbdps baud base for the UART IP.
This is useful e.g. for BCM bluetooth chips, which can operate up to
4 Mbdps.
Add 320 MHz and 640 MHz entries so the PLL can be configured accordingly.
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20221031204838.195292-1-marex@denx.de
Keep sys ctr clock always on to make sure its register
can be accessed for cpuidle.
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20221028095211.2598312-7-peng.fan@oss.nxp.com
During Linux System suspend/resume stress test after System Sleep
enabled, system will stuck sometimes. It is because NICMIX is powered
down, which HSIOMIX(always on) is not powered down. When NICMIX
powering down, HSIOMIX will get a hardware handshake, without HSIO ROOT clk,
the handshake will lose. Then after NICMIX power on when system resume,
the access to HSIOMIX through NICMIX would be broken. So keep HSIO ROOT
always on.
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20221028095211.2598312-6-peng.fan@oss.nxp.com
Per Reference Mannual System Clocks Table,
LPIT1 and TPM1 sources from bus_aon_root
LPIT2 and TPM3 sources from bus_wakeup_root
So update driver to reflect that.
Reviewed-by: Jacky Bai <ping.bai@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20221028095211.2598312-5-peng.fan@oss.nxp.com
Per update Reference Mannual, correct the enet clock parent to
wakeup_axi_root.
Fixes: 24defbe194 ("clk: imx: add i.MX93 clk")
Reviewed-by: Ye Li <ye.li@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20221028095211.2598312-3-peng.fan@oss.nxp.com
The anatop base is not unmapped during error handling path, fix it.
Fixes: 24defbe194 ("clk: imx: add i.MX93 clk")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20221028095211.2598312-2-peng.fan@oss.nxp.com
32K usb suspend clock gate is shared with usb_root_clk, this
shared clock gate was initially defined only for usb suspend
clock, usb suspend clk is kept on while system is active or
system sleep with usb wakeup enabled, so usb root clock is
fine with this situation; with the commit cf7f3f4fa9
("clk: imx8mp: fix usb_root_clk parent"), this clock gate is
changed to be for usb root clock, but usb root clock will
be off while usb is suspended, so usb suspend clock will be
gated too, this cause some usb functionalities will not work,
so define this clock to be a shared clock gate to conform with
the real HW status.
Fixes: 9c140d9926 ("clk: imx: Add support for i.MX8MP clock driver")
Cc: stable@vger.kernel.org # v5.19+
Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Signed-off-by: Li Jun <jun.li@nxp.com>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/1664549663-20364-2-git-send-email-jun.li@nxp.com
Correct IMX93_CLK_FLEXSPI1_GATE CCGR setting. Otherwise the flexspi
always can't be assigned to a parent clock when dump the clock tree.
Fixes: 24defbe194 ("clk: imx: add i.MX93 clk")
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/1666589199-1199-1-git-send-email-haibo.chen@nxp.com
Support BPMP_CLK_STATE_CHANGE_DENIED by not populating state changing
operations when the flag is set.
Support BPMP_CLK_RATE_PARENT_CHANGE_DENIED by not populating rate or
parent changing operations when the flag is set.
Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
Acked-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
For some reason the mod clock for the Allwinner F1C100s CIR (infrared
receiver) peripheral was not modeled in the CCU driver.
Add the clock description to the list, and wire it up in the clock list.
By assigning a new clock ID at the end, it extends the number of clocks.
This allows to use the CIR peripheral on any F1C100s series board.
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://lore.kernel.org/r/20221107005433.11079-5-andre.przywara@arm.com
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Rename the header guard of ccu-sun8i-v3s.h from _CCU_SUN8I_H3_H_ to
_CCU_SUN8I_V3S_H_ what corresponding with the file name.
Fixes: d0f11d14b0 ("clk: sunxi-ng: add support for V3s CCU")
Signed-off-by: Wei Li <liwei391@huawei.com>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://lore.kernel.org/r/20221108094335.3597008-1-liwei391@huawei.com
Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com>
The RSwitch2 and EtherTSN-IF clocks were accidentally mixed up.
While at it, rename them to better match the (future) documentation.
Fixes: a3b4137a4d ("clk: renesas: r8a779f0: Add Ethernet Switch clocks")
Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/99b8b41bd2c5043c9e457862ef4bc144869eca58.1668501212.git.geert+renesas@glider.be
Add support for the display clock controller found on SM6375.
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221115155808.10899-2-konrad.dybcio@linaro.org
Add full clock controller support RK3588.
[rebase, integrate fixes from Wyon and Finley, add missing frequencies
to PLL lookup table, update commit message, add GATE_LINK clocks which
downstream handles in its own driver with one DT node per clock]
Signed-off-by: Wyon Bi <bivvy.bi@rock-chips.com>
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://lore.kernel.org/r/20221018151407.63395-10-sebastian.reichel@collabora.com
[dropped module stuff after talking to Sebastian]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
of_device_get_match_data() function should not be used on the device
other than the one matched to the given driver, because it always returns
the match_data of the matched driver. In case of exynos-clkout driver,
the code matched the OF IDs on the PARENT device, so replacing it with
of_device_get_match_data() broke the driver.
This reverts commit 777aaf3d1d.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Fixes: 777aaf3d1d ("clk: samsung: exynos-clkout: Use of_device_get_match_data()")
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20221108213718.32076-1-m.szyprowski@samsung.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
rockchip_clk_add_lookup is only called from within the file,
so it can be made static. The additional checks are removed
with the following reasoning:
1. The data structure is initialized by rockchip_clk_init(),
which is called by all rockchip platforms before the clocks
are registered. Not doing so would result in an incomplete
clock tree at the moment, which is a fatal error. In other
parts of the kernel these kind of checks are usually
omitted, so this was done here. The alternative is adding
a pr_err to inform the kernel programmer adding a new platform
about his incorrect code. Apart from that we are also not
checking if the clock id is within the array boundings.
2. While not used so far by any rockchip platform, 0 is a valid
clock identifier. To align rockchip closer to other ARM
platforms we will start using it with rk3588.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://lore.kernel.org/r/20221018151407.63395-8-sebastian.reichel@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
In order to improve the main frequency of CPU, the clock path of CPU is
simplified as follows:
|--\
| \ |--\
--apll--|\ | \ | \
| |--apll_core--| \ | \
--24M---|/ |mux1 |--[gate]--|mux2|---clk_core
| / | /
--gpll--|\ | / |------| /
| |--gpll_core--| / | |--/
--24M---|/ |--/ |
|
-------apll_directly--------------|
When the CPU requests high frequency, we want to use MUX2 select the
"apll_directly".
At low frequencies use MUX1 to select “apll_core" and then MUX2 to
select "apll_core_gate".
However, in this way, the CPU frequency conversion needs to be
in the following order:
1. MUX2 select to "apll_core_gate", MUX1 select "gpll_core"
2. Apll sets slow_mode, sets APLL parameters, locks APLL, and then APLL
sets normal_mode
3. MUX1 select "apll_core", MUX2 select "apll_directly"
So add pre_mux and post_mux options to cover this special requirements.
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
[rebase]
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://lore.kernel.org/r/20221018151407.63395-7-sebastian.reichel@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add RK3588 PLL support fully relying on lookup tables like
the other upstream supported rockchip platforms.
Signed-off-by: Elaine Zhang <zhangqing@rock-chips.com>
[rebase and modify code to avoid PLL parameter calculation]
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://lore.kernel.org/r/20221018151407.63395-6-sebastian.reichel@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Qualcomm SC8280XP platform has two display clock controller
instances, add support for these. Duplication between the two
implementations is reduced by reusing any constant data between the two
sets of clock data.
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Tested-by: Steev Klimaszewski <steev@kali.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20220926203800.16771-3-quic_bjorande@quicinc.com
The PCIe PLL locking may be unreliable under some circumstance, such as
high or low temperature. If the PLL fails to lock, reset it a try again.
This helps on the S905X4
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
[commit message amend]
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/cc80cda0-4dda-2e3e-3fc8-afa97717479b@gmail.com
Dmitry Baryshkov