* Re: wmb vs mmiowb
From: Nick Piggin @ 2007-08-23 3:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-ia64, Jesse Barnes, linuxppc-dev
In-Reply-To: <alpine.LFD.0.999.0708221953360.30176@woody.linux-foundation.org>
On Wed, Aug 22, 2007 at 07:57:56PM -0700, Linus Torvalds wrote:
>
>
> On Thu, 23 Aug 2007, Nick Piggin wrote:
> >
> > > Irix actually had an io_unlock() routine that did this
> > > implicitly, but iirc that was shot down for Linux...
> >
> > Why was it shot down? Seems like a pretty good idea to me ;)
>
> It's horrible. We'd need it for *every* single spinlock type. We have lots
> of them.
>
> So the choice is between:
>
> - sane:
>
> mmiowb()
>
> followed by any of the existing "spin_unlock()" variants (plain,
> _irq(), _bh(), _irqrestore())
>
> - insane: multiply our current set of unlock primitives by two, by making
> "io" versions for them all:
>
> spin_unlock_io[_irq|_irqrestore|_bh]()
>
> but there's actually an EVEN WORSE problem with the stupid Irix approach,
> namely that it requires that the unlocker be aware of the exact details of
> what happens inside the lock. If the locking is done at an outer layer,
> that's not at all obvious!
OK, but we'd have some kind of functions that are called not to
serialise the CPUs, but to serialise the IO. It would be up to
the calling code to already provide CPU synchronisation.
serialize_io(); / unserialize_io(); / a nicer name
If we could pass in some kind of relevant resoure (eg. the IO
memory or device or something), then we might even be able to
put debug checks there to ensure two CPUs are never inside the
same critical IO section at once.
> In other words, Irix (once again) made a horrible and idiotic choice.
We could make a better one. I don't think mmiowb is really insane, but
I'd worry it being confused with a regular type of barrier and that CPU
synchronisation needs to be provided for it to work or make sense.
> Big surprise. Irix was probably the flakiest and worst of all the
> commercial proprietary unixes. No taste.
Is it? I've never used it ;)
^ permalink raw reply
* Please pull from 'mtd-2.6.24' branch
From: Kumar Gala @ 2007-08-23 4:00 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, linux-mtd, Paul Mackerras
Please pull from 'mtd-2.6.24' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git mtd-2.6.24
to receive the following updates:
drivers/mtd/maps/Kconfig | 12 -
drivers/mtd/maps/Makefile | 1
drivers/mtd/maps/pq2fads.c | 88 -------------
drivers/mtd/maps/tqm834x.c | 286 ---------------------------------------------
drivers/mtd/nand/Kconfig | 2
5 files changed, 3 insertions(+), 386 deletions(-)
Josh Boyer (1):
[MTD] 4xx: Don't build arch/ppc dependent drivers in arch/powerpc
Kumar Gala (1):
[MTD] Remove dead maps
commit 34a27ffdf59f80fe165f5c56a0be57d55b6da63d
Author: Kumar Gala <galak@kernel.crashing.org>
Date: Wed Aug 22 22:53:39 2007 -0500
[MTD] Remove dead maps
The tqm834x map Kconfig options depends on TQM834x which does not
exist anywhere else in the kernel.
The pq2fads map Kconfig/makefile support was removed a while ago but
the actual file persisted.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
commit 3feb0ff1607ab3b7dcd36b2347f00c41774464c8
Author: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Date: Wed Aug 22 14:30:47 2007 -0500
[MTD] 4xx: Don't build arch/ppc dependent drivers in arch/powerpc
These drivers are specific to 4xx support in arch/ppc at the moment. Make
sure they don't get built on arch/powerpc.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
diff --git a/drivers/mtd/maps/Kconfig b/drivers/mtd/maps/Kconfig
index cc6c734..5850ccd 100644
--- a/drivers/mtd/maps/Kconfig
+++ b/drivers/mtd/maps/Kconfig
@@ -354,7 +354,7 @@ config MTD_CFI_FLAGADM
config MTD_WALNUT
tristate "Flash device mapped on IBM 405GP Walnut"
- depends on MTD_JEDECPROBE && WALNUT
+ depends on MTD_JEDECPROBE && WALNUT && !PPC_MERGE
help
This enables access routines for the flash chips on the IBM 405GP
Walnut board. If you have one of these boards and would like to
@@ -370,7 +370,7 @@ config MTD_EBONY
config MTD_OCOTEA
tristate "Flash devices mapped on IBM 440GX Ocotea"
- depends on MTD_CFI && OCOTEA
+ depends on MTD_CFI && OCOTEA && !PPC_MERGE
help
This enables access routines for the flash chips on the IBM 440GX
Ocotea board. If you have one of these boards and would like to
@@ -384,14 +384,6 @@ config MTD_REDWOOD
Redwood board. If you have one of these boards and would like to
use the flash chips on it, say 'Y'.
-config MTD_TQM834x
- tristate "Flash device mapped on TQ Components TQM834x Boards"
- depends on MTD_CFI && TQM834x
- help
- This enables access routines for the flash chips on the
- TQ Components TQM834x boards. If you have one of these boards
- and would like to use the flash chips on it, say 'Y'.
-
config MTD_OCELOT
tristate "Momenco Ocelot boot flash device"
depends on MOMENCO_OCELOT
diff --git a/drivers/mtd/maps/Makefile b/drivers/mtd/maps/Makefile
index 970b189..b9019b1 100644
--- a/drivers/mtd/maps/Makefile
+++ b/drivers/mtd/maps/Makefile
@@ -70,4 +70,3 @@ obj-$(CONFIG_MTD_SHARP_SL) += sharpsl-flash.o
obj-$(CONFIG_MTD_PLATRAM) += plat-ram.o
obj-$(CONFIG_MTD_OMAP_NOR) += omap_nor.o
obj-$(CONFIG_MTD_MTX1) += mtx-1_flash.o
-obj-$(CONFIG_MTD_TQM834x) += tqm834x.o
diff --git a/drivers/mtd/maps/pq2fads.c b/drivers/mtd/maps/pq2fads.c
deleted file mode 100644
index fb78d87..0000000
--- a/drivers/mtd/maps/pq2fads.c
+++ /dev/null
@@ -1,88 +0,0 @@
-/*
- * drivers/mtd/maps/pq2fads.c
- *
- * Mapping for the flash SIMM on 8272ADS and PQ2FADS board
- *
- * Author: Vitaly Bordug <vbordug@ru.mvista.com>
- *
- * 2005 (c) MontaVista Software, Inc. This file is licensed under
- * the terms of the GNU General Public License version 2. This program
- * is licensed "as is" without any warranty of any kind, whether express
- * or implied.
- */
-
-#include <linux/module.h>
-#include <linux/types.h>
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <asm/io.h>
-#include <asm/ppcboot.h>
-#include <linux/mtd/mtd.h>
-#include <linux/mtd/map.h>
-#include <linux/mtd/partitions.h>
-#include <linux/mtd/physmap.h>
-
-/*
- NOTE: bank width and interleave relative to the installed flash
- should have been chosen within MTD_CFI_GEOMETRY options.
- */
-#define PQ2FADS_BANK_WIDTH 4
-
-static struct mtd_partition pq2fads_partitions[] = {
- {
-#ifdef CONFIG_ADS8272
- .name = "HRCW",
- .size = 0x40000,
- .offset = 0,
- .mask_flags = MTD_WRITEABLE, /* force read-only */
- }, {
- .name = "User FS",
- .size = 0x5c0000,
- .offset = 0x40000,
-#else
- .name = "User FS",
- .size = 0x600000,
- .offset = 0,
-#endif
- }, {
- .name = "uImage",
- .size = 0x100000,
- .offset = 0x600000,
- .mask_flags = MTD_WRITEABLE, /* force read-only */
- }, {
- .name = "bootloader",
- .size = 0x40000,
- .offset = 0x700000,
- .mask_flags = MTD_WRITEABLE, /* force read-only */
- }, {
- .name = "bootloader env",
- .size = 0x40000,
- .offset = 0x740000,
- .mask_flags = MTD_WRITEABLE, /* force read-only */
- }
-};
-
-
-/* pointer to MPC885ADS board info data */
-extern unsigned char __res[];
-
-static int __init init_pq2fads_mtd(void)
-{
- bd_t *bd = (bd_t *)__res;
- physmap_configure(bd->bi_flashstart, bd->bi_flashsize, PQ2FADS_BANK_WIDTH, NULL);
-
- physmap_set_partitions(pq2fads_partitions,
- sizeof (pq2fads_partitions) /
- sizeof (pq2fads_partitions[0]));
- return 0;
-}
-
-static void __exit cleanup_pq2fads_mtd(void)
-{
-}
-
-module_init(init_pq2fads_mtd);
-module_exit(cleanup_pq2fads_mtd);
-
-MODULE_LICENSE("GPL");
-MODULE_DESCRIPTION("MTD map and partitions for MPC8272ADS boards");
diff --git a/drivers/mtd/maps/tqm834x.c b/drivers/mtd/maps/tqm834x.c
deleted file mode 100644
index 9adc970..0000000
--- a/drivers/mtd/maps/tqm834x.c
+++ /dev/null
@@ -1,286 +0,0 @@
-/*
- * drivers/mtd/maps/tqm834x.c
- *
- * MTD mapping driver for TQM834x boards
- *
- * Copyright 2005 Wolfgang Denk, DENX Software Engineering, <wd@denx.de>.
- *
- * This file is licensed under the terms of the GNU General Public License
- * version 2. This program is licensed "as is" without any warranty of any
- * kind, whether express or implied.
- *
- */
-
-#include <linux/init.h>
-#include <linux/module.h>
-#include <linux/types.h>
-#include <linux/kernel.h>
-#include <linux/slab.h>
-#include <asm/io.h>
-#include <asm/ppcboot.h>
-
-#include <linux/mtd/mtd.h>
-#include <linux/mtd/map.h>
-#include <linux/mtd/partitions.h>
-
-#define FLASH_BANK_MAX 2
-
-extern unsigned char __res[];
-
-/* trivial struct to describe partition information */
-struct mtd_part_def
-{
- int nums;
- unsigned char *type;
- struct mtd_partition* mtd_part;
-};
-
-static struct mtd_info* mtd_banks[FLASH_BANK_MAX];
-static struct map_info* map_banks[FLASH_BANK_MAX];
-static struct mtd_part_def part_banks[FLASH_BANK_MAX];
-
-static unsigned long num_banks;
-static unsigned long start_scan_addr;
-
-#ifdef CONFIG_MTD_PARTITIONS
-/*
- * The following defines the partition layout of TQM834x boards.
- *
- * See include/linux/mtd/partitions.h for definition of the
- * mtd_partition structure.
- *
- * Assume minimal initial size of 4 MiB per bank, will be updated
- * later in init_tqm834x_mtd() routine.
- */
-
-/* Partition definition for the first flash bank which is always present. */
-static struct mtd_partition tqm834x_partitions_bank1[] = {
- {
- .name = "u-boot", /* u-boot firmware */
- .offset = 0x00000000,
- .size = 0x00040000, /* 256 KiB */
- /*mask_flags: MTD_WRITEABLE, * force read-only */
- },
- {
- .name = "env", /* u-boot environment */
- .offset = 0x00040000,
- .size = 0x00020000, /* 128 KiB */
- /*mask_flags: MTD_WRITEABLE, * force read-only */
- },
- {
- .name = "kernel", /* linux kernel image */
- .offset = 0x00060000,
- .size = 0x00100000, /* 1 MiB */
- /*mask_flags: MTD_WRITEABLE, * force read-only */
- },
- {
- .name = "initrd", /* ramdisk image */
- .offset = 0x00160000,
- .size = 0x00200000, /* 2 MiB */
- },
- {
- .name = "user", /* user data */
- .offset = 0x00360000,
- .size = 0x000a0000, /* remaining space */
- /* NOTE: this parttion size is re-calcated in */
- /* init_tqm834x_mtd() to cover actual remaining space. */
- },
-};
-
-/* Partition definition for the second flash bank which may be present on some
- * TQM834x boards.
- */
-static struct mtd_partition tqm834x_partitions_bank2[] = {
- {
- .name = "jffs2", /* jffs2 filesystem */
- .offset = 0x00000000,
- .size = 0x00400000, /* whole device */
- /* NOTE: this parttion size is re-calcated in */
- /* init_tqm834x_mtd() to cover actual device size. */
- },
-};
-
-#endif /* CONFIG_MTD_PARTITIONS */
-
-static int __init init_tqm834x_mtd(void)
-{
- int idx = 0, ret = 0;
- unsigned long flash_addr, flash_size, mtd_size = 0;
-
- /* pointer to TQM834x board info data */
- bd_t *bd = (bd_t *)__res;
-#ifdef CONFIG_MTD_CMDLINE_PARTS
- int n;
- char mtdid[4];
- const char *part_probes[] = { "cmdlinepart", NULL };
-#endif
-
- flash_addr = bd->bi_flashstart;
- flash_size = bd->bi_flashsize;
-
- /* request maximum flash size address space */
- start_scan_addr = (unsigned long)ioremap(flash_addr, flash_size);
- if (!start_scan_addr) {
- printk("%s: Failed to ioremap address: 0x%lx\n",
- __FUNCTION__, flash_addr);
- return -EIO;
- }
-
- for(idx = 0 ; idx < FLASH_BANK_MAX ; idx++) {
- if (mtd_size >= flash_size)
- break;
-
- pr_debug("%s: chip probing count %d\n", __FUNCTION__, idx);
-
- map_banks[idx] = kzalloc(sizeof(struct map_info), GFP_KERNEL);
- if (map_banks[idx] == NULL) {
- ret = -ENOMEM;
- goto error_mem;
- }
- map_banks[idx]->name = kzalloc(16, GFP_KERNEL);
- if (map_banks[idx]->name == NULL) {
- ret = -ENOMEM;
- goto error_mem;
- }
-
- sprintf(map_banks[idx]->name, "TQM834x-%d", idx);
- map_banks[idx]->size = flash_size;
- map_banks[idx]->bankwidth = 4;
-
- simple_map_init(map_banks[idx]);
-
- map_banks[idx]->virt = (void __iomem *)
- (start_scan_addr + ((idx > 0) ?
- (mtd_banks[idx-1] ? mtd_banks[idx-1]->size : 0) : 0));
- map_banks[idx]->phys =
- flash_addr + ((idx > 0) ?
- (mtd_banks[idx-1] ? mtd_banks[idx-1]->size : 0) : 0);
-
- /* start to probe flash chips */
- mtd_banks[idx] = do_map_probe("cfi_probe", map_banks[idx]);
- if (mtd_banks[idx]) {
- mtd_banks[idx]->owner = THIS_MODULE;
- mtd_size += mtd_banks[idx]->size;
- num_banks++;
- pr_debug("%s: bank %ld, name: %s, size: %d bytes \n",
- __FUNCTION__, num_banks,
- mtd_banks[idx]->name, mtd_banks[idx]->size);
- }
- }
-
- /* no supported flash chips found */
- if (!num_banks) {
- printk("TQM834x: No supported flash chips found!\n");
- ret = -ENXIO;
- goto error_mem;
- }
-
-#ifdef CONFIG_MTD_PARTITIONS
- /*
- * Select static partition definitions
- */
- n = ARRAY_SIZE(tqm834x_partitions_bank1);
- part_banks[0].mtd_part = tqm834x_partitions_bank1;
- part_banks[0].type = "static image bank1";
- part_banks[0].nums = n;
-
- /* update last partition size to cover actual remaining space */
- tqm834x_partitions_bank1[n - 1].size =
- mtd_banks[0]->size -
- tqm834x_partitions_bank1[n - 1].offset;
-
- /* check if we have second bank? */
- if (num_banks == 2) {
- n = ARRAY_SIZE(tqm834x_partitions_bank2);
- part_banks[1].mtd_part = tqm834x_partitions_bank2;
- part_banks[1].type = "static image bank2";
- part_banks[1].nums = n;
-
- /* update last partition size to cover actual remaining space */
- tqm834x_partitions_bank2[n - 1].size =
- mtd_banks[1]->size -
- tqm834x_partitions_bank2[n - 1].offset;
- }
-
- for(idx = 0; idx < num_banks ; idx++) {
-#ifdef CONFIG_MTD_CMDLINE_PARTS
- sprintf(mtdid, "%d", idx);
- n = parse_mtd_partitions(mtd_banks[idx],
- part_probes,
- &part_banks[idx].mtd_part,
- 0);
- pr_debug("%s: %d command line partitions on bank %s\n",
- __FUNCTION__, n, mtdid);
- if (n > 0) {
- part_banks[idx].type = "command line";
- part_banks[idx].nums = n;
- }
-#endif /* CONFIG_MTD_CMDLINE_PARTS */
- if (part_banks[idx].nums == 0) {
- printk(KERN_NOTICE
- "TQM834x flash bank %d: no partition info "
- "available, registering whole device\n", idx);
- add_mtd_device(mtd_banks[idx]);
- } else {
- printk(KERN_NOTICE
- "TQM834x flash bank %d: Using %s partition "
- "definition\n", idx, part_banks[idx].type);
- add_mtd_partitions(mtd_banks[idx],
- part_banks[idx].mtd_part,
- part_banks[idx].nums);
- }
- }
-#else /* ! CONFIG_MTD_PARTITIONS */
- printk(KERN_NOTICE "TQM834x flash: registering %d flash banks "
- "at once\n", num_banks);
-
- for(idx = 0 ; idx < num_banks ; idx++)
- add_mtd_device(mtd_banks[idx]);
-
-#endif /* CONFIG_MTD_PARTITIONS */
-
- return 0;
-error_mem:
- for (idx = 0 ; idx < FLASH_BANK_MAX ; idx++) {
- if (map_banks[idx] != NULL) {
- if (map_banks[idx]->name != NULL) {
- kfree(map_banks[idx]->name);
- map_banks[idx]->name = NULL;
- }
- kfree(map_banks[idx]);
- map_banks[idx] = NULL;
- }
- }
-
- iounmap((void *)start_scan_addr);
-
- return ret;
-}
-
-static void __exit cleanup_tqm834x_mtd(void)
-{
- unsigned int idx = 0;
- for(idx = 0 ; idx < num_banks ; idx++) {
- /* destroy mtd_info previously allocated */
- if (mtd_banks[idx]) {
- del_mtd_partitions(mtd_banks[idx]);
- map_destroy(mtd_banks[idx]);
- }
-
- /* release map_info not used anymore */
- kfree(map_banks[idx]->name);
- kfree(map_banks[idx]);
- }
-
- if (start_scan_addr) {
- iounmap((void *)start_scan_addr);
- start_scan_addr = 0;
- }
-}
-
-module_init(init_tqm834x_mtd);
-module_exit(cleanup_tqm834x_mtd);
-
-MODULE_LICENSE("GPL");
-MODULE_AUTHOR("Wolfgang Denk <wd@denx.de>");
-MODULE_DESCRIPTION("MTD map driver for TQM834x boards");
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index f1d60b6..a783d62 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -134,7 +134,7 @@ config MTD_NAND_S3C2410_HWECC
config MTD_NAND_NDFC
tristate "NDFC NanD Flash Controller"
- depends on 44x
+ depends on 44x && !PPC_MERGE
select MTD_NAND_ECC_SMC
help
NDFC Nand Flash Controllers are integrated in EP44x SoCs
^ permalink raw reply related
* [PATCH 1/2] [POWERPC] Remove cmd_line from head*.S
From: Stephen Rothwell @ 2007-08-23 4:05 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
In-Reply-To: <20070823130913.2e9db6eb.sfr@canb.auug.org.au>
It is just a C char array, so declare it thusly.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/head_32.S | 8 --------
arch/powerpc/kernel/head_40x.S | 7 -------
arch/powerpc/kernel/head_44x.S | 8 --------
arch/powerpc/kernel/head_64.S | 8 --------
arch/powerpc/kernel/head_8xx.S | 8 --------
arch/powerpc/kernel/head_fsl_booke.S | 8 --------
arch/powerpc/kernel/prom.c | 2 ++
7 files changed, 2 insertions(+), 47 deletions(-)
This is just rebased on Paulus' current tree as someone renamed head_4xx.S.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
index 7d73a13..de2fa61 100644
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -1300,14 +1300,6 @@ empty_zero_page:
swapper_pg_dir:
.space 4096
-/*
- * This space gets a copy of optional info passed to us by the bootstrap
- * Used to pass parameters into the kernel like root=/dev/sda1, etc.
- */
- .globl cmd_line
-cmd_line:
- .space 512
-
.globl intercept_table
intercept_table:
.long 0, 0, i0x200, i0x300, i0x400, 0, i0x600, i0x700
diff --git a/arch/powerpc/kernel/head_40x.S b/arch/powerpc/kernel/head_40x.S
index a8e0457..8a69eec 100644
--- a/arch/powerpc/kernel/head_40x.S
+++ b/arch/powerpc/kernel/head_40x.S
@@ -1006,13 +1006,6 @@ critical_stack_top:
.globl exception_stack_top
exception_stack_top:
-/* This space gets a copy of optional info passed to us by the bootstrap
- * which is used to pass parameters into the kernel like root=/dev/sda1, etc.
- */
- .globl cmd_line
-cmd_line:
- .space 512
-
/* Room for two PTE pointers, usually the kernel and current user pointers
* to their respective root page table.
*/
diff --git a/arch/powerpc/kernel/head_44x.S b/arch/powerpc/kernel/head_44x.S
index 8869596..e4068ff 100644
--- a/arch/powerpc/kernel/head_44x.S
+++ b/arch/powerpc/kernel/head_44x.S
@@ -744,14 +744,6 @@ exception_stack_bottom:
exception_stack_top:
/*
- * This space gets a copy of optional info passed to us by the bootstrap
- * which is used to pass parameters into the kernel like root=/dev/sda1, etc.
- */
- .globl cmd_line
-cmd_line:
- .space 512
-
-/*
* Room for two PTE pointers, usually the kernel and current user pointers
* to their respective root page table.
*/
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index 33c4e8c..381d07a 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -1538,11 +1538,3 @@ empty_zero_page:
.globl swapper_pg_dir
swapper_pg_dir:
.space PAGE_SIZE
-
-/*
- * This space gets a copy of optional info passed to us by the bootstrap
- * Used to pass parameters into the kernel like root=/dev/sda1, etc.
- */
- .globl cmd_line
-cmd_line:
- .space COMMAND_LINE_SIZE
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 901be47..22e1a3c 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -835,14 +835,6 @@ empty_zero_page:
swapper_pg_dir:
.space 4096
-/*
- * This space gets a copy of optional info passed to us by the bootstrap
- * Used to pass parameters into the kernel like root=/dev/sda1, etc.
- */
- .globl cmd_line
-cmd_line:
- .space 512
-
/* Room for two PTE table poiners, usually the kernel and current user
* pointer to their respective root page table (pgdir).
*/
diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
index 1f155d3..5f47adb 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -1050,14 +1050,6 @@ exception_stack_bottom:
exception_stack_top:
/*
- * This space gets a copy of optional info passed to us by the bootstrap
- * which is used to pass parameters into the kernel like root=/dev/sda1, etc.
- */
- .globl cmd_line
-cmd_line:
- .space 512
-
-/*
* Room for two PTE pointers, usually the kernel and current user pointers
* to their respective root page table.
*/
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 0028fe6..dc85005 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -60,6 +60,8 @@
#endif
+char cmd_line[COMMAND_LINE_SIZE];
+
static int __initdata dt_root_addr_cells;
static int __initdata dt_root_size_cells;
--
1.5.2.4
^ permalink raw reply related
* [PATCH] mpc8xx: Only build mpc8xx on arch/ppc
From: Kumar Gala @ 2007-08-23 4:07 UTC (permalink / raw)
To: bzolnier; +Cc: linuxppc-dev, Paul Mackerras, linux-ide
Currently the mpc8xx ide driver will only work on arch/ppc so only
allow it to be built there. Also, killed a minor include that isn't
actually used by the driver.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
drivers/ide/Kconfig | 2 +-
drivers/ide/ppc/mpc8xx.c | 1 -
2 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/ide/Kconfig b/drivers/ide/Kconfig
index 7adb61b..24ad104 100644
--- a/drivers/ide/Kconfig
+++ b/drivers/ide/Kconfig
@@ -946,7 +946,7 @@ config BLK_DEV_Q40IDE
config BLK_DEV_MPC8xx_IDE
bool "MPC8xx IDE support"
- depends on 8xx && IDE=y && BLK_DEV_IDE=y
+ depends on 8xx && IDE=y && BLK_DEV_IDE=y && !PPC_MERGE
select IDE_GENERIC
help
This option provides support for IDE on Motorola MPC8xx Systems.
diff --git a/drivers/ide/ppc/mpc8xx.c b/drivers/ide/ppc/mpc8xx.c
index 8859fe2..dab79af 100644
--- a/drivers/ide/ppc/mpc8xx.c
+++ b/drivers/ide/ppc/mpc8xx.c
@@ -32,7 +32,6 @@
#include <asm/mpc8xx.h>
#include <asm/mmu.h>
#include <asm/processor.h>
-#include <asm/residual.h>
#include <asm/io.h>
#include <asm/pgtable.h>
#include <asm/ide.h>
--
1.5.2.4
^ permalink raw reply related
* Re: asm-ppc header issues when building ARCH=powerpc
From: Kumar Gala @ 2007-08-23 4:16 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev@ozlabs.org list, Paul Mackerras
In-Reply-To: <20070823033318.GJ7042@localhost.localdomain>
On Aug 22, 2007, at 10:33 PM, David Gibson wrote:
> On Wed, Aug 22, 2007 at 10:33:55PM -0500, Kumar Gala wrote:
>>
>> On Aug 22, 2007, at 10:19 AM, Kumar Gala wrote:
>>
>>> Guys,
>>>
>>> I was wondering if I could get your help with looking at the
>>> following lists and determining if we have an issue or not related
>>> the following files:
>>>
>>> Getting some classification on these would be good. Possibly
>>> classifications, doesn't build in ARCH=powerpc, remove include, real
>>> issue, etc.
>>>
>>> - k
>>
>> My analysis of <asm/bootinfo.h> usage:
>>
>> ./drivers/macintosh/adb-iop.c:#include <asm/bootinfo.h> remove
>> ./drivers/char/vme_scc.c:#include <asm/bootinfo.h> 68k only
>> ./drivers/char/serial167.c:#include <asm/bootinfo.h> 68k only
>> ./drivers/serial/dz.c:#include <asm/bootinfo.h> decstation
>> ./drivers/mtd/devices/ms02-nv.c:#include <asm/bootinfo.h> decstation
>> ./drivers/net/macsonic.c:#include <asm/bootinfo.h> 68k
>> ./drivers/net/jazzsonic.c:#include <asm/bootinfo.h> mips
>> ./drivers/video/pmag-aa-fb.c:#include <asm/bootinfo.h> mips
>> ./drivers/video/maxinefb.c:#include <asm/bootinfo.h> mips
>> ./drivers/video/logo/logo.c:#include <asm/bootinfo.h> mips
>> ./drivers/video/macfb.c:#include <asm/bootinfo.h> 68k
>> ./drivers/video/valkyriefb.c:#include <asm/bootinfo.h> 68k
>
> Uh.. I'm pretty sure valkyriefb.c is for (old) PowerMacs, not 68k.
It appears to be both. If you look at the include its protected by a
#ifdef CONFIG_MAC which we is only defined on m68k.
- k
^ permalink raw reply
* Please pull from 'for-2.6.24' branch
From: Kumar Gala @ 2007-08-23 4:16 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Please pull from 'for-2.6.24' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.24
This has been rebased against your latest for-2.6.24 branch and includes
the removal of <asm/bootinfo.h> to drivers/macintosh/adb-iop.c.
All other driver related patches have been sent to their maintainers.
(IDE, MTD, NET).
I think this is as good as it gets.
to receive the following updates:
arch/powerpc/Makefile | 17
arch/powerpc/kernel/setup_32.c | 2
arch/powerpc/platforms/52xx/lite5200.c | 1
arch/powerpc/platforms/82xx/m82xx_pci.h | 2
arch/powerpc/platforms/82xx/mpc82xx.c | 1
arch/powerpc/platforms/82xx/mpc82xx_ads.c | 1
arch/powerpc/platforms/82xx/pq2ads.h | 1
arch/powerpc/platforms/83xx/mpc832x_mds.c | 1
arch/powerpc/platforms/83xx/mpc834x_itx.c | 1
arch/powerpc/platforms/83xx/mpc834x_mds.c | 1
arch/powerpc/platforms/83xx/mpc836x_mds.c | 1
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 1
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 1
arch/powerpc/platforms/8xx/m8xx_setup.c | 4
arch/powerpc/platforms/8xx/mpc86xads.h | 1
arch/powerpc/platforms/8xx/mpc86xads_setup.c | 1
arch/powerpc/platforms/8xx/mpc885ads.h | 1
arch/powerpc/platforms/8xx/mpc885ads_setup.c | 1
arch/powerpc/platforms/chrp/gg2.h | 61 +
arch/powerpc/platforms/chrp/pci.c | 2
arch/powerpc/platforms/chrp/setup.c | 2
arch/powerpc/platforms/chrp/smp.c | 1
arch/powerpc/platforms/embedded6xx/linkstation.c | 3
arch/powerpc/platforms/embedded6xx/ls_uart.c | 4
arch/powerpc/platforms/embedded6xx/mpc10x.h | 180 +++
arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c | 1
arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.h | 21
arch/powerpc/platforms/powermac/bootx_init.c | 1
drivers/macintosh/adb-iop.c | 1
drivers/macintosh/ans-lcd.c | 3
drivers/macintosh/ans-lcd.h | 11
include/asm-powerpc/8xx_immap.h | 564 +++++++++
include/asm-powerpc/commproc.h | 692 ++++++++++++
include/asm-powerpc/cpm2.h | 1248 ++++++++++++++++++++++
include/asm-powerpc/highmem.h | 135 ++
include/asm-powerpc/hydra.h | 102 +
include/asm-powerpc/immap_cpm2.h | 648 +++++++++++
include/asm-powerpc/kgdb.h | 57 +
include/asm-powerpc/mpc52xx_psc.h | 191 +++
include/asm-ppc/ans-lcd.h | 11
40 files changed, 3900 insertions(+), 78 deletions(-)
Kumar Gala (3):
[POWERPC] Remove old includes from arch/ppc
[POWERPC] Copy over headers from arch/ppc to arch/powerpc that we need
[POWERPC] Stop include asm-ppc when building ARCH=powerpc for ppc32
^ permalink raw reply
* Re: wmb vs mmiowb
From: Nick Piggin @ 2007-08-23 4:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-ia64, Jesse Barnes, linuxppc-dev
In-Reply-To: <alpine.LFD.0.999.0708221953360.30176@woody.linux-foundation.org>
On Wed, Aug 22, 2007 at 07:57:56PM -0700, Linus Torvalds wrote:
>
>
> On Thu, 23 Aug 2007, Nick Piggin wrote:
> >
> > > Irix actually had an io_unlock() routine that did this
> > > implicitly, but iirc that was shot down for Linux...
> >
> > Why was it shot down? Seems like a pretty good idea to me ;)
>
> It's horrible. We'd need it for *every* single spinlock type. We have lots
> of them.
>
> So the choice is between:
>
> - sane:
>
> mmiowb()
>
> followed by any of the existing "spin_unlock()" variants (plain,
> _irq(), _bh(), _irqrestore())
>
> - insane: multiply our current set of unlock primitives by two, by making
> "io" versions for them all:
>
> spin_unlock_io[_irq|_irqrestore|_bh]()
>
> but there's actually an EVEN WORSE problem with the stupid Irix approach,
> namely that it requires that the unlocker be aware of the exact details of
> what happens inside the lock. If the locking is done at an outer layer,
> that's not at all obvious!
Also, FWIW, there are some advantages of deferring the mmiowb thingy
until the point of unlock. The disadvantage is that the caller may not
know if the inner layer performed ios that require the mmiowb, but
the advantage of waiting until unlock is that the wait is deferred
for as long as possible, and will hopefully be a shorter one when
performed later.
^ permalink raw reply
* Re: [PATCH] ppc: remove unused amiga_request_irq and mach_request_irq
From: Fernando Luis Vázquez Cao @ 2007-08-23 5:27 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <18124.1417.743332.974941@cargo.ozlabs.ibm.com>
On Wed, 2007-08-22 at 19:44 +1000, Paul Mackerras wrote:
> Fernando Luis Vázquez Cao writes:
>
> > amiga_request_irq and mach_request_irq are never used, so delete them.
>
> OK, but is there a particular reason you want to do this?
Hi Paul,
Thank you for your reply.
I am currently auditing all the interrupt handlers and related code
(request_irq(), free_irq(), and others of that ilk) and, in the process,
I found some dead code. Getting rid of this cruft would just make my
life easier.
The final goal of this audit is to determine whether the Linux interrupt
handlers are kdump-ready. With the advent of kdump it is now possible
that device drivers have to handle pending interrupts generated in the
context of a previous kernel. Any pending interrupts will come in as
soon as the IRQ is allocated, but, unfortunately, not all the device
drivers handle this situation properly.
Besides, I am also trying to determine if applying this patch:
http://lkml.org/lkml/2007/7/19/687
is a sane thing to do.
> The whole of arch/ppc is going away eventually, so I don't think we
> need to remove it piece by piece.
As Linas mentioned in his reply, cleaning things up first will probably
make things easier for you too.
Please consider merging the four patches I sent to the PPC mailing list.
Fernando
^ permalink raw reply
* Re: [PATCH] ppc: remove unused amiga_request_irq and mach_request_irq
From: Fernando Luis Vázquez Cao @ 2007-08-23 5:29 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20070822182859.GX4261@austin.ibm.com>
On Wed, 2007-08-22 at 13:28 -0500, Linas Vepstas wrote:
> On Wed, Aug 22, 2007 at 07:44:41PM +1000, Paul Mackerras wrote:
> > Fernando Luis Vázquez Cao writes:
> >
> > > amiga_request_irq and mach_request_irq are never used, so delete them.
> >
> > OK, but is there a particular reason you want to do this?
> >
> > The whole of arch/ppc is going away eventually, so I don't think we
> > need to remove it piece by piece.
>
> Its often easier to port/move stuff if you clean it up first.
Agreed. It would make things easier for me too.
Fernando
^ permalink raw reply
* Re: bogus vscsi dt node on iseries
From: Olaf Hering @ 2007-08-23 5:42 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20070823133621.830245c4.sfr@canb.auug.org.au>
On Thu, Aug 23, Stephen Rothwell wrote:
> On Wed, 22 Aug 2007 19:51:21 +0200 Olaf Hering <olaf@aepfle.de> wrote:
> >
> >
> > Does anyone know why dt_vdevices() creates a vscsi node on legacy iseries?
> > I'm sure only viodasd and viocd is required as blockdevice type.
>
> Because the IBM vscsi client (in theory) works on legacy iSeries.
I'm asking because there are many unneeded nodes.
Have you tried to create only the nodes for disks/cds that are really
present and modify viodasd to use only device-tree data?
^ permalink raw reply
* Re: Need the bdi cfg file for taihu PPCEP405 Eval board
From: Stefan Roese @ 2007-08-23 5:52 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <OF4E3437FA.70738D18-ON8525733F.00715D10-8525733F.007168AC@rflelect.com>
[-- Attachment #1: Type: text/plain, Size: 737 bytes --]
On Wednesday 22 August 2007, ravi.rao@rflelect.com wrote:
> Can one of you please email me the bdi config file for Taihu Eval
> board. I need to attach bdi200 and do some debugging on that..
I don't have a config file for the Taihu, but I attached one for a board
that's quite similar to the AMCC Taihu. Needs some small changes perhaps.
Just give it a try.
Best regards,
Stefan
=====================================================================
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
=====================================================================
[-- Attachment #2: zeus.cfg --]
[-- Type: text/plain, Size: 3186 bytes --]
;bdiGDB configuration file for Zeus for U-Boot
; --------------------------------------------
;
[INIT]
; init core register
WSPR 954 0x00000000 ;DCWR: Disable data cache write-thru
WSPR 1018 0x00000000 ;DCCR: Disable data cache
WSPR 1019 0x00000000 ;ICCR: Disable instruction cache
WSPR 982 0xFFF80000 ;EVPR: Exception Vector Table @0x00000000
;
WDCR 0x0F9 0x00000010 ; enable WR# (PCI_INT/WR# multiplexing)
; Setup PLL
; CPU=133MHz
; PLB=133MHz
; OPB=66MHz
; EBC=33MHz
WDCR 0x0F0 0x00001203
WDCR 0x0F4 0x8042223E
; Setup Peripheral Bus
; CS0 (default mode)
WDCR 18 0x00000010 ;Select PB0AP
WDCR 19 0x05815600 ;PB0AP: NOR Flash/SRAM
WDCR 18 0x00000000 ;Select PB0CR
WDCR 19 0xff09a000 ;PB0CR: BAS=0xFF0,BS=4MB,BU=R/W,BW=16bit
; Setup SDRAM Controller
WDCR 16 0x00000080 ;Select SDTR1
WDCR 17 0x01074015 ;SDTR1: SDRAM Timing Register
WDCR 16 0x00000040 ;Select MB0CF
WDCR 17 0x00084001 ;MB0CF: 16MB @ 0x00000000
WDCR 16 0x00000030 ;Select RTR
WDCR 17 0x07f00000 ;RTR: Refresh Timing Register
WDCR 16 0x00000020 ;Select MCOPT1
WDCR 17 0x80800000 ;MCOPT1: Enable SDRAM Controller
; Setup MMU info - these lines must be uncommented to debug Linux kernel
;WM32 0x000000f4 0x00000000 ;invalidate kernel page table base
;WM32 0x000000f8 0x00000000 ;invalidate process page table base
;WM32 0x000000f0 0xc00000f4 ;invalidate page table base
; Setup OCM
WDCR 0x01A 0xEC000000
WDCR 0x01B 0xC0000000
[TARGET]
JTAGCLOCK 0 ;use 16 MHz JTAG clock
CPUTYPE 405 ;the used target CPU type
BDIMODE AGENT ;the BDI working mode (LOADONLY | AGENT)
WAKEUP 1000 ;wakeup time after reset
BREAKMODE HARD ;SOFT or HARD, HARD uses PPC hardware breakpoint
STEPMODE HWBP ;JTAG or HWBP, HWPB uses one or two hardware breakpoints
;VECTOR CATCH ;catch unhandled exceptions
;MMU XLAT 0xC0000000 ;enable virtual address mode
;PTBASE 0x000000f0 ;address where kernel/user stores pointer to page table
;SIO 7 9600 ;TCP port for serial IO
;REGLIST SPR ;select register to transfer to GDB
REGLIST ALL ;select register to transfer to GDB
;SCANPRED 2 2 ;JTAG devices connected before PPC400
;SCANSUCC 3 3 ;JTAG devices connected after PPC400
[HOST]
IP 10.0.0.152
FORMAT BIN
FILE /tftpboot/zeus/u-boot.bin
LOAD MANUAL ;load code MANUAL or AUTO after reset
DEBUGPORT 2001
PROMPT zeus>
[FLASH]
WORKSPACE 0x100000 ;workspace in on-chip SRAM for fast programming algorithm
CHIPTYPE MIRRORX16 ;Flash type
CHIPSIZE 0x1000000 ;16MB The size of one flash chip in bytes
BUSWIDTH 16 ;The width of the flash memory bus in bits (8 | 16 | 32)
FILE /tftpboot/zeus/u-boot.bin
FORMAT BIN 0xFFFC0000
; Erase just the last seven blocks for U-Boot
ERASE 0xFFFC0000
ERASE 0xFFFE0000
[REGS]
IDCR1 0x010 0x011 ;MEMCFGADR and MEMCFGDATA
IDCR2 0x012 0x013 ;EBCCFGADR and EBCCFGDATA
;IDCR3 0x014 0x015 ;KIAR and KIDR
FILE /tftpboot/BDI2000/reg405ep.def
^ permalink raw reply
* STK5200 pci_enable_device problem
From: Mustafa Cayır @ 2007-08-23 5:42 UTC (permalink / raw)
To: linuxppc-embedded
Hi all,
I am working on TQ STK52000 development board with TQM5200-AB cpu =
module. I am trying to use PCI bus and Local Plus Bus together. SM501, =
video chip is located on local plus bus and PLX9030 based pci device is =
on pci bus.
My pci driver is able to scan pci bus and find succesfully the pci =
device. After this point, pci_enable_device function returns following =
error:
PCI: Device 00:18.0 not available because of resource collisions
Any help is appreciated.
^ permalink raw reply
* Re: bogus vscsi dt node on iseries
From: Stephen Rothwell @ 2007-08-23 5:59 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev
In-Reply-To: <20070823054239.GA24251@aepfle.de>
[-- Attachment #1: Type: text/plain, Size: 856 bytes --]
On Thu, 23 Aug 2007 07:42:39 +0200 Olaf Hering <olaf@aepfle.de> wrote:
>
> On Thu, Aug 23, Stephen Rothwell wrote:
>
> > On Wed, 22 Aug 2007 19:51:21 +0200 Olaf Hering <olaf@aepfle.de> wrote:
> > >
> > >
> > > Does anyone know why dt_vdevices() creates a vscsi node on legacy iseries?
> > > I'm sure only viodasd and viocd is required as blockdevice type.
> >
> > Because the IBM vscsi client (in theory) works on legacy iSeries.
>
> I'm asking because there are many unneeded nodes.
> Have you tried to create only the nodes for disks/cds that are really
> present and modify viodasd to use only device-tree data?
I'll have a look, but that would require interacting with the hypervisor
very early in the boot sequence ...
--
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: Section mismatch warning
From: sivaji @ 2007-08-23 6:00 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <C5046FD2-6781-4E6E-847B-1BDB24E5D81F@kernel.crashing.org>
Hi,
I applied the patch(13066). After that i got following error.
arch/powerpc/kernel/vmlinux.lds:59: parse error
I added the following lines in the vmlinux.lds file
ALIGN_FUNCTION();
*(.text.head)
Then i removed the ALIGN_FUNCTION() in the vmlinux.lds file. The parse error
was overcome. I don't know after removing the ALIGN_FUNCTION why the error
was overcome.
>
> Hi,
> When compiling the 2.6.23-rc3 kernel, i got following warning
> messages.
>
> WARNING: vmlinux.o(.text+0x18): Section mismatch: reference to
> .init.text:early_init (between '__start' and '__after_mmu_off')
> WARNING: vmlinux.o(.text+0x3834): Section mismatch: reference to
> .init.text:machine_init (between 'start_here' and 'set_context')
> WARNING: vmlinux.o(.text+0x383c): Section mismatch: reference to
> .init.text:MMU_init (between 'start_here' and 'set_context')
> WARNING: vmlinux.o(.text+0x3866): Section mismatch: reference to
> .init.text:start_kernel (between 'start_here' and 'set_context')
> WARNING: vmlinux.o(.text+0x386a): Section mismatch: reference to
> .init.text:start_kernel (between 'start_here' and 'set_context')
>
> Processor : 8641D
> Give some idea how to overcome this warning.
There is a patch posted on the list for this. I doubt will fix these
for 2.6.23 as they are just warnings.
http://patchwork.ozlabs.org/linuxppc/patch?id=13066
- k
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
View this message in context: http://www.nabble.com/Section-mismatch-warning-tf4315101.html#a12288012
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 2/2] [POWERPC] Size swapper_pg_dir correctly
From: Stephen Rothwell @ 2007-08-23 6:13 UTC (permalink / raw)
To: Kumar Gala; +Cc: ppc-dev, paulus
In-Reply-To: <DDBA4998-5BCC-413A-9759-3815693A68E6@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 626 bytes --]
On Wed, 22 Aug 2007 22:26:35 -0500 Kumar Gala <galak@kernel.crashing.org> wrote:
>
> > +#ifdef CONFIG_PPC64
> > + DEFINE(PGD_TABLE_SIZE, PGD_TABLE_SIZE);
> > +#endif
>
> Why limit this to ppc64? The cleanup should be reasonable for all ppc.
Because PGD_TABLE_SIZE only exists for ppc64 :-) for ppc32 the
swapper_pg_dir will always be 1 page, right?
So we could have
#define PGD_TABLE_SIZE PAGE_SIZE
for 32 bit and then go around and change the swapper_pg_dir's, but that
would be a separate patch.
--
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: [PATCH] Consolidate XILINX_VIRTEX board support
From: David H. Lynch Jr. @ 2007-08-23 6:43 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-embedded
In-Reply-To: <20070818205752.049d2bc6@vader.jdub.homelinux.org>
Josh Boyer wrote:
>> arch/boot/simple/embed_config.c jusst seems to be a random collection
>> of board specific code anyway.
>> A giant case statement implimented with #ifdef's. It is just
>> screaming to be done some better way.
>>
>> You mean like a device tree? ;)
>>
>> josh
>>
Maybe, I am waiting to see somebody move something to device tree so
that I can get a better grasp of what it is and how it works.
From what little I know I think it is going to be very significant for
my BSP - we are trying to use a single binary for alot of different
boards, or the same board with different firmware. From what I am
gathering I can have the loader pass a device tree to the kernel
and the device tree will basically describe the hardware to the kernel.
Only at the moment I don't have the time to learn enough to attempt to
lead the charge moving xilinx stuff to powerpc.
Is there a way to do this in small peices ?
It would be nice to end some of the debate on how to setup ppc/4xx for
multiple xilinx targets and just get it over with and move to powerpc
device tree, ...
But I can't beat others up for what I can't find time for myself.
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* Re: wmb vs mmiowb
From: Benjamin Herrenschmidt @ 2007-08-23 7:25 UTC (permalink / raw)
To: Nick Piggin; +Cc: Linus Torvalds, linux-ia64, Jesse Barnes, linuxppc-dev
In-Reply-To: <20070822045714.GD26374@wotan.suse.de>
On Wed, 2007-08-22 at 06:57 +0200, Nick Piggin wrote:
> It doesn't seem like this primary function of mmiowb has anything to do
> with a write barrier that we are used to (it may have a seconary semantic
> of a wmb as well, but let's ignore that for now). A write barrier will
> never provide you with those semantics (writes from 2 CPUs seen in the
> same order by a 3rd party). If anything, I think it is closer to being
> a read barrier issued on behalf of the target device. But even that I
> think is not much better, because the target is not participating in the
> synchronisation that the CPUs are, so the "read barrier request" could
> still arrive at the device out of order WRT the other CPU's writes.
>
> It really seems like it is some completely different concept from a
> barrier. And it shows, on the platform where it really matters (sn2), where
> the thing actually spins.
The way mmiowb was actually defined to me by the ia64 folks who came up
with it is essentially to order an MMIO write with a spin_unlock.
Ben.
^ permalink raw reply
* Re: wmb vs mmiowb
From: Benjamin Herrenschmidt @ 2007-08-23 7:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nick Piggin, linux-ia64, Jesse Barnes, linuxppc-dev
In-Reply-To: <alpine.LFD.0.999.0708221049560.30176@woody.linux-foundation.org>
> Of course, the normal memory barrier would usually be a "spin_unlock()" or
> something like that, not a "wmb()". In fact, I don't think the powerpc
> implementation (as an example of this) will actually synchronize with
> anything *but* a spin_unlock().
We are even more sneaky in the sense that we set a per-cpu flag on any
MMIO write and do the sync automatically in spin_unlock() :-)
Ben.
^ permalink raw reply
* Re: Device tree aware EMAC driver
From: Benjamin Herrenschmidt @ 2007-08-23 7:30 UTC (permalink / raw)
To: David Gibson; +Cc: netdev, Jeff Garzik, Paul Mackerras, linuxppc-dev
In-Reply-To: <20070823035601.GL7042@localhost.localdomain>
On Thu, 2007-08-23 at 13:56 +1000, David Gibson wrote:
>
>
> Jeff, I've discussed this with BenH, and although there are some
> problems with the driver still, we think it's good enough to merge in
> 2.6.24, the warts can be fixed up later. Please apply...
Or to be more precise:
This driver will work well for 4xx platforms and will allow us to move a
big step toward getting rid of arch/ppc. The issues with DMA mapping
really only concern the case where this is used within the cell "Axon"
southbridge, which doesn't happen on any released product at this stage.
Ben.
^ permalink raw reply
* Re: Driver for device behind a PCI-VME bridge
From: Konstantin Boyanov @ 2007-08-23 7:47 UTC (permalink / raw)
To: Johan Borkhuis; +Cc: linuxppc-embedded
In-Reply-To: <46CAE973.6040306@dutchspace.nl>
[-- Attachment #1: Type: text/plain, Size: 969 bytes --]
Hi again,
First of all thanks for reply.
> I attached a diff to the 3.7 version of the Motorola patch. I hope this
> will help you. This is not the Xenomai version, but the standard version
> with VME interrupts per level. The mechanism for Xenomai is identical,
> but I don't know yet about the legal status of this. The attached patch
> has also been provided to Motorola.
I've got the 3.5 version of the driver, and tried to find newer one. Where
do you get this new releases and patches?
Nevertheless thanks for the patch.
I also had some ssh problems, but AFAICR I had to enable UNIX98PTYS and
> BSDPTYS, and create the entries in /dev/ for the BSD ptys (/dev/ttypXX
> and /dev/ptyXX).
I also had these two options enabled, but still the kernel hangs at boot
time just after trying to initialize SCSI devices... Without Xenomai this
problem doesn't occur. I'm wondering what is that makes Xenomai mess up
things so badly?
Best regards,
Konstantin Boyanov
[-- Attachment #2: Type: text/html, Size: 1412 bytes --]
^ permalink raw reply
* Re: Driver for device behind a PCI-VME bridge
From: Johan Borkhuis @ 2007-08-23 8:24 UTC (permalink / raw)
To: Konstantin Boyanov; +Cc: linuxppc-embedded
In-Reply-To: <929bf310708230047n70bfe883gb963eba6e254b479@mail.gmail.com>
Konstantin Boyanov wrote:
> Hi again,
>
> First of all thanks for reply.
>
>
> I attached a diff to the 3.7 version of the Motorola patch. I hope
> this
> will help you. This is not the Xenomai version, but the standard
> version
> with VME interrupts per level. The mechanism for Xenomai is identical,
> but I don't know yet about the legal status of this. The attached
> patch
> has also been provided to Motorola.
>
>
> I've got the 3.5 version of the driver, and tried to find newer one.
> Where do you get this new releases and patches?
> Nevertheless thanks for the patch.
We got this patch directly from Motorola. Officially Motorola does not
support Linux, but you can ask Ajit Prem (Ajit.Prem@motorola.com) for
the latest version of the patch. As far as I know there is a patch
availeble for 2.6.14 and 2.6.20, but as you have a patch for 2.6.15
already it should not be to difficult to move the 2.6.14 patch to 2.6.15.
>
> I also had some ssh problems, but AFAICR I had to enable
> UNIX98PTYS and
> BSDPTYS, and create the entries in /dev/ for the BSD ptys
> (/dev/ttypXX
> and /dev/ptyXX).
>
>
> I also had these two options enabled, but still the kernel hangs at
> boot time just after trying to initialize SCSI devices... Without
> Xenomai this problem doesn't occur. I'm wondering what is that makes
> Xenomai mess up things so badly?
I did not try SCSI on my system I just disabled all devices that I don't
need, including SCSI. You could try disabling these devices for the
moment (or build them as modules and load these later by hand) and see
if that works, or that there are other problems.
If the problem is still there, you could try the Xenomai mailing list
(see www.xenomai.org).
Kind regards,
Johan Borkhuis
--
Johan Borkhuis Dutch Space BV
email: j.borkhuis@dutchspace.nl Newtonweg 1
phone: 071-5245788 Leiden
fax: 071-5245499 The Netherlands
^ permalink raw reply
* Re: STK5200 pci_enable_device problem
From: Oliver Rutsch @ 2007-08-23 7:24 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <7B9A8FF57DBB524190E98CABF6E56F078FAE4E@itri.bte.mam.gov.tr>
Hi Mustafa,
> Hi all,
>
[...]
>
> My pci driver is able to scan pci bus and find succesfully the pci
> device. After this point, pci_enable_device function returns
> following error:
>
> PCI: Device 00:18.0 not available because of resource collisions
>
Which ELDK and kernel do you use? I had the same problem on this board
with a PLX9054 based PCI card on a 2.4.25 kernel. I switched to the 2.6
kernel and the 4.1 ELDK and the card was scanned correctly.
But keep in mind that the linux PLX drivers do not work out of the box
with a big endian platform like the MPC5200. Although there is a
BIG_ENDIAN flag in the makefiles there are still some places left in the
driver code which have to be patched (the parts with int64 adresses).
It's not so easy to compile the PLX drivers on the 4.1 ELDK because of
missing headers in the ppc architecture. I managed to build the drivers
for the 2.6.19 kernel and I was able to work with the card except the
DMA routines (still working on this issue).
Hope this helps. Bye,
--
Dipl. Ing. Oliver Rutsch
^ permalink raw reply
* Re: 2.6.23-rc3 is not booting
From: sivaji @ 2007-08-23 9:30 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <BEAC6061-FBAC-45EE-9D2A-C0904DDFECAD@kernel.crashing.org>
Hi,
I am using 8641D processor and the silicon revision is 2.0.
Part : MPC8641D
Revision: 2.0
e600 Core Revision: 2.2
DeviceMarking: B
Processor Version Register Value: 0x8004_0202
System Version Register Value: 0x8090_0120
by
Sivaji
>
> Hai,
> I am using the kernel 2.6.23-rc3. i am trying to boot this
> kernel
> to my 8641D board. It was not booting.
> I go the following message
>
> Bytes transferred = 1505 (5e1 hex)
> ## Booting image at 00200000 ...
> Image Name: Linux-2.6.23-rc3
> Image Type: PowerPC Linux Kernel Image (gzip compressed)
> Data Size: 1801717 Bytes = 1.7 MB
> Load Address: 00000000
> Entry Point: 00000000
> Verifying Checksum ... OK
> Uncompressing Kernel Image ... OK
> Booting using flat device tree at 0x800000
>
> Whether the problem belongs to device tree? I am using the
> mpc8641_hpcn.dts
> file
>
> Pls Advice me.
What rev board/silicon do you have? I'd suggest building the kernel
w/o PCI support and see what happens. Make sure you've got the
latest dts from the kernel tree.
- k
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
--
View this message in context: http://www.nabble.com/2.6.23-rc3-is-not-booting-tf4309661.html#a12290295
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* Re: asm-ppc header issues when building ARCH=powerpc
From: Geert Uytterhoeven @ 2007-08-23 9:47 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list, Paul Mackerras, David Gibson
In-Reply-To: <F19C9986-9E53-47F3-835D-C93DA9C3ADED@kernel.crashing.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2269 bytes --]
On Wed, 22 Aug 2007, Kumar Gala wrote:
> On Aug 22, 2007, at 10:33 PM, David Gibson wrote:
> > On Wed, Aug 22, 2007 at 10:33:55PM -0500, Kumar Gala wrote:
> >> On Aug 22, 2007, at 10:19 AM, Kumar Gala wrote:
> >>> I was wondering if I could get your help with looking at the
> >>> following lists and determining if we have an issue or not related
> >>> the following files:
> >>>
> >>> Getting some classification on these would be good. Possibly
> >>> classifications, doesn't build in ARCH=powerpc, remove include, real
> >>> issue, etc.
> >>>
> >> My analysis of <asm/bootinfo.h> usage:
> >>
> >> ./drivers/macintosh/adb-iop.c:#include <asm/bootinfo.h> remove
> >> ./drivers/char/vme_scc.c:#include <asm/bootinfo.h> 68k only
> >> ./drivers/char/serial167.c:#include <asm/bootinfo.h> 68k only
> >> ./drivers/serial/dz.c:#include <asm/bootinfo.h> decstation
> >> ./drivers/mtd/devices/ms02-nv.c:#include <asm/bootinfo.h> decstation
> >> ./drivers/net/macsonic.c:#include <asm/bootinfo.h> 68k
> >> ./drivers/net/jazzsonic.c:#include <asm/bootinfo.h> mips
> >> ./drivers/video/pmag-aa-fb.c:#include <asm/bootinfo.h> mips
> >> ./drivers/video/maxinefb.c:#include <asm/bootinfo.h> mips
> >> ./drivers/video/logo/logo.c:#include <asm/bootinfo.h> mips
> >> ./drivers/video/macfb.c:#include <asm/bootinfo.h> 68k
> >> ./drivers/video/valkyriefb.c:#include <asm/bootinfo.h> 68k
> >
> > Uh.. I'm pretty sure valkyriefb.c is for (old) PowerMacs, not 68k.
>
> It appears to be both. If you look at the include its protected by a
> #ifdef CONFIG_MAC which we is only defined on m68k.
Indeed, drivers/video/Kconfig says it depends on MAC || (PPC_PMAC && PPC32)
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* Re: signals handling in the kernel
From: Mirek23 @ 2007-08-23 10:57 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <46C9C70D.9080903@ovro.caltech.edu>
Hi David,
Thank you for your hints. I was not aware about race conditions in
signal handling routines. So far I did not noticed any anomalies when
running my server since I use only one interrupt which refers to only one
signal.
I would be interested however in the solution you have suggested with:
SIGIO and fasync()
Would you be so kind to provide me with some example code.
Best Regards
Mirek
David Hawkins-3 wrote:
>
> Hi Mirek,
>
>> In my case I found somehow more convenient to deal with
>> signals.
>
> Ok.
>
>> The server program which I use was originally written
>> for VxWorks. In VxWorks there was no separation betwenn
>> the user and kernel space. When the interrupt occured
>> in VxWorks the interrupt service routine was called.
>> The interrupt service routine was implemented in the server.
>>
>> I found it somehow easier to use signals to trigger signal handler
>> (previously in VxWorks interrupt service routine) than changing the
>> structure of the server to deal with select().
>
> I guess it depends on what you consider 'easier'.
> Signals have potential race conditions, and so using
> select() is safer. I find it 'easier' to have less
> problems, so would spend the time to make the server
> use select().
>
> But, you are free to ignore this advice. :)
>
>> I hope however that there is no fundamental problem with
>> sending signals from kernel (interrupt service routine)
>> to the user space.
>
> There are potential race conditions. I'm not sure if this
> problem was 2.4 kernel specific, or 2.6 kernel specific,
> or signals specific. I think its signals specific.
>
> A web search should yield more info on this. Try googling
> 'signals race condition', and it looks like its a problem
> still.
>
> So it depends on whether your server is running in
> a critical, and secure system, as to whether you want
> to stick with signals.
>
>> I do not know why the function kill_proc_info does not
>> export its symbol within the kernel 2.6.21 .
>> With previous version of the kernel 2.4 and early 2.6.*
>> the kill_proc_info symbol was exported.
>
> If SIGIO is sufficient for you, then just use the driver
> fasync() call-back mechanism. The example code I referred
> to has an example. If its not clear to you, I can
> explain it.
>
> If you're having to modify some corner of the kernel not
> used by many, then I'm sure your solution is not the
> correct one, and you won't get anyone helping you
> when things go wrong.
>
> So, take the experience of others; re-write the server
> to use signals. If the server was well written to start
> with you should be able to call the 'signal handler'
> function after returning from your select() call with
> the handle ready. It shouldn't be that hard.
>
> Come on, you've just returned from holiday, it should
> be no sweat to code up a new server :)
>
> Regards,
> Dave
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/signals-handling-in-the-kernel-tf4229566.html#a12291367
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox