* [PATCH 01/15] powerpc/a2: Add some #defines for A2 specific instructions
From: Michael Ellerman @ 2011-04-15 8:31 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jimi Xenidis, jack, imunsie, David Gibson
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/include/asm/ppc-opcode.h | 25 +++++++++++++++++++++++++
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h
index 384a96d..3e25b25 100644
--- a/arch/powerpc/include/asm/ppc-opcode.h
+++ b/arch/powerpc/include/asm/ppc-opcode.h
@@ -59,6 +59,14 @@
#define PPC_INST_NAP 0x4c000364
#define PPC_INST_SLEEP 0x4c0003a4
+/* A2 specific instructions */
+#define PPC_INST_ERATWE 0x7c0001a6
+#define PPC_INST_ERATRE 0x7c000166
+#define PPC_INST_ERATILX 0x7c000066
+#define PPC_INST_ERATIVAX 0x7c000666
+#define PPC_INST_ERATSX 0x7c000126
+#define PPC_INST_ERATSX_DOT 0x7c000127
+
/* macros to insert fields into opcodes */
#define __PPC_RA(a) (((a) & 0x1f) << 16)
#define __PPC_RB(b) (((b) & 0x1f) << 11)
@@ -70,6 +78,8 @@
#define __PPC_XT(s) __PPC_XS(s)
#define __PPC_T_TLB(t) (((t) & 0x3) << 21)
#define __PPC_WC(w) (((w) & 0x3) << 21)
+#define __PPC_WS(w) (((w) & 0x1f) << 11)
+
/*
* Only use the larx hint bit on 64bit CPUs. e500v1/v2 based CPUs will treat a
* larx with EH set as an illegal instruction.
@@ -116,6 +126,21 @@
#define PPC_TLBIVAX(a,b) stringify_in_c(.long PPC_INST_TLBIVAX | \
__PPC_RA(a) | __PPC_RB(b))
+#define PPC_ERATWE(s, a, w) stringify_in_c(.long PPC_INST_ERATWE | \
+ __PPC_RS(s) | __PPC_RA(a) | __PPC_WS(w))
+#define PPC_ERATRE(s, a, w) stringify_in_c(.long PPC_INST_ERATRE | \
+ __PPC_RS(s) | __PPC_RA(a) | __PPC_WS(w))
+#define PPC_ERATILX(t, a, b) stringify_in_c(.long PPC_INST_ERATILX | \
+ __PPC_T_TLB(t) | __PPC_RA(a) | \
+ __PPC_RB(b))
+#define PPC_ERATIVAX(s, a, b) stringify_in_c(.long PPC_INST_ERATIVAX | \
+ __PPC_RS(s) | __PPC_RA(a) | __PPC_RB(b))
+#define PPC_ERATSX(t, a, w) stringify_in_c(.long PPC_INST_ERATSX | \
+ __PPC_RS(t) | __PPC_RA(a) | __PPC_RB(b))
+#define PPC_ERATSX_DOT(t, a, w) stringify_in_c(.long PPC_INST_ERATSX_DOT | \
+ __PPC_RS(t) | __PPC_RA(a) | __PPC_RB(b))
+
+
/*
* Define what the VSX XX1 form instructions will look like, then add
* the 128 bit load store instructions based on that.
--
1.7.1
^ permalink raw reply related
* Re: FTrace on MPC8xx
From: Stefan Roese @ 2011-04-15 7:22 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <OFDD77B7E3.D5C79015-ONC1257872.0069E657-C1257872.006A5415@transmode.se>
Hi Joakim,
On Thursday 14 April 2011 21:21:23 Joakim Tjernlund wrote:
> > hmm, I guess 8xx really maps kernel RO as RO :) Try
> >
> > changing in pte-8xx.h:
> > - #define _PAGE_KERNEL_RO (_PAGE_SHARED)
> > + #define _PAGE_KERNEL_RO (_PAGE_RW |_PAGE_SHARED)
>
> hmm, I wonder if not this is the problem(in pte-common.h)
> #if defined(CONFIG_KGDB) || defined(CONFIG_XMON) ||
> defined(CONFIG_BDI_SWITCH) ||\ defined(CONFIG_KPROBES)
> #define PAGE_KERNEL_TEXT PAGE_KERNEL_X
> #else
> #define PAGE_KERNEL_TEXT PAGE_KERNEL_ROX
> #endif
>
> What is PAGE_KERNEL_TEXT for you?
> I think it must be PAGE_KERNEL_X, otherwise kernel text will be readonly.
Yes, that's it! Its PAGE_KERNEL_ROX right now. We need to add CONFIG_FTRACE or
at least CONFIG_DYNAMIC_FTRACE to the #if statement above.
Do you want to send a patch (since you detected the real problem)? Or should I
do this?
Thanks.
Best regards,
Stefan
^ permalink raw reply
* Re: Problem with mini-PCI-E slot on P2020RDB
From: Felix Radensky @ 2011-04-15 7:20 UTC (permalink / raw)
To: Kushwaha Prabhakar-B32579
Cc: leon.woestenberg@gmail.com, linuxppc-dev@ozlabs.org,
Aggrwal Poonam-B10812
In-Reply-To: <071A08F2C6A57E4E94D980ECA553F87417BAF7@039-SN1MPN1-004.039d.mgd.msft.net>
Hi Poonam,
Thanks for the confirmation.
Felix.
On 04/15/2011 09:27 AM, Kushwaha Prabhakar-B32579 wrote:
> Added Linxppc-dev
>
>> -----Original Message-----
>> From: Aggrwal Poonam-B10812
>> Sent: Friday, April 15, 2011 11:47 AM
>> To: Felix Radensky
>> Cc: Kushwaha Prabhakar-B32579; leon.woestenberg@gmail.com
>> Subject: FW: Problem with mini-PCI-E slot on P2020RDB
>>
>> Hello Felix
>>
>> We checked with the Board designer, we need the board fixes "mentioned in
>> Board errata doc" on the board for this issue. Sorry for the confusion.
>>
>> The fixes are not present on RevC, also on some RevDs this fix also may
>> be absent.
>>
>>
>> Please let us know in case of any issues.
>>
>> Regards
>> Poonam
>>
>>> -----Original Message-----
>>> From: Leon Woestenberg [mailto:leon.woestenberg@gmail.com]
>>> Sent: Wednesday, April 13, 2011 2:52 PM
>>> To: Felix Radensky
>>> Cc: Aggrwal Poonam-B10812; linuxppc-dev@ozlabs.org; Gupta
>>> Maneesh-B18878; Kushwaha Prabhakar-B32579
>>> Subject: Re: Problem with mini-PCI-E slot on P2020RDB
>>>
>>> Felix,
>>>
>>> On Tue, Apr 12, 2011 at 6:54 AM, Felix Radensky
>>> <felix@embedded-sol.com>
>>> wrote:
>>>> On 04/12/2011 07:05 AM, Aggrwal Poonam-B10812 wrote:
>>>>> As such there is no hardware fix related to this issue between RevC
>>>>> to RevD. The solution was a software patch to resolve the issue
>>>>> related to IRQ0.
>>>> Are you sure ? Please take a look at Freescale document titled
>>>> "P1020E/P2020E RDB System Errata".
>>>> There's errata CE10, IRQ0 held low. It is fixed in Rev D. Vivek
>>>> Mahajan, who looked at the issue back in 2009, estimated that
>>>> problem can be related to missing pull-up on IRQ0.
>>>> This is exactly what is
>>>> fixed in Rev D.
>>>>
>>> That's my understanding as well.
>>>
>>> Check if R420 and R423 are populated. These are the required pull-ups.
>>> On Rev D they are populated. You might be able to add them yourself.
>>>
>>> Even if you have an Rev A-C PCB, this fix can already be applied; it
>>> was on my board! (the bottom of the board mentions the schematic
>>> revision)
>>>
>>> The resistors have a silkscreen designator block called X, the
>>> resistors are situated to the left and bottom of the silkscreen X.
>>> IIRC, between the flash and Px020 part.
>>>
>>> On the left side of R420 (or R423) I measured the block wave from the
>>> RTC, which fires the 32kHz interrupt rate on IRQ0. This fixed by the
>>> u- boot patch.
>>>
>>> Regards,
>>>
>>> Leon.
>
^ permalink raw reply
* Re: PCI Memory mapping
From: David Hawkins @ 2011-04-15 6:32 UTC (permalink / raw)
To: koteswararaom; +Cc: linuxppc-dev
In-Reply-To: <000001c19230$70546870$50fd3950$@com>
Hi Ajith,
> I have come across this forum, and I have a question. I am working on
> PCI device driver, I am trying to insert the pci card in to the pci slot
> of the main computer, I am finding a problem here, when I insert the
> card in to the pci slot, my pci device ID and vendor Id are not getting
> displayed. I am using windows xp o/s.
>
> I am trying to map pci memory. Can you suggest me how can we map the pci
> memory. What steps should I take in order to make my Device Id and
> Vendor Id displayed when I insert the card in to the pci slot.
This is a PowerPC Linux developer list so your question is
way off-topic here.
If your PCI card is not showing up at all, it could be due to the
fact that it is not being powered. I have found old motherboards
that do not supply both the 5V and 3.3V rails to PCI slots.
Check the power supplies on your PCI board, or at least
measure the PCI power pins in the slots. Then if power is present,
check there is a PCI clock in the slot. After that, boot Linux
from a bootable CD-ROM and type lspci to see if your device is
listed.
Cheers,
Dave
^ permalink raw reply
* Re: PCI Memory mapping
From: Michael Neuling @ 2011-04-15 6:48 UTC (permalink / raw)
To: koteswararaom; +Cc: linuxppc-dev
In-Reply-To: <000001c19230$70546870$50fd3950$@com>
> I have come across this forum, and I have a question. I am working on PCI
> device driver, I am trying to insert the pci card in to the pci slot of the
> main computer, I am finding a problem here, when I insert the card in to the
> pci slot, my pci device ID and vendor Id are not getting displayed. I am
> using windows xp o/s.
Err, so err, humm... er... how do I put this..?!
This is the "Linux on PowerPC" mailing list. Your question is neither
Linux or PowerPC related.
I'm not sure how you expect anyone here to help.
> I am trying to map pci memory. Can you suggest me how can we map the pci
> memory. What steps should I take in order to make my Device Id and Vendor Id
> displayed when I insert the card in to the pci slot.
Mikey
^ permalink raw reply
* RE: Problem with mini-PCI-E slot on P2020RDB
From: Kushwaha Prabhakar-B32579 @ 2011-04-15 6:27 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
Cc: leon.woestenberg@gmail.com, Felix Radensky, Aggrwal Poonam-B10812
In-Reply-To: <45903308677306428B6EE7E6FF5A520410D3E6@039-SN1MPN1-004.039d.mgd.msft.net>
Added Linxppc-dev
> -----Original Message-----
> From: Aggrwal Poonam-B10812
> Sent: Friday, April 15, 2011 11:47 AM
> To: Felix Radensky
> Cc: Kushwaha Prabhakar-B32579; leon.woestenberg@gmail.com
> Subject: FW: Problem with mini-PCI-E slot on P2020RDB
>=20
> Hello Felix
>=20
> We checked with the Board designer, we need the board fixes "mentioned in
> Board errata doc" on the board for this issue. Sorry for the confusion.
>=20
> The fixes are not present on RevC, also on some RevDs this fix also may
> be absent.
>=20
>=20
> Please let us know in case of any issues.
>=20
> Regards
> Poonam
>=20
> > -----Original Message-----
> > From: Leon Woestenberg [mailto:leon.woestenberg@gmail.com]
> > Sent: Wednesday, April 13, 2011 2:52 PM
> > To: Felix Radensky
> > Cc: Aggrwal Poonam-B10812; linuxppc-dev@ozlabs.org; Gupta
> > Maneesh-B18878; Kushwaha Prabhakar-B32579
> > Subject: Re: Problem with mini-PCI-E slot on P2020RDB
> >
> > Felix,
> >
> > On Tue, Apr 12, 2011 at 6:54 AM, Felix Radensky
> > <felix@embedded-sol.com>
> > wrote:
> > > On 04/12/2011 07:05 AM, Aggrwal Poonam-B10812 wrote:
> > >> As such there is no hardware fix related to this issue between RevC
> > >> to RevD. The solution was a software patch to resolve the issue
> > >> related to IRQ0.
> > >
> > > Are you sure ? Please take a look at Freescale document titled
> > > "P1020E/P2020E RDB System Errata".
> > > There's errata CE10, IRQ0 held low. It is fixed in Rev D. Vivek
> > > Mahajan, who looked at the issue back in 2009, estimated that
> > > problem can be related to missing pull-up on IRQ0.
> > > This is exactly what is
> > > fixed in Rev D.
> > >
> >
> > That's my understanding as well.
> >
> > Check if R420 and R423 are populated. These are the required pull-ups.
> > On Rev D they are populated. You might be able to add them yourself.
> >
> > Even if you have an Rev A-C PCB, this fix can already be applied; it
> > was on my board! (the bottom of the board mentions the schematic
> > revision)
> >
> > The resistors have a silkscreen designator block called X, the
> > resistors are situated to the left and bottom of the silkscreen X.
> > IIRC, between the flash and Px020 part.
> >
> > On the left side of R420 (or R423) I measured the block wave from the
> > RTC, which fires the 32kHz interrupt rate on IRQ0. This fixed by the
> > u- boot patch.
> >
> > Regards,
> >
> > Leon.
^ permalink raw reply
* Re: PCI Memory mapping
From: koteswararaom @ 2011-04-15 5:44 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 574 bytes --]
Hi,
I have come across this forum, and I have a question. I am working on PCI
device driver, I am trying to insert the pci card in to the pci slot of the
main computer, I am finding a problem here, when I insert the card in to the
pci slot, my pci device ID and vendor Id are not getting displayed. I am
using windows xp o/s.
I am trying to map pci memory. Can you suggest me how can we map the pci
memory. What steps should I take in order to make my Device Id and Vendor Id
displayed when I insert the card in to the pci slot.
With Kind regards,
Ajith.
[-- Attachment #2: Type: text/html, Size: 2426 bytes --]
^ permalink raw reply
* [PATCH 2/2] powerpc: Add an ePAPR compliant boot wrapper
From: Michael Ellerman @ 2011-04-15 4:29 UTC (permalink / raw)
To: linuxppc-dev; +Cc: David Gibson
In-Reply-To: <34e3e03a96888bc8c20013aa65712123ccf94649.1302676893.git.michael@ellerman.id.au>
From: David Gibson <dwg@au1.ibm.com>
This is a first cut at making bootwrapper code which will
produce a zImage compliant with the requirements set down
by ePAPR.
This is a very simple bootwrapper, taking the device tree
blob supplied by the ePAPR boot program and passing it on
to the kernel. It builds on the earlier patch to build a
relocatable ET_DYN zImage to meet the other ePAPR image
requirements.
For good measure we have some paranoid checks which will
generate warnings if some of the ePAPR entry condition
guarantees are not met.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/Kconfig | 6 ++++
arch/powerpc/boot/Makefile | 4 ++-
arch/powerpc/boot/epapr.c | 66 ++++++++++++++++++++++++++++++++++++++++++++
arch/powerpc/boot/wrapper | 4 ++
4 files changed, 79 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index b6ff882..2629c21 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -193,6 +193,12 @@ config SYS_SUPPORTS_APM_EMULATION
default y if PMAC_APM_EMU
bool
+config EPAPR_BOOT
+ bool
+ help
+ Used to allow a board to specify it wants an ePAPR compliant wrapper.
+ default n
+
config DEFAULT_UIMAGE
bool
help
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 8917816..0e2a152 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -69,7 +69,8 @@ src-wlib := string.S crt0.S crtsavres.S stdio.c main.c \
cpm-serial.c stdlib.c mpc52xx-psc.c planetcore.c uartlite.c \
fsl-soc.c mpc8xx.c pq2.c ugecon.c
src-plat := of.c cuboot-52xx.c cuboot-824x.c cuboot-83xx.c cuboot-85xx.c holly.c \
- cuboot-ebony.c cuboot-hotfoot.c treeboot-ebony.c prpmc2800.c \
+ cuboot-ebony.c cuboot-hotfoot.c epapr.c treeboot-ebony.c \
+ prpmc2800.c \
ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \
cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c \
cuboot-bamboo.c cuboot-mpc7448hpc2.c cuboot-taishan.c \
@@ -182,6 +183,7 @@ image-$(CONFIG_PPC_HOLLY) += dtbImage.holly
image-$(CONFIG_PPC_PRPMC2800) += dtbImage.prpmc2800
image-$(CONFIG_PPC_ISERIES) += zImage.iseries
image-$(CONFIG_DEFAULT_UIMAGE) += uImage
+image-$(CONFIG_EPAPR_BOOT) += zImage.epapr
#
# Targets which embed a device tree blob
diff --git a/arch/powerpc/boot/epapr.c b/arch/powerpc/boot/epapr.c
new file mode 100644
index 0000000..06c1961
--- /dev/null
+++ b/arch/powerpc/boot/epapr.c
@@ -0,0 +1,66 @@
+/*
+ * Bootwrapper for ePAPR compliant firmwares
+ *
+ * Copyright 2010 David Gibson <david@gibson.dropbear.id.au>, IBM Corporation.
+ *
+ * Based on earlier bootwrappers by:
+ * (c) Benjamin Herrenschmidt <benh@kernel.crashing.org>, IBM Corp,\
+ * and
+ * Scott Wood <scottwood@freescale.com>
+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include "ops.h"
+#include "stdio.h"
+#include "io.h"
+#include <libfdt.h>
+
+BSS_STACK(4096);
+
+#define EPAPR_SMAGIC 0x65504150
+#define EPAPR_EMAGIC 0x45504150
+
+static unsigned epapr_magic;
+static unsigned long ima_size;
+static unsigned long fdt_addr;
+
+static void platform_fixups(void)
+{
+ if ((epapr_magic != EPAPR_EMAGIC)
+ && (epapr_magic != EPAPR_SMAGIC))
+ fatal("r6 contained 0x%08x instead of ePAPR magic number\n",
+ epapr_magic);
+
+ if (ima_size < (unsigned long)_end)
+ printf("WARNING: Image loaded outside IMA!"
+ " (_end=%p, ima_size=0x%lx)\n", _end, ima_size);
+ if (ima_size < fdt_addr)
+ printf("WARNING: Device tree address is outside IMA!"
+ "(fdt_addr=0x%lx, ima_size=0x%lx)\n", fdt_addr,
+ ima_size);
+ if (ima_size < fdt_addr + fdt_totalsize((void *)fdt_addr))
+ printf("WARNING: Device tree extends outside IMA!"
+ " (fdt_addr=0x%lx, size=0x%x, ima_size=0x%lx\n",
+ fdt_addr, fdt_totalsize((void *)fdt_addr), ima_size);
+}
+
+void platform_init(unsigned long r3, unsigned long r4, unsigned long r5,
+ unsigned long r6, unsigned long r7)
+{
+ epapr_magic = r6;
+ ima_size = r7;
+ fdt_addr = r3;
+
+ /* FIXME: we should process reserve entries */
+
+ simple_alloc_init(_end, ima_size - (unsigned long)_end, 32, 64);
+
+ fdt_init((void *)fdt_addr);
+
+ serial_console_init();
+ platform_ops.fixups = platform_fixups;
+}
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index fef5278..dfa29cb 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -247,6 +247,10 @@ gamecube|wii)
treeboot-iss4xx-mpic)
platformo="$object/treeboot-iss4xx.o"
;;
+epapr)
+ link_address='0x20000000'
+ pie=-pie
+ ;;
esac
vmz="$tmpdir/`basename \"$kernel\"`.$ext"
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] powerpc: Define 'crash_kexec_wait_realmode' for Non-SMP systems.
From: Shaun Ruffell @ 2011-04-15 3:45 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <4DA78A44.1000704@windriver.com>
On 4/14/11 6:59 PM, Paul Gortmaker wrote:
> On 11-04-14 06:27 PM, Shaun Ruffell wrote:
>> This fixes a regression from b987812b3fcaf70fdf0037589e5d2f5f2453e6ce
>
> A fix was already sent yesterday:
>
> http://lists.ozlabs.org/pipermail/linuxppc-dev/2011-April/089559.html
>
> which relocates the stub function to where it needs to be. Your fix
> below would end up making duplicate stub functions.
Thanks for the reply. I didn't search the linuxppp-dev list before
sending in that patch, only the LKML. Sorry about the noise.
Cheers,
Shaun
^ permalink raw reply
* Re: [PATCH] powerpc: Define 'crash_kexec_wait_realmode' for Non-SMP systems.
From: Paul Gortmaker @ 2011-04-14 23:59 UTC (permalink / raw)
To: Shaun Ruffell; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20110414222719.GA16256@digium.com>
On 11-04-14 06:27 PM, Shaun Ruffell wrote:
> This fixes a regression from b987812b3fcaf70fdf0037589e5d2f5f2453e6ce
A fix was already sent yesterday:
http://lists.ozlabs.org/pipermail/linuxppc-dev/2011-April/089559.html
which relocates the stub function to where it needs to be. Your fix
below would end up making duplicate stub functions.
Thanks,
Paul.
> "powerpc/kexec: Fix mismatched ifdefs for PPC64/SMP" which resulted in
>
> arch/powerpc/kernel/crash.c: In function ‘default_machine_crash_shutdown’:
> arch/powerpc/kernel/crash.c:349: error: implicit declaration of function
> ‘crash_kexec_wait_realmode’
>
> message on when compiling on Blue&White G3 and CONFIG_SMP is not defined.
>
> Signed-off-by: Shaun Ruffell <sruffell@digium.com>
> ---
> arch/powerpc/kernel/crash.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
> index 3d3d416..5e6e37f 100644
> --- a/arch/powerpc/kernel/crash.c
> +++ b/arch/powerpc/kernel/crash.c
> @@ -255,6 +255,9 @@ void crash_kexec_secondary(struct pt_regs *regs)
> {
> cpus_in_sr = CPU_MASK_NONE;
> }
> +
> +static inline void crash_kexec_wait_realmode(int cpu) {}
> +
> #endif
>
> /*
^ permalink raw reply
* Non-console UART issues with 8xx
From: Eran Duchan @ 2011-04-14 23:52 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 910 bytes --]
Hey list
I have a custom MPC875 board running 2.6.37. SMC1 is the console, SCC4 is a
general purpose UART (DTS is set up accordingly). No hardware or software
flow control for either.
The issue is simple: the non-console UART transmits garbled characters at
the end of the transmission. For example, set up SMC1 to console (works
perfect) and SCC4 as non-console, run stty -F /dev/ttyCPM1 19200 raw and
then echo -n 1234567890 > /dev/ttyCPM1 - transmission may be something like
"1234567ø". Set the SCC4 as console (same baud rates) and the problem is
reversed (SCC4 works perfect, SMC1 transmit garbled).
Rx direction seems fine, after some rudementary testing.
I dived into the code and see that the console UART has a completely
different initialization sequence than the non-console UART. Short of diving
into this ancient CPM architecture - does anyone have an idea?
Thanks
Eran
[-- Attachment #2: Type: text/html, Size: 1159 bytes --]
^ permalink raw reply
* [PATCH] powerpc: Define 'crash_kexec_wait_realmode' for Non-SMP systems.
From: Shaun Ruffell @ 2011-04-14 22:27 UTC (permalink / raw)
To: Paul Gortmaker, Benjamin Herrenschmidt; +Cc: linuxppc-dev, linux-kernel
This fixes a regression from b987812b3fcaf70fdf0037589e5d2f5f2453e6ce
"powerpc/kexec: Fix mismatched ifdefs for PPC64/SMP" which resulted in
arch/powerpc/kernel/crash.c: In function =E2=80=98default_machine_crash_s=
hutdown=E2=80=99:
arch/powerpc/kernel/crash.c:349: error: implicit declaration of functio=
n
=E2=80=98crash_kexec_wait_realmode=E2=80=99
message on when compiling on Blue&White G3 and CONFIG_SMP is not defined.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
---
arch/powerpc/kernel/crash.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
index 3d3d416..5e6e37f 100644
--- a/arch/powerpc/kernel/crash.c
+++ b/arch/powerpc/kernel/crash.c
@@ -255,6 +255,9 @@ void crash_kexec_secondary(struct pt_regs *regs)
{
cpus_in_sr =3D CPU_MASK_NONE;
}
+
+static inline void crash_kexec_wait_realmode(int cpu) {}
+
#endif
=20
/*
--=20
1.7.4.3
^ permalink raw reply related
* Re: [regression] 2.6.39-rc[1-3] fail to boot on G5 PowerMac
From: Mikael Pettersson @ 2011-04-14 22:14 UTC (permalink / raw)
To: Hugh Dickins
Cc: Mikael Pettersson, Jens Axboe, linux-kernel, kevin diggs,
linuxppc-dev
In-Reply-To: <BANLkTimykvKp=bwsFyNE9fWqcE9Ffws6bA@mail.gmail.com>
On Thu, 14 Apr 2011 14:25:31 -0700, Hugh Dickins wrote:
> Mikael,
>
> Something worth trying: turn off CONFIG_IDE. That's what I need to
> boot 2.6.39-rc[1-3] on PowerPC G5.
>
> I know Jens has been fixing problems with IDE versus his plug/unplug
> changes, but it's still not fixed for me in rc3.
>
> In other mail http://lkml.org/lkml/2011/4/14/614
> I see Linus recommending his post-rc3 commit 6631e635c65d
> but I've not tried that myself yet.
>
> Hugh
Hugh,
With CONFIG_IDE disabled I could finally boot 2.6.39-rc3 on my G5.
I lost the DVD drive, but that's fine for now.
Thanks!
/Mikael
^ permalink raw reply
* Re: [regression] 2.6.39-rc[1-3] fail to boot on G5 PowerMac
From: Benjamin Herrenschmidt @ 2011-04-14 21:54 UTC (permalink / raw)
To: Hugh Dickins
Cc: Mikael Pettersson, Jens Axboe, linux-kernel, kevin diggs,
linuxppc-dev
In-Reply-To: <BANLkTimykvKp=bwsFyNE9fWqcE9Ffws6bA@mail.gmail.com>
On Thu, 2011-04-14 at 14:25 -0700, Hugh Dickins wrote:
>
> Something worth trying: turn off CONFIG_IDE. That's what I need to
> boot 2.6.39-rc[1-3] on PowerPC G5.
>
> I know Jens has been fixing problems with IDE versus his plug/unplug
> changes, but it's still not fixed for me in rc3.
>
> In other mail http://lkml.org/lkml/2011/4/14/614
> I see Linus recommending his post-rc3 commit 6631e635c65d
> but I've not tried that myself yet.
Well, the disk is SATA so it's CONFIG_ATA/libata, which works fine here,
unless you somewhat replaced your CD-ROM with a legacy IDE disk :-) Or
maybe the problem is related to the CD-ROM drive. There's a libata
driver for it nowadays, so you can use PATA_MACIO instead of IDE_PMAC
Cheers,
Ben.
^ permalink raw reply
* Re: [regression] 2.6.39-rc[1-3] fail to boot on G5 PowerMac
From: Hugh Dickins @ 2011-04-14 21:25 UTC (permalink / raw)
To: Mikael Pettersson; +Cc: Jens Axboe, linux-kernel, kevin diggs, linuxppc-dev
In-Reply-To: <1302771756.15520.100.camel@thor.local>
On Thu, Apr 14, 2011 at 2:02 AM, Michel D=C3=A4nzer <michel@daenzer.net> wr=
ote:
> On Mit, 2011-04-13 at 18:43 -0500, kevin diggs wrote:
>>
>> On Wed, Apr 13, 2011 at 6:21 PM, Benjamin Herrenschmidt
>> <benh@kernel.crashing.org> wrote:
>> > On Wed, 2011-04-13 at 12:52 -0500, kevin diggs wrote:
>> >> > Actually I do get a crash in X later on... something in the radeon
>> >> DRM
>> >> > interrupt code is getting what looks like a NULL dereference. I'll
>> >> try
>> >> > to dig that one later on. I don't know if it's related to your
>> >> problem
>> >> > at all though.
>> >> >
>> >> In this context, what does 'crash' mean? The X thingy goes down? Or
>> >> the whole OS?
>> >
>> > Depends, with xmon enabled you get into xmon :-) Dunno if the oops is
>> > fatal but it could be.
>> >
>> > Cheers,
>> > Ben.
>> >
>> >
>>
>> As I think I have the same hardware as you (7,3, radeon 9600) If you
>> can tell me how to reproduce it maybe I can poke around a little.
>> Thus, at least temporarily, freeing you up for other stuff.
>>
>> I kinda need a break from fighting with GCC.
>
> FWIW, the problem Ben refers to might be fixed in current mainline by
> commit d87dfdbfc91c5e37288e7e8f7afdd992ba61a60d which reverts
> 69a07f0b117a40fcc1a479358d8e1f41793617f2 .
Mikael,
Something worth trying: turn off CONFIG_IDE. That's what I need to
boot 2.6.39-rc[1-3] on PowerPC G5.
I know Jens has been fixing problems with IDE versus his plug/unplug
changes, but it's still not fixed for me in rc3.
In other mail http://lkml.org/lkml/2011/4/14/614
I see Linus recommending his post-rc3 commit 6631e635c65d
but I've not tried that myself yet.
Hugh
^ permalink raw reply
* Re: FTrace on MPC8xx
From: Joakim Tjernlund @ 2011-04-14 19:21 UTC (permalink / raw)
Cc: Scott Wood, linuxppc-dev
In-Reply-To: <OF71C64301.E54A0A3C-ONC1257872.005BD121-C1257872.005C754F@transmode.se>
>
> Stefan Roese <ml@stefan-roese.de> wrote on 2011/04/14 17:59:30:
> >
> > Hi Joakim,
> >
> > On Wednesday 13 April 2011 17:38:03 Joakim Tjernlund wrote:
> > > > > How big was the size to copy_tofrom_user()? Did it mange to copy
> > > > > any bytes?
> > > >
> > > > The size in __copy_tofrom_user is 4. And its the first call in
> > > > ftrace_modify_code() that fails directly. This works just fine on a
> > > > PPC440EPx board.
> > >
> > > Since the size is only 4 it would not use dcbX anyway(I think).
> > > Then is is probably called with the wrong addresses?
> >
> > No, addresses seem to be correct. I checked a bit further (I'm quite new to
> > the MPC8xx MMU) and it seems that trying to modify the code (that's the
> > destination address) via __copy_tofrom_user() fails on MPC8xx. Still not sure
> > why this is the case. Perhaps an 8xx guru might chime in here. ;)
> >
> > BTW: I just noticed that enabling CONFIG_PIN_TLB seems to resolve this issue.
> > With this option enabled, the dynamic code modification works just fine.
> >
> > Joakim, Scott? Any ideas on this?
>
> hmm, I guess 8xx really maps kernel RO as RO :) Try
> changing in pte-8xx.h:
> - #define _PAGE_KERNEL_RO (_PAGE_SHARED)
> + #define _PAGE_KERNEL_RO (_PAGE_RW |_PAGE_SHARED)
hmm, I wonder if not this is the problem(in pte-common.h)
#if defined(CONFIG_KGDB) || defined(CONFIG_XMON) || defined(CONFIG_BDI_SWITCH) ||\
defined(CONFIG_KPROBES)
#define PAGE_KERNEL_TEXT PAGE_KERNEL_X
#else
#define PAGE_KERNEL_TEXT PAGE_KERNEL_ROX
#endif
What is PAGE_KERNEL_TEXT for you?
I think it must be PAGE_KERNEL_X, otherwise kernel text will be readonly.
Jocke
^ permalink raw reply
* Re: FTrace on MPC8xx
From: Joakim Tjernlund @ 2011-04-14 16:49 UTC (permalink / raw)
To: Stefan Roese; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <201104141759.30446.ml@stefan-roese.de>
Stefan Roese <ml@stefan-roese.de> wrote on 2011/04/14 17:59:30:
>
> Hi Joakim,
>
> On Wednesday 13 April 2011 17:38:03 Joakim Tjernlund wrote:
> > > > How big was the size to copy_tofrom_user()? Did it mange to copy
> > > > any bytes?
> > >
> > > The size in __copy_tofrom_user is 4. And its the first call in
> > > ftrace_modify_code() that fails directly. This works just fine on a
> > > PPC440EPx board.
> >
> > Since the size is only 4 it would not use dcbX anyway(I think).
> > Then is is probably called with the wrong addresses?
>
> No, addresses seem to be correct. I checked a bit further (I'm quite new to
> the MPC8xx MMU) and it seems that trying to modify the code (that's the
> destination address) via __copy_tofrom_user() fails on MPC8xx. Still not sure
> why this is the case. Perhaps an 8xx guru might chime in here. ;)
>
> BTW: I just noticed that enabling CONFIG_PIN_TLB seems to resolve this issue.
> With this option enabled, the dynamic code modification works just fine.
>
> Joakim, Scott? Any ideas on this?
hmm, I guess 8xx really maps kernel RO as RO :) Try
changing in pte-8xx.h:
- #define _PAGE_KERNEL_RO (_PAGE_SHARED)
+ #define _PAGE_KERNEL_RO (_PAGE_RW |_PAGE_SHARED)
^ permalink raw reply
* Re: PowerMacintosh B&W G3 boot failure - linux-2.6.36.x
From: acrux @ 2011-04-14 16:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Nello M, linuxppc-dev
In-Reply-To: <1302749356.28876.105.camel@pasglop>
On Thu, 14 Apr 2011 12:49:16 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Wed, 2011-04-13 at 20:27 +0200, acrux wrote:
> > i guess it's a different problem from the PegasosI G3 but i could
> > be wrong.
> >
> > I'd like to receive feedbacks and a working kernel config if
> > someone is running with success linux-2.6.26.x on a Pmac B&W G3.
> > This machine, altough obsolete, is still quite common
>
> The snapshot you posted doesn't have much information... there's no
> obvious error for example in there...
>
I know, I received from it from a user. It's where the kernel hangs.
Anyway, the last year, i received many install failures report from
cruxppc users. I hope it's only my fault building the bootkernel and
i'd like to receive a feedback from others distro developers for this
specific machine.
I always avoided to collect obsolete machines thus I don't have a B&W G3
but now i'm looking for one.
> What video driver are you trying to use ? Have you tried plain offb ?
> (disabling whatever is the native driver for your video card, ie,
> radeonfb or aty128fb or even atyfb, dunno what you have in there).
>
> You can also try something like "udbg-immortal" on the kernel command
> line see if that brings you more debug output.
>
I'll try to receive more detailed info from that gentle user.
Thanks again for your kind support,
Nico
--
GNU/Linux on Power Architecture
CRUX PPC - http://cruxppc.org/
^ permalink raw reply
* Re: FTrace on MPC8xx
From: Stefan Roese @ 2011-04-14 15:59 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <OF832AEAAB.68C38F85-ONC1257871.0055965D-C1257871.0055E1C2@transmode.se>
Hi Joakim,
On Wednesday 13 April 2011 17:38:03 Joakim Tjernlund wrote:
> > > How big was the size to copy_tofrom_user()? Did it mange to copy
> > > any bytes?
> >
> > The size in __copy_tofrom_user is 4. And its the first call in
> > ftrace_modify_code() that fails directly. This works just fine on a
> > PPC440EPx board.
>
> Since the size is only 4 it would not use dcbX anyway(I think).
> Then is is probably called with the wrong addresses?
No, addresses seem to be correct. I checked a bit further (I'm quite new to
the MPC8xx MMU) and it seems that trying to modify the code (that's the
destination address) via __copy_tofrom_user() fails on MPC8xx. Still not sure
why this is the case. Perhaps an 8xx guru might chime in here. ;)
BTW: I just noticed that enabling CONFIG_PIN_TLB seems to resolve this issue.
With this option enabled, the dynamic code modification works just fine.
Joakim, Scott? Any ideas on this?
Thanks,
Stefan
^ permalink raw reply
* Re: fsl elbc driver causes corruption with bus monitor timeouts while simultaneously access on Nor / Nand mtd partitions
From: Felix Radensky @ 2011-04-14 12:10 UTC (permalink / raw)
To: emre kara
Cc: Wood Scott-B07421, David Woodhouse, linux-kernel, bayraktarz,
Lan Chunhe-B25806, linux-mtd@lists.infradead.org, Scott Wood,
linuxppc-dev
In-Reply-To: <204286.97927.qm@web25602.mail.ukl.yahoo.com>
[-- Attachment #1: Type: text/html, Size: 1101 bytes --]
^ permalink raw reply
* Re: Where is CONFIG_BOOT_LOAD ?
From: Guillaume Dargaud @ 2011-04-14 9:18 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4DA485CD.6060604@gmx.de>
On Tuesday 12 April 2011 19:03:09 Joachim F=F6rster wrote:
> Note that the default 0x400... is the link address of the zImage wrapper
> rather than the one of THE kernel.
Yes, and I need more space for the uncompression to take place when using a=
ramdisk.
> Currently the link address seems to be hard-coded into
> arch/powerpc/boot/wrapper
> (a shell script). Since long ago I'm wondering why the maintainers did
> that. But I guess there is a reason, because it wasn't that way in the
> old arch/ppc days ;-) ...
Thanks for that. I'd been using "objcopy --change-addresses" to relocate th=
e elf file with success.
> Is configuring the zImage-piggy-back-loader through menuconfig & co evil?
That seems like a good idea. Maybe add some way to figure out if the uncomp=
ressed kernel overlaps the zImage wrapper ?
=2D-=20
Guillaume Dargaud
http://www.gdargaud.net/Antarctica/
^ permalink raw reply
* Re: [regression] 2.6.39-rc[1-3] fail to boot on G5 PowerMac
From: Michel Dänzer @ 2011-04-14 9:02 UTC (permalink / raw)
To: kevin diggs; +Cc: Mikael Pettersson, linuxppc-dev, linux-kernel
In-Reply-To: <BANLkTika8FY1dD_hOQ4wMhHzuQ2Qt8fg7A@mail.gmail.com>
On Mit, 2011-04-13 at 18:43 -0500, kevin diggs wrote:=20
>=20
> On Wed, Apr 13, 2011 at 6:21 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> > On Wed, 2011-04-13 at 12:52 -0500, kevin diggs wrote:
> >> > Actually I do get a crash in X later on... something in the radeon
> >> DRM
> >> > interrupt code is getting what looks like a NULL dereference. I'll
> >> try
> >> > to dig that one later on. I don't know if it's related to your
> >> problem
> >> > at all though.
> >> >
> >> In this context, what does 'crash' mean? The X thingy goes down? Or
> >> the whole OS?
> >
> > Depends, with xmon enabled you get into xmon :-) Dunno if the oops is
> > fatal but it could be.
> >
> > Cheers,
> > Ben.
> >
> >
>=20
> As I think I have the same hardware as you (7,3, radeon 9600) If you
> can tell me how to reproduce it maybe I can poke around a little.
> Thus, at least temporarily, freeing you up for other stuff.
>=20
> I kinda need a break from fighting with GCC.
FWIW, the problem Ben refers to might be fixed in current mainline by
commit d87dfdbfc91c5e37288e7e8f7afdd992ba61a60d which reverts
69a07f0b117a40fcc1a479358d8e1f41793617f2 .
--=20
Earthling Michel D=C3=A4nzer | http://www.vmware.c=
om
Libre software enthusiast | Debian, X and DRI developer
^ permalink raw reply
* fsl elbc driver causes corruption with bus monitor timeouts while simultaneously access on Nor / Nand mtd partitions
From: emre kara @ 2011-04-14 7:06 UTC (permalink / raw)
To: Scott Wood, Roy Zang
Cc: Wood Scott-B07421, felix, David Woodhouse, linux-kernel,
bayraktarz, Lan Chunhe-B25806, linuxppc-dev
Hi Scott, Roy.
Scott's "mtd: eLBC NAND: increase bus timeout to maximum" patch is excluded=
from kernel with Roy's "P4080/eLBC: Make Freescale elbc interrupt common t=
o elbc devices" patch. I don't know the reason for it but this causes bus m=
onitor timeouts and corrupts nand flash while using mainline kernel. As I k=
now there is an errata related to this topic, I think "increasing bus timeo=
ut to maximum" is a must.
You can easly generate this situation with below commands:
Note: mtd4 is a Nor and mtd9 is a Nand partition.
[root@P2020RDB root]# mount /dev/mtdblock9 /mnt/src/
mount: you must specify the filesystem type
[root@P2020RDB root]# mount /dev/mtdblock9 /mnt/src/ -t jffs2
=EF=BF=BD=EF=BF=BDJFFS2 notice: (1950) jffs2_build_xattr_subsystem: complet=
e building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xr=
ef (0 dead, 0 orphan) found.
[root@P2020RDB root]# dd if=3D/dev/mtd4 of=3D/mnt/src/uboot bs=3D1
fsl-lbc ffe05000.localbus: Local bus monitor time-out: LTESR 0x80000000
fsl-lbc ffe05000.localbus: command failed: fir 412e0000 fcr 0 status 800000=
00 mdr c0
Read of newly-erased block at 0x00430000 failed: -74. Putting on bad_list
fsl-lbc ffe05000.localbus: Local bus monitor time-out: LTESR 0x80000000
fsl-lbc ffe05000.localbus: command failed: fir 426db000 fcr 6070d000 status=
80000000 mdr ff
Erase at 0x0042c000 failed immediately: errno -5
fsl-lbc ffe05000.localbus: Local bus monitor time-out: LTESR 0x80000000
Cfsl-lbc ffe05000.localbus: command failed: fir 412e0000 fcr 0 status 80000=
000 mdr c0
Read of newly-erased block at 0x00433000 failed: -74. Putting on bad_list
JFFS2: marking eraseblock at 00433000
Regards.
Emre
^ permalink raw reply
* [PATCH v4] powerpc: use a kmem cache for DTL buffers
From: Nishanth Aravamudan @ 2011-04-14 5:45 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard
In-Reply-To: <1302758026-29313-1-git-send-email-nacc@us.ibm.com>
PAPR specifies that DTL buffers can not cross AMS environments (aka CMO
in the PAPR) and can not cross a memory entitlement granule boundary
(4k). This is found in section 14.11.3.2 H_REGISTER_VPA of the PAPR.
kmalloc does not guarantee an alignment of the allocation, though,
beyond 8 bytes (at least in my understanding). Create a special kmem
cache for DTL buffers with the alignment requirement.
---
Change from v1: removed extraneous #include.
Change from v2: instead of overallocating and aligning, use a kmem cache
Change from v3: handle cache creation failure
Note, I initially put this in a firmware check if-block, but we have
also seen some issues with alignment with non-AMS partitions. The wasted
memory is unfortunate, though.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Ben Herrenschmidt <benh@kernel.crashing.org>
Cc: Anton Blanchard <anton@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
arch/powerpc/platforms/pseries/setup.c | 12 ++++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 0007241..9e20b83 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -287,14 +287,22 @@ static int alloc_dispatch_logs(void)
int cpu, ret;
struct paca_struct *pp;
struct dtl_entry *dtl;
+ struct kmem_cache *dtl_cache;
if (!firmware_has_feature(FW_FEATURE_SPLPAR))
return 0;
+ dtl_cache = kmem_cache_create("dtl", DISPATCH_LOG_BYTES,
+ DISPATCH_LOG_BYTES, 0, NULL);
+ if (!dtl_cache) {
+ pr_warn("Failed to create dispatch trace log buffer cache\n");
+ pr_warn("Stolen time statistics will be unreliable\n");
+ return 0;
+ }
+
for_each_possible_cpu(cpu) {
pp = &paca[cpu];
- dtl = kmalloc_node(DISPATCH_LOG_BYTES, GFP_KERNEL,
- cpu_to_node(cpu));
+ dtl = kmem_cache_alloc(dtl_cache, GFP_KERNEL);
if (!dtl) {
pr_warn("Failed to allocate dispatch trace log for cpu %d\n",
cpu);
--
1.7.4.1
^ permalink raw reply related
* [PATCH v3] powerpc: use a kmem cache for DTL buffers
From: Nishanth Aravamudan @ 2011-04-14 5:13 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard
In-Reply-To: <1302754363.12513.89.camel@concordia>
PAPR specifies that DTL buffers can not cross AMS environments (aka CMO
in the PAPR) and can not cross a memory entitlement granule boundary
(4k). This is found in section 14.11.3.2 H_REGISTER_VPA of the PAPR.
kmalloc does not guarantee an alignment of the allocation, though,
beyond 8 bytes (at least in my understanding). Create a special kmem
cache for DTL buffers with the alignment requirement.
---
Change from v1: removed extraneous #include.
Change from v2: instead of overallocating and aligning, use a kmem cache
Note, I initially put this in a firmware check if-block, but we have
also seen some issues with alignment with non-AMS partitions. The wasted
memory is unfortunate, though.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Ben Herrenschmidt <benh@kernel.crashing.org>
Cc: Anton Blanchard <anton@samba.org>
Cc: linuxppc-dev@lists.ozlabs.org
arch/powerpc/platforms/pseries/setup.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 0007241..629b703 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -287,14 +287,17 @@ static int alloc_dispatch_logs(void)
int cpu, ret;
struct paca_struct *pp;
struct dtl_entry *dtl;
+ struct kmem_cache *dtl_cache;
if (!firmware_has_feature(FW_FEATURE_SPLPAR))
return 0;
+ dtl_cache = kmem_cache_create("dtl", DISPATCH_LOG_BYTES,
+ DISPATCH_LOG_BYTES, 0, NULL);
+
for_each_possible_cpu(cpu) {
pp = &paca[cpu];
- dtl = kmalloc_node(DISPATCH_LOG_BYTES, GFP_KERNEL,
- cpu_to_node(cpu));
+ dtl = kmem_cache_alloc(dtl_cache, GFP_KERNEL);
if (!dtl) {
pr_warn("Failed to allocate dispatch trace log for cpu %d\n",
cpu);
--
1.7.4.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox