On Sunday 10 January 2010 21:02:16 Benjamin Herrenschmidt wrote:
> On Sat, 2010-01-09 at 02:17 -0600, Rob Landley wrote:
> > On Thursday 07 January 2010 21:00:43 Benjamin Herrenschmidt wrote:
> > > > Ok, here's the fix. It's not the _right_ fix, but it Works For Me
> > > > (tm) and I'll leave it t
Please see my answers in line.
-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org]
Sent: Sunday, January 03, 2010 10:25 PM
To: Tirumala Reddy Marri
Cc: jwbo...@linux.vnet.ibm.com; linuxppc-dev@lists.ozlabs.org;
linuxppc-...@ozlabs.org; writetoma...@yahoo.com
Hi Ira,
I have tested your patches with async DMA memcpy support. Though I
haven't captured the improvement figures.
It works fine for RAID5 memcpy offload as interrupts are coming for
separate DMA channels while I have ran IOZONE onto RAID partition.
Regards,
Dipen
-Original Message
It seems that in qemu, we can see an interrupt in R3 despite the
fact that it's masked in W1. The chip doesn't actually issue an
interrupt, but we can "see" it when taking an interrupt for the
other channel. This may be a qemu bug ... or not, so let's be
safe and avoid calling into the UART layer w
'bd == ugeth->txBd[txQ]' has two possible statuses: 1)full queue.
2)empty queue.
Removing 'netif_queue_stopped() == 0' will make transmitting stopping
when the queue is full.
I made a new patch for this oops.
>From 726765194352d01dc8ea672d97612589b67cec3f Mon Sep 17 00:00:00 2001
From: Jiajun
On Sat, 2010-01-09 at 02:17 -0600, Rob Landley wrote:
> On Thursday 07 January 2010 21:00:43 Benjamin Herrenschmidt wrote:
> > > Ok, here's the fix. It's not the _right_ fix, but it Works For Me (tm)
> > > and I'll leave it to you guys to figure out what this _means_:
> >
> > I've failed to reprod
> OK, I'll try writing byte by byte. The funny thing is the u-boot also
> writes the
> same value to PCI_PRIMARY_BUS register and it doesn't cause reset.
Maybe the bridge doesn't want to be programmed more than once on these
registers ? In any case, that's very very fishy I wonder if the
bri
Benjamin Herrenschmidt wrote:
On Sun, 2010-01-10 at 14:56 +0200, Felix Radensky wrote:
I now have a custom board with 460EX and the same PLX bridge, running
2.6.23-rc3
Things look better here, as u-boot is now able to properly detect PLX
and device behind
it, but kernel still has problems.
On Sun, 2010-01-10 at 19:15 +0100, Michael Buesch wrote:
> On Sunday 10 January 2010 14:31:09 Michael Buesch wrote:
> > I get the following compilation failure, if 64k pages is selected
> > on 2.6.32.3 on a PowerMAC config:
> >
> > include/linux/mmzone.h:947:2: error: #error Allocator MAX_ORDER ex
On Sun, 2010-01-10 at 14:56 +0200, Felix Radensky wrote:
> I now have a custom board with 460EX and the same PLX bridge, running
> 2.6.23-rc3
> Things look better here, as u-boot is now able to properly detect PLX
> and device behind
> it, but kernel still has problems. First, I'm still getting
On Sunday 10 January 2010 14:31:09 Michael Buesch wrote:
> I get the following compilation failure, if 64k pages is selected
> on 2.6.32.3 on a PowerMAC config:
>
> include/linux/mmzone.h:947:2: error: #error Allocator MAX_ORDER exceeds
> SECTION_SIZE
>
> Any idea?
>
Ok, I figured out that low
Add platform driver support to the pmac-zilog driver, for m68k macs.
Place the powermac-specific code inside #ifdef CONFIG_PPC_PMAC.
Signed-off-by: Finn Thain
---
This patch should be applied after "[PATCH 3/13] pmac-zilog: cleanup".
It obsoletes "[PATCH 4/13] pmac-zilog, mac68k: replace mac68k
I get the following compilation failure, if 64k pages is selected
on 2.6.32.3 on a PowerMAC config:
include/linux/mmzone.h:947:2: error: #error Allocator MAX_ORDER exceeds
SECTION_SIZE
Any idea?
--
Greetings, Michael.
___
Linuxppc-dev mailing list
Li
Hi, Ben
Felix Radensky wrote:
Hi, Ben
Adding Feng Kan from AMCC to CC.
Benjamin Herrenschmidt wrote:
On Mon, 2009-12-28 at 12:51 +0200, Felix Radensky wrote:
Hi,
I'm running linux-2.6.33-rc2 on Canyonlands board. When PLX 6254
transparent PCI-PCI
bridge is plugged into PCI slot the kerne
Add platform driver support to the pmac-zilog driver, for m68k macs.
Place the powermac-specific code inside #ifdef CONFIG_PPC_PMAC.
This patch should be applied after "[PATCH 3/13] pmac-zilog: cleanup".
Signed-off-by: Finn Thain
---
Version 2 of this patch adopts Geert's suggestions: make be
From: Márton Németh
The match_table field of the struct of_device_id is constant in
so it is worth to make the initialization data also constant.
The semantic match that finds this kind of pattern is as follows:
(http://coccinelle.lip6.fr/)
//
@r@
disable decl_init,const_decl_init;
identifie
16 matches
Mail list logo
