archive mirror
 help / color / mirror / Atom feed
From: Marek Behun <>
To: "Pali Rohár" <>
Cc: Jason Cooper <>, Andrew Lunn <>,
	Gregory Clement <>,
	Sebastian Hesselbarth <>,
	Rob Herring <>,
	Thomas Petazzoni <>,
	Lorenzo Pieralisi <>,
	Andrew Murray <>,
	Bjorn Helgaas <>,
	Remi Pommarel <>,
	Tomasz Maciej Nowak <>,
	Xogium <>,,,
Subject: Re: [PATCH 7/8] dts: aardvark: Route pcie reset pin to gpio function and define reset-gpios for pcie
Date: Sun, 19 Apr 2020 05:54:14 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, 15 Apr 2020 18:03:47 +0200
Pali Rohár <> 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.

  reply	other threads:[~2020-04-19  3:54 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-15 16:00 [PATCH 0/8] PCI: aardvark: Fix support for Turris MOX and Compex wifi cards Pali Rohár
2020-04-15 16:00 ` [PATCH 1/8] PCI: aardvark: Set controller speed from Device Tree max-link-speed Pali Rohár
2020-04-15 16:00 ` [PATCH 2/8] dts: espressobin: Define max-link-speed for pcie0 Pali Rohár
2020-04-19  3:19   ` Marek Behun
2020-04-15 16:00 ` [PATCH 3/8] PCI: aardvark: Start link training immediately after enabling link training Pali Rohár
2020-04-15 16:00 ` [PATCH 4/8] PCI: aardvark: Do not overwrite Link Status register and ASPM Control bits in Link Control register Pali Rohár
2020-04-15 16:03 ` [PATCH 5/8] PCI: aardvark: Set final controller speed based on negotiated link speed Pali Rohár
2020-04-19  3:17   ` Marek Behun
2020-04-15 16:03 ` [PATCH 6/8] PCI: aardvark: Add support for issuing PERST via GPIO Pali Rohár
2020-04-19  3:23   ` Marek Behun
2020-04-15 16:03 ` [PATCH 7/8] dts: aardvark: Route pcie reset pin to gpio function and define reset-gpios for pcie Pali Rohár
2020-04-19  3:54   ` Marek Behun [this message]
2020-04-15 16:03 ` [PATCH 8/8] PCI: aardvark: Add FIXME for code which access PCIE_CORE_CMD_STATUS_REG Pali Rohár
2020-04-15 16:18   ` Pali Rohár
2020-04-16 15:50 ` [PATCH 0/8] PCI: aardvark: Fix support for Turris MOX and Compex wifi cards Tomasz Maciej Nowak
2020-04-19  4:01 ` Marek Behun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).