From: Bjorn Helgaas <helgaas@kernel.org>
To: Dave Jiang <dave.jiang@intel.com>
Cc: vkoul@kernel.org, tglx@linutronix.de, mingo@redhat.com,
bp@alien8.de, hpa@zytor.com, gregkh@linuxfoundation.org,
arnd@arndb.de, linux-kernel@vger.kernel.org, x86@kernel.org,
dmaengine@vger.kernel.org, dan.j.williams@intel.com,
ashok.raj@intel.com, fenghua.yu@intel.com,
linux-pci@vger.kernel.org, tony.luck@intel.com,
jing.lin@intel.com, sanjay.k.kumar@intel.com
Subject: Re: [PATCH 2/6] device/pci: add cmdmem cap to pci_dev
Date: Tue, 31 Mar 2020 17:00:06 -0500 [thread overview]
Message-ID: <20200331220006.GA37376@google.com> (raw)
In-Reply-To: <d798a7eb-ceb0-d81e-5422-f9e41058a098@intel.com>
On Tue, Mar 31, 2020 at 10:59:44AM -0700, Dave Jiang wrote:
> On 3/31/2020 9:03 AM, Bjorn Helgaas wrote:
> > On Mon, Mar 30, 2020 at 02:27:00PM -0700, Dave Jiang wrote:
> > > Since the current accelerator devices do not have standard PCIe capability
> > > enumeration for accepting ENQCMDS yet, for now an attribute of pdev->cmdmem has
> > > been added to struct pci_dev. Currently a PCI quirk must be used for the
> > > devices that have such cap until the PCI cap is standardized. Add a helper
> > > function to provide the check if a device supports the cmdmem capability.
> > >
> > > Such capability is expected to be added to PCIe device cap enumeration in
> > > the future.
> > This needs some sort of thumbnail description of what "synchronous
> > write notification" and "cmdmem" mean.
>
> I will add more explanation.
>
> > Do you have a pointer to a PCI-SIG ECR or similar?
>
> Deferrable Memory Write (DMWr) ECR
>
> https://members.pcisig.com/wg/PCI-SIG/document/13747
>
> From what I'm told it should be available for public review by EOW.
Please use terminology from the spec instead of things like
"synchronous write notification".
AIUI, ENQCMDS is an x86 instruction. That would have no meaning in
the PCIe domain.
I'm not committing to acking any part of this before the ECR is
accepted, but if you're adding support for the feature described by
the ECR, you might as well add support for discovering the DMWr
capability via Device Capabilities 2 as described in the ECR.
If you have hardware that supports DMWr but doesn't advertise it via
Device Capabilities 2, you can always have a quirk that works around
that lack.
next parent reply other threads:[~2020-03-31 22:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <d798a7eb-ceb0-d81e-5422-f9e41058a098@intel.com>
2020-03-31 22:00 ` Bjorn Helgaas [this message]
2020-03-31 22:34 ` [PATCH 2/6] device/pci: add cmdmem cap to pci_dev Thomas Gleixner
2020-04-01 16:37 ` Dave Jiang
2020-03-30 21:26 [PATCH 0/6] Add shared workqueue support for idxd driver Dave Jiang
2020-03-30 21:27 ` [PATCH 2/6] device/pci: add cmdmem cap to pci_dev Dave Jiang
2020-03-31 10:04 ` Greg KH
2020-03-31 17:07 ` Dave Jiang
2020-03-31 17:24 ` Greg KH
2020-03-31 17:38 ` Dave Jiang
2020-03-31 16:03 ` Bjorn Helgaas
2020-03-31 21:44 ` Dave Jiang
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=20200331220006.GA37376@google.com \
--to=helgaas@kernel.org \
--cc=arnd@arndb.de \
--cc=ashok.raj@intel.com \
--cc=bp@alien8.de \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=dmaengine@vger.kernel.org \
--cc=fenghua.yu@intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=jing.lin@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=sanjay.k.kumar@intel.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=vkoul@kernel.org \
--cc=x86@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 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).