diff options
Diffstat (limited to 'Documentation')
153 files changed, 4004 insertions, 2743 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 0f3e8bbab8d7..45b3df936d2f 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX | |||
| @@ -299,6 +299,8 @@ memory-hotplug.txt | |||
| 299 | - Hotpluggable memory support, how to use and current status. | 299 | - Hotpluggable memory support, how to use and current status. |
| 300 | memory.txt | 300 | memory.txt |
| 301 | - info on typical Linux memory problems. | 301 | - info on typical Linux memory problems. |
| 302 | metag/ | ||
| 303 | - directory with info about Linux on Meta architecture. | ||
| 302 | mips/ | 304 | mips/ |
| 303 | - directory with info about Linux on MIPS architecture. | 305 | - directory with info about Linux on MIPS architecture. |
| 304 | misc-devices/ | 306 | misc-devices/ |
diff --git a/Documentation/ABI/testing/sysfs-bus-fcoe b/Documentation/ABI/testing/sysfs-bus-fcoe index 50e2a80ea28f..21640eaad371 100644 --- a/Documentation/ABI/testing/sysfs-bus-fcoe +++ b/Documentation/ABI/testing/sysfs-bus-fcoe | |||
| @@ -1,14 +1,53 @@ | |||
| 1 | What: /sys/bus/fcoe/ctlr_X | 1 | What: /sys/bus/fcoe/ |
| 2 | Date: August 2012 | ||
| 3 | KernelVersion: TBD | ||
| 4 | Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org | ||
| 5 | Description: The FCoE bus. Attributes in this directory are control interfaces. | ||
| 6 | Attributes: | ||
| 7 | |||
| 8 | ctlr_create: 'FCoE Controller' instance creation interface. Writing an | ||
| 9 | <ifname> to this file will allocate and populate sysfs with a | ||
| 10 | fcoe_ctlr_device (ctlr_X). The user can then configure any | ||
| 11 | per-port settings and finally write to the fcoe_ctlr_device's | ||
| 12 | 'start' attribute to begin the kernel's discovery and login | ||
| 13 | process. | ||
| 14 | |||
| 15 | ctlr_destroy: 'FCoE Controller' instance removal interface. Writing a | ||
| 16 | fcoe_ctlr_device's sysfs name to this file will log the | ||
| 17 | fcoe_ctlr_device out of the fabric or otherwise connected | ||
| 18 | FCoE devices. It will also free all kernel memory allocated | ||
| 19 | for this fcoe_ctlr_device and any structures associated | ||
| 20 | with it, this includes the scsi_host. | ||
| 21 | |||
| 22 | What: /sys/bus/fcoe/devices/ctlr_X | ||
| 2 | Date: March 2012 | 23 | Date: March 2012 |
| 3 | KernelVersion: TBD | 24 | KernelVersion: TBD |
| 4 | Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org | 25 | Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org |
| 5 | Description: 'FCoE Controller' instances on the fcoe bus | 26 | Description: 'FCoE Controller' instances on the fcoe bus. |
| 27 | The FCoE Controller now has a three stage creation process. | ||
| 28 | 1) Write interface name to ctlr_create 2) Configure the FCoE | ||
| 29 | Controller (ctlr_X) 3) Enable the FCoE Controller to begin | ||
| 30 | discovery and login. The FCoE Controller is destroyed by | ||
| 31 | writing it's name, i.e. ctlr_X to the ctlr_delete file. | ||
| 32 | |||
| 6 | Attributes: | 33 | Attributes: |
| 7 | 34 | ||
| 8 | fcf_dev_loss_tmo: Device loss timeout peroid (see below). Changing | 35 | fcf_dev_loss_tmo: Device loss timeout peroid (see below). Changing |
| 9 | this value will change the dev_loss_tmo for all | 36 | this value will change the dev_loss_tmo for all |
| 10 | FCFs discovered by this controller. | 37 | FCFs discovered by this controller. |
| 11 | 38 | ||
| 39 | mode: Display or change the FCoE Controller's mode. Possible | ||
| 40 | modes are 'Fabric' and 'VN2VN'. If a FCoE Controller | ||
| 41 | is started in 'Fabric' mode then FIP FCF discovery is | ||
| 42 | initiated and ultimately a fabric login is attempted. | ||
| 43 | If a FCoE Controller is started in 'VN2VN' mode then | ||
| 44 | FIP VN2VN discovery and login is performed. A FCoE | ||
| 45 | Controller only supports one mode at a time. | ||
| 46 | |||
| 47 | enabled: Whether an FCoE controller is enabled or disabled. | ||
| 48 | 0 if disabled, 1 if enabled. Writing either 0 or 1 | ||
| 49 | to this file will enable or disable the FCoE controller. | ||
| 50 | |||
| 12 | lesb/link_fail: Link Error Status Block (LESB) link failure count. | 51 | lesb/link_fail: Link Error Status Block (LESB) link failure count. |
| 13 | 52 | ||
| 14 | lesb/vlink_fail: Link Error Status Block (LESB) virtual link | 53 | lesb/vlink_fail: Link Error Status Block (LESB) virtual link |
| @@ -26,7 +65,7 @@ Attributes: | |||
| 26 | 65 | ||
| 27 | Notes: ctlr_X (global increment starting at 0) | 66 | Notes: ctlr_X (global increment starting at 0) |
| 28 | 67 | ||
| 29 | What: /sys/bus/fcoe/fcf_X | 68 | What: /sys/bus/fcoe/devices/fcf_X |
| 30 | Date: March 2012 | 69 | Date: March 2012 |
| 31 | KernelVersion: TBD | 70 | KernelVersion: TBD |
| 32 | Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org | 71 | Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org |
diff --git a/Documentation/ABI/testing/sysfs-platform-msi-laptop b/Documentation/ABI/testing/sysfs-platform-msi-laptop new file mode 100644 index 000000000000..307a247ba1ef --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform-msi-laptop | |||
| @@ -0,0 +1,83 @@ | |||
| 1 | What: /sys/devices/platform/msi-laptop-pf/lcd_level | ||
| 2 | Date: Oct 2006 | ||
| 3 | KernelVersion: 2.6.19 | ||
| 4 | Contact: "Lennart Poettering <mzxreary@0pointer.de>" | ||
| 5 | Description: | ||
| 6 | Screen brightness: contains a single integer in the range 0..8. | ||
| 7 | |||
| 8 | What: /sys/devices/platform/msi-laptop-pf/auto_brightness | ||
| 9 | Date: Oct 2006 | ||
| 10 | KernelVersion: 2.6.19 | ||
| 11 | Contact: "Lennart Poettering <mzxreary@0pointer.de>" | ||
| 12 | Description: | ||
| 13 | Enable automatic brightness control: contains either 0 or 1. If | ||
| 14 | set to 1 the hardware adjusts the screen brightness | ||
| 15 | automatically when the power cord is plugged/unplugged. | ||
| 16 | |||
| 17 | What: /sys/devices/platform/msi-laptop-pf/wlan | ||
| 18 | Date: Oct 2006 | ||
| 19 | KernelVersion: 2.6.19 | ||
| 20 | Contact: "Lennart Poettering <mzxreary@0pointer.de>" | ||
| 21 | Description: | ||
| 22 | WLAN subsystem enabled: contains either 0 or 1. | ||
| 23 | |||
| 24 | What: /sys/devices/platform/msi-laptop-pf/bluetooth | ||
| 25 | Date: Oct 2006 | ||
| 26 | KernelVersion: 2.6.19 | ||
| 27 | Contact: "Lennart Poettering <mzxreary@0pointer.de>" | ||
| 28 | Description: | ||
| 29 | Bluetooth subsystem enabled: contains either 0 or 1. Please | ||
| 30 | note that this file is constantly 0 if no Bluetooth hardware is | ||
| 31 | available. | ||
| 32 | |||
| 33 | What: /sys/devices/platform/msi-laptop-pf/touchpad | ||
| 34 | Date: Nov 2012 | ||
| 35 | KernelVersion: 3.8 | ||
| 36 | Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>" | ||
| 37 | Description: | ||
| 38 | Contains either 0 or 1 and indicates if touchpad is turned on. | ||
| 39 | Touchpad state can only be toggled by pressing Fn+F3. | ||
| 40 | |||
| 41 | What: /sys/devices/platform/msi-laptop-pf/turbo_mode | ||
| 42 | Date: Nov 2012 | ||
| 43 | KernelVersion: 3.8 | ||
| 44 | Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>" | ||
| 45 | Description: | ||
| 46 | Contains either 0 or 1 and indicates if turbo mode is turned | ||
| 47 | on. In turbo mode power LED is orange and processor is | ||
| 48 | overclocked. Turbo mode is available only if charging. It is | ||
| 49 | only possible to toggle turbo mode state by pressing Fn+F10, | ||
| 50 | and there is a few seconds cooldown between subsequent toggles. | ||
| 51 | If user presses Fn+F10 too frequent, turbo mode state is not | ||
| 52 | changed. | ||
| 53 | |||
| 54 | What: /sys/devices/platform/msi-laptop-pf/eco_mode | ||
| 55 | Date: Nov 2012 | ||
| 56 | KernelVersion: 3.8 | ||
| 57 | Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>" | ||
| 58 | Description: | ||
| 59 | Contains either 0 or 1 and indicates if ECO mode is turned on. | ||
| 60 | In ECO mode power LED is green and userspace should do some | ||
| 61 | powersaving actions. ECO mode is available only on battery | ||
| 62 | power. ECO mode can only be toggled by pressing Fn+F10. | ||
| 63 | |||
| 64 | What: /sys/devices/platform/msi-laptop-pf/turbo_cooldown | ||
| 65 | Date: Nov 2012 | ||
| 66 | KernelVersion: 3.8 | ||
| 67 | Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>" | ||
| 68 | Description: | ||
| 69 | Contains value in range 0..3: | ||
| 70 | * 0 -> Turbo mode is off | ||
| 71 | * 1 -> Turbo mode is on, cannot be turned off yet | ||
| 72 | * 2 -> Turbo mode is off, cannot be turned on yet | ||
| 73 | * 3 -> Turbo mode is on | ||
| 74 | |||
| 75 | What: /sys/devices/platform/msi-laptop-pf/auto_fan | ||
| 76 | Date: Nov 2012 | ||
| 77 | KernelVersion: 3.8 | ||
| 78 | Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>" | ||
| 79 | Description: | ||
| 80 | Contains either 0 or 1 and indicates if fan speed is controlled | ||
| 81 | automatically (1) or fan runs at maximal speed (0). Can be | ||
| 82 | toggled in software. | ||
| 83 | |||
diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt index 4a4fb295ceef..14129f149a75 100644 --- a/Documentation/DMA-API-HOWTO.txt +++ b/Documentation/DMA-API-HOWTO.txt | |||
| @@ -488,9 +488,10 @@ will invoke the generic mapping error check interface. Doing so will ensure | |||
| 488 | that the mapping code will work correctly on all dma implementations without | 488 | that the mapping code will work correctly on all dma implementations without |
| 489 | any dependency on the specifics of the underlying implementation. Using the | 489 | any dependency on the specifics of the underlying implementation. Using the |
| 490 | returned address without checking for errors could result in failures ranging | 490 | returned address without checking for errors could result in failures ranging |
| 491 | from panics to silent data corruption. Couple of example of incorrect ways to | 491 | from panics to silent data corruption. A couple of examples of incorrect ways |
| 492 | check for errors that make assumptions about the underlying dma implementation | 492 | to check for errors that make assumptions about the underlying dma |
| 493 | are as follows and these are applicable to dma_map_page() as well. | 493 | implementation are as follows and these are applicable to dma_map_page() as |
| 494 | well. | ||
| 494 | 495 | ||
| 495 | Incorrect example 1: | 496 | Incorrect example 1: |
| 496 | dma_addr_t dma_handle; | 497 | dma_addr_t dma_handle; |
| @@ -751,7 +752,7 @@ Example 1: | |||
| 751 | dma_unmap_single(dma_handle1); | 752 | dma_unmap_single(dma_handle1); |
| 752 | map_error_handling1: | 753 | map_error_handling1: |
| 753 | 754 | ||
| 754 | Example 2: (if buffers are allocated a loop, unmap all mapped buffers when | 755 | Example 2: (if buffers are allocated in a loop, unmap all mapped buffers when |
| 755 | mapping error is detected in the middle) | 756 | mapping error is detected in the middle) |
| 756 | 757 | ||
| 757 | dma_addr_t dma_addr; | 758 | dma_addr_t dma_addr; |
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 4ee2304f82f9..f9df3b872c16 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl | |||
| @@ -743,6 +743,10 @@ char *date;</synopsis> | |||
| 743 | These two operations are mandatory for GEM drivers that support DRM | 743 | These two operations are mandatory for GEM drivers that support DRM |
| 744 | PRIME. | 744 | PRIME. |
| 745 | </para> | 745 | </para> |
| 746 | <sect4> | ||
| 747 | <title>DRM PRIME Helper Functions Reference</title> | ||
| 748 | !Pdrivers/gpu/drm/drm_prime.c PRIME Helpers | ||
| 749 | </sect4> | ||
| 746 | </sect3> | 750 | </sect3> |
| 747 | <sect3 id="drm-gem-objects-mapping"> | 751 | <sect3 id="drm-gem-objects-mapping"> |
| 748 | <title>GEM Objects Mapping</title> | 752 | <title>GEM Objects Mapping</title> |
| @@ -978,10 +982,25 @@ int max_width, max_height;</synopsis> | |||
| 978 | If the parameters are deemed valid, drivers then create, initialize and | 982 | If the parameters are deemed valid, drivers then create, initialize and |
| 979 | return an instance of struct <structname>drm_framebuffer</structname>. | 983 | return an instance of struct <structname>drm_framebuffer</structname>. |
| 980 | If desired the instance can be embedded in a larger driver-specific | 984 | If desired the instance can be embedded in a larger driver-specific |
| 981 | structure. The new instance is initialized with a call to | 985 | structure. Drivers must fill its <structfield>width</structfield>, |
| 982 | <function>drm_framebuffer_init</function> which takes a pointer to DRM | 986 | <structfield>height</structfield>, <structfield>pitches</structfield>, |
| 983 | frame buffer operations (struct | 987 | <structfield>offsets</structfield>, <structfield>depth</structfield>, |
| 984 | <structname>drm_framebuffer_funcs</structname>). Frame buffer operations are | 988 | <structfield>bits_per_pixel</structfield> and |
| 989 | <structfield>pixel_format</structfield> fields from the values passed | ||
| 990 | through the <parameter>drm_mode_fb_cmd2</parameter> argument. They | ||
| 991 | should call the <function>drm_helper_mode_fill_fb_struct</function> | ||
| 992 | helper function to do so. | ||
| 993 | </para> | ||
| 994 | |||
| 995 | <para> | ||
| 996 | The initailization of the new framebuffer instance is finalized with a | ||
| 997 | call to <function>drm_framebuffer_init</function> which takes a pointer | ||
| 998 | to DRM frame buffer operations (struct | ||
| 999 | <structname>drm_framebuffer_funcs</structname>). Note that this function | ||
| 1000 | publishes the framebuffer and so from this point on it can be accessed | ||
| 1001 | concurrently from other threads. Hence it must be the last step in the | ||
| 1002 | driver's framebuffer initialization sequence. Frame buffer operations | ||
| 1003 | are | ||
| 985 | <itemizedlist> | 1004 | <itemizedlist> |
| 986 | <listitem> | 1005 | <listitem> |
| 987 | <synopsis>int (*create_handle)(struct drm_framebuffer *fb, | 1006 | <synopsis>int (*create_handle)(struct drm_framebuffer *fb, |
| @@ -1022,16 +1041,16 @@ int max_width, max_height;</synopsis> | |||
| 1022 | </itemizedlist> | 1041 | </itemizedlist> |
| 1023 | </para> | 1042 | </para> |
| 1024 | <para> | 1043 | <para> |
| 1025 | After initializing the <structname>drm_framebuffer</structname> | 1044 | The lifetime of a drm framebuffer is controlled with a reference count, |
| 1026 | instance drivers must fill its <structfield>width</structfield>, | 1045 | drivers can grab additional references with |
| 1027 | <structfield>height</structfield>, <structfield>pitches</structfield>, | 1046 | <function>drm_framebuffer_reference</function> </para> and drop them |
| 1028 | <structfield>offsets</structfield>, <structfield>depth</structfield>, | 1047 | again with <function>drm_framebuffer_unreference</function>. For |
| 1029 | <structfield>bits_per_pixel</structfield> and | 1048 | driver-private framebuffers for which the last reference is never |
| 1030 | <structfield>pixel_format</structfield> fields from the values passed | 1049 | dropped (e.g. for the fbdev framebuffer when the struct |
| 1031 | through the <parameter>drm_mode_fb_cmd2</parameter> argument. They | 1050 | <structname>drm_framebuffer</structname> is embedded into the fbdev |
| 1032 | should call the <function>drm_helper_mode_fill_fb_struct</function> | 1051 | helper struct) drivers can manually clean up a framebuffer at module |
| 1033 | helper function to do so. | 1052 | unload time with |
| 1034 | </para> | 1053 | <function>drm_framebuffer_unregister_private</function>. |
| 1035 | </sect2> | 1054 | </sect2> |
| 1036 | <sect2> | 1055 | <sect2> |
| 1037 | <title>Output Polling</title> | 1056 | <title>Output Polling</title> |
| @@ -1043,6 +1062,22 @@ int max_width, max_height;</synopsis> | |||
| 1043 | operation. | 1062 | operation. |
| 1044 | </para> | 1063 | </para> |
| 1045 | </sect2> | 1064 | </sect2> |
| 1065 | <sect2> | ||
| 1066 | <title>Locking</title> | ||
| 1067 | <para> | ||
| 1068 | Beside some lookup structures with their own locking (which is hidden | ||
| 1069 | behind the interface functions) most of the modeset state is protected | ||
| 1070 | by the <code>dev-<mode_config.lock</code> mutex and additionally | ||
| 1071 | per-crtc locks to allow cursor updates, pageflips and similar operations | ||
| 1072 | to occur concurrently with background tasks like output detection. | ||
| 1073 | Operations which cross domains like a full modeset always grab all | ||
| 1074 | locks. Drivers there need to protect resources shared between crtcs with | ||
| 1075 | additional locking. They also need to be careful to always grab the | ||
| 1076 | relevant crtc locks if a modset functions touches crtc state, e.g. for | ||
| 1077 | load detection (which does only grab the <code>mode_config.lock</code> | ||
| 1078 | to allow concurrent screen updates on live crtcs). | ||
| 1079 | </para> | ||
| 1080 | </sect2> | ||
| 1046 | </sect1> | 1081 | </sect1> |
| 1047 | 1082 | ||
| 1048 | <!-- Internals: kms initialization and cleanup --> | 1083 | <!-- Internals: kms initialization and cleanup --> |
| @@ -1126,6 +1161,12 @@ int max_width, max_height;</synopsis> | |||
| 1126 | any new rendering to the frame buffer until the page flip completes. | 1161 | any new rendering to the frame buffer until the page flip completes. |
| 1127 | </para> | 1162 | </para> |
| 1128 | <para> | 1163 | <para> |
| 1164 | If a page flip can be successfully scheduled the driver must set the | ||
| 1165 | <code>drm_crtc-<fb</code> field to the new framebuffer pointed to | ||
| 1166 | by <code>fb</code>. This is important so that the reference counting | ||
| 1167 | on framebuffers stays balanced. | ||
| 1168 | </para> | ||
| 1169 | <para> | ||
| 1129 | If a page flip is already pending, the | 1170 | If a page flip is already pending, the |
| 1130 | <methodname>page_flip</methodname> operation must return | 1171 | <methodname>page_flip</methodname> operation must return |
| 1131 | -<errorname>EBUSY</errorname>. | 1172 | -<errorname>EBUSY</errorname>. |
| @@ -1609,6 +1650,10 @@ void intel_crt_init(struct drm_device *dev) | |||
| 1609 | make its properties available to applications. | 1650 | make its properties available to applications. |
| 1610 | </para> | 1651 | </para> |
| 1611 | </sect2> | 1652 | </sect2> |
| 1653 | <sect2> | ||
| 1654 | <title>KMS API Functions</title> | ||
| 1655 | !Edrivers/gpu/drm/drm_crtc.c | ||
| 1656 | </sect2> | ||
| 1612 | </sect1> | 1657 | </sect1> |
| 1613 | 1658 | ||
| 1614 | <!-- Internals: kms helper functions --> | 1659 | <!-- Internals: kms helper functions --> |
| @@ -2104,6 +2149,7 @@ void intel_crt_init(struct drm_device *dev) | |||
| 2104 | <title>fbdev Helper Functions Reference</title> | 2149 | <title>fbdev Helper Functions Reference</title> |
| 2105 | !Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers | 2150 | !Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers |
| 2106 | !Edrivers/gpu/drm/drm_fb_helper.c | 2151 | !Edrivers/gpu/drm/drm_fb_helper.c |
| 2152 | !Iinclude/drm/drm_fb_helper.h | ||
| 2107 | </sect2> | 2153 | </sect2> |
| 2108 | <sect2> | 2154 | <sect2> |
| 2109 | <title>Display Port Helper Functions Reference</title> | 2155 | <title>Display Port Helper Functions Reference</title> |
| @@ -2111,6 +2157,10 @@ void intel_crt_init(struct drm_device *dev) | |||
| 2111 | !Iinclude/drm/drm_dp_helper.h | 2157 | !Iinclude/drm/drm_dp_helper.h |
| 2112 | !Edrivers/gpu/drm/drm_dp_helper.c | 2158 | !Edrivers/gpu/drm/drm_dp_helper.c |
| 2113 | </sect2> | 2159 | </sect2> |
| 2160 | <sect2> | ||
| 2161 | <title>EDID Helper Functions Reference</title> | ||
| 2162 | !Edrivers/gpu/drm/drm_edid.c | ||
| 2163 | </sect2> | ||
| 2114 | </sect1> | 2164 | </sect1> |
| 2115 | 2165 | ||
| 2116 | <!-- Internals: vertical blanking --> | 2166 | <!-- Internals: vertical blanking --> |
diff --git a/Documentation/DocBook/media/dvb/dvbapi.xml b/Documentation/DocBook/media/dvb/dvbapi.xml index 757488b24f4f..0197bcc7842d 100644 --- a/Documentation/DocBook/media/dvb/dvbapi.xml +++ b/Documentation/DocBook/media/dvb/dvbapi.xml | |||
| @@ -84,7 +84,7 @@ Added ISDB-T test originally written by Patrick Boettcher | |||
| 84 | 84 | ||
| 85 | 85 | ||
| 86 | <title>LINUX DVB API</title> | 86 | <title>LINUX DVB API</title> |
| 87 | <subtitle>Version 5.8</subtitle> | 87 | <subtitle>Version 5.10</subtitle> |
| 88 | <!-- ADD THE CHAPTERS HERE --> | 88 | <!-- ADD THE CHAPTERS HERE --> |
| 89 | <chapter id="dvb_introdution"> | 89 | <chapter id="dvb_introdution"> |
| 90 | &sub-intro; | 90 | &sub-intro; |
diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml b/Documentation/DocBook/media/dvb/dvbproperty.xml index 957e3acaae8e..4a5eaeed0b9e 100644 --- a/Documentation/DocBook/media/dvb/dvbproperty.xml +++ b/Documentation/DocBook/media/dvb/dvbproperty.xml | |||
| @@ -7,14 +7,41 @@ the capability ioctls weren't implemented yet via the new way.</para> | |||
| 7 | <para>The typical usage for the <constant>FE_GET_PROPERTY/FE_SET_PROPERTY</constant> | 7 | <para>The typical usage for the <constant>FE_GET_PROPERTY/FE_SET_PROPERTY</constant> |
| 8 | API is to replace the ioctl's were the <link linkend="dvb-frontend-parameters"> | 8 | API is to replace the ioctl's were the <link linkend="dvb-frontend-parameters"> |
| 9 | struct <constant>dvb_frontend_parameters</constant></link> were used.</para> | 9 | struct <constant>dvb_frontend_parameters</constant></link> were used.</para> |
| 10 | <section id="dtv-stats"> | ||
| 11 | <title>DTV stats type</title> | ||
| 12 | <programlisting> | ||
| 13 | struct dtv_stats { | ||
| 14 | __u8 scale; /* enum fecap_scale_params type */ | ||
| 15 | union { | ||
| 16 | __u64 uvalue; /* for counters and relative scales */ | ||
| 17 | __s64 svalue; /* for 1/1000 dB measures */ | ||
| 18 | }; | ||
| 19 | } __packed; | ||
| 20 | </programlisting> | ||
| 21 | </section> | ||
| 22 | <section id="dtv-fe-stats"> | ||
| 23 | <title>DTV stats type</title> | ||
| 24 | <programlisting> | ||
| 25 | #define MAX_DTV_STATS 4 | ||
| 26 | |||
| 27 | struct dtv_fe_stats { | ||
| 28 | __u8 len; | ||
| 29 | struct dtv_stats stat[MAX_DTV_STATS]; | ||
| 30 | } __packed; | ||
| 31 | </programlisting> | ||
| 32 | </section> | ||
| 33 | |||
| 10 | <section id="dtv-property"> | 34 | <section id="dtv-property"> |
| 11 | <title>DTV property type</title> | 35 | <title>DTV property type</title> |
| 12 | <programlisting> | 36 | <programlisting> |
| 13 | /* Reserved fields should be set to 0 */ | 37 | /* Reserved fields should be set to 0 */ |
| 38 | |||
| 14 | struct dtv_property { | 39 | struct dtv_property { |
| 15 | __u32 cmd; | 40 | __u32 cmd; |
| 41 | __u32 reserved[3]; | ||
| 16 | union { | 42 | union { |
| 17 | __u32 data; | 43 | __u32 data; |
| 44 | struct dtv_fe_stats st; | ||
| 18 | struct { | 45 | struct { |
| 19 | __u8 data[32]; | 46 | __u8 data[32]; |
| 20 | __u32 len; | 47 | __u32 len; |
| @@ -440,7 +467,7 @@ typedef enum fe_delivery_system { | |||
| 440 | <title><constant>DTV-ISDBT-LAYER*</constant> parameters</title> | 467 | <title><constant>DTV-ISDBT-LAYER*</constant> parameters</title> |
| 441 | <para>ISDB-T channels can be coded hierarchically. As opposed to DVB-T in | 468 | <para>ISDB-T channels can be coded hierarchically. As opposed to DVB-T in |
| 442 | ISDB-T hierarchical layers can be decoded simultaneously. For that | 469 | ISDB-T hierarchical layers can be decoded simultaneously. For that |
| 443 | reason a ISDB-T demodulator has 3 viterbi and 3 reed-solomon-decoders.</para> | 470 | reason a ISDB-T demodulator has 3 Viterbi and 3 Reed-Solomon decoders.</para> |
| 444 | <para>ISDB-T has 3 hierarchical layers which each can use a part of the | 471 | <para>ISDB-T has 3 hierarchical layers which each can use a part of the |
| 445 | available segments. The total number of segments over all layers has | 472 | available segments. The total number of segments over all layers has |
| 446 | to 13 in ISDB-T.</para> | 473 | to 13 in ISDB-T.</para> |
| @@ -850,6 +877,147 @@ enum fe_interleaving { | |||
| 850 | <para>use the special macro LNA_AUTO to set LNA auto</para> | 877 | <para>use the special macro LNA_AUTO to set LNA auto</para> |
| 851 | </section> | 878 | </section> |
| 852 | </section> | 879 | </section> |
| 880 | |||
| 881 | <section id="frontend-stat-properties"> | ||
| 882 | <title>Frontend statistics indicators</title> | ||
| 883 | <para>The values are returned via <constant>dtv_property.stat</constant>. | ||
| 884 | If the property is supported, <constant>dtv_property.stat.len</constant> is bigger than zero.</para> | ||
| 885 | <para>For most delivery systems, <constant>dtv_property.stat.len</constant> | ||
| 886 | will be 1 if the stats is supported, and the properties will | ||
| 887 | return a single value for each parameter.</para> | ||
| 888 | <para>It should be noticed, however, that new OFDM delivery systems | ||
| 889 | like ISDB can use different modulation types for each group of | ||
| 890 | carriers. On such standards, up to 3 groups of statistics can be | ||
| 891 | provided, and <constant>dtv_property.stat.len</constant> is updated | ||
| 892 | to reflect the "global" metrics, plus one metric per each carrier | ||
| 893 | group (called "layer" on ISDB).</para> | ||
| 894 | <para>So, in order to be consistent with other delivery systems, the first | ||
| 895 | value at <link linkend="dtv-stats"><constant>dtv_property.stat.dtv_stats</constant></link> | ||
| 896 | array refers to the global metric. The other elements of the array | ||
| 897 | represent each layer, starting from layer A(index 1), | ||
| 898 | layer B (index 2) and so on.</para> | ||
| 899 | <para>The number of filled elements are stored at <constant>dtv_property.stat.len</constant>.</para> | ||
| 900 | <para>Each element of the <constant>dtv_property.stat.dtv_stats</constant> array consists on two elements:</para> | ||
| 901 | <itemizedlist mark='opencircle'> | ||
| 902 | <listitem><para><constant>svalue</constant> or <constant>uvalue</constant>, where | ||
| 903 | <constant>svalue</constant> is for signed values of the measure (dB measures) | ||
| 904 | and <constant>uvalue</constant> is for unsigned values (counters, relative scale)</para></listitem> | ||
| 905 | <listitem><para><constant>scale</constant> - Scale for the value. It can be:</para> | ||
| 906 | <section id = "fecap-scale-params"> | ||
| 907 | <itemizedlist mark='bullet'> | ||
| 908 | <listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - The parameter is supported by the frontend, but it was not possible to collect it (could be a transitory or permanent condition)</para></listitem> | ||
| 909 | <listitem><para><constant>FE_SCALE_DECIBEL</constant> - parameter is a signed value, measured in 1/1000 dB</para></listitem> | ||
| 910 | <listitem><para><constant>FE_SCALE_RELATIVE</constant> - parameter is a unsigned value, where 0 means 0% and 65535 means 100%.</para></listitem> | ||
| 911 | <listitem><para><constant>FE_SCALE_COUNTER</constant> - parameter is a unsigned value that counts the occurrence of an event, like bit error, block error, or lapsed time.</para></listitem> | ||
| 912 | </itemizedlist> | ||
| 913 | </section> | ||
| 914 | </listitem> | ||
| 915 | </itemizedlist> | ||
| 916 | <section id="DTV-STAT-SIGNAL-STRENGTH"> | ||
| 917 | <title><constant>DTV_STAT_SIGNAL_STRENGTH</constant></title> | ||
| 918 | <para>Indicates the signal strength level at the analog part of the tuner or of the demod.</para> | ||
| 919 | <para>Possible scales for this metric are:</para> | ||
| 920 | <itemizedlist mark='bullet'> | ||
| 921 | <listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem> | ||
| 922 | <listitem><constant>FE_SCALE_DECIBEL</constant> - signal strength is in 0.0001 dBm units, power measured in miliwatts. This value is generally negative.</listitem> | ||
| 923 | <listitem><constant>FE_SCALE_RELATIVE</constant> - The frontend provides a 0% to 100% measurement for power (actually, 0 to 65535).</listitem> | ||
| 924 | </itemizedlist> | ||
| 925 | </section> | ||
| 926 | <section id="DTV-STAT-CNR"> | ||
| 927 | <title><constant>DTV_STAT_CNR</constant></title> | ||
| 928 | <para>Indicates the Signal to Noise ratio for the main carrier.</para> | ||
| 929 | <para>Possible scales for this metric are:</para> | ||
| 930 | <itemizedlist mark='bullet'> | ||
| 931 | <listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem> | ||
| 932 | <listitem><constant>FE_SCALE_DECIBEL</constant> - Signal/Noise ratio is in 0.0001 dB units.</listitem> | ||
| 933 | <listitem><constant>FE_SCALE_RELATIVE</constant> - The frontend provides a 0% to 100% measurement for Signal/Noise (actually, 0 to 65535).</listitem> | ||
| 934 | </itemizedlist> | ||
| 935 | </section> | ||
| 936 | <section id="DTV-STAT-PRE-ERROR-BIT-COUNT"> | ||
| 937 | <title><constant>DTV_STAT_PRE_ERROR_BIT_COUNT</constant></title> | ||
| 938 | <para>Measures the number of bit errors before the forward error correction (FEC) on the inner coding block (before Viterbi, LDPC or other inner code).</para> | ||
| 939 | <para>This measure is taken during the same interval as <constant>DTV_STAT_PRE_TOTAL_BIT_COUNT</constant>.</para> | ||
| 940 | <para>In order to get the BER (Bit Error Rate) measurement, it should be divided by | ||
| 941 | <link linkend="DTV-STAT-PRE-TOTAL-BIT-COUNT"><constant>DTV_STAT_PRE_TOTAL_BIT_COUNT</constant></link>.</para> | ||
| 942 | <para>This measurement is monotonically increased, as the frontend gets more bit count measurements. | ||
| 943 | The frontend may reset it when a channel/transponder is tuned.</para> | ||
| 944 | <para>Possible scales for this metric are:</para> | ||
| 945 | <itemizedlist mark='bullet'> | ||
| 946 | <listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem> | ||
| 947 | <listitem><constant>FE_SCALE_COUNTER</constant> - Number of error bits counted before the inner coding.</listitem> | ||
| 948 | </itemizedlist> | ||
| 949 | </section> | ||
| 950 | <section id="DTV-STAT-PRE-TOTAL-BIT-COUNT"> | ||
| 951 | <title><constant>DTV_STAT_PRE_TOTAL_BIT_COUNT</constant></title> | ||
| 952 | <para>Measures the amount of bits received before the inner code block, during the same period as | ||
| 953 | <link linkend="DTV-STAT-PRE-ERROR-BIT-COUNT"><constant>DTV_STAT_PRE_ERROR_BIT_COUNT</constant></link> measurement was taken.</para> | ||
| 954 | <para>It should be noticed that this measurement can be smaller than the total amount of bits on the transport stream, | ||
| 955 | as the frontend may need to manually restart the measurement, loosing some data between each measurement interval.</para> | ||
| 956 | <para>This measurement is monotonically increased, as the frontend gets more bit count measurements. | ||
| 957 | The frontend may reset it when a channel/transponder is tuned.</para> | ||
| 958 | <para>Possible scales for this metric are:</para> | ||
| 959 | <itemizedlist mark='bullet'> | ||
| 960 | <listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem> | ||
| 961 | <listitem><constant>FE_SCALE_COUNTER</constant> - Number of bits counted while measuring | ||
| 962 | <link linkend="DTV-STAT-PRE-ERROR-BIT-COUNT"><constant>DTV_STAT_PRE_ERROR_BIT_COUNT</constant></link>.</listitem> | ||
| 963 | </itemizedlist> | ||
| 964 | </section> | ||
| 965 | <section id="DTV-STAT-POST-ERROR-BIT-COUNT"> | ||
| 966 | <title><constant>DTV_STAT_POST_ERROR_BIT_COUNT</constant></title> | ||
| 967 | <para>Measures the number of bit errors after the forward error correction (FEC) done by inner code block (after Viterbi, LDPC or other inner code).</para> | ||
| 968 | <para>This measure is taken during the same interval as <constant>DTV_STAT_POST_TOTAL_BIT_COUNT</constant>.</para> | ||
| 969 | <para>In order to get the BER (Bit Error Rate) measurement, it should be divided by | ||
| 970 | <link linkend="DTV-STAT-POST-TOTAL-BIT-COUNT"><constant>DTV_STAT_POST_TOTAL_BIT_COUNT</constant></link>.</para> | ||
| 971 | <para>This measurement is monotonically increased, as the frontend gets more bit count measurements. | ||
| 972 | The frontend may reset it when a channel/transponder is tuned.</para> | ||
| 973 | <para>Possible scales for this metric are:</para> | ||
| 974 | <itemizedlist mark='bullet'> | ||
| 975 | <listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem> | ||
| 976 | <listitem><constant>FE_SCALE_COUNTER</constant> - Number of error bits counted after the inner coding.</listitem> | ||
| 977 | </itemizedlist> | ||
| 978 | </section> | ||
| 979 | <section id="DTV-STAT-POST-TOTAL-BIT-COUNT"> | ||
| 980 | <title><constant>DTV_STAT_POST_TOTAL_BIT_COUNT</constant></title> | ||
| 981 | <para>Measures the amount of bits received after the inner coding, during the same period as | ||
| 982 | <link linkend="DTV-STAT-POST-ERROR-BIT-COUNT"><constant>DTV_STAT_POST_ERROR_BIT_COUNT</constant></link> measurement was taken.</para> | ||
| 983 | <para>It should be noticed that this measurement can be smaller than the total amount of bits on the transport stream, | ||
| 984 | as the frontend may need to manually restart the measurement, loosing some data between each measurement interval.</para> | ||
| 985 | <para>This measurement is monotonically increased, as the frontend gets more bit count measurements. | ||
| 986 | The frontend may reset it when a channel/transponder is tuned.</para> | ||
| 987 | <para>Possible scales for this metric are:</para> | ||
| 988 | <itemizedlist mark='bullet'> | ||
| 989 | <listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem> | ||
| 990 | <listitem><constant>FE_SCALE_COUNTER</constant> - Number of bits counted while measuring | ||
| 991 | <link linkend="DTV-STAT-POST-ERROR-BIT-COUNT"><constant>DTV_STAT_POST_ERROR_BIT_COUNT</constant></link>.</listitem> | ||
| 992 | </itemizedlist> | ||
| 993 | </section> | ||
| 994 | <section id="DTV-STAT-ERROR-BLOCK-COUNT"> | ||
| 995 | <title><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></title> | ||
| 996 | <para>Measures the number of block errors after the outer forward error correction coding (after Reed-Solomon or other outer code).</para> | ||
| 997 | <para>This measurement is monotonically increased, as the frontend gets more bit count measurements. | ||
| 998 | The frontend may reset it when a channel/transponder is tuned.</para> | ||
| 999 | <para>Possible scales for this metric are:</para> | ||
| 1000 | <itemizedlist mark='bullet'> | ||
| 1001 | <listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem> | ||
| 1002 | <listitem><constant>FE_SCALE_COUNTER</constant> - Number of error blocks counted after the outer coding.</listitem> | ||
| 1003 | </itemizedlist> | ||
| 1004 | </section> | ||
| 1005 | <section id="DTV-STAT-TOTAL-BLOCK-COUNT"> | ||
| 1006 | <title><constant>DTV-STAT_TOTAL_BLOCK_COUNT</constant></title> | ||
| 1007 | <para>Measures the total number of blocks received during the same period as | ||
| 1008 | <link linkend="DTV-STAT-ERROR-BLOCK-COUNT"><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></link> measurement was taken.</para> | ||
| 1009 | <para>It can be used to calculate the PER indicator, by dividing | ||
| 1010 | <link linkend="DTV-STAT-ERROR-BLOCK-COUNT"><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></link> | ||
| 1011 | by <link linkend="DTV-STAT-TOTAL-BLOCK-COUNT"><constant>DTV-STAT-TOTAL-BLOCK-COUNT</constant></link>.</para> | ||
| 1012 | <para>Possible scales for this metric are:</para> | ||
| 1013 | <itemizedlist mark='bullet'> | ||
| 1014 | <listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem> | ||
| 1015 | <listitem><constant>FE_SCALE_COUNTER</constant> - Number of blocks counted while measuring | ||
| 1016 | <link linkend="DTV-STAT-ERROR-BLOCK-COUNT"><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></link>.</listitem> | ||
| 1017 | </itemizedlist> | ||
| 1018 | </section> | ||
| 1019 | </section> | ||
| 1020 | |||
| 853 | <section id="frontend-property-terrestrial-systems"> | 1021 | <section id="frontend-property-terrestrial-systems"> |
| 854 | <title>Properties used on terrestrial delivery systems</title> | 1022 | <title>Properties used on terrestrial delivery systems</title> |
| 855 | <section id="dvbt-params"> | 1023 | <section id="dvbt-params"> |
| @@ -871,6 +1039,7 @@ enum fe_interleaving { | |||
| 871 | <listitem><para><link linkend="DTV-HIERARCHY"><constant>DTV_HIERARCHY</constant></link></para></listitem> | 1039 | <listitem><para><link linkend="DTV-HIERARCHY"><constant>DTV_HIERARCHY</constant></link></para></listitem> |
| 872 | <listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem> | 1040 | <listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem> |
| 873 | </itemizedlist> | 1041 | </itemizedlist> |
| 1042 | <para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para> | ||
| 874 | </section> | 1043 | </section> |
| 875 | <section id="dvbt2-params"> | 1044 | <section id="dvbt2-params"> |
| 876 | <title>DVB-T2 delivery system</title> | 1045 | <title>DVB-T2 delivery system</title> |
| @@ -895,6 +1064,7 @@ enum fe_interleaving { | |||
| 895 | <listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem> | 1064 | <listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem> |
| 896 | <listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem> | 1065 | <listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem> |
| 897 | </itemizedlist> | 1066 | </itemizedlist> |
| 1067 | <para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para> | ||
| 898 | </section> | 1068 | </section> |
| 899 | <section id="isdbt"> | 1069 | <section id="isdbt"> |
| 900 | <title>ISDB-T delivery system</title> | 1070 | <title>ISDB-T delivery system</title> |
| @@ -948,6 +1118,7 @@ enum fe_interleaving { | |||
| 948 | <listitem><para><link linkend="DTV-ISDBT-LAYER-SEGMENT-COUNT"><constant>DTV_ISDBT_LAYERC_SEGMENT_COUNT</constant></link></para></listitem> | 1118 | <listitem><para><link linkend="DTV-ISDBT-LAYER-SEGMENT-COUNT"><constant>DTV_ISDBT_LAYERC_SEGMENT_COUNT</constant></link></para></listitem> |
| 949 | <listitem><para><link linkend="DTV-ISDBT-LAYER-TIME-INTERLEAVING"><constant>DTV_ISDBT_LAYERC_TIME_INTERLEAVING</constant></link></para></listitem> | 1119 | <listitem><para><link linkend="DTV-ISDBT-LAYER-TIME-INTERLEAVING"><constant>DTV_ISDBT_LAYERC_TIME_INTERLEAVING</constant></link></para></listitem> |
| 950 | </itemizedlist> | 1120 | </itemizedlist> |
| 1121 | <para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para> | ||
| 951 | </section> | 1122 | </section> |
| 952 | <section id="atsc-params"> | 1123 | <section id="atsc-params"> |
| 953 | <title>ATSC delivery system</title> | 1124 | <title>ATSC delivery system</title> |
| @@ -961,6 +1132,7 @@ enum fe_interleaving { | |||
| 961 | <listitem><para><link linkend="DTV-MODULATION"><constant>DTV_MODULATION</constant></link></para></listitem> | 1132 | <listitem><para><link linkend="DTV-MODULATION"><constant>DTV_MODULATION</constant></link></para></listitem> |
| 962 | <listitem><para><link linkend="DTV-BANDWIDTH-HZ"><constant>DTV_BANDWIDTH_HZ</constant></link></para></listitem> | 1133 | <listitem><para><link linkend="DTV-BANDWIDTH-HZ"><constant>DTV_BANDWIDTH_HZ</constant></link></para></listitem> |
| 963 | </itemizedlist> | 1134 | </itemizedlist> |
| 1135 | <para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para> | ||
| 964 | </section> | 1136 | </section> |
| 965 | <section id="atscmh-params"> | 1137 | <section id="atscmh-params"> |
| 966 | <title>ATSC-MH delivery system</title> | 1138 | <title>ATSC-MH delivery system</title> |
| @@ -988,6 +1160,7 @@ enum fe_interleaving { | |||
| 988 | <listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-C"><constant>DTV_ATSCMH_SCCC_CODE_MODE_C</constant></link></para></listitem> | 1160 | <listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-C"><constant>DTV_ATSCMH_SCCC_CODE_MODE_C</constant></link></para></listitem> |
| 989 | <listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-D"><constant>DTV_ATSCMH_SCCC_CODE_MODE_D</constant></link></para></listitem> | 1161 | <listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-D"><constant>DTV_ATSCMH_SCCC_CODE_MODE_D</constant></link></para></listitem> |
| 990 | </itemizedlist> | 1162 | </itemizedlist> |
| 1163 | <para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para> | ||
| 991 | </section> | 1164 | </section> |
| 992 | <section id="dtmb-params"> | 1165 | <section id="dtmb-params"> |
| 993 | <title>DTMB delivery system</title> | 1166 | <title>DTMB delivery system</title> |
| @@ -1007,6 +1180,7 @@ enum fe_interleaving { | |||
| 1007 | <listitem><para><link linkend="DTV-INTERLEAVING"><constant>DTV_INTERLEAVING</constant></link></para></listitem> | 1180 | <listitem><para><link linkend="DTV-INTERLEAVING"><constant>DTV_INTERLEAVING</constant></link></para></listitem> |
| 1008 | <listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem> | 1181 | <listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem> |
| 1009 | </itemizedlist> | 1182 | </itemizedlist> |
| 1183 | <para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para> | ||
| 1010 | </section> | 1184 | </section> |
| 1011 | </section> | 1185 | </section> |
| 1012 | <section id="frontend-property-cable-systems"> | 1186 | <section id="frontend-property-cable-systems"> |
| @@ -1028,6 +1202,7 @@ enum fe_interleaving { | |||
| 1028 | <listitem><para><link linkend="DTV-INNER-FEC"><constant>DTV_INNER_FEC</constant></link></para></listitem> | 1202 | <listitem><para><link linkend="DTV-INNER-FEC"><constant>DTV_INNER_FEC</constant></link></para></listitem> |
| 1029 | <listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem> | 1203 | <listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem> |
| 1030 | </itemizedlist> | 1204 | </itemizedlist> |
| 1205 | <para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para> | ||
| 1031 | </section> | 1206 | </section> |
| 1032 | <section id="dvbc-annex-b-params"> | 1207 | <section id="dvbc-annex-b-params"> |
| 1033 | <title>DVB-C Annex B delivery system</title> | 1208 | <title>DVB-C Annex B delivery system</title> |
| @@ -1043,6 +1218,7 @@ enum fe_interleaving { | |||
| 1043 | <listitem><para><link linkend="DTV-INVERSION"><constant>DTV_INVERSION</constant></link></para></listitem> | 1218 | <listitem><para><link linkend="DTV-INVERSION"><constant>DTV_INVERSION</constant></link></para></listitem> |
| 1044 | <listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem> | 1219 | <listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem> |
| 1045 | </itemizedlist> | 1220 | </itemizedlist> |
| 1221 | <para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para> | ||
| 1046 | </section> | 1222 | </section> |
| 1047 | </section> | 1223 | </section> |
| 1048 | <section id="frontend-property-satellital-systems"> | 1224 | <section id="frontend-property-satellital-systems"> |
| @@ -1062,6 +1238,7 @@ enum fe_interleaving { | |||
| 1062 | <listitem><para><link linkend="DTV-VOLTAGE"><constant>DTV_VOLTAGE</constant></link></para></listitem> | 1238 | <listitem><para><link linkend="DTV-VOLTAGE"><constant>DTV_VOLTAGE</constant></link></para></listitem> |
| 1063 | <listitem><para><link linkend="DTV-TONE"><constant>DTV_TONE</constant></link></para></listitem> | 1239 | <listitem><para><link linkend="DTV-TONE"><constant>DTV_TONE</constant></link></para></listitem> |
| 1064 | </itemizedlist> | 1240 | </itemizedlist> |
| 1241 | <para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para> | ||
| 1065 | <para>Future implementations might add those two missing parameters:</para> | 1242 | <para>Future implementations might add those two missing parameters:</para> |
| 1066 | <itemizedlist mark='opencircle'> | 1243 | <itemizedlist mark='opencircle'> |
| 1067 | <listitem><para><link linkend="DTV-DISEQC-MASTER"><constant>DTV_DISEQC_MASTER</constant></link></para></listitem> | 1244 | <listitem><para><link linkend="DTV-DISEQC-MASTER"><constant>DTV_DISEQC_MASTER</constant></link></para></listitem> |
| @@ -1077,6 +1254,7 @@ enum fe_interleaving { | |||
| 1077 | <listitem><para><link linkend="DTV-ROLLOFF"><constant>DTV_ROLLOFF</constant></link></para></listitem> | 1254 | <listitem><para><link linkend="DTV-ROLLOFF"><constant>DTV_ROLLOFF</constant></link></para></listitem> |
| 1078 | <listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem> | 1255 | <listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem> |
| 1079 | </itemizedlist> | 1256 | </itemizedlist> |
| 1257 | <para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para> | ||
| 1080 | </section> | 1258 | </section> |
| 1081 | <section id="turbo-params"> | 1259 | <section id="turbo-params"> |
| 1082 | <title>Turbo code delivery system</title> | 1260 | <title>Turbo code delivery system</title> |
diff --git a/Documentation/DocBook/media/dvb/frontend.xml b/Documentation/DocBook/media/dvb/frontend.xml index 426c2526a454..df39ba395df0 100644 --- a/Documentation/DocBook/media/dvb/frontend.xml +++ b/Documentation/DocBook/media/dvb/frontend.xml | |||
| @@ -230,7 +230,7 @@ typedef enum fe_status { | |||
| 230 | <entry align="char">The frontend has found a DVB signal</entry> | 230 | <entry align="char">The frontend has found a DVB signal</entry> |
| 231 | </row><row> | 231 | </row><row> |
| 232 | <entry align="char">FE_HAS_VITERBI</entry> | 232 | <entry align="char">FE_HAS_VITERBI</entry> |
| 233 | <entry align="char">The frontend FEC code is stable</entry> | 233 | <entry align="char">The frontend FEC inner coding (Viterbi, LDPC or other inner code) is stable</entry> |
| 234 | </row><row> | 234 | </row><row> |
| 235 | <entry align="char">FE_HAS_SYNC</entry> | 235 | <entry align="char">FE_HAS_SYNC</entry> |
| 236 | <entry align="char">Syncronization bytes was found</entry> | 236 | <entry align="char">Syncronization bytes was found</entry> |
diff --git a/Documentation/DocBook/media/v4l/common.xml b/Documentation/DocBook/media/v4l/common.xml index 73c6847436c9..ae06afbbb3a9 100644 --- a/Documentation/DocBook/media/v4l/common.xml +++ b/Documentation/DocBook/media/v4l/common.xml | |||
| @@ -609,7 +609,7 @@ to zero and the <constant>VIDIOC_G_STD</constant>, | |||
| 609 | <para>Applications can make use of the <xref linkend="input-capabilities" /> and | 609 | <para>Applications can make use of the <xref linkend="input-capabilities" /> and |
| 610 | <xref linkend="output-capabilities"/> flags to determine whether the video standard ioctls | 610 | <xref linkend="output-capabilities"/> flags to determine whether the video standard ioctls |
| 611 | are available for the device.</para> | 611 | are available for the device.</para> |
| 612 | &ENOTTY;. | 612 | |
| 613 | <para>See <xref linkend="buffer" /> for a rationale. Probably | 613 | <para>See <xref linkend="buffer" /> for a rationale. Probably |
| 614 | even USB cameras follow some well known video standard. It might have | 614 | even USB cameras follow some well known video standard. It might have |
| 615 | been better to explicitly indicate elsewhere if a device cannot live | 615 | been better to explicitly indicate elsewhere if a device cannot live |
diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index 3dd9e78815d1..104a1a2b8849 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml | |||
| @@ -2477,6 +2477,22 @@ that used it. It was originally scheduled for removal in 2.6.35. | |||
| 2477 | </orderedlist> | 2477 | </orderedlist> |
| 2478 | </section> | 2478 | </section> |
| 2479 | 2479 | ||
| 2480 | <section> | ||
| 2481 | <title>V4L2 in Linux 3.9</title> | ||
| 2482 | <orderedlist> | ||
| 2483 | <listitem> | ||
| 2484 | <para>Added timestamp types to | ||
| 2485 | <structfield>flags</structfield> field in | ||
| 2486 | <structname>v4l2_buffer</structname>. See <xref | ||
| 2487 | linkend="buffer-flags" />.</para> | ||
| 2488 | </listitem> | ||
| 2489 | <listitem> | ||
| 2490 | <para>Added <constant>V4L2_EVENT_CTRL_CH_RANGE</constant> control event | ||
| 2491 | changes flag. See <xref linkend="changes-flags"/>.</para> | ||
| 2492 | </listitem> | ||
| 2493 | </orderedlist> | ||
| 2494 | </section> | ||
| 2495 | |||
| 2480 | <section id="other"> | 2496 | <section id="other"> |
| 2481 | <title>Relation of V4L2 to other Linux multimedia APIs</title> | 2497 | <title>Relation of V4L2 to other Linux multimedia APIs</title> |
| 2482 | 2498 | ||
diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 7fe5be1d3bbb..9e8f85498678 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml | |||
| @@ -203,29 +203,6 @@ and should not be used in new drivers and applications.</entry> | |||
| 203 | <entry>boolean</entry> | 203 | <entry>boolean</entry> |
| 204 | <entry>Mirror the picture vertically.</entry> | 204 | <entry>Mirror the picture vertically.</entry> |
| 205 | </row> | 205 | </row> |
| 206 | <row> | ||
| 207 | <entry><constant>V4L2_CID_HCENTER_DEPRECATED</constant> (formerly <constant>V4L2_CID_HCENTER</constant>)</entry> | ||
| 208 | <entry>integer</entry> | ||
| 209 | <entry>Horizontal image centering. This control is | ||
| 210 | deprecated. New drivers and applications should use the <link | ||
| 211 | linkend="camera-controls">Camera class controls</link> | ||
| 212 | <constant>V4L2_CID_PAN_ABSOLUTE</constant>, | ||
| 213 | <constant>V4L2_CID_PAN_RELATIVE</constant> and | ||
| 214 | <constant>V4L2_CID_PAN_RESET</constant> instead.</entry> | ||
| 215 | </row> | ||
| 216 | <row> | ||
| 217 | <entry><constant>V4L2_CID_VCENTER_DEPRECATED</constant> | ||
| 218 | (formerly <constant>V4L2_CID_VCENTER</constant>)</entry> | ||
| 219 | <entry>integer</entry> | ||
| 220 | <entry>Vertical image centering. Centering is intended to | ||
| 221 | <emphasis>physically</emphasis> adjust cameras. For image cropping see | ||
| 222 | <xref linkend="crop" />, for clipping <xref linkend="overlay" />. This | ||
| 223 | control is deprecated. New drivers and applications should use the | ||
| 224 | <link linkend="camera-controls">Camera class controls</link> | ||
| 225 | <constant>V4L2_CID_TILT_ABSOLUTE</constant>, | ||
| 226 | <constant>V4L2_CID_TILT_RELATIVE</constant> and | ||
| 227 | <constant>V4L2_CID_TILT_RESET</constant> instead.</entry> | ||
| 228 | </row> | ||
| 229 | <row id="v4l2-power-line-frequency"> | 206 | <row id="v4l2-power-line-frequency"> |
| 230 | <entry><constant>V4L2_CID_POWER_LINE_FREQUENCY</constant></entry> | 207 | <entry><constant>V4L2_CID_POWER_LINE_FREQUENCY</constant></entry> |
| 231 | <entry>enum</entry> | 208 | <entry>enum</entry> |
diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 388a34032653..e6c58559ca6b 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml | |||
| @@ -477,7 +477,7 @@ rest should be evident.</para> | |||
| 477 | 477 | ||
| 478 | <note> | 478 | <note> |
| 479 | <title>Experimental</title> | 479 | <title>Experimental</title> |
| 480 | <para>This is an <link linkend="experimental"> experimental </link> | 480 | <para>This is an <link linkend="experimental">experimental</link> |
| 481 | interface and may change in the future.</para> | 481 | interface and may change in the future.</para> |
| 482 | </note> | 482 | </note> |
| 483 | 483 | ||
| @@ -488,7 +488,7 @@ DMA buffer from userspace using a file descriptor previously exported for a | |||
| 488 | different or the same device (known as the importer role), or both. This | 488 | different or the same device (known as the importer role), or both. This |
| 489 | section describes the DMABUF importer role API in V4L2.</para> | 489 | section describes the DMABUF importer role API in V4L2.</para> |
| 490 | 490 | ||
| 491 | <para>Refer to <link linked="vidioc-expbuf"> DMABUF exporting </link> for | 491 | <para>Refer to <link linkend="vidioc-expbuf">DMABUF exporting</link> for |
| 492 | details about exporting V4L2 buffers as DMABUF file descriptors.</para> | 492 | details about exporting V4L2 buffers as DMABUF file descriptors.</para> |
| 493 | 493 | ||
| 494 | <para>Input and output devices support the streaming I/O method when the | 494 | <para>Input and output devices support the streaming I/O method when the |
| @@ -741,17 +741,19 @@ applications when an output stream.</entry> | |||
| 741 | <entry>struct timeval</entry> | 741 | <entry>struct timeval</entry> |
| 742 | <entry><structfield>timestamp</structfield></entry> | 742 | <entry><structfield>timestamp</structfield></entry> |
| 743 | <entry></entry> | 743 | <entry></entry> |
| 744 | <entry><para>For input streams this is the | 744 | <entry><para>For input streams this is time when the first data |
| 745 | system time (as returned by the <function>gettimeofday()</function> | 745 | byte was captured, as returned by the |
| 746 | function) when the first data byte was captured. For output streams | 746 | <function>clock_gettime()</function> function for the relevant |
| 747 | the data will not be displayed before this time, secondary to the | 747 | clock id; see <constant>V4L2_BUF_FLAG_TIMESTAMP_*</constant> in |
| 748 | nominal frame rate determined by the current video standard in | 748 | <xref linkend="buffer-flags" />. For output streams the data |
| 749 | enqueued order. Applications can for example zero this field to | 749 | will not be displayed before this time, secondary to the nominal |
| 750 | display frames as soon as possible. The driver stores the time at | 750 | frame rate determined by the current video standard in enqueued |
| 751 | which the first data byte was actually sent out in the | 751 | order. Applications can for example zero this field to display |
| 752 | <structfield>timestamp</structfield> field. This permits | 752 | frames as soon as possible. The driver stores the time at which |
| 753 | applications to monitor the drift between the video and system | 753 | the first data byte was actually sent out in the |
| 754 | clock.</para></entry> | 754 | <structfield>timestamp</structfield> field. This permits |
| 755 | applications to monitor the drift between the video and system | ||
| 756 | clock.</para></entry> | ||
| 755 | </row> | 757 | </row> |
| 756 | <row> | 758 | <row> |
| 757 | <entry>&v4l2-timecode;</entry> | 759 | <entry>&v4l2-timecode;</entry> |
| @@ -903,7 +905,7 @@ should set this to 0.</entry> | |||
| 903 | </row> | 905 | </row> |
| 904 | <row> | 906 | <row> |
| 905 | <entry></entry> | 907 | <entry></entry> |
| 906 | <entry>__unsigned long</entry> | 908 | <entry>unsigned long</entry> |
| 907 | <entry><structfield>userptr</structfield></entry> | 909 | <entry><structfield>userptr</structfield></entry> |
| 908 | <entry>When the memory type in the containing &v4l2-buffer; is | 910 | <entry>When the memory type in the containing &v4l2-buffer; is |
| 909 | <constant>V4L2_MEMORY_USERPTR</constant>, this is a userspace | 911 | <constant>V4L2_MEMORY_USERPTR</constant>, this is a userspace |
| @@ -1114,6 +1116,35 @@ Typically applications shall use this flag for output buffers if the data | |||
| 1114 | in this buffer has not been created by the CPU but by some DMA-capable unit, | 1116 | in this buffer has not been created by the CPU but by some DMA-capable unit, |
| 1115 | in which case caches have not been used.</entry> | 1117 | in which case caches have not been used.</entry> |
| 1116 | </row> | 1118 | </row> |
| 1119 | <row> | ||
| 1120 | <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MASK</constant></entry> | ||
| 1121 | <entry>0xe000</entry> | ||
| 1122 | <entry>Mask for timestamp types below. To test the | ||
| 1123 | timestamp type, mask out bits not belonging to timestamp | ||
| 1124 | type by performing a logical and operation with buffer | ||
| 1125 | flags and timestamp mask.</entry> | ||
| 1126 | </row> | ||
| 1127 | <row> | ||
| 1128 | <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN</constant></entry> | ||
| 1129 | <entry>0x0000</entry> | ||
| 1130 | <entry>Unknown timestamp type. This type is used by | ||
| 1131 | drivers before Linux 3.9 and may be either monotonic (see | ||
| 1132 | below) or realtime (wall clock). Monotonic clock has been | ||
| 1133 | favoured in embedded systems whereas most of the drivers | ||
| 1134 | use the realtime clock. Either kinds of timestamps are | ||
| 1135 | available in user space via | ||
| 1136 | <function>clock_gettime(2)</function> using clock IDs | ||
| 1137 | <constant>CLOCK_MONOTONIC</constant> and | ||
| 1138 | <constant>CLOCK_REALTIME</constant>, respectively.</entry> | ||
| 1139 | </row> | ||
| 1140 | <row> | ||
| 1141 | <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC</constant></entry> | ||
| 1142 | <entry>0x2000</entry> | ||
| 1143 | <entry>The buffer timestamp has been taken from the | ||
| 1144 | <constant>CLOCK_MONOTONIC</constant> clock. To access the | ||
| 1145 | same clock outside V4L2, use | ||
| 1146 | <function>clock_gettime(2)</function> .</entry> | ||
| 1147 | </row> | ||
| 1117 | </tbody> | 1148 | </tbody> |
| 1118 | </tgroup> | 1149 | </tgroup> |
| 1119 | </table> | 1150 | </table> |
diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml b/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml index a990b34d911a..f3a3d459fcdf 100644 --- a/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml +++ b/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml | |||
| @@ -6,7 +6,7 @@ | |||
| 6 | <refnamediv> | 6 | <refnamediv> |
| 7 | <refname id="V4L2-PIX-FMT-NV12M"><constant>V4L2_PIX_FMT_NV12M</constant></refname> | 7 | <refname id="V4L2-PIX-FMT-NV12M"><constant>V4L2_PIX_FMT_NV12M</constant></refname> |
| 8 | <refname id="V4L2-PIX-FMT-NV21M"><constant>V4L2_PIX_FMT_NV21M</constant></refname> | 8 | <refname id="V4L2-PIX-FMT-NV21M"><constant>V4L2_PIX_FMT_NV21M</constant></refname> |
| 9 | <refname id="V4L2-PIX-FMT-NV12MT_16X16"><constant>V4L2_PIX_FMT_NV12MT_16X16</constant></refname> | 9 | <refname id="V4L2-PIX-FMT-NV12MT-16X16"><constant>V4L2_PIX_FMT_NV12MT_16X16</constant></refname> |
| 10 | <refpurpose>Variation of <constant>V4L2_PIX_FMT_NV12</constant> and <constant>V4L2_PIX_FMT_NV21</constant> with planes | 10 | <refpurpose>Variation of <constant>V4L2_PIX_FMT_NV12</constant> and <constant>V4L2_PIX_FMT_NV21</constant> with planes |
| 11 | non contiguous in memory. </refpurpose> | 11 | non contiguous in memory. </refpurpose> |
| 12 | </refnamediv> | 12 | </refnamediv> |
diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml new file mode 100644 index 000000000000..29acc2098cc2 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml | |||
| @@ -0,0 +1,34 @@ | |||
| 1 | <refentry> | ||
| 2 | <refmeta> | ||
| 3 | <refentrytitle> | ||
| 4 | V4L2_PIX_FMT_SBGGR10ALAW8 ('aBA8'), | ||
| 5 | V4L2_PIX_FMT_SGBRG10ALAW8 ('aGA8'), | ||
| 6 | V4L2_PIX_FMT_SGRBG10ALAW8 ('agA8'), | ||
| 7 | V4L2_PIX_FMT_SRGGB10ALAW8 ('aRA8'), | ||
| 8 | </refentrytitle> | ||
| 9 | &manvol; | ||
| 10 | </refmeta> | ||
| 11 | <refnamediv> | ||
| 12 | <refname id="V4L2-PIX-FMT-SBGGR10ALAW8"> | ||
| 13 | <constant>V4L2_PIX_FMT_SBGGR10ALAW8</constant> | ||
| 14 | </refname> | ||
| 15 | <refname id="V4L2-PIX-FMT-SGBRG10ALAW8"> | ||
| 16 | <constant>V4L2_PIX_FMT_SGBRG10ALAW8</constant> | ||
| 17 | </refname> | ||
| 18 | <refname id="V4L2-PIX-FMT-SGRBG10ALAW8"> | ||
| 19 | <constant>V4L2_PIX_FMT_SGRBG10ALAW8</constant> | ||
| 20 | </refname> | ||
| 21 | <refname id="V4L2-PIX-FMT-SRGGB10ALAW8"> | ||
| 22 | <constant>V4L2_PIX_FMT_SRGGB10ALAW8</constant> | ||
| 23 | </refname> | ||
| 24 | <refpurpose>10-bit Bayer formats compressed to 8 bits</refpurpose> | ||
| 25 | </refnamediv> | ||
| 26 | <refsect1> | ||
| 27 | <title>Description</title> | ||
| 28 | <para>The following four pixel formats are raw sRGB / Bayer | ||
| 29 | formats with 10 bits per color compressed to 8 bits each, | ||
| 30 | using the A-LAW algorithm. Each color component consumes 8 | ||
| 31 | bits of memory. In other respects this format is similar to | ||
| 32 | <xref linkend="V4L2-PIX-FMT-SRGGB8"></xref>.</para> | ||
| 33 | </refsect1> | ||
| 34 | </refentry> | ||
diff --git a/Documentation/DocBook/media/v4l/pixfmt-uv8.xml b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml new file mode 100644 index 000000000000..c507c1f73cd0 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-uv8.xml | |||
| @@ -0,0 +1,62 @@ | |||
| 1 | <refentry id="V4L2-PIX-FMT-UV8"> | ||
| 2 | <refmeta> | ||
| 3 | <refentrytitle>V4L2_PIX_FMT_UV8 ('UV8')</refentrytitle> | ||
| 4 | &manvol; | ||
| 5 | </refmeta> | ||
| 6 | <refnamediv> | ||
| 7 | <refname><constant>V4L2_PIX_FMT_UV8</constant></refname> | ||
| 8 | <refpurpose>UV plane interleaved</refpurpose> | ||
| 9 | </refnamediv> | ||
| 10 | <refsect1> | ||
| 11 | <title>Description</title> | ||
| 12 | <para>In this format there is no Y plane, Only CbCr plane. ie | ||
| 13 | (UV interleaved)</para> | ||
| 14 | <example> | ||
| 15 | <title> | ||
| 16 | <constant>V4L2_PIX_FMT_UV8</constant> | ||
| 17 | pixel image | ||
| 18 | </title> | ||
| 19 | |||
| 20 | <formalpara> | ||
| 21 | <title>Byte Order.</title> | ||
| 22 | <para>Each cell is one byte. | ||
| 23 | <informaltable frame="none"> | ||
| 24 | <tgroup cols="5" align="center"> | ||
| 25 | <colspec align="left" colwidth="2*" /> | ||
| 26 | <tbody valign="top"> | ||
| 27 | <row> | ||
| 28 | <entry>start + 0:</entry> | ||
| 29 | <entry>Cb<subscript>00</subscript></entry> | ||
| 30 | <entry>Cr<subscript>00</subscript></entry> | ||
| 31 | <entry>Cb<subscript>01</subscript></entry> | ||
| 32 | <entry>Cr<subscript>01</subscript></entry> | ||
| 33 | </row> | ||
| 34 | <row> | ||
| 35 | <entry>start + 4:</entry> | ||
| 36 | <entry>Cb<subscript>10</subscript></entry> | ||
| 37 | <entry>Cr<subscript>10</subscript></entry> | ||
| 38 | <entry>Cb<subscript>11</subscript></entry> | ||
| 39 | <entry>Cr<subscript>11</subscript></entry> | ||
| 40 | </row> | ||
| 41 | <row> | ||
| 42 | <entry>start + 8:</entry> | ||
| 43 | <entry>Cb<subscript>20</subscript></entry> | ||
| 44 | <entry>Cr<subscript>20</subscript></entry> | ||
| 45 | <entry>Cb<subscript>21</subscript></entry> | ||
| 46 | <entry>Cr<subscript>21</subscript></entry> | ||
| 47 | </row> | ||
| 48 | <row> | ||
| 49 | <entry>start + 12:</entry> | ||
| 50 | <entry>Cb<subscript>30</subscript></entry> | ||
| 51 | <entry>Cr<subscript>30</subscript></entry> | ||
| 52 | <entry>Cb<subscript>31</subscript></entry> | ||
| 53 | <entry>Cr<subscript>31</subscript></entry> | ||
| 54 | </row> | ||
| 55 | </tbody> | ||
| 56 | </tgroup> | ||
| 57 | </informaltable> | ||
| 58 | </para> | ||
| 59 | </formalpara> | ||
| 60 | </example> | ||
| 61 | </refsect1> | ||
| 62 | </refentry> | ||
diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml index bf94f417592c..99b8d2ad6e4f 100644 --- a/Documentation/DocBook/media/v4l/pixfmt.xml +++ b/Documentation/DocBook/media/v4l/pixfmt.xml | |||
| @@ -673,6 +673,7 @@ access the palette, this must be done with ioctls of the Linux framebuffer API.< | |||
| 673 | &sub-srggb8; | 673 | &sub-srggb8; |
| 674 | &sub-sbggr16; | 674 | &sub-sbggr16; |
| 675 | &sub-srggb10; | 675 | &sub-srggb10; |
| 676 | &sub-srggb10alaw8; | ||
| 676 | &sub-srggb10dpcm8; | 677 | &sub-srggb10dpcm8; |
| 677 | &sub-srggb12; | 678 | &sub-srggb12; |
| 678 | </section> | 679 | </section> |
| @@ -701,6 +702,7 @@ information.</para> | |||
| 701 | &sub-y12; | 702 | &sub-y12; |
| 702 | &sub-y10b; | 703 | &sub-y10b; |
| 703 | &sub-y16; | 704 | &sub-y16; |
| 705 | &sub-uv8; | ||
| 704 | &sub-yuyv; | 706 | &sub-yuyv; |
| 705 | &sub-uyvy; | 707 | &sub-uyvy; |
| 706 | &sub-yvyu; | 708 | &sub-yvyu; |
diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index a0a936455fae..cc51372ed5e0 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml | |||
| @@ -353,9 +353,9 @@ | |||
| 353 | <listitem><para>The number of bits per pixel component. All components are | 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> | 354 | transferred on the same number of bits. Common values are 8, 10 and 12.</para> |
| 355 | </listitem> | 355 | </listitem> |
| 356 | <listitem><para>If the pixel components are DPCM-compressed, a mention of the | 356 | <listitem><para>The compression (optional). If the pixel components are |
| 357 | DPCM compression and the number of bits per compressed pixel component.</para> | 357 | ALAW- or DPCM-compressed, a mention of the compression scheme and the |
| 358 | </listitem> | 358 | number of bits per compressed pixel component.</para></listitem> |
| 359 | <listitem><para>The number of bus samples per pixel. Pixels that are wider than | 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 | 360 | the bus width must be transferred in multiple samples. Common values are |
| 361 | 1 and 2.</para></listitem> | 361 | 1 and 2.</para></listitem> |
| @@ -504,6 +504,74 @@ | |||
| 504 | <entry>r<subscript>1</subscript></entry> | 504 | <entry>r<subscript>1</subscript></entry> |
| 505 | <entry>r<subscript>0</subscript></entry> | 505 | <entry>r<subscript>0</subscript></entry> |
| 506 | </row> | 506 | </row> |
| 507 | <row id="V4L2-MBUS-FMT-SBGGR10-ALAW8-1X8"> | ||
| 508 | <entry>V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8</entry> | ||
| 509 | <entry>0x3015</entry> | ||
| 510 | <entry></entry> | ||
| 511 | <entry>-</entry> | ||
| 512 | <entry>-</entry> | ||
| 513 | <entry>-</entry> | ||
| 514 | <entry>-</entry> | ||
| 515 | <entry>b<subscript>7</subscript></entry> | ||
| 516 | <entry>b<subscript>6</subscript></entry> | ||
| 517 | <entry>b<subscript>5</subscript></entry> | ||
| 518 | <entry>b<subscript>4</subscript></entry> | ||
| 519 | <entry>b<subscript>3</subscript></entry> | ||
| 520 | <entry>b<subscript>2</subscript></entry> | ||
| 521 | <entry>b<subscript>1</subscript></entry> | ||
| 522 | <entry>b<subscript>0</subscript></entry> | ||
| 523 | </row> | ||
| 524 | <row id="V4L2-MBUS-FMT-SGBRG10-ALAW8-1X8"> | ||
| 525 | <entry>V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8</entry> | ||
| 526 | <entry>0x3016</entry> | ||
| 527 | <entry></entry> | ||
| 528 | <entry>-</entry> | ||
| 529 | <entry>-</entry> | ||
| 530 | <entry>-</entry> | ||
| 531 | <entry>-</entry> | ||
| 532 | <entry>g<subscript>7</subscript></entry> | ||
| 533 | <entry>g<subscript>6</subscript></entry> | ||
| 534 | <entry>g<subscript>5</subscript></entry> | ||
| 535 | <entry>g<subscript>4</subscript></entry> | ||
| 536 | <entry>g<subscript>3</subscript></entry> | ||
| 537 | <entry>g<subscript>2</subscript></entry> | ||
| 538 | <entry>g<subscript>1</subscript></entry> | ||
| 539 | <entry>g<subscript>0</subscript></entry> | ||
| 540 | </row> | ||
| 541 | <row id="V4L2-MBUS-FMT-SGRBG10-ALAW8-1X8"> | ||
| 542 | <entry>V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8</entry> | ||
| 543 | <entry>0x3017</entry> | ||
| 544 | <entry></entry> | ||
| 545 | <entry>-</entry> | ||
| 546 | <entry>-</entry> | ||
| 547 | <entry>-</entry> | ||
| 548 | <entry>-</entry> | ||
| 549 | <entry>g<subscript>7</subscript></entry> | ||
| 550 | <entry>g<subscript>6</subscript></entry> | ||
| 551 | <entry>g<subscript>5</subscript></entry> | ||
| 552 | <entry>g<subscript>4</subscript></entry> | ||
| 553 | <entry>g<subscript>3</subscript></entry> | ||
| 554 | <entry>g<subscript>2</subscript></entry> | ||
| 555 | <entry>g<subscript>1</subscript></entry> | ||
| 556 | <entry>g<subscript>0</subscript></entry> | ||
| 557 | </row> | ||
| 558 | <row id="V4L2-MBUS-FMT-SRGGB10-ALAW8-1X8"> | ||
| 559 | <entry>V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8</entry> | ||
| 560 | <entry>0x3018</entry> | ||
| 561 | <entry></entry> | ||
| 562 | <entry>-</entry> | ||
| 563 | <entry>-</entry> | ||
| 564 | <entry>-</entry> | ||
| 565 | <entry>-</entry> | ||
| 566 | <entry>r<subscript>7</subscript></entry> | ||
| 567 | <entry>r<subscript>6</subscript></entry> | ||
| 568 | <entry>r<subscript>5</subscript></entry> | ||
| 569 | <entry>r<subscript>4</subscript></entry> | ||
| 570 | <entry>r<subscript>3</subscript></entry> | ||
| 571 | <entry>r<subscript>2</subscript></entry> | ||
| 572 | <entry>r<subscript>1</subscript></entry> | ||
| 573 | <entry>r<subscript>0</subscript></entry> | ||
| 574 | </row> | ||
| 507 | <row id="V4L2-MBUS-FMT-SBGGR10-DPCM8-1X8"> | 575 | <row id="V4L2-MBUS-FMT-SBGGR10-DPCM8-1X8"> |
| 508 | <entry>V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8</entry> | 576 | <entry>V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8</entry> |
| 509 | <entry>0x300b</entry> | 577 | <entry>0x300b</entry> |
| @@ -853,10 +921,16 @@ | |||
| 853 | <title>Packed YUV Formats</title> | 921 | <title>Packed YUV Formats</title> |
| 854 | 922 | ||
| 855 | <para>Those data formats transfer pixel data as (possibly downsampled) Y, U | 923 | <para>Those data formats transfer pixel data as (possibly downsampled) Y, U |
| 856 | and V components. The format code is made of the following information. | 924 | and V components. Some formats include dummy bits in some of their samples |
| 925 | and are collectively referred to as "YDYC" (Y-Dummy-Y-Chroma) formats. | ||
| 926 | One cannot rely on the values of these dummy bits as those are undefined. | ||
| 927 | </para> | ||
| 928 | <para>The format code is made of the following information. | ||
| 857 | <itemizedlist> | 929 | <itemizedlist> |
| 858 | <listitem><para>The Y, U and V components order code, as transferred on the | 930 | <listitem><para>The Y, U and V components order code, as transferred on the |
| 859 | bus. Possible values are YUYV, UYVY, YVYU and VYUY.</para></listitem> | 931 | bus. Possible values are YUYV, UYVY, YVYU and VYUY for formats with no |
| 932 | dummy bit, and YDYUYDYV, YDYVYDYU, YUYDYVYD and YVYDYUYD for YDYC formats. | ||
| 933 | </para></listitem> | ||
| 860 | <listitem><para>The number of bits per pixel component. All components are | 934 | <listitem><para>The number of bits per pixel component. All components are |
| 861 | transferred on the same number of bits. Common values are 8, 10 and 12.</para> | 935 | transferred on the same number of bits. Common values are 8, 10 and 12.</para> |
| 862 | </listitem> | 936 | </listitem> |
| @@ -877,7 +951,21 @@ | |||
| 877 | U, Y, V, Y order will be named <constant>V4L2_MBUS_FMT_UYVY8_2X8</constant>. | 951 | U, Y, V, Y order will be named <constant>V4L2_MBUS_FMT_UYVY8_2X8</constant>. |
| 878 | </para> | 952 | </para> |
| 879 | 953 | ||
| 880 | <para>The following table lisst existing packet YUV formats.</para> | 954 | <para><xref linkend="v4l2-mbus-pixelcode-yuv8"/> list existing packet YUV |
| 955 | formats and describes the organization of each pixel data in each sample. | ||
| 956 | When a format pattern is split across multiple samples each of the samples | ||
| 957 | in the pattern is described.</para> | ||
| 958 | |||
| 959 | <para>The role of each bit transferred over the bus is identified by one | ||
| 960 | of the following codes.</para> | ||
| 961 | |||
| 962 | <itemizedlist> | ||
| 963 | <listitem><para>y<subscript>x</subscript> for luma component bit number x</para></listitem> | ||
| 964 | <listitem><para>u<subscript>x</subscript> for blue chroma component bit number x</para></listitem> | ||
| 965 | <listitem><para>v<subscript>x</subscript> for red chroma component bit number x</para></listitem> | ||
| 966 | <listitem><para>- for non-available bits (for positions higher than the bus width)</para></listitem> | ||
| 967 | <listitem><para>d for dummy bits</para></listitem> | ||
| 968 | </itemizedlist> | ||
| 881 | 969 | ||
| 882 | <table pgwide="0" frame="none" id="v4l2-mbus-pixelcode-yuv8"> | 970 | <table pgwide="0" frame="none" id="v4l2-mbus-pixelcode-yuv8"> |
| 883 | <title>YUV Formats</title> | 971 | <title>YUV Formats</title> |
| @@ -885,27 +973,37 @@ | |||
| 885 | <colspec colname="id" align="left" /> | 973 | <colspec colname="id" align="left" /> |
| 886 | <colspec colname="code" align="center"/> | 974 | <colspec colname="code" align="center"/> |
| 887 | <colspec colname="bit" /> | 975 | <colspec colname="bit" /> |
| 888 | <colspec colnum="4" colname="b19" align="center" /> | 976 | <colspec colnum="4" colname="b29" align="center" /> |
| 889 | <colspec colnum="5" colname="b18" align="center" /> | 977 | <colspec colnum="5" colname="b28" align="center" /> |
| 890 | <colspec colnum="6" colname="b17" align="center" /> | 978 | <colspec colnum="6" colname="b27" align="center" /> |
| 891 | <colspec colnum="7" colname="b16" align="center" /> | 979 | <colspec colnum="7" colname="b26" align="center" /> |
| 892 | <colspec colnum="8" colname="b15" align="center" /> | 980 | <colspec colnum="8" colname="b25" align="center" /> |
| 893 | <colspec colnum="9" colname="b14" align="center" /> | 981 | <colspec colnum="9" colname="b24" align="center" /> |
| 894 | <colspec colnum="10" colname="b13" align="center" /> | 982 | <colspec colnum="10" colname="b23" align="center" /> |
| 895 | <colspec colnum="11" colname="b12" align="center" /> | 983 | <colspec colnum="11" colname="b22" align="center" /> |
| 896 | <colspec colnum="12" colname="b11" align="center" /> | 984 | <colspec colnum="12" colname="b21" align="center" /> |
| 897 | <colspec colnum="13" colname="b10" align="center" /> | 985 | <colspec colnum="13" colname="b20" align="center" /> |
| 898 | <colspec colnum="14" colname="b09" align="center" /> | 986 | <colspec colnum="14" colname="b19" align="center" /> |
| 899 | <colspec colnum="15" colname="b08" align="center" /> | 987 | <colspec colnum="15" colname="b18" align="center" /> |
| 900 | <colspec colnum="16" colname="b07" align="center" /> | 988 | <colspec colnum="16" colname="b17" align="center" /> |
| 901 | <colspec colnum="17" colname="b06" align="center" /> | 989 | <colspec colnum="17" colname="b16" align="center" /> |
| 902 | <colspec colnum="18" colname="b05" align="center" /> | 990 | <colspec colnum="18" colname="b15" align="center" /> |
| 903 | <colspec colnum="19" colname="b04" align="center" /> | 991 | <colspec colnum="19" colname="b14" align="center" /> |
| 904 | <colspec colnum="20" colname="b03" align="center" /> | 992 | <colspec colnum="20" colname="b13" align="center" /> |
| 905 | <colspec colnum="21" colname="b02" align="center" /> | 993 | <colspec colnum="21" colname="b12" align="center" /> |
| 906 | <colspec colnum="22" colname="b01" align="center" /> | 994 | <colspec colnum="22" colname="b11" align="center" /> |
| 907 | <colspec colnum="23" colname="b00" align="center" /> | 995 | <colspec colnum="23" colname="b10" align="center" /> |
| 908 | <spanspec namest="b19" nameend="b00" spanname="b0" /> | 996 | <colspec colnum="24" colname="b09" align="center" /> |
| 997 | <colspec colnum="25" colname="b08" align="center" /> | ||
| 998 | <colspec colnum="26" colname="b07" align="center" /> | ||
| 999 | <colspec colnum="27" colname="b06" align="center" /> | ||
| 1000 | <colspec colnum="28" colname="b05" align="center" /> | ||
| 1001 | <colspec colnum="29" colname="b04" align="center" /> | ||
| 1002 | <colspec colnum="30" colname="b03" align="center" /> | ||
| 1003 | <colspec colnum="31" colname="b02" align="center" /> | ||
| 1004 | <colspec colnum="32" colname="b01" align="center" /> | ||
| 1005 | <colspec colnum="33" colname="b00" align="center" /> | ||
| 1006 | <spanspec namest="b29" nameend="b00" spanname="b0" /> | ||
| 909 | <thead> | 1007 | <thead> |
| 910 | <row> | 1008 | <row> |
| 911 | <entry>Identifier</entry> | 1009 | <entry>Identifier</entry> |
| @@ -917,6 +1015,16 @@ | |||
| 917 | <entry></entry> | 1015 | <entry></entry> |
| 918 | <entry></entry> | 1016 | <entry></entry> |
| 919 | <entry>Bit</entry> | 1017 | <entry>Bit</entry> |
| 1018 | <entry>29</entry> | ||
| 1019 | <entry>28</entry> | ||
| 1020 | <entry>27</entry> | ||
| 1021 | <entry>26</entry> | ||
| 1022 | <entry>25</entry> | ||
| 1023 | <entry>24</entry> | ||
| 1024 | <entry>23</entry> | ||
| 1025 | <entry>22</entry> | ||
| 1026 | <entry>21</entry> | ||
| 1027 | <entry>10</entry> | ||
| 920 | <entry>19</entry> | 1028 | <entry>19</entry> |
| 921 | <entry>18</entry> | 1029 | <entry>18</entry> |
| 922 | <entry>17</entry> | 1030 | <entry>17</entry> |
| @@ -944,16 +1052,8 @@ | |||
| 944 | <entry>V4L2_MBUS_FMT_Y8_1X8</entry> | 1052 | <entry>V4L2_MBUS_FMT_Y8_1X8</entry> |
| 945 | <entry>0x2001</entry> | 1053 | <entry>0x2001</entry> |
| 946 | <entry></entry> | 1054 | <entry></entry> |
| 947 | <entry>-</entry> | 1055 | &dash-ent-10; |
| 948 | <entry>-</entry> | 1056 | &dash-ent-10; |
| 949 | <entry>-</entry> | ||
| 950 | <entry>-</entry> | ||
| 951 | <entry>-</entry> | ||
| 952 | <entry>-</entry> | ||
| 953 | <entry>-</entry> | ||
| 954 | <entry>-</entry> | ||
| 955 | <entry>-</entry> | ||
| 956 | <entry>-</entry> | ||
| 957 | <entry>-</entry> | 1057 | <entry>-</entry> |
| 958 | <entry>-</entry> | 1058 | <entry>-</entry> |
| 959 | <entry>y<subscript>7</subscript></entry> | 1059 | <entry>y<subscript>7</subscript></entry> |
| @@ -965,9 +1065,9 @@ | |||
| 965 | <entry>y<subscript>1</subscript></entry> | 1065 | <entry>y<subscript>1</subscript></entry> |
| 966 | <entry>y<subscript>0</subscript></entry> | 1066 | <entry>y<subscript>0</subscript></entry> |
| 967 | </row> | 1067 | </row> |
| 968 | <row id="V4L2-MBUS-FMT-UYVY8-1_5X8"> | 1068 | <row id="V4L2-MBUS-FMT-UV8-1X8"> |
| 969 | <entry>V4L2_MBUS_FMT_UYVY8_1_5X8</entry> | 1069 | <entry>V4L2_MBUS_FMT_UV8_1X8</entry> |
| 970 | <entry>0x2002</entry> | 1070 | <entry>0x2015</entry> |
| 971 | <entry></entry> | 1071 | <entry></entry> |
| 972 | <entry>-</entry> | 1072 | <entry>-</entry> |
| 973 | <entry>-</entry> | 1073 | <entry>-</entry> |
| @@ -1006,6 +1106,40 @@ | |||
| 1006 | <entry>-</entry> | 1106 | <entry>-</entry> |
| 1007 | <entry>-</entry> | 1107 | <entry>-</entry> |
| 1008 | <entry>-</entry> | 1108 | <entry>-</entry> |
| 1109 | <entry>v<subscript>7</subscript></entry> | ||
| 1110 | <entry>v<subscript>6</subscript></entry> | ||
| 1111 | <entry>v<subscript>5</subscript></entry> | ||
| 1112 | <entry>v<subscript>4</subscript></entry> | ||
| 1113 | <entry>v<subscript>3</subscript></entry> | ||
| 1114 | <entry>v<subscript>2</subscript></entry> | ||
| 1115 | <entry>v<subscript>1</subscript></entry> | ||
| 1116 | <entry>v<subscript>0</subscript></entry> | ||
| 1117 | </row> | ||
| 1118 | <row id="V4L2-MBUS-FMT-UYVY8-1_5X8"> | ||
| 1119 | <entry>V4L2_MBUS_FMT_UYVY8_1_5X8</entry> | ||
| 1120 | <entry>0x2002</entry> | ||
| 1121 | <entry></entry> | ||
| 1122 | &dash-ent-10; | ||
| 1123 | &dash-ent-10; | ||
| 1124 | <entry>-</entry> | ||
| 1125 | <entry>-</entry> | ||
| 1126 | <entry>u<subscript>7</subscript></entry> | ||
| 1127 | <entry>u<subscript>6</subscript></entry> | ||
| 1128 | <entry>u<subscript>5</subscript></entry> | ||
| 1129 | <entry>u<subscript>4</subscript></entry> | ||
| 1130 | <entry>u<subscript>3</subscript></entry> | ||
| 1131 | <entry>u<subscript>2</subscript></entry> | ||
| 1132 | <entry>u<subscript>1</subscript></entry> | ||
| 1133 | <entry>u<subscript>0</subscript></entry> | ||
| 1134 | </row> | ||
| 1135 | <row> | ||
| 1136 | <entry></entry> | ||
| 1137 | <entry></entry> | ||
| 1138 | <entry></entry> | ||
| 1139 | &dash-ent-10; | ||
| 1140 | &dash-ent-10; | ||
| 1141 | <entry>-</entry> | ||
| 1142 | <entry>-</entry> | ||
| 1009 | <entry>y<subscript>7</subscript></entry> | 1143 | <entry>y<subscript>7</subscript></entry> |
| 1010 | <entry>y<subscript>6</subscript></entry> | 1144 | <entry>y<subscript>6</subscript></entry> |
| 1011 | <entry>y<subscript>5</subscript></entry> | 1145 | <entry>y<subscript>5</subscript></entry> |
| @@ -1019,16 +1153,8 @@ | |||
| 1019 | <entry></entry> | 1153 | <entry></entry> |
| 1020 | <entry></entry> | 1154 | <entry></entry> |
| 1021 | <entry></entry> | 1155 | <entry></entry> |
| 1022 | <entry>-</entry> | 1156 | &dash-ent-10; |
| 1023 | <entry>-</entry> | 1157 | &dash-ent-10; |
| 1024 | <entry>-</entry> | ||
| 1025 | <entry>-</entry> | ||
| 1026 | <entry>-</entry> | ||
| 1027 | <entry>-</entry> | ||
| 1028 | <entry>-</entry> | ||
| 1029 | <entry>-</entry> | ||
| 1030 | <entry>-</entry> | ||
| 1031 | <entry>-</entry> | ||
| 1032 | <entry>-</entry> | 1158 | <entry>-</entry> |
| 1033 | <entry>-</entry> | 1159 | <entry>-</entry> |
| 1034 | <entry>y<subscript>7</subscript></entry> | 1160 | <entry>y<subscript>7</subscript></entry> |
| @@ -1044,16 +1170,8 @@ | |||
| 1044 | <entry></entry> | 1170 | <entry></entry> |
| 1045 | <entry></entry> | 1171 | <entry></entry> |
| 1046 | <entry></entry> | 1172 | <entry></entry> |
| 1047 | <entry>-</entry> | 1173 | &dash-ent-10; |
| 1048 | <entry>-</entry> | 1174 | &dash-ent-10; |
| 1049 | <entry>-</entry> | ||
| 1050 | <entry>-</entry> | ||
| 1051 | <entry>-</entry> | ||
| 1052 | <entry>-</entry> | ||
| 1053 | <entry>-</entry> | ||
| 1054 | <entry>-</entry> | ||
| 1055 | <entry>-</entry> | ||
| 1056 | <entry>-</entry> | ||
| 1057 | <entry>-</entry> | 1175 | <entry>-</entry> |
| 1058 | <entry>-</entry> | 1176 | <entry>-</entry> |
| 1059 | <entry>v<subscript>7</subscript></entry> | 1177 | <entry>v<subscript>7</subscript></entry> |
| @@ -1069,16 +1187,8 @@ | |||
| 1069 | <entry></entry> | 1187 | <entry></entry> |
| 1070 | <entry></entry> | 1188 | <entry></entry> |
| 1071 | <entry></entry> | 1189 | <entry></entry> |
| 1072 | <entry>-</entry> | 1190 | &dash-ent-10; |
| 1073 | <entry>-</entry> | 1191 | &dash-ent-10; |
| 1074 | <entry>-</entry> | ||
| 1075 | <entry>-</entry> | ||
| 1076 | <entry>-</entry> | ||
| 1077 | <entry>-</entry> | ||
| 1078 | <entry>-</entry> | ||
| 1079 | <entry>-</entry> | ||
| 1080 | <entry>-</entry> | ||
| 1081 | <entry>-</entry> | ||
| 1082 | <entry>-</entry> | 1192 | <entry>-</entry> |
| 1083 | <entry>-</entry> | 1193 | <entry>-</entry> |
| 1084 | <entry>y<subscript>7</subscript></entry> | 1194 | <entry>y<subscript>7</subscript></entry> |
| @@ -1094,16 +1204,8 @@ | |||
| 1094 | <entry></entry> | 1204 | <entry></entry> |
| 1095 | <entry></entry> | 1205 | <entry></entry> |
| 1096 | <entry></entry> | 1206 | <entry></entry> |
| 1097 | <entry>-</entry> | 1207 | &dash-ent-10; |
| 1098 | <entry>-</entry> | 1208 | &dash-ent-10; |
| 1099 | <entry>-</entry> | ||
| 1100 | <entry>-</entry> | ||
| 1101 | <entry>-</entry> | ||
| 1102 | <entry>-</entry> | ||
| 1103 | <entry>-</entry> | ||
| 1104 | <entry>-</entry> | ||
| 1105 | <entry>-</entry> | ||
| 1106 | <entry>-</entry> | ||
| 1107 | <entry>-</entry> | 1209 | <entry>-</entry> |
| 1108 | <entry>-</entry> | 1210 | <entry>-</entry> |
| 1109 | <entry>y<subscript>7</subscript></entry> | 1211 | <entry>y<subscript>7</subscript></entry> |
| @@ -1119,16 +1221,8 @@ | |||
| 1119 | <entry>V4L2_MBUS_FMT_VYUY8_1_5X8</entry> | 1221 | <entry>V4L2_MBUS_FMT_VYUY8_1_5X8</entry> |
| 1120 | <entry>0x2003</entry> | 1222 | <entry>0x2003</entry> |
| 1121 | <entry></entry> | 1223 | <entry></entry> |
| 1122 | <entry>-</entry> | 1224 | &dash-ent-10; |
| 1123 | <entry>-</entry> | 1225 | &dash-ent-10; |
| 1124 | <entry>-</entry> | ||
| 1125 | <entry>-</entry> | ||
| 1126 | <entry>-</entry> | ||
| 1127 | <entry>-</entry> | ||
| 1128 | <entry>-</entry> | ||
| 1129 | <entry>-</entry> | ||
| 1130 | <entry>-</entry> | ||
| 1131 | <entry>-</entry> | ||
| 1132 | <entry>-</entry> | 1226 | <entry>-</entry> |
| 1133 | <entry>-</entry> | 1227 | <entry>-</entry> |
| 1134 | <entry>v<subscript>7</subscript></entry> | 1228 | <entry>v<subscript>7</subscript></entry> |
| @@ -1144,16 +1238,8 @@ | |||
| 1144 | <entry></entry> | 1238 | <entry></entry> |
| 1145 | <entry></entry> | 1239 | <entry></entry> |
| 1146 | <entry></entry> | 1240 | <entry></entry> |
| 1147 | <entry>-</entry> | 1241 | &dash-ent-10; |
| 1148 | <entry>-</entry> | 1242 | &dash-ent-10; |
| 1149 | <entry>-</entry> | ||
| 1150 | <entry>-</entry> | ||
| 1151 | <entry>-</entry> | ||
| 1152 | <entry>-</entry> | ||
| 1153 | <entry>-</entry> | ||
| 1154 | <entry>-</entry> | ||
| 1155 | <entry>-</entry> | ||
| 1156 | <entry>-</entry> | ||
| 1157 | <entry>-</entry> | 1243 | <entry>-</entry> |
| 1158 | <entry>-</entry> | 1244 | <entry>-</entry> |
| 1159 | <entry>y<subscript>7</subscript></entry> | 1245 | <entry>y<subscript>7</subscript></entry> |
| @@ -1169,16 +1255,8 @@ | |||
| 1169 | <entry></entry> | 1255 | <entry></entry> |
| 1170 | <entry></entry> | 1256 | <entry></entry> |
| 1171 | <entry></entry> | 1257 | <entry></entry> |
| 1172 | <entry>-</entry> | 1258 | &dash-ent-10; |
| 1173 | <entry>-</entry> | 1259 | &dash-ent-10; |
| 1174 | <entry>-</entry> | ||
| 1175 | <entry>-</entry> | ||
| 1176 | <entry>-</entry> | ||
| 1177 | <entry>-</entry> | ||
| 1178 | <entry>-</entry> | ||
| 1179 | <entry>-</entry> | ||
| 1180 | <entry>-</entry> | ||
| 1181 | <entry>-</entry> | ||
| 1182 | <entry>-</entry> | 1260 | <entry>-</entry> |
| 1183 | <entry>-</entry> | 1261 | <entry>-</entry> |
| 1184 | <entry>y<subscript>7</subscript></entry> | 1262 | <entry>y<subscript>7</subscript></entry> |
| @@ -1194,16 +1272,8 @@ | |||
| 1194 | <entry></entry> | 1272 | <entry></entry> |
| 1195 | <entry></entry> | 1273 | <entry></entry> |
| 1196 | <entry></entry> | 1274 | <entry></entry> |
| 1197 | <entry>-</entry> | 1275 | &dash-ent-10; |
| 1198 | <entry>-</entry> | 1276 | &dash-ent-10; |
| 1199 | <entry>-</entry> | ||
| 1200 | <entry>-</entry> | ||
| 1201 | <entry>-</entry> | ||
| 1202 | <entry>-</entry> | ||
| 1203 | <entry>-</entry> | ||
| 1204 | <entry>-</entry> | ||
| 1205 | <entry>-</entry> | ||
| 1206 | <entry>-</entry> | ||
| 1207 | <entry>-</entry> | 1277 | <entry>-</entry> |
| 1208 | <entry>-</entry> | 1278 | <entry>-</entry> |
| 1209 | <entry>u<subscript>7</subscript></entry> | 1279 | <entry>u<subscript>7</subscript></entry> |
| @@ -1219,16 +1289,8 @@ | |||
| 1219 | <entry></entry> | 1289 | <entry></entry> |
| 1220 | <entry></entry> | 1290 | <entry></entry> |
| 1221 | <entry></entry> | 1291 | <entry></entry> |
| 1222 | <entry>-</entry> | 1292 | &dash-ent-10; |
| 1223 | <entry>-</entry> | 1293 | &dash-ent-10; |
| 1224 | <entry>-</entry> | ||
| 1225 | <entry>-</entry> | ||
| 1226 | <entry>-</entry> | ||
| 1227 | <entry>-</entry> | ||
| 1228 | <entry>-</entry> | ||
| 1229 | <entry>-</entry> | ||
| 1230 | <entry>-</entry> | ||
| 1231 | <entry>-</entry> | ||
| 1232 | <entry>-</entry> | 1294 | <entry>-</entry> |
| 1233 | <entry>-</entry> | 1295 | <entry>-</entry> |
| 1234 | <entry>y<subscript>7</subscript></entry> | 1296 | <entry>y<subscript>7</subscript></entry> |
| @@ -1244,16 +1306,8 @@ | |||
| 1244 | <entry></entry> | 1306 | <entry></entry> |
| 1245 | <entry></entry> | 1307 | <entry></entry> |
| 1246 | <entry></entry> | 1308 | <entry></entry> |
| 1247 | <entry>-</entry> | 1309 | &dash-ent-10; |
| 1248 | <entry>-</entry> | 1310 | &dash-ent-10; |
| 1249 | <entry>-</entry> | ||
| 1250 | <entry>-</entry> | ||
| 1251 | <entry>-</entry> | ||
| 1252 | <entry>-</entry> | ||
| 1253 | <entry>-</entry> | ||
| 1254 | <entry>-</entry> | ||
| 1255 | <entry>-</entry> | ||
| 1256 | <entry>-</entry> | ||
| 1257 | <entry>-</entry> | 1311 | <entry>-</entry> |
| 1258 | <entry>-</entry> | 1312 | <entry>-</entry> |
| 1259 | <entry>y<subscript>7</subscript></entry> | 1313 | <entry>y<subscript>7</subscript></entry> |
| @@ -1269,16 +1323,8 @@ | |||
| 1269 | <entry>V4L2_MBUS_FMT_YUYV8_1_5X8</entry> | 1323 | <entry>V4L2_MBUS_FMT_YUYV8_1_5X8</entry> |
| 1270 | <entry>0x2004</entry> | 1324 | <entry>0x2004</entry> |
| 1271 | <entry></entry> | 1325 | <entry></entry> |
| 1272 | <entry>-</entry> | 1326 | &dash-ent-10; |
| 1273 | <entry>-</entry> | 1327 | &dash-ent-10; |
| 1274 | <entry>-</entry> | ||
| 1275 | <entry>-</entry> | ||
| 1276 | <entry>-</entry> | ||
| 1277 | <entry>-</entry> | ||
| 1278 | <entry>-</entry> | ||
| 1279 | <entry>-</entry> | ||
| 1280 | <entry>-</entry> | ||
| 1281 | <entry>-</entry> | ||
| 1282 | <entry>-</entry> | 1328 | <entry>-</entry> |
| 1283 | <entry>-</entry> | 1329 | <entry>-</entry> |
| 1284 | <entry>y<subscript>7</subscript></entry> | 1330 | <entry>y<subscript>7</subscript></entry> |
| @@ -1294,16 +1340,8 @@ | |||
| 1294 | <entry></entry> | 1340 | <entry></entry> |
| 1295 | <entry></entry> | 1341 | <entry></entry> |
| 1296 | <entry></entry> | 1342 | <entry></entry> |
| 1297 | <entry>-</entry> | 1343 | &dash-ent-10; |
| 1298 | <entry>-</entry> | 1344 | &dash-ent-10; |
| 1299 | <entry>-</entry> | ||
| 1300 | <entry>-</entry> | ||
| 1301 | <entry>-</entry> | ||
| 1302 | <entry>-</entry> | ||
| 1303 | <entry>-</entry> | ||
| 1304 | <entry>-</entry> | ||
| 1305 | <entry>-</entry> | ||
| 1306 | <entry>-</entry> | ||
| 1307 | <entry>-</entry> | 1345 | <entry>-</entry> |
| 1308 | <entry>-</entry> | 1346 | <entry>-</entry> |
| 1309 | <entry>y<subscript>7</subscript></entry> | 1347 | <entry>y<subscript>7</subscript></entry> |
| @@ -1319,16 +1357,8 @@ | |||
| 1319 | <entry></entry> | 1357 | <entry></entry> |
| 1320 | <entry></entry> | 1358 | <entry></entry> |
| 1321 | <entry></entry> | 1359 | <entry></entry> |
| 1322 | <entry>-</entry> | 1360 | &dash-ent-10; |
| 1323 | <entry>-</entry> | 1361 | &dash-ent-10; |
| 1324 | <entry>-</entry> | ||
| 1325 | <entry>-</entry> | ||
| 1326 | <entry>-</entry> | ||
| 1327 | <entry>-</entry> | ||
| 1328 | <entry>-</entry> | ||
| 1329 | <entry>-</entry> | ||
| 1330 | <entry>-</entry> | ||
| 1331 | <entry>-</entry> | ||
| 1332 | <entry>-</entry> | 1362 | <entry>-</entry> |
| 1333 | <entry>-</entry> | 1363 | <entry>-</entry> |
| 1334 | <entry>u<subscript>7</subscript></entry> | 1364 | <entry>u<subscript>7</subscript></entry> |
| @@ -1344,16 +1374,8 @@ | |||
| 1344 | <entry></entry> | 1374 | <entry></entry> |
| 1345 | <entry></entry> | 1375 | <entry></entry> |
| 1346 | <entry></entry> | 1376 | <entry></entry> |
| 1347 | <entry>-</entry> | 1377 | &dash-ent-10; |
| 1348 | <entry>-</entry> | 1378 | &dash-ent-10; |
| 1349 | <entry>-</entry> | ||
| 1350 | <entry>-</entry> | ||
| 1351 | <entry>-</entry> | ||
| 1352 | <entry>-</entry> | ||
| 1353 | <entry>-</entry> | ||
| 1354 | <entry>-</entry> | ||
| 1355 | <entry>-</entry> | ||
| 1356 | <entry>-</entry> | ||
| 1357 | <entry>-</entry> | 1379 | <entry>-</entry> |
| 1358 | <entry>-</entry> | 1380 | <entry>-</entry> |
| 1359 | <entry>y<subscript>7</subscript></entry> | 1381 | <entry>y<subscript>7</subscript></entry> |
| @@ -1369,16 +1391,8 @@ | |||
| 1369 | <entry></entry> | 1391 | <entry></entry> |
| 1370 | <entry></entry> | 1392 | <entry></entry> |
| 1371 | <entry></entry> | 1393 | <entry></entry> |
| 1372 | <entry>-</entry> | 1394 | &dash-ent-10; |
| 1373 | <entry>-</entry> | 1395 | &dash-ent-10; |
| 1374 | <entry>-</entry> | ||
| 1375 | <entry>-</entry> | ||
| 1376 | <entry>-</entry> | ||
| 1377 | <entry>-</entry> | ||
| 1378 | <entry>-</entry> | ||
| 1379 | <entry>-</entry> | ||
| 1380 | <entry>-</entry> | ||
| 1381 | <entry>-</entry> | ||
| 1382 | <entry>-</entry> | 1396 | <entry>-</entry> |
| 1383 | <entry>-</entry> | 1397 | <entry>-</entry> |
| 1384 | <entry>y<subscript>7</subscript></entry> | 1398 | <entry>y<subscript>7</subscript></entry> |
| @@ -1394,16 +1408,8 @@ | |||
| 1394 | <entry></entry> | 1408 | <entry></entry> |
| 1395 | <entry></entry> | 1409 | <entry></entry> |
| 1396 | <entry></entry> | 1410 | <entry></entry> |
| 1397 | <entry>-</entry> | 1411 | &dash-ent-10; |
| 1398 | <entry>-</entry> | 1412 | &dash-ent-10; |
| 1399 | <entry>-</entry> | ||
| 1400 | <entry>-</entry> | ||
| 1401 | <entry>-</entry> | ||
| 1402 | <entry>-</entry> | ||
| 1403 | <entry>-</entry> | ||
| 1404 | <entry>-</entry> | ||
| 1405 | <entry>-</entry> | ||
| 1406 | <entry>-</entry> | ||
| 1407 | <entry>-</entry> | 1413 | <entry>-</entry> |
| 1408 | <entry>-</entry> | 1414 | <entry>-</entry> |
| 1409 | <entry>v<subscript>7</subscript></entry> | 1415 | <entry>v<subscript>7</subscript></entry> |
| @@ -1419,16 +1425,8 @@ | |||
| 1419 | <entry>V4L2_MBUS_FMT_YVYU8_1_5X8</entry> | 1425 | <entry>V4L2_MBUS_FMT_YVYU8_1_5X8</entry> |
| 1420 | <entry>0x2005</entry> | 1426 | <entry>0x2005</entry> |
| 1421 | <entry></entry> | 1427 | <entry></entry> |
| 1422 | <entry>-</entry> | 1428 | &dash-ent-10; |
| 1423 | <entry>-</entry> | 1429 | &dash-ent-10; |
| 1424 | <entry>-</entry> | ||
| 1425 | <entry>-</entry> | ||
| 1426 | <entry>-</entry> | ||
| 1427 | <entry>-</entry> | ||
| 1428 | <entry>-</entry> | ||
| 1429 | <entry>-</entry> | ||
| 1430 | <entry>-</entry> | ||
| 1431 | <entry>-</entry> | ||
| 1432 | <entry>-</entry> | 1430 | <entry>-</entry> |
| 1433 | <entry>-</entry> | 1431 | <entry>-</entry> |
| 1434 | <entry>y<subscript>7</subscript></entry> | 1432 | <entry>y<subscript>7</subscript></entry> |
| @@ -1444,16 +1442,8 @@ | |||
| 1444 | <entry></entry> | 1442 | <entry></entry> |
| 1445 | <entry></entry> | 1443 | <entry></entry> |
| 1446 | <entry></entry> | 1444 | <entry></entry> |
| 1447 | <entry>-</entry> | 1445 | &dash-ent-10; |
| 1448 | <entry>-</entry> | 1446 | &dash-ent-10; |
| 1449 | <entry>-</entry> | ||
| 1450 | <entry>-</entry> | ||
| 1451 | <entry>-</entry> | ||
| 1452 | <entry>-</entry> | ||
| 1453 | <entry>-</entry> | ||
| 1454 | <entry>-</entry> | ||
| 1455 | <entry>-</entry> | ||
| 1456 | <entry>-</entry> | ||
| 1457 | <entry>-</entry> | 1447 | <entry>-</entry> |
| 1458 | <entry>-</entry> | 1448 | <entry>-</entry> |
| 1459 | <entry>y<subscript>7</subscript></entry> | 1449 | <entry>y<subscript>7</subscript></entry> |
| @@ -1469,16 +1459,8 @@ | |||
| 1469 | <entry></entry> | 1459 | <entry></entry> |
| 1470 | <entry></entry> | 1460 | <entry></entry> |
| 1471 | <entry></entry> | 1461 | <entry></entry> |
| 1472 | <entry>-</entry> | 1462 | &dash-ent-10; |
| 1473 | <entry>-</entry> | 1463 | &dash-ent-10; |
| 1474 | <entry>-</entry> | ||
| 1475 | <entry>-</entry> | ||
| 1476 | <entry>-</entry> | ||
| 1477 | <entry>-</entry> | ||
| 1478 | <entry>-</entry> | ||
| 1479 | <entry>-</entry> | ||
| 1480 | <entry>-</entry> | ||
| 1481 | <entry>-</entry> | ||
| 1482 | <entry>-</entry> | 1464 | <entry>-</entry> |
| 1483 | <entry>-</entry> | 1465 | <entry>-</entry> |
| 1484 | <entry>v<subscript>7</subscript></entry> | 1466 | <entry>v<subscript>7</subscript></entry> |
| @@ -1494,16 +1476,8 @@ | |||
| 1494 | <entry></entry> | 1476 | <entry></entry> |
| 1495 | <entry></entry> | 1477 | <entry></entry> |
| 1496 | <entry></entry> | 1478 | <entry></entry> |
| 1497 | <entry>-</entry> | 1479 | &dash-ent-10; |
| 1498 | <entry>-</entry> | 1480 | &dash-ent-10; |
| 1499 | <entry>-</entry> | ||
| 1500 | <entry>-</entry> | ||
| 1501 | <entry>-</entry> | ||
| 1502 | <entry>-</entry> | ||
| 1503 | <entry>-</entry> | ||
| 1504 | <entry>-</entry> | ||
| 1505 | <entry>-</entry> | ||
| 1506 | <entry>-</entry> | ||
| 1507 | <entry>-</entry> | 1481 | <entry>-</entry> |
| 1508 | <entry>-</entry> | 1482 | <entry>-</entry> |
| 1509 | <entry>y<subscript>7</subscript></entry> | 1483 | <entry>y<subscript>7</subscript></entry> |
| @@ -1519,16 +1493,8 @@ | |||
| 1519 | <entry></entry> | 1493 | <entry></entry> |
| 1520 | <entry></entry> | 1494 | <entry></entry> |
| 1521 | <entry></entry> | 1495 | <entry></entry> |
| 1522 | <entry>-</entry> | 1496 | &dash-ent-10; |
| 1523 | <entry>-</entry> | 1497 | &dash-ent-10; |
| 1524 | <entry>-</entry> | ||
| 1525 | <entry>-</entry> | ||
| 1526 | <entry>-</entry> | ||
| 1527 | <entry>-</entry> | ||
| 1528 | <entry>-</entry> | ||
| 1529 | <entry>-</entry> | ||
| 1530 | <entry>-</entry> | ||
| 1531 | <entry>-</entry> | ||
| 1532 | <entry>-</entry> | 1498 | <entry>-</entry> |
| 1533 | <entry>-</entry> | 1499 | <entry>-</entry> |
| 1534 | <entry>y<subscript>7</subscript></entry> | 1500 | <entry>y<subscript>7</subscript></entry> |
| @@ -1544,16 +1510,8 @@ | |||
| 1544 | <entry></entry> | 1510 | <entry></entry> |
| 1545 | <entry></entry> | 1511 | <entry></entry> |
| 1546 | <entry></entry> | 1512 | <entry></entry> |
| 1547 | <entry>-</entry> | 1513 | &dash-ent-10; |
| 1548 | <entry>-</entry> | 1514 | &dash-ent-10; |
| 1549 | <entry>-</entry> | ||
| 1550 | <entry>-</entry> | ||
| 1551 | <entry>-</entry> | ||
| 1552 | <entry>-</entry> | ||
| 1553 | <entry>-</entry> | ||
| 1554 | <entry>-</entry> | ||
| 1555 | <entry>-</entry> | ||
| 1556 | <entry>-</entry> | ||
| 1557 | <entry>-</entry> | 1515 | <entry>-</entry> |
| 1558 | <entry>-</entry> | 1516 | <entry>-</entry> |
| 1559 | <entry>u<subscript>7</subscript></entry> | 1517 | <entry>u<subscript>7</subscript></entry> |
| @@ -1569,16 +1527,8 @@ | |||
| 1569 | <entry>V4L2_MBUS_FMT_UYVY8_2X8</entry> | 1527 | <entry>V4L2_MBUS_FMT_UYVY8_2X8</entry> |
| 1570 | <entry>0x2006</entry> | 1528 | <entry>0x2006</entry> |
| 1571 | <entry></entry> | 1529 | <entry></entry> |
| 1572 | <entry>-</entry> | 1530 | &dash-ent-10; |
| 1573 | <entry>-</entry> | 1531 | &dash-ent-10; |
| 1574 | <entry>-</entry> | ||
| 1575 | <entry>-</entry> | ||
| 1576 | <entry>-</entry> | ||
| 1577 | <entry>-</entry> | ||
| 1578 | <entry>-</entry> | ||
| 1579 | <entry>-</entry> | ||
| 1580 | <entry>-</entry> | ||
| 1581 | <entry>-</entry> | ||
| 1582 | <entry>-</entry> | 1532 | <entry>-</entry> |
| 1583 | <entry>-</entry> | 1533 | <entry>-</entry> |
| 1584 | <entry>u<subscript>7</subscript></entry> | 1534 | <entry>u<subscript>7</subscript></entry> |
| @@ -1594,16 +1544,8 @@ | |||
| 1594 | <entry></entry> | 1544 | <entry></entry> |
| 1595 | <entry></entry> | 1545 | <entry></entry> |
| 1596 | <entry></entry> | 1546 | <entry></entry> |
| 1597 | <entry>-</entry> | 1547 | &dash-ent-10; |
| 1598 | <entry>-</entry> | 1548 | &dash-ent-10; |
| 1599 | <entry>-</entry> | ||
| 1600 | <entry>-</entry> | ||
| 1601 | <entry>-</entry> | ||
| 1602 | <entry>-</entry> | ||
| 1603 | <entry>-</entry> | ||
| 1604 | <entry>-</entry> | ||
| 1605 | <entry>-</entry> | ||
| 1606 | <entry>-</entry> | ||
| 1607 | <entry>-</entry> | 1549 | <entry>-</entry> |
| 1608 | <entry>-</entry> | 1550 | <entry>-</entry> |
| 1609 | <entry>y<subscript>7</subscript></entry> | 1551 | <entry>y<subscript>7</subscript></entry> |
| @@ -1619,16 +1561,8 @@ | |||
| 1619 | <entry></entry> | 1561 | <entry></entry> |
| 1620 | <entry></entry> | 1562 | <entry></entry> |
| 1621 | <entry></entry> | 1563 | <entry></entry> |
| 1622 | <entry>-</entry> | 1564 | &dash-ent-10; |
| 1623 | <entry>-</entry> | 1565 | &dash-ent-10; |
| 1624 | <entry>-</entry> | ||
| 1625 | <entry>-</entry> | ||
| 1626 | <entry>-</entry> | ||
| 1627 | <entry>-</entry> | ||
| 1628 | <entry>-</entry> | ||
| 1629 | <entry>-</entry> | ||
| 1630 | <entry>-</entry> | ||
| 1631 | <entry>-</entry> | ||
| 1632 | <entry>-</entry> | 1566 | <entry>-</entry> |
| 1633 | <entry>-</entry> | 1567 | <entry>-</entry> |
| 1634 | <entry>v<subscript>7</subscript></entry> | 1568 | <entry>v<subscript>7</subscript></entry> |
| @@ -1644,16 +1578,8 @@ | |||
| 1644 | <entry></entry> | 1578 | <entry></entry> |
| 1645 | <entry></entry> | 1579 | <entry></entry> |
| 1646 | <entry></entry> | 1580 | <entry></entry> |
| 1647 | <entry>-</entry> | 1581 | &dash-ent-10; |
| 1648 | <entry>-</entry> | 1582 | &dash-ent-10; |
| 1649 | <entry>-</entry> | ||
| 1650 | <entry>-</entry> | ||
| 1651 | <entry>-</entry> | ||
| 1652 | <entry>-</entry> | ||
| 1653 | <entry>-</entry> | ||
| 1654 | <entry>-</entry> | ||
| 1655 | <entry>-</entry> | ||
| 1656 | <entry>-</entry> | ||
| 1657 | <entry>-</entry> | 1583 | <entry>-</entry> |
| 1658 | <entry>-</entry> | 1584 | <entry>-</entry> |
| 1659 | <entry>y<subscript>7</subscript></entry> | 1585 | <entry>y<subscript>7</subscript></entry> |
| @@ -1669,16 +1595,8 @@ | |||
| 1669 | <entry>V4L2_MBUS_FMT_VYUY8_2X8</entry> | 1595 | <entry>V4L2_MBUS_FMT_VYUY8_2X8</entry> |
| 1670 | <entry>0x2007</entry> | 1596 | <entry>0x2007</entry> |
| 1671 | <entry></entry> | 1597 | <entry></entry> |
| 1672 | <entry>-</entry> | 1598 | &dash-ent-10; |
| 1673 | <entry>-</entry> | 1599 | &dash-ent-10; |
| 1674 | <entry>-</entry> | ||
| 1675 | <entry>-</entry> | ||
| 1676 | <entry>-</entry> | ||
| 1677 | <entry>-</entry> | ||
| 1678 | <entry>-</entry> | ||
| 1679 | <entry>-</entry> | ||
| 1680 | <entry>-</entry> | ||
| 1681 | <entry>-</entry> | ||
| 1682 | <entry>-</entry> | 1600 | <entry>-</entry> |
| 1683 | <entry>-</entry> | 1601 | <entry>-</entry> |
| 1684 | <entry>v<subscript>7</subscript></entry> | 1602 | <entry>v<subscript>7</subscript></entry> |
| @@ -1694,16 +1612,8 @@ | |||
| 1694 | <entry></entry> | 1612 | <entry></entry> |
| 1695 | <entry></entry> | 1613 | <entry></entry> |
| 1696 | <entry></entry> | 1614 | <entry></entry> |
| 1697 | <entry>-</entry> | 1615 | &dash-ent-10; |
| 1698 | <entry>-</entry> | 1616 | &dash-ent-10; |
| 1699 | <entry>-</entry> | ||
| 1700 | <entry>-</entry> | ||
| 1701 | <entry>-</entry> | ||
| 1702 | <entry>-</entry> | ||
| 1703 | <entry>-</entry> | ||
| 1704 | <entry>-</entry> | ||
| 1705 | <entry>-</entry> | ||
| 1706 | <entry>-</entry> | ||
| 1707 | <entry>-</entry> | 1617 | <entry>-</entry> |
| 1708 | <entry>-</entry> | 1618 | <entry>-</entry> |
| 1709 | <entry>y<subscript>7</subscript></entry> | 1619 | <entry>y<subscript>7</subscript></entry> |
| @@ -1719,16 +1629,8 @@ | |||
| 1719 | <entry></entry> | 1629 | <entry></entry> |
| 1720 | <entry></entry> | 1630 | <entry></entry> |
| 1721 | <entry></entry> | 1631 | <entry></entry> |
| 1722 | <entry>-</entry> | 1632 | &dash-ent-10; |
| 1723 | <entry>-</entry> | 1633 | &dash-ent-10; |
| 1724 | <entry>-</entry> | ||
| 1725 | <entry>-</entry> | ||
| 1726 | <entry>-</entry> | ||
| 1727 | <entry>-</entry> | ||
| 1728 | <entry>-</entry> | ||
| 1729 | <entry>-</entry> | ||
| 1730 | <entry>-</entry> | ||
| 1731 | <entry>-</entry> | ||
| 1732 | <entry>-</entry> | 1634 | <entry>-</entry> |
| 1733 | <entry>-</entry> | 1635 | <entry>-</entry> |
| 1734 | <entry>u<subscript>7</subscript></entry> | 1636 | <entry>u<subscript>7</subscript></entry> |
| @@ -1744,16 +1646,8 @@ | |||
| 1744 | <entry></entry> | 1646 | <entry></entry> |
| 1745 | <entry></entry> | 1647 | <entry></entry> |
| 1746 | <entry></entry> | 1648 | <entry></entry> |
| 1747 | <entry>-</entry> | 1649 | &dash-ent-10; |
| 1748 | <entry>-</entry> | 1650 | &dash-ent-10; |
| 1749 | <entry>-</entry> | ||
| 1750 | <entry>-</entry> | ||
| 1751 | <entry>-</entry> | ||
| 1752 | <entry>-</entry> | ||
| 1753 | <entry>-</entry> | ||
| 1754 | <entry>-</entry> | ||
| 1755 | <entry>-</entry> | ||
| 1756 | <entry>-</entry> | ||
| 1757 | <entry>-</entry> | 1651 | <entry>-</entry> |
| 1758 | <entry>-</entry> | 1652 | <entry>-</entry> |
| 1759 | <entry>y<subscript>7</subscript></entry> | 1653 | <entry>y<subscript>7</subscript></entry> |
| @@ -1769,16 +1663,8 @@ | |||
| 1769 | <entry>V4L2_MBUS_FMT_YUYV8_2X8</entry> | 1663 | <entry>V4L2_MBUS_FMT_YUYV8_2X8</entry> |
| 1770 | <entry>0x2008</entry> | 1664 | <entry>0x2008</entry> |
| 1771 | <entry></entry> | 1665 | <entry></entry> |
| 1772 | <entry>-</entry> | 1666 | &dash-ent-10; |
| 1773 | <entry>-</entry> | 1667 | &dash-ent-10; |
| 1774 | <entry>-</entry> | ||
| 1775 | <entry>-</entry> | ||
| 1776 | <entry>-</entry> | ||
| 1777 | <entry>-</entry> | ||
| 1778 | <entry>-</entry> | ||
| 1779 | <entry>-</entry> | ||
| 1780 | <entry>-</entry> | ||
| 1781 | <entry>-</entry> | ||
| 1782 | <entry>-</entry> | 1668 | <entry>-</entry> |
| 1783 | <entry>-</entry> | 1669 | <entry>-</entry> |
| 1784 | <entry>y<subscript>7</subscript></entry> | 1670 | <entry>y<subscript>7</subscript></entry> |
| @@ -1794,16 +1680,8 @@ | |||
| 1794 | <entry></entry> | 1680 | <entry></entry> |
| 1795 | <entry></entry> | 1681 | <entry></entry> |
| 1796 | <entry></entry> | 1682 | <entry></entry> |
| 1797 | <entry>-</entry> | 1683 | &dash-ent-10; |
| 1798 | <entry>-</entry> | 1684 | &dash-ent-10; |
| 1799 | <entry>-</entry> | ||
| 1800 | <entry>-</entry> | ||
| 1801 | <entry>-</entry> | ||
| 1802 | <entry>-</entry> | ||
| 1803 | <entry>-</entry> | ||
| 1804 | <entry>-</entry> | ||
| 1805 | <entry>-</entry> | ||
| 1806 | <entry>-</entry> | ||
| 1807 | <entry>-</entry> | 1685 | <entry>-</entry> |
| 1808 | <entry>-</entry> | 1686 | <entry>-</entry> |
| 1809 | <entry>u<subscript>7</subscript></entry> | 1687 | <entry>u<subscript>7</subscript></entry> |
| @@ -1819,16 +1697,8 @@ | |||
| 1819 | <entry></entry> | 1697 | <entry></entry> |
| 1820 | <entry></entry> | 1698 | <entry></entry> |
| 1821 | <entry></entry> | 1699 | <entry></entry> |
| 1822 | <entry>-</entry> | 1700 | &dash-ent-10; |
| 1823 | <entry>-</entry> | 1701 | &dash-ent-10; |
| 1824 | <entry>-</entry> | ||
| 1825 | <entry>-</entry> | ||
| 1826 | <entry>-</entry> | ||
| 1827 | <entry>-</entry> | ||
| 1828 | <entry>-</entry> | ||
| 1829 | <entry>-</entry> | ||
| 1830 | <entry>-</entry> | ||
| 1831 | <entry>-</entry> | ||
| 1832 | <entry>-</entry> | 1702 | <entry>-</entry> |
| 1833 | <entry>-</entry> | 1703 | <entry>-</entry> |
| 1834 | <entry>y<subscript>7</subscript></entry> | 1704 | <entry>y<subscript>7</subscript></entry> |
| @@ -1844,16 +1714,8 @@ | |||
| 1844 | <entry></entry> | 1714 | <entry></entry> |
| 1845 | <entry></entry> | 1715 | <entry></entry> |
| 1846 | <entry></entry> | 1716 | <entry></entry> |
| 1847 | <entry>-</entry> | 1717 | &dash-ent-10; |
| 1848 | <entry>-</entry> | 1718 | &dash-ent-10; |
| 1849 | <entry>-</entry> | ||
| 1850 | <entry>-</entry> | ||
| 1851 | <entry>-</entry> | ||
| 1852 | <entry>-</entry> | ||
| 1853 | <entry>-</entry> | ||
| 1854 | <entry>-</entry> | ||
| 1855 | <entry>-</entry> | ||
| 1856 | <entry>-</entry> | ||
| 1857 | <entry>-</entry> | 1719 | <entry>-</entry> |
| 1858 | <entry>-</entry> | 1720 | <entry>-</entry> |
| 1859 | <entry>v<subscript>7</subscript></entry> | 1721 | <entry>v<subscript>7</subscript></entry> |
| @@ -1869,16 +1731,8 @@ | |||
| 1869 | <entry>V4L2_MBUS_FMT_YVYU8_2X8</entry> | 1731 | <entry>V4L2_MBUS_FMT_YVYU8_2X8</entry> |
| 1870 | <entry>0x2009</entry> | 1732 | <entry>0x2009</entry> |
| 1871 | <entry></entry> | 1733 | <entry></entry> |
| 1872 | <entry>-</entry> | 1734 | &dash-ent-10; |
| 1873 | <entry>-</entry> | 1735 | &dash-ent-10; |
| 1874 | <entry>-</entry> | ||
| 1875 | <entry>-</entry> | ||
| 1876 | <entry>-</entry> | ||
| 1877 | <entry>-</entry> | ||
| 1878 | <entry>-</entry> | ||
| 1879 | <entry>-</entry> | ||
| 1880 | <entry>-</entry> | ||
| 1881 | <entry>-</entry> | ||
| 1882 | <entry>-</entry> | 1736 | <entry>-</entry> |
| 1883 | <entry>-</entry> | 1737 | <entry>-</entry> |
| 1884 | <entry>y<subscript>7</subscript></entry> | 1738 | <entry>y<subscript>7</subscript></entry> |
| @@ -1894,16 +1748,8 @@ | |||
| 1894 | <entry></entry> | 1748 | <entry></entry> |
| 1895 | <entry></entry> | 1749 | <entry></entry> |
| 1896 | <entry></entry> | 1750 | <entry></entry> |
| 1897 | <entry>-</entry> | 1751 | &dash-ent-10; |
| 1898 | <entry>-</entry> | 1752 | &dash-ent-10; |
| 1899 | <entry>-</entry> | ||
| 1900 | <entry>-</entry> | ||
| 1901 | <entry>-</entry> | ||
| 1902 | <entry>-</entry> | ||
| 1903 | <entry>-</entry> | ||
| 1904 | <entry>-</entry> | ||
| 1905 | <entry>-</entry> | ||
| 1906 | <entry>-</entry> | ||
| 1907 | <entry>-</entry> | 1753 | <entry>-</entry> |
| 1908 | <entry>-</entry> | 1754 | <entry>-</entry> |
| 1909 | <entry>v<subscript>7</subscript></entry> | 1755 | <entry>v<subscript>7</subscript></entry> |
| @@ -1919,16 +1765,8 @@ | |||
| 1919 | <entry></entry> | 1765 | <entry></entry> |
| 1920 | <entry></entry> | 1766 | <entry></entry> |
| 1921 | <entry></entry> | 1767 | <entry></entry> |
| 1922 | <entry>-</entry> | 1768 | &dash-ent-10; |
| 1923 | <entry>-</entry> | 1769 | &dash-ent-10; |
| 1924 | <entry>-</entry> | ||
| 1925 | <entry>-</entry> | ||
| 1926 | <entry>-</entry> | ||
| 1927 | <entry>-</entry> | ||
| 1928 | <entry>-</entry> | ||
| 1929 | <entry>-</entry> | ||
| 1930 | <entry>-</entry> | ||
| 1931 | <entry>-</entry> | ||
| 1932 | <entry>-</entry> | 1770 | <entry>-</entry> |
| 1933 | <entry>-</entry> | 1771 | <entry>-</entry> |
| 1934 | <entry>y<subscript>7</subscript></entry> | 1772 | <entry>y<subscript>7</subscript></entry> |
| @@ -1944,16 +1782,8 @@ | |||
| 1944 | <entry></entry> | 1782 | <entry></entry> |
| 1945 | <entry></entry> | 1783 | <entry></entry> |
| 1946 | <entry></entry> | 1784 | <entry></entry> |
| 1947 | <entry>-</entry> | 1785 | &dash-ent-10; |
| 1948 | <entry>-</entry> | 1786 | &dash-ent-10; |
| 1949 | <entry>-</entry> | ||
| 1950 | <entry>-</entry> | ||
| 1951 | <entry>-</entry> | ||
| 1952 | <entry>-</entry> | ||
| 1953 | <entry>-</entry> | ||
| 1954 | <entry>-</entry> | ||
| 1955 | <entry>-</entry> | ||
| 1956 | <entry>-</entry> | ||
| 1957 | <entry>-</entry> | 1787 | <entry>-</entry> |
| 1958 | <entry>-</entry> | 1788 | <entry>-</entry> |
| 1959 | <entry>u<subscript>7</subscript></entry> | 1789 | <entry>u<subscript>7</subscript></entry> |
| @@ -1969,16 +1799,8 @@ | |||
| 1969 | <entry>V4L2_MBUS_FMT_Y10_1X10</entry> | 1799 | <entry>V4L2_MBUS_FMT_Y10_1X10</entry> |
| 1970 | <entry>0x200a</entry> | 1800 | <entry>0x200a</entry> |
| 1971 | <entry></entry> | 1801 | <entry></entry> |
| 1972 | <entry>-</entry> | 1802 | &dash-ent-10; |
| 1973 | <entry>-</entry> | 1803 | &dash-ent-10; |
| 1974 | <entry>-</entry> | ||
| 1975 | <entry>-</entry> | ||
| 1976 | <entry>-</entry> | ||
| 1977 | <entry>-</entry> | ||
| 1978 | <entry>-</entry> | ||
| 1979 | <entry>-</entry> | ||
| 1980 | <entry>-</entry> | ||
| 1981 | <entry>-</entry> | ||
| 1982 | <entry>y<subscript>9</subscript></entry> | 1804 | <entry>y<subscript>9</subscript></entry> |
| 1983 | <entry>y<subscript>8</subscript></entry> | 1805 | <entry>y<subscript>8</subscript></entry> |
| 1984 | <entry>y<subscript>7</subscript></entry> | 1806 | <entry>y<subscript>7</subscript></entry> |
| @@ -1994,16 +1816,8 @@ | |||
| 1994 | <entry>V4L2_MBUS_FMT_YUYV10_2X10</entry> | 1816 | <entry>V4L2_MBUS_FMT_YUYV10_2X10</entry> |
| 1995 | <entry>0x200b</entry> | 1817 | <entry>0x200b</entry> |
| 1996 | <entry></entry> | 1818 | <entry></entry> |
| 1997 | <entry>-</entry> | 1819 | &dash-ent-10; |
| 1998 | <entry>-</entry> | 1820 | &dash-ent-10; |
| 1999 | <entry>-</entry> | ||
| 2000 | <entry>-</entry> | ||
| 2001 | <entry>-</entry> | ||
| 2002 | <entry>-</entry> | ||
| 2003 | <entry>-</entry> | ||
| 2004 | <entry>-</entry> | ||
| 2005 | <entry>-</entry> | ||
| 2006 | <entry>-</entry> | ||
| 2007 | <entry>y<subscript>9</subscript></entry> | 1821 | <entry>y<subscript>9</subscript></entry> |
| 2008 | <entry>y<subscript>8</subscript></entry> | 1822 | <entry>y<subscript>8</subscript></entry> |
| 2009 | <entry>y<subscript>7</subscript></entry> | 1823 | <entry>y<subscript>7</subscript></entry> |
| @@ -2019,16 +1833,8 @@ | |||
| 2019 | <entry></entry> | 1833 | <entry></entry> |
| 2020 | <entry></entry> | 1834 | <entry></entry> |
| 2021 | <entry></entry> | 1835 | <entry></entry> |
| 2022 | <entry>-</entry> | 1836 | &dash-ent-10; |
| 2023 | <entry>-</entry> | 1837 | &dash-ent-10; |
| 2024 | <entry>-</entry> | ||
| 2025 | <entry>-</entry> | ||
| 2026 | <entry>-</entry> | ||
| 2027 | <entry>-</entry> | ||
| 2028 | <entry>-</entry> | ||
| 2029 | <entry>-</entry> | ||
| 2030 | <entry>-</entry> | ||
| 2031 | <entry>-</entry> | ||
| 2032 | <entry>u<subscript>9</subscript></entry> | 1838 | <entry>u<subscript>9</subscript></entry> |
| 2033 | <entry>u<subscript>8</subscript></entry> | 1839 | <entry>u<subscript>8</subscript></entry> |
| 2034 | <entry>u<subscript>7</subscript></entry> | 1840 | <entry>u<subscript>7</subscript></entry> |
| @@ -2044,16 +1850,8 @@ | |||
| 2044 | <entry></entry> | 1850 | <entry></entry> |
| 2045 | <entry></entry> | 1851 | <entry></entry> |
| 2046 | <entry></entry> | 1852 | <entry></entry> |
| 2047 | <entry>-</entry> | 1853 | &dash-ent-10; |
| 2048 | <entry>-</entry> | 1854 | &dash-ent-10; |
| 2049 | <entry>-</entry> | ||
| 2050 | <entry>-</entry> | ||
| 2051 | <entry>-</entry> | ||
| 2052 | <entry>-</entry> | ||
| 2053 | <entry>-</entry> | ||
| 2054 | <entry>-</entry> | ||
| 2055 | <entry>-</entry> | ||
| 2056 | <entry>-</entry> | ||
| 2057 | <entry>y<subscript>9</subscript></entry> | 1855 | <entry>y<subscript>9</subscript></entry> |
| 2058 | <entry>y<subscript>8</subscript></entry> | 1856 | <entry>y<subscript>8</subscript></entry> |
| 2059 | <entry>y<subscript>7</subscript></entry> | 1857 | <entry>y<subscript>7</subscript></entry> |
| @@ -2069,16 +1867,8 @@ | |||
| 2069 | <entry></entry> | 1867 | <entry></entry> |
| 2070 | <entry></entry> | 1868 | <entry></entry> |
| 2071 | <entry></entry> | 1869 | <entry></entry> |
| 2072 | <entry>-</entry> | 1870 | &dash-ent-10; |
| 2073 | <entry>-</entry> | 1871 | &dash-ent-10; |
| 2074 | <entry>-</entry> | ||
| 2075 | <entry>-</entry> | ||
| 2076 | <entry>-</entry> | ||
| 2077 | <entry>-</entry> | ||
| 2078 | <entry>-</entry> | ||
| 2079 | <entry>-</entry> | ||
| 2080 | <entry>-</entry> | ||
| 2081 | <entry>-</entry> | ||
| 2082 | <entry>v<subscript>9</subscript></entry> | 1872 | <entry>v<subscript>9</subscript></entry> |
| 2083 | <entry>v<subscript>8</subscript></entry> | 1873 | <entry>v<subscript>8</subscript></entry> |
| 2084 | <entry>v<subscript>7</subscript></entry> | 1874 | <entry>v<subscript>7</subscript></entry> |
| @@ -2094,16 +1884,8 @@ | |||
| 2094 | <entry>V4L2_MBUS_FMT_YVYU10_2X10</entry> | 1884 | <entry>V4L2_MBUS_FMT_YVYU10_2X10</entry> |
| 2095 | <entry>0x200c</entry> | 1885 | <entry>0x200c</entry> |
| 2096 | <entry></entry> | 1886 | <entry></entry> |
| 2097 | <entry>-</entry> | 1887 | &dash-ent-10; |
| 2098 | <entry>-</entry> | 1888 | &dash-ent-10; |
| 2099 | <entry>-</entry> | ||
| 2100 | <entry>-</entry> | ||
| 2101 | <entry>-</entry> | ||
| 2102 | <entry>-</entry> | ||
| 2103 | <entry>-</entry> | ||
| 2104 | <entry>-</entry> | ||
| 2105 | <entry>-</entry> | ||
| 2106 | <entry>-</entry> | ||
| 2107 | <entry>y<subscript>9</subscript></entry> | 1889 | <entry>y<subscript>9</subscript></entry> |
| 2108 | <entry>y<subscript>8</subscript></entry> | 1890 | <entry>y<subscript>8</subscript></entry> |
| 2109 | <entry>y<subscript>7</subscript></entry> | 1891 | <entry>y<subscript>7</subscript></entry> |
| @@ -2119,16 +1901,8 @@ | |||
| 2119 | <entry></entry> | 1901 | <entry></entry> |
| 2120 | <entry></entry> | 1902 | <entry></entry> |
| 2121 | <entry></entry> | 1903 | <entry></entry> |
| 2122 | <entry>-</entry> | 1904 | &dash-ent-10; |
| 2123 | <entry>-</entry> | 1905 | &dash-ent-10; |
| 2124 | <entry>-</entry> | ||
| 2125 | <entry>-</entry> | ||
| 2126 | <entry>-</entry> | ||
| 2127 | <entry>-</entry> | ||
| 2128 | <entry>-</entry> | ||
| 2129 | <entry>-</entry> | ||
| 2130 | <entry>-</entry> | ||
| 2131 | <entry>-</entry> | ||
| 2132 | <entry>v<subscript>9</subscript></entry> | 1906 | <entry>v<subscript>9</subscript></entry> |
| 2133 | <entry>v<subscript>8</subscript></entry> | 1907 | <entry>v<subscript>8</subscript></entry> |
| 2134 | <entry>v<subscript>7</subscript></entry> | 1908 | <entry>v<subscript>7</subscript></entry> |
| @@ -2144,16 +1918,8 @@ | |||
| 2144 | <entry></entry> | 1918 | <entry></entry> |
| 2145 | <entry></entry> | 1919 | <entry></entry> |
| 2146 | <entry></entry> | 1920 | <entry></entry> |
| 2147 | <entry>-</entry> | 1921 | &dash-ent-10; |
| 2148 | <entry>-</entry> | 1922 | &dash-ent-10; |
| 2149 | <entry>-</entry> | ||
| 2150 | <entry>-</entry> | ||
| 2151 | <entry>-</entry> | ||
| 2152 | <entry>-</entry> | ||
| 2153 | <entry>-</entry> | ||
| 2154 | <entry>-</entry> | ||
| 2155 | <entry>-</entry> | ||
| 2156 | <entry>-</entry> | ||
| 2157 | <entry>y<subscript>9</subscript></entry> | 1923 | <entry>y<subscript>9</subscript></entry> |
| 2158 | <entry>y<subscript>8</subscript></entry> | 1924 | <entry>y<subscript>8</subscript></entry> |
| 2159 | <entry>y<subscript>7</subscript></entry> | 1925 | <entry>y<subscript>7</subscript></entry> |
| @@ -2169,16 +1935,8 @@ | |||
| 2169 | <entry></entry> | 1935 | <entry></entry> |
| 2170 | <entry></entry> | 1936 | <entry></entry> |
| 2171 | <entry></entry> | 1937 | <entry></entry> |
| 2172 | <entry>-</entry> | 1938 | &dash-ent-10; |
| 2173 | <entry>-</entry> | 1939 | &dash-ent-10; |
| 2174 | <entry>-</entry> | ||
| 2175 | <entry>-</entry> | ||
| 2176 | <entry>-</entry> | ||
| 2177 | <entry>-</entry> | ||
| 2178 | <entry>-</entry> | ||
| 2179 | <entry>-</entry> | ||
| 2180 | <entry>-</entry> | ||
| 2181 | <entry>-</entry> | ||
| 2182 | <entry>u<subscript>9</subscript></entry> | 1940 | <entry>u<subscript>9</subscript></entry> |
| 2183 | <entry>u<subscript>8</subscript></entry> | 1941 | <entry>u<subscript>8</subscript></entry> |
| 2184 | <entry>u<subscript>7</subscript></entry> | 1942 | <entry>u<subscript>7</subscript></entry> |
| @@ -2194,6 +1952,7 @@ | |||
| 2194 | <entry>V4L2_MBUS_FMT_Y12_1X12</entry> | 1952 | <entry>V4L2_MBUS_FMT_Y12_1X12</entry> |
| 2195 | <entry>0x2013</entry> | 1953 | <entry>0x2013</entry> |
| 2196 | <entry></entry> | 1954 | <entry></entry> |
| 1955 | &dash-ent-10; | ||
| 2197 | <entry>-</entry> | 1956 | <entry>-</entry> |
| 2198 | <entry>-</entry> | 1957 | <entry>-</entry> |
| 2199 | <entry>-</entry> | 1958 | <entry>-</entry> |
| @@ -2219,6 +1978,7 @@ | |||
| 2219 | <entry>V4L2_MBUS_FMT_UYVY8_1X16</entry> | 1978 | <entry>V4L2_MBUS_FMT_UYVY8_1X16</entry> |
| 2220 | <entry>0x200f</entry> | 1979 | <entry>0x200f</entry> |
| 2221 | <entry></entry> | 1980 | <entry></entry> |
| 1981 | &dash-ent-10; | ||
| 2222 | <entry>-</entry> | 1982 | <entry>-</entry> |
| 2223 | <entry>-</entry> | 1983 | <entry>-</entry> |
| 2224 | <entry>-</entry> | 1984 | <entry>-</entry> |
| @@ -2244,6 +2004,7 @@ | |||
| 2244 | <entry></entry> | 2004 | <entry></entry> |
| 2245 | <entry></entry> | 2005 | <entry></entry> |
| 2246 | <entry></entry> | 2006 | <entry></entry> |
| 2007 | &dash-ent-10; | ||
| 2247 | <entry>-</entry> | 2008 | <entry>-</entry> |
| 2248 | <entry>-</entry> | 2009 | <entry>-</entry> |
| 2249 | <entry>-</entry> | 2010 | <entry>-</entry> |
| @@ -2269,6 +2030,7 @@ | |||
| 2269 | <entry>V4L2_MBUS_FMT_VYUY8_1X16</entry> | 2030 | <entry>V4L2_MBUS_FMT_VYUY8_1X16</entry> |
| 2270 | <entry>0x2010</entry> | 2031 | <entry>0x2010</entry> |
| 2271 | <entry></entry> | 2032 | <entry></entry> |
| 2033 | &dash-ent-10; | ||
| 2272 | <entry>-</entry> | 2034 | <entry>-</entry> |
| 2273 | <entry>-</entry> | 2035 | <entry>-</entry> |
| 2274 | <entry>-</entry> | 2036 | <entry>-</entry> |
| @@ -2294,6 +2056,7 @@ | |||
| 2294 | <entry></entry> | 2056 | <entry></entry> |
| 2295 | <entry></entry> | 2057 | <entry></entry> |
| 2296 | <entry></entry> | 2058 | <entry></entry> |
| 2059 | &dash-ent-10; | ||
| 2297 | <entry>-</entry> | 2060 | <entry>-</entry> |
| 2298 | <entry>-</entry> | 2061 | <entry>-</entry> |
| 2299 | <entry>-</entry> | 2062 | <entry>-</entry> |
| @@ -2319,6 +2082,7 @@ | |||
| 2319 | <entry>V4L2_MBUS_FMT_YUYV8_1X16</entry> | 2082 | <entry>V4L2_MBUS_FMT_YUYV8_1X16</entry> |
| 2320 | <entry>0x2011</entry> | 2083 | <entry>0x2011</entry> |
| 2321 | <entry></entry> | 2084 | <entry></entry> |
| 2085 | &dash-ent-10; | ||
| 2322 | <entry>-</entry> | 2086 | <entry>-</entry> |
| 2323 | <entry>-</entry> | 2087 | <entry>-</entry> |
| 2324 | <entry>-</entry> | 2088 | <entry>-</entry> |
| @@ -2344,6 +2108,7 @@ | |||
| 2344 | <entry></entry> | 2108 | <entry></entry> |
| 2345 | <entry></entry> | 2109 | <entry></entry> |
| 2346 | <entry></entry> | 2110 | <entry></entry> |
| 2111 | &dash-ent-10; | ||
| 2347 | <entry>-</entry> | 2112 | <entry>-</entry> |
| 2348 | <entry>-</entry> | 2113 | <entry>-</entry> |
| 2349 | <entry>-</entry> | 2114 | <entry>-</entry> |
| @@ -2369,6 +2134,7 @@ | |||
| 2369 | <entry>V4L2_MBUS_FMT_YVYU8_1X16</entry> | 2134 | <entry>V4L2_MBUS_FMT_YVYU8_1X16</entry> |
| 2370 | <entry>0x2012</entry> | 2135 | <entry>0x2012</entry> |
| 2371 | <entry></entry> | 2136 | <entry></entry> |
| 2137 | &dash-ent-10; | ||
| 2372 | <entry>-</entry> | 2138 | <entry>-</entry> |
| 2373 | <entry>-</entry> | 2139 | <entry>-</entry> |
| 2374 | <entry>-</entry> | 2140 | <entry>-</entry> |
| @@ -2394,6 +2160,57 @@ | |||
| 2394 | <entry></entry> | 2160 | <entry></entry> |
| 2395 | <entry></entry> | 2161 | <entry></entry> |
| 2396 | <entry></entry> | 2162 | <entry></entry> |
| 2163 | &dash-ent-10; | ||
| 2164 | <entry>-</entry> | ||
| 2165 | <entry>-</entry> | ||
| 2166 | <entry>-</entry> | ||
| 2167 | <entry>-</entry> | ||
| 2168 | <entry>y<subscript>7</subscript></entry> | ||
| 2169 | <entry>y<subscript>6</subscript></entry> | ||
| 2170 | <entry>y<subscript>5</subscript></entry> | ||
| 2171 | <entry>y<subscript>4</subscript></entry> | ||
| 2172 | <entry>y<subscript>3</subscript></entry> | ||
| 2173 | <entry>y<subscript>2</subscript></entry> | ||
| 2174 | <entry>y<subscript>1</subscript></entry> | ||
| 2175 | <entry>y<subscript>0</subscript></entry> | ||
| 2176 | <entry>u<subscript>7</subscript></entry> | ||
| 2177 | <entry>u<subscript>6</subscript></entry> | ||
| 2178 | <entry>u<subscript>5</subscript></entry> | ||
| 2179 | <entry>u<subscript>4</subscript></entry> | ||
| 2180 | <entry>u<subscript>3</subscript></entry> | ||
| 2181 | <entry>u<subscript>2</subscript></entry> | ||
| 2182 | <entry>u<subscript>1</subscript></entry> | ||
| 2183 | <entry>u<subscript>0</subscript></entry> | ||
| 2184 | </row> | ||
| 2185 | <row id="V4L2-MBUS-FMT-YDYUYDYV8-1X16"> | ||
| 2186 | <entry>V4L2_MBUS_FMT_YDYUYDYV8_1X16</entry> | ||
| 2187 | <entry>0x2014</entry> | ||
| 2188 | <entry></entry> | ||
| 2189 | <entry>-</entry> | ||
| 2190 | <entry>-</entry> | ||
| 2191 | <entry>-</entry> | ||
| 2192 | <entry>-</entry> | ||
| 2193 | <entry>y<subscript>7</subscript></entry> | ||
| 2194 | <entry>y<subscript>6</subscript></entry> | ||
| 2195 | <entry>y<subscript>5</subscript></entry> | ||
| 2196 | <entry>y<subscript>4</subscript></entry> | ||
| 2197 | <entry>y<subscript>3</subscript></entry> | ||
| 2198 | <entry>y<subscript>2</subscript></entry> | ||
| 2199 | <entry>y<subscript>1</subscript></entry> | ||
| 2200 | <entry>y<subscript>0</subscript></entry> | ||
| 2201 | <entry>d</entry> | ||
| 2202 | <entry>d</entry> | ||
| 2203 | <entry>d</entry> | ||
| 2204 | <entry>d</entry> | ||
| 2205 | <entry>d</entry> | ||
| 2206 | <entry>d</entry> | ||
| 2207 | <entry>d</entry> | ||
| 2208 | <entry>d</entry> | ||
| 2209 | </row> | ||
| 2210 | <row> | ||
| 2211 | <entry></entry> | ||
| 2212 | <entry></entry> | ||
| 2213 | <entry></entry> | ||
| 2397 | <entry>-</entry> | 2214 | <entry>-</entry> |
| 2398 | <entry>-</entry> | 2215 | <entry>-</entry> |
| 2399 | <entry>-</entry> | 2216 | <entry>-</entry> |
| @@ -2415,10 +2232,61 @@ | |||
| 2415 | <entry>u<subscript>1</subscript></entry> | 2232 | <entry>u<subscript>1</subscript></entry> |
| 2416 | <entry>u<subscript>0</subscript></entry> | 2233 | <entry>u<subscript>0</subscript></entry> |
| 2417 | </row> | 2234 | </row> |
| 2235 | <row> | ||
| 2236 | <entry></entry> | ||
| 2237 | <entry></entry> | ||
| 2238 | <entry></entry> | ||
| 2239 | <entry>-</entry> | ||
| 2240 | <entry>-</entry> | ||
| 2241 | <entry>-</entry> | ||
| 2242 | <entry>-</entry> | ||
| 2243 | <entry>y<subscript>7</subscript></entry> | ||
| 2244 | <entry>y<subscript>6</subscript></entry> | ||
| 2245 | <entry>y<subscript>5</subscript></entry> | ||
| 2246 | <entry>y<subscript>4</subscript></entry> | ||
| 2247 | <entry>y<subscript>3</subscript></entry> | ||
| 2248 | <entry>y<subscript>2</subscript></entry> | ||
| 2249 | <entry>y<subscript>1</subscript></entry> | ||
| 2250 | <entry>y<subscript>0</subscript></entry> | ||
| 2251 | <entry>d</entry> | ||
| 2252 | <entry>d</entry> | ||
| 2253 | <entry>d</entry> | ||
| 2254 | <entry>d</entry> | ||
| 2255 | <entry>d</entry> | ||
| 2256 | <entry>d</entry> | ||
| 2257 | <entry>d</entry> | ||
| 2258 | <entry>d</entry> | ||
| 2259 | </row> | ||
| 2260 | <row> | ||
| 2261 | <entry></entry> | ||
| 2262 | <entry></entry> | ||
| 2263 | <entry></entry> | ||
| 2264 | <entry>-</entry> | ||
| 2265 | <entry>-</entry> | ||
| 2266 | <entry>-</entry> | ||
| 2267 | <entry>-</entry> | ||
| 2268 | <entry>y<subscript>7</subscript></entry> | ||
| 2269 | <entry>y<subscript>6</subscript></entry> | ||
| 2270 | <entry>y<subscript>5</subscript></entry> | ||
| 2271 | <entry>y<subscript>4</subscript></entry> | ||
| 2272 | <entry>y<subscript>3</subscript></entry> | ||
| 2273 | <entry>y<subscript>2</subscript></entry> | ||
| 2274 | <entry>y<subscript>1</subscript></entry> | ||
| 2275 | <entry>y<subscript>0</subscript></entry> | ||
| 2276 | <entry>v<subscript>7</subscript></entry> | ||
| 2277 | <entry>v<subscript>6</subscript></entry> | ||
| 2278 | <entry>v<subscript>5</subscript></entry> | ||
| 2279 | <entry>v<subscript>4</subscript></entry> | ||
| 2280 | <entry>v<subscript>3</subscript></entry> | ||
| 2281 | <entry>v<subscript>2</subscript></entry> | ||
| 2282 | <entry>v<subscript>1</subscript></entry> | ||
| 2283 | <entry>v<subscript>0</subscript></entry> | ||
| 2284 | </row> | ||
| 2418 | <row id="V4L2-MBUS-FMT-YUYV10-1X20"> | 2285 | <row id="V4L2-MBUS-FMT-YUYV10-1X20"> |
| 2419 | <entry>V4L2_MBUS_FMT_YUYV10_1X20</entry> | 2286 | <entry>V4L2_MBUS_FMT_YUYV10_1X20</entry> |
| 2420 | <entry>0x200d</entry> | 2287 | <entry>0x200d</entry> |
| 2421 | <entry></entry> | 2288 | <entry></entry> |
| 2289 | &dash-ent-10; | ||
| 2422 | <entry>y<subscript>9</subscript></entry> | 2290 | <entry>y<subscript>9</subscript></entry> |
| 2423 | <entry>y<subscript>8</subscript></entry> | 2291 | <entry>y<subscript>8</subscript></entry> |
| 2424 | <entry>y<subscript>7</subscript></entry> | 2292 | <entry>y<subscript>7</subscript></entry> |
| @@ -2444,6 +2312,7 @@ | |||
| 2444 | <entry></entry> | 2312 | <entry></entry> |
| 2445 | <entry></entry> | 2313 | <entry></entry> |
| 2446 | <entry></entry> | 2314 | <entry></entry> |
| 2315 | &dash-ent-10; | ||
| 2447 | <entry>y<subscript>9</subscript></entry> | 2316 | <entry>y<subscript>9</subscript></entry> |
| 2448 | <entry>y<subscript>8</subscript></entry> | 2317 | <entry>y<subscript>8</subscript></entry> |
| 2449 | <entry>y<subscript>7</subscript></entry> | 2318 | <entry>y<subscript>7</subscript></entry> |
| @@ -2469,6 +2338,7 @@ | |||
| 2469 | <entry>V4L2_MBUS_FMT_YVYU10_1X20</entry> | 2338 | <entry>V4L2_MBUS_FMT_YVYU10_1X20</entry> |
| 2470 | <entry>0x200e</entry> | 2339 | <entry>0x200e</entry> |
| 2471 | <entry></entry> | 2340 | <entry></entry> |
| 2341 | &dash-ent-10; | ||
| 2472 | <entry>y<subscript>9</subscript></entry> | 2342 | <entry>y<subscript>9</subscript></entry> |
| 2473 | <entry>y<subscript>8</subscript></entry> | 2343 | <entry>y<subscript>8</subscript></entry> |
| 2474 | <entry>y<subscript>7</subscript></entry> | 2344 | <entry>y<subscript>7</subscript></entry> |
| @@ -2494,6 +2364,7 @@ | |||
| 2494 | <entry></entry> | 2364 | <entry></entry> |
| 2495 | <entry></entry> | 2365 | <entry></entry> |
| 2496 | <entry></entry> | 2366 | <entry></entry> |
| 2367 | &dash-ent-10; | ||
| 2497 | <entry>y<subscript>9</subscript></entry> | 2368 | <entry>y<subscript>9</subscript></entry> |
| 2498 | <entry>y<subscript>8</subscript></entry> | 2369 | <entry>y<subscript>8</subscript></entry> |
| 2499 | <entry>y<subscript>7</subscript></entry> | 2370 | <entry>y<subscript>7</subscript></entry> |
| @@ -2515,6 +2386,41 @@ | |||
| 2515 | <entry>u<subscript>1</subscript></entry> | 2386 | <entry>u<subscript>1</subscript></entry> |
| 2516 | <entry>u<subscript>0</subscript></entry> | 2387 | <entry>u<subscript>0</subscript></entry> |
| 2517 | </row> | 2388 | </row> |
| 2389 | <row id="V4L2-MBUS-FMT-YUV10-1X30"> | ||
| 2390 | <entry>V4L2_MBUS_FMT_YUV10_1X30</entry> | ||
| 2391 | <entry>0x2014</entry> | ||
| 2392 | <entry></entry> | ||
| 2393 | <entry>y<subscript>9</subscript></entry> | ||
| 2394 | <entry>y<subscript>8</subscript></entry> | ||
| 2395 | <entry>y<subscript>7</subscript></entry> | ||
| 2396 | <entry>y<subscript>6</subscript></entry> | ||
| 2397 | <entry>y<subscript>5</subscript></entry> | ||
| 2398 | <entry>y<subscript>4</subscript></entry> | ||
| 2399 | <entry>y<subscript>3</subscript></entry> | ||
| 2400 | <entry>y<subscript>2</subscript></entry> | ||
| 2401 | <entry>y<subscript>1</subscript></entry> | ||
| 2402 | <entry>y<subscript>0</subscript></entry> | ||
| 2403 | <entry>u<subscript>9</subscript></entry> | ||
| 2404 | <entry>u<subscript>8</subscript></entry> | ||
| 2405 | <entry>u<subscript>7</subscript></entry> | ||
| 2406 | <entry>u<subscript>6</subscript></entry> | ||
| 2407 | <entry>u<subscript>5</subscript></entry> | ||
| 2408 | <entry>u<subscript>4</subscript></entry> | ||
| 2409 | <entry>u<subscript>3</subscript></entry> | ||
| 2410 | <entry>u<subscript>2</subscript></entry> | ||
| 2411 | <entry>u<subscript>1</subscript></entry> | ||
| 2412 | <entry>u<subscript>0</subscript></entry> | ||
| 2413 | <entry>v<subscript>9</subscript></entry> | ||
| 2414 | <entry>v<subscript>8</subscript></entry> | ||
| 2415 | <entry>v<subscript>7</subscript></entry> | ||
| 2416 | <entry>v<subscript>6</subscript></entry> | ||
| 2417 | <entry>v<subscript>5</subscript></entry> | ||
| 2418 | <entry>v<subscript>4</subscript></entry> | ||
| 2419 | <entry>v<subscript>3</subscript></entry> | ||
| 2420 | <entry>v<subscript>2</subscript></entry> | ||
| 2421 | <entry>v<subscript>1</subscript></entry> | ||
| 2422 | <entry>v<subscript>0</subscript></entry> | ||
| 2423 | </row> | ||
| 2518 | </tbody> | 2424 | </tbody> |
| 2519 | </tgroup> | 2425 | </tgroup> |
| 2520 | </table> | 2426 | </table> |
diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index 4d110b1ad3e9..a3cce18384e9 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml | |||
| @@ -140,6 +140,16 @@ structs, ioctls) must be noted in more detail in the history chapter | |||
| 140 | applications. --> | 140 | applications. --> |
| 141 | 141 | ||
| 142 | <revision> | 142 | <revision> |
| 143 | <revnumber>3.9</revnumber> | ||
| 144 | <date>2012-12-03</date> | ||
| 145 | <authorinitials>sa, sn</authorinitials> | ||
| 146 | <revremark>Added timestamp types to v4l2_buffer. | ||
| 147 | Added <constant>V4L2_EVENT_CTRL_CH_RANGE</constant> control | ||
| 148 | event changes flag, see <xref linkend="changes-flags"/>. | ||
| 149 | </revremark> | ||
| 150 | </revision> | ||
| 151 | |||
| 152 | <revision> | ||
| 143 | <revnumber>3.6</revnumber> | 153 | <revnumber>3.6</revnumber> |
| 144 | <date>2012-07-02</date> | 154 | <date>2012-07-02</date> |
| 145 | <authorinitials>hv</authorinitials> | 155 | <authorinitials>hv</authorinitials> |
| @@ -472,7 +482,7 @@ and discussions on the V4L mailing list.</revremark> | |||
| 472 | </partinfo> | 482 | </partinfo> |
| 473 | 483 | ||
| 474 | <title>Video for Linux Two API Specification</title> | 484 | <title>Video for Linux Two API Specification</title> |
| 475 | <subtitle>Revision 3.6</subtitle> | 485 | <subtitle>Revision 3.9</subtitle> |
| 476 | 486 | ||
| 477 | <chapter id="common"> | 487 | <chapter id="common"> |
| 478 | &sub-common; | 488 | &sub-common; |
diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml index 98a856f9ec30..89891adb928a 100644 --- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml +++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml | |||
| @@ -261,6 +261,12 @@ | |||
| 261 | <entry>This control event was triggered because the control flags | 261 | <entry>This control event was triggered because the control flags |
| 262 | changed.</entry> | 262 | changed.</entry> |
| 263 | </row> | 263 | </row> |
| 264 | <row> | ||
| 265 | <entry><constant>V4L2_EVENT_CTRL_CH_RANGE</constant></entry> | ||
| 266 | <entry>0x0004</entry> | ||
| 267 | <entry>This control event was triggered because the minimum, | ||
| 268 | maximum, step or the default value of the control changed.</entry> | ||
| 269 | </row> | ||
| 264 | </tbody> | 270 | </tbody> |
| 265 | </tgroup> | 271 | </tgroup> |
| 266 | </table> | 272 | </table> |
diff --git a/Documentation/DocBook/media/v4l/vidioc-expbuf.xml b/Documentation/DocBook/media/v4l/vidioc-expbuf.xml index 72dfbd20a802..e287c8fc803b 100644 --- a/Documentation/DocBook/media/v4l/vidioc-expbuf.xml +++ b/Documentation/DocBook/media/v4l/vidioc-expbuf.xml | |||
| @@ -83,15 +83,14 @@ descriptor. The application may pass it to other DMABUF-aware devices. Refer to | |||
| 83 | <link linkend="dmabuf">DMABUF importing</link> for details about importing | 83 | <link linkend="dmabuf">DMABUF importing</link> for details about importing |
| 84 | DMABUF files into V4L2 nodes. It is recommended to close a DMABUF file when it | 84 | DMABUF files into V4L2 nodes. It is recommended to close a DMABUF file when it |
| 85 | is no longer used to allow the associated memory to be reclaimed. </para> | 85 | is no longer used to allow the associated memory to be reclaimed. </para> |
| 86 | |||
| 87 | </refsect1> | 86 | </refsect1> |
| 87 | |||
| 88 | <refsect1> | 88 | <refsect1> |
| 89 | <section> | 89 | <title>Examples</title> |
| 90 | <title>Examples</title> | ||
| 91 | 90 | ||
| 92 | <example> | 91 | <example> |
| 93 | <title>Exporting a buffer.</title> | 92 | <title>Exporting a buffer.</title> |
| 94 | <programlisting> | 93 | <programlisting> |
| 95 | int buffer_export(int v4lfd, &v4l2-buf-type; bt, int index, int *dmafd) | 94 | int buffer_export(int v4lfd, &v4l2-buf-type; bt, int index, int *dmafd) |
| 96 | { | 95 | { |
| 97 | &v4l2-exportbuffer; expbuf; | 96 | &v4l2-exportbuffer; expbuf; |
| @@ -108,12 +107,12 @@ int buffer_export(int v4lfd, &v4l2-buf-type; bt, int index, int *dmafd) | |||
| 108 | 107 | ||
| 109 | return 0; | 108 | return 0; |
| 110 | } | 109 | } |
| 111 | </programlisting> | 110 | </programlisting> |
| 112 | </example> | 111 | </example> |
| 113 | 112 | ||
| 114 | <example> | 113 | <example> |
| 115 | <title>Exporting a buffer using the multi-planar API.</title> | 114 | <title>Exporting a buffer using the multi-planar API.</title> |
| 116 | <programlisting> | 115 | <programlisting> |
| 117 | int buffer_export_mp(int v4lfd, &v4l2-buf-type; bt, int index, | 116 | int buffer_export_mp(int v4lfd, &v4l2-buf-type; bt, int index, |
| 118 | int dmafd[], int n_planes) | 117 | int dmafd[], int n_planes) |
| 119 | { | 118 | { |
| @@ -137,12 +136,9 @@ int buffer_export_mp(int v4lfd, &v4l2-buf-type; bt, int index, | |||
| 137 | 136 | ||
| 138 | return 0; | 137 | return 0; |
| 139 | } | 138 | } |
| 140 | </programlisting> | 139 | </programlisting> |
| 141 | </example> | 140 | </example> |
| 142 | </section> | ||
| 143 | </refsect1> | ||
| 144 | 141 | ||
| 145 | <refsect1> | ||
| 146 | <table pgwide="1" frame="none" id="v4l2-exportbuffer"> | 142 | <table pgwide="1" frame="none" id="v4l2-exportbuffer"> |
| 147 | <title>struct <structname>v4l2_exportbuffer</structname></title> | 143 | <title>struct <structname>v4l2_exportbuffer</structname></title> |
| 148 | <tgroup cols="3"> | 144 | <tgroup cols="3"> |
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-ctrl.xml b/Documentation/DocBook/media/v4l/vidioc-g-ctrl.xml index 12b1d0503e26..ee2820d6ca66 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-ctrl.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-ctrl.xml | |||
| @@ -64,7 +64,9 @@ return an &EINVAL;. When the <structfield>value</structfield> is out | |||
| 64 | of bounds drivers can choose to take the closest valid value or return | 64 | of bounds drivers can choose to take the closest valid value or return |
| 65 | an &ERANGE;, whatever seems more appropriate. However, | 65 | an &ERANGE;, whatever seems more appropriate. However, |
| 66 | <constant>VIDIOC_S_CTRL</constant> is a write-only ioctl, it does not | 66 | <constant>VIDIOC_S_CTRL</constant> is a write-only ioctl, it does not |
| 67 | return the actual new value.</para> | 67 | return the actual new value. If the <structfield>value</structfield> |
| 68 | is inappropriate for the control (e.g. if it refers to an unsupported | ||
| 69 | menu index of a menu control), then &EINVAL; is returned as well.</para> | ||
| 68 | 70 | ||
| 69 | <para>These ioctls work only with user controls. For other | 71 | <para>These ioctls work only with user controls. For other |
| 70 | control classes the &VIDIOC-G-EXT-CTRLS;, &VIDIOC-S-EXT-CTRLS; or | 72 | control classes the &VIDIOC-G-EXT-CTRLS;, &VIDIOC-S-EXT-CTRLS; or |
| @@ -99,7 +101,9 @@ application.</entry> | |||
| 99 | <term><errorcode>EINVAL</errorcode></term> | 101 | <term><errorcode>EINVAL</errorcode></term> |
| 100 | <listitem> | 102 | <listitem> |
| 101 | <para>The &v4l2-control; <structfield>id</structfield> is | 103 | <para>The &v4l2-control; <structfield>id</structfield> is |
| 102 | invalid.</para> | 104 | invalid or the <structfield>value</structfield> is inappropriate for |
| 105 | the given control (i.e. if a menu item is selected that is not supported | ||
| 106 | by the driver according to &VIDIOC-QUERYMENU;).</para> | ||
| 103 | </listitem> | 107 | </listitem> |
| 104 | </varlistentry> | 108 | </varlistentry> |
| 105 | <varlistentry> | 109 | <varlistentry> |
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml index 0a4b90fcf2da..4e16112df992 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml | |||
| @@ -106,7 +106,9 @@ value or if an error is returned.</para> | |||
| 106 | &EINVAL;. When the value is out of bounds drivers can choose to take | 106 | &EINVAL;. When the value is out of bounds drivers can choose to take |
| 107 | the closest valid value or return an &ERANGE;, whatever seems more | 107 | the closest valid value or return an &ERANGE;, whatever seems more |
| 108 | appropriate. In the first case the new value is set in | 108 | appropriate. In the first case the new value is set in |
| 109 | &v4l2-ext-control;.</para> | 109 | &v4l2-ext-control;. If the new control value is inappropriate (e.g. the |
| 110 | given menu index is not supported by the menu control), then this will | ||
| 111 | also result in an &EINVAL; error.</para> | ||
| 110 | 112 | ||
| 111 | <para>The driver will only set/get these controls if all control | 113 | <para>The driver will only set/get these controls if all control |
| 112 | values are correct. This prevents the situation where only some of the | 114 | values are correct. This prevents the situation where only some of the |
| @@ -199,13 +201,46 @@ also be zero.</entry> | |||
| 199 | <row> | 201 | <row> |
| 200 | <entry>__u32</entry> | 202 | <entry>__u32</entry> |
| 201 | <entry><structfield>error_idx</structfield></entry> | 203 | <entry><structfield>error_idx</structfield></entry> |
| 202 | <entry>Set by the driver in case of an error. If it is equal | 204 | <entry><para>Set by the driver in case of an error. If the error is |
| 203 | to <structfield>count</structfield>, then no actual changes were made to | 205 | associated with a particular control, then <structfield>error_idx</structfield> |
| 204 | controls. In other words, the error was not associated with setting a particular | 206 | is set to the index of that control. If the error is not related to a specific |
| 205 | control. If it is another value, then only the controls up to <structfield>error_idx-1</structfield> | 207 | control, or the validation step failed (see below), then |
| 206 | were modified and control <structfield>error_idx</structfield> is the one that | 208 | <structfield>error_idx</structfield> is set to <structfield>count</structfield>. |
| 207 | caused the error. The <structfield>error_idx</structfield> value is undefined | 209 | The value is undefined if the ioctl returned 0 (success).</para> |
| 208 | if the ioctl returned 0 (success).</entry> | 210 | |
| 211 | <para>Before controls are read from/written to hardware a validation step | ||
| 212 | takes place: this checks if all controls in the list are valid controls, | ||
| 213 | if no attempt is made to write to a read-only control or read from a write-only | ||
| 214 | control, and any other up-front checks that can be done without accessing the | ||
| 215 | hardware. The exact validations done during this step are driver dependent | ||
| 216 | since some checks might require hardware access for some devices, thus making | ||
| 217 | it impossible to do those checks up-front. However, drivers should make a | ||
| 218 | best-effort to do as many up-front checks as possible.</para> | ||
| 219 | |||
| 220 | <para>This check is done to avoid leaving the hardware in an inconsistent state due | ||
| 221 | to easy-to-avoid problems. But it leads to another problem: the application needs to | ||
| 222 | know whether an error came from the validation step (meaning that the hardware | ||
| 223 | was not touched) or from an error during the actual reading from/writing to hardware.</para> | ||
| 224 | |||
| 225 | <para>The, in hindsight quite poor, solution for that is to set <structfield>error_idx</structfield> | ||
| 226 | to <structfield>count</structfield> if the validation failed. This has the | ||
| 227 | unfortunate side-effect that it is not possible to see which control failed the | ||
| 228 | validation. If the validation was successful and the error happened while | ||
| 229 | accessing the hardware, then <structfield>error_idx</structfield> is less than | ||
| 230 | <structfield>count</structfield> and only the controls up to | ||
| 231 | <structfield>error_idx-1</structfield> were read or written correctly, and the | ||
| 232 | state of the remaining controls is undefined.</para> | ||
| 233 | |||
| 234 | <para>Since <constant>VIDIOC_TRY_EXT_CTRLS</constant> does not access hardware | ||
| 235 | there is also no need to handle the validation step in this special way, | ||
| 236 | so <structfield>error_idx</structfield> will just be set to the control that | ||
| 237 | failed the validation step instead of to <structfield>count</structfield>. | ||
| 238 | This means that if <constant>VIDIOC_S_EXT_CTRLS</constant> fails with | ||
| 239 | <structfield>error_idx</structfield> set to <structfield>count</structfield>, | ||
| 240 | then you can call <constant>VIDIOC_TRY_EXT_CTRLS</constant> to try to discover | ||
| 241 | the actual control that failed the validation step. Unfortunately, there | ||
| 242 | is no <constant>TRY</constant> equivalent for <constant>VIDIOC_G_EXT_CTRLS</constant>. | ||
| 243 | </para></entry> | ||
| 209 | </row> | 244 | </row> |
| 210 | <row> | 245 | <row> |
| 211 | <entry>__u32</entry> | 246 | <entry>__u32</entry> |
| @@ -298,8 +333,10 @@ These controls are described in <xref | |||
| 298 | <term><errorcode>EINVAL</errorcode></term> | 333 | <term><errorcode>EINVAL</errorcode></term> |
| 299 | <listitem> | 334 | <listitem> |
| 300 | <para>The &v4l2-ext-control; <structfield>id</structfield> | 335 | <para>The &v4l2-ext-control; <structfield>id</structfield> |
| 301 | is invalid or the &v4l2-ext-controls; | 336 | is invalid, the &v4l2-ext-controls; |
| 302 | <structfield>ctrl_class</structfield> is invalid. This error code is | 337 | <structfield>ctrl_class</structfield> is invalid, or the &v4l2-ext-control; |
| 338 | <structfield>value</structfield> was inappropriate (e.g. the given menu | ||
| 339 | index is not supported by the driver). This error code is | ||
| 303 | also returned by the <constant>VIDIOC_S_EXT_CTRLS</constant> and | 340 | also returned by the <constant>VIDIOC_S_EXT_CTRLS</constant> and |
| 304 | <constant>VIDIOC_TRY_EXT_CTRLS</constant> ioctls if two or more | 341 | <constant>VIDIOC_TRY_EXT_CTRLS</constant> ioctls if two or more |
| 305 | control values are in conflict.</para> | 342 | control values are in conflict.</para> |
diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index 4c70215ae03f..d5a3c97b206a 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml | |||
| @@ -76,7 +76,7 @@ make sure the strings are properly NUL-terminated.</para></entry> | |||
| 76 | <row> | 76 | <row> |
| 77 | <entry>__u8</entry> | 77 | <entry>__u8</entry> |
| 78 | <entry><structfield>card</structfield>[32]</entry> | 78 | <entry><structfield>card</structfield>[32]</entry> |
| 79 | <entry>Name of the device, a NUL-terminated ASCII string. | 79 | <entry>Name of the device, a NUL-terminated UTF-8 string. |
| 80 | For example: "Yoyodyne TV/FM". One driver may support different brands | 80 | For example: "Yoyodyne TV/FM". One driver may support different brands |
| 81 | or models of video hardware. This information is intended for users, | 81 | or models of video hardware. This information is intended for users, |
| 82 | for example in a menu of available devices. Since multiple TV cards of | 82 | for example in a menu of available devices. Since multiple TV cards of |
diff --git a/Documentation/DocBook/media_api.tmpl b/Documentation/DocBook/media_api.tmpl index f2413acfe241..1f6593deb995 100644 --- a/Documentation/DocBook/media_api.tmpl +++ b/Documentation/DocBook/media_api.tmpl | |||
| @@ -22,6 +22,7 @@ | |||
| 22 | 22 | ||
| 23 | <!-- LinuxTV v4l-dvb repository. --> | 23 | <!-- LinuxTV v4l-dvb repository. --> |
| 24 | <!ENTITY v4l-dvb "<ulink url='http://linuxtv.org/repo/'>http://linuxtv.org/repo/</ulink>"> | 24 | <!ENTITY v4l-dvb "<ulink url='http://linuxtv.org/repo/'>http://linuxtv.org/repo/</ulink>"> |
| 25 | <!ENTITY dash-ent-10 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>"> | ||
| 25 | ]> | 26 | ]> |
| 26 | 27 | ||
| 27 | <book id="media_api"> | 28 | <book id="media_api"> |
diff --git a/Documentation/EDID/HOWTO.txt b/Documentation/EDID/HOWTO.txt index 75a9f2a0c43d..2d0a8f09475d 100644 --- a/Documentation/EDID/HOWTO.txt +++ b/Documentation/EDID/HOWTO.txt | |||
| @@ -28,11 +28,30 @@ Makefile environment are given here. | |||
| 28 | To create binary EDID and C source code files from the existing data | 28 | To create binary EDID and C source code files from the existing data |
| 29 | material, simply type "make". | 29 | material, simply type "make". |
| 30 | 30 | ||
| 31 | If you want to create your own EDID file, copy the file 1024x768.S and | 31 | If you want to create your own EDID file, copy the file 1024x768.S, |
| 32 | replace the settings with your own data. The CRC value in the last line | 32 | replace the settings with your own data and add a new target to the |
| 33 | Makefile. Please note that the EDID data structure expects the timing | ||
| 34 | values in a different way as compared to the standard X11 format. | ||
| 35 | |||
| 36 | X11: | ||
| 37 | HTimings: hdisp hsyncstart hsyncend htotal | ||
| 38 | VTimings: vdisp vsyncstart vsyncend vtotal | ||
| 39 | |||
| 40 | EDID: | ||
| 41 | #define XPIX hdisp | ||
| 42 | #define XBLANK htotal-hdisp | ||
| 43 | #define XOFFSET hsyncstart-hdisp | ||
| 44 | #define XPULSE hsyncend-hsyncstart | ||
| 45 | |||
| 46 | #define YPIX vdisp | ||
| 47 | #define YBLANK vtotal-vdisp | ||
| 48 | #define YOFFSET (63+(vsyncstart-vdisp)) | ||
| 49 | #define YPULSE (63+(vsyncend-vsyncstart)) | ||
| 50 | |||
| 51 | The CRC value in the last line | ||
| 33 | #define CRC 0x55 | 52 | #define CRC 0x55 |
| 34 | is a bit tricky. After a first version of the binary data set is | 53 | also is a bit tricky. After a first version of the binary data set is |
| 35 | created, it must be be checked with the "edid-decode" utility which will | 54 | created, it must be checked with the "edid-decode" utility which will |
| 36 | most probably complain about a wrong CRC. Fortunately, the utility also | 55 | most probably complain about a wrong CRC. Fortunately, the utility also |
| 37 | displays the correct CRC which must then be inserted into the source | 56 | displays the correct CRC which must then be inserted into the source |
| 38 | file. After the make procedure is repeated, the EDID data set is ready | 57 | file. After the make procedure is repeated, the EDID data set is ready |
diff --git a/Documentation/IPMI.txt b/Documentation/IPMI.txt index 16eb4c9e9233..f13c9132e9f2 100644 --- a/Documentation/IPMI.txt +++ b/Documentation/IPMI.txt | |||
| @@ -348,34 +348,40 @@ You can change this at module load time (for a module) with: | |||
| 348 | 348 | ||
| 349 | modprobe ipmi_si.o type=<type1>,<type2>.... | 349 | modprobe ipmi_si.o type=<type1>,<type2>.... |
| 350 | ports=<port1>,<port2>... addrs=<addr1>,<addr2>... | 350 | ports=<port1>,<port2>... addrs=<addr1>,<addr2>... |
| 351 | irqs=<irq1>,<irq2>... trydefaults=[0|1] | 351 | irqs=<irq1>,<irq2>... |
| 352 | regspacings=<sp1>,<sp2>,... regsizes=<size1>,<size2>,... | 352 | regspacings=<sp1>,<sp2>,... regsizes=<size1>,<size2>,... |
| 353 | regshifts=<shift1>,<shift2>,... | 353 | regshifts=<shift1>,<shift2>,... |
| 354 | slave_addrs=<addr1>,<addr2>,... | 354 | slave_addrs=<addr1>,<addr2>,... |
| 355 | force_kipmid=<enable1>,<enable2>,... | 355 | force_kipmid=<enable1>,<enable2>,... |
| 356 | kipmid_max_busy_us=<ustime1>,<ustime2>,... | 356 | kipmid_max_busy_us=<ustime1>,<ustime2>,... |
| 357 | unload_when_empty=[0|1] | 357 | unload_when_empty=[0|1] |
| 358 | trydefaults=[0|1] trydmi=[0|1] tryacpi=[0|1] | ||
| 359 | tryplatform=[0|1] trypci=[0|1] | ||
| 358 | 360 | ||
| 359 | Each of these except si_trydefaults is a list, the first item for the | 361 | Each of these except try... items is a list, the first item for the |
| 360 | first interface, second item for the second interface, etc. | 362 | first interface, second item for the second interface, etc. |
| 361 | 363 | ||
| 362 | The si_type may be either "kcs", "smic", or "bt". If you leave it blank, it | 364 | The si_type may be either "kcs", "smic", or "bt". If you leave it blank, it |
| 363 | defaults to "kcs". | 365 | defaults to "kcs". |
| 364 | 366 | ||
| 365 | If you specify si_addrs as non-zero for an interface, the driver will | 367 | If you specify addrs as non-zero for an interface, the driver will |
| 366 | use the memory address given as the address of the device. This | 368 | use the memory address given as the address of the device. This |
| 367 | overrides si_ports. | 369 | overrides si_ports. |
| 368 | 370 | ||
| 369 | If you specify si_ports as non-zero for an interface, the driver will | 371 | If you specify ports as non-zero for an interface, the driver will |
| 370 | use the I/O port given as the device address. | 372 | use the I/O port given as the device address. |
| 371 | 373 | ||
| 372 | If you specify si_irqs as non-zero for an interface, the driver will | 374 | If you specify irqs as non-zero for an interface, the driver will |
| 373 | attempt to use the given interrupt for the device. | 375 | attempt to use the given interrupt for the device. |
| 374 | 376 | ||
| 375 | si_trydefaults sets whether the standard IPMI interface at 0xca2 and | 377 | trydefaults sets whether the standard IPMI interface at 0xca2 and |
| 376 | any interfaces specified by ACPE are tried. By default, the driver | 378 | any interfaces specified by ACPE are tried. By default, the driver |
| 377 | tries it, set this value to zero to turn this off. | 379 | tries it, set this value to zero to turn this off. |
| 378 | 380 | ||
| 381 | The other try... items disable discovery by their corresponding | ||
| 382 | names. These are all enabled by default, set them to zero to disable | ||
| 383 | them. The tryplatform disables openfirmware. | ||
| 384 | |||
| 379 | The next three parameters have to do with register layout. The | 385 | The next three parameters have to do with register layout. The |
| 380 | registers used by the interfaces may not appear at successive | 386 | registers used by the interfaces may not appear at successive |
| 381 | locations and they may not be in 8-bit registers. These parameters | 387 | locations and they may not be in 8-bit registers. These parameters |
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index c379a2a6949f..aa0c1e63f050 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches | |||
| @@ -60,8 +60,7 @@ own source tree. For example: | |||
| 60 | "dontdiff" is a list of files which are generated by the kernel during | 60 | "dontdiff" is a list of files which are generated by the kernel during |
| 61 | the build process, and should be ignored in any diff(1)-generated | 61 | the build process, and should be ignored in any diff(1)-generated |
| 62 | patch. The "dontdiff" file is included in the kernel tree in | 62 | patch. The "dontdiff" file is included in the kernel tree in |
| 63 | 2.6.12 and later. For earlier kernel versions, you can get it | 63 | 2.6.12 and later. |
| 64 | from <http://www.xenotime.net/linux/doc/dontdiff>. | ||
| 65 | 64 | ||
| 66 | Make sure your patch does not include any extra files which do not | 65 | Make sure your patch does not include any extra files which do not |
| 67 | belong in a patch submission. Make sure to review your patch -after- | 66 | belong in a patch submission. Make sure to review your patch -after- |
diff --git a/Documentation/block/cfq-iosched.txt b/Documentation/block/cfq-iosched.txt index d89b4fe724d7..a5eb7d19a65d 100644 --- a/Documentation/block/cfq-iosched.txt +++ b/Documentation/block/cfq-iosched.txt | |||
| @@ -102,6 +102,64 @@ processing of request. Therefore, increasing the value can imporve the | |||
| 102 | performace although this can cause the latency of some I/O to increase due | 102 | performace although this can cause the latency of some I/O to increase due |
| 103 | to more number of requests. | 103 | to more number of requests. |
| 104 | 104 | ||
| 105 | CFQ Group scheduling | ||
| 106 | ==================== | ||
| 107 | |||
| 108 | CFQ supports blkio cgroup and has "blkio." prefixed files in each | ||
| 109 | blkio cgroup directory. It is weight-based and there are four knobs | ||
| 110 | for configuration - weight[_device] and leaf_weight[_device]. | ||
| 111 | Internal cgroup nodes (the ones with children) can also have tasks in | ||
| 112 | them, so the former two configure how much proportion the cgroup as a | ||
| 113 | whole is entitled to at its parent's level while the latter two | ||
| 114 | configure how much proportion the tasks in the cgroup have compared to | ||
| 115 | its direct children. | ||
| 116 | |||
| 117 | Another way to think about it is assuming that each internal node has | ||
| 118 | an implicit leaf child node which hosts all the tasks whose weight is | ||
| 119 | configured by leaf_weight[_device]. Let's assume a blkio hierarchy | ||
| 120 | composed of five cgroups - root, A, B, AA and AB - with the following | ||
| 121 | weights where the names represent the hierarchy. | ||
| 122 | |||
| 123 | weight leaf_weight | ||
| 124 | root : 125 125 | ||
| 125 | A : 500 750 | ||
| 126 | B : 250 500 | ||
| 127 | AA : 500 500 | ||
| 128 | AB : 1000 500 | ||
| 129 | |||
| 130 | root never has a parent making its weight is meaningless. For backward | ||
| 131 | compatibility, weight is always kept in sync with leaf_weight. B, AA | ||
| 132 | and AB have no child and thus its tasks have no children cgroup to | ||
| 133 | compete with. They always get 100% of what the cgroup won at the | ||
| 134 | parent level. Considering only the weights which matter, the hierarchy | ||
| 135 | looks like the following. | ||
| 136 | |||
| 137 | root | ||
| 138 | / | \ | ||
| 139 | A B leaf | ||
| 140 | 500 250 125 | ||
| 141 | / | \ | ||
| 142 | AA AB leaf | ||
| 143 | 500 1000 750 | ||
| 144 | |||
| 145 | If all cgroups have active IOs and competing with each other, disk | ||
| 146 | time will be distributed like the following. | ||
| 147 | |||
| 148 | Distribution below root. The total active weight at this level is | ||
| 149 | A:500 + B:250 + C:125 = 875. | ||
| 150 | |||
| 151 | root-leaf : 125 / 875 =~ 14% | ||
| 152 | A : 500 / 875 =~ 57% | ||
| 153 | B(-leaf) : 250 / 875 =~ 28% | ||
| 154 | |||
| 155 | A has children and further distributes its 57% among the children and | ||
| 156 | the implicit leaf node. The total active weight at this level is | ||
| 157 | AA:500 + AB:1000 + A-leaf:750 = 2250. | ||
| 158 | |||
| 159 | A-leaf : ( 750 / 2250) * A =~ 19% | ||
| 160 | AA(-leaf) : ( 500 / 2250) * A =~ 12% | ||
| 161 | AB(-leaf) : (1000 / 2250) * A =~ 25% | ||
| 162 | |||
| 105 | CFQ IOPS Mode for group scheduling | 163 | CFQ IOPS Mode for group scheduling |
| 106 | =================================== | 164 | =================================== |
| 107 | Basic CFQ design is to provide priority based time slices. Higher priority | 165 | Basic CFQ design is to provide priority based time slices. Higher priority |
diff --git a/Documentation/blockdev/nbd.txt b/Documentation/blockdev/nbd.txt index aeb93ffe6416..271e607304da 100644 --- a/Documentation/blockdev/nbd.txt +++ b/Documentation/blockdev/nbd.txt | |||
| @@ -4,43 +4,13 @@ | |||
| 4 | can use a remote server as one of its block devices. So every time | 4 | can use a remote server as one of its block devices. So every time |
| 5 | the client computer wants to read, e.g., /dev/nb0, it sends a | 5 | the client computer wants to read, e.g., /dev/nb0, it sends a |
| 6 | request over TCP to the server, which will reply with the data read. | 6 | request over TCP to the server, which will reply with the data read. |
| 7 | This can be used for stations with low disk space (or even diskless - | 7 | This can be used for stations with low disk space (or even diskless) |
| 8 | if you boot from floppy) to borrow disk space from another computer. | 8 | to borrow disk space from another computer. |
| 9 | Unlike NFS, it is possible to put any filesystem on it, etc. It should | 9 | Unlike NFS, it is possible to put any filesystem on it, etc. |
| 10 | even be possible to use NBD as a root filesystem (I've never tried), | 10 | |
| 11 | but it requires a user-level program to be in the initrd to start. | ||
| 12 | It also allows you to run block-device in user land (making server | ||
| 13 | and client physically the same computer, communicating using loopback). | ||
| 14 | |||
| 15 | Current state: It currently works. Network block device is stable. | ||
| 16 | I originally thought that it was impossible to swap over TCP. It | ||
| 17 | turned out not to be true - swapping over TCP now works and seems | ||
| 18 | to be deadlock-free, but it requires heavy patches into Linux's | ||
| 19 | network layer. | ||
| 20 | |||
| 21 | For more information, or to download the nbd-client and nbd-server | 11 | For more information, or to download the nbd-client and nbd-server |
| 22 | tools, go to http://nbd.sf.net/. | 12 | tools, go to http://nbd.sf.net/. |
| 23 | 13 | ||
| 24 | Howto: To setup nbd, you can simply do the following: | ||
| 25 | |||
| 26 | First, serve a device or file from a remote server: | ||
| 27 | |||
| 28 | nbd-server <port-number> <device-or-file-to-serve-to-client> | ||
| 29 | |||
| 30 | e.g., | ||
| 31 | root@server1 # nbd-server 1234 /dev/sdb1 | ||
| 32 | |||
| 33 | (serves sdb1 partition on TCP port 1234) | ||
| 34 | |||
| 35 | Then, on the local (client) system: | ||
| 36 | |||
| 37 | nbd-client <server-name-or-IP> <server-port-number> /dev/nb[0-n] | ||
| 38 | |||
| 39 | e.g., | ||
| 40 | root@client1 # nbd-client server1 1234 /dev/nb0 | ||
| 41 | |||
| 42 | (creates the nb0 device on client1) | ||
| 43 | |||
| 44 | The nbd kernel module need only be installed on the client | 14 | The nbd kernel module need only be installed on the client |
| 45 | system, as the nbd-server is completely in userspace. In fact, | 15 | system, as the nbd-server is completely in userspace. In fact, |
| 46 | the nbd-server has been successfully ported to other operating | 16 | the nbd-server has been successfully ported to other operating |
diff --git a/Documentation/cgroups/blkio-controller.txt b/Documentation/cgroups/blkio-controller.txt index b4b1fb3a83f0..da272c8f44e7 100644 --- a/Documentation/cgroups/blkio-controller.txt +++ b/Documentation/cgroups/blkio-controller.txt | |||
| @@ -75,7 +75,7 @@ Throttling/Upper Limit policy | |||
| 75 | mount -t cgroup -o blkio none /sys/fs/cgroup/blkio | 75 | mount -t cgroup -o blkio none /sys/fs/cgroup/blkio |
| 76 | 76 | ||
| 77 | - Specify a bandwidth rate on particular device for root group. The format | 77 | - Specify a bandwidth rate on particular device for root group. The format |
| 78 | for policy is "<major>:<minor> <byes_per_second>". | 78 | for policy is "<major>:<minor> <bytes_per_second>". |
| 79 | 79 | ||
| 80 | echo "8:16 1048576" > /sys/fs/cgroup/blkio/blkio.throttle.read_bps_device | 80 | echo "8:16 1048576" > /sys/fs/cgroup/blkio/blkio.throttle.read_bps_device |
| 81 | 81 | ||
| @@ -94,13 +94,11 @@ Throttling/Upper Limit policy | |||
| 94 | 94 | ||
| 95 | Hierarchical Cgroups | 95 | Hierarchical Cgroups |
| 96 | ==================== | 96 | ==================== |
| 97 | - Currently none of the IO control policy supports hierarchical groups. But | 97 | - Currently only CFQ supports hierarchical groups. For throttling, |
| 98 | cgroup interface does allow creation of hierarchical cgroups and internally | 98 | cgroup interface does allow creation of hierarchical cgroups and |
| 99 | IO policies treat them as flat hierarchy. | 99 | internally it treats them as flat hierarchy. |
| 100 | 100 | ||
| 101 | So this patch will allow creation of cgroup hierarchcy but at the backend | 101 | If somebody created a hierarchy like as follows. |
| 102 | everything will be treated as flat. So if somebody created a hierarchy like | ||
| 103 | as follows. | ||
| 104 | 102 | ||
| 105 | root | 103 | root |
| 106 | / \ | 104 | / \ |
| @@ -108,16 +106,20 @@ Hierarchical Cgroups | |||
| 108 | | | 106 | | |
| 109 | test3 | 107 | test3 |
| 110 | 108 | ||
| 111 | CFQ and throttling will practically treat all groups at same level. | 109 | CFQ will handle the hierarchy correctly but and throttling will |
| 110 | practically treat all groups at same level. For details on CFQ | ||
| 111 | hierarchy support, refer to Documentation/block/cfq-iosched.txt. | ||
| 112 | Throttling will treat the hierarchy as if it looks like the | ||
| 113 | following. | ||
| 112 | 114 | ||
| 113 | pivot | 115 | pivot |
| 114 | / / \ \ | 116 | / / \ \ |
| 115 | root test1 test2 test3 | 117 | root test1 test2 test3 |
| 116 | 118 | ||
| 117 | Down the line we can implement hierarchical accounting/control support | 119 | Nesting cgroups, while allowed, isn't officially supported and blkio |
| 118 | and also introduce a new cgroup file "use_hierarchy" which will control | 120 | genereates warning when cgroups nest. Once throttling implements |
| 119 | whether cgroup hierarchy is viewed as flat or hierarchical by the policy.. | 121 | hierarchy support, hierarchy will be supported and the warning will |
| 120 | This is how memory controller also has implemented the things. | 122 | be removed. |
| 121 | 123 | ||
| 122 | Various user visible config options | 124 | Various user visible config options |
| 123 | =================================== | 125 | =================================== |
| @@ -172,6 +174,12 @@ Proportional weight policy files | |||
| 172 | dev weight | 174 | dev weight |
| 173 | 8:16 300 | 175 | 8:16 300 |
| 174 | 176 | ||
| 177 | - blkio.leaf_weight[_device] | ||
| 178 | - Equivalents of blkio.weight[_device] for the purpose of | ||
| 179 | deciding how much weight tasks in the given cgroup has while | ||
| 180 | competing with the cgroup's child cgroups. For details, | ||
| 181 | please refer to Documentation/block/cfq-iosched.txt. | ||
| 182 | |||
| 175 | - blkio.time | 183 | - blkio.time |
| 176 | - disk time allocated to cgroup per device in milliseconds. First | 184 | - disk time allocated to cgroup per device in milliseconds. First |
| 177 | two fields specify the major and minor number of the device and | 185 | two fields specify the major and minor number of the device and |
| @@ -279,6 +287,11 @@ Proportional weight policy files | |||
| 279 | and minor number of the device and third field specifies the number | 287 | and minor number of the device and third field specifies the number |
| 280 | of times a group was dequeued from a particular device. | 288 | of times a group was dequeued from a particular device. |
| 281 | 289 | ||
| 290 | - blkio.*_recursive | ||
| 291 | - Recursive version of various stats. These files show the | ||
| 292 | same information as their non-recursive counterparts but | ||
| 293 | include stats from all the descendant cgroups. | ||
| 294 | |||
| 282 | Throttling/Upper limit policy files | 295 | Throttling/Upper limit policy files |
| 283 | ----------------------------------- | 296 | ----------------------------------- |
| 284 | - blkio.throttle.read_bps_device | 297 | - blkio.throttle.read_bps_device |
diff --git a/Documentation/coccinelle.txt b/Documentation/coccinelle.txt index cf44eb6499b4..dffa2d620d6d 100644 --- a/Documentation/coccinelle.txt +++ b/Documentation/coccinelle.txt | |||
| @@ -87,6 +87,10 @@ As any static code analyzer, Coccinelle produces false | |||
| 87 | positives. Thus, reports must be carefully checked, and patches | 87 | positives. Thus, reports must be carefully checked, and patches |
| 88 | reviewed. | 88 | reviewed. |
| 89 | 89 | ||
| 90 | To enable verbose messages set the V= variable, for example: | ||
| 91 | |||
| 92 | make coccicheck MODE=report V=1 | ||
| 93 | |||
| 90 | 94 | ||
| 91 | Using Coccinelle with a single semantic patch | 95 | Using Coccinelle with a single semantic patch |
| 92 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 96 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
diff --git a/Documentation/device-mapper/cache-policies.txt b/Documentation/device-mapper/cache-policies.txt new file mode 100644 index 000000000000..d7c440b444cc --- /dev/null +++ b/Documentation/device-mapper/cache-policies.txt | |||
| @@ -0,0 +1,77 @@ | |||
| 1 | Guidance for writing policies | ||
| 2 | ============================= | ||
| 3 | |||
| 4 | Try to keep transactionality out of it. The core is careful to | ||
| 5 | avoid asking about anything that is migrating. This is a pain, but | ||
| 6 | makes it easier to write the policies. | ||
| 7 | |||
| 8 | Mappings are loaded into the policy at construction time. | ||
| 9 | |||
| 10 | Every bio that is mapped by the target is referred to the policy. | ||
| 11 | The policy can return a simple HIT or MISS or issue a migration. | ||
| 12 | |||
| 13 | Currently there's no way for the policy to issue background work, | ||
| 14 | e.g. to start writing back dirty blocks that are going to be evicte | ||
| 15 | soon. | ||
| 16 | |||
| 17 | Because we map bios, rather than requests it's easy for the policy | ||
| 18 | to get fooled by many small bios. For this reason the core target | ||
| 19 | issues periodic ticks to the policy. It's suggested that the policy | ||
| 20 | doesn't update states (eg, hit counts) for a block more than once | ||
| 21 | for each tick. The core ticks by watching bios complete, and so | ||
| 22 | trying to see when the io scheduler has let the ios run. | ||
| 23 | |||
| 24 | |||
| 25 | Overview of supplied cache replacement policies | ||
| 26 | =============================================== | ||
| 27 | |||
| 28 | multiqueue | ||
| 29 | ---------- | ||
| 30 | |||
| 31 | This policy is the default. | ||
| 32 | |||
| 33 | The multiqueue policy has two sets of 16 queues: one set for entries | ||
| 34 | waiting for the cache and another one for those in the cache. | ||
| 35 | Cache entries in the queues are aged based on logical time. Entry into | ||
| 36 | the cache is based on variable thresholds and queue selection is based | ||
| 37 | on hit count on entry. The policy aims to take different cache miss | ||
| 38 | costs into account and to adjust to varying load patterns automatically. | ||
| 39 | |||
| 40 | Message and constructor argument pairs are: | ||
| 41 | 'sequential_threshold <#nr_sequential_ios>' and | ||
| 42 | 'random_threshold <#nr_random_ios>'. | ||
| 43 | |||
| 44 | The sequential threshold indicates the number of contiguous I/Os | ||
| 45 | required before a stream is treated as sequential. The random threshold | ||
| 46 | is the number of intervening non-contiguous I/Os that must be seen | ||
| 47 | before the stream is treated as random again. | ||
| 48 | |||
| 49 | The sequential and random thresholds default to 512 and 4 respectively. | ||
| 50 | |||
| 51 | Large, sequential ios are probably better left on the origin device | ||
| 52 | since spindles tend to have good bandwidth. The io_tracker counts | ||
| 53 | contiguous I/Os to try to spot when the io is in one of these sequential | ||
| 54 | modes. | ||
| 55 | |||
| 56 | cleaner | ||
| 57 | ------- | ||
| 58 | |||
| 59 | The cleaner writes back all dirty blocks in a cache to decommission it. | ||
| 60 | |||
| 61 | Examples | ||
| 62 | ======== | ||
| 63 | |||
| 64 | The syntax for a table is: | ||
| 65 | cache <metadata dev> <cache dev> <origin dev> <block size> | ||
| 66 | <#feature_args> [<feature arg>]* | ||
| 67 | <policy> <#policy_args> [<policy arg>]* | ||
| 68 | |||
| 69 | The syntax to send a message using the dmsetup command is: | ||
| 70 | dmsetup message <mapped device> 0 sequential_threshold 1024 | ||
| 71 | dmsetup message <mapped device> 0 random_threshold 8 | ||
| 72 | |||
| 73 | Using dmsetup: | ||
| 74 | dmsetup create blah --table "0 268435456 cache /dev/sdb /dev/sdc \ | ||
| 75 | /dev/sdd 512 0 mq 4 sequential_threshold 1024 random_threshold 8" | ||
| 76 | creates a 128GB large mapped device named 'blah' with the | ||
| 77 | sequential threshold set to 1024 and the random_threshold set to 8. | ||
diff --git a/Documentation/device-mapper/cache.txt b/Documentation/device-mapper/cache.txt new file mode 100644 index 000000000000..f50470abe241 --- /dev/null +++ b/Documentation/device-mapper/cache.txt | |||
| @@ -0,0 +1,243 @@ | |||
| 1 | Introduction | ||
| 2 | ============ | ||
| 3 | |||
| 4 | dm-cache is a device mapper target written by Joe Thornber, Heinz | ||
| 5 | Mauelshagen, and Mike Snitzer. | ||
| 6 | |||
| 7 | It aims to improve performance of a block device (eg, a spindle) by | ||
| 8 | dynamically migrating some of its data to a faster, smaller device | ||
| 9 | (eg, an SSD). | ||
| 10 | |||
| 11 | This device-mapper solution allows us to insert this caching at | ||
| 12 | different levels of the dm stack, for instance above the data device for | ||
| 13 | a thin-provisioning pool. Caching solutions that are integrated more | ||
| 14 | closely with the virtual memory system should give better performance. | ||
| 15 | |||
| 16 | The target reuses the metadata library used in the thin-provisioning | ||
| 17 | library. | ||
| 18 | |||
| 19 | The decision as to what data to migrate and when is left to a plug-in | ||
| 20 | policy module. Several of these have been written as we experiment, | ||
| 21 | and we hope other people will contribute others for specific io | ||
| 22 | scenarios (eg. a vm image server). | ||
| 23 | |||
| 24 | Glossary | ||
| 25 | ======== | ||
| 26 | |||
| 27 | Migration - Movement of the primary copy of a logical block from one | ||
| 28 | device to the other. | ||
| 29 | Promotion - Migration from slow device to fast device. | ||
| 30 | Demotion - Migration from fast device to slow device. | ||
| 31 | |||
| 32 | The origin device always contains a copy of the logical block, which | ||
| 33 | may be out of date or kept in sync with the copy on the cache device | ||
| 34 | (depending on policy). | ||
| 35 | |||
| 36 | Design | ||
| 37 | ====== | ||
| 38 | |||
| 39 | Sub-devices | ||
| 40 | ----------- | ||
| 41 | |||
| 42 | The target is constructed by passing three devices to it (along with | ||
| 43 | other parameters detailed later): | ||
| 44 | |||
| 45 | 1. An origin device - the big, slow one. | ||
| 46 | |||
| 47 | 2. A cache device - the small, fast one. | ||
| 48 | |||
| 49 | 3. A small metadata device - records which blocks are in the cache, | ||
| 50 | which are dirty, and extra hints for use by the policy object. | ||
| 51 | This information could be put on the cache device, but having it | ||
| 52 | separate allows the volume manager to configure it differently, | ||
| 53 | e.g. as a mirror for extra robustness. | ||
| 54 | |||
| 55 | Fixed block size | ||
| 56 | ---------------- | ||
| 57 | |||
| 58 | The origin is divided up into blocks of a fixed size. This block size | ||
| 59 | is configurable when you first create the cache. Typically we've been | ||
| 60 | using block sizes of 256k - 1024k. | ||
| 61 | |||
| 62 | Having a fixed block size simplifies the target a lot. But it is | ||
| 63 | something of a compromise. For instance, a small part of a block may be | ||
| 64 | getting hit a lot, yet the whole block will be promoted to the cache. | ||
| 65 | So large block sizes are bad because they waste cache space. And small | ||
| 66 | block sizes are bad because they increase the amount of metadata (both | ||
| 67 | in core and on disk). | ||
| 68 | |||
| 69 | Writeback/writethrough | ||
| 70 | ---------------------- | ||
| 71 | |||
| 72 | The cache has two modes, writeback and writethrough. | ||
| 73 | |||
| 74 | If writeback, the default, is selected then a write to a block that is | ||
| 75 | cached will go only to the cache and the block will be marked dirty in | ||
| 76 | the metadata. | ||
| 77 | |||
| 78 | If writethrough is selected then a write to a cached block will not | ||
| 79 | complete until it has hit both the origin and cache devices. Clean | ||
| 80 | blocks should remain clean. | ||
| 81 | |||
| 82 | A simple cleaner policy is provided, which will clean (write back) all | ||
| 83 | dirty blocks in a cache. Useful for decommissioning a cache. | ||
| 84 | |||
| 85 | Migration throttling | ||
| 86 | -------------------- | ||
| 87 | |||
| 88 | Migrating data between the origin and cache device uses bandwidth. | ||
| 89 | The user can set a throttle to prevent more than a certain amount of | ||
| 90 | migration occuring at any one time. Currently we're not taking any | ||
| 91 | account of normal io traffic going to the devices. More work needs | ||
| 92 | doing here to avoid migrating during those peak io moments. | ||
| 93 | |||
| 94 | For the time being, a message "migration_threshold <#sectors>" | ||
| 95 | can be used to set the maximum number of sectors being migrated, | ||
| 96 | the default being 204800 sectors (or 100MB). | ||
| 97 | |||
| 98 | Updating on-disk metadata | ||
| 99 | ------------------------- | ||
| 100 | |||
| 101 | On-disk metadata is committed every time a REQ_SYNC or REQ_FUA bio is | ||
| 102 | written. If no such requests are made then commits will occur every | ||
| 103 | second. This means the cache behaves like a physical disk that has a | ||
| 104 | write cache (the same is true of the thin-provisioning target). If | ||
| 105 | power is lost you may lose some recent writes. The metadata should | ||
| 106 | always be consistent in spite of any crash. | ||
| 107 | |||
| 108 | The 'dirty' state for a cache block changes far too frequently for us | ||
| 109 | to keep updating it on the fly. So we treat it as a hint. In normal | ||
| 110 | operation it will be written when the dm device is suspended. If the | ||
| 111 | system crashes all cache blocks will be assumed dirty when restarted. | ||
| 112 | |||
| 113 | Per-block policy hints | ||
| 114 | ---------------------- | ||
| 115 | |||
| 116 | Policy plug-ins can store a chunk of data per cache block. It's up to | ||
| 117 | the policy how big this chunk is, but it should be kept small. Like the | ||
| 118 | dirty flags this data is lost if there's a crash so a safe fallback | ||
| 119 | value should always be possible. | ||
| 120 | |||
| 121 | For instance, the 'mq' policy, which is currently the default policy, | ||
| 122 | uses this facility to store the hit count of the cache blocks. If | ||
| 123 | there's a crash this information will be lost, which means the cache | ||
| 124 | may be less efficient until those hit counts are regenerated. | ||
| 125 | |||
| 126 | Policy hints affect performance, not correctness. | ||
| 127 | |||
| 128 | Policy messaging | ||
| 129 | ---------------- | ||
| 130 | |||
| 131 | Policies will have different tunables, specific to each one, so we | ||
| 132 | need a generic way of getting and setting these. Device-mapper | ||
| 133 | messages are used. Refer to cache-policies.txt. | ||
| 134 | |||
| 135 | Discard bitset resolution | ||
| 136 | ------------------------- | ||
| 137 | |||
| 138 | We can avoid copying data during migration if we know the block has | ||
| 139 | been discarded. A prime example of this is when mkfs discards the | ||
| 140 | whole block device. We store a bitset tracking the discard state of | ||
| 141 | blocks. However, we allow this bitset to have a different block size | ||
| 142 | from the cache blocks. This is because we need to track the discard | ||
| 143 | state for all of the origin device (compare with the dirty bitset | ||
| 144 | which is just for the smaller cache device). | ||
| 145 | |||
| 146 | Target interface | ||
| 147 | ================ | ||
| 148 | |||
| 149 | Constructor | ||
| 150 | ----------- | ||
| 151 | |||
| 152 | cache <metadata dev> <cache dev> <origin dev> <block size> | ||
| 153 | <#feature args> [<feature arg>]* | ||
| 154 | <policy> <#policy args> [policy args]* | ||
| 155 | |||
| 156 | metadata dev : fast device holding the persistent metadata | ||
| 157 | cache dev : fast device holding cached data blocks | ||
| 158 | origin dev : slow device holding original data blocks | ||
| 159 | block size : cache unit size in sectors | ||
| 160 | |||
| 161 | #feature args : number of feature arguments passed | ||
| 162 | feature args : writethrough. (The default is writeback.) | ||
| 163 | |||
| 164 | policy : the replacement policy to use | ||
| 165 | #policy args : an even number of arguments corresponding to | ||
| 166 | key/value pairs passed to the policy | ||
| 167 | policy args : key/value pairs passed to the policy | ||
| 168 | E.g. 'sequential_threshold 1024' | ||
| 169 | See cache-policies.txt for details. | ||
| 170 | |||
| 171 | Optional feature arguments are: | ||
| 172 | writethrough : write through caching that prohibits cache block | ||
| 173 | content from being different from origin block content. | ||
| 174 | Without this argument, the default behaviour is to write | ||
| 175 | back cache block contents later for performance reasons, | ||
| 176 | so they may differ from the corresponding origin blocks. | ||
| 177 | |||
| 178 | A policy called 'default' is always registered. This is an alias for | ||
| 179 | the policy we currently think is giving best all round performance. | ||
| 180 | |||
| 181 | As the default policy could vary between kernels, if you are relying on | ||
| 182 | the characteristics of a specific policy, always request it by name. | ||
| 183 | |||
| 184 | Status | ||
| 185 | ------ | ||
| 186 | |||
| 187 | <#used metadata blocks>/<#total metadata blocks> <#read hits> <#read misses> | ||
| 188 | <#write hits> <#write misses> <#demotions> <#promotions> <#blocks in cache> | ||
| 189 | <#dirty> <#features> <features>* <#core args> <core args>* <#policy args> | ||
| 190 | <policy args>* | ||
| 191 | |||
| 192 | #used metadata blocks : Number of metadata blocks used | ||
| 193 | #total metadata blocks : Total number of metadata blocks | ||
| 194 | #read hits : Number of times a READ bio has been mapped | ||
| 195 | to the cache | ||
| 196 | #read misses : Number of times a READ bio has been mapped | ||
| 197 | to the origin | ||
| 198 | #write hits : Number of times a WRITE bio has been mapped | ||
| 199 | to the cache | ||
| 200 | #write misses : Number of times a WRITE bio has been | ||
| 201 | mapped to the origin | ||
| 202 | #demotions : Number of times a block has been removed | ||
| 203 | from the cache | ||
| 204 | #promotions : Number of times a block has been moved to | ||
| 205 | the cache | ||
| 206 | #blocks in cache : Number of blocks resident in the cache | ||
| 207 | #dirty : Number of blocks in the cache that differ | ||
| 208 | from the origin | ||
| 209 | #feature args : Number of feature args to follow | ||
| 210 | feature args : 'writethrough' (optional) | ||
| 211 | #core args : Number of core arguments (must be even) | ||
| 212 | core args : Key/value pairs for tuning the core | ||
| 213 | e.g. migration_threshold | ||
| 214 | #policy args : Number of policy arguments to follow (must be even) | ||
| 215 | policy args : Key/value pairs | ||
| 216 | e.g. 'sequential_threshold 1024 | ||
| 217 | |||
| 218 | Messages | ||
| 219 | -------- | ||
| 220 | |||
| 221 | Policies will have different tunables, specific to each one, so we | ||
| 222 | need a generic way of getting and setting these. Device-mapper | ||
| 223 | messages are used. (A sysfs interface would also be possible.) | ||
| 224 | |||
| 225 | The message format is: | ||
| 226 | |||
| 227 | <key> <value> | ||
| 228 | |||
| 229 | E.g. | ||
| 230 | dmsetup message my_cache 0 sequential_threshold 1024 | ||
| 231 | |||
| 232 | Examples | ||
| 233 | ======== | ||
| 234 | |||
| 235 | The test suite can be found here: | ||
| 236 | |||
| 237 | https://github.com/jthornber/thinp-test-suite | ||
| 238 | |||
| 239 | dmsetup create my_cache --table '0 41943040 cache /dev/mapper/metadata \ | ||
| 240 | /dev/mapper/ssd /dev/mapper/origin 512 1 writeback default 0' | ||
| 241 | dmsetup create my_cache --table '0 41943040 cache /dev/mapper/metadata \ | ||
| 242 | /dev/mapper/ssd /dev/mapper/origin 1024 1 writeback \ | ||
| 243 | mq 4 sequential_threshold 1024 random_threshold 8' | ||
diff --git a/Documentation/device-mapper/dm-raid.txt b/Documentation/device-mapper/dm-raid.txt index 56fb62b09fc5..b428556197c9 100644 --- a/Documentation/device-mapper/dm-raid.txt +++ b/Documentation/device-mapper/dm-raid.txt | |||
| @@ -30,6 +30,7 @@ The target is named "raid" and it accepts the following parameters: | |||
| 30 | raid10 Various RAID10 inspired algorithms chosen by additional params | 30 | raid10 Various RAID10 inspired algorithms chosen by additional params |
| 31 | - RAID10: Striped Mirrors (aka 'Striping on top of mirrors') | 31 | - RAID10: Striped Mirrors (aka 'Striping on top of mirrors') |
| 32 | - RAID1E: Integrated Adjacent Stripe Mirroring | 32 | - RAID1E: Integrated Adjacent Stripe Mirroring |
| 33 | - RAID1E: Integrated Offset Stripe Mirroring | ||
| 33 | - and other similar RAID10 variants | 34 | - and other similar RAID10 variants |
| 34 | 35 | ||
| 35 | Reference: Chapter 4 of | 36 | Reference: Chapter 4 of |
| @@ -64,15 +65,15 @@ The target is named "raid" and it accepts the following parameters: | |||
| 64 | synchronisation state for each region. | 65 | synchronisation state for each region. |
| 65 | 66 | ||
| 66 | [raid10_copies <# copies>] | 67 | [raid10_copies <# copies>] |
| 67 | [raid10_format near] | 68 | [raid10_format <near|far|offset>] |
| 68 | These two options are used to alter the default layout of | 69 | These two options are used to alter the default layout of |
| 69 | a RAID10 configuration. The number of copies is can be | 70 | a RAID10 configuration. The number of copies is can be |
| 70 | specified, but the default is 2. There are other variations | 71 | specified, but the default is 2. There are also three |
| 71 | to how the copies are laid down - the default and only current | 72 | variations to how the copies are laid down - the default |
| 72 | option is "near". Near copies are what most people think of | 73 | is "near". Near copies are what most people think of with |
| 73 | with respect to mirroring. If these options are left | 74 | respect to mirroring. If these options are left unspecified, |
| 74 | unspecified, or 'raid10_copies 2' and/or 'raid10_format near' | 75 | or 'raid10_copies 2' and/or 'raid10_format near' are given, |
| 75 | are given, then the layouts for 2, 3 and 4 devices are: | 76 | then the layouts for 2, 3 and 4 devices are: |
| 76 | 2 drives 3 drives 4 drives | 77 | 2 drives 3 drives 4 drives |
| 77 | -------- ---------- -------------- | 78 | -------- ---------- -------------- |
| 78 | A1 A1 A1 A1 A2 A1 A1 A2 A2 | 79 | A1 A1 A1 A1 A2 A1 A1 A2 A2 |
| @@ -85,6 +86,33 @@ The target is named "raid" and it accepts the following parameters: | |||
| 85 | 3-device layout is what might be called a 'RAID1E - Integrated | 86 | 3-device layout is what might be called a 'RAID1E - Integrated |
| 86 | Adjacent Stripe Mirroring'. | 87 | Adjacent Stripe Mirroring'. |
| 87 | 88 | ||
| 89 | If 'raid10_copies 2' and 'raid10_format far', then the layouts | ||
| 90 | for 2, 3 and 4 devices are: | ||
| 91 | 2 drives 3 drives 4 drives | ||
| 92 | -------- -------------- -------------------- | ||
| 93 | A1 A2 A1 A2 A3 A1 A2 A3 A4 | ||
| 94 | A3 A4 A4 A5 A6 A5 A6 A7 A8 | ||
| 95 | A5 A6 A7 A8 A9 A9 A10 A11 A12 | ||
| 96 | .. .. .. .. .. .. .. .. .. | ||
| 97 | A2 A1 A3 A1 A2 A2 A1 A4 A3 | ||
| 98 | A4 A3 A6 A4 A5 A6 A5 A8 A7 | ||
| 99 | A6 A5 A9 A7 A8 A10 A9 A12 A11 | ||
| 100 | .. .. .. .. .. .. .. .. .. | ||
| 101 | |||
| 102 | If 'raid10_copies 2' and 'raid10_format offset', then the | ||
| 103 | layouts for 2, 3 and 4 devices are: | ||
| 104 | 2 drives 3 drives 4 drives | ||
| 105 | -------- ------------ ----------------- | ||
| 106 | A1 A2 A1 A2 A3 A1 A2 A3 A4 | ||
| 107 | A2 A1 A3 A1 A2 A2 A1 A4 A3 | ||
| 108 | A3 A4 A4 A5 A6 A5 A6 A7 A8 | ||
| 109 | A4 A3 A6 A4 A5 A6 A5 A8 A7 | ||
| 110 | A5 A6 A7 A8 A9 A9 A10 A11 A12 | ||
| 111 | A6 A5 A9 A7 A8 A10 A9 A12 A11 | ||
| 112 | .. .. .. .. .. .. .. .. .. | ||
| 113 | Here we see layouts closely akin to 'RAID1E - Integrated | ||
| 114 | Offset Stripe Mirroring'. | ||
| 115 | |||
| 88 | <#raid_devs>: The number of devices composing the array. | 116 | <#raid_devs>: The number of devices composing the array. |
| 89 | Each device consists of two entries. The first is the device | 117 | Each device consists of two entries. The first is the device |
| 90 | containing the metadata (if any); the second is the one containing the | 118 | containing the metadata (if any); the second is the one containing the |
| @@ -142,3 +170,5 @@ Version History | |||
| 142 | 1.3.0 Added support for RAID 10 | 170 | 1.3.0 Added support for RAID 10 |
| 143 | 1.3.1 Allow device replacement/rebuild for RAID 10 | 171 | 1.3.1 Allow device replacement/rebuild for RAID 10 |
| 144 | 1.3.2 Fix/improve redundancy checking for RAID10 | 172 | 1.3.2 Fix/improve redundancy checking for RAID10 |
| 173 | 1.4.0 Non-functional change. Removes arg from mapping function. | ||
| 174 | 1.4.1 Add RAID10 "far" and "offset" algorithm support. | ||
diff --git a/Documentation/devicetree/bindings/arc/interrupts.txt b/Documentation/devicetree/bindings/arc/interrupts.txt new file mode 100644 index 000000000000..9a5d562435ea --- /dev/null +++ b/Documentation/devicetree/bindings/arc/interrupts.txt | |||
| @@ -0,0 +1,24 @@ | |||
| 1 | * ARC700 incore Interrupt Controller | ||
| 2 | |||
| 3 | The core interrupt controller provides 32 prioritised interrupts (2 levels) | ||
| 4 | to ARC700 core. | ||
| 5 | |||
| 6 | Properties: | ||
| 7 | |||
| 8 | - compatible: "snps,arc700-intc" | ||
| 9 | - interrupt-controller: This is an interrupt controller. | ||
| 10 | - #interrupt-cells: Must be <1>. | ||
| 11 | |||
| 12 | Single Cell "interrupts" property of a device specifies the IRQ number | ||
| 13 | between 0 to 31 | ||
| 14 | |||
| 15 | intc accessed via the special ARC AUX register interface, hence "reg" property | ||
| 16 | is not specified. | ||
| 17 | |||
| 18 | Example: | ||
| 19 | |||
| 20 | intc: interrupt-controller { | ||
| 21 | compatible = "snps,arc700-intc"; | ||
| 22 | interrupt-controller; | ||
| 23 | #interrupt-cells = <1>; | ||
| 24 | }; | ||
diff --git a/Documentation/devicetree/bindings/arm/armadeus.txt b/Documentation/devicetree/bindings/arm/armadeus.txt new file mode 100644 index 000000000000..9821283ff516 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/armadeus.txt | |||
| @@ -0,0 +1,6 @@ | |||
| 1 | Armadeus i.MX Platforms Device Tree Bindings | ||
| 2 | ----------------------------------------------- | ||
| 3 | |||
| 4 | APF51: i.MX51 based module. | ||
| 5 | Required root node properties: | ||
| 6 | - compatible = "armadeus,imx51-apf51", "fsl,imx51"; | ||
diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt index f79818711e83..e935d7d4ac43 100644 --- a/Documentation/devicetree/bindings/arm/fsl.txt +++ b/Documentation/devicetree/bindings/arm/fsl.txt | |||
| @@ -5,6 +5,14 @@ i.MX23 Evaluation Kit | |||
| 5 | Required root node properties: | 5 | Required root node properties: |
| 6 | - compatible = "fsl,imx23-evk", "fsl,imx23"; | 6 | - compatible = "fsl,imx23-evk", "fsl,imx23"; |
| 7 | 7 | ||
| 8 | i.MX25 Product Development Kit | ||
| 9 | Required root node properties: | ||
| 10 | - compatible = "fsl,imx25-pdk", "fsl,imx25"; | ||
| 11 | |||
| 12 | i.MX27 Product Development Kit | ||
| 13 | Required root node properties: | ||
| 14 | - compatible = "fsl,imx27-pdk", "fsl,imx27"; | ||
| 15 | |||
| 8 | i.MX28 Evaluation Kit | 16 | i.MX28 Evaluation Kit |
| 9 | Required root node properties: | 17 | Required root node properties: |
| 10 | - compatible = "fsl,imx28-evk", "fsl,imx28"; | 18 | - compatible = "fsl,imx28-evk", "fsl,imx28"; |
diff --git a/Documentation/devicetree/bindings/clock/imx5-clock.txt b/Documentation/devicetree/bindings/clock/imx5-clock.txt index 04ad47876be0..2a0c904c46ae 100644 --- a/Documentation/devicetree/bindings/clock/imx5-clock.txt +++ b/Documentation/devicetree/bindings/clock/imx5-clock.txt | |||
| @@ -171,6 +171,7 @@ clocks and IDs. | |||
| 171 | can_sel 156 | 171 | can_sel 156 |
| 172 | can1_serial_gate 157 | 172 | can1_serial_gate 157 |
| 173 | can1_ipg_gate 158 | 173 | can1_ipg_gate 158 |
| 174 | owire_gate 159 | ||
| 174 | 175 | ||
| 175 | Examples (for mx53): | 176 | Examples (for mx53): |
| 176 | 177 | ||
diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt index f73fdf595568..969b38e06ad3 100644 --- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt +++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt | |||
| @@ -203,6 +203,8 @@ clocks and IDs. | |||
| 203 | pcie_ref 188 | 203 | pcie_ref 188 |
| 204 | pcie_ref_125m 189 | 204 | pcie_ref_125m 189 |
| 205 | enet_ref 190 | 205 | enet_ref 190 |
| 206 | usbphy1_gate 191 | ||
| 207 | usbphy2_gate 192 | ||
| 206 | 208 | ||
| 207 | Examples: | 209 | Examples: |
| 208 | 210 | ||
diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt index 6d21c0288e9e..e4022776ac6e 100644 --- a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt +++ b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt | |||
| @@ -113,7 +113,7 @@ PROPERTIES | |||
| 113 | EXAMPLE | 113 | EXAMPLE |
| 114 | crypto@300000 { | 114 | crypto@300000 { |
| 115 | compatible = "fsl,sec-v4.0"; | 115 | compatible = "fsl,sec-v4.0"; |
| 116 | fsl,sec-era = <0x2>; | 116 | fsl,sec-era = <2>; |
| 117 | #address-cells = <1>; | 117 | #address-cells = <1>; |
| 118 | #size-cells = <1>; | 118 | #size-cells = <1>; |
| 119 | reg = <0x300000 0x10000>; | 119 | reg = <0x300000 0x10000>; |
diff --git a/Documentation/devicetree/bindings/dma/arm-pl330.txt b/Documentation/devicetree/bindings/dma/arm-pl330.txt index 36e27d54260b..267565894db9 100644 --- a/Documentation/devicetree/bindings/dma/arm-pl330.txt +++ b/Documentation/devicetree/bindings/dma/arm-pl330.txt | |||
| @@ -10,7 +10,11 @@ Required properties: | |||
| 10 | - interrupts: interrupt number to the cpu. | 10 | - interrupts: interrupt number to the cpu. |
| 11 | 11 | ||
| 12 | Optional properties: | 12 | Optional properties: |
| 13 | - dma-coherent : Present if dma operations are coherent | 13 | - dma-coherent : Present if dma operations are coherent |
| 14 | - #dma-cells: must be <1>. used to represent the number of integer | ||
| 15 | cells in the dmas property of client device. | ||
| 16 | - dma-channels: contains the total number of DMA channels supported by the DMAC | ||
| 17 | - dma-requests: contains the total number of DMA requests supported by the DMAC | ||
| 14 | 18 | ||
| 15 | Example: | 19 | Example: |
| 16 | 20 | ||
| @@ -18,16 +22,23 @@ Example: | |||
| 18 | compatible = "arm,pl330", "arm,primecell"; | 22 | compatible = "arm,pl330", "arm,primecell"; |
| 19 | reg = <0x12680000 0x1000>; | 23 | reg = <0x12680000 0x1000>; |
| 20 | interrupts = <99>; | 24 | interrupts = <99>; |
| 25 | #dma-cells = <1>; | ||
| 26 | #dma-channels = <8>; | ||
| 27 | #dma-requests = <32>; | ||
| 21 | }; | 28 | }; |
| 22 | 29 | ||
| 23 | Client drivers (device nodes requiring dma transfers from dev-to-mem or | 30 | Client drivers (device nodes requiring dma transfers from dev-to-mem or |
| 24 | mem-to-dev) should specify the DMA channel numbers using a two-value pair | 31 | mem-to-dev) should specify the DMA channel numbers and dma channel names |
| 25 | as shown below. | 32 | as shown below. |
| 26 | 33 | ||
| 27 | [property name] = <[phandle of the dma controller] [dma request id]>; | 34 | [property name] = <[phandle of the dma controller] [dma request id]>; |
| 35 | [property name] = <[dma channel name]> | ||
| 28 | 36 | ||
| 29 | where 'dma request id' is the dma request number which is connected | 37 | where 'dma request id' is the dma request number which is connected |
| 30 | to the client controller. The 'property name' is recommended to be | 38 | to the client controller. The 'property name' 'dmas' and 'dma-names' |
| 31 | of the form <name>-dma-channel. | 39 | as required by the generic dma device tree binding helpers. The dma |
| 40 | names correspond 1:1 with the dma request ids in the dmas property. | ||
| 32 | 41 | ||
| 33 | Example: tx-dma-channel = <&pdma0 12>; | 42 | Example: dmas = <&pdma0 12 |
| 43 | &pdma1 11>; | ||
| 44 | dma-names = "tx", "rx"; | ||
diff --git a/Documentation/devicetree/bindings/dma/dma.txt b/Documentation/devicetree/bindings/dma/dma.txt new file mode 100644 index 000000000000..8f504e6bae14 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/dma.txt | |||
| @@ -0,0 +1,81 @@ | |||
| 1 | * Generic DMA Controller and DMA request bindings | ||
| 2 | |||
| 3 | Generic binding to provide a way for a driver using DMA Engine to retrieve the | ||
| 4 | DMA request or channel information that goes from a hardware device to a DMA | ||
| 5 | controller. | ||
| 6 | |||
| 7 | |||
| 8 | * DMA controller | ||
| 9 | |||
| 10 | Required property: | ||
| 11 | - #dma-cells: Must be at least 1. Used to provide DMA controller | ||
| 12 | specific information. See DMA client binding below for | ||
| 13 | more details. | ||
| 14 | |||
| 15 | Optional properties: | ||
| 16 | - dma-channels: Number of DMA channels supported by the controller. | ||
| 17 | - dma-requests: Number of DMA requests signals supported by the | ||
| 18 | controller. | ||
| 19 | |||
| 20 | Example: | ||
| 21 | |||
| 22 | dma: dma@48000000 { | ||
| 23 | compatible = "ti,omap-sdma"; | ||
| 24 | reg = <0x48000000 0x1000>; | ||
| 25 | interrupts = <0 12 0x4 | ||
| 26 | 0 13 0x4 | ||
| 27 | 0 14 0x4 | ||
| 28 | 0 15 0x4>; | ||
| 29 | #dma-cells = <1>; | ||
| 30 | dma-channels = <32>; | ||
| 31 | dma-requests = <127>; | ||
| 32 | }; | ||
| 33 | |||
| 34 | |||
| 35 | * DMA client | ||
| 36 | |||
| 37 | Client drivers should specify the DMA property using a phandle to the controller | ||
| 38 | followed by DMA controller specific data. | ||
| 39 | |||
| 40 | Required property: | ||
| 41 | - dmas: List of one or more DMA specifiers, each consisting of | ||
| 42 | - A phandle pointing to DMA controller node | ||
| 43 | - A number of integer cells, as determined by the | ||
| 44 | #dma-cells property in the node referenced by phandle | ||
| 45 | containing DMA controller specific information. This | ||
| 46 | typically contains a DMA request line number or a | ||
| 47 | channel number, but can contain any data that is used | ||
| 48 | required for configuring a channel. | ||
| 49 | - dma-names: Contains one identifier string for each DMA specifier in | ||
| 50 | the dmas property. The specific strings that can be used | ||
| 51 | are defined in the binding of the DMA client device. | ||
| 52 | Multiple DMA specifiers can be used to represent | ||
| 53 | alternatives and in this case the dma-names for those | ||
| 54 | DMA specifiers must be identical (see examples). | ||
| 55 | |||
| 56 | Examples: | ||
| 57 | |||
| 58 | 1. A device with one DMA read channel, one DMA write channel: | ||
| 59 | |||
| 60 | i2c1: i2c@1 { | ||
| 61 | ... | ||
| 62 | dmas = <&dma 2 /* read channel */ | ||
| 63 | &dma 3>; /* write channel */ | ||
| 64 | dma-names = "rx", "tx"; | ||
| 65 | ... | ||
| 66 | }; | ||
| 67 | |||
| 68 | 2. A single read-write channel with three alternative DMA controllers: | ||
| 69 | |||
| 70 | dmas = <&dma1 5 | ||
| 71 | &dma2 7 | ||
| 72 | &dma3 2>; | ||
| 73 | dma-names = "rx-tx", "rx-tx", "rx-tx"; | ||
| 74 | |||
| 75 | 3. A device with three channels, one of which has two alternatives: | ||
| 76 | |||
| 77 | dmas = <&dma1 2 /* read channel */ | ||
| 78 | &dma1 3 /* write channel */ | ||
| 79 | &dma2 0 /* error read */ | ||
| 80 | &dma3 0>; /* alternative error read */ | ||
| 81 | dma-names = "rx", "tx", "error", "error"; | ||
diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt b/Documentation/devicetree/bindings/dma/snps-dma.txt index c0d85dbcada5..d58675ea1abf 100644 --- a/Documentation/devicetree/bindings/dma/snps-dma.txt +++ b/Documentation/devicetree/bindings/dma/snps-dma.txt | |||
| @@ -3,15 +3,61 @@ | |||
| 3 | Required properties: | 3 | Required properties: |
| 4 | - compatible: "snps,dma-spear1340" | 4 | - compatible: "snps,dma-spear1340" |
| 5 | - reg: Address range of the DMAC registers | 5 | - reg: Address range of the DMAC registers |
| 6 | - interrupt: Should contain the DMAC interrupt number | ||
| 7 | - dma-channels: Number of channels supported by hardware | ||
| 8 | - dma-requests: Number of DMA request lines supported, up to 16 | ||
| 9 | - dma-masters: Number of AHB masters supported by the controller | ||
| 10 | - #dma-cells: must be <3> | ||
| 11 | - chan_allocation_order: order of allocation of channel, 0 (default): ascending, | ||
| 12 | 1: descending | ||
| 13 | - chan_priority: priority of channels. 0 (default): increase from chan 0->n, 1: | ||
| 14 | increase from chan n->0 | ||
| 15 | - block_size: Maximum block size supported by the controller | ||
| 16 | - data_width: Maximum data width supported by hardware per AHB master | ||
| 17 | (0 - 8bits, 1 - 16bits, ..., 5 - 256bits) | ||
| 18 | |||
| 19 | |||
| 20 | Optional properties: | ||
| 6 | - interrupt-parent: Should be the phandle for the interrupt controller | 21 | - interrupt-parent: Should be the phandle for the interrupt controller |
| 7 | that services interrupts for this device | 22 | that services interrupts for this device |
| 8 | - interrupt: Should contain the DMAC interrupt number | 23 | - is_private: The device channels should be marked as private and not for by the |
| 24 | general purpose DMA channel allocator. False if not passed. | ||
| 9 | 25 | ||
| 10 | Example: | 26 | Example: |
| 11 | 27 | ||
| 12 | dma@fc000000 { | 28 | dmahost: dma@fc000000 { |
| 13 | compatible = "snps,dma-spear1340"; | 29 | compatible = "snps,dma-spear1340"; |
| 14 | reg = <0xfc000000 0x1000>; | 30 | reg = <0xfc000000 0x1000>; |
| 15 | interrupt-parent = <&vic1>; | 31 | interrupt-parent = <&vic1>; |
| 16 | interrupts = <12>; | 32 | interrupts = <12>; |
| 33 | |||
| 34 | dma-channels = <8>; | ||
| 35 | dma-requests = <16>; | ||
| 36 | dma-masters = <2>; | ||
| 37 | #dma-cells = <3>; | ||
| 38 | chan_allocation_order = <1>; | ||
| 39 | chan_priority = <1>; | ||
| 40 | block_size = <0xfff>; | ||
| 41 | data_width = <3 3 0 0>; | ||
| 42 | }; | ||
| 43 | |||
| 44 | DMA clients connected to the Designware DMA controller must use the format | ||
| 45 | described in the dma.txt file, using a four-cell specifier for each channel. | ||
| 46 | The four cells in order are: | ||
| 47 | |||
| 48 | 1. A phandle pointing to the DMA controller | ||
| 49 | 2. The DMA request line number | ||
| 50 | 3. Source master for transfers on allocated channel | ||
| 51 | 4. Destination master for transfers on allocated channel | ||
| 52 | |||
| 53 | Example: | ||
| 54 | |||
| 55 | serial@e0000000 { | ||
| 56 | compatible = "arm,pl011", "arm,primecell"; | ||
| 57 | reg = <0xe0000000 0x1000>; | ||
| 58 | interrupts = <0 35 0x4>; | ||
| 59 | status = "disabled"; | ||
| 60 | dmas = <&dmahost 12 0 1>, | ||
| 61 | <&dmahost 13 0 1 0>; | ||
| 62 | dma-names = "rx", "rx"; | ||
| 17 | }; | 63 | }; |
diff --git a/Documentation/devicetree/bindings/drm/tilcdc/panel.txt b/Documentation/devicetree/bindings/drm/tilcdc/panel.txt new file mode 100644 index 000000000000..9301c330d1a6 --- /dev/null +++ b/Documentation/devicetree/bindings/drm/tilcdc/panel.txt | |||
| @@ -0,0 +1,59 @@ | |||
| 1 | Device-Tree bindings for tilcdc DRM generic panel output driver | ||
| 2 | |||
| 3 | Required properties: | ||
| 4 | - compatible: value should be "ti,tilcdc,panel". | ||
| 5 | - panel-info: configuration info to configure LCDC correctly for the panel | ||
| 6 | - ac-bias: AC Bias Pin Frequency | ||
| 7 | - ac-bias-intrpt: AC Bias Pin Transitions per Interrupt | ||
| 8 | - dma-burst-sz: DMA burst size | ||
| 9 | - bpp: Bits per pixel | ||
| 10 | - fdd: FIFO DMA Request Delay | ||
| 11 | - sync-edge: Horizontal and Vertical Sync Edge: 0=rising 1=falling | ||
| 12 | - sync-ctrl: Horizontal and Vertical Sync: Control: 0=ignore | ||
| 13 | - raster-order: Raster Data Order Select: 1=Most-to-least 0=Least-to-most | ||
| 14 | - fifo-th: DMA FIFO threshold | ||
| 15 | - display-timings: typical videomode of lcd panel. Multiple video modes | ||
| 16 | can be listed if the panel supports multiple timings, but the 'native-mode' | ||
| 17 | should be the preferred/default resolution. Refer to | ||
| 18 | Documentation/devicetree/bindings/video/display-timing.txt for display | ||
| 19 | timing binding details. | ||
| 20 | |||
| 21 | Recommended properties: | ||
| 22 | - pinctrl-names, pinctrl-0: the pincontrol settings to configure | ||
| 23 | muxing properly for pins that connect to TFP410 device | ||
| 24 | |||
| 25 | Example: | ||
| 26 | |||
| 27 | /* Settings for CDTech_S035Q01 / LCD3 cape: */ | ||
| 28 | lcd3 { | ||
| 29 | compatible = "ti,tilcdc,panel"; | ||
| 30 | pinctrl-names = "default"; | ||
| 31 | pinctrl-0 = <&bone_lcd3_cape_lcd_pins>; | ||
| 32 | panel-info { | ||
| 33 | ac-bias = <255>; | ||
| 34 | ac-bias-intrpt = <0>; | ||
| 35 | dma-burst-sz = <16>; | ||
| 36 | bpp = <16>; | ||
| 37 | fdd = <0x80>; | ||
| 38 | sync-edge = <0>; | ||
| 39 | sync-ctrl = <1>; | ||
| 40 | raster-order = <0>; | ||
| 41 | fifo-th = <0>; | ||
| 42 | }; | ||
| 43 | display-timings { | ||
| 44 | native-mode = <&timing0>; | ||
| 45 | timing0: 320x240 { | ||
| 46 | hactive = <320>; | ||
| 47 | vactive = <240>; | ||
| 48 | hback-porch = <21>; | ||
| 49 | hfront-porch = <58>; | ||
| 50 | hsync-len = <47>; | ||
| 51 | vback-porch = <11>; | ||
| 52 | vfront-porch = <23>; | ||
| 53 | vsync-len = <2>; | ||
| 54 | clock-frequency = <8000000>; | ||
| 55 | hsync-active = <0>; | ||
| 56 | vsync-active = <0>; | ||
| 57 | }; | ||
| 58 | }; | ||
| 59 | }; | ||
diff --git a/Documentation/devicetree/bindings/drm/tilcdc/slave.txt b/Documentation/devicetree/bindings/drm/tilcdc/slave.txt new file mode 100644 index 000000000000..3d2c52460dca --- /dev/null +++ b/Documentation/devicetree/bindings/drm/tilcdc/slave.txt | |||
| @@ -0,0 +1,18 @@ | |||
| 1 | Device-Tree bindings for tilcdc DRM encoder slave output driver | ||
| 2 | |||
| 3 | Required properties: | ||
| 4 | - compatible: value should be "ti,tilcdc,slave". | ||
| 5 | - i2c: the phandle for the i2c device the encoder slave is connected to | ||
| 6 | |||
| 7 | Recommended properties: | ||
| 8 | - pinctrl-names, pinctrl-0: the pincontrol settings to configure | ||
| 9 | muxing properly for pins that connect to TFP410 device | ||
| 10 | |||
| 11 | Example: | ||
| 12 | |||
| 13 | hdmi { | ||
| 14 | compatible = "ti,tilcdc,slave"; | ||
| 15 | i2c = <&i2c0>; | ||
| 16 | pinctrl-names = "default"; | ||
| 17 | pinctrl-0 = <&nxp_hdmi_bonelt_pins>; | ||
| 18 | }; | ||
diff --git a/Documentation/devicetree/bindings/drm/tilcdc/tfp410.txt b/Documentation/devicetree/bindings/drm/tilcdc/tfp410.txt new file mode 100644 index 000000000000..a58ae7756fc6 --- /dev/null +++ b/Documentation/devicetree/bindings/drm/tilcdc/tfp410.txt | |||
| @@ -0,0 +1,21 @@ | |||
| 1 | Device-Tree bindings for tilcdc DRM TFP410 output driver | ||
| 2 | |||
| 3 | Required properties: | ||
| 4 | - compatible: value should be "ti,tilcdc,tfp410". | ||
| 5 | - i2c: the phandle for the i2c device to use for DDC | ||
| 6 | |||
| 7 | Recommended properties: | ||
| 8 | - pinctrl-names, pinctrl-0: the pincontrol settings to configure | ||
| 9 | muxing properly for pins that connect to TFP410 device | ||
| 10 | - powerdn-gpio: the powerdown GPIO, pulled low to power down the | ||
| 11 | TFP410 device (for DPMS_OFF) | ||
| 12 | |||
| 13 | Example: | ||
| 14 | |||
| 15 | dvicape { | ||
| 16 | compatible = "ti,tilcdc,tfp410"; | ||
| 17 | i2c = <&i2c2>; | ||
| 18 | pinctrl-names = "default"; | ||
| 19 | pinctrl-0 = <&bone_dvi_cape_dvi_00A1_pins>; | ||
| 20 | powerdn-gpio = <&gpio2 31 0>; | ||
| 21 | }; | ||
diff --git a/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt new file mode 100644 index 000000000000..e5f130159ae1 --- /dev/null +++ b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt | |||
| @@ -0,0 +1,21 @@ | |||
| 1 | Device-Tree bindings for tilcdc DRM driver | ||
| 2 | |||
| 3 | Required properties: | ||
| 4 | - compatible: value should be "ti,am33xx-tilcdc". | ||
| 5 | - interrupts: the interrupt number | ||
| 6 | - reg: base address and size of the LCDC device | ||
| 7 | |||
| 8 | Recommended properties: | ||
| 9 | - interrupt-parent: the phandle for the interrupt controller that | ||
| 10 | services interrupts for this device. | ||
| 11 | - ti,hwmods: Name of the hwmod associated to the LCDC | ||
| 12 | |||
| 13 | Example: | ||
| 14 | |||
| 15 | fb: fb@4830e000 { | ||
| 16 | compatible = "ti,am33xx-tilcdc"; | ||
| 17 | reg = <0x4830e000 0x1000>; | ||
| 18 | interrupt-parent = <&intc>; | ||
| 19 | interrupts = <36>; | ||
| 20 | ti,hwmods = "lcdc"; | ||
| 21 | }; | ||
diff --git a/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt b/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt new file mode 100644 index 000000000000..e9de3756752b --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/brcm,bcm2835-i2c.txt | |||
| @@ -0,0 +1,20 @@ | |||
| 1 | Broadcom BCM2835 I2C controller | ||
| 2 | |||
| 3 | Required properties: | ||
| 4 | - compatible : Should be "brcm,bcm2835-i2c". | ||
| 5 | - reg: Should contain register location and length. | ||
| 6 | - interrupts: Should contain interrupt. | ||
| 7 | - clocks : The clock feeding the I2C controller. | ||
| 8 | |||
| 9 | Recommended properties: | ||
| 10 | - clock-frequency : desired I2C bus clock frequency in Hz. | ||
| 11 | |||
| 12 | Example: | ||
| 13 | |||
| 14 | i2c@20205000 { | ||
| 15 | compatible = "brcm,bcm2835-i2c"; | ||
| 16 | reg = <0x7e205000 0x1000>; | ||
| 17 | interrupts = <2 21>; | ||
| 18 | clocks = <&clk_i2c>; | ||
| 19 | clock-frequency = <100000>; | ||
| 20 | }; | ||
diff --git a/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt b/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt index e9611ace8792..f98d4c5b5cca 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt | |||
| @@ -8,6 +8,8 @@ Required properties: | |||
| 8 | (b) "samsung, s3c2440-i2c", for i2c compatible with s3c2440 i2c. | 8 | (b) "samsung, s3c2440-i2c", for i2c compatible with s3c2440 i2c. |
| 9 | (c) "samsung, s3c2440-hdmiphy-i2c", for s3c2440-like i2c used | 9 | (c) "samsung, s3c2440-hdmiphy-i2c", for s3c2440-like i2c used |
| 10 | inside HDMIPHY block found on several samsung SoCs | 10 | inside HDMIPHY block found on several samsung SoCs |
| 11 | (d) "samsung, exynos5440-i2c", for s3c2440-like i2c used | ||
| 12 | on EXYNOS5440 which does not need GPIO configuration. | ||
| 11 | - reg: physical base address of the controller and length of memory mapped | 13 | - reg: physical base address of the controller and length of memory mapped |
| 12 | region. | 14 | region. |
| 13 | - interrupts: interrupt number to the cpu. | 15 | - interrupts: interrupt number to the cpu. |
diff --git a/Documentation/devicetree/bindings/leds/leds-pwm.txt b/Documentation/devicetree/bindings/leds/leds-pwm.txt new file mode 100644 index 000000000000..7297107cf832 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/leds-pwm.txt | |||
| @@ -0,0 +1,48 @@ | |||
| 1 | LED connected to PWM | ||
| 2 | |||
| 3 | Required properties: | ||
| 4 | - compatible : should be "pwm-leds". | ||
| 5 | |||
| 6 | Each LED is represented as a sub-node of the pwm-leds device. Each | ||
| 7 | node's name represents the name of the corresponding LED. | ||
| 8 | |||
| 9 | LED sub-node properties: | ||
| 10 | - pwms : PWM property to point to the PWM device (phandle)/port (id) and to | ||
| 11 | specify the period time to be used: <&phandle id period_ns>; | ||
| 12 | - pwm-names : (optional) Name to be used by the PWM subsystem for the PWM device | ||
| 13 | For the pwms and pwm-names property please refer to: | ||
| 14 | Documentation/devicetree/bindings/pwm/pwm.txt | ||
| 15 | - max-brightness : Maximum brightness possible for the LED | ||
| 16 | - label : (optional) | ||
| 17 | see Documentation/devicetree/bindings/leds/common.txt | ||
| 18 | - linux,default-trigger : (optional) | ||
| 19 | see Documentation/devicetree/bindings/leds/common.txt | ||
| 20 | |||
| 21 | Example: | ||
| 22 | |||
| 23 | twl_pwm: pwm { | ||
| 24 | /* provides two PWMs (id 0, 1 for PWM1 and PWM2) */ | ||
| 25 | compatible = "ti,twl6030-pwm"; | ||
| 26 | #pwm-cells = <2>; | ||
| 27 | }; | ||
| 28 | |||
| 29 | twl_pwmled: pwmled { | ||
| 30 | /* provides one PWM (id 0 for Charing indicator LED) */ | ||
| 31 | compatible = "ti,twl6030-pwmled"; | ||
| 32 | #pwm-cells = <2>; | ||
| 33 | }; | ||
| 34 | |||
| 35 | pwmleds { | ||
| 36 | compatible = "pwm-leds"; | ||
| 37 | kpad { | ||
| 38 | label = "omap4::keypad"; | ||
| 39 | pwms = <&twl_pwm 0 7812500>; | ||
| 40 | max-brightness = <127>; | ||
| 41 | }; | ||
| 42 | |||
| 43 | charging { | ||
| 44 | label = "omap4:green:chrg"; | ||
| 45 | pwms = <&twl_pwmled 0 7812500>; | ||
| 46 | max-brightness = <255>; | ||
| 47 | }; | ||
| 48 | }; | ||
diff --git a/Documentation/devicetree/bindings/leds/tca6507.txt b/Documentation/devicetree/bindings/leds/tca6507.txt new file mode 100644 index 000000000000..2b6693b972fb --- /dev/null +++ b/Documentation/devicetree/bindings/leds/tca6507.txt | |||
| @@ -0,0 +1,33 @@ | |||
| 1 | LEDs conected to tca6507 | ||
| 2 | |||
| 3 | Required properties: | ||
| 4 | - compatible : should be : "ti,tca6507". | ||
| 5 | |||
| 6 | Each led is represented as a sub-node of the ti,tca6507 device. | ||
| 7 | |||
| 8 | LED sub-node properties: | ||
| 9 | - label : (optional) see Documentation/devicetree/bindings/leds/common.txt | ||
| 10 | - reg : number of LED line (could be from 0 to 6) | ||
| 11 | - linux,default-trigger : (optional) | ||
| 12 | see Documentation/devicetree/bindings/leds/common.txt | ||
| 13 | |||
| 14 | Examples: | ||
| 15 | |||
| 16 | tca6507@45 { | ||
| 17 | compatible = "ti,tca6507"; | ||
| 18 | #address-cells = <1>; | ||
| 19 | #size-cells = <0>; | ||
| 20 | reg = <0x45>; | ||
| 21 | |||
| 22 | led0: red-aux@0 { | ||
| 23 | label = "red:aux"; | ||
| 24 | reg = <0x0>; | ||
| 25 | }; | ||
| 26 | |||
| 27 | led1: green-aux@1 { | ||
| 28 | label = "green:aux"; | ||
| 29 | reg = <0x5>; | ||
| 30 | linux,default-trigger = "default-on"; | ||
| 31 | }; | ||
| 32 | }; | ||
| 33 | |||
diff --git a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt new file mode 100644 index 000000000000..56e726ef4bf2 --- /dev/null +++ b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt | |||
| @@ -0,0 +1,16 @@ | |||
| 1 | Device-Tree bindings for GPIO IR receiver | ||
| 2 | |||
| 3 | Required properties: | ||
| 4 | - compatible: should be "gpio-ir-receiver". | ||
| 5 | - gpios: specifies GPIO used for IR signal reception. | ||
| 6 | |||
| 7 | Optional properties: | ||
| 8 | - linux,rc-map-name: Linux specific remote control map name. | ||
| 9 | |||
| 10 | Example node: | ||
| 11 | |||
| 12 | ir: ir-receiver { | ||
| 13 | compatible = "gpio-ir-receiver"; | ||
| 14 | gpios = <&gpio0 19 1>; | ||
| 15 | linux,rc-map-name = "rc-rc6-mce"; | ||
| 16 | }; | ||
diff --git a/Documentation/devicetree/bindings/metag/meta-intc.txt b/Documentation/devicetree/bindings/metag/meta-intc.txt new file mode 100644 index 000000000000..8c47dcbfabc6 --- /dev/null +++ b/Documentation/devicetree/bindings/metag/meta-intc.txt | |||
| @@ -0,0 +1,82 @@ | |||
| 1 | * Meta External Trigger Controller Binding | ||
| 2 | |||
| 3 | This binding specifies what properties must be available in the device tree | ||
| 4 | representation of a Meta external trigger controller. | ||
| 5 | |||
| 6 | Required properties: | ||
| 7 | |||
| 8 | - compatible: Specifies the compatibility list for the interrupt controller. | ||
| 9 | The type shall be <string> and the value shall include "img,meta-intc". | ||
| 10 | |||
| 11 | - num-banks: Specifies the number of interrupt banks (each of which can | ||
| 12 | handle 32 interrupt sources). | ||
| 13 | |||
| 14 | - interrupt-controller: The presence of this property identifies the node | ||
| 15 | as an interupt controller. No property value shall be defined. | ||
| 16 | |||
| 17 | - #interrupt-cells: Specifies the number of cells needed to encode an | ||
| 18 | interrupt source. The type shall be a <u32> and the value shall be 2. | ||
| 19 | |||
| 20 | - #address-cells: Specifies the number of cells needed to encode an | ||
| 21 | address. The type shall be <u32> and the value shall be 0. As such, | ||
| 22 | 'interrupt-map' nodes do not have to specify a parent unit address. | ||
| 23 | |||
| 24 | Optional properties: | ||
| 25 | |||
| 26 | - no-mask: The controller doesn't have any mask registers. | ||
| 27 | |||
| 28 | * Interrupt Specifier Definition | ||
| 29 | |||
| 30 | Interrupt specifiers consists of 2 cells encoded as follows: | ||
| 31 | |||
| 32 | - <1st-cell>: The interrupt-number that identifies the interrupt source. | ||
| 33 | |||
| 34 | - <2nd-cell>: The Linux interrupt flags containing level-sense information, | ||
| 35 | encoded as follows: | ||
| 36 | 1 = edge triggered | ||
| 37 | 4 = level-sensitive | ||
| 38 | |||
| 39 | * Examples | ||
| 40 | |||
| 41 | Example 1: | ||
| 42 | |||
| 43 | /* | ||
| 44 | * Meta external trigger block | ||
| 45 | */ | ||
| 46 | intc: intc { | ||
| 47 | // This is an interrupt controller node. | ||
| 48 | interrupt-controller; | ||
| 49 | |||
| 50 | // No address cells so that 'interrupt-map' nodes which | ||
| 51 | // reference this interrupt controller node do not need a parent | ||
| 52 | // address specifier. | ||
| 53 | #address-cells = <0>; | ||
| 54 | |||
| 55 | // Two cells to encode interrupt sources. | ||
| 56 | #interrupt-cells = <2>; | ||
| 57 | |||
| 58 | // Number of interrupt banks | ||
| 59 | num-banks = <2>; | ||
| 60 | |||
| 61 | // No HWMASKEXT is available (specify on Chorus2 and Comet ES1) | ||
| 62 | no-mask; | ||
| 63 | |||
| 64 | // Compatible with Meta hardware trigger block. | ||
| 65 | compatible = "img,meta-intc"; | ||
| 66 | }; | ||
| 67 | |||
| 68 | Example 2: | ||
| 69 | |||
| 70 | /* | ||
| 71 | * An interrupt generating device that is wired to a Meta external | ||
| 72 | * trigger block. | ||
| 73 | */ | ||
| 74 | uart1: uart@0x02004c00 { | ||
| 75 | // Interrupt source '5' that is level-sensitive. | ||
| 76 | // Note that there are only two cells as specified in the | ||
| 77 | // interrupt parent's '#interrupt-cells' property. | ||
| 78 | interrupts = <5 4 /* level */>; | ||
| 79 | |||
| 80 | // The interrupt controller that this device is wired to. | ||
| 81 | interrupt-parent = <&intc>; | ||
| 82 | }; | ||
diff --git a/Documentation/devicetree/bindings/mfd/ab8500.txt b/Documentation/devicetree/bindings/mfd/ab8500.txt index 13b707b7355c..c3a14e0ad0ad 100644 --- a/Documentation/devicetree/bindings/mfd/ab8500.txt +++ b/Documentation/devicetree/bindings/mfd/ab8500.txt | |||
| @@ -13,9 +13,6 @@ Required parent device properties: | |||
| 13 | 4 = active high level-sensitive | 13 | 4 = active high level-sensitive |
| 14 | 8 = active low level-sensitive | 14 | 8 = active low level-sensitive |
| 15 | 15 | ||
| 16 | Optional parent device properties: | ||
| 17 | - reg : contains the PRCMU mailbox address for the AB8500 i2c port | ||
| 18 | |||
| 19 | The AB8500 consists of a large and varied group of sub-devices: | 16 | The AB8500 consists of a large and varied group of sub-devices: |
| 20 | 17 | ||
| 21 | Device IRQ Names Supply Names Description | 18 | Device IRQ Names Supply Names Description |
| @@ -86,9 +83,8 @@ Non-standard child device properties: | |||
| 86 | - stericsson,amic2-bias-vamic1 : Analoge Mic wishes to use a non-standard Vamic | 83 | - stericsson,amic2-bias-vamic1 : Analoge Mic wishes to use a non-standard Vamic |
| 87 | - stericsson,earpeice-cmv : Earpeice voltage (only: 950 | 1100 | 1270 | 1580) | 84 | - stericsson,earpeice-cmv : Earpeice voltage (only: 950 | 1100 | 1270 | 1580) |
| 88 | 85 | ||
| 89 | ab8500@5 { | 86 | ab8500 { |
| 90 | compatible = "stericsson,ab8500"; | 87 | compatible = "stericsson,ab8500"; |
| 91 | reg = <5>; /* mailbox 5 is i2c */ | ||
| 92 | interrupts = <0 40 0x4>; | 88 | interrupts = <0 40 0x4>; |
| 93 | interrupt-controller; | 89 | interrupt-controller; |
| 94 | #interrupt-cells = <2>; | 90 | #interrupt-cells = <2>; |
diff --git a/Documentation/devicetree/bindings/mfd/max8925.txt b/Documentation/devicetree/bindings/mfd/max8925.txt new file mode 100644 index 000000000000..4f0dc6638e5e --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/max8925.txt | |||
| @@ -0,0 +1,64 @@ | |||
| 1 | * Maxim max8925 Power Management IC | ||
| 2 | |||
| 3 | Required parent device properties: | ||
| 4 | - compatible : "maxim,max8925" | ||
| 5 | - reg : the I2C slave address for the max8925 chip | ||
| 6 | - interrupts : IRQ line for the max8925 chip | ||
| 7 | - interrupt-controller: describes the max8925 as an interrupt | ||
| 8 | controller (has its own domain) | ||
| 9 | - #interrupt-cells : should be 1. | ||
| 10 | - The cell is the max8925 local IRQ number | ||
| 11 | |||
| 12 | Optional parent device properties: | ||
| 13 | - maxim,tsc-irq: there are 2 IRQ lines for max8925, one is indicated in | ||
| 14 | interrupts property, the other is indicated here. | ||
| 15 | |||
| 16 | max8925 consists of a large and varied group of sub-devices: | ||
| 17 | |||
| 18 | Device Supply Names Description | ||
| 19 | ------ ------------ ----------- | ||
| 20 | max8925-onkey : : On key | ||
| 21 | max8925-rtc : : RTC | ||
| 22 | max8925-regulator : : Regulators | ||
| 23 | max8925-backlight : : Backlight | ||
| 24 | max8925-touch : : Touchscreen | ||
| 25 | max8925-power : : Charger | ||
| 26 | |||
| 27 | Example: | ||
| 28 | |||
| 29 | pmic: max8925@3c { | ||
| 30 | compatible = "maxim,max8925"; | ||
| 31 | reg = <0x3c>; | ||
| 32 | interrupts = <1>; | ||
| 33 | interrupt-parent = <&intcmux4>; | ||
| 34 | interrupt-controller; | ||
| 35 | #interrupt-cells = <1>; | ||
| 36 | maxim,tsc-irq = <0>; | ||
| 37 | |||
| 38 | regulators { | ||
| 39 | SDV1 { | ||
| 40 | regulator-min-microvolt = <637500>; | ||
| 41 | regulator-max-microvolt = <1425000>; | ||
| 42 | regulator-boot-on; | ||
| 43 | regulator-always-on; | ||
| 44 | }; | ||
| 45 | |||
| 46 | LDO1 { | ||
| 47 | regulator-min-microvolt = <750000>; | ||
| 48 | regulator-max-microvolt = <3900000>; | ||
| 49 | regulator-boot-on; | ||
| 50 | regulator-always-on; | ||
| 51 | }; | ||
| 52 | |||
| 53 | }; | ||
| 54 | backlight { | ||
| 55 | maxim,max8925-dual-string = <0>; | ||
| 56 | }; | ||
| 57 | charger { | ||
| 58 | batt-detect = <0>; | ||
| 59 | topoff-threshold = <1>; | ||
| 60 | fast-charge = <7>; | ||
| 61 | no-temp-support = <0>; | ||
| 62 | no-insert-detect = <0>; | ||
| 63 | }; | ||
| 64 | }; | ||
diff --git a/Documentation/devicetree/bindings/mips/cpu_irq.txt b/Documentation/devicetree/bindings/mips/cpu_irq.txt new file mode 100644 index 000000000000..13aa4b62c62a --- /dev/null +++ b/Documentation/devicetree/bindings/mips/cpu_irq.txt | |||
| @@ -0,0 +1,47 @@ | |||
| 1 | MIPS CPU interrupt controller | ||
| 2 | |||
| 3 | On MIPS the mips_cpu_intc_init() helper can be used to initialize the 8 CPU | ||
| 4 | IRQs from a devicetree file and create a irq_domain for IRQ controller. | ||
| 5 | |||
| 6 | With the irq_domain in place we can describe how the 8 IRQs are wired to the | ||
| 7 | platforms internal interrupt controller cascade. | ||
| 8 | |||
| 9 | Below is an example of a platform describing the cascade inside the devicetree | ||
| 10 | and the code used to load it inside arch_init_irq(). | ||
| 11 | |||
| 12 | Required properties: | ||
| 13 | - compatible : Should be "mti,cpu-interrupt-controller" | ||
| 14 | |||
| 15 | Example devicetree: | ||
| 16 | cpu-irq: cpu-irq@0 { | ||
| 17 | #address-cells = <0>; | ||
| 18 | |||
| 19 | interrupt-controller; | ||
| 20 | #interrupt-cells = <1>; | ||
| 21 | |||
| 22 | compatible = "mti,cpu-interrupt-controller"; | ||
| 23 | }; | ||
| 24 | |||
| 25 | intc: intc@200 { | ||
| 26 | compatible = "ralink,rt2880-intc"; | ||
| 27 | reg = <0x200 0x100>; | ||
| 28 | |||
| 29 | interrupt-controller; | ||
| 30 | #interrupt-cells = <1>; | ||
| 31 | |||
| 32 | interrupt-parent = <&cpu-irq>; | ||
| 33 | interrupts = <2>; | ||
| 34 | }; | ||
| 35 | |||
| 36 | |||
| 37 | Example platform irq.c: | ||
| 38 | static struct of_device_id __initdata of_irq_ids[] = { | ||
| 39 | { .compatible = "mti,cpu-interrupt-controller", .data = mips_cpu_intc_init }, | ||
| 40 | { .compatible = "ralink,rt2880-intc", .data = intc_of_init }, | ||
| 41 | {}, | ||
| 42 | }; | ||
| 43 | |||
| 44 | void __init arch_init_irq(void) | ||
| 45 | { | ||
| 46 | of_irq_init(of_irq_ids); | ||
| 47 | } | ||
diff --git a/Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhci.txt b/Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhci.txt new file mode 100644 index 000000000000..59476fbdbfa1 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/brcm,bcm2835-sdhci.txt | |||
| @@ -0,0 +1,18 @@ | |||
| 1 | Broadcom BCM2835 SDHCI controller | ||
| 2 | |||
| 3 | This file documents differences between the core properties described | ||
| 4 | by mmc.txt and the properties that represent the BCM2835 controller. | ||
| 5 | |||
| 6 | Required properties: | ||
| 7 | - compatible : Should be "brcm,bcm2835-sdhci". | ||
| 8 | - clocks : The clock feeding the SDHCI controller. | ||
| 9 | |||
| 10 | Example: | ||
| 11 | |||
| 12 | sdhci: sdhci { | ||
| 13 | compatible = "brcm,bcm2835-sdhci"; | ||
| 14 | reg = <0x7e300000 0x100>; | ||
| 15 | interrupts = <2 30>; | ||
| 16 | clocks = <&clk_mmc>; | ||
| 17 | bus-width = <4>; | ||
| 18 | }; | ||
diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt index a591c6741d75..85aada2263d5 100644 --- a/Documentation/devicetree/bindings/mmc/mmc.txt +++ b/Documentation/devicetree/bindings/mmc/mmc.txt | |||
| @@ -6,23 +6,45 @@ Interpreted by the OF core: | |||
| 6 | - reg: Registers location and length. | 6 | - reg: Registers location and length. |
| 7 | - interrupts: Interrupts used by the MMC controller. | 7 | - interrupts: Interrupts used by the MMC controller. |
| 8 | 8 | ||
| 9 | Required properties: | ||
| 10 | - bus-width: Number of data lines, can be <1>, <4>, or <8> | ||
| 11 | |||
| 12 | Card detection: | 9 | Card detection: |
| 13 | If no property below is supplied, standard SDHCI card detect is used. | 10 | If no property below is supplied, host native card detect is used. |
| 14 | Only one of the properties in this section should be supplied: | 11 | Only one of the properties in this section should be supplied: |
| 15 | - broken-cd: There is no card detection available; polling must be used. | 12 | - broken-cd: There is no card detection available; polling must be used. |
| 16 | - cd-gpios: Specify GPIOs for card detection, see gpio binding | 13 | - cd-gpios: Specify GPIOs for card detection, see gpio binding |
| 17 | - non-removable: non-removable slot (like eMMC); assume always present. | 14 | - non-removable: non-removable slot (like eMMC); assume always present. |
| 18 | 15 | ||
| 19 | Optional properties: | 16 | Optional properties: |
| 17 | - bus-width: Number of data lines, can be <1>, <4>, or <8>. The default | ||
| 18 | will be <1> if the property is absent. | ||
| 20 | - wp-gpios: Specify GPIOs for write protection, see gpio binding | 19 | - wp-gpios: Specify GPIOs for write protection, see gpio binding |
| 21 | - cd-inverted: when present, polarity on the cd gpio line is inverted | 20 | - cd-inverted: when present, polarity on the CD line is inverted. See the note |
| 22 | - wp-inverted: when present, polarity on the wp gpio line is inverted | 21 | below for the case, when a GPIO is used for the CD line |
| 22 | - wp-inverted: when present, polarity on the WP line is inverted. See the note | ||
| 23 | below for the case, when a GPIO is used for the WP line | ||
| 23 | - max-frequency: maximum operating clock frequency | 24 | - max-frequency: maximum operating clock frequency |
| 24 | - no-1-8-v: when present, denotes that 1.8v card voltage is not supported on | 25 | - no-1-8-v: when present, denotes that 1.8v card voltage is not supported on |
| 25 | this system, even if the controller claims it is. | 26 | this system, even if the controller claims it is. |
| 27 | - cap-sd-highspeed: SD high-speed timing is supported | ||
| 28 | - cap-mmc-highspeed: MMC high-speed timing is supported | ||
| 29 | - cap-power-off-card: powering off the card is safe | ||
| 30 | - cap-sdio-irq: enable SDIO IRQ signalling on this interface | ||
| 31 | |||
| 32 | *NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers line | ||
| 33 | polarity properties, we have to fix the meaning of the "normal" and "inverted" | ||
| 34 | line levels. We choose to follow the SDHCI standard, which specifies both those | ||
| 35 | lines as "active low." Therefore, using the "cd-inverted" property means, that | ||
| 36 | the CD line is active high, i.e. it is high, when a card is inserted. Similar | ||
| 37 | logic applies to the "wp-inverted" property. | ||
| 38 | |||
| 39 | CD and WP lines can be implemented on the hardware in one of two ways: as GPIOs, | ||
| 40 | specified in cd-gpios and wp-gpios properties, or as dedicated pins. Polarity of | ||
| 41 | dedicated pins can be specified, using *-inverted properties. GPIO polarity can | ||
| 42 | also be specified using the OF_GPIO_ACTIVE_LOW flag. This creates an ambiguity | ||
| 43 | in the latter case. We choose to use the XOR logic for GPIO CD and WP lines. | ||
| 44 | This means, the two properties are "superimposed," for example leaving the | ||
| 45 | OF_GPIO_ACTIVE_LOW flag clear and specifying the respective *-inverted | ||
| 46 | property results in a double-inversion and actually means the "normal" line | ||
| 47 | polarity is in effect. | ||
| 26 | 48 | ||
| 27 | Optional SDIO properties: | 49 | Optional SDIO properties: |
| 28 | - keep-power-in-suspend: Preserves card power during a suspend/resume cycle | 50 | - keep-power-in-suspend: Preserves card power during a suspend/resume cycle |
diff --git a/Documentation/devicetree/bindings/mmc/orion-sdio.txt b/Documentation/devicetree/bindings/mmc/orion-sdio.txt new file mode 100644 index 000000000000..84f0ebd67a13 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/orion-sdio.txt | |||
| @@ -0,0 +1,17 @@ | |||
| 1 | * Marvell orion-sdio controller | ||
| 2 | |||
| 3 | This file documents differences between the core properties in mmc.txt | ||
| 4 | and the properties used by the orion-sdio driver. | ||
| 5 | |||
| 6 | - compatible: Should be "marvell,orion-sdio" | ||
| 7 | - clocks: reference to the clock of the SDIO interface | ||
| 8 | |||
| 9 | Example: | ||
| 10 | |||
| 11 | mvsdio@d00d4000 { | ||
| 12 | compatible = "marvell,orion-sdio"; | ||
| 13 | reg = <0xd00d4000 0x200>; | ||
| 14 | interrupts = <54>; | ||
| 15 | clocks = <&gateclk 17>; | ||
| 16 | status = "disabled"; | ||
| 17 | }; | ||
diff --git a/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt index 06cd32d08052..726fd2122a13 100644 --- a/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt +++ b/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt | |||
| @@ -26,8 +26,16 @@ Required Properties: | |||
| 26 | * bus-width: as documented in mmc core bindings. | 26 | * bus-width: as documented in mmc core bindings. |
| 27 | 27 | ||
| 28 | * wp-gpios: specifies the write protect gpio line. The format of the | 28 | * wp-gpios: specifies the write protect gpio line. The format of the |
| 29 | gpio specifier depends on the gpio controller. If the write-protect | 29 | gpio specifier depends on the gpio controller. If a GPIO is not used |
| 30 | line is not available, this property is optional. | 30 | for write-protect, this property is optional. |
| 31 | |||
| 32 | * disable-wp: If the wp-gpios property isn't present then (by default) | ||
| 33 | we'd assume that the write protect is hooked up directly to the | ||
| 34 | controller's special purpose write protect line (accessible via | ||
| 35 | the WRTPRT register). However, it's possible that we simply don't | ||
| 36 | want write protect. In that case specify 'disable-wp'. | ||
| 37 | NOTE: This property is not required for slots known to always | ||
| 38 | connect to eMMC or SDIO cards. | ||
| 31 | 39 | ||
| 32 | Optional properties: | 40 | Optional properties: |
| 33 | 41 | ||
diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt new file mode 100644 index 000000000000..df204e18e030 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt | |||
| @@ -0,0 +1,20 @@ | |||
| 1 | * Toshiba Mobile IO SD/MMC controller | ||
| 2 | |||
| 3 | The tmio-mmc driver doesn't probe its devices actively, instead its binding to | ||
| 4 | devices is managed by either MFD drivers or by the sh_mobile_sdhi platform | ||
| 5 | driver. Those drivers supply the tmio-mmc driver with platform data, that either | ||
| 6 | describe hardware capabilities, known to them, or are obtained by them from | ||
| 7 | their own platform data or from their DT information. In the latter case all | ||
| 8 | compulsory and any optional properties, common to all SD/MMC drivers, as | ||
| 9 | described in mmc.txt, can be used. Additionally the following tmio_mmc-specific | ||
| 10 | optional bindings can be used. | ||
| 11 | |||
| 12 | Optional properties: | ||
| 13 | - toshiba,mmc-wrprotect-disable: write-protect detection is unavailable | ||
| 14 | |||
| 15 | When used with Renesas SDHI hardware, the following compatibility strings | ||
| 16 | configure various model-specific properties: | ||
| 17 | |||
| 18 | "renesas,sh7372-sdhi": (default) compatible with SH7372 | ||
| 19 | "renesas,r8a7740-sdhi": compatible with R8A7740: certain MMC/SD commands have to | ||
| 20 | wait for the interface to become idle. | ||
diff --git a/Documentation/devicetree/bindings/mtd/elm.txt b/Documentation/devicetree/bindings/mtd/elm.txt new file mode 100644 index 000000000000..8c1528c421d4 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/elm.txt | |||
| @@ -0,0 +1,16 @@ | |||
| 1 | Error location module | ||
| 2 | |||
| 3 | Required properties: | ||
| 4 | - compatible: Must be "ti,am33xx-elm" | ||
| 5 | - reg: physical base address and size of the registers map. | ||
| 6 | - interrupts: Interrupt number for the elm. | ||
| 7 | |||
| 8 | Optional properties: | ||
| 9 | - ti,hwmods: Name of the hwmod associated to the elm | ||
| 10 | |||
| 11 | Example: | ||
| 12 | elm: elm@0 { | ||
| 13 | compatible = "ti,am3352-elm"; | ||
| 14 | reg = <0x48080000 0x2000>; | ||
| 15 | interrupts = <4>; | ||
| 16 | }; | ||
diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt index dab7847fc800..61c5ec850f2f 100644 --- a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt +++ b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt | |||
| @@ -26,6 +26,9 @@ file systems on embedded devices. | |||
| 26 | - linux,mtd-name: allow to specify the mtd name for retro capability with | 26 | - linux,mtd-name: allow to specify the mtd name for retro capability with |
| 27 | physmap-flash drivers as boot loader pass the mtd partition via the old | 27 | physmap-flash drivers as boot loader pass the mtd partition via the old |
| 28 | device name physmap-flash. | 28 | device name physmap-flash. |
| 29 | - use-advanced-sector-protection: boolean to enable support for the | ||
| 30 | advanced sector protection (Spansion: PPB - Persistent Protection | ||
| 31 | Bits) locking. | ||
| 29 | 32 | ||
| 30 | For JEDEC compatible devices, the following additional properties | 33 | For JEDEC compatible devices, the following additional properties |
| 31 | are defined: | 34 | are defined: |
diff --git a/Documentation/devicetree/bindings/power_supply/max8925_batter.txt b/Documentation/devicetree/bindings/power_supply/max8925_batter.txt new file mode 100644 index 000000000000..d7e3e0c0f71d --- /dev/null +++ b/Documentation/devicetree/bindings/power_supply/max8925_batter.txt | |||
| @@ -0,0 +1,18 @@ | |||
| 1 | max8925-battery bindings | ||
| 2 | ~~~~~~~~~~~~~~~~ | ||
| 3 | |||
| 4 | Optional properties : | ||
| 5 | - batt-detect: whether support battery detect | ||
| 6 | - topoff-threshold: set charging current in topoff mode | ||
| 7 | - fast-charge: set charging current in fast mode | ||
| 8 | - no-temp-support: whether support temperature protection detect | ||
| 9 | - no-insert-detect: whether support insert detect | ||
| 10 | |||
| 11 | Example: | ||
| 12 | charger { | ||
| 13 | batt-detect = <0>; | ||
| 14 | topoff-threshold = <1>; | ||
| 15 | fast-charge = <7>; | ||
| 16 | no-temp-support = <0>; | ||
| 17 | no-insert-detect = <0>; | ||
| 18 | }; | ||
diff --git a/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt new file mode 100644 index 000000000000..de0eaed86651 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/atmel-tcb-pwm.txt | |||
| @@ -0,0 +1,18 @@ | |||
| 1 | Atmel TCB PWM controller | ||
| 2 | |||
| 3 | Required properties: | ||
| 4 | - compatible: should be "atmel,tcb-pwm" | ||
| 5 | - #pwm-cells: Should be 3. The first cell specifies the per-chip index | ||
| 6 | of the PWM to use, the second cell is the period in nanoseconds and | ||
| 7 | bit 0 in the third cell is used to encode the polarity of PWM output. | ||
| 8 | Set bit 0 of the third cell in PWM specifier to 1 for inverse polarity & | ||
| 9 | set to 0 for normal polarity. | ||
| 10 | - tc-block: The Timer Counter block to use as a PWM chip. | ||
| 11 | |||
| 12 | Example: | ||
| 13 | |||
| 14 | pwm { | ||
| 15 | compatible = "atmel,tcb-pwm"; | ||
| 16 | #pwm-cells = <3>; | ||
| 17 | tc-block = <1>; | ||
| 18 | }; | ||
diff --git a/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt index bcc63678a9a5..d21d82d29855 100644 --- a/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt +++ b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt | |||
| @@ -3,14 +3,17 @@ VIA/Wondermedia VT8500/WM8xxx series SoC PWM controller | |||
| 3 | Required properties: | 3 | Required properties: |
| 4 | - compatible: should be "via,vt8500-pwm" | 4 | - compatible: should be "via,vt8500-pwm" |
| 5 | - reg: physical base address and length of the controller's registers | 5 | - reg: physical base address and length of the controller's registers |
| 6 | - #pwm-cells: should be 2. The first cell specifies the per-chip index | 6 | - #pwm-cells: Should be 3. Number of cells being used to specify PWM property. |
| 7 | of the PWM to use and the second cell is the period in nanoseconds. | 7 | First cell specifies the per-chip index of the PWM to use, the second |
| 8 | cell is the period in nanoseconds and bit 0 in the third cell is used to | ||
| 9 | encode the polarity of PWM output. Set bit 0 of the third in PWM specifier | ||
| 10 | to 1 for inverse polarity & set to 0 for normal polarity. | ||
| 8 | - clocks: phandle to the PWM source clock | 11 | - clocks: phandle to the PWM source clock |
| 9 | 12 | ||
| 10 | Example: | 13 | Example: |
| 11 | 14 | ||
| 12 | pwm1: pwm@d8220000 { | 15 | pwm1: pwm@d8220000 { |
| 13 | #pwm-cells = <2>; | 16 | #pwm-cells = <3>; |
| 14 | compatible = "via,vt8500-pwm"; | 17 | compatible = "via,vt8500-pwm"; |
| 15 | reg = <0xd8220000 0x1000>; | 18 | reg = <0xd8220000 0x1000>; |
| 16 | clocks = <&clkpwm>; | 19 | clocks = <&clkpwm>; |
diff --git a/Documentation/devicetree/bindings/regulator/tps65090.txt b/Documentation/devicetree/bindings/regulator/tps65090.txt new file mode 100644 index 000000000000..313a60ba61d8 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/tps65090.txt | |||
| @@ -0,0 +1,122 @@ | |||
| 1 | TPS65090 regulators | ||
| 2 | |||
| 3 | Required properties: | ||
| 4 | - compatible: "ti,tps65090" | ||
| 5 | - reg: I2C slave address | ||
| 6 | - interrupts: the interrupt outputs of the controller | ||
| 7 | - regulators: A node that houses a sub-node for each regulator within the | ||
| 8 | device. Each sub-node is identified using the node's name, with valid | ||
| 9 | values listed below. The content of each sub-node is defined by the | ||
| 10 | standard binding for regulators; see regulator.txt. | ||
| 11 | dcdc[1-3], fet[1-7] and ldo[1-2] respectively. | ||
| 12 | - vsys[1-3]-supply: The input supply for DCDC[1-3] respectively. | ||
| 13 | - infet[1-7]-supply: The input supply for FET[1-7] respectively. | ||
| 14 | - vsys-l[1-2]-supply: The input supply for LDO[1-2] respectively. | ||
| 15 | |||
| 16 | Optional properties: | ||
| 17 | - ti,enable-ext-control: This is applicable for DCDC1, DCDC2 and DCDC3. | ||
| 18 | If DCDCs are externally controlled then this property should be there. | ||
| 19 | - "dcdc-ext-control-gpios: This is applicable for DCDC1, DCDC2 and DCDC3. | ||
| 20 | If DCDCs are externally controlled and if it is from GPIO then GPIO | ||
| 21 | number should be provided. If it is externally controlled and no GPIO | ||
| 22 | entry then driver will just configure this rails as external control | ||
| 23 | and will not provide any enable/disable APIs. | ||
| 24 | |||
| 25 | Each regulator is defined using the standard binding for regulators. | ||
| 26 | |||
| 27 | Example: | ||
| 28 | |||
| 29 | tps65090@48 { | ||
| 30 | compatible = "ti,tps65090"; | ||
| 31 | reg = <0x48>; | ||
| 32 | interrupts = <0 88 0x4>; | ||
| 33 | |||
| 34 | vsys1-supply = <&some_reg>; | ||
| 35 | vsys2-supply = <&some_reg>; | ||
| 36 | vsys3-supply = <&some_reg>; | ||
| 37 | infet1-supply = <&some_reg>; | ||
| 38 | infet2-supply = <&some_reg>; | ||
| 39 | infet3-supply = <&some_reg>; | ||
| 40 | infet4-supply = <&some_reg>; | ||
| 41 | infet5-supply = <&some_reg>; | ||
| 42 | infet6-supply = <&some_reg>; | ||
| 43 | infet7-supply = <&some_reg>; | ||
| 44 | vsys_l1-supply = <&some_reg>; | ||
| 45 | vsys_l2-supply = <&some_reg>; | ||
| 46 | |||
| 47 | regulators { | ||
| 48 | dcdc1 { | ||
| 49 | regulator-name = "dcdc1"; | ||
| 50 | regulator-boot-on; | ||
| 51 | regulator-always-on; | ||
| 52 | ti,enable-ext-control; | ||
| 53 | dcdc-ext-control-gpios = <&gpio 10 0>; | ||
| 54 | }; | ||
| 55 | |||
| 56 | dcdc2 { | ||
| 57 | regulator-name = "dcdc2"; | ||
| 58 | regulator-boot-on; | ||
| 59 | regulator-always-on; | ||
| 60 | }; | ||
| 61 | |||
| 62 | dcdc3 { | ||
| 63 | regulator-name = "dcdc3"; | ||
| 64 | regulator-boot-on; | ||
| 65 | regulator-always-on; | ||
| 66 | }; | ||
| 67 | |||
| 68 | fet1 { | ||
| 69 | regulator-name = "fet1"; | ||
| 70 | regulator-boot-on; | ||
| 71 | regulator-always-on; | ||
| 72 | }; | ||
| 73 | |||
| 74 | fet2 { | ||
| 75 | regulator-name = "fet2"; | ||
| 76 | regulator-boot-on; | ||
| 77 | regulator-always-on; | ||
| 78 | }; | ||
| 79 | |||
| 80 | fet3 { | ||
| 81 | regulator-name = "fet3"; | ||
| 82 | regulator-boot-on; | ||
| 83 | regulator-always-on; | ||
| 84 | }; | ||
| 85 | |||
| 86 | fet4 { | ||
| 87 | regulator-name = "fet4"; | ||
| 88 | regulator-boot-on; | ||
| 89 | regulator-always-on; | ||
| 90 | }; | ||
| 91 | |||
| 92 | fet5 { | ||
| 93 | regulator-name = "fet5"; | ||
| 94 | regulator-boot-on; | ||
| 95 | regulator-always-on; | ||
| 96 | }; | ||
| 97 | |||
| 98 | fet6 { | ||
| 99 | regulator-name = "fet6"; | ||
| 100 | regulator-boot-on; | ||
| 101 | regulator-always-on; | ||
| 102 | }; | ||
| 103 | |||
| 104 | fet7 { | ||
| 105 | regulator-name = "fet7"; | ||
| 106 | regulator-boot-on; | ||
| 107 | regulator-always-on; | ||
| 108 | }; | ||
| 109 | |||
| 110 | ldo1 { | ||
| 111 | regulator-name = "ldo1"; | ||
| 112 | regulator-boot-on; | ||
| 113 | regulator-always-on; | ||
| 114 | }; | ||
| 115 | |||
| 116 | ldo2 { | ||
| 117 | regulator-name = "ldo2"; | ||
| 118 | regulator-boot-on; | ||
| 119 | regulator-always-on; | ||
| 120 | }; | ||
| 121 | }; | ||
| 122 | }; | ||
diff --git a/Documentation/devicetree/bindings/serial/lantiq_asc.txt b/Documentation/devicetree/bindings/serial/lantiq_asc.txt new file mode 100644 index 000000000000..5b78591aaa46 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/lantiq_asc.txt | |||
| @@ -0,0 +1,16 @@ | |||
| 1 | Lantiq SoC ASC serial controller | ||
| 2 | |||
| 3 | Required properties: | ||
| 4 | - compatible : Should be "lantiq,asc" | ||
| 5 | - reg : Address and length of the register set for the device | ||
| 6 | - interrupts: the 3 (tx rx err) interrupt numbers. The interrupt specifier | ||
| 7 | depends on the interrupt-parent interrupt controller. | ||
| 8 | |||
| 9 | Example: | ||
| 10 | |||
| 11 | asc1: serial@E100C00 { | ||
| 12 | compatible = "lantiq,asc"; | ||
| 13 | reg = <0xE100C00 0x400>; | ||
| 14 | interrupt-parent = <&icu0>; | ||
| 15 | interrupts = <112 113 114>; | ||
| 16 | }; | ||
diff --git a/Documentation/devicetree/bindings/thermal/dove-thermal.txt b/Documentation/devicetree/bindings/thermal/dove-thermal.txt new file mode 100644 index 000000000000..6f474677d472 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/dove-thermal.txt | |||
| @@ -0,0 +1,18 @@ | |||
| 1 | * Dove Thermal | ||
| 2 | |||
| 3 | This driver is for Dove SoCs which contain a thermal sensor. | ||
| 4 | |||
| 5 | Required properties: | ||
| 6 | - compatible : "marvell,dove-thermal" | ||
| 7 | - reg : Address range of the thermal registers | ||
| 8 | |||
| 9 | The reg properties should contain two ranges. The first is for the | ||
| 10 | three Thermal Manager registers, while the second range contains the | ||
| 11 | Thermal Diode Control Registers. | ||
| 12 | |||
| 13 | Example: | ||
| 14 | |||
| 15 | thermal@10078 { | ||
| 16 | compatible = "marvell,dove-thermal"; | ||
| 17 | reg = <0xd001c 0x0c>, <0xd005c 0x08>; | ||
| 18 | }; | ||
diff --git a/Documentation/devicetree/bindings/thermal/kirkwood-thermal.txt b/Documentation/devicetree/bindings/thermal/kirkwood-thermal.txt new file mode 100644 index 000000000000..8c0f5eb86da7 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/kirkwood-thermal.txt | |||
| @@ -0,0 +1,15 @@ | |||
| 1 | * Kirkwood Thermal | ||
| 2 | |||
| 3 | This version is for Kirkwood 88F8262 & 88F6283 SoCs. Other kirkwoods | ||
| 4 | don't contain a thermal sensor. | ||
| 5 | |||
| 6 | Required properties: | ||
| 7 | - compatible : "marvell,kirkwood-thermal" | ||
| 8 | - reg : Address range of the thermal registers | ||
| 9 | |||
| 10 | Example: | ||
| 11 | |||
| 12 | thermal@10078 { | ||
| 13 | compatible = "marvell,kirkwood-thermal"; | ||
| 14 | reg = <0x10078 0x4>; | ||
| 15 | }; | ||
diff --git a/Documentation/devicetree/bindings/thermal/rcar-thermal.txt b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt new file mode 100644 index 000000000000..28ef498a66e5 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/rcar-thermal.txt | |||
| @@ -0,0 +1,29 @@ | |||
| 1 | * Renesas R-Car Thermal | ||
| 2 | |||
| 3 | Required properties: | ||
| 4 | - compatible : "renesas,rcar-thermal" | ||
| 5 | - reg : Address range of the thermal registers. | ||
| 6 | The 1st reg will be recognized as common register | ||
| 7 | if it has "interrupts". | ||
| 8 | |||
| 9 | Option properties: | ||
| 10 | |||
| 11 | - interrupts : use interrupt | ||
| 12 | |||
| 13 | Example (non interrupt support): | ||
| 14 | |||
| 15 | thermal@e61f0100 { | ||
| 16 | compatible = "renesas,rcar-thermal"; | ||
| 17 | reg = <0xe61f0100 0x38>; | ||
| 18 | }; | ||
| 19 | |||
| 20 | Example (interrupt support): | ||
| 21 | |||
| 22 | thermal@e61f0000 { | ||
| 23 | compatible = "renesas,rcar-thermal"; | ||
| 24 | reg = <0xe61f0000 0x14 | ||
| 25 | 0xe61f0100 0x38 | ||
| 26 | 0xe61f0200 0x38 | ||
| 27 | 0xe61f0300 0x38>; | ||
| 28 | interrupts = <0 69 4>; | ||
| 29 | }; | ||
diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt b/Documentation/devicetree/bindings/timer/marvell,armada-370-xp-timer.txt index 64830118b013..36381129d141 100644 --- a/Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt +++ b/Documentation/devicetree/bindings/timer/marvell,armada-370-xp-timer.txt | |||
| @@ -1,10 +1,13 @@ | |||
| 1 | Marvell Armada 370 and Armada XP Global Timers | 1 | Marvell Armada 370 and Armada XP Timers |
| 2 | ---------------------------------------------- | 2 | --------------------------------------- |
| 3 | 3 | ||
| 4 | Required properties: | 4 | Required properties: |
| 5 | - compatible: Should be "marvell,armada-370-xp-timer" | 5 | - compatible: Should be "marvell,armada-370-xp-timer" |
| 6 | - interrupts: Should contain the list of Global Timer interrupts | 6 | - interrupts: Should contain the list of Global Timer interrupts and |
| 7 | - reg: Should contain the base address of the Global Timer registers | 7 | then local timer interrupts |
| 8 | - reg: Should contain location and length for timers register. First | ||
| 9 | pair for the Global Timer registers, second pair for the | ||
| 10 | local/private timers. | ||
| 8 | - clocks: clock driving the timer hardware | 11 | - clocks: clock driving the timer hardware |
| 9 | 12 | ||
| 10 | Optional properties: | 13 | Optional properties: |
diff --git a/Documentation/devicetree/bindings/tty/serial/of-serial.txt b/Documentation/devicetree/bindings/tty/serial/of-serial.txt index 1e1145ca4f3c..8f01cb190f25 100644 --- a/Documentation/devicetree/bindings/tty/serial/of-serial.txt +++ b/Documentation/devicetree/bindings/tty/serial/of-serial.txt | |||
| @@ -11,6 +11,9 @@ Required properties: | |||
| 11 | - "nvidia,tegra20-uart" | 11 | - "nvidia,tegra20-uart" |
| 12 | - "nxp,lpc3220-uart" | 12 | - "nxp,lpc3220-uart" |
| 13 | - "ibm,qpace-nwp-serial" | 13 | - "ibm,qpace-nwp-serial" |
| 14 | - "altr,16550-FIFO32" | ||
| 15 | - "altr,16550-FIFO64" | ||
| 16 | - "altr,16550-FIFO128" | ||
| 14 | - "serial" if the port type is unknown. | 17 | - "serial" if the port type is unknown. |
| 15 | - reg : offset and length of the register set for the device. | 18 | - reg : offset and length of the register set for the device. |
| 16 | - interrupts : should contain uart interrupt. | 19 | - interrupts : should contain uart interrupt. |
diff --git a/Documentation/devicetree/bindings/video/backlight/max8925-backlight.txt b/Documentation/devicetree/bindings/video/backlight/max8925-backlight.txt new file mode 100644 index 000000000000..b4cffdaa4137 --- /dev/null +++ b/Documentation/devicetree/bindings/video/backlight/max8925-backlight.txt | |||
| @@ -0,0 +1,10 @@ | |||
| 1 | 88pm860x-backlight bindings | ||
| 2 | |||
| 3 | Optional properties: | ||
| 4 | - maxim,max8925-dual-string: whether support dual string | ||
| 5 | |||
| 6 | Example: | ||
| 7 | |||
| 8 | backlights { | ||
| 9 | maxim,max8925-dual-string = <0>; | ||
| 10 | }; | ||
diff --git a/Documentation/devicetree/bindings/video/display-timing.txt b/Documentation/devicetree/bindings/video/display-timing.txt new file mode 100644 index 000000000000..150038552bc3 --- /dev/null +++ b/Documentation/devicetree/bindings/video/display-timing.txt | |||
| @@ -0,0 +1,109 @@ | |||
| 1 | display-timing bindings | ||
| 2 | ======================= | ||
| 3 | |||
| 4 | display-timings node | ||
| 5 | -------------------- | ||
| 6 | |||
| 7 | required properties: | ||
| 8 | - none | ||
| 9 | |||
| 10 | optional properties: | ||
| 11 | - native-mode: The native mode for the display, in case multiple modes are | ||
| 12 | provided. When omitted, assume the first node is the native. | ||
| 13 | |||
| 14 | timing subnode | ||
| 15 | -------------- | ||
| 16 | |||
| 17 | required properties: | ||
| 18 | - hactive, vactive: display resolution | ||
| 19 | - hfront-porch, hback-porch, hsync-len: horizontal display timing parameters | ||
| 20 | in pixels | ||
| 21 | vfront-porch, vback-porch, vsync-len: vertical display timing parameters in | ||
| 22 | lines | ||
| 23 | - clock-frequency: display clock in Hz | ||
| 24 | |||
| 25 | optional properties: | ||
| 26 | - hsync-active: hsync pulse is active low/high/ignored | ||
| 27 | - vsync-active: vsync pulse is active low/high/ignored | ||
| 28 | - de-active: data-enable pulse is active low/high/ignored | ||
| 29 | - pixelclk-active: with | ||
| 30 | - active high = drive pixel data on rising edge/ | ||
| 31 | sample data on falling edge | ||
| 32 | - active low = drive pixel data on falling edge/ | ||
| 33 | sample data on rising edge | ||
| 34 | - ignored = ignored | ||
| 35 | - interlaced (bool): boolean to enable interlaced mode | ||
| 36 | - doublescan (bool): boolean to enable doublescan mode | ||
| 37 | |||
| 38 | All the optional properties that are not bool follow the following logic: | ||
| 39 | <1>: high active | ||
| 40 | <0>: low active | ||
| 41 | omitted: not used on hardware | ||
| 42 | |||
| 43 | There are different ways of describing the capabilities of a display. The | ||
| 44 | devicetree representation corresponds to the one commonly found in datasheets | ||
| 45 | for displays. If a display supports multiple signal timings, the native-mode | ||
| 46 | can be specified. | ||
| 47 | |||
| 48 | The parameters are defined as: | ||
| 49 | |||
| 50 | +----------+-------------------------------------+----------+-------+ | ||
| 51 | | | ↑ | | | | ||
| 52 | | | |vback_porch | | | | ||
| 53 | | | ↓ | | | | ||
| 54 | +----------#######################################----------+-------+ | ||
| 55 | | # ↑ # | | | ||
| 56 | | # | # | | | ||
| 57 | | hback # | # hfront | hsync | | ||
| 58 | | porch # | hactive # porch | len | | ||
| 59 | |<-------->#<-------+--------------------------->#<-------->|<----->| | ||
| 60 | | # | # | | | ||
| 61 | | # |vactive # | | | ||
| 62 | | # | # | | | ||
| 63 | | # ↓ # | | | ||
| 64 | +----------#######################################----------+-------+ | ||
| 65 | | | ↑ | | | | ||
| 66 | | | |vfront_porch | | | | ||
| 67 | | | ↓ | | | | ||
| 68 | +----------+-------------------------------------+----------+-------+ | ||
| 69 | | | ↑ | | | | ||
| 70 | | | |vsync_len | | | | ||
| 71 | | | ↓ | | | | ||
| 72 | +----------+-------------------------------------+----------+-------+ | ||
| 73 | |||
| 74 | Example: | ||
| 75 | |||
| 76 | display-timings { | ||
| 77 | native-mode = <&timing0>; | ||
| 78 | timing0: 1080p24 { | ||
| 79 | /* 1920x1080p24 */ | ||
| 80 | clock-frequency = <52000000>; | ||
| 81 | hactive = <1920>; | ||
| 82 | vactive = <1080>; | ||
| 83 | hfront-porch = <25>; | ||
| 84 | hback-porch = <25>; | ||
| 85 | hsync-len = <25>; | ||
| 86 | vback-porch = <2>; | ||
| 87 | vfront-porch = <2>; | ||
| 88 | vsync-len = <2>; | ||
| 89 | hsync-active = <1>; | ||
| 90 | }; | ||
| 91 | }; | ||
| 92 | |||
| 93 | Every required property also supports the use of ranges, so the commonly used | ||
| 94 | datasheet description with minimum, typical and maximum values can be used. | ||
| 95 | |||
| 96 | Example: | ||
| 97 | |||
| 98 | timing1: timing { | ||
| 99 | /* 1920x1080p24 */ | ||
| 100 | clock-frequency = <148500000>; | ||
| 101 | hactive = <1920>; | ||
| 102 | vactive = <1080>; | ||
| 103 | hsync-len = <0 44 60>; | ||
| 104 | hfront-porch = <80 88 95>; | ||
| 105 | hback-porch = <100 148 160>; | ||
| 106 | vfront-porch = <0 4 6>; | ||
| 107 | vback-porch = <0 36 50>; | ||
| 108 | vsync-len = <0 5 6>; | ||
| 109 | }; | ||
diff --git a/Documentation/devicetree/bindings/w1/fsl-imx-owire.txt b/Documentation/devicetree/bindings/w1/fsl-imx-owire.txt new file mode 100644 index 000000000000..ecf42c07684d --- /dev/null +++ b/Documentation/devicetree/bindings/w1/fsl-imx-owire.txt | |||
| @@ -0,0 +1,19 @@ | |||
| 1 | * Freescale i.MX One wire bus master controller | ||
| 2 | |||
| 3 | Required properties: | ||
| 4 | - compatible : should be "fsl,imx21-owire" | ||
| 5 | - reg : Address and length of the register set for the device | ||
| 6 | |||
| 7 | Optional properties: | ||
| 8 | - clocks : phandle of clock that supplies the module (required if platform | ||
| 9 | clock bindings use device tree) | ||
| 10 | |||
| 11 | Example: | ||
| 12 | |||
| 13 | - From imx53.dtsi: | ||
| 14 | owire: owire@63fa4000 { | ||
| 15 | compatible = "fsl,imx53-owire", "fsl,imx21-owire"; | ||
| 16 | reg = <0x63fa4000 0x4000>; | ||
| 17 | clocks = <&clks 159>; | ||
| 18 | status = "disabled"; | ||
| 19 | }; | ||
diff --git a/Documentation/devicetree/bindings/watchdog/atmel-at91rm9200-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-at91rm9200-wdt.txt new file mode 100644 index 000000000000..d4d86cf8f9eb --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/atmel-at91rm9200-wdt.txt | |||
| @@ -0,0 +1,9 @@ | |||
| 1 | Atmel AT91RM9200 System Timer Watchdog | ||
| 2 | |||
| 3 | Required properties: | ||
| 4 | - compatible: must be "atmel,at91sam9260-wdt". | ||
| 5 | |||
| 6 | Example: | ||
| 7 | watchdog@fffffd00 { | ||
| 8 | compatible = "atmel,at91rm9200-wdt"; | ||
| 9 | }; | ||
diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt index 2957ebb5aa71..fcdd48f7dcff 100644 --- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt | |||
| @@ -7,9 +7,13 @@ Required properties: | |||
| 7 | - reg: physical base address of the controller and length of memory mapped | 7 | - reg: physical base address of the controller and length of memory mapped |
| 8 | region. | 8 | region. |
| 9 | 9 | ||
| 10 | Optional properties: | ||
| 11 | - timeout-sec: contains the watchdog timeout in seconds. | ||
| 12 | |||
| 10 | Example: | 13 | Example: |
| 11 | 14 | ||
| 12 | watchdog@fffffd40 { | 15 | watchdog@fffffd40 { |
| 13 | compatible = "atmel,at91sam9260-wdt"; | 16 | compatible = "atmel,at91sam9260-wdt"; |
| 14 | reg = <0xfffffd40 0x10>; | 17 | reg = <0xfffffd40 0x10>; |
| 18 | timeout-sec = <10>; | ||
| 15 | }; | 19 | }; |
diff --git a/Documentation/devicetree/bindings/watchdog/marvel.txt b/Documentation/devicetree/bindings/watchdog/marvel.txt index 0b2503ab0a05..5dc8d30061ce 100644 --- a/Documentation/devicetree/bindings/watchdog/marvel.txt +++ b/Documentation/devicetree/bindings/watchdog/marvel.txt | |||
| @@ -5,10 +5,15 @@ Required Properties: | |||
| 5 | - Compatibility : "marvell,orion-wdt" | 5 | - Compatibility : "marvell,orion-wdt" |
| 6 | - reg : Address of the timer registers | 6 | - reg : Address of the timer registers |
| 7 | 7 | ||
| 8 | Optional properties: | ||
| 9 | |||
| 10 | - timeout-sec : Contains the watchdog timeout in seconds | ||
| 11 | |||
| 8 | Example: | 12 | Example: |
| 9 | 13 | ||
| 10 | wdt@20300 { | 14 | wdt@20300 { |
| 11 | compatible = "marvell,orion-wdt"; | 15 | compatible = "marvell,orion-wdt"; |
| 12 | reg = <0x20300 0x28>; | 16 | reg = <0x20300 0x28>; |
| 17 | timeout-sec = <10>; | ||
| 13 | status = "okay"; | 18 | status = "okay"; |
| 14 | }; | 19 | }; |
diff --git a/Documentation/devicetree/bindings/watchdog/pnx4008-wdt.txt b/Documentation/devicetree/bindings/watchdog/pnx4008-wdt.txt index 7c7f6887c796..556d06c17c92 100644 --- a/Documentation/devicetree/bindings/watchdog/pnx4008-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/pnx4008-wdt.txt | |||
| @@ -5,9 +5,13 @@ Required properties: | |||
| 5 | - reg: physical base address of the controller and length of memory mapped | 5 | - reg: physical base address of the controller and length of memory mapped |
| 6 | region. | 6 | region. |
| 7 | 7 | ||
| 8 | Optional properties: | ||
| 9 | - timeout-sec: contains the watchdog timeout in seconds. | ||
| 10 | |||
| 8 | Example: | 11 | Example: |
| 9 | 12 | ||
| 10 | watchdog@4003C000 { | 13 | watchdog@4003C000 { |
| 11 | compatible = "nxp,pnx4008-wdt"; | 14 | compatible = "nxp,pnx4008-wdt"; |
| 12 | reg = <0x4003C000 0x1000>; | 15 | reg = <0x4003C000 0x1000>; |
| 16 | timeout-sec = <10>; | ||
| 13 | }; | 17 | }; |
diff --git a/Documentation/devicetree/bindings/watchdog/qca-ar7130-wdt.txt b/Documentation/devicetree/bindings/watchdog/qca-ar7130-wdt.txt new file mode 100644 index 000000000000..7a89e5f85415 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/qca-ar7130-wdt.txt | |||
| @@ -0,0 +1,13 @@ | |||
| 1 | * Qualcomm Atheros AR7130 Watchdog Timer (WDT) Controller | ||
| 2 | |||
| 3 | Required properties: | ||
| 4 | - compatible: must be "qca,ar7130-wdt" | ||
| 5 | - reg: physical base address of the controller and length of memory mapped | ||
| 6 | region. | ||
| 7 | |||
| 8 | Example: | ||
| 9 | |||
| 10 | wdt@18060008 { | ||
| 11 | compatible = "qca,ar9330-wdt", "qca,ar7130-wdt"; | ||
| 12 | reg = <0x18060008 0x8>; | ||
| 13 | }; | ||
diff --git a/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt b/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt index ce0d8e78ed8f..2aa486cc1ff6 100644 --- a/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt | |||
| @@ -9,3 +9,6 @@ Required properties: | |||
| 9 | - reg : base physical address of the controller and length of memory mapped | 9 | - reg : base physical address of the controller and length of memory mapped |
| 10 | region. | 10 | region. |
| 11 | - interrupts : interrupt number to the cpu. | 11 | - interrupts : interrupt number to the cpu. |
| 12 | |||
| 13 | Optional properties: | ||
| 14 | - timeout-sec : contains the watchdog timeout in seconds. | ||
diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index 0188903bc9e1..4966b1be42ac 100644 --- a/Documentation/dma-buf-sharing.txt +++ b/Documentation/dma-buf-sharing.txt | |||
| @@ -302,7 +302,11 @@ Access to a dma_buf from the kernel context involves three steps: | |||
| 302 | void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) | 302 | void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) |
| 303 | 303 | ||
| 304 | The vmap call can fail if there is no vmap support in the exporter, or if it | 304 | The vmap call can fail if there is no vmap support in the exporter, or if it |
| 305 | runs out of vmalloc space. Fallback to kmap should be implemented. | 305 | runs out of vmalloc space. Fallback to kmap should be implemented. Note that |
| 306 | the dma-buf layer keeps a reference count for all vmap access and calls down | ||
| 307 | into the exporter's vmap function only when no vmapping exists, and only | ||
| 308 | unmaps it once. Protection against concurrent vmap/vunmap calls is provided | ||
| 309 | by taking the dma_buf->lock mutex. | ||
| 306 | 310 | ||
| 307 | 3. Finish access | 311 | 3. Finish access |
| 308 | 312 | ||
diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware index 32bc56b13b1c..5d5ee4c13fa6 100755 --- a/Documentation/dvb/get_dvb_firmware +++ b/Documentation/dvb/get_dvb_firmware | |||
| @@ -23,7 +23,7 @@ use IO::Handle; | |||
| 23 | 23 | ||
| 24 | @components = ( "sp8870", "sp887x", "tda10045", "tda10046", | 24 | @components = ( "sp8870", "sp887x", "tda10045", "tda10046", |
| 25 | "tda10046lifeview", "av7110", "dec2000t", "dec2540t", | 25 | "tda10046lifeview", "av7110", "dec2000t", "dec2540t", |
| 26 | "dec3000s", "vp7041", "dibusb", "nxt2002", "nxt2004", | 26 | "dec3000s", "vp7041", "vp7049", "dibusb", "nxt2002", "nxt2004", |
| 27 | "or51211", "or51132_qam", "or51132_vsb", "bluebird", | 27 | "or51211", "or51132_qam", "or51132_vsb", "bluebird", |
| 28 | "opera1", "cx231xx", "cx18", "cx23885", "pvrusb2", "mpc718", | 28 | "opera1", "cx231xx", "cx18", "cx23885", "pvrusb2", "mpc718", |
| 29 | "af9015", "ngene", "az6027", "lme2510_lg", "lme2510c_s7395", | 29 | "af9015", "ngene", "az6027", "lme2510_lg", "lme2510c_s7395", |
| @@ -289,6 +289,19 @@ sub vp7041 { | |||
| 289 | $outfile; | 289 | $outfile; |
| 290 | } | 290 | } |
| 291 | 291 | ||
| 292 | sub vp7049 { | ||
| 293 | my $fwfile = "dvb-usb-vp7049-0.95.fw"; | ||
| 294 | my $url = "http://ao2.it/sites/default/files/blog/2012/11/06/linux-support-digicom-digitune-s-vp7049-udtt7049/$fwfile"; | ||
| 295 | my $hash = "5609fd295168aea88b25ff43a6f79c36"; | ||
| 296 | |||
| 297 | checkstandard(); | ||
| 298 | |||
| 299 | wgetfile($fwfile, $url); | ||
| 300 | verify($fwfile, $hash); | ||
| 301 | |||
| 302 | $fwfile; | ||
| 303 | } | ||
| 304 | |||
| 292 | sub dibusb { | 305 | sub dibusb { |
| 293 | my $url = "http://www.linuxtv.org/downloads/firmware/dvb-usb-dibusb-5.0.0.11.fw"; | 306 | my $url = "http://www.linuxtv.org/downloads/firmware/dvb-usb-dibusb-5.0.0.11.fw"; |
| 294 | my $outfile = "dvb-dibusb-5.0.0.11.fw"; | 307 | my $outfile = "dvb-dibusb-5.0.0.11.fw"; |
| @@ -677,7 +690,7 @@ sub drxk_terratec_h5 { | |||
| 677 | } | 690 | } |
| 678 | 691 | ||
| 679 | sub drxk_terratec_htc_stick { | 692 | sub drxk_terratec_htc_stick { |
| 680 | my $url = "http://ftp.terratec.de/Receiver/Cinergy_HTC_Stick/Updates/"; | 693 | my $url = "http://ftp.terratec.de/Receiver/Cinergy_HTC_Stick/Updates/History/"; |
| 681 | my $zipfile = "Cinergy_HTC_Stick_Drv_5.09.1202.00_XP_Vista_7.exe"; | 694 | my $zipfile = "Cinergy_HTC_Stick_Drv_5.09.1202.00_XP_Vista_7.exe"; |
| 682 | my $hash = "6722a2442a05423b781721fbc069ed5e"; | 695 | my $hash = "6722a2442a05423b781721fbc069ed5e"; |
| 683 | my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 0); | 696 | my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 0); |
diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index f48e0c6b4c42..0706d32a61e6 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking | |||
| @@ -10,6 +10,7 @@ be able to use diff(1). | |||
| 10 | --------------------------- dentry_operations -------------------------- | 10 | --------------------------- dentry_operations -------------------------- |
| 11 | prototypes: | 11 | prototypes: |
| 12 | int (*d_revalidate)(struct dentry *, unsigned int); | 12 | int (*d_revalidate)(struct dentry *, unsigned int); |
| 13 | int (*d_weak_revalidate)(struct dentry *, unsigned int); | ||
| 13 | int (*d_hash)(const struct dentry *, const struct inode *, | 14 | int (*d_hash)(const struct dentry *, const struct inode *, |
| 14 | struct qstr *); | 15 | struct qstr *); |
| 15 | int (*d_compare)(const struct dentry *, const struct inode *, | 16 | int (*d_compare)(const struct dentry *, const struct inode *, |
| @@ -25,6 +26,7 @@ prototypes: | |||
| 25 | locking rules: | 26 | locking rules: |
| 26 | rename_lock ->d_lock may block rcu-walk | 27 | rename_lock ->d_lock may block rcu-walk |
| 27 | d_revalidate: no no yes (ref-walk) maybe | 28 | d_revalidate: no no yes (ref-walk) maybe |
| 29 | d_weak_revalidate:no no yes no | ||
| 28 | d_hash no no no maybe | 30 | d_hash no no no maybe |
| 29 | d_compare: yes no no maybe | 31 | d_compare: yes no no maybe |
| 30 | d_delete: no yes no no | 32 | d_delete: no yes no no |
diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting index 0472c31c163b..4db22f6491e0 100644 --- a/Documentation/filesystems/porting +++ b/Documentation/filesystems/porting | |||
| @@ -441,3 +441,7 @@ d_make_root() drops the reference to inode if dentry allocation fails. | |||
| 441 | two, it gets "is it an O_EXCL or equivalent?" boolean argument. Note that | 441 | two, it gets "is it an O_EXCL or equivalent?" boolean argument. Note that |
| 442 | local filesystems can ignore tha argument - they are guaranteed that the | 442 | local filesystems can ignore tha argument - they are guaranteed that the |
| 443 | object doesn't exist. It's remote/distributed ones that might care... | 443 | object doesn't exist. It's remote/distributed ones that might care... |
| 444 | -- | ||
| 445 | [mandatory] | ||
| 446 | FS_REVAL_DOT is gone; if you used to have it, add ->d_weak_revalidate() | ||
| 447 | in your dentry operations instead. | ||
diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index e3869098163e..bc4b06b3160a 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt | |||
| @@ -900,6 +900,7 @@ defined: | |||
| 900 | 900 | ||
| 901 | struct dentry_operations { | 901 | struct dentry_operations { |
| 902 | int (*d_revalidate)(struct dentry *, unsigned int); | 902 | int (*d_revalidate)(struct dentry *, unsigned int); |
| 903 | int (*d_weak_revalidate)(struct dentry *, unsigned int); | ||
| 903 | int (*d_hash)(const struct dentry *, const struct inode *, | 904 | int (*d_hash)(const struct dentry *, const struct inode *, |
| 904 | struct qstr *); | 905 | struct qstr *); |
| 905 | int (*d_compare)(const struct dentry *, const struct inode *, | 906 | int (*d_compare)(const struct dentry *, const struct inode *, |
| @@ -915,8 +916,13 @@ struct dentry_operations { | |||
| 915 | 916 | ||
| 916 | d_revalidate: called when the VFS needs to revalidate a dentry. This | 917 | d_revalidate: called when the VFS needs to revalidate a dentry. This |
| 917 | is called whenever a name look-up finds a dentry in the | 918 | is called whenever a name look-up finds a dentry in the |
| 918 | dcache. Most filesystems leave this as NULL, because all their | 919 | dcache. Most local filesystems leave this as NULL, because all their |
| 919 | dentries in the dcache are valid | 920 | dentries in the dcache are valid. Network filesystems are different |
| 921 | since things can change on the server without the client necessarily | ||
| 922 | being aware of it. | ||
| 923 | |||
| 924 | This function should return a positive value if the dentry is still | ||
| 925 | valid, and zero or a negative error code if it isn't. | ||
| 920 | 926 | ||
| 921 | d_revalidate may be called in rcu-walk mode (flags & LOOKUP_RCU). | 927 | d_revalidate may be called in rcu-walk mode (flags & LOOKUP_RCU). |
| 922 | If in rcu-walk mode, the filesystem must revalidate the dentry without | 928 | If in rcu-walk mode, the filesystem must revalidate the dentry without |
| @@ -927,6 +933,20 @@ struct dentry_operations { | |||
| 927 | If a situation is encountered that rcu-walk cannot handle, return | 933 | If a situation is encountered that rcu-walk cannot handle, return |
| 928 | -ECHILD and it will be called again in ref-walk mode. | 934 | -ECHILD and it will be called again in ref-walk mode. |
| 929 | 935 | ||
| 936 | d_weak_revalidate: called when the VFS needs to revalidate a "jumped" dentry. | ||
| 937 | This is called when a path-walk ends at dentry that was not acquired by | ||
| 938 | doing a lookup in the parent directory. This includes "/", "." and "..", | ||
| 939 | as well as procfs-style symlinks and mountpoint traversal. | ||
| 940 | |||
| 941 | In this case, we are less concerned with whether the dentry is still | ||
| 942 | fully correct, but rather that the inode is still valid. As with | ||
| 943 | d_revalidate, most local filesystems will set this to NULL since their | ||
| 944 | dcache entries are always valid. | ||
| 945 | |||
| 946 | This function has the same return code semantics as d_revalidate. | ||
| 947 | |||
| 948 | d_weak_revalidate is only called after leaving rcu-walk mode. | ||
| 949 | |||
| 930 | d_hash: called when the VFS adds a dentry to the hash table. The first | 950 | d_hash: called when the VFS adds a dentry to the hash table. The first |
| 931 | dentry passed to d_hash is the parent directory that the name is | 951 | dentry passed to d_hash is the parent directory that the name is |
| 932 | to be hashed into. The inode is the dentry's inode. | 952 | to be hashed into. The inode is the dentry's inode. |
diff --git a/Documentation/hwmon/adm1275 b/Documentation/hwmon/adm1275 index 2cfa25667123..15b4a20d5062 100644 --- a/Documentation/hwmon/adm1275 +++ b/Documentation/hwmon/adm1275 | |||
| @@ -15,7 +15,7 @@ Supported chips: | |||
| 15 | Addresses scanned: - | 15 | Addresses scanned: - |
| 16 | Datasheet: www.analog.com/static/imported-files/data_sheets/ADM1276.pdf | 16 | Datasheet: www.analog.com/static/imported-files/data_sheets/ADM1276.pdf |
| 17 | 17 | ||
| 18 | Author: Guenter Roeck <guenter.roeck@ericsson.com> | 18 | Author: Guenter Roeck <linux@roeck-us.net> |
| 19 | 19 | ||
| 20 | 20 | ||
| 21 | Description | 21 | Description |
diff --git a/Documentation/hwmon/adt7410 b/Documentation/hwmon/adt7410 index 96004000dc2a..58150c480e56 100644 --- a/Documentation/hwmon/adt7410 +++ b/Documentation/hwmon/adt7410 | |||
| @@ -4,9 +4,14 @@ Kernel driver adt7410 | |||
| 4 | Supported chips: | 4 | Supported chips: |
| 5 | * Analog Devices ADT7410 | 5 | * Analog Devices ADT7410 |
| 6 | Prefix: 'adt7410' | 6 | Prefix: 'adt7410' |
| 7 | Addresses scanned: I2C 0x48 - 0x4B | 7 | Addresses scanned: None |
| 8 | Datasheet: Publicly available at the Analog Devices website | 8 | Datasheet: Publicly available at the Analog Devices website |
| 9 | http://www.analog.com/static/imported-files/data_sheets/ADT7410.pdf | 9 | http://www.analog.com/static/imported-files/data_sheets/ADT7410.pdf |
| 10 | * Analog Devices ADT7420 | ||
| 11 | Prefix: 'adt7420' | ||
| 12 | Addresses scanned: None | ||
| 13 | Datasheet: Publicly available at the Analog Devices website | ||
| 14 | http://www.analog.com/static/imported-files/data_sheets/ADT7420.pdf | ||
| 10 | 15 | ||
| 11 | Author: Hartmut Knaack <knaack.h@gmx.de> | 16 | Author: Hartmut Knaack <knaack.h@gmx.de> |
| 12 | 17 | ||
| @@ -27,6 +32,10 @@ value per second or even justget one sample on demand for power saving. | |||
| 27 | Besides, it can completely power down its ADC, if power management is | 32 | Besides, it can completely power down its ADC, if power management is |
| 28 | required. | 33 | required. |
| 29 | 34 | ||
| 35 | The ADT7420 is register compatible, the only differences being the package, | ||
| 36 | a slightly narrower operating temperature range (-40°C to +150°C), and a | ||
| 37 | better accuracy (0.25°C instead of 0.50°C.) | ||
| 38 | |||
| 30 | Configuration Notes | 39 | Configuration Notes |
| 31 | ------------------- | 40 | ------------------- |
| 32 | 41 | ||
diff --git a/Documentation/hwmon/jc42 b/Documentation/hwmon/jc42 index 165077121238..868d74d6b773 100644 --- a/Documentation/hwmon/jc42 +++ b/Documentation/hwmon/jc42 | |||
| @@ -49,7 +49,7 @@ Supported chips: | |||
| 49 | Addresses scanned: I2C 0x18 - 0x1f | 49 | Addresses scanned: I2C 0x18 - 0x1f |
| 50 | 50 | ||
| 51 | Author: | 51 | Author: |
| 52 | Guenter Roeck <guenter.roeck@ericsson.com> | 52 | Guenter Roeck <linux@roeck-us.net> |
| 53 | 53 | ||
| 54 | 54 | ||
| 55 | Description | 55 | Description |
diff --git a/Documentation/hwmon/lineage-pem b/Documentation/hwmon/lineage-pem index 2ba5ed126858..83b2ddc160c8 100644 --- a/Documentation/hwmon/lineage-pem +++ b/Documentation/hwmon/lineage-pem | |||
| @@ -8,7 +8,7 @@ Supported devices: | |||
| 8 | Documentation: | 8 | Documentation: |
| 9 | http://www.lineagepower.com/oem/pdf/CPLI2C.pdf | 9 | http://www.lineagepower.com/oem/pdf/CPLI2C.pdf |
| 10 | 10 | ||
| 11 | Author: Guenter Roeck <guenter.roeck@ericsson.com> | 11 | Author: Guenter Roeck <linux@roeck-us.net> |
| 12 | 12 | ||
| 13 | 13 | ||
| 14 | Description | 14 | Description |
diff --git a/Documentation/hwmon/lm25066 b/Documentation/hwmon/lm25066 index a21db81c4591..26025e419d35 100644 --- a/Documentation/hwmon/lm25066 +++ b/Documentation/hwmon/lm25066 | |||
| @@ -19,7 +19,7 @@ Supported chips: | |||
| 19 | Datasheet: | 19 | Datasheet: |
| 20 | http://www.national.com/pf/LM/LM5066.html | 20 | http://www.national.com/pf/LM/LM5066.html |
| 21 | 21 | ||
| 22 | Author: Guenter Roeck <guenter.roeck@ericsson.com> | 22 | Author: Guenter Roeck <linux@roeck-us.net> |
| 23 | 23 | ||
| 24 | 24 | ||
| 25 | Description | 25 | Description |
diff --git a/Documentation/hwmon/lm75 b/Documentation/hwmon/lm75 index c91a1d15fa28..69af1c7db6b7 100644 --- a/Documentation/hwmon/lm75 +++ b/Documentation/hwmon/lm75 | |||
| @@ -23,7 +23,7 @@ Supported chips: | |||
| 23 | Datasheet: Publicly available at the Maxim website | 23 | Datasheet: Publicly available at the Maxim website |
| 24 | http://www.maxim-ic.com/ | 24 | http://www.maxim-ic.com/ |
| 25 | * Microchip (TelCom) TCN75 | 25 | * Microchip (TelCom) TCN75 |
| 26 | Prefix: 'lm75' | 26 | Prefix: 'tcn75' |
| 27 | Addresses scanned: none | 27 | Addresses scanned: none |
| 28 | Datasheet: Publicly available at the Microchip website | 28 | Datasheet: Publicly available at the Microchip website |
| 29 | http://www.microchip.com/ | 29 | http://www.microchip.com/ |
diff --git a/Documentation/hwmon/ltc2978 b/Documentation/hwmon/ltc2978 index c365f9beb5dd..e4d75c606c97 100644 --- a/Documentation/hwmon/ltc2978 +++ b/Documentation/hwmon/ltc2978 | |||
| @@ -5,13 +5,13 @@ Supported chips: | |||
| 5 | * Linear Technology LTC2978 | 5 | * Linear Technology LTC2978 |
| 6 | Prefix: 'ltc2978' | 6 | Prefix: 'ltc2978' |
| 7 | Addresses scanned: - | 7 | Addresses scanned: - |
| 8 | Datasheet: http://cds.linear.com/docs/Datasheet/2978fa.pdf | 8 | Datasheet: http://www.linear.com/product/ltc2978 |
| 9 | * Linear Technology LTC3880 | 9 | * Linear Technology LTC3880 |
| 10 | Prefix: 'ltc3880' | 10 | Prefix: 'ltc3880' |
| 11 | Addresses scanned: - | 11 | Addresses scanned: - |
| 12 | Datasheet: http://cds.linear.com/docs/Datasheet/3880f.pdf | 12 | Datasheet: http://www.linear.com/product/ltc3880 |
| 13 | 13 | ||
| 14 | Author: Guenter Roeck <guenter.roeck@ericsson.com> | 14 | Author: Guenter Roeck <linux@roeck-us.net> |
| 15 | 15 | ||
| 16 | 16 | ||
| 17 | Description | 17 | Description |
diff --git a/Documentation/hwmon/ltc4261 b/Documentation/hwmon/ltc4261 index eba2e2c4b94d..9378a75c6134 100644 --- a/Documentation/hwmon/ltc4261 +++ b/Documentation/hwmon/ltc4261 | |||
| @@ -8,7 +8,7 @@ Supported chips: | |||
| 8 | Datasheet: | 8 | Datasheet: |
| 9 | http://cds.linear.com/docs/Datasheet/42612fb.pdf | 9 | http://cds.linear.com/docs/Datasheet/42612fb.pdf |
| 10 | 10 | ||
| 11 | Author: Guenter Roeck <guenter.roeck@ericsson.com> | 11 | Author: Guenter Roeck <linux@roeck-us.net> |
| 12 | 12 | ||
| 13 | 13 | ||
| 14 | Description | 14 | Description |
diff --git a/Documentation/hwmon/max16064 b/Documentation/hwmon/max16064 index f8b478076f6d..d59cc7829bec 100644 --- a/Documentation/hwmon/max16064 +++ b/Documentation/hwmon/max16064 | |||
| @@ -7,7 +7,7 @@ Supported chips: | |||
| 7 | Addresses scanned: - | 7 | Addresses scanned: - |
| 8 | Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX16064.pdf | 8 | Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX16064.pdf |
| 9 | 9 | ||
| 10 | Author: Guenter Roeck <guenter.roeck@ericsson.com> | 10 | Author: Guenter Roeck <linux@roeck-us.net> |
| 11 | 11 | ||
| 12 | 12 | ||
| 13 | Description | 13 | Description |
diff --git a/Documentation/hwmon/max16065 b/Documentation/hwmon/max16065 index c11f64a1f2ad..208a29e43010 100644 --- a/Documentation/hwmon/max16065 +++ b/Documentation/hwmon/max16065 | |||
| @@ -24,7 +24,7 @@ Supported chips: | |||
| 24 | http://datasheets.maxim-ic.com/en/ds/MAX16070-MAX16071.pdf | 24 | http://datasheets.maxim-ic.com/en/ds/MAX16070-MAX16071.pdf |
| 25 | 25 | ||
| 26 | 26 | ||
| 27 | Author: Guenter Roeck <guenter.roeck@ericsson.com> | 27 | Author: Guenter Roeck <linux@roeck-us.net> |
| 28 | 28 | ||
| 29 | 29 | ||
| 30 | Description | 30 | Description |
diff --git a/Documentation/hwmon/max34440 b/Documentation/hwmon/max34440 index 47651ff341ae..37cbf472a19d 100644 --- a/Documentation/hwmon/max34440 +++ b/Documentation/hwmon/max34440 | |||
| @@ -27,7 +27,7 @@ Supported chips: | |||
| 27 | Addresses scanned: - | 27 | Addresses scanned: - |
| 28 | Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX34461.pdf | 28 | Datasheet: http://datasheets.maximintegrated.com/en/ds/MAX34461.pdf |
| 29 | 29 | ||
| 30 | Author: Guenter Roeck <guenter.roeck@ericsson.com> | 30 | Author: Guenter Roeck <linux@roeck-us.net> |
| 31 | 31 | ||
| 32 | 32 | ||
| 33 | Description | 33 | Description |
diff --git a/Documentation/hwmon/max8688 b/Documentation/hwmon/max8688 index fe849871df32..e78078638b91 100644 --- a/Documentation/hwmon/max8688 +++ b/Documentation/hwmon/max8688 | |||
| @@ -7,7 +7,7 @@ Supported chips: | |||
| 7 | Addresses scanned: - | 7 | Addresses scanned: - |
| 8 | Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX8688.pdf | 8 | Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX8688.pdf |
| 9 | 9 | ||
| 10 | Author: Guenter Roeck <guenter.roeck@ericsson.com> | 10 | Author: Guenter Roeck <linux@roeck-us.net> |
| 11 | 11 | ||
| 12 | 12 | ||
| 13 | Description | 13 | Description |
diff --git a/Documentation/hwmon/pmbus b/Documentation/hwmon/pmbus index 3d3a0f97f966..cf756ed48ff9 100644 --- a/Documentation/hwmon/pmbus +++ b/Documentation/hwmon/pmbus | |||
| @@ -34,7 +34,7 @@ Supported chips: | |||
| 34 | Addresses scanned: - | 34 | Addresses scanned: - |
| 35 | Datasheet: n.a. | 35 | Datasheet: n.a. |
| 36 | 36 | ||
| 37 | Author: Guenter Roeck <guenter.roeck@ericsson.com> | 37 | Author: Guenter Roeck <linux@roeck-us.net> |
| 38 | 38 | ||
| 39 | 39 | ||
| 40 | Description | 40 | Description |
diff --git a/Documentation/hwmon/smm665 b/Documentation/hwmon/smm665 index 59e316140542..a341eeedab75 100644 --- a/Documentation/hwmon/smm665 +++ b/Documentation/hwmon/smm665 | |||
| @@ -29,7 +29,7 @@ Supported chips: | |||
| 29 | http://www.summitmicro.com/prod_select/summary/SMM766/SMM766_2086.pdf | 29 | http://www.summitmicro.com/prod_select/summary/SMM766/SMM766_2086.pdf |
| 30 | http://www.summitmicro.com/prod_select/summary/SMM766B/SMM766B_2122.pdf | 30 | http://www.summitmicro.com/prod_select/summary/SMM766B/SMM766B_2122.pdf |
| 31 | 31 | ||
| 32 | Author: Guenter Roeck <guenter.roeck@ericsson.com> | 32 | Author: Guenter Roeck <linux@roeck-us.net> |
| 33 | 33 | ||
| 34 | 34 | ||
| 35 | Module Parameters | 35 | Module Parameters |
diff --git a/Documentation/hwmon/ucd9000 b/Documentation/hwmon/ucd9000 index 0df5f276505b..805e33edb978 100644 --- a/Documentation/hwmon/ucd9000 +++ b/Documentation/hwmon/ucd9000 | |||
| @@ -11,7 +11,7 @@ Supported chips: | |||
| 11 | http://focus.ti.com/lit/ds/symlink/ucd9090.pdf | 11 | http://focus.ti.com/lit/ds/symlink/ucd9090.pdf |
| 12 | http://focus.ti.com/lit/ds/symlink/ucd90910.pdf | 12 | http://focus.ti.com/lit/ds/symlink/ucd90910.pdf |
| 13 | 13 | ||
| 14 | Author: Guenter Roeck <guenter.roeck@ericsson.com> | 14 | Author: Guenter Roeck <linux@roeck-us.net> |
| 15 | 15 | ||
| 16 | 16 | ||
| 17 | Description | 17 | Description |
diff --git a/Documentation/hwmon/ucd9200 b/Documentation/hwmon/ucd9200 index fd7d07b1908a..1e8060e631bd 100644 --- a/Documentation/hwmon/ucd9200 +++ b/Documentation/hwmon/ucd9200 | |||
| @@ -15,7 +15,7 @@ Supported chips: | |||
| 15 | http://focus.ti.com/lit/ds/symlink/ucd9246.pdf | 15 | http://focus.ti.com/lit/ds/symlink/ucd9246.pdf |
| 16 | http://focus.ti.com/lit/ds/symlink/ucd9248.pdf | 16 | http://focus.ti.com/lit/ds/symlink/ucd9248.pdf |
| 17 | 17 | ||
| 18 | Author: Guenter Roeck <guenter.roeck@ericsson.com> | 18 | Author: Guenter Roeck <linux@roeck-us.net> |
| 19 | 19 | ||
| 20 | 20 | ||
| 21 | Description | 21 | Description |
diff --git a/Documentation/hwmon/zl6100 b/Documentation/hwmon/zl6100 index 3d924b6b59e9..756b57c6b73e 100644 --- a/Documentation/hwmon/zl6100 +++ b/Documentation/hwmon/zl6100 | |||
| @@ -54,7 +54,7 @@ http://archive.ericsson.net/service/internet/picov/get?DocNo=28701-EN/LZT146401 | |||
| 54 | http://archive.ericsson.net/service/internet/picov/get?DocNo=28701-EN/LZT146256 | 54 | http://archive.ericsson.net/service/internet/picov/get?DocNo=28701-EN/LZT146256 |
| 55 | 55 | ||
| 56 | 56 | ||
| 57 | Author: Guenter Roeck <guenter.roeck@ericsson.com> | 57 | Author: Guenter Roeck <linux@roeck-us.net> |
| 58 | 58 | ||
| 59 | 59 | ||
| 60 | Description | 60 | Description |
diff --git a/Documentation/i2c/busses/i2c-diolan-u2c b/Documentation/i2c/busses/i2c-diolan-u2c index 30fe4bb9a069..0d6018c316c7 100644 --- a/Documentation/i2c/busses/i2c-diolan-u2c +++ b/Documentation/i2c/busses/i2c-diolan-u2c | |||
| @@ -5,7 +5,7 @@ Supported adapters: | |||
| 5 | Documentation: | 5 | Documentation: |
| 6 | http://www.diolan.com/i2c/u2c12.html | 6 | http://www.diolan.com/i2c/u2c12.html |
| 7 | 7 | ||
| 8 | Author: Guenter Roeck <guenter.roeck@ericsson.com> | 8 | Author: Guenter Roeck <linux@roeck-us.net> |
| 9 | 9 | ||
| 10 | Description | 10 | Description |
| 11 | ----------- | 11 | ----------- |
diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801 index 157416e78cc4..d55b8ab2d10f 100644 --- a/Documentation/i2c/busses/i2c-i801 +++ b/Documentation/i2c/busses/i2c-i801 | |||
| @@ -22,6 +22,8 @@ Supported adapters: | |||
| 22 | * Intel Panther Point (PCH) | 22 | * Intel Panther Point (PCH) |
| 23 | * Intel Lynx Point (PCH) | 23 | * Intel Lynx Point (PCH) |
| 24 | * Intel Lynx Point-LP (PCH) | 24 | * Intel Lynx Point-LP (PCH) |
| 25 | * Intel Avoton (SOC) | ||
| 26 | * Intel Wellsburg (PCH) | ||
| 25 | Datasheets: Publicly available at the Intel website | 27 | Datasheets: Publicly available at the Intel website |
| 26 | 28 | ||
| 27 | On Intel Patsburg and later chipsets, both the normal host SMBus controller | 29 | On Intel Patsburg and later chipsets, both the normal host SMBus controller |
diff --git a/Documentation/i2c/busses/i2c-ismt b/Documentation/i2c/busses/i2c-ismt new file mode 100644 index 000000000000..737355822c0b --- /dev/null +++ b/Documentation/i2c/busses/i2c-ismt | |||
| @@ -0,0 +1,36 @@ | |||
| 1 | Kernel driver i2c-ismt | ||
| 2 | |||
| 3 | Supported adapters: | ||
| 4 | * Intel S12xx series SOCs | ||
| 5 | |||
| 6 | Authors: | ||
| 7 | Bill Brown <bill.e.brown@intel.com> | ||
| 8 | |||
| 9 | |||
| 10 | Module Parameters | ||
| 11 | ----------------- | ||
| 12 | |||
| 13 | * bus_speed (unsigned int) | ||
| 14 | Allows changing of the bus speed. Normally, the bus speed is set by the BIOS | ||
| 15 | and never needs to be changed. However, some SMBus analyzers are too slow for | ||
| 16 | monitoring the bus during debug, thus the need for this module parameter. | ||
| 17 | Specify the bus speed in kHz. | ||
| 18 | Available bus frequency settings: | ||
| 19 | 0 no change | ||
| 20 | 80 kHz | ||
| 21 | 100 kHz | ||
| 22 | 400 kHz | ||
| 23 | 1000 kHz | ||
| 24 | |||
| 25 | |||
| 26 | Description | ||
| 27 | ----------- | ||
| 28 | |||
| 29 | The S12xx series of SOCs have a pair of integrated SMBus 2.0 controllers | ||
| 30 | targeted primarily at the microserver and storage markets. | ||
| 31 | |||
| 32 | The S12xx series contain a pair of PCI functions. An output of lspci will show | ||
| 33 | something similar to the following: | ||
| 34 | |||
| 35 | 00:13.0 System peripheral: Intel Corporation Centerton SMBus 2.0 Controller 0 | ||
| 36 | 00:13.1 System peripheral: Intel Corporation Centerton SMBus 2.0 Controller 1 | ||
diff --git a/Documentation/i2c/busses/i2c-sis630 b/Documentation/i2c/busses/i2c-sis630 index 0b9697366930..ee7943631074 100644 --- a/Documentation/i2c/busses/i2c-sis630 +++ b/Documentation/i2c/busses/i2c-sis630 | |||
| @@ -4,9 +4,11 @@ Supported adapters: | |||
| 4 | * Silicon Integrated Systems Corp (SiS) | 4 | * Silicon Integrated Systems Corp (SiS) |
| 5 | 630 chipset (Datasheet: available at http://www.sfr-fresh.com/linux) | 5 | 630 chipset (Datasheet: available at http://www.sfr-fresh.com/linux) |
| 6 | 730 chipset | 6 | 730 chipset |
| 7 | 964 chipset | ||
| 7 | * Possible other SiS chipsets ? | 8 | * Possible other SiS chipsets ? |
| 8 | 9 | ||
| 9 | Author: Alexander Malysh <amalysh@web.de> | 10 | Author: Alexander Malysh <amalysh@web.de> |
| 11 | Amaury Decrême <amaury.decreme@gmail.com> - SiS964 support | ||
| 10 | 12 | ||
| 11 | Module Parameters | 13 | Module Parameters |
| 12 | ----------------- | 14 | ----------------- |
| @@ -18,6 +20,7 @@ Module Parameters | |||
| 18 | * high_clock = [1|0] Forcibly set Host Master Clock to 56KHz (default, | 20 | * high_clock = [1|0] Forcibly set Host Master Clock to 56KHz (default, |
| 19 | what your BIOS use). DANGEROUS! This should be a bit | 21 | what your BIOS use). DANGEROUS! This should be a bit |
| 20 | faster, but freeze some systems (i.e. my Laptop). | 22 | faster, but freeze some systems (i.e. my Laptop). |
| 23 | SIS630/730 chip only. | ||
| 21 | 24 | ||
| 22 | 25 | ||
| 23 | Description | 26 | Description |
| @@ -36,6 +39,12 @@ or like this: | |||
| 36 | 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 730 Host (rev 02) | 39 | 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 730 Host (rev 02) |
| 37 | 00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513 | 40 | 00:01.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513 |
| 38 | 41 | ||
| 42 | or like this: | ||
| 43 | |||
| 44 | 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 760/M760 Host (rev 02) | ||
| 45 | 00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS964 [MuTIOL Media IO] | ||
| 46 | LPC Controller (rev 36) | ||
| 47 | |||
| 39 | in your 'lspci' output , then this driver is for your chipset. | 48 | in your 'lspci' output , then this driver is for your chipset. |
| 40 | 49 | ||
| 41 | Thank You | 50 | Thank You |
diff --git a/Documentation/i2c/smbus-protocol b/Documentation/i2c/smbus-protocol index d1f22618e14b..6012b12b3510 100644 --- a/Documentation/i2c/smbus-protocol +++ b/Documentation/i2c/smbus-protocol | |||
| @@ -137,8 +137,8 @@ available for writes where the two data bytes are the other way | |||
| 137 | around (not SMBus compliant, but very popular.) | 137 | around (not SMBus compliant, but very popular.) |
| 138 | 138 | ||
| 139 | 139 | ||
| 140 | SMBus Process Call: i2c_smbus_process_call() | 140 | SMBus Process Call: |
| 141 | ============================================= | 141 | =================== |
| 142 | 142 | ||
| 143 | This command selects a device register (through the Comm byte), sends | 143 | This command selects a device register (through the Comm byte), sends |
| 144 | 16 bits of data to it, and reads 16 bits of data in return. | 144 | 16 bits of data to it, and reads 16 bits of data in return. |
diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients index 3a94b0e6f601..6b344b516bff 100644 --- a/Documentation/i2c/writing-clients +++ b/Documentation/i2c/writing-clients | |||
| @@ -365,8 +365,6 @@ in terms of it. Never use this function directly! | |||
| 365 | s32 i2c_smbus_read_word_data(struct i2c_client *client, u8 command); | 365 | s32 i2c_smbus_read_word_data(struct i2c_client *client, u8 command); |
| 366 | s32 i2c_smbus_write_word_data(struct i2c_client *client, | 366 | s32 i2c_smbus_write_word_data(struct i2c_client *client, |
| 367 | u8 command, u16 value); | 367 | u8 command, u16 value); |
| 368 | s32 i2c_smbus_process_call(struct i2c_client *client, | ||
| 369 | u8 command, u16 value); | ||
| 370 | s32 i2c_smbus_read_block_data(struct i2c_client *client, | 368 | s32 i2c_smbus_read_block_data(struct i2c_client *client, |
| 371 | u8 command, u8 *values); | 369 | u8 command, u8 *values); |
| 372 | s32 i2c_smbus_write_block_data(struct i2c_client *client, | 370 | s32 i2c_smbus_write_block_data(struct i2c_client *client, |
| @@ -381,6 +379,8 @@ These ones were removed from i2c-core because they had no users, but could | |||
| 381 | be added back later if needed: | 379 | be added back later if needed: |
| 382 | 380 | ||
| 383 | s32 i2c_smbus_write_quick(struct i2c_client *client, u8 value); | 381 | s32 i2c_smbus_write_quick(struct i2c_client *client, u8 value); |
| 382 | s32 i2c_smbus_process_call(struct i2c_client *client, | ||
| 383 | u8 command, u16 value); | ||
| 384 | s32 i2c_smbus_block_process_call(struct i2c_client *client, | 384 | s32 i2c_smbus_block_process_call(struct i2c_client *client, |
| 385 | u8 command, u8 length, u8 *values); | 385 | u8 command, u8 length, u8 *values); |
| 386 | 386 | ||
diff --git a/Documentation/input/alps.txt b/Documentation/input/alps.txt index 3262b6e4d686..e544c7ff8cfa 100644 --- a/Documentation/input/alps.txt +++ b/Documentation/input/alps.txt | |||
| @@ -3,10 +3,26 @@ ALPS Touchpad Protocol | |||
| 3 | 3 | ||
| 4 | Introduction | 4 | Introduction |
| 5 | ------------ | 5 | ------------ |
| 6 | 6 | Currently the ALPS touchpad driver supports five protocol versions in use by | |
| 7 | Currently the ALPS touchpad driver supports four protocol versions in use by | 7 | ALPS touchpads, called versions 1, 2, 3, 4 and 5. |
| 8 | ALPS touchpads, called versions 1, 2, 3, and 4. Information about the various | 8 | |
| 9 | protocol versions is contained in the following sections. | 9 | Since roughly mid-2010 several new ALPS touchpads have been released and |
| 10 | integrated into a variety of laptops and netbooks. These new touchpads | ||
| 11 | have enough behavior differences that the alps_model_data definition | ||
| 12 | table, describing the properties of the different versions, is no longer | ||
| 13 | adequate. The design choices were to re-define the alps_model_data | ||
| 14 | table, with the risk of regression testing existing devices, or isolate | ||
| 15 | the new devices outside of the alps_model_data table. The latter design | ||
| 16 | choice was made. The new touchpad signatures are named: "Rushmore", | ||
| 17 | "Pinnacle", and "Dolphin", which you will see in the alps.c code. | ||
| 18 | For the purposes of this document, this group of ALPS touchpads will | ||
| 19 | generically be called "new ALPS touchpads". | ||
| 20 | |||
| 21 | We experimented with probing the ACPI interface _HID (Hardware ID)/_CID | ||
| 22 | (Compatibility ID) definition as a way to uniquely identify the | ||
| 23 | different ALPS variants but there did not appear to be a 1:1 mapping. | ||
| 24 | In fact, it appeared to be an m:n mapping between the _HID and actual | ||
| 25 | hardware type. | ||
| 10 | 26 | ||
| 11 | Detection | 27 | Detection |
| 12 | --------- | 28 | --------- |
| @@ -20,9 +36,13 @@ If the E6 report is successful, the touchpad model is identified using the "E7 | |||
| 20 | report" sequence: E8-E7-E7-E7-E9. The response is the model signature and is | 36 | report" sequence: E8-E7-E7-E7-E9. The response is the model signature and is |
| 21 | matched against known models in the alps_model_data_array. | 37 | matched against known models in the alps_model_data_array. |
| 22 | 38 | ||
| 23 | With protocol versions 3 and 4, the E7 report model signature is always | 39 | For older touchpads supporting protocol versions 3 and 4, the E7 report |
| 24 | 73-02-64. To differentiate between these versions, the response from the | 40 | model signature is always 73-02-64. To differentiate between these |
| 25 | "Enter Command Mode" sequence must be inspected as described below. | 41 | versions, the response from the "Enter Command Mode" sequence must be |
| 42 | inspected as described below. | ||
| 43 | |||
| 44 | The new ALPS touchpads have an E7 signature of 73-03-50 or 73-03-0A but | ||
| 45 | seem to be better differentiated by the EC Command Mode response. | ||
| 26 | 46 | ||
| 27 | Command Mode | 47 | Command Mode |
| 28 | ------------ | 48 | ------------ |
| @@ -47,6 +67,14 @@ address of the register being read, and the third contains the value of the | |||
| 47 | register. Registers are written by writing the value one nibble at a time | 67 | register. Registers are written by writing the value one nibble at a time |
| 48 | using the same encoding used for addresses. | 68 | using the same encoding used for addresses. |
| 49 | 69 | ||
| 70 | For the new ALPS touchpads, the EC command is used to enter command | ||
| 71 | mode. The response in the new ALPS touchpads is significantly different, | ||
| 72 | and more important in determining the behavior. This code has been | ||
| 73 | separated from the original alps_model_data table and put in the | ||
| 74 | alps_identify function. For example, there seem to be two hardware init | ||
| 75 | sequences for the "Dolphin" touchpads as determined by the second byte | ||
| 76 | of the EC response. | ||
| 77 | |||
| 50 | Packet Format | 78 | Packet Format |
| 51 | ------------- | 79 | ------------- |
| 52 | 80 | ||
| @@ -187,3 +215,28 @@ There are several things worth noting here. | |||
| 187 | well. | 215 | well. |
| 188 | 216 | ||
| 189 | So far no v4 devices with tracksticks have been encountered. | 217 | So far no v4 devices with tracksticks have been encountered. |
| 218 | |||
| 219 | ALPS Absolute Mode - Protocol Version 5 | ||
| 220 | --------------------------------------- | ||
| 221 | This is basically Protocol Version 3 but with different logic for packet | ||
| 222 | decode. It uses the same alps_process_touchpad_packet_v3 call with a | ||
| 223 | specialized decode_fields function pointer to correctly interpret the | ||
| 224 | packets. This appears to only be used by the Dolphin devices. | ||
| 225 | |||
| 226 | For single-touch, the 6-byte packet format is: | ||
| 227 | |||
| 228 | byte 0: 1 1 0 0 1 0 0 0 | ||
| 229 | byte 1: 0 x6 x5 x4 x3 x2 x1 x0 | ||
| 230 | byte 2: 0 y6 y5 y4 y3 y2 y1 y0 | ||
| 231 | byte 3: 0 M R L 1 m r l | ||
| 232 | byte 4: y10 y9 y8 y7 x10 x9 x8 x7 | ||
| 233 | byte 5: 0 z6 z5 z4 z3 z2 z1 z0 | ||
| 234 | |||
| 235 | For mt, the format is: | ||
| 236 | |||
| 237 | byte 0: 1 1 1 n3 1 n2 n1 x24 | ||
| 238 | byte 1: 1 y7 y6 y5 y4 y3 y2 y1 | ||
| 239 | byte 2: ? x2 x1 y12 y11 y10 y9 y8 | ||
| 240 | byte 3: 0 x23 x22 x21 x20 x19 x18 x17 | ||
| 241 | byte 4: 0 x9 x8 x7 x6 x5 x4 x3 | ||
| 242 | byte 5: 0 x16 x15 x14 x13 x12 x11 x10 | ||
diff --git a/Documentation/kbuild/kconfig-language.txt b/Documentation/kbuild/kconfig-language.txt index a686f9cd69c1..c858f8419eba 100644 --- a/Documentation/kbuild/kconfig-language.txt +++ b/Documentation/kbuild/kconfig-language.txt | |||
| @@ -388,26 +388,3 @@ config FOO | |||
| 388 | depends on BAR && m | 388 | depends on BAR && m |
| 389 | 389 | ||
| 390 | limits FOO to module (=m) or disabled (=n). | 390 | limits FOO to module (=m) or disabled (=n). |
| 391 | |||
| 392 | Kconfig symbol existence | ||
| 393 | ~~~~~~~~~~~~~~~~~~~~~~~~ | ||
| 394 | The following two methods produce the same kconfig symbol dependencies | ||
| 395 | but differ greatly in kconfig symbol existence (production) in the | ||
| 396 | generated config file. | ||
| 397 | |||
| 398 | case 1: | ||
| 399 | |||
| 400 | config FOO | ||
| 401 | tristate "about foo" | ||
| 402 | depends on BAR | ||
| 403 | |||
| 404 | vs. case 2: | ||
| 405 | |||
| 406 | if BAR | ||
| 407 | config FOO | ||
| 408 | tristate "about foo" | ||
| 409 | endif | ||
| 410 | |||
| 411 | In case 1, the symbol FOO will always exist in the config file (given | ||
| 412 | no other dependencies). In case 2, the symbol FOO will only exist in | ||
| 413 | the config file if BAR is enabled. | ||
diff --git a/Documentation/kbuild/kconfig.txt b/Documentation/kbuild/kconfig.txt index a09f1a6a830c..b8b77bbc784f 100644 --- a/Documentation/kbuild/kconfig.txt +++ b/Documentation/kbuild/kconfig.txt | |||
| @@ -46,6 +46,12 @@ KCONFIG_OVERWRITECONFIG | |||
| 46 | If you set KCONFIG_OVERWRITECONFIG in the environment, Kconfig will not | 46 | If you set KCONFIG_OVERWRITECONFIG in the environment, Kconfig will not |
| 47 | break symlinks when .config is a symlink to somewhere else. | 47 | break symlinks when .config is a symlink to somewhere else. |
| 48 | 48 | ||
| 49 | CONFIG_ | ||
| 50 | -------------------------------------------------- | ||
| 51 | If you set CONFIG_ in the environment, Kconfig will prefix all symbols | ||
| 52 | with its value when saving the configuration, instead of using the default, | ||
| 53 | "CONFIG_". | ||
| 54 | |||
| 49 | ______________________________________________________________________ | 55 | ______________________________________________________________________ |
| 50 | Environment variables for '{allyes/allmod/allno/rand}config' | 56 | Environment variables for '{allyes/allmod/allno/rand}config' |
| 51 | 57 | ||
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 766087781ecd..4609e81dbc37 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt | |||
| @@ -564,6 +564,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted. | |||
| 564 | UART at the specified I/O port or MMIO address, | 564 | UART at the specified I/O port or MMIO address, |
| 565 | switching to the matching ttyS device later. The | 565 | switching to the matching ttyS device later. The |
| 566 | options are the same as for ttyS, above. | 566 | options are the same as for ttyS, above. |
| 567 | hvc<n> Use the hypervisor console device <n>. This is for | ||
| 568 | both Xen and PowerPC hypervisors. | ||
| 567 | 569 | ||
| 568 | If the device connected to the port is not a TTY but a braille | 570 | If the device connected to the port is not a TTY but a braille |
| 569 | device, prepend "brl," before the device type, for instance | 571 | device, prepend "brl," before the device type, for instance |
| @@ -757,6 +759,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. | |||
| 757 | 759 | ||
| 758 | earlyprintk= [X86,SH,BLACKFIN] | 760 | earlyprintk= [X86,SH,BLACKFIN] |
| 759 | earlyprintk=vga | 761 | earlyprintk=vga |
| 762 | earlyprintk=xen | ||
| 760 | earlyprintk=serial[,ttySn[,baudrate]] | 763 | earlyprintk=serial[,ttySn[,baudrate]] |
| 761 | earlyprintk=ttySn[,baudrate] | 764 | earlyprintk=ttySn[,baudrate] |
| 762 | earlyprintk=dbgp[debugController#] | 765 | earlyprintk=dbgp[debugController#] |
| @@ -774,6 +777,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted. | |||
| 774 | The VGA output is eventually overwritten by the real | 777 | The VGA output is eventually overwritten by the real |
| 775 | console. | 778 | console. |
| 776 | 779 | ||
| 780 | The xen output can only be used by Xen PV guests. | ||
| 781 | |||
| 777 | ekgdboc= [X86,KGDB] Allow early kernel console debugging | 782 | ekgdboc= [X86,KGDB] Allow early kernel console debugging |
| 778 | ekgdboc=kbd | 783 | ekgdboc=kbd |
| 779 | 784 | ||
| @@ -973,6 +978,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted. | |||
| 973 | If specified, z/VM IUCV HVC accepts connections | 978 | If specified, z/VM IUCV HVC accepts connections |
| 974 | from listed z/VM user IDs only. | 979 | from listed z/VM user IDs only. |
| 975 | 980 | ||
| 981 | hwthread_map= [METAG] Comma-separated list of Linux cpu id to | ||
| 982 | hardware thread id mappings. | ||
| 983 | Format: <cpu>:<hwthread> | ||
| 984 | |||
| 976 | keep_bootcon [KNL] | 985 | keep_bootcon [KNL] |
| 977 | Do not unregister boot console at start. This is only | 986 | Do not unregister boot console at start. This is only |
| 978 | useful for debugging when something happens in the window | 987 | useful for debugging when something happens in the window |
| @@ -1640,42 +1649,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted. | |||
| 1640 | that the amount of memory usable for all allocations | 1649 | that the amount of memory usable for all allocations |
| 1641 | is not too small. | 1650 | is not too small. |
| 1642 | 1651 | ||
| 1643 | movablemem_map=acpi | ||
| 1644 | [KNL,X86,IA-64,PPC] This parameter is similar to | ||
| 1645 | memmap except it specifies the memory map of | ||
| 1646 | ZONE_MOVABLE. | ||
| 1647 | This option inform the kernel to use Hot Pluggable bit | ||
| 1648 | in flags from SRAT from ACPI BIOS to determine which | ||
| 1649 | memory devices could be hotplugged. The corresponding | ||
| 1650 | memory ranges will be set as ZONE_MOVABLE. | ||
| 1651 | NOTE: Whatever node the kernel resides in will always | ||
| 1652 | be un-hotpluggable. | ||
| 1653 | |||
| 1654 | movablemem_map=nn[KMG]@ss[KMG] | ||
| 1655 | [KNL,X86,IA-64,PPC] This parameter is similar to | ||
| 1656 | memmap except it specifies the memory map of | ||
| 1657 | ZONE_MOVABLE. | ||
| 1658 | If user specifies memory ranges, the info in SRAT will | ||
| 1659 | be ingored. And it works like the following: | ||
| 1660 | - If more ranges are all within one node, then from | ||
| 1661 | lowest ss to the end of the node will be ZONE_MOVABLE. | ||
| 1662 | - If a range is within a node, then from ss to the end | ||
| 1663 | of the node will be ZONE_MOVABLE. | ||
| 1664 | - If a range covers two or more nodes, then from ss to | ||
| 1665 | the end of the 1st node will be ZONE_MOVABLE, and all | ||
| 1666 | the rest nodes will only have ZONE_MOVABLE. | ||
| 1667 | If memmap is specified at the same time, the | ||
| 1668 | movablemem_map will be limited within the memmap | ||
| 1669 | areas. If kernelcore or movablecore is also specified, | ||
| 1670 | movablemem_map will have higher priority to be | ||
| 1671 | satisfied. So the administrator should be careful that | ||
| 1672 | the amount of movablemem_map areas are not too large. | ||
| 1673 | Otherwise kernel won't have enough memory to start. | ||
| 1674 | NOTE: We don't stop users specifying the node the | ||
| 1675 | kernel resides in as hotpluggable so that this | ||
| 1676 | option can be used as a workaround of firmware | ||
| 1677 | bugs. | ||
| 1678 | |||
| 1679 | MTD_Partition= [MTD] | 1652 | MTD_Partition= [MTD] |
| 1680 | Format: <name>,<region-number>,<size>,<offset> | 1653 | Format: <name>,<region-number>,<size>,<offset> |
| 1681 | 1654 | ||
| @@ -2262,6 +2235,21 @@ bytes respectively. Such letter suffixes can also be entirely omitted. | |||
| 2262 | This sorting is done to get a device | 2235 | This sorting is done to get a device |
| 2263 | order compatible with older (<= 2.4) kernels. | 2236 | order compatible with older (<= 2.4) kernels. |
| 2264 | nobfsort Don't sort PCI devices into breadth-first order. | 2237 | nobfsort Don't sort PCI devices into breadth-first order. |
| 2238 | pcie_bus_tune_off Disable PCIe MPS (Max Payload Size) | ||
| 2239 | tuning and use the BIOS-configured MPS defaults. | ||
| 2240 | pcie_bus_safe Set every device's MPS to the largest value | ||
| 2241 | supported by all devices below the root complex. | ||
| 2242 | pcie_bus_perf Set device MPS to the largest allowable MPS | ||
| 2243 | based on its parent bus. Also set MRRS (Max | ||
| 2244 | Read Request Size) to the largest supported | ||
| 2245 | value (no larger than the MPS that the device | ||
| 2246 | or bus can support) for best performance. | ||
| 2247 | pcie_bus_peer2peer Set every device's MPS to 128B, which | ||
| 2248 | every device is guaranteed to support. This | ||
| 2249 | configuration allows peer-to-peer DMA between | ||
| 2250 | any pair of devices, possibly at the cost of | ||
| 2251 | reduced performance. This also guarantees | ||
| 2252 | that hot-added devices will work. | ||
| 2265 | cbiosize=nn[KMG] The fixed amount of bus space which is | 2253 | cbiosize=nn[KMG] The fixed amount of bus space which is |
| 2266 | reserved for the CardBus bridge's IO window. | 2254 | reserved for the CardBus bridge's IO window. |
| 2267 | The default value is 256 bytes. | 2255 | The default value is 256 bytes. |
| @@ -2283,6 +2271,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted. | |||
| 2283 | the default. | 2271 | the default. |
| 2284 | off: Turn ECRC off | 2272 | off: Turn ECRC off |
| 2285 | on: Turn ECRC on. | 2273 | on: Turn ECRC on. |
| 2274 | hpiosize=nn[KMG] The fixed amount of bus space which is | ||
| 2275 | reserved for hotplug bridge's IO window. | ||
| 2276 | Default size is 256 bytes. | ||
| 2277 | hpmemsize=nn[KMG] The fixed amount of bus space which is | ||
| 2278 | reserved for hotplug bridge's memory window. | ||
| 2279 | Default size is 2 megabytes. | ||
| 2286 | realloc= Enable/disable reallocating PCI bridge resources | 2280 | realloc= Enable/disable reallocating PCI bridge resources |
| 2287 | if allocations done by BIOS are too small to | 2281 | if allocations done by BIOS are too small to |
| 2288 | accommodate resources required by all child | 2282 | accommodate resources required by all child |
diff --git a/Documentation/leds/00-INDEX b/Documentation/leds/00-INDEX index 5fefe374892f..5246090ef15c 100644 --- a/Documentation/leds/00-INDEX +++ b/Documentation/leds/00-INDEX | |||
| @@ -6,5 +6,7 @@ leds-lp5521.txt | |||
| 6 | - notes on how to use the leds-lp5521 driver. | 6 | - notes on how to use the leds-lp5521 driver. |
| 7 | leds-lp5523.txt | 7 | leds-lp5523.txt |
| 8 | - notes on how to use the leds-lp5523 driver. | 8 | - notes on how to use the leds-lp5523 driver. |
| 9 | leds-lp55xx.txt | ||
| 10 | - description about lp55xx common driver. | ||
| 9 | leds-lm3556.txt | 11 | leds-lm3556.txt |
| 10 | - notes on how to use the leds-lm3556 driver. | 12 | - notes on how to use the leds-lm3556 driver. |
diff --git a/Documentation/leds/leds-lp5521.txt b/Documentation/leds/leds-lp5521.txt index 0e542ab3d4a0..270f57196339 100644 --- a/Documentation/leds/leds-lp5521.txt +++ b/Documentation/leds/leds-lp5521.txt | |||
| @@ -17,19 +17,8 @@ lp5521:channelx, where x is 0 .. 2 | |||
| 17 | All three channels can be also controlled using the engine micro programs. | 17 | All three channels can be also controlled using the engine micro programs. |
| 18 | More details of the instructions can be found from the public data sheet. | 18 | More details of the instructions can be found from the public data sheet. |
| 19 | 19 | ||
| 20 | Control interface for the engines: | 20 | LP5521 has the internal program memory for running various LED patterns. |
| 21 | x is 1 .. 3 | 21 | For the details, please refer to 'firmware' section in leds-lp55xx.txt |
| 22 | enginex_mode : disabled, load, run | ||
| 23 | enginex_load : store program (visible only in engine load mode) | ||
| 24 | |||
| 25 | Example (start to blink the channel 2 led): | ||
| 26 | cd /sys/class/leds/lp5521:channel2/device | ||
| 27 | echo "load" > engine3_mode | ||
| 28 | echo "037f4d0003ff6000" > engine3_load | ||
| 29 | echo "run" > engine3_mode | ||
| 30 | |||
| 31 | stop the engine: | ||
| 32 | echo "disabled" > engine3_mode | ||
| 33 | 22 | ||
| 34 | sysfs contains a selftest entry. | 23 | sysfs contains a selftest entry. |
| 35 | The test communicates with the chip and checks that | 24 | The test communicates with the chip and checks that |
| @@ -47,7 +36,7 @@ The name of each channel can be configurable. | |||
| 47 | If the name field is not defined, the default name will be set to 'xxxx:channelN' | 36 | If the name field is not defined, the default name will be set to 'xxxx:channelN' |
| 48 | (XXXX : pdata->label or i2c client name, N : channel number) | 37 | (XXXX : pdata->label or i2c client name, N : channel number) |
| 49 | 38 | ||
| 50 | static struct lp5521_led_config lp5521_led_config[] = { | 39 | static struct lp55xx_led_config lp5521_led_config[] = { |
| 51 | { | 40 | { |
| 52 | .name = "red", | 41 | .name = "red", |
| 53 | .chan_nr = 0, | 42 | .chan_nr = 0, |
| @@ -81,10 +70,10 @@ static void lp5521_enable(bool state) | |||
| 81 | /* Control of chip enable signal */ | 70 | /* Control of chip enable signal */ |
| 82 | } | 71 | } |
| 83 | 72 | ||
| 84 | static struct lp5521_platform_data lp5521_platform_data = { | 73 | static struct lp55xx_platform_data lp5521_platform_data = { |
| 85 | .led_config = lp5521_led_config, | 74 | .led_config = lp5521_led_config, |
| 86 | .num_channels = ARRAY_SIZE(lp5521_led_config), | 75 | .num_channels = ARRAY_SIZE(lp5521_led_config), |
| 87 | .clock_mode = LP5521_CLOCK_EXT, | 76 | .clock_mode = LP55XX_CLOCK_EXT, |
| 88 | .setup_resources = lp5521_setup, | 77 | .setup_resources = lp5521_setup, |
| 89 | .release_resources = lp5521_release, | 78 | .release_resources = lp5521_release, |
| 90 | .enable = lp5521_enable, | 79 | .enable = lp5521_enable, |
| @@ -105,47 +94,9 @@ example of update_config : | |||
| 105 | LP5521_CP_MODE_AUTO | LP5521_R_TO_BATT | \ | 94 | LP5521_CP_MODE_AUTO | LP5521_R_TO_BATT | \ |
| 106 | LP5521_CLK_INT) | 95 | LP5521_CLK_INT) |
| 107 | 96 | ||
| 108 | static struct lp5521_platform_data lp5521_pdata = { | 97 | static struct lp55xx_platform_data lp5521_pdata = { |
| 109 | .led_config = lp5521_led_config, | 98 | .led_config = lp5521_led_config, |
| 110 | .num_channels = ARRAY_SIZE(lp5521_led_config), | 99 | .num_channels = ARRAY_SIZE(lp5521_led_config), |
| 111 | .clock_mode = LP5521_CLOCK_INT, | 100 | .clock_mode = LP55XX_CLOCK_INT, |
| 112 | .update_config = LP5521_CONFIGS, | 101 | .update_config = LP5521_CONFIGS, |
| 113 | }; | 102 | }; |
| 114 | |||
| 115 | LED patterns : LP5521 has autonomous operation without external control. | ||
| 116 | Pattern data can be defined in the platform data. | ||
| 117 | |||
| 118 | example of led pattern data : | ||
| 119 | |||
| 120 | /* RGB(50,5,0) 500ms on, 500ms off, infinite loop */ | ||
| 121 | static u8 pattern_red[] = { | ||
| 122 | 0x40, 0x32, 0x60, 0x00, 0x40, 0x00, 0x60, 0x00, | ||
| 123 | }; | ||
| 124 | |||
| 125 | static u8 pattern_green[] = { | ||
| 126 | 0x40, 0x05, 0x60, 0x00, 0x40, 0x00, 0x60, 0x00, | ||
| 127 | }; | ||
| 128 | |||
| 129 | static struct lp5521_led_pattern board_led_patterns[] = { | ||
| 130 | { | ||
| 131 | .r = pattern_red, | ||
| 132 | .g = pattern_green, | ||
| 133 | .size_r = ARRAY_SIZE(pattern_red), | ||
| 134 | .size_g = ARRAY_SIZE(pattern_green), | ||
| 135 | }, | ||
| 136 | }; | ||
| 137 | |||
| 138 | static struct lp5521_platform_data lp5521_platform_data = { | ||
| 139 | .led_config = lp5521_led_config, | ||
| 140 | .num_channels = ARRAY_SIZE(lp5521_led_config), | ||
| 141 | .clock_mode = LP5521_CLOCK_EXT, | ||
| 142 | .patterns = board_led_patterns, | ||
| 143 | .num_patterns = ARRAY_SIZE(board_led_patterns), | ||
| 144 | }; | ||
| 145 | |||
| 146 | Then predefined led pattern(s) can be executed via the sysfs. | ||
| 147 | To start the pattern #1, | ||
| 148 | # echo 1 > /sys/bus/i2c/devices/xxxx/led_pattern | ||
| 149 | (xxxx : i2c bus & slave address) | ||
| 150 | To end the pattern, | ||
| 151 | # echo 0 > /sys/bus/i2c/devices/xxxx/led_pattern | ||
diff --git a/Documentation/leds/leds-lp5523.txt b/Documentation/leds/leds-lp5523.txt index c2743f59f9ac..899fdad509fe 100644 --- a/Documentation/leds/leds-lp5523.txt +++ b/Documentation/leds/leds-lp5523.txt | |||
| @@ -27,25 +27,8 @@ c) Default | |||
| 27 | If both fields are NULL, 'lp5523' is used by default. | 27 | If both fields are NULL, 'lp5523' is used by default. |
| 28 | /sys/class/leds/lp5523:channelN (N: 0 ~ 8) | 28 | /sys/class/leds/lp5523:channelN (N: 0 ~ 8) |
| 29 | 29 | ||
| 30 | The chip provides 3 engines. Each engine can control channels without | 30 | LP5523 has the internal program memory for running various LED patterns. |
| 31 | interaction from the main CPU. Details of the micro engine code can be found | 31 | For the details, please refer to 'firmware' section in leds-lp55xx.txt |
| 32 | from the public data sheet. Leds can be muxed to different channels. | ||
| 33 | |||
| 34 | Control interface for the engines: | ||
| 35 | x is 1 .. 3 | ||
| 36 | enginex_mode : disabled, load, run | ||
| 37 | enginex_load : microcode load (visible only in load mode) | ||
| 38 | enginex_leds : led mux control (visible only in load mode) | ||
| 39 | |||
| 40 | cd /sys/class/leds/lp5523:channel2/device | ||
| 41 | echo "load" > engine3_mode | ||
| 42 | echo "9d80400004ff05ff437f0000" > engine3_load | ||
| 43 | echo "111111111" > engine3_leds | ||
| 44 | echo "run" > engine3_mode | ||
| 45 | |||
| 46 | sysfs contains a selftest entry. It measures each channel | ||
| 47 | voltage level and checks if it looks reasonable. If the level is too high, | ||
| 48 | the led is missing; if the level is too low, there is a short circuit. | ||
| 49 | 32 | ||
| 50 | Selftest uses always the current from the platform data. | 33 | Selftest uses always the current from the platform data. |
| 51 | 34 | ||
| @@ -58,7 +41,7 @@ Example platform data: | |||
| 58 | 41 | ||
| 59 | Note - chan_nr can have values between 0 and 8. | 42 | Note - chan_nr can have values between 0 and 8. |
| 60 | 43 | ||
| 61 | static struct lp5523_led_config lp5523_led_config[] = { | 44 | static struct lp55xx_led_config lp5523_led_config[] = { |
| 62 | { | 45 | { |
| 63 | .name = "D1", | 46 | .name = "D1", |
| 64 | .chan_nr = 0, | 47 | .chan_nr = 0, |
| @@ -88,10 +71,10 @@ static void lp5523_enable(bool state) | |||
| 88 | /* Control chip enable signal */ | 71 | /* Control chip enable signal */ |
| 89 | } | 72 | } |
| 90 | 73 | ||
| 91 | static struct lp5523_platform_data lp5523_platform_data = { | 74 | static struct lp55xx_platform_data lp5523_platform_data = { |
| 92 | .led_config = lp5523_led_config, | 75 | .led_config = lp5523_led_config, |
| 93 | .num_channels = ARRAY_SIZE(lp5523_led_config), | 76 | .num_channels = ARRAY_SIZE(lp5523_led_config), |
| 94 | .clock_mode = LP5523_CLOCK_EXT, | 77 | .clock_mode = LP55XX_CLOCK_EXT, |
| 95 | .setup_resources = lp5523_setup, | 78 | .setup_resources = lp5523_setup, |
| 96 | .release_resources = lp5523_release, | 79 | .release_resources = lp5523_release, |
| 97 | .enable = lp5523_enable, | 80 | .enable = lp5523_enable, |
diff --git a/Documentation/leds/leds-lp55xx.txt b/Documentation/leds/leds-lp55xx.txt new file mode 100644 index 000000000000..ced41868d2d1 --- /dev/null +++ b/Documentation/leds/leds-lp55xx.txt | |||
| @@ -0,0 +1,118 @@ | |||
| 1 | LP5521/LP5523/LP55231 Common Driver | ||
| 2 | =================================== | ||
| 3 | |||
| 4 | Authors: Milo(Woogyom) Kim <milo.kim@ti.com> | ||
| 5 | |||
| 6 | Description | ||
| 7 | ----------- | ||
| 8 | LP5521, LP5523/55231 have common features as below. | ||
| 9 | |||
| 10 | Register access via the I2C | ||
| 11 | Device initialization/deinitialization | ||
| 12 | Create LED class devices for multiple output channels | ||
| 13 | Device attributes for user-space interface | ||
| 14 | Program memory for running LED patterns | ||
| 15 | |||
| 16 | The LP55xx common driver provides these features using exported functions. | ||
| 17 | lp55xx_init_device() / lp55xx_deinit_device() | ||
| 18 | lp55xx_register_leds() / lp55xx_unregister_leds() | ||
| 19 | lp55xx_regsister_sysfs() / lp55xx_unregister_sysfs() | ||
| 20 | |||
| 21 | ( Driver Structure Data ) | ||
| 22 | |||
| 23 | In lp55xx common driver, two different data structure is used. | ||
| 24 | |||
| 25 | o lp55xx_led | ||
| 26 | control multi output LED channels such as led current, channel index. | ||
| 27 | o lp55xx_chip | ||
| 28 | general chip control such like the I2C and platform data. | ||
| 29 | |||
| 30 | For example, LP5521 has maximum 3 LED channels. | ||
| 31 | LP5523/55231 has 9 output channels. | ||
| 32 | |||
| 33 | lp55xx_chip for LP5521 ... lp55xx_led #1 | ||
| 34 | lp55xx_led #2 | ||
| 35 | lp55xx_led #3 | ||
| 36 | |||
| 37 | lp55xx_chip for LP5523 ... lp55xx_led #1 | ||
| 38 | lp55xx_led #2 | ||
| 39 | . | ||
| 40 | . | ||
| 41 | lp55xx_led #9 | ||
| 42 | |||
| 43 | ( Chip Dependent Code ) | ||
| 44 | |||
| 45 | To support device specific configurations, special structure | ||
| 46 | 'lpxx_device_config' is used. | ||
| 47 | |||
| 48 | Maximum number of channels | ||
| 49 | Reset command, chip enable command | ||
| 50 | Chip specific initialization | ||
| 51 | Brightness control register access | ||
| 52 | Setting LED output current | ||
| 53 | Program memory address access for running patterns | ||
| 54 | Additional device specific attributes | ||
| 55 | |||
| 56 | ( Firmware Interface ) | ||
| 57 | |||
| 58 | LP55xx family devices have the internal program memory for running | ||
| 59 | various LED patterns. | ||
| 60 | This pattern data is saved as a file in the user-land or | ||
| 61 | hex byte string is written into the memory through the I2C. | ||
| 62 | LP55xx common driver supports the firmware interface. | ||
| 63 | |||
| 64 | LP55xx chips have three program engines. | ||
| 65 | To load and run the pattern, the programming sequence is following. | ||
| 66 | (1) Select an engine number (1/2/3) | ||
| 67 | (2) Mode change to load | ||
| 68 | (3) Write pattern data into selected area | ||
| 69 | (4) Mode change to run | ||
| 70 | |||
| 71 | The LP55xx common driver provides simple interfaces as below. | ||
| 72 | select_engine : Select which engine is used for running program | ||
| 73 | run_engine : Start program which is loaded via the firmware interface | ||
| 74 | firmware : Load program data | ||
| 75 | |||
| 76 | For example, run blinking pattern in engine #1 of LP5521 | ||
| 77 | echo 1 > /sys/bus/i2c/devices/xxxx/select_engine | ||
| 78 | echo 1 > /sys/class/firmware/lp5521/loading | ||
| 79 | echo "4000600040FF6000" > /sys/class/firmware/lp5521/data | ||
| 80 | echo 0 > /sys/class/firmware/lp5521/loading | ||
| 81 | echo 1 > /sys/bus/i2c/devices/xxxx/run_engine | ||
| 82 | |||
| 83 | For example, run blinking pattern in engine #3 of LP55231 | ||
| 84 | echo 3 > /sys/bus/i2c/devices/xxxx/select_engine | ||
| 85 | echo 1 > /sys/class/firmware/lp55231/loading | ||
| 86 | echo "9d0740ff7e0040007e00a0010000" > /sys/class/firmware/lp55231/data | ||
| 87 | echo 0 > /sys/class/firmware/lp55231/loading | ||
| 88 | echo 1 > /sys/bus/i2c/devices/xxxx/run_engine | ||
| 89 | |||
| 90 | To start blinking patterns in engine #2 and #3 simultaneously, | ||
| 91 | for idx in 2 3 | ||
| 92 | do | ||
| 93 | echo $idx > /sys/class/leds/red/device/select_engine | ||
| 94 | sleep 0.1 | ||
| 95 | echo 1 > /sys/class/firmware/lp5521/loading | ||
| 96 | echo "4000600040FF6000" > /sys/class/firmware/lp5521/data | ||
| 97 | echo 0 > /sys/class/firmware/lp5521/loading | ||
| 98 | done | ||
| 99 | echo 1 > /sys/class/leds/red/device/run_engine | ||
| 100 | |||
| 101 | Here is another example for LP5523. | ||
| 102 | echo 2 > /sys/bus/i2c/devices/xxxx/select_engine | ||
| 103 | echo 1 > /sys/class/firmware/lp5523/loading | ||
| 104 | echo "9d80400004ff05ff437f0000" > /sys/class/firmware/lp5523/data | ||
| 105 | echo 0 > /sys/class/firmware/lp5523/loading | ||
| 106 | echo 1 > /sys/bus/i2c/devices/xxxx/run_engine | ||
| 107 | |||
| 108 | As soon as 'loading' is set to 0, registered callback is called. | ||
| 109 | Inside the callback, the selected engine is loaded and memory is updated. | ||
| 110 | To run programmed pattern, 'run_engine' attribute should be enabled. | ||
| 111 | |||
| 112 | ( 'run_engine' and 'firmware_cb' ) | ||
| 113 | The sequence of running the program data is common. | ||
| 114 | But each device has own specific register addresses for commands. | ||
| 115 | To support this, 'run_engine' and 'firmware_cb' are configurable in each driver. | ||
| 116 | run_engine : Control the selected engine | ||
| 117 | firmware_cb : The callback function after loading the firmware is done. | ||
| 118 | Chip specific commands for loading and updating program memory. | ||
diff --git a/Documentation/media-framework.txt b/Documentation/media-framework.txt index 802875413873..77bd0a42f19d 100644 --- a/Documentation/media-framework.txt +++ b/Documentation/media-framework.txt | |||
| @@ -336,7 +336,7 @@ Calls to media_entity_pipeline_start() can be nested. The pipeline pointer must | |||
| 336 | be identical for all nested calls to the function. | 336 | be identical for all nested calls to the function. |
| 337 | 337 | ||
| 338 | media_entity_pipeline_start() may return an error. In that case, it will | 338 | media_entity_pipeline_start() may return an error. In that case, it will |
| 339 | clean up any the changes it did by itself. | 339 | clean up any of the changes it did by itself. |
| 340 | 340 | ||
| 341 | When stopping the stream, drivers must notify the entities with | 341 | When stopping the stream, drivers must notify the entities with |
| 342 | 342 | ||
diff --git a/Documentation/metag/00-INDEX b/Documentation/metag/00-INDEX new file mode 100644 index 000000000000..db11c513bd5c --- /dev/null +++ b/Documentation/metag/00-INDEX | |||
| @@ -0,0 +1,4 @@ | |||
| 1 | 00-INDEX | ||
| 2 | - this file | ||
| 3 | kernel-ABI.txt | ||
| 4 | - Documents metag ABI details | ||
diff --git a/Documentation/metag/kernel-ABI.txt b/Documentation/metag/kernel-ABI.txt new file mode 100644 index 000000000000..7b8dee83b9c1 --- /dev/null +++ b/Documentation/metag/kernel-ABI.txt | |||
| @@ -0,0 +1,256 @@ | |||
| 1 | ========================== | ||
| 2 | KERNEL ABIS FOR METAG ARCH | ||
| 3 | ========================== | ||
| 4 | |||
| 5 | This document describes the Linux ABIs for the metag architecture, and has the | ||
| 6 | following sections: | ||
| 7 | |||
| 8 | (*) Outline of registers | ||
| 9 | (*) Userland registers | ||
| 10 | (*) Kernel registers | ||
| 11 | (*) System call ABI | ||
| 12 | (*) Calling conventions | ||
| 13 | |||
| 14 | |||
| 15 | ==================== | ||
| 16 | OUTLINE OF REGISTERS | ||
| 17 | ==================== | ||
| 18 | |||
| 19 | The main Meta core registers are arranged in units: | ||
| 20 | |||
| 21 | UNIT Type DESCRIPTION GP EXT PRIV GLOBAL | ||
| 22 | ======= ======= =============== ======= ======= ======= ======= | ||
| 23 | CT Special Control unit | ||
| 24 | D0 General Data unit 0 0-7 8-15 16-31 16-31 | ||
| 25 | D1 General Data unit 1 0-7 8-15 16-31 16-31 | ||
| 26 | A0 General Address unit 0 0-3 4-7 8-15 8-15 | ||
| 27 | A1 General Address unit 1 0-3 4-7 8-15 8-15 | ||
| 28 | PC Special PC unit 0 1 | ||
| 29 | PORT Special Ports | ||
| 30 | TR Special Trigger unit 0-7 | ||
| 31 | TT Special Trace unit 0-5 | ||
| 32 | FX General FP unit 0-15 | ||
| 33 | |||
| 34 | GP registers form part of the main context. | ||
| 35 | |||
| 36 | Extended context registers (EXT) may not be present on all hardware threads and | ||
| 37 | can be context switched if support is enabled and the appropriate bits are set | ||
| 38 | in e.g. the D0.8 register to indicate what extended state to preserve. | ||
| 39 | |||
| 40 | Global registers are shared between threads and are privilege protected. | ||
| 41 | |||
| 42 | See arch/metag/include/asm/metag_regs.h for definitions relating to core | ||
| 43 | registers and the fields and bits they contain. See the TRMs for further details | ||
| 44 | about special registers. | ||
| 45 | |||
| 46 | Several special registers are preserved in the main context, these are the | ||
| 47 | interesting ones: | ||
| 48 | |||
| 49 | REG (ALIAS) PURPOSE | ||
| 50 | ======================= =============================================== | ||
| 51 | CT.1 (TXMODE) Processor mode bits (particularly for DSP) | ||
| 52 | CT.2 (TXSTATUS) Condition flags and LSM_STEP (MGET/MSET step) | ||
| 53 | CT.3 (TXRPT) Branch repeat counter | ||
| 54 | PC.0 (PC) Program counter | ||
| 55 | |||
| 56 | Some of the general registers have special purposes in the ABI and therefore | ||
| 57 | have aliases: | ||
| 58 | |||
| 59 | D0 REG (ALIAS) PURPOSE D1 REG (ALIAS) PURPOSE | ||
| 60 | =============== =============== =============== ======================= | ||
| 61 | D0.0 (D0Re0) 32bit result D1.0 (D1Re0) Top half of 64bit result | ||
| 62 | D0.1 (D0Ar6) Argument 6 D1.1 (D1Ar5) Argument 5 | ||
| 63 | D0.2 (D0Ar4) Argument 4 D1.2 (D1Ar3) Argument 3 | ||
| 64 | D0.3 (D0Ar2) Argument 2 D1.3 (D1Ar1) Argument 1 | ||
| 65 | D0.4 (D0FrT) Frame temp D1.4 (D1RtP) Return pointer | ||
| 66 | D0.5 Call preserved D1.5 Call preserved | ||
| 67 | D0.6 Call preserved D1.6 Call preserved | ||
| 68 | D0.7 Call preserved D1.7 Call preserved | ||
| 69 | |||
| 70 | A0 REG (ALIAS) PURPOSE A1 REG (ALIAS) PURPOSE | ||
| 71 | =============== =============== =============== ======================= | ||
| 72 | A0.0 (A0StP) Stack pointer A1.0 (A1GbP) Global base pointer | ||
| 73 | A0.1 (A0FrP) Frame pointer A1.1 (A1LbP) Local base pointer | ||
| 74 | A0.2 A1.2 | ||
| 75 | A0.3 A1.3 | ||
| 76 | |||
| 77 | |||
| 78 | ================== | ||
| 79 | USERLAND REGISTERS | ||
| 80 | ================== | ||
| 81 | |||
| 82 | All the general purpose D0, D1, A0, A1 registers are preserved when entering the | ||
| 83 | kernel (including asynchronous events such as interrupts and timer ticks) except | ||
| 84 | the following which have special purposes in the ABI: | ||
| 85 | |||
| 86 | REGISTERS WHEN STATUS PURPOSE | ||
| 87 | =============== ======= =============== =============================== | ||
| 88 | D0.8 DSP Preserved ECH, determines what extended | ||
| 89 | DSP state to preserve. | ||
| 90 | A0.0 (A0StP) ALWAYS Preserved Stack >= A0StP may be clobbered | ||
| 91 | at any time by the creation of a | ||
| 92 | signal frame. | ||
| 93 | A1.0 (A1GbP) SMP Clobbered Used as temporary for loading | ||
| 94 | kernel stack pointer and saving | ||
| 95 | core context. | ||
| 96 | A0.15 !SMP Protected Stores kernel stack pointer. | ||
| 97 | A1.15 ALWAYS Protected Stores kernel base pointer. | ||
| 98 | |||
| 99 | On UP A0.15 is used to store the kernel stack pointer for storing the userland | ||
| 100 | context. A0.15 is global between hardware threads though which means it cannot | ||
| 101 | be used on SMP for this purpose. Since no protected local registers are | ||
| 102 | available A1GbP is reserved for use as a temporary to allow a percpu stack | ||
| 103 | pointer to be loaded for storing the rest of the context. | ||
| 104 | |||
| 105 | |||
| 106 | ================ | ||
| 107 | KERNEL REGISTERS | ||
| 108 | ================ | ||
| 109 | |||
| 110 | When in the kernel the following registers have special purposes in the ABI: | ||
| 111 | |||
| 112 | REGISTERS WHEN STATUS PURPOSE | ||
| 113 | =============== ======= =============== =============================== | ||
| 114 | A0.0 (A0StP) ALWAYS Preserved Stack >= A0StP may be clobbered | ||
| 115 | at any time by the creation of | ||
| 116 | an irq signal frame. | ||
| 117 | A1.0 (A1GbP) ALWAYS Preserved Reserved (kernel base pointer). | ||
| 118 | |||
| 119 | |||
| 120 | =============== | ||
| 121 | SYSTEM CALL ABI | ||
| 122 | =============== | ||
| 123 | |||
| 124 | When a system call is made, the following registers are effective: | ||
| 125 | |||
| 126 | REGISTERS CALL RETURN | ||
| 127 | =============== ======================= =============================== | ||
| 128 | D0.0 (D0Re0) Return value (or -errno) | ||
| 129 | D1.0 (D1Re0) System call number Clobbered | ||
| 130 | D0.1 (D0Ar6) Syscall arg #6 Preserved | ||
| 131 | D1.1 (D1Ar5) Syscall arg #5 Preserved | ||
| 132 | D0.2 (D0Ar4) Syscall arg #4 Preserved | ||
| 133 | D1.2 (D1Ar3) Syscall arg #3 Preserved | ||
| 134 | D0.3 (D0Ar2) Syscall arg #2 Preserved | ||
| 135 | D1.3 (D1Ar1) Syscall arg #1 Preserved | ||
| 136 | |||
| 137 | Due to the limited number of argument registers and some system calls with badly | ||
| 138 | aligned 64-bit arguments, 64-bit values are always packed in consecutive | ||
| 139 | arguments, even if this is contrary to the normal calling conventions (where the | ||
| 140 | two halves would go in a matching pair of data registers). | ||
| 141 | |||
| 142 | For example fadvise64_64 usually has the signature: | ||
| 143 | |||
| 144 | long sys_fadvise64_64(i32 fd, i64 offs, i64 len, i32 advice); | ||
| 145 | |||
| 146 | But for metag fadvise64_64 is wrapped so that the 64-bit arguments are packed: | ||
| 147 | |||
| 148 | long sys_fadvise64_64_metag(i32 fd, i32 offs_lo, | ||
| 149 | i32 offs_hi, i32 len_lo, | ||
| 150 | i32 len_hi, i32 advice) | ||
| 151 | |||
| 152 | So the arguments are packed in the registers like this: | ||
| 153 | |||
| 154 | D0 REG (ALIAS) VALUE D1 REG (ALIAS) VALUE | ||
| 155 | =============== =============== =============== ======================= | ||
| 156 | D0.1 (D0Ar6) advice D1.1 (D1Ar5) hi(len) | ||
| 157 | D0.2 (D0Ar4) lo(len) D1.2 (D1Ar3) hi(offs) | ||
| 158 | D0.3 (D0Ar2) lo(offs) D1.3 (D1Ar1) fd | ||
| 159 | |||
| 160 | |||
| 161 | =================== | ||
| 162 | CALLING CONVENTIONS | ||
| 163 | =================== | ||
| 164 | |||
| 165 | These calling conventions apply to both user and kernel code. The stack grows | ||
| 166 | from low addresses to high addresses in the metag ABI. The stack pointer (A0StP) | ||
| 167 | should always point to the next free address on the stack and should at all | ||
| 168 | times be 64-bit aligned. The following registers are effective at the point of a | ||
| 169 | call: | ||
| 170 | |||
| 171 | REGISTERS CALL RETURN | ||
| 172 | =============== ======================= =============================== | ||
| 173 | D0.0 (D0Re0) 32bit return value | ||
| 174 | D1.0 (D1Re0) Upper half of 64bit return value | ||
| 175 | D0.1 (D0Ar6) 32bit argument #6 Clobbered | ||
| 176 | D1.1 (D1Ar5) 32bit argument #5 Clobbered | ||
| 177 | D0.2 (D0Ar4) 32bit argument #4 Clobbered | ||
| 178 | D1.2 (D1Ar3) 32bit argument #3 Clobbered | ||
| 179 | D0.3 (D0Ar2) 32bit argument #2 Clobbered | ||
| 180 | D1.3 (D1Ar1) 32bit argument #1 Clobbered | ||
| 181 | D0.4 (D0FrT) Clobbered | ||
| 182 | D1.4 (D1RtP) Return pointer Clobbered | ||
| 183 | D{0-1}.{5-7} Preserved | ||
| 184 | A0.0 (A0StP) Stack pointer Preserved | ||
| 185 | A1.0 (A0GbP) Preserved | ||
| 186 | A0.1 (A0FrP) Frame pointer Preserved | ||
| 187 | A1.1 (A0LbP) Preserved | ||
| 188 | A{0-1},{2-3} Clobbered | ||
| 189 | |||
| 190 | 64-bit arguments are placed in matching pairs of registers (i.e. the same | ||
| 191 | register number in both D0 and D1 units), with the least significant half in D0 | ||
| 192 | and the most significant half in D1, leaving a gap where necessary. Futher | ||
| 193 | arguments are stored on the stack in reverse order (earlier arguments at higher | ||
| 194 | addresses): | ||
| 195 | |||
| 196 | ADDRESS 0 1 2 3 4 5 6 7 | ||
| 197 | =============== ===== ===== ===== ===== ===== ===== ===== ===== | ||
| 198 | A0StP --> | ||
| 199 | A0StP-0x08 32bit argument #8 32bit argument #7 | ||
| 200 | A0StP-0x10 32bit argument #10 32bit argument #9 | ||
| 201 | |||
| 202 | Function prologues tend to look a bit like this: | ||
| 203 | |||
| 204 | /* If frame pointer in use, move it to frame temp register so it can be | ||
| 205 | easily pushed onto stack */ | ||
| 206 | MOV D0FrT,A0FrP | ||
| 207 | |||
| 208 | /* If frame pointer in use, set it to stack pointer */ | ||
| 209 | ADD A0FrP,A0StP,#0 | ||
| 210 | |||
| 211 | /* Preserve D0FrT, D1RtP, D{0-1}.{5-7} on stack, incrementing A0StP */ | ||
| 212 | MSETL [A0StP++],D0FrT,D0.5,D0.6,D0.7 | ||
| 213 | |||
| 214 | /* Allocate some stack space for local variables */ | ||
| 215 | ADD A0StP,A0StP,#0x10 | ||
| 216 | |||
| 217 | At this point the stack would look like this: | ||
| 218 | |||
| 219 | ADDRESS 0 1 2 3 4 5 6 7 | ||
| 220 | =============== ===== ===== ===== ===== ===== ===== ===== ===== | ||
| 221 | A0StP --> | ||
| 222 | A0StP-0x08 | ||
| 223 | A0StP-0x10 | ||
| 224 | A0StP-0x18 Old D0.7 Old D1.7 | ||
| 225 | A0StP-0x20 Old D0.6 Old D1.6 | ||
| 226 | A0StP-0x28 Old D0.5 Old D1.5 | ||
| 227 | A0FrP --> Old A0FrP (frame ptr) Old D1RtP (return ptr) | ||
| 228 | A0FrP-0x08 32bit argument #8 32bit argument #7 | ||
| 229 | A0FrP-0x10 32bit argument #10 32bit argument #9 | ||
| 230 | |||
| 231 | Function epilogues tend to differ depending on the use of a frame pointer. An | ||
| 232 | example of a frame pointer epilogue: | ||
| 233 | |||
| 234 | /* Restore D0FrT, D1RtP, D{0-1}.{5-7} from stack, incrementing A0FrP */ | ||
| 235 | MGETL D0FrT,D0.5,D0.6,D0.7,[A0FrP++] | ||
| 236 | /* Restore stack pointer to where frame pointer was before increment */ | ||
| 237 | SUB A0StP,A0FrP,#0x20 | ||
| 238 | /* Restore frame pointer from frame temp */ | ||
| 239 | MOV A0FrP,D0FrT | ||
| 240 | /* Return to caller via restored return pointer */ | ||
| 241 | MOV PC,D1RtP | ||
| 242 | |||
| 243 | If the function hasn't touched the frame pointer, MGETL cannot be safely used | ||
| 244 | with A0StP as it always increments and that would expose the stack to clobbering | ||
| 245 | by interrupts (kernel) or signals (user). Therefore it's common to see the MGETL | ||
| 246 | split into separate GETL instructions: | ||
| 247 | |||
| 248 | /* Restore D0FrT, D1RtP, D{0-1}.{5-7} from stack */ | ||
| 249 | GETL D0FrT,D1RtP,[A0StP+#-0x30] | ||
| 250 | GETL D0.5,D1.5,[A0StP+#-0x28] | ||
| 251 | GETL D0.6,D1.6,[A0StP+#-0x20] | ||
| 252 | GETL D0.7,D1.7,[A0StP+#-0x18] | ||
| 253 | /* Restore stack pointer */ | ||
| 254 | SUB A0StP,A0StP,#0x30 | ||
| 255 | /* Return to caller via restored return pointer */ | ||
| 256 | MOV PC,D1RtP | ||
diff --git a/Documentation/namespaces/resource-control.txt b/Documentation/namespaces/resource-control.txt new file mode 100644 index 000000000000..abc13c394738 --- /dev/null +++ b/Documentation/namespaces/resource-control.txt | |||
| @@ -0,0 +1,14 @@ | |||
| 1 | There are a lot of kinds of objects in the kernel that don't have | ||
| 2 | individual limits or that have limits that are ineffective when a set | ||
| 3 | of processes is allowed to switch user ids. With user namespaces | ||
| 4 | enabled in a kernel for people who don't trust their users or their | ||
| 5 | users programs to play nice this problems becomes more acute. | ||
| 6 | |||
| 7 | Therefore it is recommended that memory control groups be enabled in | ||
| 8 | kernels that enable user namespaces, and it is further recommended | ||
| 9 | that userspace configure memory control groups to limit how much | ||
| 10 | memory user's they don't trust to play nice can use. | ||
| 11 | |||
| 12 | Memory control groups can be configured by installing the libcgroup | ||
| 13 | package present on most distros editing /etc/cgrules.conf, | ||
| 14 | /etc/cgconfig.conf and setting up libpam-cgroup. | ||
diff --git a/Documentation/networking/ipvs-sysctl.txt b/Documentation/networking/ipvs-sysctl.txt index f2a2488f1bf3..9573d0c48c6e 100644 --- a/Documentation/networking/ipvs-sysctl.txt +++ b/Documentation/networking/ipvs-sysctl.txt | |||
| @@ -15,6 +15,13 @@ amemthresh - INTEGER | |||
| 15 | enabled and the variable is automatically set to 2, otherwise | 15 | enabled and the variable is automatically set to 2, otherwise |
| 16 | the strategy is disabled and the variable is set to 1. | 16 | the strategy is disabled and the variable is set to 1. |
| 17 | 17 | ||
| 18 | backup_only - BOOLEAN | ||
| 19 | 0 - disabled (default) | ||
| 20 | not 0 - enabled | ||
| 21 | |||
| 22 | If set, disable the director function while the server is | ||
| 23 | in backup mode to avoid packet loops for DR/TUN methods. | ||
| 24 | |||
| 18 | conntrack - BOOLEAN | 25 | conntrack - BOOLEAN |
| 19 | 0 - disabled (default) | 26 | 0 - disabled (default) |
| 20 | not 0 - enabled | 27 | not 0 - enabled |
diff --git a/Documentation/networking/tuntap.txt b/Documentation/networking/tuntap.txt index c0aab985bad9..949d5dcdd9a3 100644 --- a/Documentation/networking/tuntap.txt +++ b/Documentation/networking/tuntap.txt | |||
| @@ -105,6 +105,83 @@ Copyright (C) 1999-2000 Maxim Krasnyansky <max_mk@yahoo.com> | |||
| 105 | Proto [2 bytes] | 105 | Proto [2 bytes] |
| 106 | Raw protocol(IP, IPv6, etc) frame. | 106 | Raw protocol(IP, IPv6, etc) frame. |
| 107 | 107 | ||
| 108 | 3.3 Multiqueue tuntap interface: | ||
| 109 | |||
| 110 | From version 3.8, Linux supports multiqueue tuntap which can uses multiple | ||
| 111 | file descriptors (queues) to parallelize packets sending or receiving. The | ||
| 112 | device allocation is the same as before, and if user wants to create multiple | ||
| 113 | queues, TUNSETIFF with the same device name must be called many times with | ||
| 114 | IFF_MULTI_QUEUE flag. | ||
| 115 | |||
| 116 | char *dev should be the name of the device, queues is the number of queues to | ||
| 117 | be created, fds is used to store and return the file descriptors (queues) | ||
| 118 | created to the caller. Each file descriptor were served as the interface of a | ||
| 119 | queue which could be accessed by userspace. | ||
| 120 | |||
| 121 | #include <linux/if.h> | ||
| 122 | #include <linux/if_tun.h> | ||
| 123 | |||
| 124 | int tun_alloc_mq(char *dev, int queues, int *fds) | ||
| 125 | { | ||
| 126 | struct ifreq ifr; | ||
| 127 | int fd, err, i; | ||
| 128 | |||
| 129 | if (!dev) | ||
| 130 | return -1; | ||
| 131 | |||
| 132 | memset(&ifr, 0, sizeof(ifr)); | ||
| 133 | /* Flags: IFF_TUN - TUN device (no Ethernet headers) | ||
| 134 | * IFF_TAP - TAP device | ||
| 135 | * | ||
| 136 | * IFF_NO_PI - Do not provide packet information | ||
| 137 | * IFF_MULTI_QUEUE - Create a queue of multiqueue device | ||
| 138 | */ | ||
| 139 | ifr.ifr_flags = IFF_TAP | IFF_NO_PI | IFF_MULTI_QUEUE; | ||
| 140 | strcpy(ifr.ifr_name, dev); | ||
| 141 | |||
| 142 | for (i = 0; i < queues; i++) { | ||
| 143 | if ((fd = open("/dev/net/tun", O_RDWR)) < 0) | ||
| 144 | goto err; | ||
| 145 | err = ioctl(fd, TUNSETIFF, (void *)&ifr); | ||
| 146 | if (err) { | ||
| 147 | close(fd); | ||
| 148 | goto err; | ||
| 149 | } | ||
| 150 | fds[i] = fd; | ||
| 151 | } | ||
| 152 | |||
| 153 | return 0; | ||
| 154 | err: | ||
| 155 | for (--i; i >= 0; i--) | ||
| 156 | close(fds[i]); | ||
| 157 | return err; | ||
| 158 | } | ||
| 159 | |||
| 160 | A new ioctl(TUNSETQUEUE) were introduced to enable or disable a queue. When | ||
| 161 | calling it with IFF_DETACH_QUEUE flag, the queue were disabled. And when | ||
| 162 | calling it with IFF_ATTACH_QUEUE flag, the queue were enabled. The queue were | ||
| 163 | enabled by default after it was created through TUNSETIFF. | ||
| 164 | |||
| 165 | fd is the file descriptor (queue) that we want to enable or disable, when | ||
| 166 | enable is true we enable it, otherwise we disable it | ||
| 167 | |||
| 168 | #include <linux/if.h> | ||
| 169 | #include <linux/if_tun.h> | ||
| 170 | |||
| 171 | int tun_set_queue(int fd, int enable) | ||
| 172 | { | ||
| 173 | struct ifreq ifr; | ||
| 174 | |||
| 175 | memset(&ifr, 0, sizeof(ifr)); | ||
| 176 | |||
| 177 | if (enable) | ||
| 178 | ifr.ifr_flags = IFF_ATTACH_QUEUE; | ||
| 179 | else | ||
| 180 | ifr.ifr_flags = IFF_DETACH_QUEUE; | ||
| 181 | |||
| 182 | return ioctl(fd, TUNSETQUEUE, (void *)&ifr); | ||
| 183 | } | ||
| 184 | |||
| 108 | Universal TUN/TAP device driver Frequently Asked Question. | 185 | Universal TUN/TAP device driver Frequently Asked Question. |
| 109 | 186 | ||
| 110 | 1. What platforms are supported by TUN/TAP driver ? | 187 | 1. What platforms are supported by TUN/TAP driver ? |
diff --git a/Documentation/power/opp.txt b/Documentation/power/opp.txt index 3035d00757ad..425c51d56aef 100644 --- a/Documentation/power/opp.txt +++ b/Documentation/power/opp.txt | |||
| @@ -1,6 +1,5 @@ | |||
| 1 | *=============* | 1 | Operating Performance Points (OPP) Library |
| 2 | * OPP Library * | 2 | ========================================== |
| 3 | *=============* | ||
| 4 | 3 | ||
| 5 | (C) 2009-2010 Nishanth Menon <nm@ti.com>, Texas Instruments Incorporated | 4 | (C) 2009-2010 Nishanth Menon <nm@ti.com>, Texas Instruments Incorporated |
| 6 | 5 | ||
| @@ -16,15 +15,31 @@ Contents | |||
| 16 | 15 | ||
| 17 | 1. Introduction | 16 | 1. Introduction |
| 18 | =============== | 17 | =============== |
| 18 | 1.1 What is an Operating Performance Point (OPP)? | ||
| 19 | |||
| 19 | Complex SoCs of today consists of a multiple sub-modules working in conjunction. | 20 | Complex SoCs of today consists of a multiple sub-modules working in conjunction. |
| 20 | In an operational system executing varied use cases, not all modules in the SoC | 21 | In an operational system executing varied use cases, not all modules in the SoC |
| 21 | need to function at their highest performing frequency all the time. To | 22 | need to function at their highest performing frequency all the time. To |
| 22 | facilitate this, sub-modules in a SoC are grouped into domains, allowing some | 23 | facilitate this, sub-modules in a SoC are grouped into domains, allowing some |
| 23 | domains to run at lower voltage and frequency while other domains are loaded | 24 | domains to run at lower voltage and frequency while other domains run at |
| 24 | more. The set of discrete tuples consisting of frequency and voltage pairs that | 25 | voltage/frequency pairs that are higher. |
| 26 | |||
| 27 | The set of discrete tuples consisting of frequency and voltage pairs that | ||
| 25 | the device will support per domain are called Operating Performance Points or | 28 | the device will support per domain are called Operating Performance Points or |
| 26 | OPPs. | 29 | OPPs. |
| 27 | 30 | ||
| 31 | As an example: | ||
| 32 | Let us consider an MPU device which supports the following: | ||
| 33 | {300MHz at minimum voltage of 1V}, {800MHz at minimum voltage of 1.2V}, | ||
| 34 | {1GHz at minimum voltage of 1.3V} | ||
| 35 | |||
| 36 | We can represent these as three OPPs as the following {Hz, uV} tuples: | ||
| 37 | {300000000, 1000000} | ||
| 38 | {800000000, 1200000} | ||
| 39 | {1000000000, 1300000} | ||
| 40 | |||
| 41 | 1.2 Operating Performance Points Library | ||
| 42 | |||
| 28 | OPP library provides a set of helper functions to organize and query the OPP | 43 | OPP library provides a set of helper functions to organize and query the OPP |
| 29 | information. The library is located in drivers/base/power/opp.c and the header | 44 | information. The library is located in drivers/base/power/opp.c and the header |
| 30 | is located in include/linux/opp.h. OPP library can be enabled by enabling | 45 | is located in include/linux/opp.h. OPP library can be enabled by enabling |
diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt index e8a6aa473bab..6e953564de03 100644 --- a/Documentation/printk-formats.txt +++ b/Documentation/printk-formats.txt | |||
| @@ -170,5 +170,5 @@ Reminder: sizeof() result is of type size_t. | |||
| 170 | Thank you for your cooperation and attention. | 170 | Thank you for your cooperation and attention. |
| 171 | 171 | ||
| 172 | 172 | ||
| 173 | By Randy Dunlap <rdunlap@xenotime.net> and | 173 | By Randy Dunlap <rdunlap@infradead.org> and |
| 174 | Andrew Murray <amurray@mpc-data.co.uk> | 174 | Andrew Murray <amurray@mpc-data.co.uk> |
diff --git a/Documentation/scsi/ChangeLog.megaraid_sas b/Documentation/scsi/ChangeLog.megaraid_sas index da03146c182a..09673c7fc8ee 100644 --- a/Documentation/scsi/ChangeLog.megaraid_sas +++ b/Documentation/scsi/ChangeLog.megaraid_sas | |||
| @@ -1,3 +1,12 @@ | |||
| 1 | Release Date : Sat. Feb 9, 2013 17:00:00 PST 2013 - | ||
| 2 | (emaild-id:megaraidlinux@lsi.com) | ||
| 3 | Adam Radford | ||
| 4 | Current Version : 06.506.00.00-rc1 | ||
| 5 | Old Version : 06.504.01.00-rc1 | ||
| 6 | 1. Add 4k FastPath DIF support. | ||
| 7 | 2. Dont load DevHandle unless FastPath enabled. | ||
| 8 | 3. Version and Changelog update. | ||
| 9 | ------------------------------------------------------------------------------- | ||
| 1 | Release Date : Mon. Oct 1, 2012 17:00:00 PST 2012 - | 10 | Release Date : Mon. Oct 1, 2012 17:00:00 PST 2012 - |
| 2 | (emaild-id:megaraidlinux@lsi.com) | 11 | (emaild-id:megaraidlinux@lsi.com) |
| 3 | Adam Radford | 12 | Adam Radford |
diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt index ce6581c8ca26..95731a08f257 100644 --- a/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/Documentation/sound/alsa/ALSA-Configuration.txt | |||
| @@ -890,9 +890,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
| 890 | enable_msi - Enable Message Signaled Interrupt (MSI) (default = off) | 890 | enable_msi - Enable Message Signaled Interrupt (MSI) (default = off) |
| 891 | power_save - Automatic power-saving timeout (in second, 0 = | 891 | power_save - Automatic power-saving timeout (in second, 0 = |
| 892 | disable) | 892 | disable) |
| 893 | power_save_controller - Support runtime D3 of HD-audio controller | 893 | power_save_controller - Reset HD-audio controller in power-saving mode |
| 894 | (-1 = on for supported chip (default), false = off, | 894 | (default = on) |
| 895 | true = force to on even for unsupported hardware) | ||
| 896 | align_buffer_size - Force rounding of buffer/period sizes to multiples | 895 | align_buffer_size - Force rounding of buffer/period sizes to multiples |
| 897 | of 128 bytes. This is more efficient in terms of memory | 896 | of 128 bytes. This is more efficient in terms of memory |
| 898 | access but isn't required by the HDA spec and prevents | 897 | access but isn't required by the HDA spec and prevents |
| @@ -912,7 +911,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. | |||
| 912 | models depending on the codec chip. The list of available models | 911 | models depending on the codec chip. The list of available models |
| 913 | is found in HD-Audio-Models.txt | 912 | is found in HD-Audio-Models.txt |
| 914 | 913 | ||
| 915 | The model name "genric" is treated as a special case. When this | 914 | The model name "generic" is treated as a special case. When this |
| 916 | model is given, the driver uses the generic codec parser without | 915 | model is given, the driver uses the generic codec parser without |
| 917 | "codec-patch". It's sometimes good for testing and debugging. | 916 | "codec-patch". It's sometimes good for testing and debugging. |
| 918 | 917 | ||
diff --git a/Documentation/sound/alsa/seq_oss.html b/Documentation/sound/alsa/seq_oss.html index d9776cf60c07..9663b45f6fde 100644 --- a/Documentation/sound/alsa/seq_oss.html +++ b/Documentation/sound/alsa/seq_oss.html | |||
| @@ -285,7 +285,7 @@ sample data. | |||
| 285 | <H4> | 285 | <H4> |
| 286 | 7.2.4 Close Callback</H4> | 286 | 7.2.4 Close Callback</H4> |
| 287 | The <TT>close</TT> callback is called when this device is closed by the | 287 | The <TT>close</TT> callback is called when this device is closed by the |
| 288 | applicaion. If any private data was allocated in open callback, it must | 288 | application. If any private data was allocated in open callback, it must |
| 289 | be released in the close callback. The deletion of ALSA port should be | 289 | be released in the close callback. The deletion of ALSA port should be |
| 290 | done here, too. This callback must not be NULL. | 290 | done here, too. This callback must not be NULL. |
| 291 | <H4> | 291 | <H4> |
diff --git a/Documentation/thermal/exynos_thermal_emulation b/Documentation/thermal/exynos_thermal_emulation new file mode 100644 index 000000000000..b73bbfb697bb --- /dev/null +++ b/Documentation/thermal/exynos_thermal_emulation | |||
| @@ -0,0 +1,53 @@ | |||
| 1 | EXYNOS EMULATION MODE | ||
| 2 | ======================== | ||
| 3 | |||
| 4 | Copyright (C) 2012 Samsung Electronics | ||
| 5 | |||
| 6 | Written by Jonghwa Lee <jonghwa3.lee@samsung.com> | ||
| 7 | |||
| 8 | Description | ||
| 9 | ----------- | ||
| 10 | |||
| 11 | Exynos 4x12 (4212, 4412) and 5 series provide emulation mode for thermal management unit. | ||
| 12 | Thermal emulation mode supports software debug for TMU's operation. User can set temperature | ||
| 13 | manually with software code and TMU will read current temperature from user value not from | ||
| 14 | sensor's value. | ||
| 15 | |||
| 16 | Enabling CONFIG_EXYNOS_THERMAL_EMUL option will make this support in available. | ||
| 17 | When it's enabled, sysfs node will be created under | ||
| 18 | /sys/bus/platform/devices/'exynos device name'/ with name of 'emulation'. | ||
| 19 | |||
| 20 | The sysfs node, 'emulation', will contain value 0 for the initial state. When you input any | ||
| 21 | temperature you want to update to sysfs node, it automatically enable emulation mode and | ||
| 22 | current temperature will be changed into it. | ||
| 23 | (Exynos also supports user changable delay time which would be used to delay of | ||
| 24 | changing temperature. However, this node only uses same delay of real sensing time, 938us.) | ||
| 25 | |||
| 26 | Exynos emulation mode requires synchronous of value changing and enabling. It means when you | ||
| 27 | want to update the any value of delay or next temperature, then you have to enable emulation | ||
| 28 | mode at the same time. (Or you have to keep the mode enabling.) If you don't, it fails to | ||
| 29 | change the value to updated one and just use last succeessful value repeatedly. That's why | ||
| 30 | this node gives users the right to change termerpature only. Just one interface makes it more | ||
| 31 | simply to use. | ||
| 32 | |||
| 33 | Disabling emulation mode only requires writing value 0 to sysfs node. | ||
| 34 | |||
| 35 | |||
| 36 | TEMP 120 | | ||
| 37 | | | ||
| 38 | 100 | | ||
| 39 | | | ||
| 40 | 80 | | ||
| 41 | | +----------- | ||
| 42 | 60 | | | | ||
| 43 | | +-------------| | | ||
| 44 | 40 | | | | | ||
| 45 | | | | | | ||
| 46 | 20 | | | +---------- | ||
| 47 | | | | | | | ||
| 48 | 0 |______________|_____________|__________|__________|_________ | ||
| 49 | A A A A TIME | ||
| 50 | |<----->| |<----->| |<----->| | | ||
| 51 | | 938us | | | | | | | ||
| 52 | emulation : 0 50 | 70 | 20 | 0 | ||
| 53 | current temp : sensor 50 70 20 sensor | ||
diff --git a/Documentation/thermal/intel_powerclamp.txt b/Documentation/thermal/intel_powerclamp.txt new file mode 100644 index 000000000000..332de4a39b5a --- /dev/null +++ b/Documentation/thermal/intel_powerclamp.txt | |||
| @@ -0,0 +1,307 @@ | |||
| 1 | ======================= | ||
| 2 | INTEL POWERCLAMP DRIVER | ||
| 3 | ======================= | ||
| 4 | By: Arjan van de Ven <arjan@linux.intel.com> | ||
| 5 | Jacob Pan <jacob.jun.pan@linux.intel.com> | ||
| 6 | |||
| 7 | Contents: | ||
| 8 | (*) Introduction | ||
| 9 | - Goals and Objectives | ||
| 10 | |||
| 11 | (*) Theory of Operation | ||
| 12 | - Idle Injection | ||
| 13 | - Calibration | ||
| 14 | |||
| 15 | (*) Performance Analysis | ||
| 16 | - Effectiveness and Limitations | ||
| 17 | - Power vs Performance | ||
| 18 | - Scalability | ||
| 19 | - Calibration | ||
| 20 | - Comparison with Alternative Techniques | ||
| 21 | |||
| 22 | (*) Usage and Interfaces | ||
| 23 | - Generic Thermal Layer (sysfs) | ||
| 24 | - Kernel APIs (TBD) | ||
| 25 | |||
| 26 | ============ | ||
| 27 | INTRODUCTION | ||
| 28 | ============ | ||
| 29 | |||
| 30 | Consider the situation where a system’s power consumption must be | ||
| 31 | reduced at runtime, due to power budget, thermal constraint, or noise | ||
| 32 | level, and where active cooling is not preferred. Software managed | ||
| 33 | passive power reduction must be performed to prevent the hardware | ||
| 34 | actions that are designed for catastrophic scenarios. | ||
| 35 | |||
| 36 | Currently, P-states, T-states (clock modulation), and CPU offlining | ||
| 37 | are used for CPU throttling. | ||
| 38 | |||
| 39 | On Intel CPUs, C-states provide effective power reduction, but so far | ||
| 40 | they’re only used opportunistically, based on workload. With the | ||
| 41 | development of intel_powerclamp driver, the method of synchronizing | ||
| 42 | idle injection across all online CPU threads was introduced. The goal | ||
| 43 | is to achieve forced and controllable C-state residency. | ||
| 44 | |||
| 45 | Test/Analysis has been made in the areas of power, performance, | ||
| 46 | scalability, and user experience. In many cases, clear advantage is | ||
| 47 | shown over taking the CPU offline or modulating the CPU clock. | ||
| 48 | |||
| 49 | |||
| 50 | =================== | ||
| 51 | THEORY OF OPERATION | ||
| 52 | =================== | ||
| 53 | |||
| 54 | Idle Injection | ||
| 55 | -------------- | ||
| 56 | |||
| 57 | On modern Intel processors (Nehalem or later), package level C-state | ||
| 58 | residency is available in MSRs, thus also available to the kernel. | ||
| 59 | |||
| 60 | These MSRs are: | ||
| 61 | #define MSR_PKG_C2_RESIDENCY 0x60D | ||
| 62 | #define MSR_PKG_C3_RESIDENCY 0x3F8 | ||
| 63 | #define MSR_PKG_C6_RESIDENCY 0x3F9 | ||
| 64 | #define MSR_PKG_C7_RESIDENCY 0x3FA | ||
| 65 | |||
| 66 | If the kernel can also inject idle time to the system, then a | ||
| 67 | closed-loop control system can be established that manages package | ||
| 68 | level C-state. The intel_powerclamp driver is conceived as such a | ||
| 69 | control system, where the target set point is a user-selected idle | ||
| 70 | ratio (based on power reduction), and the error is the difference | ||
| 71 | between the actual package level C-state residency ratio and the target idle | ||
| 72 | ratio. | ||
| 73 | |||
| 74 | Injection is controlled by high priority kernel threads, spawned for | ||
| 75 | each online CPU. | ||
| 76 | |||
| 77 | These kernel threads, with SCHED_FIFO class, are created to perform | ||
| 78 | clamping actions of controlled duty ratio and duration. Each per-CPU | ||
| 79 | thread synchronizes its idle time and duration, based on the rounding | ||
| 80 | of jiffies, so accumulated errors can be prevented to avoid a jittery | ||
| 81 | effect. Threads are also bound to the CPU such that they cannot be | ||
| 82 | migrated, unless the CPU is taken offline. In this case, threads | ||
| 83 | belong to the offlined CPUs will be terminated immediately. | ||
| 84 | |||
| 85 | Running as SCHED_FIFO and relatively high priority, also allows such | ||
| 86 | scheme to work for both preemptable and non-preemptable kernels. | ||
| 87 | Alignment of idle time around jiffies ensures scalability for HZ | ||
| 88 | values. This effect can be better visualized using a Perf timechart. | ||
| 89 | The following diagram shows the behavior of kernel thread | ||
| 90 | kidle_inject/cpu. During idle injection, it runs monitor/mwait idle | ||
| 91 | for a given "duration", then relinquishes the CPU to other tasks, | ||
| 92 | until the next time interval. | ||
| 93 | |||
| 94 | The NOHZ schedule tick is disabled during idle time, but interrupts | ||
| 95 | are not masked. Tests show that the extra wakeups from scheduler tick | ||
| 96 | have a dramatic impact on the effectiveness of the powerclamp driver | ||
| 97 | on large scale systems (Westmere system with 80 processors). | ||
| 98 | |||
| 99 | CPU0 | ||
| 100 | ____________ ____________ | ||
| 101 | kidle_inject/0 | sleep | mwait | sleep | | ||
| 102 | _________| |________| |_______ | ||
| 103 | duration | ||
| 104 | CPU1 | ||
| 105 | ____________ ____________ | ||
| 106 | kidle_inject/1 | sleep | mwait | sleep | | ||
| 107 | _________| |________| |_______ | ||
| 108 | ^ | ||
| 109 | | | ||
| 110 | | | ||
| 111 | roundup(jiffies, interval) | ||
| 112 | |||
| 113 | Only one CPU is allowed to collect statistics and update global | ||
| 114 | control parameters. This CPU is referred to as the controlling CPU in | ||
| 115 | this document. The controlling CPU is elected at runtime, with a | ||
| 116 | policy that favors BSP, taking into account the possibility of a CPU | ||
| 117 | hot-plug. | ||
| 118 | |||
| 119 | In terms of dynamics of the idle control system, package level idle | ||
| 120 | time is considered largely as a non-causal system where its behavior | ||
| 121 | cannot be based on the past or current input. Therefore, the | ||
| 122 | intel_powerclamp driver attempts to enforce the desired idle time | ||
| 123 | instantly as given input (target idle ratio). After injection, | ||
| 124 | powerclamp moniors the actual idle for a given time window and adjust | ||
| 125 | the next injection accordingly to avoid over/under correction. | ||
| 126 | |||
| 127 | When used in a causal control system, such as a temperature control, | ||
| 128 | it is up to the user of this driver to implement algorithms where | ||
| 129 | past samples and outputs are included in the feedback. For example, a | ||
| 130 | PID-based thermal controller can use the powerclamp driver to | ||
| 131 | maintain a desired target temperature, based on integral and | ||
| 132 | derivative gains of the past samples. | ||
| 133 | |||
| 134 | |||
| 135 | |||
| 136 | Calibration | ||
| 137 | ----------- | ||
| 138 | During scalability testing, it is observed that synchronized actions | ||
| 139 | among CPUs become challenging as the number of cores grows. This is | ||
| 140 | also true for the ability of a system to enter package level C-states. | ||
| 141 | |||
| 142 | To make sure the intel_powerclamp driver scales well, online | ||
| 143 | calibration is implemented. The goals for doing such a calibration | ||
| 144 | are: | ||
| 145 | |||
| 146 | a) determine the effective range of idle injection ratio | ||
| 147 | b) determine the amount of compensation needed at each target ratio | ||
| 148 | |||
| 149 | Compensation to each target ratio consists of two parts: | ||
| 150 | |||
| 151 | a) steady state error compensation | ||
| 152 | This is to offset the error occurring when the system can | ||
| 153 | enter idle without extra wakeups (such as external interrupts). | ||
| 154 | |||
| 155 | b) dynamic error compensation | ||
| 156 | When an excessive amount of wakeups occurs during idle, an | ||
| 157 | additional idle ratio can be added to quiet interrupts, by | ||
| 158 | slowing down CPU activities. | ||
| 159 | |||
| 160 | A debugfs file is provided for the user to examine compensation | ||
| 161 | progress and results, such as on a Westmere system. | ||
| 162 | [jacob@nex01 ~]$ cat | ||
| 163 | /sys/kernel/debug/intel_powerclamp/powerclamp_calib | ||
| 164 | controlling cpu: 0 | ||
| 165 | pct confidence steady dynamic (compensation) | ||
| 166 | 0 0 0 0 | ||
| 167 | 1 1 0 0 | ||
| 168 | 2 1 1 0 | ||
| 169 | 3 3 1 0 | ||
| 170 | 4 3 1 0 | ||
| 171 | 5 3 1 0 | ||
| 172 | 6 3 1 0 | ||
| 173 | 7 3 1 0 | ||
| 174 | 8 3 1 0 | ||
| 175 | ... | ||
| 176 | 30 3 2 0 | ||
| 177 | 31 3 2 0 | ||
| 178 | 32 3 1 0 | ||
| 179 | 33 3 2 0 | ||
| 180 | 34 3 1 0 | ||
| 181 | 35 3 2 0 | ||
| 182 | 36 3 1 0 | ||
| 183 | 37 3 2 0 | ||
| 184 | 38 3 1 0 | ||
| 185 | 39 3 2 0 | ||
| 186 | 40 3 3 0 | ||
| 187 | 41 3 1 0 | ||
| 188 | 42 3 2 0 | ||
| 189 | 43 3 1 0 | ||
| 190 | 44 3 1 0 | ||
| 191 | 45 3 2 0 | ||
| 192 | 46 3 3 0 | ||
| 193 | 47 3 0 0 | ||
| 194 | 48 3 2 0 | ||
| 195 | 49 3 3 0 | ||
| 196 | |||
| 197 | Calibration occurs during runtime. No offline method is available. | ||
| 198 | Steady state compensation is used only when confidence levels of all | ||
| 199 | adjacent ratios have reached satisfactory level. A confidence level | ||
| 200 | is accumulated based on clean data collected at runtime. Data | ||
| 201 | collected during a period without extra interrupts is considered | ||
| 202 | clean. | ||
| 203 | |||
| 204 | To compensate for excessive amounts of wakeup during idle, additional | ||
| 205 | idle time is injected when such a condition is detected. Currently, | ||
| 206 | we have a simple algorithm to double the injection ratio. A possible | ||
| 207 | enhancement might be to throttle the offending IRQ, such as delaying | ||
| 208 | EOI for level triggered interrupts. But it is a challenge to be | ||
| 209 | non-intrusive to the scheduler or the IRQ core code. | ||
| 210 | |||
| 211 | |||
| 212 | CPU Online/Offline | ||
| 213 | ------------------ | ||
| 214 | Per-CPU kernel threads are started/stopped upon receiving | ||
| 215 | notifications of CPU hotplug activities. The intel_powerclamp driver | ||
| 216 | keeps track of clamping kernel threads, even after they are migrated | ||
| 217 | to other CPUs, after a CPU offline event. | ||
| 218 | |||
| 219 | |||
| 220 | ===================== | ||
| 221 | Performance Analysis | ||
| 222 | ===================== | ||
| 223 | This section describes the general performance data collected on | ||
| 224 | multiple systems, including Westmere (80P) and Ivy Bridge (4P, 8P). | ||
| 225 | |||
| 226 | Effectiveness and Limitations | ||
| 227 | ----------------------------- | ||
| 228 | The maximum range that idle injection is allowed is capped at 50 | ||
| 229 | percent. As mentioned earlier, since interrupts are allowed during | ||
| 230 | forced idle time, excessive interrupts could result in less | ||
| 231 | effectiveness. The extreme case would be doing a ping -f to generated | ||
| 232 | flooded network interrupts without much CPU acknowledgement. In this | ||
| 233 | case, little can be done from the idle injection threads. In most | ||
| 234 | normal cases, such as scp a large file, applications can be throttled | ||
| 235 | by the powerclamp driver, since slowing down the CPU also slows down | ||
| 236 | network protocol processing, which in turn reduces interrupts. | ||
| 237 | |||
| 238 | When control parameters change at runtime by the controlling CPU, it | ||
| 239 | may take an additional period for the rest of the CPUs to catch up | ||
| 240 | with the changes. During this time, idle injection is out of sync, | ||
| 241 | thus not able to enter package C- states at the expected ratio. But | ||
| 242 | this effect is minor, in that in most cases change to the target | ||
| 243 | ratio is updated much less frequently than the idle injection | ||
| 244 | frequency. | ||
| 245 | |||
| 246 | Scalability | ||
| 247 | ----------- | ||
| 248 | Tests also show a minor, but measurable, difference between the 4P/8P | ||
| 249 | Ivy Bridge system and the 80P Westmere server under 50% idle ratio. | ||
| 250 | More compensation is needed on Westmere for the same amount of | ||
| 251 | target idle ratio. The compensation also increases as the idle ratio | ||
| 252 | gets larger. The above reason constitutes the need for the | ||
| 253 | calibration code. | ||
| 254 | |||
| 255 | On the IVB 8P system, compared to an offline CPU, powerclamp can | ||
| 256 | achieve up to 40% better performance per watt. (measured by a spin | ||
| 257 | counter summed over per CPU counting threads spawned for all running | ||
| 258 | CPUs). | ||
| 259 | |||
| 260 | ==================== | ||
| 261 | Usage and Interfaces | ||
| 262 | ==================== | ||
| 263 | The powerclamp driver is registered to the generic thermal layer as a | ||
| 264 | cooling device. Currently, it’s not bound to any thermal zones. | ||
| 265 | |||
| 266 | jacob@chromoly:/sys/class/thermal/cooling_device14$ grep . * | ||
| 267 | cur_state:0 | ||
| 268 | max_state:50 | ||
| 269 | type:intel_powerclamp | ||
| 270 | |||
| 271 | Example usage: | ||
| 272 | - To inject 25% idle time | ||
| 273 | $ sudo sh -c "echo 25 > /sys/class/thermal/cooling_device80/cur_state | ||
| 274 | " | ||
| 275 | |||
| 276 | If the system is not busy and has more than 25% idle time already, | ||
| 277 | then the powerclamp driver will not start idle injection. Using Top | ||
| 278 | will not show idle injection kernel threads. | ||
| 279 | |||
| 280 | If the system is busy (spin test below) and has less than 25% natural | ||
| 281 | idle time, powerclamp kernel threads will do idle injection, which | ||
| 282 | appear running to the scheduler. But the overall system idle is still | ||
| 283 | reflected. In this example, 24.1% idle is shown. This helps the | ||
| 284 | system admin or user determine the cause of slowdown, when a | ||
| 285 | powerclamp driver is in action. | ||
| 286 | |||
| 287 | |||
| 288 | Tasks: 197 total, 1 running, 196 sleeping, 0 stopped, 0 zombie | ||
| 289 | Cpu(s): 71.2%us, 4.7%sy, 0.0%ni, 24.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st | ||
| 290 | Mem: 3943228k total, 1689632k used, 2253596k free, 74960k buffers | ||
| 291 | Swap: 4087804k total, 0k used, 4087804k free, 945336k cached | ||
| 292 | |||
| 293 | PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND | ||
| 294 | 3352 jacob 20 0 262m 644 428 S 286 0.0 0:17.16 spin | ||
| 295 | 3341 root -51 0 0 0 0 D 25 0.0 0:01.62 kidle_inject/0 | ||
| 296 | 3344 root -51 0 0 0 0 D 25 0.0 0:01.60 kidle_inject/3 | ||
| 297 | 3342 root -51 0 0 0 0 D 25 0.0 0:01.61 kidle_inject/1 | ||
| 298 | 3343 root -51 0 0 0 0 D 25 0.0 0:01.60 kidle_inject/2 | ||
| 299 | 2935 jacob 20 0 696m 125m 35m S 5 3.3 0:31.11 firefox | ||
| 300 | 1546 root 20 0 158m 20m 6640 S 3 0.5 0:26.97 Xorg | ||
| 301 | 2100 jacob 20 0 1223m 88m 30m S 3 2.3 0:23.68 compiz | ||
| 302 | |||
| 303 | Tests have shown that by using the powerclamp driver as a cooling | ||
| 304 | device, a PID based userspace thermal controller can manage to | ||
| 305 | control CPU temperature effectively, when no other thermal influence | ||
| 306 | is added. For example, a UltraBook user can compile the kernel under | ||
| 307 | certain temperature (below most active trip points). | ||
diff --git a/Documentation/thermal/nouveau_thermal b/Documentation/thermal/nouveau_thermal new file mode 100644 index 000000000000..efceb7828f54 --- /dev/null +++ b/Documentation/thermal/nouveau_thermal | |||
| @@ -0,0 +1,81 @@ | |||
| 1 | Kernel driver nouveau | ||
| 2 | =================== | ||
| 3 | |||
| 4 | Supported chips: | ||
| 5 | * NV43+ | ||
| 6 | |||
| 7 | Authors: Martin Peres (mupuf) <martin.peres@labri.fr> | ||
| 8 | |||
| 9 | Description | ||
| 10 | --------- | ||
| 11 | |||
| 12 | This driver allows to read the GPU core temperature, drive the GPU fan and | ||
| 13 | set temperature alarms. | ||
| 14 | |||
| 15 | Currently, due to the absence of in-kernel API to access HWMON drivers, Nouveau | ||
| 16 | cannot access any of the i2c external monitoring chips it may find. If you | ||
| 17 | have one of those, temperature and/or fan management through Nouveau's HWMON | ||
| 18 | interface is likely not to work. This document may then not cover your situation | ||
| 19 | entirely. | ||
| 20 | |||
| 21 | Temperature management | ||
| 22 | -------------------- | ||
| 23 | |||
| 24 | Temperature is exposed under as a read-only HWMON attribute temp1_input. | ||
| 25 | |||
| 26 | In order to protect the GPU from overheating, Nouveau supports 4 configurable | ||
| 27 | temperature thresholds: | ||
| 28 | |||
| 29 | * Fan_boost: Fan speed is set to 100% when reaching this temperature; | ||
| 30 | * Downclock: The GPU will be downclocked to reduce its power dissipation; | ||
| 31 | * Critical: The GPU is put on hold to further lower power dissipation; | ||
| 32 | * Shutdown: Shut the computer down to protect your GPU. | ||
| 33 | |||
| 34 | WARNING: Some of these thresholds may not be used by Nouveau depending | ||
| 35 | on your chipset. | ||
| 36 | |||
| 37 | The default value for these thresholds comes from the GPU's vbios. These | ||
| 38 | thresholds can be configured thanks to the following HWMON attributes: | ||
| 39 | |||
| 40 | * Fan_boost: temp1_auto_point1_temp and temp1_auto_point1_temp_hyst; | ||
| 41 | * Downclock: temp1_max and temp1_max_hyst; | ||
| 42 | * Critical: temp1_crit and temp1_crit_hyst; | ||
| 43 | * Shutdown: temp1_emergency and temp1_emergency_hyst. | ||
| 44 | |||
| 45 | NOTE: Remember that the values are stored as milli degrees Celcius. Don't forget | ||
| 46 | to multiply! | ||
| 47 | |||
| 48 | Fan management | ||
| 49 | ------------ | ||
| 50 | |||
| 51 | Not all cards have a drivable fan. If you do, then the following HWMON | ||
| 52 | attributes should be available: | ||
| 53 | |||
| 54 | * pwm1_enable: Current fan management mode (NONE, MANUAL or AUTO); | ||
| 55 | * pwm1: Current PWM value (power percentage); | ||
| 56 | * pwm1_min: The minimum PWM speed allowed; | ||
| 57 | * pwm1_max: The maximum PWM speed allowed (bypassed when hitting Fan_boost); | ||
| 58 | |||
| 59 | You may also have the following attribute: | ||
| 60 | |||
| 61 | * fan1_input: Speed in RPM of your fan. | ||
| 62 | |||
| 63 | Your fan can be driven in different modes: | ||
| 64 | |||
| 65 | * 0: The fan is left untouched; | ||
| 66 | * 1: The fan can be driven in manual (use pwm1 to change the speed); | ||
| 67 | * 2; The fan is driven automatically depending on the temperature. | ||
| 68 | |||
| 69 | NOTE: Be sure to use the manual mode if you want to drive the fan speed manually | ||
| 70 | |||
| 71 | NOTE2: Not all fan management modes may be supported on all chipsets. We are | ||
| 72 | working on it. | ||
| 73 | |||
| 74 | Bug reports | ||
| 75 | --------- | ||
| 76 | |||
| 77 | Thermal management on Nouveau is new and may not work on all cards. If you have | ||
| 78 | inquiries, please ping mupuf on IRC (#nouveau, freenode). | ||
| 79 | |||
| 80 | Bug reports should be filled on Freedesktop's bug tracker. Please follow | ||
| 81 | http://nouveau.freedesktop.org/wiki/Bugs | ||
diff --git a/Documentation/thermal/sysfs-api.txt b/Documentation/thermal/sysfs-api.txt index 88c02334e356..6859661c9d31 100644 --- a/Documentation/thermal/sysfs-api.txt +++ b/Documentation/thermal/sysfs-api.txt | |||
| @@ -55,6 +55,8 @@ temperature) and throttle appropriate devices. | |||
| 55 | .get_trip_type: get the type of certain trip point. | 55 | .get_trip_type: get the type of certain trip point. |
| 56 | .get_trip_temp: get the temperature above which the certain trip point | 56 | .get_trip_temp: get the temperature above which the certain trip point |
| 57 | will be fired. | 57 | will be fired. |
| 58 | .set_emul_temp: set the emulation temperature which helps in debugging | ||
| 59 | different threshold temperature points. | ||
| 58 | 60 | ||
| 59 | 1.1.2 void thermal_zone_device_unregister(struct thermal_zone_device *tz) | 61 | 1.1.2 void thermal_zone_device_unregister(struct thermal_zone_device *tz) |
| 60 | 62 | ||
| @@ -153,6 +155,7 @@ Thermal zone device sys I/F, created once it's registered: | |||
| 153 | |---trip_point_[0-*]_temp: Trip point temperature | 155 | |---trip_point_[0-*]_temp: Trip point temperature |
| 154 | |---trip_point_[0-*]_type: Trip point type | 156 | |---trip_point_[0-*]_type: Trip point type |
| 155 | |---trip_point_[0-*]_hyst: Hysteresis value for this trip point | 157 | |---trip_point_[0-*]_hyst: Hysteresis value for this trip point |
| 158 | |---emul_temp: Emulated temperature set node | ||
| 156 | 159 | ||
| 157 | Thermal cooling device sys I/F, created once it's registered: | 160 | Thermal cooling device sys I/F, created once it's registered: |
| 158 | /sys/class/thermal/cooling_device[0-*]: | 161 | /sys/class/thermal/cooling_device[0-*]: |
| @@ -252,6 +255,16 @@ passive | |||
| 252 | Valid values: 0 (disabled) or greater than 1000 | 255 | Valid values: 0 (disabled) or greater than 1000 |
| 253 | RW, Optional | 256 | RW, Optional |
| 254 | 257 | ||
| 258 | emul_temp | ||
| 259 | Interface to set the emulated temperature method in thermal zone | ||
| 260 | (sensor). After setting this temperature, the thermal zone may pass | ||
| 261 | this temperature to platform emulation function if registered or | ||
| 262 | cache it locally. This is useful in debugging different temperature | ||
| 263 | threshold and its associated cooling action. This is write only node | ||
| 264 | and writing 0 on this node should disable emulation. | ||
| 265 | Unit: millidegree Celsius | ||
| 266 | WO, Optional | ||
| 267 | |||
| 255 | ***************************** | 268 | ***************************** |
| 256 | * Cooling device attributes * | 269 | * Cooling device attributes * |
| 257 | ***************************** | 270 | ***************************** |
| @@ -329,8 +342,9 @@ The framework includes a simple notification mechanism, in the form of a | |||
| 329 | netlink event. Netlink socket initialization is done during the _init_ | 342 | netlink event. Netlink socket initialization is done during the _init_ |
| 330 | of the framework. Drivers which intend to use the notification mechanism | 343 | of the framework. Drivers which intend to use the notification mechanism |
| 331 | just need to call thermal_generate_netlink_event() with two arguments viz | 344 | just need to call thermal_generate_netlink_event() with two arguments viz |
| 332 | (originator, event). Typically the originator will be an integer assigned | 345 | (originator, event). The originator is a pointer to struct thermal_zone_device |
| 333 | to a thermal_zone_device when it registers itself with the framework. The | 346 | from where the event has been originated. An integer which represents the |
| 347 | thermal zone device will be used in the message to identify the zone. The | ||
| 334 | event will be one of:{THERMAL_AUX0, THERMAL_AUX1, THERMAL_CRITICAL, | 348 | event will be one of:{THERMAL_AUX0, THERMAL_AUX1, THERMAL_CRITICAL, |
| 335 | THERMAL_DEV_FAULT}. Notification can be sent when the current temperature | 349 | THERMAL_DEV_FAULT}. Notification can be sent when the current temperature |
| 336 | crosses any of the configured thresholds. | 350 | crosses any of the configured thresholds. |
diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt index 53d6a3c51d87..a372304aef10 100644 --- a/Documentation/trace/ftrace.txt +++ b/Documentation/trace/ftrace.txt | |||
| @@ -1873,7 +1873,7 @@ feature: | |||
| 1873 | 1873 | ||
| 1874 | status\input | 0 | 1 | else | | 1874 | status\input | 0 | 1 | else | |
| 1875 | --------------+------------+------------+------------+ | 1875 | --------------+------------+------------+------------+ |
| 1876 | not allocated |(do nothing)| alloc+swap | EINVAL | | 1876 | not allocated |(do nothing)| alloc+swap |(do nothing)| |
| 1877 | --------------+------------+------------+------------+ | 1877 | --------------+------------+------------+------------+ |
| 1878 | allocated | free | swap | clear | | 1878 | allocated | free | swap | clear | |
| 1879 | --------------+------------+------------+------------+ | 1879 | --------------+------------+------------+------------+ |
diff --git a/Documentation/video4linux/CARDLIST.au0828 b/Documentation/video4linux/CARDLIST.au0828 index a8a65753e544..55a21deab7db 100644 --- a/Documentation/video4linux/CARDLIST.au0828 +++ b/Documentation/video4linux/CARDLIST.au0828 | |||
| @@ -1,5 +1,5 @@ | |||
| 1 | 0 -> Unknown board (au0828) | 1 | 0 -> Unknown board (au0828) |
| 2 | 1 -> Hauppauge HVR950Q (au0828) [2040:7200,2040:7210,2040:7217,2040:721b,2040:721e,2040:721f,2040:7280,0fd9:0008,2040:7260,2040:7213] | 2 | 1 -> Hauppauge HVR950Q (au0828) [2040:7200,2040:7210,2040:7217,2040:721b,2040:721e,2040:721f,2040:7280,0fd9:0008,2040:7260,2040:7213,2040:7270] |
| 3 | 2 -> Hauppauge HVR850 (au0828) [2040:7240] | 3 | 2 -> Hauppauge HVR850 (au0828) [2040:7240] |
| 4 | 3 -> DViCO FusionHDTV USB (au0828) [0fe9:d620] | 4 | 3 -> DViCO FusionHDTV USB (au0828) [0fe9:d620] |
| 5 | 4 -> Hauppauge HVR950Q rev xxF8 (au0828) [2040:7201,2040:7211,2040:7281] | 5 | 4 -> Hauppauge HVR950Q rev xxF8 (au0828) [2040:7201,2040:7211,2040:7281] |
diff --git a/Documentation/video4linux/CARDLIST.cx23885 b/Documentation/video4linux/CARDLIST.cx23885 index 1299b5e82d7f..9f056d512e35 100644 --- a/Documentation/video4linux/CARDLIST.cx23885 +++ b/Documentation/video4linux/CARDLIST.cx23885 | |||
| @@ -36,3 +36,5 @@ | |||
| 36 | 35 -> TeVii S471 [d471:9022] | 36 | 35 -> TeVii S471 [d471:9022] |
| 37 | 36 -> Hauppauge WinTV-HVR1255 [0070:2259] | 37 | 36 -> Hauppauge WinTV-HVR1255 [0070:2259] |
| 38 | 37 -> Prof Revolution DVB-S2 8000 [8000:3034] | 38 | 37 -> Prof Revolution DVB-S2 8000 [8000:3034] |
| 39 | 38 -> Hauppauge WinTV-HVR4400 [0070:c108,0070:c138,0070:c12a,0070:c1f8] | ||
| 40 | 39 -> AVerTV Hybrid Express Slim HC81R [1461:d939] | ||
diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx index d99262dda533..3f12865b2a88 100644 --- a/Documentation/video4linux/CARDLIST.em28xx +++ b/Documentation/video4linux/CARDLIST.em28xx | |||
| @@ -76,7 +76,7 @@ | |||
| 76 | 76 -> KWorld PlusTV 340U or UB435-Q (ATSC) (em2870) [1b80:a340] | 76 | 76 -> KWorld PlusTV 340U or UB435-Q (ATSC) (em2870) [1b80:a340] |
| 77 | 77 -> EM2874 Leadership ISDBT (em2874) | 77 | 77 -> EM2874 Leadership ISDBT (em2874) |
| 78 | 78 -> PCTV nanoStick T2 290e (em28174) | 78 | 78 -> PCTV nanoStick T2 290e (em28174) |
| 79 | 79 -> Terratec Cinergy H5 (em2884) [0ccd:008e,0ccd:00ac,0ccd:10a2,0ccd:10ad] | 79 | 79 -> Terratec Cinergy H5 (em2884) [0ccd:10a2,0ccd:10ad] |
| 80 | 80 -> PCTV DVB-S2 Stick (460e) (em28174) | 80 | 80 -> PCTV DVB-S2 Stick (460e) (em28174) |
| 81 | 81 -> Hauppauge WinTV HVR 930C (em2884) [2040:1605] | 81 | 81 -> Hauppauge WinTV HVR 930C (em2884) [2040:1605] |
| 82 | 82 -> Terratec Cinergy HTC Stick (em2884) [0ccd:00b2] | 82 | 82 -> Terratec Cinergy HTC Stick (em2884) [0ccd:00b2] |
| @@ -84,3 +84,4 @@ | |||
| 84 | 84 -> MaxMedia UB425-TC (em2874) [1b80:e425] | 84 | 84 -> MaxMedia UB425-TC (em2874) [1b80:e425] |
| 85 | 85 -> PCTV QuatroStick (510e) (em2884) [2304:0242] | 85 | 85 -> PCTV QuatroStick (510e) (em2884) [2304:0242] |
| 86 | 86 -> PCTV QuatroStick nano (520e) (em2884) [2013:0251] | 86 | 86 -> PCTV QuatroStick nano (520e) (em2884) [2013:0251] |
| 87 | 87 -> Terratec Cinergy HTC USB XS (em2884) [0ccd:008e,0ccd:00ac] | ||
diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134 index 94d9025aa82d..b3ad68309109 100644 --- a/Documentation/video4linux/CARDLIST.saa7134 +++ b/Documentation/video4linux/CARDLIST.saa7134 | |||
| @@ -189,3 +189,4 @@ | |||
| 189 | 188 -> Sensoray 811/911 [6000:0811,6000:0911] | 189 | 188 -> Sensoray 811/911 [6000:0811,6000:0911] |
| 190 | 189 -> Kworld PC150-U [17de:a134] | 190 | 189 -> Kworld PC150-U [17de:a134] |
| 191 | 190 -> Asus My Cinema PS3-100 [1043:48cd] | 191 | 190 -> Asus My Cinema PS3-100 [1043:48cd] |
| 192 | 191 -> Hawell HW-9004V1 | ||
diff --git a/Documentation/video4linux/et61x251.txt b/Documentation/video4linux/et61x251.txt deleted file mode 100644 index e0cdae491858..000000000000 --- a/Documentation/video4linux/et61x251.txt +++ /dev/null | |||
| @@ -1,315 +0,0 @@ | |||
| 1 | |||
| 2 | ET61X[12]51 PC Camera Controllers | ||
| 3 | Driver for Linux | ||
| 4 | ================================= | ||
| 5 | |||
| 6 | - Documentation - | ||
| 7 | |||
| 8 | |||
| 9 | Index | ||
| 10 | ===== | ||
| 11 | 1. Copyright | ||
| 12 | 2. Disclaimer | ||
| 13 | 3. License | ||
| 14 | 4. Overview and features | ||
| 15 | 5. Module dependencies | ||
| 16 | 6. Module loading | ||
| 17 | 7. Module parameters | ||
| 18 | 8. Optional device control through "sysfs" | ||
| 19 | 9. Supported devices | ||
| 20 | 10. Notes for V4L2 application developers | ||
| 21 | 11. Contact information | ||
| 22 | |||
| 23 | |||
| 24 | 1. Copyright | ||
| 25 | ============ | ||
| 26 | Copyright (C) 2006-2007 by Luca Risolia <luca.risolia@studio.unibo.it> | ||
| 27 | |||
| 28 | |||
| 29 | 2. Disclaimer | ||
| 30 | ============= | ||
| 31 | Etoms is a trademark of Etoms Electronics Corp. | ||
| 32 | This software is not developed or sponsored by Etoms Electronics. | ||
| 33 | |||
| 34 | |||
| 35 | 3. License | ||
| 36 | ========== | ||
| 37 | This program is free software; you can redistribute it and/or modify | ||
| 38 | it under the terms of the GNU General Public License as published by | ||
| 39 | the Free Software Foundation; either version 2 of the License, or | ||
| 40 | (at your option) any later version. | ||
| 41 | |||
| 42 | This program is distributed in the hope that it will be useful, | ||
| 43 | but WITHOUT ANY WARRANTY; without even the implied warranty of | ||
| 44 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | ||
| 45 | GNU General Public License for more details. | ||
| 46 | |||
| 47 | You should have received a copy of the GNU General Public License | ||
| 48 | along with this program; if not, write to the Free Software | ||
| 49 | Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. | ||
| 50 | |||
| 51 | |||
| 52 | 4. Overview and features | ||
| 53 | ======================== | ||
| 54 | This driver supports the video interface of the devices mounting the ET61X151 | ||
| 55 | or ET61X251 PC Camera Controllers. | ||
| 56 | |||
| 57 | It's worth to note that Etoms Electronics has never collaborated with the | ||
| 58 | author during the development of this project; despite several requests, | ||
| 59 | Etoms Electronics also refused to release enough detailed specifications of | ||
| 60 | the video compression engine. | ||
| 61 | |||
| 62 | The driver relies on the Video4Linux2 and USB core modules. It has been | ||
| 63 | designed to run properly on SMP systems as well. | ||
| 64 | |||
| 65 | The latest version of the ET61X[12]51 driver can be found at the following URL: | ||
| 66 | http://www.linux-projects.org/ | ||
| 67 | |||
| 68 | Some of the features of the driver are: | ||
| 69 | |||
| 70 | - full compliance with the Video4Linux2 API (see also "Notes for V4L2 | ||
| 71 | application developers" paragraph); | ||
| 72 | - available mmap or read/poll methods for video streaming through isochronous | ||
| 73 | data transfers; | ||
| 74 | - automatic detection of image sensor; | ||
| 75 | - support for any window resolutions and optional panning within the maximum | ||
| 76 | pixel area of image sensor; | ||
| 77 | - image downscaling with arbitrary scaling factors from 1 and 2 in both | ||
| 78 | directions (see "Notes for V4L2 application developers" paragraph); | ||
| 79 | - two different video formats for uncompressed or compressed data in low or | ||
| 80 | high compression quality (see also "Notes for V4L2 application developers" | ||
| 81 | paragraph); | ||
| 82 | - full support for the capabilities of every possible image sensors that can | ||
| 83 | be connected to the ET61X[12]51 bridges, including, for instance, red, green, | ||
| 84 | blue and global gain adjustments and exposure control (see "Supported | ||
| 85 | devices" paragraph for details); | ||
| 86 | - use of default color settings for sunlight conditions; | ||
| 87 | - dynamic I/O interface for both ET61X[12]51 and image sensor control (see | ||
| 88 | "Optional device control through 'sysfs'" paragraph); | ||
| 89 | - dynamic driver control thanks to various module parameters (see "Module | ||
| 90 | parameters" paragraph); | ||
| 91 | - up to 64 cameras can be handled at the same time; they can be connected and | ||
| 92 | disconnected from the host many times without turning off the computer, if | ||
| 93 | the system supports hotplugging; | ||
| 94 | - no known bugs. | ||
| 95 | |||
| 96 | |||
| 97 | 5. Module dependencies | ||
| 98 | ====================== | ||
| 99 | For it to work properly, the driver needs kernel support for Video4Linux and | ||
| 100 | USB. | ||
| 101 | |||
| 102 | The following options of the kernel configuration file must be enabled and | ||
| 103 | corresponding modules must be compiled: | ||
| 104 | |||
| 105 | # Multimedia devices | ||
| 106 | # | ||
| 107 | CONFIG_VIDEO_DEV=m | ||
| 108 | |||
| 109 | To enable advanced debugging functionality on the device through /sysfs: | ||
| 110 | |||
| 111 | # Multimedia devices | ||
| 112 | # | ||
| 113 | CONFIG_VIDEO_ADV_DEBUG=y | ||
| 114 | |||
| 115 | # USB support | ||
| 116 | # | ||
| 117 | CONFIG_USB=m | ||
| 118 | |||
| 119 | In addition, depending on the hardware being used, the modules below are | ||
| 120 | necessary: | ||
| 121 | |||
| 122 | # USB Host Controller Drivers | ||
| 123 | # | ||
| 124 | CONFIG_USB_EHCI_HCD=m | ||
| 125 | CONFIG_USB_UHCI_HCD=m | ||
| 126 | CONFIG_USB_OHCI_HCD=m | ||
| 127 | |||
| 128 | And finally: | ||
| 129 | |||
| 130 | # USB Multimedia devices | ||
| 131 | # | ||
| 132 | CONFIG_USB_ET61X251=m | ||
| 133 | |||
| 134 | |||
| 135 | 6. Module loading | ||
| 136 | ================= | ||
| 137 | To use the driver, it is necessary to load the "et61x251" module into memory | ||
| 138 | after every other module required: "videodev", "v4l2_common", "compat_ioctl32", | ||
| 139 | "usbcore" and, depending on the USB host controller you have, "ehci-hcd", | ||
| 140 | "uhci-hcd" or "ohci-hcd". | ||
| 141 | |||
| 142 | Loading can be done as shown below: | ||
| 143 | |||
| 144 | [root@localhost home]# modprobe et61x251 | ||
| 145 | |||
| 146 | At this point the devices should be recognized. You can invoke "dmesg" to | ||
| 147 | analyze kernel messages and verify that the loading process has gone well: | ||
| 148 | |||
| 149 | [user@localhost home]$ dmesg | ||
| 150 | |||
| 151 | |||
| 152 | 7. Module parameters | ||
| 153 | ==================== | ||
| 154 | Module parameters are listed below: | ||
| 155 | ------------------------------------------------------------------------------- | ||
| 156 | Name: video_nr | ||
| 157 | Type: short array (min = 0, max = 64) | ||
| 158 | Syntax: <-1|n[,...]> | ||
| 159 | Description: Specify V4L2 minor mode number: | ||
| 160 | -1 = use next available | ||
| 161 | n = use minor number n | ||
| 162 | You can specify up to 64 cameras this way. | ||
| 163 | For example: | ||
| 164 | video_nr=-1,2,-1 would assign minor number 2 to the second | ||
| 165 | registered camera and use auto for the first one and for every | ||
| 166 | other camera. | ||
| 167 | Default: -1 | ||
| 168 | ------------------------------------------------------------------------------- | ||
| 169 | Name: force_munmap | ||
| 170 | Type: bool array (min = 0, max = 64) | ||
| 171 | Syntax: <0|1[,...]> | ||
| 172 | Description: Force the application to unmap previously mapped buffer memory | ||
| 173 | before calling any VIDIOC_S_CROP or VIDIOC_S_FMT ioctl's. Not | ||
| 174 | all the applications support this feature. This parameter is | ||
| 175 | specific for each detected camera. | ||
| 176 | 0 = do not force memory unmapping | ||
| 177 | 1 = force memory unmapping (save memory) | ||
| 178 | Default: 0 | ||
| 179 | ------------------------------------------------------------------------------- | ||
| 180 | Name: frame_timeout | ||
| 181 | Type: uint array (min = 0, max = 64) | ||
| 182 | Syntax: <n[,...]> | ||
| 183 | Description: Timeout for a video frame in seconds. This parameter is | ||
| 184 | specific for each detected camera. This parameter can be | ||
| 185 | changed at runtime thanks to the /sys filesystem interface. | ||
| 186 | Default: 2 | ||
| 187 | ------------------------------------------------------------------------------- | ||
| 188 | Name: debug | ||
| 189 | Type: ushort | ||
| 190 | Syntax: <n> | ||
| 191 | Description: Debugging information level, from 0 to 3: | ||
| 192 | 0 = none (use carefully) | ||
| 193 | 1 = critical errors | ||
| 194 | 2 = significant information | ||
| 195 | 3 = more verbose messages | ||
| 196 | Level 3 is useful for testing only, when only one device | ||
| 197 | is used at the same time. It also shows some more information | ||
| 198 | about the hardware being detected. This module parameter can be | ||
| 199 | changed at runtime thanks to the /sys filesystem interface. | ||
| 200 | Default: 2 | ||
| 201 | ------------------------------------------------------------------------------- | ||
| 202 | |||
| 203 | |||
| 204 | 8. Optional device control through "sysfs" | ||
| 205 | ========================================== | ||
| 206 | If the kernel has been compiled with the CONFIG_VIDEO_ADV_DEBUG option enabled, | ||
| 207 | it is possible to read and write both the ET61X[12]51 and the image sensor | ||
| 208 | registers by using the "sysfs" filesystem interface. | ||
| 209 | |||
| 210 | There are four files in the /sys/class/video4linux/videoX directory for each | ||
| 211 | registered camera: "reg", "val", "i2c_reg" and "i2c_val". The first two files | ||
| 212 | control the ET61X[12]51 bridge, while the other two control the sensor chip. | ||
| 213 | "reg" and "i2c_reg" hold the values of the current register index where the | ||
| 214 | following reading/writing operations are addressed at through "val" and | ||
| 215 | "i2c_val". Their use is not intended for end-users, unless you know what you | ||
| 216 | are doing. Remember that you must be logged in as root before writing to them. | ||
| 217 | |||
| 218 | As an example, suppose we were to want to read the value contained in the | ||
| 219 | register number 1 of the sensor register table - which is usually the product | ||
| 220 | identifier - of the camera registered as "/dev/video0": | ||
| 221 | |||
| 222 | [root@localhost #] cd /sys/class/video4linux/video0 | ||
| 223 | [root@localhost #] echo 1 > i2c_reg | ||
| 224 | [root@localhost #] cat i2c_val | ||
| 225 | |||
| 226 | Note that if the sensor registers cannot be read, "cat" will fail. | ||
| 227 | To avoid race conditions, all the I/O accesses to the files are serialized. | ||
| 228 | |||
| 229 | |||
| 230 | 9. Supported devices | ||
| 231 | ==================== | ||
| 232 | None of the names of the companies as well as their products will be mentioned | ||
| 233 | here. They have never collaborated with the author, so no advertising. | ||
| 234 | |||
| 235 | From the point of view of a driver, what unambiguously identify a device are | ||
| 236 | its vendor and product USB identifiers. Below is a list of known identifiers of | ||
| 237 | devices mounting the ET61X[12]51 PC camera controllers: | ||
| 238 | |||
| 239 | Vendor ID Product ID | ||
| 240 | --------- ---------- | ||
| 241 | 0x102c 0x6151 | ||
| 242 | 0x102c 0x6251 | ||
| 243 | 0x102c 0x6253 | ||
| 244 | 0x102c 0x6254 | ||
| 245 | 0x102c 0x6255 | ||
| 246 | 0x102c 0x6256 | ||
| 247 | 0x102c 0x6257 | ||
| 248 | 0x102c 0x6258 | ||
| 249 | 0x102c 0x6259 | ||
| 250 | 0x102c 0x625a | ||
| 251 | 0x102c 0x625b | ||
| 252 | 0x102c 0x625c | ||
| 253 | 0x102c 0x625d | ||
| 254 | 0x102c 0x625e | ||
| 255 | 0x102c 0x625f | ||
| 256 | 0x102c 0x6260 | ||
| 257 | 0x102c 0x6261 | ||
| 258 | 0x102c 0x6262 | ||
| 259 | 0x102c 0x6263 | ||
| 260 | 0x102c 0x6264 | ||
| 261 | 0x102c 0x6265 | ||
| 262 | 0x102c 0x6266 | ||
| 263 | 0x102c 0x6267 | ||
| 264 | 0x102c 0x6268 | ||
| 265 | 0x102c 0x6269 | ||
| 266 | |||
| 267 | The following image sensors are supported: | ||
| 268 | |||
| 269 | Model Manufacturer | ||
| 270 | ----- ------------ | ||
| 271 | TAS5130D1B Taiwan Advanced Sensor Corporation | ||
| 272 | |||
| 273 | All the available control settings of each image sensor are supported through | ||
| 274 | the V4L2 interface. | ||
| 275 | |||
| 276 | |||
| 277 | 10. Notes for V4L2 application developers | ||
| 278 | ========================================= | ||
| 279 | This driver follows the V4L2 API specifications. In particular, it enforces two | ||
| 280 | rules: | ||
| 281 | |||
| 282 | - exactly one I/O method, either "mmap" or "read", is associated with each | ||
| 283 | file descriptor. Once it is selected, the application must close and reopen the | ||
| 284 | device to switch to the other I/O method; | ||
| 285 | |||
| 286 | - although it is not mandatory, previously mapped buffer memory should always | ||
| 287 | be unmapped before calling any "VIDIOC_S_CROP" or "VIDIOC_S_FMT" ioctl's. | ||
| 288 | The same number of buffers as before will be allocated again to match the size | ||
| 289 | of the new video frames, so you have to map the buffers again before any I/O | ||
| 290 | attempts on them. | ||
| 291 | |||
| 292 | Consistently with the hardware limits, this driver also supports image | ||
| 293 | downscaling with arbitrary scaling factors from 1 and 2 in both directions. | ||
| 294 | However, the V4L2 API specifications don't correctly define how the scaling | ||
| 295 | factor can be chosen arbitrarily by the "negotiation" of the "source" and | ||
| 296 | "target" rectangles. To work around this flaw, we have added the convention | ||
| 297 | that, during the negotiation, whenever the "VIDIOC_S_CROP" ioctl is issued, the | ||
| 298 | scaling factor is restored to 1. | ||
| 299 | |||
| 300 | This driver supports two different video formats: the first one is the "8-bit | ||
| 301 | Sequential Bayer" format and can be used to obtain uncompressed video data | ||
| 302 | from the device through the current I/O method, while the second one provides | ||
| 303 | "raw" compressed video data (without frame headers not related to the | ||
| 304 | compressed data). The current compression quality may vary from 0 to 1 and can | ||
| 305 | be selected or queried thanks to the VIDIOC_S_JPEGCOMP and VIDIOC_G_JPEGCOMP | ||
| 306 | V4L2 ioctl's. | ||
| 307 | |||
| 308 | |||
| 309 | 11. Contact information | ||
| 310 | ======================= | ||
| 311 | The author may be contacted by e-mail at <luca.risolia@studio.unibo.it>. | ||
| 312 | |||
| 313 | GPG/PGP encrypted e-mail's are accepted. The GPG key ID of the author is | ||
| 314 | 'FCE635A4'; the public 1024-bit key should be available at any keyserver; | ||
| 315 | the fingerprint is: '88E8 F32F 7244 68BA 3958 5D40 99DA 5D2A FCE6 35A4'. | ||
diff --git a/Documentation/video4linux/extract_xc3028.pl b/Documentation/video4linux/extract_xc3028.pl index 47877deae6d7..47877deae6d7 100644..100755 --- a/Documentation/video4linux/extract_xc3028.pl +++ b/Documentation/video4linux/extract_xc3028.pl | |||
diff --git a/Documentation/video4linux/fimc.txt b/Documentation/video4linux/fimc.txt index fd02d9a4930a..25f4d3402722 100644 --- a/Documentation/video4linux/fimc.txt +++ b/Documentation/video4linux/fimc.txt | |||
| @@ -58,7 +58,7 @@ Not currently supported: | |||
| 58 | 4.1. Media device interface | 58 | 4.1. Media device interface |
| 59 | 59 | ||
| 60 | The driver supports Media Controller API as defined at | 60 | The driver supports Media Controller API as defined at |
| 61 | http://http://linuxtv.org/downloads/v4l-dvb-apis/media_common.html | 61 | http://linuxtv.org/downloads/v4l-dvb-apis/media_common.html |
| 62 | The media device driver name is "SAMSUNG S5P FIMC". | 62 | The media device driver name is "SAMSUNG S5P FIMC". |
| 63 | 63 | ||
| 64 | The purpose of this interface is to allow changing assignment of FIMC instances | 64 | The purpose of this interface is to allow changing assignment of FIMC instances |
diff --git a/Documentation/video4linux/ibmcam.txt b/Documentation/video4linux/ibmcam.txt deleted file mode 100644 index a51055211e62..000000000000 --- a/Documentation/video4linux/ibmcam.txt +++ /dev/null | |||
| @@ -1,323 +0,0 @@ | |||
| 1 | README for Linux device driver for the IBM "C-It" USB video camera | ||
| 2 | |||
| 3 | INTRODUCTION: | ||
| 4 | |||
| 5 | This driver does not use all features known to exist in | ||
| 6 | the IBM camera. However most of needed features work well. | ||
| 7 | |||
| 8 | This driver was developed using logs of observed USB traffic | ||
| 9 | which was produced by standard Windows driver (c-it98.sys). | ||
| 10 | I did not have data sheets from Xirlink. | ||
| 11 | |||
| 12 | Video formats: | ||
| 13 | 128x96 [model 1] | ||
| 14 | 176x144 | ||
| 15 | 320x240 [model 2] | ||
| 16 | 352x240 [model 2] | ||
| 17 | 352x288 | ||
| 18 | Frame rate: 3 - 30 frames per second (FPS) | ||
| 19 | External interface: USB | ||
| 20 | Internal interface: Video For Linux (V4L) | ||
| 21 | Supported controls: | ||
| 22 | - by V4L: Contrast, Brightness, Color, Hue | ||
| 23 | - by driver options: frame rate, lighting conditions, video format, | ||
| 24 | default picture settings, sharpness. | ||
| 25 | |||
| 26 | SUPPORTED CAMERAS: | ||
| 27 | |||
| 28 | Xirlink "C-It" camera, also known as "IBM PC Camera". | ||
| 29 | The device uses proprietary ASIC (and compression method); | ||
| 30 | it is manufactured by Xirlink. See http://xirlinkwebcam.sourceforge.net, | ||
| 31 | http://www.ibmpccamera.com, or http://www.c-itnow.com/ for details and pictures. | ||
| 32 | |||
| 33 | This very chipset ("X Chip", as marked at the factory) | ||
| 34 | is used in several other cameras, and they are supported | ||
| 35 | as well: | ||
| 36 | |||
| 37 | - IBM NetCamera | ||
| 38 | - Veo Stingray | ||
| 39 | |||
| 40 | The Linux driver was developed with camera with following | ||
| 41 | model number (or FCC ID): KSX-XVP510. This camera has three | ||
| 42 | interfaces, each with one endpoint (control, iso, iso). This | ||
| 43 | type of cameras is referred to as "model 1". These cameras are | ||
| 44 | no longer manufactured. | ||
| 45 | |||
| 46 | Xirlink now manufactures new cameras which are somewhat different. | ||
| 47 | In particular, following models [FCC ID] belong to that category: | ||
| 48 | |||
| 49 | XVP300 [KSX-X9903] | ||
| 50 | XVP600 [KSX-X9902] | ||
| 51 | XVP610 [KSX-X9902] | ||
| 52 | |||
| 53 | (see http://www.xirlink.com/ibmpccamera/ for updates, they refer | ||
| 54 | to these new cameras by Windows driver dated 12-27-99, v3005 BETA) | ||
| 55 | These cameras have two interfaces, one endpoint in each (iso, bulk). | ||
| 56 | Such type of cameras is referred to as "model 2". They are supported | ||
| 57 | (with exception of 352x288 native mode). | ||
| 58 | |||
| 59 | Some IBM NetCameras (Model 4) are made to generate only compressed | ||
| 60 | video streams. This is great for performance, but unfortunately | ||
| 61 | nobody knows how to decompress the stream :-( Therefore, these | ||
| 62 | cameras are *unsupported* and if you try to use one of those, all | ||
| 63 | you get is random colored horizontal streaks, not the image! | ||
| 64 | If you have one of those cameras, you probably should return it | ||
| 65 | to the store and get something that is supported. | ||
| 66 | |||
| 67 | Tell me more about all that "model" business | ||
| 68 | -------------------------------------------- | ||
| 69 | |||
| 70 | I just invented model numbers to uniquely identify flavors of the | ||
| 71 | hardware/firmware that were sold. It was very confusing to use | ||
| 72 | brand names or some other internal numbering schemes. So I found | ||
| 73 | by experimentation that all Xirlink chipsets fall into four big | ||
| 74 | classes, and I called them "models". Each model is programmed in | ||
| 75 | its own way, and each model sends back the video in its own way. | ||
| 76 | |||
| 77 | Quirks of Model 2 cameras: | ||
| 78 | ------------------------- | ||
| 79 | |||
| 80 | Model 2 does not have hardware contrast control. Corresponding V4L | ||
| 81 | control is implemented in software, which is not very nice to your | ||
| 82 | CPU, but at least it works. | ||
| 83 | |||
| 84 | This driver provides 352x288 mode by switching the camera into | ||
| 85 | quasi-352x288 RGB mode (800 Kbits per frame) essentially limiting | ||
| 86 | this mode to 10 frames per second or less, in ideal conditions on | ||
| 87 | the bus (USB is shared, after all). The frame rate | ||
| 88 | has to be programmed very conservatively. Additional concern is that | ||
| 89 | frame rate depends on brightness setting; therefore the picture can | ||
| 90 | be good at one brightness and broken at another! I did not want to fix | ||
| 91 | the frame rate at slowest setting, but I had to move it pretty much down | ||
| 92 | the scale (so that framerate option barely matters). I also noticed that | ||
| 93 | camera after first powering up produces frames slightly faster than during | ||
| 94 | consecutive uses. All this means that if you use 352x288 (which is | ||
| 95 | default), be warned - you may encounter broken picture on first connect; | ||
| 96 | try to adjust brightness - brighter image is slower, so USB will be able | ||
| 97 | to send all data. However if you regularly use Model 2 cameras you may | ||
| 98 | prefer 176x144 which makes perfectly good I420, with no scaling and | ||
| 99 | lesser demands on USB (300 Kbits per second, or 26 frames per second). | ||
| 100 | |||
| 101 | Another strange effect of 352x288 mode is the fine vertical grid visible | ||
| 102 | on some colored surfaces. I am sure it is caused by me not understanding | ||
| 103 | what the camera is trying to say. Blame trade secrets for that. | ||
| 104 | |||
| 105 | The camera that I had also has a hardware quirk: if disconnected, | ||
| 106 | it needs few minutes to "relax" before it can be plugged in again | ||
| 107 | (poorly designed USB processor reset circuit?) | ||
| 108 | |||
| 109 | [Veo Stingray with Product ID 0x800C is also Model 2, but I haven't | ||
| 110 | observed this particular flaw in it.] | ||
| 111 | |||
| 112 | Model 2 camera can be programmed for very high sensitivity (even starlight | ||
| 113 | may be enough), this makes it convenient for tinkering with. The driver | ||
| 114 | code has enough comments to help a programmer to tweak the camera | ||
| 115 | as s/he feels necessary. | ||
| 116 | |||
| 117 | WHAT YOU NEED: | ||
| 118 | |||
| 119 | - A supported IBM PC (C-it) camera (model 1 or 2) | ||
| 120 | |||
| 121 | - A Linux box with USB support (2.3/2.4; 2.2 w/backport may work) | ||
| 122 | |||
| 123 | - A Video4Linux compatible frame grabber program such as xawtv. | ||
| 124 | |||
| 125 | HOW TO COMPILE THE DRIVER: | ||
| 126 | |||
| 127 | You need to compile the driver only if you are a developer | ||
| 128 | or if you want to make changes to the code. Most distributions | ||
| 129 | precompile all modules, so you can go directly to the next | ||
| 130 | section "HOW TO USE THE DRIVER". | ||
| 131 | |||
| 132 | The ibmcam driver uses usbvideo helper library (module), | ||
| 133 | so if you are studying the ibmcam code you will be led there. | ||
| 134 | |||
| 135 | The driver itself consists of only one file in usb/ directory: | ||
| 136 | ibmcam.c. This file is included into the Linux kernel build | ||
| 137 | process if you configure the kernel for CONFIG_USB_IBMCAM. | ||
| 138 | Run "make xconfig" and in USB section you will find the IBM | ||
| 139 | camera driver. Select it, save the configuration and recompile. | ||
| 140 | |||
| 141 | HOW TO USE THE DRIVER: | ||
| 142 | |||
| 143 | I recommend to compile driver as a module. This gives you an | ||
| 144 | easier access to its configuration. The camera has many more | ||
| 145 | settings than V4L can operate, so some settings are done using | ||
| 146 | module options. | ||
| 147 | |||
| 148 | To begin with, on most modern Linux distributions the driver | ||
| 149 | will be automatically loaded whenever you plug the supported | ||
| 150 | camera in. Therefore, you don't need to do anything. However | ||
| 151 | if you want to experiment with some module parameters then | ||
| 152 | you can load and unload the driver manually, with camera | ||
| 153 | plugged in or unplugged. | ||
| 154 | |||
| 155 | Typically module is installed with command 'modprobe', like this: | ||
| 156 | |||
| 157 | # modprobe ibmcam framerate=1 | ||
| 158 | |||
| 159 | Alternatively you can use 'insmod' in similar fashion: | ||
| 160 | |||
| 161 | # insmod /lib/modules/2.x.y/usb/ibmcam.o framerate=1 | ||
| 162 | |||
| 163 | Module can be inserted with camera connected or disconnected. | ||
| 164 | |||
| 165 | The driver can have options, though some defaults are provided. | ||
| 166 | |||
| 167 | Driver options: (* indicates that option is model-dependent) | ||
| 168 | |||
| 169 | Name Type Range [default] Example | ||
| 170 | -------------- -------------- -------------- ------------------ | ||
| 171 | debug Integer 0-9 [0] debug=1 | ||
| 172 | flags Integer 0-0xFF [0] flags=0x0d | ||
| 173 | framerate Integer 0-6 [2] framerate=1 | ||
| 174 | hue_correction Integer 0-255 [128] hue_correction=115 | ||
| 175 | init_brightness Integer 0-255 [128] init_brightness=100 | ||
| 176 | init_contrast Integer 0-255 [192] init_contrast=200 | ||
| 177 | init_color Integer 0-255 [128] init_color=130 | ||
| 178 | init_hue Integer 0-255 [128] init_hue=115 | ||
| 179 | lighting Integer 0-2* [1] lighting=2 | ||
| 180 | sharpness Integer 0-6* [4] sharpness=3 | ||
| 181 | size Integer 0-2* [2] size=1 | ||
| 182 | |||
| 183 | Options for Model 2 only: | ||
| 184 | |||
| 185 | Name Type Range [default] Example | ||
| 186 | -------------- -------------- -------------- ------------------ | ||
| 187 | init_model2_rg Integer 0..255 [0x70] init_model2_rg=128 | ||
| 188 | init_model2_rg2 Integer 0..255 [0x2f] init_model2_rg2=50 | ||
| 189 | init_model2_sat Integer 0..255 [0x34] init_model2_sat=65 | ||
| 190 | init_model2_yb Integer 0..255 [0xa0] init_model2_yb=200 | ||
| 191 | |||
| 192 | debug You don't need this option unless you are a developer. | ||
| 193 | If you are a developer then you will see in the code | ||
| 194 | what values do what. 0=off. | ||
| 195 | |||
| 196 | flags This is a bit mask, and you can combine any number of | ||
| 197 | bits to produce what you want. Usually you don't want | ||
| 198 | any of extra features this option provides: | ||
| 199 | |||
| 200 | FLAGS_RETRY_VIDIOCSYNC 1 This bit allows to retry failed | ||
| 201 | VIDIOCSYNC ioctls without failing. | ||
| 202 | Will work with xawtv, will not | ||
| 203 | with xrealproducer. Default is | ||
| 204 | not set. | ||
| 205 | FLAGS_MONOCHROME 2 Activates monochrome (b/w) mode. | ||
| 206 | FLAGS_DISPLAY_HINTS 4 Shows colored pixels which have | ||
| 207 | magic meaning to developers. | ||
| 208 | FLAGS_OVERLAY_STATS 8 Shows tiny numbers on screen, | ||
| 209 | useful only for debugging. | ||
| 210 | FLAGS_FORCE_TESTPATTERN 16 Shows blue screen with numbers. | ||
| 211 | FLAGS_SEPARATE_FRAMES 32 Shows each frame separately, as | ||
| 212 | it was received from the camera. | ||
| 213 | Default (not set) is to mix the | ||
| 214 | preceding frame in to compensate | ||
| 215 | for occasional loss of Isoc data | ||
| 216 | on high frame rates. | ||
| 217 | FLAGS_CLEAN_FRAMES 64 Forces "cleanup" of each frame | ||
| 218 | prior to use; relevant only if | ||
| 219 | FLAGS_SEPARATE_FRAMES is set. | ||
| 220 | Default is not to clean frames, | ||
| 221 | this is a little faster but may | ||
| 222 | produce flicker if frame rate is | ||
| 223 | too high and Isoc data gets lost. | ||
| 224 | FLAGS_NO_DECODING 128 This flag turns the video stream | ||
| 225 | decoder off, and dumps the raw | ||
| 226 | Isoc data from the camera into | ||
| 227 | the reading process. Useful to | ||
| 228 | developers, but not to users. | ||
| 229 | |||
| 230 | framerate This setting controls frame rate of the camera. This is | ||
| 231 | an approximate setting (in terms of "worst" ... "best") | ||
| 232 | because camera changes frame rate depending on amount | ||
| 233 | of light available. Setting 0 is slowest, 6 is fastest. | ||
| 234 | Beware - fast settings are very demanding and may not | ||
| 235 | work well with all video sizes. Be conservative. | ||
| 236 | |||
| 237 | hue_correction This highly optional setting allows to adjust the | ||
| 238 | hue of the image in a way slightly different from | ||
| 239 | what usual "hue" control does. Both controls affect | ||
| 240 | YUV colorspace: regular "hue" control adjusts only | ||
| 241 | U component, and this "hue_correction" option similarly | ||
| 242 | adjusts only V component. However usually it is enough | ||
| 243 | to tweak only U or V to compensate for colored light or | ||
| 244 | color temperature; this option simply allows more | ||
| 245 | complicated correction when and if it is necessary. | ||
| 246 | |||
| 247 | init_brightness These settings specify _initial_ values which will be | ||
| 248 | init_contrast used to set up the camera. If your V4L application has | ||
| 249 | init_color its own controls to adjust the picture then these | ||
| 250 | init_hue controls will be used too. These options allow you to | ||
| 251 | preconfigure the camera when it gets connected, before | ||
| 252 | any V4L application connects to it. Good for webcams. | ||
| 253 | |||
| 254 | init_model2_rg These initial settings alter color balance of the | ||
| 255 | init_model2_rg2 camera on hardware level. All four settings may be used | ||
| 256 | init_model2_sat to tune the camera to specific lighting conditions. These | ||
| 257 | init_model2_yb settings only apply to Model 2 cameras. | ||
| 258 | |||
| 259 | lighting This option selects one of three hardware-defined | ||
| 260 | photosensitivity settings of the camera. 0=bright light, | ||
| 261 | 1=Medium (default), 2=Low light. This setting affects | ||
| 262 | frame rate: the dimmer the lighting the lower the frame | ||
| 263 | rate (because longer exposition time is needed). The | ||
| 264 | Model 2 cameras allow values more than 2 for this option, | ||
| 265 | thus enabling extremely high sensitivity at cost of frame | ||
| 266 | rate, color saturation and imaging sensor noise. | ||
| 267 | |||
| 268 | sharpness This option controls smoothing (noise reduction) | ||
| 269 | made by camera. Setting 0 is most smooth, setting 6 | ||
| 270 | is most sharp. Be aware that CMOS sensor used in the | ||
| 271 | camera is pretty noisy, so if you choose 6 you will | ||
| 272 | be greeted with "snowy" image. Default is 4. Model 2 | ||
| 273 | cameras do not support this feature. | ||
| 274 | |||
| 275 | size This setting chooses one of several image sizes that are | ||
| 276 | supported by this driver. Cameras may support more, but | ||
| 277 | it's difficult to reverse-engineer all formats. | ||
| 278 | Following video sizes are supported: | ||
| 279 | |||
| 280 | size=0 128x96 (Model 1 only) | ||
| 281 | size=1 160x120 | ||
| 282 | size=2 176x144 | ||
| 283 | size=3 320x240 (Model 2 only) | ||
| 284 | size=4 352x240 (Model 2 only) | ||
| 285 | size=5 352x288 | ||
| 286 | size=6 640x480 (Model 3 only) | ||
| 287 | |||
| 288 | The 352x288 is the native size of the Model 1 sensor | ||
| 289 | array, so it's the best resolution the camera can | ||
| 290 | yield. The best resolution of Model 2 is 176x144, and | ||
| 291 | larger images are produced by stretching the bitmap. | ||
| 292 | Model 3 has sensor with 640x480 grid, and it works too, | ||
| 293 | but the frame rate will be exceptionally low (1-2 FPS); | ||
| 294 | it may be still OK for some applications, like security. | ||
| 295 | Choose the image size you need. The smaller image can | ||
| 296 | support faster frame rate. Default is 352x288. | ||
| 297 | |||
| 298 | For more information and the Troubleshooting FAQ visit this URL: | ||
| 299 | |||
| 300 | http://www.linux-usb.org/ibmcam/ | ||
| 301 | |||
| 302 | WHAT NEEDS TO BE DONE: | ||
| 303 | |||
| 304 | - The button on the camera is not used. I don't know how to get to it. | ||
| 305 | I know now how to read button on Model 2, but what to do with it? | ||
| 306 | |||
| 307 | - Camera reports its status back to the driver; however I don't know | ||
| 308 | what returned data means. If camera fails at some initialization | ||
| 309 | stage then something should be done, and I don't do that because | ||
| 310 | I don't even know that some command failed. This is mostly Model 1 | ||
| 311 | concern because Model 2 uses different commands which do not return | ||
| 312 | status (and seem to complete successfully every time). | ||
| 313 | |||
| 314 | - Some flavors of Model 4 NetCameras produce only compressed video | ||
| 315 | streams, and I don't know how to decode them. | ||
| 316 | |||
| 317 | CREDITS: | ||
| 318 | |||
| 319 | The code is based in no small part on the CPiA driver by Johannes Erdfelt, | ||
| 320 | Randy Dunlap, and others. Big thanks to them for their pioneering work on that | ||
| 321 | and the USB stack. | ||
| 322 | |||
| 323 | I also thank John Lightsey for his donation of the Veo Stingray camera. | ||
diff --git a/Documentation/video4linux/m5602.txt b/Documentation/video4linux/m5602.txt deleted file mode 100644 index 4450ab13f37b..000000000000 --- a/Documentation/video4linux/m5602.txt +++ /dev/null | |||
| @@ -1,12 +0,0 @@ | |||
| 1 | This document describes the ALi m5602 bridge connected | ||
| 2 | to the following supported sensors: | ||
| 3 | OmniVision OV9650, | ||
| 4 | Samsung s5k83a, | ||
| 5 | Samsung s5k4aa, | ||
| 6 | Micron mt9m111, | ||
| 7 | Pixel plus PO1030 | ||
| 8 | |||
| 9 | This driver mimics the windows drivers, which have a braindead implementation sending bayer-encoded frames at VGA resolution. | ||
| 10 | In a perfect world we should be able to reprogram the m5602 and the connected sensor in hardware instead, supporting a range of resolutions and pixelformats | ||
| 11 | |||
| 12 | Anyway, have fun and please report any bugs to m560x-driver-devel@lists.sourceforge.net | ||
diff --git a/Documentation/video4linux/ov511.txt b/Documentation/video4linux/ov511.txt deleted file mode 100644 index b3326b167ada..000000000000 --- a/Documentation/video4linux/ov511.txt +++ /dev/null | |||
| @@ -1,288 +0,0 @@ | |||
| 1 | ------------------------------------------------------------------------------- | ||
| 2 | Readme for Linux device driver for the OmniVision OV511 USB to camera bridge IC | ||
| 3 | ------------------------------------------------------------------------------- | ||
| 4 | |||
| 5 | Author: Mark McClelland | ||
| 6 | Homepage: http://alpha.dyndns.org/ov511 | ||
| 7 | |||
| 8 | INTRODUCTION: | ||
| 9 | |||
| 10 | This is a driver for the OV511, a USB-only chip used in many "webcam" devices. | ||
| 11 | Any camera using the OV511/OV511+ and the OV6620/OV7610/20/20AE should work. | ||
| 12 | Video capture devices that use the Philips SAA7111A decoder also work. It | ||
| 13 | supports streaming and capture of color or monochrome video via the Video4Linux | ||
| 14 | API. Most V4L apps are compatible with it. Most resolutions with a width and | ||
| 15 | height that are a multiple of 8 are supported. | ||
| 16 | |||
| 17 | If you need more information, please visit the OV511 homepage at the above URL. | ||
| 18 | |||
| 19 | WHAT YOU NEED: | ||
| 20 | |||
| 21 | - If you want to help with the development, get the chip's specification docs at | ||
| 22 | http://www.ovt.com/omniusbp.html | ||
| 23 | |||
| 24 | - A Video4Linux compatible frame grabber program (I recommend vidcat and xawtv) | ||
| 25 | vidcat is part of the w3cam package: http://mpx.freeshell.net/ | ||
| 26 | xawtv is available at: http://linux.bytesex.org/xawtv/ | ||
| 27 | |||
| 28 | HOW TO USE IT: | ||
| 29 | |||
| 30 | Note: These are simplified instructions. For complete instructions see: | ||
| 31 | http://alpha.dyndns.org/ov511/install.html | ||
| 32 | |||
| 33 | You must have first compiled USB support, support for your specific USB host | ||
| 34 | controller (UHCI or OHCI), and Video4Linux support for your kernel (I recommend | ||
| 35 | making them modules.) Make sure "Enforce bandwidth allocation" is NOT enabled. | ||
| 36 | |||
| 37 | Next, (as root): | ||
| 38 | |||
| 39 | modprobe usbcore | ||
| 40 | modprobe usb-uhci <OR> modprobe usb-ohci | ||
| 41 | modprobe videodev | ||
| 42 | modprobe ov511 | ||
| 43 | |||
| 44 | If it is not already there (it usually is), create the video device: | ||
| 45 | |||
| 46 | mknod /dev/video0 c 81 0 | ||
| 47 | |||
| 48 | Optionally, symlink /dev/video to /dev/video0 | ||
| 49 | |||
| 50 | You will have to set permissions on this device to allow you to read/write | ||
| 51 | from it: | ||
| 52 | |||
| 53 | chmod 666 /dev/video | ||
| 54 | chmod 666 /dev/video0 (if necessary) | ||
| 55 | |||
| 56 | Now you are ready to run a video app! Both vidcat and xawtv work well for me | ||
| 57 | at 640x480. | ||
| 58 | |||
| 59 | [Using vidcat:] | ||
| 60 | |||
| 61 | vidcat -s 640x480 -p c > test.jpg | ||
| 62 | xview test.jpg | ||
| 63 | |||
| 64 | [Using xawtv:] | ||
| 65 | |||
| 66 | From the main xawtv directory: | ||
| 67 | |||
| 68 | make clean | ||
| 69 | ./configure | ||
| 70 | make | ||
| 71 | make install | ||
| 72 | |||
| 73 | Now you should be able to run xawtv. Right click for the options dialog. | ||
| 74 | |||
| 75 | MODULE PARAMETERS: | ||
| 76 | |||
| 77 | You can set these with: insmod ov511 NAME=VALUE | ||
| 78 | There is currently no way to set these on a per-camera basis. | ||
| 79 | |||
| 80 | NAME: autobright | ||
| 81 | TYPE: integer (Boolean) | ||
| 82 | DEFAULT: 1 | ||
| 83 | DESC: Brightness is normally under automatic control and can't be set | ||
| 84 | manually by the video app. Set to 0 for manual control. | ||
| 85 | |||
| 86 | NAME: autogain | ||
| 87 | TYPE: integer (Boolean) | ||
| 88 | DEFAULT: 1 | ||
| 89 | DESC: Auto Gain Control enable. This feature is not yet implemented. | ||
| 90 | |||
| 91 | NAME: autoexp | ||
| 92 | TYPE: integer (Boolean) | ||
| 93 | DEFAULT: 1 | ||
| 94 | DESC: Auto Exposure Control enable. This feature is not yet implemented. | ||
| 95 | |||
| 96 | NAME: debug | ||
| 97 | TYPE: integer (0-6) | ||
| 98 | DEFAULT: 3 | ||
| 99 | DESC: Sets the threshold for printing debug messages. The higher the value, | ||
| 100 | the more is printed. The levels are cumulative, and are as follows: | ||
| 101 | 0=no debug messages | ||
| 102 | 1=init/detection/unload and other significant messages | ||
| 103 | 2=some warning messages | ||
| 104 | 3=config/control function calls | ||
| 105 | 4=most function calls and data parsing messages | ||
| 106 | 5=highly repetitive mesgs | ||
| 107 | |||
| 108 | NAME: snapshot | ||
| 109 | TYPE: integer (Boolean) | ||
| 110 | DEFAULT: 0 | ||
| 111 | DESC: Set to 1 to enable snapshot mode. read()/VIDIOCSYNC will block until | ||
| 112 | the snapshot button is pressed. Note: enabling this mode disables | ||
| 113 | /proc/video/ov511/<minor#>/button | ||
| 114 | |||
| 115 | NAME: cams | ||
| 116 | TYPE: integer (1-4 for OV511, 1-31 for OV511+) | ||
| 117 | DEFAULT: 1 | ||
| 118 | DESC: Number of cameras allowed to stream simultaneously on a single bus. | ||
| 119 | Values higher than 1 reduce the data rate of each camera, allowing two | ||
| 120 | or more to be used at once. If you have a complicated setup involving | ||
| 121 | both OV511 and OV511+ cameras, trial-and-error may be necessary for | ||
| 122 | finding the optimum setting. | ||
| 123 | |||
| 124 | NAME: compress | ||
| 125 | TYPE: integer (Boolean) | ||
| 126 | DEFAULT: 0 | ||
| 127 | DESC: Set this to 1 to turn on the camera's compression engine. This can | ||
| 128 | potentially increase the frame rate at the expense of quality, if you | ||
| 129 | have a fast CPU. You must load the proper compression module for your | ||
| 130 | camera before starting your application (ov511_decomp or ov518_decomp). | ||
| 131 | |||
| 132 | NAME: testpat | ||
| 133 | TYPE: integer (Boolean) | ||
| 134 | DEFAULT: 0 | ||
| 135 | DESC: This configures the camera's sensor to transmit a colored test-pattern | ||
| 136 | instead of an image. This does not work correctly yet. | ||
| 137 | |||
| 138 | NAME: dumppix | ||
| 139 | TYPE: integer (0-2) | ||
| 140 | DEFAULT: 0 | ||
| 141 | DESC: Dumps raw pixel data and skips post-processing and format conversion. | ||
| 142 | It is for debugging purposes only. Options are: | ||
| 143 | 0: Disable (default) | ||
| 144 | 1: Dump raw data from camera, excluding headers and trailers | ||
| 145 | 2: Dumps data exactly as received from camera | ||
| 146 | |||
| 147 | NAME: led | ||
| 148 | TYPE: integer (0-2) | ||
| 149 | DEFAULT: 1 (Always on) | ||
| 150 | DESC: Controls whether the LED (the little light) on the front of the camera | ||
| 151 | is always off (0), always on (1), or only on when driver is open (2). | ||
| 152 | This is not supported with the OV511, and might only work with certain | ||
| 153 | cameras (ones that actually have the LED wired to the control pin, and | ||
| 154 | not just hard-wired to be on all the time). | ||
| 155 | |||
| 156 | NAME: dump_bridge | ||
| 157 | TYPE: integer (Boolean) | ||
| 158 | DEFAULT: 0 | ||
| 159 | DESC: Dumps the bridge (OV511[+] or OV518[+]) register values to the system | ||
| 160 | log. Only useful for serious debugging/development purposes. | ||
| 161 | |||
| 162 | NAME: dump_sensor | ||
| 163 | TYPE: integer (Boolean) | ||
| 164 | DEFAULT: 0 | ||
| 165 | DESC: Dumps the sensor register values to the system log. Only useful for | ||
| 166 | serious debugging/development purposes. | ||
| 167 | |||
| 168 | NAME: printph | ||
| 169 | TYPE: integer (Boolean) | ||
| 170 | DEFAULT: 0 | ||
| 171 | DESC: Setting this to 1 will dump the first 12 bytes of each isoc frame. This | ||
| 172 | is only useful if you are trying to debug problems with the isoc data | ||
| 173 | stream (i.e.: camera initializes, but vidcat hangs until Ctrl-C). Be | ||
| 174 | warned that this dumps a large number of messages to your kernel log. | ||
| 175 | |||
| 176 | NAME: phy, phuv, pvy, pvuv, qhy, qhuv, qvy, qvuv | ||
| 177 | TYPE: integer (0-63 for phy and phuv, 0-255 for rest) | ||
| 178 | DEFAULT: OV511 default values | ||
| 179 | DESC: These are registers 70h - 77h of the OV511, which control the | ||
| 180 | prediction ranges and quantization thresholds of the compressor, for | ||
| 181 | the Y and UV channels in the horizontal and vertical directions. See | ||
| 182 | the OV511 or OV511+ data sheet for more detailed descriptions. These | ||
| 183 | normally do not need to be changed. | ||
| 184 | |||
| 185 | NAME: lightfreq | ||
| 186 | TYPE: integer (0, 50, or 60) | ||
| 187 | DEFAULT: 0 (use sensor default) | ||
| 188 | DESC: Sets the sensor to match your lighting frequency. This can reduce the | ||
| 189 | appearance of "banding", i.e. horizontal lines or waves of light and | ||
| 190 | dark that are often caused by artificial lighting. Valid values are: | ||
| 191 | 0 - Use default (depends on sensor, most likely 60 Hz) | ||
| 192 | 50 - For European and Asian 50 Hz power | ||
| 193 | 60 - For American 60 Hz power | ||
| 194 | |||
| 195 | NAME: bandingfilter | ||
| 196 | TYPE: integer (Boolean) | ||
| 197 | DEFAULT: 0 (off) | ||
| 198 | DESC: Enables the sensor´s banding filter exposure algorithm. This reduces | ||
| 199 | or stabilizes the "banding" caused by some artificial light sources | ||
| 200 | (especially fluorescent). You might have to set lightfreq correctly for | ||
| 201 | this to work right. As an added bonus, this sometimes makes it | ||
| 202 | possible to capture your monitor´s output. | ||
| 203 | |||
| 204 | NAME: fastset | ||
| 205 | TYPE: integer (Boolean) | ||
| 206 | DEFAULT: 0 (off) | ||
| 207 | DESC: Allows picture settings (brightness, contrast, color, and hue) to take | ||
| 208 | effect immediately, even in the middle of a frame. This reduces the | ||
| 209 | time to change settings, but can ruin frames during the change. Only | ||
| 210 | affects OmniVision sensors. | ||
| 211 | |||
| 212 | NAME: force_palette | ||
| 213 | TYPE: integer (Boolean) | ||
| 214 | DEFAULT: 0 (off) | ||
| 215 | DESC: Forces the palette (color format) to a specific value. If an | ||
| 216 | application requests a different palette, it will be rejected, thereby | ||
| 217 | forcing it to try others until it succeeds. This is useful for forcing | ||
| 218 | greyscale mode with a color camera, for example. Supported modes are: | ||
| 219 | 0 (Allows all the following formats) | ||
| 220 | 1 VIDEO_PALETTE_GREY (Linear greyscale) | ||
| 221 | 10 VIDEO_PALETTE_YUV420 (YUV 4:2:0 Planar) | ||
| 222 | 15 VIDEO_PALETTE_YUV420P (YUV 4:2:0 Planar, same as 10) | ||
| 223 | |||
| 224 | NAME: backlight | ||
| 225 | TYPE: integer (Boolean) | ||
| 226 | DEFAULT: 0 (off) | ||
| 227 | DESC: Setting this flag changes the exposure algorithm for OmniVision sensors | ||
| 228 | such that objects in the camera's view (i.e. your head) can be clearly | ||
| 229 | seen when they are illuminated from behind. It reduces or eliminates | ||
| 230 | the sensor's auto-exposure function, so it should only be used when | ||
| 231 | needed. Additionally, it is only supported with the OV6620 and OV7620. | ||
| 232 | |||
| 233 | NAME: unit_video | ||
| 234 | TYPE: Up to 16 comma-separated integers | ||
| 235 | DEFAULT: 0,0,0... (automatically assign the next available minor(s)) | ||
| 236 | DESC: You can specify up to 16 minor numbers to be assigned to ov511 devices. | ||
| 237 | For example, "unit_video=1,3" will make the driver use /dev/video1 and | ||
| 238 | /dev/video3 for the first two devices it detects. Additional devices | ||
| 239 | will be assigned automatically starting at the first available device | ||
| 240 | node (/dev/video0 in this case). Note that you cannot specify 0 as a | ||
| 241 | minor number. This feature requires kernel version 2.4.5 or higher. | ||
| 242 | |||
| 243 | NAME: remove_zeros | ||
| 244 | TYPE: integer (Boolean) | ||
| 245 | DEFAULT: 0 (do not skip any incoming data) | ||
| 246 | DESC: Setting this to 1 will remove zero-padding from incoming data. This | ||
| 247 | will compensate for the blocks of corruption that can appear when the | ||
| 248 | camera cannot keep up with the speed of the USB bus (eg. at low frame | ||
| 249 | resolutions). This feature is always enabled when compression is on. | ||
| 250 | |||
| 251 | NAME: mirror | ||
| 252 | TYPE: integer (Boolean) | ||
| 253 | DEFAULT: 0 (off) | ||
| 254 | DESC: Setting this to 1 will reverse ("mirror") the image horizontally. This | ||
| 255 | might be necessary if your camera has a custom lens assembly. This has | ||
| 256 | no effect with video capture devices. | ||
| 257 | |||
| 258 | NAME: ov518_color | ||
| 259 | TYPE: integer (Boolean) | ||
| 260 | DEFAULT: 0 (off) | ||
| 261 | DESC: Enable OV518 color support. This is off by default since it doesn't | ||
| 262 | work most of the time. If you want to try it, you must also load | ||
| 263 | ov518_decomp with the "nouv=0" parameter. If you get improper colors or | ||
| 264 | diagonal lines through the image, restart your video app and try again. | ||
| 265 | Repeat as necessary. | ||
| 266 | |||
| 267 | WORKING FEATURES: | ||
| 268 | o Color streaming/capture at most widths and heights that are multiples of 8. | ||
| 269 | o Monochrome (use force_palette=1 to enable) | ||
| 270 | o Setting/getting of saturation, contrast, brightness, and hue (only some of | ||
| 271 | them work the OV7620 and OV7620AE) | ||
| 272 | o /proc status reporting | ||
| 273 | o SAA7111A video capture support at 320x240 and 640x480 | ||
| 274 | o Compression support | ||
| 275 | o SMP compatibility | ||
| 276 | |||
| 277 | HOW TO CONTACT ME: | ||
| 278 | |||
| 279 | You can email me at mark@alpha.dyndns.org . Please prefix the subject line | ||
| 280 | with "OV511: " so that I am certain to notice your message. | ||
| 281 | |||
| 282 | CREDITS: | ||
| 283 | |||
| 284 | The code is based in no small part on the CPiA driver by Johannes Erdfelt, | ||
| 285 | Randy Dunlap, and others. Big thanks to them for their pioneering work on that | ||
| 286 | and the USB stack. Thanks to Bret Wallach for getting camera reg IO, ISOC, and | ||
| 287 | image capture working. Thanks to Orion Sky Lawlor, Kevin Moore, and Claudio | ||
| 288 | Matsuoka for their work as well. | ||
diff --git a/Documentation/video4linux/se401.txt b/Documentation/video4linux/se401.txt deleted file mode 100644 index bd6526ec8dd7..000000000000 --- a/Documentation/video4linux/se401.txt +++ /dev/null | |||
| @@ -1,54 +0,0 @@ | |||
| 1 | Linux driver for SE401 based USB cameras | ||
| 2 | |||
| 3 | Copyright, 2001, Jeroen Vreeken | ||
| 4 | |||
| 5 | |||
| 6 | INTRODUCTION: | ||
| 7 | |||
| 8 | The SE401 chip is the used in low-cost usb webcams. | ||
| 9 | It is produced by Endpoints Inc. (www.endpoints.com). | ||
| 10 | It interfaces directly to a cmos image sensor and USB. The only other major | ||
| 11 | part in a se401 based camera is a dram chip. | ||
| 12 | |||
| 13 | The following cameras are known to work with this driver: | ||
| 14 | |||
| 15 | Aox se401 (non-branded) cameras | ||
| 16 | Philips PVCV665 USB VGA webcam 'Vesta Fun' | ||
| 17 | Kensington VideoCAM PC Camera Model 67014 | ||
| 18 | Kensington VideoCAM PC Camera Model 67015 | ||
| 19 | Kensington VideoCAM PC Camera Model 67016 | ||
| 20 | Kensington VideoCAM PC Camera Model 67017 | ||
| 21 | |||
| 22 | |||
| 23 | WHAT YOU NEED: | ||
| 24 | |||
| 25 | - USB support | ||
| 26 | - VIDEO4LINUX support | ||
| 27 | |||
| 28 | More information about USB support for linux can be found at: | ||
| 29 | http://www.linux-usb.org | ||
| 30 | |||
| 31 | |||
| 32 | MODULE OPTIONS: | ||
| 33 | |||
| 34 | When the driver is compiled as a module you can also use the 'flickerless' | ||
| 35 | option. With it exposure is limited to values that do not interfere with the | ||
| 36 | net frequency. Valid options for this option are 0, 50 and 60. (0=disable, | ||
| 37 | 50=50hz, 60=60hz) | ||
| 38 | |||
| 39 | |||
| 40 | KNOWN PROBLEMS: | ||
| 41 | |||
| 42 | The driver works fine with the usb-ohci and uhci host controller drivers, | ||
| 43 | the default settings also work with usb-uhci. But sending more than one bulk | ||
| 44 | transfer at a time with usb-uhci doesn't work yet. | ||
| 45 | Users of usb-ohci and uhci can safely enlarge SE401_NUMSBUF in se401.h in | ||
| 46 | order to increase the throughput (and thus framerate). | ||
| 47 | |||
| 48 | |||
| 49 | HELP: | ||
| 50 | |||
| 51 | The latest info on this driver can be found at: | ||
| 52 | http://members.chello.nl/~j.vreeken/se401/ | ||
| 53 | And questions to me can be send to: | ||
| 54 | pe1rxq@amsat.org | ||
diff --git a/Documentation/video4linux/si470x.txt b/Documentation/video4linux/si470x.txt index 3a7823e01b4d..98c32925eb39 100644 --- a/Documentation/video4linux/si470x.txt +++ b/Documentation/video4linux/si470x.txt | |||
| @@ -53,6 +53,9 @@ Testing is usually done with most application under Debian/testing: | |||
| 53 | - kradio - Comfortable Radio Application for KDE | 53 | - kradio - Comfortable Radio Application for KDE |
| 54 | - radio - ncurses-based radio application | 54 | - radio - ncurses-based radio application |
| 55 | - mplayer - The Ultimate Movie Player For Linux | 55 | - mplayer - The Ultimate Movie Player For Linux |
| 56 | - v4l2-ctl - Collection of command line video4linux utilities | ||
| 57 | For example, you can use: | ||
| 58 | v4l2-ctl -d /dev/radio0 --set-ctrl=volume=10,mute=0 --set-freq=95.21 --all | ||
| 56 | 59 | ||
| 57 | There is also a library libv4l, which can be used. It's going to have a function | 60 | There is also a library libv4l, which can be used. It's going to have a function |
| 58 | for frequency seeking, either by using hardware functionality as in radio-si470x | 61 | for frequency seeking, either by using hardware functionality as in radio-si470x |
| @@ -75,8 +78,10 @@ commands. Please adjust the audio devices to your needs (/dev/dsp* and hw:x,x). | |||
| 75 | If you just want to test audio (very poor quality): | 78 | If you just want to test audio (very poor quality): |
| 76 | cat /dev/dsp1 > /dev/dsp | 79 | cat /dev/dsp1 > /dev/dsp |
| 77 | 80 | ||
| 78 | If you use OSS try: | 81 | If you use sox + OSS try: |
| 79 | sox -2 --endian little -r 96000 -t oss /dev/dsp1 -t oss /dev/dsp | 82 | sox -2 --endian little -r 96000 -t oss /dev/dsp1 -t oss /dev/dsp |
| 83 | or using sox + alsa: | ||
| 84 | sox --endian little -c 2 -S -r 96000 -t alsa hw:1 -t alsa -r 96000 hw:0 | ||
| 80 | 85 | ||
| 81 | If you use arts try: | 86 | If you use arts try: |
| 82 | arecord -D hw:1,0 -r96000 -c2 -f S16_LE | artsdsp aplay -B - | 87 | arecord -D hw:1,0 -r96000 -c2 -f S16_LE | artsdsp aplay -B - |
diff --git a/Documentation/video4linux/soc-camera.txt b/Documentation/video4linux/soc-camera.txt index 3f87c7da4ca2..f62fcdbc8b9f 100644 --- a/Documentation/video4linux/soc-camera.txt +++ b/Documentation/video4linux/soc-camera.txt | |||
| @@ -9,32 +9,36 @@ The following terms are used in this document: | |||
| 9 | of connecting to a variety of systems and interfaces, typically uses i2c for | 9 | of connecting to a variety of systems and interfaces, typically uses i2c for |
| 10 | control and configuration, and a parallel or a serial bus for data. | 10 | control and configuration, and a parallel or a serial bus for data. |
| 11 | - camera host - an interface, to which a camera is connected. Typically a | 11 | - camera host - an interface, to which a camera is connected. Typically a |
| 12 | specialised interface, present on many SoCs, e.g., PXA27x and PXA3xx, SuperH, | 12 | specialised interface, present on many SoCs, e.g. PXA27x and PXA3xx, SuperH, |
| 13 | AVR32, i.MX27, i.MX31. | 13 | AVR32, i.MX27, i.MX31. |
| 14 | - camera host bus - a connection between a camera host and a camera. Can be | 14 | - camera host bus - a connection between a camera host and a camera. Can be |
| 15 | parallel or serial, consists of data and control lines, e.g., clock, vertical | 15 | parallel or serial, consists of data and control lines, e.g. clock, vertical |
| 16 | and horizontal synchronization signals. | 16 | and horizontal synchronization signals. |
| 17 | 17 | ||
| 18 | Purpose of the soc-camera subsystem | 18 | Purpose of the soc-camera subsystem |
| 19 | ----------------------------------- | 19 | ----------------------------------- |
| 20 | 20 | ||
| 21 | The soc-camera subsystem provides a unified API between camera host drivers and | 21 | The soc-camera subsystem initially provided a unified API between camera host |
| 22 | camera sensor drivers. It implements a V4L2 interface to the user, currently | 22 | drivers and camera sensor drivers. Later the soc-camera sensor API has been |
| 23 | only the mmap method is supported. | 23 | replaced with the V4L2 standard subdev API. This also made camera driver re-use |
| 24 | with non-soc-camera hosts possible. The camera host API to the soc-camera core | ||
| 25 | has been preserved. | ||
| 24 | 26 | ||
| 25 | This subsystem has been written to connect drivers for System-on-Chip (SoC) | 27 | Soc-camera implements a V4L2 interface to the user, currently only the "mmap" |
| 26 | video capture interfaces with drivers for CMOS camera sensor chips to enable | 28 | method is supported by host drivers. However, the soc-camera core also provides |
| 27 | the reuse of sensor drivers with various hosts. The subsystem has been designed | 29 | support for the "read" method. |
| 28 | to support multiple camera host interfaces and multiple cameras per interface, | 30 | |
| 29 | although most applications have only one camera sensor. | 31 | The subsystem has been designed to support multiple camera host interfaces and |
| 32 | multiple cameras per interface, although most applications have only one camera | ||
| 33 | sensor. | ||
| 30 | 34 | ||
| 31 | Existing drivers | 35 | Existing drivers |
| 32 | ---------------- | 36 | ---------------- |
| 33 | 37 | ||
| 34 | As of 2.6.27-rc4 there are two host drivers in the mainline: pxa_camera.c for | 38 | As of 3.7 there are seven host drivers in the mainline: atmel-isi.c, |
| 35 | PXA27x SoCs and sh_mobile_ceu_camera.c for SuperH SoCs, and four sensor drivers: | 39 | mx1_camera.c (broken, scheduled for removal), mx2_camera.c, mx3_camera.c, |
| 36 | mt9m001.c, mt9m111.c, mt9v022.c and a generic soc_camera_platform.c driver. This | 40 | omap1_camera.c, pxa_camera.c, sh_mobile_ceu_camera.c, and multiple sensor |
| 37 | list is not supposed to be updated, look for more examples in your tree. | 41 | drivers under drivers/media/i2c/soc_camera/. |
| 38 | 42 | ||
| 39 | Camera host API | 43 | Camera host API |
| 40 | --------------- | 44 | --------------- |
| @@ -45,38 +49,37 @@ soc_camera_host_register(struct soc_camera_host *); | |||
| 45 | 49 | ||
| 46 | function. The host object can be initialized as follows: | 50 | function. The host object can be initialized as follows: |
| 47 | 51 | ||
| 48 | static struct soc_camera_host pxa_soc_camera_host = { | 52 | struct soc_camera_host *ici; |
| 49 | .drv_name = PXA_CAM_DRV_NAME, | 53 | ici->drv_name = DRV_NAME; |
| 50 | .ops = &pxa_soc_camera_host_ops, | 54 | ici->ops = &camera_host_ops; |
| 51 | }; | 55 | ici->priv = pcdev; |
| 56 | ici->v4l2_dev.dev = &pdev->dev; | ||
| 57 | ici->nr = pdev->id; | ||
| 52 | 58 | ||
| 53 | All camera host methods are passed in a struct soc_camera_host_ops: | 59 | All camera host methods are passed in a struct soc_camera_host_ops: |
| 54 | 60 | ||
| 55 | static struct soc_camera_host_ops pxa_soc_camera_host_ops = { | 61 | static struct soc_camera_host_ops camera_host_ops = { |
| 56 | .owner = THIS_MODULE, | 62 | .owner = THIS_MODULE, |
| 57 | .add = pxa_camera_add_device, | 63 | .add = camera_add_device, |
| 58 | .remove = pxa_camera_remove_device, | 64 | .remove = camera_remove_device, |
| 59 | .suspend = pxa_camera_suspend, | 65 | .set_fmt = camera_set_fmt_cap, |
| 60 | .resume = pxa_camera_resume, | 66 | .try_fmt = camera_try_fmt_cap, |
| 61 | .set_fmt_cap = pxa_camera_set_fmt_cap, | 67 | .init_videobuf2 = camera_init_videobuf2, |
| 62 | .try_fmt_cap = pxa_camera_try_fmt_cap, | 68 | .poll = camera_poll, |
| 63 | .init_videobuf = pxa_camera_init_videobuf, | 69 | .querycap = camera_querycap, |
| 64 | .reqbufs = pxa_camera_reqbufs, | 70 | .set_bus_param = camera_set_bus_param, |
| 65 | .poll = pxa_camera_poll, | 71 | /* The rest of host operations are optional */ |
| 66 | .querycap = pxa_camera_querycap, | ||
| 67 | .try_bus_param = pxa_camera_try_bus_param, | ||
| 68 | .set_bus_param = pxa_camera_set_bus_param, | ||
| 69 | }; | 72 | }; |
| 70 | 73 | ||
| 71 | .add and .remove methods are called when a sensor is attached to or detached | 74 | .add and .remove methods are called when a sensor is attached to or detached |
| 72 | from the host, apart from performing host-internal tasks they shall also call | 75 | from the host. .set_bus_param is used to configure physical connection |
| 73 | sensor driver's .init and .release methods respectively. .suspend and .resume | 76 | parameters between the host and the sensor. .init_videobuf2 is called by |
| 74 | methods implement host's power-management functionality and its their | 77 | soc-camera core when a video-device is opened, the host driver would typically |
| 75 | responsibility to call respective sensor's methods. .try_bus_param and | 78 | call vb2_queue_init() in this method. Further video-buffer management is |
| 76 | .set_bus_param are used to negotiate physical connection parameters between the | 79 | implemented completely by the specific camera host driver. If the host driver |
| 77 | host and the sensor. .init_videobuf is called by soc-camera core when a | 80 | supports non-standard pixel format conversion, it should implement a |
| 78 | video-device is opened, further video-buffer management is implemented completely | 81 | .get_formats and, possibly, a .put_formats operations. See below for more |
| 79 | by the specific camera host driver. The rest of the methods are called from | 82 | details about format conversion. The rest of the methods are called from |
| 80 | respective V4L2 operations. | 83 | respective V4L2 operations. |
| 81 | 84 | ||
| 82 | Camera API | 85 | Camera API |
| @@ -84,37 +87,21 @@ Camera API | |||
| 84 | 87 | ||
| 85 | Sensor drivers can use struct soc_camera_link, typically provided by the | 88 | Sensor drivers can use struct soc_camera_link, typically provided by the |
| 86 | platform, and used to specify to which camera host bus the sensor is connected, | 89 | platform, and used to specify to which camera host bus the sensor is connected, |
| 87 | and arbitrarily provide platform .power and .reset methods for the camera. | 90 | and optionally provide platform .power and .reset methods for the camera. This |
| 88 | soc_camera_device_register() and soc_camera_device_unregister() functions are | 91 | struct is provided to the camera driver via the I2C client device platform data |
| 89 | used to add a sensor driver to or remove one from the system. The registration | 92 | and can be obtained, using the soc_camera_i2c_to_link() macro. Care should be |
| 90 | function takes a pointer to struct soc_camera_device as the only parameter. | 93 | taken, when using soc_camera_vdev_to_subdev() and when accessing struct |
| 91 | This struct can be initialized as follows: | 94 | soc_camera_device, using v4l2_get_subdev_hostdata(): both only work, when |
| 92 | 95 | running on an soc-camera host. The actual camera driver operation is implemented | |
| 93 | /* link to driver operations */ | 96 | using the V4L2 subdev API. Additionally soc-camera camera drivers can use |
| 94 | icd->ops = &mt9m001_ops; | 97 | auxiliary soc-camera helper functions like soc_camera_power_on() and |
| 95 | /* link to the underlying physical (e.g., i2c) device */ | 98 | soc_camera_power_off(), which switch regulators, provided by the platform and call |
| 96 | icd->control = &client->dev; | 99 | board-specific power switching methods. soc_camera_apply_board_flags() takes |
| 97 | /* window geometry */ | 100 | camera bus configuration capability flags and applies any board transformations, |
| 98 | icd->x_min = 20; | 101 | e.g. signal polarity inversion. soc_mbus_get_fmtdesc() can be used to obtain a |
| 99 | icd->y_min = 12; | 102 | pixel format descriptor, corresponding to a certain media-bus pixel format code. |
| 100 | icd->x_current = 20; | 103 | soc_camera_limit_side() can be used to restrict beginning and length of a frame |
| 101 | icd->y_current = 12; | 104 | side, based on camera capabilities. |
| 102 | icd->width_min = 48; | ||
| 103 | icd->width_max = 1280; | ||
| 104 | icd->height_min = 32; | ||
| 105 | icd->height_max = 1024; | ||
| 106 | icd->y_skip_top = 1; | ||
| 107 | /* camera bus ID, typically obtained from platform data */ | ||
| 108 | icd->iface = icl->bus_id; | ||
| 109 | |||
| 110 | struct soc_camera_ops provides .probe and .remove methods, which are called by | ||
| 111 | the soc-camera core, when a camera is matched against or removed from a camera | ||
| 112 | host bus, .init, .release, .suspend, and .resume are called from the camera host | ||
| 113 | driver as discussed above. Other members of this struct provide respective V4L2 | ||
| 114 | functionality. | ||
| 115 | |||
| 116 | struct soc_camera_device also links to an array of struct soc_camera_data_format, | ||
| 117 | listing pixel formats, supported by the camera. | ||
| 118 | 105 | ||
| 119 | VIDIOC_S_CROP and VIDIOC_S_FMT behaviour | 106 | VIDIOC_S_CROP and VIDIOC_S_FMT behaviour |
| 120 | ---------------------------------------- | 107 | ---------------------------------------- |
| @@ -153,8 +140,25 @@ implemented. | |||
| 153 | User window geometry is kept in .user_width and .user_height fields in struct | 140 | User window geometry is kept in .user_width and .user_height fields in struct |
| 154 | soc_camera_device and used by the soc-camera core and host drivers. The core | 141 | soc_camera_device and used by the soc-camera core and host drivers. The core |
| 155 | updates these fields upon successful completion of a .s_fmt() call, but if these | 142 | updates these fields upon successful completion of a .s_fmt() call, but if these |
| 156 | fields change elsewhere, e.g., during .s_crop() processing, the host driver is | 143 | fields change elsewhere, e.g. during .s_crop() processing, the host driver is |
| 157 | responsible for updating them. | 144 | responsible for updating them. |
| 158 | 145 | ||
| 146 | Format conversion | ||
| 147 | ----------------- | ||
| 148 | |||
| 149 | V4L2 distinguishes between pixel formats, as they are stored in memory, and as | ||
| 150 | they are transferred over a media bus. Soc-camera provides support to | ||
| 151 | conveniently manage these formats. A table of standard transformations is | ||
| 152 | maintained by soc-camera core, which describes, what FOURCC pixel format will | ||
| 153 | be obtained, if a media-bus pixel format is stored in memory according to | ||
| 154 | certain rules. E.g. if V4L2_MBUS_FMT_YUYV8_2X8 data is sampled with 8 bits per | ||
| 155 | sample and stored in memory in the little-endian order with no gaps between | ||
| 156 | bytes, data in memory will represent the V4L2_PIX_FMT_YUYV FOURCC format. These | ||
| 157 | standard transformations will be used by soc-camera or by camera host drivers to | ||
| 158 | configure camera drivers to produce the FOURCC format, requested by the user, | ||
| 159 | using the VIDIOC_S_FMT ioctl(). Apart from those standard format conversions, | ||
| 160 | host drivers can also provide their own conversion rules by implementing a | ||
| 161 | .get_formats and, if required, a .put_formats methods. | ||
| 162 | |||
| 159 | -- | 163 | -- |
| 160 | Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de> | 164 | Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de> |
diff --git a/Documentation/video4linux/stv680.txt b/Documentation/video4linux/stv680.txt deleted file mode 100644 index e3de33645308..000000000000 --- a/Documentation/video4linux/stv680.txt +++ /dev/null | |||
| @@ -1,53 +0,0 @@ | |||
| 1 | Linux driver for STV0680 based USB cameras | ||
| 2 | |||
| 3 | Copyright, 2001, Kevin Sisson | ||
| 4 | |||
| 5 | |||
| 6 | INTRODUCTION: | ||
| 7 | |||
| 8 | STMicroelectronics produces the STV0680B chip, which comes in two | ||
| 9 | types, -001 and -003. The -003 version allows the recording and downloading | ||
| 10 | of sound clips from the camera, and allows a flash attachment. Otherwise, | ||
| 11 | it uses the same commands as the -001 version. Both versions support a | ||
| 12 | variety of SDRAM sizes and sensors, allowing for a maximum of 26 VGA or 20 | ||
| 13 | CIF pictures. The STV0680 supports either a serial or a usb interface, and | ||
| 14 | video is possible through the usb interface. | ||
| 15 | |||
| 16 | The following cameras are known to work with this driver, although any | ||
| 17 | camera with Vendor/Product codes of 0553/0202 should work: | ||
| 18 | |||
| 19 | Aiptek Pencam (various models) | ||
| 20 | Nisis QuickPix 2 | ||
| 21 | Radio Shack 'Kid's digital camera' (#60-1207) | ||
| 22 | At least one Trust Spycam model | ||
| 23 | Several other European brand models | ||
| 24 | |||
| 25 | WHAT YOU NEED: | ||
| 26 | |||
| 27 | - USB support | ||
| 28 | - VIDEO4LINUX support | ||
| 29 | |||
| 30 | More information about USB support for linux can be found at: | ||
| 31 | http://www.linux-usb.org | ||
| 32 | |||
| 33 | |||
| 34 | MODULE OPTIONS: | ||
| 35 | |||
| 36 | When the driver is compiled as a module, you can set a "swapRGB=1" | ||
| 37 | option, if necessary, for those applications that require it | ||
| 38 | (such as xawtv). However, the driver should detect and set this | ||
| 39 | automatically, so this option should not normally be used. | ||
| 40 | |||
| 41 | |||
| 42 | KNOWN PROBLEMS: | ||
| 43 | |||
| 44 | The driver seems to work better with the usb-ohci than the usb-uhci host | ||
| 45 | controller driver. | ||
| 46 | |||
| 47 | HELP: | ||
| 48 | |||
| 49 | The latest info on this driver can be found at: | ||
| 50 | http://personal.clt.bellsouth.net/~kjsisson or at | ||
| 51 | http://stv0680-usb.sourceforge.net | ||
| 52 | |||
| 53 | Any questions to me can be send to: kjsisson@bellsouth.net | ||
diff --git a/Documentation/video4linux/v4l2-controls.txt b/Documentation/video4linux/v4l2-controls.txt index cfe52c798d74..676f87366025 100644 --- a/Documentation/video4linux/v4l2-controls.txt +++ b/Documentation/video4linux/v4l2-controls.txt | |||
| @@ -715,14 +715,20 @@ a control of this type whenever the first control belonging to a new control | |||
| 715 | class is added. | 715 | class is added. |
| 716 | 716 | ||
| 717 | 717 | ||
| 718 | Proposals for Extensions | 718 | Adding Notify Callbacks |
| 719 | ======================== | 719 | ======================= |
| 720 | |||
| 721 | Sometimes the platform or bridge driver needs to be notified when a control | ||
| 722 | from a sub-device driver changes. You can set a notify callback by calling | ||
| 723 | this function: | ||
| 720 | 724 | ||
| 721 | Some ideas for future extensions to the spec: | 725 | void v4l2_ctrl_notify(struct v4l2_ctrl *ctrl, |
| 726 | void (*notify)(struct v4l2_ctrl *ctrl, void *priv), void *priv); | ||
| 722 | 727 | ||
| 723 | 1) Add a V4L2_CTRL_FLAG_HEX to have values shown as hexadecimal instead of | 728 | Whenever the give control changes value the notify callback will be called |
| 724 | decimal. Useful for e.g. video_mute_yuv. | 729 | with a pointer to the control and the priv pointer that was passed with |
| 730 | v4l2_ctrl_notify. Note that the control's handler lock is held when the | ||
| 731 | notify function is called. | ||
| 725 | 732 | ||
| 726 | 2) It is possible to mark in the controls array which controls have been | 733 | There can be only one notify function per control handler. Any attempt |
| 727 | successfully written and which failed by for example adding a bit to the | 734 | to set another notify function will cause a WARN_ON. |
| 728 | control ID. Not sure if it is worth the effort, though. | ||
diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index b89567ad04b7..a300b283a1a0 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt | |||
| @@ -68,8 +68,7 @@ Structure of the framework | |||
| 68 | The framework closely resembles the driver structure: it has a v4l2_device | 68 | The framework closely resembles the driver structure: it has a v4l2_device |
| 69 | struct for the device instance data, a v4l2_subdev struct to refer to | 69 | struct for the device instance data, a v4l2_subdev struct to refer to |
| 70 | sub-device instances, the video_device struct stores V4L2 device node data | 70 | 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 the v4l2_fh struct keeps track of filehandle instances. |
| 72 | (this is not yet implemented). | ||
| 73 | 72 | ||
| 74 | The V4L2 framework also optionally integrates with the media framework. If a | 73 | 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 | 74 | driver sets the struct v4l2_device mdev field, sub-devices and video nodes |
diff --git a/Documentation/video4linux/w9968cf.txt b/Documentation/video4linux/w9968cf.txt deleted file mode 100644 index 9649450f3b90..000000000000 --- a/Documentation/video4linux/w9968cf.txt +++ /dev/null | |||
| @@ -1,458 +0,0 @@ | |||
| 1 | |||
| 2 | W996[87]CF JPEG USB Dual Mode Camera Chip | ||
| 3 | Driver for Linux 2.6 (basic version) | ||
| 4 | ========================================= | ||
| 5 | |||
| 6 | - Documentation - | ||
| 7 | |||
| 8 | |||
| 9 | Index | ||
| 10 | ===== | ||
| 11 | 1. Copyright | ||
| 12 | 2. Disclaimer | ||
| 13 | 3. License | ||
| 14 | 4. Overview | ||
| 15 | 5. Supported devices | ||
| 16 | 6. Module dependencies | ||
| 17 | 7. Module loading | ||
| 18 | 8. Module parameters | ||
| 19 | 9. Contact information | ||
| 20 | 10. Credits | ||
| 21 | |||
| 22 | |||
| 23 | 1. Copyright | ||
| 24 | ============ | ||
| 25 | Copyright (C) 2002-2004 by Luca Risolia <luca.risolia@studio.unibo.it> | ||
| 26 | |||
| 27 | |||
| 28 | 2. Disclaimer | ||
| 29 | ============= | ||
| 30 | Winbond is a trademark of Winbond Electronics Corporation. | ||
| 31 | This software is not sponsored or developed by Winbond. | ||
| 32 | |||
| 33 | |||
| 34 | 3. License | ||
| 35 | ========== | ||
| 36 | This program is free software; you can redistribute it and/or modify | ||
| 37 | it under the terms of the GNU General Public License as published by | ||
| 38 | the Free Software Foundation; either version 2 of the License, or | ||
| 39 | (at your option) any later version. | ||
| 40 | |||
| 41 | This program is distributed in the hope that it will be useful, | ||
| 42 | but WITHOUT ANY WARRANTY; without even the implied warranty of | ||
| 43 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | ||
| 44 | GNU General Public License for more details. | ||
| 45 | |||
| 46 | You should have received a copy of the GNU General Public License | ||
| 47 | along with this program; if not, write to the Free Software | ||
| 48 | Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. | ||
| 49 | |||
| 50 | |||
| 51 | 4. Overview | ||
| 52 | =========== | ||
| 53 | This driver supports the video streaming capabilities of the devices mounting | ||
| 54 | Winbond W9967CF and Winbond W9968CF JPEG USB Dual Mode Camera Chips. OV681 | ||
| 55 | based cameras should be supported as well. | ||
| 56 | |||
| 57 | The driver is divided into two modules: the basic one, "w9968cf", is needed for | ||
| 58 | the supported devices to work; the second one, "w9968cf-vpp", is an optional | ||
| 59 | module, which provides some useful video post-processing functions like video | ||
| 60 | decoding, up-scaling and colour conversions. | ||
| 61 | |||
| 62 | Note that the official kernels do neither include nor support the second | ||
| 63 | module for performance purposes. Therefore, it is always recommended to | ||
| 64 | download and install the latest and complete release of the driver, | ||
| 65 | replacing the existing one, if present. | ||
| 66 | |||
| 67 | The latest and full-featured version of the W996[87]CF driver can be found at: | ||
| 68 | http://www.linux-projects.org. Please refer to the documentation included in | ||
| 69 | that package, if you are going to use it. | ||
| 70 | |||
| 71 | Up to 32 cameras can be handled at the same time. They can be connected and | ||
| 72 | disconnected from the host many times without turning off the computer, if | ||
| 73 | your system supports the hotplug facility. | ||
| 74 | |||
| 75 | To change the default settings for each camera, many parameters can be passed | ||
| 76 | through command line when the module is loaded into memory. | ||
| 77 | |||
| 78 | The driver relies on the Video4Linux, USB and I2C core modules. It has been | ||
| 79 | designed to run properly on SMP systems as well. An additional module, | ||
| 80 | "ovcamchip", is mandatory; it provides support for some OmniVision image | ||
| 81 | sensors connected to the W996[87]CF chips; if found in the system, the module | ||
| 82 | will be automatically loaded by default (provided that the kernel has been | ||
| 83 | compiled with the automatic module loading option). | ||
| 84 | |||
| 85 | |||
| 86 | 5. Supported devices | ||
| 87 | ==================== | ||
| 88 | At the moment, known W996[87]CF and OV681 based devices are: | ||
| 89 | - Aroma Digi Pen VGA Dual Mode ADG-5000 (unknown image sensor) | ||
| 90 | - AVerMedia AVerTV USB (SAA7111A, Philips FI1216Mk2 tuner, PT2313L audio chip) | ||
| 91 | - Creative Labs Video Blaster WebCam Go (OmniVision OV7610 sensor) | ||
| 92 | - Creative Labs Video Blaster WebCam Go Plus (OmniVision OV7620 sensor) | ||
| 93 | - Lebon LDC-035A (unknown image sensor) | ||
| 94 | - Ezonics EZ-802 EZMega Cam (OmniVision OV8610C sensor) | ||
| 95 | - OmniVision OV8610-EDE (OmniVision OV8610 sensor) | ||
| 96 | - OPCOM Digi Pen VGA Dual Mode Pen Camera (unknown image sensor) | ||
| 97 | - Pretec Digi Pen-II (OmniVision OV7620 sensor) | ||
| 98 | - Pretec DigiPen-480 (OmniVision OV8610 sensor) | ||
| 99 | |||
| 100 | If you know any other W996[87]CF or OV681 based cameras, please contact me. | ||
| 101 | |||
| 102 | The list above does not imply that all those devices work with this driver: up | ||
| 103 | until now only webcams that have an image sensor supported by the "ovcamchip" | ||
| 104 | module work. Kernel messages will always tell you whether this is case. | ||
| 105 | |||
| 106 | Possible external microcontrollers of those webcams are not supported: this | ||
| 107 | means that still images cannot be downloaded from the device memory. | ||
| 108 | |||
| 109 | Furthermore, it's worth to note that I was only able to run tests on my | ||
| 110 | "Creative Labs Video Blaster WebCam Go". Donations of other models, for | ||
| 111 | additional testing and full support, would be much appreciated. | ||
| 112 | |||
| 113 | |||
| 114 | 6. Module dependencies | ||
| 115 | ====================== | ||
| 116 | For it to work properly, the driver needs kernel support for Video4Linux, USB | ||
| 117 | and I2C, and the "ovcamchip" module for the image sensor. Make sure you are not | ||
| 118 | actually using any external "ovcamchip" module, given that the W996[87]CF | ||
| 119 | driver depends on the version of the module present in the official kernels. | ||
| 120 | |||
| 121 | The following options of the kernel configuration file must be enabled and | ||
| 122 | corresponding modules must be compiled: | ||
| 123 | |||
| 124 | # Multimedia devices | ||
| 125 | # | ||
| 126 | CONFIG_VIDEO_DEV=m | ||
| 127 | |||
| 128 | # I2C support | ||
| 129 | # | ||
| 130 | CONFIG_I2C=m | ||
| 131 | |||
| 132 | The I2C core module can be compiled statically in the kernel as well. | ||
| 133 | |||
| 134 | # OmniVision Camera Chip support | ||
| 135 | # | ||
| 136 | CONFIG_VIDEO_OVCAMCHIP=m | ||
| 137 | |||
| 138 | # USB support | ||
| 139 | # | ||
| 140 | CONFIG_USB=m | ||
| 141 | |||
| 142 | In addition, depending on the hardware being used, only one of the modules | ||
| 143 | below is necessary: | ||
| 144 | |||
| 145 | # USB Host Controller Drivers | ||
| 146 | # | ||
| 147 | CONFIG_USB_EHCI_HCD=m | ||
| 148 | CONFIG_USB_UHCI_HCD=m | ||
| 149 | CONFIG_USB_OHCI_HCD=m | ||
| 150 | |||
| 151 | And finally: | ||
| 152 | |||
| 153 | # USB Multimedia devices | ||
| 154 | # | ||
| 155 | CONFIG_USB_W9968CF=m | ||
| 156 | |||
| 157 | |||
| 158 | 7. Module loading | ||
| 159 | ================= | ||
| 160 | To use the driver, it is necessary to load the "w9968cf" module into memory | ||
| 161 | after every other module required. | ||
| 162 | |||
| 163 | Loading can be done this way, from root: | ||
| 164 | |||
| 165 | [root@localhost home]# modprobe usbcore | ||
| 166 | [root@localhost home]# modprobe i2c-core | ||
| 167 | [root@localhost home]# modprobe videodev | ||
| 168 | [root@localhost home]# modprobe w9968cf | ||
| 169 | |||
| 170 | At this point the pertinent devices should be recognized: "dmesg" can be used | ||
| 171 | to analyze kernel messages: | ||
| 172 | |||
| 173 | [user@localhost home]$ dmesg | ||
| 174 | |||
| 175 | There are a lot of parameters the module can use to change the default | ||
| 176 | settings for each device. To list every possible parameter with a brief | ||
| 177 | explanation about them and which syntax to use, it is recommended to run the | ||
| 178 | "modinfo" command: | ||
| 179 | |||
| 180 | [root@locahost home]# modinfo w9968cf | ||
| 181 | |||
| 182 | |||
| 183 | 8. Module parameters | ||
| 184 | ==================== | ||
| 185 | Module parameters are listed below: | ||
| 186 | ------------------------------------------------------------------------------- | ||
| 187 | Name: ovmod_load | ||
| 188 | Type: bool | ||
| 189 | Syntax: <0|1> | ||
| 190 | Description: Automatic 'ovcamchip' module loading: 0 disabled, 1 enabled. | ||
| 191 | If enabled, 'insmod' searches for the required 'ovcamchip' | ||
| 192 | module in the system, according to its configuration, and | ||
| 193 | loads that module automatically. This action is performed as | ||
| 194 | once soon as the 'w9968cf' module is loaded into memory. | ||
| 195 | Default: 1 | ||
| 196 | ------------------------------------------------------------------------------- | ||
| 197 | Name: simcams | ||
| 198 | Type: int | ||
| 199 | Syntax: <n> | ||
| 200 | Description: Number of cameras allowed to stream simultaneously. | ||
| 201 | n may vary from 0 to 32. | ||
| 202 | Default: 32 | ||
| 203 | ------------------------------------------------------------------------------- | ||
| 204 | Name: video_nr | ||
| 205 | Type: int array (min = 0, max = 32) | ||
| 206 | Syntax: <-1|n[,...]> | ||
| 207 | Description: Specify V4L minor mode number. | ||
| 208 | -1 = use next available | ||
| 209 | n = use minor number n | ||
| 210 | You can specify up to 32 cameras this way. | ||
| 211 | For example: | ||
| 212 | video_nr=-1,2,-1 would assign minor number 2 to the second | ||
| 213 | recognized camera and use auto for the first one and for every | ||
| 214 | other camera. | ||
| 215 | Default: -1 | ||
| 216 | ------------------------------------------------------------------------------- | ||
| 217 | Name: packet_size | ||
| 218 | Type: int array (min = 0, max = 32) | ||
| 219 | Syntax: <n[,...]> | ||
| 220 | Description: Specify the maximum data payload size in bytes for alternate | ||
| 221 | settings, for each device. n is scaled between 63 and 1023. | ||
| 222 | Default: 1023 | ||
| 223 | ------------------------------------------------------------------------------- | ||
| 224 | Name: max_buffers | ||
| 225 | Type: int array (min = 0, max = 32) | ||
| 226 | Syntax: <n[,...]> | ||
| 227 | Description: For advanced users. | ||
| 228 | Specify the maximum number of video frame buffers to allocate | ||
| 229 | for each device, from 2 to 32. | ||
| 230 | Default: 2 | ||
| 231 | ------------------------------------------------------------------------------- | ||
| 232 | Name: double_buffer | ||
| 233 | Type: bool array (min = 0, max = 32) | ||
| 234 | Syntax: <0|1[,...]> | ||
| 235 | Description: Hardware double buffering: 0 disabled, 1 enabled. | ||
| 236 | It should be enabled if you want smooth video output: if you | ||
| 237 | obtain out of sync. video, disable it, or try to | ||
| 238 | decrease the 'clockdiv' module parameter value. | ||
| 239 | Default: 1 for every device. | ||
| 240 | ------------------------------------------------------------------------------- | ||
| 241 | Name: clamping | ||
| 242 | Type: bool array (min = 0, max = 32) | ||
| 243 | Syntax: <0|1[,...]> | ||
| 244 | Description: Video data clamping: 0 disabled, 1 enabled. | ||
| 245 | Default: 0 for every device. | ||
| 246 | ------------------------------------------------------------------------------- | ||
| 247 | Name: filter_type | ||
| 248 | Type: int array (min = 0, max = 32) | ||
| 249 | Syntax: <0|1|2[,...]> | ||
| 250 | Description: Video filter type. | ||
| 251 | 0 none, 1 (1-2-1) 3-tap filter, 2 (2-3-6-3-2) 5-tap filter. | ||
| 252 | The filter is used to reduce noise and aliasing artifacts | ||
| 253 | produced by the CCD or CMOS image sensor. | ||
| 254 | Default: 0 for every device. | ||
| 255 | ------------------------------------------------------------------------------- | ||
| 256 | Name: largeview | ||
| 257 | Type: bool array (min = 0, max = 32) | ||
| 258 | Syntax: <0|1[,...]> | ||
| 259 | Description: Large view: 0 disabled, 1 enabled. | ||
| 260 | Default: 1 for every device. | ||
| 261 | ------------------------------------------------------------------------------- | ||
| 262 | Name: upscaling | ||
| 263 | Type: bool array (min = 0, max = 32) | ||
| 264 | Syntax: <0|1[,...]> | ||
| 265 | Description: Software scaling (for non-compressed video only): | ||
| 266 | 0 disabled, 1 enabled. | ||
| 267 | Disable it if you have a slow CPU or you don't have enough | ||
| 268 | memory. | ||
| 269 | Default: 0 for every device. | ||
| 270 | Note: If 'w9968cf-vpp' is not present, this parameter is set to 0. | ||
| 271 | ------------------------------------------------------------------------------- | ||
| 272 | Name: decompression | ||
| 273 | Type: int array (min = 0, max = 32) | ||
| 274 | Syntax: <0|1|2[,...]> | ||
| 275 | Description: Software video decompression: | ||
| 276 | 0 = disables decompression | ||
| 277 | (doesn't allow formats needing decompression). | ||
| 278 | 1 = forces decompression | ||
| 279 | (allows formats needing decompression only). | ||
| 280 | 2 = allows any permitted formats. | ||
| 281 | Formats supporting (de)compressed video are YUV422P and | ||
| 282 | YUV420P/YUV420 in any resolutions where width and height are | ||
| 283 | multiples of 16. | ||
| 284 | Default: 2 for every device. | ||
| 285 | Note: If 'w9968cf-vpp' is not present, forcing decompression is not | ||
| 286 | allowed; in this case this parameter is set to 2. | ||
| 287 | ------------------------------------------------------------------------------- | ||
| 288 | Name: force_palette | ||
| 289 | Type: int array (min = 0, max = 32) | ||
| 290 | Syntax: <0|9|10|13|15|8|7|1|6|3|4|5[,...]> | ||
| 291 | Description: Force picture palette. | ||
| 292 | In order: | ||
| 293 | 0 = Off - allows any of the following formats: | ||
| 294 | 9 = UYVY 16 bpp - Original video, compression disabled | ||
| 295 | 10 = YUV420 12 bpp - Original video, compression enabled | ||
| 296 | 13 = YUV422P 16 bpp - Original video, compression enabled | ||
| 297 | 15 = YUV420P 12 bpp - Original video, compression enabled | ||
| 298 | 8 = YUVY 16 bpp - Software conversion from UYVY | ||
| 299 | 7 = YUV422 16 bpp - Software conversion from UYVY | ||
| 300 | 1 = GREY 8 bpp - Software conversion from UYVY | ||
| 301 | 6 = RGB555 16 bpp - Software conversion from UYVY | ||
| 302 | 3 = RGB565 16 bpp - Software conversion from UYVY | ||
| 303 | 4 = RGB24 24 bpp - Software conversion from UYVY | ||
| 304 | 5 = RGB32 32 bpp - Software conversion from UYVY | ||
| 305 | When not 0, this parameter will override 'decompression'. | ||
| 306 | Default: 0 for every device. Initial palette is 9 (UYVY). | ||
| 307 | Note: If 'w9968cf-vpp' is not present, this parameter is set to 9. | ||
| 308 | ------------------------------------------------------------------------------- | ||
| 309 | Name: force_rgb | ||
| 310 | Type: bool array (min = 0, max = 32) | ||
| 311 | Syntax: <0|1[,...]> | ||
| 312 | Description: Read RGB video data instead of BGR: | ||
| 313 | 1 = use RGB component ordering. | ||
| 314 | 0 = use BGR component ordering. | ||
| 315 | This parameter has effect when using RGBX palettes only. | ||
| 316 | Default: 0 for every device. | ||
| 317 | ------------------------------------------------------------------------------- | ||
| 318 | Name: autobright | ||
| 319 | Type: bool array (min = 0, max = 32) | ||
| 320 | Syntax: <0|1[,...]> | ||
| 321 | Description: Image sensor automatically changes brightness: | ||
| 322 | 0 = no, 1 = yes | ||
| 323 | Default: 0 for every device. | ||
| 324 | ------------------------------------------------------------------------------- | ||
| 325 | Name: autoexp | ||
| 326 | Type: bool array (min = 0, max = 32) | ||
| 327 | Syntax: <0|1[,...]> | ||
| 328 | Description: Image sensor automatically changes exposure: | ||
| 329 | 0 = no, 1 = yes | ||
| 330 | Default: 1 for every device. | ||
| 331 | ------------------------------------------------------------------------------- | ||
| 332 | Name: lightfreq | ||
| 333 | Type: int array (min = 0, max = 32) | ||
| 334 | Syntax: <50|60[,...]> | ||
| 335 | Description: Light frequency in Hz: | ||
| 336 | 50 for European and Asian lighting, 60 for American lighting. | ||
| 337 | Default: 50 for every device. | ||
| 338 | ------------------------------------------------------------------------------- | ||
| 339 | Name: bandingfilter | ||
| 340 | Type: bool array (min = 0, max = 32) | ||
| 341 | Syntax: <0|1[,...]> | ||
| 342 | Description: Banding filter to reduce effects of fluorescent | ||
| 343 | lighting: | ||
| 344 | 0 disabled, 1 enabled. | ||
| 345 | This filter tries to reduce the pattern of horizontal | ||
| 346 | light/dark bands caused by some (usually fluorescent) lighting. | ||
| 347 | Default: 0 for every device. | ||
| 348 | ------------------------------------------------------------------------------- | ||
| 349 | Name: clockdiv | ||
| 350 | Type: int array (min = 0, max = 32) | ||
| 351 | Syntax: <-1|n[,...]> | ||
| 352 | Description: Force pixel clock divisor to a specific value (for experts): | ||
| 353 | n may vary from 0 to 127. | ||
| 354 | -1 for automatic value. | ||
| 355 | See also the 'double_buffer' module parameter. | ||
| 356 | Default: -1 for every device. | ||
| 357 | ------------------------------------------------------------------------------- | ||
| 358 | Name: backlight | ||
| 359 | Type: bool array (min = 0, max = 32) | ||
| 360 | Syntax: <0|1[,...]> | ||
| 361 | Description: Objects are lit from behind: | ||
| 362 | 0 = no, 1 = yes | ||
| 363 | Default: 0 for every device. | ||
| 364 | ------------------------------------------------------------------------------- | ||
| 365 | Name: mirror | ||
| 366 | Type: bool array (min = 0, max = 32) | ||
| 367 | Syntax: <0|1[,...]> | ||
| 368 | Description: Reverse image horizontally: | ||
| 369 | 0 = no, 1 = yes | ||
| 370 | Default: 0 for every device. | ||
| 371 | ------------------------------------------------------------------------------- | ||
| 372 | Name: monochrome | ||
| 373 | Type: bool array (min = 0, max = 32) | ||
| 374 | Syntax: <0|1[,...]> | ||
| 375 | Description: The image sensor is monochrome: | ||
| 376 | 0 = no, 1 = yes | ||
| 377 | Default: 0 for every device. | ||
| 378 | ------------------------------------------------------------------------------- | ||
| 379 | Name: brightness | ||
| 380 | Type: long array (min = 0, max = 32) | ||
| 381 | Syntax: <n[,...]> | ||
| 382 | Description: Set picture brightness (0-65535). | ||
| 383 | This parameter has no effect if 'autobright' is enabled. | ||
| 384 | Default: 31000 for every device. | ||
| 385 | ------------------------------------------------------------------------------- | ||
| 386 | Name: hue | ||
| 387 | Type: long array (min = 0, max = 32) | ||
| 388 | Syntax: <n[,...]> | ||
| 389 | Description: Set picture hue (0-65535). | ||
| 390 | Default: 32768 for every device. | ||
| 391 | ------------------------------------------------------------------------------- | ||
| 392 | Name: colour | ||
| 393 | Type: long array (min = 0, max = 32) | ||
| 394 | Syntax: <n[,...]> | ||
| 395 | Description: Set picture saturation (0-65535). | ||
| 396 | Default: 32768 for every device. | ||
| 397 | ------------------------------------------------------------------------------- | ||
| 398 | Name: contrast | ||
| 399 | Type: long array (min = 0, max = 32) | ||
| 400 | Syntax: <n[,...]> | ||
| 401 | Description: Set picture contrast (0-65535). | ||
| 402 | Default: 50000 for every device. | ||
| 403 | ------------------------------------------------------------------------------- | ||
| 404 | Name: whiteness | ||
| 405 | Type: long array (min = 0, max = 32) | ||
| 406 | Syntax: <n[,...]> | ||
| 407 | Description: Set picture whiteness (0-65535). | ||
| 408 | Default: 32768 for every device. | ||
| 409 | ------------------------------------------------------------------------------- | ||
| 410 | Name: debug | ||
| 411 | Type: int | ||
| 412 | Syntax: <n> | ||
| 413 | Description: Debugging information level, from 0 to 6: | ||
| 414 | 0 = none (use carefully) | ||
| 415 | 1 = critical errors | ||
| 416 | 2 = significant information | ||
| 417 | 3 = configuration or general messages | ||
| 418 | 4 = warnings | ||
| 419 | 5 = called functions | ||
| 420 | 6 = function internals | ||
| 421 | Level 5 and 6 are useful for testing only, when only one | ||
| 422 | device is used. | ||
| 423 | Default: 2 | ||
| 424 | ------------------------------------------------------------------------------- | ||
| 425 | Name: specific_debug | ||
| 426 | Type: bool | ||
| 427 | Syntax: <0|1> | ||
| 428 | Description: Enable or disable specific debugging messages: | ||
| 429 | 0 = print messages concerning every level <= 'debug' level. | ||
| 430 | 1 = print messages concerning the level indicated by 'debug'. | ||
| 431 | Default: 0 | ||
| 432 | ------------------------------------------------------------------------------- | ||
| 433 | |||
| 434 | |||
| 435 | 9. Contact information | ||
| 436 | ====================== | ||
| 437 | I may be contacted by e-mail at <luca.risolia@studio.unibo.it>. | ||
| 438 | |||
| 439 | I can accept GPG/PGP encrypted e-mail. My GPG key ID is 'FCE635A4'. | ||
| 440 | My public 1024-bit key should be available at your keyserver; the fingerprint | ||
| 441 | is: '88E8 F32F 7244 68BA 3958 5D40 99DA 5D2A FCE6 35A4'. | ||
| 442 | |||
| 443 | |||
| 444 | 10. Credits | ||
| 445 | ========== | ||
| 446 | The development would not have proceed much further without having looked at | ||
| 447 | the source code of other drivers and without the help of several persons; in | ||
| 448 | particular: | ||
| 449 | |||
| 450 | - the I2C interface to kernel and high-level image sensor control routines have | ||
| 451 | been taken from the OV511 driver by Mark McClelland; | ||
| 452 | |||
| 453 | - memory management code has been copied from the bttv driver by Ralph Metzler, | ||
| 454 | Marcus Metzler and Gerd Knorr; | ||
| 455 | |||
| 456 | - the low-level I2C read function has been written by Frederic Jouault; | ||
| 457 | |||
| 458 | - the low-level I2C fast write function has been written by Piotr Czerczak. | ||
diff --git a/Documentation/video4linux/zc0301.txt b/Documentation/video4linux/zc0301.txt deleted file mode 100644 index b41c83cf09f4..000000000000 --- a/Documentation/video4linux/zc0301.txt +++ /dev/null | |||
| @@ -1,270 +0,0 @@ | |||
| 1 | |||
| 2 | ZC0301 and ZC0301P Image Processor and Control Chip | ||
| 3 | Driver for Linux | ||
| 4 | =================================================== | ||
| 5 | |||
| 6 | - Documentation - | ||
| 7 | |||
| 8 | |||
| 9 | Index | ||
| 10 | ===== | ||
| 11 | 1. Copyright | ||
| 12 | 2. Disclaimer | ||
| 13 | 3. License | ||
| 14 | 4. Overview and features | ||
| 15 | 5. Module dependencies | ||
| 16 | 6. Module loading | ||
| 17 | 7. Module parameters | ||
| 18 | 8. Supported devices | ||
| 19 | 9. Notes for V4L2 application developers | ||
| 20 | 10. Contact information | ||
| 21 | 11. Credits | ||
| 22 | |||
| 23 | |||
| 24 | 1. Copyright | ||
| 25 | ============ | ||
| 26 | Copyright (C) 2006-2007 by Luca Risolia <luca.risolia@studio.unibo.it> | ||
| 27 | |||
| 28 | |||
| 29 | 2. Disclaimer | ||
| 30 | ============= | ||
| 31 | This software is not developed or sponsored by Z-Star Microelectronics Corp. | ||
| 32 | Trademarks are property of their respective owner. | ||
| 33 | |||
| 34 | |||
| 35 | 3. License | ||
| 36 | ========== | ||
| 37 | This program is free software; you can redistribute it and/or modify | ||
| 38 | it under the terms of the GNU General Public License as published by | ||
| 39 | the Free Software Foundation; either version 2 of the License, or | ||
| 40 | (at your option) any later version. | ||
| 41 | |||
| 42 | This program is distributed in the hope that it will be useful, | ||
| 43 | but WITHOUT ANY WARRANTY; without even the implied warranty of | ||
| 44 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | ||
| 45 | GNU General Public License for more details. | ||
| 46 | |||
| 47 | You should have received a copy of the GNU General Public License | ||
| 48 | along with this program; if not, write to the Free Software | ||
| 49 | Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. | ||
| 50 | |||
| 51 | |||
| 52 | 4. Overview and features | ||
| 53 | ======================== | ||
| 54 | This driver supports the video interface of the devices mounting the ZC0301 or | ||
| 55 | ZC0301P Image Processors and Control Chips. | ||
| 56 | |||
| 57 | The driver relies on the Video4Linux2 and USB core modules. It has been | ||
| 58 | designed to run properly on SMP systems as well. | ||
| 59 | |||
| 60 | The latest version of the ZC0301[P] driver can be found at the following URL: | ||
| 61 | http://www.linux-projects.org/ | ||
| 62 | |||
| 63 | Some of the features of the driver are: | ||
| 64 | |||
| 65 | - full compliance with the Video4Linux2 API (see also "Notes for V4L2 | ||
| 66 | application developers" paragraph); | ||
| 67 | - available mmap or read/poll methods for video streaming through isochronous | ||
| 68 | data transfers; | ||
| 69 | - automatic detection of image sensor; | ||
| 70 | - video format is standard JPEG; | ||
| 71 | - dynamic driver control thanks to various module parameters (see "Module | ||
| 72 | parameters" paragraph); | ||
| 73 | - up to 64 cameras can be handled at the same time; they can be connected and | ||
| 74 | disconnected from the host many times without turning off the computer, if | ||
| 75 | the system supports hotplugging; | ||
| 76 | |||
| 77 | |||
| 78 | 5. Module dependencies | ||
| 79 | ====================== | ||
| 80 | For it to work properly, the driver needs kernel support for Video4Linux and | ||
| 81 | USB. | ||
| 82 | |||
| 83 | The following options of the kernel configuration file must be enabled and | ||
| 84 | corresponding modules must be compiled: | ||
| 85 | |||
| 86 | # Multimedia devices | ||
| 87 | # | ||
| 88 | CONFIG_VIDEO_DEV=m | ||
| 89 | |||
| 90 | # USB support | ||
| 91 | # | ||
| 92 | CONFIG_USB=m | ||
| 93 | |||
| 94 | In addition, depending on the hardware being used, the modules below are | ||
| 95 | necessary: | ||
| 96 | |||
| 97 | # USB Host Controller Drivers | ||
| 98 | # | ||
| 99 | CONFIG_USB_EHCI_HCD=m | ||
| 100 | CONFIG_USB_UHCI_HCD=m | ||
| 101 | CONFIG_USB_OHCI_HCD=m | ||
| 102 | |||
| 103 | The ZC0301 controller also provides a built-in microphone interface. It is | ||
| 104 | supported by the USB Audio driver thanks to the ALSA API: | ||
| 105 | |||
| 106 | # Sound | ||
| 107 | # | ||
| 108 | CONFIG_SOUND=y | ||
| 109 | |||
| 110 | # Advanced Linux Sound Architecture | ||
| 111 | # | ||
| 112 | CONFIG_SND=m | ||
| 113 | |||
| 114 | # USB devices | ||
| 115 | # | ||
| 116 | CONFIG_SND_USB_AUDIO=m | ||
| 117 | |||
| 118 | And finally: | ||
| 119 | |||
| 120 | # V4L USB devices | ||
| 121 | # | ||
| 122 | CONFIG_USB_ZC0301=m | ||
| 123 | |||
| 124 | |||
| 125 | 6. Module loading | ||
| 126 | ================= | ||
| 127 | To use the driver, it is necessary to load the "zc0301" module into memory | ||
| 128 | after every other module required: "videodev", "v4l2_common", "compat_ioctl32", | ||
| 129 | "usbcore" and, depending on the USB host controller you have, "ehci-hcd", | ||
| 130 | "uhci-hcd" or "ohci-hcd". | ||
| 131 | |||
| 132 | Loading can be done as shown below: | ||
| 133 | |||
| 134 | [root@localhost home]# modprobe zc0301 | ||
| 135 | |||
| 136 | At this point the devices should be recognized. You can invoke "dmesg" to | ||
| 137 | analyze kernel messages and verify that the loading process has gone well: | ||
| 138 | |||
| 139 | [user@localhost home]$ dmesg | ||
| 140 | |||
| 141 | |||
| 142 | 7. Module parameters | ||
| 143 | ==================== | ||
| 144 | Module parameters are listed below: | ||
| 145 | ------------------------------------------------------------------------------- | ||
| 146 | Name: video_nr | ||
| 147 | Type: short array (min = 0, max = 64) | ||
| 148 | Syntax: <-1|n[,...]> | ||
| 149 | Description: Specify V4L2 minor mode number: | ||
| 150 | -1 = use next available | ||
| 151 | n = use minor number n | ||
| 152 | You can specify up to 64 cameras this way. | ||
| 153 | For example: | ||
| 154 | video_nr=-1,2,-1 would assign minor number 2 to the second | ||
| 155 | registered camera and use auto for the first one and for every | ||
| 156 | other camera. | ||
| 157 | Default: -1 | ||
| 158 | ------------------------------------------------------------------------------- | ||
| 159 | Name: force_munmap | ||
| 160 | Type: bool array (min = 0, max = 64) | ||
| 161 | Syntax: <0|1[,...]> | ||
| 162 | Description: Force the application to unmap previously mapped buffer memory | ||
| 163 | before calling any VIDIOC_S_CROP or VIDIOC_S_FMT ioctl's. Not | ||
| 164 | all the applications support this feature. This parameter is | ||
| 165 | specific for each detected camera. | ||
| 166 | 0 = do not force memory unmapping | ||
| 167 | 1 = force memory unmapping (save memory) | ||
| 168 | Default: 0 | ||
| 169 | ------------------------------------------------------------------------------- | ||
| 170 | Name: frame_timeout | ||
| 171 | Type: uint array (min = 0, max = 64) | ||
| 172 | Syntax: <n[,...]> | ||
| 173 | Description: Timeout for a video frame in seconds. This parameter is | ||
| 174 | specific for each detected camera. This parameter can be | ||
| 175 | changed at runtime thanks to the /sys filesystem interface. | ||
| 176 | Default: 2 | ||
| 177 | ------------------------------------------------------------------------------- | ||
| 178 | Name: debug | ||
| 179 | Type: ushort | ||
| 180 | Syntax: <n> | ||
| 181 | Description: Debugging information level, from 0 to 3: | ||
| 182 | 0 = none (use carefully) | ||
| 183 | 1 = critical errors | ||
| 184 | 2 = significant information | ||
| 185 | 3 = more verbose messages | ||
| 186 | Level 3 is useful for testing only, when only one device | ||
| 187 | is used at the same time. It also shows some information | ||
| 188 | about the hardware being detected. This module parameter can be | ||
| 189 | changed at runtime thanks to the /sys filesystem interface. | ||
| 190 | Default: 2 | ||
| 191 | ------------------------------------------------------------------------------- | ||
| 192 | |||
| 193 | |||
| 194 | 8. Supported devices | ||
| 195 | ==================== | ||
| 196 | None of the names of the companies as well as their products will be mentioned | ||
| 197 | here. They have never collaborated with the author, so no advertising. | ||
| 198 | |||
| 199 | From the point of view of a driver, what unambiguously identify a device are | ||
| 200 | its vendor and product USB identifiers. Below is a list of known identifiers of | ||
| 201 | devices mounting the ZC0301 Image Processor and Control Chips: | ||
| 202 | |||
| 203 | Vendor ID Product ID | ||
| 204 | --------- ---------- | ||
| 205 | 0x041e 0x4017 | ||
| 206 | 0x041e 0x401c | ||
| 207 | 0x041e 0x401e | ||
| 208 | 0x041e 0x401f | ||
| 209 | 0x041e 0x4022 | ||
| 210 | 0x041e 0x4034 | ||
| 211 | 0x041e 0x4035 | ||
| 212 | 0x041e 0x4036 | ||
| 213 | 0x041e 0x403a | ||
| 214 | 0x0458 0x7007 | ||
| 215 | 0x0458 0x700c | ||
| 216 | 0x0458 0x700f | ||
| 217 | 0x046d 0x08ae | ||
| 218 | 0x055f 0xd003 | ||
| 219 | 0x055f 0xd004 | ||
| 220 | 0x0ac8 0x0301 | ||
| 221 | 0x0ac8 0x301b | ||
| 222 | 0x0ac8 0x303b | ||
| 223 | 0x10fd 0x0128 | ||
| 224 | 0x10fd 0x8050 | ||
| 225 | 0x10fd 0x804e | ||
| 226 | |||
| 227 | The list above does not imply that all those devices work with this driver: up | ||
| 228 | until now only the ones that mount the following image sensors are supported; | ||
| 229 | kernel messages will always tell you whether this is the case: | ||
| 230 | |||
| 231 | Model Manufacturer | ||
| 232 | ----- ------------ | ||
| 233 | PAS202BCB PixArt Imaging, Inc. | ||
| 234 | PB-0330 Photobit Corporation | ||
| 235 | |||
| 236 | |||
| 237 | 9. Notes for V4L2 application developers | ||
| 238 | ======================================== | ||
| 239 | This driver follows the V4L2 API specifications. In particular, it enforces two | ||
| 240 | rules: | ||
| 241 | |||
| 242 | - exactly one I/O method, either "mmap" or "read", is associated with each | ||
| 243 | file descriptor. Once it is selected, the application must close and reopen the | ||
| 244 | device to switch to the other I/O method; | ||
| 245 | |||
| 246 | - although it is not mandatory, previously mapped buffer memory should always | ||
| 247 | be unmapped before calling any "VIDIOC_S_CROP" or "VIDIOC_S_FMT" ioctl's. | ||
| 248 | The same number of buffers as before will be allocated again to match the size | ||
| 249 | of the new video frames, so you have to map the buffers again before any I/O | ||
| 250 | attempts on them. | ||
| 251 | |||
| 252 | |||
| 253 | 10. Contact information | ||
| 254 | ======================= | ||
| 255 | The author may be contacted by e-mail at <luca.risolia@studio.unibo.it>. | ||
| 256 | |||
| 257 | GPG/PGP encrypted e-mail's are accepted. The GPG key ID of the author is | ||
| 258 | 'FCE635A4'; the public 1024-bit key should be available at any keyserver; | ||
| 259 | the fingerprint is: '88E8 F32F 7244 68BA 3958 5D40 99DA 5D2A FCE6 35A4'. | ||
| 260 | |||
| 261 | |||
| 262 | 11. Credits | ||
| 263 | =========== | ||
| 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 | ||
| 266 | by Andrew Birkett <andy@nobugs.org>; | ||
| 267 | - The initialization values of the ZC0301 controller connected to the PAS202BCB | ||
| 268 | and PB-0330 image sensors have been taken from the SPCA5XX driver maintained | ||
| 269 | by Michel Xhaard <mxhaard@magic.fr>; | ||
| 270 | - Stanislav Lechev donated one camera. | ||
diff --git a/Documentation/watchdog/watchdog-kernel-api.txt b/Documentation/watchdog/watchdog-kernel-api.txt index 086638f6c82d..a0438f3957ca 100644 --- a/Documentation/watchdog/watchdog-kernel-api.txt +++ b/Documentation/watchdog/watchdog-kernel-api.txt | |||
| @@ -1,6 +1,6 @@ | |||
| 1 | The Linux WatchDog Timer Driver Core kernel API. | 1 | The Linux WatchDog Timer Driver Core kernel API. |
| 2 | =============================================== | 2 | =============================================== |
| 3 | Last reviewed: 22-May-2012 | 3 | Last reviewed: 12-Feb-2013 |
| 4 | 4 | ||
| 5 | Wim Van Sebroeck <wim@iguana.be> | 5 | Wim Van Sebroeck <wim@iguana.be> |
| 6 | 6 | ||
| @@ -212,3 +212,15 @@ driver specific data to and a pointer to the data itself. | |||
| 212 | The watchdog_get_drvdata function allows you to retrieve driver specific data. | 212 | The watchdog_get_drvdata function allows you to retrieve driver specific data. |
| 213 | The argument of this function is the watchdog device where you want to retrieve | 213 | The argument of this function is the watchdog device where you want to retrieve |
| 214 | data from. The function returns the pointer to the driver specific data. | 214 | data from. The function returns the pointer to the driver specific data. |
| 215 | |||
| 216 | To initialize the timeout field, the following function can be used: | ||
| 217 | |||
| 218 | extern int watchdog_init_timeout(struct watchdog_device *wdd, | ||
| 219 | unsigned int timeout_parm, struct device *dev); | ||
| 220 | |||
| 221 | The watchdog_init_timeout function allows you to initialize the timeout field | ||
| 222 | using the module timeout parameter or by retrieving the timeout-sec property from | ||
| 223 | the device tree (if the module timeout parameter is invalid). Best practice is | ||
| 224 | to set the default timeout value as timeout value in the watchdog_device and | ||
| 225 | then use this function to set the user "preferred" timeout value. | ||
| 226 | This routine returns zero on success and a negative errno code for failure. | ||