All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Cochran <richardcochran@gmail.com>
To: Jonathan Richardson <jonathar@broadcom.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
	Darren Edamura <dedamura@broadcom.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Scott Branden <sbranden@broadcom.com>,
	Pawel Moll <pawel.moll@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Ray Jui <rjui@broadcom.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	Rob Herring <robh+dt@kernel.org>,
	bcm-kernel-feedback-list@broadcom.com,
	Kumar Gala <galak@codeaurora.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/2] misc: Add initial Digital Timing Engine (DTE) driver for cygnus
Date: Wed, 13 May 2015 17:21:30 +0200	[thread overview]
Message-ID: <20150513152130.GB2065@localhost.localdomain> (raw)
In-Reply-To: <5543CD73.2030902@broadcom.com>

On Fri, May 01, 2015 at 12:01:07PM -0700, Jonathan Richardson wrote:
> The DTE creates timestamps of hardware based events such as GPIO, I2S
> signals for audio, etc. It was also intended to provide 802.1AS / PTP
> timestamps for network packets. The h/w has up to 32 "clients" -- the
> hardware inputs into a timestamping engine. These clients are specific
> to the chip the DTE is used on. For Cygnus you can see what they are in
> our 'enum dte_client' from bcm_cygnus_dte.h.

These 32 channels should either go to kernel consumers (i2s audio) or,
if there aren't any, to the generic PTP ioctl.

> The DTE timestamper creates timestamps based on the current clock wall
> time.

What do you mean by "wall time"?  CLOCK_REALTIME?

> When an event occurs it stores the timestamp in a h/w FIFO. Each
> client also has a divider that can be set to control the rate that
> timestamps are generated at by the timestamper and these are adjustable
> at run time.

This does not make sense.  If you time stamp events, then the rate is
determined by the events themselves.
 
> It's a bit more than a PTP hardware clock on a NIC. It's a clock for PTP
> plus timestamping 32 other hardware inputs that can be enabled at any
> time with timestamps being generated at varying frequencies. As clients
> are enabled that generate timestamps at higher frequencies, the
> isochronous interrupt frequency needs to be increased so that overflows
> in the the h/w and s/w FIFO's don't occur (this frequency could possibly
> be automated instead of changing it manually as we currently do).

Yes, the driver should configure an appropriate rate automatically.

> It looks like the driver could almost be a PTP driver instead of a char
> driver controlled with ioctls. PTP does this already using
> clock_gettime(), clock_settime(), clock_adjtime(). But we want to set
> the frequency as well as adjust the clock and I don't see how that is
> possible with the stripped down timex data passed to the driver from
> ptp_clock_adjtime().

You can convert ppb into your time base using simple math.
 
> We have the additional requirement of controlling multiple clients and
> retrieving the timestamps, etc. The PTP driver allows for some control
> of external time stamp channels already using 'n_ext_ts' in struct
> ptp_clock_info. We could use that to enable clients and get timestamps,
> but we also need to be able to change dividers for the clients at run
> time if desired. It doesn't look like additional ioctls could be passed
> to a PTP driver because ptp_ioctl() is the ioctl handler.

I don't see any need for use space to set dividers.  Let the driver do
that.

Thanks,
Richard

WARNING: multiple messages have this Message-ID (diff)
From: Richard Cochran <richardcochran-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Jonathan Richardson <jonathar-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
	Darren Edamura <dedamura-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>,
	Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
	Scott Branden <sbranden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>,
	Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
	Ian Campbell
	<ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
	Ray Jui <rjui-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>,
	Greg Kroah-Hartman
	<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w@public.gmane.org,
	Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH 2/2] misc: Add initial Digital Timing Engine (DTE) driver for cygnus
Date: Wed, 13 May 2015 17:21:30 +0200	[thread overview]
Message-ID: <20150513152130.GB2065@localhost.localdomain> (raw)
In-Reply-To: <5543CD73.2030902-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>

On Fri, May 01, 2015 at 12:01:07PM -0700, Jonathan Richardson wrote:
> The DTE creates timestamps of hardware based events such as GPIO, I2S
> signals for audio, etc. It was also intended to provide 802.1AS / PTP
> timestamps for network packets. The h/w has up to 32 "clients" -- the
> hardware inputs into a timestamping engine. These clients are specific
> to the chip the DTE is used on. For Cygnus you can see what they are in
> our 'enum dte_client' from bcm_cygnus_dte.h.

These 32 channels should either go to kernel consumers (i2s audio) or,
if there aren't any, to the generic PTP ioctl.

> The DTE timestamper creates timestamps based on the current clock wall
> time.

What do you mean by "wall time"?  CLOCK_REALTIME?

> When an event occurs it stores the timestamp in a h/w FIFO. Each
> client also has a divider that can be set to control the rate that
> timestamps are generated at by the timestamper and these are adjustable
> at run time.

This does not make sense.  If you time stamp events, then the rate is
determined by the events themselves.
 
> It's a bit more than a PTP hardware clock on a NIC. It's a clock for PTP
> plus timestamping 32 other hardware inputs that can be enabled at any
> time with timestamps being generated at varying frequencies. As clients
> are enabled that generate timestamps at higher frequencies, the
> isochronous interrupt frequency needs to be increased so that overflows
> in the the h/w and s/w FIFO's don't occur (this frequency could possibly
> be automated instead of changing it manually as we currently do).

Yes, the driver should configure an appropriate rate automatically.

> It looks like the driver could almost be a PTP driver instead of a char
> driver controlled with ioctls. PTP does this already using
> clock_gettime(), clock_settime(), clock_adjtime(). But we want to set
> the frequency as well as adjust the clock and I don't see how that is
> possible with the stripped down timex data passed to the driver from
> ptp_clock_adjtime().

You can convert ppb into your time base using simple math.
 
> We have the additional requirement of controlling multiple clients and
> retrieving the timestamps, etc. The PTP driver allows for some control
> of external time stamp channels already using 'n_ext_ts' in struct
> ptp_clock_info. We could use that to enable clients and get timestamps,
> but we also need to be able to change dividers for the clients at run
> time if desired. It doesn't look like additional ioctls could be passed
> to a PTP driver because ptp_ioctl() is the ioctl handler.

I don't see any need for use space to set dividers.  Let the driver do
that.

Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: richardcochran@gmail.com (Richard Cochran)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] misc: Add initial Digital Timing Engine (DTE) driver for cygnus
Date: Wed, 13 May 2015 17:21:30 +0200	[thread overview]
Message-ID: <20150513152130.GB2065@localhost.localdomain> (raw)
In-Reply-To: <5543CD73.2030902@broadcom.com>

On Fri, May 01, 2015 at 12:01:07PM -0700, Jonathan Richardson wrote:
> The DTE creates timestamps of hardware based events such as GPIO, I2S
> signals for audio, etc. It was also intended to provide 802.1AS / PTP
> timestamps for network packets. The h/w has up to 32 "clients" -- the
> hardware inputs into a timestamping engine. These clients are specific
> to the chip the DTE is used on. For Cygnus you can see what they are in
> our 'enum dte_client' from bcm_cygnus_dte.h.

These 32 channels should either go to kernel consumers (i2s audio) or,
if there aren't any, to the generic PTP ioctl.

> The DTE timestamper creates timestamps based on the current clock wall
> time.

What do you mean by "wall time"?  CLOCK_REALTIME?

> When an event occurs it stores the timestamp in a h/w FIFO. Each
> client also has a divider that can be set to control the rate that
> timestamps are generated at by the timestamper and these are adjustable
> at run time.

This does not make sense.  If you time stamp events, then the rate is
determined by the events themselves.
 
> It's a bit more than a PTP hardware clock on a NIC. It's a clock for PTP
> plus timestamping 32 other hardware inputs that can be enabled at any
> time with timestamps being generated at varying frequencies. As clients
> are enabled that generate timestamps at higher frequencies, the
> isochronous interrupt frequency needs to be increased so that overflows
> in the the h/w and s/w FIFO's don't occur (this frequency could possibly
> be automated instead of changing it manually as we currently do).

Yes, the driver should configure an appropriate rate automatically.

> It looks like the driver could almost be a PTP driver instead of a char
> driver controlled with ioctls. PTP does this already using
> clock_gettime(), clock_settime(), clock_adjtime(). But we want to set
> the frequency as well as adjust the clock and I don't see how that is
> possible with the stripped down timex data passed to the driver from
> ptp_clock_adjtime().

You can convert ppb into your time base using simple math.
 
> We have the additional requirement of controlling multiple clients and
> retrieving the timestamps, etc. The PTP driver allows for some control
> of external time stamp channels already using 'n_ext_ts' in struct
> ptp_clock_info. We could use that to enable clients and get timestamps,
> but we also need to be able to change dividers for the clients at run
> time if desired. It doesn't look like additional ioctls could be passed
> to a PTP driver because ptp_ioctl() is the ioctl handler.

I don't see any need for use space to set dividers.  Let the driver do
that.

Thanks,
Richard

  parent reply	other threads:[~2015-05-13 15:21 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-22 23:22 [PATCH 0/2] Add DTE driver for Cygnus Jonathan Richardson
2015-04-22 23:22 ` Jonathan Richardson
2015-04-22 23:22 ` Jonathan Richardson
2015-04-22 23:22 ` [PATCH 1/2] misc: Add DT binding for cygnus Digital Timing Engine (DTE) driver Jonathan Richardson
2015-04-22 23:22   ` Jonathan Richardson
2015-04-22 23:22   ` Jonathan Richardson
2015-04-22 23:22 ` [PATCH 2/2] misc: Add initial Digital Timing Engine (DTE) driver for cygnus Jonathan Richardson
2015-04-22 23:22   ` Jonathan Richardson
2015-04-22 23:22   ` Jonathan Richardson
2015-04-23  8:04   ` Arnd Bergmann
2015-04-23  8:04     ` Arnd Bergmann
2015-04-23  8:04     ` Arnd Bergmann
2015-04-23 18:07     ` Jonathan Richardson
2015-04-23 18:07       ` Jonathan Richardson
2015-04-23 18:07       ` Jonathan Richardson
2015-05-01 19:01     ` Jonathan Richardson
2015-05-01 19:01       ` Jonathan Richardson
2015-05-01 19:01       ` Jonathan Richardson
2015-05-01 19:30       ` One Thousand Gnomes
2015-05-01 19:30         ` One Thousand Gnomes
2015-05-01 19:30         ` One Thousand Gnomes
2015-05-01 19:40         ` Arnd Bergmann
2015-05-01 19:40           ` Arnd Bergmann
2015-05-08 20:02           ` Jonathan Richardson
2015-05-08 20:02             ` Jonathan Richardson
2015-05-08 20:02             ` Jonathan Richardson
2015-05-13  1:03             ` Jonathan Richardson
2015-05-13  1:03               ` Jonathan Richardson
2015-05-13  1:03               ` Jonathan Richardson
2015-05-13 12:19             ` Arnd Bergmann
2015-05-13 12:19               ` Arnd Bergmann
2015-05-13 14:37               ` Richard Cochran
2015-05-13 14:37                 ` Richard Cochran
2015-05-13 14:51                 ` Richard Cochran
2015-05-13 14:51                   ` Richard Cochran
2015-05-13 15:35             ` Richard Cochran
2015-05-13 15:35               ` Richard Cochran
2015-05-13 19:50               ` Jonathan Richardson
2015-05-13 19:50                 ` Jonathan Richardson
2015-05-13 19:50                 ` Jonathan Richardson
2015-05-13 20:27                 ` Richard Cochran
2015-05-13 20:27                   ` Richard Cochran
2015-05-13 23:25                   ` Jonathan Richardson
2015-05-13 23:25                     ` Jonathan Richardson
2015-05-13 23:25                     ` Jonathan Richardson
2015-05-14 11:30                     ` Richard Cochran
2015-05-14 11:30                       ` Richard Cochran
2015-05-14 11:30                       ` Richard Cochran
2015-05-20 23:38                       ` Jonathan Richardson
2015-05-20 23:38                         ` Jonathan Richardson
2015-05-20 23:38                         ` Jonathan Richardson
2015-05-21  6:33                         ` Richard Cochran
2015-05-21  6:33                           ` Richard Cochran
2015-05-21 17:48                           ` Jonathan Richardson
2015-05-21 17:48                             ` Jonathan Richardson
2015-05-21 17:48                             ` Jonathan Richardson
2015-05-13 15:21       ` Richard Cochran [this message]
2015-05-13 15:21         ` Richard Cochran
2015-05-13 15:21         ` Richard Cochran
2015-05-13 19:38         ` Jonathan Richardson
2015-05-13 19:38           ` Jonathan Richardson
2015-05-13 19:38           ` Jonathan Richardson
2015-05-13 19:42           ` Richard Cochran
2015-05-13 19:42             ` Richard Cochran
2015-05-13 19:39         ` Jonathan Richardson
2015-05-13 19:39           ` Jonathan Richardson
2015-05-13 19:39           ` Jonathan Richardson

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=20150513152130.GB2065@localhost.localdomain \
    --to=richardcochran@gmail.com \
    --cc=arnd@arndb.de \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=dedamura@broadcom.com \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=jonathar@broadcom.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=rjui@broadcom.com \
    --cc=robh+dt@kernel.org \
    --cc=sbranden@broadcom.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.