* Re: [RESEND][PATCH][POWERPC] PIKA Warp: Update platform code tosupportRev B boards
From: Sean MacLennan @ 2008-04-28 21:24 UTC (permalink / raw)
To: Richard Purdie; +Cc: Stephen Rothwell, linuxppc-dev
In-Reply-To: <1209415445.5923.59.camel@dax.rpnet.com>
On Mon, 28 Apr 2008 21:44:05 +0100
"Richard Purdie" <rpurdie@rpsys.net> wrote:
> You can leave sections blank but it pays to leave the separator in so
> use ":red:" or ":red", not "red".
Ok, :red: and :green: it is.
What would be the advantage of pika:red: or warp:red:?
Cheers,
Sean
^ permalink raw reply
* Re: [RESEND][PATCH][POWERPC] PIKA Warp: Update platform code to supportRev B boards
From: Richard Purdie @ 2008-04-28 20:44 UTC (permalink / raw)
To: Sean MacLennan; +Cc: Stephen Rothwell, Sean MacLennan, linuxppc-dev
In-Reply-To: <20080428135905.4c037b4b@lappy.seanm.ca>
On Mon, 2008-04-28 at 13:59 -0400, Sean MacLennan wrote:
> 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 ;)
You can leave sections blank but it pays to leave the separator in so
use ":red:" or ":red", not "red".
> I also notice that it is colour, not color.
;-)
Cheers,
Richard
^ permalink raw reply
* Re: 2.6.25-git12 sysfs panic
From: Greg KH @ 2008-04-28 20:49 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1209414970.23575.17.camel@badari-desktop>
On Mon, Apr 28, 2008 at 01:36:10PM -0700, Badari Pulavarty wrote:
> Hi Greg,
>
> Ran into this sysfs oops while booting 2.6.25-git12.
It's not an "oops" but a WARN_ON(1);
> ipr issue ?
Stupid driver issue, yes:
> ipr: IBM Power RAID SCSI Device Driver version: 2.4.1 (April 24, 2007)
> ipr 0000:d0:01.0: Found IOA with IRQ: 119
> ipr 0000:d0:01.0: Starting IOA initialization sequence.
> ipr 0000:d0:01.0: Adapter firmware version: 020A005E
> ipr 0000:d0:01.0: IOA initialized.
> scsi0 : IBM 570B Storage Adapter
> sysfs: duplicate filename 'state' can not be created
Looks like someone messed up, not the sysfs core's fault here :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] make help: Show defconfig subdirs
From: Sam Ravnborg @ 2008-04-28 20:40 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <f70d44df351c88b7754e2ca93c6075f9660d3a40.1207512931.git.segher@kernel.crashing.org>
On Sun, Apr 06, 2008 at 10:16:07PM +0200, Segher Boessenkool wrote:
> PowerPC will start moving board defconfigs into subarch-specific
> subdirs soon. "make help" currently does not look in subdirs to
> find the defconfigs to show. This is partially a good thing,
> since there are way too many defconfigs for one list.
>
> This patch makes the main "make help" display something like
>
> help-40x - Show 40x-specific targets
> help-44x - Show 44x-specific targets
> help-boards - Show all of the above
>
> and wires up stuff so those new help-* commands actually work.
>
> Cc: Josh Boyer <jwboyer@linux.vnet.ibm.com>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
Thanks, applied.
Fixed it up to show x86 defconfig files too.
Sam
^ permalink raw reply
* 2.6.25-git12 sysfs panic
From: Badari Pulavarty @ 2008-04-28 20:36 UTC (permalink / raw)
To: Greg Kroah-Hartman, linuxppc-dev; +Cc: linux-kernel
Hi Greg,
Ran into this sysfs oops while booting 2.6.25-git12.
ipr issue ?
Thanks,
Badari
ipr: IBM Power RAID SCSI Device Driver version: 2.4.1 (April 24, 2007)
ipr 0000:d0:01.0: Found IOA with IRQ: 119
ipr 0000:d0:01.0: Starting IOA initialization sequence.
ipr 0000:d0:01.0: Adapter firmware version: 020A005E
ipr 0000:d0:01.0: IOA initialized.
scsi0 : IBM 570B Storage Adapter
sysfs: duplicate filename 'state' can not be created
------------[ cut here ]------------
Badness at fs/sysfs/dir.c:425
NIP: c00000000013b668 LR: c00000000013b664 CTR: 800000000013f270
REGS: c0000000700db240 TRAP: 0700 Not tainted (2.6.25-git12)
MSR: 8000000000029032 <EE,ME,IR,DR> CR: 22002024 XER: 00000006
TASK = c0000000700d7980[1] 'swapper' THREAD: c0000000700d8000 CPU: 0
GPR00: c00000000013b664 c0000000700db4c0 c000000000792970 0000000000000038
GPR04: 0000000000000001 0000000000000001 0000000000000000 0000000000000001
GPR08: c0000000007bd60c c0000000006c2c58 0000000000003ac3 c0000000007bd608
GPR12: 0000000000004000 c0000000007b3300 0000000000000000 0000000000000000
GPR16: 0000000000000000 d000080080080000 c0000000006b40d0 c00000006e07a708
GPR20: c00000006e07a650 c00000006e07a000 c0000000703241a8 c000000070324000
GPR24: c000000070324070 c000000070324000 c00000006e07a3b0 c00000006e07a170
GPR28: 0000000000000000 c0000000700db5c0 c0000000007115c0 c00000006e07e370
NIP [c00000000013b668] .sysfs_add_one+0x50/0xec
LR [c00000000013b664] .sysfs_add_one+0x4c/0xec
Call Trace:
[c0000000700db4c0] [c00000000013b664] .sysfs_add_one+0x4c/0xec (unreliable)
[c0000000700db550] [c00000000013ade4] .sysfs_add_file_mode+0x70/0xe0
[c0000000700db600] [c00000000038b408] .device_create_file+0x20/0x3c
[c0000000700db680] [c0000000003e2a50] .scsi_sysfs_add_host+0x54/0xc4
[c0000000700db710] [c0000000003d72b0] .scsi_add_host+0x1d4/0x264
[c0000000700db7b0] [c000000000537ef8] 0xc000000000537ef8
[c0000000700db920] [c00000000033b9a4] .pci_device_probe+0x100/0x170
[c0000000700db9e0] [c00000000038e67c] .driver_probe_device+0x118/0x1f8
[c0000000700dba70] [c00000000038e7c4] .__driver_attach+0x68/0xac
[c0000000700dbb00] [c00000000038db3c] .bus_for_each_dev+0x80/0xd0
[c0000000700dbbb0] [c00000000038e3c8] .driver_attach+0x28/0x40
[c0000000700dbc30] [c00000000038d058] .bus_add_driver+0xf4/0x2dc
[c0000000700dbce0] [c00000000038ea54] .driver_register+0x90/0x170
[c0000000700dbd80] [c00000000033bd4c] .__pci_register_driver+0x5c/0xcc
[c0000000700dbe10] [c0000000006675cc] .ipr_init+0x38/0x50
[c0000000700dbe90] [c000000000639414] .kernel_init+0x21c/0x3f8
[c0000000700dbf90] [c000000000023f84] .kernel_thread+0x4c/0x68
Instruction dump:
f821ff71 60000000 60000000 e8630000 e8840018 4bfffdc1 2fa30000 41be0020
e89f0018 e87e8020 4bf1d2f5 60000000 <0fe00000> 3860ffef 48000078 e93d0000
ipr: probe of 0000:d0:01.0 failed with error -17
^ permalink raw reply
* Re: [PATCH 1/7] Implement arch disable/enable irq hooks.
From: Scott Wood @ 2008-04-28 20:33 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, paulus
In-Reply-To: <Pine.LNX.4.64.0804251454050.6045@axis700.grange>
On Fri, Apr 25, 2008 at 02:57:24PM +0200, Guennadi Liakhovetski wrote:
> is there any specific reason, why out of these 7 patches only the first
> one made it into the mainline? AFAICS, there has been only one comment,
> suggesting to replace printk with dev_err on two occasions in one of
> the patches...
A while ago Paul said on IRC he'd prefer to do the TLF_SLEEPING hack more
like the soft IRQ disabling that 64-bit uses. I haven't yet had a chance
to look into it, so the patch collects dust, despite the current
implementation of TLF_SLEEPING working just fine.
-Scott
^ permalink raw reply
* Re: [PATCH 1/2] [MTD] Add support for RAM & ROMmappings in the physmap_of MTD driver.
From: Scott Wood @ 2008-04-28 20:30 UTC (permalink / raw)
To: Rune Torgersen
Cc: ben, linuxppc-dev, linux-mtd, David Woodhouse, David Gibson
In-Reply-To: <DCEAAC0833DD314AB0B58112AD99B93B04512785@ismail.innsys.innovsys.com>
On Mon, Apr 28, 2008 at 11:26:15AM -0500, Rune Torgersen wrote:
> 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)
But that choice is made by board-level hardware, not purely by software.
-Scott
^ permalink raw reply
* 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
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