- 30 Jul, 2008 40 commits
-
-
Jack Steiner authored
This file contains the functions for initializing the driver, handling file & vma operations and for processing IOCTL requests from the user. Signed-off-by:
Jack Steiner <steiner@sgi.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
Jack Steiner authored
This patch contains the header file used to export GRU services to other kernel drivers such as XPMEM or XPNET. Signed-off-by:
-
Jack Steiner authored
This patch contains header files internal to the GRU driver. Signed-off-by:
-
Jack Steiner authored
This patchs contains macros & inline functions used to issue instructions to the GRU. Signed-off-by:
-
Jack Steiner authored
This series of patches adds a driver for the SGI UV GRU. The driver is still in development but it currently compiles for both x86_64 & IA64. All simple regression tests pass on IA64. Although features remain to be added, I'd like to start the process of getting the driver into the kernel. Additional kernel drivers will depend on services provide by the GRU driver. The GRU is a hardware resource located in the system chipset. The GRU contains memory that is mmaped into the user address space. This memory is used to communicate with the GRU to perform functions such as load/store, scatter/gather, bcopy, AMOs, etc. The GRU is directly accessed by user instructions using user virtual addresses. GRU instructions (ex., bcopy) use user virtual addresses for operands. The GRU contains a large TLB that is functionally very similar to processor TLBs. Because the external contains a TLB with user virtual address, it requires callouts from the core VM system when certain types of changes are made to the process page tables. There are several MMUOPS patches currently being discussed but none has been accepted into the kernel. The GRU driver is built using version V18 from Andrea Arcangeli. This patch: Contains the definitions of the hardware GRU data structures that are used by the driver to manage the GRU. [akpm@linux-foundation;org: export hpage_shift] Signed-off-by:
-
Jack Steiner authored
zap_vma_ptes() is intended to be used by drivers to unmap ptes assigned to the driver private vmas. This interface is similar to zap_page_range() but is less general & less likely to be abused. Needed by the GRU driver. Signed-off-by:
-
Andi Kleen authored
They are really class devices, but were incorrectly declared. This leads to crashes with the recent changes that makes non normal sysdevs use a different prototype. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by:
Andi Kleen <ak@linux.intel.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Pierre Ossman <drzeus-list@drzeus.cx> Cc: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
-
Tomas Janousek authored
Solves http://bugzilla.kernel.org/show_bug.cgi?id=11127 The old rtc.c driver did it and some drivers (like rtc-sh) do it in their release function, though they should not -- because they should provide the irq_set_state op and the rtc framework itself should care about it. This patch makes it do so. I am aware that some drivers, like rtc-sh, handle userspace PIE sets in their ioctl op (instead of having the framework call the op), exporting the irq_set_state op at the same time. The logic in rtc_irq_set_state should make sure it doesn't matter and the driver should not need to care stopping periodic interrupts in its release routine any more. The correct way, in my opinion, should be this: 1) The driver provides the irq_set_state op and does not care closing the interrupts in its release op. 2) If the driver does not provide the op and handles PIE in the ioctl op, it's reponsible for closing them in its release op. 3) Something similar for other IRQs, like UIE -- if there's no in-kernel API like irq_set_state, handle it in ioctl and release ops. The framework will be responsible either for everything or for nothing. (This will probably change later.) Signed-off-by:
Tomas Janousek <tomi@nomi.cz> Acked-by:
David Brownell <dbrownell@users.sourceforge.net> Acked-by:
Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
-
Thomas Bogendoerfer authored
Writes to the cmap fifo while the display is blanked caused cmap FIFO timeout messages and a wrong colormap. To avoid this the driver now maintains a colormap in memory and updates the colormap after the display is unblanked. Signed-off-by:
Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Cc: "Antonino A. Daplas" <adaplas@pol.net> Signed-off-by:
-
Oleg Nesterov authored
Dmitry Adamushko pointed out that the error handling in __create_workqueue_key() is not clear, add the comment. Signed-off-by:
Oleg Nesterov <oleg@tv-sign.ru> Cc: Dmitry Adamushko <dmitry.adamushko@gmail.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Thomas Petazzoni authored
Uninline the __remove_assoc_queue() function in fs/buffer.c, called at too many places and too long to really be inlined. Size results: text data bss dec hex filename 1134606 118840 212992 1466438 166046 vmlinux.old 1134303 118840 212992 1466135 165f17 vmlinux -303 0 0 -303 -12F +/- This patch is part of the Linux Tiny project and has been originally written by Matt Mackall <mpm@selenic.com>. Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Matt Mackall <mpm@selenic.com> Signed-off-by:
-
Harvey Harrison authored
Missing cpu_to_be64 on some constant assignments. fs/omfs/dir.c:107:16: warning: incorrect type in assignment (different base types) fs/omfs/dir.c:107:16: expected restricted __be64 [usertype] i_sibling fs/omfs/dir.c:107:16: got unsigned long long fs/omfs/file.c:33:13: warning: incorrect type in assignment (different base types) fs/omfs/file.c:33:13: expected restricted __be64 [usertype] e_next fs/omfs/file.c:33:13: got unsigned long long fs/omfs/file.c:36:24: warning: incorrect type in assignment (different base types) fs/omfs/file.c:36:24: expected restricted __be64 [usertype] e_cluster fs/omfs/file.c:36:24: got unsigned long long fs/omfs/file.c:37:23: warning: incorrect type in assignment (different base types) fs/omfs/file.c:37:23: expected restricted __be64 [usertype] e_blocks fs/omfs/file.c:37:23: got unsigned long long fs/omfs/bitmap.c:74:18: warning: incorrect type in argument 2 (different signedness) fs/omfs/bitmap.c:74:18: expected unsigned long volatile *addr fs/omfs/bitmap.c:74:18: got long *<noident> fs/omfs/bitmap.c:77:20: warning: incorrect type in argument 2 (different signedness) fs/omfs/bitmap.c:77:20: expected unsigned long volatile *addr fs/omfs/bitmap.c:77:20: got long *<noident> fs/omfs/bitmap.c:112:17: warning: incorrect type in argument 2 (different signedness) fs/omfs/bitmap.c:112:17: expected unsigned long volatile *addr fs/omfs/bitmap.c:112:17: got long *<noident> Signed-off-by:
Harvey Harrison <harvey.harrison@gmail.com> Acked-by:
Bob Copeland <me@bobcopeland.com> Signed-off-by:
-
Ben Dooks authored
Spelling fixes in scripts/mod/modpost.c Signed-off-by:
Ben Dooks <ben-linux@fluff.org> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Adrian Bunk authored
The removal of drivers/serial/v850e_uart.c originally was in my v850 removal patch, but it seems it got lost somewhere. Reported-by:
Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by:
Adrian Bunk <bunk@kernel.org> Acked-by:
Alan Cox <alan@redhat.com> Signed-off-by:
-
Paul Mundt authored
Commit 0031a06e converted all of the USB drivers to use dev_set_name(), though there was a typo on the m66592-udc conversion that handed off the wrong pointer (we want the struct device here obviously, not the struct usb_gadget). Signed-off-by:
Paul Mundt <lethal@linux-sh.org> Cc: Kay Sievers <kay.sievers@vrfy.org> Cc: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by:
-
Joerg Roedel authored
The file kernel.h contains the upper_32_bits macro. This patch adds the other part, the lower_32_bits macro. Its first use will be in the driver for AMD IOMMU. Cc: H. Peter Anvin <hpa@zytor.com> Signed-off-by:
Joerg Roedel <joerg.roedel@amd.com> Signed-off-by:
-
Fernando Luis Vazquez Cao authored
Signed-off-by:
Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp> Cc: Hugh Dickins <hugh@veritas.com> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: Rik van Riel <riel@redhat.com> Signed-off-by:
-
Fernando Luis Vazquez Cao authored
Signed-off-by:
-
Fernando Luis Vazquez Cao authored
Signed-off-by:
-
Fernando Luis Vazquez Cao authored
Signed-off-by:
-
Uwe Kleine-König authored
The comment assumed the burst to be one and the ratelimit used to be named printk_ratelimit_jiffies. Signed-off-by:
Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com> Cc: Dave Young <hidave.darkstar@gmail.com> Signed-off-by:
-
Jiri Slaby authored
The GET_MAJOR ioctl prints out a warning, make it ratelimited. Signed-off-by:
Jiri Slaby <jirislaby@gmail.com> Acked-by:
Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
Geert Uytterhoeven authored
commit fb6624eb (initrd: Fix virtual/physical mix-up in overwrite test) introduced the compiler warning below on mips, as its virt_to_page() doesn't cast the passed address to unsigned long internally, unlike on most other architectures: init/main.c: In function `start_kernel': init/main.c:633: warning: passing argument 1 of `virt_to_phys' makes pointer from integer without a cast init/main.c:636: warning: passing argument 1 of `virt_to_phys' makes pointer from integer without a cast For now, kill the warning by explicitly casting initrd_start to `void *', as that's the type it should really be. Reported-by:
Atsushi Nemoto <anemo@mba.ocn.ne.jp> Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Cc: Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
WANG Cong authored
/home/wangcong/Projects/linux-2.6/arch/um/drivers/line.c: In function `line_write_interrupt': /home/wangcong/Projects/linux-2.6/arch/um/drivers/line.c:366: error: `struct tty_ldisc' has no member named `write_wakeup' /home/wangcong/Projects/linux-2.6/arch/um/drivers/line.c:367: error: `struct tty_ldisc' has no member named `write_wakeup' Signed-off-by:
WANG Cong <wangcong@zeuux.org> Cc: Jeff Dike <jdike@addtoit.com> Acked-by:
-
Jerome Arbez-Gindre authored
Add a BlackBoard user to connector. BlackBoard is part of the TSP GPL sampling framework (http://savannah.nongnu.org/p/tsp) [akpm@linux-foundation.org: add comment] Signed-off-by:
Jerome Arbez-Gindre <jeromearbezgindre@gmail.com> Acked-by:
Evgeniy Polyakov <johnpol@2ka.mipt.ru> Signed-off-by:
-
Vegard Nossum authored
Signed-off-by:
-
Borislav Petkov authored
serial8250_startup() doesn't disable interrupts while taking the &up->port.lock which might race against the interrupt handler serial8250_interrupt(), which when entered, will deadlock waiting for the lock to be released. Signed-off-by:
Borislav Petkov <petkovbb@gmail.com> Tested-by:
Ingo Molnar <mingo@elte.hu> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
Mathieu Desnoyers authored
Paul pointed out two incorrect read barriers in the marker handler code in the path where multiple probes are connected. Those are ordering reads of "ptype" (single or multi probe marker), "multi" array pointer, and "multi" array data access. It should be ordered like this : read ptype smp_rmb() read multi array pointer smp_read_barrier_depends() access data referenced by multi array pointer The code with a single probe connected (optimized case, does not have to allocate an array) has correct memory ordering. It applies to kernel 2.6.26.x, 2.6.25.x and linux-next. Signed-off-by:
Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Cc: <stable@kernel.org> [2.6.25.x, 2.6.26.x] Signed-off-by:
-
David Brownell authored
It was pointed out that the RTC framework handles its mutex locks oddly ... returning -EBUSY when interrupted. This fixes that by returning the value of mutex_lock_interruptible() (i.e. -EINTR). Signed-off-by:
-
Julia Lawall authored
The mutex is released on a successful return, so it would seem that it should be released on an error return as well. The semantic patch finds this problem is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @@ expression l; @@ mutex_lock(l); ... when != mutex_unlock(l) when any when strict ( if (...) { ... when != mutex_unlock(l) + mutex_unlock(l); return ...; } | mutex_unlock(l); ) // </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Acked-by:
Krzysztof Helt <krzysztof.h1@wp.pl> Acked-by:
Ondrej Zajicek <santiago@crfreenet.org> Signed-off-by:
-
Alexey Dobriyan authored
Static (read: global) is potential problem. Two threads can corrupt each other's interrupt status, better avoid this. Signed-off-by:
Alexey Dobriyan <adobriyan@gmail.com> Cc: Wim Van Sebroeck <wim@iguana.be> Cc: Thomas Mingarelli <thomas.mingarelli@hp.com> Signed-off-by:
-
Jan Beulich authored
Exporting __init functions is wrong. Signed-off-by:
Jan Beulich <jbeulich@novell.com> Acked-by:
Konrad Rzeszutek <konradr@linux.vnet.ibm.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Ben Dooks authored
It seems that we need to ensure that the lcd is powered up at start, otherwise we do not see a display. Signed-off-by:
-
Li Zefan authored
Use cpuset.stack_list rather than kfifo, so we avoid memory allocation for kfifo. Signed-off-by:
Li Zefan <lizf@cn.fujitsu.com> Signed-off-by:
Lai Jiangshan <laijs@cn.fujitsu.com> Cc: Paul Menage <menage@google.com> Cc: Cedric Le Goater <clg@fr.ibm.com> Cc: Balbir Singh <balbir@in.ibm.com> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Paul Jackson <pj@sgi.com> Signed-off-by:
-
Li Zefan authored
When multiple cpusets are overlapping in their 'cpus' and hence they form a single sched domain, the largest sched_relax_domain_level among those should be used. But when top_cpuset's sched_load_balance is set, its sched_relax_domain_level is used regardless other sub-cpusets'. This patch fixes it by walking the cpuset hierarchy to find the largest sched_relax_domain_level. Signed-off-by:
Paul Jackson <pj@sgi.com> Signed-off-by:
-
Lai Jiangshan authored
All child cpusets contain a subset of the parent's cpus, so we can skip them when partitioning sched domains. This decreases 'csa' greately for cpusets with multi-level hierarchy. Signed-off-by:
-
Li Zefan authored
clean up hierarchy traversal code Signed-off-by:
-
Li Zefan authored
It's guaranteed by cgroup that old_cgrp != cgrp. Signed-off-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by:
-
Li Zefan authored
It's not small enough, and has 2 call sites. text data bss dec hex filename 12813 1676 4832 19321 4b79 cgroup.o.orig 12775 1676 4832 19283 4b53 cgroup.o Signed-off-by:
-
Li Zefan authored
- just call free_cg_links() in allocate_cg_links() - the list will get initialized in allocate_cg_links(), so don't init it twice Signed-off-by:
-
