Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
提交 6288cf1e 编写于 作者: L Len Brown
浏览文件
操作

Merge branches 'acpica', 'aml-custom', 'bugzilla-16548', 'bugzilla-20242',... 

Merge branches 'acpica', 'aml-custom', 'bugzilla-16548', 'bugzilla-20242', 'd3-cold', 'ec-asus' and 'thermal-fix' into release
上级 0a63e230 526b4af4 932df741 534bc4e3 28c2103d af986d10 b299eb5c
展开全部 隐藏空白更改
内联 并排
Showing with 35292 addition and 13276 deletion

要显示的变更太多。

To preserve performance only 1000 of 1000+ files are displayed.
文本差异 电子邮件补丁
.mailmap
浏览文件 @ 6288cf1e
......@@ -20,6 +20,7 @@ Andreas Herrmann <aherrman@de.ibm.com>
Andrew Morton <akpm@osdl.org>
Andrew Vasquez <andrew.vasquez@qlogic.com>
Andy Adamson <andros@citi.umich.edu>
Archit Taneja <archit@ti.com>
Arnaud Patard <arnaud.patard@rtp-net.org>
Arnd Bergmann <arnd@arndb.de>
Axel Dyks <xl@xlsigned.net>
......@@ -70,6 +71,7 @@ Leonid I Ananiev <leonid.i.ananiev@intel.com>
Linas Vepstas <linas@austin.ibm.com>
Mark Brown <broonie@sirena.org.uk>
Matthieu CASTET <castet.matthieu@free.fr>
Mayuresh Janorkar <mayur@ti.com>
Michael Buesch <mb@bu3sch.de>
Michael Buesch <mbuesch@freenet.de>
Michel Dänzer <michel@tungstengraphics.com>
......@@ -78,6 +80,7 @@ Morten Welinder <terra@gnome.org>
Morten Welinder <welinder@anemone.rentec.com>
Morten Welinder <welinder@darter.rentec.com>
Morten Welinder <welinder@troll.com>
Mythri P K <mythripk@ti.com>
Nguyen Anh Quynh <aquynh@gmail.com>
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Patrick Mochel <mochel@digitalimplant.org>
......@@ -98,6 +101,7 @@ S.Çağlar Onur <caglar@pardus.org.tr>
Simon Kelley <simon@thekelleys.org.uk>
Stéphane Witzmann <stephane.witzmann@ubpmes.univ-bpclermont.fr>
Stephen Hemminger <shemminger@osdl.org>
Sumit Semwal <sumit.semwal@ti.com>
Tejun Heo <htejun@gmail.com>
Thomas Graf <tgraf@suug.ch>
Tony Luck <tony.luck@intel.com>
......
CREDITS
浏览文件 @ 6288cf1e
......@@ -1677,7 +1677,7 @@ W: http://www.codemonkey.org.uk
D: Assorted VIA x86 support.
D: 2.5 AGPGART overhaul.
D: CPUFREQ maintenance.
D: Fedora kernel maintainence.
D: Fedora kernel maintenance.
D: Misc/Other.
S: 314 Littleton Rd, Westford, MA 01886, USA
......@@ -3211,7 +3211,7 @@ N: James Simmons
E: jsimmons@infradead.org
E: jsimmons@users.sf.net
D: Frame buffer device maintainer
D: input layer developement
D: input layer development
D: tty/console layer
D: various mipsel devices
S: 115 Carmel Avenue
......@@ -3290,7 +3290,7 @@ S: USA
N: Manfred Spraul
E: manfred@colorfullife.com
W: http://www.colorfullife.com/~manfred
D: Lots of tiny hacks. Larger improvments to SysV IPC msg,
D: Lots of tiny hacks. Larger improvements to SysV IPC msg,
D: slab, pipe, select.
S: 71701 Schwieberdingen
S: Germany
......
Documentation/00-INDEX
浏览文件 @ 6288cf1e
......@@ -206,8 +206,8 @@ laptops/
- directory with laptop related info and laptop driver documentation.
ldm.txt
- a brief description of LDM (Windows Dynamic Disks).
leds-class.txt
- documents LED handling under Linux.
leds/
- directory with info about LED handling under Linux.
local_ops.txt
- semantics and behavior of local atomic operations.
lockdep-design.txt
......@@ -328,8 +328,6 @@ sysrq.txt
- info on the magic SysRq key.
telephony/
- directory with info on telephony (e.g. voice over IP) support.
time_interpolators.txt
- info on time interpolators.
uml/
- directory with information about User Mode Linux.
unicode.txt
......@@ -346,8 +344,6 @@ vm/
- directory with info on the Linux vm code.
volatile-considered-harmful.txt
- Why the "volatile" type class should not be used
voyager.txt
- guide to running Linux on the Voyager architecture.
w1/
- directory with documents regarding the 1-wire (w1) subsystem.
watchdog/
......
Documentation/ABI/stable/sysfs-class-backlight
浏览文件 @ 6288cf1e
......@@ -34,3 +34,23 @@ Contact: Richard Purdie <rpurdie@rpsys.net>
Description:
Maximum brightness for <backlight>.
Users: HAL
What: /sys/class/backlight/<backlight>/type
Date: September 2010
KernelVersion: 2.6.37
Contact: Matthew Garrett <mjg@redhat.com>
Description:
The type of interface controlled by <backlight>.
"firmware": The driver uses a standard firmware interface
"platform": The driver uses a platform-specific interface
"raw": The driver controls hardware registers directly
In the general case, when multiple backlight
interfaces are available for a single device, firmware
control should be preferred to platform control should
be preferred to raw control. Using a firmware
interface reduces the probability of confusion with
the hardware and the OS independently updating the
backlight state. Platform interfaces are mostly a
holdover from pre-standardisation of firmware
interfaces.
Documentation/ABI/stable/sysfs-firmware-efi-vars 0 → 100644
浏览文件 @ 6288cf1e
What: /sys/firmware/efi/vars
Date: April 2004
Contact: Matt Domsch <Matt_Domsch@dell.com>
Description:
This directory exposes interfaces for interactive with
EFI variables. For more information on EFI variables,
see 'Variable Services' in the UEFI specification
(section 7.2 in specification version 2.3 Errata D).
In summary, EFI variables are named, and are classified
into separate namespaces through the use of a vendor
GUID. They also have an arbitrary binary value
associated with them.
The efivars module enumerates these variables and
creates a separate directory for each one found. Each
directory has a name of the form "<key>-<vendor guid>"
and contains the following files:
attributes: A read-only text file enumerating the
EFI variable flags. Potential values
include:
EFI_VARIABLE_NON_VOLATILE
EFI_VARIABLE_BOOTSERVICE_ACCESS
EFI_VARIABLE_RUNTIME_ACCESS
EFI_VARIABLE_HARDWARE_ERROR_RECORD
EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS
See the EFI documentation for an
explanation of each of these variables.
data: A read-only binary file that can be read
to attain the value of the EFI variable
guid: The vendor GUID of the variable. This
should always match the GUID in the
variable's name.
raw_var: A binary file that can be read to obtain
a structure that contains everything
there is to know about the variable.
For structure definition see "struct
efi_variable" in the kernel sources.
This file can also be written to in
order to update the value of a variable.
For this to work however, all fields of
the "struct efi_variable" passed must
match byte for byte with the structure
read out of the file, save for the value
portion.
**Note** the efi_variable structure
read/written with this file contains a
'long' type that may change widths
depending on your underlying
architecture.
size: As ASCII representation of the size of
the variable's value.
In addition, two other magic binary files are provided
in the top-level directory and are used for adding and
removing variables:
new_var: Takes a "struct efi_variable" and
instructs the EFI firmware to create a
new variable.
del_var: Takes a "struct efi_variable" and
instructs the EFI firmware to remove any
variable that has a matching vendor GUID
and variable key name.
Documentation/ABI/testing/configfs-spear-pcie-gadget 0 → 100644
浏览文件 @ 6288cf1e
What: /config/pcie-gadget
Date: Feb 2011
KernelVersion: 2.6.37
Contact: Pratyush Anand <pratyush.anand@st.com>
Description:
Interface is used to configure selected dual mode PCIe controller
as device and then program its various registers to configure it
as a particular device type.
This interfaces can be used to show spear's PCIe device capability.
Nodes are only visible when configfs is mounted. To mount configfs
in /config directory use:
# mount -t configfs none /config/
For nth PCIe Device Controller
/config/pcie-gadget.n/
link ... used to enable ltssm and read its status.
int_type ...used to configure and read type of supported
interrupt
no_of_msi ... used to configure number of MSI vector needed and
to read no of MSI granted.
inta ... write 1 to assert INTA and 0 to de-assert.
send_msi ... write MSI vector to be sent.
vendor_id ... used to write and read vendor id (hex)
device_id ... used to write and read device id (hex)
bar0_size ... used to write and read bar0_size
bar0_address ... used to write and read bar0 mapped area in hex.
bar0_rw_offset ... used to write and read offset of bar0 where
bar0_data will be written or read.
bar0_data ... used to write and read data at bar0_rw_offset.
Documentation/ABI/testing/pstore 0 → 100644
浏览文件 @ 6288cf1e
Where: /dev/pstore/...
Date: March 2011
Kernel Version: 2.6.39
Contact: tony.luck@intel.com
Description: Generic interface to platform dependent persistent storage.
Platforms that provide a mechanism to preserve some data
across system reboots can register with this driver to
provide a generic interface to show records captured in
the dying moments. In the case of a panic the last part
of the console log is captured, but other interesting
data can also be saved.
# mount -t pstore -o kmsg_bytes=8000 - /dev/pstore
$ ls -l /dev/pstore
total 0
-r--r--r-- 1 root root 7896 Nov 30 15:38 dmesg-erst-1
Different users of this interface will result in different
filename prefixes. Currently two are defined:
"dmesg" - saved console log
"mce" - architecture dependent data from fatal h/w error
Once the information in a file has been read, removing
the file will signal to the underlying persistent storage
device that it can reclaim the space for later re-use.
$ rm /dev/pstore/dmesg-erst-1
The expectation is that all files in /dev/pstore
will be saved elsewhere and erased from persistent store
soon after boot to free up space ready for the next
catastrophe.
The 'kmsg_bytes' mount option changes the target amount of
data saved on each oops/panic. Pstore saves (possibly
multiple) files based on the record size of the underlying
persistent storage until at least this amount is reached.
Default is 10 Kbytes.
Documentation/ABI/testing/sysfs-bus-css
浏览文件 @ 6288cf1e
......@@ -29,7 +29,7 @@ Contact: Cornelia Huck <cornelia.huck@de.ibm.com>
linux-s390@vger.kernel.org
Description: Contains the PIM/PAM/POM values, as reported by the
channel subsystem when last queried by the common I/O
layer (this implies that this attribute is not neccessarily
layer (this implies that this attribute is not necessarily
in sync with the values current in the channel subsystem).
Note: This is an I/O-subchannel specific attribute.
Users: s390-tools, HAL
Documentation/ABI/testing/sysfs-bus-media 0 → 100644
浏览文件 @ 6288cf1e
What: /sys/bus/media/devices/.../model
Date: January 2011
Contact: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
linux-media@vger.kernel.org
Description: Contains the device model name in UTF-8. The device version is
is not be appended to the model name.
Documentation/ABI/testing/sysfs-bus-pci
浏览文件 @ 6288cf1e
......@@ -145,9 +145,11 @@ Date: July 2010
Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
Description:
Reading this attribute will provide the firmware
given name(SMBIOS type 41 string) of the PCI device.
The attribute will be created only if the firmware
has given a name to the PCI device.
given name (SMBIOS type 41 string or ACPI _DSM string) of
the PCI device. The attribute will be created only
if the firmware has given a name to the PCI device.
ACPI _DSM string name will be given priority if the
system firmware provides SMBIOS type 41 string also.
Users:
Userspace applications interested in knowing the
firmware assigned name of the PCI device.
......@@ -157,12 +159,27 @@ Date: July 2010
Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
Description:
Reading this attribute will provide the firmware
given instance(SMBIOS type 41 device type instance)
of the PCI device. The attribute will be created
only if the firmware has given a device type instance
to the PCI device.
given instance (SMBIOS type 41 device type instance) of the
PCI device. The attribute will be created only if the firmware
has given an instance number to the PCI device.
Users:
Userspace applications interested in knowing the
firmware assigned device type instance of the PCI
device that can help in understanding the firmware
intended order of the PCI device.
What: /sys/bus/pci/devices/.../acpi_index
Date: July 2010
Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com
Description:
Reading this attribute will provide the firmware
given instance (ACPI _DSM instance number) of the PCI device.
The attribute will be created only if the firmware has given
an instance number to the PCI device. ACPI _DSM instance number
will be given priority if the system firmware provides SMBIOS
type 41 device type instance also.
Users:
Userspace applications interested in knowing the
firmware assigned instance number of the PCI
device that can help in understanding the firmware
intended order of the PCI device.
Documentation/ABI/testing/sysfs-bus-pci-devices-cciss
浏览文件 @ 6288cf1e
......@@ -59,3 +59,15 @@ Kernel Version: 2.6.31
Contact: iss_storagedev@hp.com
Description: Displays the usage count (number of opens) of logical drive Y
of controller X.
Where: /sys/bus/pci/devices/<dev>/ccissX/resettable
Date: February 2011
Kernel Version: 2.6.38
Contact: iss_storagedev@hp.com
Description: Value of 1 indicates the controller can honor the reset_devices
kernel parameter. Value of 0 indicates reset_devices cannot be
honored. This is to allow, for example, kexec tools to be able
to warn the user if they designate an unresettable device as
a dump device, as kdump requires resetting the device in order
to work reliably.
Documentation/ABI/testing/sysfs-bus-rbd
浏览文件 @ 6288cf1e
What: /sys/bus/rbd/
Date: November 2010
Contact: Yehuda Sadeh <yehuda@hq.newdream.net>,
Contact: Yehuda Sadeh <yehuda@newdream.net>,
Sage Weil <sage@newdream.net>
Description:
......
Documentation/ABI/testing/sysfs-class-led
浏览文件 @ 6288cf1e
......@@ -33,5 +33,5 @@ Contact: Richard Purdie <rpurdie@rpsys.net>
Description:
Invert the LED on/off state. This parameter is specific to
gpio and backlight triggers. In case of the backlight trigger,
it is usefull when driving a LED which is intended to indicate
it is useful when driving a LED which is intended to indicate
a device in a standby like state.
Documentation/ABI/testing/sysfs-devices-mmc 0 → 100644
浏览文件 @ 6288cf1e
What: /sys/devices/.../mmc_host/mmcX/mmcX:XXXX/enhanced_area_offset
Date: January 2011
Contact: Chuanxiao Dong <chuanxiao.dong@intel.com>
Description:
Enhanced area is a new feature defined in eMMC4.4 standard.
eMMC4.4 or later card can support such feature. This kind of
area can help to improve the card performance. If the feature
is enabled, this attribute will indicate the start address of
enhanced data area. If not, this attribute will be -EINVAL.
Unit Byte. Format decimal.
What: /sys/devices/.../mmc_host/mmcX/mmcX:XXXX/enhanced_area_size
Date: January 2011
Contact: Chuanxiao Dong <chuanxiao.dong@intel.com>
Description:
Enhanced area is a new feature defined in eMMC4.4 standard.
eMMC4.4 or later card can support such feature. This kind of
area can help to improve the card performance. If the feature
is enabled, this attribute will indicate the size of enhanced
data area. If not, this attribute will be -EINVAL.
Unit KByte. Format decimal.
Documentation/ABI/testing/sysfs-devices-power
浏览文件 @ 6288cf1e
......@@ -29,9 +29,8 @@ Description:
"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.
events this file is not present. In that case the device cannot
be enabled to wake up the system from sleep states.
What: /sys/devices/.../power/control
Date: January 2009
......@@ -85,7 +84,7 @@ Description:
The /sys/devices/.../wakeup_count attribute contains the number
of signaled wakeup events associated with the device. This
attribute is read-only. If the device is not enabled to wake up
the system from sleep states, this attribute is empty.
the system from sleep states, this attribute is not present.
What: /sys/devices/.../power/wakeup_active_count
Date: September 2010
......@@ -95,7 +94,7 @@ Description:
number of times the processing of wakeup events associated with
the device was completed (at the kernel level). This attribute
is read-only. If the device is not enabled to wake up the
system from sleep states, this attribute is empty.
system from sleep states, this attribute is not present.
What: /sys/devices/.../power/wakeup_hit_count
Date: September 2010
......@@ -105,7 +104,8 @@ Description:
number of times the processing of a wakeup event associated with
the device might prevent the system from entering a sleep state.
This attribute is read-only. If the device is not enabled to
wake up the system from sleep states, this attribute is empty.
wake up the system from sleep states, this attribute is not
present.
What: /sys/devices/.../power/wakeup_active
Date: September 2010
......@@ -115,7 +115,7 @@ Description:
or 0, depending on whether or not a wakeup event associated with
the device is being processed (1). This attribute is read-only.
If the device is not enabled to wake up the system from sleep
states, this attribute is empty.
states, this attribute is not present.
What: /sys/devices/.../power/wakeup_total_time_ms
Date: September 2010
......@@ -125,7 +125,7 @@ Description:
the total time of processing wakeup events associated with the
device, in milliseconds. This attribute is read-only. If the
device is not enabled to wake up the system from sleep states,
this attribute is empty.
this attribute is not present.
What: /sys/devices/.../power/wakeup_max_time_ms
Date: September 2010
......@@ -135,7 +135,7 @@ Description:
the maximum time of processing a single wakeup event associated
with the device, in milliseconds. This attribute is read-only.
If the device is not enabled to wake up the system from sleep
states, this attribute is empty.
states, this attribute is not present.
What: /sys/devices/.../power/wakeup_last_time_ms
Date: September 2010
......@@ -146,7 +146,7 @@ Description:
signaling the last wakeup event associated with the device, in
milliseconds. This attribute is read-only. If the device is
not enabled to wake up the system from sleep states, this
attribute is empty.
attribute is not present.
What: /sys/devices/.../power/autosuspend_delay_ms
Date: September 2010
......
Documentation/ABI/testing/sysfs-driver-hid 0 → 100644
浏览文件 @ 6288cf1e
What: For USB devices : /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/report_descriptor
For BT devices : /sys/class/bluetooth/hci<addr>/<hid-bus>:<vendor-id>:<product-id>.<num>/report_descriptor
Symlink : /sys/class/hidraw/hidraw<num>/device/report_descriptor
Date: Jan 2011
KernelVersion: 2.0.39
Contact: Alan Ott <alan@signal11.us>
Description: When read, this file returns the device's raw binary HID
report descriptor.
This file cannot be written.
Users: HIDAPI library (http://www.signal11.us/oss/hidapi)
Documentation/ABI/testing/sysfs-driver-hid-roccat-arvo 0 → 100644
浏览文件 @ 6288cf1e
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/arvo/roccatarvo<minor>/actual_profile
Date: Januar 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The integer value of this attribute ranges from 1-5.
When read, this attribute returns the number of the actual
profile which is also the profile that's active on device startup.
When written this attribute activates the selected 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>/arvo/roccatarvo<minor>/button
Date: Januar 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The keyboard can store short macros with consist of 1 button with
several modifier keys internally.
When written, this file lets one set the sequence for a specific
button for a specific profile. Button and profile numbers are
included in written data. The data has to be 24 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>/arvo/roccatarvo<minor>/info
Date: Januar 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read, this file returns some info about the device like the
installed firmware version.
The size of the data is 8 bytes in size.
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>/arvo/roccatarvo<minor>/key_mask
Date: Januar 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The keyboard lets the user deactivate 5 certain keys like the
windows and application keys, to protect the user from the outcome
of accidentally pressing them.
The integer value of this attribute has bits 0-4 set depending
on the state of the corresponding key.
When read, this file returns the current state of the buttons.
When written, the given buttons are activated/deactivated
immediately.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/arvo/roccatarvo<minor>/mode_key
Date: Januar 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The keyboard has a condensed layout without num-lock key.
Instead it uses a mode-key which activates a gaming mode where
the assignment of the number block changes.
The integer value of this attribute ranges from 0 (OFF) to 1 (ON).
When read, this file returns the actual state of the key.
When written, the key is activated/deactivated immediately.
Users: http://roccat.sourceforge.net
Documentation/ABI/testing/sysfs-driver-hid-roccat-kone
浏览文件 @ 6288cf1e
......@@ -16,12 +16,14 @@ Description: It is possible to switch the dpi setting of the mouse with the
6 3200
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>/kone/roccatkone<minor>/actual_profile
Date: March 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read, this file returns the number of the actual profile.
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>/kone/roccatkone<minor>/firmware_version
Date: March 2010
......@@ -32,12 +34,13 @@ Description: When read, this file returns the raw integer version number of the
number the decimal point has to be shifted 2 positions to the
left. E.g. a returned value of 138 means 1.38
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>/kone/roccatkone<minor>/profile[1-5]
Date: March 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile holds informations like button
press of a button. A profile holds information like button
mappings, sensitivity, the colors of the 5 leds and light
effects.
When read, these files return the respective profile. The
......@@ -47,6 +50,7 @@ Description: The mouse can store 5 profiles which can be switched by the
The mouse will reject invalid data, whereas the profile number
stored in the profile doesn't need to fit the number of the
store.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/settings
Date: March 2010
......@@ -57,6 +61,7 @@ Description: When read, this file returns the settings stored in the mouse.
When written, this file lets write settings back to the mouse.
The data has to be 36 bytes long. The mouse will reject invalid
data.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/startup_profile
Date: March 2010
......@@ -66,6 +71,7 @@ Description: The integer value of this attribute ranges from 1 to 5.
that's active when the mouse is powered on.
When written, this file sets the number of the startup profile
and the mouse 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>/kone/roccatkone<minor>/tcu
Date: March 2010
......@@ -77,6 +83,7 @@ Description: The mouse has a "Tracking Control Unit" which lets the user
Writing 0 in this file will switch the TCU off.
Writing 1 in this file will start the calibration which takes
around 6 seconds to complete and activates the TCU.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/weight
Date: March 2010
......@@ -96,3 +103,4 @@ Description: The mouse can be equipped with one of four supplied weights
4 20g
This file is readonly.
Users: http://roccat.sourceforge.net
Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus
浏览文件 @ 6288cf1e
......@@ -4,6 +4,7 @@ Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read, this file returns the number of the actual profile in
range 0-4.
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>/koneplus/roccatkoneplus<minor>/firmware_version
Date: October 2010
......@@ -14,6 +15,7 @@ Description: When read, this file returns the raw integer version number of the
number the decimal point has to be shifted 2 positions to the
left. E.g. a returned value of 121 means 1.21
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>/koneplus/roccatkoneplus<minor>/macro
Date: October 2010
......@@ -24,36 +26,39 @@ Description: The mouse can store a macro with max 500 key/button strokes
button for a specific profile. Button and profile numbers are
included in written data. The data has to be 2082 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>/koneplus/roccatkoneplus<minor>/profile_buttons
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_buttons holds informations about button layout.
profile_buttons holds information about button layout.
When written, this file lets one write the respective profile
buttons back to the mouse. The data has to be 77 bytes long.
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
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>/koneplus/roccatkoneplus<minor>/profile[1-5]_buttons
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_buttons holds informations about button layout.
profile_buttons holds information about button layout.
When read, these files return the respective profile buttons.
The returned data is 77 bytes in size.
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>/koneplus/roccatkoneplus<minor>/profile_settings
Date: October 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_settings holds informations like resolution, sensitivity
profile_settings holds information like resolution, sensitivity
and light effects.
When written, this file lets one write the respective profile
settings back to the mouse. The data has to be 43 bytes long.
......@@ -61,17 +66,19 @@ Description: The mouse can store 5 profiles which can be switched by the
Which profile to write is determined by the profile number
contained in the data.
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>/koneplus/roccatkoneplus<minor>/profile[1-5]_settings
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_settings holds informations like resolution, sensitivity
profile_settings holds information like resolution, sensitivity
and light effects.
When read, these files return the respective profile settings.
The returned data is 43 bytes in size.
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>/koneplus/roccatkoneplus<minor>/sensor
Date: October 2010
......@@ -80,6 +87,7 @@ Description: The mouse has a tracking- and a distance-control-unit. These
can be activated/deactivated and the lift-off distance can be
set. The data has to be 6 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>/koneplus/roccatkoneplus<minor>/startup_profile
Date: October 2010
......@@ -89,6 +97,7 @@ Description: The integer value of this attribute ranges from 0-4.
that's active when the mouse is powered on.
When written, this file sets the number of the startup profile
and the mouse 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>/koneplus/roccatkoneplus<minor>/tcu
Date: October 2010
......@@ -97,6 +106,7 @@ Description: When written a calibration process for the tracking control unit
can be initiated/cancelled.
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>/koneplus/roccatkoneplus<minor>/tcu_image
Date: October 2010
......@@ -106,3 +116,4 @@ Description: When read the mouse returns a 30x30 pixel image of the
calibration process initiated with tcu.
The returned data is 1028 bytes in size.
This file is readonly.
Users: http://roccat.sourceforge.net
Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus 0 → 100644
浏览文件 @ 6288cf1e
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_cpi
Date: January 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The integer value of this attribute ranges from 1-4.
When read, this attribute returns the number of the active
cpi level.
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>/kovaplus/roccatkovaplus<minor>/actual_profile
Date: January 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 active
profile.
When written, the mouse activates this profile immediately.
The profile that's active when powered down is the same that's
active when the mouse is powered on.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_sensitivity_x
Date: January 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The integer value of this attribute ranges from 1-10.
When read, this attribute returns the number of the actual
sensitivity in x direction.
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>/kovaplus/roccatkovaplus<minor>/actual_sensitivity_y
Date: January 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The integer value of this attribute ranges from 1-10.
When read, this attribute returns the number of the actual
sensitivity in y direction.
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>/kovaplus/roccatkovaplus<minor>/firmware_version
Date: January 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read, this file returns the raw integer version number of the
firmware reported by the mouse. Using the integer value eases
further usage in other programs. To receive the real version
number the decimal point has to be shifted 2 positions to the
left. E.g. a returned value of 121 means 1.21
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>/kovaplus/roccatkovaplus<minor>/profile_buttons
Date: January 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_buttons holds information about button layout.
When written, this file lets one write the respective profile
buttons back to the mouse. The data has to be 23 bytes long.
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
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>/kovaplus/roccatkovaplus<minor>/profile[1-5]_buttons
Date: January 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_buttons holds information about button layout.
When read, these files return the respective profile buttons.
The returned data is 23 bytes in size.
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>/kovaplus/roccatkovaplus<minor>/profile_settings
Date: January 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_settings holds information like resolution, sensitivity
and light effects.
When written, this file lets one write the respective profile
settings back to the mouse. The data has to be 16 bytes long.
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
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>/kovaplus/roccatkovaplus<minor>/profile[1-5]_settings
Date: January 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_settings holds information like resolution, sensitivity
and light effects.
When read, these files return the respective profile settings.
The returned data is 16 bytes in size.
This file is readonly.
Users: http://roccat.sourceforge.net
Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra
浏览文件 @ 6288cf1e
......@@ -13,6 +13,7 @@ Description: It is possible to switch the cpi setting of the mouse with the
4 1600
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>/pyra/roccatpyra<minor>/actual_profile
Date: August 2010
......@@ -20,6 +21,7 @@ Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read, this file returns the number of the actual profile in
range 0-4.
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>/pyra/roccatpyra<minor>/firmware_version
Date: August 2010
......@@ -30,13 +32,14 @@ Description: When read, this file returns the raw integer version number of the
number the decimal point has to be shifted 2 positions to the
left. E.g. a returned value of 138 means 1.38
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>/pyra/roccatpyra<minor>/profile_settings
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_settings holds informations like resolution, sensitivity
profile_settings holds information like resolution, sensitivity
and light effects.
When written, this file lets one write the respective profile
settings back to the mouse. The data has to be 13 bytes long.
......@@ -44,40 +47,44 @@ Description: The mouse can store 5 profiles which can be switched by the
Which profile to write is determined by the profile number
contained in the data.
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>/pyra/roccatpyra<minor>/profile[1-5]_settings
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_settings holds informations like resolution, sensitivity
profile_settings holds information like resolution, sensitivity
and light effects.
When read, these files return the respective profile settings.
The returned data is 13 bytes in size.
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>/pyra/roccatpyra<minor>/profile_buttons
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_buttons holds informations about button layout.
profile_buttons holds information about button layout.
When written, this file lets one write the respective profile
buttons back to the mouse. The data has to be 19 bytes long.
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
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>/pyra/roccatpyra<minor>/profile[1-5]_buttons
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_buttons holds informations about button layout.
profile_buttons holds information about button layout.
When read, these files return the respective profile buttons.
The returned data is 19 bytes in size.
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>/pyra/roccatpyra<minor>/startup_profile
Date: August 2010
......@@ -86,6 +93,7 @@ Description: The integer value of this attribute ranges from 0-4.
When read, this attribute returns the number of the profile
that's active when the mouse is powered on.
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>/pyra/roccatpyra<minor>/settings
Date: August 2010
......@@ -96,3 +104,4 @@ Description: When read, this file returns the settings stored in the mouse.
When written, this file lets write settings back to the mouse.
The data has to be 3 bytes long. The mouse will reject invalid
data.
Users: http://roccat.sourceforge.net
Documentation/ABI/testing/sysfs-driver-samsung-laptop 0 → 100644
浏览文件 @ 6288cf1e
What: /sys/devices/platform/samsung/performance_level
Date: January 1, 2010
KernelVersion: 2.6.33
Contact: Greg Kroah-Hartman <gregkh@suse.de>
Description: Some Samsung laptops have different "performance levels"
that are can be modified by a function key, and by this
sysfs file. These values don't always make a whole lot
of sense, but some users like to modify them to keep
their fans quiet at all costs. Reading from this file
will show the current performance level. Writing to the
file can change this value.
Valid options:
"silent"
"normal"
"overclock"
Note that not all laptops support all of these options.
Specifically, not all support the "overclock" option,
and it's still unknown if this value even changes
anything, other than making the user feel a bit better.
Documentation/ABI/testing/sysfs-firmware-dmi 0 → 100644
浏览文件 @ 6288cf1e
What: /sys/firmware/dmi/
Date: February 2011
Contact: Mike Waychison <mikew@google.com>
Description:
Many machines' firmware (x86 and ia64) export DMI /
SMBIOS tables to the operating system. Getting at this
information is often valuable to userland, especially in
cases where there are OEM extensions used.
The kernel itself does not rely on the majority of the
information in these tables being correct. It equally
cannot ensure that the data as exported to userland is
without error either.
DMI is structured as a large table of entries, where
each entry has a common header indicating the type and
length of the entry, as well as 'handle' that is
supposed to be unique amongst all entries.
Some entries are required by the specification, but many
others are optional. In general though, users should
never expect to find a specific entry type on their
system unless they know for certain what their firmware
is doing. Machine to machine will vary.
Multiple entries of the same type are allowed. In order
to handle these duplicate entry types, each entry is
assigned by the operating system an 'instance', which is
derived from an entry type's ordinal position. That is
to say, if there are 'N' multiple entries with the same type
'T' in the DMI tables (adjacent or spread apart, it
doesn't matter), they will be represented in sysfs as
entries "T-0" through "T-(N-1)":
Example entry directories:
/sys/firmware/dmi/entries/17-0
/sys/firmware/dmi/entries/17-1
/sys/firmware/dmi/entries/17-2
/sys/firmware/dmi/entries/17-3
...
Instance numbers are used in lieu of the firmware
assigned entry handles as the kernel itself makes no
guarantees that handles as exported are unique, and
there are likely firmware images that get this wrong in
the wild.
Each DMI entry in sysfs has the common header values
exported as attributes:
handle : The 16bit 'handle' that is assigned to this
entry by the firmware. This handle may be
referred to by other entries.
length : The length of the entry, as presented in the
entry itself. Note that this is _not the
total count of bytes associated with the
entry_. This value represents the length of
the "formatted" portion of the entry. This
"formatted" region is sometimes followed by
the "unformatted" region composed of nul
terminated strings, with termination signalled
by a two nul characters in series.
raw : The raw bytes of the entry. This includes the
"formatted" portion of the entry, the
"unformatted" strings portion of the entry,
and the two terminating nul characters.
type : The type of the entry. This value is the same
as found in the directory name. It indicates
how the rest of the entry should be
interpreted.
instance: The instance ordinal of the entry for the
given type. This value is the same as found
in the parent directory name.
position: The position of the entry within the entirety
of the entirety.
=== Entry Specialization ===
Some entry types may have other information available in
sysfs.
--- Type 15 - System Event Log ---
This entry allows the firmware to export a log of
events the system has taken. This information is
typically backed by nvram, but the implementation
details are abstracted by this table. This entries data
is exported in the directory:
/sys/firmware/dmi/entries/15-0/system_event_log
and has the following attributes (documented in the
SMBIOS / DMI specification under "System Event Log (Type 15)":
area_length
header_start_offset
data_start_offset
access_method
status
change_token
access_method_address
header_format
per_log_type_descriptor_length
type_descriptors_supported_count
As well, the kernel exports the binary attribute:
raw_event_log : The raw binary bits of the event log
as described by the DMI entry.
Documentation/ABI/testing/sysfs-fs-ext4
浏览文件 @ 6288cf1e
......@@ -48,7 +48,7 @@ Description:
will have its blocks allocated out of its own unique
preallocation pool.
What: /sys/fs/ext4/<disk>/inode_readahead
What: /sys/fs/ext4/<disk>/inode_readahead_blks
Date: March 2008
Contact: "Theodore Ts'o" <tytso@mit.edu>
Description:
......@@ -85,7 +85,14 @@ Date: June 2008
Contact: "Theodore Ts'o" <tytso@mit.edu>
Description:
Tuning parameter which (if non-zero) controls the goal
inode used by the inode allocator in p0reference to
all other allocation hueristics. This is intended for
inode used by the inode allocator in preference to
all other allocation heuristics. This is intended for
debugging use only, and should be 0 on production
systems.
What: /sys/fs/ext4/<disk>/max_writeback_mb_bump
Date: September 2009
Contact: "Theodore Ts'o" <tytso@mit.edu>
Description:
The maximum number of megabytes the writeback code will
try to write out before move on to another inode.
Documentation/ABI/testing/sysfs-platform-asus-laptop
浏览文件 @ 6288cf1e
......@@ -27,7 +27,7 @@ KernelVersion: 2.6.20
Contact: "Corentin Chary" <corentincj@iksaif.net>
Description:
Some models like the W1N have a LED display that can be
used to display several informations.
used to display several items of information.
To control the LED display, use the following :
echo 0x0T000DDD > /sys/devices/platform/asus_laptop/
where T control the 3 letters display, and DDD the 3 digits display.
......
Documentation/ABI/testing/sysfs-platform-asus-wmi 0 → 100644
浏览文件 @ 6288cf1e
What: /sys/devices/platform/<platform>/cpufv
Date: Oct 2010
KernelVersion: 2.6.37
Contact: "Corentin Chary" <corentincj@iksaif.net>
Description:
Change CPU clock configuration (write-only).
There are three available clock configuration:
* 0 -> Super Performance Mode
* 1 -> High Performance Mode
* 2 -> Power Saving Mode
What: /sys/devices/platform/<platform>/camera
Date: Jan 2010
KernelVersion: 2.6.39
Contact: "Corentin Chary" <corentincj@iksaif.net>
Description:
Control the camera. 1 means on, 0 means off.
What: /sys/devices/platform/<platform>/cardr
Date: Jan 2010
KernelVersion: 2.6.39
Contact: "Corentin Chary" <corentincj@iksaif.net>
Description:
Control the card reader. 1 means on, 0 means off.
What: /sys/devices/platform/<platform>/touchpad
Date: Jan 2010
KernelVersion: 2.6.39
Contact: "Corentin Chary" <corentincj@iksaif.net>
Description:
Control the card touchpad. 1 means on, 0 means off.
Documentation/ABI/testing/sysfs-platform-eeepc-wmi 已删除 100644 → 0
浏览文件 @ 0a63e230
What: /sys/devices/platform/eeepc-wmi/cpufv
Date: Oct 2010
KernelVersion: 2.6.37
Contact: "Corentin Chary" <corentincj@iksaif.net>
Description:
Change CPU clock configuration (write-only).
There are three available clock configuration:
* 0 -> Super Performance Mode
* 1 -> High Performance Mode
* 2 -> Power Saving Mode
Documentation/ABI/testing/sysfs-platform-kim 0 → 100644
浏览文件 @ 6288cf1e
What: /sys/devices/platform/kim/dev_name
Date: January 2010
KernelVersion: 2.6.38
Contact: "Pavan Savoy" <pavan_savoy@ti.com>
Description:
Name of the UART device at which the WL128x chip
is connected. example: "/dev/ttyS0".
The device name flows down to architecture specific board
initialization file from the SFI/ATAGS bootloader
firmware. The name exposed is read from the user-space
dameon and opens the device when install is requested.
What: /sys/devices/platform/kim/baud_rate
Date: January 2010
KernelVersion: 2.6.38
Contact: "Pavan Savoy" <pavan_savoy@ti.com>
Description:
The maximum reliable baud-rate the host can support.
Different platforms tend to have different high-speed
UART configurations, so the baud-rate needs to be set
locally and also sent across to the WL128x via a HCI-VS
command. The entry is read and made use by the user-space
daemon when the ldisc install is requested.
What: /sys/devices/platform/kim/flow_cntrl
Date: January 2010
KernelVersion: 2.6.38
Contact: "Pavan Savoy" <pavan_savoy@ti.com>
Description:
The WL128x makes use of flow control mechanism, and this
entry most often should be 1, the host's UART is required
to have the capability of flow-control, or else this
entry can be made use of for exceptions.
What: /sys/devices/platform/kim/install
Date: January 2010
KernelVersion: 2.6.38
Contact: "Pavan Savoy" <pavan_savoy@ti.com>
Description:
When one of the protocols Bluetooth, FM or GPS wants to make
use of the shared UART transport, it registers to the shared
transport driver, which will signal the user-space for opening,
configuring baud and install line discipline via this sysfs
entry. This entry would be polled upon by the user-space
daemon managing the UART, and is notified about the change
by the sysfs_notify. The value would be '1' when UART needs
to be opened/ldisc installed, and would be '0' when UART
is no more required and needs to be closed.
Documentation/Changes
浏览文件 @ 6288cf1e
......@@ -35,7 +35,7 @@ o util-linux 2.10o # fdformat --version
o module-init-tools 0.9.10 # depmod -V
o e2fsprogs 1.41.4 # e2fsck -V
o jfsutils 1.1.3 # fsck.jfs -V
o reiserfsprogs 3.6.3 # reiserfsck -V 2>&1|grep reiserfsprogs
o reiserfsprogs 3.6.3 # reiserfsck -V
o xfsprogs 2.6.0 # xfs_db -V
o squashfs-tools 4.0 # mksquashfs -version
o btrfs-progs 0.18 # btrfsck
......@@ -46,9 +46,9 @@ o isdn4k-utils 3.1pre1 # isdnctrl 2>&1|grep version
o nfs-utils 1.0.5 # showmount --version
o procps 3.2.0 # ps --version
o oprofile 0.9 # oprofiled --version
o udev 081 # udevinfo -V
o grub 0.93 # grub --version
o mcelog 0.6
o udev 081 # udevd --version
o grub 0.93 # grub --version || grub-install --version
o mcelog 0.6 # mcelog --version
o iptables 1.4.2 # iptables -V
......
Documentation/CodingStyle
浏览文件 @ 6288cf1e
......@@ -168,6 +168,13 @@ Do not unnecessarily use braces where a single statement will do.
if (condition)
action();
and
if (condition)
do_this();
else
do_that();
This does not apply if one branch of a conditional statement is a single
statement. Use braces in both branches.
......@@ -659,7 +666,7 @@ There are a number of driver model diagnostic macros in <linux/device.h>
which you should use to make sure messages are matched to the right device
and driver, and are tagged with the right level: dev_err(), dev_warn(),
dev_info(), and so forth. For messages that aren't associated with a
particular device, <linux/kernel.h> defines pr_debug() and pr_info().
particular device, <linux/printk.h> defines pr_debug() and pr_info().
Coming up with good debugging messages can be quite a challenge; and once
you have them, they can be a huge help for remote troubleshooting. Such
......@@ -819,6 +826,3 @@ language C, URL: http://www.open-std.org/JTC1/SC22/WG14/
Kernel CodingStyle, by greg@kroah.com at OLS 2002:
http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/
--
Last updated on 2007-July-13.
Documentation/DocBook/Makefile
浏览文件 @ 6288cf1e
......@@ -53,7 +53,9 @@ MAN := $(patsubst %.xml, %.9, $(BOOKS))
mandocs: $(MAN)
build_images = mkdir -p $(objtree)/Documentation/DocBook/media/ && \
cp $(srctree)/Documentation/DocBook/dvb/*.png $(srctree)/Documentation/DocBook/v4l/*.gif $(objtree)/Documentation/DocBook/media/
cp $(srctree)/Documentation/DocBook/dvb/*.png \
$(srctree)/Documentation/DocBook/v4l/*.gif \
$(objtree)/Documentation/DocBook/media/
xmldoclinks:
ifneq ($(objtree),$(srctree))
......
Documentation/DocBook/dvb/dvbproperty.xml
浏览文件 @ 6288cf1e
......@@ -40,7 +40,7 @@
<para>Central frequency of the channel.</para>
<para>For ISDB-T the channels are usally transmitted with an offset of 143kHz. E.g. a
<para>For ISDB-T the channels are usually transmitted with an offset of 143kHz. E.g. a
valid frequncy could be 474143 kHz. The stepping is bound to the bandwidth of
the channel which is 6MHz.</para>
......
Documentation/DocBook/dvb/frontend.xml
浏览文件 @ 6288cf1e
......@@ -139,7 +139,7 @@ consistently to the DiSEqC commands as described in the DiSEqC spec.</para>
<section id="frontend_sec_tone">
<title>SEC continuous tone</title>
<para>The continous 22KHz tone is usually used with non-DiSEqC capable LNBs to switch the
<para>The continuous 22KHz tone is usually used with non-DiSEqC capable LNBs to switch the
high/low band of a dual-band LNB. When using DiSEqC epuipment this voltage has to
be switched consistently to the DiSEqC commands as described in the DiSEqC
spec.</para>
......
Documentation/DocBook/kernel-locking.tmpl
浏览文件 @ 6288cf1e
......@@ -1763,7 +1763,7 @@ as it would be on UP.
There is a furthur optimization possible here: remember our original
cache code, where there were no reference counts and the caller simply
held the lock whenever using the object? This is still possible: if
you hold the lock, noone can delete the object, so you don't need to
you hold the lock, no one can delete the object, so you don't need to
get and put the reference count.
</para>
......
Documentation/DocBook/libata.tmpl
浏览文件 @ 6288cf1e
......@@ -1032,7 +1032,7 @@ and other resources, etc.
<listitem>
<para>
This is indicated by ICRC bit in the ERROR register and
means that corruption occurred during data transfer. Upto
means that corruption occurred during data transfer. Up to
ATA/ATAPI-7, the standard specifies that this bit is only
applicable to UDMA transfers but ATA/ATAPI-8 draft revision
1f says that the bit may be applicable to multiword DMA and
......@@ -1045,10 +1045,10 @@ and other resources, etc.
<term>ABRT error during data transfer or on completion</term>
<listitem>
<para>
Upto ATA/ATAPI-7, the standard specifies that ABRT could be
Up to ATA/ATAPI-7, the standard specifies that ABRT could be
set on ICRC errors and on cases where a device is not able
to complete a command. Combined with the fact that MWDMA
and PIO transfer errors aren't allowed to use ICRC bit upto
and PIO transfer errors aren't allowed to use ICRC bit up to
ATA/ATAPI-7, it seems to imply that ABRT bit alone could
indicate tranfer errors.
</para>
......@@ -1122,7 +1122,7 @@ and other resources, etc.
<para>
Depending on commands, not all STATUS/ERROR bits are
applicable. These non-applicable bits are marked with
&quot;na&quot; in the output descriptions but upto ATA/ATAPI-7
&quot;na&quot; in the output descriptions but up to ATA/ATAPI-7
no definition of &quot;na&quot; can be found. However,
ATA/ATAPI-8 draft revision 1f describes &quot;N/A&quot; as
follows.
......@@ -1507,7 +1507,7 @@ and other resources, etc.
<listitem>
<para>
CHS set up with INITIALIZE DEVICE PARAMETERS (seldomly used)
CHS set up with INITIALIZE DEVICE PARAMETERS (seldom used)
</para>
</listitem>
......
Documentation/DocBook/media-entities.tmpl
浏览文件 @ 6288cf1e
......@@ -11,6 +11,10 @@
<!ENTITY func-select "<link linkend='func-select'><function>select()</function></link>">
<!ENTITY func-write "<link linkend='func-write'><function>write()</function></link>">
<!ENTITY media-func-close "<link linkend='media-func-close'><function>close()</function></link>">
<!ENTITY media-func-ioctl "<link linkend='media-func-ioctl'><function>ioctl()</function></link>">
<!ENTITY media-func-open "<link linkend='media-func-open'><function>open()</function></link>">
<!-- Ioctls -->
<!ENTITY VIDIOC-CROPCAP "<link linkend='vidioc-cropcap'><constant>VIDIOC_CROPCAP</constant></link>">
<!ENTITY VIDIOC-DBG-G-CHIP-IDENT "<link linkend='vidioc-dbg-g-chip-ident'><constant>VIDIOC_DBG_G_CHIP_IDENT</constant></link>">
......@@ -82,11 +86,24 @@
<!ENTITY VIDIOC-S-PRIORITY "<link linkend='vidioc-g-priority'><constant>VIDIOC_S_PRIORITY</constant></link>">
<!ENTITY VIDIOC-S-STD "<link linkend='vidioc-g-std'><constant>VIDIOC_S_STD</constant></link>">
<!ENTITY VIDIOC-S-TUNER "<link linkend='vidioc-g-tuner'><constant>VIDIOC_S_TUNER</constant></link>">
<!ENTITY VIDIOC-SUBDEV-ENUM-FRAME-SIZE "<link linkend='vidioc-subdev-enum-frame-size'><constant>VIDIOC_SUBDEV_ENUM_FRAME_SIZE</constant></link>">
<!ENTITY VIDIOC-SUBDEV-ENUM-MBUS-CODE "<link linkend='vidioc-subdev-enum-mbus-code'><constant>VIDIOC_SUBDEV_ENUM_MBUS_CODE</constant></link>">
<!ENTITY VIDIOC-SUBDEV-G-CROP "<link linkend='vidioc-subdev-g-crop'><constant>VIDIOC_SUBDEV_G_CROP</constant></link>">
<!ENTITY VIDIOC-SUBDEV-G-FMT "<link linkend='vidioc-subdev-g-fmt'><constant>VIDIOC_SUBDEV_G_FMT</constant></link>">
<!ENTITY VIDIOC-SUBDEV-G-FRAME-INTERVAL "<link linkend='vidioc-subdev-g-frame-interval'><constant>VIDIOC_SUBDEV_G_FRAME_INTERVAL</constant></link>">
<!ENTITY VIDIOC-SUBDEV-S-CROP "<link linkend='vidioc-subdev-g-crop'><constant>VIDIOC_SUBDEV_S_CROP</constant></link>">
<!ENTITY VIDIOC-SUBDEV-S-FMT "<link linkend='vidioc-subdev-g-fmt'><constant>VIDIOC_SUBDEV_S_FMT</constant></link>">
<!ENTITY VIDIOC-SUBDEV-S-FRAME-INTERVAL "<link linkend='vidioc-subdev-g-frame-interval'><constant>VIDIOC_SUBDEV_S_FRAME_INTERVAL</constant></link>">
<!ENTITY VIDIOC-TRY-ENCODER-CMD "<link linkend='vidioc-encoder-cmd'><constant>VIDIOC_TRY_ENCODER_CMD</constant></link>">
<!ENTITY VIDIOC-TRY-EXT-CTRLS "<link linkend='vidioc-g-ext-ctrls'><constant>VIDIOC_TRY_EXT_CTRLS</constant></link>">
<!ENTITY VIDIOC-TRY-FMT "<link linkend='vidioc-g-fmt'><constant>VIDIOC_TRY_FMT</constant></link>">
<!ENTITY VIDIOC-UNSUBSCRIBE-EVENT "<link linkend='vidioc-subscribe-event'><constant>VIDIOC_UNSUBSCRIBE_EVENT</constant></link>">
<!ENTITY MEDIA-IOC-DEVICE-INFO "<link linkend='media-ioc-device-info'><constant>MEDIA_IOC_DEVICE_INFO</constant></link>">
<!ENTITY MEDIA-IOC-ENUM-ENTITIES "<link linkend='media-ioc-enum-entities'><constant>MEDIA_IOC_ENUM_ENTITIES</constant></link>">
<!ENTITY MEDIA-IOC-ENUM-LINKS "<link linkend='media-ioc-enum-links'><constant>MEDIA_IOC_ENUM_LINKS</constant></link>">
<!ENTITY MEDIA-IOC-SETUP-LINK "<link linkend='media-ioc-setup-link'><constant>MEDIA_IOC_SETUP_LINK</constant></link>">
<!-- Types -->
<!ENTITY v4l2-std-id "<link linkend='v4l2-std-id'>v4l2_std_id</link>">
......@@ -98,6 +115,7 @@
<!ENTITY v4l2-field "enum&nbsp;<link linkend='v4l2-field'>v4l2_field</link>">
<!ENTITY v4l2-frmivaltypes "enum&nbsp;<link linkend='v4l2-frmivaltypes'>v4l2_frmivaltypes</link>">
<!ENTITY v4l2-frmsizetypes "enum&nbsp;<link linkend='v4l2-frmsizetypes'>v4l2_frmsizetypes</link>">
<!ENTITY v4l2-mbus-pixelcode "enum&nbsp;<link linkend='v4l2-mbus-pixelcode'>v4l2_mbus_pixelcode</link>">
<!ENTITY v4l2-memory "enum&nbsp;<link linkend='v4l2-memory'>v4l2_memory</link>">
<!ENTITY v4l2-mpeg-audio-ac3-bitrate "enum&nbsp;<link linkend='v4l2-mpeg-audio-ac3-bitrate'>v4l2_mpeg_audio_ac3_bitrate</link>">
<!ENTITY v4l2-mpeg-audio-crc "enum&nbsp;<link linkend='v4l2-mpeg-audio-crc'>v4l2_mpeg_audio_crc</link>">
......@@ -121,6 +139,7 @@
<!ENTITY v4l2-mpeg-video-encoding "enum&nbsp;<link linkend='v4l2-mpeg-video-encoding'>v4l2_mpeg_video_encoding</link>">
<!ENTITY v4l2-power-line-frequency "enum&nbsp;<link linkend='v4l2-power-line-frequency'>v4l2_power_line_frequency</link>">
<!ENTITY v4l2-priority "enum&nbsp;<link linkend='v4l2-priority'>v4l2_priority</link>">
<!ENTITY v4l2-subdev-format-whence "enum&nbsp;<link linkend='v4l2-subdev-format-whence'>v4l2_subdev_format_whence</link>">
<!ENTITY v4l2-tuner-type "enum&nbsp;<link linkend='v4l2-tuner-type'>v4l2_tuner_type</link>">
<!ENTITY v4l2-preemphasis "enum&nbsp;<link linkend='v4l2-preemphasis'>v4l2_preemphasis</link>">
......@@ -129,6 +148,7 @@
<!ENTITY v4l2-audioout "struct&nbsp;<link linkend='v4l2-audioout'>v4l2_audioout</link>">
<!ENTITY v4l2-bt-timings "struct&nbsp;<link linkend='v4l2-bt-timings'>v4l2_bt_timings</link>">
<!ENTITY v4l2-buffer "struct&nbsp;<link linkend='v4l2-buffer'>v4l2_buffer</link>">
<!ENTITY v4l2-plane "struct&nbsp;<link linkend='v4l2-plane'>v4l2_plane</link>">
<!ENTITY v4l2-capability "struct&nbsp;<link linkend='v4l2-capability'>v4l2_capability</link>">
<!ENTITY v4l2-captureparm "struct&nbsp;<link linkend='v4l2-captureparm'>v4l2_captureparm</link>">
<!ENTITY v4l2-clip "struct&nbsp;<link linkend='v4l2-clip'>v4l2_clip</link>">
......@@ -162,11 +182,14 @@
<!ENTITY v4l2-hw-freq-seek "struct&nbsp;<link linkend='v4l2-hw-freq-seek'>v4l2_hw_freq_seek</link>">
<!ENTITY v4l2-input "struct&nbsp;<link linkend='v4l2-input'>v4l2_input</link>">
<!ENTITY v4l2-jpegcompression "struct&nbsp;<link linkend='v4l2-jpegcompression'>v4l2_jpegcompression</link>">
<!ENTITY v4l2-mbus-framefmt "struct&nbsp;<link linkend='v4l2-mbus-framefmt'>v4l2_mbus_framefmt</link>">
<!ENTITY v4l2-modulator "struct&nbsp;<link linkend='v4l2-modulator'>v4l2_modulator</link>">
<!ENTITY v4l2-mpeg-vbi-fmt-ivtv "struct&nbsp;<link linkend='v4l2-mpeg-vbi-fmt-ivtv'>v4l2_mpeg_vbi_fmt_ivtv</link>">
<!ENTITY v4l2-output "struct&nbsp;<link linkend='v4l2-output'>v4l2_output</link>">
<!ENTITY v4l2-outputparm "struct&nbsp;<link linkend='v4l2-outputparm'>v4l2_outputparm</link>">
<!ENTITY v4l2-pix-format "struct&nbsp;<link linkend='v4l2-pix-format'>v4l2_pix_format</link>">
<!ENTITY v4l2-pix-format-mplane "struct&nbsp;<link linkend='v4l2-pix-format-mplane'>v4l2_pix_format_mplane</link>">
<!ENTITY v4l2-plane-pix-format "struct&nbsp;<link linkend='v4l2-plane-pix-format'>v4l2_plane_pix_format</link>">
<!ENTITY v4l2-queryctrl "struct&nbsp;<link linkend='v4l2-queryctrl'>v4l2_queryctrl</link>">
<!ENTITY v4l2-querymenu "struct&nbsp;<link linkend='v4l2-querymenu'>v4l2_querymenu</link>">
<!ENTITY v4l2-rect "struct&nbsp;<link linkend='v4l2-rect'>v4l2_rect</link>">
......@@ -174,6 +197,12 @@
<!ENTITY v4l2-sliced-vbi-cap "struct&nbsp;<link linkend='v4l2-sliced-vbi-cap'>v4l2_sliced_vbi_cap</link>">
<!ENTITY v4l2-sliced-vbi-data "struct&nbsp;<link linkend='v4l2-sliced-vbi-data'>v4l2_sliced_vbi_data</link>">
<!ENTITY v4l2-sliced-vbi-format "struct&nbsp;<link linkend='v4l2-sliced-vbi-format'>v4l2_sliced_vbi_format</link>">
<!ENTITY v4l2-subdev-frame-interval "struct&nbsp;<link linkend='v4l2-subdev-frame-interval'>v4l2_subdev_frame_interval</link>">
<!ENTITY v4l2-subdev-frame-interval-enum "struct&nbsp;<link linkend='v4l2-subdev-frame-interval-enum'>v4l2_subdev_frame_interval_enum</link>">
<!ENTITY v4l2-subdev-frame-size-enum "struct&nbsp;<link linkend='v4l2-subdev-frame-size-enum'>v4l2_subdev_frame_size_enum</link>">
<!ENTITY v4l2-subdev-crop "struct&nbsp;<link linkend='v4l2-subdev-crop'>v4l2_subdev_crop</link>">
<!ENTITY v4l2-subdev-format "struct&nbsp;<link linkend='v4l2-subdev-format'>v4l2_subdev_format</link>">
<!ENTITY v4l2-subdev-mbus-code-enum "struct&nbsp;<link linkend='v4l2-subdev-mbus-code-enum'>v4l2_subdev_mbus_code_enum</link>">
<!ENTITY v4l2-standard "struct&nbsp;<link linkend='v4l2-standard'>v4l2_standard</link>">
<!ENTITY v4l2-streamparm "struct&nbsp;<link linkend='v4l2-streamparm'>v4l2_streamparm</link>">
<!ENTITY v4l2-timecode "struct&nbsp;<link linkend='v4l2-timecode'>v4l2_timecode</link>">
......@@ -181,6 +210,12 @@
<!ENTITY v4l2-vbi-format "struct&nbsp;<link linkend='v4l2-vbi-format'>v4l2_vbi_format</link>">
<!ENTITY v4l2-window "struct&nbsp;<link linkend='v4l2-window'>v4l2_window</link>">
<!ENTITY media-device-info "struct&nbsp;<link linkend='media-device-info'>media_device_info</link>">
<!ENTITY media-entity-desc "struct&nbsp;<link linkend='media-entity-desc'>media_entity_desc</link>">
<!ENTITY media-links-enum "struct&nbsp;<link linkend='media-links-enum'>media_links_enum</link>">
<!ENTITY media-pad-desc "struct&nbsp;<link linkend='media-pad-desc'>media_pad_desc</link>">
<!ENTITY media-link-desc "struct&nbsp;<link linkend='media-link-desc'>media_link_desc</link>">
<!-- Error Codes -->
<!ENTITY EACCES "<errorcode>EACCES</errorcode> error code">
<!ENTITY EAGAIN "<errorcode>EAGAIN</errorcode> error code">
......@@ -197,11 +232,13 @@
<!ENTITY ENXIO "<errorcode>ENXIO</errorcode> error code">
<!ENTITY EMFILE "<errorcode>EMFILE</errorcode> error code">
<!ENTITY EPERM "<errorcode>EPERM</errorcode> error code">
<!ENTITY EPIPE "<errorcode>EPIPE</errorcode> error code">
<!ENTITY ERANGE "<errorcode>ERANGE</errorcode> error code">
<!-- Subsections -->
<!ENTITY sub-biblio SYSTEM "v4l/biblio.xml">
<!ENTITY sub-common SYSTEM "v4l/common.xml">
<!ENTITY sub-planar-apis SYSTEM "v4l/planar-apis.xml">
<!ENTITY sub-compat SYSTEM "v4l/compat.xml">
<!ENTITY sub-controls SYSTEM "v4l/controls.xml">
<!ENTITY sub-dev-capture SYSTEM "v4l/dev-capture.xml">
......@@ -215,6 +252,7 @@
<!ENTITY sub-dev-raw-vbi SYSTEM "v4l/dev-raw-vbi.xml">
<!ENTITY sub-dev-rds SYSTEM "v4l/dev-rds.xml">
<!ENTITY sub-dev-sliced-vbi SYSTEM "v4l/dev-sliced-vbi.xml">
<!ENTITY sub-dev-subdev SYSTEM "v4l/dev-subdev.xml">
<!ENTITY sub-dev-teletext SYSTEM "v4l/dev-teletext.xml">
<!ENTITY sub-driver SYSTEM "v4l/driver.xml">
<!ENTITY sub-libv4l SYSTEM "v4l/libv4l.xml">
......@@ -233,6 +271,8 @@
<!ENTITY sub-io SYSTEM "v4l/io.xml">
<!ENTITY sub-grey SYSTEM "v4l/pixfmt-grey.xml">
<!ENTITY sub-nv12 SYSTEM "v4l/pixfmt-nv12.xml">
<!ENTITY sub-nv12m SYSTEM "v4l/pixfmt-nv12m.xml">
<!ENTITY sub-nv12mt SYSTEM "v4l/pixfmt-nv12mt.xml">
<!ENTITY sub-nv16 SYSTEM "v4l/pixfmt-nv16.xml">
<!ENTITY sub-packed-rgb SYSTEM "v4l/pixfmt-packed-rgb.xml">
<!ENTITY sub-packed-yuv SYSTEM "v4l/pixfmt-packed-yuv.xml">
......@@ -247,12 +287,14 @@
<!ENTITY sub-yuv410 SYSTEM "v4l/pixfmt-yuv410.xml">
<!ENTITY sub-yuv411p SYSTEM "v4l/pixfmt-yuv411p.xml">
<!ENTITY sub-yuv420 SYSTEM "v4l/pixfmt-yuv420.xml">
<!ENTITY sub-yuv420m SYSTEM "v4l/pixfmt-yuv420m.xml">
<!ENTITY sub-yuv422p SYSTEM "v4l/pixfmt-yuv422p.xml">
<!ENTITY sub-yuyv SYSTEM "v4l/pixfmt-yuyv.xml">
<!ENTITY sub-yvyu SYSTEM "v4l/pixfmt-yvyu.xml">
<!ENTITY sub-srggb10 SYSTEM "v4l/pixfmt-srggb10.xml">
<!ENTITY sub-srggb8 SYSTEM "v4l/pixfmt-srggb8.xml">
<!ENTITY sub-y10 SYSTEM "v4l/pixfmt-y10.xml">
<!ENTITY sub-y12 SYSTEM "v4l/pixfmt-y12.xml">
<!ENTITY sub-pixfmt SYSTEM "v4l/pixfmt.xml">
<!ENTITY sub-cropcap SYSTEM "v4l/vidioc-cropcap.xml">
<!ENTITY sub-dbg-g-register SYSTEM "v4l/vidioc-dbg-g-register.xml">
......@@ -298,6 +340,13 @@
<!ENTITY sub-reqbufs SYSTEM "v4l/vidioc-reqbufs.xml">
<!ENTITY sub-s-hw-freq-seek SYSTEM "v4l/vidioc-s-hw-freq-seek.xml">
<!ENTITY sub-streamon SYSTEM "v4l/vidioc-streamon.xml">
<!ENTITY sub-subdev-enum-frame-interval SYSTEM "v4l/vidioc-subdev-enum-frame-interval.xml">
<!ENTITY sub-subdev-enum-frame-size SYSTEM "v4l/vidioc-subdev-enum-frame-size.xml">
<!ENTITY sub-subdev-enum-mbus-code SYSTEM "v4l/vidioc-subdev-enum-mbus-code.xml">
<!ENTITY sub-subdev-formats SYSTEM "v4l/subdev-formats.xml">
<!ENTITY sub-subdev-g-crop SYSTEM "v4l/vidioc-subdev-g-crop.xml">
<!ENTITY sub-subdev-g-fmt SYSTEM "v4l/vidioc-subdev-g-fmt.xml">
<!ENTITY sub-subdev-g-frame-interval SYSTEM "v4l/vidioc-subdev-g-frame-interval.xml">
<!ENTITY sub-capture-c SYSTEM "v4l/capture.c.xml">
<!ENTITY sub-keytable-c SYSTEM "v4l/keytable.c.xml">
<!ENTITY sub-v4l2grab-c SYSTEM "v4l/v4l2grab.c.xml">
......@@ -321,6 +370,15 @@
<!ENTITY sub-media-entities SYSTEM "media-entities.tmpl">
<!ENTITY sub-media-indices SYSTEM "media-indices.tmpl">
<!ENTITY sub-media-controller SYSTEM "v4l/media-controller.xml">
<!ENTITY sub-media-open SYSTEM "v4l/media-func-open.xml">
<!ENTITY sub-media-close SYSTEM "v4l/media-func-close.xml">
<!ENTITY sub-media-ioctl SYSTEM "v4l/media-func-ioctl.xml">
<!ENTITY sub-media-ioc-device-info SYSTEM "v4l/media-ioc-device-info.xml">
<!ENTITY sub-media-ioc-enum-entities SYSTEM "v4l/media-ioc-enum-entities.xml">
<!ENTITY sub-media-ioc-enum-links SYSTEM "v4l/media-ioc-enum-links.xml">
<!ENTITY sub-media-ioc-setup-link SYSTEM "v4l/media-ioc-setup-link.xml">
<!-- Function Reference -->
<!ENTITY close SYSTEM "v4l/func-close.xml">
<!ENTITY ioctl SYSTEM "v4l/func-ioctl.xml">
......@@ -333,6 +391,7 @@
<!ENTITY write SYSTEM "v4l/func-write.xml">
<!ENTITY grey SYSTEM "v4l/pixfmt-grey.xml">
<!ENTITY nv12 SYSTEM "v4l/pixfmt-nv12.xml">
<!ENTITY nv12m SYSTEM "v4l/pixfmt-nv12m.xml">
<!ENTITY nv16 SYSTEM "v4l/pixfmt-nv16.xml">
<!ENTITY packed-rgb SYSTEM "v4l/pixfmt-packed-rgb.xml">
<!ENTITY packed-yuv SYSTEM "v4l/pixfmt-packed-yuv.xml">
......@@ -347,6 +406,7 @@
<!ENTITY yuv410 SYSTEM "v4l/pixfmt-yuv410.xml">
<!ENTITY yuv411p SYSTEM "v4l/pixfmt-yuv411p.xml">
<!ENTITY yuv420 SYSTEM "v4l/pixfmt-yuv420.xml">
<!ENTITY yuv420m SYSTEM "v4l/pixfmt-yuv420m.xml">
<!ENTITY yuv422p SYSTEM "v4l/pixfmt-yuv422p.xml">
<!ENTITY yuyv SYSTEM "v4l/pixfmt-yuyv.xml">
<!ENTITY yvyu SYSTEM "v4l/pixfmt-yvyu.xml">
......
Documentation/DocBook/media.tmpl
浏览文件 @ 6288cf1e
......@@ -106,6 +106,9 @@ Foundation. A copy of the license is included in the chapter entitled
&sub-remote_controllers;
</chapter>
</part>
<part id="media_common">
&sub-media-controller;
</part>
&sub-fdl-appendix;
......
Documentation/DocBook/mtdnand.tmpl
浏览文件 @ 6288cf1e
......@@ -485,7 +485,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
Reed-Solomon library.
</para>
<para>
The ECC bytes must be placed immidiately after the data
The ECC bytes must be placed immediately after the data
bytes in order to make the syndrome generator work. This
is contrary to the usual layout used by software ECC. The
separation of data and out of band area is not longer
......@@ -629,7 +629,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
holds the bad block table. Store a pointer to the pattern
in the pattern field. Further the length of the pattern has to be
stored in len and the offset in the spare area must be given
in the offs member of the nand_bbt_descr stucture. For mirrored
in the offs member of the nand_bbt_descr structure. For mirrored
bad block tables different patterns are mandatory.</para></listitem>
<listitem><para>Table creation</para>
<para>Set the option NAND_BBT_CREATE to enable the table creation
......@@ -648,7 +648,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
<listitem><para>Table version control</para>
<para>Set the option NAND_BBT_VERSION to enable the table version control.
It's highly recommended to enable this for mirrored tables with write
support. It makes sure that the risk of loosing the bad block
support. It makes sure that the risk of losing the bad block
table information is reduced to the loss of the information about the
one worn out block which should be marked bad. The version is stored in
4 consecutive bytes in the spare area of the device. The position of
......@@ -1060,19 +1060,19 @@ data in this page</entry>
<row>
<entry>0x3D</entry>
<entry>ECC byte 21</entry>
<entry>Error correction code byte 0 of the eigth 256 Bytes of data
<entry>Error correction code byte 0 of the eighth 256 Bytes of data
in this page</entry>
</row>
<row>
<entry>0x3E</entry>
<entry>ECC byte 22</entry>
<entry>Error correction code byte 1 of the eigth 256 Bytes of data
<entry>Error correction code byte 1 of the eighth 256 Bytes of data
in this page</entry>
</row>
<row>
<entry>0x3F</entry>
<entry>ECC byte 23</entry>
<entry>Error correction code byte 2 of the eigth 256 Bytes of data
<entry>Error correction code byte 2 of the eighth 256 Bytes of data
in this page</entry>
</row>
</tbody></tgroup></informaltable>
......
Documentation/DocBook/rapidio.tmpl
浏览文件 @ 6288cf1e
......@@ -133,7 +133,6 @@
!Idrivers/rapidio/rio-sysfs.c
</sect1>
<sect1 id="PPC32_support"><title>PPC32 support</title>
!Earch/powerpc/sysdev/fsl_rio.c
!Iarch/powerpc/sysdev/fsl_rio.c
</sect1>
</chapter>
......
Documentation/DocBook/regulator.tmpl
浏览文件 @ 6288cf1e
......@@ -267,8 +267,8 @@
<sect1 id="machine-constraint">
<title>Constraints</title>
<para>
As well as definining the connections the machine interface
also provides constraints definining the operations that
As well as defining the connections the machine interface
also provides constraints defining the operations that
clients are allowed to perform and the parameters that may be
set. This is required since generally regulator devices will
offer more flexibility than it is safe to use on a given
......
Documentation/DocBook/uio-howto.tmpl
浏览文件 @ 6288cf1e
......@@ -797,7 +797,7 @@ framework to set up sysfs files for this region. Simply leave it alone.
perform some initialization. After that, your hardware
starts working and will generate an interrupt as soon
as it's finished, has some data available, or needs your
attention because an error occured.
attention because an error occurred.
</para>
<para>
<filename>/dev/uioX</filename> is a read-only file. A
......
Documentation/DocBook/usb.tmpl
浏览文件 @ 6288cf1e
......@@ -690,7 +690,7 @@ usbdev_ioctl (int fd, int ifno, unsigned request, void *param)
</para><para>
This request lets kernel drivers talk to user mode code
through filesystem operations even when they don't create
a charactor or block special device.
a character or block special device.
It's also been used to do things like ask devices what
device special file should be used.
Two pre-defined ioctls are used
......
Documentation/DocBook/v4l/common.xml
浏览文件 @ 6288cf1e
......@@ -100,7 +100,7 @@ linux-kernel@vger.kernel.org, 2002-11-20. --></para>
<para>By convention system administrators create various
character device special files with these major and minor numbers in
the <filename>/dev</filename> directory. The names recomended for the
the <filename>/dev</filename> directory. The names recommended for the
different V4L2 device types are listed in <xref linkend="devices" />.
</para>
......@@ -846,6 +846,8 @@ conversion routine or library for integration into applications.</para>
</section>
</section>
&sub-planar-apis;
<section id="crop">
<title>Image Cropping, Insertion and Scaling</title>
......
Documentation/DocBook/v4l/compat.xml
浏览文件 @ 6288cf1e
......@@ -1711,8 +1711,8 @@ ioctl would enumerate the available audio inputs. An ioctl to
determine the current audio input, if more than one combines with the
current video input, did not exist. So
<constant>VIDIOC_G_AUDIO</constant> was renamed to
<constant>VIDIOC_G_AUDIO_OLD</constant>, this ioctl will be removed in
the future. The &VIDIOC-ENUMAUDIO; ioctl was added to enumerate
<constant>VIDIOC_G_AUDIO_OLD</constant>, this ioctl was removed on
Kernel 2.6.39. The &VIDIOC-ENUMAUDIO; ioctl was added to enumerate
audio inputs, while &VIDIOC-G-AUDIO; now reports the current audio
input.</para>
<para>The same changes were made to &VIDIOC-G-AUDOUT; and
......@@ -1726,7 +1726,7 @@ must be updated to successfully compile again.</para>
<para>The &VIDIOC-OVERLAY; ioctl was incorrectly defined with
write-read parameter. It was changed to write-only, while the write-read
version was renamed to <constant>VIDIOC_OVERLAY_OLD</constant>. The old
ioctl will be removed in the future. Until further the "videodev"
ioctl was removed on Kernel 2.6.39. Until further the "videodev"
kernel module will automatically translate to the new version, so drivers
must be recompiled, but not applications.</para>
</listitem>
......@@ -1744,7 +1744,7 @@ surface can be seen.</para>
defined with write-only parameter, inconsistent with other ioctls
modifying their argument. They were changed to write-read, while a
<constant>_OLD</constant> suffix was added to the write-only versions.
The old ioctls will be removed in the future. Drivers and
The old ioctls were removed on Kernel 2.6.39. Drivers and
applications assuming a constant parameter need an update.</para>
</listitem>
</orderedlist>
......@@ -1815,8 +1815,8 @@ yet to be addressed, for details see <xref
<para>The &VIDIOC-CROPCAP; ioctl was incorrectly defined
with read-only parameter. It is now defined as write-read ioctl, while
the read-only version was renamed to
<constant>VIDIOC_CROPCAP_OLD</constant>. The old ioctl will be removed
in the future.</para>
<constant>VIDIOC_CROPCAP_OLD</constant>. The old ioctl was removed
on Kernel 2.6.39.</para>
</listitem>
</orderedlist>
</section>
......@@ -2353,6 +2353,20 @@ that used it. It was originally scheduled for removal in 2.6.35.
</listitem>
</orderedlist>
</section>
<section>
<title>V4L2 in Linux 2.6.39</title>
<orderedlist>
<listitem>
<para>The old VIDIOC_*_OLD symbols and V4L1 support were removed.</para>
</listitem>
<listitem>
<para>Multi-planar API added. Does not affect the compatibility of
current drivers and applications. See
<link linkend="planar-apis">multi-planar API</link>
for details.</para>
</listitem>
</orderedlist>
</section>
<section id="other">
<title>Relation of V4L2 to other Linux multimedia APIs</title>
......
Documentation/DocBook/v4l/controls.xml
浏览文件 @ 6288cf1e
......@@ -1243,7 +1243,7 @@ values are:</entry>
</row><row><entry spanname="descr">Mutes the audio when
capturing. This is not done by muting audio hardware, which can still
produce a slight hiss, but in the encoder itself, guaranteeing a fixed
and reproducable audio bitstream. 0 = unmuted, 1 = muted.</entry>
and reproducible audio bitstream. 0 = unmuted, 1 = muted.</entry>
</row>
<row><entry></entry></row>
<row id="v4l2-mpeg-video-encoding">
......
Documentation/DocBook/v4l/dev-capture.xml
浏览文件 @ 6288cf1e
......@@ -18,7 +18,8 @@ files are used for video output devices.</para>
<title>Querying Capabilities</title>
<para>Devices supporting the video capture interface set the
<constant>V4L2_CAP_VIDEO_CAPTURE</constant> flag in the
<constant>V4L2_CAP_VIDEO_CAPTURE</constant> or
<constant>V4L2_CAP_VIDEO_CAPTURE_MPLANE</constant> flag in the
<structfield>capabilities</structfield> field of &v4l2-capability;
returned by the &VIDIOC-QUERYCAP; ioctl. As secondary device functions
they may also support the <link linkend="overlay">video overlay</link>
......@@ -64,9 +65,11 @@ linkend="crop" />.</para>
<para>To query the current image format applications set the
<structfield>type</structfield> field of a &v4l2-format; to
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant> and call the
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant> or
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant> and call the
&VIDIOC-G-FMT; ioctl with a pointer to this structure. Drivers fill
the &v4l2-pix-format; <structfield>pix</structfield> member of the
the &v4l2-pix-format; <structfield>pix</structfield> or the
&v4l2-pix-format-mplane; <structfield>pix_mp</structfield> member of the
<structfield>fmt</structfield> union.</para>
<para>To request different parameters applications set the
......@@ -84,8 +87,8 @@ adjust the parameters and finally return the actual parameters as
without disabling I/O or possibly time consuming hardware
preparations.</para>
<para>The contents of &v4l2-pix-format; are discussed in <xref
linkend="pixfmt" />. See also the specification of the
<para>The contents of &v4l2-pix-format; and &v4l2-pix-format-mplane;
are discussed in <xref linkend="pixfmt" />. See also the specification of the
<constant>VIDIOC_G_FMT</constant>, <constant>VIDIOC_S_FMT</constant>
and <constant>VIDIOC_TRY_FMT</constant> ioctls for details. Video
capture devices must implement both the
......
Documentation/DocBook/v4l/dev-output.xml
浏览文件 @ 6288cf1e
......@@ -17,7 +17,8 @@ files are used for video capture devices.</para>
<title>Querying Capabilities</title>
<para>Devices supporting the video output interface set the
<constant>V4L2_CAP_VIDEO_OUTPUT</constant> flag in the
<constant>V4L2_CAP_VIDEO_OUTPUT</constant> or
<constant>V4L2_CAP_VIDEO_OUTPUT_MPLANE</constant> flag in the
<structfield>capabilities</structfield> field of &v4l2-capability;
returned by the &VIDIOC-QUERYCAP; ioctl. As secondary device functions
they may also support the <link linkend="raw-vbi">raw VBI
......@@ -60,9 +61,11 @@ linkend="crop" />.</para>
<para>To query the current image format applications set the
<structfield>type</structfield> field of a &v4l2-format; to
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> and call the
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> or
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant> and call the
&VIDIOC-G-FMT; ioctl with a pointer to this structure. Drivers fill
the &v4l2-pix-format; <structfield>pix</structfield> member of the
the &v4l2-pix-format; <structfield>pix</structfield> or the
&v4l2-pix-format-mplane; <structfield>pix_mp</structfield> member of the
<structfield>fmt</structfield> union.</para>
<para>To request different parameters applications set the
......@@ -80,8 +83,8 @@ adjust the parameters and finally return the actual parameters as
without disabling I/O or possibly time consuming hardware
preparations.</para>
<para>The contents of &v4l2-pix-format; are discussed in <xref
linkend="pixfmt" />. See also the specification of the
<para>The contents of &v4l2-pix-format; and &v4l2-pix-format-mplane;
are discussed in <xref linkend="pixfmt" />. See also the specification of the
<constant>VIDIOC_G_FMT</constant>, <constant>VIDIOC_S_FMT</constant>
and <constant>VIDIOC_TRY_FMT</constant> ioctls for details. Video
output devices must implement both the
......
Documentation/DocBook/v4l/dev-subdev.xml 0 → 100644
浏览文件 @ 6288cf1e
<title>Sub-device Interface</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental">experimental</link>
interface and may change in the future.</para>
</note>
<para>The complex nature of V4L2 devices, where hardware is often made of
several integrated circuits that need to interact with each other in a
controlled way, leads to complex V4L2 drivers. The drivers usually reflect
the hardware model in software, and model the different hardware components
as software blocks called sub-devices.</para>
<para>V4L2 sub-devices are usually kernel-only objects. If the V4L2 driver
implements the media device API, they will automatically inherit from media
entities. Applications will be able to enumerate the sub-devices and discover
the hardware topology using the media entities, pads and links enumeration
API.</para>
<para>In addition to make sub-devices discoverable, drivers can also choose
to make them directly configurable by applications. When both the sub-device
driver and the V4L2 device driver support this, sub-devices will feature a
character device node on which ioctls can be called to
<itemizedlist>
<listitem><para>query, read and write sub-devices controls</para></listitem>
<listitem><para>subscribe and unsubscribe to events and retrieve them</para></listitem>
<listitem><para>negotiate image formats on individual pads</para></listitem>
</itemizedlist>
</para>
<para>Sub-device character device nodes, conventionally named
<filename>/dev/v4l-subdev*</filename>, use major number 81.</para>
<section>
<title>Controls</title>
<para>Most V4L2 controls are implemented by sub-device hardware. Drivers
usually merge all controls and expose them through video device nodes.
Applications can control all sub-devices through a single interface.</para>
<para>Complex devices sometimes implement the same control in different
pieces of hardware. This situation is common in embedded platforms, where
both sensors and image processing hardware implement identical functions,
such as contrast adjustment, white balance or faulty pixels correction. As
the V4L2 controls API doesn't support several identical controls in a single
device, all but one of the identical controls are hidden.</para>
<para>Applications can access those hidden controls through the sub-device
node with the V4L2 control API described in <xref linkend="control" />. The
ioctls behave identically as when issued on V4L2 device nodes, with the
exception that they deal only with controls implemented in the sub-device.
</para>
<para>Depending on the driver, those controls might also be exposed through
one (or several) V4L2 device nodes.</para>
</section>
<section>
<title>Events</title>
<para>V4L2 sub-devices can notify applications of events as described in
<xref linkend="event" />. The API behaves identically as when used on V4L2
device nodes, with the exception that it only deals with events generated by
the sub-device. Depending on the driver, those events might also be reported
on one (or several) V4L2 device nodes.</para>
</section>
<section id="pad-level-formats">
<title>Pad-level Formats</title>
<warning><para>Pad-level formats are only applicable to very complex device that
need to expose low-level format configuration to user space. Generic V4L2
applications do <emphasis>not</emphasis> need to use the API described in
this section.</para></warning>
<note><para>For the purpose of this section, the term
<wordasword>format</wordasword> means the combination of media bus data
format, frame width and frame height.</para></note>
<para>Image formats are typically negotiated on video capture and output
devices using the <link linkend="crop">cropping and scaling</link> ioctls.
The driver is responsible for configuring every block in the video pipeline
according to the requested format at the pipeline input and/or
output.</para>
<para>For complex devices, such as often found in embedded systems,
identical image sizes at the output of a pipeline can be achieved using
different hardware configurations. One such example is shown on
<xref linkend="pipeline-scaling" />, where
image scaling can be performed on both the video sensor and the host image
processing hardware.</para>
<figure id="pipeline-scaling">
<title>Image Format Negotiation on Pipelines</title>
<mediaobject>
<imageobject>
<imagedata fileref="pipeline.pdf" format="PS" />
</imageobject>
<imageobject>
<imagedata fileref="pipeline.png" format="PNG" />
</imageobject>
<textobject>
<phrase>High quality and high speed pipeline configuration</phrase>
</textobject>
</mediaobject>
</figure>
<para>The sensor scaler is usually of less quality than the host scaler, but
scaling on the sensor is required to achieve higher frame rates. Depending
on the use case (quality vs. speed), the pipeline must be configured
differently. Applications need to configure the formats at every point in
the pipeline explicitly.</para>
<para>Drivers that implement the <link linkend="media-controller-intro">media
API</link> can expose pad-level image format configuration to applications.
When they do, applications can use the &VIDIOC-SUBDEV-G-FMT; and
&VIDIOC-SUBDEV-S-FMT; ioctls. to negotiate formats on a per-pad basis.</para>
<para>Applications are responsible for configuring coherent parameters on
the whole pipeline and making sure that connected pads have compatible
formats. The pipeline is checked for formats mismatch at &VIDIOC-STREAMON;
time, and an &EPIPE; is then returned if the configuration is
invalid.</para>
<para>Pad-level image format configuration support can be tested by calling
the &VIDIOC-SUBDEV-G-FMT; ioctl on pad 0. If the driver returns an &EINVAL;
pad-level format configuration is not supported by the sub-device.</para>
<section>
<title>Format Negotiation</title>
<para>Acceptable formats on pads can (and usually do) depend on a number
of external parameters, such as formats on other pads, active links, or
even controls. Finding a combination of formats on all pads in a video
pipeline, acceptable to both application and driver, can't rely on formats
enumeration only. A format negotiation mechanism is required.</para>
<para>Central to the format negotiation mechanism are the get/set format
operations. When called with the <structfield>which</structfield> argument
set to <constant>V4L2_SUBDEV_FORMAT_TRY</constant>, the
&VIDIOC-SUBDEV-G-FMT; and &VIDIOC-SUBDEV-S-FMT; ioctls operate on a set of
formats parameters that are not connected to the hardware configuration.
Modifying those 'try' formats leaves the device state untouched (this
applies to both the software state stored in the driver and the hardware
state stored in the device itself).</para>
<para>While not kept as part of the device state, try formats are stored
in the sub-device file handles. A &VIDIOC-SUBDEV-G-FMT; call will return
the last try format set <emphasis>on the same sub-device file
handle</emphasis>. Several applications querying the same sub-device at
the same time will thus not interact with each other.</para>
<para>To find out whether a particular format is supported by the device,
applications use the &VIDIOC-SUBDEV-S-FMT; ioctl. Drivers verify and, if
needed, change the requested <structfield>format</structfield> based on
device requirements and return the possibly modified value. Applications
can then choose to try a different format or accept the returned value and
continue.</para>
<para>Formats returned by the driver during a negotiation iteration are
guaranteed to be supported by the device. In particular, drivers guarantee
that a returned format will not be further changed if passed to an
&VIDIOC-SUBDEV-S-FMT; call as-is (as long as external parameters, such as
formats on other pads or links' configuration are not changed).</para>
<para>Drivers automatically propagate formats inside sub-devices. When a
try or active format is set on a pad, corresponding formats on other pads
of the same sub-device can be modified by the driver. Drivers are free to
modify formats as required by the device. However, they should comply with
the following rules when possible:
<itemizedlist>
<listitem><para>Formats should be propagated from sink pads to source pads.
Modifying a format on a source pad should not modify the format on any
sink pad.</para></listitem>
<listitem><para>Sub-devices that scale frames using variable scaling factors
should reset the scale factors to default values when sink pads formats
are modified. If the 1:1 scaling ratio is supported, this means that
source pads formats should be reset to the sink pads formats.</para></listitem>
</itemizedlist>
</para>
<para>Formats are not propagated across links, as that would involve
propagating them from one sub-device file handle to another. Applications
must then take care to configure both ends of every link explicitly with
compatible formats. Identical formats on the two ends of a link are
guaranteed to be compatible. Drivers are free to accept different formats
matching device requirements as being compatible.</para>
<para><xref linkend="sample-pipeline-config" />
shows a sample configuration sequence for the pipeline described in
<xref linkend="pipeline-scaling" /> (table
columns list entity names and pad numbers).</para>
<table pgwide="0" frame="none" id="sample-pipeline-config">
<title>Sample Pipeline Configuration</title>
<tgroup cols="3">
<colspec colname="what"/>
<colspec colname="sensor-0" />
<colspec colname="frontend-0" />
<colspec colname="frontend-1" />
<colspec colname="scaler-0" />
<colspec colname="scaler-1" />
<thead>
<row>
<entry></entry>
<entry>Sensor/0</entry>
<entry>Frontend/0</entry>
<entry>Frontend/1</entry>
<entry>Scaler/0</entry>
<entry>Scaler/1</entry>
</row>
</thead>
<tbody valign="top">
<row>
<entry>Initial state</entry>
<entry>2048x1536</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
<entry>-</entry>
</row>
<row>
<entry>Configure frontend input</entry>
<entry>2048x1536</entry>
<entry><emphasis>2048x1536</emphasis></entry>
<entry><emphasis>2046x1534</emphasis></entry>
<entry>-</entry>
<entry>-</entry>
</row>
<row>
<entry>Configure scaler input</entry>
<entry>2048x1536</entry>
<entry>2048x1536</entry>
<entry>2046x1534</entry>
<entry><emphasis>2046x1534</emphasis></entry>
<entry><emphasis>2046x1534</emphasis></entry>
</row>
<row>
<entry>Configure scaler output</entry>
<entry>2048x1536</entry>
<entry>2048x1536</entry>
<entry>2046x1534</entry>
<entry>2046x1534</entry>
<entry><emphasis>1280x960</emphasis></entry>
</row>
</tbody>
</tgroup>
</table>
<para>
<orderedlist>
<listitem><para>Initial state. The sensor output is set to its native 3MP
resolution. Resolutions on the host frontend and scaler input and output
pads are undefined.</para></listitem>
<listitem><para>The application configures the frontend input pad resolution to
2048x1536. The driver propagates the format to the frontend output pad.
Note that the propagated output format can be different, as in this case,
than the input format, as the hardware might need to crop pixels (for
instance when converting a Bayer filter pattern to RGB or YUV).</para></listitem>
<listitem><para>The application configures the scaler input pad resolution to
2046x1534 to match the frontend output resolution. The driver propagates
the format to the scaler output pad.</para></listitem>
<listitem><para>The application configures the scaler output pad resolution to
1280x960.</para></listitem>
</orderedlist>
</para>
<para>When satisfied with the try results, applications can set the active
formats by setting the <structfield>which</structfield> argument to
<constant>V4L2_SUBDEV_FORMAT_TRY</constant>. Active formats are changed
exactly as try formats by drivers. To avoid modifying the hardware state
during format negotiation, applications should negotiate try formats first
and then modify the active settings using the try formats returned during
the last negotiation iteration. This guarantees that the active format
will be applied as-is by the driver without being modified.
</para>
</section>
<section>
<title>Cropping and scaling</title>
<para>Many sub-devices support cropping frames on their input or output
pads (or possible even on both). Cropping is used to select the area of
interest in an image, typically on a video sensor or video decoder. It can
also be used as part of digital zoom implementations to select the area of
the image that will be scaled up.</para>
<para>Crop settings are defined by a crop rectangle and represented in a
&v4l2-rect; by the coordinates of the top left corner and the rectangle
size. Both the coordinates and sizes are expressed in pixels.</para>
<para>The crop rectangle is retrieved and set using the
&VIDIOC-SUBDEV-G-CROP; and &VIDIOC-SUBDEV-S-CROP; ioctls. Like for pad
formats, drivers store try and active crop rectangles. The format
negotiation mechanism applies to crop settings as well.</para>
<para>On input pads, cropping is applied relatively to the current pad
format. The pad format represents the image size as received by the
sub-device from the previous block in the pipeline, and the crop rectangle
represents the sub-image that will be transmitted further inside the
sub-device for processing. The crop rectangle be entirely containted
inside the input image size.</para>
<para>Input crop rectangle are reset to their default value when the input
image format is modified. Drivers should use the input image size as the
crop rectangle default value, but hardware requirements may prevent this.
</para>
<para>Cropping behaviour on output pads is not defined.</para>
</section>
</section>
&sub-subdev-formats;
Documentation/DocBook/v4l/func-mmap.xml
浏览文件 @ 6288cf1e
......@@ -45,7 +45,10 @@ just specify a <constant>NULL</constant> pointer here.</para>
<listitem>
<para>Length of the memory area to map. This must be the
same value as returned by the driver in the &v4l2-buffer;
<structfield>length</structfield> field.</para>
<structfield>length</structfield> field for the
single-planar API, and the same value as returned by the driver
in the &v4l2-plane; <structfield>length</structfield> field for the
multi-planar API.</para>
</listitem>
</varlistentry>
<varlistentry>
......@@ -106,7 +109,10 @@ flag.</para>
<listitem>
<para>Offset of the buffer in device memory. This must be the
same value as returned by the driver in the &v4l2-buffer;
<structfield>m</structfield> union <structfield>offset</structfield> field.</para>
<structfield>m</structfield> union <structfield>offset</structfield> field for
the single-planar API, and the same value as returned by the driver
in the &v4l2-plane; <structfield>m</structfield> union
<structfield>mem_offset</structfield> field for the multi-planar API.</para>
</listitem>
</varlistentry>
</variablelist>
......
Documentation/DocBook/v4l/func-munmap.xml
浏览文件 @ 6288cf1e
......@@ -37,7 +37,8 @@
<para>Length of the mapped buffer. This must be the same
value as given to <function>mmap()</function> and returned by the
driver in the &v4l2-buffer; <structfield>length</structfield>
field.</para>
field for the single-planar API and in the &v4l2-plane;
<structfield>length</structfield> field for the multi-planar API.</para>
</listitem>
</varlistentry>
</variablelist>
......
Documentation/DocBook/v4l/io.xml
浏览文件 @ 6288cf1e
......@@ -121,18 +121,22 @@ mapped.</para>
<para>Before applications can access the buffers they must map
them into their address space with the &func-mmap; function. The
location of the buffers in device memory can be determined with the
&VIDIOC-QUERYBUF; ioctl. The <structfield>m.offset</structfield> and
<structfield>length</structfield> returned in a &v4l2-buffer; are
passed as sixth and second parameter to the
<function>mmap()</function> function. The offset and length values
must not be modified. Remember the buffers are allocated in physical
memory, as opposed to virtual memory which can be swapped out to disk.
Applications should free the buffers as soon as possible with the
&func-munmap; function.</para>
&VIDIOC-QUERYBUF; ioctl. In the single-planar API case, the
<structfield>m.offset</structfield> and <structfield>length</structfield>
returned in a &v4l2-buffer; are passed as sixth and second parameter to the
<function>mmap()</function> function. When using the multi-planar API,
struct &v4l2-buffer; contains an array of &v4l2-plane; structures, each
containing its own <structfield>m.offset</structfield> and
<structfield>length</structfield>. When using the multi-planar API, every
plane of every buffer has to be mapped separately, so the number of
calls to &func-mmap; should be equal to number of buffers times number of
planes in each buffer. The offset and length values must not be modified.
Remember, the buffers are allocated in physical memory, as opposed to virtual
memory, which can be swapped out to disk. Applications should free the buffers
as soon as possible with the &func-munmap; function.</para>
<example>
<title>Mapping buffers</title>
<title>Mapping buffers in the single-planar API</title>
<programlisting>
&v4l2-requestbuffers; reqbuf;
struct {
......@@ -141,63 +145,145 @@ struct {
} *buffers;
unsigned int i;
memset (&amp;reqbuf, 0, sizeof (reqbuf));
memset(&amp;reqbuf, 0, sizeof(reqbuf));
reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
reqbuf.memory = V4L2_MEMORY_MMAP;
reqbuf.count = 20;
if (-1 == ioctl (fd, &VIDIOC-REQBUFS;, &amp;reqbuf)) {
if (errno == EINVAL)
printf ("Video capturing or mmap-streaming is not supported\n");
printf("Video capturing or mmap-streaming is not supported\n");
else
perror ("VIDIOC_REQBUFS");
perror("VIDIOC_REQBUFS");
exit (EXIT_FAILURE);
exit(EXIT_FAILURE);
}
/* We want at least five buffers. */
if (reqbuf.count &lt; 5) {
/* You may need to free the buffers here. */
printf ("Not enough buffer memory\n");
exit (EXIT_FAILURE);
printf("Not enough buffer memory\n");
exit(EXIT_FAILURE);
}
buffers = calloc (reqbuf.count, sizeof (*buffers));
assert (buffers != NULL);
buffers = calloc(reqbuf.count, sizeof(*buffers));
assert(buffers != NULL);
for (i = 0; i &lt; reqbuf.count; i++) {
&v4l2-buffer; buffer;
memset (&amp;buffer, 0, sizeof (buffer));
memset(&amp;buffer, 0, sizeof(buffer));
buffer.type = reqbuf.type;
buffer.memory = V4L2_MEMORY_MMAP;
buffer.index = i;
if (-1 == ioctl (fd, &VIDIOC-QUERYBUF;, &amp;buffer)) {
perror ("VIDIOC_QUERYBUF");
exit (EXIT_FAILURE);
perror("VIDIOC_QUERYBUF");
exit(EXIT_FAILURE);
}
buffers[i].length = buffer.length; /* remember for munmap() */
buffers[i].start = mmap (NULL, buffer.length,
PROT_READ | PROT_WRITE, /* recommended */
MAP_SHARED, /* recommended */
fd, buffer.m.offset);
buffers[i].start = mmap(NULL, buffer.length,
PROT_READ | PROT_WRITE, /* recommended */
MAP_SHARED, /* recommended */
fd, buffer.m.offset);
if (MAP_FAILED == buffers[i].start) {
/* If you do not exit here you should unmap() and free()
the buffers mapped so far. */
perror ("mmap");
exit (EXIT_FAILURE);
perror("mmap");
exit(EXIT_FAILURE);
}
}
/* Cleanup. */
for (i = 0; i &lt; reqbuf.count; i++)
munmap(buffers[i].start, buffers[i].length);
</programlisting>
</example>
<example>
<title>Mapping buffers in the multi-planar API</title>
<programlisting>
&v4l2-requestbuffers; reqbuf;
/* Our current format uses 3 planes per buffer */
#define FMT_NUM_PLANES = 3;
struct {
void *start[FMT_NUM_PLANES];
size_t length[FMT_NUM_PLANES];
} *buffers;
unsigned int i, j;
memset(&amp;reqbuf, 0, sizeof(reqbuf));
reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
reqbuf.memory = V4L2_MEMORY_MMAP;
reqbuf.count = 20;
if (ioctl(fd, &VIDIOC-REQBUFS;, &amp;reqbuf) &lt; 0) {
if (errno == EINVAL)
printf("Video capturing or mmap-streaming is not supported\n");
else
perror("VIDIOC_REQBUFS");
exit(EXIT_FAILURE);
}
/* We want at least five buffers. */
if (reqbuf.count &lt; 5) {
/* You may need to free the buffers here. */
printf("Not enough buffer memory\n");
exit(EXIT_FAILURE);
}
buffers = calloc(reqbuf.count, sizeof(*buffers));
assert(buffers != NULL);
for (i = 0; i &lt; reqbuf.count; i++) {
&v4l2-buffer; buffer;
&v4l2-plane; planes[FMT_NUM_PLANES];
memset(&amp;buffer, 0, sizeof(buffer));
buffer.type = reqbuf.type;
buffer.memory = V4L2_MEMORY_MMAP;
buffer.index = i;
/* length in struct v4l2_buffer in multi-planar API stores the size
* of planes array. */
buffer.length = FMT_NUM_PLANES;
buffer.m.planes = planes;
if (ioctl(fd, &VIDIOC-QUERYBUF;, &amp;buffer) &lt; 0) {
perror("VIDIOC_QUERYBUF");
exit(EXIT_FAILURE);
}
/* Every plane has to be mapped separately */
for (j = 0; j &lt; FMT_NUM_PLANES; j++) {
buffers[i].length[j] = buffer.m.planes[j].length; /* remember for munmap() */
buffers[i].start[j] = mmap(NULL, buffer.m.planes[j].length,
PROT_READ | PROT_WRITE, /* recommended */
MAP_SHARED, /* recommended */
fd, buffer.m.planes[j].m.offset);
if (MAP_FAILED == buffers[i].start[j]) {
/* If you do not exit here you should unmap() and free()
the buffers and planes mapped so far. */
perror("mmap");
exit(EXIT_FAILURE);
}
}
}
/* Cleanup. */
for (i = 0; i &lt; reqbuf.count; i++)
munmap (buffers[i].start, buffers[i].length);
for (j = 0; j &lt; FMT_NUM_PLANES; j++)
munmap(buffers[i].start[j], buffers[i].length[j]);
</programlisting>
</example>
......@@ -286,13 +372,13 @@ pointer method (not only memory mapping) is supported must be
determined by calling the &VIDIOC-REQBUFS; ioctl.</para>
<para>This I/O method combines advantages of the read/write and
memory mapping methods. Buffers are allocated by the application
memory mapping methods. Buffers (planes) are allocated by the application
itself, and can reside for example in virtual or shared memory. Only
pointers to data are exchanged, these pointers and meta-information
are passed in &v4l2-buffer;. The driver must be switched
into user pointer I/O mode by calling the &VIDIOC-REQBUFS; with the
desired buffer type. No buffers are allocated beforehands,
consequently they are not indexed and cannot be queried like mapped
are passed in &v4l2-buffer; (or in &v4l2-plane; in the multi-planar API case).
The driver must be switched into user pointer I/O mode by calling the
&VIDIOC-REQBUFS; with the desired buffer type. No buffers (planes) are allocated
beforehand, consequently they are not indexed and cannot be queried like mapped
buffers with the <constant>VIDIOC_QUERYBUF</constant> ioctl.</para>
<example>
......@@ -316,7 +402,7 @@ if (ioctl (fd, &VIDIOC-REQBUFS;, &amp;reqbuf) == -1) {
</programlisting>
</example>
<para>Buffer addresses and sizes are passed on the fly with the
<para>Buffer (plane) addresses and sizes are passed on the fly with the
&VIDIOC-QBUF; ioctl. Although buffers are commonly cycled,
applications can pass different addresses and sizes at each
<constant>VIDIOC_QBUF</constant> call. If required by the hardware the
......@@ -396,11 +482,18 @@ rest should be evident.</para>
<title>Buffers</title>
<para>A buffer contains data exchanged by application and
driver using one of the Streaming I/O methods. Only pointers to
buffers are exchanged, the data itself is not copied. These pointers,
together with meta-information like timestamps or field parity, are
stored in a struct <structname>v4l2_buffer</structname>, argument to
the &VIDIOC-QUERYBUF;, &VIDIOC-QBUF; and &VIDIOC-DQBUF; ioctl.</para>
driver using one of the Streaming I/O methods. In the multi-planar API, the
data is held in planes, while the buffer structure acts as a container
for the planes. Only pointers to buffers (planes) are exchanged, the data
itself is not copied. These pointers, together with meta-information like
timestamps or field parity, are stored in a struct
<structname>v4l2_buffer</structname>, argument to
the &VIDIOC-QUERYBUF;, &VIDIOC-QBUF; and &VIDIOC-DQBUF; ioctl.
In the multi-planar API, some plane-specific members of struct
<structname>v4l2_buffer</structname>, such as pointers and sizes for each
plane, are stored in struct <structname>v4l2_plane</structname> instead.
In that case, struct <structname>v4l2_buffer</structname> contains an array of
plane structures.</para>
<para>Nominally timestamps refer to the first data byte transmitted.
In practice however the wide range of hardware covered by the V4L2 API
......@@ -551,26 +644,40 @@ in accordance with the selected I/O method.</entry>
<entry></entry>
<entry>__u32</entry>
<entry><structfield>offset</structfield></entry>
<entry>When <structfield>memory</structfield> is
<constant>V4L2_MEMORY_MMAP</constant> this is the offset of the buffer
from the start of the device memory. The value is returned by the
driver and apart of serving as parameter to the &func-mmap; function
not useful for applications. See <xref linkend="mmap" /> for details.</entry>
<entry>For the single-planar API and when
<structfield>memory</structfield> is <constant>V4L2_MEMORY_MMAP</constant> this
is the offset of the buffer from the start of the device memory. The value is
returned by the driver and apart of serving as parameter to the &func-mmap;
function not useful for applications. See <xref linkend="mmap" /> for details
</entry>
</row>
<row>
<entry></entry>
<entry>unsigned long</entry>
<entry><structfield>userptr</structfield></entry>
<entry>When <structfield>memory</structfield> is
<constant>V4L2_MEMORY_USERPTR</constant> this is a pointer to the
buffer (casted to unsigned long type) in virtual memory, set by the
application. See <xref linkend="userp" /> for details.</entry>
<entry>For the single-planar API and when
<structfield>memory</structfield> is <constant>V4L2_MEMORY_USERPTR</constant>
this is a pointer to the buffer (casted to unsigned long type) in virtual
memory, set by the application. See <xref linkend="userp" /> for details.
</entry>
</row>
<row>
<entry></entry>
<entry>struct v4l2_plane</entry>
<entry><structfield>*planes</structfield></entry>
<entry>When using the multi-planar API, contains a userspace pointer
to an array of &v4l2-plane;. The size of the array should be put
in the <structfield>length</structfield> field of this
<structname>v4l2_buffer</structname> structure.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>length</structfield></entry>
<entry></entry>
<entry>Size of the buffer (not the payload) in bytes.</entry>
<entry>Size of the buffer (not the payload) in bytes for the
single-planar API. For the multi-planar API should contain the
number of elements in the <structfield>planes</structfield> array.
</entry>
</row>
<row>
<entry>__u32</entry>
......@@ -596,6 +703,66 @@ should set this to 0.</entry>
</tgroup>
</table>
<table frame="none" pgwide="1" id="v4l2-plane">
<title>struct <structname>v4l2_plane</structname></title>
<tgroup cols="4">
&cs-ustr;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>bytesused</structfield></entry>
<entry></entry>
<entry>The number of bytes occupied by data in the plane
(its payload).</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>length</structfield></entry>
<entry></entry>
<entry>Size in bytes of the plane (not its payload).</entry>
</row>
<row>
<entry>union</entry>
<entry><structfield>m</structfield></entry>
<entry></entry>
<entry></entry>
</row>
<row>
<entry></entry>
<entry>__u32</entry>
<entry><structfield>mem_offset</structfield></entry>
<entry>When the memory type in the containing &v4l2-buffer; is
<constant>V4L2_MEMORY_MMAP</constant>, this is the value that
should be passed to &func-mmap;, similar to the
<structfield>offset</structfield> field in &v4l2-buffer;.</entry>
</row>
<row>
<entry></entry>
<entry>__unsigned long</entry>
<entry><structfield>userptr</structfield></entry>
<entry>When the memory type in the containing &v4l2-buffer; is
<constant>V4L2_MEMORY_USERPTR</constant>, this is a userspace
pointer to the memory allocated for this plane by an application.
</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>data_offset</structfield></entry>
<entry></entry>
<entry>Offset in bytes to video data in the plane, if applicable.
</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved[11]</structfield></entry>
<entry></entry>
<entry>Reserved for future use. Should be zeroed by an
application.</entry>
</row>
</tbody>
</tgroup>
</table>
<table frame="none" pgwide="1" id="v4l2-buf-type">
<title>enum v4l2_buf_type</title>
<tgroup cols="3">
......@@ -604,13 +771,27 @@ should set this to 0.</entry>
<row>
<entry><constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant></entry>
<entry>1</entry>
<entry>Buffer of a video capture stream, see <xref
<entry>Buffer of a single-planar video capture stream, see <xref
linkend="capture" />.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>
</entry>
<entry>9</entry>
<entry>Buffer of a multi-planar video capture stream, see <xref
linkend="capture" />.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant></entry>
<entry>2</entry>
<entry>Buffer of a video output stream, see <xref
<entry>Buffer of a single-planar video output stream, see <xref
linkend="output" />.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant>
</entry>
<entry>10</entry>
<entry>Buffer of a multi-planar video output stream, see <xref
linkend="output" />.</entry>
</row>
<row>
......
Documentation/DocBook/v4l/libv4l.xml
浏览文件 @ 6288cf1e
......@@ -140,7 +140,7 @@ and is not locked sets the cid to the scaled value.
<para>int v4l2_get_control(int fd, int cid) -
This function returns a value of 0 - 65535, scaled to from the actual range
of the given v4l control id. when the cid does not exist, could not be
accessed for some reason, or some error occured 0 is returned.
accessed for some reason, or some error occurred 0 is returned.
</para></listitem>
</itemizedlist>
</section>
......
Documentation/DocBook/v4l/lirc_device_interface.xml
浏览文件 @ 6288cf1e
......@@ -45,7 +45,7 @@ describing an IR signal are read from the chardev.</para>
<para>The data written to the chardev is a pulse/space sequence of integer
values. Pulses and spaces are only marked implicitly by their position. The
data must start and end with a pulse, therefore, the data must always include
an unevent number of samples. The write function must block until the data has
an uneven number of samples. The write function must block until the data has
been transmitted by the hardware.</para>
</section>
......
Documentation/DocBook/v4l/media-controller.xml 0 → 100644
浏览文件 @ 6288cf1e
<partinfo>
<authorgroup>
<author>
<firstname>Laurent</firstname>
<surname>Pinchart</surname>
<affiliation><address><email>laurent.pinchart@ideasonboard.com</email></address></affiliation>
<contrib>Initial version.</contrib>
</author>
</authorgroup>
<copyright>
<year>2010</year>
<holder>Laurent Pinchart</holder>
</copyright>
<revhistory>
<!-- Put document revisions here, newest first. -->
<revision>
<revnumber>1.0.0</revnumber>
<date>2010-11-10</date>
<authorinitials>lp</authorinitials>
<revremark>Initial revision</revremark>
</revision>
</revhistory>
</partinfo>
<title>Media Controller API</title>
<chapter id="media_controller">
<title>Media Controller</title>
<section id="media-controller-intro">
<title>Introduction</title>
<para>Media devices increasingly handle multiple related functions. Many USB
cameras include microphones, video capture hardware can also output video,
or SoC camera interfaces also perform memory-to-memory operations similar to
video codecs.</para>
<para>Independent functions, even when implemented in the same hardware, can
be modelled as separate devices. A USB camera with a microphone will be
presented to userspace applications as V4L2 and ALSA capture devices. The
devices' relationships (when using a webcam, end-users shouldn't have to
manually select the associated USB microphone), while not made available
directly to applications by the drivers, can usually be retrieved from
sysfs.</para>
<para>With more and more advanced SoC devices being introduced, the current
approach will not scale. Device topologies are getting increasingly complex
and can't always be represented by a tree structure. Hardware blocks are
shared between different functions, creating dependencies between seemingly
unrelated devices.</para>
<para>Kernel abstraction APIs such as V4L2 and ALSA provide means for
applications to access hardware parameters. As newer hardware expose an
increasingly high number of those parameters, drivers need to guess what
applications really require based on limited information, thereby
implementing policies that belong to userspace.</para>
<para>The media controller API aims at solving those problems.</para>
</section>
<section id="media-controller-model">
<title>Media device model</title>
<para>Discovering a device internal topology, and configuring it at runtime,
is one of the goals of the media controller API. To achieve this, hardware
devices are modelled as an oriented graph of building blocks called entities
connected through pads.</para>
<para>An entity is a basic media hardware or software building block. It can
correspond to a large variety of logical blocks such as physical hardware
devices (CMOS sensor for instance), logical hardware devices (a building
block in a System-on-Chip image processing pipeline), DMA channels or
physical connectors.</para>
<para>A pad is a connection endpoint through which an entity can interact
with other entities. Data (not restricted to video) produced by an entity
flows from the entity's output to one or more entity inputs. Pads should not
be confused with physical pins at chip boundaries.</para>
<para>A link is a point-to-point oriented connection between two pads,
either on the same entity or on different entities. Data flows from a source
pad to a sink pad.</para>
</section>
</chapter>
<appendix id="media-user-func">
<title>Function Reference</title>
<!-- Keep this alphabetically sorted. -->
&sub-media-open;
&sub-media-close;
&sub-media-ioctl;
<!-- All ioctls go here. -->
&sub-media-ioc-device-info;
&sub-media-ioc-enum-entities;
&sub-media-ioc-enum-links;
&sub-media-ioc-setup-link;
</appendix>
Documentation/DocBook/v4l/media-func-close.xml 0 → 100644
浏览文件 @ 6288cf1e
<refentry id="media-func-close">
<refmeta>
<refentrytitle>media close()</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>media-close</refname>
<refpurpose>Close a media device</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcsynopsisinfo>#include &lt;unistd.h&gt;</funcsynopsisinfo>
<funcprototype>
<funcdef>int <function>close</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>&fd;</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>Closes the media device. Resources associated with the file descriptor
are freed. The device configuration remain unchanged.</para>
</refsect1>
<refsect1>
<title>Return Value</title>
<para><function>close</function> returns 0 on success. On error, -1 is
returned, and <varname>errno</varname> is set appropriately. Possible error
codes are:</para>
<variablelist>
<varlistentry>
<term><errorcode>EBADF</errorcode></term>
<listitem>
<para><parameter>fd</parameter> is not a valid open file descriptor.
</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>
Documentation/DocBook/v4l/media-func-ioctl.xml 0 → 100644
浏览文件 @ 6288cf1e
<refentry id="media-func-ioctl">
<refmeta>
<refentrytitle>media ioctl()</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>media-ioctl</refname>
<refpurpose>Control a media device</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcsynopsisinfo>#include &lt;sys/ioctl.h&gt;</funcsynopsisinfo>
<funcprototype>
<funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef>
<paramdef>void *<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>Media ioctl request code as defined in the media.h header file,
for example MEDIA_IOC_SETUP_LINK.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para>Pointer to a request-specific structure.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>The <function>ioctl()</function> function manipulates media device
parameters. The argument <parameter>fd</parameter> must be an open file
descriptor.</para>
<para>The ioctl <parameter>request</parameter> code specifies the media
function to be called. It has encoded in it whether the argument is an
input, output or read/write parameter, and the size of the argument
<parameter>argp</parameter> in bytes.</para>
<para>Macros and structures definitions specifying media ioctl requests and
their parameters are located in the media.h header file. All media ioctl
requests, their respective function and parameters are specified in
<xref linkend="media-user-func" />.</para>
</refsect1>
<refsect1>
<title>Return Value</title>
<para><function>ioctl()</function> returns <returnvalue>0</returnvalue> on
success. On failure, <returnvalue>-1</returnvalue> is returned, and the
<varname>errno</varname> variable is set appropriately. Generic error codes
are listed below, and request-specific error codes are listed in the
individual requests descriptions.</para>
<para>When an ioctl that takes an output or read/write parameter fails,
the parameter remains unmodified.</para>
<variablelist>
<varlistentry>
<term><errorcode>EBADF</errorcode></term>
<listitem>
<para><parameter>fd</parameter> is not a valid open file descriptor.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EFAULT</errorcode></term>
<listitem>
<para><parameter>argp</parameter> references an inaccessible memory
area.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The <parameter>request</parameter> or the data pointed to by
<parameter>argp</parameter> is not valid. This is a very common error
code, see the individual ioctl requests listed in
<xref linkend="media-user-func" /> for actual causes.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>ENOMEM</errorcode></term>
<listitem>
<para>Insufficient kernel memory was available to complete the
request.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>ENOTTY</errorcode></term>
<listitem>
<para><parameter>fd</parameter> is not associated with a character
special device.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>
Documentation/DocBook/v4l/media-func-open.xml 0 → 100644
浏览文件 @ 6288cf1e
<refentry id="media-func-open">
<refmeta>
<refentrytitle>media open()</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>media-open</refname>
<refpurpose>Open a media device</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcsynopsisinfo>#include &lt;fcntl.h&gt;</funcsynopsisinfo>
<funcprototype>
<funcdef>int <function>open</function></funcdef>
<paramdef>const char *<parameter>device_name</parameter></paramdef>
<paramdef>int <parameter>flags</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>device_name</parameter></term>
<listitem>
<para>Device to be opened.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>flags</parameter></term>
<listitem>
<para>Open flags. Access mode must be either <constant>O_RDONLY</constant>
or <constant>O_RDWR</constant>. Other flags have no effect.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>To open a media device applications call <function>open()</function>
with the desired device name. The function has no side effects; the device
configuration remain unchanged.</para>
<para>When the device is opened in read-only mode, attemps to modify its
configuration will result in an error, and <varname>errno</varname> will be
set to <errorcode>EBADF</errorcode>.</para>
</refsect1>
<refsect1>
<title>Return Value</title>
<para><function>open</function> returns the new file descriptor on success.
On error, -1 is returned, and <varname>errno</varname> is set appropriately.
Possible error codes are:</para>
<variablelist>
<varlistentry>
<term><errorcode>EACCES</errorcode></term>
<listitem>
<para>The requested access to the file is not allowed.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EMFILE</errorcode></term>
<listitem>
<para>The process already has the maximum number of files open.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>ENFILE</errorcode></term>
<listitem>
<para>The system limit on the total number of open files has been
reached.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>ENOMEM</errorcode></term>
<listitem>
<para>Insufficient kernel memory was available.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>ENXIO</errorcode></term>
<listitem>
<para>No device corresponding to this device special file exists.
</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>
Documentation/DocBook/v4l/media-ioc-device-info.xml 0 → 100644
浏览文件 @ 6288cf1e
<refentry id="media-ioc-device-info">
<refmeta>
<refentrytitle>ioctl MEDIA_IOC_DEVICE_INFO</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>MEDIA_IOC_DEVICE_INFO</refname>
<refpurpose>Query device information</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 media_device_info *<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>File descriptor returned by
<link linkend='media-func-open'><function>open()</function></link>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>MEDIA_IOC_DEVICE_INFO</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>All media devices must support the <constant>MEDIA_IOC_DEVICE_INFO</constant>
ioctl. To query device information, applications call the ioctl with a
pointer to a &media-device-info;. The driver fills the structure and returns
the information to the application.
The ioctl never fails.</para>
<table pgwide="1" frame="none" id="media-device-info">
<title>struct <structname>media_device_info</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>char</entry>
<entry><structfield>driver</structfield>[16]</entry>
<entry><para>Name of the driver implementing the media API as a
NUL-terminated ASCII string. The driver version is stored in the
<structfield>driver_version</structfield> field.</para>
<para>Driver specific applications can use this information to
verify the driver identity. It is also useful to work around
known bugs, or to identify drivers in error reports.</para></entry>
</row>
<row>
<entry>char</entry>
<entry><structfield>model</structfield>[32]</entry>
<entry>Device model name as a NUL-terminated UTF-8 string. The
device version is stored in the <structfield>device_version</structfield>
field and is not be appended to the model name.</entry>
</row>
<row>
<entry>char</entry>
<entry><structfield>serial</structfield>[40]</entry>
<entry>Serial number as a NUL-terminated ASCII string.</entry>
</row>
<row>
<entry>char</entry>
<entry><structfield>bus_info</structfield>[32]</entry>
<entry>Location of the device in the system as a NUL-terminated
ASCII string. This includes the bus type name (PCI, USB, ...) and a
bus-specific identifier.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>media_version</structfield></entry>
<entry>Media API version, formatted with the
<constant>KERNEL_VERSION()</constant> macro.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>hw_revision</structfield></entry>
<entry>Hardware device revision in a driver-specific format.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>media_version</structfield></entry>
<entry>Media device driver version, formatted with the
<constant>KERNEL_VERSION()</constant> macro. Together with the
<structfield>driver</structfield> field this identifies a particular
driver.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[31]</entry>
<entry>Reserved for future extensions. Drivers and applications must
set this array to zero.</entry>
</row>
</tbody>
</tgroup>
</table>
<para>The <structfield>serial</structfield> and <structfield>bus_info</structfield>
fields can be used to distinguish between multiple instances of otherwise
identical hardware. The serial number takes precedence when provided and can
be assumed to be unique. If the serial number is an empty string, the
<structfield>bus_info</structfield> field can be used instead. The
<structfield>bus_info</structfield> field is guaranteed to be unique, but
can vary across reboots or device unplug/replug.</para>
</refsect1>
<refsect1>
<title>Return value</title>
<para>This function doesn't return specific error codes.</para>
</refsect1>
</refentry>
Documentation/DocBook/v4l/media-ioc-enum-entities.xml 0 → 100644
浏览文件 @ 6288cf1e
<refentry id="media-ioc-enum-entities">
<refmeta>
<refentrytitle>ioctl MEDIA_IOC_ENUM_ENTITIES</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>MEDIA_IOC_ENUM_ENTITIES</refname>
<refpurpose>Enumerate entities and their properties</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 media_entity_desc *<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>File descriptor returned by
<link linkend='media-func-open'><function>open()</function></link>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>MEDIA_IOC_ENUM_ENTITIES</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>To query the attributes of an entity, applications set the id field
of a &media-entity-desc; structure and call the MEDIA_IOC_ENUM_ENTITIES
ioctl with a pointer to this structure. The driver fills the rest of the
structure or returns an &EINVAL; when the id is invalid.</para>
<para>Entities can be enumerated by or'ing the id with the
<constant>MEDIA_ENT_ID_FLAG_NEXT</constant> flag. The driver will return
information about the entity with the smallest id strictly larger than the
requested one ('next entity'), or the &EINVAL; if there is none.</para>
<para>Entity IDs can be non-contiguous. Applications must
<emphasis>not</emphasis> try to enumerate entities by calling
MEDIA_IOC_ENUM_ENTITIES with increasing id's until they get an error.</para>
<para>Two or more entities that share a common non-zero
<structfield>group_id</structfield> value are considered as logically
grouped. Groups are used to report
<itemizedlist>
<listitem><para>ALSA, VBI and video nodes that carry the same media
stream</para></listitem>
<listitem><para>lens and flash controllers associated with a sensor</para></listitem>
</itemizedlist>
</para>
<table pgwide="1" frame="none" id="media-entity-desc">
<title>struct <structname>media_entity_desc</structname></title>
<tgroup cols="5">
<colspec colname="c1" />
<colspec colname="c2" />
<colspec colname="c3" />
<colspec colname="c4" />
<colspec colname="c5" />
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>id</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Entity id, set by the application. When the id is or'ed with
<constant>MEDIA_ENT_ID_FLAG_NEXT</constant>, the driver clears the
flag and returns the first entity with a larger id.</entry>
</row>
<row>
<entry>char</entry>
<entry><structfield>name</structfield>[32]</entry>
<entry></entry>
<entry></entry>
<entry>Entity name as an UTF-8 NULL-terminated string.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>type</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Entity type, see <xref linkend="media-entity-type" /> for details.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>revision</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Entity revision in a driver/hardware specific format.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>flags</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Entity flags, see <xref linkend="media-entity-flag" /> for details.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>group_id</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Entity group ID</entry>
</row>
<row>
<entry>__u16</entry>
<entry><structfield>pads</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Number of pads</entry>
</row>
<row>
<entry>__u16</entry>
<entry><structfield>links</structfield></entry>
<entry></entry>
<entry></entry>
<entry>Total number of outbound links. Inbound links are not counted
in this field.</entry>
</row>
<row>
<entry>union</entry>
</row>
<row>
<entry></entry>
<entry>struct</entry>
<entry><structfield>v4l</structfield></entry>
<entry></entry>
<entry>Valid for V4L sub-devices and nodes only.</entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry>__u32</entry>
<entry><structfield>major</structfield></entry>
<entry>V4L device node major number. For V4L sub-devices with no
device node, set by the driver to 0.</entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry>__u32</entry>
<entry><structfield>minor</structfield></entry>
<entry>V4L device node minor number. For V4L sub-devices with no
device node, set by the driver to 0.</entry>
</row>
<row>
<entry></entry>
<entry>struct</entry>
<entry><structfield>fb</structfield></entry>
<entry></entry>
<entry>Valid for frame buffer nodes only.</entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry>__u32</entry>
<entry><structfield>major</structfield></entry>
<entry>Frame buffer device node major number.</entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry>__u32</entry>
<entry><structfield>minor</structfield></entry>
<entry>Frame buffer device node minor number.</entry>
</row>
<row>
<entry></entry>
<entry>struct</entry>
<entry><structfield>alsa</structfield></entry>
<entry></entry>
<entry>Valid for ALSA devices only.</entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry>__u32</entry>
<entry><structfield>card</structfield></entry>
<entry>ALSA card number</entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry>__u32</entry>
<entry><structfield>device</structfield></entry>
<entry>ALSA device number</entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry>__u32</entry>
<entry><structfield>subdevice</structfield></entry>
<entry>ALSA sub-device number</entry>
</row>
<row>
<entry></entry>
<entry>int</entry>
<entry><structfield>dvb</structfield></entry>
<entry></entry>
<entry>DVB card number</entry>
</row>
<row>
<entry></entry>
<entry>__u8</entry>
<entry><structfield>raw</structfield>[180]</entry>
<entry></entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
<table frame="none" pgwide="1" id="media-entity-type">
<title>Media entity types</title>
<tgroup cols="2">
<colspec colname="c1"/>
<colspec colname="c2"/>
<tbody valign="top">
<row>
<entry><constant>MEDIA_ENT_T_DEVNODE</constant></entry>
<entry>Unknown device node</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_DEVNODE_V4L</constant></entry>
<entry>V4L video, radio or vbi device node</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_DEVNODE_FB</constant></entry>
<entry>Frame buffer device node</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_DEVNODE_ALSA</constant></entry>
<entry>ALSA card</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_DEVNODE_DVB</constant></entry>
<entry>DVB card</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_V4L2_SUBDEV</constant></entry>
<entry>Unknown V4L sub-device</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_SENSOR</constant></entry>
<entry>Video sensor</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_FLASH</constant></entry>
<entry>Flash controller</entry>
</row>
<row>
<entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_LENS</constant></entry>
<entry>Lens controller</entry>
</row>
</tbody>
</tgroup>
</table>
<table frame="none" pgwide="1" id="media-entity-flag">
<title>Media entity flags</title>
<tgroup cols="2">
<colspec colname="c1"/>
<colspec colname="c2"/>
<tbody valign="top">
<row>
<entry><constant>MEDIA_ENT_FL_DEFAULT</constant></entry>
<entry>Default entity for its type. Used to discover the default
audio, VBI and video devices, the default camera sensor, ...</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The &media-entity-desc; <structfield>id</structfield> references
a non-existing entity.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>
Documentation/DocBook/v4l/media-ioc-enum-links.xml 0 → 100644
浏览文件 @ 6288cf1e
<refentry id="media-ioc-enum-links">
<refmeta>
<refentrytitle>ioctl MEDIA_IOC_ENUM_LINKS</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>MEDIA_IOC_ENUM_LINKS</refname>
<refpurpose>Enumerate all pads and links for a given entity</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 media_links_enum *<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>File descriptor returned by
<link linkend='media-func-open'><function>open()</function></link>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>MEDIA_IOC_ENUM_LINKS</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>To enumerate pads and/or links for a given entity, applications set
the entity field of a &media-links-enum; structure and initialize the
&media-pad-desc; and &media-link-desc; structure arrays pointed by the
<structfield>pads</structfield> and <structfield>links</structfield> fields.
They then call the MEDIA_IOC_ENUM_LINKS ioctl with a pointer to this
structure.</para>
<para>If the <structfield>pads</structfield> field is not NULL, the driver
fills the <structfield>pads</structfield> array with information about the
entity's pads. The array must have enough room to store all the entity's
pads. The number of pads can be retrieved with the &MEDIA-IOC-ENUM-ENTITIES;
ioctl.</para>
<para>If the <structfield>links</structfield> field is not NULL, the driver
fills the <structfield>links</structfield> array with information about the
entity's outbound links. The array must have enough room to store all the
entity's outbound links. The number of outbound links can be retrieved with
the &MEDIA-IOC-ENUM-ENTITIES; ioctl.</para>
<para>Only forward links that originate at one of the entity's source pads
are returned during the enumeration process.</para>
<table pgwide="1" frame="none" id="media-links-enum">
<title>struct <structname>media_links_enum</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>entity</structfield></entry>
<entry>Entity id, set by the application.</entry>
</row>
<row>
<entry>struct &media-pad-desc;</entry>
<entry>*<structfield>pads</structfield></entry>
<entry>Pointer to a pads array allocated by the application. Ignored
if NULL.</entry>
</row>
<row>
<entry>struct &media-link-desc;</entry>
<entry>*<structfield>links</structfield></entry>
<entry>Pointer to a links array allocated by the application. Ignored
if NULL.</entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="media-pad-desc">
<title>struct <structname>media_pad_desc</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>entity</structfield></entry>
<entry>ID of the entity this pad belongs to.</entry>
</row>
<row>
<entry>__u16</entry>
<entry><structfield>index</structfield></entry>
<entry>0-based pad index.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>flags</structfield></entry>
<entry>Pad flags, see <xref linkend="media-pad-flag" /> for more details.</entry>
</row>
</tbody>
</tgroup>
</table>
<table frame="none" pgwide="1" id="media-pad-flag">
<title>Media pad flags</title>
<tgroup cols="2">
<colspec colname="c1"/>
<colspec colname="c2"/>
<tbody valign="top">
<row>
<entry><constant>MEDIA_PAD_FL_SINK</constant></entry>
<entry>Input pad, relative to the entity. Input pads sink data and
are targets of links.</entry>
</row>
<row>
<entry><constant>MEDIA_PAD_FL_SOURCE</constant></entry>
<entry>Output pad, relative to the entity. Output pads source data
and are origins of links.</entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="media-link-desc">
<title>struct <structname>media_links_desc</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>struct &media-pad-desc;</entry>
<entry><structfield>source</structfield></entry>
<entry>Pad at the origin of this link.</entry>
</row>
<row>
<entry>struct &media-pad-desc;</entry>
<entry><structfield>sink</structfield></entry>
<entry>Pad at the target of this link.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>flags</structfield></entry>
<entry>Link flags, see <xref linkend="media-link-flag" /> for more details.</entry>
</row>
</tbody>
</tgroup>
</table>
<table frame="none" pgwide="1" id="media-link-flag">
<title>Media link flags</title>
<tgroup cols="2">
<colspec colname="c1"/>
<colspec colname="c2"/>
<tbody valign="top">
<row>
<entry><constant>MEDIA_LNK_FL_ENABLED</constant></entry>
<entry>The link is enabled and can be used to transfer media data.
When two or more links target a sink pad, only one of them can be
enabled at a time.</entry>
</row>
<row>
<entry><constant>MEDIA_LNK_FL_IMMUTABLE</constant></entry>
<entry>The link enabled state can't be modified at runtime. An
immutable link is always enabled.</entry>
</row>
<row>
<entry><constant>MEDIA_LNK_FL_DYNAMIC</constant></entry>
<entry>The link enabled state can be modified during streaming. This
flag is set by drivers and is read-only for applications.</entry>
</row>
</tbody>
</tgroup>
</table>
<para>One and only one of <constant>MEDIA_PAD_FL_SINK</constant> and
<constant>MEDIA_PAD_FL_SOURCE</constant> must be set for every pad.</para>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The &media-links-enum; <structfield>id</structfield> references
a non-existing entity.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>
Documentation/DocBook/v4l/media-ioc-setup-link.xml 0 → 100644
浏览文件 @ 6288cf1e
<refentry id="media-ioc-setup-link">
<refmeta>
<refentrytitle>ioctl MEDIA_IOC_SETUP_LINK</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>MEDIA_IOC_SETUP_LINK</refname>
<refpurpose>Modify the properties of a link</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 media_link_desc *<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>File descriptor returned by
<link linkend='media-func-open'><function>open()</function></link>.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>MEDIA_IOC_SETUP_LINK</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>To change link properties applications fill a &media-link-desc; with
link identification information (source and sink pad) and the new requested
link flags. They then call the MEDIA_IOC_SETUP_LINK ioctl with a pointer to
that structure.</para>
<para>The only configurable property is the <constant>ENABLED</constant>
link flag to enable/disable a link. Links marked with the
<constant>IMMUTABLE</constant> link flag can not be enabled or disabled.
</para>
<para>Link configuration has no side effect on other links. If an enabled
link at the sink pad prevents the link from being enabled, the driver
returns with an &EBUSY;.</para>
<para>Only links marked with the <constant>DYNAMIC</constant> link flag can
be enabled/disabled while streaming media data. Attempting to enable or
disable a streaming non-dynamic link will return an &EBUSY;.</para>
<para>If the specified link can't be found the driver returns with an
&EINVAL;.</para>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>EBUSY</errorcode></term>
<listitem>
<para>The link properties can't be changed because the link is
currently busy. This can be caused, for instance, by an active media
stream (audio or video) on the link. The ioctl shouldn't be retried if
no other action is performed before to fix the problem.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The &media-link-desc; references a non-existing link, or the
link is immutable and an attempt to modify its configuration was made.
</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>
Documentation/DocBook/v4l/pixfmt-nv12m.xml 0 → 100644
浏览文件 @ 6288cf1e
<refentry id="V4L2-PIX-FMT-NV12M">
<refmeta>
<refentrytitle>V4L2_PIX_FMT_NV12M ('NV12M')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname> <constant>V4L2_PIX_FMT_NV12M</constant></refname>
<refpurpose>Variation of <constant>V4L2_PIX_FMT_NV12</constant> with planes
non contiguous in memory. </refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a multi-planar, two-plane version of the YUV 4:2:0 format.
The three components are separated into two sub-images or planes.
<constant>V4L2_PIX_FMT_NV12M</constant> differs from <constant>V4L2_PIX_FMT_NV12
</constant> in that the two planes are non-contiguous in memory, i.e. the chroma
plane do not necessarily immediately follows the luma plane.
The luminance data occupies the first plane. The Y plane has one byte per pixel.
In the second plane there is a chrominance data with alternating chroma samples.
The CbCr plane is the same width, in bytes, as the Y plane (and of the image),
but is half as tall in pixels. Each CbCr pair belongs to four pixels. For example,
Cb<subscript>0</subscript>/Cr<subscript>0</subscript> belongs to
Y'<subscript>00</subscript>, Y'<subscript>01</subscript>,
Y'<subscript>10</subscript>, Y'<subscript>11</subscript>. </para>
<para><constant>V4L2_PIX_FMT_NV12M</constant> is intended to be
used only in drivers and applications that support the multi-planar API,
described in <xref linkend="planar-apis"/>. </para>
<para>If the Y plane has pad bytes after each row, then the
CbCr plane has as many pad bytes after its rows.</para>
<example>
<title><constant>V4L2_PIX_FMT_NV12M</constant> 4 &times; 4 pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="5" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start0&nbsp;+&nbsp;0:</entry>
<entry>Y'<subscript>00</subscript></entry>
<entry>Y'<subscript>01</subscript></entry>
<entry>Y'<subscript>02</subscript></entry>
<entry>Y'<subscript>03</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;4:</entry>
<entry>Y'<subscript>10</subscript></entry>
<entry>Y'<subscript>11</subscript></entry>
<entry>Y'<subscript>12</subscript></entry>
<entry>Y'<subscript>13</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;8:</entry>
<entry>Y'<subscript>20</subscript></entry>
<entry>Y'<subscript>21</subscript></entry>
<entry>Y'<subscript>22</subscript></entry>
<entry>Y'<subscript>23</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;12:</entry>
<entry>Y'<subscript>30</subscript></entry>
<entry>Y'<subscript>31</subscript></entry>
<entry>Y'<subscript>32</subscript></entry>
<entry>Y'<subscript>33</subscript></entry>
</row>
<row>
<entry></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;0:</entry>
<entry>Cb<subscript>00</subscript></entry>
<entry>Cr<subscript>00</subscript></entry>
<entry>Cb<subscript>01</subscript></entry>
<entry>Cr<subscript>01</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;4:</entry>
<entry>Cb<subscript>10</subscript></entry>
<entry>Cr<subscript>10</subscript></entry>
<entry>Cb<subscript>11</subscript></entry>
<entry>Cr<subscript>11</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
<formalpara>
<title>Color Sample Location.</title>
<para>
<informaltable frame="none">
<tgroup cols="7" align="center">
<tbody valign="top">
<row>
<entry></entry>
<entry>0</entry><entry></entry><entry>1</entry><entry></entry>
<entry>2</entry><entry></entry><entry>3</entry>
</row>
<row>
<entry>0</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
<entry></entry><entry>C</entry><entry></entry><entry></entry>
<entry></entry><entry>C</entry><entry></entry>
</row>
<row>
<entry>1</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
</row>
<row>
<entry>2</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
<entry></entry><entry>C</entry><entry></entry><entry></entry>
<entry></entry><entry>C</entry><entry></entry>
</row>
<row>
<entry>3</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "pixfmt.sgml"
indent-tabs-mode: nil
End:
-->
Documentation/DocBook/v4l/pixfmt-nv12mt.xml 0 → 100644
浏览文件 @ 6288cf1e
<refentry>
<refmeta>
<refentrytitle>V4L2_PIX_FMT_NV12MT ('TM12')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname id="V4L2-PIX-FMT-NV12MT"><constant>V4L2_PIX_FMT_NV12MT
</constant></refname>
<refpurpose>Formats with &frac12; horizontal and vertical
chroma resolution. This format has two planes - one for luminance and one for
chrominance. Chroma samples are interleaved. The difference to
<constant>V4L2_PIX_FMT_NV12</constant> is the memory layout. Pixels are
grouped in macroblocks of 64x32 size. The order of macroblocks in memory is
also not standard.
</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is the two-plane versions of the YUV 4:2:0 format where data
is grouped into 64x32 macroblocks. The three components are separated into two
sub-images or planes. The Y plane has one byte per pixel and pixels are grouped
into 64x32 macroblocks. The CbCr plane has the same width, in bytes, as the Y
plane (and the image), but is half as tall in pixels. The chroma plane is also
grouped into 64x32 macroblocks.</para>
<para>Width of the buffer has to be aligned to the multiple of 128, and
height alignment is 32. Every four adjactent buffers - two horizontally and two
vertically are grouped together and are located in memory in Z or flipped Z
order. </para>
<para>Layout of macroblocks in memory is presented in the following
figure.</para>
<para><figure id="nv12mt">
<title><constant>V4L2_PIX_FMT_NV12MT</constant> macroblock Z shape
memory layout</title>
<mediaobject>
<imageobject>
<imagedata fileref="nv12mt.gif" format="GIF" />
</imageobject>
</mediaobject>
</figure>
The requirement that width is multiple of 128 is implemented because,
the Z shape cannot be cut in half horizontally. In case the vertical resolution
of macroblocks is odd then the last row of macroblocks is arranged in a linear
order. </para>
<para>In case of chroma the layout is identical. Cb and Cr samples are
interleaved. Height of the buffer is aligned to 32.
</para>
<example>
<title>Memory layout of macroblocks in <constant>V4L2_PIX_FMT_NV12
</constant> format pixel image - extreme case</title>
<para>
<figure id="nv12mt_ex">
<title>Example <constant>V4L2_PIX_FMT_NV12MT</constant> memory
layout of macroblocks</title>
<mediaobject>
<imageobject>
<imagedata fileref="nv12mt_example.gif" format="GIF" />
</imageobject>
</mediaobject>
</figure>
Memory layout of macroblocks of <constant>V4L2_PIX_FMT_NV12MT
</constant> format in most extreme case.
</para>
</example>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "pixfmt.sgml"
indent-tabs-mode: nil
End:
-->
Documentation/DocBook/v4l/pixfmt-srggb12.xml 0 → 100644
浏览文件 @ 6288cf1e
<refentry>
<refmeta>
<refentrytitle>V4L2_PIX_FMT_SRGGB12 ('RG12'),
V4L2_PIX_FMT_SGRBG12 ('BA12'),
V4L2_PIX_FMT_SGBRG12 ('GB12'),
V4L2_PIX_FMT_SBGGR12 ('BG12'),
</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname id="V4L2-PIX-FMT-SRGGB12"><constant>V4L2_PIX_FMT_SRGGB12</constant></refname>
<refname id="V4L2-PIX-FMT-SGRBG12"><constant>V4L2_PIX_FMT_SGRBG12</constant></refname>
<refname id="V4L2-PIX-FMT-SGBRG12"><constant>V4L2_PIX_FMT_SGBRG12</constant></refname>
<refname id="V4L2-PIX-FMT-SBGGR12"><constant>V4L2_PIX_FMT_SBGGR12</constant></refname>
<refpurpose>12-bit Bayer formats expanded to 16 bits</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>The following four pixel formats are raw sRGB / Bayer formats with
12 bits per colour. Each colour component is stored in a 16-bit word, with 6
unused high bits filled with zeros. Each n-pixel row contains n/2 green samples
and n/2 blue or red samples, with alternating red and blue rows. Bytes are
stored in memory in little endian order. They are conventionally described
as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of these
formats</para>
<example>
<title><constant>V4L2_PIX_FMT_SBGGR12</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte, high 6 bits in high bytes are 0.
<informaltable frame="none">
<tgroup cols="5" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start&nbsp;+&nbsp;0:</entry>
<entry>B<subscript>00low</subscript></entry>
<entry>B<subscript>00high</subscript></entry>
<entry>G<subscript>01low</subscript></entry>
<entry>G<subscript>01high</subscript></entry>
<entry>B<subscript>02low</subscript></entry>
<entry>B<subscript>02high</subscript></entry>
<entry>G<subscript>03low</subscript></entry>
<entry>G<subscript>03high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;8:</entry>
<entry>G<subscript>10low</subscript></entry>
<entry>G<subscript>10high</subscript></entry>
<entry>R<subscript>11low</subscript></entry>
<entry>R<subscript>11high</subscript></entry>
<entry>G<subscript>12low</subscript></entry>
<entry>G<subscript>12high</subscript></entry>
<entry>R<subscript>13low</subscript></entry>
<entry>R<subscript>13high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;16:</entry>
<entry>B<subscript>20low</subscript></entry>
<entry>B<subscript>20high</subscript></entry>
<entry>G<subscript>21low</subscript></entry>
<entry>G<subscript>21high</subscript></entry>
<entry>B<subscript>22low</subscript></entry>
<entry>B<subscript>22high</subscript></entry>
<entry>G<subscript>23low</subscript></entry>
<entry>G<subscript>23high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;24:</entry>
<entry>G<subscript>30low</subscript></entry>
<entry>G<subscript>30high</subscript></entry>
<entry>R<subscript>31low</subscript></entry>
<entry>R<subscript>31high</subscript></entry>
<entry>G<subscript>32low</subscript></entry>
<entry>G<subscript>32high</subscript></entry>
<entry>R<subscript>33low</subscript></entry>
<entry>R<subscript>33high</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>
Documentation/DocBook/v4l/pixfmt-y12.xml 0 → 100644
浏览文件 @ 6288cf1e
<refentry id="V4L2-PIX-FMT-Y12">
<refmeta>
<refentrytitle>V4L2_PIX_FMT_Y12 ('Y12 ')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname><constant>V4L2_PIX_FMT_Y12</constant></refname>
<refpurpose>Grey-scale image</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a grey-scale image with a depth of 12 bits per pixel. Pixels
are stored in 16-bit words with unused high bits padded with 0. The least
significant byte is stored at lower memory addresses (little-endian).</para>
<example>
<title><constant>V4L2_PIX_FMT_Y12</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="9" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start&nbsp;+&nbsp;0:</entry>
<entry>Y'<subscript>00low</subscript></entry>
<entry>Y'<subscript>00high</subscript></entry>
<entry>Y'<subscript>01low</subscript></entry>
<entry>Y'<subscript>01high</subscript></entry>
<entry>Y'<subscript>02low</subscript></entry>
<entry>Y'<subscript>02high</subscript></entry>
<entry>Y'<subscript>03low</subscript></entry>
<entry>Y'<subscript>03high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;8:</entry>
<entry>Y'<subscript>10low</subscript></entry>
<entry>Y'<subscript>10high</subscript></entry>
<entry>Y'<subscript>11low</subscript></entry>
<entry>Y'<subscript>11high</subscript></entry>
<entry>Y'<subscript>12low</subscript></entry>
<entry>Y'<subscript>12high</subscript></entry>
<entry>Y'<subscript>13low</subscript></entry>
<entry>Y'<subscript>13high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;16:</entry>
<entry>Y'<subscript>20low</subscript></entry>
<entry>Y'<subscript>20high</subscript></entry>
<entry>Y'<subscript>21low</subscript></entry>
<entry>Y'<subscript>21high</subscript></entry>
<entry>Y'<subscript>22low</subscript></entry>
<entry>Y'<subscript>22high</subscript></entry>
<entry>Y'<subscript>23low</subscript></entry>
<entry>Y'<subscript>23high</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;24:</entry>
<entry>Y'<subscript>30low</subscript></entry>
<entry>Y'<subscript>30high</subscript></entry>
<entry>Y'<subscript>31low</subscript></entry>
<entry>Y'<subscript>31high</subscript></entry>
<entry>Y'<subscript>32low</subscript></entry>
<entry>Y'<subscript>32high</subscript></entry>
<entry>Y'<subscript>33low</subscript></entry>
<entry>Y'<subscript>33high</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>
Documentation/DocBook/v4l/pixfmt-yuv420m.xml 0 → 100644
浏览文件 @ 6288cf1e
<refentry id="V4L2-PIX-FMT-YUV420M">
<refmeta>
<refentrytitle>V4L2_PIX_FMT_YUV420M ('YU12M')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname> <constant>V4L2_PIX_FMT_YUV420M</constant></refname>
<refpurpose>Variation of <constant>V4L2_PIX_FMT_YUV420</constant>
with planes non contiguous in memory. </refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>This is a multi-planar format, as opposed to a packed format.
The three components are separated into three sub- images or planes.
The Y plane is first. The Y plane has one byte per pixel. The Cb data
constitutes the second plane which is half the width and half
the height of the Y plane (and of the image). Each Cb belongs to four
pixels, a two-by-two square of the image. For example,
Cb<subscript>0</subscript> belongs to Y'<subscript>00</subscript>,
Y'<subscript>01</subscript>, Y'<subscript>10</subscript>, and
Y'<subscript>11</subscript>. The Cr data, just like the Cb plane, is
in the third plane. </para>
<para>If the Y plane has pad bytes after each row, then the Cb
and Cr planes have half as many pad bytes after their rows. In other
words, two Cx rows (including padding) is exactly as long as one Y row
(including padding).</para>
<para><constant>V4L2_PIX_FMT_NV12M</constant> is intended to be
used only in drivers and applications that support the multi-planar API,
described in <xref linkend="planar-apis"/>. </para>
<example>
<title><constant>V4L2_PIX_FMT_YVU420M</constant> 4 &times; 4
pixel image</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="5" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start0&nbsp;+&nbsp;0:</entry>
<entry>Y'<subscript>00</subscript></entry>
<entry>Y'<subscript>01</subscript></entry>
<entry>Y'<subscript>02</subscript></entry>
<entry>Y'<subscript>03</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;4:</entry>
<entry>Y'<subscript>10</subscript></entry>
<entry>Y'<subscript>11</subscript></entry>
<entry>Y'<subscript>12</subscript></entry>
<entry>Y'<subscript>13</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;8:</entry>
<entry>Y'<subscript>20</subscript></entry>
<entry>Y'<subscript>21</subscript></entry>
<entry>Y'<subscript>22</subscript></entry>
<entry>Y'<subscript>23</subscript></entry>
</row>
<row>
<entry>start0&nbsp;+&nbsp;12:</entry>
<entry>Y'<subscript>30</subscript></entry>
<entry>Y'<subscript>31</subscript></entry>
<entry>Y'<subscript>32</subscript></entry>
<entry>Y'<subscript>33</subscript></entry>
</row>
<row><entry></entry></row>
<row>
<entry>start1&nbsp;+&nbsp;0:</entry>
<entry>Cb<subscript>00</subscript></entry>
<entry>Cb<subscript>01</subscript></entry>
</row>
<row>
<entry>start1&nbsp;+&nbsp;2:</entry>
<entry>Cb<subscript>10</subscript></entry>
<entry>Cb<subscript>11</subscript></entry>
</row>
<row><entry></entry></row>
<row>
<entry>start2&nbsp;+&nbsp;0:</entry>
<entry>Cr<subscript>00</subscript></entry>
<entry>Cr<subscript>01</subscript></entry>
</row>
<row>
<entry>start2&nbsp;+&nbsp;2:</entry>
<entry>Cr<subscript>10</subscript></entry>
<entry>Cr<subscript>11</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
<formalpara>
<title>Color Sample Location.</title>
<para>
<informaltable frame="none">
<tgroup cols="7" align="center">
<tbody valign="top">
<row>
<entry></entry>
<entry>0</entry><entry></entry><entry>1</entry><entry></entry>
<entry>2</entry><entry></entry><entry>3</entry>
</row>
<row>
<entry>0</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
<entry></entry><entry>C</entry><entry></entry><entry></entry>
<entry></entry><entry>C</entry><entry></entry>
</row>
<row>
<entry>1</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
</row>
<row>
<entry>2</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
<row>
<entry></entry>
<entry></entry><entry>C</entry><entry></entry><entry></entry>
<entry></entry><entry>C</entry><entry></entry>
</row>
<row>
<entry>3</entry>
<entry>Y</entry><entry></entry><entry>Y</entry><entry></entry>
<entry>Y</entry><entry></entry><entry>Y</entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "pixfmt.sgml"
indent-tabs-mode: nil
End:
-->
Documentation/DocBook/v4l/pixfmt.xml
浏览文件 @ 6288cf1e
......@@ -2,12 +2,16 @@
<para>The V4L2 API was primarily designed for devices exchanging
image data with applications. The
<structname>v4l2_pix_format</structname> structure defines the format
and layout of an image in memory. Image formats are negotiated with
the &VIDIOC-S-FMT; ioctl. (The explanations here focus on video
<structname>v4l2_pix_format</structname> and <structname>v4l2_pix_format_mplane
</structname> structures define the format and layout of an image in memory.
The former is used with the single-planar API, while the latter is used with the
multi-planar version (see <xref linkend="planar-apis"/>). Image formats are
negotiated with the &VIDIOC-S-FMT; ioctl. (The explanations here focus on video
capturing and output, for overlay frame buffer formats see also
&VIDIOC-G-FBUF;.)</para>
<section>
<title>Single-planar format structure</title>
<table pgwide="1" frame="none" id="v4l2-pix-format">
<title>struct <structname>v4l2_pix_format</structname></title>
<tgroup cols="3">
......@@ -106,6 +110,98 @@ set this field to zero.</entry>
</tbody>
</tgroup>
</table>
</section>
<section>
<title>Multi-planar format structures</title>
<para>The <structname>v4l2_plane_pix_format</structname> structures define
size and layout for each of the planes in a multi-planar format.
The <structname>v4l2_pix_format_mplane</structname> structure contains
information common to all planes (such as image width and height) and
an array of <structname>v4l2_plane_pix_format</structname> structures,
describing all planes of that format.</para>
<table pgwide="1" frame="none" id="v4l2-plane-pix-format">
<title>struct <structname>vl42_plane_pix_format</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>sizeimage</structfield></entry>
<entry>Maximum size in bytes required for image data in this plane.
</entry>
</row>
<row>
<entry>__u16</entry>
<entry><structfield>bytesperline</structfield></entry>
<entry>Distance in bytes between the leftmost pixels in two adjacent
lines.</entry>
</row>
<row>
<entry>__u16</entry>
<entry><structfield>reserved[7]</structfield></entry>
<entry>Reserved for future extensions. Should be zeroed by the
application.</entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="v4l2-pix-format-mplane">
<title>struct <structname>v4l2_pix_format_mplane</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>width</structfield></entry>
<entry>Image width in pixels.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>height</structfield></entry>
<entry>Image height in pixels.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>pixelformat</structfield></entry>
<entry>The pixel format. Both single- and multi-planar four character
codes can be used.</entry>
</row>
<row>
<entry>&v4l2-field;</entry>
<entry><structfield>field</structfield></entry>
<entry>See &v4l2-pix-format;.</entry>
</row>
<row>
<entry>&v4l2-colorspace;</entry>
<entry><structfield>colorspace</structfield></entry>
<entry>See &v4l2-pix-format;.</entry>
</row>
<row>
<entry>&v4l2-plane-pix-format;</entry>
<entry><structfield>plane_fmt[VIDEO_MAX_PLANES]</structfield></entry>
<entry>An array of structures describing format of each plane this
pixel format consists of. The number of valid entries in this array
has to be put in the <structfield>num_planes</structfield>
field.</entry>
</row>
<row>
<entry>__u8</entry>
<entry><structfield>num_planes</structfield></entry>
<entry>Number of planes (i.e. separate memory buffers) for this format
and the number of valid entries in the
<structfield>plane_fmt</structfield> array.</entry>
</row>
<row>
<entry>__u8</entry>
<entry><structfield>reserved[11]</structfield></entry>
<entry>Reserved for future extensions. Should be zeroed by the
application.</entry>
</row>
</tbody>
</tgroup>
</table>
</section>
<section>
<title>Standard Image Formats</title>
......@@ -142,11 +238,19 @@ leftmost pixel of the second row from the top, and so on. The last row
has just as many pad bytes after it as the other rows.</para>
<para>In V4L2 each format has an identifier which looks like
<constant>PIX_FMT_XXX</constant>, defined in the <filename>videodev2.h</filename>
header file. These identifiers
represent <link linkend="v4l2-fourcc">four character codes</link>
<constant>PIX_FMT_XXX</constant>, defined in the <link
linkend="videodev">videodev.h</link> header file. These identifiers
represent <link linkend="v4l2-fourcc">four character (FourCC) codes</link>
which are also listed below, however they are not the same as those
used in the Windows world.</para>
<para>For some formats, data is stored in separate, discontiguous
memory buffers. Those formats are identified by a separate set of FourCC codes
and are referred to as "multi-planar formats". For example, a YUV422 frame is
normally stored in one memory buffer, but it can also be placed in two or three
separate buffers, with Y component in one buffer and CbCr components in another
in the 2-planar version or with each component in its own buffer in the
3-planar case. Those sub-buffers are referred to as "planes".</para>
</section>
<section id="colorspaces">
......@@ -592,6 +696,7 @@ information.</para>
&sub-packed-yuv;
&sub-grey;
&sub-y10;
&sub-y12;
&sub-y16;
&sub-yuyv;
&sub-uyvy;
......@@ -599,10 +704,13 @@ information.</para>
&sub-vyuy;
&sub-y41p;
&sub-yuv420;
&sub-yuv420m;
&sub-yuv410;
&sub-yuv422p;
&sub-yuv411p;
&sub-nv12;
&sub-nv12m;
&sub-nv12mt;
&sub-nv16;
</section>
......
Documentation/DocBook/v4l/planar-apis.xml 0 → 100644
浏览文件 @ 6288cf1e
<section id="planar-apis">
<title>Single- and multi-planar APIs</title>
<para>Some devices require data for each input or output video frame
to be placed in discontiguous memory buffers. In such cases, one
video frame has to be addressed using more than one memory address, i.e. one
pointer per "plane". A plane is a sub-buffer of the current frame. For
examples of such formats see <xref linkend="pixfmt" />.</para>
<para>Initially, V4L2 API did not support multi-planar buffers and a set of
extensions has been introduced to handle them. Those extensions constitute
what is being referred to as the "multi-planar API".</para>
<para>Some of the V4L2 API calls and structures are interpreted differently,
depending on whether single- or multi-planar API is being used. An application
can choose whether to use one or the other by passing a corresponding buffer
type to its ioctl calls. Multi-planar versions of buffer types are suffixed
with an `_MPLANE' string. For a list of available multi-planar buffer types
see &v4l2-buf-type;.
</para>
<section>
<title>Multi-planar formats</title>
<para>Multi-planar API introduces new multi-planar formats. Those formats
use a separate set of FourCC codes. It is important to distinguish between
the multi-planar API and a multi-planar format. Multi-planar API calls can
handle all single-planar formats as well (as long as they are passed in
multi-planar API structures), while the single-planar API cannot
handle multi-planar formats.</para>
</section>
<section>
<title>Calls that distinguish between single and multi-planar APIs</title>
<variablelist>
<varlistentry>
<term>&VIDIOC-QUERYCAP;</term>
<listitem><para>Two additional multi-planar capabilities are added. They can
be set together with non-multi-planar ones for devices that handle
both single- and multi-planar formats.</para></listitem>
</varlistentry>
<varlistentry>
<term>&VIDIOC-G-FMT;, &VIDIOC-S-FMT;, &VIDIOC-TRY-FMT;</term>
<listitem><para>New structures for describing multi-planar formats are added:
&v4l2-pix-format-mplane; and &v4l2-plane-pix-format;. Drivers may
define new multi-planar formats, which have distinct FourCC codes from
the existing single-planar ones.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>&VIDIOC-QBUF;, &VIDIOC-DQBUF;, &VIDIOC-QUERYBUF;</term>
<listitem><para>A new &v4l2-plane; structure for describing planes is added.
Arrays of this structure are passed in the new
<structfield>m.planes</structfield> field of &v4l2-buffer;.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>&VIDIOC-REQBUFS;</term>
<listitem><para>Will allocate multi-planar buffers as requested.</para></listitem>
</varlistentry>
</variablelist>
</section>
</section>
Documentation/DocBook/v4l/remote_controllers.xml
浏览文件 @ 6288cf1e
......@@ -133,7 +133,7 @@ different IR's. Due to that, V4L2 API now specifies a standard for mapping Media
<row><entry><constant>KEY_LEFT</constant></entry><entry>Left key</entry><entry>LEFT</entry></row>
<row><entry><constant>KEY_RIGHT</constant></entry><entry>Right key</entry><entry>RIGHT</entry></row>
<row><entry><emphasis role="bold">Miscelaneous keys</emphasis></entry></row>
<row><entry><emphasis role="bold">Miscellaneous keys</emphasis></entry></row>
<row><entry><constant>KEY_DOT</constant></entry><entry>Return a dot</entry><entry>.</entry></row>
<row><entry><constant>KEY_FN</constant></entry><entry>Select a function</entry><entry>FUNCTION</entry></row>
......
Documentation/DocBook/v4l/subdev-formats.xml 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/DocBook/v4l/v4l2.xml
浏览文件 @ 6288cf1e
......@@ -85,6 +85,17 @@ Remote Controller chapter.</contrib>
</address>
</affiliation>
</author>
<author>
<firstname>Pawel</firstname>
<surname>Osciak</surname>
<contrib>Designed and documented the multi-planar API.</contrib>
<affiliation>
<address>
<email>pawel AT osciak.com</email>
</address>
</affiliation>
</author>
</authorgroup>
<copyright>
......@@ -102,7 +113,8 @@ Remote Controller chapter.</contrib>
<year>2010</year>
<year>2011</year>
<holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin
Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab</holder>
Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab,
Pawel Osciak</holder>
</copyright>
<legalnotice>
<para>Except when explicitly stated as GPL, programming examples within
......@@ -115,6 +127,13 @@ structs, ioctls) must be noted in more detail in the history chapter
(compat.xml), along with the possible impact on existing drivers and
applications. -->
<revision>
<revnumber>2.6.39</revnumber>
<date>2011-03-01</date>
<authorinitials>mcc, po</authorinitials>
<revremark>Removed VIDIOC_*_OLD from videodev2.h header and update it to reflect latest changes. Added the <link linkend="planar-apis">multi-planar API</link>.</revremark>
</revision>
<revision>
<revnumber>2.6.37</revnumber>
<date>2010-08-06</date>
......@@ -382,7 +401,7 @@ and discussions on the V4L mailing list.</revremark>
</partinfo>
<title>Video for Linux Two API Specification</title>
<subtitle>Revision 2.6.38</subtitle>
<subtitle>Revision 2.6.39</subtitle>
<chapter id="common">
&sub-common;
......@@ -411,6 +430,7 @@ and discussions on the V4L mailing list.</revremark>
<section id="radio"> &sub-dev-radio; </section>
<section id="rds"> &sub-dev-rds; </section>
<section id="event"> &sub-dev-event; </section>
<section id="subdev"> &sub-dev-subdev; </section>
</chapter>
<chapter id="driver">
......@@ -478,6 +498,12 @@ and discussions on the V4L mailing list.</revremark>
&sub-reqbufs;
&sub-s-hw-freq-seek;
&sub-streamon;
&sub-subdev-enum-frame-interval;
&sub-subdev-enum-frame-size;
&sub-subdev-enum-mbus-code;
&sub-subdev-g-crop;
&sub-subdev-g-fmt;
&sub-subdev-g-frame-interval;
&sub-subscribe-event;
<!-- End of ioctls. -->
&sub-mmap;
......
Documentation/DocBook/v4l/videodev2.h.xml
浏览文件 @ 6288cf1e
......@@ -71,6 +71,7 @@
* Moved from videodev.h
*/
#define VIDEO_MAX_FRAME 32
#define VIDEO_MAX_PLANES 8
#ifndef __KERNEL__
......@@ -158,9 +159,23 @@ enum <link linkend="v4l2-buf-type">v4l2_buf_type</link> {
/* Experimental */
V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY = 8,
#endif
V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE = 9,
V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE = 10,
V4L2_BUF_TYPE_PRIVATE = 0x80,
};
#define V4L2_TYPE_IS_MULTIPLANAR(type) \
((type) == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE \
|| (type) == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
#define V4L2_TYPE_IS_OUTPUT(type) \
((type) == V4L2_BUF_TYPE_VIDEO_OUTPUT \
|| (type) == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE \
|| (type) == V4L2_BUF_TYPE_VIDEO_OVERLAY \
|| (type) == V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY \
|| (type) == V4L2_BUF_TYPE_VBI_OUTPUT \
|| (type) == V4L2_BUF_TYPE_SLICED_VBI_OUTPUT)
enum <link linkend="v4l2-tuner-type">v4l2_tuner_type</link> {
V4L2_TUNER_RADIO = 1,
V4L2_TUNER_ANALOG_TV = 2,
......@@ -246,6 +261,11 @@ struct <link linkend="v4l2-capability">v4l2_capability</link> {
#define V4L2_CAP_HW_FREQ_SEEK 0x00000400 /* Can do hardware frequency seek */
#define V4L2_CAP_RDS_OUTPUT 0x00000800 /* Is an RDS encoder */
/* Is a video capture device that supports multiplanar formats */
#define V4L2_CAP_VIDEO_CAPTURE_MPLANE 0x00001000
/* Is a video output device that supports multiplanar formats */
#define V4L2_CAP_VIDEO_OUTPUT_MPLANE 0x00002000
#define V4L2_CAP_TUNER 0x00010000 /* has a tuner */
#define V4L2_CAP_AUDIO 0x00020000 /* has audio support */
#define V4L2_CAP_RADIO 0x00040000 /* is a radio device */
......@@ -320,6 +340,13 @@ struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> {
#define <link linkend="V4L2-PIX-FMT-NV16">V4L2_PIX_FMT_NV16</link> v4l2_fourcc('N', 'V', '1', '6') /* 16 Y/CbCr 4:2:2 */
#define <link linkend="V4L2-PIX-FMT-NV61">V4L2_PIX_FMT_NV61</link> v4l2_fourcc('N', 'V', '6', '1') /* 16 Y/CrCb 4:2:2 */
/* two non contiguous planes - one Y, one Cr + Cb interleaved */
#define <link linkend="V4L2-PIX-FMT-NV12M">V4L2_PIX_FMT_NV12M</link> v4l2_fourcc('N', 'M', '1', '2') /* 12 Y/CbCr 4:2:0 */
#define <link linkend="V4L2-PIX-FMT-NV12MT">V4L2_PIX_FMT_NV12MT</link> v4l2_fourcc('T', 'M', '1', '2') /* 12 Y/CbCr 4:2:0 64x32 macroblocks */
/* three non contiguous planes - Y, Cb, Cr */
#define <link linkend="V4L2-PIX-FMT-YUV420M">V4L2_PIX_FMT_YUV420M</link> v4l2_fourcc('Y', 'M', '1', '2') /* 12 YUV420 planar */
/* Bayer formats - see http://www.siliconimaging.com/RGB%20Bayer.htm */
#define <link linkend="V4L2-PIX-FMT-SBGGR8">V4L2_PIX_FMT_SBGGR8</link> v4l2_fourcc('B', 'A', '8', '1') /* 8 BGBG.. GRGR.. */
#define <link linkend="V4L2-PIX-FMT-SGBRG8">V4L2_PIX_FMT_SGBRG8</link> v4l2_fourcc('G', 'B', 'R', 'G') /* 8 GBGB.. RGRG.. */
......@@ -518,6 +545,62 @@ struct <link linkend="v4l2-requestbuffers">v4l2_requestbuffers</link> {
__u32 reserved[2];
};
/**
* struct <link linkend="v4l2-plane">v4l2_plane</link> - plane info for multi-planar buffers
* @bytesused: number of bytes occupied by data in the plane (payload)
* @length: size of this plane (NOT the payload) in bytes
* @mem_offset: when memory in the associated struct <link linkend="v4l2-buffer">v4l2_buffer</link> is
* V4L2_MEMORY_MMAP, equals the offset from the start of
* the device memory for this plane (or is a "cookie" that
* should be passed to mmap() called on the video node)
* @userptr: when memory is V4L2_MEMORY_USERPTR, a userspace pointer
* pointing to this plane
* @data_offset: offset in the plane to the start of data; usually 0,
* unless there is a header in front of the data
*
* Multi-planar buffers consist of one or more planes, e.g. an YCbCr buffer
* with two planes can have one plane for Y, and another for interleaved CbCr
* components. Each plane can reside in a separate memory buffer, or even in
* a completely separate memory node (e.g. in embedded devices).
*/
struct <link linkend="v4l2-plane">v4l2_plane</link> {
__u32 bytesused;
__u32 length;
union {
__u32 mem_offset;
unsigned long userptr;
} m;
__u32 data_offset;
__u32 reserved[11];
};
/**
* struct <link linkend="v4l2-buffer">v4l2_buffer</link> - video buffer info
* @index: id number of the buffer
* @type: buffer type (type == *_MPLANE for multiplanar buffers)
* @bytesused: number of bytes occupied by data in the buffer (payload);
* unused (set to 0) for multiplanar buffers
* @flags: buffer informational flags
* @field: field order of the image in the buffer
* @timestamp: frame timestamp
* @timecode: frame timecode
* @sequence: sequence count of this frame
* @memory: the method, in which the actual video data is passed
* @offset: for non-multiplanar buffers with memory == V4L2_MEMORY_MMAP;
* offset from the start of the device memory for this plane,
* (or a "cookie" that should be passed to mmap() as offset)
* @userptr: for non-multiplanar buffers with memory == V4L2_MEMORY_USERPTR;
* a userspace pointer pointing to this buffer
* @planes: for multiplanar buffers; userspace pointer to the array of plane
* info structs for this buffer
* @length: size in bytes of the buffer (NOT its payload) for single-plane
* buffers (when type != *_MPLANE); number of elements in the
* planes array for multi-plane buffers
* @input: input number from which the video data has has been captured
*
* Contains data exchanged by application and driver using one of the Streaming
* I/O methods.
*/
struct <link linkend="v4l2-buffer">v4l2_buffer</link> {
__u32 index;
enum <link linkend="v4l2-buf-type">v4l2_buf_type</link> type;
......@@ -533,6 +616,7 @@ struct <link linkend="v4l2-buffer">v4l2_buffer</link> {
union {
__u32 offset;
unsigned long userptr;
struct <link linkend="v4l2-plane">v4l2_plane</link> *planes;
} m;
__u32 length;
__u32 input;
......@@ -1623,12 +1707,56 @@ struct <link linkend="v4l2-mpeg-vbi-fmt-ivtv">v4l2_mpeg_vbi_fmt_ivtv</link> {
* A G G R E G A T E S T R U C T U R E S
*/
/* Stream data format
/**
* struct <link linkend="v4l2-plane-pix-format">v4l2_plane_pix_format</link> - additional, per-plane format definition
* @sizeimage: maximum size in bytes required for data, for which
* this plane will be used
* @bytesperline: distance in bytes between the leftmost pixels in two
* adjacent lines
*/
struct <link linkend="v4l2-plane-pix-format">v4l2_plane_pix_format</link> {
__u32 sizeimage;
__u16 bytesperline;
__u16 reserved[7];
} __attribute__ ((packed));
/**
* struct <link linkend="v4l2-pix-format-mplane">v4l2_pix_format_mplane</link> - multiplanar format definition
* @width: image width in pixels
* @height: image height in pixels
* @pixelformat: little endian four character code (fourcc)
* @field: field order (for interlaced video)
* @colorspace: supplemental to pixelformat
* @plane_fmt: per-plane information
* @num_planes: number of planes for this format
*/
struct <link linkend="v4l2-pix-format-mplane">v4l2_pix_format_mplane</link> {
__u32 width;
__u32 height;
__u32 pixelformat;
enum <link linkend="v4l2-field">v4l2_field</link> field;
enum <link linkend="v4l2-colorspace">v4l2_colorspace</link> colorspace;
struct <link linkend="v4l2-plane-pix-format">v4l2_plane_pix_format</link> plane_fmt[VIDEO_MAX_PLANES];
__u8 num_planes;
__u8 reserved[11];
} __attribute__ ((packed));
/**
* struct <link linkend="v4l2-format">v4l2_format</link> - stream data format
* @type: type of the data stream
* @pix: definition of an image format
* @pix_mp: definition of a multiplanar image format
* @win: definition of an overlaid image
* @vbi: raw VBI capture or output parameters
* @sliced: sliced VBI capture or output parameters
* @raw_data: placeholder for future extensions and custom formats
*/
struct <link linkend="v4l2-format">v4l2_format</link> {
enum <link linkend="v4l2-buf-type">v4l2_buf_type</link> type;
union {
struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> pix; /* V4L2_BUF_TYPE_VIDEO_CAPTURE */
struct <link linkend="v4l2-pix-format-mplane">v4l2_pix_format_mplane</link> pix_mp; /* V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE */
struct <link linkend="v4l2-window">v4l2_window</link> win; /* V4L2_BUF_TYPE_VIDEO_OVERLAY */
struct <link linkend="v4l2-vbi-format">v4l2_vbi_format</link> vbi; /* V4L2_BUF_TYPE_VBI_CAPTURE */
struct <link linkend="v4l2-sliced-vbi-format">v4l2_sliced_vbi_format</link> sliced; /* V4L2_BUF_TYPE_SLICED_VBI_CAPTURE */
......@@ -1636,7 +1764,6 @@ struct <link linkend="v4l2-format">v4l2_format</link> {
} fmt;
};
/* Stream type-dependent parameters
*/
struct <link linkend="v4l2-streamparm">v4l2_streamparm</link> {
......@@ -1809,16 +1936,6 @@ struct <link linkend="v4l2-dbg-chip-ident">v4l2_dbg_chip_ident</link> {
/* Reminder: when adding new ioctls please add support for them to
drivers/media/video/v4l2-compat-ioctl32.c as well! */
#ifdef __OLD_VIDIOC_
/* for compatibility, will go away some day */
#define VIDIOC_OVERLAY_OLD _IOWR('V', 14, int)
#define VIDIOC_S_PARM_OLD _IOW('V', 22, struct <link linkend="v4l2-streamparm">v4l2_streamparm</link>)
#define VIDIOC_S_CTRL_OLD _IOW('V', 28, struct <link linkend="v4l2-control">v4l2_control</link>)
#define VIDIOC_G_AUDIO_OLD _IOWR('V', 33, struct <link linkend="v4l2-audio">v4l2_audio</link>)
#define VIDIOC_G_AUDOUT_OLD _IOWR('V', 49, struct <link linkend="v4l2-audioout">v4l2_audioout</link>)
#define VIDIOC_CROPCAP_OLD _IOR('V', 58, struct <link linkend="v4l2-cropcap">v4l2_cropcap</link>)
#endif
#define BASE_VIDIOC_PRIVATE 192 /* 192-255 are private */
#endif /* __LINUX_VIDEODEV2_H */
......
Documentation/DocBook/v4l/vidioc-enum-fmt.xml
浏览文件 @ 6288cf1e
......@@ -76,7 +76,9 @@ pixelformat</structfield> field.</entry>
<entry>Type of the data stream, set by the application.
Only these types are valid here:
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>,
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>,
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant>,
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant>,
<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>, and custom (driver
defined) types with code <constant>V4L2_BUF_TYPE_PRIVATE</constant>
and higher.</entry>
......
Documentation/DocBook/v4l/vidioc-g-fmt.xml
浏览文件 @ 6288cf1e
......@@ -60,11 +60,13 @@ application.</para>
<structfield>type</structfield> field of a struct
<structname>v4l2_format</structname> to the respective buffer (stream)
type. For example video capture devices use
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>. When the application
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant> or
<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>. When the application
calls the <constant>VIDIOC_G_FMT</constant> ioctl with a pointer to
this structure the driver fills the respective member of the
<structfield>fmt</structfield> union. In case of video capture devices
that is the &v4l2-pix-format; <structfield>pix</structfield> member.
that is either the &v4l2-pix-format; <structfield>pix</structfield> or
the &v4l2-pix-format-mplane; <structfield>pix_mp</structfield> member.
When the requested buffer type is not supported drivers return an
&EINVAL;.</para>
......@@ -131,6 +133,15 @@ this ioctl.</para>
<entry>Definition of an image format, see <xref
linkend="pixfmt" />, used by video capture and output
devices.</entry>
</row>
<row>
<entry></entry>
<entry>&v4l2-pix-format-mplane;</entry>
<entry><structfield>pix_mp</structfield></entry>
<entry>Definition of an image format, see <xref
linkend="pixfmt" />, used by video capture and output
devices that support the <link linkend="planar-apis">multi-planar
version of the API</link>.</entry>
</row>
<row>
<entry></entry>
......
Documentation/DocBook/v4l/vidioc-qbuf.xml
浏览文件 @ 6288cf1e
......@@ -64,7 +64,8 @@ zero to the number of buffers allocated with &VIDIOC-REQBUFS;
contents of the struct <structname>v4l2_buffer</structname> returned
by a &VIDIOC-QUERYBUF; ioctl will do as well. When the buffer is
intended for output (<structfield>type</structfield> is
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> or
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant>,
<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant>, or
<constant>V4L2_BUF_TYPE_VBI_OUTPUT</constant>) applications must also
initialize the <structfield>bytesused</structfield>,
<structfield>field</structfield> and
......@@ -75,7 +76,11 @@ 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.
The <structfield>reserved</structfield> field must be set to 0. When using
the <link linkend="planar-apis">multi-planar API</link>, the
<structfield>m.planes</structfield> field must contain a userspace pointer
to a filled-in array of &v4l2-plane; and the <structfield>length</structfield>
field must be set to the number of elements in that array.
</para>
<para>To enqueue a <link linkend="mmap">memory mapped</link>
......@@ -93,10 +98,13 @@ structure the driver sets 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 <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
buffer and <structfield>length</structfield> to its size. When the multi-planar
API is used, <structfield>m.userptr</structfield> and
<structfield>length</structfield> members of the passed array of &v4l2-plane;
have to be used instead. 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
<constant>V4L2_BUF_FLAG_DONE</constant> flags in the
<structfield>flags</structfield> field, or it returns an error code.
This ioctl locks the memory pages of the buffer in physical memory,
......@@ -115,7 +123,9 @@ remaining fields or returns an error code. The driver may also set
<constant>V4L2_BUF_FLAG_ERROR</constant> in the <structfield>flags</structfield>
field. It indicates a non-critical (recoverable) streaming error. In such case
the application may continue as normal, but should be aware that data in the
dequeued buffer might be corrupted.</para>
dequeued buffer might be corrupted. When using the multi-planar API, the
planes array does not have to be passed; the <structfield>m.planes</structfield>
member must be set to NULL in that case.</para>
<para>By default <constant>VIDIOC_DQBUF</constant> blocks when no
buffer is in the outgoing queue. When the
......
Documentation/DocBook/v4l/vidioc-querybuf.xml
浏览文件 @ 6288cf1e
......@@ -61,6 +61,10 @@ buffer at any time after buffers have been allocated with the
to the number of buffers allocated with &VIDIOC-REQBUFS;
(&v4l2-requestbuffers; <structfield>count</structfield>) minus one.
The <structfield>reserved</structfield> field should to set to 0.
When using the <link linkend="planar-apis">multi-planar API</link>, the
<structfield>m.planes</structfield> field must contain a userspace pointer to an
array of &v4l2-plane; and the <structfield>length</structfield> field has
to be set to the number of elements in that array.
After calling <constant>VIDIOC_QUERYBUF</constant> with a pointer to
this structure drivers return an error code or fill the rest of
the structure.</para>
......@@ -70,11 +74,13 @@ the structure.</para>
<constant>V4L2_BUF_FLAG_QUEUED</constant> and
<constant>V4L2_BUF_FLAG_DONE</constant> flags will be valid. The
<structfield>memory</structfield> field will be set to the current
I/O method, the <structfield>m.offset</structfield>
I/O method. For the single-planar API, the <structfield>m.offset</structfield>
contains the offset of the buffer from the start of the device memory,
the <structfield>length</structfield> field its size. The driver may
or may not set the remaining fields and flags, they are meaningless in
this context.</para>
the <structfield>length</structfield> field its size. For the multi-planar API,
fields <structfield>m.mem_offset</structfield> and
<structfield>length</structfield> in the <structfield>m.planes</structfield>
array elements will be used instead. The driver may or may not set the remaining
fields and flags, they are meaningless in this context.</para>
<para>The <structname>v4l2_buffer</structname> structure is
specified in <xref linkend="buffer" />.</para>
......
Documentation/DocBook/v4l/vidioc-querycap.xml
浏览文件 @ 6288cf1e
......@@ -142,15 +142,29 @@ this array to zero.</entry>
<row>
<entry><constant>V4L2_CAP_VIDEO_CAPTURE</constant></entry>
<entry>0x00000001</entry>
<entry>The device supports the <link
<entry>The device supports the single-planar API through the <link
linkend="capture">Video Capture</link> interface.</entry>
</row>
<row>
<entry><constant>V4L2_CAP_VIDEO_CAPTURE_MPLANE</constant></entry>
<entry>0x00001000</entry>
<entry>The device supports the
<link linkend="planar-apis">multi-planar API</link> through the
<link linkend="capture">Video Capture</link> interface.</entry>
</row>
<row>
<entry><constant>V4L2_CAP_VIDEO_OUTPUT</constant></entry>
<entry>0x00000002</entry>
<entry>The device supports the <link
<entry>The device supports the single-planar API through the <link
linkend="output">Video Output</link> interface.</entry>
</row>
<row>
<entry><constant>V4L2_CAP_VIDEO_OUTPUT_MPLANE</constant></entry>
<entry>0x00002000</entry>
<entry>The device supports the
<link linkend="planar-apis">multi-planar API</link> through the
<link linkend="output">Video Output</link> interface.</entry>
</row>
<row>
<entry><constant>V4L2_CAP_VIDEO_OVERLAY</constant></entry>
<entry>0x00000004</entry>
......
Documentation/DocBook/v4l/vidioc-streamon.xml
浏览文件 @ 6288cf1e
......@@ -93,6 +93,15 @@ synchronize with other events.</para>
been allocated (memory mapping) or enqueued (output) yet.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EPIPE</errorcode></term>
<listitem>
<para>The driver implements <link
linkend="pad-level-formats">pad-level format configuration</link> and
the pipeline configuration is invalid.
</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>
......
Documentation/DocBook/v4l/vidioc-subdev-enum-frame-interval.xml 0 → 100644
浏览文件 @ 6288cf1e
<refentry id="vidioc-subdev-enum-frame-interval">
<refmeta>
<refentrytitle>ioctl VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL</refname>
<refpurpose>Enumerate frame intervals</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_subdev_frame_interval_enum *
<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_SUBDEV_ENUM_FRAME_INTERVAL</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>This ioctl lets applications enumerate available frame intervals on a
given sub-device pad. Frame intervals only makes sense for sub-devices that
can control the frame period on their own. This includes, for instance,
image sensors and TV tuners.</para>
<para>For the common use case of image sensors, the frame intervals
available on the sub-device output pad depend on the frame format and size
on the same pad. Applications must thus specify the desired format and size
when enumerating frame intervals.</para>
<para>To enumerate frame intervals applications initialize the
<structfield>index</structfield>, <structfield>pad</structfield>,
<structfield>code</structfield>, <structfield>width</structfield> and
<structfield>height</structfield> fields of
&v4l2-subdev-frame-interval-enum; and call the
<constant>VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL</constant> ioctl with a pointer
to this structure. Drivers fill the rest of the structure or return
an &EINVAL; if one of the input fields is invalid. All frame intervals are
enumerable by beginning at index zero and incrementing by one until
<errorcode>EINVAL</errorcode> is returned.</para>
<para>Available frame intervals may depend on the current 'try' formats
at other pads of the sub-device, as well as on the current active links. See
&VIDIOC-SUBDEV-G-FMT; for more information about the try formats.</para>
<para>Sub-devices that support the frame interval enumeration ioctl should
implemented it on a single pad only. Its behaviour when supported on
multiple pads of the same sub-device is not defined.</para>
<table pgwide="1" frame="none" id="v4l2-subdev-frame-interval-enum">
<title>struct <structname>v4l2_subdev_frame_interval_enum</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>index</structfield></entry>
<entry>Number of the format in the enumeration, set by the
application.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>pad</structfield></entry>
<entry>Pad number as reported by the media controller API.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>code</structfield></entry>
<entry>The media bus format code, as defined in
<xref linkend="v4l2-mbus-format" />.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>width</structfield></entry>
<entry>Frame width, in pixels.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>height</structfield></entry>
<entry>Frame height, in pixels.</entry>
</row>
<row>
<entry>&v4l2-fract;</entry>
<entry><structfield>interval</structfield></entry>
<entry>Period, in seconds, between consecutive video frames.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[9]</entry>
<entry>Reserved for future extensions. Applications and drivers must
set the array to zero.</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The &v4l2-subdev-frame-interval-enum;
<structfield>pad</structfield> references a non-existing pad, one of
the <structfield>code</structfield>, <structfield>width</structfield>
or <structfield>height</structfield> fields are invalid for the given
pad or the <structfield>index</structfield> field is out of bounds.
</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>
Documentation/DocBook/v4l/vidioc-subdev-enum-frame-size.xml 0 → 100644
浏览文件 @ 6288cf1e
<refentry id="vidioc-subdev-enum-frame-size">
<refmeta>
<refentrytitle>ioctl VIDIOC_SUBDEV_ENUM_FRAME_SIZE</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>VIDIOC_SUBDEV_ENUM_FRAME_SIZE</refname>
<refpurpose>Enumerate media bus frame sizes</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_subdev_frame_size_enum *
<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_SUBDEV_ENUM_FRAME_SIZE</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>This ioctl allows applications to enumerate all frame sizes
supported by a sub-device on the given pad for the given media bus format.
Supported formats can be retrieved with the &VIDIOC-SUBDEV-ENUM-MBUS-CODE;
ioctl.</para>
<para>To enumerate frame sizes applications initialize the
<structfield>pad</structfield>, <structfield>code</structfield> and
<structfield>index</structfield> fields of the
&v4l2-subdev-mbus-code-enum; and call the
<constant>VIDIOC_SUBDEV_ENUM_FRAME_SIZE</constant> ioctl with a pointer to
the structure. Drivers fill the minimum and maximum frame sizes or return
an &EINVAL; if one of the input parameters is invalid.</para>
<para>Sub-devices that only support discrete frame sizes (such as most
sensors) will return one or more frame sizes with identical minimum and
maximum values.</para>
<para>Not all possible sizes in given [minimum, maximum] ranges need to be
supported. For instance, a scaler that uses a fixed-point scaling ratio
might not be able to produce every frame size between the minimum and
maximum values. Applications must use the &VIDIOC-SUBDEV-S-FMT; ioctl to
try the sub-device for an exact supported frame size.</para>
<para>Available frame sizes may depend on the current 'try' formats at other
pads of the sub-device, as well as on the current active links and the
current values of V4L2 controls. See &VIDIOC-SUBDEV-G-FMT; for more
information about try formats.</para>
<table pgwide="1" frame="none" id="v4l2-subdev-frame-size-enum">
<title>struct <structname>v4l2_subdev_frame_size_enum</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>index</structfield></entry>
<entry>Number of the format in the enumeration, set by the
application.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>pad</structfield></entry>
<entry>Pad number as reported by the media controller API.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>code</structfield></entry>
<entry>The media bus format code, as defined in
<xref linkend="v4l2-mbus-format" />.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>min_width</structfield></entry>
<entry>Minimum frame width, in pixels.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>max_width</structfield></entry>
<entry>Maximum frame width, in pixels.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>min_height</structfield></entry>
<entry>Minimum frame height, in pixels.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>max_height</structfield></entry>
<entry>Maximum frame height, in pixels.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[9]</entry>
<entry>Reserved for future extensions. Applications and drivers must
set the array to zero.</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The &v4l2-subdev-frame-size-enum; <structfield>pad</structfield>
references a non-existing pad, the <structfield>code</structfield> is
invalid for the given pad or the <structfield>index</structfield>
field is out of bounds.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>
Documentation/DocBook/v4l/vidioc-subdev-g-crop.xml 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/DocBook/v4l/vidioc-subdev-g-fmt.xml 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/DocBook/writing-an-alsa-driver.tmpl
浏览文件 @ 6288cf1e
......@@ -4784,7 +4784,7 @@ struct _snd_pcm_runtime {
FM registers can be directly accessed through the direct-FM API,
defined in <filename>&lt;sound/asound_fm.h&gt;</filename>. In
ALSA native mode, FM registers are accessed through
the Hardware-Dependant Device direct-FM extension API, whereas in
the Hardware-Dependent Device direct-FM extension API, whereas in
OSS compatible mode, FM registers can be accessed with the OSS
direct-FM compatible API in <filename>/dev/dmfmX</filename> device.
</para>
......
Documentation/PCI/MSI-HOWTO.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/RCU/whatisRCU.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/SecurityBugs
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/SubmittingDrivers
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/SubmittingPatches
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/arm/IXP4xx
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/arm/SH-Mobile/Makefile 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/arm/SH-Mobile/vrl4.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/arm/SH-Mobile/zboot-rom-mmcif.txt 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/arm/Samsung/GPIO.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/arm/Sharp-LH/CompactFlash 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
Documentation/arm/Sharp-LH/IOBarrier 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
Documentation/arm/Sharp-LH/KEV7A400 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
Documentation/arm/Sharp-LH/LCDPanels 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
Documentation/arm/Sharp-LH/LPD7A400 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
Documentation/arm/Sharp-LH/LPD7A40X 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
Documentation/arm/Sharp-LH/SDRAM 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
Documentation/block/biodoc.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/cgroups/cgroups.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/cgroups/cpusets.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/cgroups/memory.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/cpu-hotplug.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/dell_rbu.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/device-mapper/dm-flakey.txt 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/devicetree/00-INDEX 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/devicetree/bindings/fb/sm501fb.txt 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/devicetree/bindings/hwmon/ads1015.txt 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/devicetree/bindings/i2c/ce4100-i2c.txt 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/devicetree/bindings/open-pic.txt 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/devicetree/bindings/rtc/rtc-cmos.txt 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/devicetree/bindings/serio/altera_ps2.txt 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/devicetree/bindings/spi/spi_altera.txt 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/devicetree/bindings/spi/spi_oc_tiny.txt 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/devicetree/bindings/x86/ce4100.txt 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/devicetree/bindings/x86/interrupt.txt 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/devicetree/bindings/x86/timer.txt 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/dvb/README.dvb-usb
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/dvb/ci.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/dvb/faq.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/dvb/get_dvb_firmware
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/dvb/lmedm04.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/dvb/udev.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/edac.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/eisa.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/fb/sm501.txt 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/fb/viafb.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/filesystems/Locking
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/filesystems/adfs.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/filesystems/exofs.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/filesystems/ext4.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/filesystems/gfs2.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/filesystems/ntfs.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/filesystems/ocfs2.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/filesystems/porting
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/filesystems/proc.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/filesystems/romfs.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/filesystems/sysfs.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/filesystems/ubifs.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/filesystems/vfs.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/flexible-arrays.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/hwmon/abituguru
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/hwmon/abituguru3
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/hwmon/adm1021
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/hwmon/ads1015 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/hwmon/f71882fg
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/hwmon/lineage-pem 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/hwmon/lis3lv02d 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
Documentation/hwmon/lm75
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/hwmon/lm85
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/hwmon/lm90
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/hwmon/ltc4151 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/hwmon/max16064 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/hwmon/max34440 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/hwmon/max6639 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/hwmon/max8688 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/hwmon/pmbus 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/hwmon/sch5627 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/hwmon/smm665
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/hwmon/submitting-patches 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/hwmon/sysfs-interface
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/hwmon/twl4030-madc-hwmon 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/hwmon/w83627ehf
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/hwmon/w83781d
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/hwmon/w83791d
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/hwmon/w83795 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/hwspinlock.txt 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/i2c/busses/i2c-diolan-u2c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/i2c/busses/i2c-i801
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/i2c/busses/i2c-sis96x
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/i2c/upgrading-clients
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/i2o/README
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/ia64/aliasing-test.c
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/input/event-codes.txt 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/input/walkera0701.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/iostats.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/irqflags-tracing.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/isdn/INTERFACE.CAPI
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/kbuild/kbuild.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/kbuild/makefiles.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/kernel-parameters.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/keys-request-key.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/keys.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/kmemleak.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/kref.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/kvm/api.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/kvm/locking.txt 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/kvm/mmu.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/kvm/ppc-pv.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/kvm/timekeeping.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/leds-class.txt 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
Documentation/leds/00-INDEX 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/leds/leds-class.txt 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/md.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/media-framework.txt 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/memory-barriers.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/memory-hotplug.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/misc-devices/lis3lv02d 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/misc-devices/spear-pcie-gadget.txt 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/networking/00-INDEX
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/networking/3c359.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/networking/can.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/networking/phonet.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/networking/s2io.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/power/devices.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/power/notifiers.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/power/opp.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/power/runtime_pm.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/power/states.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/power/swsusp.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/powerpc/00-INDEX
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/powerpc/hvcs.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/rapidio/rapidio.txt 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/rapidio/sysfs.txt 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/rtc.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/s390/Debugging390.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/scsi/ChangeLog.lpfc
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/scsi/aha152x.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/scsi/aic79xx.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/scsi/hpsa.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/scsi/ibmmca.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/scsi/scsi-changer.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/scsi/scsi_eh.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/scsi/sym53c8xx_2.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/serial/moxa-smartio
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/serial/n_gsm.txt 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/sound/oss/README.OSS
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/spi/pxa2xx
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/spi/spi-lm70llp
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/spinlocks.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/sysctl/fs.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/sysctl/kernel.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/telephony/ixj.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/trace/ftrace.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/trace/kprobetrace.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/usb/usbmon.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/video4linux/Zoran
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/video4linux/gspca.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/video4linux/omap3isp.txt 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/vm/active_mm.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/vm/hugetlbpage.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/vm/page-types.c
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/w1/slaves/w1_ds2423
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/w1/w1.netlink
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/watchdog/hpwdt.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/workqueue.txt
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/zh_CN/SecurityBugs 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/zh_CN/SubmitChecklist 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Documentation/zh_CN/magic-number.txt 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
MAINTAINERS
浏览文件 @ 6288cf1e
此差异已折叠。
Makefile
浏览文件 @ 6288cf1e
此差异已折叠。
README
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/Kconfig
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/include/asm/bitops.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/include/asm/cacheflush.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/include/asm/elf.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/include/asm/errno.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/include/asm/fcntl.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/include/asm/futex.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/include/asm/ioctls.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/include/asm/rwsem.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/include/asm/types.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/include/asm/unistd.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/kernel/Makefile
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/kernel/core_lca.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/kernel/core_mcpcia.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/kernel/err_marvel.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/kernel/err_titan.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/kernel/irq.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/kernel/irq_alpha.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/kernel/irq_i8259.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/kernel/irq_impl.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/kernel/irq_pyxis.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/kernel/irq_srm.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/kernel/osf_sys.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/kernel/setup.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/kernel/smc37c93x.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/kernel/sys_alcor.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/kernel/sys_cabriolet.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/kernel/sys_dp264.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/kernel/sys_eb64p.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/kernel/sys_eiger.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/kernel/sys_jensen.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/kernel/sys_marvel.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/kernel/sys_mikasa.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/kernel/sys_noritake.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/kernel/sys_rawhide.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/kernel/sys_rx164.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/kernel/sys_sable.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/kernel/sys_takara.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/kernel/sys_titan.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/kernel/sys_wildfire.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/kernel/systbls.S
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/kernel/time.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/kernel/vmlinux.lds.S
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/lib/ev67-strrchr.S
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/lib/fls.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/lib/strrchr.S
浏览文件 @ 6288cf1e
此差异已折叠。
arch/alpha/oprofile/op_model_ev67.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/Kconfig
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/Kconfig-nommu
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/Kconfig.debug
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/Makefile
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/boot/Makefile
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/boot/compressed/Makefile
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/boot/compressed/head-vt8500.S 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/boot/compressed/head.S
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/boot/compressed/misc.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/boot/compressed/mmcif-sh7372.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/common/Kconfig
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/common/Makefile
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/common/gic.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/common/it8152.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/common/locomo.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/common/pl330.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/common/sa1111.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/common/vic.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/configs/at91x40_defconfig 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/configs/exynos4_defconfig 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/configs/kirkwood_defconfig
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/configs/lpd7a400_defconfig 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/configs/lpd7a404_defconfig 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/configs/mx51_defconfig
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/configs/s5p64x0_defconfig
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/configs/s5pv210_defconfig
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/configs/tegra_defconfig 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/configs/u8500_defconfig
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/configs/vexpress_defconfig 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/a.out-core.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/bitops.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/cacheflush.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/cpu-multi32.h 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/include/asm/cpu-single.h 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/include/asm/cputype.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/fncpy.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/fpstate.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/futex.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/glue-cache.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/glue-df.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/glue-pf.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/glue-proc.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/glue.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/hardware/gic.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/highmem.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/hw_irq.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/kexec.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/kprobes.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/localtimer.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/mach/arch.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/mach/irq.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/memory.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/module.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/outercache.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/pgalloc.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/pgtable.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/pmu.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/proc-fns.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/processor.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/ptrace.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/setup.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/smp_scu.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/spinlock.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/system.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/tls.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/traps.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/types.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/ucontext.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/unistd.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/include/asm/user.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/Makefile
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/armksyms.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/asm-offsets.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/bios32.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/calls.S
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/crash_dump.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/debug.S
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/ecard.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/elf.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/entry-armv.S
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/entry-header.S
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/etm.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/head-common.S
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/head-nommu.S
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/head.S
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/hw_breakpoint.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/irq.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/kprobes-decode.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/kprobes.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/machine_kexec.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/module.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/perf_event.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/perf_event_v6.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/perf_event_v7.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/perf_event_xscale.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/process.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/ptrace.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/ptrace.h 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/kernel/return_address.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/setup.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/signal.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/sleep.S 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/smp.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/smp_scu.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/swp_emulate.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/sys_oabi-compat.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/tcm.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/time.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/traps.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/kernel/vmlinux.lds.S
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/lib/bitops.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/lib/changebit.S
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/lib/clearbit.S
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/lib/setbit.S
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/lib/testchangebit.S
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/lib/testclearbit.S
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/lib/testsetbit.S
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/lib/uaccess_with_memcpy.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-aaec2000/Kconfig 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-aaec2000/Makefile 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-aaec2000/Makefile.boot 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-aaec2000/aaed2000.c 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-aaec2000/core.c 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-aaec2000/core.h 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-aaec2000/include/mach/io.h 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-aaec2000/include/mach/irqs.h 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-aaec2000/include/mach/memory.h 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-aaec2000/include/mach/system.h 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-aaec2000/include/mach/timex.h 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-aaec2000/include/mach/vmalloc.h 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-at91/Kconfig
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-at91/board-carmeva.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-at91/board-eb01.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-at91/gpio.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-at91/irq.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-bcmring/dma.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-bcmring/irq.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-clps711x/irq.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-davinci/Kconfig
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-davinci/cp_intc.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-davinci/cpufreq.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-davinci/da830.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-davinci/da850.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-davinci/dm355.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-davinci/dm365.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-davinci/dm644x.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-davinci/gpio.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-davinci/irq.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-davinci/tnetv107x.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-dove/Kconfig
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-dove/cm-a510.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-dove/common.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-dove/common.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-dove/dove-db-setup.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-dove/irq.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-dove/mpp.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-ebsa110/core.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-ep93xx/edb93xx.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-ep93xx/gpio.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/Kconfig 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/Makefile 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/clock.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/cpu.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/cpufreq.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/dev-ahci.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/dev-audio.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/dev-pd.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/dev-sysmmu.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/dma.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/gpiolib.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/headsmp.S 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/hotplug.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/include/mach/debug-macro.S 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/include/mach/entry-macro.S 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/include/mach/gpio.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/include/mach/hardware.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/include/mach/io.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/include/mach/irqs.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/include/mach/map.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/include/mach/memory.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/include/mach/pm-core.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/include/mach/pwm-clock.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/include/mach/regs-clock.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/include/mach/regs-gpio.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/include/mach/regs-irq.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/include/mach/regs-mct.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/include/mach/regs-mem.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/include/mach/regs-pmu.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/include/mach/regs-sysmmu.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/include/mach/smp.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/include/mach/sysmmu.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/include/mach/system.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/include/mach/timex.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/include/mach/uncompress.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/include/mach/vmalloc.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/init.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/irq-combiner.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/irq-eint.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/localtimer.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/mach-armlex4210.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/mach-nuri.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/mach-smdkc210.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/mach-smdkv310.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/mach-universal_c210.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/mct.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/platsmp.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/pm.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/setup-fimc.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/setup-i2c0.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/setup-i2c1.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/setup-i2c2.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/setup-i2c3.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/setup-i2c4.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/setup-i2c5.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/setup-i2c6.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/setup-i2c7.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/setup-keypad.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/setup-sdhci-gpio.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/setup-sdhci.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/sleep.S 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-exynos4/time.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-footbridge/common.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-footbridge/isa-irq.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-gemini/board-rut1xx.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-gemini/board-wbd111.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-gemini/board-wbd222.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-gemini/common.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-gemini/devices.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-gemini/gpio.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-gemini/irq.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-h720x/common.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-h720x/cpu-h7202.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-imx/Kconfig
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-imx/Makefile
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-imx/clock-imx1.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-imx/clock-imx25.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-imx/devices-imx1.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-imx/devices-imx25.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-imx/dma-v1.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-imx/ehci-imx25.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-imx/ehci-imx27.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-imx/mach-cpuimx27.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-imx/mach-imx27ipcam.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-imx/mach-imx27lite.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-imx/mach-mx1ads.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-imx/mach-mx21ads.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-imx/mach-mx25_3ds.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-imx/mach-mx27_3ds.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-imx/mach-mx27ads.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-imx/mach-mxt_td60.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-imx/mach-pca100.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-imx/mach-pcm038.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-imx/mach-scb9328.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-imx/mm-imx1.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-imx/mm-imx21.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-imx/mm-imx25.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-imx/mm-imx27.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-integrator/Kconfig
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-integrator/common.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-integrator/core.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-integrator/impd1.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-iop13xx/irq.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-iop13xx/msi.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-iop13xx/pci.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-iop32x/irq.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-iop33x/irq.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-ixp2000/core.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-ixp2000/ixdp2x00.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-ixp2000/ixdp2x01.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-ixp23xx/core.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-ixp23xx/ixdp2351.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-ixp23xx/roadrunner.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-ixp4xx/avila-pci.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-ixp4xx/common.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-ixp4xx/coyote-pci.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-ixp4xx/dsmg600-pci.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-ixp4xx/fsg-pci.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-ixp4xx/goramo_mlr.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-ixp4xx/gtwx5715-pci.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-ixp4xx/ixdp425-pci.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-ixp4xx/ixdpg425-pci.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-ixp4xx/nas100d-pci.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-ixp4xx/nslu2-pci.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-ixp4xx/vulcan-pci.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-ixp4xx/wg302v2-pci.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-kirkwood/common.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-kirkwood/common.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-kirkwood/irq.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-kirkwood/mpp.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-kirkwood/pcie.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-ks8695/gpio.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-ks8695/irq.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-lh7a40x/Kconfig 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-lh7a40x/Makefile 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-lh7a40x/Makefile.boot 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-lh7a40x/arch-kev7a400.c 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-lh7a40x/arch-lpd7a40x.c 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-lh7a40x/clcd.c 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-lh7a40x/clocks.c 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-lh7a40x/common.h 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-lh7a40x/include/mach/clocks.h 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-lh7a40x/include/mach/dma.h 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-lh7a40x/include/mach/hardware.h 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-lh7a40x/include/mach/io.h 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-lh7a40x/include/mach/irqs.h 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-lh7a40x/include/mach/memory.h 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-lh7a40x/include/mach/ssp.h 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-lh7a40x/include/mach/system.h 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-lh7a40x/include/mach/timex.h 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-lh7a40x/include/mach/vmalloc.h 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-lh7a40x/irq-kev7a400.c 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-lh7a40x/irq-lh7a400.c 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-lh7a40x/irq-lh7a404.c 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-lh7a40x/irq-lpd7a40x.c 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-lh7a40x/lcd-panel.h 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-lh7a40x/ssp-cpld.c 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-lh7a40x/time.c 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-loki/common.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-loki/common.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-lpc32xx/irq.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-lpc32xx/pm.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mmp/irq-mmp2.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mmp/irq-pxa168.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mmp/time.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/Kconfig
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/Makefile
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/acpuclock-arm11.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/board-halibut.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/board-mahimahi.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/board-msm7x27.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/board-msm7x30.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/board-msm8960.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/board-msm8x60.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/board-qsd8x50.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/board-sapphire.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/board-trout-mmc.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/board-trout.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/clock-7x30.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/clock-debug.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/clock-dummy.c 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-msm/clock-pcom.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/clock-pcom.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/clock.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/clock.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/devices-iommu.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/devices-msm7x00.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/devices-msm7x30.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/devices-msm8960.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/devices-msm8x60-iommu.c 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-msm/devices-qsd8x50.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/devices.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/gpio-v2.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/gpio.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/gpiomux-7x30.c 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-msm/gpiomux-8x50.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/headsmp.S
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/include/mach/clkdev.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/include/mach/cpu.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/include/mach/io.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/include/mach/irqs-8960.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/include/mach/msm_iomap-8960.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/io.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/iommu.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/iommu_dev.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/irq-vic.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/irq.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/scm-boot.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/scm.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/scm.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/sirc.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-msm/timer.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mv78xx0/common.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mv78xx0/common.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mv78xx0/irq.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mv78xx0/mpp.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx3/Kconfig
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx3/Makefile
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx3/devices-imx35.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx3/ehci-imx31.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx3/ehci-imx35.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx3/iomux-imx31.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx3/mach-bug.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx3/mach-cpuimx35.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx3/mach-mx31_3ds.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx3/mach-mx31ads.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx3/mach-mx31lilly.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx3/mach-mx31lite.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx3/mach-mx35_3ds.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx3/mach-pcm037.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx3/mach-pcm037_eet.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx3/mach-pcm043.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx3/mach-qong.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx3/mach-vpr200.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx3/mm.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx5/Kconfig
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx5/Makefile
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx5/board-cpuimx51.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx5/board-mx50_rdp.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx5/board-mx51_3ds.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx5/board-mx51_efikasb.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx5/board-mx53_evk.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx5/board-mx53_loco.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx5/board-mx53_smd.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx5/clock-mx51-mx53.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx5/cpu.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx5/crm_regs.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx5/devices-imx50.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx5/devices-imx53.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx5/devices-mx50.h 已删除 100644 → 0
浏览文件 @ 0a63e230
此差异已折叠。
arch/arm/mach-mx5/efika.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx5/ehci.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx5/mm-mx50.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx5/mm.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx5/mx51_efika.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mx5/system.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mxc91231/iomux.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mxc91231/magx-zn5.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mxc91231/mm.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mxs/Kconfig
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mxs/Makefile
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mxs/clock-mx23.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mxs/clock-mx28.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mxs/devices-mx23.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mxs/devices-mx28.h
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mxs/devices.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mxs/devices/Kconfig
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mxs/devices/Makefile
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mxs/devices/platform-auart.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mxs/devices/platform-dma.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mxs/devices/platform-flexcan.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mxs/devices/platform-mxs-i2c.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mxs/devices/platform-mxs-mmc.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mxs/devices/platform-mxs-pwm.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mxs/devices/platform-mxsfb.c 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mxs/gpio.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mxs/icoll.c
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mxs/include/mach/dma.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
arch/arm/mach-mxs/include/mach/mmc.h 0 → 100644
浏览文件 @ 6288cf1e
此差异已折叠。
Markdown is supported
0% 或 .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑！
想要评论请 注册 或