linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC] PCI: PTM Driver
@ 2016-03-11  7:26 Yong, Jonathan
  2016-03-11  7:26 ` [PATCH] PCI: PTM preliminary implementation Yong, Jonathan
  0 siblings, 1 reply; 21+ messages in thread
From: Yong, Jonathan @ 2016-03-11  7:26 UTC (permalink / raw)
  To: linux-pci; +Cc: bhelgaas, jonathan.yong

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 programed 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
Specificaton 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.

Yong, Jonathan (1):
  PCI: PTM preliminary implementation

 drivers/pci/pci-sysfs.c     |   7 +
 drivers/pci/pci.h           |  21 +++
 drivers/pci/pcie/Kconfig    |   8 +
 drivers/pci/pcie/Makefile   |   2 +-
 drivers/pci/pcie/pcie_ptm.c | 353 ++++++++++++++++++++++++++++++++++++++++++++
 drivers/pci/probe.c         |   3 +
 6 files changed, 393 insertions(+), 1 deletion(-)
 create mode 100644 drivers/pci/pcie/pcie_ptm.c

-- 
2.4.10


^ permalink raw reply	[flat|nested] 21+ messages in thread
* [RFC v2] PCI: PTM Driver
@ 2016-03-23  2:47 Yong, Jonathan
  2016-03-23  2:47 ` [PATCH] PCI: PTM preliminary implementation Yong, Jonathan
  0 siblings, 1 reply; 21+ messages in thread
From: Yong, Jonathan @ 2016-03-23  2:47 UTC (permalink / raw)
  To: linux-pci; +Cc: bhelgaas, jonathan.yong

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.

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

-- 
2.7.3


^ permalink raw reply	[flat|nested] 21+ messages in thread
* [RFC v3] PCI: PTM Driver
@ 2016-03-23  4:04 Yong, Jonathan
  2016-03-23  4:04 ` [PATCH] PCI: PTM preliminary implementation Yong, Jonathan
  0 siblings, 1 reply; 21+ messages in thread
From: Yong, Jonathan @ 2016-03-23  4:04 UTC (permalink / raw)
  To: linux-pci; +Cc: bhelgaas, jonathan.yong

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

-- 
2.7.3


^ permalink raw reply	[flat|nested] 21+ messages in thread
* [RFC v4] PCI: PTM Driver
@ 2016-04-19  6:24 Yong, Jonathan
  2016-04-19  6:24 ` [PATCH] PCI: PTM preliminary implementation Yong, Jonathan
  0 siblings, 1 reply; 21+ messages in thread
From: Yong, Jonathan @ 2016-04-19  6:24 UTC (permalink / raw)
  To: linux-pci; +Cc: jonathan.yong, bhelgaas

Hello LKML,

This is a preliminary implementation of the PTM[1] support driver. This driver
has only been tested against a virtual PCI bus since there are no known
endpoints utilizing it yet.

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/disabled individually (enable by default).

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.

Changes since v3:
* Clearing CONFIG_PCIE_PTM now completely prevents the driver from being built.
* Renamed pci_*_ptm_sysfs to pcie_ptm_*_sysfs_dev_files for consistency.
* Removed useless prototypes.
* Driver no longer checks PTM capability version
* PCI_EXT_CAP_ID_MAX updated to include PTM (0x1F)

Yong, Jonathan (1):
  PCI: PTM preliminary implementation

 drivers/pci/pci-sysfs.c       |   7 ++
 drivers/pci/pci.h             |  20 +++++
 drivers/pci/pcie/Kconfig      |   9 ++
 drivers/pci/pcie/Makefile     |   3 +
 drivers/pci/pcie/pcie_ptm.c   | 194 ++++++++++++++++++++++++++++++++++++++++++
 drivers/pci/probe.c           |   3 +
 include/linux/pci.h           |  11 +++
 include/uapi/linux/pci_regs.h |  14 ++-
 8 files changed, 260 insertions(+), 1 deletion(-)
 create mode 100644 drivers/pci/pcie/pcie_ptm.c

-- 
2.7.3


^ permalink raw reply	[flat|nested] 21+ messages in thread
* [RFC v4] PCI: PTM Driver
@ 2016-04-19  6:29 Yong, Jonathan
  2016-04-19  6:29 ` [PATCH] PCI: PTM preliminary implementation Yong, Jonathan
  0 siblings, 1 reply; 21+ messages in thread
From: Yong, Jonathan @ 2016-04-19  6:29 UTC (permalink / raw)
  To: linux-pci; +Cc: jonathan.yong, bhelgaas

Hello LKML,

This is a preliminary implementation of the PTM[1] support driver. This driver
has only been tested against a virtual PCI bus since there are no known
endpoints utilizing it yet.

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/disabled individually (enable by default).

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.

Changes since v3:
* Clearing CONFIG_PCIE_PTM now completely prevents the driver from being built.
* Renamed pci_*_ptm_sysfs to pcie_ptm_*_sysfs_dev_files for consistency.
* Removed useless prototypes.
* Driver no longer checks PTM capability version
* PCI_EXT_CAP_ID_MAX updated to include PTM (0x1F)

Yong, Jonathan (1):
  PCI: PTM preliminary implementation

 drivers/pci/pci-sysfs.c       |   7 ++
 drivers/pci/pci.h             |  20 +++++
 drivers/pci/pcie/Kconfig      |   9 ++
 drivers/pci/pcie/Makefile     |   3 +
 drivers/pci/pcie/pcie_ptm.c   | 194 ++++++++++++++++++++++++++++++++++++++++++
 drivers/pci/probe.c           |   3 +
 include/linux/pci.h           |  11 +++
 include/uapi/linux/pci_regs.h |  14 ++-
 8 files changed, 260 insertions(+), 1 deletion(-)
 create mode 100644 drivers/pci/pcie/pcie_ptm.c

-- 
2.7.3


^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2016-05-10  3:52 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-03-11  7:26 [RFC] PCI: PTM Driver Yong, Jonathan
2016-03-11  7:26 ` [PATCH] PCI: PTM preliminary implementation Yong, Jonathan
2016-03-11 15:53   ` Bjorn Helgaas
2016-03-14  7:44     ` Yong, Jonathan
2016-03-14 15:42       ` Bjorn Helgaas
2016-03-15  8:27         ` Yong, Jonathan
2016-03-15 13:36           ` Bjorn Helgaas
  -- strict thread matches above, loose matches on Subject: below --
2016-03-23  2:47 [RFC v2] PCI: PTM Driver Yong, Jonathan
2016-03-23  2:47 ` [PATCH] PCI: PTM preliminary implementation Yong, Jonathan
2016-03-23  3:11   ` kbuild test robot
2016-03-23  3:57   ` kbuild test robot
2016-03-23  4:04 [RFC v3] PCI: PTM Driver Yong, Jonathan
2016-03-23  4:04 ` [PATCH] PCI: PTM preliminary implementation Yong, Jonathan
2016-04-12  4:23   ` Bjorn Helgaas
2016-04-12  4:48     ` Bjorn Helgaas
2016-04-19  6:24 [RFC v4] PCI: PTM Driver Yong, Jonathan
2016-04-19  6:24 ` [PATCH] PCI: PTM preliminary implementation Yong, Jonathan
2016-04-19  6:29 [RFC v4] PCI: PTM Driver Yong, Jonathan
2016-04-19  6:29 ` [PATCH] PCI: PTM preliminary implementation Yong, Jonathan
2016-04-29 16:20   ` Bjorn Helgaas
2016-04-30 12:19     ` Bjorn Helgaas
2016-05-10  3:52     ` Yong, Jonathan
2016-05-08  2:38   ` Bjorn Helgaas
2016-05-09  3:11     ` Yong, Jonathan
2016-05-09 13:35       ` Bjorn Helgaas

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).