diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/fb/cyblafb/bugs | 1 | ||||
| -rw-r--r-- | Documentation/fb/cyblafb/fb.modes | 57 | ||||
| -rw-r--r-- | Documentation/fb/cyblafb/performance | 1 | ||||
| -rw-r--r-- | Documentation/fb/cyblafb/todo | 5 | ||||
| -rw-r--r-- | Documentation/fb/cyblafb/usage | 33 | ||||
| -rw-r--r-- | Documentation/fb/cyblafb/whatsnew | 29 | ||||
| -rw-r--r-- | Documentation/filesystems/spufs.txt | 521 | ||||
| -rw-r--r-- | Documentation/kprobes.txt | 3 | ||||
| -rw-r--r-- | Documentation/networking/bonding.txt | 2 | ||||
| -rw-r--r-- | Documentation/powerpc/00-INDEX | 10 |
10 files changed, 612 insertions, 50 deletions
diff --git a/Documentation/fb/cyblafb/bugs b/Documentation/fb/cyblafb/bugs index f90cc66ea919..9443a6d72cdd 100644 --- a/Documentation/fb/cyblafb/bugs +++ b/Documentation/fb/cyblafb/bugs @@ -11,4 +11,3 @@ Untested features All LCD stuff is untested. If it worked in tridentfb, it should work in cyblafb. Please test and report the results to Knut_Petersen@t-online.de. - diff --git a/Documentation/fb/cyblafb/fb.modes b/Documentation/fb/cyblafb/fb.modes index cf4351fc32ff..fe0e5223ba86 100644 --- a/Documentation/fb/cyblafb/fb.modes +++ b/Documentation/fb/cyblafb/fb.modes @@ -14,142 +14,141 @@ # mode "640x480-50" - geometry 640 480 640 3756 8 + geometry 640 480 2048 4096 8 timings 47619 4294967256 24 17 0 216 3 endmode mode "640x480-60" - geometry 640 480 640 3756 8 + geometry 640 480 2048 4096 8 timings 39682 4294967256 24 17 0 216 3 endmode mode "640x480-70" - geometry 640 480 640 3756 8 + geometry 640 480 2048 4096 8 timings 34013 4294967256 24 17 0 216 3 endmode mode "640x480-72" - geometry 640 480 640 3756 8 + geometry 640 480 2048 4096 8 timings 33068 4294967256 24 17 0 216 3 endmode mode "640x480-75" - geometry 640 480 640 3756 8 + geometry 640 480 2048 4096 8 timings 31746 4294967256 24 17 0 216 3 endmode mode "640x480-80" - geometry 640 480 640 3756 8 + geometry 640 480 2048 4096 8 timings 29761 4294967256 24 17 0 216 3 endmode mode "640x480-85" - geometry 640 480 640 3756 8 + geometry 640 480 2048 4096 8 timings 28011 4294967256 24 17 0 216 3 endmode mode "800x600-50" - geometry 800 600 800 3221 8 + geometry 800 600 2048 4096 8 timings 30303 96 24 14 0 136 11 endmode mode "800x600-60" - geometry 800 600 800 3221 8 + geometry 800 600 2048 4096 8 timings 25252 96 24 14 0 136 11 endmode mode "800x600-70" - geometry 800 600 800 3221 8 + geometry 800 600 2048 4096 8 timings 21645 96 24 14 0 136 11 endmode mode "800x600-72" - geometry 800 600 800 3221 8 + geometry 800 600 2048 4096 8 timings 21043 96 24 14 0 136 11 endmode mode "800x600-75" - geometry 800 600 800 3221 8 + geometry 800 600 2048 4096 8 timings 20202 96 24 14 0 136 11 endmode mode "800x600-80" - geometry 800 600 800 3221 8 + geometry 800 600 2048 4096 8 timings 18939 96 24 14 0 136 11 endmode mode "800x600-85" - geometry 800 600 800 3221 8 + geometry 800 600 2048 4096 8 timings 17825 96 24 14 0 136 11 endmode mode "1024x768-50" - geometry 1024 768 1024 2815 8 + geometry 1024 768 2048 4096 8 timings 19054 144 24 29 0 120 3 endmode mode "1024x768-60" - geometry 1024 768 1024 2815 8 + geometry 1024 768 2048 4096 8 timings 15880 144 24 29 0 120 3 endmode mode "1024x768-70" - geometry 1024 768 1024 2815 8 + geometry 1024 768 2048 4096 8 timings 13610 144 24 29 0 120 3 endmode mode "1024x768-72" - geometry 1024 768 1024 2815 8 + geometry 1024 768 2048 4096 8 timings 13232 144 24 29 0 120 3 endmode mode "1024x768-75" - geometry 1024 768 1024 2815 8 + geometry 1024 768 2048 4096 8 timings 12703 144 24 29 0 120 3 endmode mode "1024x768-80" - geometry 1024 768 1024 2815 8 + geometry 1024 768 2048 4096 8 timings 11910 144 24 29 0 120 3 endmode mode "1024x768-85" - geometry 1024 768 1024 2815 8 + geometry 1024 768 2048 4096 8 timings 11209 144 24 29 0 120 3 endmode mode "1280x1024-50" - geometry 1280 1024 1280 2662 8 + geometry 1280 1024 2048 4096 8 timings 11114 232 16 39 0 160 3 endmode mode "1280x1024-60" - geometry 1280 1024 1280 2662 8 + geometry 1280 1024 2048 4096 8 timings 9262 232 16 39 0 160 3 endmode mode "1280x1024-70" - geometry 1280 1024 1280 2662 8 + geometry 1280 1024 2048 4096 8 timings 7939 232 16 39 0 160 3 endmode mode "1280x1024-72" - geometry 1280 1024 1280 2662 8 + geometry 1280 1024 2048 4096 8 timings 7719 232 16 39 0 160 3 endmode mode "1280x1024-75" - geometry 1280 1024 1280 2662 8 + geometry 1280 1024 2048 4096 8 timings 7410 232 16 39 0 160 3 endmode mode "1280x1024-80" - geometry 1280 1024 1280 2662 8 + geometry 1280 1024 2048 4096 8 timings 6946 232 16 39 0 160 3 endmode mode "1280x1024-85" - geometry 1280 1024 1280 2662 8 + geometry 1280 1024 2048 4096 8 timings 6538 232 16 39 0 160 3 endmode - diff --git a/Documentation/fb/cyblafb/performance b/Documentation/fb/cyblafb/performance index eb4e47a9cea6..8d15d5dfc6b3 100644 --- a/Documentation/fb/cyblafb/performance +++ b/Documentation/fb/cyblafb/performance @@ -77,4 +77,3 @@ patch that speeds up kernel bitblitting a lot ( > 20%). | | | | | | | | | | +-----------+-----------------+-----------------+-----------------+ - diff --git a/Documentation/fb/cyblafb/todo b/Documentation/fb/cyblafb/todo index 80fb2f89b6c1..c5f6d0eae545 100644 --- a/Documentation/fb/cyblafb/todo +++ b/Documentation/fb/cyblafb/todo @@ -22,11 +22,10 @@ accelerated color blitting Who needs it? The console driver does use color everything else is done using color expanding blitting of 1bpp character bitmaps. -xpanning Who needs it? - ioctls Who needs it? -TV-out Will be done later +TV-out Will be done later. Use "vga= " at boot time + to set a suitable video mode. ??? Feel free to contact me if you have any feature requests diff --git a/Documentation/fb/cyblafb/usage b/Documentation/fb/cyblafb/usage index e627c8f54211..a39bb3d402a2 100644 --- a/Documentation/fb/cyblafb/usage +++ b/Documentation/fb/cyblafb/usage @@ -40,6 +40,16 @@ Selecting Modes None of the modes possible to select as startup modes are affected by the problems described at the end of the next subsection. + For all startup modes cyblafb chooses a virtual x resolution of 2048, + the only exception is mode 1280x1024 in combination with 32 bpp. This + allows ywrap scrolling for all those modes if rotation is 0 or 2, and + also fast scrolling if rotation is 1 or 3. The default virtual y reso- + lution is 4096 for bpp == 8, 2048 for bpp==16 and 1024 for bpp == 32, + again with the only exception of 1280x1024 at 32 bpp. + + Please do set your video memory size to 8 Mb in the Bios setup. Other + values will work, but performace is decreased for a lot of modes. + Mode changes using fbset ======================== @@ -54,20 +64,26 @@ Selecting Modes - if a flat panel is found, cyblafb does not allow you to program a resolution higher than the physical resolution of the flat panel monitor - - cyblafb does not allow xres to differ from xres_virtual - cyblafb does not allow vclk to exceed 230 MHz. As 32 bpp and (currently) 24 bit modes use a doubled vclk internally, the dotclock limit as seen by fbset is 115 MHz for those modes and 230 MHz for 8 and 16 bpp modes. + - cyblafb will allow you to select very high resolutions as + long as the hardware can be programmed to these modes. The + documented limit 1600x1200 is not enforced, but don't expect + perfect signal quality. - Any request that violates the rules given above will be ignored and - fbset will return an error. + Any request that violates the rules given above will be either changed + to something the hardware supports or an error value will be returned. If you program a virtual y resolution higher than the hardware limit, cyblafb will silently decrease that value to the highest possible - value. + value. The same is true for a virtual x resolution that is not + supported by the hardware. Cyblafb tries to adapt vyres first because + vxres decides if ywrap scrolling is possible or not. - Attempts to disable acceleration are ignored. + Attempts to disable acceleration are ignored, I believe that this is + safe. Some video modes that should work do not work as expected. If you use the standard fb.modes, fbset 640x480-60 will program that mode, but @@ -129,10 +145,6 @@ mode 640x480 or 800x600 or 1024x768 or 1280x1024 verbosity 0 is the default, increase to at least 2 for every bug report! -vesafb allows cyblafb to be loaded after vesafb has been - loaded. See sections "Module unloading ...". - - Development hints ================= @@ -195,7 +207,7 @@ a graphics mode. After booting, load cyblafb without any mode and bpp parameter and assign cyblafb to individual ttys using con2fb, e.g.: - modprobe cyblafb vesafb=1 + modprobe cyblafb con2fb /dev/fb1 /dev/tty1 Unloading cyblafb works without problems after you assign vesafb to all @@ -203,4 +215,3 @@ ttys again, e.g.: con2fb /dev/fb0 /dev/tty1 rmmod cyblafb - diff --git a/Documentation/fb/cyblafb/whatsnew b/Documentation/fb/cyblafb/whatsnew new file mode 100644 index 000000000000..76c07a26e044 --- /dev/null +++ b/Documentation/fb/cyblafb/whatsnew @@ -0,0 +1,29 @@ +0.62 +==== + + - the vesafb parameter has been removed as I decided to allow the + feature without any special parameter. + + - Cyblafb does not use the vga style of panning any longer, now the + "right view" register in the graphics engine IO space is used. Without + that change it was impossible to use all available memory, and without + access to all available memory it is impossible to ywrap. + + - The imageblit function now uses hardware acceleration for all font + widths. Hardware blitting across pixel column 2048 is broken in the + cyberblade/i1 graphics core, but we work around that hardware bug. + + - modes with vxres != xres are supported now. + + - ywrap scrolling is supported now and the default. This is a big + performance gain. + + - default video modes use vyres > yres and vxres > xres to allow + almost optimal scrolling speed for normal and rotated screens + + - some features mainly usefull for debugging the upper layers of the + framebuffer system have been added, have a look at the code + + - fixed: Oops after unloading cyblafb when reading /proc/io* + + - we work around some bugs of the higher framebuffer layers. diff --git a/Documentation/filesystems/spufs.txt b/Documentation/filesystems/spufs.txt new file mode 100644 index 000000000000..8edc3952eff4 --- /dev/null +++ b/Documentation/filesystems/spufs.txt @@ -0,0 +1,521 @@ +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 familiy 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 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. 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 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. 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 occured 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 + EACCESS + 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) diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt index 0541fe1de704..0ea5a0c6e827 100644 --- a/Documentation/kprobes.txt +++ b/Documentation/kprobes.txt @@ -411,7 +411,8 @@ int init_module(void) printk("Couldn't find %s to plant kprobe\n", "do_fork"); return -1; } - if ((ret = register_kprobe(&kp) < 0)) { + ret = register_kprobe(&kp); + if (ret < 0) { printk("register_kprobe failed, returned %d\n", ret); return -1; } diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt index b0fe41da007b..8d8b4e5ea184 100644 --- a/Documentation/networking/bonding.txt +++ b/Documentation/networking/bonding.txt @@ -945,7 +945,6 @@ bond0 Link encap:Ethernet HWaddr 00:C0:F0:1F:37:B4 collisions:0 txqueuelen:0 eth0 Link encap:Ethernet HWaddr 00:C0:F0:1F:37:B4 - inet addr:XXX.XXX.XXX.YYY Bcast:XXX.XXX.XXX.255 Mask:255.255.252.0 UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:3573025 errors:0 dropped:0 overruns:0 frame:0 TX packets:1643167 errors:1 dropped:0 overruns:1 carrier:0 @@ -953,7 +952,6 @@ eth0 Link encap:Ethernet HWaddr 00:C0:F0:1F:37:B4 Interrupt:10 Base address:0x1080 eth1 Link encap:Ethernet HWaddr 00:C0:F0:1F:37:B4 - inet addr:XXX.XXX.XXX.YYY Bcast:XXX.XXX.XXX.255 Mask:255.255.252.0 UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:3651769 errors:0 dropped:0 overruns:0 frame:0 TX packets:1643480 errors:0 dropped:0 overruns:0 carrier:0 diff --git a/Documentation/powerpc/00-INDEX b/Documentation/powerpc/00-INDEX index e7bea0a407b4..d6d65b9bcfe3 100644 --- a/Documentation/powerpc/00-INDEX +++ b/Documentation/powerpc/00-INDEX @@ -8,12 +8,18 @@ please mail me. cpu_features.txt - info on how we support a variety of CPUs with minimal compile-time options. +eeh-pci-error-recovery.txt + - info on PCI Bus EEH Error Recovery +hvcs.txt + - IBM "Hypervisor Virtual Console Server" Installation Guide +mpc52xx.txt + - Linux 2.6.x on MPC52xx family ppc_htab.txt - info about the Linux/PPC /proc/ppc_htab entry -smp.txt - - use and state info about Linux/PPC on MP machines SBC8260_memory_mapping.txt - EST SBC8260 board info +smp.txt + - use and state info about Linux/PPC on MP machines sound.txt - info on sound support under Linux/PPC zImage_layout.txt |