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

[Dmitry Baryshkov]

On Tue, Oct 20, 2026 at 09:16:15AM +0200, Konrad Dybcio wrote:
> 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?

I've only seen a tool to generate RPMh drivers. But it looks like your
intuition was correct and there is a missing path.

-- 
With best wishes
Dmitry