[PATCH v2 1/6] powerpc/fadump: rename cpu_online_mask member of struct fadump_crash_info_header

As preparation for eliminating the indirect access to the various global cpu_*_bits bitmaps via the pointer variables cpu_*_mask, rename the cpu_online_mask member of struct fadump_crash_info_header to simply online_mask, thus allowing cpu_online_mask to become a macro. Acked-by: Michael Ellerman

[PATCH v2] cxl: Fix number of allocated pages in SPA

This moves the initialisation of the num_procs to before the SPA allocation. The field 'num_procs' of the structure cxl_afu is not updated to the right value (maximum number of processes that can be supported by the AFU) when the pages are allocated (i.e. when cxl_alloc_spa() is called). The

Re: [PATCH v2 11/25] powerpc/8xx: map 16M RAM at startup

On Tue, 2015-10-06 at 16:10 +0200, Christophe Leroy wrote: > Le 29/09/2015 01:58, Scott Wood a écrit : > > On Tue, Sep 22, 2015 at 06:50:50PM +0200, Christophe Leroy wrote: > > > On recent kernels, with some debug options like for instance > > > CONFIG_LOCKDEP, the BSS requires more than 8M

[PATCH v2 0/6] kernel/cpu.c: eliminate some indirection

v2: fix build failure on ppc, add acks. The four cpumasks cpu_{possible,online,present,active}_bits are exposed readonly via the corresponding const variables cpu_xyz_mask. But they are also accessible for arbitrary writing via the exposed functions set_cpu_xyz. There's quite a bit of code

Re: [PATCH v2 07/25] powerpc32: refactor x_mapped_by_bats() and x_mapped_by_tlbcam() together

On Tue, 2015-10-06 at 16:02 +0200, Christophe Leroy wrote: > Le 29/09/2015 01:47, Scott Wood a écrit : > > On Tue, Sep 22, 2015 at 06:50:42PM +0200, Christophe Leroy wrote: > > > x_mapped_by_bats() and x_mapped_by_tlbcam() serve the same kind of > > > purpose, so lets group them into a single

[PATCH] cxl: Fix number of allocated pages in SPA

From: Christophe Lombard The scheduled process area is currently allocated before assigning the correct maximum processes to the AFU, which will mean we only ever allocate a fixed number of pages for the scheduled process area. This will limit us to 958 processes

[PATCH 1/5] powerpc/eeh: Don't unfreeze PHB PE after reset

On PowerNV platform, the PE is kept in frozen state until the PE reset is completed to avoid recursive EEH error caused by MMIO access during the period of EEH reset. The PE's frozen state is cleared after BARs of PCI device included in the PE are restored and enabled. However, we needn't clear

[PATCH 3/5] powerpc/eeh: Force reset on fenced PHB

On fenced PHB, the error handlers in the drivers of its subordinate devices could return PCI_ERS_RESULT_CAN_RECOVER, indicating no reset will be issued during the recovery. It's conflicting with the fact that fenced PHB won't be recovered without reset. This limits the return value from the error

[PATCH 5/5] powerpc/pseries: Cleanup on pseries_eeh_get_state()

This cleans up pseries_eeh_get_state(), no functional changes: * Return EEH_STATE_NOT_SUPPORT early when the 2nd RTAS output argument is zero to avoid nested if statements. * Skip clearing bits in the PE state represented by variable "result" to simplify the code. Signed-off-by:

[PATCH 4/5] powerpc/eeh: More relxed condition for enabled IO path

When one of below two flags or both of them are marked in the PE state, the PE's IO path is regarded as enabled: EEH_STATE_MMIO_ACTIVE or EEH_STATE_MMIO_ENABLED. Signed-off-by: Gavin Shan --- arch/powerpc/kernel/eeh.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 2/5] powerpc/eeh: More relexed hotplug criterion

Currently, we rely on the existence of struct pci_driver::err_handler to judge if the corresponding PCI device should be unplugged during EEH recovery (partially hotplug case). However, it's not elaborate. some device drivers are implementing part of the EEH error handlers to collect diag-data.

Re: [PATCH] cxl: Fix number of allocated pages in SPA

Excerpts from Michael Ellerman's message of 2015-10-06 17:19:02 +1100: > On Fri, 2015-10-02 at 16:01 +0200, Christophe Lombard wrote: > > This moves the initialisation of the num_procs to before the SPA > > allocation. > > Why? What does it fix? I can't tell from the diff or the change log. This

[PATCH v2 01/18] powerpc/fsl-booke-64: Allow booting from the secondary thread

This allows SMP kernels to work as kdump crash kernels. While crash kernels don't really need to be SMP, this prevents things from breaking if a user does it anyway (which is not something you want to only find out once the main kernel has crashed in the field, especially if whether it works or

[PATCH v2 00/18] powerpc/fsl-book3e-64: kexec/kdump support

This patchset adds support for kexec and kdump to e5500 and e6500 based systems running 64-bit kernels. It depends on the kexec-tools patch http://patchwork.ozlabs.org/patch/527050/ ("ppc64: Add a flag to tell the kernel it's booting from kexec"). Scott Wood (12): powerpc/fsl-booke-64: Allow

[PATCH v2 04/18] powerpc/fsl_pci: Don't set up inbound windows in kdump crash kernel

Otherwise, because the top end of the crash kernel is treated as the absolute top of memory rather than the beginning of a reserved region, in-flight DMA from the previous kernel that targets areas above the crash kernel can trigger a storm of PCI errors. We only do this for kdump, not normal

[PATCH v2 02/18] powerpc/fsl-corenet: Disable coreint if kexec is enabled

Problems have been observed in coreint (EPR) mode if interrupts are left pending (due to the lack of device quiescence with kdump) after having tried to deliver to a CPU but unable to deliver due to MSR[EE] -- interrupts no longer get reliably delivered in the new kernel. I tried various ways of

[PATCH v2 03/18] powerpc/85xx: Don't use generic timebase sync on 64-bit

85xx currently uses the generic timebase sync mechanism when CONFIG_KEXEC is enabled, because 32-bit 85xx kexec support does a hard reset of each core. 64-bit 85xx kexec does not do this, so we neither need nor want this (nor is the generic timebase sync code built on ppc64). FWIW, I don't like

[PATCH v2 06/18] powerpc/fsl-booke-64: Don't limit ppc64_rma_size to one TLB entry

This is required for kdump to work when loaded at at an address that does not fall within the first TLB entry -- which can easily happen because while the lower limit is enforced via reserved memory, which doesn't affect how much is mapped, the upper limit is enforced via a different mechanism

[PATCH v2 05/18] powerpc/85xx: Load all early TLB entries at once

Use an AS=1 trampoline TLB entry to allow all normal TLB1 entries to be loaded at once. This avoids the need to keep the translation that code is executing from in the same TLB entry in the final TLB configuration as during early boot, which in turn is helpful for relocatable kernels (e.g. kdump)

[PATCH v2 09/18] powerpc/book3e-64: rename interrupt_end_book3e with __end_interrupts

From: Tiejun Chen Rename 'interrupt_end_book3e' to '__end_interrupts' so that the symbol can be used by both book3s and book3e. Signed-off-by: Tiejun Chen [scottwood: edit changelog] Signed-off-by: Scott Wood ---

[PATCH v2 08/18] powerpc/e6500: kexec: Handle hardware threads

The new kernel will be expecting secondary threads to be disabled, not spinning. Signed-off-by: Scott Wood --- v2: minor cleanup arch/powerpc/kernel/head_64.S | 16 ++ arch/powerpc/platforms/85xx/smp.c | 46 +++ 2

[PATCH v2 07/18] powerpc/85xx: Implement 64-bit kexec support

From: Tiejun Chen Unlike 32-bit 85xx kexec, we don't do a core reset. Signed-off-by: Tiejun Chen [scottwood: edit changelog, and cleanup] Signed-off-by: Scott Wood --- arch/powerpc/platforms/85xx/smp.c | 11

[PATCH v2 10/18] powerpc/booke64: Fix args to copy_and_flush

From: Tiejun Chen Convert r4/r5, not r6, to a virtual address when calling copy_and_flush. Otherwise, r3 is already virtual, and copy_to_flush tries to access r3+r6, PAGE_OFFSET gets added twice. This isn't normally seen because on book3e we normally enter with the

[PATCH v2 11/18] powerpc/book3e: support CONFIG_RELOCATABLE

From: Tiejun Chen book3e is different with book3s since 3s includes the exception vectors code in head_64.S as it relies on absolute addressing which is only possible within this compilation unit. So we have to get that label address with got. And when boot a

[PATCH v2 12/18] powerpc/book3e/kdump: Enable crash_kexec_wait_realmode

While book3e doesn't have "real mode", we still want to wait for all the non-crash cpus to complete their shutdown. Signed-off-by: Scott Wood --- arch/powerpc/kernel/crash.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git

[PATCH v2 14/18] powerpc/book3e-64/kexec: create an identity TLB mapping

From: Tiejun Chen book3e has no real MMU mode so we have to create an identity TLB mapping to make sure we can access the real physical address. Signed-off-by: Tiejun Chen [scottwood: cleanup, and split off some changes] Signed-off-by:

[PATCH v2 13/18] powerpc/book3e-64: Don't limit paca to 256 MiB

This limit only makes sense on book3s, and on book3e it can cause problems with kdump if we don't have any memory under 256 MiB. Signed-off-by: Scott Wood --- arch/powerpc/kernel/paca.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git

[PATCH v2 15/18] powerpc/book3e-64/kexec: Enable SMP release

The SMP release mechanism for FSL book3e is different from when booting with normal hardware. In theory we could simulate the normal spin table mechanism, but not at the addresses U-Boot put in the device tree -- so there'd need to be even more communication between the kernel and kexec to set

[PATCH v2 16/18] powerpc/booke: Only use VIRT_PHYS_OFFSET on booke32

The way VIRT_PHYS_OFFSET is not correct on book3e-64, because it does not account for CONFIG_RELOCATABLE other than via the 32-bit-only virt_phys_offset. book3e-64 can (and if the comment about a GCC miscompilation is still relevant, should) use the normal ppc64 __va/__pa. At this point, only

[PATCH v2 17/18] powerpc/book3e-64/kexec: Set "r4 = 0" when entering spinloop

book3e_secondary_core_init will only create a TLB entry if r4 = 0, so do so. Signed-off-by: Scott Wood --- arch/powerpc/kernel/misc_64.S | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S index

Re: [PATCH v2] cxl: Fix number of allocated pages in SPA

The explanation probably still needs to be expanded more (e.g. this could cause a crash for an AFU that supports more than about a thousand processes) - see my other email in reply to v1 for more, but I'm happy for this to go in as is (but ultimately that's mpe's call). It should also be CCd to

[PATCH v2 18/18] powerpc/book3e-64: Enable kexec

From: Tiejun Chen Allow KEXEC for book3e, and bypass or convert non-book3e stuff in kexec code. Signed-off-by: Tiejun Chen [scottw...@freescale.com: move code to minimize diff, and cleanup] Signed-off-by: Scott Wood

Re: [PATCH v2] cxl: Fix number of allocated pages in SPA

On Wed, 2015-10-07 at 14:51 +1100, Ian Munsie wrote: > The explanation probably still needs to be expanded more (e.g. this > could cause a crash for an AFU that supports more than about a thousand > processes) - see my other email in reply to v1 for more, but I'm happy > for this to go in as is

Re: Missing operand for tlbie instruction on Power7

On 10/05/2015 08:35 PM, Michael Ellerman wrote: On Fri, 2015-10-02 at 08:43 -0700, Laura Abbott wrote: Hi, We received a report (https://bugzilla.redhat.com/show_bug.cgi?id=1267395) of bad assembly when compiling on powerpc with little endian ... After some discussion with the binutils

Re: [PATCH] cxl: Fix number of allocated pages in SPA

On Fri, 2015-10-02 at 16:01 +0200, Christophe Lombard wrote: > This moves the initialisation of the num_procs to before the SPA > allocation. Why? What does it fix? I can't tell from the diff or the change log. cheers ___ Linuxppc-dev mailing list

Re: [PATCH 4/5] kernel/cpu.c: eliminate cpu_*_mask

On Tue, 2015-10-06 at 01:10 +0200, Rasmus Villemoes wrote: > Hi PPC maintainers > > Can I get you to ack or nak this? It's a prerequisite for a minor > patch series for kernel/cpu.c and include/linux/cpumask.h of mine. Yeah fine by me. Acked-by: Michael Ellerman cheers >

Who uses CROSS32_COMPILE ?

Does anyone build their kernels using CROSS32_COMPILE ? cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v2 01/25] powerpc/8xx: Save r3 all the time in DTLB miss handler

Le 06/10/2015 18:46, Scott Wood a écrit : On Tue, 2015-10-06 at 15:35 +0200, Christophe Leroy wrote: Le 29/09/2015 00:07, Scott Wood a écrit : On Tue, Sep 22, 2015 at 06:50:29PM +0200, Christophe Leroy wrote: We are spending between 40 and 160 cycles with a mean of 65 cycles in the TLB

[PATCH-RFC 3/7] powerpc: convert to generic builtin command line

This updates the powerpc code to use the CONFIG_GENERIC_CMDLINE option. Cc: xe-ker...@external.cisco.com Cc: Daniel Walker Signed-off-by: Daniel Walker --- arch/powerpc/Kconfig| 23 +-- arch/powerpc/kernel/prom.c | 4

Re: [PATCH v2 01/25] powerpc/8xx: Save r3 all the time in DTLB miss handler

On Tue, 2015-10-06 at 22:30 +0200, christophe leroy wrote: > Le 06/10/2015 18:46, Scott Wood a écrit : > > On Tue, 2015-10-06 at 15:35 +0200, Christophe Leroy wrote: > > > Le 29/09/2015 00:07, Scott Wood a écrit : > > > > On Tue, Sep 22, 2015 at 06:50:29PM +0200, Christophe Leroy wrote: > > > > >

[PATCH v9 1/4] perf, kvm/{x86, s390}: Remove dependency on uapi/kvm_perf.h

Its better to remove the dependency on uapi/kvm_perf.h to allow dynamic discovery of kvm events (if its needed). To do this, some extern variables have been introduced with which we can keep the generic functions generic. Signed-off-by: Hemant Kumar --- Changelog: v8

[PATCH v9 3/4] perf,kvm/powerpc: Port perf kvm stat to powerpc

perf kvm can be used to analyze guest exit reasons. This support already exists in x86. Hence, porting it to powerpc. - To trace KVM events : perf kvm stat record If many guests are running, we can track for a specific guest by using --pid as in : perf kvm stat record --pid - To see the

[PATCH v9 2/4] perf,kvm/{x86,s390}: Remove const from kvm_events_tp

This patch removes the "const" qualifier from kvm_events_tp declaration to account for the fact that some architectures may need to update this variable dynamically. For instance, powerpc will need to update this variable dynamically depending on the machine type. Signed-off-by: Hemant Kumar

[PATCH v9 4/4] perf,kvm/powerpc: Add support for HCALL reasons

Powerpc provides hcall events that also provides insights into guest behaviour. Enhance perf kvm stat to record and analyze hcall events. - To trace hcall events : perf kvm stat record - To show the results : perf kvm stat report --event=hcall The result shows the number of hypervisor

Re: [PATCH V4 0/6] Redesign SR-IOV on PowerNV

On Fri, 2015-10-02 at 20:07 +1000, Alexey Kardashevskiy wrote: > On 08/19/2015 12:01 PM, Wei Yang wrote: > > In original design, it tries to group VFs to enable more number of VFs in > > the > > system, when VF BAR is bigger than 64MB. This design has a flaw in which one > > error on a VF will

Re: [PATCH v2] perf: Fix build break on powerpc due to sample_reg_masks

On Wed, 2015-09-30 at 16:45 -0300, Arnaldo Carvalho de Melo wrote: > Em Wed, Sep 30, 2015 at 09:09:09PM +0200, Jiri Olsa escreveu: > > On Wed, Sep 30, 2015 at 11:28:36AM -0700, Sukadev Bhattiprolu wrote: > > > From e29a7236122c4d807ec9ebc721b5d7d75c8d Mon Sep 17 00:00:00 2001 > > > From:

Re: Who uses CROSS32_COMPILE ?

On 10/6/15, Michael Ellerman wrote: > Does anyone build their kernels using CROSS32_COMPILE ? I didn't even know that such macro exists.. > > cheers > > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org >

Re: [PATCH] cxl: Fix number of allocated pages in SPA

The field 'num_procs' of the structure cxl_afu is not updated to the right value (maximum number of processes that can be supported by the AFU) when the pages are allocated (i.e. when cxl_alloc_spa() is called). The number of allocates pages depends on the max number of processes. Thanks On

Re: powerpc: Fix _ALIGN_* errors due to type difference.

On Fri, 2015-02-10 at 14:33:48 UTC, "Aneesh Kumar K.V" wrote: > This avoid errors like > > unsigned int usize = 1 << 30; > int size = 1 << 30; > unsigned long addr = 64UL << 30 ; > > value = _ALIGN_DOWN(addr, usize); -> 0 > value = _ALIGN_DOWN(addr, size);

Re: [PATCH 1/5 v2] dma-mapping: add generic dma_get_page_shift API

Do we need a function here or can we just have a IOMMU_PAGE_SHIFT define with an #ifndef in common code? Also not all architectures use dma-mapping-common.h yet, so you either need to update all of those as well, or just add the #ifndef directly to linux/dma-mapping.h.

Re: [RFC, 1/5] powerpc:numa Add numa_cpu_lookup function to update lookup table

On Sun, 2015-27-09 at 18:29:09 UTC, Raghavendra K T wrote: > We access numa_cpu_lookup_table array directly in all the places > to read/update numa cpu lookup information. Instead use a helper > function to update. > > This is helpful in changing the way numa<-->cpu mapping in single > place when

[PATCH v2 1/3] ppc64: Fix warnings

Produce a warning-free build on ppc64 (at least, when built as 64-bit userspace -- if a 64-bit binary for ppc64 is a requirement, why is -m64 set only on purgatory?). Mostly unused (or write-only) variable warnings, but also one nasty one where reserve() was used without a prototype, causing long

[PATCH v2 2/3] ppc64: Avoid rfid if no need to clear MSR_LE

Commit a304e2d82a8c3 ("ppc64: purgatory: Reset primary cpu endian to big-endian) changed bctr to rfid. rfid is book3s-only and will cause a fatal exception on book3e. Purgatory is an isolated environment which makes importing information about the subarch awkward, so instead rely on the fact

[PATCH v2 3/3] ppc64: Add a flag to tell the kernel it's booting from kexec

It needs to know this because the SMP release mechanism for Freescale book3e is different from when booting with normal hardware. In theory we could simulate the normal spin table mechanism, but not (easily) at the addresses U-Boot put in the device tree -- so there'd need to be even more

Re: [kexec-lite PATCH V2] trampoline: Reset primary cpu endian to big-endian

On Wed, 2015-07-08 at 13:49 +1000, Samuel Mendoza-Jonas wrote: > On 08/07/15 13:37, Scott Wood wrote: > > On Wed, 2015-07-08 at 13:29 +1000, Samuel Mendoza-Jonas wrote: > > > Older big-endian ppc64 kernels don't include the FIXUP_ENDIAN check, > > > meaning if we kexec from a little-endian kernel

Re: [PATCH RFC 0/5] powerpc:numa Add serial nid support

On Sun, 2015-09-27 at 23:59 +0530, Raghavendra K T wrote: > Problem description: > Powerpc has sparse node numbering, i.e. on a 4 node system nodes are > numbered (possibly) as 0,1,16,17. At a lower level, we map the chipid > got from device tree is naturally mapped (directly) to nid. > >

Re: [RFC, 1/5] powerpc:numa Add numa_cpu_lookup function to update lookup table

On 10/06/2015 03:47 PM, Michael Ellerman wrote: On Sun, 2015-27-09 at 18:29:09 UTC, Raghavendra K T wrote: We access numa_cpu_lookup_table array directly in all the places to read/update numa cpu lookup information. Instead use a helper function to update. This is helpful in changing the way

Re: [PATCH] powerpc: Kconfig.cputype: Disallow TUNE_CELL on LE systems

On 06/10/15 12:05, Michael Ellerman wrote: > On Mon, 2015-09-21 at 12:07 +0200, Thomas Huth wrote: >> On 21/09/15 09:18, Michael Ellerman wrote: >>> On Fri, 2015-09-18 at 16:17 +0200, Thomas Huth wrote: It looks somewhat weird that you can enable TUNE_CELL on little endian systems, so

Re: [v2,1/2] powerpc/xmon: Paged output for paca display

On Fri, 2015-21-08 at 04:24:27 UTC, Sam bobroff wrote: > The paca display is already more than 24 lines, which can be problematic > if you have an old school 80x24 terminal, or more likely you are on a > virtual terminal which does not scroll for whatever reason. > > This patch adds a new command

Re: [PATCH v2 13/25] powerpc/8xx: also use r3 in the ITLB miss in all situations

Le 29/09/2015 02:00, Scott Wood a écrit : On Tue, Sep 22, 2015 at 06:50:54PM +0200, Christophe Leroy wrote: We are spending between 40 and 160 cycles with a mean of 65 cycles in the TLB handling routines (measured with mftbl) so make it more simple althought it adds one instruction

Re: [PATCH RFC 0/5] powerpc:numa Add serial nid support

On 10/06/2015 03:55 PM, Michael Ellerman wrote: On Sun, 2015-09-27 at 23:59 +0530, Raghavendra K T wrote: Problem description: Powerpc has sparse node numbering, i.e. on a 4 node system nodes are numbered (possibly) as 0,1,16,17. At a lower level, we map the chipid got from device tree is

Re: [PATCH v2 06/25] powerpc32: iounmap() cannot vunmap() area mapped by TLBCAMs either

Le 29/09/2015 01:41, Scott Wood a écrit : On Tue, Sep 22, 2015 at 06:50:40PM +0200, Christophe Leroy wrote: iounmap() cannot vunmap() area mapped by TLBCAMs either Signed-off-by: Christophe Leroy --- No change in v2 arch/powerpc/mm/pgtable_32.c | 4 +++- 1 file

Re: Who uses CROSS32_COMPILE ?

On Tue, 2015-10-06 at 12:40 +0300, Denis Kirjanov wrote: > On 10/6/15, Michael Ellerman wrote: > > Does anyone build their kernels using CROSS32_COMPILE ? > > I didn't even know that such macro exists.. Good, I want to remove it :) cheers

Re: [PATCH v2 07/25] powerpc32: refactor x_mapped_by_bats() and x_mapped_by_tlbcam() together

Le 29/09/2015 01:47, Scott Wood a écrit : On Tue, Sep 22, 2015 at 06:50:42PM +0200, Christophe Leroy wrote: x_mapped_by_bats() and x_mapped_by_tlbcam() serve the same kind of purpose, so lets group them into a single function. Signed-off-by: Christophe Leroy --- No

Re: [PATCH v2 01/25] powerpc/8xx: Save r3 all the time in DTLB miss handler

Le 29/09/2015 00:07, Scott Wood a écrit : On Tue, Sep 22, 2015 at 06:50:29PM +0200, Christophe Leroy wrote: We are spending between 40 and 160 cycles with a mean of 65 cycles in the TLB handling routines (measured with mftbl) so make it more simple althought it adds one instruction.

Re: [PATCH v2 13/25] powerpc/8xx: also use r3 in the ITLB miss in all situations

On Tue, 2015-10-06 at 16:12 +0200, Christophe Leroy wrote: > Le 29/09/2015 02:00, Scott Wood a écrit : > > On Tue, Sep 22, 2015 at 06:50:54PM +0200, Christophe Leroy wrote: > > > We are spending between 40 and 160 cycles with a mean of 65 cycles > > > in the TLB handling routines (measured with

Re: [PATCH v2 15/25] powerpc/8xx: move 8xx SPRN defines into reg_8xx.h and add some missing ones

On Tue, 2015-10-06 at 16:35 +0200, Christophe Leroy wrote: > Le 29/09/2015 02:03, Scott Wood a écrit : > > On Tue, Sep 22, 2015 at 06:50:58PM +0200, Christophe Leroy wrote: > > > Move 8xx SPRN defines into reg_8xx.h and add some missing ones > > > > > > Signed-off-by: Christophe Leroy

Re: [PATCH v2 01/25] powerpc/8xx: Save r3 all the time in DTLB miss handler

On Tue, 2015-10-06 at 15:35 +0200, Christophe Leroy wrote: > Le 29/09/2015 00:07, Scott Wood a écrit : > > On Tue, Sep 22, 2015 at 06:50:29PM +0200, Christophe Leroy wrote: > > > We are spending between 40 and 160 cycles with a mean of 65 cycles in > > > the TLB handling routines (measured with

Re: [PATCH v2 01/25] powerpc/8xx: Save r3 all the time in DTLB miss handler

On Tue, 2015-10-06 at 15:35 +0200, Christophe Leroy wrote: > Le 29/09/2015 00:07, Scott Wood a écrit : > > On Tue, Sep 22, 2015 at 06:50:29PM +0200, Christophe Leroy wrote: > > > We are spending between 40 and 160 cycles with a mean of 65 cycles in > > > the TLB handling routines (measured with

Re: [PATCH v2 15/25] powerpc/8xx: move 8xx SPRN defines into reg_8xx.h and add some missing ones

Le 29/09/2015 02:03, Scott Wood a écrit : On Tue, Sep 22, 2015 at 06:50:58PM +0200, Christophe Leroy wrote: Move 8xx SPRN defines into reg_8xx.h and add some missing ones Signed-off-by: Christophe Leroy --- No change in v2 Why are they being moved? Why are they

Re: [PATCH v2 11/25] powerpc/8xx: map 16M RAM at startup

Le 29/09/2015 01:58, Scott Wood a écrit : On Tue, Sep 22, 2015 at 06:50:50PM +0200, Christophe Leroy wrote: On recent kernels, with some debug options like for instance CONFIG_LOCKDEP, the BSS requires more than 8M memory, allthough the kernel code fits in the first 8M. Today, it is necessary