On Fri, Aug 27, 2010 at 20:58, Alexander Graf wrote:
> On 27.08.2010, at 21:06, Kyle Moffett wrote:
>> The kvmppc_e500_stlbe_invalidate() function was trying to pass too many
>> parameters to trace_kvm_stlb_inval(). This appears to be a bad
>> copy-paste from a call to trace_kvm_stlb_write().
>
>
On 27.08.2010, at 21:06, Kyle Moffett wrote:
> The kvmppc_e500_stlbe_invalidate() function was trying to pass too many
> parameters to trace_kvm_stlb_inval(). This appears to be a bad
> copy-paste from a call to trace_kvm_stlb_write().
Which kernel is this against? That trace point is already c
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 conceptually neutral? There are othe
Call kexec purgatory code correctly. We were getting lucky before.
If you examine the powerpc 32bit kexec "purgatory" code you will
see it expects the following:
>From kexec-tools: purgatory/arch/ppc/v2wrap_32.S
-> calling convention:
-> r3 = physical number of this cpu (all cpus)
-> r4 = addr
The first global-utilities node might not contain the rstcr
property, so we should search all the nodes
Signed-off-by: Matthew McClintock
---
arch/powerpc/sysdev/fsl_soc.c | 20 +++-
1 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b
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, 2010 at 02:28:04PM +0200, Arnd Bergmann
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 point was that a syscall is better t
The kvmppc_e500_stlbe_invalidate() function was trying to pass too many
parameters to trace_kvm_stlb_inval(). This appears to be a bad
copy-paste from a call to trace_kvm_stlb_write().
Signed-off-by: Kyle Moffett
---
arch/powerpc/kvm/e500_tlb.c |3 +--
1 files changed, 1 insertions(+), 2 de
On Fri, Aug 27, 2010 at 8:06 AM, Alan Cox wrote
> > > system time bimble track a source makes sense just as with NTP but
> making
> > > it a new clock seems the wrong model extending a non-too-bright API
> when
> > > you can just put the time sources in a file tree.
> >
> > Don't get your meaning
Hi!
I'd like to add my two cents about the discussion. Just to shortly
introduce myself: I'm working with PTP since version 2002 (now 2008 or
PTPv2) and I'm developing matching network cards, drivers, and also
sometimes a bit of the stack.
I always had the problem of different HW implementations
In message: <20100827140205.ga3...@riccoc20.at.omicron.at>
Richard Cochran writes:
: On Fri, Aug 27, 2010 at 01:41:54PM +0100, Alan Cox wrote:
: > > The master node in a PTP network probably takes its time from a
: > > precise external time source, like GPS. The GPS provides a 1 PPS
:
> Sorry for causing confusion, but please understand "a hardware clock
> with timestamping capabilities than can be used for PTP support"
> whenever I wrote "PTP" or "PTP clock."
Ok that makes sense.
>
> Well, what I just said is not entirely true.
> most are bound to the PTP protocol. That may c
On Fri, Aug 27, 2010 at 02:38:44PM +0100, Alan Cox wrote:
> > 2007. If we can justify adding a clock id in this case, surely we can
> > add one for PTP as well!
>
> But PTP isn't really a clock - its a time sync protocol. You can (and may
> need to) have multiple clocks of this form on the same ho
> To tell the truth, my original motivation for the patch set was to
> support PTP clocks and applications. I don't think that is such a bad
ptp *clocks*
> idea. After all, the adjtimex interface was added just to support NTP.
>
> At the same time, I can understand the desire to have a generic
>
On Fri, Aug 27, 2010 at 01:41:54PM +0100, Alan Cox wrote:
> > The master node in a PTP network probably takes its time from a
> > precise external time source, like GPS. The GPS provides a 1 PPS
> > directly to the PTP clock hardware, which latches the PTP hardware
> > clock time on the PPS edge. T
This patch removes all explicit tests for the TIF_32BIT flag
Signed-off-by: Denis Kirjanov
---
arch/powerpc/include/asm/compat.h|4 ++--
arch/powerpc/include/asm/elf.h |2 +-
arch/powerpc/include/asm/page_64.h |4 ++--
arch/powerpc/include/asm/processor.h |4 ++--
arc
> 2007. If we can justify adding a clock id in this case, surely we can
> add one for PTP as well!
But PTP isn't really a clock - its a time sync protocol. You can (and may
need to) have multiple clocks of this form on the same host because it's
master based and you may have to deal with multiple
> The master node in a PTP network probably takes its time from a
> precise external time source, like GPS. The GPS provides a 1 PPS
> directly to the PTP clock hardware, which latches the PTP hardware
> clock time on the PPS edge. This provides one sample as input to a
> clock servo (in the PTPd)
> > So if the clock_adjtime interface is needed, it would seem best for it
> > to be generic enough to support not only PTP, but also the NTP kernel
> > PLL.
>
> For the proposed clock_adjime, what else is needed to support clock
> adjustment in general?
Multiple PLLs, at least with containers an
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 conceptually neutral? There are other clock
> synchronization algorithms out there. Will they need their
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, 2010 at 02:28:04PM +0200, Arnd Bergmann wrote:
> > > > Have you considered passing a struct timex inste
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 point was that a syscall is better than an ioctl based interface here,
> > > which I definitely still
MPC8308 has ULPI pin muxing settings in SICRH register, bits 17-18
which is different from both MPC8313 and MPC8315.
Also MPC8308 doesn't have REFSEL, UTMI_PHY_EN and OTG_PORT fields
in the USB DR controller CONTROL register.
Signed-off-by: Ilya Yanok
---
arch/powerpc/boot/dts/mpc8308rdb.dts |
On Thu, Aug 26, 2010 at 06:57:49PM -0700, john stultz wrote:
> On Wed, 2010-08-25 at 11:40 +0200, Christian Riesch wrote:
> > 2) Master clock:
> > We have one or more network ports. Our system has a really good clock
> > (ovenized quartz crystal, an atomic clock, a GPS timing receiver...)
> > and i
24 matches
Mail list logo
