Re: [PATCH net-next 01/12] dt-bindings: ptp: add bindings for NETC Timer

[Vladimir Oltean <vladimir.oltean@nxp.com>]

On Mon, Jul 14, 2025 at 04:56:41PM +0300, Vladimir Oltean wrote:
> On Mon, Jul 14, 2025 at 04:22:51PM +0300, Wei Fang wrote:
> > > On Mon, Jul 14, 2025 at 01:43:49PM +0300, Wei Fang wrote:
> > > > > On Mon, Jul 14, 2025 at 01:28:04PM +0300, Wei Fang wrote:
> > > > > > I do not understand, the property is to indicate which pin the board is
> > > > > > used to out PPS signal, as I said earlier, these pins are multiplexed with
> > > > > > other devices, so different board design may use different pins to out
> > > > > > this PPS signal.
> > > > >
> > > > > Did you look at the 'pins' API in ptp, as used by other drivers, to set
> > > > > a function per pin?
> > > >
> > > > ptp_set_pinfunc()?
> > > 
> > > You're in the right area, but ptp_set_pinfunc() is an internal function.
> > > I was specifically referring to struct ptp_clock_info :: pin_config, the
> > > verify() function, etc.
> > 
> > I don't think these can meet customer's requirement, the PPS pin depends
> > on the board design. If I understand correctly, these can only indicate
> > whether the specified pin index is in range, or whether the pin is already
> > occupied by another PTP function.
> > 
> > However, these pins are multiplexed with other devices, such as FLEXIO,
> > CAN, etc. If the board is designed to assign this pin to other devices, then
> > this pin cannot output the PPS signal. For for this use case, we need to
> > specify a PPS pin which can output PPS signal.
> 
> Ok, apologies if I misunderstood the purpose of this device tree property
> as affecting the function of the NETC 1588 timer IP pins. You gave me
> this impression because I followed the code and I saw that "nxp,pps-channel"
> is used to select in the PTP driver which FIPER block gets configured to
> emit PPS. And I commented that maybe you don't need "nxp,pps-channel" at all,
> because:
> - PTP_CLK_REQ_PPS doesn't do what you think it does
> - PTP_CLK_REQ_PEROUT does use the pin API to describe that one of the
>   1588 timer block's pins can be used for the periodic output function

Just to expand on the last point, maybe it's not clear enough.

This is how the Felix/Ocelot switch presents itself on LS1028A. There
are four pins with unspecified functions at boot time.

$ ls -la /sys/class/ptp/ptp1/pins/
total 0
drwxr-xr-x 2 root root    0 Mar  6 16:56 .
drwxr-xr-x 4 root root    0 Mar  6 16:56 ..
-rw-r--r-- 1 root root 4096 Mar  6 16:56 switch_1588_dat0
-rw-r--r-- 1 root root 4096 Mar  6 16:56 switch_1588_dat1
-rw-r--r-- 1 root root 4096 Mar  6 16:56 switch_1588_dat2
-rw-r--r-- 1 root root 4096 Mar  6 16:56 switch_1588_dat3

And this is how we configure one of the pins (here, 1588_dat0) for
periodic output:

# enum ptp_pin_function
PTP_PF_NONE=0
PTP_PF_EXTTS=1
PTP_PF_PEROUT=2
PTP_PF_PHYSYNC=2

PTP1_CHANNEL0=0
PTP1_PEROUT_START="0 0"
PTP1_PEROUT_PERIOD="1 1"

PTP2_CHANNEL0=0

PTP3_CHANNEL0=0

echo "$PTP_PF_PEROUT $PTP1_CHANNEL0" > /sys/class/ptp/ptp1/pins/switch_1588_dat0
echo "$PTP1_CHANNEL0 $PTP1_PEROUT_START $PTP1_PEROUT_PERIOD" > /sys/class/ptp/ptp1/period

In the case above, it still depends upon system pinmuxing (on LS1028A,
that is handled by the RCW) how/whether switch_1588_dat0 is connected to
an SoC pad or not.

I was just saying that _if_ you were to eliminate the use of PTP_CLK_REQ_PPS
from your driver, _then_ the pins API should be sufficiently flexible
for the user to select which pin is configured for periodic output.