imx8mp_evk based board pcie clk is on by default

[brownls]

On a custom board based on the imx8mp we have pcie up and running and can install pcie adapters and use them without issue.  However, we are using the internal clock and need it to be off by default and to be able to turn it on when a board is plugged in.  Without a pcie board plugged in we get:

00:00.0 PCI bridge: Synopsys, Inc. DWC_usb3 / PCIe bridge (rev 01)

We believe that the clock should be off and we would probably not see the bridge until a board is plugged in and the clock is turned on.  We have the gpio for the clkreq assigned to:

MX8MP_IOMUXC_I2C4_SCL__PCIE_CLKREQ_B

However, we cannot see a time when the clock is off.  How do we set the clock to off by default?

[brownls]

The only way to keep the clock from starting we found was to remove support for PCIe or modify the driver to check for the CLKREQ# line to see if the module is there and if not then to drop out of the driver before asking to start the clock.  Since uboot has the ability to check the CLKREQ# as a gpio and correctly determine if the card is present we can load the dts with PCIe support or not based on the result.  It's not pretty but it doesn't require modifying kernels.  However, there is an errata that says if the power is on to the PCIe and the clock is not running it will ultimately deteriorate the hardware.  So we are examining the possibility of not powering the PCIe if the module is not present (which will have the same effect as not having a PCIe driver and conform to the errata restrictions.)  But this is still in discussion.

[Bio_TICFSL]

Hello,

From the driver's point of view, the pci-imx driver will call dw_pcie_wait_for_link(drivers/pci/controller/dwc/pcie-designware.c) to wait link up. These pci driver functions are very stable. So I think it might still be a hardware thing. Maybe the timing is out of sync causing the pci core to go down when this issue happen. You need verify the stability and synchronization of clocks when this issue occurs. There must be something unstable from hardware and then case core reset or you have to build with the modifications at init.

Regards

[brownls]

We see this call to wait and the call to wait times out and generates:

imx6q-pcie 33800000.pcie: Phy link never came up
imx6q-pcie 33800000.pcie: Phy link never came up
​
Which is followed by bringing up the bridge:
imx6q-pcie 33800000.pcie: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [bus 00-ff]
pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
pci_bus 0000:00: root bus resource [mem 0x18000000-0x1fefffff]
pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
pci 0000:00:00.0: supports D1
pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold
pci 0000:00:00.0: BAR 0: assigned [mem 0x18000000-0x180fffff]
pci 0000:00:00.0: BAR 6: assigned [mem 0x18100000-0x1810ffff pref]
pci 0000:00:00.0: PCI bridge to [bus 01-ff]
pcieport 0000:00:00.0: PME: Signaling with IRQ 230

And then the kernel continues the boot.  I would think the phy link not coming up would stop the probe from loading the bridge but I'm not that familiar with the SOP here.  Will continue to look at the driver infrastructure...