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@oss.qualcomm.com>
---
.../qcom/qcs6490-rb3gen2-industrial-mezzanine.dtso | 105 +++++++++++++++++++++
arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 2 +-
2 files changed, 106 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine.dtso b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine.dtso
index 0fb89e71bf7f..a8ccb9d8f6e2 100644
--- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine.dtso
+++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine.dtso
@@ -153,6 +153,100 @@ pci@0,1 {
};
};
+&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>;
+};
+
+&pcie1_switch0_dsp1 {
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ pcie@0,0 {
+ compatible = "pci1179,0623";
+ reg = <0x30000 0x0 0x0 0x0 0x0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ device_type = "pci";
+ ranges;
+ bus-range = <0x2 0xff>;
+
+ vddc-supply = <&vdd_ntn_0p9>;
+ vdd18-supply = <&vdd_ntn_1p8>;
+ vdd09-supply = <&vdd_ntn_0p9>;
+ vddio1-supply = <&vdd_ntn_1p8>;
+ vddio2-supply = <&vdd_ntn_1p8>;
+ vddio18-supply = <&vdd_ntn_1p8>;
+
+ i2c-parent = <&i2c1 0x33>;
+
+ resx-gpios = <&tlmm 124 GPIO_ACTIVE_LOW>;
+
+ pinctrl-0 = <&pcie1_tc9563_resx_n>;
+ pinctrl-names = "default";
+
+ pcie@1,0 {
+ reg = <0x40800 0x0 0x0 0x0 0x0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ device_type = "pci";
+ ranges;
+ bus-range = <0x3 0xff>;
+ };
+
+ pcie@2,0 {
+ reg = <0x41000 0x0 0x0 0x0 0x0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+ device_type = "pci";
+ ranges;
+ bus-range = <0x4 0xff>;
+ };
+
+ pcie@3,0 {
+ reg = <0x41800 0x0 0x0 0x0 0x0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ ranges;
+ bus-range = <0x5 0xff>;
+
+ pci@0,0 {
+ reg = <0x50000 0x0 0x0 0x0 0x0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ ranges;
+ };
+
+ pci@0,1 {
+ reg = <0x50100 0x0 0x0 0x0 0x0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ ranges;
+ };
+ };
+ };
+};
+
&tlmm {
pcie0_tc9563_resx_n: pcie0-tc9563-resx-state {
pins = "gpio78";
@@ -163,4 +257,15 @@ pcie0_tc9563_resx_n: pcie0-tc9563-resx-state {
output-enable;
power-source = <0>;
};
+
+ pcie1_tc9563_resx_n: pcie1-tc9563-resx-state {
+ pins = "gpio124";
+ function = "gpio";
+
+ bias-disable;
+ input-disable;
+ output-enable;
+ power-source = <0>;
+ };
+
};
diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
index e3d2f01881ae..cd54525e45e0 100644
--- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
+++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
@@ -852,7 +852,7 @@ pcie@0,0 {
pinctrl-0 = <&tc9563_resx_n>;
pinctrl-names = "default";
- pcie@1,0 {
+ pcie1_switch0_dsp1: pcie@1,0 {
reg = <0x20800 0x0 0x0 0x0 0x0>;
#address-cells = <3>;
#size-cells = <2>;
--
2.25.1On 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@oss.qualcomm.com> > --- Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Konrad
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@oss.qualcomm.com>
> ---
> +&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?
Konrad
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@oss.qualcomm.com>
>> ---
>> +&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 ?
>
> Konrad
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@oss.qualcomm.com>
>>> ---
>>> +&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?
Konrad
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@oss.qualcomm.com>
>>>> ---
>>>> +&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
On 2/18/26 11:00 AM, Sushrut Shree Trivedi wrote:
>
> 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@oss.qualcomm.com>
>>>>> ---
>>>>> +&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.
OK, this is very useful to know, thank you
Konrad
© 2016 - 2026 Red Hat, Inc.