* [PATCH 1/2] [POWERPC] mpc5200: Fix Kconfig dependancies on MPC5200 FEC device driver
From: Grant Likely @ 2007-10-31 6:28 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
From: Grant Likely <grant.likely@secretlab.ca>
When not building an arch/powerpc kernel, the mpc5200 FEC driver depends
on some symbols which are not defined (BESTCOMM & BESTCOMM_FEC).
This patch flips around the dependancy logic so that it cannot be
selected unless BESTCOMM_FEC is selected first. Kconfig stops
complaining this way.
Also, the driver only works for arch/powerpc (not arch/ppc) anyway so
it should depend on PPC_MERGE also.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
drivers/net/Kconfig | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 867cb73..5f800a6 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -1883,9 +1883,7 @@ config FEC2
config FEC_MPC52xx
tristate "MPC52xx FEC driver"
- depends on PPC_MPC52xx
- select PPC_BESTCOMM
- select PPC_BESTCOMM_FEC
+ depends on PPC_MERGE && PPC_MPC52xx && PPC_BESTCOMM_FEC
select CRC32
select PHYLIB
---help---
^ permalink raw reply related
* [PATCH] [POWERPC] ppc405 Fix arithmatic rollover bug when memory size under 16M
From: Grant Likely @ 2007-10-31 6:41 UTC (permalink / raw)
To: mh, jwboyer, linuxppc-dev
From: Grant Likely <grant.likely@secretlab.ca>
mmu_mapin_ram() loops over total_lowmem to setup page tables. However, if
total_lowmem is less that 16M, the subtraction rolls over and results in
a number just under 4G (because total_lowmem is an unsigned value).
This patch rejigs the loop from countup to countdown to eliminate the
bug.
Special thanks to Magnus Hjorth who wrote the original patch to fix this
bug. This patch improves on his by making the loop code simpler (which
also eliminates the possibility of another rollover at the high end)
and also applies the change to arch/powerpc.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Josh, I've tested this change on arch/ppc, but not arch/powerpc. The
ppc and powerpc code are darn near identical so it should be correct,
but you might want to boot a kernel before you push it to Paulus
anyway.
Cheers,
g.
arch/powerpc/mm/40x_mmu.c | 17 ++++++++---------
arch/ppc/mm/4xx_mmu.c | 17 ++++++++---------
2 files changed, 16 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/mm/40x_mmu.c b/arch/powerpc/mm/40x_mmu.c
index e067df8..3899ea9 100644
--- a/arch/powerpc/mm/40x_mmu.c
+++ b/arch/powerpc/mm/40x_mmu.c
@@ -98,13 +98,12 @@ unsigned long __init mmu_mapin_ram(void)
v = KERNELBASE;
p = PPC_MEMSTART;
- s = 0;
+ s = total_lowmem;
- if (__map_without_ltlbs) {
- return s;
- }
+ if (__map_without_ltlbs)
+ return 0;
- while (s <= (total_lowmem - LARGE_PAGE_SIZE_16M)) {
+ while (s >= LARGE_PAGE_SIZE_16M) {
pmd_t *pmdp;
unsigned long val = p | _PMD_SIZE_16M | _PAGE_HWEXEC | _PAGE_HWWRITE;
@@ -116,10 +115,10 @@ unsigned long __init mmu_mapin_ram(void)
v += LARGE_PAGE_SIZE_16M;
p += LARGE_PAGE_SIZE_16M;
- s += LARGE_PAGE_SIZE_16M;
+ s -= LARGE_PAGE_SIZE_16M;
}
- while (s <= (total_lowmem - LARGE_PAGE_SIZE_4M)) {
+ while (s >= LARGE_PAGE_SIZE_4M) {
pmd_t *pmdp;
unsigned long val = p | _PMD_SIZE_4M | _PAGE_HWEXEC | _PAGE_HWWRITE;
@@ -128,8 +127,8 @@ unsigned long __init mmu_mapin_ram(void)
v += LARGE_PAGE_SIZE_4M;
p += LARGE_PAGE_SIZE_4M;
- s += LARGE_PAGE_SIZE_4M;
+ s -= LARGE_PAGE_SIZE_4M;
}
- return s;
+ return total_lowmem - s;
}
diff --git a/arch/ppc/mm/4xx_mmu.c b/arch/ppc/mm/4xx_mmu.c
index 838e09d..ea785db 100644
--- a/arch/ppc/mm/4xx_mmu.c
+++ b/arch/ppc/mm/4xx_mmu.c
@@ -99,13 +99,12 @@ unsigned long __init mmu_mapin_ram(void)
v = KERNELBASE;
p = PPC_MEMSTART;
- s = 0;
+ s = total_lowmem;
- if (__map_without_ltlbs) {
- return s;
- }
+ if (__map_without_ltlbs)
+ return 0;
- while (s <= (total_lowmem - LARGE_PAGE_SIZE_16M)) {
+ while (s >= LARGE_PAGE_SIZE_16M) {
pmd_t *pmdp;
unsigned long val = p | _PMD_SIZE_16M | _PAGE_HWEXEC | _PAGE_HWWRITE;
@@ -117,10 +116,10 @@ unsigned long __init mmu_mapin_ram(void)
v += LARGE_PAGE_SIZE_16M;
p += LARGE_PAGE_SIZE_16M;
- s += LARGE_PAGE_SIZE_16M;
+ s -= LARGE_PAGE_SIZE_16M;
}
- while (s <= (total_lowmem - LARGE_PAGE_SIZE_4M)) {
+ while (s >= LARGE_PAGE_SIZE_4M) {
pmd_t *pmdp;
unsigned long val = p | _PMD_SIZE_4M | _PAGE_HWEXEC | _PAGE_HWWRITE;
@@ -129,8 +128,8 @@ unsigned long __init mmu_mapin_ram(void)
v += LARGE_PAGE_SIZE_4M;
p += LARGE_PAGE_SIZE_4M;
- s += LARGE_PAGE_SIZE_4M;
+ s -= LARGE_PAGE_SIZE_4M;
}
- return s;
+ return total_lowmem - s;
}
^ permalink raw reply related
* Re: ring on PowerPC
From: Bai Shuwei @ 2007-10-31 7:09 UTC (permalink / raw)
To: Wang, Baojun; +Cc: linuxppc-embedded
In-Reply-To: <393873503.24962@eyou.net>
[-- Attachment #1: Type: text/plain, Size: 1208 bytes --]
thanks all
On 10/31/07, Wang, Baojun <wangbj@lzu.edu.cn> wrote:
>
> On Wednesday 31 October 2007 13:05:16, Bai Shuwei wrote：
> > Hi, everyone
> > As we know, the program on the X86 can run on the differnt ring(0, 1,
> 2,
> > 3) and the linux kernel run in the ring 0 and user program in the ring
> 3.
> > And now I want to know wether there is a simple mechanism on the PowerPC
> > architecture? thx all!
> >
> > best regards!
> >
> > Buroc
>
> powerpc has a machine state register(MSR), bit MSR_PR present the current
> privilege level, if msr & MSR_PR, then it's from user space, otherwise(msr
> &
> MSR_PR == 0) it's kernel space.
>
> besides, the linux implementation only use ring0 and ring3 under i386,
> ring0
> is highest(kernel space), ring3 is lowest (userspace)
>
> Wang
> --
> Wang, Baojun Lanzhou University
> Distributed & Embedded System Lab http://dslab.lzu.edu.cn
> School of Information Science and Engeneering wangbj@lzu.edu.cn
> Tianshui South Road 222. Lanzhou 730000 .P.R.China
> Tel:+86-931-8912025 Fax:+86-931-8912022
>
>
--
Add: Tianshui South Road 222, Lanzhou, P.R.China
Tel: +86-931-8912025
Zip Code: 730000
URL: oss.lzu.edu.cn
Email: baishuwei@gmail.com, buroc@126.com
[-- Attachment #2: Type: text/html, Size: 1784 bytes --]
^ permalink raw reply
* Re: [PATCH v2] using mii-bitbang on different processor ports
From: Sergej Stepanov @ 2007-10-31 7:30 UTC (permalink / raw)
To: linuxppc-dev, netdev, jgarzik
In-Reply-To: <472776AE.2060009@freescale.com>
Am Dienstag, den 30.10.2007, 13:23 -0500 schrieb Scott Wood:
> Sergej Stepanov wrote:
> > + if( !of_address_to_resource(np, 1, &res[1])) {
>=20
> The spacing is still wrong.
>=20
> > - iounmap(bitbang->dir);
> > + if ( bitbang->mdio.dir !=3D bitbang->mdc.dir)
> > + iounmap(bitbang->mdio.dir);
> > + iounmap(bitbang->mdc.dir);
>=20
> And here.
>=20
> -Scott
Oh, sorry.
--=20
Sergej I. Stepanov
E-PA
IDS GmbH
Nobelstr. 18, Zim. 2.1.05
D-76275 Ettlingen
T +49 (0) 72 43/2 18-615
F +49 (0) 72 43/2 18-400
Email: <Sergej.Stepanov@ids.de>
<http://www.ids.de>
Gesch=C3=A4ftsf=C3=BChrer: Norbert Wagner, Friedrich Abri=C3=9F=20
Sitz der Gesellschaft: Ettlingen=20
Amtsgericht Mannheim HRB 362503
^ permalink raw reply
* [PATCH v3] using mii-bitbang on different processor ports
From: Sergej Stepanov @ 2007-10-31 8:32 UTC (permalink / raw)
To: linuxppc-dev, netdev, jgarzik
The patch makes possible to have mdio and mdc pins on different physical ports
also for CONFIG_PPC_CPM_NEW_BINDING.
To setup it in the device tree:
reg = <10d40 14 10d60 14>; // mdc: 0x10d40, mdio: 0x10d60
or
reg = <10d40 14>; // mdc and mdio have the same offset 10d40
The approach was taken from older version.
Signed-off-by: Sergej Stepanov <Sergej.Stepanov@ids.de>
--
diff --git a/drivers/net/fs_enet/mii-bitbang.c b/drivers/net/fs_enet/mii-bitbang.c
index b8e4a73..83ce0c6 100644
--- a/drivers/net/fs_enet/mii-bitbang.c
+++ b/drivers/net/fs_enet/mii-bitbang.c
@@ -29,12 +29,16 @@
#include "fs_enet.h"
-struct bb_info {
- struct mdiobb_ctrl ctrl;
+struct bb_port {
__be32 __iomem *dir;
__be32 __iomem *dat;
- u32 mdio_msk;
- u32 mdc_msk;
+ u32 msk;
+};
+
+struct bb_info {
+ struct mdiobb_ctrl ctrl;
+ struct bb_port mdc;
+ struct bb_port mdio;
};
/* FIXME: If any other users of GPIO crop up, then these will have to
@@ -62,18 +66,18 @@ static inline void mdio_dir(struct mdiobb_ctrl *ctrl, int dir)
struct bb_info *bitbang = container_of(ctrl, struct bb_info, ctrl);
if (dir)
- bb_set(bitbang->dir, bitbang->mdio_msk);
+ bb_set(bitbang->mdio.dir, bitbang->mdio.msk);
else
- bb_clr(bitbang->dir, bitbang->mdio_msk);
+ bb_clr(bitbang->mdio.dir, bitbang->mdio.msk);
/* Read back to flush the write. */
- in_be32(bitbang->dir);
+ in_be32(bitbang->mdio.dir);
}
static inline int mdio_read(struct mdiobb_ctrl *ctrl)
{
struct bb_info *bitbang = container_of(ctrl, struct bb_info, ctrl);
- return bb_read(bitbang->dat, bitbang->mdio_msk);
+ return bb_read(bitbang->mdio.dat, bitbang->mdio.msk);
}
static inline void mdio(struct mdiobb_ctrl *ctrl, int what)
@@ -81,12 +85,12 @@ static inline void mdio(struct mdiobb_ctrl *ctrl, int what)
struct bb_info *bitbang = container_of(ctrl, struct bb_info, ctrl);
if (what)
- bb_set(bitbang->dat, bitbang->mdio_msk);
+ bb_set(bitbang->mdio.dat, bitbang->mdio.msk);
else
- bb_clr(bitbang->dat, bitbang->mdio_msk);
+ bb_clr(bitbang->mdio.dat, bitbang->mdio.msk);
/* Read back to flush the write. */
- in_be32(bitbang->dat);
+ in_be32(bitbang->mdio.dat);
}
static inline void mdc(struct mdiobb_ctrl *ctrl, int what)
@@ -94,12 +98,12 @@ static inline void mdc(struct mdiobb_ctrl *ctrl, int what)
struct bb_info *bitbang = container_of(ctrl, struct bb_info, ctrl);
if (what)
- bb_set(bitbang->dat, bitbang->mdc_msk);
+ bb_set(bitbang->mdc.dat, bitbang->mdc.msk);
else
- bb_clr(bitbang->dat, bitbang->mdc_msk);
+ bb_clr(bitbang->mdc.dat, bitbang->mdc.msk);
/* Read back to flush the write. */
- in_be32(bitbang->dat);
+ in_be32(bitbang->mdc.dat);
}
static struct mdiobb_ops bb_ops = {
@@ -142,15 +146,32 @@ static int __devinit fs_mii_bitbang_init(struct mii_bus *bus,
return -ENODEV;
mdc_pin = *data;
- bitbang->dir = ioremap(res.start, res.end - res.start + 1);
- if (!bitbang->dir)
+ bitbang->mdc.dir = ioremap(res.start, res.end - res.start + 1);
+ if (!bitbang->mdc.dir)
return -ENOMEM;
- bitbang->dat = bitbang->dir + 4;
- bitbang->mdio_msk = 1 << (31 - mdio_pin);
- bitbang->mdc_msk = 1 << (31 - mdc_pin);
+ bitbang->mdc.dat = bitbang->mdc.dir + 4;
+ if (!of_address_to_resource(np, 1, &res)) {
+ if (res.end - res.start < 13)
+ goto bad_resource;
+ bitbang->mdio.dir = ioremap(res.start, res.end - res.start + 1);
+ if (!bitbang->mdio.dir)
+ goto unmap_and_exit;
+ bitbang->mdio.dat = bitbang->mdio.dir + 4;
+ } else {
+ bitbang->mdio.dir = bitbang->mdc.dir;
+ bitbang->mdio.dat = bitbang->mdc.dat;
+ }
+ bitbang->mdio.msk = 1 << (31 - mdio_pin);
+ bitbang->mdc.msk = 1 << (31 - mdc_pin);
return 0;
+bad_resource:
+ iounmap(bitbang->mdc.dir);
+ return -ENODEV;
+unmap_and_exit:
+ iounmap(bitbang->mdc.dir);
+ return -ENOMEM;
}
static void __devinit add_phy(struct mii_bus *bus, struct device_node *np)
@@ -220,7 +241,9 @@ out_free_irqs:
dev_set_drvdata(&ofdev->dev, NULL);
kfree(new_bus->irq);
out_unmap_regs:
- iounmap(bitbang->dir);
+ if (bitbang->mdio.dir != bitbang->mdc.dir)
+ iounmap(bitbang->mdio.dir);
+ iounmap(bitbang->mdc.dir);
out_free_bus:
kfree(new_bus);
out_free_priv:
@@ -238,6 +261,8 @@ static int fs_enet_mdio_remove(struct of_device *ofdev)
free_mdio_bitbang(bus);
dev_set_drvdata(&ofdev->dev, NULL);
kfree(bus->irq);
- iounmap(bitbang->dir);
+ if (bitbang->mdio.dir != bitbang->mdc.dir)
+ iounmap(bitbang->mdio.dir);
+ iounmap(bitbang->mdc.dir);
kfree(bitbang);
kfree(bus);
^ 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
* [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: [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
* 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 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 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: 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: [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: [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: [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: 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: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: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: 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
* [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
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