==========================================
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, :doc:`storage`) 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.

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.

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):

.. list-table::
   :header-rows: 1
   :widths: 14 40 46

   * - 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 (:doc:`/boot/qup-buses`)
   * - ``CE`` / ``IP``
     - ``CE0`` / ``IP0``
     - crypto-engine (:doc:`/trustzone/crypto-engine`) / IPA (:doc:`/soc/ipa`)
   * - ``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``).

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
(:doc:`storage`) has 22 rows spanning its two ports as UniPro gears change; SDCC,
the DSPs and the display carry their own tables. The framework:

1. sums the active vectors per NoC path into a bandwidth number,
2. maps each path to the BCM(s) that gate it,
3. writes the aggregated vote into the RSC's TCS command set, and
4. the RSC forwards it to AOP/RPMh, which programs the NoC clocks and QoS
   (:doc:`/soc/aop`).

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.

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
(:doc:`/boot/below-uefi`). 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.

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.

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: :doc:`storage` (UFS ``msm-bus`` vectors), :doc:`/soc/aop`
   (RSC/RPMh vote execution), :doc:`clocks` (RPMh/RSC), :doc:`/boot/below-uefi`
   (DDR/fabric at hand-off), :doc:`/trustzone/crypto-engine` (CE0 BCM),
   :doc:`/soc/ipa` (IP0 BCM).