[2/3] interconnect: qcom: msm8939: Merge snoc and snoc_mm into one

The current msm8939 snoc and snoc_mm definitions are represented as
separate entities based on downstream definition which declares two
identical and therefore overlapping mmio regions.

Downstream:
reg = <0x580000 0x14080>,
      <0x580000 0x14080>;
reg-names = "snoc-base", "snoc-mm-base";

Upstream:
snoc: interconnect@580000 {
        compatible = "qcom,msm8939-snoc";
        #interconnect-cells = <1>;
        reg = <0x580000 0x14080>;
        clock-names = "bus", "bus_a";
        clocks = <&rpmcc RPM_SMD_SNOC_CLK>,
                 <&rpmcc RPM_SMD_SNOC_A_CLK>;
        status = "okay";
};

snoc: interconnect@580000 {
        compatible = "qcom,msm8939-snoc_mm";
        #interconnect-cells = <1>;
        reg = <0x580000 0x14080>;
        clock-names = "bus", "bus_a",
        clocks = <&rpmcc RPM_SMD_SYSMMNOC_CLK>,
                 <&rpmcc RPM_SMD_SYSMMNOC_A_CLK>;
        status = "okay";
};

This overlapping declaration leads to the following failure on boot.

[    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

snoc_mm is a complete misnomer though, as there is no distinct register
space, simply an additional clock to drive higher frequences on snoc for
new multi-media 'mm' devices tacked on to the old msm8916 snoc.

The difference can be captured with

- A new clock
- Performance points/clock settings in the relevant multi-media devices.

Fix the above bug by representing snoc_mm as two new clocks to the existing
snoc, not a separate interconnect bus.

Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
---
 drivers/interconnect/qcom/msm8939.c | 30 +++++------------------------
 1 file changed, 5 insertions(+), 25 deletions(-)

On 28/01/2022 23:23, Bryan O'Donoghue wrote:
> On 28/01/2022 22:24, Dmitry Baryshkov wrote:
>> This would lead to higher frequencies being set on both 'normal' and
>> mm snoc clocks, thus (possibly) increasing power consumption.
>>
> How so ?
> 
> There are four clocks
> 
> bus
> bus_a
> bus_mm
> bus_a_mm
> 
> The last two clocks
> 
> SNOC performance points are
> 0 | 19.2  | XO
> 1 | 50    | GPLL0
> 2 | 100   | GPLL0
> 3 | 133.3 | GPLL0
> 4 | 160   | GPLL0
> 5 | 200   | GPLL0
> 6 | 266.6 | GPLL0
> 
> SNOC_MM performance points are
> 0 | 19.2  | XO
> 1 | 50    | GPLL0
> 2 | 100   | GPLL0
> 3 | 133.3 | GPLL0
> 4 | 160   | GPLL0
> 5 | 200   | GPLL0
> 6 | 266.6 | GPLL0
> 7 | 320   | GPLL0
> 8 | 400   | GPLL0
> 
> Its GPLL0 being set, the snoc_mm clocks really just map back to GPLL0

So taking an example

If venus
interconnects = <&snoc_mm MASTER_VIDEO_P0 &bimc SLAVE_EBI_CH0>;

or mdp
interconnects = <&snoc_mm MASTER_MDP_PORT0 &bimc SLAVE_EBI_CH0>,
                 <&snoc_mm MASTER_MDP_PORT1 &bimc SLAVE_EBI_CH0>;

wants performance point #6 GPLL0 runs at 266.6 but for performance point 
#7 it runs at 320 MHz

Since the points all map back to a GPLL0 frequency, how does aggregating 
snoc and snoc_mm - result in higher power consumption ?

On Sat, 29 Jan 2022 at 02:23, Bryan O'Donoghue
<bryan.odonoghue@linaro.org> wrote:
>
> On 28/01/2022 22:24, Dmitry Baryshkov wrote:
> > This would lead to higher frequencies being set on both 'normal' and
> > mm snoc clocks, thus (possibly) increasing power consumption.
> >
> How so ?

If I remember correctly, bus clocks are set to max(sum(avg_bw),
max(peak_bw)) calculated over all bandwidth paths (nodes).
If you merge snoc and snoc_mm, the resulting sum(avg_bw) would be a
sum of (older) snoc's and snoc_mm's sums.
Thus the bus clocks (both bus and bus_mm) would be set to higher frequencies.

>
> There are four clocks
>
> bus
> bus_a
> bus_mm
> bus_a_mm
>
> The last two clocks
>
> SNOC performance points are
> 0 | 19.2  | XO
> 1 | 50    | GPLL0
> 2 | 100   | GPLL0
> 3 | 133.3 | GPLL0
> 4 | 160   | GPLL0
> 5 | 200   | GPLL0
> 6 | 266.6 | GPLL0
>
> SNOC_MM performance points are
> 0 | 19.2  | XO
> 1 | 50    | GPLL0
> 2 | 100   | GPLL0
> 3 | 133.3 | GPLL0
> 4 | 160   | GPLL0
> 5 | 200   | GPLL0
> 6 | 266.6 | GPLL0
> 7 | 320   | GPLL0
> 8 | 400   | GPLL0
>
> Its GPLL0 being set, the snoc_mm clocks really just map back to GPLL0