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

[Wei Fang <wei.fang@nxp.com>]

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

Yes, you are right, PTP_CLK_REQ_PPS is input into the kernel PPS subsystem,
is not used to out PPS signal on external pins. I have found the kernel doc.
I thought PTP_CLK_REQ_PPS can be used to output PPS signal, but now it
seems that many people use it wrongly.

commit d04a53b1c48766665806eb75b73137734abdaa95
Author: Ahmad Fatoum <a.fatoum@pengutronix.de>
Date:   Tue Nov 17 22:38:26 2020 +0100

ptp: document struct ptp_clock_request members

It's arguable most people interested in configuring a PPS signal
want it as external output, not as kernel input. PTP_CLK_REQ_PPS
is for input though. Add documentation to nudge readers into
the correct direction.

> You seem to imply that the "nxp,pps-channel" property affects the
> function of the SoC pads, which may be connected to the NETC 1588 timer
> block or to some other IP. Nothing in the code I saw suggested this
> would be the case, and I still don't see how this is the case - but
> anyway, my bad.
> 
> In this case, echoing Krzysztof's comments: How come it isn't the system
> pinmux driver the one concerned with connecting the SoC pads to the NETC
> 1588 timer or to FlexIO, CAN etc? The pinmux driver controls the pads,
> the NETC timer controls its block's pins, regardless of how they are
> routed further.
> 

pinmux can select which device to use this pin for, but this is the
configuration inside SoC. For the outside, depending on the design
of the board, for example, pin0 is connected to a CAN-related device,
then in fact this pin can only be used by CAN.

> (reductio ad absurdum) Among the other devices which are muxed to these
> SoC pads, why is the NETC 1588 timer responsible of controlling the
> muxing, and not FlexIO or CAN? Something is illogical.