Panajev2001a
GAF's Pleasant Genius
Yet interesting stuff (credits go to version at Beyond3D's forums)
.
http://groups-beta.google.com/group/fa.linux.kernel/msg/9849e6f8455f0e57
Arnd Bergmann in IBM Germany is one of the people working for Linux on CELL: he has been submitting several patches for ppc64-bpa (BPA or Broadband Processor Architcture == CELL Architecture).
Arnd Bergmann Apr 28, 4:28 am show options
Newsgroups: fa.linux.kernel
From: Arnd Bergmann <a...@arndb.de> - Find messages by this author
Date: Thu, 28 Apr 2005 08:28:02 UTC
Local: Thurs,Apr 28 2005 4:28 am
Subject: [PATCH 4/4] ppc64: Add SPU file system
Reply | Reply to Author | Forward | Print | View Thread | Show original | Report Abuse
This is an early version of the SPU file system, which is used
to run code on the Synergistic Processing Units of the 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 ioctl. The only ioctl
method we need is the spu_run() call. spu_run suspends
the current thread from the host CPU and transfers
the flow of execution to the SPU.
The ioctl call return 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.
/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.
http://groups-beta.google.com/group/fa.linux.kernel/msg/9849e6f8455f0e57
Arnd Bergmann in IBM Germany is one of the people working for Linux on CELL: he has been submitting several patches for ppc64-bpa (BPA or Broadband Processor Architcture == CELL Architecture).