08 Jan, 2020

1 commit

  • After commit fc0c209c147f ("clk: Allow parents to be specified without
    string names") we can use DT or direct clk_hw pointers to specify
    parents. Create a generic function that shouldn't be used very often to
    encode the multitude of ways of registering a divider clk with different
    parent information. Then add a bunch of wrapper macros that only pass
    down what needs to be passed down to the generic function to support
    this with less arguments.

    Cc: Manivannan Sadhasivam
    Signed-off-by: Stephen Boyd
    Link: https://lkml.kernel.org/r/20190830150923.259497-13-sboyd@kernel.org
    [sboyd@kernel.org: Export __clk_hw_register_divider]

    Stephen Boyd
     

23 Nov, 2019

1 commit

  • The clk_init_data struct needs to be initialized to zero for the new
    parent_map implementation to work correctly. Otherwise, the member which
    is available first will get processed.

    Signed-off-by: Manivannan Sadhasivam
    Link: https://lkml.kernel.org/r/20191115162901.17456-2-manivannan.sadhasivam@linaro.org
    Signed-off-by: Stephen Boyd

    Manivannan Sadhasivam
     

08 May, 2019

1 commit

  • * clk-ti:
    clk: Remove CLK_IS_BASIC clk flag
    clk: ti: dra7: disable the RNG and TIMER12 clkctrl clocks on HS devices
    clk: ti: dra7x: prevent non-existing clkctrl clocks from registering
    ARM: omap2+: hwmod: drop CLK_IS_BASIC flag usage
    clk: ti: export the omap2_clk_is_hw_omap call

    Stephen Boyd
     

27 Apr, 2019

1 commit

  • This flag was historically used to indicate that a clk is a "basic" type
    of clk like a mux, divider, gate, etc. This never turned out to be very
    useful though because it was hard to cleanly split "basic" clks from
    other clks in a system. This one flag was a way for type introspection
    and it just didn't scale. If anything, it was used by the TI clk driver
    to indicate that a clk_hw wasn't contained in the SoC specific clk
    structure. We can get rid of this define now that TI is finding those
    clks a different way.

    Cc: Tero Kristo
    Cc: Ralf Baechle
    Cc: Paul Burton
    Cc: James Hogan
    Cc:
    Cc: Thierry Reding
    Cc: Kevin Hilman
    Cc:
    Cc:
    Acked-by: Thierry Reding
    Signed-off-by: Stephen Boyd

    Stephen Boyd
     

24 Apr, 2019

2 commits


12 Dec, 2018

1 commit


13 Mar, 2018

2 commits

  • When a divider clock has CLK_DIVIDER_READ_ONLY set, it means that the
    register shall be left un-touched, but it does not mean the clock
    should stop rate propagation if CLK_SET_RATE_PARENT is set

    This is properly handled in qcom clk-regmap-divider but it was not in
    the generic divider

    To fix this situation, introduce a new helper function
    divider_ro_round_rate, on the same model as divider_round_rate.

    Fixes: e6d5e7d90be9 ("clk-divider: Fix READ_ONLY when divider > 1")
    Signed-off-by: Jerome Brunet
    Tested-By: David Lechner
    Signed-off-by: Michael Turquette
    Signed-off-by: Stephen Boyd

    Jerome Brunet
     
  • Export clk_div_mask() in clk-provider header so every clock providers
    derived from the generic clock divider may share the definition instead
    of redefining it.

    Signed-off-by: Jerome Brunet
    Signed-off-by: Michael Turquette
    Signed-off-by: Stephen Boyd

    Jerome Brunet
     

29 Dec, 2017

1 commit

  • divider_recalc_rate() is an helper function used by clock divider of
    different types, so the structure containing the 'hw' pointer is not
    always a 'struct clk_divider'

    At the following line:
    > div = _get_div(table, val, flags, divider->width);

    in several cases, the value of 'divider->width' is garbage as the actual
    structure behind this memory is not a 'struct clk_divider'

    Fortunately, this width value is used by _get_val() only when
    CLK_DIVIDER_MAX_AT_ZERO flag is set. This has never been the case so
    far when the structure is not a 'struct clk_divider'. This is probably
    why we did not notice this bug before

    Fixes: afe76c8fd030 ("clk: allow a clk divider with max divisor when zero")
    Signed-off-by: Jerome Brunet
    Acked-by: Alexandre Belloni
    Acked-by: Sylvain Lemieux
    Signed-off-by: Stephen Boyd

    Jerome Brunet
     

01 Sep, 2017

1 commit

  • Add a check for error returned by divider value calculation to avoid
    writing error code into hw register.

    Signed-off-by: Alex Frid
    Reviewed-by: Peter De Schrijver
    Reviewed-by: Jon Mayo
    Fixes: bca9690b9426 ("clk: divider: Make generic for usage elsewhere")
    Signed-off-by: Stephen Boyd

    Alex Frid
     

07 Jun, 2017

1 commit

  • So far, divider_round_rate only considers the parent clock returned by
    clk_hw_get_parent.

    This works fine on clocks that have a single parents, this doesn't work on
    muxes, since we will only consider the first parent, while other parents
    may totally be able to provide a better combination.

    Clocks in that case cannot use divider_round_rate, so would have to come up
    with a very similar logic to work around it. Instead of having to do
    something like this, and duplicate that logic everywhere, create a
    divider_round_rate parent to allow caller to give an additional parameter
    for the parent clock to consider.

    Reviewed-by: Chen-Yu Tsai
    Signed-off-by: Maxime Ripard
    Acked-by: Stephen Boyd
    Signed-off-by: Chen-Yu Tsai

    Maxime Ripard
     

13 Aug, 2016

1 commit


20 Apr, 2016

1 commit


30 Jan, 2016

3 commits

  • Because _next_div() returns a valid divider, there is no need to
    consult _is_valid_div() for the validity of the divider in every
    iteration.

    Signed-off-by: Masahiro Yamada
    Signed-off-by: Stephen Boyd

    Masahiro Yamada
     
  • to_clk_*(_hw) macros have been repeatedly defined in many places.
    This patch moves all the to_clk_*(_hw) definitions in the common
    clock framework to public header clk-provider.h, and drop the local
    definitions.

    Signed-off-by: Geliang Tang
    Signed-off-by: Stephen Boyd

    Geliang Tang
     
  • Commit e6d5e7d90be9 ("clk-divider: Fix READ_ONLY when divider > 1") removed
    the special ops struct for read-only clocks and instead opted to handle
    them inside the regular ops.

    On the rk3368 this results in breakage as aclkm now gets set a value.
    While it is the same divider value, the A53 core still doesn't like it,
    which can result in the cpu ending up in a hang.
    The reason being that "ACLKENMasserts one clock cycle before the rising
    edge of ACLKM" and the clock should only be touched when STANDBYWFIL2
    is asserted.

    To fix this, reintroduce the read-only ops but do include the round_rate
    callback. That way no writes that may be unsafe are done to the divider
    register in any case.

    The Rockchip use of the clk_divider_ops is adapted to this split again,
    as is the nxp, lpc18xx-ccu driver that was included since the original
    commit. On lpc18xx-ccu the divider seems to always be read-only
    so only uses the new ops now.

    Fixes: e6d5e7d90be9 ("clk-divider: Fix READ_ONLY when divider > 1")
    Reported-by: Zhang Qing
    Signed-off-by: Heiko Stuebner
    Signed-off-by: Stephen Boyd

    Heiko Stuebner
     

01 Dec, 2015

1 commit

  • When we use a clk divider with a divider table, we limit the
    maximum divider value in divider_get_val() to the
    div_mask(width), but when we calculate the divider in
    divider_round_rate() we don't consider that the maximum divider
    may be limited by the width. Pass the width along to
    _get_table_maxdiv() so that we only return the maximum divider
    that is valid. This is useful for clocks that want to share the
    same divider table while limiting the available dividers to some
    subset of the table depending on the width of the bitfield.

    Cc: Rajendra Nayak
    Signed-off-by: Stephen Boyd

    Stephen Boyd
     

17 Sep, 2015

1 commit

  • On 32-bit architectures, 'unsigned long' (the type used to hold clock
    rates, in Hz) is often only 32 bits wide. DIV_ROUND_UP() (as used in,
    e.g., commit b11d282dbea2 "clk: divider: fix rate calculation for
    fractional rates") can yield an integer overflow on clock rates that are
    not (by themselves) too large to fit in 32 bits, because it performs
    addition before the division. See for example:

    DIV_ROUND_UP(3000000000, 1500000000) = (3.0G + 1.5G - 1) / 1.5G
    = OVERFLOW / 1.5G

    This patch fixes such cases by always promoting the dividend to 64-bits
    (unsigned long long) before doing the division. While this patch does
    not resolve the issue with large clock rates across the common clock
    framework nor address the problems with doing full 64-bit arithmetic on
    a 32-bit architecture, it does fix some issues seen when using clock
    dividers on a 3GHz reference clock to produce a 1.5GHz CPU clock for an
    ARMv7 Brahma B15 SoC.

    Signed-off-by: Brian Norris
    Reference: http://lkml.kernel.org/g/20150413201433.GQ32500@ld-irv-0074
    Signed-off-by: Stephen Boyd

    Brian Norris
     

25 Aug, 2015

2 commits


29 Jul, 2015

2 commits

  • The basic clock types use conditional locking for the register
    accessor spinlocks. Add __acquire() and __release() markings in
    the right locations so that sparse isn't tripped up on the
    conditional locking.

    drivers/clk/clk-mux.c:68:12: warning: context imbalance in 'clk_mux_set_parent' - different lock contexts for basic block
    drivers/clk/clk-divider.c:379:12: warning: context imbalance in 'clk_divider_set_rate' - different lock contexts for basic block
    drivers/clk/clk-gate.c:71:9: warning: context imbalance in 'clk_gate_endisable' - different lock contexts for basic block
    drivers/clk/clk-fractional-divider.c:36:9: warning: context imbalance in 'clk_fd_recalc_rate' - different lock contexts for basic block
    drivers/clk/clk-fractional-divider.c:68:12: warning: context imbalance in 'clk_fd_set_rate' - different lock contexts for basic block

    Cc: Andy Shevchenko
    Signed-off-by: Stephen Boyd

    Stephen Boyd
     
  • This commit allows certain Broadcom STB clock dividers to be used with
    clk-divider.c. It allows for a clock whose field value is the equal
    to the divisor, execpt when the field value is zero, in which case the
    divisor is 2^width. For example, consider a divisor clock with a two
    bit field:

    value divisor
    0 4
    1 1
    2 2
    3 3

    Signed-off-by: Jim Quinlan
    Signed-off-by: Michael Turquette

    Jim Quinlan
     

15 May, 2015

1 commit


10 Mar, 2015

3 commits

  • Similar to the reasoning for the previous commit

    DIV_ROUND_CLOSEST(parent_rate, rate)

    might not be the best integer divisor to get a good approximation for
    rate from parent_rate (given the metric for CLK_DIVIDER_ROUND_CLOSEST).

    For example assume a parent rate of 1000 Hz and a target rate of 700.
    Using DIV_ROUND_CLOSEST the suggested divisor gets calculated to 1
    resulting in a target rate of 1000 with a delta of 300 to the desired
    rate. With choosing 2 as divisor however the resulting rate is 500 which
    is nearer to 700.

    Signed-off-by: Uwe Kleine-König
    Acked-by: Sascha Hauer
    Acked-by: Maxime Coquelin
    Signed-off-by: Michael Turquette

    Uwe Kleine-König
     
  • It's an invalid approach to assume that among two divider values
    the one nearer the exact divider is the better one.

    Assume a parent rate of 1000 Hz, a divider with CLK_DIVIDER_POWER_OF_TWO
    and a target rate of 89 Hz. The exact divider is ~ 11.236 so 8 and 16
    are the candidates to choose from yielding rates 125 Hz and 62.5 Hz
    respectivly. While 8 is nearer to 11.236 than 16 is, the latter is still
    the better divider as 62.5 is nearer to 89 than 125 is.

    Fixes: 774b514390b1 (clk: divider: Add round to closest divider)
    Signed-off-by: Uwe Kleine-König
    Acked-by: Sascha Hauer
    Acked-by: Maxime Coquelin
    Signed-off-by: Michael Turquette

    Uwe Kleine-König
     
  • The rate provided at the output of a clk-divider is calculated as:

    DIV_ROUND_UP(parent_rate, div)

    since commit b11d282dbea2 (clk: divider: fix rate calculation for
    fractional rates). So to yield a rate not bigger than r parent_rate
    must be = its 2nd parameter. Also for dividers with
    CLK_DIVIDER_ROUND_CLOSEST set the calculation is not accurate. But this
    fixes the test case by Sascha Hauer that uses a chain of three dividers
    under a fixed clock.

    Fixes: b11d282dbea2 (clk: divider: fix rate calculation for fractional rates)
    Suggested-by: Sascha Hauer
    Signed-off-by: Uwe Kleine-König
    Acked-by: Sascha Hauer
    Signed-off-by: Michael Turquette

    Uwe Kleine-König
     

07 Mar, 2015

1 commit

  • Commit bca9690b9426 ("clk: divider: Make generic for usage elsewhere")
    returned only the divider value for read-only dividers instead of the
    actual rate.

    Fixes: bca9690b9426 ("clk: divider: Make generic for usage elsewhere")
    Signed-off-by: Heiko Stuebner
    Reviewed-by: James Hogan
    Tested-by: James Hogan
    Acked-by: Stephen Boyd
    Signed-off-by: Michael Turquette

    Heiko Stübner
     

28 Jan, 2015

1 commit


18 Jan, 2015

1 commit

  • The common clk_register_{divider,gate,mux} functions allocated memory
    for internal data which wasn't freed anywhere. Drivers using these
    helpers could only unregister clocks but the memory would still leak.

    Add corresponding unregister functions which will release all resources.

    Signed-off-by: Krzysztof Kozlowski
    Reviewed-by: Stephen Boyd
    Signed-off-by: Michael Turquette

    Krzysztof Kozlowski
     

18 Nov, 2014

1 commit

  • Commit 79c6ab509558 (clk: divider: add CLK_DIVIDER_READ_ONLY flag) in
    v3.16 introduced the CLK_DIVIDER_READ_ONLY flag which caused the
    recalc_rate() and round_rate() clock callbacks to be omitted.

    However using this flag has the unfortunate side effect of causing the
    clock recalculation code when a clock rate change is attempted to always
    treat it as a pass-through clock, i.e. with a fixed divide of 1, which
    may not be the case. Child clock rates are then recalculated using the
    wrong parent rate.

    Therefore instead of dropping the recalc_rate() and round_rate()
    callbacks, alter clk_divider_bestdiv() to always report the current
    divider as the best divider so that it is never altered.

    For me the read only clock was the system clock, which divided the PLL
    rate by 2, from which both the UART and the SPI clocks were divided.
    Initial setting of the UART rate set it correctly, but when the SPI
    clock was set, the other child clocks were miscalculated. The UART clock
    was recalculated using the PLL rate as the parent rate, resulting in a
    UART new_rate of double what it should be, and a UART which spewed forth
    garbage when the rate changes were propagated.

    Signed-off-by: James Hogan
    Cc: Thomas Abraham
    Cc: Tomasz Figa
    Cc: Max Schwarz
    Cc: # v3.16+
    Acked-by: Haojian Zhuang
    Signed-off-by: Michael Turquette

    James Hogan
     

28 May, 2014

1 commit

  • Commit c686078 ("clk: divider: Add round to closest divider") introduced
    a helper function to check whether given divisor is the best one instead
    of direct check. However due to int type used instead of unsigned long
    for passing calculated rates to this function in certain cases an
    overflow could occur, for example when trying to obtain maximum possible
    clock rate by calling clk_round_rate(..., UINT_MAX).

    This patch fixes this issue by changing the type of rate, now and best
    arguments of the function to unsigned long, which is the type that
    should be used for clock rates.

    Signed-off-by: Tomasz Figa
    Acked-by: Maxime Coquelin
    Signed-off-by: Mike Turquette

    Tomasz Figa
     

24 May, 2014

3 commits

  • Mike Turquette
     
  • Commit 1d9fe6b97 ("clk: divider: Fix best div calculation for power-of-two and
    table dividers") introduces a regression in its _table_round_up function.

    When the divider passed to this function is greater than the max divider
    available in the table, this function returns table's max divider.
    Problem is that it causes an infinite loop in clk_divider_bestdiv() because
    _next_div() will never return a value greater than maxdiv.

    Instead of returning table's max divider, this patch returns INT_MAX.

    Reported-by: Fabio Estevam
    Reported-by: Shawn Guo
    Tested-by: Fabio Estevam
    Tested-by: Shawn Guo
    Signed-off-by: Maxime Coquelin
    Signed-off-by: Mike Turquette

    Maxime COQUELIN
     
  • From: Heiko Stuebner

    Similar to muxes which already have a read-only flag there sometimes
    exist dividers which should not be changed by the clock framework
    but whose value still should be readable.

    Therefore add a READ_ONLY flag similar to the mux-one to clk-divider

    Signed-off-by: Heiko Stuebner
    [changed flag bit to BIT(5) as suggested by Tomasz Figa]
    Signed-off-by: Thomas Abraham
    Acked-by: Tomasz Figa
    Acked-by: Max Schwarz
    Tested-by: Max Schwarz
    Signed-off-by: Mike Turquette

    Heiko Stuebner
     

01 May, 2014

3 commits

  • Currently, the for-loop used to try all the different dividers to find the
    one that best fit tries all the values from 1 to max_div, incrementing by one.
    In case of power-of-two, or table based divider, the loop isn't optimal.

    Instead of incrementing by one, this patch provides directly the next divider.

    Signed-off-by: Maxime Coquelin
    Signed-off-by: Mike Turquette

    Maxime COQUELIN
     
  • In some cases, we want to be able to round the divider to the closest one,
    instead than rounding up.

    This patch adds a new CLK_DIVIDER_ROUND_CLOSEST flag to specify the divider
    has to round to closest div, keeping rounding up as de default behaviour.

    Signed-off-by: Maxime Coquelin
    Signed-off-by: Mike Turquette

    Maxime COQUELIN
     
  • The divider returned by clk_divider_bestdiv() is likely to be invalid in case
    of power-of-two and table dividers when CLK_SET_RATE_PARENT flag isn't set.

    Fixes boot on STiH416 platform.

    Signed-off-by: Maxime Coquelin
    Signed-off-by: Mike Turquette
    [mturquette@linaro.org: trivial merge conflict & updated changelog]

    Maxime COQUELIN
     

27 Feb, 2014

1 commit

  • clk-divider.c does not calculate the rates consistently at the moment.

    As an example, on OMAP3 we have a clock divider with a source clock of
    864000000 Hz. With dividers 6, 7 and 8 the theoretical rates are:

    6: 144000000
    7: 123428571.428571...
    8: 108000000

    Calling clk_round_rate() with the rate in the first column will give the
    rate in the second column:

    144000000 -> 144000000
    143999999 -> 123428571
    123428572 -> 123428571
    123428571 -> 108000000

    Note how clk_round_rate() returns 123428571 for rates from 123428572 to
    143999999, which is mathematically correct, but when clk_round_rate() is
    called with 123428571, the returned value is surprisingly 108000000.

    This means that the following code works a bit oddly:

    rate = clk_round_rate(clk, 123428572);
    clk_set_rate(clk, rate);

    As clk_set_rate() also does clock rate rounding, the result is that the
    clock is set to the rate of 108000000, not 123428571 returned by the
    clk_round_rate.

    This patch changes the clk-divider.c to use DIV_ROUND_UP when
    calculating the rate. This gives the following behavior which fixes the
    inconsistency:

    144000000 -> 144000000
    143999999 -> 123428572
    123428572 -> 123428572
    123428571 -> 108000000

    Signed-off-by: Tomi Valkeinen
    Signed-off-by: Mike Turquette

    Tomi Valkeinen
     

09 Jan, 2014

1 commit

  • Commit 6d9252bd9a4bb (clk: Add support for power of two type dividers)
    merged in v3.6 added the _get_val function to convert a divisor value to
    a register field value depending on the flags. However it used the type
    u8 for the div field, causing divisors larger than 255 to be masked
    and the resultant clock rate to be too high.

    E.g. in my case an 11bit divider was supposed to divide 24.576 MHz down
    to 32.768KHz. The divisor was correctly calculated as 750 (0x2ee). This
    was masked to 238 (0xee) resulting in a frequency of 103.26KHz.

    Signed-off-by: James Hogan
    Cc: Rajendra Nayak
    Cc: linux-arm-kernel@lists.infradead.org
    Cc: stable@vger.kernel.org
    Signed-off-by: Mike Turquette

    James Hogan