* [PATCH] use-generic-bug-for-ppc
From: Judith Lebzelter @ 2006-10-04 18:49 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, jeremy, linux-kernel
For 2.6.18-mm3, the 32-bit 'ppc' architectures won't compile due to errors:
arch/ppc/kernel/built-in.o: In function `find_bug':
arch/ppc/kernel/traps.c:582: undefined reference to `module_find_bug'
arch/powerpc/kernel/built-in.o: In function `module_arch_cleanup':
arch/powerpc/kernel/module_32.c:282: undefined reference to `module_bug_cleanup'
arch/powerpc/kernel/built-in.o: In function `module_finalize':
arch/powerpc/kernel/module_32.c:277: undefined reference to `module_bug_finalize'
make: [.tmp_vmlinux3] Error 1 (ignored)
KSYM .tmp_kallsyms3.S
powerpc-750-linux-gnu-nm: '.tmp_vmlinux3': No such file
No valid symbol.
make: [.tmp_kallsyms3.S] Error 1 (ignored)
AS .tmp_kallsyms3.o
LD vmlinux
arch/ppc/kernel/built-in.o: In function `find_bug':
arch/ppc/kernel/traps.c:582: undefined reference to `module_find_bug'
arch/powerpc/kernel/built-in.o: In function `module_arch_cleanup':
arch/powerpc/kernel/module_32.c:282: undefined reference to `module_bug_cleanup'
arch/powerpc/kernel/built-in.o: In function `module_finalize':
arch/powerpc/kernel/module_32.c:277: undefined reference to `module_bug_finalize'
make: [vmlinux] Error 1 (ignored)
These changes match changes for using the generic bug libraries as in
'use-generic-bug-for-powerpc.patch' and gets rid of the compile errors.
Signed-off-by: Judith Lebzelter <judith@osdl.org>
---
Files Edited:
arch/ppc/kernel/traps.c
arch/ppc/Kconfig
Index: linux/arch/ppc/Kconfig
===================================================================
--- linux.orig/arch/ppc/Kconfig 2006-10-03 16:11:26.456655259 -0700
+++ linux/arch/ppc/Kconfig 2006-10-03 17:10:09.398320057 -0700
@@ -52,6 +52,11 @@
bool
default y
+config GENERIC_BUG
+ bool
+ default y
+ depends on BUG
+
source "init/Kconfig"
menu "Processor"
Index: linux/arch/ppc/kernel/traps.c
===================================================================
--- linux.orig/arch/ppc/kernel/traps.c 2006-10-03 16:11:26.461653713 -0700
+++ linux/arch/ppc/kernel/traps.c 2006-10-04 10:00:21.198907987 -0700
@@ -28,6 +28,7 @@
#include <linux/init.h>
#include <linux/module.h>
#include <linux/prctl.h>
+#include <linux/bug.h>
#include <asm/pgtable.h>
#include <asm/uaccess.h>
@@ -568,55 +569,9 @@
*/
extern struct bug_entry __start___bug_table[], __stop___bug_table[];
-#ifndef CONFIG_MODULES
-#define module_find_bug(x) NULL
-#endif
-
-struct bug_entry *find_bug(unsigned long bugaddr)
+int is_valid_bugaddr(unsigned long addr)
{
- struct bug_entry *bug;
-
- for (bug = __start___bug_table; bug < __stop___bug_table; ++bug)
- if (bugaddr == bug->bug_addr)
- return bug;
- return module_find_bug(bugaddr);
-}
-
-int check_bug_trap(struct pt_regs *regs)
-{
- struct bug_entry *bug;
- unsigned long addr;
-
- if (regs->msr & MSR_PR)
- return 0; /* not in kernel */
- addr = regs->nip; /* address of trap instruction */
- if (addr < PAGE_OFFSET)
- return 0;
- bug = find_bug(regs->nip);
- if (bug == NULL)
- return 0;
- if (bug->line & BUG_WARNING_TRAP) {
- /* this is a WARN_ON rather than BUG/BUG_ON */
-#ifdef CONFIG_XMON
- xmon_printf(KERN_ERR "Badness in %s at %s:%ld\n",
- bug->function, bug->file,
- bug->line & ~BUG_WARNING_TRAP);
-#endif /* CONFIG_XMON */
- printk(KERN_ERR "Badness in %s at %s:%ld\n",
- bug->function, bug->file,
- bug->line & ~BUG_WARNING_TRAP);
- dump_stack();
- return 1;
- }
-#ifdef CONFIG_XMON
- xmon_printf(KERN_CRIT "kernel BUG in %s at %s:%ld!\n",
- bug->function, bug->file, bug->line);
- xmon(regs);
-#endif /* CONFIG_XMON */
- printk(KERN_CRIT "kernel BUG in %s at %s:%ld!\n",
- bug->function, bug->file, bug->line);
-
- return 0;
+ return addr >= PAGE_OFFSET;
}
void program_check_exception(struct pt_regs *regs)
@@ -671,7 +626,9 @@
/* trap exception */
if (debugger_bpt(regs))
return;
- if (check_bug_trap(regs)) {
+
+ if (!(regs->msr & MSR_PR) && /* not user-mode */
+ report_bug(regs->nip) == BUG_TRAP_TYPE_WARN) {
regs->nip += 4;
return;
}
^ permalink raw reply
* Re: [PATCH] Add of_platform_device_scan().
From: Scott Wood @ 2006-10-04 19:33 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
In-Reply-To: <200610041837.47317.arnd@arndb.de>
Arnd Bergmann wrote:
> On Wednesday 04 October 2006 18:32, Scott Wood wrote:
>
>>What I'd really like (long-term, of course) is if platform_device and
>>of_device were merged, with device tree support (or at least a means of
>>passing on properties that *could* come from a device tree without
>>special glue code that knows about each property) in arch-neutral code;
>>the mechanism for discovering devices ideally shouldn't depend on the
>>CPU's instruction set.
>
>
> My guess is that this won't happen, because other architectures
> normally don't describe their platform devices in a way that is
> anywhere near what we have on powerpc.
They wouldn't need to, unless they want to support a driver that
requires it. It would simply be an architecture-neutral mechanism for
attaching a dynamic list of properties and OF-compatible matching
criteria (or more generally the ability to match on any set of dynamic
properties) to platform devices; the source of the platform data could
choose to use it to represent an OF device tree, to supply a few
properties needed by a specific driver, or not at all.
Ideally, users of static structure-based platform data would gradually
migrate to dynamic properties, but there's a benefit to the integration
even if they don't. The main issue that I forsee being a problem is
clashing with another standard for the naming and content of properties.
There could be tagging to indicate which standard is being followed by
a given property, but that could lead to some ugliness in drivers that
need to support more than one if the differences can't be easily
abstracted by get-me-this-piece-of-information accessor functions (or by
code that generically converts properties from one standard to
another, which is similar to what we've already got in fsl_soc.c, but
hopefully less device-specific).
-Scott
^ permalink raw reply
* Re: [PATCH] use-generic-bug-for-ppc
From: Jeremy Fitzhardinge @ 2006-10-04 20:15 UTC (permalink / raw)
To: Judith Lebzelter; +Cc: Andrew Morton, linuxppc-dev, paulus, linux-kernel
In-Reply-To: <20061004184927.GH665@shell0.pdx.osdl.net>
Judith Lebzelter wrote:
> Index: linux/arch/ppc/kernel/traps.c
> ===================================================================
> --- linux.orig/arch/ppc/kernel/traps.c 2006-10-03 16:11:26.461653713 -0700
> +++ linux/arch/ppc/kernel/traps.c 2006-10-04 10:00:21.198907987 -0700
> @@ -28,6 +28,7 @@
> #include <linux/init.h>
> #include <linux/module.h>
> #include <linux/prctl.h>
> +#include <linux/bug.h>
>
> #include <asm/pgtable.h>
> #include <asm/uaccess.h>
> @@ -568,55 +569,9 @@
> */
> extern struct bug_entry __start___bug_table[], __stop___bug_table[];
>
> -#ifndef CONFIG_MODULES
> -#define module_find_bug(x) NULL
> -#endif
>
Looks like you need to delete a bit more here - the extern struct
bug_entry, and the comment above.
J
^ permalink raw reply
* Re: [PATCH 4/7] Add MPC8360EMDS board support (try 2)
From: Kim Phillips @ 2006-10-04 21:16 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <CEA95FBE-ED7E-4512-A6C5-6362DAE69744@kernel.crashing.org>
On Tue, 3 Oct 2006 23:27:42 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Oct 3, 2006, at 11:17 PM, Kim Phillips wrote:
>
<snip>
> > arch/powerpc/platforms/83xx/mpc8360e_pb.c | 220 ++++++
> > arch/powerpc/platforms/83xx/mpc8360e_pb.h | 23 +
> > 3 files changed, 1261 insertions(+), 0 deletions(-)
>
> What's the point of the mpc8360e_pb.h if there's nothing in it?
>
well I thought I was being consistent with the other 83xx boards ;)
> Also, any reason the files are _pb and config is emds?
>
_pb == processor board, the core of the mds (modular development system). The pb can be operated independently of the rest of what comprises the mds.
I used mds nomenclature in 832x since the support includes parts of the mds that are separate from just the pb, e.g. the pci bits in the device tree.
but we need to be more consistent, I agree.
also, there is a wealth of duplicated platform code among each of the four 83xx platforms. Somethings wrong when one duplicates a file just to s/836/832/g. How about consolidating them all down to one mpc83xx_mach.c file that enables potential board quirks based on the dev tree root's model property? That will eliminate all the redundant code, and get rid of the file naming inconsistencies.
Kim
^ permalink raw reply
* bdm/jtag interface for MPC834x with gdb access
From: Reeve Yang @ 2006-10-04 22:00 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 194 bytes --]
Can anyone share experience on bcm/jtag interface for MPC834x with gdb
access? I'm using windriver usb jtag probe. Is there any bdm interface with
gdb access available for it?
Thanks.
- Reeve
[-- Attachment #2: Type: text/html, Size: 214 bytes --]
^ permalink raw reply
* Re: [PATCH] use-generic-bug-for-ppc resubmitted
From: Judith Lebzelter @ 2006-10-04 23:29 UTC (permalink / raw)
To: Jeremy Fitzhardinge; +Cc: Andrew Morton, linuxppc-dev, paulus, linux-kernel
In-Reply-To: <45241659.301@goop.org>
On Wed, Oct 04, 2006 at 01:15:21PM -0700, Jeremy Fitzhardinge wrote:
> Judith Lebzelter wrote:
> >Index: linux/arch/ppc/kernel/traps.c
> >===================================================================
> >--- linux.orig/arch/ppc/kernel/traps.c 2006-10-03
> >16:11:26.461653713 -0700
> >+++ linux/arch/ppc/kernel/traps.c 2006-10-04 10:00:21.198907987 -0700
> >@@ -28,6 +28,7 @@
> > #include <linux/init.h>
> > #include <linux/module.h>
> > #include <linux/prctl.h>
> >+#include <linux/bug.h>
> >
> > #include <asm/pgtable.h>
> > #include <asm/uaccess.h>
> >@@ -568,55 +569,9 @@
> > */
> > extern struct bug_entry __start___bug_table[], __stop___bug_table[];
> >
> >-#ifndef CONFIG_MODULES
> >-#define module_find_bug(x) NULL
> >-#endif
> >
> Looks like you need to delete a bit more here - the extern struct
> bug_entry, and the comment above.
> J
Here is the generic bug ppc patch with the suggested change. It compiles
without error.
Signed-off-by: Judith Lebzelter <judith@osdl.org>
---
arch/ppc/kernel/traps.c
arch/ppc/Kconfig
Index: linux/arch/ppc/Kconfig
===================================================================
--- linux.orig/arch/ppc/Kconfig 2006-10-03 16:11:26.000000000 -0700
+++ linux/arch/ppc/Kconfig 2006-10-03 17:10:09.000000000 -0700
@@ -52,6 +52,11 @@
bool
default y
+config GENERIC_BUG
+ bool
+ default y
+ depends on BUG
+
source "init/Kconfig"
menu "Processor"
Index: linux/arch/ppc/kernel/traps.c
===================================================================
--- linux.orig/arch/ppc/kernel/traps.c 2006-10-03 16:11:26.000000000 -0700
+++ linux/arch/ppc/kernel/traps.c 2006-10-04 15:37:46.674644563 -0700
@@ -28,6 +28,7 @@
#include <linux/init.h>
#include <linux/module.h>
#include <linux/prctl.h>
+#include <linux/bug.h>
#include <asm/pgtable.h>
#include <asm/uaccess.h>
@@ -559,64 +560,9 @@
}
}
-/*
- * Look through the list of trap instructions that are used for BUG(),
- * BUG_ON() and WARN_ON() and see if we hit one. At this point we know
- * that the exception was caused by a trap instruction of some kind.
- * Returns 1 if we should continue (i.e. it was a WARN_ON) or 0
- * otherwise.
- */
-extern struct bug_entry __start___bug_table[], __stop___bug_table[];
-
-#ifndef CONFIG_MODULES
-#define module_find_bug(x) NULL
-#endif
-
-struct bug_entry *find_bug(unsigned long bugaddr)
-{
- struct bug_entry *bug;
-
- for (bug = __start___bug_table; bug < __stop___bug_table; ++bug)
- if (bugaddr == bug->bug_addr)
- return bug;
- return module_find_bug(bugaddr);
-}
-
-int check_bug_trap(struct pt_regs *regs)
+int is_valid_bugaddr(unsigned long addr)
{
- struct bug_entry *bug;
- unsigned long addr;
-
- if (regs->msr & MSR_PR)
- return 0; /* not in kernel */
- addr = regs->nip; /* address of trap instruction */
- if (addr < PAGE_OFFSET)
- return 0;
- bug = find_bug(regs->nip);
- if (bug == NULL)
- return 0;
- if (bug->line & BUG_WARNING_TRAP) {
- /* this is a WARN_ON rather than BUG/BUG_ON */
-#ifdef CONFIG_XMON
- xmon_printf(KERN_ERR "Badness in %s at %s:%ld\n",
- bug->function, bug->file,
- bug->line & ~BUG_WARNING_TRAP);
-#endif /* CONFIG_XMON */
- printk(KERN_ERR "Badness in %s at %s:%ld\n",
- bug->function, bug->file,
- bug->line & ~BUG_WARNING_TRAP);
- dump_stack();
- return 1;
- }
-#ifdef CONFIG_XMON
- xmon_printf(KERN_CRIT "kernel BUG in %s at %s:%ld!\n",
- bug->function, bug->file, bug->line);
- xmon(regs);
-#endif /* CONFIG_XMON */
- printk(KERN_CRIT "kernel BUG in %s at %s:%ld!\n",
- bug->function, bug->file, bug->line);
-
- return 0;
+ return addr >= PAGE_OFFSET;
}
void program_check_exception(struct pt_regs *regs)
@@ -671,7 +617,9 @@
/* trap exception */
if (debugger_bpt(regs))
return;
- if (check_bug_trap(regs)) {
+
+ if (!(regs->msr & MSR_PR) && /* not user-mode */
+ report_bug(regs->nip) == BUG_TRAP_TYPE_WARN) {
regs->nip += 4;
return;
}
^ permalink raw reply
* Please pull powerpc.git 'master' branch
From: Paul Mackerras @ 2006-10-04 23:36 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do:
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
again, to get a Cell update. I apologize on Arnd's behalf for the
lateness of this update.
Thanks,
Paul.
arch/powerpc/configs/cell_defconfig | 60 +++
arch/powerpc/platforms/cell/Kconfig | 5
arch/powerpc/platforms/cell/interrupt.c | 10 -
arch/powerpc/platforms/cell/iommu.c | 8
arch/powerpc/platforms/cell/spider-pic.c | 6
arch/powerpc/platforms/cell/spu_base.c | 168 ++++++++--
arch/powerpc/platforms/cell/spufs/Makefile | 2
arch/powerpc/platforms/cell/spufs/context.c | 6
arch/powerpc/platforms/cell/spufs/file.c | 354 +++++++++++++++-----
arch/powerpc/platforms/cell/spufs/gang.c | 81 +++++
arch/powerpc/platforms/cell/spufs/inode.c | 232 +++++++++++--
arch/powerpc/platforms/cell/spufs/run.c | 48 ++-
arch/powerpc/platforms/cell/spufs/sched.c | 450 ++++++++++----------------
arch/powerpc/platforms/cell/spufs/spufs.h | 29 ++
arch/powerpc/platforms/cell/spufs/switch.c | 9 +
arch/powerpc/platforms/cell/spufs/syscalls.c | 9 -
include/asm-powerpc/spu.h | 36 ++
17 files changed, 1017 insertions(+), 496 deletions(-)
create mode 100644 arch/powerpc/platforms/cell/spufs/gang.c
Arnd Bergmann:
[POWERPC] spufs: implement error event delivery to user space
[POWERPC] spufs: Add infrastructure needed for gang scheduling
[POWERPC] spufs: use correct pg_prot for mapping SPU local store
[POWERPC] spufs: make mailbox functions handle multiple elements
[POWERPC] spufs: remove support for ancient firmware
[POWERPC] spufs: add support for read/write on cntl
[POWERPC] spufs: support new OF device tree format
[POWERPC] spufs: add infrastructure for finding elf objects
[POWERPC] Update cell_defconfig
[POWERPC] spiderpic: enable new style devtree support
[POWERPC] cell: fix bugs found by sparse
Benjamin Herrenschmidt:
[POWERPC] spufs: cell spu problem state mapping updates
HyeonSeung Jang:
[POWERPC] spufs: fix context switch during page fault
Mark Nutter:
[POWERPC] spufs: scheduler support for NUMA.
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Benjamin Herrenschmidt @ 2006-10-04 23:36 UTC (permalink / raw)
To: Dan Malek; +Cc: Olof Johansson, linuxppc-dev, Paul Mackerras
In-Reply-To: <7BD0D5CE-7BA3-43DC-B972-B75672F6A31E@embeddedalley.com>
On Wed, 2006-10-04 at 10:48 -0400, Dan Malek wrote:
> On Oct 4, 2006, at 2:08 AM, Benjamin Herrenschmidt wrote:
>
> > It's not that complex and the single binary is not necessarily the
> > main
> > objective (it's a good practice as it enforce avoiding ugly #ifdef
> > hacks
>
> Would you guys please get off of this #ifdefs discussion! :-)
> That's not what this is about.
But it _IS_ in large part ! #ifdefs are ugly and evil. So it's about
that and having a central repository for board specific informations
instead of hacks cluttered around 20 drivers....
> > There is fundamentally little difference between the OCP tables we had
> > before and the device-tree.
>
> Exactly! So why has it become such a desire to represent
> stuff in the device tree that was never necessary to represent
> in other table formats before?
For several reasons. One of them is the fact that the previous tables
were too limited, another is that we are converging using the same
mecanism for all platforms.
> > The new device-tree model provides a more flexible and richer semantic
> > for adding all sort of driver or BSP private infos, and for dealing
> > with
> > address mapping and interrupt mapping.
>
> Not really, we had all of this before..... and in a way
> that I didn't have to learn a new syntax to represent.
Ugh ? Look at the #ifdef mess in ibm_emac...
> > When done right, it does simplify the matter. An example that I've
> > seen
> > internally is embedded boards with all sorts of variety of dodgy
> > interrupt controllers cascaded on each other.
>
> Good example. Cascaded interrupt controllers are always
> a challenge. :-) It doesn't matter how you present the
> information about their configuration if you don't have
> the code written properly to manage them. It's the
> _code_ you write the solves the problem, not the
> device tree.
The device-tree allows the code to be much simpler. The -code- becomes
what it should be in the first place: purely a driver for each actual
chip with no need for much knowledge if the general layout. Layout
related (and in general board related) informations are in the
device-tree and the board setup file(s). It's cleaner and simpler.
> It doesn't really make it any simpler for the driver, because
> they have always retrieved that information in some way that
> has been consistent, usually from the old board descriptor
> or platform data.
No, it's never been consistent.
> The method of converting that information,
> usually a concern of the boot rom or the boot wrapper or
> compiled in, is what we are changing now.
We are changing the method to make it consistent. Providing the
information is still a concern of the boot rom or the wrapper.
> > There is a great flexibility of putting whatever you want in
> > there... or
> > not.
>
> It's the 'or not' part that I am worried about. Things like
> you mention above make sense. I'm starting to worry about
> some of this other stuff, and the bscr example is what
> woke me up :-) I think that's an example of things that
> should be considered not necessary.
I haven't looked at this specific example. I'll try to have a look
later. I jumped into the discussion pointed by somebody else :)
> > It's up to the embedded developper to use that tool, it can be used
> > in a bloated way, or in a smart way, we aren't enforcing any direction
> > here.
>
> Not really. To use a particular driver you are going to have
> to provide the proper amount of information. It's not up to
> me as a consumer of something already written. I can
> only control that if I'm the developer of the code.
Oh sure, existing drivers will require some amount of information, and
that's good. Better have it in that central place than having board
specific junk in every driver. However, you can use it to add your own
stuffs as well if you feel the need. And when I say used in a simple vs.
a bloated way, it's also up to the driver writer to not require too
much...
> > I think you are a bit too dismissive here. The approach has always
> > been
> > to provide the choice,
>
> There isn't a choice. If I want to use a particular driver
> I have to provide the proper and necessary information
> using a device tree, period. If I want to change my
> board design for some reason that is advantageous
> to me, and the driver doesn't support it, no possible
> convolution of device tree information is going to make
> that happen.
Then you fix the driver. We are not solving world hunger but we are at
least trying to improve our own food quality here.
> > ... is hopefully an easier way to create the BSP in the first place,
>
> Sorry, but I don't see that. You are either skilled at
> creating a BSP or you are not. The device tree just adds
> another dimension of information in a syntax and structure
> that you have to learn.
To re-use your own answer to one of my points, I'd say that's
bullshit :) It's easier to have a central place with well defined
bindings to express things like your interrupt routing, device layout
and addresses etc...
> > .... The -ability- to build multi-board
> > kernels is made mandatory for code to be merged upstream,
>
> Why? When are people going to realize that the
> ratio of Linux on custom embedded systems to a standard
> workstation is about a million to one?
And ?
> So what if I
> can boot the same kernel on a couple of obsolete
> PowerPC workstations using drivers that aren't used
> anywhere else? Or, on a couple of embedded eval
> boards that don't represent how people build products?
> Hell, I tried to build an x86 kernel the other day
> for a PC and still don't have one that boots. I can't
> seem to figure out what processor configuration
> options or compiler options to use. Linux doesn't
> even support this on a "standard" PC. :-)
That's what defconfigs are for.
> > ... as it enforces
> > a certain level of quality,
>
> That's BS and you know it :-)
No, it's not. Look at the inextricable mess arch/ppc is in. We are
trying hard to avoid that for arch/powerpc. If you let people just do
hacks with #ifdef's all over the place for every single board, you end
up with something mostly unmaintainable. Your point would be valid if
the linux kernel was a frozen thing that didn't evolve. However, it
evolves and needs to be actively devleopped/maintained. Having a sane
infrastructure to hook board support in makes it easier and cleaner.
Also, most of the code for embedded that actually gets merged upstream
is code for evaluation boards provided by chip vendors, not end-user
embedded code, you know very well that the actual embedded developpers
never submit anything upstream, they don't care. That means that what
gets merged upstream is what will be used as example code and base for
new board supports. Thus it's important that is has as much flexibility
as possible, including the ability to build kernels with multiple board
supports in a single image. Embedded customers are the end of the chain
might chose to not use that capability, but it shall be provided by the
base/example code in the upstream repository.
> > .... In fact, you client may be happy, once it's done rev 3 of the
> > board with a 3rd type of wifi chip or a 2nd type of ethernet HUB to
> > have
> > the ability to easily build, maintain, distribute and test a single
> > kernel image,
>
> That's not very important. For high volume products that
> are already in the field, the way the binary image is created
> or if they need different ones on different versions, isn't
> important. The whole process of tracking, testing, distributing,
> installing, upgrading, reverting makes our development
> tools insignificant to them. All that is desired is an image
> that when upgraded doesn't turn a million boxes into
> bricks. If it does, our cleverness to use a device tree to
> support multiple boards better not be the problem, because
> if it is it will never be used again.
That argument too is BS and you know it :)
Ben.
^ permalink raw reply
* [PATCH] Fix dtb inclusion in zImage and split OF stuff
From: Paul Mackerras @ 2006-10-04 23:57 UTC (permalink / raw)
To: mgreer, linuxppc-dev
This fixes the inclusion of device-tree blobs by the wrapper script,
and splits of.c into of.c and ofcall.c, where ofcall.c contains the
low-level interface to OF and of.c contains the platform definition
for OF-based machines. This patch forms part of the changes I have
been working on to get an IBM PReP machine booting with ARCH=powerpc.
Paul.
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index c383d56..6568e32 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -40,8 +40,8 @@ zliblinuxheader := zlib.h zconf.h zutil.
$(addprefix $(obj)/,$(zlib) main.o): $(addprefix $(obj)/,$(zliblinuxheader)) \
$(addprefix $(obj)/,$(zlibheader))
-src-wlib := string.S stdio.c main.c div64.S $(zlib)
-src-plat := of.c
+src-wlib := string.S stdio.c main.c ofcons.c ofcall.c div64.S $(zlib)
+src-plat := of.c prep.c
src-boot := crt0.S $(src-wlib) $(src-plat) empty.c
src-boot := $(addprefix $(obj)/, $(src-boot))
diff --git a/arch/powerpc/boot/main.c b/arch/powerpc/boot/main.c
index d719bb9..3084fb0 100644
--- a/arch/powerpc/boot/main.c
+++ b/arch/powerpc/boot/main.c
@@ -27,6 +27,8 @@ extern char _vmlinux_start[];
extern char _vmlinux_end[];
extern char _initrd_start[];
extern char _initrd_end[];
+extern char _dtb_start[];
+extern char _dtb_end[];
struct addr_range {
unsigned long addr;
@@ -285,12 +287,6 @@ static void set_cmdline(char *buf)
setprop(devp, "bootargs", buf, strlen(buf) + 1);
}
-/* Section where ft can be tacked on after zImage is built */
-union blobspace {
- struct boot_param_header hdr;
- char space[8*1024];
-} dt_blob __attribute__((__section__("__builtin_ft")));
-
struct platform_ops platform_ops;
struct dt_ops dt_ops;
struct console_ops console_ops;
@@ -309,9 +305,9 @@ void start(unsigned long a1, unsigned lo
/* Override the dt_ops and device tree if there was an flat dev
* tree attached to the zImage.
*/
- if (dt_blob.hdr.magic == OF_DT_HEADER) {
+ if (_dtb_end > _dtb_start) {
have_dt = 1;
- ft_init(&dt_blob);
+ ft_init(_dtb_start);
}
if (platform_init(promptr))
diff --git a/arch/powerpc/boot/of.c b/arch/powerpc/boot/of.c
index fd99f78..2541339 100644
--- a/arch/powerpc/boot/of.c
+++ b/arch/powerpc/boot/of.c
@@ -14,165 +14,17 @@ #include "string.h"
#include "stdio.h"
#include "page.h"
#include "ops.h"
-
-typedef void *ihandle;
-typedef void *phandle;
+#include "of.h"
extern char _end[];
+static unsigned long claim_base;
+
/* Value picked to match that used by yaboot */
#define PROG_START 0x01400000 /* only used on 64-bit systems */
#define RAM_END (512<<20) /* Fixme: use OF */
#define ONE_MB 0x100000
-int (*prom) (void *);
-
-
-static unsigned long claim_base;
-
-static int call_prom(const char *service, int nargs, int nret, ...)
-{
- int i;
- struct prom_args {
- const char *service;
- int nargs;
- int nret;
- unsigned int args[12];
- } args;
- va_list list;
-
- args.service = service;
- args.nargs = nargs;
- args.nret = nret;
-
- va_start(list, nret);
- for (i = 0; i < nargs; i++)
- args.args[i] = va_arg(list, unsigned int);
- va_end(list);
-
- for (i = 0; i < nret; i++)
- args.args[nargs+i] = 0;
-
- if (prom(&args) < 0)
- return -1;
-
- return (nret > 0)? args.args[nargs]: 0;
-}
-
-static int call_prom_ret(const char *service, int nargs, int nret,
- unsigned int *rets, ...)
-{
- int i;
- struct prom_args {
- const char *service;
- int nargs;
- int nret;
- unsigned int args[12];
- } args;
- va_list list;
-
- args.service = service;
- args.nargs = nargs;
- args.nret = nret;
-
- va_start(list, rets);
- for (i = 0; i < nargs; i++)
- args.args[i] = va_arg(list, unsigned int);
- va_end(list);
-
- for (i = 0; i < nret; i++)
- args.args[nargs+i] = 0;
-
- if (prom(&args) < 0)
- return -1;
-
- if (rets != (void *) 0)
- for (i = 1; i < nret; ++i)
- rets[i-1] = args.args[nargs+i];
-
- return (nret > 0)? args.args[nargs]: 0;
-}
-
-/*
- * Older OF's require that when claiming a specific range of addresses,
- * we claim the physical space in the /memory node and the virtual
- * space in the chosen mmu node, and then do a map operation to
- * map virtual to physical.
- */
-static int need_map = -1;
-static ihandle chosen_mmu;
-static phandle memory;
-
-/* returns true if s2 is a prefix of s1 */
-static int string_match(const char *s1, const char *s2)
-{
- for (; *s2; ++s2)
- if (*s1++ != *s2)
- return 0;
- return 1;
-}
-
-static int check_of_version(void)
-{
- phandle oprom, chosen;
- char version[64];
-
- oprom = finddevice("/openprom");
- if (oprom == (phandle) -1)
- return 0;
- if (getprop(oprom, "model", version, sizeof(version)) <= 0)
- return 0;
- version[sizeof(version)-1] = 0;
- printf("OF version = '%s'\r\n", version);
- if (!string_match(version, "Open Firmware, 1.")
- && !string_match(version, "FirmWorks,3."))
- return 0;
- chosen = finddevice("/chosen");
- if (chosen == (phandle) -1) {
- chosen = finddevice("/chosen@0");
- if (chosen == (phandle) -1) {
- printf("no chosen\n");
- return 0;
- }
- }
- if (getprop(chosen, "mmu", &chosen_mmu, sizeof(chosen_mmu)) <= 0) {
- printf("no mmu\n");
- return 0;
- }
- memory = (ihandle) call_prom("open", 1, 1, "/memory");
- if (memory == (ihandle) -1) {
- memory = (ihandle) call_prom("open", 1, 1, "/memory@0");
- if (memory == (ihandle) -1) {
- printf("no memory node\n");
- return 0;
- }
- }
- printf("old OF detected\r\n");
- return 1;
-}
-
-static void *claim(unsigned long virt, unsigned long size, unsigned long align)
-{
- int ret;
- unsigned int result;
-
- if (need_map < 0)
- need_map = check_of_version();
- if (align || !need_map)
- return (void *) call_prom("claim", 3, 1, virt, size, align);
-
- ret = call_prom_ret("call-method", 5, 2, &result, "claim", memory,
- align, size, virt);
- if (ret != 0 || result == -1)
- return (void *) -1;
- ret = call_prom_ret("call-method", 5, 2, &result, "claim", chosen_mmu,
- align, size, virt);
- /* 0x12 == coherent + read/write */
- ret = call_prom("call-method", 6, 1, "map", chosen_mmu,
- 0x12, size, virt, virt);
- return (void *) virt;
-}
-
static void *of_try_claim(u32 size)
{
unsigned long addr = 0;
@@ -187,7 +39,7 @@ static void *of_try_claim(u32 size)
#ifdef DEBUG
printf(" trying: 0x%08lx\n\r", claim_base);
#endif
- addr = (unsigned long)claim(claim_base, size, 0);
+ addr = (unsigned long)of_claim(claim_base, size, 0);
if ((void *)addr != (void *)-1)
break;
}
@@ -211,73 +63,18 @@ static void of_image_hdr(const void *hdr
}
}
-static void of_exit(void)
-{
- call_prom("exit", 0, 0);
-}
-
-/*
- * OF device tree routines
- */
-static void *of_finddevice(const char *name)
-{
- return (phandle) call_prom("finddevice", 1, 1, name);
-}
-
-static int of_getprop(const void *phandle, const char *name, void *buf,
- const int buflen)
-{
- return call_prom("getprop", 4, 1, phandle, name, buf, buflen);
-}
-
-static int of_setprop(const void *phandle, const char *name, const void *buf,
- const int buflen)
-{
- return call_prom("setprop", 4, 1, phandle, name, buf, buflen);
-}
-
-/*
- * OF console routines
- */
-static void *of_stdout_handle;
-
-static int of_console_open(void)
-{
- void *devp;
-
- if (((devp = finddevice("/chosen")) != NULL)
- && (getprop(devp, "stdout", &of_stdout_handle,
- sizeof(of_stdout_handle))
- == sizeof(of_stdout_handle)))
- return 0;
-
- return -1;
-}
-
-static void of_console_write(char *buf, int len)
-{
- call_prom("write", 3, 1, of_stdout_handle, buf, len);
-}
-
int platform_init(void *promptr)
{
+ of_init(promptr);
+
platform_ops.fixups = NULL;
platform_ops.image_hdr = of_image_hdr;
platform_ops.malloc = of_try_claim;
platform_ops.free = NULL;
platform_ops.exit = of_exit;
- dt_ops.finddevice = of_finddevice;
- dt_ops.getprop = of_getprop;
- dt_ops.setprop = of_setprop;
- dt_ops.translate_addr = NULL;
-
- console_ops.open = of_console_open;
- console_ops.write = of_console_write;
- console_ops.edit_cmdline = NULL;
- console_ops.close = NULL;
- console_ops.data = NULL;
+ of_tree_init();
+ of_console_init();
- prom = (int (*)(void *))promptr;
return 0;
}
diff --git a/arch/powerpc/boot/of.h b/arch/powerpc/boot/of.h
new file mode 100644
index 0000000..0828643
--- /dev/null
+++ b/arch/powerpc/boot/of.h
@@ -0,0 +1,29 @@
+/*
+ * Copyright (C) Paul Mackerras 1997.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+typedef void *ihandle;
+typedef void *phandle;
+
+/* In ofcall.c */
+void of_init(void *promptr);
+int call_prom(const char *service, int nargs, int nret, ...);
+int call_prom_ret(const char *service, int nargs, int nret,
+ unsigned int *rets, ...);
+void *of_claim(unsigned long virt, unsigned long size, unsigned long align);
+void of_exit(void);
+
+void *of_finddevice(const char *name);
+int of_getprop(const void *phandle, const char *name, void *buf,
+ const int buflen);
+int of_setprop(const void *phandle, const char *name, const void *buf,
+ const int buflen);
+void of_tree_init(void);
+
+/* In ofcons.c */
+void of_console_init(void);
diff --git a/arch/powerpc/boot/ofcall.c b/arch/powerpc/boot/ofcall.c
new file mode 100644
index 0000000..8086b60
--- /dev/null
+++ b/arch/powerpc/boot/ofcall.c
@@ -0,0 +1,200 @@
+/*
+ * Copyright (C) Paul Mackerras 1997.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#include <stdarg.h>
+#include <stddef.h>
+#include "types.h"
+#include "string.h"
+#include "stdio.h"
+#include "page.h"
+#include "ops.h"
+#include "of.h"
+
+int (*prom) (void *);
+
+
+void of_init(void *promptr)
+{
+ prom = (int (*)(void *))promptr;
+}
+
+int call_prom(const char *service, int nargs, int nret, ...)
+{
+ int i;
+ struct prom_args {
+ const char *service;
+ int nargs;
+ int nret;
+ unsigned int args[12];
+ } args;
+ va_list list;
+
+ args.service = service;
+ args.nargs = nargs;
+ args.nret = nret;
+
+ va_start(list, nret);
+ for (i = 0; i < nargs; i++)
+ args.args[i] = va_arg(list, unsigned int);
+ va_end(list);
+
+ for (i = 0; i < nret; i++)
+ args.args[nargs+i] = 0;
+
+ if (prom(&args) < 0)
+ return -1;
+
+ return (nret > 0)? args.args[nargs]: 0;
+}
+
+int call_prom_ret(const char *service, int nargs, int nret,
+ unsigned int *rets, ...)
+{
+ int i;
+ struct prom_args {
+ const char *service;
+ int nargs;
+ int nret;
+ unsigned int args[12];
+ } args;
+ va_list list;
+
+ args.service = service;
+ args.nargs = nargs;
+ args.nret = nret;
+
+ va_start(list, rets);
+ for (i = 0; i < nargs; i++)
+ args.args[i] = va_arg(list, unsigned int);
+ va_end(list);
+
+ for (i = 0; i < nret; i++)
+ args.args[nargs+i] = 0;
+
+ if (prom(&args) < 0)
+ return -1;
+
+ if (rets != (void *) 0)
+ for (i = 1; i < nret; ++i)
+ rets[i-1] = args.args[nargs+i];
+
+ return (nret > 0)? args.args[nargs]: 0;
+}
+
+/*
+ * Older OF's require that when claiming a specific range of addresses,
+ * we claim the physical space in the /memory node and the virtual
+ * space in the chosen mmu node, and then do a map operation to
+ * map virtual to physical.
+ */
+static int need_map = -1;
+static ihandle chosen_mmu;
+static phandle memory;
+
+/* returns true if s2 is a prefix of s1 */
+static int string_match(const char *s1, const char *s2)
+{
+ for (; *s2; ++s2)
+ if (*s1++ != *s2)
+ return 0;
+ return 1;
+}
+
+static int check_of_version(void)
+{
+ phandle oprom, chosen;
+ char version[64];
+
+ oprom = finddevice("/openprom");
+ if (oprom == (phandle) -1)
+ return 0;
+ if (getprop(oprom, "model", version, sizeof(version)) <= 0)
+ return 0;
+ version[sizeof(version)-1] = 0;
+ printf("OF version = '%s'\r\n", version);
+ if (!string_match(version, "Open Firmware, 1.")
+ && !string_match(version, "FirmWorks,3."))
+ return 0;
+ chosen = finddevice("/chosen");
+ if (chosen == (phandle) -1) {
+ chosen = finddevice("/chosen@0");
+ if (chosen == (phandle) -1) {
+ printf("no chosen\n");
+ return 0;
+ }
+ }
+ if (getprop(chosen, "mmu", &chosen_mmu, sizeof(chosen_mmu)) <= 0) {
+ printf("no mmu\n");
+ return 0;
+ }
+ memory = (ihandle) call_prom("open", 1, 1, "/memory");
+ if (memory == (ihandle) -1) {
+ memory = (ihandle) call_prom("open", 1, 1, "/memory@0");
+ if (memory == (ihandle) -1) {
+ printf("no memory node\n");
+ return 0;
+ }
+ }
+ printf("old OF detected\r\n");
+ return 1;
+}
+
+void *of_claim(unsigned long virt, unsigned long size, unsigned long align)
+{
+ int ret;
+ unsigned int result;
+
+ if (need_map < 0)
+ need_map = check_of_version();
+ if (align || !need_map)
+ return (void *) call_prom("claim", 3, 1, virt, size, align);
+
+ ret = call_prom_ret("call-method", 5, 2, &result, "claim", memory,
+ align, size, virt);
+ if (ret != 0 || result == -1)
+ return (void *) -1;
+ ret = call_prom_ret("call-method", 5, 2, &result, "claim", chosen_mmu,
+ align, size, virt);
+ /* 0x12 == coherent + read/write */
+ ret = call_prom("call-method", 6, 1, "map", chosen_mmu,
+ 0x12, size, virt, virt);
+ return (void *) virt;
+}
+
+void of_exit(void)
+{
+ call_prom("exit", 0, 0);
+}
+
+/*
+ * OF device tree routines
+ */
+void *of_finddevice(const char *name)
+{
+ return (phandle) call_prom("finddevice", 1, 1, name);
+}
+
+int of_getprop(const void *phandle, const char *name, void *buf,
+ const int buflen)
+{
+ return call_prom("getprop", 4, 1, phandle, name, buf, buflen);
+}
+
+int of_setprop(const void *phandle, const char *name, const void *buf,
+ const int buflen)
+{
+ return call_prom("setprop", 4, 1, phandle, name, buf, buflen);
+}
+
+void of_tree_init(void)
+{
+ dt_ops.finddevice = of_finddevice;
+ dt_ops.getprop = of_getprop;
+ dt_ops.setprop = of_setprop;
+ dt_ops.translate_addr = NULL;
+}
diff --git a/arch/powerpc/boot/ofcons.c b/arch/powerpc/boot/ofcons.c
new file mode 100644
index 0000000..5c76734
--- /dev/null
+++ b/arch/powerpc/boot/ofcons.c
@@ -0,0 +1,50 @@
+/*
+ * Copyright (C) Paul Mackerras 1997.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+#include <stdarg.h>
+#include <stddef.h>
+#include "types.h"
+#include "elf.h"
+#include "string.h"
+#include "stdio.h"
+#include "page.h"
+#include "ops.h"
+#include "of.h"
+
+/*
+ * OF console routines
+ */
+static void *of_stdout_handle;
+
+static int of_console_open(void)
+{
+ void *devp;
+
+ if (((devp = of_finddevice("/chosen")) != NULL)
+ && (of_getprop(devp, "stdout", &of_stdout_handle,
+ sizeof(of_stdout_handle))
+ == sizeof(of_stdout_handle)))
+ return 0;
+
+ return -1;
+}
+
+static void of_console_write(char *buf, int len)
+{
+ call_prom("write", 3, 1, of_stdout_handle, buf, len);
+}
+
+void of_console_init(void)
+{
+ console_ops.open = of_console_open;
+ console_ops.write = of_console_write;
+ console_ops.edit_cmdline = NULL;
+ console_ops.close = NULL;
+ console_ops.data = NULL;
+
+}
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index eab7318..debb02b 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -179,11 +179,11 @@ if [ -z "$cacheit" ]; then
fi
if [ -n "$initrd" ]; then
- addsec $tmp "$initrd" initrd
+ addsec $tmp "$initrd" $isection
fi
if [ -n "$dtb" ]; then
- addsec $tmp "$dtb" dtb
+ addsec $tmp "$dtb" .kernel:dtb
fi
if [ "$platform" != "miboot" ]; then
diff --git a/arch/powerpc/boot/zImage.lds.S b/arch/powerpc/boot/zImage.lds.S
index 4b6bb3f..4be3c64 100644
--- a/arch/powerpc/boot/zImage.lds.S
+++ b/arch/powerpc/boot/zImage.lds.S
@@ -21,6 +21,11 @@ SECTIONS
__got2_end = .;
}
+ . = ALIGN(8);
+ _dtb_start = .;
+ .kernel:dtb : { *(.kernel:dtb) }
+ _dtb_end = .;
+
. = ALIGN(4096);
_vmlinux_start = .;
.kernel:vmlinux.strip : { *(.kernel:vmlinux.strip) }
^ permalink raw reply related
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Paul Mackerras @ 2006-10-05 0:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <1160005019.5887.30.camel@localhost.localdomain>
Benjamin Herrenschmidt writes:
> > It's the 'or not' part that I am worried about. Things like
> > you mention above make sense. I'm starting to worry about
> > some of this other stuff, and the bscr example is what
> > woke me up :-) I think that's an example of things that
> > should be considered not necessary.
>
> I haven't looked at this specific example. I'll try to have a look
> later. I jumped into the discussion pointed by somebody else :)
That one was interesting - the bcsr was being referenced from an
ethernet driver that looked to me like it would be useful on any board
based on an 836x chip (I think). Yet it was claimed that the bcsr was
so specific and unique to each board that there was no point putting
it in the device tree - which implies that we would have to have a
separate lump of code in the tree to drive it for every single
board. :P I asked why the ethernet driver was accessing it directly
if that was the case, but didn't get an answer (well, only an indirect
answer in that the bcsr access code got removed from the ethernet
driver).
Paul.
^ permalink raw reply
* Re: [PATCH 1/4]: Spidernet stop queue when queue is full
From: Linas Vepstas @ 2006-10-05 0:06 UTC (permalink / raw)
To: Arnd Bergmann
Cc: akpm, jeff, netdev, James K Lewis, linux-kernel, linuxppc-dev
In-Reply-To: <200610040019.43028.arnd@arndb.de>
On Wed, Oct 04, 2006 at 12:19:42AM +0200, Arnd Bergmann wrote:
> On Tuesday 03 October 2006 22:57, Linas Vepstas wrote:
> > result = NETDEV_TX_LOCKED;
>
> Hmm, this looks a little strange to me.
Right. This was left-over cruft from back when.
I'll fix this and resend the whole series tommorrow or friday,
I've got a few more minor performnace tweaks, an implementation
of NETIF_F_SG, and another fix or two, etc.
--linas
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Benjamin Herrenschmidt @ 2006-10-05 0:08 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <17700.19414.724178.711359@cargo.ozlabs.ibm.com>
On Thu, 2006-10-05 at 10:03 +1000, Paul Mackerras wrote:
> Benjamin Herrenschmidt writes:
>
> > > It's the 'or not' part that I am worried about. Things like
> > > you mention above make sense. I'm starting to worry about
> > > some of this other stuff, and the bscr example is what
> > > woke me up :-) I think that's an example of things that
> > > should be considered not necessary.
> >
> > I haven't looked at this specific example. I'll try to have a look
> > later. I jumped into the discussion pointed by somebody else :)
>
> That one was interesting - the bcsr was being referenced from an
> ethernet driver that looked to me like it would be useful on any board
> based on an 836x chip (I think). Yet it was claimed that the bcsr was
> so specific and unique to each board that there was no point putting
> it in the device tree - which implies that we would have to have a
> separate lump of code in the tree to drive it for every single
> board. :P I asked why the ethernet driver was accessing it directly
> if that was the case, but didn't get an answer (well, only an indirect
> answer in that the bcsr access code got removed from the ethernet
> driver).
Well, feature calls might be the answer there... at least to move the
problem out of the driver to the platform code. They are after all just
a way to do random calls into the BSP from drivers, though they have
some issues too (you gotta hope you are running the right platform code
that understands your calls, in which case, why not just call an
exported function ...)
Ben.
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Vitaly Bordug @ 2006-10-05 0:16 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <17700.19414.724178.711359@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2142 bytes --]
On Thu, 5 Oct 2006 10:03:34 +1000
Paul Mackerras wrote:
> Benjamin Herrenschmidt writes:
>
> > > It's the 'or not' part that I am worried about. Things like
> > > you mention above make sense. I'm starting to worry about
> > > some of this other stuff, and the bscr example is what
> > > woke me up :-) I think that's an example of things that
> > > should be considered not necessary.
> >
> > I haven't looked at this specific example. I'll try to have a look
> > later. I jumped into the discussion pointed by somebody else :)
>
> That one was interesting - the bcsr was being referenced from an
> ethernet driver that looked to me like it would be useful on any board
> based on an 836x chip (I think). Yet it was claimed that the bcsr was
> so specific and unique to each board that there was no point putting
> it in the device tree - which implies that we would have to have a
> separate lump of code in the tree to drive it for every single
> board. :P I asked why the ethernet driver was accessing it directly
> if that was the case, but didn't get an answer (well, only an indirect
> answer in that the bcsr access code got removed from the ethernet
> driver).
>
Well that's because accessing bcsr in generic code is just odd. Yes, there are some places with
such a stuff still. bcsr is something like a sw jumper to enable/disable stuff, configure things, etc.
which may vary up to the hw design even if it's following the reference closely.
It's unique across the boards, and should be touched in BSP code only to keep the base sane.
Such a thing in the eth driver directly was sort of "nice" because takes care of enabling network "physically"
on board. For the same aim, I used to have board-specific callback to set up some bits if needed(speaking about
fs_enet/ppc). IOW, upon network driver init, it triggers callback function (passed in there via platform data) that's intended to do the bsp setup (or may be unset if nothing needed). In powerpc, only sane solution seems to be Dan's proposed
feature_call thing. I wish I'd have some time for that ...
Thanks,
-Vitaly
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Paul Mackerras @ 2006-10-05 0:27 UTC (permalink / raw)
To: Dan Malek; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <2867EA41-5135-43F7-9873-044C617EAC1B@embeddedalley.com>
Dan Malek writes:
> I'm not against using the device tree (or platform data
> or #defines) when it's appropriate to do so. I think our
> obsession to represent everything there is what is
> creating the complexity. If a #define in a board
> specific port file makes sense, then just do that,
> even if it is a BSCR address.
So, where this discussion started was that I saw an ioremap in an
ethernet driver using a physical address defined with #define, and I
said "that should go in the device tree". And I would still say that
if the ioremap was still there, since the driver is one that is useful
across a range of boards and chips.
My other point would be that what you say is valid *until* the
hardware engineers come to you and say "we're doing rev 2 of the
board, and we had to move the BCSR a bit. That's OK with you, isn't
it?".
If you have the BCSR address in the device tree, you don't even need
to recompile your kernel. You can just copy your board.dts to
board-rev2.dts, change the address in there, and rerun the wrapper
script to create the flash image to put on the new board. Or if you
are using a bootloader that knows how to supply a device-tree blob,
you just put board-rev2.dtb into flash along with your existing kernel
image.
Paul.
^ permalink raw reply
* Re: [PATCH] uninorth: Add module param 'aperture' for aperture size
From: Benjamin Herrenschmidt @ 2006-10-05 1:09 UTC (permalink / raw)
To: Michel Dänzer; +Cc: Dave Jones, linuxppc-dev
In-Reply-To: <1159966604.23084.236.camel@thor.lorrainebruecke.local>
On Wed, 2006-10-04 at 14:56 +0200, Michel Dänzer wrote:
> In contrast to most if not all PC BIOSes, OpenFirmware (OF) on PowerMacs with
> UniNorth bridges does not allow changing the aperture size. The size set up by
> OF is usually 16 MB, which is too low for graphics intensive environments.
> Hence, add a module parameter that allows changing the aperture size at driver
> initialization time. When the parameter is not specified, the default is 32 MB.
>
> Signed-off-by: Michel Dänzer <michel@tungstengraphics.com>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
(it should probably go in 2.6.19, patch has been around for some time)
> ---
>
> Reversed a 'value == variable' test, as suggested by Andreas Schwab (thanks!).
>
> drivers/char/agp/uninorth-agp.c | 54 +++++++++++++++++++++++++--------------
> 1 files changed, 35 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/char/agp/uninorth-agp.c b/drivers/char/agp/uninorth-agp.c
> index 78c8cb2..c2b6f7d 100644
> --- a/drivers/char/agp/uninorth-agp.c
> +++ b/drivers/char/agp/uninorth-agp.c
> @@ -27,32 +27,42 @@ #include "agp.h"
> static int uninorth_rev;
> static int is_u3;
>
> +static char __devinitdata *aperture = NULL;
>
> static int uninorth_fetch_size(void)
> {
> - int i;
> - u32 temp;
> - struct aper_size_info_32 *values;
> -
> - pci_read_config_dword(agp_bridge->dev, UNI_N_CFG_GART_BASE, &temp);
> - temp &= ~(0xfffff000);
> - values = A_SIZE_32(agp_bridge->driver->aperture_sizes);
> -
> - for (i = 0; i < agp_bridge->driver->num_aperture_sizes; i++) {
> - if (temp == values[i].size_value) {
> - agp_bridge->previous_size =
> - agp_bridge->current_size = (void *) (values + i);
> - agp_bridge->aperture_size_idx = i;
> - return values[i].size;
> + int i, size = 0;
> + struct aper_size_info_32 *values =
> + A_SIZE_32(agp_bridge->driver->aperture_sizes);
> +
> + if (aperture) {
> + char *save = aperture;
> +
> + size = memparse(aperture, &aperture) >> 20;
> + aperture = save;
> +
> + for (i = 0; i < agp_bridge->driver->num_aperture_sizes; i++)
> + if (size == values[i].size)
> + break;
> +
> + if (i == agp_bridge->driver->num_aperture_sizes) {
> + printk(KERN_ERR PFX "Invalid aperture size, using"
> + " default\n");
> + size = 0;
> + aperture = NULL;
> }
> }
>
> - agp_bridge->previous_size =
> - agp_bridge->current_size = (void *) (values + 1);
> - agp_bridge->aperture_size_idx = 1;
> - return values[1].size;
> + if (!size) {
> + for (i = 0; i < agp_bridge->driver->num_aperture_sizes; i++)
> + if (values[i].size == 32)
> + break;
> + }
>
> - return 0;
> + agp_bridge->previous_size =
> + agp_bridge->current_size = (void *)(values + i);
> + agp_bridge->aperture_size_idx = i;
> + return values[i].size;
> }
>
> static void uninorth_tlbflush(struct agp_memory *mem)
> @@ -668,5 +678,11 @@ static void __exit agp_uninorth_cleanup(
> module_init(agp_uninorth_init);
> module_exit(agp_uninorth_cleanup);
>
> +module_param(aperture, charp, 0);
> +MODULE_PARM_DESC(aperture,
> + "Aperture size, must be power of two between 4MB and an\n"
> + "\t\tupper limit specific to the UniNorth revision.\n"
> + "\t\tDefault: 32M");
> +
> MODULE_AUTHOR("Ben Herrenschmidt & Paul Mackerras");
> MODULE_LICENSE("GPL");
> --
> 1.4.2.1
>
>
> --
> Earthling Michel Dänzer | http://tungstengraphics.com
> Libre software enthusiast | Debian, X and DRI developer
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] linux,tce-size property is 32 bits
From: Nathan Lynch @ 2006-10-05 3:28 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, matthltc
The "linux,tce-size" property is only 32 bits (see
prom_initialize_tce_table() in arch/powerpc/kernel/prom_init.c).
Treating it as an unsigned long in iommu_table_setparms() leads to
access beyond the end of the property's buffer, so we pass garbage to
the memset() in that function.
[boot]0020 XICS Init
i8259 legacy interrupt controller initialized
[boot]0021 XICS Done
PID hash table entries: 4096 (order: 12, 32768 bytes)
cpu 0x0: Vector: 300 (Data Access) at [c0000000fe783850]
pc: c000000000035e90: .memset+0x60/0xfc
lr: c000000000044fa4: .iommu_table_setparms+0xb0/0x158
sp: c0000000fe783ad0
msr: 9000000000009032
dar: c000000100000000
dsisr: 42010000
current = 0xc00000000450e810
paca = 0xc000000000411580
pid = 1, comm = swapper
enter ? for help
[link register ] c000000000044fa4 .iommu_table_setparms+0xb0/0x158
[c0000000fe783ad0] c000000000044f4c .iommu_table_setparms+0x58/0x158
(unreliable)
[c0000000fe783b70] c00000000004529c
.iommu_bus_setup_pSeries+0x1c4/0x254
[c0000000fe783c00] c00000000002b8ac .do_bus_setup+0x3c/0xe4
[c0000000fe783c80] c00000000002c924 .pcibios_fixup_bus+0x64/0xd8
[c0000000fe783d00] c0000000001a2d5c .pci_scan_child_bus+0x6c/0x10c
[c0000000fe783da0] c00000000002be28 .scan_phb+0x17c/0x1b4
[c0000000fe783e40] c0000000003cfa00 .pcibios_init+0x58/0x19c
[c0000000fe783ec0] c0000000000094b4 .init+0x1e8/0x3d8
[c0000000fe783f90] c000000000026e54 .kernel_thread+0x4c/0x68
Signed-off-by: Nathan Lynch <ntl@pobox.com>
---
I believe this is a regression since 2.6.18, so please push for
inclusion in 2.6.19.
--- linux-2.6.git.orig/arch/powerpc/platforms/pseries/iommu.c
+++ linux-2.6.git/arch/powerpc/platforms/pseries/iommu.c
@@ -267,7 +267,8 @@ static void iommu_table_setparms(struct
struct iommu_table *tbl)
{
struct device_node *node;
- const unsigned long *basep, *sizep;
+ const unsigned long *basep;
+ const u32 *sizep;
node = (struct device_node *)phb->arch_data;
^ permalink raw reply
* [PATCH] powerpc: Fix zImage decompress location
From: Benjamin Herrenschmidt @ 2006-10-05 4:18 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
The zImage wrapper has a "hack" that force the decompression to happen
above 20Mb for 64 bits kernels, to work around issues with some
firmwares on the field. However, the new wrapper has a bug which makes
that hack not work properly. This fixes it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-work/arch/powerpc/boot/of.c
===================================================================
--- linux-work.orig/arch/powerpc/boot/of.c 2006-10-03 12:41:02.000000000 +1000
+++ linux-work/arch/powerpc/boot/of.c 2006-10-05 13:52:29.000000000 +1000
@@ -176,12 +176,9 @@ static void *claim(unsigned long virt, u
static void *of_try_claim(u32 size)
{
unsigned long addr = 0;
- static u8 first_time = 1;
- if (first_time) {
+ if (claim_base == 0)
claim_base = _ALIGN_UP((unsigned long)_end, ONE_MB);
- first_time = 0;
- }
for(; claim_base < RAM_END; claim_base += ONE_MB) {
#ifdef DEBUG
^ permalink raw reply
* [PATCH] powerpc: Enable DEEPNAP power savings mode on 970MP
From: Olof Johansson @ 2006-10-05 4:41 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, linux-kernel
Hi,
Without this patch, on an idle system I get:
cpu-power-0:21.638
cpu-power-1:27.102
cpu-power-2:29.343
cpu-power-3:25.784
Total: 103.8W
With this patch:
cpu-power-0:11.730
cpu-power-1:17.185
cpu-power-2:18.547
cpu-power-3:17.528
Total: 65.0W
If I lower HZ to 100, I can get it as low as:
cpu-power-0:10.938
cpu-power-1:16.021
cpu-power-2:17.245
cpu-power-3:16.145
Total: 60.2W
Another (older) Quad G5 went from 54W to 39W at HZ=250.
Coming back out of Deep Nap takes 40-70 cycles longer than coming back
from just Nap (which already takes quite a while). I don't think it'll
be a performance issue (interrupt latency on an idle system), but in
case someone does measurements feel free to report them.
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: linux-2.6/arch/powerpc/kernel/cpu_setup_ppc970.S
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/cpu_setup_ppc970.S
+++ linux-2.6/arch/powerpc/kernel/cpu_setup_ppc970.S
@@ -83,6 +83,22 @@ _GLOBAL(__setup_cpu_ppc970)
rldimi r0,r11,52,8 /* set NAP and DPM */
li r11,0
rldimi r0,r11,32,31 /* clear EN_ATTN */
+ b load_hids /* Jump to shared code */
+
+
+_GLOBAL(__setup_cpu_ppc970MP)
+ /* Do nothing if not running in HV mode */
+ mfmsr r0
+ rldicl. r0,r0,4,63
+ beqlr
+
+ mfspr r0,SPRN_HID0
+ li r11,0x15 /* clear DOZE and SLEEP */
+ rldimi r0,r11,52,6 /* set DEEPNAP, NAP and DPM */
+ li r11,0
+ rldimi r0,r11,32,31 /* clear EN_ATTN */
+
+load_hids:
mtspr SPRN_HID0,r0
mfspr r0,SPRN_HID0
mfspr r0,SPRN_HID0
Index: linux-2.6/arch/powerpc/kernel/cputable.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/cputable.c
+++ linux-2.6/arch/powerpc/kernel/cputable.c
@@ -41,6 +41,7 @@ extern void __setup_cpu_745x(unsigned lo
#endif /* CONFIG_PPC32 */
#ifdef CONFIG_PPC64
extern void __setup_cpu_ppc970(unsigned long offset, struct cpu_spec* spec);
+extern void __setup_cpu_ppc970MP(unsigned long offset, struct cpu_spec* spec);
extern void __restore_cpu_ppc970(void);
#endif /* CONFIG_PPC64 */
@@ -221,7 +222,7 @@ struct cpu_spec cpu_specs[] = {
.icache_bsize = 128,
.dcache_bsize = 128,
.num_pmcs = 8,
- .cpu_setup = __setup_cpu_ppc970,
+ .cpu_setup = __setup_cpu_ppc970MP,
.cpu_restore = __restore_cpu_ppc970,
.oprofile_cpu_type = "ppc64/970",
.oprofile_type = PPC_OPROFILE_POWER4,
^ permalink raw reply
* [PATCH] powerpc: make U4 PCIe work
From: Benjamin Herrenschmidt @ 2006-10-05 4:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
The Maple support code was missing code for U4/CPC945 PCIe. This adds
it, enabling it to work on tigerwood boards, and possibly also js21
using SLOF.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
Patch just missed the merge window but should go in anyway. It's been
hanging around for a while, I just forgot about it, and it's fairly
harmless.
Index: linux-work/arch/powerpc/platforms/maple/pci.c
===================================================================
--- linux-work.orig/arch/powerpc/platforms/maple/pci.c 2006-10-05 14:14:28.000000000 +1000
+++ linux-work/arch/powerpc/platforms/maple/pci.c 2006-10-05 14:29:30.000000000 +1000
@@ -8,7 +8,7 @@
* 2 of the License, or (at your option) any later version.
*/
-#define DEBUG
+#undef DEBUG
#include <linux/kernel.h>
#include <linux/pci.h>
@@ -16,6 +16,7 @@
#include <linux/string.h>
#include <linux/init.h>
#include <linux/bootmem.h>
+#include <linux/irq.h>
#include <asm/sections.h>
#include <asm/io.h>
@@ -33,7 +34,7 @@
#define DBG(x...)
#endif
-static struct pci_controller *u3_agp, *u3_ht;
+static struct pci_controller *u3_agp, *u3_ht, *u4_pcie;
static int __init fixup_one_level_bus_range(struct device_node *node, int higher)
{
@@ -287,6 +288,110 @@ static struct pci_ops u3_ht_pci_ops =
u3_ht_write_config
};
+#define U4_PCIE_CFA0(devfn, off) \
+ ((1 << ((unsigned int)PCI_SLOT(dev_fn))) \
+ | (((unsigned int)PCI_FUNC(dev_fn)) << 8) \
+ | ((((unsigned int)(off)) >> 8) << 28) \
+ | (((unsigned int)(off)) & 0xfcU))
+
+#define U4_PCIE_CFA1(bus, devfn, off) \
+ ((((unsigned int)(bus)) << 16) \
+ |(((unsigned int)(devfn)) << 8) \
+ | ((((unsigned int)(off)) >> 8) << 28) \
+ |(((unsigned int)(off)) & 0xfcU) \
+ |1UL)
+
+static volatile void __iomem *u4_pcie_cfg_access(struct pci_controller* hose,
+ u8 bus, u8 dev_fn, int offset)
+{
+ unsigned int caddr;
+
+ if (bus == hose->first_busno) {
+ caddr = U4_PCIE_CFA0(dev_fn, offset);
+ } else
+ caddr = U4_PCIE_CFA1(bus, dev_fn, offset);
+
+ /* Uninorth will return garbage if we don't read back the value ! */
+ do {
+ out_le32(hose->cfg_addr, caddr);
+ } while (in_le32(hose->cfg_addr) != caddr);
+
+ offset &= 0x03;
+ return hose->cfg_data + offset;
+}
+
+static int u4_pcie_read_config(struct pci_bus *bus, unsigned int devfn,
+ int offset, int len, u32 *val)
+{
+ struct pci_controller *hose;
+ volatile void __iomem *addr;
+
+ hose = pci_bus_to_host(bus);
+ if (hose == NULL)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+ if (offset >= 0x1000)
+ return PCIBIOS_BAD_REGISTER_NUMBER;
+ addr = u4_pcie_cfg_access(hose, bus->number, devfn, offset);
+ if (!addr)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+ /*
+ * Note: the caller has already checked that offset is
+ * suitably aligned and that len is 1, 2 or 4.
+ */
+ switch (len) {
+ case 1:
+ *val = in_8(addr);
+ break;
+ case 2:
+ *val = in_le16(addr);
+ break;
+ default:
+ *val = in_le32(addr);
+ break;
+ }
+ return PCIBIOS_SUCCESSFUL;
+}
+static int u4_pcie_write_config(struct pci_bus *bus, unsigned int devfn,
+ int offset, int len, u32 val)
+{
+ struct pci_controller *hose;
+ volatile void __iomem *addr;
+
+ hose = pci_bus_to_host(bus);
+ if (hose == NULL)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+ if (offset >= 0x1000)
+ return PCIBIOS_BAD_REGISTER_NUMBER;
+ addr = u4_pcie_cfg_access(hose, bus->number, devfn, offset);
+ if (!addr)
+ return PCIBIOS_DEVICE_NOT_FOUND;
+ /*
+ * Note: the caller has already checked that offset is
+ * suitably aligned and that len is 1, 2 or 4.
+ */
+ switch (len) {
+ case 1:
+ out_8(addr, val);
+ (void) in_8(addr);
+ break;
+ case 2:
+ out_le16(addr, val);
+ (void) in_le16(addr);
+ break;
+ default:
+ out_le32(addr, val);
+ (void) in_le32(addr);
+ break;
+ }
+ return PCIBIOS_SUCCESSFUL;
+}
+
+static struct pci_ops u4_pcie_pci_ops =
+{
+ u4_pcie_read_config,
+ u4_pcie_write_config
+};
+
static void __init setup_u3_agp(struct pci_controller* hose)
{
/* On G5, we move AGP up to high bus number so we don't need
@@ -307,6 +412,26 @@ static void __init setup_u3_agp(struct p
u3_agp = hose;
}
+static void __init setup_u4_pcie(struct pci_controller* hose)
+{
+ /* We currently only implement the "non-atomic" config space, to
+ * be optimised later.
+ */
+ hose->ops = &u4_pcie_pci_ops;
+ hose->cfg_addr = ioremap(0xf0000000 + 0x800000, 0x1000);
+ hose->cfg_data = ioremap(0xf0000000 + 0xc00000, 0x1000);
+
+ /* The bus contains a bridge from root -> device, we need to
+ * make it visible on bus 0 so that we pick the right type
+ * of config cycles. If we didn't, we would have to force all
+ * config cycles to be type 1. So we override the "bus-range"
+ * property here
+ */
+ hose->first_busno = 0x00;
+ hose->last_busno = 0xff;
+ u4_pcie = hose;
+}
+
static void __init setup_u3_ht(struct pci_controller* hose)
{
hose->ops = &u3_ht_pci_ops;
@@ -354,6 +479,10 @@ static int __init add_bridge(struct devi
setup_u3_ht(hose);
disp_name = "U3-HT";
primary = 1;
+ } else if (device_is_compatible(dev, "u4-pcie")) {
+ setup_u4_pcie(hose);
+ disp_name = "U4-PCIE";
+ primary = 0;
}
printk(KERN_INFO "Found %s PCI host bridge. Firmware bus number: %d->%d\n",
disp_name, hose->first_busno, hose->last_busno);
@@ -361,7 +490,6 @@ static int __init add_bridge(struct devi
/* Interpret the "ranges" property */
/* This also maps the I/O region and sets isa_io/mem_base */
pci_process_bridge_OF_ranges(hose, dev, primary);
- pci_setup_phb_io(hose, primary);
/* Fixup "bus-range" OF property */
fixup_bus_range(dev);
@@ -376,8 +504,17 @@ void __init maple_pcibios_fixup(void)
DBG(" -> maple_pcibios_fixup\n");
- for_each_pci_dev(dev)
- pci_read_irq_line(dev);
+ for_each_pci_dev(dev) {
+ /* Fixup IRQ for PCIe host */
+ if (u4_pcie != NULL && dev->bus->number == 0 &&
+ pci_bus_to_host(dev->bus) == u4_pcie) {
+ printk(KERN_DEBUG "Fixup U4 PCIe IRQ\n");
+ dev->irq = irq_create_mapping(NULL, 1);
+ if (dev->irq != NO_IRQ)
+ set_irq_type(dev->irq, IRQ_TYPE_LEVEL_LOW);
+ } else
+ pci_read_irq_line(dev);
+ }
DBG(" <- maple_pcibios_fixup\n");
}
@@ -388,8 +525,10 @@ static void __init maple_fixup_phb_resou
list_for_each_entry_safe(hose, tmp, &hose_list, list_node) {
unsigned long offset = (unsigned long)hose->io_base_virt - pci_io_base;
+
hose->io_resource.start += offset;
hose->io_resource.end += offset;
+
printk(KERN_INFO "PCI Host %d, io start: %llx; io end: %llx\n",
hose->global_number,
(unsigned long long)hose->io_resource.start,
@@ -431,6 +570,19 @@ void __init maple_pci_init(void)
if (ht && add_bridge(ht) != 0)
of_node_put(ht);
+ /*
+ * We need to call pci_setup_phb_io for the HT bridge first
+ * so it gets the I/O port numbers starting at 0, and we
+ * need to call it for the AGP bridge after that so it gets
+ * small positive I/O port numbers.
+ */
+ if (u3_ht)
+ pci_setup_phb_io(u3_ht, 1);
+ if (u3_agp)
+ pci_setup_phb_io(u3_agp, 0);
+ if (u4_pcie)
+ pci_setup_phb_io(u4_pcie, 0);
+
/* Fixup the IO resources on our host bridges as the common code
* does it only for childs of the host bridges
*/
@@ -479,6 +631,9 @@ int maple_pci_get_legacy_ide_irq(struct
/* XXX: To remove once all firmwares are ok */
static void fixup_maple_ide(struct pci_dev* dev)
{
+ if (!machine_is(maple))
+ return;
+
#if 0 /* Enable this to enable IDE port 0 */
{
u8 v;
@@ -495,7 +650,7 @@ static void fixup_maple_ide(struct pci_d
dev->resource[4].start = 0xcc00;
dev->resource[4].end = 0xcc10;
#endif
-#if 1 /* Enable this to fixup IDE sense/polarity of irqs in IO-APICs */
+#if 0 /* Enable this to fixup IDE sense/polarity of irqs in IO-APICs */
{
struct pci_dev *apicdev;
u32 v;
^ permalink raw reply
* Re: [PATCH] powerpc: Enable DEEPNAP power savings mode on 970MP
From: Benjamin Herrenschmidt @ 2006-10-05 5:34 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, paulus, linux-kernel
In-Reply-To: <20061004234141.749b13fb@localhost.localdomain>
On Wed, 2006-10-04 at 23:41 -0500, Olof Johansson wrote:
> Hi,
>
> Without this patch, on an idle system I get:
>
> cpu-power-0:21.638
> cpu-power-1:27.102
> cpu-power-2:29.343
> cpu-power-3:25.784
> Total: 103.8W
>
> With this patch:
>
> cpu-power-0:11.730
> cpu-power-1:17.185
> cpu-power-2:18.547
> cpu-power-3:17.528
> Total: 65.0W
>
> If I lower HZ to 100, I can get it as low as:
>
> cpu-power-0:10.938
> cpu-power-1:16.021
> cpu-power-2:17.245
> cpu-power-3:16.145
> Total: 60.2W
>
> Another (older) Quad G5 went from 54W to 39W at HZ=250.
>
> Coming back out of Deep Nap takes 40-70 cycles longer than coming back
> from just Nap (which already takes quite a while). I don't think it'll
> be a performance issue (interrupt latency on an idle system), but in
> case someone does measurements feel free to report them.
Isn't deep nap supposed to only get entered from F/4 which we never
use ?
Ben confused...
>
> Signed-off-by: Olof Johansson <olof@lixom.net>
>
>
>
> Index: linux-2.6/arch/powerpc/kernel/cpu_setup_ppc970.S
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/kernel/cpu_setup_ppc970.S
> +++ linux-2.6/arch/powerpc/kernel/cpu_setup_ppc970.S
> @@ -83,6 +83,22 @@ _GLOBAL(__setup_cpu_ppc970)
> rldimi r0,r11,52,8 /* set NAP and DPM */
> li r11,0
> rldimi r0,r11,32,31 /* clear EN_ATTN */
> + b load_hids /* Jump to shared code */
> +
> +
> +_GLOBAL(__setup_cpu_ppc970MP)
> + /* Do nothing if not running in HV mode */
> + mfmsr r0
> + rldicl. r0,r0,4,63
> + beqlr
> +
> + mfspr r0,SPRN_HID0
> + li r11,0x15 /* clear DOZE and SLEEP */
> + rldimi r0,r11,52,6 /* set DEEPNAP, NAP and DPM */
> + li r11,0
> + rldimi r0,r11,32,31 /* clear EN_ATTN */
> +
> +load_hids:
> mtspr SPRN_HID0,r0
> mfspr r0,SPRN_HID0
> mfspr r0,SPRN_HID0
> Index: linux-2.6/arch/powerpc/kernel/cputable.c
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/kernel/cputable.c
> +++ linux-2.6/arch/powerpc/kernel/cputable.c
> @@ -41,6 +41,7 @@ extern void __setup_cpu_745x(unsigned lo
> #endif /* CONFIG_PPC32 */
> #ifdef CONFIG_PPC64
> extern void __setup_cpu_ppc970(unsigned long offset, struct cpu_spec* spec);
> +extern void __setup_cpu_ppc970MP(unsigned long offset, struct cpu_spec* spec);
> extern void __restore_cpu_ppc970(void);
> #endif /* CONFIG_PPC64 */
>
> @@ -221,7 +222,7 @@ struct cpu_spec cpu_specs[] = {
> .icache_bsize = 128,
> .dcache_bsize = 128,
> .num_pmcs = 8,
> - .cpu_setup = __setup_cpu_ppc970,
> + .cpu_setup = __setup_cpu_ppc970MP,
> .cpu_restore = __restore_cpu_ppc970,
> .oprofile_cpu_type = "ppc64/970",
> .oprofile_type = PPC_OPROFILE_POWER4,
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Eugene Surovegin @ 2006-10-05 6:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Olof Johansson, linuxppc-dev, Paul Mackerras
In-Reply-To: <1160005019.5887.30.camel@localhost.localdomain>
On Thu, Oct 05, 2006 at 09:36:59AM +1000, Benjamin Herrenschmidt wrote:
> Ugh ? Look at the #ifdef mess in ibm_emac...
Ugh?
I think you have to thank IBM/AMCC designers which keep changing bit
layout of some registers, sometimes just changing polarity for no
reason.
And with all due respect, Ben. Current ibm_emac despite of all "mess"
is actually usable in production environment, which cannot be said
about initial Armin version and second version you started but never
got time to actually finish.
--
Eugene
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Benjamin Herrenschmidt @ 2006-10-05 6:26 UTC (permalink / raw)
To: Eugene Surovegin; +Cc: Olof Johansson, linuxppc-dev, Paul Mackerras
In-Reply-To: <20061005062105.GA1985@gate.ebshome.net>
On Wed, 2006-10-04 at 23:21 -0700, Eugene Surovegin wrote:
> On Thu, Oct 05, 2006 at 09:36:59AM +1000, Benjamin Herrenschmidt wrote:
> > Ugh ? Look at the #ifdef mess in ibm_emac...
>
> Ugh?
>
> I think you have to thank IBM/AMCC designers which keep changing bit
> layout of some registers, sometimes just changing polarity for no
> reason.
>
> And with all due respect, Ben. Current ibm_emac despite of all "mess"
> is actually usable in production environment, which cannot be said
> about initial Armin version and second version you started but never
> got time to actually finish.
That second version was working fine... on the limited available
variations of EMAC back then.
Regarding the "mess", it's the whole #ifdef junk in there that is
driving me nuts and that I'll rip appart probably next week. A lot of
this could be soft-tests or the ifdefs could be resolved at Kconfig
instead of having a list of processors in 3 different headers if you
really want to compile the changes in rather than do soft-tests.
Ben.
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Eugene Surovegin @ 2006-10-05 6:29 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <17700.20834.792693.853677@cargo.ozlabs.ibm.com>
On Thu, Oct 05, 2006 at 10:27:14AM +1000, Paul Mackerras wrote:
> Dan Malek writes:
>
> > I'm not against using the device tree (or platform data
> > or #defines) when it's appropriate to do so. I think our
> > obsession to represent everything there is what is
> > creating the complexity. If a #define in a board
> > specific port file makes sense, then just do that,
> > even if it is a BSCR address.
>
> So, where this discussion started was that I saw an ioremap in an
> ethernet driver using a physical address defined with #define, and I
> said "that should go in the device tree". And I would still say that
> if the ioremap was still there, since the driver is one that is useful
> across a range of boards and chips.
>
> My other point would be that what you say is valid *until* the
> hardware engineers come to you and say "we're doing rev 2 of the
> board, and we had to move the BCSR a bit. That's OK with you, isn't
> it?".
>
> If you have the BCSR address in the device tree, you don't even need
> to recompile your kernel. You can just copy your board.dts to
> board-rev2.dts, change the address in there, and rerun the wrapper
> script to create the flash image to put on the new board. Or if you
> are using a bootloader that knows how to supply a device-tree blob,
> you just put board-rev2.dtb into flash along with your existing kernel
> image.
Paul,
it doesn't really matter if you have to rebuild a kernel or some
other blob and have it re-flashed in the actual board.
Having something in device tree doesn't change a simple fact that you
have to update some firmware component, be it boot code, kernel or
some dts blob. You still have to prepare new flash image, period.
--
Eugene
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Eugene Surovegin @ 2006-10-05 6:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Olof Johansson, linuxppc-dev, Paul Mackerras
In-Reply-To: <1160029594.22232.22.camel@localhost.localdomain>
On Thu, Oct 05, 2006 at 04:26:34PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2006-10-04 at 23:21 -0700, Eugene Surovegin wrote:
> > On Thu, Oct 05, 2006 at 09:36:59AM +1000, Benjamin Herrenschmidt wrote:
> > > Ugh ? Look at the #ifdef mess in ibm_emac...
> >
> > Ugh?
> >
> > I think you have to thank IBM/AMCC designers which keep changing bit
> > layout of some registers, sometimes just changing polarity for no
> > reason.
> >
> > And with all due respect, Ben. Current ibm_emac despite of all "mess"
> > is actually usable in production environment, which cannot be said
> > about initial Armin version and second version you started but never
> > got time to actually finish.
>
> That second version was working fine... on the limited available
> variations of EMAC back then.
No it wasn't. If it were I would have never wasted my time re-writing
this driver.
--
Eugene
^ permalink raw reply
* Re: [PATCH 10/11] Add MPC8360EMDS board support
From: Eugene Surovegin @ 2006-10-05 6:33 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Olof Johansson, linuxppc-dev, Paul Mackerras
In-Reply-To: <1160029594.22232.22.camel@localhost.localdomain>
On Thu, Oct 05, 2006 at 04:26:34PM +1000, Benjamin Herrenschmidt wrote:
>
> Regarding the "mess", it's the whole #ifdef junk in there that is
> driving me nuts and that I'll rip appart probably next week. A lot of
> this could be soft-tests or the ifdefs could be resolved at Kconfig
> instead of having a list of processors in 3 different headers if you
> really want to compile the changes in rather than do soft-tests.
Well, sent me changes for review, or become a maintainer, but this
time _real_ maintainer, not like last time when you touched this code.
--
Eugene
^ 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