From: "Spassov, Stanislav" <stanspas@amazon.de>
To: "Spassov, Stanislav" <stanspas@amazon.de>,
"rafael@kernel.org" <rafael@kernel.org>
Cc: "corbet@lwn.net" <corbet@lwn.net>,
"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
"ashok.raj@intel.com" <ashok.raj@intel.com>,
"okaya@kernel.org" <okaya@kernel.org>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"lorenzo.pieralisi@arm.com" <lorenzo.pieralisi@arm.com>,
"lkp@intel.com" <lkp@intel.com>,
"amurray@thegoodpenguin.co.uk" <amurray@thegoodpenguin.co.uk>,
"thomas.petazzoni@bootlin.com" <thomas.petazzoni@bootlin.com>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"Schoenherr, Jan H." <jschoenh@amazon.de>,
"rjw@rjwysocki.net" <rjw@rjwysocki.net>,
"jason@lakedaemon.net" <jason@lakedaemon.net>,
"rajatja@google.com" <rajatja@google.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"bhelgaas@google.com" <bhelgaas@google.com>,
"lenb@kernel.org" <lenb@kernel.org>,
"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH v3 07/17] PCI: Clean up and document PM/reset delays
Date: Sat, 7 Mar 2020 11:30:45 +0000 [thread overview]
Message-ID: <575f12241914cc6fa48e250f24db92af560cc375.camel@amazon.de> (raw)
In-Reply-To: <CAJZ5v0gD4XweLHQzQfRiBxWz8O5mFsc5Chj4JNhX+5ja6Cxrig@mail.gmail.com>
On Tue, 2020-03-03 at 20:03 +0100, Rafael J. Wysocki wrote:
>
> What "magic numbers" exactly do you mean? The SRIOV and FLR delays?
> Why not to be more specific here if so?
You are right. I am extending the commit message like this for the next version:
PCI: Clean up and document PM/reset delays
The existing set of PCI_PM_* constants has some inconsistencies (_WAIT
vs _DELAY suffix), and does not cover all the scenarios that the PCIe
specifications mandates waiting periods for.
In preparation for adding infrastructure to override, on a per-device
basis, the individual waiting periods using standardized mechanisms,
this commit introduces and documents constants providing the default
values for various waiting scenarios all around PCI device resets,
PM state changes, and enabling SR-IOV VFs.
Several instances of 'msleep(100)' in the FLR and VF enable codepaths
have been adjusted to use the newly introduced constants instead.
Corresponding explanatory code comments were removed, as they are now
superseded by the documentation of the constants.
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
next prev parent reply other threads:[~2020-03-07 11:30 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-03 13:28 [PATCH v3 00/17] Improve PCI device post-reset readiness polling Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 01/17] PCI: Fall back to slot/bus reset if softer methods timeout Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 02/17] PCI: Remove unused PCI_PM_BUS_WAIT Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 03/17] PCI: Use pci_bridge_wait_for_secondary_bus after SBR Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 04/17] PCI: Do not override delay for D0->D3hot transition Stanislav Spassov
2020-03-03 18:57 ` Rafael J. Wysocki
2020-03-07 10:58 ` Spassov, Stanislav
2020-03-03 13:28 ` [PATCH v3 05/17] PCI: Fix handling of _DSM 8 (avoiding reset delays) Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 06/17] PCI: Fix us->ms conversion in pci_acpi_optimize_delay Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 07/17] PCI: Clean up and document PM/reset delays Stanislav Spassov
2020-03-03 19:03 ` Rafael J. Wysocki
2020-03-07 11:30 ` Spassov, Stanislav [this message]
2020-03-03 13:28 ` [PATCH v3 08/17] PCI: Add more delay overrides to struct pci_dev Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 09/17] PCI: Generalize pci_bus_max_d3cold_delay to pci_bus_max_delay Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 10/17] PCI: Use correct delay in pci_bridge_wait_for_secondary_bus Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 11/17] PCI: Refactor pci_dev_wait to remove timeout parameter Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 12/17] PCI: Refactor pci_dev_wait to take pci_init_event Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 13/17] PCI: Cache CRS Software Visibiliy in struct pci_dev Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 14/17] PCI: Introduce per-device reset_ready_poll override Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 15/17] PCI: Refactor polling loop out of pci_dev_wait Stanislav Spassov
2020-03-03 13:28 ` [PATCH v3 16/17] PCI: Add CRS handling to pci_dev_wait() Stanislav Spassov
2020-03-05 17:56 ` Raj, Ashok
2020-03-06 18:07 ` Spassov, Stanislav
2020-03-03 13:28 ` [PATCH v3 17/17] PCI: Lower PCIE_RESET_READY_POLL_MS from 1m to 1s Stanislav Spassov
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=575f12241914cc6fa48e250f24db92af560cc375.camel@amazon.de \
--to=stanspas@amazon.de \
--cc=akpm@linux-foundation.org \
--cc=alex.williamson@redhat.com \
--cc=amurray@thegoodpenguin.co.uk \
--cc=ashok.raj@intel.com \
--cc=bhelgaas@google.com \
--cc=corbet@lwn.net \
--cc=jason@lakedaemon.net \
--cc=jschoenh@amazon.de \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=lkp@intel.com \
--cc=lorenzo.pieralisi@arm.com \
--cc=okaya@kernel.org \
--cc=rafael@kernel.org \
--cc=rajatja@google.com \
--cc=rjw@rjwysocki.net \
--cc=tglx@linutronix.de \
--cc=thomas.petazzoni@bootlin.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;
as well as URLs for NNTP newsgroup(s).