Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Received-SPF: Pass (protection.outlook.com: domain of nvidia.com designates
 216.228.112.35 as permitted sender) receiver=protection.outlook.com;
 client-ip=216.228.112.35; helo=mail.nvidia.com;
Subject: Re: GTE - The hardware timestamping engine
To:     Richard Cochran <richardcochran@gmail.com>,
        Arnd Bergmann <arnd@arndb.de>
CC:     Linus Walleij <linus.walleij@linaro.org>,
        Kent Gibson <warthog618@gmail.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "thierry.reding@gmail.com" <thierry.reding@gmail.com>,
        Jon Hunter <jonathanh@nvidia.com>,
        "Bartosz Golaszewski" <bgolaszewski@baylibre.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
        linux-tegra <linux-tegra@vger.kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Networking <netdev@vger.kernel.org>
References: <4c46726d-fa35-1a95-4295-bca37c8b6fe3@nvidia.com>
 <CACRpkdbmqww6UQ8CFYo=+bCtVYBJwjMxVixc4vS6D3B+dUHScw@mail.gmail.com>
 <CAK8P3a30CdRKGe++MyBVDLW=p9E1oS+C7d7W4jLE01TAA4k+GA@mail.gmail.com>
 <20210320153855.GA29456@hoboy.vegasvil.org>
From:   Dipen Patel <dipenp@nvidia.com>
Message-ID: <a58a0ec2-9da8-92bc-c08e-38b1bed6f757@nvidia.com>
Date:   Mon, 22 Mar 2021 13:33:38 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <20210320153855.GA29456@hoboy.vegasvil.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Mar 2021 20:29:11.9419
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1790cc9e-c4ad-40de-767f-08d8ed712766
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=43083d15-7273-40c1-b7db-39efd9ccc17a;Ip=[216.228.112.35];Helo=[mail.nvidia.com]
X-MS-Exchange-CrossTenant-AuthSource: BN8NAM11FT007.eop-nam11.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR12MB1798
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Hi Richard,

Thanks for your input and time. Please see below follow up.

On 3/20/21 8:38 AM, Richard Cochran wrote:
> On Sat, Mar 20, 2021 at 01:44:20PM +0100, Arnd Bergmann wrote:
>> Adding Richard Cochran as well, for drivers/ptp/, he may be able to
>> identify whether this should be integrated into that framework in some
>> form.
> 
> I'm not familiar with the GTE, but it sounds like it is a (free
> running?) clock with time stamping inputs.  If so, then it could
> expose a PHC.  That gets you functionality:
> 
> - clock_gettime() and friends
> - comparison ioctl between GTE clock and CLOCK_REALTIME
> - time stamping channels with programmable input selection
> 
GTE gets or rather records the timestamps from the TSC
(timestamp system coutner) so its not attached to GTE as any
one can access TSC, so not sure if we really need to implement PHC
and/or clock_* and friends for the GTE. I believe burden to find correlation
between various clock domains should be on the clients, consider below
example.

Networking client has access to both PTP and GTE, it would be its job
to find the correlations if that is at all needed based on whatever
use case that client serves. GTE in above may come in picture if said client
has some GPIO configured and wants timestamp on it.

Sorry if I misunderstood anything, you can elaborate more as I am also
interested in how GTE can fit in PTP framework and which usecase it can
help doing so.

> The mentioned applications (robotics and autonomous vehicle, so near
> and dear to my heart) surely already use the PHC API for dealing with
> network and system time sources, and so exposing the GTE as a PHC
> means that user space programs will have a consistent API.
> 
> [ The only drawback I can see is the naming of the C language
>   identifiers in include/uapi/linux/ptp_clock.h.  If that bothers
>   people, then these can be changed to something more generic while
>   keeping compatibility aliases. ]
> 
> Thanks,
> Richard
> 

Thanks,
Best Regards,
Dipen Patel