Hi all,
Target : PowerPC440
Kernel : Linux-2.6.29.6
The issue still remains in kernel linux-2.6.29.6 enabling following options
in kernel, the kernel panics and won't boot anymore
The following kernel options enabled :
# Networking support
CONFIG_NET=y
CONFIG_INET=y
CONFIG_NET_KEY=y
CONFIG_XF
On Aug 13, 2009, at 6:06 PM, Paul Gortmaker wrote:
From: Liang Li
The existing fsl_rstcr_restart function fails to reset the sbc8560
board. This implements a board specific reset function that uses
the RCR(Reset Control Register) of the board's EPLD to do a reset.
Signed-off-by: Liang Li
Si
On Aug 13, 2009, at 6:06 PM, Paul Gortmaker wrote:
From: Liang Li
The existing fsl_rstcr_restart function fails to reset the sbc8560
board. This implements a board specific reset function that uses
the RCR(Reset Control Register) of the board's EPLD to do a reset.
Signed-off-by: Liang Li
Si
The default COMMAND_LINE_SIZE in asm-generic is 512, so the
net effect of this change is nil, aside from the cleanup
factor. See also commit 2b74b8569.
Signed-off-by: Paul Gortmaker
---
arch/powerpc/include/asm/setup.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/ar
From: Liang Li
The existing fsl_rstcr_restart function fails to reset the sbc8560
board. This implements a board specific reset function that uses
the RCR(Reset Control Register) of the board's EPLD to do a reset.
Signed-off-by: Liang Li
Signed-off-by: Paul Gortmaker
---
arch/powerpc/platform
Arnd Bergmann wrote:
On Thursday 13 August 2009 19:37:04 Paul Gortmaker wrote:
The default COMMAND_LINE_SIZE in asm-generic is 512, so the
net effect of this change is nil, aside from the cleanup
factor. See also commit 2b74b8569.
Signed-off-by: Paul Gortmaker
Acked-by: Arnd Bergmann
Just
On Thursday 13 August 2009 19:37:04 Paul Gortmaker wrote:
> The default COMMAND_LINE_SIZE in asm-generic is 512, so the
> net effect of this change is nil, aside from the cleanup
> factor. See also commit 2b74b8569.
>
> Signed-off-by: Paul Gortmaker
Acked-by: Arnd Bergmann
Just to clarify why
Felix Radensky wrote:
Currently concatenation support is implemented in physmap_of driver.
The syntax used to define a concatenation device involves multiple
reg tuples, as described in
Documentation/powerpc/dts-bindings/mtd-physmap.txt. Will same syntax
be acceptable for NAND chips ?
I'm not
Hi Felix:
Sorry the documentation seems a little miss leading. There is no harm
with the bit
turned off to zero. Once the nand boot is over, we change the EBC to use
the ready
signal, this bit does not affect performance anymore.
Thanks
Feng Kan
On 08/12/2009 11:14 PM, Felix Radensky wrote:
On Thu, 2009-08-13 at 13:01 +1000, Michael Ellerman wrote:
> We don't actually want kmemleak to track the lmb allocations, so we
> pass min_count as 0. However telling kmemleak about lmb allocations
> allows it to scan that memory for pointers to other memory that is
> tracked by kmemleak, ie. slab
This patch adds NOR MTD support and I2C HWMON support for the AD7414
to the AMCC Arches defconfig.
Signed-off-by: Stefan Roese
---
arch/powerpc/configs/44x/arches_defconfig | 382 +
1 files changed, 332 insertions(+), 50 deletions(-)
diff --git a/arch/powerpc/config
This patch adds some nodes to the AMCC Arches dts:
- L2 cache support
- NOR FLASH mapping with default partitioning
- I2C HWMON device (AD7414)
Signed-off-by: Stefan Roese
---
arch/powerpc/boot/dts/arches.dts | 50 ++
1 files changed, 50 insertions(+), 0 de
Hi,
I'd like to be able to concatenate several NAND banks (each bank on
separate chip select)
into a single MTD device, and define partition table on a concatenated
device.
Currently concatenation support is implemented in physmap_of driver. The
syntax used
to define a concatenation device i
On Aug 13, 2009, at 5:38 AM, Benjamin Herrenschmidt wrote:
On Thu, 2009-08-13 at 10:55 +0200, Ingo Molnar wrote:
Or we can have the patches in core/iommu and I pull the whole
thing in powerpc-next. [...]
Ok! We could also stage it a bit (one or two weeks) in a separate
branch and allow a re
On Thursday 13 August 2009 07:00:03 Benjamin Herrenschmidt wrote:
> On Sat, 2009-07-18 at 15:06 +0200, Michael Buesch wrote:
> > This patch fixes a memory and semaphore leak in the viotape driver's
> > char device write op. It leaks the DMA memory and the semaphore lock
> > in case the device was o
On Thu, 2009-08-13 at 10:55 +0200, Ingo Molnar wrote:
> > Or we can have the patches in core/iommu and I pull the whole
> > thing in powerpc-next. [...]
>
> Ok! We could also stage it a bit (one or two weeks) in a separate
> branch and allow a rebase, should you find any bugs during testing?
S
I've pushed a few more things to my -test branch (in addition to some
-next updates that I may have forgotten to mention yesterday).
So here's the whole lot of stuff that's in there today vs. upstream.
Please give it a spin, it's really only compile tested here (and I
haven't scrubbed the warning
Hi,
> I'm trying to understand the rationale behind "ppc_spurious_interrupts"
> without luck so far. I'm seeing the BAD interrupt counter incrementing with
> kernels of different ages (2.6.5, 2.6.16, 2.6.27) and on different hardware
> (IBM P5 and P6 64 bit, Apple PPC 32 bit).
On IBM POWER5 an
On Thu, Aug 13, 2009 at 04:14:58PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2009-08-11 at 11:39 +0200, Bastian Blank wrote:
> > This patch just disables this driver on SMP kernels, as it is obviously
> > not supported.
> Why not remove the #error instead ? :-) I don't think it's still
> meani
Felix Radensky wrote:
Hi,
I'm trying to use dmatest driver on MPC8536DS running linux 2.6.31-rc5.
The loading of driver fails, as it is unable to allocate DMA channel.
Is this driver supposed to work with FSL DMA engine ?
I should have disabled "TCP receive copy offload" DMA client.
dmatest w
Hi,
I'm trying to use dmatest driver on MPC8536DS running linux 2.6.31-rc5.
The loading of driver fails, as it is unable to allocate DMA channel.
Is this driver supposed to work with FSL DMA engine ?
Thanks.
Felix.
___
Linuxppc-dev mailing list
Linuxp
>Now, I know there is at least one person on earth
>contemplating sharing some drivers between PPC and ARM. I
>won't tell much more at this stage, but it makes sense in the
>grand scheme of things to see SoC vendors put similar IO cores
>into either PPC or ARM and providing that clock API is a
* Benjamin Herrenschmidt wrote:
>
> > Ben, what's your preference? I waited for your reaction with these
> > bits, i.e. they are not in tip:core/iommu yet.
>
> Oh I though they were... discard my previous private mail about
> missing Ack's then :-)
>
> I'll review them more in depth hopeful
* FUJITA Tomonori wrote:
> On Thu, 13 Aug 2009 15:48:42 +1000
> Benjamin Herrenschmidt wrote:
>
> > On Wed, 2009-08-05 at 14:08 +0900, FUJITA Tomonori wrote:
> >
> > > The above swiotlb patchset was merged in -tip so I think that merging
> > > this patchset via -tip too is the easiest way to
On Thu, 2009-08-13 at 17:05 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2009-08-04 at 23:51 +0200, Michel Dänzer wrote:
> > From: Michel Dänzer
> >
> > Signed-off-by: Michel Dänzer
> > ---
>
> Hi Michel !
>
> While your two previous patches apply just fine, this one doesn't,
> the uninorth_
At Thu, 13 Aug 2009 18:07:57 +1000,
Benjamin Herrenschmidt wrote:
>
> On Thu, 2009-08-13 at 09:11 +0200, Takashi Iwai wrote:
> > I'm willing to rebase my patches to the generic dma_ops, so feel free
> > to pull it first.
>
> I think I'll end up pulling Ingo's iommu branch into powerpc-next to
> g
> Ben, what's your preference? I waited for your reaction with these
> bits, i.e. they are not in tip:core/iommu yet.
Oh I though they were... discard my previous private mail about
missing Ack's then :-)
I'll review them more in depth hopefully tomorrow but they look good.
> One variant would
On Thu, 2009-08-13 at 09:11 +0200, Takashi Iwai wrote:
> I'm willing to rebase my patches to the generic dma_ops, so feel free
> to pull it first.
I think I'll end up pulling Ingo's iommu branch into powerpc-next to
get Fujita stuff, so if you rebase on top of his stuff, it will come
along just fi
On Thu, 2009-08-13 at 09:03 +0100, Martyn Welch wrote:
> Remove the reliance on a staticly defined NVRAM size, allowing platforms to
> support NVRAMs with sizes differing from the standard. A fall back value is
> provided for platforms not supporting this extension.
>
> Signed-off-by: Martyn Wel
Remove the reliance on a staticly defined NVRAM size, allowing platforms to
support NVRAMs with sizes differing from the standard. A fall back value is
provided for platforms not supporting this extension.
Signed-off-by: Martyn Welch
---
Ben: Is this a suitable solution?
v2: rename nvram_size
At Thu, 13 Aug 2009 16:51:53 +1000,
Benjamin Herrenschmidt wrote:
>
> On Thu, 2009-08-13 at 16:44 +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2009-08-05 at 14:08 +0900, FUJITA Tomonori wrote:
> >
> > > The above swiotlb patchset was merged in -tip so I think that merging
> > > this patchset
On Thu, 2009-07-02 at 17:12 +0100, Martyn Welch wrote:
> Remove the reliance on a staticly defined NVRAM size, allowing platforms to
> support NVRAMs with sizes differing from the standard. A fall back value is
> provided for platforms not supporting this extension.
>
> Signed-off-by: Martyn Wel
On Thu, 13 Aug 2009 15:48:42 +1000
Benjamin Herrenschmidt wrote:
> On Wed, 2009-08-05 at 14:08 +0900, FUJITA Tomonori wrote:
>
> > The above swiotlb patchset was merged in -tip so I think that merging
> > this patchset via -tip too is the easiest way to handle this patchset.
> >
> > The patchse
On Tue, 2009-08-04 at 23:51 +0200, Michel Dänzer wrote:
> From: Michel Dänzer
>
> Signed-off-by: Michel Dänzer
> ---
Hi Michel !
While your two previous patches apply just fine, this one doesn't,
the uninorth_insert_memory() function seems to be slightly different
upstream. Does this depend on
34 matches
Mail list logo
