diff options
Diffstat (limited to 'Documentation')
72 files changed, 2691 insertions, 1328 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/ABI/testing/sysfs-memory-page-offline b/Documentation/ABI/testing/sysfs-memory-page-offline new file mode 100644 index 000000000000..e14703f12fdf --- /dev/null +++ b/Documentation/ABI/testing/sysfs-memory-page-offline | |||
@@ -0,0 +1,44 @@ | |||
1 | What: /sys/devices/system/memory/soft_offline_page | ||
2 | Date: Sep 2009 | ||
3 | KernelVersion: 2.6.33 | ||
4 | Contact: andi@firstfloor.org | ||
5 | Description: | ||
6 | Soft-offline the memory page containing the physical address | ||
7 | written into this file. Input is a hex number specifying the | ||
8 | physical address of the page. The kernel will then attempt | ||
9 | to soft-offline it, by moving the contents elsewhere or | ||
10 | dropping it if possible. The kernel will then be placed | ||
11 | on the bad page list and never be reused. | ||
12 | |||
13 | The offlining is done in kernel specific granuality. | ||
14 | Normally it's the base page size of the kernel, but | ||
15 | this might change. | ||
16 | |||
17 | The page must be still accessible, not poisoned. The | ||
18 | kernel will never kill anything for this, but rather | ||
19 | fail the offline. Return value is the size of the | ||
20 | number, or a error when the offlining failed. Reading | ||
21 | the file is not allowed. | ||
22 | |||
23 | What: /sys/devices/system/memory/hard_offline_page | ||
24 | Date: Sep 2009 | ||
25 | KernelVersion: 2.6.33 | ||
26 | Contact: andi@firstfloor.org | ||
27 | Description: | ||
28 | Hard-offline the memory page containing the physical | ||
29 | address written into this file. Input is a hex number | ||
30 | specifying the physical address of the page. The | ||
31 | kernel will then attempt to hard-offline the page, by | ||
32 | trying to drop the page or killing any owner or | ||
33 | triggering IO errors if needed. Note this may kill | ||
34 | any processes owning the page. The kernel will avoid | ||
35 | to access this page assuming it's poisoned by the | ||
36 | hardware. | ||
37 | |||
38 | The offlining is done in kernel specific granuality. | ||
39 | Normally it's the base page size of the kernel, but | ||
40 | this might change. | ||
41 | |||
42 | Return value is the size of the number, or a error when | ||
43 | the offlining failed. | ||
44 | Reading the file is not allowed. | ||
diff --git a/Documentation/Changes b/Documentation/Changes index 6d0f1efc5bf6..f08b313cd235 100644 --- a/Documentation/Changes +++ b/Documentation/Changes | |||
@@ -49,6 +49,8 @@ o oprofile 0.9 # oprofiled --version | |||
49 | o udev 081 # udevinfo -V | 49 | o udev 081 # udevinfo -V |
50 | o grub 0.93 # grub --version | 50 | o grub 0.93 # grub --version |
51 | o mcelog 0.6 | 51 | o mcelog 0.6 |
52 | o iptables 1.4.1 # iptables -V | ||
53 | |||
52 | 54 | ||
53 | Kernel compilation | 55 | Kernel compilation |
54 | ================== | 56 | ================== |
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/acpi/method-customizing.txt b/Documentation/acpi/method-customizing.txt new file mode 100644 index 000000000000..e628cd23ca80 --- /dev/null +++ b/Documentation/acpi/method-customizing.txt | |||
@@ -0,0 +1,66 @@ | |||
1 | Linux ACPI Custom Control Method How To | ||
2 | ======================================= | ||
3 | |||
4 | Written by Zhang Rui <rui.zhang@intel.com> | ||
5 | |||
6 | |||
7 | Linux supports customizing ACPI control methods at runtime. | ||
8 | |||
9 | Users can use this to | ||
10 | 1. override an existing method which may not work correctly, | ||
11 | or just for debugging purposes. | ||
12 | 2. insert a completely new method in order to create a missing | ||
13 | method such as _OFF, _ON, _STA, _INI, etc. | ||
14 | For these cases, it is far simpler to dynamically install a single | ||
15 | control method rather than override the entire DSDT, because kernel | ||
16 | rebuild/reboot is not needed and test result can be got in minutes. | ||
17 | |||
18 | Note: Only ACPI METHOD can be overridden, any other object types like | ||
19 | "Device", "OperationRegion", are not recognized. | ||
20 | Note: The same ACPI control method can be overridden for many times, | ||
21 | and it's always the latest one that used by Linux/kernel. | ||
22 | |||
23 | 1. override an existing method | ||
24 | a) get the ACPI table via ACPI sysfs I/F. e.g. to get the DSDT, | ||
25 | just run "cat /sys/firmware/acpi/tables/DSDT > /tmp/dsdt.dat" | ||
26 | b) disassemble the table by running "iasl -d dsdt.dat". | ||
27 | c) rewrite the ASL code of the method and save it in a new file, | ||
28 | d) package the new file (psr.asl) to an ACPI table format. | ||
29 | Here is an example of a customized \_SB._AC._PSR method, | ||
30 | |||
31 | DefinitionBlock ("", "SSDT", 1, "", "", 0x20080715) | ||
32 | { | ||
33 | External (ACON) | ||
34 | |||
35 | Method (\_SB_.AC._PSR, 0, NotSerialized) | ||
36 | { | ||
37 | Store ("In AC _PSR", Debug) | ||
38 | Return (ACON) | ||
39 | } | ||
40 | } | ||
41 | Note that the full pathname of the method in ACPI namespace | ||
42 | should be used. | ||
43 | And remember to use "External" to declare external objects. | ||
44 | e) assemble the file to generate the AML code of the method. | ||
45 | e.g. "iasl psr.asl" (psr.aml is generated as a result) | ||
46 | f) mount debugfs by "mount -t debugfs none /sys/kernel/debug" | ||
47 | g) override the old method via the debugfs by running | ||
48 | "cat /tmp/psr.aml > /sys/kernel/debug/acpi/custom_method" | ||
49 | |||
50 | 2. insert a new method | ||
51 | This is easier than overriding an existing method. | ||
52 | We just need to create the ASL code of the method we want to | ||
53 | insert and then follow the step c) ~ g) in section 1. | ||
54 | |||
55 | 3. undo your changes | ||
56 | The "undo" operation is not supported for a new inserted method | ||
57 | right now, i.e. we can not remove a method currently. | ||
58 | For an overrided method, in order to undo your changes, please | ||
59 | save a copy of the method original ASL code in step c) section 1, | ||
60 | and redo step c) ~ g) to override the method with the original one. | ||
61 | |||
62 | |||
63 | Note: We can use a kernel with multiple custom ACPI method running, | ||
64 | But each individual write to debugfs can implement a SINGLE | ||
65 | method override. i.e. if we want to insert/override multiple | ||
66 | ACPI methods, we need to redo step c) ~ g) for multiple times. | ||
diff --git a/Documentation/blackfin/00-INDEX b/Documentation/blackfin/00-INDEX index d6840a91e1e1..c34e12440fec 100644 --- a/Documentation/blackfin/00-INDEX +++ b/Documentation/blackfin/00-INDEX | |||
@@ -1,9 +1,6 @@ | |||
1 | 00-INDEX | 1 | 00-INDEX |
2 | - This file | 2 | - This file |
3 | 3 | ||
4 | cache-lock.txt | ||
5 | - HOWTO for blackfin cache locking. | ||
6 | |||
7 | cachefeatures.txt | 4 | cachefeatures.txt |
8 | - Supported cache features. | 5 | - Supported cache features. |
9 | 6 | ||
diff --git a/Documentation/blackfin/Makefile b/Documentation/blackfin/Makefile new file mode 100644 index 000000000000..773dbb103f1c --- /dev/null +++ b/Documentation/blackfin/Makefile | |||
@@ -0,0 +1,6 @@ | |||
1 | obj-m := gptimers-example.o | ||
2 | |||
3 | all: modules | ||
4 | |||
5 | modules clean: | ||
6 | $(MAKE) -C ../.. SUBDIRS=$(PWD) $@ | ||
diff --git a/Documentation/blackfin/cache-lock.txt b/Documentation/blackfin/cache-lock.txt deleted file mode 100644 index 88ba1e6c31c3..000000000000 --- a/Documentation/blackfin/cache-lock.txt +++ /dev/null | |||
@@ -1,48 +0,0 @@ | |||
1 | /* | ||
2 | * File: Documentation/blackfin/cache-lock.txt | ||
3 | * Based on: | ||
4 | * Author: | ||
5 | * | ||
6 | * Created: | ||
7 | * Description: This file contains the simple DMA Implementation for Blackfin | ||
8 | * | ||
9 | * Rev: $Id: cache-lock.txt 2384 2006-11-01 04:12:43Z magicyang $ | ||
10 | * | ||
11 | * Modified: | ||
12 | * Copyright 2004-2006 Analog Devices Inc. | ||
13 | * | ||
14 | * Bugs: Enter bugs at http://blackfin.uclinux.org/ | ||
15 | * | ||
16 | */ | ||
17 | |||
18 | How to lock your code in cache in uClinux/blackfin | ||
19 | -------------------------------------------------- | ||
20 | |||
21 | There are only a few steps required to lock your code into the cache. | ||
22 | Currently you can lock the code by Way. | ||
23 | |||
24 | Below are the interface provided for locking the cache. | ||
25 | |||
26 | |||
27 | 1. cache_grab_lock(int Ways); | ||
28 | |||
29 | This function grab the lock for locking your code into the cache specified | ||
30 | by Ways. | ||
31 | |||
32 | |||
33 | 2. cache_lock(int Ways); | ||
34 | |||
35 | This function should be called after your critical code has been executed. | ||
36 | Once the critical code exits, the code is now loaded into the cache. This | ||
37 | function locks the code into the cache. | ||
38 | |||
39 | |||
40 | So, the example sequence will be: | ||
41 | |||
42 | cache_grab_lock(WAY0_L); /* Grab the lock */ | ||
43 | |||
44 | critical_code(); /* Execute the code of interest */ | ||
45 | |||
46 | cache_lock(WAY0_L); /* Lock the cache */ | ||
47 | |||
48 | Where WAY0_L signifies WAY0 locking. | ||
diff --git a/Documentation/blackfin/cachefeatures.txt b/Documentation/blackfin/cachefeatures.txt index 0fbec23becb5..75de51f94515 100644 --- a/Documentation/blackfin/cachefeatures.txt +++ b/Documentation/blackfin/cachefeatures.txt | |||
@@ -41,16 +41,6 @@ | |||
41 | icplb_flush(); | 41 | icplb_flush(); |
42 | dcplb_flush(); | 42 | dcplb_flush(); |
43 | 43 | ||
44 | - Locking the cache. | ||
45 | |||
46 | cache_grab_lock(); | ||
47 | cache_lock(); | ||
48 | |||
49 | Please refer linux-2.6.x/Documentation/blackfin/cache-lock.txt for how to | ||
50 | lock the cache. | ||
51 | |||
52 | Locking the cache is optional feature. | ||
53 | |||
54 | - Miscellaneous cache functions. | 44 | - Miscellaneous cache functions. |
55 | 45 | ||
56 | flush_cache_all(); | 46 | flush_cache_all(); |
diff --git a/Documentation/blackfin/gptimers-example.c b/Documentation/blackfin/gptimers-example.c new file mode 100644 index 000000000000..b1bd6340e748 --- /dev/null +++ b/Documentation/blackfin/gptimers-example.c | |||
@@ -0,0 +1,83 @@ | |||
1 | /* | ||
2 | * Simple gptimers example | ||
3 | * http://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:drivers:gptimers | ||
4 | * | ||
5 | * Copyright 2007-2009 Analog Devices Inc. | ||
6 | * | ||
7 | * Licensed under the GPL-2 or later. | ||
8 | */ | ||
9 | |||
10 | #include <linux/interrupt.h> | ||
11 | #include <linux/module.h> | ||
12 | |||
13 | #include <asm/gptimers.h> | ||
14 | #include <asm/portmux.h> | ||
15 | |||
16 | /* ... random driver includes ... */ | ||
17 | |||
18 | #define DRIVER_NAME "gptimer_example" | ||
19 | |||
20 | struct gptimer_data { | ||
21 | uint32_t period, width; | ||
22 | }; | ||
23 | static struct gptimer_data data; | ||
24 | |||
25 | /* ... random driver state ... */ | ||
26 | |||
27 | static irqreturn_t gptimer_example_irq(int irq, void *dev_id) | ||
28 | { | ||
29 | struct gptimer_data *data = dev_id; | ||
30 | |||
31 | /* make sure it was our timer which caused the interrupt */ | ||
32 | if (!get_gptimer_intr(TIMER5_id)) | ||
33 | return IRQ_NONE; | ||
34 | |||
35 | /* read the width/period values that were captured for the waveform */ | ||
36 | data->width = get_gptimer_pwidth(TIMER5_id); | ||
37 | data->period = get_gptimer_period(TIMER5_id); | ||
38 | |||
39 | /* acknowledge the interrupt */ | ||
40 | clear_gptimer_intr(TIMER5_id); | ||
41 | |||
42 | /* tell the upper layers we took care of things */ | ||
43 | return IRQ_HANDLED; | ||
44 | } | ||
45 | |||
46 | /* ... random driver code ... */ | ||
47 | |||
48 | static int __init gptimer_example_init(void) | ||
49 | { | ||
50 | int ret; | ||
51 | |||
52 | /* grab the peripheral pins */ | ||
53 | ret = peripheral_request(P_TMR5, DRIVER_NAME); | ||
54 | if (ret) { | ||
55 | printk(KERN_NOTICE DRIVER_NAME ": peripheral request failed\n"); | ||
56 | return ret; | ||
57 | } | ||
58 | |||
59 | /* grab the IRQ for the timer */ | ||
60 | ret = request_irq(IRQ_TIMER5, gptimer_example_irq, IRQF_SHARED, DRIVER_NAME, &data); | ||
61 | if (ret) { | ||
62 | printk(KERN_NOTICE DRIVER_NAME ": IRQ request failed\n"); | ||
63 | peripheral_free(P_TMR5); | ||
64 | return ret; | ||
65 | } | ||
66 | |||
67 | /* setup the timer and enable it */ | ||
68 | set_gptimer_config(TIMER5_id, WDTH_CAP | PULSE_HI | PERIOD_CNT | IRQ_ENA); | ||
69 | enable_gptimers(TIMER5bit); | ||
70 | |||
71 | return 0; | ||
72 | } | ||
73 | module_init(gptimer_example_init); | ||
74 | |||
75 | static void __exit gptimer_example_exit(void) | ||
76 | { | ||
77 | disable_gptimers(TIMER5bit); | ||
78 | free_irq(IRQ_TIMER5, &data); | ||
79 | peripheral_free(P_TMR5); | ||
80 | } | ||
81 | module_exit(gptimer_example_exit); | ||
82 | |||
83 | MODULE_LICENSE("BSD"); | ||
diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt index 4d4a644b505e..a99d7031cdf9 100644 --- a/Documentation/cpu-hotplug.txt +++ b/Documentation/cpu-hotplug.txt | |||
@@ -315,41 +315,26 @@ A: The following are what is required for CPU hotplug infrastructure to work | |||
315 | 315 | ||
316 | Q: I need to ensure that a particular cpu is not removed when there is some | 316 | Q: I need to ensure that a particular cpu is not removed when there is some |
317 | work specific to this cpu is in progress. | 317 | work specific to this cpu is in progress. |
318 | A: First switch the current thread context to preferred cpu | 318 | A: There are two ways. If your code can be run in interrupt context, use |
319 | smp_call_function_single(), otherwise use work_on_cpu(). Note that | ||
320 | work_on_cpu() is slow, and can fail due to out of memory: | ||
319 | 321 | ||
320 | int my_func_on_cpu(int cpu) | 322 | int my_func_on_cpu(int cpu) |
321 | { | 323 | { |
322 | cpumask_t saved_mask, new_mask = CPU_MASK_NONE; | 324 | int err; |
323 | int curr_cpu, err = 0; | 325 | get_online_cpus(); |
324 | 326 | if (!cpu_online(cpu)) | |
325 | saved_mask = current->cpus_allowed; | 327 | err = -EINVAL; |
326 | cpu_set(cpu, new_mask); | 328 | else |
327 | err = set_cpus_allowed(current, new_mask); | 329 | #if NEEDS_BLOCKING |
328 | 330 | err = work_on_cpu(cpu, __my_func_on_cpu, NULL); | |
329 | if (err) | 331 | #else |
330 | return err; | 332 | smp_call_function_single(cpu, __my_func_on_cpu, &err, |
331 | 333 | true); | |
332 | /* | 334 | #endif |
333 | * If we got scheduled out just after the return from | 335 | put_online_cpus(); |
334 | * set_cpus_allowed() before running the work, this ensures | 336 | return err; |
335 | * we stay locked. | 337 | } |
336 | */ | ||
337 | curr_cpu = get_cpu(); | ||
338 | |||
339 | if (curr_cpu != cpu) { | ||
340 | err = -EAGAIN; | ||
341 | goto ret; | ||
342 | } else { | ||
343 | /* | ||
344 | * Do work : But cant sleep, since get_cpu() disables preempt | ||
345 | */ | ||
346 | } | ||
347 | ret: | ||
348 | put_cpu(); | ||
349 | set_cpus_allowed(current, saved_mask); | ||
350 | return err; | ||
351 | } | ||
352 | |||
353 | 338 | ||
354 | Q: How do we determine how many CPUs are available for hotplug. | 339 | Q: How do we determine how many CPUs are available for hotplug. |
355 | A: There is no clear spec defined way from ACPI that can give us that | 340 | A: There is no clear spec defined way from ACPI that can give us that |
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/dontdiff b/Documentation/dontdiff index e151b2a36267..3ad6acead949 100644 --- a/Documentation/dontdiff +++ b/Documentation/dontdiff | |||
@@ -103,6 +103,7 @@ gconf | |||
103 | gen-devlist | 103 | gen-devlist |
104 | gen_crc32table | 104 | gen_crc32table |
105 | gen_init_cpio | 105 | gen_init_cpio |
106 | generated | ||
106 | genheaders | 107 | genheaders |
107 | genksyms | 108 | genksyms |
108 | *_gray256.c | 109 | *_gray256.c |
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 2a4d77946c7d..870d190fe617 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt | |||
@@ -291,22 +291,6 @@ Who: Michael Buesch <mb@bu3sch.de> | |||
291 | 291 | ||
292 | --------------------------- | 292 | --------------------------- |
293 | 293 | ||
294 | What: usedac i386 kernel parameter | ||
295 | When: 2.6.27 | ||
296 | Why: replaced by allowdac and no dac combination | ||
297 | Who: Glauber Costa <gcosta@redhat.com> | ||
298 | |||
299 | --------------------------- | ||
300 | |||
301 | What: print_fn_descriptor_symbol() | ||
302 | When: October 2009 | ||
303 | Why: The %pF vsprintf format provides the same functionality in a | ||
304 | simpler way. print_fn_descriptor_symbol() is deprecated but | ||
305 | still present to give out-of-tree modules time to change. | ||
306 | Who: Bjorn Helgaas <bjorn.helgaas@hp.com> | ||
307 | |||
308 | --------------------------- | ||
309 | |||
310 | What: /sys/o2cb symlink | 294 | What: /sys/o2cb symlink |
311 | When: January 2010 | 295 | When: January 2010 |
312 | 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 |
@@ -490,3 +474,22 @@ Why: Obsoleted by the adt7475 driver. | |||
490 | Who: Jean Delvare <khali@linux-fr.org> | 474 | Who: Jean Delvare <khali@linux-fr.org> |
491 | 475 | ||
492 | --------------------------- | 476 | --------------------------- |
477 | What: Support for lcd_switch and display_get in asus-laptop driver | ||
478 | When: March 2010 | ||
479 | Why: These two features use non-standard interfaces. There are the | ||
480 | only features that really need multiple path to guess what's | ||
481 | the right method name on a specific laptop. | ||
482 | |||
483 | Removing them will allow to remove a lot of code an significantly | ||
484 | clean the drivers. | ||
485 | |||
486 | This will affect the backlight code which won't be able to know | ||
487 | if the backlight is on or off. The platform display file will also be | ||
488 | write only (like the one in eeepc-laptop). | ||
489 | |||
490 | This should'nt affect a lot of user because they usually know | ||
491 | when their display is on or off. | ||
492 | |||
493 | Who: Corentin Chary <corentin.chary@gmail.com> | ||
494 | |||
495 | ---------------------------- | ||
diff --git a/Documentation/filesystems/00-INDEX b/Documentation/filesystems/00-INDEX index 7001782ab932..875d49696b6e 100644 --- a/Documentation/filesystems/00-INDEX +++ b/Documentation/filesystems/00-INDEX | |||
@@ -1,7 +1,5 @@ | |||
1 | 00-INDEX | 1 | 00-INDEX |
2 | - this file (info on some of the filesystems supported by linux). | 2 | - this file (info on some of the filesystems supported by linux). |
3 | Exporting | ||
4 | - explanation of how to make filesystems exportable. | ||
5 | Locking | 3 | Locking |
6 | - info on locking rules as they pertain to Linux VFS. | 4 | - info on locking rules as they pertain to Linux VFS. |
7 | 9p.txt | 5 | 9p.txt |
@@ -68,12 +66,8 @@ mandatory-locking.txt | |||
68 | - info on the Linux implementation of Sys V mandatory file locking. | 66 | - info on the Linux implementation of Sys V mandatory file locking. |
69 | ncpfs.txt | 67 | ncpfs.txt |
70 | - info on Novell Netware(tm) filesystem using NCP protocol. | 68 | - info on Novell Netware(tm) filesystem using NCP protocol. |
71 | nfs41-server.txt | 69 | nfs/ |
72 | - info on the Linux server implementation of NFSv4 minor version 1. | 70 | - nfs-related documentation. |
73 | nfs-rdma.txt | ||
74 | - how to install and setup the Linux NFS/RDMA client and server software. | ||
75 | nfsroot.txt | ||
76 | - short guide on setting up a diskless box with NFS root filesystem. | ||
77 | nilfs2.txt | 71 | nilfs2.txt |
78 | - info and mount options for the NILFS2 filesystem. | 72 | - info and mount options for the NILFS2 filesystem. |
79 | ntfs.txt | 73 | ntfs.txt |
@@ -92,8 +86,6 @@ relay.txt | |||
92 | - info on relay, for efficient streaming from kernel to user space. | 86 | - info on relay, for efficient streaming from kernel to user space. |
93 | romfs.txt | 87 | romfs.txt |
94 | - description of the ROMFS filesystem. | 88 | - description of the ROMFS filesystem. |
95 | rpc-cache.txt | ||
96 | - introduction to the caching mechanisms in the sunrpc layer. | ||
97 | seq_file.txt | 89 | seq_file.txt |
98 | - how to use the seq_file API | 90 | - how to use the seq_file API |
99 | sharedsubtree.txt | 91 | sharedsubtree.txt |
diff --git a/Documentation/filesystems/nfs/00-INDEX b/Documentation/filesystems/nfs/00-INDEX new file mode 100644 index 000000000000..2f68cd688769 --- /dev/null +++ b/Documentation/filesystems/nfs/00-INDEX | |||
@@ -0,0 +1,16 @@ | |||
1 | 00-INDEX | ||
2 | - this file (nfs-related documentation). | ||
3 | Exporting | ||
4 | - explanation of how to make filesystems exportable. | ||
5 | knfsd-stats.txt | ||
6 | - statistics which the NFS server makes available to user space. | ||
7 | nfs.txt | ||
8 | - nfs client, and DNS resolution for fs_locations. | ||
9 | nfs41-server.txt | ||
10 | - info on the Linux server implementation of NFSv4 minor version 1. | ||
11 | nfs-rdma.txt | ||
12 | - how to install and setup the Linux NFS/RDMA client and server software | ||
13 | nfsroot.txt | ||
14 | - short guide on setting up a diskless box with NFS root filesystem. | ||
15 | rpc-cache.txt | ||
16 | - introduction to the caching mechanisms in the sunrpc layer. | ||
diff --git a/Documentation/filesystems/Exporting b/Documentation/filesystems/nfs/Exporting index 87019d2b5981..87019d2b5981 100644 --- a/Documentation/filesystems/Exporting +++ b/Documentation/filesystems/nfs/Exporting | |||
diff --git a/Documentation/filesystems/knfsd-stats.txt b/Documentation/filesystems/nfs/knfsd-stats.txt index 64ced5149d37..64ced5149d37 100644 --- a/Documentation/filesystems/knfsd-stats.txt +++ b/Documentation/filesystems/nfs/knfsd-stats.txt | |||
diff --git a/Documentation/filesystems/nfs-rdma.txt b/Documentation/filesystems/nfs/nfs-rdma.txt index e386f7e4bcee..e386f7e4bcee 100644 --- a/Documentation/filesystems/nfs-rdma.txt +++ b/Documentation/filesystems/nfs/nfs-rdma.txt | |||
diff --git a/Documentation/filesystems/nfs.txt b/Documentation/filesystems/nfs/nfs.txt index f50f26ce6cd0..f50f26ce6cd0 100644 --- a/Documentation/filesystems/nfs.txt +++ b/Documentation/filesystems/nfs/nfs.txt | |||
diff --git a/Documentation/filesystems/nfs41-server.txt b/Documentation/filesystems/nfs/nfs41-server.txt index 5920fe26e6ff..1bd0d0c05171 100644 --- a/Documentation/filesystems/nfs41-server.txt +++ b/Documentation/filesystems/nfs/nfs41-server.txt | |||
@@ -41,7 +41,7 @@ interoperability problems with future clients. Known issues: | |||
41 | conformant with the spec (for example, we don't use kerberos | 41 | conformant with the spec (for example, we don't use kerberos |
42 | on the backchannel correctly). | 42 | on the backchannel correctly). |
43 | - no trunking support: no clients currently take advantage of | 43 | - no trunking support: no clients currently take advantage of |
44 | trunking, but this is a mandatory failure, and its use is | 44 | trunking, but this is a mandatory feature, and its use is |
45 | recommended to clients in a number of places. (E.g. to ensure | 45 | recommended to clients in a number of places. (E.g. to ensure |
46 | timely renewal in case an existing connection's retry timeouts | 46 | timely renewal in case an existing connection's retry timeouts |
47 | have gotten too long; see section 8.3 of the draft.) | 47 | have gotten too long; see section 8.3 of the draft.) |
@@ -213,3 +213,10 @@ The following cases aren't supported yet: | |||
213 | DESTROY_CLIENTID, DESTROY_SESSION, EXCHANGE_ID. | 213 | DESTROY_CLIENTID, DESTROY_SESSION, EXCHANGE_ID. |
214 | * DESTROY_SESSION MUST be the final operation in the COMPOUND request. | 214 | * DESTROY_SESSION MUST be the final operation in the COMPOUND request. |
215 | 215 | ||
216 | Nonstandard compound limitations: | ||
217 | * No support for a sessions fore channel RPC compound that requires both a | ||
218 | ca_maxrequestsize request and a ca_maxresponsesize reply, so we may | ||
219 | fail to live up to the promise we made in CREATE_SESSION fore channel | ||
220 | negotiation. | ||
221 | * No more than one IO operation (read, write, readdir) allowed per | ||
222 | compound. | ||
diff --git a/Documentation/filesystems/nfsroot.txt b/Documentation/filesystems/nfs/nfsroot.txt index 3ba0b945aaf8..3ba0b945aaf8 100644 --- a/Documentation/filesystems/nfsroot.txt +++ b/Documentation/filesystems/nfs/nfsroot.txt | |||
diff --git a/Documentation/filesystems/rpc-cache.txt b/Documentation/filesystems/nfs/rpc-cache.txt index 8a382bea6808..8a382bea6808 100644 --- a/Documentation/filesystems/rpc-cache.txt +++ b/Documentation/filesystems/nfs/rpc-cache.txt | |||
diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting index 92b888d540a6..a7e9746ee7ea 100644 --- a/Documentation/filesystems/porting +++ b/Documentation/filesystems/porting | |||
@@ -140,7 +140,7 @@ Callers of notify_change() need ->i_mutex now. | |||
140 | New super_block field "struct export_operations *s_export_op" for | 140 | New super_block field "struct export_operations *s_export_op" for |
141 | explicit support for exporting, e.g. via NFS. The structure is fully | 141 | explicit support for exporting, e.g. via NFS. The structure is fully |
142 | documented at its declaration in include/linux/fs.h, and in | 142 | documented at its declaration in include/linux/fs.h, and in |
143 | Documentation/filesystems/Exporting. | 143 | Documentation/filesystems/nfs/Exporting. |
144 | 144 | ||
145 | Briefly it allows for the definition of decode_fh and encode_fh operations | 145 | Briefly it allows for the definition of decode_fh and encode_fh operations |
146 | to encode and decode filehandles, and allows the filesystem to use | 146 | to encode and decode filehandles, and allows the filesystem to use |
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/k10temp b/Documentation/hwmon/k10temp new file mode 100644 index 000000000000..a7a18d453a51 --- /dev/null +++ b/Documentation/hwmon/k10temp | |||
@@ -0,0 +1,60 @@ | |||
1 | Kernel driver k10temp | ||
2 | ===================== | ||
3 | |||
4 | Supported chips: | ||
5 | * AMD Family 10h processors: | ||
6 | Socket F: Quad-Core/Six-Core/Embedded Opteron | ||
7 | Socket AM2+: Opteron, Phenom (II) X3/X4 | ||
8 | Socket AM3: Quad-Core Opteron, Athlon/Phenom II X2/X3/X4, Sempron II | ||
9 | Socket S1G3: Athlon II, Sempron, Turion II | ||
10 | * AMD Family 11h processors: | ||
11 | Socket S1G2: Athlon (X2), Sempron (X2), Turion X2 (Ultra) | ||
12 | |||
13 | Prefix: 'k10temp' | ||
14 | Addresses scanned: PCI space | ||
15 | Datasheets: | ||
16 | BIOS and Kernel Developer's Guide (BKDG) For AMD Family 10h Processors: | ||
17 | http://support.amd.com/us/Processor_TechDocs/31116.pdf | ||
18 | BIOS and Kernel Developer's Guide (BKDG) for AMD Family 11h Processors: | ||
19 | http://support.amd.com/us/Processor_TechDocs/41256.pdf | ||
20 | Revision Guide for AMD Family 10h Processors: | ||
21 | http://support.amd.com/us/Processor_TechDocs/41322.pdf | ||
22 | Revision Guide for AMD Family 11h Processors: | ||
23 | http://support.amd.com/us/Processor_TechDocs/41788.pdf | ||
24 | AMD Family 11h Processor Power and Thermal Data Sheet for Notebooks: | ||
25 | http://support.amd.com/us/Processor_TechDocs/43373.pdf | ||
26 | AMD Family 10h Server and Workstation Processor Power and Thermal Data Sheet: | ||
27 | http://support.amd.com/us/Processor_TechDocs/43374.pdf | ||
28 | AMD Family 10h Desktop Processor Power and Thermal Data Sheet: | ||
29 | http://support.amd.com/us/Processor_TechDocs/43375.pdf | ||
30 | |||
31 | Author: Clemens Ladisch <clemens@ladisch.de> | ||
32 | |||
33 | Description | ||
34 | ----------- | ||
35 | |||
36 | This driver permits reading of the internal temperature sensor of AMD | ||
37 | Family 10h and 11h processors. | ||
38 | |||
39 | All these processors have a sensor, but on older revisions of Family 10h | ||
40 | processors, the sensor may return inconsistent values (erratum 319). The | ||
41 | driver will refuse to load on these revisions unless you specify the | ||
42 | "force=1" module parameter. | ||
43 | |||
44 | There is one temperature measurement value, available as temp1_input in | ||
45 | sysfs. It is measured in degrees Celsius with a resolution of 1/8th degree. | ||
46 | Please note that it is defined as a relative value; to quote the AMD manual: | ||
47 | |||
48 | Tctl is the processor temperature control value, used by the platform to | ||
49 | control cooling systems. Tctl is a non-physical temperature on an | ||
50 | arbitrary scale measured in degrees. It does _not_ represent an actual | ||
51 | physical temperature like die or case temperature. Instead, it specifies | ||
52 | the processor temperature relative to the point at which the system must | ||
53 | supply the maximum cooling for the processor's specified maximum case | ||
54 | temperature and maximum thermal power dissipation. | ||
55 | |||
56 | The maximum value for Tctl is available in the file temp1_max. | ||
57 | |||
58 | If the BIOS has enabled hardware temperature control, the threshold at | ||
59 | which the processor will throttle itself to avoid damage is available in | ||
60 | temp1_crit and temp1_crit_hyst. | ||
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/infiniband/ipoib.txt b/Documentation/infiniband/ipoib.txt index 6d40f00b358c..64eeb55d0c09 100644 --- a/Documentation/infiniband/ipoib.txt +++ b/Documentation/infiniband/ipoib.txt | |||
@@ -36,11 +36,11 @@ Datagram vs Connected modes | |||
36 | fabric with a 2K MTU, the IPoIB MTU will be 2048 - 4 = 2044 bytes. | 36 | fabric with a 2K MTU, the IPoIB MTU will be 2048 - 4 = 2044 bytes. |
37 | 37 | ||
38 | In connected mode, the IB RC (Reliable Connected) transport is used. | 38 | In connected mode, the IB RC (Reliable Connected) transport is used. |
39 | Connected mode is to takes advantage of the connected nature of the | 39 | Connected mode takes advantage of the connected nature of the IB |
40 | IB transport and allows an MTU up to the maximal IP packet size of | 40 | transport and allows an MTU up to the maximal IP packet size of 64K, |
41 | 64K, which reduces the number of IP packets needed for handling | 41 | which reduces the number of IP packets needed for handling large UDP |
42 | large UDP datagrams, TCP segments, etc and increases the performance | 42 | datagrams, TCP segments, etc and increases the performance for large |
43 | for large messages. | 43 | messages. |
44 | 44 | ||
45 | In connected mode, the interface's UD QP is still used for multicast | 45 | In connected mode, the interface's UD QP is still used for multicast |
46 | and communication with peers that don't support connected mode. In | 46 | and communication with peers that don't support connected mode. In |
diff --git a/Documentation/kbuild/kbuild.txt b/Documentation/kbuild/kbuild.txt index bb3bf38f03da..6f8c1cabbc5d 100644 --- a/Documentation/kbuild/kbuild.txt +++ b/Documentation/kbuild/kbuild.txt | |||
@@ -1,3 +1,17 @@ | |||
1 | Output files | ||
2 | |||
3 | modules.order | ||
4 | -------------------------------------------------- | ||
5 | This file records the order in which modules appear in Makefiles. This | ||
6 | is used by modprobe to deterministically resolve aliases that match | ||
7 | multiple modules. | ||
8 | |||
9 | modules.builtin | ||
10 | -------------------------------------------------- | ||
11 | This file lists all modules that are built into the kernel. This is used | ||
12 | by modprobe to not fail when trying to load something builtin. | ||
13 | |||
14 | |||
1 | Environment variables | 15 | Environment variables |
2 | 16 | ||
3 | KCPPFLAGS | 17 | KCPPFLAGS |
diff --git a/Documentation/kbuild/kconfig.txt b/Documentation/kbuild/kconfig.txt index 849b5e56d06f..49efae703979 100644 --- a/Documentation/kbuild/kconfig.txt +++ b/Documentation/kbuild/kconfig.txt | |||
@@ -103,10 +103,16 @@ KCONFIG_AUTOCONFIG | |||
103 | This environment variable can be set to specify the path & name of the | 103 | This environment variable can be set to specify the path & name of the |
104 | "auto.conf" file. Its default value is "include/config/auto.conf". | 104 | "auto.conf" file. Its default value is "include/config/auto.conf". |
105 | 105 | ||
106 | KCONFIG_TRISTATE | ||
107 | -------------------------------------------------- | ||
108 | This environment variable can be set to specify the path & name of the | ||
109 | "tristate.conf" file. Its default value is "include/config/tristate.conf". | ||
110 | |||
106 | KCONFIG_AUTOHEADER | 111 | KCONFIG_AUTOHEADER |
107 | -------------------------------------------------- | 112 | -------------------------------------------------- |
108 | This environment variable can be set to specify the path & name of the | 113 | This environment variable can be set to specify the path & name of the |
109 | "autoconf.h" (header) file. Its default value is "include/linux/autoconf.h". | 114 | "autoconf.h" (header) file. |
115 | Its default value is "include/generated/autoconf.h". | ||
110 | 116 | ||
111 | 117 | ||
112 | ====================================================================== | 118 | ====================================================================== |
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index ab95d3ada5c7..5ba4d9dff113 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt | |||
@@ -1032,7 +1032,7 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1032 | No delay | 1032 | No delay |
1033 | 1033 | ||
1034 | ip= [IP_PNP] | 1034 | ip= [IP_PNP] |
1035 | See Documentation/filesystems/nfsroot.txt. | 1035 | See Documentation/filesystems/nfs/nfsroot.txt. |
1036 | 1036 | ||
1037 | ip2= [HW] Set IO/IRQ pairs for up to 4 IntelliPort boards | 1037 | ip2= [HW] Set IO/IRQ pairs for up to 4 IntelliPort boards |
1038 | See comment before ip2_setup() in | 1038 | See comment before ip2_setup() in |
@@ -1553,10 +1553,10 @@ and is between 256 and 4096 characters. It is defined in the file | |||
1553 | going to be removed in 2.6.29. | 1553 | going to be removed in 2.6.29. |
1554 | 1554 | ||
1555 | nfsaddrs= [NFS] | 1555 | nfsaddrs= [NFS] |
1556 | See Documentation/filesystems/nfsroot.txt. | 1556 | See Documentation/filesystems/nfs/nfsroot.txt. |
1557 | 1557 | ||
1558 | nfsroot= [NFS] nfs root filesystem for disk-less boxes. | 1558 | nfsroot= [NFS] nfs root filesystem for disk-less boxes. |
1559 | See Documentation/filesystems/nfsroot.txt. | 1559 | See Documentation/filesystems/nfs/nfsroot.txt. |
1560 | 1560 | ||
1561 | nfs.callback_tcpport= | 1561 | nfs.callback_tcpport= |
1562 | [NFS] set the TCP port on which the NFSv4 callback | 1562 | [NFS] set the TCP port on which the NFSv4 callback |
@@ -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/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt index aafcaa634191..169091f75e6d 100644 --- a/Documentation/laptops/thinkpad-acpi.txt +++ b/Documentation/laptops/thinkpad-acpi.txt | |||
@@ -1,7 +1,7 @@ | |||
1 | ThinkPad ACPI Extras Driver | 1 | ThinkPad ACPI Extras Driver |
2 | 2 | ||
3 | Version 0.23 | 3 | Version 0.24 |
4 | April 10th, 2009 | 4 | December 11th, 2009 |
5 | 5 | ||
6 | Borislav Deianov <borislav@users.sf.net> | 6 | Borislav Deianov <borislav@users.sf.net> |
7 | Henrique de Moraes Holschuh <hmh@hmh.eng.br> | 7 | Henrique de Moraes Holschuh <hmh@hmh.eng.br> |
@@ -460,6 +460,8 @@ event code Key Notes | |||
460 | For Lenovo ThinkPads with a new | 460 | For Lenovo ThinkPads with a new |
461 | BIOS, it has to be handled either | 461 | BIOS, it has to be handled either |
462 | by the ACPI OSI, or by userspace. | 462 | by the ACPI OSI, or by userspace. |
463 | The driver does the right thing, | ||
464 | never mess with this. | ||
463 | 0x1011 0x10 FN+END Brightness down. See brightness | 465 | 0x1011 0x10 FN+END Brightness down. See brightness |
464 | up for details. | 466 | up for details. |
465 | 467 | ||
@@ -582,46 +584,15 @@ with hotkey_report_mode. | |||
582 | 584 | ||
583 | Brightness hotkey notes: | 585 | Brightness hotkey notes: |
584 | 586 | ||
585 | These are the current sane choices for brightness key mapping in | 587 | Don't mess with the brightness hotkeys in a Thinkpad. If you want |
586 | thinkpad-acpi: | 588 | notifications for OSD, use the sysfs backlight class event support. |
587 | 589 | ||
588 | For IBM and Lenovo models *without* ACPI backlight control (the ones on | 590 | The driver will issue KEY_BRIGHTNESS_UP and KEY_BRIGHTNESS_DOWN events |
589 | which thinkpad-acpi will autoload its backlight interface by default, | 591 | automatically for the cases were userspace has to do something to |
590 | and on which ACPI video does not export a backlight interface): | 592 | implement brightness changes. When you override these events, you will |
591 | 593 | either fail to handle properly the ThinkPads that require explicit | |
592 | 1. Don't enable or map the brightness hotkeys in thinkpad-acpi, as | 594 | action to change backlight brightness, or the ThinkPads that require |
593 | these older firmware versions unfortunately won't respect the hotkey | 595 | that no action be taken to work properly. |
594 | mask for brightness keys anyway, and always reacts to them. This | ||
595 | usually work fine, unless X.org drivers are doing something to block | ||
596 | the BIOS. In that case, use (3) below. This is the default mode of | ||
597 | operation. | ||
598 | |||
599 | 2. Enable the hotkeys, but map them to something else that is NOT | ||
600 | KEY_BRIGHTNESS_UP/DOWN or any other keycode that would cause | ||
601 | userspace to try to change the backlight level, and use that as an | ||
602 | on-screen-display hint. | ||
603 | |||
604 | 3. IF AND ONLY IF X.org drivers find a way to block the firmware from | ||
605 | automatically changing the brightness, enable the hotkeys and map | ||
606 | them to KEY_BRIGHTNESS_UP and KEY_BRIGHTNESS_DOWN, and feed that to | ||
607 | something that calls xbacklight. thinkpad-acpi will not be able to | ||
608 | change brightness in that case either, so you should disable its | ||
609 | backlight interface. | ||
610 | |||
611 | For Lenovo models *with* ACPI backlight control: | ||
612 | |||
613 | 1. Load up ACPI video and use that. ACPI video will report ACPI | ||
614 | events for brightness change keys. Do not mess with thinkpad-acpi | ||
615 | defaults in this case. thinkpad-acpi should not have anything to do | ||
616 | with backlight events in a scenario where ACPI video is loaded: | ||
617 | brightness hotkeys must be disabled, and the backlight interface is | ||
618 | to be kept disabled as well. This is the default mode of operation. | ||
619 | |||
620 | 2. Do *NOT* load up ACPI video, enable the hotkeys in thinkpad-acpi, | ||
621 | and map them to KEY_BRIGHTNESS_UP and KEY_BRIGHTNESS_DOWN. Process | ||
622 | these keys on userspace somehow (e.g. by calling xbacklight). | ||
623 | The driver will do this automatically if it detects that ACPI video | ||
624 | has been disabled. | ||
625 | 596 | ||
626 | 597 | ||
627 | Bluetooth | 598 | Bluetooth |
@@ -1121,25 +1092,61 @@ WARNING: | |||
1121 | its level up and down at every change. | 1092 | its level up and down at every change. |
1122 | 1093 | ||
1123 | 1094 | ||
1124 | Volume control -- /proc/acpi/ibm/volume | 1095 | Volume control |
1125 | --------------------------------------- | 1096 | -------------- |
1097 | |||
1098 | procfs: /proc/acpi/ibm/volume | ||
1099 | ALSA: "ThinkPad Console Audio Control", default ID: "ThinkPadEC" | ||
1100 | |||
1101 | NOTE: by default, the volume control interface operates in read-only | ||
1102 | mode, as it is supposed to be used for on-screen-display purposes. | ||
1103 | The read/write mode can be enabled through the use of the | ||
1104 | "volume_control=1" module parameter. | ||
1126 | 1105 | ||
1127 | This feature allows volume control on ThinkPad models which don't have | 1106 | NOTE: distros are urged to not enable volume_control by default, this |
1128 | a hardware volume knob. The available commands are: | 1107 | should be done by the local admin only. The ThinkPad UI is for the |
1108 | console audio control to be done through the volume keys only, and for | ||
1109 | the desktop environment to just provide on-screen-display feedback. | ||
1110 | Software volume control should be done only in the main AC97/HDA | ||
1111 | mixer. | ||
1112 | |||
1113 | This feature allows volume control on ThinkPad models with a digital | ||
1114 | volume knob (when available, not all models have it), as well as | ||
1115 | mute/unmute control. The available commands are: | ||
1129 | 1116 | ||
1130 | echo up >/proc/acpi/ibm/volume | 1117 | echo up >/proc/acpi/ibm/volume |
1131 | echo down >/proc/acpi/ibm/volume | 1118 | echo down >/proc/acpi/ibm/volume |
1132 | echo mute >/proc/acpi/ibm/volume | 1119 | echo mute >/proc/acpi/ibm/volume |
1120 | echo unmute >/proc/acpi/ibm/volume | ||
1133 | echo 'level <level>' >/proc/acpi/ibm/volume | 1121 | echo 'level <level>' >/proc/acpi/ibm/volume |
1134 | 1122 | ||
1135 | The <level> number range is 0 to 15 although not all of them may be | 1123 | The <level> number range is 0 to 14 although not all of them may be |
1136 | distinct. The unmute the volume after the mute command, use either the | 1124 | distinct. The unmute the volume after the mute command, use either the |
1137 | up or down command (the level command will not unmute the volume). | 1125 | up or down command (the level command will not unmute the volume), or |
1126 | the unmute command. | ||
1127 | |||
1138 | The current volume level and mute state is shown in the file. | 1128 | The current volume level and mute state is shown in the file. |
1139 | 1129 | ||
1140 | The ALSA mixer interface to this feature is still missing, but patches | 1130 | You can use the volume_capabilities parameter to tell the driver |
1141 | to add it exist. That problem should be addressed in the not so | 1131 | whether your thinkpad has volume control or mute-only control: |
1142 | distant future. | 1132 | volume_capabilities=1 for mixers with mute and volume control, |
1133 | volume_capabilities=2 for mixers with only mute control. | ||
1134 | |||
1135 | If the driver misdetects the capabilities for your ThinkPad model, | ||
1136 | please report this to ibm-acpi-devel@lists.sourceforge.net, so that we | ||
1137 | can update the driver. | ||
1138 | |||
1139 | There are two strategies for volume control. To select which one | ||
1140 | should be used, use the volume_mode module parameter: volume_mode=1 | ||
1141 | selects EC mode, and volume_mode=3 selects EC mode with NVRAM backing | ||
1142 | (so that volume/mute changes are remembered across shutdown/reboot). | ||
1143 | |||
1144 | The driver will operate in volume_mode=3 by default. If that does not | ||
1145 | work well on your ThinkPad model, please report this to | ||
1146 | ibm-acpi-devel@lists.sourceforge.net. | ||
1147 | |||
1148 | The driver supports the standard ALSA module parameters. If the ALSA | ||
1149 | mixer is disabled, the driver will disable all volume functionality. | ||
1143 | 1150 | ||
1144 | 1151 | ||
1145 | Fan control and monitoring: fan speed, fan enable/disable | 1152 | Fan control and monitoring: fan speed, fan enable/disable |
@@ -1405,6 +1412,7 @@ to enable more than one output class, just add their values. | |||
1405 | 0x0008 HKEY event interface, hotkeys | 1412 | 0x0008 HKEY event interface, hotkeys |
1406 | 0x0010 Fan control | 1413 | 0x0010 Fan control |
1407 | 0x0020 Backlight brightness | 1414 | 0x0020 Backlight brightness |
1415 | 0x0040 Audio mixer/volume control | ||
1408 | 1416 | ||
1409 | There is also a kernel build option to enable more debugging | 1417 | There is also a kernel build option to enable more debugging |
1410 | information, which may be necessary to debug driver problems. | 1418 | information, which may be necessary to debug driver problems. |
@@ -1465,3 +1473,9 @@ Sysfs interface changelog: | |||
1465 | and it is always able to disable hot keys. Very old | 1473 | and it is always able to disable hot keys. Very old |
1466 | thinkpads are properly supported. hotkey_bios_mask | 1474 | thinkpads are properly supported. hotkey_bios_mask |
1467 | is deprecated and marked for removal. | 1475 | is deprecated and marked for removal. |
1476 | |||
1477 | 0x020600: Marker for backlight change event support. | ||
1478 | |||
1479 | 0x020700: Support for mute-only mixers. | ||
1480 | Volume control in read-only mode by default. | ||
1481 | Marker for ALSA mixer support. | ||
diff --git a/Documentation/md.txt b/Documentation/md.txt index 4edd39ec7db9..188f4768f1d5 100644 --- a/Documentation/md.txt +++ b/Documentation/md.txt | |||
@@ -233,9 +233,9 @@ All md devices contain: | |||
233 | 233 | ||
234 | resync_start | 234 | resync_start |
235 | The point at which resync should start. If no resync is needed, | 235 | The point at which resync should start. If no resync is needed, |
236 | this will be a very large number. At array creation it will | 236 | this will be a very large number (or 'none' since 2.6.30-rc1). At |
237 | default to 0, though starting the array as 'clean' will | 237 | array creation it will default to 0, though starting the array as |
238 | set it much larger. | 238 | 'clean' will set it much larger. |
239 | 239 | ||
240 | new_dev | 240 | new_dev |
241 | This file can be written but not read. The value written should | 241 | This file can be written but not read. The value written should |
@@ -296,6 +296,51 @@ All md devices contain: | |||
296 | active-idle | 296 | active-idle |
297 | like active, but no writes have been seen for a while (safe_mode_delay). | 297 | like active, but no writes have been seen for a while (safe_mode_delay). |
298 | 298 | ||
299 | bitmap/location | ||
300 | This indicates where the write-intent bitmap for the array is | ||
301 | stored. | ||
302 | It can be one of "none", "file" or "[+-]N". | ||
303 | "file" may later be extended to "file:/file/name" | ||
304 | "[+-]N" means that many sectors from the start of the metadata. | ||
305 | This is replicated on all devices. For arrays with externally | ||
306 | managed metadata, the offset is from the beginning of the | ||
307 | device. | ||
308 | bitmap/chunksize | ||
309 | The size, in bytes, of the chunk which will be represented by a | ||
310 | single bit. For RAID456, it is a portion of an individual | ||
311 | device. For RAID10, it is a portion of the array. For RAID1, it | ||
312 | is both (they come to the same thing). | ||
313 | bitmap/time_base | ||
314 | The time, in seconds, between looking for bits in the bitmap to | ||
315 | be cleared. In the current implementation, a bit will be cleared | ||
316 | between 2 and 3 times "time_base" after all the covered blocks | ||
317 | are known to be in-sync. | ||
318 | bitmap/backlog | ||
319 | When write-mostly devices are active in a RAID1, write requests | ||
320 | to those devices proceed in the background - the filesystem (or | ||
321 | other user of the device) does not have to wait for them. | ||
322 | 'backlog' sets a limit on the number of concurrent background | ||
323 | writes. If there are more than this, new writes will by | ||
324 | synchronous. | ||
325 | bitmap/metadata | ||
326 | This can be either 'internal' or 'external'. | ||
327 | 'internal' is the default and means the metadata for the bitmap | ||
328 | is stored in the first 256 bytes of the allocated space and is | ||
329 | managed by the md module. | ||
330 | 'external' means that bitmap metadata is managed externally to | ||
331 | the kernel (i.e. by some userspace program) | ||
332 | bitmap/can_clear | ||
333 | This is either 'true' or 'false'. If 'true', then bits in the | ||
334 | bitmap will be cleared when the corresponding blocks are thought | ||
335 | to be in-sync. If 'false', bits will never be cleared. | ||
336 | This is automatically set to 'false' if a write happens on a | ||
337 | degraded array, or if the array becomes degraded during a write. | ||
338 | When metadata is managed externally, it should be set to true | ||
339 | once the array becomes non-degraded, and this fact has been | ||
340 | recorded in the metadata. | ||
341 | |||
342 | |||
343 | |||
299 | 344 | ||
300 | As component devices are added to an md array, they appear in the 'md' | 345 | As component devices are added to an md array, they appear in the 'md' |
301 | directory as new directories named | 346 | directory as new directories named |
@@ -334,8 +379,9 @@ Each directory contains: | |||
334 | Writing "writemostly" sets the writemostly flag. | 379 | Writing "writemostly" sets the writemostly flag. |
335 | Writing "-writemostly" clears the writemostly flag. | 380 | Writing "-writemostly" clears the writemostly flag. |
336 | Writing "blocked" sets the "blocked" flag. | 381 | Writing "blocked" sets the "blocked" flag. |
337 | Writing "-blocked" clear the "blocked" flag and allows writes | 382 | Writing "-blocked" clears the "blocked" flag and allows writes |
338 | to complete. | 383 | to complete. |
384 | Writing "in_sync" sets the in_sync flag. | ||
339 | 385 | ||
340 | This file responds to select/poll. Any change to 'faulty' | 386 | This file responds to select/poll. Any change to 'faulty' |
341 | or 'blocked' causes an event. | 387 | or 'blocked' causes an event. |
@@ -372,6 +418,24 @@ Each directory contains: | |||
372 | array. If a value less than the current component_size is | 418 | array. If a value less than the current component_size is |
373 | written, it will be rejected. | 419 | written, it will be rejected. |
374 | 420 | ||
421 | recovery_start | ||
422 | |||
423 | When the device is not 'in_sync', this records the number of | ||
424 | sectors from the start of the device which are known to be | ||
425 | correct. This is normally zero, but during a recovery | ||
426 | operation is will steadily increase, and if the recovery is | ||
427 | interrupted, restoring this value can cause recovery to | ||
428 | avoid repeating the earlier blocks. With v1.x metadata, this | ||
429 | value is saved and restored automatically. | ||
430 | |||
431 | This can be set whenever the device is not an active member of | ||
432 | the array, either before the array is activated, or before | ||
433 | the 'slot' is set. | ||
434 | |||
435 | Setting this to 'none' is equivalent to setting 'in_sync'. | ||
436 | Setting to any other value also clears the 'in_sync' flag. | ||
437 | |||
438 | |||
375 | 439 | ||
376 | An active md device will also contain and entry for each active device | 440 | An active md device will also contain and entry for each active device |
377 | in the array. These are named | 441 | in the array. These are named |
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/powerpc/dts-bindings/nintendo/gamecube.txt b/Documentation/powerpc/dts-bindings/nintendo/gamecube.txt new file mode 100644 index 000000000000..b558585b1aaf --- /dev/null +++ b/Documentation/powerpc/dts-bindings/nintendo/gamecube.txt | |||
@@ -0,0 +1,109 @@ | |||
1 | |||
2 | Nintendo GameCube device tree | ||
3 | ============================= | ||
4 | |||
5 | 1) The "flipper" node | ||
6 | |||
7 | This node represents the multi-function "Flipper" chip, which packages | ||
8 | many of the devices found in the Nintendo GameCube. | ||
9 | |||
10 | Required properties: | ||
11 | |||
12 | - compatible : Should be "nintendo,flipper" | ||
13 | |||
14 | 1.a) The Video Interface (VI) node | ||
15 | |||
16 | Represents the interface between the graphics processor and a external | ||
17 | video encoder. | ||
18 | |||
19 | Required properties: | ||
20 | |||
21 | - compatible : should be "nintendo,flipper-vi" | ||
22 | - reg : should contain the VI registers location and length | ||
23 | - interrupts : should contain the VI interrupt | ||
24 | |||
25 | 1.b) The Processor Interface (PI) node | ||
26 | |||
27 | Represents the data and control interface between the main processor | ||
28 | and graphics and audio processor. | ||
29 | |||
30 | Required properties: | ||
31 | |||
32 | - compatible : should be "nintendo,flipper-pi" | ||
33 | - reg : should contain the PI registers location and length | ||
34 | |||
35 | 1.b.i) The "Flipper" interrupt controller node | ||
36 | |||
37 | Represents the interrupt controller within the "Flipper" chip. | ||
38 | The node for the "Flipper" interrupt controller must be placed under | ||
39 | the PI node. | ||
40 | |||
41 | Required properties: | ||
42 | |||
43 | - compatible : should be "nintendo,flipper-pic" | ||
44 | |||
45 | 1.c) The Digital Signal Procesor (DSP) node | ||
46 | |||
47 | Represents the digital signal processor interface, designed to offload | ||
48 | audio related tasks. | ||
49 | |||
50 | Required properties: | ||
51 | |||
52 | - compatible : should be "nintendo,flipper-dsp" | ||
53 | - reg : should contain the DSP registers location and length | ||
54 | - interrupts : should contain the DSP interrupt | ||
55 | |||
56 | 1.c.i) The Auxiliary RAM (ARAM) node | ||
57 | |||
58 | Represents the non cpu-addressable ram designed mainly to store audio | ||
59 | related information. | ||
60 | The ARAM node must be placed under the DSP node. | ||
61 | |||
62 | Required properties: | ||
63 | |||
64 | - compatible : should be "nintendo,flipper-aram" | ||
65 | - reg : should contain the ARAM start (zero-based) and length | ||
66 | |||
67 | 1.d) The Disk Interface (DI) node | ||
68 | |||
69 | Represents the interface used to communicate with mass storage devices. | ||
70 | |||
71 | Required properties: | ||
72 | |||
73 | - compatible : should be "nintendo,flipper-di" | ||
74 | - reg : should contain the DI registers location and length | ||
75 | - interrupts : should contain the DI interrupt | ||
76 | |||
77 | 1.e) The Audio Interface (AI) node | ||
78 | |||
79 | Represents the interface to the external 16-bit stereo digital-to-analog | ||
80 | converter. | ||
81 | |||
82 | Required properties: | ||
83 | |||
84 | - compatible : should be "nintendo,flipper-ai" | ||
85 | - reg : should contain the AI registers location and length | ||
86 | - interrupts : should contain the AI interrupt | ||
87 | |||
88 | 1.f) The Serial Interface (SI) node | ||
89 | |||
90 | Represents the interface to the four single bit serial interfaces. | ||
91 | The SI is a proprietary serial interface used normally to control gamepads. | ||
92 | It's NOT a RS232-type interface. | ||
93 | |||
94 | Required properties: | ||
95 | |||
96 | - compatible : should be "nintendo,flipper-si" | ||
97 | - reg : should contain the SI registers location and length | ||
98 | - interrupts : should contain the SI interrupt | ||
99 | |||
100 | 1.g) The External Interface (EXI) node | ||
101 | |||
102 | Represents the multi-channel SPI-like interface. | ||
103 | |||
104 | Required properties: | ||
105 | |||
106 | - compatible : should be "nintendo,flipper-exi" | ||
107 | - reg : should contain the EXI registers location and length | ||
108 | - interrupts : should contain the EXI interrupt | ||
109 | |||
diff --git a/Documentation/powerpc/dts-bindings/nintendo/wii.txt b/Documentation/powerpc/dts-bindings/nintendo/wii.txt new file mode 100644 index 000000000000..a7e155a023b8 --- /dev/null +++ b/Documentation/powerpc/dts-bindings/nintendo/wii.txt | |||
@@ -0,0 +1,184 @@ | |||
1 | |||
2 | Nintendo Wii device tree | ||
3 | ======================== | ||
4 | |||
5 | 0) The root node | ||
6 | |||
7 | This node represents the Nintendo Wii video game console. | ||
8 | |||
9 | Required properties: | ||
10 | |||
11 | - model : Should be "nintendo,wii" | ||
12 | - compatible : Should be "nintendo,wii" | ||
13 | |||
14 | 1) The "hollywood" node | ||
15 | |||
16 | This node represents the multi-function "Hollywood" chip, which packages | ||
17 | many of the devices found in the Nintendo Wii. | ||
18 | |||
19 | Required properties: | ||
20 | |||
21 | - compatible : Should be "nintendo,hollywood" | ||
22 | |||
23 | 1.a) The Video Interface (VI) node | ||
24 | |||
25 | Represents the interface between the graphics processor and a external | ||
26 | video encoder. | ||
27 | |||
28 | Required properties: | ||
29 | |||
30 | - compatible : should be "nintendo,hollywood-vi","nintendo,flipper-vi" | ||
31 | - reg : should contain the VI registers location and length | ||
32 | - interrupts : should contain the VI interrupt | ||
33 | |||
34 | 1.b) The Processor Interface (PI) node | ||
35 | |||
36 | Represents the data and control interface between the main processor | ||
37 | and graphics and audio processor. | ||
38 | |||
39 | Required properties: | ||
40 | |||
41 | - compatible : should be "nintendo,hollywood-pi","nintendo,flipper-pi" | ||
42 | - reg : should contain the PI registers location and length | ||
43 | |||
44 | 1.b.i) The "Flipper" interrupt controller node | ||
45 | |||
46 | Represents the "Flipper" interrupt controller within the "Hollywood" chip. | ||
47 | The node for the "Flipper" interrupt controller must be placed under | ||
48 | the PI node. | ||
49 | |||
50 | Required properties: | ||
51 | |||
52 | - #interrupt-cells : <1> | ||
53 | - compatible : should be "nintendo,flipper-pic" | ||
54 | - interrupt-controller | ||
55 | |||
56 | 1.c) The Digital Signal Procesor (DSP) node | ||
57 | |||
58 | Represents the digital signal processor interface, designed to offload | ||
59 | audio related tasks. | ||
60 | |||
61 | Required properties: | ||
62 | |||
63 | - compatible : should be "nintendo,hollywood-dsp","nintendo,flipper-dsp" | ||
64 | - reg : should contain the DSP registers location and length | ||
65 | - interrupts : should contain the DSP interrupt | ||
66 | |||
67 | 1.d) The Serial Interface (SI) node | ||
68 | |||
69 | Represents the interface to the four single bit serial interfaces. | ||
70 | The SI is a proprietary serial interface used normally to control gamepads. | ||
71 | It's NOT a RS232-type interface. | ||
72 | |||
73 | Required properties: | ||
74 | |||
75 | - compatible : should be "nintendo,hollywood-si","nintendo,flipper-si" | ||
76 | - reg : should contain the SI registers location and length | ||
77 | - interrupts : should contain the SI interrupt | ||
78 | |||
79 | 1.e) The Audio Interface (AI) node | ||
80 | |||
81 | Represents the interface to the external 16-bit stereo digital-to-analog | ||
82 | converter. | ||
83 | |||
84 | Required properties: | ||
85 | |||
86 | - compatible : should be "nintendo,hollywood-ai","nintendo,flipper-ai" | ||
87 | - reg : should contain the AI registers location and length | ||
88 | - interrupts : should contain the AI interrupt | ||
89 | |||
90 | 1.f) The External Interface (EXI) node | ||
91 | |||
92 | Represents the multi-channel SPI-like interface. | ||
93 | |||
94 | Required properties: | ||
95 | |||
96 | - compatible : should be "nintendo,hollywood-exi","nintendo,flipper-exi" | ||
97 | - reg : should contain the EXI registers location and length | ||
98 | - interrupts : should contain the EXI interrupt | ||
99 | |||
100 | 1.g) The Open Host Controller Interface (OHCI) nodes | ||
101 | |||
102 | Represent the USB 1.x Open Host Controller Interfaces. | ||
103 | |||
104 | Required properties: | ||
105 | |||
106 | - compatible : should be "nintendo,hollywood-usb-ohci","usb-ohci" | ||
107 | - reg : should contain the OHCI registers location and length | ||
108 | - interrupts : should contain the OHCI interrupt | ||
109 | |||
110 | 1.h) The Enhanced Host Controller Interface (EHCI) node | ||
111 | |||
112 | Represents the USB 2.0 Enhanced Host Controller Interface. | ||
113 | |||
114 | Required properties: | ||
115 | |||
116 | - compatible : should be "nintendo,hollywood-usb-ehci","usb-ehci" | ||
117 | - reg : should contain the EHCI registers location and length | ||
118 | - interrupts : should contain the EHCI interrupt | ||
119 | |||
120 | 1.i) The Secure Digital Host Controller Interface (SDHCI) nodes | ||
121 | |||
122 | Represent the Secure Digital Host Controller Interfaces. | ||
123 | |||
124 | Required properties: | ||
125 | |||
126 | - compatible : should be "nintendo,hollywood-sdhci","sdhci" | ||
127 | - reg : should contain the SDHCI registers location and length | ||
128 | - interrupts : should contain the SDHCI interrupt | ||
129 | |||
130 | 1.j) The Inter-Processsor Communication (IPC) node | ||
131 | |||
132 | Represent the Inter-Processor Communication interface. This interface | ||
133 | enables communications between the Broadway and the Starlet processors. | ||
134 | |||
135 | - compatible : should be "nintendo,hollywood-ipc" | ||
136 | - reg : should contain the IPC registers location and length | ||
137 | - interrupts : should contain the IPC interrupt | ||
138 | |||
139 | 1.k) The "Hollywood" interrupt controller node | ||
140 | |||
141 | Represents the "Hollywood" interrupt controller within the | ||
142 | "Hollywood" chip. | ||
143 | |||
144 | Required properties: | ||
145 | |||
146 | - #interrupt-cells : <1> | ||
147 | - compatible : should be "nintendo,hollywood-pic" | ||
148 | - reg : should contain the controller registers location and length | ||
149 | - interrupt-controller | ||
150 | - interrupts : should contain the cascade interrupt of the "flipper" pic | ||
151 | - interrupt-parent: should contain the phandle of the "flipper" pic | ||
152 | |||
153 | 1.l) The General Purpose I/O (GPIO) controller node | ||
154 | |||
155 | Represents the dual access 32 GPIO controller interface. | ||
156 | |||
157 | Required properties: | ||
158 | |||
159 | - #gpio-cells : <2> | ||
160 | - compatible : should be "nintendo,hollywood-gpio" | ||
161 | - reg : should contain the IPC registers location and length | ||
162 | - gpio-controller | ||
163 | |||
164 | 1.m) The control node | ||
165 | |||
166 | Represents the control interface used to setup several miscellaneous | ||
167 | settings of the "Hollywood" chip like boot memory mappings, resets, | ||
168 | disk interface mode, etc. | ||
169 | |||
170 | Required properties: | ||
171 | |||
172 | - compatible : should be "nintendo,hollywood-control" | ||
173 | - reg : should contain the control registers location and length | ||
174 | |||
175 | 1.n) The Disk Interface (DI) node | ||
176 | |||
177 | Represents the interface used to communicate with mass storage devices. | ||
178 | |||
179 | Required properties: | ||
180 | |||
181 | - compatible : should be "nintendo,hollywood-di" | ||
182 | - reg : should contain the DI registers location and length | ||
183 | - interrupts : should contain the DI interrupt | ||
184 | |||
diff --git a/Documentation/spinlocks.txt b/Documentation/spinlocks.txt index 619699dde593..178c831b907d 100644 --- a/Documentation/spinlocks.txt +++ b/Documentation/spinlocks.txt | |||
@@ -1,73 +1,8 @@ | |||
1 | SPIN_LOCK_UNLOCKED and RW_LOCK_UNLOCKED defeat lockdep state tracking and | 1 | Lesson 1: Spin locks |
2 | are hence deprecated. | ||
3 | 2 | ||
4 | Please use DEFINE_SPINLOCK()/DEFINE_RWLOCK() or | 3 | The most basic primitive for locking is spinlock. |
5 | __SPIN_LOCK_UNLOCKED()/__RW_LOCK_UNLOCKED() as appropriate for static | ||
6 | initialization. | ||
7 | |||
8 | Most of the time, you can simply turn: | ||
9 | |||
10 | static spinlock_t xxx_lock = SPIN_LOCK_UNLOCKED; | ||
11 | |||
12 | into: | ||
13 | |||
14 | static DEFINE_SPINLOCK(xxx_lock); | ||
15 | |||
16 | Static structure member variables go from: | ||
17 | |||
18 | struct foo bar { | ||
19 | .lock = SPIN_LOCK_UNLOCKED; | ||
20 | }; | ||
21 | |||
22 | to: | ||
23 | |||
24 | struct foo bar { | ||
25 | .lock = __SPIN_LOCK_UNLOCKED(bar.lock); | ||
26 | }; | ||
27 | |||
28 | Declaration of static rw_locks undergo a similar transformation. | ||
29 | |||
30 | Dynamic initialization, when necessary, may be performed as | ||
31 | demonstrated below. | ||
32 | |||
33 | spinlock_t xxx_lock; | ||
34 | rwlock_t xxx_rw_lock; | ||
35 | |||
36 | static int __init xxx_init(void) | ||
37 | { | ||
38 | spin_lock_init(&xxx_lock); | ||
39 | rwlock_init(&xxx_rw_lock); | ||
40 | ... | ||
41 | } | ||
42 | |||
43 | module_init(xxx_init); | ||
44 | |||
45 | The following discussion is still valid, however, with the dynamic | ||
46 | initialization of spinlocks or with DEFINE_SPINLOCK, etc., used | ||
47 | instead of SPIN_LOCK_UNLOCKED. | ||
48 | |||
49 | ----------------------- | ||
50 | |||
51 | On Fri, 2 Jan 1998, Doug Ledford wrote: | ||
52 | > | ||
53 | > I'm working on making the aic7xxx driver more SMP friendly (as well as | ||
54 | > importing the latest FreeBSD sequencer code to have 7895 support) and wanted | ||
55 | > to get some info from you. The goal here is to make the various routines | ||
56 | > SMP safe as well as UP safe during interrupts and other manipulating | ||
57 | > routines. So far, I've added a spin_lock variable to things like my queue | ||
58 | > structs. Now, from what I recall, there are some spin lock functions I can | ||
59 | > use to lock these spin locks from other use as opposed to a (nasty) | ||
60 | > save_flags(); cli(); stuff; restore_flags(); construct. Where do I find | ||
61 | > these routines and go about making use of them? Do they only lock on a | ||
62 | > per-processor basis or can they also lock say an interrupt routine from | ||
63 | > mucking with a queue if the queue routine was manipulating it when the | ||
64 | > interrupt occurred, or should I still use a cli(); based construct on that | ||
65 | > one? | ||
66 | |||
67 | See <asm/spinlock.h>. The basic version is: | ||
68 | |||
69 | spinlock_t xxx_lock = SPIN_LOCK_UNLOCKED; | ||
70 | 4 | ||
5 | static DEFINE_SPINLOCK(xxx_lock); | ||
71 | 6 | ||
72 | unsigned long flags; | 7 | unsigned long flags; |
73 | 8 | ||
@@ -75,13 +10,11 @@ See <asm/spinlock.h>. The basic version is: | |||
75 | ... critical section here .. | 10 | ... critical section here .. |
76 | spin_unlock_irqrestore(&xxx_lock, flags); | 11 | spin_unlock_irqrestore(&xxx_lock, flags); |
77 | 12 | ||
78 | and the above is always safe. It will disable interrupts _locally_, but the | 13 | The above is always safe. It will disable interrupts _locally_, but the |
79 | spinlock itself will guarantee the global lock, so it will guarantee that | 14 | spinlock itself will guarantee the global lock, so it will guarantee that |
80 | there is only one thread-of-control within the region(s) protected by that | 15 | there is only one thread-of-control within the region(s) protected by that |
81 | lock. | 16 | lock. This works well even under UP. The above sequence under UP |
82 | 17 | essentially is just the same as doing | |
83 | Note that it works well even under UP - the above sequence under UP | ||
84 | essentially is just the same as doing a | ||
85 | 18 | ||
86 | unsigned long flags; | 19 | unsigned long flags; |
87 | 20 | ||
@@ -91,15 +24,13 @@ essentially is just the same as doing a | |||
91 | 24 | ||
92 | so the code does _not_ need to worry about UP vs SMP issues: the spinlocks | 25 | so the code does _not_ need to worry about UP vs SMP issues: the spinlocks |
93 | work correctly under both (and spinlocks are actually more efficient on | 26 | work correctly under both (and spinlocks are actually more efficient on |
94 | architectures that allow doing the "save_flags + cli" in one go because I | 27 | architectures that allow doing the "save_flags + cli" in one operation). |
95 | don't export that interface normally). | 28 | |
29 | NOTE! Implications of spin_locks for memory are further described in: | ||
96 | 30 | ||
97 | NOTE NOTE NOTE! The reason the spinlock is so much faster than a global | 31 | Documentation/memory-barriers.txt |
98 | interrupt lock under SMP is exactly because it disables interrupts only on | 32 | (5) LOCK operations. |
99 | the local CPU. The spin-lock is safe only when you _also_ use the lock | 33 | (6) UNLOCK operations. |
100 | itself to do locking across CPU's, which implies that EVERYTHING that | ||
101 | touches a shared variable has to agree about the spinlock they want to | ||
102 | use. | ||
103 | 34 | ||
104 | The above is usually pretty simple (you usually need and want only one | 35 | The above is usually pretty simple (you usually need and want only one |
105 | spinlock for most things - using more than one spinlock can make things a | 36 | spinlock for most things - using more than one spinlock can make things a |
@@ -120,20 +51,24 @@ and another sequence that does | |||
120 | then they are NOT mutually exclusive, and the critical regions can happen | 51 | then they are NOT mutually exclusive, and the critical regions can happen |
121 | at the same time on two different CPU's. That's fine per se, but the | 52 | at the same time on two different CPU's. That's fine per se, but the |
122 | critical regions had better be critical for different things (ie they | 53 | critical regions had better be critical for different things (ie they |
123 | can't stomp on each other). | 54 | can't stomp on each other). |
124 | 55 | ||
125 | The above is a problem mainly if you end up mixing code - for example the | 56 | The above is a problem mainly if you end up mixing code - for example the |
126 | routines in ll_rw_block() tend to use cli/sti to protect the atomicity of | 57 | routines in ll_rw_block() tend to use cli/sti to protect the atomicity of |
127 | their actions, and if a driver uses spinlocks instead then you should | 58 | their actions, and if a driver uses spinlocks instead then you should |
128 | think about issues like the above.. | 59 | think about issues like the above. |
129 | 60 | ||
130 | This is really the only really hard part about spinlocks: once you start | 61 | This is really the only really hard part about spinlocks: once you start |
131 | using spinlocks they tend to expand to areas you might not have noticed | 62 | using spinlocks they tend to expand to areas you might not have noticed |
132 | before, because you have to make sure the spinlocks correctly protect the | 63 | before, because you have to make sure the spinlocks correctly protect the |
133 | shared data structures _everywhere_ they are used. The spinlocks are most | 64 | shared data structures _everywhere_ they are used. The spinlocks are most |
134 | easily added to places that are completely independent of other code (ie | 65 | easily added to places that are completely independent of other code (for |
135 | internal driver data structures that nobody else ever touches, for | 66 | example, internal driver data structures that nobody else ever touches). |
136 | example). | 67 | |
68 | NOTE! The spin-lock is safe only when you _also_ use the lock itself | ||
69 | to do locking across CPU's, which implies that EVERYTHING that | ||
70 | touches a shared variable has to agree about the spinlock they want | ||
71 | to use. | ||
137 | 72 | ||
138 | ---- | 73 | ---- |
139 | 74 | ||
@@ -141,13 +76,17 @@ Lesson 2: reader-writer spinlocks. | |||
141 | 76 | ||
142 | If your data accesses have a very natural pattern where you usually tend | 77 | If your data accesses have a very natural pattern where you usually tend |
143 | to mostly read from the shared variables, the reader-writer locks | 78 | to mostly read from the shared variables, the reader-writer locks |
144 | (rw_lock) versions of the spinlocks are often nicer. They allow multiple | 79 | (rw_lock) versions of the spinlocks are sometimes useful. They allow multiple |
145 | readers to be in the same critical region at once, but if somebody wants | 80 | readers to be in the same critical region at once, but if somebody wants |
146 | to change the variables it has to get an exclusive write lock. The | 81 | to change the variables it has to get an exclusive write lock. |
147 | routines look the same as above: | ||
148 | 82 | ||
149 | rwlock_t xxx_lock = RW_LOCK_UNLOCKED; | 83 | NOTE! reader-writer locks require more atomic memory operations than |
84 | simple spinlocks. Unless the reader critical section is long, you | ||
85 | are better off just using spinlocks. | ||
150 | 86 | ||
87 | The routines look the same as above: | ||
88 | |||
89 | rwlock_t xxx_lock = RW_LOCK_UNLOCKED; | ||
151 | 90 | ||
152 | unsigned long flags; | 91 | unsigned long flags; |
153 | 92 | ||
@@ -159,18 +98,21 @@ routines look the same as above: | |||
159 | .. read and write exclusive access to the info ... | 98 | .. read and write exclusive access to the info ... |
160 | write_unlock_irqrestore(&xxx_lock, flags); | 99 | write_unlock_irqrestore(&xxx_lock, flags); |
161 | 100 | ||
162 | The above kind of lock is useful for complex data structures like linked | 101 | The above kind of lock may be useful for complex data structures like |
163 | lists etc, especially when you know that most of the work is to just | 102 | linked lists, especially searching for entries without changing the list |
164 | traverse the list searching for entries without changing the list itself, | 103 | itself. The read lock allows many concurrent readers. Anything that |
165 | for example. Then you can use the read lock for that kind of list | 104 | _changes_ the list will have to get the write lock. |
166 | traversal, which allows many concurrent readers. Anything that _changes_ | 105 | |
167 | the list will have to get the write lock. | 106 | NOTE! RCU is better for list traversal, but requires careful |
107 | attention to design detail (see Documentation/RCU/listRCU.txt). | ||
168 | 108 | ||
169 | Note: you cannot "upgrade" a read-lock to a write-lock, so if you at _any_ | 109 | Also, you cannot "upgrade" a read-lock to a write-lock, so if you at _any_ |
170 | time need to do any changes (even if you don't do it every time), you have | 110 | time need to do any changes (even if you don't do it every time), you have |
171 | to get the write-lock at the very beginning. I could fairly easily add a | 111 | to get the write-lock at the very beginning. |
172 | primitive to create a "upgradeable" read-lock, but it hasn't been an issue | 112 | |
173 | yet. Tell me if you'd want one. | 113 | NOTE! We are working hard to remove reader-writer spinlocks in most |
114 | cases, so please don't add a new one without consensus. (Instead, see | ||
115 | Documentation/RCU/rcu.txt for complete information.) | ||
174 | 116 | ||
175 | ---- | 117 | ---- |
176 | 118 | ||
@@ -233,4 +175,46 @@ indeed), while write-locks need to protect themselves against interrupts. | |||
233 | 175 | ||
234 | Linus | 176 | Linus |
235 | 177 | ||
178 | ---- | ||
179 | |||
180 | Reference information: | ||
181 | |||
182 | For dynamic initialization, use spin_lock_init() or rwlock_init() as | ||
183 | appropriate: | ||
184 | |||
185 | spinlock_t xxx_lock; | ||
186 | rwlock_t xxx_rw_lock; | ||
187 | |||
188 | static int __init xxx_init(void) | ||
189 | { | ||
190 | spin_lock_init(&xxx_lock); | ||
191 | rwlock_init(&xxx_rw_lock); | ||
192 | ... | ||
193 | } | ||
194 | |||
195 | module_init(xxx_init); | ||
196 | |||
197 | For static initialization, use DEFINE_SPINLOCK() / DEFINE_RWLOCK() or | ||
198 | __SPIN_LOCK_UNLOCKED() / __RW_LOCK_UNLOCKED() as appropriate. | ||
199 | |||
200 | SPIN_LOCK_UNLOCKED and RW_LOCK_UNLOCKED are deprecated. These interfere | ||
201 | with lockdep state tracking. | ||
202 | |||
203 | Most of the time, you can simply turn: | ||
204 | static spinlock_t xxx_lock = SPIN_LOCK_UNLOCKED; | ||
205 | into: | ||
206 | static DEFINE_SPINLOCK(xxx_lock); | ||
207 | |||
208 | Static structure member variables go from: | ||
209 | |||
210 | struct foo bar { | ||
211 | .lock = SPIN_LOCK_UNLOCKED; | ||
212 | }; | ||
213 | |||
214 | to: | ||
236 | 215 | ||
216 | struct foo bar { | ||
217 | .lock = __SPIN_LOCK_UNLOCKED(bar.lock); | ||
218 | }; | ||
219 | |||
220 | Declaration of static rw_locks undergo a similar transformation. | ||
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index 8f7a0e73ef44..3894eaa23486 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt | |||
@@ -19,6 +19,8 @@ Currently, these files might (depending on your configuration) | |||
19 | show up in /proc/sys/kernel: | 19 | show up in /proc/sys/kernel: |
20 | - acpi_video_flags | 20 | - acpi_video_flags |
21 | - acct | 21 | - acct |
22 | - bootloader_type [ X86 only ] | ||
23 | - bootloader_version [ X86 only ] | ||
22 | - callhome [ S390 only ] | 24 | - callhome [ S390 only ] |
23 | - auto_msgmni | 25 | - auto_msgmni |
24 | - core_pattern | 26 | - core_pattern |
@@ -93,6 +95,35 @@ valid for 30 seconds. | |||
93 | 95 | ||
94 | ============================================================== | 96 | ============================================================== |
95 | 97 | ||
98 | bootloader_type: | ||
99 | |||
100 | x86 bootloader identification | ||
101 | |||
102 | This gives the bootloader type number as indicated by the bootloader, | ||
103 | shifted left by 4, and OR'd with the low four bits of the bootloader | ||
104 | version. The reason for this encoding is that this used to match the | ||
105 | type_of_loader field in the kernel header; the encoding is kept for | ||
106 | backwards compatibility. That is, if the full bootloader type number | ||
107 | is 0x15 and the full version number is 0x234, this file will contain | ||
108 | the value 340 = 0x154. | ||
109 | |||
110 | See the type_of_loader and ext_loader_type fields in | ||
111 | Documentation/x86/boot.txt for additional information. | ||
112 | |||
113 | ============================================================== | ||
114 | |||
115 | bootloader_version: | ||
116 | |||
117 | x86 bootloader version | ||
118 | |||
119 | The complete bootloader version number. In the example above, this | ||
120 | file will contain the value 564 = 0x234. | ||
121 | |||
122 | See the type_of_loader and ext_loader_ver fields in | ||
123 | Documentation/x86/boot.txt for additional information. | ||
124 | |||
125 | ============================================================== | ||
126 | |||
96 | callhome: | 127 | callhome: |
97 | 128 | ||
98 | Controls the kernel's callhome behavior in case of a kernel panic. | 129 | Controls the kernel's callhome behavior in case of a kernel panic. |
diff --git a/Documentation/thermal/sysfs-api.txt b/Documentation/thermal/sysfs-api.txt index a87dc277a5ca..cb3d15bc1aeb 100644 --- a/Documentation/thermal/sysfs-api.txt +++ b/Documentation/thermal/sysfs-api.txt | |||
@@ -206,6 +206,7 @@ passive | |||
206 | passive trip point for the zone. Activation is done by polling with | 206 | passive trip point for the zone. Activation is done by polling with |
207 | an interval of 1 second. | 207 | an interval of 1 second. |
208 | Unit: millidegrees Celsius | 208 | Unit: millidegrees Celsius |
209 | Valid values: 0 (disabled) or greater than 1000 | ||
209 | RW, Optional | 210 | RW, Optional |
210 | 211 | ||
211 | ***************************** | 212 | ***************************** |
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/hwpoison.txt b/Documentation/vm/hwpoison.txt index 3ffadf8da61f..12f9ba20ccb7 100644 --- a/Documentation/vm/hwpoison.txt +++ b/Documentation/vm/hwpoison.txt | |||
@@ -92,16 +92,62 @@ PR_MCE_KILL_GET | |||
92 | 92 | ||
93 | Testing: | 93 | Testing: |
94 | 94 | ||
95 | madvise(MADV_POISON, ....) | 95 | madvise(MADV_HWPOISON, ....) |
96 | (as root) | 96 | (as root) |
97 | Poison a page in the process for testing | 97 | Poison a page in the process for testing |
98 | 98 | ||
99 | 99 | ||
100 | hwpoison-inject module through debugfs | 100 | hwpoison-inject module through debugfs |
101 | /sys/debug/hwpoison/corrupt-pfn | ||
102 | 101 | ||
103 | Inject hwpoison fault at PFN echoed into this file | 102 | /sys/debug/hwpoison/ |
104 | 103 | ||
104 | corrupt-pfn | ||
105 | |||
106 | Inject hwpoison fault at PFN echoed into this file. This does | ||
107 | some early filtering to avoid corrupted unintended pages in test suites. | ||
108 | |||
109 | unpoison-pfn | ||
110 | |||
111 | Software-unpoison page at PFN echoed into this file. This | ||
112 | way a page can be reused again. | ||
113 | This only works for Linux injected failures, not for real | ||
114 | memory failures. | ||
115 | |||
116 | Note these injection interfaces are not stable and might change between | ||
117 | kernel versions | ||
118 | |||
119 | corrupt-filter-dev-major | ||
120 | corrupt-filter-dev-minor | ||
121 | |||
122 | Only handle memory failures to pages associated with the file system defined | ||
123 | by block device major/minor. -1U is the wildcard value. | ||
124 | This should be only used for testing with artificial injection. | ||
125 | |||
126 | corrupt-filter-memcg | ||
127 | |||
128 | Limit injection to pages owned by memgroup. Specified by inode number | ||
129 | of the memcg. | ||
130 | |||
131 | Example: | ||
132 | mkdir /cgroup/hwpoison | ||
133 | |||
134 | usemem -m 100 -s 1000 & | ||
135 | echo `jobs -p` > /cgroup/hwpoison/tasks | ||
136 | |||
137 | memcg_ino=$(ls -id /cgroup/hwpoison | cut -f1 -d' ') | ||
138 | echo $memcg_ino > /debug/hwpoison/corrupt-filter-memcg | ||
139 | |||
140 | page-types -p `pidof init` --hwpoison # shall do nothing | ||
141 | page-types -p `pidof usemem` --hwpoison # poison its pages | ||
142 | |||
143 | corrupt-filter-flags-mask | ||
144 | corrupt-filter-flags-value | ||
145 | |||
146 | When specified, only poison pages if ((page_flags & mask) == value). | ||
147 | This allows stress testing of many kinds of pages. The page_flags | ||
148 | are the same as in /proc/kpageflags. The flag bits are defined in | ||
149 | include/linux/kernel-page-flags.h and documented in | ||
150 | Documentation/vm/pagemap.txt | ||
105 | 151 | ||
106 | Architecture specific MCE injector | 152 | Architecture specific MCE injector |
107 | 153 | ||
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..66e9358e2144 100644 --- a/Documentation/vm/page-types.c +++ b/Documentation/vm/page-types.c | |||
@@ -1,11 +1,22 @@ | |||
1 | /* | 1 | /* |
2 | * page-types: Tool for querying page flags | 2 | * page-types: Tool for querying page flags |
3 | * | 3 | * |
4 | * This program is free software; you can redistribute it and/or modify it | ||
5 | * under the terms of the GNU General Public License as published by the Free | ||
6 | * Software Foundation; version 2. | ||
7 | * | ||
8 | * This program is distributed in the hope that it will be useful, but WITHOUT | ||
9 | * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or | ||
10 | * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for | ||
11 | * more details. | ||
12 | * | ||
13 | * You should find a copy of v2 of the GNU General Public License somewhere on | ||
14 | * your Linux system; if not, write to the Free Software Foundation, Inc., 59 | ||
15 | * Temple Place, Suite 330, Boston, MA 02111-1307 USA. | ||
16 | * | ||
4 | * Copyright (C) 2009 Intel corporation | 17 | * Copyright (C) 2009 Intel corporation |
5 | * | 18 | * |
6 | * Authors: Wu Fengguang <fengguang.wu@intel.com> | 19 | * Authors: Wu Fengguang <fengguang.wu@intel.com> |
7 | * | ||
8 | * Released under the General Public License (GPL). | ||
9 | */ | 20 | */ |
10 | 21 | ||
11 | #define _LARGEFILE64_SOURCE | 22 | #define _LARGEFILE64_SOURCE |
@@ -100,7 +111,7 @@ | |||
100 | #define BIT(name) (1ULL << KPF_##name) | 111 | #define BIT(name) (1ULL << KPF_##name) |
101 | #define BITS_COMPOUND (BIT(COMPOUND_HEAD) | BIT(COMPOUND_TAIL)) | 112 | #define BITS_COMPOUND (BIT(COMPOUND_HEAD) | BIT(COMPOUND_TAIL)) |
102 | 113 | ||
103 | static char *page_flag_names[] = { | 114 | static const char *page_flag_names[] = { |
104 | [KPF_LOCKED] = "L:locked", | 115 | [KPF_LOCKED] = "L:locked", |
105 | [KPF_ERROR] = "E:error", | 116 | [KPF_ERROR] = "E:error", |
106 | [KPF_REFERENCED] = "R:referenced", | 117 | [KPF_REFERENCED] = "R:referenced", |
@@ -173,7 +184,7 @@ static int kpageflags_fd; | |||
173 | static int opt_hwpoison; | 184 | static int opt_hwpoison; |
174 | static int opt_unpoison; | 185 | static int opt_unpoison; |
175 | 186 | ||
176 | static char *hwpoison_debug_fs = "/debug/hwpoison"; | 187 | static const char hwpoison_debug_fs[] = "/debug/hwpoison"; |
177 | static int hwpoison_inject_fd; | 188 | static int hwpoison_inject_fd; |
178 | static int hwpoison_forget_fd; | 189 | static int hwpoison_forget_fd; |
179 | 190 | ||
@@ -560,7 +571,7 @@ static void walk_pfn(unsigned long voffset, | |||
560 | { | 571 | { |
561 | uint64_t buf[KPAGEFLAGS_BATCH]; | 572 | uint64_t buf[KPAGEFLAGS_BATCH]; |
562 | unsigned long batch; | 573 | unsigned long batch; |
563 | unsigned long pages; | 574 | long pages; |
564 | unsigned long i; | 575 | unsigned long i; |
565 | 576 | ||
566 | while (count) { | 577 | while (count) { |
@@ -673,30 +684,35 @@ static void usage(void) | |||
673 | 684 | ||
674 | printf( | 685 | printf( |
675 | "page-types [options]\n" | 686 | "page-types [options]\n" |
676 | " -r|--raw Raw mode, for kernel developers\n" | 687 | " -r|--raw Raw mode, for kernel developers\n" |
677 | " -a|--addr addr-spec Walk a range of pages\n" | 688 | " -d|--describe flags Describe flags\n" |
678 | " -b|--bits bits-spec Walk pages with specified bits\n" | 689 | " -a|--addr addr-spec Walk a range of pages\n" |
679 | " -p|--pid pid Walk process address space\n" | 690 | " -b|--bits bits-spec Walk pages with specified bits\n" |
691 | " -p|--pid pid Walk process address space\n" | ||
680 | #if 0 /* planned features */ | 692 | #if 0 /* planned features */ |
681 | " -f|--file filename Walk file address space\n" | 693 | " -f|--file filename Walk file address space\n" |
682 | #endif | 694 | #endif |
683 | " -l|--list Show page details in ranges\n" | 695 | " -l|--list Show page details in ranges\n" |
684 | " -L|--list-each Show page details one by one\n" | 696 | " -L|--list-each Show page details one by one\n" |
685 | " -N|--no-summary Don't show summay info\n" | 697 | " -N|--no-summary Don't show summay info\n" |
686 | " -X|--hwpoison hwpoison pages\n" | 698 | " -X|--hwpoison hwpoison pages\n" |
687 | " -x|--unpoison unpoison pages\n" | 699 | " -x|--unpoison unpoison pages\n" |
688 | " -h|--help Show this usage message\n" | 700 | " -h|--help Show this usage message\n" |
701 | "flags:\n" | ||
702 | " 0x10 bitfield format, e.g.\n" | ||
703 | " anon bit-name, e.g.\n" | ||
704 | " 0x10,anon comma-separated list, e.g.\n" | ||
689 | "addr-spec:\n" | 705 | "addr-spec:\n" |
690 | " N one page at offset N (unit: pages)\n" | 706 | " N one page at offset N (unit: pages)\n" |
691 | " N+M pages range from N to N+M-1\n" | 707 | " N+M pages range from N to N+M-1\n" |
692 | " N,M pages range from N to M-1\n" | 708 | " N,M pages range from N to M-1\n" |
693 | " N, pages range from N to end\n" | 709 | " N, pages range from N to end\n" |
694 | " ,M pages range from 0 to M-1\n" | 710 | " ,M pages range from 0 to M-1\n" |
695 | "bits-spec:\n" | 711 | "bits-spec:\n" |
696 | " bit1,bit2 (flags & (bit1|bit2)) != 0\n" | 712 | " bit1,bit2 (flags & (bit1|bit2)) != 0\n" |
697 | " bit1,bit2=bit1 (flags & (bit1|bit2)) == bit1\n" | 713 | " bit1,bit2=bit1 (flags & (bit1|bit2)) == bit1\n" |
698 | " bit1,~bit2 (flags & (bit1|bit2)) == bit1\n" | 714 | " bit1,~bit2 (flags & (bit1|bit2)) == bit1\n" |
699 | " =bit1,bit2 flags == (bit1|bit2)\n" | 715 | " =bit1,bit2 flags == (bit1|bit2)\n" |
700 | "bit-names:\n" | 716 | "bit-names:\n" |
701 | ); | 717 | ); |
702 | 718 | ||
@@ -884,13 +900,23 @@ static void parse_bits_mask(const char *optarg) | |||
884 | add_bits_filter(mask, bits); | 900 | add_bits_filter(mask, bits); |
885 | } | 901 | } |
886 | 902 | ||
903 | static void describe_flags(const char *optarg) | ||
904 | { | ||
905 | uint64_t flags = parse_flag_names(optarg, 0); | ||
906 | |||
907 | printf("0x%016llx\t%s\t%s\n", | ||
908 | (unsigned long long)flags, | ||
909 | page_flag_name(flags), | ||
910 | page_flag_longname(flags)); | ||
911 | } | ||
887 | 912 | ||
888 | static struct option opts[] = { | 913 | static const struct option opts[] = { |
889 | { "raw" , 0, NULL, 'r' }, | 914 | { "raw" , 0, NULL, 'r' }, |
890 | { "pid" , 1, NULL, 'p' }, | 915 | { "pid" , 1, NULL, 'p' }, |
891 | { "file" , 1, NULL, 'f' }, | 916 | { "file" , 1, NULL, 'f' }, |
892 | { "addr" , 1, NULL, 'a' }, | 917 | { "addr" , 1, NULL, 'a' }, |
893 | { "bits" , 1, NULL, 'b' }, | 918 | { "bits" , 1, NULL, 'b' }, |
919 | { "describe" , 1, NULL, 'd' }, | ||
894 | { "list" , 0, NULL, 'l' }, | 920 | { "list" , 0, NULL, 'l' }, |
895 | { "list-each" , 0, NULL, 'L' }, | 921 | { "list-each" , 0, NULL, 'L' }, |
896 | { "no-summary", 0, NULL, 'N' }, | 922 | { "no-summary", 0, NULL, 'N' }, |
@@ -907,7 +933,7 @@ int main(int argc, char *argv[]) | |||
907 | page_size = getpagesize(); | 933 | page_size = getpagesize(); |
908 | 934 | ||
909 | while ((c = getopt_long(argc, argv, | 935 | while ((c = getopt_long(argc, argv, |
910 | "rp:f:a:b:lLNXxh", opts, NULL)) != -1) { | 936 | "rp:f:a:b:d:lLNXxh", opts, NULL)) != -1) { |
911 | switch (c) { | 937 | switch (c) { |
912 | case 'r': | 938 | case 'r': |
913 | opt_raw = 1; | 939 | opt_raw = 1; |
@@ -924,6 +950,9 @@ int main(int argc, char *argv[]) | |||
924 | case 'b': | 950 | case 'b': |
925 | parse_bits_mask(optarg); | 951 | parse_bits_mask(optarg); |
926 | break; | 952 | break; |
953 | case 'd': | ||
954 | describe_flags(optarg); | ||
955 | exit(0); | ||
927 | case 'l': | 956 | case 'l': |
928 | opt_list = 1; | 957 | opt_list = 1; |
929 | break; | 958 | break; |