> From: Gala Kumar-B11780
> Sent: Thursday, November 19, 2009 7:51 PM
> > + * Cache SRAM handling for QorIQ platform
>
> should say PQ3 & some QorIQ platforms
Ok
>
> > +config FSL_85XX_CACHE_SRAM_BASE
> > + hex
> > + depends on FSL_85XX_CACHE_SRAM
> > + default "0xfff0"
> > +
>
> I
>-Original Message-
>From: Kumar Gala [mailto:ga...@kernel.crashing.org]
>
>On Nov 17, 2009, at 1:10 AM, Li Yang wrote:
>
>> Rather than the original intelligent way, we grant user more freedom.
>> This enables user to map cacheable memory not managed by Linux.
>>
>> Signed-off-by: Li Y
Some unused, unsupported debug code existed in the mpc85xx EDAC driver
that resulted in a build failure when CONFIG_EDAC_DEBUG was defined:
drivers/edac/mpc85xx_edac.c: In function 'mpc85xx_mc_err_probe':
drivers/edac/mpc85xx_edac.c:1031: error: implicit declaration of function
'edac_mc_regis
Add the ability to detect the specific data line or ECC line which
failed when printing out SDRAM single-bit errors. An example of a
single-bit SDRAM ECC error is below:
EDAC MPC85xx MC1: Err Detect Register: 0x8004
EDAC MPC85xx MC1: Faulty data bit: 59
EDAC MPC85xx MC1: Expected Data /
Commit b4846251727a38a7f248e41308c060995371dd05 accidentally broke how a
chip select's first and last page addresses are calculated. The page
addresses are being shifted too far right by PAGE_SHIFT. This results
in errors such as:
EDAC MPC85xx MC1: Err addr: 0x003075c0
EDAC MPC85xx MC1: PFN:
With a 64-bit wide data bus only the lowest 8-bits of the ECC syndrome
are relevant. With a 32-bit wide data bus only the lowest 16-bits are
relevant on most architectures.
Without this change, the ECC syndrome displayed can be mildly confusing,
eg:
EDAC MPC85xx MC1: syndrome: 0x25252525
When
On Wed, 18 Nov 2009 12:59:08 -0600
Robert Jennings wrote:
> The Collaborative Memory Manager (CMM) module allocates individual pages
> over time that are not migratable. On a long running system this can
> severely impact the ability to find enough pages to support a hotplug
> memory remove oper
On 07/01/2009 11:29 AM, ashish kalra wrote:
Enable device hot-plug support on Port multiplier fan-out ports
v3 fixes whitespace/identation issues
Signed-off-by: Ashish Kalra
---
drivers/ata/sata_fsl.c | 15 ++-
1 files changed, 10 insertions(+), 5 deletions(-)
applied #upstream
_
On 10/16/2009 12:44 PM, Anton Vorontsov wrote:
From: Jiang Yutang
Split sata_fsl_softreset() into hard and soft resets to make
error-handling more efficient& device and PMP detection more
reliable.
Also includes fix for PMP support, driver tested with Sil3726,
Sil4726& Exar PMP controllers.
On Thu, 2009-11-19 at 08:08 -0800, Felix Radensky wrote:
> Hi,
>
> The problem goes away if I remove the call to
>
> tg3_set_power_state(tp, PCI_D3hot);
>
> from tg3_close().
Added Matt to CC. He is on vacation and may not be able to look into
this right away. Thanks.
On 11/19/2009 01:44 AM, Thomas Gleixner wrote:
> The typename member of struct irq_chip was kept for migration purposes
> and is obsolete since more than 2 years. Fix up the leftovers.
> Index: linux-2.6-tip/arch/powerpc/platforms/ps3/interrupt.c
> =
Hey there-
Before anyone flames me for what a oddball solution this is, let me just
say I'm trying to get the ball rolling here. I think there may be better
solutions that can be impemented in reloc_64.S, but I've yet to make any of the
ones I've tried work successfully. I'm open to sugge
On Nov 19, 2009, at 11:45 AM, Scott Wood wrote:
On Thu, Nov 19, 2009 at 08:29:19AM -0600, Kumar Gala wrote:
+config FSL_85XX_CACHE_SRAM_BASE
+ hex
+ depends on FSL_85XX_CACHE_SRAM
+ default "0xfff0"
+
I really don't like setting the physical address this way, can we
not
NAK also.
Yes we can generate a different device tree to fix this issue.
Thanks,
John
> -Original Message-
> From: Stephen Neuendorffer
> Sent: Thursday, November 19, 2009 10:23 AM
> To: Alon Ziv; Arnd Bergmann; linuxppc-dev@lists.ozlabs.org
> Cc: John Linn; grant.lik...@secretlab.ca
> S
> -Original Message-
> From: linuxppc-dev-bounces+stephen=neuendorffer.n...@lists.ozlabs.org
[mailto:linuxppc-dev-
> bounces+stephen=neuendorffer.n...@lists.ozlabs.org] On Behalf Of Alon
Ziv
> Sent: Thursday, November 19, 2009 4:57 AM
> To: Stephen Neuendorffer; linuxppc-dev
> Cc: John Li
On Thu, Nov 19, 2009 at 08:29:19AM -0600, Kumar Gala wrote:
> >>+config FSL_85XX_CACHE_SRAM_BASE
> >>+ hex
> >>+ depends on FSL_85XX_CACHE_SRAM
> >>+ default "0xfff0"
> >>+
> >
> >I really don't like setting the physical address this way, can we
> >not do this via the device tree?
>
>
> -Original Message-
> From: linuxppc-dev-bounces+stephen=neuendorffer.n...@lists.ozlabs.org
[mailto:linuxppc-dev-
> bounces+stephen=neuendorffer.n...@lists.ozlabs.org] On Behalf Of Arnd
Bergmann
> Sent: Thursday, November 19, 2009 9:33 AM
> To: Stephen Neuendorffer
> Cc: John Linn; Alon
On Wed, Nov 18, 2009 at 03:53:27PM -0800, Ming Lei wrote:
>
> I used the vanilla linux 2.6.30 and compiled with mpc85xx_defconfig(enable
> CONFIG_BOOK_WDT) and then ran on 8548CDS and soon after I saw the prompt I
> hit this watchdog.
>
> bash-2.04# PowerPC Book-E Watchdog Exception
> NIP: c00
On Thursday 19 November 2009, Stephen Neuendorffer wrote:
> If the problem is in the device trees that are being generated, we
> should fix the issue there.
> We've been trying to avoid putting the fully specified IP versions in
> the kernel like this, since
> the IP changes so often.
No, the prob
NAK.
If the problem is in the device trees that are being generated, we
should fix the issue there.
We've been trying to avoid putting the fully specified IP versions in
the kernel like this, since
the IP changes so often.
Steve
> -Original Message-
> From: linuxppc-dev-bounces+stephen=
> -Original Message-
> From: linuxppc-dev-bounces+stephen=neuendorffer.n...@lists.ozlabs.org
[mailto:linuxppc-dev-
> bounces+stephen=neuendorffer.n...@lists.ozlabs.org] On Behalf Of Alon
Ziv
> Sent: Thursday, November 19, 2009 4:47 AM
> To: Arnd Bergmann; linuxppc-dev@lists.ozlabs.org
> S
Hi,
The problem goes away if I remove the call to
tg3_set_power_state(tp, PCI_D3hot);
from tg3_close().
Some relevant stuff from dmesg:
pci 0002:05:00.0: PME# supported from D3hot D3cold
pci 0002:05:00.0: PME# disabled
tg3.c:v3.102 (September 1, 2009)
tg3 0002:05:00.0: enabling device ( -
On Thu, Nov 19, 2009 at 03:09:31PM +0100, Arnd Bergmann wrote:
> On Thursday 19 November 2009, Alon Ziv wrote:
> > On Thursday, November 19, 2009, Arnd Bergmann wrote:
> > > I'd still add support for the compatible="ns16550a" property
> > > so that we do the right thing for future systems.
> > >
>
Hi,
I have a problem with tg3 driver on a custom MPC8536 based board
running linux-2.6.31, with tg3 and Broadcom phy drivers taken from
linux-2.6.32-rc7. Broadcom NIC is BCM57760, phy is BCM57780.
The problem I'm seeing is that the downing and interface leads to
permanent link loss, even after i
On Nov 19, 2009, at 8:45 AM, Josh Boyer wrote:
On Wed, Nov 04, 2009 at 01:55:19PM -0500, Josh Boyer wrote:
Hi Ben,
Please pull the next branch of the 4xx tree to get the following
commits.
I have some other things in the middle of being worked that may or
may not
make it in time for the
On Wed, Nov 04, 2009 at 01:55:19PM -0500, Josh Boyer wrote:
>Hi Ben,
>
>Please pull the next branch of the 4xx tree to get the following commits.
>
>I have some other things in the middle of being worked that may or may not
>make it in time for the next release, so I wanted to get these commits int
On Nov 19, 2009, at 8:21 AM, Kumar Gala wrote:
diff --git a/arch/powerpc/platforms/85xx/Kconfig b/arch/powerpc/
platforms/85xx/Kconfig
index d3a975e..b6f23c3 100644
--- a/arch/powerpc/platforms/85xx/Kconfig
+++ b/arch/powerpc/platforms/85xx/Kconfig
@@ -144,6 +144,15 @@ config SBC8560
h
On Oct 21, 2009, at 7:50 AM, Vivek Mahajan wrote:
This adds QorIQ based Cache-SRAM support as under:-
* A small abstraction over powerpc's remote heap allocator
* Exports mpc85xx_cache_sram_alloc()/free() APIs
* Supports only one contiguous SRAM window
* Defines FSL_85XX_CACHE_SRAM and its bas
On Thursday 19 November 2009, Alon Ziv wrote:
> On Thursday, November 19, 2009, Arnd Bergmann wrote:
> > I'd still add support for the compatible="ns16550a" property
> > so that we do the right thing for future systems.
> >
>
> OK...
> ---
> Xilinx 16550 UART is actually 16550A-compatible
>
> Si
On Nov 19, 2009, at 7:51 AM, Kumar Gala wrote:
On Nov 5, 2009, at 9:02 AM, Kumar Gala wrote:
On Oct 16, 2009, at 11:44 AM, Anton Vorontsov wrote:
From: Jiang Yutang
Split sata_fsl_softreset() into hard and soft resets to make
error-handling more efficient & device and PMP detection more
On Nov 17, 2009, at 1:10 AM, Li Yang wrote:
Rather than the original intelligent way, we grant user more freedom.
This enables user to map cacheable memory not managed by Linux.
Signed-off-by: Li Yang
---
The only direct users of this function is fb_mmap() and /dev/mem mmap.
Although I'm not
On Nov 5, 2009, at 9:02 AM, Kumar Gala wrote:
On Oct 16, 2009, at 11:44 AM, Anton Vorontsov wrote:
From: Jiang Yutang
Split sata_fsl_softreset() into hard and soft resets to make
error-handling more efficient & device and PMP detection more
reliable.
Also includes fix for PMP support, dri
On Thursday, November 19, 2009, Arnd Bergmann wrote:
> I'd still add support for the compatible="ns16550a" property
> so that we do the right thing for future systems.
>
OK...
---
Xilinx 16550 UART is actually 16550A-compatible
Signed-off-by: Alon Ziv
diff --git a/drivers/serial/of_serial.c b/
On Thursday 19 November 2009, Alon Ziv wrote:
> Is the following better?
>
> ---
> [PATCH] Xilinx 16550 UART is actually 16550A-compatible
>
Yes, that's better because it's guaranteed not to break any
other system, while fixing yours.
I'd still add support for the compatible="ns16550a" property
Hi,
On Thursday, November 19, 2009, Arnd wrote:
> In that case, add another entry for the device encoded in the firmware
> itself. The ns16550 entry should be the second one after a more
specific
> one telling which device it is exactly.
>
Is the following better?
---
[PATCH] Xilinx 16550 UART
On Thursday 19 November 2009, Alon Ziv wrote:
> On Monday, November 16, 2009, Arnd wrote:
> > > - { .type = "serial", .compatible = "ns16550", .data = (void
> *)PORT_16550, },
> > > + { .type = "serial", .compatible = "ns16550", .data = (void
> *)PORT_16550A, },
> >
> > Does not seem
Hi,
On Monday, November 16, 2009, Stephen wrote:
> There are at least two other ways that you might be able to reset a
> board:
> 1) Internally through the ICAP device.
> 2) Through a GPIO connected externally to the reset logic.
>
Unfortunately none of these is relevant for the specific board i
Hi,
On Monday, November 16, 2009, Arnd wrote:
> > - { .type = "serial", .compatible = "ns16550", .data = (void
*)PORT_16550, },
> > + { .type = "serial", .compatible = "ns16550", .data = (void
*)PORT_16550A, },
>
> Does not seem logical. If the device claims compatibility with
ns165
The typename member of struct irq_chip was kept for migration purposes
and is obsolete since more than 2 years. Fix up the leftovers.
Signed-off-by: Thomas Gleixner
Cc: Benjamin Herrenschmidt
Cc: linuxppc-...@ozlabs.org
---
arch/powerpc/kernel/irq.c |6 +++---
arch/pow
39 matches
Mail list logo
