* RE: [PATCH v3] powerpc: Force page alignment for initrd reserved memory
From: Dave Carroll @ 2011-05-23 1:29 UTC (permalink / raw)
To: 'Milton Miller'; +Cc: LPPC, Paul Mackerras, LKML
In-Reply-To: <initrd-reserve-reply2@mdm.bga.com>
>On Sun, 22 May 2011 about 15:17, Milton Miller wrote:
>>On Sat, 21 May 2011 about 11:05:27 -0600, Dave Carroll wrote:>
>> When using 64K pages with a separate cpio rootfs, U-Boot will align
>> the rootfs on a 4K page boundary. When the memory is reserved, and
>> subsequent early memblock_alloc is called, it will allocate memory
>> between the 64K page alignment and reserved memory. When the reserved
>> memory is subsequently freed, it is done so by pages, causing the
>> early memblock_alloc requests to be re-used, which in my case, caused
>> the device-tree to be clobbered.
>>
>> This patch forces the reserved memory for initrd to be kernel page
>> aligned, and adds the same range extension when freeing initrd.
>
>Getting better, but
>
>>
>>
>> Signed-off-by: Dave Carroll <dcarroll@astekcorp.com>
>> ---
>> arch/powerpc/kernel/prom.c | 4 +++-
>> arch/powerpc/mm/init_32.c | 3 +++
>> arch/powerpc/mm/init_64.c | 3 +++
>> 3 files changed, 9 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
>> index 48aeb55..397d4a0 100644
>> --- a/arch/powerpc/kernel/prom.c
>> +++ b/arch/powerpc/kernel/prom.c
>> @@ -555,7 +555,9 @@ static void __init early_reserve_mem(void)
>> #ifdef CONFIG_BLK_DEV_INITRD
>> /* then reserve the initrd, if any */
>> if (initrd_start && (initrd_end > initrd_start))
>
>Here you test the unaligned values
>
>> void free_initrd_mem(unsigned long start, unsigned long end)
>> {
>> + start =3D _ALIGN_DOWN(start, PAGE_SIZE);
>> + end =3D _ALIGN_UP(end, PAGE_SIZE);
>> +
>> if (start < end)
>> printk ("Freeing initrd memory: %ldk freed\n", (end - st=
art) >> 10);
>
>But here you test the aligned values. And they are aligned with
>opposite bias. Which means that if start =3D=3D end (or is less than,
>but within the same page), a page that wasn't reserved (same
>32 and 64 bit) gets freed.
>
Agreed ... I'll have the but shortly ...
>I thought "what happens if we are within a page of end, could we
>free the last page of bss?", but then I checked vmlinux.lds and we
>align end to page size. I thought other allocations should be safe,
>but then remembered:
>
>The flattened device tree (of which we continue to use the string
>table after boot) could be a problem.
>
I had previouly looked at free_initrd_mem, and thought the same conditions
should be used to handle the memory release, but as for the explicit alignm=
ent
of the release areas, that seemed to be handled by the fact that all of the
releases are specifically page aligned. The remainder of the free_initrd_me=
m
routine:
for (; start < end; start +=3D PAGE_SIZE) {
ClearPageReserved(virt_to_page(start));
init_page_count(virt_to_page(start));
free_page(start);
totalram_pages++;
}
implicitly aligns down start to a page boundary, and also would implicitly =
align
up the end address. While I would be a proponent of something like;
if (start && (start < end)) do { remainder of free_initrd_mem }
I'm not sure of the goal in explicitly attempting to align the addresses in=
the
routine as you proposed.
As for the FDT, if the FDT is packed contiguous with initrd, and the alignm=
ent is on
4K page boundaries, it would have been released before this patch. In my ca=
se (U-Boot),
they are not near each other.
Thanks,
-Dave
>
>milton
^ permalink raw reply
* Re: [PATCH v3] powerpc: Force page alignment for initrd reserved memory, Re: [PATCH v3] powerpc: Force page alignment for initrd reserved memory
From: 'Milton Miller' @ 2011-05-22 21:17 UTC (permalink / raw)
To: Dave Carroll; +Cc: LPPC, Paul Mackerras, LKML
In-Reply-To: <522F24EF533FC546962ECFA2054FF777373072AB73@MAILSERVER2.cos.astekcorp.com>
On Sat, 21 May 2011 about 11:05:27 -0600, Dave Carroll wrote:
>
> When using 64K pages with a separate cpio rootfs, U-Boot will align
> the rootfs on a 4K page boundary. When the memory is reserved, and
> subsequent early memblock_alloc is called, it will allocate memory
> between the 64K page alignment and reserved memory. When the reserved
> memory is subsequently freed, it is done so by pages, causing the
> early memblock_alloc requests to be re-used, which in my case, caused
> the device-tree to be clobbered.
>
> This patch forces the reserved memory for initrd to be kernel page
> aligned, and adds the same range extension when freeing initrd.
Getting better, but
>
>
> Signed-off-by: Dave Carroll <dcarroll@astekcorp.com>
> ---
> arch/powerpc/kernel/prom.c | 4 +++-
> arch/powerpc/mm/init_32.c | 3 +++
> arch/powerpc/mm/init_64.c | 3 +++
> 3 files changed, 9 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> index 48aeb55..397d4a0 100644
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -555,7 +555,9 @@ static void __init early_reserve_mem(void)
> #ifdef CONFIG_BLK_DEV_INITRD
> /* then reserve the initrd, if any */
> if (initrd_start && (initrd_end > initrd_start))
Here you test the unaligned values
> void free_initrd_mem(unsigned long start, unsigned long end)
> {
> + start = _ALIGN_DOWN(start, PAGE_SIZE);
> + end = _ALIGN_UP(end, PAGE_SIZE);
> +
> if (start < end)
> printk ("Freeing initrd memory: %ldk freed\n", (end - start) >> 10);
But here you test the aligned values. And they are aligned with
opposite bias. Which means that if start == end (or is less than,
but within the same page), a page that wasn't reserved (same
32 and 64 bit) gets freed.
I thought "what happens if we are within a page of end, could we
free the last page of bss?", but then I checked vmlinux.lds and we
align end to page size. I thought other allocations should be safe,
but then remembered:
The flattened device tree (of which we continue to use the string
table after boot) could be a problem.
milton
^ permalink raw reply
* [PATCH V2 2/2] cpc925_edac: support single-processor configurations
From: Dmitry Eremin-Solenikov @ 2011-05-22 10:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Harry Ciao, Paul Mackerras, Doug Thompson
In-Reply-To: <1306059295-25806-1-git-send-email-dbaryshkov@gmail.com>
If second CPU is not enabled, CPC925 EDAC driver will spill out warnings
about errors on second Processor Interface. Support masking that out,
by detecting at runtime which CPUs are present in device tree.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: Harry Ciao <qingtao.cao@windriver.com>
Cc: Doug Thompson <dougthompson@xmission.com>
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
drivers/edac/cpc925_edac.c | 52 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/drivers/edac/cpc925_edac.c b/drivers/edac/cpc925_edac.c
index 837ad8f..0b466af 100644
--- a/drivers/edac/cpc925_edac.c
+++ b/drivers/edac/cpc925_edac.c
@@ -90,6 +90,7 @@ enum apimask_bits {
ECC_MASK_ENABLE = (APIMASK_ECC_UE_H | APIMASK_ECC_CE_H |
APIMASK_ECC_UE_L | APIMASK_ECC_CE_L),
};
+#define APIMASK_ADI(n) CPC925_BIT(((n)+1))
/************************************************************
* Processor Interface Exception Register (APIEXCP)
@@ -581,16 +582,64 @@ static void cpc925_mc_check(struct mem_ctl_info *mci)
}
/******************** CPU err device********************************/
+static u32 cpc925_cpu_getmask(void)
+{
+ struct device_node *cpus;
+ struct device_node *cpunode;
+ static u32 mask = 0;
+
+ if (mask != 0)
+ return mask;
+
+ mask = APIMASK_ADI0 | APIMASK_ADI1;
+
+ cpus = of_find_node_by_path("/cpus");
+ if (cpus == NULL) {
+ cpc925_printk(KERN_DEBUG, "No /cpus node !\n");
+ return 0;
+ }
+
+ /* Get first CPU node */
+ for (cpunode = NULL;
+ (cpunode = of_get_next_child(cpus, cpunode)) != NULL;) {
+ const u32 *reg = of_get_property(cpunode, "reg", NULL);
+
+ if (!strcmp(cpunode->type, "cpu") && reg != NULL)
+ mask &= ~APIMASK_ADI(*reg);
+ }
+
+ if (mask != APIMASK_ADI0 | APIMASK_ADI1) {
+ /* We assume that each CPU sits on it's own PI and that
+ * for present CPUs the reg property equals to the PI
+ * interface id */
+ cpc925_printk(KERN_WARNING,
+ "Assuming PI id is equal to CPU MPIC id!\n");
+ }
+
+ of_node_put(cpunode);
+ of_node_put(cpus);
+
+ return mask;
+}
+
/* Enable CPU Errors detection */
static void cpc925_cpu_init(struct cpc925_dev_info *dev_info)
{
u32 apimask;
+ u32 cpumask;
apimask = __raw_readl(dev_info->vbase + REG_APIMASK_OFFSET);
if ((apimask & CPU_MASK_ENABLE) == 0) {
apimask |= CPU_MASK_ENABLE;
__raw_writel(apimask, dev_info->vbase + REG_APIMASK_OFFSET);
}
+
+ cpumask = cpc925_cpu_getmask();
+ if (apimask & cpumask) {
+ cpc925_printk(KERN_WARNING, "CPU(s) not present, "
+ "but enabled in APIMASK, disabling\n");
+ apimask &= ~cpumask;
+ }
}
/* Disable CPU Errors detection */
@@ -622,6 +671,9 @@ static void cpc925_cpu_check(struct edac_device_ctl_info *edac_dev)
if ((apiexcp & CPU_EXCP_DETECTED) == 0)
return;
+ if ((apiexcp & ~cpc925_cpu_getmask()) == 0)
+ return;
+
apimask = __raw_readl(dev_info->vbase + REG_APIMASK_OFFSET);
cpc925_printk(KERN_INFO, "Processor Interface Fault\n"
"Processor Interface register dump:\n");
--
1.7.4.4
^ permalink raw reply related
* [PATCH V2 1/2] Maple: register CPC925 EDAC device on all boards with CPC925
From: Dmitry Eremin-Solenikov @ 2011-05-22 10:14 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Harry Ciao, Paul Mackerras
Currently Maple setup code creates cpc925_edac device only on
Motorola ATCA-6101 blade. Make setup code check bridge revision
and enable EDAC on all U3H bridges.
Verified on Momentum MapleD (ppc970fx kit) board.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
arch/powerpc/platforms/maple/setup.c | 41 +++++++++++++++------------------
1 files changed, 19 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/platforms/maple/setup.c b/arch/powerpc/platforms/maple/setup.c
index fe34c3d..2f15aca 100644
--- a/arch/powerpc/platforms/maple/setup.c
+++ b/arch/powerpc/platforms/maple/setup.c
@@ -338,35 +338,16 @@ define_machine(maple) {
#ifdef CONFIG_EDAC
/*
* Register a platform device for CPC925 memory controller on
- * Motorola ATCA-6101 blade.
+ * all boards with U3H (CPC925) bridge.
*/
-#define MAPLE_CPC925_MODEL "Motorola,ATCA-6101"
static int __init maple_cpc925_edac_setup(void)
{
struct platform_device *pdev;
struct device_node *np = NULL;
struct resource r;
- const unsigned char *model;
int ret;
-
- np = of_find_node_by_path("/");
- if (!np) {
- printk(KERN_ERR "%s: Unable to get root node\n", __func__);
- return -ENODEV;
- }
-
- model = (const unsigned char *)of_get_property(np, "model", NULL);
- if (!model) {
- printk(KERN_ERR "%s: Unabel to get model info\n", __func__);
- of_node_put(np);
- return -ENODEV;
- }
-
- ret = strcmp(model, MAPLE_CPC925_MODEL);
- of_node_put(np);
-
- if (ret != 0)
- return 0;
+ volatile void __iomem *mem;
+ u32 rev;
np = of_find_node_by_type(NULL, "memory-controller");
if (!np) {
@@ -384,6 +365,22 @@ static int __init maple_cpc925_edac_setup(void)
return -ENODEV;
}
+ mem = ioremap(r.start, resource_size(&r));
+ if (!mem) {
+ printk(KERN_ERR "%s: Unable to map memory-controller memory\n",
+ __func__);
+ return -ENOMEM;
+ }
+
+ rev = __raw_readl(mem);
+ iounmap(mem);
+
+ if (rev >= 0x34 && rev <= 0x3f) { /* U3H */
+ printk(KERN_ERR "%s: Non-CPC925(U3H) bridge revision: %02x\n",
+ __func__, rev);
+ return -ENODEV;
+ }
+
pdev = platform_device_register_simple("cpc925_edac", 0, &r, 1);
if (IS_ERR(pdev))
return PTR_ERR(pdev);
--
1.7.4.4
^ permalink raw reply related
* Re: [PATCH 2/2] cpc925_edac: support single-processor configurations
From: Dmitry Eremin-Solenikov @ 2011-05-22 9:12 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Harry Ciao, Paul Mackerras, linuxppc-dev, Doug Thompson
In-Reply-To: <ed1c0926526a93858f21a1538eb84f7b@kernel.crashing.org>
On Sun, May 22, 2011 at 12:04 AM, Segher Boessenkool
<segher@kernel.crashing.org> wrote:
>>> You should be able to see which interfaces are enabled in some CPC925
>>> register,
>>> but maybe both _are_ enabled on your system (although one is not
>>> connected),
>>> which is causing the errors?
>>
>> Hmm, I dont't think this is the case: I'm using a MapleD board with two
>> CPUs
>> connected to separate PIs. However I can slect the service processor
>> to enable only one CPU via selecting correct bootscript. In this case
>> bootscript correctly enables only APIMASK_ADI0. However as cpc925_edac
>> checks the APIEXCP itself, it sees the APIEXCP_ADI1 bit set and spills
>> regular warnings about it (see below).
>
> (no below :-) )
Sorry, here it goes:
EDAC CPC925: Processor Interface Fault
Processor Interface register dump:
EDAC CPC925: APIMASK 0xdea00000
EDAC CPC925: APIEXCP 0x20000000
EDAC DEVICE0: INTERNAL ERROR: instance 0 'block' out of range (0 >=3D 0)
> I think the service processor left that processor interface enabled (the
> interface itself, not the exception stuff), so the exception thing will
> signal exceptions any time the CPC925 sends snoops to that second
> processor. =A0This also might reduce performance.
>
> Or maybe it is normal for the exception thing to signal errors on disable=
d
> interfaces.
I only have U4 manual, so I can't be sure about U3H. And for U4 manual is
also unclear about ADI1 exception.
>> If you'd prefer I can add a check for APIMASK at cpc925_cpu_init() time,
>> but I think that this will be less robust.
>
> Yeah that's less robust, for sure.
>
> Just keep what you have, but add a big fat comment that you are assuming
> the processor interface id is identical to the MPIC processor id :-)
sure
> Did you test disabling physical CPU #0 as well?
No. I still don't have _that_ level of understanding of PIBS boot scripts.
--=20
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 2/2] cpc925_edac: support single-processor configurations
From: Segher Boessenkool @ 2011-05-21 20:04 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov
Cc: Harry Ciao, Paul Mackerras, linuxppc-dev, Doug Thompson
In-Reply-To: <BANLkTimCq6zOtZ3LYKdXLsvqr5SVeMnsDg@mail.gmail.com>
>>> If second CPU is not enabled, CPC925 EDAC driver will spill out
>>> warnings
>>> about errors on second Processor Interface. Support masking that out,
>>> by detecting at runtime which CPUs are present in device tree.
>>
>> That doesn't quite work, there can be multiple CPUs per processor
>> interface.
>
> Are you sure that there can be multiple CPUs on one PI with CPC925
> (CPC945 isn't supported by this driver anyway, IIUC).
I do not know any board that actually uses this. And, hrm, you cannot
use 970MP with CPC925 if I remember correctly.
It's still better to look what processor interfaces are working
correctly
though. But given that this is essentially a dead platform, I'm okay
with
this hack, if it works ;-)
>> You should be able to see which interfaces are enabled in some CPC925
>> register,
>> but maybe both _are_ enabled on your system (although one is not
>> connected),
>> which is causing the errors?
>
> Hmm, I dont't think this is the case: I'm using a MapleD board with
> two CPUs
> connected to separate PIs. However I can slect the service processor
> to enable only one CPU via selecting correct bootscript. In this case
> bootscript correctly enables only APIMASK_ADI0. However as cpc925_edac
> checks the APIEXCP itself, it sees the APIEXCP_ADI1 bit set and spills
> regular warnings about it (see below).
(no below :-) )
I think the service processor left that processor interface enabled (the
interface itself, not the exception stuff), so the exception thing will
signal exceptions any time the CPC925 sends snoops to that second
processor. This also might reduce performance.
Or maybe it is normal for the exception thing to signal errors on
disabled
interfaces.
> If you'd prefer I can add a check for APIMASK at cpc925_cpu_init()
> time,
> but I think that this will be less robust.
Yeah that's less robust, for sure.
Just keep what you have, but add a big fat comment that you are assuming
the processor interface id is identical to the MPIC processor id :-)
Did you test disabling physical CPU #0 as well?
Segher
^ permalink raw reply
* Re: [PATCH 1/2] Maple: register CPC925 EDAC device on all boards with CPC925
From: Dmitry Eremin-Solenikov @ 2011-05-21 18:15 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Harry Ciao, Paul Mackerras, linuxppc-dev
In-Reply-To: <2825c3704d46eca735f20b01be7e33f9@kernel.crashing.org>
On 5/21/11, Segher Boessenkool <segher@kernel.crashing.org> wrote:
>> Currently Maple setup code creates cpc925_edac device only on
>> Motorola ATCA-6101 blade. Make setup code check bridge revision
>> and enable EDAC on all U3 bridges.
>
> But the EDAC code only works on U3H (CPC925), not old U3.
Ack, corrected. Thank you for the info.
>
>> + if ((rev & 0xf0) != 0x30) { /* U3 */
>> + printk(KERN_ERR "%s: Non-CPC925(U3) bridge revision: %02x\n",
>
> Should be: if (rev >= 0x34 && rev <= 0x3f)
>
>
> Segher
>
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 0/13] Hypervisor-mode KVM on POWER7
From: Alexander Graf @ 2011-05-21 18:15 UTC (permalink / raw)
To: Alexander Graf
Cc: linuxppc-dev@ozlabs.org, Paul Mackerras, Avi Kivity,
kvm@vger.kernel.org
In-Reply-To: <716BAE9B-F950-41B8-8289-DFAC4C6876CC@suse.de>
On 21.05.2011, at 19:00, Alexander Graf wrote:
>=20
> On 21.05.2011, at 18:41, Alexander Graf wrote:
>=20
>>=20
>> On 19.05.2011, at 07:22, Paul Mackerras wrote:
>>=20
>>> On Tue, May 17, 2011 at 02:42:08PM +0300, Avi Kivity wrote:
>>>> On 05/17/2011 02:38 PM, Alexander Graf wrote:
>>>>>>=20
>>>>>> What would be the path for these patches to get upstream? Would =
this
>>>>>> stuff normally go through Avi's tree? There is a bit of a
>>>>>> complication in that they are based on Ben's next branch. Would =
Avi
>>>>>> pull Ben's next branch, or would they go in via Ben's tree?
>>>>>=20
>>>>> Usually the ppc tree gets merged into Avi's tree and goes on from
>>>>> there. When we have interdependencies, we can certainly do it
>>>>> differently though. We can also shove them through Ben's tree this
>>>>> time around, as there are more dependencies on ppc code than KVM
>>>>> code.
>>>>>=20
>>>>=20
>>>> Yes, both options are fine. If it goes through kvm.git I can merge
>>>> Ben's tree (provided it is append-only) and apply the kvm-ppc
>>>> patches on top.
>>>=20
>>> OK, the easiest thing is for them to go via Ben's tree, I think, =
since
>>> they depend so much on other stuff in Ben's tree.
>>>=20
>>> Alex, could you give Ben an acked-by for patches 1-8 of the series?
>>> There haven't been any changes requested for them.
>>=20
>> With ben's tree merged into avi's tree and your patches applied on =
top, MOL breaks. I'll have to track down why exactly though.
>=20
> In fact, qemu-system-ppc64 -enable-kvm also breaks.
Only ben's tree merged into avi's tree works fine. So it's definitely =
one of your patches from 1-8 (except for 2,3 which are already in Ben's =
tree).
Alex
^ permalink raw reply
* Re: [PATCH 2/2] cpc925_edac: support single-processor configurations
From: Dmitry Eremin-Solenikov @ 2011-05-21 18:15 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Harry Ciao, Paul Mackerras, linuxppc-dev, Doug Thompson
In-Reply-To: <cca27f630fb5e3388eef060ea784f024@kernel.crashing.org>
On 5/21/11, Segher Boessenkool <segher@kernel.crashing.org> wrote:
>> If second CPU is not enabled, CPC925 EDAC driver will spill out
>> warnings
>> about errors on second Processor Interface. Support masking that out,
>> by detecting at runtime which CPUs are present in device tree.
>
> That doesn't quite work, there can be multiple CPUs per processor
> interface.
Are you sure that there can be multiple CPUs on one PI with CPC925
(CPC945 isn't supported by this driver anyway, IIUC).
> You should be able to see which interfaces are enabled in some CPC925
> register,
> but maybe both _are_ enabled on your system (although one is not
> connected),
> which is causing the errors?
Hmm, I dont't think this is the case: I'm using a MapleD board with two CPUs
connected to separate PIs. However I can slect the service processor
to enable only one CPU via selecting correct bootscript. In this case
bootscript correctly enables only APIMASK_ADI0. However as cpc925_edac
checks the APIEXCP itself, it sees the APIEXCP_ADI1 bit set and spills
regular warnings about it (see below).
If you'd prefer I can add a check for APIMASK at cpc925_cpu_init() time,
but I think that this will be less robust.
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH v3] powerpc: Force page alignment for initrd reserved memory
From: Dave Carroll @ 2011-05-21 17:05 UTC (permalink / raw)
To: 'Milton Miller', Benjamin Herrenschmidt (E-mail)
Cc: LPPC, Paul Mackerras, LKML
In-Reply-To: <initrd-reserve-alignment@mdm.bga.com>
When using 64K pages with a separate cpio rootfs, U-Boot will align
the rootfs on a 4K page boundary. When the memory is reserved, and
subsequent early memblock_alloc is called, it will allocate memory
between the 64K page alignment and reserved memory. When the reserved
memory is subsequently freed, it is done so by pages, causing the
early memblock_alloc requests to be re-used, which in my case, caused
the device-tree to be clobbered.
This patch forces the reserved memory for initrd to be kernel page
aligned, and adds the same range extension when freeing initrd.
Signed-off-by: Dave Carroll <dcarroll@astekcorp.com>
---
arch/powerpc/kernel/prom.c | 4 +++-
arch/powerpc/mm/init_32.c | 3 +++
arch/powerpc/mm/init_64.c | 3 +++
3 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 48aeb55..397d4a0 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -555,7 +555,9 @@ static void __init early_reserve_mem(void)
#ifdef CONFIG_BLK_DEV_INITRD
/* then reserve the initrd, if any */
if (initrd_start && (initrd_end > initrd_start))
- memblock_reserve(__pa(initrd_start), initrd_end - initrd_st=
art);
+ memblock_reserve(_ALIGN_DOWN(__pa(initrd_start), PAGE_SIZE)=
,
+ _ALIGN_UP(initrd_end, PAGE_SIZE) -
+ _ALIGN_DOWN(initrd_start, PAGE_SIZE));
#endif /* CONFIG_BLK_DEV_INITRD */
#ifdef CONFIG_PPC32
diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c
index d65b591..b0791cb 100644
--- a/arch/powerpc/mm/init_32.c
+++ b/arch/powerpc/mm/init_32.c
@@ -226,6 +226,9 @@ void free_initmem(void)
#ifdef CONFIG_BLK_DEV_INITRD
void free_initrd_mem(unsigned long start, unsigned long end)
{
+ start =3D _ALIGN_DOWN(start, PAGE_SIZE);
+ end =3D _ALIGN_UP(end, PAGE_SIZE);
+
if (start < end)
printk ("Freeing initrd memory: %ldk freed\n", (end - start=
) >> 10);
for (; start < end; start +=3D PAGE_SIZE) {
diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
index 6374b21..07ae936 100644
--- a/arch/powerpc/mm/init_64.c
+++ b/arch/powerpc/mm/init_64.c
@@ -102,6 +102,9 @@ void free_initmem(void)
#ifdef CONFIG_BLK_DEV_INITRD
void free_initrd_mem(unsigned long start, unsigned long end)
{
+ start =3D _ALIGN_DOWN(start, PAGE_SIZE);
+ end =3D _ALIGN_UP(end, PAGE_SIZE);
+
if (start < end)
printk ("Freeing initrd memory: %ldk freed\n", (end - start=
) >> 10);
for (; start < end; start +=3D PAGE_SIZE) {
--
1.7.4
^ permalink raw reply related
* Re: [PATCH 0/13] Hypervisor-mode KVM on POWER7
From: Alexander Graf @ 2011-05-21 17:00 UTC (permalink / raw)
To: Alexander Graf
Cc: linuxppc-dev@ozlabs.org, Paul Mackerras, Avi Kivity,
kvm@vger.kernel.org
In-Reply-To: <A46CA8F3-FADC-4D36-A068-EE79CE21C434@suse.de>
On 21.05.2011, at 18:41, Alexander Graf wrote:
>=20
> On 19.05.2011, at 07:22, Paul Mackerras wrote:
>=20
>> On Tue, May 17, 2011 at 02:42:08PM +0300, Avi Kivity wrote:
>>> On 05/17/2011 02:38 PM, Alexander Graf wrote:
>>>>>=20
>>>>> What would be the path for these patches to get upstream? Would =
this
>>>>> stuff normally go through Avi's tree? There is a bit of a
>>>>> complication in that they are based on Ben's next branch. Would =
Avi
>>>>> pull Ben's next branch, or would they go in via Ben's tree?
>>>>=20
>>>> Usually the ppc tree gets merged into Avi's tree and goes on from
>>>> there. When we have interdependencies, we can certainly do it
>>>> differently though. We can also shove them through Ben's tree this
>>>> time around, as there are more dependencies on ppc code than KVM
>>>> code.
>>>>=20
>>>=20
>>> Yes, both options are fine. If it goes through kvm.git I can merge
>>> Ben's tree (provided it is append-only) and apply the kvm-ppc
>>> patches on top.
>>=20
>> OK, the easiest thing is for them to go via Ben's tree, I think, =
since
>> they depend so much on other stuff in Ben's tree.
>>=20
>> Alex, could you give Ben an acked-by for patches 1-8 of the series?
>> There haven't been any changes requested for them.
>=20
> With ben's tree merged into avi's tree and your patches applied on =
top, MOL breaks. I'll have to track down why exactly though.
In fact, qemu-system-ppc64 -enable-kvm also breaks.
Alex
^ permalink raw reply
* Re: [PATCH 0/13] Hypervisor-mode KVM on POWER7
From: Alexander Graf @ 2011-05-21 16:41 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev@ozlabs.org, Avi Kivity, kvm@vger.kernel.org
In-Reply-To: <20110519052246.GA8165@drongo>
On 19.05.2011, at 07:22, Paul Mackerras wrote:
> On Tue, May 17, 2011 at 02:42:08PM +0300, Avi Kivity wrote:
>> On 05/17/2011 02:38 PM, Alexander Graf wrote:
>>>>=20
>>>> What would be the path for these patches to get upstream? Would =
this
>>>> stuff normally go through Avi's tree? There is a bit of a
>>>> complication in that they are based on Ben's next branch. Would =
Avi
>>>> pull Ben's next branch, or would they go in via Ben's tree?
>>>=20
>>> Usually the ppc tree gets merged into Avi's tree and goes on from
>>> there. When we have interdependencies, we can certainly do it
>>> differently though. We can also shove them through Ben's tree this
>>> time around, as there are more dependencies on ppc code than KVM
>>> code.
>>>=20
>>=20
>> Yes, both options are fine. If it goes through kvm.git I can merge
>> Ben's tree (provided it is append-only) and apply the kvm-ppc
>> patches on top.
>=20
> OK, the easiest thing is for them to go via Ben's tree, I think, since
> they depend so much on other stuff in Ben's tree.
>=20
> Alex, could you give Ben an acked-by for patches 1-8 of the series?
> There haven't been any changes requested for them.
With ben's tree merged into avi's tree and your patches applied on top, =
MOL breaks. I'll have to track down why exactly though.
Alex
^ permalink raw reply
* Re: [PATCH 2/2] cpc925_edac: support single-processor configurations
From: Segher Boessenkool @ 2011-05-21 13:45 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov
Cc: Harry Ciao, Paul Mackerras, linuxppc-dev, Doug Thompson
In-Reply-To: <1305977629-26648-1-git-send-email-dbaryshkov@gmail.com>
> If second CPU is not enabled, CPC925 EDAC driver will spill out
> warnings
> about errors on second Processor Interface. Support masking that out,
> by detecting at runtime which CPUs are present in device tree.
That doesn't quite work, there can be multiple CPUs per processor
interface.
You should be able to see which interfaces are enabled in some CPC925
register,
but maybe both _are_ enabled on your system (although one is not
connected),
which is causing the errors?
Segher
^ permalink raw reply
* Re: [PATCH 1/2] Maple: register CPC925 EDAC device on all boards with CPC925
From: Segher Boessenkool @ 2011-05-21 13:09 UTC (permalink / raw)
To: Dmitry Eremin-Solenikov; +Cc: Harry Ciao, Paul Mackerras, linuxppc-dev
In-Reply-To: <1305973871-28244-1-git-send-email-dbaryshkov@gmail.com>
> Currently Maple setup code creates cpc925_edac device only on
> Motorola ATCA-6101 blade. Make setup code check bridge revision
> and enable EDAC on all U3 bridges.
But the EDAC code only works on U3H (CPC925), not old U3.
> + if ((rev & 0xf0) != 0x30) { /* U3 */
> + printk(KERN_ERR "%s: Non-CPC925(U3) bridge revision: %02x\n",
Should be: if (rev >= 0x34 && rev <= 0x3f)
Segher
^ permalink raw reply
* [PATCH 2/2] cpc925_edac: support single-processor configurations
From: Dmitry Eremin-Solenikov @ 2011-05-21 11:33 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Harry Ciao, Paul Mackerras, Doug Thompson
In-Reply-To: <1305973871-28244-2-git-send-email-dbaryshkov@gmail.com>
If second CPU is not enabled, CPC925 EDAC driver will spill out warnings
about errors on second Processor Interface. Support masking that out,
by detecting at runtime which CPUs are present in device tree.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: Harry Ciao <qingtao.cao@windriver.com>
Cc: Doug Thompson <dougthompson@xmission.com>
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
Oops, please use this one instead, previous contained one extra debug line.
drivers/edac/cpc925_edac.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/drivers/edac/cpc925_edac.c b/drivers/edac/cpc925_edac.c
index 837ad8f..5bbe766 100644
--- a/drivers/edac/cpc925_edac.c
+++ b/drivers/edac/cpc925_edac.c
@@ -90,6 +90,7 @@ enum apimask_bits {
ECC_MASK_ENABLE = (APIMASK_ECC_UE_H | APIMASK_ECC_CE_H |
APIMASK_ECC_UE_L | APIMASK_ECC_CE_L),
};
+#define APIMASK_ADI(n) CPC925_BIT(((n)+1))
/************************************************************
* Processor Interface Exception Register (APIEXCP)
@@ -581,16 +582,56 @@ static void cpc925_mc_check(struct mem_ctl_info *mci)
}
/******************** CPU err device********************************/
+static u32 cpc925_cpu_getmask(void)
+{
+ struct device_node *cpus;
+ struct device_node *cpunode;
+ static u32 mask = 0;
+
+ if (mask != 0)
+ return mask;
+
+ mask = APIMASK_ADI0 | APIMASK_ADI1;
+
+ cpus = of_find_node_by_path("/cpus");
+ if (cpus == NULL) {
+ cpc925_printk(KERN_DEBUG, "No /cpus node !\n");
+ return 0;
+ }
+
+ /* Get first CPU node */
+ for (cpunode = NULL;
+ (cpunode = of_get_next_child(cpus, cpunode)) != NULL;) {
+ const u32 *reg = of_get_property(cpunode, "reg", NULL);
+
+ if (!strcmp(cpunode->type, "cpu") && reg != NULL)
+ mask &= ~APIMASK_ADI(*reg);
+ }
+
+ of_node_put(cpunode);
+ of_node_put(cpus);
+
+ return mask;
+}
+
/* Enable CPU Errors detection */
static void cpc925_cpu_init(struct cpc925_dev_info *dev_info)
{
u32 apimask;
+ u32 cpumask;
apimask = __raw_readl(dev_info->vbase + REG_APIMASK_OFFSET);
if ((apimask & CPU_MASK_ENABLE) == 0) {
apimask |= CPU_MASK_ENABLE;
__raw_writel(apimask, dev_info->vbase + REG_APIMASK_OFFSET);
}
+
+ cpumask = cpc925_cpu_getmask();
+ if (apimask & cpumask) {
+ cpc925_printk(KERN_WARNING, "CPU(s) not present, "
+ "but enabled in APIMASK, disabling\n");
+ apimask &= ~cpumask;
+ }
}
/* Disable CPU Errors detection */
@@ -622,6 +663,9 @@ static void cpc925_cpu_check(struct edac_device_ctl_info *edac_dev)
if ((apiexcp & CPU_EXCP_DETECTED) == 0)
return;
+ if ((apiexcp & ~cpc925_cpu_getmask()) == 0)
+ return;
+
apimask = __raw_readl(dev_info->vbase + REG_APIMASK_OFFSET);
cpc925_printk(KERN_INFO, "Processor Interface Fault\n"
"Processor Interface register dump:\n");
--
1.7.4.4
^ permalink raw reply related
* Re: [v2] powerpc: Force page alignment for initrd
From: Milton Miller @ 2011-05-21 10:36 UTC (permalink / raw)
To: Dave Carroll; +Cc: Paul Mackerras, LPPC, LKML
In-Reply-To: <522F24EF533FC546962ECFA2054FF777373072AB72@MAILSERVER2.cos.astekcorp.com>
On Fri, 20 May 2011 about 13:23:36 -0000, Dave Carroll wrote:
> When using 64K pages with a separate cpio rootfs, U-Boot will align
> the rootfs on a 4K page boundary. When the memory is reserved, and
> subsequent early memblock_alloc is called, it will allocate memory
> between the 64K page alignment and reserved memory. When the reserved
> memory is subsequently freed, it is done so by pages, causing the
> early memblock_alloc requests to be re-used, which in my case, caused
> the device-tree to be clobbered.
>
> This patch forces initrd to be kernel page aligned, to match the
> mechanism used to free reserved memory.
Actually it is only forcing the memory reserved for the initrd (its
not moving the contents nor filling the extra space).
>
> @@ -555,7 +555,8 @@ static void __init early_reserve_mem(void)
> #ifdef CONFIG_BLK_DEV_INITRD
> /* then reserve the initrd, if any */
> if (initrd_start && (initrd_end > initrd_start))
> - memblock_reserve(__pa(initrd_start), initrd_end - initrd_start);
> + memblock_reserve(_ALIGN_DOWN(__pa(initrd_start), PAGE_SIZE),
> + PAGE_ALIGN(initrd_end) - _ALIGN_DOWN(initrd_start, PAGE_SIZE));
Please align up the end, then change free_initrd_mem (32 and 64 bit)
to do the same range extension.
Thanks,
milton
^ permalink raw reply
* [PATCH 2/2] cpc925_edac: support single-processor configurations
From: Dmitry Eremin-Solenikov @ 2011-05-21 10:31 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Harry Ciao, Paul Mackerras, Doug Thompson
In-Reply-To: <1305973871-28244-1-git-send-email-dbaryshkov@gmail.com>
If second CPU is not enabled, CPC925 EDAC driver will spill out warnings
about errors on second Processor Interface. Support masking that out,
by detecting at runtime which CPUs are present in device tree.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: Harry Ciao <qingtao.cao@windriver.com>
Cc: Doug Thompson <dougthompson@xmission.com>
---
drivers/edac/cpc925_edac.c | 45 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/drivers/edac/cpc925_edac.c b/drivers/edac/cpc925_edac.c
index 837ad8f..fbb6947 100644
--- a/drivers/edac/cpc925_edac.c
+++ b/drivers/edac/cpc925_edac.c
@@ -90,6 +90,7 @@ enum apimask_bits {
ECC_MASK_ENABLE = (APIMASK_ECC_UE_H | APIMASK_ECC_CE_H |
APIMASK_ECC_UE_L | APIMASK_ECC_CE_L),
};
+#define APIMASK_ADI(n) CPC925_BIT(((n)+1))
/************************************************************
* Processor Interface Exception Register (APIEXCP)
@@ -581,16 +582,57 @@ static void cpc925_mc_check(struct mem_ctl_info *mci)
}
/******************** CPU err device********************************/
+static u32 cpc925_cpu_getmask(void)
+{
+ struct device_node *cpus;
+ struct device_node *cpunode;
+ static u32 mask = 0;
+
+ if (mask != 0)
+ return mask;
+
+ mask = APIMASK_ADI0 | APIMASK_ADI1;
+
+ cpus = of_find_node_by_path("/cpus");
+ if (cpus == NULL) {
+ cpc925_printk(KERN_DEBUG, "No /cpus node !\n");
+ return 0;
+ }
+
+ /* Get first CPU node */
+ for (cpunode = NULL;
+ (cpunode = of_get_next_child(cpus, cpunode)) != NULL;) {
+ const u32 *reg = of_get_property(cpunode, "reg", NULL);
+
+ cpc925_printk(KERN_ERR, "HERE: %s %p %d %d %d %lx\n", cpunode->type, reg, reg ? *reg : -1, !strcmp(cpunode->type, "cpu"), reg != NULL, APIMASK_ADI(*reg));
+ if (!strcmp(cpunode->type, "cpu") && reg != NULL)
+ mask &= ~APIMASK_ADI(*reg);
+ }
+
+ of_node_put(cpunode);
+ of_node_put(cpus);
+
+ return mask;
+}
+
/* Enable CPU Errors detection */
static void cpc925_cpu_init(struct cpc925_dev_info *dev_info)
{
u32 apimask;
+ u32 cpumask;
apimask = __raw_readl(dev_info->vbase + REG_APIMASK_OFFSET);
if ((apimask & CPU_MASK_ENABLE) == 0) {
apimask |= CPU_MASK_ENABLE;
__raw_writel(apimask, dev_info->vbase + REG_APIMASK_OFFSET);
}
+
+ cpumask = cpc925_cpu_getmask();
+ if (apimask & cpumask) {
+ cpc925_printk(KERN_WARNING, "CPU(s) not present, "
+ "but enabled in APIMASK, disabling\n");
+ apimask &= ~cpumask;
+ }
}
/* Disable CPU Errors detection */
@@ -622,6 +664,9 @@ static void cpc925_cpu_check(struct edac_device_ctl_info *edac_dev)
if ((apiexcp & CPU_EXCP_DETECTED) == 0)
return;
+ if ((apiexcp & ~cpc925_cpu_getmask()) == 0)
+ return;
+
apimask = __raw_readl(dev_info->vbase + REG_APIMASK_OFFSET);
cpc925_printk(KERN_INFO, "Processor Interface Fault\n"
"Processor Interface register dump:\n");
--
1.7.4.4
^ permalink raw reply related
* [PATCH 1/2] Maple: register CPC925 EDAC device on all boards with CPC925
From: Dmitry Eremin-Solenikov @ 2011-05-21 10:31 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Harry Ciao, Paul Mackerras
Currently Maple setup code creates cpc925_edac device only on
Motorola ATCA-6101 blade. Make setup code check bridge revision
and enable EDAC on all U3 bridges.
Verified on Momentum MapleD (ppc970fx kit) board.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
arch/powerpc/platforms/maple/setup.c | 41 +++++++++++++++------------------
1 files changed, 19 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/platforms/maple/setup.c b/arch/powerpc/platforms/maple/setup.c
index fe34c3d..2c48a91 100644
--- a/arch/powerpc/platforms/maple/setup.c
+++ b/arch/powerpc/platforms/maple/setup.c
@@ -338,35 +338,16 @@ define_machine(maple) {
#ifdef CONFIG_EDAC
/*
* Register a platform device for CPC925 memory controller on
- * Motorola ATCA-6101 blade.
+ * all boards with U3 (CPC925) bridge.
*/
-#define MAPLE_CPC925_MODEL "Motorola,ATCA-6101"
static int __init maple_cpc925_edac_setup(void)
{
struct platform_device *pdev;
struct device_node *np = NULL;
struct resource r;
- const unsigned char *model;
int ret;
-
- np = of_find_node_by_path("/");
- if (!np) {
- printk(KERN_ERR "%s: Unable to get root node\n", __func__);
- return -ENODEV;
- }
-
- model = (const unsigned char *)of_get_property(np, "model", NULL);
- if (!model) {
- printk(KERN_ERR "%s: Unabel to get model info\n", __func__);
- of_node_put(np);
- return -ENODEV;
- }
-
- ret = strcmp(model, MAPLE_CPC925_MODEL);
- of_node_put(np);
-
- if (ret != 0)
- return 0;
+ volatile void __iomem *mem;
+ u32 rev;
np = of_find_node_by_type(NULL, "memory-controller");
if (!np) {
@@ -384,6 +365,22 @@ static int __init maple_cpc925_edac_setup(void)
return -ENODEV;
}
+ mem = ioremap(r.start, resource_size(&r));
+ if (!mem) {
+ printk(KERN_ERR "%s: Unable to map memory-controller memory\n",
+ __func__);
+ return -ENOMEM;
+ }
+
+ rev = __raw_readl(mem);
+ iounmap(mem);
+
+ if ((rev & 0xf0) != 0x30) { /* U3 */
+ printk(KERN_ERR "%s: Non-CPC925(U3) bridge revision: %02x\n",
+ __func__, rev);
+ return -ENODEV;
+ }
+
pdev = platform_device_register_simple("cpc925_edac", 0, &r, 1);
if (IS_ERR(pdev))
return PTR_ERR(pdev);
--
1.7.4.4
^ permalink raw reply related
* [PATCH] Add cpufreq driver for Momentum Maple boards
From: Dmitry Eremin-Solenikov @ 2011-05-21 10:28 UTC (permalink / raw)
To: cpufreq; +Cc: Dave Jones, Paul Mackerras, linuxppc-dev
Add simple cpufreq driver for Maple-based boards (ppc970fx evaluation
kit and others). Driver is based on a cpufreq driver for 64-bit powermac
boxes with all pmac-dependant features removed and simple cleanup
applied.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
arch/powerpc/kernel/misc_64.S | 4 +-
arch/powerpc/platforms/Kconfig | 8 +
arch/powerpc/platforms/maple/Makefile | 1 +
arch/powerpc/platforms/maple/cpufreq.c | 317 ++++++++++++++++++++++++++++++++
4 files changed, 328 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/platforms/maple/cpufreq.c
diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S
index 206a321..c442aae 100644
--- a/arch/powerpc/kernel/misc_64.S
+++ b/arch/powerpc/kernel/misc_64.S
@@ -339,7 +339,7 @@ _GLOBAL(real_205_writeb)
#endif /* CONFIG_PPC_PASEMI */
-#ifdef CONFIG_CPU_FREQ_PMAC64
+#if defined(CONFIG_CPU_FREQ_PMAC64) || defined(CONFIG_CPU_FREQ_MAPLE)
/*
* SCOM access functions for 970 (FX only for now)
*
@@ -408,7 +408,7 @@ _GLOBAL(scom970_write)
/* restore interrupts */
mtmsrd r5,1
blr
-#endif /* CONFIG_CPU_FREQ_PMAC64 */
+#endif /* CONFIG_CPU_FREQ_PMAC64 || CONFIG_CPU_FREQ_MAPLE */
/*
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index f7b0772..4c5eb5b 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -187,6 +187,14 @@ config PPC_PASEMI_CPUFREQ
This adds the support for frequency switching on PA Semi
PWRficient processors.
+config CPU_FREQ_MAPLE
+ bool "Support for Maple 970FX Evaluation Board"
+ depends on PPC_MAPLE
+ select CPU_FREQ_TABLE
+ help
+ This adds support for frequency switching on Maple 970FX
+ Evaluation Board and compatible boards (IBM JS2x blades).
+
endmenu
config PPC601_SYNC_FIX
diff --git a/arch/powerpc/platforms/maple/Makefile b/arch/powerpc/platforms/maple/Makefile
index 1be1a99..0b3e3e3 100644
--- a/arch/powerpc/platforms/maple/Makefile
+++ b/arch/powerpc/platforms/maple/Makefile
@@ -1 +1,2 @@
obj-y += setup.o pci.o time.o
+obj-$(CONFIG_CPU_FREQ_MAPLE) += cpufreq.o
diff --git a/arch/powerpc/platforms/maple/cpufreq.c b/arch/powerpc/platforms/maple/cpufreq.c
new file mode 100644
index 0000000..854adfa
--- /dev/null
+++ b/arch/powerpc/platforms/maple/cpufreq.c
@@ -0,0 +1,317 @@
+/*
+ * Copyright (C) 2011 Dmitry Eremin-Solenikov
+ * Copyright (C) 2002 - 2005 Benjamin Herrenschmidt <benh@kernel.crashing.org>
+ * and Markus Demleitner <msdemlei@cl.uni-heidelberg.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This driver adds basic cpufreq support for SMU & 970FX based G5 Macs,
+ * that is iMac G5 and latest single CPU desktop.
+ */
+
+#undef DEBUG
+
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/errno.h>
+#include <linux/kernel.h>
+#include <linux/delay.h>
+#include <linux/sched.h>
+#include <linux/cpufreq.h>
+#include <linux/init.h>
+#include <linux/completion.h>
+#include <linux/mutex.h>
+#include <asm/prom.h>
+#include <asm/machdep.h>
+#include <asm/irq.h>
+#include <asm/sections.h>
+#include <asm/cputable.h>
+#include <asm/time.h>
+
+#define DBG(fmt...) pr_debug(fmt)
+
+/* see 970FX user manual */
+
+#define SCOM_PCR 0x0aa001 /* PCR scom addr */
+
+#define PCR_HILO_SELECT 0x80000000U /* 1 = PCR, 0 = PCRH */
+#define PCR_SPEED_FULL 0x00000000U /* 1:1 speed value */
+#define PCR_SPEED_HALF 0x00020000U /* 1:2 speed value */
+#define PCR_SPEED_QUARTER 0x00040000U /* 1:4 speed value */
+#define PCR_SPEED_MASK 0x000e0000U /* speed mask */
+#define PCR_SPEED_SHIFT 17
+#define PCR_FREQ_REQ_VALID 0x00010000U /* freq request valid */
+#define PCR_VOLT_REQ_VALID 0x00008000U /* volt request valid */
+#define PCR_TARGET_TIME_MASK 0x00006000U /* target time */
+#define PCR_STATLAT_MASK 0x00001f00U /* STATLAT value */
+#define PCR_SNOOPLAT_MASK 0x000000f0U /* SNOOPLAT value */
+#define PCR_SNOOPACC_MASK 0x0000000fU /* SNOOPACC value */
+
+#define SCOM_PSR 0x408001 /* PSR scom addr */
+/* warning: PSR is a 64 bits register */
+#define PSR_CMD_RECEIVED 0x2000000000000000U /* command received */
+#define PSR_CMD_COMPLETED 0x1000000000000000U /* command completed */
+#define PSR_CUR_SPEED_MASK 0x0300000000000000U /* current speed */
+#define PSR_CUR_SPEED_SHIFT (56)
+
+/*
+ * The G5 only supports two frequencies (Quarter speed is not supported)
+ */
+#define CPUFREQ_HIGH 0
+#define CPUFREQ_LOW 1
+
+static struct cpufreq_frequency_table g5_cpu_freqs[] = {
+ {CPUFREQ_HIGH, 0},
+ {CPUFREQ_LOW, 0},
+ {0, CPUFREQ_TABLE_END},
+};
+
+static struct freq_attr* g5_cpu_freqs_attr[] = {
+ &cpufreq_freq_attr_scaling_available_freqs,
+ NULL,
+};
+
+/* Power mode data is an array of the 32 bits PCR values to use for
+ * the various frequencies, retrieved from the device-tree
+ */
+static int g5_pmode_cur;
+
+static DEFINE_MUTEX(g5_switch_mutex);
+
+static const u32 *g5_pmode_data;
+static int g5_pmode_max;
+
+/*
+ * Fake voltage switching for platforms with missing support
+ */
+
+static void g5_dummy_switch_volt(int speed_mode)
+{
+}
+
+/*
+ * SCOM based frequency switching for 970FX rev3
+ */
+static int g5_scom_switch_freq(int speed_mode)
+{
+ unsigned long flags;
+ int to;
+
+ /* If frequency is going up, first ramp up the voltage */
+ if (speed_mode < g5_pmode_cur)
+ g5_dummy_switch_volt(speed_mode);
+
+ local_irq_save(flags);
+
+ /* Clear PCR high */
+ scom970_write(SCOM_PCR, 0);
+ /* Clear PCR low */
+ scom970_write(SCOM_PCR, PCR_HILO_SELECT | 0);
+ /* Set PCR low */
+ scom970_write(SCOM_PCR, PCR_HILO_SELECT |
+ g5_pmode_data[speed_mode]);
+
+ /* Wait for completion */
+ for (to = 0; to < 10; to++) {
+ unsigned long psr = scom970_read(SCOM_PSR);
+
+ if ((psr & PSR_CMD_RECEIVED) == 0 &&
+ (((psr >> PSR_CUR_SPEED_SHIFT) ^
+ (g5_pmode_data[speed_mode] >> PCR_SPEED_SHIFT)) & 0x3)
+ == 0)
+ break;
+ if (psr & PSR_CMD_COMPLETED)
+ break;
+ udelay(100);
+ }
+
+ local_irq_restore(flags);
+
+ /* If frequency is going down, last ramp the voltage */
+ if (speed_mode > g5_pmode_cur)
+ g5_dummy_switch_volt(speed_mode);
+
+ g5_pmode_cur = speed_mode;
+ ppc_proc_freq = g5_cpu_freqs[speed_mode].frequency * 1000ul;
+
+ return 0;
+}
+
+static int g5_scom_query_freq(void)
+{
+ unsigned long psr = scom970_read(SCOM_PSR);
+ int i;
+
+ for (i = 0; i <= g5_pmode_max; i++)
+ if ((((psr >> PSR_CUR_SPEED_SHIFT) ^
+ (g5_pmode_data[i] >> PCR_SPEED_SHIFT)) & 0x3) == 0)
+ break;
+ return i;
+}
+
+/*
+ * Common interface to the cpufreq core
+ */
+
+static int g5_cpufreq_verify(struct cpufreq_policy *policy)
+{
+ return cpufreq_frequency_table_verify(policy, g5_cpu_freqs);
+}
+
+static int g5_cpufreq_target(struct cpufreq_policy *policy,
+ unsigned int target_freq, unsigned int relation)
+{
+ unsigned int newstate = 0;
+ struct cpufreq_freqs freqs;
+ int rc;
+
+ if (cpufreq_frequency_table_target(policy, g5_cpu_freqs,
+ target_freq, relation, &newstate))
+ return -EINVAL;
+
+ if (g5_pmode_cur == newstate)
+ return 0;
+
+ mutex_lock(&g5_switch_mutex);
+
+ freqs.old = g5_cpu_freqs[g5_pmode_cur].frequency;
+ freqs.new = g5_cpu_freqs[newstate].frequency;
+ freqs.cpu = 0;
+
+ cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+ rc = g5_scom_switch_freq(newstate);
+ cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+
+ mutex_unlock(&g5_switch_mutex);
+
+ return rc;
+}
+
+static unsigned int g5_cpufreq_get_speed(unsigned int cpu)
+{
+ return g5_cpu_freqs[g5_pmode_cur].frequency;
+}
+
+static int g5_cpufreq_cpu_init(struct cpufreq_policy *policy)
+{
+ policy->cpuinfo.transition_latency = 12000;
+ policy->cur = g5_cpu_freqs[g5_scom_query_freq()].frequency;
+ /* secondary CPUs are tied to the primary one by the
+ * cpufreq core if in the secondary policy we tell it that
+ * it actually must be one policy together with all others. */
+ cpumask_copy(policy->cpus, cpu_online_mask);
+ cpufreq_frequency_table_get_attr(g5_cpu_freqs, policy->cpu);
+
+ return cpufreq_frequency_table_cpuinfo(policy,
+ g5_cpu_freqs);
+}
+
+
+static struct cpufreq_driver g5_cpufreq_driver = {
+ .name = "maple",
+ .owner = THIS_MODULE,
+ .flags = CPUFREQ_CONST_LOOPS,
+ .init = g5_cpufreq_cpu_init,
+ .verify = g5_cpufreq_verify,
+ .target = g5_cpufreq_target,
+ .get = g5_cpufreq_get_speed,
+ .attr = g5_cpu_freqs_attr,
+};
+
+static int __init g5_cpufreq_init(void)
+{
+ struct device_node *cpus;
+ struct device_node *cpunode;
+ unsigned int psize;
+ unsigned long max_freq;
+ const u32 *valp;
+ u32 pvr_hi;
+ int rc = -ENODEV;
+
+ cpus = of_find_node_by_path("/cpus");
+ if (cpus == NULL) {
+ DBG("No /cpus node !\n");
+ return -ENODEV;
+ }
+
+ /* Get first CPU node */
+ for (cpunode = NULL;
+ (cpunode = of_get_next_child(cpus, cpunode)) != NULL;) {
+ const u32 *reg = of_get_property(cpunode, "reg", NULL);
+ if (reg == NULL || (*reg) != 0)
+ continue;
+ if (!strcmp(cpunode->type, "cpu"))
+ break;
+ }
+ if (cpunode == NULL) {
+ printk(KERN_ERR "cpufreq: Can't find any CPU 0 node\n");
+ goto bail_cpus;
+ }
+
+ /* Check 970FX for now */
+ /* we actually don't care on which CPU to access PVR */
+ pvr_hi = PVR_VER(mfspr(SPRN_PVR));
+ if (pvr_hi != 0x3c && pvr_hi != 0x44) {
+ printk(KERN_ERR "cpufreq: Unsupported CPU version (%x)\n", pvr_hi);
+ goto bail_noprops;
+ }
+
+ /* Look for the powertune data in the device-tree */
+ g5_pmode_data = of_get_property(cpunode, "power-mode-data",&psize);
+ if (!g5_pmode_data) {
+ DBG("No power-mode-data !\n");
+ goto bail_noprops;
+ }
+ g5_pmode_max = psize / sizeof(u32) - 1;
+
+ /*
+ * From what I see, clock-frequency is always the maximal frequency.
+ * The current driver can not slew sysclk yet, so we really only deal
+ * with powertune steps for now. We also only implement full freq and
+ * half freq in this version. So far, I haven't yet seen a machine
+ * supporting anything else.
+ */
+ valp = of_get_property(cpunode, "clock-frequency", NULL);
+ if (!valp)
+ return -ENODEV;
+ max_freq = (*valp)/1000;
+ g5_cpu_freqs[0].frequency = max_freq;
+ g5_cpu_freqs[1].frequency = max_freq/2;
+
+ /* Force apply current frequency to make sure everything is in
+ * sync (voltage is right for example). Firmware may leave us with
+ * a strange setting ...
+ */
+ g5_dummy_switch_volt(CPUFREQ_HIGH);
+ msleep(10);
+ g5_pmode_cur = -1;
+ g5_scom_switch_freq(g5_scom_query_freq());
+
+ printk(KERN_INFO "Registering G5 CPU frequency driver\n");
+ printk(KERN_INFO "Frequency method: SCOM, Voltage method: none\n");
+ printk(KERN_INFO "Low: %d Mhz, High: %d Mhz, Cur: %d MHz\n",
+ g5_cpu_freqs[1].frequency/1000,
+ g5_cpu_freqs[0].frequency/1000,
+ g5_cpu_freqs[g5_pmode_cur].frequency/1000);
+
+ rc = cpufreq_register_driver(&g5_cpufreq_driver);
+
+ of_node_put(cpunode);
+ of_node_put(cpus);
+
+ return rc;
+
+bail_noprops:
+ of_node_put(cpunode);
+bail_cpus:
+ of_node_put(cpus);
+
+ return rc;
+}
+
+module_init(g5_cpufreq_init);
+
+
+MODULE_LICENSE("GPL");
--
1.7.4.4
^ permalink raw reply related
* Re: [stable] [PATCH] powerpc: Fix 32-bit SMP build
From: Josh Boyer @ 2011-05-21 0:38 UTC (permalink / raw)
To: Greg KH; +Cc: linuxppc-dev, stable
In-Reply-To: <20110520215835.GA14918@kroah.com>
On Fri, May 20, 2011 at 5:58 PM, Greg KH <greg@kroah.com> wrote:
> On Fri, May 20, 2011 at 04:22:25PM -0400, Josh Boyer wrote:
>> Commit 69e3cea8d5fd526 introduced start_secondary_resume to misc_32.S,
>> however it uses a 64-bit instruction which is not valid on 32-bit
>> platforms. =A0Use 'stw' instead.
>>
>> Reported-by: Richard Cochran <richardcochran@gmail.com>
>> Tested-by: Richard Cochran <richardcochran@gmail.com>
>> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
>>
>> ---
>
> <formletter>
>
> This is not the correct way to submit patches for inclusion in the
> stable kernel tree. =A0Please read Documentation/stable_kernel_rules.txt
> for how to do this properly.
>
> </formletter>
Sigh. I know that. My fault for rushing it and not thinking.
josh
^ permalink raw reply
* RE: [PATCH v2]powerpc: Force page alignment for initrd
From: Dave Carroll @ 2011-05-20 23:23 UTC (permalink / raw)
To: 'Benjamin Herrenschmidt'
Cc: Paul Mackerras (E-mail), LPPC (E-mail), LKML (E-mail)
In-Reply-To: <1305930459.7481.194.camel@pasglop>
When using 64K pages with a separate cpio rootfs, U-Boot will align the roo=
tfs
on a 4K page boundary. When the memory is reserved, and subsequent early
memblock_alloc is called, it will allocate memory between the 64K page alig=
nment
and reserved memory. When the reserved memory is subsequently freed, it is =
done
so by pages, causing the early memblock_alloc requests to be re-used, which=
in
my case, caused the device-tree to be clobbered.
This patch forces initrd to be kernel page aligned, to match the mechanism =
used
to free reserved memory.
Signed-off-by: Dave Carroll <dcarroll@astekcorp.com>
---
arch/powerpc/kernel/prom.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index 48aeb55..7e58f6b 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -555,7 +555,8 @@ static void __init early_reserve_mem(void)
#ifdef CONFIG_BLK_DEV_INITRD
/* then reserve the initrd, if any */
if (initrd_start && (initrd_end > initrd_start))
- memblock_reserve(__pa(initrd_start), initrd_end - initrd_st=
art);
+ memblock_reserve(_ALIGN_DOWN(__pa(initrd_start), PAGE_SIZE)=
,
+ PAGE_ALIGN(initrd_end) - _ALIGN_DOWN(initrd_start, =
PAGE_SIZE));
#endif /* CONFIG_BLK_DEV_INITRD */
#ifdef CONFIG_PPC32
--
1.7.4
^ permalink raw reply related
* Re: [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2011-05-20 22:21 UTC (permalink / raw)
To: Richard Cochran
Cc: linuxppc-dev list, Andrew Morton, Linus Torvalds,
Linux Kernel list
In-Reply-To: <20110520132328.GA5785@riccoc20.at.omicron.at>
On Fri, 2011-05-20 at 15:23 +0200, Richard Cochran wrote:
> On Thu, May 19, 2011 at 02:06:18PM +1000, Benjamin Herrenschmidt wrote:
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
>
> When I try to build 'next' (now at 208b3a4c), it does not compile due
> to a change from the following commit.
>
> > Benjamin Herrenschmidt (1):
> > powerpc/smp: Make start_secondary_resume available to all CPU variants
>
> I would appreciate your help in getting this fixed...
It's me being a moron. I'll send a fix to Linus.
Cheers,
Ben.
> Thanks,
> Richard
>
> PS the error looks like this:
>
> AS arch/powerpc/kernel/misc_32.o
> arch/powerpc/kernel/misc_32.S: Assembler messages:
> arch/powerpc/kernel/misc_32.S:703: Error: Unrecognized opcode: `std'
> make[2]: *** [arch/powerpc/kernel/misc_32.o] Error 1
> make[1]: *** [arch/powerpc/kernel] Error 2
>
> > ${CROSS_COMPILE}gcc -v
> Using built-in specs.
> Target: powerpc-none-linux-gnuspe
> Configured with: ../gcc-4.3.2/configure --target=powerpc-none-linux-gnuspe --host=i686-pc-linux-gnu --prefix=/opt/freescale/usr/local/gcc-4.3.74-eglibc-2.8.74-dp-2/powerpc-none-linux-gnuspe --with-sysroot=/opt/freescale/usr/local/gcc-4.3.74-eglibc-2.8.74-dp-2/powerpc-none-linux-gnuspe/powerpc-none-linux-gnuspe/libc --disable-libssp --disable-libmudflap --disable-libstdcxx-pch --enable-libgomp --enable-shared --enable-threads --enable-languages=c,c++ --with-gmp=/usr/src/redhat/BUILD/csl-tc-4.3.74/host-libs/usr --with-mpfr=/usr/src/redhat/BUILD/csl-tc-4.3.74/host-libs/usr --with-cpu=8548 --with-gnu-as --with-gnu-ld --enable-symvers=gnu --enable-__cxa_atexit --enable-cxx-flags=-mcpu=8548 --disable-multilib --with-long-double-128 --disable-nls --enable-e500_double
> Thread model: posix
> gcc version 4.3.2 (GCC)
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/book3e-64: reraise doorbell when masked by soft-irq-disable
From: Benjamin Herrenschmidt @ 2011-05-20 22:32 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20110520190047.GB7058@schlenkerla.am.freescale.net>
On Fri, 2011-05-20 at 14:00 -0500, Scott Wood wrote:
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> arch/powerpc/kernel/exceptions-64e.S | 22 +++++++++++++++++++++-
> 1 files changed, 21 insertions(+), 1 deletions(-)
You can probably remove the doorbell re-check when enabling interrupts
now, can't you ?
Cheers,
Ben.
> diff --git a/arch/powerpc/kernel/exceptions-64e.S b/arch/powerpc/kernel/exceptions-64e.S
> index b60f49e..87ca569 100644
> --- a/arch/powerpc/kernel/exceptions-64e.S
> +++ b/arch/powerpc/kernel/exceptions-64e.S
> @@ -123,6 +123,12 @@
> std r14,PACA_EXMC+EX_R14(r13); \
> std r15,PACA_EXMC+EX_R15(r13)
>
> +#define PROLOG_ADDITION_DOORBELL_GEN \
> + lbz r11,PACASOFTIRQEN(r13); /* are irqs soft-disabled ? */ \
> + cmpwi cr0,r11,0; /* yes -> go out of line */ \
> + beq masked_doorbell_book3e;
> +
> +
> /* Core exception code for all exceptions except TLB misses.
> * XXX: Needs to make SPRN_SPRG_GEN depend on exception type
> */
> @@ -466,7 +472,13 @@ kernel_dbg_exc:
> MASKABLE_EXCEPTION(0x260, perfmon, .performance_monitor_exception, ACK_NONE)
>
> /* Doorbell interrupt */
> - MASKABLE_EXCEPTION(0x2070, doorbell, .doorbell_exception, ACK_NONE)
> + START_EXCEPTION(doorbell)
> + NORMAL_EXCEPTION_PROLOG(0x2070, PROLOG_ADDITION_DOORBELL)
> + EXCEPTION_COMMON(0x2070, PACA_EXGEN, INTS_DISABLE_ALL)
> + CHECK_NAPPING()
> + addi r3,r1,STACK_FRAME_OVERHEAD
> + bl .doorbell_exception
> + b .ret_from_except_lite;
>
> /* Doorbell critical Interrupt */
> START_EXCEPTION(doorbell_crit);
> @@ -521,8 +533,16 @@ kernel_dbg_exc:
> * An interrupt came in while soft-disabled; clear EE in SRR1,
> * clear paca->hard_enabled and return.
> */
> +masked_doorbell_book3e:
> + mtcr r10
> + /* Resend the doorbell to fire again when ints enabled */
> + mfspr r10,SPRN_PIR
> + PPC_MSGSND(r10)
> + b masked_interrupt_book3e_common
> +
> masked_interrupt_book3e:
> mtcr r10
> +masked_interrupt_book3e_common:
> stb r11,PACAHARDIRQEN(r13)
> mfspr r10,SPRN_SRR1
> rldicl r11,r10,48,1 /* clear MSR_EE */
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/book3e-64: hv exceptions aren't MASKABLE
From: Benjamin Herrenschmidt @ 2011-05-20 22:30 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20110520190030.GA7058@schlenkerla.am.freescale.net>
On Fri, 2011-05-20 at 14:00 -0500, Scott Wood wrote:
> In general we will not have EE soft-disabled or be napping when
> these exceptions happen, but still it is not correct.
>
> The guest doorbell exceptions can only be triggered with MSR[GS]=1,
> and thus for host kernel nesting purposes are base-level exceptions.
>
> Note that ehpriv and hypercall are triggerable from normal userspace.
> I tested that the process gets properly signalled in this case.
Please split the renaming of type->level from the actual functional
patch.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH]powerpc: Force page alignment for early reserved memory
From: Benjamin Herrenschmidt @ 2011-05-20 22:27 UTC (permalink / raw)
To: Dave Carroll; +Cc: LPPC (E-mail), Paul Mackerras (E-mail), LKML (E-mail)
In-Reply-To: <522F24EF533FC546962ECFA2054FF777373072AB71@MAILSERVER2.cos.astekcorp.com>
On Fri, 2011-05-20 at 15:26 -0600, Dave Carroll wrote:
> When using 64K pages with a separate cpio rootfs, U-Boot will align the rootfs on a 4K
> page boundary. When the memory is reserved, and subsequent early memblock_alloc
> is called, it will allocate memory between the 64K page alignment and reserved
> memory. When the reserved memory is subsequently freed, it is done so by pages,
> causing the early memblock_alloc requests to be re-used, which in my case, caused
> the device-tree to be clobbered.
>
> This patch forces all early reserved memory to be kernel page aligned, to match
> the mechanism used to free reserved memory.
Hrm...
Reserved memory isn't normally freed. The rootfs is a special case here,
shouldn't we special case it and thus align that specific reserve at the
call site ?
Not a huge deal either way now that I fixed memblock_reserve() to cope
with overlaps but could be a problem if we want to backport your patch.
Cheers,
Ben.
> Signed-off-by: Dave Carroll <dcarroll@astekcorp.com>
> ---
> arch/powerpc/kernel/prom.c | 21 +++++++++++++++++----
> 1 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> index e74fa12..2744792 100644
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -534,6 +534,19 @@ void __init early_init_dt_setup_initrd_arch(unsigned long start,
> }
> #endif
>
> +static void __init reserve_mem(u64 base, u64 size)
> +{
> + u64 top = base + size;
> + if (size == 0)
> + return;
> +
> + base = _ALIGN_DOWN(base, PAGE_SIZE);
> + top = _ALIGN_UP(top, PAGE_SIZE);
> + size = top - base;
> + memblock_reserve(base, size);
> +
> +}
> +
> static void __init early_reserve_mem(void)
> {
> u64 base, size;
> @@ -547,12 +560,12 @@ static void __init early_reserve_mem(void)
> /* before we do anything, lets reserve the dt blob */
> self_base = __pa((unsigned long)initial_boot_params);
> self_size = initial_boot_params->totalsize;
> - memblock_reserve(self_base, self_size);
> + reserve_mem(self_base, self_size);
>
> #ifdef CONFIG_BLK_DEV_INITRD
> /* then reserve the initrd, if any */
> if (initrd_start && (initrd_end > initrd_start))
> - memblock_reserve(__pa(initrd_start), initrd_end - initrd_start);
> + reserve_mem(__pa(initrd_start), initrd_end - initrd_start);
> #endif /* CONFIG_BLK_DEV_INITRD */
>
> #ifdef CONFIG_PPC32
> @@ -573,7 +586,7 @@ static void __init early_reserve_mem(void)
> if (base_32 == self_base && size_32 == self_size)
> continue;
> DBG("reserving: %x -> %x\n", base_32, size_32);
> - memblock_reserve(base_32, size_32);
> + reserve_mem(base_32, size_32);
> }
> return;
> }
> @@ -584,7 +597,7 @@ static void __init early_reserve_mem(void)
> if (size == 0)
> break;
> DBG("reserving: %llx -> %llx\n", base, size);
> - memblock_reserve(base, size);
> + reserve_mem(base, size);
> }
> }
>
> --
> 1.7.4
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ 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