All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: nikhil.gupta@nxp.com
Cc: linux-arm-kernel@lists.infradead.org,
	Yangbo Lu <yangbo.lu@nxp.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	vakul.garg@nxp.com, rajan.gupta@nxp.com
Subject: Re: [PATCH] ptp_qoriq: fix latency in ptp_qoriq_adjtime() operation.
Date: Wed, 11 Jan 2023 21:08:56 -0800	[thread overview]
Message-ID: <20230111210856.745ef17c@kernel.org> (raw)
In-Reply-To: <20230110113024.7558-1-nikhil.gupta@nxp.com>

please put [PATCH net-next] in the subject.

On Tue, 10 Jan 2023 17:00:24 +0530 nikhil.gupta@nxp.com wrote:
> From: Nikhil Gupta <nikhil.gupta@nxp.com>
> 
> 1588 driver loses about 1us in adjtime operation at PTP slave.
> This is because adjtime operation uses a slow non-atomic tmr_cnt_read()
> followed by tmr_cnt_write() operation.

So far so good..

> In the above sequence, since the timer counter operation loses about 1us.

s/operation/keeps incrementing after the read/ ?

but frankly I don't think this sentence adds much

> Instead, tmr_offset register should be programmed with the delta
> nanoseconds 

missing full stop at the end.
You should describe what the tmr_offset register does.

> This won't lead to timer counter stopping and losing time
> while tmr_cnt_write() is being done.

Stopping? The timer was actually stopping?

> This Patch adds api for tmr_offset_read/write to program the

Use imperative mood.

> delta nanoseconds in the Timer offset Register.
> 
> Signed-off-by: Nikhil Gupta <nikhil.gupta@nxp.com>
> Reviewed-by: Yangbo Lu <yangbo.lu@nxp.com>
> ---
>  drivers/ptp/ptp_qoriq.c | 36 ++++++++++++++++++++++++++++++------
>  1 file changed, 30 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/ptp/ptp_qoriq.c b/drivers/ptp/ptp_qoriq.c
> index 08f4cf0ad9e3..5b6ea6d590be 100644
> --- a/drivers/ptp/ptp_qoriq.c
> +++ b/drivers/ptp/ptp_qoriq.c
> @@ -48,6 +48,29 @@ static void tmr_cnt_write(struct ptp_qoriq *ptp_qoriq, u64 ns)
>  	ptp_qoriq->write(&regs->ctrl_regs->tmr_cnt_h, hi);
>  }
>  
> +static void tmr_offset_write(struct ptp_qoriq *ptp_qoriq, u64 delta_ns)
> +{
> +	struct ptp_qoriq_registers *regs = &ptp_qoriq->regs;
> +	u32 hi = delta_ns >> 32;
> +	u32 lo = delta_ns & 0xffffffff;
> +
> +	ptp_qoriq->write(&regs->ctrl_regs->tmroff_l, lo);
> +	ptp_qoriq->write(&regs->ctrl_regs->tmroff_h, hi);
> +}
> +
> +static u64 tmr_offset_read(struct ptp_qoriq *ptp_qoriq)
> +{
> +	struct ptp_qoriq_registers *regs = &ptp_qoriq->regs;
> +	u64 ns;
> +	u32 lo, hi;

Order variable lines longest to shortest 

> +	lo = ptp_qoriq->read(&regs->ctrl_regs->tmroff_l);
> +	hi = ptp_qoriq->read(&regs->ctrl_regs->tmroff_h);
> +	ns = ((u64) hi) << 32;
> +	ns |= lo;
> +	return ns;
> +}
> +
>  /* Caller must hold ptp_qoriq->lock. */
>  static void set_alarm(struct ptp_qoriq *ptp_qoriq)
>  {
> @@ -55,7 +78,9 @@ static void set_alarm(struct ptp_qoriq *ptp_qoriq)
>  	u64 ns;
>  	u32 lo, hi;
>  
> -	ns = tmr_cnt_read(ptp_qoriq) + 1500000000ULL;
> +	ns = tmr_cnt_read(ptp_qoriq) + tmr_offset_read(ptp_qoriq)
> +				     + 1500000000ULL;
> +
>  	ns = div_u64(ns, 1000000000UL) * 1000000000ULL;
>  	ns -= ptp_qoriq->tclk_period;
>  	hi = ns >> 32;
> @@ -207,15 +232,12 @@ EXPORT_SYMBOL_GPL(ptp_qoriq_adjfine);
>  
>  int ptp_qoriq_adjtime(struct ptp_clock_info *ptp, s64 delta)
>  {
> -	s64 now;
>  	unsigned long flags;
>  	struct ptp_qoriq *ptp_qoriq = container_of(ptp, struct ptp_qoriq, caps);
>  
>  	spin_lock_irqsave(&ptp_qoriq->lock, flags);
>  
> -	now = tmr_cnt_read(ptp_qoriq);
> -	now += delta;
> -	tmr_cnt_write(ptp_qoriq, now);
> +	tmr_offset_write(ptp_qoriq, delta);

Writes to the offset register result in an add operation? 
Or it's a pure write? What will the offset be after a sequence of
following adjtime() calls: 
  adjtime(+100); 
  adjtime(+100); 
  adjtime(+100);
?

>  	set_fipers(ptp_qoriq);
>  
>  	spin_unlock_irqrestore(&ptp_qoriq->lock, flags);
> @@ -232,7 +254,7 @@ int ptp_qoriq_gettime(struct ptp_clock_info *ptp, struct timespec64 *ts)
>  
>  	spin_lock_irqsave(&ptp_qoriq->lock, flags);
>  
> -	ns = tmr_cnt_read(ptp_qoriq);
> +	ns = tmr_cnt_read(ptp_qoriq) + tmr_offset_read(ptp_qoriq);
>  
>  	spin_unlock_irqrestore(&ptp_qoriq->lock, flags);
>  
> @@ -251,6 +273,8 @@ int ptp_qoriq_settime(struct ptp_clock_info *ptp,
>  
>  	ns = timespec64_to_ns(ts);
>  
> +	tmr_offset_write(ptp_qoriq, 0);

Shouldn't this be under the lock?

>  	spin_lock_irqsave(&ptp_qoriq->lock, flags);
>  
>  	tmr_cnt_write(ptp_qoriq, ns);


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Jakub Kicinski <kuba@kernel.org>
To: nikhil.gupta@nxp.com
Cc: linux-arm-kernel@lists.infradead.org,
	Yangbo Lu <yangbo.lu@nxp.com>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	vakul.garg@nxp.com, rajan.gupta@nxp.com
Subject: Re: [PATCH] ptp_qoriq: fix latency in ptp_qoriq_adjtime() operation.
Date: Wed, 11 Jan 2023 21:08:56 -0800	[thread overview]
Message-ID: <20230111210856.745ef17c@kernel.org> (raw)
In-Reply-To: <20230110113024.7558-1-nikhil.gupta@nxp.com>

please put [PATCH net-next] in the subject.

On Tue, 10 Jan 2023 17:00:24 +0530 nikhil.gupta@nxp.com wrote:
> From: Nikhil Gupta <nikhil.gupta@nxp.com>
> 
> 1588 driver loses about 1us in adjtime operation at PTP slave.
> This is because adjtime operation uses a slow non-atomic tmr_cnt_read()
> followed by tmr_cnt_write() operation.

So far so good..

> In the above sequence, since the timer counter operation loses about 1us.

s/operation/keeps incrementing after the read/ ?

but frankly I don't think this sentence adds much

> Instead, tmr_offset register should be programmed with the delta
> nanoseconds 

missing full stop at the end.
You should describe what the tmr_offset register does.

> This won't lead to timer counter stopping and losing time
> while tmr_cnt_write() is being done.

Stopping? The timer was actually stopping?

> This Patch adds api for tmr_offset_read/write to program the

Use imperative mood.

> delta nanoseconds in the Timer offset Register.
> 
> Signed-off-by: Nikhil Gupta <nikhil.gupta@nxp.com>
> Reviewed-by: Yangbo Lu <yangbo.lu@nxp.com>
> ---
>  drivers/ptp/ptp_qoriq.c | 36 ++++++++++++++++++++++++++++++------
>  1 file changed, 30 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/ptp/ptp_qoriq.c b/drivers/ptp/ptp_qoriq.c
> index 08f4cf0ad9e3..5b6ea6d590be 100644
> --- a/drivers/ptp/ptp_qoriq.c
> +++ b/drivers/ptp/ptp_qoriq.c
> @@ -48,6 +48,29 @@ static void tmr_cnt_write(struct ptp_qoriq *ptp_qoriq, u64 ns)
>  	ptp_qoriq->write(&regs->ctrl_regs->tmr_cnt_h, hi);
>  }
>  
> +static void tmr_offset_write(struct ptp_qoriq *ptp_qoriq, u64 delta_ns)
> +{
> +	struct ptp_qoriq_registers *regs = &ptp_qoriq->regs;
> +	u32 hi = delta_ns >> 32;
> +	u32 lo = delta_ns & 0xffffffff;
> +
> +	ptp_qoriq->write(&regs->ctrl_regs->tmroff_l, lo);
> +	ptp_qoriq->write(&regs->ctrl_regs->tmroff_h, hi);
> +}
> +
> +static u64 tmr_offset_read(struct ptp_qoriq *ptp_qoriq)
> +{
> +	struct ptp_qoriq_registers *regs = &ptp_qoriq->regs;
> +	u64 ns;
> +	u32 lo, hi;

Order variable lines longest to shortest 

> +	lo = ptp_qoriq->read(&regs->ctrl_regs->tmroff_l);
> +	hi = ptp_qoriq->read(&regs->ctrl_regs->tmroff_h);
> +	ns = ((u64) hi) << 32;
> +	ns |= lo;
> +	return ns;
> +}
> +
>  /* Caller must hold ptp_qoriq->lock. */
>  static void set_alarm(struct ptp_qoriq *ptp_qoriq)
>  {
> @@ -55,7 +78,9 @@ static void set_alarm(struct ptp_qoriq *ptp_qoriq)
>  	u64 ns;
>  	u32 lo, hi;
>  
> -	ns = tmr_cnt_read(ptp_qoriq) + 1500000000ULL;
> +	ns = tmr_cnt_read(ptp_qoriq) + tmr_offset_read(ptp_qoriq)
> +				     + 1500000000ULL;
> +
>  	ns = div_u64(ns, 1000000000UL) * 1000000000ULL;
>  	ns -= ptp_qoriq->tclk_period;
>  	hi = ns >> 32;
> @@ -207,15 +232,12 @@ EXPORT_SYMBOL_GPL(ptp_qoriq_adjfine);
>  
>  int ptp_qoriq_adjtime(struct ptp_clock_info *ptp, s64 delta)
>  {
> -	s64 now;
>  	unsigned long flags;
>  	struct ptp_qoriq *ptp_qoriq = container_of(ptp, struct ptp_qoriq, caps);
>  
>  	spin_lock_irqsave(&ptp_qoriq->lock, flags);
>  
> -	now = tmr_cnt_read(ptp_qoriq);
> -	now += delta;
> -	tmr_cnt_write(ptp_qoriq, now);
> +	tmr_offset_write(ptp_qoriq, delta);

Writes to the offset register result in an add operation? 
Or it's a pure write? What will the offset be after a sequence of
following adjtime() calls: 
  adjtime(+100); 
  adjtime(+100); 
  adjtime(+100);
?

>  	set_fipers(ptp_qoriq);
>  
>  	spin_unlock_irqrestore(&ptp_qoriq->lock, flags);
> @@ -232,7 +254,7 @@ int ptp_qoriq_gettime(struct ptp_clock_info *ptp, struct timespec64 *ts)
>  
>  	spin_lock_irqsave(&ptp_qoriq->lock, flags);
>  
> -	ns = tmr_cnt_read(ptp_qoriq);
> +	ns = tmr_cnt_read(ptp_qoriq) + tmr_offset_read(ptp_qoriq);
>  
>  	spin_unlock_irqrestore(&ptp_qoriq->lock, flags);
>  
> @@ -251,6 +273,8 @@ int ptp_qoriq_settime(struct ptp_clock_info *ptp,
>  
>  	ns = timespec64_to_ns(ts);
>  
> +	tmr_offset_write(ptp_qoriq, 0);

Shouldn't this be under the lock?

>  	spin_lock_irqsave(&ptp_qoriq->lock, flags);
>  
>  	tmr_cnt_write(ptp_qoriq, ns);


  parent reply	other threads:[~2023-01-12  5:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-10 11:30 [PATCH] ptp_qoriq: fix latency in ptp_qoriq_adjtime() operation nikhil.gupta
2023-01-10 11:30 ` nikhil.gupta
2023-01-10 11:53 ` Nikhil Gupta
2023-01-10 11:53   ` Nikhil Gupta
2023-01-12  5:08 ` Jakub Kicinski [this message]
2023-01-12  5:08   ` Jakub Kicinski
2023-01-16  9:28   ` [PATCH net-next] " Nikhil Gupta
2023-01-16  9:28     ` Nikhil Gupta

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=20230111210856.745ef17c@kernel.org \
    --to=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nikhil.gupta@nxp.com \
    --cc=rajan.gupta@nxp.com \
    --cc=vakul.garg@nxp.com \
    --cc=yangbo.lu@nxp.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.