Fixes problems identified in a code review:
- add comment with high level dscription of the GRU
- prepend "gru_" to all global names
- delete unused function
- couple of trivial bug fixes
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Jack Steiner <steiner@sgi.com>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This file contains the functions for handlinf GRU TLB flushing, This
includes functions to handle the MMUOPS callouts.
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>
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>
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 <steiner@sgi.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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 <steiner@sgi.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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: Jack Steiner <steiner@sgi.com>
Cc: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Dean Nelson
Jack Steiner
Andi Kleen
Tomas Janousek
Thomas Bogendoerfer
Oleg Nesterov
Thomas Petazzoni
Harvey Harrison
Ben Dooks
Adrian Bunk