On 11/20/18 1:12 PM, Trent Piepho wrote:
On Tue, 2018-11-20 at 10:41 -0700, Stephen Warren wrote:
On 11/20/18 10:30 AM, Vidya Sagar wrote:
Some implementations of the DWC PCIe endpoint controller do not allow access
to DBI registers until the attached host has started REFCLK, released PERST, and
the endpoint driver has initialized clocking of the DBI registers based on that.
a) Update every existing DWC EP driver to set ep->hw_regs_available
during probe/initialization.
I believe on IMX7d, it is also the case that access to DWC PCIe
controller without PCI REFCLK causes a system hang.
We had a design with a mistake that didn't provide a REFCLK, and a hang
starting the dwc controller is what happened. It was fixed with an
external PCIe clock chip to provide the REFCLK input (as imx7d is
designed to expect), which, for the clock chip we used and the rest of
the external clock tree, means the REFCLK is there before Linux boots.
But there's no reason that must be the case. Maybe the external clock
chip is I2C controlled and needs to be enabled? And maybe I only want
to do that if PCI-e is to be used?
So I don't think if this is a specific problem for nvidia.
Good to hear that this could be more generally useful.
But I wonder, why can't you add REFCLK to the Linux clock tree and the
dwc bindings, and have the dwc driver EPROBE_DEFER if it can't
clk_prepare_enable() the refclk?
In our systems, we expect REFCLK to be provided by the system that
contains the PCIe root port. There is no communication channel between
the endpoint system and the root port system besides PCIe, so there's no
way we could implement such clock control. The endpoint system must boot
first, so that when the root port system boots, it is ready to be
enumerated on the PCIe bus. To make this work, the Tegra endpoint driver
calls dw_pcie_ep_set_regs_available() when it sees PERST release, and
hopes to complete the DWC programming before the root port system begins
PCIe enumeration.
