Re: [PATCH 8/8] arm64: dts: qcom: msm8998: wire up interconnect paths

[Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>]

On 10/19/26 4:12 PM, Dmitry Baryshkov wrote:
> With the NoC providers described but no consumer referencing them, the
> NoC bus clocks stay at their boot rates: nothing votes for DDR or
> config bandwidth, so masters such as MDSS or UFS run on whatever the
> bootloader left behind.
> 
> Add the interconnect paths for the GPU, MDSS, Venus, UFS, USB and SDHC2.
> PCIe is deliberately left out: MSM8998 has no route from the CPU to the
> PCIe config slave, and requesting one only makes the PCIe driver fail
> to probe.

On upstream, sm8450 is the first one to have one wired up in DT
(intriguing), sdm845 is the first one to have one in the icc driver

Downstream, 8450 and earlier do not have a path defined on the PCIe
node but clearly that relies on lucky ordering

I threw the LLM at msm8998-bus.dtsi and it said:

The only edges into slv_pcie_0 come from three masters:
- mas_bimc_snoc_1 (line 669), reachable only from slv_bimc_snoc_1,
  which is fed by mas_oxili and mas_mnoc_bimc. Neither is reachable from
  the apps master.
- mas_a1noc_snoc (line 679), reachable only from slv_a1noc_snoc, which
  is fed by PCIe, USB3, UFS, and BLSP2 masters.
- mas_a2noc_snoc (line 692), reachable only from slv_a2noc_snoc, which
  is fed by mas_cnoc_a2noc, IPA, SDCC2/4, TSIF, BLSP1, and
  mas_cr_virt_a2noc. The last two come from slv_cnoc_a2noc (fed only by
  mas_qdss_dap) and slv_cr_virt_a2noc (fed only by mas_crypto_c0). Neither
  of those is reachable from the apps master.

But I wonder if it's some sort of an oversight. Can we try to
regenerate the paths internally?

Konrad