* [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
* [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 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 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
* 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
* 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
* [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: 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
* 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: [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: 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] ehea: add kexec support
From: Christoph Raisch @ 2007-10-31 19:48 UTC (permalink / raw)
To: michael
Cc: Thomas Q Klein, ossthema, Jeff Garzik, Jan-Bernd Themann, netdev,
linux-kernel, linux-ppc, Marcus Eder, Stefan Roscher
In-Reply-To: <1193784636.32504.4.camel@concordia>
Michael Ellerman <michael@ellerman.id.au> wrote on 30.10.2007 23:50:36:
>
> On Tue, 2007-10-30 at 09:39 +0100, Christoph Raisch wrote:
> >
> > Michael Ellerman <michael@ellerman.id.au> wrote on 28.10.2007 23:32:17:
> > Hope I didn't miss anything here...
>
> Perhaps. When we kdump the kernel does not call the reboot notifiers, so
> the code Jan-Bernd just added won't get called. So the eHEA resources
> won't be freed. When the kdump kernel tries to load the eHEA driver what
> will happen?
>
Good point.
If the device driver tries to allocate resources again (in the kdump
kernel),
which have been allocated before (in the crashed kernel) the hcalls will
fail because from the hypervisor view the resources are still in use.
Currently there's no method to find out the resource handles for these
HEA resources allocated by the crashed kernel within the hypervisor...
So we have to trigger a explicit deregister in the hypervisor before the
driver
is started again.
How do you recommend we should trigger this in the kdump process?
Is placing a hook into a ppc_md.machine_kexec be an option?
Gruss / Regards
Christoph R.
^ permalink raw reply
* Re: Too many spurious interrupts on mpc82xx with linux-2.4.35.5
From: Matvejchikov Ilya @ 2007-10-31 19:49 UTC (permalink / raw)
To: Theo Gjaltema; +Cc: linuxppc-embedded
In-Reply-To: <4728C35B.7000709@chello.nl>
I'm glad to hear it! :)
2007/10/31, Theo Gjaltema <gjalt007@chello.nl>:
> Matvejchikov,
>
> I've tried this on 2.4.25 kernel from the denx eldk3.1.1 distribution
> and it works here fine as well.
> Thanks,
> Theo.
>
> Matvejchikov Ilya schreef:
> > Hi all!
> >
> > If you still have this problem, try this patch. It helps :)
> >
> > Signed-off-by : Matvejchikov Ilya <matvejchikov@gmail.com>
> > ---
> > diff -purN linux-2.4.34.5-vanilla/arch/ppc/kernel/cpm2_pic.c
> > linux-2.4.34.5/arch/ppc/kernel/cpm2_pic.c
> > --- linux-2.4.34.5-vanilla/arch/ppc/kernel/cpm2_pic.c 2007-06-06
> > 23:20:53.000000000 +0400
> > +++ linux-2.4.34.5/arch/ppc/kernel/cpm2_pic.c 2007-06-28
> > 12:17:42.000000000 +0400
> > @@ -79,6 +79,12 @@ static void cpm2_mask_and_ack(unsigned i
> > ppc_cached_irq_mask[word] &= ~(1 << (31 - bit));
> > simr[word] = ppc_cached_irq_mask[word];
> > sipnr[word] = 1 << (31 - bit);
> > +
> > + /*
> > + * Work around large numbers of spurious IRQs on PowerPC 82xx
> > + * systems.
> > + */
> > + mb();
> > }
> >
> > static void cpm2_end_irq(unsigned int irq_nr)
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
> >
>
>
^ permalink raw reply
* question on modifying pte entries
From: Chris Friesen @ 2007-10-31 19:45 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
We've got some kernel code that monitors which pages have been dirtied
by an application.
The pages are locked in memory, and the system has no swap. Initially
we mark the pages clean using ptep_clear_flush_dirty(), then when
requested by the app we scanning through the pages and check the dirty
bit using pte_dirty(). If it's dirty we store the address and then mark
it clean using the same function as above. The above is all done while
holding both mm->mmap_sem and mm->page_table_lock.
This worked fine in 2.6.10 but now in 2.6.14 it's giving us problems.
Periodically we'll get a page that we know has been dirtied, but it
doesn't get detected as such. It appears that once this occurs, that
page will never again be detected as dirty.
Does anyone have any ideas what may be happening? Were there any
changes in the page table area other than moving to 4-level mappings?
Anyone aware of any missing tlb flushes that were fixed later?
Thanks,
Chris
^ permalink raw reply
* Re: reboot of mpc8270 sometimes fails
From: Matvejchikov Ilya @ 2007-10-31 20:14 UTC (permalink / raw)
To: linuxppc-embedded, Theo Gjaltema
Hi!
I thik that m8260_restart in 2.4 kernel is broken. Try to get it from
the 2.6 kernel, or look at this.
/* The 8260 has an internal 1-second timer update register that
@@ -112,21 +123,16 @@ m8260_get_rtc_time(void)
static void
m8260_restart(char *cmd)
{
- extern void m8260_gorom(bd_t *bi, uint addr);
- uint startaddr;
-
- /* Most boot roms have a warmstart as the second instruction
- * of the reset vector. If that doesn't work for you, change this
- * or the reboot program to send a proper address.
- */
- startaddr = 0xff000104;
-
- if (cmd != NULL) {
- if (!strncmp(cmd, "startaddr=", 10))
- startaddr = simple_strtoul(&cmd[10], NULL, 0);
- }
-
- m8260_gorom((unsigned int)__pa(__res), startaddr);
+ __volatile__ unsigned char dummy;
+
+ local_irq_disable();
+ ((cpm2_map_t *) cpm2_immr)->im_clkrst.car_rmr |= 0x00000001;
+
+ /* Clear the ME,EE,IR & DR bits in MSR to cause checkstop */
+ mtmsr(mfmsr() & ~(MSR_ME | MSR_EE | MSR_IR | MSR_DR));
+ dummy = ((cpm2_map_t *) cpm2_immr)->im_clkrst.res[0];
+ printk("Restart failed\n");
+ while (1) ;
}
^ permalink raw reply
* Re: [PATCH 1/3] Add remove_memory() for ppc64
From: Badari Pulavarty @ 2007-10-31 21:45 UTC (permalink / raw)
To: Kumar Gala
Cc: linux-mm, anton, linuxppc-dev, Paul Mackerras, Andrew Morton,
KAMEZAWA Hiroyuki
In-Reply-To: <46434BBD-7656-41B1-BED0-3A3E212032B5@kernel.crashing.org>
On Thu, 2007-11-01 at 01:26 -0500, Kumar Gala wrote:
> 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?
Like I mentioned, nothing. When KAME did the hotplug memory
remove, he kept this remove_memory() arch-specific - so
each arch can provide its own, if it needs to something
special. So far, there is no need for arch-specific
remove_memory(). If other archs (x86-64 and others)
agree we can merge this into arch neutral code.
I have to provide this for ppc64 to plug into general
frame work.
Thanks,
Badari
^ permalink raw reply
* Re: [PATCH 1/3] Add remove_memory() for ppc64
From: Dave Hansen @ 2007-10-31 20:45 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 Wed, 2007-10-31 at 08:49 -0800, Badari Pulavarty wrote:
> +#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 */
Did someone go and copy the ia64 verion? Tsk. Tsk. Bad Badari. :)
Can we just make this a weak symbol in the generic mm/memory_hotplug.c?
Or, make this the generic memory_remove() function int there and have an
arch_remove_memory() hook called from there if the architectures need to
tweak it?
-- Dave
^ permalink raw reply
* Re: [PATCH 1/3] Add remove_memory() for ppc64
From: Badari Pulavarty @ 2007-10-31 22:11 UTC (permalink / raw)
To: Dave Hansen
Cc: linux-mm, anton, linuxppc-dev, Paul Mackerras, Andrew Morton,
KAMEZAWA Hiroyuki
In-Reply-To: <1193863502.6271.38.camel@localhost>
On Wed, 2007-10-31 at 13:45 -0700, Dave Hansen wrote:
> On Wed, 2007-10-31 at 08:49 -0800, Badari Pulavarty wrote:
> > +#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 */
>
> Did someone go and copy the ia64 verion? Tsk. Tsk. Bad Badari. :)
>
> Can we just make this a weak symbol in the generic mm/memory_hotplug.c?
> Or, make this the generic memory_remove() function int there and have an
> arch_remove_memory() hook called from there if the architectures need to
> tweak it?
Well, We don't need arch-specific remove_memory() for ia64 and ppc64.
x86_64, I don't know. We will know, only when some one does the
verification. I don't need arch_remove_memory() hook also at this time.
KAME and I agreed that, we will kill all this if no arch needs it (after
verifying it with x86/x86-64). No point adding all the infrastructure,
if no one needs it at the end.
Thanks,
Badari
^ permalink raw reply
* Re: [PATCH 1/3] Add remove_memory() for ppc64
From: Badari Pulavarty @ 2007-10-31 22:13 UTC (permalink / raw)
To: Dave Hansen
Cc: linux-mm, anton, linuxppc-dev, Paul Mackerras, Andrew Morton,
KAMEZAWA Hiroyuki
In-Reply-To: <1193863502.6271.38.camel@localhost>
On Wed, 2007-10-31 at 13:45 -0700, Dave Hansen wrote:
> On Wed, 2007-10-31 at 08:49 -0800, Badari Pulavarty wrote:
> > +#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 */
>
> Did someone go and copy the ia64 verion? Tsk. Tsk. Bad Badari. :)
>
> Can we just make this a weak symbol in the generic mm/memory_hotplug.c?
> Or, make this the generic memory_remove() function int there and have an
> arch_remove_memory() hook called from there if the architectures need to
> tweak it?
BTW, we do have generic remove_memory() which returns -EINVAL, if
CONFIG_HOTPLUG_MEMORY_REMOVE is not set to cover all the arch
that doesn't support it.
Thanks,
Badari
^ permalink raw reply
* Re: [PATCH 1/3] Add remove_memory() for ppc64
From: Dale Farnsworth @ 2007-10-31 21:47 UTC (permalink / raw)
To: pbadari; +Cc: linuxppc-dev
In-Reply-To: <1193867133.17412.49.camel@dyn9047017100.beaverton.ibm.com>
Badari Pulavarty wrote:
> On Thu, 2007-11-01 at 01:26 -0500, Kumar Gala wrote:
> > 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?
>
> Like I mentioned, nothing. When KAME did the hotplug memory
> remove, he kept this remove_memory() arch-specific - so
> each arch can provide its own, if it needs to something
> special. So far, there is no need for arch-specific
> remove_memory(). If other archs (x86-64 and others)
> agree we can merge this into arch neutral code.
>
> I have to provide this for ppc64 to plug into general
> frame work.
You've added it to arch/powerpc for both PPC32 and PPC64, so your
commit description is misleading.
-Dale
^ permalink raw reply
* Re: [PATCH 1/3] Add remove_memory() for ppc64
From: Dave Hansen @ 2007-10-31 21:55 UTC (permalink / raw)
To: Badari Pulavarty
Cc: linux-mm, anton, linuxppc-dev, Paul Mackerras, Andrew Morton,
KAMEZAWA Hiroyuki
In-Reply-To: <1193868715.17412.55.camel@dyn9047017100.beaverton.ibm.com>
On Wed, 2007-10-31 at 14:11 -0800, Badari Pulavarty wrote:
>
> Well, We don't need arch-specific remove_memory() for ia64 and ppc64.
> x86_64, I don't know. We will know, only when some one does the
> verification. I don't need arch_remove_memory() hook also at this
> time.
I wasn't being very clear. I say, add the arch hook only if you need
it. But, for now, just take the ia64 code and make it generic.
-- Dave
^ permalink raw reply
* Re: [PATCH] ucc_geth: add support for netpoll
From: Anton Vorontsov @ 2007-10-31 21:59 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: netdev, linux-kernel, linuxppc-dev
In-Reply-To: <20071029121744.GA20372@localhost.localdomain>
On Mon, Oct 29, 2007 at 03:17:44PM +0300, Anton Vorontsov wrote:
[...]
> > Oops. The original patch happened to hit the Junk mail box. :(
>
> That one as well? http://lkml.org/lkml/2007/10/11/128
>
> > I think
> > the patch is good to merge after the cosmetic change. I can do it in
> > next pull request to Jeff.
>
> Ok, great. Thanks.
I'm wondering if you missed that email again. Maybe your mail
client/server doing weird things with emails from @ru.mvista.com?
Thanks.
> Here it is:
>
> - - - -
> From: Anton Vorontsov <avorontsov@ru.mvista.com>
> Subject: [PATCH] ucc_geth: add support for netpoll
>
> This patch adds netpoll support for the QE UCC Gigabit Ethernet
> driver. Tested using netconsole and KGDBoE.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> drivers/net/ucc_geth.c | 20 ++++++++++++++++++++
> 1 files changed, 20 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
> index bec413b..94e78d8 100644
> --- a/drivers/net/ucc_geth.c
> +++ b/drivers/net/ucc_geth.c
> @@ -3678,6 +3678,23 @@ static irqreturn_t ucc_geth_irq_handler(int irq, void *info)
> return IRQ_HANDLED;
> }
>
> +#ifdef CONFIG_NET_POLL_CONTROLLER
> +/*
> + * Polling 'interrupt' - used by things like netconsole to send skbs
> + * without having to re-enable interrupts. It's not called while
> + * the interrupt routine is executing.
> + */
> +static void ucc_netpoll(struct net_device *dev)
> +{
> + struct ucc_geth_private *ugeth = netdev_priv(dev);
> + int irq = ugeth->ug_info->uf_info.irq;
> +
> + disable_irq(irq);
> + ucc_geth_irq_handler(irq, dev);
> + enable_irq(irq);
> +}
> +#endif /* CONFIG_NET_POLL_CONTROLLER */
> +
> /* Called when something needs to use the ethernet device */
> /* Returns 0 for success. */
> static int ucc_geth_open(struct net_device *dev)
> @@ -3963,6 +3980,9 @@ static int ucc_geth_probe(struct of_device* ofdev, const struct of_device_id *ma
> #ifdef CONFIG_UGETH_NAPI
> netif_napi_add(dev, &ugeth->napi, ucc_geth_poll, UCC_GETH_DEV_WEIGHT);
> #endif /* CONFIG_UGETH_NAPI */
> +#ifdef CONFIG_NET_POLL_CONTROLLER
> + dev->poll_controller = ucc_netpoll;
> +#endif
> dev->stop = ucc_geth_close;
> // dev->change_mtu = ucc_geth_change_mtu;
> dev->mtu = 1500;
> --
> 1.5.2.2
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* [patch 05/28] Add cmpxchg64 and cmpxchg64_local to powerpc
From: Mathieu Desnoyers @ 2007-10-31 22:37 UTC (permalink / raw)
To: akpm, linux-kernel; +Cc: Paul Mackerras, Mathieu Desnoyers, linuxppc-dev
In-Reply-To: <20071031223710.099558229@polymtl.ca>
Make sure that at least cmpxchg64_local is available on all architectures to use
for unsigned long long values.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Acked-by: Paul Mackerras <paulus@samba.org>
CC: linuxppc-dev@ozlabs.org
---
include/asm-powerpc/system.h | 18 ++++++++++++++++--
1 file changed, 16 insertions(+), 2 deletions(-)
Index: linux-2.6-lttng/include/asm-powerpc/system.h
===================================================================
--- linux-2.6-lttng.orig/include/asm-powerpc/system.h 2007-10-31 17:32:44.000000000 -0400
+++ linux-2.6-lttng/include/asm-powerpc/system.h 2007-10-31 17:56:25.000000000 -0400
@@ -461,7 +461,7 @@ __cmpxchg_local(volatile void *ptr, unsi
return old;
}
-#define cmpxchg(ptr,o,n) \
+#define cmpxchg(ptr, o, n) \
({ \
__typeof__(*(ptr)) _o_ = (o); \
__typeof__(*(ptr)) _n_ = (n); \
@@ -470,7 +470,7 @@ __cmpxchg_local(volatile void *ptr, unsi
})
-#define cmpxchg_local(ptr,o,n) \
+#define cmpxchg_local(ptr, o, n) \
({ \
__typeof__(*(ptr)) _o_ = (o); \
__typeof__(*(ptr)) _n_ = (n); \
@@ -490,6 +490,20 @@ __cmpxchg_local(volatile void *ptr, unsi
*/
#define NET_IP_ALIGN 0
#define NET_SKB_PAD L1_CACHE_BYTES
+
+#define cmpxchg64(ptr, o, n) \
+ ({ \
+ BUILD_BUG_ON(sizeof(*(ptr)) != 8); \
+ cmpxchg((ptr), (o), (n)); \
+ })
+#define cmpxchg64_local(ptr, o, n) \
+ ({ \
+ BUILD_BUG_ON(sizeof(*(ptr)) != 8); \
+ cmpxchg_local((ptr), (o), (n)); \
+ })
+#else
+#include <asm-generic/cmpxchg-local.h>
+#define cmpxchg64_local(ptr, o, n) __cmpxchg64_local_generic((ptr), (o), (n))
#endif
#define arch_align_stack(x) (x)
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply
* Re: RFC: replace device_type with new "class" property?
From: David Gibson @ 2007-10-31 22:55 UTC (permalink / raw)
To: Yoder Stuart-B08248; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA3035F2AC3@az33exm25.fsl.freescale.net>
On Wed, Oct 31, 2007 at 08:31:02AM -0700, Yoder Stuart-B08248 wrote:
>
> > > 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.
> >
> > 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.
> >
> > 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.
> >
> > > > 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,
> > it's "duck"
> > > > class compliant.
> > > >
> > > > Or to look at it another way, "class bindings" aren't
> > really bindings,
> > > > but rather a set of conventions that device bindings for specific
> > > > devices in that class ought to follow.
> > >
> > > I tend to think of a 'binding' as a 'set of conventions'.
> >
> > 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
> 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.
Not the device tree creater, the device binding creator (though for
"one-off" type devices those may be the same person).
> 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.
Not for a network device type that represented a point-to-point link..
(Well, technically most nodes should lack 'mac-address', but I think
'local-mac-address' is what you meant)
> 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.
There are required properties, but the requrements are done at the
device binding (i.e. compatible property) level. Those bindings might
in turn reference class requirements ("A foobaz-ethernet node must
have all the standard properties for a network node described in
Sx.y.z, and in addition must have foobaz,frobnication-quotient").
> However, maybe we do want to keep device_type in
> 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...?
No, I'm saying keep device_type for cpu and memory - we could do
otherwise but it would be a gratuitous divergence from OF trees. And
yes they should have their required properties, too.
--
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: libfdt as its own repo and submodule of dtc?
From: David Gibson @ 2007-10-31 22:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: linux-ppc list, Jon Loeliger, Jerry Van Baren
In-Reply-To: <F940E9CC-1F15-4EC5-94DC-A600FD702380@kernel.crashing.org>
On Thu, Nov 01, 2007 at 01:55:30AM -0500, Kumar Gala wrote:
>
> 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).
I'm not too keen on using a git feature that's more recent than the
git in most distros.
--
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
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