All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Vidya Sagar <vidyas@nvidia.com>
Cc: Thierry Reding <treding@nvidia.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Sinan Kaya <okaya@kernel.org>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	jonathanh@nvidia.com, linux-tegra@vger.kernel.org,
	linux-pci@vger.kernel.org, kthota@nvidia.com,
	mmaddireddy@nvidia.com, sagar.tv@gmail.com,
	Andrew Murray <andrew.murray@arm.com>,
	Lukas Wunner <lukas@wunner.de>
Subject: Re: [PATCH] PCI: Add CRS timeout for pci_device_is_present()
Date: Fri, 15 Nov 2019 16:36:47 -0600	[thread overview]
Message-ID: <20191115223647.GA129381@google.com> (raw)
In-Reply-To: <b6625491-dc02-4fdd-a748-fe0d3b573b01@nvidia.com>

On Fri, Nov 15, 2019 at 03:34:23PM +0530, Vidya Sagar wrote:
> On 11/15/2019 12:06 AM, Bjorn Helgaas wrote:
> > On Wed, Nov 13, 2019 at 12:20:43PM +0100, Thierry Reding wrote:
> > > On Tue, Nov 12, 2019 at 12:58:44PM -0600, Bjorn Helgaas wrote:
> > >
> > > > My question is whether this wait should be connected somehow with
> > > > platform_pci_set_power_state().  It sounds like the tegra host
> > > > controller driver already does the platform-specific delays, and I'm
> > > > not sure it's reasonable for platform_pci_set_power_state() to do the
> > > > CRS polling.  Maybe something like this?  I'd really like to get
> > > > Rafael's thinking here.
> > > > 
> > > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > > > index e7982af9a5d8..052fa316c917 100644
> > > > --- a/drivers/pci/pci.c
> > > > +++ b/drivers/pci/pci.c
> > > > @@ -964,9 +964,14 @@ void pci_refresh_power_state(struct pci_dev *dev)
> > > >    */
> > > >   void pci_power_up(struct pci_dev *dev)
> > > >   {
> > > > +	pci_power_state_t prev_state = dev->current_state;
> > > > +
> > > >   	if (platform_pci_power_manageable(dev))
> > > >   		platform_pci_set_power_state(dev, PCI_D0);
> > > > +	if (prev_state == PCI_D3cold)
> > > > +		pci_dev_wait(dev, "D3cold->D0", PCIE_RESET_READY_POLL_MS);
>
> Is there any specific reason why should there be a check for the
> state?  In Tegra series, I observe that, by the time execution comes
> to this point, prev_state is PCI_D3Hot and in Tegra194 particularly,
> it is PCI_D0 because the host controller driver explicitly keeps the
> downstream devices in PCI_D0 state as a work around for one of the
> Tegra194 specific issues. 

I think you're right, we probably should not try to check "prev_state"
here because we can't rely on that being accurate.

On Tegra, I assume suspend puts the PCIe devices in D3hot, then when
we suspend the RC itself, it looks like tegra_pcie_pm_suspend()
actually turns off the power, so the PCIe devices probably go to
D3cold but nothing updates their dev->current_state, so it's probably
still PCI_D3hot.

On Tegra194, the same probably happens, except that when we suspend
the RC itself, tegra_pcie_downstream_dev_to_D0() puts the PCIe devices
back in D0 (updating their dev->current_state to PCI_D0), and then we
turn off the power, so they probably also end up in D3cold but with
dev_current_state still set to PCI_D0.

> So, I feel the check for current_state may not be need here(?)

I think you're right.  We can't tell what dev->current_state is when
we enter pci_power_up().

Bjorn

  reply	other threads:[~2019-11-15 22:36 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-05 18:21 [PATCH] PCI: Add CRS timeout for pci_device_is_present() Vidya Sagar
2019-10-14  8:20 ` Thierry Reding
2019-10-14 20:21   ` Sinan Kaya
2019-10-15  9:30     ` Thierry Reding
2019-10-15 11:10       ` Sinan Kaya
2019-10-15 12:14         ` Vidya Sagar
     [not found]           ` <afa16546-e63d-6eba-8be0-8e52339cd100@nvidia.com>
2019-10-25 11:58             ` Vidya Sagar
2019-10-26 13:59               ` Sinan Kaya
2019-11-04 11:43                 ` Vidya Sagar
2019-11-04 16:52                   ` Lorenzo Pieralisi
2019-11-04 17:39           ` Bjorn Helgaas
2019-11-05 10:55             ` Rafael J. Wysocki
2019-11-06 16:41               ` Bjorn Helgaas
2019-11-11  6:01                 ` Vidya Sagar
2019-11-11 22:32                   ` Bjorn Helgaas
2019-11-12 12:59                     ` Thierry Reding
2019-11-12 14:21                       ` Bjorn Helgaas
2019-11-12 17:59                         ` Vidya Sagar
2019-11-12 18:58                           ` Bjorn Helgaas
2019-11-13  5:39                             ` Vidya Sagar
2019-11-13 11:20                             ` Thierry Reding
2019-11-14 18:36                               ` Bjorn Helgaas
2019-11-15 10:04                                 ` Vidya Sagar
2019-11-15 22:36                                   ` Bjorn Helgaas [this message]
2019-11-18 15:18                                     ` Vidya Sagar
2019-11-12 17:59                     ` Vidya Sagar
2019-10-15 12:03       ` Vidya Sagar
2019-10-15 11:34     ` Vidya Sagar
2019-10-14 10:45 ` Andrew Murray

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=20191115223647.GA129381@google.com \
    --to=helgaas@kernel.org \
    --cc=andrew.murray@arm.com \
    --cc=jonathanh@nvidia.com \
    --cc=kthota@nvidia.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=lukas@wunner.de \
    --cc=mmaddireddy@nvidia.com \
    --cc=okaya@kernel.org \
    --cc=rjw@rjwysocki.net \
    --cc=sagar.tv@gmail.com \
    --cc=treding@nvidia.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.