When we demote a slice from 64k to 4k, and we are about to insert an
HPTE for a 4k subpage and we notice that there is an existing 64k
HPTE, we first invalidate that HPTE before inserting the new 4k
subpage HPTE. Since the bits that encode which hash bucket the old
HPTE was in overlap with the bit
Currently when a 32 bit process is exec'd on a powerpc 64 bit host the values
of the top three bytes of the personality are clobbered. This patch adds a
check in the SET_PERSONALITY macro that will carry all the values in the top
three bytes across the exec.
Signed-off-by: Eric B Munson <[EMAIL P
Eric B Munson writes:
> Currently when a 32 bit process is exec'd on a powerpc 64 bit host the values
> of the top three bytes of the personality are clobbered. This patch adds a
> check in the SET_PERSONALITY macro that will carry all the values in the top
> three bytes across the exec.
>
> Sig
Hi Stephen,
next-20080617 kernel build fails with randconfig on a powerpc box
arch/powerpc/kernel/module_32.c: In function ‘module_find_bug’:
arch/powerpc/kernel/module_32.c:377: error: increment of pointer to unknown
structure
arch/powerpc/kernel/module_32.c:377: error: arithmetic on pointer
At present, if we have a kernel with a 64kB page size, and some
process maps something that has to be mapped with 4kB pages (such as a
cache-inhibited mapping on POWER5+, or the eHCA infiniband queue-pair
pages), we change the process to use 4kB pages everywhere. This hurts
the performance of HPC
On Tue, Jun 17, 2008 at 5:03 PM, John Rigby <[EMAIL PROTECTED]> wrote:
> Fixed all errors and warnings that checkpatch.pl
> reports if this was a new submission.
> Also changed instances of fec_t to struct fec in
> mac-fec.c and mii-fec.c.
Nit: checkpatch is not law; particularly in the case of wh
> >
> >I'm not sure I understand what you're looking for, but I don't see
> >anything wrong with something like this (apart from missing help text):
> >
> >config FS_ENET
> > bool
> > select MII
> > select PHYLIB
> >
> >config FS_ENET_HAS_SCC
> > bool "Freescale CPM SCC Etherne
Sorry, I thought I was doing the right thing to base the patch on Kumar's
patch that removes the CONFIG_PPC_CPM_NEW_BINDING stuff. That is likely why
it did not apply.
On Tue, Jun 17, 2008 at 9:54 PM, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> John Rigby wrote:
>
>> Fixed all errors and warnings t
John Rigby wrote:
Fixed all errors and warnings that checkpatch.pl
reports if this was a new submission.
Also changed instances of fec_t to struct fec in
mac-fec.c and mii-fec.c.
This is in preparation of adding MPC5121 support.
Signed-off-by: John Rigby <[EMAIL PROTECTED]>
---
drivers/net/fs_
Josh Boyer wrote:
The arch/ppc sub-tree has been removed in the powerpc git tree. The old
ibm_emac driver is no longer used by anything as a result of this. This
removes it, leaving the ibm_newemac driver as the proper driver to use for
PowerPC boards with the EMAC hardware.
Signed-off-by: Jos
Josh Boyer wrote:
The ibm_newemac driver requires ether_crc to be defined. Apparently it is
possible to generate a .config without CONFIG_CRC32 set which causes the
following link errors if IBM_NEW_EMAC is selected:
LD .tmp_vmlinux1
drivers/built-in.o: In function `emac_hash_mc':
core.c:
On Tue, Jun 17, 2008 at 07:35:23PM -0400, Josh Boyer wrote:
> The arch/ppc sub-tree has been removed in the powerpc git tree. The old
> ibm_emac driver is no longer used by anything as a result of this. This
> removes it, leaving the ibm_newemac driver as the proper driver to use for
> PowerPC bo
On Tue, Jun 17, 2008 at 6:35 PM, Stephen Rothwell <[EMAIL PROTECTED]>
wrote:
> Hi John,
>
> You should factor out the fec_t -> struct fec change into an earlier
> patch of its own.
Ok, I'll separate that from the checkpatch fixes.
>
>
> On Tue, 17 Jun 2008 11:48:00 -0600 John Rigby <[EMAIL PROTE
Add CONFIG_VSX config build option. Must compile with POWER4, FPU and ALTIVEC.
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/Kconfig.cputype | 16
1 file changed, 16 insertions(+)
Index: linux-2.6-ozlabs/arch/powerpc/platforms/Kconfig.cputype
This patch extends the floating point save and restore code to use the
VSX load/stores when VSX is available. This will make FP context
save/restore marginally slower on FP only code, when VSX is available,
as it has to load/store 128bits rather than just 64bits.
Mixing FP, VMX and VSX code will
This adds the macros for the VSX load/store instruction as most
binutils are not going to support this for a while.
Also add VSX register save/restore macros and vsr[0-63] register definitions.
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
include/asm-powerpc/ppc_asm.h | 127 +
Add a VSX CPU feature. Also add code to detect if VSX is available
from the device tree.
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/prom.c |3 +++
include/asm-powerpc/cputable.h | 13 +
2 files changed, 16 insertions(+)
Index: linux-2.6-ozl
The layout of the new VSR registers and how they overlap on top of the
legacy FPR and VR registers is:
VSR doubleword 0 VSR doubleword 1
VSR[0] | FPR[0]|
Make load_up_fpu and load_up_altivec callable so they can be reused by
the VSX code.
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/fpu.S|2 +-
arch/powerpc/kernel/head_32.S|6 --
arch/powerpc/kernel/head_64.S|8 +---
arch/powerpc
Move the altivec_unavailable code, to make room at 0xf40 where the
vsx_unavailable exception will be.
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/head_64.S |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/head
We are going to change where the floating point registers are stored
in the thread_struct, so in preparation add some macros to access the
floating point registers. Update all code to use these new macros.
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/align.c
If we set the SPE MSR bit in save_user_regs we can blow away the VEC
bit. This will never happen in reality, but it looks bad.
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/signal_32.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
Index: linux-
The following set of patches adds Vector Scalar Extentions (VSX)
support for POWER7. Includes context switch, ptrace and signals support.
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
This series is on top of the POWER7 cputable entry patch.
Paulus: please consider for your 2.6.27 tre
Add a cputable entry for the POWER7 processor.
Also tell firmware that we know about POWER7.
Signed-off-by: Michael Neuling <[EMAIL PROTECTED]>
---
Paulus: please consider for your 2.6.27 tree.
arch/powerpc/kernel/cputable.c | 25 +
arch/powerpc/kernel/misc.S
On Wed, 18 Jun 2008 10:34:43 +1000
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-06-17 at 20:11 -0400, Sean MacLennan wrote:
> > On Tue, 17 Jun 2008 19:35:23 -0400
> > Josh Boyer <[EMAIL PROTECTED]> wrote:
> >
> > > The arch/ppc sub-tree has been removed in the powerpc git tree
On Tue, 2008-06-17 at 20:11 -0400, Sean MacLennan wrote:
> On Tue, 17 Jun 2008 19:35:23 -0400
> Josh Boyer <[EMAIL PROTECTED]> wrote:
>
> > The arch/ppc sub-tree has been removed in the powerpc git tree. The
> > old ibm_emac driver is no longer used by anything as a result of
> > this. This remo
Hi John,
You should factor out the fec_t -> struct fec change into an earlier
patch of its own.
On Tue, 17 Jun 2008 11:48:00 -0600 John Rigby <[EMAIL PROTECTED]> wrote:
>
> +++ b/drivers/net/fs_enet/fec_mpc5121.h
> +#include
Nothing in this file uses anything in asm/cpm.h, so it shouldn't be
i
On Tue, 17 Jun 2008 19:35:23 -0400
Josh Boyer <[EMAIL PROTECTED]> wrote:
> The arch/ppc sub-tree has been removed in the powerpc git tree. The
> old ibm_emac driver is no longer used by anything as a result of
> this. This removes it, leaving the ibm_newemac driver as the proper
> driver to use
The answer is that mpic_assign_isu(mpic, 1, paddr + 0x11000) places the initial
base register
for isu 1 on a reserved location in the PIC register map (see *). I guess you
can infer from this
that no badness occurs when you write to a reserved location on the PIC.
That aside, when you walk thro
Kumar Gala writes:
> The new e500mc core from Freescale is based on the e500v2 but with the
> following changes:
>
> * Supports only the Enhanced Debug Architecture (DSRR0/1, etc)
> * Floating Point
> * No SPE
> * Supports lwsync
> * Doorbell Exceptions
> * Hypervisor
Isn't the cache line size d
Hi Simon,
Here's what I found with spending a little time on the problem.
In the driver file xlltemac_main.c, there are some values to tune the DMA SG
interrupt coalescing.
Changing these values down to 1 (all) caused the ping time to go down small (.2
- .3 ms). I'm not saying you should use
On Tue, 17 Jun 2008, Scott Wood wrote:
Sam Ravnborg wrote:
In general when you select a symbol that has dependencies you are almost
always on the wrong track.
more specific options should make sure that they never select it when the
dependencies aren't met.
Sure, in theory that would work
The ibm_newemac driver requires ether_crc to be defined. Apparently it is
possible to generate a .config without CONFIG_CRC32 set which causes the
following link errors if IBM_NEW_EMAC is selected:
LD .tmp_vmlinux1
drivers/built-in.o: In function `emac_hash_mc':
core.c:(.text+0x2f524): und
Fixed all errors and warnings that checkpatch.pl
reports if this was a new submission.
Also changed instances of fec_t to struct fec in
mac-fec.c and mii-fec.c.
This is in preparation of adding MPC5121 support.
Signed-off-by: John Rigby <[EMAIL PROTECTED]>
---
drivers/net/fs_enet/fs_enet-main.c
Add support for MPC512x to fs_enet driver
MPC5121 has an FEC core that is nearly identical to the FEC
in 8xx. The only problem is that the registers locations have
been shuffled. Because of this shuffling of registers, one needs
a different structure to describe the 5121 FEC. This is not a huge
Note: This patch series assumes Kumar's Remove
!CONFIG_PPC_CPM_NEW_BINDING patch has been applied.
http://patchwork.ozlabs.org/linuxppc/patch?q=kumar&id=18939
Addresses all comments to previous patch.
Split the patch into two parts:
Part 1 fixes all problems reported by checkpatch.pl
and change
Hi, mainly a couple of coding style things, but one minor bug (I
think).
[EMAIL PROTECTED] wrote:
> From: Sonny Rao <[EMAIL PROTECTED]>
>
> +static int bsr_mmap(struct file *filp, struct vm_area_struct *vma)
> +{
> + unsigned long size = vma->vm_end - vma->vm_start;
> + struct bsr_dev *
On Tue, 17 Jun 2008 18:34:39 -0400
Josh Boyer <[EMAIL PROTECTED]> wrote:
> A recent commit added support for the new 440x6 and 464 cores that have the
> added WL1, IL1I, IL1D, IL2I, and ILD2 bits for the caching attributes in the
> TLBs. The new bits were cleared in the finish_tlb_load function,
A recent commit added support for the new 440x6 and 464 cores that have the
added WL1, IL1I, IL1D, IL2I, and ILD2 bits for the caching attributes in the
TLBs. The new bits were cleared in the finish_tlb_load function, however a
similar bit of code was missed in the DataStorage interrupt vector.
S
On Tue, Jun 17, 2008 at 02:31:03PM -0700, Stephen Neuendorffer wrote:
> I'm very interested in trying to factor out board data from the device
> tree, but for slightly different reasons, I think. (Although I don't
> exactly understand what you're proposing...)
Sorry, I should have gone into a *l
Mark,
I'm very interested in trying to factor out board data from the device
tree, but for slightly different reasons, I think. (Although I don't
exactly understand what you're proposing...)
In FPGA-based designs, it would be nice to be able to describe a device
tree fragment for the board, whi
From: Sonny Rao <[EMAIL PROTECTED]>
Adds a character driver for BSR support on IBM POWER systems including
Power5 and Power6. The BSR is an optional processor facility not currently
implemented by any other processors. It's primary purpose is large SMP
synchronization. More details on the BS
Sam Ravnborg wrote:
But I was misguided by:
+config FS_ENET_MPC5121_FEC
+ select FS_ENET
This is not good.
Why not, if we get rid of the prompt on FS_ENET?
In general when you select a symbol that has dependencies you are almost
always on the wrong track.
The dependencies on FS_ENET coul
On Tue, Jun 17, 2008 at 03:03:54PM -0500, Scott Wood wrote:
> Sam Ravnborg wrote:
> >On Tue, Jun 17, 2008 at 02:33:28PM -0500, Scott Wood wrote:
> >>John Rigby wrote:
> >>>config FS_ENET
> >>> tristate "Freescale Ethernet Driver"
> >>>- depends on CPM1 || CPM2
> >>>+ depends on CP
Recently there's been quite a bit of discussion surrounding how to set
up machine specific hardware that can't readily be represented in the
device tree. I was wondering if one way of solving these problems might
be to provide a mechanism for drivers to load based on board type rather
than by bind
Sam Ravnborg wrote:
On Tue, Jun 17, 2008 at 02:33:28PM -0500, Scott Wood wrote:
John Rigby wrote:
config FS_ENET
tristate "Freescale Ethernet Driver"
- depends on CPM1 || CPM2
+ depends on CPM1 || CPM2 || FS_ENET_MPC5121_FEC
select MII
select PHYLIB
+config FS_
On Tue, Jun 17, 2008 at 01:43:40PM -0600, John Rigby wrote:
> Thanks Sam, Scott already addressed most of your issues. The
> background that you are likely missing and I will add to the patch
> header is that the 5121 has an FEC core with all the same registers as
> 8xx except the order of the
On Tue, Jun 17, 2008 at 02:33:28PM -0500, Scott Wood wrote:
> John Rigby wrote:
> > config FS_ENET
> >tristate "Freescale Ethernet Driver"
> >- depends on CPM1 || CPM2
> >+ depends on CPM1 || CPM2 || FS_ENET_MPC5121_FEC
> >select MII
> >select PHYLIB
> >
> >+con
On Jun 17, 2008, at 2:37 PM, Scott Wood wrote:
Scott Wood wrote:
Kumar Gala wrote:
Also, there is a direction that does work. You can run an e500v2
kernel on an e500mc. Its just going the other way around that can
be an issue.
Actually, wouldn't the kernel need to set HID0[DCBZ32] for an
On Jun 17, 2008, at 2:26 PM, Scott Wood wrote:
Kumar Gala wrote:
Also, there is a direction that does work. You can run an e500v2
kernel on an e500mc. Its just going the other way around that can
be an issue.
Maybe have a "choice" config option for minimum supported e500
version, with
On Tue, Jun 17, 2008 at 02:31:31PM -0500, Scott Wood wrote:
> Sam Ravnborg wrote:
> >>+ data = of_get_property(ofdev->node, "fsl,align-tx-packets", &len);
> >>+ if (data && len == 4)
> >>+ fpi->align_tx_packets = *data;
> >>+
> >Where did "4" come from. USe a define with a desriptive
Thanks Sam, Scott already addressed most of your issues. The
background that you are likely missing and I will add to the patch
header is that the 5121 has an FEC core with all the same registers as
8xx except the order of the registers is scrambled. Fortunately the old
FEC only exists on CP
Scott Wood wrote:
Kumar Gala wrote:
Also, there is a direction that does work. You can run an e500v2
kernel on an e500mc. Its just going the other way around that can be
an issue.
Actually, wouldn't the kernel need to set HID0[DCBZ32] for an e500v2
kernel to run on e500mc?
Grr, I meant L
Kumar Gala wrote:
Also, there is a direction that does work. You can run an e500v2 kernel
on an e500mc. Its just going the other way around that can be an issue.
Actually, wouldn't the kernel need to set HID0[DCBZ32] for an e500v2
kernel to run on e500mc?
-Scott
___
John Rigby wrote:
config FS_ENET
tristate "Freescale Ethernet Driver"
- depends on CPM1 || CPM2
+ depends on CPM1 || CPM2 || FS_ENET_MPC5121_FEC
select MII
select PHYLIB
+config FS_ENET_MPC5121_FEC
+ bool "Freescale MPC512x FEC driver"
+ depends
Sam Ravnborg wrote:
+ data = of_get_property(ofdev->node, "fsl,align-tx-packets", &len);
+ if (data && len == 4)
+ fpi->align_tx_packets = *data;
+
Where did "4" come from. USe a define with a desriptive name.
It's sizeof(u32), i.e. one device tree cell. This is fair
Kumar Gala wrote:
Also, there is a direction that does work. You can run an e500v2 kernel
on an e500mc. Its just going the other way around that can be an issue.
Maybe have a "choice" config option for minimum supported e500 version,
with higher settings being better optimized but incompatib
Hi John - a few nitpicks.
>
> +config FS_ENET_MPC5121_FEC
> + bool "Freescale MPC512x FEC driver"
> + depends on PPC_MPC512x
> + select FS_ENET
> + select PPC_CPM_NEW_BINDING
> + default y
help is missing. I assume you can help the casual reader a bit by being
a bit more ver
Add support for MPC512x to fs_enet driver
NOTE: This patch is not perfect, there are still some CONFIG_CPM1
ifdefs. But in reality this is not a problem since CPM2 and FEC
are mutually exclusive. This patch does not break MULTIPLATFORM
kernels.
arch/powerpc/boot/dts/mpc5121ads.dts
Fix a t
On Jun 17, 2008, at 1:25 PM, Scott Wood wrote:
Kumar Gala wrote:
On Jun 17, 2008, at 11:23 AM, Scott Wood wrote:
We should probably depend on !PPC_85xx until we can support such a
configuration, rather than have it break in less obvious ways.
I don't see any reason for this. While our market
Kumar Gala wrote:
On Jun 17, 2008, at 11:23 AM, Scott Wood wrote:
We should probably depend on !PPC_85xx until we can support such a
configuration, rather than have it break in less obvious ways.
I don't see any reason for this. While our marketing may say its not an
85xx anymore its pretty
On Jun 17, 2008, at 11:23 AM, Scott Wood wrote:
On Tue, Jun 17, 2008 at 09:01:39AM -0500, Kumar Gala wrote:
diff --git a/arch/powerpc/platforms/Kconfig.cputype b/arch/powerpc/
platforms/Kconfig.cputype
index f7efaa9..1a1ccfb 100644
--- a/arch/powerpc/platforms/Kconfig.cputype
+++ b/arch/power
This patch should go through Jeff Garzik and be CCed to
[EMAIL PROTECTED]
John Rigby wrote:
drivers/net/fs_enet/fs_enet-main.c
Add a routine for conditionally copying TX skb's that
are not aligned. Only do this if fep->fpi->align_tx_packets
is set.
In fs_enet_probe set fpi->a
Add support for MPC512x to fs_enet driver
NOTE: This patch is not perfect, there are still some CONFIG_CPM1
ifdefs. But there it should support multiplatform kernels
since CPM2 and FEC are mutually exclusive.
arch/powerpc/boot/dts/mpc5121ads.dts
Fix a typo in the file header and add ethern
On Jun 17, 2008, at 11:11 AM, Nate Case wrote:
This adds support for hardware configurations that don't match the
chip default register settings (e.g., 16-bit data bus, DACK and
DREQ pulled up instead of down, analog overcurrent mode).
These settings are passed in via the OF device tree. The
This was pointed out by Detlev Zundel when this code was being
added to U-boot.
Signed-off-by: Scott Wood <[EMAIL PROTECTED]>
---
Note that nothing currently uses the le16 version, so it's not
an urgent bugfix.
include/asm-powerpc/io.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Hi Simon,
I'm assuming that you have caches enabled in the hardware design.
Have you profiled the performance of the hardware design independent of Linux
to make sure you are getting good memory performance?
We haven't done performance testing yet on the open source Linux driver yet as
our imm
On Tue, Jun 17, 2008 at 09:01:39AM -0500, Kumar Gala wrote:
> diff --git a/arch/powerpc/platforms/Kconfig.cputype
> b/arch/powerpc/platforms/Kconfig.cputype
> index f7efaa9..1a1ccfb 100644
> --- a/arch/powerpc/platforms/Kconfig.cputype
> +++ b/arch/powerpc/platforms/Kconfig.cputype
> @@ -95,6 +95,
This adds support for hardware configurations that don't match the
chip default register settings (e.g., 16-bit data bus, DACK and
DREQ pulled up instead of down, analog overcurrent mode).
These settings are passed in via the OF device tree. The PCI
interface still assumes the same default values
On Jun 17, 2008, at 10:04 AM, Olof Johansson wrote:
On Jun 17, 2008, at 9:42 AM, Kumar Gala wrote:
But: since the cacheline is available in cputable, it can still be
used at runtime, so as long as the alignments are large enough,
stuff like the dcbz loops should still be OK (might need an
On Jun 17, 2008, at 9:42 AM, Kumar Gala wrote:
But: since the cacheline is available in cputable, it can still be
used at runtime, so as long as the alignments are large enough,
stuff like the dcbz loops should still be OK (might need an audit
though to make sure there's nothing missed). Wi
On Jun 17, 2008, at 9:32 AM, Olof Johansson wrote:
On Jun 17, 2008, at 8:56 AM, Kumar Gala wrote:
On Jun 16, 2008, at 2:26 PM, Olof Johansson wrote:
On Jun 16, 2008, at 10:46 AM, Kumar Gala wrote:
+ .machine_check = machine_check_e500,
+ .platform
On Jun 17, 2008, at 8:56 AM, Kumar Gala wrote:
On Jun 16, 2008, at 2:26 PM, Olof Johansson wrote:
On Jun 16, 2008, at 10:46 AM, Kumar Gala wrote:
+ .machine_check = machine_check_e500,
+ .platform = "ppc4080",
Do you really want the platfo
The new e500mc core from Freescale is based on the e500v2 but with the
following changes:
* Supports only the Enhanced Debug Architecture (DSRR0/1, etc)
* Floating Point
* No SPE
* Supports lwsync
* Doorbell Exceptions
* Hypervisor
---
* Dropped the SMP changes to Kconfig
* Changed plaform to ppc
Sulibhavi, Madhvesh wrote on Thursday, June 12, 2008 7:59 PM
> > > static void __kprobes prepare_singlestep(struct kprobe *p, struct
> > > pt_regs *regs)
> > > {
> > > +#ifdef CONFIG_BOOKE
> > > + regs->msr &= ~(MSR_EE); /* Turn off 'Externel Interrupt' bits */
> > > + regs->msr &= ~(MSR_CE); /* Tu
On Jun 16, 2008, at 2:26 PM, Olof Johansson wrote:
On Jun 16, 2008, at 10:46 AM, Kumar Gala wrote:
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -1522,6 +1522,21 @@ static struct cpu_spec __initdata
cpu_specs[] = {
.machine_check = ma
Hi all,
So, i'm using a Avnet Virtex 4 fx12 mini module.
I solved my ethernet speed negotiation problem using the kernel option
MARVELL_..._MII or other PHY.
It work fine, my rootfs is on nfs server.
But the speed isn't great. I takes serverals ms (2 to 4 ms) to answer a ping
request (packet s
On Jun 16, 2008, at 7:06 PM, Benjamin Herrenschmidt wrote:
On Mon, 2008-06-16 at 10:46 -0500, Kumar Gala wrote:
The new e500mc core from Freescale is based on the e500v2 but with
the
following changes:
* Supports only the Enhanced Debug Architecture (DSRR0/1, etc)
* Floating Point
* No SPE
Actually we're running 2.6.26-rc6 with MPC8343 and MPC5200B based boards.
Our kernel driver implements a read functions that initiates a DMA
operation into that user memory - nothing special.
For testing purposes this memory can be touched from the kernel using
memset.
1. User memory is translate
Hi,
Suspend/resume ("echo mem > /sys/power/state") does not work for me
with vanilla kernels -- the system does not suspend correctly and just
hangs. The attached patch fixes this so suspend/resume works:
1) of_iomap does not map the whole 0xC of the MPC5200 for me, so
saving registers does n
This patch adds MDMA/UDMA support (using BestComm for DMA) on the MPC5200
platform.
Based heavily on previous work by Freescale (Bernard Kuhn, John Rigby)
and Domen Puncer.
Using a SanDisk Extreme IV CF card I get read speeds of approximately
26.70 MB/sec.
The BestComm ATA task priority was chan
On Sat, May 24, 2008 at 12:43 AM, Grant Likely
<[EMAIL PROTECTED]> wrote:
> On Wed, May 21, 2008 at 6:17 PM, David Brownell <[EMAIL PROTECTED]> wrote:
>> On Friday 16 May 2008, Grant Likely wrote:
>>>
>>> This patch splits the allocation and registration portions of code out
>>> of spi_new_device()
82 matches
Mail list logo
