aboutsummaryrefslogtreecommitdiffstats
path: root/arch/ia64/lib/Makefile (follow)
AgeCommit message (Collapse)AuthorFilesLines
2007-12-07[IA64] export copy_page() to modulesAndrew Morton1-2/+2
With the unionfs patch applied I get ERROR: "copy_page" [fs/unionfs/unionfs.ko] undefined! the other architectures (some, at least) export copy_page() so I guess ia64 should also do so. To do this we need to move the copy_page() functions out of lib.a and into built-in.o and add the EXPORT_SYMBOL(). Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Kyle McMartin <kyle@mcmartin.ca> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Tony Luck <tony.luck@intel.com>
2007-03-06[IA64] always build arch/ia64/lib/xor.oLee Schermerhorn1-2/+1
Always build ia64 xor.o because multiple config options now depend on it. Necessary to build .20-mm* on ia64 when, e.g., CONFIG_ASYNC_TX_DMA is defined. Don't know if '_ASYNC_TX_DMA makes sense on ia64. If not, maybe Kconfig should preclude it. Could have defined a Kconfig option that defaults to true if MD_RAID456 || ASYNC_TX_DMA to control building of xor.o, but xor.o is only 848 bytes and this IS ia64... Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com> Cc: Bob Picco <bob.picco@hp.com> Cc: Eric Whitney <eric.whitney@hp.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Tony Luck <tony.luck@intel.com>
2006-08-03[PATCH] Fix RAID5 + IA64 compilePrarit Bhargava1-1/+1
CONFIG_MD_RAID5 became CONFIG_MD_RAID456 in drivers/md/Kconfig. Make the same change in arch/ia64 Signed-off-by: Prarit Bhargava <prarit@redhat.com> Signed-off-by: Aron Griffis <aron@hp.com> Acked-by: Jes Sorenson <jes@sgi.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2006-03-26[PATCH] bitops: ia64: use generic bitopsAkinobu Mita1-1/+1
- remove generic_fls64() - remove find_{next,first}{,_zero}_bit() - remove ext2_{set,clear,test,find_first_zero,find_next_zero}_bit() - remove minix_{test,set,test_and_clear,test,find_first_zero}_bit() - remove sched_find_first_bit() Signed-off-by: Akinobu Mita <mita@miraclelinux.com> Cc: "Luck, Tony" <tony.luck@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-10-20Update from upstream with manual merge of Yasunori Goto'sTony Luck1-1/+0
changes to swiotlb.c made in commit 281dd25cdc0d6903929b79183816d151ea626341 since this file has been moved from arch/ia64/lib/swiotlb.c to lib/swiotlb.c Signed-off-by: Tony Luck <tony.luck@intel.com>
2005-09-29[PATCH] swiotlb: move from arch/ia64/lib/ to lib/John W. Linville1-1/+1
The swiotlb implementation is shared by both IA-64 and EM64T. However, the source itself lives under arch/ia64. This patch moves swiotlb.c from arch/ia64/lib to lib/ and fixes-up the appropriate Makefile and Kconfig files. No actual changes are made to swiotlb.c. Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2005-09-14[LIB]: Consolidate _atomic_dec_and_lock()David S. Miller1-1/+0
Several implementations were essentialy a common piece of C code using the cmpxchg() macro. Put the implementation in one spot that everyone can share, and convert sparc64 over to using this. Alpha is the lone arch-specific implementation, which codes up a special fast path for the common case in order to avoid GP reloading which a pure C version would require. Signed-off-by: David S. Miller <davem@davemloft.net>
2005-08-26[IA64] Delete erroneous copy_page.o in global lib-y listKenneth Chen1-1/+1
copy_page.o appeared twice in arch/ia64/lib/Makefile. The one in global lib-y is wrong where it should be just in lib-$(CONFIG_ITANIUM). Both copy_page.o and copy_page_mck.o are build for Itanium2 processor and the link order will pick up the low performing copy_page function (originally written for itanium processor). In this case, we really want the copy_page_mck.o for optimized version. Signed-off-by: Kenneth Chen <kenneth.w.chen@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2005-04-16Linux-2.6.12-rc2Linus Torvalds1-0/+52
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!