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 -- மணிவண்ணன் சதாசிவம்
