* RE: Keep On Debugging You
From: Zhang Wei-r63237 @ 2007-09-06 2:59 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <46DE1A36.3010300@tabi.org>
Oops!
Could you give us a live show version? :D =20
Cheers!
- zw
> -----Original Message-----
> From: linuxppc-dev-bounces+wei.zhang=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+wei.zhang=3Dfreescale.com@ozlabs.or
> g] On Behalf Of Timur Tabi
> Sent: Wednesday, September 05, 2007 10:54 AM
> To: linuxppc-dev@ozlabs.org
> Subject: Keep On Debugging You
>=20
> I wrote this last year in frustration with an out-of-order=20
> execution bug=20
> I was trying to fix.
>=20
>=20
> Keep On Debugging You
> Sung to the tune of REO Speedwagon's "Keep on Loving' You"
>=20
> You should've seen by the opcodes in the queue, baby
> There was something missin'
> You should known by the registers, too, maybe
> But you were too busy bitchin'
> You stalled ahead
> But you never fed
> Instead my instructions
> All ended up switchin'
>=20
> And though I know all flushes
> Still I don't remember
> Cause it was stwu way before lwzu
> And they're still together
> And I meant every line I wrote
> When I wrote them in order I meant
> That I wanted them in order
>=20
> And I'm gonna keep on debugging you
> Cause it's the only thing I'm paid to do
> I don't have time to sleep
> I just want to keep on debugging you
>=20
> (solo)
>=20
> And I meant every line I wrote
> When I wrote them in order I meant
> That I wanted them in order
>=20
> (chorus)
>=20
>=20
> --=20
> Timur Tabi
>=20
^ permalink raw reply
* Gianfar - MPC8541 - tx buffer overrun errors
From: Shriram Janardhan @ 2007-09-06 1:48 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 765 bytes --]
All,
I am running 2.6.11 version of the kernel on MPC8541. Have one of the TSECs configured at 100Mbps/Full Duplex. The TSEC MAC is connected to a Marvell Ethernet switch MAC without any PHY in between. MAC level flow control is enabled but no pause frames sent or received.
I see a high number of transmit buffer overrun errors (tx_fifo_empty errors in the gianfar driver). I don't have NAPI enabled. In addition to other things, I was thinking of enabling NAPI and see if it helps - is there any downside to it?? Are there any other parameters that I could tweak to reduce/eliminate the overrun errors??
Thanks,
Shriram.
---------------------------------
Got a little couch potato?
Check out fun summer activities for kids.
[-- Attachment #2: Type: text/html, Size: 1026 bytes --]
^ permalink raw reply
* Re: [PATCH] PowerPC: Add 64-bit resources support to pci_iomap
From: David Gibson @ 2007-09-06 1:27 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20070905173016.GA27771@ru.mvista.com>
On Wed, Sep 05, 2007 at 09:30:16PM +0400, Valentine Barshak wrote:
> The patch adds support for the 64-bit resources to the PCI
> iomap code.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* use of asm/prom.h
From: Stephen Rothwell @ 2007-09-05 23:39 UTC (permalink / raw)
To: LKML; +Cc: sparclinux, ppc-dev, Helt, Krzysztof
[-- Attachment #1: Type: text/plain, Size: 941 bytes --]
Hi all,
I noticed in the ALSA tree:
------------------------------ sound/sparc/dbri.c ------------------------------
index 12d11fc..e96023f 100644
@@ -66,6 +66,7 @@
#include <sound/control.h>
#include <sound/initval.h>
+#include <asm/prom.h>
#include <asm/sbus.h>
#include <asm/atomic.h>
(I don't mean to pick on this particular example, it is just what was in
front of me.)
Could people please consider using linux/{of,of_device,of_platform}.h
instead of asm/prom.h now that these exist. Using asm/prom.h only works
now because it includes the above files, but that may (will?) change
eventually.
Most includes of asm/prom.h are there to get access to the routines and
data structures associated with the Open Firmware device tree, and these
are now all available from the above files instead.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Xilinx FX60
From: Grant Likely @ 2007-09-05 22:55 UTC (permalink / raw)
To: Ming Liu; +Cc: linuxppc-embedded
In-Reply-To: <BAY138-F27BF81B9795BD26A16564BB2CB0@phx.gbl>
On 9/5/07, Ming Liu <eemingliu@hotmail.com> wrote:
>
> > > Is it then possible to run two independent kernels, one on each PPC??
> >
> >Absolutely.
>
> Are you meaning two entirely seperate systems, or two ones which share a
> common HW such as memory space? Is that possible without any memory
> confliction?
You can share physical memory as long as each processor is dedicated
to separate regions. However, Linux on power expects memory to be
based at 0. Therefore you need to tweak the memory design so that the
second processor sees a different area of the ram based at zero.
You can even setup a shared memory region between the two processors,
but you that region should be cache-inhibited.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 1/9] 8xx: Fix CONFIG_PIN_TLB.
From: Dan Malek @ 2007-09-05 22:42 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905222310.GA11433@ld0162-tx32.am.freescale.net>
On Sep 5, 2007, at 3:23 PM, Scott Wood wrote:
> The IMMRs I've seen from the bootloader are ff000000 (Freescale
> boards)
> and fa200000 (Embedded Planet). AFAICT, the number of fixed TLB
> entries
> is fixed at 4 on these chips, so using the fourth for flash
> wouldn't take
> away any general-purpose TLB entries.
On these same boards, the memory controllers are usually
configured to put the flash somewhere in that space as well.
This is useful for flash file system performance. If you don't
need that, you can allocate the space differently. The point is
cover as much as you can with the IMMR entry and beyond.
Some people like to map external devices out there.
The 8xx variants have different TLB configurations.
You can't assume anything here. Some parts don't have
enough TLBs to make pinning useful, some allow hardware
wiring of only 2. When using hardware wiring, it's always
the upper entries that are wired. Since the number of
entries varies, you can't assume which TLB index
will be wired.
> I certainly agree that it would be nice to check -- my immediate
> goal is
> to get things working, though.
It's more than nice. If you want this to work correctly
and also get the performance enhancement, it needs
to be done.
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH 1/9] 8xx: Fix CONFIG_PIN_TLB.
From: Dan Malek @ 2007-09-05 22:27 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905205951.GA1047@ld0162-tx32.am.freescale.net>
On Sep 5, 2007, at 1:59 PM, Scott Wood wrote:
> BTW, it seems I misremembered what the conflict was -- it's not with
> ioremap space, but with the default location of the consistent memory
> pool (at 0xff100000).
Change the configuration option to move this somewhere
else, outside of the wired mapping.
As I said in the last message, these lower end processors
are very resource challenged, and we need to clever
about the memory mapping and use of the TLBs. This
isn't a place to be creating fancy memory maps and
algorithms to manage them. Use maximum mappings
whenever possible, configure the memory controller
to pack as much stuff into this single TLB mapping
as possible. Something configurable like this memory
pool should not be a reason to give up these performance
enhancements.
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH 1/9] 8xx: Fix CONFIG_PIN_TLB.
From: Scott Wood @ 2007-09-05 22:23 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev
In-Reply-To: <CF1B6B97-44FA-4002-9030-3C1A20F2F2F4@embeddedalley.com>
On Wed, Sep 05, 2007 at 03:08:28PM -0700, Dan Malek wrote:
> All of this worked in 2.4, many changes were part
> of the evolution in 2.6... configurable pinned entries,
> large page sizes, variations, I didn't keep track of
> all of this. I just assumed I'd have to fix it all if I
> ever needed to use it, which I haven't. The original
> version of 8xx could wire exactly three entries for
> 8M text, 8M data, and 8M IMMR plus upper device
> addresses. We would set the IMMR to ff800000,
> cover the CPM, some other devices and the flash
> at the top of memory.
The IMMRs I've seen from the bootloader are ff000000 (Freescale boards)
and fa200000 (Embedded Planet). AFAICT, the number of fixed TLB entries
is fixed at 4 on these chips, so using the fourth for flash wouldn't take
away any general-purpose TLB entries.
> >I didn't change it on a whim, I changed it because ioremap() wasn't
> >working the way it currently is.
>
> This processor is severely resource limited. It's
> far better to fix ioremap and take advantage of this
> performance enhancement than to further
> cripple it. Just like other processors test for
> mapping by BATs or CAMs, the 8xx and
> probably 4xx should test for wired mapping.
I certainly agree that it would be nice to check -- my immediate goal is
to get things working, though.
-Scott
^ permalink raw reply
* Re: [PATCH 1/9] 8xx: Fix CONFIG_PIN_TLB.
From: Dan Malek @ 2007-09-05 22:08 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905205301.GA807@ld0162-tx32.am.freescale.net>
On Sep 5, 2007, at 1:53 PM, Scott Wood wrote:
> Where is the code that checks for pinned TLB entries on 8xx when doing
> ioremap?
I don't know. I haven't been the maintainer for the 2.6
changes.
> Why could this not be done with a 512K mapping? How was this
> even tested, given the obvious wrong-register mistake in the other
> CONFIG_PIN_TLB section? On what do you base the assumption that
> flash is
> within 8MB of the IMMR base?
All of this worked in 2.4, many changes were part
of the evolution in 2.6... configurable pinned entries,
large page sizes, variations, I didn't keep track of
all of this. I just assumed I'd have to fix it all if I
ever needed to use it, which I haven't. The original
version of 8xx could wire exactly three entries for
8M text, 8M data, and 8M IMMR plus upper device
addresses. We would set the IMMR to ff800000,
cover the CPM, some other devices and the flash
at the top of memory. If you have too much flash, this
had to be adjusted accordingly, but for small systems
this was a nice performance enhancement.
> I didn't change it on a whim, I changed it because ioremap() wasn't
> working the way it currently is.
This processor is severely resource limited. It's
far better to fix ioremap and take advantage of this
performance enhancement than to further
cripple it. Just like other processors test for
mapping by BATs or CAMs, the 8xx and
probably 4xx should test for wired mapping.
Unfortunately, lots of things got messed up on 2.6
for the 8xx. I was not in the loop to approve changes,
and most of my advice was ignored. :-)
Thanks.
-- Dan
^ permalink raw reply
* Re: Xilinx FX60
From: Sergey Temerkhanov @ 2007-09-05 22:05 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <BAY138-F2634DB70ACDB83FA7430FEB2CB0@phx.gbl>
On Thursday 06 September 2007 00:40:33 Ming Liu wrote:
> >It won't. There is no hardware cache coherency on Virtex.
>
> Is that possible if we turn off the cache?
Not in current versions. Implementation of SMP will require implementing
functions from struct smp_ops_t (defined in include/asm-ppc/machdep.h) and
some additional work. Maybe PIC redesign/modification will be needed. And
after all there will be significant performance hit with caches disabled.
^ permalink raw reply
* [PATCH 4/3] Make swsusp_32.S usable for suspend-to-RAM.
From: Scott Wood @ 2007-09-05 22:08 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070905220438.GA11283@ld0162-tx32.am.freescale.net>
This allows platform suspend code to re-use the generic state saving
code, passing a pointer to the low-level suspend code.
The resume path is modified so that non-hibernate callers skip
hibernate-specific bits, and so that callers can specify that the MMU is
off (and thus BATs should be restored).
The _GLOBAL around swsusp_save_area is changed to .global, as the former
puts the data in the text section, which causes an oops with page
debugging enabled.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
Sorry, this one got left out of the previous PM patchset.
arch/powerpc/Kconfig | 11 +++++++
arch/powerpc/kernel/Makefile | 2 +-
arch/powerpc/kernel/swsusp_32.S | 60 ++++++++++++++++++++++----------------
3 files changed, 47 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 00099ef..b8c6fa2 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -123,6 +123,17 @@ config DEFAULT_UIMAGE
Used to allow a board to specify it wants a uImage built by default
default n
+config PPC32_SUSPEND
+ bool
+ depends on PPC32
+ default n
+
+config PPC32_SWSUSP
+ bool
+ depends on PPC32 && HIBERNATION
+ select PPC32_SUSPEND
+ default y
+
config PPC64_SWSUSP
bool
depends on PPC64 && (BROKEN || (PPC_PMAC64 && EXPERIMENTAL))
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 967afc5..d95b09f 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -38,7 +38,7 @@ obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
obj-$(CONFIG_6xx) += idle_6xx.o l2cr_6xx.o cpu_setup_6xx.o
obj-$(CONFIG_TAU) += tau_6xx.o
obj-$(CONFIG_HIBERNATION) += swsusp.o suspend.o
-obj32-$(CONFIG_HIBERNATION) += swsusp_32.o
+obj32-$(CONFIG_PPC32_SUSPEND) += swsusp_32.o
obj64-$(CONFIG_HIBERNATION) += swsusp_64.o swsusp_asm64.o
obj32-$(CONFIG_MODULES) += module_32.o
diff --git a/arch/powerpc/kernel/swsusp_32.S b/arch/powerpc/kernel/swsusp_32.S
index 69e8f86..ed1c95b 100644
--- a/arch/powerpc/kernel/swsusp_32.S
+++ b/arch/powerpc/kernel/swsusp_32.S
@@ -33,15 +33,21 @@
.section .data
.align 5
-_GLOBAL(swsusp_save_area)
+ .global swsusp_save_area
+swsusp_save_area:
.space SL_SIZE
.section .text
.align 5
+#ifdef CONFIG_SOFTWARE_SUSPEND
_GLOBAL(swsusp_arch_suspend)
+ lis r3, swsusp_save@h
+ ori r3, r3, swsusp_save@l
+#endif
+_GLOBAL(do_suspend)
lis r11,swsusp_save_area@h
ori r11,r11,swsusp_save_area@l
@@ -64,8 +70,8 @@ _GLOBAL(swsusp_arch_suspend)
stw r4,SL_TB(r11)
mftb r5
stw r5,SL_TB+4(r11)
- mftbu r3
- cmpw r3,r4
+ mftbu r6
+ cmpw r6,r4
bne 1b
/* Save SPRGs */
@@ -119,7 +125,8 @@ _GLOBAL(swsusp_arch_suspend)
/* Call the low level suspend stuff (we should probably have made
* a stackframe...
*/
- bl swsusp_save
+ mtctr r3
+ bctrl
/* Restore LR from the save area */
lis r11,swsusp_save_area@h
@@ -129,7 +136,7 @@ _GLOBAL(swsusp_arch_suspend)
blr
-
+#ifdef CONFIG_SOFTWARE_SUSPEND
/* Resume code */
_GLOBAL(swsusp_arch_resume)
@@ -212,6 +219,13 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
bdnz 1b
sync
+ li r3, 0
+#endif
+
+ /* r3 = nonzero if the MMU is completely disabled and
+ * BATs may be restored, zero otherwise.
+ */
+_GLOBAL(do_resume)
/* Ok, we are now running with the kernel data of the old
* kernel fully restored. We can get to the save area
* easily now. As for the rest of the code, it assumes the
@@ -226,10 +240,8 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
bl __restore_cpu_setup
#endif
/* Restore the BATs, and SDR1. Then we can turn on the MMU.
- * This is a bit hairy as we are running out of those BATs,
- * but first, our code is probably in the icache, and we are
- * writing the same value to the BAT, so that should be fine,
- * though a better solution will have to be found long-term
+ * This can only be done when r3 != 0 (and thus the MMU is
+ * off).
*/
lwz r4,SL_SDR1(r11)
mtsdr1 r4
@@ -242,7 +254,9 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
lwz r4,SL_SPRG0+12(r11)
mtsprg 3,r4
-#if 0
+ cmpw r3, 0
+ beq 1f
+
lwz r4,SL_DBAT0(r11)
mtdbatu 0,r4
lwz r4,SL_DBAT0+4(r11)
@@ -275,8 +289,8 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
mtibatu 3,r4
lwz r4,SL_IBAT3+4(r11)
mtibatl 3,r4
-#endif
+1:
BEGIN_FTR_SECTION
li r4,0
mtspr SPRN_DBAT4U,r4
@@ -306,8 +320,16 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_HIGH_BATS)
/* restore the MSR and turn on the MMU */
lwz r3,SL_MSR(r11)
- bl turn_on_mmu
- tovirt(r11,r11)
+ lis r4, 1f@h
+ ori r4, r4, 1f@l
+
+ mtsrr0 r4
+ mtsrr1 r3
+ sync
+ isync
+ rfi
+
+1: tovirt(r11, r11)
/* Restore TB */
li r3,0
@@ -334,15 +356,3 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_HIGH_BATS)
li r3,0
blr
-
-/* FIXME:This construct is actually not useful since we don't shut
- * down the instruction MMU, we could just flip back MSR-DR on.
- */
-turn_on_mmu:
- mflr r4
- mtsrr0 r4
- mtsrr1 r3
- sync
- isync
- rfi
-
--
1.5.3
^ permalink raw reply related
* [PATCH 3/3] Add 6xx-style HID0_SLEEP support.
From: Scott Wood @ 2007-09-05 22:06 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070905220438.GA11283@ld0162-tx32.am.freescale.net>
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/sysdev/6xx-suspend.S | 52 +++++++++++++++++++++++++++++++++++++
arch/powerpc/sysdev/Makefile | 4 +++
include/asm-powerpc/mpc6xx.h | 6 ++++
3 files changed, 62 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/sysdev/6xx-suspend.S
create mode 100644 include/asm-powerpc/mpc6xx.h
diff --git a/arch/powerpc/sysdev/6xx-suspend.S b/arch/powerpc/sysdev/6xx-suspend.S
new file mode 100644
index 0000000..976ee07
--- /dev/null
+++ b/arch/powerpc/sysdev/6xx-suspend.S
@@ -0,0 +1,52 @@
+/*
+ * Enter and leave sleep state on chips with 6xx-style HID0
+ * power management bits.
+ *
+ * Author: Scott Wood <scottwood@freescale.com>
+ *
+ * Copyright (c) 2006-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 <asm/ppc_asm.h>
+#include <asm/reg.h>
+#include <asm/thread_info.h>
+#include <asm/asm-offsets.h>
+
+_GLOBAL(mpc6xx_enter_sleep)
+ mflr r4
+
+ mfspr r5, SPRN_HID0
+ rlwinm r5, r5, 0, ~(HID0_DOZE | HID0_NAP)
+ oris r5, r5, HID0_SLEEP@h
+ mtspr SPRN_HID0, r5
+ isync
+
+ lis r5, ret_from_sleep@h
+ ori r5, r5, ret_from_sleep@l
+ mtlr r5
+
+ rlwinm r5, r1, 0, 0, 31-THREAD_SHIFT
+ lwz r6, TI_LOCAL_FLAGS(r5)
+ ori r6, r6, _TLF_NAPPING
+ stw r6, TI_LOCAL_FLAGS(r5)
+
+ mfmsr r5
+ ori r5, r5, MSR_EE
+ oris r5, r5, MSR_POW@h
+ sync
+ mtmsr r5
+ isync
+
+1: b 1b
+
+ret_from_sleep:
+ mfspr r5, SPRN_HID0
+ rlwinm r5, r5, 0, ~HID0_SLEEP
+ mtspr SPRN_HID0, r5
+
+ mtlr r4
+ blr
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index 08ce31e..84a0800 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -38,3 +38,7 @@ obj-$(CONFIG_CPM2) += cpm2_common.o cpm2_pic.o
obj-$(CONFIG_8xx) += mpc8xx_pic.o commproc.o
obj-$(CONFIG_UCODE_PATCH) += micropatch.o
endif
+
+ifeq ($(CONFIG_SUSPEND),y)
+obj-$(CONFIG_6xx) += 6xx-suspend.o
+endif
diff --git a/include/asm-powerpc/mpc6xx.h b/include/asm-powerpc/mpc6xx.h
new file mode 100644
index 0000000..01a33ed
--- /dev/null
+++ b/include/asm-powerpc/mpc6xx.h
@@ -0,0 +1,6 @@
+#ifndef __ASM_POWERPC_MPC6xx_H
+#define __ASM_POWERPC_MPC6xx_H
+
+void mpc6xx_enter_sleep(void);
+
+#endif
--
1.5.3
^ permalink raw reply related
* [PATCH 2/3] pm: Handle HID0_SLEEP in the TLF_NAPPING hack.
From: Scott Wood @ 2007-09-05 22:06 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <20070905220438.GA11283@ld0162-tx32.am.freescale.net>
The e300 core (and probably most other 6xx chips) can only come out of
sleep mode with an interrupt. However, interrupts are logically disabled
by the power management layer.
This hack extends the existing doze/nap hack to also suppress the running
of the interrupt handler when in sleep mode.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/kernel/idle_6xx.S | 40 +++++++++++++++++++++++++++++++++++++---
1 files changed, 37 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/idle_6xx.S b/arch/powerpc/kernel/idle_6xx.S
index 01bcd52..d176042 100644
--- a/arch/powerpc/kernel/idle_6xx.S
+++ b/arch/powerpc/kernel/idle_6xx.S
@@ -147,6 +147,12 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
isync
b 1b
+#ifdef CONFIG_SUSPEND
+ret_from_sleep:
+ .long ret_from_except
+ .long ret_from_except
+#endif
+
/*
* Return from NAP/DOZE mode, restore some CPU specific registers,
* we are called with DR/IR still off and r2 containing physical
@@ -154,7 +160,33 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
* address). We have to preserve r10.
*/
_GLOBAL(power_save_6xx_restore)
- lwz r9,_LINK(r11) /* interrupted in ppc6xx_idle: */
+#ifdef CONFIG_SUSPEND
+ mfspr r8, SPRN_HID0
+ andis. r9, r8, HID0_SLEEP@h
+ beq+ 1f
+
+ /*
+ * SLEEP mode is invoked through the PM subsystem, which means
+ * that interrupts should be disabled. However, the hardware
+ * requires them to be enabled to wake up. To prevent the
+ * interrupt from being visible to Linux, return immediately
+ * rather than run the interrupt handler.
+ */
+ lis r9, ret_from_sleep@h
+ ori r9, r9, ret_from_sleep@l
+ tophys(r9, r9)
+ mtlr r9
+
+ /*
+ * Disable interrupts, so that the interrupt doesn't happen
+ * again until the PM code sets MSR[EE].
+ */
+ lwz r9, _MSR(r11)
+ rlwinm r9, r9, 0, ~MSR_EE
+ stw r9, _MSR(r11)
+#endif
+
+1: lwz r9,_LINK(r11) /* interrupted in ppc6xx_idle: */
stw r9,_NIP(r11) /* make it do a blr */
#ifdef CONFIG_SMP
@@ -168,8 +200,10 @@ _GLOBAL(power_save_6xx_restore)
* and load r11 (@ha part + CPU offset) only once
*/
BEGIN_FTR_SECTION
- mfspr r9,SPRN_HID0
- andis. r9,r9,HID0_NAP@h
+#ifndef CONFIG_SUSPEND
+ mfspr r8,SPRN_HID0
+#endif
+ andis. r9,r8,HID0_NAP@h
beq 1f
addis r9,r11,(nap_save_msscr0-KERNELBASE)@ha
lwz r9,nap_save_msscr0@l(r9)
--
1.5.3
^ permalink raw reply related
* [PATCH 1/3] Implement arch disable/enable irq hooks.
From: Scott Wood @ 2007-09-05 22:06 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
These hooks ensure that a decrementer interrupt is not pending when
suspending; otherwise, problems may occur. For example, with deep sleep
on the 831x, a pending decrementer will cause a system freeze because the
SoC thinks the decrementer interrupt would have woken the system, but the
core must have interrupts disabled due to the setup required for deep
sleep.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/kernel/time.c | 41 +++++++++++++++++++++++++++++++++++++++++
include/asm-powerpc/machdep.h | 13 +++++++++++++
2 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index b5944d8..bf7c4d3 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -728,6 +728,47 @@ void wakeup_decrementer(void)
set_dec(ticks);
}
+#ifdef CONFIG_SUSPEND
+void generic_suspend_disable_irqs(void)
+{
+ preempt_disable();
+
+ /* Disable the decrementer, so that it doesn't interfere
+ * with suspending.
+ */
+
+ set_dec(0x7fffffff);
+ local_irq_disable();
+ set_dec(0x7fffffff);
+}
+
+void generic_suspend_enable_irqs(void)
+{
+ wakeup_decrementer();
+
+ local_irq_enable();
+ preempt_enable();
+}
+
+/* Overrides the weak version in kernel/power/main.c */
+void arch_suspend_disable_irqs(void)
+{
+ if (ppc_md.suspend_disable_irqs)
+ ppc_md.suspend_disable_irqs();
+ else
+ generic_suspend_disable_irqs();
+}
+
+/* Overrides the weak version in kernel/power/main.c */
+void arch_suspend_enable_irqs(void)
+{
+ if (ppc_md.suspend_enable_irqs)
+ ppc_md.suspend_enable_irqs();
+ else
+ generic_suspend_enable_irqs();
+}
+#endif
+
#ifdef CONFIG_SMP
void __init smp_space_timers(unsigned int max_cpus)
{
diff --git a/include/asm-powerpc/machdep.h b/include/asm-powerpc/machdep.h
index 71c6e7e..7d6d2cb 100644
--- a/include/asm-powerpc/machdep.h
+++ b/include/asm-powerpc/machdep.h
@@ -253,6 +253,16 @@ struct machdep_calls {
*/
void (*machine_kexec)(struct kimage *image);
#endif /* CONFIG_KEXEC */
+
+#ifdef CONFIG_SUSPEND
+ /* These are called to disable and enable, respectively, IRQs when
+ * entering a suspend state. If NULL, then the generic versions
+ * will be called. The generic versions disable/enable the
+ * decrementer along with interrupts.
+ */
+ void (*suspend_disable_irqs)(void);
+ void (*suspend_enable_irqs)(void);
+#endif
};
extern void power4_idle(void);
@@ -326,5 +336,8 @@ static inline void log_error(char *buf, unsigned int err_type, int fatal)
ppc_md.log_error(buf, err_type, fatal);
}
+void generic_suspend_disable_irqs(void);
+void generic_suspend_enable_irqs(void);
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_MACHDEP_H */
--
1.5.3
^ permalink raw reply related
* [PATCH v2] Check _PAGE_RW and _PAGE_PRESENT on kernel addresses.
From: Scott Wood @ 2007-09-05 22:04 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Previously, the TLB miss handlers assumed that pages above KERNELBASE are
always present and read/write. This assumption is false in the case of
CONFIG_DEBUG_PAGEALLOC.
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
arch/powerpc/kernel/head_32.S | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
index 7d73a13..0e3df1f 100644
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -475,10 +475,10 @@ InstructionTLBMiss:
li r1,_PAGE_USER|_PAGE_PRESENT /* low addresses tested as user */
lwz r2,PGDIR(r2)
blt+ 112f
+ mfspr r2,SPRN_SRR1 /* and MSR_PR bit from SRR1 */
+ rlwimi r1,r2,32-12,29,29 /* shift MSR_PR to _PAGE_USER posn */
lis r2,swapper_pg_dir@ha /* if kernel address, use */
addi r2,r2,swapper_pg_dir@l /* kernel page table */
- mfspr r1,SPRN_SRR1 /* and MSR_PR bit from SRR1 */
- rlwinm r1,r1,32-12,29,29 /* shift MSR_PR to _PAGE_USER posn */
112: tophys(r2,r2)
rlwimi r2,r3,12,20,29 /* insert top 10 bits of address */
lwz r2,0(r2) /* get pmd entry */
@@ -549,10 +549,10 @@ DataLoadTLBMiss:
li r1,_PAGE_USER|_PAGE_PRESENT /* low addresses tested as user */
lwz r2,PGDIR(r2)
blt+ 112f
+ mfspr r2,SPRN_SRR1 /* and MSR_PR bit from SRR1 */
+ rlwimi r1,r2,32-12,29,29 /* shift MSR_PR to _PAGE_USER posn */
lis r2,swapper_pg_dir@ha /* if kernel address, use */
addi r2,r2,swapper_pg_dir@l /* kernel page table */
- mfspr r1,SPRN_SRR1 /* and MSR_PR bit from SRR1 */
- rlwinm r1,r1,32-12,29,29 /* shift MSR_PR to _PAGE_USER posn */
112: tophys(r2,r2)
rlwimi r2,r3,12,20,29 /* insert top 10 bits of address */
lwz r2,0(r2) /* get pmd entry */
@@ -621,10 +621,10 @@ DataStoreTLBMiss:
li r1,_PAGE_RW|_PAGE_USER|_PAGE_PRESENT /* access flags */
lwz r2,PGDIR(r2)
blt+ 112f
+ mfspr r2,SPRN_SRR1 /* and MSR_PR bit from SRR1 */
+ rlwimi r1,r2,32-12,29,29 /* shift MSR_PR to _PAGE_USER posn */
lis r2,swapper_pg_dir@ha /* if kernel address, use */
addi r2,r2,swapper_pg_dir@l /* kernel page table */
- mfspr r1,SPRN_SRR1 /* and MSR_PR bit from SRR1 */
- rlwinm r1,r1,32-12,29,29 /* shift MSR_PR to _PAGE_USER posn */
112: tophys(r2,r2)
rlwimi r2,r3,12,20,29 /* insert top 10 bits of address */
lwz r2,0(r2) /* get pmd entry */
--
1.5.3
^ permalink raw reply related
* Re: [PATCH 1/3] CPM: Change from fsl, brg-frequency to brg/clock-frequency
From: Scott Wood @ 2007-09-05 21:58 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20070905215708.GA8718@lixom.net>
On Wed, Sep 05, 2007 at 04:57:08PM -0500, Olof Johansson wrote:
> On Wed, Sep 05, 2007 at 02:13:13PM -0500, Scott Wood wrote:
> > As suggested by David Gibson, now that we have a separate node
> > for the baud rate generators, it's better to use the standard
> > clock-frequency property than a cpm-node-level fsl,brg-frequency
> > property.
> >
> > This patch updates existing places where fsl,brg-frequency is
> > used.
>
> What about older platforms that were booted with the older device
> tree? Don't you have to stay compatible with them?
The older platforms use /soc/cpm/brg-frequency, not
/soc/cpm/fsl,brg-frequency -- and that is still supported. The latter
only exists as one patch in Kumar's tree.
-Scott
^ permalink raw reply
* Re: [PATCH 1/3] CPM: Change from fsl, brg-frequency to brg/clock-frequency
From: Olof Johansson @ 2007-09-05 21:57 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905191313.GA31927@ld0162-tx32.am.freescale.net>
On Wed, Sep 05, 2007 at 02:13:13PM -0500, Scott Wood wrote:
> As suggested by David Gibson, now that we have a separate node
> for the baud rate generators, it's better to use the standard
> clock-frequency property than a cpm-node-level fsl,brg-frequency
> property.
>
> This patch updates existing places where fsl,brg-frequency is
> used.
What about older platforms that were booted with the older device
tree? Don't you have to stay compatible with them? Think kexec of a
system running a kernel with the older device tree, for example.
-Olof
^ permalink raw reply
* Re: Xilinx FX60
From: Sergey Temerkhanov @ 2007-09-05 21:36 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <1189023628.6185.59.camel@PisteOff>
On Thursday 06 September 2007 00:20:28 Robert Woodworth wrote:
> Is it then possible to run two independent kernels, one on each PPC??
AMP must work there.
>
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* 7448 pll registers
From: Leisner, Martin @ 2007-09-05 21:24 UTC (permalink / raw)
To: Linuxppc-embedded
I'm going to get DFS into the 7448 (it looks like I'm going to take a
different
tactic then I see in 2.6.20.16 -- it hinges on powermac, and I don't
know if it
even compiles).
In include/asm-powerpc, its missing definitions for HID1/{PC4,PC5}.
bash2 :2 mleisner@linuxcom-01 05:18:58; rcsdiff -u reg.h
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
RCS file: reg.h,v
retrieving revision 1.1
diff -u -r1.1 reg.h
--- reg.h 2007/09/05 20:45:36 1.1
+++ reg.h 2007/09/05 20:46:56
@@ -253,6 +253,8 @@
#define HID1_PC1 (1<<15) /* 7450 PLL_CFG[1] */
#define HID1_PC2 (1<<14) /* 7450 PLL_CFG[2] */
#define HID1_PC3 (1<<13) /* 7450 PLL_CFG[3] */
+#define HID1_PC4 (1<<12) /* ???? PLL_CFG[4] */
+#define HID1_PC5 (1<<17) /* 7448 specific bit --
PLL_CFG[5] */
#define HID1_SYNCBE (1<<11) /* 7450 ABE for sync, eieio */
#define HID1_ABE (1<<10) /* 7450 Address Broadcast Enable
*/
#define HID1_PS (1<<16) /* 750FX PLL selection
*/
PC4 seems "generic", PC5 is a "MPC7448 specific bit"
I'm not sure what HID1_PS means ( 750FX PLL selection ), its the same
bit as=20
HID1_PC0.
marty
^ permalink raw reply
* Re: [PATCH 04/10] bootwrapper: Add strtoull().
From: Josh Boyer @ 2007-09-05 21:12 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905192110.GD32113@ld0162-tx32.am.freescale.net>
On Wed, 5 Sep 2007 14:21:10 -0500
Scott Wood <scottwood@freescale.com> wrote:
> This will be needed by PlanetCore firmware support.
Bamboo would like to use this too. And probably anything else that has
PIBS as a bootloader. I could forsee Holly using this too.
josh
^ permalink raw reply
* Re: OF NDFC
From: Josh Boyer @ 2007-09-05 21:00 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20070905181703.GA30904@ru.mvista.com>
On Wed, 5 Sep 2007 22:17:03 +0400
Valentine Barshak <vbarshak@ru.mvista.com> wrote:
> Is anybody working on the device-tree-aware ppc 44x NAND flash controller (ndfc) driver?
Not to my knowledge. We sort of need a decent binding for NAND flash
in general first. And David's recent flash binding doesn't address
NAND flash.
It's on my list of things to do, but if someone gets there first then
great.
josh
^ permalink raw reply
* Re: [PATCH 1/9] 8xx: Fix CONFIG_PIN_TLB.
From: Scott Wood @ 2007-09-05 20:59 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev
In-Reply-To: <20070905205301.GA807@ld0162-tx32.am.freescale.net>
On Wed, Sep 05, 2007 at 03:53:01PM -0500, Scott Wood wrote:
> I didn't change it on a whim, I changed it because ioremap() wasn't
> working the way it currently is.
BTW, it seems I misremembered what the conflict was -- it's not with
ioremap space, but with the default location of the consistent memory
pool (at 0xff100000).
-Scott
^ permalink raw reply
* Re: [PATCH 1/9] 8xx: Fix CONFIG_PIN_TLB.
From: Scott Wood @ 2007-09-05 20:53 UTC (permalink / raw)
To: Dan Malek; +Cc: linuxppc-dev
In-Reply-To: <4F58F233-56E5-4910-9D33-28A44FCB393C@embeddedalley.com>
On Wed, Sep 05, 2007 at 01:36:43PM -0700, Dan Malek wrote:
>
> On Sep 5, 2007, at 12:27 PM, Scott Wood wrote:
>
> >1. Only map 512K of the IMMR, rather than 8M, to avoid conflicting
> >with
> >the default ioremap region.
>
> The original reason to map 8M was so ioremap()
> could use the same wired TLB rather than allocate
> page table entries. It should also cover all addresses
> mapped to the flash as well. This was intentional,
> not a mistake.
"intentional" and "mistake" are not mutually exclusive.
Where is the code that checks for pinned TLB entries on 8xx when doing
ioremap? Why could this not be done with a 512K mapping? How was this
even tested, given the obvious wrong-register mistake in the other
CONFIG_PIN_TLB section? On what do you base the assumption that flash is
within 8MB of the IMMR base?
I didn't change it on a whim, I changed it because ioremap() wasn't
working the way it currently is.
-Scott
^ permalink raw reply
* Re: [PATCH 1/9] 8xx: Fix CONFIG_PIN_TLB.
From: Dan Malek @ 2007-09-05 20:36 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070905192727.GA32365@ld0162-tx32.am.freescale.net>
On Sep 5, 2007, at 12:27 PM, Scott Wood wrote:
> 1. Only map 512K of the IMMR, rather than 8M, to avoid conflicting
> with
> the default ioremap region.
The original reason to map 8M was so ioremap()
could use the same wired TLB rather than allocate
page table entries. It should also cover all addresses
mapped to the flash as well. This was intentional,
not a mistake.
-- Dan
^ permalink raw reply
* Re: Xilinx FX60
From: Ming Liu @ 2007-09-05 20:40 UTC (permalink / raw)
To: temerkhanov, linuxppc-embedded
In-Reply-To: <200709052342.34177.temerkhanov@yandex.ru>
>It won't. There is no hardware cache coherency on Virtex.
Is that possible if we turn off the cache?
BR
Ming
_________________________________________________________________
享用世界上最大的电子邮件系统― MSN Hotmail。 http://www.hotmail.com
^ 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