On Mon, 2011-05-16 at 16:37 +1000, Michael Neuling wrote:
what is the best book to learn assembly and architecture .
Assuming you have a powerpc compiler available you can use the -S
option to produce assembly listings.
With gcc add -fverbose-asm for more info.
For a general
(Just adding Milton to the CC list, he suspects races in the driver
instead).
On Wed, 2011-05-18 at 08:23 +0400, James Bottomley wrote:
On Tue, 2011-05-17 at 22:15 -0600, Matthew Wilcox wrote:
On Wed, May 18, 2011 at 09:37:08AM +0530, Desai, Kashyap wrote:
On Wed, 2011-05-04 at 17:23 +0530,
static inline void writeq(__u64 val, volatile void __iomem
*addr)
{
writel(val, addr);
writel(val 32, addr+4);
}
...
We need the 64 bit completed in one access pci memory write,
else spin lock is required.
Since it's going to be difficult to know
On Wed, May 18, 2011 at 07:40:16AM +1000, Benjamin Herrenschmidt wrote:
On Tue, 2011-05-17 at 18:28 +0200, Richard Cochran wrote:
Ben,
Recent 2.6.39-rc kernels behave strangely on the Freescale dual core
mpc8572 and p2020. There is a long pause (like 2 seconds) in the boot
sequence
From: Matthias Klose d...@ubuntu.com
Landed in Ubuntu klibc version 1.5.20-1ubuntu3.
Signed-off-by: maximilian attems m...@stro.at
---
usr/klibc/arch/ppc64/crt0.S | 17 +
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/usr/klibc/arch/ppc64/crt0.S
On Wed, May 18, 2011 at 4:02 AM, Prashant Bhole
prashantsmailcen...@gmail.com wrote:
On Mon, May 2, 2011 at 10:21 AM, Prashant Bhole
prashantsmailcen...@gmail.com wrote:
Hi,
I have a custom made powerpc 460EX board. On that board u-boot
can see a PCI device but Linux kernel cannot see it.
Does this patch help? If so please reply to that thread so patchwork
will see it in addition to here.
http://patchwork.ozlabs.org/patch/96146/
milton
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
On Wed, 18 May 2011 about 09:35:56 -0600, Eric Moore wrote:
On Wednesday, May 18, 2011 2:24 AM, Milton Miller wrote:
On Wed, 18 May 2011 around 17:00:10 +1000, Benjamin Herrenschmidt wrote:
(Just adding Milton to the CC list, he suspects races in the
driver instead).
On Wed,
On Wednesday, May 18, 2011 12:31 PM Milton Miller wrote:
Ingo I would propose the following commits added in 2.6.29 be reverted.
I think the current concensus is drivers must know if the writeq is
not atomic so they can provide their own locking or other workaround.
Exactly.
This saves a few cycles, at least on e5500.
Signed-off-by: Scott Wood scottw...@freescale.com
---
arch/powerpc/include/asm/exception-64e.h | 16 +++-
arch/powerpc/kernel/paca.c |5 +
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git
Loads with non-linear access patterns were producing a very high
ratio of recursive pt faults to regular tlb misses. Rather than
choose between a 4-level table walk or a 1-level virtual page table
lookup, use a hybrid scheme with a virtual linear pmd, followed by a
2-level lookup in the normal
A little more speed up measured on e5500.
Setting of U0-3 is dropped as it is not used by Linux as far as I can
see.
Signed-off-by: Scott Wood scottw...@freescale.com
---
arch/powerpc/mm/tlb_low_64e.S | 21 -
1 files changed, 8 insertions(+), 13 deletions(-)
diff --git
Signed-off-by: Scott Wood scottw...@freescale.com
---
Is there any 64-bit book3e chip that doesn't support this? It
doesn't appear to be optional in the ISA.
arch/powerpc/kernel/cputable.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/cputable.c
Load it only when needed, in recursive/linear/indirect faults,
and in the stats code.
Signed-off-by: Scott Wood scottw...@freescale.com
---
arch/powerpc/include/asm/exception-64e.h | 28 +-
arch/powerpc/mm/tlb_low_64e.S| 43 +
2 files
I don't see where any non-standard page size will be set in the
kernel page tables, so don't waste time checking for it. It wouldn't
work with TLB0 on an FSL MMU anyway, so if there's something I missed
(or which is out-of-tree), it's relying on implementation-specific
behavior. If there's an
The Linux kernel patches for the IBM BlueGene/P have been open-sourced
for quite some time, but haven't been integrated into the mainline Linux
kernel source tree. This is the first patch series of several where I
will attempt to cleanup and mainline the already public patches. I
welcome
Signed-off-by: Eric Van Hensbergen eri...@gmail.com
---
arch/powerpc/kernel/cputable.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index b9602ee..0eb245e 100644
---
BG/P nodes need to be configured for writethrough to work in SMP
configurations. This patch adds the right hooks in the MMU code
to make sure L1_WRITETHROUGH configurations are setup for BG/P.
Signed-off-by: Eric Van Hensbergen eri...@gmail.com
---
arch/powerpc/include/asm/mmu-44x.h |2
This patch adds save/restore register support for the BlueGene/P
double hummer FPU.
Signed-off-by: Eric Van Hensbergen eri...@gmail.com
---
arch/powerpc/include/asm/ppc_asm.h | 39 ---
arch/powerpc/kernel/fpu.S |8 +++---
BG/P maps firmware with an early TLB
Signed-off-by: Eric Van Hensbergen eri...@gmail.com
---
arch/powerpc/include/asm/mmu-44x.h |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/mmu-44x.h
b/arch/powerpc/include/asm/mmu-44x.h
index
For BGP, it is convenient for 'kmalloc' to come back with 32-byte
aligned units for torus DMA
Signed-off-by: Eric Van Hensbergen eri...@gmail.com
---
arch/powerpc/include/asm/page_32.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/include/asm/page_32.h
This patch adds the necessary core code to enable SMP support on BlueGene/P
Signed-off-by: Eric Van Hensbergen eri...@gmail.com
---
arch/powerpc/kernel/head_44x.S | 72 +
arch/powerpc/mm/fault.c| 77
On Wed, 2011-05-18 at 09:35 -0600, Moore, Eric wrote:
I worked the original defect a couple months ago, and Kashyap is now
getting around to posting my patch's.
This original defect has nothing to do with PPC64. The original
problem was only on x86.It only became a problem on PPC64 when
On Wed, 2011-05-18 at 16:04 -0500, Scott Wood wrote:
This allows a virtual page table to be used at the PMD rather than
the PTE level.
Rather than adjust the constant in pgd_index() (or ignore it, as
too-large values don't hurt as long as overly large addresses aren't
passed in), go back to
On Wed, 2011-05-18 at 16:05 -0500, Scott Wood wrote:
Loads with non-linear access patterns were producing a very high
ratio of recursive pt faults to regular tlb misses. Rather than
choose between a 4-level table walk or a 1-level virtual page table
lookup, use a hybrid scheme with a virtual
On Wed, 2011-05-18 at 16:05 -0500, Scott Wood wrote:
I don't see where any non-standard page size will be set in the
kernel page tables, so don't waste time checking for it. It wouldn't
work with TLB0 on an FSL MMU anyway, so if there's something I missed
(or which is out-of-tree), it's
On Wed, 2011-05-18 at 16:05 -0500, Scott Wood wrote:
A little more speed up measured on e5500.
Setting of U0-3 is dropped as it is not used by Linux as far as I can
see.
Please keep them for now. If your core doesn't have them, make them an
MMU feature.
Cheers,
Ben.
Signed-off-by: Scott
On Thu, 19 May 2011 07:32:41 +1000
Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
On Wed, 2011-05-18 at 16:04 -0500, Scott Wood wrote:
This allows a virtual page table to be used at the PMD rather than
the PTE level.
Rather than adjust the constant in pgd_index() (or ignore it,
On Thu, 19 May 2011 07:36:04 +1000
Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
On Wed, 2011-05-18 at 16:05 -0500, Scott Wood wrote:
I don't see where any non-standard page size will be set in the
kernel page tables, so don't waste time checking for it. It wouldn't
work with
On Thu, 19 May 2011 07:37:47 +1000
Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
On Wed, 2011-05-18 at 16:05 -0500, Scott Wood wrote:
A little more speed up measured on e5500.
Setting of U0-3 is dropped as it is not used by Linux as far as I can
see.
Please keep them for
Why do you want to create a virtual page table at the PMD level ? Also,
you are changing the geometry of the page tables which I think we don't
want. We chose that geometry so that the levels match the segment sizes
on server, I think it may have an impact with the hugetlbfs code (check
On Thu, 19 May 2011 07:38:19 +1000
Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
On Wed, 2011-05-18 at 16:05 -0500, Scott Wood wrote:
Signed-off-by: Scott Wood scottw...@freescale.com
---
Is there any 64-bit book3e chip that doesn't support this? It
doesn't appear to be
On Wed, 2011-05-18 at 16:50 -0500, Scott Wood wrote:
On Thu, 19 May 2011 07:36:04 +1000
Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
On Wed, 2011-05-18 at 16:05 -0500, Scott Wood wrote:
I don't see where any non-standard page size will be set in the
kernel page tables, so
On Wed, 2011-05-18 at 16:51 -0500, Scott Wood wrote:
On Thu, 19 May 2011 07:37:47 +1000
Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
On Wed, 2011-05-18 at 16:05 -0500, Scott Wood wrote:
A little more speed up measured on e5500.
Setting of U0-3 is dropped as it is not used
On Wed, 2011-05-18 at 16:52 -0500, Scott Wood wrote:
On Thu, 19 May 2011 07:38:19 +1000
Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
On Wed, 2011-05-18 at 16:05 -0500, Scott Wood wrote:
Signed-off-by: Scott Wood scottw...@freescale.com
---
Is there any 64-bit book3e chip
On Wednesday, May 18, 2011 3:30 PM, Benjamin Herrenschmidt wrote:
You may also want to look at Milton's comments, it looks like the way
you do init_completion followed immediately by wait_completion is racy.
You should init the completion before you do the IO that will eventually
trigger
On Thu, 19 May 2011 07:54:48 +1000
Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
On Wed, 2011-05-18 at 16:51 -0500, Scott Wood wrote:
On Thu, 19 May 2011 07:37:47 +1000
Benjamin Herrenschmidt b...@kernel.crashing.org wrote:
On Wed, 2011-05-18 at 16:05 -0500, Scott Wood wrote:
On 03/31/2011 01:38 PM, Benjamin Herrenschmidt wrote:
On Thu, 2011-03-31 at 10:21 -0700, Jeremy Fitzhardinge wrote:
No, its the same accessors for both, since the need to distinguish them
hasn't really come up. Could you put a if (preemptable()) return;
guard in your implementations?
That
On Wed, 2011-05-18 at 11:57 +0200, Kerstin Jonsson wrote:
commit c56e58537d504706954a06570b4034c04e5b7500 breaks SMP support in PPC_47x
chip.
secondary_ti must be set to current thread info before callin kick_cpu or
else
start_secondary_47x will jump into void when trying to return to
Hi all,
After merging the powerpc tree, today's linux-next build (powerpc
allyesconfig) produced this warning:
WARNING: arch/powerpc/sysdev/built-in.o(.text+0x10eb8): Section mismatch in
reference from the function .ics_rtas_init() to the function
.init.text:.xics_register_ics()
The function
On Fri, 2011-05-06 at 22:57 -0700, Stephen Boyd wrote:
Most arches define CONFIG_DEBUG_STACK_USAGE exactly the same way.
Move it to lib/Kconfig.debug so each arch doesn't have to define
it. This obviously makes the option generic, but that's fine
because the config is already used in generic
On Tue, May 17, 2011 at 6:19 AM, Ingo Molnar mi...@elte.hu wrote:
* Steven Rostedt rost...@goodmis.org wrote:
On Tue, 2011-05-17 at 14:42 +0200, Ingo Molnar wrote:
* Steven Rostedt rost...@goodmis.org wrote:
On Mon, 2011-05-16 at 18:52 +0200, Ingo Molnar wrote:
* Steven Rostedt
On Wed, May 18, 2011 at 9:06 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
Dunno if it's too late or not yet but here's 3 fixes for powerpc that
would be welcome to have in before the release. If not I'll send them
first thing next (one of them is already in -next in fact).
Gah.
On Fri, 2011-02-11 at 15:34 -0800, Ira W. Snyder wrote:
Hello everyone,
This is the seventh posting of these drivers, taking into account comments
from earlier postings. I've made sure that the drivers both pass checkpatch
without any errors or warnings. I would appreciate as much review as
From: Linus Torvalds torva...@linux-foundation.org
Date: Wed, 18 May 2011 21:11:47 -0700
On Wed, May 18, 2011 at 9:06 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
Dunno if it's too late or not yet but here's 3 fixes for powerpc that
would be welcome to have in before the
On Thu, May 19, 2011 at 04:11, Moore, Eric eric.mo...@lsi.com wrote:
On Wednesday, May 18, 2011 12:31 PM Milton Miller wrote:
Ingo I would propose the following commits added in 2.6.29 be reverted.
I think the current concensus is drivers must know if the writeq is
not atomic so they can
On Wed, May 18, 2011 at 11:31 AM, Milton Miller milt...@bga.com wrote:
So the real question should be why is x86-32 supplying a broken writeq
instead of letting drivers work out what to do it when needed?
Sounds a lot like what I was asking a couple of years ago :)
On Thu, 2011-05-19 at 13:08 +0900, Hitoshi Mitake wrote:
On Thu, May 19, 2011 at 04:11, Moore, Eric eric.mo...@lsi.com wrote:
On Wednesday, May 18, 2011 12:31 PM Milton Miller wrote:
Ingo I would propose the following commits added in 2.6.29 be reverted.
I think the current concensus is
On Tue, May 17, 2011 at 02:42:08PM +0300, Avi Kivity wrote:
On 05/17/2011 02:38 PM, Alexander Graf wrote:
What would be the path for these patches to get upstream? Would this
stuff normally go through Avi's tree? There is a bit of a
complication in that they are based on Ben's next
On Wed, 2011-05-18 at 21:11 -0700, Linus Torvalds wrote:
On Wed, May 18, 2011 at 9:06 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
Dunno if it's too late or not yet but here's 3 fixes for powerpc that
would be welcome to have in before the release. If not I'll send them
On May 18, 2011, at 11:06 PM, Benjamin Herrenschmidt wrote:
Hi Linus
Dunno if it's too late or not yet but here's 3 fixes for powerpc that
would be welcome to have in before the release. If not I'll send them
first thing next (one of them is already in -next in fact).
Those are
On May 18, 2011, at 4:48 PM, Benjamin Herrenschmidt wrote:
(I get the feeling that I am the only one testing recent kernels with
the mpc85xx.)
Anyhow, I see that this commit was one of a series. For my own use,
can I simply revert this one commit independently?
For your own use sure
On May 17, 2011, at 4:40 PM, Benjamin Herrenschmidt wrote:
On Tue, 2011-05-17 at 18:28 +0200, Richard Cochran wrote:
Ben,
Recent 2.6.39-rc kernels behave strangely on the Freescale dual core
mpc8572 and p2020. There is a long pause (like 2 seconds) in the boot
sequence after mpic:
On Wed, 2011-05-18 at 21:16 -0700, Roland Dreier wrote:
On Wed, May 18, 2011 at 11:31 AM, Milton Miller milt...@bga.com wrote:
So the real question should be why is x86-32 supplying a broken writeq
instead of letting drivers work out what to do it when needed?
Sounds a lot like what I was
On Thu, 2011-05-19 at 08:46 +0400, James Bottomley wrote:
This can't really be done generically. There are several considerations
to do with hardware requirements. I can see some hw requiring a
specific write order (I think this applies more to read order, though).
Right. Or there can be a
On May 9, 2011, at 4:26 PM, Scott Wood wrote:
Without this, we attempt to use doorbells for IPIs, and end up
branching to some bad address. Plus, even for the exceptions
we don't implement, it's good to handle it and get a message out.
Signed-off-by: Scott Wood scottw...@freescale.com
On May 4, 2011, at 9:29 AM, Geert Uytterhoeven wrote:
It may trigger a warning in fs/proc/generic.c:__xlate_proc_name() when
trying to add an entry for the interrupt handler to sysfs.
Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org
---
arch/powerpc/platforms/86xx/mpc8610_hpcd.c |
On May 9, 2011, at 2:29 PM, Timur Tabi wrote:
If the video mode is set to 16-, 24-, or 32-bit pixels, then the pixel data
contains actual levels of red, blue, and green. However, if the video mode is
set to 8-bit pixels, then the 8-bit value represents an index into color
table.
This is
Eric,
This patch adds save/restore register support for the BlueGene/P
double hummer FPU.
What does this mean? Needs more details here.
Signed-off-by: Eric Van Hensbergen eri...@gmail.com
---
arch/powerpc/include/asm/ppc_asm.h | 39 --
-
59 matches
Mail list logo
