* Re: DTC/dts modifications
From: Andreas Schwab @ 2006-05-01 22:59 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, jdl
In-Reply-To: <00CD15B8-F448-4985-8EEC-3BBF61C0110B@kernel.crashing.org>
Kumar Gala <galak@kernel.crashing.org> writes:
> Cool, here's an invocation that seems to work well. Not sure what
> causes linux = 1 (thus I need the -U linux). Also address the line
> information that is normally spit out.
>
> cpp -U linux -P -x assembler-with-cpp foo.dts
Try -undef, that removes all pre-defined macros.
Andreas.
--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH 11/13] cell: split out board specific files
From: Geoff Levand @ 2006-05-01 22:51 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Arnd Bergmann, Arnd Bergmann, linux-kernel, linuxppc-dev, paulus,
cbe-oss-dev
In-Reply-To: <F989FA67-91B5-493B-9A12-D02C3C14A984@kernel.crashing.org>
Segher Boessenkool wrote:
>> Split the Cell BE support into generic and platform
>> dependant parts.
>>
>> Creates a new config variable CONFIG_PPC_IBM_CELL_BLADE.
>> The existing CONFIG_PPC_CELL is now used to denote the
>> generic Cell processor support. Also renames spu_priv1.c
>> to spu_priv1_mmio.c.
>
>> config CELL_IIC
>> - depends on PPC_CELL
>> + depends on PPC_IBM_CELL_BLADE
>> bool
>> default y
>
> Erm no... Make this
>
> depends on PPC_CELL && !SOME_HYPERVISOR_THING
>
> to reflect the _real_ dependency please? Similar in a few other
> places perhaps.
Seems CELL_IIC is never used. Must be some stale variable,
so I removed it. Arnd, could you ack this.
Segher, a problem with your suggestion is that our
makefiles don't have as rich a set of logical ops as the
config files. Its easy to express 'build A if B', but not
so easy to do 'build A if not C'. To make this work
cleanly I made PPC_CELL denote !SOME_HYPERVISOR_THING,
so I can have constructions like this in the makefile:
obj-$(CONFIG_PPC_CELL) += ...
I also got rid of SPUFS_PRIV1_MMIO, since SPUFS_PRIV1_MMIO
just meant spufs with !SOME_HYPERVISOR_THING.
Updated patch follows.
-Geoff
Split the Cell BPA support into generic and platform
dependant parts.
Creates new config variable CONFIG_PPC_IBM_CELL_BLADE.
Also renames spu_priv1.c to spu_priv1_mmio.c.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Index: cell--alp--2/arch/powerpc/Kconfig
===================================================================
--- cell--alp--2.orig/arch/powerpc/Kconfig 2006-05-01 15:13:22.000000000 -0700
+++ cell--alp--2/arch/powerpc/Kconfig 2006-05-01 15:16:38.000000000 -0700
@@ -391,15 +391,20 @@
For more informations, refer to <http://www.970eval.com>
config PPC_CELL
- bool " Cell Broadband Processor Architecture"
+ bool
+ default n
+
+config PPC_IBM_CELL_BLADE
+ bool " IBM Cell Blade"
depends on PPC_MULTIPLATFORM && PPC64
+ select PPC_CELL
select PPC_RTAS
select MMIO_NVRAM
select PPC_UDBG_16550
config PPC_SYSTEMSIM
bool " IBM Full System Simulator (systemsim) support"
- depends on PPC_CELL || PPC_PSERIES || PPC_MAPLE
+ depends on PPC_IBM_CELL_BLADE || PPC_PSERIES || PPC_MAPLE
help
Support booting resulting image under IBMs Full System Simulator.
If you enable this option, you are able to select device
@@ -450,11 +455,6 @@
depends on PPC_MAPLE
default y
-config CELL_IIC
- depends on PPC_CELL
- bool
- default y
-
config IBMVIO
depends on PPC_PSERIES || PPC_ISERIES
bool
Index: cell--alp--2/arch/powerpc/configs/cell_defconfig
===================================================================
--- cell--alp--2.orig/arch/powerpc/configs/cell_defconfig 2006-05-01 15:13:22.000000000 -0700
+++ cell--alp--2/arch/powerpc/configs/cell_defconfig 2006-05-01 15:13:23.000000000 -0700
@@ -116,6 +116,7 @@
# CONFIG_PPC_PMAC is not set
# CONFIG_PPC_MAPLE is not set
CONFIG_PPC_CELL=y
+CONFIG_PPC_IBM_CELL_BLADE=y
CONFIG_PPC_SYSTEMSIM=y
# CONFIG_U3_DART is not set
CONFIG_PPC_RTAS=y
@@ -123,7 +124,6 @@
CONFIG_RTAS_PROC=y
CONFIG_RTAS_FLASH=y
CONFIG_MMIO_NVRAM=y
-CONFIG_CELL_IIC=y
# CONFIG_PPC_MPC106 is not set
# CONFIG_CPU_FREQ is not set
# CONFIG_WANT_EARLY_SERIAL is not set
@@ -133,6 +133,7 @@
#
CONFIG_BE_DD2=y
CONFIG_SPU_FS=m
+CONFIG_SPU_BASE=y
CONFIG_SPUFS_MMAP=y
#
Index: cell--alp--2/arch/powerpc/configs/systemsim_defconfig
===================================================================
--- cell--alp--2.orig/arch/powerpc/configs/systemsim_defconfig 2006-05-01 15:13:22.000000000 -0700
+++ cell--alp--2/arch/powerpc/configs/systemsim_defconfig 2006-05-01 15:13:23.000000000 -0700
@@ -117,6 +117,7 @@
# CONFIG_PPC_PMAC is not set
CONFIG_PPC_MAPLE=y
CONFIG_PPC_CELL=y
+CONFIG_PPC_IBM_CELL_BLADE=y
CONFIG_PPC_SYSTEMSIM=y
CONFIG_SYSTEMSIM_IDLE=y
CONFIG_XICS=y
@@ -128,7 +129,6 @@
# CONFIG_RTAS_FLASH is not set
CONFIG_MMIO_NVRAM=y
CONFIG_MPIC_BROKEN_U3=y
-CONFIG_CELL_IIC=y
CONFIG_IBMVIO=y
# CONFIG_IBMEBUS is not set
# CONFIG_PPC_MPC106 is not set
@@ -139,6 +139,7 @@
# Cell Broadband Engine options
#
CONFIG_SPU_FS=m
+CONFIG_SPU_BASE=y
#
# Kernel options
Index: cell--alp--2/arch/powerpc/platforms/cell/Kconfig
===================================================================
--- cell--alp--2.orig/arch/powerpc/platforms/cell/Kconfig 2006-05-01 15:13:22.000000000 -0700
+++ cell--alp--2/arch/powerpc/platforms/cell/Kconfig 2006-05-01 15:13:23.000000000 -0700
@@ -11,10 +11,15 @@
or may crash other CPUs.
Say 'n' here unless you expect to run on DD2.0 only.
+config SPU_BASE
+ bool
+ default n
+
config SPU_FS
tristate "SPU file system"
default m
depends on PPC_CELL
+ select SPU_BASE
help
The SPU file system is used to access Synergistic Processing
Units on machines implementing the Broadband Processor
Index: cell--alp--2/arch/powerpc/platforms/cell/Makefile
===================================================================
--- cell--alp--2.orig/arch/powerpc/platforms/cell/Makefile 2006-05-01 15:13:22.000000000 -0700
+++ cell--alp--2/arch/powerpc/platforms/cell/Makefile 2006-05-01 15:17:58.000000000 -0700
@@ -1,14 +1,14 @@
-obj-y += interrupt.o iommu.o setup.o spider-pic.o
-obj-y += pervasive.o pci.o
-
-obj-$(CONFIG_SMP) += smp.o
+obj-$(CONFIG_PPC_CELL) += interrupt.o iommu.o setup.o \
+ spider-pic.o pervasive.o pci.o
+ifeq ($(CONFIG_SMP),y)
+obj-$(CONFIG_PPC_CELL) += smp.o
+endif
# needed only when building loadable spufs.ko
-spufs-modular-$(CONFIG_SPU_FS) += spu_syscalls.o
-obj-y += $(spufs-modular-m)
-
-# always needed in kernel
-spufs-builtin-$(CONFIG_SPU_FS) += spu_callbacks.o spu_base.o spu_priv1.o
-obj-y += $(spufs-builtin-y) $(spufs-builtin-m)
-
-obj-$(CONFIG_SPU_FS) += spufs/
+spufs-modular-$(CONFIG_SPU_FS) += spu_syscalls.o
+obj-$(CONFIG_SPU_BASE) += spu_callbacks.o spu_base.o \
+ $(spufs-modular-m)
+ifdef CONFIG_SPU_FS
+obj-$(CONFIG_PPC_CELL) += spu_priv1_mmio.o
+endif
+obj-$(CONFIG_SPU_FS) += spufs/
Index: cell--alp--2/arch/powerpc/platforms/cell/spu_priv1.c
===================================================================
--- cell--alp--2.orig/arch/powerpc/platforms/cell/spu_priv1.c 2006-05-01 15:13:22.000000000 -0700
+++ cell--alp--2/arch/powerpc/platforms/cell/spu_priv1.c 2006-04-21 13:04:41.284693750 -0700
@@ -1,142 +0,0 @@
-/*
- * access to SPU privileged registers
- */
-#include <linux/module.h>
-
-#include <asm/io.h>
-#include <asm/spu.h>
-
-void spu_int_mask_and(struct spu *spu, int class, u64 mask)
-{
- u64 old_mask;
-
- old_mask = in_be64(&spu->priv1->int_mask_RW[class]);
- out_be64(&spu->priv1->int_mask_RW[class], old_mask & mask);
-}
-EXPORT_SYMBOL_GPL(spu_int_mask_and);
-
-void spu_int_mask_or(struct spu *spu, int class, u64 mask)
-{
- u64 old_mask;
-
- old_mask = in_be64(&spu->priv1->int_mask_RW[class]);
- out_be64(&spu->priv1->int_mask_RW[class], old_mask | mask);
-}
-EXPORT_SYMBOL_GPL(spu_int_mask_or);
-
-void spu_int_mask_set(struct spu *spu, int class, u64 mask)
-{
- out_be64(&spu->priv1->int_mask_RW[class], mask);
-}
-EXPORT_SYMBOL_GPL(spu_int_mask_set);
-
-u64 spu_int_mask_get(struct spu *spu, int class)
-{
- return in_be64(&spu->priv1->int_mask_RW[class]);
-}
-EXPORT_SYMBOL_GPL(spu_int_mask_get);
-
-void spu_int_stat_clear(struct spu *spu, int class, u64 stat)
-{
- out_be64(&spu->priv1->int_stat_RW[class], stat);
-}
-EXPORT_SYMBOL_GPL(spu_int_stat_clear);
-
-u64 spu_int_stat_get(struct spu *spu, int class)
-{
- return in_be64(&spu->priv1->int_stat_RW[class]);
-}
-EXPORT_SYMBOL_GPL(spu_int_stat_get);
-
-void spu_int_route_set(struct spu *spu, u64 route)
-{
- out_be64(&spu->priv1->int_route_RW, route);
-}
-EXPORT_SYMBOL_GPL(spu_int_route_set);
-
-u64 spu_mfc_dar_get(struct spu *spu)
-{
- return in_be64(&spu->priv1->mfc_dar_RW);
-}
-EXPORT_SYMBOL_GPL(spu_mfc_dar_get);
-
-u64 spu_mfc_dsisr_get(struct spu *spu)
-{
- return in_be64(&spu->priv1->mfc_dsisr_RW);
-}
-EXPORT_SYMBOL_GPL(spu_mfc_dsisr_get);
-
-void spu_mfc_dsisr_set(struct spu *spu, u64 dsisr)
-{
- out_be64(&spu->priv1->mfc_dsisr_RW, dsisr);
-}
-EXPORT_SYMBOL_GPL(spu_mfc_dsisr_set);
-
-void spu_mfc_sdr_set(struct spu *spu, u64 sdr)
-{
- out_be64(&spu->priv1->mfc_sdr_RW, sdr);
-}
-EXPORT_SYMBOL_GPL(spu_mfc_sdr_set);
-
-void spu_mfc_sr1_set(struct spu *spu, u64 sr1)
-{
- out_be64(&spu->priv1->mfc_sr1_RW, sr1);
-}
-EXPORT_SYMBOL_GPL(spu_mfc_sr1_set);
-
-u64 spu_mfc_sr1_get(struct spu *spu)
-{
- return in_be64(&spu->priv1->mfc_sr1_RW);
-}
-EXPORT_SYMBOL_GPL(spu_mfc_sr1_get);
-
-void spu_mfc_tclass_id_set(struct spu *spu, u64 tclass_id)
-{
- out_be64(&spu->priv1->mfc_tclass_id_RW, tclass_id);
-}
-EXPORT_SYMBOL_GPL(spu_mfc_tclass_id_set);
-
-u64 spu_mfc_tclass_id_get(struct spu *spu)
-{
- return in_be64(&spu->priv1->mfc_tclass_id_RW);
-}
-EXPORT_SYMBOL_GPL(spu_mfc_tclass_id_get);
-
-void spu_smm_pgsz_set(struct spu *spu, u64 pgsz)
-{
- u64 smm_hid;
- smm_hid = in_be64(&spu->priv1->smm_hid);
- smm_hid &= ~(0xfull << 60);
- smm_hid |= pgsz << 60;
- out_be64(&spu->priv1->smm_hid, smm_hid);
-}
-
-void spu_tlb_invalidate(struct spu *spu)
-{
- out_be64(&spu->priv1->tlb_invalidate_entry_W, 0ul);
-}
-EXPORT_SYMBOL_GPL(spu_tlb_invalidate);
-
-void spu_resource_allocation_groupID_set(struct spu *spu, u64 id)
-{
- out_be64(&spu->priv1->resource_allocation_groupID_RW, id);
-}
-EXPORT_SYMBOL_GPL(spu_resource_allocation_groupID_set);
-
-u64 spu_resource_allocation_groupID_get(struct spu *spu)
-{
- return in_be64(&spu->priv1->resource_allocation_groupID_RW);
-}
-EXPORT_SYMBOL_GPL(spu_resource_allocation_groupID_get);
-
-void spu_resource_allocation_enable_set(struct spu *spu, u64 enable)
-{
- out_be64(&spu->priv1->resource_allocation_enable_RW, enable);
-}
-EXPORT_SYMBOL_GPL(spu_resource_allocation_enable_set);
-
-u64 spu_resource_allocation_enable_get(struct spu *spu)
-{
- return in_be64(&spu->priv1->resource_allocation_enable_RW);
-}
-EXPORT_SYMBOL_GPL(spu_resource_allocation_enable_get);
Index: cell--alp--2/arch/powerpc/platforms/cell/spu_priv1_mmio.c
===================================================================
--- cell--alp--2.orig/arch/powerpc/platforms/cell/spu_priv1_mmio.c 2006-04-21 13:04:41.284693750 -0700
+++ cell--alp--2/arch/powerpc/platforms/cell/spu_priv1_mmio.c 2006-05-01 15:16:49.000000000 -0700
@@ -0,0 +1,142 @@
+/*
+ * access to SPU privileged registers
+ */
+#include <linux/module.h>
+
+#include <asm/io.h>
+#include <asm/spu.h>
+
+void spu_int_mask_and(struct spu *spu, int class, u64 mask)
+{
+ u64 old_mask;
+
+ old_mask = in_be64(&spu->priv1->int_mask_RW[class]);
+ out_be64(&spu->priv1->int_mask_RW[class], old_mask & mask);
+}
+EXPORT_SYMBOL_GPL(spu_int_mask_and);
+
+void spu_int_mask_or(struct spu *spu, int class, u64 mask)
+{
+ u64 old_mask;
+
+ old_mask = in_be64(&spu->priv1->int_mask_RW[class]);
+ out_be64(&spu->priv1->int_mask_RW[class], old_mask | mask);
+}
+EXPORT_SYMBOL_GPL(spu_int_mask_or);
+
+void spu_int_mask_set(struct spu *spu, int class, u64 mask)
+{
+ out_be64(&spu->priv1->int_mask_RW[class], mask);
+}
+EXPORT_SYMBOL_GPL(spu_int_mask_set);
+
+u64 spu_int_mask_get(struct spu *spu, int class)
+{
+ return in_be64(&spu->priv1->int_mask_RW[class]);
+}
+EXPORT_SYMBOL_GPL(spu_int_mask_get);
+
+void spu_int_stat_clear(struct spu *spu, int class, u64 stat)
+{
+ out_be64(&spu->priv1->int_stat_RW[class], stat);
+}
+EXPORT_SYMBOL_GPL(spu_int_stat_clear);
+
+u64 spu_int_stat_get(struct spu *spu, int class)
+{
+ return in_be64(&spu->priv1->int_stat_RW[class]);
+}
+EXPORT_SYMBOL_GPL(spu_int_stat_get);
+
+void spu_int_route_set(struct spu *spu, u64 route)
+{
+ out_be64(&spu->priv1->int_route_RW, route);
+}
+EXPORT_SYMBOL_GPL(spu_int_route_set);
+
+u64 spu_mfc_dar_get(struct spu *spu)
+{
+ return in_be64(&spu->priv1->mfc_dar_RW);
+}
+EXPORT_SYMBOL_GPL(spu_mfc_dar_get);
+
+u64 spu_mfc_dsisr_get(struct spu *spu)
+{
+ return in_be64(&spu->priv1->mfc_dsisr_RW);
+}
+EXPORT_SYMBOL_GPL(spu_mfc_dsisr_get);
+
+void spu_mfc_dsisr_set(struct spu *spu, u64 dsisr)
+{
+ out_be64(&spu->priv1->mfc_dsisr_RW, dsisr);
+}
+EXPORT_SYMBOL_GPL(spu_mfc_dsisr_set);
+
+void spu_mfc_sdr_set(struct spu *spu, u64 sdr)
+{
+ out_be64(&spu->priv1->mfc_sdr_RW, sdr);
+}
+EXPORT_SYMBOL_GPL(spu_mfc_sdr_set);
+
+void spu_mfc_sr1_set(struct spu *spu, u64 sr1)
+{
+ out_be64(&spu->priv1->mfc_sr1_RW, sr1);
+}
+EXPORT_SYMBOL_GPL(spu_mfc_sr1_set);
+
+u64 spu_mfc_sr1_get(struct spu *spu)
+{
+ return in_be64(&spu->priv1->mfc_sr1_RW);
+}
+EXPORT_SYMBOL_GPL(spu_mfc_sr1_get);
+
+void spu_mfc_tclass_id_set(struct spu *spu, u64 tclass_id)
+{
+ out_be64(&spu->priv1->mfc_tclass_id_RW, tclass_id);
+}
+EXPORT_SYMBOL_GPL(spu_mfc_tclass_id_set);
+
+u64 spu_mfc_tclass_id_get(struct spu *spu)
+{
+ return in_be64(&spu->priv1->mfc_tclass_id_RW);
+}
+EXPORT_SYMBOL_GPL(spu_mfc_tclass_id_get);
+
+void spu_smm_pgsz_set(struct spu *spu, u64 pgsz)
+{
+ u64 smm_hid;
+ smm_hid = in_be64(&spu->priv1->smm_hid);
+ smm_hid &= ~(0xfull << 60);
+ smm_hid |= pgsz << 60;
+ out_be64(&spu->priv1->smm_hid, smm_hid);
+}
+
+void spu_tlb_invalidate(struct spu *spu)
+{
+ out_be64(&spu->priv1->tlb_invalidate_entry_W, 0ul);
+}
+EXPORT_SYMBOL_GPL(spu_tlb_invalidate);
+
+void spu_resource_allocation_groupID_set(struct spu *spu, u64 id)
+{
+ out_be64(&spu->priv1->resource_allocation_groupID_RW, id);
+}
+EXPORT_SYMBOL_GPL(spu_resource_allocation_groupID_set);
+
+u64 spu_resource_allocation_groupID_get(struct spu *spu)
+{
+ return in_be64(&spu->priv1->resource_allocation_groupID_RW);
+}
+EXPORT_SYMBOL_GPL(spu_resource_allocation_groupID_get);
+
+void spu_resource_allocation_enable_set(struct spu *spu, u64 enable)
+{
+ out_be64(&spu->priv1->resource_allocation_enable_RW, enable);
+}
+EXPORT_SYMBOL_GPL(spu_resource_allocation_enable_set);
+
+u64 spu_resource_allocation_enable_get(struct spu *spu)
+{
+ return in_be64(&spu->priv1->resource_allocation_enable_RW);
+}
+EXPORT_SYMBOL_GPL(spu_resource_allocation_enable_get);
Index: cell--alp--2/drivers/net/Kconfig
===================================================================
--- cell--alp--2.orig/drivers/net/Kconfig 2006-05-01 15:13:22.000000000 -0700
+++ cell--alp--2/drivers/net/Kconfig 2006-05-01 15:13:23.000000000 -0700
@@ -2179,7 +2179,7 @@
config SPIDER_NET
tristate "Spider Gigabit Ethernet driver"
- depends on PCI && PPC_CELL
+ depends on PCI && PPC_IBM_CELL_BLADE
select FW_LOADER
help
This driver supports the Gigabit Ethernet chips present on the
^ permalink raw reply
* Re: DTC/dts modifications
From: Paul Mackerras @ 2006-05-01 22:14 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list, Jon Loeliger
In-Reply-To: <695BB790-1E64-4B53-91DD-7DD88305F201@kernel.crashing.org>
Kumar Gala writes:
> Because of props like:
>
> #cpus = <1>;
> #address-cells = <1>;
> #size-cells = <0>;
>
> If these used some other symbol instead of '#' cpp will be happy and
> we can use it to create macros for us.
I think it will get really really confused if the dts says "$cpus = 1"
but that turns into a "#cpus" property.
There are other macro processors besides cpp, you know - why not look
at m4, for instance?
Paul.
^ permalink raw reply
* Re: DTC/dts modifications
From: Gabriel Paubert @ 2006-05-01 22:00 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, jdl
In-Reply-To: <00CD15B8-F448-4985-8EEC-3BBF61C0110B@kernel.crashing.org>
On Mon, May 01, 2006 at 03:28:34PM -0500, Kumar Gala wrote:
>
> Cool, here's an invocation that seems to work well. Not sure what
> causes linux = 1 (thus I need the -U linux). Also address the line
> information that is normally spit out.
>
> cpp -U linux -P -x assembler-with-cpp foo.dts
Try to add the -undef parameter:
`-undef'
Do not predefine any system-specific or GCC-specific macros. The
standard predefined macros remain defined.
On this machine, the number of lines from:
cpp -dM -x assembler-with-cpp /dev/null
drops from 83 (among which linux, unix, PPC, and powerpc do not start
with underscores) to 5(!) when I add the -undef option. The only ones
left are:
#define __linux__ 1
#define __STDC_HOSTED__ 1
#define __unix__ 1
#define __gnu_linux__ 1
#define __ASSEMBLER__ 1
but at least they all have leading and trailing double underscores.
Regards,
Gabriel
^ permalink raw reply
* Re: DTC/dts modifications
From: Segher Boessenkool @ 2006-05-01 21:26 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, jdl
In-Reply-To: <00CD15B8-F448-4985-8EEC-3BBF61C0110B@kernel.crashing.org>
> Cool, here's an invocation that seems to work well. Not sure what
> causes linux = 1 (thus I need the -U linux). Also address the line
> information that is normally spit out.
>
> cpp -U linux -P -x assembler-with-cpp foo.dts
Try -undef instead. You will *still* have some predefined
symbols, but at least all of those will have plenty of underscores.
It's still a really bad idea to run non-C code through the C
pre-processor; have you considered using m4 or similar instead?
Segher
^ permalink raw reply
* ioremap
From: Srinivas Murthy @ 2006-05-01 21:25 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 431 bytes --]
Hi,
Why does ioremap() not allow normal system RAM to be mapped in using
ioremap().
We have a need to access a portion of the normal system RAM to be mapped in
non-cached.
To simulate, I used kmalloc() to allocate the memory and then passed the
virt_to_phys() of the memory to ioremap() but then noticed that ioremap()
wont allow it.
Is there another way to access this memory non-cached?
Regards,
_Srinivas
[-- Attachment #2: Type: text/html, Size: 616 bytes --]
^ permalink raw reply
* Re: [PATCH] convert powermac ide blink to new led infrastructure
From: Johannes Berg @ 2006-05-01 21:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1146476158.30710.51.camel@localhost.localdomain>
On Mon, 2006-05-01 at 19:35 +1000, Benjamin Herrenschmidt wrote:
> No need to schedule work, it should work fine to re-queue
Untested because I haven't rebooted. Does this look good to you?
I don't see how I could get away without locking, especially with
handling the outstanding requests (though loosing one there might not be
too bad).
johannes
Index: wireless-dev/drivers/ide/Kconfig
===================================================================
--- wireless-dev.orig/drivers/ide/Kconfig 2006-04-30 22:17:49.201535187 +0200
+++ wireless-dev/drivers/ide/Kconfig 2006-04-30 22:17:51.911535187 +0200
@@ -773,13 +773,6 @@ config BLK_DEV_IDEDMA_PMAC
to transfer data to and from memory. Saying Y is safe and improves
performance.
-config BLK_DEV_IDE_PMAC_BLINK
- bool "Blink laptop LED on drive activity"
- depends on BLK_DEV_IDE_PMAC && ADB_PMU
- help
- This option enables the use of the sleep LED as a hard drive
- activity LED.
-
config BLK_DEV_IDE_SWARM
tristate "IDE for Sibyte evaluation boards"
depends on SIBYTE_SB1xxx_SOC
Index: wireless-dev/drivers/ide/ppc/pmac.c
===================================================================
--- wireless-dev.orig/drivers/ide/ppc/pmac.c 2006-04-30 22:17:49.221535187 +0200
+++ wireless-dev/drivers/ide/ppc/pmac.c 2006-04-30 22:17:51.911535187 +0200
@@ -421,107 +421,6 @@ static void pmac_ide_kauai_selectproc(id
#endif /* CONFIG_BLK_DEV_IDEDMA_PMAC */
/*
- * Below is the code for blinking the laptop LED along with hard
- * disk activity.
- */
-
-#ifdef CONFIG_BLK_DEV_IDE_PMAC_BLINK
-
-/* Set to 50ms minimum led-on time (also used to limit frequency
- * of requests sent to the PMU
- */
-#define PMU_HD_BLINK_TIME (HZ/50)
-
-static struct adb_request pmu_blink_on, pmu_blink_off;
-static spinlock_t pmu_blink_lock;
-static unsigned long pmu_blink_stoptime;
-static int pmu_blink_ledstate;
-static struct timer_list pmu_blink_timer;
-static int pmu_ide_blink_enabled;
-
-
-static void
-pmu_hd_blink_timeout(unsigned long data)
-{
- unsigned long flags;
-
- spin_lock_irqsave(&pmu_blink_lock, flags);
-
- /* We may have been triggered again in a racy way, check
- * that we really want to switch it off
- */
- if (time_after(pmu_blink_stoptime, jiffies))
- goto done;
-
- /* Previous req. not complete, try 100ms more */
- if (pmu_blink_off.complete == 0)
- mod_timer(&pmu_blink_timer, jiffies + PMU_HD_BLINK_TIME);
- else if (pmu_blink_ledstate) {
- pmu_request(&pmu_blink_off, NULL, 4, 0xee, 4, 0, 0);
- pmu_blink_ledstate = 0;
- }
-done:
- spin_unlock_irqrestore(&pmu_blink_lock, flags);
-}
-
-static void
-pmu_hd_kick_blink(void *data, int rw)
-{
- unsigned long flags;
-
- pmu_blink_stoptime = jiffies + PMU_HD_BLINK_TIME;
- wmb();
- mod_timer(&pmu_blink_timer, pmu_blink_stoptime);
- /* Fast path when LED is already ON */
- if (pmu_blink_ledstate == 1)
- return;
- spin_lock_irqsave(&pmu_blink_lock, flags);
- if (pmu_blink_on.complete && !pmu_blink_ledstate) {
- pmu_request(&pmu_blink_on, NULL, 4, 0xee, 4, 0, 1);
- pmu_blink_ledstate = 1;
- }
- spin_unlock_irqrestore(&pmu_blink_lock, flags);
-}
-
-static int
-pmu_hd_blink_init(void)
-{
- struct device_node *dt;
- const char *model;
-
- /* Currently, I only enable this feature on KeyLargo based laptops,
- * older laptops may support it (at least heathrow/paddington) but
- * I don't feel like loading those venerable old machines with so
- * much additional interrupt & PMU activity...
- */
- if (pmu_get_model() != PMU_KEYLARGO_BASED)
- return 0;
-
- dt = of_find_node_by_path("/");
- if (dt == NULL)
- return 0;
- model = (const char *)get_property(dt, "model", NULL);
- if (model == NULL)
- return 0;
- if (strncmp(model, "PowerBook", strlen("PowerBook")) != 0 &&
- strncmp(model, "iBook", strlen("iBook")) != 0) {
- of_node_put(dt);
- return 0;
- }
- of_node_put(dt);
-
- pmu_blink_on.complete = 1;
- pmu_blink_off.complete = 1;
- spin_lock_init(&pmu_blink_lock);
- init_timer(&pmu_blink_timer);
- pmu_blink_timer.function = pmu_hd_blink_timeout;
-
- return 1;
-}
-
-#endif /* CONFIG_BLK_DEV_IDE_PMAC_BLINK */
-
-/*
* N.B. this can't be an initfunc, because the media-bay task can
* call ide_[un]register at any time.
*/
@@ -1190,23 +1089,6 @@ pmac_ide_do_suspend(ide_hwif_t *hwif)
pmif->timings[0] = 0;
pmif->timings[1] = 0;
-#ifdef CONFIG_BLK_DEV_IDE_PMAC_BLINK
- /* Note: This code will be called for every hwif, thus we'll
- * try several time to stop the LED blinker timer, but that
- * should be harmless
- */
- if (pmu_ide_blink_enabled) {
- unsigned long flags;
-
- /* Make sure we don't hit the PMU blink */
- spin_lock_irqsave(&pmu_blink_lock, flags);
- if (pmu_blink_ledstate)
- del_timer(&pmu_blink_timer);
- pmu_blink_ledstate = 0;
- spin_unlock_irqrestore(&pmu_blink_lock, flags);
- }
-#endif /* CONFIG_BLK_DEV_IDE_PMAC_BLINK */
-
disable_irq(pmif->irq);
/* The media bay will handle itself just fine */
@@ -1374,13 +1256,6 @@ pmac_ide_setup_device(pmac_ide_hwif_t *p
hwif->selectproc = pmac_ide_selectproc;
hwif->speedproc = pmac_ide_tune_chipset;
-#ifdef CONFIG_BLK_DEV_IDE_PMAC_BLINK
- pmu_ide_blink_enabled = pmu_hd_blink_init();
-
- if (pmu_ide_blink_enabled)
- hwif->led_act = pmu_hd_kick_blink;
-#endif
-
printk(KERN_INFO "ide%d: Found Apple %s controller, bus ID %d%s, irq %d\n",
hwif->index, model_name[pmif->kind], pmif->aapl_bus_id,
pmif->mediabay ? " (mediabay)" : "", hwif->irq);
Index: wireless-dev/drivers/macintosh/Kconfig
===================================================================
--- wireless-dev.orig/drivers/macintosh/Kconfig 2006-04-30 22:17:49.301535187 +0200
+++ wireless-dev/drivers/macintosh/Kconfig 2006-05-01 22:39:34.951534234 +0200
@@ -78,6 +78,17 @@ config ADB_PMU
this device; you should do so if your machine is one of those
mentioned above.
+config ADB_PMU_LED
+ bool "Support for the Power/iBook front LED"
+ depends on ADB_PMU
+ select LEDS_CLASS
+ help
+ Support the front LED on Power/iBooks as a generic LED that can
+ be triggered by any of the supported triggers. To get the
+ behaviour of the old CONFIG_BLK_DEV_IDE_PMAC_BLINK, select this
+ and the ide-disk LED trigger and configure appropriately through
+ sysfs.
+
config PMAC_SMU
bool "Support for SMU based PowerMacs"
depends on PPC_PMAC64
Index: wireless-dev/drivers/macintosh/Makefile
===================================================================
--- wireless-dev.orig/drivers/macintosh/Makefile 2006-04-30 22:17:49.311535187 +0200
+++ wireless-dev/drivers/macintosh/Makefile 2006-05-01 22:36:32.871534234 +0200
@@ -12,6 +12,7 @@ obj-$(CONFIG_INPUT_ADBHID) += adbhid.o
obj-$(CONFIG_ANSLCD) += ans-lcd.o
obj-$(CONFIG_ADB_PMU) += via-pmu.o
+obj-$(CONFIG_ADB_PMU_LED) += via-pmu-led.o
obj-$(CONFIG_ADB_CUDA) += via-cuda.o
obj-$(CONFIG_PMAC_APM_EMU) += apm_emu.o
obj-$(CONFIG_PMAC_SMU) += smu.o
Index: wireless-dev/drivers/macintosh/via-pmu-led.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ wireless-dev/drivers/macintosh/via-pmu-led.c 2006-05-01 23:18:41.001534234 +0200
@@ -0,0 +1,120 @@
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/device.h>
+#include <linux/leds.h>
+#include <linux/adb.h>
+#include <linux/pmu.h>
+#include <asm/prom.h>
+
+static spinlock_t pmu_blink_lock;
+static struct adb_request pmu_blink_req;
+/* -1: no change, 0: request off, 1: request on */
+static int requested_change;
+static int sleeping;
+
+static void pmu_req_done(struct adb_request * req)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&pmu_blink_lock, flags);
+ /* if someone requested a change in the meantime
+ * (we only see the last one which is fine)
+ * then apply it now */
+ if (requested_change != -1 && !sleeping)
+ pmu_request(&pmu_blink_req, NULL, 4, 0xee, 4, 0, requested_change);
+ /* reset requested change */
+ requested_change = -1;
+ spin_unlock_irqrestore(&pmu_blink_lock, flags);
+}
+
+static void pmu_led_set(struct led_classdev *led_cdev,
+ enum led_brightness brightness)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&pmu_blink_lock, flags);
+ switch (brightness) {
+ case LED_OFF:
+ requested_change = 0;
+ break;
+ case LED_FULL:
+ requested_change = 1;
+ break;
+ default:
+ goto out;
+ break;
+ }
+ /* if request isn't done, then don't do anything */
+ if (pmu_blink_req.complete && !sleeping)
+ pmu_request(&pmu_blink_req, NULL, 4, 0xee, 4, 0, requested_change);
+ out:
+ spin_unlock_irqrestore(&pmu_blink_lock, flags);
+}
+
+static struct led_classdev pmu_led = {
+ .name = "pmu-front-led",
+ .brightness_set = pmu_led_set,
+};
+
+#ifdef CONFIG_PM
+static int pmu_led_sleep_call(struct pmu_sleep_notifier *self, int when)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&pmu_blink_lock, flags);
+
+ switch (when) {
+ case PBOOK_SLEEP_REQUEST:
+ sleeping = 1;
+ break;
+ case PBOOK_WAKE:
+ sleeping = 0;
+ break;
+ default:
+ /* do nothing */
+ break;
+ }
+ spin_unlock_irqrestore(&pmu_blink_lock, flags);
+
+ return PBOOK_SLEEP_OK;
+}
+
+static struct pmu_sleep_notifier pmu_led_sleep_notif = {
+ .notifier_call = pmu_led_sleep_call,
+};
+#endif
+
+static __init int pmu_led_init(void)
+{
+ struct device_node *dt;
+ const char *model;
+
+ /* only do this on keylargo based models */
+ if (pmu_get_model() != PMU_KEYLARGO_BASED)
+ return -ENODEV;
+
+ dt = of_find_node_by_path("/");
+ if (dt == NULL)
+ return -ENODEV;
+ model = (const char *)get_property(dt, "model", NULL);
+ if (model == NULL)
+ return -ENODEV;
+ if (strncmp(model, "PowerBook", strlen("PowerBook")) != 0 &&
+ strncmp(model, "iBook", strlen("iBook")) != 0) {
+ of_node_put(dt);
+ /* silently ignore */
+ return 0;
+ }
+ of_node_put(dt);
+
+ spin_lock_init(&pmu_blink_lock);
+ /* no outstanding req */
+ pmu_blink_req.complete = 1;
+ pmu_blink_req.done = pmu_req_done;
+#ifdef CONFIG_PM
+ pmu_register_sleep_notifier(&pmu_led_sleep_notif);
+#endif
+ return led_classdev_register(NULL, &pmu_led);
+}
+
+late_initcall(pmu_led_init);
^ permalink raw reply
* Re: DTC/dts modifications
From: Kumar Gala @ 2006-05-01 20:28 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev, jdl
In-Reply-To: <20060501150728.04694488.kim.phillips@freescale.com>
On May 1, 2006, at 3:07 PM, Kim Phillips wrote:
> On Mon, 1 May 2006 14:52:23 -0500
> Kumar Gala <galak@kernel.crashing.org> wrote:
>
>> [snip]
>>
>>>> Try running a current .dts through cpp today. You will get errors
>>>> like:
>>>>
>>>> oftree.dts:15:3: error: invalid preprocessing directive #address
>>>
>>>> Because of props like:
>>>>
>>>> #cpus = <1>;
>>>> #address-cells = <1>;
>>>> #size-cells = <0>;
>>>>
>>>> If these used some other symbol instead of '#' cpp will be happy
>>>> and
>>>> we can use it to create macros for us.
>>>
>>> Yeah, we're not going to be able to change those; they
>>> are "By The Book".
>>
>> By what book? It would seem to me that BNF for dtc is completely
>> under our control and if we want to change it we can. I understand
>> that there is some correspondence to Open Firmware, but it seems that
>> if its people are ok with the dts format changing that's a lot easier
>> than implementing tons of support in dtc for features that cpp
>> gives us.
>>
>> [I'm also guessing no one's really got time to go and implement these
>> features in dtc]
>>
> cpp -x assembler-with-cpp seems to not produce the above errors,
> and still honours preprocessing directives like #define. Don't
> know what else is messes with, and whether you want to add CPPFLAGS.
Cool, here's an invocation that seems to work well. Not sure what
causes linux = 1 (thus I need the -U linux). Also address the line
information that is normally spit out.
cpp -U linux -P -x assembler-with-cpp foo.dts
With a 8349 dts I'm using I'm able to run it through cpp then dts and
get the exact same dtb.
- kumar
^ permalink raw reply
* Re: DTC/dts modifications
From: Kim Phillips @ 2006-05-01 20:07 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, jdl
In-Reply-To: <55FD11DB-54AF-4284-9E9A-C313F4232105@kernel.crashing.org>
On Mon, 1 May 2006 14:52:23 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
> [snip]
>
> >> Try running a current .dts through cpp today. You will get errors
> >> like:
> >>
> >> oftree.dts:15:3: error: invalid preprocessing directive #address
> >
> >> Because of props like:
> >>
> >> #cpus = <1>;
> >> #address-cells = <1>;
> >> #size-cells = <0>;
> >>
> >> If these used some other symbol instead of '#' cpp will be happy and
> >> we can use it to create macros for us.
> >
> > Yeah, we're not going to be able to change those; they
> > are "By The Book".
>
> By what book? It would seem to me that BNF for dtc is completely
> under our control and if we want to change it we can. I understand
> that there is some correspondence to Open Firmware, but it seems that
> if its people are ok with the dts format changing that's a lot easier
> than implementing tons of support in dtc for features that cpp gives us.
>
> [I'm also guessing no one's really got time to go and implement these
> features in dtc]
>
cpp -x assembler-with-cpp seems to not produce the above errors, and still honours preprocessing directives like #define. Don't know what else is messes with, and whether you want to add CPPFLAGS.
Kim
> > Instead, we'll have to make the lexical analysis conscious
> > of something like a <newline> context sensitive token or so.
> > Or throw some flag to cpp to not emit location markers.
>
> - kumar
^ permalink raw reply
* Re: DTC/dts modifications
From: Kumar Gala @ 2006-05-01 19:52 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Jon Loeliger, linuxppc-dev@ozlabs.org list
In-Reply-To: <1146512732.24239.34.camel@cashmere.sps.mot.com>
[snip]
>> Try running a current .dts through cpp today. You will get errors
>> like:
>>
>> oftree.dts:15:3: error: invalid preprocessing directive #address
>
>> Because of props like:
>>
>> #cpus = <1>;
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> If these used some other symbol instead of '#' cpp will be happy and
>> we can use it to create macros for us.
>
> Yeah, we're not going to be able to change those; they
> are "By The Book".
By what book? It would seem to me that BNF for dtc is completely
under our control and if we want to change it we can. I understand
that there is some correspondence to Open Firmware, but it seems that
if its people are ok with the dts format changing that's a lot easier
than implementing tons of support in dtc for features that cpp gives us.
[I'm also guessing no one's really got time to go and implement these
features in dtc]
> Instead, we'll have to make the lexical analysis conscious
> of something like a <newline> context sensitive token or so.
> Or throw some flag to cpp to not emit location markers.
- kumar
^ permalink raw reply
* Re: DTC/dts modifications
From: Jon Loeliger @ 2006-05-01 19:45 UTC (permalink / raw)
To: Kumar Gala; +Cc: Jon Loeliger, linuxppc-dev@ozlabs.org list
In-Reply-To: <695BB790-1E64-4B53-91DD-7DD88305F201@kernel.crashing.org>
On Mon, 2006-05-01 at 14:39, Kumar Gala wrote:
>
> Comment aren't the issue.
Ah, ok.
> > I think to get CPP to be usable, it will need to handle
> > the # emitted line-location markers, "# <line> <file> <level>".
>
> Don't follow you here.
The pre-processor emits crap like this:
# 1 "cmd_load.c"
# 1 "/proj/ppc/sysperf/sw/u/jdl/86xx/u-boot-86xx/common//"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "cmd_load.c"
# 27 "cmd_load.c"
# 1 "/proj/ppc/sysperf/sw/u/jdl/86xx/u-boot-86xx/include/common.h" 1
# 30 "/proj/ppc/sysperf/sw/u/jdl/86xx/u-boot-86xx/include/common.h"
typedef unsigned char uchar;
typedef volatile unsigned long vu_long;
typedef volatile unsigned short vu_short;
typedef volatile unsigned char vu_char;
> Try running a current .dts through cpp today. You will get errors like:
>
> oftree.dts:15:3: error: invalid preprocessing directive #address
> Because of props like:
>
> #cpus = <1>;
> #address-cells = <1>;
> #size-cells = <0>;
>
> If these used some other symbol instead of '#' cpp will be happy and
> we can use it to create macros for us.
Yeah, we're not going to be able to change those; they
are "By The Book".
Instead, we'll have to make the lexical analysis conscious
of something like a <newline> context sensitive token or so.
Or throw some flag to cpp to not emit location markers.
Or something.
jdl
^ permalink raw reply
* Re: DTC/dts modifications
From: Kumar Gala @ 2006-05-01 19:39 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Jon Loeliger, linuxppc-dev@ozlabs.org list
In-Reply-To: <1146512012.24239.28.camel@cashmere.sps.mot.com>
On May 1, 2006, at 2:33 PM, Jon Loeliger wrote:
> On Sat, 2006-04-29 at 11:00, Kumar Gala wrote:
>> All,
>>
>> What evilness would it be to change the use of '#' in the .dts format
>> to some other character like '$' or '%'.
>
> Uh, use of '#' for what? Current comment style is
> either C or C++, ie, /* ... */ or //.
Comment aren't the issue.
>> The problem is the use of
>> '#' prevents use from using cpp which would make some aspects of
>> building up .dts for boards far more useful.
>
> I think to get CPP to be usable, it will need to handle
> the # emitted line-location markers, "# <line> <file> <level>".
Don't follow you here.
>> We can easily provide a one line script to convert people's .dts to
>> the new format.
>
> I don't think there is a conversion necessary yet.
> Did I miss something here?
Try running a current .dts through cpp today. You will get errors like:
oftree.dts:15:3: error: invalid preprocessing directive #address
oftree.dts:16:3: error: invalid preprocessing directive #size
oftree.dts:20:4: error: invalid preprocessing directive #cpus
oftree.dts:21:4: error: invalid preprocessing directive #address
oftree.dts:22:4: error: invalid preprocessing directive #size
oftree.dts:25:2: error: invalid preprocessing directive #foobar
Because of props like:
#cpus = <1>;
#address-cells = <1>;
#size-cells = <0>;
If these used some other symbol instead of '#' cpp will be happy and
we can use it to create macros for us.
- k
^ permalink raw reply
* Re: DTC/dts modifications
From: Jon Loeliger @ 2006-05-01 19:33 UTC (permalink / raw)
To: Kumar Gala; +Cc: Jon Loeliger, linuxppc-dev@ozlabs.org list
In-Reply-To: <5CA113BC-1614-4551-87E5-6926E14C2225@kernel.crashing.org>
On Sat, 2006-04-29 at 11:00, Kumar Gala wrote:
> All,
>
> What evilness would it be to change the use of '#' in the .dts format
> to some other character like '$' or '%'.
Uh, use of '#' for what? Current comment style is
either C or C++, ie, /* ... */ or //.
> The problem is the use of
> '#' prevents use from using cpp which would make some aspects of
> building up .dts for boards far more useful.
I think to get CPP to be usable, it will need to handle
the # emitted line-location markers, "# <line> <file> <level>".
> We can easily provide a one line script to convert people's .dts to
> the new format.
I don't think there is a conversion necessary yet.
Did I miss something here?
Thanks,
jdl
^ permalink raw reply
* Re: 2.6.17-rc2-mm1
From: Andi Kleen @ 2006-05-01 18:34 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: Andrew Morton, linuxppc64-dev, linux-kernel
In-Reply-To: <44561A1E.7000103@google.com>
On Monday 01 May 2006 16:24, Martin J. Bligh wrote:
> double fault: 0000 [1] SMP
> last sysfs file: /devices/pci0000:00/0000:00:06.0/resource
> CPU 0
> Modules linked in:
> Pid: 20519, comm: mtest01 Not tainted 2.6.17-rc3-mm1-autokern1 #1
> RIP: 0010:[<ffffffff8047c8b8>] <ffffffff8047c8b8>{__sched_text_start+1856}
> RSP: 0000:0000000000000000 EFLAGS: 00010082
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff805d9438
> RDX: ffff8100db12c0d0 RSI: ffffffff805d9438 RDI: ffff8100db12c0d0
> RBP: ffffffff805d9438 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> R13: ffff8100e39bd440 R14: ffff810008003620 R15: 000002b02751726c
> FS: 0000000000000000(0000) GS:ffffffff805fa000(0063) knlGS:00000000f7dd0460
> CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
> CR2: fffffffffffffff8 CR3: 00000000da399000 CR4: 00000000000006e0
> Process mtest01 (pid: 20519, threadinfo ffff8100b1bb4000, task
> ffff8100db12c0d0)
> Stack: ffffffff80579e20 ffff8100db12c0d0 0000000000000001 ffffffff80579f58
> 0000000000000000 ffffffff80579e78 ffffffff8020b0b2 ffffffff80579f58
> 0000000000000000 ffffffff80485520
> Call Trace: <#DF> <ffffffff8020b0b2>{show_registers+140}
> <ffffffff8020b357>{__die+159} <ffffffff8020b3cc>{die+50}
> <ffffffff8020bba6>{do_double_fault+115}
> <ffffffff8020aa91>{double_fault+125}
> <ffffffff8047c8b8>{__sched_text_start+1856} <EOE>
That's really strange - i wonder why the backtracer can't find the original
stack. Should probably add some printk diagnosis here.
Can you send the output with this patch?
Index: linux/arch/x86_64/kernel/traps.c
===================================================================
--- linux.orig/arch/x86_64/kernel/traps.c
+++ linux/arch/x86_64/kernel/traps.c
@@ -238,6 +238,7 @@ void show_trace(unsigned long *stack)
HANDLE_STACK (stack < estack_end);
i += printk(" <EOE>");
stack = (unsigned long *) estack_end[-2];
+ printk("new stack %lx (%lx %lx %lx %lx %lx)\n", stack, estack_end[0], estack_end[-1], estack_end[-2], estack_end[-3], estack_end[-4]);
continue;
}
if (irqstack_end) {
^ permalink raw reply
* Re: 2.6.17-rc2-mm1
From: Andy Whitcroft @ 2006-05-01 18:32 UTC (permalink / raw)
To: Martin Bligh; +Cc: Andrew Morton, linuxppc64-dev, Badari Pulavarty, lkml, ak
In-Reply-To: <44564BEC.1040803@google.com>
Martin Bligh wrote:
> Badari Pulavarty wrote:
>
>> On Mon, 2006-05-01 at 10:26 -0700, Martin Bligh wrote:
>>
>>>> I ran mtest01 multiple times with various options on my 4-way AMD64
>>>> box.
>>>> So far couldn't reproduce the problem (2.6.17-rc3-mm1).
>>>>
>>>> Are there any special config or test options you are testing with ?
>>>
>>>
>>> Config is here:
>>>
>>> http://ftp.kernel.org/pub/linux/kernel/people/mbligh/config/abat/amd64
>>>
>>> It's just doing "runalltests", I think.
>>
>>
>>
>> FWIW, I tried your config file on my 4-way AMD64 (melody) box and ran
>> latest "mtest01" fine.
>>
>> I am now trying runalltests. I guess, its time to bi-sect :(
>
>
> There was a panic on PPC64 during LTP too, but it seems to have gone
> away with rc3-mm1. Not sure if it was really fixed, or just intermittent.
>
> http://test.kernel.org/abat/29675/debug/console.log
I think its more intermittant than gone. I've got another machine which
runs the same tests, and she threw a very similar failure on 2.6.18-rc3-mm1.
-apw
^ permalink raw reply
* Re: 2.6.17-rc2-mm1
From: Martin Bligh @ 2006-05-01 17:57 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: Andrew Morton, linuxppc64-dev, ak, lkml
In-Reply-To: <1146506105.317.4.camel@dyn9047017100.beaverton.ibm.com>
Badari Pulavarty wrote:
> On Mon, 2006-05-01 at 10:26 -0700, Martin Bligh wrote:
>
>>>I ran mtest01 multiple times with various options on my 4-way AMD64 box.
>>>So far couldn't reproduce the problem (2.6.17-rc3-mm1).
>>>
>>>Are there any special config or test options you are testing with ?
>>
>>Config is here:
>>
>>http://ftp.kernel.org/pub/linux/kernel/people/mbligh/config/abat/amd64
>>
>>It's just doing "runalltests", I think.
>
>
> FWIW, I tried your config file on my 4-way AMD64 (melody) box
> and ran latest "mtest01" fine.
>
> I am now trying runalltests. I guess, its time to bi-sect :(
There was a panic on PPC64 during LTP too, but it seems to have gone
away with rc3-mm1. Not sure if it was really fixed, or just intermittent.
http://test.kernel.org/abat/29675/debug/console.log
M.
^ permalink raw reply
* Re: 2.6.17-rc2-mm1
From: Badari Pulavarty @ 2006-05-01 17:55 UTC (permalink / raw)
To: Martin Bligh; +Cc: Andrew Morton, linuxppc64-dev, ak, lkml
In-Reply-To: <445644B7.7060807@google.com>
On Mon, 2006-05-01 at 10:26 -0700, Martin Bligh wrote:
> > I ran mtest01 multiple times with various options on my 4-way AMD64 box.
> > So far couldn't reproduce the problem (2.6.17-rc3-mm1).
> >
> > Are there any special config or test options you are testing with ?
>
> Config is here:
>
> http://ftp.kernel.org/pub/linux/kernel/people/mbligh/config/abat/amd64
>
> It's just doing "runalltests", I think.
FWIW, I tried your config file on my 4-way AMD64 (melody) box
and ran latest "mtest01" fine.
I am now trying runalltests. I guess, its time to bi-sect :(
Thanks,
Badari
^ permalink raw reply
* Re: [PATCH] powerpc: Export flat device tree via debugfs for debugging
From: Kumar Gala @ 2006-05-01 17:54 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060501074044.D552967B55@ozlabs.org>
On May 1, 2006, at 2:40 AM, Michael Ellerman wrote:
> If DEBUG is turned on in prom.c, export the flat device tree via
> debugfs.
> This has been handy on several occasions.
>
> To look at it:
> # mount -t debugfs none /sys/kernel/debug
> # od -a /sys/kernel/debug/powerpc/flat-device-tree
> and/or
> # dtc -fI dtb /sys/kernel/debug/powerpc/flat-device-tree -O dts
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> ---
>
> arch/powerpc/kernel/prom.c | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
>
> Index: to-merge/arch/powerpc/kernel/prom.c
> ===================================================================
> --- to-merge.orig/arch/powerpc/kernel/prom.c
> +++ to-merge/arch/powerpc/kernel/prom.c
> @@ -30,6 +30,7 @@
> #include <linux/bitops.h>
> #include <linux/module.h>
> #include <linux/kexec.h>
> +#include <linux/debugfs.h>
>
> #include <asm/prom.h>
> #include <asm/rtas.h>
> @@ -2009,3 +2010,27 @@ void kdump_move_device_tree(void)
> /* XXX should we unreserve the old DT? */
> }
> #endif /* CONFIG_KEXEC */
> +
> +#ifdef DEBUG
Shouldn't this also depend on DEBUGFS being built in.
> +static struct debugfs_blob_wrapper flat_dt_blob;
> +
> +static int __init export_flat_device_tree(void)
> +{
> + struct dentry *d;
> +
> + d = debugfs_create_dir("powerpc", NULL);
> + if (!d)
> + return 1;
> +
> + flat_dt_blob.data = initial_boot_params;
> + flat_dt_blob.size = initial_boot_params->totalsize;
> +
> + d = debugfs_create_blob("flat-device-tree", S_IFREG | S_IRUSR,
> + d, &flat_dt_blob);
> + if (!d)
> + return 1;
> +
> + return 0;
> +}
> +__initcall(export_flat_device_tree);
> +#endif
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Large Page Support, 2.6 kernel , PPC440
From: moris dong @ 2006-05-01 17:35 UTC (permalink / raw)
To: linuxppc-embedded
Friends,
My PPC440 (32bit) MMU supports multiple page sizes.
For the default 4K pages, my 2.6.11 kernel compiles and boots just fine.
I want to re-build it with large pages, to improve my application
performance.
I tried modifying PAGE_SHIFT in "page.h" to 13 (8K pages) and re-build my
kernel.
Compilation worked out fine, but my kernel does NOT boot, nor it prints
anything to the console.
Has anyone successfully compiled & booted a 2.6 kernel with pages larger
than 4K ?
What am I doing wrong ?
Thanks a lot.
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
^ permalink raw reply
* Large Page Support, 2.6 kernel , PPC440
From: moris dong @ 2006-05-01 17:34 UTC (permalink / raw)
To: linuxppc-dev
Friends,
My PPC440 (32bit) MMU supports multiple page sizes.
For the default 4K pages, my 2.6.11 kernel compiles and boots just fine.
I want to re-build it with large pages, to improve my application
performance.
I tried modifying PAGE_SHIFT in "page.h" to 13 (8K pages) and re-build my
kernel.
Compilation worked out fine, but my kernel does NOT boot, nor it prints
anything to the console.
Has anyone successfully compiled & booted a 2.6 kernel with pages larger
than 4K ?
What am I doing wrong ?
Thanks a lot.
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
^ permalink raw reply
* Re: 2.6.17-rc2-mm1
From: Martin Bligh @ 2006-05-01 17:26 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: Andrew Morton, linuxppc64-dev, ak, lkml
In-Reply-To: <1146503960.317.1.camel@dyn9047017100.beaverton.ibm.com>
> I ran mtest01 multiple times with various options on my 4-way AMD64 box.
> So far couldn't reproduce the problem (2.6.17-rc3-mm1).
>
> Are there any special config or test options you are testing with ?
Config is here:
http://ftp.kernel.org/pub/linux/kernel/people/mbligh/config/abat/amd64
It's just doing "runalltests", I think.
M.
^ permalink raw reply
* Re: 2.6.17-rc2-mm1
From: Badari Pulavarty @ 2006-05-01 17:19 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc64-dev, ak, lkml, Martin J. Bligh
In-Reply-To: <20060501100731.051f4eff.akpm@osdl.org>
On Mon, 2006-05-01 at 10:07 -0700, Andrew Morton wrote:
> "Martin J. Bligh" <mbligh@google.com> wrote:
> >
> > Andrew Morton wrote:
> > > (I did s/linux-kernel@google.com/linux-kernel@vger.kernel.org/)
> > >
> > > Martin Bligh <mbligh@google.com> wrote:
> > >
> > >>Still crashes in LTP on x86_64:
> > >>(introduced in previous release)
> > >>
> > >>http://test.kernel.org/abat/29674/debug/console.log
> > >
> > >
> > > What a mess. A doublefault inside an NMI watchdog timeout. I think. It's
> > > hard to see. Some CPUs are stuck on a CPU scheduler lock, others seem to
> > > be stuck in flush_tlb_others. One of these could be a consequence of the
> > > other, or both could be a consequence of something else.
> >
> > OK, well the latest one seems cleaner, on -rc3-mm1.
> > http://test.kernel.org/abat/30007/debug/console.log
> >
> > Just has the double fault, with no NMI watchdog timeouts. Not that
> > it means any more to me, but still ;-) mtest01 seems to be able to
> > reproduce this every time, but I don't have an appropriate box here
> > to diagnose it with (this was a 4x Opteron inside IBM), and it's
> > definitely something in -mm that's not in mainline.
> >
> > M.
> >
> > double fault: 0000 [1] SMP
> > last sysfs file: /devices/pci0000:00/0000:00:06.0/resource
> > CPU 0
> > Modules linked in:
> > Pid: 20519, comm: mtest01 Not tainted 2.6.17-rc3-mm1-autokern1 #1
> > RIP: 0010:[<ffffffff8047c8b8>] <ffffffff8047c8b8>{__sched_text_start+1856}
> > RSP: 0000:0000000000000000 EFLAGS: 00010082
> > RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff805d9438
> > RDX: ffff8100db12c0d0 RSI: ffffffff805d9438 RDI: ffff8100db12c0d0
> > RBP: ffffffff805d9438 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> > R13: ffff8100e39bd440 R14: ffff810008003620 R15: 000002b02751726c
> > FS: 0000000000000000(0000) GS:ffffffff805fa000(0063) knlGS:00000000f7dd0460
> > CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
> > CR2: fffffffffffffff8 CR3: 00000000da399000 CR4: 00000000000006e0
> > Process mtest01 (pid: 20519, threadinfo ffff8100b1bb4000, task
> > ffff8100db12c0d0)
> > Stack: ffffffff80579e20 ffff8100db12c0d0 0000000000000001 ffffffff80579f58
> > 0000000000000000 ffffffff80579e78 ffffffff8020b0b2 ffffffff80579f58
> > 0000000000000000 ffffffff80485520
> > Call Trace: <#DF> <ffffffff8020b0b2>{show_registers+140}
> > <ffffffff8020b357>{__die+159} <ffffffff8020b3cc>{die+50}
> > <ffffffff8020bba6>{do_double_fault+115}
> > <ffffffff8020aa91>{double_fault+125}
> > <ffffffff8047c8b8>{__sched_text_start+1856} <EOE>
> >
> > Code: e8 4c ba d8 ff 65 48 8b 34 25 00 00 00 00 4c 8b 46 08 f0 41
> > RIP <ffffffff8047c8b8>{__sched_text_start+1856} RSP <0000000000000000>
> > -- 0:conmux-control -- time-stamp -- May/01/06 3:54:37 --
>
> I was not able to reproduce this on the 4-way EMT64 machine. Am a bit stuck.
I ran mtest01 multiple times with various options on my 4-way AMD64 box.
So far couldn't reproduce the problem (2.6.17-rc3-mm1).
Are there any special config or test options you are testing with ?
Thanks,
Badari
^ permalink raw reply
* Re: 2.6.17-rc2-mm1
From: Martin Bligh @ 2006-05-01 17:14 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc64-dev, ak, linux-kernel
In-Reply-To: <20060501100731.051f4eff.akpm@osdl.org>
>>double fault: 0000 [1] SMP
>>last sysfs file: /devices/pci0000:00/0000:00:06.0/resource
>>CPU 0
>>Modules linked in:
>>Pid: 20519, comm: mtest01 Not tainted 2.6.17-rc3-mm1-autokern1 #1
>>RIP: 0010:[<ffffffff8047c8b8>] <ffffffff8047c8b8>{__sched_text_start+1856}
>>RSP: 0000:0000000000000000 EFLAGS: 00010082
>>RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff805d9438
>>RDX: ffff8100db12c0d0 RSI: ffffffff805d9438 RDI: ffff8100db12c0d0
>>RBP: ffffffff805d9438 R08: 0000000000000000 R09: 0000000000000000
>>R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
>>R13: ffff8100e39bd440 R14: ffff810008003620 R15: 000002b02751726c
>>FS: 0000000000000000(0000) GS:ffffffff805fa000(0063) knlGS:00000000f7dd0460
>>CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
>>CR2: fffffffffffffff8 CR3: 00000000da399000 CR4: 00000000000006e0
>>Process mtest01 (pid: 20519, threadinfo ffff8100b1bb4000, task
>>ffff8100db12c0d0)
>>Stack: ffffffff80579e20 ffff8100db12c0d0 0000000000000001 ffffffff80579f58
>> 0000000000000000 ffffffff80579e78 ffffffff8020b0b2 ffffffff80579f58
>> 0000000000000000 ffffffff80485520
>>Call Trace: <#DF> <ffffffff8020b0b2>{show_registers+140}
>> <ffffffff8020b357>{__die+159} <ffffffff8020b3cc>{die+50}
>> <ffffffff8020bba6>{do_double_fault+115}
>><ffffffff8020aa91>{double_fault+125}
>> <ffffffff8047c8b8>{__sched_text_start+1856} <EOE>
>>
>>Code: e8 4c ba d8 ff 65 48 8b 34 25 00 00 00 00 4c 8b 46 08 f0 41
>>RIP <ffffffff8047c8b8>{__sched_text_start+1856} RSP <0000000000000000>
>> -- 0:conmux-control -- time-stamp -- May/01/06 3:54:37 --
>
>
> I was not able to reproduce this on the 4-way EMT64 machine. Am a bit stuck.
OK, is there anything we could run this with that'd dump more info?
(eg debug patches or something). There's bugger all of use that I
can see in that stack (and why does __sched_text_start come up anyway,
is that an x86_64-ism ?). I suppose if we're really desperate, we can
play chop search, but that's very boring to try to do remotely ...
It's a couple-of-year-old 4x newisys box.
M.
^ permalink raw reply
* Re: [openib-general] Re: [PATCH 00/16] ehca: IBM eHCA InfiniBand Device Driver
From: Roland Dreier @ 2006-05-01 17:03 UTC (permalink / raw)
To: Heiko Joerg Schick; +Cc: linuxppc-dev, linux-kernel, openib-general
In-Reply-To: <e2r7a0$fo2$1@sea.gmane.org>
Heiko> I don't like the idea to put the whole driver in one patch
Heiko> file. I would propose to put the patch "ehca: integration
Heiko> in Linux kernel" last instead of first, as Arnd
Heiko> mentioned. With that change we leave the kernel in a
Heiko> working state when applying the patches.
Yes, that makes sense.
And I can fold the patches into a single git changeset when we finally
merge it, since I don't see any advantage to having the driver split
into pieces. (No one is going to git biset a half-applied driver or
anything like that)
- R.
^ permalink raw reply
* Re: 2.6.17-rc2-mm1
From: Andrew Morton @ 2006-05-01 17:07 UTC (permalink / raw)
To: Martin J. Bligh; +Cc: linuxppc64-dev, ak, linux-kernel
In-Reply-To: <44561A1E.7000103@google.com>
"Martin J. Bligh" <mbligh@google.com> wrote:
>
> Andrew Morton wrote:
> > (I did s/linux-kernel@google.com/linux-kernel@vger.kernel.org/)
> >
> > Martin Bligh <mbligh@google.com> wrote:
> >
> >>Still crashes in LTP on x86_64:
> >>(introduced in previous release)
> >>
> >>http://test.kernel.org/abat/29674/debug/console.log
> >
> >
> > What a mess. A doublefault inside an NMI watchdog timeout. I think. It's
> > hard to see. Some CPUs are stuck on a CPU scheduler lock, others seem to
> > be stuck in flush_tlb_others. One of these could be a consequence of the
> > other, or both could be a consequence of something else.
>
> OK, well the latest one seems cleaner, on -rc3-mm1.
> http://test.kernel.org/abat/30007/debug/console.log
>
> Just has the double fault, with no NMI watchdog timeouts. Not that
> it means any more to me, but still ;-) mtest01 seems to be able to
> reproduce this every time, but I don't have an appropriate box here
> to diagnose it with (this was a 4x Opteron inside IBM), and it's
> definitely something in -mm that's not in mainline.
>
> M.
>
> double fault: 0000 [1] SMP
> last sysfs file: /devices/pci0000:00/0000:00:06.0/resource
> CPU 0
> Modules linked in:
> Pid: 20519, comm: mtest01 Not tainted 2.6.17-rc3-mm1-autokern1 #1
> RIP: 0010:[<ffffffff8047c8b8>] <ffffffff8047c8b8>{__sched_text_start+1856}
> RSP: 0000:0000000000000000 EFLAGS: 00010082
> RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff805d9438
> RDX: ffff8100db12c0d0 RSI: ffffffff805d9438 RDI: ffff8100db12c0d0
> RBP: ffffffff805d9438 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> R13: ffff8100e39bd440 R14: ffff810008003620 R15: 000002b02751726c
> FS: 0000000000000000(0000) GS:ffffffff805fa000(0063) knlGS:00000000f7dd0460
> CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
> CR2: fffffffffffffff8 CR3: 00000000da399000 CR4: 00000000000006e0
> Process mtest01 (pid: 20519, threadinfo ffff8100b1bb4000, task
> ffff8100db12c0d0)
> Stack: ffffffff80579e20 ffff8100db12c0d0 0000000000000001 ffffffff80579f58
> 0000000000000000 ffffffff80579e78 ffffffff8020b0b2 ffffffff80579f58
> 0000000000000000 ffffffff80485520
> Call Trace: <#DF> <ffffffff8020b0b2>{show_registers+140}
> <ffffffff8020b357>{__die+159} <ffffffff8020b3cc>{die+50}
> <ffffffff8020bba6>{do_double_fault+115}
> <ffffffff8020aa91>{double_fault+125}
> <ffffffff8047c8b8>{__sched_text_start+1856} <EOE>
>
> Code: e8 4c ba d8 ff 65 48 8b 34 25 00 00 00 00 4c 8b 46 08 f0 41
> RIP <ffffffff8047c8b8>{__sched_text_start+1856} RSP <0000000000000000>
> -- 0:conmux-control -- time-stamp -- May/01/06 3:54:37 --
I was not able to reproduce this on the 4-way EMT64 machine. Am a bit stuck.
^ 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