On Wed, 15 Apr 2020 18:03:47 +0200
Pali Rohár <pali@xxxxxxxxxx> wrote:
> Marvell version of u-boot for Espressobin set pcie reset pin to gpio and
> toggle it when initializing u-boot aardvark driver.
>
> To not depend on bootloader version and state of Espressobin HW, route pcie
> reset pin to gpio function and define reset-gpios also in kernel. So pcie
> aardvark driver can trigger needed reset.
>
> Turris MOX dts file has already defined reset-gpios and configured pcie
> reset pin to gpio function, so unify Espressobin and Turris MOX dts files.
>
Lets specify in the commit message the other information we found out.
This pin, according to specification, can be in two modes:
- GPIO (controlled by the GPIO subsystem)
- EP_PCIE1_Resetn (which should be controlled by PCIe subsystem)
Commit f4c7d053d7f7 ("PCI: aardvark: Wait for endpoint to be ready
before training link") says that when pinctrl driver changes this
pin's mode from GPIO to PCIe, the signal is asserted for a little
while. Since this pin is in GPIO mode after reset (and if U-Boot probes
its own pci-aardvark driver, it also leaves it in GPIO mode), this
always happens.
We found out that we are unable to control this pin when in PCIe mode.
There is a register in the PCIe registers of this SOC, called
PERSTN_GPIO_EN (D0088004[3]), but changing the value of this register
does not change the pin output when measuring with voltmeter.
We do not know if this is a bug in the SOC, or if it works only when
PCIe controller is in a certain state.
So now the state of things is that the PERST signal is issued, but only
by chance, due to pinctrl machinations mentioned above. We think that
the PERST signal should be instead issued in a known way from the
pci-aardvark driver, therefore we change the function of this pin to
GPIO, so that the driver can issue it via GPIO subsystem.
Some of this explanation should also go as a comment into the dtsi file.
