diff options
Diffstat (limited to 'Documentation')
40 files changed, 1734 insertions, 1048 deletions
diff --git a/Documentation/ABI/testing/sysfs-devices-memory b/Documentation/ABI/testing/sysfs-devices-memory index 9fe91c02ee40..bf1627b02a03 100644 --- a/Documentation/ABI/testing/sysfs-devices-memory +++ b/Documentation/ABI/testing/sysfs-devices-memory | |||
@@ -60,6 +60,19 @@ Description: | |||
60 | Users: hotplug memory remove tools | 60 | Users: hotplug memory remove tools |
61 | https://w3.opensource.ibm.com/projects/powerpc-utils/ | 61 | https://w3.opensource.ibm.com/projects/powerpc-utils/ |
62 | 62 | ||
63 | |||
64 | What: /sys/devices/system/memoryX/nodeY | ||
65 | Date: October 2009 | ||
66 | Contact: Linux Memory Management list <linux-mm@kvack.org> | ||
67 | Description: | ||
68 | When CONFIG_NUMA is enabled, a symbolic link that | ||
69 | points to the corresponding NUMA node directory. | ||
70 | |||
71 | For example, the following symbolic link is created for | ||
72 | memory section 9 on node0: | ||
73 | /sys/devices/system/memory/memory9/node0 -> ../../node/node0 | ||
74 | |||
75 | |||
63 | What: /sys/devices/system/node/nodeX/memoryY | 76 | What: /sys/devices/system/node/nodeX/memoryY |
64 | Date: September 2008 | 77 | Date: September 2008 |
65 | Contact: Gary Hade <garyhade@us.ibm.com> | 78 | Contact: Gary Hade <garyhade@us.ibm.com> |
@@ -70,4 +83,3 @@ Description: | |||
70 | memory section directory. For example, the following symbolic | 83 | memory section directory. For example, the following symbolic |
71 | link is created for memory section 9 on node0. | 84 | link is created for memory section 9 on node0. |
72 | /sys/devices/system/node/node0/memory9 -> ../../memory/memory9 | 85 | /sys/devices/system/node/node0/memory9 -> ../../memory/memory9 |
73 | |||
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index 2aae06fcbed7..84a710f87c64 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu | |||
@@ -92,6 +92,20 @@ Description: Discover NUMA node a CPU belongs to | |||
92 | /sys/devices/system/cpu/cpu42/node2 -> ../../node/node2 | 92 | /sys/devices/system/cpu/cpu42/node2 -> ../../node/node2 |
93 | 93 | ||
94 | 94 | ||
95 | What: /sys/devices/system/cpu/cpu#/node | ||
96 | Date: October 2009 | ||
97 | Contact: Linux memory management mailing list <linux-mm@kvack.org> | ||
98 | Description: Discover NUMA node a CPU belongs to | ||
99 | |||
100 | When CONFIG_NUMA is enabled, a symbolic link that points | ||
101 | to the corresponding NUMA node directory. | ||
102 | |||
103 | For example, the following symlink is created for cpu42 | ||
104 | in NUMA node 2: | ||
105 | |||
106 | /sys/devices/system/cpu/cpu42/node2 -> ../../node/node2 | ||
107 | |||
108 | |||
95 | What: /sys/devices/system/cpu/cpu#/topology/core_id | 109 | What: /sys/devices/system/cpu/cpu#/topology/core_id |
96 | /sys/devices/system/cpu/cpu#/topology/core_siblings | 110 | /sys/devices/system/cpu/cpu#/topology/core_siblings |
97 | /sys/devices/system/cpu/cpu#/topology/core_siblings_list | 111 | /sys/devices/system/cpu/cpu#/topology/core_siblings_list |
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index ab8300f67182..325cfd1d6d99 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile | |||
@@ -8,7 +8,7 @@ | |||
8 | 8 | ||
9 | DOCBOOKS := z8530book.xml mcabook.xml device-drivers.xml \ | 9 | DOCBOOKS := z8530book.xml mcabook.xml device-drivers.xml \ |
10 | kernel-hacking.xml kernel-locking.xml deviceiobook.xml \ | 10 | kernel-hacking.xml kernel-locking.xml deviceiobook.xml \ |
11 | procfs-guide.xml writing_usb_driver.xml networking.xml \ | 11 | writing_usb_driver.xml networking.xml \ |
12 | kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \ | 12 | kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \ |
13 | gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \ | 13 | gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \ |
14 | genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \ | 14 | genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \ |
@@ -32,10 +32,10 @@ PS_METHOD = $(prefer-db2x) | |||
32 | 32 | ||
33 | ### | 33 | ### |
34 | # The targets that may be used. | 34 | # The targets that may be used. |
35 | PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs cleandocs media | 35 | PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs cleandocs xmldoclinks |
36 | 36 | ||
37 | BOOKS := $(addprefix $(obj)/,$(DOCBOOKS)) | 37 | BOOKS := $(addprefix $(obj)/,$(DOCBOOKS)) |
38 | xmldocs: $(BOOKS) | 38 | xmldocs: $(BOOKS) xmldoclinks |
39 | sgmldocs: xmldocs | 39 | sgmldocs: xmldocs |
40 | 40 | ||
41 | PS := $(patsubst %.xml, %.ps, $(BOOKS)) | 41 | PS := $(patsubst %.xml, %.ps, $(BOOKS)) |
@@ -45,15 +45,24 @@ PDF := $(patsubst %.xml, %.pdf, $(BOOKS)) | |||
45 | pdfdocs: $(PDF) | 45 | pdfdocs: $(PDF) |
46 | 46 | ||
47 | HTML := $(sort $(patsubst %.xml, %.html, $(BOOKS))) | 47 | HTML := $(sort $(patsubst %.xml, %.html, $(BOOKS))) |
48 | htmldocs: media $(HTML) | 48 | htmldocs: $(HTML) |
49 | $(call build_main_index) | 49 | $(call build_main_index) |
50 | $(call build_images) | ||
50 | 51 | ||
51 | MAN := $(patsubst %.xml, %.9, $(BOOKS)) | 52 | MAN := $(patsubst %.xml, %.9, $(BOOKS)) |
52 | mandocs: $(MAN) | 53 | mandocs: $(MAN) |
53 | 54 | ||
54 | media: | 55 | build_images = mkdir -p $(objtree)/Documentation/DocBook/media/ && \ |
55 | mkdir -p $(srctree)/Documentation/DocBook/media/ | 56 | cp $(srctree)/Documentation/DocBook/dvb/*.png $(srctree)/Documentation/DocBook/v4l/*.gif $(objtree)/Documentation/DocBook/media/ |
56 | cp $(srctree)/Documentation/DocBook/dvb/*.png $(srctree)/Documentation/DocBook/v4l/*.gif $(srctree)/Documentation/DocBook/media/ | 57 | |
58 | xmldoclinks: | ||
59 | ifneq ($(objtree),$(srctree)) | ||
60 | for dep in dvb media-entities.tmpl media-indices.tmpl v4l; do \ | ||
61 | rm -f $(objtree)/Documentation/DocBook/$$dep \ | ||
62 | && ln -s $(srctree)/Documentation/DocBook/$$dep $(objtree)/Documentation/DocBook/ \ | ||
63 | || exit; \ | ||
64 | done | ||
65 | endif | ||
57 | 66 | ||
58 | installmandocs: mandocs | 67 | installmandocs: mandocs |
59 | mkdir -p /usr/local/man/man9/ | 68 | mkdir -p /usr/local/man/man9/ |
@@ -65,7 +74,7 @@ KERNELDOC = $(srctree)/scripts/kernel-doc | |||
65 | DOCPROC = $(objtree)/scripts/basic/docproc | 74 | DOCPROC = $(objtree)/scripts/basic/docproc |
66 | 75 | ||
67 | XMLTOFLAGS = -m $(srctree)/Documentation/DocBook/stylesheet.xsl | 76 | XMLTOFLAGS = -m $(srctree)/Documentation/DocBook/stylesheet.xsl |
68 | #XMLTOFLAGS += --skip-validation | 77 | XMLTOFLAGS += --skip-validation |
69 | 78 | ||
70 | ### | 79 | ### |
71 | # DOCPROC is used for two purposes: | 80 | # DOCPROC is used for two purposes: |
@@ -101,17 +110,6 @@ endif | |||
101 | # Changes in kernel-doc force a rebuild of all documentation | 110 | # Changes in kernel-doc force a rebuild of all documentation |
102 | $(BOOKS): $(KERNELDOC) | 111 | $(BOOKS): $(KERNELDOC) |
103 | 112 | ||
104 | ### | ||
105 | # procfs guide uses a .c file as example code. | ||
106 | # This requires an explicit dependency | ||
107 | C-procfs-example = procfs_example.xml | ||
108 | C-procfs-example2 = $(addprefix $(obj)/,$(C-procfs-example)) | ||
109 | $(obj)/procfs-guide.xml: $(C-procfs-example2) | ||
110 | |||
111 | # List of programs to build | ||
112 | ##oops, this is a kernel module::hostprogs-y := procfs_example | ||
113 | obj-m += procfs_example.o | ||
114 | |||
115 | # Tell kbuild to always build the programs | 113 | # Tell kbuild to always build the programs |
116 | always := $(hostprogs-y) | 114 | always := $(hostprogs-y) |
117 | 115 | ||
@@ -238,7 +236,7 @@ clean-files := $(DOCBOOKS) \ | |||
238 | $(patsubst %.xml, %.pdf, $(DOCBOOKS)) \ | 236 | $(patsubst %.xml, %.pdf, $(DOCBOOKS)) \ |
239 | $(patsubst %.xml, %.html, $(DOCBOOKS)) \ | 237 | $(patsubst %.xml, %.html, $(DOCBOOKS)) \ |
240 | $(patsubst %.xml, %.9, $(DOCBOOKS)) \ | 238 | $(patsubst %.xml, %.9, $(DOCBOOKS)) \ |
241 | $(C-procfs-example) $(index) | 239 | $(index) |
242 | 240 | ||
243 | clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man | 241 | clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man |
244 | 242 | ||
diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl index bb5ab741220e..c725cb852c54 100644 --- a/Documentation/DocBook/media-entities.tmpl +++ b/Documentation/DocBook/media-entities.tmpl | |||
@@ -23,6 +23,7 @@ | |||
23 | <!ENTITY VIDIOC-ENUMINPUT "<link linkend='vidioc-enuminput'><constant>VIDIOC_ENUMINPUT</constant></link>"> | 23 | <!ENTITY VIDIOC-ENUMINPUT "<link linkend='vidioc-enuminput'><constant>VIDIOC_ENUMINPUT</constant></link>"> |
24 | <!ENTITY VIDIOC-ENUMOUTPUT "<link linkend='vidioc-enumoutput'><constant>VIDIOC_ENUMOUTPUT</constant></link>"> | 24 | <!ENTITY VIDIOC-ENUMOUTPUT "<link linkend='vidioc-enumoutput'><constant>VIDIOC_ENUMOUTPUT</constant></link>"> |
25 | <!ENTITY VIDIOC-ENUMSTD "<link linkend='vidioc-enumstd'><constant>VIDIOC_ENUMSTD</constant></link>"> | 25 | <!ENTITY VIDIOC-ENUMSTD "<link linkend='vidioc-enumstd'><constant>VIDIOC_ENUMSTD</constant></link>"> |
26 | <!ENTITY VIDIOC-ENUM-DV-PRESETS "<link linkend='vidioc-enum-dv-presets'><constant>VIDIOC_ENUM_DV_PRESETS</constant></link>"> | ||
26 | <!ENTITY VIDIOC-ENUM-FMT "<link linkend='vidioc-enum-fmt'><constant>VIDIOC_ENUM_FMT</constant></link>"> | 27 | <!ENTITY VIDIOC-ENUM-FMT "<link linkend='vidioc-enum-fmt'><constant>VIDIOC_ENUM_FMT</constant></link>"> |
27 | <!ENTITY VIDIOC-ENUM-FRAMEINTERVALS "<link linkend='vidioc-enum-frameintervals'><constant>VIDIOC_ENUM_FRAMEINTERVALS</constant></link>"> | 28 | <!ENTITY VIDIOC-ENUM-FRAMEINTERVALS "<link linkend='vidioc-enum-frameintervals'><constant>VIDIOC_ENUM_FRAMEINTERVALS</constant></link>"> |
28 | <!ENTITY VIDIOC-ENUM-FRAMESIZES "<link linkend='vidioc-enum-framesizes'><constant>VIDIOC_ENUM_FRAMESIZES</constant></link>"> | 29 | <!ENTITY VIDIOC-ENUM-FRAMESIZES "<link linkend='vidioc-enum-framesizes'><constant>VIDIOC_ENUM_FRAMESIZES</constant></link>"> |
@@ -30,6 +31,8 @@ | |||
30 | <!ENTITY VIDIOC-G-AUDOUT "<link linkend='vidioc-g-audioout'><constant>VIDIOC_G_AUDOUT</constant></link>"> | 31 | <!ENTITY VIDIOC-G-AUDOUT "<link linkend='vidioc-g-audioout'><constant>VIDIOC_G_AUDOUT</constant></link>"> |
31 | <!ENTITY VIDIOC-G-CROP "<link linkend='vidioc-g-crop'><constant>VIDIOC_G_CROP</constant></link>"> | 32 | <!ENTITY VIDIOC-G-CROP "<link linkend='vidioc-g-crop'><constant>VIDIOC_G_CROP</constant></link>"> |
32 | <!ENTITY VIDIOC-G-CTRL "<link linkend='vidioc-g-ctrl'><constant>VIDIOC_G_CTRL</constant></link>"> | 33 | <!ENTITY VIDIOC-G-CTRL "<link linkend='vidioc-g-ctrl'><constant>VIDIOC_G_CTRL</constant></link>"> |
34 | <!ENTITY VIDIOC-G-DV-PRESET "<link linkend='vidioc-g-dv-preset'><constant>VIDIOC_G_DV_PRESET</constant></link>"> | ||
35 | <!ENTITY VIDIOC-G-DV-TIMINGS "<link linkend='vidioc-g-dv-timings'><constant>VIDIOC_G_DV_TIMINGS</constant></link>"> | ||
33 | <!ENTITY VIDIOC-G-ENC-INDEX "<link linkend='vidioc-g-enc-index'><constant>VIDIOC_G_ENC_INDEX</constant></link>"> | 36 | <!ENTITY VIDIOC-G-ENC-INDEX "<link linkend='vidioc-g-enc-index'><constant>VIDIOC_G_ENC_INDEX</constant></link>"> |
34 | <!ENTITY VIDIOC-G-EXT-CTRLS "<link linkend='vidioc-g-ext-ctrls'><constant>VIDIOC_G_EXT_CTRLS</constant></link>"> | 37 | <!ENTITY VIDIOC-G-EXT-CTRLS "<link linkend='vidioc-g-ext-ctrls'><constant>VIDIOC_G_EXT_CTRLS</constant></link>"> |
35 | <!ENTITY VIDIOC-G-FBUF "<link linkend='vidioc-g-fbuf'><constant>VIDIOC_G_FBUF</constant></link>"> | 38 | <!ENTITY VIDIOC-G-FBUF "<link linkend='vidioc-g-fbuf'><constant>VIDIOC_G_FBUF</constant></link>"> |
@@ -53,6 +56,7 @@ | |||
53 | <!ENTITY VIDIOC-QUERYCTRL "<link linkend='vidioc-queryctrl'><constant>VIDIOC_QUERYCTRL</constant></link>"> | 56 | <!ENTITY VIDIOC-QUERYCTRL "<link linkend='vidioc-queryctrl'><constant>VIDIOC_QUERYCTRL</constant></link>"> |
54 | <!ENTITY VIDIOC-QUERYMENU "<link linkend='vidioc-queryctrl'><constant>VIDIOC_QUERYMENU</constant></link>"> | 57 | <!ENTITY VIDIOC-QUERYMENU "<link linkend='vidioc-queryctrl'><constant>VIDIOC_QUERYMENU</constant></link>"> |
55 | <!ENTITY VIDIOC-QUERYSTD "<link linkend='vidioc-querystd'><constant>VIDIOC_QUERYSTD</constant></link>"> | 58 | <!ENTITY VIDIOC-QUERYSTD "<link linkend='vidioc-querystd'><constant>VIDIOC_QUERYSTD</constant></link>"> |
59 | <!ENTITY VIDIOC-QUERY-DV-PRESET "<link linkend='vidioc-query-dv-preset'><constant>VIDIOC_QUERY_DV_PRESET</constant></link>"> | ||
56 | <!ENTITY VIDIOC-REQBUFS "<link linkend='vidioc-reqbufs'><constant>VIDIOC_REQBUFS</constant></link>"> | 60 | <!ENTITY VIDIOC-REQBUFS "<link linkend='vidioc-reqbufs'><constant>VIDIOC_REQBUFS</constant></link>"> |
57 | <!ENTITY VIDIOC-STREAMOFF "<link linkend='vidioc-streamon'><constant>VIDIOC_STREAMOFF</constant></link>"> | 61 | <!ENTITY VIDIOC-STREAMOFF "<link linkend='vidioc-streamon'><constant>VIDIOC_STREAMOFF</constant></link>"> |
58 | <!ENTITY VIDIOC-STREAMON "<link linkend='vidioc-streamon'><constant>VIDIOC_STREAMON</constant></link>"> | 62 | <!ENTITY VIDIOC-STREAMON "<link linkend='vidioc-streamon'><constant>VIDIOC_STREAMON</constant></link>"> |
@@ -60,6 +64,8 @@ | |||
60 | <!ENTITY VIDIOC-S-AUDOUT "<link linkend='vidioc-g-audioout'><constant>VIDIOC_S_AUDOUT</constant></link>"> | 64 | <!ENTITY VIDIOC-S-AUDOUT "<link linkend='vidioc-g-audioout'><constant>VIDIOC_S_AUDOUT</constant></link>"> |
61 | <!ENTITY VIDIOC-S-CROP "<link linkend='vidioc-g-crop'><constant>VIDIOC_S_CROP</constant></link>"> | 65 | <!ENTITY VIDIOC-S-CROP "<link linkend='vidioc-g-crop'><constant>VIDIOC_S_CROP</constant></link>"> |
62 | <!ENTITY VIDIOC-S-CTRL "<link linkend='vidioc-g-ctrl'><constant>VIDIOC_S_CTRL</constant></link>"> | 66 | <!ENTITY VIDIOC-S-CTRL "<link linkend='vidioc-g-ctrl'><constant>VIDIOC_S_CTRL</constant></link>"> |
67 | <!ENTITY VIDIOC-S-DV-PRESET "<link linkend='vidioc-g-dv-preset'><constant>VIDIOC_S_DV_PRESET</constant></link>"> | ||
68 | <!ENTITY VIDIOC-S-DV-TIMINGS "<link linkend='vidioc-g-dv-timings'><constant>VIDIOC_S_DV_TIMINGS</constant></link>"> | ||
63 | <!ENTITY VIDIOC-S-EXT-CTRLS "<link linkend='vidioc-g-ext-ctrls'><constant>VIDIOC_S_EXT_CTRLS</constant></link>"> | 69 | <!ENTITY VIDIOC-S-EXT-CTRLS "<link linkend='vidioc-g-ext-ctrls'><constant>VIDIOC_S_EXT_CTRLS</constant></link>"> |
64 | <!ENTITY VIDIOC-S-FBUF "<link linkend='vidioc-g-fbuf'><constant>VIDIOC_S_FBUF</constant></link>"> | 70 | <!ENTITY VIDIOC-S-FBUF "<link linkend='vidioc-g-fbuf'><constant>VIDIOC_S_FBUF</constant></link>"> |
65 | <!ENTITY VIDIOC-S-FMT "<link linkend='vidioc-g-fmt'><constant>VIDIOC_S_FMT</constant></link>"> | 71 | <!ENTITY VIDIOC-S-FMT "<link linkend='vidioc-g-fmt'><constant>VIDIOC_S_FMT</constant></link>"> |
@@ -118,6 +124,7 @@ | |||
118 | <!-- Structures --> | 124 | <!-- Structures --> |
119 | <!ENTITY v4l2-audio "struct <link linkend='v4l2-audio'>v4l2_audio</link>"> | 125 | <!ENTITY v4l2-audio "struct <link linkend='v4l2-audio'>v4l2_audio</link>"> |
120 | <!ENTITY v4l2-audioout "struct <link linkend='v4l2-audioout'>v4l2_audioout</link>"> | 126 | <!ENTITY v4l2-audioout "struct <link linkend='v4l2-audioout'>v4l2_audioout</link>"> |
127 | <!ENTITY v4l2-bt-timings "struct <link linkend='v4l2-bt-timings'>v4l2_bt_timings</link>"> | ||
121 | <!ENTITY v4l2-buffer "struct <link linkend='v4l2-buffer'>v4l2_buffer</link>"> | 128 | <!ENTITY v4l2-buffer "struct <link linkend='v4l2-buffer'>v4l2_buffer</link>"> |
122 | <!ENTITY v4l2-capability "struct <link linkend='v4l2-capability'>v4l2_capability</link>"> | 129 | <!ENTITY v4l2-capability "struct <link linkend='v4l2-capability'>v4l2_capability</link>"> |
123 | <!ENTITY v4l2-captureparm "struct <link linkend='v4l2-captureparm'>v4l2_captureparm</link>"> | 130 | <!ENTITY v4l2-captureparm "struct <link linkend='v4l2-captureparm'>v4l2_captureparm</link>"> |
@@ -128,6 +135,9 @@ | |||
128 | <!ENTITY v4l2-dbg-chip-ident "struct <link linkend='v4l2-dbg-chip-ident'>v4l2_dbg_chip_ident</link>"> | 135 | <!ENTITY v4l2-dbg-chip-ident "struct <link linkend='v4l2-dbg-chip-ident'>v4l2_dbg_chip_ident</link>"> |
129 | <!ENTITY v4l2-dbg-match "struct <link linkend='v4l2-dbg-match'>v4l2_dbg_match</link>"> | 136 | <!ENTITY v4l2-dbg-match "struct <link linkend='v4l2-dbg-match'>v4l2_dbg_match</link>"> |
130 | <!ENTITY v4l2-dbg-register "struct <link linkend='v4l2-dbg-register'>v4l2_dbg_register</link>"> | 137 | <!ENTITY v4l2-dbg-register "struct <link linkend='v4l2-dbg-register'>v4l2_dbg_register</link>"> |
138 | <!ENTITY v4l2-dv-enum-preset "struct <link linkend='v4l2-dv-enum-preset'>v4l2_dv_enum_preset</link>"> | ||
139 | <!ENTITY v4l2-dv-preset "struct <link linkend='v4l2-dv-preset'>v4l2_dv_preset</link>"> | ||
140 | <!ENTITY v4l2-dv-timings "struct <link linkend='v4l2-dv-timings'>v4l2_dv_timings</link>"> | ||
131 | <!ENTITY v4l2-enc-idx "struct <link linkend='v4l2-enc-idx'>v4l2_enc_idx</link>"> | 141 | <!ENTITY v4l2-enc-idx "struct <link linkend='v4l2-enc-idx'>v4l2_enc_idx</link>"> |
132 | <!ENTITY v4l2-enc-idx-entry "struct <link linkend='v4l2-enc-idx-entry'>v4l2_enc_idx_entry</link>"> | 142 | <!ENTITY v4l2-enc-idx-entry "struct <link linkend='v4l2-enc-idx-entry'>v4l2_enc_idx_entry</link>"> |
133 | <!ENTITY v4l2-encoder-cmd "struct <link linkend='v4l2-encoder-cmd'>v4l2_encoder_cmd</link>"> | 143 | <!ENTITY v4l2-encoder-cmd "struct <link linkend='v4l2-encoder-cmd'>v4l2_encoder_cmd</link>"> |
@@ -243,6 +253,10 @@ | |||
243 | <!ENTITY sub-enumaudioout SYSTEM "v4l/vidioc-enumaudioout.xml"> | 253 | <!ENTITY sub-enumaudioout SYSTEM "v4l/vidioc-enumaudioout.xml"> |
244 | <!ENTITY sub-enuminput SYSTEM "v4l/vidioc-enuminput.xml"> | 254 | <!ENTITY sub-enuminput SYSTEM "v4l/vidioc-enuminput.xml"> |
245 | <!ENTITY sub-enumoutput SYSTEM "v4l/vidioc-enumoutput.xml"> | 255 | <!ENTITY sub-enumoutput SYSTEM "v4l/vidioc-enumoutput.xml"> |
256 | <!ENTITY sub-enum-dv-presets SYSTEM "v4l/vidioc-enum-dv-presets.xml"> | ||
257 | <!ENTITY sub-g-dv-preset SYSTEM "v4l/vidioc-g-dv-preset.xml"> | ||
258 | <!ENTITY sub-query-dv-preset SYSTEM "v4l/vidioc-query-dv-preset.xml"> | ||
259 | <!ENTITY sub-g-dv-timings SYSTEM "v4l/vidioc-g-dv-timings.xml"> | ||
246 | <!ENTITY sub-enumstd SYSTEM "v4l/vidioc-enumstd.xml"> | 260 | <!ENTITY sub-enumstd SYSTEM "v4l/vidioc-enumstd.xml"> |
247 | <!ENTITY sub-g-audio SYSTEM "v4l/vidioc-g-audio.xml"> | 261 | <!ENTITY sub-g-audio SYSTEM "v4l/vidioc-g-audio.xml"> |
248 | <!ENTITY sub-g-audioout SYSTEM "v4l/vidioc-g-audioout.xml"> | 262 | <!ENTITY sub-g-audioout SYSTEM "v4l/vidioc-g-audioout.xml"> |
@@ -333,6 +347,10 @@ | |||
333 | <!ENTITY enumaudioout SYSTEM "v4l/vidioc-enumaudioout.xml"> | 347 | <!ENTITY enumaudioout SYSTEM "v4l/vidioc-enumaudioout.xml"> |
334 | <!ENTITY enuminput SYSTEM "v4l/vidioc-enuminput.xml"> | 348 | <!ENTITY enuminput SYSTEM "v4l/vidioc-enuminput.xml"> |
335 | <!ENTITY enumoutput SYSTEM "v4l/vidioc-enumoutput.xml"> | 349 | <!ENTITY enumoutput SYSTEM "v4l/vidioc-enumoutput.xml"> |
350 | <!ENTITY enum-dv-presets SYSTEM "v4l/vidioc-enum-dv-presets.xml"> | ||
351 | <!ENTITY g-dv-preset SYSTEM "v4l/vidioc-g-dv-preset.xml"> | ||
352 | <!ENTITY query-dv-preset SYSTEM "v4l/vidioc-query-dv-preset.xml"> | ||
353 | <!ENTITY g-dv-timings SYSTEM "v4l/vidioc-g-dv-timings.xml"> | ||
336 | <!ENTITY enumstd SYSTEM "v4l/vidioc-enumstd.xml"> | 354 | <!ENTITY enumstd SYSTEM "v4l/vidioc-enumstd.xml"> |
337 | <!ENTITY g-audio SYSTEM "v4l/vidioc-g-audio.xml"> | 355 | <!ENTITY g-audio SYSTEM "v4l/vidioc-g-audio.xml"> |
338 | <!ENTITY g-audioout SYSTEM "v4l/vidioc-g-audioout.xml"> | 356 | <!ENTITY g-audioout SYSTEM "v4l/vidioc-g-audioout.xml"> |
diff --git a/Documentation/DocBook/media-indices.tmpl b/Documentation/DocBook/media-indices.tmpl index 9e30a236d74f..78d6031de001 100644 --- a/Documentation/DocBook/media-indices.tmpl +++ b/Documentation/DocBook/media-indices.tmpl | |||
@@ -36,6 +36,7 @@ | |||
36 | <indexentry><primaryie>enum <link linkend='v4l2-preemphasis'>v4l2_preemphasis</link></primaryie></indexentry> | 36 | <indexentry><primaryie>enum <link linkend='v4l2-preemphasis'>v4l2_preemphasis</link></primaryie></indexentry> |
37 | <indexentry><primaryie>struct <link linkend='v4l2-audio'>v4l2_audio</link></primaryie></indexentry> | 37 | <indexentry><primaryie>struct <link linkend='v4l2-audio'>v4l2_audio</link></primaryie></indexentry> |
38 | <indexentry><primaryie>struct <link linkend='v4l2-audioout'>v4l2_audioout</link></primaryie></indexentry> | 38 | <indexentry><primaryie>struct <link linkend='v4l2-audioout'>v4l2_audioout</link></primaryie></indexentry> |
39 | <indexentry><primaryie>struct <link linkend='v4l2-bt-timings'>v4l2_bt_timings</link></primaryie></indexentry> | ||
39 | <indexentry><primaryie>struct <link linkend='v4l2-buffer'>v4l2_buffer</link></primaryie></indexentry> | 40 | <indexentry><primaryie>struct <link linkend='v4l2-buffer'>v4l2_buffer</link></primaryie></indexentry> |
40 | <indexentry><primaryie>struct <link linkend='v4l2-capability'>v4l2_capability</link></primaryie></indexentry> | 41 | <indexentry><primaryie>struct <link linkend='v4l2-capability'>v4l2_capability</link></primaryie></indexentry> |
41 | <indexentry><primaryie>struct <link linkend='v4l2-captureparm'>v4l2_captureparm</link></primaryie></indexentry> | 42 | <indexentry><primaryie>struct <link linkend='v4l2-captureparm'>v4l2_captureparm</link></primaryie></indexentry> |
@@ -46,6 +47,9 @@ | |||
46 | <indexentry><primaryie>struct <link linkend='v4l2-dbg-chip-ident'>v4l2_dbg_chip_ident</link></primaryie></indexentry> | 47 | <indexentry><primaryie>struct <link linkend='v4l2-dbg-chip-ident'>v4l2_dbg_chip_ident</link></primaryie></indexentry> |
47 | <indexentry><primaryie>struct <link linkend='v4l2-dbg-match'>v4l2_dbg_match</link></primaryie></indexentry> | 48 | <indexentry><primaryie>struct <link linkend='v4l2-dbg-match'>v4l2_dbg_match</link></primaryie></indexentry> |
48 | <indexentry><primaryie>struct <link linkend='v4l2-dbg-register'>v4l2_dbg_register</link></primaryie></indexentry> | 49 | <indexentry><primaryie>struct <link linkend='v4l2-dbg-register'>v4l2_dbg_register</link></primaryie></indexentry> |
50 | <indexentry><primaryie>struct <link linkend='v4l2-dv-enum-preset'>v4l2_dv_enum_preset</link></primaryie></indexentry> | ||
51 | <indexentry><primaryie>struct <link linkend='v4l2-dv-preset'>v4l2_dv_preset</link></primaryie></indexentry> | ||
52 | <indexentry><primaryie>struct <link linkend='v4l2-dv-timings'>v4l2_dv_timings</link></primaryie></indexentry> | ||
49 | <indexentry><primaryie>struct <link linkend='v4l2-enc-idx'>v4l2_enc_idx</link></primaryie></indexentry> | 53 | <indexentry><primaryie>struct <link linkend='v4l2-enc-idx'>v4l2_enc_idx</link></primaryie></indexentry> |
50 | <indexentry><primaryie>struct <link linkend='v4l2-enc-idx-entry'>v4l2_enc_idx_entry</link></primaryie></indexentry> | 54 | <indexentry><primaryie>struct <link linkend='v4l2-enc-idx-entry'>v4l2_enc_idx_entry</link></primaryie></indexentry> |
51 | <indexentry><primaryie>struct <link linkend='v4l2-encoder-cmd'>v4l2_encoder_cmd</link></primaryie></indexentry> | 55 | <indexentry><primaryie>struct <link linkend='v4l2-encoder-cmd'>v4l2_encoder_cmd</link></primaryie></indexentry> |
diff --git a/Documentation/DocBook/procfs-guide.tmpl b/Documentation/DocBook/procfs-guide.tmpl deleted file mode 100644 index 9eba4b7af73d..000000000000 --- a/Documentation/DocBook/procfs-guide.tmpl +++ /dev/null | |||
@@ -1,626 +0,0 @@ | |||
1 | <?xml version="1.0" encoding="UTF-8"?> | ||
2 | <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" | ||
3 | "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [ | ||
4 | <!ENTITY procfsexample SYSTEM "procfs_example.xml"> | ||
5 | ]> | ||
6 | |||
7 | <book id="LKProcfsGuide"> | ||
8 | <bookinfo> | ||
9 | <title>Linux Kernel Procfs Guide</title> | ||
10 | |||
11 | <authorgroup> | ||
12 | <author> | ||
13 | <firstname>Erik</firstname> | ||
14 | <othername>(J.A.K.)</othername> | ||
15 | <surname>Mouw</surname> | ||
16 | <affiliation> | ||
17 | <address> | ||
18 | <email>mouw@nl.linux.org</email> | ||
19 | </address> | ||
20 | </affiliation> | ||
21 | </author> | ||
22 | <othercredit> | ||
23 | <contrib> | ||
24 | This software and documentation were written while working on the | ||
25 | LART computing board | ||
26 | (<ulink url="http://www.lartmaker.nl/">http://www.lartmaker.nl/</ulink>), | ||
27 | which was sponsored by the Delt University of Technology projects | ||
28 | Mobile Multi-media Communications and Ubiquitous Communications. | ||
29 | </contrib> | ||
30 | </othercredit> | ||
31 | </authorgroup> | ||
32 | |||
33 | <revhistory> | ||
34 | <revision> | ||
35 | <revnumber>1.0</revnumber> | ||
36 | <date>May 30, 2001</date> | ||
37 | <revremark>Initial revision posted to linux-kernel</revremark> | ||
38 | </revision> | ||
39 | <revision> | ||
40 | <revnumber>1.1</revnumber> | ||
41 | <date>June 3, 2001</date> | ||
42 | <revremark>Revised after comments from linux-kernel</revremark> | ||
43 | </revision> | ||
44 | </revhistory> | ||
45 | |||
46 | <copyright> | ||
47 | <year>2001</year> | ||
48 | <holder>Erik Mouw</holder> | ||
49 | </copyright> | ||
50 | |||
51 | |||
52 | <legalnotice> | ||
53 | <para> | ||
54 | This documentation is free software; you can redistribute it | ||
55 | and/or modify it under the terms of the GNU General Public | ||
56 | License as published by the Free Software Foundation; either | ||
57 | version 2 of the License, or (at your option) any later | ||
58 | version. | ||
59 | </para> | ||
60 | |||
61 | <para> | ||
62 | This documentation is distributed in the hope that it will be | ||
63 | useful, but WITHOUT ANY WARRANTY; without even the implied | ||
64 | warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR | ||
65 | PURPOSE. See the GNU General Public License for more details. | ||
66 | </para> | ||
67 | |||
68 | <para> | ||
69 | You should have received a copy of the GNU General Public | ||
70 | License along with this program; if not, write to the Free | ||
71 | Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, | ||
72 | MA 02111-1307 USA | ||
73 | </para> | ||
74 | |||
75 | <para> | ||
76 | For more details see the file COPYING in the source | ||
77 | distribution of Linux. | ||
78 | </para> | ||
79 | </legalnotice> | ||
80 | </bookinfo> | ||
81 | |||
82 | |||
83 | |||
84 | |||
85 | <toc> | ||
86 | </toc> | ||
87 | |||
88 | |||
89 | |||
90 | |||
91 | <preface id="Preface"> | ||
92 | <title>Preface</title> | ||
93 | |||
94 | <para> | ||
95 | This guide describes the use of the procfs file system from | ||
96 | within the Linux kernel. The idea to write this guide came up on | ||
97 | the #kernelnewbies IRC channel (see <ulink | ||
98 | url="http://www.kernelnewbies.org/">http://www.kernelnewbies.org/</ulink>), | ||
99 | when Jeff Garzik explained the use of procfs and forwarded me a | ||
100 | message Alexander Viro wrote to the linux-kernel mailing list. I | ||
101 | agreed to write it up nicely, so here it is. | ||
102 | </para> | ||
103 | |||
104 | <para> | ||
105 | I'd like to thank Jeff Garzik | ||
106 | <email>jgarzik@pobox.com</email> and Alexander Viro | ||
107 | <email>viro@parcelfarce.linux.theplanet.co.uk</email> for their input, | ||
108 | Tim Waugh <email>twaugh@redhat.com</email> for his <ulink | ||
109 | url="http://people.redhat.com/twaugh/docbook/selfdocbook/">Selfdocbook</ulink>, | ||
110 | and Marc Joosen <email>marcj@historia.et.tudelft.nl</email> for | ||
111 | proofreading. | ||
112 | </para> | ||
113 | |||
114 | <para> | ||
115 | Erik | ||
116 | </para> | ||
117 | </preface> | ||
118 | |||
119 | |||
120 | |||
121 | |||
122 | <chapter id="intro"> | ||
123 | <title>Introduction</title> | ||
124 | |||
125 | <para> | ||
126 | The <filename class="directory">/proc</filename> file system | ||
127 | (procfs) is a special file system in the linux kernel. It's a | ||
128 | virtual file system: it is not associated with a block device | ||
129 | but exists only in memory. The files in the procfs are there to | ||
130 | allow userland programs access to certain information from the | ||
131 | kernel (like process information in <filename | ||
132 | class="directory">/proc/[0-9]+/</filename>), but also for debug | ||
133 | purposes (like <filename>/proc/ksyms</filename>). | ||
134 | </para> | ||
135 | |||
136 | <para> | ||
137 | This guide describes the use of the procfs file system from | ||
138 | within the Linux kernel. It starts by introducing all relevant | ||
139 | functions to manage the files within the file system. After that | ||
140 | it shows how to communicate with userland, and some tips and | ||
141 | tricks will be pointed out. Finally a complete example will be | ||
142 | shown. | ||
143 | </para> | ||
144 | |||
145 | <para> | ||
146 | Note that the files in <filename | ||
147 | class="directory">/proc/sys</filename> are sysctl files: they | ||
148 | don't belong to procfs and are governed by a completely | ||
149 | different API described in the Kernel API book. | ||
150 | </para> | ||
151 | </chapter> | ||
152 | |||
153 | |||
154 | |||
155 | |||
156 | <chapter id="managing"> | ||
157 | <title>Managing procfs entries</title> | ||
158 | |||
159 | <para> | ||
160 | This chapter describes the functions that various kernel | ||
161 | components use to populate the procfs with files, symlinks, | ||
162 | device nodes, and directories. | ||
163 | </para> | ||
164 | |||
165 | <para> | ||
166 | A minor note before we start: if you want to use any of the | ||
167 | procfs functions, be sure to include the correct header file! | ||
168 | This should be one of the first lines in your code: | ||
169 | </para> | ||
170 | |||
171 | <programlisting> | ||
172 | #include <linux/proc_fs.h> | ||
173 | </programlisting> | ||
174 | |||
175 | |||
176 | |||
177 | |||
178 | <sect1 id="regularfile"> | ||
179 | <title>Creating a regular file</title> | ||
180 | |||
181 | <funcsynopsis> | ||
182 | <funcprototype> | ||
183 | <funcdef>struct proc_dir_entry* <function>create_proc_entry</function></funcdef> | ||
184 | <paramdef>const char* <parameter>name</parameter></paramdef> | ||
185 | <paramdef>mode_t <parameter>mode</parameter></paramdef> | ||
186 | <paramdef>struct proc_dir_entry* <parameter>parent</parameter></paramdef> | ||
187 | </funcprototype> | ||
188 | </funcsynopsis> | ||
189 | |||
190 | <para> | ||
191 | This function creates a regular file with the name | ||
192 | <parameter>name</parameter>, file mode | ||
193 | <parameter>mode</parameter> in the directory | ||
194 | <parameter>parent</parameter>. To create a file in the root of | ||
195 | the procfs, use <constant>NULL</constant> as | ||
196 | <parameter>parent</parameter> parameter. When successful, the | ||
197 | function will return a pointer to the freshly created | ||
198 | <structname>struct proc_dir_entry</structname>; otherwise it | ||
199 | will return <constant>NULL</constant>. <xref | ||
200 | linkend="userland"/> describes how to do something useful with | ||
201 | regular files. | ||
202 | </para> | ||
203 | |||
204 | <para> | ||
205 | Note that it is specifically supported that you can pass a | ||
206 | path that spans multiple directories. For example | ||
207 | <function>create_proc_entry</function>(<parameter>"drivers/via0/info"</parameter>) | ||
208 | will create the <filename class="directory">via0</filename> | ||
209 | directory if necessary, with standard | ||
210 | <constant>0755</constant> permissions. | ||
211 | </para> | ||
212 | |||
213 | <para> | ||
214 | If you only want to be able to read the file, the function | ||
215 | <function>create_proc_read_entry</function> described in <xref | ||
216 | linkend="convenience"/> may be used to create and initialise | ||
217 | the procfs entry in one single call. | ||
218 | </para> | ||
219 | </sect1> | ||
220 | |||
221 | |||
222 | |||
223 | |||
224 | <sect1 id="Creating_a_symlink"> | ||
225 | <title>Creating a symlink</title> | ||
226 | |||
227 | <funcsynopsis> | ||
228 | <funcprototype> | ||
229 | <funcdef>struct proc_dir_entry* | ||
230 | <function>proc_symlink</function></funcdef> <paramdef>const | ||
231 | char* <parameter>name</parameter></paramdef> | ||
232 | <paramdef>struct proc_dir_entry* | ||
233 | <parameter>parent</parameter></paramdef> <paramdef>const | ||
234 | char* <parameter>dest</parameter></paramdef> | ||
235 | </funcprototype> | ||
236 | </funcsynopsis> | ||
237 | |||
238 | <para> | ||
239 | This creates a symlink in the procfs directory | ||
240 | <parameter>parent</parameter> that points from | ||
241 | <parameter>name</parameter> to | ||
242 | <parameter>dest</parameter>. This translates in userland to | ||
243 | <literal>ln -s</literal> <parameter>dest</parameter> | ||
244 | <parameter>name</parameter>. | ||
245 | </para> | ||
246 | </sect1> | ||
247 | |||
248 | <sect1 id="Creating_a_directory"> | ||
249 | <title>Creating a directory</title> | ||
250 | |||
251 | <funcsynopsis> | ||
252 | <funcprototype> | ||
253 | <funcdef>struct proc_dir_entry* <function>proc_mkdir</function></funcdef> | ||
254 | <paramdef>const char* <parameter>name</parameter></paramdef> | ||
255 | <paramdef>struct proc_dir_entry* <parameter>parent</parameter></paramdef> | ||
256 | </funcprototype> | ||
257 | </funcsynopsis> | ||
258 | |||
259 | <para> | ||
260 | Create a directory <parameter>name</parameter> in the procfs | ||
261 | directory <parameter>parent</parameter>. | ||
262 | </para> | ||
263 | </sect1> | ||
264 | |||
265 | |||
266 | |||
267 | |||
268 | <sect1 id="Removing_an_entry"> | ||
269 | <title>Removing an entry</title> | ||
270 | |||
271 | <funcsynopsis> | ||
272 | <funcprototype> | ||
273 | <funcdef>void <function>remove_proc_entry</function></funcdef> | ||
274 | <paramdef>const char* <parameter>name</parameter></paramdef> | ||
275 | <paramdef>struct proc_dir_entry* <parameter>parent</parameter></paramdef> | ||
276 | </funcprototype> | ||
277 | </funcsynopsis> | ||
278 | |||
279 | <para> | ||
280 | Removes the entry <parameter>name</parameter> in the directory | ||
281 | <parameter>parent</parameter> from the procfs. Entries are | ||
282 | removed by their <emphasis>name</emphasis>, not by the | ||
283 | <structname>struct proc_dir_entry</structname> returned by the | ||
284 | various create functions. Note that this function doesn't | ||
285 | recursively remove entries. | ||
286 | </para> | ||
287 | |||
288 | <para> | ||
289 | Be sure to free the <structfield>data</structfield> entry from | ||
290 | the <structname>struct proc_dir_entry</structname> before | ||
291 | <function>remove_proc_entry</function> is called (that is: if | ||
292 | there was some <structfield>data</structfield> allocated, of | ||
293 | course). See <xref linkend="usingdata"/> for more information | ||
294 | on using the <structfield>data</structfield> entry. | ||
295 | </para> | ||
296 | </sect1> | ||
297 | </chapter> | ||
298 | |||
299 | |||
300 | |||
301 | |||
302 | <chapter id="userland"> | ||
303 | <title>Communicating with userland</title> | ||
304 | |||
305 | <para> | ||
306 | Instead of reading (or writing) information directly from | ||
307 | kernel memory, procfs works with <emphasis>call back | ||
308 | functions</emphasis> for files: functions that are called when | ||
309 | a specific file is being read or written. Such functions have | ||
310 | to be initialised after the procfs file is created by setting | ||
311 | the <structfield>read_proc</structfield> and/or | ||
312 | <structfield>write_proc</structfield> fields in the | ||
313 | <structname>struct proc_dir_entry*</structname> that the | ||
314 | function <function>create_proc_entry</function> returned: | ||
315 | </para> | ||
316 | |||
317 | <programlisting> | ||
318 | struct proc_dir_entry* entry; | ||
319 | |||
320 | entry->read_proc = read_proc_foo; | ||
321 | entry->write_proc = write_proc_foo; | ||
322 | </programlisting> | ||
323 | |||
324 | <para> | ||
325 | If you only want to use a the | ||
326 | <structfield>read_proc</structfield>, the function | ||
327 | <function>create_proc_read_entry</function> described in <xref | ||
328 | linkend="convenience"/> may be used to create and initialise the | ||
329 | procfs entry in one single call. | ||
330 | </para> | ||
331 | |||
332 | |||
333 | |||
334 | <sect1 id="Reading_data"> | ||
335 | <title>Reading data</title> | ||
336 | |||
337 | <para> | ||
338 | The read function is a call back function that allows userland | ||
339 | processes to read data from the kernel. The read function | ||
340 | should have the following format: | ||
341 | </para> | ||
342 | |||
343 | <funcsynopsis> | ||
344 | <funcprototype> | ||
345 | <funcdef>int <function>read_func</function></funcdef> | ||
346 | <paramdef>char* <parameter>buffer</parameter></paramdef> | ||
347 | <paramdef>char** <parameter>start</parameter></paramdef> | ||
348 | <paramdef>off_t <parameter>off</parameter></paramdef> | ||
349 | <paramdef>int <parameter>count</parameter></paramdef> | ||
350 | <paramdef>int* <parameter>peof</parameter></paramdef> | ||
351 | <paramdef>void* <parameter>data</parameter></paramdef> | ||
352 | </funcprototype> | ||
353 | </funcsynopsis> | ||
354 | |||
355 | <para> | ||
356 | The read function should write its information into the | ||
357 | <parameter>buffer</parameter>, which will be exactly | ||
358 | <literal>PAGE_SIZE</literal> bytes long. | ||
359 | </para> | ||
360 | |||
361 | <para> | ||
362 | The parameter | ||
363 | <parameter>peof</parameter> should be used to signal that the | ||
364 | end of the file has been reached by writing | ||
365 | <literal>1</literal> to the memory location | ||
366 | <parameter>peof</parameter> points to. | ||
367 | </para> | ||
368 | |||
369 | <para> | ||
370 | The <parameter>data</parameter> | ||
371 | parameter can be used to create a single call back function for | ||
372 | several files, see <xref linkend="usingdata"/>. | ||
373 | </para> | ||
374 | |||
375 | <para> | ||
376 | The rest of the parameters and the return value are described | ||
377 | by a comment in <filename>fs/proc/generic.c</filename> as follows: | ||
378 | </para> | ||
379 | |||
380 | <blockquote> | ||
381 | <para> | ||
382 | You have three ways to return data: | ||
383 | </para> | ||
384 | <orderedlist> | ||
385 | <listitem> | ||
386 | <para> | ||
387 | Leave <literal>*start = NULL</literal>. (This is the default.) | ||
388 | Put the data of the requested offset at that | ||
389 | offset within the buffer. Return the number (<literal>n</literal>) | ||
390 | of bytes there are from the beginning of the | ||
391 | buffer up to the last byte of data. If the | ||
392 | number of supplied bytes (<literal>= n - offset</literal>) is | ||
393 | greater than zero and you didn't signal eof | ||
394 | and the reader is prepared to take more data | ||
395 | you will be called again with the requested | ||
396 | offset advanced by the number of bytes | ||
397 | absorbed. This interface is useful for files | ||
398 | no larger than the buffer. | ||
399 | </para> | ||
400 | </listitem> | ||
401 | <listitem> | ||
402 | <para> | ||
403 | Set <literal>*start</literal> to an unsigned long value less than | ||
404 | the buffer address but greater than zero. | ||
405 | Put the data of the requested offset at the | ||
406 | beginning of the buffer. Return the number of | ||
407 | bytes of data placed there. If this number is | ||
408 | greater than zero and you didn't signal eof | ||
409 | and the reader is prepared to take more data | ||
410 | you will be called again with the requested | ||
411 | offset advanced by <literal>*start</literal>. This interface is | ||
412 | useful when you have a large file consisting | ||
413 | of a series of blocks which you want to count | ||
414 | and return as wholes. | ||
415 | (Hack by Paul.Russell@rustcorp.com.au) | ||
416 | </para> | ||
417 | </listitem> | ||
418 | <listitem> | ||
419 | <para> | ||
420 | Set <literal>*start</literal> to an address within the buffer. | ||
421 | Put the data of the requested offset at <literal>*start</literal>. | ||
422 | Return the number of bytes of data placed there. | ||
423 | If this number is greater than zero and you | ||
424 | didn't signal eof and the reader is prepared to | ||
425 | take more data you will be called again with the | ||
426 | requested offset advanced by the number of bytes | ||
427 | absorbed. | ||
428 | </para> | ||
429 | </listitem> | ||
430 | </orderedlist> | ||
431 | </blockquote> | ||
432 | |||
433 | <para> | ||
434 | <xref linkend="example"/> shows how to use a read call back | ||
435 | function. | ||
436 | </para> | ||
437 | </sect1> | ||
438 | |||
439 | |||
440 | |||
441 | |||
442 | <sect1 id="Writing_data"> | ||
443 | <title>Writing data</title> | ||
444 | |||
445 | <para> | ||
446 | The write call back function allows a userland process to write | ||
447 | data to the kernel, so it has some kind of control over the | ||
448 | kernel. The write function should have the following format: | ||
449 | </para> | ||
450 | |||
451 | <funcsynopsis> | ||
452 | <funcprototype> | ||
453 | <funcdef>int <function>write_func</function></funcdef> | ||
454 | <paramdef>struct file* <parameter>file</parameter></paramdef> | ||
455 | <paramdef>const char* <parameter>buffer</parameter></paramdef> | ||
456 | <paramdef>unsigned long <parameter>count</parameter></paramdef> | ||
457 | <paramdef>void* <parameter>data</parameter></paramdef> | ||
458 | </funcprototype> | ||
459 | </funcsynopsis> | ||
460 | |||
461 | <para> | ||
462 | The write function should read <parameter>count</parameter> | ||
463 | bytes at maximum from the <parameter>buffer</parameter>. Note | ||
464 | that the <parameter>buffer</parameter> doesn't live in the | ||
465 | kernel's memory space, so it should first be copied to kernel | ||
466 | space with <function>copy_from_user</function>. The | ||
467 | <parameter>file</parameter> parameter is usually | ||
468 | ignored. <xref linkend="usingdata"/> shows how to use the | ||
469 | <parameter>data</parameter> parameter. | ||
470 | </para> | ||
471 | |||
472 | <para> | ||
473 | Again, <xref linkend="example"/> shows how to use this call back | ||
474 | function. | ||
475 | </para> | ||
476 | </sect1> | ||
477 | |||
478 | |||
479 | |||
480 | |||
481 | <sect1 id="usingdata"> | ||
482 | <title>A single call back for many files</title> | ||
483 | |||
484 | <para> | ||
485 | When a large number of almost identical files is used, it's | ||
486 | quite inconvenient to use a separate call back function for | ||
487 | each file. A better approach is to have a single call back | ||
488 | function that distinguishes between the files by using the | ||
489 | <structfield>data</structfield> field in <structname>struct | ||
490 | proc_dir_entry</structname>. First of all, the | ||
491 | <structfield>data</structfield> field has to be initialised: | ||
492 | </para> | ||
493 | |||
494 | <programlisting> | ||
495 | struct proc_dir_entry* entry; | ||
496 | struct my_file_data *file_data; | ||
497 | |||
498 | file_data = kmalloc(sizeof(struct my_file_data), GFP_KERNEL); | ||
499 | entry->data = file_data; | ||
500 | </programlisting> | ||
501 | |||
502 | <para> | ||
503 | The <structfield>data</structfield> field is a <type>void | ||
504 | *</type>, so it can be initialised with anything. | ||
505 | </para> | ||
506 | |||
507 | <para> | ||
508 | Now that the <structfield>data</structfield> field is set, the | ||
509 | <function>read_proc</function> and | ||
510 | <function>write_proc</function> can use it to distinguish | ||
511 | between files because they get it passed into their | ||
512 | <parameter>data</parameter> parameter: | ||
513 | </para> | ||
514 | |||
515 | <programlisting> | ||
516 | int foo_read_func(char *page, char **start, off_t off, | ||
517 | int count, int *eof, void *data) | ||
518 | { | ||
519 | int len; | ||
520 | |||
521 | if(data == file_data) { | ||
522 | /* special case for this file */ | ||
523 | } else { | ||
524 | /* normal processing */ | ||
525 | } | ||
526 | |||
527 | return len; | ||
528 | } | ||
529 | </programlisting> | ||
530 | |||
531 | <para> | ||
532 | Be sure to free the <structfield>data</structfield> data field | ||
533 | when removing the procfs entry. | ||
534 | </para> | ||
535 | </sect1> | ||
536 | </chapter> | ||
537 | |||
538 | |||
539 | |||
540 | |||
541 | <chapter id="tips"> | ||
542 | <title>Tips and tricks</title> | ||
543 | |||
544 | |||
545 | |||
546 | |||
547 | <sect1 id="convenience"> | ||
548 | <title>Convenience functions</title> | ||
549 | |||
550 | <funcsynopsis> | ||
551 | <funcprototype> | ||
552 | <funcdef>struct proc_dir_entry* <function>create_proc_read_entry</function></funcdef> | ||
553 | <paramdef>const char* <parameter>name</parameter></paramdef> | ||
554 | <paramdef>mode_t <parameter>mode</parameter></paramdef> | ||
555 | <paramdef>struct proc_dir_entry* <parameter>parent</parameter></paramdef> | ||
556 | <paramdef>read_proc_t* <parameter>read_proc</parameter></paramdef> | ||
557 | <paramdef>void* <parameter>data</parameter></paramdef> | ||
558 | </funcprototype> | ||
559 | </funcsynopsis> | ||
560 | |||
561 | <para> | ||
562 | This function creates a regular file in exactly the same way | ||
563 | as <function>create_proc_entry</function> from <xref | ||
564 | linkend="regularfile"/> does, but also allows to set the read | ||
565 | function <parameter>read_proc</parameter> in one call. This | ||
566 | function can set the <parameter>data</parameter> as well, like | ||
567 | explained in <xref linkend="usingdata"/>. | ||
568 | </para> | ||
569 | </sect1> | ||
570 | |||
571 | |||
572 | |||
573 | <sect1 id="Modules"> | ||
574 | <title>Modules</title> | ||
575 | |||
576 | <para> | ||
577 | If procfs is being used from within a module, be sure to set | ||
578 | the <structfield>owner</structfield> field in the | ||
579 | <structname>struct proc_dir_entry</structname> to | ||
580 | <constant>THIS_MODULE</constant>. | ||
581 | </para> | ||
582 | |||
583 | <programlisting> | ||
584 | struct proc_dir_entry* entry; | ||
585 | |||
586 | entry->owner = THIS_MODULE; | ||
587 | </programlisting> | ||
588 | </sect1> | ||
589 | |||
590 | |||
591 | |||
592 | |||
593 | <sect1 id="Mode_and_ownership"> | ||
594 | <title>Mode and ownership</title> | ||
595 | |||
596 | <para> | ||
597 | Sometimes it is useful to change the mode and/or ownership of | ||
598 | a procfs entry. Here is an example that shows how to achieve | ||
599 | that: | ||
600 | </para> | ||
601 | |||
602 | <programlisting> | ||
603 | struct proc_dir_entry* entry; | ||
604 | |||
605 | entry->mode = S_IWUSR |S_IRUSR | S_IRGRP | S_IROTH; | ||
606 | entry->uid = 0; | ||
607 | entry->gid = 100; | ||
608 | </programlisting> | ||
609 | |||
610 | </sect1> | ||
611 | </chapter> | ||
612 | |||
613 | |||
614 | |||
615 | |||
616 | <chapter id="example"> | ||
617 | <title>Example</title> | ||
618 | |||
619 | <!-- be careful with the example code: it shouldn't be wider than | ||
620 | approx. 60 columns, or otherwise it won't fit properly on a page | ||
621 | --> | ||
622 | |||
623 | &procfsexample; | ||
624 | |||
625 | </chapter> | ||
626 | </book> | ||
diff --git a/Documentation/DocBook/procfs_example.c b/Documentation/DocBook/procfs_example.c deleted file mode 100644 index a5b11793b1e0..000000000000 --- a/Documentation/DocBook/procfs_example.c +++ /dev/null | |||
@@ -1,201 +0,0 @@ | |||
1 | /* | ||
2 | * procfs_example.c: an example proc interface | ||
3 | * | ||
4 | * Copyright (C) 2001, Erik Mouw (mouw@nl.linux.org) | ||
5 | * | ||
6 | * This file accompanies the procfs-guide in the Linux kernel | ||
7 | * source. Its main use is to demonstrate the concepts and | ||
8 | * functions described in the guide. | ||
9 | * | ||
10 | * This software has been developed while working on the LART | ||
11 | * computing board (http://www.lartmaker.nl), which was sponsored | ||
12 | * by the Delt University of Technology projects Mobile Multi-media | ||
13 | * Communications and Ubiquitous Communications. | ||
14 | * | ||
15 | * This program is free software; you can redistribute | ||
16 | * it and/or modify it under the terms of the GNU General | ||
17 | * Public License as published by the Free Software | ||
18 | * Foundation; either version 2 of the License, or (at your | ||
19 | * option) any later version. | ||
20 | * | ||
21 | * This program is distributed in the hope that it will be | ||
22 | * useful, but WITHOUT ANY WARRANTY; without even the implied | ||
23 | * warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR | ||
24 | * PURPOSE. See the GNU General Public License for more | ||
25 | * details. | ||
26 | * | ||
27 | * You should have received a copy of the GNU General Public | ||
28 | * License along with this program; if not, write to the | ||
29 | * Free Software Foundation, Inc., 59 Temple Place, | ||
30 | * Suite 330, Boston, MA 02111-1307 USA | ||
31 | * | ||
32 | */ | ||
33 | |||
34 | #include <linux/module.h> | ||
35 | #include <linux/kernel.h> | ||
36 | #include <linux/init.h> | ||
37 | #include <linux/proc_fs.h> | ||
38 | #include <linux/jiffies.h> | ||
39 | #include <asm/uaccess.h> | ||
40 | |||
41 | |||
42 | #define MODULE_VERS "1.0" | ||
43 | #define MODULE_NAME "procfs_example" | ||
44 | |||
45 | #define FOOBAR_LEN 8 | ||
46 | |||
47 | struct fb_data_t { | ||
48 | char name[FOOBAR_LEN + 1]; | ||
49 | char value[FOOBAR_LEN + 1]; | ||
50 | }; | ||
51 | |||
52 | |||
53 | static struct proc_dir_entry *example_dir, *foo_file, | ||
54 | *bar_file, *jiffies_file, *symlink; | ||
55 | |||
56 | |||
57 | struct fb_data_t foo_data, bar_data; | ||
58 | |||
59 | |||
60 | static int proc_read_jiffies(char *page, char **start, | ||
61 | off_t off, int count, | ||
62 | int *eof, void *data) | ||
63 | { | ||
64 | int len; | ||
65 | |||
66 | len = sprintf(page, "jiffies = %ld\n", | ||
67 | jiffies); | ||
68 | |||
69 | return len; | ||
70 | } | ||
71 | |||
72 | |||
73 | static int proc_read_foobar(char *page, char **start, | ||
74 | off_t off, int count, | ||
75 | int *eof, void *data) | ||
76 | { | ||
77 | int len; | ||
78 | struct fb_data_t *fb_data = (struct fb_data_t *)data; | ||
79 | |||
80 | /* DON'T DO THAT - buffer overruns are bad */ | ||
81 | len = sprintf(page, "%s = '%s'\n", | ||
82 | fb_data->name, fb_data->value); | ||
83 | |||
84 | return len; | ||
85 | } | ||
86 | |||
87 | |||
88 | static int proc_write_foobar(struct file *file, | ||
89 | const char *buffer, | ||
90 | unsigned long count, | ||
91 | void *data) | ||
92 | { | ||
93 | int len; | ||
94 | struct fb_data_t *fb_data = (struct fb_data_t *)data; | ||
95 | |||
96 | if(count > FOOBAR_LEN) | ||
97 | len = FOOBAR_LEN; | ||
98 | else | ||
99 | len = count; | ||
100 | |||
101 | if(copy_from_user(fb_data->value, buffer, len)) | ||
102 | return -EFAULT; | ||
103 | |||
104 | fb_data->value[len] = '\0'; | ||
105 | |||
106 | return len; | ||
107 | } | ||
108 | |||
109 | |||
110 | static int __init init_procfs_example(void) | ||
111 | { | ||
112 | int rv = 0; | ||
113 | |||
114 | /* create directory */ | ||
115 | example_dir = proc_mkdir(MODULE_NAME, NULL); | ||
116 | if(example_dir == NULL) { | ||
117 | rv = -ENOMEM; | ||
118 | goto out; | ||
119 | } | ||
120 | /* create jiffies using convenience function */ | ||
121 | jiffies_file = create_proc_read_entry("jiffies", | ||
122 | 0444, example_dir, | ||
123 | proc_read_jiffies, | ||
124 | NULL); | ||
125 | if(jiffies_file == NULL) { | ||
126 | rv = -ENOMEM; | ||
127 | goto no_jiffies; | ||
128 | } | ||
129 | |||
130 | /* create foo and bar files using same callback | ||
131 | * functions | ||
132 | */ | ||
133 | foo_file = create_proc_entry("foo", 0644, example_dir); | ||
134 | if(foo_file == NULL) { | ||
135 | rv = -ENOMEM; | ||
136 | goto no_foo; | ||
137 | } | ||
138 | |||
139 | strcpy(foo_data.name, "foo"); | ||
140 | strcpy(foo_data.value, "foo"); | ||
141 | foo_file->data = &foo_data; | ||
142 | foo_file->read_proc = proc_read_foobar; | ||
143 | foo_file->write_proc = proc_write_foobar; | ||
144 | |||
145 | bar_file = create_proc_entry("bar", 0644, example_dir); | ||
146 | if(bar_file == NULL) { | ||
147 | rv = -ENOMEM; | ||
148 | goto no_bar; | ||
149 | } | ||
150 | |||
151 | strcpy(bar_data.name, "bar"); | ||
152 | strcpy(bar_data.value, "bar"); | ||
153 | bar_file->data = &bar_data; | ||
154 | bar_file->read_proc = proc_read_foobar; | ||
155 | bar_file->write_proc = proc_write_foobar; | ||
156 | |||
157 | /* create symlink */ | ||
158 | symlink = proc_symlink("jiffies_too", example_dir, | ||
159 | "jiffies"); | ||
160 | if(symlink == NULL) { | ||
161 | rv = -ENOMEM; | ||
162 | goto no_symlink; | ||
163 | } | ||
164 | |||
165 | /* everything OK */ | ||
166 | printk(KERN_INFO "%s %s initialised\n", | ||
167 | MODULE_NAME, MODULE_VERS); | ||
168 | return 0; | ||
169 | |||
170 | no_symlink: | ||
171 | remove_proc_entry("bar", example_dir); | ||
172 | no_bar: | ||
173 | remove_proc_entry("foo", example_dir); | ||
174 | no_foo: | ||
175 | remove_proc_entry("jiffies", example_dir); | ||
176 | no_jiffies: | ||
177 | remove_proc_entry(MODULE_NAME, NULL); | ||
178 | out: | ||
179 | return rv; | ||
180 | } | ||
181 | |||
182 | |||
183 | static void __exit cleanup_procfs_example(void) | ||
184 | { | ||
185 | remove_proc_entry("jiffies_too", example_dir); | ||
186 | remove_proc_entry("bar", example_dir); | ||
187 | remove_proc_entry("foo", example_dir); | ||
188 | remove_proc_entry("jiffies", example_dir); | ||
189 | remove_proc_entry(MODULE_NAME, NULL); | ||
190 | |||
191 | printk(KERN_INFO "%s %s removed\n", | ||
192 | MODULE_NAME, MODULE_VERS); | ||
193 | } | ||
194 | |||
195 | |||
196 | module_init(init_procfs_example); | ||
197 | module_exit(cleanup_procfs_example); | ||
198 | |||
199 | MODULE_AUTHOR("Erik Mouw"); | ||
200 | MODULE_DESCRIPTION("procfs examples"); | ||
201 | MODULE_LICENSE("GPL"); | ||
diff --git a/Documentation/DocBook/v4l/common.xml b/Documentation/DocBook/v4l/common.xml index b1a81d246d58..c65f0ac9b6ee 100644 --- a/Documentation/DocBook/v4l/common.xml +++ b/Documentation/DocBook/v4l/common.xml | |||
@@ -716,6 +716,41 @@ if (-1 == ioctl (fd, &VIDIOC-S-STD;, &std_id)) { | |||
716 | } | 716 | } |
717 | </programlisting> | 717 | </programlisting> |
718 | </example> | 718 | </example> |
719 | <section id="dv-timings"> | ||
720 | <title>Digital Video (DV) Timings</title> | ||
721 | <para> | ||
722 | The video standards discussed so far has been dealing with Analog TV and the | ||
723 | corresponding video timings. Today there are many more different hardware interfaces | ||
724 | such as High Definition TV interfaces (HDMI), VGA, DVI connectors etc., that carry | ||
725 | video signals and there is a need to extend the API to select the video timings | ||
726 | for these interfaces. Since it is not possible to extend the &v4l2-std-id; due to | ||
727 | the limited bits available, a new set of IOCTLs is added to set/get video timings at | ||
728 | the input and output: </para><itemizedlist> | ||
729 | <listitem> | ||
730 | <para>DV Presets: Digital Video (DV) presets. These are IDs representing a | ||
731 | video timing at the input/output. Presets are pre-defined timings implemented | ||
732 | by the hardware according to video standards. A __u32 data type is used to represent | ||
733 | a preset unlike the bit mask that is used in &v4l2-std-id; allowing future extensions | ||
734 | to support as many different presets as needed.</para> | ||
735 | </listitem> | ||
736 | <listitem> | ||
737 | <para>Custom DV Timings: This will allow applications to define more detailed | ||
738 | custom video timings for the interface. This includes parameters such as width, height, | ||
739 | polarities, frontporch, backporch etc. | ||
740 | </para> | ||
741 | </listitem> | ||
742 | </itemizedlist> | ||
743 | <para>To enumerate and query the attributes of DV presets supported by a device, | ||
744 | applications use the &VIDIOC-ENUM-DV-PRESETS; ioctl. To get the current DV preset, | ||
745 | applications use the &VIDIOC-G-DV-PRESET; ioctl and to set a preset they use the | ||
746 | &VIDIOC-S-DV-PRESET; ioctl.</para> | ||
747 | <para>To set custom DV timings for the device, applications use the | ||
748 | &VIDIOC-S-DV-TIMINGS; ioctl and to get current custom DV timings they use the | ||
749 | &VIDIOC-G-DV-TIMINGS; ioctl.</para> | ||
750 | <para>Applications can make use of the <xref linkend="input-capabilities" /> and | ||
751 | <xref linkend="output-capabilities"/> flags to decide what ioctls are available to set the | ||
752 | video timings for the device.</para> | ||
753 | </section> | ||
719 | </section> | 754 | </section> |
720 | 755 | ||
721 | &sub-controls; | 756 | &sub-controls; |
diff --git a/Documentation/DocBook/v4l/compat.xml b/Documentation/DocBook/v4l/compat.xml index 4d1902a54d61..b9dbdf9e6d29 100644 --- a/Documentation/DocBook/v4l/compat.xml +++ b/Documentation/DocBook/v4l/compat.xml | |||
@@ -2291,8 +2291,8 @@ was renamed to <structname id="v4l2-chip-ident-old">v4l2_chip_ident_old</structn | |||
2291 | <listitem> | 2291 | <listitem> |
2292 | <para>New control <constant>V4L2_CID_COLORFX</constant> was added.</para> | 2292 | <para>New control <constant>V4L2_CID_COLORFX</constant> was added.</para> |
2293 | </listitem> | 2293 | </listitem> |
2294 | </orderedlist> | 2294 | </orderedlist> |
2295 | </section> | 2295 | </section> |
2296 | <section> | 2296 | <section> |
2297 | <title>V4L2 in Linux 2.6.32</title> | 2297 | <title>V4L2 in Linux 2.6.32</title> |
2298 | <orderedlist> | 2298 | <orderedlist> |
@@ -2322,8 +2322,16 @@ more information.</para> | |||
2322 | <listitem> | 2322 | <listitem> |
2323 | <para>Added Remote Controller chapter, describing the default Remote Controller mapping for media devices.</para> | 2323 | <para>Added Remote Controller chapter, describing the default Remote Controller mapping for media devices.</para> |
2324 | </listitem> | 2324 | </listitem> |
2325 | </orderedlist> | 2325 | </orderedlist> |
2326 | </section> | 2326 | </section> |
2327 | <section> | ||
2328 | <title>V4L2 in Linux 2.6.33</title> | ||
2329 | <orderedlist> | ||
2330 | <listitem> | ||
2331 | <para>Added support for Digital Video timings in order to support HDTV receivers and transmitters.</para> | ||
2332 | </listitem> | ||
2333 | </orderedlist> | ||
2334 | </section> | ||
2327 | </section> | 2335 | </section> |
2328 | 2336 | ||
2329 | <section id="other"> | 2337 | <section id="other"> |
diff --git a/Documentation/DocBook/v4l/v4l2.xml b/Documentation/DocBook/v4l/v4l2.xml index 937b4157a5d0..060105af49e5 100644 --- a/Documentation/DocBook/v4l/v4l2.xml +++ b/Documentation/DocBook/v4l/v4l2.xml | |||
@@ -74,6 +74,17 @@ Remote Controller chapter.</contrib> | |||
74 | </address> | 74 | </address> |
75 | </affiliation> | 75 | </affiliation> |
76 | </author> | 76 | </author> |
77 | |||
78 | <author> | ||
79 | <firstname>Muralidharan</firstname> | ||
80 | <surname>Karicheri</surname> | ||
81 | <contrib>Documented the Digital Video timings API.</contrib> | ||
82 | <affiliation> | ||
83 | <address> | ||
84 | <email>m-karicheri2@ti.com</email> | ||
85 | </address> | ||
86 | </affiliation> | ||
87 | </author> | ||
77 | </authorgroup> | 88 | </authorgroup> |
78 | 89 | ||
79 | <copyright> | 90 | <copyright> |
@@ -89,7 +100,7 @@ Remote Controller chapter.</contrib> | |||
89 | <year>2008</year> | 100 | <year>2008</year> |
90 | <year>2009</year> | 101 | <year>2009</year> |
91 | <holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin | 102 | <holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin |
92 | Rubli, Andy Walls, Mauro Carvalho Chehab</holder> | 103 | Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab</holder> |
93 | </copyright> | 104 | </copyright> |
94 | <legalnotice> | 105 | <legalnotice> |
95 | <para>Except when explicitly stated as GPL, programming examples within | 106 | <para>Except when explicitly stated as GPL, programming examples within |
@@ -103,6 +114,13 @@ structs, ioctls) must be noted in more detail in the history chapter | |||
103 | applications. --> | 114 | applications. --> |
104 | 115 | ||
105 | <revision> | 116 | <revision> |
117 | <revnumber>2.6.33</revnumber> | ||
118 | <date>2009-12-03</date> | ||
119 | <authorinitials>mk</authorinitials> | ||
120 | <revremark>Added documentation for the Digital Video timings API.</revremark> | ||
121 | </revision> | ||
122 | |||
123 | <revision> | ||
106 | <revnumber>2.6.32</revnumber> | 124 | <revnumber>2.6.32</revnumber> |
107 | <date>2009-08-31</date> | 125 | <date>2009-08-31</date> |
108 | <authorinitials>mcc</authorinitials> | 126 | <authorinitials>mcc</authorinitials> |
@@ -355,7 +373,7 @@ and discussions on the V4L mailing list.</revremark> | |||
355 | </partinfo> | 373 | </partinfo> |
356 | 374 | ||
357 | <title>Video for Linux Two API Specification</title> | 375 | <title>Video for Linux Two API Specification</title> |
358 | <subtitle>Revision 2.6.32</subtitle> | 376 | <subtitle>Revision 2.6.33</subtitle> |
359 | 377 | ||
360 | <chapter id="common"> | 378 | <chapter id="common"> |
361 | &sub-common; | 379 | &sub-common; |
@@ -411,6 +429,7 @@ and discussions on the V4L mailing list.</revremark> | |||
411 | &sub-encoder-cmd; | 429 | &sub-encoder-cmd; |
412 | &sub-enumaudio; | 430 | &sub-enumaudio; |
413 | &sub-enumaudioout; | 431 | &sub-enumaudioout; |
432 | &sub-enum-dv-presets; | ||
414 | &sub-enum-fmt; | 433 | &sub-enum-fmt; |
415 | &sub-enum-framesizes; | 434 | &sub-enum-framesizes; |
416 | &sub-enum-frameintervals; | 435 | &sub-enum-frameintervals; |
@@ -421,6 +440,8 @@ and discussions on the V4L mailing list.</revremark> | |||
421 | &sub-g-audioout; | 440 | &sub-g-audioout; |
422 | &sub-g-crop; | 441 | &sub-g-crop; |
423 | &sub-g-ctrl; | 442 | &sub-g-ctrl; |
443 | &sub-g-dv-preset; | ||
444 | &sub-g-dv-timings; | ||
424 | &sub-g-enc-index; | 445 | &sub-g-enc-index; |
425 | &sub-g-ext-ctrls; | 446 | &sub-g-ext-ctrls; |
426 | &sub-g-fbuf; | 447 | &sub-g-fbuf; |
@@ -441,6 +462,7 @@ and discussions on the V4L mailing list.</revremark> | |||
441 | &sub-querybuf; | 462 | &sub-querybuf; |
442 | &sub-querycap; | 463 | &sub-querycap; |
443 | &sub-queryctrl; | 464 | &sub-queryctrl; |
465 | &sub-query-dv-preset; | ||
444 | &sub-querystd; | 466 | &sub-querystd; |
445 | &sub-reqbufs; | 467 | &sub-reqbufs; |
446 | &sub-s-hw-freq-seek; | 468 | &sub-s-hw-freq-seek; |
diff --git a/Documentation/DocBook/v4l/videodev2.h.xml b/Documentation/DocBook/v4l/videodev2.h.xml index 3e282ed9f593..068325940658 100644 --- a/Documentation/DocBook/v4l/videodev2.h.xml +++ b/Documentation/DocBook/v4l/videodev2.h.xml | |||
@@ -734,6 +734,99 @@ struct <link linkend="v4l2-standard">v4l2_standard</link> { | |||
734 | }; | 734 | }; |
735 | 735 | ||
736 | /* | 736 | /* |
737 | * V I D E O T I M I N G S D V P R E S E T | ||
738 | */ | ||
739 | struct <link linkend="v4l2-dv-preset">v4l2_dv_preset</link> { | ||
740 | __u32 preset; | ||
741 | __u32 reserved[4]; | ||
742 | }; | ||
743 | |||
744 | /* | ||
745 | * D V P R E S E T S E N U M E R A T I O N | ||
746 | */ | ||
747 | struct <link linkend="v4l2-dv-enum-preset">v4l2_dv_enum_preset</link> { | ||
748 | __u32 index; | ||
749 | __u32 preset; | ||
750 | __u8 name[32]; /* Name of the preset timing */ | ||
751 | __u32 width; | ||
752 | __u32 height; | ||
753 | __u32 reserved[4]; | ||
754 | }; | ||
755 | |||
756 | /* | ||
757 | * D V P R E S E T V A L U E S | ||
758 | */ | ||
759 | #define V4L2_DV_INVALID 0 | ||
760 | #define V4L2_DV_480P59_94 1 /* BT.1362 */ | ||
761 | #define V4L2_DV_576P50 2 /* BT.1362 */ | ||
762 | #define V4L2_DV_720P24 3 /* SMPTE 296M */ | ||
763 | #define V4L2_DV_720P25 4 /* SMPTE 296M */ | ||
764 | #define V4L2_DV_720P30 5 /* SMPTE 296M */ | ||
765 | #define V4L2_DV_720P50 6 /* SMPTE 296M */ | ||
766 | #define V4L2_DV_720P59_94 7 /* SMPTE 274M */ | ||
767 | #define V4L2_DV_720P60 8 /* SMPTE 274M/296M */ | ||
768 | #define V4L2_DV_1080I29_97 9 /* BT.1120/ SMPTE 274M */ | ||
769 | #define V4L2_DV_1080I30 10 /* BT.1120/ SMPTE 274M */ | ||
770 | #define V4L2_DV_1080I25 11 /* BT.1120 */ | ||
771 | #define V4L2_DV_1080I50 12 /* SMPTE 296M */ | ||
772 | #define V4L2_DV_1080I60 13 /* SMPTE 296M */ | ||
773 | #define V4L2_DV_1080P24 14 /* SMPTE 296M */ | ||
774 | #define V4L2_DV_1080P25 15 /* SMPTE 296M */ | ||
775 | #define V4L2_DV_1080P30 16 /* SMPTE 296M */ | ||
776 | #define V4L2_DV_1080P50 17 /* BT.1120 */ | ||
777 | #define V4L2_DV_1080P60 18 /* BT.1120 */ | ||
778 | |||
779 | /* | ||
780 | * D V B T T I M I N G S | ||
781 | */ | ||
782 | |||
783 | /* BT.656/BT.1120 timing data */ | ||
784 | struct <link linkend="v4l2-bt-timings">v4l2_bt_timings</link> { | ||
785 | __u32 width; /* width in pixels */ | ||
786 | __u32 height; /* height in lines */ | ||
787 | __u32 interlaced; /* Interlaced or progressive */ | ||
788 | __u32 polarities; /* Positive or negative polarity */ | ||
789 | __u64 pixelclock; /* Pixel clock in HZ. Ex. 74.25MHz->74250000 */ | ||
790 | __u32 hfrontporch; /* Horizpontal front porch in pixels */ | ||
791 | __u32 hsync; /* Horizontal Sync length in pixels */ | ||
792 | __u32 hbackporch; /* Horizontal back porch in pixels */ | ||
793 | __u32 vfrontporch; /* Vertical front porch in pixels */ | ||
794 | __u32 vsync; /* Vertical Sync length in lines */ | ||
795 | __u32 vbackporch; /* Vertical back porch in lines */ | ||
796 | __u32 il_vfrontporch; /* Vertical front porch for bottom field of | ||
797 | * interlaced field formats | ||
798 | */ | ||
799 | __u32 il_vsync; /* Vertical sync length for bottom field of | ||
800 | * interlaced field formats | ||
801 | */ | ||
802 | __u32 il_vbackporch; /* Vertical back porch for bottom field of | ||
803 | * interlaced field formats | ||
804 | */ | ||
805 | __u32 reserved[16]; | ||
806 | } __attribute__ ((packed)); | ||
807 | |||
808 | /* Interlaced or progressive format */ | ||
809 | #define V4L2_DV_PROGRESSIVE 0 | ||
810 | #define V4L2_DV_INTERLACED 1 | ||
811 | |||
812 | /* Polarities. If bit is not set, it is assumed to be negative polarity */ | ||
813 | #define V4L2_DV_VSYNC_POS_POL 0x00000001 | ||
814 | #define V4L2_DV_HSYNC_POS_POL 0x00000002 | ||
815 | |||
816 | |||
817 | /* DV timings */ | ||
818 | struct <link linkend="v4l2-dv-timings">v4l2_dv_timings</link> { | ||
819 | __u32 type; | ||
820 | union { | ||
821 | struct <link linkend="v4l2-bt-timings">v4l2_bt_timings</link> bt; | ||
822 | __u32 reserved[32]; | ||
823 | }; | ||
824 | } __attribute__ ((packed)); | ||
825 | |||
826 | /* Values for the type field */ | ||
827 | #define V4L2_DV_BT_656_1120 0 /* BT.656/1120 timing type */ | ||
828 | |||
829 | /* | ||
737 | * V I D E O I N P U T S | 830 | * V I D E O I N P U T S |
738 | */ | 831 | */ |
739 | struct <link linkend="v4l2-input">v4l2_input</link> { | 832 | struct <link linkend="v4l2-input">v4l2_input</link> { |
@@ -744,7 +837,8 @@ struct <link linkend="v4l2-input">v4l2_input</link> { | |||
744 | __u32 tuner; /* Associated tuner */ | 837 | __u32 tuner; /* Associated tuner */ |
745 | v4l2_std_id std; | 838 | v4l2_std_id std; |
746 | __u32 status; | 839 | __u32 status; |
747 | __u32 reserved[4]; | 840 | __u32 capabilities; |
841 | __u32 reserved[3]; | ||
748 | }; | 842 | }; |
749 | 843 | ||
750 | /* Values for the 'type' field */ | 844 | /* Values for the 'type' field */ |
@@ -775,6 +869,11 @@ struct <link linkend="v4l2-input">v4l2_input</link> { | |||
775 | #define V4L2_IN_ST_NO_ACCESS 0x02000000 /* Conditional access denied */ | 869 | #define V4L2_IN_ST_NO_ACCESS 0x02000000 /* Conditional access denied */ |
776 | #define V4L2_IN_ST_VTR 0x04000000 /* VTR time constant */ | 870 | #define V4L2_IN_ST_VTR 0x04000000 /* VTR time constant */ |
777 | 871 | ||
872 | /* capabilities flags */ | ||
873 | #define V4L2_IN_CAP_PRESETS 0x00000001 /* Supports S_DV_PRESET */ | ||
874 | #define V4L2_IN_CAP_CUSTOM_TIMINGS 0x00000002 /* Supports S_DV_TIMINGS */ | ||
875 | #define V4L2_IN_CAP_STD 0x00000004 /* Supports S_STD */ | ||
876 | |||
778 | /* | 877 | /* |
779 | * V I D E O O U T P U T S | 878 | * V I D E O O U T P U T S |
780 | */ | 879 | */ |
@@ -785,13 +884,19 @@ struct <link linkend="v4l2-output">v4l2_output</link> { | |||
785 | __u32 audioset; /* Associated audios (bitfield) */ | 884 | __u32 audioset; /* Associated audios (bitfield) */ |
786 | __u32 modulator; /* Associated modulator */ | 885 | __u32 modulator; /* Associated modulator */ |
787 | v4l2_std_id std; | 886 | v4l2_std_id std; |
788 | __u32 reserved[4]; | 887 | __u32 capabilities; |
888 | __u32 reserved[3]; | ||
789 | }; | 889 | }; |
790 | /* Values for the 'type' field */ | 890 | /* Values for the 'type' field */ |
791 | #define V4L2_OUTPUT_TYPE_MODULATOR 1 | 891 | #define V4L2_OUTPUT_TYPE_MODULATOR 1 |
792 | #define V4L2_OUTPUT_TYPE_ANALOG 2 | 892 | #define V4L2_OUTPUT_TYPE_ANALOG 2 |
793 | #define V4L2_OUTPUT_TYPE_ANALOGVGAOVERLAY 3 | 893 | #define V4L2_OUTPUT_TYPE_ANALOGVGAOVERLAY 3 |
794 | 894 | ||
895 | /* capabilities flags */ | ||
896 | #define V4L2_OUT_CAP_PRESETS 0x00000001 /* Supports S_DV_PRESET */ | ||
897 | #define V4L2_OUT_CAP_CUSTOM_TIMINGS 0x00000002 /* Supports S_DV_TIMINGS */ | ||
898 | #define V4L2_OUT_CAP_STD 0x00000004 /* Supports S_STD */ | ||
899 | |||
795 | /* | 900 | /* |
796 | * C O N T R O L S | 901 | * C O N T R O L S |
797 | */ | 902 | */ |
@@ -1626,6 +1731,13 @@ struct <link linkend="v4l2-dbg-chip-ident">v4l2_dbg_chip_ident</link> { | |||
1626 | #endif | 1731 | #endif |
1627 | 1732 | ||
1628 | #define VIDIOC_S_HW_FREQ_SEEK _IOW('V', 82, struct <link linkend="v4l2-hw-freq-seek">v4l2_hw_freq_seek</link>) | 1733 | #define VIDIOC_S_HW_FREQ_SEEK _IOW('V', 82, struct <link linkend="v4l2-hw-freq-seek">v4l2_hw_freq_seek</link>) |
1734 | #define VIDIOC_ENUM_DV_PRESETS _IOWR('V', 83, struct <link linkend="v4l2-dv-enum-preset">v4l2_dv_enum_preset</link>) | ||
1735 | #define VIDIOC_S_DV_PRESET _IOWR('V', 84, struct <link linkend="v4l2-dv-preset">v4l2_dv_preset</link>) | ||
1736 | #define VIDIOC_G_DV_PRESET _IOWR('V', 85, struct <link linkend="v4l2-dv-preset">v4l2_dv_preset</link>) | ||
1737 | #define VIDIOC_QUERY_DV_PRESET _IOR('V', 86, struct <link linkend="v4l2-dv-preset">v4l2_dv_preset</link>) | ||
1738 | #define VIDIOC_S_DV_TIMINGS _IOWR('V', 87, struct <link linkend="v4l2-dv-timings">v4l2_dv_timings</link>) | ||
1739 | #define VIDIOC_G_DV_TIMINGS _IOWR('V', 88, struct <link linkend="v4l2-dv-timings">v4l2_dv_timings</link>) | ||
1740 | |||
1629 | /* Reminder: when adding new ioctls please add support for them to | 1741 | /* Reminder: when adding new ioctls please add support for them to |
1630 | drivers/media/video/v4l2-compat-ioctl32.c as well! */ | 1742 | drivers/media/video/v4l2-compat-ioctl32.c as well! */ |
1631 | 1743 | ||
diff --git a/Documentation/DocBook/v4l/vidioc-enum-dv-presets.xml b/Documentation/DocBook/v4l/vidioc-enum-dv-presets.xml new file mode 100644 index 000000000000..1d31427edd1b --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-enum-dv-presets.xml | |||
@@ -0,0 +1,238 @@ | |||
1 | <refentry id="vidioc-enum-dv-presets"> | ||
2 | <refmeta> | ||
3 | <refentrytitle>ioctl VIDIOC_ENUM_DV_PRESETS</refentrytitle> | ||
4 | &manvol; | ||
5 | </refmeta> | ||
6 | |||
7 | <refnamediv> | ||
8 | <refname>VIDIOC_ENUM_DV_PRESETS</refname> | ||
9 | <refpurpose>Enumerate supported Digital Video presets</refpurpose> | ||
10 | </refnamediv> | ||
11 | |||
12 | <refsynopsisdiv> | ||
13 | <funcsynopsis> | ||
14 | <funcprototype> | ||
15 | <funcdef>int <function>ioctl</function></funcdef> | ||
16 | <paramdef>int <parameter>fd</parameter></paramdef> | ||
17 | <paramdef>int <parameter>request</parameter></paramdef> | ||
18 | <paramdef>struct v4l2_dv_enum_preset *<parameter>argp</parameter></paramdef> | ||
19 | </funcprototype> | ||
20 | </funcsynopsis> | ||
21 | </refsynopsisdiv> | ||
22 | |||
23 | <refsect1> | ||
24 | <title>Arguments</title> | ||
25 | |||
26 | <variablelist> | ||
27 | <varlistentry> | ||
28 | <term><parameter>fd</parameter></term> | ||
29 | <listitem> | ||
30 | <para>&fd;</para> | ||
31 | </listitem> | ||
32 | </varlistentry> | ||
33 | <varlistentry> | ||
34 | <term><parameter>request</parameter></term> | ||
35 | <listitem> | ||
36 | <para>VIDIOC_ENUM_DV_PRESETS</para> | ||
37 | </listitem> | ||
38 | </varlistentry> | ||
39 | <varlistentry> | ||
40 | <term><parameter>argp</parameter></term> | ||
41 | <listitem> | ||
42 | <para></para> | ||
43 | </listitem> | ||
44 | </varlistentry> | ||
45 | </variablelist> | ||
46 | </refsect1> | ||
47 | |||
48 | <refsect1> | ||
49 | <title>Description</title> | ||
50 | |||
51 | <para>To query the attributes of a DV preset, applications initialize the | ||
52 | <structfield>index</structfield> field and zero the reserved array of &v4l2-dv-enum-preset; | ||
53 | and call the <constant>VIDIOC_ENUM_DV_PRESETS</constant> ioctl with a pointer to this | ||
54 | structure. Drivers fill the rest of the structure or return an | ||
55 | &EINVAL; when the index is out of bounds. To enumerate all DV Presets supported, | ||
56 | applications shall begin at index zero, incrementing by one until the | ||
57 | driver returns <errorcode>EINVAL</errorcode>. Drivers may enumerate a | ||
58 | different set of DV presets after switching the video input or | ||
59 | output.</para> | ||
60 | |||
61 | <table pgwide="1" frame="none" id="v4l2-dv-enum-preset"> | ||
62 | <title>struct <structname>v4l2_dv_enum_presets</structname></title> | ||
63 | <tgroup cols="3"> | ||
64 | &cs-str; | ||
65 | <tbody valign="top"> | ||
66 | <row> | ||
67 | <entry>__u32</entry> | ||
68 | <entry><structfield>index</structfield></entry> | ||
69 | <entry>Number of the DV preset, set by the | ||
70 | application.</entry> | ||
71 | </row> | ||
72 | <row> | ||
73 | <entry>__u32</entry> | ||
74 | <entry><structfield>preset</structfield></entry> | ||
75 | <entry>This field identifies one of the DV preset values listed in <xref linkend="v4l2-dv-presets-vals"/>.</entry> | ||
76 | </row> | ||
77 | <row> | ||
78 | <entry>__u8</entry> | ||
79 | <entry><structfield>name</structfield>[24]</entry> | ||
80 | <entry>Name of the preset, a NUL-terminated ASCII string, for example: "720P-60", "1080I-60". This information is | ||
81 | intended for the user.</entry> | ||
82 | </row> | ||
83 | <row> | ||
84 | <entry>__u32</entry> | ||
85 | <entry><structfield>width</structfield></entry> | ||
86 | <entry>Width of the active video in pixels for the DV preset.</entry> | ||
87 | </row> | ||
88 | <row> | ||
89 | <entry>__u32</entry> | ||
90 | <entry><structfield>height</structfield></entry> | ||
91 | <entry>Height of the active video in lines for the DV preset.</entry> | ||
92 | </row> | ||
93 | <row> | ||
94 | <entry>__u32</entry> | ||
95 | <entry><structfield>reserved</structfield>[4]</entry> | ||
96 | <entry>Reserved for future extensions. Drivers must set the array to zero.</entry> | ||
97 | </row> | ||
98 | </tbody> | ||
99 | </tgroup> | ||
100 | </table> | ||
101 | |||
102 | <table pgwide="1" frame="none" id="v4l2-dv-presets-vals"> | ||
103 | <title>struct <structname>DV Presets</structname></title> | ||
104 | <tgroup cols="3"> | ||
105 | &cs-str; | ||
106 | <tbody valign="top"> | ||
107 | <row> | ||
108 | <entry>Preset</entry> | ||
109 | <entry>Preset value</entry> | ||
110 | <entry>Description</entry> | ||
111 | </row> | ||
112 | <row> | ||
113 | <entry></entry> | ||
114 | <entry></entry> | ||
115 | <entry></entry> | ||
116 | </row> | ||
117 | <row> | ||
118 | <entry>V4L2_DV_INVALID</entry> | ||
119 | <entry>0</entry> | ||
120 | <entry>Invalid preset value.</entry> | ||
121 | </row> | ||
122 | <row> | ||
123 | <entry>V4L2_DV_480P59_94</entry> | ||
124 | <entry>1</entry> | ||
125 | <entry>720x480 progressive video at 59.94 fps as per BT.1362.</entry> | ||
126 | </row> | ||
127 | <row> | ||
128 | <entry>V4L2_DV_576P50</entry> | ||
129 | <entry>2</entry> | ||
130 | <entry>720x576 progressive video at 50 fps as per BT.1362.</entry> | ||
131 | </row> | ||
132 | <row> | ||
133 | <entry>V4L2_DV_720P24</entry> | ||
134 | <entry>3</entry> | ||
135 | <entry>1280x720 progressive video at 24 fps as per SMPTE 296M.</entry> | ||
136 | </row> | ||
137 | <row> | ||
138 | <entry>V4L2_DV_720P25</entry> | ||
139 | <entry>4</entry> | ||
140 | <entry>1280x720 progressive video at 25 fps as per SMPTE 296M.</entry> | ||
141 | </row> | ||
142 | <row> | ||
143 | <entry>V4L2_DV_720P30</entry> | ||
144 | <entry>5</entry> | ||
145 | <entry>1280x720 progressive video at 30 fps as per SMPTE 296M.</entry> | ||
146 | </row> | ||
147 | <row> | ||
148 | <entry>V4L2_DV_720P50</entry> | ||
149 | <entry>6</entry> | ||
150 | <entry>1280x720 progressive video at 50 fps as per SMPTE 296M.</entry> | ||
151 | </row> | ||
152 | <row> | ||
153 | <entry>V4L2_DV_720P59_94</entry> | ||
154 | <entry>7</entry> | ||
155 | <entry>1280x720 progressive video at 59.94 fps as per SMPTE 274M.</entry> | ||
156 | </row> | ||
157 | <row> | ||
158 | <entry>V4L2_DV_720P60</entry> | ||
159 | <entry>8</entry> | ||
160 | <entry>1280x720 progressive video at 60 fps as per SMPTE 274M/296M.</entry> | ||
161 | </row> | ||
162 | <row> | ||
163 | <entry>V4L2_DV_1080I29_97</entry> | ||
164 | <entry>9</entry> | ||
165 | <entry>1920x1080 interlaced video at 29.97 fps as per BT.1120/SMPTE 274M.</entry> | ||
166 | </row> | ||
167 | <row> | ||
168 | <entry>V4L2_DV_1080I30</entry> | ||
169 | <entry>10</entry> | ||
170 | <entry>1920x1080 interlaced video at 30 fps as per BT.1120/SMPTE 274M.</entry> | ||
171 | </row> | ||
172 | <row> | ||
173 | <entry>V4L2_DV_1080I25</entry> | ||
174 | <entry>11</entry> | ||
175 | <entry>1920x1080 interlaced video at 25 fps as per BT.1120.</entry> | ||
176 | </row> | ||
177 | <row> | ||
178 | <entry>V4L2_DV_1080I50</entry> | ||
179 | <entry>12</entry> | ||
180 | <entry>1920x1080 interlaced video at 50 fps as per SMPTE 296M.</entry> | ||
181 | </row> | ||
182 | <row> | ||
183 | <entry>V4L2_DV_1080I60</entry> | ||
184 | <entry>13</entry> | ||
185 | <entry>1920x1080 interlaced video at 60 fps as per SMPTE 296M.</entry> | ||
186 | </row> | ||
187 | <row> | ||
188 | <entry>V4L2_DV_1080P24</entry> | ||
189 | <entry>14</entry> | ||
190 | <entry>1920x1080 progressive video at 24 fps as per SMPTE 296M.</entry> | ||
191 | </row> | ||
192 | <row> | ||
193 | <entry>V4L2_DV_1080P25</entry> | ||
194 | <entry>15</entry> | ||
195 | <entry>1920x1080 progressive video at 25 fps as per SMPTE 296M.</entry> | ||
196 | </row> | ||
197 | <row> | ||
198 | <entry>V4L2_DV_1080P30</entry> | ||
199 | <entry>16</entry> | ||
200 | <entry>1920x1080 progressive video at 30 fps as per SMPTE 296M.</entry> | ||
201 | </row> | ||
202 | <row> | ||
203 | <entry>V4L2_DV_1080P50</entry> | ||
204 | <entry>17</entry> | ||
205 | <entry>1920x1080 progressive video at 50 fps as per BT.1120.</entry> | ||
206 | </row> | ||
207 | <row> | ||
208 | <entry>V4L2_DV_1080P60</entry> | ||
209 | <entry>18</entry> | ||
210 | <entry>1920x1080 progressive video at 60 fps as per BT.1120.</entry> | ||
211 | </row> | ||
212 | </tbody> | ||
213 | </tgroup> | ||
214 | </table> | ||
215 | </refsect1> | ||
216 | |||
217 | <refsect1> | ||
218 | &return-value; | ||
219 | |||
220 | <variablelist> | ||
221 | <varlistentry> | ||
222 | <term><errorcode>EINVAL</errorcode></term> | ||
223 | <listitem> | ||
224 | <para>The &v4l2-dv-enum-preset; <structfield>index</structfield> | ||
225 | is out of bounds.</para> | ||
226 | </listitem> | ||
227 | </varlistentry> | ||
228 | </variablelist> | ||
229 | </refsect1> | ||
230 | </refentry> | ||
231 | |||
232 | <!-- | ||
233 | Local Variables: | ||
234 | mode: sgml | ||
235 | sgml-parent-document: "v4l2.sgml" | ||
236 | indent-tabs-mode: nil | ||
237 | End: | ||
238 | --> | ||
diff --git a/Documentation/DocBook/v4l/vidioc-enuminput.xml b/Documentation/DocBook/v4l/vidioc-enuminput.xml index 414856b82473..71b868e2fb8f 100644 --- a/Documentation/DocBook/v4l/vidioc-enuminput.xml +++ b/Documentation/DocBook/v4l/vidioc-enuminput.xml | |||
@@ -124,7 +124,13 @@ current input.</entry> | |||
124 | </row> | 124 | </row> |
125 | <row> | 125 | <row> |
126 | <entry>__u32</entry> | 126 | <entry>__u32</entry> |
127 | <entry><structfield>reserved</structfield>[4]</entry> | 127 | <entry><structfield>capabilities</structfield></entry> |
128 | <entry>This field provides capabilities for the | ||
129 | input. See <xref linkend="input-capabilities" /> for flags.</entry> | ||
130 | </row> | ||
131 | <row> | ||
132 | <entry>__u32</entry> | ||
133 | <entry><structfield>reserved</structfield>[3]</entry> | ||
128 | <entry>Reserved for future extensions. Drivers must set | 134 | <entry>Reserved for future extensions. Drivers must set |
129 | the array to zero.</entry> | 135 | the array to zero.</entry> |
130 | </row> | 136 | </row> |
@@ -261,6 +267,34 @@ flag is set Macrovision has been detected.</entry> | |||
261 | </tbody> | 267 | </tbody> |
262 | </tgroup> | 268 | </tgroup> |
263 | </table> | 269 | </table> |
270 | |||
271 | <!-- Capability flags based on video timings RFC by Muralidharan | ||
272 | Karicheri, titled RFC (v1.2): V4L - Support for video timings at the | ||
273 | input/output interface to linux-media@vger.kernel.org on 19 Oct 2009. | ||
274 | --> | ||
275 | <table frame="none" pgwide="1" id="input-capabilities"> | ||
276 | <title>Input capabilities</title> | ||
277 | <tgroup cols="3"> | ||
278 | &cs-def; | ||
279 | <tbody valign="top"> | ||
280 | <row> | ||
281 | <entry><constant>V4L2_IN_CAP_PRESETS</constant></entry> | ||
282 | <entry>0x00000001</entry> | ||
283 | <entry>This input supports setting DV presets by using VIDIOC_S_DV_PRESET.</entry> | ||
284 | </row> | ||
285 | <row> | ||
286 | <entry><constant>V4L2_OUT_CAP_CUSTOM_TIMINGS</constant></entry> | ||
287 | <entry>0x00000002</entry> | ||
288 | <entry>This input supports setting custom video timings by using VIDIOC_S_DV_TIMINGS.</entry> | ||
289 | </row> | ||
290 | <row> | ||
291 | <entry><constant>V4L2_IN_CAP_STD</constant></entry> | ||
292 | <entry>0x00000004</entry> | ||
293 | <entry>This input supports setting the TV standard by using VIDIOC_S_STD.</entry> | ||
294 | </row> | ||
295 | </tbody> | ||
296 | </tgroup> | ||
297 | </table> | ||
264 | </refsect1> | 298 | </refsect1> |
265 | 299 | ||
266 | <refsect1> | 300 | <refsect1> |
diff --git a/Documentation/DocBook/v4l/vidioc-enumoutput.xml b/Documentation/DocBook/v4l/vidioc-enumoutput.xml index e8d16dcd50cf..a281d26a195f 100644 --- a/Documentation/DocBook/v4l/vidioc-enumoutput.xml +++ b/Documentation/DocBook/v4l/vidioc-enumoutput.xml | |||
@@ -114,7 +114,13 @@ details on video standards and how to switch see <xref | |||
114 | </row> | 114 | </row> |
115 | <row> | 115 | <row> |
116 | <entry>__u32</entry> | 116 | <entry>__u32</entry> |
117 | <entry><structfield>reserved</structfield>[4]</entry> | 117 | <entry><structfield>capabilities</structfield></entry> |
118 | <entry>This field provides capabilities for the | ||
119 | output. See <xref linkend="output-capabilities" /> for flags.</entry> | ||
120 | </row> | ||
121 | <row> | ||
122 | <entry>__u32</entry> | ||
123 | <entry><structfield>reserved</structfield>[3]</entry> | ||
118 | <entry>Reserved for future extensions. Drivers must set | 124 | <entry>Reserved for future extensions. Drivers must set |
119 | the array to zero.</entry> | 125 | the array to zero.</entry> |
120 | </row> | 126 | </row> |
@@ -147,6 +153,34 @@ CVBS, S-Video, RGB.</entry> | |||
147 | </tgroup> | 153 | </tgroup> |
148 | </table> | 154 | </table> |
149 | 155 | ||
156 | <!-- Capabilities flags based on video timings RFC by Muralidharan | ||
157 | Karicheri, titled RFC (v1.2): V4L - Support for video timings at the | ||
158 | input/output interface to linux-media@vger.kernel.org on 19 Oct 2009. | ||
159 | --> | ||
160 | <table frame="none" pgwide="1" id="output-capabilities"> | ||
161 | <title>Output capabilities</title> | ||
162 | <tgroup cols="3"> | ||
163 | &cs-def; | ||
164 | <tbody valign="top"> | ||
165 | <row> | ||
166 | <entry><constant>V4L2_OUT_CAP_PRESETS</constant></entry> | ||
167 | <entry>0x00000001</entry> | ||
168 | <entry>This output supports setting DV presets by using VIDIOC_S_DV_PRESET.</entry> | ||
169 | </row> | ||
170 | <row> | ||
171 | <entry><constant>V4L2_OUT_CAP_CUSTOM_TIMINGS</constant></entry> | ||
172 | <entry>0x00000002</entry> | ||
173 | <entry>This output supports setting custom video timings by using VIDIOC_S_DV_TIMINGS.</entry> | ||
174 | </row> | ||
175 | <row> | ||
176 | <entry><constant>V4L2_OUT_CAP_STD</constant></entry> | ||
177 | <entry>0x00000004</entry> | ||
178 | <entry>This output supports setting the TV standard by using VIDIOC_S_STD.</entry> | ||
179 | </row> | ||
180 | </tbody> | ||
181 | </tgroup> | ||
182 | </table> | ||
183 | |||
150 | </refsect1> | 184 | </refsect1> |
151 | <refsect1> | 185 | <refsect1> |
152 | &return-value; | 186 | &return-value; |
diff --git a/Documentation/DocBook/v4l/vidioc-g-dv-preset.xml b/Documentation/DocBook/v4l/vidioc-g-dv-preset.xml new file mode 100644 index 000000000000..3c6784e132f3 --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-g-dv-preset.xml | |||
@@ -0,0 +1,111 @@ | |||
1 | <refentry id="vidioc-g-dv-preset"> | ||
2 | <refmeta> | ||
3 | <refentrytitle>ioctl VIDIOC_G_DV_PRESET, VIDIOC_S_DV_PRESET</refentrytitle> | ||
4 | &manvol; | ||
5 | </refmeta> | ||
6 | |||
7 | <refnamediv> | ||
8 | <refname>VIDIOC_G_DV_PRESET</refname> | ||
9 | <refname>VIDIOC_S_DV_PRESET</refname> | ||
10 | <refpurpose>Query or select the DV preset of the current input or output</refpurpose> | ||
11 | </refnamediv> | ||
12 | |||
13 | <refsynopsisdiv> | ||
14 | <funcsynopsis> | ||
15 | <funcprototype> | ||
16 | <funcdef>int <function>ioctl</function></funcdef> | ||
17 | <paramdef>int <parameter>fd</parameter></paramdef> | ||
18 | <paramdef>int <parameter>request</parameter></paramdef> | ||
19 | <paramdef>&v4l2-dv-preset; | ||
20 | *<parameter>argp</parameter></paramdef> | ||
21 | </funcprototype> | ||
22 | </funcsynopsis> | ||
23 | </refsynopsisdiv> | ||
24 | |||
25 | <refsect1> | ||
26 | <title>Arguments</title> | ||
27 | |||
28 | <variablelist> | ||
29 | <varlistentry> | ||
30 | <term><parameter>fd</parameter></term> | ||
31 | <listitem> | ||
32 | <para>&fd;</para> | ||
33 | </listitem> | ||
34 | </varlistentry> | ||
35 | <varlistentry> | ||
36 | <term><parameter>request</parameter></term> | ||
37 | <listitem> | ||
38 | <para>VIDIOC_G_DV_PRESET, VIDIOC_S_DV_PRESET</para> | ||
39 | </listitem> | ||
40 | </varlistentry> | ||
41 | <varlistentry> | ||
42 | <term><parameter>argp</parameter></term> | ||
43 | <listitem> | ||
44 | <para></para> | ||
45 | </listitem> | ||
46 | </varlistentry> | ||
47 | </variablelist> | ||
48 | </refsect1> | ||
49 | |||
50 | <refsect1> | ||
51 | <title>Description</title> | ||
52 | <para>To query and select the current DV preset, applications | ||
53 | use the <constant>VIDIOC_G_DV_PRESET</constant> and <constant>VIDIOC_S_DV_PRESET</constant> | ||
54 | ioctls which take a pointer to a &v4l2-dv-preset; type as argument. | ||
55 | Applications must zero the reserved array in &v4l2-dv-preset;. | ||
56 | <constant>VIDIOC_G_DV_PRESET</constant> returns a dv preset in the field | ||
57 | <structfield>preset</structfield> of &v4l2-dv-preset;.</para> | ||
58 | |||
59 | <para><constant>VIDIOC_S_DV_PRESET</constant> accepts a pointer to a &v4l2-dv-preset; | ||
60 | that has the preset value to be set. Applications must zero the reserved array in &v4l2-dv-preset;. | ||
61 | If the preset is not supported, it returns an &EINVAL; </para> | ||
62 | </refsect1> | ||
63 | |||
64 | <refsect1> | ||
65 | &return-value; | ||
66 | |||
67 | <variablelist> | ||
68 | <varlistentry> | ||
69 | <term><errorcode>EINVAL</errorcode></term> | ||
70 | <listitem> | ||
71 | <para>This ioctl is not supported, or the | ||
72 | <constant>VIDIOC_S_DV_PRESET</constant>,<constant>VIDIOC_S_DV_PRESET</constant> parameter was unsuitable.</para> | ||
73 | </listitem> | ||
74 | </varlistentry> | ||
75 | <varlistentry> | ||
76 | <term><errorcode>EBUSY</errorcode></term> | ||
77 | <listitem> | ||
78 | <para>The device is busy and therefore can not change the preset.</para> | ||
79 | </listitem> | ||
80 | </varlistentry> | ||
81 | </variablelist> | ||
82 | |||
83 | <table pgwide="1" frame="none" id="v4l2-dv-preset"> | ||
84 | <title>struct <structname>v4l2_dv_preset</structname></title> | ||
85 | <tgroup cols="3"> | ||
86 | &cs-str; | ||
87 | <tbody valign="top"> | ||
88 | <row> | ||
89 | <entry>__u32</entry> | ||
90 | <entry><structfield>preset</structfield></entry> | ||
91 | <entry>Preset value to represent the digital video timings</entry> | ||
92 | </row> | ||
93 | <row> | ||
94 | <entry>__u32</entry> | ||
95 | <entry><structfield>reserved[4]</structfield></entry> | ||
96 | <entry>Reserved fields for future use</entry> | ||
97 | </row> | ||
98 | </tbody> | ||
99 | </tgroup> | ||
100 | </table> | ||
101 | |||
102 | </refsect1> | ||
103 | </refentry> | ||
104 | |||
105 | <!-- | ||
106 | Local Variables: | ||
107 | mode: sgml | ||
108 | sgml-parent-document: "v4l2.sgml" | ||
109 | indent-tabs-mode: nil | ||
110 | End: | ||
111 | --> | ||
diff --git a/Documentation/DocBook/v4l/vidioc-g-dv-timings.xml b/Documentation/DocBook/v4l/vidioc-g-dv-timings.xml new file mode 100644 index 000000000000..ecc19576bb8f --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-g-dv-timings.xml | |||
@@ -0,0 +1,224 @@ | |||
1 | <refentry id="vidioc-g-dv-timings"> | ||
2 | <refmeta> | ||
3 | <refentrytitle>ioctl VIDIOC_G_DV_TIMINGS, VIDIOC_S_DV_TIMINGS</refentrytitle> | ||
4 | &manvol; | ||
5 | </refmeta> | ||
6 | |||
7 | <refnamediv> | ||
8 | <refname>VIDIOC_G_DV_TIMINGS</refname> | ||
9 | <refname>VIDIOC_S_DV_TIMINGS</refname> | ||
10 | <refpurpose>Get or set custom DV timings for input or output</refpurpose> | ||
11 | </refnamediv> | ||
12 | |||
13 | <refsynopsisdiv> | ||
14 | <funcsynopsis> | ||
15 | <funcprototype> | ||
16 | <funcdef>int <function>ioctl</function></funcdef> | ||
17 | <paramdef>int <parameter>fd</parameter></paramdef> | ||
18 | <paramdef>int <parameter>request</parameter></paramdef> | ||
19 | <paramdef>&v4l2-dv-timings; | ||
20 | *<parameter>argp</parameter></paramdef> | ||
21 | </funcprototype> | ||
22 | </funcsynopsis> | ||
23 | </refsynopsisdiv> | ||
24 | |||
25 | <refsect1> | ||
26 | <title>Arguments</title> | ||
27 | |||
28 | <variablelist> | ||
29 | <varlistentry> | ||
30 | <term><parameter>fd</parameter></term> | ||
31 | <listitem> | ||
32 | <para>&fd;</para> | ||
33 | </listitem> | ||
34 | </varlistentry> | ||
35 | <varlistentry> | ||
36 | <term><parameter>request</parameter></term> | ||
37 | <listitem> | ||
38 | <para>VIDIOC_G_DV_TIMINGS, VIDIOC_S_DV_TIMINGS</para> | ||
39 | </listitem> | ||
40 | </varlistentry> | ||
41 | <varlistentry> | ||
42 | <term><parameter>argp</parameter></term> | ||
43 | <listitem> | ||
44 | <para></para> | ||
45 | </listitem> | ||
46 | </varlistentry> | ||
47 | </variablelist> | ||
48 | </refsect1> | ||
49 | |||
50 | <refsect1> | ||
51 | <title>Description</title> | ||
52 | <para>To set custom DV timings for the input or output, applications use the | ||
53 | <constant>VIDIOC_S_DV_TIMINGS</constant> ioctl and to get the current custom timings, | ||
54 | applications use the <constant>VIDIOC_G_DV_TIMINGS</constant> ioctl. The detailed timing | ||
55 | information is filled in using the structure &v4l2-dv-timings;. These ioctls take | ||
56 | a pointer to the &v4l2-dv-timings; structure as argument. If the ioctl is not supported | ||
57 | or the timing values are not correct, the driver returns &EINVAL;.</para> | ||
58 | </refsect1> | ||
59 | |||
60 | <refsect1> | ||
61 | &return-value; | ||
62 | |||
63 | <variablelist> | ||
64 | <varlistentry> | ||
65 | <term><errorcode>EINVAL</errorcode></term> | ||
66 | <listitem> | ||
67 | <para>This ioctl is not supported, or the | ||
68 | <constant>VIDIOC_S_DV_TIMINGS</constant> parameter was unsuitable.</para> | ||
69 | </listitem> | ||
70 | </varlistentry> | ||
71 | <varlistentry> | ||
72 | <term><errorcode>EBUSY</errorcode></term> | ||
73 | <listitem> | ||
74 | <para>The device is busy and therefore can not change the timings.</para> | ||
75 | </listitem> | ||
76 | </varlistentry> | ||
77 | </variablelist> | ||
78 | |||
79 | <table pgwide="1" frame="none" id="v4l2-bt-timings"> | ||
80 | <title>struct <structname>v4l2_bt_timings</structname></title> | ||
81 | <tgroup cols="3"> | ||
82 | &cs-str; | ||
83 | <tbody valign="top"> | ||
84 | <row> | ||
85 | <entry>__u32</entry> | ||
86 | <entry><structfield>width</structfield></entry> | ||
87 | <entry>Width of the active video in pixels</entry> | ||
88 | </row> | ||
89 | <row> | ||
90 | <entry>__u32</entry> | ||
91 | <entry><structfield>height</structfield></entry> | ||
92 | <entry>Height of the active video in lines</entry> | ||
93 | </row> | ||
94 | <row> | ||
95 | <entry>__u32</entry> | ||
96 | <entry><structfield>interlaced</structfield></entry> | ||
97 | <entry>Progressive (0) or interlaced (1)</entry> | ||
98 | </row> | ||
99 | <row> | ||
100 | <entry>__u32</entry> | ||
101 | <entry><structfield>polarities</structfield></entry> | ||
102 | <entry>This is a bit mask that defines polarities of sync signals. | ||
103 | bit 0 (V4L2_DV_VSYNC_POS_POL) is for vertical sync polarity and bit 1 (V4L2_DV_HSYNC_POS_POL) is for horizontal sync polarity. If the bit is set | ||
104 | (1) it is positive polarity and if is cleared (0), it is negative polarity.</entry> | ||
105 | </row> | ||
106 | <row> | ||
107 | <entry>__u64</entry> | ||
108 | <entry><structfield>pixelclock</structfield></entry> | ||
109 | <entry>Pixel clock in Hz. Ex. 74.25MHz->74250000</entry> | ||
110 | </row> | ||
111 | <row> | ||
112 | <entry>__u32</entry> | ||
113 | <entry><structfield>hfrontporch</structfield></entry> | ||
114 | <entry>Horizontal front porch in pixels</entry> | ||
115 | </row> | ||
116 | <row> | ||
117 | <entry>__u32</entry> | ||
118 | <entry><structfield>hsync</structfield></entry> | ||
119 | <entry>Horizontal sync length in pixels</entry> | ||
120 | </row> | ||
121 | <row> | ||
122 | <entry>__u32</entry> | ||
123 | <entry><structfield>hbackporch</structfield></entry> | ||
124 | <entry>Horizontal back porch in pixels</entry> | ||
125 | </row> | ||
126 | <row> | ||
127 | <entry>__u32</entry> | ||
128 | <entry><structfield>vfrontporch</structfield></entry> | ||
129 | <entry>Vertical front porch in lines</entry> | ||
130 | </row> | ||
131 | <row> | ||
132 | <entry>__u32</entry> | ||
133 | <entry><structfield>vsync</structfield></entry> | ||
134 | <entry>Vertical sync length in lines</entry> | ||
135 | </row> | ||
136 | <row> | ||
137 | <entry>__u32</entry> | ||
138 | <entry><structfield>vbackporch</structfield></entry> | ||
139 | <entry>Vertical back porch in lines</entry> | ||
140 | </row> | ||
141 | <row> | ||
142 | <entry>__u32</entry> | ||
143 | <entry><structfield>il_vfrontporch</structfield></entry> | ||
144 | <entry>Vertical front porch in lines for bottom field of interlaced field formats</entry> | ||
145 | </row> | ||
146 | <row> | ||
147 | <entry>__u32</entry> | ||
148 | <entry><structfield>il_vsync</structfield></entry> | ||
149 | <entry>Vertical sync length in lines for bottom field of interlaced field formats</entry> | ||
150 | </row> | ||
151 | <row> | ||
152 | <entry>__u32</entry> | ||
153 | <entry><structfield>il_vbackporch</structfield></entry> | ||
154 | <entry>Vertical back porch in lines for bottom field of interlaced field formats</entry> | ||
155 | </row> | ||
156 | </tbody> | ||
157 | </tgroup> | ||
158 | </table> | ||
159 | |||
160 | <table pgwide="1" frame="none" id="v4l2-dv-timings"> | ||
161 | <title>struct <structname>v4l2_dv_timings</structname></title> | ||
162 | <tgroup cols="4"> | ||
163 | &cs-str; | ||
164 | <tbody valign="top"> | ||
165 | <row> | ||
166 | <entry>__u32</entry> | ||
167 | <entry><structfield>type</structfield></entry> | ||
168 | <entry></entry> | ||
169 | <entry>Type of DV timings as listed in <xref linkend="dv-timing-types"/>.</entry> | ||
170 | </row> | ||
171 | <row> | ||
172 | <entry>union</entry> | ||
173 | <entry><structfield></structfield></entry> | ||
174 | <entry></entry> | ||
175 | </row> | ||
176 | <row> | ||
177 | <entry></entry> | ||
178 | <entry>&v4l2-bt-timings;</entry> | ||
179 | <entry><structfield>bt</structfield></entry> | ||
180 | <entry>Timings defined by BT.656/1120 specifications</entry> | ||
181 | </row> | ||
182 | <row> | ||
183 | <entry></entry> | ||
184 | <entry>__u32</entry> | ||
185 | <entry><structfield>reserved</structfield>[32]</entry> | ||
186 | <entry></entry> | ||
187 | </row> | ||
188 | </tbody> | ||
189 | </tgroup> | ||
190 | </table> | ||
191 | |||
192 | <table pgwide="1" frame="none" id="dv-timing-types"> | ||
193 | <title>DV Timing types</title> | ||
194 | <tgroup cols="3"> | ||
195 | &cs-str; | ||
196 | <tbody valign="top"> | ||
197 | <row> | ||
198 | <entry>Timing type</entry> | ||
199 | <entry>value</entry> | ||
200 | <entry>Description</entry> | ||
201 | </row> | ||
202 | <row> | ||
203 | <entry></entry> | ||
204 | <entry></entry> | ||
205 | <entry></entry> | ||
206 | </row> | ||
207 | <row> | ||
208 | <entry>V4L2_DV_BT_656_1120</entry> | ||
209 | <entry>0</entry> | ||
210 | <entry>BT.656/1120 timings</entry> | ||
211 | </row> | ||
212 | </tbody> | ||
213 | </tgroup> | ||
214 | </table> | ||
215 | </refsect1> | ||
216 | </refentry> | ||
217 | |||
218 | <!-- | ||
219 | Local Variables: | ||
220 | mode: sgml | ||
221 | sgml-parent-document: "v4l2.sgml" | ||
222 | indent-tabs-mode: nil | ||
223 | End: | ||
224 | --> | ||
diff --git a/Documentation/DocBook/v4l/vidioc-g-std.xml b/Documentation/DocBook/v4l/vidioc-g-std.xml index b6f5d267e856..912f8513e5da 100644 --- a/Documentation/DocBook/v4l/vidioc-g-std.xml +++ b/Documentation/DocBook/v4l/vidioc-g-std.xml | |||
@@ -86,6 +86,12 @@ standards.</para> | |||
86 | <constant>VIDIOC_S_STD</constant> parameter was unsuitable.</para> | 86 | <constant>VIDIOC_S_STD</constant> parameter was unsuitable.</para> |
87 | </listitem> | 87 | </listitem> |
88 | </varlistentry> | 88 | </varlistentry> |
89 | <varlistentry> | ||
90 | <term><errorcode>EBUSY</errorcode></term> | ||
91 | <listitem> | ||
92 | <para>The device is busy and therefore can not change the standard</para> | ||
93 | </listitem> | ||
94 | </varlistentry> | ||
89 | </variablelist> | 95 | </variablelist> |
90 | </refsect1> | 96 | </refsect1> |
91 | </refentry> | 97 | </refentry> |
diff --git a/Documentation/DocBook/v4l/vidioc-query-dv-preset.xml b/Documentation/DocBook/v4l/vidioc-query-dv-preset.xml new file mode 100644 index 000000000000..87e4f0f6151c --- /dev/null +++ b/Documentation/DocBook/v4l/vidioc-query-dv-preset.xml | |||
@@ -0,0 +1,85 @@ | |||
1 | <refentry id="vidioc-query-dv-preset"> | ||
2 | <refmeta> | ||
3 | <refentrytitle>ioctl VIDIOC_QUERY_DV_PRESET</refentrytitle> | ||
4 | &manvol; | ||
5 | </refmeta> | ||
6 | |||
7 | <refnamediv> | ||
8 | <refname>VIDIOC_QUERY_DV_PRESET</refname> | ||
9 | <refpurpose>Sense the DV preset received by the current | ||
10 | input</refpurpose> | ||
11 | </refnamediv> | ||
12 | |||
13 | <refsynopsisdiv> | ||
14 | <funcsynopsis> | ||
15 | <funcprototype> | ||
16 | <funcdef>int <function>ioctl</function></funcdef> | ||
17 | <paramdef>int <parameter>fd</parameter></paramdef> | ||
18 | <paramdef>int <parameter>request</parameter></paramdef> | ||
19 | <paramdef>&v4l2-dv-preset; *<parameter>argp</parameter></paramdef> | ||
20 | </funcprototype> | ||
21 | </funcsynopsis> | ||
22 | </refsynopsisdiv> | ||
23 | |||
24 | <refsect1> | ||
25 | <title>Arguments</title> | ||
26 | |||
27 | <variablelist> | ||
28 | <varlistentry> | ||
29 | <term><parameter>fd</parameter></term> | ||
30 | <listitem> | ||
31 | <para>&fd;</para> | ||
32 | </listitem> | ||
33 | </varlistentry> | ||
34 | <varlistentry> | ||
35 | <term><parameter>request</parameter></term> | ||
36 | <listitem> | ||
37 | <para>VIDIOC_QUERY_DV_PRESET</para> | ||
38 | </listitem> | ||
39 | </varlistentry> | ||
40 | <varlistentry> | ||
41 | <term><parameter>argp</parameter></term> | ||
42 | <listitem> | ||
43 | <para></para> | ||
44 | </listitem> | ||
45 | </varlistentry> | ||
46 | </variablelist> | ||
47 | </refsect1> | ||
48 | |||
49 | <refsect1> | ||
50 | <title>Description</title> | ||
51 | |||
52 | <para>The hardware may be able to detect the current DV preset | ||
53 | automatically, similar to sensing the video standard. To do so, applications | ||
54 | call <constant> VIDIOC_QUERY_DV_PRESET</constant> with a pointer to a | ||
55 | &v4l2-dv-preset; type. Once the hardware detects a preset, that preset is | ||
56 | returned in the preset field of &v4l2-dv-preset;. When detection is not | ||
57 | possible or fails, the value V4L2_DV_INVALID is returned.</para> | ||
58 | </refsect1> | ||
59 | |||
60 | <refsect1> | ||
61 | &return-value; | ||
62 | <variablelist> | ||
63 | <varlistentry> | ||
64 | <term><errorcode>EINVAL</errorcode></term> | ||
65 | <listitem> | ||
66 | <para>This ioctl is not supported.</para> | ||
67 | </listitem> | ||
68 | </varlistentry> | ||
69 | <varlistentry> | ||
70 | <term><errorcode>EBUSY</errorcode></term> | ||
71 | <listitem> | ||
72 | <para>The device is busy and therefore can not sense the preset</para> | ||
73 | </listitem> | ||
74 | </varlistentry> | ||
75 | </variablelist> | ||
76 | </refsect1> | ||
77 | </refentry> | ||
78 | |||
79 | <!-- | ||
80 | Local Variables: | ||
81 | mode: sgml | ||
82 | sgml-parent-document: "v4l2.sgml" | ||
83 | indent-tabs-mode: nil | ||
84 | End: | ||
85 | --> | ||
diff --git a/Documentation/DocBook/v4l/vidioc-querystd.xml b/Documentation/DocBook/v4l/vidioc-querystd.xml index b5a7ff934486..1a9e60393091 100644 --- a/Documentation/DocBook/v4l/vidioc-querystd.xml +++ b/Documentation/DocBook/v4l/vidioc-querystd.xml | |||
@@ -70,6 +70,12 @@ current video input or output.</para> | |||
70 | <para>This ioctl is not supported.</para> | 70 | <para>This ioctl is not supported.</para> |
71 | </listitem> | 71 | </listitem> |
72 | </varlistentry> | 72 | </varlistentry> |
73 | <varlistentry> | ||
74 | <term><errorcode>EBUSY</errorcode></term> | ||
75 | <listitem> | ||
76 | <para>The device is busy and therefore can not detect the standard</para> | ||
77 | </listitem> | ||
78 | </varlistentry> | ||
73 | </variablelist> | 79 | </variablelist> |
74 | </refsect1> | 80 | </refsect1> |
75 | </refentry> | 81 | </refentry> |
diff --git a/Documentation/SubmitChecklist b/Documentation/SubmitChecklist index 78a9168ff377..1053a56be3b1 100644 --- a/Documentation/SubmitChecklist +++ b/Documentation/SubmitChecklist | |||
@@ -15,7 +15,7 @@ kernel patches. | |||
15 | 2: Passes allnoconfig, allmodconfig | 15 | 2: Passes allnoconfig, allmodconfig |
16 | 16 | ||
17 | 3: Builds on multiple CPU architectures by using local cross-compile tools | 17 | 3: Builds on multiple CPU architectures by using local cross-compile tools |
18 | or something like PLM at OSDL. | 18 | or some other build farm. |
19 | 19 | ||
20 | 4: ppc64 is a good architecture for cross-compilation checking because it | 20 | 4: ppc64 is a good architecture for cross-compilation checking because it |
21 | tends to use `unsigned long' for 64-bit quantities. | 21 | tends to use `unsigned long' for 64-bit quantities. |
@@ -88,3 +88,6 @@ kernel patches. | |||
88 | 88 | ||
89 | 24: All memory barriers {e.g., barrier(), rmb(), wmb()} need a comment in the | 89 | 24: All memory barriers {e.g., barrier(), rmb(), wmb()} need a comment in the |
90 | source code that explains the logic of what they are doing and why. | 90 | source code that explains the logic of what they are doing and why. |
91 | |||
92 | 25: If any ioctl's are added by the patch, then also update | ||
93 | Documentation/ioctl/ioctl-number.txt. | ||
diff --git a/Documentation/device-mapper/snapshot.txt b/Documentation/device-mapper/snapshot.txt index a5009c8300f3..e3a77b215135 100644 --- a/Documentation/device-mapper/snapshot.txt +++ b/Documentation/device-mapper/snapshot.txt | |||
@@ -8,13 +8,19 @@ the block device which are also writable without interfering with the | |||
8 | original content; | 8 | original content; |
9 | *) To create device "forks", i.e. multiple different versions of the | 9 | *) To create device "forks", i.e. multiple different versions of the |
10 | same data stream. | 10 | same data stream. |
11 | *) To merge a snapshot of a block device back into the snapshot's origin | ||
12 | device. | ||
11 | 13 | ||
14 | In the first two cases, dm copies only the chunks of data that get | ||
15 | changed and uses a separate copy-on-write (COW) block device for | ||
16 | storage. | ||
12 | 17 | ||
13 | In both cases, dm copies only the chunks of data that get changed and | 18 | For snapshot merge the contents of the COW storage are merged back into |
14 | uses a separate copy-on-write (COW) block device for storage. | 19 | the origin device. |
15 | 20 | ||
16 | 21 | ||
17 | There are two dm targets available: snapshot and snapshot-origin. | 22 | There are three dm targets available: |
23 | snapshot, snapshot-origin, and snapshot-merge. | ||
18 | 24 | ||
19 | *) snapshot-origin <origin> | 25 | *) snapshot-origin <origin> |
20 | 26 | ||
@@ -40,8 +46,25 @@ The difference is that for transient snapshots less metadata must be | |||
40 | saved on disk - they can be kept in memory by the kernel. | 46 | saved on disk - they can be kept in memory by the kernel. |
41 | 47 | ||
42 | 48 | ||
43 | How this is used by LVM2 | 49 | * snapshot-merge <origin> <COW device> <persistent> <chunksize> |
44 | ======================== | 50 | |
51 | takes the same table arguments as the snapshot target except it only | ||
52 | works with persistent snapshots. This target assumes the role of the | ||
53 | "snapshot-origin" target and must not be loaded if the "snapshot-origin" | ||
54 | is still present for <origin>. | ||
55 | |||
56 | Creates a merging snapshot that takes control of the changed chunks | ||
57 | stored in the <COW device> of an existing snapshot, through a handover | ||
58 | procedure, and merges these chunks back into the <origin>. Once merging | ||
59 | has started (in the background) the <origin> may be opened and the merge | ||
60 | will continue while I/O is flowing to it. Changes to the <origin> are | ||
61 | deferred until the merging snapshot's corresponding chunk(s) have been | ||
62 | merged. Once merging has started the snapshot device, associated with | ||
63 | the "snapshot" target, will return -EIO when accessed. | ||
64 | |||
65 | |||
66 | How snapshot is used by LVM2 | ||
67 | ============================ | ||
45 | When you create the first LVM2 snapshot of a volume, four dm devices are used: | 68 | When you create the first LVM2 snapshot of a volume, four dm devices are used: |
46 | 69 | ||
47 | 1) a device containing the original mapping table of the source volume; | 70 | 1) a device containing the original mapping table of the source volume; |
@@ -72,3 +95,30 @@ brw------- 1 root root 254, 12 29 ago 18:15 /dev/mapper/volumeGroup-snap-cow | |||
72 | brw------- 1 root root 254, 13 29 ago 18:15 /dev/mapper/volumeGroup-snap | 95 | brw------- 1 root root 254, 13 29 ago 18:15 /dev/mapper/volumeGroup-snap |
73 | brw------- 1 root root 254, 10 29 ago 18:14 /dev/mapper/volumeGroup-base | 96 | brw------- 1 root root 254, 10 29 ago 18:14 /dev/mapper/volumeGroup-base |
74 | 97 | ||
98 | |||
99 | How snapshot-merge is used by LVM2 | ||
100 | ================================== | ||
101 | A merging snapshot assumes the role of the "snapshot-origin" while | ||
102 | merging. As such the "snapshot-origin" is replaced with | ||
103 | "snapshot-merge". The "-real" device is not changed and the "-cow" | ||
104 | device is renamed to <origin name>-cow to aid LVM2's cleanup of the | ||
105 | merging snapshot after it completes. The "snapshot" that hands over its | ||
106 | COW device to the "snapshot-merge" is deactivated (unless using lvchange | ||
107 | --refresh); but if it is left active it will simply return I/O errors. | ||
108 | |||
109 | A snapshot will merge into its origin with the following command: | ||
110 | |||
111 | lvconvert --merge volumeGroup/snap | ||
112 | |||
113 | we'll now have this situation: | ||
114 | |||
115 | # dmsetup table|grep volumeGroup | ||
116 | |||
117 | volumeGroup-base-real: 0 2097152 linear 8:19 384 | ||
118 | volumeGroup-base-cow: 0 204800 linear 8:19 2097536 | ||
119 | volumeGroup-base: 0 2097152 snapshot-merge 254:11 254:12 P 16 | ||
120 | |||
121 | # ls -lL /dev/mapper/volumeGroup-* | ||
122 | brw------- 1 root root 254, 11 29 ago 18:15 /dev/mapper/volumeGroup-base-real | ||
123 | brw------- 1 root root 254, 12 29 ago 18:16 /dev/mapper/volumeGroup-base-cow | ||
124 | brw------- 1 root root 254, 10 29 ago 18:16 /dev/mapper/volumeGroup-base | ||
diff --git a/Documentation/fb/viafb.txt b/Documentation/fb/viafb.txt index 67dbf442b0b6..f3e046a6a987 100644 --- a/Documentation/fb/viafb.txt +++ b/Documentation/fb/viafb.txt | |||
@@ -7,7 +7,7 @@ | |||
7 | VIA UniChrome Family(CLE266, PM800 / CN400 / CN300, | 7 | VIA UniChrome Family(CLE266, PM800 / CN400 / CN300, |
8 | P4M800CE / P4M800Pro / CN700 / VN800, | 8 | P4M800CE / P4M800Pro / CN700 / VN800, |
9 | CX700 / VX700, K8M890, P4M890, | 9 | CX700 / VX700, K8M890, P4M890, |
10 | CN896 / P4M900, VX800) | 10 | CN896 / P4M900, VX800, VX855) |
11 | 11 | ||
12 | [Driver features] | 12 | [Driver features] |
13 | ------------------------ | 13 | ------------------------ |
@@ -154,13 +154,6 @@ | |||
154 | 0 : No Dual Edge Panel (default) | 154 | 0 : No Dual Edge Panel (default) |
155 | 1 : Dual Edge Panel | 155 | 1 : Dual Edge Panel |
156 | 156 | ||
157 | viafb_video_dev: | ||
158 | This option is used to specify video output devices(CRT, DVI, LCD) for | ||
159 | duoview case. | ||
160 | For example: | ||
161 | To output video on DVI, we should use: | ||
162 | modprobe viafb viafb_video_dev=DVI... | ||
163 | |||
164 | viafb_lcd_port: | 157 | viafb_lcd_port: |
165 | This option is used to specify LCD output port, | 158 | This option is used to specify LCD output port, |
166 | available values are "DVP0" "DVP1" "DFP_HIGHLOW" "DFP_HIGH" "DFP_LOW". | 159 | available values are "DVP0" "DVP1" "DFP_HIGHLOW" "DFP_HIGH" "DFP_LOW". |
@@ -181,9 +174,6 @@ Notes: | |||
181 | and bpp, need to call VIAFB specified ioctl interface VIAFB_SET_DEVICE | 174 | and bpp, need to call VIAFB specified ioctl interface VIAFB_SET_DEVICE |
182 | instead of calling common ioctl function FBIOPUT_VSCREENINFO since | 175 | instead of calling common ioctl function FBIOPUT_VSCREENINFO since |
183 | viafb doesn't support multi-head well, or it will cause screen crush. | 176 | viafb doesn't support multi-head well, or it will cause screen crush. |
184 | 4. VX800 2D accelerator hasn't been supported in this driver yet. When | ||
185 | using driver on VX800, the driver will disable the acceleration | ||
186 | function as default. | ||
187 | 177 | ||
188 | 178 | ||
189 | [Configure viafb with "fbset" tool] | 179 | [Configure viafb with "fbset" tool] |
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index eb2c138c277c..21ab9357326d 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt | |||
@@ -291,15 +291,6 @@ Who: Michael Buesch <mb@bu3sch.de> | |||
291 | 291 | ||
292 | --------------------------- | 292 | --------------------------- |
293 | 293 | ||
294 | What: print_fn_descriptor_symbol() | ||
295 | When: October 2009 | ||
296 | Why: The %pF vsprintf format provides the same functionality in a | ||
297 | simpler way. print_fn_descriptor_symbol() is deprecated but | ||
298 | still present to give out-of-tree modules time to change. | ||
299 | Who: Bjorn Helgaas <bjorn.helgaas@hp.com> | ||
300 | |||
301 | --------------------------- | ||
302 | |||
303 | What: /sys/o2cb symlink | 294 | What: /sys/o2cb symlink |
304 | When: January 2010 | 295 | When: January 2010 |
305 | Why: /sys/fs/o2cb is the proper location for this information - /sys/o2cb | 296 | Why: /sys/fs/o2cb is the proper location for this information - /sys/o2cb |
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index 94b9f2056f4c..220cc6376ef8 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt | |||
@@ -38,6 +38,7 @@ Table of Contents | |||
38 | 3.3 /proc/<pid>/io - Display the IO accounting fields | 38 | 3.3 /proc/<pid>/io - Display the IO accounting fields |
39 | 3.4 /proc/<pid>/coredump_filter - Core dump filtering settings | 39 | 3.4 /proc/<pid>/coredump_filter - Core dump filtering settings |
40 | 3.5 /proc/<pid>/mountinfo - Information about mounts | 40 | 3.5 /proc/<pid>/mountinfo - Information about mounts |
41 | 3.6 /proc/<pid>/comm & /proc/<pid>/task/<tid>/comm | ||
41 | 42 | ||
42 | 43 | ||
43 | ------------------------------------------------------------------------------ | 44 | ------------------------------------------------------------------------------ |
@@ -1409,3 +1410,11 @@ For more information on mount propagation see: | |||
1409 | 1410 | ||
1410 | Documentation/filesystems/sharedsubtree.txt | 1411 | Documentation/filesystems/sharedsubtree.txt |
1411 | 1412 | ||
1413 | |||
1414 | 3.6 /proc/<pid>/comm & /proc/<pid>/task/<tid>/comm | ||
1415 | -------------------------------------------------------- | ||
1416 | These files provide a method to access a tasks comm value. It also allows for | ||
1417 | a task to set its own or one of its thread siblings comm value. The comm value | ||
1418 | is limited in size compared to the cmdline value, so writing anything longer | ||
1419 | then the kernel's TASK_COMM_LEN (currently 16 chars) will result in a truncated | ||
1420 | comm value. | ||
diff --git a/Documentation/filesystems/seq_file.txt b/Documentation/filesystems/seq_file.txt index 0d15ebccf5b0..a1e2e0dda907 100644 --- a/Documentation/filesystems/seq_file.txt +++ b/Documentation/filesystems/seq_file.txt | |||
@@ -248,9 +248,7 @@ code, that is done in the initialization code in the usual way: | |||
248 | { | 248 | { |
249 | struct proc_dir_entry *entry; | 249 | struct proc_dir_entry *entry; |
250 | 250 | ||
251 | entry = create_proc_entry("sequence", 0, NULL); | 251 | proc_create("sequence", 0, NULL, &ct_file_ops); |
252 | if (entry) | ||
253 | entry->proc_fops = &ct_file_ops; | ||
254 | return 0; | 252 | return 0; |
255 | } | 253 | } |
256 | 254 | ||
diff --git a/Documentation/gpio.txt b/Documentation/gpio.txt index e4e7daed2ba8..1866c27eec69 100644 --- a/Documentation/gpio.txt +++ b/Documentation/gpio.txt | |||
@@ -531,6 +531,13 @@ and have the following read/write attributes: | |||
531 | This file exists only if the pin can be configured as an | 531 | This file exists only if the pin can be configured as an |
532 | interrupt generating input pin. | 532 | interrupt generating input pin. |
533 | 533 | ||
534 | "active_low" ... reads as either 0 (false) or 1 (true). Write | ||
535 | any nonzero value to invert the value attribute both | ||
536 | for reading and writing. Existing and subsequent | ||
537 | poll(2) support configuration via the edge attribute | ||
538 | for "rising" and "falling" edges will follow this | ||
539 | setting. | ||
540 | |||
534 | GPIO controllers have paths like /sys/class/gpio/gpiochip42/ (for the | 541 | GPIO controllers have paths like /sys/class/gpio/gpiochip42/ (for the |
535 | controller implementing GPIOs starting at #42) and have the following | 542 | controller implementing GPIOs starting at #42) and have the following |
536 | read-only attributes: | 543 | read-only attributes: |
@@ -566,6 +573,8 @@ requested using gpio_request(): | |||
566 | int gpio_export_link(struct device *dev, const char *name, | 573 | int gpio_export_link(struct device *dev, const char *name, |
567 | unsigned gpio) | 574 | unsigned gpio) |
568 | 575 | ||
576 | /* change the polarity of a GPIO node in sysfs */ | ||
577 | int gpio_sysfs_set_active_low(unsigned gpio, int value); | ||
569 | 578 | ||
570 | After a kernel driver requests a GPIO, it may only be made available in | 579 | After a kernel driver requests a GPIO, it may only be made available in |
571 | the sysfs interface by gpio_export(). The driver can control whether the | 580 | the sysfs interface by gpio_export(). The driver can control whether the |
@@ -580,3 +589,9 @@ After the GPIO has been exported, gpio_export_link() allows creating | |||
580 | symlinks from elsewhere in sysfs to the GPIO sysfs node. Drivers can | 589 | symlinks from elsewhere in sysfs to the GPIO sysfs node. Drivers can |
581 | use this to provide the interface under their own device in sysfs with | 590 | use this to provide the interface under their own device in sysfs with |
582 | a descriptive name. | 591 | a descriptive name. |
592 | |||
593 | Drivers can use gpio_sysfs_set_active_low() to hide GPIO line polarity | ||
594 | differences between boards from user space. This only affects the | ||
595 | sysfs interface. Polarity change can be done both before and after | ||
596 | gpio_export(), and previously enabled poll(2) support for either | ||
597 | rising or falling edge will be reconfigured to follow this setting. | ||
diff --git a/Documentation/hwmon/lis3lv02d b/Documentation/hwmon/lis3lv02d index effe949a7282..06534f25e643 100644 --- a/Documentation/hwmon/lis3lv02d +++ b/Documentation/hwmon/lis3lv02d | |||
@@ -3,7 +3,8 @@ Kernel driver lis3lv02d | |||
3 | 3 | ||
4 | Supported chips: | 4 | Supported chips: |
5 | 5 | ||
6 | * STMicroelectronics LIS3LV02DL and LIS3LV02DQ | 6 | * STMicroelectronics LIS3LV02DL, LIS3LV02DQ (12 bits precision) |
7 | * STMicroelectronics LIS302DL, LIS3L02DQ, LIS331DL (8 bits) | ||
7 | 8 | ||
8 | Authors: | 9 | Authors: |
9 | Yan Burman <burman.yan@gmail.com> | 10 | Yan Burman <burman.yan@gmail.com> |
@@ -13,32 +14,52 @@ Authors: | |||
13 | Description | 14 | Description |
14 | ----------- | 15 | ----------- |
15 | 16 | ||
16 | This driver provides support for the accelerometer found in various HP | 17 | This driver provides support for the accelerometer found in various HP laptops |
17 | laptops sporting the feature officially called "HP Mobile Data | 18 | sporting the feature officially called "HP Mobile Data Protection System 3D" or |
18 | Protection System 3D" or "HP 3D DriveGuard". It detects automatically | 19 | "HP 3D DriveGuard". It detects automatically laptops with this sensor. Known |
19 | laptops with this sensor. Known models (for now the HP 2133, nc6420, | 20 | models (full list can be found in drivers/hwmon/hp_accel.c) will have their |
20 | nc2510, nc8510, nc84x0, nw9440 and nx9420) will have their axis | 21 | axis automatically oriented on standard way (eg: you can directly play |
21 | automatically oriented on standard way (eg: you can directly play | 22 | neverball). The accelerometer data is readable via |
22 | neverball). The accelerometer data is readable via | 23 | /sys/devices/platform/lis3lv02d. Reported values are scaled |
23 | /sys/devices/platform/lis3lv02d. | 24 | to mg values (1/1000th of earth gravity). |
24 | 25 | ||
25 | Sysfs attributes under /sys/devices/platform/lis3lv02d/: | 26 | Sysfs attributes under /sys/devices/platform/lis3lv02d/: |
26 | position - 3D position that the accelerometer reports. Format: "(x,y,z)" | 27 | position - 3D position that the accelerometer reports. Format: "(x,y,z)" |
27 | calibrate - read: values (x, y, z) that are used as the base for input | 28 | rate - read reports the sampling rate of the accelerometer device in HZ. |
28 | class device operation. | 29 | write changes sampling rate of the accelerometer device. |
29 | write: forces the base to be recalibrated with the current | 30 | Only values which are supported by HW are accepted. |
30 | position. | 31 | selftest - performs selftest for the chip as specified by chip manufacturer. |
31 | rate - reports the sampling rate of the accelerometer device in HZ | ||
32 | 32 | ||
33 | This driver also provides an absolute input class device, allowing | 33 | This driver also provides an absolute input class device, allowing |
34 | the laptop to act as a pinball machine-esque joystick. | 34 | the laptop to act as a pinball machine-esque joystick. Joystick device can be |
35 | calibrated. Joystick device can be in two different modes. | ||
36 | By default output values are scaled between -32768 .. 32767. In joystick raw | ||
37 | mode, joystick and sysfs position entry have the same scale. There can be | ||
38 | small difference due to input system fuzziness feature. | ||
39 | Events are also available as input event device. | ||
40 | |||
41 | Selftest is meant only for hardware diagnostic purposes. It is not meant to be | ||
42 | used during normal operations. Position data is not corrupted during selftest | ||
43 | but interrupt behaviour is not guaranteed to work reliably. In test mode, the | ||
44 | sensing element is internally moved little bit. Selftest measures difference | ||
45 | between normal mode and test mode. Chip specifications tell the acceptance | ||
46 | limit for each type of the chip. Limits are provided via platform data | ||
47 | to allow adjustment of the limits without a change to the actual driver. | ||
48 | Seltest returns either "OK x y z" or "FAIL x y z" where x, y and z are | ||
49 | measured difference between modes. Axes are not remapped in selftest mode. | ||
50 | Measurement values are provided to help HW diagnostic applications to make | ||
51 | final decision. | ||
52 | |||
53 | On HP laptops, if the led infrastructure is activated, support for a led | ||
54 | indicating disk protection will be provided as /sys/class/leds/hp::hddprotect. | ||
35 | 55 | ||
36 | Another feature of the driver is misc device called "freefall" that | 56 | Another feature of the driver is misc device called "freefall" that |
37 | acts similar to /dev/rtc and reacts on free-fall interrupts received | 57 | acts similar to /dev/rtc and reacts on free-fall interrupts received |
38 | from the device. It supports blocking operations, poll/select and | 58 | from the device. It supports blocking operations, poll/select and |
39 | fasync operation modes. You must read 1 bytes from the device. The | 59 | fasync operation modes. You must read 1 bytes from the device. The |
40 | result is number of free-fall interrupts since the last successful | 60 | result is number of free-fall interrupts since the last successful |
41 | read (or 255 if number of interrupts would not fit). | 61 | read (or 255 if number of interrupts would not fit). See the hpfall.c |
62 | file for an example on using the device. | ||
42 | 63 | ||
43 | 64 | ||
44 | Axes orientation | 65 | Axes orientation |
@@ -55,7 +76,7 @@ the accelerometer are converted into a "standard" organisation of the axes | |||
55 | * If the laptop is put upside-down, Z becomes negative | 76 | * If the laptop is put upside-down, Z becomes negative |
56 | 77 | ||
57 | If your laptop model is not recognized (cf "dmesg"), you can send an | 78 | If your laptop model is not recognized (cf "dmesg"), you can send an |
58 | email to the authors to add it to the database. When reporting a new | 79 | email to the maintainer to add it to the database. When reporting a new |
59 | laptop, please include the output of "dmidecode" plus the value of | 80 | laptop, please include the output of "dmidecode" plus the value of |
60 | /sys/devices/platform/lis3lv02d/position in these four cases. | 81 | /sys/devices/platform/lis3lv02d/position in these four cases. |
61 | 82 | ||
diff --git a/Documentation/hwmon/w83627ehf b/Documentation/hwmon/w83627ehf index 02b74899edaf..b7e42ec4b26b 100644 --- a/Documentation/hwmon/w83627ehf +++ b/Documentation/hwmon/w83627ehf | |||
@@ -81,8 +81,14 @@ pwm[1-4] - this file stores PWM duty cycle or DC value (fan speed) in range: | |||
81 | 0 (stop) to 255 (full) | 81 | 0 (stop) to 255 (full) |
82 | 82 | ||
83 | pwm[1-4]_enable - this file controls mode of fan/temperature control: | 83 | pwm[1-4]_enable - this file controls mode of fan/temperature control: |
84 | * 1 Manual Mode, write to pwm file any value 0-255 (full speed) | 84 | * 1 Manual mode, write to pwm file any value 0-255 (full speed) |
85 | * 2 Thermal Cruise | 85 | * 2 "Thermal Cruise" mode |
86 | * 3 "Fan Speed Cruise" mode | ||
87 | * 4 "Smart Fan III" mode | ||
88 | |||
89 | pwm[1-4]_mode - controls if output is PWM or DC level | ||
90 | * 0 DC output (0 - 12v) | ||
91 | * 1 PWM output | ||
86 | 92 | ||
87 | Thermal Cruise mode | 93 | Thermal Cruise mode |
88 | ------------------- | 94 | ------------------- |
diff --git a/Documentation/i2c/writing-clients b/Documentation/i2c/writing-clients index 7860aafb483d..0a74603eb671 100644 --- a/Documentation/i2c/writing-clients +++ b/Documentation/i2c/writing-clients | |||
@@ -44,7 +44,7 @@ static struct i2c_driver foo_driver = { | |||
44 | /* if device autodetection is needed: */ | 44 | /* if device autodetection is needed: */ |
45 | .class = I2C_CLASS_SOMETHING, | 45 | .class = I2C_CLASS_SOMETHING, |
46 | .detect = foo_detect, | 46 | .detect = foo_detect, |
47 | .address_data = &addr_data, | 47 | .address_list = normal_i2c, |
48 | 48 | ||
49 | .shutdown = foo_shutdown, /* optional */ | 49 | .shutdown = foo_shutdown, /* optional */ |
50 | .suspend = foo_suspend, /* optional */ | 50 | .suspend = foo_suspend, /* optional */ |
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index ab95d3ada5c7..c309515ae959 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt | |||
@@ -2729,6 +2729,11 @@ and is between 256 and 4096 characters. It is defined in the file | |||
2729 | vmpoff= [KNL,S390] Perform z/VM CP command after power off. | 2729 | vmpoff= [KNL,S390] Perform z/VM CP command after power off. |
2730 | Format: <command> | 2730 | Format: <command> |
2731 | 2731 | ||
2732 | vt.cur_default= [VT] Default cursor shape. | ||
2733 | Format: 0xCCBBAA, where AA, BB, and CC are the same as | ||
2734 | the parameters of the <Esc>[?A;B;Cc escape sequence; | ||
2735 | see VGA-softcursor.txt. Default: 2 = underline. | ||
2736 | |||
2732 | vt.default_blu= [VT] | 2737 | vt.default_blu= [VT] |
2733 | Format: <blue0>,<blue1>,<blue2>,...,<blue15> | 2738 | Format: <blue0>,<blue1>,<blue2>,...,<blue15> |
2734 | Change the default blue palette of the console. | 2739 | Change the default blue palette of the console. |
diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt index bbc8a6a36921..57e7e9cc1870 100644 --- a/Documentation/memory-hotplug.txt +++ b/Documentation/memory-hotplug.txt | |||
@@ -160,12 +160,15 @@ Under each section, you can see 4 files. | |||
160 | NOTE: | 160 | NOTE: |
161 | These directories/files appear after physical memory hotplug phase. | 161 | These directories/files appear after physical memory hotplug phase. |
162 | 162 | ||
163 | If CONFIG_NUMA is enabled the | 163 | If CONFIG_NUMA is enabled the memoryXXX/ directories can also be accessed |
164 | /sys/devices/system/memory/memoryXXX memory section | 164 | via symbolic links located in the /sys/devices/system/node/node* directories. |
165 | directories can also be accessed via symbolic links located in | 165 | |
166 | the /sys/devices/system/node/node* directories. For example: | 166 | For example: |
167 | /sys/devices/system/node/node0/memory9 -> ../../memory/memory9 | 167 | /sys/devices/system/node/node0/memory9 -> ../../memory/memory9 |
168 | 168 | ||
169 | A backlink will also be created: | ||
170 | /sys/devices/system/memory/memory9/node0 -> ../../node/node0 | ||
171 | |||
169 | -------------------------------- | 172 | -------------------------------- |
170 | 4. Physical memory hot-add phase | 173 | 4. Physical memory hot-add phase |
171 | -------------------------------- | 174 | -------------------------------- |
diff --git a/Documentation/misc-devices/ad525x_dpot.txt b/Documentation/misc-devices/ad525x_dpot.txt new file mode 100644 index 000000000000..0c9413b1cbf3 --- /dev/null +++ b/Documentation/misc-devices/ad525x_dpot.txt | |||
@@ -0,0 +1,57 @@ | |||
1 | --------------------------------- | ||
2 | AD525x Digital Potentiometers | ||
3 | --------------------------------- | ||
4 | |||
5 | The ad525x_dpot driver exports a simple sysfs interface. This allows you to | ||
6 | work with the immediate resistance settings as well as update the saved startup | ||
7 | settings. Access to the factory programmed tolerance is also provided, but | ||
8 | interpretation of this settings is required by the end application according to | ||
9 | the specific part in use. | ||
10 | |||
11 | --------- | ||
12 | Files | ||
13 | --------- | ||
14 | |||
15 | Each dpot device will have a set of eeprom, rdac, and tolerance files. How | ||
16 | many depends on the actual part you have, as will the range of allowed values. | ||
17 | |||
18 | The eeprom files are used to program the startup value of the device. | ||
19 | |||
20 | The rdac files are used to program the immediate value of the device. | ||
21 | |||
22 | The tolerance files are the read-only factory programmed tolerance settings | ||
23 | and may vary greatly on a part-by-part basis. For exact interpretation of | ||
24 | this field, please consult the datasheet for your part. This is presented | ||
25 | as a hex file for easier parsing. | ||
26 | |||
27 | ----------- | ||
28 | Example | ||
29 | ----------- | ||
30 | |||
31 | Locate the device in your sysfs tree. This is probably easiest by going into | ||
32 | the common i2c directory and locating the device by the i2c slave address. | ||
33 | |||
34 | # ls /sys/bus/i2c/devices/ | ||
35 | 0-0022 0-0027 0-002f | ||
36 | |||
37 | So assuming the device in question is on the first i2c bus and has the slave | ||
38 | address of 0x2f, we descend (unrelated sysfs entries have been trimmed). | ||
39 | |||
40 | # ls /sys/bus/i2c/devices/0-002f/ | ||
41 | eeprom0 rdac0 tolerance0 | ||
42 | |||
43 | You can use simple reads/writes to access these files: | ||
44 | |||
45 | # cd /sys/bus/i2c/devices/0-002f/ | ||
46 | |||
47 | # cat eeprom0 | ||
48 | 0 | ||
49 | # echo 10 > eeprom0 | ||
50 | # cat eeprom0 | ||
51 | 10 | ||
52 | |||
53 | # cat rdac0 | ||
54 | 5 | ||
55 | # echo 3 > rdac0 | ||
56 | # cat rdac0 | ||
57 | 3 | ||
diff --git a/Documentation/nommu-mmap.txt b/Documentation/nommu-mmap.txt index b565e8279d13..8e1ddec2c78a 100644 --- a/Documentation/nommu-mmap.txt +++ b/Documentation/nommu-mmap.txt | |||
@@ -119,6 +119,32 @@ FURTHER NOTES ON NO-MMU MMAP | |||
119 | granule but will only discard the excess if appropriately configured as | 119 | granule but will only discard the excess if appropriately configured as |
120 | this has an effect on fragmentation. | 120 | this has an effect on fragmentation. |
121 | 121 | ||
122 | (*) The memory allocated by a request for an anonymous mapping will normally | ||
123 | be cleared by the kernel before being returned in accordance with the | ||
124 | Linux man pages (ver 2.22 or later). | ||
125 | |||
126 | In the MMU case this can be achieved with reasonable performance as | ||
127 | regions are backed by virtual pages, with the contents only being mapped | ||
128 | to cleared physical pages when a write happens on that specific page | ||
129 | (prior to which, the pages are effectively mapped to the global zero page | ||
130 | from which reads can take place). This spreads out the time it takes to | ||
131 | initialize the contents of a page - depending on the write-usage of the | ||
132 | mapping. | ||
133 | |||
134 | In the no-MMU case, however, anonymous mappings are backed by physical | ||
135 | pages, and the entire map is cleared at allocation time. This can cause | ||
136 | significant delays during a userspace malloc() as the C library does an | ||
137 | anonymous mapping and the kernel then does a memset for the entire map. | ||
138 | |||
139 | However, for memory that isn't required to be precleared - such as that | ||
140 | returned by malloc() - mmap() can take a MAP_UNINITIALIZED flag to | ||
141 | indicate to the kernel that it shouldn't bother clearing the memory before | ||
142 | returning it. Note that CONFIG_MMAP_ALLOW_UNINITIALIZED must be enabled | ||
143 | to permit this, otherwise the flag will be ignored. | ||
144 | |||
145 | uClibc uses this to speed up malloc(), and the ELF-FDPIC binfmt uses this | ||
146 | to allocate the brk and stack region. | ||
147 | |||
122 | (*) A list of all the private copy and anonymous mappings on the system is | 148 | (*) A list of all the private copy and anonymous mappings on the system is |
123 | visible through /proc/maps in no-MMU mode. | 149 | visible through /proc/maps in no-MMU mode. |
124 | 150 | ||
diff --git a/Documentation/powerpc/dts-bindings/4xx/ppc440spe-adma.txt b/Documentation/powerpc/dts-bindings/4xx/ppc440spe-adma.txt new file mode 100644 index 000000000000..515ebcf1b97d --- /dev/null +++ b/Documentation/powerpc/dts-bindings/4xx/ppc440spe-adma.txt | |||
@@ -0,0 +1,93 @@ | |||
1 | PPC440SPe DMA/XOR (DMA Controller and XOR Accelerator) | ||
2 | |||
3 | Device nodes needed for operation of the ppc440spe-adma driver | ||
4 | are specified hereby. These are I2O/DMA, DMA and XOR nodes | ||
5 | for DMA engines and Memory Queue Module node. The latter is used | ||
6 | by ADMA driver for configuration of RAID-6 H/W capabilities of | ||
7 | the PPC440SPe. In addition to the nodes and properties described | ||
8 | below, the ranges property of PLB node must specify ranges for | ||
9 | DMA devices. | ||
10 | |||
11 | i) The I2O node | ||
12 | |||
13 | Required properties: | ||
14 | |||
15 | - compatible : "ibm,i2o-440spe"; | ||
16 | - reg : <registers mapping> | ||
17 | - dcr-reg : <DCR registers range> | ||
18 | |||
19 | Example: | ||
20 | |||
21 | I2O: i2o@400100000 { | ||
22 | compatible = "ibm,i2o-440spe"; | ||
23 | reg = <0x00000004 0x00100000 0x100>; | ||
24 | dcr-reg = <0x060 0x020>; | ||
25 | }; | ||
26 | |||
27 | |||
28 | ii) The DMA node | ||
29 | |||
30 | Required properties: | ||
31 | |||
32 | - compatible : "ibm,dma-440spe"; | ||
33 | - cell-index : 1 cell, hardware index of the DMA engine | ||
34 | (typically 0x0 and 0x1 for DMA0 and DMA1) | ||
35 | - reg : <registers mapping> | ||
36 | - dcr-reg : <DCR registers range> | ||
37 | - interrupts : <interrupt mapping for DMA0/1 interrupts sources: | ||
38 | 2 sources: DMAx CS FIFO Needs Service IRQ (on UIC0) | ||
39 | and DMA Error IRQ (on UIC1). The latter is common | ||
40 | for both DMA engines>. | ||
41 | - interrupt-parent : needed for interrupt mapping | ||
42 | |||
43 | Example: | ||
44 | |||
45 | DMA0: dma0@400100100 { | ||
46 | compatible = "ibm,dma-440spe"; | ||
47 | cell-index = <0>; | ||
48 | reg = <0x00000004 0x00100100 0x100>; | ||
49 | dcr-reg = <0x060 0x020>; | ||
50 | interrupt-parent = <&DMA0>; | ||
51 | interrupts = <0 1>; | ||
52 | #interrupt-cells = <1>; | ||
53 | #address-cells = <0>; | ||
54 | #size-cells = <0>; | ||
55 | interrupt-map = < | ||
56 | 0 &UIC0 0x14 4 | ||
57 | 1 &UIC1 0x16 4>; | ||
58 | }; | ||
59 | |||
60 | |||
61 | iii) XOR Accelerator node | ||
62 | |||
63 | Required properties: | ||
64 | |||
65 | - compatible : "amcc,xor-accelerator"; | ||
66 | - reg : <registers mapping> | ||
67 | - interrupts : <interrupt mapping for XOR interrupt source> | ||
68 | - interrupt-parent : for interrupt mapping | ||
69 | |||
70 | Example: | ||
71 | |||
72 | xor-accel@400200000 { | ||
73 | compatible = "amcc,xor-accelerator"; | ||
74 | reg = <0x00000004 0x00200000 0x400>; | ||
75 | interrupt-parent = <&UIC1>; | ||
76 | interrupts = <0x1f 4>; | ||
77 | }; | ||
78 | |||
79 | |||
80 | iv) Memory Queue Module node | ||
81 | |||
82 | Required properties: | ||
83 | |||
84 | - compatible : "ibm,mq-440spe"; | ||
85 | - dcr-reg : <DCR registers range> | ||
86 | |||
87 | Example: | ||
88 | |||
89 | MQ0: mq { | ||
90 | compatible = "ibm,mq-440spe"; | ||
91 | dcr-reg = <0x040 0x020>; | ||
92 | }; | ||
93 | |||
diff --git a/Documentation/video4linux/gspca.txt b/Documentation/video4linux/gspca.txt index 319d9838e87e..1800a62cf135 100644 --- a/Documentation/video4linux/gspca.txt +++ b/Documentation/video4linux/gspca.txt | |||
@@ -12,6 +12,7 @@ m5602 0402:5602 ALi Video Camera Controller | |||
12 | spca501 040a:0002 Kodak DVC-325 | 12 | spca501 040a:0002 Kodak DVC-325 |
13 | spca500 040a:0300 Kodak EZ200 | 13 | spca500 040a:0300 Kodak EZ200 |
14 | zc3xx 041e:041e Creative WebCam Live! | 14 | zc3xx 041e:041e Creative WebCam Live! |
15 | ov519 041e:4003 Video Blaster WebCam Go Plus | ||
15 | spca500 041e:400a Creative PC-CAM 300 | 16 | spca500 041e:400a Creative PC-CAM 300 |
16 | sunplus 041e:400b Creative PC-CAM 600 | 17 | sunplus 041e:400b Creative PC-CAM 600 |
17 | sunplus 041e:4012 PC-Cam350 | 18 | sunplus 041e:4012 PC-Cam350 |
@@ -168,10 +169,14 @@ sunplus 055f:c650 Mustek MDC5500Z | |||
168 | zc3xx 055f:d003 Mustek WCam300A | 169 | zc3xx 055f:d003 Mustek WCam300A |
169 | zc3xx 055f:d004 Mustek WCam300 AN | 170 | zc3xx 055f:d004 Mustek WCam300 AN |
170 | conex 0572:0041 Creative Notebook cx11646 | 171 | conex 0572:0041 Creative Notebook cx11646 |
172 | ov519 05a9:0511 Video Blaster WebCam 3/WebCam Plus, D-Link USB Digital Video Camera | ||
173 | ov519 05a9:0518 Creative WebCam | ||
171 | ov519 05a9:0519 OV519 Microphone | 174 | ov519 05a9:0519 OV519 Microphone |
172 | ov519 05a9:0530 OmniVision | 175 | ov519 05a9:0530 OmniVision |
176 | ov519 05a9:2800 OmniVision SuperCAM | ||
173 | ov519 05a9:4519 Webcam Classic | 177 | ov519 05a9:4519 Webcam Classic |
174 | ov519 05a9:8519 OmniVision | 178 | ov519 05a9:8519 OmniVision |
179 | ov519 05a9:a511 D-Link USB Digital Video Camera | ||
175 | ov519 05a9:a518 D-Link DSB-C310 Webcam | 180 | ov519 05a9:a518 D-Link DSB-C310 Webcam |
176 | sunplus 05da:1018 Digital Dream Enigma 1.3 | 181 | sunplus 05da:1018 Digital Dream Enigma 1.3 |
177 | stk014 05e1:0893 Syntek DV4000 | 182 | stk014 05e1:0893 Syntek DV4000 |
@@ -187,7 +192,7 @@ ov534 06f8:3002 Hercules Blog Webcam | |||
187 | ov534 06f8:3003 Hercules Dualpix HD Weblog | 192 | ov534 06f8:3003 Hercules Dualpix HD Weblog |
188 | sonixj 06f8:3004 Hercules Classic Silver | 193 | sonixj 06f8:3004 Hercules Classic Silver |
189 | sonixj 06f8:3008 Hercules Deluxe Optical Glass | 194 | sonixj 06f8:3008 Hercules Deluxe Optical Glass |
190 | pac7311 06f8:3009 Hercules Classic Link | 195 | pac7302 06f8:3009 Hercules Classic Link |
191 | spca508 0733:0110 ViewQuest VQ110 | 196 | spca508 0733:0110 ViewQuest VQ110 |
192 | spca501 0733:0401 Intel Create and Share | 197 | spca501 0733:0401 Intel Create and Share |
193 | spca501 0733:0402 ViewQuest M318B | 198 | spca501 0733:0402 ViewQuest M318B |
@@ -199,6 +204,7 @@ sunplus 0733:2221 Mercury Digital Pro 3.1p | |||
199 | sunplus 0733:3261 Concord 3045 spca536a | 204 | sunplus 0733:3261 Concord 3045 spca536a |
200 | sunplus 0733:3281 Cyberpix S550V | 205 | sunplus 0733:3281 Cyberpix S550V |
201 | spca506 0734:043b 3DeMon USB Capture aka | 206 | spca506 0734:043b 3DeMon USB Capture aka |
207 | ov519 0813:0002 Dual Mode USB Camera Plus | ||
202 | spca500 084d:0003 D-Link DSC-350 | 208 | spca500 084d:0003 D-Link DSC-350 |
203 | spca500 08ca:0103 Aiptek PocketDV | 209 | spca500 08ca:0103 Aiptek PocketDV |
204 | sunplus 08ca:0104 Aiptek PocketDVII 1.3 | 210 | sunplus 08ca:0104 Aiptek PocketDVII 1.3 |
@@ -236,15 +242,15 @@ pac7311 093a:2603 Philips SPC 500 NC | |||
236 | pac7311 093a:2608 Trust WB-3300p | 242 | pac7311 093a:2608 Trust WB-3300p |
237 | pac7311 093a:260e Gigaware VGA PC Camera, Trust WB-3350p, SIGMA cam 2350 | 243 | pac7311 093a:260e Gigaware VGA PC Camera, Trust WB-3350p, SIGMA cam 2350 |
238 | pac7311 093a:260f SnakeCam | 244 | pac7311 093a:260f SnakeCam |
239 | pac7311 093a:2620 Apollo AC-905 | 245 | pac7302 093a:2620 Apollo AC-905 |
240 | pac7311 093a:2621 PAC731x | 246 | pac7302 093a:2621 PAC731x |
241 | pac7311 093a:2622 Genius Eye 312 | 247 | pac7302 093a:2622 Genius Eye 312 |
242 | pac7311 093a:2624 PAC7302 | 248 | pac7302 093a:2624 PAC7302 |
243 | pac7311 093a:2626 Labtec 2200 | 249 | pac7302 093a:2626 Labtec 2200 |
244 | pac7311 093a:2628 Genius iLook 300 | 250 | pac7302 093a:2628 Genius iLook 300 |
245 | pac7311 093a:2629 Genious iSlim 300 | 251 | pac7302 093a:2629 Genious iSlim 300 |
246 | pac7311 093a:262a Webcam 300k | 252 | pac7302 093a:262a Webcam 300k |
247 | pac7311 093a:262c Philips SPC 230 NC | 253 | pac7302 093a:262c Philips SPC 230 NC |
248 | jeilinj 0979:0280 Sakar 57379 | 254 | jeilinj 0979:0280 Sakar 57379 |
249 | zc3xx 0ac8:0302 Z-star Vimicro zc0302 | 255 | zc3xx 0ac8:0302 Z-star Vimicro zc0302 |
250 | vc032x 0ac8:0321 Vimicro generic vc0321 | 256 | vc032x 0ac8:0321 Vimicro generic vc0321 |
@@ -259,6 +265,7 @@ vc032x 0ac8:c002 Sony embedded vimicro | |||
259 | vc032x 0ac8:c301 Samsung Q1 Ultra Premium | 265 | vc032x 0ac8:c301 Samsung Q1 Ultra Premium |
260 | spca508 0af9:0010 Hama USB Sightcam 100 | 266 | spca508 0af9:0010 Hama USB Sightcam 100 |
261 | spca508 0af9:0011 Hama USB Sightcam 100 | 267 | spca508 0af9:0011 Hama USB Sightcam 100 |
268 | ov519 0b62:0059 iBOT2 Webcam | ||
262 | sonixb 0c45:6001 Genius VideoCAM NB | 269 | sonixb 0c45:6001 Genius VideoCAM NB |
263 | sonixb 0c45:6005 Microdia Sweex Mini Webcam | 270 | sonixb 0c45:6005 Microdia Sweex Mini Webcam |
264 | sonixb 0c45:6007 Sonix sn9c101 + Tas5110D | 271 | sonixb 0c45:6007 Sonix sn9c101 + Tas5110D |
@@ -318,8 +325,10 @@ sn9c20x 0c45:62b3 PC Camera (SN9C202 + OV9655) | |||
318 | sn9c20x 0c45:62bb PC Camera (SN9C202 + OV7660) | 325 | sn9c20x 0c45:62bb PC Camera (SN9C202 + OV7660) |
319 | sn9c20x 0c45:62bc PC Camera (SN9C202 + HV7131R) | 326 | sn9c20x 0c45:62bc PC Camera (SN9C202 + HV7131R) |
320 | sunplus 0d64:0303 Sunplus FashionCam DXG | 327 | sunplus 0d64:0303 Sunplus FashionCam DXG |
328 | ov519 0e96:c001 TRUST 380 USB2 SPACEC@M | ||
321 | etoms 102c:6151 Qcam Sangha CIF | 329 | etoms 102c:6151 Qcam Sangha CIF |
322 | etoms 102c:6251 Qcam xxxxxx VGA | 330 | etoms 102c:6251 Qcam xxxxxx VGA |
331 | ov519 1046:9967 W9967CF/W9968CF WebCam IC, Video Blaster WebCam Go | ||
323 | zc3xx 10fd:0128 Typhoon Webshot II USB 300k 0x0128 | 332 | zc3xx 10fd:0128 Typhoon Webshot II USB 300k 0x0128 |
324 | spca561 10fd:7e50 FlyCam Usb 100 | 333 | spca561 10fd:7e50 FlyCam Usb 100 |
325 | zc3xx 10fd:8050 Typhoon Webshot II USB 300k | 334 | zc3xx 10fd:8050 Typhoon Webshot II USB 300k |
@@ -332,7 +341,12 @@ spca501 1776:501c Arowana 300K CMOS Camera | |||
332 | t613 17a1:0128 TASCORP JPEG Webcam, NGS Cyclops | 341 | t613 17a1:0128 TASCORP JPEG Webcam, NGS Cyclops |
333 | vc032x 17ef:4802 Lenovo Vc0323+MI1310_SOC | 342 | vc032x 17ef:4802 Lenovo Vc0323+MI1310_SOC |
334 | pac207 2001:f115 D-Link DSB-C120 | 343 | pac207 2001:f115 D-Link DSB-C120 |
344 | sq905c 2770:9050 sq905c | ||
345 | sq905c 2770:905c DualCamera | ||
346 | sq905 2770:9120 Argus Digital Camera DC1512 | ||
347 | sq905c 2770:913d sq905c | ||
335 | spca500 2899:012c Toptro Industrial | 348 | spca500 2899:012c Toptro Industrial |
349 | ov519 8020:ef04 ov519 | ||
336 | spca508 8086:0110 Intel Easy PC Camera | 350 | spca508 8086:0110 Intel Easy PC Camera |
337 | spca500 8086:0630 Intel Pocket PC Camera | 351 | spca500 8086:0630 Intel Pocket PC Camera |
338 | spca506 99fa:8988 Grandtec V.cap | 352 | spca506 99fa:8988 Grandtec V.cap |
diff --git a/Documentation/video4linux/sh_mobile_ceu_camera.txt b/Documentation/video4linux/sh_mobile_ceu_camera.txt new file mode 100644 index 000000000000..2ae16349a78d --- /dev/null +++ b/Documentation/video4linux/sh_mobile_ceu_camera.txt | |||
@@ -0,0 +1,157 @@ | |||
1 | Cropping and Scaling algorithm, used in the sh_mobile_ceu_camera driver | ||
2 | ======================================================================= | ||
3 | |||
4 | Terminology | ||
5 | ----------- | ||
6 | |||
7 | sensor scales: horizontal and vertical scales, configured by the sensor driver | ||
8 | host scales: -"- host driver | ||
9 | combined scales: sensor_scale * host_scale | ||
10 | |||
11 | |||
12 | Generic scaling / cropping scheme | ||
13 | --------------------------------- | ||
14 | |||
15 | -1-- | ||
16 | | | ||
17 | -2-- -\ | ||
18 | | --\ | ||
19 | | --\ | ||
20 | +-5-- -\ -- -3-- | ||
21 | | ---\ | ||
22 | | --- -4-- -\ | ||
23 | | -\ | ||
24 | | - -6-- | ||
25 | | | ||
26 | | - -6'- | ||
27 | | -/ | ||
28 | | --- -4'- -/ | ||
29 | | ---/ | ||
30 | +-5'- -/ | ||
31 | | -- -3'- | ||
32 | | --/ | ||
33 | | --/ | ||
34 | -2'- -/ | ||
35 | | | ||
36 | | | ||
37 | -1'- | ||
38 | |||
39 | Produced by user requests: | ||
40 | |||
41 | S_CROP(left / top = (5) - (1), width / height = (5') - (5)) | ||
42 | S_FMT(width / height = (6') - (6)) | ||
43 | |||
44 | Here: | ||
45 | |||
46 | (1) to (1') - whole max width or height | ||
47 | (1) to (2) - sensor cropped left or top | ||
48 | (2) to (2') - sensor cropped width or height | ||
49 | (3) to (3') - sensor scale | ||
50 | (3) to (4) - CEU cropped left or top | ||
51 | (4) to (4') - CEU cropped width or height | ||
52 | (5) to (5') - reverse sensor scale applied to CEU cropped width or height | ||
53 | (2) to (5) - reverse sensor scale applied to CEU cropped left or top | ||
54 | (6) to (6') - CEU scale - user window | ||
55 | |||
56 | |||
57 | S_FMT | ||
58 | ----- | ||
59 | |||
60 | Do not touch input rectangle - it is already optimal. | ||
61 | |||
62 | 1. Calculate current sensor scales: | ||
63 | |||
64 | scale_s = ((3') - (3)) / ((2') - (2)) | ||
65 | |||
66 | 2. Calculate "effective" input crop (sensor subwindow) - CEU crop scaled back at | ||
67 | current sensor scales onto input window - this is user S_CROP: | ||
68 | |||
69 | width_u = (5') - (5) = ((4') - (4)) * scale_s | ||
70 | |||
71 | 3. Calculate new combined scales from "effective" input window to requested user | ||
72 | window: | ||
73 | |||
74 | scale_comb = width_u / ((6') - (6)) | ||
75 | |||
76 | 4. Calculate sensor output window by applying combined scales to real input | ||
77 | window: | ||
78 | |||
79 | width_s_out = ((2') - (2)) / scale_comb | ||
80 | |||
81 | 5. Apply iterative sensor S_FMT for sensor output window. | ||
82 | |||
83 | subdev->video_ops->s_fmt(.width = width_s_out) | ||
84 | |||
85 | 6. Retrieve sensor output window (g_fmt) | ||
86 | |||
87 | 7. Calculate new sensor scales: | ||
88 | |||
89 | scale_s_new = ((3')_new - (3)_new) / ((2') - (2)) | ||
90 | |||
91 | 8. Calculate new CEU crop - apply sensor scales to previously calculated | ||
92 | "effective" crop: | ||
93 | |||
94 | width_ceu = (4')_new - (4)_new = width_u / scale_s_new | ||
95 | left_ceu = (4)_new - (3)_new = ((5) - (2)) / scale_s_new | ||
96 | |||
97 | 9. Use CEU cropping to crop to the new window: | ||
98 | |||
99 | ceu_crop(.width = width_ceu, .left = left_ceu) | ||
100 | |||
101 | 10. Use CEU scaling to scale to the requested user window: | ||
102 | |||
103 | scale_ceu = width_ceu / width | ||
104 | |||
105 | |||
106 | S_CROP | ||
107 | ------ | ||
108 | |||
109 | If old scale applied to new crop is invalid produce nearest new scale possible | ||
110 | |||
111 | 1. Calculate current combined scales. | ||
112 | |||
113 | scale_comb = (((4') - (4)) / ((6') - (6))) * (((2') - (2)) / ((3') - (3))) | ||
114 | |||
115 | 2. Apply iterative sensor S_CROP for new input window. | ||
116 | |||
117 | 3. If old combined scales applied to new crop produce an impossible user window, | ||
118 | adjust scales to produce nearest possible window. | ||
119 | |||
120 | width_u_out = ((5') - (5)) / scale_comb | ||
121 | |||
122 | if (width_u_out > max) | ||
123 | scale_comb = ((5') - (5)) / max; | ||
124 | else if (width_u_out < min) | ||
125 | scale_comb = ((5') - (5)) / min; | ||
126 | |||
127 | 4. Issue G_CROP to retrieve actual input window. | ||
128 | |||
129 | 5. Using actual input window and calculated combined scales calculate sensor | ||
130 | target output window. | ||
131 | |||
132 | width_s_out = ((3') - (3)) = ((2') - (2)) / scale_comb | ||
133 | |||
134 | 6. Apply iterative S_FMT for new sensor target output window. | ||
135 | |||
136 | 7. Issue G_FMT to retrieve the actual sensor output window. | ||
137 | |||
138 | 8. Calculate sensor scales. | ||
139 | |||
140 | scale_s = ((3') - (3)) / ((2') - (2)) | ||
141 | |||
142 | 9. Calculate sensor output subwindow to be cropped on CEU by applying sensor | ||
143 | scales to the requested window. | ||
144 | |||
145 | width_ceu = ((5') - (5)) / scale_s | ||
146 | |||
147 | 10. Use CEU cropping for above calculated window. | ||
148 | |||
149 | 11. Calculate CEU scales from sensor scales from results of (10) and user window | ||
150 | from (3) | ||
151 | |||
152 | scale_ceu = calc_scale(((5') - (5)), &width_u_out) | ||
153 | |||
154 | 12. Apply CEU scales. | ||
155 | |||
156 | -- | ||
157 | Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de> | ||
diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index b806edaf3e75..74d677c8b036 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt | |||
@@ -561,6 +561,8 @@ video_device helper functions | |||
561 | 561 | ||
562 | There are a few useful helper functions: | 562 | There are a few useful helper functions: |
563 | 563 | ||
564 | - file/video_device private data | ||
565 | |||
564 | You can set/get driver private data in the video_device struct using: | 566 | You can set/get driver private data in the video_device struct using: |
565 | 567 | ||
566 | void *video_get_drvdata(struct video_device *vdev); | 568 | void *video_get_drvdata(struct video_device *vdev); |
@@ -575,8 +577,7 @@ struct video_device *video_devdata(struct file *file); | |||
575 | 577 | ||
576 | returns the video_device belonging to the file struct. | 578 | returns the video_device belonging to the file struct. |
577 | 579 | ||
578 | The final helper function combines video_get_drvdata with | 580 | The video_drvdata function combines video_get_drvdata with video_devdata: |
579 | video_devdata: | ||
580 | 581 | ||
581 | void *video_drvdata(struct file *file); | 582 | void *video_drvdata(struct file *file); |
582 | 583 | ||
@@ -584,6 +585,17 @@ You can go from a video_device struct to the v4l2_device struct using: | |||
584 | 585 | ||
585 | struct v4l2_device *v4l2_dev = vdev->v4l2_dev; | 586 | struct v4l2_device *v4l2_dev = vdev->v4l2_dev; |
586 | 587 | ||
588 | - Device node name | ||
589 | |||
590 | The video_device node kernel name can be retrieved using | ||
591 | |||
592 | const char *video_device_node_name(struct video_device *vdev); | ||
593 | |||
594 | The name is used as a hint by userspace tools such as udev. The function | ||
595 | should be used where possible instead of accessing the video_device::num and | ||
596 | video_device::minor fields. | ||
597 | |||
598 | |||
587 | video buffer helper functions | 599 | video buffer helper functions |
588 | ----------------------------- | 600 | ----------------------------- |
589 | 601 | ||
diff --git a/Documentation/vm/hugetlbpage.txt b/Documentation/vm/hugetlbpage.txt index 82a7bd1800b2..bc31636973e3 100644 --- a/Documentation/vm/hugetlbpage.txt +++ b/Documentation/vm/hugetlbpage.txt | |||
@@ -11,23 +11,21 @@ This optimization is more critical now as bigger and bigger physical memories | |||
11 | (several GBs) are more readily available. | 11 | (several GBs) are more readily available. |
12 | 12 | ||
13 | Users can use the huge page support in Linux kernel by either using the mmap | 13 | Users can use the huge page support in Linux kernel by either using the mmap |
14 | system call or standard SYSv shared memory system calls (shmget, shmat). | 14 | system call or standard SYSV shared memory system calls (shmget, shmat). |
15 | 15 | ||
16 | First the Linux kernel needs to be built with the CONFIG_HUGETLBFS | 16 | First the Linux kernel needs to be built with the CONFIG_HUGETLBFS |
17 | (present under "File systems") and CONFIG_HUGETLB_PAGE (selected | 17 | (present under "File systems") and CONFIG_HUGETLB_PAGE (selected |
18 | automatically when CONFIG_HUGETLBFS is selected) configuration | 18 | automatically when CONFIG_HUGETLBFS is selected) configuration |
19 | options. | 19 | options. |
20 | 20 | ||
21 | The kernel built with huge page support should show the number of configured | 21 | The /proc/meminfo file provides information about the total number of |
22 | huge pages in the system by running the "cat /proc/meminfo" command. | 22 | persistent hugetlb pages in the kernel's huge page pool. It also displays |
23 | information about the number of free, reserved and surplus huge pages and the | ||
24 | default huge page size. The huge page size is needed for generating the | ||
25 | proper alignment and size of the arguments to system calls that map huge page | ||
26 | regions. | ||
23 | 27 | ||
24 | /proc/meminfo also provides information about the total number of hugetlb | 28 | The output of "cat /proc/meminfo" will include lines like: |
25 | pages configured in the kernel. It also displays information about the | ||
26 | number of free hugetlb pages at any time. It also displays information about | ||
27 | the configured huge page size - this is needed for generating the proper | ||
28 | alignment and size of the arguments to the above system calls. | ||
29 | |||
30 | The output of "cat /proc/meminfo" will have lines like: | ||
31 | 29 | ||
32 | ..... | 30 | ..... |
33 | HugePages_Total: vvv | 31 | HugePages_Total: vvv |
@@ -53,59 +51,63 @@ HugePages_Surp is short for "surplus," and is the number of huge pages in | |||
53 | /proc/filesystems should also show a filesystem of type "hugetlbfs" configured | 51 | /proc/filesystems should also show a filesystem of type "hugetlbfs" configured |
54 | in the kernel. | 52 | in the kernel. |
55 | 53 | ||
56 | /proc/sys/vm/nr_hugepages indicates the current number of configured hugetlb | 54 | /proc/sys/vm/nr_hugepages indicates the current number of "persistent" huge |
57 | pages in the kernel. Super user can dynamically request more (or free some | 55 | pages in the kernel's huge page pool. "Persistent" huge pages will be |
58 | pre-configured) huge pages. | 56 | returned to the huge page pool when freed by a task. A user with root |
59 | The allocation (or deallocation) of hugetlb pages is possible only if there are | 57 | privileges can dynamically allocate more or free some persistent huge pages |
60 | enough physically contiguous free pages in system (freeing of huge pages is | 58 | by increasing or decreasing the value of 'nr_hugepages'. |
61 | possible only if there are enough hugetlb pages free that can be transferred | ||
62 | back to regular memory pool). | ||
63 | 59 | ||
64 | Pages that are used as hugetlb pages are reserved inside the kernel and cannot | 60 | Pages that are used as huge pages are reserved inside the kernel and cannot |
65 | be used for other purposes. | 61 | be used for other purposes. Huge pages cannot be swapped out under |
62 | memory pressure. | ||
66 | 63 | ||
67 | Once the kernel with Hugetlb page support is built and running, a user can | 64 | Once a number of huge pages have been pre-allocated to the kernel huge page |
68 | use either the mmap system call or shared memory system calls to start using | 65 | pool, a user with appropriate privilege can use either the mmap system call |
69 | the huge pages. It is required that the system administrator preallocate | 66 | or shared memory system calls to use the huge pages. See the discussion of |
70 | enough memory for huge page purposes. | 67 | Using Huge Pages, below. |
71 | 68 | ||
72 | The administrator can preallocate huge pages on the kernel boot command line by | 69 | The administrator can allocate persistent huge pages on the kernel boot |
73 | specifying the "hugepages=N" parameter, where 'N' = the number of huge pages | 70 | command line by specifying the "hugepages=N" parameter, where 'N' = the |
74 | requested. This is the most reliable method for preallocating huge pages as | 71 | number of huge pages requested. This is the most reliable method of |
75 | memory has not yet become fragmented. | 72 | allocating huge pages as memory has not yet become fragmented. |
76 | 73 | ||
77 | Some platforms support multiple huge page sizes. To preallocate huge pages | 74 | Some platforms support multiple huge page sizes. To allocate huge pages |
78 | of a specific size, one must preceed the huge pages boot command parameters | 75 | of a specific size, one must preceed the huge pages boot command parameters |
79 | with a huge page size selection parameter "hugepagesz=<size>". <size> must | 76 | with a huge page size selection parameter "hugepagesz=<size>". <size> must |
80 | be specified in bytes with optional scale suffix [kKmMgG]. The default huge | 77 | be specified in bytes with optional scale suffix [kKmMgG]. The default huge |
81 | page size may be selected with the "default_hugepagesz=<size>" boot parameter. | 78 | page size may be selected with the "default_hugepagesz=<size>" boot parameter. |
82 | 79 | ||
83 | /proc/sys/vm/nr_hugepages indicates the current number of configured [default | 80 | When multiple huge page sizes are supported, /proc/sys/vm/nr_hugepages |
84 | size] hugetlb pages in the kernel. Super user can dynamically request more | 81 | indicates the current number of pre-allocated huge pages of the default size. |
85 | (or free some pre-configured) huge pages. | 82 | Thus, one can use the following command to dynamically allocate/deallocate |
86 | 83 | default sized persistent huge pages: | |
87 | Use the following command to dynamically allocate/deallocate default sized | ||
88 | huge pages: | ||
89 | 84 | ||
90 | echo 20 > /proc/sys/vm/nr_hugepages | 85 | echo 20 > /proc/sys/vm/nr_hugepages |
91 | 86 | ||
92 | This command will try to configure 20 default sized huge pages in the system. | 87 | This command will try to adjust the number of default sized huge pages in the |
88 | huge page pool to 20, allocating or freeing huge pages, as required. | ||
89 | |||
93 | On a NUMA platform, the kernel will attempt to distribute the huge page pool | 90 | On a NUMA platform, the kernel will attempt to distribute the huge page pool |
94 | over the all on-line nodes. These huge pages, allocated when nr_hugepages | 91 | over all the set of allowed nodes specified by the NUMA memory policy of the |
95 | is increased, are called "persistent huge pages". | 92 | task that modifies nr_hugepages. The default for the allowed nodes--when the |
93 | task has default memory policy--is all on-line nodes with memory. Allowed | ||
94 | nodes with insufficient available, contiguous memory for a huge page will be | ||
95 | silently skipped when allocating persistent huge pages. See the discussion | ||
96 | below of the interaction of task memory policy, cpusets and per node attributes | ||
97 | with the allocation and freeing of persistent huge pages. | ||
96 | 98 | ||
97 | The success or failure of huge page allocation depends on the amount of | 99 | The success or failure of huge page allocation depends on the amount of |
98 | physically contiguous memory that is preset in system at the time of the | 100 | physically contiguous memory that is present in system at the time of the |
99 | allocation attempt. If the kernel is unable to allocate huge pages from | 101 | allocation attempt. If the kernel is unable to allocate huge pages from |
100 | some nodes in a NUMA system, it will attempt to make up the difference by | 102 | some nodes in a NUMA system, it will attempt to make up the difference by |
101 | allocating extra pages on other nodes with sufficient available contiguous | 103 | allocating extra pages on other nodes with sufficient available contiguous |
102 | memory, if any. | 104 | memory, if any. |
103 | 105 | ||
104 | System administrators may want to put this command in one of the local rc init | 106 | System administrators may want to put this command in one of the local rc |
105 | files. This will enable the kernel to request huge pages early in the boot | 107 | init files. This will enable the kernel to allocate huge pages early in |
106 | process when the possibility of getting physical contiguous pages is still | 108 | the boot process when the possibility of getting physical contiguous pages |
107 | very high. Administrators can verify the number of huge pages actually | 109 | is still very high. Administrators can verify the number of huge pages |
108 | allocated by checking the sysctl or meminfo. To check the per node | 110 | actually allocated by checking the sysctl or meminfo. To check the per node |
109 | distribution of huge pages in a NUMA system, use: | 111 | distribution of huge pages in a NUMA system, use: |
110 | 112 | ||
111 | cat /sys/devices/system/node/node*/meminfo | fgrep Huge | 113 | cat /sys/devices/system/node/node*/meminfo | fgrep Huge |
@@ -113,45 +115,47 @@ distribution of huge pages in a NUMA system, use: | |||
113 | /proc/sys/vm/nr_overcommit_hugepages specifies how large the pool of | 115 | /proc/sys/vm/nr_overcommit_hugepages specifies how large the pool of |
114 | huge pages can grow, if more huge pages than /proc/sys/vm/nr_hugepages are | 116 | huge pages can grow, if more huge pages than /proc/sys/vm/nr_hugepages are |
115 | requested by applications. Writing any non-zero value into this file | 117 | requested by applications. Writing any non-zero value into this file |
116 | indicates that the hugetlb subsystem is allowed to try to obtain "surplus" | 118 | indicates that the hugetlb subsystem is allowed to try to obtain that |
117 | huge pages from the buddy allocator, when the normal pool is exhausted. As | 119 | number of "surplus" huge pages from the kernel's normal page pool, when the |
118 | these surplus huge pages go out of use, they are freed back to the buddy | 120 | persistent huge page pool is exhausted. As these surplus huge pages become |
119 | allocator. | 121 | unused, they are freed back to the kernel's normal page pool. |
120 | 122 | ||
121 | When increasing the huge page pool size via nr_hugepages, any surplus | 123 | When increasing the huge page pool size via nr_hugepages, any existing surplus |
122 | pages will first be promoted to persistent huge pages. Then, additional | 124 | pages will first be promoted to persistent huge pages. Then, additional |
123 | huge pages will be allocated, if necessary and if possible, to fulfill | 125 | huge pages will be allocated, if necessary and if possible, to fulfill |
124 | the new huge page pool size. | 126 | the new persistent huge page pool size. |
125 | 127 | ||
126 | The administrator may shrink the pool of preallocated huge pages for | 128 | The administrator may shrink the pool of persistent huge pages for |
127 | the default huge page size by setting the nr_hugepages sysctl to a | 129 | the default huge page size by setting the nr_hugepages sysctl to a |
128 | smaller value. The kernel will attempt to balance the freeing of huge pages | 130 | smaller value. The kernel will attempt to balance the freeing of huge pages |
129 | across all on-line nodes. Any free huge pages on the selected nodes will | 131 | across all nodes in the memory policy of the task modifying nr_hugepages. |
130 | be freed back to the buddy allocator. | 132 | Any free huge pages on the selected nodes will be freed back to the kernel's |
131 | 133 | normal page pool. | |
132 | Caveat: Shrinking the pool via nr_hugepages such that it becomes less | 134 | |
133 | than the number of huge pages in use will convert the balance to surplus | 135 | Caveat: Shrinking the persistent huge page pool via nr_hugepages such that |
134 | huge pages even if it would exceed the overcommit value. As long as | 136 | it becomes less than the number of huge pages in use will convert the balance |
135 | this condition holds, however, no more surplus huge pages will be | 137 | of the in-use huge pages to surplus huge pages. This will occur even if |
136 | allowed on the system until one of the two sysctls are increased | 138 | the number of surplus pages it would exceed the overcommit value. As long as |
137 | sufficiently, or the surplus huge pages go out of use and are freed. | 139 | this condition holds--that is, until nr_hugepages+nr_overcommit_hugepages is |
140 | increased sufficiently, or the surplus huge pages go out of use and are freed-- | ||
141 | no more surplus huge pages will be allowed to be allocated. | ||
138 | 142 | ||
139 | With support for multiple huge page pools at run-time available, much of | 143 | With support for multiple huge page pools at run-time available, much of |
140 | the huge page userspace interface has been duplicated in sysfs. The above | 144 | the huge page userspace interface in /proc/sys/vm has been duplicated in sysfs. |
141 | information applies to the default huge page size which will be | 145 | The /proc interfaces discussed above have been retained for backwards |
142 | controlled by the /proc interfaces for backwards compatibility. The root | 146 | compatibility. The root huge page control directory in sysfs is: |
143 | huge page control directory in sysfs is: | ||
144 | 147 | ||
145 | /sys/kernel/mm/hugepages | 148 | /sys/kernel/mm/hugepages |
146 | 149 | ||
147 | For each huge page size supported by the running kernel, a subdirectory | 150 | For each huge page size supported by the running kernel, a subdirectory |
148 | will exist, of the form | 151 | will exist, of the form: |
149 | 152 | ||
150 | hugepages-${size}kB | 153 | hugepages-${size}kB |
151 | 154 | ||
152 | Inside each of these directories, the same set of files will exist: | 155 | Inside each of these directories, the same set of files will exist: |
153 | 156 | ||
154 | nr_hugepages | 157 | nr_hugepages |
158 | nr_hugepages_mempolicy | ||
155 | nr_overcommit_hugepages | 159 | nr_overcommit_hugepages |
156 | free_hugepages | 160 | free_hugepages |
157 | resv_hugepages | 161 | resv_hugepages |
@@ -159,6 +163,102 @@ Inside each of these directories, the same set of files will exist: | |||
159 | 163 | ||
160 | which function as described above for the default huge page-sized case. | 164 | which function as described above for the default huge page-sized case. |
161 | 165 | ||
166 | |||
167 | Interaction of Task Memory Policy with Huge Page Allocation/Freeing | ||
168 | |||
169 | Whether huge pages are allocated and freed via the /proc interface or | ||
170 | the /sysfs interface using the nr_hugepages_mempolicy attribute, the NUMA | ||
171 | nodes from which huge pages are allocated or freed are controlled by the | ||
172 | NUMA memory policy of the task that modifies the nr_hugepages_mempolicy | ||
173 | sysctl or attribute. When the nr_hugepages attribute is used, mempolicy | ||
174 | is ignored. | ||
175 | |||
176 | The recommended method to allocate or free huge pages to/from the kernel | ||
177 | huge page pool, using the nr_hugepages example above, is: | ||
178 | |||
179 | numactl --interleave <node-list> echo 20 \ | ||
180 | >/proc/sys/vm/nr_hugepages_mempolicy | ||
181 | |||
182 | or, more succinctly: | ||
183 | |||
184 | numactl -m <node-list> echo 20 >/proc/sys/vm/nr_hugepages_mempolicy | ||
185 | |||
186 | This will allocate or free abs(20 - nr_hugepages) to or from the nodes | ||
187 | specified in <node-list>, depending on whether number of persistent huge pages | ||
188 | is initially less than or greater than 20, respectively. No huge pages will be | ||
189 | allocated nor freed on any node not included in the specified <node-list>. | ||
190 | |||
191 | When adjusting the persistent hugepage count via nr_hugepages_mempolicy, any | ||
192 | memory policy mode--bind, preferred, local or interleave--may be used. The | ||
193 | resulting effect on persistent huge page allocation is as follows: | ||
194 | |||
195 | 1) Regardless of mempolicy mode [see Documentation/vm/numa_memory_policy.txt], | ||
196 | persistent huge pages will be distributed across the node or nodes | ||
197 | specified in the mempolicy as if "interleave" had been specified. | ||
198 | However, if a node in the policy does not contain sufficient contiguous | ||
199 | memory for a huge page, the allocation will not "fallback" to the nearest | ||
200 | neighbor node with sufficient contiguous memory. To do this would cause | ||
201 | undesirable imbalance in the distribution of the huge page pool, or | ||
202 | possibly, allocation of persistent huge pages on nodes not allowed by | ||
203 | the task's memory policy. | ||
204 | |||
205 | 2) One or more nodes may be specified with the bind or interleave policy. | ||
206 | If more than one node is specified with the preferred policy, only the | ||
207 | lowest numeric id will be used. Local policy will select the node where | ||
208 | the task is running at the time the nodes_allowed mask is constructed. | ||
209 | For local policy to be deterministic, the task must be bound to a cpu or | ||
210 | cpus in a single node. Otherwise, the task could be migrated to some | ||
211 | other node at any time after launch and the resulting node will be | ||
212 | indeterminate. Thus, local policy is not very useful for this purpose. | ||
213 | Any of the other mempolicy modes may be used to specify a single node. | ||
214 | |||
215 | 3) The nodes allowed mask will be derived from any non-default task mempolicy, | ||
216 | whether this policy was set explicitly by the task itself or one of its | ||
217 | ancestors, such as numactl. This means that if the task is invoked from a | ||
218 | shell with non-default policy, that policy will be used. One can specify a | ||
219 | node list of "all" with numactl --interleave or --membind [-m] to achieve | ||
220 | interleaving over all nodes in the system or cpuset. | ||
221 | |||
222 | 4) Any task mempolicy specifed--e.g., using numactl--will be constrained by | ||
223 | the resource limits of any cpuset in which the task runs. Thus, there will | ||
224 | be no way for a task with non-default policy running in a cpuset with a | ||
225 | subset of the system nodes to allocate huge pages outside the cpuset | ||
226 | without first moving to a cpuset that contains all of the desired nodes. | ||
227 | |||
228 | 5) Boot-time huge page allocation attempts to distribute the requested number | ||
229 | of huge pages over all on-lines nodes with memory. | ||
230 | |||
231 | Per Node Hugepages Attributes | ||
232 | |||
233 | A subset of the contents of the root huge page control directory in sysfs, | ||
234 | described above, will be replicated under each the system device of each | ||
235 | NUMA node with memory in: | ||
236 | |||
237 | /sys/devices/system/node/node[0-9]*/hugepages/ | ||
238 | |||
239 | Under this directory, the subdirectory for each supported huge page size | ||
240 | contains the following attribute files: | ||
241 | |||
242 | nr_hugepages | ||
243 | free_hugepages | ||
244 | surplus_hugepages | ||
245 | |||
246 | The free_' and surplus_' attribute files are read-only. They return the number | ||
247 | of free and surplus [overcommitted] huge pages, respectively, on the parent | ||
248 | node. | ||
249 | |||
250 | The nr_hugepages attribute returns the total number of huge pages on the | ||
251 | specified node. When this attribute is written, the number of persistent huge | ||
252 | pages on the parent node will be adjusted to the specified value, if sufficient | ||
253 | resources exist, regardless of the task's mempolicy or cpuset constraints. | ||
254 | |||
255 | Note that the number of overcommit and reserve pages remain global quantities, | ||
256 | as we don't know until fault time, when the faulting task's mempolicy is | ||
257 | applied, from which node the huge page allocation will be attempted. | ||
258 | |||
259 | |||
260 | Using Huge Pages | ||
261 | |||
162 | If the user applications are going to request huge pages using mmap system | 262 | If the user applications are going to request huge pages using mmap system |
163 | call, then it is required that system administrator mount a file system of | 263 | call, then it is required that system administrator mount a file system of |
164 | type hugetlbfs: | 264 | type hugetlbfs: |
@@ -206,9 +306,11 @@ map_hugetlb.c. | |||
206 | * requesting huge pages. | 306 | * requesting huge pages. |
207 | * | 307 | * |
208 | * For the ia64 architecture, the Linux kernel reserves Region number 4 for | 308 | * For the ia64 architecture, the Linux kernel reserves Region number 4 for |
209 | * huge pages. That means the addresses starting with 0x800000... will need | 309 | * huge pages. That means that if one requires a fixed address, a huge page |
210 | * to be specified. Specifying a fixed address is not required on ppc64, | 310 | * aligned address starting with 0x800000... will be required. If a fixed |
211 | * i386 or x86_64. | 311 | * address is not required, the kernel will select an address in the proper |
312 | * range. | ||
313 | * Other architectures, such as ppc64, i386 or x86_64 are not so constrained. | ||
212 | * | 314 | * |
213 | * Note: The default shared memory limit is quite low on many kernels, | 315 | * Note: The default shared memory limit is quite low on many kernels, |
214 | * you may need to increase it via: | 316 | * you may need to increase it via: |
@@ -237,14 +339,8 @@ map_hugetlb.c. | |||
237 | 339 | ||
238 | #define dprintf(x) printf(x) | 340 | #define dprintf(x) printf(x) |
239 | 341 | ||
240 | /* Only ia64 requires this */ | 342 | #define ADDR (void *)(0x0UL) /* let kernel choose address */ |
241 | #ifdef __ia64__ | ||
242 | #define ADDR (void *)(0x8000000000000000UL) | ||
243 | #define SHMAT_FLAGS (SHM_RND) | ||
244 | #else | ||
245 | #define ADDR (void *)(0x0UL) | ||
246 | #define SHMAT_FLAGS (0) | 343 | #define SHMAT_FLAGS (0) |
247 | #endif | ||
248 | 344 | ||
249 | int main(void) | 345 | int main(void) |
250 | { | 346 | { |
@@ -302,10 +398,12 @@ int main(void) | |||
302 | * example, the app is requesting memory of size 256MB that is backed by | 398 | * example, the app is requesting memory of size 256MB that is backed by |
303 | * huge pages. | 399 | * huge pages. |
304 | * | 400 | * |
305 | * For ia64 architecture, Linux kernel reserves Region number 4 for huge pages. | 401 | * For the ia64 architecture, the Linux kernel reserves Region number 4 for |
306 | * That means the addresses starting with 0x800000... will need to be | 402 | * huge pages. That means that if one requires a fixed address, a huge page |
307 | * specified. Specifying a fixed address is not required on ppc64, i386 | 403 | * aligned address starting with 0x800000... will be required. If a fixed |
308 | * or x86_64. | 404 | * address is not required, the kernel will select an address in the proper |
405 | * range. | ||
406 | * Other architectures, such as ppc64, i386 or x86_64 are not so constrained. | ||
309 | */ | 407 | */ |
310 | #include <stdlib.h> | 408 | #include <stdlib.h> |
311 | #include <stdio.h> | 409 | #include <stdio.h> |
@@ -317,14 +415,8 @@ int main(void) | |||
317 | #define LENGTH (256UL*1024*1024) | 415 | #define LENGTH (256UL*1024*1024) |
318 | #define PROTECTION (PROT_READ | PROT_WRITE) | 416 | #define PROTECTION (PROT_READ | PROT_WRITE) |
319 | 417 | ||
320 | /* Only ia64 requires this */ | 418 | #define ADDR (void *)(0x0UL) /* let kernel choose address */ |
321 | #ifdef __ia64__ | ||
322 | #define ADDR (void *)(0x8000000000000000UL) | ||
323 | #define FLAGS (MAP_SHARED | MAP_FIXED) | ||
324 | #else | ||
325 | #define ADDR (void *)(0x0UL) | ||
326 | #define FLAGS (MAP_SHARED) | 419 | #define FLAGS (MAP_SHARED) |
327 | #endif | ||
328 | 420 | ||
329 | void check_bytes(char *addr) | 421 | void check_bytes(char *addr) |
330 | { | 422 | { |
diff --git a/Documentation/vm/ksm.txt b/Documentation/vm/ksm.txt index 262d8e6793a3..b392e496f816 100644 --- a/Documentation/vm/ksm.txt +++ b/Documentation/vm/ksm.txt | |||
@@ -16,9 +16,9 @@ by sharing the data common between them. But it can be useful to any | |||
16 | application which generates many instances of the same data. | 16 | application which generates many instances of the same data. |
17 | 17 | ||
18 | KSM only merges anonymous (private) pages, never pagecache (file) pages. | 18 | KSM only merges anonymous (private) pages, never pagecache (file) pages. |
19 | KSM's merged pages are at present locked into kernel memory for as long | 19 | KSM's merged pages were originally locked into kernel memory, but can now |
20 | as they are shared: so cannot be swapped out like the user pages they | 20 | be swapped out just like other user pages (but sharing is broken when they |
21 | replace (but swapping KSM pages should follow soon in a later release). | 21 | are swapped back in: ksmd must rediscover their identity and merge again). |
22 | 22 | ||
23 | KSM only operates on those areas of address space which an application | 23 | KSM only operates on those areas of address space which an application |
24 | has advised to be likely candidates for merging, by using the madvise(2) | 24 | has advised to be likely candidates for merging, by using the madvise(2) |
@@ -44,20 +44,12 @@ includes unmapped gaps (though working on the intervening mapped areas), | |||
44 | and might fail with EAGAIN if not enough memory for internal structures. | 44 | and might fail with EAGAIN if not enough memory for internal structures. |
45 | 45 | ||
46 | Applications should be considerate in their use of MADV_MERGEABLE, | 46 | Applications should be considerate in their use of MADV_MERGEABLE, |
47 | restricting its use to areas likely to benefit. KSM's scans may use | 47 | restricting its use to areas likely to benefit. KSM's scans may use a lot |
48 | a lot of processing power, and its kernel-resident pages are a limited | 48 | of processing power: some installations will disable KSM for that reason. |
49 | resource. Some installations will disable KSM for these reasons. | ||
50 | 49 | ||
51 | The KSM daemon is controlled by sysfs files in /sys/kernel/mm/ksm/, | 50 | The KSM daemon is controlled by sysfs files in /sys/kernel/mm/ksm/, |
52 | readable by all but writable only by root: | 51 | readable by all but writable only by root: |
53 | 52 | ||
54 | max_kernel_pages - set to maximum number of kernel pages that KSM may use | ||
55 | e.g. "echo 100000 > /sys/kernel/mm/ksm/max_kernel_pages" | ||
56 | Value 0 imposes no limit on the kernel pages KSM may use; | ||
57 | but note that any process using MADV_MERGEABLE can cause | ||
58 | KSM to allocate these pages, unswappable until it exits. | ||
59 | Default: quarter of memory (chosen to not pin too much) | ||
60 | |||
61 | pages_to_scan - how many present pages to scan before ksmd goes to sleep | 53 | pages_to_scan - how many present pages to scan before ksmd goes to sleep |
62 | e.g. "echo 100 > /sys/kernel/mm/ksm/pages_to_scan" | 54 | e.g. "echo 100 > /sys/kernel/mm/ksm/pages_to_scan" |
63 | Default: 100 (chosen for demonstration purposes) | 55 | Default: 100 (chosen for demonstration purposes) |
@@ -75,7 +67,7 @@ run - set 0 to stop ksmd from running but keep merged pages, | |||
75 | 67 | ||
76 | The effectiveness of KSM and MADV_MERGEABLE is shown in /sys/kernel/mm/ksm/: | 68 | The effectiveness of KSM and MADV_MERGEABLE is shown in /sys/kernel/mm/ksm/: |
77 | 69 | ||
78 | pages_shared - how many shared unswappable kernel pages KSM is using | 70 | pages_shared - how many shared pages are being used |
79 | pages_sharing - how many more sites are sharing them i.e. how much saved | 71 | pages_sharing - how many more sites are sharing them i.e. how much saved |
80 | pages_unshared - how many pages unique but repeatedly checked for merging | 72 | pages_unshared - how many pages unique but repeatedly checked for merging |
81 | pages_volatile - how many pages changing too fast to be placed in a tree | 73 | pages_volatile - how many pages changing too fast to be placed in a tree |
@@ -87,4 +79,4 @@ pages_volatile embraces several different kinds of activity, but a high | |||
87 | proportion there would also indicate poor use of madvise MADV_MERGEABLE. | 79 | proportion there would also indicate poor use of madvise MADV_MERGEABLE. |
88 | 80 | ||
89 | Izik Eidus, | 81 | Izik Eidus, |
90 | Hugh Dickins, 24 Sept 2009 | 82 | Hugh Dickins, 17 Nov 2009 |
diff --git a/Documentation/vm/page-types.c b/Documentation/vm/page-types.c index ea44ea502da1..7a7d9bab32ef 100644 --- a/Documentation/vm/page-types.c +++ b/Documentation/vm/page-types.c | |||
@@ -100,7 +100,7 @@ | |||
100 | #define BIT(name) (1ULL << KPF_##name) | 100 | #define BIT(name) (1ULL << KPF_##name) |
101 | #define BITS_COMPOUND (BIT(COMPOUND_HEAD) | BIT(COMPOUND_TAIL)) | 101 | #define BITS_COMPOUND (BIT(COMPOUND_HEAD) | BIT(COMPOUND_TAIL)) |
102 | 102 | ||
103 | static char *page_flag_names[] = { | 103 | static const char *page_flag_names[] = { |
104 | [KPF_LOCKED] = "L:locked", | 104 | [KPF_LOCKED] = "L:locked", |
105 | [KPF_ERROR] = "E:error", | 105 | [KPF_ERROR] = "E:error", |
106 | [KPF_REFERENCED] = "R:referenced", | 106 | [KPF_REFERENCED] = "R:referenced", |
@@ -173,7 +173,7 @@ static int kpageflags_fd; | |||
173 | static int opt_hwpoison; | 173 | static int opt_hwpoison; |
174 | static int opt_unpoison; | 174 | static int opt_unpoison; |
175 | 175 | ||
176 | static char *hwpoison_debug_fs = "/debug/hwpoison"; | 176 | static const char hwpoison_debug_fs[] = "/debug/hwpoison"; |
177 | static int hwpoison_inject_fd; | 177 | static int hwpoison_inject_fd; |
178 | static int hwpoison_forget_fd; | 178 | static int hwpoison_forget_fd; |
179 | 179 | ||
@@ -560,7 +560,7 @@ static void walk_pfn(unsigned long voffset, | |||
560 | { | 560 | { |
561 | uint64_t buf[KPAGEFLAGS_BATCH]; | 561 | uint64_t buf[KPAGEFLAGS_BATCH]; |
562 | unsigned long batch; | 562 | unsigned long batch; |
563 | unsigned long pages; | 563 | long pages; |
564 | unsigned long i; | 564 | unsigned long i; |
565 | 565 | ||
566 | while (count) { | 566 | while (count) { |
@@ -673,30 +673,35 @@ static void usage(void) | |||
673 | 673 | ||
674 | printf( | 674 | printf( |
675 | "page-types [options]\n" | 675 | "page-types [options]\n" |
676 | " -r|--raw Raw mode, for kernel developers\n" | 676 | " -r|--raw Raw mode, for kernel developers\n" |
677 | " -a|--addr addr-spec Walk a range of pages\n" | 677 | " -d|--describe flags Describe flags\n" |
678 | " -b|--bits bits-spec Walk pages with specified bits\n" | 678 | " -a|--addr addr-spec Walk a range of pages\n" |
679 | " -p|--pid pid Walk process address space\n" | 679 | " -b|--bits bits-spec Walk pages with specified bits\n" |
680 | " -p|--pid pid Walk process address space\n" | ||
680 | #if 0 /* planned features */ | 681 | #if 0 /* planned features */ |
681 | " -f|--file filename Walk file address space\n" | 682 | " -f|--file filename Walk file address space\n" |
682 | #endif | 683 | #endif |
683 | " -l|--list Show page details in ranges\n" | 684 | " -l|--list Show page details in ranges\n" |
684 | " -L|--list-each Show page details one by one\n" | 685 | " -L|--list-each Show page details one by one\n" |
685 | " -N|--no-summary Don't show summay info\n" | 686 | " -N|--no-summary Don't show summay info\n" |
686 | " -X|--hwpoison hwpoison pages\n" | 687 | " -X|--hwpoison hwpoison pages\n" |
687 | " -x|--unpoison unpoison pages\n" | 688 | " -x|--unpoison unpoison pages\n" |
688 | " -h|--help Show this usage message\n" | 689 | " -h|--help Show this usage message\n" |
690 | "flags:\n" | ||
691 | " 0x10 bitfield format, e.g.\n" | ||
692 | " anon bit-name, e.g.\n" | ||
693 | " 0x10,anon comma-separated list, e.g.\n" | ||
689 | "addr-spec:\n" | 694 | "addr-spec:\n" |
690 | " N one page at offset N (unit: pages)\n" | 695 | " N one page at offset N (unit: pages)\n" |
691 | " N+M pages range from N to N+M-1\n" | 696 | " N+M pages range from N to N+M-1\n" |
692 | " N,M pages range from N to M-1\n" | 697 | " N,M pages range from N to M-1\n" |
693 | " N, pages range from N to end\n" | 698 | " N, pages range from N to end\n" |
694 | " ,M pages range from 0 to M-1\n" | 699 | " ,M pages range from 0 to M-1\n" |
695 | "bits-spec:\n" | 700 | "bits-spec:\n" |
696 | " bit1,bit2 (flags & (bit1|bit2)) != 0\n" | 701 | " bit1,bit2 (flags & (bit1|bit2)) != 0\n" |
697 | " bit1,bit2=bit1 (flags & (bit1|bit2)) == bit1\n" | 702 | " bit1,bit2=bit1 (flags & (bit1|bit2)) == bit1\n" |
698 | " bit1,~bit2 (flags & (bit1|bit2)) == bit1\n" | 703 | " bit1,~bit2 (flags & (bit1|bit2)) == bit1\n" |
699 | " =bit1,bit2 flags == (bit1|bit2)\n" | 704 | " =bit1,bit2 flags == (bit1|bit2)\n" |
700 | "bit-names:\n" | 705 | "bit-names:\n" |
701 | ); | 706 | ); |
702 | 707 | ||
@@ -884,13 +889,23 @@ static void parse_bits_mask(const char *optarg) | |||
884 | add_bits_filter(mask, bits); | 889 | add_bits_filter(mask, bits); |
885 | } | 890 | } |
886 | 891 | ||
892 | static void describe_flags(const char *optarg) | ||
893 | { | ||
894 | uint64_t flags = parse_flag_names(optarg, 0); | ||
887 | 895 | ||
888 | static struct option opts[] = { | 896 | printf("0x%016llx\t%s\t%s\n", |
897 | (unsigned long long)flags, | ||
898 | page_flag_name(flags), | ||
899 | page_flag_longname(flags)); | ||
900 | } | ||
901 | |||
902 | static const struct option opts[] = { | ||
889 | { "raw" , 0, NULL, 'r' }, | 903 | { "raw" , 0, NULL, 'r' }, |
890 | { "pid" , 1, NULL, 'p' }, | 904 | { "pid" , 1, NULL, 'p' }, |
891 | { "file" , 1, NULL, 'f' }, | 905 | { "file" , 1, NULL, 'f' }, |
892 | { "addr" , 1, NULL, 'a' }, | 906 | { "addr" , 1, NULL, 'a' }, |
893 | { "bits" , 1, NULL, 'b' }, | 907 | { "bits" , 1, NULL, 'b' }, |
908 | { "describe" , 1, NULL, 'd' }, | ||
894 | { "list" , 0, NULL, 'l' }, | 909 | { "list" , 0, NULL, 'l' }, |
895 | { "list-each" , 0, NULL, 'L' }, | 910 | { "list-each" , 0, NULL, 'L' }, |
896 | { "no-summary", 0, NULL, 'N' }, | 911 | { "no-summary", 0, NULL, 'N' }, |
@@ -907,7 +922,7 @@ int main(int argc, char *argv[]) | |||
907 | page_size = getpagesize(); | 922 | page_size = getpagesize(); |
908 | 923 | ||
909 | while ((c = getopt_long(argc, argv, | 924 | while ((c = getopt_long(argc, argv, |
910 | "rp:f:a:b:lLNXxh", opts, NULL)) != -1) { | 925 | "rp:f:a:b:d:lLNXxh", opts, NULL)) != -1) { |
911 | switch (c) { | 926 | switch (c) { |
912 | case 'r': | 927 | case 'r': |
913 | opt_raw = 1; | 928 | opt_raw = 1; |
@@ -924,6 +939,9 @@ int main(int argc, char *argv[]) | |||
924 | case 'b': | 939 | case 'b': |
925 | parse_bits_mask(optarg); | 940 | parse_bits_mask(optarg); |
926 | break; | 941 | break; |
942 | case 'd': | ||
943 | describe_flags(optarg); | ||
944 | exit(0); | ||
927 | case 'l': | 945 | case 'l': |
928 | opt_list = 1; | 946 | opt_list = 1; |
929 | break; | 947 | break; |