On Fri, 2007-08-03 at 18:54 -0400, Morrison, Tom wrote:
> Now, that looks OK! Those are what I would expect. And when the
> mdio/phy are probed, configured, and the 88E1145 interrupt (EXT7
> (0x37H)) is enabled, the interrupt never (seemingly) gets cleared,
> and basically hangs the entire box up
On Fri, 2007-08-03 at 14:32 -0500, Linas Vepstas wrote:
> On Fri, Aug 03, 2007 at 06:58:51PM +1000, Paul Mackerras wrote:
> > The code for mapping special 4k pages on kernels using a 64kB base
> > page size was missing the code for doing the RPN (real page number)
> > manipulation when inserting th
On Fri, 2007-08-03 at 21:10 +0400, Sergei Shtylyov wrote:
> > Why bother doing this?! This will only warrant you imprecise
> > decrementer
> > interrupts while it should be interrupting at the precise period currently
> > (if
> > you load PIT once)...
>
> I.e. the error will only accu
On Fri, 2007-08-03 at 20:47 +0400, Sergei Shtylyov wrote:
> Josh Boyer wrote:
>
> > Allow generic_calibrate_decr to work for 40x platforms. Given that the
> > hardware
> > behavior is identical, this also changes the set_dec function to reload the
> > PIT
> > on 40x to match the behavior 44x cu
From: Andre Detsch <[EMAIL PROTECTED]>
This patch moves affinity initialization code from spu_base.c to a
new spu_management_of_ops function (init_affinity), which is empty
in the case of PS3. This fixes a linking problem that was happening
when compiling for PS3.
Also, some small code style chan
All,
Connected to eth1 (etsec2) of my mpc8548 cpu is a 88E1145 and I
am trying to get the core functionality running with the device tree
paradigm - I know the sense of the 88E1145 is active-low for my
mpc8548 board and have it working with an older 2.6.11++ kernel.
I built this new kernel wi
> > > > + MPIC: [EMAIL PROTECTED] {
> > > > + device_type = "open-pic";
> > > >
> > > > device_type = "interrupt-controller".
> >
> > Not according to the binding in booting-without-of.txt
>
> My understanding here, though possibly flawed, is that the current
Linas Vepstas wrote:
> 3:mon> d c77b21e0
> c77b21e0 e0008004b224 067410090080 |...$.t..|
>
> Well, howdy doody, there's the value that should have been in r3
>
> c77b21f0 c4008e00 49424d00 |IBM.|
>
> IBM ???
>
> c000
Kok, Auke wrote:
> Andrew Gallatin wrote:
>> To follow up on Jan-Bernd Themann's LRO patch earlier today,
>> this patch shows how the generic LRO interface can be used for
>> page based drivers.
>>
>> Again, many thanks to Jan-Bernd Themann for leading this effort.
>>
>> Drew
>>
>> Singed off by: A
Acked by: Brian King <[EMAIL PROTECTED]>
David Woodhouse wrote:
> If you build a multiplatform kernel for iSeries and pSeries, with
> ibmvscsic support, the resulting client doesn't work on iSeries.
>
> This patch should fix that, using the appropriate low-level operations
> for the machine detec
Andrew Gallatin wrote:
> To follow up on Jan-Bernd Themann's LRO patch earlier today,
> this patch shows how the generic LRO interface can be used for
> page based drivers.
>
> Again, many thanks to Jan-Bernd Themann for leading this effort.
>
> Drew
>
> Singed off by: Andrew Gallatin <[EMAIL PR
Jan-Bernd Themann wrote:
> This patch shows how the generic LRO interface is used for SKB mode
>
> Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
>
> ---
> drivers/net/Kconfig |1 +
> drivers/net/ehea/ehea.h |9 -
> drivers/net/ehea/ehea_ethtool.c | 15 +++
On Fri, Aug 03, 2007 at 05:58:56PM +0300, Alexandros Kostopoulos wrote:
> Hi all,
> in the old arch/ppc tree, there was a function called pq2ads_setup_pci()
> that set up PCI regs for 8272xx, in m82xx_pci.c. I was wandering, where
> are these registers configured now in arch/powerpc? I can't se
On Fri, Aug 03, 2007 at 06:58:51PM +1000, Paul Mackerras wrote:
> The code for mapping special 4k pages on kernels using a 64kB base
> page size was missing the code for doing the RPN (real page number)
> manipulation when inserting the hardware PTE in the secondary hash
> bucket. It needs the sam
Josh Boyer wrote:
> Why bother doing this?! This will only warrant you imprecise
> decrementer
>interrupts while it should be interrupting at the precise period currently
>(if
>you load PIT once)...
I.e. the error will only accumulate. NAK.
>>>What error exactly?
On Fri, 03 Aug 2007 21:30:57 +0400
Sergei Shtylyov <[EMAIL PROTECTED]> wrote:
> Josh Boyer wrote:
>
> on 40x to match the behavior 44x currently has.
>
> >>>Why bother doing this?! This will only warrant you imprecise
> >>> decrementer
> >>>interrupts while it should be interrupting at
Josh Boyer wrote:
on 40x to match the behavior 44x currently has.
>>>Why bother doing this?! This will only warrant you imprecise decrementer
>>>interrupts while it should be interrupting at the precise period currently
>>>(if
>>>you load PIT once)...
>>I.e. the error will only ac
On Fri, 03 Aug 2007 21:10:19 +0400
Sergei Shtylyov <[EMAIL PROTECTED]> wrote:
> I wrote:
>
> >>Allow generic_calibrate_decr to work for 40x platforms. Given that the
> >>hardware
> >>behavior is identical, this also changes the set_dec function to reload the
> >>PIT
>
> It's not actually
Josh Boyer wrote:
>>>Allow generic_calibrate_decr to work for 40x platforms. Given that the
>>>hardware
>>>behavior is identical, this also changes the set_dec function to reload the
>>>PIT
>>>on 40x to match the behavior 44x currently has.
>>Why bother doing this?! This will only warrant
To follow up on Jan-Bernd Themann's LRO patch earlier today,
this patch shows how the generic LRO interface can be used for
page based drivers.
Again, many thanks to Jan-Bernd Themann for leading this effort.
Drew
Singed off by: Andrew Gallatin <[EMAIL PROTECTED]>
diff -urNp a/drivers/net/myri1
On Fri, 03 Aug 2007 20:47:03 +0400
Sergei Shtylyov <[EMAIL PROTECTED]> wrote:
> Josh Boyer wrote:
>
> > Allow generic_calibrate_decr to work for 40x platforms. Given that the
> > hardware
> > behavior is identical, this also changes the set_dec function to reload the
> > PIT
> > on 40x to matc
I wrote:
>>Allow generic_calibrate_decr to work for 40x platforms. Given that the
>>hardware
>>behavior is identical, this also changes the set_dec function to reload the
>>PIT
It's not actually identical. When you're writing to the PIT reg on 40x,
you're alos writing to the hidden PIT au
Josh Boyer wrote:
> Allow generic_calibrate_decr to work for 40x platforms. Given that the
> hardware
> behavior is identical, this also changes the set_dec function to reload the
> PIT
> on 40x to match the behavior 44x currently has.
Why bother doing this?! This will only warrant you imp
Add MMU definitions for 40x platforms. Also fixes two warnings in 40x_mmu.c.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/head_40x.S |2 -
arch/powerpc/mm/40x_mmu.c |4 +-
include/asm-powerpc/mmu-40x.h | 65 +
incl
Add a bootwrapper for the AMCC 440EP Bamboo Eval board. This also adds a
common fixup_clock function for all 440EP(x) chips.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/44x.h |1
arch/powerpc/boot/4xx.c | 82
Add support for the AMCC Bamboo board
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/configs/bamboo_defconfig | 775 ++
arch/powerpc/platforms/44x/Kconfig| 15
arch/powerpc/platforms/44x/Makefile |1
arch/powerpc/platforms/44x/bamboo
Remove inclusion of __res on 40x. We don't need it in arch/powerpc
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/head_40x.S |1 -
arch/powerpc/kernel/ppc_ksyms.c |2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
--- linux-2.6.orig/arch/powerpc/kernel/ppc_k
AMCC Bamboo board DTS
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/bamboo.dts | 248 +++
1 file changed, 248 insertions(+)
--- /dev/null
+++ linux-2.6/arch/powerpc/boot/dts/bamboo.dts
@@ -0,0 +1,248 @@
+/*
+ * Device Tree Source fo
Allow generic_calibrate_decr to work for 40x platforms. Given that the hardware
behavior is identical, this also changes the set_dec function to reload the PIT
on 40x to match the behavior 44x currently has.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/time.c |2 +-
Make the fixup_memsize function common for all of 4xx as several chips share
the same SDRAM controller. Also add functions to reset 40x chips and quiesce
the ethernet.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/44x.h |4
arch/powerpc/boot/4xx.c | 36 +
Rename the 44x.c wrapper file to 4xx.c. This will allow us to add common
functions in a single file that can be shared across all of 4xx.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/boot/44x.c| 85 -
arch/powerpc/boot/4xx.c
Remove some leftover cruft in the 40x Kconfig file. Also make sure we
select WANT_DEVICE_TREE for 40x.
Signed-off-by: Josh Boyer <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/40x/Kconfig | 77 -
arch/powerpc/platforms/Kconfig.cputype |1
2 files chang
Here are the current 4xx patches I'd like to get in to 2.6.24. They include
some initial cleanups for 40x support as well as the AMCC Bamboo board support.
If we can get Bamboo merged, that will make it much easier for Sequoia (440EPx)
and Rainer (440GRx) to follow on.
Also, I've started a git t
David Gibson wrote:
> Duh, forgot to attach the actual patch. Here it is:
> Index: working-2.6/Documentation/powerpc/booting-without-of.txt
> ===
> --- working-2.6.orig/Documentation/powerpc/booting-without-of.txt
> 2007-07-30
Hello.
David Gibson wrote:
>>>Index: working-2.6/Documentation/powerpc/booting-without-of.txt
>>>===
>>>--- working-2.6.orig/Documentation/powerpc/booting-without-of.txt
>>>2007-07-30 17:07:14.0 +1000
>>>+++ working-2.6/D
On Fri, 2007-08-03 at 01:35, David Gibson wrote:
> > > + PIC8259: interrupt-controller {
> > > + device_type = "i8259";
> > >
> > > device_type = "interrupt-controller".
>
> Is that really right? The MPIC binding, at least, has device_type =
> "open-pic"
Hi all,
in the old arch/ppc tree, there was a function called pq2ads_setup_pci()
that set up PCI regs for 8272xx, in m82xx_pci.c. I was wandering, where
are these registers configured now in arch/powerpc? I can't seem to find
these code now.
Also, I can see that now bus 0, dev 0 (which I thi
On Fri, 3 August 2007 14:41:19 +0200, Jan-Bernd Themann wrote:
>
> This patch provides generic Large Receive Offload (LRO) functionality
> for IPv4/TCP traffic.
>
> LRO combines received tcp packets to a single larger tcp packet and
> passes them then to the network stack in order to increase pe
This patch shows how the generic LRO interface is used for SKB mode
Signed-off-by: Jan-Bernd Themann <[EMAIL PROTECTED]>
---
drivers/net/Kconfig |1 +
drivers/net/ehea/ehea.h |9 -
drivers/net/ehea/ehea_ethtool.c | 15 +++
drivers/net/ehea/ehea_main.c|
This patch provides generic Large Receive Offload (LRO) functionality
for IPv4/TCP traffic.
LRO combines received tcp packets to a single larger tcp packet and
passes them then to the network stack in order to increase performance
(throughput). The interface supports two modes: Drivers can either
Hi,
I think this patch could be the final version for now. It has been tested
on two platforms (power and x86_64) and works very well.
Apart from David Miller and Evgeniy Polaykov, we'd like to thank especially
Andrew Gallatin for his great reviews and help to make that happen.
After some discus
On Fri, 3 Aug 2007 03:39:23 -0500
Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> On Aug 2, 2007, at 3:32 PM, Josh Boyer wrote:
>
> > On Wed, 1 Aug 2007 15:05:42 +1000
> > David Gibson <[EMAIL PROTECTED]> wrote:
> >
> >> On Wed, Aug 01, 2007 at 07:01:17AM +0200, Segher Boessenkool wrote:
> > +
On Fri, 3 Aug 2007 08:38:25 +0200
Stefan Roese <[EMAIL PROTECTED]> wrote:
> > > +static void ibm440epx_fixup_memsize(void)
> >
> > And we should move this at the same time. Isn't denali used by another
> > CPU as well?
>
> Right now the Denali DDR(2) core is only used by the 440EPx/440GRx. But o
> Depends on interpretation. IIRC currently the same die is used for 440EPx and
> 440GRx. I could be wrong here though and it is just a bug in the chip. But
> anyway we should support this somehow. Could be that I missed this in the
> current 440GRx (Rainier) arch/ppc support too. I have to adm
On Fri, 2007-08-03 at 17:20 +0530, Pradyumna Sampath wrote:
> Hi,
> I am running linux-2.6.22.1-rt8 on mpc5200 and on running stress
>
> #./stress --cpu 8 --io 4 --vm 2 --vm-bytes 2M --timeout 300s
>
> I get the following stack.But this does not happen with non -rt kernel.
>
>LR = 0xff51fcc
On Friday 03 August 2007, Valentine Barshak wrote:
> >> Should the 440GRX PVR additions be done in a separate patch? Or is the
> >> PVR and cpu features truly the only difference between 440EPx and
> >> 440GRx?
> >
> > I think it makes sense to add the 440GRx with this patchset too. The
> > 440GRx
On Fri, 2007-08-03 at 18:58 +1000, Paul Mackerras wrote:
> The code for mapping special 4k pages on kernels using a 64kB base
> page size was missing the code for doing the RPN (real page number)
> manipulation when inserting the hardware PTE in the secondary hash
> bucket. It needs the same code
Hi,
I am running linux-2.6.22.1-rt8 on mpc5200 and on running stress
#./stress --cpu 8 --io 4 --vm 2 --vm-bytes 2M --timeout 300s
I get the following stack.But this does not happen with non -rt kernel.
LR = 0xff51fcc
BUG: scheduling while atomic: stress/0x0002/739, CPU#0
Call Trace:
[c04f
Stefan Roese wrote:
> On Thursday 02 August 2007, Josh Boyer wrote:
>> On Mon, 30 Jul 2007 19:16:28 +0400
>>> +0400 +++ linux/arch/powerpc/kernel/cputable.c 2007-07-27
>>> 20:44:26.0 +0400 @@ -1132,6 +1132,42 @@
>>> .dcache_bsize = 32,
>>> .platform
Josh Boyer wrote:
> On Mon, 30 Jul 2007 19:23:39 +0400
> Valentine Barshak <[EMAIL PROTECTED]> wrote:
>
>> The patch adds PHY support for the Sequoia board to the new EMAC driver and
>> enables NEW_EMAC for 440EPx Kconfig.
>> The phy code has been written by Stefan Roese.
>> This has been tested w
Josh Boyer wrote:
> On Mon, 30 Jul 2007 19:16:28 +0400
> Valentine Barshak <[EMAIL PROTECTED]> wrote:
>
>> diff -ruN linux.orig/arch/powerpc/kernel/cputable.c
>> linux/arch/powerpc/kernel/cputable.c
>> --- linux.orig/arch/powerpc/kernel/cputable.c2007-07-27
>> 20:37:10.0 +0400
>>
Josh Boyer wrote:
> On Thu, 2 Aug 2007 13:48:48 +1000
> David Gibson <[EMAIL PROTECTED]> wrote:
>
>> On Mon, Jul 30, 2007 at 08:35:17PM +0400, Valentine Barshak wrote:
>>> PPC44x cascade UIC irq handler fix.
>>>
>>> According to PPC44x UM, if an interrupt is configured as
>>> level-sensitive, and
Linus,
Please do
git pull \
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get another batch of bug-fixes for powerpc.
Thanks,
Paul.
arch/powerpc/kernel/entry_64.S|3 +++
arch/powerpc/kernel/pci_32.c |5 -
arch/powerpc/kernel/smp
On Aug 2, 2007, at 5:14 AM, Mariusz Kozlowski wrote:
>>> Second issue as reported earilier allmodconfig fails to build on
>>> imac g3.
>>
>> Do you really mean g3? If so it's a 32-bit kernel and it
>> shouldn't be
>> building lparmap.s. Or do you mean G5?
>
> Yes it is iMac G3. More or less
On Aug 2, 2007, at 4:47 PM, David Brownell wrote:
> On Thursday 02 August 2007, Anton Vorontsov wrote:
>> Probably someday mpc83xx_spi->sysclk should be renamed to
>> mpc83xx_spi->spiclk to be less confusing.
>
> Why not "today", with this patch? That would fix some of
> the root cause of this b
On Aug 3, 2007, at 4:18 AM, Paul Mackerras wrote:
> Becky Bruce writes:
>
>> Reserved MCSR bits on FSL BookE parts may have spurious values
>> when mcheck occurs. Mask these off when printing the MCSR to
>> avoid confusion. Also, get rid of the MCSR_GL_CI bit defined
>> for e500 - this bit does
Becky Bruce writes:
> Reserved MCSR bits on FSL BookE parts may have spurious values
> when mcheck occurs. Mask these off when printing the MCSR to
> avoid confusion. Also, get rid of the MCSR_GL_CI bit defined
> for e500 - this bit doesn't actually have any meaning.
Is this needed for 2.6.23?
On Thu, Aug 02, 2007 at 04:32:13PM -0700, David Brownell wrote:
> On Wednesday 01 August 2007, Christoph Hellwig wrote:
> > On Wed, Aug 01, 2007 at 09:28:07AM +0200, Domen Puncer wrote:
> > > > It doesn't make any assumption on struct clk, it's just a
> > > > wrapper around functions from clk.h.
>
The real page number field in our PTEs when configured for 64kB pages
is currently 32 bits, which turns out to be not quite enough for the
resources that the eHCA driver wants to map. This expands the RPN
field to include 2 adjacent, previously-unused bits.
Signed-off-by: Paul Mackerras <[EMAIL P
The code for mapping special 4k pages on kernels using a 64kB base
page size was missing the code for doing the RPN (real page number)
manipulation when inserting the hardware PTE in the secondary hash
bucket. It needs the same code as has already been added to the
code that inserts the HPTE in th
On Aug 2, 2007, at 3:32 PM, Josh Boyer wrote:
> On Wed, 1 Aug 2007 15:05:42 +1000
> David Gibson <[EMAIL PROTECTED]> wrote:
>
>> On Wed, Aug 01, 2007 at 07:01:17AM +0200, Segher Boessenkool wrote:
> + { /* 440EPX - without Security/Kasumi */
> + .pvr_mask = 0xf
From: Hoang-Nam Nguyen
Date: Fri, 3 Aug 2007 09:44:56 +0200
Subject: [PATCH] ehca: map 4k firmware context of cq, qp to user space
This patch utilizes remap_4k_pfn() as introduced by Paul M.,
for details see http://patchwork.ozlabs.org/linuxppc/patch?id=10281,
to map ehca cq, qp firmware context (
62 matches
Mail list logo
