* Re: PS3: Fix build with 32-bit toolchains
From: Grant Likely @ 2007-07-19 22:16 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev, Paul Mackerras, Arnd Bergmann
In-Reply-To: <469FDBDC.5030700@am.sony.com>
On 7/19/07, Geoff Levand <geoffrey.levand@am.sony.com> wrote:
> The PS3 bootwrapper files use instructions only available on
> 64-bit CPUs. Add the code generation directive '.machine "ppc64"'
> for toolchains configured for 32-bit CPUs.
>
> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
> Paul,
>
> Please apply for 2.6.23-rc1.
>
> arch/powerpc/boot/ps3-head.S | 2 ++
> arch/powerpc/boot/ps3-hvcall.S | 2 ++
> 2 files changed, 4 insertions(+)
>
> --- a/arch/powerpc/boot/ps3-head.S
> +++ b/arch/powerpc/boot/ps3-head.S
> @@ -20,6 +20,8 @@
>
> #include "ppc_asm.h"
>
> + .machine "ppc64"
> +
> .text
>
> /*
> --- a/arch/powerpc/boot/ps3-hvcall.S
> +++ b/arch/powerpc/boot/ps3-hvcall.S
> @@ -20,6 +20,8 @@
>
> #include "ppc_asm.h"
>
> + .machine "ppc64"
> +
> /*
> * The PS3 hypervisor uses a 64 bit "C" language calling convention.
> * The routines here marshal arguments between the 32 bit wrapper
>
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 3/4] mpc8349emitx: Add chosen node for default stdout path
From: Grant Likely @ 2007-07-19 22:12 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <20070719164036.f3d4c86d.kim.phillips@freescale.com>
On 7/19/07, Kim Phillips <kim.phillips@freescale.com> wrote:
> On Thu, 19 Jul 2007 13:43:17 -0600
> "Grant Likely" <grant.likely@secretlab.ca> wrote:
>
> > On 7/19/07, Scott Wood <scottwood@freescale.com> wrote:
> > > Grant Likely wrote:
> > > > From: Grant Likely <grant.likely@secretlab.ca>
> > > >
> > > > To boot from a cuImage requires the device tree to have a
> > > > linux,stdout-path property in the chosen node. This patch adds it
> > > > to the .dts files.
> > >
> > > This will break many current u-boots, as they blindly add a /chosen node
> > > regardless of whether one already exists.
> >
> > That really should be fixed then. In the meantime; I'll resubmit the
> > patch to add the chosen node; but with it commented out.
> >
>
> the old FLAT_TREE u-boot fdt fixup code renames any existing chosen
> node out of the way, and adds its fixed up version as /chosen.
>
> The LIBFDT implementation replaces any existing /chosen with its fixed
> up version.
>
> So it all works out. Adding chosen/linux,stdout-path properties to the
> kernel dtses is fine.
>
> btw, why are these changes being limited to the ITX and GP?
Simply because I'm working on an itx-gp board. If this is deemed to
be a good change, I can whip up a patch to fix all boards with my
'best guess' as to what stdout should be.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] powerpc: Add of_register_i2c_devices()
From: Guennadi Liakhovetski @ 2007-07-19 22:07 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <87DC7695-382B-4641-B9D9-75ACB49D41A4@kernel.crashing.org>
On Thu, 19 Jul 2007, Segher Boessenkool wrote:
> > > Your device is an rs5c372b. So, that's what you put in
> > > your device tree. Simple so far, right?
> > >
> > > Now some OF I2C code goes looking for IIC devices in the
> > > device tree. It finds this thing, and from a table or
> > > something it derives that it has to tell the kernel I2C
> > > layer this is an "rtc-rs5c372". [It would be nicer if it
> > > could just instantiate the correct driver directly, but
> > > if that's how the Linux I2C layer works, so be it].
> > >
> > > No change in the I2C "core" needed, just an OF "compatible"
> > > matching thing like is needed *everywhere else* too.
> >
> > How about the patch below?
>
> Looks good. It should later be moved to a more generic
> I2C OF matching layer, but fine for now. Thanks!
>
> You might want to put vendor names in the "compatible"
> entries, dunno though, maybe these are "cross-vendor"
> ICs?
You mean like
compatible = "ricoh,rs5c372a"
etc? With this change, plus __init(data) attributes for functions and the
array, attached below is version 2 of the patch. Corresponding
modifications to the kurobox*.dts will follow separately.
Thanks
Guennadi
---
Guennadi Liakhovetski
Scan the device tree for i2c devices, check their "compatible" property
against a hard-coded table, and, if found, register with i2c boardinfo.
Signed-off-by: G. Liakhovetski <g.liakhovetski@gmx.de>
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/fsl_soc.c
index 3289fab..e07d031 100644
--- a/arch/powerpc/sysdev/fsl_soc.c
+++ b/arch/powerpc/sysdev/fsl_soc.c
@@ -305,6 +305,62 @@ err:
arch_initcall(gfar_of_init);
+#ifdef CONFIG_I2C_BOARDINFO
+#include <linux/i2c.h>
+struct i2c_driver_device {
+ char *of_device;
+ char *i2c_driver;
+ char *i2c_type;
+};
+
+static struct i2c_driver_device i2c_devices[] __initdata = {
+ {"ricoh,rs5c372a", "rtc-rs5c372", "rs5c372a",},
+ {"ricoh,rs5c372b", "rtc-rs5c372", "rs5c372b",},
+ {"ricoh,rv5c386", "rtc-rs5c372", "rv5c386",},
+ {"ricoh,rv5c387a", "rtc-rs5c372", "rv5c387a",},
+};
+
+static int __init of_find_i2c_driver(struct device_node *node, struct i2c_board_info *info)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(i2c_devices); i++) {
+ if (!of_device_is_compatible(node, i2c_devices[i].of_device))
+ continue;
+ strncpy(info->driver_name, i2c_devices[i].i2c_driver, KOBJ_NAME_LEN);
+ strncpy(info->type, i2c_devices[i].i2c_type, I2C_NAME_SIZE);
+ return 0;
+ }
+ return -ENODEV;
+}
+
+static void __init of_register_i2c_devices(struct device_node *adap_node, int bus_num)
+{
+ struct device_node *node = NULL;
+
+ while ((node = of_get_next_child(adap_node, node))) {
+ struct i2c_board_info info;
+ const u32 *addr;
+ int len;
+
+ addr = of_get_property(node, "reg", &len);
+ if (!addr || len < sizeof(int) || *addr > 0xffff)
+ continue;
+
+ info.irq = irq_of_parse_and_map(node, 0);
+ if (info.irq == NO_IRQ)
+ info.irq = -1;
+
+ if (of_find_i2c_driver(node, &info) < 0)
+ continue;
+
+ info.platform_data = NULL;
+ info.addr = *addr;
+
+ i2c_register_board_info(bus_num, &info, 1);
+ }
+}
+
static int __init fsl_i2c_of_init(void)
{
struct device_node *np;
@@ -349,6 +405,8 @@ static int __init fsl_i2c_of_init(void)
fsl_i2c_platform_data));
if (ret)
goto unreg;
+
+ of_register_i2c_devices(np, i);
}
return 0;
@@ -360,6 +418,7 @@ err:
}
arch_initcall(fsl_i2c_of_init);
+#endif
#ifdef CONFIG_PPC_83xx
static int __init mpc83xx_wdt_init(void)
^ permalink raw reply related
* Re: PS3: Fix build with 32-bit toolchains
From: Kumar Gala @ 2007-07-19 22:05 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev, Paul Mackerras, Arnd Bergmann
In-Reply-To: <469FDBDC.5030700@am.sony.com>
On Jul 19, 2007, at 4:47 PM, Geoff Levand wrote:
> The PS3 bootwrapper files use instructions only available on
> 64-bit CPUs. Add the code generation directive '.machine "ppc64"'
> for toolchains configured for 32-bit CPUs.
>
> Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
while this is a fix, why are we even building it Grant's case of
building 834x itx.
- k
^ permalink raw reply
* [PATCH] mv64x60 use mutex instead of semaphore
From: Christoph Hellwig @ 2007-07-19 21:50 UTC (permalink / raw)
To: mgreer; +Cc: linuxppc-dev
Signed-off-by: Christoph Hellwig <hch@lst.de>
Index: linux-2.6/arch/ppc/syslib/mv64x60.c
===================================================================
--- linux-2.6.orig/arch/ppc/syslib/mv64x60.c 2007-07-19 22:47:07.000000000 +0200
+++ linux-2.6/arch/ppc/syslib/mv64x60.c 2007-07-19 22:48:29.000000000 +0200
@@ -14,6 +14,7 @@
#include <linux/pci.h>
#include <linux/slab.h>
#include <linux/module.h>
+#include <linux/mutex.h>
#include <linux/string.h>
#include <linux/spinlock.h>
#include <linux/mv643xx.h>
@@ -2359,7 +2360,7 @@ mv64460_chip_specific_init(struct mv64x6
/* Export the hotswap register via sysfs for enum event monitoring */
#define VAL_LEN_MAX 11 /* 32-bit hex or dec stringified number + '\n' */
-DECLARE_MUTEX(mv64xxx_hs_lock);
+static DEFINE_MUTEX(mv64xxx_hs_lock);
static ssize_t
mv64xxx_hs_reg_read(struct kobject *kobj, char *buf, loff_t off, size_t count)
@@ -2372,14 +2373,14 @@ mv64xxx_hs_reg_read(struct kobject *kobj
if (count < VAL_LEN_MAX)
return -EINVAL;
- if (down_interruptible(&mv64xxx_hs_lock))
+ if (mutex_lock_interruptible(&mv64xxx_hs_lock))
return -ERESTARTSYS;
save_exclude = mv64x60_pci_exclude_bridge;
mv64x60_pci_exclude_bridge = 0;
early_read_config_dword(&sysfs_hose_a, 0, PCI_DEVFN(0, 0),
MV64360_PCICFG_CPCI_HOTSWAP, &v);
mv64x60_pci_exclude_bridge = save_exclude;
- up(&mv64xxx_hs_lock);
+ mutex_unlock(&mv64xxx_hs_lock);
return sprintf(buf, "0x%08x\n", v);
}
@@ -2396,14 +2397,14 @@ mv64xxx_hs_reg_write(struct kobject *kob
return -EINVAL;
if (sscanf(buf, "%i", &v) == 1) {
- if (down_interruptible(&mv64xxx_hs_lock))
+ if (mutex_lock_interruptible(&mv64xxx_hs_lock))
return -ERESTARTSYS;
save_exclude = mv64x60_pci_exclude_bridge;
mv64x60_pci_exclude_bridge = 0;
early_write_config_dword(&sysfs_hose_a, 0, PCI_DEVFN(0, 0),
MV64360_PCICFG_CPCI_HOTSWAP, v);
mv64x60_pci_exclude_bridge = save_exclude;
- up(&mv64xxx_hs_lock);
+ mutex_unlock(&mv64xxx_hs_lock);
}
else
count = -EINVAL;
@@ -2433,10 +2434,10 @@ mv64xxx_hs_reg_valid_show(struct device
pdev = container_of(dev, struct platform_device, dev);
pdp = (struct mv64xxx_pdata *)pdev->dev.platform_data;
- if (down_interruptible(&mv64xxx_hs_lock))
+ if (mutex_lock_interruptible(&mv64xxx_hs_lock))
return -ERESTARTSYS;
v = pdp->hs_reg_valid;
- up(&mv64xxx_hs_lock);
+ mutex_unlock(&mv64xxx_hs_lock);
return sprintf(buf, "%i\n", v);
}
^ permalink raw reply
* PS3: Fix build with 32-bit toolchains
From: Geoff Levand @ 2007-07-19 21:47 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <fa686aa40707191249r1e73f6f7s7f2aa4502919e98a@mail.gmail.com>
The PS3 bootwrapper files use instructions only available on
64-bit CPUs. Add the code generation directive '.machine "ppc64"'
for toolchains configured for 32-bit CPUs.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
Paul,
Please apply for 2.6.23-rc1.
arch/powerpc/boot/ps3-head.S | 2 ++
arch/powerpc/boot/ps3-hvcall.S | 2 ++
2 files changed, 4 insertions(+)
--- a/arch/powerpc/boot/ps3-head.S
+++ b/arch/powerpc/boot/ps3-head.S
@@ -20,6 +20,8 @@
#include "ppc_asm.h"
+ .machine "ppc64"
+
.text
/*
--- a/arch/powerpc/boot/ps3-hvcall.S
+++ b/arch/powerpc/boot/ps3-hvcall.S
@@ -20,6 +20,8 @@
#include "ppc_asm.h"
+ .machine "ppc64"
+
/*
* The PS3 hypervisor uses a 64 bit "C" language calling convention.
* The routines here marshal arguments between the 32 bit wrapper
^ permalink raw reply
* Re: BUG: compile failure on ps3-head.S
From: Segher Boessenkool @ 2007-07-19 21:45 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <fa686aa40707191249r1e73f6f7s7f2aa4502919e98a@mail.gmail.com>
> commit id bafdb645779c63300763acb383f7b9dd2d427228 (on Linus' tree)
> causes breakage on my mpc8349 build (see below). I've worked around
> it by removing ps3* from arch/powerpc/boot/Makefile, but I have not
> dug into what the 'proper' solution should be.
> arch/powerpc/boot/ps3-head.S:40: Error: Unrecognized opcode: `clrldi'
> arch/powerpc/boot/ps3-head.S:41: Error: Unrecognized opcode: `mtmsrd'
Those source files just need a .machine pseudo-op somewhere.
Segher
^ permalink raw reply
* Re: [PATCH 3/4] mpc8349emitx: Add chosen node for default stdout path
From: Scott Wood @ 2007-07-19 21:44 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <20070719164036.f3d4c86d.kim.phillips@freescale.com>
Kim Phillips wrote:
> the old FLAT_TREE u-boot fdt fixup code renames any existing chosen
> node out of the way, and adds its fixed up version as /chosen.
>
> The LIBFDT implementation replaces any existing /chosen with its fixed
> up version.
Could you point out the code that does this? I don't see it in either
the old code or the new.
-Scott
^ permalink raw reply
* Re: [PATCH 3/4] mpc8349emitx: Add chosen node for default stdout path
From: Kim Phillips @ 2007-07-19 21:40 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40707191243wb4ce9c1n86002405c5d01bab@mail.gmail.com>
On Thu, 19 Jul 2007 13:43:17 -0600
"Grant Likely" <grant.likely@secretlab.ca> wrote:
> On 7/19/07, Scott Wood <scottwood@freescale.com> wrote:
> > Grant Likely wrote:
> > > From: Grant Likely <grant.likely@secretlab.ca>
> > >
> > > To boot from a cuImage requires the device tree to have a
> > > linux,stdout-path property in the chosen node. This patch adds it
> > > to the .dts files.
> >
> > This will break many current u-boots, as they blindly add a /chosen node
> > regardless of whether one already exists.
>
> That really should be fixed then. In the meantime; I'll resubmit the
> patch to add the chosen node; but with it commented out.
>
the old FLAT_TREE u-boot fdt fixup code renames any existing chosen
node out of the way, and adds its fixed up version as /chosen.
The LIBFDT implementation replaces any existing /chosen with its fixed
up version.
So it all works out. Adding chosen/linux,stdout-path properties to the
kernel dtses is fine.
btw, why are these changes being limited to the ITX and GP?
Kim
^ permalink raw reply
* Re: [PATCH] Add StorCenter DTS first draft.
From: Benjamin Herrenschmidt @ 2007-07-19 21:39 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <F2806DFF-A43B-4853-A6C0-3D69B0231B06@kernel.crashing.org>
On Thu, 2007-07-19 at 19:07 +0200, Segher Boessenkool wrote:
>
> So your plan is to prefer the device tree over the cputable, and
> maybe even deprecate the cputable?
Nah, you are fine not putting anything, but if it's in the DT it should
be correct, not "0". Else, just don't put it in the DT.
We use the DT to override cputable but that's mostly useful for things
like pSeries where you can get some processors in "compatibility" mode
over another one, or some virtual PVRs, and other fancy things like that
where the cputable isn't very useful.
Ben.
^ permalink raw reply
* Re: Powerpc - Include pagemap.h in asm/powerpc/tlb.h
From: Andrew Morton @ 2007-07-19 21:30 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Mathieu Desnoyers, linux-kernel, Paul Mackerras
In-Reply-To: <E7820A72-36A3-4B4D-A497-974409D3EBDE@kernel.crashing.org>
On Thu, 19 Jul 2007 16:04:38 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
> >> Andrew,
> >>
> >> Are you sending this to linus directly or should this go via paul and
> >> me?
> >>
> >
> > I queued it up for Paul. I can send it over to Linus today if we
> > have a
> > reason for that. It's just that I dont understand the patch: does
> > it fix
> > -mm-only breakage? Does it fix something which already got fixed,
> > or what?
>
> I'm seeing the same breakage in my tree.
Oh, OK. Let's just merge it.
> > One might think "gee, it's trivial, just slam it in", but these nested
> > includes are often not-trivial and something else can explode as a
> > result.
>
> I'll do a git-bisect and see if I can find the patch that causes this
> breakage so we know what's going on.
eh, don't bother.
^ permalink raw reply
* Re: [PATCH 5/5] move 83xx into multiplatform
From: Kumar Gala @ 2007-07-19 21:19 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev@ozlabs.org, paulus, Arnd Bergmann
In-Reply-To: <20070719161013.9f982d8f.kim.phillips@freescale.com>
On Jul 19, 2007, at 4:10 PM, Kim Phillips wrote:
> On Fri, 13 Jul 2007 20:44:57 +0200
> Arnd Bergmann <arnd@arndb.de> wrote:
>
>> MPC83xx based machines don't need their own kernel,
>> but can run one that is shared with the other 6xx
>> compatible machines, so we should allow that
>> in Kconfig.
>>
>> Cc: Kumar Gala <galak@kernel.crashing.org>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> tested, works. Kumar, can we get this in?
Maybe, I need to get at least on PCI patch to makes PCI indirect ops
runtime select big/little endian.
- k
^ permalink raw reply
* Re: [PATCH 5/5] move 83xx into multiplatform
From: Kim Phillips @ 2007-07-19 21:10 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev@ozlabs.org, paulus
In-Reply-To: <20070713184824.312271421@arndb.de>
On Fri, 13 Jul 2007 20:44:57 +0200
Arnd Bergmann <arnd@arndb.de> wrote:
> MPC83xx based machines don't need their own kernel,
> but can run one that is shared with the other 6xx
> compatible machines, so we should allow that
> in Kconfig.
>
> Cc: Kumar Gala <galak@kernel.crashing.org>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
tested, works. Kumar, can we get this in?
Kim
^ permalink raw reply
* Re: Powerpc - Include pagemap.h in asm/powerpc/tlb.h
From: Kumar Gala @ 2007-07-19 21:04 UTC (permalink / raw)
To: Andrew Morton
Cc: linuxppc-dev, Mathieu Desnoyers, linux-kernel, Paul Mackerras
In-Reply-To: <20070719131348.170443bb.akpm@linux-foundation.org>
>> Andrew,
>>
>> Are you sending this to linus directly or should this go via paul and
>> me?
>>
>
> I queued it up for Paul. I can send it over to Linus today if we
> have a
> reason for that. It's just that I dont understand the patch: does
> it fix
> -mm-only breakage? Does it fix something which already got fixed,
> or what?
I'm seeing the same breakage in my tree.
> One might think "gee, it's trivial, just slam it in", but these nested
> includes are often not-trivial and something else can explode as a
> result.
I'll do a git-bisect and see if I can find the patch that causes this
breakage so we know what's going on.
- k
^ permalink raw reply
* Re: 2.6.22-git* regression: Kconfig prompts without help text
From: Stefan Richter @ 2007-07-19 20:49 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Randy Dunlap, Linux/m68k, Michal Piotrowski,
Linux Kernel Mailing List, Linux/PPC Development, Jan Engelhardt,
Andrew Morton
In-Reply-To: <Pine.LNX.4.64.0707192219380.18342@anakin>
Geert Uytterhoeven wrote:
> On Wed, 18 Jul 2007, Jan Engelhardt wrote:
>> Add some help texts to recently-introduced kconfig items
>>
>> Index: linux-2.6.23/drivers/macintosh/Kconfig
>> ===================================================================
>> --- linux-2.6.23.orig/drivers/macintosh/Kconfig
>> +++ linux-2.6.23/drivers/macintosh/Kconfig
>> @@ -3,6 +3,12 @@ menuconfig MACINTOSH_DRIVERS
>> bool "Macintosh device drivers"
>> depends on PPC || MAC || X86
>> default y if (PPC_PMAC || MAC)
>> + ---help---
>> + Say Y here to get to see options for devices used with Macintosh
>> + computers, both PPC and Intel based. This option alone does not add
> ^^^^^
>> + any kernel code.
>> +
>> + If you say N, all options in this submenu will be skipped and disabled.
>
> `MAC' is the symbol for m68k Macs.
OK, then this should read
Say Y here to get to see options for devices used with Macintosh
computers. This option alone does not add any kernel code.
If you say N, all options in this submenu will be skipped and disabled.
> From a quick look at drivers/macintosh/Kconfig, all of the entries are for m68k
> and PPC Macs only. The only thing that depends on X86 is the main menu...
There is one entry for all sorts of Macs, MAC_EMUMOUSEBTN.
--
Stefan Richter
-=====-=-=== -=== =--==
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [PATCH] Treat ISI faults as read faults on classic 32-bit PowerPC
From: Kumar Gala @ 2007-07-19 20:59 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org, Johannes Berg, Paul Mackerras
In-Reply-To: <1184872216.16820.18.camel@ld0161-tx32>
On Jul 19, 2007, at 2:10 PM, Jon Loeliger wrote:
> On Thu, 2007-07-19 at 14:02, Scott Wood wrote:
>
>> glib != glibc.
>>
>> -Scott
>
> D'oh.
>
> So, It doesn't say what version it is.
> But it is also dated 8-Apr-2003.
The glibc jdl tested against is 2.2.5.
- k
^ permalink raw reply
* Re: 2.6.22-git* regression: Kconfig prompts without help text
From: Geert Uytterhoeven @ 2007-07-19 20:26 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Randy Dunlap, Linux/m68k, Michal Piotrowski,
Linux Kernel Mailing List, Linux/PPC Development, Stefan Richter,
Andrew Morton
In-Reply-To: <Pine.LNX.4.64.0707181916410.5385@fbirervta.pbzchgretzou.qr>
On Wed, 18 Jul 2007, Jan Engelhardt wrote:
> Add some help texts to recently-introduced kconfig items
>
> Index: linux-2.6.23/drivers/macintosh/Kconfig
> ===================================================================
> --- linux-2.6.23.orig/drivers/macintosh/Kconfig
> +++ linux-2.6.23/drivers/macintosh/Kconfig
> @@ -3,6 +3,12 @@ menuconfig MACINTOSH_DRIVERS
> bool "Macintosh device drivers"
> depends on PPC || MAC || X86
> default y if (PPC_PMAC || MAC)
> + ---help---
> + Say Y here to get to see options for devices used with Macintosh
> + computers, both PPC and Intel based. This option alone does not add
^^^^^
> + any kernel code.
> +
> + If you say N, all options in this submenu will be skipped and disabled.
`MAC' is the symbol for m68k Macs.
>From a quick look at drivers/macintosh/Kconfig, all of the entries are for m68k
and PPC Macs only. The only thing that depends on X86 is the main menu...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 30/61] fsl_soc: Update the way get_brgfreq() finds things in the device tree.
From: Scott Wood @ 2007-07-19 20:16 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <624A5740-A6D3-4AF3-8AA7-100D0FFFF045@kernel.crashing.org>
Kumar Gala wrote:
> On Jul 18, 2007, at 11:32 AM, Scott Wood wrote:
>> Kumar Gala wrote:
>>> Does 'fsl,cpm' really mean anything useful?
>>
>> Yes. It's can't be used on its own to show the complete programming
>> model, but there are lots of common things that it does indicate.
>>
>> get_brgfreq() uses it to locate nodes which have an fsl,brg- frequency
>> property.
>
> I think we should introduce 'fsl,cpm' in a second pass once its clear
> what all the common points are. We can than also see if QE fits into
> it at that point.
Upon further thought (and upon being clearly outvoted), I agree --
what's common among CPMs today may not be among future CPMs/QEs. In the
absence of a commitment from marketing to call it something else if
certain things change, it's no more meaningful than "xx"-type names.
>> The CPM binding is changed in so many other ways that are much harder
>> to make backward compatible that I don't really see much point in
>> doing so here.
>
> Can you enumerate some of the other changes.
The hardest would probably be the PCI node, whose reg property
definition changed (the previous tree was including other things, such
as DMA controllers, in the PCI register resource). The CPM node also
had its reg property changed, though I don't think anything was using it
yet. The old way of specifying the 8272ads BCSR (in the /memory node)
is just too broken to leave in the device tree.
The old compatible names and custom properties could be left in for a
little while for existing boards, though.
-Scott
^ permalink raw reply
* Re: Powerpc - Include pagemap.h in asm/powerpc/tlb.h
From: Andrew Morton @ 2007-07-19 20:13 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Mathieu Desnoyers, linux-kernel, Paul Mackerras
In-Reply-To: <D9805F9D-04B0-4422-81F1-958B15482A93@kernel.crashing.org>
On Thu, 19 Jul 2007 14:55:23 -0500
Kumar Gala <galak@kernel.crashing.org> wrote:
>
> On Jul 19, 2007, at 12:30 AM, Andrew Morton wrote:
>
> > On Fri, 13 Jul 2007 21:20:33 -0400 Mathieu Desnoyers
> > <mathieu.desnoyers@polymtl.ca> wrote:
> >
> >> Powerpc - Include pagemap.h in asm/powerpc/tlb.h
> >>
> >> Fixes this powerpc build error in 2.6.22-rc6-mm1 for powerpc 64 :
> >>
> >> In file included from include2/asm/tlb.h:60,
> >> from /home/compudj/git/linux-2.6-lttng/arch/
> >> powerpc/mm/init_64.
> >> c:56:
> >> /home/compudj/git/linux-2.6-lttng/include/asm-generic/tlb.h: In
> >> function 'tlb_fl
> >> ush_mmu':
> >> /home/compudj/git/linux-2.6-lttng/include/asm-generic/tlb.h:76:
> >> error: implicit
> >> declaration of function 'release_pages'
> >> /home/compudj/git/linux-2.6-lttng/include/asm-generic/tlb.h: In
> >> function 'tlb_re
> >> move_page':
> >> /home/compudj/git/linux-2.6-lttng/include/asm-generic/tlb.h:105:
> >> error: implicit
> >> declaration of function 'page_cache_release'
> >
> > You have some wordwrapping going on there.
> >
> >> make[2]: *** [arch/powerpc/mm/init_64.o] Error 1
> >>
> >> release_pages is declared in linux/pagemap.h, but cannot be
> >> included in
> >> linux/swap.h because of a sparc related comment:
> >>
> >> /* only sparc can not include linux/pagemap.h in this file
> >> * so leave page_cache_release and release_pages undeclared... */
> >> #define free_page_and_swap_cache(page) \
> >> page_cache_release(page)
> >> #define free_pages_and_swap_cache(pages, nr) \
> >> release_pages((pages), (nr), 0);
> >
> > It's always a worry when this happens. What change made us need this
> > inclusion? How come you're hitting it but I (and test.kernel.org,
> > at least)
> > did not? How come so few other architectures include pagemap.h from
> > asm/tlb.h? Why do header files get into such a mess?
> >
> >
> >> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> >> CC: linuxppc-dev@ozlabs.org
> >> CC: Paul Mackerras <paulus@samba.org>
> >> ---
> >> include/asm-powerpc/tlb.h | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> Index: linux-2.6-lttng/include/asm-powerpc/tlb.h
> >> ===================================================================
> >> --- linux-2.6-lttng.orig/include/asm-powerpc/tlb.h 2007-07-13
> >> 11:30:54.000000000 -0400
> >> +++ linux-2.6-lttng/include/asm-powerpc/tlb.h 2007-07-13
> >> 11:31:22.000000000 -0400
> >> @@ -23,6 +23,8 @@
> >> #include <asm/mmu.h>
> >> #endif
> >>
> >> +#include <linux/pagemap.h>
> >> +
> >> struct mmu_gather;
> >>
> >
> > Oh well. I queued it up for someone else to worry over ;)
>
> Andrew,
>
> Are you sending this to linus directly or should this go via paul and
> me?
>
I queued it up for Paul. I can send it over to Linus today if we have a
reason for that. It's just that I dont understand the patch: does it fix
-mm-only breakage? Does it fix something which already got fixed, or what?
One might think "gee, it's trivial, just slam it in", but these nested
includes are often not-trivial and something else can explode as a result.
^ permalink raw reply
* Re: [PATCH 3/4] mpc8349emitx: Add chosen node for default stdout path
From: Grant Likely @ 2007-07-19 20:00 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: linuxppc-dev
In-Reply-To: <469FC275.7050309@smiths-aerospace.com>
On 7/19/07, Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com> wrote:
> I think the "proper" solution is not to add the /chosen node in the dts
> but rather to generate a _correct_ one in u-boot. Note that
> linux,stdout-path is something that _should_ be generated based on the
> u-boot configuration (currently it is hard #defined, IMHO it should be
> part of the u-boot environment).
That works for u-boot; but it doesn't work for cuImage. As it stands
now; you need different dts files for the two boot methods.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 3/4] mpc8349emitx: Add chosen node for default stdout path
From: Jerry Van Baren @ 2007-07-19 19:58 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40707191243wb4ce9c1n86002405c5d01bab@mail.gmail.com>
Grant Likely wrote:
> On 7/19/07, Scott Wood <scottwood@freescale.com> wrote:
>> Grant Likely wrote:
>>> From: Grant Likely <grant.likely@secretlab.ca>
>>>
>>> To boot from a cuImage requires the device tree to have a
>>> linux,stdout-path property in the chosen node. This patch adds it
>>> to the .dts files.
>> This will break many current u-boots, as they blindly add a /chosen node
>> regardless of whether one already exists.
>
> That really should be fixed then. In the meantime; I'll resubmit the
> patch to add the chosen node; but with it commented out.
>
> g.
We are working on fixing that with the "u-boot-fdt" subtree, but it is
slow going and it will not magically fix already fielded boards.
(Forget that Harry Potter crap magic, _that_ would be some useful magic!)
I think the "proper" solution is not to add the /chosen node in the dts
but rather to generate a _correct_ one in u-boot. Note that
linux,stdout-path is something that _should_ be generated based on the
u-boot configuration (currently it is hard #defined, IMHO it should be
part of the u-boot environment).
Looks like it is at fdt_support.c line 152:
<http://www.denx.de/cgi-bin/gitweb.cgi?p=u-boot/u-boot-fdt.git;a=blob;f=common/fdt_support.c;h=259bd42cc62c55d11370579a7af0d6519fc34c8d;hb=fdt#l152>
Best regards,
gvb
^ permalink raw reply
* Re: [PATCH 1/2] Fix error checking in Vitesse IRQ config
From: Kumar Gala @ 2007-07-19 19:57 UTC (permalink / raw)
To: Jeff Garzik; +Cc: netdev, linuxppc-dev@ozlabs.org list
In-Reply-To: <11847405503115-git-send-email-afleming@freescale.com>
On Jul 18, 2007, at 1:35 AM, Andy Fleming wrote:
> phy_read() returns a negative number if there's an error, but the
> error-checking code in the Vitesse driver's config_intr function
> triggers if phy_read() returns non-zero. Correct that.
>
> Signed-off-by: Andy Fleming <afleming@freescale.com>
Jeff,
Can you make sure to send this to linus since its need to properly
fix the Vitesse phy's used on the 8641HPCN and 8544 DS boards.
thanks
- k
> ---
> I made a really stupid mistake in the 4 patches I sent out,
> earlier. I
> thought those patches had been tested, but they hadn't been. This one
> corrects a tiny error in the patch, and they have now been tested.
> As before
> this change can be pulled from:
>
> http://opensource.freescale.com/pub/scm/linux-2.6-85xx.git netdev
>
> Really, REALLY sorry about that. I have been given a paper bag of
> appropriate
> size and shape to fit over my head.
>
> drivers/net/phy/vitesse.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/phy/vitesse.c b/drivers/net/phy/vitesse.c
> index 6a53856..8874497 100644
> --- a/drivers/net/phy/vitesse.c
> +++ b/drivers/net/phy/vitesse.c
> @@ -109,7 +109,7 @@ static int vsc824x_config_intr(struct
> phy_device *phydev)
> */
> err = phy_read(phydev, MII_VSC8244_ISTAT);
>
> - if (err)
> + if (err < 0)
> return err;
>
> err = phy_write(phydev, MII_VSC8244_IMASK, 0);
> --
> 1.5.0.2.230.gfbe3d-dirty
>
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Powerpc - Include pagemap.h in asm/powerpc/tlb.h
From: Kumar Gala @ 2007-07-19 19:55 UTC (permalink / raw)
To: Andrew Morton
Cc: linuxppc-dev, Mathieu Desnoyers, linux-kernel, Paul Mackerras
In-Reply-To: <20070718223034.7388e59f.akpm@linux-foundation.org>
On Jul 19, 2007, at 12:30 AM, Andrew Morton wrote:
> On Fri, 13 Jul 2007 21:20:33 -0400 Mathieu Desnoyers
> <mathieu.desnoyers@polymtl.ca> wrote:
>
>> Powerpc - Include pagemap.h in asm/powerpc/tlb.h
>>
>> Fixes this powerpc build error in 2.6.22-rc6-mm1 for powerpc 64 :
>>
>> In file included from include2/asm/tlb.h:60,
>> from /home/compudj/git/linux-2.6-lttng/arch/
>> powerpc/mm/init_64.
>> c:56:
>> /home/compudj/git/linux-2.6-lttng/include/asm-generic/tlb.h: In
>> function 'tlb_fl
>> ush_mmu':
>> /home/compudj/git/linux-2.6-lttng/include/asm-generic/tlb.h:76:
>> error: implicit
>> declaration of function 'release_pages'
>> /home/compudj/git/linux-2.6-lttng/include/asm-generic/tlb.h: In
>> function 'tlb_re
>> move_page':
>> /home/compudj/git/linux-2.6-lttng/include/asm-generic/tlb.h:105:
>> error: implicit
>> declaration of function 'page_cache_release'
>
> You have some wordwrapping going on there.
>
>> make[2]: *** [arch/powerpc/mm/init_64.o] Error 1
>>
>> release_pages is declared in linux/pagemap.h, but cannot be
>> included in
>> linux/swap.h because of a sparc related comment:
>>
>> /* only sparc can not include linux/pagemap.h in this file
>> * so leave page_cache_release and release_pages undeclared... */
>> #define free_page_and_swap_cache(page) \
>> page_cache_release(page)
>> #define free_pages_and_swap_cache(pages, nr) \
>> release_pages((pages), (nr), 0);
>
> It's always a worry when this happens. What change made us need this
> inclusion? How come you're hitting it but I (and test.kernel.org,
> at least)
> did not? How come so few other architectures include pagemap.h from
> asm/tlb.h? Why do header files get into such a mess?
>
>
>> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
>> CC: linuxppc-dev@ozlabs.org
>> CC: Paul Mackerras <paulus@samba.org>
>> ---
>> include/asm-powerpc/tlb.h | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> Index: linux-2.6-lttng/include/asm-powerpc/tlb.h
>> ===================================================================
>> --- linux-2.6-lttng.orig/include/asm-powerpc/tlb.h 2007-07-13
>> 11:30:54.000000000 -0400
>> +++ linux-2.6-lttng/include/asm-powerpc/tlb.h 2007-07-13
>> 11:31:22.000000000 -0400
>> @@ -23,6 +23,8 @@
>> #include <asm/mmu.h>
>> #endif
>>
>> +#include <linux/pagemap.h>
>> +
>> struct mmu_gather;
>>
>
> Oh well. I queued it up for someone else to worry over ;)
Andrew,
Are you sending this to linus directly or should this go via paul and
me?
- k
^ permalink raw reply
* BUG: compile failure on ps3-head.S
From: Grant Likely @ 2007-07-19 19:49 UTC (permalink / raw)
To: Geoff Levand, linuxppc-dev, Arnd Bergmann, Scott Wood
commit id bafdb645779c63300763acb383f7b9dd2d427228 (on Linus' tree)
causes breakage on my mpc8349 build (see below). I've worked around
it by removing ps3* from arch/powerpc/boot/Makefile, but I have not
dug into what the 'proper' solution should be.
Cheers,
g.
Toolchain: gcc version 4.0.0 (DENX ELDK 4.0 4.0.0)
Build command: make mpc834x_itxgp_defconfig; make zImage
make ARCH=ppc64 -f scripts/Makefile.build obj=arch/powerpc/boot
arch/powerpc/boot/zImage
ppc_6xx-gcc -m32 -Wp,-MD,arch/powerpc/boot/.ps3-head.o.d
-D__ASSEMBLY__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -Os -msoft-float -pipe -fomit-frame-pointer
-fno-builtin -fPIC -nostdinc -isystem
/home/opt/eldk-4.0/usr/bin/../lib/gcc/powerpc-linux/4.0.0/include
-traditional -nostdinc -c -o arch/powerpc/boot/ps3-head.o
arch/powerpc/boot/ps3-head.S
arch/powerpc/boot/ps3-head.S: Assembler messages:
arch/powerpc/boot/ps3-head.S:40: Error: Unrecognized opcode: `clrldi'
arch/powerpc/boot/ps3-head.S:41: Error: Unrecognized opcode: `mtmsrd'
make[1]: *** [arch/powerpc/boot/ps3-head.o] Error 1
make: *** [zImage] Error 2
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH 3/4] mpc8349emitx: Add chosen node for default stdout path
From: Grant Likely @ 2007-07-19 19:43 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <469FB47D.4030009@freescale.com>
On 7/19/07, Scott Wood <scottwood@freescale.com> wrote:
> Grant Likely wrote:
> > From: Grant Likely <grant.likely@secretlab.ca>
> >
> > To boot from a cuImage requires the device tree to have a
> > linux,stdout-path property in the chosen node. This patch adds it
> > to the .dts files.
>
> This will break many current u-boots, as they blindly add a /chosen node
> regardless of whether one already exists.
That really should be fixed then. In the meantime; I'll resubmit the
patch to add the chosen node; but with it commented out.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ 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