7.4. Interconnect — NoC / BCM and the LLCC¶

The on-die bus fabric and the system-level cache: how masters (UFS, the CPUs, the DSPs, the display) get bandwidth to DDR, and the last-level cache in front of it. Two things live here — the NoC bandwidth/QoS framework and the LLCC system cache — both ultimately voted through RPMh/AOP.

This tree is the downstream 4.19 ``msm-bus`` framework, not the upstream interconnect (icc) bindings: masters carry qcom,msm-bus,vectors-KBps tables (as seen on UFS and SDCC, Storage controllers — UFS, ICE, and SDCC) and a central qcom,msm-bus-device aggregates them into Bus-Clock-Manager (BCM) votes. All facts are from artifacts/boot_a/board.dts and the XBL uefiplat.cfg MMAP.

7.4.1. LLCC — the system-level cache¶

cache-controller@9200000, compatible = "lagoon-llcc-v1" — the system-level cache (SLC) that sits between the gem_noc / memory-NoC and DDR, so any master (not just the CPUs) can hit it.

Register windows:: llcc_base 0x9200000 size 0x50000 and llcc_broadcast_base 0x9600000 size 0x50000 (the broadcast alias that writes all cache slices at once).
Allocation:: cap-based-alloc-and-pwr-collapse — capacity-based way allocation per client, with the cache able to power-collapse when idle.
XBL view:: XBL maps "LLCC0" 0x09200000 size 0x50000 as ``SYS_MEM``, SYS_MEM_CAP, WRITE_BACK_XN — i.e. the SLC window is used as cacheable system memory early in boot, not as a device register block.

Instrumentation around it:

llcc-pmu@90cc000 (qcom,llcc-pmu-ver1, 0x300) — the LLCC performance monitor.
qcom,cpu-cpu-llcc-bwmon@90b6400 / qcom,bimc-bwmon4 at 0x90B6300 + 0x90B6200 — CPU↔LLCC and LLCC↔DDR bandwidth monitors feeding the cpu-llcc-ddr-bw OPP tables (the DDR DVFS governor input).
The DDR controller master is MCCC_MCCC_MSTR at 0x090B0000 (0x8000) in the XBL map — the memory-controller config the MC0 BCM (below) drives.

7.4.2. The NoC / BCM fabric¶

qcom,msm-bus-device is the central fabric node. Its ten register windows are the NoC QoS/register spaces (0x16E0000, 0x1700000, 0x1500000, 0x9160000, 0x9680000, 0x1740000, 0x1620000, 0x9990000 …) — the aggregate/config/mem NoCs and the gem_noc.

Under it are 27 Bus-Clock-Manager (BCM) resources, each a votable knob that the framework programs through an RSC’s TCS to AOP/RPMh. Grouped by prefix (the standard Qualcomm BCM taxonomy; the exact per-BCM target lives in the driver):

Prefix	BCMs present	Path it gates
`MC`	`MC0`	DDR memory controller (EBI)
`SH`	`SH0 SH2 SH3 SH4`	gem_noc / system-cache (LLCC) path
`SN`	`SN0 SN1 SN2 SN3 SN4 SN5 SN6 SN10`	system NoC
`MM`	`MM0 MM1 MM2 MM3`	multimedia NoC (display / video)
`CN`	`CN0 CN1`	config NoC (register access fabric)
`CO`	`CO0 CO2 CO3`	compute NoC (CDSP)
`QUP`	`QUP0`	the QUP serial-engine bus (QUP/GENI serial-engine bus map (what is wired where))
`CE` / `IP`	`CE0` / `IP0`	crypto-engine (Crypto engine (QCE) and hardware RNG) / IPA (IPA — the networking datapath accelerator)
`ACV` / `ALC`	`ACV` `ALC`	aggregate-vote / arbitration-latency control BCMs

Votes reach RPMh through two RSCs declared as qcom,msm-bus-rsc children — apps_rsc (the APSS/RPMh RSC, alongside qcom,rpmhclk and the RPMh regulators) and disp_rsc (the display RSC, alongside sde-rsc-rpmh). The display path gets its own RSC so it can keep the fabric up for self-refresh without waking the apps RSC; that second RSC re-declares the subset it needs (ACV ALC MC0 MM0 MM1 SH0).

7.4.3. How a master gets bandwidth¶

A master node lists qcom,msm-bus,vectors-KBps — one row per use-case, each giving {master-port, slave-port, avg-BW, peak-BW}. For example the UFS host (Storage controllers — UFS, ICE, and SDCC) has 22 rows spanning its two ports as UniPro gears change; SDCC, the DSPs and the display carry their own tables. The framework:

sums the active vectors per NoC path into a bandwidth number,
maps each path to the BCM(s) that gate it,
writes the aggregated vote into the RSC’s TCS command set, and
the RSC forwards it to AOP/RPMh, which programs the NoC clocks and QoS (AOP — the Always-On Processor (RPMh / power back-end)).

So “interconnect bandwidth” on this device is not a driver writing NoC registers directly — it is a vote aggregated into a BCM and executed by AOP.

7.4.4. Bootloader relevance¶

The fabric a bootloader must have up to touch anything is the config NoC (CN, register access) and the DDR path (MC0 + the SH gem_noc/LLCC BCMs) — XBL brings these up as part of DDR training and hands them off configured (Below UEFI — execution state and hardware register surface). A bootloader inheriting XBL state has a working fabric; one starting from scratch would have to reproduce the AOP/RPMh vote for at least DDR + config-NoC before any master (UFS, console) is reachable. The LLCC is inferred to be safe to leave in its reset (bypass) state, since it sits as a cache layer rather than on the correctness-critical datapath — not confirmed by tracing an actual bootloader that skips it.

7.4.5. Static end¶

The fabric topology (the NoC windows, the full BCM set, the two RSCs) and the LLCC geometry (base + broadcast, cap-based allocation) are fixed from the tree and the XBL map. What is not static is the live vote state — which BCM is holding what bandwidth at a given instant — because that is aggregated at runtime from whatever masters are active and lives in the RSC TCS registers / AOP, not in any partition. The per-BCM → NoC-node binding is in the qcom,msm-bus platform data in the kernel, not the dump.

7.4.6. Provenance¶

Source:: artifacts/boot_a/board.dts (cache-controller@9200000, llcc-pmu@90cc000, bimc-bwmon4, qcom,msm-bus-device with its NoC windows and 27 qcom,bcm-name resources, the two qcom,msm-bus-rsc nodes) and _READONLY/lun1/xbl_a.bin (uefiplat.cfg MMAP: LLCC0, MCCC_MCCC_MSTR).
Method:: DTB node reading + XBL MMAP cross-check; BCM prefixes grouped by the standard Qualcomm taxonomy. No code executed.
Cross-refs:: Storage controllers — UFS, ICE, and SDCC (UFS msm-bus vectors), AOP — the Always-On Processor (RPMh / power back-end) (RSC/RPMh vote execution), Clock tree — GCC, domain CCs, RPMh (RPMh/RSC), Below UEFI — execution state and hardware register surface (DDR/fabric at hand-off), Crypto engine (QCE) and hardware RNG (CE0 BCM), IPA — the networking datapath accelerator (IP0 BCM).