* Re: [PATCH 1/4] Merge dtc and libfdt upstream source
From: David Gibson @ 2007-11-12 22:43 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20071112171240.GA4394@loki.buserror.net>
On Mon, Nov 12, 2007 at 11:12:40AM -0600, Scott Wood wrote:
> On Mon, Nov 12, 2007 at 03:15:24PM +1100, David Gibson wrote:
> > This very large patch incorporates a copy of dtc (including libfdt)
> > into the kernel source, in arch/powerpc/boot/dtc-src. This patch only
> > imports the upstream sources verbatim, later patches are needed to
> > actually link it into the kernel Makefiles and use the embedded code
> > during the kernel build.
>
> Maybe it should go somewhere outside arch/powerpc, so it can be used by
> other architectures down the road.
If other architectures want to use it down the road, we can move it
down the road.
--
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: [PATCH] sungem: fix suspend regression due to NAPI changes
From: Benjamin Herrenschmidt @ 2007-11-12 22:32 UTC (permalink / raw)
To: Johannes Berg
Cc: netdev, Stephen Hemminger, David S. Miller, linuxppc-dev list
In-Reply-To: <1194889547.4456.4.camel@johannes.berg>
On Mon, 2007-11-12 at 18:45 +0100, Johannes Berg wrote:
> Commit bea3348e (the NAPI changes) made sungem unconditionally enable
> NAPI when resuming and unconditionally disable when suspending, this,
> however, makes napi_disable() hang when suspending when the interface
> was taken down before suspend because taking the interface down also
> disables NAPI. This patch makes touching the napi struct in
> suspend/resume code paths depend on having the interface up, thereby
> fixing the hang on suspend.
>
> The patch also moves the napi_disable() in gem_close() under the lock so
> that the NAPI state is always modified atomically together with the
> "opened" variable.
>
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Thanks for fixing that !
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
> ---
> drivers/net/sungem.c | 11 +++++------
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> --- everything.orig/drivers/net/sungem.c 2007-11-12 18:22:49.948748047 +0100
> +++ everything/drivers/net/sungem.c 2007-11-12 18:24:30.708748481 +0100
> @@ -2333,10 +2333,10 @@ static int gem_close(struct net_device *
> {
> struct gem *gp = dev->priv;
>
> - napi_disable(&gp->napi);
> -
> mutex_lock(&gp->pm_mutex);
>
> + napi_disable(&gp->napi);
> +
> gp->opened = 0;
> if (!gp->asleep)
> gem_do_stop(dev, 0);
> @@ -2355,8 +2355,6 @@ static int gem_suspend(struct pci_dev *p
>
> mutex_lock(&gp->pm_mutex);
>
> - napi_disable(&gp->napi);
> -
> printk(KERN_INFO "%s: suspending, WakeOnLan %s\n",
> dev->name,
> (gp->wake_on_lan && gp->opened) ? "enabled" : "disabled");
> @@ -2370,6 +2368,8 @@ static int gem_suspend(struct pci_dev *p
>
> /* If the driver is opened, we stop the MAC */
> if (gp->opened) {
> + napi_disable(&gp->napi);
> +
> /* Stop traffic, mark us closed */
> netif_device_detach(dev);
>
> @@ -2460,6 +2460,7 @@ static int gem_resume(struct pci_dev *pd
> /* Re-attach net device */
> netif_device_attach(dev);
>
> + napi_enable(&gp->napi);
> }
>
> spin_lock_irqsave(&gp->lock, flags);
> @@ -2479,8 +2480,6 @@ static int gem_resume(struct pci_dev *pd
> spin_unlock(&gp->tx_lock);
> spin_unlock_irqrestore(&gp->lock, flags);
>
> - napi_enable(&gp->napi);
> -
> mutex_unlock(&gp->pm_mutex);
>
> return 0;
>
^ permalink raw reply
* RE: [PATCH] [POWERPC] Optimize counting distinct entries in therelocation sections
From: Medve Emilian @ 2007-11-12 22:31 UTC (permalink / raw)
To: Paul Mackerras; +Cc: sfr, rusty, linuxppc-embedded, linuxppc-dev
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E270174DB3E@az33exm24.fsl.freescale.net>
Hello Paul,
> > Actually I notice that count_relocs is counting all relocs, not just
> > the R_PPC_REL24 ones, which are all that we actually care about in
> > sizing the PLT. And I would be willing to bet that every single
> > R_PPC_REL24 reloc has r_addend =3D=3D 0.
>=20
> I'll count only the R_PPC_REL24 and I'll validate if they=20
> have r_addend
> =3D=3D 0.
Seems like there are R_PPC_REL24 with r_addend !=3D 0. Within a set of =
41
modules (featuring 5457 R_PPC_REL24 relocations) already included within
the kernel tree I found 37 such relocations (R_PPC_REL24) with r_addend
!=3D 0. In my test case, from 35K relocations, 7K are R_PPC_REL24 and =
from
those only 8 have r_addend !=3D 0.
> > Also I notice that even with your patch, the actual process of doing
> > the relocations will take time proportional to the product of the
> > number of PLT entries times the number of R_PPC_REL24 relocations,
> > since we do a linear search through the PLT entries each time.
>=20
> The reason I started working on this patch was because the kernel
> detected a soft lockup in count_relocs(). It didn't complain=20
> about other
> parts so I did nothing about them.
Since the time hog in my case (and other's cases, reflected by the
previous patches) seems to be count_relocs(), would it be acceptable as
an incremental improvement to fix this now and address the relocation
process performance (later) if needed?
I'll resubmit the patch incorporating some of the feedback from you and
Rusty.
Cheers,
Emil.
^ permalink raw reply
* Re: [PATCH v4 04/13] [POWERPC] Add generic support for simple MPC5200 based boards
From: Marian Balakowicz @ 2007-11-12 22:28 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-dev
In-Reply-To: <20071110124327.1C46A248D3@gemini.denx.de>
Wolfgang Denk wrote:
> In message <20071109171202.16289.2618.stgit@hekate.izotz.org> you wrote:
>> This patch adds support for 'mpc5200-simple-platform' compatible
>> boards which do not need a platform specific setup. Such boards
>> are supported assuming the following:
> ...
>> + const char *board[] = {
>> + "tqc,tqm5200",
>> + "promess,motionpro",
>> + "schindler,cm5200",
>> + NULL
>> + };
>
> would it make sense to sort this list alphabetiacally? At the moment
> we can setill easily find each board, but assume that list grows to 50
> boards names...
Yes, that may be helpful, will change that.
Cheers,
Marian
^ permalink raw reply
* Re: [PATCH v4 00/13] [POWERPC] Add TQM5200/CM5200/Motion-PRO board support
From: Marian Balakowicz @ 2007-11-12 22:26 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <fa686aa40711091852wa1210d3t3c44d4e43f5ee40d@mail.gmail.com>
Grant Likely wrote:
> On 11/9/07, Grant Likely <grant.likely@secretlab.ca> wrote:
>> On 11/9/07, Marian Balakowicz <m8@semihalf.com> wrote:
>>> Please review, and if everything is ok schedule for 2.6.24-rc3.
>> Just to be clear, I won't be picking up these changes until the 2.6.25
>> merge window.
>>
>> The .24 tree is closed for new board support patches and is in bug fix
>> only mode.
>
> Ummm; on rereading this (after getting gently nudged on IRC) I realize
> my reply was both inaccurate and just plain rude. Sorry about that,
> it was unintentional.
Not a problem, really, no worries.
> Yes, I'll be picking up your patches into my tree fairly soon (before
> the .25 merge window opens), but I cannot ask Paul to pick it up for
> 2.6.24 because .24 is only open for bug fixes.
Understand, thanks!
Cheers,
Marian
^ permalink raw reply
* Re: [PATCH v4 04/13] [POWERPC] Add generic support for simple MPC5200 based boards
From: Marian Balakowicz @ 2007-11-12 22:22 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20071110113133.86aa3de2.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> On Fri, 09 Nov 2007 18:12:02 +0100 Marian Balakowicz <m8@semihalf.com> wrote:
>> +++ b/arch/powerpc/platforms/52xx/mpc5200_simple.c
>>
>> +static int __init mpc5200_simple_probe(void)
>> +{
>> + unsigned long node = of_get_flat_dt_root();
>
> You need to include asm/prom.h to use the flattened device tree accessors.
Right, but this one is already included in mpc52xx.h.
>> + /* list of the supported boards */
>> + const char *board[] = {
>> + "tqc,tqm5200",
>> + "promess,motionpro",
>> + "schindler,cm5200",
>> + NULL
>> + };
>
> Make that static.
Board table is no longer needed after kernel is initialized, it would
be nice to declare it static and __initdata, but that would be quite
ugly as it's a table of pointers and each string would require
separate statement too. If we don't do it then what's the benefit of
making it static?
Cheers,
m.
^ permalink raw reply
* Re: [linux-pm] Re: [RFC] powermac: proper sleep management
From: Alan Stern @ 2007-11-12 21:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Johannes Berg, David Woodhouse, linux-pm
In-Reply-To: <1194900998.18185.57.camel@pasglop>
On Tue, 13 Nov 2007, Benjamin Herrenschmidt wrote:
> I remember fixing various issues so that khubd would be safe when non
> frozen (among other things) a while ago. Did you guys break it all
> again ?
Sorry, I don't know what fixes you're referring to. But come to
think of it, some changes I added to the PM core a few months ago
(locking every device prior to system sleep) would also make khubd
and ksuspend_usbd safe, since they acquire the device lock before
trying to resume anything.
So I take back what I said. It's no longer true that those two USB
kernel threads need to be frozen for system sleep. (I should test and
make sure that really works...)
But aren't there other kernel threads scattered around that still
want to be frozen? For instance, drivers/misc/tifm_core.c calls
create_freezeable_workqueue(). And set_freezable() gets called in lots
of places.
Alan Stern
^ permalink raw reply
* Re: Gianfar ethernet device
From: Jon Smirl @ 2007-11-12 21:25 UTC (permalink / raw)
To: benh; +Cc: PowerPC dev list
In-Reply-To: <9e4733910711111716oea3572fq9bc42221f805e11@mail.gmail.com>
On 11/11/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> On 11/11/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> >
> > > The real solution is that gianfar support belongs in a device driver,
> > > not in a common file. That whole fsl_soc.c file is a catch-all of
> > > things that belong in device drivers. I haven't looked at every line
> > > in it, but 90%+ of the code should be moved into device drivers.
> > >
> > > I'm preparing a patch that moves the i2c driver out of fsl_soc.c and
> > > into i2c_mpc.c.
> >
> > The problem is how do you instantiate it. I'm working on some solution
> > for that but it's not there yet.
What's an example of a device that can't be instantiated?
>
> Are there powerpc platforms without device trees?
>
> Standard of_platform driver works fine to instantiate the i2c driver
> on mpc5200.
>
> static struct of_device_id mpc_i2c_of_match[] = {
> {
> .compatible = "fsl-i2c",
> },
> };
> MODULE_DEVICE_TABLE(of, mpc_i2c_of_match);
>
> /* Structure for a device driver */
> static struct of_platform_driver mpc_i2c_driver = {
> .match_table = mpc_i2c_of_match,
> .probe = mpc_i2c_probe,
> .remove = __devexit_p(mpc_i2c_remove),
> .driver = {
> .owner = THIS_MODULE,
> .name = DRV_NAME,
> },
> };
>
> static int __init mpc_i2c_init(void)
> {
> int rv;
>
> rv = of_register_platform_driver(&mpc_i2c_driver);
> if (rv) {
> printk(KERN_ERR DRV_NAME " of_register_platform_driver failed (%i)\n", rv);
> return rv;
> }
> return 0;
> }
>
> module_init(mpc_i2c_init);
>
> ----------------------------------------------------------------------------------------------
>
> i2c and alsa soc core instantiate like this, asoc v2 is not in tree
> yet. These cores used to create platform drivers, but that was wrong,
> they don't have any hardware associated with them.
>
> static int __init i2c_init(void)
> {
> int retval;
>
> retval = bus_register(&i2c_bus_type);
> if (retval)
> return retval;
> return class_register(&i2c_adapter_class);
> }
>
> subsys_initcall(i2c_init);
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [linux-pm] Re: [RFC] powermac: proper sleep management
From: Benjamin Herrenschmidt @ 2007-11-12 20:56 UTC (permalink / raw)
To: Alan Stern; +Cc: linuxppc-dev list, Johannes Berg, David Woodhouse, linux-pm
In-Reply-To: <Pine.LNX.4.44L0.0711121534070.3128-100000@netrider.rowland.org>
On Mon, 2007-11-12 at 15:40 -0500, Alan Stern wrote:
> On Tue, 13 Nov 2007, Benjamin Herrenschmidt wrote:
>
> >
> > On Mon, 2007-11-12 at 17:32 +0100, Johannes Berg wrote:
> > > > Looks good to me, +/- a couple of things:
> > > >
> > > > - We _REALLY_ want the freezer to be optional and not enabled by
> > > > default on PowerPC. Maybe make it a compile option ?
> > >
> > > Well, Alan is going to tell you that USB will break. If we need
> > > confirmation for that I can do the test he suggested to you or Paul a
> > > while ago.
> >
> > Then USB is broken today on powermacs and need to be fixed. We had a
> > clear agreement at KS this year that the freezer was at best a band-aid
> > and that drivers -had- to be fixed to cope regardless.
>
> More accurately, freezing user tasks is at best a band-aid. However
> some kernel threads do need to be frozen, and keeping the freezer
> around for their use makes sense. It has less overhead -- I think
> -- than adding new code to do the freezing in each of these threads.
I remember fixing various issues so that khubd would be safe when non
frozen (among other things) a while ago. Did you guys break it all
again ?
Ben.
^ permalink raw reply
* Re: [linux-pm] Re: [RFC] powermac: proper sleep management
From: Alan Stern @ 2007-11-12 20:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev list, Johannes Berg, David Woodhouse, linux-pm
In-Reply-To: <1194899041.18185.55.camel@pasglop>
On Tue, 13 Nov 2007, Benjamin Herrenschmidt wrote:
>
> On Mon, 2007-11-12 at 17:32 +0100, Johannes Berg wrote:
> > > Looks good to me, +/- a couple of things:
> > >
> > > - We _REALLY_ want the freezer to be optional and not enabled by
> > > default on PowerPC. Maybe make it a compile option ?
> >
> > Well, Alan is going to tell you that USB will break. If we need
> > confirmation for that I can do the test he suggested to you or Paul a
> > while ago.
>
> Then USB is broken today on powermacs and need to be fixed. We had a
> clear agreement at KS this year that the freezer was at best a band-aid
> and that drivers -had- to be fixed to cope regardless.
More accurately, freezing user tasks is at best a band-aid. However
some kernel threads do need to be frozen, and keeping the freezer
around for their use makes sense. It has less overhead -- I think
-- than adding new code to do the freezing in each of these threads.
(It's true that USB drivers in general aren't written to operate in a
freezerless system-suspend environment. That's a harder problem and
it will have to be fixed driver-by-driver, over time. The same may be
true for lots of non-USB char device drivers as well. Pick your
favorite char device driver: How will it behave if a user task submits
an I/O request after the device has been suspended?)
Alan Stern
^ permalink raw reply
* [PATCH] cell: Convert #include of asm/of_{platform, device}.h into linux/of_{platform, device}.h.
From: Jon Loeliger @ 2007-11-12 20:26 UTC (permalink / raw)
To: linuxppc-dev@ozlabs.org
From: Jon Loeliger <jdl@freescale.com>
Signed-off-by: Jon Loeliger <jdl@freescale.com>
---
arch/powerpc/platforms/cell/cbe_cpufreq.c | 3 ++-
arch/powerpc/platforms/cell/cbe_cpufreq_pmi.c | 3 ++-
arch/powerpc/platforms/cell/cbe_regs.c | 4 ++--
arch/powerpc/platforms/cell/iommu.c | 2 +-
arch/powerpc/platforms/cell/setup.c | 2 +-
5 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/cell/cbe_cpufreq.c b/arch/powerpc/platforms/cell/cbe_cpufreq.c
index 13d5a87..ec7c8f4 100644
--- a/arch/powerpc/platforms/cell/cbe_cpufreq.c
+++ b/arch/powerpc/platforms/cell/cbe_cpufreq.c
@@ -21,8 +21,9 @@
*/
#include <linux/cpufreq.h>
+#include <linux/of_platform.h>
+
#include <asm/machdep.h>
-#include <asm/of_platform.h>
#include <asm/prom.h>
#include <asm/cell-regs.h>
#include "cbe_cpufreq.h"
diff --git a/arch/powerpc/platforms/cell/cbe_cpufreq_pmi.c b/arch/powerpc/platforms/cell/cbe_cpufreq_pmi.c
index 6a2c1b0..69288f6 100644
--- a/arch/powerpc/platforms/cell/cbe_cpufreq_pmi.c
+++ b/arch/powerpc/platforms/cell/cbe_cpufreq_pmi.c
@@ -23,7 +23,8 @@
#include <linux/kernel.h>
#include <linux/types.h>
#include <linux/timer.h>
-#include <asm/of_platform.h>
+#include <linux/of_platform.h>
+
#include <asm/processor.h>
#include <asm/prom.h>
#include <asm/pmi.h>
diff --git a/arch/powerpc/platforms/cell/cbe_regs.c b/arch/powerpc/platforms/cell/cbe_regs.c
index 16a9b07..a839c6c 100644
--- a/arch/powerpc/platforms/cell/cbe_regs.c
+++ b/arch/powerpc/platforms/cell/cbe_regs.c
@@ -9,13 +9,13 @@
#include <linux/percpu.h>
#include <linux/types.h>
#include <linux/module.h>
+#include <linux/of_device.h>
+#include <linux/of_platform.h>
#include <asm/io.h>
#include <asm/pgtable.h>
#include <asm/prom.h>
#include <asm/ptrace.h>
-#include <asm/of_device.h>
-#include <asm/of_platform.h>
#include <asm/cell-regs.h>
/*
diff --git a/arch/powerpc/platforms/cell/iommu.c b/arch/powerpc/platforms/cell/iommu.c
index faabc3f..179ba2e 100644
--- a/arch/powerpc/platforms/cell/iommu.c
+++ b/arch/powerpc/platforms/cell/iommu.c
@@ -26,13 +26,13 @@
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/notifier.h>
+#include <linux/of_platform.h>
#include <asm/prom.h>
#include <asm/iommu.h>
#include <asm/machdep.h>
#include <asm/pci-bridge.h>
#include <asm/udbg.h>
-#include <asm/of_platform.h>
#include <asm/lmb.h>
#include <asm/cell-regs.h>
diff --git a/arch/powerpc/platforms/cell/setup.c b/arch/powerpc/platforms/cell/setup.c
index 98e7ef8..4f6347c 100644
--- a/arch/powerpc/platforms/cell/setup.c
+++ b/arch/powerpc/platforms/cell/setup.c
@@ -30,6 +30,7 @@
#include <linux/console.h>
#include <linux/mutex.h>
#include <linux/memory_hotplug.h>
+#include <linux/of_platform.h>
#include <asm/mmu.h>
#include <asm/processor.h>
@@ -51,7 +52,6 @@
#include <asm/spu_priv1.h>
#include <asm/udbg.h>
#include <asm/mpic.h>
-#include <asm/of_platform.h>
#include <asm/cell-regs.h>
#include "interrupt.h"
--
1.5.3
^ permalink raw reply related
* Re: [RFC] powermac: proper sleep management
From: Benjamin Herrenschmidt @ 2007-11-12 20:24 UTC (permalink / raw)
To: Johannes Berg
Cc: linuxppc-dev list, linux-pm, David Woodhouse, Paul Mackerras
In-Reply-To: <1194885177.5229.45.camel@johannes.berg>
On Mon, 2007-11-12 at 17:32 +0100, Johannes Berg wrote:
> > Looks good to me, +/- a couple of things:
> >
> > - We _REALLY_ want the freezer to be optional and not enabled by
> > default on PowerPC. Maybe make it a compile option ?
>
> Well, Alan is going to tell you that USB will break. If we need
> confirmation for that I can do the test he suggested to you or Paul a
> while ago.
Then USB is broken today on powermacs and need to be fixed. We had a
clear agreement at KS this year that the freezer was at best a band-aid
and that drivers -had- to be fixed to cope regardless.
> Obviously. I don't have any of that. I'd appreciate if somebody could
> test on a 3400 powerbook to see if that pci config space save/restore
> stuff is really necessary or even interferes with the regular stuff.
Might not be that necessary anymore nowadays, the generic code ought to
do it, but I'll give a go, I have one of those (paulus old one) though
last I tried, the HD was dead.
Ben.
^ permalink raw reply
* Re: [linux-pm] Re: [RFC] powermac: proper sleep management
From: Alan Stern @ 2007-11-12 19:52 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-pm, David Woodhouse, linuxppc-dev list
In-Reply-To: <1194885177.5229.45.camel@johannes.berg>
On Mon, 12 Nov 2007, Johannes Berg wrote:
> > Looks good to me, +/- a couple of things:
> >
> > - We _REALLY_ want the freezer to be optional and not enabled by
> > default on PowerPC. Maybe make it a compile option ?
>
> Well, Alan is going to tell you that USB will break. If we need
> confirmation for that I can do the test he suggested to you or Paul a
> while ago.
Isn't it true that the freezer _already_ isn't enabled on PPC? So
leaving it off wouldn't break anything more than it is broken now.
Alan Stern
^ permalink raw reply
* small bootloader that passes arguments
From: khollan @ 2007-11-12 19:54 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I would like to create a small bootloader that is able to pass kernel
arguments and boot a linux kernel. Im using a xilinx PPC, and have already
booted a working kernel with a Xilinx provided XMD bootloader over USB. My
main question is how does a bootloader pass these arguments to the kernel
before booting it? Most specifically the root=/dev/xsa1 command so I can
tell it to either boot from compact flash or NFS.
I really don't want to try and port U-boot since I don't need the bells and
whistles and I want it to fit in the BRAM of the FPGA so it will load when I
load the hardware configuration.
--
View this message in context: http://www.nabble.com/small-bootloader-that-passes-arguments-tf4793411.html#a13712778
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] powerpc: Add support for PORTA sor and PORTB odr registers
From: Scott Wood @ 2007-11-12 17:42 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: paulus, linux-kernel, linuxppc-embedded@ozlabs.org
In-Reply-To: <473736FB.7090609@scram.de>
Jochen Friedrich wrote:
> PORTA has an so register and PORTB had an odr register, as well.
> However, the PORTB odr register is only 16bit.
Which 8xx chip has a so register on port A? I checked the 860, 866,
885, and 823 manuals and didn't see one.
-Scott
^ permalink raw reply
* Re: PPC440EPx on Sequoia: /proc/iomem acts weird
From: Steven A. Falco @ 2007-11-12 19:25 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200711101403.48792.sr@denx.de>
[-- Attachment #1: Type: text/plain, Size: 1670 bytes --]
First I will say that I don't understand resources well enough to
suggest a fix. But I have done a little poking around. In file
arch/powerpc/platforms/44x/ppc4xx-nand.c I see one "struct resource",
which is referenced by two "struct platform_device" items (ndfc_dev and
nand_dev).
In routine ppc4xx_setup_nand_node() we have two calls to
platform_device_register():
platform_device_register(&ndfc_dev);
platform_device_register(&nand_dev);
If I comment out the second one, then there is no loop in the resource
tree, and I can cat /proc/iomem just fine. If both calls are present,
then cat /proc/iomem loops forever.
So, just a wild guess - should there be two "struct resource"s, one for
each platform_device, or is there some other way to break the loop in
the tree?
Steve
Stefan Roese wrote:
> Hi Steve,
>
> On Friday 09 November 2007, Steven A. Falco wrote:
>
>> I am using the Denx 2.6.32 kernel, which does have powerpc/sequoia.
>> Xenomai is a real-time kernel built on Adeos/Ipipe. I'll dig into it
>> further.
>>
>
> Is this arch/ppc or arch/powerpc? I remember fixing this a while ago in
> arch/ppc:
>
> commit 67a35ce785b1d11d09bf528c166ea26d489a4bd6
> Author: Stefan Roese <sr@denx.de>
> Date: Thu Aug 2 14:15:22 2007 +0200
>
> ppc: Fix problem with recursive NDFC platform_device resource management
>
> This change fixes a problem with a resursive platform_device resource
> management of the AMCC 4xx NDFC. Without this fix a "cat /proc/iomem"
> leads to an infinite loop of printing the "ndfc-nand.0" resource.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
>
> Best regards,
> Stefan
>
>
[-- Attachment #2: Type: text/html, Size: 2231 bytes --]
^ permalink raw reply
* RE: [PATCH 1/4] Merge dtc and libfdt upstream source
From: Stephen Neuendorffer @ 2007-11-12 18:51 UTC (permalink / raw)
To: Scott Wood, David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20071112171240.GA4394@loki.buserror.net>
> -----Original Message-----
> From:=20
> linuxppc-dev-bounces+stephen.neuendorffer=3Dxilinx.com@ozlabs.or
> g=20
> [mailto:linuxppc-dev-bounces+stephen.neuendorffer=3Dxilinx.com@o
zlabs.org] On Behalf Of Scott Wood
> Sent: Monday, November 12, 2007 9:13 AM
> To: David Gibson
> Cc: linuxppc-dev@ozlabs.org; Paul Mackerras
> Subject: Re: [PATCH 1/4] Merge dtc and libfdt upstream source
>=20
> On Mon, Nov 12, 2007 at 03:15:24PM +1100, David Gibson wrote:
> > This very large patch incorporates a copy of dtc (including libfdt)
> > into the kernel source, in arch/powerpc/boot/dtc-src. This=20
> patch only
> > imports the upstream sources verbatim, later patches are needed to
> > actually link it into the kernel Makefiles and use the embedded code
> > during the kernel build.
>=20
> Maybe it should go somewhere outside arch/powerpc, so it can=20
> be used by
> other architectures down the road.
>=20
> -Scott
I second that...
Steve
^ permalink raw reply
* [PATCH] sungem: fix suspend regression due to NAPI changes
From: Johannes Berg @ 2007-11-12 17:45 UTC (permalink / raw)
To: David S. Miller; +Cc: linuxppc-dev list, Stephen Hemminger, netdev
Commit bea3348e (the NAPI changes) made sungem unconditionally enable
NAPI when resuming and unconditionally disable when suspending, this,
however, makes napi_disable() hang when suspending when the interface
was taken down before suspend because taking the interface down also
disables NAPI. This patch makes touching the napi struct in
suspend/resume code paths depend on having the interface up, thereby
fixing the hang on suspend.
The patch also moves the napi_disable() in gem_close() under the lock so
that the NAPI state is always modified atomically together with the
"opened" variable.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
drivers/net/sungem.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
--- everything.orig/drivers/net/sungem.c 2007-11-12 18:22:49.948748047 +0100
+++ everything/drivers/net/sungem.c 2007-11-12 18:24:30.708748481 +0100
@@ -2333,10 +2333,10 @@ static int gem_close(struct net_device *
{
struct gem *gp = dev->priv;
- napi_disable(&gp->napi);
-
mutex_lock(&gp->pm_mutex);
+ napi_disable(&gp->napi);
+
gp->opened = 0;
if (!gp->asleep)
gem_do_stop(dev, 0);
@@ -2355,8 +2355,6 @@ static int gem_suspend(struct pci_dev *p
mutex_lock(&gp->pm_mutex);
- napi_disable(&gp->napi);
-
printk(KERN_INFO "%s: suspending, WakeOnLan %s\n",
dev->name,
(gp->wake_on_lan && gp->opened) ? "enabled" : "disabled");
@@ -2370,6 +2368,8 @@ static int gem_suspend(struct pci_dev *p
/* If the driver is opened, we stop the MAC */
if (gp->opened) {
+ napi_disable(&gp->napi);
+
/* Stop traffic, mark us closed */
netif_device_detach(dev);
@@ -2460,6 +2460,7 @@ static int gem_resume(struct pci_dev *pd
/* Re-attach net device */
netif_device_attach(dev);
+ napi_enable(&gp->napi);
}
spin_lock_irqsave(&gp->lock, flags);
@@ -2479,8 +2480,6 @@ static int gem_resume(struct pci_dev *pd
spin_unlock(&gp->tx_lock);
spin_unlock_irqrestore(&gp->lock, flags);
- napi_enable(&gp->napi);
-
mutex_unlock(&gp->pm_mutex);
return 0;
^ permalink raw reply
* Re: [PATCH] powerpc: Add EXPORT_SYMBOL for symbols required by fs_enet and cpm_uart
From: Scott Wood @ 2007-11-12 17:29 UTC (permalink / raw)
To: Jochen Friedrich; +Cc: paulus, linux-kernel, linuxppc-embedded@ozlabs.org
In-Reply-To: <47373571.3070605@scram.de>
Jochen Friedrich wrote:
> fs_enet and cpm_uart need symbols from commproc.c (for CPM1) or
> cpm2_common.c. Add EXPORT_SYMBOL for cpmp, cpm_setbrg and cpm2_immr, so
> the drivers can be compiled as modules.
>
> Building modules, stage 2.
> MODPOST 5 modules
> ERROR: "cpm2_immr" [drivers/net/fs_enet/fs_enet.ko] undefined!
> ERROR: "cpmp" [drivers/net/fs_enet/fs_enet.ko] undefined!
> make[1]: *** [__modpost] Error 1
> make: *** [modules] Error 2
>
> Signed-off-by: Jochen Friedrich <jochen@scram.de>
Acked-by: Scott Wood <scottwood@freescale.com>
^ permalink raw reply
* Re: [PATCH 1/4] Merge dtc and libfdt upstream source
From: Scott Wood @ 2007-11-12 17:12 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20071112041524.C6C5FDDED2@ozlabs.org>
On Mon, Nov 12, 2007 at 03:15:24PM +1100, David Gibson wrote:
> This very large patch incorporates a copy of dtc (including libfdt)
> into the kernel source, in arch/powerpc/boot/dtc-src. This patch only
> imports the upstream sources verbatim, later patches are needed to
> actually link it into the kernel Makefiles and use the embedded code
> during the kernel build.
Maybe it should go somewhere outside arch/powerpc, so it can be used by
other architectures down the road.
-Scott
^ permalink raw reply
* RE: [PATCH] [POWERPC] Optimize counting distinct entries in the relocation sections
From: Medve Emilian @ 2007-11-12 16:50 UTC (permalink / raw)
To: Paul Mackerras; +Cc: sfr, rusty, linuxppc-dev, ntl, linuxppc-embedded
In-Reply-To: <18231.60427.229658.485287@cargo.ozlabs.ibm.com>
Hello Paul,
> Actually I notice that count_relocs is counting all relocs, not just
> the R_PPC_REL24 ones, which are all that we actually care about in
> sizing the PLT. And I would be willing to bet that every single
> R_PPC_REL24 reloc has r_addend =3D=3D 0.
I'll count only the R_PPC_REL24 and I'll validate if they have r_addend
=3D=3D 0.
> Also I notice that even with your patch, the actual process of doing
> the relocations will take time proportional to the product of the
> number of PLT entries times the number of R_PPC_REL24 relocations,
> since we do a linear search through the PLT entries each time.
The reason I started working on this patch was because the kernel
detected a soft lockup in count_relocs(). It didn't complain about other
parts so I did nothing about them.
> So, two approaches suggest themselves. Both optimize the r_addend=3D0
> case and fall back to something like the current code if r_addend is
> not zero. The first is to use the st_other field in the symbol to
> record whether we have seen a R_PPC_REL24 reloc referring to the
> symbol with r_addend=3D0. That would make count_relocs of complexity
> O(N) for N relocs.
Will look into it.
> The second is to allocate an array with 1 pointer per symbol that
> points to the PLT entry (if any) for the symbol. The count_relocs
> scan can then use that array to store a 'seen before' flag to make its
> scan O(N), and do_plt_call can then later use the same array to find
> PLT entries without needing the linear scan.
This uses extra memory (which could be 'significant' for small boards)
and I was trying to avoid that.
> As far as your proposed patch is concerned, I don't like having a
> function called "count_relocs" changing the array of relocations. At
> the very least it needs a different name. But I also think we can do
> better than O(N * log N), as I have explained above, if my assertion
> that r_addend=3D0 in all the cases we care about is correct.
The array of relocations is not changed in count_relocs() but in
get_plt_size().
Thanks for your time and patience,
Emil.
^ permalink raw reply
* Re: [PATCH] powerpc: Add EXPORT_SYMBOL for symbols required by fs_enet and cpm_uart
From: Scott Wood @ 2007-11-12 16:49 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-kernel, paulus, linuxppc-embedded@ozlabs.org
In-Reply-To: <20071111201503.GA18749@infradead.org>
Christoph Hellwig wrote:
> On Sun, Nov 11, 2007 at 06:01:37PM +0100, Jochen Friedrich wrote:
>> --- a/arch/powerpc/sysdev/commproc.c
>> +++ b/arch/powerpc/sysdev/commproc.c
>> @@ -51,6 +51,8 @@ static void m8xx_cpm_dpinit(void);
>> static uint host_buffer; /* One page of host buffer */
>> static uint host_end; /* end + 1 */
>> cpm8xx_t __iomem *cpmp; /* Pointer to comm processor space */
>> +EXPORT_SYMBOL(cpmp);
>
> Sorry, but this is a nightmare waiting to happen. Please define
> proper accessors instead.
We have proper accessors: in_be32, out_be16, etc.
Now, is the huge struct encompassing all of immr space a bad idea?
Sure. Are we working towards getting rid of it? Yes. Is that a reason
to keep modules from working in the meantime? No.
> (And get rid of the typedef while you're at it)
Again, changing all the users is a bit beyond the scope of this patch.
-Scott
^ permalink raw reply
* MPC5200B - Mapping Micrel Ethernet Controller Chip
From: Sri nava kala devi Valteti, TLS-Chennai @ 2007-11-12 16:41 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Prakash Palanisamy, TLS-Chennai
[-- Attachment #1: Type: text/plain, Size: 1857 bytes --]
Hi,
We are using MPC5200B based custom board. In that we have an external
Micrel's ethernet controller mapped at 0xE0000000.
We have taken Lite5200 code as a reference to port linux to our new
board. We have integrated the ethernet driver given by the vendor
(Micrel).
Unfortunately, we are not able to access the chip mapped at 0xE0000000.
We performed the following steps to access the chip:
i) We mapped this address range of the Ethernet Controller Chip in
function "mpc52xx_map_io" as
"io_block_mapping(0xE0000000, 0xE0000000, 0x10000000, _PAGE_IO)"
ii) We tried to remap the address range using ioremap function, but we
got the same address (Virtual Address similar to IO logical Address)
even after the ioremap.
Can any one plz help us on how to map and access our chip?
Thanks,
Kala.
DISCLAIMER:
-----------------------------------------------------------------------------------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have
received this email in error please delete it and notify the sender immediately. Before opening any mail and
attachments please check them for viruses and defect.
-----------------------------------------------------------------------------------------------------------------------
[-- Attachment #2: Type: text/html, Size: 4886 bytes --]
^ permalink raw reply
* Re: [RFC] PMU: replace information ioctls and schedule for removal
From: Johannes Berg @ 2007-11-12 16:33 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev list
In-Reply-To: <1194814546.6510.20.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 616 bytes --]
On Mon, 2007-11-12 at 07:55 +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2007-11-08 at 13:02 +0100, Johannes Berg wrote:
> > This patch adds sysfs attributes to the PMU to allow getting
> > the information on the PMU type and whether adb is present from
> > there instead of via the ioctl. The ioctl is made optional and
> > scheduled for removal.
>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> While there, maybe also expose the PMU version ?
Does anybody need that? I'm not against adding it but we never showed it
and I haven't seen anyone ask for it.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [RFC] powermac: proper sleep management
From: Johannes Berg @ 2007-11-12 16:32 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev list, linux-pm, David Woodhouse, Paul Mackerras
In-Reply-To: <1194814773.6510.23.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 759 bytes --]
> Looks good to me, +/- a couple of things:
>
> - We _REALLY_ want the freezer to be optional and not enabled by
> default on PowerPC. Maybe make it a compile option ?
Well, Alan is going to tell you that USB will break. If we need
confirmation for that I can do the test he suggested to you or Paul a
while ago.
> - Don't remove the pmu_polled_request() debug code. It's very useful
> for debugging and I don't want to have to re-invent it.
Heh, ok.
> Plus I also need to test it on some exotic hardware :-)
Obviously. I don't have any of that. I'd appreciate if somebody could
test on a 3400 powerbook to see if that pci config space save/restore
stuff is really necessary or even interferes with the regular stuff.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ 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