* Re: [i2c] [PATCH 0/2] i2c: Add support for device alias names
From: Jochen Friedrich @ 2008-04-28 20:24 UTC (permalink / raw)
To: Wolfram Sang
Cc: Sievers, Laurent, Scott Wood, linuxppc-dev list, Paul Mundt,
Linux I2C, Kay, Jean Delvare
In-Reply-To: <20080428153543.GB4353@pengutronix.de>
Hi Wolfram,
> I tested on this hardware
>
> MPC8260 (powerpc) + PCF8575 (io expander) + LM84 (sensor)
> + RS5C372 (rtc) + X24645 (eeprom)
It's also OK on dbox2 hardware: MPC823 (powerpc)
+ saa7127 (patch needed to add id_table) + dbox frontprocessor
(8051 controller with i2c interface).
Thanks,
Jochen
^ permalink raw reply
* Re: pci_proc_init: proc_dir_entry '00' already registered
From: Alexey Dobriyan @ 2008-04-28 21:07 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, linux-kernel
Olaf Hering wrote:
> On Sun, Feb 10, Alexey Dobriyan wrote:
>
> > On Sun, Feb 10, 2008 at 11:07:57AM +0100, Olaf Hering wrote:
> > > Current Linus tree gives this new warning during bootup:
> > >
> > > +proc_dir_entry '00' already registered
> > > +Call Trace:
> > > +[c00000007b0dfba0] [c00000000000e4b0] .show_stack+0x70/0x1bc
> > > (unreliable)
> > > +[c00000007b0dfc50] [c0000000000f2714] .proc_register+0x130/0x210
> > > +[c00000007b0dfd00] [c0000000000f299c] .proc_mkdir_mode+0x40/0x70
> > > +[c00000007b0dfd80] [c000000000276ed8]
> > > .pci_proc_attach_device+0xac/0x144
> > > +[c00000007b0dfe20] [c0000000005bdb3c] .pci_proc_init+0x74/0xac
> > > +[c00000007b0dfea0] [c0000000005a27ac] .kernel_init+0x1d0/0x394
> > > +[c00000007b0dff90] [c00000000001e258] .kernel_thread+0x4c/0x68
> >
> > Can you insert dump_stack() when '00' is registered, not just second
> > time?
>
> Its pci_bus_add_device(). Full dmesg attached:
It can't be. "proc_initialized" is 0 at that point, so no new files in
/proc .
Must be something PCI domains related: if pci_proc_domain() returns 0
for some reason, busses will be different, but name the same -- '00'.
The reason there is no second warning is that you don't have anything
on 0001:0a .
> pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c00000007b113800 - 0000:00:0b.0
> pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c00000007b113000 - 0000:0a:00.0
> pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c00000007b149800 - 0001:00:00.0
> proc_dir_entry '00' already registered
> Call Trace:
> [c00000007b0dfb60] [c00000000000f4ec] .show_stack+0x5c/0x1f0 (unreliable)
> [c00000007b0dfc10] [c000000000112e40] .proc_register+0x190/0x250
> [c00000007b0dfcd0] [c000000000113130] .proc_mkdir_mode+0x40/0x80
> [c00000007b0dfd50] [c0000000002c7548] .pci_proc_attach_device+0x158/0x190
> [c00000007b0dfe00] [c00000000065c3f8] .pci_proc_init+0xb8/0x100
> [c00000007b0dfe90] [c00000000063c8a8] .kernel_init+0x1d8/0x420
> [c00000007b0dff90] [c000000000021dac] .kernel_thread+0x4c/0x68
> pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c00000007b149000 - 0001:00:01.0
> pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c00000007b1a4800 - 0001:00:02.0
> pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c00000007b1a4000 - 0001:00:03.0
> pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c00000007b1a5800 - 0001:00:04.0
> pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c00000007b1a5000 - 0001:00:05.0
> pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c00000007b1a6800 - 0001:00:06.0
> pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c00000007b1a6000 - 0001:00:07.0
> pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c00000007b1a7800 - 0001:00:08.0
> pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c00000007b1a7000 - 0001:00:09.0
> pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c00000007b1a9800 - 0001:05:04.0
> pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c00000007b1a9000 - 0001:05:04.1
> pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c00000007b1ab800 - 0001:01:07.0
> pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c00000007b1ab000 - 0001:01:0b.0
> pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c00000007b1ac800 - 0001:01:0b.1
> pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c00000007b1ac000 - 0001:01:0b.2
> pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c00000007b1ae800 - 0001:03:0c.0
> pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c00000007b1ae000 - 0001:03:0d.0
> pci_proc_attach_device(395) swapper(1):c0,j4294937353 1: c00000007b1af800 - 0001:03:0e.0
^ permalink raw reply
* Re: [RESEND][PATCH][POWERPC] PIKA Warp: Update platform code to supportRev B boards
From: Grant Likely @ 2008-04-28 19:56 UTC (permalink / raw)
To: Sean MacLennan; +Cc: Sean MacLennan, linuxppc-dev
In-Reply-To: <20080428145310.553b8271@lappy.seanm.ca>
On Mon, Apr 28, 2008 at 12:53 PM, Sean MacLennan
<smaclennan@pikatech.com> wrote:
> Ok, here is another version of the patch with Stephen Rothwell's and
> Grant Likely's suggestions.
>
> Cheers,
> Sean
A few more comments below.
Also, it might help to split up the .dts and code changes into 2
separate patches. That way the .dts can be picked up even if the
actual platform code still needs some revisions.
Finally, since this is a 4xx board port, you need to cc: Josh Boyer on
these patches.
> diff --git a/arch/powerpc/boot/dts/warp.dts b/arch/powerpc/boot/dts/warp.dts
> index b04a52e..d124497 100644
> --- a/arch/powerpc/boot/dts/warp.dts
> +++ b/arch/powerpc/boot/dts/warp.dts
> @@ -186,6 +179,16 @@
> reg = <ef600700 14>;
> interrupt-parent = <&UIC0>;
> interrupts = <2 4>;
> + index = <0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ad7414@4a {
> + compatible = "adi,ad7414";
> + reg = <4a>;
> + interrupts = <19 8>;
> + interrupt-parent = <&UIC0>;
> + };
> };
>
> GPIO0: gpio@ef600b00 {
> @@ -196,8 +199,22 @@
> GPIO1: gpio@ef600c00 {
> compatible = "ibm,gpio-440ep";
> reg = <ef600c00 48>;
> +
> + };
You need to add the gpio-controller and #gpio-cells properties to the
GPIO nodes for the LED's gpios property to work correctly. Search for
"2) gpio-controller nodes" in
Documentation/powerpc/booting-without-of.txt for details. #gpio-cells
should probably be '2' for this gpio controller; 1 cell for the gpio
pin and 1 cell for flags.
> +
> + led@31 {
>
> + compatible = "linux,gpio-led";
> + linux,name = "green";
> + gpios = <&GPIO1 31>;
> + };
> +
> + led@30 {
> + compatible = "linux,gpio-led";
> + linux,name = "red";
> + gpios = <&GPIO1 30>;
> };
These should not be children of the soc node (they are not part of the
SoC internal bus). However, I think it would be perfectly valid to
make them children of the gpio node since they don't have any
connections to other device on the platform.
>
> +
> ZMII0: emac-zmii@ef600d00 {
> compatible = "ibm,zmii-440ep", "ibm,zmii-440gp", "ibm,zmii";
> reg = <ef600d00 c>;
>
> diff --git a/arch/powerpc/platforms/44x/warp-nand.c b/arch/powerpc/platforms/44x/warp-nand.c
> index 9150318..d293c70 100644
>
> --- a/arch/powerpc/platforms/44x/warp-nand.c
> +++ b/arch/powerpc/platforms/44x/warp-nand.c
> @@ -11,8 +11,10 @@
> #include <linux/mtd/partitions.h>
> #include <linux/mtd/nand.h>
> #include <linux/mtd/ndfc.h>
> +#include <linux/of.h>
>
>
> #include <asm/machdep.h>
>
> +
> #ifdef CONFIG_MTD_NAND_NDFC
>
> #define CS_NAND_0 1 /* use chip select 1 for NAND device 0 */
> @@ -35,13 +37,23 @@ static struct mtd_partition nand_parts[] = {
> {
> .name = "root",
> .offset = 0x0200000,
> - .size = 0x3400000
> + .size = 0x3E00000
> + },
> + {
> + .name = "persistent",
> + .offset = 0x4000000,
> + .size = 0x4000000
> },
> {
> - .name = "user",
> - .offset = 0x3600000,
> - .size = 0x0A00000
> + .name = "persistent1",
> + .offset = 0x8000000,
> + .size = 0x4000000
> },
> + {
> + .name = "persistent2",
> + .offset = 0xC000000,
> + .size = 0x4000000
> + }
> };
Why is this information in the dts *and* the platform file? I haven't
been following the flash partition map binding conventions, but having
it in both places looks wrong....
oh, wait... the one in the dts is for NOR and this one is for NAND,
right? And we don't have a binding yet for NAND partitions yet,
correct?
>
> struct ndfc_controller_settings warp_ndfc_settings = {
> @@ -67,19 +79,15 @@ static struct platform_device warp_ndfc_device = {
> .resource = &warp_ndfc,
> };
>
> -static struct nand_ecclayout nand_oob_16 = {
> - .eccbytes = 3,
> - .eccpos = { 0, 1, 2, 3, 6, 7 },
> - .oobfree = { {.offset = 8, .length = 16} }
> -};
> -
> +/* Do NOT set the ecclayout: let it default so it is correct for both
> + * 64M and 256M flash chips.
> + */
> static struct platform_nand_chip warp_nand_chip0 = {
> .nr_chips = 1,
> .chip_offset = CS_NAND_0,
> .nr_partitions = ARRAY_SIZE(nand_parts),
> .partitions = nand_parts,
> - .chip_delay = 50,
> - .ecclayout = &nand_oob_16,
> + .chip_delay = 20,
> .priv = &warp_chip0_settings,
> };
>
> @@ -96,6 +104,23 @@ static struct platform_device warp_nand_device = {
>
> static int warp_setup_nand_flash(void)
> {
> + struct device_node *np;
> +
> + /* Try to detect a rev A based on NOR size. */
> + np = of_find_compatible_node(NULL, NULL, "cfi-flash");
> + if (np) {
> + struct property *pp;
> +
> + pp = of_find_property(np, "reg", NULL);
> + if (pp && (pp->length == 12)) {
> + u32 *v = pp->value;
> + if (v[2] == 0x4000000)
> + /* Rev A = 64M NAND */
> + warp_nand_chip0.nr_partitions = 2;
> + }
> + of_node_put(np);
> + }
> +
> platform_device_register(&warp_ndfc_device);
> platform_device_register(&warp_nand_device);
>
> diff --git a/arch/powerpc/platforms/44x/warp.c b/arch/powerpc/platforms/44x/warp.c
> index 39cf615..8f7d016 100644
>
> --- a/arch/powerpc/platforms/44x/warp.c
> +++ b/arch/powerpc/platforms/44x/warp.c
> @@ -12,6 +12,10 @@
>
> #include <linux/init.h>
> #include <linux/of_platform.h>
> #include <linux/kthread.h>
> +#include <linux/i2c.h>
> +#include <linux/interrupt.h>
> +#include <linux/pika.h>
> +#include <linux/delay.h>
>
>
> #include <asm/machdep.h>
> #include <asm/prom.h>
> @@ -27,6 +31,18 @@ static __initdata struct of_device_id warp_of_bus[] = {
>
> {},
> };
>
> +static __initdata struct i2c_board_info warp_i2c_info[] = {
> + { I2C_BOARD_INFO("ad7414", 0x4a) }
> +};
> +
> +static int __init warp_arch_init(void)
> +{
> + /* This should go away once support is moved to the dts. */
> + i2c_register_board_info(0, warp_i2c_info, ARRAY_SIZE(warp_i2c_info));
> + return 0;
> +}
> +machine_arch_initcall(warp, warp_arch_init);
> +
> static int __init warp_device_probe(void)
> {
> of_platform_bus_probe(NULL, warp_of_bus, NULL);
> @@ -52,61 +68,232 @@ define_machine(warp) {
>
>
> };
>
>
> -#define LED_GREEN (0x80000000 >> 0)
> -#define LED_RED (0x80000000 >> 1)
> +/* I am not sure this is the best place for this... */
> +static int __init warp_post_info(void)
> +{
> + struct device_node *np;
> + void __iomem *fpga;
> + u32 post1, post2;
> +
> + /* Sighhhh... POST information is in the sd area. */
> + np = of_find_compatible_node(NULL, NULL, "pika,fpga-sd");
> + if (np == NULL)
> + return -ENOENT;
> +
> + fpga = of_iomap(np, 0);
> + of_node_put(np);
> + if (fpga == NULL)
> + return -ENOENT;
> +
> + post1 = in_be32(fpga + 0x40);
> + post2 = in_be32(fpga + 0x44);
> +
> + iounmap(fpga);
> +
> + if (post1 || post2)
> + printk(KERN_INFO "Warp POST %08x %08x\n", post1, post2);
> + else
> + printk(KERN_INFO "Warp POST OK\n");
> +
> + return 0;
> +}
> +machine_late_initcall(warp, warp_post_info);
> +
> +
> +#ifdef CONFIG_SENSORS_AD7414
<snip>
> +#else /* !CONFIG_SENSORS_AD7414 */
>
> +
> +int dtm_register_shutdown(void (*func)(void *arg), void *arg)
> +{
> + return 0;
> +}
>
> +
> +int dtm_unregister_shutdown(void (*func)(void *arg), void *arg)
> +{
> + return 0;
> +}
> +
> #endif
> +
>
> +EXPORT_SYMBOL(dtm_register_shutdown);
>
> +EXPORT_SYMBOL(dtm_unregister_shutdown);
When exporting symbols for platform code you should avoid polluting
the global Linux namespace and prefix the functions with your platform
name.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: 2.6.25: pmac_newworld undefined
From: Sam Ravnborg @ 2008-04-28 19:33 UTC (permalink / raw)
To: Tony Breeds; +Cc: linuxppc-dev, LKML
In-Reply-To: <20080428042044.GX20457@bakeyournoodle.com>
On Mon, Apr 28, 2008 at 02:20:44PM +1000, Tony Breeds wrote:
> On Sun, Apr 27, 2008 at 08:03:46PM +0200, Christian Kujau wrote:
> > Hi,
> >
> > the build failure reported[0] by Kamalesh back in 01/2008 is still
> > present in today's 2.6.25-git with CONFIG_NVRAM=m (instead of =y):
> >
> > Building modules, stage 2.
> > MODPOST 72 modules
> > ERROR: "pmac_newworld" [arch/powerpc/platforms/powermac/nvram.ko] undefined!
> > ERROR: "__alloc_bootmem" [arch/powerpc/platforms/powermac/nvram.ko]
> > undefined!
> > make[1]: *** [__modpost] Error 1
>
> Yeah that isn't really surprising. Essentially
> arch/powerpc/platforms/powermac/nvram.c must be builtin (not modular)
> but CONFIG_NVRAM is tristate, and your .config has CONFIG_NVRAM=m.
>
> We can probably "fix" this by adding another config config symbol and
> "selecting" that from CONFIG_NVRAM. Then using this new symbol in
> arch/powerpc/platforms/powermac/*
>
> so I think with we need is:
> config NVRAM
> bool "..." if PPC32
> tristate "..." if !PPC32
> ...
> ...
>
> Sam is there some way to achieve that or should we just create an
> secondary symbol?
In the Makefile you could just do a:
obj-$(CONFIG_NVRAM:m=y) += nvram.o
Then you would force nvram to be build-in.
That looks simpler than messing with Kconfig in this case.
Sam
^ permalink raw reply
* Re: [PATCH] sysdev,mv64x60: MV64x60 device bus
From: Dale Farnsworth @ 2008-04-28 19:25 UTC (permalink / raw)
To: Remi Machet; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1209410557.14407.14.camel@pcds-ts102.slac.stanford.edu>
On Mon, Apr 28, 2008 at 12:22:36PM -0700, Remi Machet wrote:
> On Mon, 2008-04-28 at 11:09 -0700, Dale Farnsworth wrote:
> > On Mon, Apr 28, 2008 at 10:12:09AM -0700, Remi Machet wrote:
> > > Follow up of my email of 4/16/2008 titled "MV64x60 device bus".
> > > For each mv64360 entry in the OpenFirmware database, add the
> > > registration of an of_bus to take care of devices connected to
> > > the MV64x60 asynchronous devices controller.
> >
> > I'd like to see your dts file to see exactly how you're using it.
> Here it is, I removed everything that is not related to the subject:
>
> /dts-v1/;
>
> / {
> #address-cells = <1>;
> #size-cells = <1>;
> model = "C2K";
> compatible = "GEFanuc,C2K";
> coherency-off;
>
> <...>
>
> system-controller@d8000000 { /* Marvell Discovery */
> #address-cells = <1>;
> #size-cells = <1>;
> model = "mv64460";
> compatible = "marvell,mv64360";
>
> <...>
>
> /* Devices attached to the device controller */
> devicebus {
> device_type = "devicectrl";
> #address-cells = <1>;
> #size-cells = <1>;
> nor_flash {
> compatible = "cfi-flash";
> reg = <0xf8000000 0x8000000>; /* 128MB */
> bank-width = <4>;
> device-width = <1>;
> #address-cells = <1>;
> #size-cells = <1>;
> partition@0 {
> label = "boot";
> reg = <0x00000000 0x00080000>;
> };
> partition@40000 {
> label = "kernel";
> reg = <0x00080000 0x00400000>;
> };
> partition@440000 {
> label = "initrd";
> reg = <0x00480000 0x00B80000>;
> };
> partition@1000000 {
> label = "rootfs";
> reg = <0x01000000 0x06800000>;
> };
> partition@7800000 {
> label = "recovery";
> reg = <0x07800000 0x00800000>;
> read-only;
> };
> };
> };
> };
> <...>
> };
Thanks.
> > The only problem I see now is that you have introduced a new device
> > type, "devicectrl". New device types are frowned upon. It's better
> > to match based on the compatible field. Maybe use
> > "marvell,mv64306-devctrl" or similar.
> >
> Do you mean having the DTS file look like this:
Yes, exactly.
-Dale
> <...>
> devicebus {
> compatible = "marvell,mv64306-devctrl";
> #address-cells = <1>;
> #size-cells = <1>;
> nor_flash {
> compatible = "cfi-flash";
> reg = <0xf8000000 0x8000000>;
> <...>
> };
> };
>
> Remi
^ permalink raw reply
* Re: [PATCH] sysdev,mv64x60: MV64x60 device bus
From: Remi Machet @ 2008-04-28 19:22 UTC (permalink / raw)
To: Dale Farnsworth; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20080428180947.GA2691@farnsworth.org>
On Mon, 2008-04-28 at 11:09 -0700, Dale Farnsworth wrote:
> On Mon, Apr 28, 2008 at 10:12:09AM -0700, Remi Machet wrote:
> > Follow up of my email of 4/16/2008 titled "MV64x60 device bus".
> > For each mv64360 entry in the OpenFirmware database, add the
> > registration of an of_bus to take care of devices connected to
> > the MV64x60 asynchronous devices controller.
>
> I'd like to see your dts file to see exactly how you're using it.
Here it is, I removed everything that is not related to the subject:
/dts-v1/;
/ {
#address-cells = <1>;
#size-cells = <1>;
model = "C2K";
compatible = "GEFanuc,C2K";
coherency-off;
<...>
system-controller@d8000000 { /* Marvell Discovery */
#address-cells = <1>;
#size-cells = <1>;
model = "mv64460";
compatible = "marvell,mv64360";
<...>
/* Devices attached to the device controller */
devicebus {
device_type = "devicectrl";
#address-cells = <1>;
#size-cells = <1>;
nor_flash {
compatible = "cfi-flash";
reg = <0xf8000000 0x8000000>; /* 128MB */
bank-width = <4>;
device-width = <1>;
#address-cells = <1>;
#size-cells = <1>;
partition@0 {
label = "boot";
reg = <0x00000000 0x00080000>;
};
partition@40000 {
label = "kernel";
reg = <0x00080000 0x00400000>;
};
partition@440000 {
label = "initrd";
reg = <0x00480000 0x00B80000>;
};
partition@1000000 {
label = "rootfs";
reg = <0x01000000 0x06800000>;
};
partition@7800000 {
label = "recovery";
reg = <0x07800000 0x00800000>;
read-only;
};
};
};
};
<...>
};
>
> The only problem I see now is that you have introduced a new device
> type, "devicectrl". New device types are frowned upon. It's better
> to match based on the compatible field. Maybe use
> "marvell,mv64306-devctrl" or similar.
>
Do you mean having the DTS file look like this:
<...>
devicebus {
compatible = "marvell,mv64306-devctrl";
#address-cells = <1>;
#size-cells = <1>;
nor_flash {
compatible = "cfi-flash";
reg = <0xf8000000 0x8000000>;
<...>
};
};
Remi
^ permalink raw reply
* Re: [RESEND][PATCH][POWERPC] PIKA Warp: Update platform code to supportRev B boards
From: Sean MacLennan @ 2008-04-28 18:53 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20080417152251.2bf07219@lappy.seanm.ca>
Ok, here is another version of the patch with Stephen Rothwell's and
Grant Likely's suggestions.
Cheers,
Sean
PIKA Warp: Update platform code to support Rev B boards.
* Switched from 64M NOR/64M NAND to 4M NOR/256M NAND.
* Full DTM support including critical temperature.
* Added POST information.
* Removed LED function, moved to new LED driver.
* Moved ad7414 to new style I2C initialization.
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
diff --git a/arch/powerpc/boot/cuboot-warp.c b/arch/powerpc/boot/cuboot-warp.c
index eb108a8..2178021 100644
--- a/arch/powerpc/boot/cuboot-warp.c
+++ b/arch/powerpc/boot/cuboot-warp.c
@@ -10,6 +10,7 @@
#include "ops.h"
#include "4xx.h"
#include "cuboot.h"
+#include "stdio.h"
#define TARGET_4xx
#define TARGET_44x
@@ -17,14 +18,54 @@
static bd_t bd;
-static void warp_fixups(void)
+static void warp_fixup_one_nor(u32 from, u32 to)
{
- unsigned long sysclk = 66000000;
+ void *devp;
+ char name[50];
+ u32 v[2];
+
+ sprintf(name, "/plb/opb/ebc/nor_flash@0,0/partition@%x", from);
+
+ devp = finddevice(name);
+ if (!devp)
+ return;
+
+ if (getprop(devp, "reg", v, sizeof(v)) == sizeof(v)) {
+ v[0] = to;
+ setprop(devp, "reg", v, sizeof(v));
+
+ printf("NOR 64M fixup %x -> %x\r\n", from, to);
+ }
+}
+
- ibm440ep_fixup_clocks(sysclk, 11059200, 50000000);
+static void warp_fixups(void)
+{
+ ibm440ep_fixup_clocks(66000000, 11059200, 50000000);
ibm4xx_sdram_fixup_memsize();
ibm4xx_fixup_ebc_ranges("/plb/opb/ebc");
dt_fixup_mac_address_by_alias("ethernet0", bd.bi_enetaddr);
+
+ /* Fixup for 64M flash on Rev A boards. */
+ if (bd.bi_flashsize == 0x4000000) {
+ void *devp;
+ u32 v[3];
+
+ devp = finddevice("/plb/opb/ebc/nor_flash@0,0");
+ if (!devp)
+ return;
+
+ /* Fixup the size */
+ if (getprop(devp, "reg", v, sizeof(v)) == sizeof(v)) {
+ v[2] = bd.bi_flashsize;
+ setprop(devp, "reg", v, sizeof(v));
+ }
+
+ /* Fixup parition offsets */
+ warp_fixup_one_nor(0x300000, 0x3f00000);
+ warp_fixup_one_nor(0x340000, 0x3f40000);
+ warp_fixup_one_nor(0x380000, 0x3f80000);
+ }
}
diff --git a/arch/powerpc/boot/dts/warp.dts b/arch/powerpc/boot/dts/warp.dts
index b04a52e..d124497 100644
--- a/arch/powerpc/boot/dts/warp.dts
+++ b/arch/powerpc/boot/dts/warp.dts
@@ -132,40 +132,33 @@
fpga@2,0 {
compatible = "pika,fpga";
- reg = <2 0 2200>;
+ reg = <2 0 1000>;
interrupts = <18 8>;
interrupt-parent = <&UIC0>;
};
+ fpga@2,4000 {
+ compatible = "pika,fpga-sd";
+ reg = <2 4000 A00>;
+ };
+
nor_flash@0,0 {
- compatible = "amd,s29gl512n", "cfi-flash";
+ compatible = "amd,s29gl032a", "cfi-flash";
bank-width = <2>;
- reg = <0 0 4000000>;
+ reg = <0 0 400000>;
#address-cells = <1>;
#size-cells = <1>;
- partition@0 {
- label = "kernel";
- reg = <0 180000>;
- };
- partition@180000 {
- label = "root";
- reg = <180000 3480000>;
- };
- partition@3600000 {
- label = "user";
- reg = <3600000 900000>;
- };
- partition@3f00000 {
+ partition@300000 {
label = "fpga";
- reg = <3f00000 40000>;
+ reg = <300000 40000>;
};
- partition@3f40000 {
+ partition@340000 {
label = "env";
- reg = <3f40000 40000>;
+ reg = <340000 40000>;
};
- partition@3f80000 {
+ partition@380000 {
label = "u-boot";
- reg = <3f80000 80000>;
+ reg = <380000 80000>;
};
};
};
@@ -186,6 +179,16 @@
reg = <ef600700 14>;
interrupt-parent = <&UIC0>;
interrupts = <2 4>;
+ index = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ad7414@4a {
+ compatible = "adi,ad7414";
+ reg = <4a>;
+ interrupts = <19 8>;
+ interrupt-parent = <&UIC0>;
+ };
};
GPIO0: gpio@ef600b00 {
@@ -196,8 +199,22 @@
GPIO1: gpio@ef600c00 {
compatible = "ibm,gpio-440ep";
reg = <ef600c00 48>;
+
+ };
+
+ led@31 {
+ compatible = "linux,gpio-led";
+ linux,name = "green";
+ gpios = <&GPIO1 31>;
+ };
+
+ led@30 {
+ compatible = "linux,gpio-led";
+ linux,name = "red";
+ gpios = <&GPIO1 30>;
};
+
ZMII0: emac-zmii@ef600d00 {
compatible = "ibm,zmii-440ep", "ibm,zmii-440gp", "ibm,zmii";
reg = <ef600d00 c>;
diff --git a/arch/powerpc/platforms/44x/warp-nand.c b/arch/powerpc/platforms/44x/warp-nand.c
index 9150318..d293c70 100644
--- a/arch/powerpc/platforms/44x/warp-nand.c
+++ b/arch/powerpc/platforms/44x/warp-nand.c
@@ -11,8 +11,10 @@
#include <linux/mtd/partitions.h>
#include <linux/mtd/nand.h>
#include <linux/mtd/ndfc.h>
+#include <linux/of.h>
#include <asm/machdep.h>
+
#ifdef CONFIG_MTD_NAND_NDFC
#define CS_NAND_0 1 /* use chip select 1 for NAND device 0 */
@@ -35,13 +37,23 @@ static struct mtd_partition nand_parts[] = {
{
.name = "root",
.offset = 0x0200000,
- .size = 0x3400000
+ .size = 0x3E00000
+ },
+ {
+ .name = "persistent",
+ .offset = 0x4000000,
+ .size = 0x4000000
},
{
- .name = "user",
- .offset = 0x3600000,
- .size = 0x0A00000
+ .name = "persistent1",
+ .offset = 0x8000000,
+ .size = 0x4000000
},
+ {
+ .name = "persistent2",
+ .offset = 0xC000000,
+ .size = 0x4000000
+ }
};
struct ndfc_controller_settings warp_ndfc_settings = {
@@ -67,19 +79,15 @@ static struct platform_device warp_ndfc_device = {
.resource = &warp_ndfc,
};
-static struct nand_ecclayout nand_oob_16 = {
- .eccbytes = 3,
- .eccpos = { 0, 1, 2, 3, 6, 7 },
- .oobfree = { {.offset = 8, .length = 16} }
-};
-
+/* Do NOT set the ecclayout: let it default so it is correct for both
+ * 64M and 256M flash chips.
+ */
static struct platform_nand_chip warp_nand_chip0 = {
.nr_chips = 1,
.chip_offset = CS_NAND_0,
.nr_partitions = ARRAY_SIZE(nand_parts),
.partitions = nand_parts,
- .chip_delay = 50,
- .ecclayout = &nand_oob_16,
+ .chip_delay = 20,
.priv = &warp_chip0_settings,
};
@@ -96,6 +104,23 @@ static struct platform_device warp_nand_device = {
static int warp_setup_nand_flash(void)
{
+ struct device_node *np;
+
+ /* Try to detect a rev A based on NOR size. */
+ np = of_find_compatible_node(NULL, NULL, "cfi-flash");
+ if (np) {
+ struct property *pp;
+
+ pp = of_find_property(np, "reg", NULL);
+ if (pp && (pp->length == 12)) {
+ u32 *v = pp->value;
+ if (v[2] == 0x4000000)
+ /* Rev A = 64M NAND */
+ warp_nand_chip0.nr_partitions = 2;
+ }
+ of_node_put(np);
+ }
+
platform_device_register(&warp_ndfc_device);
platform_device_register(&warp_nand_device);
diff --git a/arch/powerpc/platforms/44x/warp.c b/arch/powerpc/platforms/44x/warp.c
index 39cf615..8f7d016 100644
--- a/arch/powerpc/platforms/44x/warp.c
+++ b/arch/powerpc/platforms/44x/warp.c
@@ -12,6 +12,10 @@
#include <linux/init.h>
#include <linux/of_platform.h>
#include <linux/kthread.h>
+#include <linux/i2c.h>
+#include <linux/interrupt.h>
+#include <linux/pika.h>
+#include <linux/delay.h>
#include <asm/machdep.h>
#include <asm/prom.h>
@@ -27,6 +31,18 @@ static __initdata struct of_device_id warp_of_bus[] = {
{},
};
+static __initdata struct i2c_board_info warp_i2c_info[] = {
+ { I2C_BOARD_INFO("ad7414", 0x4a) }
+};
+
+static int __init warp_arch_init(void)
+{
+ /* This should go away once support is moved to the dts. */
+ i2c_register_board_info(0, warp_i2c_info, ARRAY_SIZE(warp_i2c_info));
+ return 0;
+}
+machine_arch_initcall(warp, warp_arch_init);
+
static int __init warp_device_probe(void)
{
of_platform_bus_probe(NULL, warp_of_bus, NULL);
@@ -52,61 +68,232 @@ define_machine(warp) {
};
-#define LED_GREEN (0x80000000 >> 0)
-#define LED_RED (0x80000000 >> 1)
+/* I am not sure this is the best place for this... */
+static int __init warp_post_info(void)
+{
+ struct device_node *np;
+ void __iomem *fpga;
+ u32 post1, post2;
+
+ /* Sighhhh... POST information is in the sd area. */
+ np = of_find_compatible_node(NULL, NULL, "pika,fpga-sd");
+ if (np == NULL)
+ return -ENOENT;
+
+ fpga = of_iomap(np, 0);
+ of_node_put(np);
+ if (fpga == NULL)
+ return -ENOENT;
+
+ post1 = in_be32(fpga + 0x40);
+ post2 = in_be32(fpga + 0x44);
+
+ iounmap(fpga);
+
+ if (post1 || post2)
+ printk(KERN_INFO "Warp POST %08x %08x\n", post1, post2);
+ else
+ printk(KERN_INFO "Warp POST OK\n");
+
+ return 0;
+}
+machine_late_initcall(warp, warp_post_info);
+
+
+#ifdef CONFIG_SENSORS_AD7414
+
+static LIST_HEAD(dtm_shutdown_list);
+static void __iomem *dtm_fpga;
+static void __iomem *gpio_base;
+
+
+struct dtm_shutdown {
+ struct list_head list;
+ void (*func)(void *arg);
+ void *arg;
+};
-/* This is for the power LEDs 1 = on, 0 = off, -1 = leave alone */
-void warp_set_power_leds(int green, int red)
+int dtm_register_shutdown(void (*func)(void *arg), void *arg)
{
- static void __iomem *gpio_base = NULL;
- unsigned leds;
-
- if (gpio_base == NULL) {
- struct device_node *np;
-
- /* Power LEDS are on the second GPIO controller */
- np = of_find_compatible_node(NULL, NULL, "ibm,gpio-440EP");
- if (np)
- np = of_find_compatible_node(np, NULL, "ibm,gpio-440EP");
- if (np == NULL) {
- printk(KERN_ERR __FILE__ ": Unable to find gpio\n");
- return;
+ struct dtm_shutdown *shutdown;
+
+ shutdown = kmalloc(sizeof(struct dtm_shutdown), GFP_KERNEL);
+ if (shutdown == NULL)
+ return -ENOMEM;
+
+ shutdown->func = func;
+ shutdown->arg = arg;
+
+ list_add(&shutdown->list, &dtm_shutdown_list);
+
+ return 0;
+}
+
+int dtm_unregister_shutdown(void (*func)(void *arg), void *arg)
+{
+ struct dtm_shutdown *shutdown;
+
+ list_for_each_entry(shutdown, &dtm_shutdown_list, list)
+ if (shutdown->func == func && shutdown->arg == arg) {
+ list_del(&shutdown->list);
+ kfree(shutdown);
+ return 0;
+ }
+
+ return -EINVAL;
+}
+
+static irqreturn_t temp_isr(int irq, void *context)
+{
+ struct dtm_shutdown *shutdown;
+
+ local_irq_disable();
+
+ /* Run through the shutdown list. */
+ list_for_each_entry(shutdown, &dtm_shutdown_list, list)
+ shutdown->func(shutdown->arg);
+
+ printk(KERN_EMERG "\n\nCritical Temperature Shutdown\n");
+
+ while (1) {
+ if (dtm_fpga) {
+ unsigned reset = in_be32(dtm_fpga + 0x14);
+ out_be32(dtm_fpga + 0x14, reset);
}
- gpio_base = of_iomap(np, 0);
- of_node_put(np);
- if (gpio_base == NULL) {
- printk(KERN_ERR __FILE__ ": Unable to map gpio");
- return;
+ if (gpio_base) {
+ unsigned leds = in_be32(gpio_base);
+
+ /* green off, red toggle */
+ leds &= ~0x80000000;
+ leds ^= 0x40000000;
+
+ out_be32(gpio_base, leds);
}
+
+ mdelay(500);
+ }
+}
+
+static int pika_setup_leds(void)
+{
+ struct device_node *np;
+ const u32 *gpios;
+ int lenp;
+
+ np = of_find_compatible_node(NULL, NULL, "linux,gpio-led");
+ if (!np) {
+ printk(KERN_ERR __FILE__ ": Unable to find gpio-led\n");
+ return -ENOENT;
}
- leds = in_be32(gpio_base);
+ gpios = of_get_property(np, "gpios", &lenp);
+ of_node_put(np);
+ if (!gpios || lenp != 8) {
+ printk(KERN_ERR __FILE__
+ ": Unable to get gpios property (%d)\n", lenp);
+ return -ENOENT;
+ }
- switch (green) {
- case 0: leds &= ~LED_GREEN; break;
- case 1: leds |= LED_GREEN; break;
+ np = of_find_node_by_phandle(gpios[0]);
+ if (!np) {
+ printk(KERN_ERR __FILE__ ": Unable to find gpio\n");
+ return -ENOENT;
}
- switch (red) {
- case 0: leds &= ~LED_RED; break;
- case 1: leds |= LED_RED; break;
+
+ gpio_base = of_iomap(np, 0);
+ of_node_put(np);
+ if (!gpio_base) {
+ printk(KERN_ERR __FILE__ ": Unable to map gpio");
+ return -ENOMEM;
}
- out_be32(gpio_base, leds);
+ return 0;
}
-EXPORT_SYMBOL(warp_set_power_leds);
+static void pika_setup_critical_temp(struct i2c_client *client)
+{
+ struct device_node *np;
+ int irq, rc;
+
+ /* Do this before enabling critical temp interrupt since we
+ * may immediately interrupt.
+ */
+ pika_setup_leds();
+
+ /* These registers are in 1 degree increments. */
+ i2c_smbus_write_byte_data(client, 2, 65); /* Thigh */
+ i2c_smbus_write_byte_data(client, 3, 55); /* Tlow */
+
+ np = of_find_compatible_node(NULL, NULL, "adi,ad7414");
+ if (np == NULL) {
+ printk(KERN_ERR __FILE__ ": Unable to find ad7414\n");
+ return;
+ }
+
+ irq = irq_of_parse_and_map(np, 0);
+ of_node_put(np);
+ if (irq == NO_IRQ) {
+ printk(KERN_ERR __FILE__ ": Unable to get ad7414 irq\n");
+ return;
+ }
+
+ rc = request_irq(irq, temp_isr, 0, "ad7414", NULL);
+ if (rc) {
+ printk(KERN_ERR __FILE__
+ ": Unable to request ad7414 irq %d = %d\n", irq, rc);
+ return;
+ }
+}
+
+static inline void pika_dtm_check_fan(void __iomem *fpga)
+{
+ static int fan_state;
+ u32 fan = in_be32(fpga + 0x34) & (1 << 14);
+
+ if (fan_state != fan) {
+ fan_state = fan;
+ if (fan)
+ printk(KERN_WARNING "Fan rotation error detected."
+ " Please check hardware.\n");
+ }
+}
-#ifdef CONFIG_SENSORS_AD7414
static int pika_dtm_thread(void __iomem *fpga)
{
- extern int ad7414_get_temp(int index);
+ struct i2c_adapter *adap;
+ struct i2c_client *client;
+
+ /* We loop in case either driver was compiled as a module and
+ * has not been insmoded yet.
+ */
+ while (!(adap = i2c_get_adapter(0))) {
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule_timeout(HZ);
+ }
+
+ while (1) {
+ list_for_each_entry(client, &adap->clients, list)
+ if (client->addr == 0x4a)
+ goto found_it;
+
+ set_current_state(TASK_INTERRUPTIBLE);
+ schedule_timeout(HZ);
+ }
+
+found_it:
+ i2c_put_adapter(adap);
+
+ pika_setup_critical_temp(client);
+
+ printk(KERN_INFO "PIKA DTM thread running.\n");
while (!kthread_should_stop()) {
- int temp = ad7414_get_temp(0);
+ u16 temp = swab16(i2c_smbus_read_word_data(client, 0));
+ out_be32(fpga + 0x20, temp);
- out_be32(fpga, temp);
+ pika_dtm_check_fan(fpga);
set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout(HZ);
@@ -115,37 +302,44 @@ static int pika_dtm_thread(void __iomem *fpga)
return 0;
}
+
static int __init pika_dtm_start(void)
{
struct task_struct *dtm_thread;
struct device_node *np;
- struct resource res;
- void __iomem *fpga;
np = of_find_compatible_node(NULL, NULL, "pika,fpga");
if (np == NULL)
return -ENOENT;
- /* We do not call of_iomap here since it would map in the entire
- * fpga space, which is over 8k.
- */
- if (of_address_to_resource(np, 0, &res)) {
- of_node_put(np);
- return -ENOENT;
- }
+ dtm_fpga = of_iomap(np, 0);
of_node_put(np);
-
- fpga = ioremap(res.start, 0x24);
- if (fpga == NULL)
+ if (dtm_fpga == NULL)
return -ENOENT;
- dtm_thread = kthread_run(pika_dtm_thread, fpga + 0x20, "pika-dtm");
+ dtm_thread = kthread_run(pika_dtm_thread, dtm_fpga, "pika-dtm");
if (IS_ERR(dtm_thread)) {
- iounmap(fpga);
+ iounmap(dtm_fpga);
return PTR_ERR(dtm_thread);
}
return 0;
}
-device_initcall(pika_dtm_start);
+machine_late_initcall(warp, pika_dtm_start);
+
+#else /* !CONFIG_SENSORS_AD7414 */
+
+int dtm_register_shutdown(void (*func)(void *arg), void *arg)
+{
+ return 0;
+}
+
+int dtm_unregister_shutdown(void (*func)(void *arg), void *arg)
+{
+ return 0;
+}
+
#endif
+
+EXPORT_SYMBOL(dtm_register_shutdown);
+EXPORT_SYMBOL(dtm_unregister_shutdown);
^ permalink raw reply related
* Re: [PATCH 4/7] mpc83xx: timer driver for PM wakeup
From: Scott Wood @ 2008-04-28 18:15 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, linux-pm, Paul Mackerras
In-Reply-To: <Pine.LNX.4.64.0804281721050.7897@axis700.grange>
On Mon, Apr 28, 2008 at 05:39:32PM +0200, Guennadi Liakhovetski wrote:
> This is a driver for the mpc83xx's GTM4 timer. It's functionality
> is limited to providing a wakeup source for suspend-to-RAM.
This driver should be redone as a client of Anton's more general GTM
driver.
-Scott
^ permalink raw reply
* Re: [PATCH] MTD: fix partition scan control logic in physmap_ofand fsl_elbc_nand
From: Scott Wood @ 2008-04-28 18:13 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev, Stefan Roese, David Woodhouse, linux-mtd
In-Reply-To: <989B956029373F45A0B8AF029708189002007C8F@zch01exm26.fsl.freescale.net>
On Fri, Apr 25, 2008 at 07:09:59PM +0800, Li Yang wrote:
> The error can also be soft error like a typo in the cmdline or device
> tree. I could be better to try other ways to see if we can find a sane
> partition table than just to fail.
If cmdline partition information exists, typo or not, then obviously
there was intent for the cmdline to be used. It's better to let the user
know there's a problem than silently fall back to some other, likely
wrong partition information.
-Scott
^ permalink raw reply
* Re: [PATCH] sysdev,mv64x60: MV64x60 device bus
From: Dale Farnsworth @ 2008-04-28 18:09 UTC (permalink / raw)
To: Remi Machet; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1209402729.14407.2.camel@pcds-ts102.slac.stanford.edu>
On Mon, Apr 28, 2008 at 10:12:09AM -0700, Remi Machet wrote:
> Follow up of my email of 4/16/2008 titled "MV64x60 device bus".
> For each mv64360 entry in the OpenFirmware database, add the
> registration of an of_bus to take care of devices connected to
> the MV64x60 asynchronous devices controller.
I'd like to see your dts file to see exactly how you're using it.
The only problem I see now is that you have introduced a new device
type, "devicectrl". New device types are frowned upon. It's better
to match based on the compatible field. Maybe use
"marvell,mv64306-devctrl" or similar.
-Dale
^ permalink raw reply
* Re: suggestions on handling additional exception levels on ppc32
From: Kumar Gala @ 2008-04-28 18:06 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <20080428170418.GA11378@ld0162-tx32.am.freescale.net>
On Apr 28, 2008, at 12:04 PM, Scott Wood wrote:
> On Mon, Apr 28, 2008 at 11:58:58AM -0500, Kumar Gala wrote:
>>
>> On Apr 28, 2008, at 10:59 AM, Scott Wood wrote:
>>> On Mon, Apr 28, 2008 at 10:40:56AM -0500, Kumar Gala wrote:
>>>> A few possibilities:
>>>> * introduce an additional function pointer as part of
>>>> EXC_XFER_TEMPLATE() to specifies the type of handler (normal, crit,
>>>> dbg, mcheck)
>>>> * use the traps field low order bits to determine normal, crit,
>>>> dbg,
>>>> mcheck at run time.
>>>> * duplicate the code paths for each exception level
>>>>
>>>> suggestions?
>>>
>>> You could temporarily disable all asynchronous exceptions, and use
>>> the
>>> registers of the highest-priority exception type.
>>
>> That doesn't work. We have NMIs or will have them in the future.
>
> Truly non-maskable? Ick. You could have a separate code path just
> for
> the exception type that NMIs use, I guess, if there's a clear
> highest-priority among the remaining interrupt types. What sort of
> exceptions are they?
The NMIs are machine check only so a separate path for them isn't a
terrible idea.
However, disabling all other interrupts seems worse than adding a
function pointer.
- k
^ permalink raw reply
* Re: [RESEND][PATCH][POWERPC] PIKA Warp: Update platform code to supportRev B boards
From: Sean MacLennan @ 2008-04-28 17:59 UTC (permalink / raw)
To: Grant Likely; +Cc: Stephen Rothwell, rpurdie, Sean MacLennan, linuxppc-dev
In-Reply-To: <fa686aa40804281044p5fa0ef9s15107cc38fafc9fa@mail.gmail.com>
On Mon, 28 Apr 2008 11:44:19 -0600
"Grant Likely" <grant.likely@secretlab.ca> wrote:
> This looks appropriate. You'll need to make sure that the values in
> the linux,name property meet the Linux LED naming guidelines. I think
> this is covered in Documentation/leds-class.c. You can also as
> Richard Purdie; the LED subsystem maintainer.
The leds name is "devicename:colour:function" where you are allowed to
leave sections blank. So I only filled in the colour ;)
I also notice that it is colour, not color.
I am hoping that this code is only for 2.6.26 and that we will switch
to the gpio-leds driver for 2.6.27. I don't want to keep supporting yet
another driver outside of the mainline kernel. Let's face it, I'm
lazy :D
Cheers,
Sean
^ permalink raw reply
* Re: [RESEND][PATCH][POWERPC] PIKA Warp: Update platform code to supportRev B boards
From: Grant Likely @ 2008-04-28 17:44 UTC (permalink / raw)
To: Sean MacLennan; +Cc: Stephen Rothwell, rpurdie, linuxppc-dev
In-Reply-To: <20080428131001.052be010@lappy.seanm.ca>
On Mon, Apr 28, 2008 at 11:10 AM, Sean MacLennan
<smaclennan@pikatech.com> wrote:
> On Sun, 27 Apr 2008 22:47:43 -0600
>
> "Grant Likely" <grant.likely@secretlab.ca> wrote:
>
>
> > If your LEDs are attached to gpio pins, then you should use the
> > current draft led->gpio bindings as shown in the above patch. Then,
> > let your platform code extract whatever data it needs from the device
> > tree to set up the LEDs.
>
> I added the following to the dts:
>
> led@31 {
> compatible = "linux,gpio-led";
> linux,name = "green";
> gpios = <&GPIO1 31>;
> };
>
> led@30 {
> compatible = "linux,gpio-led";
> linux,name = "red";
> gpios = <&GPIO1 30>;
> };
This looks appropriate. You'll need to make sure that the values in
the linux,name property meet the Linux LED naming guidelines. I think
this is covered in Documentation/leds-class.c. You can also as
Richard Purdie; the LED subsystem maintainer.
> I then map the gpio base as follows (I removed the if checks just to
> make things short and sweet):
>
> np = of_find_compatible_node(NULL, NULL, "linux,gpio-led");
>
> gpios = of_get_property(np, "gpios", &lenp);
> of_node_put(np);
>
> np = of_find_node_by_phandle(gpios[0]);
>
>
> gpio_base = of_iomap(np, 0);
> of_node_put(np);
This isn't ideal, but it will do to start. However, if other devices
want to use the same GPIO block, then you'll probably have problems
with race conditions. Eventually, you'll want to use the common GPIO
infrastructure and remove the custom code.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* [PATCH] sysdev,mv64x60: MV64x60 device bus
From: Remi Machet @ 2008-04-28 17:12 UTC (permalink / raw)
To: Paul Mackerras, Dale Farnsworth; +Cc: linuxppc-dev
Follow up of my email of 4/16/2008 titled "MV64x60 device bus".
For each mv64360 entry in the OpenFirmware database, add the
registration of an of_bus to take care of devices connected to
the MV64x60 asynchronous devices controller.
Signed-off-by: Remi Machet (rmachet@slac.stanford.edu)
---
I did not modify the PRPMC2800 dts file to use that feature because
I cannot test it on that board. I will soon submit a patch to add
support for a board that makes use of this feature. If someone want
to use that feature to register the PRPMC2800 flash you just need
to move the NOR flash declaration in a subcategory whose device_type
field is set to "devicectrl".
arch/powerpc/sysdev/mv64x60_dev.c | 10 ++++++++++
1 files changed, 10 insertions(+)
diff --git a/arch/powerpc/sysdev/mv64x60_dev.c b/arch/powerpc/sysdev/mv64x60_dev.c
index 41af122..f335fd5 100644
--- a/arch/powerpc/sysdev/mv64x60_dev.c
+++ b/arch/powerpc/sysdev/mv64x60_dev.c
@@ -15,6 +15,7 @@
#include <linux/console.h>
#include <linux/mv643xx.h>
#include <linux/platform_device.h>
+#include <linux/of_platform.h>
#include <asm/prom.h>
@@ -25,6 +26,11 @@
* PowerPC of_platform_bus_type. They support platform_bus_type instead.
*/
+static struct of_device_id of_mv64x60_devices[] = {
+ { .type = "devicectrl", },
+ {}
+};
+
/*
* Create MPSC platform devices
*/
@@ -482,6 +488,10 @@ static int __init mv64x60_device_setup(void)
of_node_put(np);
}
+ /* Now add every node that is on the device bus (type is devicectrl */
+ for_each_compatible_node(np, NULL, "marvell,mv64360")
+ of_platform_bus_probe(np, of_mv64x60_devices, NULL);
+
return 0;
}
arch_initcall(mv64x60_device_setup);
^ permalink raw reply related
* Re: [RESEND][PATCH][POWERPC] PIKA Warp: Update platform code to supportRev B boards
From: Sean MacLennan @ 2008-04-28 17:10 UTC (permalink / raw)
To: Grant Likely; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <fa686aa40804272147y54df795fj7e8dad89dc237ecd@mail.gmail.com>
On Sun, 27 Apr 2008 22:47:43 -0600
"Grant Likely" <grant.likely@secretlab.ca> wrote:
> If your LEDs are attached to gpio pins, then you should use the
> current draft led->gpio bindings as shown in the above patch. Then,
> let your platform code extract whatever data it needs from the device
> tree to set up the LEDs.
I added the following to the dts:
led@31 {
compatible = "linux,gpio-led";
linux,name = "green";
gpios = <&GPIO1 31>;
};
led@30 {
compatible = "linux,gpio-led";
linux,name = "red";
gpios = <&GPIO1 30>;
};
I then map the gpio base as follows (I removed the if checks just to
make things short and sweet):
np = of_find_compatible_node(NULL, NULL, "linux,gpio-led");
gpios = of_get_property(np, "gpios", &lenp);
of_node_put(np);
np = of_find_node_by_phandle(gpios[0]);
gpio_base = of_iomap(np, 0);
of_node_put(np);
Comments?
Cheers,
Sean
^ permalink raw reply
* Re: suggestions on handling additional exception levels on ppc32
From: Scott Wood @ 2008-04-28 17:04 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <F8B7AFF4-85EE-4C6B-99A5-E59B416EE78B@kernel.crashing.org>
On Mon, Apr 28, 2008 at 11:58:58AM -0500, Kumar Gala wrote:
>
> On Apr 28, 2008, at 10:59 AM, Scott Wood wrote:
> >On Mon, Apr 28, 2008 at 10:40:56AM -0500, Kumar Gala wrote:
> >>A few possibilities:
> >>* introduce an additional function pointer as part of
> >>EXC_XFER_TEMPLATE() to specifies the type of handler (normal, crit,
> >>dbg, mcheck)
> >>* use the traps field low order bits to determine normal, crit, dbg,
> >>mcheck at run time.
> >>* duplicate the code paths for each exception level
> >>
> >>suggestions?
> >
> >You could temporarily disable all asynchronous exceptions, and use the
> >registers of the highest-priority exception type.
>
> That doesn't work. We have NMIs or will have them in the future.
Truly non-maskable? Ick. You could have a separate code path just for
the exception type that NMIs use, I guess, if there's a clear
highest-priority among the remaining interrupt types. What sort of
exceptions are they?
-Scott
^ permalink raw reply
* Re: suggestions on handling additional exception levels on ppc32
From: Kumar Gala @ 2008-04-28 16:58 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <20080428155928.GE9849@ld0162-tx32.am.freescale.net>
On Apr 28, 2008, at 10:59 AM, Scott Wood wrote:
> On Mon, Apr 28, 2008 at 10:40:56AM -0500, Kumar Gala wrote:
>> A few possibilities:
>> * introduce an additional function pointer as part of
>> EXC_XFER_TEMPLATE() to specifies the type of handler (normal, crit,
>> dbg, mcheck)
>> * use the traps field low order bits to determine normal, crit, dbg,
>> mcheck at run time.
>> * duplicate the code paths for each exception level
>>
>> suggestions?
>
> You could temporarily disable all asynchronous exceptions, and use the
> registers of the highest-priority exception type.
That doesn't work. We have NMIs or will have them in the future.
- k
^ permalink raw reply
* IB/ehca: handle negative return value from ibmebus_request_irq() properly in ehca_create_eq()
From: Hoang-Nam Nguyen @ 2008-04-28 16:47 UTC (permalink / raw)
To: Roland Dreier, general, Roel Kluin
Cc: linuxppc-dev, Christoph Raisch, linux-kernel
Signed-off-by: Hoang-Nam Nguyen <hnguyen@de.ibm.com>
---
drivers/infiniband/hw/ehca/ehca_eq.c | 35 ++++++++++++++++-----------------
1 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_eq.c b/drivers/infiniband/hw/ehca/ehca_eq.c
index b4ac617..49660df 100644
--- a/drivers/infiniband/hw/ehca/ehca_eq.c
+++ b/drivers/infiniband/hw/ehca/ehca_eq.c
@@ -54,7 +54,8 @@ int ehca_create_eq(struct ehca_shca *shca,
struct ehca_eq *eq,
const enum ehca_eq_type type, const u32 length)
{
- u64 ret;
+ int ret;
+ u64 h_ret;
u32 nr_pages;
u32 i;
void *vpage;
@@ -73,15 +74,15 @@ int ehca_create_eq(struct ehca_shca *shca,
return -EINVAL;
}
- ret = hipz_h_alloc_resource_eq(shca->ipz_hca_handle,
- &eq->pf,
- type,
- length,
- &eq->ipz_eq_handle,
- &eq->length,
- &nr_pages, &eq->ist);
+ h_ret = hipz_h_alloc_resource_eq(shca->ipz_hca_handle,
+ &eq->pf,
+ type,
+ length,
+ &eq->ipz_eq_handle,
+ &eq->length,
+ &nr_pages, &eq->ist);
- if (ret != H_SUCCESS) {
+ if (h_ret != H_SUCCESS) {
ehca_err(ib_dev, "Can't allocate EQ/NEQ. eq=%p", eq);
return -EINVAL;
}
@@ -97,24 +98,22 @@ int ehca_create_eq(struct ehca_shca *shca,
u64 rpage;
vpage = ipz_qpageit_get_inc(&eq->ipz_queue);
- if (!vpage) {
- ret = H_RESOURCE;
+ if (!vpage)
goto create_eq_exit2;
- }
rpage = virt_to_abs(vpage);
- ret = hipz_h_register_rpage_eq(shca->ipz_hca_handle,
- eq->ipz_eq_handle,
- &eq->pf,
- 0, 0, rpage, 1);
+ h_ret = hipz_h_register_rpage_eq(shca->ipz_hca_handle,
+ eq->ipz_eq_handle,
+ &eq->pf,
+ 0, 0, rpage, 1);
if (i == (nr_pages - 1)) {
/* last page */
vpage = ipz_qpageit_get_inc(&eq->ipz_queue);
- if (ret != H_SUCCESS || vpage)
+ if (h_ret != H_SUCCESS || vpage)
goto create_eq_exit2;
} else {
- if (ret != H_PAGE_REGISTERED || !vpage)
+ if (h_ret != H_PAGE_REGISTERED || !vpage)
goto create_eq_exit2;
}
}
--
1.5.5
^ permalink raw reply related
* RE: [PATCH 1/2] [MTD] Add support for RAM & ROMmappings in the physmap_of MTD driver.
From: Rune Torgersen @ 2008-04-28 16:26 UTC (permalink / raw)
To: Laurent Pinchart, Sergei Shtylyov
Cc: ben, linuxppc-dev, linux-mtd, David Woodhouse, David Gibson
In-Reply-To: <200804251353.13698.laurentp@cse-semaphore.com>
Laurent Pinchart wrote:
> Last thing I heard was that the device tree should not encode
> a device's
> expected usage, so memory nodes should not have any
> compatible property that
> would automatically associated them to an MTD driver. I've
> been adviced to
> add platform-specific code to instantiate a platform device manually
> (possibly checking if the required memory node is present in
> the device
> tree). This arguably makes sense, but adds more
> platform-specific code.
So... What good it the device tree at all then, if intended usage should
not be encoded in there.
Most other devices has an intended usage encoded.
Examples would be the FCC's on a Freescale PQ2 chip, where they are
encoded as ethernet controllers. (Thsy could be used as high-speed HDLC
controllers, ATM controllers and other usages), the SCC ports (as
serial, they can be used for syncronous serial and HDLC)
That would also mean if usage would change, the kernel image (and
possiby u-boot) whould have to change, instead of just fixing the device
tree. Argh....
^ permalink raw reply
* Re: [PATCH 1/2] i2c: Add support for device alias names
From: Kay Sievers @ 2008-04-28 16:16 UTC (permalink / raw)
To: Jean Delvare; +Cc: linuxppc-dev list, Paul Mundt, Scott Wood, Linux I2C
In-Reply-To: <20080428174010.5a40c2c0@hyperion.delvare>
On Mon, 2008-04-28 at 17:40 +0200, Jean Delvare wrote:
> On Mon, 28 Apr 2008 17:07:25 +0200, Kay Sievers wrote:
> > On Mon, 2008-04-28 at 11:39 +0200, Jean Delvare wrote:
> > > One thing I am still not happy with is that the aliases created have =
a
> > > trailing "*":
> > >=20
> > > $ /sbin/modinfo lm90
> > > filename: /lib/modules/2.6.25-git11/kernel/drivers/hwmon/lm90.k=
o
> > > author: Jean Delvare <khali@linux-fr.org>
> > > description: LM90/ADM1032 driver
> > > license: GPL
> > > vermagic: 2.6.25-git11 mod_unload
> > > depends: hwmon
> > > alias: i2c:lm90*
> > > alias: i2c:adm1032*
> > > alias: i2c:lm99*
> > > alias: i2c:lm86*
> > > alias: i2c:max6657*
> > > alias: i2c:adt7461*
> > > alias: i2c:max6680*
> > > $
> > >=20
> > > This would cause trouble if one I2C chip name matches the beginning o=
f
> > > another I2C chip name and both chips are supported by different
> > > drivers. This has yet to be seen, but still, I'd like to see this
> > > problem fixed quickly.
> >=20
> > =EF=BB=BFRight, the trailing "*" is not nice.
> >=20
> > We should terminate the string, so the trailing "*" will not match
> > longer strings. The usual thing is to add a ":" to the end, which would
> > then show up as
> > alias: i2c:max6680:*
> >=20
> > See DMI and ACPI:
> > alias dmi:*:svnFUJITSU:pnLifeBook*:pvr*:rvnFUJITSU:* apanel
> > alias acpi*:ASIM0000:* atlas_btns
>=20
> I didn't know about these cases, thanks for the hint.
>=20
> >=20
> > If i2c device modaliases could ever contain multiple strings, it should
> > be:
> > alias: i2c*:max6680:*
> > =EF=BB=BFto match the module, regardless of the order of the strings in=
the
> > modalias:
>=20
> Why would i2c device modaliases ever contain multiple strings? A device
> can't have multiple names, can it?
Like ACPI/PNP devices, which can have several compat id's, which means
that a single device can have "multiple names":
$ cat /sys/bus/pnp/devices/00:09/id
IBM0057
PNP0f13
> Adding a ":" at the end of the i2c device names solves the problem I
> was mentioning, sure, but why don't we simply remove the trailing "*",
> instead of trying to work around it? A trailing "*" simply makes no
> sense for aliases which are simple device names.
Sure, if there is only one single string, it's not useful.
> This is not only i2c
> devices, but also platform devices, acpi, dmi, pnp...
ACPI, DMI, PNP (PNP does not do modalias) needs to be able to match only
one string in a given list, so the trailing "*" is needed.
> Looking at the
> various device types handled by file2alias.c, it seems that most of
> them don't need the trailing "*", and many of them have the problem I
> was mentioning.
>=20
> Can't we just stop handle_moddevtable() from adding a tailing "*"
> automatically, and just let the device types which need it, add it on
> their own?
For a lot subsystems it's fine to have it appended, as there is a
defined list of identifiers, which must appear in the same order, and
new identifiers are appended to the end. So the "*" still matches
modules with possibly extended modalias strings.
We would also need to review all buses which export modalias, if they
need the "*" or not, and add them by hand, if needed.
I guess, it's easier to introduce an additional parameter to
file2alias::do_table() and suppress the trailing "*" for i2c?
Thanks,
Kay
^ permalink raw reply
* Re: suggestions on handling additional exception levels on ppc32
From: Scott Wood @ 2008-04-28 15:59 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <DF3B8F4C-EAE1-4F44-8884-44535A855139@kernel.crashing.org>
On Mon, Apr 28, 2008 at 10:40:56AM -0500, Kumar Gala wrote:
> A few possibilities:
> * introduce an additional function pointer as part of
> EXC_XFER_TEMPLATE() to specifies the type of handler (normal, crit,
> dbg, mcheck)
> * use the traps field low order bits to determine normal, crit, dbg,
> mcheck at run time.
> * duplicate the code paths for each exception level
>
> suggestions?
You could temporarily disable all asynchronous exceptions, and use the
registers of the highest-priority exception type.
-Scott
^ permalink raw reply
* Re: [i2c] [PATCH 0/2] i2c: Add support for device alias names
From: Wolfram Sang @ 2008-04-28 15:35 UTC (permalink / raw)
To: Jean Delvare
Cc: Sievers, Laurent, linuxppc-dev list, Paul Mundt, Linux I2C, Kay,
Scott Wood
In-Reply-To: <20080428113052.6d024bda@hyperion.delvare>
[-- Attachment #1: Type: text/plain, Size: 834 bytes --]
Hello Jean,
I tested on this hardware
MPC8260 (powerpc) + PCF8575 (io expander) + LM84 (sensor)
+ RS5C372 (rtc) + X24645 (eeprom)
the following software
2.6.25-git11 + your 2 patches + Patches 5-7 from Jochen's series
(for the CPM2-bus-driver)
The rtc and the eeprom were assigend through of-tree. The expander
and the sensor were assigned via the old-binding method using
force-parameters.
It builds fine, except for two warnings of redefinitions in Jochen's
patches. (I think they need a few updates anyhow). The output in
modules.alias and /sys make sense. I2C works flawlessly for all
devices.
Please let me know, if you need to more information.
All the best,
Wolfram
--
Dipl.-Ing. Wolfram Sang | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 7/7] linkstation: implement standby
From: Scott Wood @ 2008-04-28 15:58 UTC (permalink / raw)
To: Guennadi Liakhovetski
Cc: Stephen Rothwell, linuxppc-dev, Paul Mackerras, Pavel Machek,
linux-pm, Johannes Berg
In-Reply-To: <Pine.LNX.4.64.0804281732000.7897@axis700.grange>
On Mon, Apr 28, 2008 at 05:40:19PM +0200, Guennadi Liakhovetski wrote:
> +static int ls_pm_enter(suspend_state_t state)
> +{
> + u64 tb;
> +
> + /* Get timebase */
> + tb = get_tb();
> +
> + /* put CPU to sleep, re-enabling interrupts */
> + mpc6xx_enter_standby();
> +
> + local_irq_disable();
Interrupts should not be enabled when you come out of
mpc6xx_enter_standby(); see the TLF_SLEEPING patch.
> +#define MPC10X_LP_REF_EN (1<<12)
> +#define MPC10X_PM (1<<7)
> +#define MPC10X_DOZE (1<<5)
> +#define MPC10X_NAP (1<<4)
> +#define MPC10X_SLEEP (1<<3)
Mismatched whitespace (MPC10X_DOZE has a space before it; the others have
tabs).
-Scott
^ permalink raw reply
* Re: [PATCH 1/2] i2c: Add support for device alias names
From: Jean Delvare @ 2008-04-28 15:42 UTC (permalink / raw)
To: Jon Smirl
Cc: Kay Sievers, linuxppc-dev list, Paul Mundt, Linux I2C, Scott Wood
In-Reply-To: <9e4733910804280743q2de1da62m120c607b200cafa0@mail.gmail.com>
Hi Jon,
On Mon, 28 Apr 2008 10:43:35 -0400, Jon Smirl wrote:
> On 4/28/08, Jean Delvare <khali@linux-fr.org> wrote:
> > One thing I am still not happy with is that the aliases created have a
> > trailing "*":
> >
> > $ /sbin/modinfo lm90
> > filename: /lib/modules/2.6.25-git11/kernel/drivers/hwmon/lm90.ko
> > author: Jean Delvare <khali@linux-fr.org>
> > description: LM90/ADM1032 driver
> > license: GPL
> > vermagic: 2.6.25-git11 mod_unload
> > depends: hwmon
> > alias: i2c:lm90*
> > alias: i2c:adm1032*
> > alias: i2c:lm99*
> > alias: i2c:lm86*
> > alias: i2c:max6657*
> > alias: i2c:adt7461*
> > alias: i2c:max6680*
> > $
> >
> > This would cause trouble if one I2C chip name matches the beginning of
> > another I2C chip name and both chips are supported by different
> > drivers. This has yet to be seen, but still, I'd like to see this
> > problem fixed quickly.
>
>
> Trailing wildcard is always added by file2alias.c:
>
> if (do_entry(mod->name, symval+i, alias)) {
> /* Always end in a wildcard, for future extension */
> if (alias[strlen(alias)-1] != '*')
> strcat(alias, "*");
>
>
> Can't the match order be controlled in the makefile? For example if
> you had lm905* and lm90*, put lm905* into into the makefile first
> which will cause it to appear in the alias file first. But that would
> still cause problems if only lm90 was built and you had a lm905
> device.
That's too trickly and fragile - I'd rather make sure that wrong
matches just can't happen.
>
> Alternatively you could change the code to append something like a
> period to the name string.
>
> sprintf(alias, I2C_MODULE_PREFIX "%s.", id->name);
Similar to what Kay proposed. It works and we'll do that if we have to,
but if we can just get rid of the "*" I'd rather do that.
>
> I was using macros to alter the name strings to move the PowerPC names
> into their own namespace.
>
--
Jean Delvare
^ permalink raw reply
* Re: [PATCH] Add fast little-endian switch system call
From: Michael Kerrisk @ 2008-04-28 15:42 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-arch, linuxppc-dev, Paul Mackerras, mtk.manpages
In-Reply-To: <20080428144332.GA17109@lst.de>
On Mon, Apr 28, 2008 at 4:43 PM, Christoph Hellwig <hch@lst.de> wrote:
> Please see Michael Kerrisk on userspace ABI updates. A nice little
> manpage for this gimmick would be helpful, and maybe help other
> platforms that want one aswell to implement the same API.
Thanks Chrsitoph. I'm not on any of these lists at the moment.
Paul -- is this syscall defintely going in? Could you write a short
description for userland programmers? I'll do the grotty *roff stuff.
> On Mon, Apr 28, 2008 at 01:52:31PM +1000, Paul Mackerras wrote:
> > This adds a system call on 64-bit platforms for switching between
> > little-endian and big-endian modes that is much faster than doing a
> > prctl call. This system call is handled as a special case right at
> > the start of the system call entry code, and because it is a special
> > case, it uses a system call number which is out of the range of
> > normal system calls, namely 0x1ebe.
> >
> > Measurements with lmbench on a 4.2GHz POWER6 showed no measurable
> > change in the speed of normal system calls with this patch.
> >
> > Switching endianness with this new system call takes around 60ns on a
> > 4.2GHz POWER6, compared with around 300ns to switch endian mode with a
> > prctl. This can provide a significant performance advantage for
> > emulators for little-endian architectures that want to switch between
> > big-endian and little-endian mode frequently, e.g. because they are
> > generating instructions sequences on the fly and they want to run
> > those sequences in little-endian mode.
> >
> > Signed-off-by: Paul Mackerras <paulus@samba.org>
> > ---
> >
> > diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
> > index 215973a..2eb49a7 100644
> > --- a/arch/powerpc/kernel/head_64.S
> > +++ b/arch/powerpc/kernel/head_64.S
> > @@ -239,6 +239,10 @@ instruction_access_slb_pSeries:
> > .globl system_call_pSeries
> > system_call_pSeries:
> > HMT_MEDIUM
> > +BEGIN_FTR_SECTION
> > + cmpdi r0,0x1ebe
> > + beq- 1f
> > +END_FTR_SECTION_IFSET(CPU_FTR_REAL_LE)
>
> Am I missing something here or does this add a branch for every normal
> syscall?
>
> > mr r9,r13
> > mfmsr r10
> > mfspr r13,SPRN_SPRG3
> > @@ -253,6 +257,13 @@ system_call_pSeries:
> > rfid
> > b . /* prevent speculative execution */
> >
> > +/* Fast LE/BE switch system call */
> > +1: mfspr r12,SPRN_SRR1
> > + xori r12,r12,MSR_LE
> > + mtspr SPRN_SRR1,r12
> > + rfid /* return to userspace */
> > + b .
> > +
> > STD_EXCEPTION_PSERIES(0xd00, single_step)
> > STD_EXCEPTION_PSERIES(0xe00, trap_0e)
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> ---end quoted text---
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
^ 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