From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Cc: Krishna Chaitanya Chundru <quic_krichai@quicinc.com>,
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: Tue, 22 Oct 2024 20:22:07 +0300 [thread overview]
Message-ID: <CAA8EJppbY+YCesE4R4zV83CpCryyZNzvuzoNpgk+8a8h7mCzqw@mail.gmail.com> (raw)
In-Reply-To: <20241022151005.g36xnr7lf46p32ha@thinkpad>
On Tue, 22 Oct 2024 at 18:10, Manivannan Sadhasivam
<manivannan.sadhasivam@linaro.org> wrote:
>
> On Thu, Oct 17, 2024 at 02:12:00PM +0300, Dmitry Baryshkov wrote:
> > On Wed, Oct 16, 2024 at 10:43:19AM +0530, Krishna Chaitanya Chundru wrote:
> > >
> > >
> > > On 10/14/2024 4:55 AM, Dmitry Baryshkov wrote:
> > > > On Sat, Oct 12, 2024 at 06:13:34PM +0530, Manivannan Sadhasivam wrote:
> > > > > On Fri, Oct 11, 2024 at 05:24:29PM +0530, Krishna Chaitanya Chundru wrote:
> > > > >
> > > > > [...]
> > > > >
> > > > > > > > The logic here is that the fixed endpoints in the switch will get an unique SID
> > > > > > > > and the devices getting attached to slots will share the same SID of the bus
> > > > > > > > (this is the usual case with all Qcom SoCs).
> > > > > > > >
> > > > > > > > But I guess we would need 'iommu-map-mask' as well. Hope this addresses your
> > > > > > > > concern.
> > > > > > >
> > > > > > > Yes, thank you!
> > > > > > >
> > > > > > Hi dimitry & mani,
> > > > > >
> > > > > > This particular board variant doesn't expose any open slots to connect
> > > > > > a different endpoints like another switch(which might have BDF unknown
> > > > > > to us) so static table should be fine for this board variant.
> > > > > >
> > > > > > I tries to add iommu-map-mask property, the issue with that property is
> > > > > > that the driver is applying the mask to the bdf before searching for the
> > > > > > entry in the table. If I use a mask value which satisfies all the
> > > > > > entries in the table ( mask as 0x718) and if a new bdf is enumerated
> > > > > > lets say 0x600 due to mask 0x718 its value is again 0x600 only.
> > > > > >
> > > > > > Can we skip iommu-map-mask property and use only static table for this
> > > > > > board as we know this board doesn't expose any open slots.
> > > > > >
> > > > >
> > > > > Hmm, I was not aware that it doesn't have open slots. Fine with me then.
> > > >
> > > > It doesn't feature open slots, but it has two PCIe connections on HS2 /
> > > > HS3. Users might attach external PCIe devices.
> > > >
> > > > Krishna, could you please clarify, how those two connections are routed?
> > > >
> > > For this qps615 board to one of the downstream port (pcie to usb) usb
> > > hub is connected and to the other downstream port NVMe will be
> > > connected.
> >
> > The board has two PCIe links routed to the HS2 and HS3 connectors. Are
> > they routed to the PCIe switch?
> >
> > Yes, they are not standard slots, but still the board is expandable and
> > it is possible to connect external PCIe devices. As such it is not
> > possible to have static SID mapping.
> >
>
> Sorry, I think the conversation got deviated. We have concluded that the
> endpoints fixed (soldered) in the board will get a fixed SID (because we know
> what they are) and all other devices going to get connected to HS/LS connectors
> will get shared SID (because we don't know what they are).
>
> Any concern with that?
This is perfectly fine with me.
--
With best wishes
Dmitry
prev parent reply other threads:[~2024-10-22 17:22 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
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 [this message]
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=CAA8EJppbY+YCesE4R4zV83CpCryyZNzvuzoNpgk+8a8h7mCzqw@mail.gmail.com \
--to=dmitry.baryshkov@linaro.org \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.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=manivannan.sadhasivam@linaro.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).