* Re: [RFC] [PATCH v2] MPC5121 TLB errata workaround
From: Kumar Gala @ 2009-03-13 15:23 UTC (permalink / raw)
To: David Jander
Cc: linuxppc-dev, Paul Mackerras, Wolfgang Denk, Gunnar Von Boehn
In-Reply-To: <200903131524.36865.david.jander@protonic.nl>
On Mar 13, 2009, at 9:24 AM, David Jander wrote:
> On Friday 13 March 2009 14:21:57 Kumar Gala wrote:
>>>
>>
>> What does cat /proc/cpuinfo show on this board?
>
> # cat /proc/cpuinfo
> processor : 0
> cpu : e300c4
> clock : 400.000000MHz
> revision : 1.0 (pvr 8086 2010)
> bogomips : 99.84
> timebase : 50000000
> platform : MPC5121 Generic
>
>>> +#ifdef CONFIG_PPC_MPC512x
>>> +/* MPC512x: workaround for errata in die M36P and earlier:
>>> + * Implement LRW for TLB way.
>>> + */
>>
>> This errata impacts a number of cores and so we should make this a
>> CPU
>> feature fixup rather than #ifdef code.
>
> It should impact only MPC5121e and probably MPC5123, but according to
> Freescale no other processors that use this core...
Not sure about that.. But the errata impacts all e300c2/c3/c4 parts.
> Anyway, I'll try to investigate about how to write a "CPU feature
> fixup",
> I've never done that before (If you could give me a hint?)
I've posted a patch that should add the CPU feature support. This is
only compile tested. You'll need to try it out on real HW :)
>>> + mfspr r3,SPRN_DMISS
>>> + rlwinm r3,r3,19,25,29 /* Get Address bits 19:15 */
>>> + lis r2,lrw@ha /* Search index in lrw[] */
>>> + addi r2,r2,lrw@l
>>> + tophys(r2,r2)
>>> + lwzx r1,r3,r2 /* Get item from lrw[] */
>>> + cmpwi 0,r1,0 /* Was it way 0 last time? */
>>
>> Why not use a bit vector since we only need one bit of information.
>> Additionally we can use a single SPRG at that point instead to keep
>> track of the LRU information.
>
> Sounds interesting. I am just learning my first steps in powerpc-
> assembly, so
> please forgive if this is a little inefficient still. I'll try again
> next week.
Not at all. This has been on my todo list just not high priority so
I'm happy to get someone to work on it and have setup already that can
show perf differences.
I might work up a newer version w/the SPRG idea if I'm feeling up to it.
- k
^ permalink raw reply
* [RFC][PATCH v3] powerpc: e300c2/c3/c4 TLB errata workaround
From: Kumar Gala @ 2009-03-13 15:16 UTC (permalink / raw)
To: david.jander; +Cc: linuxppc-dev, wd, gunnar
From: David Jander <david.jander@protonic.nl>
Complete workaround for DTLB errata in e300c2/c3/c4 processors.
Due to the bug, the hardware-implemented LRU algorythm always goes to way
1 of the TLB. This fix implements the proposed software workaround in
form of a LRW table for chosing the TLB-way.
Signed-off-by: David Jander <david@protonic.nl>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
Added cpu feature support.. need to check with Ben if we should use a MMU feature instead
- k
arch/powerpc/include/asm/cputable.h | 7 +++-
arch/powerpc/kernel/cputable.c | 4 +-
arch/powerpc/kernel/head_32.S | 61 +++++++++++++++++++++++++++++++++++
3 files changed, 69 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
index fca1611..42e3145 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -152,6 +152,7 @@ extern const char *powerpc_base_platform;
#define CPU_FTR_NAP_DISABLE_L2_PR ASM_CONST(0x0000000000002000)
#define CPU_FTR_DUAL_PLL_750FX ASM_CONST(0x0000000000004000)
#define CPU_FTR_NO_DPM ASM_CONST(0x0000000000008000)
+#define CPU_FTR_NEED_DTLB_SW_LRU ASM_CONST(0x0000000000010000)
#define CPU_FTR_NEED_COHERENT ASM_CONST(0x0000000000020000)
#define CPU_FTR_NO_BTIC ASM_CONST(0x0000000000040000)
#define CPU_FTR_NODSISRALIGN ASM_CONST(0x0000000000100000)
@@ -356,7 +357,11 @@ extern const char *powerpc_base_platform;
CPU_FTR_COMMON)
#define CPU_FTRS_E300C2 (CPU_FTR_MAYBE_CAN_DOZE | \
CPU_FTR_USE_TB | CPU_FTR_MAYBE_CAN_NAP | \
- CPU_FTR_COMMON | CPU_FTR_FPU_UNAVAILABLE)
+ CPU_FTR_COMMON | CPU_FTR_FPU_UNAVAILABLE | \
+ CPU_FTR_NEED_DTLB_SW_LRU)
+#define CPU_FTRS_E300C3 (CPU_FTR_MAYBE_CAN_DOZE | \
+ CPU_FTR_USE_TB | CPU_FTR_MAYBE_CAN_NAP | \
+ CPU_FTR_COMMON | CPU_FTR_NEED_DTLB_SW_LRU)
#define CPU_FTRS_CLASSIC32 (CPU_FTR_COMMON | CPU_FTR_USE_TB)
#define CPU_FTRS_8XX (CPU_FTR_USE_TB)
#define CPU_FTRS_40X (CPU_FTR_USE_TB | CPU_FTR_NODSISRALIGN | CPU_FTR_NOEXECUTE)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index ccea243..039452c 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1101,7 +1101,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
.pvr_mask = 0x7fff0000,
.pvr_value = 0x00850000,
.cpu_name = "e300c3",
- .cpu_features = CPU_FTRS_E300,
+ .cpu_features = CPU_FTRS_E300C3,
.cpu_user_features = COMMON_USER,
.mmu_features = MMU_FTR_USE_HIGH_BATS,
.icache_bsize = 32,
@@ -1116,7 +1116,7 @@ static struct cpu_spec __initdata cpu_specs[] = {
.pvr_mask = 0x7fff0000,
.pvr_value = 0x00860000,
.cpu_name = "e300c4",
- .cpu_features = CPU_FTRS_E300,
+ .cpu_features = CPU_FTRS_E300C3,
.cpu_user_features = COMMON_USER,
.mmu_features = MMU_FTR_USE_HIGH_BATS,
.icache_bsize = 32,
diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
index f8c2e6b..eecae0d 100644
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -554,6 +554,10 @@ DataLoadTLBMiss:
* r2: ptr to linux-style pte
* r3: scratch
*/
+BEGIN_FTR_SECTION
+ b TlbWo /* Code for TLB-errata workaround doesn't fit here */
+END_FTR_SECTION_IFSET(CPU_FTR_NEED_DTLB_SW_LRU)
+RFTlbWo:
mfctr r0
/* Get PTE (linux-style) and check access */
mfspr r3,SPRN_DMISS
@@ -626,6 +630,31 @@ DataStoreTLBMiss:
* r2: ptr to linux-style pte
* r3: scratch
*/
+BEGIN_FTR_SECTION
+/* MPC512x: workaround for errata in die M36P and earlier:
+ * Implement LRW for TLB way.
+ */
+ mfspr r3,SPRN_DMISS
+ rlwinm r3,r3,19,25,29 /* Get Address bits 19:15 */
+ lis r2,lrw@ha /* Search index in lrw[] */
+ addi r2,r2,lrw@l
+ tophys(r2,r2)
+ lwzx r1,r3,r2 /* Get item from lrw[] */
+ cmpwi 0,r1,0 /* Was it way 0 last time? */
+ beq- 0,113f /* Then goto 113: */
+
+ mfspr r1,SPRN_SRR1
+ rlwinm r1,r1,0,15,13 /* Mask out SRR1[WAY] */
+ mtspr SPRN_SRR1,r1
+
+ li r0,0
+ stwx r0,r3,r2 /* Make lrw[] entry 0 */
+ b 114f
+113:
+ li r0,1
+ stwx r0,r3,r2 /* Make lrw[] entry 1 */
+114:
+END_FTR_SECTION_IFSET(CPU_FTR_NEED_DTLB_SW_LRU)
mfctr r0
/* Get PTE (linux-style) and check access */
mfspr r3,SPRN_DMISS
@@ -813,6 +842,32 @@ giveup_altivec:
blr
#endif /* CONFIG_ALTIVEC */
+TlbWo:
+/* MPC512x: workaround for errata in die M36P and earlier:
+ * Implement LRW for TLB way.
+ */
+ mfspr r3,SPRN_DMISS
+ rlwinm r3,r3,19,25,29 /* Get Address bits 19:15 */
+ lis r2,lrw@ha /* Search index in lrw[] */
+ addi r2,r2,lrw@l
+ tophys(r2,r2)
+ lwzx r1,r3,r2 /* Get item from lrw[] */
+ cmpwi 0,r1,0 /* Was it way 0 last time? */
+ beq- 0,113f /* Then goto 113: */
+
+ mfspr r1,SPRN_SRR1
+ rlwinm r1,r1,0,15,13 /* Mask out SRR1[WAY] */
+ mtspr SPRN_SRR1,r1
+
+ li r0,0
+ stwx r0,r3,r2 /* Make lrw[] entry 0 */
+ b 114f
+113:
+ li r0,1
+ stwx r0,r3,r2 /* Make lrw[] entry 1 */
+114:
+ b RFTlbWo
+
/*
* This code is jumped to from the startup code to copy
* the kernel image to physical address PHYSICAL_START.
@@ -1328,6 +1383,12 @@ intercept_table:
.long 0, 0, 0, 0, 0, 0, 0, 0
.long 0, 0, 0, 0, 0, 0, 0, 0
+lrw:
+ .long 0, 0, 0, 0, 0, 0, 0, 0
+ .long 0, 0, 0, 0, 0, 0, 0, 0
+ .long 0, 0, 0, 0, 0, 0, 0, 0
+ .long 0, 0, 0, 0, 0, 0, 0, 0
+
/* Room for two PTE pointers, usually the kernel and current user pointers
* to their respective root page table.
*/
--
1.5.6.6
^ permalink raw reply related
* Re: [MPC8272ADS]Can not configure the ttyCPM0
From: Laurent Pinchart @ 2009-03-13 14:38 UTC (permalink / raw)
To: Jean-Michel Hautbois; +Cc: linuxppc-dev
In-Reply-To: <8cad0aa0903130720r25e8b7c1u3f762d9560535f5e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2658 bytes --]
Hi Jean-Michel,
On Friday 13 March 2009 15:20:24 Jean-Michel Hautbois wrote:
> 2009/3/13 Laurent Pinchart <laurentp@cse-semaphore.com>:
> > Support for the modem control lines has been added in v2.6.27-rc2. You
> > will need to declare the modem control lines in your device tree. See
> > Documentation/powerpc/dts-bindings/fsl/cpm_qe/serial.txt for more
> > information.
> >
> > Please note that hardware flow control is not supported by the CPM UART
> > driver yet.
>
> OK, this is not easy, to modify...
> My DTS already contains a configuration for the CPM1 port...
>
> serial@11a00 {
> device_type = "serial";
> compatible = "fsl,mpc8272-scc-uart",
> "fsl,cpm2-scc-uart";
> reg = <0x11a00 0x20 0x8000 0x100>;
> interrupts = <40 8>;
> interrupt-parent = <&PIC>;
> fsl,cpm-brg = <1>;
> fsl,cpm-command = <0x800000>;
> };
>
> serial@11a60 {
> device_type = "serial";
> compatible = "fsl,mpc8272-scc-uart",
> "fsl,cpm2-scc-uart";
> reg = <0x11a60 0x20 0x8300 0x100>;
> interrupts = <43 8>;
> interrupt-parent = <&PIC>;
> fsl,cpm-brg = <4>;
> fsl,cpm-command = <0xce0000>;
> };
>
> I can't see what I have to do...
> This is not obvious ;).
Here are excerpts of my device tree for an MPC8248 based platform.
You need to declare GPIO controllers for the pins used by modem control lines
cpm2_pio_c: gpio_controller@10d40 {
compatible = "fsl,mpc8248-pario-bank",
"fsl,cpm2-pario-bank";
reg = <0x10d40 0x14>;
#gpio-cells = <2>;
gpio-controller;
};
cpm2_pio_d: gpio_controller@10d60 {
compatible = "fsl,mpc8248-pario-bank",
"fsl,cpm2-pario-bank";
reg = <0x10d60 0x14>;
#gpio-cells = <2>;
gpio-controller;
};
and add the GPIO mapping in your serial port controller nodes
gpios = <&cpm2_pio_c 15 0 /* CTS */
&cpm2_pio_d 29 0 /* RTS */
&cpm2_pio_c 14 0 /* DCD */
0 /* DSR */
&cpm2_pio_d 20 0 /* DTR */
&cpm2_pio_c 8 0 /* RI */
>;
Don't forget to configure the pins (direction, special purpose, ...) in your
board-specific code.
--
Laurent Pinchart
CSE Semaphore Belgium
Waterloo Office Park
Building M
Dreve Richelle, 161
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [MPC8272ADS]Can not configure the ttyCPM0
From: Jean-Michel Hautbois @ 2009-03-13 14:20 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-dev
In-Reply-To: <200903131500.51446.laurentp@cse-semaphore.com>
2009/3/13 Laurent Pinchart <laurentp@cse-semaphore.com>:
> Hi Jean-Michel,
>
> Support for the modem control lines has been added in v2.6.27-rc2. You will
> need to declare the modem control lines in your device tree. See
> Documentation/powerpc/dts-bindings/fsl/cpm_qe/serial.txt for more information.
>
> Please note that hardware flow control is not supported by the CPM UART driver
> yet.
>
OK, this is not easy, to modify...
My DTS already contains a configuration for the CPM1 port...
serial@11a00 {
device_type = "serial";
compatible = "fsl,mpc8272-scc-uart",
"fsl,cpm2-scc-uart";
reg = <0x11a00 0x20 0x8000 0x100>;
interrupts = <40 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <1>;
fsl,cpm-command = <0x800000>;
};
serial@11a60 {
device_type = "serial";
compatible = "fsl,mpc8272-scc-uart",
"fsl,cpm2-scc-uart";
reg = <0x11a60 0x20 0x8300 0x100>;
interrupts = <43 8>;
interrupt-parent = <&PIC>;
fsl,cpm-brg = <4>;
fsl,cpm-command = <0xce0000>;
};
I can't see what I have to do...
This is not obvious ;).
JM
^ permalink raw reply
* Re: [RFC] [PATCH v2] MPC5121 TLB errata workaround
From: David Jander @ 2009-03-13 14:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras, Wolfgang Denk, Gunnar Von Boehn
In-Reply-To: <9223B51A-4340-4636-B1F8-6D49A5F8833A@kernel.crashing.org>
On Friday 13 March 2009 14:21:57 Kumar Gala wrote:
> >
>
> What does cat /proc/cpuinfo show on this board?
# cat /proc/cpuinfo
processor : 0
cpu : e300c4
clock : 400.000000MHz
revision : 1.0 (pvr 8086 2010)
bogomips : 99.84
timebase : 50000000
platform : MPC5121 Generic
> > +#ifdef CONFIG_PPC_MPC512x
> > +/* MPC512x: workaround for errata in die M36P and earlier:
> > + * Implement LRW for TLB way.
> > + */
>
> This errata impacts a number of cores and so we should make this a CPU
> feature fixup rather than #ifdef code.
It should impact only MPC5121e and probably MPC5123, but according to
Freescale no other processors that use this core...
Anyway, I'll try to investigate about how to write a "CPU feature fixup",
I've never done that before (If you could give me a hint?)
> > + mfspr r3,SPRN_DMISS
> > + rlwinm r3,r3,19,25,29 /* Get Address bits 19:15 */
> > + lis r2,lrw@ha /* Search index in lrw[] */
> > + addi r2,r2,lrw@l
> > + tophys(r2,r2)
> > + lwzx r1,r3,r2 /* Get item from lrw[] */
> > + cmpwi 0,r1,0 /* Was it way 0 last time? */
>
> Why not use a bit vector since we only need one bit of information.
> Additionally we can use a single SPRG at that point instead to keep
> track of the LRU information.
Sounds interesting. I am just learning my first steps in powerpc-assembly, so
please forgive if this is a little inefficient still. I'll try again next week.
Greetings,
--
David Jander
Protonic Holland.
^ permalink raw reply
* Re: [RFC] [PATCH v2] MPC5121 TLB errata workaround
From: David Jander @ 2009-03-13 14:16 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras, Wolfgang Denk, Gunnar Von Boehn
In-Reply-To: <34B75591-5E9D-4966-BE06-9F4E48ED31B2@kernel.crashing.org>
On Friday 13 March 2009 14:22:22 Kumar Gala wrote:
>
> On Mar 13, 2009, at 5:26 AM, David Jander wrote:
>
> >
> > Forgot to mention: The patch is based on denx git tree head
> > 'ads5121', but
> > it should apply without problem (some offset at most) to mainline.
> >
> > Best regards,
> >
>
> Out of interest did this version produce better performance on the
> benchmarks than your v1 version?
Some examples:
1.- mplayer -nosound -benchmark testfile.mpeg (a DVD-mpeg2 file):
No fix at all:
VC: 30.5s VO: 53.4s Sys:1.95s Total: 85.8s
First fix (force writes to way 0):
VC: 24.3s VO: 40.6s Sys:1.95s Total: 66.9s
Complete fix (implementing lrw):
VC: 23.1s VO: 31.5s Sys:1.03s Total: 55.6s
2.- prboom -timedemo doombench1 (where doombench1.lmp is prerecorded demo):
No fix at all: 14.1 fps
First fix (force writes to way 0): 16.7 fps
Complete fix (implementing lrw): 18.1 fps
3.- Synthetic and pathologic memcpy() benchmark:
No fix at all: 26 Mbyte/s
First fix (force writes to way 0): 160 MByte/s
Complete fix (implementing lrw): 163 MByte/s
Note, that this benchmark should't really show any difference between v1
and v2, since v1 is almost the best possible fix for copy's only.
Tell me if you know of some other interesting benchmarks to try.
Best regards,
--
David Jander
Protonic Holland.
^ permalink raw reply
* Re: [MPC8272ADS]Can not configure the ttyCPM0
From: Laurent Pinchart @ 2009-03-13 14:00 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jean-Michel Hautbois
In-Reply-To: <8cad0aa0903130638w6fab6299kcd23d92d4c2d0a8@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1406 bytes --]
Hi Jean-Michel,
On Friday 13 March 2009 14:38:55 Jean-Michel Hautbois wrote:
> Hi all !
>
> I am currently facing a big problem on my MPC8272ADS development board.
> I have tried to use the /dev/ttyCPM1 port in order to send data over
> the serial cable to another device.
>
> This is just not working but nothing is sent, my DTR signal is down:
> > cat /proc/tty/driver/ttyCPM
>
> 0: uart:CPM UART mmio:0xF0011A00 irq:40 tx:296 rx:0 RTS|CTS|DTR|DSR|CD
> 1: uart:CPM UART mmio:0xF0011A60 irq:43 tx:0 rx:0 CTS|DSR|CD
>
> So, I have tried to use the serial port /dev/ttyCPM0. It is
> successfully sending out my bytes, but I can't configure it !!
> When I am trying to use the tcsetattr() function, I don't have any
> error, but the signal is always the same (no effect, if you prefer).
>
> I have tried to disable the kernel console output, but it is not
> working, either...
Support for the modem control lines has been added in v2.6.27-rc2. You will
need to declare the modem control lines in your device tree. See
Documentation/powerpc/dts-bindings/fsl/cpm_qe/serial.txt for more information.
Please note that hardware flow control is not supported by the CPM UART driver
yet.
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Waterloo Office Park
Building M
Dreve Richelle, 161
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [MPC8272ADS]Can not configure the ttyCPM0
From: Jean-Michel Hautbois @ 2009-03-13 13:38 UTC (permalink / raw)
To: linuxppc-dev
Hi all !
I am currently facing a big problem on my MPC8272ADS development board.
I have tried to use the /dev/ttyCPM1 port in order to send data over
the serial cable to another device.
This is just not working but nothing is sent, my DTR signal is down:
> cat /proc/tty/driver/ttyCPM
0: uart:CPM UART mmio:0xF0011A00 irq:40 tx:296 rx:0 RTS|CTS|DTR|DSR|CD
1: uart:CPM UART mmio:0xF0011A60 irq:43 tx:0 rx:0 CTS|DSR|CD
So, I have tried to use the serial port /dev/ttyCPM0. It is
successfully sending out my bytes, but I can't configure it !!
When I am trying to use the tcsetattr() function, I don't have any
error, but the signal is always the same (no effect, if you prefer).
I have tried to disable the kernel console output, but it is not
working, either...
Can anyone help me ?
Thanks in advance !
Best Regards,
JM
^ permalink raw reply
* Re: [RFC] [PATCH v2] MPC5121 TLB errata workaround
From: Kumar Gala @ 2009-03-13 13:22 UTC (permalink / raw)
To: David Jander
Cc: linuxppc-dev, Paul Mackerras, Wolfgang Denk, Gunnar Von Boehn
In-Reply-To: <200903131126.28662.david.jander@protonic.nl>
On Mar 13, 2009, at 5:26 AM, David Jander wrote:
>
> Forgot to mention: The patch is based on denx git tree head
> 'ads5121', but
> it should apply without problem (some offset at most) to mainline.
>
> Best regards,
>
Out of interest did this version produce better performance on the
benchmarks than your v1 version?
- k
^ permalink raw reply
* Re: [RFC] [PATCH v2] MPC5121 TLB errata workaround
From: Kumar Gala @ 2009-03-13 13:21 UTC (permalink / raw)
To: David Jander
Cc: linuxppc-dev, Paul Mackerras, Wolfgang Denk, Gunnar Von Boehn
In-Reply-To: <200903131121.00077.david.jander@protonic.nl>
>
What does cat /proc/cpuinfo show on this board?
> +#ifdef CONFIG_PPC_MPC512x
> +/* MPC512x: workaround for errata in die M36P and earlier:
> + * Implement LRW for TLB way.
> + */
This errata impacts a number of cores and so we should make this a CPU
feature fixup rather than #ifdef code.
> + mfspr r3,SPRN_DMISS
> + rlwinm r3,r3,19,25,29 /* Get Address bits 19:15 */
> + lis r2,lrw@ha /* Search index in lrw[] */
> + addi r2,r2,lrw@l
> + tophys(r2,r2)
> + lwzx r1,r3,r2 /* Get item from lrw[] */
> + cmpwi 0,r1,0 /* Was it way 0 last time? */
Why not use a bit vector since we only need one bit of information.
Additionally we can use a single SPRG at that point instead to keep
track of the LRU information.
> + beq- 0,113f /* Then goto 113: */
> +
> + mfspr r1,SPRN_SRR1
> + rlwinm r1,r1,0,15,13 /* Mask out SRR1[WAY] */
> + mtspr SPRN_SRR1,r1
> +
> + li r0,0
> + stwx r0,r3,r2 /* Make lrw[] entry 0 */
> + b 114f
> +113:
> + li r0,1
> + stwx r0,r3,r2 /* Make lrw[] entry 1 */
> +114:
> +#endif
> mfctr r0
> /* Get PTE (linux-style) and check access */
> mfspr r3,SPRN_DMISS
> @@ -688,6 +717,34 @@ DataStoreTLBMiss:
> .globl mol_trampoline
> .set mol_trampoline, i0x2f00
>
> +#ifdef CONFIG_PPC_MPC512x
> +TlbWo:
> +/* MPC512x: workaround for errata in die M36P and earlier:
> + * Implement LRW for TLB way.
> + */
> + mfspr r3,SPRN_DMISS
> + rlwinm r3,r3,19,25,29 /* Get Address bits 19:15 */
> + lis r2,lrw@ha /* Search index in lrw[] */
> + addi r2,r2,lrw@l
> + tophys(r2,r2)
> + lwzx r1,r3,r2 /* Get item from lrw[] */
> + cmpwi 0,r1,0 /* Was it way 0 last time? */
> + beq- 0,113f /* Then goto 113: */
> +
> + mfspr r1,SPRN_SRR1
> + rlwinm r1,r1,0,15,13 /* Mask out SRR1[WAY] */
> + mtspr SPRN_SRR1,r1
> +
> + li r0,0
> + stwx r0,r3,r2 /* Make lrw[] entry 0 */
> + b 114f
> +113:
> + li r0,1
> + stwx r0,r3,r2 /* Make lrw[] entry 1 */
> +114:
> + b RFTlbWo
> +#endif
> +
> . = 0x3000
>
> AltiVecUnavailable:
> @@ -1321,6 +1378,14 @@ intercept_table:
> .long 0, 0, 0, 0, 0, 0, 0, 0
> .long 0, 0, 0, 0, 0, 0, 0, 0
> .long 0, 0, 0, 0, 0, 0, 0, 0
> +
> +#ifdef CONFIG_PPC_MPC512x
> +lrw:
> + .long 0, 0, 0, 0, 0, 0, 0, 0
> + .long 0, 0, 0, 0, 0, 0, 0, 0
> + .long 0, 0, 0, 0, 0, 0, 0, 0
> + .long 0, 0, 0, 0, 0, 0, 0, 0
> +#endif
>
> /* Room for two PTE pointers, usually the kernel and current user
> pointers
> * to their respective root page table.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] powerpc/86xx: Run sbc310 USB fixup code only on the appropriate platform.
From: Martyn Welch @ 2009-03-13 11:35 UTC (permalink / raw)
To: linuxppc-dev
Patch to limit NEC fixup to SBC310, following similar patch to SBC610 by Tony Breeds: 368a12117dd8abf6eaefa37c21ac313b517128b9
Signed-off-by: Martyn Welch <martyn.welch@gefanuc.com>
---
Hi Kumar,
The sbc310 patches have been added to your next tree. This patch is
needed to stop the same problem occuring as occured with the sbc610.
arch/powerpc/platforms/86xx/gef_sbc310.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/86xx/gef_sbc310.c b/arch/powerpc/platforms/86xx/gef_sbc310.c
index 0f20172..ba3ce43 100644
--- a/arch/powerpc/platforms/86xx/gef_sbc310.c
+++ b/arch/powerpc/platforms/86xx/gef_sbc310.c
@@ -153,6 +153,10 @@ static void __init gef_sbc310_nec_fixup(struct pci_dev *pdev)
{
unsigned int val;
+ /* Do not do the fixup on other platforms! */
+ if (!machine_is(gef_sbc310))
+ return;
+
printk(KERN_INFO "Running NEC uPD720101 Fixup\n");
/* Ensure only ports 1 & 2 are enabled */
^ permalink raw reply related
* Re: [RFC] [PATCH v2] MPC5121 TLB errata workaround
From: David Jander @ 2009-03-13 10:26 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, Wolfgang Denk, Gunnar Von Boehn
In-Reply-To: <200903131121.00077.david.jander@protonic.nl>
Forgot to mention: The patch is based on denx git tree head 'ads5121', but
it should apply without problem (some offset at most) to mainline.
Best regards,
--
David Jander
Protonic Holland.
^ permalink raw reply
* [RFC] [PATCH v2] MPC5121 TLB errata workaround
From: David Jander @ 2009-03-13 10:20 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, Wolfgang Denk, Gunnar Von Boehn
Complete workaround for DTLB errata in MPC5121e processors of die M36P and
older (all currently existing versions).
Due to the bug, the hardware-implemented LRU algorythm always goes to way 1 of
the TLB. This fix implements the proposed software workaround in form of a LRW table for chosing the TLB-way.
Signed-off-by: David Jander <david@protonic.nl>
---
arch/powerpc/kernel/head_32.S | 65 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 65 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
index 0f4fac5..a88b3aa 100644
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -540,6 +540,10 @@ DataLoadTLBMiss:
* r2: ptr to linux-style pte
* r3: scratch
*/
+#ifdef CONFIG_PPC_MPC512x
+ b TlbWo /* Code for TLB-errata workaround doesn't fit here */
+RFTlbWo:
+#endif
mfctr r0
/* Get PTE (linux-style) and check access */
mfspr r3,SPRN_DMISS
@@ -612,6 +616,31 @@ DataStoreTLBMiss:
* r2: ptr to linux-style pte
* r3: scratch
*/
+#ifdef CONFIG_PPC_MPC512x
+/* MPC512x: workaround for errata in die M36P and earlier:
+ * Implement LRW for TLB way.
+ */
+ mfspr r3,SPRN_DMISS
+ rlwinm r3,r3,19,25,29 /* Get Address bits 19:15 */
+ lis r2,lrw@ha /* Search index in lrw[] */
+ addi r2,r2,lrw@l
+ tophys(r2,r2)
+ lwzx r1,r3,r2 /* Get item from lrw[] */
+ cmpwi 0,r1,0 /* Was it way 0 last time? */
+ beq- 0,113f /* Then goto 113: */
+
+ mfspr r1,SPRN_SRR1
+ rlwinm r1,r1,0,15,13 /* Mask out SRR1[WAY] */
+ mtspr SPRN_SRR1,r1
+
+ li r0,0
+ stwx r0,r3,r2 /* Make lrw[] entry 0 */
+ b 114f
+113:
+ li r0,1
+ stwx r0,r3,r2 /* Make lrw[] entry 1 */
+114:
+#endif
mfctr r0
/* Get PTE (linux-style) and check access */
mfspr r3,SPRN_DMISS
@@ -688,6 +717,34 @@ DataStoreTLBMiss:
.globl mol_trampoline
.set mol_trampoline, i0x2f00
+#ifdef CONFIG_PPC_MPC512x
+TlbWo:
+/* MPC512x: workaround for errata in die M36P and earlier:
+ * Implement LRW for TLB way.
+ */
+ mfspr r3,SPRN_DMISS
+ rlwinm r3,r3,19,25,29 /* Get Address bits 19:15 */
+ lis r2,lrw@ha /* Search index in lrw[] */
+ addi r2,r2,lrw@l
+ tophys(r2,r2)
+ lwzx r1,r3,r2 /* Get item from lrw[] */
+ cmpwi 0,r1,0 /* Was it way 0 last time? */
+ beq- 0,113f /* Then goto 113: */
+
+ mfspr r1,SPRN_SRR1
+ rlwinm r1,r1,0,15,13 /* Mask out SRR1[WAY] */
+ mtspr SPRN_SRR1,r1
+
+ li r0,0
+ stwx r0,r3,r2 /* Make lrw[] entry 0 */
+ b 114f
+113:
+ li r0,1
+ stwx r0,r3,r2 /* Make lrw[] entry 1 */
+114:
+ b RFTlbWo
+#endif
+
. = 0x3000
AltiVecUnavailable:
@@ -1321,6 +1378,14 @@ intercept_table:
.long 0, 0, 0, 0, 0, 0, 0, 0
.long 0, 0, 0, 0, 0, 0, 0, 0
.long 0, 0, 0, 0, 0, 0, 0, 0
+
+#ifdef CONFIG_PPC_MPC512x
+lrw:
+ .long 0, 0, 0, 0, 0, 0, 0, 0
+ .long 0, 0, 0, 0, 0, 0, 0, 0
+ .long 0, 0, 0, 0, 0, 0, 0, 0
+ .long 0, 0, 0, 0, 0, 0, 0, 0
+#endif
/* Room for two PTE pointers, usually the kernel and current user pointers
* to their respective root page table.
^ permalink raw reply related
* Re: [PATCH] powerpc: Remove extra semicolon in fsl_soc.c
From: Greg KH @ 2009-03-13 6:03 UTC (permalink / raw)
To: Grant Likely; +Cc: afleming, Greg KH, Johns Daniel, stable, linuxppc-dev
In-Reply-To: <fa686aa40903110903h1077860dt45c1a5aecd2ef42f@mail.gmail.com>
On Wed, Mar 11, 2009 at 10:03:22AM -0600, Grant Likely wrote:
> On Wed, Mar 11, 2009 at 9:50 AM, Johns Daniel <johns.daniel@gmail.com> wrote:
> > A semicolon at the end of the macro means that the for loop has an
> > empty body, and so TSEC/MDIO will not work with older device trees.
> >
> > This fix only applies to 2.6.28; apparently, this code is gone for
> > 2.6.29, according to Grant Likely!
> >
> > Signed-off-by: Johns Daniel <johns.daniel@gmail.com>
>
> Acked-by: Grant Likely <grant.likely@secretlab.ca>
>
> Greg: Andy Flemming should probably confirm this, but I think this
> one should be backported to the stable series.
Hm, this patch is line-wrapped and tabs are stripped, so I can't apply
it :(
Anyone care to resend it?
thanks,
greg k-h
> > ---
> > --- linux-2.6.28.7/arch/powerpc/sysdev/fsl_soc.c.orig 2009-02-20
> > 16:41:27.000000000 -0600
> > +++ linux-2.6.28.7/arch/powerpc/sysdev/fsl_soc.c 2009-03-10
> > 15:56:47.000000000 -0500
> > @@ -257,7 +257,7 @@
> > gfar_mdio_of_init_one(np);
> >
> > /* try the deprecated version */
> > - for_each_compatible_node(np, "mdio", "gianfar");
> > + for_each_compatible_node(np, "mdio", "gianfar")
> > gfar_mdio_of_init_one(np);
> >
> > return 0;
> > ---
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
>
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH 2/2] powerpc: Turn on self-tests in ppc64_defconfig
From: Michael Ellerman @ 2009-03-13 5:52 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <fc1755dacb01bff52fcf77ee18c4d7a075b01c37.1236923542.git.michael@ellerman.id.au>
Most of the code enabled by these options is __init, and it's much
more useful to actually run the tests.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/configs/ppc64_defconfig | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/configs/ppc64_defconfig b/arch/powerpc/configs/ppc64_defconfig
index 88c6295..2524018 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -2067,9 +2067,9 @@ CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_DEBUG_STACK_USAGE=y
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_HCALL_STATS is not set
-# CONFIG_CODE_PATCHING_SELFTEST is not set
-# CONFIG_FTR_FIXUP_SELFTEST is not set
-# CONFIG_MSI_BITMAP_SELFTEST is not set
+CONFIG_CODE_PATCHING_SELFTEST=y
+CONFIG_FTR_FIXUP_SELFTEST=y
+CONFIG_MSI_BITMAP_SELFTEST=y
CONFIG_XMON=y
# CONFIG_XMON_DEFAULT is not set
CONFIG_XMON_DISASSEMBLY=y
--
1.6.1.2
^ permalink raw reply related
* [PATCH 1/2] powerpc/msi: Mark the MSI bitmap selftest code as __init
From: Michael Ellerman @ 2009-03-13 5:52 UTC (permalink / raw)
To: linuxppc-dev
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/sysdev/msi_bitmap.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/sysdev/msi_bitmap.c b/arch/powerpc/sysdev/msi_bitmap.c
index f84217b..5a32cbe 100644
--- a/arch/powerpc/sysdev/msi_bitmap.c
+++ b/arch/powerpc/sysdev/msi_bitmap.c
@@ -141,7 +141,7 @@ void msi_bitmap_free(struct msi_bitmap *bmp)
#define check(x) \
if (!(x)) printk("msi_bitmap: test failed at line %d\n", __LINE__);
-void test_basics(void)
+void __init test_basics(void)
{
struct msi_bitmap bmp;
int i, size = 512;
@@ -186,7 +186,7 @@ void test_basics(void)
kfree(bmp.bitmap);
}
-void test_of_node(void)
+void __init test_of_node(void)
{
u32 prop_data[] = { 10, 10, 25, 3, 40, 1, 100, 100, 200, 20 };
const char *expected_str = "0-9,20-24,28-39,41-99,220-255";
@@ -234,7 +234,7 @@ void test_of_node(void)
kfree(bmp.bitmap);
}
-int msi_bitmap_selftest(void)
+int __init msi_bitmap_selftest(void)
{
printk(KERN_DEBUG "Running MSI bitmap self-tests ...\n");
--
1.6.1.2
^ permalink raw reply related
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2009-03-13 5:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
So here's the new ps3 nvram driver for 2.6.29 that we discussed earlier
Cheers,
Ben.
The following changes since commit 9ead64974b05501bbac0d63a47c99fa786d064ba:
Linus Torvalds (1):
Merge git://git.kernel.org/.../sam/kbuild-fixes
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Geert Uytterhoeven (1):
ps3/block: Replace mtd/ps3vram by block/ps3vram
arch/powerpc/platforms/ps3/Kconfig | 7 +
drivers/block/Makefile | 1 +
drivers/block/ps3vram.c | 865 ++++++++++++++++++++++++++++++++++++
drivers/mtd/devices/Kconfig | 7 -
drivers/mtd/devices/Makefile | 1 -
drivers/mtd/devices/ps3vram.c | 768 --------------------------------
6 files changed, 873 insertions(+), 776 deletions(-)
create mode 100644 drivers/block/ps3vram.c
delete mode 100644 drivers/mtd/devices/ps3vram.c
^ permalink raw reply
* Re: [PATCH 0/7] Generic RTC class driver
From: Kyle McMartin @ 2009-03-13 4:25 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-m68k, Alessandro Zummo, linux-parisc, rtc-linux, Paul Mundt,
Linux Kernel Development, Kyle McMartin, Linux/PPC Development,
Kyle McMartin, Dann Frazier
In-Reply-To: <alpine.LRH.2.00.0903111825040.1040@vixen.sonytel.be>
On Wed, Mar 11, 2009 at 06:26:12PM +0100, Geert Uytterhoeven wrote:
> Hi Kyle,
>
> On Wed, 11 Mar 2009, Kyle McMartin wrote:
> > On Wed, Mar 11, 2009 at 11:36:02AM +0100, Geert Uytterhoeven wrote:
> > > Is it OK for you to take it through your PA-RISC tree?
> > > If yes, I can resend the patch series with the collected acks.
> >
> > That's fine with me, just hit me up with a git tree address and I'll
> > suck it all into the rtc-parisc tree?
>
> I put it up at:
>
> master.kernel.org:/pub/scm/linux/kernel/git/geert/linux-rtc-generic.git
>
> The master branch should be a descendant of your rtc-parisc branch.
>
> Thanks!
>
Great, thanks Geert!
I've pulled it and pushed it back out, I'll submit it when the merge
window opens.
cheers, Kyle
^ permalink raw reply
* Re: [PATCH 1/3] powerpc: bare minimum checkpoint/restart implementation
From: Oren Laadan @ 2009-03-13 3:31 UTC (permalink / raw)
To: Nathan Lynch; +Cc: containers, linuxppc-dev
In-Reply-To: <20090217010355.58afd5cf@thinkcentre.lan>
Nathan Lynch wrote:
> Nathan Lynch <ntl@pobox.com> wrote:
>> Oren Laadan wrote:
>>> Nathan Lynch wrote:
>>>> What doesn't work:
>>>> * restarting a 32-bit task from a 64-bit task and vice versa
>>> Is there a test to bail if we attempt to checkpoint such tasks ?
>> No, but I'll add one if it looks too hard to fix for the next round.
>
> Unfortunately, adding a check for this is hard.
>
> The "point of no return" in the restart path is cr_read_mm, which tears
> down current's address space. cr_read_mm runs way before cr_read_cpu,
> which is the only restart method I've implemented for powerpc so far.
> So, checking for this condition in cr_read_cpu is too late if I want
> restart(2) to return an error and leave the caller's memory map
> intact. (And I do want this: restart should be as robust as execve.)
In the case of restarting a container, I think it's ok if a restarting
tasks dies in an "ugly" way -- this will be observed and handled by the
initiating task outside the container, which will gracefully report to
the caller/user.
Even if you close this hole, then any other failure later on during
restart - even a failure to allocate kernel memory due to memory pressure,
will give that undesired effect that you are trying to avoid.
That said, any difference in the architecture that may cause restart to
fail is probably best placed in cr_write_head_arch.
>
> Well okay then, cr_read_head_arch seems to be the right place in the
> restart sequence for the architecture code to handle this. However,
> cr_write_head_arch (which produces the buffer that cr_read_head_arch
> consumes) is not provided a reference to the task to be checkpointed,
> nor can it assume that it's operating on current. I need a reference
> to a task before I can determine whether it's running in 32- or 64-bit
> mode, or using the FPU, Altivec, SPE, whatever.
>
> In any case, mixing 32- and 64-bit tasks across restart is something I
> eventually want to support, not reject. But the problem I've outlined
> applies to FPU state and vector extensions (VMX, SPE), as well as
> sanity-checking debug register (DABR) contents. We'll need to be able
> to error out gracefully from restart when a checkpoint image specifies a
> feature unsupported by the current kernel or hardware. But I don't see
> how to do it with the current architecture. Am I missing something?
>
More specifically, I envision restart to work like this:
1) user invokes user-land utility (e.g. "cr --restart ..."
2) 'cr' will create a new container
3) 'cr' will start a child in that container
4) child will create rest of tree (in kernel or in user space - tbd)
5) each task in that tree will restore itself
6) 'cr' monitors this process
7) if all goes well - 'cr' report ok.
8) if something goes bad, 'cr' notices and notifies caller/user
so tasks that are restarting may just as well die badly - we don't care.
Does that make sense ?
Oren.
^ permalink raw reply
* Re: [PATCH 4/9] powerpc/mm: Tweak PTE bit combination definitions (v2)
From: Michael Ellerman @ 2009-03-13 3:44 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <20090311035335.5899BDE1A6@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 1682 bytes --]
On Wed, 2009-03-11 at 14:53 +1100, Benjamin Herrenschmidt wrote:
> This patch tweaks the way some PTE bit combinations are defined, in such a
> way that the 32 and 64-bit variant become almost identical and that will
> make it easier to bring in a new common pte-* file for the new variant
> of the Book3-E support.
>
<snip>
> +/* Permission masks used to generate the __P and __S table,
> + *
> + * Note:__pgprot is defined in arch/powerpc/include/asm/page.h
> + */
> +#define PAGE_NONE __pgprot(_PAGE_BASE)
> +#define PAGE_SHARED __pgprot(_PAGE_BASE | _PAGE_USER | _PAGE_RW)
> +#define PAGE_SHARED_X __pgprot(_PAGE_BASE | _PAGE_USER | _PAGE_RW | _PAGE_EXEC)
> #define PAGE_COPY __pgprot(_PAGE_BASE | _PAGE_USER)
> #define PAGE_COPY_X __pgprot(_PAGE_BASE | _PAGE_USER | _PAGE_EXEC)
> #define PAGE_READONLY __pgprot(_PAGE_BASE | _PAGE_USER)
> #define PAGE_READONLY_X __pgprot(_PAGE_BASE | _PAGE_USER | _PAGE_EXEC)
> -#define PAGE_KERNEL __pgprot(_PAGE_BASE | _PAGE_WRENABLE)
> -#define PAGE_KERNEL_CI __pgprot(_PAGE_PRESENT | _PAGE_ACCESSED | \
> - _PAGE_WRENABLE | _PAGE_NO_CACHE | _PAGE_GUARDED)
> -#define PAGE_KERNEL_EXEC __pgprot(_PAGE_BASE | _PAGE_WRENABLE | _PAGE_EXEC)
Generic code needs PAGE_KERNEL_EXEC:
mm/vmalloc.c:
#ifndef PAGE_KERNEL_EXEC
# define PAGE_KERNEL_EXEC PAGE_KERNEL
#endif
Not having it breaks modules because we don't map the text executable.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] powerpc: bare minimum checkpoint/restart implementation
From: Oren Laadan @ 2009-03-13 3:36 UTC (permalink / raw)
To: Nathan Lynch; +Cc: containers, Serge E. Hallyn, linuxppc-dev
In-Reply-To: <20090224151152.29e98b5f@thinkcentre.lan>
Nathan Lynch wrote:
> On Tue, 24 Feb 2009 13:58:26 -0600
> "Serge E. Hallyn" <serue@us.ibm.com> wrote:
>
>> Quoting Nathan Lynch (ntl@pobox.com):
>>> Nathan Lynch <ntl@pobox.com> wrote:
>>>> Oren Laadan wrote:
>>>>> Nathan Lynch wrote:
>>>>>> What doesn't work:
>>>>>> * restarting a 32-bit task from a 64-bit task and vice versa
>>>>> Is there a test to bail if we attempt to checkpoint such tasks ?
>>>> No, but I'll add one if it looks too hard to fix for the next round.
>>> Unfortunately, adding a check for this is hard.
>>>
>>> The "point of no return" in the restart path is cr_read_mm, which tears
>>> down current's address space. cr_read_mm runs way before cr_read_cpu,
>>> which is the only restart method I've implemented for powerpc so far.
>>> So, checking for this condition in cr_read_cpu is too late if I want
>>> restart(2) to return an error and leave the caller's memory map
>>> intact. (And I do want this: restart should be as robust as execve.)
>>>
>>> Well okay then, cr_read_head_arch seems to be the right place in the
>>> restart sequence for the architecture code to handle this. However,
>>> cr_write_head_arch (which produces the buffer that cr_read_head_arch
>>> consumes) is not provided a reference to the task to be checkpointed,
>>> nor can it assume that it's operating on current. I need a reference
>>> to a task before I can determine whether it's running in 32- or 64-bit
>>> mode, or using the FPU, Altivec, SPE, whatever.
>>>
>>> In any case, mixing 32- and 64-bit tasks across restart is something I
>>> eventually want to support, not reject. But the problem I've outlined
>>> applies to FPU state and vector extensions (VMX, SPE), as well as
>>> sanity-checking debug register (DABR) contents. We'll need to be able
>>> to error out gracefully from restart when a checkpoint image specifies a
>>> feature unsupported by the current kernel or hardware. But I don't see
>>> how to do it with the current architecture. Am I missing something?
>> I suspect I can guess the response to this suggestion, but how about we
>> accept that if sys_restart() fails due to something like this, the
>> task is lost and can't exit gracefully?
>
> In the short term it might be necessary. But the restart code should
> forcibly kill the task instead of returning an error back up to
> userspace in this case. Once the memory map of the process has been
> altered, there is no point in allowing it to continue (and likely dump
> a useless core). Btw, this failure mode seems to apply when
> cr_read_files() fails, too...
>
> But in the long term, things need to be more robust (e.g. restart(2)
> returns ENOEXEC without messing with current->mm). I think it's worth
> looking at how execve operates... if I understand correctly, it sets up
> a new mm_struct disconnected from the current task and activates it at
> the last moment.
>
That's a good idea, and I have considered it in the past.
However, it is easier to restarti a task in its own, new, context,
including the MM. For instance, you can leverage all memory syscalls.
An in-between way would be to switch to the new MM but not tear down
the original one, but rather save it along side. If a failure occur -
restore it.
Then, you'll have to ask the same question about all other resources -
signal handlers, open files, etc. Either you make all changes atomic
at once, or none - if you want the operation to be non-intrusive in
the case of an error.
However, I do think that this is not necessary: the tasks that are
doing the restart have been created from scratch for that purpose,
so they need not return any specific value to the user. It is the
task that initiates the restart that needs to handle error gracefully.
The scheme I proposed in the previous email does exactly that.
(This does not apply to self-restart, for obvious reasons, but that
is a special case anyway).
Oren.
^ permalink raw reply
* Confused about CLOCK_TICK_RATE
From: Timur Tabi @ 2009-03-12 19:01 UTC (permalink / raw)
To: linuxppc-dev
Can someone explain CLOCK_TICK_RATE to me? It's defined in
arch/powerpc/include/asm/timex.h as such:
#define CLOCK_TICK_RATE 1024000 /* Underlying HZ */
Every architecture defines this, but some use the better comment
"Underlying frequency of the HZ timer".
My question is: why is this a constant? Shouldn't it be a variable,
perhaps something that is based on tb_ticks_per_usec?
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* SLAB vs SLUB vs SLOB
From: Sean MacLennan @ 2009-03-12 16:33 UTC (permalink / raw)
To: linuxppc-dev
Any advantages on the PPC of using SLUB or SLOB over SLAB? I am
especially interested in memory savings.
Cheers,
Sean
^ permalink raw reply
* [PATCH net-next-2.6] ehea: fix circular locking problem
From: Jan-Bernd Themann @ 2009-03-12 15:20 UTC (permalink / raw)
To: David Miller
Cc: tklein, Hannes Hering, netdev, themann, linux-kernel,
linuxppc-dev, raisch
This patch fixes the circular locking problem by changing the locking strategy
concerning the logging of firmware handles.
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
---
drivers/net/ehea/ehea.h | 2 +-
drivers/net/ehea/ehea_main.c | 56 ++++++++++++++++++++++-------------------
2 files changed, 31 insertions(+), 27 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index 029631c..6e317ca 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -40,7 +40,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0099"
+#define DRV_VERSION "EHEA_0100"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 40c34bf..ac0c5b4 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -155,6 +155,8 @@ static void ehea_update_firmware_handles(void)
int num_fw_handles, k, l;
/* Determine number of handles */
+ mutex_lock(&ehea_fw_handles.lock);
+
list_for_each_entry(adapter, &adapter_list, list) {
num_adapters++;
@@ -176,15 +178,19 @@ static void ehea_update_firmware_handles(void)
if (num_fw_handles) {
arr = kzalloc(num_fw_handles * sizeof(*arr), GFP_KERNEL);
if (!arr)
- return; /* Keep the existing array */
+ goto out; /* Keep the existing array */
} else
goto out_update;
list_for_each_entry(adapter, &adapter_list, list) {
+ if (num_adapters == 0)
+ break;
+
for (k = 0; k < EHEA_MAX_PORTS; k++) {
struct ehea_port *port = adapter->port[k];
- if (!port || (port->state != EHEA_PORT_UP))
+ if (!port || (port->state != EHEA_PORT_UP)
+ || (num_ports == 0))
continue;
for (l = 0;
@@ -207,6 +213,7 @@ static void ehea_update_firmware_handles(void)
}
arr[i].adh = adapter->handle;
arr[i++].fwh = port->qp_eq->fw_handle;
+ num_ports--;
}
arr[i].adh = adapter->handle;
@@ -216,16 +223,20 @@ static void ehea_update_firmware_handles(void)
arr[i].adh = adapter->handle;
arr[i++].fwh = adapter->mr.handle;
}
+ num_adapters--;
}
out_update:
kfree(ehea_fw_handles.arr);
ehea_fw_handles.arr = arr;
ehea_fw_handles.num_entries = i;
+out:
+ mutex_unlock(&ehea_fw_handles.lock);
}
static void ehea_update_bcmc_registrations(void)
{
+ unsigned long flags;
struct ehea_bcmc_reg_entry *arr = NULL;
struct ehea_adapter *adapter;
struct ehea_mc_list *mc_entry;
@@ -233,6 +244,8 @@ static void ehea_update_bcmc_registrations(void)
int i = 0;
int k;
+ spin_lock_irqsave(&ehea_bcmc_regs.lock, flags);
+
/* Determine number of registrations */
list_for_each_entry(adapter, &adapter_list, list)
for (k = 0; k < EHEA_MAX_PORTS; k++) {
@@ -250,7 +263,7 @@ static void ehea_update_bcmc_registrations(void)
if (num_registrations) {
arr = kzalloc(num_registrations * sizeof(*arr), GFP_ATOMIC);
if (!arr)
- return; /* Keep the existing array */
+ goto out; /* Keep the existing array */
} else
goto out_update;
@@ -261,6 +274,9 @@ static void ehea_update_bcmc_registrations(void)
if (!port || (port->state != EHEA_PORT_UP))
continue;
+ if (num_registrations == 0)
+ goto out_update;
+
arr[i].adh = adapter->handle;
arr[i].port_id = port->logical_port_id;
arr[i].reg_type = EHEA_BCMC_BROADCAST |
@@ -272,9 +288,13 @@ static void ehea_update_bcmc_registrations(void)
arr[i].reg_type = EHEA_BCMC_BROADCAST |
EHEA_BCMC_VLANID_ALL;
arr[i++].macaddr = port->mac_addr;
+ num_registrations -= 2;
list_for_each_entry(mc_entry,
&port->mc_list->list, list) {
+ if (num_registrations == 0)
+ goto out_update;
+
arr[i].adh = adapter->handle;
arr[i].port_id = port->logical_port_id;
arr[i].reg_type = EHEA_BCMC_SCOPE_ALL |
@@ -288,6 +308,7 @@ static void ehea_update_bcmc_registrations(void)
EHEA_BCMC_MULTICAST |
EHEA_BCMC_VLANID_ALL;
arr[i++].macaddr = mc_entry->macaddr;
+ num_registrations -= 2;
}
}
}
@@ -296,6 +317,8 @@ out_update:
kfree(ehea_bcmc_regs.arr);
ehea_bcmc_regs.arr = arr;
ehea_bcmc_regs.num_entries = i;
+out:
+ spin_unlock_irqrestore(&ehea_bcmc_regs.lock, flags);
}
static struct net_device_stats *ehea_get_stats(struct net_device *dev)
@@ -1762,8 +1785,6 @@ static int ehea_set_mac_addr(struct net_device *dev, void *sa)
memcpy(dev->dev_addr, mac_addr->sa_data, dev->addr_len);
- spin_lock(&ehea_bcmc_regs.lock);
-
/* Deregister old MAC in pHYP */
if (port->state == EHEA_PORT_UP) {
ret = ehea_broadcast_reg_helper(port, H_DEREG_BCMC);
@@ -1784,7 +1805,6 @@ static int ehea_set_mac_addr(struct net_device *dev, void *sa)
out_upregs:
ehea_update_bcmc_registrations();
- spin_unlock(&ehea_bcmc_regs.lock);
out_free:
free_page((unsigned long)cb0);
out:
@@ -1946,8 +1966,6 @@ static void ehea_set_multicast_list(struct net_device *dev)
}
ehea_promiscuous(dev, 0);
- spin_lock(&ehea_bcmc_regs.lock);
-
if (dev->flags & IFF_ALLMULTI) {
ehea_allmulti(dev, 1);
goto out;
@@ -1977,7 +1995,6 @@ static void ehea_set_multicast_list(struct net_device *dev)
}
out:
ehea_update_bcmc_registrations();
- spin_unlock(&ehea_bcmc_regs.lock);
return;
}
@@ -2458,8 +2475,6 @@ static int ehea_up(struct net_device *dev)
if (port->state == EHEA_PORT_UP)
return 0;
- mutex_lock(&ehea_fw_handles.lock);
-
ret = ehea_port_res_setup(port, port->num_def_qps,
port->num_add_tx_qps);
if (ret) {
@@ -2496,8 +2511,6 @@ static int ehea_up(struct net_device *dev)
}
}
- spin_lock(&ehea_bcmc_regs.lock);
-
ret = ehea_broadcast_reg_helper(port, H_REG_BCMC);
if (ret) {
ret = -EIO;
@@ -2519,10 +2532,7 @@ out:
ehea_info("Failed starting %s. ret=%i", dev->name, ret);
ehea_update_bcmc_registrations();
- spin_unlock(&ehea_bcmc_regs.lock);
-
ehea_update_firmware_handles();
- mutex_unlock(&ehea_fw_handles.lock);
return ret;
}
@@ -2572,9 +2582,6 @@ static int ehea_down(struct net_device *dev)
if (port->state == EHEA_PORT_DOWN)
return 0;
- mutex_lock(&ehea_fw_handles.lock);
-
- spin_lock(&ehea_bcmc_regs.lock);
ehea_drop_multicast_list(dev);
ehea_broadcast_reg_helper(port, H_DEREG_BCMC);
@@ -2583,7 +2590,6 @@ static int ehea_down(struct net_device *dev)
port->state = EHEA_PORT_DOWN;
ehea_update_bcmc_registrations();
- spin_unlock(&ehea_bcmc_regs.lock);
ret = ehea_clean_all_portres(port);
if (ret)
@@ -2591,7 +2597,6 @@ static int ehea_down(struct net_device *dev)
dev->name, ret);
ehea_update_firmware_handles();
- mutex_unlock(&ehea_fw_handles.lock);
return ret;
}
@@ -3368,7 +3373,6 @@ static int __devinit ehea_probe_adapter(struct of_device *dev,
ehea_error("Invalid ibmebus device probed");
return -EINVAL;
}
- mutex_lock(&ehea_fw_handles.lock);
adapter = kzalloc(sizeof(*adapter), GFP_KERNEL);
if (!adapter) {
@@ -3453,7 +3457,7 @@ out_free_ad:
out:
ehea_update_firmware_handles();
- mutex_unlock(&ehea_fw_handles.lock);
+
return ret;
}
@@ -3472,8 +3476,6 @@ static int __devexit ehea_remove(struct of_device *dev)
flush_scheduled_work();
- mutex_lock(&ehea_fw_handles.lock);
-
ibmebus_free_irq(adapter->neq->attr.ist1, adapter);
tasklet_kill(&adapter->neq_tasklet);
@@ -3483,7 +3485,6 @@ static int __devexit ehea_remove(struct of_device *dev)
kfree(adapter);
ehea_update_firmware_handles();
- mutex_unlock(&ehea_fw_handles.lock);
return 0;
}
@@ -3532,6 +3533,9 @@ static int ehea_mem_notifier(struct notifier_block *nb,
default:
break;
}
+
+ ehea_update_firmware_handles();
+
return NOTIFY_OK;
}
--
1.5.5
^ permalink raw reply related
* RE: DTS device tree node for dual port RAM
From: EXTERNAL Lange Matthias (AA-DGW/ENG1) @ 2009-03-12 15:19 UTC (permalink / raw)
To: EXTERNAL Lange Matthias (AA-DGW/ENG1); +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <fa686aa40903120632yb46c34bxdecf21f01996bf42@mail.gmail.com>
> -----Original Message-----
> From:
> linuxppc-dev-bounces+matthias.lange=3Dbeissbarth.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+matthias.lange=3Dbeissbarth.com@ozl
> abs.org] On Behalf Of Grant Likely
> Sent: Thursday, March 12, 2009 2:32 PM
> To: EXTERNAL Lange Matthias (AA-DGW/ENG1)
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: DTS device tree node for dual port RAM
>
> On Thu, Mar 12, 2009 at 5:24 AM, EXTERNAL Lange Matthias (AA-DGW/ENG1)
> <Matthias.Lange@beissbarth.com> wrote:
> > Hi,
[...]
>
> > interrupts =3D <0 0 0>;
>
> What hardware irq# are you using? See this link for a description of
> what the interrupts property should look like for external IRQs:
I am using hardware irq# 0 which is wired to the critical input line. That'=
s why I was defining the interrupts property to <0 0 0>. So my device tree =
node now looks like this
dpram@40000000 {
compatible =3D "beissbarth,orion-dpram";
interrupts =3D <0 0 0>;
interrupt-parent =3D <&mpc5200_pic>;
};
If I am understanding it correctly I now need to implement a OF platform dr=
iver in which I can use irq_of_parse_and_map() to get the virq for my devic=
e.
Regards,
Matthias Lange.
>
> http://patchwork.ozlabs.org/patch/11349/
>
> To use this property, the irq_of_parse_and_map() function will
> translate from the device tree to a Linux IRQ number.
>
> > interrupt-parent =3D <&mpc5200_pic>;
>
> You probably also want a reg =3D <0 0 0x00400000>; property for mapping
> the address range.
>
> > };
> > };
> >
> > What am I doing wrong? What am I missing?
> >
> > Thanks,
> > Matthias Lange.
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
>
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
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