Linux ARM-MSM sub-architecture
 help / color / mirror / Atom feed
From: Sushrut Shree Trivedi <sushrut.trivedi@oss.qualcomm.com>
To: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>,
	Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konradybcio@kernel.org>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>
Cc: linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Subject: Re: [PATCH v3 2/2] arm64: dts: qcom: qcs6490-rb3gen2-industrial-mezzanine: Add second TC9563 PCIe switch node for PCIe1
Date: Wed, 18 Feb 2026 15:30:01 +0530	[thread overview]
Message-ID: <544be6af-fe02-425c-9457-4101f5dee80f@oss.qualcomm.com> (raw)
In-Reply-To: <5c17f64e-5125-4365-b986-8c058cee292f@oss.qualcomm.com>


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

  reply	other threads:[~2026-02-18 10:00 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-12 10:44 [PATCH v3 0/2] arm64: dts: qcom: qcs6490-rb3gen2-industrial-mezzanine: Add TC9563 PCIe switch nodes Sushrut Shree Trivedi
2026-02-12 10:44 ` [PATCH v3 1/2] arm64: dts: qcom: qcs6490-rb3gen2-industrial-mezzanine: Add TC9563 PCIe switch node for PCIe0 Sushrut Shree Trivedi
2026-02-12 11:47   ` Konrad Dybcio
2026-02-13 16:40   ` Dmitry Baryshkov
2026-02-12 10:44 ` [PATCH v3 2/2] arm64: dts: qcom: qcs6490-rb3gen2-industrial-mezzanine: Add second TC9563 PCIe switch node for PCIe1 Sushrut Shree Trivedi
2026-02-12 11:46   ` Konrad Dybcio
2026-02-15 14:19     ` Sushrut Shree Trivedi
2026-02-16 11:28       ` Konrad Dybcio
2026-02-18 10:00         ` Sushrut Shree Trivedi [this message]
2026-02-18 10:43           ` Konrad Dybcio
2026-02-18 10:43   ` Konrad Dybcio
2026-02-12 11:48 ` [PATCH v3 0/2] arm64: dts: qcom: qcs6490-rb3gen2-industrial-mezzanine: Add TC9563 PCIe switch nodes Konrad Dybcio
2026-02-24  6:33   ` Sushrut Shree Trivedi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=544be6af-fe02-425c-9457-4101f5dee80f@oss.qualcomm.com \
    --to=sushrut.trivedi@oss.qualcomm.com \
    --cc=andersson@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.baryshkov@oss.qualcomm.com \
    --cc=konrad.dybcio@oss.qualcomm.com \
    --cc=konradybcio@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox