> Again, how would 'cr' obtain exit status for these tasks, and how would
> it distinguish failure from normal operation?
Here's our solution to this issue.
mcr maintains in its kernel container object an exitcode attribute for
the mcr-restart process. This process is detached from the fork tree
From: Grant Likely
Method used to set CPU_FTR_NEED_COHERENT was unfriendly for multiplatform
kernels. This patch cleans it up.
Signed-off-by: Grant Likely
---
I haven't even compile tested this. But I want to see if there are any
objections before I do the legwork.
g.
arch/powerpc/include
On Mon, Mar 16, 2009 at 9:54 PM, Grant Likely wrote:
> On Mon, Mar 16, 2009 at 4:05 AM, Piotr Ziecik wrote:
>> BestComm, a DMA engine in MPC52xx SoC, requires snooping when
>> CPU caches are enabled to work properly.
>>
>> Adding CPU_FTR_NEED_COHERENT fixes NFS problems on MPC52xx machines
>> int
On Mon, Mar 16, 2009 at 4:05 AM, Piotr Ziecik wrote:
> BestComm, a DMA engine in MPC52xx SoC, requires snooping when
> CPU caches are enabled to work properly.
>
> Adding CPU_FTR_NEED_COHERENT fixes NFS problems on MPC52xx machines
> introduced by 'powerpc/mm: Fix handling of _PAGE_COHERENT in BAT
On Mon, Mar 16, 2009 at 10:32:18AM +, Martyn Welch wrote:
> Support for the PPC9A VME Single Board Computer from GE Fanuc (PowerPC
> MPC8641D).
>
> This is the basic board support for GE Fanuc's PPC9A, a 6U single board
> computer, based on Freescale's MPC8641D.
Uh.. sorry. Should have notic
Hi all,
The latest RT patch "patch-2.6.29-rc6-rt3" is throwing following compilation
errors for POWERPC linux kernel 2.6.29-rc6 :-
As I used plain vanilla kernel i.e -> Linux-2.6.28 + patch-2.6.29-rc6 +
patch-2.6.29-rc6-rt3
While compiling for ppc440...
[r...@srikanth linux-2.6.29-rc6]# make
On Wed, Mar 11, 2009 at 11:00 AM, Greg KH wrote:
> On Wed, Mar 11, 2009 at 10:35:29AM -0600, Grant Likely wrote:
>> On Wed, Mar 11, 2009 at 10:26 AM, Greg KH wrote:
>> > On Fri, Mar 06, 2009 at 09:10:19AM -0700, Grant Likely wrote:
>> >> From: Grant Likely
>> >>
>> >> bus_register_notifier_allde
Complete workaround for DTLB errata in e300c2/c3/c4 processors.
Due to the bug, the hardware-implemented LRU algorythm always goes to way
1 of the TLB. This fix implements the proposed software workaround in
form of a LRW table for chosing the TLB-way.
Based on patch from David Jander
Signed-of
Now that r0 is free we can keep the value of I/DMISS in r3 and not reload
it before doing the tlbli/d. This saves us a few cycles in the fast path
case.
Signed-off-by: Kumar Gala
---
arch/powerpc/kernel/head_32.S | 51 +++-
1 files changed, 24 insertions(+)
Long ago we had some code that actually used the CTR in the SW TLB
miss handlers (603/e300). Since we don't use it no reason to waste
cycles saving it off and restoring it (we actually didn't restore it
in the fast path case).
Signed-off-by: Kumar Gala
---
arch/powerpc/kernel/head_32.S | 11 +
Since we now set _PAGE_COHERENT in the Linux PTE we shouldn't be clearing
it out before we setup the SW TLB. Today all the SW TLB machines
(603/e300) that we support are non-SMP, however there are some errata on
some devices that cause us to set _PAGE_COHERENT via CPU_FTR_NEED_COHERENT.
Signed-of
This patch adds a new driver: sdhci-of. The driver is similar to
the sdhci-pci, it contains common probe code, and controller-specific
ops and quirks.
So far there are only Freescale eSDHC ops and quirks.
Signed-off-by: Anton Vorontsov
Acked-by: Arnd Bergmann
---
MAINTAINERS |
FSL eSDHC controllers can support maximum block size up to 4096 bytes,
the MBL (Maximum Block Length) field in the capabilities register
extended by one bit, and is set to 0x3.
But the SDHCI core doesn't support blocks of 4096 bytes, and thus
forces blksz to the lowest value -- 512 bytes. With thi
FSL eSDHC controllers losing signal/interrupt enable states after
reset, so we should re-enable them.
Signed-off-by: Anton Vorontsov
---
drivers/mmc/host/sdhci.c |7 +++
drivers/mmc/host/sdhci.h |2 ++
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sd
Small udelay is needed to make eSDHC work in PIO mode. Without
the delay reading causes endless interrupt storm, and writing
corrupts data. The first guess would be that we must wait for
some bit in some register, but I didn't find any reliable bits
that change before and after the delay.
Signed-o
FSL eSDHC hosts have incompatible register map to manage the SDCLK.
This patch adds set_clock callback so that drivers could overwrite
set_clock behaviour.
Similar patch[1] was posted by Ben Dooks, though in Ben's version the
callback is named change_clock, plus the patch has some unrelated bits
t
From: Ben Dooks
Some controllers do not provide clock information in their capabilities
(in the Samsung case, it is because there are multiple clock sources
available to the controller). Add hooks to allow the system to supply
clock information.
p.s.
In the original Ben's patch there was a bug t
This patch adds SDHCI_QUIRK_INVERTED_WRITE_PROTECT quirk. When
specified, the sdhci driver will invert WP state.
p.s. Actually, the quirk is more board-specific than
controller-specific.
Signed-off-by: Anton Vorontsov
---
drivers/mmc/host/sdhci.c |2 ++
drivers/mmc/host/sdhci.h |2
This patch adds SDHCI_QUIRK_BROKEN_CARD_DETECTION quirk. When specified,
sdhci driver will set MMC_CAP_NEEDS_POLL MMC host capability, and won't
enable card insert/remove interrupts.
This is needed for hosts with unreliable card detection, such as FSL
eSDHC. The original eSDHC driver was tring to
Some hosts (that is, FSL eSDHC) throw PIO interrupts during DMA
transfers, this causes tons of unneeded interrupts, and thus highly
degraded speed.
This patch modifies the driver so that now we only enable relevant
(DMA or PIO) interrupts during transfers.
Signed-off-by: Anton Vorontsov
---
dri
Card detection interrupts should be handled separately as they should
not be enabled before mmc_add_host() returns and should be disabled
before calling mmc_remove_host(). The same is for suspend and resume
routines.
sdhci_init() no longer enables card-detection irqs. Instead, two new
functions im
Currently the SDHCI driver works with PCI accessors (write{l,b,w} and
read{l,b,w}).
With this patch drivers may change memory accessors, so that we can
support hosts with "weird" IO memory access requirments.
For example, in "FSL eSDHC" SDHCI hardware all registers are 32 bit
width, with big-endi
Hi all,
Here comes another version, let's hope that one is final. ;-)
Changes since v2:
- Introduced MMC_SDHCI_IO_ACCESSORS Kconfig symbol. If not selected,
SDHCI will just use PCI memory accessors unconditionally.
- Added MAINTAINERS entry.
Changes since v1:
- "Add support for bus-specific IO
On Sun, Mar 08, 2009 at 03:11:21PM +0100, Pierre Ossman wrote:
> On Wed, 4 Mar 2009 20:49:17 +0300
> Anton Vorontsov wrote:
>
> > On Sat, Feb 21, 2009 at 04:58:21PM +0100, Pierre Ossman wrote:
> > > Just modify the if-clause and
> > > things will work.
> >
> > That would look horrid...
> >
> >
Commit-ID: a6bc3262c561780d2a6587aa3d5715b1e7d8fa13
Gitweb: http://git.kernel.org/tip/a6bc3262c561780d2a6587aa3d5715b1e7d8fa13
Author: Stephen Rothwell
AuthorDate: Mon, 16 Mar 2009 18:52:56 +1100
Commit: Ingo Molnar
CommitDate: Mon, 16 Mar 2009 09:21:57 +0100
sparseirq, powerpc/cell
Oren Laadan wrote:
>
> Nathan Lynch wrote:
> > Nathan Lynch wrote:
> >> Oren Laadan wrote:
> >>> Nathan Lynch wrote:
> What doesn't work:
> * restarting a 32-bit task from a 64-bit task and vice versa
> >>> Is there a test to bail if we attempt to checkpoint such tasks ?
> >> No, but I
On Mar 16, 2009, at 10:52 AM, David Jander wrote:
Complete workaround for DTLB errata in e300c2/c3/c4 processors.
Due to the bug, the hardware-implemented LRU algorythm always goes
to way
1 of the TLB. This fix implements the proposed software workaround in
form of a LRW table for chosing t
On Mar 16, 2009, at 11:09 AM, David Jander wrote:
In this patch, I placed the LRW table in SPRG6 like before, but
Kumar's code
seems a little more compact, so I decided to use that one and fix
it ;-)
It's a pity we seem to have one register short in the handler, so we
need to
load SPR
arch/powerpc/platforms/52xx/mpc52xx_gpt.c: In function
'mpc52xx_gpt_create_attribs':
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:373: error: parameter name omitted
arch/powerpc/platforms/52xx/mpc52xx_gpt.c:373: warning: 'return' with a value,
in function returning void
Signed-off-by: Alexander Ber
On Mon, 2009-03-16 at 16:52 +0100, David Jander wrote:
> Complete workaround for DTLB errata in e300c2/c3/c4 processors.
>
> Due to the bug, the hardware-implemented LRU algorythm always goes to way
> 1 of the TLB. This fix implements the proposed software workaround in
> form of a LRW table for c
On Mon, Mar 16, 2009 at 10:17 AM, Alexander Beregalov
wrote:
> arch/powerpc/platforms/52xx/mpc52xx_gpt.c: In function
> 'mpc52xx_gpt_create_attribs':
> arch/powerpc/platforms/52xx/mpc52xx_gpt.c:373: error: parameter name omitted
> arch/powerpc/platforms/52xx/mpc52xx_gpt.c:373: warning: 'return' w
In this patch, I placed the LRW table in SPRG6 like before, but Kumar's code
seems a little more compact, so I decided to use that one and fix it ;-)
It's a pity we seem to have one register short in the handler, so we need to
load SPRN_SRR1 twice :-(
Allthough the code-path now has 1 instruct
Complete workaround for DTLB errata in e300c2/c3/c4 processors.
Due to the bug, the hardware-implemented LRU algorythm always goes to way
1 of the TLB. This fix implements the proposed software workaround in
form of a LRW table for chosing the TLB-way.
Signed-off-by: Kumar Gala
Signed-off-by: Da
Thanks, I don't see any mdev process running.
Just wonder who is creating /dev/ttyCPM1 since in the device table file
(device_table.txt)
I have only node: 204 (major) 46 (minor) defined.
But I can see /dev/ttyCPM1 (204 47)
Liran.
On Fri, Mar 13, 2009 at 4:18 PM, Timur Tabi wrote:
> On Fri, Mar 1
On Mar 16, 2009, at 10:06 AM, Kumar Gala wrote:
On Mar 16, 2009, at 10:02 AM, David Jander wrote:
Ok, I was analysing your code (which seems much more compact than
mine):
On Monday 16 March 2009 14:02:18 Kumar Gala wrote:
[...]
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/ker
On Mar 16, 2009, at 10:02 AM, David Jander wrote:
Ok, I was analysing your code (which seems much more compact than
mine):
On Monday 16 March 2009 14:02:18 Kumar Gala wrote:
[...]
--- a/arch/powerpc/kernel/head_32.S
+++ b/arch/powerpc/kernel/head_32.S
@@ -587,9 +587,19 @@ DataLoadTLBMiss:
Ok, I was analysing your code (which seems much more compact than mine):
On Monday 16 March 2009 14:02:18 Kumar Gala wrote:
>[...]
> --- a/arch/powerpc/kernel/head_32.S
> +++ b/arch/powerpc/kernel/head_32.S
> @@ -587,9 +587,19 @@ DataLoadTLBMiss:
> ori r1,r1,0xe04 /* clear o
Hehe, and that opens up an entirely different can of worms with our board.
Thanks, however.
Mark
Benjamin Herrenschmidt wrote:
On Fri, 2009-03-13 at 16:42 -0600, Mark Takatz wrote:
Ben,
We're looking at the fixes you put in place for the various PCI errors
and we think this is the soluti
Ooops, ok I think I just missed your proposal, Kumar.
Anyway, I'll post my benchmark results to this here:
1.- mplayer -nosound -benchmark testfile.mpeg (a DVD-mpeg2 file):
No fix at all:
VC: 30.5s VO: 53.4s Sys:1.95s Total: 85.8s
First fix (force writes to way 0):
VC: 24.3s VO: 40.6s Sys:1.95
Complete workaround for DTLB errata in MPC5121e processors of die M36P and
older (all currently existing versions).
Due to the bug, the hardware-implemented LRU algorythm always goes to way 1 of
the TLB. This fix implements the proposed software workaround in form of a LRW
table encoded in 32 b
On Mon, Mar 09, 2009 at 02:26:20PM +0100, Geert Uytterhoeven wrote:
> The rtc-parisc driver is not PA-RISC specific at all, as it uses the existing
> (but deprecated) generic RTC infrastructure ([gs]et_rtc_time()).
> Rename the driver from rtc-parisc to rtc-generic.
Maybe it should be called rtc-l
Complete workaround for DTLB errata in e300c2/c3/c4 processors.
Due to the bug, the hardware-implemented LRU algorythm always goes to way
1 of the TLB. This fix implements the proposed software workaround in
form of a LRW table for chosing the TLB-way.
Based on patch from David Jander
Signed-of
Using the RTAS watchdog driver to read out the temperature crashes
on a PXCAB:
Unable to handle kernel paging request for data at address 0xfe347b50
Faulting instruction address: 0xc001af64
Oops: Kernel access of bad area, sig: 11 [#1]
This (removing "(void *)__pa") fixes it.
Signed-off
On Mar 13, 2009, at 5:06 PM, Kumar Gala wrote:
On Mar 13, 2009, at 4:26 PM, Benjamin Herrenschmidt wrote:
+BEGIN_FTR_SECTION
+ b TlbWo/* Code for TLB-errata workaround doesn't fit
here */
+END_FTR_SECTION_IFSET(CPU_FTR_NEED_DTLB_SW_LRU)
+RFTlbWo:
Can you use nicer label names ?
Now that r0 is free we can keep the value of I/DMISS in r3 and not reload
it before doing the tlbli/d. This saves us a few cycles in the fast path
case.
Signed-off-by: Kumar Gala
---
There might be better uses of the free r0 to save more cycles in these code
paths.
If anyone has suggestions I'
Long ago we had some code that actually used the CTR in the SW TLB
miss handlers (603/e300). Since we don't use it no reason to waste
cycles saving it off and restoring it (we actually didn't restore it
in the fast path case).
Signed-off-by: Kumar Gala
---
Note: I've only compiled tested this an
Since we now set _PAGE_COHERENT in the Linux PTE we shouldn't be clearing
it out before we setup the SW TLB. Today all the SW TLB machines
(603/e300) that we support are non-SMP, however there are some errata on
some devices that cause us to set _PAGE_COHERENT via CPU_FTR_NEED_COHERENT.
Signed-of
On Mar 16, 2009, at 5:44 AM, David Jander wrote:
On Friday 13 March 2009 16:23:15 Kumar Gala wrote:
[...]
This errata impacts a number of cores and so we should make this a
CPU
feature fixup rather than #ifdef code.
It should impact only MPC5121e and probably MPC5123, but according
to
Fr
On Sat, Mar 14, 2009 at 02:49:02PM +0100, Segher Boessenkool wrote:
>> Another option might be simply to say that if an app has used FP, VMX
>> or
>> VSX -once-, then it's likely to do it again and just keep re-enabling
>> it :-)
>>
>> I'm serious here, do we know that many cases where these thing
On Friday 13 March 2009 16:23:15 Kumar Gala wrote:
>[...]
> >> This errata impacts a number of cores and so we should make this a
> >> CPU
> >> feature fixup rather than #ifdef code.
> >
> > It should impact only MPC5121e and probably MPC5123, but according to
> > Freescale no other processors that
Support for the PPC9A VME Single Board Computer from GE Fanuc (PowerPC
MPC8641D).
This is the default config file for GE Fanuc's PPC9A, a 6U single board
computer, based on Freescale's MPC8641D.
Signed-off-by: Martyn Welch
---
arch/powerpc/configs/86xx/gef_ppc9a_defconfig | 1889 ++
Support for the PPC9A VME Single Board Computer from GE Fanuc (PowerPC
MPC8641D).
This is the basic board support for GE Fanuc's PPC9A, a 6U single board
computer, based on Freescale's MPC8641D.
Signed-off-by: Martyn Welch
---
v2: Corrections to DTS (soc compatible, remove device_type) as sugge
The following series implements basic support for the GE Fanuc PPC9A, a
6U single board computer, based on the Freescale MPC8641D.
This series provides:
- The ability to boot the board with a serial console.
- Ethernet support.
- Sata and USB.
- Support for one of the 2 available watchdog time
BestComm, a DMA engine in MPC52xx SoC, requires snooping when
CPU caches are enabled to work properly.
Adding CPU_FTR_NEED_COHERENT fixes NFS problems on MPC52xx machines
introduced by 'powerpc/mm: Fix handling of _PAGE_COHERENT in BAT setup code'.
Signed-off-by: Piotr Ziecik
---
This patch was
Original-Nachricht
> Datum: Mon, 16 Mar 2009 09:18:54 +0100
> Von: "Roderick Colenbrander"
> An: "Gerhard Pircher" , linuxppc-dev@ozlabs.org
> Betreff: Re: DTS file PCI / i8259 for Xilinx ML510
>
> Original-Nachricht
> > Datum: Sun, 15 Mar 2009 11:43:13 +0100
Enable highmem support for the TQM8548-AG modules and NAND support for
the TQM8548-BE modules. Furthermore disable USB, Wireless and IDE support
because it's not available on the STK85xx starter kit.
Signed-off-by: Wolfgang Grandegger
---
arch/powerpc/configs/85xx/tqm8548_defconfig | 164 ++
For enet2 and enet3 the wrong phy-handles have been used in DTS files
of the TQM8548 modules.
Signed-off-by: Wolfgang Grandegger
---
arch/powerpc/boot/dts/tqm8548-bigflash.dts |4 ++--
arch/powerpc/boot/dts/tqm8548.dts |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
d
Commit 0f73a449a649acfca91404a98a35353a618b9555 added I2C device nodes
for the LM75 thermal sensor on the TQM85xx modules, unfortunately with
the wrong I2C address. The LM75s are located at address 0x48.
Signed-off-by: Wolfgang Grandegger
---
arch/powerpc/boot/dts/tqm8540.dts |4 ++-
The following patch series fixes some issues with the DTS files of the
TQM85xx modules and the defconfig for the TQM8548 modules.
The patches are against the "next" branch of Kumar's "powerpc" GIT tree.
Wolfgang.
___
Linuxppc-dev mailing list
Linuxppc-d
Original-Nachricht
> Datum: Sun, 15 Mar 2009 11:43:13 +0100
> Von: "Gerhard Pircher"
> An: "Roderick Colenbrander" , linuxppc-dev@ozlabs.org
> Betreff: Re: DTS file PCI / i8259 for Xilinx ML510
>
> Original-Nachricht
> > Datum: Sun, 15 Mar 2009 09:38:26 +0100
arch/powerpc/platforms/cell/interrupt.c: In function 'handle_iic_irq':
arch/powerpc/platforms/cell/interrupt.c:240: warning: unused variable 'cpu'
Signed-off-by: Stephen Rothwell
---
arch/powerpc/platforms/cell/interrupt.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
On Mon, 2 F
61 matches
Mail list logo
