Browse Source
cgroup/for-3.5 contains the following changes which blk-cgroup needs to proceed with the on-going cleanup. * Dynamic addition and removal of cftypes to make config/stat file handling modular for policies. * cgroup removal update to not wait for css references to drain to fix blkcg removal hang caused by cfq caching cfqgs. Pull in cgroup/for-3.5 into block/for-3.5/core. This causes the following conflicts in block/blk-cgroup.c. *master761b3ef50e"cgroup: remove cgroup_subsys argument from callbacks" conflicts with blkiocg_pre_destroy() addition and blkiocg_attach() removal. Resolved by removing @subsys from all subsys methods. *676f7c8f84"cgroup: relocate cftype and cgroup_subsys definitions in controllers" conflicts with ->pre_destroy() and ->attach() updates and removal of modular config. Resolved by dropping forward declarations of the methods and applying updates to the relocated blkio_subsys. *4baf6e3325"cgroup: convert all non-memcg controllers to the new cftype interface" builds upon the previous item. Resolved by adding ->base_cftypes to the relocated blkio_subsys. Signed-off-by: Tejun Heo <tj@kernel.org>
Tejun Heo
10 years ago
10691 changed files with 547244 additions and 337253 deletions
@ -0,0 +1,16 @@
@@ -0,0 +1,16 @@
|
||||
What: /sys/kernel/debug/olpc-ec/cmd |
||||
Date: Dec 2011 |
||||
KernelVersion: 3.4 |
||||
Contact: devel@lists.laptop.org |
||||
Description: |
||||
|
||||
A generic interface for executing OLPC Embedded Controller commands and |
||||
reading their responses. |
||||
|
||||
To execute a command, write data with the format: CC:N A A A A |
||||
CC is the (hex) command, N is the count of expected reply bytes, and A A A A |
||||
are optional (hex) arguments. |
||||
|
||||
To read the response (if any), read from the generic node after executing |
||||
a command. Hex reply bytes will be returned, *whether or not* they came from |
||||
the immediately previous command. |
||||
@ -0,0 +1,25 @@
@@ -0,0 +1,25 @@
|
||||
What: /sys/block/dm-<num>/dm/name |
||||
Date: January 2009 |
||||
KernelVersion: 2.6.29 |
||||
Contact: dm-devel@redhat.com |
||||
Description: Device-mapper device name. |
||||
Read-only string containing mapped device name. |
||||
Users: util-linux, device-mapper udev rules |
||||
|
||||
What: /sys/block/dm-<num>/dm/uuid |
||||
Date: January 2009 |
||||
KernelVersion: 2.6.29 |
||||
Contact: dm-devel@redhat.com |
||||
Description: Device-mapper device UUID. |
||||
Read-only string containing DM-UUID or empty string |
||||
if DM-UUID is not set. |
||||
Users: util-linux, device-mapper udev rules |
||||
|
||||
What: /sys/block/dm-<num>/dm/suspended |
||||
Date: June 2009 |
||||
KernelVersion: 2.6.31 |
||||
Contact: dm-devel@redhat.com |
||||
Description: Device-mapper device suspend state. |
||||
Contains the value 1 while the device is suspended. |
||||
Otherwise it contains 0. Read-only attribute. |
||||
Users: util-linux, device-mapper udev rules |
||||
@ -0,0 +1,14 @@
@@ -0,0 +1,14 @@
|
||||
Where: /sys/bus/event_source/devices/<dev>/format |
||||
Date: January 2012 |
||||
Kernel Version: 3.3 |
||||
Contact: Jiri Olsa <jolsa@redhat.com> |
||||
Description: |
||||
Attribute group to describe the magic bits that go into |
||||
perf_event_attr::config[012] for a particular pmu. |
||||
Each attribute of this group defines the 'hardware' bitmask |
||||
we want to export, so that userspace can deal with sane |
||||
name/value pairs. |
||||
|
||||
Example: 'config1:1,6-10,44' |
||||
Defines contents of attribute that occupies bits 1,6-10,44 of |
||||
perf_event_attr::config1. |
||||
@ -0,0 +1,75 @@
@@ -0,0 +1,75 @@
|
||||
What: /sys/bus/rpmsg/devices/.../name |
||||
Date: June 2011 |
||||
KernelVersion: 3.3 |
||||
Contact: Ohad Ben-Cohen <ohad@wizery.com> |
||||
Description: |
||||
Every rpmsg device is a communication channel with a remote |
||||
processor. Channels are identified with a (textual) name, |
||||
which is maximum 32 bytes long (defined as RPMSG_NAME_SIZE in |
||||
rpmsg.h). |
||||
|
||||
This sysfs entry contains the name of this channel. |
||||
|
||||
What: /sys/bus/rpmsg/devices/.../src |
||||
Date: June 2011 |
||||
KernelVersion: 3.3 |
||||
Contact: Ohad Ben-Cohen <ohad@wizery.com> |
||||
Description: |
||||
Every rpmsg device is a communication channel with a remote |
||||
processor. Channels have a local ("source") rpmsg address, |
||||
and remote ("destination") rpmsg address. When an entity |
||||
starts listening on one end of a channel, it assigns it with |
||||
a unique rpmsg address (a 32 bits integer). This way when |
||||
inbound messages arrive to this address, the rpmsg core |
||||
dispatches them to the listening entity (a kernel driver). |
||||
|
||||
This sysfs entry contains the src (local) rpmsg address |
||||
of this channel. If it contains 0xffffffff, then an address |
||||
wasn't assigned (can happen if no driver exists for this |
||||
channel). |
||||
|
||||
What: /sys/bus/rpmsg/devices/.../dst |
||||
Date: June 2011 |
||||
KernelVersion: 3.3 |
||||
Contact: Ohad Ben-Cohen <ohad@wizery.com> |
||||
Description: |
||||
Every rpmsg device is a communication channel with a remote |
||||
processor. Channels have a local ("source") rpmsg address, |
||||
and remote ("destination") rpmsg address. When an entity |
||||
starts listening on one end of a channel, it assigns it with |
||||
a unique rpmsg address (a 32 bits integer). This way when |
||||
inbound messages arrive to this address, the rpmsg core |
||||
dispatches them to the listening entity. |
||||
|
||||
This sysfs entry contains the dst (remote) rpmsg address |
||||
of this channel. If it contains 0xffffffff, then an address |
||||
wasn't assigned (can happen if the kernel driver that |
||||
is attached to this channel is exposing a service to the |
||||
remote processor. This make it a local rpmsg server, |
||||
and it is listening for inbound messages that may be sent |
||||
from any remote rpmsg client; it is not bound to a single |
||||
remote entity). |
||||
|
||||
What: /sys/bus/rpmsg/devices/.../announce |
||||
Date: June 2011 |
||||
KernelVersion: 3.3 |
||||
Contact: Ohad Ben-Cohen <ohad@wizery.com> |
||||
Description: |
||||
Every rpmsg device is a communication channel with a remote |
||||
processor. Channels are identified by a textual name (see |
||||
/sys/bus/rpmsg/devices/.../name above) and have a local |
||||
("source") rpmsg address, and remote ("destination") rpmsg |
||||
address. |
||||
|
||||
A channel is first created when an entity, whether local |
||||
or remote, starts listening on it for messages (and is thus |
||||
called an rpmsg server). |
||||
|
||||
When that happens, a "name service" announcement is sent |
||||
to the other processor, in order to let it know about the |
||||
creation of the channel (this way remote clients know they |
||||
can start sending messages). |
||||
|
||||
This sysfs entry tells us whether the channel is a local |
||||
server channel that is announced (values are either |
||||
true or false). |
||||
@ -0,0 +1,58 @@
@@ -0,0 +1,58 @@
|
||||
What: /sys/devices/socX |
||||
Date: January 2012 |
||||
contact: Lee Jones <lee.jones@linaro.org> |
||||
Description: |
||||
The /sys/devices/ directory contains a sub-directory for each |
||||
System-on-Chip (SoC) device on a running platform. Information |
||||
regarding each SoC can be obtained by reading sysfs files. This |
||||
functionality is only available if implemented by the platform. |
||||
|
||||
The directory created for each SoC will also house information |
||||
about devices which are commonly contained in /sys/devices/platform. |
||||
It has been agreed that if an SoC device exists, its supported |
||||
devices would be better suited to appear as children of that SoC. |
||||
|
||||
What: /sys/devices/socX/machine |
||||
Date: January 2012 |
||||
contact: Lee Jones <lee.jones@linaro.org> |
||||
Description: |
||||
Read-only attribute common to all SoCs. Contains the SoC machine |
||||
name (e.g. Ux500). |
||||
|
||||
What: /sys/devices/socX/family |
||||
Date: January 2012 |
||||
contact: Lee Jones <lee.jones@linaro.org> |
||||
Description: |
||||
Read-only attribute common to all SoCs. Contains SoC family name |
||||
(e.g. DB8500). |
||||
|
||||
What: /sys/devices/socX/soc_id |
||||
Date: January 2012 |
||||
contact: Lee Jones <lee.jones@linaro.org> |
||||
Description: |
||||
Read-only attribute supported by most SoCs. In the case of |
||||
ST-Ericsson's chips this contains the SoC serial number. |
||||
|
||||
What: /sys/devices/socX/revision |
||||
Date: January 2012 |
||||
contact: Lee Jones <lee.jones@linaro.org> |
||||
Description: |
||||
Read-only attribute supported by most SoCs. Contains the SoC's |
||||
manufacturing revision number. |
||||
|
||||
What: /sys/devices/socX/process |
||||
Date: January 2012 |
||||
contact: Lee Jones <lee.jones@linaro.org> |
||||
Description: |
||||
Read-only attribute supported ST-Ericsson's silicon. Contains the |
||||
the process by which the silicon chip was manufactured. |
||||
|
||||
What: /sys/bus/soc |
||||
Date: January 2012 |
||||
contact: Lee Jones <lee.jones@linaro.org> |
||||
Description: |
||||
The /sys/bus/soc/ directory contains the usual sub-folders |
||||
expected under most buses. /sys/bus/soc/devices is of particular |
||||
interest, as it contains a symlink for each SoC device found on |
||||
the system. Each symlink points back into the aforementioned |
||||
/sys/devices/socX devices. |
||||
@ -1,11 +0,0 @@
@@ -1,11 +0,0 @@
|
||||
What: /sys/kernel/mm/cleancache/ |
||||
Date: April 2011 |
||||
Contact: Dan Magenheimer <dan.magenheimer@oracle.com> |
||||
Description: |
||||
/sys/kernel/mm/cleancache/ contains a number of files which |
||||
record a count of various cleancache operations |
||||
(sum across all filesystems): |
||||
succ_gets |
||||
failed_gets |
||||
puts |
||||
flushes |
||||
@ -0,0 +1,256 @@
@@ -0,0 +1,256 @@
|
||||
<refentry id="vidioc-decoder-cmd"> |
||||
<refmeta> |
||||
<refentrytitle>ioctl VIDIOC_DECODER_CMD, VIDIOC_TRY_DECODER_CMD</refentrytitle> |
||||
&manvol; |
||||
</refmeta> |
||||
|
||||
<refnamediv> |
||||
<refname>VIDIOC_DECODER_CMD</refname> |
||||
<refname>VIDIOC_TRY_DECODER_CMD</refname> |
||||
<refpurpose>Execute an decoder command</refpurpose> |
||||
</refnamediv> |
||||
|
||||
<refsynopsisdiv> |
||||
<funcsynopsis> |
||||
<funcprototype> |
||||
<funcdef>int <function>ioctl</function></funcdef> |
||||
<paramdef>int <parameter>fd</parameter></paramdef> |
||||
<paramdef>int <parameter>request</parameter></paramdef> |
||||
<paramdef>struct v4l2_decoder_cmd *<parameter>argp</parameter></paramdef> |
||||
</funcprototype> |
||||
</funcsynopsis> |
||||
</refsynopsisdiv> |
||||
|
||||
<refsect1> |
||||
<title>Arguments</title> |
||||
|
||||
<variablelist> |
||||
<varlistentry> |
||||
<term><parameter>fd</parameter></term> |
||||
<listitem> |
||||
<para>&fd;</para> |
||||
</listitem> |
||||
</varlistentry> |
||||
<varlistentry> |
||||
<term><parameter>request</parameter></term> |
||||
<listitem> |
||||
<para>VIDIOC_DECODER_CMD, VIDIOC_TRY_DECODER_CMD</para> |
||||
</listitem> |
||||
</varlistentry> |
||||
<varlistentry> |
||||
<term><parameter>argp</parameter></term> |
||||
<listitem> |
||||
<para></para> |
||||
</listitem> |
||||
</varlistentry> |
||||
</variablelist> |
||||
</refsect1> |
||||
|
||||
<refsect1> |
||||
<title>Description</title> |
||||
|
||||
<note> |
||||
<title>Experimental</title> |
||||
|
||||
<para>This is an <link linkend="experimental">experimental</link> |
||||
interface and may change in the future.</para> |
||||
</note> |
||||
|
||||
<para>These ioctls control an audio/video (usually MPEG-) decoder. |
||||
<constant>VIDIOC_DECODER_CMD</constant> sends a command to the |
||||
decoder, <constant>VIDIOC_TRY_DECODER_CMD</constant> can be used to |
||||
try a command without actually executing it. To send a command applications |
||||
must initialize all fields of a &v4l2-decoder-cmd; and call |
||||
<constant>VIDIOC_DECODER_CMD</constant> or <constant>VIDIOC_TRY_DECODER_CMD</constant> |
||||
with a pointer to this structure.</para> |
||||
|
||||
<para>The <structfield>cmd</structfield> field must contain the |
||||
command code. Some commands use the <structfield>flags</structfield> field for |
||||
additional information. |
||||
</para> |
||||
|
||||
<para>A <function>write</function>() or &VIDIOC-STREAMON; call sends an implicit |
||||
START command to the decoder if it has not been started yet. |
||||
</para> |
||||
|
||||
<para>A <function>close</function>() or &VIDIOC-STREAMOFF; call of a streaming |
||||
file descriptor sends an implicit immediate STOP command to the decoder, and all |
||||
buffered data is discarded.</para> |
||||
|
||||
<para>These ioctls are optional, not all drivers may support |
||||
them. They were introduced in Linux 3.3.</para> |
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-decoder-cmd"> |
||||
<title>struct <structname>v4l2_decoder_cmd</structname></title> |
||||
<tgroup cols="5"> |
||||
&cs-str; |
||||
<tbody valign="top"> |
||||
<row> |
||||
<entry>__u32</entry> |
||||
<entry><structfield>cmd</structfield></entry> |
||||
<entry></entry> |
||||
<entry></entry> |
||||
<entry>The decoder command, see <xref linkend="decoder-cmds" />.</entry> |
||||
</row> |
||||
<row> |
||||
<entry>__u32</entry> |
||||
<entry><structfield>flags</structfield></entry> |
||||
<entry></entry> |
||||
<entry></entry> |
||||
<entry>Flags to go with the command. If no flags are defined for |
||||
this command, drivers and applications must set this field to zero.</entry> |
||||
</row> |
||||
<row> |
||||
<entry>union</entry> |
||||
<entry>(anonymous)</entry> |
||||
<entry></entry> |
||||
<entry></entry> |
||||
<entry></entry> |
||||
</row> |
||||
<row> |
||||
<entry></entry> |
||||
<entry>struct</entry> |
||||
<entry><structfield>start</structfield></entry> |
||||
<entry></entry> |
||||
<entry>Structure containing additional data for the |
||||
<constant>V4L2_DEC_CMD_START</constant> command.</entry> |
||||
</row> |
||||
<row> |
||||
<entry></entry> |
||||
<entry></entry> |
||||
<entry>__s32</entry> |
||||
<entry><structfield>speed</structfield></entry> |
||||
<entry>Playback speed and direction. The playback speed is defined as |
||||
<structfield>speed</structfield>/1000 of the normal speed. So 1000 is normal playback. |
||||
Negative numbers denote reverse playback, so -1000 does reverse playback at normal |
||||
speed. Speeds -1, 0 and 1 have special meanings: speed 0 is shorthand for 1000 |
||||
(normal playback). A speed of 1 steps just one frame forward, a speed of -1 steps |
||||
just one frame back. |
||||
</entry> |
||||
</row> |
||||
<row> |
||||
<entry></entry> |
||||
<entry></entry> |
||||
<entry>__u32</entry> |
||||
<entry><structfield>format</structfield></entry> |
||||
<entry>Format restrictions. This field is set by the driver, not the |
||||
application. Possible values are <constant>V4L2_DEC_START_FMT_NONE</constant> if |
||||
there are no format restrictions or <constant>V4L2_DEC_START_FMT_GOP</constant> |
||||
if the decoder operates on full GOPs (<wordasword>Group Of Pictures</wordasword>). |
||||
This is usually the case for reverse playback: the decoder needs full GOPs, which |
||||
it can then play in reverse order. So to implement reverse playback the application |
||||
must feed the decoder the last GOP in the video file, then the GOP before that, etc. etc. |
||||
</entry> |
||||
</row> |
||||
<row> |
||||
<entry></entry> |
||||
<entry>struct</entry> |
||||
<entry><structfield>stop</structfield></entry> |
||||
<entry></entry> |
||||
<entry>Structure containing additional data for the |
||||
<constant>V4L2_DEC_CMD_STOP</constant> command.</entry> |
||||
</row> |
||||
<row> |
||||
<entry></entry> |
||||
<entry></entry> |
||||
<entry>__u64</entry> |
||||
<entry><structfield>pts</structfield></entry> |
||||
<entry>Stop playback at this <structfield>pts</structfield> or immediately |
||||
if the playback is already past that timestamp. Leave to 0 if you want to stop after the |
||||
last frame was decoded. |
||||
</entry> |
||||
</row> |
||||
<row> |
||||
<entry></entry> |
||||
<entry>struct</entry> |
||||
<entry><structfield>raw</structfield></entry> |
||||
<entry></entry> |
||||
<entry></entry> |
||||
</row> |
||||
<row> |
||||
<entry></entry> |
||||
<entry></entry> |
||||
<entry>__u32</entry> |
||||
<entry><structfield>data</structfield>[16]</entry> |
||||
<entry>Reserved for future extensions. Drivers and |
||||
applications must set the array to zero.</entry> |
||||
</row> |
||||
</tbody> |
||||
</tgroup> |
||||
</table> |
||||
|
||||
<table pgwide="1" frame="none" id="decoder-cmds"> |
||||
<title>Decoder Commands</title> |
||||
<tgroup cols="3"> |
||||
&cs-def; |
||||
<tbody valign="top"> |
||||
<row> |
||||
<entry><constant>V4L2_DEC_CMD_START</constant></entry> |
||||
<entry>0</entry> |
||||
<entry>Start the decoder. When the decoder is already |
||||
running or paused, this command will just change the playback speed. |
||||
That means that calling <constant>V4L2_DEC_CMD_START</constant> when |
||||
the decoder was paused will <emphasis>not</emphasis> resume the decoder. |
||||
You have to explicitly call <constant>V4L2_DEC_CMD_RESUME</constant> for that. |
||||
This command has one flag: |
||||
<constant>V4L2_DEC_CMD_START_MUTE_AUDIO</constant>. If set, then audio will |
||||
be muted when playing back at a non-standard speed. |
||||
</entry> |
||||
</row> |
||||
<row> |
||||
<entry><constant>V4L2_DEC_CMD_STOP</constant></entry> |
||||
<entry>1</entry> |
||||
<entry>Stop the decoder. When the decoder is already stopped, |
||||
this command does nothing. This command has two flags: |
||||
if <constant>V4L2_DEC_CMD_STOP_TO_BLACK</constant> is set, then the decoder will |
||||
set the picture to black after it stopped decoding. Otherwise the last image will |
||||
repeat. If <constant>V4L2_DEC_CMD_STOP_IMMEDIATELY</constant> is set, then the decoder |
||||
stops immediately (ignoring the <structfield>pts</structfield> value), otherwise it |
||||
will keep decoding until timestamp >= pts or until the last of the pending data from |
||||
its internal buffers was decoded. |
||||
</entry> |
||||
</row> |
||||
<row> |
||||
<entry><constant>V4L2_DEC_CMD_PAUSE</constant></entry> |
||||
<entry>2</entry> |
||||
<entry>Pause the decoder. When the decoder has not been |
||||
started yet, the driver will return an &EPERM;. When the decoder is |
||||
already paused, this command does nothing. This command has one flag: |
||||
if <constant>V4L2_DEC_CMD_PAUSE_TO_BLACK</constant> is set, then set the |
||||
decoder output to black when paused. |
||||
</entry> |
||||
</row> |
||||
<row> |
||||
<entry><constant>V4L2_DEC_CMD_RESUME</constant></entry> |
||||
<entry>3</entry> |
||||
<entry>Resume decoding after a PAUSE command. When the |
||||
decoder has not been started yet, the driver will return an &EPERM;. |
||||
When the decoder is already running, this command does nothing. No |
||||
flags are defined for this command.</entry> |
||||
</row> |
||||
</tbody> |
||||
</tgroup> |
||||
</table> |
||||
|
||||
</refsect1> |
||||
|
||||
<refsect1> |
||||
&return-value; |
||||
|
||||
<variablelist> |
||||
<varlistentry> |
||||
<term><errorcode>EINVAL</errorcode></term> |
||||
<listitem> |
||||
<para>The <structfield>cmd</structfield> field is invalid.</para> |
||||
</listitem> |
||||
</varlistentry> |
||||
<varlistentry> |
||||
<term><errorcode>EPERM</errorcode></term> |
||||
<listitem> |
||||
<para>The application sent a PAUSE or RESUME command when |
||||
the decoder was not running.</para> |
||||
</listitem> |
||||
</varlistentry> |
||||
</variablelist> |
||||
</refsect1> |
||||
</refentry> |
||||