[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a889a47f-5f44-1ae6-1ab7-3b7e7011b4f7@ti.com>
Date: Mon, 16 Jan 2023 12:42:33 +0530
From: Siddharth Vadapalli <s-vadapalli@...com>
To: Roger Quadros <rogerq@...nel.org>
CC: <davem@...emloft.net>, <edumazet@...gle.com>, <kuba@...nel.org>,
<pabeni@...hat.com>, <robh+dt@...nel.org>,
<krzysztof.kozlowski@...aro.org>,
<krzysztof.kozlowski+dt@...aro.org>, <nm@...com>,
<kristo@...nel.org>, <vigneshr@...com>, <nsekhar@...com>,
<netdev@...r.kernel.org>, <devicetree@...r.kernel.org>,
<linux-kernel@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>, <srk@...com>,
<s-vadapalli@...com>
Subject: Re: [PATCH net-next 5/5] arm64: dts: ti: k3-am625-sk: Add cpsw3g cpts
PPS support
Roger,
On 13/01/23 15:48, Roger Quadros wrote:
> Hi,
>
> On 11/01/2023 13:44, Siddharth Vadapalli wrote:
>> The CPTS driver is capable of configuring GENFy (Periodic Signal Generator
>> Function) present in the CPTS module, to generate periodic output signals
>> with a custom time period. In order to generate a PPS signal on the GENFy
>> output, the device-tree property "ti,pps" has to be used. The "ti,pps"
>> property is used to declare the mapping between the CPTS HWx_TS_PUSH
>> (Hardware Timestamp trigger) input and the GENFy output that is configured
>> to generate a PPS signal. The mapping is of the form:
>> <x-1 y>
>> where the value x corresponds to HWx_TS_PUSH input (1-based indexing) and
>> the value y corresponds to GENFy (0-based indexing).
>
> You mean there is no HWx_TX_PUSH0 pin? so user needs to use 0 for HWx_TX_PUSH1 pin?
The HWx_TX_PUSH pins correspond to the cpts_hw1_push, cpts_hw2_push,...,
cpts_hw8_push pins. The names are documented at:
Link:
https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am62x/interrupt_cfg.html#timesync-event-router0-interrupt-router-output-destinations
Thus, considering that the documentation uses 1-based indexing, I wanted to
indicate that the driver expects 0-based indexing, and therefore the user would
have to provide (x-1) for cpsw_hwx_push pin.
>
> Can you please define macros for HWx_TS_PUSH and GENFy so we avoid
> human error with this different indexing methods?
>
> DT should contain the name exactly in hardware.
>
> So if pin is called HWx_TX_PUSH1 in hardware then DT should contain HWx_TX_PUSH(1).
The pins are called HW1_TX_PUSH, HW2_TX_PUSH and so on. This 1-based indexing is
followed in the Technical Reference Manual. Similarly, the documentation in the
link above also uses 1-based indexing: cpts_hw1_push, cpts_hw2_push, and so on.
However, for the GENFy pins, the documentation consistently uses 0-based
indexing. Thus, the driver expects indices that are 0-based and the user is
expected to convert the x to x-1 for the HWx_TX_PUSH pins while the y in GENFy
pins can be used directly as it is already 0-based indexing.
>
>>
>> To verify that the signal is a PPS signal, the GENFy output signal is fed
>> into the CPTS HWx_TS_PUSH input, which generates a timestamp event on the
>> rising edge of the GENFy signal. The GENFy output signal can be routed to
>> the HWx_TS_PUSH input by using the Time Sync Router. This is done by
>> mentioning the mapping between the GENFy output and the HWx_TS_PUSH input
>> within the "timesync_router" device-tree node.
>>
>> The Input Sources to the Time Sync Router are documented at: [1]
>> The Output Destinations of the Time Sync Router are documented at: [2]
>>
>> The PPS signal can be verified using testptp and ppstest tools as follows:
>> # ./testptp -d /dev/ptp0 -P 1
>> pps for system time request okay
>> # ./ppstest /dev/pps0
>> trying PPS source "/dev/pps0"
>> found PPS source "/dev/pps0"
>> ok, found 1 source(s), now start fetching data...
>> source 0 - assert 48.000000013, sequence: 8 - clear 0.000000000, sequence: 0
>> source 0 - assert 49.000000013, sequence: 9 - clear 0.000000000, sequence: 0
>> source 0 - assert 50.000000013, sequence: 10 - clear 0.000000000, sequence: 0
>>
>> Add an example in the device-tree, enabling PPS generation on GENF1. The
>> HW3_TS_PUSH Timestamp trigger input is used to verify the PPS signal.
>>
>> [1]
>> Link: https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am62x/interrupt_cfg.html#timesync-event-router0-interrupt-router-input-sources
>> [2]
>> Link: https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am62x/interrupt_cfg.html#timesync-event-router0-interrupt-router-output-destinations
>>
>> Signed-off-by: Siddharth Vadapalli <s-vadapalli@...com>
>> ---
>> arch/arm64/boot/dts/ti/k3-am625-sk.dts | 20 ++++++++++++++++++++
>> 1 file changed, 20 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/ti/k3-am625-sk.dts b/arch/arm64/boot/dts/ti/k3-am625-sk.dts
>> index 4f179b146cab..962a922cc94b 100644
>> --- a/arch/arm64/boot/dts/ti/k3-am625-sk.dts
>> +++ b/arch/arm64/boot/dts/ti/k3-am625-sk.dts
>> @@ -366,6 +366,10 @@ &cpsw3g {
>> pinctrl-names = "default";
>> pinctrl-0 = <&main_rgmii1_pins_default
>> &main_rgmii2_pins_default>;
>> +
>> + cpts@...00 {
>> + ti,pps = <2 1>;
>> + };
>> };
>>
>> &cpsw_port1 {
>> @@ -464,3 +468,19 @@ partition@...0000 {
>> };
>> };
>> };
>> +
>> +#define TS_OFFSET(pa, val) (0x4+(pa)*4) (0x10000 | val)
>
> Should this go in ./include/dt-bindings/pinctrl/k3.h ?
> That way every board DT file doesn't have to define it.
>
> The name should be made more platform specific.
> e.g. K3_TS_OFFSET if it is the same for all K3 platforms.
> If not then please add Platform name instead of K3.
The offsets are board specific. If it is acceptable, I will add board specific
macro for the TS_OFFSET definition in the ./include/dt-bindings/pinctrl/k3.h
file. Please let me know.
Regards,
Siddharth.
Powered by blists - more mailing lists