You've already forked linux-apfs
mirror of
https://github.com/linux-apfs/linux-apfs.git
synced 2026-05-01 15:00:59 -07:00
Merge branches 'hyperv', 'multitouch', 'roccat', 'upstream', 'upstream-fixes', 'wacom' and 'wiimote' into for-linus
This commit is contained in:
Jiri Kosina
@@ -68,6 +68,7 @@ Juha Yrjola <juha.yrjola@solidboot.com>
|
||||
Kay Sievers <kay.sievers@vrfy.org>
|
||||
Kenneth W Chen <kenneth.w.chen@intel.com>
|
||||
Koushik <raghavendra.koushik@neterion.com>
|
||||
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
|
||||
Leonid I Ananiev <leonid.i.ananiev@intel.com>
|
||||
Linas Vepstas <linas@austin.ibm.com>
|
||||
Mark Brown <broonie@sirena.org.uk>
|
||||
@@ -111,3 +112,4 @@ Uwe Kleine-König <ukl@pengutronix.de>
|
||||
Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
|
||||
Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
|
||||
Takashi YOSHII <takashi.yoshii.zj@renesas.com>
|
||||
Yusuke Goda <goda.yusuke@renesas.com>
|
||||
|
||||
@@ -0,0 +1,22 @@
|
||||
What: /sys/firmware/acpi/pm_profile
|
||||
Date: 03-Nov-2011
|
||||
KernelVersion: v3.2
|
||||
Contact: linux-acpi@vger.kernel.org
|
||||
Description: The ACPI pm_profile sysfs interface exports the platform
|
||||
power management (and performance) requirement expectations
|
||||
as provided by BIOS. The integer value is directly passed as
|
||||
retrieved from the FADT ACPI table.
|
||||
Values: For possible values see ACPI specification:
|
||||
5.2.9 Fixed ACPI Description Table (FADT)
|
||||
Field: Preferred_PM_Profile
|
||||
|
||||
Currently these values are defined by spec:
|
||||
0 Unspecified
|
||||
1 Desktop
|
||||
2 Mobile
|
||||
3 Workstation
|
||||
4 Enterprise Server
|
||||
5 SOHO Server
|
||||
6 Appliance PC
|
||||
7 Performance Server
|
||||
>7 Reserved
|
||||
@@ -206,16 +206,3 @@ Description:
|
||||
when a discarded area is read the discard_zeroes_data
|
||||
parameter will be set to one. Otherwise it will be 0 and
|
||||
the result of reading a discarded area is undefined.
|
||||
What: /sys/block/<disk>/alias
|
||||
Date: Aug 2011
|
||||
Contact: Nao Nishijima <nao.nishijima.xt@hitachi.com>
|
||||
Description:
|
||||
A raw device name of a disk does not always point a same disk
|
||||
each boot-up time. Therefore, users have to use persistent
|
||||
device names, which udev creates when the kernel finds a disk,
|
||||
instead of raw device name. However, kernel doesn't show those
|
||||
persistent names on its messages (e.g. dmesg).
|
||||
This file can store an alias of the disk and it would be
|
||||
appeared in kernel messages if it is set. A disk can have an
|
||||
alias which length is up to 255bytes. Users can use alphabets,
|
||||
numbers, "-" and "_" in alias name. This file is writeonce.
|
||||
|
||||
@@ -71,3 +71,10 @@ Description: Value of 1 indicates the controller can honor the reset_devices
|
||||
a dump device, as kdump requires resetting the device in order
|
||||
to work reliably.
|
||||
|
||||
Where: /sys/bus/pci/devices/<dev>/ccissX/transport_mode
|
||||
Date: July 2011
|
||||
Kernel Version: 3.0
|
||||
Contact: iss_storagedev@hp.com
|
||||
Description: Value of "simple" indicates that the controller has been placed
|
||||
in "simple mode". Value of "performant" indicates that the
|
||||
controller has been placed in "performant mode".
|
||||
|
||||
@@ -0,0 +1,9 @@
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/quirks
|
||||
Date: November 2011
|
||||
Contact: Benjamin Tissoires <benjamin.tissoires@gmail.com>
|
||||
Description: The integer value of this attribute corresponds to the
|
||||
quirks actually in place to handle the device's protocol.
|
||||
When read, this attribute returns the current settings (see
|
||||
MT_QUIRKS_* in hid-multitouch.c).
|
||||
When written this attribute change on the fly the quirks, then
|
||||
the protocol to handle the device.
|
||||
@@ -0,0 +1,135 @@
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/actual_profile
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: The integer value of this attribute ranges from 0-4.
|
||||
When read, this attribute returns the number of the actual
|
||||
profile. This value is persistent, so its equivalent to the
|
||||
profile that's active when the device is powered on next time.
|
||||
When written, this file sets the number of the startup profile
|
||||
and the device activates this profile immediately.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/info
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When read, this file returns general data like firmware version.
|
||||
The data is 6 bytes long.
|
||||
This file is readonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/key_mask
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one deactivate certain keys like
|
||||
windows and application keys, to prevent accidental presses.
|
||||
Profile number for which this settings occur is included in
|
||||
written data. The data has to be 6 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/keys_capslock
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the function of the
|
||||
capslock key for a specific profile. Profile number is included
|
||||
in written data. The data has to be 6 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/keys_easyzone
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the function of the
|
||||
easyzone keys for a specific profile. Profile number is included
|
||||
in written data. The data has to be 65 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/keys_function
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the function of the
|
||||
function keys for a specific profile. Profile number is included
|
||||
in written data. The data has to be 41 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/keys_macro
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the function of the macro
|
||||
keys for a specific profile. Profile number is included in
|
||||
written data. The data has to be 35 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/keys_media
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the function of the media
|
||||
keys for a specific profile. Profile number is included in
|
||||
written data. The data has to be 29 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/keys_thumbster
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the function of the
|
||||
thumbster keys for a specific profile. Profile number is included
|
||||
in written data. The data has to be 23 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/last_set
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the time in secs since
|
||||
epoch in which the last configuration took place.
|
||||
The data has to be 20 bytes long.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/light
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one set the backlight intensity for
|
||||
a specific profile. Profile number is included in written data.
|
||||
The data has to be 10 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/macro
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one store macros with max 500
|
||||
keystrokes for a specific button for a specific profile.
|
||||
Button and profile numbers are included in written data.
|
||||
The data has to be 2083 bytes long.
|
||||
Before reading this file, control has to be written to select
|
||||
which profile and key to read.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/control
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one select which data from which
|
||||
profile will be read next. The data has to be 3 bytes long.
|
||||
This file is writeonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
|
||||
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/talk
|
||||
Date: June 2011
|
||||
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
|
||||
Description: When written, this file lets one trigger easyshift functionality
|
||||
from the host.
|
||||
The data has to be 16 bytes long.
|
||||
This file is writeonly.
|
||||
Users: http://roccat.sourceforge.net
|
||||
@@ -8,3 +8,15 @@ Contact: David Herrmann <dh.herrmann@googlemail.com>
|
||||
Description: Make it possible to set/get current led state. Reading from it
|
||||
returns 0 if led is off and 1 if it is on. Writing 0 to it
|
||||
disables the led, writing 1 enables it.
|
||||
|
||||
What: /sys/bus/hid/drivers/wiimote/<dev>/extension
|
||||
Date: August 2011
|
||||
KernelVersion: 3.2
|
||||
Contact: David Herrmann <dh.herrmann@googlemail.com>
|
||||
Description: This file contains the currently connected and initialized
|
||||
extensions. It can be one of: none, motionp, nunchuck, classic,
|
||||
motionp+nunchuck, motionp+classic
|
||||
motionp is the official Nintendo Motion+ extension, nunchuck is
|
||||
the official Nintendo Nunchuck extension and classic is the
|
||||
Nintendo Classic Controller extension. The motionp extension can
|
||||
be combined with the other two.
|
||||
|
||||
@@ -166,8 +166,8 @@ if (condition)
|
||||
else
|
||||
do_that();
|
||||
|
||||
This does not apply if one branch of a conditional statement is a single
|
||||
statement. Use braces in both branches.
|
||||
This does not apply if only one branch of a conditional statement is a single
|
||||
statement; in the latter case use braces in both branches:
|
||||
|
||||
if (condition) {
|
||||
do_this();
|
||||
|
||||
+168
-140
File diff suppressed because it is too large
Load Diff
@@ -2486,6 +2486,9 @@ ioctls.</para>
|
||||
<listitem>
|
||||
<para>Flash API. <xref linkend="flash-controls" /></para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>&VIDIOC-CREATE-BUFS; and &VIDIOC-PREPARE-BUF; ioctls.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</section>
|
||||
|
||||
|
||||
@@ -232,8 +232,9 @@ control is deprecated. New drivers and applications should use the
|
||||
<entry>Enables a power line frequency filter to avoid
|
||||
flicker. Possible values for <constant>enum v4l2_power_line_frequency</constant> are:
|
||||
<constant>V4L2_CID_POWER_LINE_FREQUENCY_DISABLED</constant> (0),
|
||||
<constant>V4L2_CID_POWER_LINE_FREQUENCY_50HZ</constant> (1) and
|
||||
<constant>V4L2_CID_POWER_LINE_FREQUENCY_60HZ</constant> (2).</entry>
|
||||
<constant>V4L2_CID_POWER_LINE_FREQUENCY_50HZ</constant> (1),
|
||||
<constant>V4L2_CID_POWER_LINE_FREQUENCY_60HZ</constant> (2) and
|
||||
<constant>V4L2_CID_POWER_LINE_FREQUENCY_AUTO</constant> (3).</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_CID_HUE_AUTO</constant></entry>
|
||||
|
||||
@@ -927,6 +927,33 @@ ioctl is called.</entry>
|
||||
Applications set or clear this flag before calling the
|
||||
<constant>VIDIOC_QBUF</constant> ioctl.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_BUF_FLAG_PREPARED</constant></entry>
|
||||
<entry>0x0400</entry>
|
||||
<entry>The buffer has been prepared for I/O and can be queued by the
|
||||
application. Drivers set or clear this flag when the
|
||||
<link linkend="vidioc-querybuf">VIDIOC_QUERYBUF</link>, <link
|
||||
linkend="vidioc-qbuf">VIDIOC_PREPARE_BUF</link>, <link
|
||||
linkend="vidioc-qbuf">VIDIOC_QBUF</link> or <link
|
||||
linkend="vidioc-qbuf">VIDIOC_DQBUF</link> ioctl is called.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_BUF_FLAG_NO_CACHE_INVALIDATE</constant></entry>
|
||||
<entry>0x0400</entry>
|
||||
<entry>Caches do not have to be invalidated for this buffer.
|
||||
Typically applications shall use this flag if the data captured in the buffer
|
||||
is not going to be touched by the CPU, instead the buffer will, probably, be
|
||||
passed on to a DMA-capable hardware unit for further processing or output.
|
||||
</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry><constant>V4L2_BUF_FLAG_NO_CACHE_CLEAN</constant></entry>
|
||||
<entry>0x0800</entry>
|
||||
<entry>Caches do not have to be cleaned for this buffer.
|
||||
Typically applications shall use this flag for output buffers if the data
|
||||
in this buffer has not been created by the CPU but by some DMA-capable unit,
|
||||
in which case caches have not been used.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
|
||||
@@ -469,6 +469,7 @@ and discussions on the V4L mailing list.</revremark>
|
||||
&sub-close;
|
||||
&sub-ioctl;
|
||||
<!-- All ioctls go here. -->
|
||||
&sub-create-bufs;
|
||||
&sub-cropcap;
|
||||
&sub-dbg-g-chip-ident;
|
||||
&sub-dbg-g-register;
|
||||
@@ -511,6 +512,7 @@ and discussions on the V4L mailing list.</revremark>
|
||||
&sub-queryctrl;
|
||||
&sub-query-dv-preset;
|
||||
&sub-querystd;
|
||||
&sub-prepare-buf;
|
||||
&sub-reqbufs;
|
||||
&sub-s-hw-freq-seek;
|
||||
&sub-streamon;
|
||||
|
||||
@@ -0,0 +1,139 @@
|
||||
<refentry id="vidioc-create-bufs">
|
||||
<refmeta>
|
||||
<refentrytitle>ioctl VIDIOC_CREATE_BUFS</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>VIDIOC_CREATE_BUFS</refname>
|
||||
<refpurpose>Create buffers for Memory Mapped or User Pointer I/O</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_create_buffers *<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_CREATE_BUFS</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>argp</parameter></term>
|
||||
<listitem>
|
||||
<para></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>This ioctl is used to create buffers for <link linkend="mmap">memory
|
||||
mapped</link> or <link linkend="userp">user pointer</link>
|
||||
I/O. It can be used as an alternative or in addition to the
|
||||
<constant>VIDIOC_REQBUFS</constant> ioctl, when a tighter control over buffers
|
||||
is required. This ioctl can be called multiple times to create buffers of
|
||||
different sizes.</para>
|
||||
|
||||
<para>To allocate device buffers applications initialize relevant fields of
|
||||
the <structname>v4l2_create_buffers</structname> structure. They set the
|
||||
<structfield>type</structfield> field in the
|
||||
<structname>v4l2_format</structname> structure, embedded in this
|
||||
structure, to the respective stream or buffer type.
|
||||
<structfield>count</structfield> must be set to the number of required buffers.
|
||||
<structfield>memory</structfield> specifies the required I/O method. The
|
||||
<structfield>format</structfield> field shall typically be filled in using
|
||||
either the <constant>VIDIOC_TRY_FMT</constant> or
|
||||
<constant>VIDIOC_G_FMT</constant> ioctl(). Additionally, applications can adjust
|
||||
<structfield>sizeimage</structfield> fields to fit their specific needs. The
|
||||
<structfield>reserved</structfield> array must be zeroed.</para>
|
||||
|
||||
<para>When the ioctl is called with a pointer to this structure the driver
|
||||
will attempt to allocate up to the requested number of buffers and store the
|
||||
actual number allocated and the starting index in the
|
||||
<structfield>count</structfield> and the <structfield>index</structfield> fields
|
||||
respectively. On return <structfield>count</structfield> can be smaller than
|
||||
the number requested. The driver may also increase buffer sizes if required,
|
||||
however, it will not update <structfield>sizeimage</structfield> field values.
|
||||
The user has to use <constant>VIDIOC_QUERYBUF</constant> to retrieve that
|
||||
information.</para>
|
||||
|
||||
<table pgwide="1" frame="none" id="v4l2-create-buffers">
|
||||
<title>struct <structname>v4l2_create_buffers</structname></title>
|
||||
<tgroup cols="3">
|
||||
&cs-str;
|
||||
<tbody valign="top">
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>index</structfield></entry>
|
||||
<entry>The starting buffer index, returned by the driver.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>count</structfield></entry>
|
||||
<entry>The number of buffers requested or granted.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>&v4l2-memory;</entry>
|
||||
<entry><structfield>memory</structfield></entry>
|
||||
<entry>Applications set this field to
|
||||
<constant>V4L2_MEMORY_MMAP</constant> or
|
||||
<constant>V4L2_MEMORY_USERPTR</constant>.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>&v4l2-format;</entry>
|
||||
<entry><structfield>format</structfield></entry>
|
||||
<entry>Filled in by the application, preserved by the driver.</entry>
|
||||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>reserved</structfield>[8]</entry>
|
||||
<entry>A place holder for future extensions.</entry>
|
||||
</row>
|
||||
</tbody>
|
||||
</tgroup>
|
||||
</table>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
&return-value;
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><errorcode>ENOMEM</errorcode></term>
|
||||
<listitem>
|
||||
<para>No memory to allocate buffers for <link linkend="mmap">memory
|
||||
mapped</link> I/O.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>EINVAL</errorcode></term>
|
||||
<listitem>
|
||||
<para>The buffer type (<structfield>type</structfield> field) or the
|
||||
requested I/O method (<structfield>memory</structfield>) is not
|
||||
supported.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
@@ -0,0 +1,88 @@
|
||||
<refentry id="vidioc-prepare-buf">
|
||||
<refmeta>
|
||||
<refentrytitle>ioctl VIDIOC_PREPARE_BUF</refentrytitle>
|
||||
&manvol;
|
||||
</refmeta>
|
||||
|
||||
<refnamediv>
|
||||
<refname>VIDIOC_PREPARE_BUF</refname>
|
||||
<refpurpose>Prepare a buffer for I/O</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_buffer *<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_PREPARE_BUF</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><parameter>argp</parameter></term>
|
||||
<listitem>
|
||||
<para></para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>Applications can optionally call the
|
||||
<constant>VIDIOC_PREPARE_BUF</constant> ioctl to pass ownership of the buffer
|
||||
to the driver before actually enqueuing it, using the
|
||||
<constant>VIDIOC_QBUF</constant> ioctl, and to prepare it for future I/O.
|
||||
Such preparations may include cache invalidation or cleaning. Performing them
|
||||
in advance saves time during the actual I/O. In case such cache operations are
|
||||
not required, the application can use one of
|
||||
<constant>V4L2_BUF_FLAG_NO_CACHE_INVALIDATE</constant> and
|
||||
<constant>V4L2_BUF_FLAG_NO_CACHE_CLEAN</constant> flags to skip the respective
|
||||
step.</para>
|
||||
|
||||
<para>The <structname>v4l2_buffer</structname> structure is
|
||||
specified in <xref linkend="buffer" />.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
&return-value;
|
||||
|
||||
<variablelist>
|
||||
<varlistentry>
|
||||
<term><errorcode>EBUSY</errorcode></term>
|
||||
<listitem>
|
||||
<para>File I/O is in progress.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
<varlistentry>
|
||||
<term><errorcode>EINVAL</errorcode></term>
|
||||
<listitem>
|
||||
<para>The buffer <structfield>type</structfield> is not
|
||||
supported, or the <structfield>index</structfield> is out of bounds,
|
||||
or no buffers have been allocated yet, or the
|
||||
<structfield>userptr</structfield> or
|
||||
<structfield>length</structfield> are invalid.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
</refsect1>
|
||||
</refentry>
|
||||
@@ -572,7 +572,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
|
||||
</para>
|
||||
<para>
|
||||
The simplest way to activate the FLASH based bad block table support
|
||||
is to set the option NAND_USE_FLASH_BBT in the option field of
|
||||
is to set the option NAND_BBT_USE_FLASH in the bbt_option field of
|
||||
the nand chip structure before calling nand_scan(). For AG-AND
|
||||
chips is this done by default.
|
||||
This activates the default FLASH based bad block table functionality
|
||||
@@ -773,20 +773,6 @@ struct nand_oobinfo {
|
||||
done according to the default builtin scheme.
|
||||
</para>
|
||||
</sect2>
|
||||
<sect2 id="User_space_placement_selection">
|
||||
<title>User space placement selection</title>
|
||||
<para>
|
||||
All non ecc functions like mtd->read and mtd->write use an internal
|
||||
structure, which can be set by an ioctl. This structure is preset
|
||||
to the autoplacement default.
|
||||
<programlisting>
|
||||
ioctl (fd, MEMSETOOBSEL, oobsel);
|
||||
</programlisting>
|
||||
oobsel is a pointer to a user supplied structure of type
|
||||
nand_oobconfig. The contents of this structure must match the
|
||||
criteria of the filesystem, which will be used. See an example in utils/nandwrite.c.
|
||||
</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
<sect1 id="Spare_area_autoplacement_default">
|
||||
<title>Spare area autoplacement default schemes</title>
|
||||
@@ -1158,9 +1144,6 @@ in this page</entry>
|
||||
These constants are defined in nand.h. They are ored together to describe
|
||||
the functionality.
|
||||
<programlisting>
|
||||
/* Use a flash based bad block table. This option is parsed by the
|
||||
* default bad block table function (nand_default_bbt). */
|
||||
#define NAND_USE_FLASH_BBT 0x00010000
|
||||
/* The hw ecc generator provides a syndrome instead a ecc value on read
|
||||
* This can only work if we have the ecc bytes directly behind the
|
||||
* data bytes. Applies for DOC and AG-AND Renesas HW Reed Solomon generators */
|
||||
|
||||
@@ -520,6 +520,11 @@ Here's a description of the fields of <varname>struct uio_mem</varname>:
|
||||
</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>
|
||||
<varname>const char *name</varname>: Optional. Set this to help identify
|
||||
the memory region, it will show up in the corresponding sysfs node.
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>
|
||||
<varname>int memtype</varname>: Required if the mapping is used. Set this to
|
||||
<varname>UIO_MEM_PHYS</varname> if you you have physical memory on your
|
||||
@@ -553,7 +558,7 @@ instead to remember such an address.
|
||||
</itemizedlist>
|
||||
|
||||
<para>
|
||||
Please do not touch the <varname>kobj</varname> element of
|
||||
Please do not touch the <varname>map</varname> element of
|
||||
<varname>struct uio_mem</varname>! It is used by the UIO framework
|
||||
to set up sysfs files for this mapping. Simply leave it alone.
|
||||
</para>
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
To choose IO schedulers at boot time, use the argument 'elevator=deadline'.
|
||||
'noop', 'as' and 'cfq' (the default) are also available. IO schedulers are
|
||||
assigned globally at boot time only presently.
|
||||
'noop' and 'cfq' (the default) are also available. IO schedulers are assigned
|
||||
globally at boot time only presently.
|
||||
|
||||
Each io queue has a set of io scheduler tunables associated with it. These
|
||||
tunables control how the io scheduler works. You can find these entries
|
||||
|
||||
@@ -78,6 +78,16 @@ The device naming scheme is:
|
||||
/dev/cciss/c1d1p2 Controller 1, disk 1, partition 2
|
||||
/dev/cciss/c1d1p3 Controller 1, disk 1, partition 3
|
||||
|
||||
CCISS simple mode support
|
||||
-------------------------
|
||||
|
||||
The "cciss_simple_mode=1" boot parameter may be used to prevent the driver
|
||||
from putting the controller into "performant" mode. The difference is that
|
||||
with simple mode, each command completion requires an interrupt, while with
|
||||
"performant mode" (the default, and ordinarily better performing) it is
|
||||
possible to have multiple command completions indicated by a single
|
||||
interrupt.
|
||||
|
||||
SCSI tape drive and medium changer support
|
||||
------------------------------------------
|
||||
|
||||
@@ -88,14 +98,12 @@ You must enable "SCSI tape drive support for Smart Array 5xxx" and
|
||||
"SCSI support" in your kernel configuration to be able to use SCSI
|
||||
tape drives with your Smart Array 5xxx controller.
|
||||
|
||||
Additionally, note that the driver will not engage the SCSI core at init
|
||||
time. The driver must be directed to dynamically engage the SCSI core via
|
||||
the /proc filesystem entry which the "block" side of the driver creates as
|
||||
/proc/driver/cciss/cciss* at runtime. This is because at driver init time,
|
||||
the SCSI core may not yet be initialized (because the driver is a block
|
||||
driver) and attempting to register it with the SCSI core in such a case
|
||||
would cause a hang. This is best done via an initialization script
|
||||
(typically in /etc/init.d, but could vary depending on distribution).
|
||||
Additionally, note that the driver will engage the SCSI core at init
|
||||
time if any tape drives or medium changers are detected. The driver may
|
||||
also be directed to dynamically engage the SCSI core via the /proc filesystem
|
||||
entry which the "block" side of the driver creates as
|
||||
/proc/driver/cciss/cciss* at runtime. This is best done via a script.
|
||||
|
||||
For example:
|
||||
|
||||
for x in /proc/driver/cciss/cciss[0-9]*
|
||||
|
||||
@@ -454,8 +454,8 @@ mounted hierarchy, to remove a task from its current cgroup you must
|
||||
move it into a new cgroup (possibly the root cgroup) by writing to the
|
||||
new cgroup's tasks file.
|
||||
|
||||
Note: If the ns cgroup is active, moving a process to another cgroup can
|
||||
fail.
|
||||
Note: Due to some restrictions enforced by some cgroup subsystems, moving
|
||||
a process to another cgroup can fail.
|
||||
|
||||
2.3 Mounting hierarchies by name
|
||||
--------------------------------
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user