All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Cc: thierry.reding@gmail.com, bhelgaas@google.com, cyndis@kapsi.fi,
	jonathanh@nvidia.com, linux-pci@vger.kernel.org,
	linux-tegra@vger.kernel.org, vidyas@nvidia.com,
	kthota@nvidia.com
Subject: Re: [PATCH V9 3/3] PCI: tegra: Add power management support
Date: Mon, 5 Mar 2018 09:41:24 +0000	[thread overview]
Message-ID: <20180305094116.GA28109@e107981-ln.cambridge.arm.com> (raw)
In-Reply-To: <19831410-9248-61ff-6e75-249c77dcee9a@nvidia.com>

On Sat, Mar 03, 2018 at 01:47:38PM +0530, Manikanta Maddireddy wrote:

[...]

> >> +static int tegra_pcie_pm_resume(struct device *dev)
> >> +{
> >> +	struct tegra_pcie *pcie = dev_get_drvdata(dev);
> >> +	int err;
> >> +
> >> +	err = tegra_pcie_power_on(pcie);
> >> +	if (err) {
> >> +		dev_err(dev, "tegra pcie power on fail: %d\n", err);
> >> +		return err;
> >> +	}
> >> +	err = tegra_pcie_enable_controller(pcie);
> >> +	if (err) {
> >> +		dev_err(dev, "tegra pcie controller enable fail: %d\n", err);
> >> +		goto poweroff;
> >> +	}
> >> +	tegra_pcie_setup_translations(pcie);
> >> +
> >> +	if (IS_ENABLED(CONFIG_PCI_MSI))
> >> +		tegra_pcie_enable_msi(pcie);
> >> +
> >> +	tegra_pcie_enable_ports(pcie);
> > 
> > Is it correct to report a successfull resume if some of the ports fail
> > to come up (whether within runtime PM or system suspend) ? I think that,
> > if any of the ports fails to come up, returning a failure is more
> > appropriate here given that the host bridge is a single device as far as
> > the kernel is concerned.
> > 
> > Thanks,
> > Lorenzo
> > 
> 
> Hi Lorenzo,
> 
> We(Thierry, Vidya Sagar and myself) had a discussion on this topic
> and we chose not to fail probe/resume because host controller is
> initialized properly, so failing the probe/resume is not the right
> thing to do.

What happens then to endpoints downstream a rootport that failed to
resume but we nonetheless reported that it successfully resume instead ?

Thanks,
Lorenzo

> PCIe link may fail to come up if there is no endpoint in the slot
> or interoperable failure where endpoint specific quirk or work
> around required. In such cases host controller driver shouldn't
> fail.
> 
> Also user can connect endpoint in only one slot and expect it to be
> working. Even though host bridge is a single device, driver should
> allow standalone port to work.
> 
> Thanks,
> Manikanta
> 
> >>  
> >>  	return 0;
> >> +
> >> +poweroff:
> >> +	tegra_pcie_power_off(pcie);
> >> +
> >> +	return err;
> >>  }
> >>  
> >> +static const struct dev_pm_ops tegra_pcie_pm_ops = {
> >> +	SET_RUNTIME_PM_OPS(tegra_pcie_pm_suspend, tegra_pcie_pm_resume, NULL)
> >> +	SET_NOIRQ_SYSTEM_SLEEP_PM_OPS(tegra_pcie_pm_suspend,
> >> +				      tegra_pcie_pm_resume)
> >> +};
> >> +
> >>  static struct platform_driver tegra_pcie_driver = {
> >>  	.driver = {
> >>  		.name = "tegra-pcie",
> >>  		.of_match_table = tegra_pcie_of_match,
> >>  		.suppress_bind_attrs = true,
> >> +		.pm = &tegra_pcie_pm_ops,
> >>  	},
> >>  	.probe = tegra_pcie_probe,
> >>  	.remove = tegra_pcie_remove,
> >> -- 
> >> 2.1.4
> >>

  reply	other threads:[~2018-03-05  9:41 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-28 10:00 [PATCH V9 0/3] Add loadable kernel module and power management support Manikanta Maddireddy
2018-02-28 10:00 ` [PATCH V9 1/3] PCI: tegra: Free resources on probe failure Manikanta Maddireddy
2018-02-28 10:00 ` [PATCH V9 2/3] PCI: tegra: Add loadable kernel module support Manikanta Maddireddy
2018-02-28 10:00 ` [PATCH V9 3/3] PCI: tegra: Add power management support Manikanta Maddireddy
2018-03-02 16:36   ` Lorenzo Pieralisi
2018-03-03  8:17     ` Manikanta Maddireddy
2018-03-05  9:41       ` Lorenzo Pieralisi [this message]
2018-03-06  9:56         ` Manikanta Maddireddy
2018-03-06 11:59           ` Lorenzo Pieralisi
2018-03-06 13:48             ` Manikanta Maddireddy
2018-03-06 17:58 ` [PATCH V9 0/3] Add loadable kernel module and " Lorenzo Pieralisi

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=20180305094116.GA28109@e107981-ln.cambridge.arm.com \
    --to=lorenzo.pieralisi@arm.com \
    --cc=bhelgaas@google.com \
    --cc=cyndis@kapsi.fi \
    --cc=jonathanh@nvidia.com \
    --cc=kthota@nvidia.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=mmaddireddy@nvidia.com \
    --cc=thierry.reding@gmail.com \
    --cc=vidyas@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 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.