* Re: [PATCH 1/3 v3] mtd: physmap_of: Add multiple regions and concatenation support
From: Stefan Roese @ 2009-06-23 6:36 UTC (permalink / raw)
To: devicetree-discuss; +Cc: linuxppc-dev, David Woodhouse, linux-mtd
In-Reply-To: <fa686aa40906162253j76776e88y9d7c818f4d0f1508@mail.gmail.com>
On Wednesday 17 June 2009 07:53:51 Grant Likely wrote:
> David, what's the status of this patch? Will it be merged for 2.6.31?
It's merged now.
Thanks,
Stefan
^ permalink raw reply
* Re: ppc405ex GPIO mapping
From: Lada Podivin @ 2009-06-23 6:29 UTC (permalink / raw)
To: Cote, Sylvain; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <e35801cc0906220948v22a13e2fxfcae52d51e69c310@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 72 bytes --]
Eh, sorry! I mean
include/asm-generic/gpio.h
NOT
include/linux/gpio.h
[-- Attachment #2: Type: text/html, Size: 378 bytes --]
^ permalink raw reply
* [PATCH v2] fbdev: work around old compiler bug
From: Stephen Rothwell @ 2009-06-23 5:44 UTC (permalink / raw)
To: Linus
Cc: James Simmons, Sam Ravnborg, LKML, Krzysztof Helt,
Geert Uytterhoeven, Andrew Morton, ppc-dev
In-Reply-To: <20090622183415.46fa786b.sfr@canb.auug.org.au>
When building with a 4.1.x compiler on powerpc64 (at least) we get
this error:
drivers/video/logo/logo_linux_mono.c:81: error: logo_linux_mono causes a section type conflict
This was introduced by commit ae52bb2384f721562f15f719de1acb8e934733cb
("fbdev: move logo externs to header file"). This is a partial revert
of that commit sufficient to not hit the compiler bug.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
scripts/pnmtologo.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
v2: also convert _clut arrays from __initconst to __initdata.
diff --git a/scripts/pnmtologo.c b/scripts/pnmtologo.c
index 64f5ddb..5c11312 100644
--- a/scripts/pnmtologo.c
+++ b/scripts/pnmtologo.c
@@ -237,7 +237,7 @@ static void write_header(void)
fprintf(out, " * Linux logo %s\n", logoname);
fputs(" */\n\n", out);
fputs("#include <linux/linux_logo.h>\n\n", out);
- fprintf(out, "static const unsigned char %s_data[] __initconst = {\n",
+ fprintf(out, "static unsigned char %s_data[] __initdata = {\n",
logoname);
}
@@ -374,7 +374,7 @@ static void write_logo_clut224(void)
fputs("\n};\n\n", out);
/* write logo clut */
- fprintf(out, "static const unsigned char %s_clut[] __initconst = {\n",
+ fprintf(out, "static unsigned char %s_clut[] __initdata = {\n",
logoname);
write_hex_cnt = 0;
for (i = 0; i < logo_clutsize; i++) {
--
1.6.3.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: Badness on the Warp
From: Sean MacLennan @ 2009-06-23 5:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Frans Pop, linux-kernel, linuxppc-dev, Pekka Enberg,
Paul Mackerras, David Gibson
In-Reply-To: <1245623104.16880.26.camel@pasglop>
On Mon, 22 Jun 2009 08:25:04 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> Kumar already submitted a couple, Frans, feel free to beat me
> at converting UIC (just use kmalloc directly in there instead
> of alloc_bootmem).
I replace the bootmem_alloc with a kzalloc and the badness went away.
So it looks like, for my config anyway, that solves the problem.
Cheers,
Sean
^ permalink raw reply
* Re: [ewg] Re: [PATCH 2.6.31 try 2] ehca: Tolerate dynamic memory operations and huge pages
From: Roland Dreier @ 2009-06-23 5:19 UTC (permalink / raw)
To: Alexander Schmidt
Cc: Hannes Hering, linux-kernel, ewg, linuxppc-dev, raisch,
Hoang-Nam Nguyen
In-Reply-To: <20090616091021.2acf7302@BL3D1974.boeblingen.de.ibm.com>
thanks, applied.
> -#define HCAD_VERSION "0026"
> +#define HCAD_VERSION "0027"
the driver version was already 0027 (since bde2cfaf), so I dropped this chunk.
^ permalink raw reply
* Re: [RESEND][PATCH] SPI: xilinx_spi: Added platform driver and support for DS570
From: Andrew Morton @ 2009-06-23 5:04 UTC (permalink / raw)
To: Richard Röjfors
Cc: dbrownell, Linux Kernel Mailing List, linuxppc-dev,
spi-devel-general, Andrei Konovalov, John, Linn
In-Reply-To: <4A366622.2050606@mocean-labs.com>
This appears to be a ppc thing, so let's cc that list. Let's also cc
the driver's author and other contributors. Please cc these people on
future versions of the patch also.
On Mon, 15 Jun 2009 17:17:54 +0200 Richard R__jfors <richard.rojfors.ext@mocean-labs.com> wrote:
> This patch splits xilinx_spi into three parts, an OF and a platform
> driver and generic part.
>
> The generic part now also works on X86 and also supports the Xilinx
> SPI IP DS570
>
>
> ...
>
> +#ifndef CONFIG_PPC
> +#define in_8(addr) ioread8(addr)
> +#define in_be16(addr) ioread16(addr)
> +#define in_be32(addr) ioread32(addr)
> +
> +#define out_8(addr, b) iowrite8(b, addr)
> +#define out_be16(addr, w) iowrite16(w, addr)
> +#define out_be32(addr, l) iowrite32(l, addr)
> +#endif
Why do we need these?
> +#define XSPI_WRITE8(xspi, offs, val) \
> + do { \
> + if (xspi->model == XILINX_SPI_MODEL_DS464) \
> + out_8(xspi->regs + offs, (val) & 0xff); \
> + else \
> + XSPI_WRITE32(xspi, offs, val); \
> + } while (0)
> +
> +#define XSPI_WRITE16(xspi, offs, val) \
> + do { \
> + if (xspi->model == XILINX_SPI_MODEL_DS464) \
> + out_be16(xspi->regs + offs, (val) & 0xffff); \
> + else \
> + XSPI_WRITE32(xspi, offs, val); \
> + } while (0)
> +
> +#define XSPI_WRITE32(xspi, offs, val) \
> + out_be32(xspi->regs + offs, val)
> +
> +#define XSPI_READ8(xspi, offs) \
> + (xspi->model == XILINX_SPI_MODEL_DS464) ? \
> + in_8(xspi->regs + offs) : XSPI_READ32(xspi, offs)
> +
> +#define XSPI_READ16(xspi, offs) \
> + (xspi->model == XILINX_SPI_MODEL_DS464) ? \
> + in_be16(xspi->regs + offs) : XSPI_READ32(xspi, offs)
> +
> +#define XSPI_READ32(xspi, offs) \
> + in_be32(xspi->regs + offs)
I'm seeing no reason why these had to be implemented as macros.
They're ugly, add considerable code bloat and, because they evaluate
their args multiple times they will fail if passed as expression with
side-effects.
I suggest that they be reimplemented as lower-case, uninlined C functions.
^ permalink raw reply
* [PATCH] powerpc/mpic: Fix mapping of "DCR" based MPIC variants
From: Benjamin Herrenschmidt @ 2009-06-23 2:47 UTC (permalink / raw)
To: linuxppc-dev
Commit 31207dab7d2e63795eb15823947bd2f7025b08e2
"Fix incorrect allocation of interrupt rev-map"
introduced a regression crashing on boot on machines using
a "DCR" based MPIC, such as the Cell blades.
The reason is that the irq host data structure is initialized
much later as a result of that patch, causing our calls to
mpic_map() do be done before we have a host setup.
Unfortunately, this breaks _mpic_map_dcr() which uses the
mpic->irqhost to get to the device node.
This fixes it by, instead, passing the device node explicitely
to mpic_map().
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/sysdev/mpic.c | 29 ++++++++++++++++-------------
1 file changed, 16 insertions(+), 13 deletions(-)
--- linux-work.orig/arch/powerpc/sysdev/mpic.c 2009-06-23 11:30:14.000000000 +1000
+++ linux-work/arch/powerpc/sysdev/mpic.c 2009-06-23 11:45:17.000000000 +1000
@@ -279,28 +279,29 @@ static void _mpic_map_mmio(struct mpic *
}
#ifdef CONFIG_PPC_DCR
-static void _mpic_map_dcr(struct mpic *mpic, struct mpic_reg_bank *rb,
+static void _mpic_map_dcr(struct mpic *mpic, struct device_node *node,
+ struct mpic_reg_bank *rb,
unsigned int offset, unsigned int size)
{
const u32 *dbasep;
- dbasep = of_get_property(mpic->irqhost->of_node, "dcr-reg", NULL);
+ dbasep = of_get_property(node, "dcr-reg", NULL);
- rb->dhost = dcr_map(mpic->irqhost->of_node, *dbasep + offset, size);
+ rb->dhost = dcr_map(node, *dbasep + offset, size);
BUG_ON(!DCR_MAP_OK(rb->dhost));
}
-static inline void mpic_map(struct mpic *mpic, phys_addr_t phys_addr,
- struct mpic_reg_bank *rb, unsigned int offset,
- unsigned int size)
+static inline void mpic_map(struct mpic *mpic, struct device_node *node,
+ phys_addr_t phys_addr, struct mpic_reg_bank *rb,
+ unsigned int offset, unsigned int size)
{
if (mpic->flags & MPIC_USES_DCR)
- _mpic_map_dcr(mpic, rb, offset, size);
+ _mpic_map_dcr(mpic, node, rb, offset, size);
else
_mpic_map_mmio(mpic, phys_addr, rb, offset, size);
}
#else /* CONFIG_PPC_DCR */
-#define mpic_map(m,p,b,o,s) _mpic_map_mmio(m,p,b,o,s)
+#define mpic_map(m,n,p,b,o,s) _mpic_map_mmio(m,p,b,o,s)
#endif /* !CONFIG_PPC_DCR */
@@ -1152,8 +1153,8 @@ struct mpic * __init mpic_alloc(struct d
}
/* Map the global registers */
- mpic_map(mpic, paddr, &mpic->gregs, MPIC_INFO(GREG_BASE), 0x1000);
- mpic_map(mpic, paddr, &mpic->tmregs, MPIC_INFO(TIMER_BASE), 0x1000);
+ mpic_map(mpic, node, paddr, &mpic->gregs, MPIC_INFO(GREG_BASE), 0x1000);
+ mpic_map(mpic, node, paddr, &mpic->tmregs, MPIC_INFO(TIMER_BASE), 0x1000);
/* Reset */
if (flags & MPIC_WANTS_RESET) {
@@ -1194,7 +1195,7 @@ struct mpic * __init mpic_alloc(struct d
/* Map the per-CPU registers */
for (i = 0; i < mpic->num_cpus; i++) {
- mpic_map(mpic, paddr, &mpic->cpuregs[i],
+ mpic_map(mpic, node, paddr, &mpic->cpuregs[i],
MPIC_INFO(CPU_BASE) + i * MPIC_INFO(CPU_STRIDE),
0x1000);
}
@@ -1202,7 +1203,7 @@ struct mpic * __init mpic_alloc(struct d
/* Initialize main ISU if none provided */
if (mpic->isu_size == 0) {
mpic->isu_size = mpic->num_sources;
- mpic_map(mpic, paddr, &mpic->isus[0],
+ mpic_map(mpic, node, paddr, &mpic->isus[0],
MPIC_INFO(IRQ_BASE), MPIC_INFO(IRQ_STRIDE) * mpic->isu_size);
}
mpic->isu_shift = 1 + __ilog2(mpic->isu_size - 1);
@@ -1256,8 +1257,10 @@ void __init mpic_assign_isu(struct mpic
BUG_ON(isu_num >= MPIC_MAX_ISU);
- mpic_map(mpic, paddr, &mpic->isus[isu_num], 0,
+ mpic_map(mpic, mpic->irqhost->of_node,
+ paddr, &mpic->isus[isu_num], 0,
MPIC_INFO(IRQ_STRIDE) * mpic->isu_size);
+
if ((isu_first + mpic->isu_size) > mpic->num_sources)
mpic->num_sources = isu_first + mpic->isu_size;
}
^ permalink raw reply
* Re: sym scsi driver problem with 2.6.26 or newer debian kernel on p610 (fwd)
From: Benjamin Herrenschmidt @ 2009-06-23 2:31 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, debian-powerpc, Laszlo Fekete
In-Reply-To: <Pine.LNX.4.64.0906141105050.4412@axis700.grange>
On Sun, 2009-06-14 at 11:10 +0200, Guennadi Liakhovetski wrote:
> P610 (and tested it on P630 and P640 too)
Also, send me a tarball of /proc/device-tree please.
Cheers,
Ben.
^ permalink raw reply
* Re: sym scsi driver problem with 2.6.26 or newer debian kernel on p610 (fwd)
From: Benjamin Herrenschmidt @ 2009-06-23 2:30 UTC (permalink / raw)
To: blackluck; +Cc: linuxppc-dev, debian-powerpc, Guennadi Liakhovetski
In-Reply-To: <1245719890.4017.26.camel@pasglop>
On Tue, 2009-06-23 at 11:18 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2009-06-22 at 11:10 +0200, Laszlo Fekete wrote:
> > Hello!
> >
> > Is there any idea for the solution?
>
> Hard to tell yet. Looks indeed like something is wrong with the
> interrupt controller.
>
> Any chance you can bisect that ? I'll also have a look on my side,
> it's definitely not something obvious.
I tried on a POWER3 box I have here "IBM,7044-170" and things work fine
here with current upstream. (I suspect a much smaller machine).
I will really need an actual bisection here... In the meantime, I'll see
if I can get my hand on one of these machines here.
Cheers,
Ben.
> Cheers,
> Ben.
>
> > Thanks: blackluck
> >
> > Laszlo Fekete wrote:
> > > Hello!
> > >
> > > I'm sorry about the annoyances, but I'd welcome all ideas, suggestions
> > > to see what needs to be done or should be tested for the solution.
> > >
> > > Thank you very much!
> > >
> > > Guennadi Liakhovetski wrote:
> > >> Ok, first attempt to forward this to scsi was wrong, as pointed out
> > >> by Matthew Wilcox this does indeed look like an interrupt problem -
> > >> no interrupts drom SCSI, IDE, keyboar. Might be a known problem, I
> > >> guess. In any case, I think, the OP would be grateful for any hints.
> > >>
> > >> Thanks
> > >> Guennadi
> > >> ---
> > >> Guennadi Liakhovetski, Ph.D.
> > >> Freelance Open-Source Software Developer
> > >> http://www.open-technology.de/
> > >>
> > >> ---------- Forwarded message ----------
> > >> Date: Sat, 13 Jun 2009 16:22:07 +0200
> > >> From: Laszlo Fekete <blackluck@ktk.bme.hu>
> > >> To: debian-powerpc@lists.debian.org
> > >> Subject: sym scsi driver problem with 2.6.26 or newer debian kernel
> > >> on p610
> > >> Resent-Date: Sat, 13 Jun 2009 14:29:55 +0000 (UTC)
> > >> Resent-From: debian-powerpc@lists.debian.org
> > >>
> > >> This is a multi-part message in MIME format.
> > >> ------------------------------------------------------------------------
> > >>
> > >> Hello!
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> Pls help me with sym scsi driver problem.
> > >>
> > >>
> > >>
> > >> I have Ibm P610 (and tested it on P630 and P640 too), installed debian
> > >>
> > >> etch and upgraded to lenny.
> > >>
> > >>
> > >>
> > >> But with 2.6.26 or newer kernel it's not booting, it's hang on sym scsi
> > >>
> > >> bus scan.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> Whats the problem with it, or how can I fix this?
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> I attach the output from minicom with 2.6.29, 2.6.26, and the working
> > >>
> > >> 2.6.24 kernel booting.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> Thank you very much!
> > >>
> > >>
> > >>
> > >
> > >
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] powerpc/ps3: Use pr_devel() in ps3/mm.c
From: Michael Ellerman @ 2009-06-23 1:56 UTC (permalink / raw)
To: linuxppc-dev
The non-debug case in ps3/mm.c uses pr_debug(), so that the compiler
still does type checks etc. and doesn't complain about unused
variables in the non-debug case.
However with DEBUG=n and CONFIG_DYNAMIC_DEBUG=y there's still code
generated for those pr_debugs().
size before:
text data bss dec hex filename
17553 4112 88 21753 54f9 arch/powerpc/platforms/ps3/mm.o
size after:
text data bss dec hex filename
7377 776 88 8241 2031 arch/powerpc/platforms/ps3/mm.o
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/platforms/ps3/mm.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/ps3/mm.c b/arch/powerpc/platforms/ps3/mm.c
index 846eb8b..68f1397 100644
--- a/arch/powerpc/platforms/ps3/mm.c
+++ b/arch/powerpc/platforms/ps3/mm.c
@@ -34,7 +34,7 @@
#if defined(DEBUG)
#define DBG udbg_printf
#else
-#define DBG pr_debug
+#define DBG pr_devel
#endif
enum {
--
1.6.2.1
^ permalink raw reply related
* Re: sym scsi driver problem with 2.6.26 or newer debian kernel on p610 (fwd)
From: Benjamin Herrenschmidt @ 2009-06-23 1:18 UTC (permalink / raw)
To: blackluck; +Cc: linuxppc-dev, debian-powerpc, Guennadi Liakhovetski
In-Reply-To: <4A3F4A77.6070704@ktk.bme.hu>
On Mon, 2009-06-22 at 11:10 +0200, Laszlo Fekete wrote:
> Hello!
>
> Is there any idea for the solution?
Hard to tell yet. Looks indeed like something is wrong with the
interrupt controller.
Any chance you can bisect that ? I'll also have a look on my side,
it's definitely not something obvious.
Cheers,
Ben.
> Thanks: blackluck
>
> Laszlo Fekete wrote:
> > Hello!
> >
> > I'm sorry about the annoyances, but I'd welcome all ideas, suggestions
> > to see what needs to be done or should be tested for the solution.
> >
> > Thank you very much!
> >
> > Guennadi Liakhovetski wrote:
> >> Ok, first attempt to forward this to scsi was wrong, as pointed out
> >> by Matthew Wilcox this does indeed look like an interrupt problem -
> >> no interrupts drom SCSI, IDE, keyboar. Might be a known problem, I
> >> guess. In any case, I think, the OP would be grateful for any hints.
> >>
> >> Thanks
> >> Guennadi
> >> ---
> >> Guennadi Liakhovetski, Ph.D.
> >> Freelance Open-Source Software Developer
> >> http://www.open-technology.de/
> >>
> >> ---------- Forwarded message ----------
> >> Date: Sat, 13 Jun 2009 16:22:07 +0200
> >> From: Laszlo Fekete <blackluck@ktk.bme.hu>
> >> To: debian-powerpc@lists.debian.org
> >> Subject: sym scsi driver problem with 2.6.26 or newer debian kernel
> >> on p610
> >> Resent-Date: Sat, 13 Jun 2009 14:29:55 +0000 (UTC)
> >> Resent-From: debian-powerpc@lists.debian.org
> >>
> >> This is a multi-part message in MIME format.
> >> ------------------------------------------------------------------------
> >>
> >> Hello!
> >>
> >>
> >>
> >>
> >>
> >> Pls help me with sym scsi driver problem.
> >>
> >>
> >>
> >> I have Ibm P610 (and tested it on P630 and P640 too), installed debian
> >>
> >> etch and upgraded to lenny.
> >>
> >>
> >>
> >> But with 2.6.26 or newer kernel it's not booting, it's hang on sym scsi
> >>
> >> bus scan.
> >>
> >>
> >>
> >>
> >>
> >> Whats the problem with it, or how can I fix this?
> >>
> >>
> >>
> >>
> >>
> >> I attach the output from minicom with 2.6.29, 2.6.26, and the working
> >>
> >> 2.6.24 kernel booting.
> >>
> >>
> >>
> >>
> >>
> >> Thank you very much!
> >>
> >>
> >>
> >
> >
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: Boot failure on the powerstation with 2.6.30 latest
From: Benjamin Herrenschmidt @ 2009-06-22 22:25 UTC (permalink / raw)
To: James Bottomley; +Cc: Brian King, linuxppc-dev, Pekka Enberg, Linux Kernel list
In-Reply-To: <1245708236.17035.2.camel@mulgrave.site>
> Actually, no, reverting that one doesn't fix it.
>
> A full run of git bisect turns up this commit as the culprit; I'll make
> a fuss on lkml:
I haven't had the full log of that boot failure, but reverting the patch
Brian suggested won't work well indeed, as I said, from the moment slab
is initialized, page table allocations will use kmem caches which are
initialized by pgtable_cache_init().
So the problem does indeed seem to be another fallover of moving the
allocator initialization earlier.
I'm working from home today but I'll see if I can get somebody in the
office to wire up the powerstation (got disconnected for some reason
last week) for me so I can have a look.
The mutex issue Brian noticed will definitely break _any_ kmem_cache
operation anyway, so that's one bug that need fixing at least (well,
provided Brian analysis is right, I didn't have a chance to look myself
yet :-)
Cheers,
Ben.
> 83b519e8b9572c319c8e0c615ee5dd7272856090 is first bad commit
> commit 83b519e8b9572c319c8e0c615ee5dd7272856090
> Author: Pekka Enberg <penberg@cs.helsinki.fi>
> Date: Wed Jun 10 19:40:04 2009 +0300
>
> slab: setup allocators earlier in the boot sequence
>
> James
>
^ permalink raw reply
* Re: Boot failure on the powerstation with 2.6.30 latest
From: Benjamin Herrenschmidt @ 2009-06-22 22:21 UTC (permalink / raw)
To: Brian King; +Cc: James Bottomley, linuxppc-dev, Pekka Enberg, Linux Kernel list
In-Reply-To: <4A3FAD31.2060703@linux.vnet.ibm.com>
On Mon, 2009-06-22 at 11:11 -0500, Brian King wrote:
> James,
>
> I was running into a similar hang on one of my Power boxes as well.
> Reverting c868d550115b9ccc0027c67265b9520790f05601 allowed by system
> to boot. It looks like that patch injected a bug where we can end up
> waiting on an uninitialized mutex:
>
> [c0000000009f3c30] c00000000052c7dc .mutex_lock+0x34/0x50
> [c0000000009f3cb0] c00000000008b190 .get_online_cpus+0x3c/0x74
> [c0000000009f3d40] c000000000146cd0 .kmem_cache_create+0xcc/0x548
> [c0000000009f3e50] c000000000032ae0 .pgtable_cache_init+0x28/0x6c
> [c0000000009f3ee0] c000000000780960 .start_kernel+0x1ec/0x520
> [c0000000009f3f90] c0000000000083d8 .start_here_common+0x1c/0x44
>
> The mutex gets initialized in cpu_hotplug_init, which doesn't get called until
> after pgtable_cache_init.
Ah good, I didn't have a chance to track that one down yet.
So the problem here is that we must do pgtable_cache_init there because
vmalloc is initialized right after, which relies on allocating page
tables and that will need kmem caches on some archs.
So I suspect we need to sort out this mutex, either initializing it from
elsewhere, moving cpu_hotplug_init() earlier, or avoiding it when the
kernel state isn't SYSTEM_RUNNING, I haven't looked in details yet.
Cheers,
Ben.
> -Brian
>
> James Bottomley wrote:
> > 2.6.30-rc8 worked fine ... unless this is a known problem, I suppose I
> > can begin bisecting.
> >
> > The boot log of the hang is:
> >
> > Please wait, loading kernel...
> > Elf64 kernel loaded...
> > Loading ramdisk...
> > ramdisk loaded at 02500000, size: 8280 Kbytes
> > OF stdout device is: /ht/isa@8/serial@2f8
> > Preparing to boot Linux version 2.6.30 (jejb@claymoor) (gcc version 4.3.3 (Debian 4.3.3-10) ) #1 SMP Mon Jun 22 09:59:35 CDT 2009
> > command line: root=/dev/sda3 ro console=ttyS0,19200n1
> > memory layout at init:
> > alloc_bottom : 0000000002d16000
> > alloc_top : 0000000030000000
> > alloc_top_hi : 0000000080000000
> > rmo_top : 0000000030000000
> > ram_top : 0000000080000000
> > instantiating rtas at 0x000000002fff5000... done
> > boot cpu hw idx 0000000000000000
> > starting cpu hw idx 0000000000000001... done
> > starting cpu hw idx 0000000000000002... done
> > starting cpu hw idx 0000000000000003... done
> > copying OF device tree...
> > Building dt strings...
> > Building dt structure...
> > Device tree strings 0x0000000003117000 -> 0x0000000003117640
> > Device tree struct 0x0000000003118000 -> 0x000000000311b000
> > Calling quiesce...
> > returning from prom_init
> >
> > So it looks like some type of early boot failure or handoff in head_64
> >
> > James
> >
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
^ permalink raw reply
* Re: Boot failure on the powerstation with 2.6.30 latest
From: James Bottomley @ 2009-06-22 22:03 UTC (permalink / raw)
To: Brian King; +Cc: linuxppc-dev
In-Reply-To: <4A3FAD31.2060703@linux.vnet.ibm.com>
On Mon, 2009-06-22 at 11:11 -0500, Brian King wrote:
> James,
>
> I was running into a similar hang on one of my Power boxes as well.
> Reverting c868d550115b9ccc0027c67265b9520790f05601 allowed by system
> to boot. It looks like that patch injected a bug where we can end up
> waiting on an uninitialized mutex:
>
> [c0000000009f3c30] c00000000052c7dc .mutex_lock+0x34/0x50
> [c0000000009f3cb0] c00000000008b190 .get_online_cpus+0x3c/0x74
> [c0000000009f3d40] c000000000146cd0 .kmem_cache_create+0xcc/0x548
> [c0000000009f3e50] c000000000032ae0 .pgtable_cache_init+0x28/0x6c
> [c0000000009f3ee0] c000000000780960 .start_kernel+0x1ec/0x520
> [c0000000009f3f90] c0000000000083d8 .start_here_common+0x1c/0x44
>
> The mutex gets initialized in cpu_hotplug_init, which doesn't get called until
> after pgtable_cache_init.
Actually, no, reverting that one doesn't fix it.
A full run of git bisect turns up this commit as the culprit; I'll make
a fuss on lkml:
83b519e8b9572c319c8e0c615ee5dd7272856090 is first bad commit
commit 83b519e8b9572c319c8e0c615ee5dd7272856090
Author: Pekka Enberg <penberg@cs.helsinki.fi>
Date: Wed Jun 10 19:40:04 2009 +0300
slab: setup allocators earlier in the boot sequence
James
^ permalink raw reply
* Re: [PATCH v3 2/2] fsldma: Add DMA_SLAVE support
From: Dan Williams @ 2009-06-22 21:22 UTC (permalink / raw)
To: Ira Snyder, Li Yang, Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1245705647.937.2.camel@dwillia2-linux.ch.intel.com>
On Mon, 2009-06-22 at 14:20 -0700, Dan Williams wrote:
> On Fri, 2009-06-19 at 12:31 -0700, Ira Snyder wrote:
> > Use the DMA_SLAVE capability of the DMAEngine API to copy/from a
> > scatterlist into an arbitrary list of hardware address/length pairs.
> >
> > This allows a single DMA transaction to copy data from several different
> > devices into a scatterlist at the same time.
> >
> > This also adds support to enable some controller-specific features such as
> > external start and external pause for a DMA transaction.
> >
> > Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
> > ---
> >
> > This patch depends on the "fsldma: split apart external pause and
> > request count features" patch.
> >
> > After discussion with Dan Williams, this is the third version of the
> > DMA_SLAVE API for the Freescale DMA controller. I've tested it heavily
> > with both drivers I have written against this API, an FPGA programmer
> > and an FPGA data grabber.
> >
> > Kumar, Dan asked me to add you to the CC list, so you can have a look at
> > this patch before he adds it to his tree.
> >
> > The other two small patches I posted earlier are very helpful in testing
> > this functionality. They make the fsldma driver leave the BWC (bandwidth
> > control) bits alone on the 83xx controller, as well as making the
> > external start feature available on 83xx.
> >
>
> Kumar, Leo,
>
> Can I get your acked-by's for the current state of async_tx.git/next? I
> just pushed out Ira's latest so it may take a moment to mirror out.
>
> Thanks,
> Dan
>
> The following changes since commit f234012f52a37e48f2330e1ca2df69800e797c3b:
> Linus Torvalds (1):
> Merge branch 'for-linus' of git://git.kernel.org/.../drzeus/mmc
>
> are available in the git repository at:
>
> ssh://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx.git next
That should be:
git://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx.git next
^ permalink raw reply
* Re: [PATCH v3 2/2] fsldma: Add DMA_SLAVE support
From: Dan Williams @ 2009-06-22 21:20 UTC (permalink / raw)
To: Ira Snyder; +Cc: linuxppc-dev@ozlabs.org, Li Yang
In-Reply-To: <20090619193134.GC30992@ovro.caltech.edu>
On Fri, 2009-06-19 at 12:31 -0700, Ira Snyder wrote:
> Use the DMA_SLAVE capability of the DMAEngine API to copy/from a
> scatterlist into an arbitrary list of hardware address/length pairs.
>
> This allows a single DMA transaction to copy data from several different
> devices into a scatterlist at the same time.
>
> This also adds support to enable some controller-specific features such as
> external start and external pause for a DMA transaction.
>
> Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
> ---
>
> This patch depends on the "fsldma: split apart external pause and
> request count features" patch.
>
> After discussion with Dan Williams, this is the third version of the
> DMA_SLAVE API for the Freescale DMA controller. I've tested it heavily
> with both drivers I have written against this API, an FPGA programmer
> and an FPGA data grabber.
>
> Kumar, Dan asked me to add you to the CC list, so you can have a look at
> this patch before he adds it to his tree.
>
> The other two small patches I posted earlier are very helpful in testing
> this functionality. They make the fsldma driver leave the BWC (bandwidth
> control) bits alone on the 83xx controller, as well as making the
> external start feature available on 83xx.
>
Kumar, Leo,
Can I get your acked-by's for the current state of async_tx.git/next? I
just pushed out Ira's latest so it may take a moment to mirror out.
Thanks,
Dan
The following changes since commit f234012f52a37e48f2330e1ca2df69800e797c3b:
Linus Torvalds (1):
Merge branch 'for-linus' of git://git.kernel.org/.../drzeus/mmc
are available in the git repository at:
ssh://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx.git next
Dan Williams (1):
dmaengine: move HIGHMEM64G restriction to ASYNC_TX_DMA
Ira Snyder (4):
fsldma: enable external start for the 83xx controller
fsldma: do not clear bandwidth control bits on the 83xx controller
fsldma: split apart external pause and request count features
fsldma: Add DMA_SLAVE support
Ira W. Snyder (1):
fsldma: use PCI Read Multiple command
arch/powerpc/include/asm/fsldma.h | 136 +++++++++++++++++
drivers/dma/Kconfig | 4 +-
drivers/dma/fsldma.c | 287 ++++++++++++++++++++++++++++++++++---
drivers/dma/fsldma.h | 4 +-
4 files changed, 408 insertions(+), 23 deletions(-)
create mode 100644 arch/powerpc/include/asm/fsldma.h
^ permalink raw reply
* [PATCH] spufs: remove redundant test on unsigned
From: Roel Kluin @ 2009-06-22 22:20 UTC (permalink / raw)
To: jk; +Cc: linuxppc-dev, Andrew Morton
In-Reply-To: <4A3FF508.3000304@gmail.com>
Unsigned `len' cannot be less than 0.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
Or should it be `if (!buf || len > MAX)' and what should MAX be then?
diff --git a/arch/powerpc/platforms/cell/spufs/sputrace.c b/arch/powerpc/platforms/cell/spufs/sputrace.c
index d0b1f3f..8f799ee 100644
--- a/arch/powerpc/platforms/cell/spufs/sputrace.c
+++ b/arch/powerpc/platforms/cell/spufs/sputrace.c
@@ -73,7 +73,7 @@ static ssize_t sputrace_read(struct file *file, char __user *buf,
{
int error = 0, cnt = 0;
- if (!buf || len < 0)
+ if (!buf)
return -EINVAL;
while (cnt < len) {
^ permalink raw reply related
* Re: ppc405ex GPIO mapping
From: Lada Podivin @ 2009-06-22 16:48 UTC (permalink / raw)
To: Cote, Sylvain; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <579B119545DAEF4689C8FBEEFEC5793F01D4FEF815F1@ATLMBX.verint.corp.verintsystems.com>
[-- Attachment #1: Type: text/plain, Size: 849 bytes --]
Hi,
I have the same board and I had a similar problem. I use 2.6.30, so I don't
know whether 2.6.25 supports the following - however, here's my suggestion.
Set these options in your kernel config: CONFIG_GPIOLIB=y and
CONFIG_PPC4xx_GPIO=y. Before compilation do "export
KCPPFLAGS=-DARCH_NR_GPIOS=32" - you have to let the kernel know, that your
GPIO has 32 pins (default value is 255) and compile the kernel.
Then change the line
compatible = "ibm,gpio-405ex";
to
compatible = "ibm,ppc4xx-gpio";
Ok! After this long journey you shoul be able to work with your GPIO pins
with functions like gpio_set_value() - from include/linux/gpio.h.
Documentation of these functions can be seen at
http://www.mjmwired.net/kernel/Documentation/gpio.txt
So, this is my solution. Maybe there are better ones, but this works well
for me :)
Best,
Lada Podivin
[-- Attachment #2: Type: text/html, Size: 1123 bytes --]
^ permalink raw reply
* Re: Boot failure on the powerstation with 2.6.30 latest
From: Brian King @ 2009-06-22 16:11 UTC (permalink / raw)
To: James Bottomley; +Cc: linuxppc-dev
In-Reply-To: <1245683801.6901.8.camel@mulgrave.site>
James,
I was running into a similar hang on one of my Power boxes as well.
Reverting c868d550115b9ccc0027c67265b9520790f05601 allowed by system
to boot. It looks like that patch injected a bug where we can end up
waiting on an uninitialized mutex:
[c0000000009f3c30] c00000000052c7dc .mutex_lock+0x34/0x50
[c0000000009f3cb0] c00000000008b190 .get_online_cpus+0x3c/0x74
[c0000000009f3d40] c000000000146cd0 .kmem_cache_create+0xcc/0x548
[c0000000009f3e50] c000000000032ae0 .pgtable_cache_init+0x28/0x6c
[c0000000009f3ee0] c000000000780960 .start_kernel+0x1ec/0x520
[c0000000009f3f90] c0000000000083d8 .start_here_common+0x1c/0x44
The mutex gets initialized in cpu_hotplug_init, which doesn't get called until
after pgtable_cache_init.
-Brian
James Bottomley wrote:
> 2.6.30-rc8 worked fine ... unless this is a known problem, I suppose I
> can begin bisecting.
>
> The boot log of the hang is:
>
> Please wait, loading kernel...
> Elf64 kernel loaded...
> Loading ramdisk...
> ramdisk loaded at 02500000, size: 8280 Kbytes
> OF stdout device is: /ht/isa@8/serial@2f8
> Preparing to boot Linux version 2.6.30 (jejb@claymoor) (gcc version 4.3.3 (Debian 4.3.3-10) ) #1 SMP Mon Jun 22 09:59:35 CDT 2009
> command line: root=/dev/sda3 ro console=ttyS0,19200n1
> memory layout at init:
> alloc_bottom : 0000000002d16000
> alloc_top : 0000000030000000
> alloc_top_hi : 0000000080000000
> rmo_top : 0000000030000000
> ram_top : 0000000080000000
> instantiating rtas at 0x000000002fff5000... done
> boot cpu hw idx 0000000000000000
> starting cpu hw idx 0000000000000001... done
> starting cpu hw idx 0000000000000002... done
> starting cpu hw idx 0000000000000003... done
> copying OF device tree...
> Building dt strings...
> Building dt structure...
> Device tree strings 0x0000000003117000 -> 0x0000000003117640
> Device tree struct 0x0000000003118000 -> 0x000000000311b000
> Calling quiesce...
> returning from prom_init
>
> So it looks like some type of early boot failure or handoff in head_64
>
> James
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
--
Brian King
Linux on Power Virtualization
IBM Linux Technology Center
^ permalink raw reply
* ppc405ex GPIO mapping
From: Cote, Sylvain @ 2009-06-22 15:13 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 1253 bytes --]
Hi,
I am using kernel 2.6.25.20 on my Kilauea eval board (ppc405ex). I want to access some GPIO's. I have configured my u-boot to reflect what GPIO configuration I need. I try to access my GPIO's in my driver. When accessing GPIO's, I get this error in the kernel <<Unable to handle kernel paging request for data at address 0xef600800>>. 0xef600800 is the base address of GPIO in the ppc405ex.
It looks like GPIO's are not mapped in my kernel. I have tried to add this entry in my dts file (under POB0: opb ) but it does not work:
GPIO: gpio@ef600800
{
compatible = "ibm,gpio-405ex";
reg = <ef600800 00000020>;
};
Any clues on this issues?
Thanks
Sylvain C.
This electronic message may contain proprietary and confidential information of Verint Systems Inc., its affiliates and/or subsidiaries.
The information is intended to be for the use of the individual(s) or
entity(ies) named above. If you are not the intended recipient (or authorized to receive this e-mail for the intended recipient), you may not use, copy, disclose or distribute to anyone this message or any information contained in this message. If you have received this electronic message in error, please notify us by replying to this e-mail.
\r
[-- Attachment #2: Type: text/html, Size: 5231 bytes --]
^ permalink raw reply
* Boot failure on the powerstation with 2.6.30 latest
From: James Bottomley @ 2009-06-22 15:16 UTC (permalink / raw)
To: linuxppc-dev
2.6.30-rc8 worked fine ... unless this is a known problem, I suppose I
can begin bisecting.
The boot log of the hang is:
Please wait, loading kernel...
Elf64 kernel loaded...
Loading ramdisk...
ramdisk loaded at 02500000, size: 8280 Kbytes
OF stdout device is: /ht/isa@8/serial@2f8
Preparing to boot Linux version 2.6.30 (jejb@claymoor) (gcc version 4.3.3 (Debian 4.3.3-10) ) #1 SMP Mon Jun 22 09:59:35 CDT 2009
command line: root=/dev/sda3 ro console=ttyS0,19200n1
memory layout at init:
alloc_bottom : 0000000002d16000
alloc_top : 0000000030000000
alloc_top_hi : 0000000080000000
rmo_top : 0000000030000000
ram_top : 0000000080000000
instantiating rtas at 0x000000002fff5000... done
boot cpu hw idx 0000000000000000
starting cpu hw idx 0000000000000001... done
starting cpu hw idx 0000000000000002... done
starting cpu hw idx 0000000000000003... done
copying OF device tree...
Building dt strings...
Building dt structure...
Device tree strings 0x0000000003117000 -> 0x0000000003117640
Device tree struct 0x0000000003118000 -> 0x000000000311b000
Calling quiesce...
returning from prom_init
So it looks like some type of early boot failure or handoff in head_64
James
^ permalink raw reply
* AW: PowerPC PCI DMA issues (prefetch/coherency?)
From: Sergej.Stepanov @ 2009-06-22 14:31 UTC (permalink / raw)
To: chris.pringle, scottwood; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <4A3A23FA.1000407@oxtel.com>
>The other part of the fix is in asm-powerpc/pgtable32.h. _PAGE_BASE
>needs _PAGE_COHERENT in order to work correctly, and in fact there is
>now a comment in there to that affect in 2.6.29. Backporting that change
>has made it work on 2.6.26. Both this patch, and the fix to head_32.S
>are needed for it to work correctly on older kernels.
>
>Chris
Hello Chris,
sorry for dummy, but if it possible, could you, please, send a correspondin=
g summary patch of backporting you've done for older kernels?
or just summary of that changes once again?
Many thanks
Sergej.=
^ permalink raw reply
* [PATCH] Sky CPU: redundant or incorrect tests on unsigned
From: Roel Kluin @ 2009-06-22 16:40 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, Andrew Morton
count is unsigned and cannot be less than 0.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
Can these be removed or do we need an `if (count > MAX)' test, and
what should MAX be then?
diff --git a/drivers/misc/hdpuftrs/hdpu_cpustate.c b/drivers/misc/hdpuftrs/hdpu_cpustate.c
index 176fe4e..35000cf 100644
--- a/drivers/misc/hdpuftrs/hdpu_cpustate.c
+++ b/drivers/misc/hdpuftrs/hdpu_cpustate.c
@@ -121,8 +121,6 @@ static ssize_t cpustate_read(struct file *file, char *buf,
{
unsigned char data;
- if (count < 0)
- return -EFAULT;
if (count == 0)
return 0;
@@ -137,9 +135,6 @@ static ssize_t cpustate_write(struct file *file, const char *buf,
{
unsigned char data;
- if (count < 0)
- return -EFAULT;
-
if (count == 0)
return 0;
^ permalink raw reply related
* Re: kilauea/405ex external interrupts
From: Lada Podivin @ 2009-06-22 11:31 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200906221123.11192.sr@denx.de>
[-- Attachment #1: Type: text/plain, Size: 589 bytes --]
Thanks for replies!
2009/6/22 Stefan Roese <sr@denx.de>
> Yes, this could very well be a problem of pin multiplexing. From looking at
> the Kilauea GPIO/Pin mux configuration in U-Boot, GPIO30 is configured as
> GPIO
> input and not as IRQ1. So this can't work. The easiest way to change this
> is
> in U-Boot (include/configs/kilauea.h).
>
Right, the pin multiplexing was the problem. I didn't know that U-BOOT can
do that - very useful information, thank you again!
>
> BTW: Are you using Kilauea or a custom 405EX board?
>
> Best regards,
> Stefan
>
>
Yes, it's the Kilauea board.
[-- Attachment #2: Type: text/html, Size: 1104 bytes --]
^ permalink raw reply
* Re: [PATCH] fbdev: work around old compiler bug
From: Sam Ravnborg @ 2009-06-22 9:41 UTC (permalink / raw)
To: Stephen Rothwell
Cc: James Simmons, Linus, LKML, Krzysztof Helt, Geert Uytterhoeven,
Andrew Morton, ppc-dev
In-Reply-To: <20090622183415.46fa786b.sfr@canb.auug.org.au>
On Mon, Jun 22, 2009 at 06:34:15PM +1000, Stephen Rothwell wrote:
> On Mon, 22 Jun 2009 18:04:20 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > When building with a 4.1.x compiler on powerpc64 (at least) we get
> > this error:
>
> Ignore this, it causes more problems:
>
> drivers/video/logo/logo_linux_clut224.c:548: error: logo_linux_clut224_clut causes a section type conflict
>
> I'll work on a better solution.
I have no time to experiemnt atm.
But I have seen this before.
It happens when we mix up const and non-const stuff.
I would assume the simple solution is to replace _initconst with _initdata
for all users.
If you get it to work with powerpc then it works for everyone (or so it is usually).
Sam
^ 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