* Re: Problem with OF interrupt parsing code
From: Gerhard Pircher @ 2007-10-03 7:43 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1191362607.22572.26.camel@pasglop>
-------- Original-Nachricht --------
> Datum: Wed, 03 Oct 2007 08:03:27 +1000
> Von: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> An: Gerhard Pircher <gerhard_pircher@gmx.net>
> CC: linuxppc-dev@ozlabs.org
> Betreff: Re: Problem with OF interrupt parsing code
>
> On Tue, 2007-10-02 at 14:38 +0200, Gerhard Pircher wrote:
> > I know that it's ugly, but the problem is how to distinguish the
> > boards. The only real difference I know of is the PCI interrupt
> > mapping. The northbridges chip revision for example is always the
> > same, but CPU type, amount of memory and PCI devices can appear in
> > all possible combinations. The firmware doesn't tell me, which board
> > the kernel is runnning on, so I would like to rely on this fall back
> > here until I get the chance to update the firmware (which is beyond
> > my control).
>
> And how does the firmware know ? There must be a strap somewhere...
>
> Ben.
Good question. I don't know. Anyway I changed the device tree based on
your comments and now it works (at least until the kernel deadlocks
somewhere else). :(
Gerhard
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* Re: Patches added to powerpc.git for-2.6.24 branch
From: Stephen Rothwell @ 2007-10-03 7:15 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18179.13902.936820.573996@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 629 bytes --]
On Wed, 3 Oct 2007 16:27:26 +1000 Paul Mackerras <paulus@samba.org> wrote:
>
> Stephen Rothwell (5):
> [POWERPC] Create and use CONFIG_WORD_SIZE
> [POWERPC] Remove debug printk from vio_bus_init
> [POWERPC] Simplify vio_bus_init a little for legacy iSeries
> [POWERPC] Make vio_bus_type static
> [POWERPC] Limit range of __init_ref_ok somewhat
Would you also consider:
[POWERPC] Prepare to remove of_platform_driver name
(http://patchwork.ozlabs.org/linuxppc/patch?id=13667)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Patches added to powerpc.git for-2.6.24 branch
From: Paul Mackerras @ 2007-10-03 6:27 UTC (permalink / raw)
To: linuxppc-dev
Adrian Bunk (1):
[POWERPC] Select proper defconfig for crosscompiles
Aristeu Rozanski (1):
[POWERPC] adbhid: Enable KEY_FN key reporting
Arnd Bergmann (3):
[POWERPC] add Kconfig option for optimizing for cell
[POWERPC] Move embedded6xx into multiplatform
[POWERPC] Fix pci domain detection
Benjamin Herrenschmidt (1):
[POWERPC] Fix platinumfb framebuffer
Cyrill Gorcunov (6):
[POWERPC] Sky Cpu and Nexus: code style improvement
[POWERPC] Sky Cpu and Nexus: include io.h
[POWERPC] Sky Cpu and Nexus: check for platform_get_resource retcode
[POWERPC] Sky Cpu and Nexus: check for create_proc_entry ret code
[POWERPC] Sky Cpu: use C99 style for struct init
[POWERPC] Sky Cpu and Nexus: use seq_file/single_open on proc interface
Dale Farnsworth (1):
[POWERPC] Add Marvell mv64x60 udbg putc/getc functions
David Woodhouse (1):
[POWERPC] Optionally use new device number for pmac_zilog
Domen Puncer (1):
[POWERPC] clk.h interface for platforms
Ed Swarthout (1):
[POWERPC] Add memory regions to the kcore list for 32-bit machines
Emil Medve (1):
[POWERPC] Fix build errors when BLOCK=n
Grant Likely (2):
[POWERPC] mpc8349: Add linux,network-index to ethernet nodes in device tree
[POWERPC] mpc5200: Add cuimage support for mpc5200 boards
Hugh Dickins (1):
[POWERPC] ppc64: support CONFIG_DEBUG_PREEMPT
Ishizaki Kou (5):
[POWERPC] Celleb: Move pause, kexec_cpu_down to beat.c
[POWERPC] Celleb: Support for Power/Reset buttons
[POWERPC] Celleb: New HTAB Guest OS Interface on Beat
[POWERPC] Celleb: Serial I/O update
[POWERPC] Celleb: update for PCI
Jeremy Kerr (1):
[POWERPC] cell: Don't cast the result of of_get_property()
Joachim Fenkes (1):
[POWERPC] ibmebus: More descriptive error return code in ibmebus_store_probe()
Jochen Friedrich (4):
[POWERPC] Fix copy'n'paste typo in commproc.c
[PPC] Fix cpm_dpram_addr returning phys mem instead of virt mem
[PPC] Compile fix for 8xx CPM Ehernet driver
[POWERPC] Fix cpm_uart driver
Linas Vepstas (2):
[POWERPC] pseries: device node status can be "ok" or "okay"
[POWERPC] Use alloc_maybe_bootmem() in pcibios_alloc_controller
Mark A. Greer (1):
[POWERPC] MAINTAINERS shouldn't reference linuxppc-embedded
Mathieu Desnoyers (1):
[POWERPC] Include pagemap.h in asm/powerpc/tlb.h
Meelis Roos (1):
[POWERPC] Fix ppc kernels after build-id addition
Michael Ellerman (8):
[POWERPC] Make sure to of_node_get() the result of pci_device_to_OF_node()
[POWERPC] Simplify error logic in u3msi_setup_msi_irqs()
[POWERPC] Simplify error logic in rtas_setup_msi_irqs()
[POWERPC] Simplify rtas_change_msi() error semantics
[POWERPC] Inline u3msi_compose_msi_msg()
[POWERPC] Store the base address in dcr_host_t
[POWERPC] Update mpic to use dcr_host_t.base
[POWERPC] Update axon_msi to use dcr_host_t.base
Mike Frysinger (1):
[POWERPC] Use __attribute__ in asm-powerpc
Milton Miller (2):
[POWERPC] boot: Record header bytes in gunzip_start
[POWERPC] boot: Simplify gunzip_finish
Olof Johansson (2):
[POWERPC] Support setting affinity for U3/U4 MSI sources
[POWERPC] Separate out legacy machine check exception parsers
Paul Mackerras (1):
[POWERPC] Disable power management for arch/ppc
Robert P. J. Day (1):
[POWERPC] Prevent direct inclusion of <asm/rwsem.h>.
Roland McGrath (2):
[POWERPC] Add CHECK_FULL_REGS in several places in ptrace code
[POWERPC] powerpc vDSO: install unstripped copies on disk
Satyam Sharma (1):
[POWERPC] Avoid pointless WARN_ON(irqs_disabled()) from panic codepath
Scott Wood (3):
[POWERPC] bootwrapper: Factor out dt_set_mac_address()
[POWERPC] bootwrapper: Add PlanetCore firmware support
[POWERPC] Make instruction dumping work in real mode
Stephen Rothwell (5):
[POWERPC] Create and use CONFIG_WORD_SIZE
[POWERPC] Remove debug printk from vio_bus_init
[POWERPC] Simplify vio_bus_init a little for legacy iSeries
[POWERPC] Make vio_bus_type static
[POWERPC] Limit range of __init_ref_ok somewhat
Tony Breeds (6):
[POWERPC] Convert define_machine(mpc885_ads) to C99 initializer syntax
[POWERPC] Implement {read,update}_persistent_clock
[POWERPC] Implement generic time of day clocksource for powerpc
[POWERPC] Fix panic in RTAS code
[POWERPC] Implement clockevents driver for powerpc
[POWERPC] Enable tickless idle and high res timers for powerpc
^ permalink raw reply
* dtc: Refactor Makefiles
From: David Gibson @ 2007-10-03 5:59 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
This patch makes a number of Makefile cleanups and improvements:
- We use more generic rules to invoke flex and bison, which is
useful for some of the other changes.
- We use the name dtc-lexer.lex.c for the flex output, instead
of the default lex.yy.c. That means less potential for confusion if
dtc is embedded into other projects (e.g. the kernel).
- We separate out a Makefile.dtc designed for embedding into
other projects, analagous to Makefile.libfdt.
- Makefile.libfdt is cleaned up to be more useful based on
some actual trial runs of embedding libfdt in the kernel bootwrapper.
- Versioning related rules and variables are collected into
one place in the Makefile.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/Makefile
===================================================================
--- dtc.orig/Makefile 2007-09-27 14:08:05.000000000 +1000
+++ dtc/Makefile 2007-09-27 14:32:49.000000000 +1000
@@ -15,40 +15,12 @@ EXTRAVERSION =
LOCAL_VERSION =
CONFIG_LOCALVERSION =
-DTC_VERSION = $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
-VERSION_FILE = version_gen.h
-
-CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
- else if [ -x /bin/bash ]; then echo /bin/bash; \
- else echo sh; fi ; fi)
-
-nullstring :=
-space := $(nullstring) # end of line
-
-localver_config = $(subst $(space),, $(string) \
- $(patsubst "%",%,$(CONFIG_LOCALVERSION)))
-
-localver_cmd = $(subst $(space),, $(string) \
- $(patsubst "%",%,$(LOCALVERSION)))
-
-localver_scm = $(shell $(CONFIG_SHELL) ./scripts/setlocalversion)
-localver_full = $(localver_config)$(localver_cmd)$(localver_scm)
-
-dtc_version = $(DTC_VERSION)$(localver_full)
-
-#
-# Contents of the generated version file.
-#
-define filechk_version
- (echo "#define DTC_VERSION \"DTC $(dtc_version)\""; )
-endef
-
-
CPPFLAGS = -I libfdt
CFLAGS = -Wall -g -Os
LDFLAGS = -Llibfdt
BISON = bison
+LEX = flex
INSTALL = /usr/bin/install
DESTDIR =
@@ -77,52 +49,107 @@ endif
all: dtc ftdump libfdt tests
+install: all
+ @$(VECHO) INSTALL
+ $(INSTALL) -d $(DESTDIR)$(BINDIR)
+ $(INSTALL) -m 755 dtc $(DESTDIR)$(BINDIR)
+ $(INSTALL) -d $(DESTDIR)$(LIBDIR)
+ $(INSTALL) -m 644 $(LIBFDT_LIB) $(DESTDIR)$(LIBDIR)
+ $(INSTALL) -d $(DESTDIR)$(INCLUDEDIR)
+ $(INSTALL) -m 644 $(LIBFDT_INCLUDES) $(DESTDIR)$(INCLUDEDIR)
+
#
-# Rules for dtc proper
+# Rules for versioning
#
-DTC_PROGS = dtc ftdump
-DTC_OBJS = dtc.o flattree.o fstree.o data.o livetree.o \
- srcpos.o treesource.o \
- dtc-parser.tab.o lex.yy.o
-DTC_DEPFILES = $(DTC_OBJS:%.o=%.d)
-BIN += dtc ftdump
+DTC_VERSION = $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
+VERSION_FILE = version_gen.h
-dtc-parser.tab.c dtc-parser.tab.h dtc-parser.output: dtc-parser.y
- @$(VECHO) BISON $@
- @$(VECHO) ---- Expect 2 s/r and 2 r/r. ----
- $(BISON) -d $<
+CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
+ else if [ -x /bin/bash ]; then echo /bin/bash; \
+ else echo sh; fi ; fi)
+
+nullstring :=
+space := $(nullstring) # end of line
+
+localver_config = $(subst $(space),, $(string) \
+ $(patsubst "%",%,$(CONFIG_LOCALVERSION)))
+
+localver_cmd = $(subst $(space),, $(string) \
+ $(patsubst "%",%,$(LOCALVERSION)))
+
+localver_scm = $(shell $(CONFIG_SHELL) ./scripts/setlocalversion)
+localver_full = $(localver_config)$(localver_cmd)$(localver_scm)
+
+dtc_version = $(DTC_VERSION)$(localver_full)
+
+# Contents of the generated version file.
+define filechk_version
+ (echo "#define DTC_VERSION \"DTC $(dtc_version)\""; )
+endef
+
+define filechk
+ set -e; \
+ echo ' CHK $@'; \
+ mkdir -p $(dir $@); \
+ $(filechk_$(1)) < $< > $@.tmp; \
+ if [ -r $@ ] && cmp -s $@ $@.tmp; then \
+ rm -f $@.tmp; \
+ else \
+ echo ' UPD $@'; \
+ mv -f $@.tmp $@; \
+ fi;
+endef
$(VERSION_FILE): Makefile FORCE
$(call filechk,version)
-lex.yy.c: dtc-lexer.l
- @$(VECHO) LEX $@
- $(LEX) $<
+#
+# Rules for dtc proper
+#
+include Makefile.dtc
+
+BIN += dtc
+
+# This stops make from generating the lex and bison output during
+# auto-dependency computation, but throwing them away as an
+# intermediate target and building them again "for real"
+.SECONDARY: $(DTC_GEN_SRCS)
dtc: $(DTC_OBJS)
+ifneq ($(DEPTARGETS),)
+-include $(DTC_OBJS:%.o=%.d)
+endif
+#
+# Rules for ftdump
+#
+BIN += ftdump
+
ftdump: ftdump.o
ifneq ($(DEPTARGETS),)
--include $(DTC_DEPFILES)
+-include ftdump.d
endif
-
#
# Rules for libfdt
#
-LIBFDT_PREFIX = libfdt/
+LIBFDT_objdir = libfdt
+LIBFDT_srcdir = libfdt
include libfdt/Makefile.libfdt
.PHONY: libfdt
libfdt: $(LIBFDT_LIB)
+$(LIBFDT_LIB): $(addprefix libfdt/,$(LIBFDT_OBJS))
+
libfdt_clean:
@$(VECHO) CLEAN "(libfdt)"
- rm -f $(LIBFDT_CLEANFILES)
+ rm -f $(addprefix libfdt/,$(STD_CLEANFILES))
+ rm -f $(addprefix libfdt/,$(LIBFDT_CLEANFILES))
ifneq ($(DEPTARGETS),)
--include $(LIBFDT_DEPFILES)
+-include $(LIBFDT_OBJS:%.o=%.d)
endif
#
@@ -131,38 +158,18 @@ endif
TESTS_PREFIX=tests/
include tests/Makefile.tests
-STD_CLEANFILES = *~ *.o *.d *.a *.i *.s core a.out
-GEN_CLEANFILES = $(VERSION_FILE)
+#
+# Clean rules
+#
+STD_CLEANFILES = *~ *.o *.d *.a *.i *.s core a.out vgcore.* \
+ *.tab.[ch] *.lex.c *.output
clean: libfdt_clean tests_clean
@$(VECHO) CLEAN
- rm -f $(STD_CLEANFILES)
- rm -f $(GEN_CLEANFILES)
- rm -f *.tab.[ch] lex.yy.c *.output vgcore.*
+ rm -f $(STD_CLEANFILES) $(DTC_CLEANFILES)
+ rm -f $(VERSION_FILE)
rm -f $(BIN)
-install: all
- @$(VECHO) INSTALL
- $(INSTALL) -d $(DESTDIR)$(BINDIR)
- $(INSTALL) -m 755 dtc $(DESTDIR)$(BINDIR)
- $(INSTALL) -d $(DESTDIR)$(LIBDIR)
- $(INSTALL) -m 644 $(LIBFDT_LIB) $(DESTDIR)$(LIBDIR)
- $(INSTALL) -d $(DESTDIR)$(INCLUDEDIR)
- $(INSTALL) -m 644 $(LIBFDT_INCLUDES) $(DESTDIR)$(INCLUDEDIR)
-
-define filechk
- set -e; \
- echo ' CHK $@'; \
- mkdir -p $(dir $@); \
- $(filechk_$(1)) < $< > $@.tmp; \
- if [ -r $@ ] && cmp -s $@ $@.tmp; then \
- rm -f $@.tmp; \
- else \
- echo ' UPD $@'; \
- mv -f $@.tmp $@; \
- fi;
-endef
-
#
# Generic compile rules
#
@@ -193,4 +200,12 @@ endef
@$(VECHO) AR $@
$(AR) $(ARFLAGS) $@ $^
+%.lex.c: %.l
+ @$(VECHO) LEX $@
+ $(LEX) -o $@ $<
+
+%.tab.c %.tab.h %.output: %.y
+ @$(VECHO) BISON $@
+ $(BISON) -d $<
+
FORCE:
Index: dtc/Makefile.dtc
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ dtc/Makefile.dtc 2007-09-27 14:21:17.000000000 +1000
@@ -0,0 +1,24 @@
+# Makefile.dtc
+#
+# This is not a complete Makefile of itself. Instead, it is designed to
+# be easily embeddable into other systems of Makefiles.
+#
+DTC_SRCS = dtc.c flattree.c fstree.c data.c livetree.c treesource.c srcpos.c
+DTC_EXTRA = dtc.h srcpos.h
+DTC_LEXFILES = dtc-lexer.l
+DTC_BISONFILES = dtc-parser.y
+
+DTC_LEX_SRCS = $(DTC_LEXFILES:%.l=%.lex.c)
+DTC_BISON_SRCS = $(DTC_BISONFILES:%.y=%.tab.c)
+DTC_BISON_INCLUDES = $(DTC_BISONFILES:%.y=%.tab.h)
+
+DTC_GEN_SRCS = $(DTC_LEX_SRCS) $(DTC_BISON_SRCS)
+DTC_GEN_ALL = $(DTC_GEN_SRCS) $(DTC_BISON_INCLUDES)
+DTC_OBJS = $(DTC_SRCS:%.c=%.o) $(DTC_GEN_SRCS:%.c=%.o)
+
+DTC_CLEANFILES = $(DTC_GEN_ALL)
+
+# We assume the containing Makefile system can do auto-dependencies for most
+# things, but we supply the dependencies on generated header files explicitly
+
+$(addprefix $(DTC_objdir)/,$(DTC_GEN_SRCS:%.c=%.o)): $(addprefix $(DTC_objdir)/,$(DTC_BISON_INCLUDES))
Index: dtc/libfdt/Makefile.libfdt
===================================================================
--- dtc.orig/libfdt/Makefile.libfdt 2007-09-27 14:08:05.000000000 +1000
+++ dtc/libfdt/Makefile.libfdt 2007-09-27 14:14:30.000000000 +1000
@@ -3,19 +3,12 @@
# This is not a complete Makefile of itself. Instead, it is designed to
# be easily embeddable into other systems of Makefiles.
#
-LIBFDT_OBJS_L = fdt.o fdt_ro.o fdt_wip.o fdt_sw.o fdt_rw.o fdt_strerror.o
-LIBFDT_OBJS = $(LIBFDT_OBJS_L:%=$(LIBFDT_PREFIX)%)
+LIBFDT_SRCS = fdt.c fdt_ro.c fdt_wip.c fdt_sw.c fdt_rw.c fdt_strerror.c
+LIBFDT_INCLUDES = fdt.h libfdt.h
+LIBFDT_EXTRA = libfdt_internal.h
+LIBFDT_LIB = libfdt/libfdt.a
-LIBFDT_LIB_L = libfdt.a
-LIBFDT_LIB = $(LIBFDT_LIB_L:%=$(LIBFDT_PREFIX)%)
+LIBFDT_OBJS = $(LIBFDT_SRCS:%.c=%.o)
-LIBFDT_INCLUDES_L = fdt.h libfdt.h
-LIBFDT_INCLUDES = $(LIBFDT_INCLUDES_L:%=$(LIBFDT_PREFIX)%)
+$(LIBFDT_objdir)/$(LIBFDT_LIB): $(addprefix $(LIBFDT_objdir)/,$(LIBFDT_OBJS))
-LIBFDT_CLEANFILES_L = *~ *.o *.d *.a $(LIBFDT_LIB) \
- *.i *.s a.out core
-LIBFDT_CLEANFILES = $(LIBFDT_CLEANFILES_L:%=$(LIBFDT_PREFIX)%)
-
-$(LIBFDT_LIB): $(LIBFDT_OBJS)
-
-LIBFDT_DEPFILES = $(LIBFDT_OBJS:%.o=%.d)
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [RFC] [PATCH] PowerPC: add more than 4MB kernel image size support to bootwarapper
From: David Gibson @ 2007-10-03 5:50 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <46FD0E4D.30305@ru.mvista.com>
On Fri, Sep 28, 2007 at 06:23:09PM +0400, Valentine Barshak wrote:
> David Gibson wrote:
> > On Mon, Sep 24, 2007 at 03:36:27PM +0400, Valentine Barshak wrote:
> >> Currently zImage is linked at the 4MB base address.
> >> Some platforms (using cuboot, treeboot) need the zImage's
> >> entry point and base address. They place zImage exactly
> >> at the base address it's been linked to. Sometimes 4MB left
> >> at the start of the memory is simply not enough to unpack zImage.
> >> This could happen with initramfs enabled, since the kernel image
> >> packed along with initramfs.cpio could be over 5MB in size.
> >> This patch checks vmlinux image size and links zImage at
> >> the base address that is equal to the unpacked image size
> >> aligned to 4MB boundary. This way zImage base address is 4MB
> >> only if unpacked kernel image size is less then 4MB.
> >
> > Good plan. However..
> >
> > [snip]
> >> diff -ruN linux-2.6.orig/arch/powerpc/boot/zImage.lds.S linux-2.6/arch/powerpc/boot/zImage.lds.S
> >> --- linux-2.6.orig/arch/powerpc/boot/zImage.lds.S 2007-09-22 00:48:08.000000000 +0400
> >> +++ linux-2.6/arch/powerpc/boot/zImage.lds.S 2007-09-22 04:03:58.000000000 +0400
> >> @@ -3,7 +3,7 @@
> >> EXTERN(_zimage_start)
> >> SECTIONS
> >> {
> >> - . = (4*1024*1024);
> >> + . = ALIGN((_kend - _kstart), (4*1024*1024));
> >
> > ..I don't see any reason to keep the 4MB granularity. I would just
> > align the address to say a 64k boundary (64k because that's the
> > granularity used in the normal ABI).
>
> Looking deeper at this I've found that currently u-boot thinks that
> memory space over 8MB is not reached by Linux kernel (CFG_BOOTMAPSZ
> defined as (8 << 20)), although all physical memory is identity mapped.
> That's why it puts command line and board info structure as high as
> possible within the first 8MB. This worked fine with uImage, since
> u-boot always unpacked it to 0. Now, cuImage has to be unpacked higher
> (we need space at the start of the memory to eventually put vmlinux
> image there). So, if unpacked kernel image crosses 8MB boundary, it gets
> damaged by u-boot when it prepares cmd_line and bdinfo. The possible
> workaround for that is to always link zImage at >=8MB base or to have
> 4MB granularity like this:
>
> + . = ALIGN((_kend - _kstart + 64*1024), (4*1024*1024));
>
> Reserve at least 64K for u-boot cmd_line and bdinfo.
Ah. Right. That makes things a bit tricky. Even this 4MB
granularity may not be enough (say, if the vmlinux is < 4MB, but the
zImage has a really big initrd and is > 4MB).
Except... it shouldn't really be the link address that matters. The
zImage is relocatable, so it should only be the load address specified
in the uImage header which matters. I think that's currently derived
from the link address, but it doesn't have to be.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH 8/15] bootwrapper: convert flatdevtree to version 16
From: David Gibson @ 2007-10-03 5:29 UTC (permalink / raw)
To: Milton Miller; +Cc: ppcdev
In-Reply-To: <61d44782a59ff62300416fbed26236f0@bga.com>
On Fri, Sep 28, 2007 at 10:16:51AM -0500, Milton Miller wrote:
[snip]
> Actually, there is another approach: put this converter in kexec's
> purgatory or even the kexec program. It can then run conditionally
> under command line flags to keep compatibility with the old kernels.
> If and when its is decided to only support >=v16 in kexec-tools it can
> be removed and we don't have this interim support code in the kernel
> forever (I'll handle my other usage out of tree).
Hurrah! Well, please do that then.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH] Fail early in lmb_remove_region()
From: Michael Ellerman @ 2007-10-03 4:52 UTC (permalink / raw)
To: linuxppc-dev
There was a query a while back about whether lmb_remove_region() was
correct to unconditionally decrement rgn->cnt:
http://ozlabs.org/pipermail/linuxppc-dev/2007-March/033261.html
AFAICT there is no bug at the moment because the two callers ensure that
they only pass a value of r which is < rgn->cnt. However there's the
potential for a bug if a caller got that wrong. So to avoid such a bug
in future we should fail in lmb_remove_region() if the r value is out of
range.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/mm/lmb.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/mm/lmb.c b/arch/powerpc/mm/lmb.c
index 8f4d2dc..e79e055 100644
--- a/arch/powerpc/mm/lmb.c
+++ b/arch/powerpc/mm/lmb.c
@@ -92,6 +92,8 @@ static void __init lmb_remove_region(struct lmb_region *rgn, unsigned long r)
{
unsigned long i;
+ BUG_ON(r >= rgn->cnt);
+
for (i = r; i < rgn->cnt - 1; i++) {
rgn->region[i].base = rgn->region[i + 1].base;
rgn->region[i].size = rgn->region[i + 1].size;
--
1.5.1.3.g7a33b
^ permalink raw reply related
* Re: jffs2 file system on MPC8272ADS
From: Nethra @ 2007-10-03 4:45 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <46FBD7FE.6050500@freescale.com>
Scott,
>Most common is making a jffs2 filesystem with the wrong block size. It
>could also be an incorrect flash mapping.
In our case erase block size and flash mapping seems to be correct.
> Was it the physmap driver or the pq2fads driver that found the flash?
>
> Flash is cfi compatible.
>>That's not what I meant... you have two mapping drivers enabled, and
>>the pq2fads driver might be doing something other that what you
>>specified to physmap. I'd just disable it.
I think if flash is cfi compatible then it uses default driver.
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
--
View this message in context: http://www.nabble.com/jffs2-file-system-on-MPC8272ADS-tf4513571.html#a13012850
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH] Use cache-inhibited large page bit from firmware
From: Paul Mackerras @ 2007-10-03 4:41 UTC (permalink / raw)
To: linuxppc-dev
Discussions with firmware architects have confirmed that the bit in
the ibm,pa-features property that indicates support for
cache-inhibited large (>= 64kB) page mappings does in fact mean that
the hypervisor allows 64kB mappings to I/O devices.
Thus we can now enable the code that tests that bit and sets our
CPU_FTR_CI_LARGE_PAGE feature bit.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 172dcc3..9f329a8 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -531,10 +531,7 @@ static struct ibm_pa_feature {
{CPU_FTR_CTRL, 0, 0, 3, 0},
{CPU_FTR_NOEXECUTE, 0, 0, 6, 0},
{CPU_FTR_NODSISRALIGN, 0, 1, 1, 1},
-#if 0
- /* put this back once we know how to test if firmware does 64k IO */
{CPU_FTR_CI_LARGE_PAGE, 0, 1, 2, 0},
-#endif
{CPU_FTR_REAL_LE, PPC_FEATURE_TRUE_LE, 5, 0, 0},
};
^ permalink raw reply related
* Re: [PATCH v3 2/4] Implement generic time of day clocksource for powerpc machines.
From: Thomas Gleixner @ 2007-10-03 4:00 UTC (permalink / raw)
To: Paul Mackerras
Cc: linuxppc-dev, John Stultz, Realtime Kernel, Stephen Rothwell
In-Reply-To: <18178.59123.511480.956928@cargo.ozlabs.ibm.com>
On Wed, 3 Oct 2007, Paul Mackerras wrote:
> Tony Breeds writes:
>
> > @@ -982,6 +906,10 @@ void __init time_init(void)
> >
> > write_sequnlock_irqrestore(&xtime_lock, flags);
> >
> > + /* Register the clocksource, if we're not running on iSeries */
> > + if (!firmware_has_feature(FW_FEATURE_ISERIES))
> > + clocksource_init();
>
> This breaks the 32-bit compile.
>
> Is it possible to adjust the frequency of a clocksource after it has
> been registered? Or could the timebase clocksource be unregistered
> and reregistered in iSeries_tb_recal?
There is no unregister interface right now. But we need some mechanism to
tell the core code that you changed it. I have a look if John does not
beat me.
tglx
^ permalink raw reply
* Re: [PATCH 2 6/7] Uartlite: Add of-platform-bus binding
From: Benjamin Herrenschmidt @ 2007-10-03 4:24 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40710022118r170ab652mdd65c216304b3330@mail.gmail.com>
On Tue, 2007-10-02 at 22:18 -0600, Grant Likely wrote:
> For many drivers, I think that is already the case. USB OHCI is a
> prime example where there are both PCI and platform_bus bindings among
> others. It seems to me that the bus binding effectively translates
> down to "where do I go to get the needed information". I think it
> results in less of a maintenance burden to explicitly separate bus
> binding from device setup as opposed to adding constructor code.
I think nobody consider the mess that is USB in that are to be something
we want to reproduce.
> > The important thing however, with the constructor approach is to try as
> > much as possible to keep the proper tree structure, and thus, try to
> > find a way to instanciate the devices with proper parent/child
> > relationship so that ordering for things like suspend/resume operations
> > is maintained.
>
> I'm not sure I follow. Example?
Well, make sure that if 2 platform devices repreesnt respectively a bus
and a device on that bus, they properly get instanciated as parent &
child in sysfs as well.
Ben.
^ permalink raw reply
* Re: [PATCH 2 6/7] Uartlite: Add of-platform-bus binding
From: Grant Likely @ 2007-10-03 4:18 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1191365012.22572.33.camel@pasglop>
On 10/2/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > My opinion is that since it is driver-specific code anyway, then it
> > belongs with the driver. Plus a driver writer for ARM doesn't need to
> > write them. It's the powerpc or microblaze developer who will do it.
> > If the driver maintainer doesn't want the binding in the main driver
> > .c file, then the binding can easily be in an additional .c file
> > without needing to add a constructor. (Kind of like how many USB host
> > controllers are managed)
>
> The main advantage is that it keeps the OF specific code localized to a
> single function, whether that function lives in the driver or the arch
> code, it makes it self contained and easier to deal with by the driver
> author.
>
> Having multiple device types on which the driver can attach is a pain
> from a driver standpoint. It needs multiple
> probe/remove/suspend/resume/shutdown hooks etc... it's a bigger
> maintainance burden in the long run.
For many drivers, I think that is already the case. USB OHCI is a
prime example where there are both PCI and platform_bus bindings among
others. It seems to me that the bus binding effectively translates
down to "where do I go to get the needed information". I think it
results in less of a maintenance burden to explicitly separate bus
binding from device setup as opposed to adding constructor code.
> The important thing however, with the constructor approach is to try as
> much as possible to keep the proper tree structure, and thus, try to
> find a way to instanciate the devices with proper parent/child
> relationship so that ordering for things like suspend/resume operations
> is maintained.
I'm not sure I follow. Example?
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: 2.6.23-rc7-mm1 -- powerpc rtas panic
From: Michael Ellerman @ 2007-10-03 4:09 UTC (permalink / raw)
To: Tony Breeds; +Cc: linuxppc-dev, Andrew Morton, linux-kernel
In-Reply-To: <20071003011909.GG9814@bakeyournoodle.com>
[-- Attachment #1: Type: text/plain, Size: 2975 bytes --]
On Wed, 2007-10-03 at 11:19 +1000, Tony Breeds wrote:
> On Wed, Oct 03, 2007 at 10:30:16AM +1000, Michael Ellerman wrote:
>
> > I realise it'll make the patch bigger, but this doesn't seem like a
> > particularly good name for the variable anymore.
>
> Sure, what about?
Better .. but .. :D
> diff --git a/arch/powerpc/platforms/pseries/rtasd.c b/arch/powerpc/platforms/pseries/rtasd.c
> index 30925d2..73401c8 100644
> --- a/arch/powerpc/platforms/pseries/rtasd.c
> +++ b/arch/powerpc/platforms/pseries/rtasd.c
> @@ -54,8 +54,9 @@ static unsigned int rtas_event_scan_rate;
> static int full_rtas_msgs = 0;
>
> /* Stop logging to nvram after first fatal error */
> -static int no_more_logging;
> -
> +static int logging_enabled; /* Until we initialize everything,
> + * make sure we don't try logging
> + * anything */
Until we initialise what exactly?
> static int error_log_cnt;
>
> /*
> @@ -217,7 +218,7 @@ void pSeries_log_error(char *buf, unsigned int err_type, int fatal)
> }
>
> /* Write error to NVRAM */
> - if (!no_more_logging && !(err_type & ERR_FLAG_BOOT))
> + if (logging_enabled && !(err_type & ERR_FLAG_BOOT))
> nvram_write_error_log(buf, len, err_type, error_log_cnt);
>
> /*
> @@ -229,8 +230,8 @@ void pSeries_log_error(char *buf, unsigned int err_type, int fatal)
> printk_log_rtas(buf, len);
>
> /* Check to see if we need to or have stopped logging */
> - if (fatal || no_more_logging) {
> - no_more_logging = 1;
> + if (fatal || !logging_enabled) {
> + logging_enabled = 0;
> spin_unlock_irqrestore(&rtasd_log_lock, s);
> return;
> }
Hmmm, this routine has 4 separate lock-dropping exit paths ..
> @@ -302,7 +303,7 @@ static ssize_t rtas_log_read(struct file * file, char __user * buf,
>
> spin_lock_irqsave(&rtasd_log_lock, s);
> /* if it's 0, then we know we got the last one (the one in NVRAM) */
> - if (rtas_log_size == 0 && !no_more_logging)
> + if (rtas_log_size == 0 && logging_enabled)
> nvram_clear_error_log();
> spin_unlock_irqrestore(&rtasd_log_lock, s);
>
> @@ -414,6 +415,8 @@ static int rtasd(void *unused)
> memset(logdata, 0, rtas_error_log_max);
> rc = nvram_read_error_log(logdata, rtas_error_log_max,
> &err_type, &error_log_cnt);
> + /* We can use rtas_log_buf now */
> + logging_enabled = 1;
>
> if (!rc) {
> if (err_type != ERR_FLAG_ALREADY_LOGGED) {
What exactly happens that allows us to do logging? I don't see any
ordering between anything else and the setting of the flag, and AFAICT
we're not inside a spinlock or anything here.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
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: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Use 1TB segments
From: Olof Johansson @ 2007-10-03 3:27 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Jon Tollefson, Will Schmidt
In-Reply-To: <18179.1934.821688.836972@cargo.ozlabs.ibm.com>
On Wed, Oct 03, 2007 at 01:07:58PM +1000, Paul Mackerras wrote:
> Olof Johansson writes:
>
> > > This makes the kernel use 1TB segments for all kernel mappings and for
> > > user addresses of 1TB and above, on machines which support them
> > > (currently POWER5+ and POWER6).
> >
> > PA6T supports them as well :)
>
> In the patch, we don't actually hard-code the CPU_FTR_1T_SEGMENT bit
> in the cputable entry for any processor; instead we look in the
> ibm,processor-segment-sizes property in the cpu node(s) in the device
> tree.
Yep, I see that. I just wanted to clarify it for the (future) commit
message.
> Do you want us to add the CPU_FTR_1T_SEGMENT bit to the
> cputable entry for the PA6T, or will your firmware gives the
> ibm,processor-segment-sizes property in the device tree?
Thanks, but we've already got the properties there so it just works.
> > Wouldn't it be possible to stick with 1TB segments for the low range
> > for 64-bit processes as well, and have them allocate their hugepages
> > at >1TB?
>
> You mean, forbid hugepages below 1TB? That would be a user-visible
> ABI change. There are linker scripts for generating executables whose
> text and/or data can go in hugepages, and I believe they put the
> text/data below 1TB.
Hm, good point. Bummer.
-Olof
^ permalink raw reply
* Re: [PATCH] Use 1TB segments
From: Paul Mackerras @ 2007-10-03 3:13 UTC (permalink / raw)
To: will_schmidt; +Cc: linuxppc-dev, Jon Tollefson
In-Reply-To: <1191350274.18159.279.camel@farscape.rchland.ibm.com>
Will Schmidt writes:
> I still need to test this code for performance issues, and this version
> could still use some cosmetic touchups, so I dont think we want this to
> go into a tree yet. I am reposting this primarily to indicate the prior
> version isnt quite right, and so Jon can rebase to this version. :-)
The way we scan the ibm,processor-segment-sizes property could be
nicer. Where there any other cosmetic touchups you were thinking of,
and if so what were they? I didn't notice any leftover debugging
printks or anything else that obviously needed cleaning up.
Paul.
^ permalink raw reply
* Re: [PATCH] Use 1TB segments
From: Paul Mackerras @ 2007-10-03 3:07 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, Jon Tollefson, Will Schmidt
In-Reply-To: <20071003021105.GA6553@lixom.net>
Olof Johansson writes:
> > This makes the kernel use 1TB segments for all kernel mappings and for
> > user addresses of 1TB and above, on machines which support them
> > (currently POWER5+ and POWER6).
>
> PA6T supports them as well :)
In the patch, we don't actually hard-code the CPU_FTR_1T_SEGMENT bit
in the cputable entry for any processor; instead we look in the
ibm,processor-segment-sizes property in the cpu node(s) in the device
tree. Do you want us to add the CPU_FTR_1T_SEGMENT bit to the
cputable entry for the PA6T, or will your firmware gives the
ibm,processor-segment-sizes property in the device tree?
> Wouldn't it be possible to stick with 1TB segments for the low range
> for 64-bit processes as well, and have them allocate their hugepages
> at >1TB?
You mean, forbid hugepages below 1TB? That would be a user-visible
ABI change. There are linker scripts for generating executables whose
text and/or data can go in hugepages, and I believe they put the
text/data below 1TB.
Paul.
^ permalink raw reply
* Re: [PATCH 4/5] ibmebus: Move to of_device and of_platform_driver, match eHCA and eHEA drivers
From: Paul Mackerras @ 2007-10-03 2:51 UTC (permalink / raw)
To: Joachim Fenkes
Cc: Thomas Klein, Arnd Bergmann, Jan-Bernd Themann, Paul Mackerras,
LKML, LinuxPPC-Dev, Christoph Raisch, Stefan Roscher
In-Reply-To: <200709261145.51926.fenkes@de.ibm.com>
Joachim Fenkes writes:
> Replace struct ibmebus_dev and struct ibmebus_driver with struct of_device
> and struct of_platform_driver, respectively. Match the external ibmebus
> interface and drivers using it.
>
> Signed-off-by: Joachim Fenkes <fenkes@de.ibm.com>
> ---
> drivers/infiniband/hw/ehca/ehca_classes.h | 2 +-
> drivers/net/ehea/ehea.h | 2 +-
> include/asm-powerpc/ibmebus.h | 38 +++------------
> arch/powerpc/kernel/ibmebus.c | 28 ++++++-----
> drivers/infiniband/hw/ehca/ehca_eq.c | 6 +-
> drivers/infiniband/hw/ehca/ehca_main.c | 32 ++++++------
> drivers/net/ehea/ehea_main.c | 72 ++++++++++++++--------------
This is somewhat difficult as this patch touches files that are the
responsibility of three different maintainers. Is it possible to
split the patch into three, one for each maintainer (possibly by
keeping both old and new interfaces around for a little while)?
If not, then you need to get an Acked-by and an agreement that this
change can go via the powerpc.git tree from Roland Dreier and Jeff
Garzik.
Paul.
^ permalink raw reply
* Re: [PATCH] Use 1TB segments
From: Olof Johansson @ 2007-10-03 2:11 UTC (permalink / raw)
To: Will Schmidt; +Cc: linuxppc-dev, Jon Tollefson, Paul Mackerras
In-Reply-To: <1191350274.18159.279.camel@farscape.rchland.ibm.com>
Hi,
On Tue, Oct 02, 2007 at 01:37:54PM -0500, Will Schmidt wrote:
> [RFC v2] 1TB Segment size support
>
> From: <>
>
> 1TB Segment size support
>
> This makes the kernel use 1TB segments for all kernel mappings and for
> user addresses of 1TB and above, on machines which support them
> (currently POWER5+ and POWER6).
PA6T supports them as well :)
> We don't currently use 1TB segments
> for user addresses < 1T, since that would effectively prevent 32-bit
> processes from using huge pages unless we also had a way to revert to
> using 256MB segments.
Wouldn't it be possible to stick with 1TB segments for the low range
for 64-bit processes as well, and have them allocate their hugepages
at >1TB?
-Olof
^ permalink raw reply
* Re: [RFC] PPC64 Exporting memory information through /proc/iomem
From: KAMEZAWA Hiroyuki @ 2007-10-03 1:19 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: linuxppc-dev, anton, Paul Mackerras, linux-mm
In-Reply-To: <1191366653.6106.68.camel@dyn9047017100.beaverton.ibm.com>
On Tue, 02 Oct 2007 16:10:53 -0700
Badari Pulavarty <pbadari@us.ibm.com> wrote:
> > > Otherwise, we need to add arch-specific hooks in hotplug-remove
> > > code to be able to do this.
> >
> > Isn't it just a matter of abstracting the test for a valid range of
> > memory? If it's really hard to abstract that, then I guess we can put
> > RAM in iomem_resource, but I'd rather not.
> >
>
> Sure. I will work on it and see how ugly it looks.
>
> KAME, are you okay with abstracting the find_next_system_ram() and
> let arch provide whatever implementation they want ? (since current
> code doesn't work for x86-64 also ?).
>
Hmm, registering /proc/iomem is complicated ? If too complicated, adding config
like
CONFIG_ARCH_SUPPORT_IORESOURCE_RAM or something can do good work.
you can define your own "check_pages_isolated" (you can rename this to
arch_check_apges_isolated().)
BTW, I shoudl ask people how to describe conventional memory
A. #define IORESOURCE_RAM IORESOURCE_MEM (ia64)
B. #define IORESOURCE_RAM IORESOURCE_MEM | IORESOUCE_BUSY (i386, x86_64)
Sad to say, memory hot-add registers new memory just as IORESOURCE_MEM.
Thanks,
-Kame
^ permalink raw reply
* Re: 2.6.23-rc7-mm1 -- powerpc rtas panic
From: Tony Breeds @ 2007-10-03 1:19 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Andrew Morton, linux-kernel
In-Reply-To: <1191371416.8073.1.camel@concordia>
On Wed, Oct 03, 2007 at 10:30:16AM +1000, Michael Ellerman wrote:
> I realise it'll make the patch bigger, but this doesn't seem like a
> particularly good name for the variable anymore.
Sure, what about?
Clarify when RTAS logging is enabled.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/platforms/pseries/rtasd.c | 15 +++++++++------
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/rtasd.c b/arch/powerpc/platforms/pseries/rtasd.c
index 30925d2..73401c8 100644
--- a/arch/powerpc/platforms/pseries/rtasd.c
+++ b/arch/powerpc/platforms/pseries/rtasd.c
@@ -54,8 +54,9 @@ static unsigned int rtas_event_scan_rate;
static int full_rtas_msgs = 0;
/* Stop logging to nvram after first fatal error */
-static int no_more_logging;
-
+static int logging_enabled; /* Until we initialize everything,
+ * make sure we don't try logging
+ * anything */
static int error_log_cnt;
/*
@@ -217,7 +218,7 @@ void pSeries_log_error(char *buf, unsigned int err_type, int fatal)
}
/* Write error to NVRAM */
- if (!no_more_logging && !(err_type & ERR_FLAG_BOOT))
+ if (logging_enabled && !(err_type & ERR_FLAG_BOOT))
nvram_write_error_log(buf, len, err_type, error_log_cnt);
/*
@@ -229,8 +230,8 @@ void pSeries_log_error(char *buf, unsigned int err_type, int fatal)
printk_log_rtas(buf, len);
/* Check to see if we need to or have stopped logging */
- if (fatal || no_more_logging) {
- no_more_logging = 1;
+ if (fatal || !logging_enabled) {
+ logging_enabled = 0;
spin_unlock_irqrestore(&rtasd_log_lock, s);
return;
}
@@ -302,7 +303,7 @@ static ssize_t rtas_log_read(struct file * file, char __user * buf,
spin_lock_irqsave(&rtasd_log_lock, s);
/* if it's 0, then we know we got the last one (the one in NVRAM) */
- if (rtas_log_size == 0 && !no_more_logging)
+ if (rtas_log_size == 0 && logging_enabled)
nvram_clear_error_log();
spin_unlock_irqrestore(&rtasd_log_lock, s);
@@ -414,6 +415,8 @@ static int rtasd(void *unused)
memset(logdata, 0, rtas_error_log_max);
rc = nvram_read_error_log(logdata, rtas_error_log_max,
&err_type, &error_log_cnt);
+ /* We can use rtas_log_buf now */
+ logging_enabled = 1;
if (!rc) {
if (err_type != ERR_FLAG_ALREADY_LOGGED) {
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply related
* Re: [PATCH] Remove unnecessary memset from physmap_of driver
From: Josh Boyer @ 2007-10-03 0:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18178.55231.813138.369480@cargo.ozlabs.ibm.com>
On Wed, 2007-10-03 at 09:43 +1000, Paul Mackerras wrote:
> Valentine Barshak writes:
>
> > No need for memset to zero memory here, since we use kzalloc.
> >
> > Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> > ---
> > drivers/mtd/maps/physmap_of.c | 1 -
>
> Please cc the mtd list (linux-mtd@lists.infradead.org) and/or David
> Woodhouse on MTD patches. Posting them to linuxppc-dev isn't going to
> get them upstream.
Except when I screw up and pull them into my tree. Which won't happen
again.
josh
^ permalink raw reply
* Re: [PATCH v3 2/4] Implement generic time of day clocksource for powerpc machines.
From: Paul Mackerras @ 2007-10-03 0:48 UTC (permalink / raw)
To: Tony Breeds
Cc: Stephen Rothwell, Thomas Gleixner, Realtime Kernel, linuxppc-dev
In-Reply-To: <20070921213552.GD9814@bakeyournoodle.com>
Tony Breeds writes:
> @@ -982,6 +906,10 @@ void __init time_init(void)
>
> write_sequnlock_irqrestore(&xtime_lock, flags);
>
> + /* Register the clocksource, if we're not running on iSeries */
> + if (!firmware_has_feature(FW_FEATURE_ISERIES))
> + clocksource_init();
This breaks the 32-bit compile.
Is it possible to adjust the frequency of a clocksource after it has
been registered? Or could the timebase clocksource be unregistered
and reregistered in iSeries_tb_recal?
Paul.
^ permalink raw reply
* Re: 2.6.23-rc7-mm1 -- powerpc rtas panic
From: Michael Ellerman @ 2007-10-03 0:30 UTC (permalink / raw)
To: Tony Breeds; +Cc: linuxppc-dev, Andrew Morton, linux-kernel
In-Reply-To: <20071003002646.GD9814@bakeyournoodle.com>
[-- Attachment #1: Type: text/plain, Size: 2015 bytes --]
On Wed, 2007-10-03 at 10:26 +1000, Tony Breeds wrote:
> On Tue, Oct 02, 2007 at 06:28:19PM -0500, Linas Vepstas wrote:
> > On Mon, Sep 24, 2007 at 01:35:31PM +0100, Andy Whitcroft wrote:
> > > Seeing the following from an older power LPAR, pretty sure we had
> > > this in the previous -mm also:
> >
> > I haven't forgetten about this ... and am looking at it now.
> > Seems that whenever I go to reserve the machine pSeries-102,
> > someone else is using it :-)
>
> This panic is caused by "[POWERPC] pseries: Fix jumbled no_logging flag."
> (79c0108d1b9db4864ab77b2a95dfa04f2dcf264c), in the powerpc/for-2.6.24
> branch. It looks to me that we have logging enabled too early now.
>
> I think the following is a reasonable fix?
>
> ---
> Explicitly enable RTAS error logging, when it should be ready.
>
>
> Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
>
> ---
>
> arch/powerpc/platforms/pseries/rtasd.c | 7 ++++++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/rtasd.c b/arch/powerpc/platforms/pseries/rtasd.c
> index 30925d2..0df5d0d 100644
> --- a/arch/powerpc/platforms/pseries/rtasd.c
> +++ b/arch/powerpc/platforms/pseries/rtasd.c
> @@ -54,7 +54,10 @@ static unsigned int rtas_event_scan_rate;
> static int full_rtas_msgs = 0;
>
> /* Stop logging to nvram after first fatal error */
> -static int no_more_logging;
> +static int no_more_logging = 1; /* Until we initialize everything,
> + * make sure we don't try logging
> + * anything */
> +
I realise it'll make the patch bigger, but this doesn't seem like a
particularly good name for the variable anymore.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
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: 189 bytes --]
^ permalink raw reply
* Re: 2.6.23-rc7-mm1 -- powerpc rtas panic
From: Tony Breeds @ 2007-10-03 0:26 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, Andrew Morton, linux-kernel
In-Reply-To: <20071002232819.GN4338@austin.ibm.com>
On Tue, Oct 02, 2007 at 06:28:19PM -0500, Linas Vepstas wrote:
> On Mon, Sep 24, 2007 at 01:35:31PM +0100, Andy Whitcroft wrote:
> > Seeing the following from an older power LPAR, pretty sure we had
> > this in the previous -mm also:
>
> I haven't forgetten about this ... and am looking at it now.
> Seems that whenever I go to reserve the machine pSeries-102,
> someone else is using it :-)
This panic is caused by "[POWERPC] pseries: Fix jumbled no_logging flag."
(79c0108d1b9db4864ab77b2a95dfa04f2dcf264c), in the powerpc/for-2.6.24
branch. It looks to me that we have logging enabled too early now.
I think the following is a reasonable fix?
---
Explicitly enable RTAS error logging, when it should be ready.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/platforms/pseries/rtasd.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/rtasd.c b/arch/powerpc/platforms/pseries/rtasd.c
index 30925d2..0df5d0d 100644
--- a/arch/powerpc/platforms/pseries/rtasd.c
+++ b/arch/powerpc/platforms/pseries/rtasd.c
@@ -54,7 +54,10 @@ static unsigned int rtas_event_scan_rate;
static int full_rtas_msgs = 0;
/* Stop logging to nvram after first fatal error */
-static int no_more_logging;
+static int no_more_logging = 1; /* Until we initialize everything,
+ * make sure we don't try logging
+ * anything */
+
static int error_log_cnt;
@@ -414,6 +417,8 @@ static int rtasd(void *unused)
memset(logdata, 0, rtas_error_log_max);
rc = nvram_read_error_log(logdata, rtas_error_log_max,
&err_type, &error_log_cnt);
+ /* We can use rtas_log_buf now */
+ no_more_logging = 0;
if (!rc) {
if (err_type != ERR_FLAG_ALREADY_LOGGED) {
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply related
* Re: [PATCH] Remove unnecessary memset from physmap_of driver
From: Paul Mackerras @ 2007-10-02 23:43 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20071002155328.GA3574@ru.mvista.com>
Valentine Barshak writes:
> No need for memset to zero memory here, since we use kzalloc.
>
> Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
> ---
> drivers/mtd/maps/physmap_of.c | 1 -
Please cc the mtd list (linux-mtd@lists.infradead.org) and/or David
Woodhouse on MTD patches. Posting them to linuxppc-dev isn't going to
get them upstream.
Paul.
^ 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