[ahmadexp]

Raspberry Pi 5's RP1 owns GPIO and PIO resources, while its Ethernet MAC
provides a PTP hardware clock (PHC). Linux currently does not expose those
GPIOs through that PHC's standard PTP pin interface, so it cannot timestamp a
reference PPS on a selected GPIO or generate a PHC-aligned PPS output on one.

This series connects the MACB PHC to RP1 PIO, DMA and pin control. Linux PTP
clients such as testptp can map an available GPIO to an external timestamp
input or periodic output. This provides a route for hardware timestamping a
reference PPS in the Ethernet PHC and for outputting a PHC-aligned PPS to
another device, using standard PTP ioctls and no private ABI.

The series:

• Adds a Device Tree binding for the RP1 GEM MACB instance.
• Adds device-scoped RP1 PIO consumer functions and GPIO reservation support.
• Adds MACB PHC callbacks for GPIO0 through GPIO27, two external timestamp
  channels and one periodic output channel.
• Documents the testptp configuration for PPS input, output and simultaneous
  operation.

The first external timestamp channel works without periodic output. A second
input channel needs PEROUT active to provide the PHC anchor. With PEROUT active,
both indexed rising-edge inputs can operate alongside the output on three
distinct GPIOs. The direct channel-0 input path also supports falling-edge and
both-edge requests. GPIOs are selected at runtime by GPIO number, not header
pin number. The kernel PTP UAPI is unchanged.

Validation:

• Built the full ARM64 kernel image, modules and device trees with the feature
  enabled. The counter conversion helper also compiles with W=1.
• Built the standard kernel PTP testptp selftest and validated the MACB
  binding with dt-doc-validate.
• testptp -c on a Pi 5 booted with the candidate reports two external
  timestamp channels, one periodic output and 28 programmable pins.
• The packaged CLI's non-actuating preflight selected GPIO18 on EXTS channel 0,
  GPIO24 on channel 1 and GPIO23 for PEROUT, and confirmed that the pins were
  initially unmapped.
• Earlier candidate tests exercised EXTS and PEROUT sequentially on Pi 5 GPIOs.
  The simultaneous two-input plus output path has not yet received a physical
  waveform test. No comparison against the standard pps-gpio driver has been
  run. These tests establish neither absolute accuracy nor a jitter bound.

The simultaneous input/output path still needs physical qualification with
separate PPS sources on both input GPIOs and a scope or logic analyzer on the
output. CM5, additional GPIO waveforms, sustained duplex operation, failure
recovery under hardware faults and independent timing calibration remain open.

[pelwell]

This is very TL;DR - why don't you start with brief, human-written description of the problem you are trying to solve, followed by a list of the elements involved in the solution. It's also not a good idea to let your AI randomly "improve" things, except in separate commits that are clearly described.

BTW, "BCM" has no part to play in the discussion of GPIOs in the kernel - everything uses GPIO numbers, never (header) pin numbers.

[pelwell]

Why would you not include the full output from pioasm, with the assembly language as comments?

[nbuchwitz]

Did you test this on HW? Ideally test the performance against pps-gpio

[ahmadexp]

@nbuchwitz Yes: two Pi 5s, Saleae Logic Pro 16, 250 MS/s. A 10-minute capture (600 pulses/channel) measured maximum corresponding-pin skew of 68 ns (GPIO18) and 64 ns (GPIO23), with no missing pulses. A retarget alarm occurred after capture. These bench results still need reproduction on the exact PR revision and comparison with pps-gpio.

[ahmadexp]

This is very TL;DR - why don't you start with brief, human-written description of the problem you are trying to solve, followed by a list of the elements involved in the solution. It's also not a good idea to let your AI randomly "improve" things, except in separate commits that are clearly described.

BTW, "BCM" has no part to play in the discussion of GPIOs in the kernel - everything uses GPIO numbers, never (header) pin numbers.

Thanks, I will tighten the description and GPIO terminology.
The goal is to make hardware-timed PPS input/output on Pi 5 GPIOs available, to make enabling useful timing and synchronization applications.
Your RP1 expertise would be valuable, and I would welcome your guidance or contributions to help turn this into a reliable, maintainable feature for the community.

[pelwell]

A description of the problem and the architecture of the solution will provide a framework for an analysis of the submission.

[ahmadexp]

A description of the problem and the architecture of the solution will provide a framework for an analysis of the submission.

Understood. The problem is connecting PPS on Pi 5 GPIOs to the Ethernet PTP hardware clock, allowing external PPS timestamping and clock-aligned PPS output.
The architecture is:

• PIO: detects input edges and generates output pulses on selected GPIOs.
• DMA and the MAC timestamp latch: capture input timing against the Ethernet clock.
• PHC-to-PIO timing conversion: schedules output edges against that same clock.
• MACB driver: exposes this through standard PTP EXTS/PEROUT interfaces.
• PIO and pinctrl providers: manage resource ownership and cleanup.
  The main design question is whether these responsibilities and interfaces are split appropriately. Your feedback on that would be especially helpful.