From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Krishna Chaitanya Chundru <quic_krichai@quicinc.com>
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konrad.dybcio@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>,
linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, quic_vbadigan@quicinc.com,
quic_ramkri@quicinc.com, quic_nitegupt@quicinc.com,
quic_skananth@quicinc.com, quic_parass@quicinc.com
Subject: Re: [PATCH] arm64: dts: qcom: qcs6490-rb3gen2: Add PCIe nodes
Date: Fri, 9 Feb 2024 13:27:16 +0530 [thread overview]
Message-ID: <20240209075716.GA12035@thinkpad> (raw)
In-Reply-To: <c8be2bbf-a51c-a38f-6e6f-a88801f953d5@quicinc.com>
On Fri, Feb 09, 2024 at 12:58:15PM +0530, Krishna Chaitanya Chundru wrote:
>
>
> On 2/8/2024 8:49 PM, Dmitry Baryshkov wrote:
> > On Thu, 8 Feb 2024 at 16:58, Krishna Chaitanya Chundru
> > <quic_krichai@quicinc.com> wrote:
> > > On 2/8/2024 12:21 PM, Dmitry Baryshkov wrote:
> > > > On Thu, 8 Feb 2024 at 08:14, Krishna Chaitanya Chundru
> > > > <quic_krichai@quicinc.com> wrote:
> > > > >
> > > > >
> > > > >
> > > > > On 2/7/2024 5:17 PM, Dmitry Baryshkov wrote:
> > > > > > On Wed, 7 Feb 2024 at 12:42, Krishna chaitanya chundru
> > > > > > <quic_krichai@quicinc.com> wrote:
> > > > > > >
> > > > > > > Enable PCIe1 controller and its corresponding PHY nodes on
> > > > > > > qcs6490-rb3g2 platform.
> > > > > > >
> > > > > > > PCIe switch is connected to PCIe1, PCIe switch has multiple endpoints
> > > > > > > connected. For each endpoint a unique BDF will be assigned and should
> > > > > > > assign unique smmu id. So for each BDF add smmu id.
> > > > > > >
> > > > > > > Signed-off-by: Krishna chaitanya chundru <quic_krichai@quicinc.com>
> > > > > > > ---
> > > > > > > arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 42 ++++++++++++++++++++++++++++
> > > > > > > 1 file changed, 42 insertions(+)
> > > > > > >
> > > > > > > diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > > > > > > index 8bb7d13d85f6..0082a3399453 100644
> > > > > > > --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > > > > > > +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts
> > > > > > > @@ -413,6 +413,32 @@ vreg_bob_3p296: bob {
> > > > > > > };
> > > > > > > };
> > > > > > >
> > > > > > > +&pcie1 {
> > > > > > > + perst-gpios = <&tlmm 2 GPIO_ACTIVE_LOW>;
> > > > > > > +
> > > > > > > + pinctrl-0 = <&pcie1_reset_n>, <&pcie1_wake_n>;
> > > > > > > + pinctrl-names = "default";
> > > > > > > +
> > > > > > > + 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>,
> > > > > > > + <0x400 &apps_smmu 0x1c88 0x1>,
> > > > > > > + <0x500 &apps_smmu 0x1c89 0x1>,
> > > > > > > + <0x501 &apps_smmu 0x1c90 0x1>;
> > > > > >
> > > > > > Is the iommu-map really board specific?
> > > > > >
> > > > > The iommu-map for PCIe varies if PCIe switch is connected.
> > > > > For this platform a PCIe switch is connected and for that reason
> > > > > we need to define additional smmu ID's for each BDF.
> > > > >
> > > > > For that reason we defined here as these ID's are applicable only
> > > > > for this board.
> > > >
> > > > So, these IDs are the same for all boards, just being unused on
> > > > devices which have no bridges / switches connected to this PCIe host.
> > > > If this is correct, please move them to sc7280.dtsi.
> > > >
> > > Yes ID's will be same for all boards. we can move them sc7280.dtsi
> > > but the BDF to smmu mapping will be specific to this board only.
> > > if there is some other PCIe switch with different configuration is
> > > connected to different board of same variant in future again these
> > > mapping needs to updated.
> >
> > Could you possibly clarify this? Are they assigned one at a time
> > manually? Or is it somehow handled by the board's TZ code, which
> > assigns them sequentially to the known endpoints? And is it done via
> > probing the link or via some static configuration?
>
> There is no assignment of SID's in TZ for PCIe.
> PCIe controller has BDF to SID mapping table which we need to
> program with the iommu map table.
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/controller/dwc/pcie-qcom.c?h=v6.8-rc3#n997
>
> Based upon switch the BDF to SID table will change for example I had two
> switches with one switch has 2 PCIe ports and other has 3 ports one
> embedded port which supports multiple functions.
>
> For the first switch the BDF's are
> - 0x000(root complex),
> - 0x100(USP),
> - 0x208(DSP 0),
> - 0x210(DSP 1),
> - 0x300(endpoint connected to DSP 0),
> - 0x400( endpoint connected to DSP 1).
>
> For 2nd switch the BDF's are
> - 0x000(root complex),
> - 0x100(USP),
> - 0x208(embeeded DSP 0),
> - 0x210(DSP 1),
> - 0x218 (DSP 2),
> - 0x300(embedded endpoint function 0),
> - 0x301 (embedded endpoint function 1)
> - 0x400( endpoint connected to DSP 1)
> - 0x500(endpoint connected to DSP2).
>
> For these two switches we need different BDF to SID table so for that
> reason we are keeping iommu map here as this is specific to this board.
>
I don't understand why the SID table has to change between PCIe devices. The SID
mapping should be part of the SoC dtsi, where a single SID would be defined for
the devices under a bus. And all the devices under the bus have to use the same
SID.
Perhaps you are missing iommu-map-mask?
- Mani
--
மணிவண்ணன் சதாசிவம்
next prev parent reply other threads:[~2024-02-09 7:57 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-07 10:41 [PATCH] arm64: dts: qcom: qcs6490-rb3gen2: Add PCIe nodes Krishna chaitanya chundru
2024-02-07 11:47 ` Dmitry Baryshkov
2024-02-08 6:14 ` Krishna Chaitanya Chundru
2024-02-08 6:51 ` Dmitry Baryshkov
2024-02-08 14:58 ` Krishna Chaitanya Chundru
2024-02-08 15:19 ` Dmitry Baryshkov
2024-02-09 7:28 ` Krishna Chaitanya Chundru
2024-02-09 7:57 ` Manivannan Sadhasivam [this message]
2024-02-09 10:56 ` Dmitry Baryshkov
2024-02-12 13:15 ` Manivannan Sadhasivam
2024-02-12 13:26 ` Dmitry Baryshkov
2024-10-01 10:16 ` Manivannan Sadhasivam
2024-10-01 12:30 ` Dmitry Baryshkov
2024-10-01 14:19 ` Manivannan Sadhasivam
2024-10-01 15:08 ` Dmitry Baryshkov
2024-10-11 11:54 ` Krishna Chaitanya Chundru
2024-10-12 12:43 ` Manivannan Sadhasivam
2024-10-13 23:25 ` Dmitry Baryshkov
2024-10-16 5:13 ` Krishna Chaitanya Chundru
2024-10-17 11:12 ` Dmitry Baryshkov
2024-10-22 15:10 ` Manivannan Sadhasivam
2024-10-22 17:22 ` Dmitry Baryshkov
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=20240209075716.GA12035@thinkpad \
--to=manivannan.sadhasivam@linaro.org \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.baryshkov@linaro.org \
--cc=konrad.dybcio@linaro.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_krichai@quicinc.com \
--cc=quic_nitegupt@quicinc.com \
--cc=quic_parass@quicinc.com \
--cc=quic_ramkri@quicinc.com \
--cc=quic_skananth@quicinc.com \
--cc=quic_vbadigan@quicinc.com \
--cc=robh+dt@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;
as well as URLs for NNTP newsgroup(s).