Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Mon, 2 Mar 2020 18:01:48 -0800
From:   "Christopher S. Hall" <christopher.s.hall@intel.com>
To:     Richard Cochran <richardcochran@gmail.com>
Cc:     netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
        tglx@linutronix.de, hpa@zytor.com, mingo@redhat.com,
        x86@kernel.org, jacob.e.keller@intel.com, davem@davemloft.net,
        sean.v.kelley@intel.com
Subject: Re: [Intel PMC TGPIO Driver 0/5] Add support for Intel PMC Time GPIO
 Driver with PHC interface changes to support additional H/W Features
Message-ID: <20200303020148.GB15531@skl-build>
References: <20191211214852.26317-1-christopher.s.hall@intel.com>
 <20200203040838.GA5851@localhost>
 <20200225233707.GA32079@skl-build>
 <20200226024707.GA10271@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200226024707.GA10271@localhost>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Richard,

On Tue, Feb 25, 2020 at 06:47:07PM -0800, Richard Cochran wrote:
> On Tue, Feb 25, 2020 at 03:37:07PM -0800, Christopher S. Hall wrote:
> > On Sun, Feb 02, 2020 at 08:08:38PM -0800, Richard Cochran wrote:
> > > The TGPIO input clock, the ART, is a free running counter, but you
> > > want to support frequency adjustments.  Use a timecounter cyclecounter
> > > pair.
> > 
> > I'm concerned about the complexity that the timecounter adds to
> > the driver. Specifically, the complexity of dealing with any rate mismatches
> > between the timecounter and the periodic output signal. The phase
> > error between the output and timecounter needs to be zero.
> 
> If I understood correctly, the device's outputs are generated from a
> non-adjustable counter.  So, no matter what, you will have the problem
> of changing the pulse period in concert with the user changing the
> desired frequency.
> 

> > This leaves the PHC API behavior as it is currently and uses the frequency
> > adjust API to adjust the output rate.
> > 
> > > Let the user dial a periodic output signal in the normal way.
> > > 
> > > Let the user change the frequency in the normal way, and during this
> > > call, adjust the counter values accordingly.
> > 
> > Yes to both of the above.
> 
> So, why then do you need this?
> 
> +#define PTP_EVENT_COUNT_TSTAMP2 \
> +       _IOWR(PTP_CLK_MAGIC, 19, struct ptp_event_count_tstamp)
> 
> If you can make the device work with the existing user space API,
> 
> 	ioctl(fd, PTP_PEROUT_REQUEST2, ...);
> 	while (1) {
> 		clock_adjtimex(FD_TO_CLOCKID(fd), ...);
> 	}
> 
> that would be ideal.  But I will push back on anything like the
> following.
> 
> 	ioctl(fd, PTP_PEROUT_REQUEST2, ...);
> 	while (1) {
> 		clock_adjtimex(FD_TO_CLOCKID(fd), ...);
> 		ioctl(fd, PTP_EVENT_COUNT_TSTAMP, ...);
> 	}
> 
> But maybe I misunderstood?

Thank you for the feedback, but Thomas wants to see this as
an extension of GPIO. I'll work on an RFC patch for that instead.

> Thanks,
> Richard

Thanks,
Christopher