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

[Konrad Dybcio]

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@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.

OK, this is very useful to know, thank you

Konrad