All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Balbi <felipe.balbi@linux.intel.com>
To: Bjorn Helgaas <helgaas@kernel.org>, Sinan Kaya <okaya@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>, linux-pci@vger.kernel.org
Subject: Re: [RFC] PCI: add support for Immediate Readiness
Date: Wed, 05 Sep 2018 08:29:56 +0300	[thread overview]
Message-ID: <87sh2objfv.fsf@linux.intel.com> (raw)
In-Reply-To: <87va7kbjqu.fsf@linux.intel.com>

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


Hi,

Felipe Balbi <felipe.balbi@linux.intel.com> writes:
> Felipe Balbi <felipe.balbi@linux.intel.com> writes:
>>> Since this applies to all resets, I think you also need to get rid of
>>>> waits following different reset types in step #2 and return immediately.
>>>> I suggest you review callers of pci_dev_wait() and tap in there.
>>>
>>> I agree; I think we should be able to skip the delays in pcie_flr(),
>>> pci_af_flr(), etc.
>>
>> but that's why I put the code in pci_dev_wait(). Both pcie_flr() and
>> pci_af_flr() call pci_dev_wait(); or are you saying that the msleep(100)
>> call in pci_af_flr() can also be removed if (dev->imm_ready)?
>
> What about moving that msleep() to pci_dev_wait() itself?

this will incur and extra 100ms delay on D3->D0 transitions and bus
reset. Is that acceptable or would you prefer to add another check on
pcie_flr() and pci_af_flr()?

- 
balbi

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

  reply	other threads:[~2018-09-05  5:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-02 11:36 [RFC] PCI: add support for Immediate Readiness Felipe Balbi
2018-08-02 11:56 ` Christoph Hellwig
2018-08-02 12:11   ` Felipe Balbi
2018-08-03  6:14 ` Sinan Kaya
2018-08-03  6:26   ` Felipe Balbi
2018-08-03 17:25     ` Sinan Kaya
2018-09-04 18:11       ` Bjorn Helgaas
2018-09-05  5:18         ` Felipe Balbi
2018-09-05  5:23           ` Felipe Balbi
2018-09-05  5:29             ` Felipe Balbi [this message]
2018-09-05 16:49           ` Bjorn Helgaas
2018-09-05 16:54             ` Sinan Kaya
2018-09-06  6:02             ` Felipe Balbi
2018-09-06 14:13               ` Bjorn Helgaas
2018-09-07  6:16                 ` [PATCH v2] " Felipe Balbi
2018-09-20  6:12                   ` Felipe Balbi
2018-09-28 17:57                   ` Bjorn Helgaas
2018-10-01  5:42                     ` Felipe Balbi

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=87sh2objfv.fsf@linux.intel.com \
    --to=felipe.balbi@linux.intel.com \
    --cc=bhelgaas@google.com \
    --cc=helgaas@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=okaya@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 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.