[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87ftdoupb5.fsf@nanos.tec.linutronix.de>
Date: Wed, 01 Apr 2020 00:34:06 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Bjorn Helgaas <helgaas@...nel.org>,
Dave Jiang <dave.jiang@...el.com>
Cc: vkoul@...nel.org, mingo@...hat.com, bp@...en8.de, hpa@...or.com,
gregkh@...uxfoundation.org, arnd@...db.de,
linux-kernel@...r.kernel.org, x86@...nel.org,
dmaengine@...r.kernel.org, dan.j.williams@...el.com,
ashok.raj@...el.com, fenghua.yu@...el.com,
linux-pci@...r.kernel.org, tony.luck@...el.com, jing.lin@...el.com,
sanjay.k.kumar@...el.com
Subject: Re: [PATCH 2/6] device/pci: add cmdmem cap to pci_dev
Bjorn Helgaas <helgaas@...nel.org> writes:
> 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.
Don't worry. There is nothing to decide and ack before the basic
architecture support for ENQCMD[S] is discussed and accepted. The
patches providing this support have been posted 2 hrs before this pile
hit the mailing lists yesterday.
Thanks,
tglx
Powered by blists - more mailing lists