netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: <Arun.Ramadoss@microchip.com>
To: <pavan.chebbi@broadcom.com>
Cc: <andrew@lunn.ch>, <linux-kernel@vger.kernel.org>,
	<UNGLinuxDriver@microchip.com>, <vivien.didelot@gmail.com>,
	<olteanv@gmail.com>, <linux@armlinux.org.uk>, <ceggers@arri.de>,
	<Tristram.Ha@microchip.com>, <f.fainelli@gmail.com>,
	<kuba@kernel.org>, <edumazet@google.com>, <pabeni@redhat.com>,
	<richardcochran@gmail.com>, <netdev@vger.kernel.org>,
	<Woojung.Huh@microchip.com>, <davem@davemloft.net>
Subject: Re: [Patch net-next v1 04/12] net: dsa: microchip: ptp: Manipulating absolute time using ptp hw clock
Date: Wed, 30 Nov 2022 04:22:45 +0000	[thread overview]
Message-ID: <743a908be8dcb9a6492a2adeee5f2f9de3eff5a8.camel@microchip.com> (raw)
In-Reply-To: <CALs4sv0x04ODvWv-av56-FtnnpsC_8Sudp8T0U0buNRt+hq9bA@mail.gmail.com>

Hi Pavan,
Thanks for the review comment.

On Tue, 2022-11-29 at 14:13 +0530, Pavan Chebbi wrote:
> On Mon, Nov 28, 2022 at 4:04 PM Arun Ramadoss
> <arun.ramadoss@microchip.com> wrote:
> > +/*  Function is pointer to the do_aux_work in the ptp_clock
> > capability */
> > +static long ksz_ptp_do_aux_work(struct ptp_clock_info *ptp)
> > +{
> > +       struct ksz_ptp_data *ptp_data = ptp_caps_to_data(ptp);
> > +       struct ksz_device *dev = ptp_data_to_ksz_dev(ptp_data);
> > +       struct timespec64 ts;
> > +
> > +       mutex_lock(&ptp_data->lock);
> > +       _ksz_ptp_gettime(dev, &ts);
> > +       mutex_unlock(&ptp_data->lock);
> > +
> > +       spin_lock_bh(&ptp_data->clock_lock);
> > +       ptp_data->clock_time = ts;
> > +       spin_unlock_bh(&ptp_data->clock_lock);
> 
> If I understand this correctly, the software clock is updated with
> full 64b every 1s. However only 32b timestamp registers are read
> while
> processing packets and higher bits from this clock are used.
> How do you ensure these higher order bits are in sync with the higher
> order bits in the HW? IOW, what if lower 32b have wrapped around and
> you are required to stamp a packet but you still don't have aux
> worker
> updated.

The Ptp Hardware Clock (PHC) seconds register is 32 bit wide. To have
register overflow it takes 4,294,967,296 seconds which is approximately
around 136 Years. So, it is bigger value and assume that we don't need
to care of PHC second register overflow.
For the packet timestamping, value is read from 32 bit register. This
register is splited into 2 bits seconds + 30 bits nanoseconds register.
In the ksz_tstamp_reconstruct function, lower 2 bits in the ptp_data-
>clock_time is cleared and 2 bits from the timestamp register are
added. 

 spin_lock_bh(&ptp_data->clock_lock);
 ptp_clock_time = ptp_data->clock_time;
 spin_unlock_bh(&ptp_data->clock_lock);

/* calculate full time from partial time stamp */
 ts.tv_sec = (ptp_clock_time.tv_sec & ~3) | ts.tv_sec;

> 
> > +
> > +       return HZ;  /* reschedule in 1 second */
> > +}
> > +
> >  static int ksz_ptp_start_clock(struct ksz_device *dev)
> >  {
> > -       return ksz_rmw16(dev, REG_PTP_CLK_CTRL, PTP_CLK_ENABLE,
> > PTP_CLK_ENABLE);
> > +       struct ksz_ptp_data *ptp_data = &dev->ptp_data;
> > +       int ret;
> > +
> > +       ret = ksz_rmw16(dev, REG_PTP_CLK_CTRL, PTP_CLK_ENABLE,
> > PTP_CLK_ENABLE);
> > +       if (ret)
> > +               return ret;
> > +
> > +       spin_lock_bh(&ptp_data->clock_lock);
> > +       ptp_data->clock_time.tv_sec = 0;
> > +       ptp_data->clock_time.tv_nsec = 0;
> > +       spin_unlock_bh(&ptp_data->clock_lock);
> > +
> > +       return 0;
> >  }
> > 
> >  
> > --
> > 2.36.1
> > 

  reply	other threads:[~2022-11-30  4:22 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-28 10:32 [Patch net-next v1 00/12] net: dsa: microchip: add PTP support for KSZ9563/KSZ8563 and LAN937x Arun Ramadoss
2022-11-28 10:32 ` [Patch net-next v1 01/12] net: dsa: microchip: ptp: add the posix clock support Arun Ramadoss
2022-11-28 14:49   ` Pavan Chebbi
2022-11-28 14:56     ` Christian Eggers
2022-11-30 23:05       ` Vladimir Oltean
2022-11-30  4:53     ` Arun.Ramadoss
2022-12-01  0:17   ` Vladimir Oltean
2022-12-01 10:01     ` Arun.Ramadoss
2022-11-28 10:32 ` [Patch net-next v1 02/12] net: dsa: microchip: ptp: Initial hardware time stamping support Arun Ramadoss
2022-11-29  8:49   ` Pavan Chebbi
2022-11-30  4:32     ` Arun.Ramadoss
2022-12-01  0:39   ` Vladimir Oltean
2022-12-01 10:17     ` Arun.Ramadoss
2022-11-28 10:32 ` [Patch net-next v1 03/12] net: dsa: microchip: ptp: add 4 bytes in tail tag when ptp enabled Arun Ramadoss
2022-12-01  0:52   ` Vladimir Oltean
2022-12-01 10:56     ` Arun.Ramadoss
2022-11-28 10:32 ` [Patch net-next v1 04/12] net: dsa: microchip: ptp: Manipulating absolute time using ptp hw clock Arun Ramadoss
2022-11-29  8:43   ` Pavan Chebbi
2022-11-30  4:22     ` Arun.Ramadoss [this message]
2022-11-30  6:11       ` Pavan Chebbi
2022-12-01  1:04   ` Vladimir Oltean
2022-12-02  9:40     ` Arun.Ramadoss
2022-11-28 10:32 ` [Patch net-next v1 05/12] net: dsa: microchip: ptp: enable interrupt for timestamping Arun Ramadoss
2022-11-28 10:32 ` [Patch net-next v1 06/12] net: ptp: add helper for one-step P2P clocks Arun Ramadoss
2022-11-28 10:32 ` [Patch net-next v1 07/12] net: dsa: microchip: ptp: add packet reception timestamping Arun Ramadoss
2022-11-29  0:43   ` kernel test robot
2022-11-28 10:32 ` [Patch net-next v1 08/12] net: dsa: microchip: ptp: add packet transmission timestamping Arun Ramadoss
2022-11-28 10:32 ` [Patch net-next v1 09/12] net: dsa: microchip: ptp: move pdelay_rsp correction field to tail tag Arun Ramadoss
2022-11-28 10:32 ` [Patch net-next v1 10/12] net: dsa: microchip: ptp: add 2 step timestamping for LAN937x Arun Ramadoss
2022-11-28 10:32 ` [Patch net-next v1 11/12] net: dsa: microchip: ptp: add periodic output signal Arun Ramadoss
2022-11-29  8:53   ` Pavan Chebbi
2022-11-29  9:57     ` Pavan Chebbi
2022-11-30  4:48       ` Arun.Ramadoss
2022-11-30  4:41     ` Arun.Ramadoss
2022-11-28 10:32 ` [Patch net-next v1 12/12] net: dsa: microchip: ptp: add support for perout programmable pins Arun Ramadoss

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=743a908be8dcb9a6492a2adeee5f2f9de3eff5a8.camel@microchip.com \
    --to=arun.ramadoss@microchip.com \
    --cc=Tristram.Ha@microchip.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=Woojung.Huh@microchip.com \
    --cc=andrew@lunn.ch \
    --cc=ceggers@arri.de \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=pavan.chebbi@broadcom.com \
    --cc=richardcochran@gmail.com \
    --cc=vivien.didelot@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).