Re: [PATCH v3 2/2] arm64: dts: qcom: qcs6490-rb3gen2-industrial-mezzanine: Add second TC9563 PCIe switch node for PCIe1

From: Sushrut Shree Trivedi

Date: Wed Feb 18 2026 - 05:00:34 EST



On 2/16/2026 4:58 PM, Konrad Dybcio wrote:
On 2/15/26 3:19 PM, Sushrut Shree Trivedi wrote:
On 2/12/2026 5:16 PM, Konrad Dybcio wrote:
On 2/12/26 11:44 AM, Sushrut Shree Trivedi wrote:
Add a node for the second TC9563 PCIe switch on PCIe1, which is connected
in cascade to the first TC9563 switch via the former's downstream port.

Two embedded Ethernet devices are present on one of the downstream
ports of this second switch as well. All the ports present in the
node represent the downstream ports and embedded endpoints.

The second TC9563 is powered up via the same LDO regulators as the first
one, and these can be controlled via two GPIOs, which are already present
as fixed regulators. This TC9563 can also be configured through I2C.

Signed-off-by: Sushrut Shree Trivedi <sushrut.trivedi@xxxxxxxxxxxxxxxx>
---
+&pcie1 {
+    iommu-map = <0x0 &apps_smmu 0x1c80 0x1>,
+            <0x100 &apps_smmu 0x1c81 0x1>,
+            <0x208 &apps_smmu 0x1c84 0x1>,
+            <0x210 &apps_smmu 0x1c85 0x1>,
+            <0x218 &apps_smmu 0x1c86 0x1>,
+            <0x300 &apps_smmu 0x1c87 0x1>,
+            <0x408 &apps_smmu 0x1c90 0x1>,
+            <0x410 &apps_smmu 0x1c91 0x1>,
+            <0x418 &apps_smmu 0x1c92 0x1>,
+            <0x500 &apps_smmu 0x1c93 0x1>,
+            <0x600 &apps_smmu 0x1c94 0x1>,
+            <0x700 &apps_smmu 0x1c95 0x1>,
+            <0x701 &apps_smmu 0x1c96 0x1>,
+            <0x800 &apps_smmu 0x1c97 0x1>,
+            <0x900 &apps_smmu 0x1c98 0x1>,
+            <0x901 &apps_smmu 0x1c99 0x1>;
This map is not just an extension of the existing one - is that
intentional?
Yeah, I created a new map just for readability. Should I instead just add new mappings
and keep the older core-kit map intact ?
Quite frankly, I don't know. I that against the "base" it's missing:

0x400
0x501

so presumably the second DSP and an endpoint for the primary switch's
ethernet port?
Since PCIe enumeration happens in a Depth-First Search manner, bus numbers
3 to 7 are alloted to the cascade switch connected to DSP1 of primary switch.
Bus no.'s 8 and 9 are alloted to DSP2 endpoint and embedded ethernet EP
respectively, on the primary switch.

So, in the cascade hierarchy, bus no. 4 is alloted to Cascade switch DSP's.
There is no DSP with device no. 0 so BDF 0x400 doesn't exist and is
omitted. For the same reason, BDF 0x200 on the primary switch is also
not mapped.

BDF 0x501 in single switch case maps to the ethernet EP. In cascade,
that EP is being mapped to 0x901.

Lspci (single switch):
sh-5.2# lspci
0001:00:00.0 PCI bridge: Qualcomm Technologies, Inc SM8250 PCIe RC
0001:01:00.0 PCI bridge: Toshiba Corporation Device 0623
0001:02:01.0 PCI bridge: Toshiba Corporation Device 0623
0001:02:02.0 PCI bridge: Toshiba Corporation Device 0623
0001:02:03.0 PCI bridge: Toshiba Corporation Device 0623
0001:05:00.0 Ethernet controller: Toshiba Corporation Device 0220
0001:05:00.1 Ethernet controller: Toshiba Corporation Device 0220

Lspci (cascade switch):
0001:00:00.0 PCI bridge: Qualcomm Technologies, Inc SM8250 PCIe RC
0001:01:00.0 PCI bridge: Toshiba Corporation Device 0623
0001:02:01.0 PCI bridge: Toshiba Corporation Device 0623
0001:02:02.0 PCI bridge: Toshiba Corporation Device 0623
0001:02:03.0 PCI bridge: Toshiba Corporation Device 0623
0001:03:00.0 PCI bridge: Toshiba Corporation Device 0623
0001:04:01.0 PCI bridge: Toshiba Corporation Device 0623
0001:04:02.0 PCI bridge: Toshiba Corporation Device 0623
0001:04:03.0 PCI bridge: Toshiba Corporation Device 0623
0001:07:00.0 Ethernet controller: Toshiba Corporation Device 0220
0001:07:00.1 Ethernet controller: Toshiba Corporation Device 0220
0001:09:00.0 Ethernet controller: Toshiba Corporation Device 0220
0001:09:00.1 Ethernet controller: Toshiba Corporation Device 0220

Sushrut

Konrad