* Re: libfdt as its own repo and submodule of dtc?
From: Kumar Gala @ 2007-11-01 6:55 UTC (permalink / raw)
To: David Gibson; +Cc: linux-ppc list, Jon Loeliger, Jerry Van Baren
In-Reply-To: <20071030234011.GE2784@localhost.localdomain>
On Oct 30, 2007, at 6:40 PM, David Gibson wrote:
> On Tue, Oct 30, 2007 at 01:14:06PM -0400, Jerry Van Baren wrote:
>> Jon Loeliger wrote:
>>> So, like, the other day Kumar Gala mumbled:
>>>> Jon,
>>>>
>>>> It seems like have libfdt as a unique git repo that is a
>>>> submodule of
>>>> the things that need it (dtc, u-boot, etc.) might make some
>>>> sense and it
>>>> easier for the projects that need to pull it in.
>>>>
>>>> Is this something you can take a look at? (or have other ideas on).
>>> I would be fine with making libfdt a git repository separate
>>> from the DTC repository if that makes it easier to integrate
>>> it with other projects.
>
> I don't think it's a good idea to make dtc and libfdt entirely
> seperate repositories (again). Being able to use both together in
> their combined testsuite is very useful (libfdt is used to check trees
> generated by dtc, dtc is used to generate example trees for libfdt
> testing).
>
> I'm not sure how submodules/subrepositories work so I don't know if
> that makes sense.
I believe submodules will accomplish this (at least from what I can
tell).
- k
^ permalink raw reply
* Re: [PATCH 1/3] Add remove_memory() for ppc64
From: Kumar Gala @ 2007-11-01 6:26 UTC (permalink / raw)
To: Badari Pulavarty
Cc: linux-mm, anton, linuxppc-dev, Paul Mackerras, Andrew Morton,
KAMEZAWA Hiroyuki
In-Reply-To: <1193849375.17412.34.camel@dyn9047017100.beaverton.ibm.com>
On Oct 31, 2007, at 11:49 AM, Badari Pulavarty wrote:
> Supply arch specific remove_memory() for PPC64. There is nothing
> ppc specific code here and its exactly same as ia64 version.
> For now, lets keep it arch specific - so each arch can add
> its own special things if needed.
>
> Signed-off-by: Badari Pulavarty <pbadari@us.ibm.com>
> ---
What's ppc64 specific about these patches?
- k
^ permalink raw reply
* RE: RFC: replace device_type with new "class" property?
From: Yoder Stuart-B08248 @ 2007-10-31 18:05 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: Olof Johansson, linuxppc-dev, David Gibson
In-Reply-To: <20071031170610.GA4444@loki.buserror.net>
=20
> -----Original Message-----
> From: Wood Scott-B07421=20
> Sent: Wednesday, October 31, 2007 12:06 PM
> To: Yoder Stuart-B08248
> Cc: David Gibson; Olof Johansson; linuxppc-dev@ozlabs.org
> Subject: Re: RFC: replace device_type with new "class" property?
>=20
> On Wed, Oct 31, 2007 at 08:31:02AM -0700, Yoder Stuart-B08248 wrote:
> > This works...but certainly is weaker with respect to
> > standardization. My previous argument had the assumption
> > that something like "mac-address" in a network node was
> > _required_, and thus needed a class id of some sort to tie
> > the standardized node to.
>=20
> It is certainly not required -- the device could have an=20
> eeprom, or it might
> not be ethernet at all.
Fine, I picked a bad example. My point was that if a
property was _required_ that it should have a class id
of some sort that ties it back to the standard that
required it.
Stuart
^ permalink raw reply
* Re: PPC405GP Walnut irq patch
From: Steven A. Falco @ 2007-10-31 17:52 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071030204015.06a699d7@vader.jdub.homelinux.org>
[-- Attachment #1: Type: text/plain, Size: 271 bytes --]
> Could you redo the patch with just this bit and send it again?
>
> josh
>
Ok - this one is based off the Linus tree, and follows your style of one
interrupt per line, with a comment indicating which one it is.
Signed-off-by: Steve Falco <sfalco at harris.com>
[-- Attachment #2: irq.patch --]
[-- Type: text/x-patch, Size: 548 bytes --]
diff --git a/arch/powerpc/boot/dts/walnut.dts b/arch/powerpc/boot/dts/walnut.dts
index fa681f5..754fa39 100644
--- a/arch/powerpc/boot/dts/walnut.dts
+++ b/arch/powerpc/boot/dts/walnut.dts
@@ -122,7 +122,9 @@
device_type = "network";
compatible = "ibm,emac-405gp", "ibm,emac";
interrupt-parent = <&UIC0>;
- interrupts = <9 4 f 4>;
+ interrupts = <
+ f 4 /* Ethernet */
+ 9 4 /* Ethernet Wake Up */>;
local-mac-address = [000000000000]; /* Filled in by zImage */
reg = <ef600800 70>;
mal-device = <&MAL>;
^ permalink raw reply related
* [PATCH] [powerpc v3] update xmon slb code
From: Will Schmidt @ 2007-10-31 17:29 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
[powerpc] update xmon slb code
This adds a bit more detail to the xmon SLB output. When the valid bit is
set, This displays the ESID and VSID values, as well as decoding the
segment size, (1T or 256M) and displaying the LLP bits. This supresses the
output for any slb entries that contain only zeros.
sample output from power6 (1T segment support):
00 c000000008000000 40004f7ca3000500 1T ESID= c00000 VSID= 4f7ca3 LLP:100
01 d000000008000000 4000eb71b0000400 1T ESID= d00000 VSID= eb71b0 LLP: 0
08 0000000018000000 0000c8499f8ccc80 256M ESID= 1 VSID= c8499f8cc LLP: 0
09 00000000f8000000 0000d2c1a8e46c80 256M ESID= f VSID= d2c1a8e46 LLP: 0
10 0000000048000000 0000ca87eab1dc80 256M ESID= 4 VSID= ca87eab1d LLP: 0
43 cf00000008000000 400011b260000500 1T ESID= cf0000 VSID= 11b260 LLP:100
sample output from power5 (notice the non-valid but non-zero entries)
10 0000000008000000 00004fd0e077ac80 256M ESID= 0 VSID= 4fd0e077a LLP: 0
11 00000000f8000000 00005b085830fc80 256M ESID= f VSID= 5b085830f LLP: 0
12 0000000048000000 000052ce99fe6c80 256M ESID= 4 VSID= 52ce99fe6 LLP: 0
13 0000000018000000 000050904ed95c80 256M ESID= 1 VSID= 50904ed95 LLP: 0
14 cf00000008000000 0000d59aca40f500 256M ESID=cf0000000 VSID= d59aca40f LLP:100
15 c000000078000000 000045cb97751500 256M ESID=c00000007 VSID= 45cb97751 LLP:100
Tested on power5 and power6.
Signed-Off-By: Will Schmidt <will_schmidt@vnet.ibm.com>
---
(Updates made per comments from Olof and Ben and Paul).
This version adds padding around the ESID and VSID fields, and the LLP bits
are displayed too.
Counting bits, the VSID output looks to be as large as 51 bits, which requires
up to 13 spaces. This doesnt count the B field bits which are now masked off
the top end of the VSID output.
I'll try to follow up sometime later with code that will handle decoding page
sizes. I dont have a testcase handy to properly exercise that yet. :-)
---
arch/powerpc/xmon/xmon.c | 29 +++++++++++++++++++++++------
1 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 121b04d..5314db7 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -2527,16 +2527,33 @@ static void xmon_print_symbol(unsigned long address, const char *mid,
static void dump_slb(void)
{
int i;
- unsigned long tmp;
+ unsigned long esid,vsid,valid;
+ unsigned long llp;
printf("SLB contents of cpu %x\n", smp_processor_id());
for (i = 0; i < SLB_NUM_ENTRIES; i++) {
- asm volatile("slbmfee %0,%1" : "=r" (tmp) : "r" (i));
- printf("%02d %016lx ", i, tmp);
-
- asm volatile("slbmfev %0,%1" : "=r" (tmp) : "r" (i));
- printf("%016lx\n", tmp);
+ asm volatile("slbmfee %0,%1" : "=r" (esid) : "r" (i));
+ asm volatile("slbmfev %0,%1" : "=r" (vsid) : "r" (i));
+ valid = (esid & SLB_ESID_V);
+ if (valid | esid | vsid) {
+ printf("%02d %016lx %016lx", i, esid, vsid);
+ if (valid) {
+ llp = vsid & SLB_VSID_LLP;
+ if (vsid & SLB_VSID_B_1T) {
+ printf(" 1T ESID=%9lx VSID=%13lx LLP:%3lx \n",
+ GET_ESID_1T(esid),
+ (vsid & ~SLB_VSID_B) >> SLB_VSID_SHIFT_1T,
+ llp);
+ } else {
+ printf(" 256M ESID=%9lx VSID=%13lx LLP:%3lx \n",
+ GET_ESID(esid),
+ (vsid & ~SLB_VSID_B) >> SLB_VSID_SHIFT,
+ llp);
+ }
+ } else
+ printf("\n");
+ }
}
}
^ permalink raw reply related
* Re: RFC: replace device_type with new "class" property?
From: Scott Wood @ 2007-10-31 17:06 UTC (permalink / raw)
To: Yoder Stuart-B08248; +Cc: Olof Johansson, linuxppc-dev, David Gibson
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA3035F2AC3@az33exm25.fsl.freescale.net>
On Wed, Oct 31, 2007 at 08:31:02AM -0700, Yoder Stuart-B08248 wrote:
> This works...but certainly is weaker with respect to
> standardization. My previous argument had the assumption
> that something like "mac-address" in a network node was
> _required_, and thus needed a class id of some sort to tie
> the standardized node to.
It is certainly not required -- the device could have an eeprom, or it might
not be ethernet at all.
-Scott
^ permalink raw reply
* Re: [RFC] hotplug memory remove - walk_memory_resource for ppc64
From: KAMEZAWA Hiroyuki @ 2007-10-31 15:46 UTC (permalink / raw)
To: Badari Pulavarty; +Cc: linuxppc-dev, anton, paulus, linux-mm
In-Reply-To: <1193846560.17412.3.camel@dyn9047017100.beaverton.ibm.com>
On Wed, 31 Oct 2007 08:02:40 -0800
Badari Pulavarty <pbadari@us.ibm.com> wrote:
> Paul's concern is, since we didn't need it so far - why we need this
> for hotplug memory remove to work ? It might break API for *unknown*
> applications. Its unfortunate that, hotplug memory add updates
> /proc/iomem. We can deal with it later, as a separate patch.
>
I have no objection to skip /proc/iomem related routine when arch
doesn't need it.
My advice is just "please take care both of hot-add and hot-remove".
If ppc64 people agreed to use arch-specific routine for detect
conventional memory, there is no problem, I think.
Thanks,
-Kame
^ permalink raw reply
* [PATCH 1/3] Add remove_memory() for ppc64
From: Badari Pulavarty @ 2007-10-31 16:49 UTC (permalink / raw)
To: Paul Mackerras, Andrew Morton
Cc: linuxppc-dev, anton, KAMEZAWA Hiroyuki, linux-mm
Supply arch specific remove_memory() for PPC64. There is nothing
ppc specific code here and its exactly same as ia64 version.
For now, lets keep it arch specific - so each arch can add
its own special things if needed.
Signed-off-by: Badari Pulavarty <pbadari@us.ibm.com>
---
arch/powerpc/mm/mem.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
Index: linux-2.6.23/arch/powerpc/mm/mem.c
===================================================================
--- linux-2.6.23.orig/arch/powerpc/mm/mem.c 2007-10-25 11:34:54.000000000 -0700
+++ linux-2.6.23/arch/powerpc/mm/mem.c 2007-10-25 11:35:24.000000000 -0700
@@ -131,6 +131,20 @@ int __devinit arch_add_memory(int nid, u
#endif /* CONFIG_MEMORY_HOTPLUG */
+#ifdef CONFIG_MEMORY_HOTREMOVE
+int remove_memory(u64 start, u64 size)
+{
+ unsigned long start_pfn, end_pfn;
+ unsigned long timeout = 120 * HZ;
+ int ret;
+ start_pfn = start >> PAGE_SHIFT;
+ end_pfn = start_pfn + (size >> PAGE_SHIFT);
+ ret = offline_pages(start_pfn, end_pfn, timeout);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(remove_memory);
+#endif /* CONFIG_MEMORY_HOTREMOVE */
+
void show_mem(void)
{
unsigned long total = 0, reserved = 0;
^ permalink raw reply
* [PATCH 3/3] Add arch-specific walk_memory_remove() for ppc64
From: Badari Pulavarty @ 2007-10-31 16:48 UTC (permalink / raw)
To: Paul Mackerras, Andrew Morton
Cc: linuxppc-dev, anton, KAMEZAWA Hiroyuki, linux-mm
walk_memory_resource() verifies if there are holes in a given
memory range, by checking against /proc/iomem. On x86/ia64
system memory is represented in /proc/iomem. On PPC64, we
don't show system memory as IO resource in /proc/iomem - instead
its maintained in /proc/device-tree.
This patch provides a way for an architecture to provide its
own walk_memory_resource() function. On PPC64, the memory
region is small (16MB), contiguous and non-overlapping.
So extra checking, against device-tree is not needed.
Signed-off-by: Badari Pulavarty <pbadari@us.ibm.com>
Acked-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
---
arch/powerpc/Kconfig | 3 +++
arch/powerpc/mm/mem.c | 16 ++++++++++++++++
kernel/resource.c | 2 +-
3 files changed, 20 insertions(+), 1 deletion(-)
Index: linux-2.6.24-rc1/arch/powerpc/mm/mem.c
===================================================================
--- linux-2.6.24-rc1.orig/arch/powerpc/mm/mem.c 2007-10-30 07:39:16.000000000 -0800
+++ linux-2.6.24-rc1/arch/powerpc/mm/mem.c 2007-10-31 07:17:52.000000000 -0800
@@ -129,6 +129,22 @@ int __devinit arch_add_memory(int nid, u
return __add_pages(zone, start_pfn, nr_pages);
}
+/*
+ * walk_memory_resource() needs to make sure there is no holes in a given
+ * memory range. On PPC64, since this range comes from /sysfs, the range
+ * is guaranteed to be valid, non-overlapping and can not contain any
+ * holes. By the time we get here (memory add or remove), /proc/device-tree
+ * is updated and correct. Only reason we need to check against device-tree
+ * would be if we allow user-land to specify a memory range through a
+ * system call/ioctl etc.. (instead of doing offline/online through /sysfs.
+ */
+int
+walk_memory_resource(unsigned long start_pfn, unsigned long nr_pages, void *arg,
+ int (*func)(unsigned long, unsigned long, void *))
+{
+ return (*func)(start_pfn, nr_pages, arg);
+}
+
#endif /* CONFIG_MEMORY_HOTPLUG */
#ifdef CONFIG_MEMORY_HOTREMOVE
Index: linux-2.6.24-rc1/kernel/resource.c
===================================================================
--- linux-2.6.24-rc1.orig/kernel/resource.c 2007-10-23 20:50:57.000000000 -0700
+++ linux-2.6.24-rc1/kernel/resource.c 2007-10-30 08:58:41.000000000 -0800
@@ -228,7 +228,7 @@ int release_resource(struct resource *ol
EXPORT_SYMBOL(release_resource);
-#ifdef CONFIG_MEMORY_HOTPLUG
+#if defined(CONFIG_MEMORY_HOTPLUG) && !defined(CONFIG_ARCH_HAS_WALK_MEMORY)
/*
* Finds the lowest memory reosurce exists within [res->start.res->end)
* the caller must specify res->start, res->end, res->flags.
Index: linux-2.6.24-rc1/arch/powerpc/Kconfig
===================================================================
--- linux-2.6.24-rc1.orig/arch/powerpc/Kconfig 2007-10-30 07:39:17.000000000 -0800
+++ linux-2.6.24-rc1/arch/powerpc/Kconfig 2007-10-30 08:54:57.000000000 -0800
@@ -234,6 +234,9 @@ config HOTPLUG_CPU
config ARCH_ENABLE_MEMORY_HOTPLUG
def_bool y
+config ARCH_HAS_WALK_MEMORY
+ def_bool y
+
config ARCH_ENABLE_MEMORY_HOTREMOVE
def_bool y
^ permalink raw reply
* [PATCH 2/3] Enable hotplug memory remove for ppc64
From: Badari Pulavarty @ 2007-10-31 16:48 UTC (permalink / raw)
To: Paul Mackerras, Andrew Morton
Cc: linuxppc-dev, anton, KAMEZAWA Hiroyuki, linux-mm
Enable hotplug memory remove for ppc64.
Signed-off-by: Badari Pulavarty <pbadari@us.ibm.com>
---
arch/powerpc/Kconfig | 3 +++
1 file changed, 3 insertions(+)
Index: linux-2.6.23/arch/powerpc/Kconfig
===================================================================
--- linux-2.6.23.orig/arch/powerpc/Kconfig 2007-10-23 09:39:29.000000000 -0700
+++ linux-2.6.23/arch/powerpc/Kconfig 2007-10-25 11:44:57.000000000 -0700
@@ -234,6 +234,9 @@ config HOTPLUG_CPU
config ARCH_ENABLE_MEMORY_HOTPLUG
def_bool y
+config ARCH_ENABLE_MEMORY_HOTREMOVE
+ def_bool y
+
config KEXEC
bool "kexec system call (EXPERIMENTAL)"
depends on (PPC_PRPMC2800 || PPC_MULTIPLATFORM) && EXPERIMENTAL
^ permalink raw reply
* [PATCH 0/3] hotplug memory remove support for PPC64
From: Badari Pulavarty @ 2007-10-31 16:48 UTC (permalink / raw)
To: Paul Mackerras, Andrew Morton
Cc: linuxppc-dev, anton, KAMEZAWA Hiroyuki, linux-mm
In-Reply-To: <20071031143423.586498c3.kamezawa.hiroyu@jp.fujitsu.com>
Hi Paul/Andrew,
Here are few minor fixes needed to get hotplug memory remove working
on ppc64. Could you please consider them for -mm ?
[PATCH 1/3] Add remove_memory() for ppc64
[PATCH 2/3] Enable hotplug memory remove for ppc64
[PATCH 3/3] Add arch-specific walk_memory_remove() for ppc64
I am able to successfully add/remove memory on ppc64 with these patches.
ZONE_MOVABLE guarantees the success, if we really really want to be able
to remove memory.
Thanks to Mel and KAME for doing all the real work :)
TODO:
- I am running into migrate_pages() issues on reiserfs backed
files. Nothing to do with ppc64.
Thanks,
Badari
^ permalink raw reply
* RE: Refactor booting-without-of.txt
From: Yoder Stuart-B08248 @ 2007-10-31 15:44 UTC (permalink / raw)
To: Grant Likely, linuxppc-dev, microblaze-uclinux
In-Reply-To: <fa686aa40710150908o55d1f5d2t264cbb8ed800a12f@mail.gmail.com>
=20
> -----Original Message-----
> From: linuxppc-dev-bounces+b08248=3Dfreescale.com@ozlabs.org=20
> [mailto:linuxppc-dev-bounces+b08248=3Dfreescale.com@ozlabs.org]=20
> On Behalf Of Grant Likely
> Sent: Monday, October 15, 2007 11:09 AM
> To: linuxppc-dev; microblaze-uclinux@itee.uq.edu.au
> Subject: Refactor booting-without-of.txt
>=20
> Adding the Linux expected device tree bindings to
> booting-without-of.txt seems to be getting a little unwieldy. Plus
> with more than one arch using the device tree (powerpc, sparc &
> microblaze) the device tree bindings aren't necessarily powerpc only
> (the Xilinx devices certainly fall in this category).
>=20
> Anyone have comments about splitting the expected device tree bindings
> out of booting-without-of.txt into a separate directory?
>=20
> Perhaps something like this; each file contains common bindings for
> the type of device and device specific properties:
>=20
> Documentation/of/
> Documentation/of/README - Description of the purpose and layout of
> this directory
> Documentation/of/net.txt - network device bindings (eth,=20
> MDIO, phy, etc)
> Documentation/of/serial.txt - serial device bindings
> Documentation/of/misc.txt - anything that doesn't fit=20
> anywhere else yet.
> Documentation/of/soc/* - System on chip stuff that doesn't fit will
> into established device types; possibly a separate file for each chip.
> Documentation/of/usb.txt - usb blah blah blah
> Documentation/of/whatever - you get the picture.
>=20
I agree in principle with what your are proposing.
One other thing to consider-- as has been publicly=20
announced in several forums, a committee in power.org
(including several folks on this thread) is working
on a standard called the ePAPR which in general is
attempting to standardize the base set of requirements
and boot conventions that apply to the flat device tree.
There will not be much device specific stuff to=20
start with.
The ePAPR document is actually quite far a long
and is well beyond the 'idea' stage.
The one point is that we hope that the device tree
with be useful for other embedded OSes beyond Linux.
So long term, I think this documentation should
be pulled out of the kernel source and put
on a public wiki that is not tied directly to Linux.
What you are proposing is a good start...
Stuart
^ permalink raw reply
* RE: RFC: replace device_type with new "class" property?
From: Yoder Stuart-B08248 @ 2007-10-31 15:31 UTC (permalink / raw)
To: David Gibson; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <20071030232730.GD2784@localhost.localdomain>
=20
> > I think what we should do is keep device_type, including
> > permitting new uses of it in a limited way-- only permitting
> > the use of device_type when there is an official binding
> > (like in the power.org ePAPR) defined. =20
>=20
> That's what I was thinking when we first started defining flat tree
> bindings. But the more time I've spent thinking about it, and the
> more time I've spent reviewing people's proposed bindings, the less
> useful I think it is.
>=20
> The *only* reason I'm suggesting leaving device_type values for
> IEEE1275 defined classes is so that flat trees written as flat trees
> look more similar to OF derived trees.
>=20
> > > Explicitly specifying what device class bindings / conventions the
> > > node complies with is cute, but not actually all that useful in
> > > practice. If it looks like a "duck" class device node, and it
> > > quacks^Whas the properties of a "duck" class device node,=20
> it's "duck"
> > > class compliant.
> > >=20
> > > Or to look at it another way, "class bindings" aren't=20
> really bindings,
> > > but rather a set of conventions that device bindings for specific
> > > devices in that class ought to follow.
> >=20
> > I tend to think of a 'binding' as a 'set of conventions'.
>=20
> Well, whatever. My point is that conventions are most flexible if you
> don't have to explicitly announce that you're following them - you
> just go ahead and follow as many conventions as make sense for your
> device.
Let me repeat what I think you are advocating-- we should
treat the collection of properties for 'established' device
classes like like "network", "serial", etc as a set of useful=20
conventions. That is, there are no set of _required_ properties
per se, but the device tree creator picks from the established
properties plus supplementing with "company,xyz" properties
in whatever way they think makes sense for them.
This works...but certainly is weaker with respect to
standardization. My previous argument had the assumption
that something like "mac-address" in a network node was
_required_, and thus needed a class id of some sort to tie
the standardized node to.
If we relax things so there are no required properties for
device nodes, then I agree that a device class property
has limited or no value.
However, maybe we do want to keep device_type in=20
a very limited way to define requirements for what you
call 'fundamental' types of nodes. It may be that certain
properties in a "cpu" node (like cache-size?) should be
_required_ so that an OS that consumes the device tree
can really count on certain properties being there. Or,
I guess we could use "compatible" for that...?
Stuart
^ permalink raw reply
* Re: [RFC] hotplug memory remove - walk_memory_resource for ppc64
From: Badari Pulavarty @ 2007-10-31 16:10 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: linuxppc-dev, anton, Paul Mackerras, linux-mm
In-Reply-To: <20071031142846.aef9c545.kamezawa.hiroyu@jp.fujitsu.com>
On Wed, 2007-10-31 at 14:28 +0900, KAMEZAWA Hiroyuki wrote:
> On Tue, 30 Oct 2007 11:19:11 -0800
> Badari Pulavarty <pbadari@us.ibm.com> wrote:
>
> > Hi KAME,
> >
> > As I mentioned while ago, ppc64 does not export information about
> > "system RAM" in /proc/iomem. Looking at the code and usage
> > scenerios I am not sure what its really serving. Could you
> > explain what its purpose & how the range can be invalid ?
> >
> Hm, I added walk_memory_resource() for hot-add, at first.
>
> Size of memory section is fixed and just depend on architecture, but
> any machine can have any memory-hole within continuous memory-section-size
> range of physical memory. Then we have to detect which page can be
> target of online_page() and which are leaved as Reserved.
>
> ioresource was good structure for remembering "which memory is conventional
> memory" and i386/x86_64/ia64 registered conventional memory as "System RAM",
> when I posted patch. (just say "System Ram" is not for memory hotplug.)
>
> I used walk_memory_resource() again in memory hotremove.
Agreed. On PPC64, within a memblock represented in /sysfs are pretty
small (16MB) and there can not be any holes. And you can add/remove
memory only on 16MB multiple chunks.
>
> (If I rememember correctly, walk_memory_resouce() helps x86_64 memory hot-add.
> than our ia64 box.
> In our ia64 box, we do node-hotadd. Section size is 1GiB and it has some
> "for firmware" area in newly-added node.)
>
> > At least on ppc64, all the memory ranges we get passed comes from
> > /sysfs memblock information and they are guaranteed to match
> > device-tree entries. On ppc64, each 16MB chunk has a /sysfs entry
> > and it will be part of the /proc/device-tree entry. Since we do
> > "online" or "offline" to /sysfs entries to add/remove pages -
> > these ranges are guaranteed to be valid.
> >
> ok.
>
> > Since this check is redundant for ppc64, I propose following patch.
> > Is this acceptable ? If some one really really wants, I can code
> > up this to walk lmb or /proc/device-tree and verify the range &
> > adjust the entries for overlap (I don't see how that can happen).
> >
> ok. If ppc64 guarantees "there is no memory hole in section", please try.
> I have no objection.
> I just would like to ask to add some text to explain
> "ppc64 doesn't need to care memory hole in a section."
Yes. I would like to go with this approach, rather than adding the
information to /proc/iomem (as per Paul's suggestion). If I find
cases where sections (16MB) *could* contain holes -OR- overlaps -
I can easily add code to verify against lmb/proc-device-tree information
easily without affecting arch-neutral code.
Thanks,
Badari
^ permalink raw reply
* RE: RFC: replace device_type with new "class" property?
From: Yoder Stuart-B08248 @ 2007-10-31 15:25 UTC (permalink / raw)
To: David Gibson; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <20071030232730.GD2784@localhost.localdomain>
> > 1. There are types of nodes that don't have a programming
> > inteface per se and thus no compatible.
> > "cpu", "memory", "cache" are 3 that come to mind.
>=20
> Well, yes, this is why I suggested treating these "fundamental" nodes
> as a special case in an earlier mail.
Given your statement below, I'm wondering how you think
"fundamental" nodes should be represented ideally?
=20
> The *only* reason I'm suggesting leaving device_type values for
> IEEE1275 defined classes is so that flat trees written as flat trees
> look more similar to OF derived trees.
So, ideally (without respect to 1275) how should a "cpu"
node be represented and identified as a cpu node?
Stuart
^ permalink raw reply
* Re: [RFC] hotplug memory remove - walk_memory_resource for ppc64
From: Badari Pulavarty @ 2007-10-31 16:02 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: linuxppc-dev, anton, Paul Mackerras, linux-mm
In-Reply-To: <20071031143423.586498c3.kamezawa.hiroyu@jp.fujitsu.com>
On Wed, 2007-10-31 at 14:34 +0900, KAMEZAWA Hiroyuki wrote:
> On Wed, 31 Oct 2007 14:28:46 +0900
> KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote:
>
> > ioresource was good structure for remembering "which memory is conventional
> > memory" and i386/x86_64/ia64 registered conventional memory as "System RAM",
> > when I posted patch. (just say "System Ram" is not for memory hotplug.)
> >
> If I remember correctly, System RAM is for kdump (to know which memory should
> be dumped.) Then, memory-hotadd/remove has to modify it anyway.
Yes. kdump uses it for finding memory holes on x86/x86-64 (not sure
about ia64). On PPC64, since its not represented in /proc/iomem, we
end up reading /proc/device-tree/memory* nodes to construct the
memory map.
Paul's concern is, since we didn't need it so far - why we need this
for hotplug memory remove to work ? It might break API for *unknown*
applications. Its unfortunate that, hotplug memory add updates
/proc/iomem. We can deal with it later, as a separate patch.
Thanks,
Badari
^ permalink raw reply
* Re: [PATCH 4/4] Uartlite: speed up console output
From: Peter Korsgaard @ 2007-10-31 14:45 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, paulus, David Gibson
In-Reply-To: <20071023042746.30309.15188.stgit@trillian.cg.shawcable.net>
>>>>> "Grant" == Grant Likely <grant.likely@secretlab.ca> writes:
Hi,
Grant> From: Grant Likely <grant.likely@secretlab.ca>
Grant> Change the wait_tx routine to call cpu_relax() instead of udelay() to
Grant> reduce console output latency and test for the TXFULL bit instead of
Grant> TXEMPTY. That way the FIFO doesn't need to by 100% flushed before
Grant> writing the next character.
Sorry for the slow response - I had a misunderstanding with the
phone company, and I'm now without inet :/
Looks good to me. I gave it a quick spin to check the speed
difference:
Old:
[ 0.453101] Freeing unused kernel memory: 52k init
New:
[ 0.433686] Freeing unused kernel memory: 52k init
So it shaves off ~20ms (~4%) of bootup.
It ofcause means that the console routines return before the data is
actually transmitted on the wire, but I guess you have to screw
seriously up for the UART to die before emptying it's FIFO.
Grant> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [POWERPC] Fix off-by-one error in setting decrementer on Book E
From: Sergei Shtylyov @ 2007-10-31 14:12 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <18216.19826.611308.659235@cargo.ozlabs.ibm.com>
Hello.
Paul Mackerras wrote:
> If I take out the removed lines in the rest of your patch, I get:
>>+ */
>> #if defined(CONFIG_40x)
>> mtspr(SPRN_PIT, val);
>>+#else
>>+#if !defined(CONFIG_BOOKE)
>>+ val = val ? val - 1 : 0;
>>+#endif
>>+#if defined(CONFIG_8xx_CPU6)
>> set_dec_cpu6(val);
>>+#if defined(CONFIG_PPC_ISERIES)
> I think you're missing a #else here.
You've cut off #endif's at the end. But yes, you are correct -- I've lost
it while pasting this hunk into mail. :-/
> Paul.
WBR, Sergei
^ permalink raw reply
* Re: libfdt as its own repo and submodule of dtc?
From: Jerry Van Baren @ 2007-10-31 12:50 UTC (permalink / raw)
To: Jerry Van Baren, Jon Loeliger, Kumar Gala; +Cc: linux-ppc list, u-boot-users
In-Reply-To: <20071030234011.GE2784@localhost.localdomain>
David Gibson wrote:
> On Tue, Oct 30, 2007 at 01:14:06PM -0400, Jerry Van Baren wrote:
>> Jon Loeliger wrote:
>>> So, like, the other day Kumar Gala mumbled:
>>>> Jon,
>>>>
>>>> It seems like have libfdt as a unique git repo that is a submodule of
>>>> the things that need it (dtc, u-boot, etc.) might make some sense and it
>>>> easier for the projects that need to pull it in.
>>>>
>>>> Is this something you can take a look at? (or have other ideas on).
>>> I would be fine with making libfdt a git repository separate
>>> from the DTC repository if that makes it easier to integrate
>>> it with other projects.
>
> I don't think it's a good idea to make dtc and libfdt entirely
> seperate repositories (again). Being able to use both together in
> their combined testsuite is very useful (libfdt is used to check trees
> generated by dtc, dtc is used to generate example trees for libfdt
> testing).
>
> I'm not sure how submodules/subrepositories work so I don't know if
> that makes sense.
>
>> That sounds like a good idea to me. I would really prefer pulling patches
>> out of a libfdt repo into the u-boot repo rather than trying to kerchunk
>> upgrade lumps. While we can do this with a dtc repo, it potentially makes
>> it a lot more difficult.
>
> I don't think upgrading embedded copies by diff is a good way to go.
> The upgrade method I had in mind was to pull out a whole new copy of
> libfdt, drop that into the embedding project verbatim and generate a
> new diff there in whatever their source tracking system is. I set out
> the repository to make this easy.
I looked at this some more last night and thought about it a bit and
still am conflicted...
Pros for pulling/applying diffs/patches
----
* History is preserved, including "signed-off-by" lines. This is a
*major* positive.
* Individual patches are small, allowing better publishing and
reviewing. This is a double-edged sword (see Cons).
Cons
----
* Uninteresting files may be touched by the patches, causing patch
breakage. An example of this is the original libfdt had a test
subdirectory (subsequently promoted to the same level as ./libfdt and
generalized to be a dtc+libfdt test suite). When I grabbed the original
snapshot of libfdt, I did not pick up the test suite, so any patches
that include the test suite (many older ones) will have problems.
* Tracking patches in a different repository and applying them is a lot
of WORK.
* Publishing patches for review on the u-boot list has marginal benefit.
If someone on the u-boot list has a problem with a patch, *I'm* not at
all interested in being an intermediary carrying the flames across two
mail lists between David, who isn't on the u-boot list, and Joe Uboot,
who isn't on the linuxppc-dev list. Hoo boy, would that be an untenable
situation! <http://en.wikipedia.org/wiki/Prometheus> (I prefer to have
alcohol eat my liver, not an eagle, thankyouverymuch.)
----
At this point, I'm inclined to do a "big bang" update to the (nearly)
current state, thanks to Kumar, and see how it works to apply patches to
incrementally move it forward.
Hmmm, I need to get back to the topic... the bottom line is, at this
point I don't see any major benefit of having libfdt in a separate git
repo. I don't see it as making my task significantly easier and would
just add hassle to Jon and David's life.
Best regards,
gvb
^ permalink raw reply
* Re: [PATCH 0/4] PowerPC: 440GRx Rainier board support.
From: Josh Boyer @ 2007-10-31 12:59 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <47287339.6040404@ru.mvista.com>
On Wed, 31 Oct 2007 15:21:13 +0300
Valentine Barshak <vbarshak@ru.mvista.com> wrote:
> Josh Boyer wrote:
> > On Tue, 30 Oct 2007 19:45:11 +0300
> > Valentine Barshak <vbarshak@ru.mvista.com> wrote:
> >
> >> The following patches add PowerPC 440GRx Rainier board support.
> >> The board is almost identical to Sequoia, but doesn't have USB
> >> and FPU is not supported.
> >
> > So why do we need anything other than the DTS and the defconfig? I
> > would think the sequoia wrapper and platform files would suffice
> > completely for this.
>
> Yes, they would, but how to handle the board name in this case?
> I mean the resulting image would be cuImage.sequoia for rainier and the
> DTS board name has to be sequoia for rainier too.
> I don't now, may be it's not a big deal to call rainier a sequoia though.
> What do you think?
Let me think about this for a bit. Theoretically, there should be a
way to have a common code base between these two boards and have the
images use the right names.
josh
^ permalink raw reply
* Re: [PATCH 2/4] PowerPC: 440GRx Rainier DTS.
From: Valentine Barshak @ 2007-10-31 12:26 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev
In-Reply-To: <20071031015651.GB19318@lixom.net>
Olof Johansson wrote:
> On Wed, Oct 31, 2007 at 10:08:05AM +1100, David Gibson wrote:
>> On Tue, Oct 30, 2007 at 07:56:50PM +0300, Valentine Barshak wrote:
>>> PowerPC 440GRx Rainier DTS.
>> [snip]
>>> + SDRAM0: sdram {
>>> + device_type = "memory-controller";
>> How many times do we need to say it...
>>
>> Don't make up random device_type values. This does not belong here.
>
> Maybe there should be something like checkpatch.pl that warns about
> these kinds of things so people can check for it without getting flamed
> first. :-)
>
> Lots of people base their dts'es on other ones, so until the kernel has
> bene clean a while, this will happen all the time. I'm saying "a while"
> because people tend to base them on what's fresh when they do the work,
> but it might take a few months between then and when they post, etc.
Yep, It's been copy-pasted from sequoia.dts.
Sorry for that, I'll rmove both.
Thanks,
Valentine.
>
>
> -Olof
^ permalink raw reply
* Re: [PATCH 3/4] PowerPC: 440GRx Rainier board support.
From: Valentine Barshak @ 2007-10-31 12:23 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20071031141149.a1c85909.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> On Tue, 30 Oct 2007 19:57:39 +0300 Valentine Barshak <vbarshak@ru.mvista.com> wrote:
>> +++ linux-2.6/arch/powerpc/platforms/44x/rainier.c 2007-10-30 18:00:15.000000000 +0300
>> +#include <linux/init.h>
>> +#include <asm/machdep.h>
>> +#include <asm/prom.h>
>> +#include <asm/udbg.h>
>> +#include <asm/time.h>
>> +#include <asm/uic.h>
>> +#include <asm/of_platform.h>
>
> You want <linux/of_platform.h>
>
Oops, apparently this got here from the old sequoia.c
Will correct both.
Thanks,
Valentine.
^ permalink raw reply
* Re: [PATCH 0/4] PowerPC: 440GRx Rainier board support.
From: Valentine Barshak @ 2007-10-31 12:21 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071030151608.28a2d706@weaponx.rchland.ibm.com>
Josh Boyer wrote:
> On Tue, 30 Oct 2007 19:45:11 +0300
> Valentine Barshak <vbarshak@ru.mvista.com> wrote:
>
>> The following patches add PowerPC 440GRx Rainier board support.
>> The board is almost identical to Sequoia, but doesn't have USB
>> and FPU is not supported.
>
> So why do we need anything other than the DTS and the defconfig? I
> would think the sequoia wrapper and platform files would suffice
> completely for this.
Yes, they would, but how to handle the board name in this case?
I mean the resulting image would be cuImage.sequoia for rainier and the
DTS board name has to be sequoia for rainier too.
I don't now, may be it's not a big deal to call rainier a sequoia though.
What do you think?
Thanks,
Valentine.
>
> josh
^ permalink raw reply
* [POWERPC] Fix off-by-one error in setting decrementer on Book E/4xx (v2)
From: Paul Mackerras @ 2007-10-31 11:25 UTC (permalink / raw)
To: linuxppc-dev
The decrementer in Book E and 4xx processors interrupts on the
transition from 1 to 0, rather than on the 0 to -1 transition as on
64-bit server and 32-bit "classic" (6xx/7xx/7xxx) processors. At the
moment we subtract 1 from the count of how many decrementer ticks are
required before the next interrupt before putting it into the
decrementer, which is correct for server/classic processors, but could
possibly cause the interrupt to happen too early on Book E and 4xx if
the timebase/decrementer frequency is low.
This fixes the problem by making set_dec subtract 1 from the count for
server and classic processors, instead of having the callers subtract
1. Since set_dec already had a bunch of ifdefs to handle different
processor types, there is no net increase in ugliness. :)
Note that calling set_dec(0) may not generate an interrupt on some
processors. To make sure that decrementer_set_next_event always calls
set_dec with an interval of at least 1 tick, we set min_delta_ns of
the decrementer_clockevent to correspond to 2 ticks (2 rather than 1
to compensate for truncations in the conversions between ticks and
ns).
This also removes a redundant call to set the decrementer to
0x7fffffff - it was already set to that earlier in timer_interrupt.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
Hopefully this version is correct now. :)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 9eb3284..99ebcd3 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -586,7 +586,7 @@ void timer_interrupt(struct pt_regs * regs)
/* not time for this event yet */
now = per_cpu(decrementer_next_tb, cpu) - now;
if (now <= DECREMENTER_MAX)
- set_dec((unsigned int)now - 1);
+ set_dec((int)now);
return;
}
old_regs = set_irq_regs(regs);
@@ -611,8 +611,6 @@ void timer_interrupt(struct pt_regs * regs)
if (evt->event_handler)
evt->event_handler(evt);
- else
- evt->set_next_event(DECREMENTER_MAX, evt);
#ifdef CONFIG_PPC_ISERIES
if (firmware_has_feature(FW_FEATURE_ISERIES) && hvlpevent_is_pending())
@@ -836,9 +834,6 @@ static int decrementer_set_next_event(unsigned long evt,
struct clock_event_device *dev)
{
__get_cpu_var(decrementer_next_tb) = get_tb_or_rtc() + evt;
- /* The decrementer interrupts on the 0 -> -1 transition */
- if (evt)
- --evt;
set_dec(evt);
return 0;
}
@@ -871,7 +866,8 @@ void init_decrementer_clockevent(void)
decrementer_clockevent.shift);
decrementer_clockevent.max_delta_ns =
clockevent_delta2ns(DECREMENTER_MAX, &decrementer_clockevent);
- decrementer_clockevent.min_delta_ns = 1000;
+ decrementer_clockevent.min_delta_ns =
+ clockevent_delta2ns(2, &decrementer_clockevent);
register_decrementer_clockevent(cpu);
}
diff --git a/include/asm-powerpc/time.h b/include/asm-powerpc/time.h
index f058955..780f826 100644
--- a/include/asm-powerpc/time.h
+++ b/include/asm-powerpc/time.h
@@ -176,25 +176,31 @@ static inline unsigned int get_dec(void)
#endif
}
+/*
+ * Note: Book E and 4xx processors differ from other PowerPC processors
+ * in when the decrementer generates its interrupt: on the 1 to 0
+ * transition for Book E/4xx, but on the 0 to -1 transition for others.
+ */
static inline void set_dec(int val)
{
#if defined(CONFIG_40x)
mtspr(SPRN_PIT, val);
#elif defined(CONFIG_8xx_CPU6)
- set_dec_cpu6(val);
+ set_dec_cpu6(val - 1);
#else
+#ifndef CONFIG_BOOKE
+ --val;
+#endif
#ifdef CONFIG_PPC_ISERIES
- int cur_dec;
-
if (firmware_has_feature(FW_FEATURE_ISERIES) &&
get_lppaca()->shared_proc) {
get_lppaca()->virtual_decr = val;
- cur_dec = get_dec();
- if (cur_dec > val)
+ if (get_dec() > val)
HvCall_setVirtualDecr();
- } else
+ return;
+ }
#endif
- mtspr(SPRN_DEC, val);
+ mtspr(SPRN_DEC, val);
#endif /* not 40x or 8xx_CPU6 */
}
^ permalink raw reply related
* Re: [POWERPC] Fix off-by-one error in setting decrementer on Book E
From: Paul Mackerras @ 2007-10-31 9:40 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: linuxppc-dev
In-Reply-To: <47260FE5.5080107@ru.mvista.com>
Sergei Shtylyov writes:
> + /*
> + * The "classic" decrementer interrupts at 0 to -1 transition, while
> + * 40x and book E decrementers interrupt at 1 to 0 transition.
Funky spacing . : )
If I take out the removed lines in the rest of your patch, I get:
> + */
> #if defined(CONFIG_40x)
> mtspr(SPRN_PIT, val);
> +#else
> +#if !defined(CONFIG_BOOKE)
> + val = val ? val - 1 : 0;
> +#endif
> +#if defined(CONFIG_8xx_CPU6)
> set_dec_cpu6(val);
> +#if defined(CONFIG_PPC_ISERIES)
I think you're missing a #else here.
Paul.
^ 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