* [PATCH 1/2] powerpc/vmlinux.lds: Move _edata down
From: Michael Ellerman @ 2009-08-10 5:06 UTC (permalink / raw)
To: linuxppc-dev; +Cc: catalin.marinas
Currently _edata does not include several data sections, this causes
the kernel's report of memory usage at boot to not match reality, and
also prevents kmemleak from working - because it scan between _sdata
and _edata for pointers to allocated memory.
This mirrors a similar change made recently to the x86 linker script.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/vmlinux.lds.S | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index 8ef8a14..3bb0997 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -245,10 +245,6 @@ SECTIONS
}
#endif
- . = ALIGN(PAGE_SIZE);
- _edata = .;
- PROVIDE32 (edata = .);
-
/* The initial task and kernel stack */
#ifdef CONFIG_PPC32
. = ALIGN(8192);
@@ -282,6 +278,10 @@ SECTIONS
__nosave_end = .;
}
+ . = ALIGN(PAGE_SIZE);
+ _edata = .;
+ PROVIDE32 (edata = .);
+
/*
* And finally the bss
*/
--
1.6.2.1
^ permalink raw reply related
* [PATCH 2/2] kmemleak: Allow kmemleak to be built on powerpc
From: Michael Ellerman @ 2009-08-10 5:06 UTC (permalink / raw)
To: linuxppc-dev; +Cc: catalin.marinas
In-Reply-To: <ab02e115992881a734e8e90b7d3f2d8617db4bf2.1249880775.git.michael@ellerman.id.au>
Lightly tested, doesn't crash the kernel, leak reports appear
to be mostly sane.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
lib/Kconfig.debug | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 12327b2..d5ca9a5 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -338,7 +338,7 @@ config SLUB_STATS
config DEBUG_KMEMLEAK
bool "Kernel memory leak detector"
- depends on DEBUG_KERNEL && EXPERIMENTAL && (X86 || ARM) && \
+ depends on DEBUG_KERNEL && EXPERIMENTAL && (X86 || ARM || PPC) && \
!MEMORY_HOTPLUG
select DEBUG_FS if SYSFS
select STACKTRACE if STACKTRACE_SUPPORT
--
1.6.2.1
^ permalink raw reply related
* Re: [PATCH] Stop pci_set_dma_mask() from failing when RAM doesn't exceed the mask anyway
From: Benjamin Herrenschmidt @ 2009-08-10 6:46 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1249069310.20192.220.camel@macbook.infradead.org>
On Fri, 2009-07-31 at 20:41 +0100, David Woodhouse wrote:
> On an iMac G5, the b43 driver is failing to initialise because trying to
> set the dma mask to 30-bit fails. Even though there's only 512MiB of RAM
> in the machine anyway:
> https://bugzilla.redhat.com/show_bug.cgi?id=514787
>
> We should probably let it succeed if the available RAM in the system
> doesn't exceed the requested limit.
I've slightly modified the patch to use lmb_end_of_DRAM() instead
of highest_memmap_pfn because the later is an mm internal.h thing,
it looked too fishy to rely on it form arch code with a local
"extern" in the C code :-) It's not going to cause much more overhead
and it's not a hot path anyway afaik.
Below is a copy of what I've commited to my merge branch and will
ask Linus to pull in a few minutes.
>From 10ba96df690618632a8786494b2359f5ee350048 Mon Sep 17 00:00:00 2001
From: David Woodhouse <dwmw2@infradead.org>
Date: Fri, 31 Jul 2009 09:41:50 +0000
Subject: [PATCH] powerpc/dma: pci_set_dma_mask() shouldn't fail if mask fits in RAM
On an iMac G5, the b43 driver is failing to initialise because trying to
set the dma mask to 30-bit fails. Even though there's only 512MiB of RAM
in the machine anyway:
https://bugzilla.redhat.com/show_bug.cgi?id=514787
We should probably let it succeed if the available RAM in the system
doesn't exceed the requested limit.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/kernel/dma.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index 20a60d6..ccf129d 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -7,6 +7,7 @@
#include <linux/device.h>
#include <linux/dma-mapping.h>
+#include <linux/lmb.h>
#include <asm/bug.h>
#include <asm/abs_addr.h>
@@ -90,11 +91,10 @@ static void dma_direct_unmap_sg(struct device *dev, struct scatterlist *sg,
static int dma_direct_dma_supported(struct device *dev, u64 mask)
{
#ifdef CONFIG_PPC64
- /* Could be improved to check for memory though it better be
- * done via some global so platforms can set the limit in case
+ /* Could be improved so platforms can set the limit in case
* they have limited DMA windows
*/
- return mask >= DMA_BIT_MASK(32);
+ return mask >= (lmb_end_of_DRAM() - 1);
#else
return 1;
#endif
--
1.6.1.2.14.gf26b5
^ permalink raw reply related
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2009-08-10 6:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus !
This is a simple enough fix that I decided was worth having now, it
basically allow "direct" DMA (non-iommu) to work for devices that have a
< 32-bit DMA mask (such as some infamous broadcom wireless chips) when
the machine simply has not enough memory to go over the chip addressing
limit. This fixes various smallish G5 (like old iMac G5) wireless.
The following changes since commit f4b9a988685da6386d7f9a72df3098bcc3270526:
Linus Torvalds (1):
Merge branch 'for-linus' of git://git.infradead.org/ubi-2.6
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Benjamin Herrenschmidt (1):
powerpc/dma: pci_set_dma_mask() shouldn't fail if mask fits in RAM
arch/powerpc/kernel/dma.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
^ permalink raw reply
* Re: [PATCH v2 0/6] Device table matching for SPI subsystem
From: Artem Bityutskiy @ 2009-08-10 7:35 UTC (permalink / raw)
To: avorontsov
Cc: Ben Dooks, David Brownell, linux-kernel, lm-sensors, linuxppc-dev,
linux-mtd, Jean Delvare, Andrew Morton, David Woodhouse
In-Reply-To: <20090731003957.GA23982@oksana.dev.rtsoft.ru>
On Fri, 2009-07-31 at 04:39 +0400, Anton Vorontsov wrote:
> Andrew,
>
> This new patch set overwrites following patches:
>
> hwmon-lm70-convert-to-device-table-matching.patch
> hwmon-adxx-convert-to-device-table-matching.patch
> spi-merge-probe-and-probe_id-callbacks.patch
> spi-prefix-modalias-with-spi.patch
> of-remove-stmm25p40-alias.patch
> mtd-m25p80-convert-to-device-table-matching.patch
> spi-add-support-for-device-table-matching.patch
Are you going to send v3 and address David's comments?
Do you want some of these patches to go via the MTD tree or
they better go as a series via some other tree?
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
^ permalink raw reply
* Re: sequoia: The final kernel image would overwrite the device tree
From: Geert Uytterhoeven @ 2009-08-10 7:49 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Stefan Roese, Linux/PPC Development
In-Reply-To: <20090808073807.18C4B832E416@gemini.denx.de>
On Sat, 8 Aug 2009, Wolfgang Denk wrote:
> In message <1249678991.10143.1.camel@pasglop> you wrote:
> > My experience, however, with a Canyonlands board, is that uBoot has
> > a bug that makes it always allocate the device-tree below 8M and clash
> > with the kernel when it gets too big.
> >
> > I think Stefan fixed that recently, you may need to rebuild your uboot,
> > I'll let him tell you the details about the fix.
>
> Right. These are the relevant commits; they went into mainline some
> time ago:
>
> commit 27dd5f8e1062684f1ba685760409d9b2ab6691bf
> Author: Stefan Roese <sr@denx.de>
> Date: Tue Jul 28 10:56:03 2009 +0200
>
> ppc4xx: amcc: Move "kernel_addr_r" etc to higher locations (> 16MB)
>
> This patch moves the load addresses for kernel, fdt and ramdisk to higher
> addresses (>= 16MB). This enables booting of bigger kernel images (e.g.
> lockdep enabled).
Ah, thanks, that explains it.
I'll make sure my kernel images get smaller again ;-)
With kind regards,
Geert Uytterhoeven
Software Architect
Techsoft Centre
Technology and Software Centre Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
A division of Sony Europe (Belgium) N.V.
VAT BE 0413.825.160 · RPR Brussels
Fortis · BIC GEBABEBB · IBAN BE41293037680010
^ permalink raw reply
* Re: [PATCH 03/14] powerpc: use printk_once
From: Wolfram Sang @ 2009-08-10 8:00 UTC (permalink / raw)
To: Marcin Slusarz; +Cc: linuxppc-dev, Paul Mackerras, LKML
In-Reply-To: <1249847649-11631-4-git-send-email-marcin.slusarz@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2404 bytes --]
On Sun, Aug 09, 2009 at 09:53:58PM +0200, Marcin Slusarz wrote:
> Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: linuxppc-dev@ozlabs.org
> ---
> arch/powerpc/kernel/iommu.c | 6 +-----
> arch/powerpc/kernel/irq.c | 5 ++---
> arch/powerpc/sysdev/ppc4xx_pci.c | 9 ++-------
> 3 files changed, 5 insertions(+), 15 deletions(-)
>
> diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
> index fd51578..c7fa258 100644
> --- a/arch/powerpc/kernel/iommu.c
> +++ b/arch/powerpc/kernel/iommu.c
> @@ -502,7 +502,6 @@ static void iommu_table_clear(struct iommu_table *tbl)
> struct iommu_table *iommu_init_table(struct iommu_table *tbl, int nid)
> {
> unsigned long sz;
> - static int welcomed = 0;
> struct page *page;
>
> /* Set aside 1/4 of the table for large allocations. */
> @@ -523,11 +522,8 @@ struct iommu_table *iommu_init_table(struct iommu_table *tbl, int nid)
>
> iommu_table_clear(tbl);
>
> - if (!welcomed) {
> - printk(KERN_INFO "IOMMU table initialized, virtual merging %s\n",
> + printk_once(KERN_INFO "IOMMU table initialized, virtual merging %s\n",
> novmerge ? "disabled" : "enabled");
> - welcomed = 1;
> - }
>
> return tbl;
> }
> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> index f7f376e..05ebd21 100644
> --- a/arch/powerpc/kernel/irq.c
> +++ b/arch/powerpc/kernel/irq.c
> @@ -231,7 +231,6 @@ skip:
> void fixup_irqs(cpumask_t map)
> {
> unsigned int irq;
> - static int warned;
>
> for_each_irq(irq) {
> cpumask_t mask;
> @@ -246,8 +245,8 @@ void fixup_irqs(cpumask_t map)
> }
> if (irq_desc[irq].chip->set_affinity)
> irq_desc[irq].chip->set_affinity(irq, &mask);
> - else if (irq_desc[irq].action && !(warned++))
> - printk("Cannot set affinity for irq %i\n", irq);
> + else if (irq_desc[irq].action)
> + printk_once("Cannot set affinity for irq %i\n", irq);
Maybe we should add a loglevel to this printk (and the other one in fix_irqs)
while we are here?
Other than that:
Acked-by: Wolfram Sang <w.sang@pengutronix.de>
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Do not inline putprops function
From: Milton Miller @ 2009-08-10 7:37 UTC (permalink / raw)
To: M. Mohan Kumar; +Cc: kexec, Simon Horman, linuxppc-dev
In-Reply-To: <20090805164938.GA2970@in.ibm.com>
On Thu Aug 6 at about 02:49:38 EST in 2009, M. Mohan Kumar wrote:
>
> When I align the dtstruct variable to 8 bytes, I am able to invoke kdump.
>
> When the line
> static unsigned dtstruct[TREEWORDS], *dt;
> changed to
> static unsigned dtstruct[TREEWORDS] __attribute__ ((aligned (8))), *dt;
>
> kexec-tool works.
Doh. that is the correct fix.
kexec is creating a version 3 device tree, to be backwards compatible
as far as possible. (Well, that and it was written before version 3
existed). This version of the struct has 8-byte alignment for properties
whose value is 8 or more bytes. As the code directly checks the pointer
when deciding to add the alignment word, the struct memory must start on
an 8 byte boundary.
Mohan, please prepare a patch with the above text in the changelog
and send it to Simon.
thanks.
milton
^ permalink raw reply
* Re: [PATCH 0/3] cpu: idle state framework for offline CPUs.
From: Pavel Machek @ 2009-08-10 8:19 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Brown, Len, Peter Zijlstra, Gautham R Shenoy,
linux-kernel@vger.kernel.org, Pallipadi, Venkatesh, Shaohua Li,
Ingo Molnar, linuxppc-dev@lists.ozlabs.org, Darrick J. Wong
In-Reply-To: <200908091522.02898.rjw@sisk.pl>
On Sun 2009-08-09 15:22:02, Rafael J. Wysocki wrote:
> On Sunday 09 August 2009, Pavel Machek wrote:
> > Hi!
> >
> > > > Also, approaches such as [1] can make use of this
> > > > extended infrastructure instead of putting the CPU to an arbitrary C-state
> > > > when it is offlined, thereby providing the system administrator a rope to hang
> > > > himself with should he feel the need to do so.
> > > I didn't see the reason why administrator needs to know which state offline cpu
> > > should stay. Don't know about powerpc side, but in x86 side, it appears deepest
> > > C-state is already preferred.
> > >
> >
> > Agreed, deepest c-state is always best, there's no need to make it configurable.
>
> Unless it doesn't work.
If it does not work, machine will not boot. We already have
max_cstate= kernel command line option to work around that...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH 03/14] powerpc: use printk_once
From: Michael Ellerman @ 2009-08-10 11:46 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, Paul Mackerras, Marcin Slusarz, LKML
In-Reply-To: <20090810080049.GA3132@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 2528 bytes --]
On Mon, 2009-08-10 at 10:00 +0200, Wolfram Sang wrote:
> On Sun, Aug 09, 2009 at 09:53:58PM +0200, Marcin Slusarz wrote:
> > Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
> > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Cc: Paul Mackerras <paulus@samba.org>
> > Cc: linuxppc-dev@ozlabs.org
> > ---
> > arch/powerpc/kernel/iommu.c | 6 +-----
> > arch/powerpc/kernel/irq.c | 5 ++---
> > arch/powerpc/sysdev/ppc4xx_pci.c | 9 ++-------
> > 3 files changed, 5 insertions(+), 15 deletions(-)
> >
> > diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
> > index fd51578..c7fa258 100644
> > --- a/arch/powerpc/kernel/iommu.c
> > +++ b/arch/powerpc/kernel/iommu.c
> > @@ -502,7 +502,6 @@ static void iommu_table_clear(struct iommu_table *tbl)
> > struct iommu_table *iommu_init_table(struct iommu_table *tbl, int nid)
> > {
> > unsigned long sz;
> > - static int welcomed = 0;
> > struct page *page;
> >
> > /* Set aside 1/4 of the table for large allocations. */
> > @@ -523,11 +522,8 @@ struct iommu_table *iommu_init_table(struct iommu_table *tbl, int nid)
> >
> > iommu_table_clear(tbl);
> >
> > - if (!welcomed) {
> > - printk(KERN_INFO "IOMMU table initialized, virtual merging %s\n",
> > + printk_once(KERN_INFO "IOMMU table initialized, virtual merging %s\n",
> > novmerge ? "disabled" : "enabled");
> > - welcomed = 1;
> > - }
> >
> > return tbl;
> > }
> > diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> > index f7f376e..05ebd21 100644
> > --- a/arch/powerpc/kernel/irq.c
> > +++ b/arch/powerpc/kernel/irq.c
> > @@ -231,7 +231,6 @@ skip:
> > void fixup_irqs(cpumask_t map)
> > {
> > unsigned int irq;
> > - static int warned;
> >
> > for_each_irq(irq) {
> > cpumask_t mask;
> > @@ -246,8 +245,8 @@ void fixup_irqs(cpumask_t map)
> > }
> > if (irq_desc[irq].chip->set_affinity)
> > irq_desc[irq].chip->set_affinity(irq, &mask);
> > - else if (irq_desc[irq].action && !(warned++))
> > - printk("Cannot set affinity for irq %i\n", irq);
> > + else if (irq_desc[irq].action)
> > + printk_once("Cannot set affinity for irq %i\n", irq);
>
> Maybe we should add a loglevel to this printk (and the other one in fix_irqs)
> while we are here?
I think you should drop it, it's stupid. If we actually care about irqs
that don't have a set affinity we should keep a count and report that at
the end of the loop.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 03/14] powerpc: use printk_once
From: Gary Thomas @ 2009-08-10 11:56 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, Paul Mackerras, LKML, Marcin Slusarz
In-Reply-To: <1249904809.4958.4.camel@concordia>
Michael Ellerman wrote:
> On Mon, 2009-08-10 at 10:00 +0200, Wolfram Sang wrote:
>> On Sun, Aug 09, 2009 at 09:53:58PM +0200, Marcin Slusarz wrote:
>>> Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
>>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>> Cc: Paul Mackerras <paulus@samba.org>
>>> Cc: linuxppc-dev@ozlabs.org
>>> ---
>>> arch/powerpc/kernel/iommu.c | 6 +-----
>>> arch/powerpc/kernel/irq.c | 5 ++---
>>> arch/powerpc/sysdev/ppc4xx_pci.c | 9 ++-------
>>> 3 files changed, 5 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
>>> index fd51578..c7fa258 100644
>>> --- a/arch/powerpc/kernel/iommu.c
>>> +++ b/arch/powerpc/kernel/iommu.c
>>> @@ -502,7 +502,6 @@ static void iommu_table_clear(struct iommu_table *tbl)
>>> struct iommu_table *iommu_init_table(struct iommu_table *tbl, int nid)
>>> {
>>> unsigned long sz;
>>> - static int welcomed = 0;
>>> struct page *page;
>>>
>>> /* Set aside 1/4 of the table for large allocations. */
>>> @@ -523,11 +522,8 @@ struct iommu_table *iommu_init_table(struct iommu_table *tbl, int nid)
>>>
>>> iommu_table_clear(tbl);
>>>
>>> - if (!welcomed) {
>>> - printk(KERN_INFO "IOMMU table initialized, virtual merging %s\n",
>>> + printk_once(KERN_INFO "IOMMU table initialized, virtual merging %s\n",
>>> novmerge ? "disabled" : "enabled");
>>> - welcomed = 1;
>>> - }
>>>
>>> return tbl;
>>> }
>>> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
>>> index f7f376e..05ebd21 100644
>>> --- a/arch/powerpc/kernel/irq.c
>>> +++ b/arch/powerpc/kernel/irq.c
>>> @@ -231,7 +231,6 @@ skip:
>>> void fixup_irqs(cpumask_t map)
>>> {
>>> unsigned int irq;
>>> - static int warned;
>>>
>>> for_each_irq(irq) {
>>> cpumask_t mask;
>>> @@ -246,8 +245,8 @@ void fixup_irqs(cpumask_t map)
>>> }
>>> if (irq_desc[irq].chip->set_affinity)
>>> irq_desc[irq].chip->set_affinity(irq, &mask);
>>> - else if (irq_desc[irq].action && !(warned++))
>>> - printk("Cannot set affinity for irq %i\n", irq);
>>> + else if (irq_desc[irq].action)
>>> + printk_once("Cannot set affinity for irq %i\n", irq);
>> Maybe we should add a loglevel to this printk (and the other one in fix_irqs)
>> while we are here?
>
> I think you should drop it, it's stupid. If we actually care about irqs
> that don't have a set affinity we should keep a count and report that at
> the end of the loop.
In addition, this change would prevent reporting missing
affinity on more than one IRQ if there were such.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* [PATCH 1/2] Make dtstruct variable to be 8 byte aligned
From: M. Mohan Kumar @ 2009-08-10 14:13 UTC (permalink / raw)
To: horms, kexec; +Cc: linuxppc-dev, nhorman, miltonm
[PATCH 1/2] Make dtstruct variable to be 8 byte aligned
kexec is creating a version 3 device tree to be backwards compatible. This
version of the struct has 8-byte alignment for properties whose value is 8 or
more bytes. As the code directly checks the pointer when deciding to add the
alignment word, the struct memory must start on an 8 byte boundary. Force the
dtstruct variable to be always 8 bytes aligned.
Signed-off-by: M. Mohan Kumar <mohan@in.ibm.com>
---
kexec/arch/ppc64/fs2dt.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kexec/arch/ppc64/fs2dt.c b/kexec/arch/ppc64/fs2dt.c
index 1f551fd..b01ff86 100644
--- a/kexec/arch/ppc64/fs2dt.c
+++ b/kexec/arch/ppc64/fs2dt.c
@@ -41,7 +41,7 @@
static char pathname[MAXPATH], *pathstart;
static char propnames[NAMESPACE] = { 0 };
-static unsigned dtstruct[TREEWORDS], *dt;
+static unsigned dtstruct[TREEWORDS] __attribute__ ((aligned (8))), *dt;
static unsigned long long mem_rsrv[2*MEMRESERVE] = { 0, 0 };
static int crash_param = 0;
--
1.6.2.5
^ permalink raw reply related
* [PATCH 2/2] Support R_PPC64_REL32 relocation type
From: M. Mohan Kumar @ 2009-08-10 14:14 UTC (permalink / raw)
To: horms, kexec; +Cc: linuxppc-dev, nhorman, miltonm
[PATCH 2/2] Support R_PPC64_REL32 relocation type
gcc-4.4 compiler creates R_PPC64_REL32 relocation type in the ppc64
purgatory code. Add support to handle R_PPC64_REL32 relocation type.
Signed-off-by: M. Mohan Kumar <mohan@in.ibm.com>
---
kexec/arch/ppc64/kexec-elf-rel-ppc64.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/kexec/arch/ppc64/kexec-elf-rel-ppc64.c b/kexec/arch/ppc64/kexec-elf-rel-ppc64.c
index 80543af..97aa34c 100644
--- a/kexec/arch/ppc64/kexec-elf-rel-ppc64.c
+++ b/kexec/arch/ppc64/kexec-elf-rel-ppc64.c
@@ -62,6 +62,10 @@ void machine_apply_elf_rel(struct mem_ehdr *ehdr, unsigned long r_type,
*(uint64_t *)location = value;
break;
+ case R_PPC64_REL32:
+ *(uint32_t *)location = value - (uint32_t)location;
+ break;
+
case R_PPC64_TOC:
*(uint64_t *)location = my_r2(ehdr);
break;
--
1.6.2.5
^ permalink raw reply related
* Re: need help getting SPI controller working on 405EX
From: Nathan French @ 2009-08-10 16:07 UTC (permalink / raw)
To: Lorenz Kolb; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <h5mjg0$rqs$1@ger.gmane.org>
Lorenz, thanks for the reply.
> For getting spidev devices you have to add entries for an spidev device
> to your newly created spi-"bus". So what you are currently missing are
> the spidev child-nodes in the device tree.
> As I'm currently cut off from some device to test, no guaranty that it
> will work, but your dts entry should look something like:
>
> SPI0: spi@ef600600 {
> cell-index = <0>;
> compatible = "ibm,spi-405ex", "ibm,spi";
> reg = <ef600600 6>;
> interrupts = <8 4>;
> interrupt-parent = <&UIC0>;
> mode = "cpu";
>
> yourdevice@0 {
> compatible = "spidev";
> spi-max-frequency = <1000000>; /* what ever your
> max-freq. is */
> reg = <0>; /* Chipselect-address */
> };
> };
This did not appear to have any effect.
> At least something similar worked for me some months ago (before we
> switched to a "real" driver for some custom peripheral).
Did this work on a 4xx PowerPC platform? Or something else? I've been
told that there is no SPI driver for 4xx. If you have done this on 4xx
then I'm very interested.
Thanks,
Nathan
^ permalink raw reply
* Re: [PATCH] mtd/maps: add mtd-ram support to physmap_of
From: Wolfram Sang @ 2009-08-10 16:19 UTC (permalink / raw)
To: Artem Bityutskiy
Cc: devicetree-discuss, Vitaly Wool, Albrecht Dreß, linuxppc-dev,
linux-mtd, Ken MacLeod, David Woodhouse
In-Reply-To: <1249795043.9157.37.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 1164 bytes --]
On Sun, Aug 09, 2009 at 08:17:23AM +0300, Artem Bityutskiy wrote:
> On Fri, 2009-08-07 at 23:43 -0600, Grant Likely wrote:
> > On Fri, Jul 17, 2009 at 6:39 AM, Wolfram Sang<w.sang@pengutronix.de> wrote:
> > > Use physmap_of to access RAMs as mtd and add documenation for it. This approach
> > > is a lot less intrusive as adding an of-wrapper around plat-ram.c. As most
> > > extensions of plat-ram.c (e.g. custom map-functions) can't be mapped to the
> > > device tree anyhow, extending physmap_of seems to be the cleanest approach.
> > >
> > > Tested with a phyCORE-MPC5121e.
> > >
> > > Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> >
> > Looks good to me.
> >
> > Acked-by: Grant Likely <grant.likely@secretlab.ca>
>
> This patch is sitting in my l2-mtd-2.6.git tree.
Great, thanks a lot (and for your l2-tree in general!). One question: Are the
additional Acked-bys added later? I could think they might be useful for
David's review...
Kind regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] mtd/maps: add mtd-ram support to physmap_of
From: Artem Bityutskiy @ 2009-08-10 16:25 UTC (permalink / raw)
To: Wolfram Sang
Cc: devicetree-discuss, Vitaly Wool, Albrecht Dreß, linuxppc-dev,
linux-mtd, Ken MacLeod, David Woodhouse
In-Reply-To: <20090810161942.GA27833@pengutronix.de>
On Mon, 2009-08-10 at 18:19 +0200, Wolfram Sang wrote:
> On Sun, Aug 09, 2009 at 08:17:23AM +0300, Artem Bityutskiy wrote:
> > On Fri, 2009-08-07 at 23:43 -0600, Grant Likely wrote:
> > > On Fri, Jul 17, 2009 at 6:39 AM, Wolfram Sang<w.sang@pengutronix.de> wrote:
> > > > Use physmap_of to access RAMs as mtd and add documenation for it. This approach
> > > > is a lot less intrusive as adding an of-wrapper around plat-ram.c. As most
> > > > extensions of plat-ram.c (e.g. custom map-functions) can't be mapped to the
> > > > device tree anyhow, extending physmap_of seems to be the cleanest approach.
> > > >
> > > > Tested with a phyCORE-MPC5121e.
> > > >
> > > > Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
> > >
> > > Looks good to me.
> > >
> > > Acked-by: Grant Likely <grant.likely@secretlab.ca>
> >
> > This patch is sitting in my l2-mtd-2.6.git tree.
>
> Great, thanks a lot (and for your l2-tree in general!). One question: Are the
> additional Acked-bys added later? I could think they might be useful for
> David's review...
Well, I do not bother maintaining nice history there, so rebase it
freely, which means I can add your ack. Will do tomorrow.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
^ permalink raw reply
* Linux MAINTAINERS section FREESCALE HIGHSPEED USB DEVICE DRIVER
From: Joe Perches @ 2009-08-10 19:08 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev, Guennadi Liakhovetski, linux-usb
Hi.
This entry, copied below, is no longer correct.
The "F:" entry got renamed by commit
54e4026b64a970303349b952866641a7804ef594
New file: drivers/usb/gadget/fsl_udc_core.c
Are you still maintaining this file?
You did not sign-off on the rename.
What should be done here?
cheers, Joe
FREESCALE HIGHSPEED USB DEVICE DRIVER
M: Li Yang <leoli@freescale.com>
L: linux-usb@vger.kernel.org
L: linuxppc-dev@ozlabs.org
S: Maintained
F: drivers/usb/gadget/fsl_usb2_udc.c
^ permalink raw reply
* Re: 5121 cache handling.
From: Kenneth Johansson @ 2009-08-10 20:16 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20090807195600.GB11681@b07421-ec1.am.freescale.net>
On Fri, 2009-08-07 at 14:56 -0500, Scott Wood wrote:
> On Fri, Aug 07, 2009 at 02:53:52PM +0200, Kenneth Johansson wrote:
> > on 5121 there is a e300 core that unfortunately is connected to the rest
> > of the SOC with a bus that do not support coherency.
> >
> > solution for many driver has been to use uncached memory. But for the
> > framebuffer that is not going to work as the performance impact of doing
> > graphics operations on uncached memory is to large.
> >
> > currently the "solution" is to flush the cache in the interrupt
> > handler.
> >
> > #if defined(CONFIG_NOT_COHERENT_CACHE)
> > int i;
> > unsigned int *ptr;
> > ptr = coherence_data;
> > for (i = 0; i < 1024*8; i++)
> > *ptr++ = 0;
> > #endif
> >
> > Now this apparently is not enough on a e300 core that has a PLRU cache
> > replacement algorithm. but what is the optimal solution?
>
> Which driver (in which kernel) are you looking at?
The one included in ltib 2009-06-02 for ads5121. Thought that was
including the latest drivers.
> drivers/video/fsl-diu-fb.c in current mainline has properly sized
> coherence data. It also does a dcbz (on unused data) instead of loads,
> as it's apparently faster (though I'd think you'd get more traffic
> flushing those zeroes out later on, compared to a clean line that can
> just be discarded).
It's hard to know exactly how things behave when cache is involved.
But the code allocate the 52KB buffer with vmalloc that cant be right as
cache is stored with physical address the 52KB data need to be 52KB
continuous in physical address and vmalloc do not guarantee that.
> > should not the framebuffer be marked as cache write through. that is the
> > W bit should be set in the tlb mapping. Why is this not done ? is that
> > feature also not working on 5121 ??
>
> It probably would have been too slow.
how much slower would write through be ? I thought it was not that big
of a difference from copy back.
^ permalink raw reply
* Re: 5121 cache handling.
From: Scott Wood @ 2009-08-10 20:26 UTC (permalink / raw)
To: Kenneth Johansson; +Cc: linuxppc-dev
In-Reply-To: <1249935384.7077.35.camel@localhost>
Kenneth Johansson wrote:
> But the code allocate the 52KB buffer with vmalloc that cant be right as
> cache is stored with physical address the 52KB data need to be 52KB
> continuous in physical address and vmalloc do not guarantee that.
Yeah, that looks like a bug.
>>> should not the framebuffer be marked as cache write through. that is the
>>> W bit should be set in the tlb mapping. Why is this not done ? is that
>>> feature also not working on 5121 ??
>> It probably would have been too slow.
>
> how much slower would write through be ? I thought it was not that big
> of a difference from copy back.
It's a big difference if you're writing out an entire cache line of data
anyway, but because of write-through it goes out one word at a time
without bursting.
-Scott
^ permalink raw reply
* Re: 5121 cache handling.
From: Kenneth Johansson @ 2009-08-10 20:45 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <4A808268.6000107@freescale.com>
On Mon, 2009-08-10 at 15:26 -0500, Scott Wood wrote:
> Kenneth Johansson wrote:
> >>> should not the framebuffer be marked as cache write through. that is the
> >>> W bit should be set in the tlb mapping. Why is this not done ? is that
> >>> feature also not working on 5121 ??
> >> It probably would have been too slow.
> >
> > how much slower would write through be ? I thought it was not that big
> > of a difference from copy back.
>
> It's a big difference if you're writing out an entire cache line of data
> anyway, but because of write-through it goes out one word at a time
> without bursting.
>
> -Scott
>
Yes the memory system would obviously get a higher load but do the CPU
actually see that? do it stall on the write ?
^ permalink raw reply
* Re: 5121 cache handling.
From: Scott Wood @ 2009-08-10 20:49 UTC (permalink / raw)
To: Kenneth Johansson; +Cc: linuxppc-dev
In-Reply-To: <1249937153.7077.38.camel@localhost>
Kenneth Johansson wrote:
> Yes the memory system would obviously get a higher load but do the CPU
> actually see that? do it stall on the write ?
Yes, there's a limited number of writes that can queue up before the CPU
core will have to wait.
-Scott
^ permalink raw reply
* PPC460EX with 2 Ethernet Transceivers
From: Judd Gilbert @ 2009-08-10 21:13 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1120 bytes --]
Hi,
I am currently running linux 2.6.28.4 on a PPC460EX with 2 Marvell
Alaska 88EIIII Ethernet transceivers connected to it. If I hold one of
the transceivers in reset on power on I get the following messages when
the linux kernel boots and eth0 and eth1 both work fine...
eth0: EMAC-0 /plb/opb/ethernet@ef600e00, MAC 00:13:a8:00:0d:c6
eth0: found Generic MII PHY (0x00)
/plb/opb/emac-rgmii@ef601500: input 1 in RGMII mode
eth1: EMAC-1 /plb/opb/ethernet@ef600f00, MAC 00:13:a8:00:0d:c7
eth1: found Generic MII PHY (0x02)
Now if I don't hold one of the chips in reset (I'm doing it manually
with a switch BTW) I get the following (and eth1 does not work):
eth0: EMAC-0 /plb/opb/ethernet@ef600e00, MAC 00:13:a8:00:0d:c6
eth0: found Generic MII PHY (0x00)
/plb/opb/emac-rgmii@ef601500: input 1 in RGMII mode
/plb/opb/ethernet@ef600f00: can't find PHY!
At first I thought maybe this is a problem with u-boot, but I'm not sure
now. I was going to start modifying the kernel - but thought I would ask
on here first if anyone has seen this issue.
Thanks for your time,
Judd Gilbert
[-- Attachment #2: Type: text/html, Size: 7859 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] cpu: idle state framework for offline CPUs.
From: Pallipadi, Venkatesh @ 2009-08-11 0:22 UTC (permalink / raw)
To: Pavel Machek
Cc: Brown, Len, Peter Zijlstra, Gautham R Shenoy,
linux-kernel@vger.kernel.org, Rafael J. Wysocki, Li, Shaohua,
Ingo Molnar, linuxppc-dev@lists.ozlabs.org, Darrick J. Wong
In-Reply-To: <20090810081941.GA18649@elf.ucw.cz>
On Mon, 2009-08-10 at 01:19 -0700, Pavel Machek wrote:
> On Sun 2009-08-09 15:22:02, Rafael J. Wysocki wrote:
> > On Sunday 09 August 2009, Pavel Machek wrote:
> > > Hi!
> > >
> > > > > Also, approaches such as [1] can make use of this
> > > > > extended infrastructure instead of putting the CPU to an arbitrary C-state
> > > > > when it is offlined, thereby providing the system administrator a rope to hang
> > > > > himself with should he feel the need to do so.
> > > > I didn't see the reason why administrator needs to know which state offline cpu
> > > > should stay. Don't know about powerpc side, but in x86 side, it appears deepest
> > > > C-state is already preferred.
> > > >
> > >
> > > Agreed, deepest c-state is always best, there's no need to make it configurable.
> >
> > Unless it doesn't work.
>
> If it does not work, machine will not boot. We already have
> max_cstate= kernel command line option to work around that...
>
On x86, my earlier patch was selecting deepest C-state based on CPU
capability. There, "unless it doesn't work" will not hold good. If a CPU
C-state is reported in cpuid it will work. If there is any errata we
will workaround it as we do with anything else in the kernel.
My concern about having this interface for offline CPU is
- How are we going to populate this possible states. On x86, there are
2-3 CPU mwait cstates with each having few sub C-states. And there can
be some BIOS supplied C-states which are IO port invocations which will
map to some CPU mwait state,sub state pair mentioned above and we won't
know anything about this mapping. So, we want to give all these options
in sysfs?
- Having all these states and having no information on what basis one
should change this or on what reasons one should change this will result
in some userspace superpowersaver daemon using this in a wrong way and
some distro shipping it.
Also, I don't think using just the ACPI/BIOS supplied states in _CST is
right thing to do for offline. _CST is meant for C-state and BIOS may
not include some C-state in _CST if the system manufacturer thinks that
the latency is too high for the state to be used as a C-state. That
limitation applies for C-state as the cpu is expected to come out of
C-state often and execute code handle interrupts etc. But, that
restriction does not apply for offline online which is not as frequent
as C-state entry and it already has big latency with startup IPI, and a
whole baggage of CPU setup code. So, using BIOS CST info for CPU offline
state doesn't seem right.
May be having (to pick a number) 3 possible offline states for all
platforms with one for halt equivalent and one for deepest possible that
CPU can handle and one for deepest possible that platform likes for
C-states may make sense. Will keeps things simpler in terms of usage
expectations and possibly reduce the misuse oppurtubity?
Thanks,
Venki
^ permalink raw reply
* [PATCH] usb/gadget: Update Freescale UDC entry in MAINTAINERS
From: Li Yang @ 2009-08-11 3:11 UTC (permalink / raw)
To: gregkh, joe; +Cc: linuxppc-dev, lg, linux-usb
Change the F entry for file rename, and make it also cover fsl_qe_udc
driver. Update the name accordingly.
Signed-off-by: Li Yang <leoli@freescale.com>
---
Liakhovetski,
Is it ok that it also covers your fsl_mx3_udc.c file. It's much easier
to use the wildcard.
MAINTAINERS | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index b1114cf..cf1e22c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2067,12 +2067,12 @@ S: Supported
F: arch/powerpc/sysdev/qe_lib/
F: arch/powerpc/include/asm/*qe.h
-FREESCALE HIGHSPEED USB DEVICE DRIVER
+FREESCALE USB PERIPHERIAL DRIVERS
M: Li Yang <leoli@freescale.com>
L: linux-usb@vger.kernel.org
L: linuxppc-dev@ozlabs.org
S: Maintained
-F: drivers/usb/gadget/fsl_usb2_udc.c
+F: drivers/usb/gadget/fsl*
FREESCALE QUICC ENGINE UCC ETHERNET DRIVER
M: Li Yang <leoli@freescale.com>
--
1.6.3.1.6.g4bf1f
^ permalink raw reply related
* Re: [PATCH] usb/gadget: Update Freescale UDC entry in MAINTAINERS
From: Joe Perches @ 2009-08-11 3:00 UTC (permalink / raw)
To: Li Yang; +Cc: linuxppc-dev, gregkh, lg, linux-usb
In-Reply-To: <1249960271-3400-1-git-send-email-leoli@freescale.com>
On Tue, 2009-08-11 at 11:11 +0800, Li Yang wrote:
> Change the F entry for file rename, and make it also cover fsl_qe_udc
> driver. Update the name accordingly.
>
> Signed-off-by: Li Yang <leoli@freescale.com>
> ---
> Liakhovetski,
>
> Is it ok that it also covers your fsl_mx3_udc.c file. It's much easier
> to use the wildcard.
> MAINTAINERS | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b1114cf..cf1e22c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2067,12 +2067,12 @@ S: Supported
> F: arch/powerpc/sysdev/qe_lib/
> F: arch/powerpc/include/asm/*qe.h
>
> -FREESCALE HIGHSPEED USB DEVICE DRIVER
> +FREESCALE USB PERIPHERIAL DRIVERS
> M: Li Yang <leoli@freescale.com>
> L: linux-usb@vger.kernel.org
> L: linuxppc-dev@ozlabs.org
> S: Maintained
> -F: drivers/usb/gadget/fsl_usb2_udc.c
> +F: drivers/usb/gadget/fsl*
If you want, you can add an "X:" entry as well
X: drivers/usb/gadget/fsl_mx3_udc.c
which excludes that file.
Excludes are tested before includes.
^ 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