LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 2/3]: of_i2c: Add sparc support.
From: David Miller @ 2008-08-21  7:10 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: sparclinux, paulus


of_i2c: Add sparc support.

Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/of/Kconfig  |    2 +-
 drivers/of/of_i2c.c |   58 ++++++++++++++++++++++++++++++++++++++++++++------
 2 files changed, 52 insertions(+), 8 deletions(-)

diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index f821dbc..67dea24 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -10,7 +10,7 @@ config OF_GPIO
 
 config OF_I2C
 	def_tristate I2C
-	depends on PPC_OF && I2C
+	depends on OF && I2C
 	help
 	  OpenFirmware I2C accessors
 
diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c
index 6a98dc8..beb4102 100644
--- a/drivers/of/of_i2c.c
+++ b/drivers/of/of_i2c.c
@@ -19,8 +19,20 @@
 void of_register_i2c_devices(struct i2c_adapter *adap,
 			     struct device_node *adap_node)
 {
-	void *result;
 	struct device_node *node;
+	int num_addr_cells = 1;
+	const int *prop;
+	void *result;
+
+	prop = of_get_property(adap_node, "#address-cells", NULL);
+	if (prop)
+		num_addr_cells = *prop;
+
+	if (num_addr_cells != 1 && num_addr_cells != 2) {
+		printk(KERN_ERR "of-i2c: invalid address cells %d\n",
+		       num_addr_cells);
+		return;
+	}
 
 	for_each_child_of_node(adap_node, node) {
 		struct i2c_board_info info = {};
@@ -31,16 +43,48 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
 			continue;
 
 		addr = of_get_property(node, "reg", &len);
-		if (!addr || len < sizeof(int) || *addr > (1 << 10) - 1) {
-			printk(KERN_ERR
-			       "of-i2c: invalid i2c device entry\n");
+		if (!addr || len < (num_addr_cells * sizeof(int))) {
+			printk(KERN_ERR "of-i2c: invalid i2c device entry\n");
 			continue;
 		}
+		switch (num_addr_cells) {
+		case 1:
+			info.addr = addr[0];
+			break;
+		case 2:
+			/* XXX addr[0], the first cell, is bus number XXX */
+			info.addr = addr[1];
+			break;
+		}
 
+#ifdef CONFIG_SPARC
+		/* In my copy of the I2C bindings for IEEE1275 the
+		 * register value is encoded as a 2-cell value:
+		 *
+		 * Bit #    33222222 22221111 11111100 00000000
+		 *          10987654 32109876 54321098 76543210
+		 *
+		 * bus:     00000000 00000000 00000000 bbbbbbbb
+		 * address: 00000000 00000000 00000sss sssssss0
+		 *
+		 * where:
+		 * bbbbbbbb        8-bit unsigned number representing
+		 *                 the I2C bus address within this I2C bus
+		 *                 controller node
+		 * ssssssssss      10-bit unsigned number representing the
+		 *                 slave address
+		 *
+		 * When doing I2C transfers to a device the low bit of
+		 * the address indicates whether the transfer is a read or
+		 * a write, and the upper bits indicate the device address.
+		 *
+		 * The Linux I2C layer wants device addresses which elide this
+		 * direction bit.  Thus we should shift the OF provided reg
+		 * property address down by one bit.
+		 */
+		info.addr >>= 1;
+#endif
 		info.irq = irq_of_parse_and_map(node, 0);
-
-		info.addr = *addr;
-
 		request_module(info.type);
 
 		result = i2c_new_device(adap, &info);
-- 
1.5.6.5.GIT

^ permalink raw reply related

* [PATCH 3/3]: of: Add some I2C mod aliases table entries for sparc64 systems.
From: David Miller @ 2008-08-21  7:10 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: sparclinux, paulus


of: Add some I2C mod aliases table entries for sparc64 systems.

Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/of/base.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index ad8ac1a..e849f69 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -410,7 +410,9 @@ struct of_modalias_table {
 	char *modalias;
 };
 static struct of_modalias_table of_modalias_table[] = {
-	/* Empty for now; add entries as needed */
+	{ "i2c-adm1031", "adm1031" },
+	{ "i2c-at24c64", "24c64" },
+	{ "i2c-at34c02", "spd" },
 };
 
 /**
-- 
1.5.6.5.GIT

^ permalink raw reply related

* [machdep_calls] IRQ
From: Sébastien Chrétien @ 2008-08-21  7:13 UTC (permalink / raw)
  To: linuxppc-dev

[-- Attachment #1: Type: text/plain, Size: 262 bytes --]

Hello,

What are the constraints in order to implement a irq_init function ?
I think it has to set the mask. Does it enable IRQ ?

What is the aim or get_irq ? Does it retun an information about the mask,
the states, or... ?

Thanks
Sébastien Chrétien

[-- Attachment #2: Type: text/html, Size: 298 bytes --]

^ permalink raw reply

* [PATCH] add a simple 405EP based board
From: Markus Brunner @ 2008-08-21  8:07 UTC (permalink / raw)
  To: linuxppc-dev

This adds support for a simple ppc405ep board. 
At the moment, there are no 405ep boards in arch/powerpc, so this can be used as a template
for new boards, or migrating them from arch/ppc.
I2c, UART and EMAC are working. PCI could not be tested, so it was not included in the dts.

Signed-off-by: Markus Brunner <super.firetwister@googlemail.com>
---
 boot/dts/ppc405ep.dts    |  218 +++++++++++++++++++++++++++++++++++++++++++++++
 platforms/40x/Kconfig    |    8 +
 platforms/40x/Makefile   |    1
 platforms/40x/ppc405ep.c |   58 ++++++++++++
 4 files changed, 285 insertions(+)

diff -upNr linux-2.6.27-rc4-orig/arch/powerpc/boot/dts/ppc405ep.dts 
linux-2.6.27-rc4/arch/powerpc/boot/dts/ppc405ep.dts
--- linux-2.6.27-rc4-orig/arch/powerpc/boot/dts/ppc405ep.dts	1970-01-01 01:00:00.000000000 +0100
+++ linux-2.6.27-rc4/arch/powerpc/boot/dts/ppc405ep.dts	2008-08-21 09:35:45.722031912 +0200
@@ -0,0 +1,218 @@
+/*
+ * Device Tree Source for ppc405ep
+ *
+ * (c) 2008 Markus Brunner <super.firetwister@googlemail.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without
+ * any warranty of any kind, whether express or implied.
+ */
+
+/ {
+	#address-cells = <1>;
+	#size-cells = <1>;
+	model = "company,ppc405ep";
+	compatible = "company,ppc405ep";
+	dcr-parent = <&/cpus/cpu@0>;
+
+	aliases {
+		ethernet0 = &EMAC0;
+		ethernet1 = &EMAC1;
+		serial0 = &UART0;
+		serial1 = &UART1;
+	};
+
+	cpus {
+		#address-cells = <1>;
+		#size-cells = <0>;
+
+		cpu@0 {
+			device_type = "cpu";
+			model = "PowerPC,405EP";
+			reg = <0>;
+			clock-frequency = <0>; /* Filled in by u-boot */
+			timebase-frequency = <0>; /* Filled in by u-boot */
+			i-cache-line-size = <20>;
+			d-cache-line-size = <20>;
+			i-cache-size = <4000>;
+			d-cache-size = <4000>;
+			dcr-controller;
+			dcr-access-method = "native";
+		};
+	};
+
+	memory {
+		device_type = "memory";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		reg = <00000000 00000000>;	/* Filled in by u-boot */
+	};
+
+	UIC0: interrupt-controller {
+		compatible = "ibm,uic";
+		interrupt-controller;
+		cell-index = <0>;
+		dcr-reg = <0c0 9>;
+		#address-cells = <0>;
+		#size-cells = <0>;
+		#interrupt-cells = <2>;
+	};
+
+	plb {
+		compatible = "ibm,plb3";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		ranges;
+		clock-frequency = <0>; /* Filled in by u-boot */
+
+		SDRAM0: memory-controller {
+			compatible = "ibm,sdram-405ep";
+			dcr-reg = <010 2>;
+		};
+
+		MAL: mcmal {
+			compatible = "ibm,mcmal-405ep", "ibm,mcmal";
+			dcr-reg = <180 62>;
+			num-tx-chans = <4>;
+			num-rx-chans = <4>;
+			interrupt-parent = <&UIC0>;
+			interrupts = <
+				b 4 /* TXEOB */
+				c 4 /* RXEOB */
+				a 4 /* SERR */
+				d 4 /* TXDE */
+				e 4 /* RXDE */>;
+		};
+
+		POB0: opb {
+			compatible = "ibm,opb-405ep", "ibm,opb";
+			#address-cells = <1>;
+			#size-cells = <1>;
+			ranges = <ef600000 ef600000 a00000>;
+			dcr-reg = <0a0 5>;
+			clock-frequency = <0>; /* Filled in by u-boot */
+
+			UART0: serial@ef600300 {
+				device_type = "serial";
+				compatible = "ns16550";
+				reg = <ef600300 8>;
+				virtual-reg = <ef600300>;
+				clock-frequency = <0>; /* Filled in by u-boot */
+				current-speed = <1c200>;
+				interrupt-parent = <&UIC0>;
+				interrupts = <0 4>;
+			};
+
+			UART1: serial@ef600400 {
+				device_type = "serial";
+				compatible = "ns16550";
+				reg = <ef600400 8>;
+				virtual-reg = <ef600400>;
+				clock-frequency = <0>; /* Filled in by u-boot */
+				current-speed = <1c200>;
+				interrupt-parent = <&UIC0>;
+				interrupts = <1 4>;
+			};
+
+			IIC: i2c@ef600500 {
+				compatible = "ibm,iic-405ep", "ibm,iic";
+				reg = <ef600500 11>;
+				interrupt-parent = <&UIC0>;
+				interrupts = <2 4>;
+			};
+
+			GPIO: gpio@ef600700 {
+				compatible = "ibm,gpio-405ep";
+				reg = <ef600700 38>;
+			};
+
+			EMAC0: ethernet@ef600800 {
+				linux,network-index = <0>;
+				device_type = "network";
+				compatible = "ibm,emac-405ep", "ibm,emac";
+				interrupt-parent = <&UIC0>;
+				interrupts = <
+					f 4 /* Ethernet */
+					9 4 /* Ethernet Wake Up */>;
+				local-mac-address = [000000000000]; /* Filled in by u-boot */
+				reg = <ef600800 70>;
+				mal-device = <&MAL>;
+				mal-tx-channel = <0>;
+				mal-rx-channel = <0>;
+				cell-index = <0>;
+				max-frame-size = <5dc>;
+				rx-fifo-size = <1000>;
+				tx-fifo-size = <800>;
+				phy-mode = "mii";
+				phy-map = <00000000>;
+			};
+
+			EMAC1: ethernet@ef600900 {
+				linux,network-index = <1>;
+				device_type = "network";
+				compatible = "ibm,emac-405ep", "ibm,emac";
+				interrupt-parent = <&UIC0>;
+				interrupts = <
+					11 4 /* Ethernet */
+					9 4 /* Ethernet Wake Up */>;
+				local-mac-address = [000000000000]; /* Filled in by u-boot */
+				reg = <ef600900 70>;
+				mal-device = <&MAL>;
+				mal-tx-channel = <2>;
+				mal-rx-channel = <1>;
+				cell-index = <1>;
+				max-frame-size = <5dc>;
+				rx-fifo-size = <1000>;
+				tx-fifo-size = <800>;
+				mdio-device = <&EMAC0>;
+				phy-mode = "mii";
+				phy-map = <00000020>;
+			};
+
+
+		};
+
+		EBC0: ebc {
+			compatible = "ibm,ebc-405ep", "ibm,ebc";
+			dcr-reg = <012 2>;
+			#address-cells = <2>;
+			#size-cells = <1>;
+			ranges = <0 0 f8000000 8000000
+				  1 0 0c000000  100000
+				  2 0 0C100000  100000
+				  3 0 0C200000  100000
+				  4 0 80000000  100000>;
+
+			clock-frequency = <0>; /* Filled in by u-boot */
+
+			nor_flash@0,0 {
+				compatible = "amd,s29gl01gp", "cfi-flash";
+				bank-width = <2>;
+				reg = <0 000000 8000000>;
+				#address-cells = <1>;
+				#size-cells = <1>;
+				partition@0 {
+					label = "jffs2";
+					reg = <0 a00000>;
+				};
+				partition@a00000 {
+					label = "foo";
+					reg = <a00000 400000>;
+				};
+				partition@e00000 {
+					label = "bar";
+					reg = <e00000 7180000>;
+				};
+				partition@7f80000 {
+					label = "u-boot";
+					reg = <7f80000 80000>;
+				};
+			};
+		};
+		/* PCI0: pci@ec000000 { PCI was not tested } */
+	};
+
+	chosen {
+		linux,stdout-path = "/plb/opb/serial@ef600300";
+	};
+};
diff -upNr linux-2.6.27-rc4-orig/arch/powerpc/platforms/40x/Kconfig 
linux-2.6.27-rc4/arch/powerpc/platforms/40x/Kconfig
--- linux-2.6.27-rc4-orig/arch/powerpc/platforms/40x/Kconfig	2008-07-13 23:51:29.000000000 +0200
+++ linux-2.6.27-rc4/arch/powerpc/platforms/40x/Kconfig	2008-08-21 09:35:45.722031912 +0200
@@ -42,6 +42,14 @@ config MAKALU
 	help
 	  This option enables support for the AMCC PPC405EX board.
 
+config PPC405EP
+	bool "ppc405ep"
+	depends on 40x
+	default n
+	select 405EP
+	help
+	  This option enables support for a simple ppc 405ep board.
+
 #config REDWOOD_5
 #	bool "Redwood-5"
 #	depends on 40x
diff -upNr linux-2.6.27-rc4-orig/arch/powerpc/platforms/40x/Makefile 
linux-2.6.27-rc4/arch/powerpc/platforms/40x/Makefile
--- linux-2.6.27-rc4-orig/arch/powerpc/platforms/40x/Makefile	2008-07-13 23:51:29.000000000 +0200
+++ linux-2.6.27-rc4/arch/powerpc/platforms/40x/Makefile	2008-08-21 10:03:54.718530907 +0200
@@ -3,3 +3,4 @@ obj-$(CONFIG_MAKALU)				+= makalu.o
 obj-$(CONFIG_WALNUT)				+= walnut.o
 obj-$(CONFIG_XILINX_VIRTEX_GENERIC_BOARD)	+= virtex.o
 obj-$(CONFIG_EP405)				+= ep405.o
+obj-$(CONFIG_PPC405EP)				+= ppc405ep.o
diff -upNr linux-2.6.27-rc4-orig/arch/powerpc/platforms/40x/ppc405ep.c 
linux-2.6.27-rc4/arch/powerpc/platforms/40x/ppc405ep.c
--- linux-2.6.27-rc4-orig/arch/powerpc/platforms/40x/ppc405ep.c	1970-01-01 01:00:00.000000000 +0100
+++ linux-2.6.27-rc4/arch/powerpc/platforms/40x/ppc405ep.c	2008-08-21 09:35:45.728701197 +0200
@@ -0,0 +1,58 @@
+/*
+ * Powerpc 405EP board setup. Not aimed at any particular board.
+ *
+ * Copyright(c) 2008 Markus Brunner <super.firetwister@googlemail.com>
+ *
+ * Based on the Walnut code by
+ * Josh Boyer <jwboyer@linux.vnet.ibm.com>
+ * Copyright 2007 IBM Corporation
+ *
+ * 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 <linux/init.h>
+#include <linux/of_platform.h>
+
+#include <asm/machdep.h>
+#include <asm/ppc4xx.h>
+#include <asm/time.h>
+#include <asm/udbg.h>
+#include <asm/uic.h>
+
+
+static __initdata struct of_device_id ppc405ep_of_bus[] = {
+	{ .compatible = "ibm,plb3", },
+	{ .compatible = "ibm,opb", },
+	{ .compatible = "ibm,ebc", },
+	{},
+};
+
+static int __init ppc405ep_device_probe(void)
+{
+	of_platform_bus_probe(NULL, ppc405ep_of_bus, NULL);
+
+	return 0;
+}
+machine_device_initcall(ppc405ep, ppc405ep_device_probe);
+
+static int __init ppc405ep_probe(void)
+{
+	unsigned long root = of_get_flat_dt_root();
+	if (!of_flat_dt_is_compatible(root, "company,ppc405ep"))
+		return 0;
+
+	return 1;
+}
+
+define_machine(ppc405ep) {
+	.name 				= "ppc405ep",
+	.probe 				= ppc405ep_probe,
+	.progress 			= udbg_progress,
+	.init_IRQ 			= uic_init_tree,
+	.get_irq 			= uic_get_irq,
+	.restart			= ppc4xx_reset_system,
+	.calibrate_decr			= generic_calibrate_decr,
+};

^ permalink raw reply

* Re: [machdep_calls] IRQ
From: Michael Ellerman @ 2008-08-21  8:02 UTC (permalink / raw)
  To: Sébastien Chrétien; +Cc: linuxppc-dev
In-Reply-To: <319b0ac50808210013p677ebb91vf3b30748138c6d4c@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]

On Thu, 2008-08-21 at 09:13 +0200, Sébastien Chrétien wrote:
> Hello,
> 
> What are the constraints in order to implement a irq_init function ? 

You mean ppc_md.init_IRQ() ?

If so, it's a hook you can use to setup your interrupt controller. It's
called from init_IRQ() (arch/powerpc/kernel/irq.c), which is called from
start_kernel() (init/main.c).

Not long after it is called irqs are enabled. I think it is the last
callback into arch code before irqs are enabled.

When it is called the device tree is unflattened, so you can use the of_
API. Bootmem is setup so you can use alloc_bootmem(), but you can't
kmalloc yet. ioremap should work.


> What is the aim or get_irq ? Does it retun an information about the
> mask, the states, or... ?

The aim of ppc_md.get_irq() ? It's called from do_IRQ()
(arch/powerpc/kernel/irq.c) which is called from assembler in the
appropriate head_x.S

It just returns the number (virtual number) of the irq that just fired.
If for some reason you took a spurious interrupt it should return
NO_IRQ.

I'm not sure what you mean about masks or states, someone else might
though.

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: [Cbe-oss-dev] powerpc/cell/oprofile: fix mutex locking for spu-oprofile
From: Arnd Bergmann @ 2008-08-21  8:14 UTC (permalink / raw)
  To: cbe-oss-dev
  Cc: Robert Richter, linux-kernel, linuxppc-dev, Paul Mackerras,
	oprofile-list, cel
In-Reply-To: <18604.60738.523963.886786@drongo.ozlabs.ibm.com>

On Thursday 21 August 2008, Paul Mackerras wrote:
> Arnd Bergmann writes:
> 
> > Paul, any chance we can still get this into 2.6.27?
> 
> Possibly.  We'll need a really good explanation for Linus as to why
> this is needed (what regression or serious bug this fixes) and why it
> is late.  Can you send me something explaining that?

The patch does not fix a regression, the spu-oprofile code basically never
worked. With the current code in Linux, samples in the profile buffer
can get corrupted because reader and writer to that buffer use different
locks for accessing it. It took us several iterations to come up with
a solution that does not introduce other problems and I didn't want to
push an earlier version that would need more fixups.

Since rc4 is out now, I understand if you feel more comfortable with
putting the patch into -next instead of -merge.
Note that the second patch is trivial and fixes an oopsable condition
of the kernel, so at least that should still go into 2.6.27.

> > I've added the Ack and uploaded it again for you to
> > pull from
> > 
> >  master.kernel.org:/pub/scm/linux/kernel/git/arnd/cell-2.6.git merge
> 
> Are you sure you actually managed to update that?

No, but it's there now. I was missing the '-f' for git-push.

	Arnd <><

^ permalink raw reply

* Re: [machdep_calls] IRQ
From: Sébastien Chrétien @ 2008-08-21  8:23 UTC (permalink / raw)
  To: michael; +Cc: linuxppc-dev
In-Reply-To: <1219305767.8008.14.camel@localhost>

[-- Attachment #1: Type: text/plain, Size: 1874 bytes --]

Exactly, I mean ppc_md.init_IRQ().
Ok. What have I to setup in this function ? I set the mask and other
registers. Is it right ?  How do I chose the mask ?
At the end of this funtion, IRQ are disable. Is that right ? So who does
enable IRQs ?

Sorry for all this questions, I am learning the low layer of Linux.

2008/8/21, Michael Ellerman <michael@ellerman.id.au>:
>
> On Thu, 2008-08-21 at 09:13 +0200, Sébastien Chrétien wrote:
> > Hello,
> >
> > What are the constraints in order to implement a irq_init function ?
>
>
> You mean ppc_md.init_IRQ() ?
>
> If so, it's a hook you can use to setup your interrupt controller. It's
> called from init_IRQ() (arch/powerpc/kernel/irq.c), which is called from
> start_kernel() (init/main.c).
>
> Not long after it is called irqs are enabled. I think it is the last
> callback into arch code before irqs are enabled.
>
> When it is called the device tree is unflattened, so you can use the of_
> API. Bootmem is setup so you can use alloc_bootmem(), but you can't
> kmalloc yet. ioremap should work.
>
>
>
> > What is the aim or get_irq ? Does it retun an information about the
> > mask, the states, or... ?
>
>
> The aim of ppc_md.get_irq() ? It's called from do_IRQ()
> (arch/powerpc/kernel/irq.c) which is called from assembler in the
> appropriate head_x.S
>
> It just returns the number (virtual number) of the irq that just fired.
> If for some reason you took a spurious interrupt it should return
> NO_IRQ.
>
> I'm not sure what you mean about masks or states, someone else might
> though.
>
> 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: Type: text/html, Size: 2285 bytes --]

^ permalink raw reply

* Re: powerpc allmodconfig in current -mm
From: Stephen Rothwell @ 2008-08-21  8:34 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linuxppc-dev
In-Reply-To: <20080820181626.0347c270.akpm@linux-foundation.org>

[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]

Hi Andrew,

On Wed, 20 Aug 2008 18:16:26 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> From: Andrew Morton <akpm@linux-foundation.org>
> 
> powerpc allmodconfig:
> 
> ERROR: "CMO_PageSize" [arch/powerpc/platforms/pseries/cmm.ko] undefined!
> 
> (needed for 2.6.27)
> 
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
> 
>  arch/powerpc/platforms/pseries/setup.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> diff -puN arch/powerpc/platforms/pseries/setup.c~powerpc-export-cmo_pagesize arch/powerpc/platforms/pseries/setup.c
> --- a/arch/powerpc/platforms/pseries/setup.c~powerpc-export-cmo_pagesize
> +++ a/arch/powerpc/platforms/pseries/setup.c
> @@ -71,6 +71,7 @@
>  int CMO_PrPSP = -1;
>  int CMO_SecPSP = -1;
>  unsigned long CMO_PageSize = (ASM_CONST(1) << IOMMU_PAGE_SHIFT);
> +EXPORT_SYMBOL(CMO_PageSize);
>  
>  int fwnmi_active;  /* TRUE if an FWNMI handler is present */
>  

Added to linux-next for today.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply

* Re: [RFC] mtd: add OF2PDEV convertor for the NDFC driver
From: Sebastian Siewior @ 2008-08-21  8:28 UTC (permalink / raw)
  To: Arnd Bergmann; +Cc: linuxppc-dev, tglx, linux-mtd, Sean MacLennan
In-Reply-To: <200808210040.58809.arnd@arndb.de>

* Arnd Bergmann | 2008-08-21 00:40:58 [+0200]:

>On Wednesday 20 August 2008, Sebastian Siewior wrote:
>> I didn't convert the NDFC driver to support OF because there are
>> non-OF-aware platforms with the ndfc chip.
>> All settings are mandatory except the oob layout.
>
>Are you aware of Sean's patch from
>http://patchwork.ozlabs.org/linuxppc/patch?id=20183 ?

Yes, I heard of it. tglx told me that the IP-Core might show up in
non-IBM HW and it would be better not to drop the platform support.

>	Arnd <><
Sebastian

^ permalink raw reply

* Re: powerpc allmodconfig in current -mm
From: Stephen Rothwell @ 2008-08-21  8:40 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc-dev, Andrew Morton
In-Reply-To: <18604.63159.163718.167197@drongo.ozlabs.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 383 bytes --]

Hi Paul,

On Thu, 21 Aug 2008 15:01:43 +1000 Paul Mackerras <paulus@samba.org> wrote:
>
> OK.  I think we need to export CMO_PrPSP and CMO_SecPSP as well.
> (Lovely names. :()

These are only used (indirectly) in lparcfg.c which is never a module, so
should be OK.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply

* Re: [PATCH] add a simple 405EP based board
From: Stephen Rothwell @ 2008-08-21  8:52 UTC (permalink / raw)
  To: Markus Brunner; +Cc: linuxppc-dev
In-Reply-To: <200808211007.59965.super.firetwister@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 673 bytes --]

Hi Markus,

One small nit:

On Thu, 21 Aug 2008 10:07:58 +0200 Markus Brunner <super.firetwister@googlemail.com> wrote:
>
> +#include <linux/init.h>
> +#include <linux/of_platform.h>
> +
> +#include <asm/machdep.h>
> +#include <asm/ppc4xx.h>
> +#include <asm/time.h>
> +#include <asm/udbg.h>
> +#include <asm/uic.h>
> +
> +static int __init ppc405ep_probe(void)
> +{
> +	unsigned long root = of_get_flat_dt_root();
> +	if (!of_flat_dt_is_compatible(root, "company,ppc405ep"))

You need to include <asm/prom.h> to use the of_flat ... routines.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

^ permalink raw reply

* Re:
From: Wolfgang Denk @ 2008-08-21  9:48 UTC (permalink / raw)
  To: a.schmid; +Cc: linuxppc-embedded
In-Reply-To: <FCELKENEBBOLLHKPHCCBEECMCDAA.a.schmid@systeme-steuerungen.de>

Dear Alexander,

In message <FCELKENEBBOLLHKPHCCBEECMCDAA.a.schmid@systeme-steuerungen.de> you wrote:
> 
> I use U-Boot 1.2.0 on MPC5200B. Console over serial works fine. I have a

U-Boot related questions are off topic here. Please post such
questions on the U-Boot mailing list, see
http://lists.denx.de/mailman/listinfo/u-boot

Second, U-Boot 1.2.0 is *very* old, please use recent code (1.3.4 or
later).

> Grafic controller at LPB Bus and U-Boot shows his console output at VGa too.
> But I would need a keyboard. I compiled U-Boot with USB and if i type "usb
> reset" the ohci controller scans the USB devices and finds a keyboard. But
> nothing happens if i push the buttons on the keyboard!

There is no USB keyboard driver in U-Boot yet. Please let me know if
you need help to develop one.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Time is fluid ... like a river with currents, eddies, backwash.
	-- Spock, "The City on the Edge of Forever", stardate 3134.0

^ permalink raw reply

* Re: Strange behavior with I2C on Sequoia board
From: Stefan Roese @ 2008-08-21  9:51 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: Sean MacLennan
In-Reply-To: <20080820231828.3c22da08@lappy.seanm.ca>

On Thursday 21 August 2008, Sean MacLennan wrote:
> > That's all output from the wrapper, not the kernel.  And the kernel
> > config doesn't make a difference at all to the wrapper.  I wonder if
> > there is some weird size issue going on there or if whatever U-Boot
> > version you are using is doing odd things...
>
> Any chance something in the DTS could affect it? Maybe try commenting
> out the second IIC controller?

Yes, I2C is generally working and should make a difference in Linux kernel 
booting.

It seems that your bootwrapper is somehow not copying the correct MAC address 
to the device-tree. Not sure what's going wrong here. We usually don't use 
the bootwrapper but boot the uImage directly from U-Boot on all 4xx systems.

You might want to debug the bootwrapper code, if possible drop the bootwrapper 
and use the uImage with a newer, device-tree enabled U-Boot version.

Best regards,
Stefan

^ permalink raw reply

* Re: ELDK Fedora Core 9
From: Wolfgang Denk @ 2008-08-21 10:10 UTC (permalink / raw)
  To: rmcguire; +Cc: eldk, linuxppc-embedded
In-Reply-To: <2EA59411B5534D8893C7CB74569C2DC2@absolutdaddy>

Dear "Russell McGuire",

In message <2EA59411B5534D8893C7CB74569C2DC2@absolutdaddy> you wrote:
> 
> I know that DENX doesn't list ELDK 4.1 with FC9 as officially supported, but
> has anyone tried to install it with FC9?
> 
> Attempts last night resulted in the install script freezing during install,
> and no apparent error messages.

Where exactly did it hang? What was the command you used, and what was the exact output?

> 1) Has anyone tried this? Success?

I tried it now, and it got stuck indeed:

...
Preparing...                ########################################### [100%]
   1:db4-devel-ppc_4xx      ########################################### [100%]
Preparing...                ########################################### [100%]
   1:db4-utils-ppc_4xx      ########################################### [100%]
Preparing...                ########################################### [100%]
   1:glib2-ppc_4xx          ########################################### [100%]
Preparing...                ########################################### [100%]
   1:glib2-devel-ppc_4xx    ########################################### [100%]
Preparing...                ########################################### [100%]

<hangs here>

> 2) Does anyone have suggestion on how turn on debugging with the install
> script?

It's not a a script, but a binary, so you are limited to  tools  like
strace, ltrace etc.

In my case I see this:

# strace -p 21197
Process 21197 attached - interrupt to quit
futex(0x96fe17c, FUTEX_WAIT_PRIVATE, 1, NULL

i. e. it's hanging in a futex call. [Futextes have often before  been
a major PITA].

A quick workaround seems to be to build the installer on  the  native
(Fedora  9) system; download the source and the Makefile from the git
repository:

http://git.denx.de/?p=eldk/build.git;a=tree;f=install;h=5f1a9bb9ca5757f4efbca7ff4f48bf869a2ef949;hb=90ed3ca5e1163d771badf1c26f76e95d95e13990

and run:

$ make TARGET_ARCH=ppc

Then use this "install" binary to replace 

Then reboot, and then try again.  Note  that  the  reboot  is  really
necessary,  or  at least I do not know of any other way to get rid of
the stuck futexes.


BTW: ELDK related questions are better posted on the ELDK mailing
list, see http://lists.denx.de/mailman/listinfo/eldk

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
People seldom know what they want until you give them what  they  ask
for.

^ permalink raw reply

* Re: porting linux 2.6.27 to embedded powerpc board
From: David Jander @ 2008-08-21  9:43 UTC (permalink / raw)
  To: linuxppc-embedded; +Cc: Laxmikant Rashinkar
In-Reply-To: <424724.49343.qm@web46312.mail.sp1.yahoo.com>

On Thursday 21 August 2008 01:24:46 Laxmikant Rashinkar wrote:
> Hi,
>
> I have an embedded PowerPC (MPC8347) board that works fine with uboot and
> Linux 2.6.15.
>
> I am trying to upgrade the kernel so that it runs on the latest release -
> Linux 2.6.27. So far, I have gotten the kernel to compile on my platform,
> but of course it does not boot.

Well, honestly I don't know where to look for information either (other than 
the source-code and examples from others), but here is a list with points to 
look out for (I have just done the same thing as you for a MPC5200B-based 
board):

1. Upgrade to latest u-boot first (recent git seems to be fine). There have 
been a lot of changes in u-boot lately about OF and device-tree related 
things. I suspect you need a fairly recent version of u-boot to go well with 
the latest kernel. It's also generally a good idea IMHO.

2. I assume you are porting to arch/powerpc (the old arch/ppc you used back in 
2.6.15 is obsolete and broken now).

3. Look at other platforms that use the same processor, and pick a simple one 
as starting point. Look out for the dts (device-tree-source file in 
arch/powerpc/boot/dts), copy and modify one to reflect your hardware. 
Recently a lot of changes happend in the kernel, changing device names, 
obsoleting "device-type" tags, etc..., so some of the current DTS sources 
included in the kernel might not even work (wrong device name, missing 
information, wrong use of "device-type", etc...), so watch out for these kind 
of issues too.

4. Be sure that the device(s) necessary to produce output on your console are 
correctly placed in the DT. Also make sure that u-boot knows about it 
(#define OF_STDOUT_PATH... in your u-boot board config file)

5. When compiling the device tree, it may be necessary to add some extra 
reserved entries to the compiled tree (I am using dtc -p 10240 -R 20, which 
might be slightly exaggerated), because u-boot may add something to it, and 
if it can't, linux won't boot.

6. Remember to always specify the "rootfstype=" option on the commandline if 
booting from anything other than NFS. This was not necessary back in the 
2.6.15-times AFAICR.

7. Boot with a device-tree (in u-boot: "bootm $addrofkernel - $addrofdtb", 
don't forget the dash if you are not using an initrd). If you don't do this, 
u-boot can't fix your DT, and the kernel probably won't find it either.

8. Be sure to use the correct version of the DTC (DT compiler) for your kernel 
(the sources are included nowadays, somewhere in arch/powerpc/boot IIRC). The 
command used to compile, should probably be something like this:

$ ./dtc -p 10240 -R 20 -I dts -o myplatform.dtb -O dtb -b 0 dts/myplatform.dts

Load the resulting .dtb file directly with u-boot (don't make an u-image out 
of it).

That's all I remember right now... hope it helps.

Regards,

-- 
David Jander

^ permalink raw reply

* Re: [Cbe-oss-dev] powerpc/cell/oprofile: fix mutex locking for spu-oprofile
From: Michael Ellerman @ 2008-08-21 10:20 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Robert Richter, linux-kernel, linuxppc-dev, oprofile-list, cel,
	cbe-oss-dev
In-Reply-To: <200808211014.42683.arnd@arndb.de>

[-- Attachment #1: Type: text/plain, Size: 1296 bytes --]

On Thu, 2008-08-21 at 10:14 +0200, Arnd Bergmann wrote:
> On Thursday 21 August 2008, Paul Mackerras wrote:
> > Arnd Bergmann writes:
> > 
> > > Paul, any chance we can still get this into 2.6.27?
> > 
> > Possibly.  We'll need a really good explanation for Linus as to why
> > this is needed (what regression or serious bug this fixes) and why it
> > is late.  Can you send me something explaining that?
> 
> The patch does not fix a regression, the spu-oprofile code basically never
> worked. With the current code in Linux, samples in the profile buffer
> can get corrupted because reader and writer to that buffer use different
> locks for accessing it.

Actually for me it worked[1] a reasonable amount of the time, enough to
be useful. So the spu-oprofile code has always been broken in this way,
but it's not always fatal. So the patch doesn't fix a regression, but it
fixes a serious user-visible bug, which makes it legit rc4 material
IMHO.

[1] that was late last year, so possibly a kernel or two ago.

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

* New Patchwork beta
From: Jeremy Kerr @ 2008-08-21 10:22 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: linux-mtd, bazaar-ng, cbe-oss-dev, linuxppc-embedded

Hi all,

I've just put up a new beta of patchwork:

  http://patchwork2.ozlabs.org/

I intend to replace the existing patchwork with the new code, but would 
like to get it tested first. There aren't many patches in the system at 
the moment, but it'll receive patches from the relevant lists. I'll 
also import a set of existing mails tomorrow, to give some sample data 
to test with.

One important note - after beta testing, I'm planning to clear the test 
database and start from scratch. So, don't go spending too much time 
updating patches!

However, have a play with the new site, let me know what breaks, and any 
suggestions for changing, and we can work towards a full replacement 
for the current site.

Some differences from the old patchwork:

  * Patches can now be 'delegated' to other maintainers - this means
    that maintainers can offload subsystem-specific patches to other
    maintainers.

  * Anyone can create an account, and work with bundles, and manage
    their own patches.

  * Pagination. No more 10MB patch lists!

  * Bundles can be made public, allow users to share patchsets

  * Better filtering interface

Project Maintainers:

  Create an account, then send me your username, and I'll add maintainer
  privileges to your account. Again, don't go too crazy with the   
  maintaining work, as it'll all be cleared out once we replace 
  patchwork.ozlabs.org

  Also: bazaar-ng, linux-mtd and linux-embedded folks: are you still
  using patchwork?

Existing patches:

  After talking to the powerpc maintainers, we've decided that we're
  going to start with a clean slate, and not import patches from the
  existing patchwork database. If you'd prefer to keep current patches
  for your project, let me know. This will be a bit of work, but I'm
  sure we can work something out.

Happy patchworking,


Jeremy

^ permalink raw reply

* Re: [RFC] mtd: add OF2PDEV convertor for the NDFC driver
From: Arnd Bergmann @ 2008-08-21 11:46 UTC (permalink / raw)
  To: Sebastian Siewior; +Cc: linuxppc-dev, tglx, linux-mtd, Sean MacLennan
In-Reply-To: <20080821082805.GA8013@www.tglx.de>

On Thursday 21 August 2008, Sebastian Siewior wrote:
> Yes, I heard of it. tglx told me that the IP-Core might show up in
> non-IBM HW and it would be better not to drop the platform support.

Thomas, any example of that? I would guess that all powerpc and microblaze
systems would use the of_platform drivers now, so is there any other
architecture that might get an ndfc?

	Arnd <><

^ permalink raw reply

* Re: [PATCH] add a simple 405EP based board
From: Josh Boyer @ 2008-08-21 11:55 UTC (permalink / raw)
  To: Markus Brunner; +Cc: linuxppc-dev
In-Reply-To: <200808211007.59965.super.firetwister@gmail.com>

On Thu, 2008-08-21 at 10:07 +0200, Markus Brunner wrote:
> This adds support for a simple ppc405ep board. 
> At the moment, there are no 405ep boards in arch/powerpc, so this can be used as a template
> for new boards, or migrating them from arch/ppc.
> I2c, UART and EMAC are working. PCI could not be tested, so it was not included in the dts.

I plan on adding more 405 board support very soon.  When I do, it'll be
along the lines of the patch series I just sent out for 44x.  There's
really no reason to have a per CPU/board file if we can avoid it.

Your code is simple enough overall, so I might even use it as a starting
point.  If I do, I'll certainly give you credit.  Though it's incomplete
in that you have a DTS that requires something to poke values into it,
and nothing readily apparent to do so.  A cuImage wrapper is probably
warranted here.

josh

^ permalink raw reply

* Re: Strange behavior with I2C on Sequoia board
From: Valentine Barshak @ 2008-08-21 12:30 UTC (permalink / raw)
  To: Stefan Roese; +Cc: linuxppc-dev, Sean MacLennan
In-Reply-To: <200808211151.40499.sr@denx.de>

Stefan Roese wrote:
> On Thursday 21 August 2008, Sean MacLennan wrote:
>>> That's all output from the wrapper, not the kernel.  And the kernel
>>> config doesn't make a difference at all to the wrapper.  I wonder if
>>> there is some weird size issue going on there or if whatever U-Boot
>>> version you are using is doing odd things...
>> Any chance something in the DTS could affect it? Maybe try commenting
>> out the second IIC controller?
> 
> Yes, I2C is generally working and should make a difference in Linux kernel 
> booting.
> 
> It seems that your bootwrapper is somehow not copying the correct MAC address 
> to the device-tree. Not sure what's going wrong here. We usually don't use 
> the bootwrapper but boot the uImage directly from U-Boot on all 4xx systems.
> 
> You might want to debug the bootwrapper code, if possible drop the bootwrapper 
> and use the uImage with a newer, device-tree enabled U-Boot version.
> 

U-boot thinks that all memory above the first 8MB is out of reach for 
the kernel and puts kernel bootargs and boardinfo structure below 8MB as 
close as possible to this limit. Including the i2c driver into the 
kernel increases the kernel image size. So when u-boot unpacks the 
kernel to 0x400000 (Load Address: 00400000) it overwrites the kernel 
parameters. So when the kernel actually starts, it reads zeros instead 
of boardinfo (and mac addresses)

The 8MB limit is set for all AMCC boards in include/configs/amcc-common.h:
#define CFG_BOOTMAPSZ		(8 << 20) /* Initial Memory map for Linux */

I think this limit is obsolete and can be moved to at least 64MB.
But you'll need to rebuild u-boot.

Stefan, what do you think? Can we increase the default initial memory 
map for AMCC boards in the next u-boot release, since u-boot has all 
memory identity-mapped on ppc 44x?

Thanks,
Valentine.

> Best regards,
> Stefan
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev

^ permalink raw reply

* Please pull from 'for-2.6.27' (updated)
From: Kumar Gala @ 2008-08-21 12:41 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc-dev

Please pull from 'for-2.6.27' branch of

	master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.27

to receive the following updates:

This is bug fixes and defconfig updates.  I dropped the Kconfig cpm serial
patch for 2.6.27 since its not really a bug fix and put it into my
powerpc-next branch for .28.  (I also moved 2 defconfigs since we were
already touching them).

- k

 arch/powerpc/boot/dts/mpc8641_hpcn.dts            |    2
 arch/powerpc/boot/dts/tqm8548-bigflash.dts        |    8
 arch/powerpc/boot/dts/tqm8548.dts                 |    3
 arch/powerpc/boot/wrapper                         |    2
 arch/powerpc/configs/83xx/asp8347_defconfig       | 1334 +++++++++++++++++
 arch/powerpc/configs/83xx/mpc8313_rdb_defconfig   |  188 +-
 arch/powerpc/configs/83xx/mpc8315_rdb_defconfig   |  188 +-
 arch/powerpc/configs/83xx/mpc832x_mds_defconfig   |  172 +-
 arch/powerpc/configs/83xx/mpc832x_rdb_defconfig   |  176 +-
 arch/powerpc/configs/83xx/mpc834x_itx_defconfig   |  175 +-
 arch/powerpc/configs/83xx/mpc834x_itxgp_defconfig |  172 +-
 arch/powerpc/configs/83xx/mpc834x_mds_defconfig   |  168 +-
 arch/powerpc/configs/83xx/mpc836x_mds_defconfig   |  172 +-
 arch/powerpc/configs/83xx/mpc836x_rdk_defconfig   |  183 +-
 arch/powerpc/configs/83xx/mpc837x_mds_defconfig   |  351 ++++
 arch/powerpc/configs/83xx/mpc837x_rdb_defconfig   |  340 ++++
 arch/powerpc/configs/83xx/sbc834x_defconfig       |  239 ++-
 arch/powerpc/configs/85xx/ksi8560_defconfig       |   95 -
 arch/powerpc/configs/85xx/mpc8536_ds_defconfig    | 1654 ++++++++++++++++++++++
 arch/powerpc/configs/85xx/mpc8540_ads_defconfig   |   71
 arch/powerpc/configs/85xx/mpc8544_ds_defconfig    |  178 +-
 arch/powerpc/configs/85xx/mpc8560_ads_defconfig   |   98 -
 arch/powerpc/configs/85xx/mpc8568mds_defconfig    |  121 +
 arch/powerpc/configs/85xx/mpc8572_ds_defconfig    |  177 +-
 arch/powerpc/configs/85xx/mpc85xx_cds_defconfig   |   85 -
 arch/powerpc/configs/85xx/sbc8548_defconfig       |   63
 arch/powerpc/configs/85xx/sbc8560_defconfig       |   69
 arch/powerpc/configs/85xx/stx_gp3_defconfig       |  163 +-
 arch/powerpc/configs/85xx/tqm8540_defconfig       |  112 +
 arch/powerpc/configs/85xx/tqm8541_defconfig       |  139 +
 arch/powerpc/configs/85xx/tqm8548_defconfig       |  129 +
 arch/powerpc/configs/85xx/tqm8555_defconfig       |  139 +
 arch/powerpc/configs/85xx/tqm8560_defconfig       |  139 +
 arch/powerpc/configs/adder875_defconfig           |   55
 arch/powerpc/configs/asp8347_defconfig            | 1214 ----------------
 arch/powerpc/configs/c2k_defconfig                |  245 +--
 arch/powerpc/configs/ep8248e_defconfig            |  198 ++
 arch/powerpc/configs/ep88xc_defconfig             |   57
 arch/powerpc/configs/linkstation_defconfig        |  133 +
 arch/powerpc/configs/mpc7448_hpc2_defconfig       |   72
 arch/powerpc/configs/mpc8272_ads_defconfig        |  132 +
 arch/powerpc/configs/mpc83xx_defconfig            |  389 ++++-
 arch/powerpc/configs/mpc8536_ds_defconfig         | 1637 ---------------------
 arch/powerpc/configs/mpc85xx_defconfig            |  207 +-
 arch/powerpc/configs/mpc8610_hpcd_defconfig       |  165 +-
 arch/powerpc/configs/mpc8641_hpcn_defconfig       |  215 +-
 arch/powerpc/configs/mpc866_ads_defconfig         |   61
 arch/powerpc/configs/mpc885_ads_defconfig         |   57
 arch/powerpc/configs/pq2fads_defconfig            |  147 +
 arch/powerpc/configs/prpmc2800_defconfig          |  125 +
 arch/powerpc/configs/sbc8641d_defconfig           |  173 +-
 arch/powerpc/configs/storcenter_defconfig         |  113 +
 arch/powerpc/sysdev/cpm_common.c                  |   37
 arch/powerpc/sysdev/qe_lib/ucc_fast.c             |    4
 arch/powerpc/sysdev/qe_lib/ucc_slow.c             |    8
 55 files changed, 8093 insertions(+), 4656 deletions(-)

Kumar Gala (2):
      powerpc: Fix whitespace merge in mpc8641 hpcn device tree
      powerpc: Update defconfigs for FSL PPC boards

Laurent Pinchart (1):
      cpm2: Fix race condition in CPM2 GPIO library.

Scott Wood (1):
      powerpc: Add cuImage.mpc866ads to the bootwrapper as a cuboot-8xx target

Timur Tabi (1):
      powerpc: fix memory leaks in QE library

Wolfgang Grandegger (1):
      powerpc/85xx: TQM8548: DTS file fixes and cleanup

^ permalink raw reply

* [PATCH] math-emu: Fix compiler warnings
From: Kumar Gala @ 2008-08-21 12:50 UTC (permalink / raw)
  To: linux-kernel; +Cc: linuxppc-dev, davem

Fix warnings of the form:
arch/powerpc/math-emu/fsubs.c:15: warning: 'R_f1' may be used uninitialized in this function
arch/powerpc/math-emu/fsubs.c:15: warning: 'R_f0' may be used uninitialized in this function

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---

I intend these patches to go via the powerpc.git tree if no one has issues.

- k

 include/math-emu/op-2.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/math-emu/op-2.h b/include/math-emu/op-2.h
index e193fb0..4f26ecc 100644
--- a/include/math-emu/op-2.h
+++ b/include/math-emu/op-2.h
@@ -25,7 +25,7 @@
 #ifndef __MATH_EMU_OP_2_H__
 #define __MATH_EMU_OP_2_H__
 
-#define _FP_FRAC_DECL_2(X)	_FP_W_TYPE X##_f0, X##_f1
+#define _FP_FRAC_DECL_2(X)	_FP_W_TYPE X##_f0 = 0, X##_f1 = 0
 #define _FP_FRAC_COPY_2(D,S)	(D##_f0 = S##_f0, D##_f1 = S##_f1)
 #define _FP_FRAC_SET_2(X,I)	__FP_FRAC_SET_2(X, I)
 #define _FP_FRAC_HIGH_2(X)	(X##_f1)
-- 
1.5.5.1

^ permalink raw reply related

* [PATCH] math-emu: Add support for reporting exact invalid exception
From: Kumar Gala @ 2008-08-21 12:50 UTC (permalink / raw)
  To: linux-kernel; +Cc: linuxppc-dev, davem
In-Reply-To: <1219323021-7273-1-git-send-email-galak@kernel.crashing.org>

Some architectures (like powerpc) provide status information on the exact
type of invalid exception.  This is pretty straight forward as we already
report invalid exceptions via FP_SET_EXCEPTION.

We add new flags (FP_EX_INVALID_*) the architecture code can define if it
wants the exact invalid exception reported.

We had to split out the INF/INF and 0/0 cases for divide to allow reporting
the two invalid forms properly.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
I intend these patches to go via the powerpc.git tree if no one has issues.

- k

 include/math-emu/op-common.h |   12 ++++++++----
 include/math-emu/soft-fp.h   |   19 +++++++++++++++++++
 2 files changed, 27 insertions(+), 4 deletions(-)

diff --git a/include/math-emu/op-common.h b/include/math-emu/op-common.h
index bb46e76..cc1ec39 100644
--- a/include/math-emu/op-common.h
+++ b/include/math-emu/op-common.h
@@ -73,7 +73,7 @@ do {									\
 	X##_c = FP_CLS_NAN;						\
 	/* Check for signaling NaN */					\
 	if (!(_FP_FRAC_HIGH_RAW_##fs(X) & _FP_QNANBIT_##fs))		\
-	  FP_SET_EXCEPTION(FP_EX_INVALID);				\
+	  FP_SET_EXCEPTION(FP_EX_INVALID | FP_EX_INVALID_SNAN);		\
       }									\
     break;								\
   }									\
@@ -324,7 +324,7 @@ do {									     \
 	_FP_FRAC_SET_##wc(R, _FP_NANFRAC_##fs);				     \
 	R##_s = _FP_NANSIGN_##fs;					     \
 	R##_c = FP_CLS_NAN;						     \
-	FP_SET_EXCEPTION(FP_EX_INVALID);				     \
+	FP_SET_EXCEPTION(FP_EX_INVALID | FP_EX_INVALID_ISI);		     \
 	break;								     \
       }									     \
     /* FALLTHRU */							     \
@@ -431,7 +431,7 @@ do {							\
     R##_s = _FP_NANSIGN_##fs;				\
     R##_c = FP_CLS_NAN;					\
     _FP_FRAC_SET_##wc(R, _FP_NANFRAC_##fs);		\
-    FP_SET_EXCEPTION(FP_EX_INVALID);			\
+    FP_SET_EXCEPTION(FP_EX_INVALID | FP_EX_INVALID_IMZ);\
     break;						\
 							\
   default:						\
@@ -490,11 +490,15 @@ do {							\
     break;						\
 							\
   case _FP_CLS_COMBINE(FP_CLS_INF,FP_CLS_INF):		\
+    R##_s = _FP_NANSIGN_##fs;				\
+    R##_c = FP_CLS_NAN;					\
+    _FP_FRAC_SET_##wc(R, _FP_NANFRAC_##fs);		\
+    FP_SET_EXCEPTION(FP_EX_INVALID | FP_EX_INVALID_IDI);\
   case _FP_CLS_COMBINE(FP_CLS_ZERO,FP_CLS_ZERO):	\
     R##_s = _FP_NANSIGN_##fs;				\
     R##_c = FP_CLS_NAN;					\
     _FP_FRAC_SET_##wc(R, _FP_NANFRAC_##fs);		\
-    FP_SET_EXCEPTION(FP_EX_INVALID);			\
+    FP_SET_EXCEPTION(FP_EX_INVALID | FP_EX_INVALID_ZDZ);\
     break;						\
 							\
   default:						\
diff --git a/include/math-emu/soft-fp.h b/include/math-emu/soft-fp.h
index a6f873b..3f284bc 100644
--- a/include/math-emu/soft-fp.h
+++ b/include/math-emu/soft-fp.h
@@ -51,6 +51,25 @@
 #ifndef FP_EX_INVALID
 #define FP_EX_INVALID		0
 #endif
+#ifndef FP_EX_INVALID_SNAN
+#define FP_EX_INVALID_SNAN	0
+#endif
+/* inf - inf */
+#ifndef FP_EX_INVALID_ISI
+#define FP_EX_INVALID_ISI	0
+#endif
+/* inf / inf */
+#ifndef FP_EX_INVALID_IDI
+#define FP_EX_INVALID_IDI	0
+#endif
+/* 0 / 0 */
+#ifndef FP_EX_INVALID_ZDZ
+#define FP_EX_INVALID_ZDZ	0
+#endif
+/* inf * 0 */
+#ifndef FP_EX_INVALID_IMZ
+#define FP_EX_INVALID_IMZ	0
+#endif
 #ifndef FP_EX_OVERFLOW
 #define FP_EX_OVERFLOW		0
 #endif
-- 
1.5.5.1

^ permalink raw reply related

* Re: [PATCH] add a simple 405EP based board
From: M B @ 2008-08-21 12:46 UTC (permalink / raw)
  To: jwboyer; +Cc: linuxppc-dev
In-Reply-To: <1219319729.26429.40.camel@jdub.homelinux.org>

On 8/21/08, Josh Boyer <jwboyer@linux.vnet.ibm.com> wrote:

> I plan on adding more 405 board support very soon.  When I do, it'll be
> along the lines of the patch series I just sent out for 44x.  There's
> really no reason to have a per CPU/board file if we can avoid it.
>
> Your code is simple enough overall, so I might even use it as a starting

>

I've seen your patches for 44x support and I like the idea of a
general board setup.
I wanted to make the dts public, because I needed some help to figure
out the "mdio-device" tag. So if you have further use for this you're
welcome.

> Though it's incomplete
> in that you have a DTS that requires something to poke values into it,
> and nothing readily apparent to do so.  A cuImage wrapper is probably
> warranted here.

The missing values in the dts get filled in by ft_cpu_setup(...) from
uboot, it's generic code and not board specific, but the board setup
in u-boot must call it, so it won't work for all boards.

Best regards

Markus

^ permalink raw reply

* Initrd
From: Sébastien Chrétien @ 2008-08-21 13:02 UTC (permalink / raw)
  To: linuxppc-dev

[-- Attachment #1: Type: text/plain, Size: 232 bytes --]

Hello,

I am trying to setup a initrd on my board. I selected initrd support in the
2.6.26 kernel. But when my boad boots, it crashes affet MMU:exit.
What is the process in order to use a initrd ?

Thanks
Sébastien Chrétien

[-- Attachment #2: Type: text/html, Size: 260 bytes --]

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox