From: "Aneesh Kumar K.V"
We moved the definition of shift_to_mmu_psize and mmu_psize_to_shift
out of hugetlbpage.c in patch "powerpc: New hugepage directory format".
These functions are not related to hugetlbpage and we want to use them
outside hugetlbpage.c We missed a definition for book3e whe
From: Michael Ellerman
This context switches the new Event Based Branching (EBB) SPRs. The three new
SPRs are:
- Event Based Branch Handler Register (EBBHR)
- Event Based Branch Return Register (EBBRR)
- Branch Event Status and Control Register (BESCR)
Signed-off-by: Michael Ellerman
Sig
This turns Event Based Branching (EBB) on in the Hypervisor Facility Status and
Control Register (HFSCR) and Facility Status and Control Register (FSCR).
Signed-off-by: Michael Neuling
---
arch/powerpc/include/asm/reg.h|2 ++
arch/powerpc/kernel/cpu_setup_power.S |4 ++--
2 files
From: Michael Ellerman
We are getting low on cpu feature bits. So rather than add a separate bit for
every new Power8 feature, add a bit for arch 2.07 server catagory and use that
instead.
Hijack the value we had for BCTAR, but swap the value with CFAR so that all the
ARCH defines are together.
Event Based Branching (EBB) is a new POWER8 feature to take asynchronous
userspace interrupt based on events. Currently on POWER8 these events can be
PMU overflows.
This patch series context switches the three new EBB SPRs which are:
- Event Based Branch Handler Register (EBBHR)
- Event Based Bra
On Tue, Apr 30, 2013 at 10:51:00PM +0530, Aneesh Kumar K.V wrote:
> David Gibson writes:
>
> > On Mon, Apr 29, 2013 at 01:07:39AM +0530, Aneesh Kumar K.V wrote:
> >> From: "Aneesh Kumar K.V"
> >>
> >> Encode the actual page correctly in tlbie/tlbiel. This make sure we handle
> >> multiple page
On Wed, May 01, 2013 at 10:31:33AM +0530, Vasant Hegde wrote:
> On 05/01/2013 07:36 AM, Stephen Rothwell wrote:
> >Hi Al,
> >
> >Today's linux-next merge of the vfs tree got a conflict in
> >arch/powerpc/kernel/rtas_flash.c between commit fb4696c39573
> >("powerpc/rtas_flash: Fix bad memory access"
On Wed, 2013-05-01 at 13:24 +0930, Alan Modra wrote:
> On Tue, Apr 30, 2013 at 07:24:20PM -0700, Eric Dumazet wrote:
> > li 11,1
> > ld 0,0(9)
> > rldimi 0,11,31,32
> > std 0,0(9)
> > blr
> > .ident "GCC: (GNU) 4.6.3"
> >
> > You can see "ld 0,0(9)" is used : its a 64 bit
On 05/01/2013 07:36 AM, Stephen Rothwell wrote:
Hi Al,
Today's linux-next merge of the vfs tree got a conflict in
arch/powerpc/kernel/rtas_flash.c between commit fb4696c39573
("powerpc/rtas_flash: Fix bad memory access") from the powerpc tree and
commits ad18a364f186 ("powerpc/rtas_flash: Free k
On Tue, Apr 30, 2013 at 07:24:20PM -0700, Eric Dumazet wrote:
> li 11,1
> ld 0,0(9)
> rldimi 0,11,31,32
> std 0,0(9)
> blr
> .ident "GCC: (GNU) 4.6.3"
>
> You can see "ld 0,0(9)" is used : its a 64 bit load.
Yup. This is not a powerpc64 specific problem. See
On Wed, 2013-05-01 at 11:51 +1000, Anton Blanchard wrote:
> Hi Eric,
>
> > From: Eric Dumazet
> >
> > Using bit fields is dangerous on ppc64, as the compiler uses 64bit
> > instructions to manipulate them. If the 64bit word includes any
> > atomic_t or spinlock_t, we can lose critical concurrent
Scott --
On 04/30/2013 06:42 PM, Scott Wood wrote:
I just meant that, for whatever boards you would have put this in the
device tree, put it in platform code instead (if the platform file
supports more than one board type, then check the compatible at the
top of the device tree).
I think I
Hi Al,
Today's linux-next merge of the vfs tree got a conflict in
arch/powerpc/kernel/rtas_flash.c between commit fb4696c39573
("powerpc/rtas_flash: Fix bad memory access") from the powerpc tree and
commits ad18a364f186 ("powerpc/rtas_flash: Free kmem upon module exit")
and 2352ad01409d ("ppc: Cle
Hi Eric,
> From: Eric Dumazet
>
> Using bit fields is dangerous on ppc64, as the compiler uses 64bit
> instructions to manipulate them. If the 64bit word includes any
> atomic_t or spinlock_t, we can lose critical concurrent changes.
>
> This is happening in af_unix, where unix_sk(sk)->gc_candi
On Tue, 2013-04-30 at 18:12 -0700, Eric Dumazet wrote:
> From: Eric Dumazet
>
> Using bit fields is dangerous on ppc64, as the compiler uses 64bit
> instructions to manipulate them. If the 64bit word includes any
> atomic_t or spinlock_t, we can lose critical concurrent changes.
>
> This is happ
From: Eric Dumazet
Using bit fields is dangerous on ppc64, as the compiler uses 64bit
instructions to manipulate them. If the 64bit word includes any
atomic_t or spinlock_t, we can lose critical concurrent changes.
This is happening in af_unix, where unix_sk(sk)->gc_candidate/
gc_maybe_cycle/loc
On 04/30/2013 07:34:39 PM, Anthony Foiani wrote:
Scott --
Thanks for the quick reply / review!
On 04/30/2013 12:15 PM, Scott Wood wrote:
[The devtree approach] might be OK for a new board, but adding it
now means that people using existing device trees won't get the
workaround. It might be
Scott --
Thanks for the quick reply / review!
On 04/30/2013 12:15 PM, Scott Wood wrote:
[The devtree approach] might be OK for a new board, but adding it now
means that people using existing device trees won't get the
workaround. It might be better to just put the knowledge in platform
code.
On 04/30/2013 02:41 AM, Anthony Foiani wrote:
Apologies for resurrecting a very old thread, but...
On 05/30/2012 02:14 PM, Anthony Foiani wrote:
Maybe someone who knows devtree really well could crank that out in a
few minutes... but I'm not that person. :)
Well, I wasn't last year, but this
Rework to implement RapidIO enumeration/discovery method selection
combined with ability to use enumeration/discovery as a kernel module.
This patch adds ability to introduce new RapidIO enumeration/discovery methods
using kernel configuration options. Configuration option mechanism allows to
sel
Add RapidIO enumeration/discovery start from user space.
User space start allows to defer RapidIO fabric scan until the moment when all
participating endpoints are initialized avoiding mandatory synchronized start
of all endpoints (which may be challenging in systems with large number of
RapidIO en
Update RapidIO documentation to reflect changes made to enumeration/discovery
build configuration and user space triggering mechanism.
Signed-off-by: Alexandre Bounine
Cc: Matt Porter
Cc: Li Yang
Cc: Kumar Gala
Cc: Andre van Herk
Cc: Micha Nelissen
---
Documentation/rapidio/rapidio.txt | 1
Systems that use RapidIO fabric may need to implement their own enumeration
and discovery methods which are better suitable for needs of a target
application.
The following set of patches is intended to simplify process of introduction of
new RapidIO fabric enumeration/discovery methods.
The firs
Hi,
i was reading trough arch/powerpc/kernel/misc32.S looking at the icbi and
iccci instructions, from whats on print in
http://s.eeweb.com/members/kvks_kumar/answers/1356585717-PPC440_UM2013.pdf(page
272) iccci should be used once in the power-on / reset routine, and
as far as flush_icache_range
On 04/30/2013 01:41:49 AM, Anthony Foiani wrote:
Apologies for resurrecting a very old thread, but...
On 05/30/2012 02:14 PM, Anthony Foiani wrote:
Maybe someone who knows devtree really well could crank that out in a
few minutes... but I'm not that person. :)
Well, I wasn't last year, but th
David Gibson writes:
> On Mon, Apr 29, 2013 at 01:07:39AM +0530, Aneesh Kumar K.V wrote:
>> From: "Aneesh Kumar K.V"
>>
>> Encode the actual page correctly in tlbie/tlbiel. This make sure we handle
>> multiple page size segment correctly.
>
> As mentioned in previous comments, this commit messa
Hi Joerg,
Would you take this patchset for 3.10 merge?
Regards
Varun
> -Original Message-
> From: Sethi Varun-B16395
> Sent: Wednesday, April 24, 2013 5:06 PM
> To: j...@8bytes.org; io...@lists.linux-foundation.org; linuxppc-
> d...@lists.ozlabs.org; linux-ker...@vger.kernel.org;
> ga...@
We do not want to take single step and branch-taken debug exception
in kernel exception code. But the address range check was not covering
all kernel exception handlers address range.
With this patch we defined the interrupt_end label which defines the
end on kernel exception code. So now we check
28 matches
Mail list logo