On Thu, 2011-05-19 at 16:57 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2011-05-11 at 00:29 -0500, Milton Miller wrote:
> > Consolidate the mux and demux of ipi messages into smp.c and call
> > a new smp_ops callback to actually trigger the ipi.
>
> .../...
>
> I'm merging the whole series.
On Wed, 2011-05-11 at 00:29 -0500, Milton Miller wrote:
> Consolidate the mux and demux of ipi messages into smp.c and call
> a new smp_ops callback to actually trigger the ipi.
.../...
I'm merging the whole series. I had to do some fixups to this one and
the one adding the CONFIG option, missi
On May 19, 2011, at 1:38 AM, Dipen Dudhat wrote:
> Signed-off-by: Dipen Dudhat
> Acked-By: Scott Wood
> ---
> Based upon
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git (branch
> -> master)
> .../devicetree/bindings/powerpc/fsl/ifc.txt| 76
Signed-off-by: Dipen Dudhat
Acked-By: Scott Wood
---
Based upon git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
(branch -> master)
.../devicetree/bindings/powerpc/fsl/ifc.txt| 76
1 files changed, 76 insertions(+), 0 deletions(-)
create mode
On May 4, 2011, at 8:26 AM, Ramneek Mehresh wrote:
> Add P1020 USB controller default value for "dr_mode" property
>
> Signed-off-by: Ramneek Mehresh
> ---
> Applies on git://git.am.freescale.net/mirrors/linux-2.6.git
> (branch master)
> arch/powerpc/boot/dts/p1020rdb.dts | 10 --
> 1
On Apr 28, 2011, at 2:00 AM, Prabhakar Kushwaha wrote:
> Create the dts files for each core and splits the devices between the two
> cores
> for P1020RDB.
>
> Core0 has core0 to have memory, l2, i2c, spi, gpio, tdm, dma, usb, eth1, eth2,
> sdhc, crypto, global-util, message, pci0, pci1, msi.
>
On Apr 28, 2011, at 1:38 AM, Prabhakar Kushwaha wrote:
> D3-cold state indicates removal of the clock and power. however auxiliary
> (AUX)
> Power may remain available even after the main power rails are powered down.
>
> wakeup from D3-cold state requires full context restore. Other things are
On Apr 27, 2011, at 12:35 AM, Prabhakar Kushwaha wrote:
> FSL PCIe controller can act as agent(EP) or host(RC).
> Under Agent(EP) mode they are configured via Host. So it is not required to
> add
> with the PCI(e) sub-system.
>
> Add and configure PCIe controller only for RC mode.
>
> Signed-o
On Apr 19, 2011, at 11:12 PM, Prabhakar Kushwaha wrote:
> PCIe device in legacy mode can trigger interrupts using the wires #INTA, #INTB
> ,#INTC and #INTD. PCI devices are obligated to use #INTx for interrupts under
> legacy mode. Each PCI slot or device is typically wired to different inputs
On Apr 7, 2011, at 4:10 AM, Prabhakar Kushwaha wrote:
> Creates P1020si.dtsi, containing information for the P1020 SoC. Modifies dts
> files for P1020 based systems to use dtsi file
>
> Signed-off-by: Prabhakar Kushwaha
> Acked-by: Kumar Gala
> ---
> Based upon
> git://git.kernel.org/pub/scm/
On Apr 8, 2011, at 7:27 AM, Prabhakar Kushwaha wrote:
> Creates P2020si.dtsi, containing information for P2020 SoC. Modifies dts files
> for P2020 based systems to use dtsi file.
>
> Signed-off-by: Prabhakar Kushwaha
> ---
> Based upon
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/l
On Apr 19, 2011, at 8:58 AM, Bhaskar Upadhaya wrote:
> From: Bhaskar Upadhaya
>
> Signed-off-by: Bhaskar Upadhaya
> Acked-By: Scott Wood
> ---
> Based upon
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git (branch
> -> master)
>
> .../devicetree/bindings/net/can/fsl-fl
On Tue, May 17, 2011 at 01:36:26PM +0200, Alexander Graf wrote:
>
> Just so I understand the scheme: One vcpu needs to go to MMU mode in
> KVM, it then sends IPIs to stop the other threads and finally we
> return from this wait here?
Actually, if one thread needs to get the other threads out of th
On May 17, 2011, at 6:36 PM, Scott Wood wrote:
> Previously, these macros hardcoded THREAD_EVR0 as the base of the save
> area, relative to the base register passed. This base offset is now
> passed as a separate macro parameter, allowing reuse with other SPE
> save areas, such as used by KVM.
>
On May 17, 2011, at 6:35 PM, Scott Wood wrote:
> From: yu liu
>
> giveup_spe() saves the SPE state which is protected by MSR[SPE].
> However, modifying SPEFSCR does not trap when MSR[SPE]=0.
> And since SPEFSCR is already saved/restored in _switch(),
> not all the callers want to save SPEFSCR a
On May 10, 2011, at 1:02 PM, Scott Wood wrote:
> This debug option has no overhead other than a slight increase in
> kernel size, and makes bug reports more useful. While some end users
> may prefer to save the space, as a default on a kernel config aimed
> primarily at development on reference
On Mar 24, 2011, at 4:43 PM, Scott Wood wrote:
> Add support for MPIC timers as requestable interrupt sources.
>
> Based on http://patchwork.ozlabs.org/patch/20941/ by Dave Liu.
>
> Signed-off-by: Dave Liu
> Signed-off-by: Scott Wood
> ---
> arch/powerpc/include/asm/mpic.h |3 +-
> arch/po
On Mar 24, 2011, at 4:43 PM, Scott Wood wrote:
> Signed-off-by: Scott Wood
> ---
> arch/powerpc/include/asm/mpic.h |2 ++
> arch/powerpc/sysdev/mpic.c | 37 -
> 2 files changed, 38 insertions(+), 1 deletions(-)
applied to next
- k
__
On Mar 24, 2011, at 4:43 PM, Scott Wood wrote:
> There is no hardware interrupt 0xf7. But now we can express the timer
> interrupt using 4-cell interrupts. This requires converting all of the
> other interrupt specifiers in the tree as well.
>
> Also add the second timer group, and fix the reg
On Mar 24, 2011, at 4:43 PM, Scott Wood wrote:
> Update the existing example in the general mpic binding to have a
> separate TCRx region. Currently the example doesn't describe TCRx at
> all. The one upstream device tree with an mpic timer node (p1022ds)
> uses one large reg region to describe
On 19.05.2011, at 07:22, Paul Mackerras wrote:
> 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
On May 10, 2011, at 1:01 PM, Scott Wood wrote:
> Even though support for the p5020's on-chip ethernet is not yet upstream,
> it is not appropriate to disable all networking support (including
> loopback, unix domain sockets, external ethernet devices, etc) in the
> defconfig. The networking sett
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
> ---
> arch/powerpc/include/asm/ppc_asm.h | 39 --
-
> arch/powerpc/kernel/fpu.S
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
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
> ---
> arch/powerpc/platforms/86xx/mpc8610_hpcd.c |2 +-
> 1 file
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
> ---
> arch/powerpc/i
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 Wed, 2011-05-18 at 21:16 -0700, Roland Dreier wrote:
> On Wed, May 18, 2011 at 11:31 AM, Milton Miller 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
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 "mp
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 ow
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 re
On Wed, 2011-05-18 at 21:11 -0700, Linus Torvalds wrote:
> On Wed, May 18, 2011 at 9:06 PM, Benjamin Herrenschmidt
> 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 (
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
On Thu, 2011-05-19 at 13:08 +0900, Hitoshi Mitake wrote:
> On Thu, May 19, 2011 at 04:11, Moore, Eric 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
On Wed, May 18, 2011 at 11:31 AM, Milton Miller 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 :)
http://lkml.org/lkml/2009/4/19/164
But Ing
On Thu, May 19, 2011 at 04:11, Moore, Eric 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 provide their own
From: Linus Torvalds
Date: Wed, 18 May 2011 21:11:47 -0700
> On Wed, May 18, 2011 at 9:06 PM, Benjamin Herrenschmidt
> 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 (
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
On Wed, May 18, 2011 at 9:06 PM, Benjamin Herrenschmidt
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. I just cut 2.6.39.
On Tue, May 17, 2011 at 6:19 AM, Ingo Molnar wrote:
>
> * Steven Rostedt wrote:
>
>> On Tue, 2011-05-17 at 14:42 +0200, Ingo Molnar wrote:
>> > * Steven Rostedt wrote:
>> >
>> > > On Mon, 2011-05-16 at 18:52 +0200, Ingo Molnar wrote:
>> > > > * Steven Rostedt wrote:
>> > > >
>> > > > > I'm a bi
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 regression fixes and a build breakage.
Cheers,
Ben.
The following changes si
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 generi
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 .i
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
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?
On Thu, 19 May 2011 07:54:48 +1000
Benjamin Herrenschmidt wrote:
> On Wed, 2011-05-18 at 16:51 -0500, Scott Wood wrote:
> > On Thu, 19 May 2011 07:37:47 +1000
> > Benjamin Herrenschmidt wrote:
> >
> > > On Wed, 2011-05-18 at 16:05 -0500, Scott Wood wrote:
> > > > A little more speed up measured
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
> trig
On Wed, 2011-05-18 at 16:52 -0500, Scott Wood wrote:
> On Thu, 19 May 2011 07:38:19 +1000
> Benjamin Herrenschmidt wrote:
>
> > On Wed, 2011-05-18 at 16:05 -0500, Scott Wood wrote:
> > > Signed-off-by: Scott Wood
> > > ---
> > > Is there any 64-bit book3e chip that doesn't support this? It
> >
On Wed, 2011-05-18 at 16:51 -0500, Scott Wood wrote:
> On Thu, 19 May 2011 07:37:47 +1000
> Benjamin Herrenschmidt 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 a
On Wed, 2011-05-18 at 16:50 -0500, Scott Wood wrote:
> On Thu, 19 May 2011 07:36:04 +1000
> Benjamin Herrenschmidt 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
On Thu, 19 May 2011 07:38:19 +1000
Benjamin Herrenschmidt wrote:
> On Wed, 2011-05-18 at 16:05 -0500, Scott Wood wrote:
> > Signed-off-by: Scott Wood
> > ---
> > Is there any 64-bit book3e chip that doesn't support this? It
> > doesn't appear to be optional in the ISA.
>
> Not afaik.
Any obje
> > 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 (
On Thu, 19 May 2011 07:37:47 +1000
Benjamin Herrenschmidt 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 now. If your core
On Thu, 19 May 2011 07:36:04 +1000
Benjamin Herrenschmidt 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 TLB0 on an FSL MMU an
> (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 :-) But I'd still like to get to the bottom of
this !
Cheers
On Wed, 2011-05-18 at 12:19 -0500, Milton Miller wrote:
> 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/
Interesting. I'll have a closer look today. Unfortunately, I don't have
any 32-bit BookE
On Thu, 19 May 2011 07:32:41 +1000
Benjamin Herrenschmidt 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, as
> > too-large
On Wed, 2011-05-18 at 16:05 -0500, Scott Wood wrote:
> Signed-off-by: Scott Wood
> ---
> Is there any 64-bit book3e chip that doesn't support this? It
> doesn't appear to be optional in the ISA.
Not afaik.
Cheers,
Ben.
> arch/powerpc/kernel/cputable.c |2 +-
> 1 files changed, 1 insertion
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: Sco
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 re
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 virtu
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 ba
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
This patch adds the necessary core code to enable SMP support on BlueGene/P
Signed-off-by: Eric Van Hensbergen
---
arch/powerpc/kernel/head_44x.S | 72 +
arch/powerpc/mm/fault.c| 77
arch/powerpc/platforms/K
For BGP, it is convenient for 'kmalloc' to come back with 32-byte
aligned units for torus DMA
Signed-off-by: Eric Van Hensbergen
---
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
b/arch/powerpc/inc
BG/P maps firmware with an early TLB
Signed-off-by: Eric Van Hensbergen
---
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 ca1b90c..2807d6e 100644
---
This patch adds save/restore register support for the BlueGene/P
double hummer FPU.
Signed-off-by: Eric Van Hensbergen
---
arch/powerpc/include/asm/ppc_asm.h | 39 ---
arch/powerpc/kernel/fpu.S |8 +++---
arch/powerpc/platforms/44x/Kconfig |9 ++
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
---
arch/powerpc/include/asm/mmu-44x.h |2 ++
arch/powerpc/
Signed-off-by: Eric Van Hensbergen
---
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
--- a/arch/powerpc/kernel/cputable.c
+++ b/arc
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 feedback
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 out
Load it only when needed, in recursive/linear/indirect faults,
and in the stats code.
Signed-off-by: Scott Wood
---
arch/powerpc/include/asm/exception-64e.h | 28 +-
arch/powerpc/mm/tlb_low_64e.S| 43 +
2 files changed, 39 insertions(+)
Signed-off-by: Scott Wood
---
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 b/arch/powerpc/kernel/cpu
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
---
arch/powerpc/mm/tlb_low_64e.S | 21 -
1 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/mm/tlb_low_
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 han
This saves a few cycles, at least on e5500.
Signed-off-by: Scott Wood
---
arch/powerpc/include/asm/exception-64e.h | 16 +++-
arch/powerpc/kernel/paca.c |5 +
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64
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 using PTRS_PER_PGD. The overflow comment seems to
apply to
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.
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).
> > >
> > > O
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
https://lists.ozlabs.org/listinfo/linuxppc
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, 2011-05-18 at 08:23 +0400, James Bottomley wrote:
> > > On Tue, 2
On Wed, May 18, 2011 at 4:02 AM, Prashant Bhole
wrote:
> On Mon, May 2, 2011 at 10:21 AM, Prashant Bhole
> 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. What could be the
>> problem?
>>
>> On u-boot "pci
From: Matthias Klose
Landed in Ubuntu klibc version 1.5.20-1ubuntu3.
Signed-off-by: maximilian attems
---
usr/klibc/arch/ppc64/crt0.S | 17 +
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/usr/klibc/arch/ppc64/crt0.S b/usr/klibc/arch/ppc64/crt0.S
index a7776a
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
> > se
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 c-code.
In the current setup secondary_ti is initialized before th
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 c-code.
In the current setup secondary_ti is initialized before th
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, 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,
> > > > 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 goin
(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 +
> > 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 g
90 matches
Mail list logo
