+++ /dev/null
-SPUFS(2) Linux Programmer's Manual SPUFS(2)
-
-
-
-NAME
- spufs - the SPU file system
-
-
-DESCRIPTION
- The SPU file system is used on PowerPC machines that implement the Cell
- Broadband Engine Architecture in order to access Synergistic Processor
- Units (SPUs).
-
- 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 use spu_create(2) to establish SPU contexts in the spufs root.
-
- Every SPU context is represented by a directory containing a predefined
- set of files. These files can be used for manipulating the state of the
- logical SPU. Users can change permissions on those files, but not actu-
- ally add or remove files.
-
-
-MOUNT OPTIONS
- uid=<uid>
- set the user owning the mount point, the default is 0 (root).
-
- gid=<gid>
- set the group owning the mount point, the default is 0 (root).
-
-
-FILES
- The files in spufs mostly follow the standard behavior for regular sys-
- tem calls like read(2) or write(2), but often support only a subset of
- the operations supported on regular file systems. This list details the
- supported operations and the deviations from the behaviour in the
- respective man pages.
-
- All files that support the read(2) operation also support readv(2) and
- all files that support the write(2) operation also support writev(2).
- All files support the access(2) and stat(2) family of operations, but
- only the st_mode, st_nlink, st_uid and st_gid fields of struct stat
- contain reliable information.
-
- All files support the chmod(2)/fchmod(2) and chown(2)/fchown(2) opera-
- tions, but will not be able to grant permissions that contradict the
- possible operations, e.g. read access on the wbox file.
-
- The current set of files is:
-
-
- /mem
- the contents of the local storage 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 possible operations on an
- open mem file are:
-
- read(2), pread(2), write(2), pwrite(2), lseek(2)
- These operate as documented, with the exception that seek(2),
- write(2) and pwrite(2) are not supported beyond the end of the
- file. The file size is the size of the local storage of the SPU,
- which normally is 256 kilobytes.
-
- mmap(2)
- Mapping mem into the process address space gives access to the
- SPU local storage within the process address space. Only
- MAP_SHARED mappings are allowed.
-
-
- /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. The possible
- operations on an open mbox file are:
-
- read(2)
- If a count smaller than four is requested, read returns -1 and
- sets errno to EINVAL. If there is no data available in the mail
- box, the return value is set to -1 and errno becomes EAGAIN.
- When data has been read successfully, four bytes are placed in
- the data buffer and the value four is returned.
-
-
- /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 family of system calls can be used to wait for it. The possible
- operations on an open ibox file are:
-
- read(2)
- If a count smaller than four is requested, read returns -1 and
- sets errno to EINVAL. If there is no data available in the mail
- box and the file descriptor has been opened with O_NONBLOCK, the
- return value is set to -1 and errno becomes EAGAIN.
-
- If there is no data available in the mail box and the file
- descriptor has been opened without O_NONBLOCK, the call will
- block until the SPU writes to its interrupt mailbox channel.
- When data has been read successfully, four bytes are placed in
- the data buffer and the value four is returned.
-
- poll(2)
- Poll on the ibox file returns (POLLIN | POLLRDNORM) whenever
- data is available for reading.
-
-
- /wbox
- The CPU to SPU communation mailbox. It is write-only and 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. The possible
- operations on an open wbox file are: write(2) If a count smaller than
- four is requested, write returns -1 and sets errno to EINVAL. If there
- is no space available in the mail box and the file descriptor has been
- opened with O_NONBLOCK, the return value is set to -1 and errno becomes
- EAGAIN.
-
- If there is no space available in the mail box and the file descriptor
- has been opened without O_NONBLOCK, the call will block until the SPU
- reads from its PPE mailbox channel. When data has been read success-
- fully, four bytes are placed in the data buffer and the value four is
- returned.
-
- poll(2)
- Poll on the ibox file returns (POLLOUT | POLLWRNORM) whenever
- space is available for writing.
-
-
- /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. The possible
- operations on an open *box_stat file are:
-
- read(2)
- If a count smaller than four is requested, read returns -1 and
- sets errno to EINVAL. Otherwise, a four byte value is placed in
- the data buffer, containing the number of elements that can be
- read from (for mbox_stat and ibox_stat) or written to (for
- wbox_stat) the respective mail box without blocking or resulting
- in EAGAIN.
-
-
- /npc
- /decr
- /decr_status
- /spu_tag_mask
- /event_mask
- /srr0
- Internal registers of the SPU. The representation is an ASCII string
- with the numeric value of the next instruction to be executed. These
- can be used in read/write mode for debugging, but normal operation of
- programs should not rely on them because access to any of them except
- npc requires an SPU context save and is therefore very inefficient.
-
- The contents of these files are:
-
- npc Next Program Counter
-
- decr SPU Decrementer
-
- decr_status Decrementer Status
-
- spu_tag_mask MFC tag mask for SPU DMA
-
- event_mask Event mask for SPU interrupts
-
- srr0 Interrupt Return address register
-
-
- The possible operations on an open npc, decr, decr_status,
- spu_tag_mask, event_mask or srr0 file are:
-
- read(2)
- When the count supplied to the read call is shorter than the
- required length for the pointer value plus a newline character,
- subsequent reads from the same file descriptor will result in
- completing the string, regardless of changes to the register by
- a running SPU task. When a complete string has been read, all
- subsequent read operations will return zero bytes and a new file
- descriptor needs to be opened to read the value again.
-
- write(2)
- A write operation on the file results in setting the register to
- the value given in the string. The string is parsed from the
- beginning to the first non-numeric character or the end of the
- buffer. Subsequent writes to the same file descriptor overwrite
- the previous setting.
-
-
- /fpcr
- This file gives access to the Floating Point Status and Control Regis-
- ter as a four byte long file. The operations on the fpcr file are:
-
- read(2)
- If a count smaller than four is requested, read returns -1 and
- sets errno to EINVAL. Otherwise, a four byte value is placed in
- the data buffer, containing the current value of the fpcr regis-
- ter.
-
- write(2)
- If a count smaller than four is requested, write returns -1 and
- sets errno to EINVAL. Otherwise, a four byte value is copied
- from the data buffer, updating the value of the fpcr register.
-
-
- /signal1
- /signal2
- The two signal notification channels of an SPU. These are read-write
- files that operate on a 32 bit word. Writing to one of these files
- triggers an interrupt on the SPU. The value written 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. The possible operations on an open signal1 or sig-
- nal2 file are:
-
- read(2)
- If a count smaller than four is requested, read returns -1 and
- sets errno to EINVAL. Otherwise, a four byte value is placed in
- the data buffer, containing the current value of the specified
- signal notification register.
-
- write(2)
- If a count smaller than four is requested, write returns -1 and
- sets errno to EINVAL. Otherwise, a four byte value is copied
- from the data buffer, updating the value of the specified signal
- notification register. The signal notification register will
- either be replaced with the input data or will be updated to the
- bitwise OR or the old value and the input data, depending on the
- contents of the signal1_type, or signal2_type respectively,
- file.
-
-
- /signal1_type
- /signal2_type
- These two files change the behavior of the signal1 and signal2 notifi-
- cation 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 subse-
- quently written to it. The possible operations on an open signal1_type
- or signal2_type file are:
-
- read(2)
- When the count supplied to the read call is shorter than the
- required length for the digit plus a newline character, subse-
- quent reads from the same file descriptor will result in com-
- pleting the string. When a complete string has been read, all
- subsequent read operations will return zero bytes and a new file
- descriptor needs to be opened to read the value again.
-
- write(2)
- A write operation on the file results in setting the register to
- the value given in the string. The string is parsed from the
- beginning to the first non-numeric character or the end of the
- buffer. Subsequent writes to the same file descriptor overwrite
- the previous setting.
-
-
-EXAMPLES
- /etc/fstab entry
- none /spu spufs gid=spu 0 0
-
-
-AUTHORS
- Arnd Bergmann <arndb@de.ibm.com>, Mark Nutter <mnutter@us.ibm.com>,
- Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
-
-SEE ALSO
- capabilities(7), close(2), spu_create(2), spu_run(2), spufs(7)
-
-
-
-Linux 2005-09-28 SPUFS(2)
-
-------------------------------------------------------------------------------
-
-SPU_RUN(2) Linux Programmer's Manual SPU_RUN(2)
-
-
-
-NAME
- spu_run - execute an spu context
-
-
-SYNOPSIS
- #include <sys/spu.h>
-
- int spu_run(int fd, unsigned int *npc, unsigned int *event);
-
-DESCRIPTION
- The spu_run system call is used on PowerPC machines that implement the
- Cell Broadband Engine Architecture in order to access Synergistic Pro-
- cessor Units (SPUs). It uses the fd that was returned from spu_cre-
- ate(2) to address a specific SPU context. When the context gets sched-
- uled to a physical SPU, it starts execution at the instruction pointer
- passed in npc.
-
- Execution of SPU code happens synchronously, meaning that spu_run does
- not return while the SPU is still running. If there is a need to exe-
- cute SPU code in parallel with other code on either the main CPU or
- other SPUs, you need to create a new thread of execution first, e.g.
- using the pthread_create(3) call.
-
- When spu_run returns, the current value of the SPU instruction pointer
- is written back to npc, so you can call spu_run again without updating
- the pointers.
-
- event can be a NULL pointer or point to an extended status code that
- gets filled when spu_run returns. It can be one of the following con-
- stants:
-
- SPE_EVENT_DMA_ALIGNMENT
- A DMA alignment error
-
- SPE_EVENT_SPE_DATA_SEGMENT
- A DMA segmentation error
-
- SPE_EVENT_SPE_DATA_STORAGE
- A DMA storage error
-
- If NULL is passed as the event argument, these errors will result in a
- signal delivered to the calling process.
-
-RETURN VALUE
- spu_run returns the value of the spu_status register or -1 to indicate
- an error and set errno to one of the error codes listed below. The
- spu_status register value contains a bit mask of status codes and
- optionally a 14 bit code returned from the stop-and-signal instruction
- on the SPU. The bit masks for the status codes are:
-
- 0x02 SPU was stopped by stop-and-signal.
-
- 0x04 SPU was stopped by halt.
-
- 0x08 SPU is waiting for a channel.
-
- 0x10 SPU is in single-step mode.
-
- 0x20 SPU has tried to execute an invalid instruction.
-
- 0x40 SPU has tried to access an invalid channel.
-
- 0x3fff0000
- The bits masked with this value contain the code returned from
- stop-and-signal.
-
- There are always one or more of the lower eight bits set or an error
- code is returned from spu_run.
-
-ERRORS
- EAGAIN or EWOULDBLOCK
- fd is in non-blocking mode and spu_run would block.
-
- EBADF fd is not a valid file descriptor.
-
- EFAULT npc is not a valid pointer or status is neither NULL nor a valid
- pointer.
-
- EINTR A signal occurred while spu_run was in progress. The npc value
- has been updated to the new program counter value if necessary.
-
- EINVAL fd is not a file descriptor returned from spu_create(2).
-
- ENOMEM Insufficient memory was available to handle a page fault result-
- ing from an MFC direct memory access.
-
- ENOSYS the functionality is not provided by the current system, because
- either the hardware does not provide SPUs or the spufs module is
- not loaded.
-
-
-NOTES
- spu_run is meant to be used from libraries that implement a more
- abstract interface to SPUs, not to be used from regular applications.
- See http://www.bsc.es/projects/deepcomputing/linuxoncell/ for the rec-
- ommended libraries.
-
-
-CONFORMING TO
- This call is Linux specific and only implemented by the ppc64 architec-
- ture. Programs using this system call are not portable.
-
-
-BUGS
- The code does not yet fully implement all features lined out here.
-
-
-AUTHOR
- Arnd Bergmann <arndb@de.ibm.com>
-
-SEE ALSO
- capabilities(7), close(2), spu_create(2), spufs(7)
-
-
-
-Linux 2005-09-28 SPU_RUN(2)
-
-------------------------------------------------------------------------------
-
-SPU_CREATE(2) Linux Programmer's Manual SPU_CREATE(2)
-
-
-
-NAME
- spu_create - create a new spu context
-
-
-SYNOPSIS
- #include <sys/types.h>
- #include <sys/spu.h>
-
- int spu_create(const char *pathname, int flags, mode_t mode);
-
-DESCRIPTION
- The spu_create system call is used on PowerPC machines that implement
- the Cell Broadband Engine Architecture in order to access Synergistic
- Processor Units (SPUs). It creates a new logical context for an SPU in
- pathname and returns a handle to associated with it. pathname must
- point to a non-existing directory in the mount point of the SPU file
- system (spufs). When spu_create is successful, a directory gets cre-
- ated on pathname and it is populated with files.
-
- The returned file handle can only be passed to spu_run(2) or closed,
- other operations are not defined on it. When it is closed, all associ-
- ated directory entries in spufs are removed. When the last file handle
- pointing either inside of the context directory or to this file
- descriptor is closed, the logical SPU context is destroyed.
-
- The parameter flags can be zero or any bitwise or'd combination of the
- following constants:
-
- SPU_RAWIO
- Allow mapping of some of the hardware registers of the SPU into
- user space. This flag requires the CAP_SYS_RAWIO capability, see
- capabilities(7).
-
- The mode parameter specifies the permissions used for creating the new
- directory in spufs. mode is modified with the user's umask(2) value
- and then used for both the directory and the files contained in it. The
- file permissions mask out some more bits of mode because they typically
- support only read or write access. See stat(2) for a full list of the
- possible mode values.
-
-
-RETURN VALUE
- spu_create returns a new file descriptor. It may return -1 to indicate
- an error condition and set errno to one of the error codes listed
- below.
-
-
-ERRORS
- EACCES
- The current user does not have write access on the spufs mount
- point.
-
- EEXIST An SPU context already exists at the given path name.
-
- EFAULT pathname is not a valid string pointer in the current address
- space.
-
- EINVAL pathname is not a directory in the spufs mount point.
-
- ELOOP Too many symlinks were found while resolving pathname.
-
- EMFILE The process has reached its maximum open file limit.
-
- ENAMETOOLONG
- pathname was too long.
-
- ENFILE The system has reached the global open file limit.
-
- ENOENT Part of pathname could not be resolved.
-
- ENOMEM The kernel could not allocate all resources required.
-
- ENOSPC There are not enough SPU resources available to create a new
- context or the user specific limit for the number of SPU con-
- texts has been reached.
-
- ENOSYS the functionality is not provided by the current system, because
- either the hardware does not provide SPUs or the spufs module is
- not loaded.
-
- ENOTDIR
- A part of pathname is not a directory.
-
-
-
-NOTES
- spu_create is meant to be used from libraries that implement a more
- abstract interface to SPUs, not to be used from regular applications.
- See http://www.bsc.es/projects/deepcomputing/linuxoncell/ for the rec-
- ommended libraries.
-
-
-FILES
- pathname must point to a location beneath the mount point of spufs. By
- convention, it gets mounted in /spu.
-
-
-CONFORMING TO
- This call is Linux specific and only implemented by the ppc64 architec-
- ture. Programs using this system call are not portable.
-
-
-BUGS
- The code does not yet fully implement all features lined out here.
-
-
-AUTHOR
- Arnd Bergmann <arndb@de.ibm.com>
-
-SEE ALSO
- capabilities(7), close(2), spu_run(2), spufs(7)
-
-
-
-Linux 2005-09-28 SPU_CREATE(2)
--- /dev/null
+SPU_RUN(2) Linux Programmer's Manual SPU_RUN(2)
+
+
+
+NAME
+ spu_run - execute an spu context
+
+
+SYNOPSIS
+ #include <sys/spu.h>
+
+ int spu_run(int fd, unsigned int *npc, unsigned int *event);
+
+DESCRIPTION
+ The spu_run system call is used on PowerPC machines that implement the
+ Cell Broadband Engine Architecture in order to access Synergistic Pro-
+ cessor Units (SPUs). It uses the fd that was returned from spu_cre-
+ ate(2) to address a specific SPU context. When the context gets sched-
+ uled to a physical SPU, it starts execution at the instruction pointer
+ passed in npc.
+
+ Execution of SPU code happens synchronously, meaning that spu_run does
+ not return while the SPU is still running. If there is a need to exe-
+ cute SPU code in parallel with other code on either the main CPU or
+ other SPUs, you need to create a new thread of execution first, e.g.
+ using the pthread_create(3) call.
+
+ When spu_run returns, the current value of the SPU instruction pointer
+ is written back to npc, so you can call spu_run again without updating
+ the pointers.
+
+ event can be a NULL pointer or point to an extended status code that
+ gets filled when spu_run returns. It can be one of the following con-
+ stants:
+
+ SPE_EVENT_DMA_ALIGNMENT
+ A DMA alignment error
+
+ SPE_EVENT_SPE_DATA_SEGMENT
+ A DMA segmentation error
+
+ SPE_EVENT_SPE_DATA_STORAGE
+ A DMA storage error
+
+ If NULL is passed as the event argument, these errors will result in a
+ signal delivered to the calling process.
+
+RETURN VALUE
+ spu_run returns the value of the spu_status register or -1 to indicate
+ an error and set errno to one of the error codes listed below. The
+ spu_status register value contains a bit mask of status codes and
+ optionally a 14 bit code returned from the stop-and-signal instruction
+ on the SPU. The bit masks for the status codes are:
+
+ 0x02 SPU was stopped by stop-and-signal.
+
+ 0x04 SPU was stopped by halt.
+
+ 0x08 SPU is waiting for a channel.
+
+ 0x10 SPU is in single-step mode.
+
+ 0x20 SPU has tried to execute an invalid instruction.
+
+ 0x40 SPU has tried to access an invalid channel.
+
+ 0x3fff0000
+ The bits masked with this value contain the code returned from
+ stop-and-signal.
+
+ There are always one or more of the lower eight bits set or an error
+ code is returned from spu_run.
+
+ERRORS
+ EAGAIN or EWOULDBLOCK
+ fd is in non-blocking mode and spu_run would block.
+
+ EBADF fd is not a valid file descriptor.
+
+ EFAULT npc is not a valid pointer or status is neither NULL nor a valid
+ pointer.
+
+ EINTR A signal occurred while spu_run was in progress. The npc value
+ has been updated to the new program counter value if necessary.
+
+ EINVAL fd is not a file descriptor returned from spu_create(2).
+
+ ENOMEM Insufficient memory was available to handle a page fault result-
+ ing from an MFC direct memory access.
+
+ ENOSYS the functionality is not provided by the current system, because
+ either the hardware does not provide SPUs or the spufs module is
+ not loaded.
+
+
+NOTES
+ spu_run is meant to be used from libraries that implement a more
+ abstract interface to SPUs, not to be used from regular applications.
+ See http://www.bsc.es/projects/deepcomputing/linuxoncell/ for the rec-
+ ommended libraries.
+
+
+CONFORMING TO
+ This call is Linux specific and only implemented by the ppc64 architec-
+ ture. Programs using this system call are not portable.
+
+
+BUGS
+ The code does not yet fully implement all features lined out here.
+
+
+AUTHOR
+ Arnd Bergmann <arndb@de.ibm.com>
+
+SEE ALSO
+ capabilities(7), close(2), spu_create(2), spufs(7)
+
+
+
+
+Linux 2005-09-28 SPU_RUN(2)
--- /dev/null
+SPUFS(2) Linux Programmer's Manual SPUFS(2)
+
+
+
+NAME
+ spufs - the SPU file system
+
+
+DESCRIPTION
+ The SPU file system is used on PowerPC machines that implement the Cell
+ Broadband Engine Architecture in order to access Synergistic Processor
+ Units (SPUs).
+
+ 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 use spu_create(2) to establish SPU contexts in the spufs root.
+
+ Every SPU context is represented by a directory containing a predefined
+ set of files. These files can be used for manipulating the state of the
+ logical SPU. Users can change permissions on those files, but not actu-
+ ally add or remove files.
+
+
+MOUNT OPTIONS
+ uid=<uid>
+ set the user owning the mount point, the default is 0 (root).
+
+ gid=<gid>
+ set the group owning the mount point, the default is 0 (root).
+
+
+FILES
+ The files in spufs mostly follow the standard behavior for regular sys-
+ tem calls like read(2) or write(2), but often support only a subset of
+ the operations supported on regular file systems. This list details the
+ supported operations and the deviations from the behaviour in the
+ respective man pages.
+
+ All files that support the read(2) operation also support readv(2) and
+ all files that support the write(2) operation also support writev(2).
+ All files support the access(2) and stat(2) family of operations, but
+ only the st_mode, st_nlink, st_uid and st_gid fields of struct stat
+ contain reliable information.
+
+ All files support the chmod(2)/fchmod(2) and chown(2)/fchown(2) opera-
+ tions, but will not be able to grant permissions that contradict the
+ possible operations, e.g. read access on the wbox file.
+
+ The current set of files is:
+
+
+ /mem
+ the contents of the local storage 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 possible operations on an
+ open mem file are:
+
+ read(2), pread(2), write(2), pwrite(2), lseek(2)
+ These operate as documented, with the exception that seek(2),
+ write(2) and pwrite(2) are not supported beyond the end of the
+ file. The file size is the size of the local storage of the SPU,
+ which normally is 256 kilobytes.
+
+ mmap(2)
+ Mapping mem into the process address space gives access to the
+ SPU local storage within the process address space. Only
+ MAP_SHARED mappings are allowed.
+
+
+ /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. The possible
+ operations on an open mbox file are:
+
+ read(2)
+ If a count smaller than four is requested, read returns -1 and
+ sets errno to EINVAL. If there is no data available in the mail
+ box, the return value is set to -1 and errno becomes EAGAIN.
+ When data has been read successfully, four bytes are placed in
+ the data buffer and the value four is returned.
+
+
+ /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 family of system calls can be used to wait for it. The possible
+ operations on an open ibox file are:
+
+ read(2)
+ If a count smaller than four is requested, read returns -1 and
+ sets errno to EINVAL. If there is no data available in the mail
+ box and the file descriptor has been opened with O_NONBLOCK, the
+ return value is set to -1 and errno becomes EAGAIN.
+
+ If there is no data available in the mail box and the file
+ descriptor has been opened without O_NONBLOCK, the call will
+ block until the SPU writes to its interrupt mailbox channel.
+ When data has been read successfully, four bytes are placed in
+ the data buffer and the value four is returned.
+
+ poll(2)
+ Poll on the ibox file returns (POLLIN | POLLRDNORM) whenever
+ data is available for reading.
+
+
+ /wbox
+ The CPU to SPU communation mailbox. It is write-only and 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. The possible
+ operations on an open wbox file are: write(2) If a count smaller than
+ four is requested, write returns -1 and sets errno to EINVAL. If there
+ is no space available in the mail box and the file descriptor has been
+ opened with O_NONBLOCK, the return value is set to -1 and errno becomes
+ EAGAIN.
+
+ If there is no space available in the mail box and the file descriptor
+ has been opened without O_NONBLOCK, the call will block until the SPU
+ reads from its PPE mailbox channel. When data has been read success-
+ fully, four bytes are placed in the data buffer and the value four is
+ returned.
+
+ poll(2)
+ Poll on the ibox file returns (POLLOUT | POLLWRNORM) whenever
+ space is available for writing.
+
+
+ /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. The possible
+ operations on an open *box_stat file are:
+
+ read(2)
+ If a count smaller than four is requested, read returns -1 and
+ sets errno to EINVAL. Otherwise, a four byte value is placed in
+ the data buffer, containing the number of elements that can be
+ read from (for mbox_stat and ibox_stat) or written to (for
+ wbox_stat) the respective mail box without blocking or resulting
+ in EAGAIN.
+
+
+ /npc
+ /decr
+ /decr_status
+ /spu_tag_mask
+ /event_mask
+ /srr0
+ Internal registers of the SPU. The representation is an ASCII string
+ with the numeric value of the next instruction to be executed. These
+ can be used in read/write mode for debugging, but normal operation of
+ programs should not rely on them because access to any of them except
+ npc requires an SPU context save and is therefore very inefficient.
+
+ The contents of these files are:
+
+ npc Next Program Counter
+
+ decr SPU Decrementer
+
+ decr_status Decrementer Status
+
+ spu_tag_mask MFC tag mask for SPU DMA
+
+ event_mask Event mask for SPU interrupts
+
+ srr0 Interrupt Return address register
+
+
+ The possible operations on an open npc, decr, decr_status,
+ spu_tag_mask, event_mask or srr0 file are:
+
+ read(2)
+ When the count supplied to the read call is shorter than the
+ required length for the pointer value plus a newline character,
+ subsequent reads from the same file descriptor will result in
+ completing the string, regardless of changes to the register by
+ a running SPU task. When a complete string has been read, all
+ subsequent read operations will return zero bytes and a new file
+ descriptor needs to be opened to read the value again.
+
+ write(2)
+ A write operation on the file results in setting the register to
+ the value given in the string. The string is parsed from the
+ beginning to the first non-numeric character or the end of the
+ buffer. Subsequent writes to the same file descriptor overwrite
+ the previous setting.
+
+
+ /fpcr
+ This file gives access to the Floating Point Status and Control Regis-
+ ter as a four byte long file. The operations on the fpcr file are:
+
+ read(2)
+ If a count smaller than four is requested, read returns -1 and
+ sets errno to EINVAL. Otherwise, a four byte value is placed in
+ the data buffer, containing the current value of the fpcr regis-
+ ter.
+
+ write(2)
+ If a count smaller than four is requested, write returns -1 and
+ sets errno to EINVAL. Otherwise, a four byte value is copied
+ from the data buffer, updating the value of the fpcr register.
+
+
+ /signal1
+ /signal2
+ The two signal notification channels of an SPU. These are read-write
+ files that operate on a 32 bit word. Writing to one of these files
+ triggers an interrupt on the SPU. The value written 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. The possible operations on an open signal1 or sig-
+ nal2 file are:
+
+ read(2)
+ If a count smaller than four is requested, read returns -1 and
+ sets errno to EINVAL. Otherwise, a four byte value is placed in
+ the data buffer, containing the current value of the specified
+ signal notification register.
+
+ write(2)
+ If a count smaller than four is requested, write returns -1 and
+ sets errno to EINVAL. Otherwise, a four byte value is copied
+ from the data buffer, updating the value of the specified signal
+ notification register. The signal notification register will
+ either be replaced with the input data or will be updated to the
+ bitwise OR or the old value and the input data, depending on the
+ contents of the signal1_type, or signal2_type respectively,
+ file.
+
+
+ /signal1_type
+ /signal2_type
+ These two files change the behavior of the signal1 and signal2 notifi-
+ cation 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 subse-
+ quently written to it. The possible operations on an open signal1_type
+ or signal2_type file are:
+
+ read(2)
+ When the count supplied to the read call is shorter than the
+ required length for the digit plus a newline character, subse-
+ quent reads from the same file descriptor will result in com-
+ pleting the string. When a complete string has been read, all
+ subsequent read operations will return zero bytes and a new file
+ descriptor needs to be opened to read the value again.
+
+ write(2)
+ A write operation on the file results in setting the register to
+ the value given in the string. The string is parsed from the
+ beginning to the first non-numeric character or the end of the
+ buffer. Subsequent writes to the same file descriptor overwrite
+ the previous setting.
+
+
+EXAMPLES
+ /etc/fstab entry
+ none /spu spufs gid=spu 0 0
+
+
+AUTHORS
+ Arnd Bergmann <arndb@de.ibm.com>, Mark Nutter <mnutter@us.ibm.com>,
+ Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
+
+SEE ALSO
+ capabilities(7), close(2), spu_create(2), spu_run(2), spufs(7)
+
+
+
+Linux 2005-09-28 SPUFS(2)
projects / linux-2.6-microblaze.git / commitdiff