* Re: [PATCH v2.6.26] powerpc: Fix a bunch of sparse warnings in the qe_lib
From: Andy Fleming @ 2008-05-03 0:00 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev
In-Reply-To: <481B5F59.8020201@freescale.com>
On May 2, 2008, at 13:37, Timur Tabi wrote:
> Andy Fleming wrote:
>
>> int ucc_fast_init(struct ucc_fast_info * uf_info, struct
>> ucc_fast_private ** uccf_ret)
>> {
>> struct ucc_fast_private *uccf;
>> - struct ucc_fast *uf_regs;
>> + struct ucc_fast __iomem *uf_regs;
>> u32 gumr;
>> int ret;
>>
>> @@ -216,10 +216,10 @@ int ucc_fast_init(struct ucc_fast_info *
>> uf_info, struct ucc_fast_private ** ucc
>> uccf->stopped_tx = 0;
>> uccf->stopped_rx = 0;
>> uf_regs = uccf->uf_regs;
>> - uccf->p_ucce = (u32 *) & (uf_regs->ucce);
>> - uccf->p_uccm = (u32 *) & (uf_regs->uccm);
>> + uccf->p_ucce = (u32 __iomem *) & (uf_regs->ucce);
>> + uccf->p_uccm = (u32 __iomem *) & (uf_regs->uccm);
>
> Since you've already made uf_regs into an __iomem pointer, do you
> really need to
> cast it?
Ah, yes. That's probably leftover from when uf_regs wasn't __iomem.
>
> And please remember to CC: me on any QE library patches.
Can do.
Andy
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
From: Segher Boessenkool @ 2008-05-03 0:06 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev
In-Reply-To: <20080502.163855.96423898.davem@davemloft.net>
>> That is, it would be fairly non-sensical for module code to go through
>> the trampoline to call those stubs in the kernel (and having to
>> EXPORT_SYMBOL them).
You can link every module to libgcc separately. Probably it can also
be set up so that some libgcc routines get linked into the kernel,
and exported, and the rest is linked into every module that wants
them. We can also blacklist some symbols altogether (__udivdi3...)
> Oh, I forgot about how far function calls are done on powerpc.
> Yes, that will suck.
>
> Is there some way to map all of the modules in the low 32-bits and
> thus aovid the trampolines? The powerpc call instruction can cover
> 4GB like on sparc right?
A direct call reaches +-32MB, either relative or absolute; an indirect
call can go anywhere.
> Actually, I remember there is some linkage register that has
> to be setup on powerpc with the code model you guys use, is
> that the problem?
I think the problem is just that the compiler generates "near" calls
(the 32MB thing) because of the code model used, but things don't
necessarily end up this close by at run time.
Segher
^ permalink raw reply
* [PATCH] SBC8548: Add flash support and HW Rev reporting
From: Jeremy McNicoll @ 2008-05-02 20:20 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Jeremy McNicoll
The following adds local bus, flash and MTD partition nodes for
sbc8548. As well, a compatible field for the soc node, so that
of_platform_bus_probe() will pick it up.
Something that is provided through this newly added epld node
is the Hardware Revision is now being reported at bootup.
Signed-off-by: Jeremy McNicoll <jeremy.mcnicoll@windriver.com>
---
arch/powerpc/boot/dts/sbc8548.dts | 94 +++++++++++++++++++++++++++++++++
arch/powerpc/platforms/85xx/sbc8548.c | 25 +++++++++
2 files changed, 119 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/sbc8548.dts b/arch/powerpc/boot/dts/sbc8548.dts
index b86e65d..dd9a061 100644
--- a/arch/powerpc/boot/dts/sbc8548.dts
+++ b/arch/powerpc/boot/dts/sbc8548.dts
@@ -52,6 +52,99 @@
reg = <0x00000000 0x10000000>;
};
+ localbus@e0000000 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ reg = <0xe0000000 0x5000>;
+ interrupt-parent = <&mpic>;
+
+ ranges = <0x0 0x0 0xff800000 0x00800000 /*8MB Flash*/
+ 0x3 0x0 0xf0000000 0x04000000 /*64MB SDRAM*/
+ 0x4 0x0 0xf4000000 0x04000000 /*64MB SDRAM*/
+ 0x5 0x0 0xf8000000 0x00b10000 /* EPLD */
+ 0x6 0x0 0xfb800000 0x04000000>; /*64MB Flash*/
+
+
+ flash@0,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "cfi-flash";
+ reg = <0x0 0x0 0x800000>;
+ bank-width = <1>;
+ device-width = <1>;
+ partition@0x0 {
+ label = "space";
+ reg = <0x00000000 0x00100000>;
+ };
+ partition@0x100000 {
+ label = "bootloader";
+ reg = <0x00100000 0x00700000>;
+ read-only;
+ };
+ };
+
+ epld@5,0 {
+ compatible = "wrs,epld-localbus";
+ #address-cells = <2>;
+ #size-cells = <1>;
+ reg = <0x5 0x0 0x00b10000>;
+ ranges = <
+ 0x0 0x0 0x5 0x000000 0x1fff /* LED */
+ 0x1 0x0 0x5 0x100000 0x1fff /* Switches */
+ 0x3 0x0 0x5 0x300000 0x1fff /* HW Rev. */
+ 0xb 0x0 0x5 0xb00000 0x1fff /* EEPROM */
+ >;
+
+ led@0,0 {
+ compatible = "led";
+ reg = <0x0 0x0 0x1fff>;
+ };
+
+ switches@1,0 {
+ compatible = "switches";
+ reg = <0x1 0x0 0x1fff>;
+ };
+
+ hw-rev@3,0 {
+ compatible = "hw-rev";
+ reg = <0x3 0x0 0x1fff>;
+ };
+
+ eeprom@b,0 {
+ compatible = "eeprom";
+ reg = <0xb 0 0x1fff>;
+ };
+
+ };
+
+ alt-flash@6,0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x6 0x0 0x04000000>;
+ compatible = "cfi-flash";
+ bank-width = <4>;
+ device-width = <1>;
+ partition@0x0 {
+ label = "bootloader";
+ reg = <0x00000000 0x00100000>;
+ read-only;
+ };
+ partition@0x00100000 {
+ label = "file-system";
+ reg = <0x00100000 0x01f00000>;
+ };
+ partition@0x02000000 {
+ label = "boot-config";
+ reg = <0x02000000 0x00100000>;
+ };
+ partition@0x02100000 {
+ label = "space";
+ reg = <0x02100000 0x01f00000>;
+ };
+ };
+ };
+
soc8548@e0000000 {
#address-cells = <1>;
#size-cells = <1>;
@@ -59,6 +152,7 @@
ranges = <0x00000000 0xe0000000 0x00100000>;
reg = <0xe0000000 0x00001000>; // CCSRBAR
bus-frequency = <0>;
+ compatible = "simple-bus";
memory-controller@2000 {
compatible = "fsl,8548-memory-controller";
diff --git a/arch/powerpc/platforms/85xx/sbc8548.c b/arch/powerpc/platforms/85xx/sbc8548.c
index 488facb..d148d45 100644
--- a/arch/powerpc/platforms/85xx/sbc8548.c
+++ b/arch/powerpc/platforms/85xx/sbc8548.c
@@ -130,6 +130,7 @@ static void sbc8548_show_cpuinfo(struct seq_file *m)
static struct of_device_id __initdata of_bus_ids[] = {
{ .name = "soc", },
{ .type = "soc", },
+ { .compatible = "simple-bus", },
{},
};
@@ -141,6 +142,30 @@ static int __init declare_of_platform_devices(void)
}
machine_device_initcall(sbc8548, declare_of_platform_devices);
+/* Extract the HW Rev from the EPLD on the board */
+static int __init sbc8548_hw_rev(void)
+{
+ struct device_node *np;
+ struct resource res;
+ unsigned int *rev;
+
+ np = of_find_compatible_node(NULL, NULL, "hw-rev");
+ if (np == NULL) {
+ printk("No HW-REV found in DTB.\n");
+ return -ENODEV;
+ }
+
+ of_address_to_resource(np, 0, &res);
+ of_node_put(np);
+
+ rev = ioremap(res.start,sizeof(unsigned int));
+ printk("Detected HW Rev. 0x%x\n", ((*rev) >> 28));
+ iounmap(rev);
+
+ return 0;
+}
+arch_initcall(sbc8548_hw_rev);
+
/*
* Called very early, device-tree isn't unflattened
*/
--
1.5.3.7
^ permalink raw reply related
* Re: [PATCH] [POWERPC] Fix kernel builds with newer gcc versions and -Os
From: Segher Boessenkool @ 2008-05-03 0:15 UTC (permalink / raw)
To: David Miller; +Cc: scottwood, linuxppc-dev
In-Reply-To: <20080502.150448.32652665.davem@davemloft.net>
>> What in libgcc references libc, and why isn't this a problem for
>> Linux/ARM, Linux/SH, U-boot, and the many other libc-less programs
>> that
>> use libgcc?
>
> The problem only occurs once you reference a function that references
> libc stuff, and those guys are just lucky so far.
The only calls to the C library that GCC ever generates by itself
(for freestanding mode, at least) are calls to memcmp, memcpy, memmove,
memset (and abort, in some circumstances). This is true whether or
not you link to libgcc.
> It's also one less variable to debug if you put the implementation
> in the kernel, or do you like debugging compiler induced problems?
> I don't :-)
On the other hand, if we opt to re-implement, we have to make sure
the in-kernel version of the GCC support routines is correct. We
have to trust the compiler everywhere else already, why not here as
well?
Segher
p.s. I just finished some testing linking a powerpc kernel with
libgcc. All went fine, as expected. I also did a stupid test that
actually needed a libgcc routine (__udivdi3); that went fine as well.
And yeah, I know about the modules issue, but that isn't really very
different from the analogue issue with in-kernel library routines.
^ permalink raw reply
* Re: function calls from identify_cpu()
From: Kevin Diggs @ 2008-05-03 5:45 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1209770980.26383.18.camel@pasglop>
Benjamin Herrenschmidt wrote:
> On Fri, 2008-05-02 at 13:42 -0700, Kevin Diggs wrote:
>
>>I added:
>>
>>int __init iDoNothingUseful(struct cpu_spec *s,struct cpu_spec *t)
>>{
>> return s-t;
>>}
>>
>>right before the definition of identify_cpu() in cputable.c and:
>>
>>// (void) (*PTRRELOC(&iDoNothingUseful))(s,t);
>> (void) iDoNothingUseful(s,t);
>>
>>right before the return s; in the match block and it will not boot? Can
>>someone please explain what might be going on?
>
>
> Why are you trying to muck around with that code in the first
> place ? :-)
>
> What are you trying to achieve ?
>
> Cheers,
> Ben.
>
The original intent was to find a way to add some of the PLL parameters
(min and max core frequencies, min and max bus ratios - FX 400 - 800, 2
- 20; GX 500 - 1000, 2 - 20). Initially it seemed like the place to put
them. To avoid kernel bloat I think I'll just put them in the init
routine of the driver. I'll have to redo the cpu detection (FX vs GX);
but I guess that is not that big of a deal.
But now it is about retaining what is left of my sanity. I took the
above code and added it to a GigE running the same installation (the
8600 installation was created by installing its disk in the GigE) and it
ran fine!?! ANY suggestions would be greatly appreciated. Something to
do with BootX? BootX is to old (1.2.4)? System needs an exorcism? I
screwed up something in the 750GX cpu_spec entry?
Both are running 2.6.24.
kevin
P.S.: I would still appreciate it if someone could explain why this line:
*PTRRELOC(&cur_cpu_spec) = &the_cpu_spec;
isn't:
*PTRRELOC((&cur_cpu_spec) = PTRRELOC(&the_cpu_spec);
Is the address &the_cpu_spec valid later in the kernel initialization?
Is it ... valid now?
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
From: Benjamin Herrenschmidt @ 2008-05-03 7:50 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev
In-Reply-To: <20080502.163855.96423898.davem@davemloft.net>
On Fri, 2008-05-02 at 16:38 -0700, David Miller wrote:
> Oh, I forgot about how far function calls are done on powerpc.
> Yes, that will suck.
>
> Is there some way to map all of the modules in the low 32-bits and
> thus aovid the trampolines? The powerpc call instruction can cover
> 4GB like on sparc right?
>
> Actually, I remember there is some linkage register that has
> to be setup on powerpc with the code model you guys use, is
> that the problem?
The TOC yes, so we end up doing cross-TOC calls, which we would want to
avoid to get to base runtime stuff such as the save/restore bits.
Especially useless since those runtime don't need a TOC at all :-)
Best would be if we could get those runtime bits linked in the module
itself, but I don't know enough about our toolchain to know if that's
easy (I suppose everything is always possible :-)
I can ask my local expert next week.
Ben.
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
From: David Miller @ 2008-05-03 7:55 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1209801017.26383.21.camel@pasglop>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Sat, 03 May 2008 17:50:17 +1000
> Best would be if we could get those runtime bits linked in the module
> itself, but I don't know enough about our toolchain to know if that's
> easy (I suppose everything is always possible :-)
The only downside is that you'd have N copies of these
routines, one for every module that emmited the libcalls.
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix bootwrapper builds with newer gcc versions
From: Benjamin Herrenschmidt @ 2008-05-03 11:01 UTC (permalink / raw)
To: David Miller; +Cc: linuxppc-dev
In-Reply-To: <20080503.005510.88048425.davem@davemloft.net>
On Sat, 2008-05-03 at 00:55 -0700, David Miller wrote:
> From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Date: Sat, 03 May 2008 17:50:17 +1000
>
> > Best would be if we could get those runtime bits linked in the module
> > itself, but I don't know enough about our toolchain to know if that's
> > easy (I suppose everything is always possible :-)
>
> The only downside is that you'd have N copies of these
> routines, one for every module that emmited the libcalls.
Yup, so it's mostly a matter of balance, choosing which of these should
be kept in the kernel and which of these linked directly I suppose,
possibly based on usage frequency and size. A pain in the neck tho...
Ben.
^ permalink raw reply
* Re: powerpc boot regression
From: Yasunori Goto @ 2008-05-03 12:05 UTC (permalink / raw)
To: Badari Pulavarty, Tony Breeds
Cc: linux-kernel, LinuxPPC-dev, akpm, David Miller, Hiroyuki KAMEZAWA
In-Reply-To: <1209653507.27240.7.camel@badari-desktop>
>
> On Thu, 2008-05-01 at 15:13 +1000, Tony Breeds wrote:
> > On Tue, Apr 29, 2008 at 11:12:41PM -0700, David Miller wrote:
> > >
> > > This commit causes bootup failures on sparc64:
> > >
> > > commit 86f6dae1377523689bd8468fed2f2dd180fc0560
> > > Author: Yasunori Goto <y-goto@jp.fujitsu.com>
> > > Date: Mon Apr 28 02:13:33 2008 -0700
> > >
> > > memory hotplug: allocate usemap on the section with pgdat
> >
> >
> > <snip>
> >
> > We're seeing a boot failure on powerpc. git bisect points the problem
> > at this commit. However reverting just this one comitt doesn't fix the
> > regression. I also needed to revert
> > 04753278769f3b6c3b79a080edb52f21d83bf6e2 (memory hotplug: register
> > section/node id to free")
> >
> > Problem seen on power4, power5 and ps3.
>
> I don't see the problem on my power5 machine. Can you send the
> config ? Is CONFIG_SPARSEMEM_VMEMMAP enabled ?
>
> Please let me know.
I heard sparc has the similar regression.
http://marc.info/?l=linux-kernel&m=120953950332044&w=2
If Kame-san's temporary patch fixes your problems, its cause may be same.
Thanks.
--
Yasunori Goto
^ permalink raw reply
* [PATCH] [POWERPC] Fix of_i2c include for module compilation
From: Jochen Friedrich @ 2008-05-03 12:42 UTC (permalink / raw)
To: Kumar Gala
Cc: Stephen Rothwell, linuxppc-dev list, Kernel, Linux, Scott Wood,
Paul Mackerras, Jean Delvare, David Miller, Linux I2C
Now that of_i2c may be compiled as module, the header must be
exported for module compilation, as well.
Signed-off-by: Jochen Friedrich <jochen@scram.de>
---
include/linux/of_i2c.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/of_i2c.h b/include/linux/of_i2c.h
index 2e5a967..dca6013 100644
--- a/include/linux/of_i2c.h
+++ b/include/linux/of_i2c.h
@@ -14,7 +14,7 @@
#include <linux/i2c.h>
-#ifdef CONFIG_OF_I2C
+#if defined(CONFIG_OF_I2C) || defined(CONFIG_OF_I2C_MODULE)
void of_register_i2c_devices(struct i2c_adapter *adap,
struct device_node *adap_node);
--
1.5.5.1
^ permalink raw reply related
* Re: SKB corruption on heavy traffic
From: Matvejchikov Ilya @ 2008-05-03 14:07 UTC (permalink / raw)
To: Myron.Dixon
Cc: linuxppc-dev, linuxppc-embedded,
Franca, Jose (NSN - PT/Portugal - MiniMD)
In-Reply-To: <F83A28966A0FAF41897D75586AFBBF5134A1FC@gns-mail.GNS.L-3COM.COM>
[-- Attachment #1: Type: text/plain, Size: 4998 bytes --]
Hi all!
The same problem! I've tried 2.4.xx and 2.6.xx kernels. Nothing changed!
BUT. After many days of fucking with fs_enet driver I've found a
stable (as I see) solution. The bugs I've had:
- kernel oopses
- SKB data corruption
- BDs status corruption
- SKB ring full message
- too many RX errors
- may be something else :)
For now I have a 2.4.35 fs_enet driver that works on heavy load
24/7... I don't know what happens with my 8260 board, but with this
code it be very stable. I supposed that there are some errors in 8260
CPM core, but errata don't know about it :)
I've append an attachment with my 2.4.35 kernel patch. Sorry for a big
file and not for only fs_enet file. Moreover I've used CPM111 errata
microcode and NAPI in fs_enet driver.
If you have any questions I'm glad to hear it.
2008/5/2 <Myron.Dixon@l-3com.com>:
> We have experience a very similar problem using a 2.4.18 kernel on an 8260 ppc processor.
> We have a telecomunication product that for some time only used the fec for TCP/IP ethernet
> traffic only and worked just fine.
>
> After we upgraded our product to implement TDM data over IP we started to notice an occasional
> kernel oops. We began to evaluate all of our products and determined that only some of the units
> exhibted this behaviour at various rates of occurrence. Further evaluation revealed that the pointers
> located in dpram pointing to the fec's buffer descriptors were some how getting corrupted.
> Note that the 8260 has 4 internal scc/fccs and we use all four for various aspects of our application
> and each shares dpram for pointers to buffer descriptors that reside in sdram. However, only the
> fec that is used for IP experiences this buffer descriptor corruption and, then, apparently, only under
> heavy traffic load. We spent about six months evaluating this problem including contacting freescale,
> but never found a solution. We finally, decided to use an external ethernet chip on a daughter card
> for our IP channel.
>
> It is, however, our belief that our problem relates to a possible bug in the 8260 CPM, but have yet to
> absolutely prove this.
>
> If we are experiencing the same problem (and potentially others) and there is a solution we would be
> very interested, as, we are not happy about the daughter card solution.
>
>
> Myron L. Dixon
> Sr. Software Engineer
> L-3 Communications, GNS
> 1519 Grundy's Lane
> Bristol, PA 19007
> Phone: 215 957 3739
> Fax: 215 957 3790
> email: Myron.Dixon@L-3Com.com
>
> -----Original Message-----
> From: linuxppc-dev-bounces+myron.dixon=l-3com.com@ozlabs.org [mailto:linuxppc-dev-bounces+myron.dixon=l-3com.com@ozlabs.org] On Behalf Of Franca, Jose (NSN - PT/Portugal - MiniMD)
> Sent: Wednesday, April 30, 2008 5:07 AM
> To: linuxppc-dev@ozlabs.org; linuxppc-embedded@ozlabs.org
> Subject: FW: SKB corruption on heavy traffic
>
> From our latest debugs we found that the problem occurs mainly on skbuff code. After some variable time kfree or kalloc result in kernel oops.
>
> -----Original Message-----
> From: Franca, Jose (NSN - PT/Portugal - MiniMD)
> Sent: quarta-feira, 30 de Abril de 2008 9:44
> To: 'ext Scott Wood'
> Cc:
> Subject: RE: SKB corruption on heavy traffic
>
> Hello!
>
> Thank you for replying!
> It't quite dificult to say if the problem exists without our changes, since the all software is dependent on this changes so to work with the hardware. I can't answer to that right now on that, but I forgot to add one thing: we have ring buffer full problems on our fcc_enet driver from time to time. So, I think the problem could be on linux configurations (related to hw) because there is a lot of posts on the web related to problems similar to this (none of them has really solved the bottom problem).
>
> Regards,
> Filipe
>
> -----Original Message-----
> From: ext Scott Wood [mailto:scottwood@freescale.com]
> Sent: terça-feira, 29 de Abril de 2008 20:15
> To: Franca, Jose (NSN - PT/Portugal - MiniMD)
> Cc: linuxppc-dev@ozlabs.org; linuxppc-embedded@ozlabs.org
> Subject: Re: SKB corruption on heavy traffic
>
> On Tue, Apr 29, 2008 at 07:39:07PM +0100, Franca, Jose (NSN - PT/Portugal - MiniMD) wrote:
> > We are developing a MPC8247 based telecom board (512MB), using linux
> > 2.4 with some proprietary changes on IP stack and we are facing some
> > problems when we have heavy traffic on our Ethernet interfaces...
>
> Do you see these problems without the proprietary changes, and with a current kernel?
>
> -Scott
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: linux-2.4.35-m82-2.patch.gz --]
[-- Type: application/x-gzip, Size: 21860 bytes --]
^ permalink raw reply
* [PATCH] [POWERPC] 86xx: mpc8610_hpcd: add support for NOR and NAND flashes
From: Anton Vorontsov @ 2008-05-04 15:07 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
This patch adds device tree nodes for NOR and NAND flashes and places
board-control node inside the localbus.
defconfig and board file updated appropriately.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 39 +++++++++++-
arch/powerpc/configs/mpc8610_hpcd_defconfig | 88 ++++++++++++++++++++++++++-
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 1 +
3 files changed, 124 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index bba234e..64c8e78 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -46,9 +46,42 @@
reg = <0x00000000 0x20000000>; // 512M at 0x0
};
- board-control@e8000000 {
- compatible = "fsl,fpga-pixis";
- reg = <0xe8000000 32>; // pixis at 0xe8000000
+ localbus@e0005000 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8610-elbc", "fsl,elbc", "simple-bus";
+ reg = <0xe0005000 0x1000>;
+ interrupts = <19 2>;
+ interrupt-parent = <&mpic>;
+ ranges = <0 0 0xf8000000 0x08000000
+ 1 0 0xf0000000 0x08000000
+ 2 0 0xe8400000 0x00008000
+ 3 0 0xe8000000 0x00000020>;
+
+ flash@0,0 {
+ compatible = "cfi-flash";
+ reg = <0 0 0x8000000>;
+ bank-width = <2>;
+ device-width = <1>;
+ };
+
+ flash@1,0 {
+ compatible = "cfi-flash";
+ reg = <1 0 0x8000000>;
+ bank-width = <2>;
+ device-width = <1>;
+ };
+
+ flash@2,0 {
+ compatible = "fsl,mpc8610-fcm-nand",
+ "fsl,elbc-fcm-nand";
+ reg = <2 0 0x8000>;
+ };
+
+ board-control@3,0 {
+ compatible = "fsl,fpga-pixis";
+ reg = <3 0 0x20>;
+ };
};
soc@e0000000 {
diff --git a/arch/powerpc/configs/mpc8610_hpcd_defconfig b/arch/powerpc/configs/mpc8610_hpcd_defconfig
index f9e53bd..7e5b9ce 100644
--- a/arch/powerpc/configs/mpc8610_hpcd_defconfig
+++ b/arch/powerpc/configs/mpc8610_hpcd_defconfig
@@ -358,7 +358,93 @@ CONFIG_FW_LOADER=y
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
-# CONFIG_MTD is not set
+CONFIG_MTD=y
+# CONFIG_MTD_DEBUG is not set
+# CONFIG_MTD_CONCAT is not set
+CONFIG_MTD_PARTITIONS=y
+# CONFIG_MTD_REDBOOT_PARTS is not set
+CONFIG_MTD_CMDLINE_PARTS=y
+# CONFIG_MTD_OF_PARTS is not set
+# CONFIG_MTD_AR7_PARTS is not set
+
+#
+# User Modules And Translation Layers
+#
+CONFIG_MTD_CHAR=y
+CONFIG_MTD_BLKDEVS=y
+CONFIG_MTD_BLOCK=y
+# CONFIG_FTL is not set
+# CONFIG_NFTL is not set
+# CONFIG_INFTL is not set
+# CONFIG_RFD_FTL is not set
+# CONFIG_SSFDC is not set
+# CONFIG_MTD_OOPS is not set
+
+#
+# RAM/ROM/Flash chip drivers
+#
+CONFIG_MTD_CFI=y
+# CONFIG_MTD_JEDECPROBE is not set
+CONFIG_MTD_GEN_PROBE=y
+# CONFIG_MTD_CFI_ADV_OPTIONS is not set
+CONFIG_MTD_MAP_BANK_WIDTH_1=y
+CONFIG_MTD_MAP_BANK_WIDTH_2=y
+CONFIG_MTD_MAP_BANK_WIDTH_4=y
+# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
+CONFIG_MTD_CFI_I1=y
+CONFIG_MTD_CFI_I2=y
+# CONFIG_MTD_CFI_I4 is not set
+# CONFIG_MTD_CFI_I8 is not set
+# CONFIG_MTD_CFI_INTELEXT is not set
+CONFIG_MTD_CFI_AMDSTD=y
+# CONFIG_MTD_CFI_STAA is not set
+CONFIG_MTD_CFI_UTIL=y
+# CONFIG_MTD_RAM is not set
+# CONFIG_MTD_ROM is not set
+# CONFIG_MTD_ABSENT is not set
+
+#
+# Mapping drivers for chip access
+#
+# CONFIG_MTD_COMPLEX_MAPPINGS is not set
+# CONFIG_MTD_PHYSMAP is not set
+CONFIG_MTD_PHYSMAP_OF=y
+# CONFIG_MTD_INTEL_VR_NOR is not set
+# CONFIG_MTD_PLATRAM is not set
+
+#
+# Self-contained MTD device drivers
+#
+# CONFIG_MTD_PMC551 is not set
+# CONFIG_MTD_SLRAM is not set
+# CONFIG_MTD_PHRAM is not set
+# CONFIG_MTD_MTDRAM is not set
+# CONFIG_MTD_BLOCK2MTD is not set
+
+#
+# Disk-On-Chip Device Drivers
+#
+# CONFIG_MTD_DOC2000 is not set
+# CONFIG_MTD_DOC2001 is not set
+# CONFIG_MTD_DOC2001PLUS is not set
+CONFIG_MTD_NAND=y
+# CONFIG_MTD_NAND_VERIFY_WRITE is not set
+# CONFIG_MTD_NAND_ECC_SMC is not set
+# CONFIG_MTD_NAND_MUSEUM_IDS is not set
+CONFIG_MTD_NAND_IDS=y
+# CONFIG_MTD_NAND_DISKONCHIP is not set
+# CONFIG_MTD_NAND_CAFE is not set
+# CONFIG_MTD_NAND_NANDSIM is not set
+# CONFIG_MTD_NAND_PLATFORM is not set
+CONFIG_MTD_NAND_FSL_ELBC=y
+# CONFIG_MTD_ONENAND is not set
+
+#
+# UBI - Unsorted block images
+#
+# CONFIG_MTD_UBI is not set
CONFIG_OF_DEVICE=y
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
index 5e1e8cf..782d1cb 100644
--- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
+++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
@@ -43,6 +43,7 @@ static unsigned char *pixis_bdcfg0, *pixis_arch;
static struct of_device_id __initdata mpc8610_ids[] = {
{ .compatible = "fsl,mpc8610-immr", },
+ { .compatible = "simple-bus", },
{}
};
--
1.5.5.1
^ permalink raw reply related
* powerpc-next branch and 2.6.27?
From: Kumar Gala @ 2008-05-04 17:46 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev@ozlabs.org list
Paul,
Now that 2.6.26-rc1 is out, will your powerpc-next branch be used for
work queued up for 2.6.27?
- k
^ permalink raw reply
* How to link a .o with all modules
From: Kumar Gala @ 2008-05-04 18:22 UTC (permalink / raw)
To: sam; +Cc: linuxppc-dev@ozlabs.org list, lkml List
Sam,
We have a case in powerpc in which we want to link some library
routines with all module objects. The routines are intended for
handling out-of-line function call register save/restore so having
them as EXPORT_SYMBOL() is counter productive (we do also need to link
the same "library" code into the kernel).
Any suggestions on how to handle this?
thanks
- k
^ permalink raw reply
* [PATCH v2] [POWERPC] 86xx: mpc8610_hpcd: add support for NOR and NAND flashes
From: Anton Vorontsov @ 2008-05-04 18:46 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <20080504150727.GA27038@polina.dev.rtsoft.ru>
This patch adds device tree nodes for NOR and NAND flashes and places
board-control node inside the localbus.
defconfig and board file updated appropriately.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
Heh, this is v2. The flash setup on the MPC8610 tricked me.
There is single NAND package, but with four physical NAND
chips inside. Each occupy its own localbus CE line, i.e. bank.
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 60 +++++++++++++++++-
arch/powerpc/configs/mpc8610_hpcd_defconfig | 88 ++++++++++++++++++++++++++-
arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 1 +
3 files changed, 145 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index bba234e..08a780d 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -46,9 +46,63 @@
reg = <0x00000000 0x20000000>; // 512M at 0x0
};
- board-control@e8000000 {
- compatible = "fsl,fpga-pixis";
- reg = <0xe8000000 32>; // pixis at 0xe8000000
+ localbus@e0005000 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ compatible = "fsl,mpc8610-elbc", "fsl,elbc", "simple-bus";
+ reg = <0xe0005000 0x1000>;
+ interrupts = <19 2>;
+ interrupt-parent = <&mpic>;
+ ranges = <0 0 0xf8000000 0x08000000
+ 1 0 0xf0000000 0x08000000
+ 2 0 0xe8400000 0x00008000
+ 4 0 0xe8440000 0x00008000
+ 5 0 0xe8480000 0x00008000
+ 6 0 0xe84c0000 0x00008000
+ 3 0 0xe8000000 0x00000020>;
+
+ flash@0,0 {
+ compatible = "cfi-flash";
+ reg = <0 0 0x8000000>;
+ bank-width = <2>;
+ device-width = <1>;
+ };
+
+ flash@1,0 {
+ compatible = "cfi-flash";
+ reg = <1 0 0x8000000>;
+ bank-width = <2>;
+ device-width = <1>;
+ };
+
+ flash@2,0 {
+ compatible = "fsl,mpc8610-fcm-nand",
+ "fsl,elbc-fcm-nand";
+ reg = <2 0 0x8000>;
+ };
+
+ flash@4,0 {
+ compatible = "fsl,mpc8610-fcm-nand",
+ "fsl,elbc-fcm-nand";
+ reg = <4 0 0x8000>;
+ };
+
+ flash@5,0 {
+ compatible = "fsl,mpc8610-fcm-nand",
+ "fsl,elbc-fcm-nand";
+ reg = <5 0 0x8000>;
+ };
+
+ flash@6,0 {
+ compatible = "fsl,mpc8610-fcm-nand",
+ "fsl,elbc-fcm-nand";
+ reg = <6 0 0x8000>;
+ };
+
+ board-control@3,0 {
+ compatible = "fsl,fpga-pixis";
+ reg = <3 0 0x20>;
+ };
};
soc@e0000000 {
diff --git a/arch/powerpc/configs/mpc8610_hpcd_defconfig b/arch/powerpc/configs/mpc8610_hpcd_defconfig
index f9e53bd..7e5b9ce 100644
--- a/arch/powerpc/configs/mpc8610_hpcd_defconfig
+++ b/arch/powerpc/configs/mpc8610_hpcd_defconfig
@@ -358,7 +358,93 @@ CONFIG_FW_LOADER=y
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
-# CONFIG_MTD is not set
+CONFIG_MTD=y
+# CONFIG_MTD_DEBUG is not set
+# CONFIG_MTD_CONCAT is not set
+CONFIG_MTD_PARTITIONS=y
+# CONFIG_MTD_REDBOOT_PARTS is not set
+CONFIG_MTD_CMDLINE_PARTS=y
+# CONFIG_MTD_OF_PARTS is not set
+# CONFIG_MTD_AR7_PARTS is not set
+
+#
+# User Modules And Translation Layers
+#
+CONFIG_MTD_CHAR=y
+CONFIG_MTD_BLKDEVS=y
+CONFIG_MTD_BLOCK=y
+# CONFIG_FTL is not set
+# CONFIG_NFTL is not set
+# CONFIG_INFTL is not set
+# CONFIG_RFD_FTL is not set
+# CONFIG_SSFDC is not set
+# CONFIG_MTD_OOPS is not set
+
+#
+# RAM/ROM/Flash chip drivers
+#
+CONFIG_MTD_CFI=y
+# CONFIG_MTD_JEDECPROBE is not set
+CONFIG_MTD_GEN_PROBE=y
+# CONFIG_MTD_CFI_ADV_OPTIONS is not set
+CONFIG_MTD_MAP_BANK_WIDTH_1=y
+CONFIG_MTD_MAP_BANK_WIDTH_2=y
+CONFIG_MTD_MAP_BANK_WIDTH_4=y
+# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
+# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
+CONFIG_MTD_CFI_I1=y
+CONFIG_MTD_CFI_I2=y
+# CONFIG_MTD_CFI_I4 is not set
+# CONFIG_MTD_CFI_I8 is not set
+# CONFIG_MTD_CFI_INTELEXT is not set
+CONFIG_MTD_CFI_AMDSTD=y
+# CONFIG_MTD_CFI_STAA is not set
+CONFIG_MTD_CFI_UTIL=y
+# CONFIG_MTD_RAM is not set
+# CONFIG_MTD_ROM is not set
+# CONFIG_MTD_ABSENT is not set
+
+#
+# Mapping drivers for chip access
+#
+# CONFIG_MTD_COMPLEX_MAPPINGS is not set
+# CONFIG_MTD_PHYSMAP is not set
+CONFIG_MTD_PHYSMAP_OF=y
+# CONFIG_MTD_INTEL_VR_NOR is not set
+# CONFIG_MTD_PLATRAM is not set
+
+#
+# Self-contained MTD device drivers
+#
+# CONFIG_MTD_PMC551 is not set
+# CONFIG_MTD_SLRAM is not set
+# CONFIG_MTD_PHRAM is not set
+# CONFIG_MTD_MTDRAM is not set
+# CONFIG_MTD_BLOCK2MTD is not set
+
+#
+# Disk-On-Chip Device Drivers
+#
+# CONFIG_MTD_DOC2000 is not set
+# CONFIG_MTD_DOC2001 is not set
+# CONFIG_MTD_DOC2001PLUS is not set
+CONFIG_MTD_NAND=y
+# CONFIG_MTD_NAND_VERIFY_WRITE is not set
+# CONFIG_MTD_NAND_ECC_SMC is not set
+# CONFIG_MTD_NAND_MUSEUM_IDS is not set
+CONFIG_MTD_NAND_IDS=y
+# CONFIG_MTD_NAND_DISKONCHIP is not set
+# CONFIG_MTD_NAND_CAFE is not set
+# CONFIG_MTD_NAND_NANDSIM is not set
+# CONFIG_MTD_NAND_PLATFORM is not set
+CONFIG_MTD_NAND_FSL_ELBC=y
+# CONFIG_MTD_ONENAND is not set
+
+#
+# UBI - Unsorted block images
+#
+# CONFIG_MTD_UBI is not set
CONFIG_OF_DEVICE=y
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
diff --git a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
index 5e1e8cf..782d1cb 100644
--- a/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
+++ b/arch/powerpc/platforms/86xx/mpc8610_hpcd.c
@@ -43,6 +43,7 @@ static unsigned char *pixis_bdcfg0, *pixis_arch;
static struct of_device_id __initdata mpc8610_ids[] = {
{ .compatible = "fsl,mpc8610-immr", },
+ { .compatible = "simple-bus", },
{}
};
--
1.5.5.1
^ permalink raw reply related
* Re: How to link a .o with all modules
From: Sam Ravnborg @ 2008-05-04 19:24 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list, lkml List
In-Reply-To: <6C8AB345-2DA0-460D-B7C8-262463247DDE@kernel.crashing.org>
On Sun, May 04, 2008 at 01:22:38PM -0500, Kumar Gala wrote:
> Sam,
>
> We have a case in powerpc in which we want to link some library
> routines with all module objects. The routines are intended for
> handling out-of-line function call register save/restore so having
> them as EXPORT_SYMBOL() is counter productive (we do also need to link
> the same "library" code into the kernel).
>
> Any suggestions on how to handle this?
I assume you have the .o file build somewhere as part of the
normal kernel build.
Then you in
arch/powerpc/Makefile adds the following assignment:
LDFLAGS_MODULE += arch/powerpc/lib/my_magic_file.o
kbuild will then during the modpost stage link this
file on all modules.
To add the same file to the kernel just include it
in a obj-y += my_magic_file.o
One trap is that my_magic_file.o needs to be built
for a modules build too.
I think you need to assign it to always:
always := my_magic_file.o
to accomplish this.
So in the end we will have:
arch/powerpc/Makefile:
LDFLAGS_MODULE += arch/powerpc/lib/my_magic_file.o
arch/powerpc/lib/Makefile:
always := my_magic_file.o
obj-y += my_magic_file.o
Let me know if this does address your question.
Sam
^ permalink raw reply
* Re: how to check for "optional" ppc chip features (MSR_BE)
From: Benjamin Herrenschmidt @ 2008-05-04 21:45 UTC (permalink / raw)
To: Roland McGrath; +Cc: linuxppc-dev
In-Reply-To: <DC173CDE-FBC4-4EA0-8022-3F993B6466BF@kernel.crashing.org>
On Thu, 2008-05-01 at 22:48 -0500, Kumar Gala wrote:
>
> Look at arch/powerpc/kernel/cputable.c to see how we handle issues
> like this.
>
Oh and classic pitfall: If you define a new feature bit, make sure
CPU_FTRS_POSSIBLE is updated to contain it in cputable.h
Also, It may not be totally clear, but:
PPC_FEATURE_* are exposed to userspace via AT_HWCAP
CPU_FTR_* are kernel internal (and can be used for runtime patching of
assembly code).
Ben.
^ permalink raw reply
* Re: how to check for "optional" ppc chip features (MSR_BE)
From: Roland McGrath @ 2008-05-04 23:12 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1209937549.21644.2.camel@pasglop>
> Oh and classic pitfall: If you define a new feature bit, make sure
> CPU_FTRS_POSSIBLE is updated to contain it in cputable.h
Yeah, all that stuff I could figure out as needed. What I really meant
was, where is the big official table of which chips behave which ways that
you base all code that on? Actually, I don't really care as long as you
all are happy to be responsible for figuring out what matters. With the
patch I posted to use MSR_BE, I took Kumar Gala's word as gospel that all
the chips on which we use MSR_SE also have MSR_BE. If that's not right,
then I hope you'd like to pick a feature bit, populate the tables, etc.,
and fix the definition of arch_has_block_step() as appropriate.
Thanks,
Roland
^ permalink raw reply
* Re: How to link a .o with all modules
From: Paul Mackerras @ 2008-05-04 23:38 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: linuxppc-dev@ozlabs.org list, sam, lkml List
In-Reply-To: <481E4655.7040000@zytor.com>
H. Peter Anvin writes:
> Why is having them as an EXPORT_SYMBOL() counterproductive? It sounds
> like *exactly* what you need -- and then having the kernel provide the
> same code to modules, instead of replication...?
It means we would go through a trampoline just to call little things
like __ucmpdi2, which seems a bit unnecessary.
Paul.
^ permalink raw reply
* Re: How to link a .o with all modules
From: H. Peter Anvin @ 2008-05-04 23:27 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list, sam, lkml List
In-Reply-To: <6C8AB345-2DA0-460D-B7C8-262463247DDE@kernel.crashing.org>
Kumar Gala wrote:
> Sam,
>
> We have a case in powerpc in which we want to link some library routines
> with all module objects. The routines are intended for handling
> out-of-line function call register save/restore so having them as
> EXPORT_SYMBOL() is counter productive (we do also need to link the same
> "library" code into the kernel).
>
Why is having them as an EXPORT_SYMBOL() counterproductive? It sounds
like *exactly* what you need -- and then having the kernel provide the
same code to modules, instead of replication...?
-hpa
^ permalink raw reply
* WARNING: mutexes are preferred for single holder semaphores
From: Sean MacLennan @ 2008-05-05 0:41 UTC (permalink / raw)
To: linuxppc-dev
This is a bit OT, but I got the warning in the subject from
checkpatch.pl for a piece of code. The code *is* using a mutex. Does it
actually mean I shouldn't use a mutex?
The code declares a global mutex:
static DECLARE_MUTEX(list_lock);
The odds of two accesses to the list_lock at the same time are zero.
But it would be Very Bad(tm) if it did happen. Since the odds of
contention are near zero, the cost of the mutex is near zero, so I put
it in.
I think I can safely ignore the warning, but I want to make sure....
Cheers,
Sean
^ permalink raw reply
* Re: how to check for "optional" ppc chip features (MSR_BE)
From: Benjamin Herrenschmidt @ 2008-05-05 0:49 UTC (permalink / raw)
To: Roland McGrath; +Cc: linuxppc-dev
In-Reply-To: <20080504231207.8377E26FA08@magilla.localdomain>
On Sun, 2008-05-04 at 16:12 -0700, Roland McGrath wrote:
> > Oh and classic pitfall: If you define a new feature bit, make sure
> > CPU_FTRS_POSSIBLE is updated to contain it in cputable.h
>
> Yeah, all that stuff I could figure out as needed. What I really meant
> was, where is the big official table of which chips behave which ways that
> you base all code that on?
There isn't any ...
> Actually, I don't really care as long as you
> all are happy to be responsible for figuring out what matters. With the
> patch I posted to use MSR_BE, I took Kumar Gala's word as gospel that all
> the chips on which we use MSR_SE also have MSR_BE. If that's not right,
> then I hope you'd like to pick a feature bit, populate the tables, etc.,
> and fix the definition of arch_has_block_step() as appropriate.
I'll have to check with Paul, we'll scrub the IBM parts, and Kumar can
dbl check the "classic 32" FSL parts.
Ben.
^ permalink raw reply
* Re: WARNING: mutexes are preferred for single holder semaphores
From: Michael Ellerman @ 2008-05-05 1:06 UTC (permalink / raw)
To: Sean MacLennan; +Cc: linuxppc-dev
In-Reply-To: <20080504204104.7eea7618@lappy.seanm.ca>
[-- Attachment #1: Type: text/plain, Size: 719 bytes --]
On Sun, 2008-05-04 at 20:41 -0400, Sean MacLennan wrote:
> This is a bit OT, but I got the warning in the subject from
> checkpatch.pl for a piece of code. The code *is* using a mutex. Does it
> actually mean I shouldn't use a mutex?
>
> The code declares a global mutex:
>
> static DECLARE_MUTEX(list_lock);
.. which is a semaphore :( [see include/linux/semaphore.h]
I think you want DEFINE_MUTEX().
Yes, this is completely ridiculous.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] add Phytec pcm030 board support
From: David Gibson @ 2008-05-05 1:16 UTC (permalink / raw)
To: Sascha Hauer; +Cc: linuxppc-dev
In-Reply-To: <20080425134805.GP6692@pengutronix.de>
On Fri, Apr 25, 2008 at 03:48:05PM +0200, Sascha Hauer wrote:
> Add board support for the Phytec pcm030 mpc5200b based board. It
> does not need any platform specific fixups and as such is handled
> as a mpc5200 simple platform.
Those still whingeing about how horrible and hard and tedious the new
world of device trees is, take note. We've certainly had some
teething problems as we all figure out how to use the device tree
properly. But this is the payoff: support for a new board added with
one text file. It's only going to get more common.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: WARNING: mutexes are preferred for single holder semaphores
From: Sean MacLennan @ 2008-05-05 1:31 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev
In-Reply-To: <1209949615.8159.7.camel@localhost>
On Mon, 05 May 2008 11:06:55 +1000
"Michael Ellerman" <michael@ellerman.id.au> wrote:
> On Sun, 2008-05-04 at 20:41 -0400, Sean MacLennan wrote:
> > This is a bit OT, but I got the warning in the subject from
> > checkpatch.pl for a piece of code. The code *is* using a mutex.
> > Does it actually mean I shouldn't use a mutex?
> >
> > The code declares a global mutex:
> >
> > static DECLARE_MUTEX(list_lock);
>
> .. which is a semaphore :( [see include/linux/semaphore.h]
>
> I think you want DEFINE_MUTEX().
>
> Yes, this is completely ridiculous.
>
> cheers
>
Ok, that fixed it, once I changed all the up and down calls :p
Thanks.
Cheers,
Sean
^ 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