2.6.32-longterm review patch. If anyone has any objections, please let us know.
--
From: Milton Miller milt...@bga.com
commit 5db1256a5131d3b133946fa02ac9770a784e6eb2 upstream.
Move the smp_rmb after cpu_relax loop in read_seqlock and add
ACCESS_ONCE to make sure the test and
2.6.33-longterm review patch. If anyone has any objections, please let us know.
--
From: Milton Miller milt...@bga.com
commit 5db1256a5131d3b133946fa02ac9770a784e6eb2 upstream.
Move the smp_rmb after cpu_relax loop in read_seqlock and add
ACCESS_ONCE to make sure the test and
On Wed, Jun 15, 2011 at 04:34:17PM -0700, Nishanth Aravamudan wrote:
That looks like the right thing to do. For ipr's usage of
libata, we don't have the concept of a port frozen state, so this flag
should really never get set. The alternate way to fix this would be to
only set
The format of memory/reg is based on the #address-cells,#size-cells. Currently,
the kexec-tools doesn't use the above values in parsing the memory/reg values.
Hence the kexec cannot handle cases where #address-cells, #size-cells are
different, (for e.g, PPC440X ).
This patch introduces a
The problem was with the mail client. Also, mistyped the To field in the
previous
one. Resending.
ChangeLog from V1:
* Changed the interface for read_memory_region_limits to use 'int fd'
* Use sizeof(variable) for read(, instead of sizeof(type).
---
The format of memory/reg is
On 06/16/2011 02:51 AM, Tejun Heo wrote:
On Wed, Jun 15, 2011 at 04:34:17PM -0700, Nishanth Aravamudan wrote:
That looks like the right thing to do. For ipr's usage of
libata, we don't have the concept of a port frozen state, so this flag
should really never get set. The alternate way to fix
Hi,
John mentioned in his email that we have some patches.
I am also sending them [patch 1/7-6/7]. It is support for non zero
boot address for ppc44x.
Patch 7/7 is relocatable support for ppc44x.
All patches are against 2.6.31.13 but it shouldn't be big problem
to port them to the latest and
From: John Williams john.willi...@petalogix.com
The macro PHYSICAL_START is available in this context, currently always with
the value zero. However, that will change in a future patchset.
For now, just remove the zero physical address start assumption in head_44x.S
where we setup the initial
From: John Williams john.willi...@petalogix.com
The initial TLB entry is 256M, meaning that the physical base address must be
256M aligned.
Signed-off-by: John Williams john.willi...@petalogix.com
---
arch/powerpc/Kconfig |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git
From: John Williams john.willi...@petalogix.com
It is unnecessarily restrictive to fatal() if there is physical memory at a
non-zero base address.
Signed-off-by: John Williams john.willi...@petalogix.com
---
arch/powerpc/boot/simpleboot.c |5 -
1 files changed, 0 insertions(+), 5
From: John Williams john.willi...@petalogix.com
There's no fundamental reason the bootwrapper can't boot off a non-zero base,
we just need to make sure we account for it in the link.
Do this by adding the (up-aligned) kernel size to membase, and using that as
the link address.
Signed-off-by:
Changes:
- Find out address where kernel runs
- Create the first 256MB TLB from online detected address
Limitations:
- Kernel must be aligned to 256MB
Backport:
- Changes in page.h are backported from newer kernel version
mmu_mapin_ram function has to reflect offset in memory start.
From: John Williams john.willi...@petalogix.com
simpleboot current assumes that the physical load address is zero, even if
the ELF payload has a non-zero paddr.
This is a simple fix that avoids a custom pltform_ops handler in this case.
Signed-off-by: John Williams john.willi...@petalogix.com
From: John Williams john.willi...@petalogix.com
The default kernel_fdt.its hard codes zero load/start addresses, but this may
no longer be true.
As we copy the FIT tree descriptor, update these values based on the incoming
ELF payload.
Signed-off-by: John Williams john.willi...@petalogix.com
On 16.06.2011 [08:28:39 -0500], Brian King wrote:
On 06/16/2011 02:51 AM, Tejun Heo wrote:
On Wed, Jun 15, 2011 at 04:34:17PM -0700, Nishanth Aravamudan wrote:
That looks like the right thing to do. For ipr's usage of
libata, we don't have the concept of a port frozen state, so this flag
Priyanka Jain wrote:
PT7C4338 chip is being manufactured by Pericom Technology Inc.
It is a serial real-time clock which provides:
1)Low-power clock/calendar.
2)Programmable square-wave output.
It has 56 bytes of nonvolatile RAM.
Its register set is same as that of rtc device: DS1307.
The wrong MCSR bit was being used on e500mc. MCSR_BUS_RBERR only exists
on e500v1/v2. Use MCSR_LD on e500mc, and remove all MCSR checking
in fsl_rio_mcheck_exception as we now no longer call that function
if the appropriate bit in MCSR is not set.
If RIO support was enabled at compile-time, but
On Thu, Jun 16, 2011 at 10:38:11AM -0500, Timur Tabi wrote:
Priyanka Jain wrote:
PT7C4338 chip is being manufactured by Pericom Technology Inc.
It is a serial real-time clock which provides:
1)Low-power clock/calendar.
2)Programmable square-wave output.
It has 56 bytes of nonvolatile
On Thu, Jun 16, 2011 at 04:15:13PM +0530, Suzuki K. Poulose wrote:
The format of memory/reg is based on the #address-cells,#size-cells.
Currently,
the kexec-tools doesn't use the above values in parsing the memory/reg values.
Hence the kexec cannot handle cases where #address-cells,
This moves various HVSI protocol definitions from the hvsi.c
driver to a header file that can be used later on by a udbg
implementation
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/include/asm/hvsi.h | 68 +++
Embed the struct hvsi_header in the various packet definitions
rather than open coding it multiple times. Will help provide
stronger type checking.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/include/asm/hvsi.h | 16 ++---
drivers/tty/hvc/hvsi.c
This will allow a different backend to share it
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/include/asm/hvsi.h | 34 +++
drivers/tty/hvc/Makefile|2 +-
drivers/tty/hvc/hvc_vio.c | 405 ++---
When CONFIG_PPC_EARLY_DEBUG is set, call register_early_udbg_console()
early from generic code.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/kernel/udbg.c|2 ++
arch/powerpc/platforms/pseries/lpar.c |2 --
2 files changed, 2 insertions(+), 2
On pseries machines, consoles are provided by the hypervisor using
a low level get_chars/put_chars type interface. However, this is
really just a transport to the service processor which implements
them either as raw console (networked consoles, HMC, ...) or as
hvsi serial ports.
The later is a
On Fri, 2011-06-03 at 17:12 -0500, Scott Wood wrote:
On MMUs such as FSL where we can guarantee the entire linear mapping is
bolted, we don't need to worry about linear TLB misses. If on top of
that we do a full table walk, we get rid of all recursive TLB faults, and
can dispense with some
On Sat, 2011-05-21 at 14:28 +0400, Dmitry Eremin-Solenikov wrote:
Add simple cpufreq driver for Maple-based boards (ppc970fx evaluation
kit and others). Driver is based on a cpufreq driver for 64-bit powermac
boxes with all pmac-dependant features removed and simple cleanup
applied.
No
On Wed, 2011-06-01 at 18:05 +0530, Deepthi Dharwar wrote:
Hi,
Please find below a patch, which has perf_events added for pseries (ppc64)
platform in order to emit the trace required for perf timechart.
It essentially enables perf timechart for pseries platfrom to analyse
power savings
On Tue, 2011-06-07 at 21:59 +0530, Trinabh Gupta wrote:
From: Len Brown len.br...@intel.com
useful for disabling cpuidle to fall back
to architecture-default idle loop
cpuidle drivers and governors will fail to register.
on x86 they'll say so:
intel_idle: intel_idle yielding to (null)
On Tue, 2011-06-07 at 22:00 +0530, Trinabh Gupta wrote:
diff --git a/arch/powerpc/kernel/idle.c b/arch/powerpc/kernel/idle.c
index 39a2baa..932392b 100644
--- a/arch/powerpc/kernel/idle.c
+++ b/arch/powerpc/kernel/idle.c
@@ -102,6 +102,24 @@ void cpu_idle(void)
}
}
+static void
On Tue, 2011-06-07 at 22:00 +0530, Trinabh Gupta wrote:
+static int snooze_loop(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ unsigned long in_purr, out_purr;
+ ktime_t kt_before, kt_after;
+ s64 usec_delta;
Here are POWER7 optimised versions of copy_page, memcpy and
copy_tofrom_user.
Anton
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Implement a POWER7 optimised copy_page using VMX. We copy a cacheline
at a time using VMX loads and stores.
Signed-off-by: Anton Blanchard an...@samba.org
---
How do we want to handle per machine optimised functions? I create
yet another feature bit, but feature bits might get out of control
at
Implement a POWER7 optimised memcpy using VMX. For large aligned
copies this new loop is over 10% faster and for large unaligned
copies it is over 200% faster.
On POWER7 unaligned stores rarely slow down - they only flush when
a store crosses a 4KB page boundary. Furthermore this flush is
handled
Implement a POWER7 optimised copy_to_user/copy_from_user using VMX.
For large aligned copies this new loop is over 10% faster, and for
large unaligned copies it is over 200% faster.
If we take a fault we fall back to the old version, this keeps
things relatively simple and easy to verify.
(The
On Tue, 2011-05-24 at 06:51 +1000, Benjamin Herrenschmidt wrote:
On Mon, 2011-05-23 at 15:26 -0500, Scott Wood wrote:
On Sat, 21 May 2011 08:32:58 +1000
Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
On Fri, 2011-05-20 at 14:00 -0500, Scott Wood wrote:
Signed-off-by: Scott
Implement a POWER7 optimised copy_page using VMX. We copy a cacheline
at a time using VMX loads and stores.
Signed-off-by: Anton Blanchard an...@samba.org
---
How do we want to handle per machine optimised functions? I create
yet another feature bit, but feature bits might get out of
Hi,
Yeah, I'm pretty against CPU_FTR_POWER7. Every loon is going to
attach anything POWER7 to it.
I'm keen to see it setup in __setup_cpu_power7. Either a function
pointer or use the patch_instruction infrastructure to avoid indirect
function calls on small copies.
Instruction
On Tue, 2011-05-31 at 14:19 -0500, Meador Inge wrote:
Some MPIC implementations contain one or more blocks of message registers
that are used to send messages between cores via IPIs. A simple API has
been added to access (get/put, read, write, etc ...) these message registers.
The available
Hi all,
After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:
mm/page_cgroup.c: In function 'page_cgroup_init':
mm/page_cgroup.c:309:13: error: 'pg_data_t' has no member named 'node_end_pfn'
Caused by commit 37573e8c7182 (memcg: fix init_page_cgroup nid
(Original mail lost in my email cleanup so this isn't a proper reply)
I'll apply that for now, but I'd very much like somebody to just get rid
of the whole ppc_md.progress business.
We have printk working early enough nowadays (and we can use udbg for
debugging).
It was meant to display magic
On Fri, 2011-06-17 at 14:53 +1000, Anton Blanchard wrote:
plain text document attachment (power7_copypage)
Implement a POWER7 optimised copy_page using VMX. We copy a cacheline
at a time using VMX loads and stores.
Signed-off-by: Anton Blanchard an...@samba.org
---
How do we want to
On Fri, 2011-06-17 at 14:53 +1000, Anton Blanchard wrote:
+#include asm/page.h
+#include asm/ppc_asm.h
+
+#define STACKFRAMESIZE 112
+
+_GLOBAL(copypage_power7)
+ mflrr0
+ std r3,48(r1)
+ std r4,56(r1)
+ std r0,16(r1)
+ stdu
O
+.Lvmx_copy:
+ mflrr0
+ std r4,56(r1)
+ std r5,64(r1)
+ std r0,16(r1)
+ stdur1,-STACKFRAMESIZE(r1)
+ bl .enable_kernel_altivec
+ ld r0,STACKFRAMESIZE+16(r1)
+ ld r3,STACKFRAMESIZE+48(r1)
+ ld
On Fri, 2011-06-17 at 14:54 +1000, Anton Blanchard wrote:
plain text document attachment (power7_copy_tofrom_user)
Implement a POWER7 optimised copy_to_user/copy_from_user using VMX.
For large aligned copies this new loop is over 10% faster, and for
large unaligned copies it is over 200%
44 matches
Mail list logo
