* Re: [PATCH] Remove CPU_FTR_NEED_COHERENT for 7448.
From: Paul Mackerras @ 2007-05-03 11:02 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1178141683.32136.46.camel@ld0161-tx32>
Jon Loeliger writes:
> From: James.Yang <James.Yang@freescale.com>
>
> Remove CPU_FTR_NEED_COHERENT for MPC7448 (and single-core MPC86xx).
> This prevents needlessly setting M=1 when not SMP.
Do you have any benchmark results showing a real performance
improvement from these?
Paul.
^ permalink raw reply
* Re: powerpc_flash_init(), wtf!?
From: Sergei Shtylyov @ 2007-05-03 11:47 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070501051804.GB3881@localhost.localdomain>
Hello.
David Gibson wrote:
> powerpc_flash_init(), the only function in arch/powerpc/sysdev/rom.c,
> goes through the device tree finding anything with device_type=="rom"
> and creating of_platform devices for them, which will be picked up by
> the physmap_of mtd driver. This has two serious conceptual errors and
> one bad implementation error which is quite an accomplishment for 15
> lines of code.
> Most seriously, this "find all roms" approach to probing is
> fundamentally incompatible with the normal way of probing for
> of_platform devices, to wit, using of_platform_bus_probe(). If a
We weren't aware of the of_platform.c work when writing the MTD support.
Note that this function usually probes only the specified set of (SoC)
busses, none of which usully contains NOR flash (which is located at the root
level).
> flash is on a bus probed with of_platform_bus_probe()
> powerpc_flash_init() will create a duplicate of_platform device for it.
Flash on a SoC bus? Well, that's more likely to happen for NAND.
But generally, I'd agree with you.
> powerpc_flash_init() could also mistakenly probe roms which
> appear on other random busses which should use their own probe logic
> instead of going straight off the device tree (admittedly flash is
> unlikely to appear on such a bus).
Well, if you consider NAND...
> Also, it uses the device node's name without unit address as the
> of_platform device's name. So if a bus somewhere has two flash
> devices named, say "flash@0" and "flash@800000", the device code will
> give a stack dump during boot as powerpc_flash_init() attempts to
> register them both under the name "flash".
Well, we didn't think about 2 flashes named the same way. :-/
> I observe that none of the dts files actually present in the kernel
> tree use physmap_of's format for describing flash devices (and
> therefore don't use this code). I'm therefore rather tempted to
Which means I still haven't submitted the patch. :-<
> simply blow arch/powerpc/sysdev/rom.c away, and anyone out-of-tree
> relying on this code will have to fix their platform probing code to
> create the flash of_platform devices properly.
You mean creating the "rom" devices from the platform-specific code?
I doubt that it's really a flexible approach...
> Unless someone who actually knows how this code was intended to be
> used can suggest a more polite way of fixing it.
Well, probably it needs to only look up the root bus...
WBR, Sergei
^ permalink raw reply
* Re: powerpc_flash_init(), wtf!?
From: Sergei Shtylyov @ 2007-05-03 12:02 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070503070358.GA9430@localhost.localdomain>
Hello.
David Gibson wrote:
>>>Unless someone who actually knows how this code was intended to be
>>>used can suggest a more polite way of fixing it.
>>I guess, the idea was for this stuff to be updated once one of the
>>dts inside boot/ would have physmap nodes added. I have
>>rom/physmap[dts] rehaul in my TODO list, but it has (so far at
>>least) little chance to happen during this merge window. Yet, if
>>someone has suggestions and/or some interest for this to be cured,
>>it will gain priority. Otherwise, I'll replace actual erroneous code
>>with kind of rant that it's up to BSP code to take care of
>>of_devices to be registered, using of_platform_bus_probe() or other
>>way.
> I'm having some trouble parsing that paragraph. At this stage I don't
> see any reason to hold off on tearing out arch/powerpc/sysdev/rom.c,
> any necessary changes to replace it will go in the platform code or
It doesn't seem a flexible enough approach. We could continue using
platform devices then.
> other places.
Any ideas where else?
WBR, Sergei
^ permalink raw reply
* Re: powerpc_flash_init(), wtf!?
From: David Gibson @ 2007-05-03 12:22 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev
In-Reply-To: <4639CF44.6020608@ru.mvista.com>
On Thu, May 03, 2007 at 04:02:12PM +0400, Sergei Shtylyov wrote:
> Hello.
>
> David Gibson wrote:
>
> >>>Unless someone who actually knows how this code was intended to be
> >>>used can suggest a more polite way of fixing it.
>
> >>I guess, the idea was for this stuff to be updated once one of the
> >>dts inside boot/ would have physmap nodes added. I have
> >>rom/physmap[dts] rehaul in my TODO list, but it has (so far at
> >>least) little chance to happen during this merge window. Yet, if
> >>someone has suggestions and/or some interest for this to be cured,
> >>it will gain priority. Otherwise, I'll replace actual erroneous code
> >>with kind of rant that it's up to BSP code to take care of
> >>of_devices to be registered, using of_platform_bus_probe() or other
> >>way.
>
> > I'm having some trouble parsing that paragraph. At this stage I don't
> > see any reason to hold off on tearing out arch/powerpc/sysdev/rom.c,
> > any necessary changes to replace it will go in the platform code or
>
> It doesn't seem a flexible enough approach. We could continue using
> platform devices then.
Sorry, I don't follow you.
> > other places.
>
> Any ideas where else?
Not really. I don't immediately see a case where doing it from the
platform code wouldn't be right.
--
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
* Re: patches for 2.6.22
From: Johannes Berg @ 2007-05-03 12:25 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17969.56735.644629.328360@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 417 bytes --]
Hi,
I'll reply to this message with 3 more patches that I will send as soon
as akpm sends Rafael's swsusp patches from -mm to Linus. Please take a
look anyway, only some register_nosave_region{_late,}() calls are in
these patches that are not possible yet.
I'd love to have the G5 suspend merged even though nvidiafb still breaks
it, I do think it's a bug in nvidiafb and not the generic code.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* [PATCH] powerpc: dart iommu suspend
From: Johannes Berg @ 2007-05-03 12:28 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <1178195106.13233.108.camel@johannes.berg>
This implements save and restore hooks for IOMMUs and implements
it the dart iommu.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Cc: Paul Mackeras <paulus@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Olof Johansson <olof@lixom.net>
---
arch/powerpc/sysdev/dart_iommu.c | 46 +++++++++++++++++++++++++++++++++++++++
include/asm-powerpc/iommu.h | 14 +++++++++++
include/asm-powerpc/machdep.h | 5 ++++
3 files changed, 65 insertions(+)
--- wireless-dev.orig/arch/powerpc/sysdev/dart_iommu.c 2007-05-03 14:20:26.089165535 +0200
+++ wireless-dev/arch/powerpc/sysdev/dart_iommu.c 2007-05-03 14:21:08.889165535 +0200
@@ -36,6 +36,7 @@
#include <linux/pci.h>
#include <linux/dma-mapping.h>
#include <linux/vmalloc.h>
+#include <linux/suspend.h>
#include <asm/io.h>
#include <asm/prom.h>
#include <asm/iommu.h>
@@ -54,6 +55,9 @@ static unsigned long dart_tablesize;
/* Virtual base address of the DART table */
static u32 *dart_vbase;
+#ifdef CONFIG_PM
+static u32 *dart_copy;
+#endif
/* Mapped base address for the dart */
static unsigned int __iomem *dart;
@@ -346,6 +350,48 @@ void iommu_init_early_dart(void)
set_pci_dma_ops(&dma_direct_ops);
}
+#ifdef CONFIG_PM
+static void iommu_dart_save(void)
+{
+ memcpy(dart_copy, dart_vbase, 2*1024*1024);
+}
+
+static void iommu_dart_restore(void)
+{
+ memcpy(dart_vbase, dart_copy, 2*1024*1024);
+ dart_tlb_invalidate_all();
+}
+
+static int __init iommu_init_late_dart(void)
+{
+ unsigned long tbasepfn;
+ struct page *p;
+
+ /* if no dart table exists then we won't need to save it
+ * and the area has also not been reserved */
+ if (!dart_tablebase)
+ return 0;
+
+ tbasepfn = __pa(dart_tablebase) >> PAGE_SHIFT;
+ register_nosave_region_late(tbasepfn,
+ tbasepfn + ((1<<24) >> PAGE_SHIFT));
+
+ /* For suspend we need to copy the dart contents because
+ * it is not part of the regular mapping (see above) and
+ * thus not saved automatically. The memory for this copy
+ * must be allocated early because we need 2 MB. */
+ p = alloc_pages(GFP_KERNEL, 21 - PAGE_SHIFT);
+ BUG_ON(!p);
+ dart_copy = page_address(p);
+
+ ppc_md.iommu_save = iommu_dart_save;
+ ppc_md.iommu_restore = iommu_dart_restore;
+
+ return 0;
+}
+
+late_initcall(iommu_init_late_dart);
+#endif
void __init alloc_dart_table(void)
{
--- wireless-dev.orig/include/asm-powerpc/iommu.h 2007-05-03 14:20:26.109165535 +0200
+++ wireless-dev/include/asm-powerpc/iommu.h 2007-05-03 14:21:08.889165535 +0200
@@ -26,6 +26,7 @@
#include <linux/spinlock.h>
#include <linux/device.h>
#include <linux/dma-mapping.h>
+#include <asm/machdep.h>
#include <asm/types.h>
#include <asm/bitops.h>
@@ -109,6 +110,19 @@ static inline void pci_iommu_init(void)
#endif
extern void alloc_dart_table(void);
+#if defined(CONFIG_PPC64) && defined(CONFIG_PM)
+static inline void iommu_save(void)
+{
+ if (ppc_md.iommu_save)
+ ppc_md.iommu_save();
+}
+
+static inline void iommu_restore(void)
+{
+ if (ppc_md.iommu_restore)
+ ppc_md.iommu_restore();
+}
+#endif
#endif /* __KERNEL__ */
#endif /* _ASM_IOMMU_H */
--- wireless-dev.orig/include/asm-powerpc/machdep.h 2007-05-03 14:21:07.569165535 +0200
+++ wireless-dev/include/asm-powerpc/machdep.h 2007-05-03 14:21:08.899165535 +0200
@@ -91,6 +91,11 @@ struct machdep_calls {
void __iomem * (*ioremap)(phys_addr_t addr, unsigned long size,
unsigned long flags);
void (*iounmap)(volatile void __iomem *token);
+
+#ifdef CONFIG_PM
+ void (*iommu_save)(void);
+ void (*iommu_restore)(void);
+#endif
#endif /* CONFIG_PPC64 */
int (*probe)(void);
^ permalink raw reply
* [PATCH] powerpc: mark pages that don't exist as nosave
From: Johannes Berg @ 2007-05-03 12:29 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <1178195106.13233.108.camel@johannes.berg>
On some powerpc architectures (notably 64-bit powermac) there is a memory
hole, for example on powermacs between 2G and 4G. Since we use the flat
memory model regardless, these pages must be marked as nosave (for suspend
to disk.)
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Rafael J. Wysocki <rjw@sisk.pl>
---
Tested on powerbook and G5 powermac.
---
arch/powerpc/mm/mem.c | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
--- wireless-dev.orig/arch/powerpc/mm/mem.c 2007-05-03 14:20:25.959165535 +0200
+++ wireless-dev/arch/powerpc/mm/mem.c 2007-05-03 14:21:09.659165535 +0200
@@ -31,6 +31,7 @@
#include <linux/highmem.h>
#include <linux/initrd.h>
#include <linux/pagemap.h>
+#include <linux/suspend.h>
#include <asm/pgalloc.h>
#include <asm/prom.h>
@@ -277,6 +278,28 @@ void __init do_init_bootmem(void)
init_bootmem_done = 1;
}
+/* mark pages that don't exist as nosave */
+static int __init mark_nonram_nosave(void)
+{
+ unsigned long lmb_next_region_start_pfn,
+ lmb_region_max_pfn;
+ int i;
+
+ for (i = 0; i < lmb.memory.cnt - 1; i++) {
+ lmb_region_max_pfn =
+ (lmb.memory.region[i].base >> PAGE_SHIFT) +
+ (lmb.memory.region[i].size >> PAGE_SHIFT);
+ lmb_next_region_start_pfn =
+ lmb.memory.region[i+1].base >> PAGE_SHIFT;
+
+ if (lmb_region_max_pfn < lmb_next_region_start_pfn)
+ register_nosave_region(lmb_region_max_pfn,
+ lmb_next_region_start_pfn);
+ }
+
+ return 0;
+}
+
/*
* paging_init() sets up the page tables - in fact we've already done this.
*/
@@ -308,6 +331,8 @@ void __init paging_init(void)
max_zone_pfns[ZONE_DMA] = top_of_ram >> PAGE_SHIFT;
#endif
free_area_init_nodes(max_zone_pfns);
+
+ mark_nonram_nosave();
}
#endif /* ! CONFIG_NEED_MULTIPLE_NODES */
^ permalink raw reply
* Re: powerpc_flash_init(), wtf!?
From: Benjamin Herrenschmidt @ 2007-05-03 12:29 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <4639CF44.6020608@ru.mvista.com>
> It doesn't seem a flexible enough approach. We could continue using
> platform devices then.
The problem is trivial enough tho... who ends up creating an
of_platform_device for that rom node ... to be picked up by the driver.
Creating of_platform devices is platform code responsibility... either
by calling of_platform_bus_probe() (or whatever I called it ...) to
generate them from known bus type or by creating them directly, that
doesn't matter, that's still platform code business.
Ben.
^ permalink raw reply
* [PATCH] powermac: suspend to disk on G5
From: Johannes Berg @ 2007-05-03 12:31 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <1178195106.13233.108.camel@johannes.berg>
Powermac G5 suspend to disk implementation. The code is platform
agnostic but only tested on powermac, no other 64-bit powerpc
machines.
Because nvidiafb still breaks suspend I have marked it EXPERIMENTAL on
powermac and because I can't test it and some lowlevel code will need
changes it is BROKEN on all other 64-bit platforms.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
WARNING: nvidiafb breaks suspend. I don't know why yet, but if it is
compiled and you try to suspend from X it all just freezes. The nvidiafb
suspend code looks a bit fishy but I shall have to understand first what
it's trying to achieve.
Other than that I'm really happy with this, it's good to finally be able to
hibernate the machine instead of keeping it up or shutting it down.
Tested on my powermac with forced preemption enabled.
---
arch/powerpc/Kconfig | 5
arch/powerpc/kernel/Makefile | 1
arch/powerpc/kernel/asm-offsets.c | 4
arch/powerpc/kernel/idle.c | 5
arch/powerpc/kernel/swsusp.c | 9 +
arch/powerpc/kernel/swsusp_64.c | 24 +++
arch/powerpc/kernel/swsusp_asm64.S | 228 +++++++++++++++++++++++++++++++++++++
include/linux/suspend.h | 2
kernel/power/Kconfig | 4
9 files changed, 276 insertions(+), 6 deletions(-)
--- wireless-dev.orig/arch/powerpc/kernel/Makefile 2007-05-03 14:21:02.139165535 +0200
+++ wireless-dev/arch/powerpc/kernel/Makefile 2007-05-03 14:21:10.859165535 +0200
@@ -38,6 +38,7 @@ obj-$(CONFIG_6xx) += idle_6xx.o l2cr_6x
obj-$(CONFIG_TAU) += tau_6xx.o
obj-$(CONFIG_SOFTWARE_SUSPEND) += swsusp.o
obj32-$(CONFIG_SOFTWARE_SUSPEND) += swsusp_32.o
+obj64-$(CONFIG_SOFTWARE_SUSPEND) += swsusp_64.o swsusp_asm64.o
obj32-$(CONFIG_MODULES) += module_32.o
ifeq ($(CONFIG_PPC_MERGE),y)
--- wireless-dev.orig/kernel/power/Kconfig 2007-05-03 14:20:25.629165535 +0200
+++ wireless-dev/kernel/power/Kconfig 2007-05-03 14:21:10.869165535 +0200
@@ -79,7 +79,7 @@ config PM_SYSFS_DEPRECATED
config SOFTWARE_SUSPEND
bool "Software Suspend"
- depends on PM && SWAP && ((X86 && (!SMP || SUSPEND_SMP)) || ((FRV || PPC32) && !SMP))
+ depends on PM && SWAP && (((X86 || PPC64_SWSUSP) && (!SMP || SUSPEND_SMP)) || ((FRV || PPC32) && !SMP))
---help---
Enable the suspend to disk (STD) functionality.
@@ -134,7 +134,7 @@ config PM_STD_PARTITION
config SUSPEND_SMP
bool
- depends on HOTPLUG_CPU && X86 && PM
+ depends on HOTPLUG_CPU && (X86 || PPC64) && PM
default y
config APM_EMULATION
--- wireless-dev.orig/include/linux/suspend.h 2007-05-03 14:21:06.929165535 +0200
+++ wireless-dev/include/linux/suspend.h 2007-05-03 14:21:10.869165535 +0200
@@ -1,7 +1,7 @@
#ifndef _LINUX_SWSUSP_H
#define _LINUX_SWSUSP_H
-#if defined(CONFIG_X86) || defined(CONFIG_FRV) || defined(CONFIG_PPC32)
+#if defined(CONFIG_X86) || defined(CONFIG_FRV) || defined(CONFIG_PPC32) || defined(CONFIG_PPC64)
#include <asm/suspend.h>
#endif
#include <linux/swap.h>
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ wireless-dev/arch/powerpc/kernel/swsusp_64.c 2007-05-03 14:21:10.869165535 +0200
@@ -0,0 +1,24 @@
+/*
+ * PowerPC 64-bit swsusp implementation
+ *
+ * Copyright 2006 Johannes Berg <johannes@sipsolutions.net>
+ *
+ * GPLv2
+ */
+
+#include <asm/system.h>
+#include <asm/iommu.h>
+#include <linux/irq.h>
+#include <linux/interrupt.h>
+
+void do_after_copyback(void)
+{
+ iommu_restore();
+ touch_softlockup_watchdog();
+ mb();
+}
+
+void _iommu_save(void)
+{
+ iommu_save();
+}
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ wireless-dev/arch/powerpc/kernel/swsusp_asm64.S 2007-05-03 14:21:10.869165535 +0200
@@ -0,0 +1,228 @@
+/*
+ * PowerPC 64-bit swsusp implementation
+ *
+ * Copyright 2006 Johannes Berg <johannes@sipsolutions.net>
+ *
+ * GPLv2
+ */
+
+#include <linux/threads.h>
+#include <asm/processor.h>
+#include <asm/page.h>
+#include <asm/cputable.h>
+#include <asm/thread_info.h>
+#include <asm/ppc_asm.h>
+#include <asm/asm-offsets.h>
+
+/*
+ * Structure for storing CPU registers on the save area.
+ */
+#define SL_r1 0x00 /* stack pointer */
+#define SL_PC 0x08
+#define SL_MSR 0x10
+#define SL_SDR1 0x18
+#define SL_XER 0x20
+#define SL_TB 0x40
+#define SL_r2 0x48
+#define SL_CR 0x50
+#define SL_LR 0x58
+#define SL_r12 0x60
+#define SL_r13 0x68
+#define SL_r14 0x70
+#define SL_r15 0x78
+#define SL_r16 0x80
+#define SL_r17 0x88
+#define SL_r18 0x90
+#define SL_r19 0x98
+#define SL_r20 0xa0
+#define SL_r21 0xa8
+#define SL_r22 0xb0
+#define SL_r23 0xb8
+#define SL_r24 0xc0
+#define SL_r25 0xc8
+#define SL_r26 0xd0
+#define SL_r27 0xd8
+#define SL_r28 0xe0
+#define SL_r29 0xe8
+#define SL_r30 0xf0
+#define SL_r31 0xf8
+#define SL_SIZE SL_r31+8
+
+/* these macros rely on the save area being
+ * pointed to by r11 */
+#define SAVE_SPECIAL(special) \
+ mf##special r0 ;\
+ std r0, SL_##special(r11)
+#define RESTORE_SPECIAL(special) \
+ ld r0, SL_##special(r11) ;\
+ mt##special r0
+#define SAVE_REGISTER(reg) \
+ std reg, SL_##reg(r11)
+#define RESTORE_REGISTER(reg) \
+ ld reg, SL_##reg(r11)
+
+/* space for storing cpu state */
+ .section .data
+ .align 5
+swsusp_save_area:
+ .space SL_SIZE
+
+ .section ".toc","aw"
+swsusp_save_area_ptr:
+ .tc swsusp_save_area[TC],swsusp_save_area
+restore_pblist_ptr:
+ .tc restore_pblist[TC],restore_pblist
+
+ .section .text
+ .align 5
+_GLOBAL(swsusp_arch_suspend)
+ ld r11,swsusp_save_area_ptr@toc(r2)
+ SAVE_SPECIAL(LR)
+ SAVE_REGISTER(r1)
+ SAVE_SPECIAL(CR)
+ SAVE_SPECIAL(TB)
+ SAVE_REGISTER(r2)
+ SAVE_REGISTER(r12)
+ SAVE_REGISTER(r13)
+ SAVE_REGISTER(r14)
+ SAVE_REGISTER(r15)
+ SAVE_REGISTER(r16)
+ SAVE_REGISTER(r17)
+ SAVE_REGISTER(r18)
+ SAVE_REGISTER(r19)
+ SAVE_REGISTER(r20)
+ SAVE_REGISTER(r21)
+ SAVE_REGISTER(r22)
+ SAVE_REGISTER(r23)
+ SAVE_REGISTER(r24)
+ SAVE_REGISTER(r25)
+ SAVE_REGISTER(r26)
+ SAVE_REGISTER(r27)
+ SAVE_REGISTER(r28)
+ SAVE_REGISTER(r29)
+ SAVE_REGISTER(r30)
+ SAVE_REGISTER(r31)
+ SAVE_SPECIAL(MSR)
+ SAVE_SPECIAL(SDR1)
+ SAVE_SPECIAL(XER)
+
+ /* we push the stack up 128 bytes but don't store the
+ * stack pointer on the stack like a real stackframe */
+ addi r1,r1,-128
+
+ bl _iommu_save
+ bl swsusp_save
+
+ /* restore LR */
+ ld r11,swsusp_save_area_ptr@toc(r2)
+ RESTORE_SPECIAL(LR)
+ addi r1,r1,128
+
+ blr
+
+/* Resume code */
+_GLOBAL(swsusp_arch_resume)
+ /* Stop pending alitvec streams and memory accesses */
+BEGIN_FTR_SECTION
+ DSSALL
+END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
+ sync
+
+ ld r12,restore_pblist_ptr@toc(r2)
+ ld r12,0(r12)
+
+ cmpdi r12,0
+ beq- nothing_to_copy
+ li r15,512
+copyloop:
+ ld r13,pbe_address(r12)
+ ld r14,pbe_orig_address(r12)
+
+ mtctr r15
+ li r10,0
+copy_page_loop:
+ ldx r0,r10,r13
+ stdx r0,r10,r14
+ addi r10,r10,8
+ bdnz copy_page_loop
+
+ ld r12,pbe_next(r12)
+ cmpdi r12,0
+ bne+ copyloop
+nothing_to_copy:
+
+ /* flush caches */
+ lis r3, 0x10
+ mtctr r3
+ li r3, 0
+ ori r3, r3, CONFIG_KERNEL_START>>48
+ li r0, 48
+ sld r3, r3, r0
+ li r0, 0
+1:
+ dcbf r0,r3
+ addi r3,r3,0x20
+ bdnz 1b
+
+ sync
+
+ tlbia
+
+ ld r11,swsusp_save_area_ptr@toc(r2)
+
+ RESTORE_SPECIAL(CR)
+
+ /* restore timebase */
+ /* load saved tb */
+ ld r1, SL_TB(r11)
+ /* get upper 32 bits of it */
+ srdi r2, r1, 32
+ /* clear tb lower to avoid wrap */
+ li r0, 0
+ mttbl r0
+ /* set tb upper */
+ mttbu r2
+ /* set tb lower */
+ mttbl r1
+
+ /* restore registers */
+ RESTORE_REGISTER(r1)
+ RESTORE_REGISTER(r2)
+ RESTORE_REGISTER(r12)
+ RESTORE_REGISTER(r13)
+ RESTORE_REGISTER(r14)
+ RESTORE_REGISTER(r15)
+ RESTORE_REGISTER(r16)
+ RESTORE_REGISTER(r17)
+ RESTORE_REGISTER(r18)
+ RESTORE_REGISTER(r19)
+ RESTORE_REGISTER(r20)
+ RESTORE_REGISTER(r21)
+ RESTORE_REGISTER(r22)
+ RESTORE_REGISTER(r23)
+ RESTORE_REGISTER(r24)
+ RESTORE_REGISTER(r25)
+ RESTORE_REGISTER(r26)
+ RESTORE_REGISTER(r27)
+ RESTORE_REGISTER(r28)
+ RESTORE_REGISTER(r29)
+ RESTORE_REGISTER(r30)
+ RESTORE_REGISTER(r31)
+ /* can't use RESTORE_SPECIAL(MSR) */
+ ld r0, SL_MSR(r11)
+ mtmsrd r0, 0
+ RESTORE_SPECIAL(SDR1)
+ RESTORE_SPECIAL(XER)
+
+ sync
+
+ addi r1,r1,-128
+ bl slb_flush_and_rebolt
+ bl do_after_copyback
+ addi r1,r1,128
+
+ ld r11,swsusp_save_area_ptr@toc(r2)
+ RESTORE_SPECIAL(LR)
+
+ li r3, 0
+ blr
--- wireless-dev.orig/arch/powerpc/kernel/asm-offsets.c 2007-05-03 14:20:25.519165535 +0200
+++ wireless-dev/arch/powerpc/kernel/asm-offsets.c 2007-05-03 14:21:10.869165535 +0200
@@ -21,12 +21,12 @@
#include <linux/types.h>
#include <linux/mman.h>
#include <linux/mm.h>
+#include <linux/suspend.h>
#ifdef CONFIG_PPC64
#include <linux/time.h>
#include <linux/hardirq.h>
#else
#include <linux/ptrace.h>
-#include <linux/suspend.h>
#endif
#include <asm/io.h>
@@ -257,11 +257,11 @@ int main(void)
DEFINE(CPU_SPEC_SETUP, offsetof(struct cpu_spec, cpu_setup));
DEFINE(CPU_SPEC_RESTORE, offsetof(struct cpu_spec, cpu_restore));
-#ifndef CONFIG_PPC64
DEFINE(pbe_address, offsetof(struct pbe, address));
DEFINE(pbe_orig_address, offsetof(struct pbe, orig_address));
DEFINE(pbe_next, offsetof(struct pbe, next));
+#ifndef CONFIG_PPC64
DEFINE(TASK_SIZE, TASK_SIZE);
DEFINE(NUM_USER_SEGMENTS, TASK_SIZE>>28);
#endif /* ! CONFIG_PPC64 */
--- wireless-dev.orig/arch/powerpc/kernel/idle.c 2007-05-03 14:20:25.539165535 +0200
+++ wireless-dev/arch/powerpc/kernel/idle.c 2007-05-03 14:21:10.869165535 +0200
@@ -33,8 +33,11 @@
#include <asm/smp.h>
#ifdef CONFIG_HOTPLUG_CPU
+/* this is used for software suspend, and that shuts down
+ * CPUs even while the system is still booting... */
#define cpu_should_die() (cpu_is_offline(smp_processor_id()) && \
- system_state == SYSTEM_RUNNING)
+ (system_state == SYSTEM_RUNNING \
+ || system_state == SYSTEM_BOOTING))
#else
#define cpu_should_die() 0
#endif
--- wireless-dev.orig/arch/powerpc/kernel/swsusp.c 2007-05-03 14:21:02.139165535 +0200
+++ wireless-dev/arch/powerpc/kernel/swsusp.c 2007-05-03 14:21:10.869165535 +0200
@@ -32,6 +32,11 @@ void save_processor_state(void)
#ifdef CONFIG_SPE
enable_kernel_spe();
#endif
+
+#ifdef CONFIG_PPC64
+ hard_irq_disable();
+#endif
+
}
void restore_processor_state(void)
@@ -39,4 +44,8 @@ void restore_processor_state(void)
#ifdef CONFIG_PPC32
set_context(current->active_mm->context.id, current->active_mm->pgd);
#endif
+
+#ifdef CONFIG_PPC64
+ hard_irq_enable();
+#endif
}
--- wireless-dev.orig/arch/powerpc/Kconfig 2007-05-03 14:21:03.969165535 +0200
+++ wireless-dev/arch/powerpc/Kconfig 2007-05-03 14:21:10.869165535 +0200
@@ -126,6 +126,11 @@ config DEFAULT_UIMAGE
Used to allow a board to specify it wants a uImage built by default
default n
+config PPC64_SWSUSP
+ bool
+ depends on PPC64 && (BROKEN || (PPC_PMAC64 && EXPERIMENTAL))
+ default y
+
menu "Processor support"
choice
prompt "Processor Type"
^ permalink raw reply
* Re: [PATCH] powerpc: dart iommu suspend
From: Benjamin Herrenschmidt @ 2007-05-03 12:30 UTC (permalink / raw)
To: Johannes Berg; +Cc: Olof Johansson, linuxppc-dev, Paul Mackerras
In-Reply-To: <1178195312.13233.111.camel@johannes.berg>
On Thu, 2007-05-03 at 14:28 +0200, Johannes Berg wrote:
> This implements save and restore hooks for IOMMUs and implements
> it the dart iommu.
Paul and I have been discussing a possible better way to handle that ...
We could just make the DART pages CI in the linear mapping rather than
not mapping it. That would make it "just work" with the normal code
path.
Ben.
^ permalink raw reply
* Re: powerpc_flash_init(), wtf!?
From: David Gibson @ 2007-05-03 12:30 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev
In-Reply-To: <4639CBD8.6010205@ru.mvista.com>
On Thu, May 03, 2007 at 03:47:36PM +0400, Sergei Shtylyov wrote:
> Hello.
>
> David Gibson wrote:
>
> >powerpc_flash_init(), the only function in arch/powerpc/sysdev/rom.c,
> >goes through the device tree finding anything with device_type=="rom"
> >and creating of_platform devices for them, which will be picked up by
> >the physmap_of mtd driver. This has two serious conceptual errors and
> >one bad implementation error which is quite an accomplishment for 15
> >lines of code.
>
> >Most seriously, this "find all roms" approach to probing is
> >fundamentally incompatible with the normal way of probing for
> >of_platform devices, to wit, using of_platform_bus_probe(). If a
>
> We weren't aware of the of_platform.c work when writing the MTD support.
> Note that this function usually probes only the specified set of (SoC)
> busses, none of which usully contains NOR flash (which is located at the
> root level).
The root level? Um... I don't think so...
> >flash is on a bus probed with of_platform_bus_probe()
> >powerpc_flash_init() will create a duplicate of_platform device for it.
>
> Flash on a SoC bus? Well, that's more likely to happen for NAND.
> But generally, I'd agree with you.
Well, on Ebony, the (NOR) flash is on the bus controlled by the
440gp's external bus controller (EBC). So it's not an SoC bus as
such, but it's still a "dumb bus" (to use BenH's terminology) which
can be suitably probed by of_platform_bus_probe().
I believe the arrangement is similar for most other 4xx systems. More
PC or desktop like systems sometimes have boot flash connected to the
south bridge, which I believe puts it on the ISA bus, topologically
speaking.
> > powerpc_flash_init() could also mistakenly probe roms which
> >appear on other random busses which should use their own probe logic
> >instead of going straight off the device tree (admittedly flash is
> >unlikely to appear on such a bus).
>
> Well, if you consider NAND...
>
> >Also, it uses the device node's name without unit address as the
> >of_platform device's name. So if a bus somewhere has two flash
> >devices named, say "flash@0" and "flash@800000", the device code will
> >give a stack dump during boot as powerpc_flash_init() attempts to
> >register them both under the name "flash".
>
> Well, we didn't think about 2 flashes named the same way. :-/
>
> >I observe that none of the dts files actually present in the kernel
> >tree use physmap_of's format for describing flash devices (and
> >therefore don't use this code). I'm therefore rather tempted to
>
> Which means I still haven't submitted the patch. :-<
>
> >simply blow arch/powerpc/sysdev/rom.c away, and anyone out-of-tree
> >relying on this code will have to fix their platform probing code to
> >create the flash of_platform devices properly.
>
> You mean creating the "rom" devices from the platform-specific code?
> I doubt that it's really a flexible approach...
Since it's handled on a per-platform basis, it's more-or-less by
definition more flexible than the current broken approach.
> >Unless someone who actually knows how this code was intended to be
> >used can suggest a more polite way of fixing it.
>
> Well, probably it needs to only look up the root bus...
Really, truly on the root bus? Even so I don't think such a probe
should be conducted as an initcall whenever CONFIG_MTD is set. A
helper function invoked from the platform code might be reasonable.
--
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
* Re: [PATCH] powerpc: dart iommu suspend
From: Johannes Berg @ 2007-05-03 12:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Olof Johansson, linuxppc-dev, Paul Mackerras
In-Reply-To: <1178195447.6353.40.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 390 bytes --]
On Thu, 2007-05-03 at 22:30 +1000, Benjamin Herrenschmidt wrote:
> We could just make the DART pages CI in the linear mapping rather than
> not mapping it. That would make it "just work" with the normal code
> path.
I didn't think that was even possible because it's mapped in larger
blocks than that. If it is then all this hackery can go, I'm not
attached to it...
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: dart iommu suspend
From: Benjamin Herrenschmidt @ 2007-05-03 12:34 UTC (permalink / raw)
To: Johannes Berg; +Cc: Olof Johansson, linuxppc-dev, Paul Mackerras
In-Reply-To: <1178195662.13233.118.camel@johannes.berg>
On Thu, 2007-05-03 at 14:34 +0200, Johannes Berg wrote:
> On Thu, 2007-05-03 at 22:30 +1000, Benjamin Herrenschmidt wrote:
>
> > We could just make the DART pages CI in the linear mapping rather than
> > not mapping it. That would make it "just work" with the normal code
> > path.
>
> I didn't think that was even possible because it's mapped in larger
> blocks than that. If it is then all this hackery can go, I'm not
> attached to it...
Well.. the linear mapping is mapped with 16M pages. The DART only uses a
couple of MB but we blast an entire 16M page for it because of that ...
We could probably just map that 16MB page CI rather than not mapping it
and later on ioremapping the DART.
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: dart iommu suspend
From: Johannes Berg @ 2007-05-03 12:48 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Olof Johansson, linuxppc-dev, Paul Mackerras
In-Reply-To: <1178195447.6353.40.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 466 bytes --]
On Thu, 2007-05-03 at 22:30 +1000, Benjamin Herrenschmidt wrote:
> That would make it "just work" with the normal code path.
We still need the iommu restore hook to invalidate the entries, so that
API I add there is needed anyway. Who actually saves the code doesn't
really matter at that point. The save hook isn't strictly necessary then
but I guess it should be there for symmetry anyway.
Maybe somebody can offer opinions on other iommus?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: powerpc_flash_init(), wtf!?
From: Sergei Shtylyov @ 2007-05-03 13:04 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070503123055.GE26659@localhost.localdomain>
Hello.
David Gibson wrote:
>>>powerpc_flash_init(), the only function in arch/powerpc/sysdev/rom.c,
>>>goes through the device tree finding anything with device_type=="rom"
>>>and creating of_platform devices for them, which will be picked up by
>>>the physmap_of mtd driver. This has two serious conceptual errors and
>>>one bad implementation error which is quite an accomplishment for 15
>>>lines of code.
>>>Most seriously, this "find all roms" approach to probing is
>>>fundamentally incompatible with the normal way of probing for
>>>of_platform devices, to wit, using of_platform_bus_probe(). If a
>> We weren't aware of the of_platform.c work when writing the MTD support.
>> Note that this function usually probes only the specified set of (SoC)
>>busses, none of which usully contains NOR flash (which is located at the
>>root level).
> The root level? Um... I don't think so...
"Trust me". :-)
NOR flashes are at the same level as the "memory" node (where else you
expect them to appear I wonder?).
>>>flash is on a bus probed with of_platform_bus_probe()
>>>powerpc_flash_init() will create a duplicate of_platform device for it.
>> Flash on a SoC bus? Well, that's more likely to happen for NAND.
>>But generally, I'd agree with you.
> Well, on Ebony, the (NOR) flash is on the bus controlled by the
> 440gp's external bus controller (EBC). So it's not an SoC bus as
> such, but it's still a "dumb bus" (to use BenH's terminology) which
> can be suitably probed by of_platform_bus_probe().
Interesting...
> I believe the arrangement is similar for most other 4xx systems. More
> PC or desktop like systems sometimes have boot flash connected to the
> south bridge, which I believe puts it on the ISA bus, topologically
> speaking.
Not exactly. Boot flash is mapped beyond ISA address space on 386+ -- at
the top of 4GB (where the "reset vector" is). Although it may be dual mapped
below 1MB as well (I'm starting to forget x86 :-).
>>>powerpc_flash_init() could also mistakenly probe roms which
>>>appear on other random busses which should use their own probe logic
>>>instead of going straight off the device tree (admittedly flash is
>>>unlikely to appear on such a bus).
>> Well, if you consider NAND...
>>>Also, it uses the device node's name without unit address as the
>>>of_platform device's name. So if a bus somewhere has two flash
>>>devices named, say "flash@0" and "flash@800000", the device code will
>>>give a stack dump during boot as powerpc_flash_init() attempts to
>>>register them both under the name "flash".
>> Well, we didn't think about 2 flashes named the same way. :-/
>>>I observe that none of the dts files actually present in the kernel
>>>tree use physmap_of's format for describing flash devices (and
>>>therefore don't use this code). I'm therefore rather tempted to
>> Which means I still haven't submitted the patch. :-<
I hope to post a patch soon.
>>>simply blow arch/powerpc/sysdev/rom.c away, and anyone out-of-tree
>>>relying on this code will have to fix their platform probing code to
>>>create the flash of_platform devices properly.
>> You mean creating the "rom" devices from the platform-specific code?
>>I doubt that it's really a flexible approach...
> Since it's handled on a per-platform basis, it's more-or-less by
> definition more flexible than the current broken approach.
I'm worried about the code duplication.
>>>Unless someone who actually knows how this code was intended to be
>>>used can suggest a more polite way of fixing it.
>> Well, probably it needs to only look up the root bus...
> Really, truly on the root bus? Even so I don't think such a probe
> should be conducted as an initcall whenever CONFIG_MTD is set. A
> helper function invoked from the platform code might be reasonable.
Yeah, I agree. Probably doesn't even worth a function since for most
cases there's only one flash.
WBR, Sergei
^ permalink raw reply
* pci based on mpc8250
From: feng @ 2007-05-02 9:11 UTC (permalink / raw)
To: linuxppc-embedded
hi all:
I have been working on my pci for about 2 mounths ,but I can't work it out.
I list the problems I encounter here.Any suggestion will be welcome.
We want to send 208 bytes per frame.but it was send in several frames.
We try to disalbe the snoop bit in our program ,choose another dma band
width.the result it we can speed up the speed ,but it can't be checked
through by our check program.what confused us is that the data gets by our
software transferes through the hardware is right .
some one suggests that:
When snooping is not used and a memeory region is cacheable, you should
invalidate cache area (executing as much DCBI instructions as required)
corresponding to the transfer region after each transfer before read it by the
core. Refer to the Programming Environments Manual for 32-Bit Implementations
of the PowerPC Architecture, Chapter 8 Instruction Set, dcbi.
our Latency Timer Register value is 0xc4,and the cachline is 0x8
thank you for you attention.
feng
^ permalink raw reply
* Re: [PATCH 2/2] powerpc: change topology_init() to a subsys_initcall
From: Kevin Corry @ 2007-05-03 13:26 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, Carl Love, linux-kernel, Stephane Eranian
In-Reply-To: <1178154707.5338.11.camel@concordia.ozlabs.ibm.com>
Hi Michael,
On Wed May 2 2007 8:11 pm, Michael Ellerman wrote:
> On Wed, 2007-05-02 at 12:11 -0500, Kevin Corry wrote:
> > Change the powerpc version of topology_init() from an __initcall to
> > a subsys_initcall to match all other architectures.
> >
> > Signed-off-by: Kevin Corry <kevcorry@us.ibm.com>
> >
> > Index: linux-2.6.21/arch/powerpc/kernel/sysfs.c
> > ===================================================================
> > --- linux-2.6.21.orig/arch/powerpc/kernel/sysfs.c
> > +++ linux-2.6.21/arch/powerpc/kernel/sysfs.c
> > @@ -498,4 +498,4 @@ static int __init topology_init(void)
> >
> > return 0;
> > }
> > -__initcall(topology_init);
> > +subsys_initcall(topology_init);
>
> topology_init() depends on the register_one_node() stuff being
> available, which relies on register_node_type() being called AFAICT -
> which is a postcore_initcall(). So that's OK.
>
> It also creates sysfs files, which is OK because long before initcalls
> run vfs_caches_init() called mnt_init() which called sysfs_init().
>
> Just to be super safe it'd be good to diff your sysfs before and after
> the change. But assuming that show's nothing this looks fine to me.
I booted with and without this patch applied, and the file listings of /sys on
both kernels show no differences (other than timestamps).
Thanks for the feedback.
--
Kevin Corry
kevcorry@us.ibm.com
http://www.ibm.com/linux/
^ permalink raw reply
* Re: powerpc_flash_init(), wtf!?
From: Sergei Shtylyov @ 2007-05-03 13:28 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070503122213.GD26659@localhost.localdomain>
Hello.
David Gibson wrote:
>>>>>Unless someone who actually knows how this code was intended to be
>>>>>used can suggest a more polite way of fixing it.
>>>>I guess, the idea was for this stuff to be updated once one of the
>>>>dts inside boot/ would have physmap nodes added. I have
>>>>rom/physmap[dts] rehaul in my TODO list, but it has (so far at
>>>>least) little chance to happen during this merge window. Yet, if
>>>>someone has suggestions and/or some interest for this to be cured,
>>>>it will gain priority. Otherwise, I'll replace actual erroneous code
>>>>with kind of rant that it's up to BSP code to take care of
>>>>of_devices to be registered, using of_platform_bus_probe() or other
>>>>way.
>>>I'm having some trouble parsing that paragraph. At this stage I don't
>>>see any reason to hold off on tearing out arch/powerpc/sysdev/rom.c,
>>>any necessary changes to replace it will go in the platform code or
>> It doesn't seem a flexible enough approach. We could continue using
>>platform devices then.
> Sorry, I don't follow you.
Well, IIUC, the idea behind the device is to free the platform code of as
much burden of registering the platform devices itself as possible, isn't it?
>>>other places.
>> Any ideas where else?
> Not really. I don't immediately see a case where doing it from the
> platform code wouldn't be right.
BTW, is it legal/appropriate to specify device (not bus) types for
of_platform_bus_probe()?
WBR, Sergei
^ permalink raw reply
* Re: [PATCH v4] powerpc: 64K page support for kexec
From: Arnd Bergmann @ 2007-05-03 13:45 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Olof Johansson, Paul Mackerras, cbe-oss-dev, miltonm
In-Reply-To: <1178115551.24866.139.camel@luke-laptop>
On Wednesday 02 May 2007, Luke Browning wrote:
> This patch fixes a couple of kexec problems related to 64K page
> support in the kernel. =A0kexec issues a tlbie for each pte. =A0The
> parameters for the tlbie are the page size and the virtual address.
> Support was missing for the computation of these two parameters
> for 64K pages. =A0This patch adds that support.
>=20
> Same as previous versions without BUG_ON()s.
>=20
> Signed-off-by: Luke Browning <lukebrowning@us.ibm.com>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Acked-by: Olof Johansson <olof@lixom.net>
Acked-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
Paul, please include this in your next merge for 2.6.22.
^ permalink raw reply
* Re: [PATCH 10/13] powerpc: Add arch/powerpc mv64x60 PCI setup
From: Dale Farnsworth @ 2007-05-03 13:45 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200705030917.47037.arnd@arndb.de>
On Thu, May 03, 2007 at 09:17:46AM +0200, Arnd Bergmann wrote:
> On Wednesday 02 May 2007, Dale Farnsworth wrote:
>
> > Index: linux-2.6-powerpc-df/arch/powerpc/sysdev/Makefile
> > ===================================================================
> > --- linux-2.6-powerpc-df.orig/arch/powerpc/sysdev/Makefile
> > +++ linux-2.6-powerpc-df/arch/powerpc/sysdev/Makefile
> > @@ -16,6 +16,10 @@ obj-$(CONFIG_TSI108_BRIDGE) += tsi108_pc
> > obj-$(CONFIG_QUICC_ENGINE) += qe_lib/
> > obj-$(CONFIG_MV64X60) += mv64x60_pic.o mv64x60_dev.o
> >
> > +ifeq ($(CONFIG_PCI),y)
> > +obj-$(CONFIG_MV64X60) += mv64x60_pci.o
> > +endif
> > +
>
> I'd write this as
>
> mv64x60-$(CONFIG_INDIRECT_PCI) += mv64x60_pci.o
> obj-$(CONFIG_MV64X60) += mv64x60-y
>
> though that doesn't make much difference any more
>
> > +#ifdef CONFIG_SYSFS
> > +/* 32-bit hex or dec stringified number + '\n' */
> > +#define MV64X60_VAL_LEN_MAX 11
> > +#define MV64X60_PCICFG_CPCI_HOTSWAP 0x68
> > +
> > +DECLARE_MUTEX(mv64x60_hs_lock);
>
> Please avoid using struct semephores in new code, we now have struct mutex
> for this, which gets defined as
>
> static DEFINE_MUTEX(mv64x60_hs_mutex);
This is existing code being moved over from arch/ppc. I'll make the change.
> > +static ssize_t mv64x60_hs_reg_read(struct kobject *kobj, char *buf, loff_t off,
> > + size_t count)
> > +{
> > + u32 v;
> > + int save_exclude;
> > +
> > + if (off > 0)
> > + return 0;
> > + if (count < MV64X60_VAL_LEN_MAX)
> > + return -EINVAL;
> > +
> > + if (down_interruptible(&mv64x60_hs_lock))
> > + return -ERESTARTSYS;
> > + save_exclude = mv64x60_pci_exclude_bridge;
> > + mv64x60_pci_exclude_bridge = 0;
> > + early_read_config_dword(mv64x60_primary_hose, 0, PCI_DEVFN(0, 0),
> > + MV64X60_PCICFG_CPCI_HOTSWAP, &v);
>
> Why do you use early_read_config_dword, not pci_read_config_dword()?
As above, this is existing code being moved over from arch/ppc.
I'll make the change.
> > + mv64x60_pci_exclude_bridge = save_exclude;
> > + up(&mv64x60_hs_lock);
> > +
> > + return sprintf(buf, "0x%08x\n", v);
> > +}
>
> <snip>
>
> > +static int mv64x60_exclude_device(u_char bus, u_char devfn)
> > +{
> > + if ((bus == 0 || bus == mv64x60_pci2_busno) &&
> > + PCI_SLOT(devfn) == 0 && mv64x60_pci_exclude_bridge)
> > + return PCIBIOS_DEVICE_NOT_FOUND;
> > +
> > + return PCIBIOS_SUCCESSFUL;
> > +}
>
> The locking here looks wrong. If you call mv64x60_exclude_device() from one thread
> thread while another one is calling mv64x60_hs_reg_read(), the bridge will
> not be excluded.
Good catch. Again, it's existing code, but clearly there's a race here.
I'm guessing that the mutex above was just to prevent nesting of setting
mv64x60_pci_exclude_bridge. A fix for the race doesn't look easy.
I'll look into it.
Thanks,
-Dale
^ permalink raw reply
* Re: [PATCH 9/13] powerpc: Add arch/powerpc mv64x60 I2C platform data setup
From: @ 2007-05-03 13:06 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <200705030853.17749.arnd@arndb.de>
On Thu, May 03, 2007 at 08:53:17AM +0200, Arnd Bergmann wrote:
> On Wednesday 02 May 2007, Dale Farnsworth wrote:
> > +???????static int called_count;
> > +???????int instance = called_count++;
>
> I would think it's simpler to count the instances in the outer loop
> when looking for the devices than having a static counter here.
Maybe. I did it with passing an outer counter in a previous
incarnation. I'll look at it again.
> > + pdev = platform_device_register_simple(MV64XXX_I2C_CTLR_NAME,
> > + instance, r, 2);
> > + if (IS_ERR(pdev))
> > + return PTR_ERR(pdev);
> > +
> > + err = platform_device_add_data(pdev, &pdata, sizeof(pdata));
> > + if (err) {
> > + platform_device_unregister(pdev);
> > + return err;
>
> Doing the initialization in this order means that you have to add the
> devices before the driver is loaded. I haven't checked if you do
> the same thing in the oder places as well, but I think it would be
> better to do it open coded like
>
> pdev = platform_device_alloc(MV64XXX_I2C_CTLR_NAME, instance);
> if (!pdev)
> return -ENOMEM;
> err = platform_device_add_resources(pdev, r, 2);
> if (err)
> goto error;
> err = platform_device_add_data(pdev, &pdata, sizeof(pdata));
> if (err)
> goto error;
> err = platform_device_add(pdev);
> if (err)
> goto error;
> return pdev;
> error:
> platform_device_put(pdev);
> return ERR_PTR(err);
Makes sense to me. I'll change it (in all three places).
Thanks.
-Dale
^ permalink raw reply
* Re: [U-Boot-Users] Where do you find *.dtb files?
From: Alex Zeffertt @ 2007-05-03 13:55 UTC (permalink / raw)
To: Jerry Van Baren, linuxppc-embedded
In-Reply-To: <4639E6A9.2040708@smiths-aerospace.com>
Jerry Van Baren wrote:
> Alex Zeffertt wrote:
>> Hi all,
>>
>> I'm trying to boot linux-2.6.21-rc5 on my mpc832xemds board which is
>> running
>> u-boot 1.2.0.
>>
>> According to u-boot I need a device tree blob:
>>
>> => help bootm
>> bootm [addr [arg ...]]
>> - boot application image stored in memory
>> passing arguments 'arg ...'; when booting a Linux kernel,
>> 'arg' can be the address of an initrd image
>> When booting a Linux kernel which requires a flat
>> device-tree
>> a third argument is required which is the address of the
>> of the
>> device-tree blob. To boot that kernel without an initrd
>> image,
>> use a '-' for the second argument. If you do not pass a
>> third
>> a bd_info struct will be passed instead
>>
>>
>> Can anybody tell me where I can find one for this board?
>>
>> TIA,
>>
>> Alex
>
> Kernel tree under arch/powerpc/boot/dts?
> <http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=arch/powerpc/boot/dts;h=2591d25045401b8beea474a1b4e117527e478521;hb=HEAD>
>
>
> Best regards,
> gvb
Thanks Jerry. I've found
powerpc/arch/powerpc/boot/dts/mpc832x_mds.dts
... but when I try to compile it I get an error:
$ /opt/freescale/ltib/usr/bin/dtc -I dts -O dtb powerpc/arch/powerpc/boot/dts/mpc832x_mds.dts
DTC: dts->dtb on file "powerpc/arch/powerpc/boot/dts/mpc832x_mds.dts"
syntax error at line 14
FATAL ERROR: Couldn't read input tree
Perhaps my dtc is out of date - it came with the BSP from freescale which uses
the 2.6.11 kernel.
Do you know where I can find an up to date dtc? Is there any documentation regarding its use?
Regards,
Alex
^ permalink raw reply
* Writing an AC97 device driver for MPC52xx
From: spitzauer_77 @ 2007-05-03 14:22 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
i try to write device driver for an AC97 external codec on MPC5200 controller. The PSC1 and 2 on MPC5200 can be configured as AC97.
I'm a little bit new in this topic of writing linux drivers and read a lot in the internet about this. (e.g. http://www.alsa-project.org/~iwai/writing-an-alsa-driver/x1052.htm )
But i have some questions:
- Is there a simple driver maybe on other platforms available, which have the same problem solved?? Most of the sound drivers are coupled with pci.
- I only have to write the pure hardware (PSC) stuff, or?? I'm little confused on how i should handle this with AC97 (ac97_codec.c) and ALSA.
- Is this for my driver the correct layer:
User App -> ALSA -> AC97 -> "My driver" -> Hardware MPC52xx
I'm glad for any hint!
Spitzauer
--
"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail
^ permalink raw reply
* Re: [PATCH] powerpc: dart iommu suspend
From: Olof Johansson @ 2007-05-03 14:24 UTC (permalink / raw)
To: Johannes Berg; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <1178196492.8233.1.camel@johannes.berg>
On Thu, May 03, 2007 at 02:48:11PM +0200, Johannes Berg wrote:
> On Thu, 2007-05-03 at 22:30 +1000, Benjamin Herrenschmidt wrote:
> > That would make it "just work" with the normal code path.
>
> We still need the iommu restore hook to invalidate the entries, so that
> API I add there is needed anyway. Who actually saves the code doesn't
> really matter at that point. The save hook isn't strictly necessary then
> but I guess it should be there for symmetry anyway.
>
> Maybe somebody can offer opinions on other iommus?
The PWRficient iommu shouldn't need any special considerations here, our
in-memory table is kept in regular coherent memory, so as long as that
is saved and restored (and hooks to clear out old cached TLB entries, etc
are called), everything should just work. No need to copy things around.
So yes, we'd still need the hooks, at least the restore one. And as you
say, keeping the save one there for symmetry makes sense.
I don't know what's happened to the IBM bloa^WPAPR platforms the last
year and a half, but last I looked at them you would essentially need
to scan out all entries from firmware by hand and save them away. So
they'd need both save and restore hooks.
-Olof
^ permalink raw reply
* Re: [U-Boot-Users] Where do you find *.dtb files?
From: Jerry Van Baren @ 2007-05-03 14:05 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linuxppc-embedded
In-Reply-To: <4639E9BF.40902@cambridgebroadband.com>
Alex Zeffertt wrote:
> Jerry Van Baren wrote:
>> Alex Zeffertt wrote:
>>> Hi all,
>>>
>>> I'm trying to boot linux-2.6.21-rc5 on my mpc832xemds board which is
>>> running
>>> u-boot 1.2.0.
>>>
>>> According to u-boot I need a device tree blob:
>>>
>>> => help bootm
>>> bootm [addr [arg ...]]
>>> - boot application image stored in memory
>>> passing arguments 'arg ...'; when booting a Linux kernel,
>>> 'arg' can be the address of an initrd image
>>> When booting a Linux kernel which requires a flat
>>> device-tree
>>> a third argument is required which is the address of the
>>> of the
>>> device-tree blob. To boot that kernel without an initrd
>>> image,
>>> use a '-' for the second argument. If you do not pass a
>>> third
>>> a bd_info struct will be passed instead
>>>
>>>
>>> Can anybody tell me where I can find one for this board?
>>>
>>> TIA,
>>>
>>> Alex
>>
>> Kernel tree under arch/powerpc/boot/dts?
>> <http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=arch/powerpc/boot/dts;h=2591d25045401b8beea474a1b4e117527e478521;hb=HEAD>
>>
>>
>> Best regards,
>> gvb
>
> Thanks Jerry. I've found
>
> powerpc/arch/powerpc/boot/dts/mpc832x_mds.dts
>
> ... but when I try to compile it I get an error:
>
> $ /opt/freescale/ltib/usr/bin/dtc -I dts -O dtb
> powerpc/arch/powerpc/boot/dts/mpc832x_mds.dts
> DTC: dts->dtb on file "powerpc/arch/powerpc/boot/dts/mpc832x_mds.dts"
> syntax error at line 14
> FATAL ERROR: Couldn't read input tree
>
> Perhaps my dtc is out of date - it came with the BSP from freescale
> which uses
> the 2.6.11 kernel.
>
> Do you know where I can find an up to date dtc? Is there any
> documentation regarding its use?
>
> Regards,
> Alex
Hi Alex,
Yes, you need to update your dtc. The latest dtc can be gotten from:
http://jdl.com/git_repos/
My makefile looks like this (WARNING: it is whitespace damaged, you must
replace the eight spaces in the rules with tabs):
8<--------------------------------------------------------------------
#
# Make device tree blobs
#
src = $(wildcard *.dts)
out = $(src:.dts=.dtb)
asm = $(src:.dts=.dtb)
QUIET = #-q
RESERVE = -R 4
SIZE = -S 0x3000
all: $(out)
%.dtb : %.dts
dtc $(QUIET) $(RESERVE) $(SIZE) -b 0 -O dtb -f -o $@ $^
%.asm : %.dts
dtc $(QUIET) $(RESERVE) $(SIZE) -b 0 -O asm -f -o $@ $^
8<--------------------------------------------------------------------
Best regards,
gvb
^ 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;
as well as URLs for NNTP newsgroup(s).