something's amiss.
While we're at it, also use pr_err() to neaten the code up a bit.
Signed-off-by: Mark Nelson ma...@au1.ibm.com
---
arch/powerpc/platforms/pseries/event_sources.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
Index: upstream/arch/powerpc
it
RTAS_VECTOR_EXTERNAL_INTERRUPT.
Signed-off-by: Mark Nelson ma...@au1.ibm.com
---
arch/powerpc/include/asm/rtas.h |3 +++
arch/powerpc/platforms/pseries/ras.c |5 ++---
2 files changed, 5 insertions(+), 3 deletions(-)
Index: upstream/arch/powerpc/include/asm/rtas.h
Hi Michael,
Thanks for looking over these patches!
On Tuesday 18 May 2010 22:40:51 Michael Ellerman wrote:
On Mon, 2010-05-17 at 22:33 +1000, Mark Nelson wrote:
At the moment only the RAS code uses event-sources interrupts (for EPOW
events and internal errors) so request_ras_irqs() (which
On Wednesday 19 May 2010 16:35:54 Michael Ellerman wrote:
On Wed, 2010-05-19 at 16:35 +1000, Mark Nelson wrote:
Hi Michael,
Thanks for looking over these patches!
..
Existing code I know, but the error handling in here is a little lax,
what's not going to work if we miss some
rename request_ras_irqs() to request_event_sources_irqs() and
move it to event_sources.c.
This will be used in an upcoming patch that adds support for IO Event
interrupts that come through as event sources.
Signed-off-by: Mark Nelson ma...@au1.ibm.com
---
Changes v1 - v2:
* move the prototype
On Tuesday 18 May 2010 23:37:31 Michael Ellerman wrote:
On Mon, 2010-05-17 at 22:53 +1000, Mark Nelson wrote:
This patch adds support for handling IO Event interrupts which come
through at the /event-sources/ibm,io-events device tree node.
Hi Mark,
You'll have to explain to me offline
On Wednesday 19 May 2010 14:27:44 Sonny Rao wrote:
On Tue, 18 May 2010 23:37:31 +1000, Michael Ellerman wrote:
On Mon, 2010-05-17 at 22:53 +1000, Mark Nelson wrote:
This patch adds support for handling IO Event interrupts which come
through at the /event-sources/ibm,io-events device
rename request_ras_irqs() to request_event_sources_irqs() and
move it to event_sources.c.
This will be used in an upcoming patch that adds support for IO Event
interrupts that come through as event sources.
Signed-off-by: Mark Nelson ma...@au1.ibm.com
---
arch/powerpc/platforms/pseries/Makefile
register with IOEI_SCOPE_ANY.
A driver can unregister to stop receiving the IO Event interrupts using
ioei_unregister_isr(), passing it the same function pointer to the
driver's handler and the scope the driver was registered with.
Signed-off-by: Mark Nelson ma...@au1.ibm.com
---
arch/powerpc/include
() and then handing out chunks of this to
vmemmap_list_populate().
This means that we waste at most just under one page, but this keeps the code
is simple.
Signed-off-by: Mark Nelson ma...@au1.ibm.com
---
changes since v2:
- use a pointer to the next struct vmemmap_backing instead of an hlist
- add
On Tuesday 13 April 2010 21:16:44 Benjamin Herrenschmidt wrote:
On Tue, 2010-04-13 at 16:02 +1000, Mark Nelson wrote:
That's a good question, and one that I probably should have added to
the
commit message.
But, following through, it looks like we end up calling into
__remove_section
don't need a spinlock to protect the vmemmap_list.
Signed-off-by: Mark Nelson ma...@au1.ibm.com
---
changes since v1:
- use an hlist to save space in the structure
- remove the spinlock because it's not needed
arch/powerpc/include/asm/pgalloc-64.h |7 +++
arch/powerpc/mm/init_64.c
On Tuesday 13 April 2010 15:24:17 Michael Ellerman wrote:
On Tue, 2010-04-13 at 14:16 +1000, Mark Nelson wrote:
We need to keep track of the backing pages that get allocated by
vmemmap_populate() so that when we use kdump, the dump-capture kernel knows
where these pages are.
We use
to track the backing pages.
And we use a simple spinlock to protect the vmemmap_list.
Signed-off-by: Mark Nelson ma...@au1.ibm.com
---
arch/powerpc/include/asm/pgalloc-64.h |7 +++
arch/powerpc/mm/init_64.c | 27 +++
2 files changed, 34 insertions(+)
Index
Hi Anton,
On Thursday 11 February 2010 15:07:54 Anton Blanchard wrote:
A number of our chips like loads and stores to be paired. A small kernel
module testcase shows the improvement of pairing loads and stores in
copy_4k_page:
POWER6: +9%
POWER7: +1.5%
I just tried this on one of our
in the stack, and enforce it by updating the value of
os_cppr-stack[0] rather than os_cppr-stack[os_cppr-index].
While we're at it change the BUG_ON to a WARN_ON.
Reported-by: Anton Blanchard an...@samba.org
Signed-off-by: Mark Nelson ma...@au1.ibm.com
---
Ben, if it's not too late for 2.6.33
in the future.
This will also be useful because the partition adjunct option of
upcoming machines will update the H_XIRR hcall to accept the CPPR
as a parameter.
Signed-off-by: Mark Nelson ma...@au1.ibm.com
---
changes since v1:
* simplified function names to push_cppr() and pop_cppr()
* added checking
in the future.
This will also be useful because the partition adjunct option of
upcoming machines will update the H_XIRR hcall to accept the CPPR
as a parameter.
Signed-off-by: Mark Nelson ma...@au1.ibm.com
---
arch/powerpc/platforms/pseries/xics.c | 48 ++
1 file
On Tuesday 07 July 2009 21:08:25 Benjamin Herrenschmidt wrote:
On Tue, 2009-07-07 at 10:15 +1000, Mark Nelson wrote:
When the 32 and 64bit DMA code was merged in .28 , map_/unmap_page() was
added in favour of map_/unmap_single() (which was later removed in .29)
so you'll have to replace
On Tuesday 07 July 2009 03:51:00 Kári Davíðsson wrote:
I am doing a driver that uses dma_map_single().
After changing to to linux 2.6.29.3 I am getting
segfaults in dma_map_single() because dma_ops-map_page is NULL.
Actually dma_ops looks funky too.
When the 32 and 64bit DMA code was merged
the WDRTAS_SP_SPI_LEN so we don't litter '4' throughout the
function.
Signed-off-by: Mark Nelson ma...@au1.ibm.com
---
Adrian, does this patch cause any problems for your pxcabs?
Thanks!
Mark
drivers/watchdog/wdrtas.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
Index: upstream
On Tue, 24 Mar 2009 11:31:31 pm Adrian Reber wrote:
On Tue, Mar 24, 2009 at 05:30:41PM +1100, Mark Nelson wrote:
The buffer passed to the ibm,get-system-parameter RTAS call must be
in the RMA. To ensure we pass an address in the RMA use rtas_data_buf
for the actual RTAS call and then copy
On Wed, 25 Mar 2009 01:31:32 am Utz Bacher wrote:
Adrian Reber adr...@lisas.de wrote on 24.03.2009 13:31:31:
On Tue, Mar 24, 2009 at 05:30:41PM +1100, Mark Nelson wrote:
The buffer passed to the ibm,get-system-parameter RTAS call must be
in the RMA. To ensure we pass an address in the RMA
On Wed, 25 Feb 2009 08:50:46 pm Geert Uytterhoeven wrote:
On Wed, 25 Feb 2009, Mark Nelson wrote:
On Tue, 24 Feb 2009 05:38:37 pm Sachin P. Sant wrote:
Jan Kara wrote:
Hmm, OK. But then I'm not sure how that can happen. Obviously, memcpy
somehow got beyond end of the page
On Wed, 25 Feb 2009 10:08:22 pm Sachin P. Sant wrote:
Mark Nelson wrote:
Hi Sanchin and Geert,
Does the patch below fix the problems you're seeing? If it does I'll send
a properly written up and formatted patch to linuxppc-dev (as well as
another one to fix the same problem
On Thu, 26 Feb 2009 12:31:20 am Geert Uytterhoeven wrote:
On Wed, 25 Feb 2009, Mark Nelson wrote:
On Wed, 25 Feb 2009 08:50:46 pm Geert Uytterhoeven wrote:
On Wed, 25 Feb 2009, Mark Nelson wrote:
On Tue, 24 Feb 2009 05:38:37 pm Sachin P. Sant wrote:
Jan Kara wrote:
Hmm, OK
On Thu, 26 Feb 2009 09:45:41 am Mark Nelson wrote:
On Thu, 26 Feb 2009 12:31:20 am Geert Uytterhoeven wrote:
On Wed, 25 Feb 2009, Mark Nelson wrote:
On Wed, 25 Feb 2009 08:50:46 pm Geert Uytterhoeven wrote:
On Wed, 25 Feb 2009, Mark Nelson wrote:
On Tue, 24 Feb 2009 05:38:37 pm
] c016aaec .compat_sys_open+0x24/0x38
[c0003baf3e30] c000855c syscall_exit+0x0/0x40
--- Exception: c01 (System Call) at 0ff0ef18
SP (ffc6f4b0) is in userspace
1:mon
Signed-off-by: Mark Nelson ma...@au1.ibm.com
Reported-by: Sachin Sant sach...@in.ibm.com
Tested-by: Sachin Sant sach
() with the
addition of fixes for the exception handling code required for
__copy_tofrom_user().
This stops us reading beyond the end of the source region we were told
to copy.
Signed-off-by: Mark Nelson ma...@au1.ibm.com
---
arch/powerpc/lib/copyuser_64.S | 38
On Wed, 25 Feb 2009 02:51:20 am Jan Kara wrote:
Hello,
On Tue 24-02-09 12:08:37, Sachin P. Sant wrote:
Jan Kara wrote:
Hmm, OK. But then I'm not sure how that can happen. Obviously, memcpy
somehow got beyond end of the page referenced by bh-b_data. So it means
that
On Wed, 25 Feb 2009 05:01:59 am Geert Uytterhoeven wrote:
On Mon, 23 Feb 2009, Paul Mackerras wrote:
Andrew Morton writes:
It looks like we died in ext3_xattr_block_get():
memcpy(buffer, bh-b_data + le16_to_cpu(entry-e_value_offs),
size);
Perhaps
On Tue, 24 Feb 2009 05:38:37 pm Sachin P. Sant wrote:
Jan Kara wrote:
Hmm, OK. But then I'm not sure how that can happen. Obviously, memcpy
somehow got beyond end of the page referenced by bh-b_data. So it means
that le16_to_cpu(entry-e_value_offs) + size page_size. But
.
CPU_FTR_UNALIGNED_LD_STD CPU was added in commit
4ec577a28980a0790df3c3dfe9c81f6eacfb
We also make the same simple one line change from cmpldi r1,... to cmpldi
cr1,... for consistency.
Signed-off-by: Mark Nelson [EMAIL PROTECTED]
---
arch/powerpc/lib/copyuser_64.S | 17 +++--
1 file
, just taking different arguments.
This has no effect on drivers because the dma_map_single_attrs() just ends up
calling the map_page() function of the appropriate dma_mapping_ops and
similarly the dma_unmap_single_attrs() calls unmap_page().
Signed-off-by: Mark Nelson [EMAIL PROTECTED
the checking for which set of functions to use.
Signed-off-by: Mark Nelson [EMAIL PROTECTED]
---
This is just a cleanup so can wait for 2.6.29
arch/powerpc/include/asm/dma-mapping.h | 36 -
1 file changed, 5 insertions(+), 31 deletions(-)
Index: upstream/arch
on CPUs that require
it.
Signed-off-by: Mark Nelson [EMAIL PROTECTED]
---
arch/powerpc/include/asm/cputable.h |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
Index: upstream/arch/powerpc/include/asm/cputable.h
,... to
cmpldi cr1,... for consistency.
Signed-off-by: Mark Nelson [EMAIL PROTECTED]
---
arch/powerpc/lib/memcpy_64.S | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
Index: upstream/arch/powerpc/lib/memcpy_64.S
On Thu, 14 Aug 2008 04:17:32 pm Mark Nelson wrote:
Hi All,
What follows is an updated version of copy_4K_page that has been tuned
for the Cell processor. With this new routine it was found that the
system time measured when compiling a 2.6.26 pseries_defconfig was
reduced by ~10s
because they show
better performance with the new copy_4K_page() when dcbt and dcbz
instructions are used.
Signed-off-by: Mark Nelson [EMAIL PROTECTED]
---
arch/powerpc/include/asm/cputable.h |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
Index: upstream/arch/powerpc/include/asm
in the
previous patch) is used to make the modification to this new copy
routine - on Power4, 970 and Cell the feature bit is set so the
setup loop is executed, but on all other 64bit chips the setup
loop is nop'ed out.
Signed-off-by: Mark Nelson [EMAIL PROTECTED]
---
arch/powerpc/lib/copypage_64.S
On Thu, 14 Aug 2008 10:10:48 pm Michael Ellerman wrote:
On Thu, 2008-08-14 at 21:48 +1000, Mark Nelson wrote:
Hi Michael,
On Thu, 14 Aug 2008 08:51:35 pm Michael Ellerman wrote:
On Thu, 2008-08-14 at 16:18 +1000, Mark Nelson wrote:
Add a new CPU feature, CPU_FTR_CP_USE_DCBTZ
Hi All,
What follows is an updated version of copy_4K_page that has been tuned
for the Cell processor. With this new routine it was found that the
system time measured when compiling a 2.6.26 pseries_defconfig was
reduced by ~10s:
mainline (2.6.27-rc1-00632-g2e1e921):
real17m8.727s
user
/*
* Copyright (C) 2008 Mark Nelson, IBM Corp.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later
-by: Mark Nelson [EMAIL PROTECTED]
---
arch/powerpc/include/asm/cputable.h |9 ++---
arch/powerpc/lib/copypage_64.S |3 ++-
2 files changed, 8 insertions(+), 4 deletions(-)
Index: upstream/arch/powerpc/include/asm/cputable.h
Hi Michael,
On Thu, 14 Aug 2008 08:51:35 pm Michael Ellerman wrote:
On Thu, 2008-08-14 at 16:18 +1000, Mark Nelson wrote:
Add a new CPU feature, CPU_FTR_CP_USE_DCBTZ, to be added to the CPUs that
benefit
from having dcbt and dcbz instructions used in copy_4K_page(). So far Cell,
PPC970
From: Mark Nelson [EMAIL PROTECTED]
At the moment the fixed mapping is by default strongly ordered (the
iommu_fixed=weak boot option must be used to make the fixed mapping weakly
ordered). If we're on a setup where the southbridge is being used in
endpoint mode (triblade and CAB boards
From: Mark Nelson [EMAIL PROTECTED]
At the moment the fixed mapping is by default strongly ordered (the
iommu_fixed=weak boot option must be used to make the fixed mapping weakly
ordered). If we're on a setup where the southbridge is being used in
endpoint mode (triblade and CAB boards
On Fri, 20 Jun 2008 09:49:29 am Mark Nelson wrote:
On Thu, 19 Jun 2008 09:53:16 pm Arnd Bergmann wrote:
On Thursday 19 June 2008, Mark Nelson wrote:
The plan is to use Michael Ellerman's code patching work so that at
runtime
if we're running on a Cell machine the new routines
/*
* Copyright (C) 2008 Gunnar von Boehn, IBM Corp.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later
/*
* Copyright (C) 2008 Gunnar von Boehn, IBM Corp.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later
On Thu, 19 Jun 2008 09:53:16 pm Arnd Bergmann wrote:
On Thursday 19 June 2008, Mark Nelson wrote:
The plan is to use Michael Ellerman's code patching work so that at runtime
if we're running on a Cell machine the new routines are called but otherwise
the existing memory copy routines
On Fri, 20 Jun 2008 12:53:49 am Olof Johansson wrote:
On Jun 19, 2008, at 8:59 AM, Arnd Bergmann wrote:
I assume it has suffered from bitrot and nobody tried to do better
since the Power3 days. AFAICT, it hasn't seen any update since your
original Power4 version from 2002.
I've got
* The naming of the labels (with just numbers) is rather confusing,
it would be good to have something better, but I must admit that
I don't have a good idea either.
I will admit that at first glance the label naming with numbers
does look confusing but when you notice that all the loads start
On Fri, 20 Jun 2008 07:28:50 am Arnd Bergmann wrote:
On Thursday 19 June 2008, Mark Nelson wrote:
.align 7
_GLOBAL(copy_4K_page)
dcbt0,r4/* Prefetch ONE SRC cacheline */
addir6,r3,-8/* prepare for stdu */
addir4,r4,-8
On Fri, 23 May 2008 06:06:50 pm Mark Nelson wrote:
On Thu, 1 May 2008 09:36:43 am Becky Bruce wrote:
I essentially adopt the 64-bit dma code, with some changes to support
32-bit systems, including HIGHMEM. dma functions on 32-bit are now
invoked via accessor functions which call
. Adding these to dma_ops makes it cleaner to
substitute different functionality once we have iommu/swiotlb support.
This code conflicts with the dma_attrs code that Mark Nelson just pushed.
At this point, I'm just looking for some review, and suggestions on how
this code might be improved
On Thu, 1 May 2008 07:04:30 pm Segher Boessenkool wrote:
Move device_to_mask() to dma-mapping.h because we need to use it from
outside dma_64.c in a later patch.
Why does this need to become an inline function?
Segher
I'm not sure exactly what you mean - it was inline before the
Olof Johansson wrote:
On Tue, Apr 29, 2008 at 03:17:45PM +1000, Mark Nelson wrote:
Make iommu_map_sg take a struct iommu_table. It did so before commit
740c3ce66700640a6e6136ff679b067e92125794 (iommu sg merging: ppc: make
iommu respect the segment size limits).
This stops the function looking
with a device that has
no table there.
This also has the nice side effect of making iommu_map_sg() match the
other map functions.
Signed-off-by: Mark Nelson [EMAIL PROTECTED]
---
arch/powerpc/kernel/dma_64.c |2 +-
arch/powerpc/kernel/iommu.c |7 +++
include/asm-powerpc/iommu.h |6
be
added with an appropriate #define.
#define ELF_CORE_XFPREG_TYPE to be NT_PRXFPREG in all current users so
there's are no change in behaviour.
Can we make this ELF_CORE_VECREG_TYPE or something that is so coupled to
the x86 specific name?
Signed-off-by: Mark Nelson [EMAIL PROTECTED
have.
Signed-off-by: Mark Nelson [EMAIL PROTECTED]
---
arch/ia64/ia32/elfcore32.h |1 +
arch/x86_64/ia32/ia32_binfmt.c |1 +
fs/binfmt_elf.c|8
fs/binfmt_elf_fdpic.c |6 +++---
include/asm-i386/elf.h |1 +
5 files changed, 10
Sorry for the patch noise but please disregard this patch - a line is longer
than 80 characters and I'd hate to be brought up on that...
V3 will be the perfect version then :)
Thanks and apologies again!
Mark.
Mark Nelson wrote:
Replace NT_PRXFPREG with ELF_CORE_XFPREG_TYPE in the coredump
have.
Signed-off-by: Mark Nelson [EMAIL PROTECTED]
---
arch/ia64/ia32/elfcore32.h |1 +
arch/x86_64/ia32/ia32_binfmt.c |1 +
fs/binfmt_elf.c|8
fs/binfmt_elf_fdpic.c |8
include/asm-i386/elf.h |1 +
5 files changed, 11
Kumar Gala wrote:
On Sep 24, 2007, at 11:03 PM, Mark Nelson wrote:
Update dump_task_altivec() (that has so far never been put to use)
so that it dumps the Altivec/VMX registers (VR[0] - VR[31], VSCR
and VRSAVE) in the same format as the ptrace get_vrregs() and add
the appropriate glue
Kumar Gala wrote:
On Sep 25, 2007, at 8:22 PM, Mark Nelson wrote:
Kumar Gala wrote:
On Sep 24, 2007, at 11:03 PM, Mark Nelson wrote:
Update dump_task_altivec() (that has so far never been put to use)
so that it dumps the Altivec/VMX registers (VR[0] - VR[31], VSCR
and VRSAVE
-by: Mark Nelson [EMAIL PROTECTED]
---
arch/powerpc/kernel/process.c | 28 +---
include/asm-powerpc/elf.h |7 +++
2 files changed, 32 insertions(+), 3 deletions(-)
Index: linux/arch/powerpc/kernel/process.c
66 matches
Mail list logo
