[RFC,v3,00/11] Add support for Intel PPS Generator

  From: Lakshmi Sowjanya D <lakshmi.sowjanya.d@intel.com>

The goal of the PPS(Pulse Per Second) hardware/software is to generate a
signal from the system on a wire so that some third-party hardware can
observe that signal and judge how close the system's time is to another
system or piece of hardware.

Existing methods (like parallel ports) require software to flip a bit at
just the right time to create a PPS signal. Many things can prevent
software from doing this precisely. This (Timed I/O) method is better
because software only "arms" the hardware in advance and then depends on
the hardware to "fire" and flip the signal at just the right time.

To generate a PPS signal with this new hardware, the kernel wakes up
twice a second, once for 1->0 edge and other for the 0->1 edge. It does
this shortly (~10ms) before the actual change in the signal needs to be
made. It computes the TSC value at which edge will happen, convert to a
value hardware understands and program this value to Timed I/O hardware.
The actual edge transition happens without any further action from the
kernel.

The result here is a signal coming out of the system that is roughly
1,000 times more accurate than the old methods. If the system is heavily
loaded, the difference in accuracy is larger in old methods.
Facebook and Google are the customers that use this feature.

Application Interface:
The API to use Timed I/O is very simple. It is enabled and disabled by
writing a '1' or '0' value to the sysfs enable attribute associated with
the Timed I/O PPS device. Each Timed I/O pin is represented by a PPS
device. When enabled, a pulse-per-second(PPS) synchronized with the
system clock is continuously produced on the Timed I/O pin, otherwise it
is pulled low.

The Timed I/O signal on the motherboard is enabled in the BIOS setup.

This patchset is dependent on [1]

References:
https://en.wikipedia.org/wiki/Pulse-per-second_signal
https://drive.google.com/file/d/1vkBRRDuELmY8I3FlfOZaEBp-DxLW6t_V/view
https://youtu.be/JLUTT-lrDqw

Patch 1 adds base clock properties in clocksource structure
Patch 2 adds function to convert realtime to base clock
Patch 3 - 7 removes reference to convert_art_to_tsc function across
drivers
Patch 8 removes the convert art to tsc functions which are no longer
used
Patch 9 adds the pps(pulse per second) generator tio driver to the pps
subsystem.
Patch 10 documentation and usage of the pps tio generator module.
Patch 11 includes documentation for sysfs interface.

[1] https://lore.kernel.org/netdev/20231215220612.173603-2-peter.hilber@opensynergy.com/T/

Please help to review the changes.

Thanks in advance,
Sowjanya

Changes from v2:
 - Split patch 1 to remove the functions in later stages.
 - Include required headers in pps_gen_tio.

Lakshmi Sowjanya D (6):
  x86/tsc: Add base clock properties in clocksource structure
  timekeeping: Add function to convert realtime to base clock
  x86/tsc: Remove art to tsc conversion functions which are obsolete
  pps: generators: Add PPS Generator TIO Driver
  Documentation: driver-api: pps: Add Intel Timed I/O PPS generator
  ABI: pps: Add ABI documentation for Intel TIO

Thomas Gleixner (5):
  e10002: remove convert_art_to_tsc()
  igc: remove convert_art_to_tsc()
  stmmac: intel: remove convert_art_to_tsc()
  ALSA: hda: remove convert_art_to_tsc()
  ice/ptp: remove convert_art_to_tsc()

 .../ABI/testing/sysfs-platform-pps-tio        |   7 +
 Documentation/driver-api/pps.rst              |  22 ++
 arch/x86/include/asm/tsc.h                    |   3 -
 arch/x86/kernel/tsc.c                         |  94 ++-----
 drivers/net/ethernet/intel/e1000e/ptp.c       |   3 +-
 drivers/net/ethernet/intel/ice/ice_ptp.c      |   2 +-
 drivers/net/ethernet/intel/igc/igc_ptp.c      |   6 +-
 .../net/ethernet/stmicro/stmmac/dwmac-intel.c |   3 +-
 drivers/pps/generators/Kconfig                |  16 ++
 drivers/pps/generators/Makefile               |   1 +
 drivers/pps/generators/pps_gen_tio.c          | 245 ++++++++++++++++++
 include/linux/clocksource.h                   |  27 ++
 include/linux/clocksource_ids.h               |   1 +
 include/linux/timekeeping.h                   |   6 +
 kernel/time/timekeeping.c                     | 112 +++++++-
 sound/pci/hda/hda_controller.c                |   3 +-
 16 files changed, 466 insertions(+), 85 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-platform-pps-tio
 create mode 100644 drivers/pps/generators/pps_gen_tio.c
  

On Wed, Jan 03, 2024 at 05:25:51PM +0530, lakshmi.sowjanya.d@intel.com wrote:
> From: Lakshmi Sowjanya D <lakshmi.sowjanya.d@intel.com>
> 
> The goal of the PPS(Pulse Per Second) hardware/software is to generate a
> signal from the system on a wire so that some third-party hardware can
> observe that signal and judge how close the system's time is to another
> system or piece of hardware.
> 
> Existing methods (like parallel ports) require software to flip a bit at
> just the right time to create a PPS signal. Many things can prevent
> software from doing this precisely. This (Timed I/O) method is better
> because software only "arms" the hardware in advance and then depends on
> the hardware to "fire" and flip the signal at just the right time.
> 
> To generate a PPS signal with this new hardware, the kernel wakes up
> twice a second, once for 1->0 edge and other for the 0->1 edge. It does
> this shortly (~10ms) before the actual change in the signal needs to be
> made. It computes the TSC value at which edge will happen, convert to a
> value hardware understands and program this value to Timed I/O hardware.
> The actual edge transition happens without any further action from the
> kernel.
> 
> The result here is a signal coming out of the system that is roughly
> 1,000 times more accurate than the old methods. If the system is heavily
> loaded, the difference in accuracy is larger in old methods.
> Facebook and Google are the customers that use this feature.
> 
> Application Interface:
> The API to use Timed I/O is very simple. It is enabled and disabled by
> writing a '1' or '0' value to the sysfs enable attribute associated with
> the Timed I/O PPS device. Each Timed I/O pin is represented by a PPS
> device. When enabled, a pulse-per-second(PPS) synchronized with the
> system clock is continuously produced on the Timed I/O pin, otherwise it
> is pulled low.
> 
> The Timed I/O signal on the motherboard is enabled in the BIOS setup.

At some point you should announce v1 of the series. RFC is usually being
neglected by many (busy) maintainers.
  

> -----Original Message-----
> From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> Sent: Saturday, January 6, 2024 8:50 PM
> To: D, Lakshmi Sowjanya <lakshmi.sowjanya.d@intel.com>
> Cc: tglx@linutronix.de; jstultz@google.com; giometti@enneenne.com;
> corbet@lwn.net; linux-kernel@vger.kernel.org; x86@kernel.org;
> netdev@vger.kernel.org; linux-doc@vger.kernel.org; intel-wired-
> lan@lists.osuosl.org; Dong, Eddie <eddie.dong@intel.com>; Hall, Christopher S
> <christopher.s.hall@intel.com>; Brandeburg, Jesse
> <jesse.brandeburg@intel.com>; davem@davemloft.net;
> alexandre.torgue@foss.st.com; joabreu@synopsys.com;
> mcoquelin.stm32@gmail.com; perex@perex.cz; linux-sound@vger.kernel.org;
> Nguyen, Anthony L <anthony.l.nguyen@intel.com>; N, Pandith
> <pandith.n@intel.com>; Sangannavar, Mallikarjunappa
> <mallikarjunappa.sangannavar@intel.com>; T R, Thejesh Reddy
> <thejesh.reddy.t.r@intel.com>
> Subject: Re: [RFC PATCH v3 00/11] Add support for Intel PPS Generator
> 
> On Wed, Jan 03, 2024 at 05:25:51PM +0530, lakshmi.sowjanya.d@intel.com
> wrote:
> > From: Lakshmi Sowjanya D <lakshmi.sowjanya.d@intel.com>
> >
> > The goal of the PPS(Pulse Per Second) hardware/software is to generate
> > a signal from the system on a wire so that some third-party hardware
> > can observe that signal and judge how close the system's time is to
> > another system or piece of hardware.
> >
> > Existing methods (like parallel ports) require software to flip a bit
> > at just the right time to create a PPS signal. Many things can prevent
> > software from doing this precisely. This (Timed I/O) method is better
> > because software only "arms" the hardware in advance and then depends
> > on the hardware to "fire" and flip the signal at just the right time.
> >
> > To generate a PPS signal with this new hardware, the kernel wakes up
> > twice a second, once for 1->0 edge and other for the 0->1 edge. It
> > does this shortly (~10ms) before the actual change in the signal needs
> > to be made. It computes the TSC value at which edge will happen,
> > convert to a value hardware understands and program this value to Timed I/O
> hardware.
> > The actual edge transition happens without any further action from the
> > kernel.
> >
> > The result here is a signal coming out of the system that is roughly
> > 1,000 times more accurate than the old methods. If the system is
> > heavily loaded, the difference in accuracy is larger in old methods.
> > Facebook and Google are the customers that use this feature.
> >
> > Application Interface:
> > The API to use Timed I/O is very simple. It is enabled and disabled by
> > writing a '1' or '0' value to the sysfs enable attribute associated
> > with the Timed I/O PPS device. Each Timed I/O pin is represented by a
> > PPS device. When enabled, a pulse-per-second(PPS) synchronized with
> > the system clock is continuously produced on the Timed I/O pin,
> > otherwise it is pulled low.
> >
> > The Timed I/O signal on the motherboard is enabled in the BIOS setup.
> 
> At some point you should announce v1 of the series. RFC is usually being
> neglected by many (busy) maintainers.

This patch series is dependent on https://lore.kernel.org/netdev/20231215220612.173603-2-peter.hilber@opensynergy.com/T/ which is RFC.

Regards,
Sowjanya
> 
> --
> With Best Regards,
> Andy Shevchenko
>
  

On 09.01.24 07:31, D, Lakshmi Sowjanya wrote:
> 
> 
>> -----Original Message-----
>> From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>> Sent: Saturday, January 6, 2024 8:50 PM
>> To: D, Lakshmi Sowjanya <lakshmi.sowjanya.d@intel.com>
>> Cc: tglx@linutronix.de; jstultz@google.com; giometti@enneenne.com;
>> corbet@lwn.net; linux-kernel@vger.kernel.org; x86@kernel.org;
>> netdev@vger.kernel.org; linux-doc@vger.kernel.org; intel-wired-
>> lan@lists.osuosl.org; Dong, Eddie <eddie.dong@intel.com>; Hall, Christopher S
>> <christopher.s.hall@intel.com>; Brandeburg, Jesse
>> <jesse.brandeburg@intel.com>; davem@davemloft.net;
>> alexandre.torgue@foss.st.com; joabreu@synopsys.com;
>> mcoquelin.stm32@gmail.com; perex@perex.cz; linux-sound@vger.kernel.org;
>> Nguyen, Anthony L <anthony.l.nguyen@intel.com>; N, Pandith
>> <pandith.n@intel.com>; Sangannavar, Mallikarjunappa
>> <mallikarjunappa.sangannavar@intel.com>; T R, Thejesh Reddy
>> <thejesh.reddy.t.r@intel.com>
>> Subject: Re: [RFC PATCH v3 00/11] Add support for Intel PPS Generator
>>
[...]
>> At some point you should announce v1 of the series. RFC is usually being
>> neglected by many (busy) maintainers.
> 
> This patch series is dependent on https://lore.kernel.org/netdev/20231215220612.173603-2-peter.hilber@opensynergy.com/T/ which is RFC.

So I understand my dependency series being RFC prevents the PPS series from
dropping the RFC tag (correct me if I am wrong).

I plan to send out a non-RFC version of the dependency series next. So far
I think there will only be polishing changes. Due to testing being some
effort, I wanted to test and send it together with some other series.

But if this is blocking the PPS series, I think I could send out a non-RFC
version of the dependency series earlier (by the end of January?). Please
let me know what would align with the PPS series timeline.

Regards,

Peter

> 
> Regards,
> Sowjanya
>>
>> --
>> With Best Regards,
>> Andy Shevchenko
>>
>
  

> -----Original Message-----
> From: Peter Hilber <peter.hilber@opensynergy.com>
> Sent: Thursday, January 11, 2024 5:15 PM
> To: D, Lakshmi Sowjanya <lakshmi.sowjanya.d@intel.com>; Andy Shevchenko
> <andriy.shevchenko@linux.intel.com>
> Cc: tglx@linutronix.de; jstultz@google.com; giometti@enneenne.com;
> corbet@lwn.net; linux-kernel@vger.kernel.org; x86@kernel.org;
> netdev@vger.kernel.org; linux-doc@vger.kernel.org; intel-wired-
> lan@lists.osuosl.org; Dong, Eddie <eddie.dong@intel.com>; Hall, Christopher S
> <christopher.s.hall@intel.com>; Brandeburg, Jesse
> <jesse.brandeburg@intel.com>; davem@davemloft.net;
> alexandre.torgue@foss.st.com; joabreu@synopsys.com;
> mcoquelin.stm32@gmail.com; perex@perex.cz; linux-sound@vger.kernel.org;
> Nguyen, Anthony L <anthony.l.nguyen@intel.com>; N, Pandith
> <pandith.n@intel.com>; Sangannavar, Mallikarjunappa
> <mallikarjunappa.sangannavar@intel.com>; T R, Thejesh Reddy
> <thejesh.reddy.t.r@intel.com>
> Subject: Re: [RFC PATCH v3 00/11] Add support for Intel PPS Generator
> 
> On 09.01.24 07:31, D, Lakshmi Sowjanya wrote:
> >
> >
> >> -----Original Message-----
> >> From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> >> Sent: Saturday, January 6, 2024 8:50 PM
> >> To: D, Lakshmi Sowjanya <lakshmi.sowjanya.d@intel.com>
> >> Cc: tglx@linutronix.de; jstultz@google.com; giometti@enneenne.com;
> >> corbet@lwn.net; linux-kernel@vger.kernel.org; x86@kernel.org;
> >> netdev@vger.kernel.org; linux-doc@vger.kernel.org; intel-wired-
> >> lan@lists.osuosl.org; Dong, Eddie <eddie.dong@intel.com>; Hall,
> >> Christopher S <christopher.s.hall@intel.com>; Brandeburg, Jesse
> >> <jesse.brandeburg@intel.com>; davem@davemloft.net;
> >> alexandre.torgue@foss.st.com; joabreu@synopsys.com;
> >> mcoquelin.stm32@gmail.com; perex@perex.cz;
> >> linux-sound@vger.kernel.org; Nguyen, Anthony L
> >> <anthony.l.nguyen@intel.com>; N, Pandith <pandith.n@intel.com>;
> >> Sangannavar, Mallikarjunappa <mallikarjunappa.sangannavar@intel.com>;
> >> T R, Thejesh Reddy <thejesh.reddy.t.r@intel.com>
> >> Subject: Re: [RFC PATCH v3 00/11] Add support for Intel PPS Generator
> >>
> [...]
> >> At some point you should announce v1 of the series. RFC is usually
> >> being neglected by many (busy) maintainers.
> >
> > This patch series is dependent on
> https://lore.kernel.org/netdev/20231215220612.173603-2-
> peter.hilber@opensynergy.com/T/ which is RFC.
> 
> So I understand my dependency series being RFC prevents the PPS series from
> dropping the RFC tag (correct me if I am wrong).
> 
> I plan to send out a non-RFC version of the dependency series next. So far I think
> there will only be polishing changes. Due to testing being some effort, I wanted
> to test and send it together with some other series.
> 
> But if this is blocking the PPS series, I think I could send out a non-RFC version of
> the dependency series earlier (by the end of January?). Please let me know what
> would align with the PPS series timeline.

Thanks Peter,
This timeline should be okay. We will also send non-RFC v1 by the same time.

Regards,
Sowjanya

> Regards,
> 
> Peter
> 
> >
> > Regards,
> > Sowjanya
> >>
> >> --
> >> With Best Regards,
> >> Andy Shevchenko
> >>
> >