[0/3] interconnect: qcom: msm8939: Coalesce snoc and snoc_mm

Message

Bryan O'Donoghue Jan. 28, 2022, 4:09 p.m. UTC

Booting msm8939 on tip-of-tree I encountered the following error.

[    1.212340] qnoc-msm8939 580000.interconnect_mm: can't request region for resource [mem 0x00580000-0x0059407f]
[    1.212391] qnoc-msm8939 580000.interconnect_mm: Cannot ioremap interconnect bus resource
[    1.221524] qnoc-msm8939: probe of 580000.interconnect_mm failed with error -16

Initially I thought this was a bug with the interconnect driver but,
examining it a bit more I realized the DTS I was working with based on
downstream, declares snoc and snoc_mm as existing at the same address
range.

When we were developing the DTS for 8939 we weren't using the common rpm
interconnect driver so we never saw the ioremap collision.

Taking a hard look at the qcom documentation as well as the downstream code
we see that yes downstream declares snoc and snoc_mm separately but, also
at the same overlapping address.

The qcom documentation for performance points for msm8936/msm8939 snoc,
deliniates snoc_mm as simply two new performance-points i.e. a faster GPLL0
vote associated with new multi-media devices attached to the snoc.

In other words the snoc had two new RPM vote indices added to it, to
represent the higher performance clocks, should one of the multi-media IP
blocks call for it.

We can fix the ioremap collision and still represent the two higher
performance point clock votes by coalsecing snoc and snoc_mm into snoc. The
DTS clock references will take care of the appropriate votes.

Bryan O'Donoghue (3):
  dt-bindings: interconnect: Create modified msm8939-snoc description
  interconnect: qcom: msm8939: Merge snoc and snoc_mm into one
  interconnect: qcom: msm8939: Deliniate bus, bus_a, bus_mm and bus_a_mm
    clocks

 .../bindings/interconnect/qcom,rpm.yaml       | 25 +++++++++++-
 drivers/interconnect/qcom/msm8939.c           | 39 +++++++------------
 2 files changed, 37 insertions(+), 27 deletions(-)