[lkml]   [2020]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2/6] device/pci: add cmdmem cap to pci_dev

On 3/31/2020 3:00 PM, Bjorn Helgaas wrote:
> 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
>> 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.

I'll look into adding the support for 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.

 \ /
  Last update: 2020-04-01 18:51    [W:0.061 / U:0.444 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site