With this patch the L2 cache is enabled on Canyonlands to increase the
overall performance. There is a known cache coherency issue with the L2
cache, but this is related to the high bandwidth (HB) PLB segment where
the memory address is 0x8.. (low bandwidth PLB segment is mapped
to 0x0.
On Friday 05 December 2008, Kim Phillips wrote:
> > diff --git a/arch/powerpc/boot/dts/canyonlands.dts
> > b/arch/powerpc/boot/dts/canyonlands.dts index 79fe412..b0f0096 100644
> > --- a/arch/powerpc/boot/dts/canyonlands.dts
> > +++ b/arch/powerpc/boot/dts/canyonlands.dts
> > @@ -116,6 +116,13 @@
>
Dave Hansen wrote:
I got a bug report about a distro kernel not booting on a particular
machine. It would freeze during boot:
...
Could not find start_pfn for node 1
[boot]0015 Setup Done
Built 2 zonelists in Node order, mobility grouping on. Total pages: 123783
Policy zone: DMA
Kernel com
Hi Ben,
On Fri, Dec 5, 2008 at 4:24 AM, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
> On Fri, 2008-12-05 at 00:06 +0530, Deepak Pandian wrote:
>> Hi,
>>
>> In ppc4xx_pci i see the pci size to be declared as
>> u32 lah, lal, pciah, pcial, sa;
>
> I think the 4xx code is pretty much ok at thi
On Tue, 02 Dec 2008 14:17:12 -0800
James Hsiao <[EMAIL PROTECTED]> wrote:
> Hi,
>
> This patch add canyonlands support.
>
> Few performance optimizations:
> Redesigned the crypto4xx_build_pd(), which now calculate number of
> scatter and gather descriptors need before taking them. Instead take
A bit off topic, but since the subject is pci resource allocation:
As entered here:
http://bugs.gentoo.org/show_bug.cgi?id=249832
the 2.6.24-gentoo-r3 kernel; iomem tree for my video display works, but
has not worked in the following kernels:
2.6.26-gentoo-r2
2.6.27-gentoo-r2
2.6.28-rc4 (perfmon2
On Dec 4, 2008, at 11:52 AM, Anton Vorontsov wrote:
This is needed so that Vitesse 7385 5-port switch could work on
MPC8349E-mITX boards.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
applied to merge.
Guys, can you put a [for 2.6.28] or something if a patch is intended
for .28..
Paul Mackerras wrote:
> Brian King writes:
>
>> This should go to Linus for 2.6.28
>
> OK, thanks, but is it a regression from 2.6.27?
Probably not. Its probably broken in 2.6.27 as well.
Looking at the git history of arch/powerpc/mm/hugetlbpage.c,
it hasn't changed since 2.6.27 went out the do
Hi Becky,
On Thu, 4 Dec 2008 12:12:40 -0600 Becky Bruce <[EMAIL PROTECTED]> wrote:
>
> Change #define stubs of dma_sync ops to be empty static inlines
> to avoid build warning.
>
> Signed-off-by: Becky Bruce <[EMAIL PROTECTED]>
Acked-by: Stephen Rothwell <[EMAIL PROTECTED]>
Build tested for pp
Brian King writes:
> This should go to Linus for 2.6.28
OK, thanks, but is it a regression from 2.6.27?
(Serves me right for asking two questions in one email. :)
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/l
Paul Mackerras wrote:
> Brian King writes:
>
>> It looks like most of the hugetlb code is doing the correct thing if
>> hugepages are not supported, but the mmap code is not. If we get into
>> the mmap code when hugepages are not supported, such as in an LPAR
>> which is running Active Memory Shar
Brian King writes:
> It looks like most of the hugetlb code is doing the correct thing if
> hugepages are not supported, but the mmap code is not. If we get into
> the mmap code when hugepages are not supported, such as in an LPAR
> which is running Active Memory Sharing, we can oops the kernel. T
On Fri, 2008-12-05 at 00:06 +0530, Deepak Pandian wrote:
> Hi,
>
> In ppc4xx_pci i see the pci size to be declared as
> u32 lah, lal, pciah, pcial, sa;
I think the 4xx code is pretty much ok at this stage no ?
> Also at many other places I see the pci region is not capable of
> handling resourc
On Thu, 2008-12-04 at 07:46 -0500, Josh Boyer wrote:
> ..but I couldn't let this one go. Totally incorrect comments here given
> that the file is _for_ 8xx and 4xx. I suspect an errant copy/paste :).
Or rather blame "cp" :-) I just duplicated mmu_context_32.c and modified
both versions differentl
On Thu, 2008-12-04 at 07:33 -0500, Josh Boyer wrote:
> On Thu, 04 Dec 2008 17:12:59 +1100
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> > We were missing the CPU_FTR_NOEXECUTE bit in our cputable for all
> > these processors. The result is that update_mmu_cache() would flush
> > the cach
From: Jason Jin <[EMAIL PROTECTED]>
The general pci resume code can only restore part of the
configuration registers. We need to reconfigure those
registers in the FIXUP_RESUME.
Signed-off-by: Jason Jin <[EMAIL PROTECTED]>
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/
The read-mask function assumes that it is running in 32-bit mode,
by addressing the bitmask as a series of int values, instead of
longs. This is broken as can easily be reproduced by running numademo
on a bit-endian 64-bit system.
Changing the addressing to use 'long' values fixes the problem.
Re
On Thursday 04 December 2008, Lee Schermerhorn wrote:
> On Thu, 2008-12-04 at 18:34 +0100, Arnd Bergmann wrote:
> > The read-mask function assumes that it is running in 32-bit mode,
> > by addressing the bitmask as a series of int values, instead of
> > longs. This is broken as can easily be reprod
On Thu, 2008-12-04 at 18:34 +0100, Arnd Bergmann wrote:
> The read-mask function assumes that it is running in 32-bit mode,
> by addressing the bitmask as a series of int values, instead of
> longs. This is broken as can easily be reproduced by running numademo
> on a bit-endian 64-bit system.
>
>
Anton Vorontsov wrote:
> The FIXED_PHY driver isn't enabled in the defconfig. Following
> patch should fix the issue.
>
> arch/powerpc/configs/83xx/mpc834x_itx_defconfig |2 +-
> arch/powerpc/configs/mpc83xx_defconfig |2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
Ac
Hi,
In ppc4xx_pci i see the pci size to be declared as
u32 lah, lal, pciah, pcial, sa;
Also at many other places I see the pci region is not capable of
handling resources > 4GB. I am planning to work on this arch specific
code to make it handle pci resource of width greater than 4 GB.
But befor
Change #define stubs of dma_sync ops to be empty static inlines
to avoid build warning.
Signed-off-by: Becky Bruce <[EMAIL PROTECTED]>
---
arch/powerpc/include/asm/dma-mapping.h | 41 +++
1 files changed, 35 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/in
On Thu, Dec 04, 2008 at 09:42:14PM +1100, Paul Mackerras wrote:
> Greg KH writes:
>
> > Yes, Paul, please apply the patch, and let me know. It will make things
> > much easier in the end for everyone involved.
>
> Hmmm, I don't have it in my inbox, all I can find is an email from Kay
> saying it
Timur Tabi schrieb:
> Andre Schwarz wrote:
>
>> Timur,
>>
>> is it possible that the PHY adress doesn't match the one specified in
>> the dts ?
>>
>
> What part of the DTS contains the PHY address? I have this:
>
> [EMAIL PROTECTED] {
> #address-cells = <1>;
>
On Thu, Dec 04, 2008 at 11:47:26AM -0600, Timur Tabi wrote:
> Andre Schwarz wrote:
> > Timur,
> >
> > is it possible that the PHY adress doesn't match the one specified in
> > the dts ?
>
> What part of the DTS contains the PHY address? I have this:
>
> [EMAIL PROTECTED] {
>
This is needed so that Vitesse 7385 5-port switch could work on
MPC8349E-mITX boards.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
On Thu, Dec 04, 2008 at 11:15:32AM -0600, Timur Tabi wrote:
> The Freescale MPC8349e-MITX reference board has two TSECs, the second
> of which (eth1) is att
Andre Schwarz wrote:
> Timur,
>
> is it possible that the PHY adress doesn't match the one specified in
> the dts ?
What part of the DTS contains the PHY address? I have this:
[EMAIL PROTECTED] {
#address-cells = <1>;
#size-cells = <0>;
co
Timur,
is it possible that the PHY adress doesn't match the one specified in
the dts ?
regards,
Andre
Timur Tabi schrieb:
> The Freescale MPC8349e-MITX reference board has two TSECs, the second
> of which (eth1) is attached to a Vitesse 7385 5-port switch.
>
> Using the latest U-Boot, Kernel, an
The read-mask function assumes that it is running in 32-bit mode,
by addressing the bitmask as a series of int values, instead of
longs. This is broken as can easily be reproduced by running numademo
on a bit-endian 64-bit system.
Changing the addressing to use 'long' values fixes the problem.
Re
On Thu, 4 Dec 2008 09:01:07 -0500
"Josh Boyer" <[EMAIL PROTECTED]> wrote:
> On Wed, 3 Dec 2008 22:28:32 -0500
> Sean MacLennan <[EMAIL PROTECTED]> wrote:
>
> Hi Sean,
>
> A couple of comments/requests below.
>
> In addition to an example DTS patch (probably to warp itself), could
> you briefly
The Freescale MPC8349e-MITX reference board has two TSECs, the second
of which (eth1) is attached to a Vitesse 7385 5-port switch.
Using the latest U-Boot, Kernel, and device tree, I cannot bring up
eth1. When I try, I get this message:
[EMAIL PROTECTED] root]# ifconfig eth1 up
0:01 not found
et
[oops forgot to cc the list]
Nathan Lynch wrote at 2008-12-03 17:43:40:
Kumar Gala wrote:
On Dec 2, 2008, at 11:31 PM, Nathan Lynch wrote:
Kumar Gala wrote:
WARNING: vmlinux.o(.text+0x2aa): Section mismatch in reference from
the variable __secondary_start to the function
.devinit.text:start_s
From: Grant Likely <[EMAIL PROTECTED]>
The 440x5 core in the Virtex5 uses the 440A type machine check
(ie, they have MCSRR0/MCSRR1). They thus need to call the
appropriate fixup function to hook the right variant of the
exception.
Without this, all machine checks become fatal due to loss
of conte
Hi Laurent,
> The two messages making up the transaction are parsed. The driver fills a TX
> buffer descriptor for the first one, and a TX and an RX buffer descriptor for
> the second one.
>
>> rbase 0x01e0 tbase 0x01c0 rfcr 0x30 tfcr 0x30 mrblr 0x0201
>> rstate 0x rptr 0x rbptr
On Dec 4, 2008, at 5:06 AM, Paul Mackerras wrote:
Kumar Gala writes:
Please pull from 'next' branch of
Pulled and pushed out to my master and next branches.
thanks
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mai
It looks like most of the hugetlb code is doing the correct thing if
hugepages are not supported, but the mmap code is not. If we get into
the mmap code when hugepages are not supported, such as in an LPAR
which is running Active Memory Sharing, we can oops the kernel. This
patch fixes the oops be
On Wed, 3 Dec 2008 22:28:32 -0500
Sean MacLennan <[EMAIL PROTECTED]> wrote:
Hi Sean,
A couple of comments/requests below.
> The current ndfc driver only compiles under arch/ppc. This arch was
> removed from the kernel. I notice the event entry for the ndfc in
> Kconfig has been removed in 2.6.28
I have a MPC5200 based board which has an FPGA for external
I/O, etc. This FPGA also funnels interrupts from the various
external devices through to the CPU.
I've defined this structure in my DTS:
[EMAIL PROTECTED] {
device_type = "board-control";
#address
On Thu, 04 Dec 2008 16:41:48 +1100
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
Stephen had a bunch of comments as well, so I'll spare you those
again...
> Index: linux-work/arch/powerpc/mm/mmu_context_nohash.c
> ===
> --- /dev/
On Thu, 04 Dec 2008 17:12:59 +1100
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> We were missing the CPU_FTR_NOEXECUTE bit in our cputable for all
> these processors. The result is that update_mmu_cache() would flush
> the cache for all pages mapped to userspace which is totally
> unnecessar
Kumar Gala writes:
> Please pull from 'next' branch of
Pulled and pushed out to my master and next branches.
Paul.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Greg KH writes:
> Yes, Paul, please apply the patch, and let me know. It will make things
> much easier in the end for everyone involved.
Hmmm, I don't have it in my inbox, all I can find is an email from Kay
saying it had a problem. Care to forward it to me?
Paul.
42 matches
Mail list logo
