Message-ID: <ZhcAKSJCQag6AX09@ryzen>
Date: Wed, 10 Apr 2024 23:10:01 +0200
From: Niklas Cassel <cassel@...nel.org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
Cc: Lorenzo Pieralisi <lpieralisi@...nel.org>,
	Krzysztof Wilczyński <kw@...ux.com>,
	Rob Herring <robh@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>,
	Kishon Vijay Abraham I <kishon@...nel.org>,
	Thierry Reding <thierry.reding@...il.com>,
	Jonathan Hunter <jonathanh@...dia.com>,
	Jingoo Han <jingoohan1@...il.com>, linux-pci@...r.kernel.org,
	linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
	mhi@...ts.linux.dev, linux-tegra@...r.kernel.org
Subject: Re: [PATCH v2 10/10] PCI: qcom: Implement shutdown() callback to
 properly reset the endpoint devices

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?)

So... why can't you run in SRNS or SRIS mode, where the EP provides
it's own clock?


Kind regards,
Niklas

Powered by blists - more mailing lists