On Sun, May 3, 2015 at 10:51 PM, Preeti U Murthy
wrote:
> Ping.
>
> Any comments on this patch ?
>
Got this queued for testing, and hopefully 4.2
thanks
-john
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo
On 12/14/2012 03:19 PM, Jason Gunthorpe wrote:
The purpose of this option is to allow ARM/etc systems that rely on the
class RTC subsystem to have the same kind of automatic NTP based
synchronization that we have on PC platforms. Today ARM does not
implement update_persistent_clock and makes exte
On 08/10/2014 09:19 PM, Benjamin Herrenschmidt wrote:
> On Wed, 2014-07-30 at 00:31 -0700, tip-bot for John Stultz wrote:
>> Commit-ID: 953dec21aed4038464fec02f96a2f1b8701a5bce
>> Gitweb:
>> http://git.kernel.org/tip/953dec21aed4038464fec02f96a2f1b8701a5bce
>&
On Thu, Sep 26, 2019 at 6:50 PM Shengjiu Wang wrote:
>
> When set the runtime hardware parameters, we may need to query
> the capability of DMA to complete the parameters.
>
> This patch is to Extract this operation from
> dmaengine_pcm_set_runtime_hwparams function to a separate function
> snd_dm
On Wed, Jan 8, 2020 at 8:58 PM John Stultz wrote:
> On Thu, Sep 26, 2019 at 6:50 PM Shengjiu Wang wrote:
> >
> > When set the runtime hardware parameters, we may need to query
> > the capability of DMA to complete the parameters.
> >
> > This patch
On Thu, Jan 16, 2020 at 11:11 PM Shengjiu Wang wrote:
>
> Hi
>
> On Thu, Jan 16, 2020 at 1:56 PM John Stultz wrote:
> >
> > On Wed, Jan 8, 2020 at 8:58 PM John Stultz wrote:
> > > On Thu, Sep 26, 2019 at 6:50 PM Shengjiu Wang
> > > wrote:
>
On Thu, 2011-11-03 at 11:59 +1100, Anton Blanchard wrote:
> plain text document attachment (clock3)
> Use clocksource_register_hz which calculates the shift/mult
> factors for us.
>
> Signed-off-by: Anton Blanchard
> ---
>
> Index: linux-build/arch/powerpc/kernel/time.c
> ===
On Sat, 2011-11-05 at 11:55 +1100, Paul Mackerras wrote:
> On Thu, Nov 03, 2011 at 09:14:44AM -0400, John Stultz wrote:
> > On Thu, 2011-11-03 at 11:59 +1100, Anton Blanchard wrote:
> > > plain text document attachment (clock3)
> > > Use clocksource_register_hz whic
On Thu, 2011-11-24 at 17:07 +1100, Anton Blanchard wrote:
> plain text document attachment (clock3)
> Use clocksource_register_hz which calculates the shift/mult
> factors for us. Also remove the shift = 22 assumption in
> vsyscall_update - thanks to Paul Mackerras and John Stultz fo
On 08/19/2012 02:02 PM, Andreas Schwab wrote:
John Stultz writes:
The timekeeper struct has a xtime_nsec, which keeps the
sub-nanosecond remainder. This ends up being somewhat
duplicative of the timekeeper.xtime.tv_nsec value, and we
have to do extra work to keep them apart, copying the full
On 08/20/2012 12:45 PM, Andreas Schwab wrote:
John Stultz writes:
I'm not very familiar w/ the iBook hardware, but does it use a
clocksource, or does it use arch_gettimeoffset()?
clocksource: timebase mult[3640e38e] shift[24] registered
I suspect that the casting has avoided clipping
On 08/20/2012 01:04 PM, Andreas Schwab wrote:
John Stultz writes:
Huh. Yea, that looks fine. And without the
__timekeeping_inject_sleeptime() call, the system resumed ok?
Yes, it does.
So I'm mostly still stumped on this. But I did find one possible related
bugfix that maybe you ca
On 08/21/2012 12:14 AM, Andreas Schwab wrote:
John Stultz writes:
@@ -115,6 +115,7 @@ static void tk_xtime_add(struct timekeeper *tk, const
struct timespec *ts)
{
tk->xtime_sec += ts->tv_sec;
tk->xtime_nsec += (u64)ts->tv_nsec << tk->shift;
+
On Fri, 2010-09-24 at 09:29 +0200, Richard Cochran wrote:
> On Thu, Sep 23, 2010 at 12:48:51PM -0700, john stultz wrote:
> > So I'd still split this patch up a little bit more.
> >
> > 1) Patch that implements the ADJ_SETOFFSET (*and its implementation*)
> > i
On Mon, 2011-02-28 at 08:57 +0100, Richard Cochran wrote:
> This patch adds an infrastructure for hardware clocks that implement
> IEEE 1588, the Precision Time Protocol (PTP). A class driver offers a
> registration method to particular hardware clock drivers. Each clock is
> presented as a standar
On Mon, 2011-02-28 at 08:57 +0100, Richard Cochran wrote:
> The eTSEC includes a PTP clock with quite a few features. This patch adds
> support for the basic clock adjustment functions, plus two external time
> stamps, one alarm, and the PPS callback.
Just a minor question on the locking, but othe
On Mon, 2011-02-28 at 08:58 +0100, Richard Cochran wrote:
> This patch adds a driver for the hardware time stamping unit found on the
> IXP465. The basic clock operations and an external trigger are implemented.
>
> Signed-off-by: Richard Cochran
> Acked-by: John Stultz
My ac
On Mon, 2011-02-28 at 08:58 +0100, Richard Cochran wrote:
> This patch adds support for the PTP clock found on the DP83640.
> The basic clock operations and one external time stamp have
> been implemented.
Just locking rule comment nits here.
> +static int tdr_write(int bc, struct phy_device *dev
esented as a standard POSIX clock.
>
> The ancillary clock features are exposed in two different ways, via
> the sysfs and by a character device.
>
> Signed-off-by: Richard Cochran
Acked-by: John Stultz
thanks
-john
___
Linuxppc-de
hran
Acked-by: John Stultz
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Sun, 2011-03-27 at 08:39 +0200, Richard Cochran wrote:
> This patch adds a driver for the hardware time stamping unit found on the
> IXP465. The basic clock operations and an external trigger are implemented.
>
> Signed-off-by: Richard Cochran
Acked-by:
On Sun, 2011-03-27 at 08:39 +0200, Richard Cochran wrote:
> This patch adds support for the PTP clock found on the DP83640.
> The basic clock operations and one external time stamp have
> been implemented.
>
> Signed-off-by: Richard Cochran
Acked-
On Wed, 2010-07-28 at 09:41 +1000, Paul Mackerras wrote:
> On Tue, Jul 13, 2010 at 05:56:21PM -0700, John Stultz wrote:
>
> > Currently powerpc's update_vsyscall calls an inline update_gtod.
> > However, both are straightforward, and there are no other users,
> > so
On Mon, Aug 16, 2010 at 4:17 AM, Richard Cochran
wrote:
> This patch adds an infrastructure for hardware clocks that implement
> IEEE 1588, the Precision Time Protocol (PTP). A class driver offers a
> registration method to particular hardware clock drivers. Each clock is
> exposed to user space a
On Mon, Aug 16, 2010 at 12:24 PM, john stultz wrote:
> On Mon, Aug 16, 2010 at 4:17 AM, Richard Cochran
> A few comments below
>
>> +** PTP user space API
>> +
>> + The class driver creates a character device for each registered PTP
>> + clock. User spa
On Tue, 2010-08-17 at 10:53 +0200, Richard Cochran wrote:
> On Mon, Aug 16, 2010 at 12:24:48PM -0700, john stultz wrote:
> > 3) I'm not sure I see the benefit of being able to have multiple
> > frequency corrected time domains. In other words, what benefit would
> > yo
On Tue, 2010-08-17 at 13:36 +0200, Arnd Bergmann wrote:
> On Tuesday 17 August 2010, Richard Cochran wrote:
> > On Tue, Aug 17, 2010 at 09:25:55AM +, Arnd Bergmann wrote:
> > > Another difference is that we generally use ioctl for devices that can
> > > be enumerated, while syscalls are for sys
On Wed, 2010-08-18 at 09:19 +0200, Richard Cochran wrote:
> On Tue, Aug 17, 2010 at 05:22:43PM -0700, john stultz wrote:
>>
> > So while to me, it think it would be more ideal (or maybe just less
> > different) to have a read-only interface (like the RTC), leaving PTPd
Sorry for the slow response here, I got busy with other work at the end
of last week.
On Thu, 2010-08-19 at 07:55 +0200, Richard Cochran wrote:
> On Wed, Aug 18, 2010 at 05:12:56PM -0700, john stultz wrote:
> > On Wed, 2010-08-18 at 09:19 +0200, Richard Cochran wrote:
> > > The
On Thu, 2010-08-19 at 17:38 +0200, Richard Cochran wrote:
> On Thu, Aug 19, 2010 at 02:28:04PM +0200, Arnd Bergmann wrote:
> > My point was that a syscall is better than an ioctl based interface here,
> > which I definitely still think. Given that John knows much more about
> > clocks than I do, we
On Wed, 2010-08-25 at 11:40 +0200, Christian Riesch wrote:
> What you describe here is only one of the use cases. If the hardware
> has a single network port and operates as a PTP slave, it timestamps
> the PTP packets that are sent and received and subsequently uses these
> timestamps and the info
On Fri, 2010-08-27 at 13:08 +0200, Richard Cochran wrote:
> On Mon, Aug 23, 2010 at 01:21:39PM -0700, john stultz wrote:
> > On Thu, 2010-08-19 at 17:38 +0200, Richard Cochran wrote:
> > > On Thu, Aug 19, 2010 at 02:28:04PM +0200, Arnd Bergmann wrote:
> > > > My poin
On Fri, 2010-08-27 at 14:03 +0200, Arnd Bergmann wrote:
> On Friday 27 August 2010, Richard Cochran wrote:
> > On Mon, Aug 23, 2010 at 01:21:39PM -0700, john stultz wrote:
> > > On Thu, 2010-08-19 at 17:38 +0200, Richard Cochran wrote:
> > > > On Thu, Aug 19,
On Fri, 2010-08-27 at 14:38 +0200, Richard Cochran wrote:
> On Mon, Aug 23, 2010 at 01:08:45PM -0700, john stultz wrote:
> > On Thu, 2010-08-19 at 07:55 +0200, Richard Cochran wrote:
> > > The clockid_t CLOCK_PTP will be arch-neutral.
> >
> > Sure, but are they c
On Thu, 2010-09-23 at 12:53 -0500, Christoph Lameter wrote:
> On Thu, 23 Sep 2010, Richard Cochran wrote:
> > In contrast to the standard Linux system clock, a PHC is
> > adjustable in hardware, for example using frequency compensation
> > registers or a VCO. The ability to directly tun
On Thu, 2010-09-23 at 19:30 +0200, Richard Cochran wrote:
> Here is the sixth version of my patch set adding PTP hardware clock
> support to the Linux kernel. The main difference to v5 is that the
> character device interface has been replaced with one based on the
> posix clock system calls.
>
>
On Thu, 2010-09-23 at 19:31 +0200, Richard Cochran wrote:
> A new syscall is introduced that allows tuning of a POSIX clock. The
> syscall is implemented for four architectures: arm, blackfin, powerpc,
> and x86.
>
> The new syscall, clock_adjtime, takes two parameters, the clock ID,
> and a point
On Thu, 2010-09-23 at 14:15 -0500, Christoph Lameter wrote:
> On Thu, 23 Sep 2010, john stultz wrote:
>
> > This was my initial gut reaction as well, but in the end, I agree with
> > Richard that in the case of one or multiple PTP hardware clocks, we
> > really can'
On Thu, 2010-09-23 at 21:36 +0100, Alan Cox wrote:
> >So as far as the POSIX standard is concerned, offering a clock id
> >to represent the PHC would be acceptable.
>
> But completely useless as you may have more than one entirely different
> time managed by PTP and in which you are not ma
On Thu, 2010-09-23 at 15:49 -0500, Christoph Lameter wrote:
> On Thu, 23 Sep 2010, john stultz wrote:
>
> > > The HPET or pit timesource are also quite slow these days. You only need
> > > access periodically to essentially tune the TSC ratio.
> >
> > If we&#x
On Thu, 2010-09-23 at 22:30 +0100, Alan Cox wrote:
> O> I don't see how this is a problem, as it exposes the multiple hardware
> > clocks via different posix clock ids. So in the boundary clock case, you
> > can configure which side is the client and which side is the master in a
> > config file an
On Fri, Mar 8, 2024 at 5:15 AM Adrian Hunter wrote:
>
> Consolidate vdso_calc_delta(), in preparation for further simplification.
>
> Suggested-by: Thomas Gleixner
> Signed-off-by: Adrian Hunter
> ---
> arch/powerpc/include/asm/vdso/gettimeofday.h | 17 ++---
> arch/s390/include/asm
_MAX instead which will work just as well and is in
> include/vdso/limits.h.
>
> Reported-by: Stephen Rothwell
> Closes: https://lore.kernel.org/all/20240409124905.6816d...@canb.auug.org.au/
> Fixes: c8e3a8b6f2e6 ("vdso: Consolidate vdso_calc_delta()")
> Signed-off-by: Adrian Hunter
Acked-by: John Stultz
On Thu, 2007-09-20 at 10:52 +1000, Paul Mackerras wrote:
> Daniel Walker writes:
>
> > If you switch to the rtc do the shift and mult need to change?
>
> You can't switch; any given CPU chip will have either the RTC or the
> timebase but not both.
I think what Daniel is pointing out is that the
for missing this earlier.
So no objections from me. I can't say I really worked the whole thing
out, but you're handling the xtime_nsec field properly and the rest
looks reasonable and is well documented.
So for what its worth:
Acked-by: John Stultz
Thanks again for making this update!
-john
45 matches
Mail list logo
