* Re: [PATCH] powerpc: Remove remaining iSeries debugger cruft
From: Michael Ellerman @ 2006-05-02 4:52 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <20060502040557.DE09667C13@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 559 bytes --]
On Tue, 2006-05-02 at 14:05 +1000, Michael Ellerman wrote:
> This isn't needed anymore, as no one is using this debugger. Doesn't have
> any effect on early debug output etc.
>
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
> ---
This is bogus, it moves the embedded_sysmap variables, new patch coming.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: question about Linux 2.6 with Xilinx ML-403
From: Grant Likely @ 2006-05-02 4:09 UTC (permalink / raw)
To: yding; +Cc: linuxppc-embedded list
In-Reply-To: <445696A9.5070200@lnxw.com>
On 5/1/06, yding <yding@lnxw.com> wrote:
> HI, Grant,
>
> It looks like that the patch for ML-403 in Linux 2.6.17 kernel(I downloa=
ded
> from Linus git tree) does not have the directory :
> ./arch/ppc/platform/4xx/xilinx_ocp like the one in the
> 2.4.30 kernel.
That's right. AFAIK, The 2.6 kernel is not yet supported by the
Xilinx EDK tools; and so it cannot generate a 2.6 BSP. If you want to
use the generated BSP; use the montavista 2.4 kernel.
> And also, I saw this thread: "Migrate Xilinx Vertex support from the OCP
> bus to the platfom bus"
>
> http://patchwork.ozlabs.org/linuxppc/patch?id=3D3933
> Does it mean all of onchip peripherals for Virtex-4 FX must reside on th=
e
> PLB bus instead of OPB (OCB) bus ?
No. Platform bus is a Linux construct to make it simpler to handle
"directly attached" devices. ie. Anything that the processor can
access directly w/o PCI et all. OPB and PLB devices are both
'platform' devices in Linux 2.6 terminology.
> (i.e. during the process of creating the ref design for Linux using Xili=
nx
> Platform studio, I have to select PLB peripherals instead of OPB
> peripherals. Is is correct ?)
No, use whatever peripherals you want (either PLB, or OPB). Just be
prepared to port device drivers for anything beyond a serial port.
>
> BTW, do you have a sample ref design for ML-403 board for Xilinx Platfor=
m
> studio ?
Why not use the ref design that Xilinx provides? (I have a number of
designs that work; but most of the time I use the ML403 ref design
because I know it's proven)
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 399-0195
^ permalink raw reply
* [PATCH] powerpc: Remove remaining iSeries debugger cruft
From: Michael Ellerman @ 2006-05-02 4:05 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <1145386937.20493.33.camel@localhost.localdomain>
This isn't needed anymore, as no one is using this debugger. Doesn't have
any effect on early debug output etc.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/head_64.S | 9 ---------
1 file changed, 9 deletions(-)
Index: to-merge/arch/powerpc/kernel/head_64.S
===================================================================
--- to-merge.orig/arch/powerpc/kernel/head_64.S
+++ to-merge/arch/powerpc/kernel/head_64.S
@@ -93,15 +93,6 @@ END_FTR_SECTION(0, 1)
. = 0x20
.llong hvReleaseData-KERNELBASE
- /*
- * At offset 0x28 and 0x30 are offsets to the mschunks_map
- * array (used by the iSeries LPAR debugger to do translation
- * between physical addresses and absolute addresses) and
- * to the pidhash table (also used by the debugger)
- */
- .llong mschunks_map-KERNELBASE
- .llong 0 /* pidhash-KERNELBASE SFRXXX */
-
/* Offset 0x38 - Pointer to start of embedded System.map */
.globl embedded_sysmap_start
embedded_sysmap_start:
^ permalink raw reply
* Re: alignment exceptionhandler sleeps in invalid context
From: Paul Mackerras @ 2006-05-02 4:00 UTC (permalink / raw)
To: Olaf Hering, linuxppc-dev
In-Reply-To: <17489.63055.968862.256370@cargo.ozlabs.ibm.com>
I wrote:
> This patch should fix it, I hope. If you can verify that it fixes it
> I'll send it to Linus.
but init barfs at startup with that patch, due to the double
evaluation of `ptr'. This one runs a bit better...
Paul.
diff --git a/include/asm-powerpc/uaccess.h b/include/asm-powerpc/uaccess.h
index 3872e92..d83fc29 100644
--- a/include/asm-powerpc/uaccess.h
+++ b/include/asm-powerpc/uaccess.h
@@ -7,6 +7,7 @@ #ifndef __ASSEMBLY__
#include <linux/sched.h>
#include <linux/errno.h>
#include <asm/processor.h>
+#include <asm/page.h>
#define VERIFY_READ 0
#define VERIFY_WRITE 1
@@ -179,9 +180,11 @@ do { \
#define __put_user_nocheck(x, ptr, size) \
({ \
long __pu_err; \
- might_sleep(); \
- __chk_user_ptr(ptr); \
- __put_user_size((x), (ptr), (size), __pu_err); \
+ __typeof__(*(ptr)) __user *__pu_addr = (ptr); \
+ if (!is_kernel_addr((unsigned long)__pu_addr)) \
+ might_sleep(); \
+ __chk_user_ptr(ptr); \
+ __put_user_size((x), __pu_addr, (size), __pu_err); \
__pu_err; \
})
@@ -258,9 +261,11 @@ #define __get_user_nocheck(x, ptr, size)
({ \
long __gu_err; \
unsigned long __gu_val; \
+ const __typeof__(*(ptr)) __user *__gu_addr = (ptr); \
__chk_user_ptr(ptr); \
- might_sleep(); \
- __get_user_size(__gu_val, (ptr), (size), __gu_err); \
+ if (!is_kernel_addr((unsigned long)__gu_addr)) \
+ might_sleep(); \
+ __get_user_size(__gu_val, __gu_addr, (size), __gu_err); \
(x) = (__typeof__(*(ptr)))__gu_val; \
__gu_err; \
})
@@ -270,9 +275,11 @@ #define __get_user64_nocheck(x, ptr, siz
({ \
long __gu_err; \
long long __gu_val; \
- __chk_user_ptr(ptr); \
- might_sleep(); \
- __get_user_size(__gu_val, (ptr), (size), __gu_err); \
+ const __typeof__(*(ptr)) __user *__gu_addr = (ptr); \
+ __chk_user_ptr(ptr); \
+ if (!is_kernel_addr((unsigned long)__gu_addr)) \
+ might_sleep(); \
+ __get_user_size(__gu_val, __gu_addr, (size), __gu_err); \
(x) = (__typeof__(*(ptr)))__gu_val; \
__gu_err; \
})
^ permalink raw reply related
* [PATCH] powerpc: move _etext out of the text section
From: Stephen Rothwell @ 2006-05-02 3:25 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
The readprofile program stops when it hits the first non-text symbol
after _stext. By moving _etext, it will become an absolute symbol and
so stop the readprofile output. This is a safety measure in case more
text symbols are placed directly after the text section.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/kernel/vmlinux.lds.S | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
It would be nice if this was in 2.6.17, but 2.6.18 would also do.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
77a86e7cdbf5eaa5810109f7632e5bff69e1a7e6
diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index fe79c25..9055f5a 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -46,12 +46,12 @@ #ifdef CONFIG_PPC32
*(.got2)
__got2_end = .;
#endif /* CONFIG_PPC32 */
-
- . = ALIGN(PAGE_SIZE);
- _etext = .;
- PROVIDE32 (etext = .);
}
+ . = ALIGN(PAGE_SIZE);
+ _etext = .;
+ PROVIDE32 (etext = .);
+
/* Read-only data */
RODATA
--
1.3.1.gaa6b
^ permalink raw reply related
* Re: [PATCH 0/5] powerpc: Cleanup htab code a little
From: Michael Ellerman @ 2006-05-02 1:09 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <1143699173.339118.857634197021.qpush@concordia>
[-- Attachment #1: Type: text/plain, Size: 500 bytes --]
On Thu, 2006-03-30 at 17:12 +1100, Michael Ellerman wrote:
> A few cleanups to the htab. Built for pSeries, iSeries, pmac, pmac32
> and maple. Booted on P5 LPAR and iSeries.
This series still applies cleanly, so consider this a resend for 2.6.18
if you will.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Export flat device tree via debugfs for debugging
From: Michael Ellerman @ 2006-05-02 0:20 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <7C163A77-FF5F-49E7-87CF-0EA0411FE7A6@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 1635 bytes --]
On Mon, 2006-05-01 at 12:54 -0500, Kumar Gala wrote:
> 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.
It could, but DEBUG_FS is written so that you don't have to care, so I
didn't :)
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: DTC/dts modifications
From: Segher Boessenkool @ 2006-05-02 0:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org list, Jon Loeliger
In-Reply-To: <1146526448.30710.70.camel@localhost.localdomain>
>> 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.
>
> What about just providing a way to escape them ? Something like \#
> would
> do the trick
Nope, cpp won't eat that.
\#Segher
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 11/13] cell: split out board specific files
From: Michael Ellerman @ 2006-05-02 0:13 UTC (permalink / raw)
To: Geoff Levand
Cc: Arnd Bergmann, Arnd Bergmann, linux-kernel, linuxppc-dev,
cbe-oss-dev
In-Reply-To: <445690F7.5050605@am.sony.com>
[-- Attachment #1: Type: text/plain, Size: 1598 bytes --]
On Mon, 2006-05-01 at 15:51 -0700, Geoff Levand wrote:
> 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) += ...
Hi Geoff,
I've been ignoring this discussion, but now that I read it I think this
is all kinda backwards.
PPC_CELL should not denote !SOME_HYPERVISOR, it should just mean "basic
cell support", ie. PPC_CELL gets you platforms/cell built in.
Then we can have SOME_HYPERVISOR which _adds_ support for that
hypervisor. And PPC_CELL_BLADE which selects things which are actually
specific to that hardware, like SPIDERNET etc.
But SOME_HYPERVISOR should not remove support for running on bare metal,
it should just give you the option of running on the hypervisor. Yes
that may require testing things at runtime, that's what
firmware_has_feature() is for.
The goal should be that we have one kernel which can boot on all Cell
implementations. In fact the ultimate goal is to have one kernel that
can boot any platform under powerpc, that's a way off still, but we
don't want to start going backwards.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: windfarm for PM72/PM73/RM31
From: Robin H. Johnson @ 2006-05-02 0:13 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <A2D81A03-8CD5-41CD-BD49-3EDB1CDE53FD@laposte.net>
[-- Attachment #1: Type: text/plain, Size: 647 bytes --]
On Mon, May 01, 2006 at 06:53:09AM +0200, ?tienne Bersac wrote:
> I own an iMac G5 rev C (iSight) with a PowerMac 12,1 included. Do you
> intend to make support for it ? I will be happy to help you :)
Thanks for sending it to me.
The sensor portion of yours is done, it fit right into my existing code
(three lm75 and two max6690, with the dual temps on max6690 being very
important).
The PID params portion will come together a bit later, please bug me by
Wednesday next week if I haven't posted anything.
--
Robin Hugh Johnson
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
[-- Attachment #2: Type: application/pgp-signature, Size: 241 bytes --]
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 11/13] cell: split out board specific files
From: Segher Boessenkool @ 2006-05-02 0:06 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, cbe-oss-dev, linux-kernel
In-Reply-To: <200605020150.14152.arnd@arndb.de>
>> 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
>
> Hmm, I'm also no longer sure if this is right. In theory, spidernet
> could be used in all sorts of products, wether they are using the
> same bridge chip or just the gigabit ethernet macro from it.
>
> For now, I guess you can just leave this one alone if you respin
> the patch another time. It's disabled by default, so the dependency
> can be updated the next time we get a user in _addition_ to PPC_CELL.
Is there any reason the driver wouldn't build and/or run on other
platforms? If so, fix it. If not, just make it
depends on PCI
?
Segher
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 11/13] cell: split out board specific files
From: Arnd Bergmann @ 2006-05-01 23:50 UTC (permalink / raw)
To: cbe-oss-dev; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <445690F7.5050605@am.sony.com>
On Tuesday 02 May 2006 00:51, Geoff Levand wrote:
> Seems CELL_IIC is never used. Must be some stale variable,
> so I removed it. Arnd, could you ack this.
Yes, I used it before when there was more code shared between
Cell and pSeries, but that is no longer the case.
> 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.
>
I guess that one should really be (SPU_FS && CELL_NATIVE),
using the option Segher suggested now.
> ===================================================================
> --- 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
whoops, this one should not be there at all. Note that I updated
your previous patch as well to fit into the series for submission,
and that did not include systemsim.
> 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
I guess this could then become something like
spu-priv1-$(CONFIG_PPC_CELL_NATIVE) += spu_priv1_mmio.o
spufs-modular-$(CONFIG_SPU_FS) += spu_syscalls.o
obj-$(CONFIG_SPU_BASE) += spu_callbacks.o spu_base.o \
$(spufs-modular-m) \
$(spu-priv1-y)
> 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
Hmm, I'm also no longer sure if this is right. In theory, spidernet
could be used in all sorts of products, wether they are using the
same bridge chip or just the gigabit ethernet macro from it.
For now, I guess you can just leave this one alone if you respin
the patch another time. It's disabled by default, so the dependency
can be updated the next time we get a user in _addition_ to PPC_CELL.
Arnd <><
^ permalink raw reply
* Re: [Cbe-oss-dev] [PATCH 11/13] cell: split out board specific files
From: Arnd Bergmann @ 2006-05-01 23:49 UTC (permalink / raw)
To: cbe-oss-dev; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <FE7E70B5-F0CD-4254-8555-27EC2A70C316@kernel.crashing.org>
On Tuesday 02 May 2006 01:09, Segher Boessenkool wrote:
> So it really should be
>
> depends on PPC_CELL_NATIVE
>
> or similar. Having PPC_CELL mean "native" / "raw" is not the
> way to go, there will be many many hypervisors in the future,
> it would be nice to have PPC_CELL mean just that, "support for
> the Cell architecture" in general, kernels running on various
> hypervisors will see the hardware virtualised to varying degrees.
>
Yes, good point.
Arnd <><
^ permalink raw reply
* Re: DTC/dts modifications
From: Benjamin Herrenschmidt @ 2006-05-01 23:34 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list, Jon Loeliger
In-Reply-To: <55FD11DB-54AF-4284-9E9A-C313F4232105@kernel.crashing.org>
> 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.
What about just providing a way to escape them ? Something like \# would
do the trick
Ben
^ permalink raw reply
* Re: ioremap
From: Josh Boyer @ 2006-05-01 22:45 UTC (permalink / raw)
To: Srinivas Murthy; +Cc: linuxppc-dev
In-Reply-To: <7cb1293c0605011425w1cc34197h4d5fa73ad1077d5a@mail.gmail.com>
On Mon, 2006-05-01 at 14:25 -0700, Srinivas Murthy wrote:
> 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?
Limit the amount of memory the kernel consumes using mem=XXM. Then you
should be able to use ioremap on the remainder.
josh
^ permalink raw reply
* Re: 2.6.17-rc2-mm1
From: Badari Pulavarty @ 2006-05-01 23:29 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Andrew Morton, linuxppc64-dev, lkml, Martin Bligh, ak
In-Reply-To: <44565443.3020000@shadowen.org>
Andy Whitcroft wrote:
>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.
>
I ran whole LTP with 2.6.17-rc3-mm1 on my (2-way P710) Power box and
didn't see any crashes. I also ran LTP on AMD64 box without any crashes.
Thanks,
Badari
^ permalink raw reply
* Re: question about Linux 2.6 with Xilinx ML-403
From: yding @ 2006-05-01 23:15 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded list
In-Reply-To: <528646bc0604071518i5f95b4dbtd232d8cb92ef4fb9@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]
HI, Grant,
It looks like that the patch for ML-403 in Linux 2.6.17 kernel(I
downloaded from Linus git tree) does not have the directory :
./arch/ppc/platform/4xx/xilinx_ocp like the one in the 2.4.30 kernel.
And also, I saw this thread: "Migrate Xilinx Vertex support from the OCP
bus to the platfom bus"
http://patchwork.ozlabs.org/linuxppc/patch?id=3933
Does it mean all of onchip peripherals for Virtex-4 FX must reside on
the PLB bus instead of OPB (OCB) bus ?
(i.e. during the process of creating the ref design for Linux using
Xilinx Platform studio, I have to select PLB peripherals instead of OPB
peripherals. Is is correct ?)
BTW, do you have a sample ref design for ML-403 board for Xilinx
Platform studio ?
Thanks for the help.
--
Ying Ding
Grant Likely wrote:
>On 4/7/06, yding <yding@lnxw.com> wrote:
>
>
>> HI, Grant,
>>
>> I found this message :
>>http://patchwork.ozlabs.org/linuxppc/patch?id=3841 on
>>Internet.
>> It looks like you created some patch files for supporting Linux 2.6 with
>>Xilinx ML-403.
>>
>>how can download the whole kernel source tree with your patched files (via
>>cvs or bitkeeper) ?
>>
>>
>
>I believe they are now in Linus' mainline git tree. If not, they are
>in Paul's powerpc git tree.
>
>BTW, please CC the linuxppc-embedded mailing list when emailing me directly.
>
>Cheers,
>g.
>--
>Grant Likely, B.Sc. P.Eng.
>Secret Lab Technologies Ltd.
>(403) 399-0195
>
>
>
[-- Attachment #2: Type: text/html, Size: 2165 bytes --]
^ permalink raw reply
* Re: [PATCH 11/13] cell: split out board specific files
From: Segher Boessenkool @ 2006-05-01 23:09 UTC (permalink / raw)
To: Geoff Levand
Cc: Arnd Bergmann, Arnd Bergmann, linux-kernel, linuxppc-dev, paulus,
cbe-oss-dev
In-Reply-To: <445690F7.5050605@am.sony.com>
> 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:
Not just that, but we can have a kernel image supporting both
the "raw" hardware _and_ stuff with a hypervisor underneath.
All CONFIG_<whatever> should always be used as a positive,
never a negative. My bad :-)
So it really should be
depends on PPC_CELL_NATIVE
or similar. Having PPC_CELL mean "native" / "raw" is not the
way to go, there will be many many hypervisors in the future,
it would be nice to have PPC_CELL mean just that, "support for
the Cell architecture" in general, kernels running on various
hypervisors will see the hardware virtualised to varying degrees.
Segher
^ permalink raw reply
* 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
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