public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Thierry Reding <thierry.reding@kernel.org>
Cc: "Bjorn Helgaas" <bhelgaas@google.com>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
	"Manivannan Sadhasivam" <mani@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Jon Hunter" <jonathanh@nvidia.com>,
	linux-pci@vger.kernel.org, devicetree@vger.kernel.org,
	linux-tegra@vger.kernel.org
Subject: Re: [PATCH 4/5] PCI: tegra: Add Tegra264 support
Date: Thu, 19 Mar 2026 12:46:39 -0500	[thread overview]
Message-ID: <20260319174639.GA515667@bhelgaas> (raw)
In-Reply-To: <20260319160110.2131954-5-thierry.reding@kernel.org>

On Thu, Mar 19, 2026 at 05:01:08PM +0100, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
> 
> Add a driver for the PCIe controller found on NVIDIA Tegra264 SoCs. The
> driver is very small, with its main purpose being to set up the address
> translation registers and then creating a standard PCI host using ECAM.
> 
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
>  drivers/pci/controller/Kconfig         |   8 +
>  drivers/pci/controller/Makefile        |   1 +
>  drivers/pci/controller/pcie-tegra264.c | 506 +++++++++++++++++++++++++
>  3 files changed, 515 insertions(+)
>  create mode 100644 drivers/pci/controller/pcie-tegra264.c
> 
> diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
> index e72ac6934379..36abee65eca1 100644
> --- a/drivers/pci/controller/Kconfig
> +++ b/drivers/pci/controller/Kconfig
> @@ -257,6 +257,14 @@ config PCI_TEGRA
>  	  Say Y here if you want support for the PCIe host controller found
>  	  on NVIDIA Tegra SoCs.

Should the PCI_TEGRA menu item ("NVIDIA Tegra PCIe controller") and
this text be clarified somehow to make them clearly separate?

> +config PCIE_TEGRA264
> +	bool "NVIDIA Tegra264 PCIe controller"
> +	depends on ARCH_TEGRA || COMPILE_TEST
> +	depends on PCI_MSI
> +	help
> +	  Say Y here if you want support for the PCIe host controller found
> +	  on NVIDIA Tegra264 SoCs.

> + * PCIe host controller driver for Tegra264 SoC
> + *
> + * Author: Manikanta Maddireddy <mmaddireddy@nvidia.com>

Manikanta doesn't appear in the signed-off-by or other tags above.
Not really an issue for me; just a question of whether this is
accurate.

> +#define PCIE_LINK_UP_DELAY	10000	/* 10 msec */
> +#define PCIE_LINK_UP_TIMEOUT	1000000	/* 1 s */

Use something from drivers/pci/pci.h if possible.  If not, please add
units suffixes to the name, e.g., it looks like these are in "_US".

PCIE_LINK_WAIT_MAX_RETRIES and PCIE_LINK_WAIT_SLEEP_MS look like
they're used in similar ways in other drivers.

> +/* XAL registers */
> +#define XAL_RC_ECAM_BASE_HI			0x00
> +#define XAL_RC_ECAM_BASE_LO			0x04
> +#define XAL_RC_ECAM_BUSMASK			0x08
> +#define XAL_RC_IO_BASE_HI			0x0c
> ...
> +#define XTL_RC_MGMT_CLOCK_CONTROL		0x47C

Inconsistent use of upper/lower-case hex with above.

> +struct tegra264_pcie {
> +	struct device *dev;
> +	bool link_state;

"link_state" being true/false doesn't read quite right because
true/false isn't a "state".  I guess true means "link is up"?

> +static int tegra264_pcie_parse_dt(struct tegra264_pcie *pcie)
> +{
> +	int err;
> +
> +	pcie->wake_gpio = devm_gpiod_get_optional(pcie->dev, "nvidia,pex-wake",
> +						  GPIOD_IN);
> +	if (IS_ERR(pcie->wake_gpio))
> +		return PTR_ERR(pcie->wake_gpio);
> +
> +	if (pcie->wake_gpio) {
> +		device_init_wakeup(pcie->dev, true);
> +
> +		err = gpiod_to_irq(pcie->wake_gpio);
> +		if (err < 0) {
> +			dev_err(pcie->dev, "failed to get wake IRQ: %d\n", err);

Does %pe work here (and below)?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/core-api/printk-formats.rst?id=v6.19#n96

> +static void tegra264_pcie_bpmp_set_rp_state(struct tegra264_pcie *pcie)
> +{
> +	struct tegra_bpmp_message msg;
> +	struct mrq_pcie_request req;
> +	int err;
> +
> +	memset(&req, 0, sizeof(req));

I think "struct mrq_pcie_request req = {}" is equivalent, also for
msg.  No real preference from me.

> +static void tegra264_pcie_init(struct tegra264_pcie *pcie)
> +{
> +	u32 value;
> +
> +	if (!tegra_is_silicon()) {
> +		dev_info(pcie->dev,
> +			 "skipping link state for PCIe #%u in simulation\n",
> +			 pcie->ctl_id);
> +		pcie->link_state = true;
> +		return;
> +	}
> +
> +	/* Poll every 10 msec for 1 sec to link up */
> +	readl_poll_timeout(pcie->ecam + XTL_RC_PCIE_CFG_LINK_CONTROL_STATUS,
> +		value, value & XTL_RC_PCIE_CFG_LINK_CONTROL_STATUS_DLL_ACTIVE,
> +		PCIE_LINK_UP_DELAY, PCIE_LINK_UP_TIMEOUT);
> +
> +	if (value & XTL_RC_PCIE_CFG_LINK_CONTROL_STATUS_DLL_ACTIVE) {
> +		/* Per PCIe r5.0, 6.6.1 wait for 100ms after DLL up */
> +		msleep(100);

Looks like possibly PCIE_RESET_CONFIG_WAIT_MS?

> +		dev_info(pcie->dev, "PCIe #%u link is up (speed: %d)\n",
> +			 pcie->ctl_id, (value & 0xf0000) >> 16);
> +		pcie->link_state = true;
> +		tegra264_pcie_icc_set(pcie);
> +	} else {
> +		dev_info(pcie->dev, "PCIe #%u link is down\n", pcie->ctl_id);
> +
> +		value = readl(pcie->xtl + XTL_RC_MGMT_CLOCK_CONTROL);
> +
> +		/** Set link state only when link fails and no hot-plug feature is present */

/* (not /**), and wrap to fit in 78 columns.

> +		if ((value & XTL_RC_MGMT_CLOCK_CONTROL_PEX_CLKREQ_I_N_PIN_USE_CONV_TO_PRSNT) == 0) {
> +			dev_info(pcie->dev,
> +				 "PCIe #%u link is down and not hotplug-capable, turning off\n",
> +				 pcie->ctl_id);
> +			tegra264_pcie_bpmp_set_rp_state(pcie);
> +			pcie->link_state = false;
> +		} else {
> +			pcie->link_state = true;
> +		}
> +	}
> +}
> +
> +static int tegra264_pcie_probe(struct platform_device *pdev)
> +{
> +	struct device *dev = &pdev->dev;
> +	struct pci_host_bridge *bridge;
> +	struct tegra264_pcie *pcie;
> +	struct resource_entry *bus;
> +	struct resource *res;
> +	int err;
> +
> +	bridge = devm_pci_alloc_host_bridge(dev, sizeof(struct tegra264_pcie));
> +	if (!bridge) {
> +		dev_err(dev, "failed to allocate host bridge\n");
> +		return -ENOMEM;

Looks like this and others below could use:

  if (!bridge)
    return dev_err_probe(dev, -ENOMEM, "failed ...");

> +static const struct dev_pm_ops tegra264_pcie_pm_ops = {
> +	.resume_noirq = tegra264_pcie_resume_noirq,
> +	.suspend_noirq = tegra264_pcie_suspend_noirq,
> +};

Should this use DEFINE_NOIRQ_DEV_PM_OPS() or similar to avoid warnings
when CONFIG_PM_SLEEP, etc are not enabled?

> +static const struct of_device_id tegra264_pcie_of_match[] = {
> +	{
> +		.compatible = "nvidia,tegra264-pcie",
> +	},
> +	{ /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, tegra264_pcie_of_match);
> +
> +static struct platform_driver tegra264_pcie_driver = {
> +	.probe = tegra264_pcie_probe,
> +	.remove = tegra264_pcie_remove,
> +	.driver = {
> +		.name = "tegra264-pcie",
> +		.pm = &tegra264_pcie_pm_ops,
> +		.of_match_table = tegra264_pcie_of_match,
> +	},
> +};
> +module_platform_driver(tegra264_pcie_driver);
> +
> +MODULE_AUTHOR("Manikanta Maddireddy <mmaddireddy@nvidia.com>");
> +MODULE_DESCRIPTION("NVIDIA Tegra264 PCIe host controller driver");
> +MODULE_LICENSE("GPL");
> -- 
> 2.52.0
> 

  parent reply	other threads:[~2026-03-19 17:46 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-19 16:01 [PATCH 0/5] PCI: tegra: Add Tegra264 support Thierry Reding
2026-03-19 16:01 ` [PATCH 1/5] soc/tegra: Update BPMP ABI header Thierry Reding
2026-03-19 16:15   ` Krzysztof Kozlowski
2026-03-20  9:34     ` Thierry Reding
2026-03-20  9:44       ` Krzysztof Kozlowski
2026-03-20  9:49         ` Krzysztof Kozlowski
2026-03-20 10:52           ` Thierry Reding
2026-03-20 12:46       ` Krzysztof Kozlowski
2026-03-19 16:01 ` [PATCH 2/5] firmware: tegra: bpmp: Add tegra_bpmp_get_with_id() function Thierry Reding
2026-03-19 16:01 ` [PATCH 3/5] dt-bindings: pci: Document the NVIDIA Tegra264 PCIe controller Thierry Reding
2026-03-19 16:11   ` Krzysztof Kozlowski
2026-03-20 10:56     ` Thierry Reding
2026-03-19 17:53   ` Rob Herring (Arm)
2026-03-19 21:26   ` Rob Herring
2026-03-20  9:39     ` Thierry Reding
2026-03-20 13:06       ` Rob Herring
2026-03-20 13:48         ` Thierry Reding
2026-03-20 15:58           ` Rob Herring
2026-03-19 16:01 ` [PATCH 4/5] PCI: tegra: Add Tegra264 support Thierry Reding
2026-03-19 16:14   ` Krzysztof Kozlowski
2026-03-20 10:39     ` Thierry Reding
2026-03-19 17:46   ` Bjorn Helgaas [this message]
2026-03-20 10:34     ` Thierry Reding
2026-03-20 14:27       ` Bjorn Helgaas
2026-03-19 16:01 ` [PATCH 5/5] arm64: tegra: Add PCI controllers on Tegra264 Thierry Reding

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=20260319174639.GA515667@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jonathanh@nvidia.com \
    --cc=krzk+dt@kernel.org \
    --cc=kwilczynski@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=mani@kernel.org \
    --cc=robh@kernel.org \
    --cc=thierry.reding@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox