Date: Wed, 13 May 2015 17:21:30 +0200
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
Message-ID: <20150513152130.GB2065@localhost.localdomain>
References: <1429744923-2007-1-git-send-email-jonathar@broadcom.com>
 <1429744923-2007-3-git-send-email-jonathar@broadcom.com>
 <6346218.3x3hbSlxMs@wuerfel>
 <5543CD73.2030902@broadcom.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5543CD73.2030902@broadcom.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2911
Lines: 61

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 linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/