linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kent Gibson <warthog618@gmail.com>
To: Dipen Patel <dipenp@nvidia.com>
Cc: thierry.reding@gmail.com, jonathanh@nvidia.com,
	linux-kernel@vger.kernel.org, linux-tegra@vger.kernel.org,
	linux-gpio@vger.kernel.org, linus.walleij@linaro.org,
	brgl@bgdev.pl, devicetree@vger.kernel.org,
	linux-doc@vger.kernel.org, robh+dt@kernel.org
Subject: Re: [RFC v3 06/12] gpiolib: Add HTE support
Date: Fri, 26 Nov 2021 09:31:09 +0800	[thread overview]
Message-ID: <20211126013109.GB10380@sol> (raw)
In-Reply-To: <20211123193039.25154-7-dipenp@nvidia.com>

On Tue, Nov 23, 2021 at 11:30:33AM -0800, Dipen Patel wrote:
> Some GPIO chip can provide hardware timestamp support on its GPIO lines
> , in order to support that additional API needs to be added which
> can talk to both GPIO chip and HTE (hardware timestamping engine)
> subsystem. This patch introduces APIs which gpio consumer can use
> to request hardware assisted timestamping. Below is the list of the APIs
> that are added in gpiolib subsystem.
> 
> - gpiod_req_hw_timestamp_ns - Request HTE on specified GPIO line.
> - gpiod_rel_hw_timestamp_ns - Release HTE functionality on GPIO line.
> 
> Signed-off-by: Dipen Patel <dipenp@nvidia.com>
> Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> Reported-by: kernel test robot <lkp@intel.com>
> ---
> Changes in v2:
> - removed get timestamp and is timestamp enabled APIs
> 
>  drivers/gpio/gpiolib.c        | 73 +++++++++++++++++++++++++++++++++++
>  drivers/gpio/gpiolib.h        | 12 ++++++
>  include/linux/gpio/consumer.h | 19 ++++++++-
>  include/linux/gpio/driver.h   | 14 +++++++
>  4 files changed, 116 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index abfbf546d159..46cba75c80e8 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -1976,6 +1976,10 @@ static bool gpiod_free_commit(struct gpio_desc *desc)
>  			gc->free(gc, gpio_chip_hwgpio(desc));
>  			spin_lock_irqsave(&gpio_lock, flags);
>  		}
> +		spin_unlock_irqrestore(&gpio_lock, flags);
> +		gpiod_rel_hw_timestamp_ns(desc);
> +		spin_lock_irqsave(&gpio_lock, flags);
> +
>  		kfree_const(desc->label);
>  		desc_set_label(desc, NULL);
>  		clear_bit(FLAG_ACTIVE_LOW, &desc->flags);
> @@ -2388,6 +2392,75 @@ int gpiod_direction_output(struct gpio_desc *desc, int value)
>  }
>  EXPORT_SYMBOL_GPL(gpiod_direction_output);
>  
> +/**
> + * gpiod_req_hw_timestamp_ns - Enable the hardware assisted timestamp in
> + * nano second.
> + *

s/nano second/nanoseconds/g

> + * @desc: GPIO to enable
> + * @cb:	Callback, will be called when HTE pushes timestamp data.
> + * @tcb: Threaeded callback, it gets called from kernel thread context and when

s/Threaeded/Threaded/

> + * cb returns with HTE_RUN_THREADED_CB return value.
> + * @data: Client data, will be sent back with tcb and cb.
> + *
> + * Certain GPIO chip can rely on hardware assisted timestamp engines which can

Either drop the 'assisted' and refer to them as "hardware timestamping
engines" throughout, or rename your subsystem 'hate'?
Either way, be consistent.

> + * record timestamp at the occurance of the configured events
> + * i.e. rising/falling on specified GPIO lines. This is helper API to enable hw
> + * assisted timestamp in nano second.
> + *

Not sure this comment block adds anything.

> + * Return 0 in case of success, else an error code.
> + */
> +int gpiod_req_hw_timestamp_ns(struct gpio_desc *desc, hte_ts_cb_t cb,
> +			      hte_ts_threaded_cb_t tcb, void *data)
> +{
> +	struct gpio_chip *gc;
> +	int ret = 0;
> +
> +	VALIDATE_DESC(desc);
> +	gc = desc->gdev->chip;
> +
> +	if (!gc->req_hw_timestamp) {
> +		gpiod_warn(desc, "%s: hw ts not supported\n", __func__);
> +		return -ENOTSUPP;
> +	}
> +
> +	ret = gc->req_hw_timestamp(gc, gpio_chip_hwgpio(desc), cb, tcb,
> +				   &desc->hdesc, data);
> +	if (ret)
> +		gpiod_warn(desc, "%s: hw ts request failed\n", __func__);
> +
> +	return ret;
> +}
> +EXPORT_SYMBOL_GPL(gpiod_req_hw_timestamp_ns);
> +
> +/**
> + * gpiod_rel_hw_timestamp_ns - Release and disable the hardware assisted
> + * timestamp.
> + *

Are gpiod_req_hw_timestamp_ns() and gpiod_rel_hw_timestamp_ns()
request/release or enable/disable?
You are using both descriptions in the documentation.
request/release implies resource allocation, while enable/disable does
not.  Which is it?

> + * @desc: GPIO to disable
> + *
> + * Return 0 in case of success, else an error code.
> + */
> +int gpiod_rel_hw_timestamp_ns(struct gpio_desc *desc)

Cheers,
Kent.


  reply	other threads:[~2021-11-26  1:33 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-23 19:30 [RFC v3 00/12] Intro to Hardware timestamping engine Dipen Patel
2021-11-23 19:30 ` [RFC v3 01/12] Documentation: Add HTE subsystem guide Dipen Patel
2021-11-23 19:30 ` [RFC v3 02/12] drivers: Add hardware timestamp engine (HTE) Dipen Patel
2021-11-26  1:30   ` Kent Gibson
2021-12-08  0:36     ` Dipen Patel
2021-12-08  1:21       ` Kent Gibson
2021-12-08  1:59         ` Dipen Patel
2021-11-23 19:30 ` [RFC v3 03/12] hte: Add tegra194 HTE kernel provider Dipen Patel
2021-11-24  0:45   ` Randy Dunlap
2021-11-23 19:30 ` [RFC v3 04/12] dt-bindings: Add HTE bindings Dipen Patel
2021-11-24  2:59   ` Rob Herring
2021-11-23 19:30 ` [RFC v3 05/12] hte: Add Tegra194 IRQ HTE test driver Dipen Patel
2021-11-23 19:30 ` [RFC v3 06/12] gpiolib: Add HTE support Dipen Patel
2021-11-26  1:31   ` Kent Gibson [this message]
2021-11-23 19:30 ` [RFC v3 07/12] dt-bindings: gpio: Add hardware-timestamp-engine property Dipen Patel
2021-11-30 22:32   ` Rob Herring
2021-11-23 19:30 ` [RFC v3 08/12] gpio: tegra186: Add HTE in gpio-tegra186 driver Dipen Patel
2021-11-23 19:30 ` [RFC v3 09/12] gpiolib: cdev: Add hardware timestamp clock type Dipen Patel
2021-11-26  1:31   ` Kent Gibson
2021-12-01  3:29     ` Dipen Patel
2021-12-01 17:16       ` Kent Gibson
2021-12-01 18:01         ` Dipen Patel
2021-12-02  0:53           ` Kent Gibson
2021-12-03 23:24             ` Dipen Patel
2021-12-08  1:42             ` Dipen Patel
2021-12-08 20:14               ` Dipen Patel
2021-12-08 22:24                 ` Kent Gibson
2021-12-08 22:28               ` Kent Gibson
2022-01-05 23:00             ` Dipen Patel
2021-12-01 17:18       ` Dipen Patel
2021-11-23 19:30 ` [RFC v3 10/12] tools: gpio: Add new hardware " Dipen Patel
2021-11-23 19:30 ` [RFC v3 11/12] hte: Add tegra GPIO HTE test driver Dipen Patel
2021-11-23 19:30 ` [RFC v3 12/12] MAINTAINERS: Added HTE Subsystem Dipen Patel

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=20211126013109.GB10380@sol \
    --to=warthog618@gmail.com \
    --cc=brgl@bgdev.pl \
    --cc=devicetree@vger.kernel.org \
    --cc=dipenp@nvidia.com \
    --cc=jonathanh@nvidia.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --cc=thierry.reding@gmail.com \
    /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).