Re: [PATCH 4/6] Add ppc_function_entry() which gets the entry point for a function

On Thu, 2008-05-29 at 16:37 +1000, Benjamin Herrenschmidt wrote: > On Thu, 2008-05-29 at 16:20 +1000, Michael Ellerman wrote: > > Because function pointers point to different things on 32-bit vs > > 64-bit, > > add a macro that deals with dereferencing the OPD on 64-bit. The soon > > to > > be merg

Re: [PATCH 4/6] Add ppc_function_entry() which gets the entry point for a function

On Thu, 2008-05-29 at 16:20 +1000, Michael Ellerman wrote: > Because function pointers point to different things on 32-bit vs > 64-bit, > add a macro that deals with dereferencing the OPD on 64-bit. The soon > to > be merged ftrace wants this, as well as other code I am working on. > > Signed-off-

Re: [PATCH 3/6] Make create_branch() return errors if the branch target is too large

On Thu, 2008-05-29 at 16:20 +1000, Michael Ellerman wrote: > If you pass a target value to create_branch() which is more than 32MB - 4, > or - 32MB away from the branch site, then it's impossible to create an > immediate branch. The current code doesn't check, which will lead to us > creating a bra

Re: [PATCH 2/6] Allow create_branch() to return errors

On Thu, 2008-05-29 at 16:20 +1000, Michael Ellerman wrote: > Currently create_branch() creates a branch instruction for you, and patches > it into the call site. In some circumstances it would be nice to be able to > create the instruction and patch it later, and also some code might want > to chec

Re: [PATCH 1/6] Move code patching code into arch/powerpc/lib/code-patching.c

On Thu, 2008-05-29 at 16:20 +1000, Michael Ellerman wrote: > We currently have a few routines for patching code in asm/system.h, because > they didn't fit anywhere else. I'd like to clean them up a little and add > some more, so first move them into a dedicated C file - they don't need to > be inli

[PATCH 6/6] Add PPC_NOP_INSTR, a hash define for the preferred nop instruction

A bunch of code has hard-coded the value for a "nop" instruction, it would be nice to have a #define for it. Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]> --- arch/powerpc/kernel/cputable.c |3 ++- arch/powerpc/kernel/crash_dump.c|2 +- arch/powerpc/kernel/module_64.c |

[PATCH 5/6] Add tests for the code patching code, and introduce checking functions

Some code I am working on wants to check that the code it's patching is what it expects, so add three functions which check the passed instruction to see what it is. Add some tests for those routines, and also test the results of the existing create_branch() function using the new routines. It wo

[PATCH 4/6] Add ppc_function_entry() which gets the entry point for a function

Because function pointers point to different things on 32-bit vs 64-bit, add a macro that deals with dereferencing the OPD on 64-bit. The soon to be merged ftrace wants this, as well as other code I am working on. Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]> --- include/asm-powerpc/code-pa

[PATCH 3/6] Make create_branch() return errors if the branch target is too large

If you pass a target value to create_branch() which is more than 32MB - 4, or - 32MB away from the branch site, then it's impossible to create an immediate branch. The current code doesn't check, which will lead to us creating a branch to somewhere else - which is bad. For code that cares to check

[PATCH 2/6] Allow create_branch() to return errors

Currently create_branch() creates a branch instruction for you, and patches it into the call site. In some circumstances it would be nice to be able to create the instruction and patch it later, and also some code might want to check for errors in the branch creation before doing the patching. A fu

[PATCH 1/6] Move code patching code into arch/powerpc/lib/code-patching.c

We currently have a few routines for patching code in asm/system.h, because they didn't fit anywhere else. I'd like to clean them up a little and add some more, so first move them into a dedicated C file - they don't need to be inlined. While we're moving the code, drop create_function_call(), it'

[PATCH] [POWERPC] Free a PTE bit on ppc64 with 64K pages

This patch frees a PTE bit when using 64K pages on ppc64. This is done by getting rid of the separate _PAGE_HASHPTE bit. Instead, we just test if any of the 16 sub-page bits is set. For non-combo pages (ie. real 64K pages), we set SUB0 and the location encoding in that field. Signed-off-by: Benjam

Re: [RFC] POWERPC: Merge 32 and 64-bit dma code

On Fri, 23 May 2008 06:06:50 pm Mark Nelson wrote: > On Thu, 1 May 2008 09:36:43 am Becky Bruce wrote: > > > > I essentially adopt the 64-bit dma code, with some changes to support > > 32-bit systems, including HIGHMEM. dma functions on 32-bit are now > > invoked via accessor functions which call

Re: JFFS2 FS not writeable

So I found something that looks suspicious to me. This may not be a fsl_elbc_nand.c problem, but a more general problem. Shortly after mounting the root filesystem, which is a jffs2 on a large page NAND device (my board is based on the MPC8313) the kernel appears to read the device starting just

Re: [PATCH] Add support for binary includes.

On Thu, May 29, 2008 at 09:58:59AM +1000, David Gibson wrote: > On Tue, May 27, 2008 at 12:59:32PM -0500, Jon Loeliger wrote: > > Kumar Gala wrote: > >> > >> On Feb 25, 2008, at 6:39 PM, David Gibson wrote: > >> > >>> On Wed, Feb 20, 2008 at 01:19:41PM -0600, Scott Wood wrote: > A property's d

Re: [PATCH] Add support for binary includes.

On Tue, May 27, 2008 at 12:59:32PM -0500, Jon Loeliger wrote: > Kumar Gala wrote: >> >> On Feb 25, 2008, at 6:39 PM, David Gibson wrote: >> >>> On Wed, Feb 20, 2008 at 01:19:41PM -0600, Scott Wood wrote: A property's data can be populated with a file's contents as follows: node

Re: [PATCH 07/12] pcmcia: use linux/of_{device, platform}.h instead of asm

On Fri, May 23, 2008 at 04:31:08PM +1000, Stephen Rothwell wrote: > > Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]> Acked-by: Dominik Brodowski <[EMAIL PROTECTED]> I assume this is pushed upstream through -ppc? Thanks, Dominik ___ Linuxpp

Re: JFFS2 FS not writeable

Ron Madrid wrote: --- Scott Wood <[EMAIL PROTECTED]> wrote: You may want to try increasing the OR[SCY] field or other timing parameters associated with the NAND flash. So are you saying that when this happened in the past it was a timing issue? This change would need to happen in u-boot corr

Re: JFFS2 FS not writeable

--- Scott Wood <[EMAIL PROTECTED]> wrote: > You may want to try increasing the OR[SCY] field or > other timing > parameters associated with the NAND flash. So are you saying that when this happened in the past it was a timing issue? This change would need to happen in u-boot correct? Ron __

Re: PPC PReP link failure - copy_page, empty_zero_page

> > ERROR: "copy_page" [fs/fuse/fuse.ko] undefined! > > ERROR: "empty_zero_page" [fs/ext4/ext4dev.ko] undefined! > > Try that patch at: http://patchwork.ozlabs.org/linuxppc/patch?id=18710 > > Fixes it for me. Yes, this fixes it, thanks! Hopefully it is merged before 2.6.26. -- Meelis Roos ([EM

Re: [PATCH 2/3] [2.6.26] ehea: Add dependency to Kconfig

Hello, Hannes Hering wrote: > The new ehea memory hot plug implementation depends on MEMORY_HOTPLUG. > > Signed-off-by: Hannes Hering <[EMAIL PROTECTED]> > --- > > diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig > index f90a86b..181cd86 100644 > --- a/drivers/net/Kconfig > +++ b/drivers/n

Re: Still struggling with Xilinx GPIO...

Hi Guillaume, gpio_ioctl.chan = x; That's what determines which gpio device gets used. Since using 1 at least doesn't give you a core dump, I would guess that 1 is the correct value to use there. So the next thing to check is to make sure that the ioctl command codes being used are right. The o

May I ask some questions?

I am Michael from China.A few days ago, I was supposed to debug executable.elf with xmd while some problems happened.It said like that: xmd% dow executable.elf Failed to download ELF file ERROR(1053):UNABLE TO READ ELF FILE.THE ELF FILE MAYBE CORRUPTED :executable.elf I wan

Re: Still struggling with Xilinx GPIO...

Hi John, Try using channel 1. It may be set up where the first channel is 1 and not 0. Not sure what you mean... I'm actually not clear how many devices I should have: $ grep "GPIO.*BASEADDR" arch/ppc/platforms/4xx/xparameters/xparameters_ml405.h #define XPAR_GPIO_0_BASEADDR XPAR_LEDS_4BIT

Re: MMIO and gcc re-ordering issue

Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > > > I'm happy to say that __raw is purely about ordering and make them > > > byteswap on powerpc tho (ie, make them little endian like the non-raw > > > counterpart). > > > > That would break a lot of drivers. > > How many actually use __raw