All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vidya Sagar <vidyas@nvidia.com>
To: Bjorn Helgaas <helgaas@kernel.org>, Thierry Reding <treding@nvidia.com>
Cc: "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 15:34:23 +0530	[thread overview]
Message-ID: <b6625491-dc02-4fdd-a748-fe0d3b573b01@nvidia.com> (raw)
In-Reply-To: <20191114183612.GA215974@google.com>

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 reason in particular why you chose to call pci_dev_wait()?
>> It seems to me like that's a little broader than pci_bus_wait_crs(). The
>> latter is static in drivers/pci/probe.c so we'd need to change that in
>> order to use it from drivers/pci/pci.c, but it sounds like the more
>> explicit thing to do.
> 
> Broader in what sense?  They work essentially identically except that
> pci_bus_wait_crs() doesn't need a pci_dev * (because it's used during
> enumeration when we don't have a pci_dev yet) and it does dword reads
> instead of word reads.
> 
> It is a shame that the logic is duplicated, but we don't have to worry
> about that here.
> 
> I think I would stick with pci_dev_wait() in this case since we do
> have a pci_dev * and it's a little simpler, unless I'm missing the
> advantage of pci_bus_wait_crs().
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. So, I feel the check
for current_state may not be need here(?)

- Vidya Sagar
> 
> Bjorn
> 


  reply	other threads:[~2019-11-15 10:04 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 [this message]
2019-11-15 22:36                                   ` Bjorn Helgaas
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=b6625491-dc02-4fdd-a748-fe0d3b573b01@nvidia.com \
    --to=vidyas@nvidia.com \
    --cc=andrew.murray@arm.com \
    --cc=helgaas@kernel.org \
    --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 \
    /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.