From: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
To: Niklas Cassel <cassel@kernel.org>
Cc: "Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Rob Herring" <robh@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Kishon Vijay Abraham I" <kishon@kernel.org>,
"Thierry Reding" <thierry.reding@gmail.com>,
"Jonathan Hunter" <jonathanh@nvidia.com>,
"Jingoo Han" <jingoohan1@gmail.com>,
linux-pci@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-kernel@vger.kernel.org, mhi@lists.linux.dev,
linux-tegra@vger.kernel.org
Subject: Re: [PATCH v2 10/10] PCI: qcom: Implement shutdown() callback to properly reset the endpoint devices
Date: Fri, 12 Apr 2024 12:02:42 +0530 [thread overview]
Message-ID: <20240412063242.GA2712@thinkpad> (raw)
In-Reply-To: <ZhcAKSJCQag6AX09@ryzen>
On Wed, Apr 10, 2024 at 11:10:01PM +0200, Niklas Cassel wrote:
> On Wed, Apr 10, 2024 at 04:52:18PM +0200, Niklas Cassel wrote:
> > On Wed, Apr 10, 2024 at 04:24:10PM +0530, Manivannan Sadhasivam wrote:
> > >
> > > Well, we could prevent the register access during PERST# assert time in the
> > > endpoint, but my worry is that we will end up with 2 version of the cleanup
> > > APIs. Lets take an example of dw_pcie_edma_remove() API which gets called
> > > during deinit and it touches some eDMA registers.
> > >
> > > So should we introduce another API which just clears the sw data structure and
> > > not touching the registers? And this may be needed for other generic APIs as
> > > well.
> >
> > I agree that it will be hard to come up with an elegant solution to this
> > problem.
> >
> > These endpoint controllers that cannot do register accesses to their own
> > controllers' DBI/register space without the RC providing a refclock are
> > really becoming a pain... and the design and complexity of the PCI endpoint
> > APIs is what suffers as a result.
> >
> > PERST could be asserted at any time.
> > So for your system to not crash/hang by accessing registers in the controller,
> > an EPF driver must be designed with great care to never do any register access
> > when it is not safe...
> >
> > Perhaps the the EPF core should set the state (i.e. init_complete = false,
> > even before calling the deinit callback in EPF driver, and perhaps even add
> > safe-guards against init_complete in some APIs, so that e.g. a set_bar() call
> > cannot trigger a crash because PERST# is asserted.. but even then, it could
> > still be asserted in the middle of set_bar()'s execution.)
> >
> >
> > Looking at the databook, it looks like core_clk is derived from pipe_clk
> > output of the PHY. The PHY will either use external clock or internal clock.
> >
> > 4.6.2 DBI Protocol Transactions
> > it looks like core_clk must be active to read/write the DBI.
> >
> > I really wish those controllers could e.g. change the clock temporarily
> > using a mux, so that it could still perform DBI read/writes when there is
> > not external refclk... Something like pm_sel_aux_clk selecting to use the
> > aux clk instead of core_clk when in low power states.
> > But I don't know the hardware well enough to know if that is possible for
> > the DBI, so that might just be wishful thinking...
>
>
> Looking at the rock5b SBC (rockchip rk3588), the PHY refclk can either
> be taken from
> -a PLL internally from the SoC.
> or
> -an external clock on the SBC.
>
> There does not seem to be an option to get the refclk as an input from
> the PCIe slot. (The refclk can only be output to the PCIe slot.)
>
> So when running two rock5b SBC, you cannot use a common clock for the RC
> and the EP side, you have to use a separate reference clock scheme,
> either SRNS or SRIS.
>
> Since I assume that you use two qcom platforms of the same model
> (I remember that you wrote that you usually test with
> qcom,sdx55-pcie-ep somewhere.)
> Surely this board must be able to supply a reference clock?
> (How else does it send this clock to the EP side?)
>
It is not the same model. It is the same SoC but with different base boards.
FWIW, I'm testing with both SDX55 and SM8450 SoC based boards.
So the Qcom EP has no way to generate refclk internally (I double checked this)
and it has to rely on refclk from either host or a separate clock source.
But in most of the board designs they connect to host refclk by default.
> So... why can't you run in SRNS or SRIS mode, where the EP provides
> it's own clock?
>
As per the discussion I had with Qcom PCIe team, they that said SRIS is only
available at the host side to supply independent clock to the EP. But that
requires changes to the PHY sequence and could also result in preformance drop.
Also this mode is available only on new SoCs but not on older ones like SDX55.
So I don't think this is a viable option.
- Mani
--
மணிவண்ணன் சதாசிவம்
next prev parent reply other threads:[~2024-04-12 6:32 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-01 15:50 [PATCH v2 00/10] PCI: endpoint: Make host reboot handling more robust Manivannan Sadhasivam
2024-04-01 15:50 ` [PATCH v2 01/10] PCI: qcom-ep: Disable resources unconditionally during PERST# assert Manivannan Sadhasivam
2024-04-01 15:50 ` [PATCH v2 02/10] PCI: endpoint: Decouple EPC and PCIe bus specific events Manivannan Sadhasivam
2024-04-02 0:14 ` Damien Le Moal
2024-04-03 14:26 ` Manivannan Sadhasivam
2024-04-04 2:40 ` Damien Le Moal
2024-04-01 15:50 ` [PATCH v2 03/10] PCI: endpoint: Rename core_init() callback in 'struct pci_epc_event_ops' to init() Manivannan Sadhasivam
2024-04-02 10:52 ` Niklas Cassel
2024-04-03 13:46 ` Manivannan Sadhasivam
2024-04-03 15:51 ` Manivannan Sadhasivam
2024-04-01 15:50 ` [PATCH v2 04/10] PCI: epf-test: Refactor pci_epf_test_unbind() function Manivannan Sadhasivam
2024-04-01 15:50 ` [PATCH v2 05/10] PCI: epf-{mhi/test}: Move DMA initialization to EPC init callback Manivannan Sadhasivam
2024-04-01 15:50 ` [PATCH v2 06/10] PCI: endpoint: Introduce EPC 'deinit' event and notify the EPF drivers Manivannan Sadhasivam
2024-04-01 15:50 ` [PATCH v2 07/10] PCI: dwc: ep: Add a generic dw_pcie_ep_linkdown() API to handle Link Down event Manivannan Sadhasivam
2024-04-02 10:52 ` Niklas Cassel
2024-04-01 15:50 ` [PATCH v2 08/10] PCI: qcom-ep: Use the " Manivannan Sadhasivam
2024-04-01 15:50 ` [PATCH v2 09/10] PCI: epf-test: Handle " Manivannan Sadhasivam
2024-04-01 15:50 ` [PATCH v2 10/10] PCI: qcom: Implement shutdown() callback to properly reset the endpoint devices Manivannan Sadhasivam
2024-04-02 11:18 ` Niklas Cassel
2024-04-03 13:32 ` Manivannan Sadhasivam
2024-04-03 20:03 ` Niklas Cassel
2024-04-09 13:31 ` Bjorn Helgaas
2024-04-10 10:54 ` Manivannan Sadhasivam
2024-04-10 14:52 ` Niklas Cassel
2024-04-10 21:10 ` Niklas Cassel
2024-04-12 6:32 ` Manivannan Sadhasivam [this message]
2024-04-02 9:41 ` [PATCH v2 00/10] PCI: endpoint: Make host reboot handling more robust Niklas Cassel
2024-04-03 13:48 ` Manivannan Sadhasivam
2024-04-08 9:49 ` Niklas Cassel
2024-04-02 10:52 ` Niklas Cassel
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=20240412063242.GA2712@thinkpad \
--to=manivannan.sadhasivam@linaro.org \
--cc=bhelgaas@google.com \
--cc=cassel@kernel.org \
--cc=jingoohan1@gmail.com \
--cc=jonathanh@nvidia.com \
--cc=kishon@kernel.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=linux-tegra@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mhi@lists.linux.dev \
--cc=robh@kernel.org \
--cc=thierry.reding@gmail.com \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).