diff options
| author | Dmitry Torokhov <dmitry.torokhov@gmail.com> | 2011-05-24 03:06:26 -0400 |
|---|---|---|
| committer | Dmitry Torokhov <dmitry.torokhov@gmail.com> | 2011-05-24 03:06:26 -0400 |
| commit | b73077eb03f510a84b102fb97640e595a958403c (patch) | |
| tree | 8b639000418e2756bf6baece4e00e07d2534bccc /Documentation | |
| parent | 28350e330cfab46b60a1dbf763b678d859f9f3d9 (diff) | |
| parent | 9d2e173644bb5c42ff1b280fbdda3f195a7cf1f7 (diff) | |
Merge branch 'next' into for-linus
Diffstat (limited to 'Documentation')
397 files changed, 12208 insertions, 1822 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 8dfc6708a257..c17cd4bb2290 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX | |||
| @@ -206,8 +206,8 @@ laptops/ | |||
| 206 | - directory with laptop related info and laptop driver documentation. | 206 | - directory with laptop related info and laptop driver documentation. |
| 207 | ldm.txt | 207 | ldm.txt |
| 208 | - a brief description of LDM (Windows Dynamic Disks). | 208 | - a brief description of LDM (Windows Dynamic Disks). |
| 209 | leds-class.txt | 209 | leds/ |
| 210 | - documents LED handling under Linux. | 210 | - directory with info about LED handling under Linux. |
| 211 | local_ops.txt | 211 | local_ops.txt |
| 212 | - semantics and behavior of local atomic operations. | 212 | - semantics and behavior of local atomic operations. |
| 213 | lockdep-design.txt | 213 | lockdep-design.txt |
| @@ -328,8 +328,6 @@ sysrq.txt | |||
| 328 | - info on the magic SysRq key. | 328 | - info on the magic SysRq key. |
| 329 | telephony/ | 329 | telephony/ |
| 330 | - directory with info on telephony (e.g. voice over IP) support. | 330 | - directory with info on telephony (e.g. voice over IP) support. |
| 331 | time_interpolators.txt | ||
| 332 | - info on time interpolators. | ||
| 333 | uml/ | 331 | uml/ |
| 334 | - directory with information about User Mode Linux. | 332 | - directory with information about User Mode Linux. |
| 335 | unicode.txt | 333 | unicode.txt |
| @@ -346,8 +344,6 @@ vm/ | |||
| 346 | - directory with info on the Linux vm code. | 344 | - directory with info on the Linux vm code. |
| 347 | volatile-considered-harmful.txt | 345 | volatile-considered-harmful.txt |
| 348 | - Why the "volatile" type class should not be used | 346 | - Why the "volatile" type class should not be used |
| 349 | voyager.txt | ||
| 350 | - guide to running Linux on the Voyager architecture. | ||
| 351 | w1/ | 347 | w1/ |
| 352 | - directory with documents regarding the 1-wire (w1) subsystem. | 348 | - directory with documents regarding the 1-wire (w1) subsystem. |
| 353 | watchdog/ | 349 | watchdog/ |
diff --git a/Documentation/ABI/stable/sysfs-class-backlight b/Documentation/ABI/stable/sysfs-class-backlight index 4d637e1c4ff7..70302f370e7e 100644 --- a/Documentation/ABI/stable/sysfs-class-backlight +++ b/Documentation/ABI/stable/sysfs-class-backlight | |||
| @@ -34,3 +34,23 @@ Contact: Richard Purdie <rpurdie@rpsys.net> | |||
| 34 | Description: | 34 | Description: |
| 35 | Maximum brightness for <backlight>. | 35 | Maximum brightness for <backlight>. |
| 36 | Users: HAL | 36 | Users: HAL |
| 37 | |||
| 38 | What: /sys/class/backlight/<backlight>/type | ||
| 39 | Date: September 2010 | ||
| 40 | KernelVersion: 2.6.37 | ||
| 41 | Contact: Matthew Garrett <mjg@redhat.com> | ||
| 42 | Description: | ||
| 43 | The type of interface controlled by <backlight>. | ||
| 44 | "firmware": The driver uses a standard firmware interface | ||
| 45 | "platform": The driver uses a platform-specific interface | ||
| 46 | "raw": The driver controls hardware registers directly | ||
| 47 | |||
| 48 | In the general case, when multiple backlight | ||
| 49 | interfaces are available for a single device, firmware | ||
| 50 | control should be preferred to platform control should | ||
| 51 | be preferred to raw control. Using a firmware | ||
| 52 | interface reduces the probability of confusion with | ||
| 53 | the hardware and the OS independently updating the | ||
| 54 | backlight state. Platform interfaces are mostly a | ||
| 55 | holdover from pre-standardisation of firmware | ||
| 56 | interfaces. | ||
diff --git a/Documentation/ABI/stable/sysfs-firmware-efi-vars b/Documentation/ABI/stable/sysfs-firmware-efi-vars new file mode 100644 index 000000000000..5def20b9019e --- /dev/null +++ b/Documentation/ABI/stable/sysfs-firmware-efi-vars | |||
| @@ -0,0 +1,75 @@ | |||
| 1 | What: /sys/firmware/efi/vars | ||
| 2 | Date: April 2004 | ||
| 3 | Contact: Matt Domsch <Matt_Domsch@dell.com> | ||
| 4 | Description: | ||
| 5 | This directory exposes interfaces for interactive with | ||
| 6 | EFI variables. For more information on EFI variables, | ||
| 7 | see 'Variable Services' in the UEFI specification | ||
| 8 | (section 7.2 in specification version 2.3 Errata D). | ||
| 9 | |||
| 10 | In summary, EFI variables are named, and are classified | ||
| 11 | into separate namespaces through the use of a vendor | ||
| 12 | GUID. They also have an arbitrary binary value | ||
| 13 | associated with them. | ||
| 14 | |||
| 15 | The efivars module enumerates these variables and | ||
| 16 | creates a separate directory for each one found. Each | ||
| 17 | directory has a name of the form "<key>-<vendor guid>" | ||
| 18 | and contains the following files: | ||
| 19 | |||
| 20 | attributes: A read-only text file enumerating the | ||
| 21 | EFI variable flags. Potential values | ||
| 22 | include: | ||
| 23 | |||
| 24 | EFI_VARIABLE_NON_VOLATILE | ||
| 25 | EFI_VARIABLE_BOOTSERVICE_ACCESS | ||
| 26 | EFI_VARIABLE_RUNTIME_ACCESS | ||
| 27 | EFI_VARIABLE_HARDWARE_ERROR_RECORD | ||
| 28 | EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS | ||
| 29 | |||
| 30 | See the EFI documentation for an | ||
| 31 | explanation of each of these variables. | ||
| 32 | |||
| 33 | data: A read-only binary file that can be read | ||
| 34 | to attain the value of the EFI variable | ||
| 35 | |||
| 36 | guid: The vendor GUID of the variable. This | ||
| 37 | should always match the GUID in the | ||
| 38 | variable's name. | ||
| 39 | |||
| 40 | raw_var: A binary file that can be read to obtain | ||
| 41 | a structure that contains everything | ||
| 42 | there is to know about the variable. | ||
| 43 | For structure definition see "struct | ||
| 44 | efi_variable" in the kernel sources. | ||
| 45 | |||
| 46 | This file can also be written to in | ||
| 47 | order to update the value of a variable. | ||
| 48 | For this to work however, all fields of | ||
| 49 | the "struct efi_variable" passed must | ||
| 50 | match byte for byte with the structure | ||
| 51 | read out of the file, save for the value | ||
| 52 | portion. | ||
| 53 | |||
| 54 | **Note** the efi_variable structure | ||
| 55 | read/written with this file contains a | ||
| 56 | 'long' type that may change widths | ||
| 57 | depending on your underlying | ||
| 58 | architecture. | ||
| 59 | |||
| 60 | size: As ASCII representation of the size of | ||
| 61 | the variable's value. | ||
| 62 | |||
| 63 | |||
| 64 | In addition, two other magic binary files are provided | ||
| 65 | in the top-level directory and are used for adding and | ||
| 66 | removing variables: | ||
| 67 | |||
| 68 | new_var: Takes a "struct efi_variable" and | ||
| 69 | instructs the EFI firmware to create a | ||
| 70 | new variable. | ||
| 71 | |||
| 72 | del_var: Takes a "struct efi_variable" and | ||
| 73 | instructs the EFI firmware to remove any | ||
| 74 | variable that has a matching vendor GUID | ||
| 75 | and variable key name. | ||
diff --git a/Documentation/ABI/testing/configfs-spear-pcie-gadget b/Documentation/ABI/testing/configfs-spear-pcie-gadget new file mode 100644 index 000000000000..875988146a63 --- /dev/null +++ b/Documentation/ABI/testing/configfs-spear-pcie-gadget | |||
| @@ -0,0 +1,31 @@ | |||
| 1 | What: /config/pcie-gadget | ||
| 2 | Date: Feb 2011 | ||
| 3 | KernelVersion: 2.6.37 | ||
| 4 | Contact: Pratyush Anand <pratyush.anand@st.com> | ||
| 5 | Description: | ||
| 6 | |||
| 7 | Interface is used to configure selected dual mode PCIe controller | ||
| 8 | as device and then program its various registers to configure it | ||
| 9 | as a particular device type. | ||
| 10 | This interfaces can be used to show spear's PCIe device capability. | ||
| 11 | |||
| 12 | Nodes are only visible when configfs is mounted. To mount configfs | ||
| 13 | in /config directory use: | ||
| 14 | # mount -t configfs none /config/ | ||
| 15 | |||
| 16 | For nth PCIe Device Controller | ||
| 17 | /config/pcie-gadget.n/ | ||
| 18 | link ... used to enable ltssm and read its status. | ||
| 19 | int_type ...used to configure and read type of supported | ||
| 20 | interrupt | ||
| 21 | no_of_msi ... used to configure number of MSI vector needed and | ||
| 22 | to read no of MSI granted. | ||
| 23 | inta ... write 1 to assert INTA and 0 to de-assert. | ||
| 24 | send_msi ... write MSI vector to be sent. | ||
| 25 | vendor_id ... used to write and read vendor id (hex) | ||
| 26 | device_id ... used to write and read device id (hex) | ||
| 27 | bar0_size ... used to write and read bar0_size | ||
| 28 | bar0_address ... used to write and read bar0 mapped area in hex. | ||
| 29 | bar0_rw_offset ... used to write and read offset of bar0 where | ||
| 30 | bar0_data will be written or read. | ||
| 31 | bar0_data ... used to write and read data at bar0_rw_offset. | ||
diff --git a/Documentation/ABI/testing/pstore b/Documentation/ABI/testing/pstore new file mode 100644 index 000000000000..ddf451ee2a08 --- /dev/null +++ b/Documentation/ABI/testing/pstore | |||
| @@ -0,0 +1,41 @@ | |||
| 1 | Where: /dev/pstore/... | ||
| 2 | Date: March 2011 | ||
| 3 | Kernel Version: 2.6.39 | ||
| 4 | Contact: tony.luck@intel.com | ||
| 5 | Description: Generic interface to platform dependent persistent storage. | ||
| 6 | |||
| 7 | Platforms that provide a mechanism to preserve some data | ||
| 8 | across system reboots can register with this driver to | ||
| 9 | provide a generic interface to show records captured in | ||
| 10 | the dying moments. In the case of a panic the last part | ||
| 11 | of the console log is captured, but other interesting | ||
| 12 | data can also be saved. | ||
| 13 | |||
| 14 | # mount -t pstore -o kmsg_bytes=8000 - /dev/pstore | ||
| 15 | |||
| 16 | $ ls -l /dev/pstore | ||
| 17 | total 0 | ||
| 18 | -r--r--r-- 1 root root 7896 Nov 30 15:38 dmesg-erst-1 | ||
| 19 | |||
| 20 | Different users of this interface will result in different | ||
| 21 | filename prefixes. Currently two are defined: | ||
| 22 | |||
| 23 | "dmesg" - saved console log | ||
| 24 | "mce" - architecture dependent data from fatal h/w error | ||
| 25 | |||
| 26 | Once the information in a file has been read, removing | ||
| 27 | the file will signal to the underlying persistent storage | ||
| 28 | device that it can reclaim the space for later re-use. | ||
| 29 | |||
| 30 | $ rm /dev/pstore/dmesg-erst-1 | ||
| 31 | |||
| 32 | The expectation is that all files in /dev/pstore | ||
| 33 | will be saved elsewhere and erased from persistent store | ||
| 34 | soon after boot to free up space ready for the next | ||
| 35 | catastrophe. | ||
| 36 | |||
| 37 | The 'kmsg_bytes' mount option changes the target amount of | ||
| 38 | data saved on each oops/panic. Pstore saves (possibly | ||
| 39 | multiple) files based on the record size of the underlying | ||
| 40 | persistent storage until at least this amount is reached. | ||
| 41 | Default is 10 Kbytes. | ||
diff --git a/Documentation/ABI/testing/sysfs-bus-css b/Documentation/ABI/testing/sysfs-bus-css index b585ec258a08..2979c40c10e9 100644 --- a/Documentation/ABI/testing/sysfs-bus-css +++ b/Documentation/ABI/testing/sysfs-bus-css | |||
| @@ -29,7 +29,7 @@ Contact: Cornelia Huck <cornelia.huck@de.ibm.com> | |||
| 29 | linux-s390@vger.kernel.org | 29 | linux-s390@vger.kernel.org |
| 30 | Description: Contains the PIM/PAM/POM values, as reported by the | 30 | Description: Contains the PIM/PAM/POM values, as reported by the |
| 31 | channel subsystem when last queried by the common I/O | 31 | channel subsystem when last queried by the common I/O |
| 32 | layer (this implies that this attribute is not neccessarily | 32 | layer (this implies that this attribute is not necessarily |
| 33 | in sync with the values current in the channel subsystem). | 33 | in sync with the values current in the channel subsystem). |
| 34 | Note: This is an I/O-subchannel specific attribute. | 34 | Note: This is an I/O-subchannel specific attribute. |
| 35 | Users: s390-tools, HAL | 35 | Users: s390-tools, HAL |
diff --git a/Documentation/ABI/testing/sysfs-bus-media b/Documentation/ABI/testing/sysfs-bus-media new file mode 100644 index 000000000000..7057e574154a --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-media | |||
| @@ -0,0 +1,6 @@ | |||
| 1 | What: /sys/bus/media/devices/.../model | ||
| 2 | Date: January 2011 | ||
| 3 | Contact: Laurent Pinchart <laurent.pinchart@ideasonboard.com> | ||
| 4 | linux-media@vger.kernel.org | ||
| 5 | Description: Contains the device model name in UTF-8. The device version is | ||
| 6 | is not be appended to the model name. | ||
diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci index f979d825d112..36bf454ba855 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci +++ b/Documentation/ABI/testing/sysfs-bus-pci | |||
| @@ -145,9 +145,11 @@ Date: July 2010 | |||
| 145 | Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com | 145 | Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com |
| 146 | Description: | 146 | Description: |
| 147 | Reading this attribute will provide the firmware | 147 | Reading this attribute will provide the firmware |
| 148 | given name(SMBIOS type 41 string) of the PCI device. | 148 | given name (SMBIOS type 41 string or ACPI _DSM string) of |
| 149 | The attribute will be created only if the firmware | 149 | the PCI device. The attribute will be created only |
| 150 | has given a name to the PCI device. | 150 | if the firmware has given a name to the PCI device. |
| 151 | ACPI _DSM string name will be given priority if the | ||
| 152 | system firmware provides SMBIOS type 41 string also. | ||
| 151 | Users: | 153 | Users: |
| 152 | Userspace applications interested in knowing the | 154 | Userspace applications interested in knowing the |
| 153 | firmware assigned name of the PCI device. | 155 | firmware assigned name of the PCI device. |
| @@ -157,12 +159,27 @@ Date: July 2010 | |||
| 157 | Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com | 159 | Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com |
| 158 | Description: | 160 | Description: |
| 159 | Reading this attribute will provide the firmware | 161 | Reading this attribute will provide the firmware |
| 160 | given instance(SMBIOS type 41 device type instance) | 162 | given instance (SMBIOS type 41 device type instance) of the |
| 161 | of the PCI device. The attribute will be created | 163 | PCI device. The attribute will be created only if the firmware |
| 162 | only if the firmware has given a device type instance | 164 | has given an instance number to the PCI device. |
| 163 | to the PCI device. | ||
| 164 | Users: | 165 | Users: |
| 165 | Userspace applications interested in knowing the | 166 | Userspace applications interested in knowing the |
| 166 | firmware assigned device type instance of the PCI | 167 | firmware assigned device type instance of the PCI |
| 167 | device that can help in understanding the firmware | 168 | device that can help in understanding the firmware |
| 168 | intended order of the PCI device. | 169 | intended order of the PCI device. |
| 170 | |||
| 171 | What: /sys/bus/pci/devices/.../acpi_index | ||
| 172 | Date: July 2010 | ||
| 173 | Contact: Narendra K <narendra_k@dell.com>, linux-bugs@dell.com | ||
| 174 | Description: | ||
| 175 | Reading this attribute will provide the firmware | ||
| 176 | given instance (ACPI _DSM instance number) of the PCI device. | ||
| 177 | The attribute will be created only if the firmware has given | ||
| 178 | an instance number to the PCI device. ACPI _DSM instance number | ||
| 179 | will be given priority if the system firmware provides SMBIOS | ||
| 180 | type 41 device type instance also. | ||
| 181 | Users: | ||
| 182 | Userspace applications interested in knowing the | ||
| 183 | firmware assigned instance number of the PCI | ||
| 184 | device that can help in understanding the firmware | ||
| 185 | intended order of the PCI device. | ||
diff --git a/Documentation/ABI/testing/sysfs-bus-pci-devices-cciss b/Documentation/ABI/testing/sysfs-bus-pci-devices-cciss index 4f29e5f1ebfa..f5bb0a3bb8c0 100644 --- a/Documentation/ABI/testing/sysfs-bus-pci-devices-cciss +++ b/Documentation/ABI/testing/sysfs-bus-pci-devices-cciss | |||
| @@ -59,3 +59,15 @@ Kernel Version: 2.6.31 | |||
| 59 | Contact: iss_storagedev@hp.com | 59 | Contact: iss_storagedev@hp.com |
| 60 | Description: Displays the usage count (number of opens) of logical drive Y | 60 | Description: Displays the usage count (number of opens) of logical drive Y |
| 61 | of controller X. | 61 | of controller X. |
| 62 | |||
| 63 | Where: /sys/bus/pci/devices/<dev>/ccissX/resettable | ||
| 64 | Date: February 2011 | ||
| 65 | Kernel Version: 2.6.38 | ||
| 66 | Contact: iss_storagedev@hp.com | ||
| 67 | Description: Value of 1 indicates the controller can honor the reset_devices | ||
| 68 | kernel parameter. Value of 0 indicates reset_devices cannot be | ||
| 69 | honored. This is to allow, for example, kexec tools to be able | ||
| 70 | to warn the user if they designate an unresettable device as | ||
| 71 | a dump device, as kdump requires resetting the device in order | ||
| 72 | to work reliably. | ||
| 73 | |||
diff --git a/Documentation/ABI/testing/sysfs-bus-rbd b/Documentation/ABI/testing/sysfs-bus-rbd index 90a87e2a572b..fa72ccb2282e 100644 --- a/Documentation/ABI/testing/sysfs-bus-rbd +++ b/Documentation/ABI/testing/sysfs-bus-rbd | |||
| @@ -1,6 +1,6 @@ | |||
| 1 | What: /sys/bus/rbd/ | 1 | What: /sys/bus/rbd/ |
| 2 | Date: November 2010 | 2 | Date: November 2010 |
| 3 | Contact: Yehuda Sadeh <yehuda@hq.newdream.net>, | 3 | Contact: Yehuda Sadeh <yehuda@newdream.net>, |
| 4 | Sage Weil <sage@newdream.net> | 4 | Sage Weil <sage@newdream.net> |
| 5 | Description: | 5 | Description: |
| 6 | 6 | ||
diff --git a/Documentation/ABI/testing/sysfs-class-led b/Documentation/ABI/testing/sysfs-class-led index edff6630c805..3646ec85d513 100644 --- a/Documentation/ABI/testing/sysfs-class-led +++ b/Documentation/ABI/testing/sysfs-class-led | |||
| @@ -33,5 +33,5 @@ Contact: Richard Purdie <rpurdie@rpsys.net> | |||
| 33 | Description: | 33 | Description: |
| 34 | Invert the LED on/off state. This parameter is specific to | 34 | Invert the LED on/off state. This parameter is specific to |
| 35 | gpio and backlight triggers. In case of the backlight trigger, | 35 | gpio and backlight triggers. In case of the backlight trigger, |
| 36 | it is usefull when driving a LED which is intended to indicate | 36 | it is useful when driving a LED which is intended to indicate |
| 37 | a device in a standby like state. | 37 | a device in a standby like state. |
diff --git a/Documentation/ABI/testing/sysfs-devices-mmc b/Documentation/ABI/testing/sysfs-devices-mmc new file mode 100644 index 000000000000..5a50ab655843 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-mmc | |||
| @@ -0,0 +1,21 @@ | |||
| 1 | What: /sys/devices/.../mmc_host/mmcX/mmcX:XXXX/enhanced_area_offset | ||
| 2 | Date: January 2011 | ||
| 3 | Contact: Chuanxiao Dong <chuanxiao.dong@intel.com> | ||
| 4 | Description: | ||
| 5 | Enhanced area is a new feature defined in eMMC4.4 standard. | ||
| 6 | eMMC4.4 or later card can support such feature. This kind of | ||
| 7 | area can help to improve the card performance. If the feature | ||
| 8 | is enabled, this attribute will indicate the start address of | ||
| 9 | enhanced data area. If not, this attribute will be -EINVAL. | ||
| 10 | Unit Byte. Format decimal. | ||
| 11 | |||
| 12 | What: /sys/devices/.../mmc_host/mmcX/mmcX:XXXX/enhanced_area_size | ||
| 13 | Date: January 2011 | ||
| 14 | Contact: Chuanxiao Dong <chuanxiao.dong@intel.com> | ||
| 15 | Description: | ||
| 16 | Enhanced area is a new feature defined in eMMC4.4 standard. | ||
| 17 | eMMC4.4 or later card can support such feature. This kind of | ||
| 18 | area can help to improve the card performance. If the feature | ||
| 19 | is enabled, this attribute will indicate the size of enhanced | ||
| 20 | data area. If not, this attribute will be -EINVAL. | ||
| 21 | Unit KByte. Format decimal. | ||
diff --git a/Documentation/ABI/testing/sysfs-devices-power b/Documentation/ABI/testing/sysfs-devices-power index 7628cd1bc36a..8ffbc25376a0 100644 --- a/Documentation/ABI/testing/sysfs-devices-power +++ b/Documentation/ABI/testing/sysfs-devices-power | |||
| @@ -29,9 +29,8 @@ Description: | |||
| 29 | "disabled" to it. | 29 | "disabled" to it. |
| 30 | 30 | ||
| 31 | For the devices that are not capable of generating system wakeup | 31 | For the devices that are not capable of generating system wakeup |
| 32 | events this file contains "\n". In that cases the user space | 32 | events this file is not present. In that case the device cannot |
| 33 | cannot modify the contents of this file and the device cannot be | 33 | be enabled to wake up the system from sleep states. |
| 34 | enabled to wake up the system. | ||
| 35 | 34 | ||
| 36 | What: /sys/devices/.../power/control | 35 | What: /sys/devices/.../power/control |
| 37 | Date: January 2009 | 36 | Date: January 2009 |
| @@ -85,7 +84,7 @@ Description: | |||
| 85 | The /sys/devices/.../wakeup_count attribute contains the number | 84 | The /sys/devices/.../wakeup_count attribute contains the number |
| 86 | of signaled wakeup events associated with the device. This | 85 | of signaled wakeup events associated with the device. This |
| 87 | attribute is read-only. If the device is not enabled to wake up | 86 | attribute is read-only. If the device is not enabled to wake up |
| 88 | the system from sleep states, this attribute is empty. | 87 | the system from sleep states, this attribute is not present. |
| 89 | 88 | ||
| 90 | What: /sys/devices/.../power/wakeup_active_count | 89 | What: /sys/devices/.../power/wakeup_active_count |
| 91 | Date: September 2010 | 90 | Date: September 2010 |
| @@ -95,7 +94,7 @@ Description: | |||
| 95 | number of times the processing of wakeup events associated with | 94 | number of times the processing of wakeup events associated with |
| 96 | the device was completed (at the kernel level). This attribute | 95 | the device was completed (at the kernel level). This attribute |
| 97 | is read-only. If the device is not enabled to wake up the | 96 | is read-only. If the device is not enabled to wake up the |
| 98 | system from sleep states, this attribute is empty. | 97 | system from sleep states, this attribute is not present. |
| 99 | 98 | ||
| 100 | What: /sys/devices/.../power/wakeup_hit_count | 99 | What: /sys/devices/.../power/wakeup_hit_count |
| 101 | Date: September 2010 | 100 | Date: September 2010 |
| @@ -105,7 +104,8 @@ Description: | |||
| 105 | number of times the processing of a wakeup event associated with | 104 | number of times the processing of a wakeup event associated with |
| 106 | the device might prevent the system from entering a sleep state. | 105 | the device might prevent the system from entering a sleep state. |
| 107 | This attribute is read-only. If the device is not enabled to | 106 | This attribute is read-only. If the device is not enabled to |
| 108 | wake up the system from sleep states, this attribute is empty. | 107 | wake up the system from sleep states, this attribute is not |
| 108 | present. | ||
| 109 | 109 | ||
| 110 | What: /sys/devices/.../power/wakeup_active | 110 | What: /sys/devices/.../power/wakeup_active |
| 111 | Date: September 2010 | 111 | Date: September 2010 |
| @@ -115,7 +115,7 @@ Description: | |||
| 115 | or 0, depending on whether or not a wakeup event associated with | 115 | or 0, depending on whether or not a wakeup event associated with |
| 116 | the device is being processed (1). This attribute is read-only. | 116 | the device is being processed (1). This attribute is read-only. |
| 117 | If the device is not enabled to wake up the system from sleep | 117 | If the device is not enabled to wake up the system from sleep |
| 118 | states, this attribute is empty. | 118 | states, this attribute is not present. |
| 119 | 119 | ||
| 120 | What: /sys/devices/.../power/wakeup_total_time_ms | 120 | What: /sys/devices/.../power/wakeup_total_time_ms |
| 121 | Date: September 2010 | 121 | Date: September 2010 |
| @@ -125,7 +125,7 @@ Description: | |||
| 125 | the total time of processing wakeup events associated with the | 125 | the total time of processing wakeup events associated with the |
| 126 | device, in milliseconds. This attribute is read-only. If the | 126 | device, in milliseconds. This attribute is read-only. If the |
| 127 | device is not enabled to wake up the system from sleep states, | 127 | device is not enabled to wake up the system from sleep states, |
| 128 | this attribute is empty. | 128 | this attribute is not present. |
| 129 | 129 | ||
| 130 | What: /sys/devices/.../power/wakeup_max_time_ms | 130 | What: /sys/devices/.../power/wakeup_max_time_ms |
| 131 | Date: September 2010 | 131 | Date: September 2010 |
| @@ -135,7 +135,7 @@ Description: | |||
| 135 | the maximum time of processing a single wakeup event associated | 135 | the maximum time of processing a single wakeup event associated |
| 136 | with the device, in milliseconds. This attribute is read-only. | 136 | with the device, in milliseconds. This attribute is read-only. |
| 137 | If the device is not enabled to wake up the system from sleep | 137 | If the device is not enabled to wake up the system from sleep |
| 138 | states, this attribute is empty. | 138 | states, this attribute is not present. |
| 139 | 139 | ||
| 140 | What: /sys/devices/.../power/wakeup_last_time_ms | 140 | What: /sys/devices/.../power/wakeup_last_time_ms |
| 141 | Date: September 2010 | 141 | Date: September 2010 |
| @@ -146,7 +146,7 @@ Description: | |||
| 146 | signaling the last wakeup event associated with the device, in | 146 | signaling the last wakeup event associated with the device, in |
| 147 | milliseconds. This attribute is read-only. If the device is | 147 | milliseconds. This attribute is read-only. If the device is |
| 148 | not enabled to wake up the system from sleep states, this | 148 | not enabled to wake up the system from sleep states, this |
| 149 | attribute is empty. | 149 | attribute is not present. |
| 150 | 150 | ||
| 151 | What: /sys/devices/.../power/autosuspend_delay_ms | 151 | What: /sys/devices/.../power/autosuspend_delay_ms |
| 152 | Date: September 2010 | 152 | Date: September 2010 |
diff --git a/Documentation/ABI/testing/sysfs-driver-hid b/Documentation/ABI/testing/sysfs-driver-hid new file mode 100644 index 000000000000..b6490e14fe83 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-hid | |||
| @@ -0,0 +1,10 @@ | |||
| 1 | What: For USB devices : /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/report_descriptor | ||
| 2 | For BT devices : /sys/class/bluetooth/hci<addr>/<hid-bus>:<vendor-id>:<product-id>.<num>/report_descriptor | ||
| 3 | Symlink : /sys/class/hidraw/hidraw<num>/device/report_descriptor | ||
| 4 | Date: Jan 2011 | ||
| 5 | KernelVersion: 2.0.39 | ||
| 6 | Contact: Alan Ott <alan@signal11.us> | ||
| 7 | Description: When read, this file returns the device's raw binary HID | ||
| 8 | report descriptor. | ||
| 9 | This file cannot be written. | ||
| 10 | Users: HIDAPI library (http://www.signal11.us/oss/hidapi) | ||
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-arvo b/Documentation/ABI/testing/sysfs-driver-hid-roccat-arvo new file mode 100644 index 000000000000..55e281b0071a --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-arvo | |||
| @@ -0,0 +1,53 @@ | |||
| 1 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/arvo/roccatarvo<minor>/actual_profile | ||
| 2 | Date: Januar 2011 | ||
| 3 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> | ||
| 4 | Description: The integer value of this attribute ranges from 1-5. | ||
| 5 | When read, this attribute returns the number of the actual | ||
| 6 | profile which is also the profile that's active on device startup. | ||
| 7 | When written this attribute activates the selected profile | ||
| 8 | immediately. | ||
| 9 | Users: http://roccat.sourceforge.net | ||
| 10 | |||
| 11 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/arvo/roccatarvo<minor>/button | ||
| 12 | Date: Januar 2011 | ||
| 13 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> | ||
| 14 | Description: The keyboard can store short macros with consist of 1 button with | ||
| 15 | several modifier keys internally. | ||
| 16 | When written, this file lets one set the sequence for a specific | ||
| 17 | button for a specific profile. Button and profile numbers are | ||
| 18 | included in written data. The data has to be 24 bytes long. | ||
| 19 | This file is writeonly. | ||
| 20 | Users: http://roccat.sourceforge.net | ||
| 21 | |||
| 22 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/arvo/roccatarvo<minor>/info | ||
| 23 | Date: Januar 2011 | ||
| 24 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> | ||
| 25 | Description: When read, this file returns some info about the device like the | ||
| 26 | installed firmware version. | ||
| 27 | The size of the data is 8 bytes in size. | ||
| 28 | This file is readonly. | ||
| 29 | Users: http://roccat.sourceforge.net | ||
| 30 | |||
| 31 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/arvo/roccatarvo<minor>/key_mask | ||
| 32 | Date: Januar 2011 | ||
| 33 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> | ||
| 34 | Description: The keyboard lets the user deactivate 5 certain keys like the | ||
| 35 | windows and application keys, to protect the user from the outcome | ||
| 36 | of accidentally pressing them. | ||
| 37 | The integer value of this attribute has bits 0-4 set depending | ||
| 38 | on the state of the corresponding key. | ||
| 39 | When read, this file returns the current state of the buttons. | ||
| 40 | When written, the given buttons are activated/deactivated | ||
| 41 | immediately. | ||
| 42 | Users: http://roccat.sourceforge.net | ||
| 43 | |||
| 44 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/arvo/roccatarvo<minor>/mode_key | ||
| 45 | Date: Januar 2011 | ||
| 46 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> | ||
| 47 | Description: The keyboard has a condensed layout without num-lock key. | ||
| 48 | Instead it uses a mode-key which activates a gaming mode where | ||
| 49 | the assignment of the number block changes. | ||
| 50 | The integer value of this attribute ranges from 0 (OFF) to 1 (ON). | ||
| 51 | When read, this file returns the actual state of the key. | ||
| 52 | When written, the key is activated/deactivated immediately. | ||
| 53 | Users: http://roccat.sourceforge.net | ||
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-kone b/Documentation/ABI/testing/sysfs-driver-hid-roccat-kone index 698b8081c473..3ca3971109bf 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-kone +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-kone | |||
| @@ -16,12 +16,14 @@ Description: It is possible to switch the dpi setting of the mouse with the | |||
| 16 | 6 3200 | 16 | 6 3200 |
| 17 | 17 | ||
| 18 | This file is readonly. | 18 | This file is readonly. |
| 19 | Users: http://roccat.sourceforge.net | ||
| 19 | 20 | ||
| 20 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/actual_profile | 21 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/actual_profile |
| 21 | Date: March 2010 | 22 | Date: March 2010 |
| 22 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> | 23 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> |
| 23 | Description: When read, this file returns the number of the actual profile. | 24 | Description: When read, this file returns the number of the actual profile. |
| 24 | This file is readonly. | 25 | This file is readonly. |
| 26 | Users: http://roccat.sourceforge.net | ||
| 25 | 27 | ||
| 26 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/firmware_version | 28 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/firmware_version |
| 27 | Date: March 2010 | 29 | Date: March 2010 |
| @@ -32,12 +34,13 @@ Description: When read, this file returns the raw integer version number of the | |||
| 32 | number the decimal point has to be shifted 2 positions to the | 34 | number the decimal point has to be shifted 2 positions to the |
| 33 | left. E.g. a returned value of 138 means 1.38 | 35 | left. E.g. a returned value of 138 means 1.38 |
| 34 | This file is readonly. | 36 | This file is readonly. |
| 37 | Users: http://roccat.sourceforge.net | ||
| 35 | 38 | ||
| 36 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/profile[1-5] | 39 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/profile[1-5] |
| 37 | Date: March 2010 | 40 | Date: March 2010 |
| 38 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> | 41 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> |
| 39 | Description: The mouse can store 5 profiles which can be switched by the | 42 | Description: The mouse can store 5 profiles which can be switched by the |
| 40 | press of a button. A profile holds informations like button | 43 | press of a button. A profile holds information like button |
| 41 | mappings, sensitivity, the colors of the 5 leds and light | 44 | mappings, sensitivity, the colors of the 5 leds and light |
| 42 | effects. | 45 | effects. |
| 43 | When read, these files return the respective profile. The | 46 | 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 | |||
| 47 | The mouse will reject invalid data, whereas the profile number | 50 | The mouse will reject invalid data, whereas the profile number |
| 48 | stored in the profile doesn't need to fit the number of the | 51 | stored in the profile doesn't need to fit the number of the |
| 49 | store. | 52 | store. |
| 53 | Users: http://roccat.sourceforge.net | ||
| 50 | 54 | ||
| 51 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/settings | 55 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/settings |
| 52 | Date: March 2010 | 56 | Date: March 2010 |
| @@ -57,6 +61,7 @@ Description: When read, this file returns the settings stored in the mouse. | |||
| 57 | When written, this file lets write settings back to the mouse. | 61 | When written, this file lets write settings back to the mouse. |
| 58 | The data has to be 36 bytes long. The mouse will reject invalid | 62 | The data has to be 36 bytes long. The mouse will reject invalid |
| 59 | data. | 63 | data. |
| 64 | Users: http://roccat.sourceforge.net | ||
| 60 | 65 | ||
| 61 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/startup_profile | 66 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/startup_profile |
| 62 | Date: March 2010 | 67 | Date: March 2010 |
| @@ -66,6 +71,7 @@ Description: The integer value of this attribute ranges from 1 to 5. | |||
| 66 | that's active when the mouse is powered on. | 71 | that's active when the mouse is powered on. |
| 67 | When written, this file sets the number of the startup profile | 72 | When written, this file sets the number of the startup profile |
| 68 | and the mouse activates this profile immediately. | 73 | and the mouse activates this profile immediately. |
| 74 | Users: http://roccat.sourceforge.net | ||
| 69 | 75 | ||
| 70 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/tcu | 76 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/tcu |
| 71 | Date: March 2010 | 77 | Date: March 2010 |
| @@ -77,6 +83,7 @@ Description: The mouse has a "Tracking Control Unit" which lets the user | |||
| 77 | Writing 0 in this file will switch the TCU off. | 83 | Writing 0 in this file will switch the TCU off. |
| 78 | Writing 1 in this file will start the calibration which takes | 84 | Writing 1 in this file will start the calibration which takes |
| 79 | around 6 seconds to complete and activates the TCU. | 85 | around 6 seconds to complete and activates the TCU. |
| 86 | Users: http://roccat.sourceforge.net | ||
| 80 | 87 | ||
| 81 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/weight | 88 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kone/roccatkone<minor>/weight |
| 82 | Date: March 2010 | 89 | Date: March 2010 |
| @@ -96,3 +103,4 @@ Description: The mouse can be equipped with one of four supplied weights | |||
| 96 | 4 20g | 103 | 4 20g |
| 97 | 104 | ||
| 98 | This file is readonly. | 105 | This file is readonly. |
| 106 | Users: http://roccat.sourceforge.net | ||
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus b/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus index 0f9f30eb1742..326e05452da7 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus | |||
| @@ -4,6 +4,7 @@ Contact: Stefan Achatz <erazor_de@users.sourceforge.net> | |||
| 4 | Description: When read, this file returns the number of the actual profile in | 4 | Description: When read, this file returns the number of the actual profile in |
| 5 | range 0-4. | 5 | range 0-4. |
| 6 | This file is readonly. | 6 | This file is readonly. |
| 7 | Users: http://roccat.sourceforge.net | ||
| 7 | 8 | ||
| 8 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/firmware_version | 9 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/firmware_version |
| 9 | Date: October 2010 | 10 | Date: October 2010 |
| @@ -14,6 +15,7 @@ Description: When read, this file returns the raw integer version number of the | |||
| 14 | number the decimal point has to be shifted 2 positions to the | 15 | number the decimal point has to be shifted 2 positions to the |
| 15 | left. E.g. a returned value of 121 means 1.21 | 16 | left. E.g. a returned value of 121 means 1.21 |
| 16 | This file is readonly. | 17 | This file is readonly. |
| 18 | Users: http://roccat.sourceforge.net | ||
| 17 | 19 | ||
| 18 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/macro | 20 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/macro |
| 19 | Date: October 2010 | 21 | Date: October 2010 |
| @@ -24,36 +26,39 @@ Description: The mouse can store a macro with max 500 key/button strokes | |||
| 24 | button for a specific profile. Button and profile numbers are | 26 | button for a specific profile. Button and profile numbers are |
| 25 | included in written data. The data has to be 2082 bytes long. | 27 | included in written data. The data has to be 2082 bytes long. |
| 26 | This file is writeonly. | 28 | This file is writeonly. |
| 29 | Users: http://roccat.sourceforge.net | ||
| 27 | 30 | ||
| 28 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile_buttons | 31 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile_buttons |
| 29 | Date: August 2010 | 32 | Date: August 2010 |
| 30 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> | 33 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> |
| 31 | Description: The mouse can store 5 profiles which can be switched by the | 34 | Description: The mouse can store 5 profiles which can be switched by the |
| 32 | press of a button. A profile is split in settings and buttons. | 35 | press of a button. A profile is split in settings and buttons. |
| 33 | profile_buttons holds informations about button layout. | 36 | profile_buttons holds information about button layout. |
| 34 | When written, this file lets one write the respective profile | 37 | When written, this file lets one write the respective profile |
| 35 | buttons back to the mouse. The data has to be 77 bytes long. | 38 | buttons back to the mouse. The data has to be 77 bytes long. |
| 36 | The mouse will reject invalid data. | 39 | The mouse will reject invalid data. |
| 37 | Which profile to write is determined by the profile number | 40 | Which profile to write is determined by the profile number |
| 38 | contained in the data. | 41 | contained in the data. |
| 39 | This file is writeonly. | 42 | This file is writeonly. |
| 43 | Users: http://roccat.sourceforge.net | ||
| 40 | 44 | ||
| 41 | 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 | 45 | 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 |
| 42 | Date: August 2010 | 46 | Date: August 2010 |
| 43 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> | 47 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> |
| 44 | Description: The mouse can store 5 profiles which can be switched by the | 48 | Description: The mouse can store 5 profiles which can be switched by the |
| 45 | press of a button. A profile is split in settings and buttons. | 49 | press of a button. A profile is split in settings and buttons. |
| 46 | profile_buttons holds informations about button layout. | 50 | profile_buttons holds information about button layout. |
| 47 | When read, these files return the respective profile buttons. | 51 | When read, these files return the respective profile buttons. |
| 48 | The returned data is 77 bytes in size. | 52 | The returned data is 77 bytes in size. |
| 49 | This file is readonly. | 53 | This file is readonly. |
| 54 | Users: http://roccat.sourceforge.net | ||
| 50 | 55 | ||
| 51 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile_settings | 56 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile_settings |
| 52 | Date: October 2010 | 57 | Date: October 2010 |
| 53 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> | 58 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> |
| 54 | Description: The mouse can store 5 profiles which can be switched by the | 59 | Description: The mouse can store 5 profiles which can be switched by the |
| 55 | press of a button. A profile is split in settings and buttons. | 60 | press of a button. A profile is split in settings and buttons. |
| 56 | profile_settings holds informations like resolution, sensitivity | 61 | profile_settings holds information like resolution, sensitivity |
| 57 | and light effects. | 62 | and light effects. |
| 58 | When written, this file lets one write the respective profile | 63 | When written, this file lets one write the respective profile |
| 59 | settings back to the mouse. The data has to be 43 bytes long. | 64 | 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 | |||
| 61 | Which profile to write is determined by the profile number | 66 | Which profile to write is determined by the profile number |
| 62 | contained in the data. | 67 | contained in the data. |
| 63 | This file is writeonly. | 68 | This file is writeonly. |
| 69 | Users: http://roccat.sourceforge.net | ||
| 64 | 70 | ||
| 65 | 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 | 71 | 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 |
| 66 | Date: August 2010 | 72 | Date: August 2010 |
| 67 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> | 73 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> |
| 68 | Description: The mouse can store 5 profiles which can be switched by the | 74 | Description: The mouse can store 5 profiles which can be switched by the |
| 69 | press of a button. A profile is split in settings and buttons. | 75 | press of a button. A profile is split in settings and buttons. |
| 70 | profile_settings holds informations like resolution, sensitivity | 76 | profile_settings holds information like resolution, sensitivity |
| 71 | and light effects. | 77 | and light effects. |
| 72 | When read, these files return the respective profile settings. | 78 | When read, these files return the respective profile settings. |
| 73 | The returned data is 43 bytes in size. | 79 | The returned data is 43 bytes in size. |
| 74 | This file is readonly. | 80 | This file is readonly. |
| 81 | Users: http://roccat.sourceforge.net | ||
| 75 | 82 | ||
| 76 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/sensor | 83 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/sensor |
| 77 | Date: October 2010 | 84 | Date: October 2010 |
| @@ -80,6 +87,7 @@ Description: The mouse has a tracking- and a distance-control-unit. These | |||
| 80 | can be activated/deactivated and the lift-off distance can be | 87 | can be activated/deactivated and the lift-off distance can be |
| 81 | set. The data has to be 6 bytes long. | 88 | set. The data has to be 6 bytes long. |
| 82 | This file is writeonly. | 89 | This file is writeonly. |
| 90 | Users: http://roccat.sourceforge.net | ||
| 83 | 91 | ||
| 84 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/startup_profile | 92 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/startup_profile |
| 85 | Date: October 2010 | 93 | Date: October 2010 |
| @@ -89,6 +97,7 @@ Description: The integer value of this attribute ranges from 0-4. | |||
| 89 | that's active when the mouse is powered on. | 97 | that's active when the mouse is powered on. |
| 90 | When written, this file sets the number of the startup profile | 98 | When written, this file sets the number of the startup profile |
| 91 | and the mouse activates this profile immediately. | 99 | and the mouse activates this profile immediately. |
| 100 | Users: http://roccat.sourceforge.net | ||
| 92 | 101 | ||
| 93 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/tcu | 102 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/tcu |
| 94 | Date: October 2010 | 103 | Date: October 2010 |
| @@ -97,6 +106,7 @@ Description: When written a calibration process for the tracking control unit | |||
| 97 | can be initiated/cancelled. | 106 | can be initiated/cancelled. |
| 98 | The data has to be 3 bytes long. | 107 | The data has to be 3 bytes long. |
| 99 | This file is writeonly. | 108 | This file is writeonly. |
| 109 | Users: http://roccat.sourceforge.net | ||
| 100 | 110 | ||
| 101 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/tcu_image | 111 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/tcu_image |
| 102 | Date: October 2010 | 112 | Date: October 2010 |
| @@ -106,3 +116,4 @@ Description: When read the mouse returns a 30x30 pixel image of the | |||
| 106 | calibration process initiated with tcu. | 116 | calibration process initiated with tcu. |
| 107 | The returned data is 1028 bytes in size. | 117 | The returned data is 1028 bytes in size. |
| 108 | This file is readonly. | 118 | This file is readonly. |
| 119 | Users: http://roccat.sourceforge.net | ||
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus b/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus new file mode 100644 index 000000000000..20f937c9d84f --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus | |||
| @@ -0,0 +1,100 @@ | |||
| 1 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_cpi | ||
| 2 | Date: January 2011 | ||
| 3 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> | ||
| 4 | Description: The integer value of this attribute ranges from 1-4. | ||
| 5 | When read, this attribute returns the number of the active | ||
| 6 | cpi level. | ||
| 7 | This file is readonly. | ||
| 8 | Users: http://roccat.sourceforge.net | ||
| 9 | |||
| 10 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_profile | ||
| 11 | Date: January 2011 | ||
| 12 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> | ||
| 13 | Description: The integer value of this attribute ranges from 0-4. | ||
| 14 | When read, this attribute returns the number of the active | ||
| 15 | profile. | ||
| 16 | When written, the mouse activates this profile immediately. | ||
| 17 | The profile that's active when powered down is the same that's | ||
| 18 | active when the mouse is powered on. | ||
| 19 | Users: http://roccat.sourceforge.net | ||
| 20 | |||
| 21 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_sensitivity_x | ||
| 22 | Date: January 2011 | ||
| 23 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> | ||
| 24 | Description: The integer value of this attribute ranges from 1-10. | ||
| 25 | When read, this attribute returns the number of the actual | ||
| 26 | sensitivity in x direction. | ||
| 27 | This file is readonly. | ||
| 28 | Users: http://roccat.sourceforge.net | ||
| 29 | |||
| 30 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_sensitivity_y | ||
| 31 | Date: January 2011 | ||
| 32 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> | ||
| 33 | Description: The integer value of this attribute ranges from 1-10. | ||
| 34 | When read, this attribute returns the number of the actual | ||
| 35 | sensitivity in y direction. | ||
| 36 | This file is readonly. | ||
| 37 | Users: http://roccat.sourceforge.net | ||
| 38 | |||
| 39 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/firmware_version | ||
| 40 | Date: January 2011 | ||
| 41 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> | ||
| 42 | Description: When read, this file returns the raw integer version number of the | ||
| 43 | firmware reported by the mouse. Using the integer value eases | ||
| 44 | further usage in other programs. To receive the real version | ||
| 45 | number the decimal point has to be shifted 2 positions to the | ||
| 46 | left. E.g. a returned value of 121 means 1.21 | ||
| 47 | This file is readonly. | ||
| 48 | Users: http://roccat.sourceforge.net | ||
| 49 | |||
| 50 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/profile_buttons | ||
| 51 | Date: January 2011 | ||
| 52 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> | ||
| 53 | Description: The mouse can store 5 profiles which can be switched by the | ||
| 54 | press of a button. A profile is split in settings and buttons. | ||
| 55 | profile_buttons holds information about button layout. | ||
| 56 | When written, this file lets one write the respective profile | ||
| 57 | buttons back to the mouse. The data has to be 23 bytes long. | ||
| 58 | The mouse will reject invalid data. | ||
| 59 | Which profile to write is determined by the profile number | ||
| 60 | contained in the data. | ||
| 61 | This file is writeonly. | ||
| 62 | Users: http://roccat.sourceforge.net | ||
| 63 | |||
| 64 | 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 | ||
| 65 | Date: January 2011 | ||
| 66 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> | ||
| 67 | Description: The mouse can store 5 profiles which can be switched by the | ||
| 68 | press of a button. A profile is split in settings and buttons. | ||
| 69 | profile_buttons holds information about button layout. | ||
| 70 | When read, these files return the respective profile buttons. | ||
| 71 | The returned data is 23 bytes in size. | ||
| 72 | This file is readonly. | ||
| 73 | Users: http://roccat.sourceforge.net | ||
| 74 | |||
| 75 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/profile_settings | ||
| 76 | Date: January 2011 | ||
| 77 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> | ||
| 78 | Description: The mouse can store 5 profiles which can be switched by the | ||
| 79 | press of a button. A profile is split in settings and buttons. | ||
| 80 | profile_settings holds information like resolution, sensitivity | ||
| 81 | and light effects. | ||
| 82 | When written, this file lets one write the respective profile | ||
| 83 | settings back to the mouse. The data has to be 16 bytes long. | ||
| 84 | The mouse will reject invalid data. | ||
| 85 | Which profile to write is determined by the profile number | ||
| 86 | contained in the data. | ||
| 87 | This file is writeonly. | ||
| 88 | Users: http://roccat.sourceforge.net | ||
| 89 | |||
| 90 | 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 | ||
| 91 | Date: January 2011 | ||
| 92 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> | ||
| 93 | Description: The mouse can store 5 profiles which can be switched by the | ||
| 94 | press of a button. A profile is split in settings and buttons. | ||
| 95 | profile_settings holds information like resolution, sensitivity | ||
| 96 | and light effects. | ||
| 97 | When read, these files return the respective profile settings. | ||
| 98 | The returned data is 16 bytes in size. | ||
| 99 | This file is readonly. | ||
| 100 | Users: http://roccat.sourceforge.net | ||
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra b/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra index 1c37b823f142..3f8de50e4ff1 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra | |||
| @@ -13,6 +13,7 @@ Description: It is possible to switch the cpi setting of the mouse with the | |||
| 13 | 4 1600 | 13 | 4 1600 |
| 14 | 14 | ||
| 15 | This file is readonly. | 15 | This file is readonly. |
| 16 | Users: http://roccat.sourceforge.net | ||
| 16 | 17 | ||
| 17 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/actual_profile | 18 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/actual_profile |
| 18 | Date: August 2010 | 19 | Date: August 2010 |
| @@ -20,6 +21,7 @@ Contact: Stefan Achatz <erazor_de@users.sourceforge.net> | |||
| 20 | Description: When read, this file returns the number of the actual profile in | 21 | Description: When read, this file returns the number of the actual profile in |
| 21 | range 0-4. | 22 | range 0-4. |
| 22 | This file is readonly. | 23 | This file is readonly. |
| 24 | Users: http://roccat.sourceforge.net | ||
| 23 | 25 | ||
| 24 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/firmware_version | 26 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/firmware_version |
| 25 | Date: August 2010 | 27 | Date: August 2010 |
| @@ -30,13 +32,14 @@ Description: When read, this file returns the raw integer version number of the | |||
| 30 | number the decimal point has to be shifted 2 positions to the | 32 | number the decimal point has to be shifted 2 positions to the |
| 31 | left. E.g. a returned value of 138 means 1.38 | 33 | left. E.g. a returned value of 138 means 1.38 |
| 32 | This file is readonly. | 34 | This file is readonly. |
| 35 | Users: http://roccat.sourceforge.net | ||
| 33 | 36 | ||
| 34 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile_settings | 37 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile_settings |
| 35 | Date: August 2010 | 38 | Date: August 2010 |
| 36 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> | 39 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> |
| 37 | Description: The mouse can store 5 profiles which can be switched by the | 40 | Description: The mouse can store 5 profiles which can be switched by the |
| 38 | press of a button. A profile is split in settings and buttons. | 41 | press of a button. A profile is split in settings and buttons. |
| 39 | profile_settings holds informations like resolution, sensitivity | 42 | profile_settings holds information like resolution, sensitivity |
| 40 | and light effects. | 43 | and light effects. |
| 41 | When written, this file lets one write the respective profile | 44 | When written, this file lets one write the respective profile |
| 42 | settings back to the mouse. The data has to be 13 bytes long. | 45 | 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 | |||
| 44 | Which profile to write is determined by the profile number | 47 | Which profile to write is determined by the profile number |
| 45 | contained in the data. | 48 | contained in the data. |
| 46 | This file is writeonly. | 49 | This file is writeonly. |
| 50 | Users: http://roccat.sourceforge.net | ||
| 47 | 51 | ||
| 48 | 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 | 52 | 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 |
| 49 | Date: August 2010 | 53 | Date: August 2010 |
| 50 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> | 54 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> |
| 51 | Description: The mouse can store 5 profiles which can be switched by the | 55 | Description: The mouse can store 5 profiles which can be switched by the |
| 52 | press of a button. A profile is split in settings and buttons. | 56 | press of a button. A profile is split in settings and buttons. |
| 53 | profile_settings holds informations like resolution, sensitivity | 57 | profile_settings holds information like resolution, sensitivity |
| 54 | and light effects. | 58 | and light effects. |
| 55 | When read, these files return the respective profile settings. | 59 | When read, these files return the respective profile settings. |
| 56 | The returned data is 13 bytes in size. | 60 | The returned data is 13 bytes in size. |
| 57 | This file is readonly. | 61 | This file is readonly. |
| 62 | Users: http://roccat.sourceforge.net | ||
| 58 | 63 | ||
| 59 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile_buttons | 64 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile_buttons |
| 60 | Date: August 2010 | 65 | Date: August 2010 |
| 61 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> | 66 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> |
| 62 | Description: The mouse can store 5 profiles which can be switched by the | 67 | Description: The mouse can store 5 profiles which can be switched by the |
| 63 | press of a button. A profile is split in settings and buttons. | 68 | press of a button. A profile is split in settings and buttons. |
| 64 | profile_buttons holds informations about button layout. | 69 | profile_buttons holds information about button layout. |
| 65 | When written, this file lets one write the respective profile | 70 | When written, this file lets one write the respective profile |
| 66 | buttons back to the mouse. The data has to be 19 bytes long. | 71 | buttons back to the mouse. The data has to be 19 bytes long. |
| 67 | The mouse will reject invalid data. | 72 | The mouse will reject invalid data. |
| 68 | Which profile to write is determined by the profile number | 73 | Which profile to write is determined by the profile number |
| 69 | contained in the data. | 74 | contained in the data. |
| 70 | This file is writeonly. | 75 | This file is writeonly. |
| 76 | Users: http://roccat.sourceforge.net | ||
| 71 | 77 | ||
| 72 | 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 | 78 | 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 |
| 73 | Date: August 2010 | 79 | Date: August 2010 |
| 74 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> | 80 | Contact: Stefan Achatz <erazor_de@users.sourceforge.net> |
| 75 | Description: The mouse can store 5 profiles which can be switched by the | 81 | Description: The mouse can store 5 profiles which can be switched by the |
| 76 | press of a button. A profile is split in settings and buttons. | 82 | press of a button. A profile is split in settings and buttons. |
| 77 | profile_buttons holds informations about button layout. | 83 | profile_buttons holds information about button layout. |
| 78 | When read, these files return the respective profile buttons. | 84 | When read, these files return the respective profile buttons. |
| 79 | The returned data is 19 bytes in size. | 85 | The returned data is 19 bytes in size. |
| 80 | This file is readonly. | 86 | This file is readonly. |
| 87 | Users: http://roccat.sourceforge.net | ||
| 81 | 88 | ||
| 82 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/startup_profile | 89 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/startup_profile |
| 83 | Date: August 2010 | 90 | Date: August 2010 |
| @@ -86,6 +93,7 @@ Description: The integer value of this attribute ranges from 0-4. | |||
| 86 | When read, this attribute returns the number of the profile | 93 | When read, this attribute returns the number of the profile |
| 87 | that's active when the mouse is powered on. | 94 | that's active when the mouse is powered on. |
| 88 | This file is readonly. | 95 | This file is readonly. |
| 96 | Users: http://roccat.sourceforge.net | ||
| 89 | 97 | ||
| 90 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/settings | 98 | What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/settings |
| 91 | Date: August 2010 | 99 | Date: August 2010 |
| @@ -96,3 +104,4 @@ Description: When read, this file returns the settings stored in the mouse. | |||
| 96 | When written, this file lets write settings back to the mouse. | 104 | When written, this file lets write settings back to the mouse. |
| 97 | The data has to be 3 bytes long. The mouse will reject invalid | 105 | The data has to be 3 bytes long. The mouse will reject invalid |
| 98 | data. | 106 | data. |
| 107 | Users: http://roccat.sourceforge.net | ||
diff --git a/Documentation/ABI/testing/sysfs-driver-samsung-laptop b/Documentation/ABI/testing/sysfs-driver-samsung-laptop new file mode 100644 index 000000000000..0a810231aad4 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-samsung-laptop | |||
| @@ -0,0 +1,19 @@ | |||
| 1 | What: /sys/devices/platform/samsung/performance_level | ||
| 2 | Date: January 1, 2010 | ||
| 3 | KernelVersion: 2.6.33 | ||
| 4 | Contact: Greg Kroah-Hartman <gregkh@suse.de> | ||
| 5 | Description: Some Samsung laptops have different "performance levels" | ||
| 6 | that are can be modified by a function key, and by this | ||
| 7 | sysfs file. These values don't always make a whole lot | ||
| 8 | of sense, but some users like to modify them to keep | ||
| 9 | their fans quiet at all costs. Reading from this file | ||
| 10 | will show the current performance level. Writing to the | ||
| 11 | file can change this value. | ||
| 12 | Valid options: | ||
| 13 | "silent" | ||
| 14 | "normal" | ||
| 15 | "overclock" | ||
| 16 | Note that not all laptops support all of these options. | ||
| 17 | Specifically, not all support the "overclock" option, | ||
| 18 | and it's still unknown if this value even changes | ||
| 19 | anything, other than making the user feel a bit better. | ||
diff --git a/Documentation/ABI/testing/sysfs-firmware-dmi b/Documentation/ABI/testing/sysfs-firmware-dmi new file mode 100644 index 000000000000..ba9da9503c23 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-firmware-dmi | |||
| @@ -0,0 +1,110 @@ | |||
| 1 | What: /sys/firmware/dmi/ | ||
| 2 | Date: February 2011 | ||
| 3 | Contact: Mike Waychison <mikew@google.com> | ||
| 4 | Description: | ||
| 5 | Many machines' firmware (x86 and ia64) export DMI / | ||
| 6 | SMBIOS tables to the operating system. Getting at this | ||
| 7 | information is often valuable to userland, especially in | ||
| 8 | cases where there are OEM extensions used. | ||
| 9 | |||
| 10 | The kernel itself does not rely on the majority of the | ||
| 11 | information in these tables being correct. It equally | ||
| 12 | cannot ensure that the data as exported to userland is | ||
| 13 | without error either. | ||
| 14 | |||
| 15 | DMI is structured as a large table of entries, where | ||
| 16 | each entry has a common header indicating the type and | ||
| 17 | length of the entry, as well as 'handle' that is | ||
| 18 | supposed to be unique amongst all entries. | ||
| 19 | |||
| 20 | Some entries are required by the specification, but many | ||
| 21 | others are optional. In general though, users should | ||
| 22 | never expect to find a specific entry type on their | ||
| 23 | system unless they know for certain what their firmware | ||
| 24 | is doing. Machine to machine will vary. | ||
| 25 | |||
| 26 | Multiple entries of the same type are allowed. In order | ||
| 27 | to handle these duplicate entry types, each entry is | ||
| 28 | assigned by the operating system an 'instance', which is | ||
| 29 | derived from an entry type's ordinal position. That is | ||
| 30 | to say, if there are 'N' multiple entries with the same type | ||
| 31 | 'T' in the DMI tables (adjacent or spread apart, it | ||
| 32 | doesn't matter), they will be represented in sysfs as | ||
| 33 | entries "T-0" through "T-(N-1)": | ||
| 34 | |||
| 35 | Example entry directories: | ||
| 36 | |||
| 37 | /sys/firmware/dmi/entries/17-0 | ||
| 38 | /sys/firmware/dmi/entries/17-1 | ||
| 39 | /sys/firmware/dmi/entries/17-2 | ||
| 40 | /sys/firmware/dmi/entries/17-3 | ||
| 41 | ... | ||
| 42 | |||
| 43 | Instance numbers are used in lieu of the firmware | ||
| 44 | assigned entry handles as the kernel itself makes no | ||
| 45 | guarantees that handles as exported are unique, and | ||
| 46 | there are likely firmware images that get this wrong in | ||
| 47 | the wild. | ||
| 48 | |||
| 49 | Each DMI entry in sysfs has the common header values | ||
| 50 | exported as attributes: | ||
| 51 | |||
| 52 | handle : The 16bit 'handle' that is assigned to this | ||
| 53 | entry by the firmware. This handle may be | ||
| 54 | referred to by other entries. | ||
| 55 | length : The length of the entry, as presented in the | ||
| 56 | entry itself. Note that this is _not the | ||
| 57 | total count of bytes associated with the | ||
| 58 | entry_. This value represents the length of | ||
| 59 | the "formatted" portion of the entry. This | ||
| 60 | "formatted" region is sometimes followed by | ||
| 61 | the "unformatted" region composed of nul | ||
| 62 | terminated strings, with termination signalled | ||
| 63 | by a two nul characters in series. | ||
| 64 | raw : The raw bytes of the entry. This includes the | ||
| 65 | "formatted" portion of the entry, the | ||
| 66 | "unformatted" strings portion of the entry, | ||
| 67 | and the two terminating nul characters. | ||
| 68 | type : The type of the entry. This value is the same | ||
| 69 | as found in the directory name. It indicates | ||
| 70 | how the rest of the entry should be | ||
| 71 | interpreted. | ||
| 72 | instance: The instance ordinal of the entry for the | ||
| 73 | given type. This value is the same as found | ||
| 74 | in the parent directory name. | ||
| 75 | position: The position of the entry within the entirety | ||
| 76 | of the entirety. | ||
| 77 | |||
| 78 | === Entry Specialization === | ||
| 79 | |||
| 80 | Some entry types may have other information available in | ||
| 81 | sysfs. | ||
| 82 | |||
| 83 | --- Type 15 - System Event Log --- | ||
| 84 | |||
| 85 | This entry allows the firmware to export a log of | ||
| 86 | events the system has taken. This information is | ||
| 87 | typically backed by nvram, but the implementation | ||
| 88 | details are abstracted by this table. This entries data | ||
| 89 | is exported in the directory: | ||
| 90 | |||
| 91 | /sys/firmware/dmi/entries/15-0/system_event_log | ||
| 92 | |||
| 93 | and has the following attributes (documented in the | ||
| 94 | SMBIOS / DMI specification under "System Event Log (Type 15)": | ||
| 95 | |||
| 96 | area_length | ||
| 97 | header_start_offset | ||
| 98 | data_start_offset | ||
| 99 | access_method | ||
| 100 | status | ||
| 101 | change_token | ||
| 102 | access_method_address | ||
| 103 | header_format | ||
| 104 | per_log_type_descriptor_length | ||
| 105 | type_descriptors_supported_count | ||
| 106 | |||
| 107 | As well, the kernel exports the binary attribute: | ||
| 108 | |||
| 109 | raw_event_log : The raw binary bits of the event log | ||
| 110 | as described by the DMI entry. | ||
diff --git a/Documentation/ABI/testing/sysfs-fs-ext4 b/Documentation/ABI/testing/sysfs-fs-ext4 index 5fb709997d96..f22ac0872ae8 100644 --- a/Documentation/ABI/testing/sysfs-fs-ext4 +++ b/Documentation/ABI/testing/sysfs-fs-ext4 | |||
| @@ -48,7 +48,7 @@ Description: | |||
| 48 | will have its blocks allocated out of its own unique | 48 | will have its blocks allocated out of its own unique |
| 49 | preallocation pool. | 49 | preallocation pool. |
| 50 | 50 | ||
| 51 | What: /sys/fs/ext4/<disk>/inode_readahead | 51 | What: /sys/fs/ext4/<disk>/inode_readahead_blks |
| 52 | Date: March 2008 | 52 | Date: March 2008 |
| 53 | Contact: "Theodore Ts'o" <tytso@mit.edu> | 53 | Contact: "Theodore Ts'o" <tytso@mit.edu> |
| 54 | Description: | 54 | Description: |
| @@ -85,7 +85,14 @@ Date: June 2008 | |||
| 85 | Contact: "Theodore Ts'o" <tytso@mit.edu> | 85 | Contact: "Theodore Ts'o" <tytso@mit.edu> |
| 86 | Description: | 86 | Description: |
| 87 | Tuning parameter which (if non-zero) controls the goal | 87 | Tuning parameter which (if non-zero) controls the goal |
| 88 | inode used by the inode allocator in p0reference to | 88 | inode used by the inode allocator in preference to |
| 89 | all other allocation hueristics. This is intended for | 89 | all other allocation heuristics. This is intended for |
| 90 | debugging use only, and should be 0 on production | 90 | debugging use only, and should be 0 on production |
| 91 | systems. | 91 | systems. |
| 92 | |||
| 93 | What: /sys/fs/ext4/<disk>/max_writeback_mb_bump | ||
| 94 | Date: September 2009 | ||
| 95 | Contact: "Theodore Ts'o" <tytso@mit.edu> | ||
| 96 | Description: | ||
| 97 | The maximum number of megabytes the writeback code will | ||
| 98 | try to write out before move on to another inode. | ||
diff --git a/Documentation/ABI/testing/sysfs-platform-asus-laptop b/Documentation/ABI/testing/sysfs-platform-asus-laptop index 41ff8ae4dee0..cd9d667c3da2 100644 --- a/Documentation/ABI/testing/sysfs-platform-asus-laptop +++ b/Documentation/ABI/testing/sysfs-platform-asus-laptop | |||
| @@ -27,7 +27,7 @@ KernelVersion: 2.6.20 | |||
| 27 | Contact: "Corentin Chary" <corentincj@iksaif.net> | 27 | Contact: "Corentin Chary" <corentincj@iksaif.net> |
| 28 | Description: | 28 | Description: |
| 29 | Some models like the W1N have a LED display that can be | 29 | Some models like the W1N have a LED display that can be |
| 30 | used to display several informations. | 30 | used to display several items of information. |
| 31 | To control the LED display, use the following : | 31 | To control the LED display, use the following : |
| 32 | echo 0x0T000DDD > /sys/devices/platform/asus_laptop/ | 32 | echo 0x0T000DDD > /sys/devices/platform/asus_laptop/ |
| 33 | where T control the 3 letters display, and DDD the 3 digits display. | 33 | where T control the 3 letters display, and DDD the 3 digits display. |
diff --git a/Documentation/ABI/testing/sysfs-platform-asus-wmi b/Documentation/ABI/testing/sysfs-platform-asus-wmi new file mode 100644 index 000000000000..2e7df91620de --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform-asus-wmi | |||
| @@ -0,0 +1,31 @@ | |||
| 1 | What: /sys/devices/platform/<platform>/cpufv | ||
| 2 | Date: Oct 2010 | ||
| 3 | KernelVersion: 2.6.37 | ||
| 4 | Contact: "Corentin Chary" <corentincj@iksaif.net> | ||
| 5 | Description: | ||
| 6 | Change CPU clock configuration (write-only). | ||
| 7 | There are three available clock configuration: | ||
| 8 | * 0 -> Super Performance Mode | ||
| 9 | * 1 -> High Performance Mode | ||
| 10 | * 2 -> Power Saving Mode | ||
| 11 | |||
| 12 | What: /sys/devices/platform/<platform>/camera | ||
| 13 | Date: Jan 2010 | ||
| 14 | KernelVersion: 2.6.39 | ||
| 15 | Contact: "Corentin Chary" <corentincj@iksaif.net> | ||
| 16 | Description: | ||
| 17 | Control the camera. 1 means on, 0 means off. | ||
| 18 | |||
| 19 | What: /sys/devices/platform/<platform>/cardr | ||
| 20 | Date: Jan 2010 | ||
| 21 | KernelVersion: 2.6.39 | ||
| 22 | Contact: "Corentin Chary" <corentincj@iksaif.net> | ||
| 23 | Description: | ||
| 24 | Control the card reader. 1 means on, 0 means off. | ||
| 25 | |||
| 26 | What: /sys/devices/platform/<platform>/touchpad | ||
| 27 | Date: Jan 2010 | ||
| 28 | KernelVersion: 2.6.39 | ||
| 29 | Contact: "Corentin Chary" <corentincj@iksaif.net> | ||
| 30 | Description: | ||
| 31 | Control the card touchpad. 1 means on, 0 means off. | ||
diff --git a/Documentation/ABI/testing/sysfs-platform-eeepc-wmi b/Documentation/ABI/testing/sysfs-platform-eeepc-wmi deleted file mode 100644 index e4b5fef5fadd..000000000000 --- a/Documentation/ABI/testing/sysfs-platform-eeepc-wmi +++ /dev/null | |||
| @@ -1,10 +0,0 @@ | |||
| 1 | What: /sys/devices/platform/eeepc-wmi/cpufv | ||
| 2 | Date: Oct 2010 | ||
| 3 | KernelVersion: 2.6.37 | ||
| 4 | Contact: "Corentin Chary" <corentincj@iksaif.net> | ||
| 5 | Description: | ||
| 6 | Change CPU clock configuration (write-only). | ||
| 7 | There are three available clock configuration: | ||
| 8 | * 0 -> Super Performance Mode | ||
| 9 | * 1 -> High Performance Mode | ||
| 10 | * 2 -> Power Saving Mode | ||
diff --git a/Documentation/ABI/testing/sysfs-platform-kim b/Documentation/ABI/testing/sysfs-platform-kim new file mode 100644 index 000000000000..c1653271872a --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform-kim | |||
| @@ -0,0 +1,48 @@ | |||
| 1 | What: /sys/devices/platform/kim/dev_name | ||
| 2 | Date: January 2010 | ||
| 3 | KernelVersion: 2.6.38 | ||
| 4 | Contact: "Pavan Savoy" <pavan_savoy@ti.com> | ||
| 5 | Description: | ||
| 6 | Name of the UART device at which the WL128x chip | ||
| 7 | is connected. example: "/dev/ttyS0". | ||
| 8 | The device name flows down to architecture specific board | ||
| 9 | initialization file from the SFI/ATAGS bootloader | ||
| 10 | firmware. The name exposed is read from the user-space | ||
| 11 | dameon and opens the device when install is requested. | ||
| 12 | |||
| 13 | What: /sys/devices/platform/kim/baud_rate | ||
| 14 | Date: January 2010 | ||
| 15 | KernelVersion: 2.6.38 | ||
| 16 | Contact: "Pavan Savoy" <pavan_savoy@ti.com> | ||
| 17 | Description: | ||
| 18 | The maximum reliable baud-rate the host can support. | ||
| 19 | Different platforms tend to have different high-speed | ||
| 20 | UART configurations, so the baud-rate needs to be set | ||
| 21 | locally and also sent across to the WL128x via a HCI-VS | ||
| 22 | command. The entry is read and made use by the user-space | ||
| 23 | daemon when the ldisc install is requested. | ||
| 24 | |||
| 25 | What: /sys/devices/platform/kim/flow_cntrl | ||
| 26 | Date: January 2010 | ||
| 27 | KernelVersion: 2.6.38 | ||
| 28 | Contact: "Pavan Savoy" <pavan_savoy@ti.com> | ||
| 29 | Description: | ||
| 30 | The WL128x makes use of flow control mechanism, and this | ||
| 31 | entry most often should be 1, the host's UART is required | ||
| 32 | to have the capability of flow-control, or else this | ||
| 33 | entry can be made use of for exceptions. | ||
| 34 | |||
| 35 | What: /sys/devices/platform/kim/install | ||
| 36 | Date: January 2010 | ||
| 37 | KernelVersion: 2.6.38 | ||
| 38 | Contact: "Pavan Savoy" <pavan_savoy@ti.com> | ||
| 39 | Description: | ||
| 40 | When one of the protocols Bluetooth, FM or GPS wants to make | ||
| 41 | use of the shared UART transport, it registers to the shared | ||
| 42 | transport driver, which will signal the user-space for opening, | ||
| 43 | configuring baud and install line discipline via this sysfs | ||
| 44 | entry. This entry would be polled upon by the user-space | ||
| 45 | daemon managing the UART, and is notified about the change | ||
| 46 | by the sysfs_notify. The value would be '1' when UART needs | ||
| 47 | to be opened/ldisc installed, and would be '0' when UART | ||
| 48 | is no more required and needs to be closed. | ||
diff --git a/Documentation/Changes b/Documentation/Changes index 4fb88f15f2ef..5f4828a034e3 100644 --- a/Documentation/Changes +++ b/Documentation/Changes | |||
| @@ -35,7 +35,7 @@ o util-linux 2.10o # fdformat --version | |||
| 35 | o module-init-tools 0.9.10 # depmod -V | 35 | o module-init-tools 0.9.10 # depmod -V |
| 36 | o e2fsprogs 1.41.4 # e2fsck -V | 36 | o e2fsprogs 1.41.4 # e2fsck -V |
| 37 | o jfsutils 1.1.3 # fsck.jfs -V | 37 | o jfsutils 1.1.3 # fsck.jfs -V |
| 38 | o reiserfsprogs 3.6.3 # reiserfsck -V 2>&1|grep reiserfsprogs | 38 | o reiserfsprogs 3.6.3 # reiserfsck -V |
| 39 | o xfsprogs 2.6.0 # xfs_db -V | 39 | o xfsprogs 2.6.0 # xfs_db -V |
| 40 | o squashfs-tools 4.0 # mksquashfs -version | 40 | o squashfs-tools 4.0 # mksquashfs -version |
| 41 | o btrfs-progs 0.18 # btrfsck | 41 | o btrfs-progs 0.18 # btrfsck |
| @@ -46,9 +46,9 @@ o isdn4k-utils 3.1pre1 # isdnctrl 2>&1|grep version | |||
| 46 | o nfs-utils 1.0.5 # showmount --version | 46 | o nfs-utils 1.0.5 # showmount --version |
| 47 | o procps 3.2.0 # ps --version | 47 | o procps 3.2.0 # ps --version |
| 48 | o oprofile 0.9 # oprofiled --version | 48 | o oprofile 0.9 # oprofiled --version |
| 49 | o udev 081 # udevinfo -V | 49 | o udev 081 # udevd --version |
| 50 | o grub 0.93 # grub --version | 50 | o grub 0.93 # grub --version || grub-install --version |
| 51 | o mcelog 0.6 | 51 | o mcelog 0.6 # mcelog --version |
| 52 | o iptables 1.4.2 # iptables -V | 52 | o iptables 1.4.2 # iptables -V |
| 53 | 53 | ||
| 54 | 54 | ||
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index 8bb37237ebd2..58b0bf917834 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle | |||
| @@ -168,6 +168,13 @@ Do not unnecessarily use braces where a single statement will do. | |||
| 168 | if (condition) | 168 | if (condition) |
| 169 | action(); | 169 | action(); |
| 170 | 170 | ||
| 171 | and | ||
| 172 | |||
| 173 | if (condition) | ||
| 174 | do_this(); | ||
| 175 | else | ||
| 176 | do_that(); | ||
| 177 | |||
| 171 | This does not apply if one branch of a conditional statement is a single | 178 | This does not apply if one branch of a conditional statement is a single |
| 172 | statement. Use braces in both branches. | 179 | statement. Use braces in both branches. |
| 173 | 180 | ||
| @@ -659,7 +666,7 @@ There are a number of driver model diagnostic macros in <linux/device.h> | |||
| 659 | which you should use to make sure messages are matched to the right device | 666 | which you should use to make sure messages are matched to the right device |
| 660 | and driver, and are tagged with the right level: dev_err(), dev_warn(), | 667 | and driver, and are tagged with the right level: dev_err(), dev_warn(), |
| 661 | dev_info(), and so forth. For messages that aren't associated with a | 668 | dev_info(), and so forth. For messages that aren't associated with a |
| 662 | particular device, <linux/kernel.h> defines pr_debug() and pr_info(). | 669 | particular device, <linux/printk.h> defines pr_debug() and pr_info(). |
| 663 | 670 | ||
| 664 | Coming up with good debugging messages can be quite a challenge; and once | 671 | Coming up with good debugging messages can be quite a challenge; and once |
| 665 | you have them, they can be a huge help for remote troubleshooting. Such | 672 | 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/ | |||
| 819 | Kernel CodingStyle, by greg@kroah.com at OLS 2002: | 826 | Kernel CodingStyle, by greg@kroah.com at OLS 2002: |
| 820 | http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/ | 827 | http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/ |
| 821 | 828 | ||
| 822 | -- | ||
| 823 | Last updated on 2007-July-13. | ||
| 824 | |||
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index 8b6e00a71034..8436b018c289 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile | |||
| @@ -53,7 +53,9 @@ MAN := $(patsubst %.xml, %.9, $(BOOKS)) | |||
| 53 | mandocs: $(MAN) | 53 | mandocs: $(MAN) |
| 54 | 54 | ||
| 55 | build_images = mkdir -p $(objtree)/Documentation/DocBook/media/ && \ | 55 | build_images = mkdir -p $(objtree)/Documentation/DocBook/media/ && \ |
| 56 | cp $(srctree)/Documentation/DocBook/dvb/*.png $(srctree)/Documentation/DocBook/v4l/*.gif $(objtree)/Documentation/DocBook/media/ | 56 | cp $(srctree)/Documentation/DocBook/dvb/*.png \ |
| 57 | $(srctree)/Documentation/DocBook/v4l/*.gif \ | ||
| 58 | $(objtree)/Documentation/DocBook/media/ | ||
| 57 | 59 | ||
| 58 | xmldoclinks: | 60 | xmldoclinks: |
| 59 | ifneq ($(objtree),$(srctree)) | 61 | ifneq ($(objtree),$(srctree)) |
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 2861055afd7a..c27915893974 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl | |||
| @@ -73,8 +73,8 @@ | |||
| 73 | services. | 73 | services. |
| 74 | </para> | 74 | </para> |
| 75 | <para> | 75 | <para> |
| 76 | The core of every DRM driver is struct drm_device. Drivers | 76 | The core of every DRM driver is struct drm_driver. Drivers |
| 77 | will typically statically initialize a drm_device structure, | 77 | will typically statically initialize a drm_driver structure, |
| 78 | then pass it to drm_init() at load time. | 78 | then pass it to drm_init() at load time. |
| 79 | </para> | 79 | </para> |
| 80 | 80 | ||
| @@ -84,7 +84,7 @@ | |||
| 84 | <title>Driver initialization</title> | 84 | <title>Driver initialization</title> |
| 85 | <para> | 85 | <para> |
| 86 | Before calling the DRM initialization routines, the driver must | 86 | Before calling the DRM initialization routines, the driver must |
| 87 | first create and fill out a struct drm_device structure. | 87 | first create and fill out a struct drm_driver structure. |
| 88 | </para> | 88 | </para> |
| 89 | <programlisting> | 89 | <programlisting> |
| 90 | static struct drm_driver driver = { | 90 | static struct drm_driver driver = { |
diff --git a/Documentation/DocBook/dvb/dvbproperty.xml b/Documentation/DocBook/dvb/dvbproperty.xml index 5f57c7ccd4ba..97f397e2fb3a 100644 --- a/Documentation/DocBook/dvb/dvbproperty.xml +++ b/Documentation/DocBook/dvb/dvbproperty.xml | |||
| @@ -40,7 +40,7 @@ | |||
| 40 | 40 | ||
| 41 | <para>Central frequency of the channel.</para> | 41 | <para>Central frequency of the channel.</para> |
| 42 | 42 | ||
| 43 | <para>For ISDB-T the channels are usally transmitted with an offset of 143kHz. E.g. a | 43 | <para>For ISDB-T the channels are usually transmitted with an offset of 143kHz. E.g. a |
| 44 | valid frequncy could be 474143 kHz. The stepping is bound to the bandwidth of | 44 | valid frequncy could be 474143 kHz. The stepping is bound to the bandwidth of |
| 45 | the channel which is 6MHz.</para> | 45 | the channel which is 6MHz.</para> |
| 46 | 46 | ||
diff --git a/Documentation/DocBook/dvb/frontend.xml b/Documentation/DocBook/dvb/frontend.xml index 78d756de5906..60c6976fb311 100644 --- a/Documentation/DocBook/dvb/frontend.xml +++ b/Documentation/DocBook/dvb/frontend.xml | |||
| @@ -139,7 +139,7 @@ consistently to the DiSEqC commands as described in the DiSEqC spec.</para> | |||
| 139 | <section id="frontend_sec_tone"> | 139 | <section id="frontend_sec_tone"> |
| 140 | <title>SEC continuous tone</title> | 140 | <title>SEC continuous tone</title> |
| 141 | 141 | ||
| 142 | <para>The continous 22KHz tone is usually used with non-DiSEqC capable LNBs to switch the | 142 | <para>The continuous 22KHz tone is usually used with non-DiSEqC capable LNBs to switch the |
| 143 | high/low band of a dual-band LNB. When using DiSEqC epuipment this voltage has to | 143 | high/low band of a dual-band LNB. When using DiSEqC epuipment this voltage has to |
| 144 | be switched consistently to the DiSEqC commands as described in the DiSEqC | 144 | be switched consistently to the DiSEqC commands as described in the DiSEqC |
| 145 | spec.</para> | 145 | spec.</para> |
diff --git a/Documentation/DocBook/filesystems.tmpl b/Documentation/DocBook/filesystems.tmpl index 5e87ad58c0b5..f51f28531b8d 100644 --- a/Documentation/DocBook/filesystems.tmpl +++ b/Documentation/DocBook/filesystems.tmpl | |||
| @@ -82,6 +82,11 @@ | |||
| 82 | </sect1> | 82 | </sect1> |
| 83 | </chapter> | 83 | </chapter> |
| 84 | 84 | ||
| 85 | <chapter id="fs_events"> | ||
| 86 | <title>Events based on file descriptors</title> | ||
| 87 | !Efs/eventfd.c | ||
| 88 | </chapter> | ||
| 89 | |||
| 85 | <chapter id="sysfs"> | 90 | <chapter id="sysfs"> |
| 86 | <title>The Filesystem for Exporting Kernel Objects</title> | 91 | <title>The Filesystem for Exporting Kernel Objects</title> |
| 87 | !Efs/sysfs/file.c | 92 | !Efs/sysfs/file.c |
diff --git a/Documentation/DocBook/kernel-locking.tmpl b/Documentation/DocBook/kernel-locking.tmpl index f66f4df18690..67e7ab41c0a6 100644 --- a/Documentation/DocBook/kernel-locking.tmpl +++ b/Documentation/DocBook/kernel-locking.tmpl | |||
| @@ -1763,7 +1763,7 @@ as it would be on UP. | |||
| 1763 | There is a furthur optimization possible here: remember our original | 1763 | There is a furthur optimization possible here: remember our original |
| 1764 | cache code, where there were no reference counts and the caller simply | 1764 | cache code, where there were no reference counts and the caller simply |
| 1765 | held the lock whenever using the object? This is still possible: if | 1765 | held the lock whenever using the object? This is still possible: if |
| 1766 | you hold the lock, noone can delete the object, so you don't need to | 1766 | you hold the lock, no one can delete the object, so you don't need to |
| 1767 | get and put the reference count. | 1767 | get and put the reference count. |
| 1768 | </para> | 1768 | </para> |
| 1769 | 1769 | ||
diff --git a/Documentation/DocBook/libata.tmpl b/Documentation/DocBook/libata.tmpl index 8c5411cfeaf0..cdd1bb9aac0d 100644 --- a/Documentation/DocBook/libata.tmpl +++ b/Documentation/DocBook/libata.tmpl | |||
| @@ -1032,7 +1032,7 @@ and other resources, etc. | |||
| 1032 | <listitem> | 1032 | <listitem> |
| 1033 | <para> | 1033 | <para> |
| 1034 | This is indicated by ICRC bit in the ERROR register and | 1034 | This is indicated by ICRC bit in the ERROR register and |
| 1035 | means that corruption occurred during data transfer. Upto | 1035 | means that corruption occurred during data transfer. Up to |
| 1036 | ATA/ATAPI-7, the standard specifies that this bit is only | 1036 | ATA/ATAPI-7, the standard specifies that this bit is only |
| 1037 | applicable to UDMA transfers but ATA/ATAPI-8 draft revision | 1037 | applicable to UDMA transfers but ATA/ATAPI-8 draft revision |
| 1038 | 1f says that the bit may be applicable to multiword DMA and | 1038 | 1f says that the bit may be applicable to multiword DMA and |
| @@ -1045,10 +1045,10 @@ and other resources, etc. | |||
| 1045 | <term>ABRT error during data transfer or on completion</term> | 1045 | <term>ABRT error during data transfer or on completion</term> |
| 1046 | <listitem> | 1046 | <listitem> |
| 1047 | <para> | 1047 | <para> |
| 1048 | Upto ATA/ATAPI-7, the standard specifies that ABRT could be | 1048 | Up to ATA/ATAPI-7, the standard specifies that ABRT could be |
| 1049 | set on ICRC errors and on cases where a device is not able | 1049 | set on ICRC errors and on cases where a device is not able |
| 1050 | to complete a command. Combined with the fact that MWDMA | 1050 | to complete a command. Combined with the fact that MWDMA |
| 1051 | and PIO transfer errors aren't allowed to use ICRC bit upto | 1051 | and PIO transfer errors aren't allowed to use ICRC bit up to |
| 1052 | ATA/ATAPI-7, it seems to imply that ABRT bit alone could | 1052 | ATA/ATAPI-7, it seems to imply that ABRT bit alone could |
| 1053 | indicate tranfer errors. | 1053 | indicate tranfer errors. |
| 1054 | </para> | 1054 | </para> |
| @@ -1122,7 +1122,7 @@ and other resources, etc. | |||
| 1122 | <para> | 1122 | <para> |
| 1123 | Depending on commands, not all STATUS/ERROR bits are | 1123 | Depending on commands, not all STATUS/ERROR bits are |
| 1124 | applicable. These non-applicable bits are marked with | 1124 | applicable. These non-applicable bits are marked with |
| 1125 | "na" in the output descriptions but upto ATA/ATAPI-7 | 1125 | "na" in the output descriptions but up to ATA/ATAPI-7 |
| 1126 | no definition of "na" can be found. However, | 1126 | no definition of "na" can be found. However, |
| 1127 | ATA/ATAPI-8 draft revision 1f describes "N/A" as | 1127 | ATA/ATAPI-8 draft revision 1f describes "N/A" as |
| 1128 | follows. | 1128 | follows. |
| @@ -1507,7 +1507,7 @@ and other resources, etc. | |||
| 1507 | 1507 | ||
| 1508 | <listitem> | 1508 | <listitem> |
| 1509 | <para> | 1509 | <para> |
| 1510 | CHS set up with INITIALIZE DEVICE PARAMETERS (seldomly used) | 1510 | CHS set up with INITIALIZE DEVICE PARAMETERS (seldom used) |
| 1511 | </para> | 1511 | </para> |
| 1512 | </listitem> | 1512 | </listitem> |
| 1513 | 1513 | ||
diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl index be34dcbe0d90..5d259c632cdf 100644 --- a/Documentation/DocBook/media-entities.tmpl +++ b/Documentation/DocBook/media-entities.tmpl | |||
| @@ -11,6 +11,10 @@ | |||
| 11 | <!ENTITY func-select "<link linkend='func-select'><function>select()</function></link>"> | 11 | <!ENTITY func-select "<link linkend='func-select'><function>select()</function></link>"> |
| 12 | <!ENTITY func-write "<link linkend='func-write'><function>write()</function></link>"> | 12 | <!ENTITY func-write "<link linkend='func-write'><function>write()</function></link>"> |
| 13 | 13 | ||
| 14 | <!ENTITY media-func-close "<link linkend='media-func-close'><function>close()</function></link>"> | ||
| 15 | <!ENTITY media-func-ioctl "<link linkend='media-func-ioctl'><function>ioctl()</function></link>"> | ||
| 16 | <!ENTITY media-func-open "<link linkend='media-func-open'><function>open()</function></link>"> | ||
| 17 | |||
| 14 | <!-- Ioctls --> | 18 | <!-- Ioctls --> |
| 15 | <!ENTITY VIDIOC-CROPCAP "<link linkend='vidioc-cropcap'><constant>VIDIOC_CROPCAP</constant></link>"> | 19 | <!ENTITY VIDIOC-CROPCAP "<link linkend='vidioc-cropcap'><constant>VIDIOC_CROPCAP</constant></link>"> |
| 16 | <!ENTITY VIDIOC-DBG-G-CHIP-IDENT "<link linkend='vidioc-dbg-g-chip-ident'><constant>VIDIOC_DBG_G_CHIP_IDENT</constant></link>"> | 20 | <!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 @@ | |||
| 82 | <!ENTITY VIDIOC-S-PRIORITY "<link linkend='vidioc-g-priority'><constant>VIDIOC_S_PRIORITY</constant></link>"> | 86 | <!ENTITY VIDIOC-S-PRIORITY "<link linkend='vidioc-g-priority'><constant>VIDIOC_S_PRIORITY</constant></link>"> |
| 83 | <!ENTITY VIDIOC-S-STD "<link linkend='vidioc-g-std'><constant>VIDIOC_S_STD</constant></link>"> | 87 | <!ENTITY VIDIOC-S-STD "<link linkend='vidioc-g-std'><constant>VIDIOC_S_STD</constant></link>"> |
| 84 | <!ENTITY VIDIOC-S-TUNER "<link linkend='vidioc-g-tuner'><constant>VIDIOC_S_TUNER</constant></link>"> | 88 | <!ENTITY VIDIOC-S-TUNER "<link linkend='vidioc-g-tuner'><constant>VIDIOC_S_TUNER</constant></link>"> |
| 89 | <!ENTITY VIDIOC-SUBDEV-ENUM-FRAME-SIZE "<link linkend='vidioc-subdev-enum-frame-size'><constant>VIDIOC_SUBDEV_ENUM_FRAME_SIZE</constant></link>"> | ||
| 90 | <!ENTITY VIDIOC-SUBDEV-ENUM-MBUS-CODE "<link linkend='vidioc-subdev-enum-mbus-code'><constant>VIDIOC_SUBDEV_ENUM_MBUS_CODE</constant></link>"> | ||
| 91 | <!ENTITY VIDIOC-SUBDEV-G-CROP "<link linkend='vidioc-subdev-g-crop'><constant>VIDIOC_SUBDEV_G_CROP</constant></link>"> | ||
| 92 | <!ENTITY VIDIOC-SUBDEV-G-FMT "<link linkend='vidioc-subdev-g-fmt'><constant>VIDIOC_SUBDEV_G_FMT</constant></link>"> | ||
| 93 | <!ENTITY VIDIOC-SUBDEV-G-FRAME-INTERVAL "<link linkend='vidioc-subdev-g-frame-interval'><constant>VIDIOC_SUBDEV_G_FRAME_INTERVAL</constant></link>"> | ||
| 94 | <!ENTITY VIDIOC-SUBDEV-S-CROP "<link linkend='vidioc-subdev-g-crop'><constant>VIDIOC_SUBDEV_S_CROP</constant></link>"> | ||
| 95 | <!ENTITY VIDIOC-SUBDEV-S-FMT "<link linkend='vidioc-subdev-g-fmt'><constant>VIDIOC_SUBDEV_S_FMT</constant></link>"> | ||
| 96 | <!ENTITY VIDIOC-SUBDEV-S-FRAME-INTERVAL "<link linkend='vidioc-subdev-g-frame-interval'><constant>VIDIOC_SUBDEV_S_FRAME_INTERVAL</constant></link>"> | ||
| 85 | <!ENTITY VIDIOC-TRY-ENCODER-CMD "<link linkend='vidioc-encoder-cmd'><constant>VIDIOC_TRY_ENCODER_CMD</constant></link>"> | 97 | <!ENTITY VIDIOC-TRY-ENCODER-CMD "<link linkend='vidioc-encoder-cmd'><constant>VIDIOC_TRY_ENCODER_CMD</constant></link>"> |
| 86 | <!ENTITY VIDIOC-TRY-EXT-CTRLS "<link linkend='vidioc-g-ext-ctrls'><constant>VIDIOC_TRY_EXT_CTRLS</constant></link>"> | 98 | <!ENTITY VIDIOC-TRY-EXT-CTRLS "<link linkend='vidioc-g-ext-ctrls'><constant>VIDIOC_TRY_EXT_CTRLS</constant></link>"> |
| 87 | <!ENTITY VIDIOC-TRY-FMT "<link linkend='vidioc-g-fmt'><constant>VIDIOC_TRY_FMT</constant></link>"> | 99 | <!ENTITY VIDIOC-TRY-FMT "<link linkend='vidioc-g-fmt'><constant>VIDIOC_TRY_FMT</constant></link>"> |
| 88 | <!ENTITY VIDIOC-UNSUBSCRIBE-EVENT "<link linkend='vidioc-subscribe-event'><constant>VIDIOC_UNSUBSCRIBE_EVENT</constant></link>"> | 100 | <!ENTITY VIDIOC-UNSUBSCRIBE-EVENT "<link linkend='vidioc-subscribe-event'><constant>VIDIOC_UNSUBSCRIBE_EVENT</constant></link>"> |
| 89 | 101 | ||
| 102 | <!ENTITY MEDIA-IOC-DEVICE-INFO "<link linkend='media-ioc-device-info'><constant>MEDIA_IOC_DEVICE_INFO</constant></link>"> | ||
| 103 | <!ENTITY MEDIA-IOC-ENUM-ENTITIES "<link linkend='media-ioc-enum-entities'><constant>MEDIA_IOC_ENUM_ENTITIES</constant></link>"> | ||
| 104 | <!ENTITY MEDIA-IOC-ENUM-LINKS "<link linkend='media-ioc-enum-links'><constant>MEDIA_IOC_ENUM_LINKS</constant></link>"> | ||
| 105 | <!ENTITY MEDIA-IOC-SETUP-LINK "<link linkend='media-ioc-setup-link'><constant>MEDIA_IOC_SETUP_LINK</constant></link>"> | ||
| 106 | |||
| 90 | <!-- Types --> | 107 | <!-- Types --> |
| 91 | <!ENTITY v4l2-std-id "<link linkend='v4l2-std-id'>v4l2_std_id</link>"> | 108 | <!ENTITY v4l2-std-id "<link linkend='v4l2-std-id'>v4l2_std_id</link>"> |
| 92 | 109 | ||
| @@ -98,6 +115,7 @@ | |||
| 98 | <!ENTITY v4l2-field "enum <link linkend='v4l2-field'>v4l2_field</link>"> | 115 | <!ENTITY v4l2-field "enum <link linkend='v4l2-field'>v4l2_field</link>"> |
| 99 | <!ENTITY v4l2-frmivaltypes "enum <link linkend='v4l2-frmivaltypes'>v4l2_frmivaltypes</link>"> | 116 | <!ENTITY v4l2-frmivaltypes "enum <link linkend='v4l2-frmivaltypes'>v4l2_frmivaltypes</link>"> |
| 100 | <!ENTITY v4l2-frmsizetypes "enum <link linkend='v4l2-frmsizetypes'>v4l2_frmsizetypes</link>"> | 117 | <!ENTITY v4l2-frmsizetypes "enum <link linkend='v4l2-frmsizetypes'>v4l2_frmsizetypes</link>"> |
| 118 | <!ENTITY v4l2-mbus-pixelcode "enum <link linkend='v4l2-mbus-pixelcode'>v4l2_mbus_pixelcode</link>"> | ||
| 101 | <!ENTITY v4l2-memory "enum <link linkend='v4l2-memory'>v4l2_memory</link>"> | 119 | <!ENTITY v4l2-memory "enum <link linkend='v4l2-memory'>v4l2_memory</link>"> |
| 102 | <!ENTITY v4l2-mpeg-audio-ac3-bitrate "enum <link linkend='v4l2-mpeg-audio-ac3-bitrate'>v4l2_mpeg_audio_ac3_bitrate</link>"> | 120 | <!ENTITY v4l2-mpeg-audio-ac3-bitrate "enum <link linkend='v4l2-mpeg-audio-ac3-bitrate'>v4l2_mpeg_audio_ac3_bitrate</link>"> |
| 103 | <!ENTITY v4l2-mpeg-audio-crc "enum <link linkend='v4l2-mpeg-audio-crc'>v4l2_mpeg_audio_crc</link>"> | 121 | <!ENTITY v4l2-mpeg-audio-crc "enum <link linkend='v4l2-mpeg-audio-crc'>v4l2_mpeg_audio_crc</link>"> |
| @@ -121,6 +139,7 @@ | |||
| 121 | <!ENTITY v4l2-mpeg-video-encoding "enum <link linkend='v4l2-mpeg-video-encoding'>v4l2_mpeg_video_encoding</link>"> | 139 | <!ENTITY v4l2-mpeg-video-encoding "enum <link linkend='v4l2-mpeg-video-encoding'>v4l2_mpeg_video_encoding</link>"> |
| 122 | <!ENTITY v4l2-power-line-frequency "enum <link linkend='v4l2-power-line-frequency'>v4l2_power_line_frequency</link>"> | 140 | <!ENTITY v4l2-power-line-frequency "enum <link linkend='v4l2-power-line-frequency'>v4l2_power_line_frequency</link>"> |
| 123 | <!ENTITY v4l2-priority "enum <link linkend='v4l2-priority'>v4l2_priority</link>"> | 141 | <!ENTITY v4l2-priority "enum <link linkend='v4l2-priority'>v4l2_priority</link>"> |
| 142 | <!ENTITY v4l2-subdev-format-whence "enum <link linkend='v4l2-subdev-format-whence'>v4l2_subdev_format_whence</link>"> | ||
| 124 | <!ENTITY v4l2-tuner-type "enum <link linkend='v4l2-tuner-type'>v4l2_tuner_type</link>"> | 143 | <!ENTITY v4l2-tuner-type "enum <link linkend='v4l2-tuner-type'>v4l2_tuner_type</link>"> |
| 125 | <!ENTITY v4l2-preemphasis "enum <link linkend='v4l2-preemphasis'>v4l2_preemphasis</link>"> | 144 | <!ENTITY v4l2-preemphasis "enum <link linkend='v4l2-preemphasis'>v4l2_preemphasis</link>"> |
| 126 | 145 | ||
| @@ -129,6 +148,7 @@ | |||
| 129 | <!ENTITY v4l2-audioout "struct <link linkend='v4l2-audioout'>v4l2_audioout</link>"> | 148 | <!ENTITY v4l2-audioout "struct <link linkend='v4l2-audioout'>v4l2_audioout</link>"> |
| 130 | <!ENTITY v4l2-bt-timings "struct <link linkend='v4l2-bt-timings'>v4l2_bt_timings</link>"> | 149 | <!ENTITY v4l2-bt-timings "struct <link linkend='v4l2-bt-timings'>v4l2_bt_timings</link>"> |
| 131 | <!ENTITY v4l2-buffer "struct <link linkend='v4l2-buffer'>v4l2_buffer</link>"> | 150 | <!ENTITY v4l2-buffer "struct <link linkend='v4l2-buffer'>v4l2_buffer</link>"> |
| 151 | <!ENTITY v4l2-plane "struct <link linkend='v4l2-plane'>v4l2_plane</link>"> | ||
| 132 | <!ENTITY v4l2-capability "struct <link linkend='v4l2-capability'>v4l2_capability</link>"> | 152 | <!ENTITY v4l2-capability "struct <link linkend='v4l2-capability'>v4l2_capability</link>"> |
| 133 | <!ENTITY v4l2-captureparm "struct <link linkend='v4l2-captureparm'>v4l2_captureparm</link>"> | 153 | <!ENTITY v4l2-captureparm "struct <link linkend='v4l2-captureparm'>v4l2_captureparm</link>"> |
| 134 | <!ENTITY v4l2-clip "struct <link linkend='v4l2-clip'>v4l2_clip</link>"> | 154 | <!ENTITY v4l2-clip "struct <link linkend='v4l2-clip'>v4l2_clip</link>"> |
| @@ -162,11 +182,14 @@ | |||
| 162 | <!ENTITY v4l2-hw-freq-seek "struct <link linkend='v4l2-hw-freq-seek'>v4l2_hw_freq_seek</link>"> | 182 | <!ENTITY v4l2-hw-freq-seek "struct <link linkend='v4l2-hw-freq-seek'>v4l2_hw_freq_seek</link>"> |
| 163 | <!ENTITY v4l2-input "struct <link linkend='v4l2-input'>v4l2_input</link>"> | 183 | <!ENTITY v4l2-input "struct <link linkend='v4l2-input'>v4l2_input</link>"> |
| 164 | <!ENTITY v4l2-jpegcompression "struct <link linkend='v4l2-jpegcompression'>v4l2_jpegcompression</link>"> | 184 | <!ENTITY v4l2-jpegcompression "struct <link linkend='v4l2-jpegcompression'>v4l2_jpegcompression</link>"> |
| 185 | <!ENTITY v4l2-mbus-framefmt "struct <link linkend='v4l2-mbus-framefmt'>v4l2_mbus_framefmt</link>"> | ||
| 165 | <!ENTITY v4l2-modulator "struct <link linkend='v4l2-modulator'>v4l2_modulator</link>"> | 186 | <!ENTITY v4l2-modulator "struct <link linkend='v4l2-modulator'>v4l2_modulator</link>"> |
| 166 | <!ENTITY v4l2-mpeg-vbi-fmt-ivtv "struct <link linkend='v4l2-mpeg-vbi-fmt-ivtv'>v4l2_mpeg_vbi_fmt_ivtv</link>"> | 187 | <!ENTITY v4l2-mpeg-vbi-fmt-ivtv "struct <link linkend='v4l2-mpeg-vbi-fmt-ivtv'>v4l2_mpeg_vbi_fmt_ivtv</link>"> |
| 167 | <!ENTITY v4l2-output "struct <link linkend='v4l2-output'>v4l2_output</link>"> | 188 | <!ENTITY v4l2-output "struct <link linkend='v4l2-output'>v4l2_output</link>"> |
| 168 | <!ENTITY v4l2-outputparm "struct <link linkend='v4l2-outputparm'>v4l2_outputparm</link>"> | 189 | <!ENTITY v4l2-outputparm "struct <link linkend='v4l2-outputparm'>v4l2_outputparm</link>"> |
| 169 | <!ENTITY v4l2-pix-format "struct <link linkend='v4l2-pix-format'>v4l2_pix_format</link>"> | 190 | <!ENTITY v4l2-pix-format "struct <link linkend='v4l2-pix-format'>v4l2_pix_format</link>"> |
| 191 | <!ENTITY v4l2-pix-format-mplane "struct <link linkend='v4l2-pix-format-mplane'>v4l2_pix_format_mplane</link>"> | ||
| 192 | <!ENTITY v4l2-plane-pix-format "struct <link linkend='v4l2-plane-pix-format'>v4l2_plane_pix_format</link>"> | ||
| 170 | <!ENTITY v4l2-queryctrl "struct <link linkend='v4l2-queryctrl'>v4l2_queryctrl</link>"> | 193 | <!ENTITY v4l2-queryctrl "struct <link linkend='v4l2-queryctrl'>v4l2_queryctrl</link>"> |
| 171 | <!ENTITY v4l2-querymenu "struct <link linkend='v4l2-querymenu'>v4l2_querymenu</link>"> | 194 | <!ENTITY v4l2-querymenu "struct <link linkend='v4l2-querymenu'>v4l2_querymenu</link>"> |
| 172 | <!ENTITY v4l2-rect "struct <link linkend='v4l2-rect'>v4l2_rect</link>"> | 195 | <!ENTITY v4l2-rect "struct <link linkend='v4l2-rect'>v4l2_rect</link>"> |
| @@ -174,6 +197,12 @@ | |||
| 174 | <!ENTITY v4l2-sliced-vbi-cap "struct <link linkend='v4l2-sliced-vbi-cap'>v4l2_sliced_vbi_cap</link>"> | 197 | <!ENTITY v4l2-sliced-vbi-cap "struct <link linkend='v4l2-sliced-vbi-cap'>v4l2_sliced_vbi_cap</link>"> |
| 175 | <!ENTITY v4l2-sliced-vbi-data "struct <link linkend='v4l2-sliced-vbi-data'>v4l2_sliced_vbi_data</link>"> | 198 | <!ENTITY v4l2-sliced-vbi-data "struct <link linkend='v4l2-sliced-vbi-data'>v4l2_sliced_vbi_data</link>"> |
| 176 | <!ENTITY v4l2-sliced-vbi-format "struct <link linkend='v4l2-sliced-vbi-format'>v4l2_sliced_vbi_format</link>"> | 199 | <!ENTITY v4l2-sliced-vbi-format "struct <link linkend='v4l2-sliced-vbi-format'>v4l2_sliced_vbi_format</link>"> |
| 200 | <!ENTITY v4l2-subdev-frame-interval "struct <link linkend='v4l2-subdev-frame-interval'>v4l2_subdev_frame_interval</link>"> | ||
| 201 | <!ENTITY v4l2-subdev-frame-interval-enum "struct <link linkend='v4l2-subdev-frame-interval-enum'>v4l2_subdev_frame_interval_enum</link>"> | ||
| 202 | <!ENTITY v4l2-subdev-frame-size-enum "struct <link linkend='v4l2-subdev-frame-size-enum'>v4l2_subdev_frame_size_enum</link>"> | ||
| 203 | <!ENTITY v4l2-subdev-crop "struct <link linkend='v4l2-subdev-crop'>v4l2_subdev_crop</link>"> | ||
| 204 | <!ENTITY v4l2-subdev-format "struct <link linkend='v4l2-subdev-format'>v4l2_subdev_format</link>"> | ||
| 205 | <!ENTITY v4l2-subdev-mbus-code-enum "struct <link linkend='v4l2-subdev-mbus-code-enum'>v4l2_subdev_mbus_code_enum</link>"> | ||
| 177 | <!ENTITY v4l2-standard "struct <link linkend='v4l2-standard'>v4l2_standard</link>"> | 206 | <!ENTITY v4l2-standard "struct <link linkend='v4l2-standard'>v4l2_standard</link>"> |
| 178 | <!ENTITY v4l2-streamparm "struct <link linkend='v4l2-streamparm'>v4l2_streamparm</link>"> | 207 | <!ENTITY v4l2-streamparm "struct <link linkend='v4l2-streamparm'>v4l2_streamparm</link>"> |
| 179 | <!ENTITY v4l2-timecode "struct <link linkend='v4l2-timecode'>v4l2_timecode</link>"> | 208 | <!ENTITY v4l2-timecode "struct <link linkend='v4l2-timecode'>v4l2_timecode</link>"> |
| @@ -181,6 +210,12 @@ | |||
| 181 | <!ENTITY v4l2-vbi-format "struct <link linkend='v4l2-vbi-format'>v4l2_vbi_format</link>"> | 210 | <!ENTITY v4l2-vbi-format "struct <link linkend='v4l2-vbi-format'>v4l2_vbi_format</link>"> |
| 182 | <!ENTITY v4l2-window "struct <link linkend='v4l2-window'>v4l2_window</link>"> | 211 | <!ENTITY v4l2-window "struct <link linkend='v4l2-window'>v4l2_window</link>"> |
| 183 | 212 | ||
| 213 | <!ENTITY media-device-info "struct <link linkend='media-device-info'>media_device_info</link>"> | ||
| 214 | <!ENTITY media-entity-desc "struct <link linkend='media-entity-desc'>media_entity_desc</link>"> | ||
| 215 | <!ENTITY media-links-enum "struct <link linkend='media-links-enum'>media_links_enum</link>"> | ||
| 216 | <!ENTITY media-pad-desc "struct <link linkend='media-pad-desc'>media_pad_desc</link>"> | ||
| 217 | <!ENTITY media-link-desc "struct <link linkend='media-link-desc'>media_link_desc</link>"> | ||
| 218 | |||
| 184 | <!-- Error Codes --> | 219 | <!-- Error Codes --> |
| 185 | <!ENTITY EACCES "<errorcode>EACCES</errorcode> error code"> | 220 | <!ENTITY EACCES "<errorcode>EACCES</errorcode> error code"> |
| 186 | <!ENTITY EAGAIN "<errorcode>EAGAIN</errorcode> error code"> | 221 | <!ENTITY EAGAIN "<errorcode>EAGAIN</errorcode> error code"> |
| @@ -197,11 +232,13 @@ | |||
| 197 | <!ENTITY ENXIO "<errorcode>ENXIO</errorcode> error code"> | 232 | <!ENTITY ENXIO "<errorcode>ENXIO</errorcode> error code"> |
| 198 | <!ENTITY EMFILE "<errorcode>EMFILE</errorcode> error code"> | 233 | <!ENTITY EMFILE "<errorcode>EMFILE</errorcode> error code"> |
| 199 | <!ENTITY EPERM "<errorcode>EPERM</errorcode> error code"> | 234 | <!ENTITY EPERM "<errorcode>EPERM</errorcode> error code"> |
| 235 | <!ENTITY EPIPE "<errorcode>EPIPE</errorcode> error code"> | ||
| 200 | <!ENTITY ERANGE "<errorcode>ERANGE</errorcode> error code"> | 236 | <!ENTITY ERANGE "<errorcode>ERANGE</errorcode> error code"> |
| 201 | 237 | ||
| 202 | <!-- Subsections --> | 238 | <!-- Subsections --> |
| 203 | <!ENTITY sub-biblio SYSTEM "v4l/biblio.xml"> | 239 | <!ENTITY sub-biblio SYSTEM "v4l/biblio.xml"> |
| 204 | <!ENTITY sub-common SYSTEM "v4l/common.xml"> | 240 | <!ENTITY sub-common SYSTEM "v4l/common.xml"> |
| 241 | <!ENTITY sub-planar-apis SYSTEM "v4l/planar-apis.xml"> | ||
| 205 | <!ENTITY sub-compat SYSTEM "v4l/compat.xml"> | 242 | <!ENTITY sub-compat SYSTEM "v4l/compat.xml"> |
| 206 | <!ENTITY sub-controls SYSTEM "v4l/controls.xml"> | 243 | <!ENTITY sub-controls SYSTEM "v4l/controls.xml"> |
| 207 | <!ENTITY sub-dev-capture SYSTEM "v4l/dev-capture.xml"> | 244 | <!ENTITY sub-dev-capture SYSTEM "v4l/dev-capture.xml"> |
| @@ -215,6 +252,7 @@ | |||
| 215 | <!ENTITY sub-dev-raw-vbi SYSTEM "v4l/dev-raw-vbi.xml"> | 252 | <!ENTITY sub-dev-raw-vbi SYSTEM "v4l/dev-raw-vbi.xml"> |
| 216 | <!ENTITY sub-dev-rds SYSTEM "v4l/dev-rds.xml"> | 253 | <!ENTITY sub-dev-rds SYSTEM "v4l/dev-rds.xml"> |
| 217 | <!ENTITY sub-dev-sliced-vbi SYSTEM "v4l/dev-sliced-vbi.xml"> | 254 | <!ENTITY sub-dev-sliced-vbi SYSTEM "v4l/dev-sliced-vbi.xml"> |
| 255 | <!ENTITY sub-dev-subdev SYSTEM "v4l/dev-subdev.xml"> | ||
| 218 | <!ENTITY sub-dev-teletext SYSTEM "v4l/dev-teletext.xml"> | 256 | <!ENTITY sub-dev-teletext SYSTEM "v4l/dev-teletext.xml"> |
| 219 | <!ENTITY sub-driver SYSTEM "v4l/driver.xml"> | 257 | <!ENTITY sub-driver SYSTEM "v4l/driver.xml"> |
| 220 | <!ENTITY sub-libv4l SYSTEM "v4l/libv4l.xml"> | 258 | <!ENTITY sub-libv4l SYSTEM "v4l/libv4l.xml"> |
| @@ -233,6 +271,8 @@ | |||
| 233 | <!ENTITY sub-io SYSTEM "v4l/io.xml"> | 271 | <!ENTITY sub-io SYSTEM "v4l/io.xml"> |
| 234 | <!ENTITY sub-grey SYSTEM "v4l/pixfmt-grey.xml"> | 272 | <!ENTITY sub-grey SYSTEM "v4l/pixfmt-grey.xml"> |
| 235 | <!ENTITY sub-nv12 SYSTEM "v4l/pixfmt-nv12.xml"> | 273 | <!ENTITY sub-nv12 SYSTEM "v4l/pixfmt-nv12.xml"> |
| 274 | <!ENTITY sub-nv12m SYSTEM "v4l/pixfmt-nv12m.xml"> | ||
| 275 | <!ENTITY sub-nv12mt SYSTEM "v4l/pixfmt-nv12mt.xml"> | ||
| 236 | <!ENTITY sub-nv16 SYSTEM "v4l/pixfmt-nv16.xml"> | 276 | <!ENTITY sub-nv16 SYSTEM "v4l/pixfmt-nv16.xml"> |
| 237 | <!ENTITY sub-packed-rgb SYSTEM "v4l/pixfmt-packed-rgb.xml"> | 277 | <!ENTITY sub-packed-rgb SYSTEM "v4l/pixfmt-packed-rgb.xml"> |
| 238 | <!ENTITY sub-packed-yuv SYSTEM "v4l/pixfmt-packed-yuv.xml"> | 278 | <!ENTITY sub-packed-yuv SYSTEM "v4l/pixfmt-packed-yuv.xml"> |
| @@ -247,6 +287,7 @@ | |||
| 247 | <!ENTITY sub-yuv410 SYSTEM "v4l/pixfmt-yuv410.xml"> | 287 | <!ENTITY sub-yuv410 SYSTEM "v4l/pixfmt-yuv410.xml"> |
| 248 | <!ENTITY sub-yuv411p SYSTEM "v4l/pixfmt-yuv411p.xml"> | 288 | <!ENTITY sub-yuv411p SYSTEM "v4l/pixfmt-yuv411p.xml"> |
| 249 | <!ENTITY sub-yuv420 SYSTEM "v4l/pixfmt-yuv420.xml"> | 289 | <!ENTITY sub-yuv420 SYSTEM "v4l/pixfmt-yuv420.xml"> |
| 290 | <!ENTITY sub-yuv420m SYSTEM "v4l/pixfmt-yuv420m.xml"> | ||
| 250 | <!ENTITY sub-yuv422p SYSTEM "v4l/pixfmt-yuv422p.xml"> | 291 | <!ENTITY sub-yuv422p SYSTEM "v4l/pixfmt-yuv422p.xml"> |
| 251 | <!ENTITY sub-yuyv SYSTEM "v4l/pixfmt-yuyv.xml"> | 292 | <!ENTITY sub-yuyv SYSTEM "v4l/pixfmt-yuyv.xml"> |
| 252 | <!ENTITY sub-yvyu SYSTEM "v4l/pixfmt-yvyu.xml"> | 293 | <!ENTITY sub-yvyu SYSTEM "v4l/pixfmt-yvyu.xml"> |
| @@ -298,6 +339,13 @@ | |||
| 298 | <!ENTITY sub-reqbufs SYSTEM "v4l/vidioc-reqbufs.xml"> | 339 | <!ENTITY sub-reqbufs SYSTEM "v4l/vidioc-reqbufs.xml"> |
| 299 | <!ENTITY sub-s-hw-freq-seek SYSTEM "v4l/vidioc-s-hw-freq-seek.xml"> | 340 | <!ENTITY sub-s-hw-freq-seek SYSTEM "v4l/vidioc-s-hw-freq-seek.xml"> |
| 300 | <!ENTITY sub-streamon SYSTEM "v4l/vidioc-streamon.xml"> | 341 | <!ENTITY sub-streamon SYSTEM "v4l/vidioc-streamon.xml"> |
| 342 | <!ENTITY sub-subdev-enum-frame-interval SYSTEM "v4l/vidioc-subdev-enum-frame-interval.xml"> | ||
| 343 | <!ENTITY sub-subdev-enum-frame-size SYSTEM "v4l/vidioc-subdev-enum-frame-size.xml"> | ||
| 344 | <!ENTITY sub-subdev-enum-mbus-code SYSTEM "v4l/vidioc-subdev-enum-mbus-code.xml"> | ||
| 345 | <!ENTITY sub-subdev-formats SYSTEM "v4l/subdev-formats.xml"> | ||
| 346 | <!ENTITY sub-subdev-g-crop SYSTEM "v4l/vidioc-subdev-g-crop.xml"> | ||
| 347 | <!ENTITY sub-subdev-g-fmt SYSTEM "v4l/vidioc-subdev-g-fmt.xml"> | ||
| 348 | <!ENTITY sub-subdev-g-frame-interval SYSTEM "v4l/vidioc-subdev-g-frame-interval.xml"> | ||
| 301 | <!ENTITY sub-capture-c SYSTEM "v4l/capture.c.xml"> | 349 | <!ENTITY sub-capture-c SYSTEM "v4l/capture.c.xml"> |
| 302 | <!ENTITY sub-keytable-c SYSTEM "v4l/keytable.c.xml"> | 350 | <!ENTITY sub-keytable-c SYSTEM "v4l/keytable.c.xml"> |
| 303 | <!ENTITY sub-v4l2grab-c SYSTEM "v4l/v4l2grab.c.xml"> | 351 | <!ENTITY sub-v4l2grab-c SYSTEM "v4l/v4l2grab.c.xml"> |
| @@ -321,6 +369,15 @@ | |||
| 321 | <!ENTITY sub-media-entities SYSTEM "media-entities.tmpl"> | 369 | <!ENTITY sub-media-entities SYSTEM "media-entities.tmpl"> |
| 322 | <!ENTITY sub-media-indices SYSTEM "media-indices.tmpl"> | 370 | <!ENTITY sub-media-indices SYSTEM "media-indices.tmpl"> |
| 323 | 371 | ||
| 372 | <!ENTITY sub-media-controller SYSTEM "v4l/media-controller.xml"> | ||
| 373 | <!ENTITY sub-media-open SYSTEM "v4l/media-func-open.xml"> | ||
| 374 | <!ENTITY sub-media-close SYSTEM "v4l/media-func-close.xml"> | ||
| 375 | <!ENTITY sub-media-ioctl SYSTEM "v4l/media-func-ioctl.xml"> | ||
| 376 | <!ENTITY sub-media-ioc-device-info SYSTEM "v4l/media-ioc-device-info.xml"> | ||
| 377 | <!ENTITY sub-media-ioc-enum-entities SYSTEM "v4l/media-ioc-enum-entities.xml"> | ||
| 378 | <!ENTITY sub-media-ioc-enum-links SYSTEM "v4l/media-ioc-enum-links.xml"> | ||
| 379 | <!ENTITY sub-media-ioc-setup-link SYSTEM "v4l/media-ioc-setup-link.xml"> | ||
| 380 | |||
| 324 | <!-- Function Reference --> | 381 | <!-- Function Reference --> |
| 325 | <!ENTITY close SYSTEM "v4l/func-close.xml"> | 382 | <!ENTITY close SYSTEM "v4l/func-close.xml"> |
| 326 | <!ENTITY ioctl SYSTEM "v4l/func-ioctl.xml"> | 383 | <!ENTITY ioctl SYSTEM "v4l/func-ioctl.xml"> |
| @@ -333,6 +390,7 @@ | |||
| 333 | <!ENTITY write SYSTEM "v4l/func-write.xml"> | 390 | <!ENTITY write SYSTEM "v4l/func-write.xml"> |
| 334 | <!ENTITY grey SYSTEM "v4l/pixfmt-grey.xml"> | 391 | <!ENTITY grey SYSTEM "v4l/pixfmt-grey.xml"> |
| 335 | <!ENTITY nv12 SYSTEM "v4l/pixfmt-nv12.xml"> | 392 | <!ENTITY nv12 SYSTEM "v4l/pixfmt-nv12.xml"> |
| 393 | <!ENTITY nv12m SYSTEM "v4l/pixfmt-nv12m.xml"> | ||
| 336 | <!ENTITY nv16 SYSTEM "v4l/pixfmt-nv16.xml"> | 394 | <!ENTITY nv16 SYSTEM "v4l/pixfmt-nv16.xml"> |
| 337 | <!ENTITY packed-rgb SYSTEM "v4l/pixfmt-packed-rgb.xml"> | 395 | <!ENTITY packed-rgb SYSTEM "v4l/pixfmt-packed-rgb.xml"> |
| 338 | <!ENTITY packed-yuv SYSTEM "v4l/pixfmt-packed-yuv.xml"> | 396 | <!ENTITY packed-yuv SYSTEM "v4l/pixfmt-packed-yuv.xml"> |
| @@ -347,6 +405,7 @@ | |||
| 347 | <!ENTITY yuv410 SYSTEM "v4l/pixfmt-yuv410.xml"> | 405 | <!ENTITY yuv410 SYSTEM "v4l/pixfmt-yuv410.xml"> |
| 348 | <!ENTITY yuv411p SYSTEM "v4l/pixfmt-yuv411p.xml"> | 406 | <!ENTITY yuv411p SYSTEM "v4l/pixfmt-yuv411p.xml"> |
| 349 | <!ENTITY yuv420 SYSTEM "v4l/pixfmt-yuv420.xml"> | 407 | <!ENTITY yuv420 SYSTEM "v4l/pixfmt-yuv420.xml"> |
| 408 | <!ENTITY yuv420m SYSTEM "v4l/pixfmt-yuv420m.xml"> | ||
| 350 | <!ENTITY yuv422p SYSTEM "v4l/pixfmt-yuv422p.xml"> | 409 | <!ENTITY yuv422p SYSTEM "v4l/pixfmt-yuv422p.xml"> |
| 351 | <!ENTITY yuyv SYSTEM "v4l/pixfmt-yuyv.xml"> | 410 | <!ENTITY yuyv SYSTEM "v4l/pixfmt-yuyv.xml"> |
| 352 | <!ENTITY yvyu SYSTEM "v4l/pixfmt-yvyu.xml"> | 411 | <!ENTITY yvyu SYSTEM "v4l/pixfmt-yvyu.xml"> |
diff --git a/Documentation/DocBook/media.tmpl b/Documentation/DocBook/media.tmpl index a99088aae1aa..88f2cc680cc2 100644 --- a/Documentation/DocBook/media.tmpl +++ b/Documentation/DocBook/media.tmpl | |||
| @@ -106,6 +106,9 @@ Foundation. A copy of the license is included in the chapter entitled | |||
| 106 | &sub-remote_controllers; | 106 | &sub-remote_controllers; |
| 107 | </chapter> | 107 | </chapter> |
| 108 | </part> | 108 | </part> |
| 109 | <part id="media_common"> | ||
| 110 | &sub-media-controller; | ||
| 111 | </part> | ||
| 109 | 112 | ||
| 110 | &sub-fdl-appendix; | 113 | &sub-fdl-appendix; |
| 111 | 114 | ||
diff --git a/Documentation/DocBook/mtdnand.tmpl b/Documentation/DocBook/mtdnand.tmpl index 620eb3f6a90a..6f242d5dee9a 100644 --- a/Documentation/DocBook/mtdnand.tmpl +++ b/Documentation/DocBook/mtdnand.tmpl | |||
| @@ -485,7 +485,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip) | |||
| 485 | Reed-Solomon library. | 485 | Reed-Solomon library. |
| 486 | </para> | 486 | </para> |
| 487 | <para> | 487 | <para> |
| 488 | The ECC bytes must be placed immidiately after the data | 488 | The ECC bytes must be placed immediately after the data |
| 489 | bytes in order to make the syndrome generator work. This | 489 | bytes in order to make the syndrome generator work. This |
| 490 | is contrary to the usual layout used by software ECC. The | 490 | is contrary to the usual layout used by software ECC. The |
| 491 | separation of data and out of band area is not longer | 491 | 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) | |||
| 629 | holds the bad block table. Store a pointer to the pattern | 629 | holds the bad block table. Store a pointer to the pattern |
| 630 | in the pattern field. Further the length of the pattern has to be | 630 | in the pattern field. Further the length of the pattern has to be |
| 631 | stored in len and the offset in the spare area must be given | 631 | stored in len and the offset in the spare area must be given |
| 632 | in the offs member of the nand_bbt_descr stucture. For mirrored | 632 | in the offs member of the nand_bbt_descr structure. For mirrored |
| 633 | bad block tables different patterns are mandatory.</para></listitem> | 633 | bad block tables different patterns are mandatory.</para></listitem> |
| 634 | <listitem><para>Table creation</para> | 634 | <listitem><para>Table creation</para> |
| 635 | <para>Set the option NAND_BBT_CREATE to enable the table creation | 635 | <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) | |||
| 648 | <listitem><para>Table version control</para> | 648 | <listitem><para>Table version control</para> |
| 649 | <para>Set the option NAND_BBT_VERSION to enable the table version control. | 649 | <para>Set the option NAND_BBT_VERSION to enable the table version control. |
| 650 | It's highly recommended to enable this for mirrored tables with write | 650 | It's highly recommended to enable this for mirrored tables with write |
| 651 | support. It makes sure that the risk of loosing the bad block | 651 | support. It makes sure that the risk of losing the bad block |
| 652 | table information is reduced to the loss of the information about the | 652 | table information is reduced to the loss of the information about the |
| 653 | one worn out block which should be marked bad. The version is stored in | 653 | one worn out block which should be marked bad. The version is stored in |
| 654 | 4 consecutive bytes in the spare area of the device. The position of | 654 | 4 consecutive bytes in the spare area of the device. The position of |
| @@ -1060,19 +1060,19 @@ data in this page</entry> | |||
| 1060 | <row> | 1060 | <row> |
| 1061 | <entry>0x3D</entry> | 1061 | <entry>0x3D</entry> |
| 1062 | <entry>ECC byte 21</entry> | 1062 | <entry>ECC byte 21</entry> |
| 1063 | <entry>Error correction code byte 0 of the eigth 256 Bytes of data | 1063 | <entry>Error correction code byte 0 of the eighth 256 Bytes of data |
| 1064 | in this page</entry> | 1064 | in this page</entry> |
| 1065 | </row> | 1065 | </row> |
| 1066 | <row> | 1066 | <row> |
| 1067 | <entry>0x3E</entry> | 1067 | <entry>0x3E</entry> |
| 1068 | <entry>ECC byte 22</entry> | 1068 | <entry>ECC byte 22</entry> |
| 1069 | <entry>Error correction code byte 1 of the eigth 256 Bytes of data | 1069 | <entry>Error correction code byte 1 of the eighth 256 Bytes of data |
| 1070 | in this page</entry> | 1070 | in this page</entry> |
| 1071 | </row> | 1071 | </row> |
| 1072 | <row> | 1072 | <row> |
| 1073 | <entry>0x3F</entry> | 1073 | <entry>0x3F</entry> |
| 1074 | <entry>ECC byte 23</entry> | 1074 | <entry>ECC byte 23</entry> |
| 1075 | <entry>Error correction code byte 2 of the eigth 256 Bytes of data | 1075 | <entry>Error correction code byte 2 of the eighth 256 Bytes of data |
| 1076 | in this page</entry> | 1076 | in this page</entry> |
| 1077 | </row> | 1077 | </row> |
| 1078 | </tbody></tgroup></informaltable> | 1078 | </tbody></tgroup></informaltable> |
diff --git a/Documentation/DocBook/rapidio.tmpl b/Documentation/DocBook/rapidio.tmpl index 54eb26b57372..50479360d845 100644 --- a/Documentation/DocBook/rapidio.tmpl +++ b/Documentation/DocBook/rapidio.tmpl | |||
| @@ -133,7 +133,6 @@ | |||
| 133 | !Idrivers/rapidio/rio-sysfs.c | 133 | !Idrivers/rapidio/rio-sysfs.c |
| 134 | </sect1> | 134 | </sect1> |
| 135 | <sect1 id="PPC32_support"><title>PPC32 support</title> | 135 | <sect1 id="PPC32_support"><title>PPC32 support</title> |
| 136 | !Earch/powerpc/sysdev/fsl_rio.c | ||
| 137 | !Iarch/powerpc/sysdev/fsl_rio.c | 136 | !Iarch/powerpc/sysdev/fsl_rio.c |
| 138 | </sect1> | 137 | </sect1> |
| 139 | </chapter> | 138 | </chapter> |
diff --git a/Documentation/DocBook/regulator.tmpl b/Documentation/DocBook/regulator.tmpl index 53f4f8d3b810..346e552fa2cc 100644 --- a/Documentation/DocBook/regulator.tmpl +++ b/Documentation/DocBook/regulator.tmpl | |||
| @@ -267,8 +267,8 @@ | |||
| 267 | <sect1 id="machine-constraint"> | 267 | <sect1 id="machine-constraint"> |
| 268 | <title>Constraints</title> | 268 | <title>Constraints</title> |
| 269 | <para> | 269 | <para> |
| 270 | As well as definining the connections the machine interface | 270 | As well as defining the connections the machine interface |
| 271 | also provides constraints definining the operations that | 271 | also provides constraints defining the operations that |
| 272 | clients are allowed to perform and the parameters that may be | 272 | clients are allowed to perform and the parameters that may be |
| 273 | set. This is required since generally regulator devices will | 273 | set. This is required since generally regulator devices will |
| 274 | offer more flexibility than it is safe to use on a given | 274 | offer more flexibility than it is safe to use on a given |
diff --git a/Documentation/DocBook/uio-howto.tmpl b/Documentation/DocBook/uio-howto.tmpl index b4665b9c40b0..7c4b514d62b1 100644 --- a/Documentation/DocBook/uio-howto.tmpl +++ b/Documentation/DocBook/uio-howto.tmpl | |||
| @@ -797,7 +797,7 @@ framework to set up sysfs files for this region. Simply leave it alone. | |||
| 797 | perform some initialization. After that, your hardware | 797 | perform some initialization. After that, your hardware |
| 798 | starts working and will generate an interrupt as soon | 798 | starts working and will generate an interrupt as soon |
| 799 | as it's finished, has some data available, or needs your | 799 | as it's finished, has some data available, or needs your |
| 800 | attention because an error occured. | 800 | attention because an error occurred. |
| 801 | </para> | 801 | </para> |
| 802 | <para> | 802 | <para> |
| 803 | <filename>/dev/uioX</filename> is a read-only file. A | 803 | <filename>/dev/uioX</filename> is a read-only file. A |
diff --git a/Documentation/DocBook/usb.tmpl b/Documentation/DocBook/usb.tmpl index af293606fbe3..8d57c1888dca 100644 --- a/Documentation/DocBook/usb.tmpl +++ b/Documentation/DocBook/usb.tmpl | |||
| @@ -690,7 +690,7 @@ usbdev_ioctl (int fd, int ifno, unsigned request, void *param) | |||
| 690 | </para><para> | 690 | </para><para> |
| 691 | This request lets kernel drivers talk to user mode code | 691 | This request lets kernel drivers talk to user mode code |
| 692 | through filesystem operations even when they don't create | 692 | through filesystem operations even when they don't create |
| 693 | a charactor or block special device. | 693 | a character or block special device. |
| 694 | It's also been used to do things like ask devices what | 694 | It's also been used to do things like ask devices what |
| 695 | device special file should be used. | 695 | device special file should be used. |
| 696 | Two pre-defined ioctls are used | 696 | Two pre-defined ioctls are used |
diff --git a/Documentation/DocBook/v4l/bayer.pdf b/Documentation/DocBook/v4l/bayer.pdf new file mode 100644 index 000000000000..905e60e6cd42 --- /dev/null +++ b/Documentation/DocBook/v4l/bayer.pdf | |||
| Binary files differ | |||
diff --git a/Documentation/DocBook/v4l/bayer.png b/Documentation/DocBook/v4l/bayer.png new file mode 100644 index 000000000000..9b15fb22e817 --- /dev/null +++ b/Documentation/DocBook/v4l/bayer.png | |||
| Binary files differ | |||
diff --git a/Documentation/DocBook/v4l/common.xml b/Documentation/DocBook/v4l/common.xml index cea23e1c4fc6..9028721438dc 100644 --- a/Documentation/DocBook/v4l/common.xml +++ b/Documentation/DocBook/v4l/common.xml | |||
| @@ -100,7 +100,7 @@ linux-kernel@vger.kernel.org, 2002-11-20. --></para> | |||
| 100 | 100 | ||
| 101 | <para>By convention system administrators create various | 101 | <para>By convention system administrators create various |
| 102 | character device special files with these major and minor numbers in | 102 | character device special files with these major and minor numbers in |
| 103 | the <filename>/dev</filename> directory. The names recomended for the | 103 | the <filename>/dev</filename> directory. The names recommended for the |
| 104 | different V4L2 device types are listed in <xref linkend="devices" />. | 104 | different V4L2 device types are listed in <xref linkend="devices" />. |
| 105 | </para> | 105 | </para> |
| 106 | 106 | ||
| @@ -846,6 +846,8 @@ conversion routine or library for integration into applications.</para> | |||
| 846 | </section> | 846 | </section> |
| 847 | </section> | 847 | </section> |
| 848 | 848 | ||
| 849 | &sub-planar-apis; | ||
| 850 | |||
| 849 | <section id="crop"> | 851 | <section id="crop"> |
| 850 | <title>Image Cropping, Insertion and Scaling</title> | 852 | <title>Image Cropping, Insertion and Scaling</title> |
| 851 | 853 | ||
diff --git a/Documentation/DocBook/v4l/compat.xml b/Documentation/DocBook/v4l/compat.xml index c9ce61d981f5..9f7cd4f25792 100644 --- a/Documentation/DocBook/v4l/compat.xml +++ b/Documentation/DocBook/v4l/compat.xml | |||
| @@ -1711,8 +1711,8 @@ ioctl would enumerate the available audio inputs. An ioctl to | |||
| 1711 | determine the current audio input, if more than one combines with the | 1711 | determine the current audio input, if more than one combines with the |
| 1712 | current video input, did not exist. So | 1712 | current video input, did not exist. So |
| 1713 | <constant>VIDIOC_G_AUDIO</constant> was renamed to | 1713 | <constant>VIDIOC_G_AUDIO</constant> was renamed to |
| 1714 | <constant>VIDIOC_G_AUDIO_OLD</constant>, this ioctl will be removed in | 1714 | <constant>VIDIOC_G_AUDIO_OLD</constant>, this ioctl was removed on |
| 1715 | the future. The &VIDIOC-ENUMAUDIO; ioctl was added to enumerate | 1715 | Kernel 2.6.39. The &VIDIOC-ENUMAUDIO; ioctl was added to enumerate |
| 1716 | audio inputs, while &VIDIOC-G-AUDIO; now reports the current audio | 1716 | audio inputs, while &VIDIOC-G-AUDIO; now reports the current audio |
| 1717 | input.</para> | 1717 | input.</para> |
| 1718 | <para>The same changes were made to &VIDIOC-G-AUDOUT; and | 1718 | <para>The same changes were made to &VIDIOC-G-AUDOUT; and |
| @@ -1726,7 +1726,7 @@ must be updated to successfully compile again.</para> | |||
| 1726 | <para>The &VIDIOC-OVERLAY; ioctl was incorrectly defined with | 1726 | <para>The &VIDIOC-OVERLAY; ioctl was incorrectly defined with |
| 1727 | write-read parameter. It was changed to write-only, while the write-read | 1727 | write-read parameter. It was changed to write-only, while the write-read |
| 1728 | version was renamed to <constant>VIDIOC_OVERLAY_OLD</constant>. The old | 1728 | version was renamed to <constant>VIDIOC_OVERLAY_OLD</constant>. The old |
| 1729 | ioctl will be removed in the future. Until further the "videodev" | 1729 | ioctl was removed on Kernel 2.6.39. Until further the "videodev" |
| 1730 | kernel module will automatically translate to the new version, so drivers | 1730 | kernel module will automatically translate to the new version, so drivers |
| 1731 | must be recompiled, but not applications.</para> | 1731 | must be recompiled, but not applications.</para> |
| 1732 | </listitem> | 1732 | </listitem> |
| @@ -1744,7 +1744,7 @@ surface can be seen.</para> | |||
| 1744 | defined with write-only parameter, inconsistent with other ioctls | 1744 | defined with write-only parameter, inconsistent with other ioctls |
| 1745 | modifying their argument. They were changed to write-read, while a | 1745 | modifying their argument. They were changed to write-read, while a |
| 1746 | <constant>_OLD</constant> suffix was added to the write-only versions. | 1746 | <constant>_OLD</constant> suffix was added to the write-only versions. |
| 1747 | The old ioctls will be removed in the future. Drivers and | 1747 | The old ioctls were removed on Kernel 2.6.39. Drivers and |
| 1748 | applications assuming a constant parameter need an update.</para> | 1748 | applications assuming a constant parameter need an update.</para> |
| 1749 | </listitem> | 1749 | </listitem> |
| 1750 | </orderedlist> | 1750 | </orderedlist> |
| @@ -1815,8 +1815,8 @@ yet to be addressed, for details see <xref | |||
| 1815 | <para>The &VIDIOC-CROPCAP; ioctl was incorrectly defined | 1815 | <para>The &VIDIOC-CROPCAP; ioctl was incorrectly defined |
| 1816 | with read-only parameter. It is now defined as write-read ioctl, while | 1816 | with read-only parameter. It is now defined as write-read ioctl, while |
| 1817 | the read-only version was renamed to | 1817 | the read-only version was renamed to |
| 1818 | <constant>VIDIOC_CROPCAP_OLD</constant>. The old ioctl will be removed | 1818 | <constant>VIDIOC_CROPCAP_OLD</constant>. The old ioctl was removed |
| 1819 | in the future.</para> | 1819 | on Kernel 2.6.39.</para> |
| 1820 | </listitem> | 1820 | </listitem> |
| 1821 | </orderedlist> | 1821 | </orderedlist> |
| 1822 | </section> | 1822 | </section> |
| @@ -2353,6 +2353,20 @@ that used it. It was originally scheduled for removal in 2.6.35. | |||
| 2353 | </listitem> | 2353 | </listitem> |
| 2354 | </orderedlist> | 2354 | </orderedlist> |
| 2355 | </section> | 2355 | </section> |
| 2356 | <section> | ||
| 2357 | <title>V4L2 in Linux 2.6.39</title> | ||
| 2358 | <orderedlist> | ||
| 2359 | <listitem> | ||
| 2360 | <para>The old VIDIOC_*_OLD symbols and V4L1 support were removed.</para> | ||
| 2361 | </listitem> | ||
| 2362 | <listitem> | ||
| 2363 | <para>Multi-planar API added. Does not affect the compatibility of | ||
| 2364 | current drivers and applications. See | ||
| 2365 | <link linkend="planar-apis">multi-planar API</link> | ||
| 2366 | for details.</para> | ||
| 2367 | </listitem> | ||
| 2368 | </orderedlist> | ||
| 2369 | </section> | ||
| 2356 | 2370 | ||
| 2357 | <section id="other"> | 2371 | <section id="other"> |
| 2358 | <title>Relation of V4L2 to other Linux multimedia APIs</title> | 2372 | <title>Relation of V4L2 to other Linux multimedia APIs</title> |
diff --git a/Documentation/DocBook/v4l/controls.xml b/Documentation/DocBook/v4l/controls.xml index 2fae3e87ce73..a920ee80f640 100644 --- a/Documentation/DocBook/v4l/controls.xml +++ b/Documentation/DocBook/v4l/controls.xml | |||
| @@ -1243,7 +1243,7 @@ values are:</entry> | |||
| 1243 | </row><row><entry spanname="descr">Mutes the audio when | 1243 | </row><row><entry spanname="descr">Mutes the audio when |
| 1244 | capturing. This is not done by muting audio hardware, which can still | 1244 | capturing. This is not done by muting audio hardware, which can still |
| 1245 | produce a slight hiss, but in the encoder itself, guaranteeing a fixed | 1245 | produce a slight hiss, but in the encoder itself, guaranteeing a fixed |
| 1246 | and reproducable audio bitstream. 0 = unmuted, 1 = muted.</entry> | 1246 | and reproducible audio bitstream. 0 = unmuted, 1 = muted.</entry> |
| 1247 | </row> | 1247 | </row> |
| 1248 | <row><entry></entry></row> | 1248 | <row><entry></entry></row> |
| 1249 | <row id="v4l2-mpeg-video-encoding"> | 1249 | <row id="v4l2-mpeg-video-encoding"> |
diff --git a/Documentation/DocBook/v4l/dev-capture.xml b/Documentation/DocBook/v4l/dev-capture.xml index 32807e43f170..2237c661f26a 100644 --- a/Documentation/DocBook/v4l/dev-capture.xml +++ b/Documentation/DocBook/v4l/dev-capture.xml | |||
| @@ -18,7 +18,8 @@ files are used for video output devices.</para> | |||
| 18 | <title>Querying Capabilities</title> | 18 | <title>Querying Capabilities</title> |
| 19 | 19 | ||
| 20 | <para>Devices supporting the video capture interface set the | 20 | <para>Devices supporting the video capture interface set the |
| 21 | <constant>V4L2_CAP_VIDEO_CAPTURE</constant> flag in the | 21 | <constant>V4L2_CAP_VIDEO_CAPTURE</constant> or |
| 22 | <constant>V4L2_CAP_VIDEO_CAPTURE_MPLANE</constant> flag in the | ||
| 22 | <structfield>capabilities</structfield> field of &v4l2-capability; | 23 | <structfield>capabilities</structfield> field of &v4l2-capability; |
| 23 | returned by the &VIDIOC-QUERYCAP; ioctl. As secondary device functions | 24 | returned by the &VIDIOC-QUERYCAP; ioctl. As secondary device functions |
| 24 | they may also support the <link linkend="overlay">video overlay</link> | 25 | they may also support the <link linkend="overlay">video overlay</link> |
| @@ -64,9 +65,11 @@ linkend="crop" />.</para> | |||
| 64 | 65 | ||
| 65 | <para>To query the current image format applications set the | 66 | <para>To query the current image format applications set the |
| 66 | <structfield>type</structfield> field of a &v4l2-format; to | 67 | <structfield>type</structfield> field of a &v4l2-format; to |
| 67 | <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant> and call the | 68 | <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant> or |
| 69 | <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant> and call the | ||
| 68 | &VIDIOC-G-FMT; ioctl with a pointer to this structure. Drivers fill | 70 | &VIDIOC-G-FMT; ioctl with a pointer to this structure. Drivers fill |
| 69 | the &v4l2-pix-format; <structfield>pix</structfield> member of the | 71 | the &v4l2-pix-format; <structfield>pix</structfield> or the |
| 72 | &v4l2-pix-format-mplane; <structfield>pix_mp</structfield> member of the | ||
| 70 | <structfield>fmt</structfield> union.</para> | 73 | <structfield>fmt</structfield> union.</para> |
| 71 | 74 | ||
| 72 | <para>To request different parameters applications set the | 75 | <para>To request different parameters applications set the |
| @@ -84,8 +87,8 @@ adjust the parameters and finally return the actual parameters as | |||
| 84 | without disabling I/O or possibly time consuming hardware | 87 | without disabling I/O or possibly time consuming hardware |
| 85 | preparations.</para> | 88 | preparations.</para> |
| 86 | 89 | ||
| 87 | <para>The contents of &v4l2-pix-format; are discussed in <xref | 90 | <para>The contents of &v4l2-pix-format; and &v4l2-pix-format-mplane; |
| 88 | linkend="pixfmt" />. See also the specification of the | 91 | are discussed in <xref linkend="pixfmt" />. See also the specification of the |
| 89 | <constant>VIDIOC_G_FMT</constant>, <constant>VIDIOC_S_FMT</constant> | 92 | <constant>VIDIOC_G_FMT</constant>, <constant>VIDIOC_S_FMT</constant> |
| 90 | and <constant>VIDIOC_TRY_FMT</constant> ioctls for details. Video | 93 | and <constant>VIDIOC_TRY_FMT</constant> ioctls for details. Video |
| 91 | capture devices must implement both the | 94 | capture devices must implement both the |
diff --git a/Documentation/DocBook/v4l/dev-output.xml b/Documentation/DocBook/v4l/dev-output.xml index 63c3c20e5a72..919e22c53854 100644 --- a/Documentation/DocBook/v4l/dev-output.xml +++ b/Documentation/DocBook/v4l/dev-output.xml | |||
| @@ -17,7 +17,8 @@ files are used for video capture devices.</para> | |||
| 17 | <title>Querying Capabilities</title> | 17 | <title>Querying Capabilities</title> |
| 18 | 18 | ||
| 19 | <para>Devices supporting the video output interface set the | 19 | <para>Devices supporting the video output interface set the |
| 20 | <constant>V4L2_CAP_VIDEO_OUTPUT</constant> flag in the | 20 | <constant>V4L2_CAP_VIDEO_OUTPUT</constant> or |
| 21 | <constant>V4L2_CAP_VIDEO_OUTPUT_MPLANE</constant> flag in the | ||
| 21 | <structfield>capabilities</structfield> field of &v4l2-capability; | 22 | <structfield>capabilities</structfield> field of &v4l2-capability; |
| 22 | returned by the &VIDIOC-QUERYCAP; ioctl. As secondary device functions | 23 | returned by the &VIDIOC-QUERYCAP; ioctl. As secondary device functions |
| 23 | they may also support the <link linkend="raw-vbi">raw VBI | 24 | they may also support the <link linkend="raw-vbi">raw VBI |
| @@ -60,9 +61,11 @@ linkend="crop" />.</para> | |||
| 60 | 61 | ||
| 61 | <para>To query the current image format applications set the | 62 | <para>To query the current image format applications set the |
| 62 | <structfield>type</structfield> field of a &v4l2-format; to | 63 | <structfield>type</structfield> field of a &v4l2-format; to |
| 63 | <constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> and call the | 64 | <constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> or |
| 65 | <constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant> and call the | ||
| 64 | &VIDIOC-G-FMT; ioctl with a pointer to this structure. Drivers fill | 66 | &VIDIOC-G-FMT; ioctl with a pointer to this structure. Drivers fill |
| 65 | the &v4l2-pix-format; <structfield>pix</structfield> member of the | 67 | the &v4l2-pix-format; <structfield>pix</structfield> or the |
| 68 | &v4l2-pix-format-mplane; <structfield>pix_mp</structfield> member of the | ||
| 66 | <structfield>fmt</structfield> union.</para> | 69 | <structfield>fmt</structfield> union.</para> |
| 67 | 70 | ||
| 68 | <para>To request different parameters applications set the | 71 | <para>To request different parameters applications set the |
| @@ -80,8 +83,8 @@ adjust the parameters and finally return the actual parameters as | |||
| 80 | without disabling I/O or possibly time consuming hardware | 83 | without disabling I/O or possibly time consuming hardware |
| 81 | preparations.</para> | 84 | preparations.</para> |
| 82 | 85 | ||
| 83 | <para>The contents of &v4l2-pix-format; are discussed in <xref | 86 | <para>The contents of &v4l2-pix-format; and &v4l2-pix-format-mplane; |
| 84 | linkend="pixfmt" />. See also the specification of the | 87 | are discussed in <xref linkend="pixfmt" />. See also the specification of the |
| 85 | <constant>VIDIOC_G_FMT</constant>, <constant>VIDIOC_S_FMT</constant> | 88 | <constant>VIDIOC_G_FMT</constant>, <constant>VIDIOC_S_FMT</constant> |
| 86 | and <constant>VIDIOC_TRY_FMT</constant> ioctls for details. Video | 89 | and <constant>VIDIOC_TRY_FMT</constant> ioctls for details. Video |
| 87 | output devices must implement both the | 90 | output devices must implement both the |
diff --git a/Documentation/DocBook/v4l/dev-subdev.xml b/Documentation/DocBook/v4l/dev-subdev.xml new file mode 100644 index 000000000000..05c8fefcbcbe --- /dev/null +++ b/Documentation/DocBook/v4l/dev-subdev.xml | |||
| @@ -0,0 +1,313 @@ | |||
| 1 | <title>Sub-device Interface</title> | ||
| 2 | |||
| 3 | <note> | ||
| 4 | <title>Experimental</title> | ||
| 5 | <para>This is an <link linkend="experimental">experimental</link> | ||
| 6 | interface and may change in the future.</para> | ||
| 7 | </note> | ||
| 8 | |||
| 9 | <para>The complex nature of V4L2 devices, where hardware is often made of | ||
| 10 | several integrated circuits that need to interact with each other in a | ||
| 11 | controlled way, leads to complex V4L2 drivers. The drivers usually reflect | ||
| 12 | the hardware model in software, and model the different hardware components | ||
| 13 | as software blocks called sub-devices.</para> | ||
| 14 | |||
| 15 | <para>V4L2 sub-devices are usually kernel-only objects. If the V4L2 driver | ||
| 16 | implements the media device API, they will automatically inherit from media | ||
| 17 | entities. Applications will be able to enumerate the sub-devices and discover | ||
| 18 | the hardware topology using the media entities, pads and links enumeration | ||
| 19 | API.</para> | ||
| 20 | |||
| 21 | <para>In addition to make sub-devices discoverable, drivers can also choose | ||
| 22 | to make them directly configurable by applications. When both the sub-device | ||
| 23 | driver and the V4L2 device driver support this, sub-devices will feature a | ||
| 24 | character device node on which ioctls can be called to | ||
| 25 | <itemizedlist> | ||
| 26 | <listitem><para>query, read and write sub-devices controls</para></listitem> | ||
| 27 | <listitem><para>subscribe and unsubscribe to events and retrieve them</para></listitem> | ||
| 28 | <listitem><para>negotiate image formats on individual pads</para></listitem> | ||
| 29 | </itemizedlist> | ||
| 30 | </para> | ||
| 31 | |||
| 32 | <para>Sub-device character device nodes, conventionally named | ||
| 33 | <filename>/dev/v4l-subdev*</filename>, use major number 81.</para> | ||
| 34 | |||
| 35 | <section> | ||
| 36 | <title>Controls</title> | ||
| 37 | <para>Most V4L2 controls are implemented by sub-device hardware. Drivers | ||
| 38 | usually merge all controls and expose them through video device nodes. | ||
| 39 | Applications can control all sub-devices through a single interface.</para> | ||
| 40 | |||
| 41 | <para>Complex devices sometimes implement the same control in different | ||
| 42 | pieces of hardware. This situation is common in embedded platforms, where | ||
| 43 | both sensors and image processing hardware implement identical functions, | ||
| 44 | such as contrast adjustment, white balance or faulty pixels correction. As | ||
| 45 | the V4L2 controls API doesn't support several identical controls in a single | ||
| 46 | device, all but one of the identical controls are hidden.</para> | ||
| 47 | |||
| 48 | <para>Applications can access those hidden controls through the sub-device | ||
| 49 | node with the V4L2 control API described in <xref linkend="control" />. The | ||
| 50 | ioctls behave identically as when issued on V4L2 device nodes, with the | ||
| 51 | exception that they deal only with controls implemented in the sub-device. | ||
| 52 | </para> | ||
| 53 | |||
| 54 | <para>Depending on the driver, those controls might also be exposed through | ||
| 55 | one (or several) V4L2 device nodes.</para> | ||
| 56 | </section> | ||
| 57 | |||
| 58 | <section> | ||
| 59 | <title>Events</title> | ||
| 60 | <para>V4L2 sub-devices can notify applications of events as described in | ||
| 61 | <xref linkend="event" />. The API behaves identically as when used on V4L2 | ||
| 62 | device nodes, with the exception that it only deals with events generated by | ||
| 63 | the sub-device. Depending on the driver, those events might also be reported | ||
| 64 | on one (or several) V4L2 device nodes.</para> | ||
| 65 | </section> | ||
| 66 | |||
| 67 | <section id="pad-level-formats"> | ||
| 68 | <title>Pad-level Formats</title> | ||
| 69 | |||
| 70 | <warning><para>Pad-level formats are only applicable to very complex device that | ||
| 71 | need to expose low-level format configuration to user space. Generic V4L2 | ||
| 72 | applications do <emphasis>not</emphasis> need to use the API described in | ||
| 73 | this section.</para></warning> | ||
| 74 | |||
| 75 | <note><para>For the purpose of this section, the term | ||
| 76 | <wordasword>format</wordasword> means the combination of media bus data | ||
| 77 | format, frame width and frame height.</para></note> | ||
| 78 | |||
| 79 | <para>Image formats are typically negotiated on video capture and output | ||
| 80 | devices using the <link linkend="crop">cropping and scaling</link> ioctls. | ||
| 81 | The driver is responsible for configuring every block in the video pipeline | ||
| 82 | according to the requested format at the pipeline input and/or | ||
| 83 | output.</para> | ||
| 84 | |||
| 85 | <para>For complex devices, such as often found in embedded systems, | ||
| 86 | identical image sizes at the output of a pipeline can be achieved using | ||
| 87 | different hardware configurations. One such example is shown on | ||
| 88 | <xref linkend="pipeline-scaling" />, where | ||
| 89 | image scaling can be performed on both the video sensor and the host image | ||
| 90 | processing hardware.</para> | ||
| 91 | |||
| 92 | <figure id="pipeline-scaling"> | ||
| 93 | <title>Image Format Negotiation on Pipelines</title> | ||
| 94 | <mediaobject> | ||
| 95 | <imageobject> | ||
| 96 | <imagedata fileref="pipeline.pdf" format="PS" /> | ||
| 97 | </imageobject> | ||
| 98 | <imageobject> | ||
| 99 | <imagedata fileref="pipeline.png" format="PNG" /> | ||
| 100 | </imageobject> | ||
| 101 | <textobject> | ||
| 102 | <phrase>High quality and high speed pipeline configuration</phrase> | ||
| 103 | </textobject> | ||
| 104 | </mediaobject> | ||
| 105 | </figure> | ||
| 106 | |||
| 107 | <para>The sensor scaler is usually of less quality than the host scaler, but | ||
| 108 | scaling on the sensor is required to achieve higher frame rates. Depending | ||
| 109 | on the use case (quality vs. speed), the pipeline must be configured | ||
| 110 | differently. Applications need to configure the formats at every point in | ||
| 111 | the pipeline explicitly.</para> | ||
| 112 | |||
| 113 | <para>Drivers that implement the <link linkend="media-controller-intro">media | ||
| 114 | API</link> can expose pad-level image format configuration to applications. | ||
| 115 | When they do, applications can use the &VIDIOC-SUBDEV-G-FMT; and | ||
| 116 | &VIDIOC-SUBDEV-S-FMT; ioctls. to negotiate formats on a per-pad basis.</para> | ||
| 117 | |||
| 118 | <para>Applications are responsible for configuring coherent parameters on | ||
| 119 | the whole pipeline and making sure that connected pads have compatible | ||
| 120 | formats. The pipeline is checked for formats mismatch at &VIDIOC-STREAMON; | ||
| 121 | time, and an &EPIPE; is then returned if the configuration is | ||
| 122 | invalid.</para> | ||
| 123 | |||
| 124 | <para>Pad-level image format configuration support can be tested by calling | ||
| 125 | the &VIDIOC-SUBDEV-G-FMT; ioctl on pad 0. If the driver returns an &EINVAL; | ||
| 126 | pad-level format configuration is not supported by the sub-device.</para> | ||
| 127 | |||
| 128 | <section> | ||
| 129 | <title>Format Negotiation</title> | ||
| 130 | |||
| 131 | <para>Acceptable formats on pads can (and usually do) depend on a number | ||
| 132 | of external parameters, such as formats on other pads, active links, or | ||
| 133 | even controls. Finding a combination of formats on all pads in a video | ||
| 134 | pipeline, acceptable to both application and driver, can't rely on formats | ||
| 135 | enumeration only. A format negotiation mechanism is required.</para> | ||
| 136 | |||
| 137 | <para>Central to the format negotiation mechanism are the get/set format | ||
| 138 | operations. When called with the <structfield>which</structfield> argument | ||
| 139 | set to <constant>V4L2_SUBDEV_FORMAT_TRY</constant>, the | ||
| 140 | &VIDIOC-SUBDEV-G-FMT; and &VIDIOC-SUBDEV-S-FMT; ioctls operate on a set of | ||
| 141 | formats parameters that are not connected to the hardware configuration. | ||
| 142 | Modifying those 'try' formats leaves the device state untouched (this | ||
| 143 | applies to both the software state stored in the driver and the hardware | ||
| 144 | state stored in the device itself).</para> | ||
| 145 | |||
| 146 | <para>While not kept as part of the device state, try formats are stored | ||
| 147 | in the sub-device file handles. A &VIDIOC-SUBDEV-G-FMT; call will return | ||
| 148 | the last try format set <emphasis>on the same sub-device file | ||
| 149 | handle</emphasis>. Several applications querying the same sub-device at | ||
| 150 | the same time will thus not interact with each other.</para> | ||
| 151 | |||
| 152 | <para>To find out whether a particular format is supported by the device, | ||
| 153 | applications use the &VIDIOC-SUBDEV-S-FMT; ioctl. Drivers verify and, if | ||
| 154 | needed, change the requested <structfield>format</structfield> based on | ||
| 155 | device requirements and return the possibly modified value. Applications | ||
| 156 | can then choose to try a different format or accept the returned value and | ||
| 157 | continue.</para> | ||
| 158 | |||
| 159 | <para>Formats returned by the driver during a negotiation iteration are | ||
| 160 | guaranteed to be supported by the device. In particular, drivers guarantee | ||
| 161 | that a returned format will not be further changed if passed to an | ||
| 162 | &VIDIOC-SUBDEV-S-FMT; call as-is (as long as external parameters, such as | ||
| 163 | formats on other pads or links' configuration are not changed).</para> | ||
| 164 | |||
| 165 | <para>Drivers automatically propagate formats inside sub-devices. When a | ||
| 166 | try or active format is set on a pad, corresponding formats on other pads | ||
| 167 | of the same sub-device can be modified by the driver. Drivers are free to | ||
| 168 | modify formats as required by the device. However, they should comply with | ||
| 169 | the following rules when possible: | ||
| 170 | <itemizedlist> | ||
| 171 | <listitem><para>Formats should be propagated from sink pads to source pads. | ||
| 172 | Modifying a format on a source pad should not modify the format on any | ||
| 173 | sink pad.</para></listitem> | ||
| 174 | <listitem><para>Sub-devices that scale frames using variable scaling factors | ||
| 175 | should reset the scale factors to default values when sink pads formats | ||
| 176 | are modified. If the 1:1 scaling ratio is supported, this means that | ||
| 177 | source pads formats should be reset to the sink pads formats.</para></listitem> | ||
| 178 | </itemizedlist> | ||
| 179 | </para> | ||
| 180 | |||
| 181 | <para>Formats are not propagated across links, as that would involve | ||
| 182 | propagating them from one sub-device file handle to another. Applications | ||
| 183 | must then take care to configure both ends of every link explicitly with | ||
| 184 | compatible formats. Identical formats on the two ends of a link are | ||
| 185 | guaranteed to be compatible. Drivers are free to accept different formats | ||
| 186 | matching device requirements as being compatible.</para> | ||
| 187 | |||
| 188 | <para><xref linkend="sample-pipeline-config" /> | ||
| 189 | shows a sample configuration sequence for the pipeline described in | ||
| 190 | <xref linkend="pipeline-scaling" /> (table | ||
| 191 | columns list entity names and pad numbers).</para> | ||
| 192 | |||
| 193 | <table pgwide="0" frame="none" id="sample-pipeline-config"> | ||
| 194 | <title>Sample Pipeline Configuration</title> | ||
| 195 | <tgroup cols="3"> | ||
| 196 | <colspec colname="what"/> | ||
| 197 | <colspec colname="sensor-0" /> | ||
| 198 | <colspec colname="frontend-0" /> | ||
| 199 | <colspec colname="frontend-1" /> | ||
| 200 | <colspec colname="scaler-0" /> | ||
| 201 | <colspec colname="scaler-1" /> | ||
| 202 | <thead> | ||
| 203 | <row> | ||
| 204 | <entry></entry> | ||
| 205 | <entry>Sensor/0</entry> | ||
| 206 | <entry>Frontend/0</entry> | ||
| 207 | <entry>Frontend/1</entry> | ||
| 208 | <entry>Scaler/0</entry> | ||
| 209 | <entry>Scaler/1</entry> | ||
| 210 | </row> | ||
| 211 | </thead> | ||
| 212 | <tbody valign="top"> | ||
| 213 | <row> | ||
| 214 | <entry>Initial state</entry> | ||
| 215 | <entry>2048x1536</entry> | ||
| 216 | <entry>-</entry> | ||
| 217 | <entry>-</entry> | ||
| 218 | <entry>-</entry> | ||
| 219 | <entry>-</entry> | ||
| 220 | </row> | ||
| 221 | <row> | ||
| 222 | <entry>Configure frontend input</entry> | ||
| 223 | <entry>2048x1536</entry> | ||
| 224 | <entry><emphasis>2048x1536</emphasis></entry> | ||
| 225 | <entry><emphasis>2046x1534</emphasis></entry> | ||
| 226 | <entry>-</entry> | ||
| 227 | <entry>-</entry> | ||
| 228 | </row> | ||
| 229 | <row> | ||
| 230 | <entry>Configure scaler input</entry> | ||
| 231 | <entry>2048x1536</entry> | ||
| 232 | <entry>2048x1536</entry> | ||
| 233 | <entry>2046x1534</entry> | ||
| 234 | <entry><emphasis>2046x1534</emphasis></entry> | ||
| 235 | <entry><emphasis>2046x1534</emphasis></entry> | ||
| 236 | </row> | ||
| 237 | <row> | ||
| 238 | <entry>Configure scaler output</entry> | ||
| 239 | <entry>2048x1536</entry> | ||
| 240 | <entry>2048x1536</entry> | ||
| 241 | <entry>2046x1534</entry> | ||
| 242 | <entry>2046x1534</entry> | ||
| 243 | <entry><emphasis>1280x960</emphasis></entry> | ||
| 244 | </row> | ||
| 245 | </tbody> | ||
| 246 | </tgroup> | ||
| 247 | </table> | ||
| 248 | |||
| 249 | <para> | ||
| 250 | <orderedlist> | ||
| 251 | <listitem><para>Initial state. The sensor output is set to its native 3MP | ||
| 252 | resolution. Resolutions on the host frontend and scaler input and output | ||
| 253 | pads are undefined.</para></listitem> | ||
| 254 | <listitem><para>The application configures the frontend input pad resolution to | ||
| 255 | 2048x1536. The driver propagates the format to the frontend output pad. | ||
| 256 | Note that the propagated output format can be different, as in this case, | ||
| 257 | than the input format, as the hardware might need to crop pixels (for | ||
| 258 | instance when converting a Bayer filter pattern to RGB or YUV).</para></listitem> | ||
| 259 | <listitem><para>The application configures the scaler input pad resolution to | ||
| 260 | 2046x1534 to match the frontend output resolution. The driver propagates | ||
| 261 | the format to the scaler output pad.</para></listitem> | ||
| 262 | <listitem><para>The application configures the scaler output pad resolution to | ||
| 263 | 1280x960.</para></listitem> | ||
| 264 | </orderedlist> | ||
| 265 | </para> | ||
| 266 | |||
| 267 | <para>When satisfied with the try results, applications can set the active | ||
| 268 | formats by setting the <structfield>which</structfield> argument to | ||
| 269 | <constant>V4L2_SUBDEV_FORMAT_TRY</constant>. Active formats are changed | ||
| 270 | exactly as try formats by drivers. To avoid modifying the hardware state | ||
| 271 | during format negotiation, applications should negotiate try formats first | ||
| 272 | and then modify the active settings using the try formats returned during | ||
| 273 | the last negotiation iteration. This guarantees that the active format | ||
| 274 | will be applied as-is by the driver without being modified. | ||
| 275 | </para> | ||
| 276 | </section> | ||
| 277 | |||
| 278 | <section> | ||
| 279 | <title>Cropping and scaling</title> | ||
| 280 | |||
| 281 | <para>Many sub-devices support cropping frames on their input or output | ||
| 282 | pads (or possible even on both). Cropping is used to select the area of | ||
| 283 | interest in an image, typically on a video sensor or video decoder. It can | ||
| 284 | also be used as part of digital zoom implementations to select the area of | ||
| 285 | the image that will be scaled up.</para> | ||
| 286 | |||
| 287 | <para>Crop settings are defined by a crop rectangle and represented in a | ||
| 288 | &v4l2-rect; by the coordinates of the top left corner and the rectangle | ||
| 289 | size. Both the coordinates and sizes are expressed in pixels.</para> | ||
| 290 | |||
| 291 | <para>The crop rectangle is retrieved and set using the | ||
| 292 | &VIDIOC-SUBDEV-G-CROP; and &VIDIOC-SUBDEV-S-CROP; ioctls. Like for pad | ||
| 293 | formats, drivers store try and active crop rectangles. The format | ||
| 294 | negotiation mechanism applies to crop settings as well.</para> | ||
| 295 | |||
| 296 | <para>On input pads, cropping is applied relatively to the current pad | ||
| 297 | format. The pad format represents the image size as received by the | ||
| 298 | sub-device from the previous block in the pipeline, and the crop rectangle | ||
| 299 | represents the sub-image that will be transmitted further inside the | ||
| 300 | sub-device for processing. The crop rectangle be entirely containted | ||
| 301 | inside the input image size.</para> | ||
| 302 | |||
| 303 | <para>Input crop rectangle are reset to their default value when the input | ||
| 304 | image format is modified. Drivers should use the input image size as the | ||
| 305 | crop rectangle default value, but hardware requirements may prevent this. | ||
| 306 | </para> | ||
| 307 | |||
| 308 | <para>Cropping behaviour on output pads is not defined.</para> | ||
| 309 | |||
| 310 | </section> | ||
| 311 | </section> | ||
| 312 | |||
| 313 | &sub-subdev-formats; | ||
diff --git a/Documentation/DocBook/v4l/func-mmap.xml b/Documentation/DocBook/v4l/func-mmap.xml index 2e2fc3933aea..786732b64bbd 100644 --- a/Documentation/DocBook/v4l/func-mmap.xml +++ b/Documentation/DocBook/v4l/func-mmap.xml | |||
| @@ -45,7 +45,10 @@ just specify a <constant>NULL</constant> pointer here.</para> | |||
| 45 | <listitem> | 45 | <listitem> |
| 46 | <para>Length of the memory area to map. This must be the | 46 | <para>Length of the memory area to map. This must be the |
| 47 | same value as returned by the driver in the &v4l2-buffer; | 47 | same value as returned by the driver in the &v4l2-buffer; |
| 48 | <structfield>length</structfield> field.</para> | 48 | <structfield>length</structfield> field for the |
| 49 | single-planar API, and the same value as returned by the driver | ||
| 50 | in the &v4l2-plane; <structfield>length</structfield> field for the | ||
| 51 | multi-planar API.</para> | ||
| 49 | </listitem> | 52 | </listitem> |
| 50 | </varlistentry> | 53 | </varlistentry> |
| 51 | <varlistentry> | 54 | <varlistentry> |
| @@ -106,7 +109,10 @@ flag.</para> | |||
| 106 | <listitem> | 109 | <listitem> |
| 107 | <para>Offset of the buffer in device memory. This must be the | 110 | <para>Offset of the buffer in device memory. This must be the |
| 108 | same value as returned by the driver in the &v4l2-buffer; | 111 | same value as returned by the driver in the &v4l2-buffer; |
| 109 | <structfield>m</structfield> union <structfield>offset</structfield> field.</para> | 112 | <structfield>m</structfield> union <structfield>offset</structfield> field for |
| 113 | the single-planar API, and the same value as returned by the driver | ||
| 114 | in the &v4l2-plane; <structfield>m</structfield> union | ||
| 115 | <structfield>mem_offset</structfield> field for the multi-planar API.</para> | ||
| 110 | </listitem> | 116 | </listitem> |
| 111 | </varlistentry> | 117 | </varlistentry> |
| 112 | </variablelist> | 118 | </variablelist> |
diff --git a/Documentation/DocBook/v4l/func-munmap.xml b/Documentation/DocBook/v4l/func-munmap.xml index 502ed49323b0..e2c4190f9bb6 100644 --- a/Documentation/DocBook/v4l/func-munmap.xml +++ b/Documentation/DocBook/v4l/func-munmap.xml | |||
| @@ -37,7 +37,8 @@ | |||
| 37 | <para>Length of the mapped buffer. This must be the same | 37 | <para>Length of the mapped buffer. This must be the same |
| 38 | value as given to <function>mmap()</function> and returned by the | 38 | value as given to <function>mmap()</function> and returned by the |
| 39 | driver in the &v4l2-buffer; <structfield>length</structfield> | 39 | driver in the &v4l2-buffer; <structfield>length</structfield> |
| 40 | field.</para> | 40 | field for the single-planar API and in the &v4l2-plane; |
| 41 | <structfield>length</structfield> field for the multi-planar API.</para> | ||
| 41 | </listitem> | 42 | </listitem> |
| 42 | </varlistentry> | 43 | </varlistentry> |
| 43 | </variablelist> | 44 | </variablelist> |
diff --git a/Documentation/DocBook/v4l/io.xml b/Documentation/DocBook/v4l/io.xml index d424886beda0..227e7ac45a06 100644 --- a/Documentation/DocBook/v4l/io.xml +++ b/Documentation/DocBook/v4l/io.xml | |||
| @@ -121,18 +121,22 @@ mapped.</para> | |||
| 121 | <para>Before applications can access the buffers they must map | 121 | <para>Before applications can access the buffers they must map |
| 122 | them into their address space with the &func-mmap; function. The | 122 | them into their address space with the &func-mmap; function. The |
| 123 | location of the buffers in device memory can be determined with the | 123 | location of the buffers in device memory can be determined with the |
| 124 | &VIDIOC-QUERYBUF; ioctl. The <structfield>m.offset</structfield> and | 124 | &VIDIOC-QUERYBUF; ioctl. In the single-planar API case, the |
| 125 | <structfield>length</structfield> returned in a &v4l2-buffer; are | 125 | <structfield>m.offset</structfield> and <structfield>length</structfield> |
| 126 | passed as sixth and second parameter to the | 126 | returned in a &v4l2-buffer; are passed as sixth and second parameter to the |
| 127 | <function>mmap()</function> function. The offset and length values | 127 | <function>mmap()</function> function. When using the multi-planar API, |
| 128 | must not be modified. Remember the buffers are allocated in physical | 128 | struct &v4l2-buffer; contains an array of &v4l2-plane; structures, each |
| 129 | memory, as opposed to virtual memory which can be swapped out to disk. | 129 | containing its own <structfield>m.offset</structfield> and |
| 130 | Applications should free the buffers as soon as possible with the | 130 | <structfield>length</structfield>. When using the multi-planar API, every |
| 131 | &func-munmap; function.</para> | 131 | plane of every buffer has to be mapped separately, so the number of |
| 132 | calls to &func-mmap; should be equal to number of buffers times number of | ||
| 133 | planes in each buffer. The offset and length values must not be modified. | ||
| 134 | Remember, the buffers are allocated in physical memory, as opposed to virtual | ||
| 135 | memory, which can be swapped out to disk. Applications should free the buffers | ||
| 136 | as soon as possible with the &func-munmap; function.</para> | ||
| 132 | 137 | ||
| 133 | <example> | 138 | <example> |
| 134 | <title>Mapping buffers</title> | 139 | <title>Mapping buffers in the single-planar API</title> |
| 135 | |||
| 136 | <programlisting> | 140 | <programlisting> |
| 137 | &v4l2-requestbuffers; reqbuf; | 141 | &v4l2-requestbuffers; reqbuf; |
| 138 | struct { | 142 | struct { |
| @@ -141,63 +145,145 @@ struct { | |||
| 141 | } *buffers; | 145 | } *buffers; |
| 142 | unsigned int i; | 146 | unsigned int i; |
| 143 | 147 | ||
| 144 | memset (&reqbuf, 0, sizeof (reqbuf)); | 148 | memset(&reqbuf, 0, sizeof(reqbuf)); |
| 145 | reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; | 149 | reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE; |
| 146 | reqbuf.memory = V4L2_MEMORY_MMAP; | 150 | reqbuf.memory = V4L2_MEMORY_MMAP; |
| 147 | reqbuf.count = 20; | 151 | reqbuf.count = 20; |
| 148 | 152 | ||
| 149 | if (-1 == ioctl (fd, &VIDIOC-REQBUFS;, &reqbuf)) { | 153 | if (-1 == ioctl (fd, &VIDIOC-REQBUFS;, &reqbuf)) { |
| 150 | if (errno == EINVAL) | 154 | if (errno == EINVAL) |
| 151 | printf ("Video capturing or mmap-streaming is not supported\n"); | 155 | printf("Video capturing or mmap-streaming is not supported\n"); |
| 152 | else | 156 | else |
| 153 | perror ("VIDIOC_REQBUFS"); | 157 | perror("VIDIOC_REQBUFS"); |
| 154 | 158 | ||
| 155 | exit (EXIT_FAILURE); | 159 | exit(EXIT_FAILURE); |
| 156 | } | 160 | } |
| 157 | 161 | ||
| 158 | /* We want at least five buffers. */ | 162 | /* We want at least five buffers. */ |
| 159 | 163 | ||
| 160 | if (reqbuf.count < 5) { | 164 | if (reqbuf.count < 5) { |
| 161 | /* You may need to free the buffers here. */ | 165 | /* You may need to free the buffers here. */ |
| 162 | printf ("Not enough buffer memory\n"); | 166 | printf("Not enough buffer memory\n"); |
| 163 | exit (EXIT_FAILURE); | 167 | exit(EXIT_FAILURE); |
| 164 | } | 168 | } |
| 165 | 169 | ||
| 166 | buffers = calloc (reqbuf.count, sizeof (*buffers)); | 170 | buffers = calloc(reqbuf.count, sizeof(*buffers)); |
| 167 | assert (buffers != NULL); | 171 | assert(buffers != NULL); |
| 168 | 172 | ||
| 169 | for (i = 0; i < reqbuf.count; i++) { | 173 | for (i = 0; i < reqbuf.count; i++) { |
| 170 | &v4l2-buffer; buffer; | 174 | &v4l2-buffer; buffer; |
| 171 | 175 | ||
| 172 | memset (&buffer, 0, sizeof (buffer)); | 176 | memset(&buffer, 0, sizeof(buffer)); |
| 173 | buffer.type = reqbuf.type; | 177 | buffer.type = reqbuf.type; |
| 174 | buffer.memory = V4L2_MEMORY_MMAP; | 178 | buffer.memory = V4L2_MEMORY_MMAP; |
| 175 | buffer.index = i; | 179 | buffer.index = i; |
| 176 | 180 | ||
| 177 | if (-1 == ioctl (fd, &VIDIOC-QUERYBUF;, &buffer)) { | 181 | if (-1 == ioctl (fd, &VIDIOC-QUERYBUF;, &buffer)) { |
| 178 | perror ("VIDIOC_QUERYBUF"); | 182 | perror("VIDIOC_QUERYBUF"); |
| 179 | exit (EXIT_FAILURE); | 183 | exit(EXIT_FAILURE); |
| 180 | } | 184 | } |
| 181 | 185 | ||
| 182 | buffers[i].length = buffer.length; /* remember for munmap() */ | 186 | buffers[i].length = buffer.length; /* remember for munmap() */ |
| 183 | 187 | ||
| 184 | buffers[i].start = mmap (NULL, buffer.length, | 188 | buffers[i].start = mmap(NULL, buffer.length, |
| 185 | PROT_READ | PROT_WRITE, /* recommended */ | 189 | PROT_READ | PROT_WRITE, /* recommended */ |
| 186 | MAP_SHARED, /* recommended */ | 190 | MAP_SHARED, /* recommended */ |
| 187 | fd, buffer.m.offset); | 191 | fd, buffer.m.offset); |
| 188 | 192 | ||
| 189 | if (MAP_FAILED == buffers[i].start) { | 193 | if (MAP_FAILED == buffers[i].start) { |
| 190 | /* If you do not exit here you should unmap() and free() | 194 | /* If you do not exit here you should unmap() and free() |
| 191 | the buffers mapped so far. */ | 195 | the buffers mapped so far. */ |
| 192 | perror ("mmap"); | 196 | perror("mmap"); |
| 193 | exit (EXIT_FAILURE); | 197 | exit(EXIT_FAILURE); |
| 198 | } | ||
| 199 | } | ||
| 200 | |||
| 201 | /* Cleanup. */ | ||
| 202 | |||
| 203 | for (i = 0; i < reqbuf.count; i++) | ||
| 204 | munmap(buffers[i].start, buffers[i].length); | ||
| 205 | </programlisting> | ||
| 206 | </example> | ||
| 207 | |||
| 208 | <example> | ||
| 209 | <title>Mapping buffers in the multi-planar API</title> | ||
| 210 | <programlisting> | ||
| 211 | &v4l2-requestbuffers; reqbuf; | ||
| 212 | /* Our current format uses 3 planes per buffer */ | ||
| 213 | #define FMT_NUM_PLANES = 3; | ||
| 214 | |||
| 215 | struct { | ||
| 216 | void *start[FMT_NUM_PLANES]; | ||
| 217 | size_t length[FMT_NUM_PLANES]; | ||
| 218 | } *buffers; | ||
| 219 | unsigned int i, j; | ||
| 220 | |||
| 221 | memset(&reqbuf, 0, sizeof(reqbuf)); | ||
| 222 | reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE; | ||
| 223 | reqbuf.memory = V4L2_MEMORY_MMAP; | ||
| 224 | reqbuf.count = 20; | ||
| 225 | |||
| 226 | if (ioctl(fd, &VIDIOC-REQBUFS;, &reqbuf) < 0) { | ||
| 227 | if (errno == EINVAL) | ||
| 228 | printf("Video capturing or mmap-streaming is not supported\n"); | ||
| 229 | else | ||
| 230 | perror("VIDIOC_REQBUFS"); | ||
| 231 | |||
| 232 | exit(EXIT_FAILURE); | ||
| 233 | } | ||
| 234 | |||
| 235 | /* We want at least five buffers. */ | ||
| 236 | |||
| 237 | if (reqbuf.count < 5) { | ||
| 238 | /* You may need to free the buffers here. */ | ||
| 239 | printf("Not enough buffer memory\n"); | ||
| 240 | exit(EXIT_FAILURE); | ||
| 241 | } | ||
| 242 | |||
| 243 | buffers = calloc(reqbuf.count, sizeof(*buffers)); | ||
| 244 | assert(buffers != NULL); | ||
| 245 | |||
| 246 | for (i = 0; i < reqbuf.count; i++) { | ||
| 247 | &v4l2-buffer; buffer; | ||
| 248 | &v4l2-plane; planes[FMT_NUM_PLANES]; | ||
| 249 | |||
| 250 | memset(&buffer, 0, sizeof(buffer)); | ||
| 251 | buffer.type = reqbuf.type; | ||
| 252 | buffer.memory = V4L2_MEMORY_MMAP; | ||
| 253 | buffer.index = i; | ||
| 254 | /* length in struct v4l2_buffer in multi-planar API stores the size | ||
| 255 | * of planes array. */ | ||
| 256 | buffer.length = FMT_NUM_PLANES; | ||
| 257 | buffer.m.planes = planes; | ||
| 258 | |||
| 259 | if (ioctl(fd, &VIDIOC-QUERYBUF;, &buffer) < 0) { | ||
| 260 | perror("VIDIOC_QUERYBUF"); | ||
| 261 | exit(EXIT_FAILURE); | ||
| 262 | } | ||
| 263 | |||
| 264 | /* Every plane has to be mapped separately */ | ||
| 265 | for (j = 0; j < FMT_NUM_PLANES; j++) { | ||
| 266 | buffers[i].length[j] = buffer.m.planes[j].length; /* remember for munmap() */ | ||
| 267 | |||
| 268 | buffers[i].start[j] = mmap(NULL, buffer.m.planes[j].length, | ||
| 269 | PROT_READ | PROT_WRITE, /* recommended */ | ||
| 270 | MAP_SHARED, /* recommended */ | ||
| 271 | fd, buffer.m.planes[j].m.offset); | ||
| 272 | |||
| 273 | if (MAP_FAILED == buffers[i].start[j]) { | ||
| 274 | /* If you do not exit here you should unmap() and free() | ||
| 275 | the buffers and planes mapped so far. */ | ||
| 276 | perror("mmap"); | ||
| 277 | exit(EXIT_FAILURE); | ||
| 278 | } | ||
| 194 | } | 279 | } |
| 195 | } | 280 | } |
| 196 | 281 | ||
| 197 | /* Cleanup. */ | 282 | /* Cleanup. */ |
| 198 | 283 | ||
| 199 | for (i = 0; i < reqbuf.count; i++) | 284 | for (i = 0; i < reqbuf.count; i++) |
| 200 | munmap (buffers[i].start, buffers[i].length); | 285 | for (j = 0; j < FMT_NUM_PLANES; j++) |
| 286 | munmap(buffers[i].start[j], buffers[i].length[j]); | ||
| 201 | </programlisting> | 287 | </programlisting> |
| 202 | </example> | 288 | </example> |
| 203 | 289 | ||
| @@ -286,13 +372,13 @@ pointer method (not only memory mapping) is supported must be | |||
| 286 | determined by calling the &VIDIOC-REQBUFS; ioctl.</para> | 372 | determined by calling the &VIDIOC-REQBUFS; ioctl.</para> |
| 287 | 373 | ||
| 288 | <para>This I/O method combines advantages of the read/write and | 374 | <para>This I/O method combines advantages of the read/write and |
| 289 | memory mapping methods. Buffers are allocated by the application | 375 | memory mapping methods. Buffers (planes) are allocated by the application |
| 290 | itself, and can reside for example in virtual or shared memory. Only | 376 | itself, and can reside for example in virtual or shared memory. Only |
| 291 | pointers to data are exchanged, these pointers and meta-information | 377 | pointers to data are exchanged, these pointers and meta-information |
| 292 | are passed in &v4l2-buffer;. The driver must be switched | 378 | are passed in &v4l2-buffer; (or in &v4l2-plane; in the multi-planar API case). |
| 293 | into user pointer I/O mode by calling the &VIDIOC-REQBUFS; with the | 379 | The driver must be switched into user pointer I/O mode by calling the |
| 294 | desired buffer type. No buffers are allocated beforehands, | 380 | &VIDIOC-REQBUFS; with the desired buffer type. No buffers (planes) are allocated |
| 295 | consequently they are not indexed and cannot be queried like mapped | 381 | beforehand, consequently they are not indexed and cannot be queried like mapped |
| 296 | buffers with the <constant>VIDIOC_QUERYBUF</constant> ioctl.</para> | 382 | buffers with the <constant>VIDIOC_QUERYBUF</constant> ioctl.</para> |
| 297 | 383 | ||
| 298 | <example> | 384 | <example> |
| @@ -316,7 +402,7 @@ if (ioctl (fd, &VIDIOC-REQBUFS;, &reqbuf) == -1) { | |||
| 316 | </programlisting> | 402 | </programlisting> |
| 317 | </example> | 403 | </example> |
| 318 | 404 | ||
| 319 | <para>Buffer addresses and sizes are passed on the fly with the | 405 | <para>Buffer (plane) addresses and sizes are passed on the fly with the |
| 320 | &VIDIOC-QBUF; ioctl. Although buffers are commonly cycled, | 406 | &VIDIOC-QBUF; ioctl. Although buffers are commonly cycled, |
| 321 | applications can pass different addresses and sizes at each | 407 | applications can pass different addresses and sizes at each |
| 322 | <constant>VIDIOC_QBUF</constant> call. If required by the hardware the | 408 | <constant>VIDIOC_QBUF</constant> call. If required by the hardware the |
| @@ -396,11 +482,18 @@ rest should be evident.</para> | |||
| 396 | <title>Buffers</title> | 482 | <title>Buffers</title> |
| 397 | 483 | ||
| 398 | <para>A buffer contains data exchanged by application and | 484 | <para>A buffer contains data exchanged by application and |
| 399 | driver using one of the Streaming I/O methods. Only pointers to | 485 | driver using one of the Streaming I/O methods. In the multi-planar API, the |
| 400 | buffers are exchanged, the data itself is not copied. These pointers, | 486 | data is held in planes, while the buffer structure acts as a container |
| 401 | together with meta-information like timestamps or field parity, are | 487 | for the planes. Only pointers to buffers (planes) are exchanged, the data |
| 402 | stored in a struct <structname>v4l2_buffer</structname>, argument to | 488 | itself is not copied. These pointers, together with meta-information like |
| 403 | the &VIDIOC-QUERYBUF;, &VIDIOC-QBUF; and &VIDIOC-DQBUF; ioctl.</para> | 489 | timestamps or field parity, are stored in a struct |
| 490 | <structname>v4l2_buffer</structname>, argument to | ||
| 491 | the &VIDIOC-QUERYBUF;, &VIDIOC-QBUF; and &VIDIOC-DQBUF; ioctl. | ||
| 492 | In the multi-planar API, some plane-specific members of struct | ||
| 493 | <structname>v4l2_buffer</structname>, such as pointers and sizes for each | ||
| 494 | plane, are stored in struct <structname>v4l2_plane</structname> instead. | ||
| 495 | In that case, struct <structname>v4l2_buffer</structname> contains an array of | ||
| 496 | plane structures.</para> | ||
| 404 | 497 | ||
| 405 | <para>Nominally timestamps refer to the first data byte transmitted. | 498 | <para>Nominally timestamps refer to the first data byte transmitted. |
| 406 | In practice however the wide range of hardware covered by the V4L2 API | 499 | 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> | |||
| 551 | <entry></entry> | 644 | <entry></entry> |
| 552 | <entry>__u32</entry> | 645 | <entry>__u32</entry> |
| 553 | <entry><structfield>offset</structfield></entry> | 646 | <entry><structfield>offset</structfield></entry> |
| 554 | <entry>When <structfield>memory</structfield> is | 647 | <entry>For the single-planar API and when |
| 555 | <constant>V4L2_MEMORY_MMAP</constant> this is the offset of the buffer | 648 | <structfield>memory</structfield> is <constant>V4L2_MEMORY_MMAP</constant> this |
| 556 | from the start of the device memory. The value is returned by the | 649 | is the offset of the buffer from the start of the device memory. The value is |
| 557 | driver and apart of serving as parameter to the &func-mmap; function | 650 | returned by the driver and apart of serving as parameter to the &func-mmap; |
| 558 | not useful for applications. See <xref linkend="mmap" /> for details.</entry> | 651 | function not useful for applications. See <xref linkend="mmap" /> for details |
| 652 | </entry> | ||
| 559 | </row> | 653 | </row> |
| 560 | <row> | 654 | <row> |
| 561 | <entry></entry> | 655 | <entry></entry> |
| 562 | <entry>unsigned long</entry> | 656 | <entry>unsigned long</entry> |
| 563 | <entry><structfield>userptr</structfield></entry> | 657 | <entry><structfield>userptr</structfield></entry> |
| 564 | <entry>When <structfield>memory</structfield> is | 658 | <entry>For the single-planar API and when |
| 565 | <constant>V4L2_MEMORY_USERPTR</constant> this is a pointer to the | 659 | <structfield>memory</structfield> is <constant>V4L2_MEMORY_USERPTR</constant> |
| 566 | buffer (casted to unsigned long type) in virtual memory, set by the | 660 | this is a pointer to the buffer (casted to unsigned long type) in virtual |
| 567 | application. See <xref linkend="userp" /> for details.</entry> | 661 | memory, set by the application. See <xref linkend="userp" /> for details. |
| 662 | </entry> | ||
| 663 | </row> | ||
| 664 | <row> | ||
| 665 | <entry></entry> | ||
| 666 | <entry>struct v4l2_plane</entry> | ||
| 667 | <entry><structfield>*planes</structfield></entry> | ||
| 668 | <entry>When using the multi-planar API, contains a userspace pointer | ||
| 669 | to an array of &v4l2-plane;. The size of the array should be put | ||
| 670 | in the <structfield>length</structfield> field of this | ||
| 671 | <structname>v4l2_buffer</structname> structure.</entry> | ||
| 568 | </row> | 672 | </row> |
| 569 | <row> | 673 | <row> |
| 570 | <entry>__u32</entry> | 674 | <entry>__u32</entry> |
| 571 | <entry><structfield>length</structfield></entry> | 675 | <entry><structfield>length</structfield></entry> |
| 572 | <entry></entry> | 676 | <entry></entry> |
| 573 | <entry>Size of the buffer (not the payload) in bytes.</entry> | 677 | <entry>Size of the buffer (not the payload) in bytes for the |
| 678 | single-planar API. For the multi-planar API should contain the | ||
| 679 | number of elements in the <structfield>planes</structfield> array. | ||
| 680 | </entry> | ||
| 574 | </row> | 681 | </row> |
| 575 | <row> | 682 | <row> |
| 576 | <entry>__u32</entry> | 683 | <entry>__u32</entry> |
| @@ -596,6 +703,66 @@ should set this to 0.</entry> | |||
| 596 | </tgroup> | 703 | </tgroup> |
| 597 | </table> | 704 | </table> |
| 598 | 705 | ||
| 706 | <table frame="none" pgwide="1" id="v4l2-plane"> | ||
| 707 | <title>struct <structname>v4l2_plane</structname></title> | ||
| 708 | <tgroup cols="4"> | ||
| 709 | &cs-ustr; | ||
| 710 | <tbody valign="top"> | ||
| 711 | <row> | ||
| 712 | <entry>__u32</entry> | ||
| 713 | <entry><structfield>bytesused</structfield></entry> | ||
| 714 | <entry></entry> | ||
| 715 | <entry>The number of bytes occupied by data in the plane | ||
| 716 | (its payload).</entry> | ||
| 717 | </row> | ||
| 718 | <row> | ||
| 719 | <entry>__u32</entry> | ||
| 720 | <entry><structfield>length</structfield></entry> | ||
| 721 | <entry></entry> | ||
| 722 | <entry>Size in bytes of the plane (not its payload).</entry> | ||
| 723 | </row> | ||
| 724 | <row> | ||
| 725 | <entry>union</entry> | ||
| 726 | <entry><structfield>m</structfield></entry> | ||
| 727 | <entry></entry> | ||
| 728 | <entry></entry> | ||
| 729 | </row> | ||
| 730 | <row> | ||
| 731 | <entry></entry> | ||
| 732 | <entry>__u32</entry> | ||
| 733 | <entry><structfield>mem_offset</structfield></entry> | ||
| 734 | <entry>When the memory type in the containing &v4l2-buffer; is | ||
| 735 | <constant>V4L2_MEMORY_MMAP</constant>, this is the value that | ||
| 736 | should be passed to &func-mmap;, similar to the | ||
| 737 | <structfield>offset</structfield> field in &v4l2-buffer;.</entry> | ||
| 738 | </row> | ||
| 739 | <row> | ||
| 740 | <entry></entry> | ||
| 741 | <entry>__unsigned long</entry> | ||
| 742 | <entry><structfield>userptr</structfield></entry> | ||
| 743 | <entry>When the memory type in the containing &v4l2-buffer; is | ||
| 744 | <constant>V4L2_MEMORY_USERPTR</constant>, this is a userspace | ||
| 745 | pointer to the memory allocated for this plane by an application. | ||
| 746 | </entry> | ||
| 747 | </row> | ||
| 748 | <row> | ||
| 749 | <entry>__u32</entry> | ||
| 750 | <entry><structfield>data_offset</structfield></entry> | ||
| 751 | <entry></entry> | ||
| 752 | <entry>Offset in bytes to video data in the plane, if applicable. | ||
| 753 | </entry> | ||
| 754 | </row> | ||
| 755 | <row> | ||
| 756 | <entry>__u32</entry> | ||
| 757 | <entry><structfield>reserved[11]</structfield></entry> | ||
| 758 | <entry></entry> | ||
| 759 | <entry>Reserved for future use. Should be zeroed by an | ||
| 760 | application.</entry> | ||
| 761 | </row> | ||
| 762 | </tbody> | ||
| 763 | </tgroup> | ||
| 764 | </table> | ||
| 765 | |||
| 599 | <table frame="none" pgwide="1" id="v4l2-buf-type"> | 766 | <table frame="none" pgwide="1" id="v4l2-buf-type"> |
| 600 | <title>enum v4l2_buf_type</title> | 767 | <title>enum v4l2_buf_type</title> |
| 601 | <tgroup cols="3"> | 768 | <tgroup cols="3"> |
| @@ -604,13 +771,27 @@ should set this to 0.</entry> | |||
| 604 | <row> | 771 | <row> |
| 605 | <entry><constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant></entry> | 772 | <entry><constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant></entry> |
| 606 | <entry>1</entry> | 773 | <entry>1</entry> |
| 607 | <entry>Buffer of a video capture stream, see <xref | 774 | <entry>Buffer of a single-planar video capture stream, see <xref |
| 775 | linkend="capture" />.</entry> | ||
| 776 | </row> | ||
| 777 | <row> | ||
| 778 | <entry><constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant> | ||
| 779 | </entry> | ||
| 780 | <entry>9</entry> | ||
| 781 | <entry>Buffer of a multi-planar video capture stream, see <xref | ||
| 608 | linkend="capture" />.</entry> | 782 | linkend="capture" />.</entry> |
| 609 | </row> | 783 | </row> |
| 610 | <row> | 784 | <row> |
| 611 | <entry><constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant></entry> | 785 | <entry><constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant></entry> |
| 612 | <entry>2</entry> | 786 | <entry>2</entry> |
| 613 | <entry>Buffer of a video output stream, see <xref | 787 | <entry>Buffer of a single-planar video output stream, see <xref |
| 788 | linkend="output" />.</entry> | ||
| 789 | </row> | ||
| 790 | <row> | ||
| 791 | <entry><constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant> | ||
| 792 | </entry> | ||
| 793 | <entry>10</entry> | ||
| 794 | <entry>Buffer of a multi-planar video output stream, see <xref | ||
| 614 | linkend="output" />.</entry> | 795 | linkend="output" />.</entry> |
| 615 | </row> | 796 | </row> |
| 616 | <row> | 797 | <row> |
diff --git a/Documentation/DocBook/v4l/libv4l.xml b/Documentation/DocBook/v4l/libv4l.xml index c14fc3db2a81..3cb10ec51929 100644 --- a/Documentation/DocBook/v4l/libv4l.xml +++ b/Documentation/DocBook/v4l/libv4l.xml | |||
| @@ -140,7 +140,7 @@ and is not locked sets the cid to the scaled value. | |||
| 140 | <para>int v4l2_get_control(int fd, int cid) - | 140 | <para>int v4l2_get_control(int fd, int cid) - |
| 141 | This function returns a value of 0 - 65535, scaled to from the actual range | 141 | This function returns a value of 0 - 65535, scaled to from the actual range |
| 142 | of the given v4l control id. when the cid does not exist, could not be | 142 | of the given v4l control id. when the cid does not exist, could not be |
| 143 | accessed for some reason, or some error occured 0 is returned. | 143 | accessed for some reason, or some error occurred 0 is returned. |
| 144 | </para></listitem> | 144 | </para></listitem> |
| 145 | </itemizedlist> | 145 | </itemizedlist> |
| 146 | </section> | 146 | </section> |
diff --git a/Documentation/DocBook/v4l/lirc_device_interface.xml b/Documentation/DocBook/v4l/lirc_device_interface.xml index 68134c0ab4d1..0e0453f39e73 100644 --- a/Documentation/DocBook/v4l/lirc_device_interface.xml +++ b/Documentation/DocBook/v4l/lirc_device_interface.xml | |||
| @@ -45,7 +45,7 @@ describing an IR signal are read from the chardev.</para> | |||
| 45 | <para>The data written to the chardev is a pulse/space sequence of integer | 45 | <para>The data written to the chardev is a pulse/space sequence of integer |
| 46 | values. Pulses and spaces are only marked implicitly by their position. The | 46 | values. Pulses and spaces are only marked implicitly by their position. The |
| 47 | data must start and end with a pulse, therefore, the data must always include | 47 | data must start and end with a pulse, therefore, the data must always include |
| 48 | an unevent number of samples. The write function must block until the data has | 48 | an uneven number of samples. The write function must block until the data has |
| 49 | been transmitted by the hardware.</para> | 49 | been transmitted by the hardware.</para> |
| 50 | </section> | 50 | </section> |
| 51 | 51 | ||
diff --git a/Documentation/DocBook/v4l/media-controller.xml b/Documentation/DocBook/v4l/media-controller.xml new file mode 100644 index 000000000000..2dc25e1d4089 --- /dev/null +++ b/Documentation/DocBook/v4l/media-controller.xml | |||
| @@ -0,0 +1,89 @@ | |||
| 1 | <partinfo> | ||
| 2 | <authorgroup> | ||
| 3 | <author> | ||
| 4 | <firstname>Laurent</firstname> | ||
| 5 | <surname>Pinchart</surname> | ||
| 6 | <affiliation><address><email>laurent.pinchart@ideasonboard.com</email></address></affiliation> | ||
| 7 | <contrib>Initial version.</contrib> | ||
| 8 | </author> | ||
| 9 | </authorgroup> | ||
| 10 | <copyright> | ||
| 11 | <year>2010</year> | ||
| 12 | <holder>Laurent Pinchart</holder> | ||
| 13 | </copyright> | ||
| 14 | |||
| 15 | <revhistory> | ||
| 16 | <!-- Put document revisions here, newest first. --> | ||
| 17 | <revision> | ||
| 18 | <revnumber>1.0.0</revnumber> | ||
| 19 | <date>2010-11-10</date> | ||
| 20 | <authorinitials>lp</authorinitials> | ||
| 21 | <revremark>Initial revision</revremark> | ||
| 22 | </revision> | ||
| 23 | </revhistory> | ||
| 24 | </partinfo> | ||
| 25 | |||
| 26 | <title>Media Controller API</title> | ||
| 27 | |||
| 28 | <chapter id="media_controller"> | ||
| 29 | <title>Media Controller</title> | ||
| 30 | |||
| 31 | <section id="media-controller-intro"> | ||
| 32 | <title>Introduction</title> | ||
| 33 | <para>Media devices increasingly handle multiple related functions. Many USB | ||
| 34 | cameras include microphones, video capture hardware can also output video, | ||
| 35 | or SoC camera interfaces also perform memory-to-memory operations similar to | ||
| 36 | video codecs.</para> | ||
| 37 | <para>Independent functions, even when implemented in the same hardware, can | ||
| 38 | be modelled as separate devices. A USB camera with a microphone will be | ||
| 39 | presented to userspace applications as V4L2 and ALSA capture devices. The | ||
| 40 | devices' relationships (when using a webcam, end-users shouldn't have to | ||
| 41 | manually select the associated USB microphone), while not made available | ||
| 42 | directly to applications by the drivers, can usually be retrieved from | ||
| 43 | sysfs.</para> | ||
| 44 | <para>With more and more advanced SoC devices being introduced, the current | ||
| 45 | approach will not scale. Device topologies are getting increasingly complex | ||
| 46 | and can't always be represented by a tree structure. Hardware blocks are | ||
| 47 | shared between different functions, creating dependencies between seemingly | ||
| 48 | unrelated devices.</para> | ||
| 49 | <para>Kernel abstraction APIs such as V4L2 and ALSA provide means for | ||
| 50 | applications to access hardware parameters. As newer hardware expose an | ||
| 51 | increasingly high number of those parameters, drivers need to guess what | ||
| 52 | applications really require based on limited information, thereby | ||
| 53 | implementing policies that belong to userspace.</para> | ||
| 54 | <para>The media controller API aims at solving those problems.</para> | ||
| 55 | </section> | ||
| 56 | |||
| 57 | <section id="media-controller-model"> | ||
| 58 | <title>Media device model</title> | ||
| 59 | <para>Discovering a device internal topology, and configuring it at runtime, | ||
| 60 | is one of the goals of the media controller API. To achieve this, hardware | ||
| 61 | devices are modelled as an oriented graph of building blocks called entities | ||
| 62 | connected through pads.</para> | ||
| 63 | <para>An entity is a basic media hardware or software building block. It can | ||
| 64 | correspond to a large variety of logical blocks such as physical hardware | ||
| 65 | devices (CMOS sensor for instance), logical hardware devices (a building | ||
| 66 | block in a System-on-Chip image processing pipeline), DMA channels or | ||
| 67 | physical connectors.</para> | ||
| 68 | <para>A pad is a connection endpoint through which an entity can interact | ||
| 69 | with other entities. Data (not restricted to video) produced by an entity | ||
| 70 | flows from the entity's output to one or more entity inputs. Pads should not | ||
| 71 | be confused with physical pins at chip boundaries.</para> | ||
| 72 | <para>A link is a point-to-point oriented connection between two pads, | ||
| 73 | either on the same entity or on different entities. Data flows from a source | ||
| 74 | pad to a sink pad.</para> | ||
| 75 | </section> | ||
| 76 | </chapter> | ||
| 77 | |||
| 78 | <appendix id="media-user-func"> | ||
| 79 | <title>Function Reference</title> | ||
| 80 | <!-- Keep this alphabetically sorted. --> | ||
| 81 | &sub-media-open; | ||
| 82 | &sub-media-close; | ||
| 83 | &sub-media-ioctl; | ||
| 84 | <!-- All ioctls go here. --> | ||
| 85 | &sub-media-ioc-device-info; | ||
| 86 | &sub-media-ioc-enum-entities; | ||
| 87 | &sub-media-ioc-enum-links; | ||
| 88 | &sub-media-ioc-setup-link; | ||
| 89 | </appendix> | ||
diff --git a/Documentation/DocBook/v4l/media-func-close.xml b/Documentation/DocBook/v4l/media-func-close.xml new file mode 100644 index 000000000000..be149c802aeb --- /dev/null +++ b/Documentation/DocBook/v4l/media-func-close.xml | |||
| @@ -0,0 +1,59 @@ | |||
| 1 | <refentry id="media-func-close"> | ||
| 2 | <refmeta> | ||
| 3 | <refentrytitle>media close()</refentrytitle> | ||
| 4 | &manvol; | ||
| 5 | </refmeta> | ||
| 6 | |||
| 7 | <refnamediv> | ||
| 8 | <refname>media-close</refname> | ||
| 9 | <refpurpose>Close a media device</refpurpose> | ||
| 10 | </refnamediv> | ||
| 11 | |||
| 12 | <refsynopsisdiv> | ||
| 13 | <funcsynopsis> | ||
| 14 | <funcsynopsisinfo>#include <unistd.h></funcsynopsisinfo> | ||
| 15 | <funcprototype> | ||
| 16 | <funcdef>int <function>close</function></funcdef> | ||
| 17 | <paramdef>int <parameter>fd</parameter></paramdef> | ||
| 18 | </funcprototype> | ||
| 19 | </funcsynopsis> | ||
| 20 | </refsynopsisdiv> | ||
| 21 | |||
| 22 | <refsect1> | ||
| 23 | <title>Arguments</title> | ||
| 24 | |||
| 25 | <variablelist> | ||
| 26 | <varlistentry> | ||
| 27 | <term><parameter>fd</parameter></term> | ||
| 28 | <listitem> | ||
| 29 | <para>&fd;</para> | ||
| 30 | </listitem> | ||
| 31 | </varlistentry> | ||
| 32 | </variablelist> | ||
| 33 | </refsect1> | ||
| 34 | |||
| 35 | <refsect1> | ||
| 36 | <title>Description</title> | ||
| 37 | |||
| 38 | <para>Closes the media device. Resources associated with the file descriptor | ||
| 39 | are freed. The device configuration remain unchanged.</para> | ||
| 40 | </refsect1> | ||
| 41 | |||
| 42 | <refsect1> | ||
| 43 | <title>Return Value</title> | ||
| 44 | |||
| 45 | <para><function>close</function> returns 0 on success. On error, -1 is | ||
| 46 | returned, and <varname>errno</varname> is set appropriately. Possible error | ||
| 47 | codes are:</para> | ||
| 48 | |||
| 49 | <variablelist> | ||
| 50 | <varlistentry> | ||
| 51 | <term><errorcode>EBADF</errorcode></term> | ||
| 52 | <listitem> | ||
| 53 | <para><parameter>fd</parameter> is not a valid open file descriptor. | ||
| 54 | </para> | ||
| 55 | </listitem> | ||
| 56 | </varlistentry> | ||
| 57 | </variablelist> | ||
| 58 | </refsect1> | ||
| 59 | </refentry> | ||
diff --git a/Documentation/DocBook/v4l/media-func-ioctl.xml b/Documentation/DocBook/v4l/media-func-ioctl.xml new file mode 100644 index 000000000000..bda8604de15c --- /dev/null +++ b/Documentation/DocBook/v4l/media-func-ioctl.xml | |||
| @@ -0,0 +1,116 @@ | |||
| 1 | <refentry id="media-func-ioctl"> | ||
| 2 | <refmeta> | ||
| 3 | <refentrytitle>media ioctl()</refentrytitle> | ||
| 4 | &manvol; | ||
| 5 | </refmeta> | ||
| 6 | |||
| 7 | <refnamediv> | ||
| 8 | <refname>media-ioctl</refname> | ||
| 9 | <refpurpose>Control a media device</refpurpose> | ||
| 10 | </refnamediv> | ||
| 11 | |||
| 12 | <refsynopsisdiv> | ||
| 13 | <funcsynopsis> | ||
| 14 | <funcsynopsisinfo>#include <sys/ioctl.h></funcsynopsisinfo> | ||
| 15 | <funcprototype> | ||
| 16 | <funcdef>int <function>ioctl</function></funcdef> | ||
| 17 | <paramdef>int <parameter>fd</parameter></paramdef> | ||
| 18 | <paramdef>int <parameter>request</parameter></paramdef> | ||
| 19 | <paramdef>void *<parameter>argp</parameter></paramdef> | ||
| 20 | </funcprototype> | ||
| 21 | </funcsynopsis> | ||
| 22 | </refsynopsisdiv> | ||
| 23 | |||
| 24 | <refsect1> | ||
| 25 | <title>Arguments</title> | ||
| 26 | |||
| 27 | <variablelist> | ||
| 28 | <varlistentry> | ||
| 29 | <term><parameter>fd</parameter></term> | ||
| 30 | <listitem> | ||
| 31 | <para>&fd;</para> | ||
| 32 | </listitem> | ||
| 33 | </varlistentry> | ||
| 34 | <varlistentry> | ||
| 35 | <term><parameter>request</parameter></term> | ||
| 36 | <listitem> | ||
| 37 | <para>Media ioctl request code as defined in the media.h header file, | ||
| 38 | for example MEDIA_IOC_SETUP_LINK.</para> | ||
| 39 | </listitem> | ||
| 40 | </varlistentry> | ||
| 41 | <varlistentry> | ||
| 42 | <term><parameter>argp</parameter></term> | ||
| 43 | <listitem> | ||
| 44 | <para>Pointer to a request-specific structure.</para> | ||
| 45 | </listitem> | ||
| 46 | </varlistentry> | ||
| 47 | </variablelist> | ||
| 48 | </refsect1> | ||
| 49 | |||
| 50 | <refsect1> | ||
| 51 | <title>Description</title> | ||
| 52 | <para>The <function>ioctl()</function> function manipulates media device | ||
| 53 | parameters. The argument <parameter>fd</parameter> must be an open file | ||
| 54 | descriptor.</para> | ||
| 55 | <para>The ioctl <parameter>request</parameter> code specifies the media | ||
| 56 | function to be called. It has encoded in it whether the argument is an | ||
| 57 | input, output or read/write parameter, and the size of the argument | ||
| 58 | <parameter>argp</parameter> in bytes.</para> | ||
| 59 | <para>Macros and structures definitions specifying media ioctl requests and | ||
| 60 | their parameters are located in the media.h header file. All media ioctl | ||
| 61 | requests, their respective function and parameters are specified in | ||
| 62 | <xref linkend="media-user-func" />.</para> | ||
| 63 | </refsect1> | ||
| 64 | |||
| 65 | <refsect1> | ||
| 66 | <title>Return Value</title> | ||
| 67 | |||
| 68 | <para><function>ioctl()</function> returns <returnvalue>0</returnvalue> on | ||
| 69 | success. On failure, <returnvalue>-1</returnvalue> is returned, and the | ||
| 70 | <varname>errno</varname> variable is set appropriately. Generic error codes | ||
| 71 | are listed below, and request-specific error codes are listed in the | ||
| 72 | individual requests descriptions.</para> | ||
| 73 | <para>When an ioctl that takes an output or read/write parameter fails, | ||
| 74 | the parameter remains unmodified.</para> | ||
| 75 | |||
| 76 | <variablelist> | ||
| 77 | <varlistentry> | ||
| 78 | <term><errorcode>EBADF</errorcode></term> | ||
| 79 | <listitem> | ||
| 80 | <para><parameter>fd</parameter> is not a valid open file descriptor. | ||
| 81 | </para> | ||
| 82 | </listitem> | ||
| 83 | </varlistentry> | ||
| 84 | <varlistentry> | ||
| 85 | <term><errorcode>EFAULT</errorcode></term> | ||
| 86 | <listitem> | ||
| 87 | <para><parameter>argp</parameter> references an inaccessible memory | ||
| 88 | area.</para> | ||
| 89 | </listitem> | ||
| 90 | </varlistentry> | ||
| 91 | <varlistentry> | ||
| 92 | <term><errorcode>EINVAL</errorcode></term> | ||
| 93 | <listitem> | ||
| 94 | <para>The <parameter>request</parameter> or the data pointed to by | ||
| 95 | <parameter>argp</parameter> is not valid. This is a very common error | ||
| 96 | code, see the individual ioctl requests listed in | ||
| 97 | <xref linkend="media-user-func" /> for actual causes.</para> | ||
| 98 | </listitem> | ||
| 99 | </varlistentry> | ||
| 100 | <varlistentry> | ||
| 101 | <term><errorcode>ENOMEM</errorcode></term> | ||
| 102 | <listitem> | ||
| 103 | <para>Insufficient kernel memory was available to complete the | ||
| 104 | request.</para> | ||
| 105 | </listitem> | ||
| 106 | </varlistentry> | ||
| 107 | <varlistentry> | ||
| 108 | <term><errorcode>ENOTTY</errorcode></term> | ||
| 109 | <listitem> | ||
| 110 | <para><parameter>fd</parameter> is not associated with a character | ||
| 111 | special device.</para> | ||
| 112 | </listitem> | ||
| 113 | </varlistentry> | ||
| 114 | </variablelist> | ||
| 115 | </refsect1> | ||
| 116 | </refentry> | ||
diff --git a/Documentation/DocBook/v4l/media-func-open.xml b/Documentation/DocBook/v4l/media-func-open.xml new file mode 100644 index 000000000000..f7df034dc9ed --- /dev/null +++ b/Documentation/DocBook/v4l/media-func-open.xml | |||
| @@ -0,0 +1,94 @@ | |||
| 1 | <refentry id="media-func-open"> | ||
| 2 | <refmeta> | ||
| 3 | <refentrytitle>media open()</refentrytitle> | ||
| 4 | &manvol; | ||
| 5 | </refmeta> | ||
| 6 | |||
| 7 | <refnamediv> | ||
| 8 | <refname>media-open</refname> | ||
| 9 | <refpurpose>Open a media device</refpurpose> | ||
| 10 | </refnamediv> | ||
| 11 | |||
| 12 | <refsynopsisdiv> | ||
| 13 | <funcsynopsis> | ||
| 14 | <funcsynopsisinfo>#include <fcntl.h></funcsynopsisinfo> | ||
| 15 | <funcprototype> | ||
| 16 | <funcdef>int <function>open</function></funcdef> | ||
| 17 | <paramdef>const char *<parameter>device_name</parameter></paramdef> | ||
| 18 | <paramdef>int <parameter>flags</parameter></paramdef> | ||
| 19 | </funcprototype> | ||
| 20 | </funcsynopsis> | ||
| 21 | </refsynopsisdiv> | ||
| 22 | |||
| 23 | <refsect1> | ||
| 24 | <title>Arguments</title> | ||
| 25 | |||
| 26 | <variablelist> | ||
| 27 | <varlistentry> | ||
| 28 | <term><parameter>device_name</parameter></term> | ||
| 29 | <listitem> | ||
| 30 | <para>Device to be opened.</para> | ||
| 31 | </listitem> | ||
| 32 | </varlistentry> | ||
| 33 | <varlistentry> | ||
| 34 | <term><parameter>flags</parameter></term> | ||
| 35 | <listitem> | ||
| 36 | <para>Open flags. Access mode must be either <constant>O_RDONLY</constant> | ||
| 37 | or <constant>O_RDWR</constant>. Other flags have no effect.</para> | ||
| 38 | </listitem> | ||
| 39 | </varlistentry> | ||
| 40 | </variablelist> | ||
| 41 | </refsect1> | ||
| 42 | <refsect1> | ||
| 43 | <title>Description</title> | ||
| 44 | <para>To open a media device applications call <function>open()</function> | ||
| 45 | with the desired device name. The function has no side effects; the device | ||
| 46 | configuration remain unchanged.</para> | ||
| 47 | <para>When the device is opened in read-only mode, attemps to modify its | ||
| 48 | configuration will result in an error, and <varname>errno</varname> will be | ||
| 49 | set to <errorcode>EBADF</errorcode>.</para> | ||
| 50 | </refsect1> | ||
| 51 | <refsect1> | ||
| 52 | <title>Return Value</title> | ||
| 53 | |||
| 54 | <para><function>open</function> returns the new file descriptor on success. | ||
| 55 | On error, -1 is returned, and <varname>errno</varname> is set appropriately. | ||
| 56 | Possible error codes are:</para> | ||
| 57 | |||
| 58 | <variablelist> | ||
| 59 | <varlistentry> | ||
| 60 | <term><errorcode>EACCES</errorcode></term> | ||
| 61 | <listitem> | ||
| 62 | <para>The requested access to the file is not allowed.</para> | ||
| 63 | </listitem> | ||
| 64 | </varlistentry> | ||
| 65 | <varlistentry> | ||
| 66 | <term><errorcode>EMFILE</errorcode></term> | ||
| 67 | <listitem> | ||
| 68 | <para>The process already has the maximum number of files open. | ||
| 69 | </para> | ||
| 70 | </listitem> | ||
| 71 | </varlistentry> | ||
| 72 | <varlistentry> | ||
| 73 | <term><errorcode>ENFILE</errorcode></term> | ||
| 74 | <listitem> | ||
| 75 | <para>The system limit on the total number of open files has been | ||
| 76 | reached.</para> | ||
| 77 | </listitem> | ||
| 78 | </varlistentry> | ||
| 79 | <varlistentry> | ||
| 80 | <term><errorcode>ENOMEM</errorcode></term> | ||
| 81 | <listitem> | ||
| 82 | <para>Insufficient kernel memory was available.</para> | ||
| 83 | </listitem> | ||
| 84 | </varlistentry> | ||
| 85 | <varlistentry> | ||
| 86 | <term><errorcode>ENXIO</errorcode></term> | ||
| 87 | <listitem> | ||
| 88 | <para>No device corresponding to this device special file exists. | ||
| 89 | </para> | ||
| 90 | </listitem> | ||
| 91 | </varlistentry> | ||
| 92 | </variablelist> | ||
| 93 | </refsect1> | ||
| 94 | </refentry> | ||
diff --git a/Documentation/DocBook/v4l/media-ioc-device-info.xml b/Documentation/DocBook/v4l/media-ioc-device-info.xml new file mode 100644 index 000000000000..1f3237351bba --- /dev/null +++ b/Documentation/DocBook/v4l/media-ioc-device-info.xml | |||
| @@ -0,0 +1,133 @@ | |||
| 1 | <refentry id="media-ioc-device-info"> | ||
| 2 | <refmeta> | ||
| 3 | <refentrytitle>ioctl MEDIA_IOC_DEVICE_INFO</refentrytitle> | ||
| 4 | &manvol; | ||
| 5 | </refmeta> | ||
| 6 | |||
| 7 | <refnamediv> | ||
| 8 | <refname>MEDIA_IOC_DEVICE_INFO</refname> | ||
| 9 | <refpurpose>Query device information</refpurpose> | ||
| 10 | </refnamediv> | ||
| 11 | |||
| 12 | <refsynopsisdiv> | ||
| 13 | <funcsynopsis> | ||
| 14 | <funcprototype> | ||
| 15 | <funcdef>int <function>ioctl</function></funcdef> | ||
| 16 | <paramdef>int <parameter>fd</parameter></paramdef> | ||
| 17 | <paramdef>int <parameter>request</parameter></paramdef> | ||
| 18 | <paramdef>struct media_device_info *<parameter>argp</parameter></paramdef> | ||
| 19 | </funcprototype> | ||
| 20 | </funcsynopsis> | ||
| 21 | </refsynopsisdiv> | ||
| 22 | |||
| 23 | <refsect1> | ||
| 24 | <title>Arguments</title> | ||
| 25 | |||
| 26 | <variablelist> | ||
| 27 | <varlistentry> | ||
| 28 | <term><parameter>fd</parameter></term> | ||
| 29 | <listitem> | ||
| 30 | <para>File descriptor returned by | ||
| 31 | <link linkend='media-func-open'><function>open()</function></link>.</para> | ||
| 32 | </listitem> | ||
| 33 | </varlistentry> | ||
| 34 | <varlistentry> | ||
| 35 | <term><parameter>request</parameter></term> | ||
| 36 | <listitem> | ||
| 37 | <para>MEDIA_IOC_DEVICE_INFO</para> | ||
| 38 | </listitem> | ||
| 39 | </varlistentry> | ||
| 40 | <varlistentry> | ||
| 41 | <term><parameter>argp</parameter></term> | ||
| 42 | <listitem> | ||
| 43 | <para></para> | ||
| 44 | </listitem> | ||
| 45 | </varlistentry> | ||
| 46 | </variablelist> | ||
| 47 | </refsect1> | ||
| 48 | |||
| 49 | <refsect1> | ||
| 50 | <title>Description</title> | ||
| 51 | |||
| 52 | <para>All media devices must support the <constant>MEDIA_IOC_DEVICE_INFO</constant> | ||
| 53 | ioctl. To query device information, applications call the ioctl with a | ||
| 54 | pointer to a &media-device-info;. The driver fills the structure and returns | ||
| 55 | the information to the application. | ||
| 56 | The ioctl never fails.</para> | ||
| 57 | |||
| 58 | <table pgwide="1" frame="none" id="media-device-info"> | ||
| 59 | <title>struct <structname>media_device_info</structname></title> | ||
| 60 | <tgroup cols="3"> | ||
| 61 | &cs-str; | ||
| 62 | <tbody valign="top"> | ||
| 63 | <row> | ||
| 64 | <entry>char</entry> | ||
| 65 | <entry><structfield>driver</structfield>[16]</entry> | ||
| 66 | <entry><para>Name of the driver implementing the media API as a | ||
| 67 | NUL-terminated ASCII string. The driver version is stored in the | ||
| 68 | <structfield>driver_version</structfield> field.</para> | ||
| 69 | <para>Driver specific applications can use this information to | ||
| 70 | verify the driver identity. It is also useful to work around | ||
| 71 | known bugs, or to identify drivers in error reports.</para></entry> | ||
| 72 | </row> | ||
| 73 | <row> | ||
| 74 | <entry>char</entry> | ||
| 75 | <entry><structfield>model</structfield>[32]</entry> | ||
| 76 | <entry>Device model name as a NUL-terminated UTF-8 string. The | ||
| 77 | device version is stored in the <structfield>device_version</structfield> | ||
| 78 | field and is not be appended to the model name.</entry> | ||
| 79 | </row> | ||
| 80 | <row> | ||
| 81 | <entry>char</entry> | ||
| 82 | <entry><structfield>serial</structfield>[40]</entry> | ||
| 83 | <entry>Serial number as a NUL-terminated ASCII string.</entry> | ||
| 84 | </row> | ||
| 85 | <row> | ||
| 86 | <entry>char</entry> | ||
| 87 | <entry><structfield>bus_info</structfield>[32]</entry> | ||
| 88 | <entry>Location of the device in the system as a NUL-terminated | ||
| 89 | ASCII string. This includes the bus type name (PCI, USB, ...) and a | ||
| 90 | bus-specific identifier.</entry> | ||
| 91 | </row> | ||
| 92 | <row> | ||
| 93 | <entry>__u32</entry> | ||
| 94 | <entry><structfield>media_version</structfield></entry> | ||
| 95 | <entry>Media API version, formatted with the | ||
| 96 | <constant>KERNEL_VERSION()</constant> macro.</entry> | ||
| 97 | </row> | ||
| 98 | <row> | ||
| 99 | <entry>__u32</entry> | ||
| 100 | <entry><structfield>hw_revision</structfield></entry> | ||
| 101 | <entry>Hardware device revision in a driver-specific format.</entry> | ||
| 102 | </row> | ||
| 103 | <row> | ||
| 104 | <entry>__u32</entry> | ||
| 105 | <entry><structfield>media_version</structfield></entry> | ||
| 106 | <entry>Media device driver version, formatted with the | ||
| 107 | <constant>KERNEL_VERSION()</constant> macro. Together with the | ||
| 108 | <structfield>driver</structfield> field this identifies a particular | ||
| 109 | driver.</entry> | ||
| 110 | </row> | ||
| 111 | <row> | ||
| 112 | <entry>__u32</entry> | ||
| 113 | <entry><structfield>reserved</structfield>[31]</entry> | ||
| 114 | <entry>Reserved for future extensions. Drivers and applications must | ||
| 115 | set this array to zero.</entry> | ||
| 116 | </row> | ||
| 117 | </tbody> | ||
| 118 | </tgroup> | ||
| 119 | </table> | ||
| 120 | <para>The <structfield>serial</structfield> and <structfield>bus_info</structfield> | ||
| 121 | fields can be used to distinguish between multiple instances of otherwise | ||
| 122 | identical hardware. The serial number takes precedence when provided and can | ||
| 123 | be assumed to be unique. If the serial number is an empty string, the | ||
| 124 | <structfield>bus_info</structfield> field can be used instead. The | ||
| 125 | <structfield>bus_info</structfield> field is guaranteed to be unique, but | ||
| 126 | can vary across reboots or device unplug/replug.</para> | ||
| 127 | </refsect1> | ||
| 128 | |||
| 129 | <refsect1> | ||
| 130 | <title>Return value</title> | ||
| 131 | <para>This function doesn't return specific error codes.</para> | ||
| 132 | </refsect1> | ||
| 133 | </refentry> | ||
diff --git a/Documentation/DocBook/v4l/media-ioc-enum-entities.xml b/Documentation/DocBook/v4l/media-ioc-enum-entities.xml new file mode 100644 index 000000000000..576b68b33f2c --- /dev/null +++ b/Documentation/DocBook/v4l/media-ioc-enum-entities.xml | |||
| @@ -0,0 +1,308 @@ | |||
| 1 | <refentry id="media-ioc-enum-entities"> | ||
| 2 | <refmeta> | ||
| 3 | <refentrytitle>ioctl MEDIA_IOC_ENUM_ENTITIES</refentrytitle> | ||
| 4 | &manvol; | ||
| 5 | </refmeta> | ||
| 6 | |||
| 7 | <refnamediv> | ||
| 8 | <refname>MEDIA_IOC_ENUM_ENTITIES</refname> | ||
| 9 | <refpurpose>Enumerate entities and their properties</refpurpose> | ||
| 10 | </refnamediv> | ||
| 11 | |||
| 12 | <refsynopsisdiv> | ||
| 13 | <funcsynopsis> | ||
| 14 | <funcprototype> | ||
| 15 | <funcdef>int <function>ioctl</function></funcdef> | ||
| 16 | <paramdef>int <parameter>fd</parameter></paramdef> | ||
| 17 | <paramdef>int <parameter>request</parameter></paramdef> | ||
| 18 | <paramdef>struct media_entity_desc *<parameter>argp</parameter></paramdef> | ||
| 19 | </funcprototype> | ||
| 20 | </funcsynopsis> | ||
| 21 | </refsynopsisdiv> | ||
| 22 | |||
| 23 | <refsect1> | ||
| 24 | <title>Arguments</title> | ||
| 25 | |||
| 26 | <variablelist> | ||
| 27 | <varlistentry> | ||
| 28 | <term><parameter>fd</parameter></term> | ||
| 29 | <listitem> | ||
| 30 | <para>File descriptor returned by | ||
| 31 | <link linkend='media-func-open'><function>open()</function></link>.</para> | ||
| 32 | </listitem> | ||
| 33 | </varlistentry> | ||
| 34 | <varlistentry> | ||
| 35 | <term><parameter>request</parameter></term> | ||
| 36 | <listitem> | ||
| 37 | <para>MEDIA_IOC_ENUM_ENTITIES</para> | ||
| 38 | </listitem> | ||
| 39 | </varlistentry> | ||
| 40 | <varlistentry> | ||
| 41 | <term><parameter>argp</parameter></term> | ||
| 42 | <listitem> | ||
| 43 | <para></para> | ||
| 44 | </listitem> | ||
| 45 | </varlistentry> | ||
| 46 | </variablelist> | ||
| 47 | </refsect1> | ||
| 48 | |||
| 49 | <refsect1> | ||
| 50 | <title>Description</title> | ||
| 51 | <para>To query the attributes of an entity, applications set the id field | ||
| 52 | of a &media-entity-desc; structure and call the MEDIA_IOC_ENUM_ENTITIES | ||
| 53 | ioctl with a pointer to this structure. The driver fills the rest of the | ||
| 54 | structure or returns an &EINVAL; when the id is invalid.</para> | ||
| 55 | <para>Entities can be enumerated by or'ing the id with the | ||
| 56 | <constant>MEDIA_ENT_ID_FLAG_NEXT</constant> flag. The driver will return | ||
| 57 | information about the entity with the smallest id strictly larger than the | ||
| 58 | requested one ('next entity'), or the &EINVAL; if there is none.</para> | ||
| 59 | <para>Entity IDs can be non-contiguous. Applications must | ||
| 60 | <emphasis>not</emphasis> try to enumerate entities by calling | ||
| 61 | MEDIA_IOC_ENUM_ENTITIES with increasing id's until they get an error.</para> | ||
| 62 | <para>Two or more entities that share a common non-zero | ||
| 63 | <structfield>group_id</structfield> value are considered as logically | ||
| 64 | grouped. Groups are used to report | ||
| 65 | <itemizedlist> | ||
| 66 | <listitem><para>ALSA, VBI and video nodes that carry the same media | ||
| 67 | stream</para></listitem> | ||
| 68 | <listitem><para>lens and flash controllers associated with a sensor</para></listitem> | ||
| 69 | </itemizedlist> | ||
| 70 | </para> | ||
| 71 | |||
| 72 | <table pgwide="1" frame="none" id="media-entity-desc"> | ||
| 73 | <title>struct <structname>media_entity_desc</structname></title> | ||
| 74 | <tgroup cols="5"> | ||
| 75 | <colspec colname="c1" /> | ||
| 76 | <colspec colname="c2" /> | ||
| 77 | <colspec colname="c3" /> | ||
| 78 | <colspec colname="c4" /> | ||
| 79 | <colspec colname="c5" /> | ||
| 80 | <tbody valign="top"> | ||
| 81 | <row> | ||
| 82 | <entry>__u32</entry> | ||
| 83 | <entry><structfield>id</structfield></entry> | ||
| 84 | <entry></entry> | ||
| 85 | <entry></entry> | ||
| 86 | <entry>Entity id, set by the application. When the id is or'ed with | ||
| 87 | <constant>MEDIA_ENT_ID_FLAG_NEXT</constant>, the driver clears the | ||
| 88 | flag and returns the first entity with a larger id.</entry> | ||
| 89 | </row> | ||
| 90 | <row> | ||
| 91 | <entry>char</entry> | ||
| 92 | <entry><structfield>name</structfield>[32]</entry> | ||
| 93 | <entry></entry> | ||
| 94 | <entry></entry> | ||
| 95 | <entry>Entity name as an UTF-8 NULL-terminated string.</entry> | ||
| 96 | </row> | ||
| 97 | <row> | ||
| 98 | <entry>__u32</entry> | ||
| 99 | <entry><structfield>type</structfield></entry> | ||
| 100 | <entry></entry> | ||
| 101 | <entry></entry> | ||
| 102 | <entry>Entity type, see <xref linkend="media-entity-type" /> for details.</entry> | ||
| 103 | </row> | ||
| 104 | <row> | ||
| 105 | <entry>__u32</entry> | ||
| 106 | <entry><structfield>revision</structfield></entry> | ||
| 107 | <entry></entry> | ||
| 108 | <entry></entry> | ||
| 109 | <entry>Entity revision in a driver/hardware specific format.</entry> | ||
| 110 | </row> | ||
| 111 | <row> | ||
| 112 | <entry>__u32</entry> | ||
| 113 | <entry><structfield>flags</structfield></entry> | ||
| 114 | <entry></entry> | ||
| 115 | <entry></entry> | ||
| 116 | <entry>Entity flags, see <xref linkend="media-entity-flag" /> for details.</entry> | ||
| 117 | </row> | ||
| 118 | <row> | ||
| 119 | <entry>__u32</entry> | ||
| 120 | <entry><structfield>group_id</structfield></entry> | ||
| 121 | <entry></entry> | ||
| 122 | <entry></entry> | ||
| 123 | <entry>Entity group ID</entry> | ||
| 124 | </row> | ||
| 125 | <row> | ||
| 126 | <entry>__u16</entry> | ||
| 127 | <entry><structfield>pads</structfield></entry> | ||
| 128 | <entry></entry> | ||
| 129 | <entry></entry> | ||
| 130 | <entry>Number of pads</entry> | ||
| 131 | </row> | ||
| 132 | <row> | ||
| 133 | <entry>__u16</entry> | ||
| 134 | <entry><structfield>links</structfield></entry> | ||
| 135 | <entry></entry> | ||
| 136 | <entry></entry> | ||
| 137 | <entry>Total number of outbound links. Inbound links are not counted | ||
| 138 | in this field.</entry> | ||
| 139 | </row> | ||
| 140 | <row> | ||
| 141 | <entry>union</entry> | ||
| 142 | </row> | ||
| 143 | <row> | ||
| 144 | <entry></entry> | ||
| 145 | <entry>struct</entry> | ||
| 146 | <entry><structfield>v4l</structfield></entry> | ||
| 147 | <entry></entry> | ||
| 148 | <entry>Valid for V4L sub-devices and nodes only.</entry> | ||
| 149 | </row> | ||
| 150 | <row> | ||
| 151 | <entry></entry> | ||
| 152 | <entry></entry> | ||
| 153 | <entry>__u32</entry> | ||
| 154 | <entry><structfield>major</structfield></entry> | ||
| 155 | <entry>V4L device node major number. For V4L sub-devices with no | ||
| 156 | device node, set by the driver to 0.</entry> | ||
| 157 | </row> | ||
| 158 | <row> | ||
| 159 | <entry></entry> | ||
| 160 | <entry></entry> | ||
| 161 | <entry>__u32</entry> | ||
| 162 | <entry><structfield>minor</structfield></entry> | ||
| 163 | <entry>V4L device node minor number. For V4L sub-devices with no | ||
| 164 | device node, set by the driver to 0.</entry> | ||
| 165 | </row> | ||
| 166 | <row> | ||
| 167 | <entry></entry> | ||
| 168 | <entry>struct</entry> | ||
| 169 | <entry><structfield>fb</structfield></entry> | ||
| 170 | <entry></entry> | ||
| 171 | <entry>Valid for frame buffer nodes only.</entry> | ||
| 172 | </row> | ||
| 173 | <row> | ||
| 174 | <entry></entry> | ||
| 175 | <entry></entry> | ||
| 176 | <entry>__u32</entry> | ||
| 177 | <entry><structfield>major</structfield></entry> | ||
| 178 | <entry>Frame buffer device node major number.</entry> | ||
| 179 | </row> | ||
| 180 | <row> | ||
| 181 | <entry></entry> | ||
| 182 | <entry></entry> | ||
| 183 | <entry>__u32</entry> | ||
| 184 | <entry><structfield>minor</structfield></entry> | ||
| 185 | <entry>Frame buffer device node minor number.</entry> | ||
| 186 | </row> | ||
| 187 | <row> | ||
| 188 | <entry></entry> | ||
| 189 | <entry>struct</entry> | ||
| 190 | <entry><structfield>alsa</structfield></entry> | ||
| 191 | <entry></entry> | ||
| 192 | <entry>Valid for ALSA devices only.</entry> | ||
| 193 | </row> | ||
| 194 | <row> | ||
| 195 | <entry></entry> | ||
| 196 | <entry></entry> | ||
| 197 | <entry>__u32</entry> | ||
| 198 | <entry><structfield>card</structfield></entry> | ||
| 199 | <entry>ALSA card number</entry> | ||
| 200 | </row> | ||
| 201 | <row> | ||
| 202 | <entry></entry> | ||
| 203 | <entry></entry> | ||
| 204 | <entry>__u32</entry> | ||
| 205 | <entry><structfield>device</structfield></entry> | ||
| 206 | <entry>ALSA device number</entry> | ||
| 207 | </row> | ||
| 208 | <row> | ||
| 209 | <entry></entry> | ||
| 210 | <entry></entry> | ||
| 211 | <entry>__u32</entry> | ||
| 212 | <entry><structfield>subdevice</structfield></entry> | ||
| 213 | <entry>ALSA sub-device number</entry> | ||
| 214 | </row> | ||
| 215 | <row> | ||
| 216 | <entry></entry> | ||
| 217 | <entry>int</entry> | ||
| 218 | <entry><structfield>dvb</structfield></entry> | ||
| 219 | <entry></entry> | ||
| 220 | <entry>DVB card number</entry> | ||
| 221 | </row> | ||
| 222 | <row> | ||
| 223 | <entry></entry> | ||
| 224 | <entry>__u8</entry> | ||
| 225 | <entry><structfield>raw</structfield>[180]</entry> | ||
| 226 | <entry></entry> | ||
| 227 | <entry></entry> | ||
| 228 | </row> | ||
| 229 | </tbody> | ||
| 230 | </tgroup> | ||
| 231 | </table> | ||
| 232 | |||
| 233 | <table frame="none" pgwide="1" id="media-entity-type"> | ||
| 234 | <title>Media entity types</title> | ||
| 235 | <tgroup cols="2"> | ||
| 236 | <colspec colname="c1"/> | ||
| 237 | <colspec colname="c2"/> | ||
| 238 | <tbody valign="top"> | ||
| 239 | <row> | ||
| 240 | <entry><constant>MEDIA_ENT_T_DEVNODE</constant></entry> | ||
| 241 | <entry>Unknown device node</entry> | ||
| 242 | </row> | ||
| 243 | <row> | ||
| 244 | <entry><constant>MEDIA_ENT_T_DEVNODE_V4L</constant></entry> | ||
| 245 | <entry>V4L video, radio or vbi device node</entry> | ||
| 246 | </row> | ||
| 247 | <row> | ||
| 248 | <entry><constant>MEDIA_ENT_T_DEVNODE_FB</constant></entry> | ||
| 249 | <entry>Frame buffer device node</entry> | ||
| 250 | </row> | ||
| 251 | <row> | ||
| 252 | <entry><constant>MEDIA_ENT_T_DEVNODE_ALSA</constant></entry> | ||
| 253 | <entry>ALSA card</entry> | ||
| 254 | </row> | ||
| 255 | <row> | ||
| 256 | <entry><constant>MEDIA_ENT_T_DEVNODE_DVB</constant></entry> | ||
| 257 | <entry>DVB card</entry> | ||
| 258 | </row> | ||
| 259 | <row> | ||
| 260 | <entry><constant>MEDIA_ENT_T_V4L2_SUBDEV</constant></entry> | ||
| 261 | <entry>Unknown V4L sub-device</entry> | ||
| 262 | </row> | ||
| 263 | <row> | ||
| 264 | <entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_SENSOR</constant></entry> | ||
| 265 | <entry>Video sensor</entry> | ||
| 266 | </row> | ||
| 267 | <row> | ||
| 268 | <entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_FLASH</constant></entry> | ||
| 269 | <entry>Flash controller</entry> | ||
| 270 | </row> | ||
| 271 | <row> | ||
| 272 | <entry><constant>MEDIA_ENT_T_V4L2_SUBDEV_LENS</constant></entry> | ||
| 273 | <entry>Lens controller</entry> | ||
| 274 | </row> | ||
| 275 | </tbody> | ||
| 276 | </tgroup> | ||
| 277 | </table> | ||
| 278 | |||
| 279 | <table frame="none" pgwide="1" id="media-entity-flag"> | ||
| 280 | <title>Media entity flags</title> | ||
| 281 | <tgroup cols="2"> | ||
| 282 | <colspec colname="c1"/> | ||
| 283 | <colspec colname="c2"/> | ||
| 284 | <tbody valign="top"> | ||
| 285 | <row> | ||
| 286 | <entry><constant>MEDIA_ENT_FL_DEFAULT</constant></entry> | ||
| 287 | <entry>Default entity for its type. Used to discover the default | ||
| 288 | audio, VBI and video devices, the default camera sensor, ...</entry> | ||
| 289 | </row> | ||
| 290 | </tbody> | ||
| 291 | </tgroup> | ||
| 292 | </table> | ||
| 293 | </refsect1> | ||
| 294 | |||
| 295 | <refsect1> | ||
| 296 | &return-value; | ||
| 297 | |||
| 298 | <variablelist> | ||
| 299 | <varlistentry> | ||
| 300 | <term><errorcode>EINVAL</errorcode></term> | ||
| 301 | <listitem> | ||
| 302 | <para>The &media-entity-desc; <structfield>id</structfield> references | ||
| 303 | a non-existing entity.</para> | ||
| 304 | </listitem> | ||
| 305 | </varlistentry> | ||
| 306 | </variablelist> | ||
| 307 | </refsect1> | ||
| 308 | </refentry> | ||
diff --git a/Documentation/DocBook/v4l/media-ioc-enum-links.xml b/Documentation/DocBook/v4l/media-ioc-enum-links.xml new file mode 100644 index 000000000000..d2fc73ef8d56 --- /dev/null +++ b/Documentation/DocBook/v4l/media-ioc-enum-links.xml | |||
| @@ -0,0 +1,207 @@ | |||
| 1 | <refentry id="media-ioc-enum-links"> | ||
| 2 | <refmeta> | ||
| 3 | <refentrytitle>ioctl MEDIA_IOC_ENUM_LINKS</refentrytitle> | ||
| 4 | &manvol; | ||
| 5 | </refmeta> | ||
| 6 | |||
| 7 | <refnamediv> | ||
| 8 | <refname>MEDIA_IOC_ENUM_LINKS</refname> | ||
| 9 | <refpurpose>Enumerate all pads and links for a given entity</refpurpose> | ||
| 10 | </refnamediv> | ||
| 11 | |||
| 12 | <refsynopsisdiv> | ||
| 13 | <funcsynopsis> | ||
| 14 | <funcprototype> | ||
| 15 | <funcdef>int <function>ioctl</function></funcdef> | ||
| 16 | <paramdef>int <parameter>fd</parameter></paramdef> | ||
| 17 | <paramdef>int <parameter>request</parameter></paramdef> | ||
| 18 | <paramdef>struct media_links_enum *<parameter>argp</parameter></paramdef> | ||
| 19 | </funcprototype> | ||
| 20 | </funcsynopsis> | ||
| 21 | </refsynopsisdiv> | ||
| 22 | |||
| 23 | <refsect1> | ||
| 24 | <title>Arguments</title> | ||
| 25 | |||
| 26 | <variablelist> | ||
| 27 | <varlistentry> | ||
| 28 | <term><parameter>fd</parameter></term> | ||
| 29 | <listitem> | ||
| 30 | <para>File descriptor returned by | ||
| 31 | <link linkend='media-func-open'><function>open()</function></link>.</para> | ||
| 32 | </listitem> | ||
| 33 | </varlistentry> | ||
| 34 | <varlistentry> | ||
| 35 | <term><parameter>request</parameter></term> | ||
| 36 | <listitem> | ||
| 37 | <para>MEDIA_IOC_ENUM_LINKS</para> | ||
| 38 | </listitem> | ||
| 39 | </varlistentry> | ||
| 40 | <varlistentry> | ||
| 41 | <term><parameter>argp</parameter></term> | ||
| 42 | <listitem> | ||
| 43 | <para></para> | ||
| 44 | </listitem> | ||
| 45 | </varlistentry> | ||
| 46 | </variablelist> | ||
| 47 | </refsect1> | ||
| 48 | |||
| 49 | <refsect1> | ||
| 50 | <title>Description</title> | ||
| 51 | |||
| 52 | <para>To enumerate pads and/or links for a given entity, applications set | ||
| 53 | the entity field of a &media-links-enum; structure and initialize the | ||
| 54 | &media-pad-desc; and &media-link-desc; structure arrays pointed by the | ||
| 55 | <structfield>pads</structfield> and <structfield>links</structfield> fields. | ||
| 56 | They then call the MEDIA_IOC_ENUM_LINKS ioctl with a pointer to this | ||
| 57 | structure.</para> | ||
| 58 | <para>If the <structfield>pads</structfield> field is not NULL, the driver | ||
| 59 | fills the <structfield>pads</structfield> array with information about the | ||
| 60 | entity's pads. The array must have enough room to store all the entity's | ||
| 61 | pads. The number of pads can be retrieved with the &MEDIA-IOC-ENUM-ENTITIES; | ||
| 62 | ioctl.</para> | ||
| 63 | <para>If the <structfield>links</structfield> field is not NULL, the driver | ||
| 64 | fills the <structfield>links</structfield> array with information about the | ||
| 65 | entity's outbound links. The array must have enough room to store all the | ||
| 66 | entity's outbound links. The number of outbound links can be retrieved with | ||
| 67 | the &MEDIA-IOC-ENUM-ENTITIES; ioctl.</para> | ||
| 68 | <para>Only forward links that originate at one of the entity's source pads | ||
| 69 | are returned during the enumeration process.</para> | ||
| 70 | |||
| 71 | <table pgwide="1" frame="none" id="media-links-enum"> | ||
| 72 | <title>struct <structname>media_links_enum</structname></title> | ||
| 73 | <tgroup cols="3"> | ||
| 74 | &cs-str; | ||
| 75 | <tbody valign="top"> | ||
| 76 | <row> | ||
| 77 | <entry>__u32</entry> | ||
| 78 | <entry><structfield>entity</structfield></entry> | ||
| 79 | <entry>Entity id, set by the application.</entry> | ||
| 80 | </row> | ||
| 81 | <row> | ||
| 82 | <entry>struct &media-pad-desc;</entry> | ||
| 83 | <entry>*<structfield>pads</structfield></entry> | ||
| 84 | <entry>Pointer to a pads array allocated by the application. Ignored | ||
| 85 | if NULL.</entry> | ||
| 86 | </row> | ||
| 87 | <row> | ||
| 88 | <entry>struct &media-link-desc;</entry> | ||
| 89 | <entry>*<structfield>links</structfield></entry> | ||
| 90 | <entry>Pointer to a links array allocated by the application. Ignored | ||
| 91 | if NULL.</entry> | ||
| 92 | </row> | ||
| 93 | </tbody> | ||
| 94 | </tgroup> | ||
| 95 | </table> | ||
| 96 | |||
| 97 | <table pgwide="1" frame="none" id="media-pad-desc"> | ||
| 98 | <title>struct <structname>media_pad_desc</structname></title> | ||
| 99 | <tgroup cols="3"> | ||
| 100 | &cs-str; | ||
| 101 | <tbody valign="top"> | ||
| 102 | <row> | ||
| 103 | <entry>__u32</entry> | ||
| 104 | <entry><structfield>entity</structfield></entry> | ||
| 105 | <entry>ID of the entity this pad belongs to.</entry> | ||
| 106 | </row> | ||
| 107 | <row> | ||
| 108 | <entry>__u16</entry> | ||
| 109 | <entry><structfield>index</structfield></entry> | ||
| 110 | <entry>0-based pad index.</entry> | ||
| 111 | </row> | ||
| 112 | <row> | ||
| 113 | <entry>__u32</entry> | ||
| 114 | <entry><structfield>flags</structfield></entry> | ||
| 115 | <entry>Pad flags, see <xref linkend="media-pad-flag" /> for more details.</entry> | ||
| 116 | </row> | ||
| 117 | </tbody> | ||
| 118 | </tgroup> | ||
| 119 | </table> | ||
| 120 | |||
| 121 | <table frame="none" pgwide="1" id="media-pad-flag"> | ||
| 122 | <title>Media pad flags</title> | ||
| 123 | <tgroup cols="2"> | ||
| 124 | <colspec colname="c1"/> | ||
| 125 | <colspec colname="c2"/> | ||
| 126 | <tbody valign="top"> | ||
| 127 | <row> | ||
| 128 | <entry><constant>MEDIA_PAD_FL_SINK</constant></entry> | ||
| 129 | <entry>Input pad, relative to the entity. Input pads sink data and | ||
| 130 | are targets of links.</entry> | ||
| 131 | </row> | ||
| 132 | <row> | ||
| 133 | <entry><constant>MEDIA_PAD_FL_SOURCE</constant></entry> | ||
| 134 | <entry>Output pad, relative to the entity. Output pads source data | ||
| 135 | and are origins of links.</entry> | ||
| 136 | </row> | ||
| 137 | </tbody> | ||
| 138 | </tgroup> | ||
| 139 | </table> | ||
| 140 | |||
| 141 | <table pgwide="1" frame="none" id="media-link-desc"> | ||
| 142 | <title>struct <structname>media_links_desc</structname></title> | ||
| 143 | <tgroup cols="3"> | ||
| 144 | &cs-str; | ||
| 145 | <tbody valign="top"> | ||
| 146 | <row> | ||
| 147 | <entry>struct &media-pad-desc;</entry> | ||
| 148 | <entry><structfield>source</structfield></entry> | ||
| 149 | <entry>Pad at the origin of this link.</entry> | ||
| 150 | </row> | ||
| 151 | <row> | ||
| 152 | <entry>struct &media-pad-desc;</entry> | ||
| 153 | <entry><structfield>sink</structfield></entry> | ||
| 154 | <entry>Pad at the target of this link.</entry> | ||
| 155 | </row> | ||
| 156 | <row> | ||
| 157 | <entry>__u32</entry> | ||
| 158 | <entry><structfield>flags</structfield></entry> | ||
| 159 | <entry>Link flags, see <xref linkend="media-link-flag" /> for more details.</entry> | ||
| 160 | </row> | ||
| 161 | </tbody> | ||
| 162 | </tgroup> | ||
| 163 | </table> | ||
| 164 | |||
| 165 | <table frame="none" pgwide="1" id="media-link-flag"> | ||
| 166 | <title>Media link flags</title> | ||
| 167 | <tgroup cols="2"> | ||
| 168 | <colspec colname="c1"/> | ||
| 169 | <colspec colname="c2"/> | ||
| 170 | <tbody valign="top"> | ||
| 171 | <row> | ||
| 172 | <entry><constant>MEDIA_LNK_FL_ENABLED</constant></entry> | ||
| 173 | <entry>The link is enabled and can be used to transfer media data. | ||
| 174 | When two or more links target a sink pad, only one of them can be | ||
| 175 | enabled at a time.</entry> | ||
| 176 | </row> | ||
| 177 | <row> | ||
| 178 | <entry><constant>MEDIA_LNK_FL_IMMUTABLE</constant></entry> | ||
| 179 | <entry>The link enabled state can't be modified at runtime. An | ||
| 180 | immutable link is always enabled.</entry> | ||
| 181 | </row> | ||
| 182 | <row> | ||
| 183 | <entry><constant>MEDIA_LNK_FL_DYNAMIC</constant></entry> | ||
| 184 | <entry>The link enabled state can be modified during streaming. This | ||
| 185 | flag is set by drivers and is read-only for applications.</entry> | ||
| 186 | </row> | ||
| 187 | </tbody> | ||
| 188 | </tgroup> | ||
| 189 | </table> | ||
| 190 | <para>One and only one of <constant>MEDIA_PAD_FL_SINK</constant> and | ||
| 191 | <constant>MEDIA_PAD_FL_SOURCE</constant> must be set for every pad.</para> | ||
| 192 | </refsect1> | ||
| 193 | |||
| 194 | <refsect1> | ||
| 195 | &return-value; | ||
| 196 | |||
| 197 | <variablelist> | ||
| 198 | <varlistentry> | ||
| 199 | <term><errorcode>EINVAL</errorcode></term> | ||
| 200 | <listitem> | ||
| 201 | <para>The &media-links-enum; <structfield>id</structfield> references | ||
| 202 | a non-existing entity.</para> | ||
| 203 | </listitem> | ||
| 204 | </varlistentry> | ||
| 205 | </variablelist> | ||
| 206 | </refsect1> | ||
| 207 | </refentry> | ||
diff --git a/Documentation/DocBook/v4l/media-ioc-setup-link.xml b/Documentation/DocBook/v4l/media-ioc-setup-link.xml new file mode 100644 index 000000000000..2331e76ded17 --- /dev/null +++ b/Documentation/DocBook/v4l/media-ioc-setup-link.xml | |||
| @@ -0,0 +1,93 @@ | |||
| 1 | <refentry id="media-ioc-setup-link"> | ||
| 2 | <refmeta> | ||
| 3 | <refentrytitle>ioctl MEDIA_IOC_SETUP_LINK</refentrytitle> | ||
| 4 | &manvol; | ||
| 5 | </refmeta> | ||
| 6 | |||
| 7 | <refnamediv> | ||
| 8 | <refname>MEDIA_IOC_SETUP_LINK</refname> | ||
| 9 | <refpurpose>Modify the properties of a link</refpurpose> | ||
| 10 | </refnamediv> | ||
| 11 | |||
| 12 | <refsynopsisdiv> | ||
| 13 | <funcsynopsis> | ||
| 14 | <funcprototype> | ||
| 15 | <funcdef>int <function>ioctl</function></funcdef> | ||
| 16 | <paramdef>int <parameter>fd</parameter></paramdef> | ||
| 17 | <paramdef>int <parameter>request</parameter></paramdef> | ||
| 18 | <paramdef>struct media_link_desc *<parameter>argp</parameter></paramdef> | ||
| 19 | </funcprototype> | ||
| 20 | </funcsynopsis> | ||
| 21 | </refsynopsisdiv> | ||
| 22 | |||
| 23 | <refsect1> | ||
| 24 | <title>Arguments</title> | ||
| 25 | |||
| 26 | <variablelist> | ||
| 27 | <varlistentry> | ||
| 28 | <term><parameter>fd</parameter></term> | ||
| 29 | <listitem> | ||
| 30 | <para>File descriptor returned by | ||
| 31 | <link linkend='media-func-open'><function>open()</function></link>.</para> | ||
| 32 | </listitem> | ||
| 33 | </varlistentry> | ||
| 34 | <varlistentry> | ||
| 35 | <term><parameter>request</parameter></term> | ||
| 36 | <listitem> | ||
| 37 | <para>MEDIA_IOC_ENUM_LINKS</para> | ||
| 38 | </listitem> | ||
| 39 | </varlistentry> | ||
| 40 | <varlistentry> | ||
| 41 | <term><parameter>argp</parameter></term> | ||
| 42 | <listitem> | ||
| 43 | <para></para> | ||
| 44 | </listitem> | ||
| 45 | </varlistentry> | ||
| 46 | </variablelist> | ||
| 47 | </refsect1> | ||
| 48 | |||
| 49 | <refsect1> | ||
| 50 | <title>Description</title> | ||
| 51 | |||
| 52 | <para>To change link properties applications fill a &media-link-desc; with | ||
| 53 | link identification information (source and sink pad) and the new requested | ||
| 54 | link flags. They then call the MEDIA_IOC_SETUP_LINK ioctl with a pointer to | ||
| 55 | that structure.</para> | ||
| 56 | <para>The only configurable property is the <constant>ENABLED</constant> | ||
| 57 | link flag to enable/disable a link. Links marked with the | ||
| 58 | <constant>IMMUTABLE</constant> link flag can not be enabled or disabled. | ||
| 59 | </para> | ||
| 60 | <para>Link configuration has no side effect on other links. If an enabled | ||
| 61 | link at the sink pad prevents the link from being enabled, the driver | ||
| 62 | returns with an &EBUSY;.</para> | ||
| 63 | <para>Only links marked with the <constant>DYNAMIC</constant> link flag can | ||
| 64 | be enabled/disabled while streaming media data. Attempting to enable or | ||
| 65 | disable a streaming non-dynamic link will return an &EBUSY;.</para> | ||
| 66 | <para>If the specified link can't be found the driver returns with an | ||
| 67 | &EINVAL;.</para> | ||
| 68 | </refsect1> | ||
| 69 | |||
| 70 | <refsect1> | ||
| 71 | &return-value; | ||
| 72 | |||
| 73 | <variablelist> | ||
| 74 | <varlistentry> | ||
| 75 | <term><errorcode>EBUSY</errorcode></term> | ||
| 76 | <listitem> | ||
| 77 | <para>The link properties can't be changed because the link is | ||
| 78 | currently busy. This can be caused, for instance, by an active media | ||
| 79 | stream (audio or video) on the link. The ioctl shouldn't be retried if | ||
| 80 | no other action is performed before to fix the problem.</para> | ||
| 81 | </listitem> | ||
| 82 | </varlistentry> | ||
| 83 | <varlistentry> | ||
| 84 | <term><errorcode>EINVAL</errorcode></term> | ||
| 85 | <listitem> | ||
| 86 | <para>The &media-link-desc; references a non-existing link, or the | ||
| 87 | link is immutable and an attempt to modify its configuration was made. | ||
| 88 | </para> | ||
| 89 | </listitem> | ||
| 90 | </varlistentry> | ||
| 91 | </variablelist> | ||
| 92 | </refsect1> | ||
| 93 | </refentry> | ||
diff --git a/Documentation/DocBook/v4l/nv12mt.gif b/Documentation/DocBook/v4l/nv12mt.gif new file mode 100644 index 000000000000..ef2d4cf8367b --- /dev/null +++ b/Documentation/DocBook/v4l/nv12mt.gif | |||
| Binary files differ | |||
diff --git a/Documentation/DocBook/v4l/nv12mt_example.gif b/Documentation/DocBook/v4l/nv12mt_example.gif new file mode 100644 index 000000000000..df81d68108ee --- /dev/null +++ b/Documentation/DocBook/v4l/nv12mt_example.gif | |||
| Binary files differ | |||
diff --git a/Documentation/DocBook/v4l/pipeline.pdf b/Documentation/DocBook/v4l/pipeline.pdf new file mode 100644 index 000000000000..ee3e37f04b6a --- /dev/null +++ b/Documentation/DocBook/v4l/pipeline.pdf | |||
| Binary files differ | |||
diff --git a/Documentation/DocBook/v4l/pipeline.png b/Documentation/DocBook/v4l/pipeline.png new file mode 100644 index 000000000000..f19b86c2c24d --- /dev/null +++ b/Documentation/DocBook/v4l/pipeline.png | |||
| Binary files differ | |||
diff --git a/Documentation/DocBook/v4l/pixfmt-nv12m.xml b/Documentation/DocBook/v4l/pixfmt-nv12m.xml new file mode 100644 index 000000000000..c9e166d9ded8 --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt-nv12m.xml | |||
| @@ -0,0 +1,154 @@ | |||
| 1 | <refentry id="V4L2-PIX-FMT-NV12M"> | ||
| 2 | <refmeta> | ||
| 3 | <refentrytitle>V4L2_PIX_FMT_NV12M ('NV12M')</refentrytitle> | ||
| 4 | &manvol; | ||
| 5 | </refmeta> | ||
| 6 | <refnamediv> | ||
| 7 | <refname> <constant>V4L2_PIX_FMT_NV12M</constant></refname> | ||
| 8 | <refpurpose>Variation of <constant>V4L2_PIX_FMT_NV12</constant> with planes | ||
| 9 | non contiguous in memory. </refpurpose> | ||
| 10 | </refnamediv> | ||
| 11 | <refsect1> | ||
| 12 | <title>Description</title> | ||
| 13 | |||
| 14 | <para>This is a multi-planar, two-plane version of the YUV 4:2:0 format. | ||
| 15 | The three components are separated into two sub-images or planes. | ||
| 16 | <constant>V4L2_PIX_FMT_NV12M</constant> differs from <constant>V4L2_PIX_FMT_NV12 | ||
| 17 | </constant> in that the two planes are non-contiguous in memory, i.e. the chroma | ||
| 18 | plane do not necessarily immediately follows the luma plane. | ||
| 19 | The luminance data occupies the first plane. The Y plane has one byte per pixel. | ||
| 20 | In the second plane there is a chrominance data with alternating chroma samples. | ||
| 21 | The CbCr plane is the same width, in bytes, as the Y plane (and of the image), | ||
| 22 | but is half as tall in pixels. Each CbCr pair belongs to four pixels. For example, | ||
| 23 | Cb<subscript>0</subscript>/Cr<subscript>0</subscript> belongs to | ||
| 24 | Y'<subscript>00</subscript>, Y'<subscript>01</subscript>, | ||
| 25 | Y'<subscript>10</subscript>, Y'<subscript>11</subscript>. </para> | ||
| 26 | |||
| 27 | <para><constant>V4L2_PIX_FMT_NV12M</constant> is intended to be | ||
| 28 | used only in drivers and applications that support the multi-planar API, | ||
| 29 | described in <xref linkend="planar-apis"/>. </para> | ||
| 30 | |||
| 31 | <para>If the Y plane has pad bytes after each row, then the | ||
| 32 | CbCr plane has as many pad bytes after its rows.</para> | ||
| 33 | |||
| 34 | <example> | ||
| 35 | <title><constant>V4L2_PIX_FMT_NV12M</constant> 4 × 4 pixel image</title> | ||
| 36 | |||
| 37 | <formalpara> | ||
| 38 | <title>Byte Order.</title> | ||
| 39 | <para>Each cell is one byte. | ||
| 40 | <informaltable frame="none"> | ||
| 41 | <tgroup cols="5" align="center"> | ||
| 42 | <colspec align="left" colwidth="2*" /> | ||
| 43 | <tbody valign="top"> | ||
| 44 | <row> | ||
| 45 | <entry>start0 + 0:</entry> | ||
| 46 | <entry>Y'<subscript>00</subscript></entry> | ||
| 47 | <entry>Y'<subscript>01</subscript></entry> | ||
| 48 | <entry>Y'<subscript>02</subscript></entry> | ||
| 49 | <entry>Y'<subscript>03</subscript></entry> | ||
| 50 | </row> | ||
| 51 | <row> | ||
| 52 | <entry>start0 + 4:</entry> | ||
| 53 | <entry>Y'<subscript>10</subscript></entry> | ||
| 54 | <entry>Y'<subscript>11</subscript></entry> | ||
| 55 | <entry>Y'<subscript>12</subscript></entry> | ||
| 56 | <entry>Y'<subscript>13</subscript></entry> | ||
| 57 | </row> | ||
| 58 | <row> | ||
| 59 | <entry>start0 + 8:</entry> | ||
| 60 | <entry>Y'<subscript>20</subscript></entry> | ||
| 61 | <entry>Y'<subscript>21</subscript></entry> | ||
| 62 | <entry>Y'<subscript>22</subscript></entry> | ||
| 63 | <entry>Y'<subscript>23</subscript></entry> | ||
| 64 | </row> | ||
| 65 | <row> | ||
| 66 | <entry>start0 + 12:</entry> | ||
| 67 | <entry>Y'<subscript>30</subscript></entry> | ||
| 68 | <entry>Y'<subscript>31</subscript></entry> | ||
| 69 | <entry>Y'<subscript>32</subscript></entry> | ||
| 70 | <entry>Y'<subscript>33</subscript></entry> | ||
| 71 | </row> | ||
| 72 | <row> | ||
| 73 | <entry></entry> | ||
| 74 | </row> | ||
| 75 | <row> | ||
| 76 | <entry>start1 + 0:</entry> | ||
| 77 | <entry>Cb<subscript>00</subscript></entry> | ||
| 78 | <entry>Cr<subscript>00</subscript></entry> | ||
| 79 | <entry>Cb<subscript>01</subscript></entry> | ||
| 80 | <entry>Cr<subscript>01</subscript></entry> | ||
| 81 | </row> | ||
| 82 | <row> | ||
| 83 | <entry>start1 + 4:</entry> | ||
| 84 | <entry>Cb<subscript>10</subscript></entry> | ||
| 85 | <entry>Cr<subscript>10</subscript></entry> | ||
| 86 | <entry>Cb<subscript>11</subscript></entry> | ||
| 87 | <entry>Cr<subscript>11</subscript></entry> | ||
| 88 | </row> | ||
| 89 | </tbody> | ||
| 90 | </tgroup> | ||
| 91 | </informaltable> | ||
| 92 | </para> | ||
| 93 | </formalpara> | ||
| 94 | |||
| 95 | <formalpara> | ||
| 96 | <title>Color Sample Location.</title> | ||
| 97 | <para> | ||
| 98 | <informaltable frame="none"> | ||
| 99 | <tgroup cols="7" align="center"> | ||
| 100 | <tbody valign="top"> | ||
| 101 | <row> | ||
| 102 | <entry></entry> | ||
| 103 | <entry>0</entry><entry></entry><entry>1</entry><entry></entry> | ||
| 104 | <entry>2</entry><entry></entry><entry>3</entry> | ||
| 105 | </row> | ||
| 106 | <row> | ||
| 107 | <entry>0</entry> | ||
| 108 | <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> | ||
| 109 | <entry>Y</entry><entry></entry><entry>Y</entry> | ||
| 110 | </row> | ||
| 111 | <row> | ||
| 112 | <entry></entry> | ||
| 113 | <entry></entry><entry>C</entry><entry></entry><entry></entry> | ||
| 114 | <entry></entry><entry>C</entry><entry></entry> | ||
| 115 | </row> | ||
| 116 | <row> | ||
| 117 | <entry>1</entry> | ||
| 118 | <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> | ||
| 119 | <entry>Y</entry><entry></entry><entry>Y</entry> | ||
| 120 | </row> | ||
| 121 | <row> | ||
| 122 | <entry></entry> | ||
| 123 | </row> | ||
| 124 | <row> | ||
| 125 | <entry>2</entry> | ||
| 126 | <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> | ||
| 127 | <entry>Y</entry><entry></entry><entry>Y</entry> | ||
| 128 | </row> | ||
| 129 | <row> | ||
| 130 | <entry></entry> | ||
| 131 | <entry></entry><entry>C</entry><entry></entry><entry></entry> | ||
| 132 | <entry></entry><entry>C</entry><entry></entry> | ||
| 133 | </row> | ||
| 134 | <row> | ||
| 135 | <entry>3</entry> | ||
| 136 | <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> | ||
| 137 | <entry>Y</entry><entry></entry><entry>Y</entry> | ||
| 138 | </row> | ||
| 139 | </tbody> | ||
| 140 | </tgroup> | ||
| 141 | </informaltable> | ||
| 142 | </para> | ||
| 143 | </formalpara> | ||
| 144 | </example> | ||
| 145 | </refsect1> | ||
| 146 | </refentry> | ||
| 147 | |||
| 148 | <!-- | ||
| 149 | Local Variables: | ||
| 150 | mode: sgml | ||
| 151 | sgml-parent-document: "pixfmt.sgml" | ||
| 152 | indent-tabs-mode: nil | ||
| 153 | End: | ||
| 154 | --> | ||
diff --git a/Documentation/DocBook/v4l/pixfmt-nv12mt.xml b/Documentation/DocBook/v4l/pixfmt-nv12mt.xml new file mode 100644 index 000000000000..7a2855a526c1 --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt-nv12mt.xml | |||
| @@ -0,0 +1,74 @@ | |||
| 1 | <refentry> | ||
| 2 | <refmeta> | ||
| 3 | <refentrytitle>V4L2_PIX_FMT_NV12MT ('TM12')</refentrytitle> | ||
| 4 | &manvol; | ||
| 5 | </refmeta> | ||
| 6 | <refnamediv> | ||
| 7 | <refname id="V4L2-PIX-FMT-NV12MT"><constant>V4L2_PIX_FMT_NV12MT | ||
| 8 | </constant></refname> | ||
| 9 | <refpurpose>Formats with ½ horizontal and vertical | ||
| 10 | chroma resolution. This format has two planes - one for luminance and one for | ||
| 11 | chrominance. Chroma samples are interleaved. The difference to | ||
| 12 | <constant>V4L2_PIX_FMT_NV12</constant> is the memory layout. Pixels are | ||
| 13 | grouped in macroblocks of 64x32 size. The order of macroblocks in memory is | ||
| 14 | also not standard. | ||
| 15 | </refpurpose> | ||
| 16 | </refnamediv> | ||
| 17 | <refsect1> | ||
| 18 | <title>Description</title> | ||
| 19 | |||
| 20 | <para>This is the two-plane versions of the YUV 4:2:0 format where data | ||
| 21 | is grouped into 64x32 macroblocks. The three components are separated into two | ||
| 22 | sub-images or planes. The Y plane has one byte per pixel and pixels are grouped | ||
| 23 | into 64x32 macroblocks. The CbCr plane has the same width, in bytes, as the Y | ||
| 24 | plane (and the image), but is half as tall in pixels. The chroma plane is also | ||
| 25 | grouped into 64x32 macroblocks.</para> | ||
| 26 | <para>Width of the buffer has to be aligned to the multiple of 128, and | ||
| 27 | height alignment is 32. Every four adjactent buffers - two horizontally and two | ||
| 28 | vertically are grouped together and are located in memory in Z or flipped Z | ||
| 29 | order. </para> | ||
| 30 | <para>Layout of macroblocks in memory is presented in the following | ||
| 31 | figure.</para> | ||
| 32 | <para><figure id="nv12mt"> | ||
| 33 | <title><constant>V4L2_PIX_FMT_NV12MT</constant> macroblock Z shape | ||
| 34 | memory layout</title> | ||
| 35 | <mediaobject> | ||
| 36 | <imageobject> | ||
| 37 | <imagedata fileref="nv12mt.gif" format="GIF" /> | ||
| 38 | </imageobject> | ||
| 39 | </mediaobject> | ||
| 40 | </figure> | ||
| 41 | The requirement that width is multiple of 128 is implemented because, | ||
| 42 | the Z shape cannot be cut in half horizontally. In case the vertical resolution | ||
| 43 | of macroblocks is odd then the last row of macroblocks is arranged in a linear | ||
| 44 | order. </para> | ||
| 45 | <para>In case of chroma the layout is identical. Cb and Cr samples are | ||
| 46 | interleaved. Height of the buffer is aligned to 32. | ||
| 47 | </para> | ||
| 48 | <example> | ||
| 49 | <title>Memory layout of macroblocks in <constant>V4L2_PIX_FMT_NV12 | ||
| 50 | </constant> format pixel image - extreme case</title> | ||
| 51 | <para> | ||
| 52 | <figure id="nv12mt_ex"> | ||
| 53 | <title>Example <constant>V4L2_PIX_FMT_NV12MT</constant> memory | ||
| 54 | layout of macroblocks</title> | ||
| 55 | <mediaobject> | ||
| 56 | <imageobject> | ||
| 57 | <imagedata fileref="nv12mt_example.gif" format="GIF" /> | ||
| 58 | </imageobject> | ||
| 59 | </mediaobject> | ||
| 60 | </figure> | ||
| 61 | Memory layout of macroblocks of <constant>V4L2_PIX_FMT_NV12MT | ||
| 62 | </constant> format in most extreme case. | ||
| 63 | </para> | ||
| 64 | </example> | ||
| 65 | </refsect1> | ||
| 66 | </refentry> | ||
| 67 | |||
| 68 | <!-- | ||
| 69 | Local Variables: | ||
| 70 | mode: sgml | ||
| 71 | sgml-parent-document: "pixfmt.sgml" | ||
| 72 | indent-tabs-mode: nil | ||
| 73 | End: | ||
| 74 | --> | ||
diff --git a/Documentation/DocBook/v4l/pixfmt-srggb12.xml b/Documentation/DocBook/v4l/pixfmt-srggb12.xml new file mode 100644 index 000000000000..9ba4fb690bc0 --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt-srggb12.xml | |||
| @@ -0,0 +1,90 @@ | |||
| 1 | <refentry> | ||
| 2 | <refmeta> | ||
| 3 | <refentrytitle>V4L2_PIX_FMT_SRGGB12 ('RG12'), | ||
| 4 | V4L2_PIX_FMT_SGRBG12 ('BA12'), | ||
| 5 | V4L2_PIX_FMT_SGBRG12 ('GB12'), | ||
| 6 | V4L2_PIX_FMT_SBGGR12 ('BG12'), | ||
| 7 | </refentrytitle> | ||
| 8 | &manvol; | ||
| 9 | </refmeta> | ||
| 10 | <refnamediv> | ||
| 11 | <refname id="V4L2-PIX-FMT-SRGGB12"><constant>V4L2_PIX_FMT_SRGGB12</constant></refname> | ||
| 12 | <refname id="V4L2-PIX-FMT-SGRBG12"><constant>V4L2_PIX_FMT_SGRBG12</constant></refname> | ||
| 13 | <refname id="V4L2-PIX-FMT-SGBRG12"><constant>V4L2_PIX_FMT_SGBRG12</constant></refname> | ||
| 14 | <refname id="V4L2-PIX-FMT-SBGGR12"><constant>V4L2_PIX_FMT_SBGGR12</constant></refname> | ||
| 15 | <refpurpose>12-bit Bayer formats expanded to 16 bits</refpurpose> | ||
| 16 | </refnamediv> | ||
| 17 | <refsect1> | ||
| 18 | <title>Description</title> | ||
| 19 | |||
| 20 | <para>The following four pixel formats are raw sRGB / Bayer formats with | ||
| 21 | 12 bits per colour. Each colour component is stored in a 16-bit word, with 6 | ||
| 22 | unused high bits filled with zeros. Each n-pixel row contains n/2 green samples | ||
| 23 | and n/2 blue or red samples, with alternating red and blue rows. Bytes are | ||
| 24 | stored in memory in little endian order. They are conventionally described | ||
| 25 | as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of these | ||
| 26 | formats</para> | ||
| 27 | |||
| 28 | <example> | ||
| 29 | <title><constant>V4L2_PIX_FMT_SBGGR12</constant> 4 × 4 | ||
| 30 | pixel image</title> | ||
| 31 | |||
| 32 | <formalpara> | ||
| 33 | <title>Byte Order.</title> | ||
| 34 | <para>Each cell is one byte, high 6 bits in high bytes are 0. | ||
| 35 | <informaltable frame="none"> | ||
| 36 | <tgroup cols="5" align="center"> | ||
| 37 | <colspec align="left" colwidth="2*" /> | ||
| 38 | <tbody valign="top"> | ||
| 39 | <row> | ||
| 40 | <entry>start + 0:</entry> | ||
| 41 | <entry>B<subscript>00low</subscript></entry> | ||
| 42 | <entry>B<subscript>00high</subscript></entry> | ||
| 43 | <entry>G<subscript>01low</subscript></entry> | ||
| 44 | <entry>G<subscript>01high</subscript></entry> | ||
| 45 | <entry>B<subscript>02low</subscript></entry> | ||
| 46 | <entry>B<subscript>02high</subscript></entry> | ||
| 47 | <entry>G<subscript>03low</subscript></entry> | ||
| 48 | <entry>G<subscript>03high</subscript></entry> | ||
| 49 | </row> | ||
| 50 | <row> | ||
| 51 | <entry>start + 8:</entry> | ||
| 52 | <entry>G<subscript>10low</subscript></entry> | ||
| 53 | <entry>G<subscript>10high</subscript></entry> | ||
| 54 | <entry>R<subscript>11low</subscript></entry> | ||
| 55 | <entry>R<subscript>11high</subscript></entry> | ||
| 56 | <entry>G<subscript>12low</subscript></entry> | ||
| 57 | <entry>G<subscript>12high</subscript></entry> | ||
| 58 | <entry>R<subscript>13low</subscript></entry> | ||
| 59 | <entry>R<subscript>13high</subscript></entry> | ||
| 60 | </row> | ||
| 61 | <row> | ||
| 62 | <entry>start + 16:</entry> | ||
| 63 | <entry>B<subscript>20low</subscript></entry> | ||
| 64 | <entry>B<subscript>20high</subscript></entry> | ||
| 65 | <entry>G<subscript>21low</subscript></entry> | ||
| 66 | <entry>G<subscript>21high</subscript></entry> | ||
| 67 | <entry>B<subscript>22low</subscript></entry> | ||
| 68 | <entry>B<subscript>22high</subscript></entry> | ||
| 69 | <entry>G<subscript>23low</subscript></entry> | ||
| 70 | <entry>G<subscript>23high</subscript></entry> | ||
| 71 | </row> | ||
| 72 | <row> | ||
| 73 | <entry>start + 24:</entry> | ||
| 74 | <entry>G<subscript>30low</subscript></entry> | ||
| 75 | <entry>G<subscript>30high</subscript></entry> | ||
| 76 | <entry>R<subscript>31low</subscript></entry> | ||
| 77 | <entry>R<subscript>31high</subscript></entry> | ||
| 78 | <entry>G<subscript>32low</subscript></entry> | ||
| 79 | <entry>G<subscript>32high</subscript></entry> | ||
| 80 | <entry>R<subscript>33low</subscript></entry> | ||
| 81 | <entry>R<subscript>33high</subscript></entry> | ||
| 82 | </row> | ||
| 83 | </tbody> | ||
| 84 | </tgroup> | ||
| 85 | </informaltable> | ||
| 86 | </para> | ||
| 87 | </formalpara> | ||
| 88 | </example> | ||
| 89 | </refsect1> | ||
| 90 | </refentry> | ||
diff --git a/Documentation/DocBook/v4l/pixfmt-yuv420m.xml b/Documentation/DocBook/v4l/pixfmt-yuv420m.xml new file mode 100644 index 000000000000..f5d8f57495c8 --- /dev/null +++ b/Documentation/DocBook/v4l/pixfmt-yuv420m.xml | |||
| @@ -0,0 +1,162 @@ | |||
| 1 | <refentry id="V4L2-PIX-FMT-YUV420M"> | ||
| 2 | <refmeta> | ||
| 3 | <refentrytitle>V4L2_PIX_FMT_YUV420M ('YU12M')</refentrytitle> | ||
| 4 | &manvol; | ||
| 5 | </refmeta> | ||
| 6 | <refnamediv> | ||
| 7 | <refname> <constant>V4L2_PIX_FMT_YUV420M</constant></refname> | ||
| 8 | <refpurpose>Variation of <constant>V4L2_PIX_FMT_YUV420</constant> | ||
| 9 | with planes non contiguous in memory. </refpurpose> | ||
| 10 | </refnamediv> | ||
| 11 | |||
| 12 | <refsect1> | ||
| 13 | <title>Description</title> | ||
| 14 | |||
| 15 | <para>This is a multi-planar format, as opposed to a packed format. | ||
| 16 | The three components are separated into three sub- images or planes. | ||
| 17 | |||
| 18 | The Y plane is first. The Y plane has one byte per pixel. The Cb data | ||
| 19 | constitutes the second plane which is half the width and half | ||
| 20 | the height of the Y plane (and of the image). Each Cb belongs to four | ||
| 21 | pixels, a two-by-two square of the image. For example, | ||
| 22 | Cb<subscript>0</subscript> belongs to Y'<subscript>00</subscript>, | ||
| 23 | Y'<subscript>01</subscript>, Y'<subscript>10</subscript>, and | ||
| 24 | Y'<subscript>11</subscript>. The Cr data, just like the Cb plane, is | ||
| 25 | in the third plane. </para> | ||
| 26 | |||
| 27 | <para>If the Y plane has pad bytes after each row, then the Cb | ||
| 28 | and Cr planes have half as many pad bytes after their rows. In other | ||
| 29 | words, two Cx rows (including padding) is exactly as long as one Y row | ||
| 30 | (including padding).</para> | ||
| 31 | |||
| 32 | <para><constant>V4L2_PIX_FMT_NV12M</constant> is intended to be | ||
| 33 | used only in drivers and applications that support the multi-planar API, | ||
| 34 | described in <xref linkend="planar-apis"/>. </para> | ||
| 35 | |||
| 36 | <example> | ||
| 37 | <title><constant>V4L2_PIX_FMT_YVU420M</constant> 4 × 4 | ||
| 38 | pixel image</title> | ||
| 39 | |||
| 40 | <formalpara> | ||
| 41 | <title>Byte Order.</title> | ||
| 42 | <para>Each cell is one byte. | ||
| 43 | <informaltable frame="none"> | ||
| 44 | <tgroup cols="5" align="center"> | ||
| 45 | <colspec align="left" colwidth="2*" /> | ||
| 46 | <tbody valign="top"> | ||
| 47 | <row> | ||
| 48 | <entry>start0 + 0:</entry> | ||
| 49 | <entry>Y'<subscript>00</subscript></entry> | ||
| 50 | <entry>Y'<subscript>01</subscript></entry> | ||
| 51 | <entry>Y'<subscript>02</subscript></entry> | ||
| 52 | <entry>Y'<subscript>03</subscript></entry> | ||
| 53 | </row> | ||
| 54 | <row> | ||
| 55 | <entry>start0 + 4:</entry> | ||
| 56 | <entry>Y'<subscript>10</subscript></entry> | ||
| 57 | <entry>Y'<subscript>11</subscript></entry> | ||
| 58 | <entry>Y'<subscript>12</subscript></entry> | ||
| 59 | <entry>Y'<subscript>13</subscript></entry> | ||
| 60 | </row> | ||
| 61 | <row> | ||
| 62 | <entry>start0 + 8:</entry> | ||
| 63 | <entry>Y'<subscript>20</subscript></entry> | ||
| 64 | <entry>Y'<subscript>21</subscript></entry> | ||
| 65 | <entry>Y'<subscript>22</subscript></entry> | ||
| 66 | <entry>Y'<subscript>23</subscript></entry> | ||
| 67 | </row> | ||
| 68 | <row> | ||
| 69 | <entry>start0 + 12:</entry> | ||
| 70 | <entry>Y'<subscript>30</subscript></entry> | ||
| 71 | <entry>Y'<subscript>31</subscript></entry> | ||
| 72 | <entry>Y'<subscript>32</subscript></entry> | ||
| 73 | <entry>Y'<subscript>33</subscript></entry> | ||
| 74 | </row> | ||
| 75 | <row><entry></entry></row> | ||
| 76 | <row> | ||
| 77 | <entry>start1 + 0:</entry> | ||
| 78 | <entry>Cb<subscript>00</subscript></entry> | ||
| 79 | <entry>Cb<subscript>01</subscript></entry> | ||
| 80 | </row> | ||
| 81 | <row> | ||
| 82 | <entry>start1 + 2:</entry> | ||
| 83 | <entry>Cb<subscript>10</subscript></entry> | ||
| 84 | <entry>Cb<subscript>11</subscript></entry> | ||
| 85 | </row> | ||
| 86 | <row><entry></entry></row> | ||
| 87 | <row> | ||
| 88 | <entry>start2 + 0:</entry> | ||
| 89 | <entry>Cr<subscript>00</subscript></entry> | ||
| 90 | <entry>Cr<subscript>01</subscript></entry> | ||
| 91 | </row> | ||
| 92 | <row> | ||
| 93 | <entry>start2 + 2:</entry> | ||
| 94 | <entry>Cr<subscript>10</subscript></entry> | ||
| 95 | <entry>Cr<subscript>11</subscript></entry> | ||
| 96 | </row> | ||
| 97 | </tbody> | ||
| 98 | </tgroup> | ||
| 99 | </informaltable> | ||
| 100 | </para> | ||
| 101 | </formalpara> | ||
| 102 | |||
| 103 | <formalpara> | ||
| 104 | <title>Color Sample Location.</title> | ||
| 105 | <para> | ||
| 106 | <informaltable frame="none"> | ||
| 107 | <tgroup cols="7" align="center"> | ||
| 108 | <tbody valign="top"> | ||
| 109 | <row> | ||
| 110 | <entry></entry> | ||
| 111 | <entry>0</entry><entry></entry><entry>1</entry><entry></entry> | ||
| 112 | <entry>2</entry><entry></entry><entry>3</entry> | ||
| 113 | </row> | ||
| 114 | <row> | ||
| 115 | <entry>0</entry> | ||
| 116 | <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> | ||
| 117 | <entry>Y</entry><entry></entry><entry>Y</entry> | ||
| 118 | </row> | ||
| 119 | <row> | ||
| 120 | <entry></entry> | ||
| 121 | <entry></entry><entry>C</entry><entry></entry><entry></entry> | ||
| 122 | <entry></entry><entry>C</entry><entry></entry> | ||
| 123 | </row> | ||
| 124 | <row> | ||
| 125 | <entry>1</entry> | ||
| 126 | <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> | ||
| 127 | <entry>Y</entry><entry></entry><entry>Y</entry> | ||
| 128 | </row> | ||
| 129 | <row> | ||
| 130 | <entry></entry> | ||
| 131 | </row> | ||
| 132 | <row> | ||
| 133 | <entry>2</entry> | ||
| 134 | <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> | ||
| 135 | <entry>Y</entry><entry></entry><entry>Y</entry> | ||
| 136 | </row> | ||
| 137 | <row> | ||
| 138 | <entry></entry> | ||
| 139 | <entry></entry><entry>C</entry><entry></entry><entry></entry> | ||
| 140 | <entry></entry><entry>C</entry><entry></entry> | ||
| 141 | </row> | ||
| 142 | <row> | ||
| 143 | <entry>3</entry> | ||
| 144 | <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> | ||
| 145 | <entry>Y</entry><entry></entry><entry>Y</entry> | ||
| 146 | </row> | ||
| 147 | </tbody> | ||
| 148 | </tgroup> | ||
| 149 | </informaltable> | ||
| 150 | </para> | ||
| 151 | </formalpara> | ||
| 152 | </example> | ||
| 153 | </refsect1> | ||
| 154 | </refentry> | ||
| 155 | |||
| 156 | <!-- | ||
| 157 | Local Variables: | ||
| 158 | mode: sgml | ||
| 159 | sgml-parent-document: "pixfmt.sgml" | ||
| 160 | indent-tabs-mode: nil | ||
| 161 | End: | ||
| 162 | --> | ||
diff --git a/Documentation/DocBook/v4l/pixfmt.xml b/Documentation/DocBook/v4l/pixfmt.xml index cfffc88d7383..c6fdcbbd1b41 100644 --- a/Documentation/DocBook/v4l/pixfmt.xml +++ b/Documentation/DocBook/v4l/pixfmt.xml | |||
| @@ -2,12 +2,16 @@ | |||
| 2 | 2 | ||
| 3 | <para>The V4L2 API was primarily designed for devices exchanging | 3 | <para>The V4L2 API was primarily designed for devices exchanging |
| 4 | image data with applications. The | 4 | image data with applications. The |
| 5 | <structname>v4l2_pix_format</structname> structure defines the format | 5 | <structname>v4l2_pix_format</structname> and <structname>v4l2_pix_format_mplane |
| 6 | and layout of an image in memory. Image formats are negotiated with | 6 | </structname> structures define the format and layout of an image in memory. |
| 7 | the &VIDIOC-S-FMT; ioctl. (The explanations here focus on video | 7 | The former is used with the single-planar API, while the latter is used with the |
| 8 | multi-planar version (see <xref linkend="planar-apis"/>). Image formats are | ||
| 9 | negotiated with the &VIDIOC-S-FMT; ioctl. (The explanations here focus on video | ||
| 8 | capturing and output, for overlay frame buffer formats see also | 10 | capturing and output, for overlay frame buffer formats see also |
| 9 | &VIDIOC-G-FBUF;.)</para> | 11 | &VIDIOC-G-FBUF;.)</para> |
| 10 | 12 | ||
| 13 | <section> | ||
| 14 | <title>Single-planar format structure</title> | ||
| 11 | <table pgwide="1" frame="none" id="v4l2-pix-format"> | 15 | <table pgwide="1" frame="none" id="v4l2-pix-format"> |
| 12 | <title>struct <structname>v4l2_pix_format</structname></title> | 16 | <title>struct <structname>v4l2_pix_format</structname></title> |
| 13 | <tgroup cols="3"> | 17 | <tgroup cols="3"> |
| @@ -106,6 +110,98 @@ set this field to zero.</entry> | |||
| 106 | </tbody> | 110 | </tbody> |
| 107 | </tgroup> | 111 | </tgroup> |
| 108 | </table> | 112 | </table> |
| 113 | </section> | ||
| 114 | |||
| 115 | <section> | ||
| 116 | <title>Multi-planar format structures</title> | ||
| 117 | <para>The <structname>v4l2_plane_pix_format</structname> structures define | ||
| 118 | size and layout for each of the planes in a multi-planar format. | ||
| 119 | The <structname>v4l2_pix_format_mplane</structname> structure contains | ||
| 120 | information common to all planes (such as image width and height) and | ||
| 121 | an array of <structname>v4l2_plane_pix_format</structname> structures, | ||
| 122 | describing all planes of that format.</para> | ||
| 123 | <table pgwide="1" frame="none" id="v4l2-plane-pix-format"> | ||
| 124 | <title>struct <structname>vl42_plane_pix_format</structname></title> | ||
| 125 | <tgroup cols="3"> | ||
| 126 | &cs-str; | ||
| 127 | <tbody valign="top"> | ||
| 128 | <row> | ||
| 129 | <entry>__u32</entry> | ||
| 130 | <entry><structfield>sizeimage</structfield></entry> | ||
| 131 | <entry>Maximum size in bytes required for image data in this plane. | ||
| 132 | </entry> | ||
| 133 | </row> | ||
| 134 | <row> | ||
| 135 | <entry>__u16</entry> | ||
| 136 | <entry><structfield>bytesperline</structfield></entry> | ||
| 137 | <entry>Distance in bytes between the leftmost pixels in two adjacent | ||
| 138 | lines.</entry> | ||
| 139 | </row> | ||
| 140 | <row> | ||
| 141 | <entry>__u16</entry> | ||
| 142 | <entry><structfield>reserved[7]</structfield></entry> | ||
| 143 | <entry>Reserved for future extensions. Should be zeroed by the | ||
| 144 | application.</entry> | ||
| 145 | </row> | ||
| 146 | </tbody> | ||
| 147 | </tgroup> | ||
| 148 | </table> | ||
| 149 | <table pgwide="1" frame="none" id="v4l2-pix-format-mplane"> | ||
| 150 | <title>struct <structname>v4l2_pix_format_mplane</structname></title> | ||
| 151 | <tgroup cols="3"> | ||
| 152 | &cs-str; | ||
| 153 | <tbody valign="top"> | ||
| 154 | <row> | ||
| 155 | <entry>__u32</entry> | ||
| 156 | <entry><structfield>width</structfield></entry> | ||
| 157 | <entry>Image width in pixels.</entry> | ||
| 158 | </row> | ||
| 159 | <row> | ||
| 160 | <entry>__u32</entry> | ||
| 161 | <entry><structfield>height</structfield></entry> | ||
| 162 | <entry>Image height in pixels.</entry> | ||
| 163 | </row> | ||
| 164 | <row> | ||
| 165 | <entry>__u32</entry> | ||
| 166 | <entry><structfield>pixelformat</structfield></entry> | ||
| 167 | <entry>The pixel format. Both single- and multi-planar four character | ||
| 168 | codes can be used.</entry> | ||
| 169 | </row> | ||
| 170 | <row> | ||
| 171 | <entry>&v4l2-field;</entry> | ||
| 172 | <entry><structfield>field</structfield></entry> | ||
| 173 | <entry>See &v4l2-pix-format;.</entry> | ||
| 174 | </row> | ||
| 175 | <row> | ||
| 176 | <entry>&v4l2-colorspace;</entry> | ||
| 177 | <entry><structfield>colorspace</structfield></entry> | ||
| 178 | <entry>See &v4l2-pix-format;.</entry> | ||
| 179 | </row> | ||
| 180 | <row> | ||
| 181 | <entry>&v4l2-plane-pix-format;</entry> | ||
| 182 | <entry><structfield>plane_fmt[VIDEO_MAX_PLANES]</structfield></entry> | ||
| 183 | <entry>An array of structures describing format of each plane this | ||
| 184 | pixel format consists of. The number of valid entries in this array | ||
| 185 | has to be put in the <structfield>num_planes</structfield> | ||
| 186 | field.</entry> | ||
| 187 | </row> | ||
| 188 | <row> | ||
| 189 | <entry>__u8</entry> | ||
| 190 | <entry><structfield>num_planes</structfield></entry> | ||
| 191 | <entry>Number of planes (i.e. separate memory buffers) for this format | ||
| 192 | and the number of valid entries in the | ||
| 193 | <structfield>plane_fmt</structfield> array.</entry> | ||
| 194 | </row> | ||
| 195 | <row> | ||
| 196 | <entry>__u8</entry> | ||
| 197 | <entry><structfield>reserved[11]</structfield></entry> | ||
| 198 | <entry>Reserved for future extensions. Should be zeroed by the | ||
| 199 | application.</entry> | ||
| 200 | </row> | ||
| 201 | </tbody> | ||
| 202 | </tgroup> | ||
| 203 | </table> | ||
| 204 | </section> | ||
| 109 | 205 | ||
| 110 | <section> | 206 | <section> |
| 111 | <title>Standard Image Formats</title> | 207 | <title>Standard Image Formats</title> |
| @@ -142,11 +238,19 @@ leftmost pixel of the second row from the top, and so on. The last row | |||
| 142 | has just as many pad bytes after it as the other rows.</para> | 238 | has just as many pad bytes after it as the other rows.</para> |
| 143 | 239 | ||
| 144 | <para>In V4L2 each format has an identifier which looks like | 240 | <para>In V4L2 each format has an identifier which looks like |
| 145 | <constant>PIX_FMT_XXX</constant>, defined in the <filename>videodev2.h</filename> | 241 | <constant>PIX_FMT_XXX</constant>, defined in the <link |
| 146 | header file. These identifiers | 242 | linkend="videodev">videodev.h</link> header file. These identifiers |
| 147 | represent <link linkend="v4l2-fourcc">four character codes</link> | 243 | represent <link linkend="v4l2-fourcc">four character (FourCC) codes</link> |
| 148 | which are also listed below, however they are not the same as those | 244 | which are also listed below, however they are not the same as those |
| 149 | used in the Windows world.</para> | 245 | used in the Windows world.</para> |
| 246 | |||
| 247 | <para>For some formats, data is stored in separate, discontiguous | ||
| 248 | memory buffers. Those formats are identified by a separate set of FourCC codes | ||
| 249 | and are referred to as "multi-planar formats". For example, a YUV422 frame is | ||
| 250 | normally stored in one memory buffer, but it can also be placed in two or three | ||
| 251 | separate buffers, with Y component in one buffer and CbCr components in another | ||
| 252 | in the 2-planar version or with each component in its own buffer in the | ||
| 253 | 3-planar case. Those sub-buffers are referred to as "planes".</para> | ||
| 150 | </section> | 254 | </section> |
| 151 | 255 | ||
| 152 | <section id="colorspaces"> | 256 | <section id="colorspaces"> |
| @@ -599,10 +703,13 @@ information.</para> | |||
| 599 | &sub-vyuy; | 703 | &sub-vyuy; |
| 600 | &sub-y41p; | 704 | &sub-y41p; |
| 601 | &sub-yuv420; | 705 | &sub-yuv420; |
| 706 | &sub-yuv420m; | ||
| 602 | &sub-yuv410; | 707 | &sub-yuv410; |
| 603 | &sub-yuv422p; | 708 | &sub-yuv422p; |
| 604 | &sub-yuv411p; | 709 | &sub-yuv411p; |
| 605 | &sub-nv12; | 710 | &sub-nv12; |
| 711 | &sub-nv12m; | ||
| 712 | &sub-nv12mt; | ||
| 606 | &sub-nv16; | 713 | &sub-nv16; |
| 607 | </section> | 714 | </section> |
| 608 | 715 | ||
diff --git a/Documentation/DocBook/v4l/planar-apis.xml b/Documentation/DocBook/v4l/planar-apis.xml new file mode 100644 index 000000000000..878ce2040488 --- /dev/null +++ b/Documentation/DocBook/v4l/planar-apis.xml | |||
| @@ -0,0 +1,62 @@ | |||
| 1 | <section id="planar-apis"> | ||
| 2 | <title>Single- and multi-planar APIs</title> | ||
| 3 | |||
| 4 | <para>Some devices require data for each input or output video frame | ||
| 5 | to be placed in discontiguous memory buffers. In such cases, one | ||
| 6 | video frame has to be addressed using more than one memory address, i.e. one | ||
| 7 | pointer per "plane". A plane is a sub-buffer of the current frame. For | ||
| 8 | examples of such formats see <xref linkend="pixfmt" />.</para> | ||
| 9 | |||
| 10 | <para>Initially, V4L2 API did not support multi-planar buffers and a set of | ||
| 11 | extensions has been introduced to handle them. Those extensions constitute | ||
| 12 | what is being referred to as the "multi-planar API".</para> | ||
| 13 | |||
| 14 | <para>Some of the V4L2 API calls and structures are interpreted differently, | ||
| 15 | depending on whether single- or multi-planar API is being used. An application | ||
| 16 | can choose whether to use one or the other by passing a corresponding buffer | ||
| 17 | type to its ioctl calls. Multi-planar versions of buffer types are suffixed | ||
| 18 | with an `_MPLANE' string. For a list of available multi-planar buffer types | ||
| 19 | see &v4l2-buf-type;. | ||
| 20 | </para> | ||
| 21 | |||
| 22 | <section> | ||
| 23 | <title>Multi-planar formats</title> | ||
| 24 | <para>Multi-planar API introduces new multi-planar formats. Those formats | ||
| 25 | use a separate set of FourCC codes. It is important to distinguish between | ||
| 26 | the multi-planar API and a multi-planar format. Multi-planar API calls can | ||
| 27 | handle all single-planar formats as well (as long as they are passed in | ||
| 28 | multi-planar API structures), while the single-planar API cannot | ||
| 29 | handle multi-planar formats.</para> | ||
| 30 | </section> | ||
| 31 | |||
| 32 | <section> | ||
| 33 | <title>Calls that distinguish between single and multi-planar APIs</title> | ||
| 34 | <variablelist> | ||
| 35 | <varlistentry> | ||
| 36 | <term>&VIDIOC-QUERYCAP;</term> | ||
| 37 | <listitem><para>Two additional multi-planar capabilities are added. They can | ||
| 38 | be set together with non-multi-planar ones for devices that handle | ||
| 39 | both single- and multi-planar formats.</para></listitem> | ||
| 40 | </varlistentry> | ||
| 41 | <varlistentry> | ||
| 42 | <term>&VIDIOC-G-FMT;, &VIDIOC-S-FMT;, &VIDIOC-TRY-FMT;</term> | ||
| 43 | <listitem><para>New structures for describing multi-planar formats are added: | ||
| 44 | &v4l2-pix-format-mplane; and &v4l2-plane-pix-format;. Drivers may | ||
| 45 | define new multi-planar formats, which have distinct FourCC codes from | ||
| 46 | the existing single-planar ones.</para> | ||
| 47 | </listitem> | ||
| 48 | </varlistentry> | ||
| 49 | <varlistentry> | ||
| 50 | <term>&VIDIOC-QBUF;, &VIDIOC-DQBUF;, &VIDIOC-QUERYBUF;</term> | ||
| 51 | <listitem><para>A new &v4l2-plane; structure for describing planes is added. | ||
| 52 | Arrays of this structure are passed in the new | ||
| 53 | <structfield>m.planes</structfield> field of &v4l2-buffer;.</para> | ||
| 54 | </listitem> | ||
| 55 | </varlistentry> | ||
| 56 | <varlistentry> | ||
| 57 | <term>&VIDIOC-REQBUFS;</term> | ||
| 58 | <listitem><para>Will allocate multi-planar buffers as requested.</para></listitem> | ||
| 59 | </varlistentry> | ||
| 60 | </variablelist> | ||
| 61 | </section> | ||
| 62 | </section> | ||
diff --git a/Documentation/DocBook/v4l/remote_controllers.xml b/Documentation/DocBook/v4l/remote_controllers.xml index 3c3b667b28e7..160e464d44b7 100644 --- a/Documentation/DocBook/v4l/remote_controllers.xml +++ b/Documentation/DocBook/v4l/remote_controllers.xml | |||
| @@ -133,7 +133,7 @@ different IR's. Due to that, V4L2 API now specifies a standard for mapping Media | |||
| 133 | <row><entry><constant>KEY_LEFT</constant></entry><entry>Left key</entry><entry>LEFT</entry></row> | 133 | <row><entry><constant>KEY_LEFT</constant></entry><entry>Left key</entry><entry>LEFT</entry></row> |
| 134 | <row><entry><constant>KEY_RIGHT</constant></entry><entry>Right key</entry><entry>RIGHT</entry></row> | 134 | <row><entry><constant>KEY_RIGHT</constant></entry><entry>Right key</entry><entry>RIGHT</entry></row> |
| 135 | 135 | ||
| 136 | <row><entry><emphasis role="bold">Miscelaneous keys</emphasis></entry></row> | 136 | <row><entry><emphasis role="bold">Miscellaneous keys</emphasis></entry></row> |
| 137 | 137 | ||
| 138 | <row><entry><constant>KEY_DOT</constant></entry><entry>Return a dot</entry><entry>.</entry></row> | 138 | <row><entry><constant>KEY_DOT</constant></entry><entry>Return a dot</entry><entry>.</entry></row> |
| 139 | <row><entry><constant>KEY_FN</constant></entry><entry>Select a function</entry><entry>FUNCTION</entry></row> | 139 | <row><entry><constant>KEY_FN</constant></entry><entry>Select a function</entry><entry>FUNCTION</entry></row> |
diff --git a/Documentation/DocBook/v4l/subdev-formats.xml b/Documentation/DocBook/v4l/subdev-formats.xml new file mode 100644 index 000000000000..7041127d6dfc --- /dev/null +++ b/Documentation/DocBook/v4l/subdev-formats.xml | |||
| @@ -0,0 +1,2467 @@ | |||
| 1 | <section id="v4l2-mbus-format"> | ||
| 2 | <title>Media Bus Formats</title> | ||
| 3 | |||
| 4 | <table pgwide="1" frame="none" id="v4l2-mbus-framefmt"> | ||
| 5 | <title>struct <structname>v4l2_mbus_framefmt</structname></title> | ||
| 6 | <tgroup cols="3"> | ||
| 7 | &cs-str; | ||
| 8 | <tbody valign="top"> | ||
| 9 | <row> | ||
| 10 | <entry>__u32</entry> | ||
| 11 | <entry><structfield>width</structfield></entry> | ||
| 12 | <entry>Image width, in pixels.</entry> | ||
| 13 | </row> | ||
| 14 | <row> | ||
| 15 | <entry>__u32</entry> | ||
| 16 | <entry><structfield>height</structfield></entry> | ||
| 17 | <entry>Image height, in pixels.</entry> | ||
| 18 | </row> | ||
| 19 | <row> | ||
| 20 | <entry>__u32</entry> | ||
| 21 | <entry><structfield>code</structfield></entry> | ||
| 22 | <entry>Format code, from &v4l2-mbus-pixelcode;.</entry> | ||
| 23 | </row> | ||
| 24 | <row> | ||
| 25 | <entry>__u32</entry> | ||
| 26 | <entry><structfield>field</structfield></entry> | ||
| 27 | <entry>Field order, from &v4l2-field;. See | ||
| 28 | <xref linkend="field-order" /> for details.</entry> | ||
| 29 | </row> | ||
| 30 | <row> | ||
| 31 | <entry>__u32</entry> | ||
| 32 | <entry><structfield>colorspace</structfield></entry> | ||
| 33 | <entry>Image colorspace, from &v4l2-colorspace;. See | ||
| 34 | <xref linkend="colorspaces" /> for details.</entry> | ||
| 35 | </row> | ||
| 36 | <row> | ||
| 37 | <entry>__u32</entry> | ||
| 38 | <entry><structfield>reserved</structfield>[7]</entry> | ||
| 39 | <entry>Reserved for future extensions. Applications and drivers must | ||
| 40 | set the array to zero.</entry> | ||
| 41 | </row> | ||
| 42 | </tbody> | ||
| 43 | </tgroup> | ||
| 44 | </table> | ||
| 45 | |||
| 46 | <section id="v4l2-mbus-pixelcode"> | ||
| 47 | <title>Media Bus Pixel Codes</title> | ||
| 48 | |||
| 49 | <para>The media bus pixel codes describe image formats as flowing over | ||
| 50 | physical busses (both between separate physical components and inside SoC | ||
| 51 | devices). This should not be confused with the V4L2 pixel formats that | ||
| 52 | describe, using four character codes, image formats as stored in memory. | ||
| 53 | </para> | ||
| 54 | |||
| 55 | <para>While there is a relationship between image formats on busses and | ||
| 56 | image formats in memory (a raw Bayer image won't be magically converted to | ||
| 57 | JPEG just by storing it to memory), there is no one-to-one correspondance | ||
| 58 | between them.</para> | ||
| 59 | |||
| 60 | <section> | ||
| 61 | <title>Packed RGB Formats</title> | ||
| 62 | |||
| 63 | <para>Those formats transfer pixel data as red, green and blue components. | ||
| 64 | The format code is made of the following information. | ||
| 65 | <itemizedlist> | ||
| 66 | <listitem><para>The red, green and blue components order code, as encoded in a | ||
| 67 | pixel sample. Possible values are RGB and BGR.</para></listitem> | ||
| 68 | <listitem><para>The number of bits per component, for each component. The values | ||
| 69 | can be different for all components. Common values are 555 and 565.</para> | ||
| 70 | </listitem> | ||
| 71 | <listitem><para>The number of bus samples per pixel. Pixels that are wider than | ||
| 72 | the bus width must be transferred in multiple samples. Common values are | ||
| 73 | 1 and 2.</para></listitem> | ||
| 74 | <listitem><para>The bus width.</para></listitem> | ||
| 75 | <listitem><para>For formats where the total number of bits per pixel is smaller | ||
| 76 | than the number of bus samples per pixel times the bus width, a padding | ||
| 77 | value stating if the bytes are padded in their most high order bits | ||
| 78 | (PADHI) or low order bits (PADLO).</para></listitem> | ||
| 79 | <listitem><para>For formats where the number of bus samples per pixel is larger | ||
| 80 | than 1, an endianness value stating if the pixel is transferred MSB first | ||
| 81 | (BE) or LSB first (LE).</para></listitem> | ||
| 82 | </itemizedlist> | ||
| 83 | </para> | ||
| 84 | |||
| 85 | <para>For instance, a format where pixels are encoded as 5-bits red, 5-bits | ||
| 86 | green and 5-bit blue values padded on the high bit, transferred as 2 8-bit | ||
| 87 | samples per pixel with the most significant bits (padding, red and half of | ||
| 88 | the green value) transferred first will be named | ||
| 89 | <constant>V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE</constant>. | ||
| 90 | </para> | ||
| 91 | |||
| 92 | <para>The following tables list existing packet RGB formats.</para> | ||
| 93 | |||
| 94 | <table pgwide="0" frame="none" id="v4l2-mbus-pixelcode-rgb"> | ||
| 95 | <title>RGB formats</title> | ||
| 96 | <tgroup cols="11"> | ||
| 97 | <colspec colname="id" align="left" /> | ||
| 98 | <colspec colname="code" align="center"/> | ||
| 99 | <colspec colname="bit" /> | ||
| 100 | <colspec colnum="4" colname="b07" align="center" /> | ||
| 101 | <colspec colnum="5" colname="b06" align="center" /> | ||
| 102 | <colspec colnum="6" colname="b05" align="center" /> | ||
| 103 | <colspec colnum="7" colname="b04" align="center" /> | ||
| 104 | <colspec colnum="8" colname="b03" align="center" /> | ||
| 105 | <colspec colnum="9" colname="b02" align="center" /> | ||
| 106 | <colspec colnum="10" colname="b01" align="center" /> | ||
| 107 | <colspec colnum="11" colname="b00" align="center" /> | ||
| 108 | <spanspec namest="b07" nameend="b00" spanname="b0" /> | ||
| 109 | <thead> | ||
| 110 | <row> | ||
| 111 | <entry>Identifier</entry> | ||
| 112 | <entry>Code</entry> | ||
| 113 | <entry></entry> | ||
| 114 | <entry spanname="b0">Data organization</entry> | ||
| 115 | </row> | ||
| 116 | <row> | ||
| 117 | <entry></entry> | ||
| 118 | <entry></entry> | ||
| 119 | <entry>Bit</entry> | ||
| 120 | <entry>7</entry> | ||
| 121 | <entry>6</entry> | ||
| 122 | <entry>5</entry> | ||
| 123 | <entry>4</entry> | ||
| 124 | <entry>3</entry> | ||
| 125 | <entry>2</entry> | ||
| 126 | <entry>1</entry> | ||
| 127 | <entry>0</entry> | ||
| 128 | </row> | ||
| 129 | </thead> | ||
| 130 | <tbody valign="top"> | ||
| 131 | <row id="V4L2-MBUS-FMT-RGB444-2X8-PADHI-BE"> | ||
| 132 | <entry>V4L2_MBUS_FMT_RGB444_2X8_PADHI_BE</entry> | ||
| 133 | <entry>0x1001</entry> | ||
| 134 | <entry></entry> | ||
| 135 | <entry>0</entry> | ||
| 136 | <entry>0</entry> | ||
| 137 | <entry>0</entry> | ||
| 138 | <entry>0</entry> | ||
| 139 | <entry>r<subscript>3</subscript></entry> | ||
| 140 | <entry>r<subscript>2</subscript></entry> | ||
| 141 | <entry>r<subscript>1</subscript></entry> | ||
| 142 | <entry>r<subscript>0</subscript></entry> | ||
| 143 | </row> | ||
| 144 | <row> | ||
| 145 | <entry></entry> | ||
| 146 | <entry></entry> | ||
| 147 | <entry></entry> | ||
| 148 | <entry>g<subscript>3</subscript></entry> | ||
| 149 | <entry>g<subscript>2</subscript></entry> | ||
| 150 | <entry>g<subscript>1</subscript></entry> | ||
| 151 | <entry>g<subscript>0</subscript></entry> | ||
| 152 | <entry>b<subscript>3</subscript></entry> | ||
| 153 | <entry>b<subscript>2</subscript></entry> | ||
| 154 | <entry>b<subscript>1</subscript></entry> | ||
| 155 | <entry>b<subscript>0</subscript></entry> | ||
| 156 | </row> | ||
| 157 | <row id="V4L2-MBUS-FMT-RGB444-2X8-PADHI-LE"> | ||
| 158 | <entry>V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE</entry> | ||
| 159 | <entry>0x1002</entry> | ||
| 160 | <entry></entry> | ||
| 161 | <entry>g<subscript>3</subscript></entry> | ||
| 162 | <entry>g<subscript>2</subscript></entry> | ||
| 163 | <entry>g<subscript>1</subscript></entry> | ||
| 164 | <entry>g<subscript>0</subscript></entry> | ||
| 165 | <entry>b<subscript>3</subscript></entry> | ||
| 166 | <entry>b<subscript>2</subscript></entry> | ||
| 167 | <entry>b<subscript>1</subscript></entry> | ||
| 168 | <entry>b<subscript>0</subscript></entry> | ||
| 169 | </row> | ||
| 170 | <row> | ||
| 171 | <entry></entry> | ||
| 172 | <entry></entry> | ||
| 173 | <entry></entry> | ||
| 174 | <entry>0</entry> | ||
| 175 | <entry>0</entry> | ||
| 176 | <entry>0</entry> | ||
| 177 | <entry>0</entry> | ||
| 178 | <entry>r<subscript>3</subscript></entry> | ||
| 179 | <entry>r<subscript>2</subscript></entry> | ||
| 180 | <entry>r<subscript>1</subscript></entry> | ||
| 181 | <entry>r<subscript>0</subscript></entry> | ||
| 182 | </row> | ||
| 183 | <row id="V4L2-MBUS-FMT-RGB555-2X8-PADHI-BE"> | ||
| 184 | <entry>V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE</entry> | ||
| 185 | <entry>0x1003</entry> | ||
| 186 | <entry></entry> | ||
| 187 | <entry>0</entry> | ||
| 188 | <entry>r<subscript>4</subscript></entry> | ||
| 189 | <entry>r<subscript>3</subscript></entry> | ||
| 190 | <entry>r<subscript>2</subscript></entry> | ||
| 191 | <entry>r<subscript>1</subscript></entry> | ||
| 192 | <entry>r<subscript>0</subscript></entry> | ||
| 193 | <entry>g<subscript>4</subscript></entry> | ||
| 194 | <entry>g<subscript>3</subscript></entry> | ||
| 195 | </row> | ||
| 196 | <row> | ||
| 197 | <entry></entry> | ||
| 198 | <entry></entry> | ||
| 199 | <entry></entry> | ||
| 200 | <entry>g<subscript>2</subscript></entry> | ||
| 201 | <entry>g<subscript>1</subscript></entry> | ||
| 202 | <entry>g<subscript>0</subscript></entry> | ||
| 203 | <entry>b<subscript>4</subscript></entry> | ||
| 204 | <entry>b<subscript>3</subscript></entry> | ||
| 205 | <entry>b<subscript>2</subscript></entry> | ||
| 206 | <entry>b<subscript>1</subscript></entry> | ||
| 207 | <entry>b<subscript>0</subscript></entry> | ||
| 208 | </row> | ||
| 209 | <row id="V4L2-MBUS-FMT-RGB555-2X8-PADHI-LE"> | ||
| 210 | <entry>V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE</entry> | ||
| 211 | <entry>0x1004</entry> | ||
| 212 | <entry></entry> | ||
| 213 | <entry>g<subscript>2</subscript></entry> | ||
| 214 | <entry>g<subscript>1</subscript></entry> | ||
| 215 | <entry>g<subscript>0</subscript></entry> | ||
| 216 | <entry>b<subscript>4</subscript></entry> | ||
| 217 | <entry>b<subscript>3</subscript></entry> | ||
| 218 | <entry>b<subscript>2</subscript></entry> | ||
| 219 | <entry>b<subscript>1</subscript></entry> | ||
| 220 | <entry>b<subscript>0</subscript></entry> | ||
| 221 | </row> | ||
| 222 | <row> | ||
| 223 | <entry></entry> | ||
| 224 | <entry></entry> | ||
| 225 | <entry></entry> | ||
| 226 | <entry>0</entry> | ||
| 227 | <entry>r<subscript>4</subscript></entry> | ||
| 228 | <entry>r<subscript>3</subscript></entry> | ||
| 229 | <entry>r<subscript>2</subscript></entry> | ||
| 230 | <entry>r<subscript>1</subscript></entry> | ||
| 231 | <entry>r<subscript>0</subscript></entry> | ||
| 232 | <entry>g<subscript>4</subscript></entry> | ||
| 233 | <entry>g<subscript>3</subscript></entry> | ||
| 234 | </row> | ||
| 235 | <row id="V4L2-MBUS-FMT-BGR565-2X8-BE"> | ||
| 236 | <entry>V4L2_MBUS_FMT_BGR565_2X8_BE</entry> | ||
| 237 | <entry>0x1005</entry> | ||
| 238 | <entry></entry> | ||
| 239 | <entry>b<subscript>4</subscript></entry> | ||
| 240 | <entry>b<subscript>3</subscript></entry> | ||
| 241 | <entry>b<subscript>2</subscript></entry> | ||
| 242 | <entry>b<subscript>1</subscript></entry> | ||
| 243 | <entry>b<subscript>0</subscript></entry> | ||
| 244 | <entry>g<subscript>5</subscript></entry> | ||
| 245 | <entry>g<subscript>4</subscript></entry> | ||
| 246 | <entry>g<subscript>3</subscript></entry> | ||
| 247 | </row> | ||
| 248 | <row> | ||
| 249 | <entry></entry> | ||
| 250 | <entry></entry> | ||
| 251 | <entry></entry> | ||
| 252 | <entry>g<subscript>2</subscript></entry> | ||
| 253 | <entry>g<subscript>1</subscript></entry> | ||
| 254 | <entry>g<subscript>0</subscript></entry> | ||
| 255 | <entry>r<subscript>4</subscript></entry> | ||
| 256 | <entry>r<subscript>3</subscript></entry> | ||
| 257 | <entry>r<subscript>2</subscript></entry> | ||
| 258 | <entry>r<subscript>1</subscript></entry> | ||
| 259 | <entry>r<subscript>0</subscript></entry> | ||
| 260 | </row> | ||
| 261 | <row id="V4L2-MBUS-FMT-BGR565-2X8-LE"> | ||
| 262 | <entry>V4L2_MBUS_FMT_BGR565_2X8_LE</entry> | ||
| 263 | <entry>0x1006</entry> | ||
| 264 | <entry></entry> | ||
| 265 | <entry>g<subscript>2</subscript></entry> | ||
| 266 | <entry>g<subscript>1</subscript></entry> | ||
| 267 | <entry>g<subscript>0</subscript></entry> | ||
| 268 | <entry>r<subscript>4</subscript></entry> | ||
| 269 | <entry>r<subscript>3</subscript></entry> | ||
| 270 | <entry>r<subscript>2</subscript></entry> | ||
| 271 | <entry>r<subscript>1</subscript></entry> | ||
| 272 | <entry>r<subscript>0</subscript></entry> | ||
| 273 | </row> | ||
| 274 | <row> | ||
| 275 | <entry></entry> | ||
| 276 | <entry></entry> | ||
| 277 | <entry></entry> | ||
| 278 | <entry>b<subscript>4</subscript></entry> | ||
| 279 | <entry>b<subscript>3</subscript></entry> | ||
| 280 | <entry>b<subscript>2</subscript></entry> | ||
| 281 | <entry>b<subscript>1</subscript></entry> | ||
| 282 | <entry>b<subscript>0</subscript></entry> | ||
| 283 | <entry>g<subscript>5</subscript></entry> | ||
| 284 | <entry>g<subscript>4</subscript></entry> | ||
| 285 | <entry>g<subscript>3</subscript></entry> | ||
| 286 | </row> | ||
| 287 | <row id="V4L2-MBUS-FMT-RGB565-2X8-BE"> | ||
| 288 | <entry>V4L2_MBUS_FMT_RGB565_2X8_BE</entry> | ||
| 289 | <entry>0x1007</entry> | ||
| 290 | <entry></entry> | ||
| 291 | <entry>r<subscript>4</subscript></entry> | ||
| 292 | <entry>r<subscript>3</subscript></entry> | ||
| 293 | <entry>r<subscript>2</subscript></entry> | ||
| 294 | <entry>r<subscript>1</subscript></entry> | ||
| 295 | <entry>r<subscript>0</subscript></entry> | ||
| 296 | <entry>g<subscript>5</subscript></entry> | ||
| 297 | <entry>g<subscript>4</subscript></entry> | ||
| 298 | <entry>g<subscript>3</subscript></entry> | ||
| 299 | </row> | ||
| 300 | <row> | ||
| 301 | <entry></entry> | ||
| 302 | <entry></entry> | ||
| 303 | <entry></entry> | ||
| 304 | <entry>g<subscript>2</subscript></entry> | ||
| 305 | <entry>g<subscript>1</subscript></entry> | ||
| 306 | <entry>g<subscript>0</subscript></entry> | ||
| 307 | <entry>b<subscript>4</subscript></entry> | ||
| 308 | <entry>b<subscript>3</subscript></entry> | ||
| 309 | <entry>b<subscript>2</subscript></entry> | ||
| 310 | <entry>b<subscript>1</subscript></entry> | ||
| 311 | <entry>b<subscript>0</subscript></entry> | ||
| 312 | </row> | ||
| 313 | <row id="V4L2-MBUS-FMT-RGB565-2X8-LE"> | ||
| 314 | <entry>V4L2_MBUS_FMT_RGB565_2X8_LE</entry> | ||
| 315 | <entry>0x1008</entry> | ||
| 316 | <entry></entry> | ||
| 317 | <entry>g<subscript>2</subscript></entry> | ||
| 318 | <entry>g<subscript>1</subscript></entry> | ||
| 319 | <entry>g<subscript>0</subscript></entry> | ||
| 320 | <entry>b<subscript>4</subscript></entry> | ||
| 321 | <entry>b<subscript>3</subscript></entry> | ||
| 322 | <entry>b<subscript>2</subscript></entry> | ||
| 323 | <entry>b<subscript>1</subscript></entry> | ||
| 324 | <entry>b<subscript>0</subscript></entry> | ||
| 325 | </row> | ||
| 326 | <row> | ||
| 327 | <entry></entry> | ||
| 328 | <entry></entry> | ||
| 329 | <entry></entry> | ||
| 330 | <entry>r<subscript>4</subscript></entry> | ||
| 331 | <entry>r<subscript>3</subscript></entry> | ||
| 332 | <entry>r<subscript>2</subscript></entry> | ||
| 333 | <entry>r<subscript>1</subscript></entry> | ||
| 334 | <entry>r<subscript>0</subscript></entry> | ||
| 335 | <entry>g<subscript>5</subscript></entry> | ||
| 336 | <entry>g<subscript>4</subscript></entry> | ||
| 337 | <entry>g<subscript>3</subscript></entry> | ||
| 338 | </row> | ||
| 339 | </tbody> | ||
| 340 | </tgroup> | ||
| 341 | </table> | ||
| 342 | </section> | ||
| 343 | |||
| 344 | <section> | ||
| 345 | <title>Bayer Formats</title> | ||
| 346 | |||
| 347 | <para>Those formats transfer pixel data as red, green and blue components. | ||
| 348 | The format code is made of the following information. | ||
| 349 | <itemizedlist> | ||
| 350 | <listitem><para>The red, green and blue components order code, as encoded in a | ||
| 351 | pixel sample. The possible values are shown in <xref | ||
| 352 | linkend="bayer-patterns" />.</para></listitem> | ||
| 353 | <listitem><para>The number of bits per pixel component. All components are | ||
| 354 | transferred on the same number of bits. Common values are 8, 10 and 12.</para> | ||
| 355 | </listitem> | ||
| 356 | <listitem><para>If the pixel components are DPCM-compressed, a mention of the | ||
| 357 | DPCM compression and the number of bits per compressed pixel component.</para> | ||
| 358 | </listitem> | ||
| 359 | <listitem><para>The number of bus samples per pixel. Pixels that are wider than | ||
| 360 | the bus width must be transferred in multiple samples. Common values are | ||
| 361 | 1 and 2.</para></listitem> | ||
| 362 | <listitem><para>The bus width.</para></listitem> | ||
| 363 | <listitem><para>For formats where the total number of bits per pixel is smaller | ||
| 364 | than the number of bus samples per pixel times the bus width, a padding | ||
| 365 | value stating if the bytes are padded in their most high order bits | ||
| 366 | (PADHI) or low order bits (PADLO).</para></listitem> | ||
| 367 | <listitem><para>For formats where the number of bus samples per pixel is larger | ||
| 368 | than 1, an endianness value stating if the pixel is transferred MSB first | ||
| 369 | (BE) or LSB first (LE).</para></listitem> | ||
| 370 | </itemizedlist> | ||
| 371 | </para> | ||
| 372 | |||
| 373 | <para>For instance, a format with uncompressed 10-bit Bayer components | ||
| 374 | arranged in a red, green, green, blue pattern transferred as 2 8-bit | ||
| 375 | samples per pixel with the least significant bits transferred first will | ||
| 376 | be named <constant>V4L2_MBUS_FMT_SRGGB10_2X8_PADHI_LE</constant>. | ||
| 377 | </para> | ||
| 378 | |||
| 379 | <figure id="bayer-patterns"> | ||
| 380 | <title>Bayer Patterns</title> | ||
| 381 | <mediaobject> | ||
| 382 | <imageobject> | ||
| 383 | <imagedata fileref="bayer.pdf" format="PS" /> | ||
| 384 | </imageobject> | ||
| 385 | <imageobject> | ||
| 386 | <imagedata fileref="bayer.png" format="PNG" /> | ||
| 387 | </imageobject> | ||
| 388 | <textobject> | ||
| 389 | <phrase>Bayer filter color patterns</phrase> | ||
| 390 | </textobject> | ||
| 391 | </mediaobject> | ||
| 392 | </figure> | ||
| 393 | |||
| 394 | <para>The following table lists existing packet Bayer formats. The data | ||
| 395 | organization is given as an example for the first pixel only.</para> | ||
| 396 | |||
| 397 | <table pgwide="0" frame="none" id="v4l2-mbus-pixelcode-bayer"> | ||
| 398 | <title>Bayer Formats</title> | ||
| 399 | <tgroup cols="15"> | ||
| 400 | <colspec colname="id" align="left" /> | ||
| 401 | <colspec colname="code" align="center"/> | ||
| 402 | <colspec colname="bit" /> | ||
| 403 | <colspec colnum="4" colname="b11" align="center" /> | ||
| 404 | <colspec colnum="5" colname="b10" align="center" /> | ||
| 405 | <colspec colnum="6" colname="b09" align="center" /> | ||
| 406 | <colspec colnum="7" colname="b08" align="center" /> | ||
| 407 | <colspec colnum="8" colname="b07" align="center" /> | ||
| 408 | <colspec colnum="9" colname="b06" align="center" /> | ||
| 409 | <colspec colnum="10" colname="b05" align="center" /> | ||
| 410 | <colspec colnum="11" colname="b04" align="center" /> | ||
| 411 | <colspec colnum="12" colname="b03" align="center" /> | ||
| 412 | <colspec colnum="13" colname="b02" align="center" /> | ||
| 413 | <colspec colnum="14" colname="b01" align="center" /> | ||
| 414 | <colspec colnum="15" colname="b00" align="center" /> | ||
| 415 | <spanspec namest="b11" nameend="b00" spanname="b0" /> | ||
| 416 | <thead> | ||
| 417 | <row> | ||
| 418 | <entry>Identifier</entry> | ||
| 419 | <entry>Code</entry> | ||
| 420 | <entry></entry> | ||
| 421 | <entry spanname="b0">Data organization</entry> | ||
| 422 | </row> | ||
| 423 | <row> | ||
| 424 | <entry></entry> | ||
| 425 | <entry></entry> | ||
| 426 | <entry>Bit</entry> | ||
| 427 | <entry>11</entry> | ||
| 428 | <entry>10</entry> | ||
| 429 | <entry>9</entry> | ||
| 430 | <entry>8</entry> | ||
| 431 | <entry>7</entry> | ||
| 432 | <entry>6</entry> | ||
| 433 | <entry>5</entry> | ||
| 434 | <entry>4</entry> | ||
| 435 | <entry>3</entry> | ||
| 436 | <entry>2</entry> | ||
| 437 | <entry>1</entry> | ||
| 438 | <entry>0</entry> | ||
| 439 | </row> | ||
| 440 | </thead> | ||
| 441 | <tbody valign="top"> | ||
| 442 | <row id="V4L2-MBUS-FMT-SBGGR8-1X8"> | ||
| 443 | <entry>V4L2_MBUS_FMT_SBGGR8_1X8</entry> | ||
| 444 | <entry>0x3001</entry> | ||
| 445 | <entry></entry> | ||
| 446 | <entry>-</entry> | ||
| 447 | <entry>-</entry> | ||
| 448 | <entry>-</entry> | ||
| 449 | <entry>-</entry> | ||
| 450 | <entry>b<subscript>7</subscript></entry> | ||
| 451 | <entry>b<subscript>6</subscript></entry> | ||
| 452 | <entry>b<subscript>5</subscript></entry> | ||
| 453 | <entry>b<subscript>4</subscript></entry> | ||
| 454 | <entry>b<subscript>3</subscript></entry> | ||
| 455 | <entry>b<subscript>2</subscript></entry> | ||
| 456 | <entry>b<subscript>1</subscript></entry> | ||
| 457 | <entry>b<subscript>0</subscript></entry> | ||
| 458 | </row> | ||
| 459 | <row id="V4L2-MBUS-FMT-SGRBG8-1X8"> | ||
| 460 | <entry>V4L2_MBUS_FMT_SGRBG8_1X8</entry> | ||
| 461 | <entry>0x3002</entry> | ||
| 462 | <entry></entry> | ||
| 463 | <entry>-</entry> | ||
| 464 | <entry>-</entry> | ||
| 465 | <entry>-</entry> | ||
| 466 | <entry>-</entry> | ||
| 467 | <entry>g<subscript>7</subscript></entry> | ||
| 468 | <entry>g<subscript>6</subscript></entry> | ||
| 469 | <entry>g<subscript>5</subscript></entry> | ||
| 470 | <entry>g<subscript>4</subscript></entry> | ||
| 471 | <entry>g<subscript>3</subscript></entry> | ||
| 472 | <entry>g<subscript>2</subscript></entry> | ||
| 473 | <entry>g<subscript>1</subscript></entry> | ||
| 474 | <entry>g<subscript>0</subscript></entry> | ||
| 475 | </row> | ||
| 476 | <row id="V4L2-MBUS-FMT-SBGGR10-DPCM8-1X8"> | ||
| 477 | <entry>V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8</entry> | ||
| 478 | <entry>0x300b</entry> | ||
| 479 | <entry></entry> | ||
| 480 | <entry>-</entry> | ||
| 481 | <entry>-</entry> | ||
| 482 | <entry>-</entry> | ||
| 483 | <entry>-</entry> | ||
| 484 | <entry>b<subscript>7</subscript></entry> | ||
| 485 | <entry>b<subscript>6</subscript></entry> | ||
| 486 | <entry>b<subscript>5</subscript></entry> | ||
| 487 | <entry>b<subscript>4</subscript></entry> | ||
| 488 | <entry>b<subscript>3</subscript></entry> | ||
| 489 | <entry>b<subscript>2</subscript></entry> | ||
| 490 | <entry>b<subscript>1</subscript></entry> | ||
| 491 | <entry>b<subscript>0</subscript></entry> | ||
| 492 | </row> | ||
| 493 | <row id="V4L2-MBUS-FMT-SGBRG10-DPCM8-1X8"> | ||
| 494 | <entry>V4L2_MBUS_FMT_SGBRG10_DPCM8_1X8</entry> | ||
| 495 | <entry>0x300c</entry> | ||
| 496 | <entry></entry> | ||
| 497 | <entry>-</entry> | ||
| 498 | <entry>-</entry> | ||
| 499 | <entry>-</entry> | ||
| 500 | <entry>-</entry> | ||
| 501 | <entry>g<subscript>7</subscript></entry> | ||
| 502 | <entry>g<subscript>6</subscript></entry> | ||
| 503 | <entry>g<subscript>5</subscript></entry> | ||
| 504 | <entry>g<subscript>4</subscript></entry> | ||
| 505 | <entry>g<subscript>3</subscript></entry> | ||
| 506 | <entry>g<subscript>2</subscript></entry> | ||
| 507 | <entry>g<subscript>1</subscript></entry> | ||
| 508 | <entry>g<subscript>0</subscript></entry> | ||
| 509 | </row> | ||
| 510 | <row id="V4L2-MBUS-FMT-SGRBG10-DPCM8-1X8"> | ||
| 511 | <entry>V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8</entry> | ||
| 512 | <entry>0x3009</entry> | ||
| 513 | <entry></entry> | ||
| 514 | <entry>-</entry> | ||
| 515 | <entry>-</entry> | ||
| 516 | <entry>-</entry> | ||
| 517 | <entry>-</entry> | ||
| 518 | <entry>g<subscript>7</subscript></entry> | ||
| 519 | <entry>g<subscript>6</subscript></entry> | ||
| 520 | <entry>g<subscript>5</subscript></entry> | ||
| 521 | <entry>g<subscript>4</subscript></entry> | ||
| 522 | <entry>g<subscript>3</subscript></entry> | ||
| 523 | <entry>g<subscript>2</subscript></entry> | ||
| 524 | <entry>g<subscript>1</subscript></entry> | ||
| 525 | <entry>g<subscript>0</subscript></entry> | ||
| 526 | </row> | ||
| 527 | <row id="V4L2-MBUS-FMT-SRGGB10-DPCM8-1X8"> | ||
| 528 | <entry>V4L2_MBUS_FMT_SRGGB10_DPCM8_1X8</entry> | ||
| 529 | <entry>0x300d</entry> | ||
| 530 | <entry></entry> | ||
| 531 | <entry>-</entry> | ||
| 532 | <entry>-</entry> | ||
| 533 | <entry>-</entry> | ||
| 534 | <entry>-</entry> | ||
| 535 | <entry>r<subscript>7</subscript></entry> | ||
| 536 | <entry>r<subscript>6</subscript></entry> | ||
| 537 | <entry>r<subscript>5</subscript></entry> | ||
| 538 | <entry>r<subscript>4</subscript></entry> | ||
| 539 | <entry>r<subscript>3</subscript></entry> | ||
| 540 | <entry>r<subscript>2</subscript></entry> | ||
| 541 | <entry>r<subscript>1</subscript></entry> | ||
| 542 | <entry>r<subscript>0</subscript></entry> | ||
| 543 | </row> | ||
| 544 | <row id="V4L2-MBUS-FMT-SBGGR10-2X8-PADHI-BE"> | ||
| 545 | <entry>V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE</entry> | ||
| 546 | <entry>0x3003</entry> | ||
| 547 | <entry></entry> | ||
| 548 | <entry>-</entry> | ||
| 549 | <entry>-</entry> | ||
| 550 | <entry>-</entry> | ||
| 551 | <entry>-</entry> | ||
| 552 | <entry>0</entry> | ||
| 553 | <entry>0</entry> | ||
| 554 | <entry>0</entry> | ||
| 555 | <entry>0</entry> | ||
| 556 | <entry>0</entry> | ||
| 557 | <entry>0</entry> | ||
| 558 | <entry>b<subscript>9</subscript></entry> | ||
| 559 | <entry>b<subscript>8</subscript></entry> | ||
| 560 | </row> | ||
| 561 | <row> | ||
| 562 | <entry></entry> | ||
| 563 | <entry></entry> | ||
| 564 | <entry></entry> | ||
| 565 | <entry>-</entry> | ||
| 566 | <entry>-</entry> | ||
| 567 | <entry>-</entry> | ||
| 568 | <entry>-</entry> | ||
| 569 | <entry>b<subscript>7</subscript></entry> | ||
| 570 | <entry>b<subscript>6</subscript></entry> | ||
| 571 | <entry>b<subscript>5</subscript></entry> | ||
| 572 | <entry>b<subscript>4</subscript></entry> | ||
| 573 | <entry>b<subscript>3</subscript></entry> | ||
| 574 | <entry>b<subscript>2</subscript></entry> | ||
| 575 | <entry>b<subscript>1</subscript></entry> | ||
| 576 | <entry>b<subscript>0</subscript></entry> | ||
| 577 | </row> | ||
| 578 | <row id="V4L2-MBUS-FMT-SBGGR10-2X8-PADHI-LE"> | ||
| 579 | <entry>V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE</entry> | ||
| 580 | <entry>0x3004</entry> | ||
| 581 | <entry></entry> | ||
| 582 | <entry>-</entry> | ||
| 583 | <entry>-</entry> | ||
| 584 | <entry>-</entry> | ||
| 585 | <entry>-</entry> | ||
| 586 | <entry>b<subscript>7</subscript></entry> | ||
| 587 | <entry>b<subscript>6</subscript></entry> | ||
| 588 | <entry>b<subscript>5</subscript></entry> | ||
| 589 | <entry>b<subscript>4</subscript></entry> | ||
| 590 | <entry>b<subscript>3</subscript></entry> | ||
| 591 | <entry>b<subscript>2</subscript></entry> | ||
| 592 | <entry>b<subscript>1</subscript></entry> | ||
| 593 | <entry>b<subscript>0</subscript></entry> | ||
| 594 | </row> | ||
| 595 | <row> | ||
| 596 | <entry></entry> | ||
| 597 | <entry></entry> | ||
| 598 | <entry></entry> | ||
| 599 | <entry>-</entry> | ||
| 600 | <entry>-</entry> | ||
| 601 | <entry>-</entry> | ||
| 602 | <entry>-</entry> | ||
| 603 | <entry>0</entry> | ||
| 604 | <entry>0</entry> | ||
| 605 | <entry>0</entry> | ||
| 606 | <entry>0</entry> | ||
| 607 | <entry>0</entry> | ||
| 608 | <entry>0</entry> | ||
| 609 | <entry>b<subscript>9</subscript></entry> | ||
| 610 | <entry>b<subscript>8</subscript></entry> | ||
| 611 | </row> | ||
| 612 | <row id="V4L2-MBUS-FMT-SBGGR10-2X8-PADLO-BE"> | ||
| 613 | <entry>V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE</entry> | ||
| 614 | <entry>0x3005</entry> | ||
| 615 | <entry></entry> | ||
| 616 | <entry>-</entry> | ||
| 617 | <entry>-</entry> | ||
| 618 | <entry>-</entry> | ||
| 619 | <entry>-</entry> | ||
| 620 | <entry>b<subscript>9</subscript></entry> | ||
| 621 | <entry>b<subscript>8</subscript></entry> | ||
| 622 | <entry>b<subscript>7</subscript></entry> | ||
| 623 | <entry>b<subscript>6</subscript></entry> | ||
| 624 | <entry>b<subscript>5</subscript></entry> | ||
| 625 | <entry>b<subscript>4</subscript></entry> | ||
| 626 | <entry>b<subscript>3</subscript></entry> | ||
| 627 | <entry>b<subscript>2</subscript></entry> | ||
| 628 | </row> | ||
| 629 | <row> | ||
| 630 | <entry></entry> | ||
| 631 | <entry></entry> | ||
| 632 | <entry></entry> | ||
| 633 | <entry>-</entry> | ||
| 634 | <entry>-</entry> | ||
| 635 | <entry>-</entry> | ||
| 636 | <entry>-</entry> | ||
| 637 | <entry>b<subscript>1</subscript></entry> | ||
| 638 | <entry>b<subscript>0</subscript></entry> | ||
| 639 | <entry>0</entry> | ||
| 640 | <entry>0</entry> | ||
| 641 | <entry>0</entry> | ||
| 642 | <entry>0</entry> | ||
| 643 | <entry>0</entry> | ||
| 644 | <entry>0</entry> | ||
| 645 | </row> | ||
| 646 | <row id="V4L2-MBUS-FMT-SBGGR10-2X8-PADLO-LE"> | ||
| 647 | <entry>V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE</entry> | ||
| 648 | <entry>0x3006</entry> | ||
| 649 | <entry></entry> | ||
| 650 | <entry>-</entry> | ||
| 651 | <entry>-</entry> | ||
| 652 | <entry>-</entry> | ||
| 653 | <entry>-</entry> | ||
| 654 | <entry>b<subscript>1</subscript></entry> | ||
| 655 | <entry>b<subscript>0</subscript></entry> | ||
| 656 | <entry>0</entry> | ||
| 657 | <entry>0</entry> | ||
| 658 | <entry>0</entry> | ||
| 659 | <entry>0</entry> | ||
| 660 | <entry>0</entry> | ||
| 661 | <entry>0</entry> | ||
| 662 | </row> | ||
| 663 | <row> | ||
| 664 | <entry></entry> | ||
| 665 | <entry></entry> | ||
| 666 | <entry></entry> | ||
| 667 | <entry>-</entry> | ||
| 668 | <entry>-</entry> | ||
| 669 | <entry>-</entry> | ||
| 670 | <entry>-</entry> | ||
| 671 | <entry>b<subscript>9</subscript></entry> | ||
| 672 | <entry>b<subscript>8</subscript></entry> | ||
| 673 | <entry>b<subscript>7</subscript></entry> | ||
| 674 | <entry>b<subscript>6</subscript></entry> | ||
| 675 | <entry>b<subscript>5</subscript></entry> | ||
| 676 | <entry>b<subscript>4</subscript></entry> | ||
| 677 | <entry>b<subscript>3</subscript></entry> | ||
| 678 | <entry>b<subscript>2</subscript></entry> | ||
| 679 | </row> | ||
| 680 | <row id="V4L2-MBUS-FMT-SBGGR10-1X10"> | ||
| 681 | <entry>V4L2_MBUS_FMT_SBGGR10_1X10</entry> | ||
| 682 | <entry>0x3007</entry> | ||
| 683 | <entry></entry> | ||
| 684 | <entry>-</entry> | ||
| 685 | <entry>-</entry> | ||
| 686 | <entry>b<subscript>9</subscript></entry> | ||
| 687 | <entry>b<subscript>8</subscript></entry> | ||
| 688 | <entry>b<subscript>7</subscript></entry> | ||
| 689 | <entry>b<subscript>6</subscript></entry> | ||
| 690 | <entry>b<subscript>5</subscript></entry> | ||
| 691 | <entry>b<subscript>4</subscript></entry> | ||
| 692 | <entry>b<subscript>3</subscript></entry> | ||
| 693 | <entry>b<subscript>2</subscript></entry> | ||
| 694 | <entry>b<subscript>1</subscript></entry> | ||
| 695 | <entry>b<subscript>0</subscript></entry> | ||
| 696 | </row> | ||
| 697 | <row id="V4L2-MBUS-FMT-SGBRG10-1X10"> | ||
| 698 | <entry>V4L2_MBUS_FMT_SGBRG10_1X10</entry> | ||
| 699 | <entry>0x300e</entry> | ||
| 700 | <entry></entry> | ||
| 701 | <entry>-</entry> | ||
| 702 | <entry>-</entry> | ||
| 703 | <entry>g<subscript>9</subscript></entry> | ||
| 704 | <entry>g<subscript>8</subscript></entry> | ||
| 705 | <entry>g<subscript>7</subscript></entry> | ||
| 706 | <entry>g<subscript>6</subscript></entry> | ||
| 707 | <entry>g<subscript>5</subscript></entry> | ||
| 708 | <entry>g<subscript>4</subscript></entry> | ||
| 709 | <entry>g<subscript>3</subscript></entry> | ||
| 710 | <entry>g<subscript>2</subscript></entry> | ||
| 711 | <entry>g<subscript>1</subscript></entry> | ||
| 712 | <entry>g<subscript>0</subscript></entry> | ||
| 713 | </row> | ||
| 714 | <row id="V4L2-MBUS-FMT-SGRBG10-1X10"> | ||
| 715 | <entry>V4L2_MBUS_FMT_SGRBG10_1X10</entry> | ||
| 716 | <entry>0x300a</entry> | ||
| 717 | <entry></entry> | ||
| 718 | <entry>-</entry> | ||
| 719 | <entry>-</entry> | ||
| 720 | <entry>g<subscript>9</subscript></entry> | ||
| 721 | <entry>g<subscript>8</subscript></entry> | ||
| 722 | <entry>g<subscript>7</subscript></entry> | ||
| 723 | <entry>g<subscript>6</subscript></entry> | ||
| 724 | <entry>g<subscript>5</subscript></entry> | ||
| 725 | <entry>g<subscript>4</subscript></entry> | ||
| 726 | <entry>g<subscript>3</subscript></entry> | ||
| 727 | <entry>g<subscript>2</subscript></entry> | ||
| 728 | <entry>g<subscript>1</subscript></entry> | ||
| 729 | <entry>g<subscript>0</subscript></entry> | ||
| 730 | </row> | ||
| 731 | <row id="V4L2-MBUS-FMT-SRGGB10-1X10"> | ||
| 732 | <entry>V4L2_MBUS_FMT_SRGGB10_1X10</entry> | ||
| 733 | <entry>0x300f</entry> | ||
| 734 | <entry></entry> | ||
| 735 | <entry>-</entry> | ||
| 736 | <entry>-</entry> | ||
| 737 | <entry>r<subscript>9</subscript></entry> | ||
| 738 | <entry>r<subscript>8</subscript></entry> | ||
| 739 | <entry>r<subscript>7</subscript></entry> | ||
| 740 | <entry>r<subscript>6</subscript></entry> | ||
| 741 | <entry>r<subscript>5</subscript></entry> | ||
| 742 | <entry>r<subscript>4</subscript></entry> | ||
| 743 | <entry>r<subscript>3</subscript></entry> | ||
| 744 | <entry>r<subscript>2</subscript></entry> | ||
| 745 | <entry>r<subscript>1</subscript></entry> | ||
| 746 | <entry>r<subscript>0</subscript></entry> | ||
| 747 | </row> | ||
| 748 | <row id="V4L2-MBUS-FMT-SBGGR12-1X12"> | ||
| 749 | <entry>V4L2_MBUS_FMT_SBGGR12_1X12</entry> | ||
| 750 | <entry>0x3008</entry> | ||
| 751 | <entry></entry> | ||
| 752 | <entry>b<subscript>11</subscript></entry> | ||
| 753 | <entry>b<subscript>10</subscript></entry> | ||
| 754 | <entry>b<subscript>9</subscript></entry> | ||
| 755 | <entry>b<subscript>8</subscript></entry> | ||
| 756 | <entry>b<subscript>7</subscript></entry> | ||
| 757 | <entry>b<subscript>6</subscript></entry> | ||
| 758 | <entry>b<subscript>5</subscript></entry> | ||
| 759 | <entry>b<subscript>4</subscript></entry> | ||
| 760 | <entry>b<subscript>3</subscript></entry> | ||
| 761 | <entry>b<subscript>2</subscript></entry> | ||
| 762 | <entry>b<subscript>1</subscript></entry> | ||
| 763 | <entry>b<subscript>0</subscript></entry> | ||
| 764 | </row> | ||
| 765 | <row id="V4L2-MBUS-FMT-SGBRG12-1X12"> | ||
| 766 | <entry>V4L2_MBUS_FMT_SGBRG12_1X12</entry> | ||
| 767 | <entry>0x3010</entry> | ||
| 768 | <entry></entry> | ||
| 769 | <entry>g<subscript>11</subscript></entry> | ||
| 770 | <entry>g<subscript>10</subscript></entry> | ||
| 771 | <entry>g<subscript>9</subscript></entry> | ||
| 772 | <entry>g<subscript>8</subscript></entry> | ||
| 773 | <entry>g<subscript>7</subscript></entry> | ||
| 774 | <entry>g<subscript>6</subscript></entry> | ||
| 775 | <entry>g<subscript>5</subscript></entry> | ||
| 776 | <entry>g<subscript>4</subscript></entry> | ||
| 777 | <entry>g<subscript>3</subscript></entry> | ||
| 778 | <entry>g<subscript>2</subscript></entry> | ||
| 779 | <entry>g<subscript>1</subscript></entry> | ||
| 780 | <entry>g<subscript>0</subscript></entry> | ||
| 781 | </row> | ||
| 782 | <row id="V4L2-MBUS-FMT-SGRBG12-1X12"> | ||
| 783 | <entry>V4L2_MBUS_FMT_SGRBG12_1X12</entry> | ||
| 784 | <entry>0x3011</entry> | ||
| 785 | <entry></entry> | ||
| 786 | <entry>g<subscript>11</subscript></entry> | ||
| 787 | <entry>g<subscript>10</subscript></entry> | ||
| 788 | <entry>g<subscript>9</subscript></entry> | ||
| 789 | <entry>g<subscript>8</subscript></entry> | ||
| 790 | <entry>g<subscript>7</subscript></entry> | ||
| 791 | <entry>g<subscript>6</subscript></entry> | ||
| 792 | <entry>g<subscript>5</subscript></entry> | ||
| 793 | <entry>g<subscript>4</subscript></entry> | ||
| 794 | <entry>g<subscript>3</subscript></entry> | ||
| 795 | <entry>g<subscript>2</subscript></entry> | ||
| 796 | <entry>g<subscript>1</subscript></entry> | ||
| 797 | <entry>g<subscript>0</subscript></entry> | ||
| 798 | </row> | ||
| 799 | <row id="V4L2-MBUS-FMT-SRGGB12-1X12"> | ||
| 800 | <entry>V4L2_MBUS_FMT_SRGGB12_1X12</entry> | ||
| 801 | <entry>0x3012</entry> | ||
| 802 | <entry></entry> | ||
| 803 | <entry>r<subscript>11</subscript></entry> | ||
| 804 | <entry>r<subscript>10</subscript></entry> | ||
| 805 | <entry>r<subscript>9</subscript></entry> | ||
| 806 | <entry>r<subscript>8</subscript></entry> | ||
| 807 | <entry>r<subscript>7</subscript></entry> | ||
| 808 | <entry>r<subscript>6</subscript></entry> | ||
| 809 | <entry>r<subscript>5</subscript></entry> | ||
| 810 | <entry>r<subscript>4</subscript></entry> | ||
| 811 | <entry>r<subscript>3</subscript></entry> | ||
| 812 | <entry>r<subscript>2</subscript></entry> | ||
| 813 | <entry>r<subscript>1</subscript></entry> | ||
| 814 | <entry>r<subscript>0</subscript></entry> | ||
| 815 | </row> | ||
| 816 | </tbody> | ||
| 817 | </tgroup> | ||
| 818 | </table> | ||
| 819 | </section> | ||
| 820 | |||
| 821 | <section> | ||
| 822 | <title>Packed YUV Formats</title> | ||
| 823 | |||
| 824 | <para>Those data formats transfer pixel data as (possibly downsampled) Y, U | ||
| 825 | and V components. The format code is made of the following information. | ||
| 826 | <itemizedlist> | ||
| 827 | <listitem><para>The Y, U and V components order code, as transferred on the | ||
| 828 | bus. Possible values are YUYV, UYVY, YVYU and VYUY.</para></listitem> | ||
| 829 | <listitem><para>The number of bits per pixel component. All components are | ||
| 830 | transferred on the same number of bits. Common values are 8, 10 and 12.</para> | ||
| 831 | </listitem> | ||
| 832 | <listitem><para>The number of bus samples per pixel. Pixels that are wider than | ||
| 833 | the bus width must be transferred in multiple samples. Common values are | ||
| 834 | 1, 1.5 (encoded as 1_5) and 2.</para></listitem> | ||
| 835 | <listitem><para>The bus width. When the bus width is larger than the number of | ||
| 836 | bits per pixel component, several components are packed in a single bus | ||
| 837 | sample. The components are ordered as specified by the order code, with | ||
| 838 | components on the left of the code transferred in the high order bits. | ||
| 839 | Common values are 8 and 16.</para> | ||
| 840 | </listitem> | ||
| 841 | </itemizedlist> | ||
| 842 | </para> | ||
| 843 | |||
| 844 | <para>For instance, a format where pixels are encoded as 8-bit YUV values | ||
| 845 | downsampled to 4:2:2 and transferred as 2 8-bit bus samples per pixel in the | ||
| 846 | U, Y, V, Y order will be named <constant>V4L2_MBUS_FMT_UYVY8_2X8</constant>. | ||
| 847 | </para> | ||
| 848 | |||
| 849 | <para>The following table lisst existing packet YUV formats.</para> | ||
| 850 | |||
| 851 | <table pgwide="0" frame="none" id="v4l2-mbus-pixelcode-yuv8"> | ||
| 852 | <title>YUV Formats</title> | ||
| 853 | <tgroup cols="23"> | ||
| 854 | <colspec colname="id" align="left" /> | ||
| 855 | <colspec colname="code" align="center"/> | ||
| 856 | <colspec colname="bit" /> | ||
| 857 | <colspec colnum="4" colname="b19" align="center" /> | ||
| 858 | <colspec colnum="5" colname="b18" align="center" /> | ||
| 859 | <colspec colnum="6" colname="b17" align="center" /> | ||
| 860 | <colspec colnum="7" colname="b16" align="center" /> | ||
| 861 | <colspec colnum="8" colname="b15" align="center" /> | ||
| 862 | <colspec colnum="9" colname="b14" align="center" /> | ||
| 863 | <colspec colnum="10" colname="b13" align="center" /> | ||
| 864 | <colspec colnum="11" colname="b12" align="center" /> | ||
| 865 | <colspec colnum="12" colname="b11" align="center" /> | ||
| 866 | <colspec colnum="13" colname="b10" align="center" /> | ||
| 867 | <colspec colnum="14" colname="b09" align="center" /> | ||
| 868 | <colspec colnum="15" colname="b08" align="center" /> | ||
| 869 | <colspec colnum="16" colname="b07" align="center" /> | ||
| 870 | <colspec colnum="17" colname="b06" align="center" /> | ||
| 871 | <colspec colnum="18" colname="b05" align="center" /> | ||
| 872 | <colspec colnum="19" colname="b04" align="center" /> | ||
| 873 | <colspec colnum="20" colname="b03" align="center" /> | ||
| 874 | <colspec colnum="21" colname="b02" align="center" /> | ||
| 875 | <colspec colnum="22" colname="b01" align="center" /> | ||
| 876 | <colspec colnum="23" colname="b00" align="center" /> | ||
| 877 | <spanspec namest="b19" nameend="b00" spanname="b0" /> | ||
| 878 | <thead> | ||
| 879 | <row> | ||
| 880 | <entry>Identifier</entry> | ||
| 881 | <entry>Code</entry> | ||
| 882 | <entry></entry> | ||
| 883 | <entry spanname="b0">Data organization</entry> | ||
| 884 | </row> | ||
| 885 | <row> | ||
| 886 | <entry></entry> | ||
| 887 | <entry></entry> | ||
| 888 | <entry>Bit</entry> | ||
| 889 | <entry>19</entry> | ||
| 890 | <entry>18</entry> | ||
| 891 | <entry>17</entry> | ||
| 892 | <entry>16</entry> | ||
| 893 | <entry>15</entry> | ||
| 894 | <entry>14</entry> | ||
| 895 | <entry>13</entry> | ||
| 896 | <entry>12</entry> | ||
| 897 | <entry>11</entry> | ||
| 898 | <entry>10</entry> | ||
| 899 | <entry>9</entry> | ||
| 900 | <entry>8</entry> | ||
| 901 | <entry>7</entry> | ||
| 902 | <entry>6</entry> | ||
| 903 | <entry>5</entry> | ||
| 904 | <entry>4</entry> | ||
| 905 | <entry>3</entry> | ||
| 906 | <entry>2</entry> | ||
| 907 | <entry>1</entry> | ||
| 908 | <entry>0</entry> | ||
| 909 | </row> | ||
| 910 | </thead> | ||
| 911 | <tbody valign="top"> | ||
| 912 | <row id="V4L2-MBUS-FMT-Y8-1X8"> | ||
| 913 | <entry>V4L2_MBUS_FMT_Y8_1X8</entry> | ||
| 914 | <entry>0x2001</entry> | ||
| 915 | <entry></entry> | ||
| 916 | <entry>-</entry> | ||
| 917 | <entry>-</entry> | ||
| 918 | <entry>-</entry> | ||
| 919 | <entry>-</entry> | ||
| 920 | <entry>-</entry> | ||
| 921 | <entry>-</entry> | ||
| 922 | <entry>-</entry> | ||
| 923 | <entry>-</entry> | ||
| 924 | <entry>-</entry> | ||
| 925 | <entry>-</entry> | ||
| 926 | <entry>-</entry> | ||
| 927 | <entry>-</entry> | ||
| 928 | <entry>y<subscript>7</subscript></entry> | ||
| 929 | <entry>y<subscript>6</subscript></entry> | ||
| 930 | <entry>y<subscript>5</subscript></entry> | ||
| 931 | <entry>y<subscript>4</subscript></entry> | ||
| 932 | <entry>y<subscript>3</subscript></entry> | ||
| 933 | <entry>y<subscript>2</subscript></entry> | ||
| 934 | <entry>y<subscript>1</subscript></entry> | ||
| 935 | <entry>y<subscript>0</subscript></entry> | ||
| 936 | </row> | ||
| 937 | <row id="V4L2-MBUS-FMT-UYVY8-1_5X8"> | ||
| 938 | <entry>V4L2_MBUS_FMT_UYVY8_1_5X8</entry> | ||
| 939 | <entry>0x2002</entry> | ||
| 940 | <entry></entry> | ||
| 941 | <entry>-</entry> | ||
| 942 | <entry>-</entry> | ||
| 943 | <entry>-</entry> | ||
| 944 | <entry>-</entry> | ||
| 945 | <entry>-</entry> | ||
| 946 | <entry>-</entry> | ||
| 947 | <entry>-</entry> | ||
| 948 | <entry>-</entry> | ||
| 949 | <entry>-</entry> | ||
| 950 | <entry>-</entry> | ||
| 951 | <entry>-</entry> | ||
| 952 | <entry>-</entry> | ||
| 953 | <entry>u<subscript>7</subscript></entry> | ||
| 954 | <entry>u<subscript>6</subscript></entry> | ||
| 955 | <entry>u<subscript>5</subscript></entry> | ||
| 956 | <entry>u<subscript>4</subscript></entry> | ||
| 957 | <entry>u<subscript>3</subscript></entry> | ||
| 958 | <entry>u<subscript>2</subscript></entry> | ||
| 959 | <entry>u<subscript>1</subscript></entry> | ||
| 960 | <entry>u<subscript>0</subscript></entry> | ||
| 961 | </row> | ||
| 962 | <row> | ||
| 963 | <entry></entry> | ||
| 964 | <entry></entry> | ||
| 965 | <entry></entry> | ||
| 966 | <entry>-</entry> | ||
| 967 | <entry>-</entry> | ||
| 968 | <entry>-</entry> | ||
| 969 | <entry>-</entry> | ||
| 970 | <entry>-</entry> | ||
| 971 | <entry>-</entry> | ||
| 972 | <entry>-</entry> | ||
| 973 | <entry>-</entry> | ||
| 974 | <entry>-</entry> | ||
| 975 | <entry>-</entry> | ||
| 976 | <entry>-</entry> | ||
| 977 | <entry>-</entry> | ||
| 978 | <entry>y<subscript>7</subscript></entry> | ||
| 979 | <entry>y<subscript>6</subscript></entry> | ||
| 980 | <entry>y<subscript>5</subscript></entry> | ||
| 981 | <entry>y<subscript>4</subscript></entry> | ||
| 982 | <entry>y<subscript>3</subscript></entry> | ||
| 983 | <entry>y<subscript>2</subscript></entry> | ||
| 984 | <entry>y<subscript>1</subscript></entry> | ||
| 985 | <entry>y<subscript>0</subscript></entry> | ||
| 986 | </row> | ||
| 987 | <row> | ||
| 988 | <entry></entry> | ||
| 989 | <entry></entry> | ||
| 990 | <entry></entry> | ||
| 991 | <entry>-</entry> | ||
| 992 | <entry>-</entry> | ||
| 993 | <entry>-</entry> | ||
| 994 | <entry>-</entry> | ||
| 995 | <entry>-</entry> | ||
| 996 | <entry>-</entry> | ||
| 997 | <entry>-</entry> | ||
| 998 | <entry>-</entry> | ||
| 999 | <entry>-</entry> | ||
| 1000 | <entry>-</entry> | ||
| 1001 | <entry>-</entry> | ||
| 1002 | <entry>-</entry> | ||
| 1003 | <entry>y<subscript>7</subscript></entry> | ||
| 1004 | <entry>y<subscript>6</subscript></entry> | ||
| 1005 | <entry>y<subscript>5</subscript></entry> | ||
| 1006 | <entry>y<subscript>4</subscript></entry> | ||
| 1007 | <entry>y<subscript>3</subscript></entry> | ||
| 1008 | <entry>y<subscript>2</subscript></entry> | ||
| 1009 | <entry>y<subscript>1</subscript></entry> | ||
| 1010 | <entry>y<subscript>0</subscript></entry> | ||
| 1011 | </row> | ||
| 1012 | <row> | ||
| 1013 | <entry></entry> | ||
| 1014 | <entry></entry> | ||
| 1015 | <entry></entry> | ||
| 1016 | <entry>-</entry> | ||
| 1017 | <entry>-</entry> | ||
| 1018 | <entry>-</entry> | ||
| 1019 | <entry>-</entry> | ||
| 1020 | <entry>-</entry> | ||
| 1021 | <entry>-</entry> | ||
| 1022 | <entry>-</entry> | ||
| 1023 | <entry>-</entry> | ||
| 1024 | <entry>-</entry> | ||
| 1025 | <entry>-</entry> | ||
| 1026 | <entry>-</entry> | ||
| 1027 | <entry>-</entry> | ||
| 1028 | <entry>v<subscript>7</subscript></entry> | ||
| 1029 | <entry>v<subscript>6</subscript></entry> | ||
| 1030 | <entry>v<subscript>5</subscript></entry> | ||
| 1031 | <entry>v<subscript>4</subscript></entry> | ||
| 1032 | <entry>v<subscript>3</subscript></entry> | ||
| 1033 | <entry>v<subscript>2</subscript></entry> | ||
| 1034 | <entry>v<subscript>1</subscript></entry> | ||
| 1035 | <entry>v<subscript>0</subscript></entry> | ||
| 1036 | </row> | ||
| 1037 | <row> | ||
| 1038 | <entry></entry> | ||
| 1039 | <entry></entry> | ||
| 1040 | <entry></entry> | ||
| 1041 | <entry>-</entry> | ||
| 1042 | <entry>-</entry> | ||
| 1043 | <entry>-</entry> | ||
| 1044 | <entry>-</entry> | ||
| 1045 | <entry>-</entry> | ||
| 1046 | <entry>-</entry> | ||
| 1047 | <entry>-</entry> | ||
| 1048 | <entry>-</entry> | ||
| 1049 | <entry>-</entry> | ||
| 1050 | <entry>-</entry> | ||
| 1051 | <entry>-</entry> | ||
| 1052 | <entry>-</entry> | ||
| 1053 | <entry>y<subscript>7</subscript></entry> | ||
| 1054 | <entry>y<subscript>6</subscript></entry> | ||
| 1055 | <entry>y<subscript>5</subscript></entry> | ||
| 1056 | <entry>y<subscript>4</subscript></entry> | ||
| 1057 | <entry>y<subscript>3</subscript></entry> | ||
| 1058 | <entry>y<subscript>2</subscript></entry> | ||
| 1059 | <entry>y<subscript>1</subscript></entry> | ||
| 1060 | <entry>y<subscript>0</subscript></entry> | ||
| 1061 | </row> | ||
| 1062 | <row> | ||
| 1063 | <entry></entry> | ||
| 1064 | <entry></entry> | ||
| 1065 | <entry></entry> | ||
| 1066 | <entry>-</entry> | ||
| 1067 | <entry>-</entry> | ||
| 1068 | <entry>-</entry> | ||
| 1069 | <entry>-</entry> | ||
| 1070 | <entry>-</entry> | ||
| 1071 | <entry>-</entry> | ||
| 1072 | <entry>-</entry> | ||
| 1073 | <entry>-</entry> | ||
| 1074 | <entry>-</entry> | ||
| 1075 | <entry>-</entry> | ||
| 1076 | <entry>-</entry> | ||
| 1077 | <entry>-</entry> | ||
| 1078 | <entry>y<subscript>7</subscript></entry> | ||
| 1079 | <entry>y<subscript>6</subscript></entry> | ||
| 1080 | <entry>y<subscript>5</subscript></entry> | ||
| 1081 | <entry>y<subscript>4</subscript></entry> | ||
| 1082 | <entry>y<subscript>3</subscript></entry> | ||
| 1083 | <entry>y<subscript>2</subscript></entry> | ||
| 1084 | <entry>y<subscript>1</subscript></entry> | ||
| 1085 | <entry>y<subscript>0</subscript></entry> | ||
| 1086 | </row> | ||
| 1087 | <row id="V4L2-MBUS-FMT-VYUY8-1_5X8"> | ||
| 1088 | <entry>V4L2_MBUS_FMT_VYUY8_1_5X8</entry> | ||
| 1089 | <entry>0x2003</entry> | ||
| 1090 | <entry></entry> | ||
| 1091 | <entry>-</entry> | ||
| 1092 | <entry>-</entry> | ||
| 1093 | <entry>-</entry> | ||
| 1094 | <entry>-</entry> | ||
| 1095 | <entry>-</entry> | ||
| 1096 | <entry>-</entry> | ||
| 1097 | <entry>-</entry> | ||
| 1098 | <entry>-</entry> | ||
| 1099 | <entry>-</entry> | ||
| 1100 | <entry>-</entry> | ||
| 1101 | <entry>-</entry> | ||
| 1102 | <entry>-</entry> | ||
| 1103 | <entry>v<subscript>7</subscript></entry> | ||
| 1104 | <entry>v<subscript>6</subscript></entry> | ||
| 1105 | <entry>v<subscript>5</subscript></entry> | ||
| 1106 | <entry>v<subscript>4</subscript></entry> | ||
| 1107 | <entry>v<subscript>3</subscript></entry> | ||
| 1108 | <entry>v<subscript>2</subscript></entry> | ||
| 1109 | <entry>v<subscript>1</subscript></entry> | ||
| 1110 | <entry>v<subscript>0</subscript></entry> | ||
| 1111 | </row> | ||
| 1112 | <row> | ||
| 1113 | <entry></entry> | ||
| 1114 | <entry></entry> | ||
| 1115 | <entry></entry> | ||
| 1116 | <entry>-</entry> | ||
| 1117 | <entry>-</entry> | ||
| 1118 | <entry>-</entry> | ||
| 1119 | <entry>-</entry> | ||
| 1120 | <entry>-</entry> | ||
| 1121 | <entry>-</entry> | ||
| 1122 | <entry>-</entry> | ||
| 1123 | <entry>-</entry> | ||
| 1124 | <entry>-</entry> | ||
| 1125 | <entry>-</entry> | ||
| 1126 | <entry>-</entry> | ||
| 1127 | <entry>-</entry> | ||
| 1128 | <entry>y<subscript>7</subscript></entry> | ||
| 1129 | <entry>y<subscript>6</subscript></entry> | ||
| 1130 | <entry>y<subscript>5</subscript></entry> | ||
| 1131 | <entry>y<subscript>4</subscript></entry> | ||
| 1132 | <entry>y<subscript>3</subscript></entry> | ||
| 1133 | <entry>y<subscript>2</subscript></entry> | ||
| 1134 | <entry>y<subscript>1</subscript></entry> | ||
| 1135 | <entry>y<subscript>0</subscript></entry> | ||
| 1136 | </row> | ||
| 1137 | <row> | ||
| 1138 | <entry></entry> | ||
| 1139 | <entry></entry> | ||
| 1140 | <entry></entry> | ||
| 1141 | <entry>-</entry> | ||
| 1142 | <entry>-</entry> | ||
| 1143 | <entry>-</entry> | ||
| 1144 | <entry>-</entry> | ||
| 1145 | <entry>-</entry> | ||
| 1146 | <entry>-</entry> | ||
| 1147 | <entry>-</entry> | ||
| 1148 | <entry>-</entry> | ||
| 1149 | <entry>-</entry> | ||
| 1150 | <entry>-</entry> | ||
| 1151 | <entry>-</entry> | ||
| 1152 | <entry>-</entry> | ||
| 1153 | <entry>y<subscript>7</subscript></entry> | ||
| 1154 | <entry>y<subscript>6</subscript></entry> | ||
| 1155 | <entry>y<subscript>5</subscript></entry> | ||
| 1156 | <entry>y<subscript>4</subscript></entry> | ||
| 1157 | <entry>y<subscript>3</subscript></entry> | ||
| 1158 | <entry>y<subscript>2</subscript></entry> | ||
| 1159 | <entry>y<subscript>1</subscript></entry> | ||
| 1160 | <entry>y<subscript>0</subscript></entry> | ||
| 1161 | </row> | ||
| 1162 | <row> | ||
| 1163 | <entry></entry> | ||
| 1164 | <entry></entry> | ||
| 1165 | <entry></entry> | ||
| 1166 | <entry>-</entry> | ||
| 1167 | <entry>-</entry> | ||
| 1168 | <entry>-</entry> | ||
| 1169 | <entry>-</entry> | ||
| 1170 | <entry>-</entry> | ||
| 1171 | <entry>-</entry> | ||
| 1172 | <entry>-</entry> | ||
| 1173 | <entry>-</entry> | ||
| 1174 | <entry>-</entry> | ||
| 1175 | <entry>-</entry> | ||
| 1176 | <entry>-</entry> | ||
| 1177 | <entry>-</entry> | ||
| 1178 | <entry>u<subscript>7</subscript></entry> | ||
| 1179 | <entry>u<subscript>6</subscript></entry> | ||
| 1180 | <entry>u<subscript>5</subscript></entry> | ||
| 1181 | <entry>u<subscript>4</subscript></entry> | ||
| 1182 | <entry>u<subscript>3</subscript></entry> | ||
| 1183 | <entry>u<subscript>2</subscript></entry> | ||
| 1184 | <entry>u<subscript>1</subscript></entry> | ||
| 1185 | <entry>u<subscript>0</subscript></entry> | ||
| 1186 | </row> | ||
| 1187 | <row> | ||
| 1188 | <entry></entry> | ||
| 1189 | <entry></entry> | ||
| 1190 | <entry></entry> | ||
| 1191 | <entry>-</entry> | ||
| 1192 | <entry>-</entry> | ||
| 1193 | <entry>-</entry> | ||
| 1194 | <entry>-</entry> | ||
| 1195 | <entry>-</entry> | ||
| 1196 | <entry>-</entry> | ||
| 1197 | <entry>-</entry> | ||
| 1198 | <entry>-</entry> | ||
| 1199 | <entry>-</entry> | ||
| 1200 | <entry>-</entry> | ||
| 1201 | <entry>-</entry> | ||
| 1202 | <entry>-</entry> | ||
| 1203 | <entry>y<subscript>7</subscript></entry> | ||
| 1204 | <entry>y<subscript>6</subscript></entry> | ||
| 1205 | <entry>y<subscript>5</subscript></entry> | ||
| 1206 | <entry>y<subscript>4</subscript></entry> | ||
| 1207 | <entry>y<subscript>3</subscript></entry> | ||
| 1208 | <entry>y<subscript>2</subscript></entry> | ||
| 1209 | <entry>y<subscript>1</subscript></entry> | ||
| 1210 | <entry>y<subscript>0</subscript></entry> | ||
| 1211 | </row> | ||
| 1212 | <row> | ||
| 1213 | <entry></entry> | ||
| 1214 | <entry></entry> | ||
| 1215 | <entry></entry> | ||
| 1216 | <entry>-</entry> | ||
| 1217 | <entry>-</entry> | ||
| 1218 | <entry>-</entry> | ||
| 1219 | <entry>-</entry> | ||
| 1220 | <entry>-</entry> | ||
| 1221 | <entry>-</entry> | ||
| 1222 | <entry>-</entry> | ||
| 1223 | <entry>-</entry> | ||
| 1224 | <entry>-</entry> | ||
| 1225 | <entry>-</entry> | ||
| 1226 | <entry>-</entry> | ||
| 1227 | <entry>-</entry> | ||
| 1228 | <entry>y<subscript>7</subscript></entry> | ||
| 1229 | <entry>y<subscript>6</subscript></entry> | ||
| 1230 | <entry>y<subscript>5</subscript></entry> | ||
| 1231 | <entry>y<subscript>4</subscript></entry> | ||
| 1232 | <entry>y<subscript>3</subscript></entry> | ||
| 1233 | <entry>y<subscript>2</subscript></entry> | ||
| 1234 | <entry>y<subscript>1</subscript></entry> | ||
| 1235 | <entry>y<subscript>0</subscript></entry> | ||
| 1236 | </row> | ||
| 1237 | <row id="V4L2-MBUS-FMT-YUYV8-1_5X8"> | ||
| 1238 | <entry>V4L2_MBUS_FMT_YUYV8_1_5X8</entry> | ||
| 1239 | <entry>0x2004</entry> | ||
| 1240 | <entry></entry> | ||
| 1241 | <entry>-</entry> | ||
| 1242 | <entry>-</entry> | ||
| 1243 | <entry>-</entry> | ||
| 1244 | <entry>-</entry> | ||
| 1245 | <entry>-</entry> | ||
| 1246 | <entry>-</entry> | ||
| 1247 | <entry>-</entry> | ||
| 1248 | <entry>-</entry> | ||
| 1249 | <entry>-</entry> | ||
| 1250 | <entry>-</entry> | ||
| 1251 | <entry>-</entry> | ||
| 1252 | <entry>-</entry> | ||
| 1253 | <entry>y<subscript>7</subscript></entry> | ||
| 1254 | <entry>y<subscript>6</subscript></entry> | ||
| 1255 | <entry>y<subscript>5</subscript></entry> | ||
| 1256 | <entry>y<subscript>4</subscript></entry> | ||
| 1257 | <entry>y<subscript>3</subscript></entry> | ||
| 1258 | <entry>y<subscript>2</subscript></entry> | ||
| 1259 | <entry>y<subscript>1</subscript></entry> | ||
| 1260 | <entry>y<subscript>0</subscript></entry> | ||
| 1261 | </row> | ||
| 1262 | <row> | ||
| 1263 | <entry></entry> | ||
| 1264 | <entry></entry> | ||
| 1265 | <entry></entry> | ||
| 1266 | <entry>-</entry> | ||
| 1267 | <entry>-</entry> | ||
| 1268 | <entry>-</entry> | ||
| 1269 | <entry>-</entry> | ||
| 1270 | <entry>-</entry> | ||
| 1271 | <entry>-</entry> | ||
| 1272 | <entry>-</entry> | ||
| 1273 | <entry>-</entry> | ||
| 1274 | <entry>-</entry> | ||
| 1275 | <entry>-</entry> | ||
| 1276 | <entry>-</entry> | ||
| 1277 | <entry>-</entry> | ||
| 1278 | <entry>y<subscript>7</subscript></entry> | ||
| 1279 | <entry>y<subscript>6</subscript></entry> | ||
| 1280 | <entry>y<subscript>5</subscript></entry> | ||
| 1281 | <entry>y<subscript>4</subscript></entry> | ||
| 1282 | <entry>y<subscript>3</subscript></entry> | ||
| 1283 | <entry>y<subscript>2</subscript></entry> | ||
| 1284 | <entry>y<subscript>1</subscript></entry> | ||
| 1285 | <entry>y<subscript>0</subscript></entry> | ||
| 1286 | </row> | ||
| 1287 | <row> | ||
| 1288 | <entry></entry> | ||
| 1289 | <entry></entry> | ||
| 1290 | <entry></entry> | ||
| 1291 | <entry>-</entry> | ||
| 1292 | <entry>-</entry> | ||
| 1293 | <entry>-</entry> | ||
| 1294 | <entry>-</entry> | ||
| 1295 | <entry>-</entry> | ||
| 1296 | <entry>-</entry> | ||
| 1297 | <entry>-</entry> | ||
| 1298 | <entry>-</entry> | ||
| 1299 | <entry>-</entry> | ||
| 1300 | <entry>-</entry> | ||
| 1301 | <entry>-</entry> | ||
| 1302 | <entry>-</entry> | ||
| 1303 | <entry>u<subscript>7</subscript></entry> | ||
| 1304 | <entry>u<subscript>6</subscript></entry> | ||
| 1305 | <entry>u<subscript>5</subscript></entry> | ||
| 1306 | <entry>u<subscript>4</subscript></entry> | ||
| 1307 | <entry>u<subscript>3</subscript></entry> | ||
| 1308 | <entry>u<subscript>2</subscript></entry> | ||
| 1309 | <entry>u<subscript>1</subscript></entry> | ||
| 1310 | <entry>u<subscript>0</subscript></entry> | ||
| 1311 | </row> | ||
| 1312 | <row> | ||
| 1313 | <entry></entry> | ||
| 1314 | <entry></entry> | ||
| 1315 | <entry></entry> | ||
| 1316 | <entry>-</entry> | ||
| 1317 | <entry>-</entry> | ||
| 1318 | <entry>-</entry> | ||
| 1319 | <entry>-</entry> | ||
| 1320 | <entry>-</entry> | ||
| 1321 | <entry>-</entry> | ||
| 1322 | <entry>-</entry> | ||
| 1323 | <entry>-</entry> | ||
| 1324 | <entry>-</entry> | ||
| 1325 | <entry>-</entry> | ||
| 1326 | <entry>-</entry> | ||
| 1327 | <entry>-</entry> | ||
| 1328 | <entry>y<subscript>7</subscript></entry> | ||
| 1329 | <entry>y<subscript>6</subscript></entry> | ||
| 1330 | <entry>y<subscript>5</subscript></entry> | ||
| 1331 | <entry>y<subscript>4</subscript></entry> | ||
| 1332 | <entry>y<subscript>3</subscript></entry> | ||
| 1333 | <entry>y<subscript>2</subscript></entry> | ||
| 1334 | <entry>y<subscript>1</subscript></entry> | ||
| 1335 | <entry>y<subscript>0</subscript></entry> | ||
| 1336 | </row> | ||
| 1337 | <row> | ||
| 1338 | <entry></entry> | ||
| 1339 | <entry></entry> | ||
| 1340 | <entry></entry> | ||
| 1341 | <entry>-</entry> | ||
| 1342 | <entry>-</entry> | ||
| 1343 | <entry>-</entry> | ||
| 1344 | <entry>-</entry> | ||
| 1345 | <entry>-</entry> | ||
| 1346 | <entry>-</entry> | ||
| 1347 | <entry>-</entry> | ||
| 1348 | <entry>-</entry> | ||
| 1349 | <entry>-</entry> | ||
| 1350 | <entry>-</entry> | ||
| 1351 | <entry>-</entry> | ||
| 1352 | <entry>-</entry> | ||
| 1353 | <entry>y<subscript>7</subscript></entry> | ||
| 1354 | <entry>y<subscript>6</subscript></entry> | ||
| 1355 | <entry>y<subscript>5</subscript></entry> | ||
| 1356 | <entry>y<subscript>4</subscript></entry> | ||
| 1357 | <entry>y<subscript>3</subscript></entry> | ||
| 1358 | <entry>y<subscript>2</subscript></entry> | ||
| 1359 | <entry>y<subscript>1</subscript></entry> | ||
| 1360 | <entry>y<subscript>0</subscript></entry> | ||
| 1361 | </row> | ||
| 1362 | <row> | ||
| 1363 | <entry></entry> | ||
| 1364 | <entry></entry> | ||
| 1365 | <entry></entry> | ||
| 1366 | <entry>-</entry> | ||
| 1367 | <entry>-</entry> | ||
| 1368 | <entry>-</entry> | ||
| 1369 | <entry>-</entry> | ||
| 1370 | <entry>-</entry> | ||
| 1371 | <entry>-</entry> | ||
| 1372 | <entry>-</entry> | ||
| 1373 | <entry>-</entry> | ||
| 1374 | <entry>-</entry> | ||
| 1375 | <entry>-</entry> | ||
| 1376 | <entry>-</entry> | ||
| 1377 | <entry>-</entry> | ||
| 1378 | <entry>v<subscript>7</subscript></entry> | ||
| 1379 | <entry>v<subscript>6</subscript></entry> | ||
| 1380 | <entry>v<subscript>5</subscript></entry> | ||
| 1381 | <entry>v<subscript>4</subscript></entry> | ||
| 1382 | <entry>v<subscript>3</subscript></entry> | ||
| 1383 | <entry>v<subscript>2</subscript></entry> | ||
| 1384 | <entry>v<subscript>1</subscript></entry> | ||
| 1385 | <entry>v<subscript>0</subscript></entry> | ||
| 1386 | </row> | ||
| 1387 | <row id="V4L2-MBUS-FMT-YVYU8-1_5X8"> | ||
| 1388 | <entry>V4L2_MBUS_FMT_YVYU8_1_5X8</entry> | ||
| 1389 | <entry>0x2005</entry> | ||
| 1390 | <entry></entry> | ||
| 1391 | <entry>-</entry> | ||
| 1392 | <entry>-</entry> | ||
| 1393 | <entry>-</entry> | ||
| 1394 | <entry>-</entry> | ||
| 1395 | <entry>-</entry> | ||
| 1396 | <entry>-</entry> | ||
| 1397 | <entry>-</entry> | ||
| 1398 | <entry>-</entry> | ||
| 1399 | <entry>-</entry> | ||
| 1400 | <entry>-</entry> | ||
| 1401 | <entry>-</entry> | ||
| 1402 | <entry>-</entry> | ||
| 1403 | <entry>y<subscript>7</subscript></entry> | ||
| 1404 | <entry>y<subscript>6</subscript></entry> | ||
| 1405 | <entry>y<subscript>5</subscript></entry> | ||
| 1406 | <entry>y<subscript>4</subscript></entry> | ||
| 1407 | <entry>y<subscript>3</subscript></entry> | ||
| 1408 | <entry>y<subscript>2</subscript></entry> | ||
| 1409 | <entry>y<subscript>1</subscript></entry> | ||
| 1410 | <entry>y<subscript>0</subscript></entry> | ||
| 1411 | </row> | ||
| 1412 | <row> | ||
| 1413 | <entry></entry> | ||
| 1414 | <entry></entry> | ||
| 1415 | <entry></entry> | ||
| 1416 | <entry>-</entry> | ||
| 1417 | <entry>-</entry> | ||
| 1418 | <entry>-</entry> | ||
| 1419 | <entry>-</entry> | ||
| 1420 | <entry>-</entry> | ||
| 1421 | <entry>-</entry> | ||
| 1422 | <entry>-</entry> | ||
| 1423 | <entry>-</entry> | ||
| 1424 | <entry>-</entry> | ||
| 1425 | <entry>-</entry> | ||
| 1426 | <entry>-</entry> | ||
| 1427 | <entry>-</entry> | ||
| 1428 | <entry>y<subscript>7</subscript></entry> | ||
| 1429 | <entry>y<subscript>6</subscript></entry> | ||
| 1430 | <entry>y<subscript>5</subscript></entry> | ||
| 1431 | <entry>y<subscript>4</subscript></entry> | ||
| 1432 | <entry>y<subscript>3</subscript></entry> | ||
| 1433 | <entry>y<subscript>2</subscript></entry> | ||
| 1434 | <entry>y<subscript>1</subscript></entry> | ||
| 1435 | <entry>y<subscript>0</subscript></entry> | ||
| 1436 | </row> | ||
| 1437 | <row> | ||
| 1438 | <entry></entry> | ||
| 1439 | <entry></entry> | ||
| 1440 | <entry></entry> | ||
| 1441 | <entry>-</entry> | ||
| 1442 | <entry>-</entry> | ||
| 1443 | <entry>-</entry> | ||
| 1444 | <entry>-</entry> | ||
| 1445 | <entry>-</entry> | ||
| 1446 | <entry>-</entry> | ||
| 1447 | <entry>-</entry> | ||
| 1448 | <entry>-</entry> | ||
| 1449 | <entry>-</entry> | ||
| 1450 | <entry>-</entry> | ||
| 1451 | <entry>-</entry> | ||
| 1452 | <entry>-</entry> | ||
| 1453 | <entry>v<subscript>7</subscript></entry> | ||
| 1454 | <entry>v<subscript>6</subscript></entry> | ||
| 1455 | <entry>v<subscript>5</subscript></entry> | ||
| 1456 | <entry>v<subscript>4</subscript></entry> | ||
| 1457 | <entry>v<subscript>3</subscript></entry> | ||
| 1458 | <entry>v<subscript>2</subscript></entry> | ||
| 1459 | <entry>v<subscript>1</subscript></entry> | ||
| 1460 | <entry>v<subscript>0</subscript></entry> | ||
| 1461 | </row> | ||
| 1462 | <row> | ||
| 1463 | <entry></entry> | ||
| 1464 | <entry></entry> | ||
| 1465 | <entry></entry> | ||
| 1466 | <entry>-</entry> | ||
| 1467 | <entry>-</entry> | ||
| 1468 | <entry>-</entry> | ||
| 1469 | <entry>-</entry> | ||
| 1470 | <entry>-</entry> | ||
| 1471 | <entry>-</entry> | ||
| 1472 | <entry>-</entry> | ||
| 1473 | <entry>-</entry> | ||
| 1474 | <entry>-</entry> | ||
| 1475 | <entry>-</entry> | ||
| 1476 | <entry>-</entry> | ||
| 1477 | <entry>-</entry> | ||
| 1478 | <entry>y<subscript>7</subscript></entry> | ||
| 1479 | <entry>y<subscript>6</subscript></entry> | ||
| 1480 | <entry>y<subscript>5</subscript></entry> | ||
| 1481 | <entry>y<subscript>4</subscript></entry> | ||
| 1482 | <entry>y<subscript>3</subscript></entry> | ||
| 1483 | <entry>y<subscript>2</subscript></entry> | ||
| 1484 | <entry>y<subscript>1</subscript></entry> | ||
| 1485 | <entry>y<subscript>0</subscript></entry> | ||
| 1486 | </row> | ||
| 1487 | <row> | ||
| 1488 | <entry></entry> | ||
| 1489 | <entry></entry> | ||
| 1490 | <entry></entry> | ||
| 1491 | <entry>-</entry> | ||
| 1492 | <entry>-</entry> | ||
| 1493 | <entry>-</entry> | ||
| 1494 | <entry>-</entry> | ||
| 1495 | <entry>-</entry> | ||
| 1496 | <entry>-</entry> | ||
| 1497 | <entry>-</entry> | ||
| 1498 | <entry>-</entry> | ||
| 1499 | <entry>-</entry> | ||
| 1500 | <entry>-</entry> | ||
| 1501 | <entry>-</entry> | ||
| 1502 | <entry>-</entry> | ||
| 1503 | <entry>y<subscript>7</subscript></entry> | ||
| 1504 | <entry>y<subscript>6</subscript></entry> | ||
| 1505 | <entry>y<subscript>5</subscript></entry> | ||
| 1506 | <entry>y<subscript>4</subscript></entry> | ||
| 1507 | <entry>y<subscript>3</subscript></entry> | ||
| 1508 | <entry>y<subscript>2</subscript></entry> | ||
| 1509 | <entry>y<subscript>1</subscript></entry> | ||
| 1510 | <entry>y<subscript>0</subscript></entry> | ||
| 1511 | </row> | ||
| 1512 | <row> | ||
| 1513 | <entry></entry> | ||
| 1514 | <entry></entry> | ||
| 1515 | <entry></entry> | ||
| 1516 | <entry>-</entry> | ||
| 1517 | <entry>-</entry> | ||
| 1518 | <entry>-</entry> | ||
| 1519 | <entry>-</entry> | ||
| 1520 | <entry>-</entry> | ||
| 1521 | <entry>-</entry> | ||
| 1522 | <entry>-</entry> | ||
| 1523 | <entry>-</entry> | ||
| 1524 | <entry>-</entry> | ||
| 1525 | <entry>-</entry> | ||
| 1526 | <entry>-</entry> | ||
| 1527 | <entry>-</entry> | ||
| 1528 | <entry>u<subscript>7</subscript></entry> | ||
| 1529 | <entry>u<subscript>6</subscript></entry> | ||
| 1530 | <entry>u<subscript>5</subscript></entry> | ||
| 1531 | <entry>u<subscript>4</subscript></entry> | ||
| 1532 | <entry>u<subscript>3</subscript></entry> | ||
| 1533 | <entry>u<subscript>2</subscript></entry> | ||
| 1534 | <entry>u<subscript>1</subscript></entry> | ||
| 1535 | <entry>u<subscript>0</subscript></entry> | ||
| 1536 | </row> | ||
| 1537 | <row id="V4L2-MBUS-FMT-UYVY8-2X8"> | ||
| 1538 | <entry>V4L2_MBUS_FMT_UYVY8_2X8</entry> | ||
| 1539 | <entry>0x2006</entry> | ||
| 1540 | <entry></entry> | ||
| 1541 | <entry>-</entry> | ||
| 1542 | <entry>-</entry> | ||
| 1543 | <entry>-</entry> | ||
| 1544 | <entry>-</entry> | ||
| 1545 | <entry>-</entry> | ||
| 1546 | <entry>-</entry> | ||
| 1547 | <entry>-</entry> | ||
| 1548 | <entry>-</entry> | ||
| 1549 | <entry>-</entry> | ||
| 1550 | <entry>-</entry> | ||
| 1551 | <entry>-</entry> | ||
| 1552 | <entry>-</entry> | ||
| 1553 | <entry>u<subscript>7</subscript></entry> | ||
| 1554 | <entry>u<subscript>6</subscript></entry> | ||
| 1555 | <entry>u<subscript>5</subscript></entry> | ||
| 1556 | <entry>u<subscript>4</subscript></entry> | ||
| 1557 | <entry>u<subscript>3</subscript></entry> | ||
| 1558 | <entry>u<subscript>2</subscript></entry> | ||
| 1559 | <entry>u<subscript>1</subscript></entry> | ||
| 1560 | <entry>u<subscript>0</subscript></entry> | ||
| 1561 | </row> | ||
| 1562 | <row> | ||
| 1563 | <entry></entry> | ||
| 1564 | <entry></entry> | ||
| 1565 | <entry></entry> | ||
| 1566 | <entry>-</entry> | ||
| 1567 | <entry>-</entry> | ||
| 1568 | <entry>-</entry> | ||
| 1569 | <entry>-</entry> | ||
| 1570 | <entry>-</entry> | ||
| 1571 | <entry>-</entry> | ||
| 1572 | <entry>-</entry> | ||
| 1573 | <entry>-</entry> | ||
| 1574 | <entry>-</entry> | ||
| 1575 | <entry>-</entry> | ||
| 1576 | <entry>-</entry> | ||
| 1577 | <entry>-</entry> | ||
| 1578 | <entry>y<subscript>7</subscript></entry> | ||
| 1579 | <entry>y<subscript>6</subscript></entry> | ||
| 1580 | <entry>y<subscript>5</subscript></entry> | ||
| 1581 | <entry>y<subscript>4</subscript></entry> | ||
| 1582 | <entry>y<subscript>3</subscript></entry> | ||
| 1583 | <entry>y<subscript>2</subscript></entry> | ||
| 1584 | <entry>y<subscript>1</subscript></entry> | ||
| 1585 | <entry>y<subscript>0</subscript></entry> | ||
| 1586 | </row> | ||
| 1587 | <row> | ||
| 1588 | <entry></entry> | ||
| 1589 | <entry></entry> | ||
| 1590 | <entry></entry> | ||
| 1591 | <entry>-</entry> | ||
| 1592 | <entry>-</entry> | ||
| 1593 | <entry>-</entry> | ||
| 1594 | <entry>-</entry> | ||
| 1595 | <entry>-</entry> | ||
| 1596 | <entry>-</entry> | ||
| 1597 | <entry>-</entry> | ||
| 1598 | <entry>-</entry> | ||
| 1599 | <entry>-</entry> | ||
| 1600 | <entry>-</entry> | ||
| 1601 | <entry>-</entry> | ||
| 1602 | <entry>-</entry> | ||
| 1603 | <entry>v<subscript>7</subscript></entry> | ||
| 1604 | <entry>v<subscript>6</subscript></entry> | ||
| 1605 | <entry>v<subscript>5</subscript></entry> | ||
| 1606 | <entry>v<subscript>4</subscript></entry> | ||
| 1607 | <entry>v<subscript>3</subscript></entry> | ||
| 1608 | <entry>v<subscript>2</subscript></entry> | ||
| 1609 | <entry>v<subscript>1</subscript></entry> | ||
| 1610 | <entry>v<subscript>0</subscript></entry> | ||
| 1611 | </row> | ||
| 1612 | <row> | ||
| 1613 | <entry></entry> | ||
| 1614 | <entry></entry> | ||
| 1615 | <entry></entry> | ||
| 1616 | <entry>-</entry> | ||
| 1617 | <entry>-</entry> | ||
| 1618 | <entry>-</entry> | ||
| 1619 | <entry>-</entry> | ||
| 1620 | <entry>-</entry> | ||
| 1621 | <entry>-</entry> | ||
| 1622 | <entry>-</entry> | ||
| 1623 | <entry>-</entry> | ||
| 1624 | <entry>-</entry> | ||
| 1625 | <entry>-</entry> | ||
| 1626 | <entry>-</entry> | ||
| 1627 | <entry>-</entry> | ||
| 1628 | <entry>y<subscript>7</subscript></entry> | ||
| 1629 | <entry>y<subscript>6</subscript></entry> | ||
| 1630 | <entry>y<subscript>5</subscript></entry> | ||
| 1631 | <entry>y<subscript>4</subscript></entry> | ||
| 1632 | <entry>y<subscript>3</subscript></entry> | ||
| 1633 | <entry>y<subscript>2</subscript></entry> | ||
| 1634 | <entry>y<subscript>1</subscript></entry> | ||
| 1635 | <entry>y<subscript>0</subscript></entry> | ||
| 1636 | </row> | ||
| 1637 | <row id="V4L2-MBUS-FMT-VYUY8-2X8"> | ||
| 1638 | <entry>V4L2_MBUS_FMT_VYUY8_2X8</entry> | ||
| 1639 | <entry>0x2007</entry> | ||
| 1640 | <entry></entry> | ||
| 1641 | <entry>-</entry> | ||
| 1642 | <entry>-</entry> | ||
| 1643 | <entry>-</entry> | ||
| 1644 | <entry>-</entry> | ||
| 1645 | <entry>-</entry> | ||
| 1646 | <entry>-</entry> | ||
| 1647 | <entry>-</entry> | ||
| 1648 | <entry>-</entry> | ||
| 1649 | <entry>-</entry> | ||
| 1650 | <entry>-</entry> | ||
| 1651 | <entry>-</entry> | ||
| 1652 | <entry>-</entry> | ||
| 1653 | <entry>v<subscript>7</subscript></entry> | ||
| 1654 | <entry>v<subscript>6</subscript></entry> | ||
| 1655 | <entry>v<subscript>5</subscript></entry> | ||
| 1656 | <entry>v<subscript>4</subscript></entry> | ||
| 1657 | <entry>v<subscript>3</subscript></entry> | ||
| 1658 | <entry>v<subscript>2</subscript></entry> | ||
| 1659 | <entry>v<subscript>1</subscript></entry> | ||
| 1660 | <entry>v<subscript>0</subscript></entry> | ||
| 1661 | </row> | ||
| 1662 | <row> | ||
| 1663 | <entry></entry> | ||
| 1664 | <entry></entry> | ||
| 1665 | <entry></entry> | ||
| 1666 | <entry>-</entry> | ||
| 1667 | <entry>-</entry> | ||
| 1668 | <entry>-</entry> | ||
| 1669 | <entry>-</entry> | ||
| 1670 | <entry>-</entry> | ||
| 1671 | <entry>-</entry> | ||
| 1672 | <entry>-</entry> | ||
| 1673 | <entry>-</entry> | ||
| 1674 | <entry>-</entry> | ||
| 1675 | <entry>-</entry> | ||
| 1676 | <entry>-</entry> | ||
| 1677 | <entry>-</entry> | ||
| 1678 | <entry>y<subscript>7</subscript></entry> | ||
| 1679 | <entry>y<subscript>6</subscript></entry> | ||
| 1680 | <entry>y<subscript>5</subscript></entry> | ||
| 1681 | <entry>y<subscript>4</subscript></entry> | ||
| 1682 | <entry>y<subscript>3</subscript></entry> | ||
| 1683 | <entry>y<subscript>2</subscript></entry> | ||
| 1684 | <entry>y<subscript>1</subscript></entry> | ||
| 1685 | <entry>y<subscript>0</subscript></entry> | ||
| 1686 | </row> | ||
| 1687 | <row> | ||
| 1688 | <entry></entry> | ||
| 1689 | <entry></entry> | ||
| 1690 | <entry></entry> | ||
| 1691 | <entry>-</entry> | ||
| 1692 | <entry>-</entry> | ||
| 1693 | <entry>-</entry> | ||
| 1694 | <entry>-</entry> | ||
| 1695 | <entry>-</entry> | ||
| 1696 | <entry>-</entry> | ||
| 1697 | <entry>-</entry> | ||
| 1698 | <entry>-</entry> | ||
| 1699 | <entry>-</entry> | ||
| 1700 | <entry>-</entry> | ||
| 1701 | <entry>-</entry> | ||
| 1702 | <entry>-</entry> | ||
| 1703 | <entry>u<subscript>7</subscript></entry> | ||
| 1704 | <entry>u<subscript>6</subscript></entry> | ||
| 1705 | <entry>u<subscript>5</subscript></entry> | ||
| 1706 | <entry>u<subscript>4</subscript></entry> | ||
| 1707 | <entry>u<subscript>3</subscript></entry> | ||
| 1708 | <entry>u<subscript>2</subscript></entry> | ||
| 1709 | <entry>u<subscript>1</subscript></entry> | ||
| 1710 | <entry>u<subscript>0</subscript></entry> | ||
| 1711 | </row> | ||
| 1712 | <row> | ||
| 1713 | <entry></entry> | ||
| 1714 | <entry></entry> | ||
| 1715 | <entry></entry> | ||
| 1716 | <entry>-</entry> | ||
| 1717 | <entry>-</entry> | ||
| 1718 | <entry>-</entry> | ||
| 1719 | <entry>-</entry> | ||
| 1720 | <entry>-</entry> | ||
| 1721 | <entry>-</entry> | ||
| 1722 | <entry>-</entry> | ||
| 1723 | <entry>-</entry> | ||
| 1724 | <entry>-</entry> | ||
| 1725 | <entry>-</entry> | ||
| 1726 | <entry>-</entry> | ||
| 1727 | <entry>-</entry> | ||
| 1728 | <entry>y<subscript>7</subscript></entry> | ||
| 1729 | <entry>y<subscript>6</subscript></entry> | ||
| 1730 | <entry>y<subscript>5</subscript></entry> | ||
| 1731 | <entry>y<subscript>4</subscript></entry> | ||
| 1732 | <entry>y<subscript>3</subscript></entry> | ||
| 1733 | <entry>y<subscript>2</subscript></entry> | ||
| 1734 | <entry>y<subscript>1</subscript></entry> | ||
| 1735 | <entry>y<subscript>0</subscript></entry> | ||
| 1736 | </row> | ||
| 1737 | <row id="V4L2-MBUS-FMT-YUYV8-2X8"> | ||
| 1738 | <entry>V4L2_MBUS_FMT_YUYV8_2X8</entry> | ||
| 1739 | <entry>0x2008</entry> | ||
| 1740 | <entry></entry> | ||
| 1741 | <entry>-</entry> | ||
| 1742 | <entry>-</entry> | ||
| 1743 | <entry>-</entry> | ||
| 1744 | <entry>-</entry> | ||
| 1745 | <entry>-</entry> | ||
| 1746 | <entry>-</entry> | ||
| 1747 | <entry>-</entry> | ||
| 1748 | <entry>-</entry> | ||
| 1749 | <entry>-</entry> | ||
| 1750 | <entry>-</entry> | ||
| 1751 | <entry>-</entry> | ||
| 1752 | <entry>-</entry> | ||
| 1753 | <entry>y<subscript>7</subscript></entry> | ||
| 1754 | <entry>y<subscript>6</subscript></entry> | ||
| 1755 | <entry>y<subscript>5</subscript></entry> | ||
| 1756 | <entry>y<subscript>4</subscript></entry> | ||
| 1757 | <entry>y<subscript>3</subscript></entry> | ||
| 1758 | <entry>y<subscript>2</subscript></entry> | ||
| 1759 | <entry>y<subscript>1</subscript></entry> | ||
| 1760 | <entry>y<subscript>0</subscript></entry> | ||
| 1761 | </row> | ||
| 1762 | <row> | ||
| 1763 | <entry></entry> | ||
| 1764 | <entry></entry> | ||
| 1765 | <entry></entry> | ||
| 1766 | <entry>-</entry> | ||
| 1767 | <entry>-</entry> | ||
| 1768 | <entry>-</entry> | ||
| 1769 | <entry>-</entry> | ||
| 1770 | <entry>-</entry> | ||
| 1771 | <entry>-</entry> | ||
| 1772 | <entry>-</entry> | ||
| 1773 | <entry>-</entry> | ||
| 1774 | <entry>-</entry> | ||
| 1775 | <entry>-</entry> | ||
| 1776 | <entry>-</entry> | ||
| 1777 | <entry>-</entry> | ||
| 1778 | <entry>u<subscript>7</subscript></entry> | ||
| 1779 | <entry>u<subscript>6</subscript></entry> | ||
| 1780 | <entry>u<subscript>5</subscript></entry> | ||
| 1781 | <entry>u<subscript>4</subscript></entry> | ||
| 1782 | <entry>u<subscript>3</subscript></entry> | ||
| 1783 | <entry>u<subscript>2</subscript></entry> | ||
| 1784 | <entry>u<subscript>1</subscript></entry> | ||
| 1785 | <entry>u<subscript>0</subscript></entry> | ||
| 1786 | </row> | ||
| 1787 | <row> | ||
| 1788 | <entry></entry> | ||
| 1789 | <entry></entry> | ||
| 1790 | <entry></entry> | ||
| 1791 | <entry>-</entry> | ||
| 1792 | <entry>-</entry> | ||
| 1793 | <entry>-</entry> | ||
| 1794 | <entry>-</entry> | ||
| 1795 | <entry>-</entry> | ||
| 1796 | <entry>-</entry> | ||
| 1797 | <entry>-</entry> | ||
| 1798 | <entry>-</entry> | ||
| 1799 | <entry>-</entry> | ||
| 1800 | <entry>-</entry> | ||
| 1801 | <entry>-</entry> | ||
| 1802 | <entry>-</entry> | ||
| 1803 | <entry>y<subscript>7</subscript></entry> | ||
| 1804 | <entry>y<subscript>6</subscript></entry> | ||
| 1805 | <entry>y<subscript>5</subscript></entry> | ||
| 1806 | <entry>y<subscript>4</subscript></entry> | ||
| 1807 | <entry>y<subscript>3</subscript></entry> | ||
| 1808 | <entry>y<subscript>2</subscript></entry> | ||
| 1809 | <entry>y<subscript>1</subscript></entry> | ||
| 1810 | <entry>y<subscript>0</subscript></entry> | ||
| 1811 | </row> | ||
| 1812 | <row> | ||
| 1813 | <entry></entry> | ||
| 1814 | <entry></entry> | ||
| 1815 | <entry></entry> | ||
| 1816 | <entry>-</entry> | ||
| 1817 | <entry>-</entry> | ||
| 1818 | <entry>-</entry> | ||
| 1819 | <entry>-</entry> | ||
| 1820 | <entry>-</entry> | ||
| 1821 | <entry>-</entry> | ||
| 1822 | <entry>-</entry> | ||
| 1823 | <entry>-</entry> | ||
| 1824 | <entry>-</entry> | ||
| 1825 | <entry>-</entry> | ||
| 1826 | <entry>-</entry> | ||
| 1827 | <entry>-</entry> | ||
| 1828 | <entry>v<subscript>7</subscript></entry> | ||
| 1829 | <entry>v<subscript>6</subscript></entry> | ||
| 1830 | <entry>v<subscript>5</subscript></entry> | ||
| 1831 | <entry>v<subscript>4</subscript></entry> | ||
| 1832 | <entry>v<subscript>3</subscript></entry> | ||
| 1833 | <entry>v<subscript>2</subscript></entry> | ||
| 1834 | <entry>v<subscript>1</subscript></entry> | ||
| 1835 | <entry>v<subscript>0</subscript></entry> | ||
| 1836 | </row> | ||
| 1837 | <row id="V4L2-MBUS-FMT-YVYU8-2X8"> | ||
| 1838 | <entry>V4L2_MBUS_FMT_YVYU8_2X8</entry> | ||
| 1839 | <entry>0x2009</entry> | ||
| 1840 | <entry></entry> | ||
| 1841 | <entry>-</entry> | ||
| 1842 | <entry>-</entry> | ||
| 1843 | <entry>-</entry> | ||
| 1844 | <entry>-</entry> | ||
| 1845 | <entry>-</entry> | ||
| 1846 | <entry>-</entry> | ||
| 1847 | <entry>-</entry> | ||
| 1848 | <entry>-</entry> | ||
| 1849 | <entry>-</entry> | ||
| 1850 | <entry>-</entry> | ||
| 1851 | <entry>-</entry> | ||
| 1852 | <entry>-</entry> | ||
| 1853 | <entry>y<subscript>7</subscript></entry> | ||
| 1854 | <entry>y<subscript>6</subscript></entry> | ||
| 1855 | <entry>y<subscript>5</subscript></entry> | ||
| 1856 | <entry>y<subscript>4</subscript></entry> | ||
| 1857 | <entry>y<subscript>3</subscript></entry> | ||
| 1858 | <entry>y<subscript>2</subscript></entry> | ||
| 1859 | <entry>y<subscript>1</subscript></entry> | ||
| 1860 | <entry>y<subscript>0</subscript></entry> | ||
| 1861 | </row> | ||
| 1862 | <row> | ||
| 1863 | <entry></entry> | ||
| 1864 | <entry></entry> | ||
| 1865 | <entry></entry> | ||
| 1866 | <entry>-</entry> | ||
| 1867 | <entry>-</entry> | ||
| 1868 | <entry>-</entry> | ||
| 1869 | <entry>-</entry> | ||
| 1870 | <entry>-</entry> | ||
| 1871 | <entry>-</entry> | ||
| 1872 | <entry>-</entry> | ||
| 1873 | <entry>-</entry> | ||
| 1874 | <entry>-</entry> | ||
| 1875 | <entry>-</entry> | ||
| 1876 | <entry>-</entry> | ||
| 1877 | <entry>-</entry> | ||
| 1878 | <entry>v<subscript>7</subscript></entry> | ||
| 1879 | <entry>v<subscript>6</subscript></entry> | ||
| 1880 | <entry>v<subscript>5</subscript></entry> | ||
| 1881 | <entry>v<subscript>4</subscript></entry> | ||
| 1882 | <entry>v<subscript>3</subscript></entry> | ||
| 1883 | <entry>v<subscript>2</subscript></entry> | ||
| 1884 | <entry>v<subscript>1</subscript></entry> | ||
| 1885 | <entry>v<subscript>0</subscript></entry> | ||
| 1886 | </row> | ||
| 1887 | <row> | ||
| 1888 | <entry></entry> | ||
| 1889 | <entry></entry> | ||
| 1890 | <entry></entry> | ||
| 1891 | <entry>-</entry> | ||
| 1892 | <entry>-</entry> | ||
| 1893 | <entry>-</entry> | ||
| 1894 | <entry>-</entry> | ||
| 1895 | <entry>-</entry> | ||
| 1896 | <entry>-</entry> | ||
| 1897 | <entry>-</entry> | ||
| 1898 | <entry>-</entry> | ||
| 1899 | <entry>-</entry> | ||
| 1900 | <entry>-</entry> | ||
| 1901 | <entry>-</entry> | ||
| 1902 | <entry>-</entry> | ||
| 1903 | <entry>y<subscript>7</subscript></entry> | ||
| 1904 | <entry>y<subscript>6</subscript></entry> | ||
| 1905 | <entry>y<subscript>5</subscript></entry> | ||
| 1906 | <entry>y<subscript>4</subscript></entry> | ||
| 1907 | <entry>y<subscript>3</subscript></entry> | ||
| 1908 | <entry>y<subscript>2</subscript></entry> | ||
| 1909 | <entry>y<subscript>1</subscript></entry> | ||
| 1910 | <entry>y<subscript>0</subscript></entry> | ||
| 1911 | </row> | ||
| 1912 | <row> | ||
| 1913 | <entry></entry> | ||
| 1914 | <entry></entry> | ||
| 1915 | <entry></entry> | ||
| 1916 | <entry>-</entry> | ||
| 1917 | <entry>-</entry> | ||
| 1918 | <entry>-</entry> | ||
| 1919 | <entry>-</entry> | ||
| 1920 | <entry>-</entry> | ||
| 1921 | <entry>-</entry> | ||
| 1922 | <entry>-</entry> | ||
| 1923 | <entry>-</entry> | ||
| 1924 | <entry>-</entry> | ||
| 1925 | <entry>-</entry> | ||
| 1926 | <entry>-</entry> | ||
| 1927 | <entry>-</entry> | ||
| 1928 | <entry>u<subscript>7</subscript></entry> | ||
| 1929 | <entry>u<subscript>6</subscript></entry> | ||
| 1930 | <entry>u<subscript>5</subscript></entry> | ||
| 1931 | <entry>u<subscript>4</subscript></entry> | ||
| 1932 | <entry>u<subscript>3</subscript></entry> | ||
| 1933 | <entry>u<subscript>2</subscript></entry> | ||
| 1934 | <entry>u<subscript>1</subscript></entry> | ||
| 1935 | <entry>u<subscript>0</subscript></entry> | ||
| 1936 | </row> | ||
| 1937 | <row id="V4L2-MBUS-FMT-Y10-1X10"> | ||
| 1938 | <entry>V4L2_MBUS_FMT_Y10_1X10</entry> | ||
| 1939 | <entry>0x200a</entry> | ||
| 1940 | <entry></entry> | ||
| 1941 | <entry>-</entry> | ||
| 1942 | <entry>-</entry> | ||
| 1943 | <entry>-</entry> | ||
| 1944 | <entry>-</entry> | ||
| 1945 | <entry>-</entry> | ||
| 1946 | <entry>-</entry> | ||
| 1947 | <entry>-</entry> | ||
| 1948 | <entry>-</entry> | ||
| 1949 | <entry>-</entry> | ||
| 1950 | <entry>-</entry> | ||
| 1951 | <entry>y<subscript>9</subscript></entry> | ||
| 1952 | <entry>y<subscript>8</subscript></entry> | ||
| 1953 | <entry>y<subscript>7</subscript></entry> | ||
| 1954 | <entry>y<subscript>6</subscript></entry> | ||
| 1955 | <entry>y<subscript>5</subscript></entry> | ||
| 1956 | <entry>y<subscript>4</subscript></entry> | ||
| 1957 | <entry>y<subscript>3</subscript></entry> | ||
| 1958 | <entry>y<subscript>2</subscript></entry> | ||
| 1959 | <entry>y<subscript>1</subscript></entry> | ||
| 1960 | <entry>y<subscript>0</subscript></entry> | ||
| 1961 | </row> | ||
| 1962 | <row id="V4L2-MBUS-FMT-YUYV10-2X10"> | ||
| 1963 | <entry>V4L2_MBUS_FMT_YUYV10_2X10</entry> | ||
| 1964 | <entry>0x200b</entry> | ||
| 1965 | <entry></entry> | ||
| 1966 | <entry>-</entry> | ||
| 1967 | <entry>-</entry> | ||
| 1968 | <entry>-</entry> | ||
| 1969 | <entry>-</entry> | ||
| 1970 | <entry>-</entry> | ||
| 1971 | <entry>-</entry> | ||
| 1972 | <entry>-</entry> | ||
| 1973 | <entry>-</entry> | ||
| 1974 | <entry>-</entry> | ||
| 1975 | <entry>-</entry> | ||
| 1976 | <entry>y<subscript>9</subscript></entry> | ||
| 1977 | <entry>y<subscript>8</subscript></entry> | ||
| 1978 | <entry>y<subscript>7</subscript></entry> | ||
| 1979 | <entry>y<subscript>6</subscript></entry> | ||
| 1980 | <entry>y<subscript>5</subscript></entry> | ||
| 1981 | <entry>y<subscript>4</subscript></entry> | ||
| 1982 | <entry>y<subscript>3</subscript></entry> | ||
| 1983 | <entry>y<subscript>2</subscript></entry> | ||
| 1984 | <entry>y<subscript>1</subscript></entry> | ||
| 1985 | <entry>y<subscript>0</subscript></entry> | ||
| 1986 | </row> | ||
| 1987 | <row> | ||
| 1988 | <entry></entry> | ||
| 1989 | <entry></entry> | ||
| 1990 | <entry></entry> | ||
| 1991 | <entry>-</entry> | ||
| 1992 | <entry>-</entry> | ||
| 1993 | <entry>-</entry> | ||
| 1994 | <entry>-</entry> | ||
| 1995 | <entry>-</entry> | ||
| 1996 | <entry>-</entry> | ||
| 1997 | <entry>-</entry> | ||
| 1998 | <entry>-</entry> | ||
| 1999 | <entry>-</entry> | ||
| 2000 | <entry>-</entry> | ||
| 2001 | <entry>u<subscript>9</subscript></entry> | ||
| 2002 | <entry>u<subscript>8</subscript></entry> | ||
| 2003 | <entry>u<subscript>7</subscript></entry> | ||
| 2004 | <entry>u<subscript>6</subscript></entry> | ||
| 2005 | <entry>u<subscript>5</subscript></entry> | ||
| 2006 | <entry>u<subscript>4</subscript></entry> | ||
| 2007 | <entry>u<subscript>3</subscript></entry> | ||
| 2008 | <entry>u<subscript>2</subscript></entry> | ||
| 2009 | <entry>u<subscript>1</subscript></entry> | ||
| 2010 | <entry>u<subscript>0</subscript></entry> | ||
| 2011 | </row> | ||
| 2012 | <row> | ||
| 2013 | <entry></entry> | ||
| 2014 | <entry></entry> | ||
| 2015 | <entry></entry> | ||
| 2016 | <entry>-</entry> | ||
| 2017 | <entry>-</entry> | ||
| 2018 | <entry>-</entry> | ||
| 2019 | <entry>-</entry> | ||
| 2020 | <entry>-</entry> | ||
| 2021 | <entry>-</entry> | ||
| 2022 | <entry>-</entry> | ||
| 2023 | <entry>-</entry> | ||
| 2024 | <entry>-</entry> | ||
| 2025 | <entry>-</entry> | ||
| 2026 | <entry>y<subscript>9</subscript></entry> | ||
| 2027 | <entry>y<subscript>8</subscript></entry> | ||
| 2028 | <entry>y<subscript>7</subscript></entry> | ||
| 2029 | <entry>y<subscript>6</subscript></entry> | ||
| 2030 | <entry>y<subscript>5</subscript></entry> | ||
| 2031 | <entry>y<subscript>4</subscript></entry> | ||
| 2032 | <entry>y<subscript>3</subscript></entry> | ||
| 2033 | <entry>y<subscript>2</subscript></entry> | ||
| 2034 | <entry>y<subscript>1</subscript></entry> | ||
| 2035 | <entry>y<subscript>0</subscript></entry> | ||
| 2036 | </row> | ||
| 2037 | <row> | ||
| 2038 | <entry></entry> | ||
| 2039 | <entry></entry> | ||
| 2040 | <entry></entry> | ||
| 2041 | <entry>-</entry> | ||
| 2042 | <entry>-</entry> | ||
| 2043 | <entry>-</entry> | ||
| 2044 | <entry>-</entry> | ||
| 2045 | <entry>-</entry> | ||
| 2046 | <entry>-</entry> | ||
| 2047 | <entry>-</entry> | ||
| 2048 | <entry>-</entry> | ||
| 2049 | <entry>-</entry> | ||
| 2050 | <entry>-</entry> | ||
| 2051 | <entry>v<subscript>9</subscript></entry> | ||
| 2052 | <entry>v<subscript>8</subscript></entry> | ||
| 2053 | <entry>v<subscript>7</subscript></entry> | ||
| 2054 | <entry>v<subscript>6</subscript></entry> | ||
| 2055 | <entry>v<subscript>5</subscript></entry> | ||
| 2056 | <entry>v<subscript>4</subscript></entry> | ||
| 2057 | <entry>v<subscript>3</subscript></entry> | ||
| 2058 | <entry>v<subscript>2</subscript></entry> | ||
| 2059 | <entry>v<subscript>1</subscript></entry> | ||
| 2060 | <entry>v<subscript>0</subscript></entry> | ||
| 2061 | </row> | ||
| 2062 | <row id="V4L2-MBUS-FMT-YVYU10-2X10"> | ||
| 2063 | <entry>V4L2_MBUS_FMT_YVYU10_2X10</entry> | ||
| 2064 | <entry>0x200c</entry> | ||
| 2065 | <entry></entry> | ||
| 2066 | <entry>-</entry> | ||
| 2067 | <entry>-</entry> | ||
| 2068 | <entry>-</entry> | ||
| 2069 | <entry>-</entry> | ||
| 2070 | <entry>-</entry> | ||
| 2071 | <entry>-</entry> | ||
| 2072 | <entry>-</entry> | ||
| 2073 | <entry>-</entry> | ||
| 2074 | <entry>-</entry> | ||
| 2075 | <entry>-</entry> | ||
| 2076 | <entry>y<subscript>9</subscript></entry> | ||
| 2077 | <entry>y<subscript>8</subscript></entry> | ||
| 2078 | <entry>y<subscript>7</subscript></entry> | ||
| 2079 | <entry>y<subscript>6</subscript></entry> | ||
| 2080 | <entry>y<subscript>5</subscript></entry> | ||
| 2081 | <entry>y<subscript>4</subscript></entry> | ||
| 2082 | <entry>y<subscript>3</subscript></entry> | ||
| 2083 | <entry>y<subscript>2</subscript></entry> | ||
| 2084 | <entry>y<subscript>1</subscript></entry> | ||
| 2085 | <entry>y<subscript>0</subscript></entry> | ||
| 2086 | </row> | ||
| 2087 | <row> | ||
| 2088 | <entry></entry> | ||
| 2089 | <entry></entry> | ||
| 2090 | <entry></entry> | ||
| 2091 | <entry>-</entry> | ||
| 2092 | <entry>-</entry> | ||
| 2093 | <entry>-</entry> | ||
| 2094 | <entry>-</entry> | ||
| 2095 | <entry>-</entry> | ||
| 2096 | <entry>-</entry> | ||
| 2097 | <entry>-</entry> | ||
| 2098 | <entry>-</entry> | ||
| 2099 | <entry>-</entry> | ||
| 2100 | <entry>-</entry> | ||
| 2101 | <entry>v<subscript>9</subscript></entry> | ||
| 2102 | <entry>v<subscript>8</subscript></entry> | ||
| 2103 | <entry>v<subscript>7</subscript></entry> | ||
| 2104 | <entry>v<subscript>6</subscript></entry> | ||
| 2105 | <entry>v<subscript>5</subscript></entry> | ||
| 2106 | <entry>v<subscript>4</subscript></entry> | ||
| 2107 | <entry>v<subscript>3</subscript></entry> | ||
| 2108 | <entry>v<subscript>2</subscript></entry> | ||
| 2109 | <entry>v<subscript>1</subscript></entry> | ||
| 2110 | <entry>v<subscript>0</subscript></entry> | ||
| 2111 | </row> | ||
| 2112 | <row> | ||
| 2113 | <entry></entry> | ||
| 2114 | <entry></entry> | ||
| 2115 | <entry></entry> | ||
| 2116 | <entry>-</entry> | ||
| 2117 | <entry>-</entry> | ||
| 2118 | <entry>-</entry> | ||
| 2119 | <entry>-</entry> | ||
| 2120 | <entry>-</entry> | ||
| 2121 | <entry>-</entry> | ||
| 2122 | <entry>-</entry> | ||
| 2123 | <entry>-</entry> | ||
| 2124 | <entry>-</entry> | ||
| 2125 | <entry>-</entry> | ||
| 2126 | <entry>y<subscript>9</subscript></entry> | ||
| 2127 | <entry>y<subscript>8</subscript></entry> | ||
| 2128 | <entry>y<subscript>7</subscript></entry> | ||
| 2129 | <entry>y<subscript>6</subscript></entry> | ||
| 2130 | <entry>y<subscript>5</subscript></entry> | ||
| 2131 | <entry>y<subscript>4</subscript></entry> | ||
| 2132 | <entry>y<subscript>3</subscript></entry> | ||
| 2133 | <entry>y<subscript>2</subscript></entry> | ||
| 2134 | <entry>y<subscript>1</subscript></entry> | ||
| 2135 | <entry>y<subscript>0</subscript></entry> | ||
| 2136 | </row> | ||
| 2137 | <row> | ||
| 2138 | <entry></entry> | ||
| 2139 | <entry></entry> | ||
| 2140 | <entry></entry> | ||
| 2141 | <entry>-</entry> | ||
| 2142 | <entry>-</entry> | ||
| 2143 | <entry>-</entry> | ||
| 2144 | <entry>-</entry> | ||
| 2145 | <entry>-</entry> | ||
| 2146 | <entry>-</entry> | ||
| 2147 | <entry>-</entry> | ||
| 2148 | <entry>-</entry> | ||
| 2149 | <entry>-</entry> | ||
| 2150 | <entry>-</entry> | ||
| 2151 | <entry>u<subscript>9</subscript></entry> | ||
| 2152 | <entry>u<subscript>8</subscript></entry> | ||
| 2153 | <entry>u<subscript>7</subscript></entry> | ||
| 2154 | <entry>u<subscript>6</subscript></entry> | ||
| 2155 | <entry>u<subscript>5</subscript></entry> | ||
| 2156 | <entry>u<subscript>4</subscript></entry> | ||
| 2157 | <entry>u<subscript>3</subscript></entry> | ||
| 2158 | <entry>u<subscript>2</subscript></entry> | ||
| 2159 | <entry>u<subscript>1</subscript></entry> | ||
| 2160 | <entry>u<subscript>0</subscript></entry> | ||
| 2161 | </row> | ||
| 2162 | <row id="V4L2-MBUS-FMT-UYVY8-1X16"> | ||
| 2163 | <entry>V4L2_MBUS_FMT_UYVY8_1X16</entry> | ||
| 2164 | <entry>0x200f</entry> | ||
| 2165 | <entry></entry> | ||
| 2166 | <entry>-</entry> | ||
| 2167 | <entry>-</entry> | ||
| 2168 | <entry>-</entry> | ||
| 2169 | <entry>-</entry> | ||
| 2170 | <entry>u<subscript>7</subscript></entry> | ||
| 2171 | <entry>u<subscript>6</subscript></entry> | ||
| 2172 | <entry>u<subscript>5</subscript></entry> | ||
| 2173 | <entry>u<subscript>4</subscript></entry> | ||
| 2174 | <entry>u<subscript>3</subscript></entry> | ||
| 2175 | <entry>u<subscript>2</subscript></entry> | ||
| 2176 | <entry>u<subscript>1</subscript></entry> | ||
| 2177 | <entry>u<subscript>0</subscript></entry> | ||
| 2178 | <entry>y<subscript>7</subscript></entry> | ||
| 2179 | <entry>y<subscript>6</subscript></entry> | ||
| 2180 | <entry>y<subscript>5</subscript></entry> | ||
| 2181 | <entry>y<subscript>4</subscript></entry> | ||
| 2182 | <entry>y<subscript>3</subscript></entry> | ||
| 2183 | <entry>y<subscript>2</subscript></entry> | ||
| 2184 | <entry>y<subscript>1</subscript></entry> | ||
| 2185 | <entry>y<subscript>0</subscript></entry> | ||
| 2186 | </row> | ||
| 2187 | <row> | ||
| 2188 | <entry></entry> | ||
| 2189 | <entry></entry> | ||
| 2190 | <entry></entry> | ||
| 2191 | <entry>-</entry> | ||
| 2192 | <entry>-</entry> | ||
| 2193 | <entry>-</entry> | ||
| 2194 | <entry>-</entry> | ||
| 2195 | <entry>v<subscript>7</subscript></entry> | ||
| 2196 | <entry>v<subscript>6</subscript></entry> | ||
| 2197 | <entry>v<subscript>5</subscript></entry> | ||
| 2198 | <entry>v<subscript>4</subscript></entry> | ||
| 2199 | <entry>v<subscript>3</subscript></entry> | ||
| 2200 | <entry>v<subscript>2</subscript></entry> | ||
| 2201 | <entry>v<subscript>1</subscript></entry> | ||
| 2202 | <entry>v<subscript>0</subscript></entry> | ||
| 2203 | <entry>y<subscript>7</subscript></entry> | ||
| 2204 | <entry>y<subscript>6</subscript></entry> | ||
| 2205 | <entry>y<subscript>5</subscript></entry> | ||
| 2206 | <entry>y<subscript>4</subscript></entry> | ||
| 2207 | <entry>y<subscript>3</subscript></entry> | ||
| 2208 | <entry>y<subscript>2</subscript></entry> | ||
| 2209 | <entry>y<subscript>1</subscript></entry> | ||
| 2210 | <entry>y<subscript>0</subscript></entry> | ||
| 2211 | </row> | ||
| 2212 | <row id="V4L2-MBUS-FMT-VYUY8-1X16"> | ||
| 2213 | <entry>V4L2_MBUS_FMT_VYUY8_1X16</entry> | ||
| 2214 | <entry>0x2010</entry> | ||
| 2215 | <entry></entry> | ||
| 2216 | <entry>-</entry> | ||
| 2217 | <entry>-</entry> | ||
| 2218 | <entry>-</entry> | ||
| 2219 | <entry>-</entry> | ||
| 2220 | <entry>v<subscript>7</subscript></entry> | ||
| 2221 | <entry>v<subscript>6</subscript></entry> | ||
| 2222 | <entry>v<subscript>5</subscript></entry> | ||
| 2223 | <entry>v<subscript>4</subscript></entry> | ||
| 2224 | <entry>v<subscript>3</subscript></entry> | ||
| 2225 | <entry>v<subscript>2</subscript></entry> | ||
| 2226 | <entry>v<subscript>1</subscript></entry> | ||
| 2227 | <entry>v<subscript>0</subscript></entry> | ||
| 2228 | <entry>y<subscript>7</subscript></entry> | ||
| 2229 | <entry>y<subscript>6</subscript></entry> | ||
| 2230 | <entry>y<subscript>5</subscript></entry> | ||
| 2231 | <entry>y<subscript>4</subscript></entry> | ||
| 2232 | <entry>y<subscript>3</subscript></entry> | ||
| 2233 | <entry>y<subscript>2</subscript></entry> | ||
| 2234 | <entry>y<subscript>1</subscript></entry> | ||
| 2235 | <entry>y<subscript>0</subscript></entry> | ||
| 2236 | </row> | ||
| 2237 | <row> | ||
| 2238 | <entry></entry> | ||
| 2239 | <entry></entry> | ||
| 2240 | <entry></entry> | ||
| 2241 | <entry>-</entry> | ||
| 2242 | <entry>-</entry> | ||
| 2243 | <entry>-</entry> | ||
| 2244 | <entry>-</entry> | ||
| 2245 | <entry>u<subscript>7</subscript></entry> | ||
| 2246 | <entry>u<subscript>6</subscript></entry> | ||
| 2247 | <entry>u<subscript>5</subscript></entry> | ||
| 2248 | <entry>u<subscript>4</subscript></entry> | ||
| 2249 | <entry>u<subscript>3</subscript></entry> | ||
| 2250 | <entry>u<subscript>2</subscript></entry> | ||
| 2251 | <entry>u<subscript>1</subscript></entry> | ||
| 2252 | <entry>u<subscript>0</subscript></entry> | ||
| 2253 | <entry>y<subscript>7</subscript></entry> | ||
| 2254 | <entry>y<subscript>6</subscript></entry> | ||
| 2255 | <entry>y<subscript>5</subscript></entry> | ||
| 2256 | <entry>y<subscript>4</subscript></entry> | ||
| 2257 | <entry>y<subscript>3</subscript></entry> | ||
| 2258 | <entry>y<subscript>2</subscript></entry> | ||
| 2259 | <entry>y<subscript>1</subscript></entry> | ||
| 2260 | <entry>y<subscript>0</subscript></entry> | ||
| 2261 | </row> | ||
| 2262 | <row id="V4L2-MBUS-FMT-YUYV8-1X16"> | ||
| 2263 | <entry>V4L2_MBUS_FMT_YUYV8_1X16</entry> | ||
| 2264 | <entry>0x2011</entry> | ||
| 2265 | <entry></entry> | ||
| 2266 | <entry>-</entry> | ||
| 2267 | <entry>-</entry> | ||
| 2268 | <entry>-</entry> | ||
| 2269 | <entry>-</entry> | ||
| 2270 | <entry>y<subscript>7</subscript></entry> | ||
| 2271 | <entry>y<subscript>6</subscript></entry> | ||
| 2272 | <entry>y<subscript>5</subscript></entry> | ||
| 2273 | <entry>y<subscript>4</subscript></entry> | ||
| 2274 | <entry>y<subscript>3</subscript></entry> | ||
| 2275 | <entry>y<subscript>2</subscript></entry> | ||
| 2276 | <entry>y<subscript>1</subscript></entry> | ||
| 2277 | <entry>y<subscript>0</subscript></entry> | ||
| 2278 | <entry>u<subscript>7</subscript></entry> | ||
| 2279 | <entry>u<subscript>6</subscript></entry> | ||
| 2280 | <entry>u<subscript>5</subscript></entry> | ||
| 2281 | <entry>u<subscript>4</subscript></entry> | ||
| 2282 | <entry>u<subscript>3</subscript></entry> | ||
| 2283 | <entry>u<subscript>2</subscript></entry> | ||
| 2284 | <entry>u<subscript>1</subscript></entry> | ||
| 2285 | <entry>u<subscript>0</subscript></entry> | ||
| 2286 | </row> | ||
| 2287 | <row> | ||
| 2288 | <entry></entry> | ||
| 2289 | <entry></entry> | ||
| 2290 | <entry></entry> | ||
| 2291 | <entry>-</entry> | ||
| 2292 | <entry>-</entry> | ||
| 2293 | <entry>-</entry> | ||
| 2294 | <entry>-</entry> | ||
| 2295 | <entry>y<subscript>7</subscript></entry> | ||
| 2296 | <entry>y<subscript>6</subscript></entry> | ||
| 2297 | <entry>y<subscript>5</subscript></entry> | ||
| 2298 | <entry>y<subscript>4</subscript></entry> | ||
| 2299 | <entry>y<subscript>3</subscript></entry> | ||
| 2300 | <entry>y<subscript>2</subscript></entry> | ||
| 2301 | <entry>y<subscript>1</subscript></entry> | ||
| 2302 | <entry>y<subscript>0</subscript></entry> | ||
| 2303 | <entry>v<subscript>7</subscript></entry> | ||
| 2304 | <entry>v<subscript>6</subscript></entry> | ||
| 2305 | <entry>v<subscript>5</subscript></entry> | ||
| 2306 | <entry>v<subscript>4</subscript></entry> | ||
| 2307 | <entry>v<subscript>3</subscript></entry> | ||
| 2308 | <entry>v<subscript>2</subscript></entry> | ||
| 2309 | <entry>v<subscript>1</subscript></entry> | ||
| 2310 | <entry>v<subscript>0</subscript></entry> | ||
| 2311 | </row> | ||
| 2312 | <row id="V4L2-MBUS-FMT-YVYU8-1X16"> | ||
| 2313 | <entry>V4L2_MBUS_FMT_YVYU8_1X16</entry> | ||
| 2314 | <entry>0x2012</entry> | ||
| 2315 | <entry></entry> | ||
| 2316 | <entry>-</entry> | ||
| 2317 | <entry>-</entry> | ||
| 2318 | <entry>-</entry> | ||
| 2319 | <entry>-</entry> | ||
| 2320 | <entry>y<subscript>7</subscript></entry> | ||
| 2321 | <entry>y<subscript>6</subscript></entry> | ||
| 2322 | <entry>y<subscript>5</subscript></entry> | ||
| 2323 | <entry>y<subscript>4</subscript></entry> | ||
| 2324 | <entry>y<subscript>3</subscript></entry> | ||
| 2325 | <entry>y<subscript>2</subscript></entry> | ||
| 2326 | <entry>y<subscript>1</subscript></entry> | ||
| 2327 | <entry>y<subscript>0</subscript></entry> | ||
| 2328 | <entry>v<subscript>7</subscript></entry> | ||
| 2329 | <entry>v<subscript>6</subscript></entry> | ||
| 2330 | <entry>v<subscript>5</subscript></entry> | ||
| 2331 | <entry>v<subscript>4</subscript></entry> | ||
| 2332 | <entry>v<subscript>3</subscript></entry> | ||
| 2333 | <entry>v<subscript>2</subscript></entry> | ||
| 2334 | <entry>v<subscript>1</subscript></entry> | ||
| 2335 | <entry>v<subscript>0</subscript></entry> | ||
| 2336 | </row> | ||
| 2337 | <row> | ||
| 2338 | <entry></entry> | ||
| 2339 | <entry></entry> | ||
| 2340 | <entry></entry> | ||
| 2341 | <entry>-</entry> | ||
| 2342 | <entry>-</entry> | ||
| 2343 | <entry>-</entry> | ||
| 2344 | <entry>-</entry> | ||
| 2345 | <entry>y<subscript>7</subscript></entry> | ||
| 2346 | <entry>y<subscript>6</subscript></entry> | ||
| 2347 | <entry>y<subscript>5</subscript></entry> | ||
| 2348 | <entry>y<subscript>4</subscript></entry> | ||
| 2349 | <entry>y<subscript>3</subscript></entry> | ||
| 2350 | <entry>y<subscript>2</subscript></entry> | ||
| 2351 | <entry>y<subscript>1</subscript></entry> | ||
| 2352 | <entry>y<subscript>0</subscript></entry> | ||
| 2353 | <entry>u<subscript>7</subscript></entry> | ||
| 2354 | <entry>u<subscript>6</subscript></entry> | ||
| 2355 | <entry>u<subscript>5</subscript></entry> | ||
| 2356 | <entry>u<subscript>4</subscript></entry> | ||
| 2357 | <entry>u<subscript>3</subscript></entry> | ||
| 2358 | <entry>u<subscript>2</subscript></entry> | ||
| 2359 | <entry>u<subscript>1</subscript></entry> | ||
| 2360 | <entry>u<subscript>0</subscript></entry> | ||
| 2361 | </row> | ||
| 2362 | <row id="V4L2-MBUS-FMT-YUYV10-1X20"> | ||
| 2363 | <entry>V4L2_MBUS_FMT_YUYV10_1X20</entry> | ||
| 2364 | <entry>0x200d</entry> | ||
| 2365 | <entry></entry> | ||
| 2366 | <entry>y<subscript>9</subscript></entry> | ||
| 2367 | <entry>y<subscript>8</subscript></entry> | ||
| 2368 | <entry>y<subscript>7</subscript></entry> | ||
| 2369 | <entry>y<subscript>6</subscript></entry> | ||
| 2370 | <entry>y<subscript>5</subscript></entry> | ||
| 2371 | <entry>y<subscript>4</subscript></entry> | ||
| 2372 | <entry>y<subscript>3</subscript></entry> | ||
| 2373 | <entry>y<subscript>2</subscript></entry> | ||
| 2374 | <entry>y<subscript>1</subscript></entry> | ||
| 2375 | <entry>y<subscript>0</subscript></entry> | ||
| 2376 | <entry>u<subscript>9</subscript></entry> | ||
| 2377 | <entry>u<subscript>8</subscript></entry> | ||
| 2378 | <entry>u<subscript>7</subscript></entry> | ||
| 2379 | <entry>u<subscript>6</subscript></entry> | ||
| 2380 | <entry>u<subscript>5</subscript></entry> | ||
| 2381 | <entry>u<subscript>4</subscript></entry> | ||
| 2382 | <entry>u<subscript>3</subscript></entry> | ||
| 2383 | <entry>u<subscript>2</subscript></entry> | ||
| 2384 | <entry>u<subscript>1</subscript></entry> | ||
| 2385 | <entry>u<subscript>0</subscript></entry> | ||
| 2386 | </row> | ||
| 2387 | <row> | ||
| 2388 | <entry></entry> | ||
| 2389 | <entry></entry> | ||
| 2390 | <entry></entry> | ||
| 2391 | <entry>y<subscript>9</subscript></entry> | ||
| 2392 | <entry>y<subscript>8</subscript></entry> | ||
| 2393 | <entry>y<subscript>7</subscript></entry> | ||
| 2394 | <entry>y<subscript>6</subscript></entry> | ||
| 2395 | <entry>y<subscript>5</subscript></entry> | ||
| 2396 | <entry>y<subscript>4</subscript></entry> | ||
| 2397 | <entry>y<subscript>3</subscript></entry> | ||
| 2398 | <entry>y<subscript>2</subscript></entry> | ||
| 2399 | <entry>y<subscript>1</subscript></entry> | ||
| 2400 | <entry>y<subscript>0</subscript></entry> | ||
| 2401 | <entry>v<subscript>9</subscript></entry> | ||
| 2402 | <entry>v<subscript>8</subscript></entry> | ||
| 2403 | <entry>v<subscript>7</subscript></entry> | ||
| 2404 | <entry>v<subscript>6</subscript></entry> | ||
| 2405 | <entry>v<subscript>5</subscript></entry> | ||
| 2406 | <entry>v<subscript>4</subscript></entry> | ||
| 2407 | <entry>v<subscript>3</subscript></entry> | ||
| 2408 | <entry>v<subscript>2</subscript></entry> | ||
| 2409 | <entry>v<subscript>1</subscript></entry> | ||
| 2410 | <entry>v<subscript>0</subscript></entry> | ||
| 2411 | </row> | ||
| 2412 | <row id="V4L2-MBUS-FMT-YVYU10-1X20"> | ||
| 2413 | <entry>V4L2_MBUS_FMT_YVYU10_1X20</entry> | ||
| 2414 | <entry>0x200e</entry> | ||
| 2415 | <entry></entry> | ||
| 2416 | <entry>y<subscript>9</subscript></entry> | ||
| 2417 | <entry>y<subscript>8</subscript></entry> | ||
| 2418 | <entry>y<subscript>7</subscript></entry> | ||
| 2419 | <entry>y<subscript>6</subscript></entry> | ||
| 2420 | <entry>y<subscript>5</subscript></entry> | ||
| 2421 | <entry>y<subscript>4</subscript></entry> | ||
| 2422 | <entry>y<subscript>3</subscript></entry> | ||
| 2423 | <entry>y<subscript>2</subscript></entry> | ||
| 2424 | <entry>y<subscript>1</subscript></entry> | ||
| 2425 | <entry>y<subscript>0</subscript></entry> | ||
| 2426 | <entry>v<subscript>9</subscript></entry> | ||
| 2427 | <entry>v<subscript>8</subscript></entry> | ||
| 2428 | <entry>v<subscript>7</subscript></entry> | ||
| 2429 | <entry>v<subscript>6</subscript></entry> | ||
| 2430 | <entry>v<subscript>5</subscript></entry> | ||
| 2431 | <entry>v<subscript>4</subscript></entry> | ||
| 2432 | <entry>v<subscript>3</subscript></entry> | ||
| 2433 | <entry>v<subscript>2</subscript></entry> | ||
| 2434 | <entry>v<subscript>1</subscript></entry> | ||
| 2435 | <entry>v<subscript>0</subscript></entry> | ||
| 2436 | </row> | ||
| 2437 | <row> | ||
| 2438 | <entry></entry> | ||
| 2439 | <entry></entry> | ||
| 2440 | <entry></entry> | ||
| 2441 | <entry>y<subscript>9</subscript></entry> | ||
| 2442 | <entry>y<subscript>8</subscript></entry> | ||
| 2443 | <entry>y<subscript>7</subscript></entry> | ||
| 2444 | <entry>y<subscript>6</subscript></entry> | ||
| 2445 | <entry>y<subscript>5</subscript></entry> | ||
| 2446 | <entry>y<subscript>4</subscript></entry> | ||
| 2447 | <entry>y<subscript>3</subscript></entry> | ||
| 2448 | <entry>y<subscript>2</subscript></entry> | ||
| 2449 | <entry>y<subscript>1</subscript></entry> | ||
| 2450 | <entry>y<subscript>0</subscript></entry> | ||
| 2451 | <entry>u<subscript>9</subscript></entry> | ||
| 2452 | <entry>u<subscript>8</subscript></entry> | ||
| 2453 | <entry>u<subscript>7</subscript></entry> | ||
| 2454 | <entry>u<subscript>6</subscript></entry> | ||
| 2455 | <entry>u<subscript>5</subscript></entry> | ||
| 2456 | <entry>u<subscript>4</subscript></entry> | ||
| 2457 | <entry>u<subscript>3</subscript></entry> | ||
| 2458 | <entry>u<subscript>2</subscript></entry> | ||
| 2459 | <entry>u<subscript>1</subscript></entry> | ||
| 2460 | <entry>u<subscript>0</subscript></entry> | ||
| 2461 | </row> | ||
| 2462 | </tbody> | ||
| 2463 | </tgroup> | ||
| 2464 | </table> | ||
| 2465 | </section> | ||
| 2466 | </section> | ||
| 2467 | </section> | ||
diff --git a/Documentation/DocBook/v4l/v4l2.xml b/Documentation/DocBook/v4l/v4l2.xml index 9288af96de34..a7fd76d0dac1 100644 --- a/Documentation/DocBook/v4l/v4l2.xml +++ b/Documentation/DocBook/v4l/v4l2.xml | |||
| @@ -85,6 +85,17 @@ Remote Controller chapter.</contrib> | |||
| 85 | </address> | 85 | </address> |
| 86 | </affiliation> | 86 | </affiliation> |
| 87 | </author> | 87 | </author> |
| 88 | |||
| 89 | <author> | ||
| 90 | <firstname>Pawel</firstname> | ||
| 91 | <surname>Osciak</surname> | ||
| 92 | <contrib>Designed and documented the multi-planar API.</contrib> | ||
| 93 | <affiliation> | ||
| 94 | <address> | ||
| 95 | <email>pawel AT osciak.com</email> | ||
| 96 | </address> | ||
| 97 | </affiliation> | ||
| 98 | </author> | ||
| 88 | </authorgroup> | 99 | </authorgroup> |
| 89 | 100 | ||
| 90 | <copyright> | 101 | <copyright> |
| @@ -102,7 +113,8 @@ Remote Controller chapter.</contrib> | |||
| 102 | <year>2010</year> | 113 | <year>2010</year> |
| 103 | <year>2011</year> | 114 | <year>2011</year> |
| 104 | <holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin | 115 | <holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin |
| 105 | Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab</holder> | 116 | Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab, |
| 117 | Pawel Osciak</holder> | ||
| 106 | </copyright> | 118 | </copyright> |
| 107 | <legalnotice> | 119 | <legalnotice> |
| 108 | <para>Except when explicitly stated as GPL, programming examples within | 120 | <para>Except when explicitly stated as GPL, programming examples within |
| @@ -116,6 +128,13 @@ structs, ioctls) must be noted in more detail in the history chapter | |||
| 116 | applications. --> | 128 | applications. --> |
| 117 | 129 | ||
| 118 | <revision> | 130 | <revision> |
| 131 | <revnumber>2.6.39</revnumber> | ||
| 132 | <date>2011-03-01</date> | ||
| 133 | <authorinitials>mcc, po</authorinitials> | ||
| 134 | <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> | ||
| 135 | </revision> | ||
| 136 | |||
| 137 | <revision> | ||
| 119 | <revnumber>2.6.37</revnumber> | 138 | <revnumber>2.6.37</revnumber> |
| 120 | <date>2010-08-06</date> | 139 | <date>2010-08-06</date> |
| 121 | <authorinitials>hv</authorinitials> | 140 | <authorinitials>hv</authorinitials> |
| @@ -382,7 +401,7 @@ and discussions on the V4L mailing list.</revremark> | |||
| 382 | </partinfo> | 401 | </partinfo> |
| 383 | 402 | ||
| 384 | <title>Video for Linux Two API Specification</title> | 403 | <title>Video for Linux Two API Specification</title> |
| 385 | <subtitle>Revision 2.6.38</subtitle> | 404 | <subtitle>Revision 2.6.39</subtitle> |
| 386 | 405 | ||
| 387 | <chapter id="common"> | 406 | <chapter id="common"> |
| 388 | &sub-common; | 407 | &sub-common; |
| @@ -411,6 +430,7 @@ and discussions on the V4L mailing list.</revremark> | |||
| 411 | <section id="radio"> &sub-dev-radio; </section> | 430 | <section id="radio"> &sub-dev-radio; </section> |
| 412 | <section id="rds"> &sub-dev-rds; </section> | 431 | <section id="rds"> &sub-dev-rds; </section> |
| 413 | <section id="event"> &sub-dev-event; </section> | 432 | <section id="event"> &sub-dev-event; </section> |
| 433 | <section id="subdev"> &sub-dev-subdev; </section> | ||
| 414 | </chapter> | 434 | </chapter> |
| 415 | 435 | ||
| 416 | <chapter id="driver"> | 436 | <chapter id="driver"> |
| @@ -478,6 +498,12 @@ and discussions on the V4L mailing list.</revremark> | |||
| 478 | &sub-reqbufs; | 498 | &sub-reqbufs; |
| 479 | &sub-s-hw-freq-seek; | 499 | &sub-s-hw-freq-seek; |
| 480 | &sub-streamon; | 500 | &sub-streamon; |
| 501 | &sub-subdev-enum-frame-interval; | ||
| 502 | &sub-subdev-enum-frame-size; | ||
| 503 | &sub-subdev-enum-mbus-code; | ||
| 504 | &sub-subdev-g-crop; | ||
| 505 | &sub-subdev-g-fmt; | ||
| 506 | &sub-subdev-g-frame-interval; | ||
| 481 | &sub-subscribe-event; | 507 | &sub-subscribe-event; |
| 482 | <!-- End of ioctls. --> | 508 | <!-- End of ioctls. --> |
| 483 | &sub-mmap; | 509 | &sub-mmap; |
diff --git a/Documentation/DocBook/v4l/videodev2.h.xml b/Documentation/DocBook/v4l/videodev2.h.xml index 325b23b6964c..2b796a2ee98a 100644 --- a/Documentation/DocBook/v4l/videodev2.h.xml +++ b/Documentation/DocBook/v4l/videodev2.h.xml | |||
| @@ -71,6 +71,7 @@ | |||
| 71 | * Moved from videodev.h | 71 | * Moved from videodev.h |
| 72 | */ | 72 | */ |
| 73 | #define VIDEO_MAX_FRAME 32 | 73 | #define VIDEO_MAX_FRAME 32 |
| 74 | #define VIDEO_MAX_PLANES 8 | ||
| 74 | 75 | ||
| 75 | #ifndef __KERNEL__ | 76 | #ifndef __KERNEL__ |
| 76 | 77 | ||
| @@ -158,9 +159,23 @@ enum <link linkend="v4l2-buf-type">v4l2_buf_type</link> { | |||
| 158 | /* Experimental */ | 159 | /* Experimental */ |
| 159 | V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY = 8, | 160 | V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY = 8, |
| 160 | #endif | 161 | #endif |
| 162 | V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE = 9, | ||
| 163 | V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE = 10, | ||
| 161 | V4L2_BUF_TYPE_PRIVATE = 0x80, | 164 | V4L2_BUF_TYPE_PRIVATE = 0x80, |
| 162 | }; | 165 | }; |
| 163 | 166 | ||
| 167 | #define V4L2_TYPE_IS_MULTIPLANAR(type) \ | ||
| 168 | ((type) == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE \ | ||
| 169 | || (type) == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) | ||
| 170 | |||
| 171 | #define V4L2_TYPE_IS_OUTPUT(type) \ | ||
| 172 | ((type) == V4L2_BUF_TYPE_VIDEO_OUTPUT \ | ||
| 173 | || (type) == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE \ | ||
| 174 | || (type) == V4L2_BUF_TYPE_VIDEO_OVERLAY \ | ||
| 175 | || (type) == V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY \ | ||
| 176 | || (type) == V4L2_BUF_TYPE_VBI_OUTPUT \ | ||
| 177 | || (type) == V4L2_BUF_TYPE_SLICED_VBI_OUTPUT) | ||
| 178 | |||
| 164 | enum <link linkend="v4l2-tuner-type">v4l2_tuner_type</link> { | 179 | enum <link linkend="v4l2-tuner-type">v4l2_tuner_type</link> { |
| 165 | V4L2_TUNER_RADIO = 1, | 180 | V4L2_TUNER_RADIO = 1, |
| 166 | V4L2_TUNER_ANALOG_TV = 2, | 181 | V4L2_TUNER_ANALOG_TV = 2, |
| @@ -246,6 +261,11 @@ struct <link linkend="v4l2-capability">v4l2_capability</link> { | |||
| 246 | #define V4L2_CAP_HW_FREQ_SEEK 0x00000400 /* Can do hardware frequency seek */ | 261 | #define V4L2_CAP_HW_FREQ_SEEK 0x00000400 /* Can do hardware frequency seek */ |
| 247 | #define V4L2_CAP_RDS_OUTPUT 0x00000800 /* Is an RDS encoder */ | 262 | #define V4L2_CAP_RDS_OUTPUT 0x00000800 /* Is an RDS encoder */ |
| 248 | 263 | ||
| 264 | /* Is a video capture device that supports multiplanar formats */ | ||
| 265 | #define V4L2_CAP_VIDEO_CAPTURE_MPLANE 0x00001000 | ||
| 266 | /* Is a video output device that supports multiplanar formats */ | ||
| 267 | #define V4L2_CAP_VIDEO_OUTPUT_MPLANE 0x00002000 | ||
| 268 | |||
| 249 | #define V4L2_CAP_TUNER 0x00010000 /* has a tuner */ | 269 | #define V4L2_CAP_TUNER 0x00010000 /* has a tuner */ |
| 250 | #define V4L2_CAP_AUDIO 0x00020000 /* has audio support */ | 270 | #define V4L2_CAP_AUDIO 0x00020000 /* has audio support */ |
| 251 | #define V4L2_CAP_RADIO 0x00040000 /* is a radio device */ | 271 | #define V4L2_CAP_RADIO 0x00040000 /* is a radio device */ |
| @@ -320,6 +340,13 @@ struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> { | |||
| 320 | #define <link linkend="V4L2-PIX-FMT-NV16">V4L2_PIX_FMT_NV16</link> v4l2_fourcc('N', 'V', '1', '6') /* 16 Y/CbCr 4:2:2 */ | 340 | #define <link linkend="V4L2-PIX-FMT-NV16">V4L2_PIX_FMT_NV16</link> v4l2_fourcc('N', 'V', '1', '6') /* 16 Y/CbCr 4:2:2 */ |
| 321 | #define <link linkend="V4L2-PIX-FMT-NV61">V4L2_PIX_FMT_NV61</link> v4l2_fourcc('N', 'V', '6', '1') /* 16 Y/CrCb 4:2:2 */ | 341 | #define <link linkend="V4L2-PIX-FMT-NV61">V4L2_PIX_FMT_NV61</link> v4l2_fourcc('N', 'V', '6', '1') /* 16 Y/CrCb 4:2:2 */ |
| 322 | 342 | ||
| 343 | /* two non contiguous planes - one Y, one Cr + Cb interleaved */ | ||
| 344 | #define <link linkend="V4L2-PIX-FMT-NV12M">V4L2_PIX_FMT_NV12M</link> v4l2_fourcc('N', 'M', '1', '2') /* 12 Y/CbCr 4:2:0 */ | ||
| 345 | #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 */ | ||
| 346 | |||
| 347 | /* three non contiguous planes - Y, Cb, Cr */ | ||
| 348 | #define <link linkend="V4L2-PIX-FMT-YUV420M">V4L2_PIX_FMT_YUV420M</link> v4l2_fourcc('Y', 'M', '1', '2') /* 12 YUV420 planar */ | ||
| 349 | |||
| 323 | /* Bayer formats - see http://www.siliconimaging.com/RGB%20Bayer.htm */ | 350 | /* Bayer formats - see http://www.siliconimaging.com/RGB%20Bayer.htm */ |
| 324 | #define <link linkend="V4L2-PIX-FMT-SBGGR8">V4L2_PIX_FMT_SBGGR8</link> v4l2_fourcc('B', 'A', '8', '1') /* 8 BGBG.. GRGR.. */ | 351 | #define <link linkend="V4L2-PIX-FMT-SBGGR8">V4L2_PIX_FMT_SBGGR8</link> v4l2_fourcc('B', 'A', '8', '1') /* 8 BGBG.. GRGR.. */ |
| 325 | #define <link linkend="V4L2-PIX-FMT-SGBRG8">V4L2_PIX_FMT_SGBRG8</link> v4l2_fourcc('G', 'B', 'R', 'G') /* 8 GBGB.. RGRG.. */ | 352 | #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> { | |||
| 518 | __u32 reserved[2]; | 545 | __u32 reserved[2]; |
| 519 | }; | 546 | }; |
| 520 | 547 | ||
| 548 | /** | ||
| 549 | * struct <link linkend="v4l2-plane">v4l2_plane</link> - plane info for multi-planar buffers | ||
| 550 | * @bytesused: number of bytes occupied by data in the plane (payload) | ||
| 551 | * @length: size of this plane (NOT the payload) in bytes | ||
| 552 | * @mem_offset: when memory in the associated struct <link linkend="v4l2-buffer">v4l2_buffer</link> is | ||
| 553 | * V4L2_MEMORY_MMAP, equals the offset from the start of | ||
| 554 | * the device memory for this plane (or is a "cookie" that | ||
| 555 | * should be passed to mmap() called on the video node) | ||
| 556 | * @userptr: when memory is V4L2_MEMORY_USERPTR, a userspace pointer | ||
| 557 | * pointing to this plane | ||
| 558 | * @data_offset: offset in the plane to the start of data; usually 0, | ||
| 559 | * unless there is a header in front of the data | ||
| 560 | * | ||
| 561 | * Multi-planar buffers consist of one or more planes, e.g. an YCbCr buffer | ||
| 562 | * with two planes can have one plane for Y, and another for interleaved CbCr | ||
| 563 | * components. Each plane can reside in a separate memory buffer, or even in | ||
| 564 | * a completely separate memory node (e.g. in embedded devices). | ||
| 565 | */ | ||
| 566 | struct <link linkend="v4l2-plane">v4l2_plane</link> { | ||
| 567 | __u32 bytesused; | ||
| 568 | __u32 length; | ||
| 569 | union { | ||
| 570 | __u32 mem_offset; | ||
| 571 | unsigned long userptr; | ||
| 572 | } m; | ||
| 573 | __u32 data_offset; | ||
| 574 | __u32 reserved[11]; | ||
| 575 | }; | ||
| 576 | |||
| 577 | /** | ||
| 578 | * struct <link linkend="v4l2-buffer">v4l2_buffer</link> - video buffer info | ||
| 579 | * @index: id number of the buffer | ||
| 580 | * @type: buffer type (type == *_MPLANE for multiplanar buffers) | ||
| 581 | * @bytesused: number of bytes occupied by data in the buffer (payload); | ||
| 582 | * unused (set to 0) for multiplanar buffers | ||
| 583 | * @flags: buffer informational flags | ||
| 584 | * @field: field order of the image in the buffer | ||
| 585 | * @timestamp: frame timestamp | ||
| 586 | * @timecode: frame timecode | ||
| 587 | * @sequence: sequence count of this frame | ||
| 588 | * @memory: the method, in which the actual video data is passed | ||
| 589 | * @offset: for non-multiplanar buffers with memory == V4L2_MEMORY_MMAP; | ||
| 590 | * offset from the start of the device memory for this plane, | ||
| 591 | * (or a "cookie" that should be passed to mmap() as offset) | ||
| 592 | * @userptr: for non-multiplanar buffers with memory == V4L2_MEMORY_USERPTR; | ||
| 593 | * a userspace pointer pointing to this buffer | ||
| 594 | * @planes: for multiplanar buffers; userspace pointer to the array of plane | ||
| 595 | * info structs for this buffer | ||
| 596 | * @length: size in bytes of the buffer (NOT its payload) for single-plane | ||
| 597 | * buffers (when type != *_MPLANE); number of elements in the | ||
| 598 | * planes array for multi-plane buffers | ||
| 599 | * @input: input number from which the video data has has been captured | ||
| 600 | * | ||
| 601 | * Contains data exchanged by application and driver using one of the Streaming | ||
| 602 | * I/O methods. | ||
| 603 | */ | ||
| 521 | struct <link linkend="v4l2-buffer">v4l2_buffer</link> { | 604 | struct <link linkend="v4l2-buffer">v4l2_buffer</link> { |
| 522 | __u32 index; | 605 | __u32 index; |
| 523 | enum <link linkend="v4l2-buf-type">v4l2_buf_type</link> type; | 606 | enum <link linkend="v4l2-buf-type">v4l2_buf_type</link> type; |
| @@ -533,6 +616,7 @@ struct <link linkend="v4l2-buffer">v4l2_buffer</link> { | |||
| 533 | union { | 616 | union { |
| 534 | __u32 offset; | 617 | __u32 offset; |
| 535 | unsigned long userptr; | 618 | unsigned long userptr; |
| 619 | struct <link linkend="v4l2-plane">v4l2_plane</link> *planes; | ||
| 536 | } m; | 620 | } m; |
| 537 | __u32 length; | 621 | __u32 length; |
| 538 | __u32 input; | 622 | __u32 input; |
| @@ -1623,12 +1707,56 @@ struct <link linkend="v4l2-mpeg-vbi-fmt-ivtv">v4l2_mpeg_vbi_fmt_ivtv</link> { | |||
| 1623 | * A G G R E G A T E S T R U C T U R E S | 1707 | * A G G R E G A T E S T R U C T U R E S |
| 1624 | */ | 1708 | */ |
| 1625 | 1709 | ||
| 1626 | /* Stream data format | 1710 | /** |
| 1711 | * struct <link linkend="v4l2-plane-pix-format">v4l2_plane_pix_format</link> - additional, per-plane format definition | ||
| 1712 | * @sizeimage: maximum size in bytes required for data, for which | ||
| 1713 | * this plane will be used | ||
| 1714 | * @bytesperline: distance in bytes between the leftmost pixels in two | ||
| 1715 | * adjacent lines | ||
| 1716 | */ | ||
| 1717 | struct <link linkend="v4l2-plane-pix-format">v4l2_plane_pix_format</link> { | ||
| 1718 | __u32 sizeimage; | ||
| 1719 | __u16 bytesperline; | ||
| 1720 | __u16 reserved[7]; | ||
| 1721 | } __attribute__ ((packed)); | ||
| 1722 | |||
| 1723 | /** | ||
| 1724 | * struct <link linkend="v4l2-pix-format-mplane">v4l2_pix_format_mplane</link> - multiplanar format definition | ||
| 1725 | * @width: image width in pixels | ||
| 1726 | * @height: image height in pixels | ||
| 1727 | * @pixelformat: little endian four character code (fourcc) | ||
| 1728 | * @field: field order (for interlaced video) | ||
| 1729 | * @colorspace: supplemental to pixelformat | ||
| 1730 | * @plane_fmt: per-plane information | ||
| 1731 | * @num_planes: number of planes for this format | ||
| 1732 | */ | ||
| 1733 | struct <link linkend="v4l2-pix-format-mplane">v4l2_pix_format_mplane</link> { | ||
| 1734 | __u32 width; | ||
| 1735 | __u32 height; | ||
| 1736 | __u32 pixelformat; | ||
| 1737 | enum <link linkend="v4l2-field">v4l2_field</link> field; | ||
| 1738 | enum <link linkend="v4l2-colorspace">v4l2_colorspace</link> colorspace; | ||
| 1739 | |||
| 1740 | struct <link linkend="v4l2-plane-pix-format">v4l2_plane_pix_format</link> plane_fmt[VIDEO_MAX_PLANES]; | ||
| 1741 | __u8 num_planes; | ||
| 1742 | __u8 reserved[11]; | ||
| 1743 | } __attribute__ ((packed)); | ||
| 1744 | |||
| 1745 | /** | ||
| 1746 | * struct <link linkend="v4l2-format">v4l2_format</link> - stream data format | ||
| 1747 | * @type: type of the data stream | ||
| 1748 | * @pix: definition of an image format | ||
| 1749 | * @pix_mp: definition of a multiplanar image format | ||
| 1750 | * @win: definition of an overlaid image | ||
| 1751 | * @vbi: raw VBI capture or output parameters | ||
| 1752 | * @sliced: sliced VBI capture or output parameters | ||
| 1753 | * @raw_data: placeholder for future extensions and custom formats | ||
| 1627 | */ | 1754 | */ |
| 1628 | struct <link linkend="v4l2-format">v4l2_format</link> { | 1755 | struct <link linkend="v4l2-format">v4l2_format</link> { |
| 1629 | enum <link linkend="v4l2-buf-type">v4l2_buf_type</link> type; | 1756 | enum <link linkend="v4l2-buf-type">v4l2_buf_type</link> type; |
| 1630 | union { | 1757 | union { |
| 1631 | struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> pix; /* V4L2_BUF_TYPE_VIDEO_CAPTURE */ | 1758 | struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> pix; /* V4L2_BUF_TYPE_VIDEO_CAPTURE */ |
| 1759 | struct <link linkend="v4l2-pix-format-mplane">v4l2_pix_format_mplane</link> pix_mp; /* V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE */ | ||
| 1632 | struct <link linkend="v4l2-window">v4l2_window</link> win; /* V4L2_BUF_TYPE_VIDEO_OVERLAY */ | 1760 | struct <link linkend="v4l2-window">v4l2_window</link> win; /* V4L2_BUF_TYPE_VIDEO_OVERLAY */ |
| 1633 | struct <link linkend="v4l2-vbi-format">v4l2_vbi_format</link> vbi; /* V4L2_BUF_TYPE_VBI_CAPTURE */ | 1761 | struct <link linkend="v4l2-vbi-format">v4l2_vbi_format</link> vbi; /* V4L2_BUF_TYPE_VBI_CAPTURE */ |
| 1634 | struct <link linkend="v4l2-sliced-vbi-format">v4l2_sliced_vbi_format</link> sliced; /* V4L2_BUF_TYPE_SLICED_VBI_CAPTURE */ | 1762 | 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> { | |||
| 1636 | } fmt; | 1764 | } fmt; |
| 1637 | }; | 1765 | }; |
| 1638 | 1766 | ||
| 1639 | |||
| 1640 | /* Stream type-dependent parameters | 1767 | /* Stream type-dependent parameters |
| 1641 | */ | 1768 | */ |
| 1642 | struct <link linkend="v4l2-streamparm">v4l2_streamparm</link> { | 1769 | struct <link linkend="v4l2-streamparm">v4l2_streamparm</link> { |
| @@ -1809,16 +1936,6 @@ struct <link linkend="v4l2-dbg-chip-ident">v4l2_dbg_chip_ident</link> { | |||
| 1809 | /* Reminder: when adding new ioctls please add support for them to | 1936 | /* Reminder: when adding new ioctls please add support for them to |
| 1810 | drivers/media/video/v4l2-compat-ioctl32.c as well! */ | 1937 | drivers/media/video/v4l2-compat-ioctl32.c as well! */ |
| 1811 | 1938 | ||
| 1812 | #ifdef __OLD_VIDIOC_ | ||
| 1813 | /* for compatibility, will go away some day */ | ||
| 1814 | #define VIDIOC_OVERLAY_OLD _IOWR('V', 14, int) | ||
| 1815 | #define VIDIOC_S_PARM_OLD _IOW('V', 22, struct <link linkend="v4l2-streamparm">v4l2_streamparm</link>) | ||
| 1816 | #define VIDIOC_S_CTRL_OLD _IOW('V', 28, struct <link linkend="v4l2-control">v4l2_control</link>) | ||
| 1817 | #define VIDIOC_G_AUDIO_OLD _IOWR('V', 33, struct <link linkend="v4l2-audio">v4l2_audio</link>) | ||
| 1818 | #define VIDIOC_G_AUDOUT_OLD _IOWR('V', 49, struct <link linkend="v4l2-audioout">v4l2_audioout</link>) | ||
| 1819 | #define VIDIOC_CROPCAP_OLD _IOR('V', 58, struct <link linkend="v4l2-cropcap">v4l2_cropcap</link>) | ||
| 1820 | #endif | ||
| 1821 | |||
| 1822 | #define BASE_VIDIOC_PRIVATE 192 /* 192-255 are private */ | 1939 | #define BASE_VIDIOC_PRIVATE 192 /* 192-255 are private */ |
| 1823 | 1940 | ||
| 1824 | #endif /* __LINUX_VIDEODEV2_H */ | 1941 | #endif /* __LINUX_VIDEODEV2_H */ |
diff --git a/Documentation/DocBook/v4l/vidioc-enum-fmt.xml b/Documentation/DocBook/v4l/vidioc-enum-fmt.xml index 960d44615ca6..71d373b6d36a 100644 --- a/Documentation/DocBook/v4l/vidioc-enum-fmt.xml +++ b/Documentation/DocBook/v4l/vidioc-enum-fmt.xml | |||
| @@ -76,7 +76,9 @@ pixelformat</structfield> field.</entry> | |||
| 76 | <entry>Type of the data stream, set by the application. | 76 | <entry>Type of the data stream, set by the application. |
| 77 | Only these types are valid here: | 77 | Only these types are valid here: |
| 78 | <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>, | 78 | <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>, |
| 79 | <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>, | ||
| 79 | <constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant>, | 80 | <constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant>, |
| 81 | <constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant>, | ||
| 80 | <constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>, and custom (driver | 82 | <constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>, and custom (driver |
| 81 | defined) types with code <constant>V4L2_BUF_TYPE_PRIVATE</constant> | 83 | defined) types with code <constant>V4L2_BUF_TYPE_PRIVATE</constant> |
| 82 | and higher.</entry> | 84 | and higher.</entry> |
diff --git a/Documentation/DocBook/v4l/vidioc-g-fmt.xml b/Documentation/DocBook/v4l/vidioc-g-fmt.xml index 7c7d1b72c40d..a4ae59b664eb 100644 --- a/Documentation/DocBook/v4l/vidioc-g-fmt.xml +++ b/Documentation/DocBook/v4l/vidioc-g-fmt.xml | |||
| @@ -60,11 +60,13 @@ application.</para> | |||
| 60 | <structfield>type</structfield> field of a struct | 60 | <structfield>type</structfield> field of a struct |
| 61 | <structname>v4l2_format</structname> to the respective buffer (stream) | 61 | <structname>v4l2_format</structname> to the respective buffer (stream) |
| 62 | type. For example video capture devices use | 62 | type. For example video capture devices use |
| 63 | <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>. When the application | 63 | <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant> or |
| 64 | <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>. When the application | ||
| 64 | calls the <constant>VIDIOC_G_FMT</constant> ioctl with a pointer to | 65 | calls the <constant>VIDIOC_G_FMT</constant> ioctl with a pointer to |
| 65 | this structure the driver fills the respective member of the | 66 | this structure the driver fills the respective member of the |
| 66 | <structfield>fmt</structfield> union. In case of video capture devices | 67 | <structfield>fmt</structfield> union. In case of video capture devices |
| 67 | that is the &v4l2-pix-format; <structfield>pix</structfield> member. | 68 | that is either the &v4l2-pix-format; <structfield>pix</structfield> or |
| 69 | the &v4l2-pix-format-mplane; <structfield>pix_mp</structfield> member. | ||
| 68 | When the requested buffer type is not supported drivers return an | 70 | When the requested buffer type is not supported drivers return an |
| 69 | &EINVAL;.</para> | 71 | &EINVAL;.</para> |
| 70 | 72 | ||
| @@ -134,6 +136,15 @@ devices.</entry> | |||
| 134 | </row> | 136 | </row> |
| 135 | <row> | 137 | <row> |
| 136 | <entry></entry> | 138 | <entry></entry> |
| 139 | <entry>&v4l2-pix-format-mplane;</entry> | ||
| 140 | <entry><structfield>pix_mp</structfield></entry> | ||
| 141 | <entry>Definition of an image format, see <xref | ||
| 142 | linkend="pixfmt" />, used by video capture and output | ||
| 143 | devices that support the <link linkend="planar-apis">multi-planar | ||
| 144 | version of the API</link>.</entry> | ||
| 145 | </row> | ||
| 146 | <row> | ||
| 147 | <entry></entry> | ||
| 137 | <entry>&v4l2-window;</entry> | 148 | <entry>&v4l2-window;</entry> |
| 138 | <entry><structfield>win</structfield></entry> | 149 | <entry><structfield>win</structfield></entry> |
| 139 | <entry>Definition of an overlaid image, see <xref | 150 | <entry>Definition of an overlaid image, see <xref |
diff --git a/Documentation/DocBook/v4l/vidioc-qbuf.xml b/Documentation/DocBook/v4l/vidioc-qbuf.xml index ab691ebf3b93..f2b11f8a4031 100644 --- a/Documentation/DocBook/v4l/vidioc-qbuf.xml +++ b/Documentation/DocBook/v4l/vidioc-qbuf.xml | |||
| @@ -64,7 +64,8 @@ zero to the number of buffers allocated with &VIDIOC-REQBUFS; | |||
| 64 | contents of the struct <structname>v4l2_buffer</structname> returned | 64 | contents of the struct <structname>v4l2_buffer</structname> returned |
| 65 | by a &VIDIOC-QUERYBUF; ioctl will do as well. When the buffer is | 65 | by a &VIDIOC-QUERYBUF; ioctl will do as well. When the buffer is |
| 66 | intended for output (<structfield>type</structfield> is | 66 | intended for output (<structfield>type</structfield> is |
| 67 | <constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> or | 67 | <constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant>, |
| 68 | <constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant>, or | ||
| 68 | <constant>V4L2_BUF_TYPE_VBI_OUTPUT</constant>) applications must also | 69 | <constant>V4L2_BUF_TYPE_VBI_OUTPUT</constant>) applications must also |
| 69 | initialize the <structfield>bytesused</structfield>, | 70 | initialize the <structfield>bytesused</structfield>, |
| 70 | <structfield>field</structfield> and | 71 | <structfield>field</structfield> and |
| @@ -75,7 +76,11 @@ supports capturing from specific video inputs and you want to specify a video | |||
| 75 | input, then <structfield>flags</structfield> should be set to | 76 | input, then <structfield>flags</structfield> should be set to |
| 76 | <constant>V4L2_BUF_FLAG_INPUT</constant> and the field | 77 | <constant>V4L2_BUF_FLAG_INPUT</constant> and the field |
| 77 | <structfield>input</structfield> must be initialized to the desired input. | 78 | <structfield>input</structfield> must be initialized to the desired input. |
| 78 | The <structfield>reserved</structfield> field must be set to 0. | 79 | The <structfield>reserved</structfield> field must be set to 0. When using |
| 80 | the <link linkend="planar-apis">multi-planar API</link>, the | ||
| 81 | <structfield>m.planes</structfield> field must contain a userspace pointer | ||
| 82 | to a filled-in array of &v4l2-plane; and the <structfield>length</structfield> | ||
| 83 | field must be set to the number of elements in that array. | ||
| 79 | </para> | 84 | </para> |
| 80 | 85 | ||
| 81 | <para>To enqueue a <link linkend="mmap">memory mapped</link> | 86 | <para>To enqueue a <link linkend="mmap">memory mapped</link> |
| @@ -93,10 +98,13 @@ structure the driver sets the | |||
| 93 | buffer applications set the <structfield>memory</structfield> | 98 | buffer applications set the <structfield>memory</structfield> |
| 94 | field to <constant>V4L2_MEMORY_USERPTR</constant>, the | 99 | field to <constant>V4L2_MEMORY_USERPTR</constant>, the |
| 95 | <structfield>m.userptr</structfield> field to the address of the | 100 | <structfield>m.userptr</structfield> field to the address of the |
| 96 | buffer and <structfield>length</structfield> to its size. | 101 | buffer and <structfield>length</structfield> to its size. When the multi-planar |
| 97 | When <constant>VIDIOC_QBUF</constant> is called with a pointer to this | 102 | API is used, <structfield>m.userptr</structfield> and |
| 98 | structure the driver sets the <constant>V4L2_BUF_FLAG_QUEUED</constant> | 103 | <structfield>length</structfield> members of the passed array of &v4l2-plane; |
| 99 | flag and clears the <constant>V4L2_BUF_FLAG_MAPPED</constant> and | 104 | have to be used instead. When <constant>VIDIOC_QBUF</constant> is called with |
| 105 | a pointer to this structure the driver sets the | ||
| 106 | <constant>V4L2_BUF_FLAG_QUEUED</constant> flag and clears the | ||
| 107 | <constant>V4L2_BUF_FLAG_MAPPED</constant> and | ||
| 100 | <constant>V4L2_BUF_FLAG_DONE</constant> flags in the | 108 | <constant>V4L2_BUF_FLAG_DONE</constant> flags in the |
| 101 | <structfield>flags</structfield> field, or it returns an error code. | 109 | <structfield>flags</structfield> field, or it returns an error code. |
| 102 | This ioctl locks the memory pages of the buffer in physical memory, | 110 | 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 | |||
| 115 | <constant>V4L2_BUF_FLAG_ERROR</constant> in the <structfield>flags</structfield> | 123 | <constant>V4L2_BUF_FLAG_ERROR</constant> in the <structfield>flags</structfield> |
| 116 | field. It indicates a non-critical (recoverable) streaming error. In such case | 124 | field. It indicates a non-critical (recoverable) streaming error. In such case |
| 117 | the application may continue as normal, but should be aware that data in the | 125 | the application may continue as normal, but should be aware that data in the |
| 118 | dequeued buffer might be corrupted.</para> | 126 | dequeued buffer might be corrupted. When using the multi-planar API, the |
| 127 | planes array does not have to be passed; the <structfield>m.planes</structfield> | ||
| 128 | member must be set to NULL in that case.</para> | ||
| 119 | 129 | ||
| 120 | <para>By default <constant>VIDIOC_DQBUF</constant> blocks when no | 130 | <para>By default <constant>VIDIOC_DQBUF</constant> blocks when no |
| 121 | buffer is in the outgoing queue. When the | 131 | buffer is in the outgoing queue. When the |
diff --git a/Documentation/DocBook/v4l/vidioc-querybuf.xml b/Documentation/DocBook/v4l/vidioc-querybuf.xml index e649805a4908..5c104d42d31c 100644 --- a/Documentation/DocBook/v4l/vidioc-querybuf.xml +++ b/Documentation/DocBook/v4l/vidioc-querybuf.xml | |||
| @@ -61,6 +61,10 @@ buffer at any time after buffers have been allocated with the | |||
| 61 | to the number of buffers allocated with &VIDIOC-REQBUFS; | 61 | to the number of buffers allocated with &VIDIOC-REQBUFS; |
| 62 | (&v4l2-requestbuffers; <structfield>count</structfield>) minus one. | 62 | (&v4l2-requestbuffers; <structfield>count</structfield>) minus one. |
| 63 | The <structfield>reserved</structfield> field should to set to 0. | 63 | The <structfield>reserved</structfield> field should to set to 0. |
| 64 | When using the <link linkend="planar-apis">multi-planar API</link>, the | ||
| 65 | <structfield>m.planes</structfield> field must contain a userspace pointer to an | ||
| 66 | array of &v4l2-plane; and the <structfield>length</structfield> field has | ||
| 67 | to be set to the number of elements in that array. | ||
| 64 | After calling <constant>VIDIOC_QUERYBUF</constant> with a pointer to | 68 | After calling <constant>VIDIOC_QUERYBUF</constant> with a pointer to |
| 65 | this structure drivers return an error code or fill the rest of | 69 | this structure drivers return an error code or fill the rest of |
| 66 | the structure.</para> | 70 | the structure.</para> |
| @@ -70,11 +74,13 @@ the structure.</para> | |||
| 70 | <constant>V4L2_BUF_FLAG_QUEUED</constant> and | 74 | <constant>V4L2_BUF_FLAG_QUEUED</constant> and |
| 71 | <constant>V4L2_BUF_FLAG_DONE</constant> flags will be valid. The | 75 | <constant>V4L2_BUF_FLAG_DONE</constant> flags will be valid. The |
| 72 | <structfield>memory</structfield> field will be set to the current | 76 | <structfield>memory</structfield> field will be set to the current |
| 73 | I/O method, the <structfield>m.offset</structfield> | 77 | I/O method. For the single-planar API, the <structfield>m.offset</structfield> |
| 74 | contains the offset of the buffer from the start of the device memory, | 78 | contains the offset of the buffer from the start of the device memory, |
| 75 | the <structfield>length</structfield> field its size. The driver may | 79 | the <structfield>length</structfield> field its size. For the multi-planar API, |
| 76 | or may not set the remaining fields and flags, they are meaningless in | 80 | fields <structfield>m.mem_offset</structfield> and |
| 77 | this context.</para> | 81 | <structfield>length</structfield> in the <structfield>m.planes</structfield> |
| 82 | array elements will be used instead. The driver may or may not set the remaining | ||
| 83 | fields and flags, they are meaningless in this context.</para> | ||
| 78 | 84 | ||
| 79 | <para>The <structname>v4l2_buffer</structname> structure is | 85 | <para>The <structname>v4l2_buffer</structname> structure is |
| 80 | specified in <xref linkend="buffer" />.</para> | 86 | specified in <xref linkend="buffer" />.</para> |
diff --git a/Documentation/DocBook/v4l/vidioc-querycap.xml b/Documentation/DocBook/v4l/vidioc-querycap.xml index d499da93a450..f29f1b86213c 100644 --- a/Documentation/DocBook/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/v4l/vidioc-querycap.xml | |||
| @@ -142,16 +142,30 @@ this array to zero.</entry> | |||
| 142 | <row> | 142 | <row> |
| 143 | <entry><constant>V4L2_CAP_VIDEO_CAPTURE</constant></entry> | 143 | <entry><constant>V4L2_CAP_VIDEO_CAPTURE</constant></entry> |
| 144 | <entry>0x00000001</entry> | 144 | <entry>0x00000001</entry> |
| 145 | <entry>The device supports the <link | 145 | <entry>The device supports the single-planar API through the <link |
| 146 | linkend="capture">Video Capture</link> interface.</entry> | 146 | linkend="capture">Video Capture</link> interface.</entry> |
| 147 | </row> | 147 | </row> |
| 148 | <row> | 148 | <row> |
| 149 | <entry><constant>V4L2_CAP_VIDEO_CAPTURE_MPLANE</constant></entry> | ||
| 150 | <entry>0x00001000</entry> | ||
| 151 | <entry>The device supports the | ||
| 152 | <link linkend="planar-apis">multi-planar API</link> through the | ||
| 153 | <link linkend="capture">Video Capture</link> interface.</entry> | ||
| 154 | </row> | ||
| 155 | <row> | ||
| 149 | <entry><constant>V4L2_CAP_VIDEO_OUTPUT</constant></entry> | 156 | <entry><constant>V4L2_CAP_VIDEO_OUTPUT</constant></entry> |
| 150 | <entry>0x00000002</entry> | 157 | <entry>0x00000002</entry> |
| 151 | <entry>The device supports the <link | 158 | <entry>The device supports the single-planar API through the <link |
| 152 | linkend="output">Video Output</link> interface.</entry> | 159 | linkend="output">Video Output</link> interface.</entry> |
| 153 | </row> | 160 | </row> |
| 154 | <row> | 161 | <row> |
| 162 | <entry><constant>V4L2_CAP_VIDEO_OUTPUT_MPLANE</constant></entry> | ||
| 163 | <entry>0x00002000</entry> | ||
| 164 | <entry>The device supports the | ||
| 165 | <link linkend="planar-apis">multi-planar API</link> through the | ||
| 166 | <link linkend="output">Video Output</link> interface.</entry> | ||
| 167 | </row> | ||
| 168 | <row> | ||
| 155 | <entry><constant>V4L2_CAP_VIDEO_OVERLAY</constant></entry> | 169 | <entry><constant>V4L2_CAP_VIDEO_OVERLAY</constant></entry> |
| 156 | <entry>0x00000004</entry> | 170 | <entry>0x00000004</entry> |
| 157 | <entry>The device supports the <link | 171 | <entry>The device supports the <link |
diff --git a/Documentation/DocBook/v4l/vidioc-streamon.xml b/Documentation/DocBook/v4l/vidioc-streamon.xml index e42bff1f2c0a..75ed39bf4d2b 100644 --- a/Documentation/DocBook/v4l/vidioc-streamon.xml +++ b/Documentation/DocBook/v4l/vidioc-streamon.xml | |||
| @@ -93,6 +93,15 @@ synchronize with other events.</para> | |||
| 93 | been allocated (memory mapping) or enqueued (output) yet.</para> | 93 | been allocated (memory mapping) or enqueued (output) yet.</para> |
| 94 | </listitem> | 94 | </listitem> |
| 95 | </varlistentry> | 95 | </varlistentry> |
| 96 | <varlistentry> | ||
| 97 | <term><errorcode>EPIPE</errorcode></term> | ||
| 98 | <listitem> | ||
| 99 | <para>The driver implements <link | ||
| 100 | linkend="pad-level-formats">pad-level format configuration</link> and | ||
| 101 | the pipeline configuration is invalid. | ||
| 102 | </para> | ||
| 103 | </listitem> | ||
| 104 | </varlistentry> | ||
| 96 | </variablelist> | 105 | </variablelist> |
| 97 | </refsect1> | 106 | </refsect1> |
| 98 | </refentry> | 107 | </refentry> |
diff --git a/Documentation/DocBook/v4l/vidioc-subdev-enum-frame-interval.xml b/Documentation/DocBook/v4l/vidioc-subdev-enum-frame-interval.xml new file mode 100644 index 000000000000..2f8f4f0a0235 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-subdev-enum-frame-interval.xml | |||
| @@ -0,0 +1,152 @@ | |||
| 1 | <refentry id="vidioc-subdev-enum-frame-interval"> | ||
| 2 | <refmeta> | ||
| 3 | <refentrytitle>ioctl VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL</refentrytitle> | ||
| 4 | &manvol; | ||
| 5 | </refmeta> | ||
| 6 | |||
| 7 | <refnamediv> | ||
| 8 | <refname>VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL</refname> | ||
| 9 | <refpurpose>Enumerate frame intervals</refpurpose> | ||
| 10 | </refnamediv> | ||
| 11 | |||
| 12 | <refsynopsisdiv> | ||
| 13 | <funcsynopsis> | ||
| 14 | <funcprototype> | ||
| 15 | <funcdef>int <function>ioctl</function></funcdef> | ||
| 16 | <paramdef>int <parameter>fd</parameter></paramdef> | ||
| 17 | <paramdef>int <parameter>request</parameter></paramdef> | ||
| 18 | <paramdef>struct v4l2_subdev_frame_interval_enum * | ||
| 19 | <parameter>argp</parameter></paramdef> | ||
| 20 | </funcprototype> | ||
| 21 | </funcsynopsis> | ||
| 22 | </refsynopsisdiv> | ||
| 23 | |||
| 24 | <refsect1> | ||
| 25 | <title>Arguments</title> | ||
| 26 | |||
| 27 | <variablelist> | ||
| 28 | <varlistentry> | ||
| 29 | <term><parameter>fd</parameter></term> | ||
| 30 | <listitem> | ||
| 31 | <para>&fd;</para> | ||
| 32 | </listitem> | ||
| 33 | </varlistentry> | ||
| 34 | <varlistentry> | ||
| 35 | <term><parameter>request</parameter></term> | ||
| 36 | <listitem> | ||
| 37 | <para>VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL</para> | ||
| 38 | </listitem> | ||
| 39 | </varlistentry> | ||
| 40 | <varlistentry> | ||
| 41 | <term><parameter>argp</parameter></term> | ||
| 42 | <listitem> | ||
| 43 | <para></para> | ||
| 44 | </listitem> | ||
| 45 | </varlistentry> | ||
| 46 | </variablelist> | ||
| 47 | </refsect1> | ||
| 48 | |||
| 49 | <refsect1> | ||
| 50 | <title>Description</title> | ||
| 51 | |||
| 52 | <note> | ||
| 53 | <title>Experimental</title> | ||
| 54 | <para>This is an <link linkend="experimental">experimental</link> | ||
| 55 | interface and may change in the future.</para> | ||
| 56 | </note> | ||
| 57 | |||
| 58 | <para>This ioctl lets applications enumerate available frame intervals on a | ||
| 59 | given sub-device pad. Frame intervals only makes sense for sub-devices that | ||
| 60 | can control the frame period on their own. This includes, for instance, | ||
| 61 | image sensors and TV tuners.</para> | ||
| 62 | |||
| 63 | <para>For the common use case of image sensors, the frame intervals | ||
| 64 | available on the sub-device output pad depend on the frame format and size | ||
| 65 | on the same pad. Applications must thus specify the desired format and size | ||
| 66 | when enumerating frame intervals.</para> | ||
| 67 | |||
| 68 | <para>To enumerate frame intervals applications initialize the | ||
| 69 | <structfield>index</structfield>, <structfield>pad</structfield>, | ||
| 70 | <structfield>code</structfield>, <structfield>width</structfield> and | ||
| 71 | <structfield>height</structfield> fields of | ||
| 72 | &v4l2-subdev-frame-interval-enum; and call the | ||
| 73 | <constant>VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL</constant> ioctl with a pointer | ||
| 74 | to this structure. Drivers fill the rest of the structure or return | ||
| 75 | an &EINVAL; if one of the input fields is invalid. All frame intervals are | ||
| 76 | enumerable by beginning at index zero and incrementing by one until | ||
| 77 | <errorcode>EINVAL</errorcode> is returned.</para> | ||
| 78 | |||
| 79 | <para>Available frame intervals may depend on the current 'try' formats | ||
| 80 | at other pads of the sub-device, as well as on the current active links. See | ||
| 81 | &VIDIOC-SUBDEV-G-FMT; for more information about the try formats.</para> | ||
| 82 | |||
| 83 | <para>Sub-devices that support the frame interval enumeration ioctl should | ||
| 84 | implemented it on a single pad only. Its behaviour when supported on | ||
| 85 | multiple pads of the same sub-device is not defined.</para> | ||
| 86 | |||
| 87 | <table pgwide="1" frame="none" id="v4l2-subdev-frame-interval-enum"> | ||
| 88 | <title>struct <structname>v4l2_subdev_frame_interval_enum</structname></title> | ||
| 89 | <tgroup cols="3"> | ||
| 90 | &cs-str; | ||
| 91 | <tbody valign="top"> | ||
| 92 | <row> | ||
| 93 | <entry>__u32</entry> | ||
| 94 | <entry><structfield>index</structfield></entry> | ||
| 95 | <entry>Number of the format in the enumeration, set by the | ||
| 96 | application.</entry> | ||
| 97 | </row> | ||
| 98 | <row> | ||
| 99 | <entry>__u32</entry> | ||
| 100 | <entry><structfield>pad</structfield></entry> | ||
| 101 | <entry>Pad number as reported by the media controller API.</entry> | ||
| 102 | </row> | ||
| 103 | <row> | ||
| 104 | <entry>__u32</entry> | ||
| 105 | <entry><structfield>code</structfield></entry> | ||
| 106 | <entry>The media bus format code, as defined in | ||
| 107 | <xref linkend="v4l2-mbus-format" />.</entry> | ||
| 108 | </row> | ||
| 109 | <row> | ||
| 110 | <entry>__u32</entry> | ||
| 111 | <entry><structfield>width</structfield></entry> | ||
| 112 | <entry>Frame width, in pixels.</entry> | ||
| 113 | </row> | ||
| 114 | <row> | ||
| 115 | <entry>__u32</entry> | ||
| 116 | <entry><structfield>height</structfield></entry> | ||
| 117 | <entry>Frame height, in pixels.</entry> | ||
| 118 | </row> | ||
| 119 | <row> | ||
| 120 | <entry>&v4l2-fract;</entry> | ||
| 121 | <entry><structfield>interval</structfield></entry> | ||
| 122 | <entry>Period, in seconds, between consecutive video frames.</entry> | ||
| 123 | </row> | ||
| 124 | <row> | ||
| 125 | <entry>__u32</entry> | ||
| 126 | <entry><structfield>reserved</structfield>[9]</entry> | ||
| 127 | <entry>Reserved for future extensions. Applications and drivers must | ||
| 128 | set the array to zero.</entry> | ||
| 129 | </row> | ||
| 130 | </tbody> | ||
| 131 | </tgroup> | ||
| 132 | </table> | ||
| 133 | </refsect1> | ||
| 134 | |||
| 135 | <refsect1> | ||
| 136 | &return-value; | ||
| 137 | |||
| 138 | <variablelist> | ||
| 139 | <varlistentry> | ||
| 140 | <term><errorcode>EINVAL</errorcode></term> | ||
| 141 | <listitem> | ||
| 142 | <para>The &v4l2-subdev-frame-interval-enum; | ||
| 143 | <structfield>pad</structfield> references a non-existing pad, one of | ||
| 144 | the <structfield>code</structfield>, <structfield>width</structfield> | ||
| 145 | or <structfield>height</structfield> fields are invalid for the given | ||
| 146 | pad or the <structfield>index</structfield> field is out of bounds. | ||
| 147 | </para> | ||
| 148 | </listitem> | ||
| 149 | </varlistentry> | ||
| 150 | </variablelist> | ||
| 151 | </refsect1> | ||
| 152 | </refentry> | ||
diff --git a/Documentation/DocBook/v4l/vidioc-subdev-enum-frame-size.xml b/Documentation/DocBook/v4l/vidioc-subdev-enum-frame-size.xml new file mode 100644 index 000000000000..79ce42b7c60c --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-subdev-enum-frame-size.xml | |||
| @@ -0,0 +1,154 @@ | |||
| 1 | <refentry id="vidioc-subdev-enum-frame-size"> | ||
| 2 | <refmeta> | ||
| 3 | <refentrytitle>ioctl VIDIOC_SUBDEV_ENUM_FRAME_SIZE</refentrytitle> | ||
| 4 | &manvol; | ||
| 5 | </refmeta> | ||
| 6 | |||
| 7 | <refnamediv> | ||
| 8 | <refname>VIDIOC_SUBDEV_ENUM_FRAME_SIZE</refname> | ||
| 9 | <refpurpose>Enumerate media bus frame sizes</refpurpose> | ||
| 10 | </refnamediv> | ||
| 11 | |||
| 12 | <refsynopsisdiv> | ||
| 13 | <funcsynopsis> | ||
| 14 | <funcprototype> | ||
| 15 | <funcdef>int <function>ioctl</function></funcdef> | ||
| 16 | <paramdef>int <parameter>fd</parameter></paramdef> | ||
| 17 | <paramdef>int <parameter>request</parameter></paramdef> | ||
| 18 | <paramdef>struct v4l2_subdev_frame_size_enum * | ||
| 19 | <parameter>argp</parameter></paramdef> | ||
| 20 | </funcprototype> | ||
| 21 | </funcsynopsis> | ||
| 22 | </refsynopsisdiv> | ||
| 23 | |||
| 24 | <refsect1> | ||
| 25 | <title>Arguments</title> | ||
| 26 | |||
| 27 | <variablelist> | ||
| 28 | <varlistentry> | ||
| 29 | <term><parameter>fd</parameter></term> | ||
| 30 | <listitem> | ||
| 31 | <para>&fd;</para> | ||
| 32 | </listitem> | ||
| 33 | </varlistentry> | ||
| 34 | <varlistentry> | ||
| 35 | <term><parameter>request</parameter></term> | ||
| 36 | <listitem> | ||
| 37 | <para>VIDIOC_SUBDEV_ENUM_FRAME_SIZE</para> | ||
| 38 | </listitem> | ||
| 39 | </varlistentry> | ||
| 40 | <varlistentry> | ||
| 41 | <term><parameter>argp</parameter></term> | ||
| 42 | <listitem> | ||
| 43 | <para></para> | ||
| 44 | </listitem> | ||
| 45 | </varlistentry> | ||
| 46 | </variablelist> | ||
| 47 | </refsect1> | ||
| 48 | |||
| 49 | <refsect1> | ||
| 50 | <title>Description</title> | ||
| 51 | |||
| 52 | <note> | ||
| 53 | <title>Experimental</title> | ||
| 54 | <para>This is an <link linkend="experimental">experimental</link> | ||
| 55 | interface and may change in the future.</para> | ||
| 56 | </note> | ||
| 57 | |||
| 58 | <para>This ioctl allows applications to enumerate all frame sizes | ||
| 59 | supported by a sub-device on the given pad for the given media bus format. | ||
| 60 | Supported formats can be retrieved with the &VIDIOC-SUBDEV-ENUM-MBUS-CODE; | ||
| 61 | ioctl.</para> | ||
| 62 | |||
| 63 | <para>To enumerate frame sizes applications initialize the | ||
| 64 | <structfield>pad</structfield>, <structfield>code</structfield> and | ||
| 65 | <structfield>index</structfield> fields of the | ||
| 66 | &v4l2-subdev-mbus-code-enum; and call the | ||
| 67 | <constant>VIDIOC_SUBDEV_ENUM_FRAME_SIZE</constant> ioctl with a pointer to | ||
| 68 | the structure. Drivers fill the minimum and maximum frame sizes or return | ||
| 69 | an &EINVAL; if one of the input parameters is invalid.</para> | ||
| 70 | |||
| 71 | <para>Sub-devices that only support discrete frame sizes (such as most | ||
| 72 | sensors) will return one or more frame sizes with identical minimum and | ||
| 73 | maximum values.</para> | ||
| 74 | |||
| 75 | <para>Not all possible sizes in given [minimum, maximum] ranges need to be | ||
| 76 | supported. For instance, a scaler that uses a fixed-point scaling ratio | ||
| 77 | might not be able to produce every frame size between the minimum and | ||
| 78 | maximum values. Applications must use the &VIDIOC-SUBDEV-S-FMT; ioctl to | ||
| 79 | try the sub-device for an exact supported frame size.</para> | ||
| 80 | |||
| 81 | <para>Available frame sizes may depend on the current 'try' formats at other | ||
| 82 | pads of the sub-device, as well as on the current active links and the | ||
| 83 | current values of V4L2 controls. See &VIDIOC-SUBDEV-G-FMT; for more | ||
| 84 | information about try formats.</para> | ||
| 85 | |||
| 86 | <table pgwide="1" frame="none" id="v4l2-subdev-frame-size-enum"> | ||
| 87 | <title>struct <structname>v4l2_subdev_frame_size_enum</structname></title> | ||
| 88 | <tgroup cols="3"> | ||
| 89 | &cs-str; | ||
| 90 | <tbody valign="top"> | ||
| 91 | <row> | ||
| 92 | <entry>__u32</entry> | ||
| 93 | <entry><structfield>index</structfield></entry> | ||
| 94 | <entry>Number of the format in the enumeration, set by the | ||
| 95 | application.</entry> | ||
| 96 | </row> | ||
| 97 | <row> | ||
| 98 | <entry>__u32</entry> | ||
| 99 | <entry><structfield>pad</structfield></entry> | ||
| 100 | <entry>Pad number as reported by the media controller API.</entry> | ||
| 101 | </row> | ||
| 102 | <row> | ||
| 103 | <entry>__u32</entry> | ||
| 104 | <entry><structfield>code</structfield></entry> | ||
| 105 | <entry>The media bus format code, as defined in | ||
| 106 | <xref linkend="v4l2-mbus-format" />.</entry> | ||
| 107 | </row> | ||
| 108 | <row> | ||
| 109 | <entry>__u32</entry> | ||
| 110 | <entry><structfield>min_width</structfield></entry> | ||
| 111 | <entry>Minimum frame width, in pixels.</entry> | ||
| 112 | </row> | ||
| 113 | <row> | ||
| 114 | <entry>__u32</entry> | ||
| 115 | <entry><structfield>max_width</structfield></entry> | ||
| 116 | <entry>Maximum frame width, in pixels.</entry> | ||
| 117 | </row> | ||
| 118 | <row> | ||
| 119 | <entry>__u32</entry> | ||
| 120 | <entry><structfield>min_height</structfield></entry> | ||
| 121 | <entry>Minimum frame height, in pixels.</entry> | ||
| 122 | </row> | ||
| 123 | <row> | ||
| 124 | <entry>__u32</entry> | ||
| 125 | <entry><structfield>max_height</structfield></entry> | ||
| 126 | <entry>Maximum frame height, in pixels.</entry> | ||
| 127 | </row> | ||
| 128 | <row> | ||
| 129 | <entry>__u32</entry> | ||
| 130 | <entry><structfield>reserved</structfield>[9]</entry> | ||
| 131 | <entry>Reserved for future extensions. Applications and drivers must | ||
| 132 | set the array to zero.</entry> | ||
| 133 | </row> | ||
| 134 | </tbody> | ||
| 135 | </tgroup> | ||
| 136 | </table> | ||
| 137 | </refsect1> | ||
| 138 | |||
| 139 | <refsect1> | ||
| 140 | &return-value; | ||
| 141 | |||
| 142 | <variablelist> | ||
| 143 | <varlistentry> | ||
| 144 | <term><errorcode>EINVAL</errorcode></term> | ||
| 145 | <listitem> | ||
| 146 | <para>The &v4l2-subdev-frame-size-enum; <structfield>pad</structfield> | ||
| 147 | references a non-existing pad, the <structfield>code</structfield> is | ||
| 148 | invalid for the given pad or the <structfield>index</structfield> | ||
| 149 | field is out of bounds.</para> | ||
| 150 | </listitem> | ||
| 151 | </varlistentry> | ||
| 152 | </variablelist> | ||
| 153 | </refsect1> | ||
| 154 | </refentry> | ||
diff --git a/Documentation/DocBook/v4l/vidioc-subdev-enum-mbus-code.xml b/Documentation/DocBook/v4l/vidioc-subdev-enum-mbus-code.xml new file mode 100644 index 000000000000..a6b3432449f6 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-subdev-enum-mbus-code.xml | |||
| @@ -0,0 +1,119 @@ | |||
| 1 | <refentry id="vidioc-subdev-enum-mbus-code"> | ||
| 2 | <refmeta> | ||
| 3 | <refentrytitle>ioctl VIDIOC_SUBDEV_ENUM_MBUS_CODE</refentrytitle> | ||
| 4 | &manvol; | ||
| 5 | </refmeta> | ||
| 6 | |||
| 7 | <refnamediv> | ||
| 8 | <refname>VIDIOC_SUBDEV_ENUM_MBUS_CODE</refname> | ||
| 9 | <refpurpose>Enumerate media bus formats</refpurpose> | ||
| 10 | </refnamediv> | ||
| 11 | |||
| 12 | <refsynopsisdiv> | ||
| 13 | <funcsynopsis> | ||
| 14 | <funcprototype> | ||
| 15 | <funcdef>int <function>ioctl</function></funcdef> | ||
| 16 | <paramdef>int <parameter>fd</parameter></paramdef> | ||
| 17 | <paramdef>int <parameter>request</parameter></paramdef> | ||
| 18 | <paramdef>struct v4l2_subdev_mbus_code_enum * | ||
| 19 | <parameter>argp</parameter></paramdef> | ||
| 20 | </funcprototype> | ||
| 21 | </funcsynopsis> | ||
| 22 | </refsynopsisdiv> | ||
| 23 | |||
| 24 | <refsect1> | ||
| 25 | <title>Arguments</title> | ||
| 26 | |||
| 27 | <variablelist> | ||
| 28 | <varlistentry> | ||
| 29 | <term><parameter>fd</parameter></term> | ||
| 30 | <listitem> | ||
| 31 | <para>&fd;</para> | ||
| 32 | </listitem> | ||
| 33 | </varlistentry> | ||
| 34 | <varlistentry> | ||
| 35 | <term><parameter>request</parameter></term> | ||
| 36 | <listitem> | ||
| 37 | <para>VIDIOC_SUBDEV_ENUM_MBUS_CODE</para> | ||
| 38 | </listitem> | ||
| 39 | </varlistentry> | ||
| 40 | <varlistentry> | ||
| 41 | <term><parameter>argp</parameter></term> | ||
| 42 | <listitem> | ||
| 43 | <para></para> | ||
| 44 | </listitem> | ||
| 45 | </varlistentry> | ||
| 46 | </variablelist> | ||
| 47 | </refsect1> | ||
| 48 | |||
| 49 | <refsect1> | ||
| 50 | <title>Description</title> | ||
| 51 | |||
| 52 | <note> | ||
| 53 | <title>Experimental</title> | ||
| 54 | <para>This is an <link linkend="experimental">experimental</link> | ||
| 55 | interface and may change in the future.</para> | ||
| 56 | </note> | ||
| 57 | |||
| 58 | <para>To enumerate media bus formats available at a given sub-device pad | ||
| 59 | applications initialize the <structfield>pad</structfield> and | ||
| 60 | <structfield>index</structfield> fields of &v4l2-subdev-mbus-code-enum; and | ||
| 61 | call the <constant>VIDIOC_SUBDEV_ENUM_MBUS_CODE</constant> ioctl with a | ||
| 62 | pointer to this structure. Drivers fill the rest of the structure or return | ||
| 63 | an &EINVAL; if either the <structfield>pad</structfield> or | ||
| 64 | <structfield>index</structfield> are invalid. All media bus formats are | ||
| 65 | enumerable by beginning at index zero and incrementing by one until | ||
| 66 | <errorcode>EINVAL</errorcode> is returned.</para> | ||
| 67 | |||
| 68 | <para>Available media bus formats may depend on the current 'try' formats | ||
| 69 | at other pads of the sub-device, as well as on the current active links. See | ||
| 70 | &VIDIOC-SUBDEV-G-FMT; for more information about the try formats.</para> | ||
| 71 | |||
| 72 | <table pgwide="1" frame="none" id="v4l2-subdev-mbus-code-enum"> | ||
| 73 | <title>struct <structname>v4l2_subdev_mbus_code_enum</structname></title> | ||
| 74 | <tgroup cols="3"> | ||
| 75 | &cs-str; | ||
| 76 | <tbody valign="top"> | ||
| 77 | <row> | ||
| 78 | <entry>__u32</entry> | ||
| 79 | <entry><structfield>pad</structfield></entry> | ||
| 80 | <entry>Pad number as reported by the media controller API.</entry> | ||
| 81 | </row> | ||
| 82 | <row> | ||
| 83 | <entry>__u32</entry> | ||
| 84 | <entry><structfield>index</structfield></entry> | ||
| 85 | <entry>Number of the format in the enumeration, set by the | ||
| 86 | application.</entry> | ||
| 87 | </row> | ||
| 88 | <row> | ||
| 89 | <entry>__u32</entry> | ||
| 90 | <entry><structfield>code</structfield></entry> | ||
| 91 | <entry>The media bus format code, as defined in | ||
| 92 | <xref linkend="v4l2-mbus-format" />.</entry> | ||
| 93 | </row> | ||
| 94 | <row> | ||
| 95 | <entry>__u32</entry> | ||
| 96 | <entry><structfield>reserved</structfield>[9]</entry> | ||
| 97 | <entry>Reserved for future extensions. Applications and drivers must | ||
| 98 | set the array to zero.</entry> | ||
| 99 | </row> | ||
| 100 | </tbody> | ||
| 101 | </tgroup> | ||
| 102 | </table> | ||
| 103 | </refsect1> | ||
| 104 | |||
| 105 | <refsect1> | ||
| 106 | &return-value; | ||
| 107 | |||
| 108 | <variablelist> | ||
| 109 | <varlistentry> | ||
| 110 | <term><errorcode>EINVAL</errorcode></term> | ||
| 111 | <listitem> | ||
| 112 | <para>The &v4l2-subdev-mbus-code-enum; <structfield>pad</structfield> | ||
| 113 | references a non-existing pad, or the <structfield>index</structfield> | ||
| 114 | field is out of bounds.</para> | ||
| 115 | </listitem> | ||
| 116 | </varlistentry> | ||
| 117 | </variablelist> | ||
| 118 | </refsect1> | ||
| 119 | </refentry> | ||
diff --git a/Documentation/DocBook/v4l/vidioc-subdev-g-crop.xml b/Documentation/DocBook/v4l/vidioc-subdev-g-crop.xml new file mode 100644 index 000000000000..06197323a8cc --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-subdev-g-crop.xml | |||
| @@ -0,0 +1,155 @@ | |||
| 1 | <refentry id="vidioc-subdev-g-crop"> | ||
| 2 | <refmeta> | ||
| 3 | <refentrytitle>ioctl VIDIOC_SUBDEV_G_CROP, VIDIOC_SUBDEV_S_CROP</refentrytitle> | ||
| 4 | &manvol; | ||
| 5 | </refmeta> | ||
| 6 | |||
| 7 | <refnamediv> | ||
| 8 | <refname>VIDIOC_SUBDEV_G_CROP</refname> | ||
| 9 | <refname>VIDIOC_SUBDEV_S_CROP</refname> | ||
| 10 | <refpurpose>Get or set the crop rectangle on a subdev pad</refpurpose> | ||
| 11 | </refnamediv> | ||
| 12 | |||
| 13 | <refsynopsisdiv> | ||
| 14 | <funcsynopsis> | ||
| 15 | <funcprototype> | ||
| 16 | <funcdef>int <function>ioctl</function></funcdef> | ||
| 17 | <paramdef>int <parameter>fd</parameter></paramdef> | ||
| 18 | <paramdef>int <parameter>request</parameter></paramdef> | ||
| 19 | <paramdef>struct v4l2_subdev_crop *<parameter>argp</parameter></paramdef> | ||
| 20 | </funcprototype> | ||
| 21 | </funcsynopsis> | ||
| 22 | <funcsynopsis> | ||
| 23 | <funcprototype> | ||
| 24 | <funcdef>int <function>ioctl</function></funcdef> | ||
| 25 | <paramdef>int <parameter>fd</parameter></paramdef> | ||
| 26 | <paramdef>int <parameter>request</parameter></paramdef> | ||
| 27 | <paramdef>const struct v4l2_subdev_crop *<parameter>argp</parameter></paramdef> | ||
| 28 | </funcprototype> | ||
| 29 | </funcsynopsis> | ||
| 30 | </refsynopsisdiv> | ||
| 31 | |||
| 32 | <refsect1> | ||
| 33 | <title>Arguments</title> | ||
| 34 | |||
| 35 | <variablelist> | ||
| 36 | <varlistentry> | ||
| 37 | <term><parameter>fd</parameter></term> | ||
| 38 | <listitem> | ||
| 39 | <para>&fd;</para> | ||
| 40 | </listitem> | ||
| 41 | </varlistentry> | ||
| 42 | <varlistentry> | ||
| 43 | <term><parameter>request</parameter></term> | ||
| 44 | <listitem> | ||
| 45 | <para>VIDIOC_SUBDEV_G_CROP, VIDIOC_SUBDEV_S_CROP</para> | ||
| 46 | </listitem> | ||
| 47 | </varlistentry> | ||
| 48 | <varlistentry> | ||
| 49 | <term><parameter>argp</parameter></term> | ||
| 50 | <listitem> | ||
| 51 | <para></para> | ||
| 52 | </listitem> | ||
| 53 | </varlistentry> | ||
| 54 | </variablelist> | ||
| 55 | </refsect1> | ||
| 56 | |||
| 57 | <refsect1> | ||
| 58 | <title>Description</title> | ||
| 59 | |||
| 60 | <note> | ||
| 61 | <title>Experimental</title> | ||
| 62 | <para>This is an <link linkend="experimental">experimental</link> | ||
| 63 | interface and may change in the future.</para> | ||
| 64 | </note> | ||
| 65 | |||
| 66 | <para>To retrieve the current crop rectangle applications set the | ||
| 67 | <structfield>pad</structfield> field of a &v4l2-subdev-crop; to the | ||
| 68 | desired pad number as reported by the media API and the | ||
| 69 | <structfield>which</structfield> field to | ||
| 70 | <constant>V4L2_SUBDEV_FORMAT_ACTIVE</constant>. They then call the | ||
| 71 | <constant>VIDIOC_SUBDEV_G_CROP</constant> ioctl with a pointer to this | ||
| 72 | structure. The driver fills the members of the <structfield>rect</structfield> | ||
| 73 | field or returns &EINVAL; if the input arguments are invalid, or if cropping | ||
| 74 | is not supported on the given pad.</para> | ||
| 75 | |||
| 76 | <para>To change the current crop rectangle applications set both the | ||
| 77 | <structfield>pad</structfield> and <structfield>which</structfield> fields | ||
| 78 | and all members of the <structfield>rect</structfield> field. They then call | ||
| 79 | the <constant>VIDIOC_SUBDEV_S_CROP</constant> ioctl with a pointer to this | ||
| 80 | structure. The driver verifies the requested crop rectangle, adjusts it | ||
| 81 | based on the hardware capabilities and configures the device. Upon return | ||
| 82 | the &v4l2-subdev-crop; contains the current format as would be returned | ||
| 83 | by a <constant>VIDIOC_SUBDEV_G_CROP</constant> call.</para> | ||
| 84 | |||
| 85 | <para>Applications can query the device capabilities by setting the | ||
| 86 | <structfield>which</structfield> to | ||
| 87 | <constant>V4L2_SUBDEV_FORMAT_TRY</constant>. When set, 'try' crop | ||
| 88 | rectangles are not applied to the device by the driver, but are mangled | ||
| 89 | exactly as active crop rectangles and stored in the sub-device file handle. | ||
| 90 | Two applications querying the same sub-device would thus not interact with | ||
| 91 | each other.</para> | ||
| 92 | |||
| 93 | <para>Drivers must not return an error solely because the requested crop | ||
| 94 | rectangle doesn't match the device capabilities. They must instead modify | ||
| 95 | the rectangle to match what the hardware can provide. The modified format | ||
| 96 | should be as close as possible to the original request.</para> | ||
| 97 | |||
| 98 | <table pgwide="1" frame="none" id="v4l2-subdev-crop"> | ||
| 99 | <title>struct <structname>v4l2_subdev_crop</structname></title> | ||
| 100 | <tgroup cols="3"> | ||
| 101 | &cs-str; | ||
| 102 | <tbody valign="top"> | ||
| 103 | <row> | ||
| 104 | <entry>__u32</entry> | ||
| 105 | <entry><structfield>pad</structfield></entry> | ||
| 106 | <entry>Pad number as reported by the media framework.</entry> | ||
| 107 | </row> | ||
| 108 | <row> | ||
| 109 | <entry>__u32</entry> | ||
| 110 | <entry><structfield>which</structfield></entry> | ||
| 111 | <entry>Crop rectangle to get or set, from | ||
| 112 | &v4l2-subdev-format-whence;.</entry> | ||
| 113 | </row> | ||
| 114 | <row> | ||
| 115 | <entry>&v4l2-rect;</entry> | ||
| 116 | <entry><structfield>rect</structfield></entry> | ||
| 117 | <entry>Crop rectangle boundaries, in pixels.</entry> | ||
| 118 | </row> | ||
| 119 | <row> | ||
| 120 | <entry>__u32</entry> | ||
| 121 | <entry><structfield>reserved</structfield>[8]</entry> | ||
| 122 | <entry>Reserved for future extensions. Applications and drivers must | ||
| 123 | set the array to zero.</entry> | ||
| 124 | </row> | ||
| 125 | </tbody> | ||
| 126 | </tgroup> | ||
| 127 | </table> | ||
| 128 | </refsect1> | ||
| 129 | |||
| 130 | <refsect1> | ||
| 131 | &return-value; | ||
| 132 | |||
| 133 | <variablelist> | ||
| 134 | <varlistentry> | ||
| 135 | <term><errorcode>EBUSY</errorcode></term> | ||
| 136 | <listitem> | ||
| 137 | <para>The crop rectangle can't be changed because the pad is currently | ||
| 138 | busy. This can be caused, for instance, by an active video stream on | ||
| 139 | the pad. The ioctl must not be retried without performing another | ||
| 140 | action to fix the problem first. Only returned by | ||
| 141 | <constant>VIDIOC_SUBDEV_S_CROP</constant></para> | ||
| 142 | </listitem> | ||
| 143 | </varlistentry> | ||
| 144 | <varlistentry> | ||
| 145 | <term><errorcode>EINVAL</errorcode></term> | ||
| 146 | <listitem> | ||
| 147 | <para>The &v4l2-subdev-crop; <structfield>pad</structfield> | ||
| 148 | references a non-existing pad, the <structfield>which</structfield> | ||
| 149 | field references a non-existing format, or cropping is not supported | ||
| 150 | on the given subdev pad.</para> | ||
| 151 | </listitem> | ||
| 152 | </varlistentry> | ||
| 153 | </variablelist> | ||
| 154 | </refsect1> | ||
| 155 | </refentry> | ||
diff --git a/Documentation/DocBook/v4l/vidioc-subdev-g-fmt.xml b/Documentation/DocBook/v4l/vidioc-subdev-g-fmt.xml new file mode 100644 index 000000000000..f367c570c530 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-subdev-g-fmt.xml | |||
| @@ -0,0 +1,180 @@ | |||
| 1 | <refentry id="vidioc-subdev-g-fmt"> | ||
| 2 | <refmeta> | ||
| 3 | <refentrytitle>ioctl VIDIOC_SUBDEV_G_FMT, VIDIOC_SUBDEV_S_FMT</refentrytitle> | ||
| 4 | &manvol; | ||
| 5 | </refmeta> | ||
| 6 | |||
| 7 | <refnamediv> | ||
| 8 | <refname>VIDIOC_SUBDEV_G_FMT</refname> | ||
| 9 | <refname>VIDIOC_SUBDEV_S_FMT</refname> | ||
| 10 | <refpurpose>Get or set the data format on a subdev pad</refpurpose> | ||
| 11 | </refnamediv> | ||
| 12 | |||
| 13 | <refsynopsisdiv> | ||
| 14 | <funcsynopsis> | ||
| 15 | <funcprototype> | ||
| 16 | <funcdef>int <function>ioctl</function></funcdef> | ||
| 17 | <paramdef>int <parameter>fd</parameter></paramdef> | ||
| 18 | <paramdef>int <parameter>request</parameter></paramdef> | ||
| 19 | <paramdef>struct v4l2_subdev_format *<parameter>argp</parameter> | ||
| 20 | </paramdef> | ||
| 21 | </funcprototype> | ||
| 22 | </funcsynopsis> | ||
| 23 | </refsynopsisdiv> | ||
| 24 | |||
| 25 | <refsect1> | ||
| 26 | <title>Arguments</title> | ||
| 27 | |||
| 28 | <variablelist> | ||
| 29 | <varlistentry> | ||
| 30 | <term><parameter>fd</parameter></term> | ||
| 31 | <listitem> | ||
| 32 | <para>&fd;</para> | ||
| 33 | </listitem> | ||
| 34 | </varlistentry> | ||
| 35 | <varlistentry> | ||
| 36 | <term><parameter>request</parameter></term> | ||
| 37 | <listitem> | ||
| 38 | <para>VIDIOC_SUBDEV_G_FMT, VIDIOC_SUBDEV_S_FMT</para> | ||
| 39 | </listitem> | ||
| 40 | </varlistentry> | ||
| 41 | <varlistentry> | ||
| 42 | <term><parameter>argp</parameter></term> | ||
| 43 | <listitem> | ||
| 44 | <para></para> | ||
| 45 | </listitem> | ||
| 46 | </varlistentry> | ||
| 47 | </variablelist> | ||
| 48 | </refsect1> | ||
| 49 | |||
| 50 | <refsect1> | ||
| 51 | <title>Description</title> | ||
| 52 | |||
| 53 | <note> | ||
| 54 | <title>Experimental</title> | ||
| 55 | <para>This is an <link linkend="experimental">experimental</link> | ||
| 56 | interface and may change in the future.</para> | ||
| 57 | </note> | ||
| 58 | |||
| 59 | <para>These ioctls are used to negotiate the frame format at specific | ||
| 60 | subdev pads in the image pipeline.</para> | ||
| 61 | |||
| 62 | <para>To retrieve the current format applications set the | ||
| 63 | <structfield>pad</structfield> field of a &v4l2-subdev-format; to the | ||
| 64 | desired pad number as reported by the media API and the | ||
| 65 | <structfield>which</structfield> field to | ||
| 66 | <constant>V4L2_SUBDEV_FORMAT_ACTIVE</constant>. When they call the | ||
| 67 | <constant>VIDIOC_SUBDEV_G_FMT</constant> ioctl with a pointer to this | ||
| 68 | structure the driver fills the members of the <structfield>format</structfield> | ||
| 69 | field.</para> | ||
| 70 | |||
| 71 | <para>To change the current format applications set both the | ||
| 72 | <structfield>pad</structfield> and <structfield>which</structfield> fields | ||
| 73 | and all members of the <structfield>format</structfield> field. When they | ||
| 74 | call the <constant>VIDIOC_SUBDEV_S_FMT</constant> ioctl with a pointer to this | ||
| 75 | structure the driver verifies the requested format, adjusts it based on the | ||
| 76 | hardware capabilities and configures the device. Upon return the | ||
| 77 | &v4l2-subdev-format; contains the current format as would be returned by a | ||
| 78 | <constant>VIDIOC_SUBDEV_G_FMT</constant> call.</para> | ||
| 79 | |||
| 80 | <para>Applications can query the device capabilities by setting the | ||
| 81 | <structfield>which</structfield> to | ||
| 82 | <constant>V4L2_SUBDEV_FORMAT_TRY</constant>. When set, 'try' formats are not | ||
| 83 | applied to the device by the driver, but are changed exactly as active | ||
| 84 | formats and stored in the sub-device file handle. Two applications querying | ||
| 85 | the same sub-device would thus not interact with each other.</para> | ||
| 86 | |||
| 87 | <para>For instance, to try a format at the output pad of a sub-device, | ||
| 88 | applications would first set the try format at the sub-device input with the | ||
| 89 | <constant>VIDIOC_SUBDEV_S_FMT</constant> ioctl. They would then either | ||
| 90 | retrieve the default format at the output pad with the | ||
| 91 | <constant>VIDIOC_SUBDEV_G_FMT</constant> ioctl, or set the desired output | ||
| 92 | pad format with the <constant>VIDIOC_SUBDEV_S_FMT</constant> ioctl and check | ||
| 93 | the returned value.</para> | ||
| 94 | |||
| 95 | <para>Try formats do not depend on active formats, but can depend on the | ||
| 96 | current links configuration or sub-device controls value. For instance, a | ||
| 97 | low-pass noise filter might crop pixels at the frame boundaries, modifying | ||
| 98 | its output frame size.</para> | ||
| 99 | |||
| 100 | <para>Drivers must not return an error solely because the requested format | ||
| 101 | doesn't match the device capabilities. They must instead modify the format | ||
| 102 | to match what the hardware can provide. The modified format should be as | ||
| 103 | close as possible to the original request.</para> | ||
| 104 | |||
| 105 | <table pgwide="1" frame="none" id="v4l2-subdev-format"> | ||
| 106 | <title>struct <structname>v4l2_subdev_format</structname></title> | ||
| 107 | <tgroup cols="3"> | ||
| 108 | &cs-str; | ||
| 109 | <tbody valign="top"> | ||
| 110 | <row> | ||
| 111 | <entry>__u32</entry> | ||
| 112 | <entry><structfield>pad</structfield></entry> | ||
| 113 | <entry>Pad number as reported by the media controller API.</entry> | ||
| 114 | </row> | ||
| 115 | <row> | ||
| 116 | <entry>__u32</entry> | ||
| 117 | <entry><structfield>which</structfield></entry> | ||
| 118 | <entry>Format to modified, from &v4l2-subdev-format-whence;.</entry> | ||
| 119 | </row> | ||
| 120 | <row> | ||
| 121 | <entry>&v4l2-mbus-framefmt;</entry> | ||
| 122 | <entry><structfield>format</structfield></entry> | ||
| 123 | <entry>Definition of an image format, see <xref | ||
| 124 | linkend="v4l2-mbus-framefmt" /> for details.</entry> | ||
| 125 | </row> | ||
| 126 | <row> | ||
| 127 | <entry>__u32</entry> | ||
| 128 | <entry><structfield>reserved</structfield>[8]</entry> | ||
| 129 | <entry>Reserved for future extensions. Applications and drivers must | ||
| 130 | set the array to zero.</entry> | ||
| 131 | </row> | ||
| 132 | </tbody> | ||
| 133 | </tgroup> | ||
| 134 | </table> | ||
| 135 | |||
| 136 | <table pgwide="1" frame="none" id="v4l2-subdev-format-whence"> | ||
| 137 | <title>enum <structname>v4l2_subdev_format_whence</structname></title> | ||
| 138 | <tgroup cols="3"> | ||
| 139 | &cs-def; | ||
| 140 | <tbody valign="top"> | ||
| 141 | <row> | ||
| 142 | <entry>V4L2_SUBDEV_FORMAT_TRY</entry> | ||
| 143 | <entry>0</entry> | ||
| 144 | <entry>Try formats, used for querying device capabilities.</entry> | ||
| 145 | </row> | ||
| 146 | <row> | ||
| 147 | <entry>V4L2_SUBDEV_FORMAT_ACTIVE</entry> | ||
| 148 | <entry>1</entry> | ||
| 149 | <entry>Active formats, applied to the hardware.</entry> | ||
| 150 | </row> | ||
| 151 | </tbody> | ||
| 152 | </tgroup> | ||
| 153 | </table> | ||
| 154 | </refsect1> | ||
| 155 | |||
| 156 | <refsect1> | ||
| 157 | &return-value; | ||
| 158 | |||
| 159 | <variablelist> | ||
| 160 | <varlistentry> | ||
| 161 | <term><errorcode>EBUSY</errorcode></term> | ||
| 162 | <listitem> | ||
| 163 | <para>The format can't be changed because the pad is currently busy. | ||
| 164 | This can be caused, for instance, by an active video stream on the | ||
| 165 | pad. The ioctl must not be retried without performing another action | ||
| 166 | to fix the problem first. Only returned by | ||
| 167 | <constant>VIDIOC_SUBDEV_S_FMT</constant></para> | ||
| 168 | </listitem> | ||
| 169 | </varlistentry> | ||
| 170 | <varlistentry> | ||
| 171 | <term><errorcode>EINVAL</errorcode></term> | ||
| 172 | <listitem> | ||
| 173 | <para>The &v4l2-subdev-format; <structfield>pad</structfield> | ||
| 174 | references a non-existing pad, or the <structfield>which</structfield> | ||
| 175 | field references a non-existing format.</para> | ||
| 176 | </listitem> | ||
| 177 | </varlistentry> | ||
| 178 | </variablelist> | ||
| 179 | </refsect1> | ||
| 180 | </refentry> | ||
diff --git a/Documentation/DocBook/v4l/vidioc-subdev-g-frame-interval.xml b/Documentation/DocBook/v4l/vidioc-subdev-g-frame-interval.xml new file mode 100644 index 000000000000..0bc3ea22d31f --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-subdev-g-frame-interval.xml | |||
| @@ -0,0 +1,141 @@ | |||
| 1 | <refentry id="vidioc-subdev-g-frame-interval"> | ||
| 2 | <refmeta> | ||
| 3 | <refentrytitle>ioctl VIDIOC_SUBDEV_G_FRAME_INTERVAL, VIDIOC_SUBDEV_S_FRAME_INTERVAL</refentrytitle> | ||
| 4 | &manvol; | ||
| 5 | </refmeta> | ||
| 6 | |||
| 7 | <refnamediv> | ||
| 8 | <refname>VIDIOC_SUBDEV_G_FRAME_INTERVAL</refname> | ||
| 9 | <refname>VIDIOC_SUBDEV_S_FRAME_INTERVAL</refname> | ||
| 10 | <refpurpose>Get or set the frame interval on a subdev pad</refpurpose> | ||
| 11 | </refnamediv> | ||
| 12 | |||
| 13 | <refsynopsisdiv> | ||
| 14 | <funcsynopsis> | ||
| 15 | <funcprototype> | ||
| 16 | <funcdef>int <function>ioctl</function></funcdef> | ||
| 17 | <paramdef>int <parameter>fd</parameter></paramdef> | ||
| 18 | <paramdef>int <parameter>request</parameter></paramdef> | ||
| 19 | <paramdef>struct v4l2_subdev_frame_interval *<parameter>argp</parameter> | ||
| 20 | </paramdef> | ||
| 21 | </funcprototype> | ||
| 22 | </funcsynopsis> | ||
| 23 | </refsynopsisdiv> | ||
| 24 | |||
| 25 | <refsect1> | ||
| 26 | <title>Arguments</title> | ||
| 27 | |||
| 28 | <variablelist> | ||
| 29 | <varlistentry> | ||
| 30 | <term><parameter>fd</parameter></term> | ||
| 31 | <listitem> | ||
| 32 | <para>&fd;</para> | ||
| 33 | </listitem> | ||
| 34 | </varlistentry> | ||
| 35 | <varlistentry> | ||
| 36 | <term><parameter>request</parameter></term> | ||
| 37 | <listitem> | ||
| 38 | <para>VIDIOC_SUBDEV_G_FRAME_INTERVAL, VIDIOC_SUBDEV_S_FRAME_INTERVAL</para> | ||
| 39 | </listitem> | ||
| 40 | </varlistentry> | ||
| 41 | <varlistentry> | ||
| 42 | <term><parameter>argp</parameter></term> | ||
| 43 | <listitem> | ||
| 44 | <para></para> | ||
| 45 | </listitem> | ||
| 46 | </varlistentry> | ||
| 47 | </variablelist> | ||
| 48 | </refsect1> | ||
| 49 | |||
| 50 | <refsect1> | ||
| 51 | <title>Description</title> | ||
| 52 | |||
| 53 | <note> | ||
| 54 | <title>Experimental</title> | ||
| 55 | <para>This is an <link linkend="experimental">experimental</link> | ||
| 56 | interface and may change in the future.</para> | ||
| 57 | </note> | ||
| 58 | |||
| 59 | <para>These ioctls are used to get and set the frame interval at specific | ||
| 60 | subdev pads in the image pipeline. The frame interval only makes sense for | ||
| 61 | sub-devices that can control the frame period on their own. This includes, | ||
| 62 | for instance, image sensors and TV tuners. Sub-devices that don't support | ||
| 63 | frame intervals must not implement these ioctls.</para> | ||
| 64 | |||
| 65 | <para>To retrieve the current frame interval applications set the | ||
| 66 | <structfield>pad</structfield> field of a &v4l2-subdev-frame-interval; to | ||
| 67 | the desired pad number as reported by the media controller API. When they | ||
| 68 | call the <constant>VIDIOC_SUBDEV_G_FRAME_INTERVAL</constant> ioctl with a | ||
| 69 | pointer to this structure the driver fills the members of the | ||
| 70 | <structfield>interval</structfield> field.</para> | ||
| 71 | |||
| 72 | <para>To change the current frame interval applications set both the | ||
| 73 | <structfield>pad</structfield> field and all members of the | ||
| 74 | <structfield>interval</structfield> field. When they call the | ||
| 75 | <constant>VIDIOC_SUBDEV_S_FRAME_INTERVAL</constant> ioctl with a pointer to | ||
| 76 | this structure the driver verifies the requested interval, adjusts it based | ||
| 77 | on the hardware capabilities and configures the device. Upon return the | ||
| 78 | &v4l2-subdev-frame-interval; contains the current frame interval as would be | ||
| 79 | returned by a <constant>VIDIOC_SUBDEV_G_FRAME_INTERVAL</constant> call. | ||
| 80 | </para> | ||
| 81 | |||
| 82 | <para>Drivers must not return an error solely because the requested interval | ||
| 83 | doesn't match the device capabilities. They must instead modify the interval | ||
| 84 | to match what the hardware can provide. The modified interval should be as | ||
| 85 | close as possible to the original request.</para> | ||
| 86 | |||
| 87 | <para>Sub-devices that support the frame interval ioctls should implement | ||
| 88 | them on a single pad only. Their behaviour when supported on multiple pads | ||
| 89 | of the same sub-device is not defined.</para> | ||
| 90 | |||
| 91 | <table pgwide="1" frame="none" id="v4l2-subdev-frame-interval"> | ||
| 92 | <title>struct <structname>v4l2_subdev_frame_interval</structname></title> | ||
| 93 | <tgroup cols="3"> | ||
| 94 | &cs-str; | ||
| 95 | <tbody valign="top"> | ||
| 96 | <row> | ||
| 97 | <entry>__u32</entry> | ||
| 98 | <entry><structfield>pad</structfield></entry> | ||
| 99 | <entry>Pad number as reported by the media controller API.</entry> | ||
| 100 | </row> | ||
| 101 | <row> | ||
| 102 | <entry>&v4l2-fract;</entry> | ||
| 103 | <entry><structfield>interval</structfield></entry> | ||
| 104 | <entry>Period, in seconds, between consecutive video frames.</entry> | ||
| 105 | </row> | ||
| 106 | <row> | ||
| 107 | <entry>__u32</entry> | ||
| 108 | <entry><structfield>reserved</structfield>[9]</entry> | ||
| 109 | <entry>Reserved for future extensions. Applications and drivers must | ||
| 110 | set the array to zero.</entry> | ||
| 111 | </row> | ||
| 112 | </tbody> | ||
| 113 | </tgroup> | ||
| 114 | </table> | ||
| 115 | </refsect1> | ||
| 116 | |||
| 117 | <refsect1> | ||
| 118 | &return-value; | ||
| 119 | |||
| 120 | <variablelist> | ||
| 121 | <varlistentry> | ||
| 122 | <term><errorcode>EBUSY</errorcode></term> | ||
| 123 | <listitem> | ||
| 124 | <para>The frame interval can't be changed because the pad is currently | ||
| 125 | busy. This can be caused, for instance, by an active video stream on | ||
| 126 | the pad. The ioctl must not be retried without performing another | ||
| 127 | action to fix the problem first. Only returned by | ||
| 128 | <constant>VIDIOC_SUBDEV_S_FRAME_INTERVAL</constant></para> | ||
| 129 | </listitem> | ||
| 130 | </varlistentry> | ||
| 131 | <varlistentry> | ||
| 132 | <term><errorcode>EINVAL</errorcode></term> | ||
| 133 | <listitem> | ||
| 134 | <para>The &v4l2-subdev-frame-interval; <structfield>pad</structfield> | ||
| 135 | references a non-existing pad, or the pad doesn't support frame | ||
| 136 | intervals.</para> | ||
| 137 | </listitem> | ||
| 138 | </varlistentry> | ||
| 139 | </variablelist> | ||
| 140 | </refsect1> | ||
| 141 | </refentry> | ||
diff --git a/Documentation/DocBook/writing-an-alsa-driver.tmpl b/Documentation/DocBook/writing-an-alsa-driver.tmpl index 0ba149de2608..58ced2346e67 100644 --- a/Documentation/DocBook/writing-an-alsa-driver.tmpl +++ b/Documentation/DocBook/writing-an-alsa-driver.tmpl | |||
| @@ -4784,7 +4784,7 @@ struct _snd_pcm_runtime { | |||
| 4784 | FM registers can be directly accessed through the direct-FM API, | 4784 | FM registers can be directly accessed through the direct-FM API, |
| 4785 | defined in <filename><sound/asound_fm.h></filename>. In | 4785 | defined in <filename><sound/asound_fm.h></filename>. In |
| 4786 | ALSA native mode, FM registers are accessed through | 4786 | ALSA native mode, FM registers are accessed through |
| 4787 | the Hardware-Dependant Device direct-FM extension API, whereas in | 4787 | the Hardware-Dependent Device direct-FM extension API, whereas in |
| 4788 | OSS compatible mode, FM registers can be accessed with the OSS | 4788 | OSS compatible mode, FM registers can be accessed with the OSS |
| 4789 | direct-FM compatible API in <filename>/dev/dmfmX</filename> device. | 4789 | direct-FM compatible API in <filename>/dev/dmfmX</filename> device. |
| 4790 | </para> | 4790 | </para> |
diff --git a/Documentation/PCI/MSI-HOWTO.txt b/Documentation/PCI/MSI-HOWTO.txt index dcf7acc720e1..3f5e0b09bed5 100644 --- a/Documentation/PCI/MSI-HOWTO.txt +++ b/Documentation/PCI/MSI-HOWTO.txt | |||
| @@ -253,8 +253,8 @@ In constrast, MSI is restricted to a maximum of 32 interrupts (and | |||
| 253 | must be a power of two). In addition, the MSI interrupt vectors must | 253 | must be a power of two). In addition, the MSI interrupt vectors must |
| 254 | be allocated consecutively, so the system may not be able to allocate | 254 | be allocated consecutively, so the system may not be able to allocate |
| 255 | as many vectors for MSI as it could for MSI-X. On some platforms, MSI | 255 | as many vectors for MSI as it could for MSI-X. On some platforms, MSI |
| 256 | interrupts must all be targetted at the same set of CPUs whereas MSI-X | 256 | interrupts must all be targeted at the same set of CPUs whereas MSI-X |
| 257 | interrupts can all be targetted at different CPUs. | 257 | interrupts can all be targeted at different CPUs. |
| 258 | 258 | ||
| 259 | 4.5.2 Spinlocks | 259 | 4.5.2 Spinlocks |
| 260 | 260 | ||
diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt index cfaac34c4557..6ef692667e2f 100644 --- a/Documentation/RCU/whatisRCU.txt +++ b/Documentation/RCU/whatisRCU.txt | |||
| @@ -849,6 +849,37 @@ All: lockdep-checked RCU-protected pointer access | |||
| 849 | See the comment headers in the source code (or the docbook generated | 849 | See the comment headers in the source code (or the docbook generated |
| 850 | from them) for more information. | 850 | from them) for more information. |
| 851 | 851 | ||
| 852 | However, given that there are no fewer than four families of RCU APIs | ||
| 853 | in the Linux kernel, how do you choose which one to use? The following | ||
| 854 | list can be helpful: | ||
| 855 | |||
| 856 | a. Will readers need to block? If so, you need SRCU. | ||
| 857 | |||
| 858 | b. What about the -rt patchset? If readers would need to block | ||
| 859 | in an non-rt kernel, you need SRCU. If readers would block | ||
| 860 | in a -rt kernel, but not in a non-rt kernel, SRCU is not | ||
| 861 | necessary. | ||
| 862 | |||
| 863 | c. Do you need to treat NMI handlers, hardirq handlers, | ||
| 864 | and code segments with preemption disabled (whether | ||
| 865 | via preempt_disable(), local_irq_save(), local_bh_disable(), | ||
| 866 | or some other mechanism) as if they were explicit RCU readers? | ||
| 867 | If so, you need RCU-sched. | ||
| 868 | |||
| 869 | d. Do you need RCU grace periods to complete even in the face | ||
| 870 | of softirq monopolization of one or more of the CPUs? For | ||
| 871 | example, is your code subject to network-based denial-of-service | ||
| 872 | attacks? If so, you need RCU-bh. | ||
| 873 | |||
| 874 | e. Is your workload too update-intensive for normal use of | ||
| 875 | RCU, but inappropriate for other synchronization mechanisms? | ||
| 876 | If so, consider SLAB_DESTROY_BY_RCU. But please be careful! | ||
| 877 | |||
| 878 | f. Otherwise, use RCU. | ||
| 879 | |||
| 880 | Of course, this all assumes that you have determined that RCU is in fact | ||
| 881 | the right tool for your job. | ||
| 882 | |||
| 852 | 883 | ||
| 853 | 8. ANSWERS TO QUICK QUIZZES | 884 | 8. ANSWERS TO QUICK QUIZZES |
| 854 | 885 | ||
diff --git a/Documentation/SecurityBugs b/Documentation/SecurityBugs index 26c3b3635d9f..a660d494c8ed 100644 --- a/Documentation/SecurityBugs +++ b/Documentation/SecurityBugs | |||
| @@ -28,7 +28,7 @@ expect these delays to be short, measurable in days, not weeks or months. | |||
| 28 | A disclosure date is negotiated by the security team working with the | 28 | A disclosure date is negotiated by the security team working with the |
| 29 | bug submitter as well as vendors. However, the kernel security team | 29 | bug submitter as well as vendors. However, the kernel security team |
| 30 | holds the final say when setting a disclosure date. The timeframe for | 30 | holds the final say when setting a disclosure date. The timeframe for |
| 31 | disclosure is from immediate (esp. if it's already publically known) | 31 | disclosure is from immediate (esp. if it's already publicly known) |
| 32 | to a few weeks. As a basic default policy, we expect report date to | 32 | to a few weeks. As a basic default policy, we expect report date to |
| 33 | disclosure date to be on the order of 7 days. | 33 | disclosure date to be on the order of 7 days. |
| 34 | 34 | ||
diff --git a/Documentation/SubmittingDrivers b/Documentation/SubmittingDrivers index 38d2aab59cac..319baa8b60dd 100644 --- a/Documentation/SubmittingDrivers +++ b/Documentation/SubmittingDrivers | |||
| @@ -101,7 +101,7 @@ PM support: Since Linux is used on many portable and desktop systems, your | |||
| 101 | complete overview of the power management issues related to | 101 | complete overview of the power management issues related to |
| 102 | drivers see Documentation/power/devices.txt . | 102 | drivers see Documentation/power/devices.txt . |
| 103 | 103 | ||
| 104 | Control: In general if there is active maintainance of a driver by | 104 | Control: In general if there is active maintenance of a driver by |
| 105 | the author then patches will be redirected to them unless | 105 | the author then patches will be redirected to them unless |
| 106 | they are totally obvious and without need of checking. | 106 | they are totally obvious and without need of checking. |
| 107 | If you want to be the contact and update point for the | 107 | If you want to be the contact and update point for the |
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 689e2371095c..e439cd0d3375 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches | |||
| @@ -729,7 +729,7 @@ Linus Torvalds's mail on the canonical patch format: | |||
| 729 | <http://lkml.org/lkml/2005/4/7/183> | 729 | <http://lkml.org/lkml/2005/4/7/183> |
| 730 | 730 | ||
| 731 | Andi Kleen, "On submitting kernel patches" | 731 | Andi Kleen, "On submitting kernel patches" |
| 732 | Some strategies to get difficult or controversal changes in. | 732 | Some strategies to get difficult or controversial changes in. |
| 733 | http://halobates.de/on-submitting-patches.pdf | 733 | http://halobates.de/on-submitting-patches.pdf |
| 734 | 734 | ||
| 735 | -- | 735 | -- |
diff --git a/Documentation/acpi/apei/output_format.txt b/Documentation/acpi/apei/output_format.txt index 9146952c612a..0c49c197c47a 100644 --- a/Documentation/acpi/apei/output_format.txt +++ b/Documentation/acpi/apei/output_format.txt | |||
| @@ -92,6 +92,11 @@ vendor_id: <integer>, device_id: <integer> | |||
| 92 | class_code: <integer>] | 92 | class_code: <integer>] |
| 93 | [serial number: <integer>, <integer>] | 93 | [serial number: <integer>, <integer>] |
| 94 | [bridge: secondary_status: <integer>, control: <integer>] | 94 | [bridge: secondary_status: <integer>, control: <integer>] |
| 95 | [aer_status: <integer>, aer_mask: <integer> | ||
| 96 | <aer status string> | ||
| 97 | [aer_uncor_severity: <integer>] | ||
| 98 | aer_layer=<aer layer string>, aer_agent=<aer agent string> | ||
| 99 | aer_tlp_header: <integer> <integer> <integer> <integer>] | ||
| 95 | 100 | ||
| 96 | <pcie port type string>* := PCIe end point | legacy PCI end point | \ | 101 | <pcie port type string>* := PCIe end point | legacy PCI end point | \ |
| 97 | unknown | unknown | root port | upstream switch port | \ | 102 | unknown | unknown | root port | upstream switch port | \ |
| @@ -99,6 +104,26 @@ downstream switch port | PCIe to PCI/PCI-X bridge | \ | |||
| 99 | PCI/PCI-X to PCIe bridge | root complex integrated endpoint device | \ | 104 | PCI/PCI-X to PCIe bridge | root complex integrated endpoint device | \ |
| 100 | root complex event collector | 105 | root complex event collector |
| 101 | 106 | ||
| 107 | if section severity is fatal or recoverable | ||
| 108 | <aer status string># := | ||
| 109 | unknown | unknown | unknown | unknown | Data Link Protocol | \ | ||
| 110 | unknown | unknown | unknown | unknown | unknown | unknown | unknown | \ | ||
| 111 | Poisoned TLP | Flow Control Protocol | Completion Timeout | \ | ||
| 112 | Completer Abort | Unexpected Completion | Receiver Overflow | \ | ||
| 113 | Malformed TLP | ECRC | Unsupported Request | ||
| 114 | else | ||
| 115 | <aer status string># := | ||
| 116 | Receiver Error | unknown | unknown | unknown | unknown | unknown | \ | ||
| 117 | Bad TLP | Bad DLLP | RELAY_NUM Rollover | unknown | unknown | unknown | \ | ||
| 118 | Replay Timer Timeout | Advisory Non-Fatal | ||
| 119 | fi | ||
| 120 | |||
| 121 | <aer layer string> := | ||
| 122 | Physical Layer | Data Link Layer | Transaction Layer | ||
| 123 | |||
| 124 | <aer agent string> := | ||
| 125 | Receiver ID | Requester ID | Completer ID | Transmitter ID | ||
| 126 | |||
| 102 | Where, [] designate corresponding content is optional | 127 | Where, [] designate corresponding content is optional |
| 103 | 128 | ||
| 104 | All <field string> description with * has the following format: | 129 | All <field string> description with * has the following format: |
diff --git a/Documentation/arm/IXP4xx b/Documentation/arm/IXP4xx index 133c5fa6c7a1..7b9351f2f555 100644 --- a/Documentation/arm/IXP4xx +++ b/Documentation/arm/IXP4xx | |||
| @@ -36,7 +36,7 @@ Linux currently supports the following features on the IXP4xx chips: | |||
| 36 | - Timers (watchdog, OS) | 36 | - Timers (watchdog, OS) |
| 37 | 37 | ||
| 38 | The following components of the chips are not supported by Linux and | 38 | The following components of the chips are not supported by Linux and |
| 39 | require the use of Intel's propietary CSR softare: | 39 | require the use of Intel's proprietary CSR softare: |
| 40 | 40 | ||
| 41 | - USB device interface | 41 | - USB device interface |
| 42 | - Network interfaces (HSS, Utopia, NPEs, etc) | 42 | - Network interfaces (HSS, Utopia, NPEs, etc) |
| @@ -47,7 +47,7 @@ software from: | |||
| 47 | 47 | ||
| 48 | http://developer.intel.com/design/network/products/npfamily/ixp425.htm | 48 | http://developer.intel.com/design/network/products/npfamily/ixp425.htm |
| 49 | 49 | ||
| 50 | DO NOT POST QUESTIONS TO THE LINUX MAILING LISTS REGARDING THE PROPIETARY | 50 | DO NOT POST QUESTIONS TO THE LINUX MAILING LISTS REGARDING THE PROPRIETARY |
| 51 | SOFTWARE. | 51 | SOFTWARE. |
| 52 | 52 | ||
| 53 | There are several websites that provide directions/pointers on using | 53 | There are several websites that provide directions/pointers on using |
diff --git a/Documentation/arm/SH-Mobile/Makefile b/Documentation/arm/SH-Mobile/Makefile new file mode 100644 index 000000000000..8771d832cf8c --- /dev/null +++ b/Documentation/arm/SH-Mobile/Makefile | |||
| @@ -0,0 +1,8 @@ | |||
| 1 | BIN := vrl4 | ||
| 2 | |||
| 3 | .PHONY: all | ||
| 4 | all: $(BIN) | ||
| 5 | |||
| 6 | .PHONY: clean | ||
| 7 | clean: | ||
| 8 | rm -f *.o $(BIN) | ||
diff --git a/Documentation/arm/SH-Mobile/vrl4.c b/Documentation/arm/SH-Mobile/vrl4.c new file mode 100644 index 000000000000..e8a191358ad2 --- /dev/null +++ b/Documentation/arm/SH-Mobile/vrl4.c | |||
| @@ -0,0 +1,169 @@ | |||
| 1 | /* | ||
| 2 | * vrl4 format generator | ||
| 3 | * | ||
| 4 | * Copyright (C) 2010 Simon Horman | ||
| 5 | * | ||
| 6 | * This file is subject to the terms and conditions of the GNU General Public | ||
| 7 | * License. See the file "COPYING" in the main directory of this archive | ||
| 8 | * for more details. | ||
| 9 | */ | ||
| 10 | |||
| 11 | /* | ||
| 12 | * usage: vrl4 < zImage > out | ||
| 13 | * dd if=out of=/dev/sdx bs=512 seek=1 # Write the image to sector 1 | ||
| 14 | * | ||
| 15 | * Reads a zImage from stdin and writes a vrl4 image to stdout. | ||
| 16 | * In practice this means writing a padded vrl4 header to stdout followed | ||
| 17 | * by the zImage. | ||
| 18 | * | ||
| 19 | * The padding places the zImage at ALIGN bytes into the output. | ||
| 20 | * The vrl4 uses ALIGN + START_BASE as the start_address. | ||
| 21 | * This is where the mask ROM will jump to after verifying the header. | ||
| 22 | * | ||
| 23 | * The header sets copy_size to min(sizeof(zImage), MAX_BOOT_PROG_LEN) + ALIGN. | ||
| 24 | * That is, the mask ROM will load the padded header (ALIGN bytes) | ||
| 25 | * And then MAX_BOOT_PROG_LEN bytes of the image, or the entire image, | ||
| 26 | * whichever is smaller. | ||
| 27 | * | ||
| 28 | * The zImage is not modified in any way. | ||
| 29 | */ | ||
| 30 | |||
| 31 | #define _BSD_SOURCE | ||
| 32 | #include <endian.h> | ||
| 33 | #include <unistd.h> | ||
| 34 | #include <stdint.h> | ||
| 35 | #include <stdio.h> | ||
| 36 | #include <errno.h> | ||
| 37 | |||
| 38 | struct hdr { | ||
| 39 | uint32_t magic1; | ||
| 40 | uint32_t reserved1; | ||
| 41 | uint32_t magic2; | ||
| 42 | uint32_t reserved2; | ||
| 43 | uint16_t copy_size; | ||
| 44 | uint16_t boot_options; | ||
| 45 | uint32_t reserved3; | ||
| 46 | uint32_t start_address; | ||
| 47 | uint32_t reserved4; | ||
| 48 | uint32_t reserved5; | ||
| 49 | char reserved6[308]; | ||
| 50 | }; | ||
| 51 | |||
| 52 | #define DECLARE_HDR(h) \ | ||
| 53 | struct hdr (h) = { \ | ||
| 54 | .magic1 = htole32(0xea000000), \ | ||
| 55 | .reserved1 = htole32(0x56), \ | ||
| 56 | .magic2 = htole32(0xe59ff008), \ | ||
| 57 | .reserved3 = htole16(0x1) } | ||
| 58 | |||
| 59 | /* Align to 512 bytes, the MMCIF sector size */ | ||
| 60 | #define ALIGN_BITS 9 | ||
| 61 | #define ALIGN (1 << ALIGN_BITS) | ||
| 62 | |||
| 63 | #define START_BASE 0xe55b0000 | ||
| 64 | |||
| 65 | /* | ||
| 66 | * With an alignment of 512 the header uses the first sector. | ||
| 67 | * There is a 128 sector (64kbyte) limit on the data loaded by the mask ROM. | ||
| 68 | * So there are 127 sectors left for the boot programme. But in practice | ||
| 69 | * Only a small portion of a zImage is needed, 16 sectors should be more | ||
| 70 | * than enough. | ||
| 71 | * | ||
| 72 | * Note that this sets how much of the zImage is copied by the mask ROM. | ||
| 73 | * The entire zImage is present after the header and is loaded | ||
| 74 | * by the code in the boot program (which is the first portion of the zImage). | ||
| 75 | */ | ||
| 76 | #define MAX_BOOT_PROG_LEN (16 * 512) | ||
| 77 | |||
| 78 | #define ROUND_UP(x) ((x + ALIGN - 1) & ~(ALIGN - 1)) | ||
| 79 | |||
| 80 | ssize_t do_read(int fd, void *buf, size_t count) | ||
| 81 | { | ||
| 82 | size_t offset = 0; | ||
| 83 | ssize_t l; | ||
| 84 | |||
| 85 | while (offset < count) { | ||
| 86 | l = read(fd, buf + offset, count - offset); | ||
| 87 | if (!l) | ||
| 88 | break; | ||
| 89 | if (l < 0) { | ||
| 90 | if (errno == EAGAIN || errno == EWOULDBLOCK) | ||
| 91 | continue; | ||
| 92 | perror("read"); | ||
| 93 | return -1; | ||
| 94 | } | ||
| 95 | offset += l; | ||
| 96 | } | ||
| 97 | |||
| 98 | return offset; | ||
| 99 | } | ||
| 100 | |||
| 101 | ssize_t do_write(int fd, const void *buf, size_t count) | ||
| 102 | { | ||
| 103 | size_t offset = 0; | ||
| 104 | ssize_t l; | ||
| 105 | |||
| 106 | while (offset < count) { | ||
| 107 | l = write(fd, buf + offset, count - offset); | ||
| 108 | if (l < 0) { | ||
| 109 | if (errno == EAGAIN || errno == EWOULDBLOCK) | ||
| 110 | continue; | ||
| 111 | perror("write"); | ||
| 112 | return -1; | ||
| 113 | } | ||
| 114 | offset += l; | ||
| 115 | } | ||
| 116 | |||
| 117 | return offset; | ||
| 118 | } | ||
| 119 | |||
| 120 | ssize_t write_zero(int fd, size_t len) | ||
| 121 | { | ||
| 122 | size_t i = len; | ||
| 123 | |||
| 124 | while (i--) { | ||
| 125 | const char x = 0; | ||
| 126 | if (do_write(fd, &x, 1) < 0) | ||
| 127 | return -1; | ||
| 128 | } | ||
| 129 | |||
| 130 | return len; | ||
| 131 | } | ||
| 132 | |||
| 133 | int main(void) | ||
| 134 | { | ||
| 135 | DECLARE_HDR(hdr); | ||
| 136 | char boot_program[MAX_BOOT_PROG_LEN]; | ||
| 137 | size_t aligned_hdr_len, alligned_prog_len; | ||
| 138 | ssize_t prog_len; | ||
| 139 | |||
| 140 | prog_len = do_read(0, boot_program, sizeof(boot_program)); | ||
| 141 | if (prog_len <= 0) | ||
| 142 | return -1; | ||
| 143 | |||
| 144 | aligned_hdr_len = ROUND_UP(sizeof(hdr)); | ||
| 145 | hdr.start_address = htole32(START_BASE + aligned_hdr_len); | ||
| 146 | alligned_prog_len = ROUND_UP(prog_len); | ||
| 147 | hdr.copy_size = htole16(aligned_hdr_len + alligned_prog_len); | ||
| 148 | |||
| 149 | if (do_write(1, &hdr, sizeof(hdr)) < 0) | ||
| 150 | return -1; | ||
| 151 | if (write_zero(1, aligned_hdr_len - sizeof(hdr)) < 0) | ||
| 152 | return -1; | ||
| 153 | |||
| 154 | if (do_write(1, boot_program, prog_len) < 0) | ||
| 155 | return 1; | ||
| 156 | |||
| 157 | /* Write out the rest of the kernel */ | ||
| 158 | while (1) { | ||
| 159 | prog_len = do_read(0, boot_program, sizeof(boot_program)); | ||
| 160 | if (prog_len < 0) | ||
| 161 | return 1; | ||
| 162 | if (prog_len == 0) | ||
| 163 | break; | ||
| 164 | if (do_write(1, boot_program, prog_len) < 0) | ||
| 165 | return 1; | ||
| 166 | } | ||
| 167 | |||
| 168 | return 0; | ||
| 169 | } | ||
diff --git a/Documentation/arm/SH-Mobile/zboot-rom-mmcif.txt b/Documentation/arm/SH-Mobile/zboot-rom-mmcif.txt new file mode 100644 index 000000000000..efff8ae2713d --- /dev/null +++ b/Documentation/arm/SH-Mobile/zboot-rom-mmcif.txt | |||
| @@ -0,0 +1,29 @@ | |||
| 1 | ROM-able zImage boot from MMC | ||
| 2 | ----------------------------- | ||
| 3 | |||
| 4 | An ROM-able zImage compiled with ZBOOT_ROM_MMCIF may be written to MMC and | ||
| 5 | SuperH Mobile ARM will to boot directly from the MMCIF hardware block. | ||
| 6 | |||
| 7 | This is achieved by the mask ROM loading the first portion of the image into | ||
| 8 | MERAM and then jumping to it. This portion contains loader code which | ||
| 9 | copies the entire image to SDRAM and jumps to it. From there the zImage | ||
| 10 | boot code proceeds as normal, uncompressing the image into its final | ||
| 11 | location and then jumping to it. | ||
| 12 | |||
| 13 | This code has been tested on an AP4EB board using the developer 1A eMMC | ||
| 14 | boot mode which is configured using the following jumper settings. | ||
| 15 | The board used for testing required a patched mask ROM in order for | ||
| 16 | this mode to function. | ||
| 17 | |||
| 18 | 8 7 6 5 4 3 2 1 | ||
| 19 | x|x|x|x|x| |x| | ||
| 20 | S4 -+-+-+-+-+-+-+- | ||
| 21 | | | | | |x| |x on | ||
| 22 | |||
| 23 | The zImage must be written to the MMC card at sector 1 (512 bytes) in | ||
| 24 | vrl4 format. A utility vrl4 is supplied to accomplish this. | ||
| 25 | |||
| 26 | e.g. | ||
| 27 | vrl4 < zImage | dd of=/dev/sdX bs=512 seek=1 | ||
| 28 | |||
| 29 | A dual-voltage MMC 4.0 card was used for testing. | ||
diff --git a/Documentation/arm/Samsung-S3C24XX/Suspend.txt b/Documentation/arm/Samsung-S3C24XX/Suspend.txt index 7edd0e2e6c5b..1ca63b3e5635 100644 --- a/Documentation/arm/Samsung-S3C24XX/Suspend.txt +++ b/Documentation/arm/Samsung-S3C24XX/Suspend.txt | |||
| @@ -116,7 +116,7 @@ Configuration | |||
| 116 | Allows the entire memory to be checksummed before and after the | 116 | Allows the entire memory to be checksummed before and after the |
| 117 | suspend to see if there has been any corruption of the contents. | 117 | suspend to see if there has been any corruption of the contents. |
| 118 | 118 | ||
| 119 | Note, the time to calculate the CRC is dependant on the CPU speed | 119 | Note, the time to calculate the CRC is dependent on the CPU speed |
| 120 | and the size of memory. For an 64Mbyte RAM area on an 200MHz | 120 | and the size of memory. For an 64Mbyte RAM area on an 200MHz |
| 121 | S3C2410, this can take approximately 4 seconds to complete. | 121 | S3C2410, this can take approximately 4 seconds to complete. |
| 122 | 122 | ||
diff --git a/Documentation/arm/Samsung/GPIO.txt b/Documentation/arm/Samsung/GPIO.txt index 05850c62abeb..513f2562c1a3 100644 --- a/Documentation/arm/Samsung/GPIO.txt +++ b/Documentation/arm/Samsung/GPIO.txt | |||
| @@ -5,7 +5,7 @@ Introduction | |||
| 5 | ------------ | 5 | ------------ |
| 6 | 6 | ||
| 7 | This outlines the Samsung GPIO implementation and the architecture | 7 | This outlines the Samsung GPIO implementation and the architecture |
| 8 | specfic calls provided alongisde the drivers/gpio core. | 8 | specific calls provided alongisde the drivers/gpio core. |
| 9 | 9 | ||
| 10 | 10 | ||
| 11 | S3C24XX (Legacy) | 11 | S3C24XX (Legacy) |
diff --git a/Documentation/arm/Sharp-LH/ADC-LH7-Touchscreen b/Documentation/arm/Sharp-LH/ADC-LH7-Touchscreen deleted file mode 100644 index dc460f055647..000000000000 --- a/Documentation/arm/Sharp-LH/ADC-LH7-Touchscreen +++ /dev/null | |||
| @@ -1,61 +0,0 @@ | |||
| 1 | README on the ADC/Touchscreen Controller | ||
| 2 | ======================================== | ||
| 3 | |||
| 4 | The LH79524 and LH7A404 include a built-in Analog to Digital | ||
| 5 | controller (ADC) that is used to process input from a touchscreen. | ||
| 6 | The driver only implements a four-wire touch panel protocol. | ||
| 7 | |||
| 8 | The touchscreen driver is maintenance free except for the pen-down or | ||
| 9 | touch threshold. Some resistive displays and board combinations may | ||
| 10 | require tuning of this threshold. The driver exposes some of its | ||
| 11 | internal state in the sys filesystem. If the kernel is configured | ||
| 12 | with it, CONFIG_SYSFS, and sysfs is mounted at /sys, there will be a | ||
| 13 | directory | ||
| 14 | |||
| 15 | /sys/devices/platform/adc-lh7.0 | ||
| 16 | |||
| 17 | containing these files. | ||
| 18 | |||
| 19 | -r--r--r-- 1 root root 4096 Jan 1 00:00 samples | ||
| 20 | -rw-r--r-- 1 root root 4096 Jan 1 00:00 threshold | ||
| 21 | -r--r--r-- 1 root root 4096 Jan 1 00:00 threshold_range | ||
| 22 | |||
| 23 | The threshold is the current touch threshold. It defaults to 750 on | ||
| 24 | most targets. | ||
| 25 | |||
| 26 | # cat threshold | ||
| 27 | 750 | ||
| 28 | |||
| 29 | The threshold_range contains the range of valid values for the | ||
| 30 | threshold. Values outside of this range will be silently ignored. | ||
| 31 | |||
| 32 | # cat threshold_range | ||
| 33 | 0 1023 | ||
| 34 | |||
| 35 | To change the threshold, write a value to the threshold file. | ||
| 36 | |||
| 37 | # echo 500 > threshold | ||
| 38 | # cat threshold | ||
| 39 | 500 | ||
| 40 | |||
| 41 | The samples file contains the most recently sampled values from the | ||
| 42 | ADC. There are 12. Below are typical of the last sampled values when | ||
| 43 | the pen has been released. The first two and last two samples are for | ||
| 44 | detecting whether or not the pen is down. The third through sixth are | ||
| 45 | X coordinate samples. The seventh through tenth are Y coordinate | ||
| 46 | samples. | ||
| 47 | |||
| 48 | # cat samples | ||
| 49 | 1023 1023 0 0 0 0 530 529 530 529 1023 1023 | ||
| 50 | |||
| 51 | To determine a reasonable threshold, press on the touch panel with an | ||
| 52 | appropriate stylus and read the values from samples. | ||
| 53 | |||
| 54 | # cat samples | ||
| 55 | 1023 676 92 103 101 102 855 919 922 922 1023 679 | ||
| 56 | |||
| 57 | The first and eleventh samples are discarded. Thus, the important | ||
| 58 | values are the second and twelfth which are used to determine if the | ||
| 59 | pen is down. When both are below the threshold, the driver registers | ||
| 60 | that the pen is down. When either is above the threshold, it | ||
| 61 | registers then pen is up. | ||
diff --git a/Documentation/arm/Sharp-LH/CompactFlash b/Documentation/arm/Sharp-LH/CompactFlash deleted file mode 100644 index 8616d877df9e..000000000000 --- a/Documentation/arm/Sharp-LH/CompactFlash +++ /dev/null | |||
| @@ -1,32 +0,0 @@ | |||
| 1 | README on the Compact Flash for Card Engines | ||
| 2 | ============================================ | ||
| 3 | |||
| 4 | There are three challenges in supporting the CF interface of the Card | ||
| 5 | Engines. First, every IO operation must be followed with IO to | ||
| 6 | another memory region. Second, the slot is wired for one-to-one | ||
| 7 | address mapping *and* it is wired for 16 bit access only. Second, the | ||
| 8 | interrupt request line from the CF device isn't wired. | ||
| 9 | |||
| 10 | The IOBARRIER issue is covered in README.IOBARRIER. This isn't an | ||
| 11 | onerous problem. Enough said here. | ||
| 12 | |||
| 13 | The addressing issue is solved in the | ||
| 14 | arch/arm/mach-lh7a40x/ide-lpd7a40x.c file with some awkward | ||
| 15 | work-arounds. We implement a special SELECT_DRIVE routine that is | ||
| 16 | called before the IDE driver performs its own SELECT_DRIVE. Our code | ||
| 17 | recognizes that the SELECT register cannot be modified without also | ||
| 18 | writing a command. It send an IDLE_IMMEDIATE command on selecting a | ||
| 19 | drive. The function also prevents drive select to the slave drive | ||
| 20 | since there can be only one. The awkward part is that the IDE driver, | ||
| 21 | even though we have a select procedure, also attempts to change the | ||
| 22 | drive by writing directly the SELECT register. This attempt is | ||
| 23 | explicitly blocked by the OUTB function--not pretty, but effective. | ||
| 24 | |||
| 25 | The lack of interrupts is a more serious problem. Even though the CF | ||
| 26 | card is fast when compared to a normal IDE device, we don't know that | ||
| 27 | the CF is really flash. A user could use one of the very small hard | ||
| 28 | drives being shipped with a CF interface. The IDE code includes a | ||
| 29 | check for interfaces that lack an IRQ. In these cases, submitting a | ||
| 30 | command to the IDE controller is followed by a call to poll for | ||
| 31 | completion. If the device isn't immediately ready, it schedules a | ||
| 32 | timer to poll again later. | ||
diff --git a/Documentation/arm/Sharp-LH/IOBarrier b/Documentation/arm/Sharp-LH/IOBarrier deleted file mode 100644 index 2e953e228f4d..000000000000 --- a/Documentation/arm/Sharp-LH/IOBarrier +++ /dev/null | |||
| @@ -1,45 +0,0 @@ | |||
| 1 | README on the IOBARRIER for CardEngine IO | ||
| 2 | ========================================= | ||
| 3 | |||
| 4 | Due to an unfortunate oversight when the Card Engines were designed, | ||
| 5 | the signals that control access to some peripherals, most notably the | ||
| 6 | SMC91C9111 ethernet controller, are not properly handled. | ||
| 7 | |||
| 8 | The symptom is that some back to back IO with the peripheral returns | ||
| 9 | unreliable data. With the SMC chip, you'll see errors about the bank | ||
| 10 | register being 'screwed'. | ||
| 11 | |||
| 12 | The cause is that the AEN signal to the SMC chip does not transition | ||
| 13 | for every memory access. It is driven through the CPLD from the CS7 | ||
| 14 | line of the CPU's static memory controller which is optimized to | ||
| 15 | eliminate unnecessary transitions. Yet, the SMC requires a transition | ||
| 16 | for every write access. The Sharp website has more information about | ||
| 17 | the effect this power-conserving feature has on peripheral | ||
| 18 | interfacing. | ||
| 19 | |||
| 20 | The solution is to follow every write access to the SMC chip with an | ||
| 21 | access to another memory region that will force the CPU to release the | ||
| 22 | chip select line. It is important to guarantee that this access | ||
| 23 | forces the CPU off-chip. We map a page of SDRAM as if it were an | ||
| 24 | uncacheable IO device and read from it after every SMC IO write | ||
| 25 | operation. | ||
| 26 | |||
| 27 | SMC IO | ||
| 28 | BARRIER IO | ||
| 29 | |||
| 30 | Only this sequence is important. It does not matter that there is no | ||
| 31 | BARRIER IO before the access to the SMC chip because the AEN latch | ||
| 32 | only needs occurs after the SMC IO write cycle. The routines that | ||
| 33 | implement this work-around make an additional concession which is to | ||
| 34 | disable interrupts during the IO sequence. Other hardware devices | ||
| 35 | (the LogicPD CPLD) have registers in the same physical memory | ||
| 36 | region as the SMC chip. An interrupt might allow an access to one of | ||
| 37 | those registers while SMC IO is being performed. | ||
| 38 | |||
| 39 | You might be tempted to think that we have to access another device | ||
| 40 | attached to the static memory controller, but the empirical evidence | ||
| 41 | indicates that this is not so. Mapping 0x00000000 (flash) and | ||
| 42 | 0xc0000000 (SDRAM) appear to have the same effect. Using SDRAM seems | ||
| 43 | to be faster. Choosing to access an undecoded memory region is not | ||
| 44 | desirable as there is no way to know how that chip select will be used | ||
| 45 | in the future. | ||
diff --git a/Documentation/arm/Sharp-LH/KEV7A400 b/Documentation/arm/Sharp-LH/KEV7A400 deleted file mode 100644 index be32b14cd535..000000000000 --- a/Documentation/arm/Sharp-LH/KEV7A400 +++ /dev/null | |||
| @@ -1,8 +0,0 @@ | |||
| 1 | README on Implementing Linux for Sharp's KEV7a400 | ||
| 2 | ================================================= | ||
| 3 | |||
| 4 | This product has been discontinued by Sharp. For the time being, the | ||
| 5 | partially implemented code remains in the kernel. At some point in | ||
| 6 | the future, either the code will be finished or it will be removed | ||
| 7 | completely. This depends primarily on how many of the development | ||
| 8 | boards are in the field. | ||
diff --git a/Documentation/arm/Sharp-LH/LCDPanels b/Documentation/arm/Sharp-LH/LCDPanels deleted file mode 100644 index fb1b21c2f2f4..000000000000 --- a/Documentation/arm/Sharp-LH/LCDPanels +++ /dev/null | |||
| @@ -1,59 +0,0 @@ | |||
| 1 | README on the LCD Panels | ||
| 2 | ======================== | ||
| 3 | |||
| 4 | Configuration options for several LCD panels, available from Logic PD, | ||
| 5 | are included in the kernel source. This README will help you | ||
| 6 | understand the configuration data and give you some guidance for | ||
| 7 | adding support for other panels if you wish. | ||
| 8 | |||
| 9 | |||
| 10 | lcd-panels.h | ||
| 11 | ------------ | ||
| 12 | |||
| 13 | There is no way, at present, to detect which panel is attached to the | ||
| 14 | system at runtime. Thus the kernel configuration is static. The file | ||
| 15 | arch/arm/mach-ld7a40x/lcd-panels.h (or similar) defines all of the | ||
| 16 | panel specific parameters. | ||
| 17 | |||
| 18 | It should be possible for this data to be shared among several device | ||
| 19 | families. The current layout may be insufficiently general, but it is | ||
| 20 | amenable to improvement. | ||
| 21 | |||
| 22 | |||
| 23 | PIXEL_CLOCK | ||
| 24 | ----------- | ||
| 25 | |||
| 26 | The panel data sheets will give a range of acceptable pixel clocks. | ||
| 27 | The fundamental LCDCLK input frequency is divided down by a PCD | ||
| 28 | constant in field '.tim2'. It may happen that it is impossible to set | ||
| 29 | the pixel clock within this range. A clock which is too slow will | ||
| 30 | tend to flicker. For the highest quality image, set the clock as high | ||
| 31 | as possible. | ||
| 32 | |||
| 33 | |||
| 34 | MARGINS | ||
| 35 | ------- | ||
| 36 | |||
| 37 | These values may be difficult to glean from the panel data sheet. In | ||
| 38 | the case of the Sharp panels, the upper margin is explicitly called | ||
| 39 | out as a specific number of lines from the top of the frame. The | ||
| 40 | other values may not matter as much as the panels tend to | ||
| 41 | automatically center the image. | ||
| 42 | |||
| 43 | |||
| 44 | Sync Sense | ||
| 45 | ---------- | ||
| 46 | |||
| 47 | The sense of the hsync and vsync pulses may be called out in the data | ||
| 48 | sheet. On one panel, the sense of these pulses determine the height | ||
| 49 | of the visible region on the panel. Most of the Sharp panels use | ||
| 50 | negative sense sync pulses set by the TIM2_IHS and TIM2_IVS bits in | ||
| 51 | '.tim2'. | ||
| 52 | |||
| 53 | |||
| 54 | Pel Layout | ||
| 55 | ---------- | ||
| 56 | |||
| 57 | The Sharp color TFT panels are all configured for 16 bit direct color | ||
| 58 | modes. The amba-lcd driver sets the pel mode to 565 for 5 bits of | ||
| 59 | each red and blue and 6 bits of green. | ||
diff --git a/Documentation/arm/Sharp-LH/LPD7A400 b/Documentation/arm/Sharp-LH/LPD7A400 deleted file mode 100644 index 3275b453bfdf..000000000000 --- a/Documentation/arm/Sharp-LH/LPD7A400 +++ /dev/null | |||
| @@ -1,15 +0,0 @@ | |||
| 1 | README on Implementing Linux for the Logic PD LPD7A400-10 | ||
| 2 | ========================================================= | ||
| 3 | |||
| 4 | - CPLD memory mapping | ||
| 5 | |||
| 6 | The board designers chose to use high address lines for controlling | ||
| 7 | access to the CPLD registers. It turns out to be a big waste | ||
| 8 | because we're using an MMU and must map IO space into virtual | ||
| 9 | memory. The result is that we have to make a mapping for every | ||
| 10 | register. | ||
| 11 | |||
| 12 | - Serial Console | ||
| 13 | |||
| 14 | It may be OK not to use the serial console option if the user passes | ||
| 15 | the console device name to the kernel. This deserves some exploration. | ||
diff --git a/Documentation/arm/Sharp-LH/LPD7A40X b/Documentation/arm/Sharp-LH/LPD7A40X deleted file mode 100644 index 8c29a27e208f..000000000000 --- a/Documentation/arm/Sharp-LH/LPD7A40X +++ /dev/null | |||
| @@ -1,16 +0,0 @@ | |||
| 1 | README on Implementing Linux for the Logic PD LPD7A40X-10 | ||
| 2 | ========================================================= | ||
| 3 | |||
| 4 | - CPLD memory mapping | ||
| 5 | |||
| 6 | The board designers chose to use high address lines for controlling | ||
| 7 | access to the CPLD registers. It turns out to be a big waste | ||
| 8 | because we're using an MMU and must map IO space into virtual | ||
| 9 | memory. The result is that we have to make a mapping for every | ||
| 10 | register. | ||
| 11 | |||
| 12 | - Serial Console | ||
| 13 | |||
| 14 | It may be OK not to use the serial console option if the user passes | ||
| 15 | the console device name to the kernel. This deserves some exploration. | ||
| 16 | |||
diff --git a/Documentation/arm/Sharp-LH/SDRAM b/Documentation/arm/Sharp-LH/SDRAM deleted file mode 100644 index 93ddc23c2faa..000000000000 --- a/Documentation/arm/Sharp-LH/SDRAM +++ /dev/null | |||
| @@ -1,51 +0,0 @@ | |||
| 1 | README on the SDRAM Controller for the LH7a40X | ||
| 2 | ============================================== | ||
| 3 | |||
| 4 | The standard configuration for the SDRAM controller generates a sparse | ||
| 5 | memory array. The precise layout is determined by the SDRAM chips. A | ||
| 6 | default kernel configuration assembles the discontiguous memory | ||
| 7 | regions into separate memory nodes via the NUMA (Non-Uniform Memory | ||
| 8 | Architecture) facilities. In this default configuration, the kernel | ||
| 9 | is forgiving about the precise layout. As long as it is given an | ||
| 10 | accurate picture of available memory by the bootloader the kernel will | ||
| 11 | execute correctly. | ||
| 12 | |||
| 13 | The SDRC supports a mode where some of the chip select lines are | ||
| 14 | swapped in order to make SDRAM look like a synchronous ROM. Setting | ||
| 15 | this bit means that the RAM will present as a contiguous array. Some | ||
| 16 | programmers prefer this to the discontiguous layout. Be aware that | ||
| 17 | may be a penalty for this feature where some some configurations of | ||
| 18 | memory are significantly reduced; i.e. 64MiB of RAM appears as only 32 | ||
| 19 | MiB. | ||
| 20 | |||
| 21 | There are a couple of configuration options to override the default | ||
| 22 | behavior. When the SROMLL bit is set and memory appears as a | ||
| 23 | contiguous array, there is no reason to support NUMA. | ||
| 24 | CONFIG_LH7A40X_CONTIGMEM disables NUMA support. When physical memory | ||
| 25 | is discontiguous, the memory tables are organized such that there are | ||
| 26 | two banks per nodes with a small gap between them. This layout wastes | ||
| 27 | some kernel memory for page tables representing non-existent memory. | ||
| 28 | CONFIG_LH7A40X_ONE_BANK_PER_NODE optimizes the node tables such that | ||
| 29 | there are no gaps. These options control the low level organization | ||
| 30 | of the memory management tables in ways that may prevent the kernel | ||
| 31 | from booting or may cause the kernel to allocated excessively large | ||
| 32 | page tables. Be warned. Only change these options if you know what | ||
| 33 | you are doing. The default behavior is a reasonable compromise that | ||
| 34 | will suit all users. | ||
| 35 | |||
| 36 | -- | ||
| 37 | |||
| 38 | A typical 32MiB system with the default configuration options will | ||
| 39 | find physical memory managed as follows. | ||
| 40 | |||
| 41 | node 0: 0xc0000000 4MiB | ||
| 42 | 0xc1000000 4MiB | ||
| 43 | node 1: 0xc4000000 4MiB | ||
| 44 | 0xc5000000 4MiB | ||
| 45 | node 2: 0xc8000000 4MiB | ||
| 46 | 0xc9000000 4MiB | ||
| 47 | node 3: 0xcc000000 4MiB | ||
| 48 | 0xcd000000 4MiB | ||
| 49 | |||
| 50 | Setting CONFIG_LH7A40X_ONE_BANK_PER_NODE will put each bank into a | ||
| 51 | separate node. | ||
diff --git a/Documentation/arm/Sharp-LH/VectoredInterruptController b/Documentation/arm/Sharp-LH/VectoredInterruptController deleted file mode 100644 index 23047e9861ee..000000000000 --- a/Documentation/arm/Sharp-LH/VectoredInterruptController +++ /dev/null | |||
| @@ -1,80 +0,0 @@ | |||
| 1 | README on the Vectored Interrupt Controller of the LH7A404 | ||
| 2 | ========================================================== | ||
| 3 | |||
| 4 | The 404 revision of the LH7A40X series comes with two vectored | ||
| 5 | interrupts controllers. While the kernel does use some of the | ||
| 6 | features of these devices, it is far from the purpose for which they | ||
| 7 | were designed. | ||
| 8 | |||
| 9 | When this README was written, the implementation of the VICs was in | ||
| 10 | flux. It is possible that some details, especially with priorities, | ||
| 11 | will change. | ||
| 12 | |||
| 13 | The VIC support code is inspired by routines written by Sharp. | ||
| 14 | |||
| 15 | |||
| 16 | Priority Control | ||
| 17 | ---------------- | ||
| 18 | |||
| 19 | The significant reason for using the VIC's vectoring is to control | ||
| 20 | interrupt priorities. There are two tables in | ||
| 21 | arch/arm/mach-lh7a40x/irq-lh7a404.c that look something like this. | ||
| 22 | |||
| 23 | static unsigned char irq_pri_vic1[] = { IRQ_GPIO3INTR, }; | ||
| 24 | static unsigned char irq_pri_vic2[] = { | ||
| 25 | IRQ_T3UI, IRQ_GPIO7INTR, | ||
| 26 | IRQ_UART1INTR, IRQ_UART2INTR, IRQ_UART3INTR, }; | ||
| 27 | |||
| 28 | The initialization code reads these tables and inserts a vector | ||
| 29 | address and enable for each indicated IRQ. Vectored interrupts have | ||
| 30 | higher priority than non-vectored interrupts. So, on VIC1, | ||
| 31 | IRQ_GPIO3INTR will be served before any other non-FIQ interrupt. Due | ||
| 32 | to the way that the vectoring works, IRQ_T3UI is the next highest | ||
| 33 | priority followed by the other vectored interrupts on VIC2. After | ||
| 34 | that, the non-vectored interrupts are scanned in VIC1 then in VIC2. | ||
| 35 | |||
| 36 | |||
| 37 | ISR | ||
| 38 | --- | ||
| 39 | |||
| 40 | The interrupt service routine macro get_irqnr() in | ||
| 41 | arch/arm/kernel/entry-armv.S scans the VICs for the next active | ||
| 42 | interrupt. The vectoring makes this code somewhat larger than it was | ||
| 43 | before using vectoring (refer to the LH7A400 implementation). In the | ||
| 44 | case where an interrupt is vectored, the implementation will tend to | ||
| 45 | be faster than the non-vectored version. However, the worst-case path | ||
| 46 | is longer. | ||
| 47 | |||
| 48 | It is worth noting that at present, there is no need to read | ||
| 49 | VIC2_VECTADDR because the register appears to be shared between the | ||
| 50 | controllers. The code is written such that if this changes, it ought | ||
| 51 | to still work properly. | ||
| 52 | |||
| 53 | |||
| 54 | Vector Addresses | ||
| 55 | ---------------- | ||
| 56 | |||
| 57 | The proper use of the vectoring hardware would jump to the ISR | ||
| 58 | specified by the vectoring address. Linux isn't structured to take | ||
| 59 | advantage of this feature, though it might be possible to change | ||
| 60 | things to support it. | ||
| 61 | |||
| 62 | In this implementation, the vectoring address is used to speed the | ||
| 63 | search for the active IRQ. The address is coded such that the lowest | ||
| 64 | 6 bits store the IRQ number for vectored interrupts. These numbers | ||
| 65 | correspond to the bits in the interrupt status registers. IRQ zero is | ||
| 66 | the lowest interrupt bit in VIC1. IRQ 32 is the lowest interrupt bit | ||
| 67 | in VIC2. Because zero is a valid IRQ number and because we cannot | ||
| 68 | detect whether or not there is a valid vectoring address if that | ||
| 69 | address is zero, the eigth bit (0x100) is set for vectored interrupts. | ||
| 70 | The address for IRQ 0x18 (VIC2) is 0x118. Only the ninth bit is set | ||
| 71 | for the default handler on VIC1 and only the tenth bit is set for the | ||
| 72 | default handler on VIC2. | ||
| 73 | |||
| 74 | In other words. | ||
| 75 | |||
| 76 | 0x000 - no active interrupt | ||
| 77 | 0x1ii - vectored interrupt 0xii | ||
| 78 | 0x2xx - unvectored interrupt on VIC1 (xx is don't care) | ||
| 79 | 0x4xx - unvectored interrupt on VIC2 (xx is don't care) | ||
| 80 | |||
diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt index b9a83dd24732..c6d84cfd2f56 100644 --- a/Documentation/block/biodoc.txt +++ b/Documentation/block/biodoc.txt | |||
| @@ -497,7 +497,7 @@ The scatter gather list is in the form of an array of <page, offset, len> | |||
| 497 | entries with their corresponding dma address mappings filled in at the | 497 | entries with their corresponding dma address mappings filled in at the |
| 498 | appropriate time. As an optimization, contiguous physical pages can be | 498 | appropriate time. As an optimization, contiguous physical pages can be |
| 499 | covered by a single entry where <page> refers to the first page and <len> | 499 | covered by a single entry where <page> refers to the first page and <len> |
| 500 | covers the range of pages (upto 16 contiguous pages could be covered this | 500 | covers the range of pages (up to 16 contiguous pages could be covered this |
| 501 | way). There is a helper routine (blk_rq_map_sg) which drivers can use to build | 501 | way). There is a helper routine (blk_rq_map_sg) which drivers can use to build |
| 502 | the sg list. | 502 | the sg list. |
| 503 | 503 | ||
| @@ -565,7 +565,7 @@ struct request { | |||
| 565 | . | 565 | . |
| 566 | int tag; /* command tag associated with request */ | 566 | int tag; /* command tag associated with request */ |
| 567 | void *special; /* same as before */ | 567 | void *special; /* same as before */ |
| 568 | char *buffer; /* valid only for low memory buffers upto | 568 | char *buffer; /* valid only for low memory buffers up to |
| 569 | current_nr_sectors */ | 569 | current_nr_sectors */ |
| 570 | . | 570 | . |
| 571 | . | 571 | . |
| @@ -963,11 +963,6 @@ elevator_dispatch_fn* fills the dispatch queue with ready requests. | |||
| 963 | 963 | ||
| 964 | elevator_add_req_fn* called to add a new request into the scheduler | 964 | elevator_add_req_fn* called to add a new request into the scheduler |
| 965 | 965 | ||
| 966 | elevator_queue_empty_fn returns true if the merge queue is empty. | ||
| 967 | Drivers shouldn't use this, but rather check | ||
| 968 | if elv_next_request is NULL (without losing the | ||
| 969 | request if one exists!) | ||
| 970 | |||
| 971 | elevator_former_req_fn | 966 | elevator_former_req_fn |
| 972 | elevator_latter_req_fn These return the request before or after the | 967 | elevator_latter_req_fn These return the request before or after the |
| 973 | one specified in disk sort order. Used by the | 968 | one specified in disk sort order. Used by the |
diff --git a/Documentation/cgroups/blkio-controller.txt b/Documentation/cgroups/blkio-controller.txt index 4ed7b5ceeed2..465351d4cf85 100644 --- a/Documentation/cgroups/blkio-controller.txt +++ b/Documentation/cgroups/blkio-controller.txt | |||
| @@ -140,7 +140,7 @@ Proportional weight policy files | |||
| 140 | - Specifies per cgroup weight. This is default weight of the group | 140 | - Specifies per cgroup weight. This is default weight of the group |
| 141 | on all the devices until and unless overridden by per device rule. | 141 | on all the devices until and unless overridden by per device rule. |
| 142 | (See blkio.weight_device). | 142 | (See blkio.weight_device). |
| 143 | Currently allowed range of weights is from 100 to 1000. | 143 | Currently allowed range of weights is from 10 to 1000. |
| 144 | 144 | ||
| 145 | - blkio.weight_device | 145 | - blkio.weight_device |
| 146 | - One can specify per cgroup per device rules using this interface. | 146 | - One can specify per cgroup per device rules using this interface. |
| @@ -343,34 +343,6 @@ Common files among various policies | |||
| 343 | 343 | ||
| 344 | CFQ sysfs tunable | 344 | CFQ sysfs tunable |
| 345 | ================= | 345 | ================= |
| 346 | /sys/block/<disk>/queue/iosched/group_isolation | ||
| 347 | ----------------------------------------------- | ||
| 348 | |||
| 349 | If group_isolation=1, it provides stronger isolation between groups at the | ||
| 350 | expense of throughput. By default group_isolation is 0. In general that | ||
| 351 | means that if group_isolation=0, expect fairness for sequential workload | ||
| 352 | only. Set group_isolation=1 to see fairness for random IO workload also. | ||
| 353 | |||
| 354 | Generally CFQ will put random seeky workload in sync-noidle category. CFQ | ||
| 355 | will disable idling on these queues and it does a collective idling on group | ||
| 356 | of such queues. Generally these are slow moving queues and if there is a | ||
| 357 | sync-noidle service tree in each group, that group gets exclusive access to | ||
| 358 | disk for certain period. That means it will bring the throughput down if | ||
| 359 | group does not have enough IO to drive deeper queue depths and utilize disk | ||
| 360 | capacity to the fullest in the slice allocated to it. But the flip side is | ||
| 361 | that even a random reader should get better latencies and overall throughput | ||
| 362 | if there are lots of sequential readers/sync-idle workload running in the | ||
| 363 | system. | ||
| 364 | |||
| 365 | If group_isolation=0, then CFQ automatically moves all the random seeky queues | ||
| 366 | in the root group. That means there will be no service differentiation for | ||
| 367 | that kind of workload. This leads to better throughput as we do collective | ||
| 368 | idling on root sync-noidle tree. | ||
| 369 | |||
| 370 | By default one should run with group_isolation=0. If that is not sufficient | ||
| 371 | and one wants stronger isolation between groups, then set group_isolation=1 | ||
| 372 | but this will come at cost of reduced throughput. | ||
| 373 | |||
| 374 | /sys/block/<disk>/queue/iosched/slice_idle | 346 | /sys/block/<disk>/queue/iosched/slice_idle |
| 375 | ------------------------------------------ | 347 | ------------------------------------------ |
| 376 | On a faster hardware CFQ can be slow, especially with sequential workload. | 348 | On a faster hardware CFQ can be slow, especially with sequential workload. |
diff --git a/Documentation/cgroups/cgroups.txt b/Documentation/cgroups/cgroups.txt index 44b8b7af8019..aedf1bd02fdd 100644 --- a/Documentation/cgroups/cgroups.txt +++ b/Documentation/cgroups/cgroups.txt | |||
| @@ -110,22 +110,22 @@ university server with various users - students, professors, system | |||
| 110 | tasks etc. The resource planning for this server could be along the | 110 | tasks etc. The resource planning for this server could be along the |
| 111 | following lines: | 111 | following lines: |
| 112 | 112 | ||
| 113 | CPU : Top cpuset | 113 | CPU : "Top cpuset" |
| 114 | / \ | 114 | / \ |
| 115 | CPUSet1 CPUSet2 | 115 | CPUSet1 CPUSet2 |
| 116 | | | | 116 | | | |
| 117 | (Profs) (Students) | 117 | (Professors) (Students) |
| 118 | 118 | ||
| 119 | In addition (system tasks) are attached to topcpuset (so | 119 | In addition (system tasks) are attached to topcpuset (so |
| 120 | that they can run anywhere) with a limit of 20% | 120 | that they can run anywhere) with a limit of 20% |
| 121 | 121 | ||
| 122 | Memory : Professors (50%), students (30%), system (20%) | 122 | Memory : Professors (50%), Students (30%), system (20%) |
| 123 | 123 | ||
| 124 | Disk : Prof (50%), students (30%), system (20%) | 124 | Disk : Professors (50%), Students (30%), system (20%) |
| 125 | 125 | ||
| 126 | Network : WWW browsing (20%), Network File System (60%), others (20%) | 126 | Network : WWW browsing (20%), Network File System (60%), others (20%) |
| 127 | / \ | 127 | / \ |
| 128 | Prof (15%) students (5%) | 128 | Professors (15%) students (5%) |
| 129 | 129 | ||
| 130 | Browsers like Firefox/Lynx go into the WWW network class, while (k)nfsd go | 130 | Browsers like Firefox/Lynx go into the WWW network class, while (k)nfsd go |
| 131 | into NFS network class. | 131 | into NFS network class. |
| @@ -349,6 +349,10 @@ To mount a cgroup hierarchy with all available subsystems, type: | |||
| 349 | The "xxx" is not interpreted by the cgroup code, but will appear in | 349 | The "xxx" is not interpreted by the cgroup code, but will appear in |
| 350 | /proc/mounts so may be any useful identifying string that you like. | 350 | /proc/mounts so may be any useful identifying string that you like. |
| 351 | 351 | ||
| 352 | Note: Some subsystems do not work without some user input first. For instance, | ||
| 353 | if cpusets are enabled the user will have to populate the cpus and mems files | ||
| 354 | for each new cgroup created before that group can be used. | ||
| 355 | |||
| 352 | To mount a cgroup hierarchy with just the cpuset and memory | 356 | To mount a cgroup hierarchy with just the cpuset and memory |
| 353 | subsystems, type: | 357 | subsystems, type: |
| 354 | # mount -t cgroup -o cpuset,memory hier1 /dev/cgroup | 358 | # mount -t cgroup -o cpuset,memory hier1 /dev/cgroup |
| @@ -426,6 +430,14 @@ You can attach the current shell task by echoing 0: | |||
| 426 | 430 | ||
| 427 | # echo 0 > tasks | 431 | # echo 0 > tasks |
| 428 | 432 | ||
| 433 | Note: Since every task is always a member of exactly one cgroup in each | ||
| 434 | mounted hierarchy, to remove a task from its current cgroup you must | ||
| 435 | move it into a new cgroup (possibly the root cgroup) by writing to the | ||
| 436 | new cgroup's tasks file. | ||
| 437 | |||
| 438 | Note: If the ns cgroup is active, moving a process to another cgroup can | ||
| 439 | fail. | ||
| 440 | |||
| 429 | 2.3 Mounting hierarchies by name | 441 | 2.3 Mounting hierarchies by name |
| 430 | -------------------------------- | 442 | -------------------------------- |
| 431 | 443 | ||
diff --git a/Documentation/cgroups/cpusets.txt b/Documentation/cgroups/cpusets.txt index 5d0d5692a365..98a30829af7a 100644 --- a/Documentation/cgroups/cpusets.txt +++ b/Documentation/cgroups/cpusets.txt | |||
| @@ -693,7 +693,7 @@ There are ways to query or modify cpusets: | |||
| 693 | - via the C library libcgroup. | 693 | - via the C library libcgroup. |
| 694 | (http://sourceforge.net/projects/libcg/) | 694 | (http://sourceforge.net/projects/libcg/) |
| 695 | - via the python application cset. | 695 | - via the python application cset. |
| 696 | (http://developer.novell.com/wiki/index.php/Cpuset) | 696 | (http://code.google.com/p/cpuset/) |
| 697 | 697 | ||
| 698 | The sched_setaffinity calls can also be done at the shell prompt using | 698 | The sched_setaffinity calls can also be done at the shell prompt using |
| 699 | SGI's runon or Robert Love's taskset. The mbind and set_mempolicy | 699 | SGI's runon or Robert Love's taskset. The mbind and set_mempolicy |
| @@ -725,13 +725,14 @@ Now you want to do something with this cpuset. | |||
| 725 | 725 | ||
| 726 | In this directory you can find several files: | 726 | In this directory you can find several files: |
| 727 | # ls | 727 | # ls |
| 728 | cpuset.cpu_exclusive cpuset.memory_spread_slab | 728 | cgroup.clone_children cpuset.memory_pressure |
| 729 | cpuset.cpus cpuset.mems | 729 | cgroup.event_control cpuset.memory_spread_page |
| 730 | cpuset.mem_exclusive cpuset.sched_load_balance | 730 | cgroup.procs cpuset.memory_spread_slab |
| 731 | cpuset.mem_hardwall cpuset.sched_relax_domain_level | 731 | cpuset.cpu_exclusive cpuset.mems |
| 732 | cpuset.memory_migrate notify_on_release | 732 | cpuset.cpus cpuset.sched_load_balance |
| 733 | cpuset.memory_pressure tasks | 733 | cpuset.mem_exclusive cpuset.sched_relax_domain_level |
| 734 | cpuset.memory_spread_page | 734 | cpuset.mem_hardwall notify_on_release |
| 735 | cpuset.memory_migrate tasks | ||
| 735 | 736 | ||
| 736 | Reading them will give you information about the state of this cpuset: | 737 | Reading them will give you information about the state of this cpuset: |
| 737 | the CPUs and Memory Nodes it can use, the processes that are using | 738 | the CPUs and Memory Nodes it can use, the processes that are using |
diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt index 7781857dc940..b6ed61c95856 100644 --- a/Documentation/cgroups/memory.txt +++ b/Documentation/cgroups/memory.txt | |||
| @@ -485,8 +485,9 @@ The feature can be disabled by | |||
| 485 | 485 | ||
| 486 | # echo 0 > memory.use_hierarchy | 486 | # echo 0 > memory.use_hierarchy |
| 487 | 487 | ||
| 488 | NOTE1: Enabling/disabling will fail if the cgroup already has other | 488 | NOTE1: Enabling/disabling will fail if either the cgroup already has other |
| 489 | cgroups created below it. | 489 | cgroups created below it, or if the parent cgroup has use_hierarchy |
| 490 | enabled. | ||
| 490 | 491 | ||
| 491 | NOTE2: When panic_on_oom is set to "2", the whole system will panic in | 492 | NOTE2: When panic_on_oom is set to "2", the whole system will panic in |
| 492 | case of an OOM event in any cgroup. | 493 | case of an OOM event in any cgroup. |
diff --git a/Documentation/cpu-freq/governors.txt b/Documentation/cpu-freq/governors.txt index 737988fca64d..e74d0a2eb1cf 100644 --- a/Documentation/cpu-freq/governors.txt +++ b/Documentation/cpu-freq/governors.txt | |||
| @@ -158,6 +158,17 @@ intensive calculation on your laptop that you do not care how long it | |||
| 158 | takes to complete as you can 'nice' it and prevent it from taking part | 158 | takes to complete as you can 'nice' it and prevent it from taking part |
| 159 | in the deciding process of whether to increase your CPU frequency. | 159 | in the deciding process of whether to increase your CPU frequency. |
| 160 | 160 | ||
| 161 | sampling_down_factor: this parameter controls the rate at which the | ||
| 162 | kernel makes a decision on when to decrease the frequency while running | ||
| 163 | at top speed. When set to 1 (the default) decisions to reevaluate load | ||
| 164 | are made at the same interval regardless of current clock speed. But | ||
| 165 | when set to greater than 1 (e.g. 100) it acts as a multiplier for the | ||
| 166 | scheduling interval for reevaluating load when the CPU is at its top | ||
| 167 | speed due to high load. This improves performance by reducing the overhead | ||
| 168 | of load evaluation and helping the CPU stay at its top speed when truly | ||
| 169 | busy, rather than shifting back and forth in speed. This tunable has no | ||
| 170 | effect on behavior at lower speeds/lower CPU loads. | ||
| 171 | |||
| 161 | 172 | ||
| 162 | 2.5 Conservative | 173 | 2.5 Conservative |
| 163 | ---------------- | 174 | ---------------- |
diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt index 45d5a217484f..a20bfd415e41 100644 --- a/Documentation/cpu-hotplug.txt +++ b/Documentation/cpu-hotplug.txt | |||
| @@ -196,7 +196,7 @@ the state as 0 when a cpu if offline and 1 when its online. | |||
| 196 | #To display the current cpu state. | 196 | #To display the current cpu state. |
| 197 | #cat /sys/devices/system/cpu/cpuX/online | 197 | #cat /sys/devices/system/cpu/cpuX/online |
| 198 | 198 | ||
| 199 | Q: Why cant i remove CPU0 on some systems? | 199 | Q: Why can't i remove CPU0 on some systems? |
| 200 | A: Some architectures may have some special dependency on a certain CPU. | 200 | A: Some architectures may have some special dependency on a certain CPU. |
| 201 | 201 | ||
| 202 | For e.g in IA64 platforms we have ability to sent platform interrupts to the | 202 | For e.g in IA64 platforms we have ability to sent platform interrupts to the |
diff --git a/Documentation/dell_rbu.txt b/Documentation/dell_rbu.txt index 15174985ad08..d262e22bddec 100644 --- a/Documentation/dell_rbu.txt +++ b/Documentation/dell_rbu.txt | |||
| @@ -62,7 +62,7 @@ image file and then arrange all these packets back to back in to one single | |||
| 62 | file. | 62 | file. |
| 63 | This file is then copied to /sys/class/firmware/dell_rbu/data. | 63 | This file is then copied to /sys/class/firmware/dell_rbu/data. |
| 64 | Once this file gets to the driver, the driver extracts packet_size data from | 64 | Once this file gets to the driver, the driver extracts packet_size data from |
| 65 | the file and spreads it accross the physical memory in contiguous packet_sized | 65 | the file and spreads it across the physical memory in contiguous packet_sized |
| 66 | space. | 66 | space. |
| 67 | This method makes sure that all the packets get to the driver in a single operation. | 67 | This method makes sure that all the packets get to the driver in a single operation. |
| 68 | 68 | ||
diff --git a/Documentation/development-process/1.Intro b/Documentation/development-process/1.Intro index 8cc2cba2b10d..9b614480aa84 100644 --- a/Documentation/development-process/1.Intro +++ b/Documentation/development-process/1.Intro | |||
| @@ -56,13 +56,13 @@ information on kernel development. | |||
| 56 | 56 | ||
| 57 | 1.2: WHAT THIS DOCUMENT IS ABOUT | 57 | 1.2: WHAT THIS DOCUMENT IS ABOUT |
| 58 | 58 | ||
| 59 | The Linux kernel, at over 6 million lines of code and well over 1000 active | 59 | The Linux kernel, at over 8 million lines of code and well over 1000 |
| 60 | contributors, is one of the largest and most active free software projects | 60 | contributors to each release, is one of the largest and most active free |
| 61 | in existence. Since its humble beginning in 1991, this kernel has evolved | 61 | software projects in existence. Since its humble beginning in 1991, this |
| 62 | into a best-of-breed operating system component which runs on pocket-sized | 62 | kernel has evolved into a best-of-breed operating system component which |
| 63 | digital music players, desktop PCs, the largest supercomputers in | 63 | runs on pocket-sized digital music players, desktop PCs, the largest |
| 64 | existence, and all types of systems in between. It is a robust, efficient, | 64 | supercomputers in existence, and all types of systems in between. It is a |
| 65 | and scalable solution for almost any situation. | 65 | robust, efficient, and scalable solution for almost any situation. |
| 66 | 66 | ||
| 67 | With the growth of Linux has come an increase in the number of developers | 67 | With the growth of Linux has come an increase in the number of developers |
| 68 | (and companies) wishing to participate in its development. Hardware | 68 | (and companies) wishing to participate in its development. Hardware |
| @@ -115,7 +115,7 @@ This document was written by Jonathan Corbet, corbet@lwn.net. It has been | |||
| 115 | improved by comments from Johannes Berg, James Berry, Alex Chiang, Roland | 115 | improved by comments from Johannes Berg, James Berry, Alex Chiang, Roland |
| 116 | Dreier, Randy Dunlap, Jake Edge, Jiri Kosina, Matt Mackall, Arthur Marsh, | 116 | Dreier, Randy Dunlap, Jake Edge, Jiri Kosina, Matt Mackall, Arthur Marsh, |
| 117 | Amanda McPherson, Andrew Morton, Andrew Price, Tsugikazu Shibata, and | 117 | Amanda McPherson, Andrew Morton, Andrew Price, Tsugikazu Shibata, and |
| 118 | Jochen Vo脽. | 118 | Jochen Vo脽. |
| 119 | 119 | ||
| 120 | This work was supported by the Linux Foundation; thanks especially to | 120 | This work was supported by the Linux Foundation; thanks especially to |
| 121 | Amanda McPherson, who saw the value of this effort and made it all happen. | 121 | Amanda McPherson, who saw the value of this effort and made it all happen. |
| @@ -221,7 +221,7 @@ include: | |||
| 221 | - Everything that was said above about code review applies doubly to | 221 | - Everything that was said above about code review applies doubly to |
| 222 | closed-source code. Since this code is not available at all, it cannot | 222 | closed-source code. Since this code is not available at all, it cannot |
| 223 | have been reviewed by the community and will, beyond doubt, have serious | 223 | have been reviewed by the community and will, beyond doubt, have serious |
| 224 | problems. | 224 | problems. |
| 225 | 225 | ||
| 226 | Makers of embedded systems, in particular, may be tempted to disregard much | 226 | Makers of embedded systems, in particular, may be tempted to disregard much |
| 227 | of what has been said in this section in the belief that they are shipping | 227 | of what has been said in this section in the belief that they are shipping |
diff --git a/Documentation/development-process/2.Process b/Documentation/development-process/2.Process index 911a45186340..4823577c6509 100644 --- a/Documentation/development-process/2.Process +++ b/Documentation/development-process/2.Process | |||
| @@ -14,16 +14,15 @@ The kernel developers use a loosely time-based release process, with a new | |||
| 14 | major kernel release happening every two or three months. The recent | 14 | major kernel release happening every two or three months. The recent |
| 15 | release history looks like this: | 15 | release history looks like this: |
| 16 | 16 | ||
| 17 | 2.6.26 July 13, 2008 | 17 | 2.6.38 March 14, 2011 |
| 18 | 2.6.25 April 16, 2008 | 18 | 2.6.37 January 4, 2011 |
| 19 | 2.6.24 January 24, 2008 | 19 | 2.6.36 October 20, 2010 |
| 20 | 2.6.23 October 9, 2007 | 20 | 2.6.35 August 1, 2010 |
| 21 | 2.6.22 July 8, 2007 | 21 | 2.6.34 May 15, 2010 |
| 22 | 2.6.21 April 25, 2007 | 22 | 2.6.33 February 24, 2010 |
| 23 | 2.6.20 February 4, 2007 | ||
| 24 | 23 | ||
| 25 | Every 2.6.x release is a major kernel release with new features, internal | 24 | Every 2.6.x release is a major kernel release with new features, internal |
| 26 | API changes, and more. A typical 2.6 release can contain over 10,000 | 25 | API changes, and more. A typical 2.6 release can contain nearly 10,000 |
| 27 | changesets with changes to several hundred thousand lines of code. 2.6 is | 26 | changesets with changes to several hundred thousand lines of code. 2.6 is |
| 28 | thus the leading edge of Linux kernel development; the kernel uses a | 27 | thus the leading edge of Linux kernel development; the kernel uses a |
| 29 | rolling development model which is continually integrating major changes. | 28 | rolling development model which is continually integrating major changes. |
| @@ -42,13 +41,13 @@ merge window do not come out of thin air; they have been collected, tested, | |||
| 42 | and staged ahead of time. How that process works will be described in | 41 | and staged ahead of time. How that process works will be described in |
| 43 | detail later on). | 42 | detail later on). |
| 44 | 43 | ||
| 45 | The merge window lasts for two weeks. At the end of this time, Linus | 44 | The merge window lasts for approximately two weeks. At the end of this |
| 46 | Torvalds will declare that the window is closed and release the first of | 45 | time, Linus Torvalds will declare that the window is closed and release the |
| 47 | the "rc" kernels. For the kernel which is destined to be 2.6.26, for | 46 | first of the "rc" kernels. For the kernel which is destined to be 2.6.40, |
| 48 | example, the release which happens at the end of the merge window will be | 47 | for example, the release which happens at the end of the merge window will |
| 49 | called 2.6.26-rc1. The -rc1 release is the signal that the time to merge | 48 | be called 2.6.40-rc1. The -rc1 release is the signal that the time to |
| 50 | new features has passed, and that the time to stabilize the next kernel has | 49 | merge new features has passed, and that the time to stabilize the next |
| 51 | begun. | 50 | kernel has begun. |
| 52 | 51 | ||
| 53 | Over the next six to ten weeks, only patches which fix problems should be | 52 | Over the next six to ten weeks, only patches which fix problems should be |
| 54 | submitted to the mainline. On occasion a more significant change will be | 53 | submitted to the mainline. On occasion a more significant change will be |
| @@ -66,20 +65,19 @@ will get up to somewhere between -rc6 and -rc9 before the kernel is | |||
| 66 | considered to be sufficiently stable and the final 2.6.x release is made. | 65 | considered to be sufficiently stable and the final 2.6.x release is made. |
| 67 | At that point the whole process starts over again. | 66 | At that point the whole process starts over again. |
| 68 | 67 | ||
| 69 | As an example, here is how the 2.6.25 development cycle went (all dates in | 68 | As an example, here is how the 2.6.38 development cycle went (all dates in |
| 70 | 2008): | 69 | 2011): |
| 71 | 70 | ||
| 72 | January 24 2.6.24 stable release | 71 | January 4 2.6.37 stable release |
| 73 | February 10 2.6.25-rc1, merge window closes | 72 | January 18 2.6.38-rc1, merge window closes |
| 74 | February 15 2.6.25-rc2 | 73 | January 21 2.6.38-rc2 |
| 75 | February 24 2.6.25-rc3 | 74 | February 1 2.6.38-rc3 |
| 76 | March 4 2.6.25-rc4 | 75 | February 7 2.6.38-rc4 |
| 77 | March 9 2.6.25-rc5 | 76 | February 15 2.6.38-rc5 |
| 78 | March 16 2.6.25-rc6 | 77 | February 21 2.6.38-rc6 |
| 79 | March 25 2.6.25-rc7 | 78 | March 1 2.6.38-rc7 |
| 80 | April 1 2.6.25-rc8 | 79 | March 7 2.6.38-rc8 |
| 81 | April 11 2.6.25-rc9 | 80 | March 14 2.6.38 stable release |
| 82 | April 16 2.6.25 stable release | ||
| 83 | 81 | ||
| 84 | How do the developers decide when to close the development cycle and create | 82 | How do the developers decide when to close the development cycle and create |
| 85 | the stable release? The most significant metric used is the list of | 83 | the stable release? The most significant metric used is the list of |
| @@ -87,7 +85,7 @@ regressions from previous releases. No bugs are welcome, but those which | |||
| 87 | break systems which worked in the past are considered to be especially | 85 | break systems which worked in the past are considered to be especially |
| 88 | serious. For this reason, patches which cause regressions are looked upon | 86 | serious. For this reason, patches which cause regressions are looked upon |
| 89 | unfavorably and are quite likely to be reverted during the stabilization | 87 | unfavorably and are quite likely to be reverted during the stabilization |
| 90 | period. | 88 | period. |
| 91 | 89 | ||
| 92 | The developers' goal is to fix all known regressions before the stable | 90 | The developers' goal is to fix all known regressions before the stable |
| 93 | release is made. In the real world, this kind of perfection is hard to | 91 | release is made. In the real world, this kind of perfection is hard to |
| @@ -99,26 +97,34 @@ kernels go out with a handful of known regressions though, hopefully, none | |||
| 99 | of them are serious. | 97 | of them are serious. |
| 100 | 98 | ||
| 101 | Once a stable release is made, its ongoing maintenance is passed off to the | 99 | Once a stable release is made, its ongoing maintenance is passed off to the |
| 102 | "stable team," currently comprised of Greg Kroah-Hartman and Chris Wright. | 100 | "stable team," currently consisting of Greg Kroah-Hartman. The stable team |
| 103 | The stable team will release occasional updates to the stable release using | 101 | will release occasional updates to the stable release using the 2.6.x.y |
| 104 | the 2.6.x.y numbering scheme. To be considered for an update release, a | 102 | numbering scheme. To be considered for an update release, a patch must (1) |
| 105 | patch must (1) fix a significant bug, and (2) already be merged into the | 103 | fix a significant bug, and (2) already be merged into the mainline for the |
| 106 | mainline for the next development kernel. Continuing our 2.6.25 example, | 104 | next development kernel. Kernels will typically receive stable updates for |
| 107 | the history (as of this writing) is: | 105 | a little more than one development cycle past their initial release. So, |
| 108 | 106 | for example, the 2.6.36 kernel's history looked like: | |
| 109 | May 1 2.6.25.1 | 107 | |
| 110 | May 6 2.6.25.2 | 108 | October 10 2.6.36 stable release |
| 111 | May 9 2.6.25.3 | 109 | November 22 2.6.36.1 |
| 112 | May 15 2.6.25.4 | 110 | December 9 2.6.36.2 |
| 113 | June 7 2.6.25.5 | 111 | January 7 2.6.36.3 |
| 114 | June 9 2.6.25.6 | 112 | February 17 2.6.36.4 |
| 115 | June 16 2.6.25.7 | 113 | |
| 116 | June 21 2.6.25.8 | 114 | 2.6.36.4 was the final stable update for the 2.6.36 release. |
| 117 | June 24 2.6.25.9 | 115 | |
| 118 | 116 | Some kernels are designated "long term" kernels; they will receive support | |
| 119 | Stable updates for a given kernel are made for approximately six months; | 117 | for a longer period. As of this writing, the current long term kernels |
| 120 | after that, the maintenance of stable releases is solely the responsibility | 118 | and their maintainers are: |
| 121 | of the distributors which have shipped that particular kernel. | 119 | |
| 120 | 2.6.27 Willy Tarreau (Deep-frozen stable kernel) | ||
| 121 | 2.6.32 Greg Kroah-Hartman | ||
| 122 | 2.6.35 Andi Kleen (Embedded flag kernel) | ||
| 123 | |||
| 124 | The selection of a kernel for long-term support is purely a matter of a | ||
| 125 | maintainer having the need and the time to maintain that release. There | ||
| 126 | are no known plans for long-term support for any specific upcoming | ||
| 127 | release. | ||
| 122 | 128 | ||
| 123 | 129 | ||
| 124 | 2.2: THE LIFECYCLE OF A PATCH | 130 | 2.2: THE LIFECYCLE OF A PATCH |
| @@ -130,7 +136,7 @@ each patch implements a change which is desirable to have in the mainline. | |||
| 130 | This process can happen quickly for minor fixes, or, in the case of large | 136 | This process can happen quickly for minor fixes, or, in the case of large |
| 131 | and controversial changes, go on for years. Much developer frustration | 137 | and controversial changes, go on for years. Much developer frustration |
| 132 | comes from a lack of understanding of this process or from attempts to | 138 | comes from a lack of understanding of this process or from attempts to |
| 133 | circumvent it. | 139 | circumvent it. |
| 134 | 140 | ||
| 135 | In the hopes of reducing that frustration, this document will describe how | 141 | In the hopes of reducing that frustration, this document will describe how |
| 136 | a patch gets into the kernel. What follows below is an introduction which | 142 | a patch gets into the kernel. What follows below is an introduction which |
| @@ -193,8 +199,8 @@ involved. | |||
| 193 | 2.3: HOW PATCHES GET INTO THE KERNEL | 199 | 2.3: HOW PATCHES GET INTO THE KERNEL |
| 194 | 200 | ||
| 195 | There is exactly one person who can merge patches into the mainline kernel | 201 | There is exactly one person who can merge patches into the mainline kernel |
| 196 | repository: Linus Torvalds. But, of the over 12,000 patches which went | 202 | repository: Linus Torvalds. But, of the over 9,500 patches which went |
| 197 | into the 2.6.25 kernel, only 250 (around 2%) were directly chosen by Linus | 203 | into the 2.6.38 kernel, only 112 (around 1.3%) were directly chosen by Linus |
| 198 | himself. The kernel project has long since grown to a size where no single | 204 | himself. The kernel project has long since grown to a size where no single |
| 199 | developer could possibly inspect and select every patch unassisted. The | 205 | developer could possibly inspect and select every patch unassisted. The |
| 200 | way the kernel developers have addressed this growth is through the use of | 206 | way the kernel developers have addressed this growth is through the use of |
| @@ -229,7 +235,7 @@ first in trees dedicated to network device drivers, wireless networking, | |||
| 229 | etc. This chain of repositories can be arbitrarily long, though it rarely | 235 | etc. This chain of repositories can be arbitrarily long, though it rarely |
| 230 | exceeds two or three links. Since each maintainer in the chain trusts | 236 | exceeds two or three links. Since each maintainer in the chain trusts |
| 231 | those managing lower-level trees, this process is known as the "chain of | 237 | those managing lower-level trees, this process is known as the "chain of |
| 232 | trust." | 238 | trust." |
| 233 | 239 | ||
| 234 | Clearly, in a system like this, getting patches into the kernel depends on | 240 | Clearly, in a system like this, getting patches into the kernel depends on |
| 235 | finding the right maintainer. Sending patches directly to Linus is not | 241 | finding the right maintainer. Sending patches directly to Linus is not |
| @@ -254,7 +260,7 @@ The answer comes in the form of -next trees, where subsystem trees are | |||
| 254 | collected for testing and review. The older of these trees, maintained by | 260 | collected for testing and review. The older of these trees, maintained by |
| 255 | Andrew Morton, is called "-mm" (for memory management, which is how it got | 261 | Andrew Morton, is called "-mm" (for memory management, which is how it got |
| 256 | started). The -mm tree integrates patches from a long list of subsystem | 262 | started). The -mm tree integrates patches from a long list of subsystem |
| 257 | trees; it also has some patches aimed at helping with debugging. | 263 | trees; it also has some patches aimed at helping with debugging. |
| 258 | 264 | ||
| 259 | Beyond that, -mm contains a significant collection of patches which have | 265 | Beyond that, -mm contains a significant collection of patches which have |
| 260 | been selected by Andrew directly. These patches may have been posted on a | 266 | been selected by Andrew directly. These patches may have been posted on a |
| @@ -264,8 +270,8 @@ subsystem tree of last resort; if there is no other obvious path for a | |||
| 264 | patch into the mainline, it is likely to end up in -mm. Miscellaneous | 270 | patch into the mainline, it is likely to end up in -mm. Miscellaneous |
| 265 | patches which accumulate in -mm will eventually either be forwarded on to | 271 | patches which accumulate in -mm will eventually either be forwarded on to |
| 266 | an appropriate subsystem tree or be sent directly to Linus. In a typical | 272 | an appropriate subsystem tree or be sent directly to Linus. In a typical |
| 267 | development cycle, approximately 10% of the patches going into the mainline | 273 | development cycle, approximately 5-10% of the patches going into the |
| 268 | get there via -mm. | 274 | mainline get there via -mm. |
| 269 | 275 | ||
| 270 | The current -mm patch is available in the "mmotm" (-mm of the moment) | 276 | The current -mm patch is available in the "mmotm" (-mm of the moment) |
| 271 | directory at: | 277 | directory at: |
| @@ -275,7 +281,7 @@ directory at: | |||
| 275 | Use of the MMOTM tree is likely to be a frustrating experience, though; | 281 | Use of the MMOTM tree is likely to be a frustrating experience, though; |
| 276 | there is a definite chance that it will not even compile. | 282 | there is a definite chance that it will not even compile. |
| 277 | 283 | ||
| 278 | The other -next tree, started more recently, is linux-next, maintained by | 284 | The primary tree for next-cycle patch merging is linux-next, maintained by |
| 279 | Stephen Rothwell. The linux-next tree is, by design, a snapshot of what | 285 | Stephen Rothwell. The linux-next tree is, by design, a snapshot of what |
| 280 | the mainline is expected to look like after the next merge window closes. | 286 | the mainline is expected to look like after the next merge window closes. |
| 281 | Linux-next trees are announced on the linux-kernel and linux-next mailing | 287 | Linux-next trees are announced on the linux-kernel and linux-next mailing |
| @@ -287,25 +293,14 @@ Some information about linux-next has been gathered at: | |||
| 287 | 293 | ||
| 288 | http://linux.f-seidel.de/linux-next/pmwiki/ | 294 | http://linux.f-seidel.de/linux-next/pmwiki/ |
| 289 | 295 | ||
| 290 | How the linux-next tree will fit into the development process is still | 296 | Linux-next has become an integral part of the kernel development process; |
| 291 | changing. As of this writing, the first full development cycle involving | 297 | all patches merged during a given merge window should really have found |
| 292 | linux-next (2.6.26) is coming to an end; thus far, it has proved to be a | 298 | their way into linux-next some time before the merge window opens. |
| 293 | valuable resource for finding and fixing integration problems before the | 299 | |
| 294 | beginning of the merge window. See http://lwn.net/Articles/287155/ for | ||
| 295 | more information on how linux-next has worked to set up the 2.6.27 merge | ||
| 296 | window. | ||
| 297 | |||
| 298 | Some developers have begun to suggest that linux-next should be used as the | ||
| 299 | target for future development as well. The linux-next tree does tend to be | ||
| 300 | far ahead of the mainline and is more representative of the tree into which | ||
| 301 | any new work will be merged. The downside to this idea is that the | ||
| 302 | volatility of linux-next tends to make it a difficult development target. | ||
| 303 | See http://lwn.net/Articles/289013/ for more information on this topic, and | ||
| 304 | stay tuned; much is still in flux where linux-next is involved. | ||
| 305 | 300 | ||
| 306 | 2.4.1: STAGING TREES | 301 | 2.4.1: STAGING TREES |
| 307 | 302 | ||
| 308 | The kernel source tree now contains the drivers/staging/ directory, where | 303 | The kernel source tree contains the drivers/staging/ directory, where |
| 309 | many sub-directories for drivers or filesystems that are on their way to | 304 | many sub-directories for drivers or filesystems that are on their way to |
| 310 | being added to the kernel tree live. They remain in drivers/staging while | 305 | being added to the kernel tree live. They remain in drivers/staging while |
| 311 | they still need more work; once complete, they can be moved into the | 306 | they still need more work; once complete, they can be moved into the |
| @@ -313,15 +308,23 @@ kernel proper. This is a way to keep track of drivers that aren't | |||
| 313 | up to Linux kernel coding or quality standards, but people may want to use | 308 | up to Linux kernel coding or quality standards, but people may want to use |
| 314 | them and track development. | 309 | them and track development. |
| 315 | 310 | ||
| 316 | Greg Kroah-Hartman currently (as of 2.6.36) maintains the staging tree. | 311 | Greg Kroah-Hartman currently maintains the staging tree. Drivers that |
| 317 | Drivers that still need work are sent to him, with each driver having | 312 | still need work are sent to him, with each driver having its own |
| 318 | its own subdirectory in drivers/staging/. Along with the driver source | 313 | subdirectory in drivers/staging/. Along with the driver source files, a |
| 319 | files, a TODO file should be present in the directory as well. The TODO | 314 | TODO file should be present in the directory as well. The TODO file lists |
| 320 | file lists the pending work that the driver needs for acceptance into | 315 | the pending work that the driver needs for acceptance into the kernel |
| 321 | the kernel proper, as well as a list of people that should be Cc'd for any | 316 | proper, as well as a list of people that should be Cc'd for any patches to |
| 322 | patches to the driver. Staging drivers that don't currently build should | 317 | the driver. Current rules require that drivers contributed to staging |
| 323 | have their config entries depend upon CONFIG_BROKEN. Once they can | 318 | must, at a minimum, compile properly. |
| 324 | be successfully built without outside patches, CONFIG_BROKEN can be removed. | 319 | |
| 320 | Staging can be a relatively easy way to get new drivers into the mainline | ||
| 321 | where, with luck, they will come to the attention of other developers and | ||
| 322 | improve quickly. Entry into staging is not the end of the story, though; | ||
| 323 | code in staging which is not seeing regular progress will eventually be | ||
| 324 | removed. Distributors also tend to be relatively reluctant to enable | ||
| 325 | staging drivers. So staging is, at best, a stop on the way toward becoming | ||
| 326 | a proper mainline driver. | ||
| 327 | |||
| 325 | 328 | ||
| 326 | 2.5: TOOLS | 329 | 2.5: TOOLS |
| 327 | 330 | ||
| @@ -347,11 +350,7 @@ page at: | |||
| 347 | 350 | ||
| 348 | http://git-scm.com/ | 351 | http://git-scm.com/ |
| 349 | 352 | ||
| 350 | That page has pointers to documentation and tutorials. One should be | 353 | That page has pointers to documentation and tutorials. |
| 351 | aware, in particular, of the Kernel Hacker's Guide to git, which has | ||
| 352 | information specific to kernel development: | ||
| 353 | |||
| 354 | http://linux.yyz.us/git-howto.html | ||
| 355 | 354 | ||
| 356 | Among the kernel developers who do not use git, the most popular choice is | 355 | Among the kernel developers who do not use git, the most popular choice is |
| 357 | almost certainly Mercurial: | 356 | almost certainly Mercurial: |
| @@ -408,7 +407,7 @@ There are a few hints which can help with linux-kernel survival: | |||
| 408 | important to filter on both the topic of interest (though note that | 407 | important to filter on both the topic of interest (though note that |
| 409 | long-running conversations can drift away from the original subject | 408 | long-running conversations can drift away from the original subject |
| 410 | without changing the email subject line) and the people who are | 409 | without changing the email subject line) and the people who are |
| 411 | participating. | 410 | participating. |
| 412 | 411 | ||
| 413 | - Do not feed the trolls. If somebody is trying to stir up an angry | 412 | - Do not feed the trolls. If somebody is trying to stir up an angry |
| 414 | response, ignore them. | 413 | response, ignore them. |
diff --git a/Documentation/development-process/3.Early-stage b/Documentation/development-process/3.Early-stage index 307a159a70ca..f87ba7b3fbac 100644 --- a/Documentation/development-process/3.Early-stage +++ b/Documentation/development-process/3.Early-stage | |||
| @@ -110,8 +110,8 @@ the kernel community's standards. Some examples include: | |||
| 110 | 110 | ||
| 111 | - The AppArmor security module made use of internal virtual filesystem | 111 | - The AppArmor security module made use of internal virtual filesystem |
| 112 | data structures in ways which were considered to be unsafe and | 112 | data structures in ways which were considered to be unsafe and |
| 113 | unreliable. This code has since been significantly reworked, but | 113 | unreliable. This concern (among others) kept AppArmor out of the |
| 114 | remains outside of the mainline. | 114 | mainline for years. |
| 115 | 115 | ||
| 116 | In each of these cases, a great deal of pain and extra work could have been | 116 | In each of these cases, a great deal of pain and extra work could have been |
| 117 | avoided with some early discussion with the kernel developers. | 117 | avoided with some early discussion with the kernel developers. |
| @@ -138,6 +138,19 @@ patches, and who, if anybody, is attaching Signed-off-by lines to those | |||
| 138 | patches. Those are the people who will be best placed to help with a new | 138 | patches. Those are the people who will be best placed to help with a new |
| 139 | development project. | 139 | development project. |
| 140 | 140 | ||
| 141 | The task of finding the right maintainer is sometimes challenging enough | ||
| 142 | that the kernel developers have added a script to ease the process: | ||
| 143 | |||
| 144 | .../scripts/get_maintainer.pl | ||
| 145 | |||
| 146 | This script will return the current maintainer(s) for a given file or | ||
| 147 | directory when given the "-f" option. If passed a patch on the | ||
| 148 | command line, it will list the maintainers who should probably receive | ||
| 149 | copies of the patch. There are a number of options regulating how hard | ||
| 150 | get_maintainer.pl will search for maintainers; please be careful about | ||
| 151 | using the more aggressive options as you may end up including developers | ||
| 152 | who have no real interest in the code you are modifying. | ||
| 153 | |||
| 141 | If all else fails, talking to Andrew Morton can be an effective way to | 154 | If all else fails, talking to Andrew Morton can be an effective way to |
| 142 | track down a maintainer for a specific piece of code. | 155 | track down a maintainer for a specific piece of code. |
| 143 | 156 | ||
| @@ -155,11 +168,15 @@ reaction, but, instead, little or no reaction at all. The sad truth of the | |||
| 155 | matter is (1) kernel developers tend to be busy, (2) there is no shortage | 168 | matter is (1) kernel developers tend to be busy, (2) there is no shortage |
| 156 | of people with grand plans and little code (or even prospect of code) to | 169 | of people with grand plans and little code (or even prospect of code) to |
| 157 | back them up, and (3) nobody is obligated to review or comment on ideas | 170 | back them up, and (3) nobody is obligated to review or comment on ideas |
| 158 | posted by others. If a request-for-comments posting yields little in the | 171 | posted by others. Beyond that, high-level designs often hide problems |
| 159 | way of comments, do not assume that it means there is no interest in the | 172 | which are only reviewed when somebody actually tries to implement those |
| 160 | project. Unfortunately, you also cannot assume that there are no problems | 173 | designs; for that reason, kernel developers would rather see the code. |
| 161 | with your idea. The best thing to do in this situation is to proceed, | 174 | |
| 162 | keeping the community informed as you go. | 175 | If a request-for-comments posting yields little in the way of comments, do |
| 176 | not assume that it means there is no interest in the project. | ||
| 177 | Unfortunately, you also cannot assume that there are no problems with your | ||
| 178 | idea. The best thing to do in this situation is to proceed, keeping the | ||
| 179 | community informed as you go. | ||
| 163 | 180 | ||
| 164 | 181 | ||
| 165 | 3.5: GETTING OFFICIAL BUY-IN | 182 | 3.5: GETTING OFFICIAL BUY-IN |
diff --git a/Documentation/development-process/4.Coding b/Documentation/development-process/4.Coding index 2278693c8ffa..f3f1a469443c 100644 --- a/Documentation/development-process/4.Coding +++ b/Documentation/development-process/4.Coding | |||
| @@ -131,6 +131,11 @@ classic time/space tradeoff taught in beginning data structures classes | |||
| 131 | often does not apply to contemporary hardware. Space *is* time, in that a | 131 | often does not apply to contemporary hardware. Space *is* time, in that a |
| 132 | larger program will run slower than one which is more compact. | 132 | larger program will run slower than one which is more compact. |
| 133 | 133 | ||
| 134 | More recent compilers take an increasingly active role in deciding whether | ||
| 135 | a given function should actually be inlined or not. So the liberal | ||
| 136 | placement of "inline" keywords may not just be excessive; it could also be | ||
| 137 | irrelevant. | ||
| 138 | |||
| 134 | 139 | ||
| 135 | * Locking | 140 | * Locking |
| 136 | 141 | ||
| @@ -285,6 +290,13 @@ be found at https://sparse.wiki.kernel.org/index.php/Main_Page if your | |||
| 285 | distributor does not package it); it can then be run on the code by adding | 290 | distributor does not package it); it can then be run on the code by adding |
| 286 | "C=1" to your make command. | 291 | "C=1" to your make command. |
| 287 | 292 | ||
| 293 | The "Coccinelle" tool (http://coccinelle.lip6.fr/) is able to find a wide | ||
| 294 | variety of potential coding problems; it can also propose fixes for those | ||
| 295 | problems. Quite a few "semantic patches" for the kernel have been packaged | ||
| 296 | under the scripts/coccinelle directory; running "make coccicheck" will run | ||
| 297 | through those semantic patches and report on any problems found. See | ||
| 298 | Documentation/coccinelle.txt for more information. | ||
| 299 | |||
| 288 | Other kinds of portability errors are best found by compiling your code for | 300 | Other kinds of portability errors are best found by compiling your code for |
| 289 | other architectures. If you do not happen to have an S/390 system or a | 301 | other architectures. If you do not happen to have an S/390 system or a |
| 290 | Blackfin development board handy, you can still perform the compilation | 302 | Blackfin development board handy, you can still perform the compilation |
| @@ -308,7 +320,9 @@ The first piece of documentation for any patch is its associated | |||
| 308 | changelog. Log entries should describe the problem being solved, the form | 320 | changelog. Log entries should describe the problem being solved, the form |
| 309 | of the solution, the people who worked on the patch, any relevant | 321 | of the solution, the people who worked on the patch, any relevant |
| 310 | effects on performance, and anything else that might be needed to | 322 | effects on performance, and anything else that might be needed to |
| 311 | understand the patch. | 323 | understand the patch. Be sure that the changelog says *why* the patch is |
| 324 | worth applying; a surprising number of developers fail to provide that | ||
| 325 | information. | ||
| 312 | 326 | ||
| 313 | Any code which adds a new user-space interface - including new sysfs or | 327 | Any code which adds a new user-space interface - including new sysfs or |
| 314 | /proc files - should include documentation of that interface which enables | 328 | /proc files - should include documentation of that interface which enables |
| @@ -321,7 +335,7 @@ boot-time parameters. Any patch which adds new parameters should add the | |||
| 321 | appropriate entries to this file. | 335 | appropriate entries to this file. |
| 322 | 336 | ||
| 323 | Any new configuration options must be accompanied by help text which | 337 | Any new configuration options must be accompanied by help text which |
| 324 | clearly explains the options and when the user might want to select them. | 338 | clearly explains the options and when the user might want to select them. |
| 325 | 339 | ||
| 326 | Internal API information for many subsystems is documented by way of | 340 | Internal API information for many subsystems is documented by way of |
| 327 | specially-formatted comments; these comments can be extracted and formatted | 341 | specially-formatted comments; these comments can be extracted and formatted |
| @@ -372,7 +386,8 @@ which is broken by the change. For a widely-used function, this duty can | |||
| 372 | lead to literally hundreds or thousands of changes - many of which are | 386 | lead to literally hundreds or thousands of changes - many of which are |
| 373 | likely to conflict with work being done by other developers. Needless to | 387 | likely to conflict with work being done by other developers. Needless to |
| 374 | say, this can be a large job, so it is best to be sure that the | 388 | say, this can be a large job, so it is best to be sure that the |
| 375 | justification is solid. | 389 | justification is solid. Note that the Coccinelle tool can help with |
| 390 | wide-ranging API changes. | ||
| 376 | 391 | ||
| 377 | When making an incompatible API change, one should, whenever possible, | 392 | When making an incompatible API change, one should, whenever possible, |
| 378 | ensure that code which has not been updated is caught by the compiler. | 393 | ensure that code which has not been updated is caught by the compiler. |
diff --git a/Documentation/development-process/5.Posting b/Documentation/development-process/5.Posting index f622c1e9f0f9..903a2546f138 100644 --- a/Documentation/development-process/5.Posting +++ b/Documentation/development-process/5.Posting | |||
| @@ -60,12 +60,15 @@ even in the short term. | |||
| 60 | 60 | ||
| 61 | Patches must be prepared against a specific version of the kernel. As a | 61 | Patches must be prepared against a specific version of the kernel. As a |
| 62 | general rule, a patch should be based on the current mainline as found in | 62 | general rule, a patch should be based on the current mainline as found in |
| 63 | Linus's git tree. It may become necessary to make versions against -mm, | 63 | Linus's git tree. When basing on mainline, start with a well-known release |
| 64 | linux-next, or a subsystem tree, though, to facilitate wider testing and | 64 | point - a stable or -rc release - rather than branching off the mainline at |
| 65 | review. Depending on the area of your patch and what is going on | 65 | an arbitrary spot. |
| 66 | elsewhere, basing a patch against these other trees can require a | 66 | |
| 67 | significant amount of work resolving conflicts and dealing with API | 67 | It may become necessary to make versions against -mm, linux-next, or a |
| 68 | changes. | 68 | subsystem tree, though, to facilitate wider testing and review. Depending |
| 69 | on the area of your patch and what is going on elsewhere, basing a patch | ||
| 70 | against these other trees can require a significant amount of work | ||
| 71 | resolving conflicts and dealing with API changes. | ||
| 69 | 72 | ||
| 70 | Only the most simple changes should be formatted as a single patch; | 73 | Only the most simple changes should be formatted as a single patch; |
| 71 | everything else should be made as a logical series of changes. Splitting | 74 | everything else should be made as a logical series of changes. Splitting |
| @@ -100,11 +103,11 @@ rules of thumb, however, which can help considerably: | |||
| 100 | result is a broken kernel, you will make life harder for developers and | 103 | result is a broken kernel, you will make life harder for developers and |
| 101 | users who are engaging in the noble work of tracking down problems. | 104 | users who are engaging in the noble work of tracking down problems. |
| 102 | 105 | ||
| 103 | - Do not overdo it, though. One developer recently posted a set of edits | 106 | - Do not overdo it, though. One developer once posted a set of edits |
| 104 | to a single file as 500 separate patches - an act which did not make him | 107 | to a single file as 500 separate patches - an act which did not make him |
| 105 | the most popular person on the kernel mailing list. A single patch can | 108 | the most popular person on the kernel mailing list. A single patch can |
| 106 | be reasonably large as long as it still contains a single *logical* | 109 | be reasonably large as long as it still contains a single *logical* |
| 107 | change. | 110 | change. |
| 108 | 111 | ||
| 109 | - It can be tempting to add a whole new infrastructure with a series of | 112 | - It can be tempting to add a whole new infrastructure with a series of |
| 110 | patches, but to leave that infrastructure unused until the final patch | 113 | patches, but to leave that infrastructure unused until the final patch |
| @@ -162,7 +165,8 @@ To that end, the summary line should describe the effects of and motivation | |||
| 162 | for the change as well as possible given the one-line constraint. The | 165 | for the change as well as possible given the one-line constraint. The |
| 163 | detailed description can then amplify on those topics and provide any | 166 | detailed description can then amplify on those topics and provide any |
| 164 | needed additional information. If the patch fixes a bug, cite the commit | 167 | needed additional information. If the patch fixes a bug, cite the commit |
| 165 | which introduced the bug if possible. If a problem is associated with | 168 | which introduced the bug if possible (and please provide both the commit ID |
| 169 | and the title when citing commits). If a problem is associated with | ||
| 166 | specific log or compiler output, include that output to help others | 170 | specific log or compiler output, include that output to help others |
| 167 | searching for a solution to the same problem. If the change is meant to | 171 | searching for a solution to the same problem. If the change is meant to |
| 168 | support other changes coming in later patch, say so. If internal APIs are | 172 | support other changes coming in later patch, say so. If internal APIs are |
| @@ -230,7 +234,7 @@ take care of: | |||
| 230 | which have had gratuitous white-space changes or line wrapping performed | 234 | which have had gratuitous white-space changes or line wrapping performed |
| 231 | by the mail client will not apply at the other end, and often will not | 235 | by the mail client will not apply at the other end, and often will not |
| 232 | be examined in any detail. If there is any doubt at all, mail the patch | 236 | be examined in any detail. If there is any doubt at all, mail the patch |
| 233 | to yourself and convince yourself that it shows up intact. | 237 | to yourself and convince yourself that it shows up intact. |
| 234 | 238 | ||
| 235 | Documentation/email-clients.txt has some helpful hints on making | 239 | Documentation/email-clients.txt has some helpful hints on making |
| 236 | specific mail clients work for sending patches. | 240 | specific mail clients work for sending patches. |
| @@ -287,7 +291,7 @@ something like: | |||
| 287 | 291 | ||
| 288 | where "nn" is the ordinal number of the patch, "mm" is the total number of | 292 | where "nn" is the ordinal number of the patch, "mm" is the total number of |
| 289 | patches in the series, and "subsys" is the name of the affected subsystem. | 293 | patches in the series, and "subsys" is the name of the affected subsystem. |
| 290 | Clearly, nn/mm can be omitted for a single, standalone patch. | 294 | Clearly, nn/mm can be omitted for a single, standalone patch. |
| 291 | 295 | ||
| 292 | If you have a significant series of patches, it is customary to send an | 296 | If you have a significant series of patches, it is customary to send an |
| 293 | introductory description as part zero. This convention is not universally | 297 | introductory description as part zero. This convention is not universally |
| @@ -299,5 +303,5 @@ In general, the second and following parts of a multi-part patch should be | |||
| 299 | sent as a reply to the first part so that they all thread together at the | 303 | sent as a reply to the first part so that they all thread together at the |
| 300 | receiving end. Tools like git and quilt have commands to mail out a set of | 304 | receiving end. Tools like git and quilt have commands to mail out a set of |
| 301 | patches with the proper threading. If you have a long series, though, and | 305 | patches with the proper threading. If you have a long series, though, and |
| 302 | are using git, please provide the --no-chain-reply-to option to avoid | 306 | are using git, please stay away from the --chain-reply-to option to avoid |
| 303 | creating exceptionally deep nesting. | 307 | creating exceptionally deep nesting. |
diff --git a/Documentation/development-process/6.Followthrough b/Documentation/development-process/6.Followthrough index a8fba3d83a85..41d324a9420d 100644 --- a/Documentation/development-process/6.Followthrough +++ b/Documentation/development-process/6.Followthrough | |||
| @@ -66,6 +66,11 @@ be easy to become blinded by your own solution to a problem to the point | |||
| 66 | that you don't realize that something is fundamentally wrong or, perhaps, | 66 | that you don't realize that something is fundamentally wrong or, perhaps, |
| 67 | you're not even solving the right problem. | 67 | you're not even solving the right problem. |
| 68 | 68 | ||
| 69 | Andrew Morton has suggested that every review comment which does not result | ||
| 70 | in a code change should result in an additional code comment instead; that | ||
| 71 | can help future reviewers avoid the questions which came up the first time | ||
| 72 | around. | ||
| 73 | |||
| 69 | One fatal mistake is to ignore review comments in the hope that they will | 74 | One fatal mistake is to ignore review comments in the hope that they will |
| 70 | go away. They will not go away. If you repost code without having | 75 | go away. They will not go away. If you repost code without having |
| 71 | responded to the comments you got the time before, you're likely to find | 76 | responded to the comments you got the time before, you're likely to find |
| @@ -100,7 +105,7 @@ entry into a subsystem maintainer's tree. How that works varies from one | |||
| 100 | subsystem to the next; each maintainer has his or her own way of doing | 105 | subsystem to the next; each maintainer has his or her own way of doing |
| 101 | things. In particular, there may be more than one tree - one, perhaps, | 106 | things. In particular, there may be more than one tree - one, perhaps, |
| 102 | dedicated to patches planned for the next merge window, and another for | 107 | dedicated to patches planned for the next merge window, and another for |
| 103 | longer-term work. | 108 | longer-term work. |
| 104 | 109 | ||
| 105 | For patches applying to areas for which there is no obvious subsystem tree | 110 | For patches applying to areas for which there is no obvious subsystem tree |
| 106 | (memory management patches, for example), the default tree often ends up | 111 | (memory management patches, for example), the default tree often ends up |
| @@ -109,11 +114,10 @@ through the -mm tree. | |||
| 109 | 114 | ||
| 110 | Inclusion into a subsystem tree can bring a higher level of visibility to a | 115 | Inclusion into a subsystem tree can bring a higher level of visibility to a |
| 111 | patch. Now other developers working with that tree will get the patch by | 116 | patch. Now other developers working with that tree will get the patch by |
| 112 | default. Subsystem trees typically feed into -mm and linux-next as well, | 117 | default. Subsystem trees typically feed linux-next as well, making their |
| 113 | making their contents visible to the development community as a whole. At | 118 | contents visible to the development community as a whole. At this point, |
| 114 | this point, there's a good chance that you will get more comments from a | 119 | there's a good chance that you will get more comments from a new set of |
| 115 | new set of reviewers; these comments need to be answered as in the previous | 120 | reviewers; these comments need to be answered as in the previous round. |
| 116 | round. | ||
| 117 | 121 | ||
| 118 | What may also happen at this point, depending on the nature of your patch, | 122 | What may also happen at this point, depending on the nature of your patch, |
| 119 | is that conflicts with work being done by others turn up. In the worst | 123 | is that conflicts with work being done by others turn up. In the worst |
diff --git a/Documentation/development-process/7.AdvancedTopics b/Documentation/development-process/7.AdvancedTopics index 837179447e17..26dc3fa196e4 100644 --- a/Documentation/development-process/7.AdvancedTopics +++ b/Documentation/development-process/7.AdvancedTopics | |||
| @@ -119,7 +119,7 @@ can affect your ability to get trees pulled in the future. Quoting Linus: | |||
| 119 | to trust things *without* then having to go and check every | 119 | to trust things *without* then having to go and check every |
| 120 | individual change by hand. | 120 | individual change by hand. |
| 121 | 121 | ||
| 122 | (http://lwn.net/Articles/224135/). | 122 | (http://lwn.net/Articles/224135/). |
| 123 | 123 | ||
| 124 | To avoid this kind of situation, ensure that all patches within a given | 124 | To avoid this kind of situation, ensure that all patches within a given |
| 125 | branch stick closely to the associated topic; a "driver fixes" branch | 125 | branch stick closely to the associated topic; a "driver fixes" branch |
| @@ -138,7 +138,7 @@ When requesting a pull, be sure to give all the relevant information: where | |||
| 138 | your tree is, what branch to pull, and what changes will result from the | 138 | your tree is, what branch to pull, and what changes will result from the |
| 139 | pull. The git request-pull command can be helpful in this regard; it will | 139 | pull. The git request-pull command can be helpful in this regard; it will |
| 140 | format the request as other developers expect, and will also check to be | 140 | format the request as other developers expect, and will also check to be |
| 141 | sure that you have remembered to push those changes to the public server. | 141 | sure that you have remembered to push those changes to the public server. |
| 142 | 142 | ||
| 143 | 143 | ||
| 144 | 7.2: REVIEWING PATCHES | 144 | 7.2: REVIEWING PATCHES |
diff --git a/Documentation/device-mapper/dm-crypt.txt b/Documentation/device-mapper/dm-crypt.txt index 59293ac4a5d0..6b5c42dbbe84 100644 --- a/Documentation/device-mapper/dm-crypt.txt +++ b/Documentation/device-mapper/dm-crypt.txt | |||
| @@ -41,7 +41,7 @@ Example scripts | |||
| 41 | =============== | 41 | =============== |
| 42 | LUKS (Linux Unified Key Setup) is now the preferred way to set up disk | 42 | LUKS (Linux Unified Key Setup) is now the preferred way to set up disk |
| 43 | encryption with dm-crypt using the 'cryptsetup' utility, see | 43 | encryption with dm-crypt using the 'cryptsetup' utility, see |
| 44 | http://clemens.endorphin.org/cryptography | 44 | http://code.google.com/p/cryptsetup/ |
| 45 | 45 | ||
| 46 | [[ | 46 | [[ |
| 47 | #!/bin/sh | 47 | #!/bin/sh |
diff --git a/Documentation/device-mapper/dm-flakey.txt b/Documentation/device-mapper/dm-flakey.txt new file mode 100644 index 000000000000..c8efdfd19a65 --- /dev/null +++ b/Documentation/device-mapper/dm-flakey.txt | |||
| @@ -0,0 +1,17 @@ | |||
| 1 | dm-flakey | ||
| 2 | ========= | ||
| 3 | |||
| 4 | This target is the same as the linear target except that it returns I/O | ||
| 5 | errors periodically. It's been found useful in simulating failing | ||
| 6 | devices for testing purposes. | ||
| 7 | |||
| 8 | Starting from the time the table is loaded, the device is available for | ||
| 9 | <up interval> seconds, then returns errors for <down interval> seconds, | ||
| 10 | and then this cycle repeats. | ||
| 11 | |||
| 12 | Parameters: <dev path> <offset> <up interval> <down interval> | ||
| 13 | <dev path>: Full pathname to the underlying block-device, or a | ||
| 14 | "major:minor" device-number. | ||
| 15 | <offset>: Starting sector within the device. | ||
| 16 | <up interval>: Number of seconds device is available. | ||
| 17 | <down interval>: Number of seconds device returns errors. | ||
diff --git a/Documentation/device-mapper/dm-service-time.txt b/Documentation/device-mapper/dm-service-time.txt index 7d00668e97bb..fb1d4a0cf122 100644 --- a/Documentation/device-mapper/dm-service-time.txt +++ b/Documentation/device-mapper/dm-service-time.txt | |||
| @@ -37,7 +37,7 @@ Algorithm | |||
| 37 | ========= | 37 | ========= |
| 38 | 38 | ||
| 39 | dm-service-time adds the I/O size to 'in-flight-size' when the I/O is | 39 | dm-service-time adds the I/O size to 'in-flight-size' when the I/O is |
| 40 | dispatched and substracts when completed. | 40 | dispatched and subtracts when completed. |
| 41 | Basically, dm-service-time selects a path having minimum service time | 41 | Basically, dm-service-time selects a path having minimum service time |
| 42 | which is calculated by: | 42 | which is calculated by: |
| 43 | 43 | ||
diff --git a/Documentation/devicetree/00-INDEX b/Documentation/devicetree/00-INDEX new file mode 100644 index 000000000000..b78f691fd847 --- /dev/null +++ b/Documentation/devicetree/00-INDEX | |||
| @@ -0,0 +1,10 @@ | |||
| 1 | Documentation for device trees, a data structure by which bootloaders pass | ||
| 2 | hardware layout to Linux in a device-independent manner, simplifying hardware | ||
| 3 | probing. This subsystem is maintained by Grant Likely | ||
| 4 | <grant.likely@secretlab.ca> and has a mailing list at | ||
| 5 | https://lists.ozlabs.org/listinfo/devicetree-discuss | ||
| 6 | |||
| 7 | 00-INDEX | ||
| 8 | - this file | ||
| 9 | booting-without-of.txt | ||
| 10 | - Booting Linux without Open Firmware, describes history and format of device trees. | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/sata.txt b/Documentation/devicetree/bindings/ata/fsl-sata.txt index b46bcf46c3d8..b46bcf46c3d8 100644 --- a/Documentation/powerpc/dts-bindings/fsl/sata.txt +++ b/Documentation/devicetree/bindings/ata/fsl-sata.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/eeprom.txt b/Documentation/devicetree/bindings/eeprom.txt index 4342c10de1bf..4342c10de1bf 100644 --- a/Documentation/powerpc/dts-bindings/eeprom.txt +++ b/Documentation/devicetree/bindings/eeprom.txt | |||
diff --git a/Documentation/devicetree/bindings/fb/sm501fb.txt b/Documentation/devicetree/bindings/fb/sm501fb.txt new file mode 100644 index 000000000000..9d9f0098092b --- /dev/null +++ b/Documentation/devicetree/bindings/fb/sm501fb.txt | |||
| @@ -0,0 +1,34 @@ | |||
| 1 | * SM SM501 | ||
| 2 | |||
| 3 | The SM SM501 is a LCD controller, with proper hardware, it can also | ||
| 4 | drive DVI monitors. | ||
| 5 | |||
| 6 | Required properties: | ||
| 7 | - compatible : should be "smi,sm501". | ||
| 8 | - reg : contain two entries: | ||
| 9 | - First entry: System Configuration register | ||
| 10 | - Second entry: IO space (Display Controller register) | ||
| 11 | - interrupts : SMI interrupt to the cpu should be described here. | ||
| 12 | - interrupt-parent : the phandle for the interrupt controller that | ||
| 13 | services interrupts for this device. | ||
| 14 | |||
| 15 | Optional properties: | ||
| 16 | - mode : select a video mode: | ||
| 17 | <xres>x<yres>[-<bpp>][@<refresh>] | ||
| 18 | - edid : verbatim EDID data block describing attached display. | ||
| 19 | Data from the detailed timing descriptor will be used to | ||
| 20 | program the display controller. | ||
| 21 | - little-endian: available on big endian systems, to | ||
| 22 | set different foreign endian. | ||
| 23 | - big-endian: available on little endian systems, to | ||
| 24 | set different foreign endian. | ||
| 25 | |||
| 26 | Example for MPC5200: | ||
| 27 | display@1,0 { | ||
| 28 | compatible = "smi,sm501"; | ||
| 29 | reg = <1 0x00000000 0x00800000 | ||
| 30 | 1 0x03e00000 0x00200000>; | ||
| 31 | interrupts = <1 1 3>; | ||
| 32 | mode = "640x480-32@60"; | ||
| 33 | edid = [edid-data]; | ||
| 34 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/8xxx_gpio.txt b/Documentation/devicetree/bindings/gpio/8xxx_gpio.txt index b0019eb5330e..b0019eb5330e 100644 --- a/Documentation/powerpc/dts-bindings/fsl/8xxx_gpio.txt +++ b/Documentation/devicetree/bindings/gpio/8xxx_gpio.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt index edaa84d288a1..edaa84d288a1 100644 --- a/Documentation/powerpc/dts-bindings/gpio/gpio.txt +++ b/Documentation/devicetree/bindings/gpio/gpio.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/gpio/led.txt b/Documentation/devicetree/bindings/gpio/led.txt index 064db928c3c1..064db928c3c1 100644 --- a/Documentation/powerpc/dts-bindings/gpio/led.txt +++ b/Documentation/devicetree/bindings/gpio/led.txt | |||
diff --git a/Documentation/devicetree/bindings/hwmon/ads1015.txt b/Documentation/devicetree/bindings/hwmon/ads1015.txt new file mode 100644 index 000000000000..918a507d1159 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/ads1015.txt | |||
| @@ -0,0 +1,73 @@ | |||
| 1 | ADS1015 (I2C) | ||
| 2 | |||
| 3 | This device is a 12-bit A-D converter with 4 inputs. | ||
| 4 | |||
| 5 | The inputs can be used single ended or in certain differential combinations. | ||
| 6 | |||
| 7 | For configuration all possible combinations are mapped to 8 channels: | ||
| 8 | 0: Voltage over AIN0 and AIN1. | ||
| 9 | 1: Voltage over AIN0 and AIN3. | ||
| 10 | 2: Voltage over AIN1 and AIN3. | ||
| 11 | 3: Voltage over AIN2 and AIN3. | ||
| 12 | 4: Voltage over AIN0 and GND. | ||
| 13 | 5: Voltage over AIN1 and GND. | ||
| 14 | 6: Voltage over AIN2 and GND. | ||
| 15 | 7: Voltage over AIN3 and GND. | ||
| 16 | |||
| 17 | Each channel can be configured individually: | ||
| 18 | - pga is the programmable gain amplifier (values are full scale) | ||
| 19 | 0: +/- 6.144 V | ||
| 20 | 1: +/- 4.096 V | ||
| 21 | 2: +/- 2.048 V (default) | ||
| 22 | 3: +/- 1.024 V | ||
| 23 | 4: +/- 0.512 V | ||
| 24 | 5: +/- 0.256 V | ||
| 25 | - data_rate in samples per second | ||
| 26 | 0: 128 | ||
| 27 | 1: 250 | ||
| 28 | 2: 490 | ||
| 29 | 3: 920 | ||
| 30 | 4: 1600 (default) | ||
| 31 | 5: 2400 | ||
| 32 | 6: 3300 | ||
| 33 | |||
| 34 | 1) The /ads1015 node | ||
| 35 | |||
| 36 | Required properties: | ||
| 37 | |||
| 38 | - compatible : must be "ti,ads1015" | ||
| 39 | - reg : I2C bus address of the device | ||
| 40 | - #address-cells : must be <1> | ||
| 41 | - #size-cells : must be <0> | ||
| 42 | |||
| 43 | The node contains child nodes for each channel that the platform uses. | ||
| 44 | |||
| 45 | Example ADS1015 node: | ||
| 46 | |||
| 47 | ads1015@49 { | ||
| 48 | compatible = "ti,ads1015"; | ||
| 49 | reg = <0x49>; | ||
| 50 | #address-cells = <1>; | ||
| 51 | #size-cells = <0>; | ||
| 52 | |||
| 53 | [ child node definitions... ] | ||
| 54 | } | ||
| 55 | |||
| 56 | 2) channel nodes | ||
| 57 | |||
| 58 | Required properties: | ||
| 59 | |||
| 60 | - reg : the channel number | ||
| 61 | |||
| 62 | Optional properties: | ||
| 63 | |||
| 64 | - ti,gain : the programmable gain amplifier setting | ||
| 65 | - ti,datarate : the converter data rate | ||
| 66 | |||
| 67 | Example ADS1015 channel node: | ||
| 68 | |||
| 69 | channel@4 { | ||
| 70 | reg = <4>; | ||
| 71 | ti,gain = <3>; | ||
| 72 | ti,datarate = <5>; | ||
| 73 | }; | ||
diff --git a/Documentation/devicetree/bindings/i2c/ce4100-i2c.txt b/Documentation/devicetree/bindings/i2c/ce4100-i2c.txt new file mode 100644 index 000000000000..569b16248514 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/ce4100-i2c.txt | |||
| @@ -0,0 +1,93 @@ | |||
| 1 | CE4100 I2C | ||
| 2 | ---------- | ||
| 3 | |||
| 4 | CE4100 has one PCI device which is described as the I2C-Controller. This | ||
| 5 | PCI device has three PCI-bars, each bar contains a complete I2C | ||
| 6 | controller. So we have a total of three independent I2C-Controllers | ||
| 7 | which share only an interrupt line. | ||
| 8 | The driver is probed via the PCI-ID and is gathering the information of | ||
| 9 | attached devices from the devices tree. | ||
| 10 | Grant Likely recommended to use the ranges property to map the PCI-Bar | ||
| 11 | number to its physical address and to use this to find the child nodes | ||
| 12 | of the specific I2C controller. This were his exact words: | ||
| 13 | |||
| 14 | Here's where the magic happens. Each entry in | ||
| 15 | ranges describes how the parent pci address space | ||
| 16 | (middle group of 3) is translated to the local | ||
| 17 | address space (first group of 2) and the size of | ||
| 18 | each range (last cell). In this particular case, | ||
| 19 | the first cell of the local address is chosen to be | ||
| 20 | 1:1 mapped to the BARs, and the second is the | ||
| 21 | offset from be base of the BAR (which would be | ||
| 22 | non-zero if you had 2 or more devices mapped off | ||
| 23 | the same BAR) | ||
| 24 | |||
| 25 | ranges allows the address mapping to be described | ||
| 26 | in a way that the OS can interpret without | ||
| 27 | requiring custom device driver code. | ||
| 28 | |||
| 29 | This is an example which is used on FalconFalls: | ||
| 30 | ------------------------------------------------ | ||
| 31 | i2c-controller@b,2 { | ||
| 32 | #address-cells = <2>; | ||
| 33 | #size-cells = <1>; | ||
| 34 | compatible = "pci8086,2e68.2", | ||
| 35 | "pci8086,2e68", | ||
| 36 | "pciclass,ff0000", | ||
| 37 | "pciclass,ff00"; | ||
| 38 | |||
| 39 | reg = <0x15a00 0x0 0x0 0x0 0x0>; | ||
| 40 | interrupts = <16 1>; | ||
| 41 | |||
| 42 | /* as described by Grant, the first number in the group of | ||
| 43 | * three is the bar number followed by the 64bit bar address | ||
| 44 | * followed by size of the mapping. The bar address | ||
| 45 | * requires also a valid translation in parents ranges | ||
| 46 | * property. | ||
| 47 | */ | ||
| 48 | ranges = <0 0 0x02000000 0 0xdffe0500 0x100 | ||
| 49 | 1 0 0x02000000 0 0xdffe0600 0x100 | ||
| 50 | 2 0 0x02000000 0 0xdffe0700 0x100>; | ||
| 51 | |||
| 52 | i2c@0 { | ||
| 53 | #address-cells = <1>; | ||
| 54 | #size-cells = <0>; | ||
| 55 | compatible = "intel,ce4100-i2c-controller"; | ||
| 56 | |||
| 57 | /* The first number in the reg property is the | ||
| 58 | * number of the bar | ||
| 59 | */ | ||
| 60 | reg = <0 0 0x100>; | ||
| 61 | |||
| 62 | /* This I2C controller has no devices */ | ||
| 63 | }; | ||
| 64 | |||
| 65 | i2c@1 { | ||
| 66 | #address-cells = <1>; | ||
| 67 | #size-cells = <0>; | ||
| 68 | compatible = "intel,ce4100-i2c-controller"; | ||
| 69 | reg = <1 0 0x100>; | ||
| 70 | |||
| 71 | /* This I2C controller has one gpio controller */ | ||
| 72 | gpio@26 { | ||
| 73 | #gpio-cells = <2>; | ||
| 74 | compatible = "ti,pcf8575"; | ||
| 75 | reg = <0x26>; | ||
| 76 | gpio-controller; | ||
| 77 | }; | ||
| 78 | }; | ||
| 79 | |||
| 80 | i2c@2 { | ||
| 81 | #address-cells = <1>; | ||
| 82 | #size-cells = <0>; | ||
| 83 | compatible = "intel,ce4100-i2c-controller"; | ||
| 84 | reg = <2 0 0x100>; | ||
| 85 | |||
| 86 | gpio@26 { | ||
| 87 | #gpio-cells = <2>; | ||
| 88 | compatible = "ti,pcf8575"; | ||
| 89 | reg = <0x26>; | ||
| 90 | gpio-controller; | ||
| 91 | }; | ||
| 92 | }; | ||
| 93 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/i2c.txt b/Documentation/devicetree/bindings/i2c/fsl-i2c.txt index 1eacd6b20ed5..1eacd6b20ed5 100644 --- a/Documentation/powerpc/dts-bindings/fsl/i2c.txt +++ b/Documentation/devicetree/bindings/i2c/fsl-i2c.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/marvell.txt b/Documentation/devicetree/bindings/marvell.txt index f1533d91953a..f1533d91953a 100644 --- a/Documentation/powerpc/dts-bindings/marvell.txt +++ b/Documentation/devicetree/bindings/marvell.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/fsl/esdhc.txt b/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt index 64bcb8be973c..64bcb8be973c 100644 --- a/Documentation/powerpc/dts-bindings/fsl/esdhc.txt +++ b/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/mmc-spi-slot.txt b/Documentation/devicetree/bindings/mmc/mmc-spi-slot.txt index c39ac2891951..89a0084df2f7 100644 --- a/Documentation/powerpc/dts-bindings/mmc-spi-slot.txt +++ b/Documentation/devicetree/bindings/mmc/mmc-spi-slot.txt | |||
| @@ -7,8 +7,13 @@ Required properties: | |||
| 7 | - voltage-ranges : two cells are required, first cell specifies minimum | 7 | - voltage-ranges : two cells are required, first cell specifies minimum |
| 8 | slot voltage (mV), second cell specifies maximum slot voltage (mV). | 8 | slot voltage (mV), second cell specifies maximum slot voltage (mV). |
| 9 | Several ranges could be specified. | 9 | Several ranges could be specified. |
| 10 | - gpios : (optional) may specify GPIOs in this order: Card-Detect GPIO, | 10 | |
| 11 | Optional properties: | ||
| 12 | - gpios : may specify GPIOs in this order: Card-Detect GPIO, | ||
| 11 | Write-Protect GPIO. | 13 | Write-Protect GPIO. |
| 14 | - interrupts : the interrupt of a card detect interrupt. | ||
| 15 | - interrupt-parent : the phandle for the interrupt controller that | ||
| 16 | services interrupts for this device. | ||
| 12 | 17 | ||
| 13 | Example: | 18 | Example: |
| 14 | 19 | ||
| @@ -20,4 +25,6 @@ Example: | |||
| 20 | &qe_pio_d 15 0>; | 25 | &qe_pio_d 15 0>; |
| 21 | voltage-ranges = <3300 3300>; | 26 | voltage-ranges = <3300 3300>; |
| 22 | spi-max-frequency = <50000000>; | 27 | spi-max-frequency = <50000000>; |
| 28 | interrupts = <42>; | ||
| 29 | interrupt-parent = <&PIC>; | ||
| 23 | }; | 30 | }; |
diff --git a/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt b/Documentation/devicetree/bindings/mtd/fsl-upm-nand.txt index a48b2cadc7f0..00f1f546b32e 100644 --- a/Documentation/powerpc/dts-bindings/fsl/upm-nand.txt +++ b/Documentation/devicetree/bindings/mtd/fsl-upm-nand.txt | |||
| @@ -15,7 +15,7 @@ Optional properties: | |||
| 15 | - gpios : may specify optional GPIOs connected to the Ready-Not-Busy pins | 15 | - gpios : may specify optional GPIOs connected to the Ready-Not-Busy pins |
| 16 | (R/B#). For multi-chip devices, "n" GPIO definitions are required | 16 | (R/B#). For multi-chip devices, "n" GPIO definitions are required |
| 17 | according to the number of chips. | 17 | according to the number of chips. |
| 18 | - chip-delay : chip dependent delay for transfering data from array to | 18 | - chip-delay : chip dependent delay for transferring data from array to |
| 19 | read registers (tR). Required if property "gpios" is not used | 19 | read registers (tR). Required if property "gpios" is not used |
| 20 | (R/B# pins not connected). | 20 | (R/B# pins not connected). |
| 21 | 21 | ||
diff --git a/Documentation/powerpc/dts-bindings/mtd-physmap.txt b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt index 80152cb567d9..80152cb567d9 100644 --- a/Documentation/powerpc/dts-bindings/mtd-physmap.txt +++ b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/fsl/can.txt b/Documentation/devicetree/bindings/net/can/mpc5xxx-mscan.txt index 2fa4fcd38fd6..2fa4fcd38fd6 100644 --- a/Documentation/powerpc/dts-bindings/fsl/can.txt +++ b/Documentation/devicetree/bindings/net/can/mpc5xxx-mscan.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/can/sja1000.txt b/Documentation/devicetree/bindings/net/can/sja1000.txt index d6d209ded937..c2dbcec0ee31 100644 --- a/Documentation/powerpc/dts-bindings/can/sja1000.txt +++ b/Documentation/devicetree/bindings/net/can/sja1000.txt | |||
| @@ -39,7 +39,7 @@ Optional properties: | |||
| 39 | 39 | ||
| 40 | - nxp,no-comparator-bypass : Allows to disable the CAN input comperator. | 40 | - nxp,no-comparator-bypass : Allows to disable the CAN input comperator. |
| 41 | 41 | ||
| 42 | For futher information, please have a look to the SJA1000 data sheet. | 42 | For further information, please have a look to the SJA1000 data sheet. |
| 43 | 43 | ||
| 44 | Examples: | 44 | Examples: |
| 45 | 45 | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/tsec.txt b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt index edb7ae19e868..edb7ae19e868 100644 --- a/Documentation/powerpc/dts-bindings/fsl/tsec.txt +++ b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/gpio/mdio.txt b/Documentation/devicetree/bindings/net/mdio-gpio.txt index bc9549529014..bc9549529014 100644 --- a/Documentation/powerpc/dts-bindings/gpio/mdio.txt +++ b/Documentation/devicetree/bindings/net/mdio-gpio.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/phy.txt b/Documentation/devicetree/bindings/net/phy.txt index bb8c742eb8c5..bb8c742eb8c5 100644 --- a/Documentation/powerpc/dts-bindings/phy.txt +++ b/Documentation/devicetree/bindings/net/phy.txt | |||
diff --git a/Documentation/devicetree/bindings/open-pic.txt b/Documentation/devicetree/bindings/open-pic.txt new file mode 100644 index 000000000000..909a902dff85 --- /dev/null +++ b/Documentation/devicetree/bindings/open-pic.txt | |||
| @@ -0,0 +1,98 @@ | |||
| 1 | * Open PIC Binding | ||
| 2 | |||
| 3 | This binding specifies what properties must be available in the device tree | ||
| 4 | representation of an Open PIC compliant interrupt controller. This binding is | ||
| 5 | based on the binding defined for Open PIC in [1] and is a superset of that | ||
| 6 | binding. | ||
| 7 | |||
| 8 | Required properties: | ||
| 9 | |||
| 10 | NOTE: Many of these descriptions were paraphrased here from [1] to aid | ||
| 11 | readability. | ||
| 12 | |||
| 13 | - compatible: Specifies the compatibility list for the PIC. The type | ||
| 14 | shall be <string> and the value shall include "open-pic". | ||
| 15 | |||
| 16 | - reg: Specifies the base physical address(s) and size(s) of this | ||
| 17 | PIC's addressable register space. The type shall be <prop-encoded-array>. | ||
| 18 | |||
| 19 | - interrupt-controller: The presence of this property identifies the node | ||
| 20 | as an Open PIC. No property value shall be defined. | ||
| 21 | |||
| 22 | - #interrupt-cells: Specifies the number of cells needed to encode an | ||
| 23 | interrupt source. The type shall be a <u32> and the value shall be 2. | ||
| 24 | |||
| 25 | - #address-cells: Specifies the number of cells needed to encode an | ||
| 26 | address. The type shall be <u32> and the value shall be 0. As such, | ||
| 27 | 'interrupt-map' nodes do not have to specify a parent unit address. | ||
| 28 | |||
| 29 | Optional properties: | ||
| 30 | |||
| 31 | - pic-no-reset: The presence of this property indicates that the PIC | ||
| 32 | shall not be reset during runtime initialization. No property value shall | ||
| 33 | be defined. The presence of this property also mandates that any | ||
| 34 | initialization related to interrupt sources shall be limited to sources | ||
| 35 | explicitly referenced in the device tree. | ||
| 36 | |||
| 37 | * Interrupt Specifier Definition | ||
| 38 | |||
| 39 | Interrupt specifiers consists of 2 cells encoded as | ||
| 40 | follows: | ||
| 41 | |||
| 42 | - <1st-cell>: The interrupt-number that identifies the interrupt source. | ||
| 43 | |||
| 44 | - <2nd-cell>: The level-sense information, encoded as follows: | ||
| 45 | 0 = low-to-high edge triggered | ||
| 46 | 1 = active low level-sensitive | ||
| 47 | 2 = active high level-sensitive | ||
| 48 | 3 = high-to-low edge triggered | ||
| 49 | |||
| 50 | * Examples | ||
| 51 | |||
| 52 | Example 1: | ||
| 53 | |||
| 54 | /* | ||
| 55 | * An Open PIC interrupt controller | ||
| 56 | */ | ||
| 57 | mpic: pic@40000 { | ||
| 58 | // This is an interrupt controller node. | ||
| 59 | interrupt-controller; | ||
| 60 | |||
| 61 | // No address cells so that 'interrupt-map' nodes which reference | ||
| 62 | // this Open PIC node do not need a parent address specifier. | ||
| 63 | #address-cells = <0>; | ||
| 64 | |||
| 65 | // Two cells to encode interrupt sources. | ||
| 66 | #interrupt-cells = <2>; | ||
| 67 | |||
| 68 | // Offset address of 0x40000 and size of 0x40000. | ||
| 69 | reg = <0x40000 0x40000>; | ||
| 70 | |||
| 71 | // Compatible with Open PIC. | ||
| 72 | compatible = "open-pic"; | ||
| 73 | |||
| 74 | // The PIC shall not be reset. | ||
| 75 | pic-no-reset; | ||
| 76 | }; | ||
| 77 | |||
| 78 | Example 2: | ||
| 79 | |||
| 80 | /* | ||
| 81 | * An interrupt generating device that is wired to an Open PIC. | ||
| 82 | */ | ||
| 83 | serial0: serial@4500 { | ||
| 84 | // Interrupt source '42' that is active high level-sensitive. | ||
| 85 | // Note that there are only two cells as specified in the interrupt | ||
| 86 | // parent's '#interrupt-cells' property. | ||
| 87 | interrupts = <42 2>; | ||
| 88 | |||
| 89 | // The interrupt controller that this device is wired to. | ||
| 90 | interrupt-parent = <&mpic>; | ||
| 91 | }; | ||
| 92 | |||
| 93 | * References | ||
| 94 | |||
| 95 | [1] Power.org (TM) Standard for Embedded Power Architecture (TM) Platform | ||
| 96 | Requirements (ePAPR), Version 1.0, July 2008. | ||
| 97 | (http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf) | ||
| 98 | |||
diff --git a/Documentation/powerpc/dts-bindings/fsl/83xx-512x-pci.txt b/Documentation/devicetree/bindings/pci/83xx-512x-pci.txt index 35a465362408..35a465362408 100644 --- a/Documentation/powerpc/dts-bindings/fsl/83xx-512x-pci.txt +++ b/Documentation/devicetree/bindings/pci/83xx-512x-pci.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/4xx/cpm.txt b/Documentation/devicetree/bindings/powerpc/4xx/cpm.txt index ee459806d35e..ee459806d35e 100644 --- a/Documentation/powerpc/dts-bindings/4xx/cpm.txt +++ b/Documentation/devicetree/bindings/powerpc/4xx/cpm.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/4xx/emac.txt b/Documentation/devicetree/bindings/powerpc/4xx/emac.txt index 2161334a7ca5..2161334a7ca5 100644 --- a/Documentation/powerpc/dts-bindings/4xx/emac.txt +++ b/Documentation/devicetree/bindings/powerpc/4xx/emac.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/4xx/ndfc.txt b/Documentation/devicetree/bindings/powerpc/4xx/ndfc.txt index 869f0b5f16e8..869f0b5f16e8 100644 --- a/Documentation/powerpc/dts-bindings/4xx/ndfc.txt +++ b/Documentation/devicetree/bindings/powerpc/4xx/ndfc.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/4xx/ppc440spe-adma.txt b/Documentation/devicetree/bindings/powerpc/4xx/ppc440spe-adma.txt index 515ebcf1b97d..515ebcf1b97d 100644 --- a/Documentation/powerpc/dts-bindings/4xx/ppc440spe-adma.txt +++ b/Documentation/devicetree/bindings/powerpc/4xx/ppc440spe-adma.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/4xx/reboot.txt b/Documentation/devicetree/bindings/powerpc/4xx/reboot.txt index d7217260589c..d7217260589c 100644 --- a/Documentation/powerpc/dts-bindings/4xx/reboot.txt +++ b/Documentation/devicetree/bindings/powerpc/4xx/reboot.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/fsl/board.txt b/Documentation/devicetree/bindings/powerpc/fsl/board.txt index 39e941515a36..39e941515a36 100644 --- a/Documentation/powerpc/dts-bindings/fsl/board.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/board.txt | |||
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/cache_sram.txt b/Documentation/devicetree/bindings/powerpc/fsl/cache_sram.txt new file mode 100644 index 000000000000..781955f5217d --- /dev/null +++ b/Documentation/devicetree/bindings/powerpc/fsl/cache_sram.txt | |||
| @@ -0,0 +1,20 @@ | |||
| 1 | * Freescale PQ3 and QorIQ based Cache SRAM | ||
| 2 | |||
| 3 | Freescale's mpc85xx and some QorIQ platforms provide an | ||
| 4 | option of configuring a part of (or full) cache memory | ||
| 5 | as SRAM. This cache SRAM representation in the device | ||
| 6 | tree should be done as under:- | ||
| 7 | |||
| 8 | Required properties: | ||
| 9 | |||
| 10 | - compatible : should be "fsl,p2020-cache-sram" | ||
| 11 | - fsl,cache-sram-ctlr-handle : points to the L2 controller | ||
| 12 | - reg : offset and length of the cache-sram. | ||
| 13 | |||
| 14 | Example: | ||
| 15 | |||
| 16 | cache-sram@fff00000 { | ||
| 17 | fsl,cache-sram-ctlr-handle = <&L2>; | ||
| 18 | reg = <0 0xfff00000 0 0x10000>; | ||
| 19 | compatible = "fsl,p2020-cache-sram"; | ||
| 20 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm.txt b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/cpm.txt index 160c752484b4..160c752484b4 100644 --- a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/cpm.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/brg.txt b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/cpm/brg.txt index 4c7d45eaf025..4c7d45eaf025 100644 --- a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/brg.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/cpm/brg.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/i2c.txt b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/cpm/i2c.txt index 87bc6048667e..87bc6048667e 100644 --- a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/i2c.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/cpm/i2c.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/pic.txt b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/cpm/pic.txt index 8e3ee1681618..8e3ee1681618 100644 --- a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/pic.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/cpm/pic.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/usb.txt b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/cpm/usb.txt index 74bfda4bb824..74bfda4bb824 100644 --- a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/cpm/usb.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/cpm/usb.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/gpio.txt b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/gpio.txt index 349f79fd7076..349f79fd7076 100644 --- a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/gpio.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/gpio.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/network.txt b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/network.txt index 0e4269446580..0e4269446580 100644 --- a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/network.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/network.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe.txt index 4f8930263dd9..4f8930263dd9 100644 --- a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/firmware.txt b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe/firmware.txt index 249db3a15d15..249db3a15d15 100644 --- a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/firmware.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe/firmware.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/par_io.txt b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe/par_io.txt index 60984260207b..60984260207b 100644 --- a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/par_io.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe/par_io.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/pincfg.txt b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe/pincfg.txt index c5b43061db3a..c5b43061db3a 100644 --- a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/pincfg.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe/pincfg.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/ucc.txt b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe/ucc.txt index e47734bee3f0..e47734bee3f0 100644 --- a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/ucc.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe/ucc.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/usb.txt b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe/usb.txt index 9ccd5f30405b..9ccd5f30405b 100644 --- a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/qe/usb.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe/usb.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/serial.txt b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/serial.txt index 2ea76d9d137c..2ea76d9d137c 100644 --- a/Documentation/powerpc/dts-bindings/fsl/cpm_qe/serial.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/serial.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/fsl/diu.txt b/Documentation/devicetree/bindings/powerpc/fsl/diu.txt index b66cb6d31d69..b66cb6d31d69 100644 --- a/Documentation/powerpc/dts-bindings/fsl/diu.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/diu.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/fsl/dma.txt b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt index 2a4b4bce6110..2a4b4bce6110 100644 --- a/Documentation/powerpc/dts-bindings/fsl/dma.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/ecm.txt b/Documentation/devicetree/bindings/powerpc/fsl/ecm.txt index f514f29c67d6..f514f29c67d6 100644 --- a/Documentation/powerpc/dts-bindings/ecm.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/ecm.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/fsl/gtm.txt b/Documentation/devicetree/bindings/powerpc/fsl/gtm.txt index 9a33efded4bc..9a33efded4bc 100644 --- a/Documentation/powerpc/dts-bindings/fsl/gtm.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/gtm.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/fsl/guts.txt b/Documentation/devicetree/bindings/powerpc/fsl/guts.txt index 9e7a2417dac5..9e7a2417dac5 100644 --- a/Documentation/powerpc/dts-bindings/fsl/guts.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/guts.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/fsl/lbc.txt b/Documentation/devicetree/bindings/powerpc/fsl/lbc.txt index 3300fec501c5..3300fec501c5 100644 --- a/Documentation/powerpc/dts-bindings/fsl/lbc.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/lbc.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/fsl/mcm.txt b/Documentation/devicetree/bindings/powerpc/fsl/mcm.txt index 4ceda9b3b413..4ceda9b3b413 100644 --- a/Documentation/powerpc/dts-bindings/fsl/mcm.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/mcm.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/fsl/mcu-mpc8349emitx.txt b/Documentation/devicetree/bindings/powerpc/fsl/mcu-mpc8349emitx.txt index 0f766333b6eb..0f766333b6eb 100644 --- a/Documentation/powerpc/dts-bindings/fsl/mcu-mpc8349emitx.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/mcu-mpc8349emitx.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/fsl/mpc5121-psc.txt b/Documentation/devicetree/bindings/powerpc/fsl/mpc5121-psc.txt index 8832e8798912..8832e8798912 100644 --- a/Documentation/powerpc/dts-bindings/fsl/mpc5121-psc.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/mpc5121-psc.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt b/Documentation/devicetree/bindings/powerpc/fsl/mpc5200.txt index 4ccb2cd5df94..4ccb2cd5df94 100644 --- a/Documentation/powerpc/dts-bindings/fsl/mpc5200.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/mpc5200.txt | |||
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt b/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt new file mode 100644 index 000000000000..4f6145859aab --- /dev/null +++ b/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt | |||
| @@ -0,0 +1,211 @@ | |||
| 1 | ===================================================================== | ||
| 2 | Freescale MPIC Interrupt Controller Node | ||
| 3 | Copyright (C) 2010,2011 Freescale Semiconductor Inc. | ||
| 4 | ===================================================================== | ||
| 5 | |||
| 6 | The Freescale MPIC interrupt controller is found on all PowerQUICC | ||
| 7 | and QorIQ processors and is compatible with the Open PIC. The | ||
| 8 | notable difference from Open PIC binding is the addition of 2 | ||
| 9 | additional cells in the interrupt specifier defining interrupt type | ||
| 10 | information. | ||
| 11 | |||
| 12 | PROPERTIES | ||
| 13 | |||
| 14 | - compatible | ||
| 15 | Usage: required | ||
| 16 | Value type: <string> | ||
| 17 | Definition: Shall include "fsl,mpic". Freescale MPIC | ||
| 18 | controllers compatible with this binding have Block | ||
| 19 | Revision Registers BRR1 and BRR2 at offset 0x0 and | ||
| 20 | 0x10 in the MPIC. | ||
| 21 | |||
| 22 | - reg | ||
| 23 | Usage: required | ||
| 24 | Value type: <prop-encoded-array> | ||
| 25 | Definition: A standard property. Specifies the physical | ||
| 26 | offset and length of the device's registers within the | ||
| 27 | CCSR address space. | ||
| 28 | |||
| 29 | - interrupt-controller | ||
| 30 | Usage: required | ||
| 31 | Value type: <empty> | ||
| 32 | Definition: Specifies that this node is an interrupt | ||
| 33 | controller | ||
| 34 | |||
| 35 | - #interrupt-cells | ||
| 36 | Usage: required | ||
| 37 | Value type: <u32> | ||
| 38 | Definition: Shall be 2 or 4. A value of 2 means that interrupt | ||
| 39 | specifiers do not contain the interrupt-type or type-specific | ||
| 40 | information cells. | ||
| 41 | |||
| 42 | - #address-cells | ||
| 43 | Usage: required | ||
| 44 | Value type: <u32> | ||
| 45 | Definition: Shall be 0. | ||
| 46 | |||
| 47 | - pic-no-reset | ||
| 48 | Usage: optional | ||
| 49 | Value type: <empty> | ||
| 50 | Definition: The presence of this property specifies that the | ||
| 51 | MPIC must not be reset by the client program, and that | ||
| 52 | the boot program has initialized all interrupt source | ||
| 53 | configuration registers to a sane state-- masked or | ||
| 54 | directed at other cores. This ensures that the client | ||
| 55 | program will not receive interrupts for sources not belonging | ||
| 56 | to the client. The presence of this property also mandates | ||
| 57 | that any initialization related to interrupt sources shall | ||
| 58 | be limited to sources explicitly referenced in the device tree. | ||
| 59 | |||
| 60 | INTERRUPT SPECIFIER DEFINITION | ||
| 61 | |||
| 62 | Interrupt specifiers consists of 4 cells encoded as | ||
| 63 | follows: | ||
| 64 | |||
| 65 | <1st-cell> interrupt-number | ||
| 66 | |||
| 67 | Identifies the interrupt source. The meaning | ||
| 68 | depends on the type of interrupt. | ||
| 69 | |||
| 70 | Note: If the interrupt-type cell is undefined | ||
| 71 | (i.e. #interrupt-cells = 2), this cell | ||
| 72 | should be interpreted the same as for | ||
| 73 | interrupt-type 0-- i.e. an external or | ||
| 74 | normal SoC device interrupt. | ||
| 75 | |||
| 76 | <2nd-cell> level-sense information, encoded as follows: | ||
| 77 | 0 = low-to-high edge triggered | ||
| 78 | 1 = active low level-sensitive | ||
| 79 | 2 = active high level-sensitive | ||
| 80 | 3 = high-to-low edge triggered | ||
| 81 | |||
| 82 | <3rd-cell> interrupt-type | ||
| 83 | |||
| 84 | The following types are supported: | ||
| 85 | |||
| 86 | 0 = external or normal SoC device interrupt | ||
| 87 | |||
| 88 | The interrupt-number cell contains | ||
| 89 | the SoC device interrupt number. The | ||
| 90 | type-specific cell is undefined. The | ||
| 91 | interrupt-number is derived from the | ||
| 92 | MPIC a block of registers referred to as | ||
| 93 | the "Interrupt Source Configuration Registers". | ||
| 94 | Each source has 32-bytes of registers | ||
| 95 | (vector/priority and destination) in this | ||
| 96 | region. So interrupt 0 is at offset 0x0, | ||
| 97 | interrupt 1 is at offset 0x20, and so on. | ||
| 98 | |||
| 99 | 1 = error interrupt | ||
| 100 | |||
| 101 | The interrupt-number cell contains | ||
| 102 | the SoC device interrupt number for | ||
| 103 | the error interrupt. The type-specific | ||
| 104 | cell identifies the specific error | ||
| 105 | interrupt number. | ||
| 106 | |||
| 107 | 2 = MPIC inter-processor interrupt (IPI) | ||
| 108 | |||
| 109 | The interrupt-number cell identifies | ||
| 110 | the MPIC IPI number. The type-specific | ||
| 111 | cell is undefined. | ||
| 112 | |||
| 113 | 3 = MPIC timer interrupt | ||
| 114 | |||
| 115 | The interrupt-number cell identifies | ||
| 116 | the MPIC timer number. The type-specific | ||
| 117 | cell is undefined. | ||
| 118 | |||
| 119 | <4th-cell> type-specific information | ||
| 120 | |||
| 121 | The type-specific cell is encoded as follows: | ||
| 122 | |||
| 123 | - For interrupt-type 1 (error interrupt), | ||
| 124 | the type-specific cell contains the | ||
| 125 | bit number of the error interrupt in the | ||
| 126 | Error Interrupt Summary Register. | ||
| 127 | |||
| 128 | EXAMPLE 1 | ||
| 129 | /* | ||
| 130 | * mpic interrupt controller with 4 cells per specifier | ||
| 131 | */ | ||
| 132 | mpic: pic@40000 { | ||
| 133 | compatible = "fsl,mpic"; | ||
| 134 | interrupt-controller; | ||
| 135 | #interrupt-cells = <4>; | ||
| 136 | #address-cells = <0>; | ||
| 137 | reg = <0x40000 0x40000>; | ||
| 138 | }; | ||
| 139 | |||
| 140 | EXAMPLE 2 | ||
| 141 | /* | ||
| 142 | * The MPC8544 I2C controller node has an internal | ||
| 143 | * interrupt number of 27. As per the reference manual | ||
| 144 | * this corresponds to interrupt source configuration | ||
| 145 | * registers at 0x5_0560. | ||
| 146 | * | ||
| 147 | * The interrupt source configuration registers begin | ||
| 148 | * at 0x5_0000. | ||
| 149 | * | ||
| 150 | * To compute the interrupt specifier interrupt number | ||
| 151 | * | ||
| 152 | * 0x560 >> 5 = 43 | ||
| 153 | * | ||
| 154 | * The interrupt source configuration registers begin | ||
| 155 | * at 0x5_0000, and so the i2c vector/priority registers | ||
| 156 | * are at 0x5_0560. | ||
| 157 | */ | ||
| 158 | i2c@3000 { | ||
| 159 | #address-cells = <1>; | ||
| 160 | #size-cells = <0>; | ||
| 161 | cell-index = <0>; | ||
| 162 | compatible = "fsl-i2c"; | ||
| 163 | reg = <0x3000 0x100>; | ||
| 164 | interrupts = <43 2>; | ||
| 165 | interrupt-parent = <&mpic>; | ||
| 166 | dfsrr; | ||
| 167 | }; | ||
| 168 | |||
| 169 | |||
| 170 | EXAMPLE 3 | ||
| 171 | /* | ||
| 172 | * Definition of a node defining the 4 | ||
| 173 | * MPIC IPI interrupts. Note the interrupt | ||
| 174 | * type of 2. | ||
| 175 | */ | ||
| 176 | ipi@410a0 { | ||
| 177 | compatible = "fsl,mpic-ipi"; | ||
| 178 | reg = <0x40040 0x10>; | ||
| 179 | interrupts = <0 0 2 0 | ||
| 180 | 1 0 2 0 | ||
| 181 | 2 0 2 0 | ||
| 182 | 3 0 2 0>; | ||
| 183 | }; | ||
| 184 | |||
| 185 | EXAMPLE 4 | ||
| 186 | /* | ||
| 187 | * Definition of a node defining the MPIC | ||
| 188 | * global timers. Note the interrupt | ||
| 189 | * type of 3. | ||
| 190 | */ | ||
| 191 | timer0: timer@41100 { | ||
| 192 | compatible = "fsl,mpic-global-timer"; | ||
| 193 | reg = <0x41100 0x100>; | ||
| 194 | interrupts = <0 0 3 0 | ||
| 195 | 1 0 3 0 | ||
| 196 | 2 0 3 0 | ||
| 197 | 3 0 3 0>; | ||
| 198 | }; | ||
| 199 | |||
| 200 | EXAMPLE 5 | ||
| 201 | /* | ||
| 202 | * Definition of an error interrupt (interrupt type 1). | ||
| 203 | * SoC interrupt number is 16 and the specific error | ||
| 204 | * interrupt bit in the error interrupt summary register | ||
| 205 | * is 23. | ||
| 206 | */ | ||
| 207 | memory-controller@8000 { | ||
| 208 | compatible = "fsl,p4080-memory-controller"; | ||
| 209 | reg = <0x8000 0x1000>; | ||
| 210 | interrupts = <16 2 1 23>; | ||
| 211 | }; | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/msi-pic.txt b/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt index bcc30bac6831..70558c3f3682 100644 --- a/Documentation/powerpc/dts-bindings/fsl/msi-pic.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt | |||
| @@ -5,14 +5,21 @@ Required properties: | |||
| 5 | first is "fsl,CHIP-msi", where CHIP is the processor(mpc8610, mpc8572, | 5 | first is "fsl,CHIP-msi", where CHIP is the processor(mpc8610, mpc8572, |
| 6 | etc.) and the second is "fsl,mpic-msi" or "fsl,ipic-msi" depending on | 6 | etc.) and the second is "fsl,mpic-msi" or "fsl,ipic-msi" depending on |
| 7 | the parent type. | 7 | the parent type. |
| 8 | |||
| 8 | - reg : should contain the address and the length of the shared message | 9 | - reg : should contain the address and the length of the shared message |
| 9 | interrupt register set. | 10 | interrupt register set. |
| 11 | |||
| 10 | - msi-available-ranges: use <start count> style section to define which | 12 | - msi-available-ranges: use <start count> style section to define which |
| 11 | msi interrupt can be used in the 256 msi interrupts. This property is | 13 | msi interrupt can be used in the 256 msi interrupts. This property is |
| 12 | optional, without this, all the 256 MSI interrupts can be used. | 14 | optional, without this, all the 256 MSI interrupts can be used. |
| 15 | Each available range must begin and end on a multiple of 32 (i.e. | ||
| 16 | no splitting an individual MSI register or the associated PIC interrupt). | ||
| 17 | |||
| 13 | - interrupts : each one of the interrupts here is one entry per 32 MSIs, | 18 | - interrupts : each one of the interrupts here is one entry per 32 MSIs, |
| 14 | and routed to the host interrupt controller. the interrupts should | 19 | and routed to the host interrupt controller. the interrupts should |
| 15 | be set as edge sensitive. | 20 | be set as edge sensitive. If msi-available-ranges is present, only |
| 21 | the interrupts that correspond to available ranges shall be present. | ||
| 22 | |||
| 16 | - interrupt-parent: the phandle for the interrupt controller | 23 | - interrupt-parent: the phandle for the interrupt controller |
| 17 | that services interrupts for this device. for 83xx cpu, the interrupts | 24 | that services interrupts for this device. for 83xx cpu, the interrupts |
| 18 | are routed to IPIC, and for 85xx/86xx cpu the interrupts are routed | 25 | are routed to IPIC, and for 85xx/86xx cpu the interrupts are routed |
diff --git a/Documentation/powerpc/dts-bindings/fsl/pmc.txt b/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt index 07256b7ffcaa..07256b7ffcaa 100644 --- a/Documentation/powerpc/dts-bindings/fsl/pmc.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/pmc.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/fsl/sec.txt b/Documentation/devicetree/bindings/powerpc/fsl/sec.txt index 2b6f2d45c45a..2b6f2d45c45a 100644 --- a/Documentation/powerpc/dts-bindings/fsl/sec.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/sec.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/fsl/ssi.txt b/Documentation/devicetree/bindings/powerpc/fsl/ssi.txt index 5ff76c9c57d2..5ff76c9c57d2 100644 --- a/Documentation/powerpc/dts-bindings/fsl/ssi.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/ssi.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/nintendo/gamecube.txt b/Documentation/devicetree/bindings/powerpc/nintendo/gamecube.txt index b558585b1aaf..b558585b1aaf 100644 --- a/Documentation/powerpc/dts-bindings/nintendo/gamecube.txt +++ b/Documentation/devicetree/bindings/powerpc/nintendo/gamecube.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/nintendo/wii.txt b/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt index a7e155a023b8..a7e155a023b8 100644 --- a/Documentation/powerpc/dts-bindings/nintendo/wii.txt +++ b/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt | |||
diff --git a/Documentation/devicetree/bindings/rtc/rtc-cmos.txt b/Documentation/devicetree/bindings/rtc/rtc-cmos.txt new file mode 100644 index 000000000000..7382989b3052 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/rtc-cmos.txt | |||
| @@ -0,0 +1,28 @@ | |||
| 1 | Motorola mc146818 compatible RTC | ||
| 2 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
| 3 | |||
| 4 | Required properties: | ||
| 5 | - compatible : "motorola,mc146818" | ||
| 6 | - reg : should contain registers location and length. | ||
| 7 | |||
| 8 | Optional properties: | ||
| 9 | - interrupts : should contain interrupt. | ||
| 10 | - interrupt-parent : interrupt source phandle. | ||
| 11 | - ctrl-reg : Contains the initial value of the control register also | ||
| 12 | called "Register B". | ||
| 13 | - freq-reg : Contains the initial value of the frequency register also | ||
| 14 | called "Regsiter A". | ||
| 15 | |||
| 16 | "Register A" and "B" are usually initialized by the firmware (BIOS for | ||
| 17 | instance). If this is not done, it can be performed by the driver. | ||
| 18 | |||
| 19 | ISA Example: | ||
| 20 | |||
| 21 | rtc@70 { | ||
| 22 | compatible = "motorola,mc146818"; | ||
| 23 | interrupts = <8 3>; | ||
| 24 | interrupt-parent = <&ioapic1>; | ||
| 25 | ctrl-reg = <2>; | ||
| 26 | freq-reg = <0x26>; | ||
| 27 | reg = <1 0x70 2>; | ||
| 28 | }; | ||
diff --git a/Documentation/devicetree/bindings/serial/altera_jtaguart.txt b/Documentation/devicetree/bindings/serial/altera_jtaguart.txt new file mode 100644 index 000000000000..c152f65f9a28 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/altera_jtaguart.txt | |||
| @@ -0,0 +1,4 @@ | |||
| 1 | Altera JTAG UART | ||
| 2 | |||
| 3 | Required properties: | ||
| 4 | - compatible : should be "ALTR,juart-1.0" | ||
diff --git a/Documentation/devicetree/bindings/serial/altera_uart.txt b/Documentation/devicetree/bindings/serial/altera_uart.txt new file mode 100644 index 000000000000..71cae3f70100 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/altera_uart.txt | |||
| @@ -0,0 +1,7 @@ | |||
| 1 | Altera UART | ||
| 2 | |||
| 3 | Required properties: | ||
| 4 | - compatible : should be "ALTR,uart-1.0" | ||
| 5 | |||
| 6 | Optional properties: | ||
| 7 | - clock-frequency : frequency of the clock input to the UART | ||
diff --git a/Documentation/devicetree/bindings/serio/altera_ps2.txt b/Documentation/devicetree/bindings/serio/altera_ps2.txt new file mode 100644 index 000000000000..4d9eecc2ef7d --- /dev/null +++ b/Documentation/devicetree/bindings/serio/altera_ps2.txt | |||
| @@ -0,0 +1,4 @@ | |||
| 1 | Altera UP PS/2 controller | ||
| 2 | |||
| 3 | Required properties: | ||
| 4 | - compatible : should be "ALTR,ps2-1.0". | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/spi.txt b/Documentation/devicetree/bindings/spi/fsl-spi.txt index 777abd7399d5..777abd7399d5 100644 --- a/Documentation/powerpc/dts-bindings/fsl/spi.txt +++ b/Documentation/devicetree/bindings/spi/fsl-spi.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/spi-bus.txt b/Documentation/devicetree/bindings/spi/spi-bus.txt index e782add2e457..e782add2e457 100644 --- a/Documentation/powerpc/dts-bindings/spi-bus.txt +++ b/Documentation/devicetree/bindings/spi/spi-bus.txt | |||
diff --git a/Documentation/devicetree/bindings/spi/spi_altera.txt b/Documentation/devicetree/bindings/spi/spi_altera.txt new file mode 100644 index 000000000000..dda375943506 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi_altera.txt | |||
| @@ -0,0 +1,4 @@ | |||
| 1 | Altera SPI | ||
| 2 | |||
| 3 | Required properties: | ||
| 4 | - compatible : should be "ALTR,spi-1.0". | ||
diff --git a/Documentation/devicetree/bindings/spi/spi_oc_tiny.txt b/Documentation/devicetree/bindings/spi/spi_oc_tiny.txt new file mode 100644 index 000000000000..d95c0b367a04 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi_oc_tiny.txt | |||
| @@ -0,0 +1,12 @@ | |||
| 1 | OpenCores tiny SPI | ||
| 2 | |||
| 3 | Required properties: | ||
| 4 | - compatible : should be "opencores,tiny-spi-rtlsvn2". | ||
| 5 | - gpios : should specify GPIOs used for chipselect. | ||
| 6 | Optional properties: | ||
| 7 | - clock-frequency : input clock frequency to the core. | ||
| 8 | - baud-width: width, in bits, of the programmable divider used to scale | ||
| 9 | the input clock to SCLK. | ||
| 10 | |||
| 11 | The clock-frequency and baud-width properties are needed only if the divider | ||
| 12 | is programmable. They are not needed if the divider is fixed. | ||
diff --git a/Documentation/powerpc/dts-bindings/fsl/usb.txt b/Documentation/devicetree/bindings/usb/fsl-usb.txt index bd5723f0b67e..bd5723f0b67e 100644 --- a/Documentation/powerpc/dts-bindings/fsl/usb.txt +++ b/Documentation/devicetree/bindings/usb/fsl-usb.txt | |||
diff --git a/Documentation/powerpc/dts-bindings/usb-ehci.txt b/Documentation/devicetree/bindings/usb/usb-ehci.txt index fa18612f757b..fa18612f757b 100644 --- a/Documentation/powerpc/dts-bindings/usb-ehci.txt +++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt | |||
diff --git a/Documentation/devicetree/bindings/x86/ce4100.txt b/Documentation/devicetree/bindings/x86/ce4100.txt new file mode 100644 index 000000000000..b49ae593a60b --- /dev/null +++ b/Documentation/devicetree/bindings/x86/ce4100.txt | |||
| @@ -0,0 +1,38 @@ | |||
| 1 | CE4100 Device Tree Bindings | ||
| 2 | --------------------------- | ||
| 3 | |||
| 4 | The CE4100 SoC uses for in core peripherals the following compatible | ||
| 5 | format: <vendor>,<chip>-<device>. | ||
| 6 | Many of the "generic" devices like HPET or IO APIC have the ce4100 | ||
| 7 | name in their compatible property because they first appeared in this | ||
| 8 | SoC. | ||
| 9 | |||
| 10 | The CPU node | ||
| 11 | ------------ | ||
| 12 | cpu@0 { | ||
| 13 | device_type = "cpu"; | ||
| 14 | compatible = "intel,ce4100"; | ||
| 15 | reg = <0>; | ||
| 16 | lapic = <&lapic0>; | ||
| 17 | }; | ||
| 18 | |||
| 19 | The reg property describes the CPU number. The lapic property points to | ||
| 20 | the local APIC timer. | ||
| 21 | |||
| 22 | The SoC node | ||
| 23 | ------------ | ||
| 24 | |||
| 25 | This node describes the in-core peripherals. Required property: | ||
| 26 | compatible = "intel,ce4100-cp"; | ||
| 27 | |||
| 28 | The PCI node | ||
| 29 | ------------ | ||
| 30 | This node describes the PCI bus on the SoC. Its property should be | ||
| 31 | compatible = "intel,ce4100-pci", "pci"; | ||
| 32 | |||
| 33 | If the OS is using the IO-APIC for interrupt routing then the reported | ||
| 34 | interrupt numbers for devices is no longer true. In order to obtain the | ||
| 35 | correct interrupt number, the child node which represents the device has | ||
| 36 | to contain the interrupt property. Besides the interrupt property it has | ||
| 37 | to contain at least the reg property containing the PCI bus address and | ||
| 38 | compatible property according to "PCI Bus Binding Revision 2.1". | ||
diff --git a/Documentation/devicetree/bindings/x86/interrupt.txt b/Documentation/devicetree/bindings/x86/interrupt.txt new file mode 100644 index 000000000000..7d19f494f19a --- /dev/null +++ b/Documentation/devicetree/bindings/x86/interrupt.txt | |||
| @@ -0,0 +1,26 @@ | |||
| 1 | Interrupt chips | ||
| 2 | --------------- | ||
| 3 | |||
| 4 | * Intel I/O Advanced Programmable Interrupt Controller (IO APIC) | ||
| 5 | |||
| 6 | Required properties: | ||
| 7 | -------------------- | ||
| 8 | compatible = "intel,ce4100-ioapic"; | ||
| 9 | #interrupt-cells = <2>; | ||
| 10 | |||
| 11 | Device's interrupt property: | ||
| 12 | |||
| 13 | interrupts = <P S>; | ||
| 14 | |||
| 15 | The first number (P) represents the interrupt pin which is wired to the | ||
| 16 | IO APIC. The second number (S) represents the sense of interrupt which | ||
| 17 | should be configured and can be one of: | ||
| 18 | 0 - Edge Rising | ||
| 19 | 1 - Level Low | ||
| 20 | 2 - Level High | ||
| 21 | 3 - Edge Falling | ||
| 22 | |||
| 23 | * Local APIC | ||
| 24 | Required property: | ||
| 25 | |||
| 26 | compatible = "intel,ce4100-lapic"; | ||
diff --git a/Documentation/devicetree/bindings/x86/timer.txt b/Documentation/devicetree/bindings/x86/timer.txt new file mode 100644 index 000000000000..c688af58e3bd --- /dev/null +++ b/Documentation/devicetree/bindings/x86/timer.txt | |||
| @@ -0,0 +1,6 @@ | |||
| 1 | Timers | ||
| 2 | ------ | ||
| 3 | |||
| 4 | * High Precision Event Timer (HPET) | ||
| 5 | Required property: | ||
| 6 | compatible = "intel,ce4100-hpet"; | ||
diff --git a/Documentation/powerpc/dts-bindings/xilinx.txt b/Documentation/devicetree/bindings/xilinx.txt index 299d0923537b..299d0923537b 100644 --- a/Documentation/powerpc/dts-bindings/xilinx.txt +++ b/Documentation/devicetree/bindings/xilinx.txt | |||
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/devicetree/booting-without-of.txt index 7400d7555dc3..50619a0720a8 100644 --- a/Documentation/powerpc/booting-without-of.txt +++ b/Documentation/devicetree/booting-without-of.txt | |||
| @@ -13,7 +13,7 @@ Table of Contents | |||
| 13 | 13 | ||
| 14 | I - Introduction | 14 | I - Introduction |
| 15 | 1) Entry point for arch/powerpc | 15 | 1) Entry point for arch/powerpc |
| 16 | 2) Board support | 16 | 2) Entry point for arch/x86 |
| 17 | 17 | ||
| 18 | II - The DT block format | 18 | II - The DT block format |
| 19 | 1) Header | 19 | 1) Header |
| @@ -41,13 +41,6 @@ Table of Contents | |||
| 41 | VI - System-on-a-chip devices and nodes | 41 | VI - System-on-a-chip devices and nodes |
| 42 | 1) Defining child nodes of an SOC | 42 | 1) Defining child nodes of an SOC |
| 43 | 2) Representing devices without a current OF specification | 43 | 2) Representing devices without a current OF specification |
| 44 | a) PHY nodes | ||
| 45 | b) Interrupt controllers | ||
| 46 | c) 4xx/Axon EMAC ethernet nodes | ||
| 47 | d) Xilinx IP cores | ||
| 48 | e) USB EHCI controllers | ||
| 49 | f) MDIO on GPIOs | ||
| 50 | g) SPI busses | ||
| 51 | 44 | ||
| 52 | VII - Specifying interrupt information for devices | 45 | VII - Specifying interrupt information for devices |
| 53 | 1) interrupts property | 46 | 1) interrupts property |
| @@ -123,7 +116,7 @@ Revision Information | |||
| 123 | I - Introduction | 116 | I - Introduction |
| 124 | ================ | 117 | ================ |
| 125 | 118 | ||
| 126 | During the recent development of the Linux/ppc64 kernel, and more | 119 | During the development of the Linux/ppc64 kernel, and more |
| 127 | specifically, the addition of new platform types outside of the old | 120 | specifically, the addition of new platform types outside of the old |
| 128 | IBM pSeries/iSeries pair, it was decided to enforce some strict rules | 121 | IBM pSeries/iSeries pair, it was decided to enforce some strict rules |
| 129 | regarding the kernel entry and bootloader <-> kernel interfaces, in | 122 | regarding the kernel entry and bootloader <-> kernel interfaces, in |
| @@ -145,8 +138,8 @@ and properties to be present. This will be described in detail in | |||
| 145 | section III, but, for example, the kernel does not require you to | 138 | section III, but, for example, the kernel does not require you to |
| 146 | create a node for every PCI device in the system. It is a requirement | 139 | create a node for every PCI device in the system. It is a requirement |
| 147 | to have a node for PCI host bridges in order to provide interrupt | 140 | to have a node for PCI host bridges in order to provide interrupt |
| 148 | routing informations and memory/IO ranges, among others. It is also | 141 | routing information and memory/IO ranges, among others. It is also |
| 149 | recommended to define nodes for on chip devices and other busses that | 142 | recommended to define nodes for on chip devices and other buses that |
| 150 | don't specifically fit in an existing OF specification. This creates a | 143 | don't specifically fit in an existing OF specification. This creates a |
| 151 | great flexibility in the way the kernel can then probe those and match | 144 | great flexibility in the way the kernel can then probe those and match |
| 152 | drivers to device, without having to hard code all sorts of tables. It | 145 | drivers to device, without having to hard code all sorts of tables. It |
| @@ -158,7 +151,7 @@ it with special cases. | |||
| 158 | 1) Entry point for arch/powerpc | 151 | 1) Entry point for arch/powerpc |
| 159 | ------------------------------- | 152 | ------------------------------- |
| 160 | 153 | ||
| 161 | There is one and one single entry point to the kernel, at the start | 154 | There is one single entry point to the kernel, at the start |
| 162 | of the kernel image. That entry point supports two calling | 155 | of the kernel image. That entry point supports two calling |
| 163 | conventions: | 156 | conventions: |
| 164 | 157 | ||
| @@ -210,12 +203,6 @@ it with special cases. | |||
| 210 | with all CPUs. The way to do that with method b) will be | 203 | with all CPUs. The way to do that with method b) will be |
| 211 | described in a later revision of this document. | 204 | described in a later revision of this document. |
| 212 | 205 | ||
| 213 | |||
| 214 | 2) Board support | ||
| 215 | ---------------- | ||
| 216 | |||
| 217 | 64-bit kernels: | ||
| 218 | |||
| 219 | Board supports (platforms) are not exclusive config options. An | 206 | Board supports (platforms) are not exclusive config options. An |
| 220 | arbitrary set of board supports can be built in a single kernel | 207 | arbitrary set of board supports can be built in a single kernel |
| 221 | image. The kernel will "know" what set of functions to use for a | 208 | image. The kernel will "know" what set of functions to use for a |
| @@ -234,48 +221,30 @@ it with special cases. | |||
| 234 | containing the various callbacks that the generic code will | 221 | containing the various callbacks that the generic code will |
| 235 | use to get to your platform specific code | 222 | use to get to your platform specific code |
| 236 | 223 | ||
| 237 | c) Add a reference to your "ppc_md" structure in the | 224 | A kernel image may support multiple platforms, but only if the |
| 238 | "machines" table in arch/powerpc/kernel/setup_64.c if you are | ||
| 239 | a 64-bit platform. | ||
| 240 | |||
| 241 | d) request and get assigned a platform number (see PLATFORM_* | ||
| 242 | constants in arch/powerpc/include/asm/processor.h | ||
| 243 | |||
| 244 | 32-bit embedded kernels: | ||
| 245 | |||
| 246 | Currently, board support is essentially an exclusive config option. | ||
| 247 | The kernel is configured for a single platform. Part of the reason | ||
| 248 | for this is to keep kernels on embedded systems small and efficient; | ||
| 249 | part of this is due to the fact the code is already that way. In the | ||
| 250 | future, a kernel may support multiple platforms, but only if the | ||
| 251 | platforms feature the same core architecture. A single kernel build | 225 | platforms feature the same core architecture. A single kernel build |
| 252 | cannot support both configurations with Book E and configurations | 226 | cannot support both configurations with Book E and configurations |
| 253 | with classic Powerpc architectures. | 227 | with classic Powerpc architectures. |
| 254 | 228 | ||
| 255 | 32-bit embedded platforms that are moved into arch/powerpc using a | 229 | 2) Entry point for arch/x86 |
| 256 | flattened device tree should adopt the merged tree practice of | 230 | ------------------------------- |
| 257 | setting ppc_md up dynamically, even though the kernel is currently | ||
| 258 | built with support for only a single platform at a time. This allows | ||
| 259 | unification of the setup code, and will make it easier to go to a | ||
| 260 | multiple-platform-support model in the future. | ||
| 261 | |||
| 262 | NOTE: I believe the above will be true once Ben's done with the merge | ||
| 263 | of the boot sequences.... someone speak up if this is wrong! | ||
| 264 | |||
| 265 | To add a 32-bit embedded platform support, follow the instructions | ||
| 266 | for 64-bit platforms above, with the exception that the Kconfig | ||
| 267 | option should be set up such that the kernel builds exclusively for | ||
| 268 | the platform selected. The processor type for the platform should | ||
| 269 | enable another config option to select the specific board | ||
| 270 | supported. | ||
| 271 | |||
| 272 | NOTE: If Ben doesn't merge the setup files, may need to change this to | ||
| 273 | point to setup_32.c | ||
| 274 | 231 | ||
| 232 | There is one single 32bit entry point to the kernel at code32_start, | ||
| 233 | the decompressor (the real mode entry point goes to the same 32bit | ||
| 234 | entry point once it switched into protected mode). That entry point | ||
| 235 | supports one calling convention which is documented in | ||
| 236 | Documentation/x86/boot.txt | ||
| 237 | The physical pointer to the device-tree block (defined in chapter II) | ||
| 238 | is passed via setup_data which requires at least boot protocol 2.09. | ||
| 239 | The type filed is defined as | ||
| 275 | 240 | ||
| 276 | I will describe later the boot process and various callbacks that | 241 | #define SETUP_DTB 2 |
| 277 | your platform should implement. | ||
| 278 | 242 | ||
| 243 | This device-tree is used as an extension to the "boot page". As such it | ||
| 244 | does not parse / consider data which is already covered by the boot | ||
| 245 | page. This includes memory size, reserved ranges, command line arguments | ||
| 246 | or initrd address. It simply holds information which can not be retrieved | ||
| 247 | otherwise like interrupt routing or a list of devices behind an I2C bus. | ||
| 279 | 248 | ||
| 280 | II - The DT block format | 249 | II - The DT block format |
| 281 | ======================== | 250 | ======================== |
| @@ -300,8 +269,8 @@ the block to RAM before passing it to the kernel. | |||
| 300 | 1) Header | 269 | 1) Header |
| 301 | --------- | 270 | --------- |
| 302 | 271 | ||
| 303 | The kernel is entered with r3 pointing to an area of memory that is | 272 | The kernel is passed the physical address pointing to an area of memory |
| 304 | roughly described in arch/powerpc/include/asm/prom.h by the structure | 273 | that is roughly described in include/linux/of_fdt.h by the structure |
| 305 | boot_param_header: | 274 | boot_param_header: |
| 306 | 275 | ||
| 307 | struct boot_param_header { | 276 | struct boot_param_header { |
| @@ -339,7 +308,7 @@ struct boot_param_header { | |||
| 339 | All values in this header are in big endian format, the various | 308 | All values in this header are in big endian format, the various |
| 340 | fields in this header are defined more precisely below. All | 309 | fields in this header are defined more precisely below. All |
| 341 | "offset" values are in bytes from the start of the header; that is | 310 | "offset" values are in bytes from the start of the header; that is |
| 342 | from the value of r3. | 311 | from the physical base address of the device tree block. |
| 343 | 312 | ||
| 344 | - magic | 313 | - magic |
| 345 | 314 | ||
| @@ -416,7 +385,7 @@ struct boot_param_header { | |||
| 416 | among others, by kexec. If you are on an SMP system, this value | 385 | among others, by kexec. If you are on an SMP system, this value |
| 417 | should match the content of the "reg" property of the CPU node in | 386 | should match the content of the "reg" property of the CPU node in |
| 418 | the device-tree corresponding to the CPU calling the kernel entry | 387 | the device-tree corresponding to the CPU calling the kernel entry |
| 419 | point (see further chapters for more informations on the required | 388 | point (see further chapters for more information on the required |
| 420 | device-tree contents) | 389 | device-tree contents) |
| 421 | 390 | ||
| 422 | - size_dt_strings | 391 | - size_dt_strings |
| @@ -437,7 +406,7 @@ struct boot_param_header { | |||
| 437 | 406 | ||
| 438 | 407 | ||
| 439 | ------------------------------ | 408 | ------------------------------ |
| 440 | r3 -> | struct boot_param_header | | 409 | base -> | struct boot_param_header | |
| 441 | ------------------------------ | 410 | ------------------------------ |
| 442 | | (alignment gap) (*) | | 411 | | (alignment gap) (*) | |
| 443 | ------------------------------ | 412 | ------------------------------ |
| @@ -457,7 +426,7 @@ struct boot_param_header { | |||
| 457 | -----> ------------------------------ | 426 | -----> ------------------------------ |
| 458 | | | 427 | | |
| 459 | | | 428 | | |
| 460 | --- (r3 + totalsize) | 429 | --- (base + totalsize) |
| 461 | 430 | ||
| 462 | (*) The alignment gaps are not necessarily present; their presence | 431 | (*) The alignment gaps are not necessarily present; their presence |
| 463 | and size are dependent on the various alignment requirements of | 432 | and size are dependent on the various alignment requirements of |
| @@ -500,7 +469,7 @@ the device-tree structure. It is typically used to represent "path" in | |||
| 500 | the device-tree. More details about the actual format of these will be | 469 | the device-tree. More details about the actual format of these will be |
| 501 | below. | 470 | below. |
| 502 | 471 | ||
| 503 | The kernel powerpc generic code does not make any formal use of the | 472 | The kernel generic code does not make any formal use of the |
| 504 | unit address (though some board support code may do) so the only real | 473 | unit address (though some board support code may do) so the only real |
| 505 | requirement here for the unit address is to ensure uniqueness of | 474 | requirement here for the unit address is to ensure uniqueness of |
| 506 | the node unit name at a given level of the tree. Nodes with no notion | 475 | the node unit name at a given level of the tree. Nodes with no notion |
| @@ -518,20 +487,21 @@ path to the root node is "/". | |||
| 518 | 487 | ||
| 519 | Every node which actually represents an actual device (that is, a node | 488 | Every node which actually represents an actual device (that is, a node |
| 520 | which isn't only a virtual "container" for more nodes, like "/cpus" | 489 | which isn't only a virtual "container" for more nodes, like "/cpus" |
| 521 | is) is also required to have a "device_type" property indicating the | 490 | is) is also required to have a "compatible" property indicating the |
| 522 | type of node . | 491 | specific hardware and an optional list of devices it is fully |
| 492 | backwards compatible with. | ||
| 523 | 493 | ||
| 524 | Finally, every node that can be referenced from a property in another | 494 | Finally, every node that can be referenced from a property in another |
| 525 | node is required to have a "linux,phandle" property. Real open | 495 | node is required to have either a "phandle" or a "linux,phandle" |
| 526 | firmware implementations provide a unique "phandle" value for every | 496 | property. Real Open Firmware implementations provide a unique |
| 527 | node that the "prom_init()" trampoline code turns into | 497 | "phandle" value for every node that the "prom_init()" trampoline code |
| 528 | "linux,phandle" properties. However, this is made optional if the | 498 | turns into "linux,phandle" properties. However, this is made optional |
| 529 | flattened device tree is used directly. An example of a node | 499 | if the flattened device tree is used directly. An example of a node |
| 530 | referencing another node via "phandle" is when laying out the | 500 | referencing another node via "phandle" is when laying out the |
| 531 | interrupt tree which will be described in a further version of this | 501 | interrupt tree which will be described in a further version of this |
| 532 | document. | 502 | document. |
| 533 | 503 | ||
| 534 | This "linux, phandle" property is a 32-bit value that uniquely | 504 | The "phandle" property is a 32-bit value that uniquely |
| 535 | identifies a node. You are free to use whatever values or system of | 505 | identifies a node. You are free to use whatever values or system of |
| 536 | values, internal pointers, or whatever to generate these, the only | 506 | values, internal pointers, or whatever to generate these, the only |
| 537 | requirement is that every node for which you provide that property has | 507 | requirement is that every node for which you provide that property has |
| @@ -583,7 +553,7 @@ looks like in practice. | |||
| 583 | 553 | ||
| 584 | This tree is almost a minimal tree. It pretty much contains the | 554 | This tree is almost a minimal tree. It pretty much contains the |
| 585 | minimal set of required nodes and properties to boot a linux kernel; | 555 | minimal set of required nodes and properties to boot a linux kernel; |
| 586 | that is, some basic model informations at the root, the CPUs, and the | 556 | that is, some basic model information at the root, the CPUs, and the |
| 587 | physical memory layout. It also includes misc information passed | 557 | physical memory layout. It also includes misc information passed |
| 588 | through /chosen, like in this example, the platform type (mandatory) | 558 | through /chosen, like in this example, the platform type (mandatory) |
| 589 | and the kernel command line arguments (optional). | 559 | and the kernel command line arguments (optional). |
| @@ -694,7 +664,7 @@ made of 3 cells, the bottom two containing the actual address itself | |||
| 694 | while the top cell contains address space indication, flags, and pci | 664 | while the top cell contains address space indication, flags, and pci |
| 695 | bus & device numbers. | 665 | bus & device numbers. |
| 696 | 666 | ||
| 697 | For busses that support dynamic allocation, it's the accepted practice | 667 | For buses that support dynamic allocation, it's the accepted practice |
| 698 | to then not provide the address in "reg" (keep it 0) though while | 668 | to then not provide the address in "reg" (keep it 0) though while |
| 699 | providing a flag indicating the address is dynamically allocated, and | 669 | providing a flag indicating the address is dynamically allocated, and |
| 700 | then, to provide a separate "assigned-addresses" property that | 670 | then, to provide a separate "assigned-addresses" property that |
| @@ -711,7 +681,7 @@ prom_parse.c file of the recent kernels for your bus type. | |||
| 711 | The "reg" property only defines addresses and sizes (if #size-cells is | 681 | The "reg" property only defines addresses and sizes (if #size-cells is |
| 712 | non-0) within a given bus. In order to translate addresses upward | 682 | non-0) within a given bus. In order to translate addresses upward |
| 713 | (that is into parent bus addresses, and possibly into CPU physical | 683 | (that is into parent bus addresses, and possibly into CPU physical |
| 714 | addresses), all busses must contain a "ranges" property. If the | 684 | addresses), all buses must contain a "ranges" property. If the |
| 715 | "ranges" property is missing at a given level, it's assumed that | 685 | "ranges" property is missing at a given level, it's assumed that |
| 716 | translation isn't possible, i.e., the registers are not visible on the | 686 | translation isn't possible, i.e., the registers are not visible on the |
| 717 | parent bus. The format of the "ranges" property for a bus is a list | 687 | parent bus. The format of the "ranges" property for a bus is a list |
| @@ -727,9 +697,9 @@ example, for a PCI host controller, that would be a CPU address. For a | |||
| 727 | PCI<->ISA bridge, that would be a PCI address. It defines the base | 697 | PCI<->ISA bridge, that would be a PCI address. It defines the base |
| 728 | address in the parent bus where the beginning of that range is mapped. | 698 | address in the parent bus where the beginning of that range is mapped. |
| 729 | 699 | ||
| 730 | For a new 64-bit powerpc board, I recommend either the 2/2 format or | 700 | For new 64-bit board support, I recommend either the 2/2 format or |
| 731 | Apple's 2/1 format which is slightly more compact since sizes usually | 701 | Apple's 2/1 format which is slightly more compact since sizes usually |
| 732 | fit in a single 32-bit word. New 32-bit powerpc boards should use a | 702 | fit in a single 32-bit word. New 32-bit board support should use a |
| 733 | 1/1 format, unless the processor supports physical addresses greater | 703 | 1/1 format, unless the processor supports physical addresses greater |
| 734 | than 32-bits, in which case a 2/1 format is recommended. | 704 | than 32-bits, in which case a 2/1 format is recommended. |
| 735 | 705 | ||
| @@ -754,7 +724,7 @@ of their actual names. | |||
| 754 | While earlier users of Open Firmware like OldWorld macintoshes tended | 724 | While earlier users of Open Firmware like OldWorld macintoshes tended |
| 755 | to use the actual device name for the "name" property, it's nowadays | 725 | to use the actual device name for the "name" property, it's nowadays |
| 756 | considered a good practice to use a name that is closer to the device | 726 | considered a good practice to use a name that is closer to the device |
| 757 | class (often equal to device_type). For example, nowadays, ethernet | 727 | class (often equal to device_type). For example, nowadays, Ethernet |
| 758 | controllers are named "ethernet", an additional "model" property | 728 | controllers are named "ethernet", an additional "model" property |
| 759 | defining precisely the chip type/model, and "compatible" property | 729 | defining precisely the chip type/model, and "compatible" property |
| 760 | defining the family in case a single driver can driver more than one | 730 | defining the family in case a single driver can driver more than one |
| @@ -772,7 +742,7 @@ is present). | |||
| 772 | 4) Note about node and property names and character set | 742 | 4) Note about node and property names and character set |
| 773 | ------------------------------------------------------- | 743 | ------------------------------------------------------- |
| 774 | 744 | ||
| 775 | While open firmware provides more flexible usage of 8859-1, this | 745 | While Open Firmware provides more flexible usage of 8859-1, this |
| 776 | specification enforces more strict rules. Nodes and properties should | 746 | specification enforces more strict rules. Nodes and properties should |
| 777 | be comprised only of ASCII characters 'a' to 'z', '0' to | 747 | be comprised only of ASCII characters 'a' to 'z', '0' to |
| 778 | '9', ',', '.', '_', '+', '#', '?', and '-'. Node names additionally | 748 | '9', ',', '.', '_', '+', '#', '?', and '-'. Node names additionally |
| @@ -792,7 +762,7 @@ address which can extend beyond that limit. | |||
| 792 | -------------------------------- | 762 | -------------------------------- |
| 793 | These are all that are currently required. However, it is strongly | 763 | These are all that are currently required. However, it is strongly |
| 794 | recommended that you expose PCI host bridges as documented in the | 764 | recommended that you expose PCI host bridges as documented in the |
| 795 | PCI binding to open firmware, and your interrupt tree as documented | 765 | PCI binding to Open Firmware, and your interrupt tree as documented |
| 796 | in OF interrupt tree specification. | 766 | in OF interrupt tree specification. |
| 797 | 767 | ||
| 798 | a) The root node | 768 | a) The root node |
| @@ -802,20 +772,12 @@ address which can extend beyond that limit. | |||
| 802 | - model : this is your board name/model | 772 | - model : this is your board name/model |
| 803 | - #address-cells : address representation for "root" devices | 773 | - #address-cells : address representation for "root" devices |
| 804 | - #size-cells: the size representation for "root" devices | 774 | - #size-cells: the size representation for "root" devices |
| 805 | - device_type : This property shouldn't be necessary. However, if | ||
| 806 | you decide to create a device_type for your root node, make sure it | ||
| 807 | is _not_ "chrp" unless your platform is a pSeries or PAPR compliant | ||
| 808 | one for 64-bit, or a CHRP-type machine for 32-bit as this will | ||
| 809 | matched by the kernel this way. | ||
| 810 | |||
| 811 | Additionally, some recommended properties are: | ||
| 812 | |||
| 813 | - compatible : the board "family" generally finds its way here, | 775 | - compatible : the board "family" generally finds its way here, |
| 814 | for example, if you have 2 board models with a similar layout, | 776 | for example, if you have 2 board models with a similar layout, |
| 815 | that typically get driven by the same platform code in the | 777 | that typically get driven by the same platform code in the |
| 816 | kernel, you would use a different "model" property but put a | 778 | kernel, you would specify the exact board model in the |
| 817 | value in "compatible". The kernel doesn't directly use that | 779 | compatible property followed by an entry that represents the SoC |
| 818 | value but it is generally useful. | 780 | model. |
| 819 | 781 | ||
| 820 | The root node is also generally where you add additional properties | 782 | The root node is also generally where you add additional properties |
| 821 | specific to your board like the serial number if any, that sort of | 783 | specific to your board like the serial number if any, that sort of |
| @@ -841,8 +803,11 @@ address which can extend beyond that limit. | |||
| 841 | 803 | ||
| 842 | So under /cpus, you are supposed to create a node for every CPU on | 804 | So under /cpus, you are supposed to create a node for every CPU on |
| 843 | the machine. There is no specific restriction on the name of the | 805 | the machine. There is no specific restriction on the name of the |
| 844 | CPU, though It's common practice to call it PowerPC,<name>. For | 806 | CPU, though it's common to call it <architecture>,<core>. For |
| 845 | example, Apple uses PowerPC,G5 while IBM uses PowerPC,970FX. | 807 | example, Apple uses PowerPC,G5 while IBM uses PowerPC,970FX. |
| 808 | However, the Generic Names convention suggests that it would be | ||
| 809 | better to simply use 'cpu' for each cpu node and use the compatible | ||
| 810 | property to identify the specific cpu core. | ||
| 846 | 811 | ||
| 847 | Required properties: | 812 | Required properties: |
| 848 | 813 | ||
| @@ -923,7 +888,7 @@ compatibility. | |||
| 923 | 888 | ||
| 924 | e) The /chosen node | 889 | e) The /chosen node |
| 925 | 890 | ||
| 926 | This node is a bit "special". Normally, that's where open firmware | 891 | This node is a bit "special". Normally, that's where Open Firmware |
| 927 | puts some variable environment information, like the arguments, or | 892 | puts some variable environment information, like the arguments, or |
| 928 | the default input/output devices. | 893 | the default input/output devices. |
| 929 | 894 | ||
| @@ -940,11 +905,7 @@ compatibility. | |||
| 940 | console device if any. Typically, if you have serial devices on | 905 | console device if any. Typically, if you have serial devices on |
| 941 | your board, you may want to put the full path to the one set as | 906 | your board, you may want to put the full path to the one set as |
| 942 | the default console in the firmware here, for the kernel to pick | 907 | the default console in the firmware here, for the kernel to pick |
| 943 | it up as its own default console. If you look at the function | 908 | it up as its own default console. |
| 944 | set_preferred_console() in arch/ppc64/kernel/setup.c, you'll see | ||
| 945 | that the kernel tries to find out the default console and has | ||
| 946 | knowledge of various types like 8250 serial ports. You may want | ||
| 947 | to extend this function to add your own. | ||
| 948 | 909 | ||
| 949 | Note that u-boot creates and fills in the chosen node for platforms | 910 | Note that u-boot creates and fills in the chosen node for platforms |
| 950 | that use it. | 911 | that use it. |
| @@ -955,23 +916,23 @@ compatibility. | |||
| 955 | 916 | ||
| 956 | f) the /soc<SOCname> node | 917 | f) the /soc<SOCname> node |
| 957 | 918 | ||
| 958 | This node is used to represent a system-on-a-chip (SOC) and must be | 919 | This node is used to represent a system-on-a-chip (SoC) and must be |
| 959 | present if the processor is a SOC. The top-level soc node contains | 920 | present if the processor is a SoC. The top-level soc node contains |
| 960 | information that is global to all devices on the SOC. The node name | 921 | information that is global to all devices on the SoC. The node name |
| 961 | should contain a unit address for the SOC, which is the base address | 922 | should contain a unit address for the SoC, which is the base address |
| 962 | of the memory-mapped register set for the SOC. The name of an soc | 923 | of the memory-mapped register set for the SoC. The name of an SoC |
| 963 | node should start with "soc", and the remainder of the name should | 924 | node should start with "soc", and the remainder of the name should |
| 964 | represent the part number for the soc. For example, the MPC8540's | 925 | represent the part number for the soc. For example, the MPC8540's |
| 965 | soc node would be called "soc8540". | 926 | soc node would be called "soc8540". |
| 966 | 927 | ||
| 967 | Required properties: | 928 | Required properties: |
| 968 | 929 | ||
| 969 | - device_type : Should be "soc" | ||
| 970 | - ranges : Should be defined as specified in 1) to describe the | 930 | - ranges : Should be defined as specified in 1) to describe the |
| 971 | translation of SOC addresses for memory mapped SOC registers. | 931 | translation of SoC addresses for memory mapped SoC registers. |
| 972 | - bus-frequency: Contains the bus frequency for the SOC node. | 932 | - bus-frequency: Contains the bus frequency for the SoC node. |
| 973 | Typically, the value of this field is filled in by the boot | 933 | Typically, the value of this field is filled in by the boot |
| 974 | loader. | 934 | loader. |
| 935 | - compatible : Exact model of the SoC | ||
| 975 | 936 | ||
| 976 | 937 | ||
| 977 | Recommended properties: | 938 | Recommended properties: |
| @@ -1155,12 +1116,13 @@ while all this has been defined and implemented. | |||
| 1155 | 1116 | ||
| 1156 | - An example of code for iterating nodes & retrieving properties | 1117 | - An example of code for iterating nodes & retrieving properties |
| 1157 | directly from the flattened tree format can be found in the kernel | 1118 | directly from the flattened tree format can be found in the kernel |
| 1158 | file arch/ppc64/kernel/prom.c, look at scan_flat_dt() function, | 1119 | file drivers/of/fdt.c. Look at the of_scan_flat_dt() function, |
| 1159 | its usage in early_init_devtree(), and the corresponding various | 1120 | its usage in early_init_devtree(), and the corresponding various |
| 1160 | early_init_dt_scan_*() callbacks. That code can be re-used in a | 1121 | early_init_dt_scan_*() callbacks. That code can be re-used in a |
| 1161 | GPL bootloader, and as the author of that code, I would be happy | 1122 | GPL bootloader, and as the author of that code, I would be happy |
| 1162 | to discuss possible free licensing to any vendor who wishes to | 1123 | to discuss possible free licensing to any vendor who wishes to |
| 1163 | integrate all or part of this code into a non-GPL bootloader. | 1124 | integrate all or part of this code into a non-GPL bootloader. |
| 1125 | (reference needed; who is 'I' here? ---gcl Jan 31, 2011) | ||
| 1164 | 1126 | ||
| 1165 | 1127 | ||
| 1166 | 1128 | ||
| @@ -1203,18 +1165,19 @@ MPC8540. | |||
| 1203 | 2) Representing devices without a current OF specification | 1165 | 2) Representing devices without a current OF specification |
| 1204 | ---------------------------------------------------------- | 1166 | ---------------------------------------------------------- |
| 1205 | 1167 | ||
| 1206 | Currently, there are many devices on SOCs that do not have a standard | 1168 | Currently, there are many devices on SoCs that do not have a standard |
| 1207 | representation pre-defined as part of the open firmware | 1169 | representation defined as part of the Open Firmware specifications, |
| 1208 | specifications, mainly because the boards that contain these SOCs are | 1170 | mainly because the boards that contain these SoCs are not currently |
| 1209 | not currently booted using open firmware. This section contains | 1171 | booted using Open Firmware. Binding documentation for new devices |
| 1210 | descriptions for the SOC devices for which new nodes have been | 1172 | should be added to the Documentation/devicetree/bindings directory. |
| 1211 | defined; this list will expand as more and more SOC-containing | 1173 | That directory will expand as device tree support is added to more and |
| 1212 | platforms are moved over to use the flattened-device-tree model. | 1174 | more SoCs. |
| 1175 | |||
| 1213 | 1176 | ||
| 1214 | VII - Specifying interrupt information for devices | 1177 | VII - Specifying interrupt information for devices |
| 1215 | =================================================== | 1178 | =================================================== |
| 1216 | 1179 | ||
| 1217 | The device tree represents the busses and devices of a hardware | 1180 | The device tree represents the buses and devices of a hardware |
| 1218 | system in a form similar to the physical bus topology of the | 1181 | system in a form similar to the physical bus topology of the |
| 1219 | hardware. | 1182 | hardware. |
| 1220 | 1183 | ||
diff --git a/Documentation/dvb/README.dvb-usb b/Documentation/dvb/README.dvb-usb index c8238e44ed6b..c4d963a67d6f 100644 --- a/Documentation/dvb/README.dvb-usb +++ b/Documentation/dvb/README.dvb-usb | |||
| @@ -138,7 +138,7 @@ Hotplug is able to load the driver, when it is needed (because you plugged | |||
| 138 | in the device). | 138 | in the device). |
| 139 | 139 | ||
| 140 | If you want to enable debug output, you have to load the driver manually and | 140 | If you want to enable debug output, you have to load the driver manually and |
| 141 | from withing the dvb-kernel cvs repository. | 141 | from within the dvb-kernel cvs repository. |
| 142 | 142 | ||
| 143 | first have a look, which debug level are available: | 143 | first have a look, which debug level are available: |
| 144 | 144 | ||
diff --git a/Documentation/dvb/ci.txt b/Documentation/dvb/ci.txt index 4a0c2b56e690..6c3bda50f7dc 100644 --- a/Documentation/dvb/ci.txt +++ b/Documentation/dvb/ci.txt | |||
| @@ -47,7 +47,7 @@ so on. | |||
| 47 | 47 | ||
| 48 | * CI modules that are supported | 48 | * CI modules that are supported |
| 49 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 49 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 50 | The CI module support is largely dependant upon the firmware on the cards | 50 | The CI module support is largely dependent upon the firmware on the cards |
| 51 | Some cards do support almost all of the available CI modules. There is | 51 | Some cards do support almost all of the available CI modules. There is |
| 52 | nothing much that can be done in order to make additional CI modules | 52 | nothing much that can be done in order to make additional CI modules |
| 53 | working with these cards. | 53 | working with these cards. |
diff --git a/Documentation/dvb/faq.txt b/Documentation/dvb/faq.txt index 121832e5d899..97b1373f2428 100644 --- a/Documentation/dvb/faq.txt +++ b/Documentation/dvb/faq.txt | |||
| @@ -106,7 +106,7 @@ Some very frequently asked questions about linuxtv-dvb | |||
| 106 | 5. The dvb_net device doesn't give me any packets at all | 106 | 5. The dvb_net device doesn't give me any packets at all |
| 107 | 107 | ||
| 108 | Run tcpdump on the dvb0_0 interface. This sets the interface | 108 | Run tcpdump on the dvb0_0 interface. This sets the interface |
| 109 | into promiscous mode so it accepts any packets from the PID | 109 | into promiscuous mode so it accepts any packets from the PID |
| 110 | you have configured with the dvbnet utility. Check if there | 110 | you have configured with the dvbnet utility. Check if there |
| 111 | are any packets with the IP addr and MAC addr you have | 111 | are any packets with the IP addr and MAC addr you have |
| 112 | configured with ifconfig. | 112 | configured with ifconfig. |
diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware index 59690de8ebfe..3348d313fbe0 100644 --- a/Documentation/dvb/get_dvb_firmware +++ b/Documentation/dvb/get_dvb_firmware | |||
| @@ -556,6 +556,9 @@ sub ngene { | |||
| 556 | my $hash1 = "d798d5a757121174f0dbc5f2833c0c85"; | 556 | my $hash1 = "d798d5a757121174f0dbc5f2833c0c85"; |
| 557 | my $file2 = "ngene_17.fw"; | 557 | my $file2 = "ngene_17.fw"; |
| 558 | my $hash2 = "26b687136e127b8ac24b81e0eeafc20b"; | 558 | my $hash2 = "26b687136e127b8ac24b81e0eeafc20b"; |
| 559 | my $url2 = "http://l4m-daten.de/downloads/firmware/dvb-s2/linux/all/"; | ||
| 560 | my $file3 = "ngene_18.fw"; | ||
| 561 | my $hash3 = "ebce3ea769a53e3e0b0197c3b3f127e3"; | ||
| 559 | 562 | ||
| 560 | checkstandard(); | 563 | checkstandard(); |
| 561 | 564 | ||
| @@ -565,7 +568,10 @@ sub ngene { | |||
| 565 | wgetfile($file2, $url . $file2); | 568 | wgetfile($file2, $url . $file2); |
| 566 | verify($file2, $hash2); | 569 | verify($file2, $hash2); |
| 567 | 570 | ||
| 568 | "$file1, $file2"; | 571 | wgetfile($file3, $url2 . $file3); |
| 572 | verify($file3, $hash3); | ||
| 573 | |||
| 574 | "$file1, $file2, $file3"; | ||
| 569 | } | 575 | } |
| 570 | 576 | ||
| 571 | sub az6027{ | 577 | sub az6027{ |
diff --git a/Documentation/dvb/lmedm04.txt b/Documentation/dvb/lmedm04.txt index 641886504201..10b5f0411386 100644 --- a/Documentation/dvb/lmedm04.txt +++ b/Documentation/dvb/lmedm04.txt | |||
| @@ -4,7 +4,7 @@ following file(s) to this directory. | |||
| 4 | for DM04+/QQBOX LME2510C (Sharp 7395 Tuner) | 4 | for DM04+/QQBOX LME2510C (Sharp 7395 Tuner) |
| 5 | ------------------------------------------- | 5 | ------------------------------------------- |
| 6 | 6 | ||
| 7 | The Sharp 7395 driver can be found in windows/system32/driver | 7 | The Sharp 7395 driver can be found in windows/system32/drivers |
| 8 | 8 | ||
| 9 | US2A0D.sys (dated 17 Mar 2009) | 9 | US2A0D.sys (dated 17 Mar 2009) |
| 10 | 10 | ||
| @@ -44,7 +44,7 @@ and run | |||
| 44 | 44 | ||
| 45 | 45 | ||
| 46 | Other LG firmware can be extracted manually from US280D.sys | 46 | Other LG firmware can be extracted manually from US280D.sys |
| 47 | only found in windows/system32/driver. | 47 | only found in windows/system32/drivers |
| 48 | 48 | ||
| 49 | dd if=US280D.sys ibs=1 skip=42360 count=3924 of=dvb-usb-lme2510-lg.fw | 49 | dd if=US280D.sys ibs=1 skip=42360 count=3924 of=dvb-usb-lme2510-lg.fw |
| 50 | 50 | ||
| @@ -55,4 +55,16 @@ dd if=US280D.sys ibs=1 skip=35200 count=3850 of=dvb-usb-lme2510c-lg.fw | |||
| 55 | 55 | ||
| 56 | --------------------------------------------------------------------- | 56 | --------------------------------------------------------------------- |
| 57 | 57 | ||
| 58 | The Sharp 0194 tuner driver can be found in windows/system32/drivers | ||
| 59 | |||
| 60 | US290D.sys (dated 09 Apr 2009) | ||
| 61 | |||
| 62 | For LME2510 | ||
| 63 | dd if=US290D.sys ibs=1 skip=36856 count=3976 of=dvb-usb-lme2510-s0194.fw | ||
| 64 | |||
| 65 | |||
| 66 | For LME2510C | ||
| 67 | dd if=US290D.sys ibs=1 skip=33152 count=3697 of=dvb-usb-lme2510c-s0194.fw | ||
| 68 | |||
| 69 | |||
| 58 | Copy the firmware file(s) to /lib/firmware | 70 | Copy the firmware file(s) to /lib/firmware |
diff --git a/Documentation/dvb/udev.txt b/Documentation/dvb/udev.txt index 68ee224b6aae..412305b7c557 100644 --- a/Documentation/dvb/udev.txt +++ b/Documentation/dvb/udev.txt | |||
| @@ -1,7 +1,7 @@ | |||
| 1 | The DVB subsystem currently registers to the sysfs subsystem using the | 1 | The DVB subsystem currently registers to the sysfs subsystem using the |
| 2 | "class_simple" interface. | 2 | "class_simple" interface. |
| 3 | 3 | ||
| 4 | This means that only the basic informations like module loading parameters | 4 | This means that only the basic information like module loading parameters |
| 5 | are presented through sysfs. Other things that might be interesting are | 5 | are presented through sysfs. Other things that might be interesting are |
| 6 | currently *not* available. | 6 | currently *not* available. |
| 7 | 7 | ||
diff --git a/Documentation/dynamic-debug-howto.txt b/Documentation/dynamic-debug-howto.txt index 58ea64a96165..f959909d7154 100644 --- a/Documentation/dynamic-debug-howto.txt +++ b/Documentation/dynamic-debug-howto.txt | |||
| @@ -6,7 +6,7 @@ This document describes how to use the dynamic debug (ddebug) feature. | |||
| 6 | 6 | ||
| 7 | Dynamic debug is designed to allow you to dynamically enable/disable kernel | 7 | Dynamic debug is designed to allow you to dynamically enable/disable kernel |
| 8 | code to obtain additional kernel information. Currently, if | 8 | code to obtain additional kernel information. Currently, if |
| 9 | CONFIG_DYNAMIC_DEBUG is set, then all pr_debug()/dev_debug() calls can be | 9 | CONFIG_DYNAMIC_DEBUG is set, then all pr_debug()/dev_dbg() calls can be |
| 10 | dynamically enabled per-callsite. | 10 | dynamically enabled per-callsite. |
| 11 | 11 | ||
| 12 | Dynamic debug has even more useful features: | 12 | Dynamic debug has even more useful features: |
| @@ -26,7 +26,7 @@ Dynamic debug has even more useful features: | |||
| 26 | Controlling dynamic debug Behaviour | 26 | Controlling dynamic debug Behaviour |
| 27 | =================================== | 27 | =================================== |
| 28 | 28 | ||
| 29 | The behaviour of pr_debug()/dev_debug()s are controlled via writing to a | 29 | The behaviour of pr_debug()/dev_dbg()s are controlled via writing to a |
| 30 | control file in the 'debugfs' filesystem. Thus, you must first mount the debugfs | 30 | control file in the 'debugfs' filesystem. Thus, you must first mount the debugfs |
| 31 | filesystem, in order to make use of this feature. Subsequently, we refer to the | 31 | filesystem, in order to make use of this feature. Subsequently, we refer to the |
| 32 | control file as: <debugfs>/dynamic_debug/control. For example, if you want to | 32 | control file as: <debugfs>/dynamic_debug/control. For example, if you want to |
| @@ -205,12 +205,20 @@ of the characters: | |||
| 205 | 205 | ||
| 206 | The flags are: | 206 | The flags are: |
| 207 | 207 | ||
| 208 | f | ||
| 209 | Include the function name in the printed message | ||
| 210 | l | ||
| 211 | Include line number in the printed message | ||
| 212 | m | ||
| 213 | Include module name in the printed message | ||
| 208 | p | 214 | p |
| 209 | Causes a printk() message to be emitted to dmesg | 215 | Causes a printk() message to be emitted to dmesg |
| 216 | t | ||
| 217 | Include thread ID in messages not generated from interrupt context | ||
| 210 | 218 | ||
| 211 | Note the regexp ^[-+=][scp]+$ matches a flags specification. | 219 | Note the regexp ^[-+=][flmpt]+$ matches a flags specification. |
| 212 | Note also that there is no convenient syntax to remove all | 220 | Note also that there is no convenient syntax to remove all |
| 213 | the flags at once, you need to use "-psc". | 221 | the flags at once, you need to use "-flmpt". |
| 214 | 222 | ||
| 215 | 223 | ||
| 216 | Debug messages during boot process | 224 | Debug messages during boot process |
diff --git a/Documentation/edac.txt b/Documentation/edac.txt index 9ee774de57cd..249822cde82b 100644 --- a/Documentation/edac.txt +++ b/Documentation/edac.txt | |||
| @@ -311,7 +311,7 @@ Total Correctable Errors count attribute file: | |||
| 311 | 'ce_noinfo_count' | 311 | 'ce_noinfo_count' |
| 312 | 312 | ||
| 313 | This attribute file displays the number of CEs that | 313 | This attribute file displays the number of CEs that |
| 314 | have occurred wherewith no informations as to which DIMM slot | 314 | have occurred wherewith no information as to which DIMM slot |
| 315 | is having errors. Memory is handicapped, but operational, | 315 | is having errors. Memory is handicapped, but operational, |
| 316 | yet no information is available to indicate which slot | 316 | yet no information is available to indicate which slot |
| 317 | the failing memory is in. This count field should be also | 317 | the failing memory is in. This count field should be also |
| @@ -741,7 +741,7 @@ were done at i7core_edac driver. This chapter will cover those differences | |||
| 741 | As EDAC API maps the minimum unity is csrows, the driver sequencially | 741 | As EDAC API maps the minimum unity is csrows, the driver sequencially |
| 742 | maps channel/dimm into different csrows. | 742 | maps channel/dimm into different csrows. |
| 743 | 743 | ||
| 744 | For example, suposing the following layout: | 744 | For example, supposing the following layout: |
| 745 | Ch0 phy rd0, wr0 (0x063f4031): 2 ranks, UDIMMs | 745 | Ch0 phy rd0, wr0 (0x063f4031): 2 ranks, UDIMMs |
| 746 | dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400 | 746 | dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400 |
| 747 | dimm 1 1024 Mb offset: 4, bank: 8, rank: 1, row: 0x4000, col: 0x400 | 747 | dimm 1 1024 Mb offset: 4, bank: 8, rank: 1, row: 0x4000, col: 0x400 |
diff --git a/Documentation/eisa.txt b/Documentation/eisa.txt index f297fc1202ae..38cf0c7b559f 100644 --- a/Documentation/eisa.txt +++ b/Documentation/eisa.txt | |||
| @@ -84,7 +84,7 @@ struct eisa_driver { | |||
| 84 | 84 | ||
| 85 | id_table : an array of NULL terminated EISA id strings, | 85 | id_table : an array of NULL terminated EISA id strings, |
| 86 | followed by an empty string. Each string can | 86 | followed by an empty string. Each string can |
| 87 | optionally be paired with a driver-dependant value | 87 | optionally be paired with a driver-dependent value |
| 88 | (driver_data). | 88 | (driver_data). |
| 89 | 89 | ||
| 90 | driver : a generic driver, such as described in | 90 | driver : a generic driver, such as described in |
diff --git a/Documentation/fb/sm501.txt b/Documentation/fb/sm501.txt new file mode 100644 index 000000000000..8d17aebd2648 --- /dev/null +++ b/Documentation/fb/sm501.txt | |||
| @@ -0,0 +1,10 @@ | |||
| 1 | Configuration: | ||
| 2 | |||
| 3 | You can pass the following kernel command line options to sm501 videoframebuffer: | ||
| 4 | |||
| 5 | sm501fb.bpp= SM501 Display driver: | ||
| 6 | Specifiy bits-per-pixel if not specified by 'mode' | ||
| 7 | |||
| 8 | sm501fb.mode= SM501 Display driver: | ||
| 9 | Specify resolution as | ||
| 10 | "<xres>x<yres>[-<bpp>][@<refresh>]" | ||
diff --git a/Documentation/fb/viafb.txt b/Documentation/fb/viafb.txt index 1a2e8aa3fbb1..444e34b52ae1 100644 --- a/Documentation/fb/viafb.txt +++ b/Documentation/fb/viafb.txt | |||
| @@ -204,7 +204,7 @@ Notes: | |||
| 204 | 204 | ||
| 205 | supported_output_devices | 205 | supported_output_devices |
| 206 | 206 | ||
| 207 | This read-only file contains a full ',' seperated list containing all | 207 | This read-only file contains a full ',' separated list containing all |
| 208 | output devices that could be available on your platform. It is likely | 208 | output devices that could be available on your platform. It is likely |
| 209 | that not all of those have a connector on your hardware but it should | 209 | that not all of those have a connector on your hardware but it should |
| 210 | provide a good starting point to figure out which of those names match | 210 | provide a good starting point to figure out which of those names match |
| @@ -225,7 +225,7 @@ Notes: | |||
| 225 | This can happen for example if only one (the other) iga is used. | 225 | This can happen for example if only one (the other) iga is used. |
| 226 | Writing to these files allows adjusting the output devices during | 226 | Writing to these files allows adjusting the output devices during |
| 227 | runtime. One can add new devices, remove existing ones or switch | 227 | runtime. One can add new devices, remove existing ones or switch |
| 228 | between igas. Essentially you can write a ',' seperated list of device | 228 | between igas. Essentially you can write a ',' separated list of device |
| 229 | names (or a single one) in the same format as the output to those | 229 | names (or a single one) in the same format as the output to those |
| 230 | files. You can add a '+' or '-' as a prefix allowing simple addition | 230 | files. You can add a '+' or '-' as a prefix allowing simple addition |
| 231 | and removal of devices. So a prefix '+' adds the devices from your list | 231 | and removal of devices. So a prefix '+' adds the devices from your list |
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index b959659c5df4..492e81df2968 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt | |||
| @@ -35,6 +35,17 @@ Who: Luis R. Rodriguez <lrodriguez@atheros.com> | |||
| 35 | 35 | ||
| 36 | --------------------------- | 36 | --------------------------- |
| 37 | 37 | ||
| 38 | What: AR9170USB | ||
| 39 | When: 2.6.40 | ||
| 40 | |||
| 41 | Why: This driver is deprecated and the firmware is no longer | ||
| 42 | maintained. The replacement driver "carl9170" has been | ||
| 43 | around for a while, so the devices are still supported. | ||
| 44 | |||
| 45 | Who: Christian Lamparter <chunkeey@googlemail.com> | ||
| 46 | |||
| 47 | --------------------------- | ||
| 48 | |||
| 38 | What: IRQF_SAMPLE_RANDOM | 49 | What: IRQF_SAMPLE_RANDOM |
| 39 | Check: IRQF_SAMPLE_RANDOM | 50 | Check: IRQF_SAMPLE_RANDOM |
| 40 | When: July 2009 | 51 | When: July 2009 |
| @@ -97,42 +108,6 @@ Who: Pavel Machek <pavel@ucw.cz> | |||
| 97 | 108 | ||
| 98 | --------------------------- | 109 | --------------------------- |
| 99 | 110 | ||
| 100 | What: Video4Linux obsolete drivers using V4L1 API | ||
| 101 | When: kernel 2.6.39 | ||
| 102 | Files: drivers/staging/se401/* drivers/staging/usbvideo/* | ||
| 103 | Check: drivers/staging/se401/se401.c drivers/staging/usbvideo/usbvideo.c | ||
| 104 | Why: There are some drivers still using V4L1 API, despite all efforts we've done | ||
| 105 | to migrate. Those drivers are for obsolete hardware that the old maintainer | ||
| 106 | didn't care (or not have the hardware anymore), and that no other developer | ||
| 107 | could find any hardware to buy. They probably have no practical usage today, | ||
| 108 | and people with such old hardware could probably keep using an older version | ||
| 109 | of the kernel. Those drivers will be moved to staging on 2.6.38 and, if nobody | ||
| 110 | cares enough to port and test them with V4L2 API, they'll be removed on 2.6.39. | ||
| 111 | Who: Mauro Carvalho Chehab <mchehab@infradead.org> | ||
| 112 | |||
| 113 | --------------------------- | ||
| 114 | |||
| 115 | What: Video4Linux: Remove obsolete ioctl's | ||
| 116 | When: kernel 2.6.39 | ||
| 117 | Files: include/media/videodev2.h | ||
| 118 | Why: Some ioctl's were defined wrong on 2.6.2 and 2.6.6, using the wrong | ||
| 119 | type of R/W arguments. They were fixed, but the old ioctl names are | ||
| 120 | still there, maintained to avoid breaking binary compatibility: | ||
| 121 | #define VIDIOC_OVERLAY_OLD _IOWR('V', 14, int) | ||
| 122 | #define VIDIOC_S_PARM_OLD _IOW('V', 22, struct v4l2_streamparm) | ||
| 123 | #define VIDIOC_S_CTRL_OLD _IOW('V', 28, struct v4l2_control) | ||
| 124 | #define VIDIOC_G_AUDIO_OLD _IOWR('V', 33, struct v4l2_audio) | ||
| 125 | #define VIDIOC_G_AUDOUT_OLD _IOWR('V', 49, struct v4l2_audioout) | ||
| 126 | #define VIDIOC_CROPCAP_OLD _IOR('V', 58, struct v4l2_cropcap) | ||
| 127 | There's no sense on preserving those forever, as it is very doubtful | ||
| 128 | that someone would try to use a such old binary with a modern kernel. | ||
| 129 | Removing them will allow us to remove some magic done at the V4L ioctl | ||
| 130 | handler. | ||
| 131 | |||
| 132 | Who: Mauro Carvalho Chehab <mchehab@infradead.org> | ||
| 133 | |||
| 134 | --------------------------- | ||
| 135 | |||
| 136 | What: sys_sysctl | 111 | What: sys_sysctl |
| 137 | When: September 2010 | 112 | When: September 2010 |
| 138 | Option: CONFIG_SYSCTL_SYSCALL | 113 | Option: CONFIG_SYSCTL_SYSCALL |
| @@ -259,14 +234,6 @@ Who: Zhang Rui <rui.zhang@intel.com> | |||
| 259 | 234 | ||
| 260 | --------------------------- | 235 | --------------------------- |
| 261 | 236 | ||
| 262 | What: /proc/acpi/button | ||
| 263 | When: August 2007 | ||
| 264 | Why: /proc/acpi/button has been replaced by events to the input layer | ||
| 265 | since 2.6.20. | ||
| 266 | Who: Len Brown <len.brown@intel.com> | ||
| 267 | |||
| 268 | --------------------------- | ||
| 269 | |||
| 270 | What: /proc/acpi/event | 237 | What: /proc/acpi/event |
| 271 | When: February 2008 | 238 | When: February 2008 |
| 272 | Why: /proc/acpi/event has been replaced by events via the input layer | 239 | Why: /proc/acpi/event has been replaced by events via the input layer |
| @@ -420,26 +387,6 @@ Who: Tejun Heo <tj@kernel.org> | |||
| 420 | 387 | ||
| 421 | ---------------------------- | 388 | ---------------------------- |
| 422 | 389 | ||
| 423 | What: Support for lcd_switch and display_get in asus-laptop driver | ||
| 424 | When: March 2010 | ||
| 425 | Why: These two features use non-standard interfaces. There are the | ||
| 426 | only features that really need multiple path to guess what's | ||
| 427 | the right method name on a specific laptop. | ||
| 428 | |||
| 429 | Removing them will allow to remove a lot of code an significantly | ||
| 430 | clean the drivers. | ||
| 431 | |||
| 432 | This will affect the backlight code which won't be able to know | ||
| 433 | if the backlight is on or off. The platform display file will also be | ||
| 434 | write only (like the one in eeepc-laptop). | ||
| 435 | |||
| 436 | This should'nt affect a lot of user because they usually know | ||
| 437 | when their display is on or off. | ||
| 438 | |||
| 439 | Who: Corentin Chary <corentin.chary@gmail.com> | ||
| 440 | |||
| 441 | ---------------------------- | ||
| 442 | |||
| 443 | What: sysfs-class-rfkill state file | 390 | What: sysfs-class-rfkill state file |
| 444 | When: Feb 2014 | 391 | When: Feb 2014 |
| 445 | Files: net/rfkill/core.c | 392 | Files: net/rfkill/core.c |
| @@ -574,16 +521,6 @@ Who: NeilBrown <neilb@suse.de> | |||
| 574 | 521 | ||
| 575 | ---------------------------- | 522 | ---------------------------- |
| 576 | 523 | ||
| 577 | What: i2c_adapter.id | ||
| 578 | When: June 2011 | ||
| 579 | Why: This field is deprecated. I2C device drivers shouldn't change their | ||
| 580 | behavior based on the underlying I2C adapter. Instead, the I2C | ||
| 581 | adapter driver should instantiate the I2C devices and provide the | ||
| 582 | needed platform-specific information. | ||
| 583 | Who: Jean Delvare <khali@linux-fr.org> | ||
| 584 | |||
| 585 | ---------------------------- | ||
| 586 | |||
| 587 | What: cancel_rearming_delayed_work[queue]() | 524 | What: cancel_rearming_delayed_work[queue]() |
| 588 | When: 2.6.39 | 525 | When: 2.6.39 |
| 589 | 526 | ||
| @@ -603,3 +540,43 @@ Why: The adm9240, w83792d and w83793 hardware monitoring drivers have | |||
| 603 | Who: Jean Delvare <khali@linux-fr.org> | 540 | Who: Jean Delvare <khali@linux-fr.org> |
| 604 | 541 | ||
| 605 | ---------------------------- | 542 | ---------------------------- |
| 543 | |||
| 544 | What: xt_connlimit rev 0 | ||
| 545 | When: 2012 | ||
| 546 | Who: Jan Engelhardt <jengelh@medozas.de> | ||
| 547 | Files: net/netfilter/xt_connlimit.c | ||
| 548 | |||
| 549 | ---------------------------- | ||
| 550 | |||
| 551 | What: noswapaccount kernel command line parameter | ||
| 552 | When: 2.6.40 | ||
| 553 | Why: The original implementation of memsw feature enabled by | ||
| 554 | CONFIG_CGROUP_MEM_RES_CTLR_SWAP could be disabled by the noswapaccount | ||
| 555 | kernel parameter (introduced in 2.6.29-rc1). Later on, this decision | ||
| 556 | turned out to be not ideal because we cannot have the feature compiled | ||
| 557 | in and disabled by default and let only interested to enable it | ||
| 558 | (e.g. general distribution kernels might need it). Therefore we have | ||
| 559 | added swapaccount[=0|1] parameter (introduced in 2.6.37) which provides | ||
| 560 | the both possibilities. If we remove noswapaccount we will have | ||
| 561 | less command line parameters with the same functionality and we | ||
| 562 | can also cleanup the parameter handling a bit (). | ||
| 563 | Who: Michal Hocko <mhocko@suse.cz> | ||
| 564 | |||
| 565 | ---------------------------- | ||
| 566 | |||
| 567 | What: ipt_addrtype match include file | ||
| 568 | When: 2012 | ||
| 569 | Why: superseded by xt_addrtype | ||
| 570 | Who: Florian Westphal <fw@strlen.de> | ||
| 571 | Files: include/linux/netfilter_ipv4/ipt_addrtype.h | ||
| 572 | |||
| 573 | ---------------------------- | ||
| 574 | |||
| 575 | What: i2c_driver.attach_adapter | ||
| 576 | i2c_driver.detach_adapter | ||
| 577 | When: September 2011 | ||
| 578 | Why: These legacy callbacks should no longer be used as i2c-core offers | ||
| 579 | a variety of preferable alternative ways to instantiate I2C devices. | ||
| 580 | Who: Jean Delvare <khali@linux-fr.org> | ||
| 581 | |||
| 582 | ---------------------------- | ||
diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index 4471a416c274..61b31acb9176 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking | |||
| @@ -128,7 +128,7 @@ alloc_inode: | |||
| 128 | destroy_inode: | 128 | destroy_inode: |
| 129 | dirty_inode: (must not sleep) | 129 | dirty_inode: (must not sleep) |
| 130 | write_inode: | 130 | write_inode: |
| 131 | drop_inode: !!!inode_lock!!! | 131 | drop_inode: !!!inode->i_lock!!! |
| 132 | evict_inode: | 132 | evict_inode: |
| 133 | put_super: write | 133 | put_super: write |
| 134 | write_super: read | 134 | write_super: read |
| @@ -166,13 +166,11 @@ prototypes: | |||
| 166 | void (*kill_sb) (struct super_block *); | 166 | void (*kill_sb) (struct super_block *); |
| 167 | locking rules: | 167 | locking rules: |
| 168 | may block | 168 | may block |
| 169 | get_sb yes | ||
| 170 | mount yes | 169 | mount yes |
| 171 | kill_sb yes | 170 | kill_sb yes |
| 172 | 171 | ||
| 173 | ->get_sb() returns error or 0 with locked superblock attached to the vfsmount | 172 | ->mount() returns ERR_PTR or the root dentry; its superblock should be locked |
| 174 | (exclusive on ->s_umount). | 173 | on return. |
| 175 | ->mount() returns ERR_PTR or the root dentry. | ||
| 176 | ->kill_sb() takes a write-locked superblock, does all shutdown work on it, | 174 | ->kill_sb() takes a write-locked superblock, does all shutdown work on it, |
| 177 | unlocks and drops the reference. | 175 | unlocks and drops the reference. |
| 178 | 176 | ||
diff --git a/Documentation/filesystems/adfs.txt b/Documentation/filesystems/adfs.txt index 9e8811f92b84..5949766353f7 100644 --- a/Documentation/filesystems/adfs.txt +++ b/Documentation/filesystems/adfs.txt | |||
| @@ -9,6 +9,9 @@ Mount options for ADFS | |||
| 9 | will be nnn. Default 0700. | 9 | will be nnn. Default 0700. |
| 10 | othmask=nnn The permission mask for ADFS 'other' permissions | 10 | othmask=nnn The permission mask for ADFS 'other' permissions |
| 11 | will be nnn. Default 0077. | 11 | will be nnn. Default 0077. |
| 12 | ftsuffix=n When ftsuffix=0, no file type suffix will be applied. | ||
| 13 | When ftsuffix=1, a hexadecimal suffix corresponding to | ||
| 14 | the RISC OS file type will be added. Default 0. | ||
| 12 | 15 | ||
| 13 | Mapping of ADFS permissions to Linux permissions | 16 | Mapping of ADFS permissions to Linux permissions |
| 14 | ------------------------------------------------ | 17 | ------------------------------------------------ |
| @@ -55,3 +58,18 @@ Mapping of ADFS permissions to Linux permissions | |||
| 55 | 58 | ||
| 56 | You can therefore tailor the permission translation to whatever you | 59 | You can therefore tailor the permission translation to whatever you |
| 57 | desire the permissions should be under Linux. | 60 | desire the permissions should be under Linux. |
| 61 | |||
| 62 | RISC OS file type suffix | ||
| 63 | ------------------------ | ||
| 64 | |||
| 65 | RISC OS file types are stored in bits 19..8 of the file load address. | ||
| 66 | |||
| 67 | To enable non-RISC OS systems to be used to store files without losing | ||
| 68 | file type information, a file naming convention was devised (initially | ||
| 69 | for use with NFS) such that a hexadecimal suffix of the form ,xyz | ||
| 70 | denoted the file type: e.g. BasicFile,ffb is a BASIC (0xffb) file. This | ||
| 71 | naming convention is now also used by RISC OS emulators such as RPCEmu. | ||
| 72 | |||
| 73 | Mounting an ADFS disc with option ftsuffix=1 will cause appropriate file | ||
| 74 | type suffixes to be appended to file names read from a directory. If the | ||
| 75 | ftsuffix option is zero or omitted, no file type suffixes will be added. | ||
diff --git a/Documentation/filesystems/autofs4-mount-control.txt b/Documentation/filesystems/autofs4-mount-control.txt index 51986bf08a4d..4c95935cbcf4 100644 --- a/Documentation/filesystems/autofs4-mount-control.txt +++ b/Documentation/filesystems/autofs4-mount-control.txt | |||
| @@ -309,7 +309,7 @@ ioctlfd field set to the descriptor obtained from the open call. | |||
| 309 | AUTOFS_DEV_IOCTL_TIMEOUT_CMD | 309 | AUTOFS_DEV_IOCTL_TIMEOUT_CMD |
| 310 | ---------------------------- | 310 | ---------------------------- |
| 311 | 311 | ||
| 312 | Set the expire timeout for mounts withing an autofs mount point. | 312 | Set the expire timeout for mounts within an autofs mount point. |
| 313 | 313 | ||
| 314 | The call requires an initialized struct autofs_dev_ioctl with the | 314 | The call requires an initialized struct autofs_dev_ioctl with the |
| 315 | ioctlfd field set to the descriptor obtained from the open call. | 315 | ioctlfd field set to the descriptor obtained from the open call. |
diff --git a/Documentation/filesystems/caching/netfs-api.txt b/Documentation/filesystems/caching/netfs-api.txt index 1902c57b72ef..a167ab876c35 100644 --- a/Documentation/filesystems/caching/netfs-api.txt +++ b/Documentation/filesystems/caching/netfs-api.txt | |||
| @@ -95,7 +95,7 @@ restraints as possible on how an index is structured and where it is placed in | |||
| 95 | the tree. The netfs can even mix indices and data files at the same level, but | 95 | the tree. The netfs can even mix indices and data files at the same level, but |
| 96 | it's not recommended. | 96 | it's not recommended. |
| 97 | 97 | ||
| 98 | Each index entry consists of a key of indeterminate length plus some auxilliary | 98 | Each index entry consists of a key of indeterminate length plus some auxiliary |
| 99 | data, also of indeterminate length. | 99 | data, also of indeterminate length. |
| 100 | 100 | ||
| 101 | There are some limits on indices: | 101 | There are some limits on indices: |
| @@ -203,23 +203,23 @@ This has the following fields: | |||
| 203 | 203 | ||
| 204 | If the function is absent, a file size of 0 is assumed. | 204 | If the function is absent, a file size of 0 is assumed. |
| 205 | 205 | ||
| 206 | (6) A function to retrieve auxilliary data from the netfs [optional]. | 206 | (6) A function to retrieve auxiliary data from the netfs [optional]. |
| 207 | 207 | ||
| 208 | This function will be called with the netfs data that was passed to the | 208 | This function will be called with the netfs data that was passed to the |
| 209 | cookie acquisition function and the maximum length of auxilliary data that | 209 | cookie acquisition function and the maximum length of auxiliary data that |
| 210 | it may provide. It should write the auxilliary data into the given buffer | 210 | it may provide. It should write the auxiliary data into the given buffer |
| 211 | and return the quantity it wrote. | 211 | and return the quantity it wrote. |
| 212 | 212 | ||
| 213 | If this function is absent, the auxilliary data length will be set to 0. | 213 | If this function is absent, the auxiliary data length will be set to 0. |
| 214 | 214 | ||
| 215 | The length of the auxilliary data buffer may be dependent on the key | 215 | The length of the auxiliary data buffer may be dependent on the key |
| 216 | length. A netfs mustn't rely on being able to provide more than 400 bytes | 216 | length. A netfs mustn't rely on being able to provide more than 400 bytes |
| 217 | for both. | 217 | for both. |
| 218 | 218 | ||
| 219 | (7) A function to check the auxilliary data [optional]. | 219 | (7) A function to check the auxiliary data [optional]. |
| 220 | 220 | ||
| 221 | This function will be called to check that a match found in the cache for | 221 | This function will be called to check that a match found in the cache for |
| 222 | this object is valid. For instance with AFS it could check the auxilliary | 222 | this object is valid. For instance with AFS it could check the auxiliary |
| 223 | data against the data version number returned by the server to determine | 223 | data against the data version number returned by the server to determine |
| 224 | whether the index entry in a cache is still valid. | 224 | whether the index entry in a cache is still valid. |
| 225 | 225 | ||
| @@ -232,7 +232,7 @@ This has the following fields: | |||
| 232 | (*) FSCACHE_CHECKAUX_NEEDS_UPDATE - the entry requires update | 232 | (*) FSCACHE_CHECKAUX_NEEDS_UPDATE - the entry requires update |
| 233 | (*) FSCACHE_CHECKAUX_OBSOLETE - the entry should be deleted | 233 | (*) FSCACHE_CHECKAUX_OBSOLETE - the entry should be deleted |
| 234 | 234 | ||
| 235 | This function can also be used to extract data from the auxilliary data in | 235 | This function can also be used to extract data from the auxiliary data in |
| 236 | the cache and copy it into the netfs's structures. | 236 | the cache and copy it into the netfs's structures. |
| 237 | 237 | ||
| 238 | (8) A pair of functions to manage contexts for the completion callback | 238 | (8) A pair of functions to manage contexts for the completion callback |
diff --git a/Documentation/filesystems/configfs/configfs.txt b/Documentation/filesystems/configfs/configfs.txt index fabcb0e00f25..dd57bb6bb390 100644 --- a/Documentation/filesystems/configfs/configfs.txt +++ b/Documentation/filesystems/configfs/configfs.txt | |||
| @@ -409,7 +409,7 @@ As a consequence of this, default_groups cannot be removed directly via | |||
| 409 | rmdir(2). They also are not considered when rmdir(2) on the parent | 409 | rmdir(2). They also are not considered when rmdir(2) on the parent |
| 410 | group is checking for children. | 410 | group is checking for children. |
| 411 | 411 | ||
| 412 | [Dependant Subsystems] | 412 | [Dependent Subsystems] |
| 413 | 413 | ||
| 414 | Sometimes other drivers depend on particular configfs items. For | 414 | Sometimes other drivers depend on particular configfs items. For |
| 415 | example, ocfs2 mounts depend on a heartbeat region item. If that | 415 | example, ocfs2 mounts depend on a heartbeat region item. If that |
diff --git a/Documentation/filesystems/exofs.txt b/Documentation/filesystems/exofs.txt index abd2a9b5b787..23583a136975 100644 --- a/Documentation/filesystems/exofs.txt +++ b/Documentation/filesystems/exofs.txt | |||
| @@ -104,7 +104,15 @@ Where: | |||
| 104 | exofs specific options: Options are separated by commas (,) | 104 | exofs specific options: Options are separated by commas (,) |
| 105 | pid=<integer> - The partition number to mount/create as | 105 | pid=<integer> - The partition number to mount/create as |
| 106 | container of the filesystem. | 106 | container of the filesystem. |
| 107 | This option is mandatory. | 107 | This option is mandatory. integer can be |
| 108 | Hex by pre-pending an 0x to the number. | ||
| 109 | osdname=<id> - Mount by a device's osdname. | ||
| 110 | osdname is usually a 36 character uuid of the | ||
| 111 | form "d2683732-c906-4ee1-9dbd-c10c27bb40df". | ||
| 112 | It is one of the device's uuid specified in the | ||
| 113 | mkfs.exofs format command. | ||
| 114 | If this option is specified then the /dev/osdX | ||
| 115 | above can be empty and is ignored. | ||
| 108 | to=<integer> - Timeout in ticks for a single command. | 116 | to=<integer> - Timeout in ticks for a single command. |
| 109 | default is (60 * HZ) [for debugging only] | 117 | default is (60 * HZ) [for debugging only] |
| 110 | 118 | ||
diff --git a/Documentation/filesystems/ext4.txt b/Documentation/filesystems/ext4.txt index 6ab9442d7eeb..c79ec58fd7f6 100644 --- a/Documentation/filesystems/ext4.txt +++ b/Documentation/filesystems/ext4.txt | |||
| @@ -97,7 +97,7 @@ Note: More extensive information for getting started with ext4 can be | |||
| 97 | * Inode allocation using large virtual block groups via flex_bg | 97 | * Inode allocation using large virtual block groups via flex_bg |
| 98 | * delayed allocation | 98 | * delayed allocation |
| 99 | * large block (up to pagesize) support | 99 | * large block (up to pagesize) support |
| 100 | * efficent new ordered mode in JBD2 and ext4(avoid using buffer head to force | 100 | * efficient new ordered mode in JBD2 and ext4(avoid using buffer head to force |
| 101 | the ordering) | 101 | the ordering) |
| 102 | 102 | ||
| 103 | [1] Filesystems with a block size of 1k may see a limit imposed by the | 103 | [1] Filesystems with a block size of 1k may see a limit imposed by the |
| @@ -106,7 +106,7 @@ directory hash tree having a maximum depth of two. | |||
| 106 | 2.2 Candidate features for future inclusion | 106 | 2.2 Candidate features for future inclusion |
| 107 | 107 | ||
| 108 | * Online defrag (patches available but not well tested) | 108 | * Online defrag (patches available but not well tested) |
| 109 | * reduced mke2fs time via lazy itable initialization in conjuction with | 109 | * reduced mke2fs time via lazy itable initialization in conjunction with |
| 110 | the uninit_bg feature (capability to do this is available in e2fsprogs | 110 | the uninit_bg feature (capability to do this is available in e2fsprogs |
| 111 | but a kernel thread to do lazy zeroing of unused inode table blocks | 111 | but a kernel thread to do lazy zeroing of unused inode table blocks |
| 112 | after filesystem is first mounted is required for safety) | 112 | after filesystem is first mounted is required for safety) |
| @@ -367,12 +367,47 @@ init_itable=n The lazy itable init code will wait n times the | |||
| 367 | minimizes the impact on the systme performance | 367 | minimizes the impact on the systme performance |
| 368 | while file system's inode table is being initialized. | 368 | while file system's inode table is being initialized. |
| 369 | 369 | ||
| 370 | discard Controls whether ext4 should issue discard/TRIM | 370 | discard Controls whether ext4 should issue discard/TRIM |
| 371 | nodiscard(*) commands to the underlying block device when | 371 | nodiscard(*) commands to the underlying block device when |
| 372 | blocks are freed. This is useful for SSD devices | 372 | blocks are freed. This is useful for SSD devices |
| 373 | and sparse/thinly-provisioned LUNs, but it is off | 373 | and sparse/thinly-provisioned LUNs, but it is off |
| 374 | by default until sufficient testing has been done. | 374 | by default until sufficient testing has been done. |
| 375 | 375 | ||
| 376 | nouid32 Disables 32-bit UIDs and GIDs. This is for | ||
| 377 | interoperability with older kernels which only | ||
| 378 | store and expect 16-bit values. | ||
| 379 | |||
| 380 | resize Allows to resize filesystem to the end of the last | ||
| 381 | existing block group, further resize has to be done | ||
| 382 | with resize2fs either online, or offline. It can be | ||
| 383 | used only with conjunction with remount. | ||
| 384 | |||
| 385 | block_validity This options allows to enables/disables the in-kernel | ||
| 386 | noblock_validity facility for tracking filesystem metadata blocks | ||
| 387 | within internal data structures. This allows multi- | ||
| 388 | block allocator and other routines to quickly locate | ||
| 389 | extents which might overlap with filesystem metadata | ||
| 390 | blocks. This option is intended for debugging | ||
| 391 | purposes and since it negatively affects the | ||
| 392 | performance, it is off by default. | ||
| 393 | |||
| 394 | dioread_lock Controls whether or not ext4 should use the DIO read | ||
| 395 | dioread_nolock locking. If the dioread_nolock option is specified | ||
| 396 | ext4 will allocate uninitialized extent before buffer | ||
| 397 | write and convert the extent to initialized after IO | ||
| 398 | completes. This approach allows ext4 code to avoid | ||
| 399 | using inode mutex, which improves scalability on high | ||
| 400 | speed storages. However this does not work with nobh | ||
| 401 | option and the mount will fail. Nor does it work with | ||
| 402 | data journaling and dioread_nolock option will be | ||
| 403 | ignored with kernel warning. Note that dioread_nolock | ||
| 404 | code path is only used for extent-based files. | ||
| 405 | Because of the restrictions this options comprises | ||
| 406 | it is off by default (e.g. dioread_lock). | ||
| 407 | |||
| 408 | i_version Enable 64-bit inode version support. This option is | ||
| 409 | off by default. | ||
| 410 | |||
| 376 | Data Mode | 411 | Data Mode |
| 377 | ========= | 412 | ========= |
| 378 | There are 3 different data modes: | 413 | There are 3 different data modes: |
| @@ -400,6 +435,176 @@ needs to be read from and written to disk at the same time where it | |||
| 400 | outperforms all others modes. Currently ext4 does not have delayed | 435 | outperforms all others modes. Currently ext4 does not have delayed |
| 401 | allocation support if this data journalling mode is selected. | 436 | allocation support if this data journalling mode is selected. |
| 402 | 437 | ||
| 438 | /proc entries | ||
| 439 | ============= | ||
| 440 | |||
| 441 | Information about mounted ext4 file systems can be found in | ||
| 442 | /proc/fs/ext4. Each mounted filesystem will have a directory in | ||
| 443 | /proc/fs/ext4 based on its device name (i.e., /proc/fs/ext4/hdc or | ||
| 444 | /proc/fs/ext4/dm-0). The files in each per-device directory are shown | ||
| 445 | in table below. | ||
| 446 | |||
| 447 | Files in /proc/fs/ext4/<devname> | ||
| 448 | .............................................................................. | ||
| 449 | File Content | ||
| 450 | mb_groups details of multiblock allocator buddy cache of free blocks | ||
| 451 | .............................................................................. | ||
| 452 | |||
| 453 | /sys entries | ||
| 454 | ============ | ||
| 455 | |||
| 456 | Information about mounted ext4 file systems can be found in | ||
| 457 | /sys/fs/ext4. Each mounted filesystem will have a directory in | ||
| 458 | /sys/fs/ext4 based on its device name (i.e., /sys/fs/ext4/hdc or | ||
| 459 | /sys/fs/ext4/dm-0). The files in each per-device directory are shown | ||
| 460 | in table below. | ||
| 461 | |||
| 462 | Files in /sys/fs/ext4/<devname> | ||
| 463 | (see also Documentation/ABI/testing/sysfs-fs-ext4) | ||
| 464 | .............................................................................. | ||
| 465 | File Content | ||
| 466 | |||
| 467 | delayed_allocation_blocks This file is read-only and shows the number of | ||
| 468 | blocks that are dirty in the page cache, but | ||
| 469 | which do not have their location in the | ||
| 470 | filesystem allocated yet. | ||
| 471 | |||
| 472 | inode_goal Tuning parameter which (if non-zero) controls | ||
| 473 | the goal inode used by the inode allocator in | ||
| 474 | preference to all other allocation heuristics. | ||
| 475 | This is intended for debugging use only, and | ||
| 476 | should be 0 on production systems. | ||
| 477 | |||
| 478 | inode_readahead_blks Tuning parameter which controls the maximum | ||
| 479 | number of inode table blocks that ext4's inode | ||
| 480 | table readahead algorithm will pre-read into | ||
| 481 | the buffer cache | ||
| 482 | |||
| 483 | lifetime_write_kbytes This file is read-only and shows the number of | ||
| 484 | kilobytes of data that have been written to this | ||
| 485 | filesystem since it was created. | ||
| 486 | |||
| 487 | max_writeback_mb_bump The maximum number of megabytes the writeback | ||
| 488 | code will try to write out before move on to | ||
| 489 | another inode. | ||
| 490 | |||
| 491 | mb_group_prealloc The multiblock allocator will round up allocation | ||
| 492 | requests to a multiple of this tuning parameter if | ||
| 493 | the stripe size is not set in the ext4 superblock | ||
| 494 | |||
| 495 | mb_max_to_scan The maximum number of extents the multiblock | ||
| 496 | allocator will search to find the best extent | ||
| 497 | |||
| 498 | mb_min_to_scan The minimum number of extents the multiblock | ||
| 499 | allocator will search to find the best extent | ||
| 500 | |||
| 501 | mb_order2_req Tuning parameter which controls the minimum size | ||
| 502 | for requests (as a power of 2) where the buddy | ||
| 503 | cache is used | ||
| 504 | |||
| 505 | mb_stats Controls whether the multiblock allocator should | ||
| 506 | collect statistics, which are shown during the | ||
| 507 | unmount. 1 means to collect statistics, 0 means | ||
| 508 | not to collect statistics | ||
| 509 | |||
| 510 | mb_stream_req Files which have fewer blocks than this tunable | ||
| 511 | parameter will have their blocks allocated out | ||
| 512 | of a block group specific preallocation pool, so | ||
| 513 | that small files are packed closely together. | ||
| 514 | Each large file will have its blocks allocated | ||
| 515 | out of its own unique preallocation pool. | ||
| 516 | |||
| 517 | session_write_kbytes This file is read-only and shows the number of | ||
| 518 | kilobytes of data that have been written to this | ||
| 519 | filesystem since it was mounted. | ||
| 520 | .............................................................................. | ||
| 521 | |||
| 522 | Ioctls | ||
| 523 | ====== | ||
| 524 | |||
| 525 | There is some Ext4 specific functionality which can be accessed by applications | ||
| 526 | through the system call interfaces. The list of all Ext4 specific ioctls are | ||
| 527 | shown in the table below. | ||
| 528 | |||
| 529 | Table of Ext4 specific ioctls | ||
| 530 | .............................................................................. | ||
| 531 | Ioctl Description | ||
| 532 | EXT4_IOC_GETFLAGS Get additional attributes associated with inode. | ||
| 533 | The ioctl argument is an integer bitfield, with | ||
| 534 | bit values described in ext4.h. This ioctl is an | ||
| 535 | alias for FS_IOC_GETFLAGS. | ||
| 536 | |||
| 537 | EXT4_IOC_SETFLAGS Set additional attributes associated with inode. | ||
| 538 | The ioctl argument is an integer bitfield, with | ||
| 539 | bit values described in ext4.h. This ioctl is an | ||
| 540 | alias for FS_IOC_SETFLAGS. | ||
| 541 | |||
| 542 | EXT4_IOC_GETVERSION | ||
| 543 | EXT4_IOC_GETVERSION_OLD | ||
| 544 | Get the inode i_generation number stored for | ||
| 545 | each inode. The i_generation number is normally | ||
| 546 | changed only when new inode is created and it is | ||
| 547 | particularly useful for network filesystems. The | ||
| 548 | '_OLD' version of this ioctl is an alias for | ||
| 549 | FS_IOC_GETVERSION. | ||
| 550 | |||
| 551 | EXT4_IOC_SETVERSION | ||
| 552 | EXT4_IOC_SETVERSION_OLD | ||
| 553 | Set the inode i_generation number stored for | ||
| 554 | each inode. The '_OLD' version of this ioctl | ||
| 555 | is an alias for FS_IOC_SETVERSION. | ||
| 556 | |||
| 557 | EXT4_IOC_GROUP_EXTEND This ioctl has the same purpose as the resize | ||
| 558 | mount option. It allows to resize filesystem | ||
| 559 | to the end of the last existing block group, | ||
| 560 | further resize has to be done with resize2fs, | ||
| 561 | either online, or offline. The argument points | ||
| 562 | to the unsigned logn number representing the | ||
| 563 | filesystem new block count. | ||
| 564 | |||
| 565 | EXT4_IOC_MOVE_EXT Move the block extents from orig_fd (the one | ||
| 566 | this ioctl is pointing to) to the donor_fd (the | ||
| 567 | one specified in move_extent structure passed | ||
| 568 | as an argument to this ioctl). Then, exchange | ||
| 569 | inode metadata between orig_fd and donor_fd. | ||
| 570 | This is especially useful for online | ||
| 571 | defragmentation, because the allocator has the | ||
| 572 | opportunity to allocate moved blocks better, | ||
| 573 | ideally into one contiguous extent. | ||
| 574 | |||
| 575 | EXT4_IOC_GROUP_ADD Add a new group descriptor to an existing or | ||
| 576 | new group descriptor block. The new group | ||
| 577 | descriptor is described by ext4_new_group_input | ||
| 578 | structure, which is passed as an argument to | ||
| 579 | this ioctl. This is especially useful in | ||
| 580 | conjunction with EXT4_IOC_GROUP_EXTEND, | ||
| 581 | which allows online resize of the filesystem | ||
| 582 | to the end of the last existing block group. | ||
| 583 | Those two ioctls combined is used in userspace | ||
| 584 | online resize tool (e.g. resize2fs). | ||
| 585 | |||
| 586 | EXT4_IOC_MIGRATE This ioctl operates on the filesystem itself. | ||
| 587 | It converts (migrates) ext3 indirect block mapped | ||
| 588 | inode to ext4 extent mapped inode by walking | ||
| 589 | through indirect block mapping of the original | ||
| 590 | inode and converting contiguous block ranges | ||
| 591 | into ext4 extents of the temporary inode. Then, | ||
| 592 | inodes are swapped. This ioctl might help, when | ||
| 593 | migrating from ext3 to ext4 filesystem, however | ||
| 594 | suggestion is to create fresh ext4 filesystem | ||
| 595 | and copy data from the backup. Note, that | ||
| 596 | filesystem has to support extents for this ioctl | ||
| 597 | to work. | ||
| 598 | |||
| 599 | EXT4_IOC_ALLOC_DA_BLKS Force all of the delay allocated blocks to be | ||
| 600 | allocated to preserve application-expected ext3 | ||
| 601 | behaviour. Note that this will also start | ||
| 602 | triggering a write of the data blocks, but this | ||
| 603 | behaviour may change in the future as it is | ||
| 604 | not necessary and has been done this way only | ||
| 605 | for sake of simplicity. | ||
| 606 | .............................................................................. | ||
| 607 | |||
| 403 | References | 608 | References |
| 404 | ========== | 609 | ========== |
| 405 | 610 | ||
diff --git a/Documentation/filesystems/gfs2-uevents.txt b/Documentation/filesystems/gfs2-uevents.txt index fd966dc9979a..d81889669293 100644 --- a/Documentation/filesystems/gfs2-uevents.txt +++ b/Documentation/filesystems/gfs2-uevents.txt | |||
| @@ -62,7 +62,7 @@ be fixed. | |||
| 62 | 62 | ||
| 63 | The REMOVE uevent is generated at the end of an unsuccessful mount | 63 | The REMOVE uevent is generated at the end of an unsuccessful mount |
| 64 | or at the end of a umount of the filesystem. All REMOVE uevents will | 64 | or at the end of a umount of the filesystem. All REMOVE uevents will |
| 65 | have been preceeded by at least an ADD uevent for the same fileystem, | 65 | have been preceded by at least an ADD uevent for the same fileystem, |
| 66 | and unlike the other uevents is generated automatically by the kernel's | 66 | and unlike the other uevents is generated automatically by the kernel's |
| 67 | kobject subsystem. | 67 | kobject subsystem. |
| 68 | 68 | ||
diff --git a/Documentation/filesystems/gfs2.txt b/Documentation/filesystems/gfs2.txt index 0b59c0200912..4cda926628aa 100644 --- a/Documentation/filesystems/gfs2.txt +++ b/Documentation/filesystems/gfs2.txt | |||
| @@ -11,7 +11,7 @@ their I/O so file system consistency is maintained. One of the nifty | |||
| 11 | features of GFS is perfect consistency -- changes made to the file system | 11 | features of GFS is perfect consistency -- changes made to the file system |
| 12 | on one machine show up immediately on all other machines in the cluster. | 12 | on one machine show up immediately on all other machines in the cluster. |
| 13 | 13 | ||
| 14 | GFS uses interchangable inter-node locking mechanisms, the currently | 14 | GFS uses interchangeable inter-node locking mechanisms, the currently |
| 15 | supported mechanisms are: | 15 | supported mechanisms are: |
| 16 | 16 | ||
| 17 | lock_nolock -- allows gfs to be used as a local file system | 17 | lock_nolock -- allows gfs to be used as a local file system |
diff --git a/Documentation/filesystems/nfs/pnfs.txt b/Documentation/filesystems/nfs/pnfs.txt index bc0b9cfe095b..983e14abe7e9 100644 --- a/Documentation/filesystems/nfs/pnfs.txt +++ b/Documentation/filesystems/nfs/pnfs.txt | |||
| @@ -46,3 +46,10 @@ data server cache | |||
| 46 | file driver devices refer to data servers, which are kept in a module | 46 | file driver devices refer to data servers, which are kept in a module |
| 47 | level cache. Its reference is held over the lifetime of the deviceid | 47 | level cache. Its reference is held over the lifetime of the deviceid |
| 48 | pointing to it. | 48 | pointing to it. |
| 49 | |||
| 50 | lseg | ||
| 51 | ---- | ||
| 52 | lseg maintains an extra reference corresponding to the NFS_LSEG_VALID | ||
| 53 | bit which holds it in the pnfs_layout_hdr's list. When the final lseg | ||
| 54 | is removed from the pnfs_layout_hdr's list, the NFS_LAYOUT_DESTROYED | ||
| 55 | bit is set, preventing any new lsegs from being added. | ||
diff --git a/Documentation/filesystems/ntfs.txt b/Documentation/filesystems/ntfs.txt index 933bc66ccff1..791af8dac065 100644 --- a/Documentation/filesystems/ntfs.txt +++ b/Documentation/filesystems/ntfs.txt | |||
| @@ -350,7 +350,7 @@ Note the "Should sync?" parameter "nosync" means that the two mirrors are | |||
| 350 | already in sync which will be the case on a clean shutdown of Windows. If the | 350 | already in sync which will be the case on a clean shutdown of Windows. If the |
| 351 | mirrors are not clean, you can specify the "sync" option instead of "nosync" | 351 | mirrors are not clean, you can specify the "sync" option instead of "nosync" |
| 352 | and the Device-Mapper driver will then copy the entirety of the "Source Device" | 352 | and the Device-Mapper driver will then copy the entirety of the "Source Device" |
| 353 | to the "Target Device" or if you specified multipled target devices to all of | 353 | to the "Target Device" or if you specified multiple target devices to all of |
| 354 | them. | 354 | them. |
| 355 | 355 | ||
| 356 | Once you have your table, save it in a file somewhere (e.g. /etc/ntfsvolume1), | 356 | Once you have your table, save it in a file somewhere (e.g. /etc/ntfsvolume1), |
diff --git a/Documentation/filesystems/ocfs2.txt b/Documentation/filesystems/ocfs2.txt index 5393e6611691..9ed920a8cd79 100644 --- a/Documentation/filesystems/ocfs2.txt +++ b/Documentation/filesystems/ocfs2.txt | |||
| @@ -80,7 +80,7 @@ user_xattr (*) Enables Extended User Attributes. | |||
| 80 | nouser_xattr Disables Extended User Attributes. | 80 | nouser_xattr Disables Extended User Attributes. |
| 81 | acl Enables POSIX Access Control Lists support. | 81 | acl Enables POSIX Access Control Lists support. |
| 82 | noacl (*) Disables POSIX Access Control Lists support. | 82 | noacl (*) Disables POSIX Access Control Lists support. |
| 83 | resv_level=2 (*) Set how agressive allocation reservations will be. | 83 | resv_level=2 (*) Set how aggressive allocation reservations will be. |
| 84 | Valid values are between 0 (reservations off) to 8 | 84 | Valid values are between 0 (reservations off) to 8 |
| 85 | (maximum space for reservations). | 85 | (maximum space for reservations). |
| 86 | dir_resv_level= (*) By default, directory reservations will scale with file | 86 | dir_resv_level= (*) By default, directory reservations will scale with file |
diff --git a/Documentation/filesystems/path-lookup.txt b/Documentation/filesystems/path-lookup.txt index eb59c8b44be9..3571667c7105 100644 --- a/Documentation/filesystems/path-lookup.txt +++ b/Documentation/filesystems/path-lookup.txt | |||
| @@ -42,7 +42,7 @@ Path walking overview | |||
| 42 | A name string specifies a start (root directory, cwd, fd-relative) and a | 42 | A name string specifies a start (root directory, cwd, fd-relative) and a |
| 43 | sequence of elements (directory entry names), which together refer to a path in | 43 | sequence of elements (directory entry names), which together refer to a path in |
| 44 | the namespace. A path is represented as a (dentry, vfsmount) tuple. The name | 44 | the namespace. A path is represented as a (dentry, vfsmount) tuple. The name |
| 45 | elements are sub-strings, seperated by '/'. | 45 | elements are sub-strings, separated by '/'. |
| 46 | 46 | ||
| 47 | Name lookups will want to find a particular path that a name string refers to | 47 | Name lookups will want to find a particular path that a name string refers to |
| 48 | (usually the final element, or parent of final element). This is done by taking | 48 | (usually the final element, or parent of final element). This is done by taking |
| @@ -354,7 +354,7 @@ vfstest 24185492 4945 708725(2.9%) 1076136(4.4%) 0 2651 | |||
| 354 | 354 | ||
| 355 | What this shows is that failed rcu-walk lookups, ie. ones that are restarted | 355 | What this shows is that failed rcu-walk lookups, ie. ones that are restarted |
| 356 | entirely with ref-walk, are quite rare. Even the "vfstest" case which | 356 | entirely with ref-walk, are quite rare. Even the "vfstest" case which |
| 357 | specifically has concurrent renames/mkdir/rmdir/ creat/unlink/etc to excercise | 357 | specifically has concurrent renames/mkdir/rmdir/ creat/unlink/etc to exercise |
| 358 | such races is not showing a huge amount of restarts. | 358 | such races is not showing a huge amount of restarts. |
| 359 | 359 | ||
| 360 | Dropping from rcu-walk to ref-walk mean that we have encountered a dentry where | 360 | Dropping from rcu-walk to ref-walk mean that we have encountered a dentry where |
diff --git a/Documentation/filesystems/pohmelfs/network_protocol.txt b/Documentation/filesystems/pohmelfs/network_protocol.txt index 40ea6c295afb..65e03dd44823 100644 --- a/Documentation/filesystems/pohmelfs/network_protocol.txt +++ b/Documentation/filesystems/pohmelfs/network_protocol.txt | |||
| @@ -20,7 +20,7 @@ Commands can be embedded into transaction command (which in turn has own command | |||
| 20 | so one can extend protocol as needed without breaking backward compatibility as long | 20 | so one can extend protocol as needed without breaking backward compatibility as long |
| 21 | as old commands are supported. All string lengths include tail 0 byte. | 21 | as old commands are supported. All string lengths include tail 0 byte. |
| 22 | 22 | ||
| 23 | All commans are transfered over the network in big-endian. CPU endianess is used at the end peers. | 23 | All commands are transferred over the network in big-endian. CPU endianess is used at the end peers. |
| 24 | 24 | ||
| 25 | @cmd - command number, which specifies command to be processed. Following | 25 | @cmd - command number, which specifies command to be processed. Following |
| 26 | commands are used currently: | 26 | commands are used currently: |
diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting index dfbcd1b00b0a..6e29954851a2 100644 --- a/Documentation/filesystems/porting +++ b/Documentation/filesystems/porting | |||
| @@ -298,11 +298,14 @@ be used instead. It gets called whenever the inode is evicted, whether it has | |||
| 298 | remaining links or not. Caller does *not* evict the pagecache or inode-associated | 298 | remaining links or not. Caller does *not* evict the pagecache or inode-associated |
| 299 | metadata buffers; getting rid of those is responsibility of method, as it had | 299 | metadata buffers; getting rid of those is responsibility of method, as it had |
| 300 | been for ->delete_inode(). | 300 | been for ->delete_inode(). |
| 301 | ->drop_inode() returns int now; it's called on final iput() with inode_lock | 301 | |
| 302 | held and it returns true if filesystems wants the inode to be dropped. As before, | 302 | ->drop_inode() returns int now; it's called on final iput() with |
| 303 | generic_drop_inode() is still the default and it's been updated appropriately. | 303 | inode->i_lock held and it returns true if filesystems wants the inode to be |
| 304 | generic_delete_inode() is also alive and it consists simply of return 1. Note that | 304 | dropped. As before, generic_drop_inode() is still the default and it's been |
| 305 | all actual eviction work is done by caller after ->drop_inode() returns. | 305 | updated appropriately. generic_delete_inode() is also alive and it consists |
| 306 | simply of return 1. Note that all actual eviction work is done by caller after | ||
| 307 | ->drop_inode() returns. | ||
| 308 | |||
| 306 | clear_inode() is gone; use end_writeback() instead. As before, it must | 309 | clear_inode() is gone; use end_writeback() instead. As before, it must |
| 307 | be called exactly once on each call of ->evict_inode() (as it used to be for | 310 | be called exactly once on each call of ->evict_inode() (as it used to be for |
| 308 | each call of ->delete_inode()). Unlike before, if you are using inode-associated | 311 | each call of ->delete_inode()). Unlike before, if you are using inode-associated |
| @@ -394,3 +397,13 @@ file) you must return -EOPNOTSUPP if FALLOC_FL_PUNCH_HOLE is set in mode. | |||
| 394 | Currently you can only have FALLOC_FL_PUNCH_HOLE with FALLOC_FL_KEEP_SIZE set, | 397 | Currently you can only have FALLOC_FL_PUNCH_HOLE with FALLOC_FL_KEEP_SIZE set, |
| 395 | so the i_size should not change when hole punching, even when puching the end of | 398 | so the i_size should not change when hole punching, even when puching the end of |
| 396 | a file off. | 399 | a file off. |
| 400 | |||
| 401 | -- | ||
| 402 | [mandatory] | ||
| 403 | |||
| 404 | -- | ||
| 405 | [mandatory] | ||
| 406 | ->get_sb() is gone. Switch to use of ->mount(). Typically it's just | ||
| 407 | a matter of switching from calling get_sb_... to mount_... and changing the | ||
| 408 | function type. If you were doing it manually, just switch from setting ->mnt_root | ||
| 409 | to some pointer to returning that pointer. On errors return ERR_PTR(...). | ||
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index 23cae6548d3a..b0b814d75ca1 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt | |||
| @@ -543,7 +543,7 @@ just those considered 'most important'. The new vectors are: | |||
| 543 | their statistics are used by kernel developers and interested users to | 543 | their statistics are used by kernel developers and interested users to |
| 544 | determine the occurrence of interrupts of the given type. | 544 | determine the occurrence of interrupts of the given type. |
| 545 | 545 | ||
| 546 | The above IRQ vectors are displayed only when relevent. For example, | 546 | The above IRQ vectors are displayed only when relevant. For example, |
| 547 | the threshold vector does not exist on x86_64 platforms. Others are | 547 | the threshold vector does not exist on x86_64 platforms. Others are |
| 548 | suppressed when the system is a uniprocessor. As of this writing, only | 548 | suppressed when the system is a uniprocessor. As of this writing, only |
| 549 | i386 and x86_64 platforms support the new IRQ vector displays. | 549 | i386 and x86_64 platforms support the new IRQ vector displays. |
| @@ -1202,7 +1202,7 @@ The columns are: | |||
| 1202 | W = can do write operations | 1202 | W = can do write operations |
| 1203 | U = can do unblank | 1203 | U = can do unblank |
| 1204 | flags E = it is enabled | 1204 | flags E = it is enabled |
| 1205 | C = it is prefered console | 1205 | C = it is preferred console |
| 1206 | B = it is primary boot console | 1206 | B = it is primary boot console |
| 1207 | p = it is used for printk buffer | 1207 | p = it is used for printk buffer |
| 1208 | b = it is not a TTY but a Braille device | 1208 | b = it is not a TTY but a Braille device |
| @@ -1331,7 +1331,7 @@ NOTICE: /proc/<pid>/oom_adj is deprecated and will be removed, please see | |||
| 1331 | Documentation/feature-removal-schedule.txt. | 1331 | Documentation/feature-removal-schedule.txt. |
| 1332 | 1332 | ||
| 1333 | Caveat: when a parent task is selected, the oom killer will sacrifice any first | 1333 | Caveat: when a parent task is selected, the oom killer will sacrifice any first |
| 1334 | generation children with seperate address spaces instead, if possible. This | 1334 | generation children with separate address spaces instead, if possible. This |
| 1335 | avoids servers and important system daemons from being killed and loses the | 1335 | avoids servers and important system daemons from being killed and loses the |
| 1336 | minimal amount of work. | 1336 | minimal amount of work. |
| 1337 | 1337 | ||
diff --git a/Documentation/filesystems/romfs.txt b/Documentation/filesystems/romfs.txt index 2d2a7b2a16b9..e2b07cc9120a 100644 --- a/Documentation/filesystems/romfs.txt +++ b/Documentation/filesystems/romfs.txt | |||
| @@ -17,8 +17,7 @@ comparison, an actual rescue disk used up 3202 blocks with ext2, while | |||
| 17 | with romfs, it needed 3079 blocks. | 17 | with romfs, it needed 3079 blocks. |
| 18 | 18 | ||
| 19 | To create such a file system, you'll need a user program named | 19 | To create such a file system, you'll need a user program named |
| 20 | genromfs. It is available via anonymous ftp on sunsite.unc.edu and | 20 | genromfs. It is available on http://romfs.sourceforge.net/ |
| 21 | its mirrors, in the /pub/Linux/system/recovery/ directory. | ||
| 22 | 21 | ||
| 23 | As the name suggests, romfs could be also used (space-efficiently) on | 22 | As the name suggests, romfs could be also used (space-efficiently) on |
| 24 | various read-only media, like (E)EPROM disks if someone will have the | 23 | various read-only media, like (E)EPROM disks if someone will have the |
diff --git a/Documentation/filesystems/squashfs.txt b/Documentation/filesystems/squashfs.txt index 66699afd66ca..d4d41465a0b1 100644 --- a/Documentation/filesystems/squashfs.txt +++ b/Documentation/filesystems/squashfs.txt | |||
| @@ -59,12 +59,15 @@ obtained from this site also. | |||
| 59 | 3. SQUASHFS FILESYSTEM DESIGN | 59 | 3. SQUASHFS FILESYSTEM DESIGN |
| 60 | ----------------------------- | 60 | ----------------------------- |
| 61 | 61 | ||
| 62 | A squashfs filesystem consists of a maximum of eight parts, packed together on a byte | 62 | A squashfs filesystem consists of a maximum of nine parts, packed together on a |
| 63 | alignment: | 63 | byte alignment: |
| 64 | 64 | ||
| 65 | --------------- | 65 | --------------- |
| 66 | | superblock | | 66 | | superblock | |
| 67 | |---------------| | 67 | |---------------| |
| 68 | | compression | | ||
| 69 | | options | | ||
| 70 | |---------------| | ||
| 68 | | datablocks | | 71 | | datablocks | |
| 69 | | & fragments | | 72 | | & fragments | |
| 70 | |---------------| | 73 | |---------------| |
| @@ -91,7 +94,14 @@ the source directory, and checked for duplicates. Once all file data has been | |||
| 91 | written the completed inode, directory, fragment, export and uid/gid lookup | 94 | written the completed inode, directory, fragment, export and uid/gid lookup |
| 92 | tables are written. | 95 | tables are written. |
| 93 | 96 | ||
| 94 | 3.1 Inodes | 97 | 3.1 Compression options |
| 98 | ----------------------- | ||
| 99 | |||
| 100 | Compressors can optionally support compression specific options (e.g. | ||
| 101 | dictionary size). If non-default compression options have been used, then | ||
| 102 | these are stored here. | ||
| 103 | |||
| 104 | 3.2 Inodes | ||
| 95 | ---------- | 105 | ---------- |
| 96 | 106 | ||
| 97 | Metadata (inodes and directories) are compressed in 8Kbyte blocks. Each | 107 | Metadata (inodes and directories) are compressed in 8Kbyte blocks. Each |
| @@ -114,7 +124,7 @@ directory inode are defined: inodes optimised for frequently occurring | |||
| 114 | regular files and directories, and extended types where extra | 124 | regular files and directories, and extended types where extra |
| 115 | information has to be stored. | 125 | information has to be stored. |
| 116 | 126 | ||
| 117 | 3.2 Directories | 127 | 3.3 Directories |
| 118 | --------------- | 128 | --------------- |
| 119 | 129 | ||
| 120 | Like inodes, directories are packed into compressed metadata blocks, stored | 130 | Like inodes, directories are packed into compressed metadata blocks, stored |
| @@ -144,7 +154,7 @@ decompressed to do a lookup irrespective of the length of the directory. | |||
| 144 | This scheme has the advantage that it doesn't require extra memory overhead | 154 | This scheme has the advantage that it doesn't require extra memory overhead |
| 145 | and doesn't require much extra storage on disk. | 155 | and doesn't require much extra storage on disk. |
| 146 | 156 | ||
| 147 | 3.3 File data | 157 | 3.4 File data |
| 148 | ------------- | 158 | ------------- |
| 149 | 159 | ||
| 150 | Regular files consist of a sequence of contiguous compressed blocks, and/or a | 160 | Regular files consist of a sequence of contiguous compressed blocks, and/or a |
| @@ -163,7 +173,7 @@ Larger files use multiple slots, with 1.75 TiB files using all 8 slots. | |||
| 163 | The index cache is designed to be memory efficient, and by default uses | 173 | The index cache is designed to be memory efficient, and by default uses |
| 164 | 16 KiB. | 174 | 16 KiB. |
| 165 | 175 | ||
| 166 | 3.4 Fragment lookup table | 176 | 3.5 Fragment lookup table |
| 167 | ------------------------- | 177 | ------------------------- |
| 168 | 178 | ||
| 169 | Regular files can contain a fragment index which is mapped to a fragment | 179 | Regular files can contain a fragment index which is mapped to a fragment |
| @@ -173,7 +183,7 @@ A second index table is used to locate these. This second index table for | |||
| 173 | speed of access (and because it is small) is read at mount time and cached | 183 | speed of access (and because it is small) is read at mount time and cached |
| 174 | in memory. | 184 | in memory. |
| 175 | 185 | ||
| 176 | 3.5 Uid/gid lookup table | 186 | 3.6 Uid/gid lookup table |
| 177 | ------------------------ | 187 | ------------------------ |
| 178 | 188 | ||
| 179 | For space efficiency regular files store uid and gid indexes, which are | 189 | For space efficiency regular files store uid and gid indexes, which are |
| @@ -182,7 +192,7 @@ stored compressed into metadata blocks. A second index table is used to | |||
| 182 | locate these. This second index table for speed of access (and because it | 192 | locate these. This second index table for speed of access (and because it |
| 183 | is small) is read at mount time and cached in memory. | 193 | is small) is read at mount time and cached in memory. |
| 184 | 194 | ||
| 185 | 3.6 Export table | 195 | 3.7 Export table |
| 186 | ---------------- | 196 | ---------------- |
| 187 | 197 | ||
| 188 | To enable Squashfs filesystems to be exportable (via NFS etc.) filesystems | 198 | To enable Squashfs filesystems to be exportable (via NFS etc.) filesystems |
| @@ -196,7 +206,7 @@ This table is stored compressed into metadata blocks. A second index table is | |||
| 196 | used to locate these. This second index table for speed of access (and because | 206 | used to locate these. This second index table for speed of access (and because |
| 197 | it is small) is read at mount time and cached in memory. | 207 | it is small) is read at mount time and cached in memory. |
| 198 | 208 | ||
| 199 | 3.7 Xattr table | 209 | 3.8 Xattr table |
| 200 | --------------- | 210 | --------------- |
| 201 | 211 | ||
| 202 | The xattr table contains extended attributes for each inode. The xattrs | 212 | The xattr table contains extended attributes for each inode. The xattrs |
| @@ -209,7 +219,7 @@ or if it is stored out of line (in which case the value field stores a | |||
| 209 | reference to where the actual value is stored). This allows large values | 219 | reference to where the actual value is stored). This allows large values |
| 210 | to be stored out of line improving scanning and lookup performance and it | 220 | to be stored out of line improving scanning and lookup performance and it |
| 211 | also allows values to be de-duplicated, the value being stored once, and | 221 | also allows values to be de-duplicated, the value being stored once, and |
| 212 | all other occurences holding an out of line reference to that value. | 222 | all other occurrences holding an out of line reference to that value. |
| 213 | 223 | ||
| 214 | The xattr lists are packed into compressed 8K metadata blocks. | 224 | The xattr lists are packed into compressed 8K metadata blocks. |
| 215 | To reduce overhead in inodes, rather than storing the on-disk | 225 | To reduce overhead in inodes, rather than storing the on-disk |
diff --git a/Documentation/filesystems/sysfs.txt b/Documentation/filesystems/sysfs.txt index 5d1335faec2d..597f728e7b4e 100644 --- a/Documentation/filesystems/sysfs.txt +++ b/Documentation/filesystems/sysfs.txt | |||
| @@ -39,10 +39,12 @@ userspace. Top-level directories in sysfs represent the common | |||
| 39 | ancestors of object hierarchies; i.e. the subsystems the objects | 39 | ancestors of object hierarchies; i.e. the subsystems the objects |
| 40 | belong to. | 40 | belong to. |
| 41 | 41 | ||
| 42 | Sysfs internally stores the kobject that owns the directory in the | 42 | Sysfs internally stores a pointer to the kobject that implements a |
| 43 | ->d_fsdata pointer of the directory's dentry. This allows sysfs to do | 43 | directory in the sysfs_dirent object associated with the directory. In |
| 44 | reference counting directly on the kobject when the file is opened and | 44 | the past this kobject pointer has been used by sysfs to do reference |
| 45 | closed. | 45 | counting directly on the kobject whenever the file is opened or closed. |
| 46 | With the current sysfs implementation the kobject reference count is | ||
| 47 | only modified directly by the function sysfs_schedule_callback(). | ||
| 46 | 48 | ||
| 47 | 49 | ||
| 48 | Attributes | 50 | Attributes |
| @@ -60,7 +62,7 @@ values of the same type. | |||
| 60 | 62 | ||
| 61 | Mixing types, expressing multiple lines of data, and doing fancy | 63 | Mixing types, expressing multiple lines of data, and doing fancy |
| 62 | formatting of data is heavily frowned upon. Doing these things may get | 64 | formatting of data is heavily frowned upon. Doing these things may get |
| 63 | you publically humiliated and your code rewritten without notice. | 65 | you publicly humiliated and your code rewritten without notice. |
| 64 | 66 | ||
| 65 | 67 | ||
| 66 | An attribute definition is simply: | 68 | An attribute definition is simply: |
| @@ -208,9 +210,9 @@ Other notes: | |||
| 208 | is 4096. | 210 | is 4096. |
| 209 | 211 | ||
| 210 | - show() methods should return the number of bytes printed into the | 212 | - show() methods should return the number of bytes printed into the |
| 211 | buffer. This is the return value of snprintf(). | 213 | buffer. This is the return value of scnprintf(). |
| 212 | 214 | ||
| 213 | - show() should always use snprintf(). | 215 | - show() should always use scnprintf(). |
| 214 | 216 | ||
| 215 | - store() should return the number of bytes used from the buffer. If the | 217 | - store() should return the number of bytes used from the buffer. If the |
| 216 | entire buffer has been used, just return the count argument. | 218 | entire buffer has been used, just return the count argument. |
| @@ -229,7 +231,7 @@ A very simple (and naive) implementation of a device attribute is: | |||
| 229 | static ssize_t show_name(struct device *dev, struct device_attribute *attr, | 231 | static ssize_t show_name(struct device *dev, struct device_attribute *attr, |
| 230 | char *buf) | 232 | char *buf) |
| 231 | { | 233 | { |
| 232 | return snprintf(buf, PAGE_SIZE, "%s\n", dev->name); | 234 | return scnprintf(buf, PAGE_SIZE, "%s\n", dev->name); |
| 233 | } | 235 | } |
| 234 | 236 | ||
| 235 | static ssize_t store_name(struct device *dev, struct device_attribute *attr, | 237 | static ssize_t store_name(struct device *dev, struct device_attribute *attr, |
diff --git a/Documentation/filesystems/ubifs.txt b/Documentation/filesystems/ubifs.txt index 12fedb7834c6..d7b13b01e980 100644 --- a/Documentation/filesystems/ubifs.txt +++ b/Documentation/filesystems/ubifs.txt | |||
| @@ -82,12 +82,12 @@ Mount options | |||
| 82 | bulk_read read more in one go to take advantage of flash | 82 | bulk_read read more in one go to take advantage of flash |
| 83 | media that read faster sequentially | 83 | media that read faster sequentially |
| 84 | no_bulk_read (*) do not bulk-read | 84 | no_bulk_read (*) do not bulk-read |
| 85 | no_chk_data_crc skip checking of CRCs on data nodes in order to | 85 | no_chk_data_crc (*) skip checking of CRCs on data nodes in order to |
| 86 | improve read performance. Use this option only | 86 | improve read performance. Use this option only |
| 87 | if the flash media is highly reliable. The effect | 87 | if the flash media is highly reliable. The effect |
| 88 | of this option is that corruption of the contents | 88 | of this option is that corruption of the contents |
| 89 | of a file can go unnoticed. | 89 | of a file can go unnoticed. |
| 90 | chk_data_crc (*) do not skip checking CRCs on data nodes | 90 | chk_data_crc do not skip checking CRCs on data nodes |
| 91 | compr=none override default compressor and set it to "none" | 91 | compr=none override default compressor and set it to "none" |
| 92 | compr=lzo override default compressor and set it to "lzo" | 92 | compr=lzo override default compressor and set it to "lzo" |
| 93 | compr=zlib override default compressor and set it to "zlib" | 93 | compr=zlib override default compressor and set it to "zlib" |
diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index 94cf97b901d7..21a7dc467bba 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt | |||
| @@ -95,10 +95,11 @@ functions: | |||
| 95 | extern int unregister_filesystem(struct file_system_type *); | 95 | extern int unregister_filesystem(struct file_system_type *); |
| 96 | 96 | ||
| 97 | The passed struct file_system_type describes your filesystem. When a | 97 | The passed struct file_system_type describes your filesystem. When a |
| 98 | request is made to mount a device onto a directory in your filespace, | 98 | request is made to mount a filesystem onto a directory in your namespace, |
| 99 | the VFS will call the appropriate get_sb() method for the specific | 99 | the VFS will call the appropriate mount() method for the specific |
| 100 | filesystem. The dentry for the mount point will then be updated to | 100 | filesystem. New vfsmount referring to the tree returned by ->mount() |
| 101 | point to the root inode for the new filesystem. | 101 | will be attached to the mountpoint, so that when pathname resolution |
| 102 | reaches the mountpoint it will jump into the root of that vfsmount. | ||
| 102 | 103 | ||
| 103 | You can see all filesystems that are registered to the kernel in the | 104 | You can see all filesystems that are registered to the kernel in the |
| 104 | file /proc/filesystems. | 105 | file /proc/filesystems. |
| @@ -107,14 +108,14 @@ file /proc/filesystems. | |||
| 107 | struct file_system_type | 108 | struct file_system_type |
| 108 | ----------------------- | 109 | ----------------------- |
| 109 | 110 | ||
| 110 | This describes the filesystem. As of kernel 2.6.22, the following | 111 | This describes the filesystem. As of kernel 2.6.39, the following |
| 111 | members are defined: | 112 | members are defined: |
| 112 | 113 | ||
| 113 | struct file_system_type { | 114 | struct file_system_type { |
| 114 | const char *name; | 115 | const char *name; |
| 115 | int fs_flags; | 116 | int fs_flags; |
| 116 | int (*get_sb) (struct file_system_type *, int, | 117 | struct dentry (*mount) (struct file_system_type *, int, |
| 117 | const char *, void *, struct vfsmount *); | 118 | const char *, void *); |
| 118 | void (*kill_sb) (struct super_block *); | 119 | void (*kill_sb) (struct super_block *); |
| 119 | struct module *owner; | 120 | struct module *owner; |
| 120 | struct file_system_type * next; | 121 | struct file_system_type * next; |
| @@ -128,11 +129,11 @@ struct file_system_type { | |||
| 128 | 129 | ||
| 129 | fs_flags: various flags (i.e. FS_REQUIRES_DEV, FS_NO_DCACHE, etc.) | 130 | fs_flags: various flags (i.e. FS_REQUIRES_DEV, FS_NO_DCACHE, etc.) |
| 130 | 131 | ||
| 131 | get_sb: the method to call when a new instance of this | 132 | mount: the method to call when a new instance of this |
| 132 | filesystem should be mounted | 133 | filesystem should be mounted |
| 133 | 134 | ||
| 134 | kill_sb: the method to call when an instance of this filesystem | 135 | kill_sb: the method to call when an instance of this filesystem |
| 135 | should be unmounted | 136 | should be shut down |
| 136 | 137 | ||
| 137 | owner: for internal VFS use: you should initialize this to THIS_MODULE in | 138 | owner: for internal VFS use: you should initialize this to THIS_MODULE in |
| 138 | most cases. | 139 | most cases. |
| @@ -141,7 +142,7 @@ struct file_system_type { | |||
| 141 | 142 | ||
| 142 | s_lock_key, s_umount_key: lockdep-specific | 143 | s_lock_key, s_umount_key: lockdep-specific |
| 143 | 144 | ||
| 144 | The get_sb() method has the following arguments: | 145 | The mount() method has the following arguments: |
| 145 | 146 | ||
| 146 | struct file_system_type *fs_type: describes the filesystem, partly initialized | 147 | struct file_system_type *fs_type: describes the filesystem, partly initialized |
| 147 | by the specific filesystem code | 148 | by the specific filesystem code |
| @@ -153,32 +154,39 @@ The get_sb() method has the following arguments: | |||
| 153 | void *data: arbitrary mount options, usually comes as an ASCII | 154 | void *data: arbitrary mount options, usually comes as an ASCII |
| 154 | string (see "Mount Options" section) | 155 | string (see "Mount Options" section) |
| 155 | 156 | ||
| 156 | struct vfsmount *mnt: a vfs-internal representation of a mount point | 157 | The mount() method must return the root dentry of the tree requested by |
| 158 | caller. An active reference to its superblock must be grabbed and the | ||
| 159 | superblock must be locked. On failure it should return ERR_PTR(error). | ||
| 157 | 160 | ||
| 158 | The get_sb() method must determine if the block device specified | 161 | The arguments match those of mount(2) and their interpretation |
| 159 | in the dev_name and fs_type contains a filesystem of the type the method | 162 | depends on filesystem type. E.g. for block filesystems, dev_name is |
| 160 | supports. If it succeeds in opening the named block device, it initializes a | 163 | interpreted as block device name, that device is opened and if it |
| 161 | struct super_block descriptor for the filesystem contained by the block device. | 164 | contains a suitable filesystem image the method creates and initializes |
| 162 | On failure it returns an error. | 165 | struct super_block accordingly, returning its root dentry to caller. |
| 166 | |||
| 167 | ->mount() may choose to return a subtree of existing filesystem - it | ||
| 168 | doesn't have to create a new one. The main result from the caller's | ||
| 169 | point of view is a reference to dentry at the root of (sub)tree to | ||
| 170 | be attached; creation of new superblock is a common side effect. | ||
| 163 | 171 | ||
| 164 | The most interesting member of the superblock structure that the | 172 | The most interesting member of the superblock structure that the |
| 165 | get_sb() method fills in is the "s_op" field. This is a pointer to | 173 | mount() method fills in is the "s_op" field. This is a pointer to |
| 166 | a "struct super_operations" which describes the next level of the | 174 | a "struct super_operations" which describes the next level of the |
| 167 | filesystem implementation. | 175 | filesystem implementation. |
| 168 | 176 | ||
| 169 | Usually, a filesystem uses one of the generic get_sb() implementations | 177 | Usually, a filesystem uses one of the generic mount() implementations |
| 170 | and provides a fill_super() method instead. The generic methods are: | 178 | and provides a fill_super() callback instead. The generic variants are: |
| 171 | 179 | ||
| 172 | get_sb_bdev: mount a filesystem residing on a block device | 180 | mount_bdev: mount a filesystem residing on a block device |
| 173 | 181 | ||
| 174 | get_sb_nodev: mount a filesystem that is not backed by a device | 182 | mount_nodev: mount a filesystem that is not backed by a device |
| 175 | 183 | ||
| 176 | get_sb_single: mount a filesystem which shares the instance between | 184 | mount_single: mount a filesystem which shares the instance between |
| 177 | all mounts | 185 | all mounts |
| 178 | 186 | ||
| 179 | A fill_super() method implementation has the following arguments: | 187 | A fill_super() callback implementation has the following arguments: |
| 180 | 188 | ||
| 181 | struct super_block *sb: the superblock structure. The method fill_super() | 189 | struct super_block *sb: the superblock structure. The callback |
| 182 | must initialize this properly. | 190 | must initialize this properly. |
| 183 | 191 | ||
| 184 | void *data: arbitrary mount options, usually comes as an ASCII | 192 | void *data: arbitrary mount options, usually comes as an ASCII |
| @@ -246,7 +254,7 @@ or bottom half). | |||
| 246 | should be synchronous or not, not all filesystems check this flag. | 254 | should be synchronous or not, not all filesystems check this flag. |
| 247 | 255 | ||
| 248 | drop_inode: called when the last access to the inode is dropped, | 256 | drop_inode: called when the last access to the inode is dropped, |
| 249 | with the inode_lock spinlock held. | 257 | with the inode->i_lock spinlock held. |
| 250 | 258 | ||
| 251 | This method should be either NULL (normal UNIX filesystem | 259 | This method should be either NULL (normal UNIX filesystem |
| 252 | semantics) or "generic_delete_inode" (for filesystems that do not | 260 | semantics) or "generic_delete_inode" (for filesystems that do not |
| @@ -865,7 +873,7 @@ struct dentry_operations { | |||
| 865 | void (*d_iput)(struct dentry *, struct inode *); | 873 | void (*d_iput)(struct dentry *, struct inode *); |
| 866 | char *(*d_dname)(struct dentry *, char *, int); | 874 | char *(*d_dname)(struct dentry *, char *, int); |
| 867 | struct vfsmount *(*d_automount)(struct path *); | 875 | struct vfsmount *(*d_automount)(struct path *); |
| 868 | int (*d_manage)(struct dentry *, bool, bool); | 876 | int (*d_manage)(struct dentry *, bool); |
| 869 | }; | 877 | }; |
| 870 | 878 | ||
| 871 | d_revalidate: called when the VFS needs to revalidate a dentry. This | 879 | d_revalidate: called when the VFS needs to revalidate a dentry. This |
| @@ -961,10 +969,6 @@ struct dentry_operations { | |||
| 961 | mounted on it and not to check the automount flag. Any other error | 969 | mounted on it and not to check the automount flag. Any other error |
| 962 | code will abort pathwalk completely. | 970 | code will abort pathwalk completely. |
| 963 | 971 | ||
| 964 | If the 'mounting_here' parameter is true, then namespace_sem is being | ||
| 965 | held by the caller and the function should not initiate any mounts or | ||
| 966 | unmounts that it will then wait for. | ||
| 967 | |||
| 968 | If the 'rcu_walk' parameter is true, then the caller is doing a | 972 | If the 'rcu_walk' parameter is true, then the caller is doing a |
| 969 | pathwalk in RCU-walk mode. Sleeping is not permitted in this mode, | 973 | pathwalk in RCU-walk mode. Sleeping is not permitted in this mode, |
| 970 | and the caller can be asked to leave it and call again by returing | 974 | and the caller can be asked to leave it and call again by returing |
diff --git a/Documentation/filesystems/xfs-delayed-logging-design.txt b/Documentation/filesystems/xfs-delayed-logging-design.txt index 7445bf335dae..2ce36439c09f 100644 --- a/Documentation/filesystems/xfs-delayed-logging-design.txt +++ b/Documentation/filesystems/xfs-delayed-logging-design.txt | |||
| @@ -42,7 +42,7 @@ the aggregation of all the previous changes currently held only in the log. | |||
| 42 | This relogging technique also allows objects to be moved forward in the log so | 42 | This relogging technique also allows objects to be moved forward in the log so |
| 43 | that an object being relogged does not prevent the tail of the log from ever | 43 | that an object being relogged does not prevent the tail of the log from ever |
| 44 | moving forward. This can be seen in the table above by the changing | 44 | moving forward. This can be seen in the table above by the changing |
| 45 | (increasing) LSN of each subsquent transaction - the LSN is effectively a | 45 | (increasing) LSN of each subsequent transaction - the LSN is effectively a |
| 46 | direct encoding of the location in the log of the transaction. | 46 | direct encoding of the location in the log of the transaction. |
| 47 | 47 | ||
| 48 | This relogging is also used to implement long-running, multiple-commit | 48 | This relogging is also used to implement long-running, multiple-commit |
| @@ -338,7 +338,7 @@ the same time another transaction modifies the item and inserts the log item | |||
| 338 | into the new CIL, then checkpoint transaction commit code cannot use log items | 338 | into the new CIL, then checkpoint transaction commit code cannot use log items |
| 339 | to store the list of log vectors that need to be written into the transaction. | 339 | to store the list of log vectors that need to be written into the transaction. |
| 340 | Hence log vectors need to be able to be chained together to allow them to be | 340 | Hence log vectors need to be able to be chained together to allow them to be |
| 341 | detatched from the log items. That is, when the CIL is flushed the memory | 341 | detached from the log items. That is, when the CIL is flushed the memory |
| 342 | buffer and log vector attached to each log item needs to be attached to the | 342 | buffer and log vector attached to each log item needs to be attached to the |
| 343 | checkpoint context so that the log item can be released. In diagrammatic form, | 343 | checkpoint context so that the log item can be released. In diagrammatic form, |
| 344 | the CIL would look like this before the flush: | 344 | the CIL would look like this before the flush: |
| @@ -577,7 +577,7 @@ only becomes unpinned when all the transactions complete and there are no | |||
| 577 | pending transactions. Thus the pinning and unpinning of a log item is symmetric | 577 | pending transactions. Thus the pinning and unpinning of a log item is symmetric |
| 578 | as there is a 1:1 relationship with transaction commit and log item completion. | 578 | as there is a 1:1 relationship with transaction commit and log item completion. |
| 579 | 579 | ||
| 580 | For delayed logging, however, we have an assymetric transaction commit to | 580 | For delayed logging, however, we have an asymmetric transaction commit to |
| 581 | completion relationship. Every time an object is relogged in the CIL it goes | 581 | completion relationship. Every time an object is relogged in the CIL it goes |
| 582 | through the commit process without a corresponding completion being registered. | 582 | through the commit process without a corresponding completion being registered. |
| 583 | That is, we now have a many-to-one relationship between transaction commit and | 583 | That is, we now have a many-to-one relationship between transaction commit and |
| @@ -780,7 +780,7 @@ With delayed logging, there are new steps inserted into the life cycle: | |||
| 780 | From this, it can be seen that the only life cycle differences between the two | 780 | From this, it can be seen that the only life cycle differences between the two |
| 781 | logging methods are in the middle of the life cycle - they still have the same | 781 | logging methods are in the middle of the life cycle - they still have the same |
| 782 | beginning and end and execution constraints. The only differences are in the | 782 | beginning and end and execution constraints. The only differences are in the |
| 783 | commiting of the log items to the log itself and the completion processing. | 783 | committing of the log items to the log itself and the completion processing. |
| 784 | Hence delayed logging should not introduce any constraints on log item | 784 | Hence delayed logging should not introduce any constraints on log item |
| 785 | behaviour, allocation or freeing that don't already exist. | 785 | behaviour, allocation or freeing that don't already exist. |
| 786 | 786 | ||
| @@ -791,10 +791,3 @@ mount option. Fundamentally, there is no reason why the log manager would not | |||
| 791 | be able to swap methods automatically and transparently depending on load | 791 | be able to swap methods automatically and transparently depending on load |
| 792 | characteristics, but this should not be necessary if delayed logging works as | 792 | characteristics, but this should not be necessary if delayed logging works as |
| 793 | designed. | 793 | designed. |
| 794 | |||
| 795 | Roadmap: | ||
| 796 | |||
| 797 | 2.6.39 Switch default mount option to use delayed logging | ||
| 798 | => should be roughly 12 months after initial merge | ||
| 799 | => enough time to shake out remaining problems before next round of | ||
| 800 | enterprise distro kernel rebases | ||
diff --git a/Documentation/hwmon/abituguru b/Documentation/hwmon/abituguru index 5eb3b9d5f0d5..915f32063a26 100644 --- a/Documentation/hwmon/abituguru +++ b/Documentation/hwmon/abituguru | |||
| @@ -78,7 +78,7 @@ motherboards (most modern Abit motherboards). | |||
| 78 | 78 | ||
| 79 | The first and second revision of the uGuru chip in reality is a Winbond | 79 | The first and second revision of the uGuru chip in reality is a Winbond |
| 80 | W83L950D in disguise (despite Abit claiming it is "a new microprocessor | 80 | W83L950D in disguise (despite Abit claiming it is "a new microprocessor |
| 81 | designed by the ABIT Engineers"). Unfortunatly this doesn't help since the | 81 | designed by the ABIT Engineers"). Unfortunately this doesn't help since the |
| 82 | W83L950D is a generic microcontroller with a custom Abit application running | 82 | W83L950D is a generic microcontroller with a custom Abit application running |
| 83 | on it. | 83 | on it. |
| 84 | 84 | ||
diff --git a/Documentation/hwmon/abituguru-datasheet b/Documentation/hwmon/abituguru-datasheet index d9251efdcec7..8d2be8a0b1e3 100644 --- a/Documentation/hwmon/abituguru-datasheet +++ b/Documentation/hwmon/abituguru-datasheet | |||
| @@ -5,9 +5,9 @@ First of all, what I know about uGuru is no fact based on any help, hints or | |||
| 5 | datasheet from Abit. The data I have got on uGuru have I assembled through | 5 | datasheet from Abit. The data I have got on uGuru have I assembled through |
| 6 | my weak knowledge in "backwards engineering". | 6 | my weak knowledge in "backwards engineering". |
| 7 | And just for the record, you may have noticed uGuru isn't a chip developed by | 7 | And just for the record, you may have noticed uGuru isn't a chip developed by |
| 8 | Abit, as they claim it to be. It's realy just an microprocessor (uC) created by | 8 | Abit, as they claim it to be. It's really just an microprocessor (uC) created by |
| 9 | Winbond (W83L950D). And no, reading the manual for this specific uC or | 9 | Winbond (W83L950D). And no, reading the manual for this specific uC or |
| 10 | mailing Windbond for help won't give any usefull data about uGuru, as it is | 10 | mailing Windbond for help won't give any useful data about uGuru, as it is |
| 11 | the program inside the uC that is responding to calls. | 11 | the program inside the uC that is responding to calls. |
| 12 | 12 | ||
| 13 | Olle Sandberg <ollebull@gmail.com>, 2005-05-25 | 13 | Olle Sandberg <ollebull@gmail.com>, 2005-05-25 |
| @@ -41,7 +41,7 @@ later on attached again data-port will hold 0x08, more about this later. | |||
| 41 | 41 | ||
| 42 | After wider testing of the Linux kernel driver some variants of the uGuru have | 42 | After wider testing of the Linux kernel driver some variants of the uGuru have |
| 43 | turned up which will hold 0x00 instead of 0xAC at the CMD port, thus we also | 43 | turned up which will hold 0x00 instead of 0xAC at the CMD port, thus we also |
| 44 | have to test CMD for two different values. On these uGuru's DATA will initally | 44 | have to test CMD for two different values. On these uGuru's DATA will initially |
| 45 | hold 0x09 and will only hold 0x08 after reading CMD first, so CMD must be read | 45 | hold 0x09 and will only hold 0x08 after reading CMD first, so CMD must be read |
| 46 | first! | 46 | first! |
| 47 | 47 | ||
| @@ -308,5 +308,5 @@ the voltage / clock programming out, I tried reading and only reading banks | |||
| 308 | resulted in a _permanent_ reprogramming of the voltages, luckily I had the | 308 | resulted in a _permanent_ reprogramming of the voltages, luckily I had the |
| 309 | sensors part configured so that it would shutdown my system on any out of spec | 309 | sensors part configured so that it would shutdown my system on any out of spec |
| 310 | voltages which proprably safed my computer (after a reboot I managed to | 310 | voltages which proprably safed my computer (after a reboot I managed to |
| 311 | immediatly enter the bios and reload the defaults). This probably means that | 311 | immediately enter the bios and reload the defaults). This probably means that |
| 312 | the read/write cycle for the non sensor part is different from the sensor part. | 312 | the read/write cycle for the non sensor part is different from the sensor part. |
diff --git a/Documentation/hwmon/abituguru3 b/Documentation/hwmon/abituguru3 index fa598aac22fa..a6ccfe4bb6aa 100644 --- a/Documentation/hwmon/abituguru3 +++ b/Documentation/hwmon/abituguru3 | |||
| @@ -47,7 +47,7 @@ This driver supports the hardware monitoring features of the third revision of | |||
| 47 | the Abit uGuru chip, found on recent Abit uGuru featuring motherboards. | 47 | the Abit uGuru chip, found on recent Abit uGuru featuring motherboards. |
| 48 | 48 | ||
| 49 | The 3rd revision of the uGuru chip in reality is a Winbond W83L951G. | 49 | The 3rd revision of the uGuru chip in reality is a Winbond W83L951G. |
| 50 | Unfortunatly this doesn't help since the W83L951G is a generic microcontroller | 50 | Unfortunately this doesn't help since the W83L951G is a generic microcontroller |
| 51 | with a custom Abit application running on it. | 51 | with a custom Abit application running on it. |
| 52 | 52 | ||
| 53 | Despite Abit not releasing any information regarding the uGuru revision 3, | 53 | Despite Abit not releasing any information regarding the uGuru revision 3, |
diff --git a/Documentation/hwmon/ads1015 b/Documentation/hwmon/ads1015 new file mode 100644 index 000000000000..f6fe9c203733 --- /dev/null +++ b/Documentation/hwmon/ads1015 | |||
| @@ -0,0 +1,72 @@ | |||
| 1 | Kernel driver ads1015 | ||
| 2 | ===================== | ||
| 3 | |||
| 4 | Supported chips: | ||
| 5 | * Texas Instruments ADS1015 | ||
| 6 | Prefix: 'ads1015' | ||
| 7 | Datasheet: Publicly available at the Texas Instruments website : | ||
| 8 | http://focus.ti.com/lit/ds/symlink/ads1015.pdf | ||
| 9 | |||
| 10 | Authors: | ||
| 11 | Dirk Eibach, Guntermann & Drunck GmbH <eibach@gdsys.de> | ||
| 12 | |||
| 13 | Description | ||
| 14 | ----------- | ||
| 15 | |||
| 16 | This driver implements support for the Texas Instruments ADS1015. | ||
| 17 | |||
| 18 | This device is a 12-bit A-D converter with 4 inputs. | ||
| 19 | |||
| 20 | The inputs can be used single ended or in certain differential combinations. | ||
| 21 | |||
| 22 | The inputs can be made available by 8 sysfs input files in0_input - in7_input: | ||
| 23 | in0: Voltage over AIN0 and AIN1. | ||
| 24 | in1: Voltage over AIN0 and AIN3. | ||
| 25 | in2: Voltage over AIN1 and AIN3. | ||
| 26 | in3: Voltage over AIN2 and AIN3. | ||
| 27 | in4: Voltage over AIN0 and GND. | ||
| 28 | in5: Voltage over AIN1 and GND. | ||
| 29 | in6: Voltage over AIN2 and GND. | ||
| 30 | in7: Voltage over AIN3 and GND. | ||
| 31 | |||
| 32 | Which inputs are available can be configured using platform data or devicetree. | ||
| 33 | |||
| 34 | By default all inputs are exported. | ||
| 35 | |||
| 36 | Platform Data | ||
| 37 | ------------- | ||
| 38 | |||
| 39 | In linux/i2c/ads1015.h platform data is defined, channel_data contains | ||
| 40 | configuration data for the used input combinations: | ||
| 41 | - pga is the programmable gain amplifier (values are full scale) | ||
| 42 | 0: +/- 6.144 V | ||
| 43 | 1: +/- 4.096 V | ||
| 44 | 2: +/- 2.048 V | ||
| 45 | 3: +/- 1.024 V | ||
| 46 | 4: +/- 0.512 V | ||
| 47 | 5: +/- 0.256 V | ||
| 48 | - data_rate in samples per second | ||
| 49 | 0: 128 | ||
| 50 | 1: 250 | ||
| 51 | 2: 490 | ||
| 52 | 3: 920 | ||
| 53 | 4: 1600 | ||
| 54 | 5: 2400 | ||
| 55 | 6: 3300 | ||
| 56 | |||
| 57 | Example: | ||
| 58 | struct ads1015_platform_data data = { | ||
| 59 | .channel_data = { | ||
| 60 | [2] = { .enabled = true, .pga = 1, .data_rate = 0 }, | ||
| 61 | [4] = { .enabled = true, .pga = 4, .data_rate = 5 }, | ||
| 62 | } | ||
| 63 | }; | ||
| 64 | |||
| 65 | In this case only in2_input (FS +/- 4.096 V, 128 SPS) and in4_input | ||
| 66 | (FS +/- 0.512 V, 2400 SPS) would be created. | ||
| 67 | |||
| 68 | Devicetree | ||
| 69 | ---------- | ||
| 70 | |||
| 71 | Configuration is also possible via devicetree: | ||
| 72 | Documentation/devicetree/bindings/hwmon/ads1015.txt | ||
diff --git a/Documentation/hwmon/f71882fg b/Documentation/hwmon/f71882fg index a7952c2bd959..df02245d1419 100644 --- a/Documentation/hwmon/f71882fg +++ b/Documentation/hwmon/f71882fg | |||
| @@ -2,6 +2,10 @@ Kernel driver f71882fg | |||
| 2 | ====================== | 2 | ====================== |
| 3 | 3 | ||
| 4 | Supported chips: | 4 | Supported chips: |
| 5 | * Fintek F71808E | ||
| 6 | Prefix: 'f71808e' | ||
| 7 | Addresses scanned: none, address read from Super I/O config space | ||
| 8 | Datasheet: Not public | ||
| 5 | * Fintek F71858FG | 9 | * Fintek F71858FG |
| 6 | Prefix: 'f71858fg' | 10 | Prefix: 'f71858fg' |
| 7 | Addresses scanned: none, address read from Super I/O config space | 11 | Addresses scanned: none, address read from Super I/O config space |
| @@ -10,6 +14,10 @@ Supported chips: | |||
| 10 | Prefix: 'f71862fg' | 14 | Prefix: 'f71862fg' |
| 11 | Addresses scanned: none, address read from Super I/O config space | 15 | Addresses scanned: none, address read from Super I/O config space |
| 12 | Datasheet: Available from the Fintek website | 16 | Datasheet: Available from the Fintek website |
| 17 | * Fintek F71869F and F71869E | ||
| 18 | Prefix: 'f71869' | ||
| 19 | Addresses scanned: none, address read from Super I/O config space | ||
| 20 | Datasheet: Available from the Fintek website | ||
| 13 | * Fintek F71882FG and F71883FG | 21 | * Fintek F71882FG and F71883FG |
| 14 | Prefix: 'f71882fg' | 22 | Prefix: 'f71882fg' |
| 15 | Addresses scanned: none, address read from Super I/O config space | 23 | Addresses scanned: none, address read from Super I/O config space |
| @@ -17,11 +25,30 @@ Supported chips: | |||
| 17 | * Fintek F71889FG | 25 | * Fintek F71889FG |
| 18 | Prefix: 'f71889fg' | 26 | Prefix: 'f71889fg' |
| 19 | Addresses scanned: none, address read from Super I/O config space | 27 | Addresses scanned: none, address read from Super I/O config space |
| 28 | Datasheet: Available from the Fintek website | ||
| 29 | * Fintek F71889ED | ||
| 30 | Prefix: 'f71889ed' | ||
| 31 | Addresses scanned: none, address read from Super I/O config space | ||
| 32 | Datasheet: Should become available on the Fintek website soon | ||
| 33 | * Fintek F71889A | ||
| 34 | Prefix: 'f71889a' | ||
| 35 | Addresses scanned: none, address read from Super I/O config space | ||
| 20 | Datasheet: Should become available on the Fintek website soon | 36 | Datasheet: Should become available on the Fintek website soon |
| 21 | * Fintek F8000 | 37 | * Fintek F8000 |
| 22 | Prefix: 'f8000' | 38 | Prefix: 'f8000' |
| 23 | Addresses scanned: none, address read from Super I/O config space | 39 | Addresses scanned: none, address read from Super I/O config space |
| 24 | Datasheet: Not public | 40 | Datasheet: Not public |
| 41 | * Fintek F81801U | ||
| 42 | Prefix: 'f71889fg' | ||
| 43 | Addresses scanned: none, address read from Super I/O config space | ||
| 44 | Datasheet: Not public | ||
| 45 | Note: This is the 64-pin variant of the F71889FG, they have the | ||
| 46 | same device ID and are fully compatible as far as hardware | ||
| 47 | monitoring is concerned. | ||
| 48 | * Fintek F81865F | ||
| 49 | Prefix: 'f81865f' | ||
| 50 | Addresses scanned: none, address read from Super I/O config space | ||
| 51 | Datasheet: Available from the Fintek website | ||
| 25 | 52 | ||
| 26 | Author: Hans de Goede <hdegoede@redhat.com> | 53 | Author: Hans de Goede <hdegoede@redhat.com> |
| 27 | 54 | ||
| @@ -29,9 +56,9 @@ Author: Hans de Goede <hdegoede@redhat.com> | |||
| 29 | Description | 56 | Description |
| 30 | ----------- | 57 | ----------- |
| 31 | 58 | ||
| 32 | Fintek F718xxFG/F8000 Super I/O chips include complete hardware monitoring | 59 | Fintek F718xx/F8000 Super I/O chips include complete hardware monitoring |
| 33 | capabilities. They can monitor up to 9 voltages (3 for the F8000), 4 fans and | 60 | capabilities. They can monitor up to 9 voltages, 4 fans and 3 temperature |
| 34 | 3 temperature sensors. | 61 | sensors. |
| 35 | 62 | ||
| 36 | These chips also have fan controlling features, using either DC or PWM, in | 63 | These chips also have fan controlling features, using either DC or PWM, in |
| 37 | three different modes (one manual, two automatic). | 64 | three different modes (one manual, two automatic). |
| @@ -99,5 +126,5 @@ Writing an unsupported mode will result in an invalid parameter error. | |||
| 99 | The fan speed is regulated to keep the temp the fan is mapped to between | 126 | The fan speed is regulated to keep the temp the fan is mapped to between |
| 100 | temp#_auto_point2_temp and temp#_auto_point3_temp. | 127 | temp#_auto_point2_temp and temp#_auto_point3_temp. |
| 101 | 128 | ||
| 102 | Both of the automatic modes require that pwm1 corresponds to fan1, pwm2 to | 129 | All of the automatic modes require that pwm1 corresponds to fan1, pwm2 to |
| 103 | fan2 and pwm3 to fan3. | 130 | fan2 and pwm3 to fan3. |
diff --git a/Documentation/hwmon/jc42 b/Documentation/hwmon/jc42 index 0e76ef12e4c6..a22ecf48f255 100644 --- a/Documentation/hwmon/jc42 +++ b/Documentation/hwmon/jc42 | |||
| @@ -51,7 +51,8 @@ Supported chips: | |||
| 51 | * JEDEC JC 42.4 compliant temperature sensor chips | 51 | * JEDEC JC 42.4 compliant temperature sensor chips |
| 52 | Prefix: 'jc42' | 52 | Prefix: 'jc42' |
| 53 | Addresses scanned: I2C 0x18 - 0x1f | 53 | Addresses scanned: I2C 0x18 - 0x1f |
| 54 | Datasheet: - | 54 | Datasheet: |
| 55 | http://www.jedec.org/sites/default/files/docs/4_01_04R19.pdf | ||
| 55 | 56 | ||
| 56 | Author: | 57 | Author: |
| 57 | Guenter Roeck <guenter.roeck@ericsson.com> | 58 | Guenter Roeck <guenter.roeck@ericsson.com> |
| @@ -60,7 +61,11 @@ Author: | |||
| 60 | Description | 61 | Description |
| 61 | ----------- | 62 | ----------- |
| 62 | 63 | ||
| 63 | This driver implements support for JEDEC JC 42.4 compliant temperature sensors. | 64 | This driver implements support for JEDEC JC 42.4 compliant temperature sensors, |
| 65 | which are used on many DDR3 memory modules for mobile devices and servers. Some | ||
| 66 | systems use the sensor to prevent memory overheating by automatically throttling | ||
| 67 | the memory controller. | ||
| 68 | |||
| 64 | The driver auto-detects the chips listed above, but can be manually instantiated | 69 | The driver auto-detects the chips listed above, but can be manually instantiated |
| 65 | to support other JC 42.4 compliant chips. | 70 | to support other JC 42.4 compliant chips. |
| 66 | 71 | ||
| @@ -81,15 +86,19 @@ limits. The chip supports only a single register to configure the hysteresis, | |||
| 81 | which applies to all limits. This register can be written by writing into | 86 | which applies to all limits. This register can be written by writing into |
| 82 | temp1_crit_hyst. Other hysteresis attributes are read-only. | 87 | temp1_crit_hyst. Other hysteresis attributes are read-only. |
| 83 | 88 | ||
| 89 | If the BIOS has configured the sensor for automatic temperature management, it | ||
| 90 | is likely that it has locked the registers, i.e., that the temperature limits | ||
| 91 | cannot be changed. | ||
| 92 | |||
| 84 | Sysfs entries | 93 | Sysfs entries |
| 85 | ------------- | 94 | ------------- |
| 86 | 95 | ||
| 87 | temp1_input Temperature (RO) | 96 | temp1_input Temperature (RO) |
| 88 | temp1_min Minimum temperature (RW) | 97 | temp1_min Minimum temperature (RO or RW) |
| 89 | temp1_max Maximum temperature (RW) | 98 | temp1_max Maximum temperature (RO or RW) |
| 90 | temp1_crit Critical high temperature (RW) | 99 | temp1_crit Critical high temperature (RO or RW) |
| 91 | 100 | ||
| 92 | temp1_crit_hyst Critical hysteresis temperature (RW) | 101 | temp1_crit_hyst Critical hysteresis temperature (RO or RW) |
| 93 | temp1_max_hyst Maximum hysteresis temperature (RO) | 102 | temp1_max_hyst Maximum hysteresis temperature (RO) |
| 94 | 103 | ||
| 95 | temp1_min_alarm Temperature low alarm | 104 | temp1_min_alarm Temperature low alarm |
diff --git a/Documentation/hwmon/k10temp b/Documentation/hwmon/k10temp index 6526eee525a6..d2b56a4fd1f5 100644 --- a/Documentation/hwmon/k10temp +++ b/Documentation/hwmon/k10temp | |||
| @@ -9,6 +9,8 @@ Supported chips: | |||
| 9 | Socket S1G3: Athlon II, Sempron, Turion II | 9 | Socket S1G3: Athlon II, Sempron, Turion II |
| 10 | * AMD Family 11h processors: | 10 | * AMD Family 11h processors: |
| 11 | Socket S1G2: Athlon (X2), Sempron (X2), Turion X2 (Ultra) | 11 | Socket S1G2: Athlon (X2), Sempron (X2), Turion X2 (Ultra) |
| 12 | * AMD Family 12h processors: "Llano" | ||
| 13 | * AMD Family 14h processors: "Brazos" (C/E/G-Series) | ||
| 12 | 14 | ||
| 13 | Prefix: 'k10temp' | 15 | Prefix: 'k10temp' |
| 14 | Addresses scanned: PCI space | 16 | Addresses scanned: PCI space |
| @@ -17,10 +19,14 @@ Supported chips: | |||
| 17 | http://support.amd.com/us/Processor_TechDocs/31116.pdf | 19 | http://support.amd.com/us/Processor_TechDocs/31116.pdf |
| 18 | BIOS and Kernel Developer's Guide (BKDG) for AMD Family 11h Processors: | 20 | BIOS and Kernel Developer's Guide (BKDG) for AMD Family 11h Processors: |
| 19 | http://support.amd.com/us/Processor_TechDocs/41256.pdf | 21 | http://support.amd.com/us/Processor_TechDocs/41256.pdf |
| 22 | BIOS and Kernel Developer's Guide (BKDG) for AMD Family 14h Models 00h-0Fh Processors: | ||
| 23 | http://support.amd.com/us/Processor_TechDocs/43170.pdf | ||
| 20 | Revision Guide for AMD Family 10h Processors: | 24 | Revision Guide for AMD Family 10h Processors: |
| 21 | http://support.amd.com/us/Processor_TechDocs/41322.pdf | 25 | http://support.amd.com/us/Processor_TechDocs/41322.pdf |
| 22 | Revision Guide for AMD Family 11h Processors: | 26 | Revision Guide for AMD Family 11h Processors: |
| 23 | http://support.amd.com/us/Processor_TechDocs/41788.pdf | 27 | http://support.amd.com/us/Processor_TechDocs/41788.pdf |
| 28 | Revision Guide for AMD Family 14h Models 00h-0Fh Processors: | ||
| 29 | http://support.amd.com/us/Processor_TechDocs/47534.pdf | ||
| 24 | AMD Family 11h Processor Power and Thermal Data Sheet for Notebooks: | 30 | AMD Family 11h Processor Power and Thermal Data Sheet for Notebooks: |
| 25 | http://support.amd.com/us/Processor_TechDocs/43373.pdf | 31 | http://support.amd.com/us/Processor_TechDocs/43373.pdf |
| 26 | AMD Family 10h Server and Workstation Processor Power and Thermal Data Sheet: | 32 | AMD Family 10h Server and Workstation Processor Power and Thermal Data Sheet: |
| @@ -34,7 +40,7 @@ Description | |||
| 34 | ----------- | 40 | ----------- |
| 35 | 41 | ||
| 36 | This driver permits reading of the internal temperature sensor of AMD | 42 | This driver permits reading of the internal temperature sensor of AMD |
| 37 | Family 10h and 11h processors. | 43 | Family 10h/11h/12h/14h processors. |
| 38 | 44 | ||
| 39 | All these processors have a sensor, but on those for Socket F or AM2+, | 45 | All these processors have a sensor, but on those for Socket F or AM2+, |
| 40 | the sensor may return inconsistent values (erratum 319). The driver | 46 | the sensor may return inconsistent values (erratum 319). The driver |
diff --git a/Documentation/hwmon/lineage-pem b/Documentation/hwmon/lineage-pem new file mode 100644 index 000000000000..2ba5ed126858 --- /dev/null +++ b/Documentation/hwmon/lineage-pem | |||
| @@ -0,0 +1,77 @@ | |||
| 1 | Kernel driver lineage-pem | ||
| 2 | ========================= | ||
| 3 | |||
| 4 | Supported devices: | ||
| 5 | * Lineage Compact Power Line Power Entry Modules | ||
| 6 | Prefix: 'lineage-pem' | ||
| 7 | Addresses scanned: - | ||
| 8 | Documentation: | ||
| 9 | http://www.lineagepower.com/oem/pdf/CPLI2C.pdf | ||
| 10 | |||
| 11 | Author: Guenter Roeck <guenter.roeck@ericsson.com> | ||
| 12 | |||
| 13 | |||
| 14 | Description | ||
| 15 | ----------- | ||
| 16 | |||
| 17 | This driver supports various Lineage Compact Power Line DC/DC and AC/DC | ||
| 18 | converters such as CP1800, CP2000AC, CP2000DC, CP2100DC, and others. | ||
| 19 | |||
| 20 | Lineage CPL power entry modules are nominally PMBus compliant. However, most | ||
| 21 | standard PMBus commands are not supported. Specifically, all hardware monitoring | ||
| 22 | and status reporting commands are non-standard. For this reason, a standard | ||
| 23 | PMBus driver can not be used. | ||
| 24 | |||
| 25 | |||
| 26 | Usage Notes | ||
| 27 | ----------- | ||
| 28 | |||
| 29 | This driver does not probe for Lineage CPL devices, since there is no register | ||
| 30 | which can be safely used to identify the chip. You will have to instantiate | ||
| 31 | the devices explicitly. | ||
| 32 | |||
| 33 | Example: the following will load the driver for a Lineage PEM at address 0x40 | ||
| 34 | on I2C bus #1: | ||
| 35 | $ modprobe lineage-pem | ||
| 36 | $ echo lineage-pem 0x40 > /sys/bus/i2c/devices/i2c-1/new_device | ||
| 37 | |||
| 38 | All Lineage CPL power entry modules have a built-in I2C bus master selector | ||
| 39 | (PCA9541). To ensure device access, this driver should only be used as client | ||
| 40 | driver to the pca9541 I2C master selector driver. | ||
| 41 | |||
| 42 | |||
| 43 | Sysfs entries | ||
| 44 | ------------- | ||
| 45 | |||
| 46 | All Lineage CPL devices report output voltage and device temperature as well as | ||
| 47 | alarms for output voltage, temperature, input voltage, input current, input power, | ||
| 48 | and fan status. | ||
| 49 | |||
| 50 | Input voltage, input current, input power, and fan speed measurement is only | ||
| 51 | supported on newer devices. The driver detects if those attributes are supported, | ||
| 52 | and only creates respective sysfs entries if they are. | ||
| 53 | |||
| 54 | in1_input Output voltage (mV) | ||
| 55 | in1_min_alarm Output undervoltage alarm | ||
| 56 | in1_max_alarm Output overvoltage alarm | ||
| 57 | in1_crit Output voltage critical alarm | ||
| 58 | |||
| 59 | in2_input Input voltage (mV, optional) | ||
| 60 | in2_alarm Input voltage alarm | ||
| 61 | |||
| 62 | curr1_input Input current (mA, optional) | ||
| 63 | curr1_alarm Input overcurrent alarm | ||
| 64 | |||
| 65 | power1_input Input power (uW, optional) | ||
| 66 | power1_alarm Input power alarm | ||
| 67 | |||
| 68 | fan1_input Fan 1 speed (rpm, optional) | ||
| 69 | fan2_input Fan 2 speed (rpm, optional) | ||
| 70 | fan3_input Fan 3 speed (rpm, optional) | ||
| 71 | |||
| 72 | temp1_input | ||
| 73 | temp1_max | ||
| 74 | temp1_crit | ||
| 75 | temp1_alarm | ||
| 76 | temp1_crit_alarm | ||
| 77 | temp1_fault | ||
diff --git a/Documentation/hwmon/lm75 b/Documentation/hwmon/lm75 index 8e6356fe05d7..a1790401fdde 100644 --- a/Documentation/hwmon/lm75 +++ b/Documentation/hwmon/lm75 | |||
| @@ -7,6 +7,11 @@ Supported chips: | |||
| 7 | Addresses scanned: I2C 0x48 - 0x4f | 7 | Addresses scanned: I2C 0x48 - 0x4f |
| 8 | Datasheet: Publicly available at the National Semiconductor website | 8 | Datasheet: Publicly available at the National Semiconductor website |
| 9 | http://www.national.com/ | 9 | http://www.national.com/ |
| 10 | * National Semiconductor LM75A | ||
| 11 | Prefix: 'lm75a' | ||
| 12 | Addresses scanned: I2C 0x48 - 0x4f | ||
| 13 | Datasheet: Publicly available at the National Semiconductor website | ||
| 14 | http://www.national.com/ | ||
| 10 | * Dallas Semiconductor DS75 | 15 | * Dallas Semiconductor DS75 |
| 11 | Prefix: 'lm75' | 16 | Prefix: 'lm75' |
| 12 | Addresses scanned: I2C 0x48 - 0x4f | 17 | Addresses scanned: I2C 0x48 - 0x4f |
diff --git a/Documentation/hwmon/lm85 b/Documentation/hwmon/lm85 index 239258a63c81..7c49feaa79d2 100644 --- a/Documentation/hwmon/lm85 +++ b/Documentation/hwmon/lm85 | |||
| @@ -26,6 +26,14 @@ Supported chips: | |||
| 26 | Prefix: 'emc6d102' | 26 | Prefix: 'emc6d102' |
| 27 | Addresses scanned: I2C 0x2c, 0x2d, 0x2e | 27 | Addresses scanned: I2C 0x2c, 0x2d, 0x2e |
| 28 | Datasheet: http://www.smsc.com/main/catalog/emc6d102.html | 28 | Datasheet: http://www.smsc.com/main/catalog/emc6d102.html |
| 29 | * SMSC EMC6D103 | ||
| 30 | Prefix: 'emc6d103' | ||
| 31 | Addresses scanned: I2C 0x2c, 0x2d, 0x2e | ||
| 32 | Datasheet: http://www.smsc.com/main/catalog/emc6d103.html | ||
| 33 | * SMSC EMC6D103S | ||
| 34 | Prefix: 'emc6d103s' | ||
| 35 | Addresses scanned: I2C 0x2c, 0x2d, 0x2e | ||
| 36 | Datasheet: http://www.smsc.com/main/catalog/emc6d103s.html | ||
| 29 | 37 | ||
| 30 | Authors: | 38 | Authors: |
| 31 | Philip Pokorny <ppokorny@penguincomputing.com>, | 39 | Philip Pokorny <ppokorny@penguincomputing.com>, |
| @@ -122,9 +130,11 @@ to be register compatible. The EMC6D100 offers all the features of the | |||
| 122 | EMC6D101 plus additional voltage monitoring and system control features. | 130 | EMC6D101 plus additional voltage monitoring and system control features. |
| 123 | Unfortunately it is not possible to distinguish between the package | 131 | Unfortunately it is not possible to distinguish between the package |
| 124 | versions on register level so these additional voltage inputs may read | 132 | versions on register level so these additional voltage inputs may read |
| 125 | zero. The EMC6D102 features addtional ADC bits thus extending precision | 133 | zero. EMC6D102 and EMC6D103 feature additional ADC bits thus extending precision |
| 126 | of voltage and temperature channels. | 134 | of voltage and temperature channels. |
| 127 | 135 | ||
| 136 | SMSC EMC6D103S is similar to EMC6D103, but does not support pwm#_auto_pwm_minctl | ||
| 137 | and temp#_auto_temp_off. | ||
| 128 | 138 | ||
| 129 | Hardware Configurations | 139 | Hardware Configurations |
| 130 | ----------------------- | 140 | ----------------------- |
diff --git a/Documentation/hwmon/ltc4151 b/Documentation/hwmon/ltc4151 new file mode 100644 index 000000000000..43c667e6677a --- /dev/null +++ b/Documentation/hwmon/ltc4151 | |||
| @@ -0,0 +1,47 @@ | |||
| 1 | Kernel driver ltc4151 | ||
| 2 | ===================== | ||
| 3 | |||
| 4 | Supported chips: | ||
| 5 | * Linear Technology LTC4151 | ||
| 6 | Prefix: 'ltc4151' | ||
| 7 | Addresses scanned: - | ||
| 8 | Datasheet: | ||
| 9 | http://www.linear.com/docs/Datasheet/4151fc.pdf | ||
| 10 | |||
| 11 | Author: Per Dalen <per.dalen@appeartv.com> | ||
| 12 | |||
| 13 | |||
| 14 | Description | ||
| 15 | ----------- | ||
| 16 | |||
| 17 | The LTC4151 is a High Voltage I2C Current and Voltage Monitor. | ||
| 18 | |||
| 19 | |||
| 20 | Usage Notes | ||
| 21 | ----------- | ||
| 22 | |||
| 23 | This driver does not probe for LTC4151 devices, since there is no register | ||
| 24 | which can be safely used to identify the chip. You will have to instantiate | ||
| 25 | the devices explicitly. | ||
| 26 | |||
| 27 | Example: the following will load the driver for an LTC4151 at address 0x6f | ||
| 28 | on I2C bus #0: | ||
| 29 | # modprobe ltc4151 | ||
| 30 | # echo ltc4151 0x6f > /sys/bus/i2c/devices/i2c-0/new_device | ||
| 31 | |||
| 32 | |||
| 33 | Sysfs entries | ||
| 34 | ------------- | ||
| 35 | |||
| 36 | Voltage readings provided by this driver are reported as obtained from the ADIN | ||
| 37 | and VIN registers. | ||
| 38 | |||
| 39 | Current reading provided by this driver is reported as obtained from the Current | ||
| 40 | Sense register. The reported value assumes that a 1 mOhm sense resistor is | ||
| 41 | installed. | ||
| 42 | |||
| 43 | in1_input VDIN voltage (mV) | ||
| 44 | |||
| 45 | in2_input ADIN voltage (mV) | ||
| 46 | |||
| 47 | curr1_input SENSE current (mA) | ||
diff --git a/Documentation/hwmon/max6639 b/Documentation/hwmon/max6639 new file mode 100644 index 000000000000..dc49f8be7167 --- /dev/null +++ b/Documentation/hwmon/max6639 | |||
| @@ -0,0 +1,49 @@ | |||
| 1 | Kernel driver max6639 | ||
| 2 | ===================== | ||
| 3 | |||
| 4 | Supported chips: | ||
| 5 | * Maxim MAX6639 | ||
| 6 | Prefix: 'max6639' | ||
| 7 | Addresses scanned: I2C 0x2c, 0x2e, 0x2f | ||
| 8 | Datasheet: http://pdfserv.maxim-ic.com/en/ds/MAX6639.pdf | ||
| 9 | |||
| 10 | Authors: | ||
| 11 | He Changqing <hechangqing@semptian.com> | ||
| 12 | Roland Stigge <stigge@antcom.de> | ||
| 13 | |||
| 14 | Description | ||
| 15 | ----------- | ||
| 16 | |||
| 17 | This driver implements support for the Maxim MAX6639. This chip is a 2-channel | ||
| 18 | temperature monitor with dual PWM fan speed controller. It can monitor its own | ||
| 19 | temperature and one external diode-connected transistor or two external | ||
| 20 | diode-connected transistors. | ||
| 21 | |||
| 22 | The following device attributes are implemented via sysfs: | ||
| 23 | |||
| 24 | Attribute R/W Contents | ||
| 25 | ---------------------------------------------------------------------------- | ||
| 26 | temp1_input R Temperature channel 1 input (0..150 C) | ||
| 27 | temp2_input R Temperature channel 2 input (0..150 C) | ||
| 28 | temp1_fault R Temperature channel 1 diode fault | ||
| 29 | temp2_fault R Temperature channel 2 diode fault | ||
| 30 | temp1_max RW Set THERM temperature for input 1 | ||
| 31 | (in C, see datasheet) | ||
| 32 | temp2_max RW Set THERM temperature for input 2 | ||
| 33 | temp1_crit RW Set ALERT temperature for input 1 | ||
| 34 | temp2_crit RW Set ALERT temperature for input 2 | ||
| 35 | temp1_emergency RW Set OT temperature for input 1 | ||
| 36 | (in C, see datasheet) | ||
| 37 | temp2_emergency RW Set OT temperature for input 2 | ||
| 38 | pwm1 RW Fan 1 target duty cycle (0..255) | ||
| 39 | pwm2 RW Fan 2 target duty cycle (0..255) | ||
| 40 | fan1_input R TACH1 fan tachometer input (in RPM) | ||
| 41 | fan2_input R TACH2 fan tachometer input (in RPM) | ||
| 42 | fan1_fault R Fan 1 fault | ||
| 43 | fan2_fault R Fan 2 fault | ||
| 44 | temp1_max_alarm R Alarm on THERM temperature on channel 1 | ||
| 45 | temp2_max_alarm R Alarm on THERM temperature on channel 2 | ||
| 46 | temp1_crit_alarm R Alarm on ALERT temperature on channel 1 | ||
| 47 | temp2_crit_alarm R Alarm on ALERT temperature on channel 2 | ||
| 48 | temp1_emergency_alarm R Alarm on OT temperature on channel 1 | ||
| 49 | temp2_emergency_alarm R Alarm on OT temperature on channel 2 | ||
diff --git a/Documentation/hwmon/pmbus b/Documentation/hwmon/pmbus new file mode 100644 index 000000000000..dc4933e96344 --- /dev/null +++ b/Documentation/hwmon/pmbus | |||
| @@ -0,0 +1,215 @@ | |||
| 1 | Kernel driver pmbus | ||
| 2 | ==================== | ||
| 3 | |||
| 4 | Supported chips: | ||
| 5 | * Ericsson BMR45X series | ||
| 6 | DC/DC Converter | ||
| 7 | Prefixes: 'bmr450', 'bmr451', 'bmr453', 'bmr454' | ||
| 8 | Addresses scanned: - | ||
| 9 | Datasheet: | ||
| 10 | http://archive.ericsson.net/service/internet/picov/get?DocNo=28701-EN/LZT146395 | ||
| 11 | * Linear Technology LTC2978 | ||
| 12 | Octal PMBus Power Supply Monitor and Controller | ||
| 13 | Prefix: 'ltc2978' | ||
| 14 | Addresses scanned: - | ||
| 15 | Datasheet: http://cds.linear.com/docs/Datasheet/2978fa.pdf | ||
| 16 | * Maxim MAX16064 | ||
| 17 | Quad Power-Supply Controller | ||
| 18 | Prefix: 'max16064' | ||
| 19 | Addresses scanned: - | ||
| 20 | Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX16064.pdf | ||
| 21 | * Maxim MAX34440 | ||
| 22 | PMBus 6-Channel Power-Supply Manager | ||
| 23 | Prefixes: 'max34440' | ||
| 24 | Addresses scanned: - | ||
| 25 | Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34440.pdf | ||
| 26 | * Maxim MAX34441 | ||
| 27 | PMBus 5-Channel Power-Supply Manager and Intelligent Fan Controller | ||
| 28 | Prefixes: 'max34441' | ||
| 29 | Addresses scanned: - | ||
| 30 | Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34441.pdf | ||
| 31 | * Maxim MAX8688 | ||
| 32 | Digital Power-Supply Controller/Monitor | ||
| 33 | Prefix: 'max8688' | ||
| 34 | Addresses scanned: - | ||
| 35 | Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX8688.pdf | ||
| 36 | * Generic PMBus devices | ||
| 37 | Prefix: 'pmbus' | ||
| 38 | Addresses scanned: - | ||
| 39 | Datasheet: n.a. | ||
| 40 | |||
| 41 | Author: Guenter Roeck <guenter.roeck@ericsson.com> | ||
| 42 | |||
| 43 | |||
| 44 | Description | ||
| 45 | ----------- | ||
| 46 | |||
| 47 | This driver supports hardware montoring for various PMBus compliant devices. | ||
| 48 | It supports voltage, current, power, and temperature sensors as supported | ||
| 49 | by the device. | ||
| 50 | |||
| 51 | Each monitored channel has its own high and low limits, plus a critical | ||
| 52 | limit. | ||
| 53 | |||
| 54 | Fan support will be added in a later version of this driver. | ||
| 55 | |||
| 56 | |||
| 57 | Usage Notes | ||
| 58 | ----------- | ||
| 59 | |||
| 60 | This driver does not probe for PMBus devices, since there is no register | ||
| 61 | which can be safely used to identify the chip (The MFG_ID register is not | ||
| 62 | supported by all chips), and since there is no well defined address range for | ||
| 63 | PMBus devices. You will have to instantiate the devices explicitly. | ||
| 64 | |||
| 65 | Example: the following will load the driver for an LTC2978 at address 0x60 | ||
| 66 | on I2C bus #1: | ||
| 67 | $ modprobe pmbus | ||
| 68 | $ echo ltc2978 0x60 > /sys/bus/i2c/devices/i2c-1/new_device | ||
| 69 | |||
| 70 | |||
| 71 | Platform data support | ||
| 72 | --------------------- | ||
| 73 | |||
| 74 | Support for additional PMBus chips can be added by defining chip parameters in | ||
| 75 | a new chip specific driver file. For example, (untested) code to add support for | ||
| 76 | Emerson DS1200 power modules might look as follows. | ||
| 77 | |||
| 78 | static struct pmbus_driver_info ds1200_info = { | ||
| 79 | .pages = 1, | ||
| 80 | /* Note: All other sensors are in linear mode */ | ||
| 81 | .direct[PSC_VOLTAGE_OUT] = true, | ||
| 82 | .direct[PSC_TEMPERATURE] = true, | ||
| 83 | .direct[PSC_CURRENT_OUT] = true, | ||
| 84 | .m[PSC_VOLTAGE_IN] = 1, | ||
| 85 | .b[PSC_VOLTAGE_IN] = 0, | ||
| 86 | .R[PSC_VOLTAGE_IN] = 3, | ||
| 87 | .m[PSC_VOLTAGE_OUT] = 1, | ||
| 88 | .b[PSC_VOLTAGE_OUT] = 0, | ||
| 89 | .R[PSC_VOLTAGE_OUT] = 3, | ||
| 90 | .m[PSC_TEMPERATURE] = 1, | ||
| 91 | .b[PSC_TEMPERATURE] = 0, | ||
| 92 | .R[PSC_TEMPERATURE] = 3, | ||
| 93 | .func[0] = PMBUS_HAVE_VIN | PMBUS_HAVE_IIN | PMBUS_HAVE_STATUS_INPUT | ||
| 94 | | PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT | ||
| 95 | | PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_IOUT | ||
| 96 | | PMBUS_HAVE_PIN | PMBUS_HAVE_POUT | ||
| 97 | | PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP | ||
| 98 | | PMBUS_HAVE_FAN12 | PMBUS_HAVE_STATUS_FAN12, | ||
| 99 | }; | ||
| 100 | |||
| 101 | static int ds1200_probe(struct i2c_client *client, | ||
| 102 | const struct i2c_device_id *id) | ||
| 103 | { | ||
| 104 | return pmbus_do_probe(client, id, &ds1200_info); | ||
| 105 | } | ||
| 106 | |||
| 107 | static int ds1200_remove(struct i2c_client *client) | ||
| 108 | { | ||
| 109 | return pmbus_do_remove(client); | ||
| 110 | } | ||
| 111 | |||
| 112 | static const struct i2c_device_id ds1200_id[] = { | ||
| 113 | {"ds1200", 0}, | ||
| 114 | {} | ||
| 115 | }; | ||
| 116 | |||
| 117 | MODULE_DEVICE_TABLE(i2c, ds1200_id); | ||
| 118 | |||
| 119 | /* This is the driver that will be inserted */ | ||
| 120 | static struct i2c_driver ds1200_driver = { | ||
| 121 | .driver = { | ||
| 122 | .name = "ds1200", | ||
| 123 | }, | ||
| 124 | .probe = ds1200_probe, | ||
| 125 | .remove = ds1200_remove, | ||
| 126 | .id_table = ds1200_id, | ||
| 127 | }; | ||
| 128 | |||
| 129 | static int __init ds1200_init(void) | ||
| 130 | { | ||
| 131 | return i2c_add_driver(&ds1200_driver); | ||
| 132 | } | ||
| 133 | |||
| 134 | static void __exit ds1200_exit(void) | ||
| 135 | { | ||
| 136 | i2c_del_driver(&ds1200_driver); | ||
| 137 | } | ||
| 138 | |||
| 139 | |||
| 140 | Sysfs entries | ||
| 141 | ------------- | ||
| 142 | |||
| 143 | When probing the chip, the driver identifies which PMBus registers are | ||
| 144 | supported, and determines available sensors from this information. | ||
| 145 | Attribute files only exist if respective sensors are suported by the chip. | ||
| 146 | Labels are provided to inform the user about the sensor associated with | ||
| 147 | a given sysfs entry. | ||
| 148 | |||
| 149 | The following attributes are supported. Limits are read-write; all other | ||
| 150 | attributes are read-only. | ||
| 151 | |||
| 152 | inX_input Measured voltage. From READ_VIN or READ_VOUT register. | ||
| 153 | inX_min Minimum Voltage. | ||
| 154 | From VIN_UV_WARN_LIMIT or VOUT_UV_WARN_LIMIT register. | ||
| 155 | inX_max Maximum voltage. | ||
| 156 | From VIN_OV_WARN_LIMIT or VOUT_OV_WARN_LIMIT register. | ||
| 157 | inX_lcrit Critical minimum Voltage. | ||
| 158 | From VIN_UV_FAULT_LIMIT or VOUT_UV_FAULT_LIMIT register. | ||
| 159 | inX_crit Critical maximum voltage. | ||
| 160 | From VIN_OV_FAULT_LIMIT or VOUT_OV_FAULT_LIMIT register. | ||
| 161 | inX_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status. | ||
| 162 | inX_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status. | ||
| 163 | inX_lcrit_alarm Voltage critical low alarm. | ||
| 164 | From VOLTAGE_UV_FAULT status. | ||
| 165 | inX_crit_alarm Voltage critical high alarm. | ||
| 166 | From VOLTAGE_OV_FAULT status. | ||
| 167 | inX_label "vin", "vcap", or "voutY" | ||
| 168 | |||
| 169 | currX_input Measured current. From READ_IIN or READ_IOUT register. | ||
| 170 | currX_max Maximum current. | ||
| 171 | From IIN_OC_WARN_LIMIT or IOUT_OC_WARN_LIMIT register. | ||
| 172 | currX_lcrit Critical minimum output current. | ||
| 173 | From IOUT_UC_FAULT_LIMIT register. | ||
| 174 | currX_crit Critical maximum current. | ||
| 175 | From IIN_OC_FAULT_LIMIT or IOUT_OC_FAULT_LIMIT register. | ||
| 176 | currX_alarm Current high alarm. | ||
| 177 | From IIN_OC_WARNING or IOUT_OC_WARNING status. | ||
| 178 | currX_lcrit_alarm Output current critical low alarm. | ||
| 179 | From IOUT_UC_FAULT status. | ||
| 180 | currX_crit_alarm Current critical high alarm. | ||
| 181 | From IIN_OC_FAULT or IOUT_OC_FAULT status. | ||
| 182 | currX_label "iin" or "vinY" | ||
| 183 | |||
| 184 | powerX_input Measured power. From READ_PIN or READ_POUT register. | ||
| 185 | powerX_cap Output power cap. From POUT_MAX register. | ||
| 186 | powerX_max Power limit. From PIN_OP_WARN_LIMIT or | ||
| 187 | POUT_OP_WARN_LIMIT register. | ||
| 188 | powerX_crit Critical output power limit. | ||
| 189 | From POUT_OP_FAULT_LIMIT register. | ||
| 190 | powerX_alarm Power high alarm. | ||
| 191 | From PIN_OP_WARNING or POUT_OP_WARNING status. | ||
| 192 | powerX_crit_alarm Output power critical high alarm. | ||
| 193 | From POUT_OP_FAULT status. | ||
| 194 | powerX_label "pin" or "poutY" | ||
| 195 | |||
| 196 | tempX_input Measured tempererature. | ||
| 197 | From READ_TEMPERATURE_X register. | ||
| 198 | tempX_min Mimimum tempererature. From UT_WARN_LIMIT register. | ||
| 199 | tempX_max Maximum tempererature. From OT_WARN_LIMIT register. | ||
| 200 | tempX_lcrit Critical low tempererature. | ||
| 201 | From UT_FAULT_LIMIT register. | ||
| 202 | tempX_crit Critical high tempererature. | ||
| 203 | From OT_FAULT_LIMIT register. | ||
| 204 | tempX_min_alarm Chip temperature low alarm. Set by comparing | ||
| 205 | READ_TEMPERATURE_X with UT_WARN_LIMIT if | ||
| 206 | TEMP_UT_WARNING status is set. | ||
| 207 | tempX_max_alarm Chip temperature high alarm. Set by comparing | ||
| 208 | READ_TEMPERATURE_X with OT_WARN_LIMIT if | ||
| 209 | TEMP_OT_WARNING status is set. | ||
| 210 | tempX_lcrit_alarm Chip temperature critical low alarm. Set by comparing | ||
| 211 | READ_TEMPERATURE_X with UT_FAULT_LIMIT if | ||
| 212 | TEMP_UT_FAULT status is set. | ||
| 213 | tempX_crit_alarm Chip temperature critical high alarm. Set by comparing | ||
| 214 | READ_TEMPERATURE_X with OT_FAULT_LIMIT if | ||
| 215 | TEMP_OT_FAULT status is set. | ||
diff --git a/Documentation/hwmon/sch5627 b/Documentation/hwmon/sch5627 new file mode 100644 index 000000000000..446a054e4912 --- /dev/null +++ b/Documentation/hwmon/sch5627 | |||
| @@ -0,0 +1,22 @@ | |||
| 1 | Kernel driver sch5627 | ||
| 2 | ===================== | ||
| 3 | |||
| 4 | Supported chips: | ||
| 5 | * SMSC SCH5627 | ||
| 6 | Prefix: 'sch5627' | ||
| 7 | Addresses scanned: none, address read from Super I/O config space | ||
| 8 | Datasheet: Application Note available upon request | ||
| 9 | |||
| 10 | Author: Hans de Goede <hdegoede@redhat.com> | ||
| 11 | |||
| 12 | |||
| 13 | Description | ||
| 14 | ----------- | ||
| 15 | |||
| 16 | SMSC SCH5627 Super I/O chips include complete hardware monitoring | ||
| 17 | capabilities. They can monitor up to 5 voltages, 4 fans and 8 temperatures. | ||
| 18 | |||
| 19 | The hardware monitoring part of the SMSC SCH5627 is accessed by talking | ||
| 20 | through an embedded microcontroller. An application note describing the | ||
| 21 | protocol for communicating with the microcontroller is available upon | ||
| 22 | request. Please mail me if you want a copy. | ||
diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface index c6559f153589..8f63c244f1aa 100644 --- a/Documentation/hwmon/sysfs-interface +++ b/Documentation/hwmon/sysfs-interface | |||
| @@ -187,6 +187,17 @@ fan[1-*]_div Fan divisor. | |||
| 187 | Note that this is actually an internal clock divisor, which | 187 | Note that this is actually an internal clock divisor, which |
| 188 | affects the measurable speed range, not the read value. | 188 | affects the measurable speed range, not the read value. |
| 189 | 189 | ||
| 190 | fan[1-*]_pulses Number of tachometer pulses per fan revolution. | ||
| 191 | Integer value, typically between 1 and 4. | ||
| 192 | RW | ||
| 193 | This value is a characteristic of the fan connected to the | ||
| 194 | device's input, so it has to be set in accordance with the fan | ||
| 195 | model. | ||
| 196 | Should only be created if the chip has a register to configure | ||
| 197 | the number of pulses. In the absence of such a register (and | ||
| 198 | thus attribute) the value assumed by all devices is 2 pulses | ||
| 199 | per fan revolution. | ||
| 200 | |||
| 190 | fan[1-*]_target | 201 | fan[1-*]_target |
| 191 | Desired fan speed | 202 | Desired fan speed |
| 192 | Unit: revolution/min (RPM) | 203 | Unit: revolution/min (RPM) |
| @@ -568,7 +579,7 @@ channel should not be trusted. | |||
| 568 | fan[1-*]_fault | 579 | fan[1-*]_fault |
| 569 | temp[1-*]_fault | 580 | temp[1-*]_fault |
| 570 | Input fault condition | 581 | Input fault condition |
| 571 | 0: no fault occured | 582 | 0: no fault occurred |
| 572 | 1: fault condition | 583 | 1: fault condition |
| 573 | RO | 584 | RO |
| 574 | 585 | ||
diff --git a/Documentation/hwmon/twl4030-madc-hwmon b/Documentation/hwmon/twl4030-madc-hwmon new file mode 100644 index 000000000000..ef7984317cec --- /dev/null +++ b/Documentation/hwmon/twl4030-madc-hwmon | |||
| @@ -0,0 +1,45 @@ | |||
| 1 | Kernel driver twl4030-madc | ||
| 2 | ========================= | ||
| 3 | |||
| 4 | Supported chips: | ||
| 5 | * Texas Instruments TWL4030 | ||
| 6 | Prefix: 'twl4030-madc' | ||
| 7 | |||
| 8 | |||
| 9 | Authors: | ||
| 10 | J Keerthy <j-keerthy@ti.com> | ||
| 11 | |||
| 12 | Description | ||
| 13 | ----------- | ||
| 14 | |||
| 15 | The Texas Instruments TWL4030 is a Power Management and Audio Circuit. Among | ||
| 16 | other things it contains a 10-bit A/D converter MADC. The converter has 16 | ||
| 17 | channels which can be used in different modes. | ||
| 18 | |||
| 19 | |||
| 20 | See this table for the meaning of the different channels | ||
| 21 | |||
| 22 | Channel Signal | ||
| 23 | ------------------------------------------ | ||
| 24 | 0 Battery type(BTYPE) | ||
| 25 | 1 BCI: Battery temperature (BTEMP) | ||
| 26 | 2 GP analog input | ||
| 27 | 3 GP analog input | ||
| 28 | 4 GP analog input | ||
| 29 | 5 GP analog input | ||
| 30 | 6 GP analog input | ||
| 31 | 7 GP analog input | ||
| 32 | 8 BCI: VBUS voltage(VBUS) | ||
| 33 | 9 Backup Battery voltage (VBKP) | ||
| 34 | 10 BCI: Battery charger current (ICHG) | ||
| 35 | 11 BCI: Battery charger voltage (VCHG) | ||
| 36 | 12 BCI: Main battery voltage (VBAT) | ||
| 37 | 13 Reserved | ||
| 38 | 14 Reserved | ||
| 39 | 15 VRUSB Supply/Speaker left/Speaker right polarization level | ||
| 40 | |||
| 41 | |||
| 42 | The Sysfs nodes will represent the voltage in the units of mV, | ||
| 43 | the temperature channel shows the converted temperature in | ||
| 44 | degree celcius. The Battery charging current channel represents | ||
| 45 | battery charging current in mA. | ||
diff --git a/Documentation/hwmon/w83627ehf b/Documentation/hwmon/w83627ehf index 13d556112fc0..76ffef94ed75 100644 --- a/Documentation/hwmon/w83627ehf +++ b/Documentation/hwmon/w83627ehf | |||
| @@ -5,13 +5,11 @@ Supported chips: | |||
| 5 | * Winbond W83627EHF/EHG (ISA access ONLY) | 5 | * Winbond W83627EHF/EHG (ISA access ONLY) |
| 6 | Prefix: 'w83627ehf' | 6 | Prefix: 'w83627ehf' |
| 7 | Addresses scanned: ISA address retrieved from Super I/O registers | 7 | Addresses scanned: ISA address retrieved from Super I/O registers |
| 8 | Datasheet: | 8 | Datasheet: not available |
| 9 | http://www.nuvoton.com.tw/NR/rdonlyres/A6A258F0-F0C9-4F97-81C0-C4D29E7E943E/0/W83627EHF.pdf | ||
| 10 | * Winbond W83627DHG | 9 | * Winbond W83627DHG |
| 11 | Prefix: 'w83627dhg' | 10 | Prefix: 'w83627dhg' |
| 12 | Addresses scanned: ISA address retrieved from Super I/O registers | 11 | Addresses scanned: ISA address retrieved from Super I/O registers |
| 13 | Datasheet: | 12 | Datasheet: not available |
| 14 | http://www.nuvoton.com.tw/NR/rdonlyres/7885623D-A487-4CF9-A47F-30C5F73D6FE6/0/W83627DHG.pdf | ||
| 15 | * Winbond W83627DHG-P | 13 | * Winbond W83627DHG-P |
| 16 | Prefix: 'w83627dhg' | 14 | Prefix: 'w83627dhg' |
| 17 | Addresses scanned: ISA address retrieved from Super I/O registers | 15 | Addresses scanned: ISA address retrieved from Super I/O registers |
| @@ -24,6 +22,14 @@ Supported chips: | |||
| 24 | Prefix: 'w83667hg' | 22 | Prefix: 'w83667hg' |
| 25 | Addresses scanned: ISA address retrieved from Super I/O registers | 23 | Addresses scanned: ISA address retrieved from Super I/O registers |
| 26 | Datasheet: Available from Nuvoton upon request | 24 | Datasheet: Available from Nuvoton upon request |
| 25 | * Nuvoton NCT6775F/W83667HG-I | ||
| 26 | Prefix: 'nct6775' | ||
| 27 | Addresses scanned: ISA address retrieved from Super I/O registers | ||
| 28 | Datasheet: Available from Nuvoton upon request | ||
| 29 | * Nuvoton NCT6776F | ||
| 30 | Prefix: 'nct6776' | ||
| 31 | Addresses scanned: ISA address retrieved from Super I/O registers | ||
| 32 | Datasheet: Available from Nuvoton upon request | ||
| 27 | 33 | ||
| 28 | Authors: | 34 | Authors: |
| 29 | Jean Delvare <khali@linux-fr.org> | 35 | Jean Delvare <khali@linux-fr.org> |
| @@ -36,19 +42,28 @@ Description | |||
| 36 | ----------- | 42 | ----------- |
| 37 | 43 | ||
| 38 | This driver implements support for the Winbond W83627EHF, W83627EHG, | 44 | This driver implements support for the Winbond W83627EHF, W83627EHG, |
| 39 | W83627DHG, W83627DHG-P, W83667HG and W83667HG-B super I/O chips. | 45 | W83627DHG, W83627DHG-P, W83667HG, W83667HG-B, W83667HG-I (NCT6775F), |
| 40 | We will refer to them collectively as Winbond chips. | 46 | and NCT6776F super I/O chips. We will refer to them collectively as |
| 41 | 47 | Winbond chips. | |
| 42 | The chips implement three temperature sensors, five fan rotation | 48 | |
| 43 | speed sensors, ten analog voltage sensors (only nine for the 627DHG), one | 49 | The chips implement three temperature sensors (up to four for 667HG-B, and nine |
| 44 | VID (6 pins for the 627EHF/EHG, 8 pins for the 627DHG and 667HG), alarms | 50 | for NCT6775F and NCT6776F), five fan rotation speed sensors, ten analog voltage |
| 45 | with beep warnings (control unimplemented), and some automatic fan | 51 | sensors (only nine for the 627DHG), one VID (6 pins for the 627EHF/EHG, 8 pins |
| 46 | regulation strategies (plus manual fan control mode). | 52 | for the 627DHG and 667HG), alarms with beep warnings (control unimplemented), |
| 53 | and some automatic fan regulation strategies (plus manual fan control mode). | ||
| 54 | |||
| 55 | The temperature sensor sources on W82677HG-B, NCT6775F, and NCT6776F are | ||
| 56 | configurable. temp4 and higher attributes are only reported if its temperature | ||
| 57 | source differs from the temperature sources of the already reported temperature | ||
| 58 | sensors. The configured source for each of the temperature sensors is provided | ||
| 59 | in tempX_label. | ||
| 47 | 60 | ||
| 48 | Temperatures are measured in degrees Celsius and measurement resolution is 1 | 61 | Temperatures are measured in degrees Celsius and measurement resolution is 1 |
| 49 | degC for temp1 and 0.5 degC for temp2 and temp3. An alarm is triggered when | 62 | degC for temp1 and and 0.5 degC for temp2 and temp3. For temp4 and higher, |
| 50 | the temperature gets higher than high limit; it stays on until the temperature | 63 | resolution is 1 degC for W83667HG-B and 0.0 degC for NCT6775F and NCT6776F. |
| 51 | falls below the hysteresis value. | 64 | An alarm is triggered when the temperature gets higher than high limit; |
| 65 | it stays on until the temperature falls below the hysteresis value. | ||
| 66 | Alarms are only supported for temp1, temp2, and temp3. | ||
| 52 | 67 | ||
| 53 | Fan rotation speeds are reported in RPM (rotations per minute). An alarm is | 68 | Fan rotation speeds are reported in RPM (rotations per minute). An alarm is |
| 54 | triggered if the rotation speed has dropped below a programmable limit. Fan | 69 | triggered if the rotation speed has dropped below a programmable limit. Fan |
| @@ -80,7 +95,8 @@ prog -> pwm4 (not on 667HG and 667HG-B; the programmable setting is not | |||
| 80 | 95 | ||
| 81 | name - this is a standard hwmon device entry. For the W83627EHF and W83627EHG, | 96 | name - this is a standard hwmon device entry. For the W83627EHF and W83627EHG, |
| 82 | it is set to "w83627ehf", for the W83627DHG it is set to "w83627dhg", | 97 | it is set to "w83627ehf", for the W83627DHG it is set to "w83627dhg", |
| 83 | and for the W83667HG it is set to "w83667hg". | 98 | for the W83667HG and W83667HG-B it is set to "w83667hg", for NCT6775F it |
| 99 | is set to "nct6775", and for NCT6776F it is set to "nct6776". | ||
| 84 | 100 | ||
| 85 | pwm[1-4] - this file stores PWM duty cycle or DC value (fan speed) in range: | 101 | pwm[1-4] - this file stores PWM duty cycle or DC value (fan speed) in range: |
| 86 | 0 (stop) to 255 (full) | 102 | 0 (stop) to 255 (full) |
| @@ -90,6 +106,18 @@ pwm[1-4]_enable - this file controls mode of fan/temperature control: | |||
| 90 | * 2 "Thermal Cruise" mode | 106 | * 2 "Thermal Cruise" mode |
| 91 | * 3 "Fan Speed Cruise" mode | 107 | * 3 "Fan Speed Cruise" mode |
| 92 | * 4 "Smart Fan III" mode | 108 | * 4 "Smart Fan III" mode |
| 109 | * 5 "Smart Fan IV" mode | ||
| 110 | |||
| 111 | SmartFan III mode is not supported on NCT6776F. | ||
| 112 | |||
| 113 | SmartFan IV mode is configurable only if it was configured at system | ||
| 114 | startup, and is only supported for W83677HG-B, NCT6775F, and NCT6776F. | ||
| 115 | SmartFan IV operational parameters can not be configured at this time, | ||
| 116 | and the various pwm attributes are not used in SmartFan IV mode. | ||
| 117 | The attributes can be written to, which is useful if you plan to | ||
| 118 | configure the system for a different pwm mode. However, the information | ||
| 119 | returned when reading pwm attributes is unrelated to SmartFan IV | ||
| 120 | operation. | ||
| 93 | 121 | ||
| 94 | pwm[1-4]_mode - controls if output is PWM or DC level | 122 | pwm[1-4]_mode - controls if output is PWM or DC level |
| 95 | * 0 DC output (0 - 12v) | 123 | * 0 DC output (0 - 12v) |
diff --git a/Documentation/hwmon/w83781d b/Documentation/hwmon/w83781d index ecbc1e4574b4..129b0a3b555b 100644 --- a/Documentation/hwmon/w83781d +++ b/Documentation/hwmon/w83781d | |||
| @@ -403,7 +403,7 @@ found out the following values do work as a form of coarse pwm: | |||
| 403 | 403 | ||
| 404 | 0x80 - seems to turn fans off after some time(1-2 minutes)... might be | 404 | 0x80 - seems to turn fans off after some time(1-2 minutes)... might be |
| 405 | some form of auto-fan-control based on temp? hmm (Qfan? this mobo is an | 405 | some form of auto-fan-control based on temp? hmm (Qfan? this mobo is an |
| 406 | old ASUS, it isn't marketed as Qfan. Maybe some beta pre-attemp at Qfan | 406 | old ASUS, it isn't marketed as Qfan. Maybe some beta pre-attempt at Qfan |
| 407 | that was dropped at the BIOS) | 407 | that was dropped at the BIOS) |
| 408 | 0x81 - off | 408 | 0x81 - off |
| 409 | 0x82 - slightly "on-ner" than off, but my fans do not get to move. I can | 409 | 0x82 - slightly "on-ner" than off, but my fans do not get to move. I can |
diff --git a/Documentation/hwmon/w83791d b/Documentation/hwmon/w83791d index 5663e491655c..90387c3540f7 100644 --- a/Documentation/hwmon/w83791d +++ b/Documentation/hwmon/w83791d | |||
| @@ -93,7 +93,7 @@ The sysfs interface to the beep bitmask has migrated from the original legacy | |||
| 93 | method of a single sysfs beep_mask file to a newer method using multiple | 93 | method of a single sysfs beep_mask file to a newer method using multiple |
| 94 | *_beep files as described in .../Documentation/hwmon/sysfs-interface. | 94 | *_beep files as described in .../Documentation/hwmon/sysfs-interface. |
| 95 | 95 | ||
| 96 | A similar change has occured for the bitmap corresponding to the alarms. The | 96 | A similar change has occurred for the bitmap corresponding to the alarms. The |
| 97 | original legacy method used a single sysfs alarms file containing a bitmap | 97 | original legacy method used a single sysfs alarms file containing a bitmap |
| 98 | of triggered alarms. The newer method uses multiple sysfs *_alarm files | 98 | of triggered alarms. The newer method uses multiple sysfs *_alarm files |
| 99 | (again following the pattern described in sysfs-interface). | 99 | (again following the pattern described in sysfs-interface). |
diff --git a/Documentation/hwmon/w83795 b/Documentation/hwmon/w83795 new file mode 100644 index 000000000000..9f160371f463 --- /dev/null +++ b/Documentation/hwmon/w83795 | |||
| @@ -0,0 +1,127 @@ | |||
| 1 | Kernel driver w83795 | ||
| 2 | ==================== | ||
| 3 | |||
| 4 | Supported chips: | ||
| 5 | * Winbond/Nuvoton W83795G | ||
| 6 | Prefix: 'w83795g' | ||
| 7 | Addresses scanned: I2C 0x2c - 0x2f | ||
| 8 | Datasheet: Available for download on nuvoton.com | ||
| 9 | * Winbond/Nuvoton W83795ADG | ||
| 10 | Prefix: 'w83795adg' | ||
| 11 | Addresses scanned: I2C 0x2c - 0x2f | ||
| 12 | Datasheet: Available for download on nuvoton.com | ||
| 13 | |||
| 14 | Authors: | ||
| 15 | Wei Song (Nuvoton) | ||
| 16 | Jean Delvare <khali@linux-fr.org> | ||
| 17 | |||
| 18 | |||
| 19 | Pin mapping | ||
| 20 | ----------- | ||
| 21 | |||
| 22 | Here is a summary of the pin mapping for the W83795G and W83795ADG. | ||
| 23 | This can be useful to convert data provided by board manufacturers | ||
| 24 | into working libsensors configuration statements. | ||
| 25 | |||
| 26 | W83795G | | ||
| 27 | Pin | Name | Register | Sysfs attribute | ||
| 28 | ------------------------------------------------------------------ | ||
| 29 | 13 | VSEN1 (VCORE1) | 10h | in0 | ||
| 30 | 14 | VSEN2 (VCORE2) | 11h | in1 | ||
| 31 | 15 | VSEN3 (VCORE3) | 12h | in2 | ||
| 32 | 16 | VSEN4 | 13h | in3 | ||
| 33 | 17 | VSEN5 | 14h | in4 | ||
| 34 | 18 | VSEN6 | 15h | in5 | ||
| 35 | 19 | VSEN7 | 16h | in6 | ||
| 36 | 20 | VSEN8 | 17h | in7 | ||
| 37 | 21 | VSEN9 | 18h | in8 | ||
| 38 | 22 | VSEN10 | 19h | in9 | ||
| 39 | 23 | VSEN11 | 1Ah | in10 | ||
| 40 | 28 | VTT | 1Bh | in11 | ||
| 41 | 24 | 3VDD | 1Ch | in12 | ||
| 42 | 25 | 3VSB | 1Dh | in13 | ||
| 43 | 26 | VBAT | 1Eh | in14 | ||
| 44 | 3 | VSEN12/TR5 | 1Fh | in15/temp5 | ||
| 45 | 4 | VSEN13/TR5 | 20h | in16/temp6 | ||
| 46 | 5/ 6 | VDSEN14/TR1/TD1 | 21h | in17/temp1 | ||
| 47 | 7/ 8 | VDSEN15/TR2/TD2 | 22h | in18/temp2 | ||
| 48 | 9/ 10 | VDSEN16/TR3/TD3 | 23h | in19/temp3 | ||
| 49 | 11/ 12 | VDSEN17/TR4/TD4 | 24h | in20/temp4 | ||
| 50 | 40 | FANIN1 | 2Eh | fan1 | ||
| 51 | 42 | FANIN2 | 2Fh | fan2 | ||
| 52 | 44 | FANIN3 | 30h | fan3 | ||
| 53 | 46 | FANIN4 | 31h | fan4 | ||
| 54 | 48 | FANIN5 | 32h | fan5 | ||
| 55 | 50 | FANIN6 | 33h | fan6 | ||
| 56 | 52 | FANIN7 | 34h | fan7 | ||
| 57 | 54 | FANIN8 | 35h | fan8 | ||
| 58 | 57 | FANIN9 | 36h | fan9 | ||
| 59 | 58 | FANIN10 | 37h | fan10 | ||
| 60 | 59 | FANIN11 | 38h | fan11 | ||
| 61 | 60 | FANIN12 | 39h | fan12 | ||
| 62 | 31 | FANIN13 | 3Ah | fan13 | ||
| 63 | 35 | FANIN14 | 3Bh | fan14 | ||
| 64 | 41 | FANCTL1 | 10h (bank 2) | pwm1 | ||
| 65 | 43 | FANCTL2 | 11h (bank 2) | pwm2 | ||
| 66 | 45 | FANCTL3 | 12h (bank 2) | pwm3 | ||
| 67 | 47 | FANCTL4 | 13h (bank 2) | pwm4 | ||
| 68 | 49 | FANCTL5 | 14h (bank 2) | pwm5 | ||
| 69 | 51 | FANCTL6 | 15h (bank 2) | pwm6 | ||
| 70 | 53 | FANCTL7 | 16h (bank 2) | pwm7 | ||
| 71 | 55 | FANCTL8 | 17h (bank 2) | pwm8 | ||
| 72 | 29/ 30 | PECI/TSI (DTS1) | 26h | temp7 | ||
| 73 | 29/ 30 | PECI/TSI (DTS2) | 27h | temp8 | ||
| 74 | 29/ 30 | PECI/TSI (DTS3) | 28h | temp9 | ||
| 75 | 29/ 30 | PECI/TSI (DTS4) | 29h | temp10 | ||
| 76 | 29/ 30 | PECI/TSI (DTS5) | 2Ah | temp11 | ||
| 77 | 29/ 30 | PECI/TSI (DTS6) | 2Bh | temp12 | ||
| 78 | 29/ 30 | PECI/TSI (DTS7) | 2Ch | temp13 | ||
| 79 | 29/ 30 | PECI/TSI (DTS8) | 2Dh | temp14 | ||
| 80 | 27 | CASEOPEN# | 46h | intrusion0 | ||
| 81 | |||
| 82 | W83795ADG | | ||
| 83 | Pin | Name | Register | Sysfs attribute | ||
| 84 | ------------------------------------------------------------------ | ||
| 85 | 10 | VSEN1 (VCORE1) | 10h | in0 | ||
| 86 | 11 | VSEN2 (VCORE2) | 11h | in1 | ||
| 87 | 12 | VSEN3 (VCORE3) | 12h | in2 | ||
| 88 | 13 | VSEN4 | 13h | in3 | ||
| 89 | 14 | VSEN5 | 14h | in4 | ||
| 90 | 15 | VSEN6 | 15h | in5 | ||
| 91 | 16 | VSEN7 | 16h | in6 | ||
| 92 | 17 | VSEN8 | 17h | in7 | ||
| 93 | 22 | VTT | 1Bh | in11 | ||
| 94 | 18 | 3VDD | 1Ch | in12 | ||
| 95 | 19 | 3VSB | 1Dh | in13 | ||
| 96 | 20 | VBAT | 1Eh | in14 | ||
| 97 | 48 | VSEN12/TR5 | 1Fh | in15/temp5 | ||
| 98 | 1 | VSEN13/TR5 | 20h | in16/temp6 | ||
| 99 | 2/ 3 | VDSEN14/TR1/TD1 | 21h | in17/temp1 | ||
| 100 | 4/ 5 | VDSEN15/TR2/TD2 | 22h | in18/temp2 | ||
| 101 | 6/ 7 | VDSEN16/TR3/TD3 | 23h | in19/temp3 | ||
| 102 | 8/ 9 | VDSEN17/TR4/TD4 | 24h | in20/temp4 | ||
| 103 | 32 | FANIN1 | 2Eh | fan1 | ||
| 104 | 34 | FANIN2 | 2Fh | fan2 | ||
| 105 | 36 | FANIN3 | 30h | fan3 | ||
| 106 | 37 | FANIN4 | 31h | fan4 | ||
| 107 | 38 | FANIN5 | 32h | fan5 | ||
| 108 | 39 | FANIN6 | 33h | fan6 | ||
| 109 | 40 | FANIN7 | 34h | fan7 | ||
| 110 | 41 | FANIN8 | 35h | fan8 | ||
| 111 | 43 | FANIN9 | 36h | fan9 | ||
| 112 | 44 | FANIN10 | 37h | fan10 | ||
| 113 | 45 | FANIN11 | 38h | fan11 | ||
| 114 | 46 | FANIN12 | 39h | fan12 | ||
| 115 | 24 | FANIN13 | 3Ah | fan13 | ||
| 116 | 28 | FANIN14 | 3Bh | fan14 | ||
| 117 | 33 | FANCTL1 | 10h (bank 2) | pwm1 | ||
| 118 | 35 | FANCTL2 | 11h (bank 2) | pwm2 | ||
| 119 | 23 | PECI (DTS1) | 26h | temp7 | ||
| 120 | 23 | PECI (DTS2) | 27h | temp8 | ||
| 121 | 23 | PECI (DTS3) | 28h | temp9 | ||
| 122 | 23 | PECI (DTS4) | 29h | temp10 | ||
| 123 | 23 | PECI (DTS5) | 2Ah | temp11 | ||
| 124 | 23 | PECI (DTS6) | 2Bh | temp12 | ||
| 125 | 23 | PECI (DTS7) | 2Ch | temp13 | ||
| 126 | 23 | PECI (DTS8) | 2Dh | temp14 | ||
| 127 | 21 | CASEOPEN# | 46h | intrusion0 | ||
diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt new file mode 100644 index 000000000000..7dcd1a4e726c --- /dev/null +++ b/Documentation/hwspinlock.txt | |||
| @@ -0,0 +1,293 @@ | |||
| 1 | Hardware Spinlock Framework | ||
| 2 | |||
| 3 | 1. Introduction | ||
| 4 | |||
| 5 | Hardware spinlock modules provide hardware assistance for synchronization | ||
| 6 | and mutual exclusion between heterogeneous processors and those not operating | ||
| 7 | under a single, shared operating system. | ||
| 8 | |||
| 9 | For example, OMAP4 has dual Cortex-A9, dual Cortex-M3 and a C64x+ DSP, | ||
| 10 | each of which is running a different Operating System (the master, A9, | ||
| 11 | is usually running Linux and the slave processors, the M3 and the DSP, | ||
| 12 | are running some flavor of RTOS). | ||
| 13 | |||
| 14 | A generic hwspinlock framework allows platform-independent drivers to use | ||
| 15 | the hwspinlock device in order to access data structures that are shared | ||
| 16 | between remote processors, that otherwise have no alternative mechanism | ||
| 17 | to accomplish synchronization and mutual exclusion operations. | ||
| 18 | |||
| 19 | This is necessary, for example, for Inter-processor communications: | ||
| 20 | on OMAP4, cpu-intensive multimedia tasks are offloaded by the host to the | ||
| 21 | remote M3 and/or C64x+ slave processors (by an IPC subsystem called Syslink). | ||
| 22 | |||
| 23 | To achieve fast message-based communications, a minimal kernel support | ||
| 24 | is needed to deliver messages arriving from a remote processor to the | ||
| 25 | appropriate user process. | ||
| 26 | |||
| 27 | This communication is based on simple data structures that is shared between | ||
| 28 | the remote processors, and access to it is synchronized using the hwspinlock | ||
| 29 | module (remote processor directly places new messages in this shared data | ||
| 30 | structure). | ||
| 31 | |||
| 32 | A common hwspinlock interface makes it possible to have generic, platform- | ||
| 33 | independent, drivers. | ||
| 34 | |||
| 35 | 2. User API | ||
| 36 | |||
| 37 | struct hwspinlock *hwspin_lock_request(void); | ||
| 38 | - dynamically assign an hwspinlock and return its address, or NULL | ||
| 39 | in case an unused hwspinlock isn't available. Users of this | ||
| 40 | API will usually want to communicate the lock's id to the remote core | ||
| 41 | before it can be used to achieve synchronization. | ||
| 42 | Can be called from an atomic context (this function will not sleep) but | ||
| 43 | not from within interrupt context. | ||
| 44 | |||
| 45 | struct hwspinlock *hwspin_lock_request_specific(unsigned int id); | ||
| 46 | - assign a specific hwspinlock id and return its address, or NULL | ||
| 47 | if that hwspinlock is already in use. Usually board code will | ||
| 48 | be calling this function in order to reserve specific hwspinlock | ||
| 49 | ids for predefined purposes. | ||
| 50 | Can be called from an atomic context (this function will not sleep) but | ||
| 51 | not from within interrupt context. | ||
| 52 | |||
| 53 | int hwspin_lock_free(struct hwspinlock *hwlock); | ||
| 54 | - free a previously-assigned hwspinlock; returns 0 on success, or an | ||
| 55 | appropriate error code on failure (e.g. -EINVAL if the hwspinlock | ||
| 56 | is already free). | ||
| 57 | Can be called from an atomic context (this function will not sleep) but | ||
| 58 | not from within interrupt context. | ||
| 59 | |||
| 60 | int hwspin_lock_timeout(struct hwspinlock *hwlock, unsigned int timeout); | ||
| 61 | - lock a previously-assigned hwspinlock with a timeout limit (specified in | ||
| 62 | msecs). If the hwspinlock is already taken, the function will busy loop | ||
| 63 | waiting for it to be released, but give up when the timeout elapses. | ||
| 64 | Upon a successful return from this function, preemption is disabled so | ||
| 65 | the caller must not sleep, and is advised to release the hwspinlock as | ||
| 66 | soon as possible, in order to minimize remote cores polling on the | ||
| 67 | hardware interconnect. | ||
| 68 | Returns 0 when successful and an appropriate error code otherwise (most | ||
| 69 | notably -ETIMEDOUT if the hwspinlock is still busy after timeout msecs). | ||
| 70 | The function will never sleep. | ||
| 71 | |||
| 72 | int hwspin_lock_timeout_irq(struct hwspinlock *hwlock, unsigned int timeout); | ||
| 73 | - lock a previously-assigned hwspinlock with a timeout limit (specified in | ||
| 74 | msecs). If the hwspinlock is already taken, the function will busy loop | ||
| 75 | waiting for it to be released, but give up when the timeout elapses. | ||
| 76 | Upon a successful return from this function, preemption and the local | ||
| 77 | interrupts are disabled, so the caller must not sleep, and is advised to | ||
| 78 | release the hwspinlock as soon as possible. | ||
| 79 | Returns 0 when successful and an appropriate error code otherwise (most | ||
| 80 | notably -ETIMEDOUT if the hwspinlock is still busy after timeout msecs). | ||
| 81 | The function will never sleep. | ||
| 82 | |||
| 83 | int hwspin_lock_timeout_irqsave(struct hwspinlock *hwlock, unsigned int to, | ||
| 84 | unsigned long *flags); | ||
| 85 | - lock a previously-assigned hwspinlock with a timeout limit (specified in | ||
| 86 | msecs). If the hwspinlock is already taken, the function will busy loop | ||
| 87 | waiting for it to be released, but give up when the timeout elapses. | ||
| 88 | Upon a successful return from this function, preemption is disabled, | ||
| 89 | local interrupts are disabled and their previous state is saved at the | ||
| 90 | given flags placeholder. The caller must not sleep, and is advised to | ||
| 91 | release the hwspinlock as soon as possible. | ||
| 92 | Returns 0 when successful and an appropriate error code otherwise (most | ||
| 93 | notably -ETIMEDOUT if the hwspinlock is still busy after timeout msecs). | ||
| 94 | The function will never sleep. | ||
| 95 | |||
| 96 | int hwspin_trylock(struct hwspinlock *hwlock); | ||
| 97 | - attempt to lock a previously-assigned hwspinlock, but immediately fail if | ||
| 98 | it is already taken. | ||
| 99 | Upon a successful return from this function, preemption is disabled so | ||
| 100 | caller must not sleep, and is advised to release the hwspinlock as soon as | ||
| 101 | possible, in order to minimize remote cores polling on the hardware | ||
| 102 | interconnect. | ||
| 103 | Returns 0 on success and an appropriate error code otherwise (most | ||
| 104 | notably -EBUSY if the hwspinlock was already taken). | ||
| 105 | The function will never sleep. | ||
| 106 | |||
| 107 | int hwspin_trylock_irq(struct hwspinlock *hwlock); | ||
| 108 | - attempt to lock a previously-assigned hwspinlock, but immediately fail if | ||
| 109 | it is already taken. | ||
| 110 | Upon a successful return from this function, preemption and the local | ||
| 111 | interrupts are disabled so caller must not sleep, and is advised to | ||
| 112 | release the hwspinlock as soon as possible. | ||
| 113 | Returns 0 on success and an appropriate error code otherwise (most | ||
| 114 | notably -EBUSY if the hwspinlock was already taken). | ||
| 115 | The function will never sleep. | ||
| 116 | |||
| 117 | int hwspin_trylock_irqsave(struct hwspinlock *hwlock, unsigned long *flags); | ||
| 118 | - attempt to lock a previously-assigned hwspinlock, but immediately fail if | ||
| 119 | it is already taken. | ||
| 120 | Upon a successful return from this function, preemption is disabled, | ||
| 121 | the local interrupts are disabled and their previous state is saved | ||
| 122 | at the given flags placeholder. The caller must not sleep, and is advised | ||
| 123 | to release the hwspinlock as soon as possible. | ||
| 124 | Returns 0 on success and an appropriate error code otherwise (most | ||
| 125 | notably -EBUSY if the hwspinlock was already taken). | ||
| 126 | The function will never sleep. | ||
| 127 | |||
| 128 | void hwspin_unlock(struct hwspinlock *hwlock); | ||
| 129 | - unlock a previously-locked hwspinlock. Always succeed, and can be called | ||
| 130 | from any context (the function never sleeps). Note: code should _never_ | ||
| 131 | unlock an hwspinlock which is already unlocked (there is no protection | ||
| 132 | against this). | ||
| 133 | |||
| 134 | void hwspin_unlock_irq(struct hwspinlock *hwlock); | ||
| 135 | - unlock a previously-locked hwspinlock and enable local interrupts. | ||
| 136 | The caller should _never_ unlock an hwspinlock which is already unlocked. | ||
| 137 | Doing so is considered a bug (there is no protection against this). | ||
| 138 | Upon a successful return from this function, preemption and local | ||
| 139 | interrupts are enabled. This function will never sleep. | ||
| 140 | |||
| 141 | void | ||
| 142 | hwspin_unlock_irqrestore(struct hwspinlock *hwlock, unsigned long *flags); | ||
| 143 | - unlock a previously-locked hwspinlock. | ||
| 144 | The caller should _never_ unlock an hwspinlock which is already unlocked. | ||
| 145 | Doing so is considered a bug (there is no protection against this). | ||
| 146 | Upon a successful return from this function, preemption is reenabled, | ||
| 147 | and the state of the local interrupts is restored to the state saved at | ||
| 148 | the given flags. This function will never sleep. | ||
| 149 | |||
| 150 | int hwspin_lock_get_id(struct hwspinlock *hwlock); | ||
| 151 | - retrieve id number of a given hwspinlock. This is needed when an | ||
| 152 | hwspinlock is dynamically assigned: before it can be used to achieve | ||
| 153 | mutual exclusion with a remote cpu, the id number should be communicated | ||
| 154 | to the remote task with which we want to synchronize. | ||
| 155 | Returns the hwspinlock id number, or -EINVAL if hwlock is null. | ||
| 156 | |||
| 157 | 3. Typical usage | ||
| 158 | |||
| 159 | #include <linux/hwspinlock.h> | ||
| 160 | #include <linux/err.h> | ||
| 161 | |||
| 162 | int hwspinlock_example1(void) | ||
| 163 | { | ||
| 164 | struct hwspinlock *hwlock; | ||
| 165 | int ret; | ||
| 166 | |||
| 167 | /* dynamically assign a hwspinlock */ | ||
| 168 | hwlock = hwspin_lock_request(); | ||
| 169 | if (!hwlock) | ||
| 170 | ... | ||
| 171 | |||
| 172 | id = hwspin_lock_get_id(hwlock); | ||
| 173 | /* probably need to communicate id to a remote processor now */ | ||
| 174 | |||
| 175 | /* take the lock, spin for 1 sec if it's already taken */ | ||
| 176 | ret = hwspin_lock_timeout(hwlock, 1000); | ||
| 177 | if (ret) | ||
| 178 | ... | ||
| 179 | |||
| 180 | /* | ||
| 181 | * we took the lock, do our thing now, but do NOT sleep | ||
| 182 | */ | ||
| 183 | |||
| 184 | /* release the lock */ | ||
| 185 | hwspin_unlock(hwlock); | ||
| 186 | |||
| 187 | /* free the lock */ | ||
| 188 | ret = hwspin_lock_free(hwlock); | ||
| 189 | if (ret) | ||
| 190 | ... | ||
| 191 | |||
| 192 | return ret; | ||
| 193 | } | ||
| 194 | |||
| 195 | int hwspinlock_example2(void) | ||
| 196 | { | ||
| 197 | struct hwspinlock *hwlock; | ||
| 198 | int ret; | ||
| 199 | |||
| 200 | /* | ||
| 201 | * assign a specific hwspinlock id - this should be called early | ||
| 202 | * by board init code. | ||
| 203 | */ | ||
| 204 | hwlock = hwspin_lock_request_specific(PREDEFINED_LOCK_ID); | ||
| 205 | if (!hwlock) | ||
| 206 | ... | ||
| 207 | |||
| 208 | /* try to take it, but don't spin on it */ | ||
| 209 | ret = hwspin_trylock(hwlock); | ||
| 210 | if (!ret) { | ||
| 211 | pr_info("lock is already taken\n"); | ||
| 212 | return -EBUSY; | ||
| 213 | } | ||
| 214 | |||
| 215 | /* | ||
| 216 | * we took the lock, do our thing now, but do NOT sleep | ||
| 217 | */ | ||
| 218 | |||
| 219 | /* release the lock */ | ||
| 220 | hwspin_unlock(hwlock); | ||
| 221 | |||
| 222 | /* free the lock */ | ||
| 223 | ret = hwspin_lock_free(hwlock); | ||
| 224 | if (ret) | ||
| 225 | ... | ||
| 226 | |||
| 227 | return ret; | ||
| 228 | } | ||
| 229 | |||
| 230 | |||
| 231 | 4. API for implementors | ||
| 232 | |||
| 233 | int hwspin_lock_register(struct hwspinlock *hwlock); | ||
| 234 | - to be called from the underlying platform-specific implementation, in | ||
| 235 | order to register a new hwspinlock instance. Can be called from an atomic | ||
| 236 | context (this function will not sleep) but not from within interrupt | ||
| 237 | context. Returns 0 on success, or appropriate error code on failure. | ||
| 238 | |||
| 239 | struct hwspinlock *hwspin_lock_unregister(unsigned int id); | ||
| 240 | - to be called from the underlying vendor-specific implementation, in order | ||
| 241 | to unregister an existing (and unused) hwspinlock instance. | ||
| 242 | Can be called from an atomic context (will not sleep) but not from | ||
| 243 | within interrupt context. | ||
| 244 | Returns the address of hwspinlock on success, or NULL on error (e.g. | ||
| 245 | if the hwspinlock is sill in use). | ||
| 246 | |||
| 247 | 5. struct hwspinlock | ||
| 248 | |||
| 249 | This struct represents an hwspinlock instance. It is registered by the | ||
| 250 | underlying hwspinlock implementation using the hwspin_lock_register() API. | ||
| 251 | |||
| 252 | /** | ||
| 253 | * struct hwspinlock - vendor-specific hwspinlock implementation | ||
| 254 | * | ||
| 255 | * @dev: underlying device, will be used with runtime PM api | ||
| 256 | * @ops: vendor-specific hwspinlock handlers | ||
| 257 | * @id: a global, unique, system-wide, index of the lock. | ||
| 258 | * @lock: initialized and used by hwspinlock core | ||
| 259 | * @owner: underlying implementation module, used to maintain module ref count | ||
| 260 | */ | ||
| 261 | struct hwspinlock { | ||
| 262 | struct device *dev; | ||
| 263 | const struct hwspinlock_ops *ops; | ||
| 264 | int id; | ||
| 265 | spinlock_t lock; | ||
| 266 | struct module *owner; | ||
| 267 | }; | ||
| 268 | |||
| 269 | The underlying implementation is responsible to assign the dev, ops, id and | ||
| 270 | owner members. The lock member, OTOH, is initialized and used by the hwspinlock | ||
| 271 | core. | ||
| 272 | |||
| 273 | 6. Implementation callbacks | ||
| 274 | |||
| 275 | There are three possible callbacks defined in 'struct hwspinlock_ops': | ||
| 276 | |||
| 277 | struct hwspinlock_ops { | ||
| 278 | int (*trylock)(struct hwspinlock *lock); | ||
| 279 | void (*unlock)(struct hwspinlock *lock); | ||
| 280 | void (*relax)(struct hwspinlock *lock); | ||
| 281 | }; | ||
| 282 | |||
| 283 | The first two callbacks are mandatory: | ||
| 284 | |||
| 285 | The ->trylock() callback should make a single attempt to take the lock, and | ||
| 286 | return 0 on failure and 1 on success. This callback may _not_ sleep. | ||
| 287 | |||
| 288 | The ->unlock() callback releases the lock. It always succeed, and it, too, | ||
| 289 | may _not_ sleep. | ||
| 290 | |||
| 291 | The ->relax() callback is optional. It is called by hwspinlock core while | ||
| 292 | spinning on a lock, and can be used by the underlying implementation to force | ||
| 293 | a delay between two successive invocations of ->trylock(). It may _not_ sleep. | ||
diff --git a/Documentation/i2c/busses/i2c-diolan-u2c b/Documentation/i2c/busses/i2c-diolan-u2c new file mode 100644 index 000000000000..30fe4bb9a069 --- /dev/null +++ b/Documentation/i2c/busses/i2c-diolan-u2c | |||
| @@ -0,0 +1,26 @@ | |||
| 1 | Kernel driver i2c-diolan-u2c | ||
| 2 | |||
| 3 | Supported adapters: | ||
| 4 | * Diolan U2C-12 I2C-USB adapter | ||
| 5 | Documentation: | ||
| 6 | http://www.diolan.com/i2c/u2c12.html | ||
| 7 | |||
| 8 | Author: Guenter Roeck <guenter.roeck@ericsson.com> | ||
| 9 | |||
| 10 | Description | ||
| 11 | ----------- | ||
| 12 | |||
| 13 | This is the driver for the Diolan U2C-12 USB-I2C adapter. | ||
| 14 | |||
| 15 | The Diolan U2C-12 I2C-USB Adapter provides a low cost solution to connect | ||
| 16 | a computer to I2C slave devices using a USB interface. It also supports | ||
| 17 | connectivity to SPI devices. | ||
| 18 | |||
| 19 | This driver only supports the I2C interface of U2C-12. The driver does not use | ||
| 20 | interrupts. | ||
| 21 | |||
| 22 | |||
| 23 | Module parameters | ||
| 24 | ----------------- | ||
| 25 | |||
| 26 | * frequency: I2C bus frequency | ||
diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801 index 93fe76e56522..6df69765ccb7 100644 --- a/Documentation/i2c/busses/i2c-i801 +++ b/Documentation/i2c/busses/i2c-i801 | |||
| @@ -16,8 +16,9 @@ Supported adapters: | |||
| 16 | * Intel EP80579 (Tolapai) | 16 | * Intel EP80579 (Tolapai) |
| 17 | * Intel 82801JI (ICH10) | 17 | * Intel 82801JI (ICH10) |
| 18 | * Intel 5/3400 Series (PCH) | 18 | * Intel 5/3400 Series (PCH) |
| 19 | * Intel Cougar Point (PCH) | 19 | * Intel 6 Series (PCH) |
| 20 | * Intel Patsburg (PCH) | 20 | * Intel Patsburg (PCH) |
| 21 | * Intel DH89xxCC (PCH) | ||
| 21 | Datasheets: Publicly available at the Intel website | 22 | Datasheets: Publicly available at the Intel website |
| 22 | 23 | ||
| 23 | On Intel Patsburg and later chipsets, both the normal host SMBus controller | 24 | On Intel Patsburg and later chipsets, both the normal host SMBus controller |
diff --git a/Documentation/i2c/busses/i2c-parport-light b/Documentation/i2c/busses/i2c-parport-light index bdc9cbb2e0f2..c22ee063e1e5 100644 --- a/Documentation/i2c/busses/i2c-parport-light +++ b/Documentation/i2c/busses/i2c-parport-light | |||
| @@ -4,7 +4,7 @@ Author: Jean Delvare <khali@linux-fr.org> | |||
| 4 | 4 | ||
| 5 | This driver is a light version of i2c-parport. It doesn't depend | 5 | This driver is a light version of i2c-parport. It doesn't depend |
| 6 | on the parport driver, and uses direct I/O access instead. This might be | 6 | on the parport driver, and uses direct I/O access instead. This might be |
| 7 | prefered on embedded systems where wasting memory for the clean but heavy | 7 | preferred on embedded systems where wasting memory for the clean but heavy |
| 8 | parport handling is not an option. The drawback is a reduced portability | 8 | parport handling is not an option. The drawback is a reduced portability |
| 9 | and the impossibility to daisy-chain other parallel port devices. | 9 | and the impossibility to daisy-chain other parallel port devices. |
| 10 | 10 | ||
diff --git a/Documentation/i2c/busses/i2c-sis96x b/Documentation/i2c/busses/i2c-sis96x index 70e6a0cc1e15..0b979f3252a4 100644 --- a/Documentation/i2c/busses/i2c-sis96x +++ b/Documentation/i2c/busses/i2c-sis96x | |||
| @@ -35,7 +35,7 @@ or perhaps this... | |||
| 35 | 35 | ||
| 36 | (kernel versions later than 2.4.18 may fill in the "Unknown"s) | 36 | (kernel versions later than 2.4.18 may fill in the "Unknown"s) |
| 37 | 37 | ||
| 38 | If you cant see it please look on quirk_sis_96x_smbus | 38 | If you can't see it please look on quirk_sis_96x_smbus |
| 39 | (drivers/pci/quirks.c) (also if southbridge detection fails) | 39 | (drivers/pci/quirks.c) (also if southbridge detection fails) |
| 40 | 40 | ||
| 41 | I suspect that this driver could be made to work for the following SiS | 41 | I suspect that this driver could be made to work for the following SiS |
diff --git a/Documentation/i2c/busses/i2c-taos-evm b/Documentation/i2c/busses/i2c-taos-evm index 9146e33be6dd..63f62bcbf592 100644 --- a/Documentation/i2c/busses/i2c-taos-evm +++ b/Documentation/i2c/busses/i2c-taos-evm | |||
| @@ -13,7 +13,7 @@ Currently supported devices are: | |||
| 13 | 13 | ||
| 14 | * TAOS TSL2550 EVM | 14 | * TAOS TSL2550 EVM |
| 15 | 15 | ||
| 16 | For addtional information on TAOS products, please see | 16 | For additional information on TAOS products, please see |
| 17 | http://www.taosinc.com/ | 17 | http://www.taosinc.com/ |
| 18 | 18 | ||
| 19 | 19 | ||
diff --git a/Documentation/i2c/instantiating-devices b/Documentation/i2c/instantiating-devices index 87da405a8597..9edb75d8c9b9 100644 --- a/Documentation/i2c/instantiating-devices +++ b/Documentation/i2c/instantiating-devices | |||
| @@ -100,7 +100,7 @@ static int __devinit usb_hcd_pnx4008_probe(struct platform_device *pdev) | |||
| 100 | (...) | 100 | (...) |
| 101 | i2c_adap = i2c_get_adapter(2); | 101 | i2c_adap = i2c_get_adapter(2); |
| 102 | memset(&i2c_info, 0, sizeof(struct i2c_board_info)); | 102 | memset(&i2c_info, 0, sizeof(struct i2c_board_info)); |
| 103 | strlcpy(i2c_info.name, "isp1301_pnx", I2C_NAME_SIZE); | 103 | strlcpy(i2c_info.type, "isp1301_pnx", I2C_NAME_SIZE); |
| 104 | isp1301_i2c_client = i2c_new_probed_device(i2c_adap, &i2c_info, | 104 | isp1301_i2c_client = i2c_new_probed_device(i2c_adap, &i2c_info, |
| 105 | normal_i2c, NULL); | 105 | normal_i2c, NULL); |
| 106 | i2c_put_adapter(i2c_adap); | 106 | i2c_put_adapter(i2c_adap); |
diff --git a/Documentation/i2c/upgrading-clients b/Documentation/i2c/upgrading-clients index 9a45f9bb6a25..d6991625c407 100644 --- a/Documentation/i2c/upgrading-clients +++ b/Documentation/i2c/upgrading-clients | |||
| @@ -61,7 +61,7 @@ static int example_attach(struct i2c_adapter *adap, int addr, int kind) | |||
| 61 | return 0; | 61 | return 0; |
| 62 | } | 62 | } |
| 63 | 63 | ||
| 64 | static int __devexit example_detach(struct i2c_client *client) | 64 | static int example_detach(struct i2c_client *client) |
| 65 | { | 65 | { |
| 66 | struct example_state *state = i2c_get_clientdata(client); | 66 | struct example_state *state = i2c_get_clientdata(client); |
| 67 | 67 | ||
| @@ -81,7 +81,7 @@ static struct i2c_driver example_driver = { | |||
| 81 | .name = "example", | 81 | .name = "example", |
| 82 | }, | 82 | }, |
| 83 | .attach_adapter = example_attach_adapter, | 83 | .attach_adapter = example_attach_adapter, |
| 84 | .detach_client = __devexit_p(example_detach), | 84 | .detach_client = example_detach, |
| 85 | .suspend = example_suspend, | 85 | .suspend = example_suspend, |
| 86 | .resume = example_resume, | 86 | .resume = example_resume, |
| 87 | }; | 87 | }; |
| @@ -93,7 +93,7 @@ Updating the client | |||
| 93 | The new style binding model will check against a list of supported | 93 | The new style binding model will check against a list of supported |
| 94 | devices and their associated address supplied by the code registering | 94 | devices and their associated address supplied by the code registering |
| 95 | the busses. This means that the driver .attach_adapter and | 95 | the busses. This means that the driver .attach_adapter and |
| 96 | .detach_adapter methods can be removed, along with the addr_data, | 96 | .detach_client methods can be removed, along with the addr_data, |
| 97 | as follows: | 97 | as follows: |
| 98 | 98 | ||
| 99 | - static struct i2c_driver example_driver; | 99 | - static struct i2c_driver example_driver; |
| @@ -110,14 +110,14 @@ as follows: | |||
| 110 | 110 | ||
| 111 | static struct i2c_driver example_driver = { | 111 | static struct i2c_driver example_driver = { |
| 112 | - .attach_adapter = example_attach_adapter, | 112 | - .attach_adapter = example_attach_adapter, |
| 113 | - .detach_client = __devexit_p(example_detach), | 113 | - .detach_client = example_detach, |
| 114 | } | 114 | } |
| 115 | 115 | ||
| 116 | Add the probe and remove methods to the i2c_driver, as so: | 116 | Add the probe and remove methods to the i2c_driver, as so: |
| 117 | 117 | ||
| 118 | static struct i2c_driver example_driver = { | 118 | static struct i2c_driver example_driver = { |
| 119 | + .probe = example_probe, | 119 | + .probe = example_probe, |
| 120 | + .remove = __devexit_p(example_remove), | 120 | + .remove = example_remove, |
| 121 | } | 121 | } |
| 122 | 122 | ||
| 123 | Change the example_attach method to accept the new parameters | 123 | Change the example_attach method to accept the new parameters |
| @@ -199,8 +199,8 @@ to delete the i2c_detach_client call. It is possible that you | |||
| 199 | can also remove the ret variable as it is not not needed for | 199 | can also remove the ret variable as it is not not needed for |
| 200 | any of the core functions. | 200 | any of the core functions. |
| 201 | 201 | ||
| 202 | - static int __devexit example_detach(struct i2c_client *client) | 202 | - static int example_detach(struct i2c_client *client) |
| 203 | + static int __devexit example_remove(struct i2c_client *client) | 203 | + static int example_remove(struct i2c_client *client) |
| 204 | { | 204 | { |
| 205 | struct example_state *state = i2c_get_clientdata(client); | 205 | struct example_state *state = i2c_get_clientdata(client); |
| 206 | 206 | ||
| @@ -253,7 +253,7 @@ static int example_probe(struct i2c_client *client, | |||
| 253 | return 0; | 253 | return 0; |
| 254 | } | 254 | } |
| 255 | 255 | ||
| 256 | static int __devexit example_remove(struct i2c_client *client) | 256 | static int example_remove(struct i2c_client *client) |
| 257 | { | 257 | { |
| 258 | struct example_state *state = i2c_get_clientdata(client); | 258 | struct example_state *state = i2c_get_clientdata(client); |
| 259 | 259 | ||
| @@ -275,7 +275,7 @@ static struct i2c_driver example_driver = { | |||
| 275 | }, | 275 | }, |
| 276 | .id_table = example_idtable, | 276 | .id_table = example_idtable, |
| 277 | .probe = example_probe, | 277 | .probe = example_probe, |
| 278 | .remove = __devexit_p(example_remove), | 278 | .remove = example_remove, |
| 279 | .suspend = example_suspend, | 279 | .suspend = example_suspend, |
| 280 | .resume = example_resume, | 280 | .resume = example_resume, |
| 281 | }; | 281 | }; |
diff --git a/Documentation/i2o/README b/Documentation/i2o/README index 0ebf58c73f54..ee91e2626ff0 100644 --- a/Documentation/i2o/README +++ b/Documentation/i2o/README | |||
| @@ -53,7 +53,7 @@ Symbios Logic (Now LSI) | |||
| 53 | BoxHill Corporation | 53 | BoxHill Corporation |
| 54 | Loan of initial FibreChannel disk array used for development work. | 54 | Loan of initial FibreChannel disk array used for development work. |
| 55 | 55 | ||
| 56 | European Comission | 56 | European Commission |
| 57 | Funding the work done by the University of Helsinki | 57 | Funding the work done by the University of Helsinki |
| 58 | 58 | ||
| 59 | SysKonnect | 59 | SysKonnect |
diff --git a/Documentation/ia64/aliasing-test.c b/Documentation/ia64/aliasing-test.c index 3dfb76ca6931..5caa2af33207 100644 --- a/Documentation/ia64/aliasing-test.c +++ b/Documentation/ia64/aliasing-test.c | |||
| @@ -177,7 +177,7 @@ static int scan_rom(char *path, char *file) | |||
| 177 | 177 | ||
| 178 | /* | 178 | /* |
| 179 | * It's OK if the ROM is unreadable. Maybe there | 179 | * It's OK if the ROM is unreadable. Maybe there |
| 180 | * is no ROM, or some other error ocurred. The | 180 | * is no ROM, or some other error occurred. The |
| 181 | * important thing is that no MCA happened. | 181 | * important thing is that no MCA happened. |
| 182 | */ | 182 | */ |
| 183 | if (rc > 0) | 183 | if (rc > 0) |
diff --git a/Documentation/input/elantech.txt b/Documentation/input/elantech.txt index 56941ae1f5db..db798af5ef98 100644 --- a/Documentation/input/elantech.txt +++ b/Documentation/input/elantech.txt | |||
| @@ -34,7 +34,8 @@ Contents | |||
| 34 | Currently the Linux Elantech touchpad driver is aware of two different | 34 | Currently the Linux Elantech touchpad driver is aware of two different |
| 35 | hardware versions unimaginatively called version 1 and version 2. Version 1 | 35 | hardware versions unimaginatively called version 1 and version 2. Version 1 |
| 36 | is found in "older" laptops and uses 4 bytes per packet. Version 2 seems to | 36 | is found in "older" laptops and uses 4 bytes per packet. Version 2 seems to |
| 37 | be introduced with the EeePC and uses 6 bytes per packet. | 37 | be introduced with the EeePC and uses 6 bytes per packet, and provides |
| 38 | additional features such as position of two fingers, and width of the touch. | ||
| 38 | 39 | ||
| 39 | The driver tries to support both hardware versions and should be compatible | 40 | The driver tries to support both hardware versions and should be compatible |
| 40 | with the Xorg Synaptics touchpad driver and its graphical configuration | 41 | with the Xorg Synaptics touchpad driver and its graphical configuration |
| @@ -94,18 +95,44 @@ Currently the Linux Elantech touchpad driver provides two extra knobs under | |||
| 94 | can check these bits and reject any packet that appears corrupted. Using | 95 | can check these bits and reject any packet that appears corrupted. Using |
| 95 | this knob you can bypass that check. | 96 | this knob you can bypass that check. |
| 96 | 97 | ||
| 97 | It is not known yet whether hardware version 2 provides the same parity | 98 | Hardware version 2 does not provide the same parity bits. Only some basic |
| 98 | bits. Hence checking is disabled by default. Currently even turning it on | 99 | data consistency checking can be done. For now checking is disabled by |
| 99 | will do nothing. | 100 | default. Currently even turning it on will do nothing. |
| 100 | |||
| 101 | 101 | ||
| 102 | ///////////////////////////////////////////////////////////////////////////// | 102 | ///////////////////////////////////////////////////////////////////////////// |
| 103 | 103 | ||
| 104 | 3. Differentiating hardware versions | ||
| 105 | ================================= | ||
| 106 | |||
| 107 | To detect the hardware version, read the version number as param[0].param[1].param[2] | ||
| 108 | |||
| 109 | 4 bytes version: (after the arrow is the name given in the Dell-provided driver) | ||
| 110 | 02.00.22 => EF013 | ||
| 111 | 02.06.00 => EF019 | ||
| 112 | In the wild, there appear to be more versions, such as 00.01.64, 01.00.21, | ||
| 113 | 02.00.00, 02.00.04, 02.00.06. | ||
| 114 | |||
| 115 | 6 bytes: | ||
| 116 | 02.00.30 => EF113 | ||
| 117 | 02.08.00 => EF023 | ||
| 118 | 02.08.XX => EF123 | ||
| 119 | 02.0B.00 => EF215 | ||
| 120 | 04.01.XX => Scroll_EF051 | ||
| 121 | 04.02.XX => EF051 | ||
| 122 | In the wild, there appear to be more versions, such as 04.03.01, 04.04.11. There | ||
| 123 | appears to be almost no difference, except for EF113, which does not report | ||
| 124 | pressure/width and has different data consistency checks. | ||
| 125 | |||
| 126 | Probably all the versions with param[0] <= 01 can be considered as | ||
| 127 | 4 bytes/firmware 1. The versions < 02.08.00, with the exception of 02.00.30, as | ||
| 128 | 4 bytes/firmware 2. Everything >= 02.08.00 can be considered as 6 bytes. | ||
| 129 | |||
| 130 | ///////////////////////////////////////////////////////////////////////////// | ||
| 104 | 131 | ||
| 105 | 3. Hardware version 1 | 132 | 4. Hardware version 1 |
| 106 | ================== | 133 | ================== |
| 107 | 134 | ||
| 108 | 3.1 Registers | 135 | 4.1 Registers |
| 109 | ~~~~~~~~~ | 136 | ~~~~~~~~~ |
| 110 | 137 | ||
| 111 | By echoing a hexadecimal value to a register it contents can be altered. | 138 | By echoing a hexadecimal value to a register it contents can be altered. |
| @@ -168,7 +195,7 @@ For example: | |||
| 168 | smart edge activation area width? | 195 | smart edge activation area width? |
| 169 | 196 | ||
| 170 | 197 | ||
| 171 | 3.2 Native relative mode 4 byte packet format | 198 | 4.2 Native relative mode 4 byte packet format |
| 172 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 199 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 173 | 200 | ||
| 174 | byte 0: | 201 | byte 0: |
| @@ -226,9 +253,13 @@ byte 3: | |||
| 226 | positive = down | 253 | positive = down |
| 227 | 254 | ||
| 228 | 255 | ||
| 229 | 3.3 Native absolute mode 4 byte packet format | 256 | 4.3 Native absolute mode 4 byte packet format |
| 230 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 257 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 231 | 258 | ||
| 259 | EF013 and EF019 have a special behaviour (due to a bug in the firmware?), and | ||
| 260 | when 1 finger is touching, the first 2 position reports must be discarded. | ||
| 261 | This counting is reset whenever a different number of fingers is reported. | ||
| 262 | |||
| 232 | byte 0: | 263 | byte 0: |
| 233 | firmware version 1.x: | 264 | firmware version 1.x: |
| 234 | 265 | ||
| @@ -279,11 +310,11 @@ byte 3: | |||
| 279 | ///////////////////////////////////////////////////////////////////////////// | 310 | ///////////////////////////////////////////////////////////////////////////// |
| 280 | 311 | ||
| 281 | 312 | ||
| 282 | 4. Hardware version 2 | 313 | 5. Hardware version 2 |
| 283 | ================== | 314 | ================== |
| 284 | 315 | ||
| 285 | 316 | ||
| 286 | 4.1 Registers | 317 | 5.1 Registers |
| 287 | ~~~~~~~~~ | 318 | ~~~~~~~~~ |
| 288 | 319 | ||
| 289 | By echoing a hexadecimal value to a register it contents can be altered. | 320 | By echoing a hexadecimal value to a register it contents can be altered. |
| @@ -316,16 +347,41 @@ For example: | |||
| 316 | 0x7f = never i.e. tap again to release) | 347 | 0x7f = never i.e. tap again to release) |
| 317 | 348 | ||
| 318 | 349 | ||
| 319 | 4.2 Native absolute mode 6 byte packet format | 350 | 5.2 Native absolute mode 6 byte packet format |
| 320 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 351 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 321 | 352 | 5.2.1 Parity checking and packet re-synchronization | |
| 322 | 4.2.1 One finger touch | 353 | There is no parity checking, however some consistency checks can be performed. |
| 354 | |||
| 355 | For instance for EF113: | ||
| 356 | SA1= packet[0]; | ||
| 357 | A1 = packet[1]; | ||
| 358 | B1 = packet[2]; | ||
| 359 | SB1= packet[3]; | ||
| 360 | C1 = packet[4]; | ||
| 361 | D1 = packet[5]; | ||
| 362 | if( (((SA1 & 0x3C) != 0x3C) && ((SA1 & 0xC0) != 0x80)) || // check Byte 1 | ||
| 363 | (((SA1 & 0x0C) != 0x0C) && ((SA1 & 0xC0) == 0x80)) || // check Byte 1 (one finger pressed) | ||
| 364 | (((SA1 & 0xC0) != 0x80) && (( A1 & 0xF0) != 0x00)) || // check Byte 2 | ||
| 365 | (((SB1 & 0x3E) != 0x38) && ((SA1 & 0xC0) != 0x80)) || // check Byte 4 | ||
| 366 | (((SB1 & 0x0E) != 0x08) && ((SA1 & 0xC0) == 0x80)) || // check Byte 4 (one finger pressed) | ||
| 367 | (((SA1 & 0xC0) != 0x80) && (( C1 & 0xF0) != 0x00)) ) // check Byte 5 | ||
| 368 | // error detected | ||
| 369 | |||
| 370 | For all the other ones, there are just a few constant bits: | ||
| 371 | if( ((packet[0] & 0x0C) != 0x04) || | ||
| 372 | ((packet[3] & 0x0f) != 0x02) ) | ||
| 373 | // error detected | ||
| 374 | |||
| 375 | |||
| 376 | In case an error is detected, all the packets are shifted by one (and packet[0] is discarded). | ||
| 377 | |||
| 378 | 5.2.1 One/Three finger touch | ||
| 323 | ~~~~~~~~~~~~~~~~ | 379 | ~~~~~~~~~~~~~~~~ |
| 324 | 380 | ||
| 325 | byte 0: | 381 | byte 0: |
| 326 | 382 | ||
| 327 | bit 7 6 5 4 3 2 1 0 | 383 | bit 7 6 5 4 3 2 1 0 |
| 328 | n1 n0 . . . . R L | 384 | n1 n0 w3 w2 . . R L |
| 329 | 385 | ||
| 330 | L, R = 1 when Left, Right mouse button pressed | 386 | L, R = 1 when Left, Right mouse button pressed |
| 331 | n1..n0 = numbers of fingers on touchpad | 387 | n1..n0 = numbers of fingers on touchpad |
| @@ -333,24 +389,40 @@ byte 0: | |||
| 333 | byte 1: | 389 | byte 1: |
| 334 | 390 | ||
| 335 | bit 7 6 5 4 3 2 1 0 | 391 | bit 7 6 5 4 3 2 1 0 |
| 336 | . . . . . x10 x9 x8 | 392 | p7 p6 p5 p4 . x10 x9 x8 |
| 337 | 393 | ||
| 338 | byte 2: | 394 | byte 2: |
| 339 | 395 | ||
| 340 | bit 7 6 5 4 3 2 1 0 | 396 | bit 7 6 5 4 3 2 1 0 |
| 341 | x7 x6 x5 x4 x4 x2 x1 x0 | 397 | x7 x6 x5 x4 x3 x2 x1 x0 |
| 342 | 398 | ||
| 343 | x10..x0 = absolute x value (horizontal) | 399 | x10..x0 = absolute x value (horizontal) |
| 344 | 400 | ||
| 345 | byte 3: | 401 | byte 3: |
| 346 | 402 | ||
| 347 | bit 7 6 5 4 3 2 1 0 | 403 | bit 7 6 5 4 3 2 1 0 |
| 348 | . . . . . . . . | 404 | n4 vf w1 w0 . . . b2 |
| 405 | |||
| 406 | n4 = set if more than 3 fingers (only in 3 fingers mode) | ||
| 407 | vf = a kind of flag ? (only on EF123, 0 when finger is over one | ||
| 408 | of the buttons, 1 otherwise) | ||
| 409 | w3..w0 = width of the finger touch (not EF113) | ||
| 410 | b2 (on EF113 only, 0 otherwise), b2.R.L indicates one button pressed: | ||
| 411 | 0 = none | ||
| 412 | 1 = Left | ||
| 413 | 2 = Right | ||
| 414 | 3 = Middle (Left and Right) | ||
| 415 | 4 = Forward | ||
| 416 | 5 = Back | ||
| 417 | 6 = Another one | ||
| 418 | 7 = Another one | ||
| 349 | 419 | ||
| 350 | byte 4: | 420 | byte 4: |
| 351 | 421 | ||
| 352 | bit 7 6 5 4 3 2 1 0 | 422 | bit 7 6 5 4 3 2 1 0 |
| 353 | . . . . . . y9 y8 | 423 | p3 p1 p2 p0 . . y9 y8 |
| 424 | |||
| 425 | p7..p0 = pressure (not EF113) | ||
| 354 | 426 | ||
| 355 | byte 5: | 427 | byte 5: |
| 356 | 428 | ||
| @@ -363,6 +435,11 @@ byte 5: | |||
| 363 | 4.2.2 Two finger touch | 435 | 4.2.2 Two finger touch |
| 364 | ~~~~~~~~~~~~~~~~ | 436 | ~~~~~~~~~~~~~~~~ |
| 365 | 437 | ||
| 438 | Note that the two pairs of coordinates are not exactly the coordinates of the | ||
| 439 | two fingers, but only the pair of the lower-left and upper-right coordinates. | ||
| 440 | So the actual fingers might be situated on the other diagonal of the square | ||
| 441 | defined by these two points. | ||
| 442 | |||
| 366 | byte 0: | 443 | byte 0: |
| 367 | 444 | ||
| 368 | bit 7 6 5 4 3 2 1 0 | 445 | bit 7 6 5 4 3 2 1 0 |
| @@ -376,14 +453,14 @@ byte 1: | |||
| 376 | bit 7 6 5 4 3 2 1 0 | 453 | bit 7 6 5 4 3 2 1 0 |
| 377 | ax7 ax6 ax5 ax4 ax3 ax2 ax1 ax0 | 454 | ax7 ax6 ax5 ax4 ax3 ax2 ax1 ax0 |
| 378 | 455 | ||
| 379 | ax8..ax0 = first finger absolute x value | 456 | ax8..ax0 = lower-left finger absolute x value |
| 380 | 457 | ||
| 381 | byte 2: | 458 | byte 2: |
| 382 | 459 | ||
| 383 | bit 7 6 5 4 3 2 1 0 | 460 | bit 7 6 5 4 3 2 1 0 |
| 384 | ay7 ay6 ay5 ay4 ay3 ay2 ay1 ay0 | 461 | ay7 ay6 ay5 ay4 ay3 ay2 ay1 ay0 |
| 385 | 462 | ||
| 386 | ay8..ay0 = first finger absolute y value | 463 | ay8..ay0 = lower-left finger absolute y value |
| 387 | 464 | ||
| 388 | byte 3: | 465 | byte 3: |
| 389 | 466 | ||
| @@ -395,11 +472,11 @@ byte 4: | |||
| 395 | bit 7 6 5 4 3 2 1 0 | 472 | bit 7 6 5 4 3 2 1 0 |
| 396 | bx7 bx6 bx5 bx4 bx3 bx2 bx1 bx0 | 473 | bx7 bx6 bx5 bx4 bx3 bx2 bx1 bx0 |
| 397 | 474 | ||
| 398 | bx8..bx0 = second finger absolute x value | 475 | bx8..bx0 = upper-right finger absolute x value |
| 399 | 476 | ||
| 400 | byte 5: | 477 | byte 5: |
| 401 | 478 | ||
| 402 | bit 7 6 5 4 3 2 1 0 | 479 | bit 7 6 5 4 3 2 1 0 |
| 403 | by7 by8 by5 by4 by3 by2 by1 by0 | 480 | by7 by8 by5 by4 by3 by2 by1 by0 |
| 404 | 481 | ||
| 405 | by8..by0 = second finger absolute y value | 482 | by8..by0 = upper-right finger absolute y value |
diff --git a/Documentation/input/joystick-parport.txt b/Documentation/input/joystick-parport.txt index 1c856f32ff2c..56870c70a796 100644 --- a/Documentation/input/joystick-parport.txt +++ b/Documentation/input/joystick-parport.txt | |||
| @@ -272,7 +272,7 @@ if you want to use gamecon.c. | |||
| 272 | 272 | ||
| 273 | Also, the connection is a bit more complex. You'll need a bunch of diodes, | 273 | Also, the connection is a bit more complex. You'll need a bunch of diodes, |
| 274 | and one pullup resistor. First, you connect the Directions and the button | 274 | and one pullup resistor. First, you connect the Directions and the button |
| 275 | the same as for db9, however with the diodes inbetween. | 275 | the same as for db9, however with the diodes between. |
| 276 | 276 | ||
| 277 | Diodes | 277 | Diodes |
| 278 | (pin 2) -----|<|----> Up | 278 | (pin 2) -----|<|----> Up |
diff --git a/Documentation/input/rotary-encoder.txt b/Documentation/input/rotary-encoder.txt index 8b4129de1d2d..92e68bce13a4 100644 --- a/Documentation/input/rotary-encoder.txt +++ b/Documentation/input/rotary-encoder.txt | |||
| @@ -9,6 +9,9 @@ peripherals with two wires. The outputs are phase-shifted by 90 degrees | |||
| 9 | and by triggering on falling and rising edges, the turn direction can | 9 | and by triggering on falling and rising edges, the turn direction can |
| 10 | be determined. | 10 | be determined. |
| 11 | 11 | ||
| 12 | Some encoders have both outputs low in stable states, whereas others also have | ||
| 13 | a stable state with both outputs high (half-period mode). | ||
| 14 | |||
| 12 | The phase diagram of these two outputs look like this: | 15 | The phase diagram of these two outputs look like this: |
| 13 | 16 | ||
| 14 | _____ _____ _____ | 17 | _____ _____ _____ |
| @@ -26,6 +29,8 @@ The phase diagram of these two outputs look like this: | |||
| 26 | |<-------->| | 29 | |<-------->| |
| 27 | one step | 30 | one step |
| 28 | 31 | ||
| 32 | |<-->| | ||
| 33 | one step (half-period mode) | ||
| 29 | 34 | ||
| 30 | For more information, please see | 35 | For more information, please see |
| 31 | http://en.wikipedia.org/wiki/Rotary_encoder | 36 | http://en.wikipedia.org/wiki/Rotary_encoder |
| @@ -34,6 +39,13 @@ For more information, please see | |||
| 34 | 1. Events / state machine | 39 | 1. Events / state machine |
| 35 | ------------------------- | 40 | ------------------------- |
| 36 | 41 | ||
| 42 | In half-period mode, state a) and c) above are used to determine the | ||
| 43 | rotational direction based on the last stable state. Events are reported in | ||
| 44 | states b) and d) given that the new stable state is different from the last | ||
| 45 | (i.e. the rotation was not reversed half-way). | ||
| 46 | |||
| 47 | Otherwise, the following apply: | ||
| 48 | |||
| 37 | a) Rising edge on channel A, channel B in low state | 49 | a) Rising edge on channel A, channel B in low state |
| 38 | This state is used to recognize a clockwise turn | 50 | This state is used to recognize a clockwise turn |
| 39 | 51 | ||
| @@ -46,7 +58,7 @@ c) Falling edge on channel A, channel B in high state | |||
| 46 | 58 | ||
| 47 | d) Falling edge on channel B, channel A in low state | 59 | d) Falling edge on channel B, channel A in low state |
| 48 | Parking position. If the encoder enters this state, a full transition | 60 | Parking position. If the encoder enters this state, a full transition |
| 49 | should have happend, unless it flipped back on half the way. The | 61 | should have happened, unless it flipped back on half the way. The |
| 50 | 'armed' state tells us about that. | 62 | 'armed' state tells us about that. |
| 51 | 63 | ||
| 52 | 2. Platform requirements | 64 | 2. Platform requirements |
| @@ -96,6 +108,7 @@ static struct rotary_encoder_platform_data my_rotary_encoder_info = { | |||
| 96 | .gpio_b = GPIO_ROTARY_B, | 108 | .gpio_b = GPIO_ROTARY_B, |
| 97 | .inverted_a = 0, | 109 | .inverted_a = 0, |
| 98 | .inverted_b = 0, | 110 | .inverted_b = 0, |
| 111 | .half_period = false, | ||
| 99 | }; | 112 | }; |
| 100 | 113 | ||
| 101 | static struct platform_device rotary_encoder_device = { | 114 | static struct platform_device rotary_encoder_device = { |
diff --git a/Documentation/input/walkera0701.txt b/Documentation/input/walkera0701.txt index 8f4289efc5c4..561385d38482 100644 --- a/Documentation/input/walkera0701.txt +++ b/Documentation/input/walkera0701.txt | |||
| @@ -77,7 +77,7 @@ pulse length: | |||
| 77 | 77 | ||
| 78 | 24 bin+oct values + 1 bin value = 24*4+1 bits = 97 bits | 78 | 24 bin+oct values + 1 bin value = 24*4+1 bits = 97 bits |
| 79 | 79 | ||
| 80 | (Warning, pulses on ACK ar inverted by transistor, irq is rised up on sync | 80 | (Warning, pulses on ACK are inverted by transistor, irq is raised up on sync |
| 81 | to bin change or octal value to bin change). | 81 | to bin change or octal value to bin change). |
| 82 | 82 | ||
| 83 | Binary data representations: | 83 | Binary data representations: |
diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index ac293e955308..a0a5d82b6b0b 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt | |||
| @@ -133,6 +133,7 @@ Code Seq#(hex) Include File Comments | |||
| 133 | 'H' C0-DF net/bluetooth/hidp/hidp.h conflict! | 133 | 'H' C0-DF net/bluetooth/hidp/hidp.h conflict! |
| 134 | 'H' C0-DF net/bluetooth/cmtp/cmtp.h conflict! | 134 | 'H' C0-DF net/bluetooth/cmtp/cmtp.h conflict! |
| 135 | 'H' C0-DF net/bluetooth/bnep/bnep.h conflict! | 135 | 'H' C0-DF net/bluetooth/bnep/bnep.h conflict! |
| 136 | 'H' F1 linux/hid-roccat.h <mailto:erazor_de@users.sourceforge.net> | ||
| 136 | 'I' all linux/isdn.h conflict! | 137 | 'I' all linux/isdn.h conflict! |
| 137 | 'I' 00-0F drivers/isdn/divert/isdn_divert.h conflict! | 138 | 'I' 00-0F drivers/isdn/divert/isdn_divert.h conflict! |
| 138 | 'I' 40-4F linux/mISDNif.h conflict! | 139 | 'I' 40-4F linux/mISDNif.h conflict! |
| @@ -272,6 +273,7 @@ Code Seq#(hex) Include File Comments | |||
| 272 | 'z' 40-7F CAN bus card conflict! | 273 | 'z' 40-7F CAN bus card conflict! |
| 273 | <mailto:oe@port.de> | 274 | <mailto:oe@port.de> |
| 274 | 'z' 10-4F drivers/s390/crypto/zcrypt_api.h conflict! | 275 | 'z' 10-4F drivers/s390/crypto/zcrypt_api.h conflict! |
| 276 | '|' 00-7F linux/media.h | ||
| 275 | 0x80 00-1F linux/fb.h | 277 | 0x80 00-1F linux/fb.h |
| 276 | 0x89 00-06 arch/x86/include/asm/sockios.h | 278 | 0x89 00-06 arch/x86/include/asm/sockios.h |
| 277 | 0x89 0B-DF linux/sockios.h | 279 | 0x89 0B-DF linux/sockios.h |
diff --git a/Documentation/iostats.txt b/Documentation/iostats.txt index f6dece5b7014..c76c21d87e85 100644 --- a/Documentation/iostats.txt +++ b/Documentation/iostats.txt | |||
| @@ -1,8 +1,6 @@ | |||
| 1 | I/O statistics fields | 1 | I/O statistics fields |
| 2 | --------------- | 2 | --------------- |
| 3 | 3 | ||
| 4 | Last modified Sep 30, 2003 | ||
| 5 | |||
| 6 | Since 2.4.20 (and some versions before, with patches), and 2.5.45, | 4 | Since 2.4.20 (and some versions before, with patches), and 2.5.45, |
| 7 | more extensive disk statistics have been introduced to help measure disk | 5 | more extensive disk statistics have been introduced to help measure disk |
| 8 | activity. Tools such as sar and iostat typically interpret these and do | 6 | activity. Tools such as sar and iostat typically interpret these and do |
| @@ -46,11 +44,12 @@ the above example, the first field of statistics would be 446216. | |||
| 46 | By contrast, in 2.6 if you look at /sys/block/hda/stat, you'll | 44 | By contrast, in 2.6 if you look at /sys/block/hda/stat, you'll |
| 47 | find just the eleven fields, beginning with 446216. If you look at | 45 | find just the eleven fields, beginning with 446216. If you look at |
| 48 | /proc/diskstats, the eleven fields will be preceded by the major and | 46 | /proc/diskstats, the eleven fields will be preceded by the major and |
| 49 | minor device numbers, and device name. Each of these formats provide | 47 | minor device numbers, and device name. Each of these formats provides |
| 50 | eleven fields of statistics, each meaning exactly the same things. | 48 | eleven fields of statistics, each meaning exactly the same things. |
| 51 | All fields except field 9 are cumulative since boot. Field 9 should | 49 | All fields except field 9 are cumulative since boot. Field 9 should |
| 52 | go to zero as I/Os complete; all others only increase. Yes, these are | 50 | go to zero as I/Os complete; all others only increase (unless they |
| 53 | 32 bit unsigned numbers, and on a very busy or long-lived system they | 51 | overflow and wrap). Yes, these are (32-bit or 64-bit) unsigned long |
| 52 | (native word size) numbers, and on a very busy or long-lived system they | ||
| 54 | may wrap. Applications should be prepared to deal with that; unless | 53 | may wrap. Applications should be prepared to deal with that; unless |
| 55 | your observations are measured in large numbers of minutes or hours, | 54 | your observations are measured in large numbers of minutes or hours, |
| 56 | they should not wrap twice before you notice them. | 55 | they should not wrap twice before you notice them. |
| @@ -96,11 +95,11 @@ introduced when changes collide, so (for instance) adding up all the | |||
| 96 | read I/Os issued per partition should equal those made to the disks ... | 95 | read I/Os issued per partition should equal those made to the disks ... |
| 97 | but due to the lack of locking it may only be very close. | 96 | but due to the lack of locking it may only be very close. |
| 98 | 97 | ||
| 99 | In 2.6, there are counters for each cpu, which made the lack of locking | 98 | In 2.6, there are counters for each CPU, which make the lack of locking |
| 100 | almost a non-issue. When the statistics are read, the per-cpu counters | 99 | almost a non-issue. When the statistics are read, the per-CPU counters |
| 101 | are summed (possibly overflowing the unsigned 32-bit variable they are | 100 | are summed (possibly overflowing the unsigned long variable they are |
| 102 | summed to) and the result given to the user. There is no convenient | 101 | summed to) and the result given to the user. There is no convenient |
| 103 | user interface for accessing the per-cpu counters themselves. | 102 | user interface for accessing the per-CPU counters themselves. |
| 104 | 103 | ||
| 105 | Disks vs Partitions | 104 | Disks vs Partitions |
| 106 | ------------------- | 105 | ------------------- |
diff --git a/Documentation/irqflags-tracing.txt b/Documentation/irqflags-tracing.txt index 6a444877ee0b..67aa71e73035 100644 --- a/Documentation/irqflags-tracing.txt +++ b/Documentation/irqflags-tracing.txt | |||
| @@ -53,5 +53,5 @@ implementation in an architecture: lockdep will detect that and will | |||
| 53 | turn itself off. I.e. the lock validator will still be reliable. There | 53 | turn itself off. I.e. the lock validator will still be reliable. There |
| 54 | should be no crashes due to irq-tracing bugs. (except if the assembly | 54 | should be no crashes due to irq-tracing bugs. (except if the assembly |
| 55 | changes break other code by modifying conditions or registers that | 55 | changes break other code by modifying conditions or registers that |
| 56 | shouldnt be) | 56 | shouldn't be) |
| 57 | 57 | ||
diff --git a/Documentation/isdn/INTERFACE.CAPI b/Documentation/isdn/INTERFACE.CAPI index 309eb5ed942b..1688b5a1fd77 100644 --- a/Documentation/isdn/INTERFACE.CAPI +++ b/Documentation/isdn/INTERFACE.CAPI | |||
| @@ -240,7 +240,7 @@ Functions capi_cmsg2message() and capi_message2cmsg() are provided to convert | |||
| 240 | messages between their transport encoding described in the CAPI 2.0 standard | 240 | messages between their transport encoding described in the CAPI 2.0 standard |
| 241 | and their _cmsg structure representation. Note that capi_cmsg2message() does | 241 | and their _cmsg structure representation. Note that capi_cmsg2message() does |
| 242 | not know or check the size of its destination buffer. The caller must make | 242 | not know or check the size of its destination buffer. The caller must make |
| 243 | sure it is big enough to accomodate the resulting CAPI message. | 243 | sure it is big enough to accommodate the resulting CAPI message. |
| 244 | 244 | ||
| 245 | 245 | ||
| 246 | 5. Lower Layer Interface Functions | 246 | 5. Lower Layer Interface Functions |
diff --git a/Documentation/kbuild/kbuild.txt b/Documentation/kbuild/kbuild.txt index 4a990317b84a..7c2a89ba674c 100644 --- a/Documentation/kbuild/kbuild.txt +++ b/Documentation/kbuild/kbuild.txt | |||
| @@ -26,11 +26,11 @@ Additional options to the assembler (for built-in and modules). | |||
| 26 | 26 | ||
| 27 | AFLAGS_MODULE | 27 | AFLAGS_MODULE |
| 28 | -------------------------------------------------- | 28 | -------------------------------------------------- |
| 29 | Addtional module specific options to use for $(AS). | 29 | Additional module specific options to use for $(AS). |
| 30 | 30 | ||
| 31 | AFLAGS_KERNEL | 31 | AFLAGS_KERNEL |
| 32 | -------------------------------------------------- | 32 | -------------------------------------------------- |
| 33 | Addtional options for $(AS) when used for assembler | 33 | Additional options for $(AS) when used for assembler |
| 34 | code for code that is compiled as built-in. | 34 | code for code that is compiled as built-in. |
| 35 | 35 | ||
| 36 | KCFLAGS | 36 | KCFLAGS |
| @@ -39,12 +39,12 @@ Additional options to the C compiler (for built-in and modules). | |||
| 39 | 39 | ||
| 40 | CFLAGS_KERNEL | 40 | CFLAGS_KERNEL |
| 41 | -------------------------------------------------- | 41 | -------------------------------------------------- |
| 42 | Addtional options for $(CC) when used to compile | 42 | Additional options for $(CC) when used to compile |
| 43 | code that is compiled as built-in. | 43 | code that is compiled as built-in. |
| 44 | 44 | ||
| 45 | CFLAGS_MODULE | 45 | CFLAGS_MODULE |
| 46 | -------------------------------------------------- | 46 | -------------------------------------------------- |
| 47 | Addtional module specific options to use for $(CC). | 47 | Additional module specific options to use for $(CC). |
| 48 | 48 | ||
| 49 | LDFLAGS_MODULE | 49 | LDFLAGS_MODULE |
| 50 | -------------------------------------------------- | 50 | -------------------------------------------------- |
| @@ -146,7 +146,7 @@ INSTALL_MOD_STRIP | |||
| 146 | INSTALL_MOD_STRIP, if defined, will cause modules to be | 146 | INSTALL_MOD_STRIP, if defined, will cause modules to be |
| 147 | stripped after they are installed. If INSTALL_MOD_STRIP is '1', then | 147 | stripped after they are installed. If INSTALL_MOD_STRIP is '1', then |
| 148 | the default option --strip-debug will be used. Otherwise, | 148 | the default option --strip-debug will be used. Otherwise, |
| 149 | INSTALL_MOD_STRIP will used as the options to the strip command. | 149 | INSTALL_MOD_STRIP value will be used as the options to the strip command. |
| 150 | 150 | ||
| 151 | INSTALL_FW_PATH | 151 | INSTALL_FW_PATH |
| 152 | -------------------------------------------------- | 152 | -------------------------------------------------- |
| @@ -196,3 +196,8 @@ to be included in the databases, separated by blank space. E.g.: | |||
| 196 | To get all available archs you can also specify all. E.g.: | 196 | To get all available archs you can also specify all. E.g.: |
| 197 | 197 | ||
| 198 | $ make ALLSOURCE_ARCHS=all tags | 198 | $ make ALLSOURCE_ARCHS=all tags |
| 199 | |||
| 200 | KBUILD_ENABLE_EXTRA_GCC_CHECKS | ||
| 201 | -------------------------------------------------- | ||
| 202 | If enabled over the make command line with "W=1", it turns on additional | ||
| 203 | gcc -W... options for more extensive build-time checking. | ||
diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index 86e3cd0d26a0..5d145bb443c0 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt | |||
| @@ -1325,7 +1325,8 @@ The top Makefile exports the following variables: | |||
| 1325 | If this variable is specified, will cause modules to be stripped | 1325 | If this variable is specified, will cause modules to be stripped |
| 1326 | after they are installed. If INSTALL_MOD_STRIP is '1', then the | 1326 | after they are installed. If INSTALL_MOD_STRIP is '1', then the |
| 1327 | default option --strip-debug will be used. Otherwise, | 1327 | default option --strip-debug will be used. Otherwise, |
| 1328 | INSTALL_MOD_STRIP will used as the option(s) to the strip command. | 1328 | INSTALL_MOD_STRIP value will be used as the option(s) to the strip |
| 1329 | command. | ||
| 1329 | 1330 | ||
| 1330 | 1331 | ||
| 1331 | === 9 Makefile language | 1332 | === 9 Makefile language |
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 89835a4766a6..cc85a9278190 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt | |||
| @@ -144,6 +144,11 @@ a fixed number of characters. This limit depends on the architecture | |||
| 144 | and is between 256 and 4096 characters. It is defined in the file | 144 | and is between 256 and 4096 characters. It is defined in the file |
| 145 | ./include/asm/setup.h as COMMAND_LINE_SIZE. | 145 | ./include/asm/setup.h as COMMAND_LINE_SIZE. |
| 146 | 146 | ||
| 147 | Finally, the [KMG] suffix is commonly described after a number of kernel | ||
| 148 | parameter values. These 'K', 'M', and 'G' letters represent the _binary_ | ||
| 149 | multipliers 'Kilo', 'Mega', and 'Giga', equalling 2^10, 2^20, and 2^30 | ||
| 150 | bytes respectively. Such letter suffixes can also be entirely omitted. | ||
| 151 | |||
| 147 | 152 | ||
| 148 | acpi= [HW,ACPI,X86] | 153 | acpi= [HW,ACPI,X86] |
| 149 | Advanced Configuration and Power Interface | 154 | Advanced Configuration and Power Interface |
| @@ -545,16 +550,20 @@ and is between 256 and 4096 characters. It is defined in the file | |||
| 545 | Format: | 550 | Format: |
| 546 | <first_slot>,<last_slot>,<port>,<enum_bit>[,<debug>] | 551 | <first_slot>,<last_slot>,<port>,<enum_bit>[,<debug>] |
| 547 | 552 | ||
| 548 | crashkernel=nn[KMG]@ss[KMG] | 553 | crashkernel=size[KMG][@offset[KMG]] |
| 549 | [KNL] Reserve a chunk of physical memory to | 554 | [KNL] Using kexec, Linux can switch to a 'crash kernel' |
| 550 | hold a kernel to switch to with kexec on panic. | 555 | upon panic. This parameter reserves the physical |
| 556 | memory region [offset, offset + size] for that kernel | ||
| 557 | image. If '@offset' is omitted, then a suitable offset | ||
| 558 | is selected automatically. Check | ||
| 559 | Documentation/kdump/kdump.txt for further details. | ||
| 551 | 560 | ||
| 552 | crashkernel=range1:size1[,range2:size2,...][@offset] | 561 | crashkernel=range1:size1[,range2:size2,...][@offset] |
| 553 | [KNL] Same as above, but depends on the memory | 562 | [KNL] Same as above, but depends on the memory |
| 554 | in the running system. The syntax of range is | 563 | in the running system. The syntax of range is |
| 555 | start-[end] where start and end are both | 564 | start-[end] where start and end are both |
| 556 | a memory unit (amount[KMG]). See also | 565 | a memory unit (amount[KMG]). See also |
| 557 | Documentation/kdump/kdump.txt for a example. | 566 | Documentation/kdump/kdump.txt for an example. |
| 558 | 567 | ||
| 559 | cs89x0_dma= [HW,NET] | 568 | cs89x0_dma= [HW,NET] |
| 560 | Format: <dma> | 569 | Format: <dma> |
| @@ -617,6 +626,10 @@ and is between 256 and 4096 characters. It is defined in the file | |||
| 617 | disable= [IPV6] | 626 | disable= [IPV6] |
| 618 | See Documentation/networking/ipv6.txt. | 627 | See Documentation/networking/ipv6.txt. |
| 619 | 628 | ||
| 629 | disable_ddw [PPC/PSERIES] | ||
| 630 | Disable Dynamic DMA Window support. Use this if | ||
| 631 | to workaround buggy firmware. | ||
| 632 | |||
| 620 | disable_ipv6= [IPV6] | 633 | disable_ipv6= [IPV6] |
| 621 | See Documentation/networking/ipv6.txt. | 634 | See Documentation/networking/ipv6.txt. |
| 622 | 635 | ||
| @@ -686,7 +699,7 @@ and is between 256 and 4096 characters. It is defined in the file | |||
| 686 | ekgdboc= [X86,KGDB] Allow early kernel console debugging | 699 | ekgdboc= [X86,KGDB] Allow early kernel console debugging |
| 687 | ekgdboc=kbd | 700 | ekgdboc=kbd |
| 688 | 701 | ||
| 689 | This is desgined to be used in conjunction with | 702 | This is designed to be used in conjunction with |
| 690 | the boot argument: earlyprintk=vga | 703 | the boot argument: earlyprintk=vga |
| 691 | 704 | ||
| 692 | edd= [EDD] | 705 | edd= [EDD] |
| @@ -859,6 +872,12 @@ and is between 256 and 4096 characters. It is defined in the file | |||
| 859 | If specified, z/VM IUCV HVC accepts connections | 872 | If specified, z/VM IUCV HVC accepts connections |
| 860 | from listed z/VM user IDs only. | 873 | from listed z/VM user IDs only. |
| 861 | 874 | ||
| 875 | keep_bootcon [KNL] | ||
| 876 | Do not unregister boot console at start. This is only | ||
| 877 | useful for debugging when something happens in the window | ||
| 878 | between unregistering the boot console and initializing | ||
| 879 | the real console. | ||
| 880 | |||
| 862 | i2c_bus= [HW] Override the default board specific I2C bus speed | 881 | i2c_bus= [HW] Override the default board specific I2C bus speed |
| 863 | or register an additional I2C bus that is not | 882 | or register an additional I2C bus that is not |
| 864 | registered from board initialization code. | 883 | registered from board initialization code. |
| @@ -1262,10 +1281,9 @@ and is between 256 and 4096 characters. It is defined in the file | |||
| 1262 | 6 (KERN_INFO) informational | 1281 | 6 (KERN_INFO) informational |
| 1263 | 7 (KERN_DEBUG) debug-level messages | 1282 | 7 (KERN_DEBUG) debug-level messages |
| 1264 | 1283 | ||
| 1265 | log_buf_len=n Sets the size of the printk ring buffer, in bytes. | 1284 | log_buf_len=n[KMG] Sets the size of the printk ring buffer, |
| 1266 | Format: { n | nk | nM } | 1285 | in bytes. n must be a power of two. The default |
| 1267 | n must be a power of two. The default size | 1286 | size is set in the kernel config file. |
| 1268 | is set in the kernel config file. | ||
| 1269 | 1287 | ||
| 1270 | logo.nologo [FB] Disables display of the built-in Linux logo. | 1288 | logo.nologo [FB] Disables display of the built-in Linux logo. |
| 1271 | This may be used to provide more screen space for | 1289 | This may be used to provide more screen space for |
| @@ -1572,16 +1590,25 @@ and is between 256 and 4096 characters. It is defined in the file | |||
| 1572 | of returning the full 64-bit number. | 1590 | of returning the full 64-bit number. |
| 1573 | The default is to return 64-bit inode numbers. | 1591 | The default is to return 64-bit inode numbers. |
| 1574 | 1592 | ||
| 1593 | nfs.nfs4_disable_idmapping= | ||
| 1594 | [NFSv4] When set, this option disables the NFSv4 | ||
| 1595 | idmapper on the client, but only if the mount | ||
| 1596 | is using the 'sec=sys' security flavour. This may | ||
| 1597 | make migration from legacy NFSv2/v3 systems easier | ||
| 1598 | provided that the server has the appropriate support. | ||
| 1599 | The default is to always enable NFSv4 idmapping. | ||
| 1600 | |||
| 1575 | nmi_debug= [KNL,AVR32,SH] Specify one or more actions to take | 1601 | nmi_debug= [KNL,AVR32,SH] Specify one or more actions to take |
| 1576 | when a NMI is triggered. | 1602 | when a NMI is triggered. |
| 1577 | Format: [state][,regs][,debounce][,die] | 1603 | Format: [state][,regs][,debounce][,die] |
| 1578 | 1604 | ||
| 1579 | nmi_watchdog= [KNL,BUGS=X86] Debugging features for SMP kernels | 1605 | nmi_watchdog= [KNL,BUGS=X86] Debugging features for SMP kernels |
| 1580 | Format: [panic,][num] | 1606 | Format: [panic,][nopanic,][num] |
| 1581 | Valid num: 0 | 1607 | Valid num: 0 |
| 1582 | 0 - turn nmi_watchdog off | 1608 | 0 - turn nmi_watchdog off |
| 1583 | When panic is specified, panic when an NMI watchdog | 1609 | When panic is specified, panic when an NMI watchdog |
| 1584 | timeout occurs. | 1610 | timeout occurs (or 'nopanic' to override the opposite |
| 1611 | default). | ||
| 1585 | This is useful when you use a panic=... timeout and | 1612 | This is useful when you use a panic=... timeout and |
| 1586 | need the box quickly up again. | 1613 | need the box quickly up again. |
| 1587 | 1614 | ||
| @@ -1805,10 +1832,17 @@ and is between 256 and 4096 characters. It is defined in the file | |||
| 1805 | perfmon on Intel CPUs instead of the | 1832 | perfmon on Intel CPUs instead of the |
| 1806 | CPU specific event set. | 1833 | CPU specific event set. |
| 1807 | 1834 | ||
| 1835 | oops=panic Always panic on oopses. Default is to just kill the | ||
| 1836 | process, but there is a small probability of | ||
| 1837 | deadlocking the machine. | ||
| 1838 | This will also cause panics on machine check exceptions. | ||
| 1839 | Useful together with panic=30 to trigger a reboot. | ||
| 1840 | |||
| 1808 | OSS [HW,OSS] | 1841 | OSS [HW,OSS] |
| 1809 | See Documentation/sound/oss/oss-parameters.txt | 1842 | See Documentation/sound/oss/oss-parameters.txt |
| 1810 | 1843 | ||
| 1811 | panic= [KNL] Kernel behaviour on panic | 1844 | panic= [KNL] Kernel behaviour on panic: delay <timeout> |
| 1845 | seconds before rebooting | ||
| 1812 | Format: <timeout> | 1846 | Format: <timeout> |
| 1813 | 1847 | ||
| 1814 | parkbd.port= [HW] Parallel port number the keyboard adapter is | 1848 | parkbd.port= [HW] Parallel port number the keyboard adapter is |
| @@ -2311,6 +2345,7 @@ and is between 256 and 4096 characters. It is defined in the file | |||
| 2311 | 2345 | ||
| 2312 | softlockup_panic= | 2346 | softlockup_panic= |
| 2313 | [KNL] Should the soft-lockup detector generate panics. | 2347 | [KNL] Should the soft-lockup detector generate panics. |
| 2348 | Format: <integer> | ||
| 2314 | 2349 | ||
| 2315 | sonypi.*= [HW] Sony Programmable I/O Control Device driver | 2350 | sonypi.*= [HW] Sony Programmable I/O Control Device driver |
| 2316 | See Documentation/sonypi.txt | 2351 | See Documentation/sonypi.txt |
| @@ -2436,11 +2471,15 @@ and is between 256 and 4096 characters. It is defined in the file | |||
| 2436 | <deci-seconds>: poll all this frequency | 2471 | <deci-seconds>: poll all this frequency |
| 2437 | 0: no polling (default) | 2472 | 0: no polling (default) |
| 2438 | 2473 | ||
| 2474 | threadirqs [KNL] | ||
| 2475 | Force threading of all interrupt handlers except those | ||
| 2476 | marked explicitely IRQF_NO_THREAD. | ||
| 2477 | |||
| 2439 | topology= [S390] | 2478 | topology= [S390] |
| 2440 | Format: {off | on} | 2479 | Format: {off | on} |
| 2441 | Specify if the kernel should make use of the cpu | 2480 | Specify if the kernel should make use of the cpu |
| 2442 | topology informations if the hardware supports these. | 2481 | topology information if the hardware supports this. |
| 2443 | The scheduler will make use of these informations and | 2482 | The scheduler will make use of this information and |
| 2444 | e.g. base its process migration decisions on it. | 2483 | e.g. base its process migration decisions on it. |
| 2445 | Default is on. | 2484 | Default is on. |
| 2446 | 2485 | ||
| @@ -2493,8 +2532,7 @@ and is between 256 and 4096 characters. It is defined in the file | |||
| 2493 | reported either. | 2532 | reported either. |
| 2494 | 2533 | ||
| 2495 | unknown_nmi_panic | 2534 | unknown_nmi_panic |
| 2496 | [X86] | 2535 | [X86] Cause panic on unknown NMI. |
| 2497 | Set unknown_nmi_panic=1 early on boot. | ||
| 2498 | 2536 | ||
| 2499 | usbcore.autosuspend= | 2537 | usbcore.autosuspend= |
| 2500 | [USB] The autosuspend time delay (in seconds) used | 2538 | [USB] The autosuspend time delay (in seconds) used |
diff --git a/Documentation/keys-request-key.txt b/Documentation/keys-request-key.txt index 09b55e461740..69686ad12c66 100644 --- a/Documentation/keys-request-key.txt +++ b/Documentation/keys-request-key.txt | |||
| @@ -127,14 +127,15 @@ This is because process A's keyrings can't simply be attached to | |||
| 127 | of them, and (b) it requires the same UID/GID/Groups all the way through. | 127 | of them, and (b) it requires the same UID/GID/Groups all the way through. |
| 128 | 128 | ||
| 129 | 129 | ||
| 130 | ====================== | 130 | ==================================== |
| 131 | NEGATIVE INSTANTIATION | 131 | NEGATIVE INSTANTIATION AND REJECTION |
| 132 | ====================== | 132 | ==================================== |
| 133 | 133 | ||
| 134 | Rather than instantiating a key, it is possible for the possessor of an | 134 | Rather than instantiating a key, it is possible for the possessor of an |
| 135 | authorisation key to negatively instantiate a key that's under construction. | 135 | authorisation key to negatively instantiate a key that's under construction. |
| 136 | This is a short duration placeholder that causes any attempt at re-requesting | 136 | This is a short duration placeholder that causes any attempt at re-requesting |
| 137 | the key whilst it exists to fail with error ENOKEY. | 137 | the key whilst it exists to fail with error ENOKEY if negated or the specified |
| 138 | error if rejected. | ||
| 138 | 139 | ||
| 139 | This is provided to prevent excessive repeated spawning of /sbin/request-key | 140 | This is provided to prevent excessive repeated spawning of /sbin/request-key |
| 140 | processes for a key that will never be obtainable. | 141 | processes for a key that will never be obtainable. |
diff --git a/Documentation/keys.txt b/Documentation/keys.txt index e4dbbdb1bd96..6523a9e6f293 100644 --- a/Documentation/keys.txt +++ b/Documentation/keys.txt | |||
| @@ -637,6 +637,9 @@ The keyctl syscall functions are: | |||
| 637 | long keyctl(KEYCTL_INSTANTIATE, key_serial_t key, | 637 | long keyctl(KEYCTL_INSTANTIATE, key_serial_t key, |
| 638 | const void *payload, size_t plen, | 638 | const void *payload, size_t plen, |
| 639 | key_serial_t keyring); | 639 | key_serial_t keyring); |
| 640 | long keyctl(KEYCTL_INSTANTIATE_IOV, key_serial_t key, | ||
| 641 | const struct iovec *payload_iov, unsigned ioc, | ||
| 642 | key_serial_t keyring); | ||
| 640 | 643 | ||
| 641 | If the kernel calls back to userspace to complete the instantiation of a | 644 | If the kernel calls back to userspace to complete the instantiation of a |
| 642 | key, userspace should use this call to supply data for the key before the | 645 | key, userspace should use this call to supply data for the key before the |
| @@ -652,11 +655,16 @@ The keyctl syscall functions are: | |||
| 652 | 655 | ||
| 653 | The payload and plen arguments describe the payload data as for add_key(). | 656 | The payload and plen arguments describe the payload data as for add_key(). |
| 654 | 657 | ||
| 658 | The payload_iov and ioc arguments describe the payload data in an iovec | ||
| 659 | array instead of a single buffer. | ||
| 660 | |||
| 655 | 661 | ||
| 656 | (*) Negatively instantiate a partially constructed key. | 662 | (*) Negatively instantiate a partially constructed key. |
| 657 | 663 | ||
| 658 | long keyctl(KEYCTL_NEGATE, key_serial_t key, | 664 | long keyctl(KEYCTL_NEGATE, key_serial_t key, |
| 659 | unsigned timeout, key_serial_t keyring); | 665 | unsigned timeout, key_serial_t keyring); |
| 666 | long keyctl(KEYCTL_REJECT, key_serial_t key, | ||
| 667 | unsigned timeout, unsigned error, key_serial_t keyring); | ||
| 660 | 668 | ||
| 661 | If the kernel calls back to userspace to complete the instantiation of a | 669 | If the kernel calls back to userspace to complete the instantiation of a |
| 662 | key, userspace should use this call mark the key as negative before the | 670 | key, userspace should use this call mark the key as negative before the |
| @@ -669,6 +677,10 @@ The keyctl syscall functions are: | |||
| 669 | that keyring, however all the constraints applying in KEYCTL_LINK apply in | 677 | that keyring, however all the constraints applying in KEYCTL_LINK apply in |
| 670 | this case too. | 678 | this case too. |
| 671 | 679 | ||
| 680 | If the key is rejected, future searches for it will return the specified | ||
| 681 | error code until the rejected key expires. Negating the key is the same | ||
| 682 | as rejecting the key with ENOKEY as the error code. | ||
| 683 | |||
| 672 | 684 | ||
| 673 | (*) Set the default request-key destination keyring. | 685 | (*) Set the default request-key destination keyring. |
| 674 | 686 | ||
| @@ -1062,6 +1074,13 @@ The structure has a number of fields, some of which are mandatory: | |||
| 1062 | viable. | 1074 | viable. |
| 1063 | 1075 | ||
| 1064 | 1076 | ||
| 1077 | (*) int (*vet_description)(const char *description); | ||
| 1078 | |||
| 1079 | This optional method is called to vet a key description. If the key type | ||
| 1080 | doesn't approve of the key description, it may return an error, otherwise | ||
| 1081 | it should return 0. | ||
| 1082 | |||
| 1083 | |||
| 1065 | (*) int (*instantiate)(struct key *key, const void *data, size_t datalen); | 1084 | (*) int (*instantiate)(struct key *key, const void *data, size_t datalen); |
| 1066 | 1085 | ||
| 1067 | This method is called to attach a payload to a key during construction. | 1086 | This method is called to attach a payload to a key during construction. |
| @@ -1231,10 +1250,11 @@ hand the request off to (perhaps a path held in placed in another key by, for | |||
| 1231 | example, the KDE desktop manager). | 1250 | example, the KDE desktop manager). |
| 1232 | 1251 | ||
| 1233 | The program (or whatever it calls) should finish construction of the key by | 1252 | The program (or whatever it calls) should finish construction of the key by |
| 1234 | calling KEYCTL_INSTANTIATE, which also permits it to cache the key in one of | 1253 | calling KEYCTL_INSTANTIATE or KEYCTL_INSTANTIATE_IOV, which also permits it to |
| 1235 | the keyrings (probably the session ring) before returning. Alternatively, the | 1254 | cache the key in one of the keyrings (probably the session ring) before |
| 1236 | key can be marked as negative with KEYCTL_NEGATE; this also permits the key to | 1255 | returning. Alternatively, the key can be marked as negative with KEYCTL_NEGATE |
| 1237 | be cached in one of the keyrings. | 1256 | or KEYCTL_REJECT; this also permits the key to be cached in one of the |
| 1257 | keyrings. | ||
| 1238 | 1258 | ||
| 1239 | If it returns with the key remaining in the unconstructed state, the key will | 1259 | If it returns with the key remaining in the unconstructed state, the key will |
| 1240 | be marked as being negative, it will be added to the session keyring, and an | 1260 | be marked as being negative, it will be added to the session keyring, and an |
diff --git a/Documentation/kmemleak.txt b/Documentation/kmemleak.txt index 34f6638aa5ac..090e6ee04536 100644 --- a/Documentation/kmemleak.txt +++ b/Documentation/kmemleak.txt | |||
| @@ -11,6 +11,7 @@ with the difference that the orphan objects are not freed but only | |||
| 11 | reported via /sys/kernel/debug/kmemleak. A similar method is used by the | 11 | reported via /sys/kernel/debug/kmemleak. A similar method is used by the |
| 12 | Valgrind tool (memcheck --leak-check) to detect the memory leaks in | 12 | Valgrind tool (memcheck --leak-check) to detect the memory leaks in |
| 13 | user-space applications. | 13 | user-space applications. |
| 14 | Kmemleak is supported on x86, arm, powerpc, sparc, sh, microblaze and tile. | ||
| 14 | 15 | ||
| 15 | Usage | 16 | Usage |
| 16 | ----- | 17 | ----- |
| @@ -178,5 +179,4 @@ block doesn't need to be freed (some cases in the init_call functions), | |||
| 178 | the pointer is calculated by other methods than the usual container_of | 179 | the pointer is calculated by other methods than the usual container_of |
| 179 | macro or the pointer is stored in a location not scanned by kmemleak. | 180 | macro or the pointer is stored in a location not scanned by kmemleak. |
| 180 | 181 | ||
| 181 | Page allocations and ioremap are not tracked. Only the ARM and x86 | 182 | Page allocations and ioremap are not tracked. |
| 182 | architectures are currently supported. | ||
diff --git a/Documentation/kref.txt b/Documentation/kref.txt index ae203f91ee9b..48ba715d5a63 100644 --- a/Documentation/kref.txt +++ b/Documentation/kref.txt | |||
| @@ -156,7 +156,7 @@ static struct my_data *get_entry() | |||
| 156 | struct my_data *entry = NULL; | 156 | struct my_data *entry = NULL; |
| 157 | mutex_lock(&mutex); | 157 | mutex_lock(&mutex); |
| 158 | if (!list_empty(&q)) { | 158 | if (!list_empty(&q)) { |
| 159 | entry = container_of(q.next, struct my_q_entry, link); | 159 | entry = container_of(q.next, struct my_data, link); |
| 160 | kref_get(&entry->refcount); | 160 | kref_get(&entry->refcount); |
| 161 | } | 161 | } |
| 162 | mutex_unlock(&mutex); | 162 | mutex_unlock(&mutex); |
diff --git a/Documentation/kvm/api.txt b/Documentation/kvm/api.txt index ad85797c1cf0..9bef4e4cec50 100644 --- a/Documentation/kvm/api.txt +++ b/Documentation/kvm/api.txt | |||
| @@ -166,7 +166,7 @@ Returns: 0 on success, -1 on error | |||
| 166 | 166 | ||
| 167 | This ioctl is obsolete and has been removed. | 167 | This ioctl is obsolete and has been removed. |
| 168 | 168 | ||
| 169 | 4.6 KVM_CREATE_VCPU | 169 | 4.7 KVM_CREATE_VCPU |
| 170 | 170 | ||
| 171 | Capability: basic | 171 | Capability: basic |
| 172 | Architectures: all | 172 | Architectures: all |
| @@ -177,7 +177,7 @@ Returns: vcpu fd on success, -1 on error | |||
| 177 | This API adds a vcpu to a virtual machine. The vcpu id is a small integer | 177 | This API adds a vcpu to a virtual machine. The vcpu id is a small integer |
| 178 | in the range [0, max_vcpus). | 178 | in the range [0, max_vcpus). |
| 179 | 179 | ||
| 180 | 4.7 KVM_GET_DIRTY_LOG (vm ioctl) | 180 | 4.8 KVM_GET_DIRTY_LOG (vm ioctl) |
| 181 | 181 | ||
| 182 | Capability: basic | 182 | Capability: basic |
| 183 | Architectures: x86 | 183 | Architectures: x86 |
| @@ -200,7 +200,7 @@ since the last call to this ioctl. Bit 0 is the first page in the | |||
| 200 | memory slot. Ensure the entire structure is cleared to avoid padding | 200 | memory slot. Ensure the entire structure is cleared to avoid padding |
| 201 | issues. | 201 | issues. |
| 202 | 202 | ||
| 203 | 4.8 KVM_SET_MEMORY_ALIAS | 203 | 4.9 KVM_SET_MEMORY_ALIAS |
| 204 | 204 | ||
| 205 | Capability: basic | 205 | Capability: basic |
| 206 | Architectures: x86 | 206 | Architectures: x86 |
| @@ -210,7 +210,7 @@ Returns: 0 (success), -1 (error) | |||
| 210 | 210 | ||
| 211 | This ioctl is obsolete and has been removed. | 211 | This ioctl is obsolete and has been removed. |
| 212 | 212 | ||
| 213 | 4.9 KVM_RUN | 213 | 4.10 KVM_RUN |
| 214 | 214 | ||
| 215 | Capability: basic | 215 | Capability: basic |
| 216 | Architectures: all | 216 | Architectures: all |
| @@ -226,7 +226,7 @@ obtained by mmap()ing the vcpu fd at offset 0, with the size given by | |||
| 226 | KVM_GET_VCPU_MMAP_SIZE. The parameter block is formatted as a 'struct | 226 | KVM_GET_VCPU_MMAP_SIZE. The parameter block is formatted as a 'struct |
| 227 | kvm_run' (see below). | 227 | kvm_run' (see below). |
| 228 | 228 | ||
| 229 | 4.10 KVM_GET_REGS | 229 | 4.11 KVM_GET_REGS |
| 230 | 230 | ||
| 231 | Capability: basic | 231 | Capability: basic |
| 232 | Architectures: all | 232 | Architectures: all |
| @@ -246,7 +246,7 @@ struct kvm_regs { | |||
| 246 | __u64 rip, rflags; | 246 | __u64 rip, rflags; |
| 247 | }; | 247 | }; |
| 248 | 248 | ||
| 249 | 4.11 KVM_SET_REGS | 249 | 4.12 KVM_SET_REGS |
| 250 | 250 | ||
| 251 | Capability: basic | 251 | Capability: basic |
| 252 | Architectures: all | 252 | Architectures: all |
| @@ -258,7 +258,7 @@ Writes the general purpose registers into the vcpu. | |||
| 258 | 258 | ||
| 259 | See KVM_GET_REGS for the data structure. | 259 | See KVM_GET_REGS for the data structure. |
| 260 | 260 | ||
| 261 | 4.12 KVM_GET_SREGS | 261 | 4.13 KVM_GET_SREGS |
| 262 | 262 | ||
| 263 | Capability: basic | 263 | Capability: basic |
| 264 | Architectures: x86 | 264 | Architectures: x86 |
| @@ -283,7 +283,7 @@ interrupt_bitmap is a bitmap of pending external interrupts. At most | |||
| 283 | one bit may be set. This interrupt has been acknowledged by the APIC | 283 | one bit may be set. This interrupt has been acknowledged by the APIC |
| 284 | but not yet injected into the cpu core. | 284 | but not yet injected into the cpu core. |
| 285 | 285 | ||
| 286 | 4.13 KVM_SET_SREGS | 286 | 4.14 KVM_SET_SREGS |
| 287 | 287 | ||
| 288 | Capability: basic | 288 | Capability: basic |
| 289 | Architectures: x86 | 289 | Architectures: x86 |
| @@ -294,7 +294,7 @@ Returns: 0 on success, -1 on error | |||
| 294 | Writes special registers into the vcpu. See KVM_GET_SREGS for the | 294 | Writes special registers into the vcpu. See KVM_GET_SREGS for the |
| 295 | data structures. | 295 | data structures. |
| 296 | 296 | ||
| 297 | 4.14 KVM_TRANSLATE | 297 | 4.15 KVM_TRANSLATE |
| 298 | 298 | ||
| 299 | Capability: basic | 299 | Capability: basic |
| 300 | Architectures: x86 | 300 | Architectures: x86 |
| @@ -317,7 +317,7 @@ struct kvm_translation { | |||
| 317 | __u8 pad[5]; | 317 | __u8 pad[5]; |
| 318 | }; | 318 | }; |
| 319 | 319 | ||
| 320 | 4.15 KVM_INTERRUPT | 320 | 4.16 KVM_INTERRUPT |
| 321 | 321 | ||
| 322 | Capability: basic | 322 | Capability: basic |
| 323 | Architectures: x86, ppc | 323 | Architectures: x86, ppc |
| @@ -365,7 +365,7 @@ c) KVM_INTERRUPT_SET_LEVEL | |||
| 365 | Note that any value for 'irq' other than the ones stated above is invalid | 365 | Note that any value for 'irq' other than the ones stated above is invalid |
| 366 | and incurs unexpected behavior. | 366 | and incurs unexpected behavior. |
| 367 | 367 | ||
| 368 | 4.16 KVM_DEBUG_GUEST | 368 | 4.17 KVM_DEBUG_GUEST |
| 369 | 369 | ||
| 370 | Capability: basic | 370 | Capability: basic |
| 371 | Architectures: none | 371 | Architectures: none |
| @@ -375,7 +375,7 @@ Returns: -1 on error | |||
| 375 | 375 | ||
| 376 | Support for this has been removed. Use KVM_SET_GUEST_DEBUG instead. | 376 | Support for this has been removed. Use KVM_SET_GUEST_DEBUG instead. |
| 377 | 377 | ||
| 378 | 4.17 KVM_GET_MSRS | 378 | 4.18 KVM_GET_MSRS |
| 379 | 379 | ||
| 380 | Capability: basic | 380 | Capability: basic |
| 381 | Architectures: x86 | 381 | Architectures: x86 |
| @@ -403,7 +403,7 @@ Application code should set the 'nmsrs' member (which indicates the | |||
| 403 | size of the entries array) and the 'index' member of each array entry. | 403 | size of the entries array) and the 'index' member of each array entry. |
| 404 | kvm will fill in the 'data' member. | 404 | kvm will fill in the 'data' member. |
| 405 | 405 | ||
| 406 | 4.18 KVM_SET_MSRS | 406 | 4.19 KVM_SET_MSRS |
| 407 | 407 | ||
| 408 | Capability: basic | 408 | Capability: basic |
| 409 | Architectures: x86 | 409 | Architectures: x86 |
| @@ -418,7 +418,7 @@ Application code should set the 'nmsrs' member (which indicates the | |||
| 418 | size of the entries array), and the 'index' and 'data' members of each | 418 | size of the entries array), and the 'index' and 'data' members of each |
| 419 | array entry. | 419 | array entry. |
| 420 | 420 | ||
| 421 | 4.19 KVM_SET_CPUID | 421 | 4.20 KVM_SET_CPUID |
| 422 | 422 | ||
| 423 | Capability: basic | 423 | Capability: basic |
| 424 | Architectures: x86 | 424 | Architectures: x86 |
| @@ -446,7 +446,7 @@ struct kvm_cpuid { | |||
| 446 | struct kvm_cpuid_entry entries[0]; | 446 | struct kvm_cpuid_entry entries[0]; |
| 447 | }; | 447 | }; |
| 448 | 448 | ||
| 449 | 4.20 KVM_SET_SIGNAL_MASK | 449 | 4.21 KVM_SET_SIGNAL_MASK |
| 450 | 450 | ||
| 451 | Capability: basic | 451 | Capability: basic |
| 452 | Architectures: x86 | 452 | Architectures: x86 |
| @@ -468,7 +468,7 @@ struct kvm_signal_mask { | |||
| 468 | __u8 sigset[0]; | 468 | __u8 sigset[0]; |
| 469 | }; | 469 | }; |
| 470 | 470 | ||
| 471 | 4.21 KVM_GET_FPU | 471 | 4.22 KVM_GET_FPU |
| 472 | 472 | ||
| 473 | Capability: basic | 473 | Capability: basic |
| 474 | Architectures: x86 | 474 | Architectures: x86 |
| @@ -493,7 +493,7 @@ struct kvm_fpu { | |||
| 493 | __u32 pad2; | 493 | __u32 pad2; |
| 494 | }; | 494 | }; |
| 495 | 495 | ||
| 496 | 4.22 KVM_SET_FPU | 496 | 4.23 KVM_SET_FPU |
| 497 | 497 | ||
| 498 | Capability: basic | 498 | Capability: basic |
| 499 | Architectures: x86 | 499 | Architectures: x86 |
| @@ -518,7 +518,7 @@ struct kvm_fpu { | |||
| 518 | __u32 pad2; | 518 | __u32 pad2; |
| 519 | }; | 519 | }; |
| 520 | 520 | ||
| 521 | 4.23 KVM_CREATE_IRQCHIP | 521 | 4.24 KVM_CREATE_IRQCHIP |
| 522 | 522 | ||
| 523 | Capability: KVM_CAP_IRQCHIP | 523 | Capability: KVM_CAP_IRQCHIP |
| 524 | Architectures: x86, ia64 | 524 | Architectures: x86, ia64 |
| @@ -531,7 +531,7 @@ ioapic, a virtual PIC (two PICs, nested), and sets up future vcpus to have a | |||
| 531 | local APIC. IRQ routing for GSIs 0-15 is set to both PIC and IOAPIC; GSI 16-23 | 531 | local APIC. IRQ routing for GSIs 0-15 is set to both PIC and IOAPIC; GSI 16-23 |
| 532 | only go to the IOAPIC. On ia64, a IOSAPIC is created. | 532 | only go to the IOAPIC. On ia64, a IOSAPIC is created. |
| 533 | 533 | ||
| 534 | 4.24 KVM_IRQ_LINE | 534 | 4.25 KVM_IRQ_LINE |
| 535 | 535 | ||
| 536 | Capability: KVM_CAP_IRQCHIP | 536 | Capability: KVM_CAP_IRQCHIP |
| 537 | Architectures: x86, ia64 | 537 | Architectures: x86, ia64 |
| @@ -552,7 +552,7 @@ struct kvm_irq_level { | |||
| 552 | __u32 level; /* 0 or 1 */ | 552 | __u32 level; /* 0 or 1 */ |
| 553 | }; | 553 | }; |
| 554 | 554 | ||
| 555 | 4.25 KVM_GET_IRQCHIP | 555 | 4.26 KVM_GET_IRQCHIP |
| 556 | 556 | ||
| 557 | Capability: KVM_CAP_IRQCHIP | 557 | Capability: KVM_CAP_IRQCHIP |
| 558 | Architectures: x86, ia64 | 558 | Architectures: x86, ia64 |
| @@ -573,7 +573,7 @@ struct kvm_irqchip { | |||
| 573 | } chip; | 573 | } chip; |
| 574 | }; | 574 | }; |
| 575 | 575 | ||
| 576 | 4.26 KVM_SET_IRQCHIP | 576 | 4.27 KVM_SET_IRQCHIP |
| 577 | 577 | ||
| 578 | Capability: KVM_CAP_IRQCHIP | 578 | Capability: KVM_CAP_IRQCHIP |
| 579 | Architectures: x86, ia64 | 579 | Architectures: x86, ia64 |
| @@ -594,7 +594,7 @@ struct kvm_irqchip { | |||
| 594 | } chip; | 594 | } chip; |
| 595 | }; | 595 | }; |
| 596 | 596 | ||
| 597 | 4.27 KVM_XEN_HVM_CONFIG | 597 | 4.28 KVM_XEN_HVM_CONFIG |
| 598 | 598 | ||
| 599 | Capability: KVM_CAP_XEN_HVM | 599 | Capability: KVM_CAP_XEN_HVM |
| 600 | Architectures: x86 | 600 | Architectures: x86 |
| @@ -618,7 +618,7 @@ struct kvm_xen_hvm_config { | |||
| 618 | __u8 pad2[30]; | 618 | __u8 pad2[30]; |
| 619 | }; | 619 | }; |
| 620 | 620 | ||
| 621 | 4.27 KVM_GET_CLOCK | 621 | 4.29 KVM_GET_CLOCK |
| 622 | 622 | ||
| 623 | Capability: KVM_CAP_ADJUST_CLOCK | 623 | Capability: KVM_CAP_ADJUST_CLOCK |
| 624 | Architectures: x86 | 624 | Architectures: x86 |
| @@ -636,7 +636,7 @@ struct kvm_clock_data { | |||
| 636 | __u32 pad[9]; | 636 | __u32 pad[9]; |
| 637 | }; | 637 | }; |
| 638 | 638 | ||
| 639 | 4.28 KVM_SET_CLOCK | 639 | 4.30 KVM_SET_CLOCK |
| 640 | 640 | ||
| 641 | Capability: KVM_CAP_ADJUST_CLOCK | 641 | Capability: KVM_CAP_ADJUST_CLOCK |
| 642 | Architectures: x86 | 642 | Architectures: x86 |
| @@ -654,7 +654,7 @@ struct kvm_clock_data { | |||
| 654 | __u32 pad[9]; | 654 | __u32 pad[9]; |
| 655 | }; | 655 | }; |
| 656 | 656 | ||
| 657 | 4.29 KVM_GET_VCPU_EVENTS | 657 | 4.31 KVM_GET_VCPU_EVENTS |
| 658 | 658 | ||
| 659 | Capability: KVM_CAP_VCPU_EVENTS | 659 | Capability: KVM_CAP_VCPU_EVENTS |
| 660 | Extended by: KVM_CAP_INTR_SHADOW | 660 | Extended by: KVM_CAP_INTR_SHADOW |
| @@ -693,7 +693,7 @@ struct kvm_vcpu_events { | |||
| 693 | KVM_VCPUEVENT_VALID_SHADOW may be set in the flags field to signal that | 693 | KVM_VCPUEVENT_VALID_SHADOW may be set in the flags field to signal that |
| 694 | interrupt.shadow contains a valid state. Otherwise, this field is undefined. | 694 | interrupt.shadow contains a valid state. Otherwise, this field is undefined. |
| 695 | 695 | ||
| 696 | 4.30 KVM_SET_VCPU_EVENTS | 696 | 4.32 KVM_SET_VCPU_EVENTS |
| 697 | 697 | ||
| 698 | Capability: KVM_CAP_VCPU_EVENTS | 698 | Capability: KVM_CAP_VCPU_EVENTS |
| 699 | Extended by: KVM_CAP_INTR_SHADOW | 699 | Extended by: KVM_CAP_INTR_SHADOW |
| @@ -719,7 +719,7 @@ If KVM_CAP_INTR_SHADOW is available, KVM_VCPUEVENT_VALID_SHADOW can be set in | |||
| 719 | the flags field to signal that interrupt.shadow contains a valid state and | 719 | the flags field to signal that interrupt.shadow contains a valid state and |
| 720 | shall be written into the VCPU. | 720 | shall be written into the VCPU. |
| 721 | 721 | ||
| 722 | 4.32 KVM_GET_DEBUGREGS | 722 | 4.33 KVM_GET_DEBUGREGS |
| 723 | 723 | ||
| 724 | Capability: KVM_CAP_DEBUGREGS | 724 | Capability: KVM_CAP_DEBUGREGS |
| 725 | Architectures: x86 | 725 | Architectures: x86 |
| @@ -737,7 +737,7 @@ struct kvm_debugregs { | |||
| 737 | __u64 reserved[9]; | 737 | __u64 reserved[9]; |
| 738 | }; | 738 | }; |
| 739 | 739 | ||
| 740 | 4.33 KVM_SET_DEBUGREGS | 740 | 4.34 KVM_SET_DEBUGREGS |
| 741 | 741 | ||
| 742 | Capability: KVM_CAP_DEBUGREGS | 742 | Capability: KVM_CAP_DEBUGREGS |
| 743 | Architectures: x86 | 743 | Architectures: x86 |
| @@ -750,7 +750,7 @@ Writes debug registers into the vcpu. | |||
| 750 | See KVM_GET_DEBUGREGS for the data structure. The flags field is unused | 750 | See KVM_GET_DEBUGREGS for the data structure. The flags field is unused |
| 751 | yet and must be cleared on entry. | 751 | yet and must be cleared on entry. |
| 752 | 752 | ||
| 753 | 4.34 KVM_SET_USER_MEMORY_REGION | 753 | 4.35 KVM_SET_USER_MEMORY_REGION |
| 754 | 754 | ||
| 755 | Capability: KVM_CAP_USER_MEM | 755 | Capability: KVM_CAP_USER_MEM |
| 756 | Architectures: all | 756 | Architectures: all |
| @@ -796,7 +796,7 @@ It is recommended to use this API instead of the KVM_SET_MEMORY_REGION ioctl. | |||
| 796 | The KVM_SET_MEMORY_REGION does not allow fine grained control over memory | 796 | The KVM_SET_MEMORY_REGION does not allow fine grained control over memory |
| 797 | allocation and is deprecated. | 797 | allocation and is deprecated. |
| 798 | 798 | ||
| 799 | 4.35 KVM_SET_TSS_ADDR | 799 | 4.36 KVM_SET_TSS_ADDR |
| 800 | 800 | ||
| 801 | Capability: KVM_CAP_SET_TSS_ADDR | 801 | Capability: KVM_CAP_SET_TSS_ADDR |
| 802 | Architectures: x86 | 802 | Architectures: x86 |
| @@ -814,7 +814,7 @@ This ioctl is required on Intel-based hosts. This is needed on Intel hardware | |||
| 814 | because of a quirk in the virtualization implementation (see the internals | 814 | because of a quirk in the virtualization implementation (see the internals |
| 815 | documentation when it pops into existence). | 815 | documentation when it pops into existence). |
| 816 | 816 | ||
| 817 | 4.36 KVM_ENABLE_CAP | 817 | 4.37 KVM_ENABLE_CAP |
| 818 | 818 | ||
| 819 | Capability: KVM_CAP_ENABLE_CAP | 819 | Capability: KVM_CAP_ENABLE_CAP |
| 820 | Architectures: ppc | 820 | Architectures: ppc |
| @@ -849,7 +849,7 @@ function properly, this is the place to put them. | |||
| 849 | __u8 pad[64]; | 849 | __u8 pad[64]; |
| 850 | }; | 850 | }; |
| 851 | 851 | ||
| 852 | 4.37 KVM_GET_MP_STATE | 852 | 4.38 KVM_GET_MP_STATE |
| 853 | 853 | ||
| 854 | Capability: KVM_CAP_MP_STATE | 854 | Capability: KVM_CAP_MP_STATE |
| 855 | Architectures: x86, ia64 | 855 | Architectures: x86, ia64 |
| @@ -879,7 +879,7 @@ Possible values are: | |||
| 879 | This ioctl is only useful after KVM_CREATE_IRQCHIP. Without an in-kernel | 879 | This ioctl is only useful after KVM_CREATE_IRQCHIP. Without an in-kernel |
| 880 | irqchip, the multiprocessing state must be maintained by userspace. | 880 | irqchip, the multiprocessing state must be maintained by userspace. |
| 881 | 881 | ||
| 882 | 4.38 KVM_SET_MP_STATE | 882 | 4.39 KVM_SET_MP_STATE |
| 883 | 883 | ||
| 884 | Capability: KVM_CAP_MP_STATE | 884 | Capability: KVM_CAP_MP_STATE |
| 885 | Architectures: x86, ia64 | 885 | Architectures: x86, ia64 |
| @@ -893,7 +893,7 @@ arguments. | |||
| 893 | This ioctl is only useful after KVM_CREATE_IRQCHIP. Without an in-kernel | 893 | This ioctl is only useful after KVM_CREATE_IRQCHIP. Without an in-kernel |
| 894 | irqchip, the multiprocessing state must be maintained by userspace. | 894 | irqchip, the multiprocessing state must be maintained by userspace. |
| 895 | 895 | ||
| 896 | 4.39 KVM_SET_IDENTITY_MAP_ADDR | 896 | 4.40 KVM_SET_IDENTITY_MAP_ADDR |
| 897 | 897 | ||
| 898 | Capability: KVM_CAP_SET_IDENTITY_MAP_ADDR | 898 | Capability: KVM_CAP_SET_IDENTITY_MAP_ADDR |
| 899 | Architectures: x86 | 899 | Architectures: x86 |
| @@ -911,7 +911,7 @@ This ioctl is required on Intel-based hosts. This is needed on Intel hardware | |||
| 911 | because of a quirk in the virtualization implementation (see the internals | 911 | because of a quirk in the virtualization implementation (see the internals |
| 912 | documentation when it pops into existence). | 912 | documentation when it pops into existence). |
| 913 | 913 | ||
| 914 | 4.40 KVM_SET_BOOT_CPU_ID | 914 | 4.41 KVM_SET_BOOT_CPU_ID |
| 915 | 915 | ||
| 916 | Capability: KVM_CAP_SET_BOOT_CPU_ID | 916 | Capability: KVM_CAP_SET_BOOT_CPU_ID |
| 917 | Architectures: x86, ia64 | 917 | Architectures: x86, ia64 |
| @@ -923,7 +923,7 @@ Define which vcpu is the Bootstrap Processor (BSP). Values are the same | |||
| 923 | as the vcpu id in KVM_CREATE_VCPU. If this ioctl is not called, the default | 923 | as the vcpu id in KVM_CREATE_VCPU. If this ioctl is not called, the default |
| 924 | is vcpu 0. | 924 | is vcpu 0. |
| 925 | 925 | ||
| 926 | 4.41 KVM_GET_XSAVE | 926 | 4.42 KVM_GET_XSAVE |
| 927 | 927 | ||
| 928 | Capability: KVM_CAP_XSAVE | 928 | Capability: KVM_CAP_XSAVE |
| 929 | Architectures: x86 | 929 | Architectures: x86 |
| @@ -937,7 +937,7 @@ struct kvm_xsave { | |||
| 937 | 937 | ||
| 938 | This ioctl would copy current vcpu's xsave struct to the userspace. | 938 | This ioctl would copy current vcpu's xsave struct to the userspace. |
| 939 | 939 | ||
| 940 | 4.42 KVM_SET_XSAVE | 940 | 4.43 KVM_SET_XSAVE |
| 941 | 941 | ||
| 942 | Capability: KVM_CAP_XSAVE | 942 | Capability: KVM_CAP_XSAVE |
| 943 | Architectures: x86 | 943 | Architectures: x86 |
| @@ -951,7 +951,7 @@ struct kvm_xsave { | |||
| 951 | 951 | ||
| 952 | This ioctl would copy userspace's xsave struct to the kernel. | 952 | This ioctl would copy userspace's xsave struct to the kernel. |
| 953 | 953 | ||
| 954 | 4.43 KVM_GET_XCRS | 954 | 4.44 KVM_GET_XCRS |
| 955 | 955 | ||
| 956 | Capability: KVM_CAP_XCRS | 956 | Capability: KVM_CAP_XCRS |
| 957 | Architectures: x86 | 957 | Architectures: x86 |
| @@ -974,7 +974,7 @@ struct kvm_xcrs { | |||
| 974 | 974 | ||
| 975 | This ioctl would copy current vcpu's xcrs to the userspace. | 975 | This ioctl would copy current vcpu's xcrs to the userspace. |
| 976 | 976 | ||
| 977 | 4.44 KVM_SET_XCRS | 977 | 4.45 KVM_SET_XCRS |
| 978 | 978 | ||
| 979 | Capability: KVM_CAP_XCRS | 979 | Capability: KVM_CAP_XCRS |
| 980 | Architectures: x86 | 980 | Architectures: x86 |
| @@ -997,7 +997,7 @@ struct kvm_xcrs { | |||
| 997 | 997 | ||
| 998 | This ioctl would set vcpu's xcr to the value userspace specified. | 998 | This ioctl would set vcpu's xcr to the value userspace specified. |
| 999 | 999 | ||
| 1000 | 4.45 KVM_GET_SUPPORTED_CPUID | 1000 | 4.46 KVM_GET_SUPPORTED_CPUID |
| 1001 | 1001 | ||
| 1002 | Capability: KVM_CAP_EXT_CPUID | 1002 | Capability: KVM_CAP_EXT_CPUID |
| 1003 | Architectures: x86 | 1003 | Architectures: x86 |
| @@ -1062,7 +1062,7 @@ emulate them efficiently. The fields in each entry are defined as follows: | |||
| 1062 | eax, ebx, ecx, edx: the values returned by the cpuid instruction for | 1062 | eax, ebx, ecx, edx: the values returned by the cpuid instruction for |
| 1063 | this function/index combination | 1063 | this function/index combination |
| 1064 | 1064 | ||
| 1065 | 4.46 KVM_PPC_GET_PVINFO | 1065 | 4.47 KVM_PPC_GET_PVINFO |
| 1066 | 1066 | ||
| 1067 | Capability: KVM_CAP_PPC_GET_PVINFO | 1067 | Capability: KVM_CAP_PPC_GET_PVINFO |
| 1068 | Architectures: ppc | 1068 | Architectures: ppc |
| @@ -1085,7 +1085,7 @@ of 4 instructions that make up a hypercall. | |||
| 1085 | If any additional field gets added to this structure later on, a bit for that | 1085 | If any additional field gets added to this structure later on, a bit for that |
| 1086 | additional piece of information will be set in the flags bitmap. | 1086 | additional piece of information will be set in the flags bitmap. |
| 1087 | 1087 | ||
| 1088 | 4.47 KVM_ASSIGN_PCI_DEVICE | 1088 | 4.48 KVM_ASSIGN_PCI_DEVICE |
| 1089 | 1089 | ||
| 1090 | Capability: KVM_CAP_DEVICE_ASSIGNMENT | 1090 | Capability: KVM_CAP_DEVICE_ASSIGNMENT |
| 1091 | Architectures: x86 ia64 | 1091 | Architectures: x86 ia64 |
| @@ -1113,7 +1113,7 @@ following flags are specified: | |||
| 1113 | /* Depends on KVM_CAP_IOMMU */ | 1113 | /* Depends on KVM_CAP_IOMMU */ |
| 1114 | #define KVM_DEV_ASSIGN_ENABLE_IOMMU (1 << 0) | 1114 | #define KVM_DEV_ASSIGN_ENABLE_IOMMU (1 << 0) |
| 1115 | 1115 | ||
| 1116 | 4.48 KVM_DEASSIGN_PCI_DEVICE | 1116 | 4.49 KVM_DEASSIGN_PCI_DEVICE |
| 1117 | 1117 | ||
| 1118 | Capability: KVM_CAP_DEVICE_DEASSIGNMENT | 1118 | Capability: KVM_CAP_DEVICE_DEASSIGNMENT |
| 1119 | Architectures: x86 ia64 | 1119 | Architectures: x86 ia64 |
| @@ -1126,7 +1126,7 @@ Ends PCI device assignment, releasing all associated resources. | |||
| 1126 | See KVM_CAP_DEVICE_ASSIGNMENT for the data structure. Only assigned_dev_id is | 1126 | See KVM_CAP_DEVICE_ASSIGNMENT for the data structure. Only assigned_dev_id is |
| 1127 | used in kvm_assigned_pci_dev to identify the device. | 1127 | used in kvm_assigned_pci_dev to identify the device. |
| 1128 | 1128 | ||
| 1129 | 4.49 KVM_ASSIGN_DEV_IRQ | 1129 | 4.50 KVM_ASSIGN_DEV_IRQ |
| 1130 | 1130 | ||
| 1131 | Capability: KVM_CAP_ASSIGN_DEV_IRQ | 1131 | Capability: KVM_CAP_ASSIGN_DEV_IRQ |
| 1132 | Architectures: x86 ia64 | 1132 | Architectures: x86 ia64 |
| @@ -1164,7 +1164,7 @@ The following flags are defined: | |||
| 1164 | It is not valid to specify multiple types per host or guest IRQ. However, the | 1164 | It is not valid to specify multiple types per host or guest IRQ. However, the |
| 1165 | IRQ type of host and guest can differ or can even be null. | 1165 | IRQ type of host and guest can differ or can even be null. |
| 1166 | 1166 | ||
| 1167 | 4.50 KVM_DEASSIGN_DEV_IRQ | 1167 | 4.51 KVM_DEASSIGN_DEV_IRQ |
| 1168 | 1168 | ||
| 1169 | Capability: KVM_CAP_ASSIGN_DEV_IRQ | 1169 | Capability: KVM_CAP_ASSIGN_DEV_IRQ |
| 1170 | Architectures: x86 ia64 | 1170 | Architectures: x86 ia64 |
| @@ -1178,7 +1178,7 @@ See KVM_ASSIGN_DEV_IRQ for the data structure. The target device is specified | |||
| 1178 | by assigned_dev_id, flags must correspond to the IRQ type specified on | 1178 | by assigned_dev_id, flags must correspond to the IRQ type specified on |
| 1179 | KVM_ASSIGN_DEV_IRQ. Partial deassignment of host or guest IRQ is allowed. | 1179 | KVM_ASSIGN_DEV_IRQ. Partial deassignment of host or guest IRQ is allowed. |
| 1180 | 1180 | ||
| 1181 | 4.51 KVM_SET_GSI_ROUTING | 1181 | 4.52 KVM_SET_GSI_ROUTING |
| 1182 | 1182 | ||
| 1183 | Capability: KVM_CAP_IRQ_ROUTING | 1183 | Capability: KVM_CAP_IRQ_ROUTING |
| 1184 | Architectures: x86 ia64 | 1184 | Architectures: x86 ia64 |
| @@ -1226,7 +1226,7 @@ struct kvm_irq_routing_msi { | |||
| 1226 | __u32 pad; | 1226 | __u32 pad; |
| 1227 | }; | 1227 | }; |
| 1228 | 1228 | ||
| 1229 | 4.52 KVM_ASSIGN_SET_MSIX_NR | 1229 | 4.53 KVM_ASSIGN_SET_MSIX_NR |
| 1230 | 1230 | ||
| 1231 | Capability: KVM_CAP_DEVICE_MSIX | 1231 | Capability: KVM_CAP_DEVICE_MSIX |
| 1232 | Architectures: x86 ia64 | 1232 | Architectures: x86 ia64 |
| @@ -1245,7 +1245,7 @@ struct kvm_assigned_msix_nr { | |||
| 1245 | 1245 | ||
| 1246 | #define KVM_MAX_MSIX_PER_DEV 256 | 1246 | #define KVM_MAX_MSIX_PER_DEV 256 |
| 1247 | 1247 | ||
| 1248 | 4.53 KVM_ASSIGN_SET_MSIX_ENTRY | 1248 | 4.54 KVM_ASSIGN_SET_MSIX_ENTRY |
| 1249 | 1249 | ||
| 1250 | Capability: KVM_CAP_DEVICE_MSIX | 1250 | Capability: KVM_CAP_DEVICE_MSIX |
| 1251 | Architectures: x86 ia64 | 1251 | Architectures: x86 ia64 |
diff --git a/Documentation/kvm/locking.txt b/Documentation/kvm/locking.txt new file mode 100644 index 000000000000..3b4cd3bf5631 --- /dev/null +++ b/Documentation/kvm/locking.txt | |||
| @@ -0,0 +1,25 @@ | |||
| 1 | KVM Lock Overview | ||
| 2 | ================= | ||
| 3 | |||
| 4 | 1. Acquisition Orders | ||
| 5 | --------------------- | ||
| 6 | |||
| 7 | (to be written) | ||
| 8 | |||
| 9 | 2. Reference | ||
| 10 | ------------ | ||
| 11 | |||
| 12 | Name: kvm_lock | ||
| 13 | Type: raw_spinlock | ||
| 14 | Arch: any | ||
| 15 | Protects: - vm_list | ||
| 16 | - hardware virtualization enable/disable | ||
| 17 | Comment: 'raw' because hardware enabling/disabling must be atomic /wrt | ||
| 18 | migration. | ||
| 19 | |||
| 20 | Name: kvm_arch::tsc_write_lock | ||
| 21 | Type: raw_spinlock | ||
| 22 | Arch: x86 | ||
| 23 | Protects: - kvm_arch::{last_tsc_write,last_tsc_nsec,last_tsc_offset} | ||
| 24 | - tsc offset in vmcb | ||
| 25 | Comment: 'raw' because updating the tsc offsets must not be preempted. | ||
diff --git a/Documentation/kvm/mmu.txt b/Documentation/kvm/mmu.txt index 142cc5136650..f46aa58389ca 100644 --- a/Documentation/kvm/mmu.txt +++ b/Documentation/kvm/mmu.txt | |||
| @@ -23,7 +23,7 @@ The mmu code attempts to satisfy the following requirements: | |||
| 23 | and framebuffer-based displays | 23 | and framebuffer-based displays |
| 24 | - footprint: keep the amount of pinned kernel memory low (most memory | 24 | - footprint: keep the amount of pinned kernel memory low (most memory |
| 25 | should be shrinkable) | 25 | should be shrinkable) |
| 26 | - reliablity: avoid multipage or GFP_ATOMIC allocations | 26 | - reliability: avoid multipage or GFP_ATOMIC allocations |
| 27 | 27 | ||
| 28 | Acronyms | 28 | Acronyms |
| 29 | ======== | 29 | ======== |
diff --git a/Documentation/kvm/ppc-pv.txt b/Documentation/kvm/ppc-pv.txt index a7f2244b3be9..3ab969c59046 100644 --- a/Documentation/kvm/ppc-pv.txt +++ b/Documentation/kvm/ppc-pv.txt | |||
| @@ -136,7 +136,7 @@ Patched instructions | |||
| 136 | ==================== | 136 | ==================== |
| 137 | 137 | ||
| 138 | The "ld" and "std" instructions are transormed to "lwz" and "stw" instructions | 138 | The "ld" and "std" instructions are transormed to "lwz" and "stw" instructions |
| 139 | respectively on 32 bit systems with an added offset of 4 to accomodate for big | 139 | respectively on 32 bit systems with an added offset of 4 to accommodate for big |
| 140 | endianness. | 140 | endianness. |
| 141 | 141 | ||
| 142 | The following is a list of mapping the Linux kernel performs when running as | 142 | The following is a list of mapping the Linux kernel performs when running as |
diff --git a/Documentation/kvm/timekeeping.txt b/Documentation/kvm/timekeeping.txt index 0c5033a58c9e..df8946377cb6 100644 --- a/Documentation/kvm/timekeeping.txt +++ b/Documentation/kvm/timekeeping.txt | |||
| @@ -81,7 +81,7 @@ Mode 0: Single Timeout. This is a one-shot software timeout that counts down | |||
| 81 | when the gate is high (always true for timers 0 and 1). When the count | 81 | when the gate is high (always true for timers 0 and 1). When the count |
| 82 | reaches zero, the output goes high. | 82 | reaches zero, the output goes high. |
| 83 | 83 | ||
| 84 | Mode 1: Triggered One-shot. The output is intially set high. When the gate | 84 | Mode 1: Triggered One-shot. The output is initially set high. When the gate |
| 85 | line is set high, a countdown is initiated (which does not stop if the gate is | 85 | line is set high, a countdown is initiated (which does not stop if the gate is |
| 86 | lowered), during which the output is set low. When the count reaches zero, | 86 | lowered), during which the output is set low. When the count reaches zero, |
| 87 | the output goes high. | 87 | the output goes high. |
diff --git a/Documentation/laptops/asus-laptop.txt b/Documentation/laptops/asus-laptop.txt index c1c5be84e4b1..803e51f6768b 100644 --- a/Documentation/laptops/asus-laptop.txt +++ b/Documentation/laptops/asus-laptop.txt | |||
| @@ -61,7 +61,7 @@ Usage | |||
| 61 | Hotkeys are also reported as input keys (like keyboards) you can check | 61 | Hotkeys are also reported as input keys (like keyboards) you can check |
| 62 | which key are supported using "xev" under X11. | 62 | which key are supported using "xev" under X11. |
| 63 | 63 | ||
| 64 | You can get informations on the version of your DSDT table by reading the | 64 | You can get information on the version of your DSDT table by reading the |
| 65 | /sys/devices/platform/asus-laptop/infos entry. If you have a question or a | 65 | /sys/devices/platform/asus-laptop/infos entry. If you have a question or a |
| 66 | bug report to do, please include the output of this entry. | 66 | bug report to do, please include the output of this entry. |
| 67 | 67 | ||
| @@ -178,7 +178,7 @@ LED display | |||
| 178 | ----------- | 178 | ----------- |
| 179 | 179 | ||
| 180 | Some models like the W1N have a LED display that can be used to display | 180 | Some models like the W1N have a LED display that can be used to display |
| 181 | several informations. | 181 | several items of information. |
| 182 | 182 | ||
| 183 | LED display works for the following models: | 183 | LED display works for the following models: |
| 184 | W1000N | 184 | W1000N |
diff --git a/Documentation/hwmon/hpfall.c b/Documentation/laptops/hpfall.c index a4a8fc5d05d4..a4a8fc5d05d4 100644 --- a/Documentation/hwmon/hpfall.c +++ b/Documentation/laptops/hpfall.c | |||
diff --git a/Documentation/laptops/sony-laptop.txt b/Documentation/laptops/sony-laptop.txt index 23ce7d350d1a..2bd4e82e5d9f 100644 --- a/Documentation/laptops/sony-laptop.txt +++ b/Documentation/laptops/sony-laptop.txt | |||
| @@ -14,7 +14,8 @@ Some models report hotkeys through the SNC or SPIC devices, such events are | |||
| 14 | reported both through the ACPI subsystem as acpi events and through the INPUT | 14 | reported both through the ACPI subsystem as acpi events and through the INPUT |
| 15 | subsystem. See the logs of acpid or /proc/acpi/event and | 15 | subsystem. See the logs of acpid or /proc/acpi/event and |
| 16 | /proc/bus/input/devices to find out what those events are and which input | 16 | /proc/bus/input/devices to find out what those events are and which input |
| 17 | devices are created by the driver. | 17 | devices are created by the driver. Additionally, loading the driver with the |
| 18 | debug option will report all events in the kernel log. | ||
| 18 | 19 | ||
| 19 | Backlight control: | 20 | Backlight control: |
| 20 | ------------------ | 21 | ------------------ |
| @@ -64,6 +65,16 @@ powers off the sound card, | |||
| 64 | # echo "1" > /sys/devices/platform/sony-laptop/audiopower | 65 | # echo "1" > /sys/devices/platform/sony-laptop/audiopower |
| 65 | powers on the sound card. | 66 | powers on the sound card. |
| 66 | 67 | ||
| 68 | |||
| 69 | RFkill control: | ||
| 70 | --------------- | ||
| 71 | More recent Vaio models expose a consistent set of ACPI methods to | ||
| 72 | control radio frequency emitting devices. If you are a lucky owner of | ||
| 73 | such a laptop you will find the necessary rfkill devices under | ||
| 74 | /sys/class/rfkill. Check those starting with sony-* in | ||
| 75 | # grep . /sys/class/rfkill/*/{state,name} | ||
| 76 | |||
| 77 | |||
| 67 | Development: | 78 | Development: |
| 68 | ------------ | 79 | ------------ |
| 69 | 80 | ||
| @@ -75,8 +86,21 @@ pass the option 'debug=1'. | |||
| 75 | REPEAT: DON'T DO THIS IF YOU DON'T LIKE RISKY BUSINESS. | 86 | REPEAT: DON'T DO THIS IF YOU DON'T LIKE RISKY BUSINESS. |
| 76 | 87 | ||
| 77 | In your kernel logs you will find the list of all ACPI methods | 88 | In your kernel logs you will find the list of all ACPI methods |
| 78 | the SNC device has on your laptop. You can see the GCDP/GCDP methods | 89 | the SNC device has on your laptop. |
| 79 | used to pwer on/off the CD drive, but there are others. | 90 | |
| 91 | * For new models you will see a long list of meaningless method names, | ||
| 92 | reading the DSDT table source should reveal that: | ||
| 93 | (1) the SNC device uses an internal capability lookup table | ||
| 94 | (2) SN00 is used to find values in the lookup table | ||
| 95 | (3) SN06 and SN07 are used to call into the real methods based on | ||
| 96 | offsets you can obtain iterating the table using SN00 | ||
| 97 | (4) SN02 used to enable events. | ||
| 98 | Some values in the capability lookup table are more or less known, see | ||
| 99 | the code for all sony_call_snc_handle calls, others are more obscure. | ||
| 100 | |||
| 101 | * For old models you can see the GCDP/GCDP methods used to pwer on/off | ||
| 102 | the CD drive, but there are others and they are usually different from | ||
| 103 | model to model. | ||
| 80 | 104 | ||
| 81 | I HAVE NO IDEA WHAT THOSE METHODS DO. | 105 | I HAVE NO IDEA WHAT THOSE METHODS DO. |
| 82 | 106 | ||
| @@ -108,9 +132,8 @@ Bugs/Limitations: | |||
| 108 | laptop, including permanent damage. | 132 | laptop, including permanent damage. |
| 109 | 133 | ||
| 110 | * The sony-laptop and sonypi drivers do not interact at all. In the | 134 | * The sony-laptop and sonypi drivers do not interact at all. In the |
| 111 | future, sonypi could use sony-laptop to do (part of) its business. | 135 | future, sonypi will be removed and replaced by sony-laptop. |
| 112 | 136 | ||
| 113 | * spicctrl, which is the userspace tool used to communicate with the | 137 | * spicctrl, which is the userspace tool used to communicate with the |
| 114 | sonypi driver (through /dev/sonypi) does not try to use the | 138 | sonypi driver (through /dev/sonypi) is deprecated as well since all |
| 115 | sony-laptop driver. In the future, spicctrl could try sonypi first, | 139 | its features are now available under the sysfs tree via sony-laptop. |
| 116 | and if it isn't present, try sony-laptop instead. | ||
diff --git a/Documentation/leds/00-INDEX b/Documentation/leds/00-INDEX new file mode 100644 index 000000000000..29f481df32c7 --- /dev/null +++ b/Documentation/leds/00-INDEX | |||
| @@ -0,0 +1,8 @@ | |||
| 1 | leds-class.txt | ||
| 2 | - documents LED handling under Linux. | ||
| 3 | leds-lp3944.txt | ||
| 4 | - notes on how to use the leds-lp3944 driver. | ||
| 5 | leds-lp5521.txt | ||
| 6 | - notes on how to use the leds-lp5521 driver. | ||
| 7 | leds-lp5523.txt | ||
| 8 | - notes on how to use the leds-lp5523 driver. | ||
diff --git a/Documentation/leds-class.txt b/Documentation/leds/leds-class.txt index 58b266bd1846..4996586e27e8 100644 --- a/Documentation/leds-class.txt +++ b/Documentation/leds/leds-class.txt | |||
| @@ -95,4 +95,3 @@ There are a number of cases where a trigger might only be mappable to a | |||
| 95 | particular LED (ACPI?). The addition of triggers provided by the LED driver | 95 | particular LED (ACPI?). The addition of triggers provided by the LED driver |
| 96 | should cover this option and be possible to add without breaking the | 96 | should cover this option and be possible to add without breaking the |
| 97 | current interface. | 97 | current interface. |
| 98 | |||
diff --git a/Documentation/leds-lp3944.txt b/Documentation/leds/leds-lp3944.txt index c6eda18b15ef..c6eda18b15ef 100644 --- a/Documentation/leds-lp3944.txt +++ b/Documentation/leds/leds-lp3944.txt | |||
diff --git a/Documentation/media-framework.txt b/Documentation/media-framework.txt new file mode 100644 index 000000000000..76a2087db205 --- /dev/null +++ b/Documentation/media-framework.txt | |||
| @@ -0,0 +1,353 @@ | |||
| 1 | Linux kernel media framework | ||
| 2 | ============================ | ||
| 3 | |||
| 4 | This document describes the Linux kernel media framework, its data structures, | ||
| 5 | functions and their usage. | ||
| 6 | |||
| 7 | |||
| 8 | Introduction | ||
| 9 | ------------ | ||
| 10 | |||
| 11 | The media controller API is documented in DocBook format in | ||
| 12 | Documentation/DocBook/v4l/media-controller.xml. This document will focus on | ||
| 13 | the kernel-side implementation of the media framework. | ||
| 14 | |||
| 15 | |||
| 16 | Abstract media device model | ||
| 17 | --------------------------- | ||
| 18 | |||
| 19 | Discovering a device internal topology, and configuring it at runtime, is one | ||
| 20 | of the goals of the media framework. To achieve this, hardware devices are | ||
| 21 | modeled as an oriented graph of building blocks called entities connected | ||
| 22 | through pads. | ||
| 23 | |||
| 24 | An entity is a basic media hardware building block. It can correspond to | ||
| 25 | a large variety of logical blocks such as physical hardware devices | ||
| 26 | (CMOS sensor for instance), logical hardware devices (a building block | ||
| 27 | in a System-on-Chip image processing pipeline), DMA channels or physical | ||
| 28 | connectors. | ||
| 29 | |||
| 30 | A pad is a connection endpoint through which an entity can interact with | ||
| 31 | other entities. Data (not restricted to video) produced by an entity | ||
| 32 | flows from the entity's output to one or more entity inputs. Pads should | ||
| 33 | not be confused with physical pins at chip boundaries. | ||
| 34 | |||
| 35 | A link is a point-to-point oriented connection between two pads, either | ||
| 36 | on the same entity or on different entities. Data flows from a source | ||
| 37 | pad to a sink pad. | ||
| 38 | |||
| 39 | |||
| 40 | Media device | ||
| 41 | ------------ | ||
| 42 | |||
| 43 | A media device is represented by a struct media_device instance, defined in | ||
| 44 | include/media/media-device.h. Allocation of the structure is handled by the | ||
| 45 | media device driver, usually by embedding the media_device instance in a | ||
| 46 | larger driver-specific structure. | ||
| 47 | |||
| 48 | Drivers register media device instances by calling | ||
| 49 | |||
| 50 | media_device_register(struct media_device *mdev); | ||
| 51 | |||
| 52 | The caller is responsible for initializing the media_device structure before | ||
| 53 | registration. The following fields must be set: | ||
| 54 | |||
| 55 | - dev must point to the parent device (usually a pci_dev, usb_interface or | ||
| 56 | platform_device instance). | ||
| 57 | |||
| 58 | - model must be filled with the device model name as a NUL-terminated UTF-8 | ||
| 59 | string. The device/model revision must not be stored in this field. | ||
| 60 | |||
| 61 | The following fields are optional: | ||
| 62 | |||
| 63 | - serial is a unique serial number stored as a NUL-terminated ASCII string. | ||
| 64 | The field is big enough to store a GUID in text form. If the hardware | ||
| 65 | doesn't provide a unique serial number this field must be left empty. | ||
| 66 | |||
| 67 | - bus_info represents the location of the device in the system as a | ||
| 68 | NUL-terminated ASCII string. For PCI/PCIe devices bus_info must be set to | ||
| 69 | "PCI:" (or "PCIe:") followed by the value of pci_name(). For USB devices, | ||
| 70 | the usb_make_path() function must be used. This field is used by | ||
| 71 | applications to distinguish between otherwise identical devices that don't | ||
| 72 | provide a serial number. | ||
| 73 | |||
| 74 | - hw_revision is the hardware device revision in a driver-specific format. | ||
| 75 | When possible the revision should be formatted with the KERNEL_VERSION | ||
| 76 | macro. | ||
| 77 | |||
| 78 | - driver_version is formatted with the KERNEL_VERSION macro. The version | ||
| 79 | minor must be incremented when new features are added to the userspace API | ||
| 80 | without breaking binary compatibility. The version major must be | ||
| 81 | incremented when binary compatibility is broken. | ||
| 82 | |||
| 83 | Upon successful registration a character device named media[0-9]+ is created. | ||
| 84 | The device major and minor numbers are dynamic. The model name is exported as | ||
| 85 | a sysfs attribute. | ||
| 86 | |||
| 87 | Drivers unregister media device instances by calling | ||
| 88 | |||
| 89 | media_device_unregister(struct media_device *mdev); | ||
| 90 | |||
| 91 | Unregistering a media device that hasn't been registered is *NOT* safe. | ||
| 92 | |||
| 93 | |||
| 94 | Entities, pads and links | ||
| 95 | ------------------------ | ||
| 96 | |||
| 97 | - Entities | ||
| 98 | |||
| 99 | Entities are represented by a struct media_entity instance, defined in | ||
| 100 | include/media/media-entity.h. The structure is usually embedded into a | ||
| 101 | higher-level structure, such as a v4l2_subdev or video_device instance, | ||
| 102 | although drivers can allocate entities directly. | ||
| 103 | |||
| 104 | Drivers initialize entities by calling | ||
| 105 | |||
| 106 | media_entity_init(struct media_entity *entity, u16 num_pads, | ||
| 107 | struct media_pad *pads, u16 extra_links); | ||
| 108 | |||
| 109 | The media_entity name, type, flags, revision and group_id fields can be | ||
| 110 | initialized before or after calling media_entity_init. Entities embedded in | ||
| 111 | higher-level standard structures can have some of those fields set by the | ||
| 112 | higher-level framework. | ||
| 113 | |||
| 114 | As the number of pads is known in advance, the pads array is not allocated | ||
| 115 | dynamically but is managed by the entity driver. Most drivers will embed the | ||
| 116 | pads array in a driver-specific structure, avoiding dynamic allocation. | ||
| 117 | |||
| 118 | Drivers must set the direction of every pad in the pads array before calling | ||
| 119 | media_entity_init. The function will initialize the other pads fields. | ||
| 120 | |||
| 121 | Unlike the number of pads, the total number of links isn't always known in | ||
| 122 | advance by the entity driver. As an initial estimate, media_entity_init | ||
| 123 | pre-allocates a number of links equal to the number of pads plus an optional | ||
| 124 | number of extra links. The links array will be reallocated if it grows beyond | ||
| 125 | the initial estimate. | ||
| 126 | |||
| 127 | Drivers register entities with a media device by calling | ||
| 128 | |||
| 129 | media_device_register_entity(struct media_device *mdev, | ||
| 130 | struct media_entity *entity); | ||
| 131 | |||
| 132 | Entities are identified by a unique positive integer ID. Drivers can provide an | ||
| 133 | ID by filling the media_entity id field prior to registration, or request the | ||
| 134 | media controller framework to assign an ID automatically. Drivers that provide | ||
| 135 | IDs manually must ensure that all IDs are unique. IDs are not guaranteed to be | ||
| 136 | contiguous even when they are all assigned automatically by the framework. | ||
| 137 | |||
| 138 | Drivers unregister entities by calling | ||
| 139 | |||
| 140 | media_device_unregister_entity(struct media_entity *entity); | ||
| 141 | |||
| 142 | Unregistering an entity will not change the IDs of the other entities, and the | ||
| 143 | ID will never be reused for a newly registered entity. | ||
| 144 | |||
| 145 | When a media device is unregistered, all its entities are unregistered | ||
| 146 | automatically. No manual entities unregistration is then required. | ||
| 147 | |||
| 148 | Drivers free resources associated with an entity by calling | ||
| 149 | |||
| 150 | media_entity_cleanup(struct media_entity *entity); | ||
| 151 | |||
| 152 | This function must be called during the cleanup phase after unregistering the | ||
| 153 | entity. Note that the media_entity instance itself must be freed explicitly by | ||
| 154 | the driver if required. | ||
| 155 | |||
| 156 | Entities have flags that describe the entity capabilities and state. | ||
| 157 | |||
| 158 | MEDIA_ENT_FL_DEFAULT indicates the default entity for a given type. | ||
| 159 | This can be used to report the default audio and video devices or the | ||
| 160 | default camera sensor. | ||
| 161 | |||
| 162 | Logical entity groups can be defined by setting the group ID of all member | ||
| 163 | entities to the same non-zero value. An entity group serves no purpose in the | ||
| 164 | kernel, but is reported to userspace during entities enumeration. The group_id | ||
| 165 | field belongs to the media device driver and must not by touched by entity | ||
| 166 | drivers. | ||
| 167 | |||
| 168 | Media device drivers should define groups if several entities are logically | ||
| 169 | bound together. Example usages include reporting | ||
| 170 | |||
| 171 | - ALSA, VBI and video nodes that carry the same media stream | ||
| 172 | - lens and flash controllers associated with a sensor | ||
| 173 | |||
| 174 | - Pads | ||
| 175 | |||
| 176 | Pads are represented by a struct media_pad instance, defined in | ||
| 177 | include/media/media-entity.h. Each entity stores its pads in a pads array | ||
| 178 | managed by the entity driver. Drivers usually embed the array in a | ||
| 179 | driver-specific structure. | ||
| 180 | |||
| 181 | Pads are identified by their entity and their 0-based index in the pads array. | ||
| 182 | Both information are stored in the media_pad structure, making the media_pad | ||
| 183 | pointer the canonical way to store and pass link references. | ||
| 184 | |||
| 185 | Pads have flags that describe the pad capabilities and state. | ||
| 186 | |||
| 187 | MEDIA_PAD_FL_SINK indicates that the pad supports sinking data. | ||
| 188 | MEDIA_PAD_FL_SOURCE indicates that the pad supports sourcing data. | ||
| 189 | |||
| 190 | One and only one of MEDIA_PAD_FL_SINK and MEDIA_PAD_FL_SOURCE must be set for | ||
| 191 | each pad. | ||
| 192 | |||
| 193 | - Links | ||
| 194 | |||
| 195 | Links are represented by a struct media_link instance, defined in | ||
| 196 | include/media/media-entity.h. Each entity stores all links originating at or | ||
| 197 | targeting any of its pads in a links array. A given link is thus stored | ||
| 198 | twice, once in the source entity and once in the target entity. The array is | ||
| 199 | pre-allocated and grows dynamically as needed. | ||
| 200 | |||
| 201 | Drivers create links by calling | ||
| 202 | |||
| 203 | media_entity_create_link(struct media_entity *source, u16 source_pad, | ||
| 204 | struct media_entity *sink, u16 sink_pad, | ||
| 205 | u32 flags); | ||
| 206 | |||
| 207 | An entry in the link array of each entity is allocated and stores pointers | ||
| 208 | to source and sink pads. | ||
| 209 | |||
| 210 | Links have flags that describe the link capabilities and state. | ||
| 211 | |||
| 212 | MEDIA_LNK_FL_ENABLED indicates that the link is enabled and can be used | ||
| 213 | to transfer media data. When two or more links target a sink pad, only | ||
| 214 | one of them can be enabled at a time. | ||
| 215 | MEDIA_LNK_FL_IMMUTABLE indicates that the link enabled state can't be | ||
| 216 | modified at runtime. If MEDIA_LNK_FL_IMMUTABLE is set, then | ||
| 217 | MEDIA_LNK_FL_ENABLED must also be set since an immutable link is always | ||
| 218 | enabled. | ||
| 219 | |||
| 220 | |||
| 221 | Graph traversal | ||
| 222 | --------------- | ||
| 223 | |||
| 224 | The media framework provides APIs to iterate over entities in a graph. | ||
| 225 | |||
| 226 | To iterate over all entities belonging to a media device, drivers can use the | ||
| 227 | media_device_for_each_entity macro, defined in include/media/media-device.h. | ||
| 228 | |||
| 229 | struct media_entity *entity; | ||
| 230 | |||
| 231 | media_device_for_each_entity(entity, mdev) { | ||
| 232 | /* entity will point to each entity in turn */ | ||
| 233 | ... | ||
| 234 | } | ||
| 235 | |||
| 236 | Drivers might also need to iterate over all entities in a graph that can be | ||
| 237 | reached only through enabled links starting at a given entity. The media | ||
| 238 | framework provides a depth-first graph traversal API for that purpose. | ||
| 239 | |||
| 240 | Note that graphs with cycles (whether directed or undirected) are *NOT* | ||
| 241 | supported by the graph traversal API. To prevent infinite loops, the graph | ||
| 242 | traversal code limits the maximum depth to MEDIA_ENTITY_ENUM_MAX_DEPTH, | ||
| 243 | currently defined as 16. | ||
| 244 | |||
| 245 | Drivers initiate a graph traversal by calling | ||
| 246 | |||
| 247 | media_entity_graph_walk_start(struct media_entity_graph *graph, | ||
| 248 | struct media_entity *entity); | ||
| 249 | |||
| 250 | The graph structure, provided by the caller, is initialized to start graph | ||
| 251 | traversal at the given entity. | ||
| 252 | |||
| 253 | Drivers can then retrieve the next entity by calling | ||
| 254 | |||
| 255 | media_entity_graph_walk_next(struct media_entity_graph *graph); | ||
| 256 | |||
| 257 | When the graph traversal is complete the function will return NULL. | ||
| 258 | |||
| 259 | Graph traversal can be interrupted at any moment. No cleanup function call is | ||
| 260 | required and the graph structure can be freed normally. | ||
| 261 | |||
| 262 | Helper functions can be used to find a link between two given pads, or a pad | ||
| 263 | connected to another pad through an enabled link | ||
| 264 | |||
| 265 | media_entity_find_link(struct media_pad *source, | ||
| 266 | struct media_pad *sink); | ||
| 267 | |||
| 268 | media_entity_remote_source(struct media_pad *pad); | ||
| 269 | |||
| 270 | Refer to the kerneldoc documentation for more information. | ||
| 271 | |||
| 272 | |||
| 273 | Use count and power handling | ||
| 274 | ---------------------------- | ||
| 275 | |||
| 276 | Due to the wide differences between drivers regarding power management needs, | ||
| 277 | the media controller does not implement power management. However, the | ||
| 278 | media_entity structure includes a use_count field that media drivers can use to | ||
| 279 | track the number of users of every entity for power management needs. | ||
| 280 | |||
| 281 | The use_count field is owned by media drivers and must not be touched by entity | ||
| 282 | drivers. Access to the field must be protected by the media device graph_mutex | ||
| 283 | lock. | ||
| 284 | |||
| 285 | |||
| 286 | Links setup | ||
| 287 | ----------- | ||
| 288 | |||
| 289 | Link properties can be modified at runtime by calling | ||
| 290 | |||
| 291 | media_entity_setup_link(struct media_link *link, u32 flags); | ||
| 292 | |||
| 293 | The flags argument contains the requested new link flags. | ||
| 294 | |||
| 295 | The only configurable property is the ENABLED link flag to enable/disable a | ||
| 296 | link. Links marked with the IMMUTABLE link flag can not be enabled or disabled. | ||
| 297 | |||
| 298 | When a link is enabled or disabled, the media framework calls the | ||
| 299 | link_setup operation for the two entities at the source and sink of the link, | ||
| 300 | in that order. If the second link_setup call fails, another link_setup call is | ||
| 301 | made on the first entity to restore the original link flags. | ||
| 302 | |||
| 303 | Media device drivers can be notified of link setup operations by setting the | ||
| 304 | media_device::link_notify pointer to a callback function. If provided, the | ||
| 305 | notification callback will be called before enabling and after disabling | ||
| 306 | links. | ||
| 307 | |||
| 308 | Entity drivers must implement the link_setup operation if any of their links | ||
| 309 | is non-immutable. The operation must either configure the hardware or store | ||
| 310 | the configuration information to be applied later. | ||
| 311 | |||
| 312 | Link configuration must not have any side effect on other links. If an enabled | ||
| 313 | link at a sink pad prevents another link at the same pad from being disabled, | ||
| 314 | the link_setup operation must return -EBUSY and can't implicitly disable the | ||
| 315 | first enabled link. | ||
| 316 | |||
| 317 | |||
| 318 | Pipelines and media streams | ||
| 319 | --------------------------- | ||
| 320 | |||
| 321 | When starting streaming, drivers must notify all entities in the pipeline to | ||
| 322 | prevent link states from being modified during streaming by calling | ||
| 323 | |||
| 324 | media_entity_pipeline_start(struct media_entity *entity, | ||
| 325 | struct media_pipeline *pipe); | ||
| 326 | |||
| 327 | The function will mark all entities connected to the given entity through | ||
| 328 | enabled links, either directly or indirectly, as streaming. | ||
| 329 | |||
| 330 | The media_pipeline instance pointed to by the pipe argument will be stored in | ||
| 331 | every entity in the pipeline. Drivers should embed the media_pipeline structure | ||
| 332 | in higher-level pipeline structures and can then access the pipeline through | ||
| 333 | the media_entity pipe field. | ||
| 334 | |||
| 335 | Calls to media_entity_pipeline_start() can be nested. The pipeline pointer must | ||
| 336 | be identical for all nested calls to the function. | ||
| 337 | |||
| 338 | When stopping the stream, drivers must notify the entities with | ||
| 339 | |||
| 340 | media_entity_pipeline_stop(struct media_entity *entity); | ||
| 341 | |||
| 342 | If multiple calls to media_entity_pipeline_start() have been made the same | ||
| 343 | number of media_entity_pipeline_stop() calls are required to stop streaming. The | ||
| 344 | media_entity pipe field is reset to NULL on the last nested stop call. | ||
| 345 | |||
| 346 | Link configuration will fail with -EBUSY by default if either end of the link is | ||
| 347 | a streaming entity. Links that can be modified while streaming must be marked | ||
| 348 | with the MEDIA_LNK_FL_DYNAMIC flag. | ||
| 349 | |||
| 350 | If other operations need to be disallowed on streaming entities (such as | ||
| 351 | changing entities configuration parameters) drivers can explicitly check the | ||
| 352 | media_entity stream_count field to find out if an entity is streaming. This | ||
| 353 | operation must be done with the media_device graph_mutex held. | ||
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 631ad2f1b229..f0d3a8026a56 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt | |||
| @@ -21,6 +21,7 @@ Contents: | |||
| 21 | - SMP barrier pairing. | 21 | - SMP barrier pairing. |
| 22 | - Examples of memory barrier sequences. | 22 | - Examples of memory barrier sequences. |
| 23 | - Read memory barriers vs load speculation. | 23 | - Read memory barriers vs load speculation. |
| 24 | - Transitivity | ||
| 24 | 25 | ||
| 25 | (*) Explicit kernel barriers. | 26 | (*) Explicit kernel barriers. |
| 26 | 27 | ||
| @@ -959,6 +960,63 @@ the speculation will be cancelled and the value reloaded: | |||
| 959 | retrieved : : +-------+ | 960 | retrieved : : +-------+ |
| 960 | 961 | ||
| 961 | 962 | ||
| 963 | TRANSITIVITY | ||
| 964 | ------------ | ||
| 965 | |||
| 966 | Transitivity is a deeply intuitive notion about ordering that is not | ||
| 967 | always provided by real computer systems. The following example | ||
| 968 | demonstrates transitivity (also called "cumulativity"): | ||
| 969 | |||
| 970 | CPU 1 CPU 2 CPU 3 | ||
| 971 | ======================= ======================= ======================= | ||
| 972 | { X = 0, Y = 0 } | ||
| 973 | STORE X=1 LOAD X STORE Y=1 | ||
| 974 | <general barrier> <general barrier> | ||
| 975 | LOAD Y LOAD X | ||
| 976 | |||
| 977 | Suppose that CPU 2's load from X returns 1 and its load from Y returns 0. | ||
| 978 | This indicates that CPU 2's load from X in some sense follows CPU 1's | ||
| 979 | store to X and that CPU 2's load from Y in some sense preceded CPU 3's | ||
| 980 | store to Y. The question is then "Can CPU 3's load from X return 0?" | ||
| 981 | |||
| 982 | Because CPU 2's load from X in some sense came after CPU 1's store, it | ||
| 983 | is natural to expect that CPU 3's load from X must therefore return 1. | ||
| 984 | This expectation is an example of transitivity: if a load executing on | ||
| 985 | CPU A follows a load from the same variable executing on CPU B, then | ||
| 986 | CPU A's load must either return the same value that CPU B's load did, | ||
| 987 | or must return some later value. | ||
| 988 | |||
| 989 | In the Linux kernel, use of general memory barriers guarantees | ||
| 990 | transitivity. Therefore, in the above example, if CPU 2's load from X | ||
| 991 | returns 1 and its load from Y returns 0, then CPU 3's load from X must | ||
| 992 | also return 1. | ||
| 993 | |||
| 994 | However, transitivity is -not- guaranteed for read or write barriers. | ||
| 995 | For example, suppose that CPU 2's general barrier in the above example | ||
| 996 | is changed to a read barrier as shown below: | ||
| 997 | |||
| 998 | CPU 1 CPU 2 CPU 3 | ||
| 999 | ======================= ======================= ======================= | ||
| 1000 | { X = 0, Y = 0 } | ||
| 1001 | STORE X=1 LOAD X STORE Y=1 | ||
| 1002 | <read barrier> <general barrier> | ||
| 1003 | LOAD Y LOAD X | ||
| 1004 | |||
| 1005 | This substitution destroys transitivity: in this example, it is perfectly | ||
| 1006 | legal for CPU 2's load from X to return 1, its load from Y to return 0, | ||
| 1007 | and CPU 3's load from X to return 0. | ||
| 1008 | |||
| 1009 | The key point is that although CPU 2's read barrier orders its pair | ||
| 1010 | of loads, it does not guarantee to order CPU 1's store. Therefore, if | ||
| 1011 | this example runs on a system where CPUs 1 and 2 share a store buffer | ||
| 1012 | or a level of cache, CPU 2 might have early access to CPU 1's writes. | ||
| 1013 | General barriers are therefore required to ensure that all CPUs agree | ||
| 1014 | on the combined order of CPU 1's and CPU 2's accesses. | ||
| 1015 | |||
| 1016 | To reiterate, if your code requires transitivity, use general barriers | ||
| 1017 | throughout. | ||
| 1018 | |||
| 1019 | |||
| 962 | ======================== | 1020 | ======================== |
| 963 | EXPLICIT KERNEL BARRIERS | 1021 | EXPLICIT KERNEL BARRIERS |
| 964 | ======================== | 1022 | ======================== |
diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt index 57e7e9cc1870..8f485d72cf25 100644 --- a/Documentation/memory-hotplug.txt +++ b/Documentation/memory-hotplug.txt | |||
| @@ -126,36 +126,51 @@ config options. | |||
| 126 | -------------------------------- | 126 | -------------------------------- |
| 127 | 4 sysfs files for memory hotplug | 127 | 4 sysfs files for memory hotplug |
| 128 | -------------------------------- | 128 | -------------------------------- |
| 129 | All sections have their device information under /sys/devices/system/memory as | 129 | All sections have their device information in sysfs. Each section is part of |
| 130 | a memory block under /sys/devices/system/memory as | ||
| 130 | 131 | ||
| 131 | /sys/devices/system/memory/memoryXXX | 132 | /sys/devices/system/memory/memoryXXX |
| 132 | (XXX is section id.) | 133 | (XXX is the section id.) |
| 133 | 134 | ||
| 134 | Now, XXX is defined as start_address_of_section / section_size. | 135 | Now, XXX is defined as (start_address_of_section / section_size) of the first |
| 136 | section contained in the memory block. The files 'phys_index' and | ||
| 137 | 'end_phys_index' under each directory report the beginning and end section id's | ||
| 138 | for the memory block covered by the sysfs directory. It is expected that all | ||
| 139 | memory sections in this range are present and no memory holes exist in the | ||
| 140 | range. Currently there is no way to determine if there is a memory hole, but | ||
| 141 | the existence of one should not affect the hotplug capabilities of the memory | ||
| 142 | block. | ||
| 135 | 143 | ||
| 136 | For example, assume 1GiB section size. A device for a memory starting at | 144 | For example, assume 1GiB section size. A device for a memory starting at |
| 137 | 0x100000000 is /sys/device/system/memory/memory4 | 145 | 0x100000000 is /sys/device/system/memory/memory4 |
| 138 | (0x100000000 / 1Gib = 4) | 146 | (0x100000000 / 1Gib = 4) |
| 139 | This device covers address range [0x100000000 ... 0x140000000) | 147 | This device covers address range [0x100000000 ... 0x140000000) |
| 140 | 148 | ||
| 141 | Under each section, you can see 4 files. | 149 | Under each section, you can see 4 or 5 files, the end_phys_index file being |
| 150 | a recent addition and not present on older kernels. | ||
| 142 | 151 | ||
| 143 | /sys/devices/system/memory/memoryXXX/phys_index | 152 | /sys/devices/system/memory/memoryXXX/start_phys_index |
| 153 | /sys/devices/system/memory/memoryXXX/end_phys_index | ||
| 144 | /sys/devices/system/memory/memoryXXX/phys_device | 154 | /sys/devices/system/memory/memoryXXX/phys_device |
| 145 | /sys/devices/system/memory/memoryXXX/state | 155 | /sys/devices/system/memory/memoryXXX/state |
| 146 | /sys/devices/system/memory/memoryXXX/removable | 156 | /sys/devices/system/memory/memoryXXX/removable |
| 147 | 157 | ||
| 148 | 'phys_index' : read-only and contains section id, same as XXX. | 158 | 'phys_index' : read-only and contains section id of the first section |
| 149 | 'state' : read-write | 159 | in the memory block, same as XXX. |
| 150 | at read: contains online/offline state of memory. | 160 | 'end_phys_index' : read-only and contains section id of the last section |
| 151 | at write: user can specify "online", "offline" command | 161 | in the memory block. |
| 152 | 'phys_device': read-only: designed to show the name of physical memory device. | 162 | 'state' : read-write |
| 153 | This is not well implemented now. | 163 | at read: contains online/offline state of memory. |
| 154 | 'removable' : read-only: contains an integer value indicating | 164 | at write: user can specify "online", "offline" command |
| 155 | whether the memory section is removable or not | 165 | which will be performed on al sections in the block. |
| 156 | removable. A value of 1 indicates that the memory | 166 | 'phys_device' : read-only: designed to show the name of physical memory |
| 157 | section is removable and a value of 0 indicates that | 167 | device. This is not well implemented now. |
| 158 | it is not removable. | 168 | 'removable' : read-only: contains an integer value indicating |
| 169 | whether the memory block is removable or not | ||
| 170 | removable. A value of 1 indicates that the memory | ||
| 171 | block is removable and a value of 0 indicates that | ||
| 172 | it is not removable. A memory block is removable only if | ||
| 173 | every section in the block is removable. | ||
| 159 | 174 | ||
| 160 | NOTE: | 175 | NOTE: |
| 161 | These directories/files appear after physical memory hotplug phase. | 176 | These directories/files appear after physical memory hotplug phase. |
diff --git a/Documentation/mips/AU1xxx_IDE.README b/Documentation/mips/AU1xxx_IDE.README index 8ace35ebdcd5..cc887ecfd6eb 100644 --- a/Documentation/mips/AU1xxx_IDE.README +++ b/Documentation/mips/AU1xxx_IDE.README | |||
| @@ -39,13 +39,13 @@ Note: for more information, please refer "AMD Alchemy Au1200/Au1550 IDE | |||
| 39 | Interface and Linux Device Driver" Application Note. | 39 | Interface and Linux Device Driver" Application Note. |
| 40 | 40 | ||
| 41 | 41 | ||
| 42 | FILES, CONFIGS AND COMPATABILITY | 42 | FILES, CONFIGS AND COMPATIBILITY |
| 43 | -------------------------------- | 43 | -------------------------------- |
| 44 | 44 | ||
| 45 | Two files are introduced: | 45 | Two files are introduced: |
| 46 | 46 | ||
| 47 | a) 'arch/mips/include/asm/mach-au1x00/au1xxx_ide.h' | 47 | a) 'arch/mips/include/asm/mach-au1x00/au1xxx_ide.h' |
| 48 | containes : struct _auide_hwif | 48 | contains : struct _auide_hwif |
| 49 | timing parameters for PIO mode 0/1/2/3/4 | 49 | timing parameters for PIO mode 0/1/2/3/4 |
| 50 | timing parameters for MWDMA 0/1/2 | 50 | timing parameters for MWDMA 0/1/2 |
| 51 | 51 | ||
diff --git a/Documentation/misc-devices/ics932s401 b/Documentation/misc-devices/ics932s401 index 07a739f406d8..bdac67ff6e3f 100644 --- a/Documentation/misc-devices/ics932s401 +++ b/Documentation/misc-devices/ics932s401 | |||
| @@ -5,7 +5,7 @@ Supported chips: | |||
| 5 | * IDT ICS932S401 | 5 | * IDT ICS932S401 |
| 6 | Prefix: 'ics932s401' | 6 | Prefix: 'ics932s401' |
| 7 | Addresses scanned: I2C 0x69 | 7 | Addresses scanned: I2C 0x69 |
| 8 | Datasheet: Publically available at the IDT website | 8 | Datasheet: Publicly available at the IDT website |
| 9 | 9 | ||
| 10 | Author: Darrick J. Wong | 10 | Author: Darrick J. Wong |
| 11 | 11 | ||
diff --git a/Documentation/hwmon/lis3lv02d b/Documentation/misc-devices/lis3lv02d index 06534f25e643..f1a4ec840f86 100644 --- a/Documentation/hwmon/lis3lv02d +++ b/Documentation/misc-devices/lis3lv02d | |||
| @@ -17,8 +17,8 @@ Description | |||
| 17 | This driver provides support for the accelerometer found in various HP laptops | 17 | This driver provides support for the accelerometer found in various HP laptops |
| 18 | sporting the feature officially called "HP Mobile Data Protection System 3D" or | 18 | sporting the feature officially called "HP Mobile Data Protection System 3D" or |
| 19 | "HP 3D DriveGuard". It detects automatically laptops with this sensor. Known | 19 | "HP 3D DriveGuard". It detects automatically laptops with this sensor. Known |
| 20 | models (full list can be found in drivers/hwmon/hp_accel.c) will have their | 20 | models (full list can be found in drivers/platform/x86/hp_accel.c) will have |
| 21 | axis automatically oriented on standard way (eg: you can directly play | 21 | their axis automatically oriented on standard way (eg: you can directly play |
| 22 | neverball). The accelerometer data is readable via | 22 | neverball). The accelerometer data is readable via |
| 23 | /sys/devices/platform/lis3lv02d. Reported values are scaled | 23 | /sys/devices/platform/lis3lv02d. Reported values are scaled |
| 24 | to mg values (1/1000th of earth gravity). | 24 | to mg values (1/1000th of earth gravity). |
diff --git a/Documentation/misc-devices/spear-pcie-gadget.txt b/Documentation/misc-devices/spear-pcie-gadget.txt new file mode 100644 index 000000000000..02c13ef5e908 --- /dev/null +++ b/Documentation/misc-devices/spear-pcie-gadget.txt | |||
| @@ -0,0 +1,130 @@ | |||
| 1 | Spear PCIe Gadget Driver: | ||
| 2 | |||
| 3 | Author | ||
| 4 | ============= | ||
| 5 | Pratyush Anand (pratyush.anand@st.com) | ||
| 6 | |||
| 7 | Location | ||
| 8 | ============ | ||
| 9 | driver/misc/spear13xx_pcie_gadget.c | ||
| 10 | |||
| 11 | Supported Chip: | ||
| 12 | =================== | ||
| 13 | SPEAr1300 | ||
| 14 | SPEAr1310 | ||
| 15 | |||
| 16 | Menuconfig option: | ||
| 17 | ========================== | ||
| 18 | Device Drivers | ||
| 19 | Misc devices | ||
| 20 | PCIe gadget support for SPEAr13XX platform | ||
| 21 | purpose | ||
| 22 | =========== | ||
| 23 | This driver has several nodes which can be read/written by configfs interface. | ||
| 24 | Its main purpose is to configure selected dual mode PCIe controller as device | ||
| 25 | and then program its various registers to configure it as a particular device | ||
| 26 | type. This driver can be used to show spear's PCIe device capability. | ||
| 27 | |||
| 28 | Description of different nodes: | ||
| 29 | ================================= | ||
| 30 | |||
| 31 | read behavior of nodes: | ||
| 32 | ------------------------------ | ||
| 33 | link :gives ltssm status. | ||
| 34 | int_type :type of supported interrupt | ||
| 35 | no_of_msi :zero if MSI is not enabled by host. A positive value is the | ||
| 36 | number of MSI vector granted. | ||
| 37 | vendor_id :returns programmed vendor id (hex) | ||
| 38 | device_id :returns programmed device id(hex) | ||
| 39 | bar0_size: :returns size of bar0 in hex. | ||
| 40 | bar0_address :returns address of bar0 mapped area in hex. | ||
| 41 | bar0_rw_offset :returns offset of bar0 for which bar0_data will return value. | ||
| 42 | bar0_data :returns data at bar0_rw_offset. | ||
| 43 | |||
| 44 | write behavior of nodes: | ||
| 45 | ------------------------------ | ||
| 46 | link :write UP to enable ltsmm DOWN to disable | ||
| 47 | int_type :write interrupt type to be configured and (int_type could be | ||
| 48 | INTA, MSI or NO_INT). Select MSI only when you have programmed | ||
| 49 | no_of_msi node. | ||
| 50 | no_of_msi :number of MSI vector needed. | ||
| 51 | inta :write 1 to assert INTA and 0 to de-assert. | ||
| 52 | send_msi :write MSI vector to be sent. | ||
| 53 | vendor_id :write vendor id(hex) to be programmed. | ||
| 54 | device_id :write device id(hex) to be programmed. | ||
| 55 | bar0_size :write size of bar0 in hex. default bar0 size is 1000 (hex) | ||
| 56 | bytes. | ||
| 57 | bar0_address :write address of bar0 mapped area in hex. (default mapping of | ||
| 58 | bar0 is SYSRAM1(E0800000). Always program bar size before bar | ||
| 59 | address. Kernel might modify bar size and address for alignment, so | ||
| 60 | read back bar size and address after writing to cross check. | ||
| 61 | bar0_rw_offset :write offset of bar0 for which bar0_data will write value. | ||
| 62 | bar0_data :write data to be written at bar0_rw_offset. | ||
| 63 | |||
| 64 | Node programming example | ||
| 65 | =========================== | ||
| 66 | Program all PCIe registers in such a way that when this device is connected | ||
| 67 | to the PCIe host, then host sees this device as 1MB RAM. | ||
| 68 | #mount -t configfs none /Config | ||
| 69 | For nth PCIe Device Controller | ||
| 70 | # cd /config/pcie_gadget.n/ | ||
| 71 | Now you have all the nodes in this directory. | ||
| 72 | program vendor id as 0x104a | ||
| 73 | # echo 104A >> vendor_id | ||
| 74 | |||
| 75 | program device id as 0xCD80 | ||
| 76 | # echo CD80 >> device_id | ||
| 77 | |||
| 78 | program BAR0 size as 1MB | ||
| 79 | # echo 100000 >> bar0_size | ||
| 80 | |||
| 81 | check for programmed bar0 size | ||
| 82 | # cat bar0_size | ||
| 83 | |||
| 84 | Program BAR0 Address as DDR (0x2100000). This is the physical address of | ||
| 85 | memory, which is to be made visible to PCIe host. Similarly any other peripheral | ||
| 86 | can also be made visible to PCIe host. E.g., if you program base address of UART | ||
| 87 | as BAR0 address then when this device will be connected to a host, it will be | ||
| 88 | visible as UART. | ||
| 89 | # echo 2100000 >> bar0_address | ||
| 90 | |||
| 91 | program interrupt type : INTA | ||
| 92 | # echo INTA >> int_type | ||
| 93 | |||
| 94 | go for link up now. | ||
| 95 | # echo UP >> link | ||
| 96 | |||
| 97 | It will have to be insured that, once link up is done on gadget, then only host | ||
| 98 | is initialized and start to search PCIe devices on its port. | ||
| 99 | |||
| 100 | /*wait till link is up*/ | ||
| 101 | # cat link | ||
| 102 | wait till it returns UP. | ||
| 103 | |||
| 104 | To assert INTA | ||
| 105 | # echo 1 >> inta | ||
| 106 | |||
| 107 | To de-assert INTA | ||
| 108 | # echo 0 >> inta | ||
| 109 | |||
| 110 | if MSI is to be used as interrupt, program no of msi vector needed (say4) | ||
| 111 | # echo 4 >> no_of_msi | ||
| 112 | |||
| 113 | select MSI as interrupt type | ||
| 114 | # echo MSI >> int_type | ||
| 115 | |||
| 116 | go for link up now | ||
| 117 | # echo UP >> link | ||
| 118 | |||
| 119 | wait till link is up | ||
| 120 | # cat link | ||
| 121 | An application can repetitively read this node till link is found UP. It can | ||
| 122 | sleep between two read. | ||
| 123 | |||
| 124 | wait till msi is enabled | ||
| 125 | # cat no_of_msi | ||
| 126 | Should return 4 (number of requested MSI vector) | ||
| 127 | |||
| 128 | to send msi vector 2 | ||
| 129 | # echo 2 >> send_msi | ||
| 130 | #cd - | ||
diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX index fe5c099b8fc8..4edd78dfb362 100644 --- a/Documentation/networking/00-INDEX +++ b/Documentation/networking/00-INDEX | |||
| @@ -40,8 +40,6 @@ decnet.txt | |||
| 40 | - info on using the DECnet networking layer in Linux. | 40 | - info on using the DECnet networking layer in Linux. |
| 41 | depca.txt | 41 | depca.txt |
| 42 | - the Digital DEPCA/EtherWORKS DE1?? and DE2?? LANCE Ethernet driver | 42 | - the Digital DEPCA/EtherWORKS DE1?? and DE2?? LANCE Ethernet driver |
| 43 | dgrs.txt | ||
| 44 | - the Digi International RightSwitch SE-X Ethernet driver | ||
| 45 | dmfe.txt | 43 | dmfe.txt |
| 46 | - info on the Davicom DM9102(A)/DM9132/DM9801 fast ethernet driver. | 44 | - info on the Davicom DM9102(A)/DM9132/DM9801 fast ethernet driver. |
| 47 | e100.txt | 45 | e100.txt |
| @@ -50,8 +48,6 @@ e1000.txt | |||
| 50 | - info on Intel's E1000 line of gigabit ethernet boards | 48 | - info on Intel's E1000 line of gigabit ethernet boards |
| 51 | eql.txt | 49 | eql.txt |
| 52 | - serial IP load balancing | 50 | - serial IP load balancing |
| 53 | ethertap.txt | ||
| 54 | - the Ethertap user space packet reception and transmission driver | ||
| 55 | ewrk3.txt | 51 | ewrk3.txt |
| 56 | - the Digital EtherWORKS 3 DE203/4/5 Ethernet driver | 52 | - the Digital EtherWORKS 3 DE203/4/5 Ethernet driver |
| 57 | filter.txt | 53 | filter.txt |
| @@ -104,8 +100,6 @@ tuntap.txt | |||
| 104 | - TUN/TAP device driver, allowing user space Rx/Tx of packets. | 100 | - TUN/TAP device driver, allowing user space Rx/Tx of packets. |
| 105 | vortex.txt | 101 | vortex.txt |
| 106 | - info on using 3Com Vortex (3c590, 3c592, 3c595, 3c597) Ethernet cards. | 102 | - info on using 3Com Vortex (3c590, 3c592, 3c595, 3c597) Ethernet cards. |
| 107 | wavelan.txt | ||
| 108 | - AT&T GIS (nee NCR) WaveLAN card: An Ethernet-like radio transceiver | ||
| 109 | x25.txt | 103 | x25.txt |
| 110 | - general info on X.25 development. | 104 | - general info on X.25 development. |
| 111 | x25-iface.txt | 105 | x25-iface.txt |
diff --git a/Documentation/networking/3c359.txt b/Documentation/networking/3c359.txt index 4af8071a6d18..dadfe8147ab8 100644 --- a/Documentation/networking/3c359.txt +++ b/Documentation/networking/3c359.txt | |||
| @@ -45,7 +45,7 @@ debugging messages on, that must be done by modified the source code. | |||
| 45 | 45 | ||
| 46 | Variable MTU size: | 46 | Variable MTU size: |
| 47 | 47 | ||
| 48 | The driver can handle a MTU size upto either 4500 or 18000 depending upon | 48 | The driver can handle a MTU size up to either 4500 or 18000 depending upon |
| 49 | ring speed. The driver also changes the size of the receive buffers as part | 49 | ring speed. The driver also changes the size of the receive buffers as part |
| 50 | of the mtu re-sizing, so if you set mtu = 18000, you will need to be able | 50 | of the mtu re-sizing, so if you set mtu = 18000, you will need to be able |
| 51 | to allocate 16 * (sk_buff with 18000 buffer size) call it 18500 bytes per ring | 51 | to allocate 16 * (sk_buff with 18000 buffer size) call it 18500 bytes per ring |
diff --git a/Documentation/networking/Makefile b/Documentation/networking/Makefile index 5aba7a33aeeb..24c308dd3fd1 100644 --- a/Documentation/networking/Makefile +++ b/Documentation/networking/Makefile | |||
| @@ -4,6 +4,8 @@ obj- := dummy.o | |||
| 4 | # List of programs to build | 4 | # List of programs to build |
| 5 | hostprogs-y := ifenslave | 5 | hostprogs-y := ifenslave |
| 6 | 6 | ||
| 7 | HOSTCFLAGS_ifenslave.o += -I$(objtree)/usr/include | ||
| 8 | |||
| 7 | # Tell kbuild to always build the programs | 9 | # Tell kbuild to always build the programs |
| 8 | always := $(hostprogs-y) | 10 | always := $(hostprogs-y) |
| 9 | 11 | ||
diff --git a/Documentation/networking/README.ipw2200 b/Documentation/networking/README.ipw2200 index 616a8e540b0b..b7658bed4906 100644 --- a/Documentation/networking/README.ipw2200 +++ b/Documentation/networking/README.ipw2200 | |||
| @@ -256,7 +256,7 @@ You can set the debug level via: | |||
| 256 | 256 | ||
| 257 | Where $VALUE would be a number in the case of this sysfs entry. The | 257 | Where $VALUE would be a number in the case of this sysfs entry. The |
| 258 | input to sysfs files does not have to be a number. For example, the | 258 | input to sysfs files does not have to be a number. For example, the |
| 259 | firmware loader used by hotplug utilizes sysfs entries for transfering | 259 | firmware loader used by hotplug utilizes sysfs entries for transferring |
| 260 | the firmware image from user space into the driver. | 260 | the firmware image from user space into the driver. |
| 261 | 261 | ||
| 262 | The Intel(R) PRO/Wireless 2915ABG Driver for Linux exposes sysfs entries | 262 | The Intel(R) PRO/Wireless 2915ABG Driver for Linux exposes sysfs entries |
diff --git a/Documentation/networking/batman-adv.txt b/Documentation/networking/batman-adv.txt index 77f0cdd5b0dd..ee496eb2f4a6 100644 --- a/Documentation/networking/batman-adv.txt +++ b/Documentation/networking/batman-adv.txt | |||
| @@ -1,4 +1,4 @@ | |||
| 1 | [state: 21-11-2010] | 1 | [state: 27-01-2011] |
| 2 | 2 | ||
| 3 | BATMAN-ADV | 3 | BATMAN-ADV |
| 4 | ---------- | 4 | ---------- |
| @@ -67,15 +67,16 @@ All mesh wide settings can be found in batman's own interface | |||
| 67 | folder: | 67 | folder: |
| 68 | 68 | ||
| 69 | # ls /sys/class/net/bat0/mesh/ | 69 | # ls /sys/class/net/bat0/mesh/ |
| 70 | # aggregated_ogms bonding fragmentation orig_interval | 70 | # aggregated_ogms gw_bandwidth hop_penalty |
| 71 | # vis_mode | 71 | # bonding gw_mode orig_interval |
| 72 | # fragmentation gw_sel_class vis_mode | ||
| 72 | 73 | ||
| 73 | 74 | ||
| 74 | There is a special folder for debugging informations: | 75 | There is a special folder for debugging information: |
| 75 | 76 | ||
| 76 | # ls /sys/kernel/debug/batman_adv/bat0/ | 77 | # ls /sys/kernel/debug/batman_adv/bat0/ |
| 77 | # originators socket transtable_global transtable_local | 78 | # gateways socket transtable_global vis_data |
| 78 | # vis_data | 79 | # originators softif_neigh transtable_local |
| 79 | 80 | ||
| 80 | 81 | ||
| 81 | Some of the files contain all sort of status information regard- | 82 | Some of the files contain all sort of status information regard- |
| @@ -230,9 +231,8 @@ CONTACT | |||
| 230 | Please send us comments, experiences, questions, anything :) | 231 | Please send us comments, experiences, questions, anything :) |
| 231 | 232 | ||
| 232 | IRC: #batman on irc.freenode.org | 233 | IRC: #batman on irc.freenode.org |
| 233 | Mailing-list: b.a.t.m.a.n@b.a.t.m.a.n@lists.open-mesh.org | 234 | Mailing-list: b.a.t.m.a.n@open-mesh.org (optional subscription |
| 234 | (optional subscription at | 235 | at https://lists.open-mesh.org/mm/listinfo/b.a.t.m.a.n) |
| 235 | https://lists.open-mesh.org/mm/listinfo/b.a.t.m.a.n) | ||
| 236 | 236 | ||
| 237 | You can also contact the Authors: | 237 | You can also contact the Authors: |
| 238 | 238 | ||
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt index 25d2f4141d27..e27202bb8d75 100644 --- a/Documentation/networking/bonding.txt +++ b/Documentation/networking/bonding.txt | |||
| @@ -368,7 +368,7 @@ fail_over_mac | |||
| 368 | gratuitous ARP is lost, communication may be | 368 | gratuitous ARP is lost, communication may be |
| 369 | disrupted. | 369 | disrupted. |
| 370 | 370 | ||
| 371 | When this policy is used in conjuction with the mii | 371 | When this policy is used in conjunction with the mii |
| 372 | monitor, devices which assert link up prior to being | 372 | monitor, devices which assert link up prior to being |
| 373 | able to actually transmit and receive are particularly | 373 | able to actually transmit and receive are particularly |
| 374 | susceptible to loss of the gratuitous ARP, and an | 374 | susceptible to loss of the gratuitous ARP, and an |
| @@ -2558,18 +2558,15 @@ enslaved. | |||
| 2558 | 16. Resources and Links | 2558 | 16. Resources and Links |
| 2559 | ======================= | 2559 | ======================= |
| 2560 | 2560 | ||
| 2561 | The latest version of the bonding driver can be found in the latest | 2561 | The latest version of the bonding driver can be found in the latest |
| 2562 | version of the linux kernel, found on http://kernel.org | 2562 | version of the linux kernel, found on http://kernel.org |
| 2563 | 2563 | ||
| 2564 | The latest version of this document can be found in either the latest | 2564 | The latest version of this document can be found in the latest kernel |
| 2565 | kernel source (named Documentation/networking/bonding.txt), or on the | 2565 | source (named Documentation/networking/bonding.txt). |
| 2566 | bonding sourceforge site: | ||
| 2567 | 2566 | ||
| 2568 | http://www.sourceforge.net/projects/bonding | 2567 | Discussions regarding the usage of the bonding driver take place on the |
| 2569 | 2568 | bonding-devel mailing list, hosted at sourceforge.net. If you have questions or | |
| 2570 | Discussions regarding the bonding driver take place primarily on the | 2569 | problems, post them to the list. The list address is: |
| 2571 | bonding-devel mailing list, hosted at sourceforge.net. If you have | ||
| 2572 | questions or problems, post them to the list. The list address is: | ||
| 2573 | 2570 | ||
| 2574 | bonding-devel@lists.sourceforge.net | 2571 | bonding-devel@lists.sourceforge.net |
| 2575 | 2572 | ||
| @@ -2578,6 +2575,17 @@ be found at: | |||
| 2578 | 2575 | ||
| 2579 | https://lists.sourceforge.net/lists/listinfo/bonding-devel | 2576 | https://lists.sourceforge.net/lists/listinfo/bonding-devel |
| 2580 | 2577 | ||
| 2578 | Discussions regarding the developpement of the bonding driver take place | ||
| 2579 | on the main Linux network mailing list, hosted at vger.kernel.org. The list | ||
| 2580 | address is: | ||
| 2581 | |||
| 2582 | netdev@vger.kernel.org | ||
| 2583 | |||
| 2584 | The administrative interface (to subscribe or unsubscribe) can | ||
| 2585 | be found at: | ||
| 2586 | |||
| 2587 | http://vger.kernel.org/vger-lists.html#netdev | ||
| 2588 | |||
| 2581 | Donald Becker's Ethernet Drivers and diag programs may be found at : | 2589 | Donald Becker's Ethernet Drivers and diag programs may be found at : |
| 2582 | - http://web.archive.org/web/*/http://www.scyld.com/network/ | 2590 | - http://web.archive.org/web/*/http://www.scyld.com/network/ |
| 2583 | 2591 | ||
diff --git a/Documentation/networking/caif/Linux-CAIF.txt b/Documentation/networking/caif/Linux-CAIF.txt index 7fe7a9a33a4f..e52fd62bef3a 100644 --- a/Documentation/networking/caif/Linux-CAIF.txt +++ b/Documentation/networking/caif/Linux-CAIF.txt | |||
| @@ -136,7 +136,7 @@ The CAIF Protocol implementation contains: | |||
| 136 | - CFMUX CAIF Mux layer. Handles multiplexing between multiple | 136 | - CFMUX CAIF Mux layer. Handles multiplexing between multiple |
| 137 | physical bearers and multiple channels such as VEI, Datagram, etc. | 137 | physical bearers and multiple channels such as VEI, Datagram, etc. |
| 138 | The MUX keeps track of the existing CAIF Channels and | 138 | The MUX keeps track of the existing CAIF Channels and |
| 139 | Physical Instances and selects the apropriate instance based | 139 | Physical Instances and selects the appropriate instance based |
| 140 | on Channel-Id and Physical-ID. | 140 | on Channel-Id and Physical-ID. |
| 141 | 141 | ||
| 142 | - CFFRML CAIF Framing layer. Handles Framing i.e. Frame length | 142 | - CFFRML CAIF Framing layer. Handles Framing i.e. Frame length |
diff --git a/Documentation/networking/caif/spi_porting.txt b/Documentation/networking/caif/spi_porting.txt index 0cb8cb9098f4..9efd0687dc4c 100644 --- a/Documentation/networking/caif/spi_porting.txt +++ b/Documentation/networking/caif/spi_porting.txt | |||
| @@ -150,7 +150,7 @@ static int sspi_init_xfer(struct cfspi_xfer *xfer, struct cfspi_dev *dev) | |||
| 150 | void sspi_sig_xfer(bool xfer, struct cfspi_dev *dev) | 150 | void sspi_sig_xfer(bool xfer, struct cfspi_dev *dev) |
| 151 | { | 151 | { |
| 152 | /* If xfer is true then you should assert the SPI_INT to indicate to | 152 | /* If xfer is true then you should assert the SPI_INT to indicate to |
| 153 | * the master that you are ready to recieve the data from the master | 153 | * the master that you are ready to receive the data from the master |
| 154 | * SPI. If xfer is false then you should de-assert SPI_INT to indicate | 154 | * SPI. If xfer is false then you should de-assert SPI_INT to indicate |
| 155 | * that the transfer is done. | 155 | * that the transfer is done. |
| 156 | */ | 156 | */ |
diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt index 5b04b67ddca2..56ca3b75376e 100644 --- a/Documentation/networking/can.txt +++ b/Documentation/networking/can.txt | |||
| @@ -240,7 +240,7 @@ solution for a couple of reasons: | |||
| 240 | the user application using the common CAN filter mechanisms. Inside | 240 | the user application using the common CAN filter mechanisms. Inside |
| 241 | this filter definition the (interested) type of errors may be | 241 | this filter definition the (interested) type of errors may be |
| 242 | selected. The reception of error frames is disabled by default. | 242 | selected. The reception of error frames is disabled by default. |
| 243 | The format of the CAN error frame is briefly decribed in the Linux | 243 | The format of the CAN error frame is briefly described in the Linux |
| 244 | header file "include/linux/can/error.h". | 244 | header file "include/linux/can/error.h". |
| 245 | 245 | ||
| 246 | 4. How to use Socket CAN | 246 | 4. How to use Socket CAN |
diff --git a/Documentation/networking/dns_resolver.txt b/Documentation/networking/dns_resolver.txt index aefd1e681804..04ca06325b08 100644 --- a/Documentation/networking/dns_resolver.txt +++ b/Documentation/networking/dns_resolver.txt | |||
| @@ -61,7 +61,6 @@ before the more general line given above as the first match is the one taken. | |||
| 61 | create dns_resolver foo:* * /usr/sbin/dns.foo %k | 61 | create dns_resolver foo:* * /usr/sbin/dns.foo %k |
| 62 | 62 | ||
| 63 | 63 | ||
| 64 | |||
| 65 | ===== | 64 | ===== |
| 66 | USAGE | 65 | USAGE |
| 67 | ===== | 66 | ===== |
| @@ -104,6 +103,14 @@ implemented in the module can be called after doing: | |||
| 104 | returned also. | 103 | returned also. |
| 105 | 104 | ||
| 106 | 105 | ||
| 106 | =============================== | ||
| 107 | READING DNS KEYS FROM USERSPACE | ||
| 108 | =============================== | ||
| 109 | |||
| 110 | Keys of dns_resolver type can be read from userspace using keyctl_read() or | ||
| 111 | "keyctl read/print/pipe". | ||
| 112 | |||
| 113 | |||
| 107 | ========= | 114 | ========= |
| 108 | MECHANISM | 115 | MECHANISM |
| 109 | ========= | 116 | ========= |
diff --git a/Documentation/networking/ieee802154.txt b/Documentation/networking/ieee802154.txt index 23c995e64032..f41ea2405220 100644 --- a/Documentation/networking/ieee802154.txt +++ b/Documentation/networking/ieee802154.txt | |||
| @@ -9,7 +9,7 @@ The Linux-ZigBee project goal is to provide complete implementation | |||
| 9 | of IEEE 802.15.4 / ZigBee / 6LoWPAN protocols. IEEE 802.15.4 is a stack | 9 | of IEEE 802.15.4 / ZigBee / 6LoWPAN protocols. IEEE 802.15.4 is a stack |
| 10 | of protocols for organizing Low-Rate Wireless Personal Area Networks. | 10 | of protocols for organizing Low-Rate Wireless Personal Area Networks. |
| 11 | 11 | ||
| 12 | Currently only IEEE 802.15.4 layer is implemented. We have choosen | 12 | Currently only IEEE 802.15.4 layer is implemented. We have chosen |
| 13 | to use plain Berkeley socket API, the generic Linux networking stack | 13 | to use plain Berkeley socket API, the generic Linux networking stack |
| 14 | to transfer IEEE 802.15.4 messages and a special protocol over genetlink | 14 | to transfer IEEE 802.15.4 messages and a special protocol over genetlink |
| 15 | for configuration/management | 15 | for configuration/management |
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index d99940dcfc44..d3d653a5f9b9 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt | |||
| @@ -187,7 +187,7 @@ tcp_cookie_size - INTEGER | |||
| 187 | tcp_dsack - BOOLEAN | 187 | tcp_dsack - BOOLEAN |
| 188 | Allows TCP to send "duplicate" SACKs. | 188 | Allows TCP to send "duplicate" SACKs. |
| 189 | 189 | ||
| 190 | tcp_ecn - BOOLEAN | 190 | tcp_ecn - INTEGER |
| 191 | Enable Explicit Congestion Notification (ECN) in TCP. ECN is only | 191 | Enable Explicit Congestion Notification (ECN) in TCP. ECN is only |
| 192 | used when both ends of the TCP flow support it. It is useful to | 192 | used when both ends of the TCP flow support it. It is useful to |
| 193 | avoid losses due to congestion (when the bottleneck router supports | 193 | avoid losses due to congestion (when the bottleneck router supports |
| @@ -280,6 +280,17 @@ tcp_max_orphans - INTEGER | |||
| 280 | more aggressively. Let me to remind again: each orphan eats | 280 | more aggressively. Let me to remind again: each orphan eats |
| 281 | up to ~64K of unswappable memory. | 281 | up to ~64K of unswappable memory. |
| 282 | 282 | ||
| 283 | tcp_max_ssthresh - INTEGER | ||
| 284 | Limited Slow-Start for TCP with large congestion windows (cwnd) defined in | ||
| 285 | RFC3742. Limited slow-start is a mechanism to limit growth of the cwnd | ||
| 286 | on the region where cwnd is larger than tcp_max_ssthresh. TCP increases cwnd | ||
| 287 | by at most tcp_max_ssthresh segments, and by at least tcp_max_ssthresh/2 | ||
| 288 | segments per RTT when the cwnd is above tcp_max_ssthresh. | ||
| 289 | If TCP connection increased cwnd to thousands (or tens of thousands) segments, | ||
| 290 | and thousands of packets were being dropped during slow-start, you can set | ||
| 291 | tcp_max_ssthresh to improve performance for new TCP connection. | ||
| 292 | Default: 0 (off) | ||
| 293 | |||
| 283 | tcp_max_syn_backlog - INTEGER | 294 | tcp_max_syn_backlog - INTEGER |
| 284 | Maximal number of remembered connection requests, which are | 295 | Maximal number of remembered connection requests, which are |
| 285 | still did not receive an acknowledgment from connecting client. | 296 | still did not receive an acknowledgment from connecting client. |
diff --git a/Documentation/networking/olympic.txt b/Documentation/networking/olympic.txt index c65a94010ea8..b95b5bf96751 100644 --- a/Documentation/networking/olympic.txt +++ b/Documentation/networking/olympic.txt | |||
| @@ -65,7 +65,7 @@ together. | |||
| 65 | 65 | ||
| 66 | Variable MTU size: | 66 | Variable MTU size: |
| 67 | 67 | ||
| 68 | The driver can handle a MTU size upto either 4500 or 18000 depending upon | 68 | The driver can handle a MTU size up to either 4500 or 18000 depending upon |
| 69 | ring speed. The driver also changes the size of the receive buffers as part | 69 | ring speed. The driver also changes the size of the receive buffers as part |
| 70 | of the mtu re-sizing, so if you set mtu = 18000, you will need to be able | 70 | of the mtu re-sizing, so if you set mtu = 18000, you will need to be able |
| 71 | to allocate 16 * (sk_buff with 18000 buffer size) call it 18500 bytes per ring | 71 | to allocate 16 * (sk_buff with 18000 buffer size) call it 18500 bytes per ring |
diff --git a/Documentation/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt index 073894d1c093..4acea6603720 100644 --- a/Documentation/networking/packet_mmap.txt +++ b/Documentation/networking/packet_mmap.txt | |||
| @@ -223,7 +223,7 @@ we will get the following buffer structure: | |||
| 223 | 223 | ||
| 224 | A frame can be of any size with the only condition it can fit in a block. A block | 224 | A frame can be of any size with the only condition it can fit in a block. A block |
| 225 | can only hold an integer number of frames, or in other words, a frame cannot | 225 | can only hold an integer number of frames, or in other words, a frame cannot |
| 226 | be spawned accross two blocks, so there are some details you have to take into | 226 | be spawned across two blocks, so there are some details you have to take into |
| 227 | account when choosing the frame_size. See "Mapping and use of the circular | 227 | account when choosing the frame_size. See "Mapping and use of the circular |
| 228 | buffer (ring)". | 228 | buffer (ring)". |
| 229 | 229 | ||
diff --git a/Documentation/networking/phonet.txt b/Documentation/networking/phonet.txt index 24ad2adba6e5..81003581f47a 100644 --- a/Documentation/networking/phonet.txt +++ b/Documentation/networking/phonet.txt | |||
| @@ -154,9 +154,28 @@ connections, one per accept()'d socket. | |||
| 154 | write(cfd, msg, msglen); | 154 | write(cfd, msg, msglen); |
| 155 | } | 155 | } |
| 156 | 156 | ||
| 157 | Connections are established between two endpoints by a "third party" | 157 | Connections are traditionally established between two endpoints by a |
| 158 | application. This means that both endpoints are passive; so connect() | 158 | "third party" application. This means that both endpoints are passive. |
| 159 | is not possible. | 159 | |
| 160 | |||
| 161 | As of Linux kernel version 2.6.39, it is also possible to connect | ||
| 162 | two endpoints directly, using connect() on the active side. This is | ||
| 163 | intended to support the newer Nokia Wireless Modem API, as found in | ||
| 164 | e.g. the Nokia Slim Modem in the ST-Ericsson U8500 platform: | ||
| 165 | |||
| 166 | struct sockaddr_spn spn; | ||
| 167 | int fd; | ||
| 168 | |||
| 169 | fd = socket(PF_PHONET, SOCK_SEQPACKET, PN_PROTO_PIPE); | ||
| 170 | memset(&spn, 0, sizeof(spn)); | ||
| 171 | spn.spn_family = AF_PHONET; | ||
| 172 | spn.spn_obj = ...; | ||
| 173 | spn.spn_dev = ...; | ||
| 174 | spn.spn_resource = 0xD9; | ||
| 175 | connect(fd, (struct sockaddr *)&spn, sizeof(spn)); | ||
| 176 | /* normal I/O here ... */ | ||
| 177 | close(fd); | ||
| 178 | |||
| 160 | 179 | ||
| 161 | WARNING: | 180 | WARNING: |
| 162 | When polling a connected pipe socket for writability, there is an | 181 | When polling a connected pipe socket for writability, there is an |
| @@ -181,45 +200,9 @@ The pipe protocol provides two socket options at the SOL_PNPIPE level: | |||
| 181 | interface index of the network interface created by PNPIPE_ENCAP, | 200 | interface index of the network interface created by PNPIPE_ENCAP, |
| 182 | or zero if encapsulation is off. | 201 | or zero if encapsulation is off. |
| 183 | 202 | ||
| 184 | 203 | PNPIPE_HANDLE is a read-only integer value. It contains the underlying | |
| 185 | Phonet Pipe-controller Implementation | 204 | identifier ("pipe handle") of the pipe. This is only defined for |
| 186 | ------------------------------------- | 205 | socket descriptors that are already connected or being connected. |
| 187 | |||
| 188 | Phonet Pipe-controller is enabled by selecting the CONFIG_PHONET_PIPECTRLR Kconfig | ||
| 189 | option. It is useful when communicating with those Nokia Modems which do not | ||
| 190 | implement Pipe controller in them e.g. Nokia Slim Modem used in ST-Ericsson | ||
| 191 | U8500 platform. | ||
| 192 | |||
| 193 | The implementation is based on the Data Connection Establishment Sequence | ||
| 194 | depicted in 'Nokia Wireless Modem API - Wireless_modem_user_guide.pdf' | ||
| 195 | document. | ||
| 196 | |||
| 197 | It allows a phonet sequenced socket (host-pep) to initiate a Pipe connection | ||
| 198 | between itself and a remote pipe-end point (e.g. modem). | ||
| 199 | |||
| 200 | The implementation adds socket options at SOL_PNPIPE level: | ||
| 201 | |||
| 202 | PNPIPE_PIPE_HANDLE | ||
| 203 | It accepts an integer argument for setting value of pipe handle. | ||
| 204 | |||
| 205 | PNPIPE_ENABLE accepts one integer value (int). If set to zero, the pipe | ||
| 206 | is disabled. If the value is non-zero, the pipe is enabled. If the pipe | ||
| 207 | is not (yet) connected, ENOTCONN is error is returned. | ||
| 208 | |||
| 209 | The implementation also adds socket 'connect'. On calling the 'connect', pipe | ||
| 210 | will be created between the source socket and the destination, and the pipe | ||
| 211 | state will be set to PIPE_DISABLED. | ||
| 212 | |||
| 213 | After a pipe has been created and enabled successfully, the Pipe data can be | ||
| 214 | exchanged between the host-pep and remote-pep (modem). | ||
| 215 | |||
| 216 | User-space would typically follow below sequence with Pipe controller:- | ||
| 217 | -socket | ||
| 218 | -bind | ||
| 219 | -setsockopt for PNPIPE_PIPE_HANDLE | ||
| 220 | -connect | ||
| 221 | -setsockopt for PNPIPE_ENCAP_IP | ||
| 222 | -setsockopt for PNPIPE_ENABLE | ||
| 223 | 206 | ||
| 224 | 207 | ||
| 225 | Authors | 208 | Authors |
diff --git a/Documentation/networking/s2io.txt b/Documentation/networking/s2io.txt index 9d4e0f4df5a8..4be0c039edbc 100644 --- a/Documentation/networking/s2io.txt +++ b/Documentation/networking/s2io.txt | |||
| @@ -37,7 +37,7 @@ To associate an interface with a physical adapter use "ethtool -p <ethX>". | |||
| 37 | The corresponding adapter's LED will blink multiple times. | 37 | The corresponding adapter's LED will blink multiple times. |
| 38 | 38 | ||
| 39 | 3. Features supported: | 39 | 3. Features supported: |
| 40 | a. Jumbo frames. Xframe I/II supports MTU upto 9600 bytes, | 40 | a. Jumbo frames. Xframe I/II supports MTU up to 9600 bytes, |
| 41 | modifiable using ifconfig command. | 41 | modifiable using ifconfig command. |
| 42 | 42 | ||
| 43 | b. Offloads. Supports checksum offload(TCP/UDP/IP) on transmit | 43 | b. Offloads. Supports checksum offload(TCP/UDP/IP) on transmit |
| @@ -49,7 +49,7 @@ significant performance improvement on certain platforms(SGI Altix, | |||
| 49 | IBM xSeries). | 49 | IBM xSeries). |
| 50 | 50 | ||
| 51 | d. MSI/MSI-X. Can be enabled on platforms which support this feature | 51 | d. MSI/MSI-X. Can be enabled on platforms which support this feature |
| 52 | (IA64, Xeon) resulting in noticeable performance improvement(upto 7% | 52 | (IA64, Xeon) resulting in noticeable performance improvement(up to 7% |
| 53 | on certain platforms). | 53 | on certain platforms). |
| 54 | 54 | ||
| 55 | e. Statistics. Comprehensive MAC-level and software statistics displayed | 55 | e. Statistics. Comprehensive MAC-level and software statistics displayed |
diff --git a/Documentation/networking/tc-actions-env-rules.txt b/Documentation/networking/tc-actions-env-rules.txt index dcadf6f88e34..70d6cf608251 100644 --- a/Documentation/networking/tc-actions-env-rules.txt +++ b/Documentation/networking/tc-actions-env-rules.txt | |||
| @@ -1,5 +1,5 @@ | |||
| 1 | 1 | ||
| 2 | The "enviromental" rules for authors of any new tc actions are: | 2 | The "environmental" rules for authors of any new tc actions are: |
| 3 | 3 | ||
| 4 | 1) If you stealeth or borroweth any packet thou shalt be branching | 4 | 1) If you stealeth or borroweth any packet thou shalt be branching |
| 5 | from the righteous path and thou shalt cloneth. | 5 | from the righteous path and thou shalt cloneth. |
| @@ -20,7 +20,7 @@ this way any action downstream can stomp on the packet. | |||
| 20 | 3) Dropping packets you don't own is a no-no. You simply return | 20 | 3) Dropping packets you don't own is a no-no. You simply return |
| 21 | TC_ACT_SHOT to the caller and they will drop it. | 21 | TC_ACT_SHOT to the caller and they will drop it. |
| 22 | 22 | ||
| 23 | The "enviromental" rules for callers of actions (qdiscs etc) are: | 23 | The "environmental" rules for callers of actions (qdiscs etc) are: |
| 24 | 24 | ||
| 25 | *) Thou art responsible for freeing anything returned as being | 25 | *) Thou art responsible for freeing anything returned as being |
| 26 | TC_ACT_SHOT/STOLEN/QUEUED. If none of TC_ACT_SHOT/STOLEN/QUEUED is | 26 | TC_ACT_SHOT/STOLEN/QUEUED. If none of TC_ACT_SHOT/STOLEN/QUEUED is |
diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt index 57080cd74575..1971bcf48a60 100644 --- a/Documentation/power/devices.txt +++ b/Documentation/power/devices.txt | |||
| @@ -1,6 +1,6 @@ | |||
| 1 | Device Power Management | 1 | Device Power Management |
| 2 | 2 | ||
| 3 | Copyright (c) 2010 Rafael J. Wysocki <rjw@sisk.pl>, Novell Inc. | 3 | Copyright (c) 2010-2011 Rafael J. Wysocki <rjw@sisk.pl>, Novell Inc. |
| 4 | Copyright (c) 2010 Alan Stern <stern@rowland.harvard.edu> | 4 | Copyright (c) 2010 Alan Stern <stern@rowland.harvard.edu> |
| 5 | 5 | ||
| 6 | 6 | ||
| @@ -159,18 +159,18 @@ matter, and the kernel is responsible for keeping track of it. By contrast, | |||
| 159 | whether or not a wakeup-capable device should issue wakeup events is a policy | 159 | whether or not a wakeup-capable device should issue wakeup events is a policy |
| 160 | decision, and it is managed by user space through a sysfs attribute: the | 160 | decision, and it is managed by user space through a sysfs attribute: the |
| 161 | power/wakeup file. User space can write the strings "enabled" or "disabled" to | 161 | power/wakeup file. User space can write the strings "enabled" or "disabled" to |
| 162 | set or clear the should_wakeup flag, respectively. Reads from the file will | 162 | set or clear the "should_wakeup" flag, respectively. This file is only present |
| 163 | return the corresponding string if can_wakeup is true, but if can_wakeup is | 163 | for wakeup-capable devices (i.e. devices whose "can_wakeup" flags are set) |
| 164 | false then reads will return an empty string, to indicate that the device | 164 | and is created (or removed) by device_set_wakeup_capable(). Reads from the |
| 165 | doesn't support wakeup events. (But even though the file appears empty, writes | 165 | file will return the corresponding string. |
| 166 | will still affect the should_wakeup flag.) | ||
| 167 | 166 | ||
| 168 | The device_may_wakeup() routine returns true only if both flags are set. | 167 | The device_may_wakeup() routine returns true only if both flags are set. |
| 169 | Drivers should check this routine when putting devices in a low-power state | 168 | This information is used by subsystems, like the PCI bus type code, to see |
| 170 | during a system sleep transition, to see whether or not to enable the devices' | 169 | whether or not to enable the devices' wakeup mechanisms. If device wakeup |
| 171 | wakeup mechanisms. However for runtime power management, wakeup events should | 170 | mechanisms are enabled or disabled directly by drivers, they also should use |
| 172 | be enabled whenever the device and driver both support them, regardless of the | 171 | device_may_wakeup() to decide what to do during a system sleep transition. |
| 173 | should_wakeup flag. | 172 | However for runtime power management, wakeup events should be enabled whenever |
| 173 | the device and driver both support them, regardless of the should_wakeup flag. | ||
| 174 | 174 | ||
| 175 | 175 | ||
| 176 | /sys/devices/.../power/control files | 176 | /sys/devices/.../power/control files |
| @@ -249,23 +249,18 @@ various phases always run after tasks have been frozen and before they are | |||
| 249 | unfrozen. Furthermore, the *_noirq phases run at a time when IRQ handlers have | 249 | unfrozen. Furthermore, the *_noirq phases run at a time when IRQ handlers have |
| 250 | been disabled (except for those marked with the IRQ_WAKEUP flag). | 250 | been disabled (except for those marked with the IRQ_WAKEUP flag). |
| 251 | 251 | ||
| 252 | Most phases use bus, type, and class callbacks (that is, methods defined in | 252 | All phases use bus, type, or class callbacks (that is, methods defined in |
| 253 | dev->bus->pm, dev->type->pm, and dev->class->pm). The prepare and complete | 253 | dev->bus->pm, dev->type->pm, or dev->class->pm). These callbacks are mutually |
| 254 | phases are exceptions; they use only bus callbacks. When multiple callbacks | 254 | exclusive, so if the device type provides a struct dev_pm_ops object pointed to |
| 255 | are used in a phase, they are invoked in the order: <class, type, bus> during | 255 | by its pm field (i.e. both dev->type and dev->type->pm are defined), the |
| 256 | power-down transitions and in the opposite order during power-up transitions. | 256 | callbacks included in that object (i.e. dev->type->pm) will be used. Otherwise, |
| 257 | For example, during the suspend phase the PM core invokes | 257 | if the class provides a struct dev_pm_ops object pointed to by its pm field |
| 258 | 258 | (i.e. both dev->class and dev->class->pm are defined), the PM core will use the | |
| 259 | dev->class->pm.suspend(dev); | 259 | callbacks from that object (i.e. dev->class->pm). Finally, if the pm fields of |
| 260 | dev->type->pm.suspend(dev); | 260 | both the device type and class objects are NULL (or those objects do not exist), |
| 261 | dev->bus->pm.suspend(dev); | 261 | the callbacks provided by the bus (that is, the callbacks from dev->bus->pm) |
| 262 | 262 | will be used (this allows device types to override callbacks provided by bus | |
| 263 | before moving on to the next device, whereas during the resume phase the core | 263 | types or classes if necessary). |
| 264 | invokes | ||
| 265 | |||
| 266 | dev->bus->pm.resume(dev); | ||
| 267 | dev->type->pm.resume(dev); | ||
| 268 | dev->class->pm.resume(dev); | ||
| 269 | 264 | ||
| 270 | These callbacks may in turn invoke device- or driver-specific methods stored in | 265 | These callbacks may in turn invoke device- or driver-specific methods stored in |
| 271 | dev->driver->pm, but they don't have to. | 266 | dev->driver->pm, but they don't have to. |
| @@ -372,7 +367,7 @@ Drivers need to be able to handle hardware which has been reset since the | |||
| 372 | suspend methods were called, for example by complete reinitialization. | 367 | suspend methods were called, for example by complete reinitialization. |
| 373 | This may be the hardest part, and the one most protected by NDA'd documents | 368 | This may be the hardest part, and the one most protected by NDA'd documents |
| 374 | and chip errata. It's simplest if the hardware state hasn't changed since | 369 | and chip errata. It's simplest if the hardware state hasn't changed since |
| 375 | the suspend was carried out, but that can't be guaranteed (in fact, it ususally | 370 | the suspend was carried out, but that can't be guaranteed (in fact, it usually |
| 376 | is not the case). | 371 | is not the case). |
| 377 | 372 | ||
| 378 | Drivers must also be prepared to notice that the device has been removed | 373 | Drivers must also be prepared to notice that the device has been removed |
| @@ -507,6 +502,49 @@ routines. Nevertheless, different callback pointers are used in case there is a | |||
| 507 | situation where it actually matters. | 502 | situation where it actually matters. |
| 508 | 503 | ||
| 509 | 504 | ||
| 505 | Device Power Domains | ||
| 506 | -------------------- | ||
| 507 | Sometimes devices share reference clocks or other power resources. In those | ||
| 508 | cases it generally is not possible to put devices into low-power states | ||
| 509 | individually. Instead, a set of devices sharing a power resource can be put | ||
| 510 | into a low-power state together at the same time by turning off the shared | ||
| 511 | power resource. Of course, they also need to be put into the full-power state | ||
| 512 | together, by turning the shared power resource on. A set of devices with this | ||
| 513 | property is often referred to as a power domain. | ||
| 514 | |||
| 515 | Support for power domains is provided through the pwr_domain field of struct | ||
| 516 | device. This field is a pointer to an object of type struct dev_power_domain, | ||
| 517 | defined in include/linux/pm.h, providing a set of power management callbacks | ||
| 518 | analogous to the subsystem-level and device driver callbacks that are executed | ||
| 519 | for the given device during all power transitions, in addition to the respective | ||
| 520 | subsystem-level callbacks. Specifically, the power domain "suspend" callbacks | ||
| 521 | (i.e. ->runtime_suspend(), ->suspend(), ->freeze(), ->poweroff(), etc.) are | ||
| 522 | executed after the analogous subsystem-level callbacks, while the power domain | ||
| 523 | "resume" callbacks (i.e. ->runtime_resume(), ->resume(), ->thaw(), ->restore, | ||
| 524 | etc.) are executed before the analogous subsystem-level callbacks. Error codes | ||
| 525 | returned by the "suspend" and "resume" power domain callbacks are ignored. | ||
| 526 | |||
| 527 | Power domain ->runtime_idle() callback is executed before the subsystem-level | ||
| 528 | ->runtime_idle() callback and the result returned by it is not ignored. Namely, | ||
| 529 | if it returns error code, the subsystem-level ->runtime_idle() callback will not | ||
| 530 | be called and the helper function rpm_idle() executing it will return error | ||
| 531 | code. This mechanism is intended to help platforms where saving device state | ||
| 532 | is a time consuming operation and should only be carried out if all devices | ||
| 533 | in the power domain are idle, before turning off the shared power resource(s). | ||
| 534 | Namely, the power domain ->runtime_idle() callback may return error code until | ||
| 535 | the pm_runtime_idle() helper (or its asychronous version) has been called for | ||
| 536 | all devices in the power domain (it is recommended that the returned error code | ||
| 537 | be -EBUSY in those cases), preventing the subsystem-level ->runtime_idle() | ||
| 538 | callback from being run prematurely. | ||
| 539 | |||
| 540 | The support for device power domains is only relevant to platforms needing to | ||
| 541 | use the same subsystem-level (e.g. platform bus type) and device driver power | ||
| 542 | management callbacks in many different power domain configurations and wanting | ||
| 543 | to avoid incorporating the support for power domains into the subsystem-level | ||
| 544 | callbacks. The other platforms need not implement it or take it into account | ||
| 545 | in any way. | ||
| 546 | |||
| 547 | |||
| 510 | System Devices | 548 | System Devices |
| 511 | -------------- | 549 | -------------- |
| 512 | System devices (sysdevs) follow a slightly different API, which can be found in | 550 | System devices (sysdevs) follow a slightly different API, which can be found in |
diff --git a/Documentation/power/notifiers.txt b/Documentation/power/notifiers.txt index ae1b7ec07684..cf980709122a 100644 --- a/Documentation/power/notifiers.txt +++ b/Documentation/power/notifiers.txt | |||
| @@ -24,7 +24,7 @@ PM_HIBERNATION_PREPARE The system is going to hibernate or suspend, tasks will | |||
| 24 | be frozen immediately. | 24 | be frozen immediately. |
| 25 | 25 | ||
| 26 | PM_POST_HIBERNATION The system memory state has been restored from a | 26 | PM_POST_HIBERNATION The system memory state has been restored from a |
| 27 | hibernation image or an error occured during the | 27 | hibernation image or an error occurred during the |
| 28 | hibernation. Device drivers' .resume() callbacks have | 28 | hibernation. Device drivers' .resume() callbacks have |
| 29 | been executed and tasks have been thawed. | 29 | been executed and tasks have been thawed. |
| 30 | 30 | ||
| @@ -38,7 +38,7 @@ PM_POST_RESTORE An error occurred during the hibernation restore. | |||
| 38 | 38 | ||
| 39 | PM_SUSPEND_PREPARE The system is preparing for a suspend. | 39 | PM_SUSPEND_PREPARE The system is preparing for a suspend. |
| 40 | 40 | ||
| 41 | PM_POST_SUSPEND The system has just resumed or an error occured during | 41 | PM_POST_SUSPEND The system has just resumed or an error occurred during |
| 42 | the suspend. Device drivers' .resume() callbacks have | 42 | the suspend. Device drivers' .resume() callbacks have |
| 43 | been executed and tasks have been thawed. | 43 | been executed and tasks have been thawed. |
| 44 | 44 | ||
diff --git a/Documentation/power/opp.txt b/Documentation/power/opp.txt index cd445582d1f8..5ae70a12c1e2 100644 --- a/Documentation/power/opp.txt +++ b/Documentation/power/opp.txt | |||
| @@ -178,7 +178,7 @@ opp_find_freq_ceil - Search for an available OPP which is *at least* the | |||
| 178 | if (!IS_ERR(opp)) | 178 | if (!IS_ERR(opp)) |
| 179 | soc_switch_to_freq_voltage(freq); | 179 | soc_switch_to_freq_voltage(freq); |
| 180 | else | 180 | else |
| 181 | /* do something when we cant satisfy the req */ | 181 | /* do something when we can't satisfy the req */ |
| 182 | /* do other stuff */ | 182 | /* do other stuff */ |
| 183 | } | 183 | } |
| 184 | 184 | ||
diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt index ffe55ffa540a..654097b130b4 100644 --- a/Documentation/power/runtime_pm.txt +++ b/Documentation/power/runtime_pm.txt | |||
| @@ -1,6 +1,6 @@ | |||
| 1 | Run-time Power Management Framework for I/O Devices | 1 | Run-time Power Management Framework for I/O Devices |
| 2 | 2 | ||
| 3 | (C) 2009 Rafael J. Wysocki <rjw@sisk.pl>, Novell Inc. | 3 | (C) 2009-2011 Rafael J. Wysocki <rjw@sisk.pl>, Novell Inc. |
| 4 | (C) 2010 Alan Stern <stern@rowland.harvard.edu> | 4 | (C) 2010 Alan Stern <stern@rowland.harvard.edu> |
| 5 | 5 | ||
| 6 | 1. Introduction | 6 | 1. Introduction |
| @@ -44,11 +44,12 @@ struct dev_pm_ops { | |||
| 44 | }; | 44 | }; |
| 45 | 45 | ||
| 46 | The ->runtime_suspend(), ->runtime_resume() and ->runtime_idle() callbacks are | 46 | The ->runtime_suspend(), ->runtime_resume() and ->runtime_idle() callbacks are |
| 47 | executed by the PM core for either the bus type, or device type (if the bus | 47 | executed by the PM core for either the device type, or the class (if the device |
| 48 | type's callback is not defined), or device class (if the bus type's and device | 48 | type's struct dev_pm_ops object does not exist), or the bus type (if the |
| 49 | type's callbacks are not defined) of given device. The bus type, device type | 49 | device type's and class' struct dev_pm_ops objects do not exist) of the given |
| 50 | and device class callbacks are referred to as subsystem-level callbacks in what | 50 | device (this allows device types to override callbacks provided by bus types or |
| 51 | follows. | 51 | classes if necessary). The bus type, device type and class callbacks are |
| 52 | referred to as subsystem-level callbacks in what follows. | ||
| 52 | 53 | ||
| 53 | By default, the callbacks are always invoked in process context with interrupts | 54 | By default, the callbacks are always invoked in process context with interrupts |
| 54 | enabled. However, subsystems can use the pm_runtime_irq_safe() helper function | 55 | enabled. However, subsystems can use the pm_runtime_irq_safe() helper function |
diff --git a/Documentation/power/states.txt b/Documentation/power/states.txt index 34800cc521bf..4416b28630df 100644 --- a/Documentation/power/states.txt +++ b/Documentation/power/states.txt | |||
| @@ -62,12 +62,12 @@ setup via another operating system for it to use. Despite the | |||
| 62 | inconvenience, this method requires minimal work by the kernel, since | 62 | inconvenience, this method requires minimal work by the kernel, since |
| 63 | the firmware will also handle restoring memory contents on resume. | 63 | the firmware will also handle restoring memory contents on resume. |
| 64 | 64 | ||
| 65 | For suspend-to-disk, a mechanism called swsusp called 'swsusp' (Swap | 65 | For suspend-to-disk, a mechanism called 'swsusp' (Swap Suspend) is used |
| 66 | Suspend) is used to write memory contents to free swap space. | 66 | to write memory contents to free swap space. swsusp has some restrictive |
| 67 | swsusp has some restrictive requirements, but should work in most | 67 | requirements, but should work in most cases. Some, albeit outdated, |
| 68 | cases. Some, albeit outdated, documentation can be found in | 68 | documentation can be found in Documentation/power/swsusp.txt. |
| 69 | Documentation/power/swsusp.txt. Alternatively, userspace can do most | 69 | Alternatively, userspace can do most of the actual suspend to disk work, |
| 70 | of the actual suspend to disk work, see userland-swsusp.txt. | 70 | see userland-swsusp.txt. |
| 71 | 71 | ||
| 72 | Once memory state is written to disk, the system may either enter a | 72 | Once memory state is written to disk, the system may either enter a |
| 73 | low-power state (like ACPI S4), or it may simply power down. Powering | 73 | low-power state (like ACPI S4), or it may simply power down. Powering |
diff --git a/Documentation/power/swsusp.txt b/Documentation/power/swsusp.txt index ea718891a665..ac190cf1963e 100644 --- a/Documentation/power/swsusp.txt +++ b/Documentation/power/swsusp.txt | |||
| @@ -192,7 +192,7 @@ Q: There don't seem to be any generally useful behavioral | |||
| 192 | distinctions between SUSPEND and FREEZE. | 192 | distinctions between SUSPEND and FREEZE. |
| 193 | 193 | ||
| 194 | A: Doing SUSPEND when you are asked to do FREEZE is always correct, | 194 | A: Doing SUSPEND when you are asked to do FREEZE is always correct, |
| 195 | but it may be unneccessarily slow. If you want your driver to stay simple, | 195 | but it may be unnecessarily slow. If you want your driver to stay simple, |
| 196 | slowness may not matter to you. It can always be fixed later. | 196 | slowness may not matter to you. It can always be fixed later. |
| 197 | 197 | ||
| 198 | For devices like disk it does matter, you do not want to spindown for | 198 | For devices like disk it does matter, you do not want to spindown for |
| @@ -237,7 +237,7 @@ disk. Whole sequence goes like | |||
| 237 | 237 | ||
| 238 | running system, user asks for suspend-to-disk | 238 | running system, user asks for suspend-to-disk |
| 239 | 239 | ||
| 240 | user processes are stopped (in common case there are none, but with resume-from-initrd, noone knows) | 240 | user processes are stopped (in common case there are none, but with resume-from-initrd, no one knows) |
| 241 | 241 | ||
| 242 | read image from disk | 242 | read image from disk |
| 243 | 243 | ||
diff --git a/Documentation/power/userland-swsusp.txt b/Documentation/power/userland-swsusp.txt index 81680f9f5909..1101bee4e822 100644 --- a/Documentation/power/userland-swsusp.txt +++ b/Documentation/power/userland-swsusp.txt | |||
| @@ -98,7 +98,7 @@ SNAPSHOT_S2RAM - suspend to RAM; using this call causes the kernel to | |||
| 98 | The device's read() operation can be used to transfer the snapshot image from | 98 | The device's read() operation can be used to transfer the snapshot image from |
| 99 | the kernel. It has the following limitations: | 99 | the kernel. It has the following limitations: |
| 100 | - you cannot read() more than one virtual memory page at a time | 100 | - you cannot read() more than one virtual memory page at a time |
| 101 | - read()s accross page boundaries are impossible (ie. if ypu read() 1/2 of | 101 | - read()s across page boundaries are impossible (ie. if ypu read() 1/2 of |
| 102 | a page in the previous call, you will only be able to read() | 102 | a page in the previous call, you will only be able to read() |
| 103 | _at_ _most_ 1/2 of the page in the next call) | 103 | _at_ _most_ 1/2 of the page in the next call) |
| 104 | 104 | ||
| @@ -137,7 +137,7 @@ mechanism and the userland utilities using the interface SHOULD use additional | |||
| 137 | means, such as checksums, to ensure the integrity of the snapshot image. | 137 | means, such as checksums, to ensure the integrity of the snapshot image. |
| 138 | 138 | ||
| 139 | The suspending and resuming utilities MUST lock themselves in memory, | 139 | The suspending and resuming utilities MUST lock themselves in memory, |
| 140 | preferrably using mlockall(), before calling SNAPSHOT_FREEZE. | 140 | preferably using mlockall(), before calling SNAPSHOT_FREEZE. |
| 141 | 141 | ||
| 142 | The suspending utility MUST check the value stored by SNAPSHOT_CREATE_IMAGE | 142 | The suspending utility MUST check the value stored by SNAPSHOT_CREATE_IMAGE |
| 143 | in the memory location pointed to by the last argument of ioctl() and proceed | 143 | in the memory location pointed to by the last argument of ioctl() and proceed |
| @@ -147,7 +147,7 @@ in accordance with it: | |||
| 147 | (a) The suspending utility MUST NOT close the snapshot device | 147 | (a) The suspending utility MUST NOT close the snapshot device |
| 148 | _unless_ the whole suspend procedure is to be cancelled, in | 148 | _unless_ the whole suspend procedure is to be cancelled, in |
| 149 | which case, if the snapshot image has already been saved, the | 149 | which case, if the snapshot image has already been saved, the |
| 150 | suspending utility SHOULD destroy it, preferrably by zapping | 150 | suspending utility SHOULD destroy it, preferably by zapping |
| 151 | its header. If the suspend is not to be cancelled, the | 151 | its header. If the suspend is not to be cancelled, the |
| 152 | system MUST be powered off or rebooted after the snapshot | 152 | system MUST be powered off or rebooted after the snapshot |
| 153 | image has been saved. | 153 | image has been saved. |
diff --git a/Documentation/powerpc/00-INDEX b/Documentation/powerpc/00-INDEX index e3960b8c8689..5620fb5ac425 100644 --- a/Documentation/powerpc/00-INDEX +++ b/Documentation/powerpc/00-INDEX | |||
| @@ -5,8 +5,6 @@ please mail me. | |||
| 5 | 5 | ||
| 6 | 00-INDEX | 6 | 00-INDEX |
| 7 | - this file | 7 | - this file |
| 8 | booting-without-of.txt | ||
| 9 | - Booting the Linux/ppc kernel without Open Firmware | ||
| 10 | cpu_features.txt | 8 | cpu_features.txt |
| 11 | - info on how we support a variety of CPUs with minimal compile-time | 9 | - info on how we support a variety of CPUs with minimal compile-time |
| 12 | options. | 10 | options. |
| @@ -16,8 +14,6 @@ hvcs.txt | |||
| 16 | - IBM "Hypervisor Virtual Console Server" Installation Guide | 14 | - IBM "Hypervisor Virtual Console Server" Installation Guide |
| 17 | mpc52xx.txt | 15 | mpc52xx.txt |
| 18 | - Linux 2.6.x on MPC52xx family | 16 | - Linux 2.6.x on MPC52xx family |
| 19 | mpc52xx-device-tree-bindings.txt | ||
| 20 | - MPC5200 Device Tree Bindings | ||
| 21 | sound.txt | 17 | sound.txt |
| 22 | - info on sound support under Linux/PPC | 18 | - info on sound support under Linux/PPC |
| 23 | zImage_layout.txt | 19 | zImage_layout.txt |
diff --git a/Documentation/powerpc/dts-bindings/fsl/mpic.txt b/Documentation/powerpc/dts-bindings/fsl/mpic.txt deleted file mode 100644 index 71e39cf3215b..000000000000 --- a/Documentation/powerpc/dts-bindings/fsl/mpic.txt +++ /dev/null | |||
| @@ -1,42 +0,0 @@ | |||
| 1 | * OpenPIC and its interrupt numbers on Freescale's e500/e600 cores | ||
| 2 | |||
| 3 | The OpenPIC specification does not specify which interrupt source has to | ||
| 4 | become which interrupt number. This is up to the software implementation | ||
| 5 | of the interrupt controller. The only requirement is that every | ||
| 6 | interrupt source has to have an unique interrupt number / vector number. | ||
| 7 | To accomplish this the current implementation assigns the number zero to | ||
| 8 | the first source, the number one to the second source and so on until | ||
| 9 | all interrupt sources have their unique number. | ||
| 10 | Usually the assigned vector number equals the interrupt number mentioned | ||
| 11 | in the documentation for a given core / CPU. This is however not true | ||
| 12 | for the e500 cores (MPC85XX CPUs) where the documentation distinguishes | ||
| 13 | between internal and external interrupt sources and starts counting at | ||
| 14 | zero for both of them. | ||
| 15 | |||
| 16 | So what to write for external interrupt source X or internal interrupt | ||
| 17 | source Y into the device tree? Here is an example: | ||
| 18 | |||
| 19 | The memory map for the interrupt controller in the MPC8544[0] shows, | ||
| 20 | that the first interrupt source starts at 0x5_0000 (PIC Register Address | ||
| 21 | Map-Interrupt Source Configuration Registers). This source becomes the | ||
| 22 | number zero therefore: | ||
| 23 | External interrupt 0 = interrupt number 0 | ||
| 24 | External interrupt 1 = interrupt number 1 | ||
| 25 | External interrupt 2 = interrupt number 2 | ||
| 26 | ... | ||
| 27 | Every interrupt number allocates 0x20 bytes register space. So to get | ||
| 28 | its number it is sufficient to shift the lower 16bits to right by five. | ||
| 29 | So for the external interrupt 10 we have: | ||
| 30 | 0x0140 >> 5 = 10 | ||
| 31 | |||
| 32 | After the external sources, the internal sources follow. The in core I2C | ||
| 33 | controller on the MPC8544 for instance has the internal source number | ||
| 34 | 27. Oo obtain its interrupt number we take the lower 16bits of its memory | ||
| 35 | address (0x5_0560) and shift it right: | ||
| 36 | 0x0560 >> 5 = 43 | ||
| 37 | |||
| 38 | Therefore the I2C device node for the MPC8544 CPU has to have the | ||
| 39 | interrupt number 43 specified in the device tree. | ||
| 40 | |||
| 41 | [0] MPC8544E PowerQUICCTM III, Integrated Host Processor Family Reference Manual | ||
| 42 | MPC8544ERM Rev. 1 10/2007 | ||
diff --git a/Documentation/powerpc/hvcs.txt b/Documentation/powerpc/hvcs.txt index 6d8be3468d7d..a730ca5a07f8 100644 --- a/Documentation/powerpc/hvcs.txt +++ b/Documentation/powerpc/hvcs.txt | |||
| @@ -528,7 +528,7 @@ this driver assignment of hotplug added vty-servers may be in a different | |||
| 528 | order than how they would be exposed on module load. Rebooting or | 528 | order than how they would be exposed on module load. Rebooting or |
| 529 | reloading the module after dynamic addition may result in the /dev/hvcs* | 529 | reloading the module after dynamic addition may result in the /dev/hvcs* |
| 530 | and vty-server coupling changing if a vty-server adapter was added in a | 530 | and vty-server coupling changing if a vty-server adapter was added in a |
| 531 | slot inbetween two other vty-server adapters. Refer to the section above | 531 | slot between two other vty-server adapters. Refer to the section above |
| 532 | on how to determine which vty-server goes with which /dev/hvcs* node. | 532 | on how to determine which vty-server goes with which /dev/hvcs* node. |
| 533 | Hint; look at the sysfs "index" attribute for the vty-server. | 533 | Hint; look at the sysfs "index" attribute for the vty-server. |
| 534 | 534 | ||
diff --git a/Documentation/rapidio/rapidio.txt b/Documentation/rapidio/rapidio.txt new file mode 100644 index 000000000000..be70ee15f8ca --- /dev/null +++ b/Documentation/rapidio/rapidio.txt | |||
| @@ -0,0 +1,173 @@ | |||
| 1 | The Linux RapidIO Subsystem | ||
| 2 | |||
| 3 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
| 4 | |||
| 5 | The RapidIO standard is a packet-based fabric interconnect standard designed for | ||
| 6 | use in embedded systems. Development of the RapidIO standard is directed by the | ||
| 7 | RapidIO Trade Association (RTA). The current version of the RapidIO specification | ||
| 8 | is publicly available for download from the RTA web-site [1]. | ||
| 9 | |||
| 10 | This document describes the basics of the Linux RapidIO subsystem and provides | ||
| 11 | information on its major components. | ||
| 12 | |||
| 13 | 1 Overview | ||
| 14 | ---------- | ||
| 15 | |||
| 16 | Because the RapidIO subsystem follows the Linux device model it is integrated | ||
| 17 | into the kernel similarly to other buses by defining RapidIO-specific device and | ||
| 18 | bus types and registering them within the device model. | ||
| 19 | |||
| 20 | The Linux RapidIO subsystem is architecture independent and therefore defines | ||
| 21 | architecture-specific interfaces that provide support for common RapidIO | ||
| 22 | subsystem operations. | ||
| 23 | |||
| 24 | 2. Core Components | ||
| 25 | ------------------ | ||
| 26 | |||
| 27 | A typical RapidIO network is a combination of endpoints and switches. | ||
| 28 | Each of these components is represented in the subsystem by an associated data | ||
| 29 | structure. The core logical components of the RapidIO subsystem are defined | ||
| 30 | in include/linux/rio.h file. | ||
| 31 | |||
| 32 | 2.1 Master Port | ||
| 33 | |||
| 34 | A master port (or mport) is a RapidIO interface controller that is local to the | ||
| 35 | processor executing the Linux code. A master port generates and receives RapidIO | ||
| 36 | packets (transactions). In the RapidIO subsystem each master port is represented | ||
| 37 | by a rio_mport data structure. This structure contains master port specific | ||
| 38 | resources such as mailboxes and doorbells. The rio_mport also includes a unique | ||
| 39 | host device ID that is valid when a master port is configured as an enumerating | ||
| 40 | host. | ||
| 41 | |||
| 42 | RapidIO master ports are serviced by subsystem specific mport device drivers | ||
| 43 | that provide functionality defined for this subsystem. To provide a hardware | ||
| 44 | independent interface for RapidIO subsystem operations, rio_mport structure | ||
| 45 | includes rio_ops data structure which contains pointers to hardware specific | ||
| 46 | implementations of RapidIO functions. | ||
| 47 | |||
| 48 | 2.2 Device | ||
| 49 | |||
| 50 | A RapidIO device is any endpoint (other than mport) or switch in the network. | ||
| 51 | All devices are presented in the RapidIO subsystem by corresponding rio_dev data | ||
| 52 | structure. Devices form one global device list and per-network device lists | ||
| 53 | (depending on number of available mports and networks). | ||
| 54 | |||
| 55 | 2.3 Switch | ||
| 56 | |||
| 57 | A RapidIO switch is a special class of device that routes packets between its | ||
| 58 | ports towards their final destination. The packet destination port within a | ||
| 59 | switch is defined by an internal routing table. A switch is presented in the | ||
| 60 | RapidIO subsystem by rio_dev data structure expanded by additional rio_switch | ||
| 61 | data structure, which contains switch specific information such as copy of the | ||
| 62 | routing table and pointers to switch specific functions. | ||
| 63 | |||
| 64 | The RapidIO subsystem defines the format and initialization method for subsystem | ||
| 65 | specific switch drivers that are designed to provide hardware-specific | ||
| 66 | implementation of common switch management routines. | ||
| 67 | |||
| 68 | 2.4 Network | ||
| 69 | |||
| 70 | A RapidIO network is a combination of interconnected endpoint and switch devices. | ||
| 71 | Each RapidIO network known to the system is represented by corresponding rio_net | ||
| 72 | data structure. This structure includes lists of all devices and local master | ||
| 73 | ports that form the same network. It also contains a pointer to the default | ||
| 74 | master port that is used to communicate with devices within the network. | ||
| 75 | |||
| 76 | 3. Subsystem Initialization | ||
| 77 | --------------------------- | ||
| 78 | |||
| 79 | In order to initialize the RapidIO subsystem, a platform must initialize and | ||
| 80 | register at least one master port within the RapidIO network. To register mport | ||
| 81 | within the subsystem controller driver initialization code calls function | ||
| 82 | rio_register_mport() for each available master port. After all active master | ||
| 83 | ports are registered with a RapidIO subsystem, the rio_init_mports() routine | ||
| 84 | is called to perform enumeration and discovery. | ||
| 85 | |||
| 86 | In the current PowerPC-based implementation a subsys_initcall() is specified to | ||
| 87 | perform controller initialization and mport registration. At the end it directly | ||
| 88 | calls rio_init_mports() to execute RapidIO enumeration and discovery. | ||
| 89 | |||
| 90 | 4. Enumeration and Discovery | ||
| 91 | ---------------------------- | ||
| 92 | |||
| 93 | When rio_init_mports() is called it scans a list of registered master ports and | ||
| 94 | calls an enumeration or discovery routine depending on the configured role of a | ||
| 95 | master port: host or agent. | ||
| 96 | |||
| 97 | Enumeration is performed by a master port if it is configured as a host port by | ||
| 98 | assigning a host device ID greater than or equal to zero. A host device ID is | ||
| 99 | assigned to a master port through the kernel command line parameter "riohdid=", | ||
| 100 | or can be configured in a platform-specific manner. If the host device ID for | ||
| 101 | a specific master port is set to -1, the discovery process will be performed | ||
| 102 | for it. | ||
| 103 | |||
| 104 | The enumeration and discovery routines use RapidIO maintenance transactions | ||
| 105 | to access the configuration space of devices. | ||
| 106 | |||
| 107 | The enumeration process is implemented according to the enumeration algorithm | ||
| 108 | outlined in the RapidIO Interconnect Specification: Annex I [1]. | ||
| 109 | |||
| 110 | The enumeration process traverses the network using a recursive depth-first | ||
| 111 | algorithm. When a new device is found, the enumerator takes ownership of that | ||
| 112 | device by writing into the Host Device ID Lock CSR. It does this to ensure that | ||
| 113 | the enumerator has exclusive right to enumerate the device. If device ownership | ||
| 114 | is successfully acquired, the enumerator allocates a new rio_dev structure and | ||
| 115 | initializes it according to device capabilities. | ||
| 116 | |||
| 117 | If the device is an endpoint, a unique device ID is assigned to it and its value | ||
| 118 | is written into the device's Base Device ID CSR. | ||
| 119 | |||
| 120 | If the device is a switch, the enumerator allocates an additional rio_switch | ||
| 121 | structure to store switch specific information. Then the switch's vendor ID and | ||
| 122 | device ID are queried against a table of known RapidIO switches. Each switch | ||
| 123 | table entry contains a pointer to a switch-specific initialization routine that | ||
| 124 | initializes pointers to the rest of switch specific operations, and performs | ||
| 125 | hardware initialization if necessary. A RapidIO switch does not have a unique | ||
| 126 | device ID; it relies on hopcount and routing for device ID of an attached | ||
| 127 | endpoint if access to its configuration registers is required. If a switch (or | ||
| 128 | chain of switches) does not have any endpoint (except enumerator) attached to | ||
| 129 | it, a fake device ID will be assigned to configure a route to that switch. | ||
| 130 | In the case of a chain of switches without endpoint, one fake device ID is used | ||
| 131 | to configure a route through the entire chain and switches are differentiated by | ||
| 132 | their hopcount value. | ||
| 133 | |||
| 134 | For both endpoints and switches the enumerator writes a unique component tag | ||
| 135 | into device's Component Tag CSR. That unique value is used by the error | ||
| 136 | management notification mechanism to identify a device that is reporting an | ||
| 137 | error management event. | ||
| 138 | |||
| 139 | Enumeration beyond a switch is completed by iterating over each active egress | ||
| 140 | port of that switch. For each active link, a route to a default device ID | ||
| 141 | (0xFF for 8-bit systems and 0xFFFF for 16-bit systems) is temporarily written | ||
| 142 | into the routing table. The algorithm recurs by calling itself with hopcount + 1 | ||
| 143 | and the default device ID in order to access the device on the active port. | ||
| 144 | |||
| 145 | After the host has completed enumeration of the entire network it releases | ||
| 146 | devices by clearing device ID locks (calls rio_clear_locks()). For each endpoint | ||
| 147 | in the system, it sets the Master Enable bit in the Port General Control CSR | ||
| 148 | to indicate that enumeration is completed and agents are allowed to execute | ||
| 149 | passive discovery of the network. | ||
| 150 | |||
| 151 | The discovery process is performed by agents and is similar to the enumeration | ||
| 152 | process that is described above. However, the discovery process is performed | ||
| 153 | without changes to the existing routing because agents only gather information | ||
| 154 | about RapidIO network structure and are building an internal map of discovered | ||
| 155 | devices. This way each Linux-based component of the RapidIO subsystem has | ||
| 156 | a complete view of the network. The discovery process can be performed | ||
| 157 | simultaneously by several agents. After initializing its RapidIO master port | ||
| 158 | each agent waits for enumeration completion by the host for the configured wait | ||
| 159 | time period. If this wait time period expires before enumeration is completed, | ||
| 160 | an agent skips RapidIO discovery and continues with remaining kernel | ||
| 161 | initialization. | ||
| 162 | |||
| 163 | 5. References | ||
| 164 | ------------- | ||
| 165 | |||
| 166 | [1] RapidIO Trade Association. RapidIO Interconnect Specifications. | ||
| 167 | http://www.rapidio.org. | ||
| 168 | [2] Rapidio TA. Technology Comparisons. | ||
| 169 | http://www.rapidio.org/education/technology_comparisons/ | ||
| 170 | [3] RapidIO support for Linux. | ||
| 171 | http://lwn.net/Articles/139118/ | ||
| 172 | [4] Matt Porter. RapidIO for Linux. Ottawa Linux Symposium, 2005 | ||
| 173 | http://www.kernel.org/doc/ols/2005/ols2005v2-pages-43-56.pdf | ||
diff --git a/Documentation/rapidio/sysfs.txt b/Documentation/rapidio/sysfs.txt new file mode 100644 index 000000000000..97f71ce575d6 --- /dev/null +++ b/Documentation/rapidio/sysfs.txt | |||
| @@ -0,0 +1,90 @@ | |||
| 1 | RapidIO sysfs Files | ||
| 2 | |||
| 3 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
| 4 | |||
| 5 | 1. Device Subdirectories | ||
| 6 | ------------------------ | ||
| 7 | |||
| 8 | For each RapidIO device, the RapidIO subsystem creates files in an individual | ||
| 9 | subdirectory with the following name, /sys/bus/rapidio/devices/<device_name>. | ||
| 10 | |||
| 11 | The format of device_name is "nn:d:iiii", where: | ||
| 12 | |||
| 13 | nn - two-digit hexadecimal ID of RapidIO network where the device resides | ||
| 14 | d - device typr: 'e' - for endpoint or 's' - for switch | ||
| 15 | iiii - four-digit device destID for endpoints, or switchID for switches | ||
| 16 | |||
| 17 | For example, below is a list of device directories that represents a typical | ||
| 18 | RapidIO network with one switch, one host, and two agent endpoints, as it is | ||
| 19 | seen by the enumerating host (destID = 1): | ||
| 20 | |||
| 21 | /sys/bus/rapidio/devices/00:e:0000 | ||
| 22 | /sys/bus/rapidio/devices/00:e:0002 | ||
| 23 | /sys/bus/rapidio/devices/00:s:0001 | ||
| 24 | |||
| 25 | NOTE: An enumerating or discovering endpoint does not create a sysfs entry for | ||
| 26 | itself, this is why an endpoint with destID=1 is not shown in the list. | ||
| 27 | |||
| 28 | 2. Attributes Common for All Devices | ||
| 29 | ------------------------------------ | ||
| 30 | |||
| 31 | Each device subdirectory contains the following informational read-only files: | ||
| 32 | |||
| 33 | did - returns the device identifier | ||
| 34 | vid - returns the device vendor identifier | ||
| 35 | device_rev - returns the device revision level | ||
| 36 | asm_did - returns identifier for the assembly containing the device | ||
| 37 | asm_rev - returns revision level of the assembly containing the device | ||
| 38 | asm_vid - returns vendor identifier of the assembly containing the device | ||
| 39 | destid - returns device destination ID assigned by the enumeration routine | ||
| 40 | (see 4.1 for switch specific details) | ||
| 41 | lprev - returns name of previous device (switch) on the path to the device | ||
| 42 | that that owns this attribute | ||
| 43 | |||
| 44 | In addition to the files listed above, each device has a binary attribute file | ||
| 45 | that allows read/write access to the device configuration registers using | ||
| 46 | the RapidIO maintenance transactions: | ||
| 47 | |||
| 48 | config - reads from and writes to the device configuration registers. | ||
| 49 | |||
| 50 | This attribute is similar in behavior to the "config" attribute of PCI devices | ||
| 51 | and provides an access to the RapidIO device registers using standard file read | ||
| 52 | and write operations. | ||
| 53 | |||
| 54 | 3. Endpoint Device Attributes | ||
| 55 | ----------------------------- | ||
| 56 | |||
| 57 | Currently Linux RapidIO subsystem does not create any endpoint specific sysfs | ||
| 58 | attributes. It is possible that RapidIO master port drivers and endpoint device | ||
| 59 | drivers will add their device-specific sysfs attributes but such attributes are | ||
| 60 | outside the scope of this document. | ||
| 61 | |||
| 62 | 4. Switch Device Attributes | ||
| 63 | --------------------------- | ||
| 64 | |||
| 65 | RapidIO switches have additional attributes in sysfs. RapidIO subsystem supports | ||
| 66 | common and device-specific sysfs attributes for switches. Because switches are | ||
| 67 | integrated into the RapidIO subsystem, it offers a method to create | ||
| 68 | device-specific sysfs attributes by specifying a callback function that may be | ||
| 69 | set by the switch initialization routine during enumeration or discovery process. | ||
| 70 | |||
| 71 | 4.1 Common Switch Attributes | ||
| 72 | |||
| 73 | routes - reports switch routing information in "destID port" format. This | ||
| 74 | attribute reports only valid routing table entries, one line for | ||
| 75 | each entry. | ||
| 76 | destid - device destination ID that defines a route to the switch | ||
| 77 | hopcount - number of hops on the path to the switch | ||
| 78 | lnext - returns names of devices linked to the switch except one of a device | ||
| 79 | linked to the ingress port (reported as "lprev"). This is an array | ||
| 80 | names with number of lines equal to number of ports in switch. If | ||
| 81 | a switch port has no attached device, returns "null" instead of | ||
| 82 | a device name. | ||
| 83 | |||
| 84 | 4.2 Device-specific Switch Attributes | ||
| 85 | |||
| 86 | Device-specific switch attributes are listed for each RapidIO switch driver | ||
| 87 | that exports additional attributes. | ||
| 88 | |||
| 89 | IDT_GEN2: | ||
| 90 | errlog - reads contents of device error log until it is empty. | ||
diff --git a/Documentation/rtc.txt b/Documentation/rtc.txt index 9104c1062084..250160469d83 100644 --- a/Documentation/rtc.txt +++ b/Documentation/rtc.txt | |||
| @@ -178,38 +178,29 @@ RTC class framework, but can't be supported by the older driver. | |||
| 178 | setting the longer alarm time and enabling its IRQ using a single | 178 | setting the longer alarm time and enabling its IRQ using a single |
| 179 | request (using the same model as EFI firmware). | 179 | request (using the same model as EFI firmware). |
| 180 | 180 | ||
| 181 | * RTC_UIE_ON, RTC_UIE_OFF ... if the RTC offers IRQs, it probably | 181 | * RTC_UIE_ON, RTC_UIE_OFF ... if the RTC offers IRQs, the RTC framework |
| 182 | also offers update IRQs whenever the "seconds" counter changes. | 182 | will emulate this mechanism. |
| 183 | If needed, the RTC framework can emulate this mechanism. | ||
| 184 | 183 | ||
| 185 | * RTC_PIE_ON, RTC_PIE_OFF, RTC_IRQP_SET, RTC_IRQP_READ ... another | 184 | * RTC_PIE_ON, RTC_PIE_OFF, RTC_IRQP_SET, RTC_IRQP_READ ... these icotls |
| 186 | feature often accessible with an IRQ line is a periodic IRQ, issued | 185 | are emulated via a kernel hrtimer. |
| 187 | at settable frequencies (usually 2^N Hz). | ||
| 188 | 186 | ||
| 189 | In many cases, the RTC alarm can be a system wake event, used to force | 187 | In many cases, the RTC alarm can be a system wake event, used to force |
| 190 | Linux out of a low power sleep state (or hibernation) back to a fully | 188 | Linux out of a low power sleep state (or hibernation) back to a fully |
| 191 | operational state. For example, a system could enter a deep power saving | 189 | operational state. For example, a system could enter a deep power saving |
| 192 | state until it's time to execute some scheduled tasks. | 190 | state until it's time to execute some scheduled tasks. |
| 193 | 191 | ||
| 194 | Note that many of these ioctls need not actually be implemented by your | 192 | Note that many of these ioctls are handled by the common rtc-dev interface. |
| 195 | driver. The common rtc-dev interface handles many of these nicely if your | 193 | Some common examples: |
| 196 | driver returns ENOIOCTLCMD. Some common examples: | ||
| 197 | 194 | ||
| 198 | * RTC_RD_TIME, RTC_SET_TIME: the read_time/set_time functions will be | 195 | * RTC_RD_TIME, RTC_SET_TIME: the read_time/set_time functions will be |
| 199 | called with appropriate values. | 196 | called with appropriate values. |
| 200 | 197 | ||
| 201 | * RTC_ALM_SET, RTC_ALM_READ, RTC_WKALM_SET, RTC_WKALM_RD: the | 198 | * RTC_ALM_SET, RTC_ALM_READ, RTC_WKALM_SET, RTC_WKALM_RD: gets or sets |
| 202 | set_alarm/read_alarm functions will be called. | 199 | the alarm rtc_timer. May call the set_alarm driver function. |
| 203 | 200 | ||
| 204 | * RTC_IRQP_SET, RTC_IRQP_READ: the irq_set_freq function will be called | 201 | * RTC_IRQP_SET, RTC_IRQP_READ: These are emulated by the generic code. |
| 205 | to set the frequency while the framework will handle the read for you | ||
| 206 | since the frequency is stored in the irq_freq member of the rtc_device | ||
| 207 | structure. Your driver needs to initialize the irq_freq member during | ||
| 208 | init. Make sure you check the requested frequency is in range of your | ||
| 209 | hardware in the irq_set_freq function. If it isn't, return -EINVAL. If | ||
| 210 | you cannot actually change the frequency, do not define irq_set_freq. | ||
| 211 | 202 | ||
| 212 | * RTC_PIE_ON, RTC_PIE_OFF: the irq_set_state function will be called. | 203 | * RTC_PIE_ON, RTC_PIE_OFF: These are also emulated by the generic code. |
| 213 | 204 | ||
| 214 | If all else fails, check out the rtc-test.c driver! | 205 | If all else fails, check out the rtc-test.c driver! |
| 215 | 206 | ||
diff --git a/Documentation/s390/Debugging390.txt b/Documentation/s390/Debugging390.txt index 86f9f74b2b34..efe998becc5b 100644 --- a/Documentation/s390/Debugging390.txt +++ b/Documentation/s390/Debugging390.txt | |||
| @@ -2273,7 +2273,7 @@ IP forwarding is on. | |||
| 2273 | There is a lot of useful info in here best found by going in & having a look around, | 2273 | There is a lot of useful info in here best found by going in & having a look around, |
| 2274 | so I'll take you through some entries I consider important. | 2274 | so I'll take you through some entries I consider important. |
| 2275 | 2275 | ||
| 2276 | All the processes running on the machine have there own entry defined by | 2276 | All the processes running on the machine have their own entry defined by |
| 2277 | /proc/<pid> | 2277 | /proc/<pid> |
| 2278 | So lets have a look at the init process | 2278 | So lets have a look at the init process |
| 2279 | cd /proc/1 | 2279 | cd /proc/1 |
diff --git a/Documentation/scheduler/sched-design-CFS.txt b/Documentation/scheduler/sched-design-CFS.txt index 8239ebbcddce..99961993257a 100644 --- a/Documentation/scheduler/sched-design-CFS.txt +++ b/Documentation/scheduler/sched-design-CFS.txt | |||
| @@ -164,7 +164,7 @@ This is the (partial) list of the hooks: | |||
| 164 | It puts the scheduling entity (task) into the red-black tree and | 164 | It puts the scheduling entity (task) into the red-black tree and |
| 165 | increments the nr_running variable. | 165 | increments the nr_running variable. |
| 166 | 166 | ||
| 167 | - dequeue_tree(...) | 167 | - dequeue_task(...) |
| 168 | 168 | ||
| 169 | When a task is no longer runnable, this function is called to keep the | 169 | When a task is no longer runnable, this function is called to keep the |
| 170 | corresponding scheduling entity out of the red-black tree. It decrements | 170 | corresponding scheduling entity out of the red-black tree. It decrements |
| @@ -195,11 +195,6 @@ This is the (partial) list of the hooks: | |||
| 195 | This function is mostly called from time tick functions; it might lead to | 195 | This function is mostly called from time tick functions; it might lead to |
| 196 | process switch. This drives the running preemption. | 196 | process switch. This drives the running preemption. |
| 197 | 197 | ||
| 198 | - task_new(...) | ||
| 199 | |||
| 200 | The core scheduler gives the scheduling module an opportunity to manage new | ||
| 201 | task startup. The CFS scheduling module uses it for group scheduling, while | ||
| 202 | the scheduling module for a real-time task does not use it. | ||
| 203 | 198 | ||
| 204 | 199 | ||
| 205 | 200 | ||
diff --git a/Documentation/scheduler/sched-domains.txt b/Documentation/scheduler/sched-domains.txt index 373ceacc367e..b7ee379b651b 100644 --- a/Documentation/scheduler/sched-domains.txt +++ b/Documentation/scheduler/sched-domains.txt | |||
| @@ -1,8 +1,7 @@ | |||
| 1 | Each CPU has a "base" scheduling domain (struct sched_domain). These are | 1 | Each CPU has a "base" scheduling domain (struct sched_domain). The domain |
| 2 | accessed via cpu_sched_domain(i) and this_sched_domain() macros. The domain | ||
| 3 | hierarchy is built from these base domains via the ->parent pointer. ->parent | 2 | hierarchy is built from these base domains via the ->parent pointer. ->parent |
| 4 | MUST be NULL terminated, and domain structures should be per-CPU as they | 3 | MUST be NULL terminated, and domain structures should be per-CPU as they are |
| 5 | are locklessly updated. | 4 | locklessly updated. |
| 6 | 5 | ||
| 7 | Each scheduling domain spans a number of CPUs (stored in the ->span field). | 6 | Each scheduling domain spans a number of CPUs (stored in the ->span field). |
| 8 | A domain's span MUST be a superset of it child's span (this restriction could | 7 | A domain's span MUST be a superset of it child's span (this restriction could |
| @@ -26,11 +25,26 @@ is treated as one entity. The load of a group is defined as the sum of the | |||
| 26 | load of each of its member CPUs, and only when the load of a group becomes | 25 | load of each of its member CPUs, and only when the load of a group becomes |
| 27 | out of balance are tasks moved between groups. | 26 | out of balance are tasks moved between groups. |
| 28 | 27 | ||
| 29 | In kernel/sched.c, rebalance_tick is run periodically on each CPU. This | 28 | In kernel/sched.c, trigger_load_balance() is run periodically on each CPU |
| 30 | function takes its CPU's base sched domain and checks to see if has reached | 29 | through scheduler_tick(). It raises a softirq after the next regularly scheduled |
| 31 | its rebalance interval. If so, then it will run load_balance on that domain. | 30 | rebalancing event for the current runqueue has arrived. The actual load |
| 32 | rebalance_tick then checks the parent sched_domain (if it exists), and the | 31 | balancing workhorse, run_rebalance_domains()->rebalance_domains(), is then run |
| 33 | parent of the parent and so forth. | 32 | in softirq context (SCHED_SOFTIRQ). |
| 33 | |||
| 34 | The latter function takes two arguments: the current CPU and whether it was idle | ||
| 35 | at the time the scheduler_tick() happened and iterates over all sched domains | ||
| 36 | our CPU is on, starting from its base domain and going up the ->parent chain. | ||
| 37 | While doing that, it checks to see if the current domain has exhausted its | ||
| 38 | rebalance interval. If so, it runs load_balance() on that domain. It then checks | ||
| 39 | the parent sched_domain (if it exists), and the parent of the parent and so | ||
| 40 | forth. | ||
| 41 | |||
| 42 | Initially, load_balance() finds the busiest group in the current sched domain. | ||
| 43 | If it succeeds, it looks for the busiest runqueue of all the CPUs' runqueues in | ||
| 44 | that group. If it manages to find such a runqueue, it locks both our initial | ||
| 45 | CPU's runqueue and the newly found busiest one and starts moving tasks from it | ||
| 46 | to our runqueue. The exact number of tasks amounts to an imbalance previously | ||
| 47 | computed while iterating over this sched domain's groups. | ||
| 34 | 48 | ||
| 35 | *** Implementing sched domains *** | 49 | *** Implementing sched domains *** |
| 36 | The "base" domain will "span" the first level of the hierarchy. In the case | 50 | The "base" domain will "span" the first level of the hierarchy. In the case |
diff --git a/Documentation/scheduler/sched-stats.txt b/Documentation/scheduler/sched-stats.txt index 01e69404ee5e..1cd5d51bc761 100644 --- a/Documentation/scheduler/sched-stats.txt +++ b/Documentation/scheduler/sched-stats.txt | |||
| @@ -1,3 +1,7 @@ | |||
| 1 | Version 15 of schedstats dropped counters for some sched_yield: | ||
| 2 | yld_exp_empty, yld_act_empty and yld_both_empty. Otherwise, it is | ||
| 3 | identical to version 14. | ||
| 4 | |||
| 1 | Version 14 of schedstats includes support for sched_domains, which hit the | 5 | Version 14 of schedstats includes support for sched_domains, which hit the |
| 2 | mainline kernel in 2.6.20 although it is identical to the stats from version | 6 | mainline kernel in 2.6.20 although it is identical to the stats from version |
| 3 | 12 which was in the kernel from 2.6.13-2.6.19 (version 13 never saw a kernel | 7 | 12 which was in the kernel from 2.6.13-2.6.19 (version 13 never saw a kernel |
| @@ -28,32 +32,25 @@ to write their own scripts, the fields are described here. | |||
| 28 | 32 | ||
| 29 | CPU statistics | 33 | CPU statistics |
| 30 | -------------- | 34 | -------------- |
| 31 | cpu<N> 1 2 3 4 5 6 7 8 9 10 11 12 | 35 | cpu<N> 1 2 3 4 5 6 7 8 9 |
| 32 | |||
| 33 | NOTE: In the sched_yield() statistics, the active queue is considered empty | ||
| 34 | if it has only one process in it, since obviously the process calling | ||
| 35 | sched_yield() is that process. | ||
| 36 | 36 | ||
| 37 | First four fields are sched_yield() statistics: | 37 | First field is a sched_yield() statistic: |
| 38 | 1) # of times both the active and the expired queue were empty | 38 | 1) # of times sched_yield() was called |
| 39 | 2) # of times just the active queue was empty | ||
| 40 | 3) # of times just the expired queue was empty | ||
| 41 | 4) # of times sched_yield() was called | ||
| 42 | 39 | ||
| 43 | Next three are schedule() statistics: | 40 | Next three are schedule() statistics: |
| 44 | 5) # of times we switched to the expired queue and reused it | 41 | 2) # of times we switched to the expired queue and reused it |
| 45 | 6) # of times schedule() was called | 42 | 3) # of times schedule() was called |
| 46 | 7) # of times schedule() left the processor idle | 43 | 4) # of times schedule() left the processor idle |
| 47 | 44 | ||
| 48 | Next two are try_to_wake_up() statistics: | 45 | Next two are try_to_wake_up() statistics: |
| 49 | 8) # of times try_to_wake_up() was called | 46 | 5) # of times try_to_wake_up() was called |
| 50 | 9) # of times try_to_wake_up() was called to wake up the local cpu | 47 | 6) # of times try_to_wake_up() was called to wake up the local cpu |
| 51 | 48 | ||
| 52 | Next three are statistics describing scheduling latency: | 49 | Next three are statistics describing scheduling latency: |
| 53 | 10) sum of all time spent running by tasks on this processor (in jiffies) | 50 | 7) sum of all time spent running by tasks on this processor (in jiffies) |
| 54 | 11) sum of all time spent waiting to run by tasks on this processor (in | 51 | 8) sum of all time spent waiting to run by tasks on this processor (in |
| 55 | jiffies) | 52 | jiffies) |
| 56 | 12) # of timeslices run on this cpu | 53 | 9) # of timeslices run on this cpu |
| 57 | 54 | ||
| 58 | 55 | ||
| 59 | Domain statistics | 56 | Domain statistics |
diff --git a/Documentation/scsi/ChangeLog.lpfc b/Documentation/scsi/ChangeLog.lpfc index 5e83769c6aa9..c56ec99d7b2f 100644 --- a/Documentation/scsi/ChangeLog.lpfc +++ b/Documentation/scsi/ChangeLog.lpfc | |||
| @@ -352,7 +352,7 @@ Changes from 20041229 to 20050110 | |||
| 352 | lpfc_scsiport.c | 352 | lpfc_scsiport.c |
| 353 | * In remote port changes: no longer nulling target->pnode when | 353 | * In remote port changes: no longer nulling target->pnode when |
| 354 | removing from mapped list. Pnode get nulled when the node is | 354 | removing from mapped list. Pnode get nulled when the node is |
| 355 | freed (after nodev tmo). This bug was causing i/o recieved in | 355 | freed (after nodev tmo). This bug was causing i/o received in |
| 356 | the small window while the device was blocked to be errored w/ | 356 | the small window while the device was blocked to be errored w/ |
| 357 | did_no_connect. With the fix, it returns host_busy | 357 | did_no_connect. With the fix, it returns host_busy |
| 358 | (per the pre-remote port changes). | 358 | (per the pre-remote port changes). |
| @@ -530,7 +530,7 @@ Changes from 20041018 to 20041123 | |||
| 530 | coherent mappings. Note: There are more consistent mappings | 530 | coherent mappings. Note: There are more consistent mappings |
| 531 | that are using pci_dma_sync calls. Probably these should be | 531 | that are using pci_dma_sync calls. Probably these should be |
| 532 | removed as well. | 532 | removed as well. |
| 533 | * Modified lpfc_free_scsi_buf to accomodate all three scsi_buf | 533 | * Modified lpfc_free_scsi_buf to accommodate all three scsi_buf |
| 534 | free types to alleviate miscellaneous panics with cable pull | 534 | free types to alleviate miscellaneous panics with cable pull |
| 535 | testing. | 535 | testing. |
| 536 | * Set hotplug to default 0 and lpfc_target_remove to not remove | 536 | * Set hotplug to default 0 and lpfc_target_remove to not remove |
| @@ -583,7 +583,7 @@ Changes from 20041018 to 20041123 | |||
| 583 | included more than once. | 583 | included more than once. |
| 584 | * Replaced "set_current_state(TASK_UNINTERRUPTIBLE); | 584 | * Replaced "set_current_state(TASK_UNINTERRUPTIBLE); |
| 585 | schedule_timeout(timeout)" with "msleep(timeout)". | 585 | schedule_timeout(timeout)" with "msleep(timeout)". |
| 586 | * Fixnode was loosing starget when rediscovered. We saw messages | 586 | * Fixnode was losing starget when rediscovered. We saw messages |
| 587 | like: lpfc 0000:04:02.0: 0:0263 Cannot block scsi target as a | 587 | like: lpfc 0000:04:02.0: 0:0263 Cannot block scsi target as a |
| 588 | result. Moved starget field into struct lpfc_target which is | 588 | result. Moved starget field into struct lpfc_target which is |
| 589 | referenced from the node. | 589 | referenced from the node. |
| @@ -604,7 +604,7 @@ Changes from 20041018 to 20041123 | |||
| 604 | * Make 3 functions static: lpfc_get_hba_sym_node_name, | 604 | * Make 3 functions static: lpfc_get_hba_sym_node_name, |
| 605 | lpfc_intr_prep and lpfc_setup_slim_access. Move lpfc_intr_prep | 605 | lpfc_intr_prep and lpfc_setup_slim_access. Move lpfc_intr_prep |
| 606 | and lpfc_setup_slim_access so they're defined before being used. | 606 | and lpfc_setup_slim_access so they're defined before being used. |
| 607 | * Remove an unecessary list_del() in lpfc_hbadisc.c. | 607 | * Remove an unnecessary list_del() in lpfc_hbadisc.c. |
| 608 | * Set nlp_state before calling lpfc_nlp_list() since this will | 608 | * Set nlp_state before calling lpfc_nlp_list() since this will |
| 609 | potentially call fc_target_unblock which may cause a race in | 609 | potentially call fc_target_unblock which may cause a race in |
| 610 | queuecommand by releasing host_lock. | 610 | queuecommand by releasing host_lock. |
| @@ -753,7 +753,7 @@ Changes from 20040908 to 20040920 | |||
| 753 | * Changed version number to 8.0.12 | 753 | * Changed version number to 8.0.12 |
| 754 | * Removed used #defines: DEFAULT_PCI_LATENCY_CLOCKS and | 754 | * Removed used #defines: DEFAULT_PCI_LATENCY_CLOCKS and |
| 755 | PCI_LATENCY_VALUE from lpfc_hw.h. | 755 | PCI_LATENCY_VALUE from lpfc_hw.h. |
| 756 | * Changes to accomodate rnid. | 756 | * Changes to accommodate rnid. |
| 757 | * Fix RSCN handling so RSCN NS queries only effect NPorts found in | 757 | * Fix RSCN handling so RSCN NS queries only effect NPorts found in |
| 758 | RSCN data. | 758 | RSCN data. |
| 759 | * If we rcv a plogi on a NPort queued up for discovery, clear the | 759 | * If we rcv a plogi on a NPort queued up for discovery, clear the |
| @@ -813,7 +813,7 @@ Changes from 20040908 to 20040920 | |||
| 813 | counter instead, brd_no isn't reused anymore. Also some tiny | 813 | counter instead, brd_no isn't reused anymore. Also some tiny |
| 814 | whitespace cleanups in surrounding code. | 814 | whitespace cleanups in surrounding code. |
| 815 | * Reorder functions in lpfc_els.c to remove need for prototypes. | 815 | * Reorder functions in lpfc_els.c to remove need for prototypes. |
| 816 | * Removed unsed prototypes from lpfc_crtn.h - | 816 | * Removed unused prototypes from lpfc_crtn.h - |
| 817 | lpfc_ip_timeout_handler, lpfc_read_pci and lpfc_revoke. | 817 | lpfc_ip_timeout_handler, lpfc_read_pci and lpfc_revoke. |
| 818 | * Removed some unused prototypes from lpfc_crtn.h - | 818 | * Removed some unused prototypes from lpfc_crtn.h - |
| 819 | lpfc_scsi_hba_reset, lpfc_scsi_issue_inqsn, | 819 | lpfc_scsi_hba_reset, lpfc_scsi_issue_inqsn, |
| @@ -863,7 +863,7 @@ Changes from 20040823 to 20040908 | |||
| 863 | * Minimal support for SCSI flat space addressing/volume set | 863 | * Minimal support for SCSI flat space addressing/volume set |
| 864 | addressing. Use 16 bits of LUN address so that flat | 864 | addressing. Use 16 bits of LUN address so that flat |
| 865 | addressing/VSA will work. | 865 | addressing/VSA will work. |
| 866 | * Changed 2 occurences of if( 1 != f(x)) to if(f(x) != 1) | 866 | * Changed 2 occurrences of if( 1 != f(x)) to if(f(x) != 1) |
| 867 | * Drop include of lpfc_cfgparm.h. | 867 | * Drop include of lpfc_cfgparm.h. |
| 868 | * Reduce stack usage of lpfc_fdmi_cmd in lpfc_ct.c. | 868 | * Reduce stack usage of lpfc_fdmi_cmd in lpfc_ct.c. |
| 869 | * Add minimum range checking property to /sys write/store | 869 | * Add minimum range checking property to /sys write/store |
| @@ -1449,7 +1449,7 @@ Changes from 20040402 to 20040409 | |||
| 1449 | * Removed lpfc_els_chk_latt from the lpfc_config_post function. | 1449 | * Removed lpfc_els_chk_latt from the lpfc_config_post function. |
| 1450 | lpfc_els_chk_latt will enable the link event interrupts when | 1450 | lpfc_els_chk_latt will enable the link event interrupts when |
| 1451 | flogi is pending which causes two discovery state machines | 1451 | flogi is pending which causes two discovery state machines |
| 1452 | running parallely. | 1452 | running parallelly. |
| 1453 | * Add pci_disable_device to unload path. | 1453 | * Add pci_disable_device to unload path. |
| 1454 | * Move lpfc_sleep_event from lpfc_fcp.c to lpfc_util_ioctl.c | 1454 | * Move lpfc_sleep_event from lpfc_fcp.c to lpfc_util_ioctl.c |
| 1455 | * Call dma_map_single() & pci_map_single() directly instead of via | 1455 | * Call dma_map_single() & pci_map_single() directly instead of via |
| @@ -1590,7 +1590,7 @@ Changes from 20040326 to 20040402 | |||
| 1590 | ELX_WRITE_HS ELX_WRITE_HA ELX_WRITE_CA ELX_READ_HC | 1590 | ELX_WRITE_HS ELX_WRITE_HA ELX_WRITE_CA ELX_READ_HC |
| 1591 | ELX_READ_HS ELX_READ_HA ELX_READ_CA ELX_READ_MB ELX_RESET | 1591 | ELX_READ_HS ELX_READ_HA ELX_READ_CA ELX_READ_MB ELX_RESET |
| 1592 | ELX_READ_HBA ELX_INSTANCE ELX_LIP. Also introduced | 1592 | ELX_READ_HBA ELX_INSTANCE ELX_LIP. Also introduced |
| 1593 | attribute "set" to be used in conjuction with the above | 1593 | attribute "set" to be used in conjunction with the above |
| 1594 | attributes. | 1594 | attributes. |
| 1595 | * Removed DLINK, enque and deque declarations now that clock | 1595 | * Removed DLINK, enque and deque declarations now that clock |
| 1596 | doesn't use them anymore | 1596 | doesn't use them anymore |
diff --git a/Documentation/scsi/ChangeLog.megaraid b/Documentation/scsi/ChangeLog.megaraid index 5e07d320817d..d2052fdbedd2 100644 --- a/Documentation/scsi/ChangeLog.megaraid +++ b/Documentation/scsi/ChangeLog.megaraid | |||
| @@ -168,7 +168,7 @@ Older Version : 2.20.4.6 (scsi module), 2.20.2.6 (cmm module) | |||
| 168 | 168 | ||
| 169 | 1. Sorted out PCI IDs to remove megaraid support overlaps. | 169 | 1. Sorted out PCI IDs to remove megaraid support overlaps. |
| 170 | Based on the patch from Daniel, sorted out PCI IDs along with | 170 | Based on the patch from Daniel, sorted out PCI IDs along with |
| 171 | charactor node name change from 'megadev' to 'megadev_legacy' to avoid | 171 | character node name change from 'megadev' to 'megadev_legacy' to avoid |
| 172 | conflict. | 172 | conflict. |
| 173 | --- | 173 | --- |
| 174 | Hopefully we'll be getting the build restriction zapped much sooner, | 174 | Hopefully we'll be getting the build restriction zapped much sooner, |
diff --git a/Documentation/scsi/ChangeLog.megaraid_sas b/Documentation/scsi/ChangeLog.megaraid_sas index b64d10d221ec..4d9ce73ff730 100644 --- a/Documentation/scsi/ChangeLog.megaraid_sas +++ b/Documentation/scsi/ChangeLog.megaraid_sas | |||
| @@ -1,3 +1,26 @@ | |||
| 1 | Release Date : Thu. Feb 24, 2011 17:00:00 PST 2010 - | ||
| 2 | (emaild-id:megaraidlinux@lsi.com) | ||
| 3 | Adam Radford | ||
| 4 | Current Version : 00.00.05.34-rc1 | ||
| 5 | Old Version : 00.00.05.29-rc1 | ||
| 6 | 1. Fix some failure gotos from megasas_probe_one(), etc. | ||
| 7 | 2. Add missing check_and_restore_queue_depth() call in | ||
| 8 | complete_cmd_fusion(). | ||
| 9 | 3. Enable MSI-X before calling megasas_init_fw(). | ||
| 10 | 4. Call tasklet_schedule() even if outbound_intr_status == 0 for MFI based | ||
| 11 | boards in MSI-X mode. | ||
| 12 | 5. Fix megasas_probe_one() to clear PCI_MSIX_FLAGS_ENABLE in msi control | ||
| 13 | register in kdump kernel. | ||
| 14 | 6. Fix megasas_get_cmd() to only print "Command pool empty" if | ||
| 15 | megasas_dbg_lvl is set. | ||
| 16 | 7. Fix megasas_build_dcdb_fusion() to not filter by TYPE_DISK. | ||
| 17 | 8. Fix megasas_build_dcdb_fusion() to use io_request->LUN[1] field. | ||
| 18 | 9. Add MR_EVT_CFG_CLEARED to megasas_aen_polling(). | ||
| 19 | 10. Fix tasklet_init() in megasas_init_fw() to use instancet->tasklet. | ||
| 20 | 11. Fix fault state handling in megasas_transition_to_ready(). | ||
| 21 | 12. Fix max_sectors setting for IEEE SGL's. | ||
| 22 | 13. Fix iMR OCR support to work correctly. | ||
| 23 | ------------------------------------------------------------------------------- | ||
| 1 | Release Date : Tues. Dec 14, 2010 17:00:00 PST 2010 - | 24 | Release Date : Tues. Dec 14, 2010 17:00:00 PST 2010 - |
| 2 | (emaild-id:megaraidlinux@lsi.com) | 25 | (emaild-id:megaraidlinux@lsi.com) |
| 3 | Adam Radford | 26 | Adam Radford |
diff --git a/Documentation/scsi/ChangeLog.ncr53c8xx b/Documentation/scsi/ChangeLog.ncr53c8xx index 8b278c10edfd..9288e3d8974a 100644 --- a/Documentation/scsi/ChangeLog.ncr53c8xx +++ b/Documentation/scsi/ChangeLog.ncr53c8xx | |||
| @@ -200,7 +200,7 @@ Sun Feb 14:00 1999 Gerard Roudier (groudier@club-internet.fr) | |||
| 200 | By default the driver uses both IRQF_SHARED and IRQF_DISABLED. | 200 | By default the driver uses both IRQF_SHARED and IRQF_DISABLED. |
| 201 | Option 'ncr53c8xx=irqm:0x20' may be used when an IRQ is shared by | 201 | Option 'ncr53c8xx=irqm:0x20' may be used when an IRQ is shared by |
| 202 | a 53C8XX adapter and a network board. | 202 | a 53C8XX adapter and a network board. |
| 203 | - Tiny mispelling fixed (ABORT instead of ABRT). Was fortunately | 203 | - Tiny misspelling fixed (ABORT instead of ABRT). Was fortunately |
| 204 | harmless. | 204 | harmless. |
| 205 | - Negotiate SYNC data transfers with CCS devices. | 205 | - Negotiate SYNC data transfers with CCS devices. |
| 206 | 206 | ||
diff --git a/Documentation/scsi/ChangeLog.sym53c8xx b/Documentation/scsi/ChangeLog.sym53c8xx index 02ffbc1e8a84..c1933707d0bc 100644 --- a/Documentation/scsi/ChangeLog.sym53c8xx +++ b/Documentation/scsi/ChangeLog.sym53c8xx | |||
| @@ -457,7 +457,7 @@ Fri Jan 1 20:00 1999 Gerard Roudier (groudier@club-internet.fr) | |||
| 457 | Sat Dec 19 21:00 1998 Gerard Roudier (groudier@club-internet.fr) | 457 | Sat Dec 19 21:00 1998 Gerard Roudier (groudier@club-internet.fr) |
| 458 | * version sym53c8xx-1.0 | 458 | * version sym53c8xx-1.0 |
| 459 | - Define some new IO registers for the 896 (istat1, mbox0, mbox1) | 459 | - Define some new IO registers for the 896 (istat1, mbox0, mbox1) |
| 460 | - Revamp slighly the Symbios NVRAM lay-out based on the excerpt of | 460 | - Revamp slightly the Symbios NVRAM lay-out based on the excerpt of |
| 461 | the header file I received from Symbios. | 461 | the header file I received from Symbios. |
| 462 | - Check the PCI bus number for the boot order (Using a fast | 462 | - Check the PCI bus number for the boot order (Using a fast |
| 463 | PCI controller behing a PCI-PCI bridge seems sub-optimal). | 463 | PCI controller behing a PCI-PCI bridge seems sub-optimal). |
diff --git a/Documentation/scsi/aha152x.txt b/Documentation/scsi/aha152x.txt index 29ce6d87e451..94848734ac66 100644 --- a/Documentation/scsi/aha152x.txt +++ b/Documentation/scsi/aha152x.txt | |||
| @@ -124,7 +124,7 @@ in the partition table and therefore every operating system has to know | |||
| 124 | the right geometry to be able to interpret it. | 124 | the right geometry to be able to interpret it. |
| 125 | 125 | ||
| 126 | Moreover there are certain limitations to the C/H/S addressing scheme, | 126 | Moreover there are certain limitations to the C/H/S addressing scheme, |
| 127 | namely the address space is limited to upto 255 heads, upto 63 sectors | 127 | namely the address space is limited to up to 255 heads, up to 63 sectors |
| 128 | and a maximum of 1023 cylinders. | 128 | and a maximum of 1023 cylinders. |
| 129 | 129 | ||
| 130 | The AHA-1522 BIOS calculates the geometry by fixing the number of heads | 130 | The AHA-1522 BIOS calculates the geometry by fixing the number of heads |
diff --git a/Documentation/scsi/aic79xx.txt b/Documentation/scsi/aic79xx.txt index 16e054c9c70b..64ac7093c872 100644 --- a/Documentation/scsi/aic79xx.txt +++ b/Documentation/scsi/aic79xx.txt | |||
| @@ -267,7 +267,7 @@ The following information is available in this file: | |||
| 267 | Option: tag_info:{{value[,value...]}[,{value[,value...]}...]} | 267 | Option: tag_info:{{value[,value...]}[,{value[,value...]}...]} |
| 268 | Definition: Set the per-target tagged queue depth on a | 268 | Definition: Set the per-target tagged queue depth on a |
| 269 | per controller basis. Both controllers and targets | 269 | per controller basis. Both controllers and targets |
| 270 | may be ommitted indicating that they should retain | 270 | may be omitted indicating that they should retain |
| 271 | the default tag depth. | 271 | the default tag depth. |
| 272 | Examples: tag_info:{{16,32,32,64,8,8,,32,32,32,32,32,32,32,32,32} | 272 | Examples: tag_info:{{16,32,32,64,8,8,,32,32,32,32,32,32,32,32,32} |
| 273 | On Controller 0 | 273 | On Controller 0 |
| @@ -291,7 +291,7 @@ The following information is available in this file: | |||
| 291 | The rd_strm_bitmask is a 16 bit hex value in which | 291 | The rd_strm_bitmask is a 16 bit hex value in which |
| 292 | each bit represents a target. Setting the target's | 292 | each bit represents a target. Setting the target's |
| 293 | bit to '1' enables read streaming for that | 293 | bit to '1' enables read streaming for that |
| 294 | target. Controllers may be ommitted indicating that | 294 | target. Controllers may be omitted indicating that |
| 295 | they should retain the default read streaming setting. | 295 | they should retain the default read streaming setting. |
| 296 | Example: rd_strm:{0x0041} | 296 | Example: rd_strm:{0x0041} |
| 297 | On Controller 0 | 297 | On Controller 0 |
| @@ -313,7 +313,7 @@ The following information is available in this file: | |||
| 313 | ----------------------------------------------------------------- | 313 | ----------------------------------------------------------------- |
| 314 | Option: dv: {value[,value...]} | 314 | Option: dv: {value[,value...]} |
| 315 | Definition: Set Domain Validation Policy on a per-controller basis. | 315 | Definition: Set Domain Validation Policy on a per-controller basis. |
| 316 | Controllers may be ommitted indicating that | 316 | Controllers may be omitted indicating that |
| 317 | they should retain the default read streaming setting. | 317 | they should retain the default read streaming setting. |
| 318 | Example: dv:{-1,0,,1,1,0} | 318 | Example: dv:{-1,0,,1,1,0} |
| 319 | On Controller 0 leave DV at its default setting. | 319 | On Controller 0 leave DV at its default setting. |
| @@ -340,7 +340,7 @@ The following information is available in this file: | |||
| 340 | Option: precomp: {value[,value...]} | 340 | Option: precomp: {value[,value...]} |
| 341 | Definition: Set IO Cell precompensation value on a per-controller | 341 | Definition: Set IO Cell precompensation value on a per-controller |
| 342 | basis. | 342 | basis. |
| 343 | Controllers may be ommitted indicating that | 343 | Controllers may be omitted indicating that |
| 344 | they should retain the default precompensation setting. | 344 | they should retain the default precompensation setting. |
| 345 | Example: precomp:{0x1} | 345 | Example: precomp:{0x1} |
| 346 | On Controller 0 set precompensation to 1. | 346 | On Controller 0 set precompensation to 1. |
| @@ -353,7 +353,7 @@ The following information is available in this file: | |||
| 353 | ----------------------------------------------------------------- | 353 | ----------------------------------------------------------------- |
| 354 | Option: slewrate: {value[,value...]} | 354 | Option: slewrate: {value[,value...]} |
| 355 | Definition: Set IO Cell slew rate on a per-controller basis. | 355 | Definition: Set IO Cell slew rate on a per-controller basis. |
| 356 | Controllers may be ommitted indicating that | 356 | Controllers may be omitted indicating that |
| 357 | they should retain the default slew rate setting. | 357 | they should retain the default slew rate setting. |
| 358 | Example: slewrate:{0x1} | 358 | Example: slewrate:{0x1} |
| 359 | On Controller 0 set slew rate to 1. | 359 | On Controller 0 set slew rate to 1. |
| @@ -366,7 +366,7 @@ The following information is available in this file: | |||
| 366 | ----------------------------------------------------------------- | 366 | ----------------------------------------------------------------- |
| 367 | Option: amplitude: {value[,value...]} | 367 | Option: amplitude: {value[,value...]} |
| 368 | Definition: Set IO Cell signal amplitude on a per-controller basis. | 368 | Definition: Set IO Cell signal amplitude on a per-controller basis. |
| 369 | Controllers may be ommitted indicating that | 369 | Controllers may be omitted indicating that |
| 370 | they should retain the default read streaming setting. | 370 | they should retain the default read streaming setting. |
| 371 | Example: amplitude:{0x1} | 371 | Example: amplitude:{0x1} |
| 372 | On Controller 0 set amplitude to 1. | 372 | On Controller 0 set amplitude to 1. |
diff --git a/Documentation/scsi/hpsa.txt b/Documentation/scsi/hpsa.txt index dca658362cbf..891435a72fce 100644 --- a/Documentation/scsi/hpsa.txt +++ b/Documentation/scsi/hpsa.txt | |||
| @@ -28,6 +28,12 @@ boot parameter "hpsa_allow_any=1" is specified, however these are not tested | |||
| 28 | nor supported by HP with this driver. For older Smart Arrays, the cciss | 28 | nor supported by HP with this driver. For older Smart Arrays, the cciss |
| 29 | driver should still be used. | 29 | driver should still be used. |
| 30 | 30 | ||
| 31 | The "hpsa_simple_mode=1" boot parameter may be used to prevent the driver from | ||
| 32 | putting the controller into "performant" mode. The difference is that with simple | ||
| 33 | mode, each command completion requires an interrupt, while with "performant mode" | ||
| 34 | (the default, and ordinarily better performing) it is possible to have multiple | ||
| 35 | command completions indicated by a single interrupt. | ||
| 36 | |||
| 31 | HPSA specific entries in /sys | 37 | HPSA specific entries in /sys |
| 32 | ----------------------------- | 38 | ----------------------------- |
| 33 | 39 | ||
| @@ -39,6 +45,8 @@ HPSA specific entries in /sys | |||
| 39 | 45 | ||
| 40 | /sys/class/scsi_host/host*/rescan | 46 | /sys/class/scsi_host/host*/rescan |
| 41 | /sys/class/scsi_host/host*/firmware_revision | 47 | /sys/class/scsi_host/host*/firmware_revision |
| 48 | /sys/class/scsi_host/host*/resettable | ||
| 49 | /sys/class/scsi_host/host*/transport_mode | ||
| 42 | 50 | ||
| 43 | the host "rescan" attribute is a write only attribute. Writing to this | 51 | the host "rescan" attribute is a write only attribute. Writing to this |
| 44 | attribute will cause the driver to scan for new, changed, or removed devices | 52 | attribute will cause the driver to scan for new, changed, or removed devices |
| @@ -55,6 +63,21 @@ HPSA specific entries in /sys | |||
| 55 | root@host:/sys/class/scsi_host/host4# cat firmware_revision | 63 | root@host:/sys/class/scsi_host/host4# cat firmware_revision |
| 56 | 7.14 | 64 | 7.14 |
| 57 | 65 | ||
| 66 | The transport_mode indicates whether the controller is in "performant" | ||
| 67 | or "simple" mode. This is controlled by the "hpsa_simple_mode" module | ||
| 68 | parameter. | ||
| 69 | |||
| 70 | The "resettable" read-only attribute indicates whether a particular | ||
| 71 | controller is able to honor the "reset_devices" kernel parameter. If the | ||
| 72 | device is resettable, this file will contain a "1", otherwise, a "0". This | ||
| 73 | parameter is used by kdump, for example, to reset the controller at driver | ||
| 74 | load time to eliminate any outstanding commands on the controller and get the | ||
| 75 | controller into a known state so that the kdump initiated i/o will work right | ||
| 76 | and not be disrupted in any way by stale commands or other stale state | ||
| 77 | remaining on the controller from the previous kernel. This attribute enables | ||
| 78 | kexec tools to warn the user if they attempt to designate a device which is | ||
| 79 | unable to honor the reset_devices kernel parameter as a dump device. | ||
| 80 | |||
| 58 | HPSA specific disk attributes: | 81 | HPSA specific disk attributes: |
| 59 | ------------------------------ | 82 | ------------------------------ |
| 60 | 83 | ||
diff --git a/Documentation/scsi/ibmmca.txt b/Documentation/scsi/ibmmca.txt index 45d61ad8c6f7..ac41a9fcac77 100644 --- a/Documentation/scsi/ibmmca.txt +++ b/Documentation/scsi/ibmmca.txt | |||
| @@ -303,7 +303,7 @@ | |||
| 303 | (scb) and calls a local function issue_cmd(), which writes a scb | 303 | (scb) and calls a local function issue_cmd(), which writes a scb |
| 304 | command into subsystem I/O ports. Once the scb command is carried out, | 304 | command into subsystem I/O ports. Once the scb command is carried out, |
| 305 | the interrupt_handler() is invoked. If a device is determined to be | 305 | the interrupt_handler() is invoked. If a device is determined to be |
| 306 | existant and it has not assigned any ldn, it gets one dynamically. | 306 | existent and it has not assigned any ldn, it gets one dynamically. |
| 307 | For this, the whole stuff is done in ibmmca_queuecommand(). | 307 | For this, the whole stuff is done in ibmmca_queuecommand(). |
| 308 | 308 | ||
| 309 | 2.6 Abort & Reset Commands | 309 | 2.6 Abort & Reset Commands |
| @@ -741,7 +741,7 @@ | |||
| 741 | some error appeared, else it is undefined. Now, this is fixed. Before | 741 | some error appeared, else it is undefined. Now, this is fixed. Before |
| 742 | any SCB command gets queued, the tsb.dev_status is set to 0, so the | 742 | any SCB command gets queued, the tsb.dev_status is set to 0, so the |
| 743 | cmd->result won't screw up Linux higher level drivers. | 743 | cmd->result won't screw up Linux higher level drivers. |
| 744 | 2) The reset-function has slightly improved. This is still planed for | 744 | 2) The reset-function has slightly improved. This is still planned for |
| 745 | abort. During the abort and the reset function, no interrupts are | 745 | abort. During the abort and the reset function, no interrupts are |
| 746 | allowed. This is however quite hard to cope with, so the INT-status | 746 | allowed. This is however quite hard to cope with, so the INT-status |
| 747 | register is read. When the interrupt gets queued, one can find its | 747 | register is read. When the interrupt gets queued, one can find its |
diff --git a/Documentation/scsi/scsi-changer.txt b/Documentation/scsi/scsi-changer.txt index 032399b16a53..ade046ea7c17 100644 --- a/Documentation/scsi/scsi-changer.txt +++ b/Documentation/scsi/scsi-changer.txt | |||
| @@ -102,7 +102,7 @@ Trouble? | |||
| 102 | 102 | ||
| 103 | If you insmod the driver with "insmod debug=1", it will be verbose and | 103 | If you insmod the driver with "insmod debug=1", it will be verbose and |
| 104 | prints a lot of stuff to the syslog. Compiling the kernel with | 104 | prints a lot of stuff to the syslog. Compiling the kernel with |
| 105 | CONFIG_SCSI_CONSTANTS=y improves the quality of the error messages alot | 105 | CONFIG_SCSI_CONSTANTS=y improves the quality of the error messages a lot |
| 106 | because the kernel will translate the error codes into human-readable | 106 | because the kernel will translate the error codes into human-readable |
| 107 | strings then. | 107 | strings then. |
| 108 | 108 | ||
diff --git a/Documentation/scsi/scsi_eh.txt b/Documentation/scsi/scsi_eh.txt index 7acbebb17fa6..6ff16b620d84 100644 --- a/Documentation/scsi/scsi_eh.txt +++ b/Documentation/scsi/scsi_eh.txt | |||
| @@ -290,7 +290,7 @@ scmd->allowed. | |||
| 290 | SCSI transports/LLDDs automatically acquire sense data on | 290 | SCSI transports/LLDDs automatically acquire sense data on |
| 291 | command failures (autosense). Autosense is recommended for | 291 | command failures (autosense). Autosense is recommended for |
| 292 | performance reasons and as sense information could get out of | 292 | performance reasons and as sense information could get out of |
| 293 | sync inbetween occurrence of CHECK CONDITION and this action. | 293 | sync between occurrence of CHECK CONDITION and this action. |
| 294 | 294 | ||
| 295 | Note that if autosense is not supported, scmd->sense_buffer | 295 | Note that if autosense is not supported, scmd->sense_buffer |
| 296 | contains invalid sense data when error-completing the scmd | 296 | contains invalid sense data when error-completing the scmd |
diff --git a/Documentation/scsi/scsi_fc_transport.txt b/Documentation/scsi/scsi_fc_transport.txt index e00192de4d1c..f79282fc48d7 100644 --- a/Documentation/scsi/scsi_fc_transport.txt +++ b/Documentation/scsi/scsi_fc_transport.txt | |||
| @@ -291,7 +291,7 @@ Transport <-> LLDD Interfaces : | |||
| 291 | Vport support by LLDD: | 291 | Vport support by LLDD: |
| 292 | 292 | ||
| 293 | The LLDD indicates support for vports by supplying a vport_create() | 293 | The LLDD indicates support for vports by supplying a vport_create() |
| 294 | function in the transport template. The presense of this function will | 294 | function in the transport template. The presence of this function will |
| 295 | cause the creation of the new attributes on the fc_host. As part of | 295 | cause the creation of the new attributes on the fc_host. As part of |
| 296 | the physical port completing its initialization relative to the | 296 | the physical port completing its initialization relative to the |
| 297 | transport, it should set the max_npiv_vports attribute to indicate the | 297 | transport, it should set the max_npiv_vports attribute to indicate the |
diff --git a/Documentation/scsi/scsi_mid_low_api.txt b/Documentation/scsi/scsi_mid_low_api.txt index df322c103466..5f17d29c59b5 100644 --- a/Documentation/scsi/scsi_mid_low_api.txt +++ b/Documentation/scsi/scsi_mid_low_api.txt | |||
| @@ -1343,7 +1343,7 @@ Members of interest: | |||
| 1343 | underruns (overruns should be rare). If possible an LLD | 1343 | underruns (overruns should be rare). If possible an LLD |
| 1344 | should set 'resid' prior to invoking 'done'. The most | 1344 | should set 'resid' prior to invoking 'done'. The most |
| 1345 | interesting case is data transfers from a SCSI target | 1345 | interesting case is data transfers from a SCSI target |
| 1346 | device device (i.e. READs) that underrun. | 1346 | device (e.g. READs) that underrun. |
| 1347 | underflow - LLD should place (DID_ERROR << 16) in 'result' if | 1347 | underflow - LLD should place (DID_ERROR << 16) in 'result' if |
| 1348 | actual number of bytes transferred is less than this | 1348 | actual number of bytes transferred is less than this |
| 1349 | figure. Not many LLDs implement this check and some that | 1349 | figure. Not many LLDs implement this check and some that |
| @@ -1351,6 +1351,18 @@ Members of interest: | |||
| 1351 | report a DID_ERROR. Better for an LLD to implement | 1351 | report a DID_ERROR. Better for an LLD to implement |
| 1352 | 'resid'. | 1352 | 'resid'. |
| 1353 | 1353 | ||
| 1354 | It is recommended that a LLD set 'resid' on data transfers from a SCSI | ||
| 1355 | target device (e.g. READs). It is especially important that 'resid' is set | ||
| 1356 | when such data transfers have sense keys of MEDIUM ERROR and HARDWARE ERROR | ||
| 1357 | (and possibly RECOVERED ERROR). In these cases if a LLD is in doubt how much | ||
| 1358 | data has been received then the safest approach is to indicate no bytes have | ||
| 1359 | been received. For example: to indicate that no valid data has been received | ||
| 1360 | a LLD might use these helpers: | ||
| 1361 | scsi_set_resid(SCpnt, scsi_bufflen(SCpnt)); | ||
| 1362 | where 'SCpnt' is a pointer to a scsi_cmnd object. To indicate only three 512 | ||
| 1363 | bytes blocks has been received 'resid' could be set like this: | ||
| 1364 | scsi_set_resid(SCpnt, scsi_bufflen(SCpnt) - (3 * 512)); | ||
| 1365 | |||
| 1354 | The scsi_cmnd structure is defined in include/scsi/scsi_cmnd.h | 1366 | The scsi_cmnd structure is defined in include/scsi/scsi_cmnd.h |
| 1355 | 1367 | ||
| 1356 | 1368 | ||
diff --git a/Documentation/scsi/sym53c8xx_2.txt b/Documentation/scsi/sym53c8xx_2.txt index 6f63b7989679..6af8f7a7770f 100644 --- a/Documentation/scsi/sym53c8xx_2.txt +++ b/Documentation/scsi/sym53c8xx_2.txt | |||
| @@ -285,7 +285,7 @@ from the driver. | |||
| 285 | 285 | ||
| 286 | 7. Profiling information | 286 | 7. Profiling information |
| 287 | 287 | ||
| 288 | This driver does not provide profiling informations as did its predecessors. | 288 | This driver does not provide profiling information as did its predecessors. |
| 289 | This feature was not this useful and added complexity to the code. | 289 | This feature was not this useful and added complexity to the code. |
| 290 | As the driver code got more complex, I have decided to remove everything | 290 | As the driver code got more complex, I have decided to remove everything |
| 291 | that didn't seem actually useful. | 291 | that didn't seem actually useful. |
diff --git a/Documentation/serial/moxa-smartio b/Documentation/serial/moxa-smartio index d10443918684..5d2a33be0bd8 100644 --- a/Documentation/serial/moxa-smartio +++ b/Documentation/serial/moxa-smartio | |||
| @@ -473,7 +473,7 @@ Content | |||
| 473 | spd_normal Use 38.4kb when the application requests 38.4kb. | 473 | spd_normal Use 38.4kb when the application requests 38.4kb. |
| 474 | spd_cust Use the custom divisor to set the speed when the | 474 | spd_cust Use the custom divisor to set the speed when the |
| 475 | application requests 38.4kb. | 475 | application requests 38.4kb. |
| 476 | divisor This option set the custom divison. | 476 | divisor This option set the custom division. |
| 477 | baud_base This option set the base baud rate. | 477 | baud_base This option set the base baud rate. |
| 478 | 478 | ||
| 479 | ----------------------------------------------------------------------------- | 479 | ----------------------------------------------------------------------------- |
diff --git a/Documentation/serial/n_gsm.txt b/Documentation/serial/n_gsm.txt new file mode 100644 index 000000000000..a5d91126a8f7 --- /dev/null +++ b/Documentation/serial/n_gsm.txt | |||
| @@ -0,0 +1,89 @@ | |||
| 1 | n_gsm.c GSM 0710 tty multiplexor HOWTO | ||
| 2 | =================================================== | ||
| 3 | |||
| 4 | This line discipline implements the GSM 07.10 multiplexing protocol | ||
| 5 | detailed in the following 3GPP document : | ||
| 6 | http://www.3gpp.org/ftp/Specs/archive/07_series/07.10/0710-720.zip | ||
| 7 | |||
| 8 | This document give some hints on how to use this driver with GPRS and 3G | ||
| 9 | modems connected to a physical serial port. | ||
| 10 | |||
| 11 | How to use it | ||
| 12 | ------------- | ||
| 13 | 1- initialize the modem in 0710 mux mode (usually AT+CMUX= command) through | ||
| 14 | its serial port. Depending on the modem used, you can pass more or less | ||
| 15 | parameters to this command, | ||
| 16 | 2- switch the serial line to using the n_gsm line discipline by using | ||
| 17 | TIOCSETD ioctl, | ||
| 18 | 3- configure the mux using GSMIOC_GETCONF / GSMIOC_SETCONF ioctl, | ||
| 19 | |||
| 20 | Major parts of the initialization program : | ||
| 21 | (a good starting point is util-linux-ng/sys-utils/ldattach.c) | ||
| 22 | #include <linux/gsmmux.h> | ||
| 23 | #define N_GSM0710 21 /* GSM 0710 Mux */ | ||
| 24 | #define DEFAULT_SPEED B115200 | ||
| 25 | #define SERIAL_PORT /dev/ttyS0 | ||
| 26 | |||
| 27 | int ldisc = N_GSM0710; | ||
| 28 | struct gsm_config c; | ||
| 29 | struct termios configuration; | ||
| 30 | |||
| 31 | /* open the serial port connected to the modem */ | ||
| 32 | fd = open(SERIAL_PORT, O_RDWR | O_NOCTTY | O_NDELAY); | ||
| 33 | |||
| 34 | /* configure the serial port : speed, flow control ... */ | ||
| 35 | |||
| 36 | /* send the AT commands to switch the modem to CMUX mode | ||
| 37 | and check that it's successful (should return OK) */ | ||
| 38 | write(fd, "AT+CMUX=0\r", 10); | ||
| 39 | |||
| 40 | /* experience showed that some modems need some time before | ||
| 41 | being able to answer to the first MUX packet so a delay | ||
| 42 | may be needed here in some case */ | ||
| 43 | sleep(3); | ||
| 44 | |||
| 45 | /* use n_gsm line discipline */ | ||
| 46 | ioctl(fd, TIOCSETD, &ldisc); | ||
| 47 | |||
| 48 | /* get n_gsm configuration */ | ||
| 49 | ioctl(fd, GSMIOC_GETCONF, &c); | ||
| 50 | /* we are initiator and need encoding 0 (basic) */ | ||
| 51 | c.initiator = 1; | ||
| 52 | c.encapsulation = 0; | ||
| 53 | /* our modem defaults to a maximum size of 127 bytes */ | ||
| 54 | c.mru = 127; | ||
| 55 | c.mtu = 127; | ||
| 56 | /* set the new configuration */ | ||
| 57 | ioctl(fd, GSMIOC_SETCONF, &c); | ||
| 58 | |||
| 59 | /* and wait for ever to keep the line discipline enabled */ | ||
| 60 | daemon(0,0); | ||
| 61 | pause(); | ||
| 62 | |||
| 63 | 4- create the devices corresponding to the "virtual" serial ports (take care, | ||
| 64 | each modem has its configuration and some DLC have dedicated functions, | ||
| 65 | for example GPS), starting with minor 1 (DLC0 is reserved for the management | ||
| 66 | of the mux) | ||
| 67 | |||
| 68 | MAJOR=`cat /proc/devices |grep gsmtty | awk '{print $1}` | ||
| 69 | for i in `seq 1 4`; do | ||
| 70 | mknod /dev/ttygsm$i c $MAJOR $i | ||
| 71 | done | ||
| 72 | |||
| 73 | 5- use these devices as plain serial ports. | ||
| 74 | for example, it's possible : | ||
| 75 | - and to use gnokii to send / receive SMS on ttygsm1 | ||
| 76 | - to use ppp to establish a datalink on ttygsm2 | ||
| 77 | |||
| 78 | 6- first close all virtual ports before closing the physical port. | ||
| 79 | |||
| 80 | Additional Documentation | ||
| 81 | ------------------------ | ||
| 82 | More practical details on the protocol and how it's supported by industrial | ||
| 83 | modems can be found in the following documents : | ||
| 84 | http://www.telit.com/module/infopool/download.php?id=616 | ||
| 85 | http://www.u-blox.com/images/downloads/Product_Docs/LEON-G100-G200-MuxImplementation_ApplicationNote_%28GSM%20G1-CS-10002%29.pdf | ||
| 86 | http://www.sierrawireless.com/Support/Downloads/AirPrime/WMP_Series/~/media/Support_Downloads/AirPrime/Application_notes/CMUX_Feature_Application_Note-Rev004.ashx | ||
| 87 | http://wm.sim.com/sim/News/photo/2010721161442.pdf | ||
| 88 | |||
| 89 | 11-03-08 - Eric B茅nard - <eric@eukrea.com> | ||
diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt index 3c1eddd9fcc7..9822afb6313c 100644 --- a/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/Documentation/sound/alsa/ALSA-Configuration.txt | |||
| @@ -322,7 +322,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
| 322 | "port" needs to match the BASE ADDRESS jumper on the card (0x220 or 0x240) | 322 | "port" needs to match the BASE ADDRESS jumper on the card (0x220 or 0x240) |
| 323 | or the value stored in the card's EEPROM for cards that have an EEPROM and | 323 | or the value stored in the card's EEPROM for cards that have an EEPROM and |
| 324 | their "CONFIG MODE" jumper set to "EEPROM SETTING". The other values can | 324 | their "CONFIG MODE" jumper set to "EEPROM SETTING". The other values can |
| 325 | be choosen freely from the options enumerated above. | 325 | be chosen freely from the options enumerated above. |
| 326 | 326 | ||
| 327 | If dma2 is specified and different from dma1, the card will operate in | 327 | If dma2 is specified and different from dma1, the card will operate in |
| 328 | full-duplex mode. When dma1=3, only dma2=0 is valid and the only way to | 328 | full-duplex mode. When dma1=3, only dma2=0 is valid and the only way to |
| @@ -356,7 +356,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
| 356 | "port" needs to match the BASE ADDRESS jumper on the card (0x220 or 0x240) | 356 | "port" needs to match the BASE ADDRESS jumper on the card (0x220 or 0x240) |
| 357 | or the value stored in the card's EEPROM for cards that have an EEPROM and | 357 | or the value stored in the card's EEPROM for cards that have an EEPROM and |
| 358 | their "CONFIG MODE" jumper set to "EEPROM SETTING". The other values can | 358 | their "CONFIG MODE" jumper set to "EEPROM SETTING". The other values can |
| 359 | be choosen freely from the options enumerated above. | 359 | be chosen freely from the options enumerated above. |
| 360 | 360 | ||
| 361 | If dma2 is specified and different from dma1, the card will operate in | 361 | If dma2 is specified and different from dma1, the card will operate in |
| 362 | full-duplex mode. When dma1=3, only dma2=0 is valid and the only way to | 362 | full-duplex mode. When dma1=3, only dma2=0 is valid and the only way to |
| @@ -2229,7 +2229,7 @@ Proc interfaces (/proc/asound) | |||
| 2229 | 2229 | ||
| 2230 | /proc/asound/card#/pcm#[cp]/oss | 2230 | /proc/asound/card#/pcm#[cp]/oss |
| 2231 | ------------------------------- | 2231 | ------------------------------- |
| 2232 | String "erase" - erase all additional informations about OSS applications | 2232 | String "erase" - erase all additional information about OSS applications |
| 2233 | String "<app_name> <fragments> <fragment_size> [<options>]" | 2233 | String "<app_name> <fragments> <fragment_size> [<options>]" |
| 2234 | 2234 | ||
| 2235 | <app_name> - name of application with (higher priority) or without path | 2235 | <app_name> - name of application with (higher priority) or without path |
diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index 16ae4300c747..0caf77e59be4 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt | |||
| @@ -296,6 +296,7 @@ Conexant 5066 | |||
| 296 | ============= | 296 | ============= |
| 297 | laptop Basic Laptop config (default) | 297 | laptop Basic Laptop config (default) |
| 298 | hp-laptop HP laptops, e g G60 | 298 | hp-laptop HP laptops, e g G60 |
| 299 | asus Asus K52JU, Lenovo G560 | ||
| 299 | dell-laptop Dell laptops | 300 | dell-laptop Dell laptops |
| 300 | dell-vostro Dell Vostro | 301 | dell-vostro Dell Vostro |
| 301 | olpc-xo-1_5 OLPC XO 1.5 | 302 | olpc-xo-1_5 OLPC XO 1.5 |
diff --git a/Documentation/sound/oss/AudioExcelDSP16 b/Documentation/sound/oss/AudioExcelDSP16 index c0f08922993b..e0dc0641b480 100644 --- a/Documentation/sound/oss/AudioExcelDSP16 +++ b/Documentation/sound/oss/AudioExcelDSP16 | |||
| @@ -1,10 +1,10 @@ | |||
| 1 | Driver | 1 | Driver |
| 2 | ------ | 2 | ------ |
| 3 | 3 | ||
| 4 | Informations about Audio Excel DSP 16 driver can be found in the source | 4 | Information about Audio Excel DSP 16 driver can be found in the source |
| 5 | file aedsp16.c | 5 | file aedsp16.c |
| 6 | Please, read the head of the source before using it. It contain useful | 6 | Please, read the head of the source before using it. It contain useful |
| 7 | informations. | 7 | information. |
| 8 | 8 | ||
| 9 | Configuration | 9 | Configuration |
| 10 | ------------- | 10 | ------------- |
| @@ -68,7 +68,7 @@ Sound cards supported | |||
| 68 | This driver supports the SC-6000 and SC-6600 based Gallant's sound card. | 68 | This driver supports the SC-6000 and SC-6600 based Gallant's sound card. |
| 69 | It don't support the Audio Excel DSP 16 III (try the SC-6600 code). | 69 | It don't support the Audio Excel DSP 16 III (try the SC-6600 code). |
| 70 | I'm working on the III version of the card: if someone have useful | 70 | I'm working on the III version of the card: if someone have useful |
| 71 | informations about it, please let me know. | 71 | information about it, please let me know. |
| 72 | For all the non-supported audio cards, you have to boot MS-DOS (or WIN95) | 72 | For all the non-supported audio cards, you have to boot MS-DOS (or WIN95) |
| 73 | activating the audio card with the MS-DOS device driver, then you have to | 73 | activating the audio card with the MS-DOS device driver, then you have to |
| 74 | <ctrl>-<alt>-<del> and boot Linux. | 74 | <ctrl>-<alt>-<del> and boot Linux. |
diff --git a/Documentation/sound/oss/README.OSS b/Documentation/sound/oss/README.OSS index c615debbf08d..4be259428a1c 100644 --- a/Documentation/sound/oss/README.OSS +++ b/Documentation/sound/oss/README.OSS | |||
| @@ -1352,7 +1352,7 @@ OSS-mixer. | |||
| 1352 | The PCM20 contains a radio tuner, which is also controlled by | 1352 | The PCM20 contains a radio tuner, which is also controlled by |
| 1353 | ACI. This radio tuner is supported by the ACI driver together with the | 1353 | ACI. This radio tuner is supported by the ACI driver together with the |
| 1354 | miropcm20.o module. Also the 7-band equalizer is integrated | 1354 | miropcm20.o module. Also the 7-band equalizer is integrated |
| 1355 | (limited by the OSS-design). Developement has started and maybe | 1355 | (limited by the OSS-design). Development has started and maybe |
| 1356 | finished for the RDS decoder on this card, too. You will be able to | 1356 | finished for the RDS decoder on this card, too. You will be able to |
| 1357 | read RadioText, the Programme Service name, Programme TYpe and | 1357 | read RadioText, the Programme Service name, Programme TYpe and |
| 1358 | others. Even the v4l radio module benefits from it with a refined | 1358 | others. Even the v4l radio module benefits from it with a refined |
diff --git a/Documentation/sound/oss/README.ymfsb b/Documentation/sound/oss/README.ymfsb index af8a7d3a4e8e..b6b77906b58d 100644 --- a/Documentation/sound/oss/README.ymfsb +++ b/Documentation/sound/oss/README.ymfsb | |||
| @@ -5,7 +5,7 @@ FIRST OF ALL | |||
| 5 | ============ | 5 | ============ |
| 6 | 6 | ||
| 7 | This code references YAMAHA's sample codes and data sheets. | 7 | This code references YAMAHA's sample codes and data sheets. |
| 8 | I respect and thank for all people they made open the informations | 8 | I respect and thank for all people they made open the information |
| 9 | about YMF7xx cards. | 9 | about YMF7xx cards. |
| 10 | 10 | ||
| 11 | And this codes heavily based on Jeff Garzik <jgarzik@pobox.com>'s | 11 | And this codes heavily based on Jeff Garzik <jgarzik@pobox.com>'s |
diff --git a/Documentation/spi/pxa2xx b/Documentation/spi/pxa2xx index 68a4fe3818a1..493dada57372 100644 --- a/Documentation/spi/pxa2xx +++ b/Documentation/spi/pxa2xx | |||
| @@ -143,7 +143,7 @@ configured to use SSPFRM instead. | |||
| 143 | NOTE: the SPI driver cannot control the chip select if SSPFRM is used, so the | 143 | NOTE: the SPI driver cannot control the chip select if SSPFRM is used, so the |
| 144 | chipselect is dropped after each spi_transfer. Most devices need chip select | 144 | chipselect is dropped after each spi_transfer. Most devices need chip select |
| 145 | asserted around the complete message. Use SSPFRM as a GPIO (through cs_control) | 145 | asserted around the complete message. Use SSPFRM as a GPIO (through cs_control) |
| 146 | to accomodate these chips. | 146 | to accommodate these chips. |
| 147 | 147 | ||
| 148 | 148 | ||
| 149 | NSSP SLAVE SAMPLE | 149 | NSSP SLAVE SAMPLE |
diff --git a/Documentation/spi/spi-lm70llp b/Documentation/spi/spi-lm70llp index 34a9cfd746bd..463f6d01fa15 100644 --- a/Documentation/spi/spi-lm70llp +++ b/Documentation/spi/spi-lm70llp | |||
| @@ -46,7 +46,7 @@ The hardware interfacing on the LM70 LLP eval board is as follows: | |||
| 46 | 46 | ||
| 47 | Note that since the LM70 uses a "3-wire" variant of SPI, the SI/SO pin | 47 | Note that since the LM70 uses a "3-wire" variant of SPI, the SI/SO pin |
| 48 | is connected to both pin D7 (as Master Out) and Select (as Master In) | 48 | is connected to both pin D7 (as Master Out) and Select (as Master In) |
| 49 | using an arrangment that lets either the parport or the LM70 pull the | 49 | using an arrangement that lets either the parport or the LM70 pull the |
| 50 | pin low. This can't be shared with true SPI devices, but other 3-wire | 50 | pin low. This can't be shared with true SPI devices, but other 3-wire |
| 51 | devices might share the same SI/SO pin. | 51 | devices might share the same SI/SO pin. |
| 52 | 52 | ||
diff --git a/Documentation/spinlocks.txt b/Documentation/spinlocks.txt index 178c831b907d..2e3c64b1a6a5 100644 --- a/Documentation/spinlocks.txt +++ b/Documentation/spinlocks.txt | |||
| @@ -86,7 +86,7 @@ to change the variables it has to get an exclusive write lock. | |||
| 86 | 86 | ||
| 87 | The routines look the same as above: | 87 | The routines look the same as above: |
| 88 | 88 | ||
| 89 | rwlock_t xxx_lock = RW_LOCK_UNLOCKED; | 89 | rwlock_t xxx_lock = __RW_LOCK_UNLOCKED(xxx_lock); |
| 90 | 90 | ||
| 91 | unsigned long flags; | 91 | unsigned long flags; |
| 92 | 92 | ||
| @@ -196,25 +196,3 @@ appropriate: | |||
| 196 | 196 | ||
| 197 | For static initialization, use DEFINE_SPINLOCK() / DEFINE_RWLOCK() or | 197 | For static initialization, use DEFINE_SPINLOCK() / DEFINE_RWLOCK() or |
| 198 | __SPIN_LOCK_UNLOCKED() / __RW_LOCK_UNLOCKED() as appropriate. | 198 | __SPIN_LOCK_UNLOCKED() / __RW_LOCK_UNLOCKED() as appropriate. |
| 199 | |||
| 200 | SPIN_LOCK_UNLOCKED and RW_LOCK_UNLOCKED are deprecated. These interfere | ||
| 201 | with lockdep state tracking. | ||
| 202 | |||
| 203 | Most of the time, you can simply turn: | ||
| 204 | static spinlock_t xxx_lock = SPIN_LOCK_UNLOCKED; | ||
| 205 | into: | ||
| 206 | static DEFINE_SPINLOCK(xxx_lock); | ||
| 207 | |||
| 208 | Static structure member variables go from: | ||
| 209 | |||
| 210 | struct foo bar { | ||
| 211 | .lock = SPIN_LOCK_UNLOCKED; | ||
| 212 | }; | ||
| 213 | |||
| 214 | to: | ||
| 215 | |||
| 216 | struct foo bar { | ||
| 217 | .lock = __SPIN_LOCK_UNLOCKED(bar.lock); | ||
| 218 | }; | ||
| 219 | |||
| 220 | Declaration of static rw_locks undergo a similar transformation. | ||
diff --git a/Documentation/sysctl/fs.txt b/Documentation/sysctl/fs.txt index 62682500878a..4af0614147ef 100644 --- a/Documentation/sysctl/fs.txt +++ b/Documentation/sysctl/fs.txt | |||
| @@ -88,20 +88,19 @@ you might want to raise the limit. | |||
| 88 | 88 | ||
| 89 | file-max & file-nr: | 89 | file-max & file-nr: |
| 90 | 90 | ||
| 91 | The kernel allocates file handles dynamically, but as yet it | ||
| 92 | doesn't free them again. | ||
| 93 | |||
| 94 | The value in file-max denotes the maximum number of file- | 91 | The value in file-max denotes the maximum number of file- |
| 95 | handles that the Linux kernel will allocate. When you get lots | 92 | handles that the Linux kernel will allocate. When you get lots |
| 96 | of error messages about running out of file handles, you might | 93 | of error messages about running out of file handles, you might |
| 97 | want to increase this limit. | 94 | want to increase this limit. |
| 98 | 95 | ||
| 99 | Historically, the three values in file-nr denoted the number of | 96 | Historically,the kernel was able to allocate file handles |
| 100 | allocated file handles, the number of allocated but unused file | 97 | dynamically, but not to free them again. The three values in |
| 101 | handles, and the maximum number of file handles. Linux 2.6 always | 98 | file-nr denote the number of allocated file handles, the number |
| 102 | reports 0 as the number of free file handles -- this is not an | 99 | of allocated but unused file handles, and the maximum number of |
| 103 | error, it just means that the number of allocated file handles | 100 | file handles. Linux 2.6 always reports 0 as the number of free |
| 104 | exactly matches the number of used file handles. | 101 | file handles -- this is not an error, it just means that the |
| 102 | number of allocated file handles exactly matches the number of | ||
| 103 | used file handles. | ||
| 105 | 104 | ||
| 106 | Attempts to allocate more file descriptors than file-max are | 105 | Attempts to allocate more file descriptors than file-max are |
| 107 | reported with printk, look for "VFS: file-max limit <number> | 106 | reported with printk, look for "VFS: file-max limit <number> |
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index 11d5ceda5bb0..36f007514db3 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt | |||
| @@ -367,7 +367,7 @@ the different loglevels. | |||
| 367 | 367 | ||
| 368 | - console_loglevel: messages with a higher priority than | 368 | - console_loglevel: messages with a higher priority than |
| 369 | this will be printed to the console | 369 | this will be printed to the console |
| 370 | - default_message_level: messages without an explicit priority | 370 | - default_message_loglevel: messages without an explicit priority |
| 371 | will be printed with this priority | 371 | will be printed with this priority |
| 372 | - minimum_console_loglevel: minimum (highest) value to which | 372 | - minimum_console_loglevel: minimum (highest) value to which |
| 373 | console_loglevel can be set | 373 | console_loglevel can be set |
diff --git a/Documentation/target/tcm_mod_builder.py b/Documentation/target/tcm_mod_builder.py index dbeb8a0d7175..7ef9b843d529 100755 --- a/Documentation/target/tcm_mod_builder.py +++ b/Documentation/target/tcm_mod_builder.py | |||
| @@ -239,8 +239,8 @@ def tcm_mod_build_configfs(proto_ident, fabric_mod_dir_var, fabric_mod_name): | |||
| 239 | buf += "#include <target/target_core_configfs.h>\n" | 239 | buf += "#include <target/target_core_configfs.h>\n" |
| 240 | buf += "#include <target/target_core_base.h>\n" | 240 | buf += "#include <target/target_core_base.h>\n" |
| 241 | buf += "#include <target/configfs_macros.h>\n\n" | 241 | buf += "#include <target/configfs_macros.h>\n\n" |
| 242 | buf += "#include <" + fabric_mod_name + "_base.h>\n" | 242 | buf += "#include \"" + fabric_mod_name + "_base.h\"\n" |
| 243 | buf += "#include <" + fabric_mod_name + "_fabric.h>\n\n" | 243 | buf += "#include \"" + fabric_mod_name + "_fabric.h\"\n\n" |
| 244 | 244 | ||
| 245 | buf += "/* Local pointer to allocated TCM configfs fabric module */\n" | 245 | buf += "/* Local pointer to allocated TCM configfs fabric module */\n" |
| 246 | buf += "struct target_fabric_configfs *" + fabric_mod_name + "_fabric_configfs;\n\n" | 246 | buf += "struct target_fabric_configfs *" + fabric_mod_name + "_fabric_configfs;\n\n" |
| @@ -289,6 +289,7 @@ def tcm_mod_build_configfs(proto_ident, fabric_mod_dir_var, fabric_mod_name): | |||
| 289 | buf += "{\n" | 289 | buf += "{\n" |
| 290 | buf += " struct " + fabric_mod_name + "_nacl *nacl = container_of(se_acl,\n" | 290 | buf += " struct " + fabric_mod_name + "_nacl *nacl = container_of(se_acl,\n" |
| 291 | buf += " struct " + fabric_mod_name + "_nacl, se_node_acl);\n" | 291 | buf += " struct " + fabric_mod_name + "_nacl, se_node_acl);\n" |
| 292 | buf += " core_tpg_del_initiator_node_acl(se_acl->se_tpg, se_acl, 1);\n" | ||
| 292 | buf += " kfree(nacl);\n" | 293 | buf += " kfree(nacl);\n" |
| 293 | buf += "}\n\n" | 294 | buf += "}\n\n" |
| 294 | 295 | ||
| @@ -583,9 +584,9 @@ def tcm_mod_dump_fabric_ops(proto_ident, fabric_mod_dir_var, fabric_mod_name): | |||
| 583 | buf += "#include <target/target_core_fabric_lib.h>\n" | 584 | buf += "#include <target/target_core_fabric_lib.h>\n" |
| 584 | buf += "#include <target/target_core_device.h>\n" | 585 | buf += "#include <target/target_core_device.h>\n" |
| 585 | buf += "#include <target/target_core_tpg.h>\n" | 586 | buf += "#include <target/target_core_tpg.h>\n" |
| 586 | buf += "#include <target/target_core_configfs.h>\n" | 587 | buf += "#include <target/target_core_configfs.h>\n\n" |
| 587 | buf += "#include <" + fabric_mod_name + "_base.h>\n" | 588 | buf += "#include \"" + fabric_mod_name + "_base.h\"\n" |
| 588 | buf += "#include <" + fabric_mod_name + "_fabric.h>\n\n" | 589 | buf += "#include \"" + fabric_mod_name + "_fabric.h\"\n\n" |
| 589 | 590 | ||
| 590 | buf += "int " + fabric_mod_name + "_check_true(struct se_portal_group *se_tpg)\n" | 591 | buf += "int " + fabric_mod_name + "_check_true(struct se_portal_group *se_tpg)\n" |
| 591 | buf += "{\n" | 592 | buf += "{\n" |
| @@ -973,14 +974,13 @@ def tcm_mod_dump_fabric_ops(proto_ident, fabric_mod_dir_var, fabric_mod_name): | |||
| 973 | def tcm_mod_build_kbuild(fabric_mod_dir_var, fabric_mod_name): | 974 | def tcm_mod_build_kbuild(fabric_mod_dir_var, fabric_mod_name): |
| 974 | 975 | ||
| 975 | buf = "" | 976 | buf = "" |
| 976 | f = fabric_mod_dir_var + "/Kbuild" | 977 | f = fabric_mod_dir_var + "/Makefile" |
| 977 | print "Writing file: " + f | 978 | print "Writing file: " + f |
| 978 | 979 | ||
| 979 | p = open(f, 'w') | 980 | p = open(f, 'w') |
| 980 | if not p: | 981 | if not p: |
| 981 | tcm_mod_err("Unable to open file: " + f) | 982 | tcm_mod_err("Unable to open file: " + f) |
| 982 | 983 | ||
| 983 | buf = "EXTRA_CFLAGS += -I$(srctree)/drivers/target/ -I$(srctree)/include/ -I$(srctree)/drivers/scsi/ -I$(srctree)/include/scsi/ -I$(srctree)/drivers/target/" + fabric_mod_name + "\n\n" | ||
| 984 | buf += fabric_mod_name + "-objs := " + fabric_mod_name + "_fabric.o \\\n" | 984 | buf += fabric_mod_name + "-objs := " + fabric_mod_name + "_fabric.o \\\n" |
| 985 | buf += " " + fabric_mod_name + "_configfs.o\n" | 985 | buf += " " + fabric_mod_name + "_configfs.o\n" |
| 986 | buf += "obj-$(CONFIG_" + fabric_mod_name.upper() + ") += " + fabric_mod_name + ".o\n" | 986 | buf += "obj-$(CONFIG_" + fabric_mod_name.upper() + ") += " + fabric_mod_name + ".o\n" |
| @@ -1018,7 +1018,7 @@ def tcm_mod_build_kconfig(fabric_mod_dir_var, fabric_mod_name): | |||
| 1018 | 1018 | ||
| 1019 | def tcm_mod_add_kbuild(tcm_dir, fabric_mod_name): | 1019 | def tcm_mod_add_kbuild(tcm_dir, fabric_mod_name): |
| 1020 | buf = "obj-$(CONFIG_" + fabric_mod_name.upper() + ") += " + fabric_mod_name.lower() + "/\n" | 1020 | buf = "obj-$(CONFIG_" + fabric_mod_name.upper() + ") += " + fabric_mod_name.lower() + "/\n" |
| 1021 | kbuild = tcm_dir + "/drivers/target/Kbuild" | 1021 | kbuild = tcm_dir + "/drivers/target/Makefile" |
| 1022 | 1022 | ||
| 1023 | f = open(kbuild, 'a') | 1023 | f = open(kbuild, 'a') |
| 1024 | f.write(buf) | 1024 | f.write(buf) |
| @@ -1064,7 +1064,7 @@ def main(modname, proto_ident): | |||
| 1064 | tcm_mod_build_kbuild(fabric_mod_dir, fabric_mod_name) | 1064 | tcm_mod_build_kbuild(fabric_mod_dir, fabric_mod_name) |
| 1065 | tcm_mod_build_kconfig(fabric_mod_dir, fabric_mod_name) | 1065 | tcm_mod_build_kconfig(fabric_mod_dir, fabric_mod_name) |
| 1066 | 1066 | ||
| 1067 | input = raw_input("Would you like to add " + fabric_mod_name + "to drivers/target/Kbuild..? [yes,no]: ") | 1067 | input = raw_input("Would you like to add " + fabric_mod_name + "to drivers/target/Makefile..? [yes,no]: ") |
| 1068 | if input == "yes" or input == "y": | 1068 | if input == "yes" or input == "y": |
| 1069 | tcm_mod_add_kbuild(tcm_dir, fabric_mod_name) | 1069 | tcm_mod_add_kbuild(tcm_dir, fabric_mod_name) |
| 1070 | 1070 | ||
diff --git a/Documentation/telephony/ixj.txt b/Documentation/telephony/ixj.txt index 4fb314d51702..db94fb6c5678 100644 --- a/Documentation/telephony/ixj.txt +++ b/Documentation/telephony/ixj.txt | |||
| @@ -51,7 +51,7 @@ be removed to protect the rights of others. | |||
| 51 | Specifically, very old Internet PhoneJACK cards have non-standard | 51 | Specifically, very old Internet PhoneJACK cards have non-standard |
| 52 | G.723.1 codecs (due to the early nature of the DSPs in those days). | 52 | G.723.1 codecs (due to the early nature of the DSPs in those days). |
| 53 | The auto-conversion code to bring those cards into compliance with | 53 | The auto-conversion code to bring those cards into compliance with |
| 54 | todays standards is available as a binary only module to those people | 54 | today's standards is available as a binary only module to those people |
| 55 | needing it. If you bought your card after 1997 or so, you are OK - | 55 | needing it. If you bought your card after 1997 or so, you are OK - |
| 56 | it's only the very old cards that are affected. | 56 | it's only the very old cards that are affected. |
| 57 | 57 | ||
diff --git a/Documentation/trace/ftrace-design.txt b/Documentation/trace/ftrace-design.txt index dc52bd442c92..79fcafc7fd64 100644 --- a/Documentation/trace/ftrace-design.txt +++ b/Documentation/trace/ftrace-design.txt | |||
| @@ -247,6 +247,13 @@ You need very few things to get the syscalls tracing in an arch. | |||
| 247 | - Support the TIF_SYSCALL_TRACEPOINT thread flags. | 247 | - Support the TIF_SYSCALL_TRACEPOINT thread flags. |
| 248 | - Put the trace_sys_enter() and trace_sys_exit() tracepoints calls from ptrace | 248 | - Put the trace_sys_enter() and trace_sys_exit() tracepoints calls from ptrace |
| 249 | in the ptrace syscalls tracing path. | 249 | in the ptrace syscalls tracing path. |
| 250 | - If the system call table on this arch is more complicated than a simple array | ||
| 251 | of addresses of the system calls, implement an arch_syscall_addr to return | ||
| 252 | the address of a given system call. | ||
| 253 | - If the symbol names of the system calls do not match the function names on | ||
| 254 | this arch, define ARCH_HAS_SYSCALL_MATCH_SYM_NAME in asm/ftrace.h and | ||
| 255 | implement arch_syscall_match_sym_name with the appropriate logic to return | ||
| 256 | true if the function name corresponds with the symbol name. | ||
| 250 | - Tag this arch as HAVE_SYSCALL_TRACEPOINTS. | 257 | - Tag this arch as HAVE_SYSCALL_TRACEPOINTS. |
| 251 | 258 | ||
| 252 | 259 | ||
diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt index 557c1edeccaf..1ebc24cf9a55 100644 --- a/Documentation/trace/ftrace.txt +++ b/Documentation/trace/ftrace.txt | |||
| @@ -80,11 +80,11 @@ of ftrace. Here is a list of some of the key files: | |||
| 80 | tracers listed here can be configured by | 80 | tracers listed here can be configured by |
| 81 | echoing their name into current_tracer. | 81 | echoing their name into current_tracer. |
| 82 | 82 | ||
| 83 | tracing_enabled: | 83 | tracing_on: |
| 84 | 84 | ||
| 85 | This sets or displays whether the current_tracer | 85 | This sets or displays whether writing to the trace |
| 86 | is activated and tracing or not. Echo 0 into this | 86 | ring buffer is enabled. Echo 0 into this file to disable |
| 87 | file to disable the tracer or 1 to enable it. | 87 | the tracer or 1 to enable it. |
| 88 | 88 | ||
| 89 | trace: | 89 | trace: |
| 90 | 90 | ||
| @@ -202,10 +202,6 @@ Here is the list of current tracers that may be configured. | |||
| 202 | to draw a graph of function calls similar to C code | 202 | to draw a graph of function calls similar to C code |
| 203 | source. | 203 | source. |
| 204 | 204 | ||
| 205 | "sched_switch" | ||
| 206 | |||
| 207 | Traces the context switches and wakeups between tasks. | ||
| 208 | |||
| 209 | "irqsoff" | 205 | "irqsoff" |
| 210 | 206 | ||
| 211 | Traces the areas that disable interrupts and saves | 207 | Traces the areas that disable interrupts and saves |
| @@ -273,39 +269,6 @@ format, the function name that was traced "path_put" and the | |||
| 273 | parent function that called this function "path_walk". The | 269 | parent function that called this function "path_walk". The |
| 274 | timestamp is the time at which the function was entered. | 270 | timestamp is the time at which the function was entered. |
| 275 | 271 | ||
| 276 | The sched_switch tracer also includes tracing of task wakeups | ||
| 277 | and context switches. | ||
| 278 | |||
| 279 | ksoftirqd/1-7 [01] 1453.070013: 7:115:R + 2916:115:S | ||
| 280 | ksoftirqd/1-7 [01] 1453.070013: 7:115:R + 10:115:S | ||
| 281 | ksoftirqd/1-7 [01] 1453.070013: 7:115:R ==> 10:115:R | ||
| 282 | events/1-10 [01] 1453.070013: 10:115:S ==> 2916:115:R | ||
| 283 | kondemand/1-2916 [01] 1453.070013: 2916:115:S ==> 7:115:R | ||
| 284 | ksoftirqd/1-7 [01] 1453.070013: 7:115:S ==> 0:140:R | ||
| 285 | |||
| 286 | Wake ups are represented by a "+" and the context switches are | ||
| 287 | shown as "==>". The format is: | ||
| 288 | |||
| 289 | Context switches: | ||
| 290 | |||
| 291 | Previous task Next Task | ||
| 292 | |||
| 293 | <pid>:<prio>:<state> ==> <pid>:<prio>:<state> | ||
| 294 | |||
| 295 | Wake ups: | ||
| 296 | |||
| 297 | Current task Task waking up | ||
| 298 | |||
| 299 | <pid>:<prio>:<state> + <pid>:<prio>:<state> | ||
| 300 | |||
| 301 | The prio is the internal kernel priority, which is the inverse | ||
| 302 | of the priority that is usually displayed by user-space tools. | ||
| 303 | Zero represents the highest priority (99). Prio 100 starts the | ||
| 304 | "nice" priorities with 100 being equal to nice -20 and 139 being | ||
| 305 | nice 19. The prio "140" is reserved for the idle task which is | ||
| 306 | the lowest priority thread (pid 0). | ||
| 307 | |||
| 308 | |||
| 309 | Latency trace format | 272 | Latency trace format |
| 310 | -------------------- | 273 | -------------------- |
| 311 | 274 | ||
| @@ -491,78 +454,10 @@ x494] <- /root/a.out[+0x4a8] <- /lib/libc-2.7.so[+0x1e1a6] | |||
| 491 | latencies, as described in "Latency | 454 | latencies, as described in "Latency |
| 492 | trace format". | 455 | trace format". |
| 493 | 456 | ||
| 494 | sched_switch | 457 | overwrite - This controls what happens when the trace buffer is |
| 495 | ------------ | 458 | full. If "1" (default), the oldest events are |
| 496 | 459 | discarded and overwritten. If "0", then the newest | |
| 497 | This tracer simply records schedule switches. Here is an example | 460 | events are discarded. |
| 498 | of how to use it. | ||
| 499 | |||
| 500 | # echo sched_switch > current_tracer | ||
| 501 | # echo 1 > tracing_enabled | ||
| 502 | # sleep 1 | ||
| 503 | # echo 0 > tracing_enabled | ||
| 504 | # cat trace | ||
| 505 | |||
| 506 | # tracer: sched_switch | ||
| 507 | # | ||
| 508 | # TASK-PID CPU# TIMESTAMP FUNCTION | ||
| 509 | # | | | | | | ||
| 510 | bash-3997 [01] 240.132281: 3997:120:R + 4055:120:R | ||
| 511 | bash-3997 [01] 240.132284: 3997:120:R ==> 4055:120:R | ||
| 512 | sleep-4055 [01] 240.132371: 4055:120:S ==> 3997:120:R | ||
| 513 | bash-3997 [01] 240.132454: 3997:120:R + 4055:120:S | ||
| 514 | bash-3997 [01] 240.132457: 3997:120:R ==> 4055:120:R | ||
| 515 | sleep-4055 [01] 240.132460: 4055:120:D ==> 3997:120:R | ||
| 516 | bash-3997 [01] 240.132463: 3997:120:R + 4055:120:D | ||
| 517 | bash-3997 [01] 240.132465: 3997:120:R ==> 4055:120:R | ||
| 518 | <idle>-0 [00] 240.132589: 0:140:R + 4:115:S | ||
| 519 | <idle>-0 [00] 240.132591: 0:140:R ==> 4:115:R | ||
| 520 | ksoftirqd/0-4 [00] 240.132595: 4:115:S ==> 0:140:R | ||
| 521 | <idle>-0 [00] 240.132598: 0:140:R + 4:115:S | ||
| 522 | <idle>-0 [00] 240.132599: 0:140:R ==> 4:115:R | ||
| 523 | ksoftirqd/0-4 [00] 240.132603: 4:115:S ==> 0:140:R | ||
| 524 | sleep-4055 [01] 240.133058: 4055:120:S ==> 3997:120:R | ||
| 525 | [...] | ||
| 526 | |||
| 527 | |||
| 528 | As we have discussed previously about this format, the header | ||
| 529 | shows the name of the trace and points to the options. The | ||
| 530 | "FUNCTION" is a misnomer since here it represents the wake ups | ||
| 531 | and context switches. | ||
| 532 | |||
| 533 | The sched_switch file only lists the wake ups (represented with | ||
| 534 | '+') and context switches ('==>') with the previous task or | ||
| 535 | current task first followed by the next task or task waking up. | ||
| 536 | The format for both of these is PID:KERNEL-PRIO:TASK-STATE. | ||
| 537 | Remember that the KERNEL-PRIO is the inverse of the actual | ||
| 538 | priority with zero (0) being the highest priority and the nice | ||
| 539 | values starting at 100 (nice -20). Below is a quick chart to map | ||
| 540 | the kernel priority to user land priorities. | ||
| 541 | |||
| 542 | Kernel Space User Space | ||
| 543 | =============================================================== | ||
| 544 | 0(high) to 98(low) user RT priority 99(high) to 1(low) | ||
| 545 | with SCHED_RR or SCHED_FIFO | ||
| 546 | --------------------------------------------------------------- | ||
| 547 | 99 sched_priority is not used in scheduling | ||
| 548 | decisions(it must be specified as 0) | ||
| 549 | --------------------------------------------------------------- | ||
| 550 | 100(high) to 139(low) user nice -20(high) to 19(low) | ||
| 551 | --------------------------------------------------------------- | ||
| 552 | 140 idle task priority | ||
| 553 | --------------------------------------------------------------- | ||
| 554 | |||
| 555 | The task states are: | ||
| 556 | |||
| 557 | R - running : wants to run, may not actually be running | ||
| 558 | S - sleep : process is waiting to be woken up (handles signals) | ||
| 559 | D - disk sleep (uninterruptible sleep) : process must be woken up | ||
| 560 | (ignores signals) | ||
| 561 | T - stopped : process suspended | ||
| 562 | t - traced : process is being traced (with something like gdb) | ||
| 563 | Z - zombie : process waiting to be cleaned up | ||
| 564 | X - unknown | ||
| 565 | |||
| 566 | 461 | ||
| 567 | ftrace_enabled | 462 | ftrace_enabled |
| 568 | -------------- | 463 | -------------- |
| @@ -607,10 +502,10 @@ an example: | |||
| 607 | # echo irqsoff > current_tracer | 502 | # echo irqsoff > current_tracer |
| 608 | # echo latency-format > trace_options | 503 | # echo latency-format > trace_options |
| 609 | # echo 0 > tracing_max_latency | 504 | # echo 0 > tracing_max_latency |
| 610 | # echo 1 > tracing_enabled | 505 | # echo 1 > tracing_on |
| 611 | # ls -ltr | 506 | # ls -ltr |
| 612 | [...] | 507 | [...] |
| 613 | # echo 0 > tracing_enabled | 508 | # echo 0 > tracing_on |
| 614 | # cat trace | 509 | # cat trace |
| 615 | # tracer: irqsoff | 510 | # tracer: irqsoff |
| 616 | # | 511 | # |
| @@ -715,10 +610,10 @@ is much like the irqsoff tracer. | |||
| 715 | # echo preemptoff > current_tracer | 610 | # echo preemptoff > current_tracer |
| 716 | # echo latency-format > trace_options | 611 | # echo latency-format > trace_options |
| 717 | # echo 0 > tracing_max_latency | 612 | # echo 0 > tracing_max_latency |
| 718 | # echo 1 > tracing_enabled | 613 | # echo 1 > tracing_on |
| 719 | # ls -ltr | 614 | # ls -ltr |
| 720 | [...] | 615 | [...] |
| 721 | # echo 0 > tracing_enabled | 616 | # echo 0 > tracing_on |
| 722 | # cat trace | 617 | # cat trace |
| 723 | # tracer: preemptoff | 618 | # tracer: preemptoff |
| 724 | # | 619 | # |
| @@ -863,10 +758,10 @@ tracers. | |||
| 863 | # echo preemptirqsoff > current_tracer | 758 | # echo preemptirqsoff > current_tracer |
| 864 | # echo latency-format > trace_options | 759 | # echo latency-format > trace_options |
| 865 | # echo 0 > tracing_max_latency | 760 | # echo 0 > tracing_max_latency |
| 866 | # echo 1 > tracing_enabled | 761 | # echo 1 > tracing_on |
| 867 | # ls -ltr | 762 | # ls -ltr |
| 868 | [...] | 763 | [...] |
| 869 | # echo 0 > tracing_enabled | 764 | # echo 0 > tracing_on |
| 870 | # cat trace | 765 | # cat trace |
| 871 | # tracer: preemptirqsoff | 766 | # tracer: preemptirqsoff |
| 872 | # | 767 | # |
| @@ -1026,9 +921,9 @@ Instead of performing an 'ls', we will run 'sleep 1' under | |||
| 1026 | # echo wakeup > current_tracer | 921 | # echo wakeup > current_tracer |
| 1027 | # echo latency-format > trace_options | 922 | # echo latency-format > trace_options |
| 1028 | # echo 0 > tracing_max_latency | 923 | # echo 0 > tracing_max_latency |
| 1029 | # echo 1 > tracing_enabled | 924 | # echo 1 > tracing_on |
| 1030 | # chrt -f 5 sleep 1 | 925 | # chrt -f 5 sleep 1 |
| 1031 | # echo 0 > tracing_enabled | 926 | # echo 0 > tracing_on |
| 1032 | # cat trace | 927 | # cat trace |
| 1033 | # tracer: wakeup | 928 | # tracer: wakeup |
| 1034 | # | 929 | # |
| @@ -1140,9 +1035,9 @@ ftrace_enabled is set; otherwise this tracer is a nop. | |||
| 1140 | 1035 | ||
| 1141 | # sysctl kernel.ftrace_enabled=1 | 1036 | # sysctl kernel.ftrace_enabled=1 |
| 1142 | # echo function > current_tracer | 1037 | # echo function > current_tracer |
| 1143 | # echo 1 > tracing_enabled | 1038 | # echo 1 > tracing_on |
| 1144 | # usleep 1 | 1039 | # usleep 1 |
| 1145 | # echo 0 > tracing_enabled | 1040 | # echo 0 > tracing_on |
| 1146 | # cat trace | 1041 | # cat trace |
| 1147 | # tracer: function | 1042 | # tracer: function |
| 1148 | # | 1043 | # |
| @@ -1180,7 +1075,7 @@ int trace_fd; | |||
| 1180 | [...] | 1075 | [...] |
| 1181 | int main(int argc, char *argv[]) { | 1076 | int main(int argc, char *argv[]) { |
| 1182 | [...] | 1077 | [...] |
| 1183 | trace_fd = open(tracing_file("tracing_enabled"), O_WRONLY); | 1078 | trace_fd = open(tracing_file("tracing_on"), O_WRONLY); |
| 1184 | [...] | 1079 | [...] |
| 1185 | if (condition_hit()) { | 1080 | if (condition_hit()) { |
| 1186 | write(trace_fd, "0", 1); | 1081 | write(trace_fd, "0", 1); |
| @@ -1631,9 +1526,9 @@ If I am only interested in sys_nanosleep and hrtimer_interrupt: | |||
| 1631 | # echo sys_nanosleep hrtimer_interrupt \ | 1526 | # echo sys_nanosleep hrtimer_interrupt \ |
| 1632 | > set_ftrace_filter | 1527 | > set_ftrace_filter |
| 1633 | # echo function > current_tracer | 1528 | # echo function > current_tracer |
| 1634 | # echo 1 > tracing_enabled | 1529 | # echo 1 > tracing_on |
| 1635 | # usleep 1 | 1530 | # usleep 1 |
| 1636 | # echo 0 > tracing_enabled | 1531 | # echo 0 > tracing_on |
| 1637 | # cat trace | 1532 | # cat trace |
| 1638 | # tracer: ftrace | 1533 | # tracer: ftrace |
| 1639 | # | 1534 | # |
| @@ -1879,9 +1774,9 @@ different. The trace is live. | |||
| 1879 | # echo function > current_tracer | 1774 | # echo function > current_tracer |
| 1880 | # cat trace_pipe > /tmp/trace.out & | 1775 | # cat trace_pipe > /tmp/trace.out & |
| 1881 | [1] 4153 | 1776 | [1] 4153 |
| 1882 | # echo 1 > tracing_enabled | 1777 | # echo 1 > tracing_on |
| 1883 | # usleep 1 | 1778 | # usleep 1 |
| 1884 | # echo 0 > tracing_enabled | 1779 | # echo 0 > tracing_on |
| 1885 | # cat trace | 1780 | # cat trace |
| 1886 | # tracer: function | 1781 | # tracer: function |
| 1887 | # | 1782 | # |
diff --git a/Documentation/trace/kprobetrace.txt b/Documentation/trace/kprobetrace.txt index 5f77d94598dd..6d27ab8d6e9f 100644 --- a/Documentation/trace/kprobetrace.txt +++ b/Documentation/trace/kprobetrace.txt | |||
| @@ -42,11 +42,25 @@ Synopsis of kprobe_events | |||
| 42 | +|-offs(FETCHARG) : Fetch memory at FETCHARG +|- offs address.(**) | 42 | +|-offs(FETCHARG) : Fetch memory at FETCHARG +|- offs address.(**) |
| 43 | NAME=FETCHARG : Set NAME as the argument name of FETCHARG. | 43 | NAME=FETCHARG : Set NAME as the argument name of FETCHARG. |
| 44 | FETCHARG:TYPE : Set TYPE as the type of FETCHARG. Currently, basic types | 44 | FETCHARG:TYPE : Set TYPE as the type of FETCHARG. Currently, basic types |
| 45 | (u8/u16/u32/u64/s8/s16/s32/s64) and string are supported. | 45 | (u8/u16/u32/u64/s8/s16/s32/s64), "string" and bitfield |
| 46 | are supported. | ||
| 46 | 47 | ||
| 47 | (*) only for return probe. | 48 | (*) only for return probe. |
| 48 | (**) this is useful for fetching a field of data structures. | 49 | (**) this is useful for fetching a field of data structures. |
| 49 | 50 | ||
| 51 | Types | ||
| 52 | ----- | ||
| 53 | Several types are supported for fetch-args. Kprobe tracer will access memory | ||
| 54 | by given type. Prefix 's' and 'u' means those types are signed and unsigned | ||
| 55 | respectively. Traced arguments are shown in decimal (signed) or hex (unsigned). | ||
| 56 | String type is a special type, which fetches a "null-terminated" string from | ||
| 57 | kernel space. This means it will fail and store NULL if the string container | ||
| 58 | has been paged out. | ||
| 59 | Bitfield is another special type, which takes 3 parameters, bit-width, bit- | ||
| 60 | offset, and container-size (usually 32). The syntax is; | ||
| 61 | |||
| 62 | b<bit-width>@<bit-offset>/<container-size> | ||
| 63 | |||
| 50 | 64 | ||
| 51 | Per-Probe Event Filtering | 65 | Per-Probe Event Filtering |
| 52 | ------------------------- | 66 | ------------------------- |
diff --git a/Documentation/trace/ring-buffer-design.txt b/Documentation/trace/ring-buffer-design.txt index d299ff31df57..7d350b496585 100644 --- a/Documentation/trace/ring-buffer-design.txt +++ b/Documentation/trace/ring-buffer-design.txt | |||
| @@ -237,7 +237,7 @@ with the previous write. | |||
| 237 | |written | | 237 | |written | |
| 238 | +---------+ | 238 | +---------+ |
| 239 | |written | | 239 | |written | |
| 240 | +---------+ <--- next positon for write (current commit) | 240 | +---------+ <--- next position for write (current commit) |
| 241 | | empty | | 241 | | empty | |
| 242 | +---------+ | 242 | +---------+ |
| 243 | 243 | ||
diff --git a/Documentation/usb/usbmon.txt b/Documentation/usb/usbmon.txt index 66f92d1194c1..a4efa0462f05 100644 --- a/Documentation/usb/usbmon.txt +++ b/Documentation/usb/usbmon.txt | |||
| @@ -12,6 +12,10 @@ Controller Drivers (HCD). So, if HCD is buggy, the traces reported by | |||
| 12 | usbmon may not correspond to bus transactions precisely. This is the same | 12 | usbmon may not correspond to bus transactions precisely. This is the same |
| 13 | situation as with tcpdump. | 13 | situation as with tcpdump. |
| 14 | 14 | ||
| 15 | Two APIs are currently implemented: "text" and "binary". The binary API | ||
| 16 | is available through a character device in /dev namespace and is an ABI. | ||
| 17 | The text API is deprecated since 2.6.35, but available for convenience. | ||
| 18 | |||
| 15 | * How to use usbmon to collect raw text traces | 19 | * How to use usbmon to collect raw text traces |
| 16 | 20 | ||
| 17 | Unlike the packet socket, usbmon has an interface which provides traces | 21 | Unlike the packet socket, usbmon has an interface which provides traces |
| @@ -162,39 +166,11 @@ Here is the list of words, from left to right: | |||
| 162 | not machine words, but really just a byte stream split into words to make | 166 | not machine words, but really just a byte stream split into words to make |
| 163 | it easier to read. Thus, the last word may contain from one to four bytes. | 167 | it easier to read. Thus, the last word may contain from one to four bytes. |
| 164 | The length of collected data is limited and can be less than the data length | 168 | The length of collected data is limited and can be less than the data length |
| 165 | report in Data Length word. | 169 | reported in the Data Length word. In the case of an Isochronous input (Zi) |
| 166 | 170 | completion where the received data is sparse in the buffer, the length of | |
| 167 | Here is an example of code to read the data stream in a well known programming | 171 | the collected data can be greater than the Data Length value (because Data |
| 168 | language: | 172 | Length counts only the bytes that were received whereas the Data words |
| 169 | 173 | contain the entire transfer buffer). | |
| 170 | class ParsedLine { | ||
| 171 | int data_len; /* Available length of data */ | ||
| 172 | byte data[]; | ||
| 173 | |||
| 174 | void parseData(StringTokenizer st) { | ||
| 175 | int availwords = st.countTokens(); | ||
| 176 | data = new byte[availwords * 4]; | ||
| 177 | data_len = 0; | ||
| 178 | while (st.hasMoreTokens()) { | ||
| 179 | String data_str = st.nextToken(); | ||
| 180 | int len = data_str.length() / 2; | ||
| 181 | int i; | ||
| 182 | int b; // byte is signed, apparently?! XXX | ||
| 183 | for (i = 0; i < len; i++) { | ||
| 184 | // data[data_len] = Byte.parseByte( | ||
| 185 | // data_str.substring(i*2, i*2 + 2), | ||
| 186 | // 16); | ||
| 187 | b = Integer.parseInt( | ||
| 188 | data_str.substring(i*2, i*2 + 2), | ||
| 189 | 16); | ||
| 190 | if (b >= 128) | ||
| 191 | b *= -1; | ||
| 192 | data[data_len] = (byte) b; | ||
| 193 | data_len++; | ||
| 194 | } | ||
| 195 | } | ||
| 196 | } | ||
| 197 | } | ||
| 198 | 174 | ||
| 199 | Examples: | 175 | Examples: |
| 200 | 176 | ||
diff --git a/Documentation/video4linux/README.ivtv b/Documentation/video4linux/README.ivtv index 42b06686eb78..2579b5b709ed 100644 --- a/Documentation/video4linux/README.ivtv +++ b/Documentation/video4linux/README.ivtv | |||
| @@ -36,8 +36,7 @@ Additional features for the PVR-350 (CX23415 based): | |||
| 36 | * Provides comprehensive OSD (On Screen Display: ie. graphics overlaying the | 36 | * Provides comprehensive OSD (On Screen Display: ie. graphics overlaying the |
| 37 | video signal) | 37 | video signal) |
| 38 | * Provides a framebuffer (allowing X applications to appear on the video | 38 | * Provides a framebuffer (allowing X applications to appear on the video |
| 39 | device) (this framebuffer is not yet part of the kernel. In the meantime it | 39 | device) |
| 40 | is available from www.ivtvdriver.org). | ||
| 41 | * Supports raw YUV output. | 40 | * Supports raw YUV output. |
| 42 | 41 | ||
| 43 | IMPORTANT: In case of problems first read this page: | 42 | IMPORTANT: In case of problems first read this page: |
diff --git a/Documentation/video4linux/README.pvrusb2 b/Documentation/video4linux/README.pvrusb2 index a747200fe67c..2137b589276b 100644 --- a/Documentation/video4linux/README.pvrusb2 +++ b/Documentation/video4linux/README.pvrusb2 | |||
| @@ -172,7 +172,7 @@ Source file list / functional overview: | |||
| 172 | to provide a streaming API usable by a read() system call style of | 172 | to provide a streaming API usable by a read() system call style of |
| 173 | I/O. Right now this is the only layer on top of pvrusb2-io.[ch], | 173 | I/O. Right now this is the only layer on top of pvrusb2-io.[ch], |
| 174 | however the underlying architecture here was intended to allow for | 174 | however the underlying architecture here was intended to allow for |
| 175 | other styles of I/O to be implemented with additonal modules, like | 175 | other styles of I/O to be implemented with additional modules, like |
| 176 | mmap()'ed buffers or something even more exotic. | 176 | mmap()'ed buffers or something even more exotic. |
| 177 | 177 | ||
| 178 | pvrusb2-main.c - This is the top level of the driver. Module level | 178 | pvrusb2-main.c - This is the top level of the driver. Module level |
diff --git a/Documentation/video4linux/Zoran b/Documentation/video4linux/Zoran index 699b60e070d2..c40e3bab08fa 100644 --- a/Documentation/video4linux/Zoran +++ b/Documentation/video4linux/Zoran | |||
| @@ -130,7 +130,7 @@ Card number: 4 | |||
| 130 | 130 | ||
| 131 | Note: No module for the mse3000 is available yet | 131 | Note: No module for the mse3000 is available yet |
| 132 | Note: No module for the vpx3224 is available yet | 132 | Note: No module for the vpx3224 is available yet |
| 133 | Note: use encoder=X or decoder=X for non-default i2c chips (see i2c-id.h) | 133 | Note: use encoder=X or decoder=X for non-default i2c chips |
| 134 | 134 | ||
| 135 | =========================== | 135 | =========================== |
| 136 | 136 | ||
diff --git a/Documentation/video4linux/bttv/Insmod-options b/Documentation/video4linux/bttv/Insmod-options index bbe3ed667d91..14c065fa23ef 100644 --- a/Documentation/video4linux/bttv/Insmod-options +++ b/Documentation/video4linux/bttv/Insmod-options | |||
| @@ -1,5 +1,5 @@ | |||
| 1 | 1 | ||
| 2 | Note: "modinfo <module>" prints various informations about a kernel | 2 | Note: "modinfo <module>" prints various information about a kernel |
| 3 | module, among them a complete and up-to-date list of insmod options. | 3 | module, among them a complete and up-to-date list of insmod options. |
| 4 | This list tends to be outdated because it is updated manually ... | 4 | This list tends to be outdated because it is updated manually ... |
| 5 | 5 | ||
diff --git a/Documentation/video4linux/bttv/README b/Documentation/video4linux/bttv/README index 3a367cdb664e..7cbf4fb6cf31 100644 --- a/Documentation/video4linux/bttv/README +++ b/Documentation/video4linux/bttv/README | |||
| @@ -70,7 +70,7 @@ If you have trouble with some specific TV card, try to ask there | |||
| 70 | instead of mailing me directly. The chance that someone with the | 70 | instead of mailing me directly. The chance that someone with the |
| 71 | same card listens there is much higher... | 71 | same card listens there is much higher... |
| 72 | 72 | ||
| 73 | For problems with sound: There are alot of different systems used | 73 | For problems with sound: There are a lot of different systems used |
| 74 | for TV sound all over the world. And there are also different chips | 74 | for TV sound all over the world. And there are also different chips |
| 75 | which decode the audio signal. Reports about sound problems ("stereo | 75 | which decode the audio signal. Reports about sound problems ("stereo |
| 76 | does'nt work") are pretty useless unless you include some details | 76 | does'nt work") are pretty useless unless you include some details |
diff --git a/Documentation/video4linux/bttv/README.freeze b/Documentation/video4linux/bttv/README.freeze index 4259dccc8287..5eddfa076cfb 100644 --- a/Documentation/video4linux/bttv/README.freeze +++ b/Documentation/video4linux/bttv/README.freeze | |||
| @@ -33,7 +33,7 @@ state is stuck. | |||
| 33 | 33 | ||
| 34 | I've seen reports that bttv 0.7.x crashes whereas 0.8.x works rock solid | 34 | I've seen reports that bttv 0.7.x crashes whereas 0.8.x works rock solid |
| 35 | for some people. Thus probably a small buglet left somewhere in bttv | 35 | for some people. Thus probably a small buglet left somewhere in bttv |
| 36 | 0.7.x. I have no idea where exactly, it works stable for me and alot of | 36 | 0.7.x. I have no idea where exactly, it works stable for me and a lot of |
| 37 | other people. But in case you have problems with the 0.7.x versions you | 37 | other people. But in case you have problems with the 0.7.x versions you |
| 38 | can give 0.8.x a try ... | 38 | can give 0.8.x a try ... |
| 39 | 39 | ||
diff --git a/Documentation/video4linux/bttv/Sound-FAQ b/Documentation/video4linux/bttv/Sound-FAQ index 1e6328f91083..395f6c6fdd98 100644 --- a/Documentation/video4linux/bttv/Sound-FAQ +++ b/Documentation/video4linux/bttv/Sound-FAQ | |||
| @@ -2,13 +2,13 @@ | |||
| 2 | bttv and sound mini howto | 2 | bttv and sound mini howto |
| 3 | ========================= | 3 | ========================= |
| 4 | 4 | ||
| 5 | There are alot of different bt848/849/878/879 based boards available. | 5 | There are a lot of different bt848/849/878/879 based boards available. |
| 6 | Making video work often is not a big deal, because this is handled | 6 | Making video work often is not a big deal, because this is handled |
| 7 | completely by the bt8xx chip, which is common on all boards. But | 7 | completely by the bt8xx chip, which is common on all boards. But |
| 8 | sound is handled in slightly different ways on each board. | 8 | sound is handled in slightly different ways on each board. |
| 9 | 9 | ||
| 10 | To handle the grabber boards correctly, there is a array tvcards[] in | 10 | To handle the grabber boards correctly, there is a array tvcards[] in |
| 11 | bttv-cards.c, which holds the informations required for each board. | 11 | bttv-cards.c, which holds the information required for each board. |
| 12 | Sound will work only, if the correct entry is used (for video it often | 12 | Sound will work only, if the correct entry is used (for video it often |
| 13 | makes no difference). The bttv driver prints a line to the kernel | 13 | makes no difference). The bttv driver prints a line to the kernel |
| 14 | log, telling which card type is used. Like this one: | 14 | log, telling which card type is used. Like this one: |
diff --git a/Documentation/video4linux/et61x251.txt b/Documentation/video4linux/et61x251.txt index 1247566c4de3..e0cdae491858 100644 --- a/Documentation/video4linux/et61x251.txt +++ b/Documentation/video4linux/et61x251.txt | |||
| @@ -191,10 +191,10 @@ Syntax: <n> | |||
| 191 | Description: Debugging information level, from 0 to 3: | 191 | Description: Debugging information level, from 0 to 3: |
| 192 | 0 = none (use carefully) | 192 | 0 = none (use carefully) |
| 193 | 1 = critical errors | 193 | 1 = critical errors |
| 194 | 2 = significant informations | 194 | 2 = significant information |
| 195 | 3 = more verbose messages | 195 | 3 = more verbose messages |
| 196 | Level 3 is useful for testing only, when only one device | 196 | Level 3 is useful for testing only, when only one device |
| 197 | is used at the same time. It also shows some more informations | 197 | is used at the same time. It also shows some more information |
| 198 | about the hardware being detected. This module parameter can be | 198 | about the hardware being detected. This module parameter can be |
| 199 | changed at runtime thanks to the /sys filesystem interface. | 199 | changed at runtime thanks to the /sys filesystem interface. |
| 200 | Default: 2 | 200 | Default: 2 |
diff --git a/Documentation/video4linux/gspca.txt b/Documentation/video4linux/gspca.txt index 261776e0c5e1..5c542e60f51d 100644 --- a/Documentation/video4linux/gspca.txt +++ b/Documentation/video4linux/gspca.txt | |||
| @@ -103,6 +103,7 @@ spca561 046d:092d Logitech QC Elch2 | |||
| 103 | spca561 046d:092e Logitech QC Elch2 | 103 | spca561 046d:092e Logitech QC Elch2 |
| 104 | spca561 046d:092f Logitech QuickCam Express Plus | 104 | spca561 046d:092f Logitech QuickCam Express Plus |
| 105 | sunplus 046d:0960 Logitech ClickSmart 420 | 105 | sunplus 046d:0960 Logitech ClickSmart 420 |
| 106 | nw80x 046d:d001 Logitech QuickCam Pro (dark focus ring) | ||
| 106 | sunplus 0471:0322 Philips DMVC1300K | 107 | sunplus 0471:0322 Philips DMVC1300K |
| 107 | zc3xx 0471:0325 Philips SPC 200 NC | 108 | zc3xx 0471:0325 Philips SPC 200 NC |
| 108 | zc3xx 0471:0326 Philips SPC 300 NC | 109 | zc3xx 0471:0326 Philips SPC 300 NC |
| @@ -150,10 +151,12 @@ sunplus 04fc:5330 Digitrex 2110 | |||
| 150 | sunplus 04fc:5360 Sunplus Generic | 151 | sunplus 04fc:5360 Sunplus Generic |
| 151 | spca500 04fc:7333 PalmPixDC85 | 152 | spca500 04fc:7333 PalmPixDC85 |
| 152 | sunplus 04fc:ffff Pure DigitalDakota | 153 | sunplus 04fc:ffff Pure DigitalDakota |
| 154 | nw80x 0502:d001 DVC V6 | ||
| 153 | spca501 0506:00df 3Com HomeConnect Lite | 155 | spca501 0506:00df 3Com HomeConnect Lite |
| 154 | sunplus 052b:1507 Megapixel 5 Pretec DC-1007 | 156 | sunplus 052b:1507 Megapixel 5 Pretec DC-1007 |
| 155 | sunplus 052b:1513 Megapix V4 | 157 | sunplus 052b:1513 Megapix V4 |
| 156 | sunplus 052b:1803 MegaImage VI | 158 | sunplus 052b:1803 MegaImage VI |
| 159 | nw80x 052b:d001 EZCam Pro p35u | ||
| 157 | tv8532 0545:808b Veo Stingray | 160 | tv8532 0545:808b Veo Stingray |
| 158 | tv8532 0545:8333 Veo Stingray | 161 | tv8532 0545:8333 Veo Stingray |
| 159 | sunplus 0546:3155 Polaroid PDC3070 | 162 | sunplus 0546:3155 Polaroid PDC3070 |
| @@ -177,6 +180,7 @@ sunplus 055f:c530 Mustek Gsmart LCD 3 | |||
| 177 | sunplus 055f:c540 Gsmart D30 | 180 | sunplus 055f:c540 Gsmart D30 |
| 178 | sunplus 055f:c630 Mustek MDC4000 | 181 | sunplus 055f:c630 Mustek MDC4000 |
| 179 | sunplus 055f:c650 Mustek MDC5500Z | 182 | sunplus 055f:c650 Mustek MDC5500Z |
| 183 | nw80x 055f:d001 Mustek Wcam 300 mini | ||
| 180 | zc3xx 055f:d003 Mustek WCam300A | 184 | zc3xx 055f:d003 Mustek WCam300A |
| 181 | zc3xx 055f:d004 Mustek WCam300 AN | 185 | zc3xx 055f:d004 Mustek WCam300 AN |
| 182 | conex 0572:0041 Creative Notebook cx11646 | 186 | conex 0572:0041 Creative Notebook cx11646 |
| @@ -195,14 +199,20 @@ gl860 05e3:0503 Genesys Logic PC Camera | |||
| 195 | gl860 05e3:f191 Genesys Logic PC Camera | 199 | gl860 05e3:f191 Genesys Logic PC Camera |
| 196 | spca561 060b:a001 Maxell Compact Pc PM3 | 200 | spca561 060b:a001 Maxell Compact Pc PM3 |
| 197 | zc3xx 0698:2003 CTX M730V built in | 201 | zc3xx 0698:2003 CTX M730V built in |
| 202 | nw80x 06a5:0000 Typhoon Webcam 100 USB | ||
| 203 | nw80x 06a5:d001 Divio based webcams | ||
| 204 | nw80x 06a5:d800 Divio Chicony TwinkleCam, Trust SpaceCam | ||
| 198 | spca500 06bd:0404 Agfa CL20 | 205 | spca500 06bd:0404 Agfa CL20 |
| 199 | spca500 06be:0800 Optimedia | 206 | spca500 06be:0800 Optimedia |
| 207 | nw80x 06be:d001 EZCam Pro p35u | ||
| 200 | sunplus 06d6:0031 Trust 610 LCD PowerC@m Zoom | 208 | sunplus 06d6:0031 Trust 610 LCD PowerC@m Zoom |
| 201 | spca506 06e1:a190 ADS Instant VCD | 209 | spca506 06e1:a190 ADS Instant VCD |
| 210 | ov534 06f8:3002 Hercules Blog Webcam | ||
| 202 | ov534_9 06f8:3003 Hercules Dualpix HD Weblog | 211 | ov534_9 06f8:3003 Hercules Dualpix HD Weblog |
| 203 | sonixj 06f8:3004 Hercules Classic Silver | 212 | sonixj 06f8:3004 Hercules Classic Silver |
| 204 | sonixj 06f8:3008 Hercules Deluxe Optical Glass | 213 | sonixj 06f8:3008 Hercules Deluxe Optical Glass |
| 205 | pac7302 06f8:3009 Hercules Classic Link | 214 | pac7302 06f8:3009 Hercules Classic Link |
| 215 | nw80x 0728:d001 AVerMedia Camguard | ||
| 206 | spca508 0733:0110 ViewQuest VQ110 | 216 | spca508 0733:0110 ViewQuest VQ110 |
| 207 | spca501 0733:0401 Intel Create and Share | 217 | spca501 0733:0401 Intel Create and Share |
| 208 | spca501 0733:0402 ViewQuest M318B | 218 | spca501 0733:0402 ViewQuest M318B |
diff --git a/Documentation/video4linux/omap3isp.txt b/Documentation/video4linux/omap3isp.txt new file mode 100644 index 000000000000..69be2c782b98 --- /dev/null +++ b/Documentation/video4linux/omap3isp.txt | |||
| @@ -0,0 +1,278 @@ | |||
| 1 | OMAP 3 Image Signal Processor (ISP) driver | ||
| 2 | |||
| 3 | Copyright (C) 2010 Nokia Corporation | ||
| 4 | Copyright (C) 2009 Texas Instruments, Inc. | ||
| 5 | |||
| 6 | Contacts: Laurent Pinchart <laurent.pinchart@ideasonboard.com> | ||
| 7 | Sakari Ailus <sakari.ailus@iki.fi> | ||
| 8 | David Cohen <dacohen@gmail.com> | ||
| 9 | |||
| 10 | |||
| 11 | Introduction | ||
| 12 | ============ | ||
| 13 | |||
| 14 | This file documents the Texas Instruments OMAP 3 Image Signal Processor (ISP) | ||
| 15 | driver located under drivers/media/video/omap3isp. The original driver was | ||
| 16 | written by Texas Instruments but since that it has been rewritten (twice) at | ||
| 17 | Nokia. | ||
| 18 | |||
| 19 | The driver has been successfully used on the following versions of OMAP 3: | ||
| 20 | |||
| 21 | 3430 | ||
| 22 | 3530 | ||
| 23 | 3630 | ||
| 24 | |||
| 25 | The driver implements V4L2, Media controller and v4l2_subdev interfaces. | ||
| 26 | Sensor, lens and flash drivers using the v4l2_subdev interface in the kernel | ||
| 27 | are supported. | ||
| 28 | |||
| 29 | |||
| 30 | Split to subdevs | ||
| 31 | ================ | ||
| 32 | |||
| 33 | The OMAP 3 ISP is split into V4L2 subdevs, each of the blocks inside the ISP | ||
| 34 | having one subdev to represent it. Each of the subdevs provide a V4L2 subdev | ||
| 35 | interface to userspace. | ||
| 36 | |||
| 37 | OMAP3 ISP CCP2 | ||
| 38 | OMAP3 ISP CSI2a | ||
| 39 | OMAP3 ISP CCDC | ||
| 40 | OMAP3 ISP preview | ||
| 41 | OMAP3 ISP resizer | ||
| 42 | OMAP3 ISP AEWB | ||
| 43 | OMAP3 ISP AF | ||
| 44 | OMAP3 ISP histogram | ||
| 45 | |||
| 46 | Each possible link in the ISP is modelled by a link in the Media controller | ||
| 47 | interface. For an example program see [2]. | ||
| 48 | |||
| 49 | |||
| 50 | Controlling the OMAP 3 ISP | ||
| 51 | ========================== | ||
| 52 | |||
| 53 | In general, the settings given to the OMAP 3 ISP take effect at the beginning | ||
| 54 | of the following frame. This is done when the module becomes idle during the | ||
| 55 | vertical blanking period on the sensor. In memory-to-memory operation the pipe | ||
| 56 | is run one frame at a time. Applying the settings is done between the frames. | ||
| 57 | |||
| 58 | All the blocks in the ISP, excluding the CSI-2 and possibly the CCP2 receiver, | ||
| 59 | insist on receiving complete frames. Sensors must thus never send the ISP | ||
| 60 | partial frames. | ||
| 61 | |||
| 62 | Autoidle does have issues with some ISP blocks on the 3430, at least. | ||
| 63 | Autoidle is only enabled on 3630 when the omap3isp module parameter autoidle | ||
| 64 | is non-zero. | ||
| 65 | |||
| 66 | |||
| 67 | Events | ||
| 68 | ====== | ||
| 69 | |||
| 70 | The OMAP 3 ISP driver does support the V4L2 event interface on CCDC and | ||
| 71 | statistics (AEWB, AF and histogram) subdevs. | ||
| 72 | |||
| 73 | The CCDC subdev produces V4L2_EVENT_OMAP3ISP_HS_VS type event on HS_VS | ||
| 74 | interrupt which is used to signal frame start. The event is triggered exactly | ||
| 75 | when the reception of the first line of the frame starts in the CCDC module. | ||
| 76 | The event can be subscribed on the CCDC subdev. | ||
| 77 | |||
| 78 | (When using parallel interface one must pay account to correct configuration | ||
| 79 | of the VS signal polarity. This is automatically correct when using the serial | ||
| 80 | receivers.) | ||
| 81 | |||
| 82 | Each of the statistics subdevs is able to produce events. An event is | ||
| 83 | generated whenever a statistics buffer can be dequeued by a user space | ||
| 84 | application using the VIDIOC_OMAP3ISP_STAT_REQ IOCTL. The events available | ||
| 85 | are: | ||
| 86 | |||
| 87 | V4L2_EVENT_OMAP3ISP_AEWB | ||
| 88 | V4L2_EVENT_OMAP3ISP_AF | ||
| 89 | V4L2_EVENT_OMAP3ISP_HIST | ||
| 90 | |||
| 91 | The type of the event data is struct omap3isp_stat_event_status for these | ||
| 92 | ioctls. If there is an error calculating the statistics, there will be an | ||
| 93 | event as usual, but no related statistics buffer. In this case | ||
| 94 | omap3isp_stat_event_status.buf_err is set to non-zero. | ||
| 95 | |||
| 96 | |||
| 97 | Private IOCTLs | ||
| 98 | ============== | ||
| 99 | |||
| 100 | The OMAP 3 ISP driver supports standard V4L2 IOCTLs and controls where | ||
| 101 | possible and practical. Much of the functions provided by the ISP, however, | ||
| 102 | does not fall under the standard IOCTLs --- gamma tables and configuration of | ||
| 103 | statistics collection are examples of such. | ||
| 104 | |||
| 105 | In general, there is a private ioctl for configuring each of the blocks | ||
| 106 | containing hardware-dependent functions. | ||
| 107 | |||
| 108 | The following private IOCTLs are supported: | ||
| 109 | |||
| 110 | VIDIOC_OMAP3ISP_CCDC_CFG | ||
| 111 | VIDIOC_OMAP3ISP_PRV_CFG | ||
| 112 | VIDIOC_OMAP3ISP_AEWB_CFG | ||
| 113 | VIDIOC_OMAP3ISP_HIST_CFG | ||
| 114 | VIDIOC_OMAP3ISP_AF_CFG | ||
| 115 | VIDIOC_OMAP3ISP_STAT_REQ | ||
| 116 | VIDIOC_OMAP3ISP_STAT_EN | ||
| 117 | |||
| 118 | The parameter structures used by these ioctls are described in | ||
| 119 | include/linux/omap3isp.h. The detailed functions of the ISP itself related to | ||
| 120 | a given ISP block is described in the Technical Reference Manuals (TRMs) --- | ||
| 121 | see the end of the document for those. | ||
| 122 | |||
| 123 | While it is possible to use the ISP driver without any use of these private | ||
| 124 | IOCTLs it is not possible to obtain optimal image quality this way. The AEWB, | ||
| 125 | AF and histogram modules cannot be used without configuring them using the | ||
| 126 | appropriate private IOCTLs. | ||
| 127 | |||
| 128 | |||
| 129 | CCDC and preview block IOCTLs | ||
| 130 | ============================= | ||
| 131 | |||
| 132 | The VIDIOC_OMAP3ISP_CCDC_CFG and VIDIOC_OMAP3ISP_PRV_CFG IOCTLs are used to | ||
| 133 | configure, enable and disable functions in the CCDC and preview blocks, | ||
| 134 | respectively. Both IOCTLs control several functions in the blocks they | ||
| 135 | control. VIDIOC_OMAP3ISP_CCDC_CFG IOCTL accepts a pointer to struct | ||
| 136 | omap3isp_ccdc_update_config as its argument. Similarly VIDIOC_OMAP3ISP_PRV_CFG | ||
| 137 | accepts a pointer to struct omap3isp_prev_update_config. The definition of | ||
| 138 | both structures is available in [1]. | ||
| 139 | |||
| 140 | The update field in the structures tells whether to update the configuration | ||
| 141 | for the specific function and the flag tells whether to enable or disable the | ||
| 142 | function. | ||
| 143 | |||
| 144 | The update and flag bit masks accept the following values. Each separate | ||
| 145 | functions in the CCDC and preview blocks is associated with a flag (either | ||
| 146 | disable or enable; part of the flag field in the structure) and a pointer to | ||
| 147 | configuration data for the function. | ||
| 148 | |||
| 149 | Valid values for the update and flag fields are listed here for | ||
| 150 | VIDIOC_OMAP3ISP_CCDC_CFG. Values may be or'ed to configure more than one | ||
| 151 | function in the same IOCTL call. | ||
| 152 | |||
| 153 | OMAP3ISP_CCDC_ALAW | ||
| 154 | OMAP3ISP_CCDC_LPF | ||
| 155 | OMAP3ISP_CCDC_BLCLAMP | ||
| 156 | OMAP3ISP_CCDC_BCOMP | ||
| 157 | OMAP3ISP_CCDC_FPC | ||
| 158 | OMAP3ISP_CCDC_CULL | ||
| 159 | OMAP3ISP_CCDC_CONFIG_LSC | ||
| 160 | OMAP3ISP_CCDC_TBL_LSC | ||
| 161 | |||
| 162 | The corresponding values for the VIDIOC_OMAP3ISP_PRV_CFG are here: | ||
| 163 | |||
| 164 | OMAP3ISP_PREV_LUMAENH | ||
| 165 | OMAP3ISP_PREV_INVALAW | ||
| 166 | OMAP3ISP_PREV_HRZ_MED | ||
| 167 | OMAP3ISP_PREV_CFA | ||
| 168 | OMAP3ISP_PREV_CHROMA_SUPP | ||
| 169 | OMAP3ISP_PREV_WB | ||
| 170 | OMAP3ISP_PREV_BLKADJ | ||
| 171 | OMAP3ISP_PREV_RGB2RGB | ||
| 172 | OMAP3ISP_PREV_COLOR_CONV | ||
| 173 | OMAP3ISP_PREV_YC_LIMIT | ||
| 174 | OMAP3ISP_PREV_DEFECT_COR | ||
| 175 | OMAP3ISP_PREV_GAMMABYPASS | ||
| 176 | OMAP3ISP_PREV_DRK_FRM_CAPTURE | ||
| 177 | OMAP3ISP_PREV_DRK_FRM_SUBTRACT | ||
| 178 | OMAP3ISP_PREV_LENS_SHADING | ||
| 179 | OMAP3ISP_PREV_NF | ||
| 180 | OMAP3ISP_PREV_GAMMA | ||
| 181 | |||
| 182 | The associated configuration pointer for the function may not be NULL when | ||
| 183 | enabling the function. When disabling a function the configuration pointer is | ||
| 184 | ignored. | ||
| 185 | |||
| 186 | |||
| 187 | Statistic blocks IOCTLs | ||
| 188 | ======================= | ||
| 189 | |||
| 190 | The statistics subdevs do offer more dynamic configuration options than the | ||
| 191 | other subdevs. They can be enabled, disable and reconfigured when the pipeline | ||
| 192 | is in streaming state. | ||
| 193 | |||
| 194 | The statistics blocks always get the input image data from the CCDC (as the | ||
| 195 | histogram memory read isn't implemented). The statistics are dequeueable by | ||
| 196 | the user from the statistics subdev nodes using private IOCTLs. | ||
| 197 | |||
| 198 | The private IOCTLs offered by the AEWB, AF and histogram subdevs are heavily | ||
| 199 | reflected by the register level interface offered by the ISP hardware. There | ||
| 200 | are aspects that are purely related to the driver implementation and these are | ||
| 201 | discussed next. | ||
| 202 | |||
| 203 | VIDIOC_OMAP3ISP_STAT_EN | ||
| 204 | ----------------------- | ||
| 205 | |||
| 206 | This private IOCTL enables/disables a statistic module. If this request is | ||
| 207 | done before streaming, it will take effect as soon as the pipeline starts to | ||
| 208 | stream. If the pipeline is already streaming, it will take effect as soon as | ||
| 209 | the CCDC becomes idle. | ||
| 210 | |||
| 211 | VIDIOC_OMAP3ISP_AEWB_CFG, VIDIOC_OMAP3ISP_HIST_CFG and VIDIOC_OMAP3ISP_AF_CFG | ||
| 212 | ----------------------------------------------------------------------------- | ||
| 213 | |||
| 214 | Those IOCTLs are used to configure the modules. They require user applications | ||
| 215 | to have an in-depth knowledge of the hardware. Most of the fields explanation | ||
| 216 | can be found on OMAP's TRMs. The two following fields common to all the above | ||
| 217 | configure private IOCTLs require explanation for better understanding as they | ||
| 218 | are not part of the TRM. | ||
| 219 | |||
| 220 | omap3isp_[h3a_af/h3a_aewb/hist]_config.buf_size: | ||
| 221 | |||
| 222 | The modules handle their buffers internally. The necessary buffer size for the | ||
| 223 | module's data output depends on the requested configuration. Although the | ||
| 224 | driver supports reconfiguration while streaming, it does not support a | ||
| 225 | reconfiguration which requires bigger buffer size than what is already | ||
| 226 | internally allocated if the module is enabled. It will return -EBUSY on this | ||
| 227 | case. In order to avoid such condition, either disable/reconfigure/enable the | ||
| 228 | module or request the necessary buffer size during the first configuration | ||
| 229 | while the module is disabled. | ||
| 230 | |||
| 231 | The internal buffer size allocation considers the requested configuration's | ||
| 232 | minimum buffer size and the value set on buf_size field. If buf_size field is | ||
| 233 | out of [minimum, maximum] buffer size range, it's clamped to fit in there. | ||
| 234 | The driver then selects the biggest value. The corrected buf_size value is | ||
| 235 | written back to user application. | ||
| 236 | |||
| 237 | omap3isp_[h3a_af/h3a_aewb/hist]_config.config_counter: | ||
| 238 | |||
| 239 | As the configuration doesn't take effect synchronously to the request, the | ||
| 240 | driver must provide a way to track this information to provide more accurate | ||
| 241 | data. After a configuration is requested, the config_counter returned to user | ||
| 242 | space application will be an unique value associated to that request. When | ||
| 243 | user application receives an event for buffer availability or when a new | ||
| 244 | buffer is requested, this config_counter is used to match a buffer data and a | ||
| 245 | configuration. | ||
| 246 | |||
| 247 | VIDIOC_OMAP3ISP_STAT_REQ | ||
| 248 | ------------------------ | ||
| 249 | |||
| 250 | Send to user space the oldest data available in the internal buffer queue and | ||
| 251 | discards such buffer afterwards. The field omap3isp_stat_data.frame_number | ||
| 252 | matches with the video buffer's field_count. | ||
| 253 | |||
| 254 | |||
| 255 | Technical reference manuals (TRMs) and other documentation | ||
| 256 | ========================================================== | ||
| 257 | |||
| 258 | OMAP 3430 TRM: | ||
| 259 | <URL:http://focus.ti.com/pdfs/wtbu/OMAP34xx_ES3.1.x_PUBLIC_TRM_vZM.zip> | ||
| 260 | Referenced 2011-03-05. | ||
| 261 | |||
| 262 | OMAP 35xx TRM: | ||
| 263 | <URL:http://www.ti.com/litv/pdf/spruf98o> Referenced 2011-03-05. | ||
| 264 | |||
| 265 | OMAP 3630 TRM: | ||
| 266 | <URL:http://focus.ti.com/pdfs/wtbu/OMAP36xx_ES1.x_PUBLIC_TRM_vQ.zip> | ||
| 267 | Referenced 2011-03-05. | ||
| 268 | |||
| 269 | DM 3730 TRM: | ||
| 270 | <URL:http://www.ti.com/litv/pdf/sprugn4h> Referenced 2011-03-06. | ||
| 271 | |||
| 272 | |||
| 273 | References | ||
| 274 | ========== | ||
| 275 | |||
| 276 | [1] include/linux/omap3isp.h | ||
| 277 | |||
| 278 | [2] http://git.ideasonboard.org/?p=media-ctl.git;a=summary | ||
diff --git a/Documentation/video4linux/pxa_camera.txt b/Documentation/video4linux/pxa_camera.txt index 4f6d0ca01956..51ed1578b0e8 100644 --- a/Documentation/video4linux/pxa_camera.txt +++ b/Documentation/video4linux/pxa_camera.txt | |||
| @@ -84,12 +84,12 @@ DMA usage | |||
| 84 | transfer is not started. On "End Of Frame" interrupt, the irq handler | 84 | transfer is not started. On "End Of Frame" interrupt, the irq handler |
| 85 | starts the DMA chain. | 85 | starts the DMA chain. |
| 86 | - capture of one videobuffer | 86 | - capture of one videobuffer |
| 87 | The DMA chain starts transfering data into videobuffer RAM pages. | 87 | The DMA chain starts transferring data into videobuffer RAM pages. |
| 88 | When all pages are transfered, the DMA irq is raised on "ENDINTR" status | 88 | When all pages are transferred, the DMA irq is raised on "ENDINTR" status |
| 89 | - finishing one videobuffer | 89 | - finishing one videobuffer |
| 90 | The DMA irq handler marks the videobuffer as "done", and removes it from | 90 | The DMA irq handler marks the videobuffer as "done", and removes it from |
| 91 | the active running queue | 91 | the active running queue |
| 92 | Meanwhile, the next videobuffer (if there is one), is transfered by DMA | 92 | Meanwhile, the next videobuffer (if there is one), is transferred by DMA |
| 93 | - finishing the last videobuffer | 93 | - finishing the last videobuffer |
| 94 | On the DMA irq of the last videobuffer, the QCI is stopped. | 94 | On the DMA irq of the last videobuffer, the QCI is stopped. |
| 95 | 95 | ||
| @@ -101,7 +101,7 @@ DMA usage | |||
| 101 | 101 | ||
| 102 | This structure is pointed by dma->sg_cpu. | 102 | This structure is pointed by dma->sg_cpu. |
| 103 | The descriptors are used as follows : | 103 | The descriptors are used as follows : |
| 104 | - desc-sg[i]: i-th descriptor, transfering the i-th sg | 104 | - desc-sg[i]: i-th descriptor, transferring the i-th sg |
| 105 | element to the video buffer scatter gather | 105 | element to the video buffer scatter gather |
| 106 | - finisher: has ddadr=DADDR_STOP, dcmd=ENDIRQEN | 106 | - finisher: has ddadr=DADDR_STOP, dcmd=ENDIRQEN |
| 107 | - linker: has ddadr= desc-sg[0] of next video buffer, dcmd=0 | 107 | - linker: has ddadr= desc-sg[0] of next video buffer, dcmd=0 |
diff --git a/Documentation/video4linux/sn9c102.txt b/Documentation/video4linux/sn9c102.txt index 73de4050d637..b4f67040403a 100644 --- a/Documentation/video4linux/sn9c102.txt +++ b/Documentation/video4linux/sn9c102.txt | |||
| @@ -214,10 +214,10 @@ Syntax: <n> | |||
| 214 | Description: Debugging information level, from 0 to 3: | 214 | Description: Debugging information level, from 0 to 3: |
| 215 | 0 = none (use carefully) | 215 | 0 = none (use carefully) |
| 216 | 1 = critical errors | 216 | 1 = critical errors |
| 217 | 2 = significant informations | 217 | 2 = significant information |
| 218 | 3 = more verbose messages | 218 | 3 = more verbose messages |
| 219 | Level 3 is useful for testing only. It also shows some more | 219 | Level 3 is useful for testing only. It also shows some more |
| 220 | informations about the hardware being detected. | 220 | information about the hardware being detected. |
| 221 | This parameter can be changed at runtime thanks to the /sys | 221 | This parameter can be changed at runtime thanks to the /sys |
| 222 | filesystem interface. | 222 | filesystem interface. |
| 223 | Default: 2 | 223 | Default: 2 |
diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index f22f35c271f3..cf21f7aae976 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt | |||
| @@ -71,6 +71,10 @@ sub-device instances, the video_device struct stores V4L2 device node data | |||
| 71 | and in the future a v4l2_fh struct will keep track of filehandle instances | 71 | and in the future a v4l2_fh struct will keep track of filehandle instances |
| 72 | (this is not yet implemented). | 72 | (this is not yet implemented). |
| 73 | 73 | ||
| 74 | The V4L2 framework also optionally integrates with the media framework. If a | ||
| 75 | driver sets the struct v4l2_device mdev field, sub-devices and video nodes | ||
| 76 | will automatically appear in the media framework as entities. | ||
| 77 | |||
| 74 | 78 | ||
| 75 | struct v4l2_device | 79 | struct v4l2_device |
| 76 | ------------------ | 80 | ------------------ |
| @@ -83,11 +87,20 @@ You must register the device instance: | |||
| 83 | 87 | ||
| 84 | v4l2_device_register(struct device *dev, struct v4l2_device *v4l2_dev); | 88 | v4l2_device_register(struct device *dev, struct v4l2_device *v4l2_dev); |
| 85 | 89 | ||
| 86 | Registration will initialize the v4l2_device struct and link dev->driver_data | 90 | Registration will initialize the v4l2_device struct. If the dev->driver_data |
| 87 | to v4l2_dev. If v4l2_dev->name is empty then it will be set to a value derived | 91 | field is NULL, it will be linked to v4l2_dev. |
| 88 | from dev (driver name followed by the bus_id, to be precise). If you set it | 92 | |
| 89 | up before calling v4l2_device_register then it will be untouched. If dev is | 93 | Drivers that want integration with the media device framework need to set |
| 90 | NULL, then you *must* setup v4l2_dev->name before calling v4l2_device_register. | 94 | dev->driver_data manually to point to the driver-specific device structure |
| 95 | that embed the struct v4l2_device instance. This is achieved by a | ||
| 96 | dev_set_drvdata() call before registering the V4L2 device instance. They must | ||
| 97 | also set the struct v4l2_device mdev field to point to a properly initialized | ||
| 98 | and registered media_device instance. | ||
| 99 | |||
| 100 | If v4l2_dev->name is empty then it will be set to a value derived from dev | ||
| 101 | (driver name followed by the bus_id, to be precise). If you set it up before | ||
| 102 | calling v4l2_device_register then it will be untouched. If dev is NULL, then | ||
| 103 | you *must* setup v4l2_dev->name before calling v4l2_device_register. | ||
| 91 | 104 | ||
| 92 | You can use v4l2_device_set_name() to set the name based on a driver name and | 105 | You can use v4l2_device_set_name() to set the name based on a driver name and |
| 93 | a driver-global atomic_t instance. This will generate names like ivtv0, ivtv1, | 106 | a driver-global atomic_t instance. This will generate names like ivtv0, ivtv1, |
| @@ -108,6 +121,7 @@ You unregister with: | |||
| 108 | 121 | ||
| 109 | v4l2_device_unregister(struct v4l2_device *v4l2_dev); | 122 | v4l2_device_unregister(struct v4l2_device *v4l2_dev); |
| 110 | 123 | ||
| 124 | If the dev->driver_data field points to v4l2_dev, it will be reset to NULL. | ||
| 111 | Unregistering will also automatically unregister all subdevs from the device. | 125 | Unregistering will also automatically unregister all subdevs from the device. |
| 112 | 126 | ||
| 113 | If you have a hotpluggable device (e.g. a USB device), then when a disconnect | 127 | If you have a hotpluggable device (e.g. a USB device), then when a disconnect |
| @@ -167,6 +181,21 @@ static int __devinit drv_probe(struct pci_dev *pdev, | |||
| 167 | state->instance = atomic_inc_return(&drv_instance) - 1; | 181 | state->instance = atomic_inc_return(&drv_instance) - 1; |
| 168 | } | 182 | } |
| 169 | 183 | ||
| 184 | If you have multiple device nodes then it can be difficult to know when it is | ||
| 185 | safe to unregister v4l2_device. For this purpose v4l2_device has refcounting | ||
| 186 | support. The refcount is increased whenever video_register_device is called and | ||
| 187 | it is decreased whenever that device node is released. When the refcount reaches | ||
| 188 | zero, then the v4l2_device release() callback is called. You can do your final | ||
| 189 | cleanup there. | ||
| 190 | |||
| 191 | If other device nodes (e.g. ALSA) are created, then you can increase and | ||
| 192 | decrease the refcount manually as well by calling: | ||
| 193 | |||
| 194 | void v4l2_device_get(struct v4l2_device *v4l2_dev); | ||
| 195 | |||
| 196 | or: | ||
| 197 | |||
| 198 | int v4l2_device_put(struct v4l2_device *v4l2_dev); | ||
| 170 | 199 | ||
| 171 | struct v4l2_subdev | 200 | struct v4l2_subdev |
| 172 | ------------------ | 201 | ------------------ |
| @@ -254,6 +283,26 @@ A sub-device driver initializes the v4l2_subdev struct using: | |||
| 254 | Afterwards you need to initialize subdev->name with a unique name and set the | 283 | Afterwards you need to initialize subdev->name with a unique name and set the |
| 255 | module owner. This is done for you if you use the i2c helper functions. | 284 | module owner. This is done for you if you use the i2c helper functions. |
| 256 | 285 | ||
| 286 | If integration with the media framework is needed, you must initialize the | ||
| 287 | media_entity struct embedded in the v4l2_subdev struct (entity field) by | ||
| 288 | calling media_entity_init(): | ||
| 289 | |||
| 290 | struct media_pad *pads = &my_sd->pads; | ||
| 291 | int err; | ||
| 292 | |||
| 293 | err = media_entity_init(&sd->entity, npads, pads, 0); | ||
| 294 | |||
| 295 | The pads array must have been previously initialized. There is no need to | ||
| 296 | manually set the struct media_entity type and name fields, but the revision | ||
| 297 | field must be initialized if needed. | ||
| 298 | |||
| 299 | A reference to the entity will be automatically acquired/released when the | ||
| 300 | subdev device node (if any) is opened/closed. | ||
| 301 | |||
| 302 | Don't forget to cleanup the media entity before the sub-device is destroyed: | ||
| 303 | |||
| 304 | media_entity_cleanup(&sd->entity); | ||
| 305 | |||
| 257 | A device (bridge) driver needs to register the v4l2_subdev with the | 306 | A device (bridge) driver needs to register the v4l2_subdev with the |
| 258 | v4l2_device: | 307 | v4l2_device: |
| 259 | 308 | ||
| @@ -263,6 +312,9 @@ This can fail if the subdev module disappeared before it could be registered. | |||
| 263 | After this function was called successfully the subdev->dev field points to | 312 | After this function was called successfully the subdev->dev field points to |
| 264 | the v4l2_device. | 313 | the v4l2_device. |
| 265 | 314 | ||
| 315 | If the v4l2_device parent device has a non-NULL mdev field, the sub-device | ||
| 316 | entity will be automatically registered with the media device. | ||
| 317 | |||
| 266 | You can unregister a sub-device using: | 318 | You can unregister a sub-device using: |
| 267 | 319 | ||
| 268 | v4l2_device_unregister_subdev(sd); | 320 | v4l2_device_unregister_subdev(sd); |
| @@ -291,7 +343,7 @@ ignored. If you want to check for errors use this: | |||
| 291 | err = v4l2_device_call_until_err(v4l2_dev, 0, core, g_chip_ident, &chip); | 343 | err = v4l2_device_call_until_err(v4l2_dev, 0, core, g_chip_ident, &chip); |
| 292 | 344 | ||
| 293 | Any error except -ENOIOCTLCMD will exit the loop with that error. If no | 345 | Any error except -ENOIOCTLCMD will exit the loop with that error. If no |
| 294 | errors (except -ENOIOCTLCMD) occured, then 0 is returned. | 346 | errors (except -ENOIOCTLCMD) occurred, then 0 is returned. |
| 295 | 347 | ||
| 296 | The second argument to both calls is a group ID. If 0, then all subdevs are | 348 | The second argument to both calls is a group ID. If 0, then all subdevs are |
| 297 | called. If non-zero, then only those whose group ID match that value will | 349 | called. If non-zero, then only those whose group ID match that value will |
| @@ -319,6 +371,61 @@ controlled through GPIO pins. This distinction is only relevant when setting | |||
| 319 | up the device, but once the subdev is registered it is completely transparent. | 371 | up the device, but once the subdev is registered it is completely transparent. |
| 320 | 372 | ||
| 321 | 373 | ||
| 374 | V4L2 sub-device userspace API | ||
| 375 | ----------------------------- | ||
| 376 | |||
| 377 | Beside exposing a kernel API through the v4l2_subdev_ops structure, V4L2 | ||
| 378 | sub-devices can also be controlled directly by userspace applications. | ||
| 379 | |||
| 380 | Device nodes named v4l-subdevX can be created in /dev to access sub-devices | ||
| 381 | directly. If a sub-device supports direct userspace configuration it must set | ||
| 382 | the V4L2_SUBDEV_FL_HAS_DEVNODE flag before being registered. | ||
| 383 | |||
| 384 | After registering sub-devices, the v4l2_device driver can create device nodes | ||
| 385 | for all registered sub-devices marked with V4L2_SUBDEV_FL_HAS_DEVNODE by calling | ||
| 386 | v4l2_device_register_subdev_nodes(). Those device nodes will be automatically | ||
| 387 | removed when sub-devices are unregistered. | ||
| 388 | |||
| 389 | The device node handles a subset of the V4L2 API. | ||
| 390 | |||
| 391 | VIDIOC_QUERYCTRL | ||
| 392 | VIDIOC_QUERYMENU | ||
| 393 | VIDIOC_G_CTRL | ||
| 394 | VIDIOC_S_CTRL | ||
| 395 | VIDIOC_G_EXT_CTRLS | ||
| 396 | VIDIOC_S_EXT_CTRLS | ||
| 397 | VIDIOC_TRY_EXT_CTRLS | ||
| 398 | |||
| 399 | The controls ioctls are identical to the ones defined in V4L2. They | ||
| 400 | behave identically, with the only exception that they deal only with | ||
| 401 | controls implemented in the sub-device. Depending on the driver, those | ||
| 402 | controls can be also be accessed through one (or several) V4L2 device | ||
| 403 | nodes. | ||
| 404 | |||
| 405 | VIDIOC_DQEVENT | ||
| 406 | VIDIOC_SUBSCRIBE_EVENT | ||
| 407 | VIDIOC_UNSUBSCRIBE_EVENT | ||
| 408 | |||
| 409 | The events ioctls are identical to the ones defined in V4L2. They | ||
| 410 | behave identically, with the only exception that they deal only with | ||
| 411 | events generated by the sub-device. Depending on the driver, those | ||
| 412 | events can also be reported by one (or several) V4L2 device nodes. | ||
| 413 | |||
| 414 | Sub-device drivers that want to use events need to set the | ||
| 415 | V4L2_SUBDEV_USES_EVENTS v4l2_subdev::flags and initialize | ||
| 416 | v4l2_subdev::nevents to events queue depth before registering the | ||
| 417 | sub-device. After registration events can be queued as usual on the | ||
| 418 | v4l2_subdev::devnode device node. | ||
| 419 | |||
| 420 | To properly support events, the poll() file operation is also | ||
| 421 | implemented. | ||
| 422 | |||
| 423 | Private ioctls | ||
| 424 | |||
| 425 | All ioctls not in the above list are passed directly to the sub-device | ||
| 426 | driver through the core::ioctl operation. | ||
| 427 | |||
| 428 | |||
| 322 | I2C sub-device drivers | 429 | I2C sub-device drivers |
| 323 | ---------------------- | 430 | ---------------------- |
| 324 | 431 | ||
| @@ -457,6 +564,10 @@ You should also set these fields: | |||
| 457 | Otherwise you give it a pointer to a struct mutex_lock and before any | 564 | Otherwise you give it a pointer to a struct mutex_lock and before any |
| 458 | of the v4l2_file_operations is called this lock will be taken by the | 565 | of the v4l2_file_operations is called this lock will be taken by the |
| 459 | core and released afterwards. | 566 | core and released afterwards. |
| 567 | - prio: keeps track of the priorities. Used to implement VIDIOC_G/S_PRIORITY. | ||
| 568 | If left to NULL, then it will use the struct v4l2_prio_state in v4l2_device. | ||
| 569 | If you want to have a separate priority state per (group of) device node(s), | ||
| 570 | then you can point it to your own struct v4l2_prio_state. | ||
| 460 | - parent: you only set this if v4l2_device was registered with NULL as | 571 | - parent: you only set this if v4l2_device was registered with NULL as |
| 461 | the parent device struct. This only happens in cases where one hardware | 572 | the parent device struct. This only happens in cases where one hardware |
| 462 | device has multiple PCI devices that all share the same v4l2_device core. | 573 | device has multiple PCI devices that all share the same v4l2_device core. |
| @@ -466,13 +577,34 @@ You should also set these fields: | |||
| 466 | (cx8802). Since the v4l2_device cannot be associated with a particular | 577 | (cx8802). Since the v4l2_device cannot be associated with a particular |
| 467 | PCI device it is setup without a parent device. But when the struct | 578 | PCI device it is setup without a parent device. But when the struct |
| 468 | video_device is setup you do know which parent PCI device to use. | 579 | video_device is setup you do know which parent PCI device to use. |
| 580 | - flags: optional. Set to V4L2_FL_USE_FH_PRIO if you want to let the framework | ||
| 581 | handle the VIDIOC_G/S_PRIORITY ioctls. This requires that you use struct | ||
| 582 | v4l2_fh. Eventually this flag will disappear once all drivers use the core | ||
| 583 | priority handling. But for now it has to be set explicitly. | ||
| 469 | 584 | ||
| 470 | If you use v4l2_ioctl_ops, then you should set either .unlocked_ioctl or | 585 | If you use v4l2_ioctl_ops, then you should set .unlocked_ioctl to video_ioctl2 |
| 471 | .ioctl to video_ioctl2 in your v4l2_file_operations struct. | 586 | in your v4l2_file_operations struct. |
| 587 | |||
| 588 | Do not use .ioctl! This is deprecated and will go away in the future. | ||
| 472 | 589 | ||
| 473 | The v4l2_file_operations struct is a subset of file_operations. The main | 590 | The v4l2_file_operations struct is a subset of file_operations. The main |
| 474 | difference is that the inode argument is omitted since it is never used. | 591 | difference is that the inode argument is omitted since it is never used. |
| 475 | 592 | ||
| 593 | If integration with the media framework is needed, you must initialize the | ||
| 594 | media_entity struct embedded in the video_device struct (entity field) by | ||
| 595 | calling media_entity_init(): | ||
| 596 | |||
| 597 | struct media_pad *pad = &my_vdev->pad; | ||
| 598 | int err; | ||
| 599 | |||
| 600 | err = media_entity_init(&vdev->entity, 1, pad, 0); | ||
| 601 | |||
| 602 | The pads array must have been previously initialized. There is no need to | ||
| 603 | manually set the struct media_entity type and name fields. | ||
| 604 | |||
| 605 | A reference to the entity will be automatically acquired/released when the | ||
| 606 | video device is opened/closed. | ||
| 607 | |||
| 476 | v4l2_file_operations and locking | 608 | v4l2_file_operations and locking |
| 477 | -------------------------------- | 609 | -------------------------------- |
| 478 | 610 | ||
| @@ -502,6 +634,9 @@ for you. | |||
| 502 | return err; | 634 | return err; |
| 503 | } | 635 | } |
| 504 | 636 | ||
| 637 | If the v4l2_device parent device has a non-NULL mdev field, the video device | ||
| 638 | entity will be automatically registered with the media device. | ||
| 639 | |||
| 505 | Which device is registered depends on the type argument. The following | 640 | Which device is registered depends on the type argument. The following |
| 506 | types exist: | 641 | types exist: |
| 507 | 642 | ||
| @@ -577,6 +712,13 @@ release, of course) will return an error as well. | |||
| 577 | When the last user of the video device node exits, then the vdev->release() | 712 | When the last user of the video device node exits, then the vdev->release() |
| 578 | callback is called and you can do the final cleanup there. | 713 | callback is called and you can do the final cleanup there. |
| 579 | 714 | ||
| 715 | Don't forget to cleanup the media entity associated with the video device if | ||
| 716 | it has been initialized: | ||
| 717 | |||
| 718 | media_entity_cleanup(&vdev->entity); | ||
| 719 | |||
| 720 | This can be done from the release callback. | ||
| 721 | |||
| 580 | 722 | ||
| 581 | video_device helper functions | 723 | video_device helper functions |
| 582 | ----------------------------- | 724 | ----------------------------- |
| @@ -636,39 +778,25 @@ struct v4l2_fh | |||
| 636 | -------------- | 778 | -------------- |
| 637 | 779 | ||
| 638 | struct v4l2_fh provides a way to easily keep file handle specific data | 780 | struct v4l2_fh provides a way to easily keep file handle specific data |
| 639 | that is used by the V4L2 framework. Using v4l2_fh is optional for | 781 | that is used by the V4L2 framework. New drivers must use struct v4l2_fh |
| 640 | drivers. | 782 | since it is also used to implement priority handling (VIDIOC_G/S_PRIORITY) |
| 783 | if the video_device flag V4L2_FL_USE_FH_PRIO is also set. | ||
| 641 | 784 | ||
| 642 | The users of v4l2_fh (in the V4L2 framework, not the driver) know | 785 | The users of v4l2_fh (in the V4L2 framework, not the driver) know |
| 643 | whether a driver uses v4l2_fh as its file->private_data pointer by | 786 | whether a driver uses v4l2_fh as its file->private_data pointer by |
| 644 | testing the V4L2_FL_USES_V4L2_FH bit in video_device->flags. | 787 | testing the V4L2_FL_USES_V4L2_FH bit in video_device->flags. This bit is |
| 645 | 788 | set whenever v4l2_fh_init() is called. | |
| 646 | Useful functions: | ||
| 647 | |||
| 648 | - v4l2_fh_init() | ||
| 649 | |||
| 650 | Initialise the file handle. This *MUST* be performed in the driver's | ||
| 651 | v4l2_file_operations->open() handler. | ||
| 652 | |||
| 653 | - v4l2_fh_add() | ||
| 654 | 789 | ||
| 655 | Add a v4l2_fh to video_device file handle list. May be called after | 790 | struct v4l2_fh is allocated as a part of the driver's own file handle |
| 656 | initialising the file handle. | 791 | structure and file->private_data is set to it in the driver's open |
| 657 | 792 | function by the driver. | |
| 658 | - v4l2_fh_del() | ||
| 659 | |||
| 660 | Unassociate the file handle from video_device(). The file handle | ||
| 661 | exit function may now be called. | ||
| 662 | 793 | ||
| 663 | - v4l2_fh_exit() | 794 | In many cases the struct v4l2_fh will be embedded in a larger structure. |
| 795 | In that case you should call v4l2_fh_init+v4l2_fh_add in open() and | ||
| 796 | v4l2_fh_del+v4l2_fh_exit in release(). | ||
| 664 | 797 | ||
| 665 | Uninitialise the file handle. After uninitialisation the v4l2_fh | 798 | Drivers can extract their own file handle structure by using the container_of |
| 666 | memory can be freed. | 799 | macro. Example: |
| 667 | |||
| 668 | struct v4l2_fh is allocated as a part of the driver's own file handle | ||
| 669 | structure and is set to file->private_data in the driver's open | ||
| 670 | function by the driver. Drivers can extract their own file handle | ||
| 671 | structure by using the container_of macro. Example: | ||
| 672 | 800 | ||
| 673 | struct my_fh { | 801 | struct my_fh { |
| 674 | int blah; | 802 | int blah; |
| @@ -685,15 +813,21 @@ int my_open(struct file *file) | |||
| 685 | 813 | ||
| 686 | ... | 814 | ... |
| 687 | 815 | ||
| 816 | my_fh = kzalloc(sizeof(*my_fh), GFP_KERNEL); | ||
| 817 | |||
| 818 | ... | ||
| 819 | |||
| 688 | ret = v4l2_fh_init(&my_fh->fh, vfd); | 820 | ret = v4l2_fh_init(&my_fh->fh, vfd); |
| 689 | if (ret) | 821 | if (ret) { |
| 822 | kfree(my_fh); | ||
| 690 | return ret; | 823 | return ret; |
| 824 | } | ||
| 691 | 825 | ||
| 692 | v4l2_fh_add(&my_fh->fh); | 826 | ... |
| 693 | 827 | ||
| 694 | file->private_data = &my_fh->fh; | 828 | file->private_data = &my_fh->fh; |
| 695 | 829 | v4l2_fh_add(&my_fh->fh); | |
| 696 | ... | 830 | return 0; |
| 697 | } | 831 | } |
| 698 | 832 | ||
| 699 | int my_release(struct file *file) | 833 | int my_release(struct file *file) |
| @@ -702,8 +836,65 @@ int my_release(struct file *file) | |||
| 702 | struct my_fh *my_fh = container_of(fh, struct my_fh, fh); | 836 | struct my_fh *my_fh = container_of(fh, struct my_fh, fh); |
| 703 | 837 | ||
| 704 | ... | 838 | ... |
| 839 | v4l2_fh_del(&my_fh->fh); | ||
| 840 | v4l2_fh_exit(&my_fh->fh); | ||
| 841 | kfree(my_fh); | ||
| 842 | return 0; | ||
| 705 | } | 843 | } |
| 706 | 844 | ||
| 845 | Below is a short description of the v4l2_fh functions used: | ||
| 846 | |||
| 847 | int v4l2_fh_init(struct v4l2_fh *fh, struct video_device *vdev) | ||
| 848 | |||
| 849 | Initialise the file handle. This *MUST* be performed in the driver's | ||
| 850 | v4l2_file_operations->open() handler. | ||
| 851 | |||
| 852 | void v4l2_fh_add(struct v4l2_fh *fh) | ||
| 853 | |||
| 854 | Add a v4l2_fh to video_device file handle list. Must be called once the | ||
| 855 | file handle is completely initialized. | ||
| 856 | |||
| 857 | void v4l2_fh_del(struct v4l2_fh *fh) | ||
| 858 | |||
| 859 | Unassociate the file handle from video_device(). The file handle | ||
| 860 | exit function may now be called. | ||
| 861 | |||
| 862 | void v4l2_fh_exit(struct v4l2_fh *fh) | ||
| 863 | |||
| 864 | Uninitialise the file handle. After uninitialisation the v4l2_fh | ||
| 865 | memory can be freed. | ||
| 866 | |||
| 867 | |||
| 868 | If struct v4l2_fh is not embedded, then you can use these helper functions: | ||
| 869 | |||
| 870 | int v4l2_fh_open(struct file *filp) | ||
| 871 | |||
| 872 | This allocates a struct v4l2_fh, initializes it and adds it to the struct | ||
| 873 | video_device associated with the file struct. | ||
| 874 | |||
| 875 | int v4l2_fh_release(struct file *filp) | ||
| 876 | |||
| 877 | This deletes it from the struct video_device associated with the file | ||
| 878 | struct, uninitialised the v4l2_fh and frees it. | ||
| 879 | |||
| 880 | These two functions can be plugged into the v4l2_file_operation's open() and | ||
| 881 | release() ops. | ||
| 882 | |||
| 883 | |||
| 884 | Several drivers need to do something when the first file handle is opened and | ||
| 885 | when the last file handle closes. Two helper functions were added to check | ||
| 886 | whether the v4l2_fh struct is the only open filehandle of the associated | ||
| 887 | device node: | ||
| 888 | |||
| 889 | int v4l2_fh_is_singular(struct v4l2_fh *fh) | ||
| 890 | |||
| 891 | Returns 1 if the file handle is the only open file handle, else 0. | ||
| 892 | |||
| 893 | int v4l2_fh_is_singular_file(struct file *filp) | ||
| 894 | |||
| 895 | Same, but it calls v4l2_fh_is_singular with filp->private_data. | ||
| 896 | |||
| 897 | |||
| 707 | V4L2 events | 898 | V4L2 events |
| 708 | ----------- | 899 | ----------- |
| 709 | 900 | ||
diff --git a/Documentation/video4linux/w9968cf.txt b/Documentation/video4linux/w9968cf.txt index 05138e8aea07..9649450f3b90 100644 --- a/Documentation/video4linux/w9968cf.txt +++ b/Documentation/video4linux/w9968cf.txt | |||
| @@ -413,7 +413,7 @@ Syntax: <n> | |||
| 413 | Description: Debugging information level, from 0 to 6: | 413 | Description: Debugging information level, from 0 to 6: |
| 414 | 0 = none (use carefully) | 414 | 0 = none (use carefully) |
| 415 | 1 = critical errors | 415 | 1 = critical errors |
| 416 | 2 = significant informations | 416 | 2 = significant information |
| 417 | 3 = configuration or general messages | 417 | 3 = configuration or general messages |
| 418 | 4 = warnings | 418 | 4 = warnings |
| 419 | 5 = called functions | 419 | 5 = called functions |
diff --git a/Documentation/video4linux/zc0301.txt b/Documentation/video4linux/zc0301.txt index befdfdacdc5b..b41c83cf09f4 100644 --- a/Documentation/video4linux/zc0301.txt +++ b/Documentation/video4linux/zc0301.txt | |||
| @@ -181,10 +181,10 @@ Syntax: <n> | |||
| 181 | Description: Debugging information level, from 0 to 3: | 181 | Description: Debugging information level, from 0 to 3: |
| 182 | 0 = none (use carefully) | 182 | 0 = none (use carefully) |
| 183 | 1 = critical errors | 183 | 1 = critical errors |
| 184 | 2 = significant informations | 184 | 2 = significant information |
| 185 | 3 = more verbose messages | 185 | 3 = more verbose messages |
| 186 | Level 3 is useful for testing only, when only one device | 186 | Level 3 is useful for testing only, when only one device |
| 187 | is used at the same time. It also shows some more informations | 187 | is used at the same time. It also shows some information |
| 188 | about the hardware being detected. This module parameter can be | 188 | about the hardware being detected. This module parameter can be |
| 189 | changed at runtime thanks to the /sys filesystem interface. | 189 | changed at runtime thanks to the /sys filesystem interface. |
| 190 | Default: 2 | 190 | Default: 2 |
| @@ -261,7 +261,7 @@ the fingerprint is: '88E8 F32F 7244 68BA 3958 5D40 99DA 5D2A FCE6 35A4'. | |||
| 261 | 261 | ||
| 262 | 11. Credits | 262 | 11. Credits |
| 263 | =========== | 263 | =========== |
| 264 | - Informations about the chip internals needed to enable the I2C protocol have | 264 | - Information about the chip internals needed to enable the I2C protocol have |
| 265 | been taken from the documentation of the ZC030x Video4Linux1 driver written | 265 | been taken from the documentation of the ZC030x Video4Linux1 driver written |
| 266 | by Andrew Birkett <andy@nobugs.org>; | 266 | by Andrew Birkett <andy@nobugs.org>; |
| 267 | - The initialization values of the ZC0301 controller connected to the PAS202BCB | 267 | - The initialization values of the ZC0301 controller connected to the PAS202BCB |
diff --git a/Documentation/vm/active_mm.txt b/Documentation/vm/active_mm.txt index 4ee1f643d897..dbf45817405f 100644 --- a/Documentation/vm/active_mm.txt +++ b/Documentation/vm/active_mm.txt | |||
| @@ -74,7 +74,7 @@ we have a user context", and is generally done by the page fault handler | |||
| 74 | and things like that). | 74 | and things like that). |
| 75 | 75 | ||
| 76 | Anyway, I put a pre-patch-2.3.13-1 on ftp.kernel.org just a moment ago, | 76 | Anyway, I put a pre-patch-2.3.13-1 on ftp.kernel.org just a moment ago, |
| 77 | because it slightly changes the interfaces to accomodate the alpha (who | 77 | because it slightly changes the interfaces to accommodate the alpha (who |
| 78 | would have thought it, but the alpha actually ends up having one of the | 78 | would have thought it, but the alpha actually ends up having one of the |
| 79 | ugliest context switch codes - unlike the other architectures where the MM | 79 | ugliest context switch codes - unlike the other architectures where the MM |
| 80 | and register state is separate, the alpha PALcode joins the two, and you | 80 | and register state is separate, the alpha PALcode joins the two, and you |
diff --git a/Documentation/vm/hugetlbpage.txt b/Documentation/vm/hugetlbpage.txt index 457634c1e03e..f8551b3879f8 100644 --- a/Documentation/vm/hugetlbpage.txt +++ b/Documentation/vm/hugetlbpage.txt | |||
| @@ -72,7 +72,7 @@ number of huge pages requested. This is the most reliable method of | |||
| 72 | allocating huge pages as memory has not yet become fragmented. | 72 | allocating huge pages as memory has not yet become fragmented. |
| 73 | 73 | ||
| 74 | Some platforms support multiple huge page sizes. To allocate huge pages | 74 | Some platforms support multiple huge page sizes. To allocate huge pages |
| 75 | of a specific size, one must preceed the huge pages boot command parameters | 75 | of a specific size, one must precede the huge pages boot command parameters |
| 76 | with a huge page size selection parameter "hugepagesz=<size>". <size> must | 76 | with a huge page size selection parameter "hugepagesz=<size>". <size> must |
| 77 | be specified in bytes with optional scale suffix [kKmMgG]. The default huge | 77 | be specified in bytes with optional scale suffix [kKmMgG]. The default huge |
| 78 | page size may be selected with the "default_hugepagesz=<size>" boot parameter. | 78 | page size may be selected with the "default_hugepagesz=<size>" boot parameter. |
diff --git a/Documentation/vm/overcommit-accounting b/Documentation/vm/overcommit-accounting index 21c7b1f8f32b..706d7ed9d8d2 100644 --- a/Documentation/vm/overcommit-accounting +++ b/Documentation/vm/overcommit-accounting | |||
| @@ -4,7 +4,7 @@ The Linux kernel supports the following overcommit handling modes | |||
| 4 | address space are refused. Used for a typical system. It | 4 | address space are refused. Used for a typical system. It |
| 5 | ensures a seriously wild allocation fails while allowing | 5 | ensures a seriously wild allocation fails while allowing |
| 6 | overcommit to reduce swap usage. root is allowed to | 6 | overcommit to reduce swap usage. root is allowed to |
| 7 | allocate slighly more memory in this mode. This is the | 7 | allocate slightly more memory in this mode. This is the |
| 8 | default. | 8 | default. |
| 9 | 9 | ||
| 10 | 1 - Always overcommit. Appropriate for some scientific | 10 | 1 - Always overcommit. Appropriate for some scientific |
diff --git a/Documentation/vm/page-types.c b/Documentation/vm/page-types.c index cc96ee2666f2..7445caa26d05 100644 --- a/Documentation/vm/page-types.c +++ b/Documentation/vm/page-types.c | |||
| @@ -32,8 +32,20 @@ | |||
| 32 | #include <sys/types.h> | 32 | #include <sys/types.h> |
| 33 | #include <sys/errno.h> | 33 | #include <sys/errno.h> |
| 34 | #include <sys/fcntl.h> | 34 | #include <sys/fcntl.h> |
| 35 | #include <sys/mount.h> | ||
| 36 | #include <sys/statfs.h> | ||
| 37 | #include "../../include/linux/magic.h" | ||
| 35 | 38 | ||
| 36 | 39 | ||
| 40 | #ifndef MAX_PATH | ||
| 41 | # define MAX_PATH 256 | ||
| 42 | #endif | ||
| 43 | |||
| 44 | #ifndef STR | ||
| 45 | # define _STR(x) #x | ||
| 46 | # define STR(x) _STR(x) | ||
| 47 | #endif | ||
| 48 | |||
| 37 | /* | 49 | /* |
| 38 | * pagemap kernel ABI bits | 50 | * pagemap kernel ABI bits |
| 39 | */ | 51 | */ |
| @@ -152,6 +164,12 @@ static const char *page_flag_names[] = { | |||
| 152 | }; | 164 | }; |
| 153 | 165 | ||
| 154 | 166 | ||
| 167 | static const char *debugfs_known_mountpoints[] = { | ||
| 168 | "/sys/kernel/debug", | ||
| 169 | "/debug", | ||
| 170 | 0, | ||
| 171 | }; | ||
| 172 | |||
| 155 | /* | 173 | /* |
| 156 | * data structures | 174 | * data structures |
| 157 | */ | 175 | */ |
| @@ -184,7 +202,7 @@ static int kpageflags_fd; | |||
| 184 | static int opt_hwpoison; | 202 | static int opt_hwpoison; |
| 185 | static int opt_unpoison; | 203 | static int opt_unpoison; |
| 186 | 204 | ||
| 187 | static const char hwpoison_debug_fs[] = "/debug/hwpoison"; | 205 | static char hwpoison_debug_fs[MAX_PATH+1]; |
| 188 | static int hwpoison_inject_fd; | 206 | static int hwpoison_inject_fd; |
| 189 | static int hwpoison_forget_fd; | 207 | static int hwpoison_forget_fd; |
| 190 | 208 | ||
| @@ -464,21 +482,100 @@ static uint64_t kpageflags_flags(uint64_t flags) | |||
| 464 | return flags; | 482 | return flags; |
| 465 | } | 483 | } |
| 466 | 484 | ||
| 485 | /* verify that a mountpoint is actually a debugfs instance */ | ||
| 486 | static int debugfs_valid_mountpoint(const char *debugfs) | ||
| 487 | { | ||
| 488 | struct statfs st_fs; | ||
| 489 | |||
| 490 | if (statfs(debugfs, &st_fs) < 0) | ||
| 491 | return -ENOENT; | ||
| 492 | else if (st_fs.f_type != (long) DEBUGFS_MAGIC) | ||
| 493 | return -ENOENT; | ||
| 494 | |||
| 495 | return 0; | ||
| 496 | } | ||
| 497 | |||
| 498 | /* find the path to the mounted debugfs */ | ||
| 499 | static const char *debugfs_find_mountpoint(void) | ||
| 500 | { | ||
| 501 | const char **ptr; | ||
| 502 | char type[100]; | ||
| 503 | FILE *fp; | ||
| 504 | |||
| 505 | ptr = debugfs_known_mountpoints; | ||
| 506 | while (*ptr) { | ||
| 507 | if (debugfs_valid_mountpoint(*ptr) == 0) { | ||
| 508 | strcpy(hwpoison_debug_fs, *ptr); | ||
| 509 | return hwpoison_debug_fs; | ||
| 510 | } | ||
| 511 | ptr++; | ||
| 512 | } | ||
| 513 | |||
| 514 | /* give up and parse /proc/mounts */ | ||
| 515 | fp = fopen("/proc/mounts", "r"); | ||
| 516 | if (fp == NULL) | ||
| 517 | perror("Can't open /proc/mounts for read"); | ||
| 518 | |||
| 519 | while (fscanf(fp, "%*s %" | ||
| 520 | STR(MAX_PATH) | ||
| 521 | "s %99s %*s %*d %*d\n", | ||
| 522 | hwpoison_debug_fs, type) == 2) { | ||
| 523 | if (strcmp(type, "debugfs") == 0) | ||
| 524 | break; | ||
| 525 | } | ||
| 526 | fclose(fp); | ||
| 527 | |||
| 528 | if (strcmp(type, "debugfs") != 0) | ||
| 529 | return NULL; | ||
| 530 | |||
| 531 | return hwpoison_debug_fs; | ||
| 532 | } | ||
| 533 | |||
| 534 | /* mount the debugfs somewhere if it's not mounted */ | ||
| 535 | |||
| 536 | static void debugfs_mount(void) | ||
| 537 | { | ||
| 538 | const char **ptr; | ||
| 539 | |||
| 540 | /* see if it's already mounted */ | ||
| 541 | if (debugfs_find_mountpoint()) | ||
| 542 | return; | ||
| 543 | |||
| 544 | ptr = debugfs_known_mountpoints; | ||
| 545 | while (*ptr) { | ||
| 546 | if (mount(NULL, *ptr, "debugfs", 0, NULL) == 0) { | ||
| 547 | /* save the mountpoint */ | ||
| 548 | strcpy(hwpoison_debug_fs, *ptr); | ||
| 549 | break; | ||
| 550 | } | ||
| 551 | ptr++; | ||
| 552 | } | ||
| 553 | |||
| 554 | if (*ptr == NULL) { | ||
| 555 | perror("mount debugfs"); | ||
| 556 | exit(EXIT_FAILURE); | ||
| 557 | } | ||
| 558 | } | ||
| 559 | |||
| 467 | /* | 560 | /* |
| 468 | * page actions | 561 | * page actions |
| 469 | */ | 562 | */ |
| 470 | 563 | ||
| 471 | static void prepare_hwpoison_fd(void) | 564 | static void prepare_hwpoison_fd(void) |
| 472 | { | 565 | { |
| 473 | char buf[100]; | 566 | char buf[MAX_PATH + 1]; |
| 567 | |||
| 568 | debugfs_mount(); | ||
| 474 | 569 | ||
| 475 | if (opt_hwpoison && !hwpoison_inject_fd) { | 570 | if (opt_hwpoison && !hwpoison_inject_fd) { |
| 476 | sprintf(buf, "%s/corrupt-pfn", hwpoison_debug_fs); | 571 | snprintf(buf, MAX_PATH, "%s/hwpoison/corrupt-pfn", |
| 572 | hwpoison_debug_fs); | ||
| 477 | hwpoison_inject_fd = checked_open(buf, O_WRONLY); | 573 | hwpoison_inject_fd = checked_open(buf, O_WRONLY); |
| 478 | } | 574 | } |
| 479 | 575 | ||
| 480 | if (opt_unpoison && !hwpoison_forget_fd) { | 576 | if (opt_unpoison && !hwpoison_forget_fd) { |
| 481 | sprintf(buf, "%s/unpoison-pfn", hwpoison_debug_fs); | 577 | snprintf(buf, MAX_PATH, "%s/hwpoison/unpoison-pfn", |
| 578 | hwpoison_debug_fs); | ||
| 482 | hwpoison_forget_fd = checked_open(buf, O_WRONLY); | 579 | hwpoison_forget_fd = checked_open(buf, O_WRONLY); |
| 483 | } | 580 | } |
| 484 | } | 581 | } |
diff --git a/Documentation/vm/unevictable-lru.txt b/Documentation/vm/unevictable-lru.txt index 2d70d0d95108..97bae3c576c2 100644 --- a/Documentation/vm/unevictable-lru.txt +++ b/Documentation/vm/unevictable-lru.txt | |||
| @@ -84,8 +84,7 @@ indicate that the page is being managed on the unevictable list. | |||
| 84 | 84 | ||
| 85 | The PG_unevictable flag is analogous to, and mutually exclusive with, the | 85 | The PG_unevictable flag is analogous to, and mutually exclusive with, the |
| 86 | PG_active flag in that it indicates on which LRU list a page resides when | 86 | PG_active flag in that it indicates on which LRU list a page resides when |
| 87 | PG_lru is set. The unevictable list is compile-time configurable based on the | 87 | PG_lru is set. |
| 88 | UNEVICTABLE_LRU Kconfig option. | ||
| 89 | 88 | ||
| 90 | The Unevictable LRU infrastructure maintains unevictable pages on an additional | 89 | The Unevictable LRU infrastructure maintains unevictable pages on an additional |
| 91 | LRU list for a few reasons: | 90 | LRU list for a few reasons: |
diff --git a/Documentation/w1/slaves/w1_ds2423 b/Documentation/w1/slaves/w1_ds2423 index 90a65d23cf59..3f98b505a0ee 100644 --- a/Documentation/w1/slaves/w1_ds2423 +++ b/Documentation/w1/slaves/w1_ds2423 | |||
| @@ -21,8 +21,8 @@ value and associated ram buffer is outpputed to own line. | |||
| 21 | 21 | ||
| 22 | Each lines will contain the values of 42 bytes read from the counter and | 22 | Each lines will contain the values of 42 bytes read from the counter and |
| 23 | memory page along the crc=YES or NO for indicating whether the read operation | 23 | memory page along the crc=YES or NO for indicating whether the read operation |
| 24 | was successfull and CRC matched. | 24 | was successful and CRC matched. |
| 25 | If the operation was successfull, there is also in the end of each line | 25 | If the operation was successful, there is also in the end of each line |
| 26 | a counter value expressed as an integer after c= | 26 | a counter value expressed as an integer after c= |
| 27 | 27 | ||
| 28 | Meaning of 42 bytes represented is following: | 28 | Meaning of 42 bytes represented is following: |
| @@ -34,7 +34,7 @@ Meaning of 42 bytes represented is following: | |||
| 34 | - crc=YES/NO indicating whether read was ok and crc matched | 34 | - crc=YES/NO indicating whether read was ok and crc matched |
| 35 | - c=<int> current counter value | 35 | - c=<int> current counter value |
| 36 | 36 | ||
| 37 | example from the successfull read: | 37 | example from the successful read: |
| 38 | 00 02 00 00 00 00 00 00 00 6d 38 00 ff ff 00 00 fe ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff crc=YES c=2 | 38 | 00 02 00 00 00 00 00 00 00 6d 38 00 ff ff 00 00 fe ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff crc=YES c=2 |
| 39 | 00 02 00 00 00 00 00 00 00 e0 1f 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff crc=YES c=2 | 39 | 00 02 00 00 00 00 00 00 00 e0 1f 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff crc=YES c=2 |
| 40 | 00 29 c6 5d 18 00 00 00 00 04 37 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff crc=YES c=408798761 | 40 | 00 29 c6 5d 18 00 00 00 00 04 37 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff crc=YES c=408798761 |
diff --git a/Documentation/w1/w1.netlink b/Documentation/w1/w1.netlink index 804445f745ed..f59a31965d50 100644 --- a/Documentation/w1/w1.netlink +++ b/Documentation/w1/w1.netlink | |||
| @@ -81,7 +81,7 @@ which will contain list of all registered master ids in the following | |||
| 81 | format: | 81 | format: |
| 82 | 82 | ||
| 83 | cn_msg (CN_W1_IDX.CN_W1_VAL as id, len is equal to sizeof(struct | 83 | cn_msg (CN_W1_IDX.CN_W1_VAL as id, len is equal to sizeof(struct |
| 84 | w1_netlink_msg) plus number of masters multipled by 4) | 84 | w1_netlink_msg) plus number of masters multiplied by 4) |
| 85 | w1_netlink_msg (type: W1_LIST_MASTERS, len is equal to | 85 | w1_netlink_msg (type: W1_LIST_MASTERS, len is equal to |
| 86 | number of masters multiplied by 4 (u32 size)) | 86 | number of masters multiplied by 4 (u32 size)) |
| 87 | id0 ... idN | 87 | id0 ... idN |
diff --git a/Documentation/watchdog/hpwdt.txt b/Documentation/watchdog/hpwdt.txt index 9c24d5ffbb06..9488078900e0 100644 --- a/Documentation/watchdog/hpwdt.txt +++ b/Documentation/watchdog/hpwdt.txt | |||
| @@ -8,7 +8,7 @@ Last reviewed: 06/02/2009 | |||
| 8 | The HP iLO2 NMI Watchdog driver is a kernel module that provides basic | 8 | The HP iLO2 NMI Watchdog driver is a kernel module that provides basic |
| 9 | watchdog functionality and the added benefit of NMI sourcing. Both the | 9 | watchdog functionality and the added benefit of NMI sourcing. Both the |
| 10 | watchdog functionality and the NMI sourcing capability need to be enabled | 10 | watchdog functionality and the NMI sourcing capability need to be enabled |
| 11 | by the user. Remember that the two modes are not dependant on one another. | 11 | by the user. Remember that the two modes are not dependent on one another. |
| 12 | A user can have the NMI sourcing without the watchdog timer and vice-versa. | 12 | A user can have the NMI sourcing without the watchdog timer and vice-versa. |
| 13 | 13 | ||
| 14 | Watchdog functionality is enabled like any other common watchdog driver. That | 14 | Watchdog functionality is enabled like any other common watchdog driver. That |
diff --git a/Documentation/workqueue.txt b/Documentation/workqueue.txt index 996a27d9b8db..01c513fac40e 100644 --- a/Documentation/workqueue.txt +++ b/Documentation/workqueue.txt | |||
| @@ -190,9 +190,9 @@ resources, scheduled and executed. | |||
| 190 | * Long running CPU intensive workloads which can be better | 190 | * Long running CPU intensive workloads which can be better |
| 191 | managed by the system scheduler. | 191 | managed by the system scheduler. |
| 192 | 192 | ||
| 193 | WQ_FREEZEABLE | 193 | WQ_FREEZABLE |
| 194 | 194 | ||
| 195 | A freezeable wq participates in the freeze phase of the system | 195 | A freezable wq participates in the freeze phase of the system |
| 196 | suspend operations. Work items on the wq are drained and no | 196 | suspend operations. Work items on the wq are drained and no |
| 197 | new work item starts execution until thawed. | 197 | new work item starts execution until thawed. |
| 198 | 198 | ||
diff --git a/Documentation/x86/x86_64/boot-options.txt b/Documentation/x86/x86_64/boot-options.txt index 7fbbaf85f5b7..092e596a1301 100644 --- a/Documentation/x86/x86_64/boot-options.txt +++ b/Documentation/x86/x86_64/boot-options.txt | |||
| @@ -189,13 +189,13 @@ ACPI | |||
| 189 | 189 | ||
| 190 | PCI | 190 | PCI |
| 191 | 191 | ||
| 192 | pci=off Don't use PCI | 192 | pci=off Don't use PCI |
| 193 | pci=conf1 Use conf1 access. | 193 | pci=conf1 Use conf1 access. |
| 194 | pci=conf2 Use conf2 access. | 194 | pci=conf2 Use conf2 access. |
| 195 | pci=rom Assign ROMs. | 195 | pci=rom Assign ROMs. |
| 196 | pci=assign-busses Assign busses | 196 | pci=assign-busses Assign busses |
| 197 | pci=irqmask=MASK Set PCI interrupt mask to MASK | 197 | pci=irqmask=MASK Set PCI interrupt mask to MASK |
| 198 | pci=lastbus=NUMBER Scan upto NUMBER busses, no matter what the mptable says. | 198 | pci=lastbus=NUMBER Scan up to NUMBER busses, no matter what the mptable says. |
| 199 | pci=noacpi Don't use ACPI to set up PCI interrupt routing. | 199 | pci=noacpi Don't use ACPI to set up PCI interrupt routing. |
| 200 | 200 | ||
| 201 | IOMMU (input/output memory management unit) | 201 | IOMMU (input/output memory management unit) |
| @@ -293,11 +293,6 @@ IOMMU (input/output memory management unit) | |||
| 293 | 293 | ||
| 294 | Debugging | 294 | Debugging |
| 295 | 295 | ||
| 296 | oops=panic Always panic on oopses. Default is to just kill the process, | ||
| 297 | but there is a small probability of deadlocking the machine. | ||
| 298 | This will also cause panics on machine check exceptions. | ||
| 299 | Useful together with panic=30 to trigger a reboot. | ||
| 300 | |||
| 301 | kstack=N Print N words from the kernel stack in oops dumps. | 296 | kstack=N Print N words from the kernel stack in oops dumps. |
| 302 | 297 | ||
| 303 | pagefaulttrace Dump all page faults. Only useful for extreme debugging | 298 | pagefaulttrace Dump all page faults. Only useful for extreme debugging |
diff --git a/Documentation/zh_CN/SecurityBugs b/Documentation/zh_CN/SecurityBugs new file mode 100644 index 000000000000..d21eb07fe943 --- /dev/null +++ b/Documentation/zh_CN/SecurityBugs | |||
| @@ -0,0 +1,50 @@ | |||
| 1 | Chinese translated version of Documentation/SecurityBugs | ||
| 2 | |||
| 3 | If you have any comment or update to the content, please contact the | ||
| 4 | original document maintainer directly. However, if you have a problem | ||
| 5 | communicating in English you can also ask the Chinese maintainer for | ||
| 6 | help. Contact the Chinese maintainer if this translation is outdated | ||
| 7 | or if there is a problem with the translation. | ||
| 8 | |||
| 9 | Chinese maintainer: Harry Wei <harryxiyou@gmail.com> | ||
| 10 | --------------------------------------------------------------------- | ||
| 11 | Documentation/SecurityBugs 鐨勪腑鏂囩炕璇 | ||
| 12 | |||
| 13 | 濡傛灉鎯宠瘎璁烘垨鏇存柊鏈枃鐨勫唴瀹癸紝璇风洿鎺ヨ仈绯诲師鏂囨。鐨勭淮鎶よ呫傚鏋滀綘浣跨敤鑻辨枃 | ||
| 14 | 浜ゆ祦鏈夊洶闅剧殑璇濓紝涔熷彲浠ュ悜涓枃鐗堢淮鎶よ呮眰鍔┿傚鏋滄湰缈昏瘧鏇存柊涓嶅強鏃舵垨鑰呯炕 | ||
| 15 | 璇戝瓨鍦ㄩ棶棰橈紝璇疯仈绯讳腑鏂囩増缁存姢鑰呫 | ||
| 16 | |||
| 17 | 涓枃鐗堢淮鎶よ咃細 璐惧▉濞 Harry Wei <harryxiyou@gmail.com> | ||
| 18 | 涓枃鐗堢炕璇戣咃細 璐惧▉濞 Harry Wei <harryxiyou@gmail.com> | ||
| 19 | 涓枃鐗堟牎璇戣咃細 璐惧▉濞 Harry Wei <harryxiyou@gmail.com> | ||
| 20 | |||
| 21 | |||
| 22 | 浠ヤ笅涓烘鏂 | ||
| 23 | --------------------------------------------------------------------- | ||
| 24 | Linux鍐呮牳寮鍙戣呰涓哄畨鍏ㄩ潪甯搁噸瑕併傚洜姝わ紝鎴戜滑鎯宠鐭ラ亾褰撲竴涓湁鍏充簬 | ||
| 25 | 瀹夊叏鐨勬紡娲炶鍙戠幇鐨勬椂鍊欙紝骞朵笖瀹冨彲鑳戒細琚敖蹇殑淇鎴栬呭叕寮銆傝鎶婅繖涓畨鍏 | ||
| 26 | 婕忔礊鎶ュ憡缁橪inux鍐呮牳瀹夊叏鍥㈤槦銆 | ||
| 27 | |||
| 28 | 1) 鑱旂郴 | ||
| 29 | |||
| 30 | linux鍐呮牳瀹夊叏鍥㈤槦鍙互閫氳繃email<security@kernel.org>鏉ヨ仈绯汇傝繖鏄 | ||
| 31 | 涓缁勭嫭绔嬬殑瀹夊叏宸ヤ綔浜哄憳锛屽彲浠ュ府鍔╂敼鍠勬紡娲炴姤鍛婂苟涓斿叕甯冨拰鍙栨秷涓涓慨澶嶃傚畨 | ||
| 32 | 鍏ㄥ洟闃熸湁鍙兘浼氫粠閮ㄥ垎鐨勭淮鎶よ呴偅閲屽紩杩涢澶栫殑甯姪鏉ヤ簡瑙ｅ苟涓斾慨澶嶅畨鍏ㄦ紡娲炪 | ||
| 33 | 褰撻亣鍒颁换浣曟紡娲烇紝鎵鑳芥彁渚涚殑淇℃伅瓒婂灏辫秺鑳借瘖鏂拰淇銆傚鏋滀綘涓嶆竻妤氫粈涔 | ||
| 34 | 鏄湁甯姪鐨勪俊鎭紝閭ｅ氨璇烽噸娓╀竴涓婻EPORTING-BUGS鏂囦欢涓殑姒傝堪杩囩▼銆備换 | ||
| 35 | 浣曟敾鍑绘х殑浠ｇ爜閮芥槸闈炲父鏈夌敤鐨勶紝鏈粡鎶ュ憡鑰呯殑鍚屾剰涓嶄細琚彇娑堬紝闄ら潪瀹冨凡缁 | ||
| 36 | 琚叕甯冧簬浼椼 | ||
| 37 | |||
| 38 | 2) 鍏紑 | ||
| 39 | |||
| 40 | Linux鍐呮牳瀹夊叏鍥㈤槦鐨勫畻鏃ㄥ氨鏄拰婕忔礊鎻愪氦鑰呬竴璧峰鐞嗘紡娲炵殑瑙ｅ喅鏂规鐩 | ||
| 41 | 鍒板叕寮銆傛垜浠枩娆㈠敖蹇湴瀹屽叏鍏紑婕忔礊銆傚綋涓涓紡娲炴垨鑰呬慨澶嶈繕娌℃湁琚畬鍏ㄥ湴鐞 | ||
| 42 | 瑙ｏ紝瑙ｅ喅鏂规娌℃湁閫氳繃娴嬭瘯鎴栬呬緵搴斿晢鍗忚皟锛屽彲浠ュ悎鐞嗗湴寤惰繜鍏紑銆傜劧鑰岋紝鎴戜滑 | ||
| 43 | 鏈熸湜杩欎簺寤惰繜灏藉彲鑳界殑鐭簺锛屾槸鍙暟鐨勫嚑澶╋紝鑰屼笉鏄嚑涓槦鏈熸垨鑰呭嚑涓湀銆傚叕寮 | ||
| 44 | 鏃ユ湡鏄氳繃瀹夊叏鍥㈤槦鍜屾紡娲炴彁渚涜呬互鍙婁緵搴斿晢娲借皥鍚庣殑缁撴灉銆傚叕寮鏃堕棿琛ㄦ槸浠庡緢 | ||
| 45 | 鐭紙鐗规畩鐨勶紝瀹冨凡缁忚鍏紬鎵鐭ラ亾锛夊埌鍑犱釜鏄熸湡銆備綔涓轰竴涓熀鏈殑榛樿鏀跨瓥锛屾垜 | ||
| 46 | 浠墍鏈熸湜閫氱煡鍏紬鐨勬棩鏈熸槸7澶╃殑瀹夋帓銆 | ||
| 47 | |||
| 48 | 3) 淇濆瘑鍗忚 | ||
| 49 | |||
| 50 | Linux鍐呮牳瀹夊叏鍥㈤槦涓嶆槸涓涓寮忕殑鍥綋锛屽洜姝や笉鑳藉姞鍏ヤ换浣曠殑淇濆瘑鍗忚銆 | ||
diff --git a/Documentation/zh_CN/SubmitChecklist b/Documentation/zh_CN/SubmitChecklist new file mode 100644 index 000000000000..951415bbab0c --- /dev/null +++ b/Documentation/zh_CN/SubmitChecklist | |||
| @@ -0,0 +1,109 @@ | |||
| 1 | Chinese translated version of Documentation/SubmitChecklist | ||
| 2 | |||
| 3 | If you have any comment or update to the content, please contact the | ||
| 4 | original document maintainer directly. However, if you have a problem | ||
| 5 | communicating in English you can also ask the Chinese maintainer for | ||
| 6 | help. Contact the Chinese maintainer if this translation is outdated | ||
| 7 | or if there is a problem with the translation. | ||
| 8 | |||
| 9 | Chinese maintainer: Harry Wei <harryxiyou@gmail.com> | ||
| 10 | --------------------------------------------------------------------- | ||
| 11 | Documentation/SubmitChecklist 的中文翻译 | ||
| 12 | |||
| 13 | 如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文 | ||
| 14 | 交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻 | ||
| 15 | 译存在问题，请联系中文版维护者。 | ||
| 16 | |||
| 17 | 中文版维护者： 贾威威 Harry Wei <harryxiyou@gmail.com> | ||
| 18 | 中文版翻译者： 贾威威 Harry Wei <harryxiyou@gmail.com> | ||
| 19 | 中文版校译者： 贾威威 Harry Wei <harryxiyou@gmail.com> | ||
| 20 | |||
| 21 | |||
| 22 | 以下为正文 | ||
| 23 | --------------------------------------------------------------------- | ||
| 24 | Linux内核提交清单 | ||
| 25 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
| 26 | |||
| 27 | 这里有一些内核开发者应该做的基本事情，如果他们想看到自己的内核补丁提交 | ||
| 28 | 被接受的更快。 | ||
| 29 | |||
| 30 | 这些都是超出Documentation/SubmittingPatches文档里所提供的以及其他 | ||
| 31 | 关于提交Linux内核补丁的说明。 | ||
| 32 | |||
| 33 | 1：如果你使用了一个功能那么就#include定义/声明那个功能的那个文件。 | ||
| 34 | 不要依靠其他间接引入定义/声明那个功能的头文件。 | ||
| 35 | |||
| 36 | 2：构建简洁适用或者更改CONFIG选项 =y，=m，或者=n。 | ||
| 37 | 不要有编译警告/错误， 不要有链接警告/错误。 | ||
| 38 | |||
| 39 | 2b：通过 allnoconfig, allmodconfig | ||
| 40 | |||
| 41 | 2c：当使用 0=builddir 成功地构建 | ||
| 42 | |||
| 43 | 3：通过使用本地交叉编译工具或者其他一些构建产所，在多CPU框架上构建。 | ||
| 44 | |||
| 45 | 4：ppc64 是一个很好的检查交叉编译的框架，因为它往往把‘unsigned long’ | ||
| 46 | 当64位值来使用。 | ||
| 47 | |||
| 48 | 5：按照Documentation/CodingStyle文件里的详细描述，检查你补丁的整体风格。 | ||
| 49 | 使用补丁风格检查琐碎的违规(scripts/checkpatch.pl)，审核员优先提交。 | ||
| 50 | 你应该调整遗留在你补丁中的所有违规。 | ||
| 51 | |||
| 52 | 6：任何更新或者改动CONFIG选项都不能打乱配置菜单。 | ||
| 53 | |||
| 54 | 7：所有的Kconfig选项更新都要有说明文字。 | ||
| 55 | |||
| 56 | 8：已经认真地总结了相关的Kconfig组合。这是很难通过测试做好的--脑力在这里下降。 | ||
| 57 | |||
| 58 | 9：检查具有简洁性。 | ||
| 59 | |||
| 60 | 10：使用'make checkstack'和'make namespacecheck'检查，然后修改所找到的问题。 | ||
| 61 | 注意：堆栈检查不会明确地出现问题，但是任何的一个函数在堆栈上使用多于512字节 | ||
| 62 | 都要准备修改。 | ||
| 63 | |||
| 64 | 11：包含kernel-doc到全局内核APIs文件。（不要求静态的函数，但是包含也无所谓。） | ||
| 65 | 使用'make htmldocs'或者'make mandocs'来检查kernel-doc，然后修改任何 | ||
| 66 | 发现的问题。 | ||
| 67 | |||
| 68 | 12：已经通过CONFIG_PREEMPT, CONFIG_DEBUG_PREEMPT, | ||
| 69 | CONFIG_DEBUG_SLAB, CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES, | ||
| 70 | CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_SPINLOCK_SLEEP测试，并且同时都 | ||
| 71 | 使能。 | ||
| 72 | |||
| 73 | 13：已经都构建并且使用或者不使用 CONFIG_SMP 和 CONFIG_PREEMPT测试执行时间。 | ||
| 74 | |||
| 75 | 14：如果补丁影响IO/Disk，等等：已经通过使用或者不使用 CONFIG_LBDAF 测试。 | ||
| 76 | |||
| 77 | 15：所有的codepaths已经行使所有lockdep启用功能。 | ||
| 78 | |||
| 79 | 16：所有的/proc记录更新都要作成文件放在Documentation/目录下。 | ||
| 80 | |||
| 81 | 17：所有的内核启动参数更新都被记录到Documentation/kernel-parameters.txt文件中。 | ||
| 82 | |||
| 83 | 18：所有的模块参数更新都用MODULE_PARM_DESC()记录。 | ||
| 84 | |||
| 85 | 19：所有的用户空间接口更新都被记录到Documentation/ABI/。查看Documentation/ABI/README | ||
| 86 | 可以获得更多的信息。改变用户空间接口的补丁应该被邮件抄送给linux-api@vger.kernel.org。 | ||
| 87 | |||
| 88 | 20：检查它是不是都通过`make headers_check'。 | ||
| 89 | |||
| 90 | 21：已经通过至少引入slab和page-allocation失败检查。查看Documentation/fault-injection/。 | ||
| 91 | |||
| 92 | 22：新加入的源码已经通过`gcc -W'（使用"make EXTRA_CFLAGS=-W"）编译。这样将产生很多烦恼， | ||
| 93 | 但是对于寻找漏洞很有益处，例如:"warning: comparison between signed and unsigned"。 | ||
| 94 | |||
| 95 | 23：当它被合并到-mm补丁集后再测试，用来确定它是否还和补丁队列中的其他补丁一起工作以及在VM，VFS | ||
| 96 | 和其他子系统中各个变化。 | ||
| 97 | |||
| 98 | 24：所有的内存屏障{e.g., barrier(), rmb(), wmb()}需要在源代码中的一个注释来解释他们都是干什么的 | ||
| 99 | 以及原因。 | ||
| 100 | |||
| 101 | 25：如果有任何输入输出控制的补丁被添加，也要更新Documentation/ioctl/ioctl-number.txt。 | ||
| 102 | |||
| 103 | 26：如果你的更改代码依靠或者使用任何的内核APIs或者与下面的kconfig符号有关系的功能，你就要 | ||
| 104 | 使用相关的kconfig符号关闭， and/or =m（如果选项提供）[在同一时间不是所用的都启用，仅仅各个或者自由 | ||
| 105 | 组合他们]： | ||
| 106 | |||
| 107 | CONFIG_SMP, CONFIG_SYSFS, CONFIG_PROC_FS, CONFIG_INPUT, CONFIG_PCI, | ||
| 108 | CONFIG_BLOCK, CONFIG_PM, CONFIG_HOTPLUG, CONFIG_MAGIC_SYSRQ, | ||
| 109 | CONFIG_NET, CONFIG_INET=n (后一个使用 CONFIG_NET=y) | ||
diff --git a/Documentation/zh_CN/SubmittingPatches b/Documentation/zh_CN/SubmittingPatches index 9a1a6e1ed09e..0f4385a62a49 100644 --- a/Documentation/zh_CN/SubmittingPatches +++ b/Documentation/zh_CN/SubmittingPatches | |||
| @@ -100,7 +100,7 @@ http://userweb.kernel.org/~akpm/stuff/patch-scripts.tar.gz | |||
| 100 | 100 | ||
| 101 | 灏嗘敼鍔ㄦ媶鍒嗭紝閫昏緫绫讳技鐨勬斁鍒板悓涓涓ˉ涓佹枃浠堕噷銆 | 101 | 灏嗘敼鍔ㄦ媶鍒嗭紝閫昏緫绫讳技鐨勬斁鍒板悓涓涓ˉ涓佹枃浠堕噷銆 |
| 102 | 102 | ||
| 103 | 渚嬪锛屽鏋滀綘鐨勬敼鍔ㄩ噷鍚屾椂鏈塨ug淇鍜屾ц兘浼樺寲锛岄偅涔堟妸杩欎簺鏀瑰姩墠鍒嗗埌涓や釜鎴 | 103 | 渚嬪锛屽鏋滀綘鐨勬敼鍔ㄩ噷鍚屾椂鏈塨ug淇鍜屾ц兘浼樺寲锛岄偅涔堟妸杩欎簺鏀瑰姩媶鍒嗗埌涓や釜鎴 |
| 104 | 鑰呮洿澶氱殑琛ヤ竵鏂囦欢涓傚鏋滀綘鐨勬敼鍔ㄥ寘鍚API鐨勪慨鏀癸紝骞朵笖淇敼浜嗛┍鍔ㄧ▼搴忔潵閫 | 104 | 鑰呮洿澶氱殑琛ヤ竵鏂囦欢涓傚鏋滀綘鐨勬敼鍔ㄥ寘鍚API鐨勪慨鏀癸紝骞朵笖淇敼浜嗛┍鍔ㄧ▼搴忔潵閫 |
| 105 | 搴旇繖浜涙柊鐨凙PI锛岄偅涔堟妸杩欎簺淇敼鍒嗘垚涓や釜琛ヤ竵銆 | 105 | 搴旇繖浜涙柊鐨凙PI锛岄偅涔堟妸杩欎簺淇敼鍒嗘垚涓や釜琛ヤ竵銆 |
| 106 | 106 | ||
| @@ -230,7 +230,7 @@ pref("mailnews.display.disable_format_flowed_support", true); | |||
| 230 | 浜涘師鍥狅紝淇閿欒锛岄噸鏂版彁浜ゆ洿鏂板悗鐨勬敼鍔紝鏄綘鑷繁鐨勫伐浣溿 | 230 | 浜涘師鍥狅紝淇閿欒锛岄噸鏂版彁浜ゆ洿鏂板悗鐨勬敼鍔紝鏄綘鑷繁鐨勫伐浣溿 |
| 231 | 231 | ||
| 232 | Linus涓嶇粰鍑轰换浣曡瘎璁哄氨鈥滀涪寮冣濅綘鐨勮ˉ涓佹槸甯歌鐨勪簨鎯呫傚湪绯荤粺涓繖鏍风殑浜嬫儏寰 | 232 | Linus涓嶇粰鍑轰换浣曡瘎璁哄氨鈥滀涪寮冣濅綘鐨勮ˉ涓佹槸甯歌鐨勪簨鎯呫傚湪绯荤粺涓繖鏍风殑浜嬫儏寰 |
| 233 | 骞冲父銆傚鏋滀粬娌℃湁鎺ュ彈浣犵殑琛ヤ竵锛屼篃璁告槸鐢变簬浠ヤ笅鍘鏈锛 | 233 | 骞冲父銆傚鏋滀粬娌℃湁鎺ュ彈浣犵殑琛ヤ竵锛屼篃璁告槸鐢变簬浠ヤ笅鍘鍥锛 |
| 234 | * 浣犵殑琛ヤ竵涓嶈兘鍦ㄦ渶鏂扮増鏈殑鍐呮牳涓婂共鍑鐨勬墦涓娿 | 234 | * 浣犵殑琛ヤ竵涓嶈兘鍦ㄦ渶鏂扮増鏈殑鍐呮牳涓婂共鍑鐨勬墦涓娿 |
| 235 | * 浣犵殑琛ヤ竵鍦 linux-kernel 閭欢鍒楄〃涓病鏈夊緱鍒板厖鍒嗙殑璁ㄨ銆 | 235 | * 浣犵殑琛ヤ竵鍦 linux-kernel 閭欢鍒楄〃涓病鏈夊緱鍒板厖鍒嗙殑璁ㄨ銆 |
| 236 | * 椋庢牸闂锛堝弬鐓х2灏忚妭锛 | 236 | * 椋庢牸闂锛堝弬鐓х2灏忚妭锛 |
diff --git a/Documentation/zh_CN/magic-number.txt b/Documentation/zh_CN/magic-number.txt new file mode 100644 index 000000000000..4c4ce853577b --- /dev/null +++ b/Documentation/zh_CN/magic-number.txt | |||
| @@ -0,0 +1,167 @@ | |||
| 1 | Chinese translated version of Documentation/magic-number.txt | ||
| 2 | |||
| 3 | If you have any comment or update to the content, please post to LKML directly. | ||
| 4 | However, if you have problem communicating in English you can also ask the | ||
| 5 | Chinese maintainer for help. Contact the Chinese maintainer, if this | ||
| 6 | translation is outdated or there is problem with translation. | ||
| 7 | |||
| 8 | Chinese maintainer: Jia Wei Wei <harryxiyou@gmail.com> | ||
| 9 | --------------------------------------------------------------------- | ||
| 10 | Documentation/magic-number.txt鐨勪腑鏂囩炕璇 | ||
| 11 | |||
| 12 | 濡傛灉鎯宠瘎璁烘垨鏇存柊鏈枃鐨勫唴瀹癸紝璇风洿鎺ュ彂淇″埌LKML銆傚鏋滀綘浣跨敤鑻辨枃浜ゆ祦鏈夊洶闅剧殑璇濓紝涔熷彲 | ||
| 13 | 浠ュ悜涓枃鐗堢淮鎶よ呮眰鍔┿傚鏋滄湰缈昏瘧鏇存柊涓嶅強鏃舵垨鑰呯炕璇戝瓨鍦ㄩ棶棰橈紝璇疯仈绯讳腑鏂囩増缁存姢鑰呫 | ||
| 14 | |||
| 15 | 涓枃鐗堢淮鎶よ咃細 璐惧▉濞 Jia Wei Wei <harryxiyou@gmail.com> | ||
| 16 | 涓枃鐗堢炕璇戣咃細 璐惧▉濞 Jia Wei Wei <harryxiyou@gmail.com> | ||
| 17 | 涓枃鐗堟牎璇戣咃細 璐惧▉濞 Jia Wei Wei <harryxiyou@gmail.com> | ||
| 18 | |||
| 19 | 浠ヤ笅涓烘鏂 | ||
| 20 | --------------------------------------------------------------------- | ||
| 21 | 杩欎釜鏂囦欢鏄湁鍏冲綋鍓嶄娇鐢ㄧ殑榄旀湳鍊兼敞鍐岃〃銆傚綋浣犵粰涓涓粨鏋勬坊鍔犱簡涓涓瓟鏈硷紝浣犱篃搴旇鎶婅繖涓瓟鏈兼坊鍔犲埌杩欎釜鏂囦欢锛屽洜涓烘垜浠渶濂芥妸鐢ㄤ簬鍚勭缁撴瀯鐨勯瓟鏈肩粺涓璧锋潵銆 | ||
| 22 | |||
| 23 | 浣跨敤榄旀湳鍊兼潵淇濇姢鍐呮牳鏁版嵁缁撴瀯鏄竴涓潪甯稿ソ鐨勪富鎰忋傝繖灏卞厑璁镐綘鍦ㄨ繍琛屾湡妫鏌(a)涓涓粨鏋勬槸鍚﹀凡缁忚鏀诲嚮锛屾垨鑰(b)浣犲凡缁忕粰涓涓緥琛岀▼搴忛氳繃浜嗕竴涓敊璇殑缁撴瀯銆傚悗涓绉嶆儏鍐电壒鍒湴鏈夌敤---鐗瑰埆鏄綋浣犻氳繃涓涓┖鎸囬拡鎸囧悜缁撴瀯浣撶殑鏃跺欍倀ty婧愮爜锛屼緥濡傦紝缁忓父閫氳繃鐗瑰畾椹卞姩浣跨敤杩欑鏂规硶骞朵笖鍙嶅鍦版帓鍒楃壒瀹氭柟闈㈢殑缁撴瀯銆 | ||
| 24 | |||
| 25 | 浣跨敤榄旀湳鍊肩殑鏂规硶鏄湪缁撴瀯鐨勫紑濮嬪澹版槑鐨勶紝濡備笅锛 | ||
| 26 | |||
| 27 | struct tty_ldisc { | ||
| 28 | int magic; | ||
| 29 | ... | ||
| 30 | }; | ||
| 31 | |||
| 32 | 褰撲綘浠ュ悗缁欏唴鏍告坊鍔犲寮哄姛鑳界殑鏃跺欙紝璇烽伒瀹堣繖鏉¤鍒欙紒杩欐牱灏变細鑺傜渷鏁颁笉娓呯殑璋冭瘯鏃堕棿锛岀壒鍒槸涓浜涘彜鎬殑鎯呭喌锛屼緥濡傦紝鏁扮粍瓒呭嚭鑼冨洿骞朵笖閲嶆柊鍐欎簡瓒呭嚭閮ㄥ垎銆傞伒瀹堣繖涓鍒欙紝鈥繖浜涙儏鍐靛彲浠ヨ蹇熷湴锛屽畨鍏ㄥ湴閬垮厤銆 | ||
| 33 | |||
| 34 | Theodore Ts'o | ||
| 35 | 31 Mar 94 | ||
| 36 | |||
| 37 | 缁欏綋鍓嶇殑Linux 2.1.55娣诲姞榄旀湳琛ㄣ | ||
| 38 | |||
| 39 | Michael Chastain | ||
| 40 | <mailto:mec@shout.net> | ||
| 41 | 22 Sep 1997 | ||
| 42 | |||
| 43 | 鐜板湪搴旇鏈鏂扮殑Linux 2.1.112.鍥犱负鍦ㄧ壒鎬у喕缁撴湡闂达紝涓嶈兘鍦2.2.x鍓嶆敼鍙樹换浣曚笢瑗裤傝繖浜涙潯鐩鏁板煙鎵鎺掑簭銆 | ||
| 44 | |||
| 45 | Krzysztof G.Baranowski | ||
| 46 | <mailto: kgb@knm.org.pl> | ||
| 47 | 29 Jul 1998 | ||
| 48 | |||
| 49 | 鏇存柊榄旀湳琛ㄥ埌Linux 2.5.45銆傚垰濂借秺杩囩壒鎬у喕缁擄紝浣嗘槸鏈夊彲鑳借繕浼氭湁涓浜涙柊鐨勯瓟鏈煎湪2.6.x涔嬪墠铻嶅叆鍒板唴鏍镐腑銆 | ||
| 50 | |||
| 51 | Petr Baudis | ||
| 52 | <pasky@ucw.cz> | ||
| 53 | 03 Nov 2002 | ||
| 54 | |||
| 55 | 鏇存柊榄旀湳琛ㄥ埌Linux 2.5.74銆 | ||
| 56 | |||
| 57 | Fabian Frederick | ||
| 58 | <ffrederick@users.sourceforge.net> | ||
| 59 | 09 Jul 2003 | ||
| 60 | |||
| 61 | 榄旀湳鍚 鍦板潃 缁撴瀯 鎵鍦ㄦ枃浠 | ||
| 62 | =========================================================================== | ||
| 63 | PG_MAGIC 'P' pg_{read,write}_hdr include/linux/pg.h | ||
| 64 | CMAGIC 0x0111 user include/linux/a.out.h | ||
| 65 | MKISS_DRIVER_MAGIC 0x04bf mkiss_channel drivers/net/mkiss.h | ||
| 66 | RISCOM8_MAGIC 0x0907 riscom_port drivers/char/riscom8.h | ||
| 67 | SPECIALIX_MAGIC 0x0907 specialix_port drivers/char/specialix_io8.h | ||
| 68 | HDLC_MAGIC 0x239e n_hdlc drivers/char/n_hdlc.c | ||
| 69 | APM_BIOS_MAGIC 0x4101 apm_user arch/i386/kernel/apm.c | ||
| 70 | CYCLADES_MAGIC 0x4359 cyclades_port include/linux/cyclades.h | ||
| 71 | DB_MAGIC 0x4442 fc_info drivers/net/iph5526_novram.c | ||
| 72 | DL_MAGIC 0x444d fc_info drivers/net/iph5526_novram.c | ||
| 73 | FASYNC_MAGIC 0x4601 fasync_struct include/linux/fs.h | ||
| 74 | FF_MAGIC 0x4646 fc_info drivers/net/iph5526_novram.c | ||
| 75 | ISICOM_MAGIC 0x4d54 isi_port include/linux/isicom.h | ||
| 76 | PTY_MAGIC 0x5001 drivers/char/pty.c | ||
| 77 | PPP_MAGIC 0x5002 ppp include/linux/if_pppvar.h | ||
| 78 | SERIAL_MAGIC 0x5301 async_struct include/linux/serial.h | ||
| 79 | SSTATE_MAGIC 0x5302 serial_state include/linux/serial.h | ||
| 80 | SLIP_MAGIC 0x5302 slip drivers/net/slip.h | ||
| 81 | STRIP_MAGIC 0x5303 strip drivers/net/strip.c | ||
| 82 | X25_ASY_MAGIC 0x5303 x25_asy drivers/net/x25_asy.h | ||
| 83 | SIXPACK_MAGIC 0x5304 sixpack drivers/net/hamradio/6pack.h | ||
| 84 | AX25_MAGIC 0x5316 ax_disp drivers/net/mkiss.h | ||
| 85 | ESP_MAGIC 0x53ee esp_struct drivers/char/esp.h | ||
| 86 | TTY_MAGIC 0x5401 tty_struct include/linux/tty.h | ||
| 87 | MGSL_MAGIC 0x5401 mgsl_info drivers/char/synclink.c | ||
| 88 | TTY_DRIVER_MAGIC 0x5402 tty_driver include/linux/tty_driver.h | ||
| 89 | MGSLPC_MAGIC 0x5402 mgslpc_info drivers/char/pcmcia/synclink_cs.c | ||
| 90 | TTY_LDISC_MAGIC 0x5403 tty_ldisc include/linux/tty_ldisc.h | ||
| 91 | USB_SERIAL_MAGIC 0x6702 usb_serial drivers/usb/serial/usb-serial.h | ||
| 92 | FULL_DUPLEX_MAGIC 0x6969 drivers/net/tulip/de2104x.c | ||
| 93 | USB_BLUETOOTH_MAGIC 0x6d02 usb_bluetooth drivers/usb/class/bluetty.c | ||
| 94 | RFCOMM_TTY_MAGIC 0x6d02 net/bluetooth/rfcomm/tty.c | ||
| 95 | USB_SERIAL_PORT_MAGIC 0x7301 usb_serial_port drivers/usb/serial/usb-serial.h | ||
| 96 | CG_MAGIC 0x00090255 ufs_cylinder_group include/linux/ufs_fs.h | ||
| 97 | A2232_MAGIC 0x000a2232 gs_port drivers/char/ser_a2232.h | ||
| 98 | RPORT_MAGIC 0x00525001 r_port drivers/char/rocket_int.h | ||
| 99 | LSEMAGIC 0x05091998 lse drivers/fc4/fc.c | ||
| 100 | GDTIOCTL_MAGIC 0x06030f07 gdth_iowr_str drivers/scsi/gdth_ioctl.h | ||
| 101 | RIEBL_MAGIC 0x09051990 drivers/net/atarilance.c | ||
| 102 | RIO_MAGIC 0x12345678 gs_port drivers/char/rio/rio_linux.c | ||
| 103 | SX_MAGIC 0x12345678 gs_port drivers/char/sx.h | ||
| 104 | NBD_REQUEST_MAGIC 0x12560953 nbd_request include/linux/nbd.h | ||
| 105 | RED_MAGIC2 0x170fc2a5 (any) mm/slab.c | ||
| 106 | BAYCOM_MAGIC 0x19730510 baycom_state drivers/net/baycom_epp.c | ||
| 107 | ISDN_X25IFACE_MAGIC 0x1e75a2b9 isdn_x25iface_proto_data | ||
| 108 | drivers/isdn/isdn_x25iface.h | ||
| 109 | ECP_MAGIC 0x21504345 cdkecpsig include/linux/cdk.h | ||
| 110 | LSOMAGIC 0x27091997 lso drivers/fc4/fc.c | ||
| 111 | LSMAGIC 0x2a3b4d2a ls drivers/fc4/fc.c | ||
| 112 | WANPIPE_MAGIC 0x414C4453 sdla_{dump,exec} include/linux/wanpipe.h | ||
| 113 | CS_CARD_MAGIC 0x43525553 cs_card sound/oss/cs46xx.c | ||
| 114 | LABELCL_MAGIC 0x4857434c labelcl_info_s include/asm/ia64/sn/labelcl.h | ||
| 115 | ISDN_ASYNC_MAGIC 0x49344C01 modem_info include/linux/isdn.h | ||
| 116 | CTC_ASYNC_MAGIC 0x49344C01 ctc_tty_info drivers/s390/net/ctctty.c | ||
| 117 | ISDN_NET_MAGIC 0x49344C02 isdn_net_local_s drivers/isdn/i4l/isdn_net_lib.h | ||
| 118 | SAVEKMSG_MAGIC2 0x4B4D5347 savekmsg arch/*/amiga/config.c | ||
| 119 | STLI_BOARDMAGIC 0x4bc6c825 stlibrd include/linux/istallion.h | ||
| 120 | CS_STATE_MAGIC 0x4c4f4749 cs_state sound/oss/cs46xx.c | ||
| 121 | SLAB_C_MAGIC 0x4f17a36d kmem_cache mm/slab.c | ||
| 122 | COW_MAGIC 0x4f4f4f4d cow_header_v1 arch/um/drivers/ubd_user.c | ||
| 123 | I810_CARD_MAGIC 0x5072696E i810_card sound/oss/i810_audio.c | ||
| 124 | TRIDENT_CARD_MAGIC 0x5072696E trident_card sound/oss/trident.c | ||
| 125 | ROUTER_MAGIC 0x524d4157 wan_device include/linux/wanrouter.h | ||
| 126 | SCC_MAGIC 0x52696368 gs_port drivers/char/scc.h | ||
| 127 | SAVEKMSG_MAGIC1 0x53415645 savekmsg arch/*/amiga/config.c | ||
| 128 | GDA_MAGIC 0x58464552 gda arch/mips/include/asm/sn/gda.h | ||
| 129 | RED_MAGIC1 0x5a2cf071 (any) mm/slab.c | ||
| 130 | STL_PORTMAGIC 0x5a7182c9 stlport include/linux/stallion.h | ||
| 131 | EEPROM_MAGIC_VALUE 0x5ab478d2 lanai_dev drivers/atm/lanai.c | ||
| 132 | HDLCDRV_MAGIC 0x5ac6e778 hdlcdrv_state include/linux/hdlcdrv.h | ||
| 133 | EPCA_MAGIC 0x5c6df104 channel include/linux/epca.h | ||
| 134 | PCXX_MAGIC 0x5c6df104 channel drivers/char/pcxx.h | ||
| 135 | KV_MAGIC 0x5f4b565f kernel_vars_s arch/mips/include/asm/sn/klkernvars.h | ||
| 136 | I810_STATE_MAGIC 0x63657373 i810_state sound/oss/i810_audio.c | ||
| 137 | TRIDENT_STATE_MAGIC 0x63657373 trient_state sound/oss/trident.c | ||
| 138 | M3_CARD_MAGIC 0x646e6f50 m3_card sound/oss/maestro3.c | ||
| 139 | FW_HEADER_MAGIC 0x65726F66 fw_header drivers/atm/fore200e.h | ||
| 140 | SLOT_MAGIC 0x67267321 slot drivers/hotplug/cpqphp.h | ||
| 141 | SLOT_MAGIC 0x67267322 slot drivers/hotplug/acpiphp.h | ||
| 142 | LO_MAGIC 0x68797548 nbd_device include/linux/nbd.h | ||
| 143 | OPROFILE_MAGIC 0x6f70726f super_block drivers/oprofile/oprofilefs.h | ||
| 144 | M3_STATE_MAGIC 0x734d724d m3_state sound/oss/maestro3.c | ||
| 145 | STL_PANELMAGIC 0x7ef621a1 stlpanel include/linux/stallion.h | ||
| 146 | VMALLOC_MAGIC 0x87654320 snd_alloc_track sound/core/memory.c | ||
| 147 | KMALLOC_MAGIC 0x87654321 snd_alloc_track sound/core/memory.c | ||
| 148 | PWC_MAGIC 0x89DC10AB pwc_device drivers/usb/media/pwc.h | ||
| 149 | NBD_REPLY_MAGIC 0x96744668 nbd_reply include/linux/nbd.h | ||
| 150 | STL_BOARDMAGIC 0xa2267f52 stlbrd include/linux/stallion.h | ||
| 151 | ENI155_MAGIC 0xa54b872d midway_eprom drivers/atm/eni.h | ||
| 152 | SCI_MAGIC 0xbabeface gs_port drivers/char/sh-sci.h | ||
| 153 | CODA_MAGIC 0xC0DAC0DA coda_file_info include/linux/coda_fs_i.h | ||
| 154 | DPMEM_MAGIC 0xc0ffee11 gdt_pci_sram drivers/scsi/gdth.h | ||
| 155 | STLI_PORTMAGIC 0xe671c7a1 stliport include/linux/istallion.h | ||
| 156 | YAM_MAGIC 0xF10A7654 yam_port drivers/net/hamradio/yam.c | ||
| 157 | CCB_MAGIC 0xf2691ad2 ccb drivers/scsi/ncr53c8xx.c | ||
| 158 | QUEUE_MAGIC_FREE 0xf7e1c9a3 queue_entry drivers/scsi/arm/queue.c | ||
| 159 | QUEUE_MAGIC_USED 0xf7e1cc33 queue_entry drivers/scsi/arm/queue.c | ||
| 160 | HTB_CMAGIC 0xFEFAFEF1 htb_class net/sched/sch_htb.c | ||
| 161 | NMI_MAGIC 0x48414d4d455201 nmi_s arch/mips/include/asm/sn/nmi.h | ||
| 162 | |||
| 163 | 璇锋敞鎰忥紝鍦ㄥ０闊宠蹇嗙鐞嗕腑浠嶇劧鏈夋瘡涓浜涜瀹氫箟鐨勯┍鍔ㄩ瓟鏈笺傛煡鐪媔nclude/sound/sndmagic.h鏉ヨ幏鍙栦粬浠畬鏁寸殑鍒楄〃淇℃伅銆傚緢澶歄SS澹伴煶椹卞姩鎷ユ湁鑷繁浠庡０鍗CI ID鏋勫缓鐨勯瓟鏈-浠栦滑涔熸病鏈夎鍒楀湪杩欓噷銆 | ||
| 164 | |||
| 165 | IrDA瀛愮郴缁熶篃浣跨敤浜嗗ぇ閲忕殑鑷繁鐨勯瓟鏈硷紝鏌ョ湅include/net/irda/irda.h鏉ヨ幏鍙栦粬浠畬鏁寸殑淇℃伅銆 | ||
| 166 | |||
| 167 | HFS鏄彟澶栦竴涓瘮杈冨ぇ鐨勪娇鐢ㄩ瓟鏈肩殑鏂囦欢绯荤粺-浣犲彲浠ュ湪fs/hfs/hfs.h涓壘鍒颁粬浠 | ||
