We are using the MPC8572 running SMP Linux 2.6.23 kernel. Having
problems reliably recovering from core_fault_in which is generated by
the PCIe 2 Controller (RC) on reception of UR/CA messages. The PCIe
Controller has error detection and interrupts turned on in PEX_ERR_XX
registers. Also, AER capa
At Wed, 3 Jun 2009 15:35:19 +1000,
Stephen Rothwell wrote:
>
> [I am not sure if this is the correct approach as I don't know if any of
> this actual hardware or drivers are really hot pluggable.]
I thought it can be bound/unbound dynamically via sysfs.
Anyway, the patch looks correct, so I appl
On Tue, Jun 2, 2009 at 5:12 PM, Grant Likely wrote:
> Hi Esben and Ben,
>
> Sorry for the lateness in reviewing this. FWIW, here are my comments.
>
> g.
>
> On Mon, May 18, 2009 at 11:22 PM, Esben Haabendal
> wrote:
>> This fixes MAL (arbitration lost) bug caused by illegal use of
>> RSTA (repea
[I am not sure if this is the correct approach as I don't know if any of
this actual hardware or drivers are really hot pluggable.]
Gets rid of these build warnings:
WARNING: sound/ppc/snd-powermac.o(.devinit.text+0x5c): Section mismatch in
reference from the function .snd_pmac_probe() to the fu
The MMU context_lock can be taken from switch_mm() while the
rq->lock is held. The rq->lock can also be taken from interrupts,
thus if we get interrupted in destroy_context() with the context
lock held and that interrupt tries to take the rq->lock, there's
a possible deadlock scenario with another
resource_size_t is 64 bits on pseries
Gets rid of these warnings:
arch/powerpc/platforms/pseries/iommu.c: In function 'pci_dma_bus_setup_pSeries':
arch/powerpc/platforms/pseries/iommu.c:391: warning: format '%lx' expects type
'long unsigned int', but argument 2 has type 'resource_size_t'
arch/po
Gets rid of this warning:
arch/powerpc/xmon/xmon.c: In function 'dump_log_buf':
arch/powerpc/xmon/xmon.c:2133: warning: unused variable 'i'
Signed-off-by: Stephen Rothwell
---
arch/powerpc/xmon/xmon.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/xmon/xm
resource_size_t is 64 bits on PowerPC 64.
Gets rid of this warning:
arch/powerpc/kernel/pci_64.c: In function 'pcibios_map_io_space':
arch/powerpc/kernel/pci_64.c:504: warning: format '%016lx' expects type 'long
unsigned int', but argument 2 has type 'resource_size_t'
Signed-off-by: Stephen Rot
Commit 45db9240890d9343c934db1fe82d6e68ac2d28da ("powerpc/spufs: Remove
double check for non-negative dentry") removed the only user of the
out_dput label, so remove it and the code following it.
Gets rid of this warning:
arch/powerpc/platforms/cell/spufs/inode.c: In function 'spufs_create':
arch
On Tue, 2009-06-02 at 11:49 +0100, Arnd Bergmann wrote:
>
> then add the other BOOK3S option depending on PPC64. Even though
> it might look silly to have a choice statement with just one possible
> option in case of PPC64, why not integrate it right away, for
> consistency
> reasons. It seems str
Hi Linus !
Here's a defconfig update if you still get things in .30
Cheers,
Ben.
The following changes since commit d9244b5d2fbfe9fa540024b410047af13ceec90f:
Linus Torvalds (1):
Merge branch 'hwmon-for-linus' of
git://git.kernel.org/.../jdelvare/staging
are available in the git repos
Hi Esben and Ben,
Sorry for the lateness in reviewing this. FWIW, here are my comments.
g.
On Mon, May 18, 2009 at 11:22 PM, Esben Haabendal
wrote:
> This fixes MAL (arbitration lost) bug caused by illegal use of
> RSTA (repeated START) after STOP condition generated after last byte
> of reads
On Tue, 2009-06-02 at 20:45 +0200, Albrecht Dreß wrote:
>
> which drops the r1 accesses, but still produces the sub-optimal loop.
> Is this a gcc regression, or did I miss something here? Probably the
> only bullet-proof way is to write some core loops in assembly... :-/
Well, gcc may be r
On Thu, May 28, 2009 at 10:15:22PM +0200, Esben Haabendal wrote:
> On Thu, May 28, 2009 at 9:31 PM, Grant Likely
> wrote:
> > On Tue, May 26, 2009 at 5:30 AM, Esben Haabendal wrote:
> >> On Tue, May 19, 2009 at 7:22 AM, Esben Haabendal wrote:
> >>> This fixes MAL (arbitration lost) bug caused by
wael showair wrote:
> Hi All,
> i have board that contains MPC8555 processor with linux 2.6.27 ported to it.
> i want to use an accurate function to measure the time. i searched the
> kernel code & i found several functions but i read that the do_gettimeofday
> is the most accurate one since it has
Am 01.06.09 08:14 schrieb(en) Joakim Tjernlund:
.. not even 4.2.2 which is fairly modern will get it right. It breaks
very easy as gcc has never been any good at this type of
optimization. Sometimes small changes will make gcc unhappy and it
won't do the right optimization.
It's even worse
On Wed, May 06, 2009 at 06:40:07PM +0800, Dave Liu wrote:
> Freescale eSDHC controller has the special order for
> the HOST version register. that is not same as the other's
> registers. The address of HOSTVER in spec is 0xFE, and
> we need use the in_be16(0xFE) to access it, not in_be16(0xFC).
>
Hi Stefan,
On Tue, Jun 02, 2009 at 07:02:25PM +0200, Stefan Strobl wrote:
> Hi
> I still don't quite understand how to use the Flattened Device Tree /
> Open Firmware. I see there's a driver (mpc52xx_gpt.c) that supports to
> use the Pins on the GPT as simple GPIOs. I activated it by adding these
Hi
I still don't quite understand how to use the Flattened Device Tree /
Open Firmware. I see there's a driver (mpc52xx_gpt.c) that supports to
use the Pins on the GPT as simple GPIOs. I activated it by adding these
lines to my dts file:
gpt2: ti...@620 {
compatible = "fsl,mpc5200b-gpt-gpi
Signed-off-by: Haiying Wang
---
arch/powerpc/boot/dts/mpc8569mds.dts | 63 ++
1 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8569mds.dts
b/arch/powerpc/boot/dts/mpc8569mds.dts
index 39c2927..4e95abd 100644
--- a/arch/pow
Signed-off-by: Haiying Wang
---
arch/powerpc/include/asm/qe.h |2 +
drivers/net/ucc_geth.c| 79 -
drivers/net/ucc_geth.h| 28 ++-
3 files changed, 107 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/q
Current code makes the UCC whose register range includes the current mdio
register to be the MII managemnt interface master of the QE. If there is more
than one mdio bus for QE, the UCC of the last mdio bus will be the MII
management interface master which will make the primary mdio bus working
unp
Disable fiber/copper auto selection for Marvell m88e SGMII support.
Signed-off-by: Haiying Wang
---
drivers/net/phy/marvell.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 7a3ec9d..dd6f54d 100644
--- a/dri
On Mon, 2009-06-01 at 02:51 -0700, David Miller wrote:
> Patch 3 of this series doesn't apply cleanly to net-next-2.6
> so I'm dropping the entire patch set.
> Also, in patch 3 you put your signoff in the Subject line.
>
> Please fix all of this up and resubmit your patch series.
I only verified
Hi all,
In a normal situation, I have something like this:
serial8250_interrupt()
serial8250_handle_port()
transmit_chars()
pass_counter: 0
serial8250_handle_port()
pass_counter: 1
serial8250_handle_port()
pass_counter: 2
pass_counter: 3
But when the problem happends:
serial8250_interrupt(16)
On Tue, 2009-06-02 at 11:49 +0100, Arnd Bergmann wrote:
> On Tuesday 02 June 2009, Benjamin Herrenschmidt wrote:
> > --- linux-work.orig/arch/powerpc/platforms/Kconfig.cputype 2009-06-02
> > 16:29:27.0 +1000
> > +++ linux-work/arch/powerpc/platforms/Kconfig.cputype 2009-06-02
> > 1
Hi
I'm using the i2c/chips/tsl2550 driver. In the tsl2550_probe() function
the driver checks for platform data to set the operating_mode. I suppose
I can provide this data in my dts file but I don't know how to do that.
Currently my dts looks like this:
tsl2...@39 {
compatible = "taos,tsl2
On Tuesday 02 June 2009, Benjamin Herrenschmidt wrote:
> --- linux-work.orig/arch/powerpc/platforms/Kconfig.cputype2009-06-02
> 16:29:27.0 +1000
> +++ linux-work/arch/powerpc/platforms/Kconfig.cputype 2009-06-02
> 16:55:01.0 +1000
> @@ -9,7 +9,6 @@ menu "Processor support"
>
On Tue, 2009-06-02 at 17:50 +1000, Benjamin Herrenschmidt wrote:
> +#ifdef CONFIG_PPC_BOOK3S
> +#include "exceptions-64s.S"
> #endif
Patches are in the wrong order ... the symbol above is only
define by patch 3/5 :-)
I'll flip the around before mering if there's no other comment.
Cheers,
Ben.
Stephen Rothwell wrote:
Fixes a couple of warnings like this one:
WARNING: arch/powerpc/kvm/kvm-440.o(.text+0x1e8c): Section mismatch in
reference from the function kvmppc_44x_exit() to the function
.exit.text:kvmppc_booke_exit()
The function kvmppc_44x_exit() references a function in an exit
This is a random collection of added ifdef's around portions of
code that only mak sense on server processors. Using either
CONFIG_PPC_STD_MMU_64 or CONFIG_PPC_BOOK3S as seems appropriate.
This is meant to make the future merging of Book3E 64-bit support
easier.
Signed-off-by: Benjamin Herrenschm
This patch has no effect other than re-ordering PACA fields on
current server CPUs. It however is a pre-requisite for future
support of BookE 64-bit processors. Various parts of the PACA
struct are now moved under some ifdef's, either the new
CONFIG_PPC_BOOK3S or CONFIG_PPC_STD_MMU_64, whatever see
This patch introduce a new Kconfig option, CONFIG_PPC_BOOK3S
that represents processors that are compliant with the "classic"
(aka "server") variant of the PowerPC architecture.
It replaces CONFIG_6xx on 32-bit (though the symbol is still
defined for compatibility) and encompass all currently supp
To prepare for future support of Book3E 64-bit PowerPC processors,
which use a completely different exception handling, we move that
code to a new exceptions-64s.S file.
This file is #included from head_64.S due to some of the absolute
address requirements which can currently only be fulfilled fro
Currently, load_up_altivec and give_up_altivec are duplicated
in 32-bit and 64-bit. This creates a common implementation that
is moved away from head_32.S, head_64.S and misc_64.S and into
vector.S, using the same macros we already use for our common
implementation of load_up_fpu.
I also moved the
These are a few patches that are extracted or cleaned up from
the current 64-bit Book3E support pile and that could be merged
already in 2.6.31 to make subsequent patches easier to maintain
and apply.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
36 matches
Mail list logo
