Skip to content

L
linux
Switch branch/tag
  1. 14 Aug, 2023 8 commits
  3. 11 Aug, 2023 3 commits
  5. 04 Aug, 2023 2 commits
  7. 03 Aug, 2023 3 commits
  9. 31 Jul, 2023 13 commits
  11. 28 Jul, 2023 1 commit
  13. 18 Jul, 2023 8 commits
  15. 15 Jul, 2023 2 commits
    • Bjorn Andersson's avatar
      Merge branch '20230526-topic-smd_icc-v7-0-09c78c175546@linaro.org' into clk-for-6.6 · ad4e807f
      Bjorn Andersson authored 
      This series reshuffles things around, moving the management of SMD RPM
bus clocks to the interconnect framework where they belong. This helps
us solve a couple of issues:

1. We can work towards unused clk cleanup of RPMCC without worrying
   about it killing some NoC bus, resulting in the SoC dying.
   Deasserting actually unused RPM clocks (among other things) will
   let us achieve "true SoC-wide power collapse states", also known as
   VDD_LOW and VDD_MIN.

2. We no longer have to keep tons of quirky bus clock ifs in the icc
   driver. You either have a RPM clock and call "rpm set rate" or you
   have a single non-RPM clock (like AHB_CLK_SRC) or you don't have any.

3. There's less overhead - instead of going through layers and layers of
   the CCF, ratesetting comes down to calling max() and sending a single
   RPM message. ICC is very very dynamic so that's a big plus.

The clocks still need to be vaguely described in the clk-smd-rpm driver,
as it gives them an initial kickoff, before actually telling RPM to
enable DVFS scaling.  After RPM receives that command, all clocks that
have not been assigned a rate are considered unused and are shut down
in hardware, leading to the same issue as described in point 1.

We can consider marking them __initconst in the future, but this series
is very fat even without that..

Apart from that, it squashes a couple of bugs that really need fixing..

The series is merged through a topic branch to manage the dependencies
between interconnect, Qualcomm clocks and Qualcomm SoC.
      ad4e807f
    • Konrad Dybcio's avatar
      interconnect: qcom: icc-rpm: Fix bandwidth calculations · 17fc623e
      Konrad Dybcio authored 
      Up until now, we've been aggregating the bandwidth values and only
dividing them by the bus width of the source node. This was completely
wrong, as different nodes on a given path may (and usually do) have
varying bus widths.  That in turn, resulted in the calculated clock rates
being completely bogus - usually they ended up being much higher, as
NoC_A<->NoC_B links are very wide.

Since we're not using the aggregate bandwidth value for anything other
than clock rate calculations, remodel qcom_icc_bus_aggregate() to
calculate the per-context clock rate for a given provider, taking into
account the bus width of every individual node.

Fixes: 30c8fa3e ("interconnect: qcom: Add MSM8916 interconnect provider driver")
Reported-by: default avatarStephan Gerhold <stephan@gerhold.net>
Reviewed-by: default avatarStephan Gerhold <stephan@gerhold.net>
Signed-off-by: default avatarKonrad Dybcio <konrad.dybcio@linaro.org>
Acked-by: default avatarGeorgi Djakov <djakov@kernel.org>
Link: https://lore.kernel.org/r/20230526-topic-smd_icc-v7-22-09c78c175546@linaro.orgSigned-off-by: default avatarBjorn Andersson <andersson@kernel.org>
      17fc623e
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7