Re: linux-next: build warning in Linus' tree
On 18.11.10 at 04:55, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Mon, 2010-10-25 at 17:03 +1100, Stephen Rothwell wrote: Hi Arnaud, On Sun, 24 Oct 2010 23:47:09 -0400 Arnaud Lacombe lacom...@gmail.com wrote: The following patch should fix this warning. I think the following is preferable. Not tested yet, I will test tomorrow and submit properly then. I agree. Tho I don't understand the original problem. Both definitions have no parenthesis for me and I don't see warnings, or am I missing some changes still in -next that cause this ? There had been parentheses for a short while, but them causing problems for at least one other arch, they got removed again. Jan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix call to subpage_protection()
On Thu, 2010-11-18 at 13:32 +1100, Michael Neuling wrote: In: powerpc/mm: Fix pgtable cache cleanup with CONFIG_PPC_SUBPAGE_PROT commit d28513bc7f675d28b479db666d572e078ecf182d Author: David Gibson da...@gibson.dropbear.id.au subpage_protection() was changed to to take an mm rather a pgdir but it didn't change calling site in hashpage_preload(). The change wasn't noticed at compile time since hashpage_preload() used a void* as the parameter to subpage_protection(). ... diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c index 83f534d..5e95844 100644 --- a/arch/powerpc/mm/hash_utils_64.c +++ b/arch/powerpc/mm/hash_utils_64.c @@ -1123,7 +1123,7 @@ void hash_preload(struct mm_struct *mm, unsigned long ea, else #endif /* CONFIG_PPC_HAS_HASH_64K */ rc = __hash_page_4K(ea, access, vsid, ptep, trap, local, ssize, - subpage_protection(pgdir, ea)); + subpage_protection(mm, ea)); Type checking is fun :) This is stable material no? cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: application needs fast access to physical memory
On Wed, 2010-11-17 at 16:03 -0600, steven@teradyne.com wrote: My application needs a fast way to access a specific physical DDR memory region. The application runs on an MPC8548 PowerPC which has an MMU. I've tried two approaches that are typical for Linux, mmap() and using a kernel module that implements read()/write() into this region and I'm finding that performance is very slow for both. It's a couple orders of magnitude slower than, for example, copying a large buffer from one place in the application's virtual memory to another place in the application's virtual memory. The mmap() version should basically run at full speed, at least once you've faulted the address range in. This specific DDR region isn't specifically slow is it ? :) cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: application needs fast access to physical memory
On Wed, 2010-11-17 at 16:03 -0600, steven@teradyne.com wrote: My application needs a fast way to access a specific physical DDR memory region. The application runs on an MPC8548 PowerPC which has an MMU. I've tried two approaches that are typical for Linux, mmap() and using a kernel module that implements read()/write() into this region and I'm finding that performance is very slow for both. It's a couple orders of magnitude slower than, for example, copying a large buffer from one place in the application's virtual memory to another place in the application's virtual memory. The mmap() version should basically run at full speed, at least once you've faulted the address range in. This specific DDR region isn't specifically slow is it ? :) Or being mapped uncached ? David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: application needs fast access to physical memory
On Thu, Nov 18, 2010 at 11:24:22PM +1100, Michael Ellerman wrote: On Wed, 2010-11-17 at 16:03 -0600, steven@teradyne.com wrote: My application needs a fast way to access a specific physical DDR memory region. The application runs on an MPC8548 PowerPC which has an MMU. I've tried two approaches that are typical for Linux, mmap() and using a kernel module that implements read()/write() into this region and I'm finding that performance is very slow for both. It's a couple orders of magnitude slower than, for example, copying a large buffer from one place in the application's virtual memory to another place in the application's virtual memory. The mmap() version should basically run at full speed, at least once you've faulted the address range in. This specific DDR region isn't specifically slow is it ? :) The other theory that springs to mind is whatever method you're using to access the region enabling cacheing? -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Gianfar TCP checksumming broken in 2.6.35+
From: Matthew L. Creech mlcre...@gmail.com Date: Tue, 2 Nov 2010 18:29:08 -0400 An upgrade from 2.6.34 to 2.6.35 caused networking to stop working on my MPC8313-based board. It turned out that TCP checksums were invalid, so I dug through the .35 changelog to try and isolate the reason. The change tcp: Set CHECKSUM_UNNECESSARY in tcp_init_nondata_skb seems to be the specific one that causes breakage - if I revert this one-liner, things work again: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2e8e18ef52e7dd1af0a3bd1f7d990a1d0b249586 However, I also noticed that one of my boards was broken while a newer prototype (which is very similar, hardware-wise) was not. It turns out they're using 2 different revisions of silicon, so the broken board still has a 1.0 version microcontroller. Therefore I'm guessing (just a hunch) that the root cause of the problem is MPC8313 errata eTSEC12: eTSEC12: Tx IP and TCP/UDP Checksum Generation not supported for some Tx FCB offsets Description: If the Tx FCB (Frame Control Block) 32-byte offset is 0x19, 0x1A, 0x1B, 0x1C, 0x1D, 0x1E or 0x1F, IP and TCP/UDP header checksum generation do not function properly. The checksum value may be inserted in the wrong location or not inserted at all. IP and TCP/UDP header checksum generation is not supported in LINUX and other systems in which headers are prepended to pre-aligned packet data, or where the alignment of the Tx FCB cannot be controlled. This behavior applies to pseudo-header checksum insertion as well as checksum generation. Workaround: Align Tx FCB to a 16 or 32-byte boundary. If the alignment of TxFCB is not controllable, set TCTRL[TUCSEN]=0 and TCTRL[IPCSEN]=0 to disable IP and TCP/UDP header checksum generation. Fix plan: Fixed in Rev 2.0 This appears to have been working previously, but doesn't work any more. I'm not familiar enough with Dave's checksum/sk_buff changes to figure out whether this errata is to blame, though, or how I should fix it if it is. Presumably there's some alignment magic needed in the sk_buff or gfar_add_fcb() to make sure that the microcontroller is happy with the FCB offset? Any tip on how I can solve this, or at least verify that this errata is at fault? Thanks in advance Can someone please follow up Matthew to get this bug resolved? It has been sitting around for a long time. I suspect the gianfar driver, for these chip revisions, will need to do a software checksum when the offset matches the criteria mentioned in the errata above. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: application needs fast access to physical memory
Thanks for the replies.
In the Linux Device Drivers book regarding mmap(), it states:
Mapping a device means associating a range of user-space addresses to
device memory.
Whenever the program reads or writes in the assigned address range, it
is actually
accessing the device. In the X server example, using mmap allows quick
and easy
access to the video card’s memory. For a performance-critical
application like this,
direct access makes a large difference.
For whatever reason, mmap() is definitely not quick and does not appear to
be a direct access to device memory. After the application completes a
large write into physical memory (via the pointer returned from mmap()),
the application performs an ioctl() to query whether the data actually
arrived into the memory region. It seems to take some time before the
associated kernel module actually sees the data in the physical memory
region.
There's a few things I should say about this memory region. There's a total
of 512 MB of physical memory. U-Boot passes mem=256M as a kernel
parameter to tell Linux to only directly manage the lower 256 MB. The
special region of physical memory that the application is trying to access
is the upper 256 MB of memory not directly managed by Linux. The mmap()
call from the application is:
*memptr = (void *) mmap( NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED,
_fdTerAlloc, (off_t) 0x1000);
On the kernel module side, the function handling the mmap() file operation
is:
static int ter_alloc_mmap( struct file *pFile, struct vm_area_struct
*vma )
{
if (remap_pfn_range(vma, vma-vm_start, vma-vm_pgoff, vma-vm_end -
vma-vm_start, vma-vm_page_prot))
return -EAGAIN;
vma-vm_ops = ter_alloc_remap_vm_ops;
ter_alloc_vma_open(vma);
return 0;
}
-Steve Lin
David Gibson
da...@gibson.dro
pbear.id.au To
Michael Ellerman
11/18/2010 06:54 mich...@ellerman.id.au
AM cc
steven@teradyne.com,
steven_...@notes.teradyne.com,
linuxppc-dev@lists.ozlabs.org
Subject
Re: application needs fast access
to physical memory
On Thu, Nov 18, 2010 at 11:24:22PM +1100, Michael Ellerman wrote:
On Wed, 2010-11-17 at 16:03 -0600, steven@teradyne.com wrote:
My application needs a fast way to access a specific physical DDR
memory region. The application runs on an MPC8548 PowerPC which has an
MMU. I've tried two approaches that are typical for Linux, mmap() and
using a kernel module that implements read()/write() into this region
and I'm finding that performance is very slow for both. It's a couple
orders of magnitude slower than, for example, copying a large buffer
from one place in the application's virtual memory to another place in
the application's virtual memory.
The mmap() version should basically run at full speed, at least once
you've faulted the address range in.
This specific DDR region isn't specifically slow is it ? :)
The other theory that springs to mind is whatever method you're using
to access the region enabling cacheing?
--
David Gibson | I'll have my music
baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT
_the_ _other_
| _way_
_around_!
http://www.ozlabs.org/~dgibson
[attachment signature.asc deleted by Steven Lin/USW/Teradyne]inline: graycol.gifinline: pic02872.gifinline: ecblank.gif___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix call to subpage_protection()
On Thu, 2010-11-18 at 13:32 +1100, Michael Neuling wrote: In: powerpc/mm: Fix pgtable cache cleanup with CONFIG_PPC_SUBPAGE_PROT commit d28513bc7f675d28b479db666d572e078ecf182d Author: David Gibson da...@gibson.dropbear.id.au subpage_protection() was changed to to take an mm rather a pgdir but it didn't change calling site in hashpage_preload(). The change wasn't noticed at compile time since hashpage_preload() used a void* as the parameter to subpage_protection(). This is obviously wrong and can trigger the following crash when CONFIG_SLAB, CONFIG_DEBUG_SLAB, CONFIG_PPC_64K_PAGES CONFIG_PPC_SUBPAGE_PROT are enabled. ... The following changes this subpage_protection() call. Reported-by: Jim Keniston jkeni...@linux.vnet.ibm.com Signed-off-by: Michael Neuling mi...@neuling.org Tested-by: Jim Keniston jkeni...@linux.vnet.ibm.com cc: David Gibson da...@gibson.dropbear.id.au cc: sta...@kernel.org (only 2.6.33 and newer) --- It boots fine with pseries_defconfig. Attached is the config file that I've been using, which is probably descended over many generations of kernels from some config file in my machine's distant past. (Enable DEBUG_SLAB or DEBUG_PAGEALLOC and it will fail to boot.) After I run 'make menuconfig' starting from pseries_defconfig... $ diff config_ok .config | wc -l 2052 I narrowed this down to adding the following on pseries_defconfig: +CONFIG_SLAB=y +CONFIG_PPC_64K_PAGES=y +CONFIG_PPC_SUBPAGE_PROT=y +CONFIG_DEBUG_SLAB=y To reproduce the fail. I have indeed verified that when I apply those config changes atop pseries_defconfig, the resulting kernel fails to boot on my Power 5 system without this fix, and boots correctly with this fix. So the Tested-by line is correct. Unfortunately, this fix doesn't enable my legacy configuration to boot with CONFIG_SLAB=y. It still fails in the same way -- console output attached. FWIW, this failure isn't an obstacle for me. I'm in no way attached to my legacy configuration; pseries_defconfig is fine for me. On the other hand, I can continue testing fixes, and/or make my system available to other IBMers when I'm not using it, if you want to continue to pursue this problem. Thanks. Jim diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c index 83f534d..5e95844 100644 --- a/arch/powerpc/mm/hash_utils_64.c +++ b/arch/powerpc/mm/hash_utils_64.c @@ -1123,7 +1123,7 @@ void hash_preload(struct mm_struct *mm, unsigned long ea, else #endif /* CONFIG_PPC_HAS_HASH_64K */ rc = __hash_page_4K(ea, access, vsid, ptep, trap, local, ssize, - subpage_protection(pgdir, ea)); + subpage_protection(mm, ea)); /* Dump some info in case of hash insertion failure, they should * never happen so it is really useful to know if/when they do This is with Michael Neuling's subpage_protection fix, using my legacy .config DEBUG_SLAB configured. boot: linus Using 0084e28a bytes for initrd buffer Please wait, loading kernel... Allocated 00f0 bytes for kernel @ 01e0 Elf64 kernel loaded... Loading ramdisk... ramdisk loaded 0084e28a @ 02d0 OF stdout device is: /vdevice/v...@3000 Preparing to boot Linux version 2.6.37-rc2-5-ppc64 (j...@elm3b90) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #9 SMP Wed Nov 17 18:17:23 PST 2010 Max number of cores passed to firmware: 512 (NR_CPUS = 1024) Calling ibm,client-architecture-support... not implemented command line: root=/dev/disk/by-id/scsi-SIBM_ST373453LC_3HW1CQ147445Q2A4-part3 quiet profile=2 sysrq=1 insmod=sym53c8xx insmod=ipr crashkernel=256M-:128M loglevel=8 memory layout at init: memory_limit : (16 MB aligned) alloc_bottom : 0355 alloc_top: 0800 alloc_top_hi : 7000 amo_top : 0800 ram_top : 7000 instantiating rtas at 0x076a... done boot cpu hw idx 0 starting cpu hw idx 2... done copying OF device tree... Building dt strings... Building dt structure... Device tree strings 0x0356 - 0x0356129c Device tree struct 0x0357 - 0x0358 Calling quiesce... returning from prom_init Crash kernel location must be 0x200 Reserving 128MB of memory at 32MB for crashkernel (System RAM: 1792MB) Phyp-dump not supported on this hardware Allocated 655360 bytes for 1024 pacas at c1f3 Using pSeries machine description Page orders: linear mapping = 24, virtual = 12, io = 12 Found initrd at 0xc2d0:0xc354e28a bootconsole [udbg0] enabled Partition configured for 4 cpus. CPU maps initialized for 2 threads per core (thread shift is 1) Freed 589824 bytes for unused pacas Starting Linux PPC64 #9 SMP Wed Nov 17 18:17:23 PST 2010 - ppc64_pft_size= 0x19
Re: Gianfar TCP checksumming broken in 2.6.35+
On Thu, Nov 18, 2010 at 12:06 PM, David Miller da...@davemloft.net wrote:
Can someone please follow up Matthew to get this bug resolved? It has
been sitting around for a long time.
I suspect the gianfar driver, for these chip revisions, will need to
do a software checksum when the offset matches the criteria mentioned
in the errata above.
I added a patch for this which fixes our affected systems; however, I
don't know if this is a good way to perform checksum offloading, I
just kind of dug around until I found a function that seemed like it
worked. :) Patch against 2.6.36 is below for reference.
---
gianfar.c | 21 +++--
gianfar.h |1 +
2 files changed, 20 insertions(+), 2 deletions(-)
diff -purN orig/drivers/net/gianfar.c linux-2.6.36/drivers/net/gianfar.c
--- orig/drivers/net/gianfar.c 2010-11-03 15:10:29.287140651 -0400
+++ linux-2.6.36/drivers/net/gianfar.c 2010-11-03 16:01:03.754321896 -0400
@@ -937,6 +937,10 @@ static void gfar_detect_errata(struct gf
unsigned int mod = (svr 16) 0xfff6; /* w/o E suffix */
unsigned int rev = svr 0x;
+ /* MPC8313 Rev 2.0 */
+ if (pvr == 0x80850010 mod == 0x80b0 rev 0x0020)
+ priv-errata |= GFAR_ERRATA_12;
+
/* MPC8313 Rev 2.0 and higher; All MPC837x */
if ((pvr == 0x80850010 mod == 0x80b0 rev = 0x0020) ||
(pvr == 0x80861010 (mod 0xfff9) == 0x80c0))
@@ -1984,7 +1988,8 @@ static inline struct txfcb *gfar_add_fcb
return fcb;
}
-static inline void gfar_tx_checksum(struct sk_buff *skb, struct txfcb *fcb)
+static inline void gfar_tx_checksum(struct sk_buff *skb, struct txfcb *fcb,
+ int has_csum_bug)
{
u8 flags = 0;
@@ -1994,6 +1999,17 @@ static inline void gfar_tx_checksum(stru
*/
flags = TXFCB_DEFAULT;
+ /* If using old-rev silicon, the alignment of the TXFCB may be off,
+* causing TCP checksumming to fail (errata eTSEC12). In that case,
+* we compute the checksum manually.
+*/
+ if (has_csum_bug) {
+ /* Disable handling of TCP/UDP header (checksumming) */
+ flags = ~TXFCB_TUP;
+ /* Manually add checksum */
+ skb_checksum_help(skb);
+ }
+
/* Tell the controller what the protocol is */
/* And provide the already calculated phcs */
if (ip_hdr(skb)-protocol == IPPROTO_UDP) {
@@ -2159,7 +2175,8 @@ static int gfar_start_xmit(struct sk_buf
if (CHECKSUM_PARTIAL == skb-ip_summed) {
fcb = gfar_add_fcb(skb);
lstatus |= BD_LFLAG(TXBD_TOE);
- gfar_tx_checksum(skb, fcb);
+ gfar_tx_checksum(skb, fcb,
+ gfar_has_errata(priv, GFAR_ERRATA_12));
}
if (priv-vlgrp vlan_tx_tag_present(skb)) {
diff -purN orig/drivers/net/gianfar.h linux-2.6.36/drivers/net/gianfar.h
--- orig/drivers/net/gianfar.h 2010-11-03 15:10:29.257142194 -0400
+++ linux-2.6.36/drivers/net/gianfar.h 2010-11-03 15:48:10.117134959 -0400
@@ -1029,6 +1029,7 @@ enum gfar_errata {
GFAR_ERRATA_74 = 0x01,
GFAR_ERRATA_76 = 0x02,
GFAR_ERRATA_A002= 0x04,
+ GFAR_ERRATA_12 = 0x08,
};
/* Struct stolen almost completely (and shamelessly) from the FCC enet source
--
Matthew L. Creech
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Gianfar TCP checksumming broken in 2.6.35+
From: Matthew L. Creech mlcre...@gmail.com Date: Thu, 18 Nov 2010 14:31:46 -0500 On Thu, Nov 18, 2010 at 12:06 PM, David Miller da...@davemloft.net wrote: Can someone please follow up Matthew to get this bug resolved? It has been sitting around for a long time. I suspect the gianfar driver, for these chip revisions, will need to do a software checksum when the offset matches the criteria mentioned in the errata above. I added a patch for this which fixes our affected systems; however, I don't know if this is a good way to perform checksum offloading, I just kind of dug around until I found a function that seemed like it worked. :) Patch against 2.6.36 is below for reference. It looks fine except I would limit the software checksum to the exact conditions listed in the errate. Otherwise this is going to hurt performance and cpu utilization quite a bit. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: application needs fast access to physical memory
On Thu, 18 Nov 2010 10:55:21 -0600 steven@teradyne.com wrote: Thanks for the replies. In the Linux Device Drivers book regarding mmap(), it states: Mapping a device means associating a range of user-space addresses to device memory. Whenever the program reads or writes in the assigned address range, it is actually accessing the device. In the X server example, using mmap allows quick and easy access to the video card’s memory. For a performance-critical application like this, direct access makes a large difference. For whatever reason, mmap() is definitely not quick and does not appear to be a direct access to device memory. After the application completes a large write into physical memory (via the pointer returned from mmap()), the application performs an ioctl() to query whether the data actually arrived into the memory region. It seems to take some time before the associated kernel module actually sees the data in the physical memory region. There's a few things I should say about this memory region. There's a total of 512 MB of physical memory. U-Boot passes mem=256M as a kernel parameter to tell Linux to only directly manage the lower 256 MB. The special region of physical memory that the application is trying to access is the upper 256 MB of memory not directly managed by Linux. The mmap() call from the application is: *memptr = (void *) mmap( NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, _fdTerAlloc, (off_t) 0x1000); Try this patch: http://patchwork.ozlabs.org/patch/68246/ -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] iSeries: Remove unused mf_getSrcHistory function and caller.
On Fri, 5 Nov 2010, Jesper Juhl wrote:
On Tue, 2 Nov 2010, Michael Ellerman wrote:
On Mon, 2010-11-01 at 22:20 +0100, Jesper Juhl wrote:
Hi Stephen,
On Tue, 2 Nov 2010, Stephen Rothwell wrote:
On Mon, 1 Nov 2010 21:06:23 +0100 (CET) Jesper Juhl
j...@chaosbits.net wrote:
Remove unused function 'mf_getSrcHistory' (that will never be used
ever
according to Stephen Rothwell).
Signed-off-by: Jesper Juhl j...@chaosbits.net
Acked-by: Stephen Rothwell s...@canb.auug.org.au
Ok, so if you are the (unofficial) iSeries maintainer and you don't merge
the patch somewhere that'll eventually go up-stream, but just ACK it
(thank you for that btw), then where do I send it to get it merged?
Here. ie. linuxppc-dev.
But, while you're removing it you should remove the #if 0'ed callsite as
well, see mf_src_proc_show() in that file. :)
Done. See patch below.
Remove unused function 'mf_getSrcHistory' (that will never be used
ever according to Stephen Rothwell) and also remove most of (under 'if
0') code from mf_src_proc_show() where the function was called.
Signed-off-by: Jesper Juhl j...@chaosbits.net
---
mf.c | 62
--
1 file changed, 62 deletions(-)
diff --git a/arch/powerpc/platforms/iseries/mf.c
b/arch/powerpc/platforms/iseries/mf.c
index 42d0a88..b5e026b 100644
--- a/arch/powerpc/platforms/iseries/mf.c
+++ b/arch/powerpc/platforms/iseries/mf.c
@@ -1045,71 +1045,9 @@ static const struct file_operations mf_side_proc_fops
= {
.write = mf_side_proc_write,
};
-#if 0
-static void mf_getSrcHistory(char *buffer, int size)
-{
- struct IplTypeReturnStuff return_stuff;
- struct pending_event *ev = new_pending_event();
- int rc = 0;
- char *pages[4];
-
- pages[0] = kmalloc(4096, GFP_ATOMIC);
- pages[1] = kmalloc(4096, GFP_ATOMIC);
- pages[2] = kmalloc(4096, GFP_ATOMIC);
- pages[3] = kmalloc(4096, GFP_ATOMIC);
- if ((ev == NULL) || (pages[0] == NULL) || (pages[1] == NULL)
- || (pages[2] == NULL) || (pages[3] == NULL))
- return -ENOMEM;
-
- return_stuff.xType = 0;
- return_stuff.xRc = 0;
- return_stuff.xDone = 0;
- ev-event.hp_lp_event.xSubtype = 6;
- ev-event.hp_lp_event.x.xSubtypeData =
- subtype_data('M', 'F', 'V', 'I');
- ev-event.data.vsp_cmd.xEvent = return_stuff;
- ev-event.data.vsp_cmd.cmd = 4;
- ev-event.data.vsp_cmd.lp_index = HvLpConfig_getLpIndex();
- ev-event.data.vsp_cmd.result_code = 0xFF;
- ev-event.data.vsp_cmd.reserved = 0;
- ev-event.data.vsp_cmd.sub_data.page[0] = iseries_hv_addr(pages[0]);
- ev-event.data.vsp_cmd.sub_data.page[1] = iseries_hv_addr(pages[1]);
- ev-event.data.vsp_cmd.sub_data.page[2] = iseries_hv_addr(pages[2]);
- ev-event.data.vsp_cmd.sub_data.page[3] = iseries_hv_addr(pages[3]);
- mb();
- if (signal_event(ev) != 0)
- return;
-
- while (return_stuff.xDone != 1)
- udelay(10);
- if (return_stuff.xRc == 0)
- memcpy(buffer, pages[0], size);
- kfree(pages[0]);
- kfree(pages[1]);
- kfree(pages[2]);
- kfree(pages[3]);
-}
-#endif
-
static int mf_src_proc_show(struct seq_file *m, void *v)
{
-#if 0
- int len;
-
- mf_getSrcHistory(page, count);
- len = count;
- len -= off;
- if (len count) {
- *eof = 1;
- if (len = 0)
- return 0;
- } else
- len = count;
- *start = page + off;
- return len;
-#else
return 0;
-#endif
}
static int mf_src_proc_open(struct inode *inode, struct file *file)
PING.
Is this going to get merged somewhere or is there a problem?
--
Jesper Juhl j...@chaosbits.nethttp://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] Powerpc: separate CONFIG_RELOCATABLE from CONFIG_CRASHDUMP in boot code
Fix head_64.S so that we can build a relocatable kernel that isn't necessarily a crash-dump kernel Signed-off-by: Milton Miller milt...@bga.com Signed-off-by: Sonny Rao sonny...@linux.vnet.ibm.com --- arch/powerpc/kernel/head_64.S |6 ++ 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S index f0dd577..53b098f 100644 --- a/arch/powerpc/kernel/head_64.S +++ b/arch/powerpc/kernel/head_64.S @@ -96,7 +96,7 @@ __secondary_hold_acknowledge: .llong hvReleaseData-KERNELBASE #endif /* CONFIG_PPC_ISERIES */ -#ifdef CONFIG_CRASH_DUMP +#ifdef CONFIG_RELOCATABLE /* This flag is set to 1 by a loader if the kernel should run * at the loaded address instead of the linked address. This * is used by kexec-tools to keep the the kdump kernel in the @@ -384,12 +384,10 @@ _STATIC(__after_prom_start) /* process relocations for the final address of the kernel */ lis r25,page_off...@highest /* compute virtual base of kernel */ sldir25,r25,32 -#ifdef CONFIG_CRASH_DUMP lwz r7,__run_at_load-_stext(r26) - cmplwi cr0,r7,1/* kdump kernel ? - stay where we are */ + cmplwi cr0,r7,1/* flagged to stay where we are ? */ bne 1f add r25,r25,r26 -#endif 1: mr r3,r25 bl .relocate #endif -- 1.5.6.5 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: minor cleanups for machdep.h
remove stale declaration of setup_pci_ptrs, aparently from ppc before 2.4.0
remove #ifdef around struct existance delcaration
fix spelling of linear
Signed-off-by: Milton Miller milt...@bga.com
Signed-off-by: Sonny Rao sonny...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/machdep.h |6 +-
1 files changed, 1 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/include/asm/machdep.h
b/arch/powerpc/include/asm/machdep.h
index d045b01..8433d36 100644
--- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -27,9 +27,7 @@ struct iommu_table;
struct rtc_time;
struct file;
struct pci_controller;
-#ifdef CONFIG_KEXEC
struct kimage;
-#endif
#ifdef CONFIG_SMP
struct smp_ops_t {
@@ -72,7 +70,7 @@ struct machdep_calls {
int psize, int ssize);
void(*flush_hash_range)(unsigned long number, int local);
- /* special for kexec, to be called in real mode, linar mapping is
+ /* special for kexec, to be called in real mode, linear mapping is
* destroyed as well */
void(*hpte_clear_all)(void);
@@ -324,8 +322,6 @@ extern sys_ctrler_t sys_ctrler;
#endif /* CONFIG_PPC_PMAC */
-extern void setup_pci_ptrs(void);
-
#ifdef CONFIG_SMP
/* Poor default implementations */
extern void __devinit smp_generic_give_timebase(void);
--
1.5.6.5
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix call to subpage_protection()
On Thu, 2010-11-18 at 10:23 -0800, Jim Keniston wrote: FWIW, this failure isn't an obstacle for me. I'm in no way attached to my legacy configuration; pseries_defconfig is fine for me. On the other hand, I can continue testing fixes, and/or make my system available to other IBMers when I'm not using it, if you want to continue to pursue this problem. Thank From the look of it your legacy config is lacking the necessary storage drivers... Ben. . Jim diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c index 83f534d..5e95844 100644 --- a/arch/powerpc/mm/hash_utils_64.c +++ b/arch/powerpc/mm/hash_utils_64.c @@ -1123,7 +1123,7 @@ void hash_preload(struct mm_struct *mm, unsigned long ea, else #endif /* CONFIG_PPC_HAS_HASH_64K */ rc = __hash_page_4K(ea, access, vsid, ptep, trap, local, ssize, - subpage_protection(pgdir, ea)); + subpage_protection(mm, ea)); /* Dump some info in case of hash insertion failure, they should * never happen so it is really useful to know if/when they do ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix call to subpage_protection()
On Thu, 2010-11-18 at 13:32 +1100, Michael Neuling wrote: In:=20 powerpc/mm: Fix pgtable cache cleanup with CONFIG_PPC_SUBPAGE_PROT commit d28513bc7f675d28b479db666d572e078ecf182d Author: David Gibson da...@gibson.dropbear.id.au =20 subpage_protection() was changed to to take an mm rather a pgdir but it didn't change calling site in hashpage_preload(). The change wasn't noticed at compile time since hashpage_preload() used a void* as the parameter to subpage_protection(). ...=20 =20 diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils= _64.c index 83f534d..5e95844 100644 --- a/arch/powerpc/mm/hash_utils_64.c +++ b/arch/powerpc/mm/hash_utils_64.c @@ -1123,7 +1123,7 @@ void hash_preload(struct mm_struct *mm, unsigned lo= ng ea, else #endif /* CONFIG_PPC_HAS_HASH_64K */ rc =3D __hash_page_4K(ea, access, vsid, ptep, trap, local, ssiz e, - subpage_protection(pgdir, ea)); + subpage_protection(mm, ea)); Type checking is fun :) This is stable material no? Yes. In the bit you snipped was a: cc: sta...@kernel.org (only 2.6.33 and newer) Fortunately it's not in 2.6.32 so the bug missed the distros. Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: application needs fast access to physical memory
On Thu, 18 Nov 2010 14:46:16 -0600 steven@teradyne.com wrote: Hello Scott, Do you know whether this patch is necessary if I were to use alloc_bootmem () (to set aside a region of contiguous physical memory) instead of the kernel parameter mem=256? It should not be needed in that case. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
Michael Neuling (1): powerpc: Fix call to subpage_protection() Well that's annoying... Looks like the bottom of my commit got chopped as the oops message has a --- in it. We lost the cc: sta...@kernel.org :-( Comparing the original post to the final commit: http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-November/087141.html To the final: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=1c2c25c78740b2796c7c06640784cb6732fa4907 It'd be nice if we had something like this in: powerpc: fix debug prints to avoid --- Many commit tools assume anything below a line starting with --- is a comment. Since the following two prints are often used as debug outputs and hence in checkin comments avoid using --- in these Signed-off-by: Michael Neuling mi...@neuling.org --- Let the bike shedding begin! arch/powerpc/kernel/process.c |2 +- arch/powerpc/xmon/xmon.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Index: linux-2.6-ozlabs/arch/powerpc/kernel/process.c === --- linux-2.6-ozlabs.orig/arch/powerpc/kernel/process.c +++ linux-2.6-ozlabs/arch/powerpc/kernel/process.c @@ -1167,7 +1167,7 @@ struct pt_regs *regs = (struct pt_regs *) (sp + STACK_FRAME_OVERHEAD); lr = regs-link; - printk(--- Exception: %lx at %pS\nLR = %pS\n, + printk(=== Exception: %lx at %pS\nLR = %pS\n, regs-trap, (void *)regs-nip, (void *)lr); firstframe = 1; } Index: linux-2.6-ozlabs/arch/powerpc/xmon/xmon.c === --- linux-2.6-ozlabs.orig/arch/powerpc/xmon/xmon.c +++ linux-2.6-ozlabs/arch/powerpc/xmon/xmon.c @@ -1363,7 +1363,7 @@ sp + REGS_OFFSET); break; } -printf(--- Exception: %lx %s at , regs.trap, +printf(=== Exception: %lx %s at , regs.trap, getvecname(TRAP(regs))); pc = regs.nip; lr = regs.link; ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: fix call to subpage_protection()
On Fri, 2010-11-19 at 07:24 +1100, Michael Neuling wrote: On Thu, 2010-11-18 at 13:32 +1100, Michael Neuling wrote: In:=20 powerpc/mm: Fix pgtable cache cleanup with CONFIG_PPC_SUBPAGE_PROT commit d28513bc7f675d28b479db666d572e078ecf182d Author: David Gibson da...@gibson.dropbear.id.au =20 subpage_protection() was changed to to take an mm rather a pgdir but it didn't change calling site in hashpage_preload(). The change wasn't noticed at compile time since hashpage_preload() used a void* as the parameter to subpage_protection(). ...=20 =20 diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils= _64.c index 83f534d..5e95844 100644 --- a/arch/powerpc/mm/hash_utils_64.c +++ b/arch/powerpc/mm/hash_utils_64.c @@ -1123,7 +1123,7 @@ void hash_preload(struct mm_struct *mm, unsigned lo= ng ea, else #endif /* CONFIG_PPC_HAS_HASH_64K */ rc =3D __hash_page_4K(ea, access, vsid, ptep, trap, local, ssiz e, - subpage_protection(pgdir, ea)); + subpage_protection(mm, ea)); Type checking is fun :) This is stable material no? Yes. In the bit you snipped was a: cc: sta...@kernel.org (only 2.6.33 and newer) Oh right, I thought you actually had to send it to them :D Fortunately it's not in 2.6.32 so the bug missed the distros. Phew. cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] iSeries: Remove unused mf_getSrcHistory function and caller.
On Thu, 2010-11-18 at 20:45 +0100, Jesper Juhl wrote: On Fri, 5 Nov 2010, Jesper Juhl wrote: static int mf_src_proc_open(struct inode *inode, struct file *file) PING. Is this going to get merged somewhere or is there a problem? Yes, no. It won't get lost: http://patchwork.ozlabs.org/patch/70201/ cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] iSeries: Remove unused mf_getSrcHistory function and caller.
On Fri, 19 Nov 2010, Michael Ellerman wrote: On Thu, 2010-11-18 at 20:45 +0100, Jesper Juhl wrote: On Fri, 5 Nov 2010, Jesper Juhl wrote: static int mf_src_proc_open(struct inode *inode, struct file *file) PING. Is this going to get merged somewhere or is there a problem? Yes, no. It won't get lost: http://patchwork.ozlabs.org/patch/70201/ Ok. Thank you for that bit of information. That was one place that I had no knowledge about what-so-ever, so I didn't look. I will now rest happily in the knowledge that the patch is in good hands. Thanks. -- Jesper Juhl j...@chaosbits.nethttp://www.chaosbits.net/ Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
On Fri, 2010-11-19 at 08:42 +1100, Michael Neuling wrote: Michael Neuling (1): powerpc: Fix call to subpage_protection() Well that's annoying... Looks like the bottom of my commit got chopped as the oops message has a --- in it. We lost the cc: sta...@kernel.org :-( Comparing the original post to the final commit: http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-November/087141.html To the final: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=1c2c25c78740b2796c7c06640784cb6732fa4907 LOL. It'd be nice if we had something like this in: powerpc: fix debug prints to avoid --- Many commit tools assume anything below a line starting with --- is a comment. Since the following two prints are often used as debug outputs and hence in checkin comments avoid using --- in these Signed-off-by: Michael Neuling mi...@neuling.org --- Let the bike shedding begin! I vote for: - Exception: 401 (Instruction Access) at f7937794 Because exceptions are like an arrow! signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 0/7] add of_fdt_unflatten_tree
Currently, fdt blobs are handled solely at boot time. However, it may be useful to parse blobs into device trees after boot time. For instance, a PCIe device may have an FPGA which includes a device tree. This set of patches locally refactors the existing code to enable this. Patch 1 and 4-7 are the interesting bits. Patch 2 and 3 provide the ability to use this code on x86, and are provided mostly for reference. The non-early boot code has been compile-tested and executed on X86. Stephen Neuendorffer (7): fdt: Add Kconfig for EARLY_FLATTREE arch/x86: Add support for device tree code. arch/x86: select OF and OF_FLATTREE fdt.c: Add non-boottime device tree functions fdt.c: Refactor unflatten_dt_node fdt.c: Reorder unflatten_dt_node fdt.c: Refactor unflatten_device_tree and add fdt_unflatten_tree arch/microblaze/Kconfig|1 + arch/powerpc/Kconfig |1 + arch/x86/Kconfig |2 + arch/x86/include/asm/irq.h |2 + arch/x86/kernel/irq.c | 11 ++ drivers/of/Kconfig |5 + drivers/of/fdt.c | 393 ++-- include/linux/of_fdt.h | 13 ++ 8 files changed, 272 insertions(+), 156 deletions(-) This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/7] fdt: Add Kconfig for EARLY_FLATTREE
The device tree code is now in two pieces: some which can be used generically
on any platform which selects CONFIG_OF_FLATTREE, and some early which is used
at boot time on only a few architectures. This patch segregates the early
code so that only those architectures which care about it need compile it.
This also means that some of the requirements in the early code (such as
a cmd_line variable) that most architectures (e.g. X86) don't provide
can be ignored.
Signed-off-by: Stephen Neuendorffer stephen.neuendorf...@xilinx.com
Grant,
We had discussed doing something like this a lng time ago. This (or at
least some other way of dealing with cmd_line) is
actually necessary to compile on X86. Do you still want to do it this way?
Looking at my old email, you suggested only powerpc and microblaze need this.
Is that still the case?
Conflicts:
drivers/of/fdt.c
---
arch/microblaze/Kconfig |1 +
arch/powerpc/Kconfig|1 +
drivers/of/Kconfig |5 +
drivers/of/fdt.c|4
4 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index 692fdfc..384375c 100644
--- a/arch/microblaze/Kconfig
+++ b/arch/microblaze/Kconfig
@@ -20,6 +20,7 @@ config MICROBLAZE
select TRACING_SUPPORT
select OF
select OF_FLATTREE
+ select OF_EARLY_FLATTREE
config SWAP
def_bool n
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 631e5a0..2cd7b32 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -119,6 +119,7 @@ config PPC
default y
select OF
select OF_FLATTREE
+ select OF_EARLY_FLATTREE
select HAVE_FTRACE_MCOUNT_RECORD
select HAVE_DYNAMIC_FTRACE
select HAVE_FUNCTION_TRACER
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index aa675eb..0199157 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -19,6 +19,10 @@ config OF_FLATTREE
bool
select DTC
+config OF_EARLY_FLATTREE
+ bool
+ depends on OF_FLATTREE
+
config OF_PROMTREE
bool
@@ -62,3 +66,4 @@ config OF_MDIO
OpenFirmware MDIO bus (Ethernet PHY) accessors
endmenu # OF
+
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index c1360e0..4d71b29 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -27,6 +27,8 @@ int __initdata dt_root_size_cells;
struct boot_param_header *initial_boot_params;
+#ifdef CONFIG_EARLY_FLATTREE
+
char *find_flat_dt_string(u32 offset)
{
return ((char *)initial_boot_params) +
@@ -604,3 +606,5 @@ void __init unflatten_device_tree(void)
pr_debug( - unflatten_device_tree()\n);
}
+
+#endif /* CONFIG_EARLY_FLATTREE */
--
1.5.6.6
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/7] arch/x86: Add support for device tree code.
A few support device-tree related support functions that x86 didn't
have before.
Signed-off-by: Stephen Neuendorffer stephen.neuendorf...@xilinx.com
Looks like just some irq related junk left!
---
arch/x86/include/asm/irq.h |2 ++
arch/x86/kernel/irq.c | 11 +++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/x86/include/asm/irq.h b/arch/x86/include/asm/irq.h
index 5458380..af4e630 100644
--- a/arch/x86/include/asm/irq.h
+++ b/arch/x86/include/asm/irq.h
@@ -10,6 +10,8 @@
#include asm/apicdef.h
#include asm/irq_vectors.h
+#define irq_dispose_mapping(...)
+
static inline int irq_canonicalize(int irq)
{
return ((irq == 2) ? 9 : irq);
diff --git a/arch/x86/kernel/irq.c b/arch/x86/kernel/irq.c
index 91fd0c7..a3aaed4 100644
--- a/arch/x86/kernel/irq.c
+++ b/arch/x86/kernel/irq.c
@@ -364,3 +364,14 @@ void fixup_irqs(void)
}
}
#endif
+
+#ifdef CONFIG_OF
+#include linux/of_irq.h
+unsigned int irq_create_of_mapping(struct device_node *controller,
+ const u32 *intspec, unsigned int intsize)
+{
+ return intspec[0] + 1;
+}
+EXPORT_SYMBOL_GPL(irq_create_of_mapping);
+
+#endif
--
1.5.6.6
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 7/7] fdt.c: Refactor unflatten_device_tree and add fdt_unflatten_tree
unflatten_device_tree has two dependencies on things that happen
during boot time. Firstly, it references the initial device tree
directly. Secondly, it allocates memory using the early boot
allocator. This patch factors out these dependencies and uses
the new __unflatten_device_tree function to implement a driver-visible
fdt_unflatten_tree function, which can be used to unflatten a
blob after boot time.
Signed-off-by: Stephen Neuendorffer stephen.neuendorf...@xilinx.com
--
V2: remove extra __va() call
make dt_alloc functions return void *. This doesn't fix the general
strangeness in this code that constantly casts back and forth between
unsigned long and __be32 *
---
drivers/of/fdt.c | 149 +++
include/linux/of_fdt.h |2 +
2 files changed, 100 insertions(+), 51 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 236a8c9..e29dbe2 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -11,10 +11,12 @@
#include linux/kernel.h
#include linux/initrd.h
+#include linux/module.h
#include linux/of.h
#include linux/of_fdt.h
#include linux/string.h
#include linux/errno.h
+#include linux/slab.h
#ifdef CONFIG_PPC
#include asm/machdep.h
@@ -312,6 +314,94 @@ unsigned long unflatten_dt_node(struct boot_param_header
*blob,
return mem;
}
+/**
+ * __unflatten_device_tree - create tree of device_nodes from flat blob
+ *
+ * unflattens a device-tree, creating the
+ * tree of struct device_node. It also fills the name and type
+ * pointers of the nodes so the normal device-tree walking functions
+ * can be used.
+ * @blob: The blob to expand
+ * @mynodes: The device_node tree created by the call
+ * @dt_alloc: An allocator that provides a virtual address to memory
+ * for the resulting tree
+ */
+void __unflatten_device_tree(struct boot_param_header *blob,
+struct device_node **mynodes,
+void * (*dt_alloc)(u64 size, u64 align))
+{
+ unsigned long start, mem, size;
+ struct device_node **allnextp = mynodes;
+
+ pr_debug( - unflatten_device_tree()\n);
+
+ if (!blob) {
+ pr_debug(No device tree pointer\n);
+ return;
+ }
+
+ pr_debug(Unflattening device tree:\n);
+ pr_debug(magic: %08x\n, be32_to_cpu(blob-magic));
+ pr_debug(size: %08x\n, be32_to_cpu(blob-totalsize));
+ pr_debug(version: %08x\n, be32_to_cpu(blob-version));
+
+ if (be32_to_cpu(blob-magic) != OF_DT_HEADER) {
+ pr_err(Invalid device tree blob header\n);
+ return;
+ }
+
+ /* First pass, scan for size */
+ start = ((unsigned long)blob) +
+ be32_to_cpu(blob-off_dt_struct);
+ size = unflatten_dt_node(blob, 0, start, NULL, NULL, 0);
+ size = (size | 3) + 1;
+
+ pr_debug( size is %lx, allocating...\n, size);
+
+ /* Allocate memory for the expanded device tree */
+ mem = (unsigned long)
+ dt_alloc(size + 4, __alignof__(struct device_node));
+
+ ((__be32 *)mem)[size / 4] = cpu_to_be32(0xdeadbeef);
+
+ pr_debug( unflattening %lx...\n, mem);
+
+ /* Second pass, do actual unflattening */
+ start = ((unsigned long)blob) +
+ be32_to_cpu(blob-off_dt_struct);
+ unflatten_dt_node(blob, mem, start, NULL, allnextp, 0);
+ if (be32_to_cpup((__be32 *)start) != OF_DT_END)
+ pr_warning(Weird tag at end of tree: %08x\n, *((u32 *)start));
+ if (be32_to_cpu(((__be32 *)mem)[size / 4]) != 0xdeadbeef)
+ pr_warning(End of tree marker overwritten: %08x\n,
+ be32_to_cpu(((__be32 *)mem)[size / 4]));
+ *allnextp = NULL;
+
+ pr_debug( - unflatten_device_tree()\n);
+}
+
+static void *kernel_tree_alloc(u64 size, u64 align)
+{
+ return kzalloc(size, GFP_KERNEL);
+}
+
+/**
+ * of_fdt_unflatten_tree - create tree of device_nodes from flat blob
+ *
+ * unflattens the device-tree passed by the firmware, creating the
+ * tree of struct device_node. It also fills the name and type
+ * pointers of the nodes so the normal device-tree walking functions
+ * can be used.
+ */
+void of_fdt_unflatten_tree(unsigned long *blob,
+ struct device_node **mynodes)
+{
+ struct boot_param_header *device_tree =
+ (struct boot_param_header *)blob;
+ __unflatten_device_tree(device_tree, mynodes, kernel_tree_alloc);
+}
+EXPORT_SYMBOL_GPL(of_fdt_unflatten_tree);
+
/* Everything below here references initial_boot_params directly. */
int __initdata dt_root_addr_cells;
int __initdata dt_root_size_cells;
@@ -569,6 +659,12 @@ int __init early_init_dt_scan_chosen(unsigned long node,
const char *uname,
return 1;
}
+static void *__init early_device_tree_alloc(u64 size, u64 align)
+{
+ unsigned long mem = early_init_dt_alloc_memory_arch(size, align);
+ return __va(mem);
+}
+
[PATCH 4/7] fdt.c: Add non-boottime device tree functions
In preparation for providing run-time handling of device trees, factor
out some of the basic functions so that they take an arbitrary blob,
rather than relying on the single boot-time tree.
Signed-off-by: Stephen Neuendorffer stephen.neuendorf...@xilinx.com
--
V2: functions have of_fdt_* names
removed find_flat_dt_string
blob argument is first
---
drivers/of/fdt.c | 133 ---
include/linux/of_fdt.h | 11
2 files changed, 90 insertions(+), 54 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 4d71b29..190e26c 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -22,6 +22,82 @@
#include asm/page.h
+char *of_fdt_get_string(struct boot_param_header *blob, u32 offset)
+{
+ return ((char *)blob) +
+ be32_to_cpu(blob-off_dt_strings) + offset;
+}
+
+/**
+ * of_fdt_get_property - Given a node in the given flat blob, return
+ * the property ptr
+ */
+void *of_fdt_get_property(struct boot_param_header *blob,
+ unsigned long node, const char *name,
+ unsigned long *size)
+{
+ unsigned long p = node;
+
+ do {
+ u32 tag = be32_to_cpup((__be32 *)p);
+ u32 sz, noff;
+ const char *nstr;
+
+ p += 4;
+ if (tag == OF_DT_NOP)
+ continue;
+ if (tag != OF_DT_PROP)
+ return NULL;
+
+ sz = be32_to_cpup((__be32 *)p);
+ noff = be32_to_cpup((__be32 *)(p + 4));
+ p += 8;
+ if (be32_to_cpu(blob-version) 0x10)
+ p = ALIGN(p, sz = 8 ? 8 : 4);
+
+ nstr = of_fdt_get_string(blob, noff);
+ if (nstr == NULL) {
+ pr_warning(Can't find property index name !\n);
+ return NULL;
+ }
+ if (strcmp(name, nstr) == 0) {
+ if (size)
+ *size = sz;
+ return (void *)p;
+ }
+ p += sz;
+ p = ALIGN(p, 4);
+ } while (1);
+}
+
+/**
+ * of_fdt_is_compatible - Return true if given node from the given blob has
+ * compat in its compatible list
+ * @blob: A device tree blob
+ * @node: node to test
+ * @compat: compatible string to compare with compatible list.
+ */
+int of_fdt_is_compatible(struct boot_param_header *blob,
+ unsigned long node, const char *compat)
+{
+ const char *cp;
+ unsigned long cplen, l;
+
+ cp = of_fdt_get_property(blob, node, compatible, cplen);
+ if (cp == NULL)
+ return 0;
+ while (cplen 0) {
+ if (of_compat_cmp(cp, compat, strlen(compat)) == 0)
+ return 1;
+ l = strlen(cp) + 1;
+ cp += l;
+ cplen -= l;
+ }
+
+ return 0;
+}
+
+/* Everything below here references initial_boot_params directly. */
int __initdata dt_root_addr_cells;
int __initdata dt_root_size_cells;
@@ -29,12 +105,6 @@ struct boot_param_header *initial_boot_params;
#ifdef CONFIG_EARLY_FLATTREE
-char *find_flat_dt_string(u32 offset)
-{
- return ((char *)initial_boot_params) +
- be32_to_cpu(initial_boot_params-off_dt_strings) + offset;
-}
-
/**
* of_scan_flat_dt - scan flattened tree blob and call callback on each.
* @it: callback function
@@ -123,38 +193,7 @@ unsigned long __init of_get_flat_dt_root(void)
void *__init of_get_flat_dt_prop(unsigned long node, const char *name,
unsigned long *size)
{
- unsigned long p = node;
-
- do {
- u32 tag = be32_to_cpup((__be32 *)p);
- u32 sz, noff;
- const char *nstr;
-
- p += 4;
- if (tag == OF_DT_NOP)
- continue;
- if (tag != OF_DT_PROP)
- return NULL;
-
- sz = be32_to_cpup((__be32 *)p);
- noff = be32_to_cpup((__be32 *)(p + 4));
- p += 8;
- if (be32_to_cpu(initial_boot_params-version) 0x10)
- p = ALIGN(p, sz = 8 ? 8 : 4);
-
- nstr = find_flat_dt_string(noff);
- if (nstr == NULL) {
- pr_warning(Can't find property index name !\n);
- return NULL;
- }
- if (strcmp(name, nstr) == 0) {
- if (size)
- *size = sz;
- return (void *)p;
- }
- p += sz;
- p = ALIGN(p, 4);
- } while (1);
+ return of_fdt_get_property(initial_boot_params, node, name, size);
}
/**
@@ -164,21 +203,7 @@ void *__init of_get_flat_dt_prop(unsigned long node, const
char *name,
*/
int __init of_flat_dt_is_compatible(unsigned
[PATCH 5/7] fdt.c: Refactor unflatten_dt_node
unflatten_dt_node is a helper function that does most of the work to
convert a device tree blob into tree of device nodes. This code
now uses a passed-in blob instead of using the single boot-time blob,
allowing it to be called in more contexts.
Signed-off-by: Stephen Neuendorffer stephen.neuendorf...@xilinx.com
---
V2: don't reorder
blob argument first.
---
drivers/of/fdt.c | 27 ---
1 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 190e26c..a07fd1a 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -206,7 +206,7 @@ int __init of_flat_dt_is_compatible(unsigned long node,
const char *compat)
return of_fdt_is_compatible(initial_boot_params, node, compat);
}
-static void *__init unflatten_dt_alloc(unsigned long *mem, unsigned long size,
+static void *unflatten_dt_alloc(unsigned long *mem, unsigned long size,
unsigned long align)
{
void *res;
@@ -220,16 +220,18 @@ static void *__init unflatten_dt_alloc(unsigned long
*mem, unsigned long size,
/**
* unflatten_dt_node - Alloc and populate a device_node from the flat tree
+ * @blob: The parent device tree blob
* @p: pointer to node in flat tree
* @dad: Parent struct device_node
* @allnextpp: pointer to -allnext from last allocated device_node
* @fpsize: Size of the node path up at the current depth.
*/
-unsigned long __init unflatten_dt_node(unsigned long mem,
- unsigned long *p,
- struct device_node *dad,
- struct device_node ***allnextpp,
- unsigned long fpsize)
+unsigned long unflatten_dt_node(struct boot_param_header *blob,
+ unsigned long mem,
+ unsigned long *p,
+ struct device_node *dad,
+ struct device_node ***allnextpp,
+ unsigned long fpsize)
{
struct device_node *np;
struct property *pp, **prev_pp = NULL;
@@ -325,10 +327,10 @@ unsigned long __init unflatten_dt_node(unsigned long mem,
sz = be32_to_cpup((__be32 *)(*p));
noff = be32_to_cpup((__be32 *)((*p) + 4));
*p += 8;
- if (be32_to_cpu(initial_boot_params-version) 0x10)
+ if (be32_to_cpu(blob-version) 0x10)
*p = ALIGN(*p, sz = 8 ? 8 : 4);
- pname = of_fdt_get_string(initial_boot_params, noff);
+ pname = of_fdt_get_string(blob, noff);
if (pname == NULL) {
pr_info(Can't find property name in list !\n);
break;
@@ -407,7 +409,8 @@ unsigned long __init unflatten_dt_node(unsigned long mem,
if (tag == OF_DT_NOP)
*p += 4;
else
- mem = unflatten_dt_node(mem, p, np, allnextpp, fpsize);
+ mem = unflatten_dt_node(blob, mem, p, np, allnextpp,
+ fpsize);
tag = be32_to_cpup((__be32 *)(*p));
}
if (tag != OF_DT_END_NODE) {
@@ -599,7 +602,8 @@ void __init unflatten_device_tree(void)
/* First pass, scan for size */
start = ((unsigned long)initial_boot_params) +
be32_to_cpu(initial_boot_params-off_dt_struct);
- size = unflatten_dt_node(0, start, NULL, NULL, 0);
+ size = unflatten_dt_node(initial_boot_params, 0, start,
+NULL, NULL, 0);
size = (size | 3) + 1;
pr_debug( size is %lx, allocating...\n, size);
@@ -616,7 +620,8 @@ void __init unflatten_device_tree(void)
/* Second pass, do actual unflattening */
start = ((unsigned long)initial_boot_params) +
be32_to_cpu(initial_boot_params-off_dt_struct);
- unflatten_dt_node(mem, start, NULL, allnextp, 0);
+ unflatten_dt_node(initial_boot_params, mem, start,
+ NULL, allnextp, 0);
if (be32_to_cpup((__be32 *)start) != OF_DT_END)
pr_warning(Weird tag at end of tree: %08x\n, *((u32 *)start));
if (be32_to_cpu(((__be32 *)mem)[size / 4]) != 0xdeadbeef)
--
1.5.6.6
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 3/7] arch/x86: select OF and OF_FLATTREE
Testing patch to verify that the device tree code can be compiled on X86. --- arch/x86/Kconfig |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index cea0cd9..0f2ed5b 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -59,6 +59,8 @@ config X86 select ANON_INODES select HAVE_ARCH_KMEMCHECK select HAVE_USER_RETURN_NOTIFIER + select OF + select OF_FLATTREE config INSTRUCTION_DECODER def_bool (KPROBES || PERF_EVENTS) -- 1.5.6.6 This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 6/7] fdt.c: Reorder unflatten_dt_node
Move unflatten_dt_node to be grouped with non-__init functions.
Signed-off-by: Stephen Neuendorffer stephen.neuendorf...@xilinx.com
---
drivers/of/fdt.c | 218 +++---
1 files changed, 109 insertions(+), 109 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index a07fd1a..236a8c9 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -97,115 +97,6 @@ int of_fdt_is_compatible(struct boot_param_header *blob,
return 0;
}
-/* Everything below here references initial_boot_params directly. */
-int __initdata dt_root_addr_cells;
-int __initdata dt_root_size_cells;
-
-struct boot_param_header *initial_boot_params;
-
-#ifdef CONFIG_EARLY_FLATTREE
-
-/**
- * of_scan_flat_dt - scan flattened tree blob and call callback on each.
- * @it: callback function
- * @data: context data pointer
- *
- * This function is used to scan the flattened device-tree, it is
- * used to extract the memory information at boot before we can
- * unflatten the tree
- */
-int __init of_scan_flat_dt(int (*it)(unsigned long node,
-const char *uname, int depth,
-void *data),
- void *data)
-{
- unsigned long p = ((unsigned long)initial_boot_params) +
- be32_to_cpu(initial_boot_params-off_dt_struct);
- int rc = 0;
- int depth = -1;
-
- do {
- u32 tag = be32_to_cpup((__be32 *)p);
- char *pathp;
-
- p += 4;
- if (tag == OF_DT_END_NODE) {
- depth--;
- continue;
- }
- if (tag == OF_DT_NOP)
- continue;
- if (tag == OF_DT_END)
- break;
- if (tag == OF_DT_PROP) {
- u32 sz = be32_to_cpup((__be32 *)p);
- p += 8;
- if (be32_to_cpu(initial_boot_params-version) 0x10)
- p = ALIGN(p, sz = 8 ? 8 : 4);
- p += sz;
- p = ALIGN(p, 4);
- continue;
- }
- if (tag != OF_DT_BEGIN_NODE) {
- pr_err(Invalid tag %x in flat device tree!\n, tag);
- return -EINVAL;
- }
- depth++;
- pathp = (char *)p;
- p = ALIGN(p + strlen(pathp) + 1, 4);
- if ((*pathp) == '/') {
- char *lp, *np;
- for (lp = NULL, np = pathp; *np; np++)
- if ((*np) == '/')
- lp = np+1;
- if (lp != NULL)
- pathp = lp;
- }
- rc = it(p, pathp, depth, data);
- if (rc != 0)
- break;
- } while (1);
-
- return rc;
-}
-
-/**
- * of_get_flat_dt_root - find the root node in the flat blob
- */
-unsigned long __init of_get_flat_dt_root(void)
-{
- unsigned long p = ((unsigned long)initial_boot_params) +
- be32_to_cpu(initial_boot_params-off_dt_struct);
-
- while (be32_to_cpup((__be32 *)p) == OF_DT_NOP)
- p += 4;
- BUG_ON(be32_to_cpup((__be32 *)p) != OF_DT_BEGIN_NODE);
- p += 4;
- return ALIGN(p + strlen((char *)p) + 1, 4);
-}
-
-/**
- * of_get_flat_dt_prop - Given a node in the flat blob, return the property ptr
- *
- * This function can be used within scan_flattened_dt callback to get
- * access to properties
- */
-void *__init of_get_flat_dt_prop(unsigned long node, const char *name,
-unsigned long *size)
-{
- return of_fdt_get_property(initial_boot_params, node, name, size);
-}
-
-/**
- * of_flat_dt_is_compatible - Return true if given node has compat in
compatible list
- * @node: node to test
- * @compat: compatible string to compare with compatible list.
- */
-int __init of_flat_dt_is_compatible(unsigned long node, const char *compat)
-{
- return of_fdt_is_compatible(initial_boot_params, node, compat);
-}
-
static void *unflatten_dt_alloc(unsigned long *mem, unsigned long size,
unsigned long align)
{
@@ -421,6 +312,115 @@ unsigned long unflatten_dt_node(struct boot_param_header
*blob,
return mem;
}
+/* Everything below here references initial_boot_params directly. */
+int __initdata dt_root_addr_cells;
+int __initdata dt_root_size_cells;
+
+struct boot_param_header *initial_boot_params;
+
+#ifdef CONFIG_EARLY_FLATTREE
+
+/**
+ * of_scan_flat_dt - scan flattened tree blob and call callback on each.
+ * @it: callback function
+ * @data: context data pointer
+ *
+ * This function is used to scan the flattened device-tree, it is
+ * used to extract the memory information at boot before we can
+ * unflatten the tree
+ */
+int __init
Re: application needs fast access to physical memory
Hello Scott, Do you know whether this patch is necessary if I were to use alloc_bootmem () (to set aside a region of contiguous physical memory) instead of the kernel parameter mem=256? -Steve Lin Scott Wood scottw...@freesc ale.com To steven@teradyne.com 11/18/2010 01:35 cc PMDavid Gibson da...@gibson.dropbear.id.au, Michael Ellerman mich...@ellerman.id.au, linuxppc-dev@lists.ozlabs.org Subject Re: application needs fast access to physical memory On Thu, 18 Nov 2010 10:55:21 -0600 steven@teradyne.com wrote: Thanks for the replies. In the Linux Device Drivers book regarding mmap(), it states: Mapping a device means associating a range of user-space addresses to device memory. Whenever the program reads or writes in the assigned address range, it is actually accessing the device. In the X server example, using mmap allows quick and easy access to the video card’s memory. For a performance-critical application like this, direct access makes a large difference. For whatever reason, mmap() is definitely not quick and does not appear to be a direct access to device memory. After the application completes a large write into physical memory (via the pointer returned from mmap()), the application performs an ioctl() to query whether the data actually arrived into the memory region. It seems to take some time before the associated kernel module actually sees the data in the physical memory region. There's a few things I should say about this memory region. There's a total of 512 MB of physical memory. U-Boot passes mem=256M as a kernel parameter to tell Linux to only directly manage the lower 256 MB. The special region of physical memory that the application is trying to access is the upper 256 MB of memory not directly managed by Linux. The mmap() call from the application is: *memptr = (void *) mmap( NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, _fdTerAlloc, (off_t) 0x1000); Try this patch: http://patchwork.ozlabs.org/patch/68246/ -Scott inline: graycol.gifinline: pic0.gifinline: ecblank.gif___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: remove second definition of STACK_FRAME_OVERHEAD
Since STACK_FRAME_OVERHEAD is defined in asm/ptrace.h and that is ASSEMBER safe, we can just include that instead of going via asm-offsets.h. Signed-off-by: Stephen Rothwell s...@canb.auug.org.au --- arch/powerpc/kernel/asm-offsets.c |1 - arch/powerpc/kernel/entry_32.S |1 + arch/powerpc/kernel/exceptions-64s.S|1 + arch/powerpc/kernel/fpu.S |1 + arch/powerpc/kernel/head_40x.S |1 + arch/powerpc/kernel/head_44x.S |1 + arch/powerpc/kernel/head_64.S |1 + arch/powerpc/kernel/head_8xx.S |1 + arch/powerpc/kernel/head_fsl_booke.S|1 + arch/powerpc/kernel/misc_32.S |1 + arch/powerpc/kernel/misc_64.S |1 + arch/powerpc/kernel/ppc_save_regs.S |1 + arch/powerpc/kernel/vector.S|1 + arch/powerpc/platforms/pseries/hvCall.S |1 + 14 files changed, 13 insertions(+), 1 deletions(-) This was prompted by another change that caused the multiple definitions to produce a warning. That warning has already been fixe, but this seems the correct thing to do anyway. I have build tested this for all the (top level) powerpc defconfigs. diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c index bd0df2e..23e6a93 100644 --- a/arch/powerpc/kernel/asm-offsets.c +++ b/arch/powerpc/kernel/asm-offsets.c @@ -209,7 +209,6 @@ int main(void) DEFINE(RTASENTRY, offsetof(struct rtas_t, entry)); /* Interrupt register frame */ - DEFINE(STACK_FRAME_OVERHEAD, STACK_FRAME_OVERHEAD); DEFINE(INT_FRAME_SIZE, STACK_INT_FRAME_SIZE); DEFINE(SWITCH_FRAME_SIZE, STACK_FRAME_OVERHEAD + sizeof(struct pt_regs)); #ifdef CONFIG_PPC64 diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S index ed4aeb9..c22dc1e 100644 --- a/arch/powerpc/kernel/entry_32.S +++ b/arch/powerpc/kernel/entry_32.S @@ -31,6 +31,7 @@ #include asm/asm-offsets.h #include asm/unistd.h #include asm/ftrace.h +#include asm/ptrace.h #undef SHOW_SYSCALLS #undef SHOW_SYSCALLS_TASK diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S index 9f8b01d..8a81799 100644 --- a/arch/powerpc/kernel/exceptions-64s.S +++ b/arch/powerpc/kernel/exceptions-64s.S @@ -13,6 +13,7 @@ */ #include asm/exception-64s.h +#include asm/ptrace.h /* * We layout physical memory as follows: diff --git a/arch/powerpc/kernel/fpu.S b/arch/powerpc/kernel/fpu.S index e86c040..de36955 100644 --- a/arch/powerpc/kernel/fpu.S +++ b/arch/powerpc/kernel/fpu.S @@ -23,6 +23,7 @@ #include asm/thread_info.h #include asm/ppc_asm.h #include asm/asm-offsets.h +#include asm/ptrace.h #ifdef CONFIG_VSX #define REST_32FPVSRS(n,c,base) \ diff --git a/arch/powerpc/kernel/head_40x.S b/arch/powerpc/kernel/head_40x.S index 8278e8b..9dd21a8 100644 --- a/arch/powerpc/kernel/head_40x.S +++ b/arch/powerpc/kernel/head_40x.S @@ -40,6 +40,7 @@ #include asm/thread_info.h #include asm/ppc_asm.h #include asm/asm-offsets.h +#include asm/ptrace.h /* As with the other PowerPC ports, it is expected that when code * execution begins here, the following registers contain valid, yet diff --git a/arch/powerpc/kernel/head_44x.S b/arch/powerpc/kernel/head_44x.S index 562305b..cbb3436 100644 --- a/arch/powerpc/kernel/head_44x.S +++ b/arch/powerpc/kernel/head_44x.S @@ -37,6 +37,7 @@ #include asm/thread_info.h #include asm/ppc_asm.h #include asm/asm-offsets.h +#include asm/ptrace.h #include asm/synch.h #include head_booke.h diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S index f0dd577..ce41b97 100644 --- a/arch/powerpc/kernel/head_64.S +++ b/arch/powerpc/kernel/head_64.S @@ -38,6 +38,7 @@ #include asm/page_64.h #include asm/irqflags.h #include asm/kvm_book3s_asm.h +#include asm/ptrace.h /* The physical memory is layed out such that the secondary processor * spin code sits at 0x...0x00ff. On server, the vectors follow diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S index 1f1a04b..1cbf64e 100644 --- a/arch/powerpc/kernel/head_8xx.S +++ b/arch/powerpc/kernel/head_8xx.S @@ -29,6 +29,7 @@ #include asm/thread_info.h #include asm/ppc_asm.h #include asm/asm-offsets.h +#include asm/ptrace.h /* Macro to make the code more readable. */ #ifdef CONFIG_8xx_CPU6 diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S index 529b817..3e02710 100644 --- a/arch/powerpc/kernel/head_fsl_booke.S +++ b/arch/powerpc/kernel/head_fsl_booke.S @@ -41,6 +41,7 @@ #include asm/ppc_asm.h #include asm/asm-offsets.h #include asm/cache.h +#include asm/ptrace.h #include head_booke.h /* As with the other PowerPC ports, it is expected that when code diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S index a7a570d..094bd98 100644 --- a/arch/powerpc/kernel/misc_32.S +++
linux-next: manual merge of the bkl-config tree with Linus' tree
Hi Arnd, Today's linux-next merge of the bkl-config tree got a conflict in arch/powerpc/kernel/setup_64.c between commit 0f6b77ca12bea571e0a97b0588f62aa5f6012d61 (powerpc: Update a BKL related comment) from Linus' tree and commit bb2d384ab8184eb7f7146897e47fa5b38583112c (BKL: remove references to lock_kernel from comments) from the bkl-config tree. I just used the former version. -- Cheers, Stephen Rothwells...@canb.auug.org.au http://www.canb.auug.org.au/~sfr/ pgpjDs0Zd7ePa.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
On Fri, 2010-11-19 at 16:31 +1100, Stephen Rothwell wrote: On Fri, 19 Nov 2010 09:08:02 +1100 Michael Ellerman mich...@ellerman.id.au wrote: I vote for: - Exception: 401 (Instruction Access) at f7937794 Or: ☛ Exception: 401 (Instruction Access) at f7937794 Let's get serious, it's _really_ like a phone call: ☎ Exception: 401 (Instruction Access) at f7937794 cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git merge branch
On Fri, 2010-11-19 at 16:31 +1100, Stephen Rothwell wrote: On Fri, 19 Nov 2010 09:08:02 +1100 Michael Ellerman mich...@ellerman.id.= au wrote: I vote for: =20 - Exception: 401 (Instruction Access) at f7937794 =20 Or: =20 =E2=98=9B Exception: 401 (Instruction Access) at f7937794 Let's get serious, it's _really_ like a phone call: =E2=98=8E Exception: 401 (Instruction Access) at f7937794 We need a dedicated NACK char! Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
