linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Christopher S. Hall" <christopher.s.hall@intel.com>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	netdev <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
	<x86@kernel.org>,
	jacob.e.keller@intel.com,
	Richard Cochran <richardcochran@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	sean.v.kelley@intel.com
Subject: Re: [Intel PMC TGPIO Driver 5/5] drivers/ptp: Add PMC Time-Aware GPIO Driver
Date: Mon, 24 Feb 2020 15:17:42 -0800	[thread overview]
Message-ID: <20200224231742.GD1508@skl-build> (raw)
In-Reply-To: <CACRpkdbi7q5Vr2Lt12eirs3Z8GLL2AuLLrAARCHkYEYgKbYkHg@mail.gmail.com>

Hi Linus,

Thanks for the review.

On Fri, Feb 07, 2020 at 06:10:46PM +0100, Linus Walleij wrote:
> Hi Christopher,
> 
> thanks for your patch!
> 
> On Fri, Jan 31, 2020 at 7:41 AM <christopher.s.hall@intel.com> wrote:
> 
> > From: Christopher Hall <christopher.s.hall@intel.com>
> >

> > The driver implements to the expanded PHC interface. Input requires use of
> > the user-polling interface. Also, since the ART clock can't be adjusted,
> > modulating the output frequency uses the edge timestamp interface
> > (EVENT_COUNT_TSTAMP2) and the PEROUT2 ioctl output frequency adjustment
> > interface.
> >
> > Acknowledgment: Portions of the driver code were authored by Felipe
> > Balbi <balbi@kernel.org>
> >
> > Signed-off-by: Christopher Hall <christopher.s.hall@intel.com>

> This driver becomes a big confusion for the GPIO maintainer...

I see your concern. TGPIO is Intel's internal name for the device, but
there's no reason we can't use some other terminology in the context of
the Linux kernel. How about removing the GP? We could refer to the device
as "timed I/O". I think that is still fairly descriptive, but removes the
confusion. Does this help the problem?

> > +config PTP_INTEL_PMC_TGPIO
> > +       tristate "Intel PMC Timed GPIO"
> > +       depends on X86
> > +       depends on ACPI
> > +       depends on PTP_1588_CLOCK
> (...)
> > +#include <linux/gpio.h>
> 
> Don't use this header in new code, use <linux/gpio/driver.h>
> 
> But it looks like you should just drop it because there is no GPIO
> of that generic type going on at all?

Yes. You're correct. Removed.

> > +/* Control Register */
> > +#define TGPIOCTL_EN                    BIT(0)
> > +#define TGPIOCTL_DIR                   BIT(1)
> > +#define TGPIOCTL_EP                    GENMASK(3, 2)
> > +#define TGPIOCTL_EP_RISING_EDGE                (0 << 2)
> > +#define TGPIOCTL_EP_FALLING_EDGE       (1 << 2)
> > +#define TGPIOCTL_EP_TOGGLE_EDGE                (2 << 2)
> > +#define TGPIOCTL_PM                    BIT(4)
> 
> OK this looks like some GPIO registers...
> 
> Then there is a bunch of PTP stuff I don't understand I suppose
> related to the precision time protocol.
> 
> Could you explain to a simple soul like me what is going on?
> Should I bother myself with this or is this "some other GPIO,
> not what you work on" or could it be that it's something I should
> review?

The Timed GPIO device has some GPIO-like features, but is mostly used to
import/export a clock signal. It doesn't implement PWM or some other "GP"
features like reading/setting pin state. I think you can safely ignore
the feature.

> I get the impression that this so-called "general purpose I/O"
> isn't very general purpose at all, it seems to be very PTP-purpose

Yes. It is missing many of general purpose features.

> rather, so this confusion needs to be explained in the commit
> message and possibly in the code as well.
> 
> What is it for really?

For import/export system clock, primarily.

> Yours,
> Linus Walleij

Thanks,
Christopher

  parent reply	other threads:[~2020-02-24 23:17 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-11 21:48 [Intel PMC TGPIO Driver 0/5] Add support for Intel PMC Time GPIO Driver with PHC interface changes to support additional H/W Features christopher.s.hall
2019-12-11 21:48 ` [Intel PMC TGPIO Driver 1/5] drivers/ptp: Add Enhanced handling of reserve fields christopher.s.hall
2020-01-31 16:54   ` Jacob Keller
2020-02-03  1:45     ` Richard Cochran
2020-02-24 23:29       ` Christopher S. Hall
2020-01-31 17:02   ` Jacob Keller
2020-02-03  1:27   ` Richard Cochran
2020-02-24 23:23     ` Christopher S. Hall
2019-12-11 21:48 ` [Intel PMC TGPIO Driver 2/5] drivers/ptp: Add PEROUT2 ioctl frequency adjustment interface christopher.s.hall
2020-02-03  2:14   ` Richard Cochran
2020-02-26  0:20     ` Christopher S. Hall
2019-12-11 21:48 ` [Intel PMC TGPIO Driver 3/5] drivers/ptp: Add user-space input polling interface christopher.s.hall
2020-02-03  2:28   ` Richard Cochran
2019-12-11 21:48 ` [Intel PMC TGPIO Driver 4/5] x86/tsc: Add TSC support functions to support ART driven Time-Aware GPIO christopher.s.hall
2019-12-11 21:48 ` [Intel PMC TGPIO Driver 5/5] drivers/ptp: Add PMC Time-Aware GPIO Driver christopher.s.hall
2020-02-03  2:31   ` Richard Cochran
2020-02-07 17:10   ` Linus Walleij
2020-02-07 17:28     ` Andrew Lunn
2020-02-07 19:49       ` Andy Shevchenko
2020-02-07 19:52         ` Andy Shevchenko
2020-02-24 23:17     ` Christopher S. Hall [this message]
2020-01-31 15:08 ` [Intel PMC TGPIO Driver 0/5] Add support for Intel PMC Time GPIO Driver with PHC interface changes to support additional H/W Features Jakub Kicinski
2020-01-31 18:14 ` Thomas Gleixner
2020-02-24 22:40   ` Christopher S. Hall
2020-02-26 23:06     ` Thomas Gleixner
2020-03-03  1:56       ` Christopher S. Hall
2020-03-03 13:00       ` Linus Walleij
2020-03-03 15:23         ` Richard Cochran
2020-03-03 15:24         ` Thomas Gleixner
2020-03-08 19:14           ` Jonathan Cameron
2020-02-03  4:08 ` Richard Cochran
2020-02-03 18:27   ` Jacob Keller
2020-02-25 23:37   ` Christopher S. Hall
2020-02-26  2:47     ` Richard Cochran
2020-03-03  2:01       ` Christopher S. Hall
2020-02-07 17:17 ` Linus Walleij

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200224231742.GD1508@skl-build \
    --to=christopher.s.hall@intel.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=hpa@zytor.com \
    --cc=jacob.e.keller@intel.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=mingo@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=richardcochran@gmail.com \
    --cc=sean.v.kelley@intel.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).