> Subject: [PATCH 2/2] powerpc/85xx: Add new LAW & MCM device
> tree nodes for all85xx systems
One nit/typo, the tittle of the two patches should be "ECM"
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc
Hello Scott,
Scott Wood wrote:
> On Mon, Apr 27, 2009 at 07:38:38AM +0200, Heiko Schocher wrote:
>> 1) add in the soc node an "errata" node and in this "errata" node
>>we can add all CPU specific errata as an example the qe_enet10
>>errata, which above code covers:
>
> What about errata d
Linus,
Please pull from the 'merge' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get a collection of bug fixes for powerpc.
Thanks,
Paul.
MAINTAINERS |2 +
arch/powerpc/boot/4xx.c | 56 +++
From: Milton Miller
powerpc: Enable MMU feature sections for inline asm
This adds the ability to do MMU feature sections for inline asm.
Signed-off-by: Milton Miller
Signed-off-by: Michael Neuling
---
arch/powerpc/include/asm/feature-fixups.h | 25 -
1 file changed
From: Milton Miller
This adds the PowerPC 2.06 tlbie mnemonics and keeps backwards
compatibilty for CPUs before 2.06.
Only useful for bare metal systems.
Signed-off-by: Milton Miller
Signed-off-by: Michael Neuling
---
arch/powerpc/include/asm/ppc-opcode.h |3 +++
arch/powerpc/kernel/c
These patches implement the PowerPC ISA 2.06 tlbie mnemonics
Signed-off-by: Michael Neuling
---
This version attempts to address issues raised by Kumar and Benh.
- Moves from CPU_FTR to MMU_FTR
- Moves #define of tlbie to ppc-opcode.h
___
Linuxppc-dev
On Thu, Apr 23, 2009 at 07:53:11AM -0600, Grant Likely wrote:
> On Wed, Apr 22, 2009 at 3:31 PM, Kumar Gala wrote:
> >
> > On Apr 22, 2009, at 3:16 PM, Timur Tabi wrote:
> >
> >> Scott Wood wrote:
> >>>
> >>> Timur Tabi wrote:
> >
> > these two are related and seem like we could look
On Thu, Apr 23, 2009 at 05:50:05PM +0400, Anton Vorontsov wrote:
> On Thu, Apr 23, 2009 at 08:02:20AM -0500, Timur Tabi wrote:
> > David Gibson wrote:
> >
> > > It's not so much point of view as situation. Putting the device tree
> > > in the firmware and putting the device tree in the kernel are
On Thu, Apr 23, 2009 at 08:02:20AM -0500, Timur Tabi wrote:
> David Gibson wrote:
>
> > It's not so much point of view as situation. Putting the device tree
> > in the firmware and putting the device tree in the kernel are both
> > valid choices, with their own distinct advantages and drawbacks.
On Mon, Apr 27, 2009 at 02:24:42PM +1000, John Williams wrote:
> To MicroBlazers and other interested parties:
>
> Currently the MicroBlaze kernel boot-time ABI requires r7 to point to
> a valid DTB, whereupon in early kernel setup the DTB is copied to a
> statically allocated 16k memory region in
On Wed, Apr 22, 2009 at 11:41:31PM -0500, Kumar Gala wrote:
>
> On Apr 22, 2009, at 11:06 PM, David Gibson wrote:
>
>> Well, yes, I guess I agree. How immutable you consider the device
>> tree blob to be is a judgement call based on the specific details of
>> platform/board in question. If it is
Linus,
Please revert commits edada399 ("powerpc: Use TEXT_TEXT macro in
linker script.") and 9203fc9c ("powerpc: Use __REF macro instead of
old .text.init.refok."), which depends on edada399.
Commit edada399 breaks the build because it moves the __ftr_alt_*
sections of a file away from the .text
On Mon, Apr 27, 2009 at 4:20 PM, Andrew Morton
wrote:
> On Tue, 03 Mar 2009 16:37:13 -0800 (PST)
> David Miller wrote:
>
>> From: Sean MacLennan
>> Date: Tue, 3 Mar 2009 19:29:32 -0500
>>
>> > It has been. u carry the two... longer than I want to admit
>> > since I worked on a sparc. Wou
Hi Andrew,
On Mon, 27 Apr 2009 14:50:31 -0700 Andrew Morton
wrote:
>
> powerpc allmodconfig, current mainline:
>
> drivers/video/logo/logo_linux_mono.c:11: error: logo_linux_mono_data causes a
> section type conflict
>
> switching it from __initconst to __initdata "fixes" it.
Interesting. T
Hi, Kumar.
On Apr 27 2009, Kumar Gala wrote:
>
> On Apr 24, 2009, at 5:33 PM, Rogério Brito wrote:
>> 04. disable CONFIG_BLK_DEV_RAM.
>
> do we not allow booting a ramdisk?
Well, do we need a block device in ram to use initramfs?
(...)
>> Dear Kumar, please, apply this one.
>>
>> I have another
Hi Dave,
For the DMA PCI read/line/multi-line is outbound transaction.
So according to your experiment, the 8349 PCI controller(as master)
attemp to streaming/combining the outbound transaction(treated as
prefetchable space).
Yep, with the MPC8349EA configured as a PCI Target,
and operating as
> >> You can mark the pci inbound window on the 83xx as
> >> non-prefetchable(assuming 83xx is host). On a x86 host
> >> I doubt there is any easy way to get non-prefetchable memory.
> One more note; we don't have access to a host-mode MPC8349EA,
> our boards are all targets.
Actually we also ca
> Here's a few results from DMA tests between two
> MPC8349EA boards housed in a CPCI chassis.
>
> 1. DMA mode register (DMAMRn)
> PCI read command (PRC, bits 11:10)
>
> a) DMAMRn[PRC] = 00 = PCI Read
>
>The PCI read command is 6h on the PCI bus.
>For DMA lengths of less
How about FIFO RAM case?
If the FIFO has a fixed address, then according to
the user guide, the DMA controller won't generate
a burst transaction to it.
We can try confirming this if you'd like.
Cheers,
Dave
___
Linuxppc-dev mailing list
Linuxp
> > You are assuming the PCI memory space is prefetchable( no
> > side effect) for DMA.
> > Is it possible that DMA is from non-prefetchable memory space?
>
> This should be a safe assumption for this driver. Remember, this
> driver just does offload memcpy, from one region to another. So the
>
On Sat, 2009-04-25 at 20:18 +0200, Christoph Hellwig wrote:
> On Thu, Apr 23, 2009 at 11:31:37AM +1000, Michael Ellerman wrote:
> > +#ifdef CONFIG_IRQSTACKS
>
> Wasn't there a plan to make CONFIG_IRQSTACKS the unconditional default?
Not sure. Looks like the 64-bit configs all turn it on, and all
On Tue, 03 Mar 2009 16:37:13 -0800 (PST)
David Miller wrote:
> From: Sean MacLennan
> Date: Tue, 3 Mar 2009 19:29:32 -0500
>
> > It has been. u carry the two... longer than I want to admit
> > since I worked on a sparc. Would GPIO based LEDS make sense on a sparc
> > platform? Is sparc
powerpc allmodconfig, current mainline:
drivers/video/logo/logo_linux_mono.c:11: error: logo_linux_mono_data causes a
section type conflict
switching it from __initconst to __initdata "fixes" it.
I'm (illegally) using gcc-4.1.0.
I assume this is an FAQ but I don't know what the A is ;)
__
On Mon, Apr 27, 2009 at 1:47 PM, Timur Tabi wrote:
> Adding Kumar to the CC: list, since he might pick up the patch.
>
Acked-by: Dan Williams
I agree with taking this through Kumar's tree.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://
Scott Wood wrote:
> I thought the driver only used the bit if the device tree indicated it
> was an 83xx-era DMA controller?
I just wanted to make sure it didn't do anything weird. It was the only
test I could think of that didn't involve PCI.
> That said, the bits are documented as specificall
On Mon, Apr 27, 2009 at 03:04:49PM -0500, Timur Tabi wrote:
> David Hawkins wrote:
>
> > Can you give me an example of non-PCI memory that would be
> > non-prefetchable that you'd like us to try? We can see if our
> > host CPUs have an area like that ... we just need to know
> > what device to loo
Adding Kumar to the CC: list, since he might pick up the patch.
Ira Snyder wrote:
> From 73e42fa58c93de8d4d429ba8e069b60c42037b58 Mon Sep 17 00:00:00 2001
> From: Ira W. Snyder
> Date: Thu, 23 Apr 2009 16:17:54 -0700
> Subject: [PATCH] fsldma: use PCI Read Multiple command
>
> By default, the F
Timur Tabi wrote:
David Hawkins wrote:
Ira will add your comment to the body of the code near
the PRC_RM command and submit a new patch.
I'd rather have it near the top where people can see it.
Looks like Ira had the same thought :)
Dave
___
Li
David Hawkins wrote:
> Ira will add your comment to the body of the code near
> the PRC_RM command and submit a new patch.
I'd rather have it near the top where people can see it.
--
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mail
On Mon, Apr 27, 2009 at 03:26:36PM -0500, Timur Tabi wrote:
> David Hawkins wrote:
>
> > PRC_RM - PCI read multiple
> >The default PCI read command used by the DMA controller is
> >PCI Read (PCI command 6h). When the burst length is 32-bytes
> >or longer, PCI Read Line (PCI command Eh)
Hi Timur,
PRC_RM - PCI read multiple
The default PCI read command used by the DMA controller is
PCI Read (PCI command 6h). When the burst length is 32-bytes
or longer, PCI Read Line (PCI command Eh) is used (undocumented
feature of the controller). Using PCI read multiple
(PCI com
Signed-off-by: Kumar Gala
---
arch/powerpc/boot/dts/ksi8560.dts | 13 +
arch/powerpc/boot/dts/mpc8536ds.dts| 13 +
arch/powerpc/boot/dts/mpc8540ads.dts | 13 +
arch/powerpc/boot/dts/mpc8541cds.dts | 13 ++
The first 4k region of CCSR space is well defined for local access
windows, CCSRBAR, etc. The second 4k region is well defined as
register for configuring and getting errors for the ECM coherency
module.
Signed-off-by: Kumar Gala
---
Documentation/powerpc/dts-bindings/ecm.txt | 64 +++
David Hawkins wrote:
> PRC_RM - PCI read multiple
>The default PCI read command used by the DMA controller is
>PCI Read (PCI command 6h). When the burst length is 32-bytes
>or longer, PCI Read Line (PCI command Eh) is used (undocumented
>feature of the controller). Using PCI read m
Hi Timur,
Would you like some sort of summary of this info for a commit
message?
That's probably overkill. I just want a sentence or two that tells
someone looking at the code casually that the behavior of reading PCI
memory might be different than what they expect.
Could you help us with t
Paul,
Can we possibly get this and the other pull requests dealt with and sent
to Linus so we might get such fixes in before he tags a -rc4.
thanks
- k
Please pull from 'merge' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git merge
to receive the following updat
Can you give me an example of non-PCI memory that would be
non-prefetchable that you'd like us to try? We can see if our
host CPUs have an area like that ... we just need to know
what device to look for first :)
You can mark the pci inbound window on the 83xx as non-prefetchable
(assuming 83xx
David Hawkins wrote:
> Can you give me an example of non-PCI memory that would be
> non-prefetchable that you'd like us to try? We can see if our
> host CPUs have an area like that ... we just need to know
> what device to look for first :)
H I was going to say any SOC device in the IMMR,
On Apr 27, 2009, at 3:00 PM, David Hawkins wrote:
Can you give me an example of non-PCI memory that would be
non-prefetchable that you'd like us to try? We can see if our
host CPUs have an area like that ... we just need to know
what device to look for first :)
You can mark the pci inbound wi
You can mark the pci inbound window on the 83xx as non-prefetchable
(assuming 83xx is host). On a x86 host I doubt there is any easy way
to get non-prefetchable memory.
One more note; we don't have access to a host-mode MPC8349EA,
our boards are all targets.
Cheers,
Dave
___
Can you give me an example of non-PCI memory that would be
non-prefetchable that you'd like us to try? We can see if our
host CPUs have an area like that ... we just need to know
what device to look for first :)
You can mark the pci inbound window on the 83xx as non-prefetchable
(assuming 83x
On Apr 27, 2009, at 2:48 PM, David Hawkins wrote:
Can you give me an example of non-PCI memory that would be
non-prefetchable that you'd like us to try? We can see if our
host CPUs have an area like that ... we just need to know
what device to look for first :)
You can mark the pci inbound wi
Would you like some sort of summary of this info for a commit
message?
That's probably overkill. I just want a sentence or two that tells
someone looking at the code casually that the behavior of reading PCI
memory might be different than what they expect.
Ok, will-do.
Would you like us
On Apr 27, 2009, at 2:31 PM, Kumar Gala wrote:
On Apr 24, 2009, at 1:24 AM, Michael Neuling wrote:
Index: linux-2.6-ozlabs/arch/powerpc/include/asm/cputable.h
===
--- linux-2.6-ozlabs.orig/arch/powerpc/include/asm/cputable.h
+++
David Hawkins wrote:
> Would you like some sort of summary of this info for a commit
> message?
That's probably overkill. I just want a sentence or two that tells
someone looking at the code casually that the behavior of reading PCI
memory might be different than what they expect.
> Would you l
On Apr 24, 2009, at 5:33 PM, Rogério Brito wrote:
This patch addresses the following issues:
01. makes CFQ the default scheduler, to be in line with the rest of
the kernel.
02. since linkstations are meant to store files, enable large blk
devices.
03. disable CONFIG_MIGRATION in in su
Hi all,
You are assuming the PCI memory space is prefetchable( no side effect)
for DMA. Is it possible that DMA is from non-prefetchable memory space?
This should be a safe assumption for this driver. Remember, this
driver just does offload memcpy, from one region to another. So the
PCI memo
On Apr 24, 2009, at 1:24 AM, Michael Neuling wrote:
Index: linux-2.6-ozlabs/arch/powerpc/include/asm/cputable.h
===
--- linux-2.6-ozlabs.orig/arch/powerpc/include/asm/cputable.h
+++ linux-2.6-ozlabs/arch/powerpc/include/asm/cputabl
On Apr 24, 2009, at 1:24 AM, Michael Neuling wrote:
Index: linux-2.6-ozlabs/arch/powerpc/mm/hash_native_64.c
===
--- linux-2.6-ozlabs.orig/arch/powerpc/mm/hash_native_64.c
+++ linux-2.6-ozlabs/arch/powerpc/mm/hash_native_64.c
@@ -3
The macro spin_event_timeout() takes a condition and timeout value
(in microseconds) as parameters. It spins until either the condition is true
or the timeout expires. It returns the result of the condition when the loop
was terminated.
This primary purpose of this macro is to poll on a hardware
Some time ago we had to disable init_hwif callback for PowerPC builds.
That was because of a historical IRQ overwrite in the driver, which
was causing IDE malfunction on the MPC8610HPCD PowerPC boards.
It's unclear whether this overwrite is still useful, but it is proven
to cause a bit of harm, an
On Apr 27, 2009, at 11:24 AM, Martyn Welch wrote:
The 'device_type = "soc";' line *is* needed in the DTS for
get_immrbase()
to return the correct address.
Signed-off-by: Martyn Welch
---
arch/powerpc/boot/dts/gef_ppc9a.dts |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
applied
On Mon, Apr 27, 2009 at 07:38:38AM +0200, Heiko Schocher wrote:
> 1) add in the soc node an "errata" node and in this "errata" node
>we can add all CPU specific errata as an example the qe_enet10
>errata, which above code covers:
What about errata discovered after the device tree is deploy
The first 4k region of CCSR space is well defined for local access
windows, CCSRBAR, etc. The second 4k region is well defined as
register for configuring and getting errors for the MPX coherency
module.
Signed-off-by: Kumar Gala
---
Documentation/powerpc/dts-bindings/fsl/mcm.txt | 64 +++
Signed-off-by: Kumar Gala
---
arch/powerpc/boot/dts/gef_ppc9a.dts| 13 +
arch/powerpc/boot/dts/gef_sbc310.dts | 13 +
arch/powerpc/boot/dts/gef_sbc610.dts | 13 +
arch/powerpc/boot/dts/mpc8610_hpcd.dts | 13 +
arch/po
On Mon, Apr 27, 2009 at 11:36 AM, Scott Wood wrote:
> On Mon, Apr 27, 2009 at 09:36:13AM -0600, Grant Likely wrote:
>> From: Grant Likely
>>
>> Previous rework to ucc_geth.c to add of_mdio support (net: Rework
>> ucc_geth driver to use of_mdio infrastructure) added a block of
>> code which broke
On Mon, Apr 27, 2009 at 11:18 AM, Albrecht Dreß wrote:
> Hi all,
>
> I have a question about the definition of the localbus on the Freescale
> 5200B (I'm testing with the Lite5200B board) with Kernel 2.6.29.1 which I
> could not figure out with the docs and the list archives...
>
> When I use 'com
On Mon, Apr 27, 2009 at 09:36:13AM -0600, Grant Likely wrote:
> From: Grant Likely
>
> Previous rework to ucc_geth.c to add of_mdio support (net: Rework
> ucc_geth driver to use of_mdio infrastructure) added a block of
> code which broke older openfirmware device trees which use an
> 'interface'
Hi all,
I have a question about the definition of the localbus on the Freescale
5200B (I'm testing with the Lite5200B board) with Kernel 2.6.29.1 which
I could not figure out with the docs and the list archives...
When I use 'compatible = "fsl,mpc5200b-lpb";' in the dts file, the
localbus
Kumar,
David has pulled my phylib changes into his -next tree. However, some
of the driver changes have been compile tested only due to lack of
hardware. Who can I ask to test the changes to the following files?
arch/powerpc/platforms/82xx/ep8248e.c |9 +-
drivers/net/fs_enet/fs_enet-m
The 'device_type = "soc";' line *is* needed in the DTS for get_immrbase()
to return the correct address.
Signed-off-by: Martyn Welch
---
arch/powerpc/boot/dts/gef_ppc9a.dts |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/gef_ppc9a.dts
b/arch/power
Oprofile is changing the naming it is using for the compatibility modes.
Instead of having compat-power, oprofile will go to family naming
convention and use ibm-compat-v. Currently only ibm-compat-v1 will
be defined.
The notion of compatibility events just started with POWER6. So there is
no way
On Apr 27, 2009, at 10:06 AM, Martyn Welch wrote:
I am using the config in the kernel ("arch/powerpc/configs/68xx/
gef_ppc9a_defconfig") as is, ditto for the DTS.
CONFIG_PHYS_64BIT is not set.
However, looking into it a bit further 'device_type = "soc";' is
missing from the DTS file, so I
On Sun, Apr 26, 2009 at 3:00 AM, Joakim Tjernlund
wrote:
> Change in fixed link case, see inline.
>
>>
>> From: Grant Likely
>>
>> This patch simplifies the driver by making use of more common code.
>>
>> Signed-off-by: Grant Likely
>> Acked-by: Andy Fleming
>> ---
>>
>> drivers/net/ucc_geth.c
From: Grant Likely
Previous rework to ucc_geth.c to add of_mdio support (net: Rework
ucc_geth driver to use of_mdio infrastructure) added a block of
code which broke older openfirmware device trees which use an
'interface' property in the phy node to describe the connection
between the MAC and th
Andres F Marquez wrote:
After struggling for several days with this issue we have finally
taken a different approach to solve our problem. We wanted to interface
our CPU (MPC8265) with a FPGA through a serial connection. Now, we are
using a parallel interface through the data bus (defining a
Kumar Gala wrote:
On Apr 23, 2009, at 7:54 AM, Martyn Welch wrote:
Kumar Gala wrote:
Removed the need for asm/mpc86xx.h as it was only used in mpc86xx_smp.c
and just moved the defines it cared about into there. Also fixed up
the ioremap to only map the one 4k page we need access to and to
i
On Mon, Apr 27, 2009 at 4:09 AM, Liu Dave-R63238 wrote:
> You are assuming the PCI memory space is prefetchable( no side effect)
> for DMA.
> Is it possible that DMA is from non-prefetchable memory space?
This should be a safe assumption for this driver. Remember, this
driver just does offload
Hi, Dave.
On Apr 27 2009, David Miller wrote:
> You can fix the mace_set_timeout() function arguments by having a
> helper function that simply wraps around it and provides the second
> expection of argument types.
Hummm, this means that I'm not that bad... The wrapper function was the
first thin
On Apr 23, 2009, at 7:54 AM, Martyn Welch wrote:
Kumar Gala wrote:
Removed the need for asm/mpc86xx.h as it was only used in
mpc86xx_smp.c
and just moved the defines it cared about into there. Also fixed up
the ioremap to only map the one 4k page we need access to and to
iounmap
when we
On Sun, Apr 26, 2009 at 10:27 PM, Jon Smirl wrote:
> On Mon, Apr 27, 2009 at 12:08 AM, Grant Likely
> wrote:
>> On Sun, Apr 26, 2009 at 1:53 PM, Jon Smirl wrote:
>>> Rename the public DMA exports into the global name space so that the DMA
>>> code can be built as a module.
>>>
>>> Signed-off-by
On Sun, Apr 26, 2009 at 10:24 PM, John Williams
wrote:
> To MicroBlazers and other interested parties:
>
> Currently the MicroBlaze kernel boot-time ABI requires r7 to point to
> a valid DTB, whereupon in early kernel setup the DTB is copied to a
> statically allocated 16k memory region inside the
Hello Scott,
Thank you for your support.
After struggling for several days with this issue we have finally
taken a different approach to solve our problem. We wanted to interface
our CPU (MPC8265) with a FPGA through a serial connection. Now, we are
using a parallel interface through the dat
On Thu, 2009-04-23 at 16:27 -0600, Gary Thomas wrote:
> I don't think any of this matters. It turns out that even
> the 2.6.26 kernel fails on an identical board with a newer
> revision of the 8347 chip. I'm sure that the problem is
> that the Coral-P fails when mapped to 0 (PCI relative).
Ther
On Mon, Apr 27, 2009 at 3:54 AM, David Miller wrote:
> From: Grant Likely
> Date: Sat, 25 Apr 2009 16:52:34 -0600
>
>> This series adds common code for reading PHY connection data out of
>> the OpenFirmware device tree. This simplifies the network drivers
>> which use the device tree and which c
Hi,
I've got the following error on custom board based on AMCC 405EXr
running 2.6.27 kernel, with ndfc driver back ported from 2.6.29 (to support
OF partitions on NAND). This happened once, right after reboot. I was
unable to reproduce this. The NAND device is Samsung K9K8G08U0B,
1GB with 2k pag
On Fri, 2009-04-24 at 13:01 +0200, Arnd Bergmann wrote:
> I just said in another email thread that we would need a CONFIG_DCR
> option that DCR using drivers should depend on, if it ever happened
> outside of powerpc.
>
> Well, apparently this happened earlier than I expected.
Sadly...
Cheers,
B
From: Rogério Brito
Date: Mon, 27 Apr 2009 09:16:33 -0300
> Is this anything close to what needs to be done? It's not without
> failures, because the function mace_set_timeout receives a pointer to a
> struct net_device, but is marked inline and is used by mace_tx_timeout,
> which receives an uns
Hi, Dave.
On Apr 26 2009, David Miller wrote:
> Or, if you're bored, feel free to convert the mace driver over
> to netdev_ops :-)
Is this anything close to what needs to be done? It's not without
failures, because the function mace_set_timeout receives a pointer to a
struct net_device, but is ma
On Mon, Apr 27, 2009 at 5:09 PM, Liu Dave-R63238 wrote:
>> By default, the Freescale 83xx DMA controller uses the PCI Read Line
>> command when reading data over the PCI bus. Setting the
>> controller to use the PCI Read Multiple command instead allows the
>> controller to read much larger bursts
From: Grant Likely
Date: Sat, 25 Apr 2009 16:52:34 -0600
> This series adds common code for reading PHY connection data out of
> the OpenFirmware device tree. This simplifies the network drivers
> which use the device tree and which currently implement their own
> solutions for reading the PHY d
> By default, the Freescale 83xx DMA controller uses the PCI Read Line
> command when reading data over the PCI bus. Setting the
> controller to use the PCI Read Multiple command instead allows the
> controller to read much larger bursts of data, which provides a
drastic
> speed increase.
IIRC, t
On Fri, 2009-04-24 at 10:51 +0100, Mel Gorman wrote:
> I'm seeing some tests with sysbench+postgres+large pages fail on ppc64
> although a very clear pattern is not forming as to what exactly is
> causing it. However, the libhugetlbfs regression tests (make && make
> func) are triggering the follow
On Sat, Apr 25, 2009 at 2:35 AM, Ira Snyder wrote:
> By default, the Freescale 83xx DMA controller uses the PCI Read Line
> command when reading data over the PCI bus. Setting the controller to use
> the PCI Read Multiple command instead allows the controller to read much
> larger bursts of data,
>--- a/drivers/mtd/ofpart.c
>+++ b/drivers/mtd/ofpart.c
>@@ -48,7 +48,9 @@ int __devinit of_mtd_parse_partitions(struct device *dev,
>
> /* check if this is a partition node */
> partname = of_get_property(pp, "name", &len);
>- if (strcmp(partname, "partiti
85 matches
Mail list logo