Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit d702d121 authored by Tony Lindgren's avatar Tony Lindgren
Browse files

Merge with mainline to remove plat-omap/Kconfig conflict

Conflicts:
	arch/arm/plat-omap/Kconfig
parents 9418c65f ac0f6f92
Loading
Loading
Loading
Loading
+14 −0
Original line number Diff line number Diff line
@@ -128,3 +128,17 @@ Description:
		preferred request size for workloads where sustained
		throughput is desired.  If no optimal I/O size is
		reported this file contains 0.

What:		/sys/block/<disk>/queue/nomerges
Date:		January 2010
Contact:
Description:
		Standard I/O elevator operations include attempts to
		merge contiguous I/Os. For known random I/O loads these
		attempts will always fail and result in extra cycles
		being spent in the kernel. This allows one to turn off
		this behavior on one of two ways: When set to 1, complex
		merge checks are disabled, but the simple one-shot merges
		with the previous I/O request are enabled. When set to 2,
		all merge tries are disabled. The default value is 0 -
		which enables all types of merge tries.
+79 −0
Original line number Diff line number Diff line
What:		/sys/devices/.../power/
Date:		January 2009
Contact:	Rafael J. Wysocki <rjw@sisk.pl>
Description:
		The /sys/devices/.../power directory contains attributes
		allowing the user space to check and modify some power
		management related properties of given device.

What:		/sys/devices/.../power/wakeup
Date:		January 2009
Contact:	Rafael J. Wysocki <rjw@sisk.pl>
Description:
		The /sys/devices/.../power/wakeup attribute allows the user
		space to check if the device is enabled to wake up the system
		from sleep states, such as the memory sleep state (suspend to
		RAM) and hibernation (suspend to disk), and to enable or disable
		it to do that as desired.

		Some devices support "wakeup" events, which are hardware signals
		used to activate the system from a sleep state.  Such devices
		have one of the following two values for the sysfs power/wakeup
		file:

		+ "enabled\n" to issue the events;
		+ "disabled\n" not to do so;

		In that cases the user space can change the setting represented
		by the contents of this file by writing either "enabled", or
		"disabled" to it.

		For the devices that are not capable of generating system wakeup
		events this file contains "\n".  In that cases the user space
		cannot modify the contents of this file and the device cannot be
		enabled to wake up the system.

What:		/sys/devices/.../power/control
Date:		January 2009
Contact:	Rafael J. Wysocki <rjw@sisk.pl>
Description:
		The /sys/devices/.../power/control attribute allows the user
		space to control the run-time power management of the device.

		All devices have one of the following two values for the
		power/control file:

		+ "auto\n" to allow the device to be power managed at run time;
		+ "on\n" to prevent the device from being power managed;

		The default for all devices is "auto", which means that they may
		be subject to automatic power management, depending on their
		drivers.  Changing this attribute to "on" prevents the driver
		from power managing the device at run time.  Doing that while
		the device is suspended causes it to be woken up.

What:		/sys/devices/.../power/async
Date:		January 2009
Contact:	Rafael J. Wysocki <rjw@sisk.pl>
Description:
		The /sys/devices/.../async attribute allows the user space to
		enable or diasble the device's suspend and resume callbacks to
		be executed asynchronously (ie. in separate threads, in parallel
		with the main suspend/resume thread) during system-wide power
		transitions (eg. suspend to RAM, hibernation).

		All devices have one of the following two values for the
		power/async file:

		+ "enabled\n" to permit the asynchronous suspend/resume;
		+ "disabled\n" to forbid it;

		The value of this attribute may be changed by writing either
		"enabled", or "disabled" to it.

		It generally is unsafe to permit the asynchronous suspend/resume
		of a device unless it is certain that all of the PM dependencies
		of the device are known to the PM core.  However, for some
		devices this attribute is set to "enabled" by bus type code or
		device drivers and in that cases it should be safe to leave the
		default value.
+13 −0
Original line number Diff line number Diff line
@@ -101,3 +101,16 @@ Description:

		CAUTION: Using it will cause your machine's real-time (CMOS)
		clock to be set to a random invalid time after a resume.

What:		/sys/power/pm_async
Date:		January 2009
Contact:	Rafael J. Wysocki <rjw@sisk.pl>
Description:
		The /sys/power/pm_async file controls the switch allowing the
		user space to enable or disable asynchronous suspend and resume
		of devices.  If enabled, this feature will cause some device
		drivers' suspend and resume callbacks to be executed in parallel
		with each other and with the main suspend thread.  It is enabled
		if this file contains "1", which is the default.  It may be
		disabled by writing "0" to this file, in which case all devices
		will be suspended and resumed synchronously.
+2 −1
Original line number Diff line number Diff line
@@ -589,7 +589,8 @@ number of a video input as in &v4l2-input; field
	    <entry></entry>
	    <entry>A place holder for future extensions and custom
(driver defined) buffer types
<constant>V4L2_BUF_TYPE_PRIVATE</constant> and higher.</entry>
<constant>V4L2_BUF_TYPE_PRIVATE</constant> and higher. Applications
should set this to 0.</entry>
	  </row>
	</tbody>
      </tgroup>
+23 −17
Original line number Diff line number Diff line
@@ -54,12 +54,10 @@ to enqueue an empty (capturing) or filled (output) buffer in the
driver's incoming queue. The semantics depend on the selected I/O
method.</para>

    <para>To enqueue a <link linkend="mmap">memory mapped</link>
buffer applications set the <structfield>type</structfield> field of a
&v4l2-buffer; to the same buffer type as previously &v4l2-format;
<structfield>type</structfield> and &v4l2-requestbuffers;
<structfield>type</structfield>, the <structfield>memory</structfield>
field to <constant>V4L2_MEMORY_MMAP</constant> and the
    <para>To enqueue a buffer applications set the <structfield>type</structfield>
field of a &v4l2-buffer; to the same buffer type as was previously used
with &v4l2-format; <structfield>type</structfield> and &v4l2-requestbuffers;
<structfield>type</structfield>. Applications must also set the
<structfield>index</structfield> field. Valid index numbers range from
zero to the number of buffers allocated with &VIDIOC-REQBUFS;
(&v4l2-requestbuffers; <structfield>count</structfield>) minus one. The
@@ -70,8 +68,19 @@ intended for output (<structfield>type</structfield> is
<constant>V4L2_BUF_TYPE_VBI_OUTPUT</constant>) applications must also
initialize the <structfield>bytesused</structfield>,
<structfield>field</structfield> and
<structfield>timestamp</structfield> fields. See <xref
	linkend="buffer" /> for details. When
<structfield>timestamp</structfield> fields, see <xref
linkend="buffer" /> for details.
Applications must also set <structfield>flags</structfield> to 0. If a driver
supports capturing from specific video inputs and you want to specify a video
input, then <structfield>flags</structfield> should be set to
<constant>V4L2_BUF_FLAG_INPUT</constant> and the field
<structfield>input</structfield> must be initialized to the desired input.
The <structfield>reserved</structfield> field must be set to 0.
</para>

    <para>To enqueue a <link linkend="mmap">memory mapped</link>
buffer applications set the <structfield>memory</structfield>
field to <constant>V4L2_MEMORY_MMAP</constant>. When
<constant>VIDIOC_QBUF</constant> is called with a pointer to this
structure the driver sets the
<constant>V4L2_BUF_FLAG_MAPPED</constant> and
@@ -81,14 +90,10 @@ structure the driver sets the
&EINVAL;.</para>

    <para>To enqueue a <link linkend="userp">user pointer</link>
buffer applications set the <structfield>type</structfield> field of a
&v4l2-buffer; to the same buffer type as previously &v4l2-format;
<structfield>type</structfield> and &v4l2-requestbuffers;
<structfield>type</structfield>, the <structfield>memory</structfield>
field to <constant>V4L2_MEMORY_USERPTR</constant> and the
buffer applications set the <structfield>memory</structfield>
field to <constant>V4L2_MEMORY_USERPTR</constant>, the
<structfield>m.userptr</structfield> field to the address of the
buffer and <structfield>length</structfield> to its size. When the
buffer is intended for output additional fields must be set as above.
buffer and <structfield>length</structfield> to its size.
When <constant>VIDIOC_QBUF</constant> is called with a pointer to this
structure the driver sets the <constant>V4L2_BUF_FLAG_QUEUED</constant>
flag and clears the <constant>V4L2_BUF_FLAG_MAPPED</constant> and
@@ -96,13 +101,14 @@ flag and clears the <constant>V4L2_BUF_FLAG_MAPPED</constant> and
<structfield>flags</structfield> field, or it returns an error code.
This ioctl locks the memory pages of the buffer in physical memory,
they cannot be swapped out to disk. Buffers remain locked until
dequeued, until the &VIDIOC-STREAMOFF; or &VIDIOC-REQBUFS; ioctl are
dequeued, until the &VIDIOC-STREAMOFF; or &VIDIOC-REQBUFS; ioctl is
called, or until the device is closed.</para>

    <para>Applications call the <constant>VIDIOC_DQBUF</constant>
ioctl to dequeue a filled (capturing) or displayed (output) buffer
from the driver's outgoing queue. They just set the
<structfield>type</structfield> and <structfield>memory</structfield>
<structfield>type</structfield>, <structfield>memory</structfield>
and <structfield>reserved</structfield>
fields of a &v4l2-buffer; as above, when <constant>VIDIOC_DQBUF</constant>
is called with a pointer to this structure the driver fills the
remaining fields or returns an error code.</para>
Loading