On 06/17/2011 10:02 AM, Benjamin Herrenschmidt wrote:
On Tue, 2011-06-07 at 22:00 +0530, Trinabh Gupta wrote:
diff --git a/arch/powerpc/kernel/idle.c b/arch/powerpc/kernel/idle.c
index 39a2baa..932392b 100644
--- a/arch/powerpc/kernel/idle.c
+++ b/arch/powerpc/kernel/idle.c
@@ -102,6 +102,24
On 06/17/2011 09:59 AM, Benjamin Herrenschmidt wrote:
On Tue, 2011-06-07 at 21:59 +0530, Trinabh Gupta wrote:
From: Len Brown
useful for disabling cpuidle to fall back
to architecture-default idle loop
cpuidle drivers and governors will fail to register.
on x86 they'll say so:
intel_idle: i
On Mon, 2011-06-20 at 22:48 +0530, deepthi wrote:
> On Friday 17 June 2011 09:54 AM, Benjamin Herrenschmidt wrote:
> > On Wed, 2011-06-01 at 18:05 +0530, Deepthi Dharwar wrote:
> >> Hi,
> >>
> >> Please find below a patch, which has perf_events added for pseries (ppc64)
> >> platform in order to em
On Friday 17 June 2011 09:54 AM, Benjamin Herrenschmidt wrote:
> On Wed, 2011-06-01 at 18:05 +0530, Deepthi Dharwar wrote:
>> Hi,
>>
>> Please find below a patch, which has perf_events added for pseries (ppc64)
>> platform in order to emit the trace required for perf timechart.
>> It essentially e
This patch fixes the freescale spi driver for CPM. Without this
patch SPI on CPM failed because cpm_muram_alloc_fixed tries to
allocate muram in an preserved area. The error reported was:
mpc8xxx_spi f0011a80.spi: can't allocate spi parameter ram
mpc8xxx_spi: probe of f0011a80.spi failed with erro
On Sat, 18 Jun 2011 08:58:53 +1000
Benjamin Herrenschmidt wrote:
> On Fri, 2011-06-17 at 11:58 -0500, Scott Wood wrote:
> > When did this change from "considered an internal implementation
> > issue, and not really an interface" to "all new interfaces"?
>
> Interesting blurb... that's not everyb
On Fri, Jun 17, 2011 at 5:34 PM, Scott Wood wrote:
>
> As for the corruption, could it be degradation from repeated reads of that
> one page?
>
Could be. I think Mike's theory was that the -1 page_addr sort of
"wrapped around", and caused us to read in the last block on flash
each time NAND_CMD_
Mike:
> It is not a permanent damage thing.
A "read disturb" does no permanent damage to the chip
but if the read disturb event involves more bits than
can be corrected by your ECC code, it can do permanent
damage to the *DATA* you've stored in that block.
For this reason, a good flash
