From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: "Mrinmay Sarkar" <quic_msarkar@quicinc.com>,
andersson@kernel.org, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, konrad.dybcio@linaro.org, robh@kernel.org,
quic_shazhuss@quicinc.com, quic_nitegupt@quicinc.com,
quic_ramkri@quicinc.com, quic_nayiluri@quicinc.com,
dmitry.baryshkov@linaro.org, quic_krichai@quicinc.com,
quic_vbadigan@quicinc.com, quic_schintav@quicinc.com,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Bjorn Helgaas" <bhelgaas@google.com>,
linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Re: [PATCH v5 1/3] PCI: qcom: Enable cache coherency for SA8775P RC
Date: Mon, 4 Mar 2024 11:30:06 +0530 [thread overview]
Message-ID: <20240304060006.GC2647@thinkpad> (raw)
In-Reply-To: <20240228193441.GA281471@bhelgaas>
On Wed, Feb 28, 2024 at 01:34:41PM -0600, Bjorn Helgaas wrote:
> On Thu, Feb 29, 2024 at 12:15:02AM +0530, Manivannan Sadhasivam wrote:
> > On Wed, Feb 28, 2024 at 11:39:07AM -0600, Bjorn Helgaas wrote:
> > > On Wed, Feb 28, 2024 at 10:44:12PM +0530, Manivannan Sadhasivam wrote:
> > > > On Wed, Feb 28, 2024 at 09:02:11AM -0600, Bjorn Helgaas wrote:
> > > > > On Wed, Feb 28, 2024 at 06:34:11PM +0530, Mrinmay Sarkar wrote:
> > > > > > On 2/24/2024 4:24 AM, Bjorn Helgaas wrote:
> > > > > > > On Fri, Feb 23, 2024 at 07:33:38PM +0530, Mrinmay Sarkar wrote:
> > > > > > > > Due to some hardware changes, SA8775P has set the
> > > > > > > > NO_SNOOP attribute in its TLP for all the PCIe
> > > > > > > > controllers. NO_SNOOP attribute when set, the requester
> > > > > > > > is indicating that there no cache coherency issues exit
> > > > > > > > for the addressed memory on the host i.e., memory is not
> > > > > > > > cached. But in reality, requester cannot assume this
> > > > > > > > unless there is a complete control/visibility over the
> > > > > > > > addressed memory on the host.
> > > > > > >
> > > > > > > Forgive my ignorance here. It sounds like the cache
> > > > > > > coherency issue would refer to system memory, so the
> > > > > > > relevant No Snoop attribute would be in DMA transactions,
> > > > > > > i.e., Memory Reads or Writes initiated by PCIe Endpoints.
> > > > > > > But it looks like this patch would affect TLPs initiated
> > > > > > > by the Root Complex, not those from Endpoints, so I'm
> > > > > > > confused about how this works.
> > > > > > >
> > > > > > > If this were in the qcom-ep driver, it would make sense
> > > > > > > that setting No Snoop in the TLPs initiated by the
> > > > > > > Endpoint could be a problem, but that doesn't seem to be
> > > > > > > what this patch is concerned with.
> > > > > >
> > > > > > I think in multiprocessor system cache coherency issue might
> > > > > > occur. and RC as well needs to snoop cache to avoid
> > > > > > coherency as it is not enable by default.
> > > > >
> > > > > My mental picture isn't detailed enough, so I'm still
> > > > > confused. We're talking about TLPs initiated by the RC.
> > > > > Normally these would be because a driver did a CPU load or
> > > > > store to a PCIe device MMIO space, not to system memory.
> > > >
> > > > Endpoint can expose its system memory as a BAR to the host. In
> > > > that case, the cache coherency issue would apply for TLPs
> > > > originating from RC as well.
> > >
> > > What PCIe transactions are involved here? So far I know about:
> > >
> > > RC initiates Memory Read Request (or Write) with NO_SNOOP==0
> > > ...
> > > EP responds with Completion with Data (for Read)
> >
> > The memory on the endpoint may be cached (due to linear map and
> > such). So if the RC is initiating the MWd TLP with NO_SNOOP=1, then
> > there would be coherency issues because there is no guarantee that
> > the memory is not cached on the endpoint. So, not snooping the
> > caches and directly writing to the DDR would cause coherency issues
> > on the endpoint as well.
>
> I don't know what linear map is, but I'll take your word for it that
> endpoints are allowed to cache things internally. So I guess in the
> ideal world there might be a way for a driver to specify no-snoop for
> accesses to its device if it knows there is no caching.
>
I referred to Linux kernel's mapping of the DDR space as "linear map". But the
endpoint may not run only Linux, but any RTOS or even bare metal. So it is
certainly possible the BAR memory could be cached.
> The commit log for this patch refers to caching on the *host*, though,
> and IIUC you're saying this patch clears NO_SNOOP on TLPs from the RC
> because of potential coherency issues on the *endpoint*.
>
Yeah, the commit message was wrong. I shared the wording during the review of
previous version and it got duplicated for both RC and EP patches :(
This should be fixed.
- Mani
--
மணிவண்ணன் சதாசிவம்
next prev parent reply other threads:[~2024-03-04 6:00 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-23 14:03 [PATCH v5 0/3] arm64: qcom: sa8775p: add cache coherency support for SA8775P Mrinmay Sarkar
2024-02-23 14:03 ` [PATCH v5 1/3] PCI: qcom: Enable cache coherency for SA8775P RC Mrinmay Sarkar
2024-02-23 22:54 ` Bjorn Helgaas
2024-02-28 13:04 ` Mrinmay Sarkar
2024-02-28 15:02 ` Bjorn Helgaas
2024-02-28 17:14 ` Manivannan Sadhasivam
2024-02-28 17:39 ` Bjorn Helgaas
2024-02-28 18:45 ` Manivannan Sadhasivam
2024-02-28 19:34 ` Bjorn Helgaas
2024-03-04 6:00 ` Manivannan Sadhasivam [this message]
2024-03-04 6:07 ` Manivannan Sadhasivam
2024-02-23 14:03 ` [PATCH v5 2/3] PCI: qcom-ep: Enable cache coherency for SA8775P EP Mrinmay Sarkar
2024-02-24 0:07 ` Konrad Dybcio
2024-02-28 13:06 ` Mrinmay Sarkar
2024-02-23 14:03 ` [PATCH v5 3/3] arm64: dts: qcom: sa8775p: Mark PCIe EP controller as cache coherent Mrinmay Sarkar
2024-02-24 10:19 ` [PATCH v5 0/3] arm64: qcom: sa8775p: add cache coherency support for SA8775P Krzysztof Kozlowski
2024-02-28 13:07 ` Mrinmay Sarkar
2024-02-28 14:02 ` Krzysztof Kozlowski
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=20240304060006.GC2647@thinkpad \
--to=manivannan.sadhasivam@linaro.org \
--cc=andersson@kernel.org \
--cc=bhelgaas@google.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.baryshkov@linaro.org \
--cc=helgaas@kernel.org \
--cc=konrad.dybcio@linaro.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kw@linux.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=quic_krichai@quicinc.com \
--cc=quic_msarkar@quicinc.com \
--cc=quic_nayiluri@quicinc.com \
--cc=quic_nitegupt@quicinc.com \
--cc=quic_ramkri@quicinc.com \
--cc=quic_schintav@quicinc.com \
--cc=quic_shazhuss@quicinc.com \
--cc=quic_vbadigan@quicinc.com \
--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;
as well as URLs for NNTP newsgroup(s).