Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <BYAPR11MB3240F382BD180FF90C7DF0B9E1069@BYAPR11MB3240.namprd11.prod.outlook.com>
 <7de35859-97ab-8e88-f590-d5851b81773b@nvidia.com> <BYAPR11MB32405F4FA22BB47BD03C8F18E10C9@BYAPR11MB3240.namprd11.prod.outlook.com>
 <CACRpkdbY5aU3OTufA0q+N7Pwm0shGgnjScAGR_96oo9XdgBDhQ@mail.gmail.com> <BYAPR11MB3240CE6547117D138B1A112DE1129@BYAPR11MB3240.namprd11.prod.outlook.com>
In-Reply-To: <BYAPR11MB3240CE6547117D138B1A112DE1129@BYAPR11MB3240.namprd11.prod.outlook.com>
From:   Linus Walleij <linus.walleij@linaro.org>
Date:   Wed, 30 Nov 2022 10:00:49 +0100
Message-ID: <CACRpkdbOPbqot+Yf6i_EayPrRn2S+ZTA1FzZ-0OkjXjR5UZvqw@mail.gmail.com>
Subject: Re: Intel timed i/o driver in HTE
To:     "N, Pandith" <pandith.n@intel.com>, Johan Hovold <johan@kernel.org>
Cc:     Dipen Patel <dipenp@nvidia.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "Hall, Christopher S" <christopher.s.hall@intel.com>,
        "Gross, Mark" <mark.gross@intel.com>,
        "Sangannavar, Mallikarjunappa" 
        <mallikarjunappa.sangannavar@intel.com>,
        "D, Lakshmi Sowjanya" <lakshmi.sowjanya.d@intel.com>,
        "T R, Thejesh Reddy" <thejesh.reddy.t.r@intel.com>,
        "andriy.shevchenko@linux.intel.com" 
        <andriy.shevchenko@linux.intel.com>,
        "timestamp@lists.linux.dev" <timestamp@lists.linux.dev>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, Nov 29, 2022 at 7:10 PM N, Pandith <pandith.n@intel.com> wrote:

> Intel  timed i/o is mainly intended for couple of functionalities.
> 1. Input event capture with timestamping

I understand this part, and it is handled by the HTE subsystem.

> 2. Generate single shot or periodic pulse train
(...)
> c. Most importantly, precise time synchronization between devices/sub-systems
> Ex : Share precise time from a GPS receiver to the network or
>        Synchronize processor clock with external signal.

So I think this is the actual use case of the output mode. The
pulse train output by HTE is to share precise time to GPS receivers.

So what about putting that part into drivers/gnss?
GNSS Global Navigation Satellite Subsystem like GPS etc

If this is the only usecase, that is where it should go, along
with the serial or whatever transport driver is used with the
GPS. I don't think this is a generic functionality (such as
GPIO) at all, but rather a very application-specific use case
which will only be used for GPS time synchronization.

If the timed output has other use cases - and I mean HAVE
other use cases, not COULD HAVE other use cases - then
we can discuss generalizations. There is no point of designing
upfront abstractions that never get used.

Yours,
Linus Walleij