From: Minda Chen <minda.chen@starfivetech.com>
To: "Conor Dooley" <conor@kernel.org>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Rob Herring" <robh+dt@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Daire McNamara" <daire.mcnamara@microchip.com>,
"Emil Renner Berthing" <emil.renner.berthing@canonical.com>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-riscv@lists.infradead.org, linux-pci@vger.kernel.org,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Philipp Zabel <p.zabel@pengutronix.de>,
Mason Huo <mason.huo@starfivetech.com>,
Leyfoon Tan <leyfoon.tan@starfivetech.com>,
Kevin Xie <kevin.xie@starfivetech.com>,
Minda Chen <minda.chen@starfivetech.com>
Subject: [PATCH v14,RESEND 20/22] PCI: Add PCIE_RESET_CONFIG_DEVICE_WAIT_MS waiting time value
Date: Mon, 29 Jan 2024 09:01:40 +0800 [thread overview]
Message-ID: <20240129010142.3732-5-minda.chen@starfivetech.com> (raw)
In-Reply-To: <20240129010142.3732-1-minda.chen@starfivetech.com>
From: Kevin Xie <kevin.xie@starfivetech.com>
Add the PCIE_RESET_CONFIG_DEVICE_WAIT_MS macro to define the minimum
waiting time between exit from a conventional reset and sending the
first configuration request to the device.
As described in PCI base specification r6.0, section 6.6.1 <Conventional
Reset>, there are two different use cases of the value:
- "With a Downstream Port that does not support Link speeds greater
than 5.0 GT/s, software must wait a minimum of 100 ms following exit
from a Conventional Reset before sending a Configuration Request to
the device immediately below that Port."
- "With a Downstream Port that supports Link speeds greater than
5.0 GT/s, software must wait a minimum of 100 ms after Link training
completes before sending a Configuration Request to the device
immediately below that Port."
Signed-off-by: Kevin Xie <kevin.xie@starfivetech.com>
Reviewed-by: Mason Huo <mason.huo@starfivetech.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
---
drivers/pci/pci.h | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 2336a8d1edab..bd38b3a69d8b 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -22,6 +22,22 @@
*/
#define PCIE_PME_TO_L2_TIMEOUT_US 10000
+/*
+ * As described in PCI base specification r6.0, section 6.6.1 <Conventional
+ * Reset>, there are two different use cases of the value:
+ *
+ * - "With a Downstream Port that does not support Link speeds greater
+ * than 5.0 GT/s, software must wait a minimum of 100 ms following exit
+ * from a Conventional Reset before sending a Configuration Request to
+ * the device immediately below that Port."
+ *
+ * - "With a Downstream Port that supports Link speeds greater than
+ * 5.0 GT/s, software must wait a minimum of 100 ms after Link training
+ * completes before sending a Configuration Request to the device
+ * immediately below that Port."
+ */
+#define PCIE_RESET_CONFIG_DEVICE_WAIT_MS 100
+
extern const unsigned char pcie_link_speed[];
extern bool pci_early_dump;
--
2.17.1
WARNING: multiple messages have this Message-ID (diff)
From: Minda Chen <minda.chen@starfivetech.com>
To: "Conor Dooley" <conor@kernel.org>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Rob Herring" <robh+dt@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Daire McNamara" <daire.mcnamara@microchip.com>,
"Emil Renner Berthing" <emil.renner.berthing@canonical.com>,
"Krzysztof Kozlowski" <krzysztof.kozlowski+dt@linaro.org>
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-riscv@lists.infradead.org, linux-pci@vger.kernel.org,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Philipp Zabel <p.zabel@pengutronix.de>,
Mason Huo <mason.huo@starfivetech.com>,
Leyfoon Tan <leyfoon.tan@starfivetech.com>,
Kevin Xie <kevin.xie@starfivetech.com>,
Minda Chen <minda.chen@starfivetech.com>
Subject: [PATCH v14,RESEND 20/22] PCI: Add PCIE_RESET_CONFIG_DEVICE_WAIT_MS waiting time value
Date: Mon, 29 Jan 2024 09:01:40 +0800 [thread overview]
Message-ID: <20240129010142.3732-5-minda.chen@starfivetech.com> (raw)
In-Reply-To: <20240129010142.3732-1-minda.chen@starfivetech.com>
From: Kevin Xie <kevin.xie@starfivetech.com>
Add the PCIE_RESET_CONFIG_DEVICE_WAIT_MS macro to define the minimum
waiting time between exit from a conventional reset and sending the
first configuration request to the device.
As described in PCI base specification r6.0, section 6.6.1 <Conventional
Reset>, there are two different use cases of the value:
- "With a Downstream Port that does not support Link speeds greater
than 5.0 GT/s, software must wait a minimum of 100 ms following exit
from a Conventional Reset before sending a Configuration Request to
the device immediately below that Port."
- "With a Downstream Port that supports Link speeds greater than
5.0 GT/s, software must wait a minimum of 100 ms after Link training
completes before sending a Configuration Request to the device
immediately below that Port."
Signed-off-by: Kevin Xie <kevin.xie@starfivetech.com>
Reviewed-by: Mason Huo <mason.huo@starfivetech.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
---
drivers/pci/pci.h | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 2336a8d1edab..bd38b3a69d8b 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -22,6 +22,22 @@
*/
#define PCIE_PME_TO_L2_TIMEOUT_US 10000
+/*
+ * As described in PCI base specification r6.0, section 6.6.1 <Conventional
+ * Reset>, there are two different use cases of the value:
+ *
+ * - "With a Downstream Port that does not support Link speeds greater
+ * than 5.0 GT/s, software must wait a minimum of 100 ms following exit
+ * from a Conventional Reset before sending a Configuration Request to
+ * the device immediately below that Port."
+ *
+ * - "With a Downstream Port that supports Link speeds greater than
+ * 5.0 GT/s, software must wait a minimum of 100 ms after Link training
+ * completes before sending a Configuration Request to the device
+ * immediately below that Port."
+ */
+#define PCIE_RESET_CONFIG_DEVICE_WAIT_MS 100
+
extern const unsigned char pcie_link_speed[];
extern bool pci_early_dump;
--
2.17.1
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2024-01-29 1:02 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-29 1:01 [PATCH v14,RESEND 16/22] PCI: microchip: Move IRQ functions to pcie-plda-host.c Minda Chen
2024-01-29 1:01 ` Minda Chen
2024-01-29 1:01 ` [PATCH v14,RESEND 17/22] PCI: plda: Add event bitmap field to struct plda_pcie_rp Minda Chen
2024-01-29 1:01 ` Minda Chen
2024-01-29 1:01 ` [PATCH v14,RESEND 18/22] PCI: plda: Add host init/deinit and map bus functions Minda Chen
2024-01-29 1:01 ` Minda Chen
2024-01-29 1:01 ` [PATCH v14,RESEND 19/22] dt-bindings: PCI: Add StarFive JH7110 PCIe controller Minda Chen
2024-01-29 1:01 ` Minda Chen
2024-01-29 22:21 ` Rob Herring
2024-01-29 22:21 ` Rob Herring
2024-01-30 15:19 ` Rob Herring
2024-01-30 15:19 ` Rob Herring
2024-01-31 10:07 ` Minda Chen
2024-01-31 10:07 ` Minda Chen
2024-01-29 1:01 ` Minda Chen [this message]
2024-01-29 1:01 ` [PATCH v14,RESEND 20/22] PCI: Add PCIE_RESET_CONFIG_DEVICE_WAIT_MS waiting time value Minda Chen
2024-01-29 1:01 ` [PATCH v14,RESEND 21/22] PCI: starfive: Add JH7110 PCIe controller Minda Chen
2024-01-29 1:01 ` Minda Chen
2024-01-29 1:01 ` [PATCH v14,RESEND 22/22] riscv: dts: starfive: add PCIe dts configuration for JH7110 Minda Chen
2024-01-29 1:01 ` Minda Chen
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=20240129010142.3732-5-minda.chen@starfivetech.com \
--to=minda.chen@starfivetech.com \
--cc=aou@eecs.berkeley.edu \
--cc=bhelgaas@google.com \
--cc=conor@kernel.org \
--cc=daire.mcnamara@microchip.com \
--cc=devicetree@vger.kernel.org \
--cc=emil.renner.berthing@canonical.com \
--cc=kevin.xie@starfivetech.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=kw@linux.com \
--cc=leyfoon.tan@starfivetech.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=lpieralisi@kernel.org \
--cc=mason.huo@starfivetech.com \
--cc=p.zabel@pengutronix.de \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=robh+dt@kernel.org \
/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.