From: Vladimir Oltean <olteanv@gmail.com>
To: Christian Eggers <ceggers@arri.de>
Cc: Jakub Kicinski <kuba@kernel.org>, Andrew Lunn <andrew@lunn.ch>,
Richard Cochran <richardcochran@gmail.com>,
Rob Herring <robh+dt@kernel.org>,
Vivien Didelot <vivien.didelot@gmail.com>,
"David S . Miller" <davem@davemloft.net>,
Kurt Kanzenbach <kurt.kanzenbach@linutronix.de>,
George McCollister <george.mccollister@gmail.com>,
Marek Vasut <marex@denx.de>,
Helmut Grohne <helmut.grohne@intenta.de>,
Paul Barker <pbarker@konsulko.com>,
Codrin Ciubotariu <codrin.ciubotariu@microchip.com>,
Tristram Ha <Tristram.Ha@microchip.com>,
Woojung Huh <woojung.huh@microchip.com>,
Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>,
netdev@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v3 12/12] net: dsa: microchip: ksz9477: add periodic output support
Date: Sat, 21 Nov 2020 01:48:08 +0200 [thread overview]
Message-ID: <20201120234808.q4qvxpuj6akuev6h@skbuf> (raw)
In-Reply-To: <20201118203013.5077-13-ceggers@arri.de>
On Wed, Nov 18, 2020 at 09:30:13PM +0100, Christian Eggers wrote:
> The KSZ9563 has a Trigger Output Unit (TOU) which can be used to
> generate periodic signals.
>
> The pulse length can be altered via a device attribute.
>
> Tested on a Microchip KSZ9563 switch.
>
> Signed-off-by: Christian Eggers <ceggers@arri.de>
> ---
> drivers/net/dsa/microchip/ksz9477_ptp.c | 197 +++++++++++++++++++++++-
> drivers/net/dsa/microchip/ksz_common.h | 5 +
> 2 files changed, 201 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/dsa/microchip/ksz9477_ptp.c b/drivers/net/dsa/microchip/ksz9477_ptp.c
> index ce3fdc9a1f9e..3174574d52f6 100644
> --- a/drivers/net/dsa/microchip/ksz9477_ptp.c
> +++ b/drivers/net/dsa/microchip/ksz9477_ptp.c
> @@ -90,6 +90,20 @@ static int ksz9477_ptp_tou_cycle_count_set(struct ksz_device *dev, u16 count)
> return 0;
> }
>
> +static int ksz9477_ptp_tou_pulse_verify(u64 pulse_ns)
> +{
> + u32 data;
> +
> + if (pulse_ns & 0x3)
> + return -EINVAL;
> +
> + data = (pulse_ns / 8);
> + if (data != (data & TRIG_PULSE_WIDTH_M))
> + return -ERANGE;
> +
> + return 0;
> +}
> +
> static int ksz9477_ptp_tou_pulse_set(struct ksz_device *dev, u32 pulse_ns)
> {
> u32 data;
> @@ -196,6 +210,7 @@ static int ksz9477_ptp_adjfine(struct ptp_clock_info *ptp, long scaled_ppm)
> return ret;
> }
>
> +static int ksz9477_ptp_restart_perout(struct ksz_device *dev);
> static int ksz9477_ptp_enable_pps(struct ksz_device *dev, int on);
>
> static int ksz9477_ptp_adjtime(struct ptp_clock_info *ptp, s64 delta)
> @@ -241,6 +256,15 @@ static int ksz9477_ptp_adjtime(struct ptp_clock_info *ptp, s64 delta)
> case KSZ_PTP_TOU_IDLE:
> break;
>
> + case KSZ_PTP_TOU_PEROUT:
> + dev_info(dev->dev, "Restarting periodic output signal\n");
Isn't this a bit too verbose, or is there something for the user to be
concerned about?
> +
> + ret = ksz9477_ptp_restart_perout(dev);
> + if (ret)
> + goto error_return;
> +
> + break;
> +
> case KSZ_PTP_TOU_PPS:
> dev_info(dev->dev, "Restarting PPS\n");
>
> @@ -358,6 +382,15 @@ static int ksz9477_ptp_settime(struct ptp_clock_info *ptp,
> case KSZ_PTP_TOU_IDLE:
> break;
>
> + case KSZ_PTP_TOU_PEROUT:
> + dev_info(dev->dev, "Restarting periodic output signal\n");
> +
> + ret = ksz9477_ptp_restart_perout(dev);
> + if (ret)
> + goto error_return;
> +
> + break;
> +
> case KSZ_PTP_TOU_PPS:
> dev_info(dev->dev, "Restarting PPS\n");
>
> @@ -377,6 +410,159 @@ static int ksz9477_ptp_settime(struct ptp_clock_info *ptp,
> return ret;
> }
>
> +static int ksz9477_ptp_configure_perout(struct ksz_device *dev, u32 cycle_width_ns,
Watch out for 80 characters, please!
> + u16 cycle_count, u32 pulse_width_ns,
> + struct timespec64 const *target_time)
> +{
> + int ret;
> + u32 trig_ctrl;
Reverse Christmas tree.
> +
> + /* Enable notify, set rising edge, set periodic pattern */
> + trig_ctrl = TRIG_NOTIFY | (TRIG_POS_PERIOD << TRIG_PATTERN_S);
> + ret = ksz_write32(dev, REG_TRIG_CTRL__4, trig_ctrl);
> + if (ret)
> + return ret;
> +
> + ret = ksz9477_ptp_tou_cycle_width_set(dev, cycle_width_ns);
> + if (ret)
> + return ret;
> +
> + ksz9477_ptp_tou_cycle_count_set(dev, cycle_count);
> + if (ret)
> + return ret;
> +
> + ret = ksz9477_ptp_tou_pulse_set(dev, pulse_width_ns);
> + if (ret)
> + return ret;
> +
> + ret = ksz9477_ptp_tou_target_time_set(dev, target_time);
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
> +
> +static int ksz9477_ptp_enable_perout(struct ksz_device *dev,
> + struct ptp_perout_request const *perout_request, int on)
> +{
> + u32 gpio_stat0;
> + u64 cycle_width_ns;
> + int ret;
> +
> + if (dev->ptp_tou_mode != KSZ_PTP_TOU_PEROUT && dev->ptp_tou_mode != KSZ_PTP_TOU_IDLE)
> + return -EBUSY;
> +
> + ret = ksz9477_ptp_tou_reset(dev, 0);
> + if (ret)
> + return ret;
> +
> + if (!on) {
> + dev->ptp_tou_mode = KSZ_PTP_TOU_IDLE;
> + return 0; /* success */
> + }
> +
> + dev->ptp_perout_target_time_first.tv_sec = perout_request->start.sec;
> + dev->ptp_perout_target_time_first.tv_nsec = perout_request->start.nsec;
> +
> + dev->ptp_perout_period.tv_sec = perout_request->period.sec;
> + dev->ptp_perout_period.tv_nsec = perout_request->period.nsec;
> +
> + cycle_width_ns = timespec64_to_ns(&dev->ptp_perout_period);
> + if ((cycle_width_ns & GENMASK(31, 0)) != cycle_width_ns)
> + return -EINVAL;
> +
> + if (perout_request->flags & PTP_PEROUT_DUTY_CYCLE) {
> + u64 value = perout_request->on.sec * NSEC_PER_SEC +
> + perout_request->on.nsec;
> +
> + ret = ksz9477_ptp_tou_pulse_verify(value);
> + if (ret)
> + return ret;
> +
> + dev->ptp_perout_pulse_width_ns = value;
> + }
It is not guaranteed that user space will set this flag. Shouldn't you
assign a default value for the pulse width? I don't know, half the
period should be a good default.
Also, please reject PTP_PEROUT_ONE_SHOT and PTP_PEROUT_PHASE, since you
don't do anything with them, but user space might be led into believing
otherwise.
> +
> + ret = ksz9477_ptp_configure_perout(dev, cycle_width_ns,
> + dev->ptp_perout_cycle_count,
> + dev->ptp_perout_pulse_width_ns,
> + &dev->ptp_perout_target_time_first);
> + if (ret)
> + return ret;
> +
> + /* Activate trigger unit */
> + ret = ksz9477_ptp_tou_start(dev, NULL);
> + if (ret)
> + return ret;
> +
> + /* Check error flag:
> + * - the ACTIVE flag is NOT cleared an error!
> + */
> + ret = ksz_read32(dev, REG_PTP_TRIG_STATUS__4, &gpio_stat0);
> + if (ret)
> + return ret;
> +
> + if (gpio_stat0 & (1 << (0 + TRIG_ERROR_S))) {
What is the role of this "0 +" term here?
> + dev_err(dev->dev, "%s: Trigger unit0 error!\n", __func__);
> + ret = -EIO;
> + /* Unit will be reset on next access */
> + return ret;
> + }
> +
> + dev->ptp_tou_mode = KSZ_PTP_TOU_PEROUT;
> + return 0;
> +}
next prev parent reply other threads:[~2020-11-20 23:48 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-18 20:30 [PATCH net-next v3 00/12] net: dsa: microchip: PTP support for KSZ956x Christian Eggers
2020-11-18 20:30 ` [PATCH net-next v3 01/12] dt-bindings: net: dsa: convert ksz bindings document to yaml Christian Eggers
2020-11-19 13:42 ` Rob Herring
2020-11-19 13:48 ` Rob Herring
2020-11-19 20:22 ` Christian Eggers
2020-11-18 20:30 ` [PATCH net-next v3 02/12] net: dsa: microchip: support for "ethernet-ports" node Christian Eggers
2020-11-18 20:30 ` [PATCH net-next v3 03/12] net: dsa: microchip: rename ksz9477.c to ksz9477_main.c Christian Eggers
2020-11-18 20:30 ` [PATCH net-next v3 04/12] dt-bindings: net: dsa: microchip,ksz: add interrupt property Christian Eggers
2020-11-18 20:30 ` [PATCH net-next v3 05/12] net: dsa: microchip: ksz9477: move chip reset to ksz9477_switch_init() Christian Eggers
2020-11-20 22:49 ` Vladimir Oltean
2020-11-18 20:30 ` [PATCH net-next v3 06/12] net: dsa: microchip: ksz9477: basic interrupt support Christian Eggers
2020-11-20 23:03 ` Vladimir Oltean
2020-11-18 20:30 ` [PATCH net-next v3 07/12] net: dsa: microchip: ksz9477: add Posix clock support for chip PTP clock Christian Eggers
2020-11-20 23:14 ` Vladimir Oltean
2020-11-18 20:30 ` [PATCH net-next v3 08/12] net: ptp: add helper for one-step P2P clocks Christian Eggers
2020-11-18 20:30 ` [PATCH net-next v3 09/12] net: dsa: microchip: ksz9477: initial hardware time stamping support Christian Eggers
2020-11-20 23:27 ` Vladimir Oltean
2020-11-18 20:30 ` [PATCH net-next v3 10/12] net: dsa: microchip: ksz9477: remaining " Christian Eggers
2020-11-18 20:30 ` [PATCH net-next v3 11/12] net: dsa: microchip: ksz9477: add Pulse Per Second (PPS) support Christian Eggers
2020-11-18 20:30 ` [PATCH net-next v3 12/12] net: dsa: microchip: ksz9477: add periodic output support Christian Eggers
2020-11-20 23:48 ` Vladimir Oltean [this message]
2020-11-18 23:40 ` [PATCH net-next v3 00/12] net: dsa: microchip: PTP support for KSZ956x Vladimir Oltean
2020-11-19 5:28 ` Christian Eggers
2020-11-19 18:51 ` Tristram.Ha
2020-11-19 20:16 ` Christian Eggers
2020-11-21 1:26 ` Vladimir Oltean
2020-11-22 1:36 ` Richard Cochran
2020-11-22 1:53 ` Richard Cochran
2020-11-25 21:08 ` Christian Eggers
2020-11-26 16:53 ` Christian Eggers
2020-11-30 21:01 ` Tristram.Ha
2020-11-30 22:28 ` Richard Cochran
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=20201120234808.q4qvxpuj6akuev6h@skbuf \
--to=olteanv@gmail.com \
--cc=Tristram.Ha@microchip.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=andrew@lunn.ch \
--cc=ceggers@arri.de \
--cc=codrin.ciubotariu@microchip.com \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=george.mccollister@gmail.com \
--cc=helmut.grohne@intenta.de \
--cc=kuba@kernel.org \
--cc=kurt.kanzenbach@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=marex@denx.de \
--cc=netdev@vger.kernel.org \
--cc=pbarker@konsulko.com \
--cc=richardcochran@gmail.com \
--cc=robh+dt@kernel.org \
--cc=vivien.didelot@gmail.com \
--cc=woojung.huh@microchip.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).