[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190819151429.GG15291@lunn.ch>
Date: Mon, 19 Aug 2019 17:14:29 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Hubert Feurstein <h.feurstein@...il.com>,
netdev <netdev@...r.kernel.org>,
lkml <linux-kernel@...r.kernel.org>,
Richard Cochran <richardcochran@...il.com>,
Florian Fainelli <f.fainelli@...il.com>,
Heiner Kallweit <hkallweit1@...il.com>,
"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH net-next 1/3] net: mdio: add support for passing a PTP
system timestamp to the mii_bus driver
> > > How expensive is ptp_read_system_prets()? My original suggestion was
> > > to unconditionally call it here, and then let the driver overwrite it
> > > if it supports finer grained time stamping. MDIO is slow, so as long
> > > as ptp_read_system_prets() is not too expensive, i prefer KISS.
> > >
> > > Andrew
> >
> > While that works for the pre_ts, it doesn't work for the post_ts (the
> > MDIO bus core will unconditionally overwrite the system timestamp from
> > the driver).
> > Unless you're suggesting to keep the pre_ts unconditional and the
> > post_ts under the "if" condition, which is a bit odd.
> > According to my tests with a scope (measuring the width between SPI
> > transfers with and without the ptp_read_system_*ts calls), two calls
> > to ktime_get_real_ts64 amount to around 750 ns on a 1200 MHz Cortex A7
> > core, or around 90 clock cycles.
>
> 900 clock cycles, my bad.
That is quite a lot. I was just expecting it to read a free running
clock and maybe do some unit conversions. 900 cycles suggests it is
doing a lot more.
So please keep with the idea of the bus driver indicating if it
supports the time stamping. But please make it a generic bus->flags,
and bit 0 indicating time stamping. At some point in the future, it
would be useful to indicate if the bus supports c45, which would be
another use of flags.
Thanks
Andrew
Powered by blists - more mailing lists