spufs: The SPU file system

@@ -0,0 +1,107 @@
+              *** The SPU file system ***
+
+Spufs is used to run code on the Synergistic Processing Units
+of the Cell Processor (a.k.a Broadband Engine).
+
+The file system provides a name space similar to posix shared
+memory or message queues. Users that have write permissions
+on the file system can create directories in the spufs root.
+
+Every directory represents an SPU context, which is currently
+mapped to a physical SPU, but that is going to change to a
+virtualization scheme in future updates.
+
+An SPU context directory contains a predefined set of files
+used for manipulating the state of the logical SPU. Users
+can change permissions on those files, but not actually
+add or remove files without removing the complete directory.
+
+The current set of files is:
+
+/mem	the contents of the local store memory of the SPU.
+	This can be accessed like a regular shared memory
+	file and contains both code and data in the address
+	space of the SPU.
+	The implemented file operations currently are read(),
+	write() and mmap(). We will need our own address
+	space operations as soon as we allow the SPU context
+	to be scheduled away from the physical SPU into
+	page cache.
+
+/run	A stub file that lets us do the spu_run() call.
+	spu_run suspends the current thread from the host
+	CPU and transfers the flow of execution to the SPU.
+	The spu_run call returns to the calling thread when a
+	state is entered that can not be handled by the kernel,
+	e.g.  an error in the SPU code or an exit() from it.
+	When a signal is pending for the host CPU thread, the
+	ioctl is interrupted and the SPU stopped in order to
+	call the signal handler.
+	Currently, there are three different methods how
+	spu_run can be entered with the /run file:
+	- The spu_run() syscall (see other patch)
+	- ioctl(), as used in previous versions
+	- read(), to return only the status, while the npc
+	  is updated in kernel or through the /npc file.
+	Very likely, the concept of the /run file will change
+	in the near future and it will be replaced with
+	something completely different.
+
+/mbox	The first SPU to CPU communication mailbox. This file
+	is read-only and can be read in units of 32 bits.
+	The file can only be used in non-blocking mode and
+	it even poll() will not block on it.
+	When no data is available in the mailbox, read() returns
+	EAGAIN.
+
+/ibox	The second SPU to CPU communication mailbox. This file
+	is similar to the first mailbox file, but can be read
+	in blocking I/O mode, and the poll familiy of system
+	calls can be used to wait for it.
+
+/wbox	The CPU to SPU communation mailbox. It is write-only
+	can can be written in units of 32 bits. If the mailbox
+	is full, write() will block and poll can be used to
+	wait for it becoming empty again.
+
+/mbox_stat
+/ibox_stat
+/wbox_stat
+	Read-only files that contain the length of the current
+	queue, i.e. how many words can be read from mbox or
+	ibox or how many words can be written to wbox without
+	blocking.
+	The files can be read only in 4-byte units and return
+	a big-endian binary integer number.
+
+/npc	The next program counter of the SPU. The representation
+	is an ASCII string with the numeric value of the
+	next instruction to be executed. It can be used in
+	read/write mode.
+
+/signal1
+/signal2
+	The two signal notification channels of an SPU. These
+	are read-write files that operate on a 32 bit word,
+	similar to the npc file.
+	Writing to one of these files triggers an interrupt on
+	the SPU. The value writting to the signal files can
+	be read from the SPU through a channel read or from
+	host user space through the file.
+	After the value has been read by the SPU, it is reset
+	to zero.
+
+/signal1_type
+/signal2_type
+	These two files change the behavior of the signal1 and
+	signal2 notification files. The contain a numerical
+	ASCII string which is read as either "1" or "0".
+	In mode 0 (overwrite), the hardware replaces the contents
+	of the signal channel with the data that is written to it.
+	in mode 1 (logical OR), the hardware accumulates the bits
+	that are subsequently written to it.
+
+There are also a number of files that are only there for
+debugging purposes and give low-level access to hardware
+registers of an SPE. These will certainly go away and
+should not be considered official interfaces.

@@ -53,6 +53,7 @@ obj-$(CONFIG_HVCS)		+= hvcserver.o
 obj-$(CONFIG_IBMVIO)		+= vio.o
 obj-$(CONFIG_XICS)		+= xics.o
 obj-$(CONFIG_MPIC)		+= mpic.o
+obj-$(CONFIG_SPU_FS)		+= spu_base.o
 
 obj-$(CONFIG_PPC_PMAC)		+= pmac_setup.o pmac_feature.o pmac_pci.o \
 				   pmac_time.o pmac_nvram.o pmac_low_i2c.o

@@ -845,6 +845,16 @@ config HUGETLBFS
 config HUGETLB_PAGE
 	def_bool HUGETLBFS
 
+config SPU_FS
+	tristate "SPU file system"
+	default m
+	depends on PPC_BPA
+	help
+	  The SPU file system is used to access Synergistic Processing
+	  Units on machines implementing the Broadband Processor
+	  Architecture.
+	
+
 config RAMFS
 	bool
 	default y

@@ -98,3 +98,4 @@ obj-$(CONFIG_BEFS_FS)		+= befs/
 obj-$(CONFIG_HOSTFS)		+= hostfs/
 obj-$(CONFIG_HPPFS)		+= hppfs/
 obj-$(CONFIG_DEBUG_FS)		+= debugfs/
+obj-$(CONFIG_SPU_FS)		+= spufs/

@@ -0,0 +1,3 @@
+obj-$(CONFIG_SPU_FS) += spufs.o
+
+spufs-y += inode.o file.o context.o