Hi Jay, On Mon, Aug 10, 2015 at 1:36 PM, Jay Cornwall <jay@xxxxxxxxxxxx> wrote: > There is some interest in using the PCIe 3.0 AtomicOp capability with a > subset of devices supported by drm/amdgpu. > > Adding this line to drm/amdgpu produced correct results in our tests: > pcie_capability_set_word(adev->pdev, PCI_EXP_DEVCTL2, 0x40); > > I have found only a handful of examples of capability use throughout > drivers/. I see that the ARI capability is enabled if supported in > drivers/pci/pci.c. > > Should the AtomicOp capabilities be similarly enabled if available? Or might > there be a reason for doing this on a per-driver basis? I think the PCIe capability structure (including device, link slot, etc., capability, status, and control registers) should be managed by the PCI core, not by individual drivers, because these things often have implications beyond the scope of a driver. There are some existing cases where drivers fiddle with the PCIe capability, but I try to avoid adding new ones. I'm not very familiar with the AtomicOp functionality, but a quick skim of the spec suggests that it does have system implications and should be handled by the core. For example, AtomicOp support is optional, and it looks like it would be a bad idea to enable it in an endpoint if the upstream switch didn't support it. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
