Hello Rogerio,
Rogério Brito wrote onTue Sep 9 10:47:29 EST 2008:
> I just compiled a new 2.6.27-rc5 kernel for my standard Kurobox (an
> embedded NAS that has an MPC8241 CPU, if I'm not mistaken) and upon
> booting, I get these scary messages and Call Traces:
>
> - - - - - - - - - - - - - - - - -
The typesafe version of the powerpc pagetable handling (with
USE_STRICT_MM_TYPECHECKS defined) has bitrotted again. This patch
makes a bunch of small fixes to get it building again.
Signed-off-by: David Gibson <[EMAIL PROTECTED]>
Index: working-2.6/arch/powerpc/include/asm/pgtable-ppc64.h
==
Hi there.
I just compiled a new 2.6.27-rc5 kernel for my standard Kurobox (an
embedded NAS that has an MPC8241 CPU, if I'm not mistaken) and upon
booting, I get these scary messages and Call Traces:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Linux version 2.6.27-rc5.t
On Sep 08 2008, Rogério Brito wrote:
> I just compiled a new 2.6.27-rc5 kernel for my standard Kurobox (an
> embedded NAS that has an MPC8241 CPU, if I'm not mistaken) and upon
> booting, I get these scary messages and Call Traces:
(...)
I obviously forgot to attach the files in the previous e-mai
On Mon, 8 Sep 2008 14:42:33 -0700
"Prodyut Hazarika" <[EMAIL PROTECTED]> wrote:
> Hi Josh,
> Thanks for your reply.
>
> > That was a bit old and I've updated it now to match the overallpowerpc.git
> > tree master branch
> Thanks. I can see the changes now.
>
> > Generally, if you track my 'next
> - if (unlikely(dev == NULL || dev->archdata.dma_ops == NULL))
> +
> + if (unlikely(dev == NULL) || dev->archdata.dma_ops == NULL) {
> +#ifdef CONFIG_PPC64
> return NULL;
> +#else
> + /* Use default on 32-bit if dma_ops is not set up */
> + return &dma
On Tue, Sep 09, 2008 at 01:27:17AM +0400, Anton Vorontsov wrote:
> I always thought that posting "-M" patches to the public lists is
> discouraged since it is quite difficult to apply them via patch(1).
> Also think of non-git users...
Yes, it's a horrible idea.
__
On Mon, Sep 08, 2008 at 02:09:53PM -0500, Becky Bruce wrote:
> +/* We support DMA to/from any memory page via the iommu */
> +static int dma_iommu_dma_supported(struct device *dev, u64 mask)
> +{
> + struct iommu_table *tbl = dev->archdata.dma_data;
> +
> + if (!tbl || tbl->it_offset > mask
On Mon, Sep 08, 2008 at 02:09:51PM -0500, Becky Bruce wrote:
> I have tested this code on 8641 and 8572 platforms using the popular
> kernel build as well as full runs of LTP. I have built 64-bit
> platforms, but have no means to test there, so I would greatly
> appreciate any feedback you can pro
On Mon, Sep 08, 2008 at 04:38:57PM -0500, Scott Wood wrote:
> Anton Vorontsov wrote:
>> I always thought that posting "-M" patches to the public lists is
>> discouraged since it is quite difficult to apply them via patch(1).
>> Also think of non-git users...
>
> I think the substantially enhanced r
Anton Vorontsov wrote:
I always thought that posting "-M" patches to the public lists is
discouraged since it is quite difficult to apply them via patch(1).
Also think of non-git users...
I think the substantially enhanced reviewability trumps non-git-users
who can follow the rename instructio
On Mon, 8 Sep 2008 13:55:26 -0700
"Prodyut Hazarika" <[EMAIL PROTECTED]> wrote:
> Hi Josh,
> I am planning to submit a patch to support 4K/16K and 64K page size for 4xx
> processors.
> I see that your git tree still has the include/asm-powerpc/* header files,
> while in Linus's git tree, the pow
On Mon, Sep 08, 2008 at 02:18:42PM -0500, Scott Wood wrote:
> Becky Bruce wrote:
>> This is in preparation for the merge of the 32 and 64-bit
>> dma code in arch/powerpc.
>>
>> Signed-off-by: Becky Bruce <[EMAIL PROTECTED]>
>> ---
>> arch/powerpc/kernel/Makefile |2 +-
>> arch/powerpc/kernel/d
Becky Bruce wrote:
We're currently passing NULL, and really shouldn't be.
This patch doesn't change that for cpm2, since port.dev is never
initialized. :-P
Signed-off-by: Becky Bruce <[EMAIL PROTECTED]>
---
drivers/serial/cpm_uart/cpm_uart_cpm2.c |6 +++---
drivers/serial/ucc_uart.c
We're currently passing NULL, and really shouldn't be.
Signed-off-by: Becky Bruce <[EMAIL PROTECTED]>
---
drivers/serial/cpm_uart/cpm_uart_cpm2.c |6 +++---
drivers/serial/ucc_uart.c |4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/serial/cpm_u
Becky Bruce wrote:
This is in preparation for the merge of the 32 and 64-bit
dma code in arch/powerpc.
Signed-off-by: Becky Bruce <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/Makefile |2 +-
arch/powerpc/kernel/dma.c| 200 ++
arch/powerpc/kernel/d
We essentially adopt the 64-bit dma code, with some changes to support
32-bit systems, including HIGHMEM. dma functions on 32-bit are now
invoked via accessor functions which call the correct op for a device based
on archdata dma_ops. If there is no archdata dma_ops, this defaults
to dma_direct_o
This is in preparation for the merge of the 32 and 64-bit
dma code in arch/powerpc.
Signed-off-by: Becky Bruce <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/Makefile |2 +-
arch/powerpc/kernel/dma.c| 200 ++
arch/powerpc/kernel/dma_64.c | 200 --
Use the struct device's numa_node instead; use accessor functions
to get/set numa_node.
Signed-off-by: Becky Bruce <[EMAIL PROTECTED]>
---
64-bit folks: Please test when you get a moment. I've build-tested this,
but I do not have the ability to actually boot it on anything. Yes, I know
this fund
32-bit platforms are about to start using dma.c; move the iommu
dma ops into their own file to make this a bit cleaner.
Signed-off-by: Becky Bruce <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/Makefile|2 +-
arch/powerpc/kernel/dma-iommu.c | 103 +++
arc
This patch series merges the 32 and 64-bit dma code and does some
other cleanup. This has changed a bit since the RFC was submitted
a few months ago - I incorporated most of the comments from Christoph,
including moving the iommu-specific code into its own file and dropping
numa_node from archdat
On Sat, Sep 06, 2008 at 05:07:15PM +0200, Wolfgang Grandegger wrote:
> How about "dtt"? That's what we use in U-Boot for digital temperature
> sensors as well.
I vote against any acronyms that are not very well known. Even knowing
that it's supposed to be "digital temperature ", I can't
figure ou
The following patch series adds things needed to support the PowerPC 405EZ
SoC. I've incorporated the suggestions and fixes from the previous round
of patches and barring any further comments these should be ready to go.
josh
Josh Boyer (3):
ibm_newemac: Allow the "no flow control" EMAC featur
The PowerPC 405EZ SoC has some differences in the interrupt layout and
handling for the MAL. The SERR, TXDE, and RXDE interrupts are OR'd into
a single interrupt. Also, due to the possibility for interrupt coalescing,
the TXEOB and RXEOB interrupts require an interrupt bit to be cleared in
the IC
There are some PowerPC SoCs that do odd things with the MAL handling. In
order to accommodate them, we need to introduce a feature mechanism that is
similar to the existing emac_has_feature function.
This adds a feature variable to the mal_instance structure, and adds a
mal_has_feature function.
Some PowerPC 40x chips have errata that force us not to use the integrated
flow control. We have the feature defined, but it currently can't be used
because it is never added to EMAC_FTRS_POSSIBLE.
This adds a Kconfig option for affected platforms to select and puts the
feature in the EMAC_FTRS_P
Linus,
Please pull from the 'merge' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
There is one commit there from Hugh Dickins that fixes a build
problem, plus three from the Cell guys fixing a couple of races and a
reference count leak in arch/powerpc/platforms
This patch adds support for the AD7414 temperature sensor
on Sequoia PPC440EPx board.
Signed-off-by: Matthias Fuchs <[EMAIL PROTECTED]>
Acked-by: Stefan Roese <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/sequoia.dts |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a
28 matches
Mail list logo
