Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Manivannan Sadhasivam <mani@kernel.org>
Cc: "Thierry Reding" <thierry.reding@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Conor Dooley" <conor+dt@kernel.org>,
	"Jonathan Hunter" <jonathanh@nvidia.com>,
	"Karthikeyan Mitran" <m.karthikeyan@mobiveil.co.in>,
	"Hou Zhiqiang" <Zhiqiang.Hou@nxp.com>,
	"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
	"Pali Rohár" <pali@kernel.org>,
	"Michal Simek" <michal.simek@amd.com>,
	"Kevin Xie" <kevin.xie@starfivetech.com>,
	linux-pci@vger.kernel.org, devicetree@vger.kernel.org,
	linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	"Thierry Reding" <treding@nvidia.com>,
	"Manikanta Maddireddy" <mmaddireddy@nvidia.com>
Subject: Re: [PATCH v4 3/4] PCI: tegra: Add Tegra264 support
Date: Tue, 26 May 2026 10:42:52 +0200	[thread overview]
Message-ID: <ahVbq96MYmhIngcP@orome> (raw)
In-Reply-To: <ukeelrtmjgxxwlkkzsojygzo6us5ijshis66a4x2a44hg4bw25@hggglahvrajy>

[-- Attachment #1: Type: text/plain, Size: 5189 bytes --]

On Fri, Apr 10, 2026 at 10:04:20PM +0530, Manivannan Sadhasivam wrote:
> On Tue, Apr 07, 2026 at 11:38:28AM +0200, Thierry Reding wrote:
> > On Thu, Apr 02, 2026 at 11:02:02PM +0530, Manivannan Sadhasivam wrote:
> > > On Thu, Apr 02, 2026 at 04:27:37PM +0200, Thierry Reding wrote:
[...]
> > > > +	depends on ARCH_TEGRA || COMPILE_TEST
> > > > +	depends on PCI_MSI
> > > 
> > > Why?
> > 
> > I suppose it's not necessary in the sense of it being a build
> > dependency. At runtime, however, the root complex is not useful if PCI
> > MSI is not enabled. We can drop this dependency and rely on .config to
> > have it enabled as needed.
> > 
> 
> Yes. I think the rationale is to depend on the symbols that the driver needs for
> build dependency.

Done.

[...]
> > > > +						  GPIOD_IN);
> > > > +	if (IS_ERR(pcie->wake_gpio))
> > > > +		return PTR_ERR(pcie->wake_gpio);
> > > > +
> > > > +	if (pcie->wake_gpio) {
> > > 
> > > Since you are bailing out above, you don't need this check.
> > 
> > I think we still want to have this check to handle the case of optional
> > wake GPIOs. Not all controllers may have this wired up and
> > devm_gpiod_get_optional() will return NULL (not an ERR_PTR()-encoded
> > error) if the wake-gpios property is missing.
> > 
> 
> Ok. In that case you can just bail out:
> 	if (!pcie->wake_gpio)
> 		return 0;

Done.

[...]
> > > > +	bw = width * (PCIE_SPEED2MBS_ENC(speed) / BITS_PER_BYTE);
> > > > +	value = MBps_to_icc(bw);
> > > 
> > > So this becomes, 'width * (PCIE_SPEED2MBS_ENC(speed) / 8) * 1000 / 8'. But don't
> > > you want, 'width * (PCIE_SPEED2MBS_ENC(speed)) * 1000 / 8'?
> > 
> > This is M*B*ps_to_icc(), not M*b*ps_to_icc(), so we do in fact get the
> > latter. I almost fell for this as well because I got confused by some of
> > these macros being all-caps and other times the case actually mattering.
> > 
> 
> Oops, I was misleaded too. But you can simply do:
> 	bw = Mbps_to_icc(width * PCIE_SPEED2MBS_ENC(speed));
> 
> > > > +	err = icc_set_bw(pcie->icc_path, bw, bw);
> 
> And here you were setting the MBps, not Kbps.

Done.

> > > > +	if (err < 0)
> > > > +		dev_err(pcie->dev,
> > > > +			"failed to request bandwidth (%u MBps): %pe\n",
> > > > +			bw, ERR_PTR(err));
> > > 
> > > So you don't want to error out if this fails?
> > 
> > No. This is not a fatal error and the system will continue to work,
> > albeit perhaps at suboptimal performance. Given that Ethernet and mass
> > storage are connected to these, a failure to set the bandwidth and
> > erroring out here may leave the system unusable, but continuing on would
> > let the system boot and update firmware, kernel or whatever to recover.
> > 
> > I'll add a comment explaining this.
> > 
> 
> Yeah, that'll help.

Done.

[...]
> > > s/link/controller or endpoint?
> > 
> > This controls the PERST# signal, so I guess "endpoint" would be more
> > correct.
> > 
> 
> Yes!

Done.

[...]
> > > > +	if (!pcie->link_up)
> > > > +		goto free;
> > > 
> > > goto free_ecam;
> > 
> > It's not clear to me, but are you suggesting to rename the existing
> > "free" label to "free_ecam"? I can do that.
> > 
> 
> Yeah, I was just asking for a rename.

Done.

[...]
> > > > +static int tegra264_pcie_resume_noirq(struct device *dev)
> > > > +{
> > > > +	struct tegra264_pcie *pcie = dev_get_drvdata(dev);
> > > > +	int err;
> > > > +
> > > > +	if (pcie->wake_gpio && device_may_wakeup(dev)) {
> > > > +		err = disable_irq_wake(pcie->wake_irq);
> > > > +		if (err < 0)
> > > > +			dev_err(dev, "failed to disable wake IRQ: %pe\n",
> > > > +				ERR_PTR(err));
> > > > +	}
> > > > +
> > > > +	if (pcie->link_up == false)
> > > > +		return 0;
> > > > +
> > > > +	tegra264_pcie_init(pcie);
> > > > +
> > > 
> > > Why do you need init() here without deinit() in tegra264_pcie_suspend_noirq()?
> > 
> > That's because when we come out of suspend the link may have gone down
> > again, so we need to take the endpoint out of reset to retrigger the
> > link training. I think we could possibly explicitly clear that PERST_O_N
> > bit in the PERST_CONTROL register in a new tegra264_pcie_deinit() to
> > mirror what tegra264_pcie_init() does, but it's automatically done by
> > firmware anyway, so not needed.
> > 
> 
> Hmm, so firmware asserts PERST# at the end of suspend? It is not clear to me why
> it is doing so. But for symmetry I'd like to do it in tegra264_pcie_deinit().

Done.

> Also, I'm not certain about the 'pcie->link_up' check here. If it is 'false',
> then probe() should've failed. So why do you need the check here anyway?
> 
> Maybe you should get rid of this check and return the link status from
> tegra264_pcie_init() directly?

We specifically don't want to fail the probe for this when the link is
not there because we want to tighly control the power mode when the link
is not up. We also need to keep the link alive for the case where it can
be hotplug capable.

I've added a new tegra264_pcie_deinit() function to clear that PERST_O_N
bit explicitly, but I've kept the link_up flag.

Thanks,
Thierry

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2026-05-26  8:43 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-02 14:27 [PATCH v4 0/4] PCI: tegra: Add Tegra264 support Thierry Reding
2026-04-02 14:27 ` [PATCH v4 1/4] dt-bindings: pci: Document the NVIDIA Tegra264 PCIe controller Thierry Reding
2026-04-02 14:27 ` [PATCH v4 2/4] PCI: Use standard wait times for PCIe link monitoring Thierry Reding
2026-04-02 14:27 ` [PATCH v4 3/4] PCI: tegra: Add Tegra264 support Thierry Reding
2026-04-02 17:32   ` Manivannan Sadhasivam
2026-04-07  9:38     ` Thierry Reding
2026-04-10 16:34       ` Manivannan Sadhasivam
2026-05-26  8:42         ` Thierry Reding [this message]
2026-04-02 14:27 ` [PATCH v4 4/4] 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=ahVbq96MYmhIngcP@orome \
    --to=thierry.reding@gmail.com \
    --cc=Zhiqiang.Hou@nxp.com \
    --cc=bhelgaas@google.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=jonathanh@nvidia.com \
    --cc=kevin.xie@starfivetech.com \
    --cc=krzk+dt@kernel.org \
    --cc=kwilczynski@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=m.karthikeyan@mobiveil.co.in \
    --cc=mani@kernel.org \
    --cc=michal.simek@amd.com \
    --cc=mmaddireddy@nvidia.com \
    --cc=pali@kernel.org \
    --cc=robh@kernel.org \
    --cc=thierry.reding@kernel.org \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=treding@nvidia.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox