mbox series

[v9,00/25] clk: More clock rate fixes and tests

Message ID 20220816112530.1837489-1-maxime@cerno.tech (mailing list archive)
Headers show
Series clk: More clock rate fixes and tests | expand

Message

Maxime Ripard Aug. 16, 2022, 11:25 a.m. UTC
Hi,

Thanks to the feedback I got on the previous series, I found and fixed a
number of bugs in the clock framework and how it deals with rates,
especially when it comes to orphan clocks.

In order to make sure this doesn't pop up again as a regression, I've
extended the number of tests.

The first patch reintroduces the clk_set_rate_range call on clk_put, but
this time will only do so if there was a range set on that clock to
begin with. It should be less intrusive, and reduce the number of
potential side effects considerably.

We then have a fix for the qcom rcg2 issue that has been reported
recently.

All the other patches should be probably be flagged as fixes, but
they've never seem to have shown any real-world issues until now, and
they aren't all really trivial to backport either, so I'm not sure it's
worth it.

There's also some documentation improvements for recalc_rate and
clk_get_rate to hopefully make the documentation less ambiguous and
acknowledge that recalc_rate() returning 0 on error is fine.

Let me know what you think,
Maxime

Changes from v8:
  - Fixed a regression when probing a clock driver backed by a device accessed
    through a bus that might sleep

Changes from v7:
  - Dropped the RPi fixes
  - Rebased on 6.0-rc1

Changes from v6:
  - Fixed a kernel build bot warning

Changes from v5:
  - Rebased on current next (next-20220711)
  - Dropped clk_get_rate_range, and used a custom function instead
  - Switched all tests to use clk_hw_get_clk() instead of struct clk_hw->clk
  - Removed some intermediate variables
  - Added some comments
  - Dropped clk_get_parent() changes
  - Dropped test on clk_hw pointer non-NULL in clk_hw_get_name
  - Made clk_has_parent more const

Changes from v4:
  - Fix build breakage on SAM9x60

Changes from v3:
  - constness warning fix in clk_core_forward_rate_req

Changes from v2:
  - Rebased on top of current next
  - Fixed locking issue in clk_get_rate_range

Changes from v1:
  - Rebased on top of next-20220428
  - Dropped the patch to prevent non-orphan clocks from registering if
    their recalc_rate hook returns 0
  - Added some patches to clarify the clk_get_rate and recalc_rate
    documentation
  - Dropped the patch to skip the range setup on an orphan clock that
    was introducing a regression on RaspberryPi3 when a monitor wasn't
    connected at boot
  - Added a patch to skip the rate clamping in clk_round_rate() when
    min_rate == max_rate == 0
  - Added a new set of functions to query the clk boundaries and fix a
    regression with the RaspberryPi4
  - Fixed all the drivers hand-crafting their clk_rate_request
  - Reworded the test suite descriptions
  - Reordered a few patches to ease the review
  - Reworded some commit logs to better explain the issues they address
  - Collected the Tested-by of Alexander and Marek
  - More tests

Maxime Ripard (25):
  clk: test: Switch to clk_hw_get_clk
  clk: Drop the rate range on clk_put()
  clk: Skip clamping when rounding if there's no boundaries
  clk: Mention that .recalc_rate can return 0 on error
  clk: Clarify clk_get_rate() expectations
  clk: tests: Add test suites description
  clk: tests: Add reference to the orphan mux bug report
  clk: tests: Add tests for uncached clock
  clk: tests: Add tests for single parent mux
  clk: tests: Add tests for mux with multiple parents
  clk: tests: Add some tests for orphan with multiple parents
  clk: Take into account uncached clocks in clk_set_rate_range()
  clk: Set req_rate on reparenting
  clk: Change clk_core_init_rate_req prototype
  clk: Move clk_core_init_rate_req() from clk_core_round_rate_nolock()
    to its caller
  clk: Introduce clk_hw_init_rate_request()
  clk: Add our request boundaries in clk_core_init_rate_req
  clk: Switch from __clk_determine_rate to clk_core_round_rate_nolock
  clk: Introduce clk_core_has_parent()
  clk: Constify clk_has_parent()
  clk: Stop forwarding clk_rate_requests to the parent
  clk: Zero the clk_rate_request structure
  clk: Introduce the clk_hw_get_rate_range function
  clk: qcom: clk-rcg2: Take clock boundaries into consideration for
    gfx3d
  clk: tests: Add missing test case for ranges

 drivers/clk/at91/clk-generated.c  |    5 +-
 drivers/clk/at91/clk-master.c     |    9 +-
 drivers/clk/at91/clk-peripheral.c |    4 +-
 drivers/clk/clk-composite.c       |    6 +-
 drivers/clk/clk-divider.c         |   20 +-
 drivers/clk/clk.c                 |  288 ++++--
 drivers/clk/clk_test.c            | 1413 ++++++++++++++++++++++++++++-
 drivers/clk/qcom/clk-rcg2.c       |    9 +
 include/linux/clk-provider.h      |   18 +-
 include/linux/clk.h               |    2 +-
 10 files changed, 1665 insertions(+), 109 deletions(-)

Comments

Alexander Stein Aug. 16, 2022, 2:07 p.m. UTC | #1
Hello Maxime,

Am Dienstag, 16. August 2022, 13:25:05 CEST schrieb Maxime Ripard:
> Thanks to the feedback I got on the previous series, I found and fixed a
> number of bugs in the clock framework and how it deals with rates,
> especially when it comes to orphan clocks.
> 
> In order to make sure this doesn't pop up again as a regression, I've
> extended the number of tests.
> 
> The first patch reintroduces the clk_set_rate_range call on clk_put, but
> this time will only do so if there was a range set on that clock to
> begin with. It should be less intrusive, and reduce the number of
> potential side effects considerably.
> 
> We then have a fix for the qcom rcg2 issue that has been reported
> recently.
> 
> All the other patches should be probably be flagged as fixes, but
> they've never seem to have shown any real-world issues until now, and
> they aren't all really trivial to backport either, so I'm not sure it's
> worth it.
> 
> There's also some documentation improvements for recalc_rate and
> clk_get_rate to hopefully make the documentation less ambiguous and
> acknowledge that recalc_rate() returning 0 on error is fine.
> 
> Let me know what you think,
> Maxime
> 
> Changes from v8:
>   - Fixed a regression when probing a clock driver backed by a device
> accessed through a bus that might sleep

With this v9 series my TQMa8MPxL platform boots without issue, also with the 
i2c attached audio codec driver successfully probed. Thanks!

Best regards,
Alexander

> Changes from v7:
>   - Dropped the RPi fixes
>   - Rebased on 6.0-rc1
> 
> Changes from v6:
>   - Fixed a kernel build bot warning
> 
> Changes from v5:
>   - Rebased on current next (next-20220711)
>   - Dropped clk_get_rate_range, and used a custom function instead
>   - Switched all tests to use clk_hw_get_clk() instead of struct clk_hw->clk
> - Removed some intermediate variables
>   - Added some comments
>   - Dropped clk_get_parent() changes
>   - Dropped test on clk_hw pointer non-NULL in clk_hw_get_name
>   - Made clk_has_parent more const
> 
> Changes from v4:
>   - Fix build breakage on SAM9x60
> 
> Changes from v3:
>   - constness warning fix in clk_core_forward_rate_req
> 
> Changes from v2:
>   - Rebased on top of current next
>   - Fixed locking issue in clk_get_rate_range
> 
> Changes from v1:
>   - Rebased on top of next-20220428
>   - Dropped the patch to prevent non-orphan clocks from registering if
>     their recalc_rate hook returns 0
>   - Added some patches to clarify the clk_get_rate and recalc_rate
>     documentation
>   - Dropped the patch to skip the range setup on an orphan clock that
>     was introducing a regression on RaspberryPi3 when a monitor wasn't
>     connected at boot
>   - Added a patch to skip the rate clamping in clk_round_rate() when
>     min_rate == max_rate == 0
>   - Added a new set of functions to query the clk boundaries and fix a
>     regression with the RaspberryPi4
>   - Fixed all the drivers hand-crafting their clk_rate_request
>   - Reworded the test suite descriptions
>   - Reordered a few patches to ease the review
>   - Reworded some commit logs to better explain the issues they address
>   - Collected the Tested-by of Alexander and Marek
>   - More tests
> 
> Maxime Ripard (25):
>   clk: test: Switch to clk_hw_get_clk
>   clk: Drop the rate range on clk_put()
>   clk: Skip clamping when rounding if there's no boundaries
>   clk: Mention that .recalc_rate can return 0 on error
>   clk: Clarify clk_get_rate() expectations
>   clk: tests: Add test suites description
>   clk: tests: Add reference to the orphan mux bug report
>   clk: tests: Add tests for uncached clock
>   clk: tests: Add tests for single parent mux
>   clk: tests: Add tests for mux with multiple parents
>   clk: tests: Add some tests for orphan with multiple parents
>   clk: Take into account uncached clocks in clk_set_rate_range()
>   clk: Set req_rate on reparenting
>   clk: Change clk_core_init_rate_req prototype
>   clk: Move clk_core_init_rate_req() from clk_core_round_rate_nolock()
>     to its caller
>   clk: Introduce clk_hw_init_rate_request()
>   clk: Add our request boundaries in clk_core_init_rate_req
>   clk: Switch from __clk_determine_rate to clk_core_round_rate_nolock
>   clk: Introduce clk_core_has_parent()
>   clk: Constify clk_has_parent()
>   clk: Stop forwarding clk_rate_requests to the parent
>   clk: Zero the clk_rate_request structure
>   clk: Introduce the clk_hw_get_rate_range function
>   clk: qcom: clk-rcg2: Take clock boundaries into consideration for
>     gfx3d
>   clk: tests: Add missing test case for ranges
> 
>  drivers/clk/at91/clk-generated.c  |    5 +-
>  drivers/clk/at91/clk-master.c     |    9 +-
>  drivers/clk/at91/clk-peripheral.c |    4 +-
>  drivers/clk/clk-composite.c       |    6 +-
>  drivers/clk/clk-divider.c         |   20 +-
>  drivers/clk/clk.c                 |  288 ++++--
>  drivers/clk/clk_test.c            | 1413 ++++++++++++++++++++++++++++-
>  drivers/clk/qcom/clk-rcg2.c       |    9 +
>  include/linux/clk-provider.h      |   18 +-
>  include/linux/clk.h               |    2 +-
>  10 files changed, 1665 insertions(+), 109 deletions(-)
Naresh Kamboju Aug. 18, 2022, 6:44 a.m. UTC | #2
On Tue, 16 Aug 2022 at 16:55, Maxime Ripard <maxime@cerno.tech> wrote:
>
> Hi,
>
> Thanks to the feedback I got on the previous series, I found and fixed a
> number of bugs in the clock framework and how it deals with rates,
> especially when it comes to orphan clocks.
>
> In order to make sure this doesn't pop up again as a regression, I've
> extended the number of tests.
>
> The first patch reintroduces the clk_set_rate_range call on clk_put, but
> this time will only do so if there was a range set on that clock to
> begin with. It should be less intrusive, and reduce the number of
> potential side effects considerably.
>
> We then have a fix for the qcom rcg2 issue that has been reported
> recently.
>
> All the other patches should be probably be flagged as fixes, but
> they've never seem to have shown any real-world issues until now, and
> they aren't all really trivial to backport either, so I'm not sure it's
> worth it.
>
> There's also some documentation improvements for recalc_rate and
> clk_get_rate to hopefully make the documentation less ambiguous and
> acknowledge that recalc_rate() returning 0 on error is fine.
>
> Let me know what you think,
> Maxime
>
> Changes from v8:
>   - Fixed a regression when probing a clock driver backed by a device accessed
>     through a bus that might sleep
>
> Changes from v7:
>   - Dropped the RPi fixes
>   - Rebased on 6.0-rc1
>
> Changes from v6:
>   - Fixed a kernel build bot warning
>
> Changes from v5:
>   - Rebased on current next (next-20220711)
>   - Dropped clk_get_rate_range, and used a custom function instead
>   - Switched all tests to use clk_hw_get_clk() instead of struct clk_hw->clk
>   - Removed some intermediate variables
>   - Added some comments
>   - Dropped clk_get_parent() changes
>   - Dropped test on clk_hw pointer non-NULL in clk_hw_get_name
>   - Made clk_has_parent more const
>
> Changes from v4:
>   - Fix build breakage on SAM9x60
>
> Changes from v3:
>   - constness warning fix in clk_core_forward_rate_req
>
> Changes from v2:
>   - Rebased on top of current next
>   - Fixed locking issue in clk_get_rate_range
>
> Changes from v1:
>   - Rebased on top of next-20220428
>   - Dropped the patch to prevent non-orphan clocks from registering if
>     their recalc_rate hook returns 0
>   - Added some patches to clarify the clk_get_rate and recalc_rate
>     documentation
>   - Dropped the patch to skip the range setup on an orphan clock that
>     was introducing a regression on RaspberryPi3 when a monitor wasn't
>     connected at boot
>   - Added a patch to skip the rate clamping in clk_round_rate() when
>     min_rate == max_rate == 0
>   - Added a new set of functions to query the clk boundaries and fix a
>     regression with the RaspberryPi4
>   - Fixed all the drivers hand-crafting their clk_rate_request
>   - Reworded the test suite descriptions
>   - Reordered a few patches to ease the review
>   - Reworded some commit logs to better explain the issues they address
>   - Collected the Tested-by of Alexander and Marek
>   - More tests
>
> Maxime Ripard (25):
>   clk: test: Switch to clk_hw_get_clk
>   clk: Drop the rate range on clk_put()
>   clk: Skip clamping when rounding if there's no boundaries
>   clk: Mention that .recalc_rate can return 0 on error
>   clk: Clarify clk_get_rate() expectations
>   clk: tests: Add test suites description
>   clk: tests: Add reference to the orphan mux bug report
>   clk: tests: Add tests for uncached clock
>   clk: tests: Add tests for single parent mux
>   clk: tests: Add tests for mux with multiple parents
>   clk: tests: Add some tests for orphan with multiple parents
>   clk: Take into account uncached clocks in clk_set_rate_range()
>   clk: Set req_rate on reparenting
>   clk: Change clk_core_init_rate_req prototype
>   clk: Move clk_core_init_rate_req() from clk_core_round_rate_nolock()
>     to its caller
>   clk: Introduce clk_hw_init_rate_request()
>   clk: Add our request boundaries in clk_core_init_rate_req
>   clk: Switch from __clk_determine_rate to clk_core_round_rate_nolock
>   clk: Introduce clk_core_has_parent()
>   clk: Constify clk_has_parent()
>   clk: Stop forwarding clk_rate_requests to the parent
>   clk: Zero the clk_rate_request structure
>   clk: Introduce the clk_hw_get_rate_range function
>   clk: qcom: clk-rcg2: Take clock boundaries into consideration for
>     gfx3d
>   clk: tests: Add missing test case for ranges
>
>  drivers/clk/at91/clk-generated.c  |    5 +-
>  drivers/clk/at91/clk-master.c     |    9 +-
>  drivers/clk/at91/clk-peripheral.c |    4 +-
>  drivers/clk/clk-composite.c       |    6 +-
>  drivers/clk/clk-divider.c         |   20 +-
>  drivers/clk/clk.c                 |  288 ++++--
>  drivers/clk/clk_test.c            | 1413 ++++++++++++++++++++++++++++-
>  drivers/clk/qcom/clk-rcg2.c       |    9 +
>  include/linux/clk-provider.h      |   18 +-
>  include/linux/clk.h               |    2 +-
>  10 files changed, 1665 insertions(+), 109 deletions(-)

I have done build testing, boot testing and LTP syscalls testing on
arm64 devices Rpi4 and db410c all test pass.

Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
Tested-by: Naresh Kamboju <naresh.kamboju@linaro.org>

Build link:
https://builds.tuxbuild.com/2DUDJVgnEeotDGSNrcOuFswbTRm/

Test runs links:
https://lkft.validation.linaro.org/scheduler/job/5402030
https://lkft.validation.linaro.org/scheduler/job/5402031

- Naresh
Maxime Ripard Sept. 2, 2022, 2:53 p.m. UTC | #3
Stephen, Mike,

On Tue, Aug 16, 2022 at 01:25:05PM +0200, Maxime Ripard wrote:
> Thanks to the feedback I got on the previous series, I found and fixed a
> number of bugs in the clock framework and how it deals with rates,
> especially when it comes to orphan clocks.
> 
> In order to make sure this doesn't pop up again as a regression, I've
> extended the number of tests.
> 
> The first patch reintroduces the clk_set_rate_range call on clk_put, but
> this time will only do so if there was a range set on that clock to
> begin with. It should be less intrusive, and reduce the number of
> potential side effects considerably.
> 
> We then have a fix for the qcom rcg2 issue that has been reported
> recently.
> 
> All the other patches should be probably be flagged as fixes, but
> they've never seem to have shown any real-world issues until now, and
> they aren't all really trivial to backport either, so I'm not sure it's
> worth it.
> 
> There's also some documentation improvements for recalc_rate and
> clk_get_rate to hopefully make the documentation less ambiguous and
> acknowledge that recalc_rate() returning 0 on error is fine.

I'm not sure what to do at that point.

Back in July, you felt uncomfortable merging that series so close to the
merge window. I've sent a new series as soon as -rc1 was out, got a
kernelci run to test it and on a number of other platforms. And now
we're close to rc4, which means that you're going to bring the "we're
too late now for 6.1, let's target 6.2".

I believe this series fixes a number of real bugs in the CCF, in
addition to extending quite a lot the unit test coverage of the
framework. But if you just don't care, please just say so. I really
don't want to waste any more time rebasing and sending that series, and
pinging you on a regular basis if it's not going anywhere.

Maxime
Stephen Boyd Sept. 17, 2022, 8:31 a.m. UTC | #4
Quoting Maxime Ripard (2022-09-02 07:53:05)
> 
> I believe this series fixes a number of real bugs in the CCF, in
> addition to extending quite a lot the unit test coverage of the
> framework. But if you just don't care, please just say so. I really
> don't want to waste any more time rebasing and sending that series, and
> pinging you on a regular basis if it's not going anywhere.
> 

I've merged the patch series to clk-next. If things go sideways in the
next week we can figure out what to do. Thanks for sticking with it!
Maxime Ripard Sept. 20, 2022, 12:35 p.m. UTC | #5
Hi Stephen,

On Sat, Sep 17, 2022 at 01:31:35AM -0700, Stephen Boyd wrote:
> Quoting Maxime Ripard (2022-09-02 07:53:05)
> > 
> > I believe this series fixes a number of real bugs in the CCF, in
> > addition to extending quite a lot the unit test coverage of the
> > framework. But if you just don't care, please just say so. I really
> > don't want to waste any more time rebasing and sending that series, and
> > pinging you on a regular basis if it's not going anywhere.
> > 
> 
> I've merged the patch series to clk-next. If things go sideways in the
> next week we can figure out what to do. Thanks for sticking with it!

It looks like you picked it up in a separate branch, but didnt't
merge/push the merge into clk-next?

Maxime