interconnect: qcom: icc-rpm: Fix for cached clock rate

interconnect: qcom: icc-rpm: Fix for cached clock rate

All nodes within an interconnect bus share interconnect bus clocks, but
every node has its own cached clock rate values, this can lead to
unexpected clock rate setting.

Let's see an example shown in below, in this case, a bus have two nodes
A and B, and its buswidth is 8:

  step1: vote bandwidth 1600M for node(A):

    aggregated(bw) = 1600M
    qcom_icc_node(A)->rate = 1600M / 8 = 200MHz

  step2: vote bandwidth 1600M for node(B):

    aggregated(bw) = 1600M + 1600M = 3200M
    qcom_icc_node(B)->rate = 3200M / 8 = 400MHz

  step3: unvote bandwidth 1600M for node(A)

    aggregated(bw) = 3200M - 1600M = 1600M
    target_clock = 1600M / 8 = 200MHz

The problem is in step 3, the calculated target clock rate is 200MHz,
which equals to the cached clock rate in node(A) (See step 1),
unfortunately, qcom_icc_set() skips to set the new clock rate 200MHz in
this case, so the bus clock rate will continue to stay at 400MHz.

To resolve the issue, one possible solution is to invoke clk_get_rate()
to retrieve the clock rates on the fly, thus we can totally remove the
cached clock rates.  But after review the code, many bus clock has set
the flag CLK_GET_RATE_NOCACHE, this results in the retrieving bus clock
rate is time cost for iterating parent clock nodes, and even challenges
bus clock drivers to provide recalc_rate() callbacks.

So this patch moves the cached rates into structure qcom_icc_provider,
we use it as a central place to maintain bus clock handlers and cached
clock rate, therefore, it can smoothly dismiss the mismatching problem.

Signed-off-by: Leo Yan <leo.yan@linaro.org>
Link: https://lore.kernel.org/r/20220416031029.693211-2-leo.yan@linaro.org
Signed-off-by: Georgi Djakov <djakov@kernel.org>