Can you paste the whole log from the u-boot prompt?
In the previous run the ramdisk image was corrupted because the single
image was loaded at 0x80. But the boot message showed that the
initrd image was at 0x0066c000-0x009ae825. So it was over the 8MB
area.
However after the load
Replace EXTRA_CFLAGS with ccflags-y and EXTRA_AFLAGS with asflags-y.
Signed-off-by: matt mooney m...@muteddisk.com
---
arch/powerpc/kernel/vdso32/Makefile |6 +++---
arch/powerpc/kernel/vdso64/Makefile |6 +++---
arch/powerpc/kvm/Makefile |2 +-
posting patches beats waiting for an indefinite amount of time :)
Kim
Well, yes I suppose so.. Only I have noticed that only 1-2 people post
these kind of patches, so I thought maybe there were some kind of
unwritten agreement that no one else were to tamper with their work.
I will dig into
On Wed, 2010-09-22 at 16:04 +1000, Michael Neuling wrote:
When irqblance attempts writes to the IPI smp_affinity (ie.
/proc/irq/16/smp_affinity in the above example) it fails but irqbalance
ignores currently ignores this.
This patch catches these write fails and in this case adds that IRQ
Hi Matt,
On Wed, 22 Sep 2010 23:51:09 -0700 matt mooney m...@muteddisk.com wrote:
Replace EXTRA_CFLAGS with ccflags-y and EXTRA_AFLAGS with asflags-y.
This looks good. One comment below ...
--- a/arch/powerpc/platforms/pseries/Makefile
+++ b/arch/powerpc/platforms/pseries/Makefile
@@
+ if (fwrite(line, strlen(line) - 1, 1, file) == 0)
if (fputs(line, file) == EOF)
Good point thanks... new patch below
Mikey
irqbalance, powerpc: add IRQs without settable SMP affinity to banned list
On pseries powerpc, IPIs are registered with an IRQ number so
/proc/interrupts
On Thu, 2010-09-23 at 05:21 +0200, Chen, Tiejun wrote:
I can get the device to show up on the host's PCI bus, I can
This only ensure you can access the PCIe configure space.
Not quite: I can also read the BARs that I program, and the memory
behind them on the PPC.
program the inbound
Running modules_install from a newly built 2.6.36-rc5 kernel
on my 32-bit PowerMac results in:
WARNING: Module
/lib/modules/2.6.36-rc5/kernel/drivers/i2c/busses/i2c-powermac.ko ignored, due
to loop
WARNING: Loop detected: /lib/modules/2.6.36-rc5/kernel/drivers/i2c/i2c-core.ko
needs of_i2c.ko
-Original Message-
From: Shawn Jin [mailto:shawnx...@gmail.com]
Sent: Thursday, September 23, 2010 4:23 AM
To: Chen, Tiejun
Cc: Scott Wood; ppcdev; uboot
Subject: Re: [U-Boot] cuImage and multi image?
I have a large ramdisk image. The size of the image itself
(i.e. the
*.gz)
On Thu, Sep 23, 2010 at 08:57:20PM +1000, Michael Neuling wrote:
+ if (fwrite(line, strlen(line) - 1, 1, file) == 0)
if (fputs(line, file) == EOF)
Good point thanks... new patch below
Mikey
irqbalance, powerpc: add IRQs without settable SMP affinity to banned list
On
-Original Message-
From: David Hagood [mailto:david.hag...@gmail.com]
Sent: Thursday, September 23, 2010 7:11 PM
To: Chen, Tiejun; linuxppc-...@ozlabs.org
Subject: RE: MPC8641D PEX: programming OWBAR in Endpoint mode?
On Thu, 2010-09-23 at 05:21 +0200, Chen, Tiejun wrote:
I can
-Original Message-
via the BARs.
I read your email again and something hint me. I notice you clarify you
already condigure InBound successfully.
I am programming BOTH the inbound ATMUs to make PPC memory available to
the root complex, AND programming outbound ATMUs to enable the PPC
I've implemented a working driver on my 460EX. it allocates a couple
of buffers of 4MB each. I have a custom memcmp algorithm in asm that
is extremely fast in user space, but 1/2 as fast when run on these
buffers.
my tests are showing that the algorithm seems to be memory bandwidth
bound. my
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.
The first three patches add necessary background support in the posix
This patch augments the POSIX clock code to offer a dynamic clock
creation method. Instead of registering a hard coded clock ID, modules
may call create_posix_clock(), which returns a new clock ID.
Signed-off-by: Richard Cochran richard.coch...@omicron.at
---
include/linux/posix-timers.h |7
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 pointer to a struct timex. The semantics of the timex struct
have been
This patch adds a 'timesource' class into sysfs. Each registered POSIX
clock appears by name under /sys/class/timesource. The idea is to
expose to user space the dynamic mapping between clock devices and
clock IDs.
Signed-off-by: Richard Cochran richard.coch...@omicron.at
---
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 standard POSIX clock.
The ancillary clock features are exposed in two
This patch adds a driver that simulates a PTP hardware clock. The
driver serves as a simple example for writing real clock driver and
can be used for testing the PTP clock API.
The basic clock operations are implemented using the system clock,
and the ancillary clock operations are simulated.
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.
Signed-off-by: Richard Cochran richard.coch...@omicron.at
---
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 richard.coch...@omicron.at
---
arch/arm/mach-ixp4xx/include/mach/ixp46x_ts.h | 78 ++
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 richard.coch...@omicron.at
---
drivers/net/phy/Kconfig | 29 ++
drivers/net/phy/Makefile |1 +
On Thu, 23 Sep 2010, Richard Cochran wrote:
Support for obtaining timestamps from a PHC already exists via the
SO_TIMESTAMPING socket option, integrated in kernel version 2.6.30.
This patch set completes the picture by allow user space programs to
adjust the PHC and to control its
On 20:19 Thu 23 Sep , Stephen Rothwell wrote:
Hi Matt,
On Wed, 22 Sep 2010 23:51:09 -0700 matt mooney m...@muteddisk.com wrote:
Replace EXTRA_CFLAGS with ccflags-y and EXTRA_AFLAGS with asflags-y.
This looks good. One comment below ...
---
On Thu, 23 Sep 2010, Jacob Keller wrote:
There is a reason for not being able to shift posix clocks: The system has
one time base. The various clocks are contributing to maintaining that
sytem wide time.
Adjusting clocks is absolutely essential for proper functioning of the PTP
On Thu, 23 Sep 2010 13:53:18 +0200 Mikael Pettersson wrote:
Running modules_install from a newly built 2.6.36-rc5 kernel
on my 32-bit PowerMac results in:
WARNING: Module
/lib/modules/2.6.36-rc5/kernel/drivers/i2c/busses/i2c-powermac.ko ignored,
due to loop
WARNING: Loop detected:
* Nathan Fontenot nf...@austin.ibm.com [2010-09-22 09:15:43]:
This set of patches decouples the concept that a single memory
section corresponds to a single directory in
/sys/devices/system/memory/. On systems
with large amounts of memory (1+ TB) there are performance issues
related to
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 tune the
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.
The
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't abstract over the different time domains.
My (arguably still superficial) review of the source does
On Thu, 23 Sep 2010, Richard Cochran wrote:
+* Gianfar PTP clock nodes
+
+General Properties:
+
+ - compatible Should be fsl,etsec-ptp
+ - reg Offset and length of the register set for the device
+ - interrupts There should be at least two interrupts. Some devices
+
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 pointer to
From: Tiejun Chen tiejun.c...@windriver.com
There exists a four line chunk of code, which when configured for
64 bit address space, can incorrectly set certain page flags during
the TLB creation. It turns out that this is legacy code that is no
longer required, but since it isn't obvious why
Randy Dunlap writes:
On Thu, 23 Sep 2010 13:53:18 +0200 Mikael Pettersson wrote:
Running modules_install from a newly built 2.6.36-rc5 kernel
on my 32-bit PowerMac results in:
WARNING: Module
/lib/modules/2.6.36-rc5/kernel/drivers/i2c/busses/i2c-powermac.ko ignored,
due
Please do not introduce useless additional layers for clock sync. Load
these ptp clocks like the other regular clock modules and make them sync
system time like any other clock.
I don't think you understand PTP. PTP has masters, a system can need to
be honouring multiple conflicting masters at
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't abstract over the different time
On Fri, Sep 17, 2010 at 6:42 PM, tma...@apm.com wrote:
From: Tirumala Marri tma...@apm.com
This patch combines drivers/dma/ppc4xx/xor.h and driver/dma/dma/ppc4xx/dma.h
into drivers/dma/ppc4xx/ppx440spe-dma.h .
Is this just code churn, or do we gain anything by combining these
header files?
On 9/17/2010 6:42 PM, tma...@apm.com wrote:
From: Tirumala Marritma...@apm.com
This patch generalizes the existing drver/dma/ppc4xx/adma.c, so that
common code can be shared between different similar DMA engine
drivers in other SoCs.
Signed-off-by: Tirumala R Marritma...@apm.com
---
On Thu, 23 Sep 2010, Alan Cox wrote:
Please do not introduce useless additional layers for clock sync. Load
these ptp clocks like the other regular clock modules and make them sync
system time like any other clock.
I don't think you understand PTP. PTP has masters, a system can need to
On Thu, 23 Sep 2010 16:10:15 -0400
Paul Gortmaker paul.gortma...@windriver.com wrote:
So the possibility exists to wrongly assign the user MAS3_URWX bits
to kernel (PAGE_KERNEL_X) address space via the following code fragment:
if (flags _PAGE_USER) {
TLBCAM[index].MAS3
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 master
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're using the TSC, then we're not using the PTP clock as you
suggest. Further the HPET and PIT aren't used to steer
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 tune the PHC is
essential to reap the benefit of hardware timestamping.
There is a reason for not being
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 and the PTPd will appropriately steer them individually.
They
There is no other scalable time source available for fast timer access
than the time stamp counter in the cpu. Other time source require
memory accesses which is inherently slower.
On what hardware ?
An accurate other time source is used to adjust this clock. NTP does that
via the clock
Alan Cox wrote:
Please do not introduce useless additional layers for clock sync. Load
these ptp clocks like the other regular clock modules and make them sync
system time like any other clock.
I don't think you understand PTP. PTP has masters, a system can need to
be honouring multiple
Alan Cox wrote:
It implies clock tuning in userspace for a potential sub microsecond
accurate clock. The clock accuracy will be limited by user space
latencies and noise. You wont be able to discipline the system clock
accurately.
Noise matters, latency doesn't.
Well put! That's why we need
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're using the TSC, then we're not using the PTP
On Thu, 2010-09-23 at 15:33 -0500, Scott Wood wrote:
I don't see a generic accessor that can test PTE flags for user
access -- in the absence of one, I guess we need an ifdef here. Or at
least put in a comment so anyone who adds a userspace use knows they
need to fix it.
We could make up
On Thu, 2010-09-23 at 10:12 -0500, Ayman El-Khashab wrote:
I've implemented a working driver on my 460EX. it allocates a couple
of buffers of 4MB each. I have a custom memcmp algorithm in asm that
is extremely fast in user space, but 1/2 as fast when run on these
buffers.
my tests are
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 and the
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 pointer to
On Thu, 23 Sep 2010 22:16:32 +0200 Mikael Pettersson wrote:
Randy Dunlap writes:
On Thu, 23 Sep 2010 13:53:18 +0200 Mikael Pettersson wrote:
Running modules_install from a newly built 2.6.36-rc5 kernel
on my 32-bit PowerMac results in:
WARNING: Module
On Tue, Sep 21, 2010 at 10:41 PM, Kumar Gala ga...@kernel.crashing.org wrote:
On Sep 21, 2010, at 5:34 PM, Timur Tabi wrote:
On Tue, Sep 21, 2010 at 5:17 PM, Scott Wood scottw...@freescale.com wrote:
It needs to be the actual device that is performing the DMA -- the
platform may need to do
From: Tirumala Marri tma...@apm.com
This patch creates new file with SoC dependent functions.
Signed-off-by: Tirumala R Marri tma...@apm.com
---
V1:
* Remove all 440SPe specific references.
* Move some of the code from header file to c file.
---
drivers/dma/ppc4xx/ppc4xx-adma.c | 1658
From: Tirumala Marri tma...@apm.com
This patch merges dma.h and xor.h to create ppc440spe-dma.h
Signed-off-by: Tirumala R Marri tma...@apm.com
---
V1:
* No change.
---
drivers/dma/ppc4xx/dma.h | 223 -
drivers/dma/ppc4xx/ppc440spe-dma.h | 318
On Fri, 24 Sep 2010, Benjamin Herrenschmidt wrote:
On Thu, 2010-09-23 at 19:31 +0200, Richard Cochran wrote:
The new syscall, clock_adjtime, takes two parameters, the clock ID,
and a pointer to a struct timex. The semantics of the timex struct
have been expanded by one additional mode flag,
On Fri, Sep 24, 2010 at 08:01:04AM +1000, Benjamin Herrenschmidt wrote:
On Thu, 2010-09-23 at 10:12 -0500, Ayman El-Khashab wrote:
I've implemented a working driver on my 460EX. it allocates a couple
of buffers of 4MB each. I have a custom memcmp algorithm in asm that
is extremely fast in
Will both versions of this driver exist in the same kernel build? For
example the iop-adma driver supports iop13xx and iop3xx, but we select
the archtitecture at build time? Or, as I assume in this case, will
the
two (maybe more?) ppc4xx adma drivers all be built in the same image,
more
Did you look at this changelog before sending? It just deletes 4000
lines of code??
[Marri] The reason I have to send it in different file is the size of the
patch.
There seem to be issue with patch sizes 200k or more.
___
Linuxppc-dev mailing list
On 9/23/2010 3:10 PM, tma...@apm.com wrote:
From: Tirumala Marritma...@apm.com
This patch generalizes the existing drver/dma/ppc4xx/adma.c, so that
common code can be shared between different similar DMA engine
drivers in other SoCs. Also Makefile and Kconfig changed to accommodate
PPC4XX.
On 9/23/2010 3:11 PM, tma...@apm.com wrote:
From: Tirumala Marritma...@apm.com
This patch creates new file with SoC dependent functions.
Signed-off-by: Tirumala R Marritma...@apm.com
---
V1:
* Remove all 440SPe specific references.
Maybe it renames ppc440spe to ppc4xx but it adds things
On 9/23/2010 3:44 PM, Tirumala Marri wrote:
Did you look at this changelog before sending? It just deletes 4000
lines of code??
[Marri] The reason I have to send it in different file is the size of the
patch.
There seem to be issue with patch sizes 200k or more.
Read the rest of what I
On Thu, 2010-09-23 at 17:35 -0500, Ayman El-Khashab wrote:
Anything you allocate with kmalloc() is going to be mapped by bolted
256M TLB entries, so there should be no TLB misses happening in the
kernel case.
Hi Ben, can you or somebody elaborate? I saw the pinned tlb in
44x_mmu.c.
On Fri, 2010-09-24 at 00:12 +0200, Thomas Gleixner wrote:
This list is getting way too much unrelated stuff, which I find
annoying, it would be nice if we were all a bit more careful here
with
our CC lists.
Says the guy who missed to trim the useless context of the original
mail, which
On Fri, Sep 24, 2010 at 11:07:24AM +1000, Benjamin Herrenschmidt wrote:
On Thu, 2010-09-23 at 17:35 -0500, Ayman El-Khashab wrote:
Anything you allocate with kmalloc() is going to be mapped by bolted
256M TLB entries, so there should be no TLB misses happening in the
kernel case.
No. The first pinned entry (0...256M) is inserted by the asm code in
head_44x.S. The code in 44x_mmu.c will later map the rest of lowmem
(typically up to 768M but various settings can change that) using more
256M entries.
Thanks Ben, appreciate all your wisdom and insight.
Ok, so my
-Original Message-
From:
linuxppc-dev-bounces+tiejun.chen=windriver@lists.ozlabs.or
g
[mailto:linuxppc-dev-bounces+tiejun.chen=windriver@lists.o
zlabs.org] On Behalf Of Scott Wood
Sent: Friday, September 24, 2010 4:34 AM
To: Gortmaker, Paul
Cc:
On Thu, 2010-09-23 at 09:13 -0400, Neil Horman wrote:
On Thu, Sep 23, 2010 at 08:57:20PM +1000, Michael Neuling wrote:
+ if (fwrite(line, strlen(line) - 1, 1, file) == 0)
if (fputs(line, file) == EOF)
Good point thanks... new patch below
Mikey
-Original Message-
From:
linuxppc-dev-bounces+tiejun.chen=windriver@lists.ozlabs.or
g
[mailto:linuxppc-dev-bounces+tiejun.chen=windriver@lists.o
zlabs.org] On Behalf Of Benjamin Herrenschmidt
Sent: Friday, September 24, 2010 5:59 AM
To: Scott Wood
Cc: Gortmaker, Paul;
-Original Message-
From: david.hag...@gmail.com [mailto:david.hag...@gmail.com]
Sent: Thursday, September 23, 2010 10:44 PM
To: Chen, Tiejun
Cc: David Hagood; linuxppc-...@ozlabs.org
Subject: RE: MPC8641D PEX: programming OWBAR in Endpoint mode?
-Original Message-
via
71 matches
Mail list logo
