IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The current core while setting the min and max rate properly in the
clk_request structure will not make sure that the requested rate is
within these boundaries, leaving it to each and every driver to make
sure it is.
It's not clear if this was on purpose or not, but this introduces some
inconsistencies within the API.
For example, a user setting a range and then calling clk_round_rate()
with a value outside of that range will get the same value back
(ignoring any driver adjustements), effectively ignoring the range that
was just set.
Another one, arguably worse, is that it also makes clk_round_rate() and
clk_set_rate() behave differently if there's a range and the rate being
used for both is outside that range. As we have seen, the rate will be
returned unchanged by clk_round_rate(), but clk_set_rate() will error
out returning -EINVAL.
Let's make sure the framework will always clamp the rate to the current
range found on the clock, which will fix both these inconsistencies.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220225143534.405820-5-maxime@cerno.tech
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
If we were to have two users of the same clock, doing something like:
clk_set_rate_range(user1, 1000, 2000);
clk_set_rate_range(user2, 3000, 4000);
The second call would fail with -EINVAL, preventing from getting in a
situation where we end up with impossible limits.
However, this is never explicitly checked against and enforced, and
works by relying on an undocumented behaviour of clk_set_rate().
Indeed, on the first clk_set_rate_range will make sure the current clock
rate is within the new range, so it will be between 1000 and 2000Hz. On
the second clk_set_rate_range(), it will consider (rightfully), that our
current clock is outside of the 3000-4000Hz range, and will call
clk_core_set_rate_nolock() to set it to 3000Hz.
clk_core_set_rate_nolock() will then call clk_calc_new_rates() that will
eventually check that our rate 3000Hz rate is outside the min 3000Hz max
2000Hz range, will bail out, the error will propagate and we'll
eventually return -EINVAL.
This solely relies on the fact that clk_calc_new_rates(), and in
particular clk_core_determine_round_nolock(), won't modify the new rate
allowing the error to be reported. That assumption won't be true for all
drivers, and most importantly we'll break that assumption in a later
patch.
It can also be argued that we shouldn't even reach the point where we're
calling clk_core_set_rate_nolock().
Let's make an explicit check for disjoints range before we're doing
anything.
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220225143534.405820-4-maxime@cerno.tech
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Let's test various parts of the rate-related clock API with the kunit
testing framework.
Cc: kunit-dev@googlegroups.com
Tested-by: Daniel Latypov <dlatypov@google.com>
Suggested-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220225143534.405820-3-maxime@cerno.tech
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Any registered clk_core structure can have a NULL pointer in its dev
field. While never actually documented, this is evidenced by the wide
usage of clk_register and clk_hw_register with a NULL device pointer,
and the fact that the core of_clk_hw_register() function also passes a
NULL device pointer.
A call to clk_hw_get_clk() on a clk_hw struct whose clk_core is in that
case will result in a NULL pointer derefence when it calls dev_name() on
that NULL device pointer.
Add a test for this case and use NULL as the dev_id if the device
pointer is NULL.
Fixes: 30d6f8c15d2c ("clk: add api to get clk consumer from clk_hw")
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220225143534.405820-2-maxime@cerno.tech
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
For spdx
Space instead of tab before spdx tag
Removed repeated works
the, to, two
Replacements
much much to a much
'to to' to 'to do'
aready to already
Comunications to Communications
freqency to frequency
Signed-off-by: Tom Rix <trix@redhat.com>
Link: https://lore.kernel.org/r/20220222195153.3817625-1-trix@redhat.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
The sentinel elements of various tables in drivers/clk/actions can be a
bit hard to recognize. Make them easier to see by changing the style
from { 0, 0 } to { /* sentinel */ }.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Link: https://lore.kernel.org/r/20220218000922.134857-6-j.neuschaefer@gmx.net
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
In order that the end of a clk_div_table can be detected, it must be
terminated with a sentinel element (.div = 0).
Fixes: 631c53478973d ("clk: Add CLPS711X clk driver")
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Link: https://lore.kernel.org/r/20220218000922.134857-5-j.neuschaefer@gmx.net
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
In order that the end of a clk_div_table can be detected, it must be
terminated with a sentinel element (.div = 0).
Fixes: 6c81966107dc0 ("clk: hisilicon: Add clock driver for hi3559A SoC")
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Link: https://lore.kernel.org/r/20220218000922.134857-4-j.neuschaefer@gmx.net
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
In order that the end of a clk_div_table can be detected, it must be
terminated with a sentinel element (.div = 0).
Fixes: b4626a7f4892 ("CLK: Add Loongson1C clock support")
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Link: https://lore.kernel.org/r/20220218000922.134857-3-j.neuschaefer@gmx.net
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
In order that the end of a clk_div_table can be detected, it must be
terminated with a sentinel element (.div = 0).
In owl-s900.s, the { 0, 8 } element was probably meant to be just that,
so this patch changes { 0, 8 } to { 0, 0 }.
Fixes: d47317ca4ade1 ("clk: actions: Add S700 SoC clock support")
Fixes: d85d20053e195 ("clk: actions: Add S900 SoC clock support")
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Link: https://lore.kernel.org/r/20220218000922.134857-2-j.neuschaefer@gmx.net
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Let's update all the TI component clocks to use ti_dt_clk_name() instead
of devicetree node name if available.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20220204071449.16762-9-tony@atomide.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Let's update the TI pll and clockdomain clocks to use ti_dt_clk_name()
instead of devicetree node name if available.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20220204071449.16762-8-tony@atomide.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Let's create the clock alias based on the clock-output-names property if
available. Also the component clock drivers can use ti_dt_clk_name() in
the following patches.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20220204071449.16762-7-tony@atomide.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Let's add ti_find_clock_provider() so we can use clock-output-names
to name the clock provider instead of relying on non-standard devicetree
node names.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20220204071449.16762-5-tony@atomide.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
If no reg property is specified for a TI clock, let's try to use the
parent clock node IO address. This way we can avoid duplicate devicetree
reg properties that cause warnings for unique_unit_address.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20220204071449.16762-4-tony@atomide.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
In preparation for making use of the clock-output-names, we want to
keep node around in ti_dt_clocks_register().
This change should not needed as a fix currently.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20220204071449.16762-3-tony@atomide.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
We can constify clkctrl_name in preparation for making use of the
clock-output-names property.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20220204071449.16762-2-tony@atomide.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Unlike the system clocks there are audio clocks that combine both
multiplexer/divider and gate/multiplexer/divider, so add support for
that.
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Link: https://lore.kernel.org/r/20220126173953.1016706-7-kernel@esmil.dk
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
The JH7100 has additional audio and video clocks at different memory
ranges, but they use the same register layout. Add a header and export
the starfive_jh7100_clk_ops function so the clock implementation can be
reused by drivers handling these clocks.
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Link: https://lore.kernel.org/r/20220126173953.1016706-6-kernel@esmil.dk
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
It turns out the audio_div clock is a fractional divider where the
lowest byte of the ctrl register is the integer part of the divider and
the 2nd byte is the number of 100th added to the divider.
The children of this clock is used by the audio peripherals for their
sample rate clock, so round to the closest possible rate rather than
always rounding down like regular dividers.
Fixes: 4210be668a09 ("clk: starfive: Add JH7100 clock generator driver")
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Link: https://lore.kernel.org/r/20220126173953.1016706-3-kernel@esmil.dk
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
The problem is best illustrated by an example. Suppose a consumer wants
a 4MHz clock rate from a divider with a 10MHz parent. It would then
call
clk_round_rate(clk, 4000000)
which would call into our determine_rate() callback that correctly
rounds up and finds that a divisor of 3 gives the highest possible
frequency below the requested 4MHz and returns 10000000 / 3 = 3333333Hz.
However the consumer would then call
clk_set_rate(clk, 3333333)
but since 3333333 doesn't divide 10000000 evenly our set_rate() callback
would again round the divisor up and set it to 4 which results in an
unnecessarily low rate of 2.5MHz.
Fix it by using DIV_ROUND_CLOSEST in the set_rate() callback.
Fixes: 4210be668a09 ("clk: starfive: Add JH7100 clock generator driver")
Signed-off-by: Emil Renner Berthing <kernel@esmil.dk>
Link: https://lore.kernel.org/r/20220126173953.1016706-2-kernel@esmil.dk
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
There are two identical assignments of pll->base to the same value,
the second assignment is redundant and can be removed.
Cleans up cppcheck warning:
drivers/clk/imx/clk-sscg-pll.c:528:12: style: Variable 'pll->base' is
reassigned a value before the old one has been used. [redundantAssignment]
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Link: https://lore.kernel.org/r/20220303090508.1125175-1-colin.i.king@gmail.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Add support for the display clock controller found on SM6125
based devices. This allows display drivers to probe and
control their clocks.
Signed-off-by: Martin Botka <martin.botka@somainline.org>
Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220303131812.302302-4-marijn.suijten@somainline.org
In order to keep at least the list of `CONFIG_SM_` drivers sorted
alphabetically, SDX_GCC_65 should have been moved one line up. This in
turn makes it easier and cleaner to add the followup SM_DISPCC_6125
driver in the right place, right before SM_DISPCC_8250.
Fixes: d79afa201328 ("clk: qcom: Add SDX65 GCC support")
Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220303131812.302302-2-marijn.suijten@somainline.org
Support the new numerator and denominator for pixel clock on SM8350 and
support rgb101010, RGB888 use cases on SM8450.
Fixes: 99cbd064b059f ("clk: qcom: Support display RCG clocks")
Signed-off-by: Taniya Das <tdas@codeaurora.org>
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220227175536.3131-2-tdas@codeaurora.org
The display pixel clock has a requirement on certain newer platforms to
support M/N as (2/3) and the final D value calculated results in
underflow errors.
As the current implementation does not check for D value is within
the accepted range for a given M & N value. Update the logic to
calculate the final D value based on the range.
Fixes: 99cbd064b059f ("clk: qcom: Support display RCG clocks")
Signed-off-by: Taniya Das <tdas@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220227175536.3131-1-tdas@codeaurora.org
Add missing RPM-provided clocks on msm8998 and reorder the definitions
where needed.
Tested-by: Jami Kettunen <jami.kettunen@somainline.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Tested-by: Caleb Connolly <caleb@connolly.tech>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220226214126.21209-3-konrad.dybcio@somainline.org
XO and MSS_CFG were omitted when first adding the clocks for these SoCs.
Add them, and while at it, move the XO clock to the top of the definition
list, as ideally everyone should start using it sooner or later..
Fixes: b4297844995f ("clk: qcom: smd: Add support for MSM8992/4 rpm clocks")
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220226214126.21209-2-konrad.dybcio@somainline.org
Add additional freq supported for the sdc table. The ops are changed to
the floor_ops to handle a freq request of 52kHz where we need to provide
a freq of 51.2kHz instead for stability reason.
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Tested-by: Jonathan McDowell <noodles@earth.li>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220226135235.10051-11-ansuelsmth@gmail.com
Add clk_rcg_floor_ops for clock that can't provide a stable freq and
require to use a floor freq to provide the requested frequency.
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Tested-by: Jonathan McDowell <noodles@earth.li>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220226135235.10051-10-ansuelsmth@gmail.com
Some clocks are used by other devices present on the SoC. For example
the gsbi4_h_clk is used by RPM and is if disabled cause the RPM to
reject any regulator change command. These clock should never be
disabled.
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
Tested-by: Jonathan McDowell <noodles@earth.li>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220226135235.10051-9-ansuelsmth@gmail.com
Ipq8065 SoC (an evolution of ipq8064 SoC) contains nss cores that can be
clocked to 800MHz. Add these missing freq to the gcc driver.
Set the freq_tbl for the ubi32_cores to the correct values based on the
machine compatible.
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Tested-by: Jonathan McDowell <noodles@earth.li>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220226135235.10051-8-ansuelsmth@gmail.com
Use ARRAY_SIZE for num_parents instead of hardcoding the value.
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Tested-by: Jonathan McDowell <noodles@earth.li>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220226135235.10051-7-ansuelsmth@gmail.com
Convert parent_names to parent_data to modernize the driver.
Where possible use parent_hws directly.
Signed-off-by: Ansuel Smith <ansuelsmth@gmail.com>
Tested-by: Jonathan McDowell <noodles@earth.li>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220226135235.10051-6-ansuelsmth@gmail.com
Commit facb87ad7560 ("clk: at91: sama7g5: remove prescaler part of master
clock") removed the master clock's prescaler from clock tree of SAMA7G5
as it has been discovered that there is a hardware bug when trying to
change it at run-time (bug is described in description of
commit facb87ad7560 ("clk: at91: sama7g5: remove prescaler part of master
clock")). This was previously changed at CPUFreq driver request. Thus, with
commit facb87ad7560 ("clk: at91: sama7g5: remove prescaler part of master
clock") there is no need of code that handles run-time changes of master
clock's prescaler, thus remove this code.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20220203110202.18329-1-claudiu.beznea@microchip.com
Audio PLL can be used as parent by the GCLKs of PDMCs.
Fixes: cb783bbbcf54 ("clk: at91: sama7g5: add clock support for sama7g5")
Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20220304182616.1920392-1-codrin.ciubotariu@microchip.com
