All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Damien Le Moal <dlemoal@kernel.org>
Cc: "Shawn Lin" <shawn.lin@rock-chips.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Heiko Stuebner" <heiko@sntech.de>,
	linux-pci@vger.kernel.org,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	linux-rockchip@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2] PCI: rockchip-host: Fix rockchip_pcie_host_init_port() PERST# handling
Date: Tue, 9 Apr 2024 11:15:58 -0500	[thread overview]
Message-ID: <20240409161558.GA2077808@bhelgaas> (raw)
In-Reply-To: <20240330035043.1546087-1-dlemoal@kernel.org>

On Sat, Mar 30, 2024 at 12:50:43PM +0900, Damien Le Moal wrote:
> The PCIe specifications (PCI Express Electromechanical Specification rev
> 2.0, section 2.6.2) mandate that the PERST# signal must remain asserted
> for at least 100 usec (Tperst-clk) after the PCIe reference clock
> becomes stable (if a reference clock is supplied), for at least 100 msec
> after the power is stable (Tpvperl).

Reference current spec, e.g., "PCIe CEM r5.1, sec 2.9.2" and a note
about why you mention two parameters here but the code change only
uses one of them.

> In addition, the PCI Express Base SPecification Rev 2.0, section 6.6.1
> state that the host should wait for at least 100 msec from the end of a
> conventional reset (PERST# is de-asserted) before accessing the
> configuration space of the attached device.

Current spec, e.g., "PCIe r6.0, sec 6.6.1".

> Modify rockchip_pcie_host_init_port() by adding two 100ms sleep, one
> before and after bringing back PESRT signal to high using the ep_gpio
> GPIO. Comments are also added to clarify this behavior.

s/PESRT/PERST#/

This is two separate changes that really would be better as separate
patches.

> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
> ---
> 
> Changes from v1:
>  - Add more specification details to the commit message.
>  - Add missing msleep(100) after PERST# is deasserted.
> 
>  drivers/pci/controller/pcie-rockchip-host.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/pci/controller/pcie-rockchip-host.c b/drivers/pci/controller/pcie-rockchip-host.c
> index 300b9dc85ecc..ff2fa27bd883 100644
> --- a/drivers/pci/controller/pcie-rockchip-host.c
> +++ b/drivers/pci/controller/pcie-rockchip-host.c
> @@ -294,6 +294,7 @@ static int rockchip_pcie_host_init_port(struct rockchip_pcie *rockchip)
>  	int err, i = MAX_LANE_NUM;
>  	u32 status;
>  
> +	/* Assert PERST */
>  	gpiod_set_value_cansleep(rockchip->ep_gpio, 0);
>  
>  	err = rockchip_pcie_init_port(rockchip);
> @@ -322,8 +323,19 @@ static int rockchip_pcie_host_init_port(struct rockchip_pcie *rockchip)
>  	rockchip_pcie_write(rockchip, PCIE_CLIENT_LINK_TRAIN_ENABLE,
>  			    PCIE_CLIENT_CONFIG);
>  
> +	/*
> +	 * PCIe CME specifications mandate that PERST be asserted for at
> +	 * least 100ms after power is stable.
> +	 */

Remove comment completely (given use of PCIE_T_PVPERL_MS below).

> +	msleep(100);

s/100/PCIE_T_PVPERL_MS/

>  	gpiod_set_value_cansleep(rockchip->ep_gpio, 1);
>  
> +	/*
> +	 * PCIe base specifications rev 2.0 mandate that the host wait for
> +	 * 100ms after completion of a conventional reset.
> +	 */
> +	msleep(100);

Please add a #define for this since it's generic across all PCIe, not
just Rockchip.

I don't think the PCIe spec actually names this parameter.  It's
similar to T_rhfa (Conventional PCI r3.0, sec 4.3.2), although I think
devices must be ready to accept config cycles after T_rhfa.

This delay is a little different because IIUC, a PCIe device doesn't
have to be "Configuration Ready"; after 100ms, it only has to be able
to respond with a "Request Retry Status" completion if it isn't
Configuration Ready yet.

So I think we should add something like

  #define PCIE_T_RRS_READY_MS   100

to drivers/pci/pci.h for this case.

>  	/* 500ms timeout value should be enough for Gen1/2 training */
>  	err = readl_poll_timeout(rockchip->apb_base + PCIE_CLIENT_BASIC_STATUS1,
>  				 status, PCIE_LINK_UP(status), 20,
> -- 
> 2.44.0
> 

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Damien Le Moal <dlemoal@kernel.org>
Cc: "Shawn Lin" <shawn.lin@rock-chips.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Heiko Stuebner" <heiko@sntech.de>,
	linux-pci@vger.kernel.org,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	linux-rockchip@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2] PCI: rockchip-host: Fix rockchip_pcie_host_init_port() PERST# handling
Date: Tue, 9 Apr 2024 11:15:58 -0500	[thread overview]
Message-ID: <20240409161558.GA2077808@bhelgaas> (raw)
In-Reply-To: <20240330035043.1546087-1-dlemoal@kernel.org>

On Sat, Mar 30, 2024 at 12:50:43PM +0900, Damien Le Moal wrote:
> The PCIe specifications (PCI Express Electromechanical Specification rev
> 2.0, section 2.6.2) mandate that the PERST# signal must remain asserted
> for at least 100 usec (Tperst-clk) after the PCIe reference clock
> becomes stable (if a reference clock is supplied), for at least 100 msec
> after the power is stable (Tpvperl).

Reference current spec, e.g., "PCIe CEM r5.1, sec 2.9.2" and a note
about why you mention two parameters here but the code change only
uses one of them.

> In addition, the PCI Express Base SPecification Rev 2.0, section 6.6.1
> state that the host should wait for at least 100 msec from the end of a
> conventional reset (PERST# is de-asserted) before accessing the
> configuration space of the attached device.

Current spec, e.g., "PCIe r6.0, sec 6.6.1".

> Modify rockchip_pcie_host_init_port() by adding two 100ms sleep, one
> before and after bringing back PESRT signal to high using the ep_gpio
> GPIO. Comments are also added to clarify this behavior.

s/PESRT/PERST#/

This is two separate changes that really would be better as separate
patches.

> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
> ---
> 
> Changes from v1:
>  - Add more specification details to the commit message.
>  - Add missing msleep(100) after PERST# is deasserted.
> 
>  drivers/pci/controller/pcie-rockchip-host.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/pci/controller/pcie-rockchip-host.c b/drivers/pci/controller/pcie-rockchip-host.c
> index 300b9dc85ecc..ff2fa27bd883 100644
> --- a/drivers/pci/controller/pcie-rockchip-host.c
> +++ b/drivers/pci/controller/pcie-rockchip-host.c
> @@ -294,6 +294,7 @@ static int rockchip_pcie_host_init_port(struct rockchip_pcie *rockchip)
>  	int err, i = MAX_LANE_NUM;
>  	u32 status;
>  
> +	/* Assert PERST */
>  	gpiod_set_value_cansleep(rockchip->ep_gpio, 0);
>  
>  	err = rockchip_pcie_init_port(rockchip);
> @@ -322,8 +323,19 @@ static int rockchip_pcie_host_init_port(struct rockchip_pcie *rockchip)
>  	rockchip_pcie_write(rockchip, PCIE_CLIENT_LINK_TRAIN_ENABLE,
>  			    PCIE_CLIENT_CONFIG);
>  
> +	/*
> +	 * PCIe CME specifications mandate that PERST be asserted for at
> +	 * least 100ms after power is stable.
> +	 */

Remove comment completely (given use of PCIE_T_PVPERL_MS below).

> +	msleep(100);

s/100/PCIE_T_PVPERL_MS/

>  	gpiod_set_value_cansleep(rockchip->ep_gpio, 1);
>  
> +	/*
> +	 * PCIe base specifications rev 2.0 mandate that the host wait for
> +	 * 100ms after completion of a conventional reset.
> +	 */
> +	msleep(100);

Please add a #define for this since it's generic across all PCIe, not
just Rockchip.

I don't think the PCIe spec actually names this parameter.  It's
similar to T_rhfa (Conventional PCI r3.0, sec 4.3.2), although I think
devices must be ready to accept config cycles after T_rhfa.

This delay is a little different because IIUC, a PCIe device doesn't
have to be "Configuration Ready"; after 100ms, it only has to be able
to respond with a "Request Retry Status" completion if it isn't
Configuration Ready yet.

So I think we should add something like

  #define PCIE_T_RRS_READY_MS   100

to drivers/pci/pci.h for this case.

>  	/* 500ms timeout value should be enough for Gen1/2 training */
>  	err = readl_poll_timeout(rockchip->apb_base + PCIE_CLIENT_BASIC_STATUS1,
>  				 status, PCIE_LINK_UP(status), 20,
> -- 
> 2.44.0
> 

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Damien Le Moal <dlemoal@kernel.org>
Cc: "Shawn Lin" <shawn.lin@rock-chips.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Heiko Stuebner" <heiko@sntech.de>,
	linux-pci@vger.kernel.org,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	linux-rockchip@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2] PCI: rockchip-host: Fix rockchip_pcie_host_init_port() PERST# handling
Date: Tue, 9 Apr 2024 11:15:58 -0500	[thread overview]
Message-ID: <20240409161558.GA2077808@bhelgaas> (raw)
In-Reply-To: <20240330035043.1546087-1-dlemoal@kernel.org>

On Sat, Mar 30, 2024 at 12:50:43PM +0900, Damien Le Moal wrote:
> The PCIe specifications (PCI Express Electromechanical Specification rev
> 2.0, section 2.6.2) mandate that the PERST# signal must remain asserted
> for at least 100 usec (Tperst-clk) after the PCIe reference clock
> becomes stable (if a reference clock is supplied), for at least 100 msec
> after the power is stable (Tpvperl).

Reference current spec, e.g., "PCIe CEM r5.1, sec 2.9.2" and a note
about why you mention two parameters here but the code change only
uses one of them.

> In addition, the PCI Express Base SPecification Rev 2.0, section 6.6.1
> state that the host should wait for at least 100 msec from the end of a
> conventional reset (PERST# is de-asserted) before accessing the
> configuration space of the attached device.

Current spec, e.g., "PCIe r6.0, sec 6.6.1".

> Modify rockchip_pcie_host_init_port() by adding two 100ms sleep, one
> before and after bringing back PESRT signal to high using the ep_gpio
> GPIO. Comments are also added to clarify this behavior.

s/PESRT/PERST#/

This is two separate changes that really would be better as separate
patches.

> Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
> ---
> 
> Changes from v1:
>  - Add more specification details to the commit message.
>  - Add missing msleep(100) after PERST# is deasserted.
> 
>  drivers/pci/controller/pcie-rockchip-host.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/pci/controller/pcie-rockchip-host.c b/drivers/pci/controller/pcie-rockchip-host.c
> index 300b9dc85ecc..ff2fa27bd883 100644
> --- a/drivers/pci/controller/pcie-rockchip-host.c
> +++ b/drivers/pci/controller/pcie-rockchip-host.c
> @@ -294,6 +294,7 @@ static int rockchip_pcie_host_init_port(struct rockchip_pcie *rockchip)
>  	int err, i = MAX_LANE_NUM;
>  	u32 status;
>  
> +	/* Assert PERST */
>  	gpiod_set_value_cansleep(rockchip->ep_gpio, 0);
>  
>  	err = rockchip_pcie_init_port(rockchip);
> @@ -322,8 +323,19 @@ static int rockchip_pcie_host_init_port(struct rockchip_pcie *rockchip)
>  	rockchip_pcie_write(rockchip, PCIE_CLIENT_LINK_TRAIN_ENABLE,
>  			    PCIE_CLIENT_CONFIG);
>  
> +	/*
> +	 * PCIe CME specifications mandate that PERST be asserted for at
> +	 * least 100ms after power is stable.
> +	 */

Remove comment completely (given use of PCIE_T_PVPERL_MS below).

> +	msleep(100);

s/100/PCIE_T_PVPERL_MS/

>  	gpiod_set_value_cansleep(rockchip->ep_gpio, 1);
>  
> +	/*
> +	 * PCIe base specifications rev 2.0 mandate that the host wait for
> +	 * 100ms after completion of a conventional reset.
> +	 */
> +	msleep(100);

Please add a #define for this since it's generic across all PCIe, not
just Rockchip.

I don't think the PCIe spec actually names this parameter.  It's
similar to T_rhfa (Conventional PCI r3.0, sec 4.3.2), although I think
devices must be ready to accept config cycles after T_rhfa.

This delay is a little different because IIUC, a PCIe device doesn't
have to be "Configuration Ready"; after 100ms, it only has to be able
to respond with a "Request Retry Status" completion if it isn't
Configuration Ready yet.

So I think we should add something like

  #define PCIE_T_RRS_READY_MS   100

to drivers/pci/pci.h for this case.

>  	/* 500ms timeout value should be enough for Gen1/2 training */
>  	err = readl_poll_timeout(rockchip->apb_base + PCIE_CLIENT_BASIC_STATUS1,
>  				 status, PCIE_LINK_UP(status), 20,
> -- 
> 2.44.0
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2024-04-09 16:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-30  3:50 [PATCH v2] PCI: rockchip-host: Fix rockchip_pcie_host_init_port() PERST# handling Damien Le Moal
2024-03-30  3:50 ` Damien Le Moal
2024-03-30  3:50 ` Damien Le Moal
2024-03-31 19:34 ` Dragan Simic
2024-03-31 19:34   ` Dragan Simic
2024-03-31 19:34   ` Dragan Simic
2024-04-01  6:59   ` Damien Le Moal
2024-04-01  6:59     ` Damien Le Moal
2024-04-01  6:59     ` Damien Le Moal
2024-04-01 17:28     ` Dragan Simic
2024-04-01 17:28       ` Dragan Simic
2024-04-01 17:28       ` Dragan Simic
2024-04-09 16:15 ` Bjorn Helgaas [this message]
2024-04-09 16:15   ` Bjorn Helgaas
2024-04-09 16:15   ` Bjorn Helgaas

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20240409161558.GA2077808@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=dlemoal@kernel.org \
    --cc=heiko@sntech.de \
    --cc=kw@linux.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=lpieralisi@kernel.org \
    --cc=shawn.lin@rock-chips.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.