Re: [RFC v3] PCI: PTM Driver

["Yong, Jonathan" <jonathan.yong@intel.com>]

On 04/07/2016 15:08, Yong, Jonathan wrote:
> On 03/23/2016 12:04, Yong, Jonathan wrote:
>> Hello LKML,
>>
>> This is a preliminary implementation of the PTM[1] support driver, the
>> code
>> is obviously hacked together and in need of refactoring. This driver has
>> only been tested against a virtual PCI bus.
>>
>> The drivers job is to get to every PTM capable device, set some PCI
>> config
>> space bits, then go back to sleep [2].
>>
>> PTM capable PCIe devices will get a new sysfs entry to allow PTM to be
>> enabled if automatic PTM activation is disabled, or disabled if so
>> desired.
>>
>> Comments? Should I explain the PTM registers in more details?
>> Please CC me, thanks.
>>
>> [1] Precision Time Measurement: A protocol for synchronizing PCIe
>> endpoint
>> clocks against the host clock as specified in the PCI Express Base
>> Specification 3.1. It is identified by the 0x001f extended capability ID.
>>
>> PTM capable devices are split into 3 roles, master, responder and
>> requester.
>> Summary as follows:
>>
>> A master holds the master clock that will be used for all devices
>> under its
>> domain (not to be confused with PCI domains). There may be multiple
>> masters
>> in a PTM hierarchy, in which case, the highest master closest to the root
>> complex will be selected for the PTM domain. A master is also always
>> responder capable. Clock precision is signified by a Local Clock
>> Granularity field, in nano-seconds.
>>
>> A responder responds to any PTM synchronization requests from a
>> downstream
>> device. A responder is typically a switch device. It may also hold a
>> local
>> clock signified by a non-zero Local Clock Granularity field. A value of 0
>> signifies that the device simply propagates timing information from
>> upstream devices.
>>
>> A requester is typically an endpoint that will request synchronization
>> updates from an upstream PTM capable time source. The driver will update
>> the Effective Clock Granularity field based on the same field from the
>> PTM domain master. The field should be programmed with a value of 0 if
>> any
>> intervening responder has a Local Clock Granularity field value of 0.
>>
>> [2] The software drivers never see the PTM packets, the PCI Express Base
>> Specification 3.1 reads:
>>     PTM capable components can make their PTM context available for
>>     inspection by software, enabling software to translate timing
>>     information between local times and PTM Master Time.
>>
>> This isn't very informative.
>>
>> Changes since v1:
>> * Moved register constants to pci_regs.h
>> * Use pci_dev to hold PTM status
>> * PTM initialization now done top-down hierarchy wise.
>>
>> Changes since v2:
>> * Added missing void return in the pci_ptm_init inline stub.
>>
>> Yong, Jonathan (1):
>>    PCI: PTM preliminary implementation
>>
>>   drivers/pci/pci-sysfs.c       |   7 ++
>>   drivers/pci/pci.h             |  25 +++++
>>   drivers/pci/pcie/Kconfig      |   8 ++
>>   drivers/pci/pcie/Makefile     |   2 +-
>>   drivers/pci/pcie/pcie_ptm.c   | 212
>> ++++++++++++++++++++++++++++++++++++++++++
>>   drivers/pci/probe.c           |   3 +
>>   include/linux/pci.h           |   9 ++
>>   include/uapi/linux/pci_regs.h |  12 +++
>>   8 files changed, 277 insertions(+), 1 deletion(-)
>>   create mode 100644 drivers/pci/pcie/pcie_ptm.c
>>
>
> Ping?
>
Ping2?