* Re: [PATCH 6/7] mpc83xx: timer driver for PM wakeup
From: Anton Vorontsov @ 2007-10-27 10:46 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071023212502.GE30959@loki.buserror.net>
Hi Scott,
On Tue, Oct 23, 2007 at 04:25:02PM -0500, Scott Wood wrote:
> This is a driver for the mpc83xx's GTM4 timer. It's functionality
> is limited to providing a wakeup source for suspend-to-RAM.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
I think you can use dev_err(&dev->dev
> +static int __devinit gtm_probe(struct of_device *dev,
> + const struct of_device_id *match)
> +{
> + struct device_node *np = dev->node;
> + struct resource res;
> + int ret = 0;
> + u32 busfreq = fsl_get_sys_freq();
> + struct gtm_priv *priv;
> +
> + if (busfreq == 0) {
> + printk(KERN_ERR "gtm: No bus frequency in device tree.\n");
here
> + return -ENODEV;
> + }
> +
> + priv = kmalloc(sizeof(struct gtm_priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + spin_lock_init(&priv->lock);
> + dev_set_drvdata(&dev->dev, priv);
> +
> + ret = of_address_to_resource(np, 0, &res);
> + if (ret)
> + goto out;
> +
> + priv->irq = irq_of_parse_and_map(np, 0);
> + if (priv->irq == NO_IRQ) {
> + printk(KERN_ERR "mpc83xx-gtm exists in device tree "
> + "without an IRQ.\n");
and here.
Thanks,
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH] compat_ioctl: fix block device compat ioctl regression
From: Arnd Bergmann @ 2007-10-27 9:38 UTC (permalink / raw)
To: akpm, linuxppc-dev, Geert Uytterhoeven, Johannes Berg, Jens Axboe
Cc: linux-kernel, Philip Langdale
In-Reply-To: <47228A9E.80505@overt.org>
From: Philip Langdale <philipl@overt.org>
The conversion of handlers to compat_blkdev_ioctl accidentally
disabled handling of most ioctl numbers on block devices because
of a typo. Fix the one line to enable it all again.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
Mea Culpa. This should have been found by my testing, as it's clear
that most of my big patch never worked at all. Sorry for causing
problems for everyone involved here.
I'm attributing the patch to Philip, as he's the one who pointed
out to me what the fix is.
Arnd <><
--- a/block/compat_ioctl.c
+++ b/block/compat_ioctl.c
@@ -581,7 +581,7 @@ static int compat_blkdev_driver_ioctl(struct inode *inode, struct file *file,
{
int ret;
- switch (arg) {
+ switch (cmd) {
case HDIO_GET_UNMASKINTR:
case HDIO_GET_MULTCOUNT:
case HDIO_GET_KEEPSETTINGS:
^ permalink raw reply
* Re: [PATCH 1/2] PowerPC: Add 44x NDFC device-tree aware support
From: Thomas Gleixner @ 2007-10-27 8:46 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <200710270653.32459.sr@denx.de>
On Sat, 27 Oct 2007, Stefan Roese wrote:
> Hi Valentine,
>
> On Friday 26 October 2007, Valentine Barshak wrote:
> > This adds device-tree aware PowerPC 44x NDFC (NAND Flash Controller)
> > driver. The code is based on the original ndfc.c driver by Thomas Gleixner.
> > The major difference is that here we try to handle all chips found as one
> > mtd device instead of having a separate one on each chip.
> > The partition handling code is based on the physmap_of one.
> > The the first 4 bits of the "bank-mask" property show which of the 4 NDFC
> > banks have chips attached. The "bank-width" property is 1 for 8-bit flash
> > and 2 for a 16-bit one.
> >
> > Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> > Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
>
> Are you sure you have the Signed-off-by from Thomas already on this?
Definitely not.
tglx
^ permalink raw reply
* [PATCH] ppc4xx: mmu_mapin_ram bugfix for booting with mem<16 MB
From: Magnus Hjorth @ 2007-10-27 8:35 UTC (permalink / raw)
To: Grant Likely; +Cc: Linuxppc-embedded
In-Reply-To: <fa686aa40710261254r105530d4u2e95d96948030ed7@mail.gmail.com>
From: Magnus Hjorth <mh@omnisys.se>
This patch (for 2.6.23.1) fixes an unsigned arithmetic bug causing the
kernel to hang when booting with less than 16 MB of memory on ppc4xx.
Signed-off-by: Magnus Hjorth <mh@omnisys.se>
---
OK, trying to do this by the book now...
--- linux-2.6.23.1/arch/ppc/mm/4xx_mmu.c.orig 2007-10-27 10:14:42.000000000 +0200
+++ linux-2.6.23.1/arch/ppc/mm/4xx_mmu.c 2007-10-27 10:15:34.000000000 +0200
@@ -105,7 +105,7 @@ unsigned long __init mmu_mapin_ram(void)
return s;
}
- while (s <= (total_lowmem - LARGE_PAGE_SIZE_16M)) {
+ while (s + LARGE_PAGE_SIZE_16M <= total_lowmem) {
pmd_t *pmdp;
unsigned long val = p | _PMD_SIZE_16M | _PAGE_HWEXEC | _PAGE_HWWRITE;
@@ -120,7 +120,7 @@ unsigned long __init mmu_mapin_ram(void)
s += LARGE_PAGE_SIZE_16M;
}
- while (s <= (total_lowmem - LARGE_PAGE_SIZE_4M)) {
+ while (s + LARGE_PAGE_SIZE_4M <= total_lowmem) {
pmd_t *pmdp;
unsigned long val = p | _PMD_SIZE_4M | _PAGE_HWEXEC | _PAGE_HWWRITE;
^ permalink raw reply
* [PATCH/RFC] powerpc: Pass PID argument to _tlbie (WAS: Apparent kernel bug with GDB on ppc405)
From: Benjamin Herrenschmidt @ 2007-10-27 7:32 UTC (permalink / raw)
To: Matt Mackall; +Cc: linuxppc-dev list, Josh Boyer, Kumar Gala, linuxppc-embedded
In-Reply-To: <1193448653.18243.9.camel@pasglop>
Allright, so Matt, let me know if that fixes your problem with gdb, and
I'll clean the patch up a bit and submit it. I want to double check if
something similar may be needed for freescale booke.
Basically, the problem is that things like get_user_pages() can cause
COW operations which in turn call _tlbie() to be called for translations
that aren't in the current address space.
The current 40x and 44x implementation of _tlbie doesn't handle that
properly as it only invalidates entries in the current PID.
This is an attempt at fixing it. Untested, I just checked it builds for
arch/powerpc and arch/ppc. I also haven't looked whether the freescale
BookE _tlbie needs similar treatement (it will get passed the pid in r4
with that patch, so if it needs to do something with it, it can). Kumar,
can you have a look ?
Index: linux-work/arch/powerpc/mm/fault.c
===================================================================
--- linux-work.orig/arch/powerpc/mm/fault.c 2007-10-27 14:44:05.000000000 +1000
+++ linux-work/arch/powerpc/mm/fault.c 2007-10-27 16:57:50.000000000 +1000
@@ -309,7 +309,7 @@ good_area:
set_bit(PG_arch_1, &page->flags);
}
pte_update(ptep, 0, _PAGE_HWEXEC);
- _tlbie(address);
+ _tlbie(address, mm->context.id);
pte_unmap_unlock(ptep, ptl);
up_read(&mm->mmap_sem);
return 0;
Index: linux-work/include/asm-powerpc/tlbflush.h
===================================================================
--- linux-work.orig/include/asm-powerpc/tlbflush.h 2007-10-27 14:44:19.000000000 +1000
+++ linux-work/include/asm-powerpc/tlbflush.h 2007-10-27 16:57:50.000000000 +1000
@@ -1,5 +1,8 @@
#ifndef _ASM_POWERPC_TLBFLUSH_H
#define _ASM_POWERPC_TLBFLUSH_H
+
+#include <linux/mm.h>
+
/*
* TLB flushing:
*
@@ -16,9 +19,6 @@
*/
#ifdef __KERNEL__
-struct mm_struct;
-struct vm_area_struct;
-
#if defined(CONFIG_4xx) || defined(CONFIG_8xx) || defined(CONFIG_FSL_BOOKE)
/*
* TLB flushing for software loaded TLB chips
@@ -28,7 +28,7 @@ struct vm_area_struct;
* specific tlbie's
*/
-extern void _tlbie(unsigned long address);
+extern void _tlbie(unsigned long address, unsigned int pid);
#if defined(CONFIG_40x) || defined(CONFIG_8xx)
#define _tlbia() asm volatile ("tlbia; sync" : : : "memory")
@@ -44,13 +44,13 @@ static inline void flush_tlb_mm(struct m
static inline void flush_tlb_page(struct vm_area_struct *vma,
unsigned long vmaddr)
{
- _tlbie(vmaddr);
+ _tlbie(vmaddr, vma->vm_mm->context.id);
}
static inline void flush_tlb_page_nohash(struct vm_area_struct *vma,
unsigned long vmaddr)
{
- _tlbie(vmaddr);
+ _tlbie(vmaddr, vma->vm_mm->context.id);
}
static inline void flush_tlb_range(struct vm_area_struct *vma,
Index: linux-work/arch/powerpc/kernel/misc_32.S
===================================================================
--- linux-work.orig/arch/powerpc/kernel/misc_32.S 2007-10-27 16:58:33.000000000 +1000
+++ linux-work/arch/powerpc/kernel/misc_32.S 2007-10-27 17:08:32.000000000 +1000
@@ -288,7 +288,16 @@ _GLOBAL(_tlbia)
*/
_GLOBAL(_tlbie)
#if defined(CONFIG_40x)
+ /* We run the search with interrupts disabled because we have to change
+ * the PID and I don't want to preempt when that happens.
+ */
+ mfmsr r5
+ mfspr r6,SPRN_PID
+ wrteei 0
+ mtspr SPRN_PID,r4
tlbsx. r3, 0, r3
+ mtspr SPRN_PID,r6
+ wrtee r5
bne 10f
sync
/* There are only 64 TLB entries, so r3 < 64, which means bit 25 is clear.
@@ -297,23 +306,23 @@ _GLOBAL(_tlbie)
tlbwe r3, r3, TLB_TAG
isync
10:
+
#elif defined(CONFIG_44x)
- mfspr r4,SPRN_MMUCR
- mfspr r5,SPRN_PID /* Get PID */
- rlwimi r4,r5,0,24,31 /* Set TID */
+ mfspr r5,SPRN_MMUCR
+ rlwimi r5,r4,0,24,31 /* Set TID */
/* We have to run the search with interrupts disabled, even critical
* and debug interrupts (in fact the only critical exceptions we have
* are debug and machine check). Otherwise an interrupt which causes
* a TLB miss can clobber the MMUCR between the mtspr and the tlbsx. */
- mfmsr r5
+ mfmsr r4
lis r6,(MSR_EE|MSR_CE|MSR_ME|MSR_DE)@ha
addi r6,r6,(MSR_EE|MSR_CE|MSR_ME|MSR_DE)@l
- andc r6,r5,r6
+ andc r6,r4,r6
mtmsr r6
- mtspr SPRN_MMUCR,r4
+ mtspr SPRN_MMUCR,r5
tlbsx. r3, 0, r3
- mtmsr r5
+ mtmsr r4
bne 10f
sync
/* There are only 64 TLB entries, so r3 < 64,
Index: linux-work/arch/powerpc/mm/mmu_decl.h
===================================================================
--- linux-work.orig/arch/powerpc/mm/mmu_decl.h 2007-10-27 17:11:33.000000000 +1000
+++ linux-work/arch/powerpc/mm/mmu_decl.h 2007-10-27 17:11:58.000000000 +1000
@@ -61,12 +61,12 @@ extern unsigned long total_lowmem;
#define mmu_mapin_ram() (0UL)
#elif defined(CONFIG_4xx)
-#define flush_HPTE(X, va, pg) _tlbie(va)
+#define flush_HPTE(pid, va, pg) _tlbie(va, pid)
extern void MMU_init_hw(void);
extern unsigned long mmu_mapin_ram(void);
#elif defined(CONFIG_FSL_BOOKE)
-#define flush_HPTE(X, va, pg) _tlbie(va)
+#define flush_HPTE(pid, va, pg) _tlbie(va, pid)
extern void MMU_init_hw(void);
extern unsigned long mmu_mapin_ram(void);
extern void adjust_total_lowmem(void);
Index: linux-work/arch/ppc/kernel/misc.S
===================================================================
--- linux-work.orig/arch/ppc/kernel/misc.S 2007-10-27 17:15:25.000000000 +1000
+++ linux-work/arch/ppc/kernel/misc.S 2007-10-27 17:15:59.000000000 +1000
@@ -224,7 +224,16 @@ _GLOBAL(_tlbia)
*/
_GLOBAL(_tlbie)
#if defined(CONFIG_40x)
+ /* We run the search with interrupts disabled because we have to change
+ * the PID and I don't want to preempt when that happens.
+ */
+ mfmsr r5
+ mfspr r6,SPRN_PID
+ wrteei 0
+ mtspr SPRN_PID,r4
tlbsx. r3, 0, r3
+ mtspr SPRN_PID,r6
+ wrtee r5
bne 10f
sync
/* There are only 64 TLB entries, so r3 < 64, which means bit 25 is clear.
@@ -234,22 +243,21 @@ _GLOBAL(_tlbie)
isync
10:
#elif defined(CONFIG_44x)
- mfspr r4,SPRN_MMUCR
- mfspr r5,SPRN_PID /* Get PID */
- rlwimi r4,r5,0,24,31 /* Set TID */
+ mfspr r5,SPRN_MMUCR
+ rlwimi r5,r4,0,24,31 /* Set TID */
/* We have to run the search with interrupts disabled, even critical
* and debug interrupts (in fact the only critical exceptions we have
* are debug and machine check). Otherwise an interrupt which causes
* a TLB miss can clobber the MMUCR between the mtspr and the tlbsx. */
- mfmsr r5
+ mfmsr r4
lis r6,(MSR_EE|MSR_CE|MSR_ME|MSR_DE)@ha
addi r6,r6,(MSR_EE|MSR_CE|MSR_ME|MSR_DE)@l
- andc r6,r5,r6
+ andc r6,r4,r6
mtmsr r6
- mtspr SPRN_MMUCR,r4
+ mtspr SPRN_MMUCR,r5
tlbsx. r3, 0, r3
- mtmsr r5
+ mtmsr r4
bne 10f
sync
/* There are only 64 TLB entries, so r3 < 64,
Index: linux-work/arch/ppc/mm/fault.c
===================================================================
--- linux-work.orig/arch/ppc/mm/fault.c 2007-10-27 17:14:09.000000000 +1000
+++ linux-work/arch/ppc/mm/fault.c 2007-10-27 17:14:13.000000000 +1000
@@ -227,7 +227,7 @@ good_area:
set_bit(PG_arch_1, &page->flags);
}
pte_update(ptep, 0, _PAGE_HWEXEC);
- _tlbie(address);
+ _tlbie(address, mm->context.id);
pte_unmap_unlock(ptep, ptl);
up_read(&mm->mmap_sem);
return 0;
Index: linux-work/arch/ppc/mm/mmu_decl.h
===================================================================
--- linux-work.orig/arch/ppc/mm/mmu_decl.h 2007-10-27 17:14:43.000000000 +1000
+++ linux-work/arch/ppc/mm/mmu_decl.h 2007-10-27 17:14:54.000000000 +1000
@@ -54,12 +54,12 @@ extern unsigned int num_tlbcam_entries;
#define mmu_mapin_ram() (0UL)
#elif defined(CONFIG_4xx)
-#define flush_HPTE(X, va, pg) _tlbie(va)
+#define flush_HPTE(pid, va, pg) _tlbie(va, pid)
extern void MMU_init_hw(void);
extern unsigned long mmu_mapin_ram(void);
#elif defined(CONFIG_FSL_BOOKE)
-#define flush_HPTE(X, va, pg) _tlbie(va)
+#define flush_HPTE(pid, va, pg) _tlbie(va, pid)
extern void MMU_init_hw(void);
extern unsigned long mmu_mapin_ram(void);
extern void adjust_total_lowmem(void);
Index: linux-work/arch/ppc/platforms/4xx/ebony.c
===================================================================
--- linux-work.orig/arch/ppc/platforms/4xx/ebony.c 2007-10-27 17:13:38.000000000 +1000
+++ linux-work/arch/ppc/platforms/4xx/ebony.c 2007-10-27 17:13:40.000000000 +1000
@@ -236,7 +236,7 @@ ebony_early_serial_map(void)
gen550_init(0, &port);
/* Purge TLB entry added in head_44x.S for early serial access */
- _tlbie(UART0_IO_BASE);
+ _tlbie(UART0_IO_BASE, 0);
#endif
port.membase = ioremap64(PPC440GP_UART1_ADDR, 8);
Index: linux-work/arch/ppc/platforms/4xx/ocotea.c
===================================================================
--- linux-work.orig/arch/ppc/platforms/4xx/ocotea.c 2007-10-27 17:13:26.000000000 +1000
+++ linux-work/arch/ppc/platforms/4xx/ocotea.c 2007-10-27 17:13:28.000000000 +1000
@@ -259,7 +259,7 @@ ocotea_early_serial_map(void)
gen550_init(0, &port);
/* Purge TLB entry added in head_44x.S for early serial access */
- _tlbie(UART0_IO_BASE);
+ _tlbie(UART0_IO_BASE, 0);
#endif
port.membase = ioremap64(PPC440GX_UART1_ADDR, 8);
Index: linux-work/arch/ppc/platforms/4xx/taishan.c
===================================================================
--- linux-work.orig/arch/ppc/platforms/4xx/taishan.c 2007-10-27 17:13:47.000000000 +1000
+++ linux-work/arch/ppc/platforms/4xx/taishan.c 2007-10-27 17:13:50.000000000 +1000
@@ -316,7 +316,7 @@ taishan_early_serial_map(void)
gen550_init(0, &port);
/* Purge TLB entry added in head_44x.S for early serial access */
- _tlbie(UART0_IO_BASE);
+ _tlbie(UART0_IO_BASE, 0);
#endif
port.membase = ioremap64(PPC440GX_UART1_ADDR, 8);
^ permalink raw reply
* Re: [PATCH 1/2] PowerPC: Add 44x NDFC device-tree aware support
From: Stefan Roese @ 2007-10-27 4:53 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, tglx, linux-mtd
In-Reply-To: <20071026163958.GA11784@ru.mvista.com>
Hi Valentine,
On Friday 26 October 2007, Valentine Barshak wrote:
> This adds device-tree aware PowerPC 44x NDFC (NAND Flash Controller)
> driver. The code is based on the original ndfc.c driver by Thomas Gleixne=
r.
> The major difference is that here we try to handle all chips found as one
> mtd device instead of having a separate one on each chip.
> The partition handling code is based on the physmap_of one.
> The the first 4 bits of the "bank-mask" property show which of the 4 NDFC
> banks have chips attached. The "bank-width" property is 1 for 8-bit flash
> and 2 for a 16-bit one.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
Are you sure you have the Signed-off-by from Thomas already on this?
> ---
> =A0drivers/mtd/nand/Kconfig =A0 | =A0 =A07
> =A0drivers/mtd/nand/Makefile =A0| =A0 =A01
> =A0drivers/mtd/nand/ndfc_of.c | =A0449
> +++++++++++++++++++++++++++++++++++++++++++++ include/linux/mtd/ndfc.h =
=A0 |
> =A0 =A04
> =A04 files changed, 461 insertions(+)
>
> diff -pruN linux-2.6.orig/drivers/mtd/nand/Kconfig
> linux-2.6/drivers/mtd/nand/Kconfig ---
> linux-2.6.orig/drivers/mtd/nand/Kconfig=A0=A0=A0=A0=A02007-10-25 19:20:05=
=2E000000000
> +0400 +++ linux-2.6/drivers/mtd/nand/Kconfig=A0=A02007-10-26 16:16:20.000=
000000
> +0400 @@ -158,6 +158,13 @@ config MTD_NAND_NDFC
> =A0=A0=A0=A0=A0=A0=A0=A0help
> =A0=A0=A0=A0=A0=A0=A0=A0 NDFC Nand Flash Controllers are integrated in IB=
M/AMCC's 4xx SoCs
> =A0
> +config MTD_NAND_NDFC_OF
> +=A0=A0=A0=A0=A0=A0=A0tristate "NDFC OF Nand Flash Controller"
> +=A0=A0=A0=A0=A0=A0=A0depends on 44x
> +=A0=A0=A0=A0=A0=A0=A0select MTD_NAND_ECC_SMC
> +=A0=A0=A0=A0=A0=A0=A0help
> +=A0=A0=A0=A0=A0=A0=A0 NDFC OF Nand Flash Controllers are integrated in P=
owerPC44x SoCs
> +
> =A0config MTD_NAND_S3C2410_CLKSTOP
> =A0=A0=A0=A0=A0=A0=A0=A0bool "S3C2410 NAND IDLE clock stop"
> =A0=A0=A0=A0=A0=A0=A0=A0depends on MTD_NAND_S3C2410
> diff -pruN linux-2.6.orig/drivers/mtd/nand/Makefile
> linux-2.6/drivers/mtd/nand/Makefile ---
> linux-2.6.orig/drivers/mtd/nand/Makefile=A0=A0=A0=A02007-10-25 19:20:05.0=
00000000
> +0400 +++ linux-2.6/drivers/mtd/nand/Makefile=A02007-10-26 16:16:20.00000=
0000
> +0400 @@ -24,6 +24,7 @@ obj-$(CONFIG_MTD_NAND_TS7250)=A0=A0=A0=A0=A0=A0=
=A0=A0=A0+=3D ts7250
> =A0obj-$(CONFIG_MTD_NAND_NANDSIM)=A0=A0=A0=A0=A0=A0=A0=A0=A0+=3D nandsim.o
> =A0obj-$(CONFIG_MTD_NAND_CS553X)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0+=3D cs553x=
_nand.o
> =A0obj-$(CONFIG_MTD_NAND_NDFC)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0+=3D nd=
fc.o
> +obj-$(CONFIG_MTD_NAND_NDFC_OF)=A0=A0=A0=A0=A0=A0=A0=A0=A0+=3D ndfc_of.o
> =A0obj-$(CONFIG_MTD_NAND_AT91)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0+=3D at=
91_nand.o
> =A0obj-$(CONFIG_MTD_NAND_CM_X270)=A0=A0=A0=A0=A0=A0=A0=A0=A0+=3D cmx270_n=
and.o
> =A0obj-$(CONFIG_MTD_NAND_BASLER_EXCITE)=A0=A0=A0+=3D excite_nandflash.o
> diff -pruN linux-2.6.orig/drivers/mtd/nand/ndfc_of.c
> linux-2.6/drivers/mtd/nand/ndfc_of.c ---
> linux-2.6.orig/drivers/mtd/nand/ndfc_of.c=A0=A0=A01970-01-01 03:00:00.000=
000000
> +0300 +++ linux-2.6/drivers/mtd/nand/ndfc_of.c=A0=A0=A0=A0=A0=A0=A0=A0200=
7-10-26
> 17:28:57.000000000 +0400 @@ -0,0 +1,449 @@
> +/*
> + * =A0PowerPC 44x NDFC (NanD Flash Controller) driver
> + * =A0with OF device tree support.
> + *
> + * =A0Based on the original ndfc driver by Thomas Gleixner
> + *
> + * =A0Copyright 2006 IBM
> + *
> + * =A0This program is free software; you can redistribute=A0=A0=A0=A0=A0=
=A0=A0=A0 it and/or
> modify it + * =A0under =A0the terms of=A0=A0=A0=A0=A0=A0=A0=A0 the GNU Ge=
neral =A0Public License
> as published by the + * =A0Free Software Foundation; =A0either version 2 =
of
> the=A0License, or (at your + * =A0option) any later version.
> + *
> + */
> +#include <linux/module.h>
> +#include <linux/mtd/nand.h>
> +#include <linux/mtd/nand_ecc.h>
> +#include <linux/mtd/partitions.h>
> +#include <linux/mtd/ndfc.h>
> +#include <linux/mtd/mtd.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
> +
> +#include <asm/io.h>
> +
> +
> +struct of_ndfc {
> +=A0=A0=A0=A0=A0=A0=A0__iomem void=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0*ba=
se;
> +=A0=A0=A0=A0=A0=A0=A0struct resource=A0=A0=A0=A0=A0=A0=A0=A0=A0*res;
> +=A0=A0=A0=A0=A0=A0=A0unsigned=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0bank_width;
> +=A0=A0=A0=A0=A0=A0=A0unsigned =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0chip_cnt;
> +=A0=A0=A0=A0=A0=A0=A0unsigned char=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0chip_=
map[NDFC_MAX_BANKS];
> +=A0=A0=A0=A0=A0=A0=A0struct nand_hw_control=A0=A0control;
> +=A0=A0=A0=A0=A0=A0=A0struct nand_chip=A0=A0=A0=A0=A0=A0=A0=A0chip;
> +=A0=A0=A0=A0=A0=A0=A0struct mtd_info=A0=A0=A0=A0=A0=A0=A0=A0=A0mtd;
> +#ifdef CONFIG_MTD_PARTITIONS
> +=A0=A0=A0=A0=A0=A0=A0struct mtd_partition=A0=A0=A0=A0*parts;
> +#endif
> +};
> +
> +static inline u32 ndfc_raw_readl(struct of_ndfc *ndfc, u32 off)
> +{
> + return __raw_readl(ndfc->base + off);
> +}
> +
> +static inline void ndfc_raw_writel(struct of_ndfc *ndfc, u32 off, u32 va=
l)
> +{
> + __raw_writel(val, ndfc->base + off);
> +}
> +
> +static inline void ndfc_writel(struct of_ndfc *ndfc, u32 off, u32 val)
> +{
> + writel(val, ndfc->base + off);
> +}
> +
> +static void ndfc_select_chip(struct mtd_info *mtd, int chip)
> +{
> + struct nand_chip *this =3D mtd->priv;
> + struct of_ndfc *ndfc =3D this->priv;
> + uint32_t ccr;
> +
> + ccr =3D ndfc_raw_readl(ndfc, NDFC_CCR);
> + if ((chip >=3D 0) && (chip < ndfc->chip_cnt)) {
> + ccr &=3D ~NDFC_CCR_BS_MASK;
> + ccr |=3D NDFC_CCR_BS(ndfc->chip_map[chip]);
> + } else
> + ccr |=3D NDFC_CCR_RESET_CE;
> + ndfc_raw_writel(ndfc, NDFC_CCR, ccr);
> +}
> +
> +static void ndfc_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int
> ctrl) +{
> + struct nand_chip *this =3D mtd->priv;
> + struct of_ndfc *ndfc =3D this->priv;
> +
> + if (cmd =3D=3D NAND_CMD_NONE)
> + return;
> +
> + if (ctrl & NAND_CLE)
> + ndfc_writel(ndfc, NDFC_CMD, cmd & 0xff);
> + else
> + ndfc_writel(ndfc, NDFC_ALE, cmd & 0xff);
> +}
> +
> +static int ndfc_ready(struct mtd_info *mtd)
> +{
> + struct nand_chip *this =3D mtd->priv;
> + struct of_ndfc *ndfc =3D this->priv;
> +
> + return ndfc_raw_readl(ndfc, NDFC_STAT) & NDFC_STAT_IS_READY;
> +}
> +
> +static void ndfc_enable_hwecc(struct mtd_info *mtd, int mode)
> +{
> + uint32_t ccr;
> + struct nand_chip *this =3D mtd->priv;
> + struct of_ndfc *ndfc =3D this->priv;
> +
> + ccr =3D ndfc_raw_readl(ndfc, NDFC_CCR);
> + ccr |=3D NDFC_CCR_RESET_ECC;
> + ndfc_raw_writel(ndfc, NDFC_CCR, ccr);
> + wmb();
I suspect that when we use the in_be32() and friends functions for IO acces=
s,=20
the memory-barriers can go away.
> +}
> +
> +
> +static int ndfc_calculate_ecc(struct mtd_info *mtd,
> + const u_char *dat, u_char *ecc_code)
> +{
> + uint32_t ecc;
> + struct nand_chip *this =3D mtd->priv;
> + struct of_ndfc *ndfc =3D this->priv;
> + uint8_t *p =3D (uint8_t *)&ecc;
> +
> + wmb();
Same here.
> + ecc =3D ndfc_raw_readl(ndfc, NDFC_ECC);
> + ecc_code[0] =3D p[1];
> + ecc_code[1] =3D p[2];
> + ecc_code[2] =3D p[3];
> +
> + return 0;
> +}
> +
> +
> +/*
> + * Speedups for buffer read/write/verify
> + *
> + * NDFC allows 32bit read/write of data. So we can speed up the buffer
> + * functions. No further checking, as nand_base will always read/write
> + * page aligned.
> + */
> +static void ndfc_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
> +{
> + struct nand_chip *this =3D mtd->priv;
> + struct of_ndfc *ndfc =3D this->priv;
> + uint32_t *p =3D (uint32_t *) buf;
> +
> + for(;len > 0; len -=3D 4)
> + *p++ =3D ndfc_raw_readl(ndfc, NDFC_DATA);
> +}
> +
> +static void ndfc_write_buf(struct mtd_info *mtd, const uint8_t *buf, int
> len) +{
> + struct nand_chip *this =3D mtd->priv;
> + struct of_ndfc *ndfc =3D this->priv;
> + uint32_t *p =3D (uint32_t *) buf;
> +
> + for(;len > 0; len -=3D 4)
> + ndfc_raw_writel(ndfc, NDFC_DATA, *p++);
> +}
> +
> +static int ndfc_verify_buf(struct mtd_info *mtd, const uint8_t *buf, int
> len) +{
> + struct nand_chip *this =3D mtd->priv;
> + struct of_ndfc *ndfc =3D this->priv;
> + uint32_t *p =3D (uint32_t *) buf;
> +
> + for(;len > 0; len -=3D 4)
> + if (*p++ !=3D ndfc_raw_readl(ndfc, NDFC_DATA))
> + return -EFAULT;
> + return 0;
> +}
> +
> +
> +
> +static void ndfc_chip_init(struct nand_chip *chip,
> + struct of_ndfc *ndfc)
> +{
> + chip->IO_ADDR_R =3D ndfc->base + NDFC_DATA;
> + chip->IO_ADDR_W =3D ndfc->base + NDFC_DATA;
> + chip->cmd_ctrl =3D ndfc_hwcontrol;
> + chip->dev_ready =3D ndfc_ready;
> + chip->select_chip =3D ndfc_select_chip;
> + chip->chip_delay =3D 50;
> + chip->priv =3D ndfc;
> + if (ndfc->bank_width =3D=3D 2)
> + chip->options |=3D NAND_BUSWIDTH_16;
> + chip->controller =3D &ndfc->control;
> + chip->read_buf =3D ndfc_read_buf;
> + chip->write_buf =3D ndfc_write_buf;
> + chip->verify_buf =3D ndfc_verify_buf;
> + chip->ecc.correct =3D nand_correct_data;
> + chip->ecc.hwctl =3D ndfc_enable_hwecc;
> + chip->ecc.calculate =3D ndfc_calculate_ecc;
> + chip->ecc.mode =3D NAND_ECC_HW;
> + chip->ecc.size =3D 256;
> + chip->ecc.bytes =3D 3;
> + ndfc->mtd.priv =3D chip;
> + ndfc->mtd.owner =3D THIS_MODULE;
> +}
> +
> +
> +#ifdef CONFIG_MTD_PARTITIONS
> +#define OF_FLASH_PARTS(ndfc) ((ndfc)->parts)
> +
> +static int __devinit parse_partitions(struct of_ndfc *ndfc,
> + struct of_device *dev)
> +{
> + const char *partname;
> + static const char *part_probe_types[]
> + =3D { "cmdlinepart", "RedBoot", NULL };
> + struct device_node *dp =3D dev->node, *pp;
> + int nr_parts, i;
> +
> + /* First look for RedBoot table or partitions on the command
> + * line, these take precedence over device tree information */
> + nr_parts =3D parse_mtd_partitions(&ndfc->mtd, part_probe_types,
> + &ndfc->parts, 0);
> + if (nr_parts > 0) {
> + add_mtd_partitions(&ndfc->mtd, ndfc->parts, nr_parts);
> + return 0;
> + }
> +
> + /* First count the subnodes */
> + nr_parts =3D 0;
> + for (pp =3D dp->child; pp; pp =3D pp->sibling)
> + nr_parts++;
> +
> + if (nr_parts =3D=3D 0)
> + return 0;
> +
> + ndfc->parts =3D kzalloc(nr_parts * sizeof(*ndfc->parts),
> + GFP_KERNEL);
> + if (!ndfc->parts)
> + return -ENOMEM;
> +
> + for (pp =3D dp->child, i =3D 0; pp; pp =3D pp->sibling, i++) {
> + const u32 *reg;
> + int len;
> +
> + reg =3D of_get_property(pp, "reg", &len);
> + if (!reg || (len !=3D 2*sizeof(u32))) {
> + dev_err(&dev->dev, "Invalid 'reg' on %s\n",
> + dp->full_name);
> + kfree(ndfc->parts);
> + ndfc->parts =3D NULL;
> + return -EINVAL;
> + }
> + ndfc->parts[i].offset =3D reg[0];
> + ndfc->parts[i].size =3D reg[1];
> +
> + partname =3D of_get_property(pp, "label", &len);
> + if (!partname)
> + partname =3D of_get_property(pp, "name", &len);
> + ndfc->parts[i].name =3D (char *)partname;
> +
> + if (of_get_property(pp, "read-only", &len))
> + ndfc->parts[i].mask_flags =3D MTD_WRITEABLE;
> + }
> +
> + return nr_parts;
> +}
This parse_partition code looks very much like the code in the physmap_of=20
driver. I think it would be a good idea not to duplicate this code, but to=
=20
extract it and use one version in both drivers.
> +#else /* MTD_PARTITIONS */
> +#define OF_FLASH_PARTS(ndfc) (0)
> +#define parse_partitions(ndfc, dev) (0)
> +#endif /* MTD_PARTITIONS */
> +
> +
> +static int of_ndfc_remove(struct of_device *dev)
> +{
> + struct of_ndfc *ndfc;
> +
> + ndfc =3D dev_get_drvdata(&dev->dev);
> + if (!ndfc)
> + return 0;
> +
> + if (OF_FLASH_PARTS(ndfc)) {
> + del_mtd_partitions(&ndfc->mtd);
> + kfree(OF_FLASH_PARTS(ndfc));
> + } else {
> + del_mtd_device(&ndfc->mtd);
> + }
> + nand_release(&ndfc->mtd);
> +
> + dev_set_drvdata(&dev->dev, NULL);
> +
> + if (ndfc->base)
> + iounmap(ndfc->base);
> +
> + if (ndfc->res) {
> + release_resource(ndfc->res);
> + kfree(ndfc->res);
> + }
> +
> + kfree(ndfc);
> +
> + return 0;
> +}
> +
> +
> +static int __devinit ndfc_map_banks(struct of_ndfc *ndfc, const u32 *mas=
k)
> +{
> + unsigned cnt, i, tmp;
> + uint32_t bcr;
> +
> + if (!ndfc || !mask)
> + return -EINVAL;
> +
> + /* Disable all banks */
> + for (cnt =3D 0; cnt < NDFC_MAX_BANKS; cnt++) {
> + ndfc_raw_writel(ndfc, NDFC_BCFG0 + (cnt << 2), 0);
> + }
> +
> + /* Enable bank and set default RE/WE/CE timings */
> + bcr =3D NDFC_BxCFG_EN | NDFC_BxCFG_RR(2) | NDFC_BxCFG_RWH(2) |
> + NDFC_BxCFG_RWP(2) | NDFC_BxCFG_CRW(2);
> + if (ndfc->bank_width =3D=3D 2)
> + bcr |=3D NDFC_BxCFG_SZ_16BIT;
> +
> + cnt =3D 0;
> + tmp =3D *mask;
> + while ((i =3D ffs(tmp)) && (cnt < NDFC_MAX_BANKS)) {
> + i--;
> + tmp &=3D ~(1 << i);
> + ndfc->chip_map[cnt++] =3D i;
> + ndfc_raw_writel(ndfc, NDFC_BCFG0 + (i << 2), bcr);
> + }
> + ndfc->chip_cnt =3D cnt;
> + return cnt;
> +}
> +
> +
> +static int __devinit of_ndfc_probe(struct of_device *dev,
> + const struct of_device_id *match)
> +{
> + struct device_node *dp =3D dev->node;
> + struct resource res;
> + struct of_ndfc *ndfc;
> + const u32 *prop;
> + resource_size_t rlen;
> + int err;
> +
> + err =3D -ENXIO;
> + if (of_address_to_resource(dp, 0, &res)) {
> + dev_err(&dev->dev, "can't get IO address from device tree\n");
> + goto err_out;
> + }
> +
> + dev_dbg(&dev->dev, "regs: %.8llx-%.8llx\n",
> + (unsigned long long)res.start, (unsigned long long)res.end);
> +
> + ndfc =3D kzalloc(sizeof(struct of_ndfc), GFP_KERNEL);
> + if (!ndfc) {
> + err =3D -ENOMEM;
> + goto err_out;
> + }
> +
> + rlen =3D res.end - res.start + 1;
> + ndfc->res =3D request_mem_region(res.start, rlen, dev->dev.bus_id);
> + if (!ndfc->res) {
> + err =3D -EBUSY;
> + goto err_free_out;
> + }
> +
> + ndfc->base =3D ioremap(res.start, rlen);
> + if (!ndfc->base) {
> + err =3D -ENXIO;
> + goto err_rel_out;
> + }
> +
> + spin_lock_init(&ndfc->control.lock);
> + init_waitqueue_head(&ndfc->control.wq);
> +
> + prop =3D of_get_property(dp, "bank-width", NULL);
> + ndfc->bank_width =3D ((prop) && (*prop) =3D=3D 2) ? 2 : 1;
> +
> + prop =3D of_get_property(dp, "bank-mask", NULL);
> + err =3D ndfc_map_banks(ndfc, prop);
> + if (err <=3D 0) {
> + dev_err(&dev->dev, "no banks found\n");
> + err =3D -ENODEV;
> + goto err_unmap_out;
> + }
> +
> + ndfc_chip_init(&ndfc->chip, ndfc);
> + dev_set_drvdata(&dev->dev, ndfc);
> +
> + dev_info(&dev->dev, "NDFC driver initialized. Chip-Rev: 0x%08x\n",
> + ndfc_raw_readl(ndfc, NDFC_REVID));
> +
> + err =3D nand_scan_ident(&ndfc->mtd, ndfc->chip_cnt);
> + if (err)
> + goto err_dat_out;
> +
> + if ((ndfc->mtd.writesize !=3D 2048) && (ndfc->mtd.writesize !=3D 512)) {
> + dev_err(&dev->dev, "unexpected NAND flash writesize %d",
> + ndfc->mtd.writesize);
> + goto err_dat_out;
> + }
> +
> + err =3D nand_scan_tail(&ndfc->mtd);
> + if (err)
> + goto err_dat_out;
> +
> + err =3D parse_partitions(ndfc, dev);
> + if (err < 0)
> + goto err_dat_out;
> +
> + if (err > 0)
> + add_mtd_partitions(&ndfc->mtd, OF_FLASH_PARTS(ndfc), err);
> + else
> + add_mtd_device(&ndfc->mtd);
> +
> + return 0;
> +
> +err_dat_out:
> + dev_set_drvdata(&dev->dev, NULL);
> +err_unmap_out:
> + iounmap(ndfc->base);
> +err_rel_out:
> + release_resource(ndfc->res);
> + kfree(ndfc->res);
> +err_free_out:
> + kfree(ndfc);
> +err_out:
> + return err;
> +}
> +
> +static struct of_device_id of_ndfc_match[] =3D {
> + {
> + .compatible =3D "ibm,ndfc",
> + },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, of_ndfc_match);
> +
> +static struct of_platform_driver of_ndfc_driver =3D {
> + .name =3D "of-ndfc",
> + .match_table =3D of_ndfc_match,
> + .probe =3D of_ndfc_probe,
> + .remove =3D of_ndfc_remove,
> +};
> +
> +static int __init of_ndfc_init(void)
> +{
> + return of_register_platform_driver(&of_ndfc_driver);
> +}
> +
> +static void __exit of_ndfc_exit(void)
> +{
> + of_unregister_platform_driver(&of_ndfc_driver);
> +}
> +
> +module_init(of_ndfc_init);
> +module_exit(of_ndfc_exit);
> +
> +MODULE_LICENSE("GPL");
> +
> +
> +MODULE_DESCRIPTION("OF driver for NDFC");
> diff -pruN linux-2.6.orig/include/linux/mtd/ndfc.h
> linux-2.6/include/linux/mtd/ndfc.h ---
> linux-2.6.orig/include/linux/mtd/ndfc.h 2007-10-25 19:20:42.000000000 +04=
00
> +++ linux-2.6/include/linux/mtd/ndfc.h 2007-10-26 16:19:42.000000000 +0400
> @@ -52,6 +52,10 @@
> #define NDFC_BxCFG_SZ_MASK 0x08000000 /* Bank Size */
> #define NDFC_BxCFG_SZ_8BIT 0x00000000 /* 8bit */
> #define NDFC_BxCFG_SZ_16BIT 0x08000000 /* 16bit */
> +#define NDFC_BxCFG_RR(x) (((x) & 0x7) << 0)
> +#define NDFC_BxCFG_RWH(x) (((x) & 0x7) << 4)
> +#define NDFC_BxCFG_RWP(x) (((x) & 0x7) << 8)
> +#define NDFC_BxCFG_CRW(x) (((x) & 0x7) << 12)
>
> #define NDFC_MAX_BANKS 4
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH 0/2] PowerPC: Add 44x NDFC device-tree aware support
From: Stefan Roese @ 2007-10-27 4:42 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, Thomas Gleixner, linux-mtd
In-Reply-To: <alpine.LFD.0.9999.0710262316590.3186@localhost.localdomain>
Hi Valentine,
On Friday 26 October 2007, Thomas Gleixner wrote:
> On Fri, 26 Oct 2007, Valentine Barshak wrote:
> > The major difference is that the original implements each chip connected
> > NDFC banks as a separate MTD device. Here I try to have one MTD device
> > spread on all chips found. However, the chips should have equal ID's and
> > sizes, but I've never seen several different chips attached to single
> > ndfc.
>
> Bamboo has 2 different nand chips.
Right. This was my first thought after seeing your mail too.
> And I'm aware of another board
> which has a 2k-page onboard NAND and sockets for SmartMedia /
> PictureXd cards, which will simply break with your design.
>
> Restricting stuff for no good reason is never a good idea.
Add my voice here too.
> mtdconcat can build you a big one if you want, so why adding
> restrictions to a driver ?
>
> > I'm adding ndfc_of as a separate file, since some other changes
> > have also been made (e.g. all i/o is made with ndfc_readl/writel inline
> > functions).
>
> This should be done in the original ndfc driver and not in a separate
> incarnation.
Right. And I always thought it would be a good idea to switch to using the
in_be32() functions and friends for IO access in this driver too.
Best regards,
Stefan
^ permalink raw reply
* Re: [PATCH] [Powerpc] fix switch_slb handling of 1T ESID values
From: Benjamin Herrenschmidt @ 2007-10-27 4:19 UTC (permalink / raw)
To: Will Schmidt; +Cc: linuxppc-dev, paulus
In-Reply-To: <20071026204641.25514.45178.stgit@farscape.rchland.ibm.com>
On Fri, 2007-10-26 at 15:46 -0500, Will Schmidt wrote:
> [Powerpc] fix switch_slb handling of 1T ESID values
>
> Now that we have 1TB segment size support, we need to be using the
> GET_ESID_1T macro when comparing ESID values for pc,stack, and
> unmapped_base within switch_slb() when we're on a CPU that supports it.
>
> This also happens to fix a duplicate-slb-entry inspired machine-check
> exception I was seeing when trying to run java on a power6 partition.
>
> Tested on power6 and power5.
>
> Signed-Off-By: Will Schmidt <will_schmidt@vnet.ibm.com>
Good catch !
A minor comment is maybe you could factor out the code better doing
something like a ESID_COMPARE() macro ?
> ---
>
> There is a similar bit of code in stab.c switch_stab(). Should this change also be made there?
> ---
There is no machine that does stab and 1T segments.
Ben.
>
> arch/powerpc/mm/slb.c | 19 ++++++++++++++-----
> 1 files changed, 14 insertions(+), 5 deletions(-)
>
>
> diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
> index bbd2c51..0c527d7 100644
> --- a/arch/powerpc/mm/slb.c
> +++ b/arch/powerpc/mm/slb.c
> @@ -193,16 +193,25 @@ void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
> return;
> slb_allocate(pc);
>
> - if (GET_ESID(pc) == GET_ESID(stack))
> - return;
> + if (cpu_has_feature(CPU_FTR_1T_SEGMENT)) {
> + if (GET_ESID_1T(pc) == GET_ESID_1T(stack))
> + return;
> + } else
> + if (GET_ESID(pc) == GET_ESID(stack))
> + return;
>
> if (is_kernel_addr(stack))
> return;
> slb_allocate(stack);
>
> - if ((GET_ESID(pc) == GET_ESID(unmapped_base))
> - || (GET_ESID(stack) == GET_ESID(unmapped_base)))
> - return;
> + if (cpu_has_feature(CPU_FTR_1T_SEGMENT)) {
> + if ((GET_ESID_1T(pc) == GET_ESID_1T(unmapped_base))
> + || (GET_ESID_1T(stack) == GET_ESID_1T(unmapped_base)))
> + return;
> + } else
> + if ((GET_ESID(pc) == GET_ESID(unmapped_base))
> + || (GET_ESID(stack) == GET_ESID(unmapped_base)))
> + return;
>
> if (is_kernel_addr(unmapped_base))
> return;
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 1/2] PowerPC: Add 44x NDFC device-tree aware support
From: Stephen Rothwell @ 2007-10-27 3:37 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, tglx, sr, linux-mtd
In-Reply-To: <20071026163958.GA11784@ru.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 2917 bytes --]
On Fri, 26 Oct 2007 20:39:58 +0400 Valentine Barshak <vbarshak@ru.mvista.com> wrote:
>
> +static int __devinit parse_partitions(struct of_ndfc *ndfc,
> + struct of_device *dev)
> +{
> + const char *partname;
> + static const char *part_probe_types[]
> + = { "cmdlinepart", "RedBoot", NULL };
> + struct device_node *dp = dev->node, *pp;
> + int nr_parts, i;
> +
> + /* First look for RedBoot table or partitions on the command
> + * line, these take precedence over device tree information */
> + nr_parts = parse_mtd_partitions(&ndfc->mtd, part_probe_types,
> + &ndfc->parts, 0);
> + if (nr_parts > 0) {
> + add_mtd_partitions(&ndfc->mtd, ndfc->parts, nr_parts);
> + return 0;
> + }
> +
> + /* First count the subnodes */
> + nr_parts = 0;
> + for (pp = dp->child; pp; pp = pp->sibling)
For proper ref counting and locking, use:
for (pp = of_get_next_child(dp, NULL); pp;
pp = of_get_next_child(dp, pp))
> + nr_parts++;
> +
> + if (nr_parts == 0)
> + return 0;
> +
> + ndfc->parts = kzalloc(nr_parts * sizeof(*ndfc->parts),
> + GFP_KERNEL);
> + if (!ndfc->parts)
> + return -ENOMEM;
> +
> + for (pp = dp->child, i = 0; pp; pp = pp->sibling, i++) {
for (pp = of_get_next_child(dp, NULL), i = 0; pp;
pp = of_get_next_child(dp, pp), i++)
> + const u32 *reg;
> + int len;
> +
> + reg = of_get_property(pp, "reg", &len);
> + if (!reg || (len != 2*sizeof(u32))) {
of_node_put(pp);
> + dev_err(&dev->dev, "Invalid 'reg' on %s\n",
> + dp->full_name);
> + kfree(ndfc->parts);
> + ndfc->parts = NULL;
> + return -EINVAL;
> + }
> + ndfc->parts[i].offset = reg[0];
> + ndfc->parts[i].size = reg[1];
> +
> + partname = of_get_property(pp, "label", &len);
> + if (!partname)
> + partname = of_get_property(pp, "name", &len);
> + ndfc->parts[i].name = (char *)partname;
> +
> + if (of_get_property(pp, "read-only", &len))
> + ndfc->parts[i].mask_flags = MTD_WRITEABLE;
> + }
> +
> + return nr_parts;
> +}
> +#else /* MTD_PARTITIONS */
> +#define OF_FLASH_PARTS(ndfc) (0)
> +#define parse_partitions(ndfc, dev) (0)
static inline int parse_partitions(struct of_ndfc *ndfc, struct of_device *dev)
{
return 0;
}
> +#endif /* MTD_PARTITIONS */
> +static int __devinit of_ndfc_probe(struct of_device *dev,
> + const struct of_device_id *match)
> +{
> + struct device_node *dp = dev->node;
> + struct resource res;
> + struct of_ndfc *ndfc;
> + const u32 *prop;
> + resource_size_t rlen;
> + int err;
> +
> + err = -ENXIO;
> + if (of_address_to_resource(dp, 0, &res)) {
> + dev_err(&dev->dev, "can't get IO address from device tree\n");
> + goto err_out;
> + }
> +
> + dev_dbg(&dev->dev, "regs: %.8llx-%.8llx\n",
indentation ?
--
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: Apparent kernel bug with GDB on ppc405
From: Josh Boyer @ 2007-10-27 1:27 UTC (permalink / raw)
To: benh; +Cc: gdb, Matt Mackall, linuxppc-embedded, Daniel Jacobowitz
In-Reply-To: <1193448983.18243.16.camel@pasglop>
On Sat, 2007-10-27 at 11:36 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2007-10-26 at 15:41 -0500, Josh Boyer wrote:
> > On Fri, 26 Oct 2007 11:51:22 +1000
> > Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > >
> > > On Wed, 2007-10-24 at 18:41 -0400, Daniel Jacobowitz wrote:
> > > > On Wed, Oct 24, 2007 at 05:32:50PM -0500, Matt Mackall wrote:
> > > > > Not completely implausible, but a) why isn't this seen on basically
> > > > > every machine with software TLB? b) why does -local- GDB, which is
> > > > > presumably doing much less work than gdbserver + network stack, not fail?
> > > >
> > > > You said it yourself. Local gdb does more work -> blows through more
> > > > TLB entries.
> > > >
> > > > I can't answer you about the other half, but I'm pretty sure TLB
> > > > invalidation is already supposed to be happening... somewhere.
> > >
> > > Yes. do_wp_page() -> ptep_clear_flush() -> flush_tlb_page()
> >
> > Aren't there cases in do_wp_page that don't call ptep_clear_flush?
> > Seems anonymous pages, and possibly shared writeable pages skip that
> > step if reuse is true.
>
> Nah, if that was broken, everybody would be in bad shape. I think I know
> what's up, see my other email.
Yeah, I figured that out after I sent this anyway. In those cases it
should likely get flushed from ptep_set_access_flags.
josh
^ permalink raw reply
* Re: Apparent kernel bug with GDB on ppc405
From: Benjamin Herrenschmidt @ 2007-10-27 1:36 UTC (permalink / raw)
To: Josh Boyer; +Cc: gdb, Matt Mackall, linuxppc-embedded, Daniel Jacobowitz
In-Reply-To: <20071026154126.28082129@weaponx.rchland.ibm.com>
On Fri, 2007-10-26 at 15:41 -0500, Josh Boyer wrote:
> On Fri, 26 Oct 2007 11:51:22 +1000
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> >
> > On Wed, 2007-10-24 at 18:41 -0400, Daniel Jacobowitz wrote:
> > > On Wed, Oct 24, 2007 at 05:32:50PM -0500, Matt Mackall wrote:
> > > > Not completely implausible, but a) why isn't this seen on basically
> > > > every machine with software TLB? b) why does -local- GDB, which is
> > > > presumably doing much less work than gdbserver + network stack, not fail?
> > >
> > > You said it yourself. Local gdb does more work -> blows through more
> > > TLB entries.
> > >
> > > I can't answer you about the other half, but I'm pretty sure TLB
> > > invalidation is already supposed to be happening... somewhere.
> >
> > Yes. do_wp_page() -> ptep_clear_flush() -> flush_tlb_page()
>
> Aren't there cases in do_wp_page that don't call ptep_clear_flush?
> Seems anonymous pages, and possibly shared writeable pages skip that
> step if reuse is true.
Nah, if that was broken, everybody would be in bad shape. I think I know
what's up, see my other email.
Cheers,
Ben.
^ permalink raw reply
* Re: Apparent kernel bug with GDB on ppc405
From: Benjamin Herrenschmidt @ 2007-10-27 1:30 UTC (permalink / raw)
To: Matt Mackall; +Cc: gdb, linuxppc-embedded
In-Reply-To: <20071026144134.GW19691@waste.org>
On Fri, 2007-10-26 at 09:41 -0500, Matt Mackall wrote:
> On Fri, Oct 26, 2007 at 01:23:25PM +1000, Benjamin Herrenschmidt
> wrote:
> >
> > > This is actually 405. Does that have the same issue?
> >
> > hrm... I don't remember :-) There -is- something fishy about the
> icache
> > on 405 but I don't remember for sure. Try sticking an iccci in there
> and
> > tell us if that helps.
>
> I did. I stuck an iccci -and- a dccci loop in. I threw in the tlbia
> when I ran out of other ideas. And the tlbia + existing
> flush_icache_range appears to be sufficient (tested on a non-trivial
> app).
>
> According to my docs, the 405fx's icache is virtually
> indexed/physically mapped, while the dcache is phys/phys.
I think there is a bug in the 40x/44x support at this stage, it only
doing invalidations for the current PID. That means that a process
trying to invalidate TLB entries of another address space will fail to
do so ... oops.
That can be fixed by adding a pid argument to to _tlbie, and using it in
the assembly. In the 40x case, probably by switching SPRN_PID to that
and then back, in the 44x case, by using that value instead of SPRN_PID
for the MMUCR register.
It's part of a patche I have around taking dirt that rework signficantly
the 44x (though not the 40x yet) TLB handling, cleaning things and
fixing bugs (such as this one, I remember it now). I need to spend a bit
of time to clean it up, remove some experimental stuff from it, and
submit it.
I'll try to do that early next week, and maybe come up with a fix for
that specific bug today or tomorrow.
Ben.
^ permalink raw reply
* Re: [PATCH 0/2] PowerPC: Add 44x NDFC device-tree aware support
From: Thomas Gleixner @ 2007-10-26 21:37 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, sr, linux-mtd
In-Reply-To: <20071026163058.GA11354@ru.mvista.com>
On Fri, 26 Oct 2007, Valentine Barshak wrote:
> The major difference is that the original implements each chip connected NDFC banks as a
> separate MTD device. Here I try to have one MTD device spread on all chips found.
> However, the chips should have equal ID's and sizes, but I've never seen several different
> chips attached to single ndfc.
Bamboo has 2 different nand chips. And I'm aware of another board
which has a 2k-page onboard NAND and sockets for SmartMedia /
PictureXd cards, which will simply break with your design.
Restricting stuff for no good reason is never a good idea.
mtdconcat can build you a big one if you want, so why adding
restrictions to a driver ?
> I'm adding ndfc_of as a separate file, since some other changes
> have also been made (e.g. all i/o is made with ndfc_readl/writel inline functions).
This should be done in the original ndfc driver and not in a separate
incarnation.
> The original version didn't handle driver removal well (it never calls del_mtd...),it's
> corrected here.
Why not fixing the original driver ?
> Any comments are greatly appreciated.
NACK.
Please fix the existing driver and convert it to deal with OF and fix
the other short comings as well.
Duplicate code is not going anywhere near drivers/mtd/nand
tglx
^ permalink raw reply
* Re: reg adjust_total_lowmem
From: Scott Wood @ 2007-10-26 21:27 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Surya Ravikiran
In-Reply-To: <Pine.LNX.4.64.0710261615380.23925@blarg.am.freescale.net>
Kumar Gala wrote:
> On Fri, 26 Oct 2007, Scott Wood wrote:
>
>> Scott Wood wrote:
>>> On Fri, Oct 26, 2007 at 10:04:19AM -0500, Kumar Gala wrote:
>>>> The reason you have 192M is that lowmem is the total amount of memory
>>>> that can be covered by up to three CAM entries. In the case of setting
>>>> mem=252M that max that three CAM entries can cover is 192M (64 +64+64).
>>>> You should be able to access the other 60M via HIGHMEM.
>>> Why doesn't it just use a 256M mapping, and not access the last 4M?
>
> This has some possibility, not sure what the threshold should be. Do we
> just always map 768M of lowmem regardless of how much memory we have?
That's probably the simplest way. We'll need to fix VMALLOC_START as well.
>> Not to mention, why highmem and not just normal TLB0 mappings for the extra
>> pages?
>
> Because we do not handle recursive misses in the TLB handlers. We expect
> any load/store that occurs in the TLB handlers to not have a TLB fault
> associated with (and thus all of lowmem must be pinned).
OK. I guess that means no page debugging... :-P
-Scott
^ permalink raw reply
* Re: reg adjust_total_lowmem
From: Kumar Gala @ 2007-10-26 21:17 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev list, Surya Ravikiran
In-Reply-To: <47225327.2070103@freescale.com>
On Fri, 26 Oct 2007, Scott Wood wrote:
> Scott Wood wrote:
> > On Fri, Oct 26, 2007 at 10:04:19AM -0500, Kumar Gala wrote:
> > > The reason you have 192M is that lowmem is the total amount of memory
> > > that can be covered by up to three CAM entries. In the case of setting
> > > mem=252M that max that three CAM entries can cover is 192M (64 +64+64).
> > > You should be able to access the other 60M via HIGHMEM.
> >
> > Why doesn't it just use a 256M mapping, and not access the last 4M?
This has some possibility, not sure what the threshold should be. Do we
just always map 768M of lowmem regardless of how much memory we have?
> Not to mention, why highmem and not just normal TLB0 mappings for the extra
> pages?
Because we do not handle recursive misses in the TLB handlers. We expect
any load/store that occurs in the TLB handlers to not have a TLB fault
associated with (and thus all of lowmem must be pinned).
- k
^ permalink raw reply
* Re: reg adjust_total_lowmem
From: Scott Wood @ 2007-10-26 20:50 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Surya Ravikiran
In-Reply-To: <20071026194005.GA4571@loki.buserror.net>
Scott Wood wrote:
> On Fri, Oct 26, 2007 at 10:04:19AM -0500, Kumar Gala wrote:
>> The reason you have 192M is that lowmem is the total amount of memory
>> that can be covered by up to three CAM entries. In the case of
>> setting mem=252M that max that three CAM entries can cover is 192M (64
>> +64+64). You should be able to access the other 60M via HIGHMEM.
>
> Why doesn't it just use a 256M mapping, and not access the last 4M?
Not to mention, why highmem and not just normal TLB0 mappings for the
extra pages?
-Scott
^ permalink raw reply
* [PATCH] [Powerpc] fix switch_slb handling of 1T ESID values
From: Will Schmidt @ 2007-10-26 20:46 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
[Powerpc] fix switch_slb handling of 1T ESID values
Now that we have 1TB segment size support, we need to be using the
GET_ESID_1T macro when comparing ESID values for pc,stack, and
unmapped_base within switch_slb() when we're on a CPU that supports it.
This also happens to fix a duplicate-slb-entry inspired machine-check
exception I was seeing when trying to run java on a power6 partition.
Tested on power6 and power5.
Signed-Off-By: Will Schmidt <will_schmidt@vnet.ibm.com>
---
There is a similar bit of code in stab.c switch_stab(). Should this change also be made there?
---
arch/powerpc/mm/slb.c | 19 ++++++++++++++-----
1 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
index bbd2c51..0c527d7 100644
--- a/arch/powerpc/mm/slb.c
+++ b/arch/powerpc/mm/slb.c
@@ -193,16 +193,25 @@ void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
return;
slb_allocate(pc);
- if (GET_ESID(pc) == GET_ESID(stack))
- return;
+ if (cpu_has_feature(CPU_FTR_1T_SEGMENT)) {
+ if (GET_ESID_1T(pc) == GET_ESID_1T(stack))
+ return;
+ } else
+ if (GET_ESID(pc) == GET_ESID(stack))
+ return;
if (is_kernel_addr(stack))
return;
slb_allocate(stack);
- if ((GET_ESID(pc) == GET_ESID(unmapped_base))
- || (GET_ESID(stack) == GET_ESID(unmapped_base)))
- return;
+ if (cpu_has_feature(CPU_FTR_1T_SEGMENT)) {
+ if ((GET_ESID_1T(pc) == GET_ESID_1T(unmapped_base))
+ || (GET_ESID_1T(stack) == GET_ESID_1T(unmapped_base)))
+ return;
+ } else
+ if ((GET_ESID(pc) == GET_ESID(unmapped_base))
+ || (GET_ESID(stack) == GET_ESID(unmapped_base)))
+ return;
if (is_kernel_addr(unmapped_base))
return;
^ permalink raw reply related
* Re: Apparent kernel bug with GDB on ppc405
From: Josh Boyer @ 2007-10-26 20:41 UTC (permalink / raw)
To: benh; +Cc: gdb, Matt Mackall, linuxppc-embedded, Daniel Jacobowitz
In-Reply-To: <1193363482.7018.41.camel@pasglop>
On Fri, 26 Oct 2007 11:51:22 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> On Wed, 2007-10-24 at 18:41 -0400, Daniel Jacobowitz wrote:
> > On Wed, Oct 24, 2007 at 05:32:50PM -0500, Matt Mackall wrote:
> > > Not completely implausible, but a) why isn't this seen on basically
> > > every machine with software TLB? b) why does -local- GDB, which is
> > > presumably doing much less work than gdbserver + network stack, not fail?
> >
> > You said it yourself. Local gdb does more work -> blows through more
> > TLB entries.
> >
> > I can't answer you about the other half, but I'm pretty sure TLB
> > invalidation is already supposed to be happening... somewhere.
>
> Yes. do_wp_page() -> ptep_clear_flush() -> flush_tlb_page()
Aren't there cases in do_wp_page that don't call ptep_clear_flush?
Seems anonymous pages, and possibly shared writeable pages skip that
step if reuse is true.
josh
^ permalink raw reply
* Re: [PATCH] fix appletouch geyser 1 breakage
From: Johannes Berg @ 2007-10-26 20:31 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linuxppc-dev list, Benjamin Berg, Anton Ekblad
In-Reply-To: <d120d5000710260905k4c6391b2j7c3d8528cc8198b0@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 107 bytes --]
> Johannes, and what is product ID for your touchpad?
It's 0x20e, listed as 'fountain'
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: problems to boot 2.6.23 kernel on XILINX ppc with 8Mbytes of RAM
From: Grant Likely @ 2007-10-26 19:54 UTC (permalink / raw)
To: Magnus Hjorth; +Cc: Linuxppc-embedded
In-Reply-To: <47203EF9.1070906@omnisys.se>
On 10/25/07, Magnus Hjorth <mh@omnisys.se> wrote:
> Hello Manu,
>
> Could you try the attached patch to arch/ppc/mm/4xx_mmu.c and see if it
> solves your problem?
Good catch, thanks!
Send you're signed off by line, and I'll for Josh to pick it up.
Reviewed-by: Grant Likely <grant.likely@secretlab.ca>
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: reg adjust_total_lowmem
From: Scott Wood @ 2007-10-26 19:40 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Surya Ravikiran
In-Reply-To: <524E69ED-899B-452F-B593-44499C5181A3@kernel.crashing.org>
On Fri, Oct 26, 2007 at 10:04:19AM -0500, Kumar Gala wrote:
>
> On Oct 25, 2007, at 10:51 PM, Surya Ravikiran wrote:
>
> > Hi,
> >
> > I am trying to bootup a Linux kernel, on a FS eval board with 256M.
> > I pass the kernel argument mem=252M, and see that the kernel boots up
> > fine, but with much less memory, ~192M (the closes 64M multiple), and
> > I browsed through the code to see that the adjust_total_lowmem
> > function does not add up the residual memory to the total memory.
> > I am trying to understand why I cannot do this reserving of higher end
> > of the RAM during boot up,
> > I would appreciate your comments.
>
> The reason you have 192M is that lowmem is the total amount of memory
> that can be covered by up to three CAM entries. In the case of
> setting mem=252M that max that three CAM entries can cover is 192M (64
> +64+64). You should be able to access the other 60M via HIGHMEM.
Why doesn't it just use a 256M mapping, and not access the last 4M?
-Scott
^ permalink raw reply
* RE: Porting to /arch/powerpc
From: Joakim Tjernlund @ 2007-10-26 19:03 UTC (permalink / raw)
To: 'Scott Wood', Li Yang; +Cc: linuxppc-embedded
In-Reply-To: <47222D86.1000502@freescale.com>
> -----Original Message-----
> From: Scott Wood [mailto:scottwood@freescale.com]
> Sent: den 26 oktober 2007 20:10
> To: Joakim Tjernlund
> Cc: 'Rune Torgersen'; linuxppc-embedded@ozlabs.org
> Subject: Re: Porting to /arch/powerpc
>
> Joakim Tjernlund wrote:
> >> The fs_enet driver doesn't currently support phy-less
> >> directly, but you
> >> may be able to do something with the fixed phy driver.
> >
> > How is PHY less support supposed to be impl.? I would like
> > to do the same for ucc_geth. I once sent a patch that made
> > the PHY optional, but it never made into the driver.
>
> Basically, the driver needs to assume the link is up if there's no
> phy-handle in the device tree, rather than error out.
>
> -Scott
Right, that was what I did, but I think Leo didn't want it at the time.
Leo?
Jocke
^ permalink raw reply
* Re: [PATCH 0/2] PowerPC: Add 44x NDFC device-tree aware support
From: Josh Boyer @ 2007-10-26 18:50 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev, tglx, sr, linux-mtd
In-Reply-To: <20071026163058.GA11354@ru.mvista.com>
On Fri, 26 Oct 2007 20:30:58 +0400
Valentine Barshak <vbarshak@ru.mvista.com> wrote:
> I've worked in parallel with Stefan Roese on the new OF NDFC support.
> This version (as well as Stefan's) is based on the original NDFC driver by Thomas Gleixner.
> The major difference is that the original implements each chip connected NDFC banks as a
> separate MTD device. Here I try to have one MTD device spread on all chips found.
> However, the chips should have equal ID's and sizes, but I've never seen several different
> chips attached to single ndfc.
Hm. Why did you do that? It adds restrictions to the driver that
really don't need to be present. If people want a single MTD device
across multiple chips, they can use mtdconcat.
Remember, just because you've never seen something, doesn't mean it
doesn't exist. Bamboo even has two different sized NAND chips
hooked to the NDFC, IIRC.
josh
^ permalink raw reply
* Re: problems to boot 2.6.23 kernel on XILINX ppc with 8Mbytes of RAM
From: manu @ 2007-10-26 18:43 UTC (permalink / raw)
To: Linuxppc-embedded
In-Reply-To: <47203EF9.1070906@omnisys.se>
Hello Magnus,
your patch solved the problem.
Thank you.
Manu
Magnus Hjorth a écrit :
> Hello Manu,
>
> Could you try the attached patch to arch/ppc/mm/4xx_mmu.c and see if
> it solves your problem?
>
> Best regards,
> Magnus
>
>
> manu wrote:
>> Hello,
>> I work on a custom board based on a virtex 2 pro FPGA and 8Mbytes of
>> SDRAM.
>> Untill now I used a 2.4.31 linux ppc kernel with John Williams patches
>> and uclinux distribution and everything worked perfectly.
>> I've decided to move to the latest 2.6 version from kernel.org
>> (2.6.23.1) with an initramfs containing a busybox.
>> My complete zImage including the initramfs has a size of 900Kbytes.
>> I made some tests with a ML300 board and I managed to get a shell
>> easily.
>> When I migrated to the custom board, I had the "Now booting the kernel"
>> message and then nothing.
>> When I trace the code running on the ppc with the debugger, execution
>> seems to be stuck in some early initialization code.
>> I managed to reproduce the problem on the ML300 using "mem=8m" parameter
>> on the bootline.
>> With "mem=16m" the kernel boots correctly.
>> I'm really surprised by the amount of RAM required to boot the kernel.
>> Is there a way to make it boot with only 8Mbytes of RAM ?
>> Thanks for your help.
>>
>> Manu
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>
>
> ------------------------------------------------------------------------
>
> --- 4xx_mmu_old.c 2007-10-25 08:54:46.000000000 +0200
> +++ 4xx_mmu.c 2007-10-25 08:55:57.000000000 +0200
> @@ -105,7 +105,7 @@
> return s;
> }
>
> - while (s <= (total_lowmem - LARGE_PAGE_SIZE_16M)) {
> + while (s + LARGE_PAGE_SIZE_16M <= total_lowmem) {
> pmd_t *pmdp;
> unsigned long val = p | _PMD_SIZE_16M | _PAGE_HWEXEC | _PAGE_HWWRITE;
>
> @@ -120,7 +120,7 @@
> s += LARGE_PAGE_SIZE_16M;
> }
>
> - while (s <= (total_lowmem - LARGE_PAGE_SIZE_4M)) {
> + while (s + LARGE_PAGE_SIZE_4M <= total_lowmem) {
> pmd_t *pmdp;
> unsigned long val = p | _PMD_SIZE_4M | _PAGE_HWEXEC | _PAGE_HWWRITE;
>
>
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix CONFIG_SMP=n build break
From: Arnd Bergmann @ 2007-10-26 18:19 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Olof Johansson, paulus, linux-kernel
In-Reply-To: <20071026165510.GA2323@lixom.net>
On Friday 26 October 2007, Olof Johansson wrote:
> Fix two build errors on powerpc allyesconfig + CONFIG_SMP=3Dn:
>
> arch/powerpc/platforms/built-in.o: In function `cpu_affinity_set':
> arch/powerpc/platforms/cell/spu_priv1_mmio.c:78: undefined reference to
> `.iic_get_target_id' arch/powerpc/platforms/built-in.o: In function
> `iic_init_IRQ':
> arch/powerpc/platforms/cell/interrupt.c:397: undefined reference to
> `.iic_setup_cpu'
Thanks for reporting this.
> --- a/arch/powerpc/platforms/cell/spu_priv1_mmio.c
> +++ b/arch/powerpc/platforms/cell/spu_priv1_mmio.c
> @@ -75,9 +75,11 @@ static u64 int_stat_get(struct spu *spu, int class)
> =A0
> =A0static void cpu_affinity_set(struct spu *spu, int cpu)
> =A0{
> +#ifdef CONFIG_SMP
> =A0=A0=A0=A0=A0=A0=A0=A0u64 target =3D iic_get_target_id(cpu);
> =A0=A0=A0=A0=A0=A0=A0=A0u64 route =3D target << 48 | target << 32 | targe=
t << 16;
> =A0=A0=A0=A0=A0=A0=A0=A0out_be64(&spu->priv1->int_route_RW, route);
> +#endif
> =A0}
I think here it would be better to move iic_get_target_id out of
CONFIG_SMP as well. We might want to kexec from an SMP kernel into
a UP kernel, and in that case, cpu_affinity_set() should better
reset the routing to CPU 0.
Arnd <><
^ 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