diff options
| author | Marcelo Tosatti <mtosatti@redhat.com> | 2012-10-29 19:15:32 -0200 |
|---|---|---|
| committer | Marcelo Tosatti <mtosatti@redhat.com> | 2012-10-29 19:15:32 -0200 |
| commit | 19bf7f8ac3f8131100027281c495dbbe00cd5ae0 (patch) | |
| tree | 270b97e3ca47c0f62a1babca2ae37f79a76a309c /Documentation | |
| parent | 787c57c0fb393fe8a3974d300ddcfe30373386fe (diff) | |
| parent | 35fd3dc58da675d659513384221349ef90749a01 (diff) | |
| download | linux-19bf7f8ac3f8131100027281c495dbbe00cd5ae0.tar.bz2 | |
Merge remote-tracking branch 'master' into queue
Merge reason: development work has dependency on kvm patches merged
upstream.
Conflicts:
arch/powerpc/include/asm/Kbuild
arch/powerpc/include/asm/kvm_para.h
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Diffstat (limited to 'Documentation')
190 files changed, 6509 insertions, 1117 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 49c051380daf..ceb1ff735469 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -210,6 +210,8 @@ local_ops.txt - semantics and behavior of local atomic operations. lockdep-design.txt - documentation on the runtime locking correctness validator. +lockup-watchdogs.txt + - info on soft and hard lockup detectors (aka nmi_watchdog). logo.gif - full colour GIF image of Linux logo (penguin - Tux). logo.txt @@ -240,8 +242,6 @@ netlabel/ - directory with information on the NetLabel subsystem. networking/ - directory with info on various aspects of networking with Linux. -nmi_watchdog.txt - - info on NMI watchdog for SMP systems. nommu-mmap.txt - documentation about no-mmu memory mapping support. numastat.txt @@ -270,8 +270,6 @@ preempt-locking.txt - info on locking under a preemptive kernel. printk-formats.txt - how to get printk format specifiers right -prio_tree.txt - - info on radix-priority-search-tree use for indexing vmas. ramoops.txt - documentation of the ramoops oops/panic logging module. rbtree.txt diff --git a/Documentation/ABI/obsolete/proc-pid-oom_adj b/Documentation/ABI/obsolete/proc-pid-oom_adj deleted file mode 100644 index 9a3cb88ade47..000000000000 --- a/Documentation/ABI/obsolete/proc-pid-oom_adj +++ /dev/null @@ -1,22 +0,0 @@ -What: /proc/<pid>/oom_adj -When: August 2012 -Why: /proc/<pid>/oom_adj allows userspace to influence the oom killer's - badness heuristic used to determine which task to kill when the kernel - is out of memory. - - The badness heuristic has since been rewritten since the introduction of - this tunable such that its meaning is deprecated. The value was - implemented as a bitshift on a score generated by the badness() - function that did not have any precise units of measure. With the - rewrite, the score is given as a proportion of available memory to the - task allocating pages, so using a bitshift which grows the score - exponentially is, thus, impossible to tune with fine granularity. - - A much more powerful interface, /proc/<pid>/oom_score_adj, was - introduced with the oom killer rewrite that allows users to increase or - decrease the badness score linearly. This interface will replace - /proc/<pid>/oom_adj. - - A warning will be emitted to the kernel log if an application uses this - deprecated interface. After it is printed once, future warnings will be - suppressed until the kernel is rebooted. diff --git a/Documentation/ABI/testing/sysfs-block b/Documentation/ABI/testing/sysfs-block index c1eb41cb9876..279da08f7541 100644 --- a/Documentation/ABI/testing/sysfs-block +++ b/Documentation/ABI/testing/sysfs-block @@ -206,3 +206,17 @@ Description: when a discarded area is read the discard_zeroes_data parameter will be set to one. Otherwise it will be 0 and the result of reading a discarded area is undefined. + +What: /sys/block/<disk>/queue/write_same_max_bytes +Date: January 2012 +Contact: Martin K. Petersen <martin.petersen@oracle.com> +Description: + Some devices support a write same operation in which a + single data block can be written to a range of several + contiguous blocks on storage. This can be used to wipe + areas on disk or to initialize drives in a RAID + configuration. write_same_max_bytes indicates how many + bytes can be written in a single write same command. If + write_same_max_bytes is 0, write same is not supported + by the device. + diff --git a/Documentation/ABI/testing/sysfs-bus-fcoe b/Documentation/ABI/testing/sysfs-bus-fcoe index 469d09c02f6b..50e2a80ea28f 100644 --- a/Documentation/ABI/testing/sysfs-bus-fcoe +++ b/Documentation/ABI/testing/sysfs-bus-fcoe @@ -9,19 +9,19 @@ Attributes: this value will change the dev_loss_tmo for all FCFs discovered by this controller. - lesb_link_fail: Link Error Status Block (LESB) link failure count. + lesb/link_fail: Link Error Status Block (LESB) link failure count. - lesb_vlink_fail: Link Error Status Block (LESB) virtual link + lesb/vlink_fail: Link Error Status Block (LESB) virtual link failure count. - lesb_miss_fka: Link Error Status Block (LESB) missed FCoE + lesb/miss_fka: Link Error Status Block (LESB) missed FCoE Initialization Protocol (FIP) Keep-Alives (FKA). - lesb_symb_err: Link Error Status Block (LESB) symbolic error count. + lesb/symb_err: Link Error Status Block (LESB) symbolic error count. - lesb_err_block: Link Error Status Block (LESB) block error count. + lesb/err_block: Link Error Status Block (LESB) block error count. - lesb_fcs_error: Link Error Status Block (LESB) Fibre Channel + lesb/fcs_error: Link Error Status Block (LESB) Fibre Channel Serivces error count. Notes: ctlr_X (global increment starting at 0) diff --git a/Documentation/ABI/testing/sysfs-bus-rbd b/Documentation/ABI/testing/sysfs-bus-rbd index 3c17b62899f6..1cf2adf46b11 100644 --- a/Documentation/ABI/testing/sysfs-bus-rbd +++ b/Documentation/ABI/testing/sysfs-bus-rbd @@ -25,6 +25,10 @@ client_id The ceph unique client id that was assigned for this specific session. +features + + A hexadecimal encoding of the feature bits for this image. + major The block device major number. @@ -33,6 +37,11 @@ name The name of the rbd image. +image_id + + The unique id for the rbd image. (For rbd image format 1 + this is empty.) + pool The name of the storage pool where this rbd image resides. @@ -57,12 +66,6 @@ current_snap The current snapshot for which the device is mapped. -create_snap - - Create a snapshot: - - $ echo <snap-name> > /sys/bus/rbd/devices/<dev-id>/snap_create - snap_* A directory per each snapshot @@ -79,4 +82,7 @@ snap_size The size of the image when this snapshot was taken. +snap_features + + A hexadecimal encoding of the feature bits for this snapshot. diff --git a/Documentation/ABI/testing/sysfs-devices-firmware_node b/Documentation/ABI/testing/sysfs-devices-firmware_node new file mode 100644 index 000000000000..46badc9ea284 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-firmware_node @@ -0,0 +1,17 @@ +What: /sys/devices/.../firmware_node/ +Date: September 2012 +Contact: <> +Description: + The /sys/devices/.../firmware_node directory contains attributes + allowing the user space to check and modify some firmware + related properties of given device. + +What: /sys/devices/.../firmware_node/description +Date: September 2012 +Contact: Lance Ortiz <lance.ortiz@hp.com> +Description: + The /sys/devices/.../firmware/description attribute contains a string + that describes the device as provided by the _STR method in the ACPI + namespace. This attribute is read-only. If the device does not have + an _STR method associated with it in the ACPI namespace, this + attribute is not present. diff --git a/Documentation/ABI/testing/sysfs-fs-ext4 b/Documentation/ABI/testing/sysfs-fs-ext4 index f22ac0872ae8..c631253cf85c 100644 --- a/Documentation/ABI/testing/sysfs-fs-ext4 +++ b/Documentation/ABI/testing/sysfs-fs-ext4 @@ -96,3 +96,16 @@ Contact: "Theodore Ts'o" <tytso@mit.edu> Description: The maximum number of megabytes the writeback code will try to write out before move on to another inode. + +What: /sys/fs/ext4/<disk>/extent_max_zeroout_kb +Date: August 2012 +Contact: "Theodore Ts'o" <tytso@mit.edu> +Description: + The maximum number of kilobytes which will be zeroed + out in preference to creating a new uninitialized + extent when manipulating an inode's extent tree. Note + that using a larger value will increase the + variability of time necessary to complete a random + write operation (since a 4k random write might turn + into a much larger write due to the zeroout + operation). diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index cb9258b8fd35..495e5ba1634c 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -454,6 +454,16 @@ The preferred style for long (multi-line) comments is: * with beginning and ending almost-blank lines. */ +For files in net/ and drivers/net/ the preferred style for long (multi-line) +comments is a little different. + + /* The preferred comment style for files in net/ and drivers/net + * looks like this. + * + * It is nearly the same as the generally preferred comment style, + * but there is no initial almost-blank line. + */ + It's also important to comment data, whether they are basic types or derived types. To this end, use just one data declaration per line (no commas for multiple data declarations). This leaves you room for a small comment on each diff --git a/Documentation/DocBook/media/Makefile b/Documentation/DocBook/media/Makefile index 362520992ced..f9fd615427fb 100644 --- a/Documentation/DocBook/media/Makefile +++ b/Documentation/DocBook/media/Makefile @@ -56,15 +56,15 @@ FUNCS = \ write \ IOCTLS = \ - $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/linux/videodev2.h) \ - $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/linux/dvb/audio.h) \ - $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/linux/dvb/ca.h) \ - $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/linux/dvb/dmx.h) \ - $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/linux/dvb/frontend.h) \ - $(shell perl -ne 'print "$$1 " if /\#define\s+([A-Z][^\s]+)\s+_IO/' $(srctree)/include/linux/dvb/net.h) \ - $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/linux/dvb/video.h) \ - $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/linux/media.h) \ - $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/linux/v4l2-subdev.h) \ + $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/videodev2.h) \ + $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/dvb/audio.h) \ + $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/dvb/ca.h) \ + $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/dvb/dmx.h) \ + $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/dvb/frontend.h) \ + $(shell perl -ne 'print "$$1 " if /\#define\s+([A-Z][^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/dvb/net.h) \ + $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/dvb/video.h) \ + $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/media.h) \ + $(shell perl -ne 'print "$$1 " if /\#define\s+([^\s]+)\s+_IO/' $(srctree)/include/uapi/linux/v4l2-subdev.h) \ VIDIOC_SUBDEV_G_FRAME_INTERVAL \ VIDIOC_SUBDEV_S_FRAME_INTERVAL \ VIDIOC_SUBDEV_ENUM_MBUS_CODE \ @@ -74,32 +74,32 @@ IOCTLS = \ VIDIOC_SUBDEV_S_SELECTION \ TYPES = \ - $(shell perl -ne 'print "$$1 " if /^typedef\s+[^\s]+\s+([^\s]+)\;/' $(srctree)/include/linux/videodev2.h) \ - $(shell perl -ne 'print "$$1 " if /^}\s+([a-z0-9_]+_t)/' $(srctree)/include/linux/dvb/frontend.h) + $(shell perl -ne 'print "$$1 " if /^typedef\s+[^\s]+\s+([^\s]+)\;/' $(srctree)/include/uapi/linux/videodev2.h) \ + $(shell perl -ne 'print "$$1 " if /^}\s+([a-z0-9_]+_t)/' $(srctree)/include/uapi/linux/dvb/frontend.h) ENUMS = \ - $(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/linux/videodev2.h) \ - $(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/linux/dvb/audio.h) \ - $(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/linux/dvb/ca.h) \ - $(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/linux/dvb/dmx.h) \ - $(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/linux/dvb/frontend.h) \ - $(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/linux/dvb/net.h) \ - $(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/linux/dvb/video.h) \ - $(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/linux/media.h) \ - $(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/linux/v4l2-mediabus.h) \ - $(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/linux/v4l2-subdev.h) + $(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/videodev2.h) \ + $(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/dvb/audio.h) \ + $(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/dvb/ca.h) \ + $(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/dvb/dmx.h) \ + $(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/dvb/frontend.h) \ + $(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/dvb/net.h) \ + $(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/dvb/video.h) \ + $(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/media.h) \ + $(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/v4l2-mediabus.h) \ + $(shell perl -ne 'print "$$1 " if /^enum\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/v4l2-subdev.h) STRUCTS = \ - $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/linux/videodev2.h) \ - $(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s\{]+)\s*/)' $(srctree)/include/linux/dvb/audio.h) \ - $(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/)' $(srctree)/include/linux/dvb/ca.h) \ - $(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/)' $(srctree)/include/linux/dvb/dmx.h) \ - $(shell perl -ne 'print "$$1 " if (!/dtv\_cmds\_h/ && /^struct\s+([^\s]+)\s+/)' $(srctree)/include/linux/dvb/frontend.h) \ - $(shell perl -ne 'print "$$1 " if (/^struct\s+([A-Z][^\s]+)\s+/)' $(srctree)/include/linux/dvb/net.h) \ - $(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/)' $(srctree)/include/linux/dvb/video.h) \ - $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/linux/media.h) \ - $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/linux/v4l2-subdev.h) \ - $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/linux/v4l2-mediabus.h) + $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/videodev2.h) \ + $(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s\{]+)\s*/)' $(srctree)/include/uapi/linux/dvb/audio.h) \ + $(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/)' $(srctree)/include/uapi/linux/dvb/ca.h) \ + $(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/)' $(srctree)/include/uapi/linux/dvb/dmx.h) \ + $(shell perl -ne 'print "$$1 " if (!/dtv\_cmds\_h/ && /^struct\s+([^\s]+)\s+/)' $(srctree)/include/uapi/linux/dvb/frontend.h) \ + $(shell perl -ne 'print "$$1 " if (/^struct\s+([A-Z][^\s]+)\s+/)' $(srctree)/include/uapi/linux/dvb/net.h) \ + $(shell perl -ne 'print "$$1 " if (/^struct\s+([^\s]+)\s+/)' $(srctree)/include/uapi/linux/dvb/video.h) \ + $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/media.h) \ + $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/v4l2-subdev.h) \ + $(shell perl -ne 'print "$$1 " if /^struct\s+([^\s]+)\s+/' $(srctree)/include/uapi/linux/v4l2-mediabus.h) ERRORS = \ E2BIG \ @@ -205,7 +205,7 @@ $(MEDIA_OBJ_DIR)/v4l2.xml: $(OBJIMGFILES) @(ln -sf $(MEDIA_SRC_DIR)/v4l/*xml $(MEDIA_OBJ_DIR)/) @(ln -sf $(MEDIA_SRC_DIR)/dvb/*xml $(MEDIA_OBJ_DIR)/) -$(MEDIA_OBJ_DIR)/videodev2.h.xml: $(srctree)/include/linux/videodev2.h $(MEDIA_OBJ_DIR)/v4l2.xml +$(MEDIA_OBJ_DIR)/videodev2.h.xml: $(srctree)/include/uapi/linux/videodev2.h $(MEDIA_OBJ_DIR)/v4l2.xml @$($(quiet)gen_xml) @( \ echo "<programlisting>") > $@ @@ -216,7 +216,7 @@ $(MEDIA_OBJ_DIR)/videodev2.h.xml: $(srctree)/include/linux/videodev2.h $(MEDIA_O @( \ echo "</programlisting>") >> $@ -$(MEDIA_OBJ_DIR)/audio.h.xml: $(srctree)/include/linux/dvb/audio.h $(MEDIA_OBJ_DIR)/v4l2.xml +$(MEDIA_OBJ_DIR)/audio.h.xml: $(srctree)/include/uapi/linux/dvb/audio.h $(MEDIA_OBJ_DIR)/v4l2.xml @$($(quiet)gen_xml) @( \ echo "<programlisting>") > $@ @@ -227,7 +227,7 @@ $(MEDIA_OBJ_DIR)/audio.h.xml: $(srctree)/include/linux/dvb/audio.h $(MEDIA_OBJ_D @( \ echo "</programlisting>") >> $@ -$(MEDIA_OBJ_DIR)/ca.h.xml: $(srctree)/include/linux/dvb/ca.h $(MEDIA_OBJ_DIR)/v4l2.xml +$(MEDIA_OBJ_DIR)/ca.h.xml: $(srctree)/include/uapi/linux/dvb/ca.h $(MEDIA_OBJ_DIR)/v4l2.xml @$($(quiet)gen_xml) @( \ echo "<programlisting>") > $@ @@ -238,7 +238,7 @@ $(MEDIA_OBJ_DIR)/ca.h.xml: $(srctree)/include/linux/dvb/ca.h $(MEDIA_OBJ_DIR)/v4 @( \ echo "</programlisting>") >> $@ -$(MEDIA_OBJ_DIR)/dmx.h.xml: $(srctree)/include/linux/dvb/dmx.h $(MEDIA_OBJ_DIR)/v4l2.xml +$(MEDIA_OBJ_DIR)/dmx.h.xml: $(srctree)/include/uapi/linux/dvb/dmx.h $(MEDIA_OBJ_DIR)/v4l2.xml @$($(quiet)gen_xml) @( \ echo "<programlisting>") > $@ @@ -249,7 +249,7 @@ $(MEDIA_OBJ_DIR)/dmx.h.xml: $(srctree)/include/linux/dvb/dmx.h $(MEDIA_OBJ_DIR)/ @( \ echo "</programlisting>") >> $@ -$(MEDIA_OBJ_DIR)/frontend.h.xml: $(srctree)/include/linux/dvb/frontend.h $(MEDIA_OBJ_DIR)/v4l2.xml +$(MEDIA_OBJ_DIR)/frontend.h.xml: $(srctree)/include/uapi/linux/dvb/frontend.h $(MEDIA_OBJ_DIR)/v4l2.xml @$($(quiet)gen_xml) @( \ echo "<programlisting>") > $@ @@ -260,7 +260,7 @@ $(MEDIA_OBJ_DIR)/frontend.h.xml: $(srctree)/include/linux/dvb/frontend.h $(MEDIA @( \ echo "</programlisting>") >> $@ -$(MEDIA_OBJ_DIR)/net.h.xml: $(srctree)/include/linux/dvb/net.h $(MEDIA_OBJ_DIR)/v4l2.xml +$(MEDIA_OBJ_DIR)/net.h.xml: $(srctree)/include/uapi/linux/dvb/net.h $(MEDIA_OBJ_DIR)/v4l2.xml @$($(quiet)gen_xml) @( \ echo "<programlisting>") > $@ @@ -271,7 +271,7 @@ $(MEDIA_OBJ_DIR)/net.h.xml: $(srctree)/include/linux/dvb/net.h $(MEDIA_OBJ_DIR)/ @( \ echo "</programlisting>") >> $@ -$(MEDIA_OBJ_DIR)/video.h.xml: $(srctree)/include/linux/dvb/video.h $(MEDIA_OBJ_DIR)/v4l2.xml +$(MEDIA_OBJ_DIR)/video.h.xml: $(srctree)/include/uapi/linux/dvb/video.h $(MEDIA_OBJ_DIR)/v4l2.xml @$($(quiet)gen_xml) @( \ echo "<programlisting>") > $@ @@ -300,7 +300,7 @@ $(MEDIA_OBJ_DIR)/media-entities.tmpl: $(MEDIA_OBJ_DIR)/v4l2.xml @( \ for ident in $(IOCTLS) ; do \ entity=`echo $$ident | tr _ -` ; \ - id=`grep "<refname>$$ident" $(MEDIA_OBJ_DIR)/vidioc-*.xml | sed -r s,"^.*/(.*).xml.*","\1",` ; \ + id=`grep "<refname>$$ident" $(MEDIA_OBJ_DIR)/vidioc-*.xml $(MEDIA_OBJ_DIR)/media-ioc-*.xml | sed -r s,"^.*/(.*).xml.*","\1",` ; \ echo "<!ENTITY $$entity \"<link" \ "linkend='$$id'><constant>$$ident</constant></link>\">" \ >>$@ ; \ diff --git a/Documentation/DocBook/media/dvb/audio.xml b/Documentation/DocBook/media/dvb/audio.xml index d64386237207..a7ea56c71a27 100644 --- a/Documentation/DocBook/media/dvb/audio.xml +++ b/Documentation/DocBook/media/dvb/audio.xml @@ -1,12 +1,16 @@ <title>DVB Audio Device</title> <para>The DVB audio device controls the MPEG2 audio decoder of the DVB hardware. It can be accessed through <emphasis role="tt">/dev/dvb/adapter0/audio0</emphasis>. Data types and and -ioctl definitions can be accessed by including <emphasis role="tt">linux/dvb/video.h</emphasis> in your +ioctl definitions can be accessed by including <emphasis role="tt">linux/dvb/audio.h</emphasis> in your application. </para> <para>Please note that some DVB cards don’t have their own MPEG decoder, which results in the omission of the audio and video device. </para> +<para> +These ioctls were also used by V4L2 to control MPEG decoders implemented in V4L2. The use +of these ioctls for that purpose has been made obsolete and proper V4L2 ioctls or controls +have been created to replace that functionality.</para> <section id="audio_data_types"> <title>Audio Data Types</title> @@ -558,6 +562,8 @@ role="subsection"><title>AUDIO_SELECT_SOURCE</title> role="subsection"><title>AUDIO_SET_MUTE</title> <para>DESCRIPTION </para> +<para>This ioctl is for DVB devices only. To control a V4L2 decoder use the V4L2 +&VIDIOC-DECODER-CMD; with the <constant>V4L2_DEC_CMD_START_MUTE_AUDIO</constant> flag instead.</para> <informaltable><tgroup cols="1"><tbody><row><entry align="char"> <para>This ioctl call asks the audio device to mute the stream that is currently being @@ -730,6 +736,8 @@ role="subsection"><title>AUDIO_SET_BYPASS_MODE</title> role="subsection"><title>AUDIO_CHANNEL_SELECT</title> <para>DESCRIPTION </para> +<para>This ioctl is for DVB devices only. To control a V4L2 decoder use the V4L2 +<constant>V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK</constant> control instead.</para> <informaltable><tgroup cols="1"><tbody><row><entry align="char"> <para>This ioctl call asks the Audio Device to select the requested channel if possible.</para> @@ -772,6 +780,109 @@ role="subsection"><title>AUDIO_CHANNEL_SELECT</title> </row></tbody></tgroup></informaltable> &return-value-dvb; +</section><section id="AUDIO_BILINGUAL_CHANNEL_SELECT" +role="subsection"><title>AUDIO_BILINGUAL_CHANNEL_SELECT</title> +<para>DESCRIPTION +</para> +<para>This ioctl is obsolete. Do not use in new drivers. It has been replaced by +the V4L2 <constant>V4L2_CID_MPEG_AUDIO_DEC_MULTILINGUAL_PLAYBACK</constant> control +for MPEG decoders controlled through V4L2.</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call asks the Audio Device to select the requested channel for bilingual streams if possible.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = + AUDIO_BILINGUAL_CHANNEL_SELECT, audio_channel_select_t);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals AUDIO_BILINGUAL_CHANNEL_SELECT for this + command.</para> +</entry> + </row><row><entry + align="char"> +<para>audio_channel_select_t +ch</para> +</entry><entry + align="char"> +<para>Select the output format of the audio (mono left/right, + stereo).</para> +</entry> + </row> +</tbody></tgroup></informaltable> +&return-value-dvb; + +</section><section id="AUDIO_GET_PTS" +role="subsection"><title>AUDIO_GET_PTS</title> +<para>DESCRIPTION +</para> +<para>This ioctl is obsolete. Do not use in new drivers. If you need this functionality, +then please contact the linux-media mailing list (&v4l-ml;).</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call asks the Audio Device to return the current PTS timestamp.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = + AUDIO_GET_PTS, __u64 *pts);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals AUDIO_GET_PTS for this + command.</para> +</entry> + </row><row><entry + align="char"> +<para>__u64 *pts +</para> +</entry><entry + align="char"> +<para>Returns the 33-bit timestamp as defined in ITU T-REC-H.222.0 / ISO/IEC 13818-1. +</para> +<para> +The PTS should belong to the currently played +frame if possible, but may also be a value close to it +like the PTS of the last decoded frame or the last PTS +extracted by the PES parser.</para> +</entry> + </row></tbody></tgroup></informaltable> +&return-value-dvb; + </section><section id="AUDIO_GET_STATUS" role="subsection"><title>AUDIO_GET_STATUS</title> <para>DESCRIPTION diff --git a/Documentation/DocBook/media/dvb/ca.xml b/Documentation/DocBook/media/dvb/ca.xml index 5c4adb44b1c1..85eaf4fe2931 100644 --- a/Documentation/DocBook/media/dvb/ca.xml +++ b/Documentation/DocBook/media/dvb/ca.xml @@ -226,4 +226,357 @@ typedef struct ca_pid { </entry> </row></tbody></tgroup></informaltable> </section> + +<section id="CA_RESET" +role="subsection"><title>CA_RESET</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl is undocumented. Documentation is welcome.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(fd, int request = CA_RESET); +</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals CA_RESET for this command.</para> +</entry> + </row></tbody></tgroup></informaltable> +&return-value-dvb; +</section> + +<section id="CA_GET_CAP" +role="subsection"><title>CA_GET_CAP</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl is undocumented. Documentation is welcome.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(fd, int request = CA_GET_CAP, + ca_caps_t *);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals CA_GET_CAP for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>ca_caps_t * +</para> +</entry><entry + align="char"> +<para>Undocumented.</para> +</entry> + </row></tbody></tgroup></informaltable> +&return-value-dvb; +</section> + +<section id="CA_GET_SLOT_INFO" +role="subsection"><title>CA_GET_SLOT_INFO</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl is undocumented. Documentation is welcome.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(fd, int request = CA_GET_SLOT_INFO, + ca_slot_info_t *);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals CA_GET_SLOT_INFO for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>ca_slot_info_t * +</para> +</entry><entry + align="char"> +<para>Undocumented.</para> +</entry> + </row></tbody></tgroup></informaltable> +&return-value-dvb; +</section> + +<section id="CA_GET_DESCR_INFO" +role="subsection"><title>CA_GET_DESCR_INFO</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl is undocumented. Documentation is welcome.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(fd, int request = CA_GET_DESCR_INFO, + ca_descr_info_t *);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals CA_GET_DESCR_INFO for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>ca_descr_info_t * +</para> +</entry><entry + align="char"> +<para>Undocumented.</para> +</entry> + </row></tbody></tgroup></informaltable> +&return-value-dvb; +</section> + +<section id="CA_GET_MSG" +role="subsection"><title>CA_GET_MSG</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl is undocumented. Documentation is welcome.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(fd, int request = CA_GET_MSG, + ca_msg_t *);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals CA_GET_MSG for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>ca_msg_t * +</para> +</entry><entry + align="char"> +<para>Undocumented.</para> +</entry> + </row></tbody></tgroup></informaltable> +&return-value-dvb; +</section> + +<section id="CA_SEND_MSG" +role="subsection"><title>CA_SEND_MSG</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl is undocumented. Documentation is welcome.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(fd, int request = CA_SEND_MSG, + ca_msg_t *);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals CA_SEND_MSG for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>ca_msg_t * +</para> +</entry><entry + align="char"> +<para>Undocumented.</para> +</entry> + </row></tbody></tgroup></informaltable> +&return-value-dvb; +</section> + +<section id="CA_SET_DESCR" +role="subsection"><title>CA_SET_DESCR</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl is undocumented. Documentation is welcome.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(fd, int request = CA_SET_DESCR, + ca_descr_t *);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals CA_SET_DESCR for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>ca_descr_t * +</para> +</entry><entry + align="char"> +<para>Undocumented.</para> +</entry> + </row></tbody></tgroup></informaltable> +&return-value-dvb; +</section> + +<section id="CA_SET_PID" +role="subsection"><title>CA_SET_PID</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl is undocumented. Documentation is welcome.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(fd, int request = CA_SET_PID, + ca_pid_t *);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals CA_SET_PID for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>ca_pid_t * +</para> +</entry><entry + align="char"> +<para>Undocumented.</para> +</entry> + </row></tbody></tgroup></informaltable> +&return-value-dvb; +</section> + </section> diff --git a/Documentation/DocBook/media/dvb/demux.xml b/Documentation/DocBook/media/dvb/demux.xml index 37c17908aa40..86de89cfbd67 100644 --- a/Documentation/DocBook/media/dvb/demux.xml +++ b/Documentation/DocBook/media/dvb/demux.xml @@ -899,4 +899,232 @@ typedef enum { <para>Invalid stc number.</para> </entry> </row></tbody></tgroup></informaltable> - </section></section> + </section> + +<section id="DMX_GET_PES_PIDS" +role="subsection"><title>DMX_GET_PES_PIDS</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl is undocumented. Documentation is welcome.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(fd, int request = DMX_GET_PES_PIDS, + __u16[5]);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals DMX_GET_PES_PIDS for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>__u16[5] +</para> +</entry><entry + align="char"> +<para>Undocumented.</para> +</entry> + </row></tbody></tgroup></informaltable> +&return-value-dvb; +</section> + +<section id="DMX_GET_CAPS" +role="subsection"><title>DMX_GET_CAPS</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl is undocumented. Documentation is welcome.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(fd, int request = DMX_GET_CAPS, + dmx_caps_t *);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals DMX_GET_CAPS for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>dmx_caps_t * +</para> +</entry><entry + align="char"> +<para>Undocumented.</para> +</entry> + </row></tbody></tgroup></informaltable> +&return-value-dvb; +</section> + +<section id="DMX_SET_SOURCE" +role="subsection"><title>DMX_SET_SOURCE</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl is undocumented. Documentation is welcome.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(fd, int request = DMX_SET_SOURCE, + dmx_source_t *);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals DMX_SET_SOURCE for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>dmx_source_t * +</para> +</entry><entry + align="char"> +<para>Undocumented.</para> +</entry> + </row></tbody></tgroup></informaltable> +&return-value-dvb; +</section> + +<section id="DMX_ADD_PID" +role="subsection"><title>DMX_ADD_PID</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl is undocumented. Documentation is welcome.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(fd, int request = DMX_ADD_PID, + __u16 *);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals DMX_ADD_PID for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>__u16 * +</para> +</entry><entry + align="char"> +<para>Undocumented.</para> +</entry> + </row></tbody></tgroup></informaltable> +&return-value-dvb; +</section> + +<section id="DMX_REMOVE_PID" +role="subsection"><title>DMX_REMOVE_PID</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl is undocumented. Documentation is welcome.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(fd, int request = DMX_REMOVE_PID, + __u16 *);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals DMX_REMOVE_PID for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>__u16 * +</para> +</entry><entry + align="char"> +<para>Undocumented.</para> +</entry> + </row></tbody></tgroup></informaltable> +&return-value-dvb; +</section> + + +</section> diff --git a/Documentation/DocBook/media/dvb/dvbapi.xml b/Documentation/DocBook/media/dvb/dvbapi.xml index 2ab6ddcfc4e0..757488b24f4f 100644 --- a/Documentation/DocBook/media/dvb/dvbapi.xml +++ b/Documentation/DocBook/media/dvb/dvbapi.xml @@ -28,7 +28,7 @@ <holder>Convergence GmbH</holder> </copyright> <copyright> - <year>2009-2011</year> + <year>2009-2012</year> <holder>Mauro Carvalho Chehab</holder> </copyright> @@ -84,7 +84,7 @@ Added ISDB-T test originally written by Patrick Boettcher <title>LINUX DVB API</title> -<subtitle>Version 5.2</subtitle> +<subtitle>Version 5.8</subtitle> <!-- ADD THE CHAPTERS HERE --> <chapter id="dvb_introdution"> &sub-intro; diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml b/Documentation/DocBook/media/dvb/dvbproperty.xml index e633c097a8d1..957e3acaae8e 100644 --- a/Documentation/DocBook/media/dvb/dvbproperty.xml +++ b/Documentation/DocBook/media/dvb/dvbproperty.xml @@ -194,6 +194,7 @@ get/set up to 64 properties. The actual meaning of each property is described on APSK_16, APSK_32, DQPSK, + QAM_4_NR, } fe_modulation_t; </programlisting> </section> @@ -265,6 +266,7 @@ typedef enum fe_code_rate { FEC_AUTO, FEC_3_5, FEC_9_10, + FEC_2_5, } fe_code_rate_t; </programlisting> <para>which correspond to error correction rates of 1/2, 2/3, etc., @@ -351,7 +353,7 @@ typedef enum fe_delivery_system { SYS_ISDBC, SYS_ATSC, SYS_ATSCMH, - SYS_DMBTH, + SYS_DTMB, SYS_CMMB, SYS_DAB, SYS_DVBT2, @@ -567,28 +569,33 @@ typedef enum fe_delivery_system { <title><constant>DTV_ATSCMH_RS_FRAME_MODE</constant></title> <para>RS frame mode.</para> <para>Possible values are:</para> + <para id="atscmh-rs-frame-mode"> <programlisting> typedef enum atscmh_rs_frame_mode { ATSCMH_RSFRAME_PRI_ONLY = 0, ATSCMH_RSFRAME_PRI_SEC = 1, } atscmh_rs_frame_mode_t; </programlisting> + </para> </section> <section id="DTV-ATSCMH-RS-FRAME-ENSEMBLE"> <title><constant>DTV_ATSCMH_RS_FRAME_ENSEMBLE</constant></title> <para>RS frame ensemble.</para> <para>Possible values are:</para> + <para id="atscmh-rs-frame-ensemble"> <programlisting> typedef enum atscmh_rs_frame_ensemble { ATSCMH_RSFRAME_ENS_PRI = 0, ATSCMH_RSFRAME_ENS_SEC = 1, } atscmh_rs_frame_ensemble_t; </programlisting> + </para> </section> <section id="DTV-ATSCMH-RS-CODE-MODE-PRI"> <title><constant>DTV_ATSCMH_RS_CODE_MODE_PRI</constant></title> <para>RS code mode (primary).</para> <para>Possible values are:</para> + <para id="atscmh-rs-code-mode"> <programlisting> typedef enum atscmh_rs_code_mode { ATSCMH_RSCODE_211_187 = 0, @@ -596,6 +603,7 @@ typedef enum atscmh_rs_code_mode { ATSCMH_RSCODE_235_187 = 2, } atscmh_rs_code_mode_t; </programlisting> + </para> </section> <section id="DTV-ATSCMH-RS-CODE-MODE-SEC"> <title><constant>DTV_ATSCMH_RS_CODE_MODE_SEC</constant></title> @@ -613,23 +621,27 @@ typedef enum atscmh_rs_code_mode { <title><constant>DTV_ATSCMH_SCCC_BLOCK_MODE</constant></title> <para>Series Concatenated Convolutional Code Block Mode.</para> <para>Possible values are:</para> + <para id="atscmh-sccc-block-mode"> <programlisting> typedef enum atscmh_sccc_block_mode { ATSCMH_SCCC_BLK_SEP = 0, ATSCMH_SCCC_BLK_COMB = 1, } atscmh_sccc_block_mode_t; </programlisting> + </para> </section> <section id="DTV-ATSCMH-SCCC-CODE-MODE-A"> <title><constant>DTV_ATSCMH_SCCC_CODE_MODE_A</constant></title> <para>Series Concatenated Convolutional Code Rate.</para> <para>Possible values are:</para> + <para id="atscmh-sccc-code-mode"> <programlisting> typedef enum atscmh_sccc_code_mode { ATSCMH_SCCC_CODE_HLF = 0, ATSCMH_SCCC_CODE_QTR = 1, } atscmh_sccc_code_mode_t; </programlisting> + </para> </section> <section id="DTV-ATSCMH-SCCC-CODE-MODE-B"> <title><constant>DTV_ATSCMH_SCCC_CODE_MODE_B</constant></title> @@ -725,6 +737,9 @@ typedef enum fe_guard_interval { GUARD_INTERVAL_1_128, GUARD_INTERVAL_19_128, GUARD_INTERVAL_19_256, + GUARD_INTERVAL_PN420, + GUARD_INTERVAL_PN595, + GUARD_INTERVAL_PN945, } fe_guard_interval_t; </programlisting> @@ -733,6 +748,7 @@ typedef enum fe_guard_interval { try to find the correct guard interval (if capable) and will use TMCC to fill in the missing parameters.</para> <para>2) Intervals 1/128, 19/128 and 19/256 are used only for DVB-T2 at present</para> + <para>3) DTMB specifies PN420, PN595 and PN945.</para> </section> <section id="DTV-TRANSMISSION-MODE"> <title><constant>DTV_TRANSMISSION_MODE</constant></title> @@ -749,6 +765,8 @@ typedef enum fe_transmit_mode { TRANSMISSION_MODE_1K, TRANSMISSION_MODE_16K, TRANSMISSION_MODE_32K, + TRANSMISSION_MODE_C1, + TRANSMISSION_MODE_C3780, } fe_transmit_mode_t; </programlisting> <para>Notes:</para> @@ -760,6 +778,7 @@ typedef enum fe_transmit_mode { use TMCC to fill in the missing parameters.</para> <para>3) DVB-T specifies 2K and 8K as valid sizes.</para> <para>4) DVB-T2 specifies 1K, 2K, 4K, 8K, 16K and 32K.</para> + <para>5) DTMB specifies C1 and C3780.</para> </section> <section id="DTV-HIERARCHY"> <title><constant>DTV_HIERARCHY</constant></title> @@ -774,17 +793,28 @@ typedef enum fe_hierarchy { } fe_hierarchy_t; </programlisting> </section> - <section id="DTV-ISDBS-TS-ID"> - <title><constant>DTV_ISDBS_TS_ID</constant></title> - <para>Currently unused.</para> + <section id="DTV-STREAM-ID"> + <title><constant>DTV_STREAM_ID</constant></title> + <para>DVB-S2, DVB-T2 and ISDB-S support the transmission of several + streams on a single transport stream. + This property enables the DVB driver to handle substream filtering, + when supported by the hardware. + By default, substream filtering is disabled. + </para><para> + For DVB-S2 and DVB-T2, the valid substream id range is from 0 to 255. + </para><para> + For ISDB, the valid substream id range is from 1 to 65535. + </para><para> + To disable it, you should use the special macro NO_STREAM_ID_FILTER. + </para><para> + Note: any value outside the id range also disables filtering. + </para> </section> - <section id="DTV-DVBT2-PLP-ID"> - <title><constant>DTV_DVBT2_PLP_ID</constant></title> - <para>DVB-T2 supports Physical Layer Pipes (PLP) to allow transmission of - many data types via a single multiplex. The API will soon support this - at which point this section will be expanded.</para> + <section id="DTV-DVBT2-PLP-ID-LEGACY"> + <title><constant>DTV_DVBT2_PLP_ID_LEGACY</constant></title> + <para>Obsolete, replaced with DTV_STREAM_ID.</para> </section> - <section id="DTV_ENUM_DELSYS"> + <section id="DTV-ENUM-DELSYS"> <title><constant>DTV_ENUM_DELSYS</constant></title> <para>A Multi standard frontend needs to advertise the delivery systems provided. Applications need to enumerate the provided delivery systems, before using @@ -796,6 +826,29 @@ typedef enum fe_hierarchy { FE_GET_INFO. In the case of a legacy frontend, the result is just the same as with FE_GET_INFO, but in a more structured format </para> </section> + <section id="DTV-INTERLEAVING"> + <title><constant>DTV_INTERLEAVING</constant></title> + <para id="fe-interleaving">Interleaving mode</para> + <programlisting> +enum fe_interleaving { + INTERLEAVING_NONE, + INTERLEAVING_AUTO, + INTERLEAVING_240, + INTERLEAVING_720, +}; + </programlisting> + </section> + <section id="DTV-LNA"> + <title><constant>DTV_LNA</constant></title> + <para>Low-noise amplifier.</para> + <para>Hardware might offer controllable LNA which can be set manually + using that parameter. Usually LNA could be found only from + terrestrial devices if at all.</para> + <para>Possible values: 0, 1, LNA_AUTO</para> + <para>0, LNA off</para> + <para>1, LNA on</para> + <para>use the special macro LNA_AUTO to set LNA auto</para> + </section> </section> <section id="frontend-property-terrestrial-systems"> <title>Properties used on terrestrial delivery systems</title> @@ -816,6 +869,7 @@ typedef enum fe_hierarchy { <listitem><para><link linkend="DTV-GUARD-INTERVAL"><constant>DTV_GUARD_INTERVAL</constant></link></para></listitem> <listitem><para><link linkend="DTV-TRANSMISSION-MODE"><constant>DTV_TRANSMISSION_MODE</constant></link></para></listitem> <listitem><para><link linkend="DTV-HIERARCHY"><constant>DTV_HIERARCHY</constant></link></para></listitem> + <listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem> </itemizedlist> </section> <section id="dvbt2-params"> @@ -838,7 +892,8 @@ typedef enum fe_hierarchy { <listitem><para><link linkend="DTV-GUARD-INTERVAL"><constant>DTV_GUARD_INTERVAL</constant></link></para></listitem> <listitem><para><link linkend="DTV-TRANSMISSION-MODE"><constant>DTV_TRANSMISSION_MODE</constant></link></para></listitem> <listitem><para><link linkend="DTV-HIERARCHY"><constant>DTV_HIERARCHY</constant></link></para></listitem> - <listitem><para><link linkend="DTV-DVBT2-PLP-ID"><constant>DTV_DVBT2_PLP_ID</constant></link></para></listitem> + <listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem> + <listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem> </itemizedlist> </section> <section id="isdbt"> @@ -925,13 +980,32 @@ typedef enum fe_hierarchy { <listitem><para><link linkend="DTV-ATSCMH-PRC"><constant>DTV_ATSCMH_PRC</constant></link></para></listitem> <listitem><para><link linkend="DTV-ATSCMH-RS-FRAME-MODE"><constant>DTV_ATSCMH_RS_FRAME_MODE</constant></link></para></listitem> <listitem><para><link linkend="DTV-ATSCMH-RS-FRAME-ENSEMBLE"><constant>DTV_ATSCMH_RS_FRAME_ENSEMBLE</constant></link></para></listitem> - <listitem><para><link linkend="DTV-ATSCMH-CODE-MODE-PRI"><constant>DTV_ATSCMH_CODE_MODE_PRI</constant></link></para></listitem> - <listitem><para><link linkend="DTV-ATSCMH-CODE-MODE-SEC"><constant>DTV_ATSCMH_CODE_MODE_SEC</constant></link></para></listitem> + <listitem><para><link linkend="DTV-ATSCMH-RS-CODE-MODE-PRI"><constant>DTV_ATSCMH_RS_CODE_MODE_PRI</constant></link></para></listitem> + <listitem><para><link linkend="DTV-ATSCMH-RS-CODE-MODE-SEC"><constant>DTV_ATSCMH_RS_CODE_MODE_SEC</constant></link></para></listitem> <listitem><para><link linkend="DTV-ATSCMH-SCCC-BLOCK-MODE"><constant>DTV_ATSCMH_SCCC_BLOCK_MODE</constant></link></para></listitem> - <listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE_MODE-A"><constant>DTV_ATSCMH_SCCC_CODE_MODE_A</constant></link></para></listitem> - <listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE_MODE-B"><constant>DTV_ATSCMH_SCCC_CODE_MODE_B</constant></link></para></listitem> - <listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE_MODE-C"><constant>DTV_ATSCMH_SCCC_CODE_MODE_C</constant></link></para></listitem> - <listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE_MODE-D"><constant>DTV_ATSCMH_SCCC_CODE_MODE_D</constant></link></para></listitem> + <listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-A"><constant>DTV_ATSCMH_SCCC_CODE_MODE_A</constant></link></para></listitem> + <listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-B"><constant>DTV_ATSCMH_SCCC_CODE_MODE_B</constant></link></para></listitem> + <listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-C"><constant>DTV_ATSCMH_SCCC_CODE_MODE_C</constant></link></para></listitem> + <listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-D"><constant>DTV_ATSCMH_SCCC_CODE_MODE_D</constant></link></para></listitem> + </itemizedlist> + </section> + <section id="dtmb-params"> + <title>DTMB delivery system</title> + <para>The following parameters are valid for DTMB:</para> + <itemizedlist mark='opencircle'> + <listitem><para><link linkend="DTV-API-VERSION"><constant>DTV_API_VERSION</constant></link></para></listitem> + <listitem><para><link linkend="DTV-DELIVERY-SYSTEM"><constant>DTV_DELIVERY_SYSTEM</constant></link></para></listitem> + <listitem><para><link linkend="DTV-TUNE"><constant>DTV_TUNE</constant></link></para></listitem> + <listitem><para><link linkend="DTV-CLEAR"><constant>DTV_CLEAR</constant></link></para></listitem> + <listitem><para><link linkend="DTV-FREQUENCY"><constant>DTV_FREQUENCY</constant></link></para></listitem> + <listitem><para><link linkend="DTV-MODULATION"><constant>DTV_MODULATION</constant></link></para></listitem> + <listitem><para><link linkend="DTV-BANDWIDTH-HZ"><constant>DTV_BANDWIDTH_HZ</constant></link></para></listitem> + <listitem><para><link linkend="DTV-INVERSION"><constant>DTV_INVERSION</constant></link></para></listitem> + <listitem><para><link linkend="DTV-INNER-FEC"><constant>DTV_INNER_FEC</constant></link></para></listitem> + <listitem><para><link linkend="DTV-GUARD-INTERVAL"><constant>DTV_GUARD_INTERVAL</constant></link></para></listitem> + <listitem><para><link linkend="DTV-TRANSMISSION-MODE"><constant>DTV_TRANSMISSION_MODE</constant></link></para></listitem> + <listitem><para><link linkend="DTV-INTERLEAVING"><constant>DTV_INTERLEAVING</constant></link></para></listitem> + <listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem> </itemizedlist> </section> </section> @@ -952,6 +1026,7 @@ typedef enum fe_hierarchy { <listitem><para><link linkend="DTV-INVERSION"><constant>DTV_INVERSION</constant></link></para></listitem> <listitem><para><link linkend="DTV-SYMBOL-RATE"><constant>DTV_SYMBOL_RATE</constant></link></para></listitem> <listitem><para><link linkend="DTV-INNER-FEC"><constant>DTV_INNER_FEC</constant></link></para></listitem> + <listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem> </itemizedlist> </section> <section id="dvbc-annex-b-params"> @@ -966,6 +1041,7 @@ typedef enum fe_hierarchy { <listitem><para><link linkend="DTV-FREQUENCY"><constant>DTV_FREQUENCY</constant></link></para></listitem> <listitem><para><link linkend="DTV-MODULATION"><constant>DTV_MODULATION</constant></link></para></listitem> <listitem><para><link linkend="DTV-INVERSION"><constant>DTV_INVERSION</constant></link></para></listitem> + <listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem> </itemizedlist> </section> </section> @@ -999,6 +1075,7 @@ typedef enum fe_hierarchy { <listitem><para><link linkend="DTV-MODULATION"><constant>DTV_MODULATION</constant></link></para></listitem> <listitem><para><link linkend="DTV-PILOT"><constant>DTV_PILOT</constant></link></para></listitem> <listitem><para><link linkend="DTV-ROLLOFF"><constant>DTV_ROLLOFF</constant></link></para></listitem> + <listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem> </itemizedlist> </section> <section id="turbo-params"> @@ -1021,7 +1098,7 @@ typedef enum fe_hierarchy { <listitem><para><link linkend="DTV-SYMBOL-RATE"><constant>DTV_SYMBOL_RATE</constant></link></para></listitem> <listitem><para><link linkend="DTV-INNER-FEC"><constant>DTV_INNER_FEC</constant></link></para></listitem> <listitem><para><link linkend="DTV-VOLTAGE"><constant>DTV_VOLTAGE</constant></link></para></listitem> - <listitem><para><link linkend="DTV-ISDBS-TS-ID"><constant>DTV_ISDBS_TS_ID</constant></link></para></listitem> + <listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem> </itemizedlist> </section> </section> diff --git a/Documentation/DocBook/media/dvb/frontend.xml b/Documentation/DocBook/media/dvb/frontend.xml index aeaed59d0f1f..426c2526a454 100644 --- a/Documentation/DocBook/media/dvb/frontend.xml +++ b/Documentation/DocBook/media/dvb/frontend.xml @@ -66,7 +66,7 @@ supported via the new <link linkend="FE_GET_SET_PROPERTY">FE_GET_PROPERTY/FE_GET <para>The usage of this field is deprecated, as it doesn't report all supported standards, and will provide an incomplete information for frontends that support multiple delivery systems. -Please use <link linkend="DTV_ENUM_DELSYS">DTV_ENUM_DELSYS</link> instead.</para> +Please use <link linkend="DTV-ENUM-DELSYS">DTV_ENUM_DELSYS</link> instead.</para> </section> <section id="fe-caps-t"> @@ -101,6 +101,7 @@ a specific frontend type.</para> FE_CAN_8VSB = 0x200000, FE_CAN_16VSB = 0x400000, FE_HAS_EXTENDED_CAPS = 0x800000, + FE_CAN_MULTISTREAM = 0x4000000, FE_CAN_TURBO_FEC = 0x8000000, FE_CAN_2G_MODULATION = 0x10000000, FE_NEEDS_BENDING = 0x20000000, @@ -207,18 +208,44 @@ spec.</para> <para>Several functions of the frontend device use the fe_status data type defined by</para> <programlisting> - typedef enum fe_status { - FE_HAS_SIGNAL = 0x01, /⋆ found something above the noise level ⋆/ - FE_HAS_CARRIER = 0x02, /⋆ found a DVB signal ⋆/ - FE_HAS_VITERBI = 0x04, /⋆ FEC is stable ⋆/ - FE_HAS_SYNC = 0x08, /⋆ found sync bytes ⋆/ - FE_HAS_LOCK = 0x10, /⋆ everything's working... ⋆/ - FE_TIMEDOUT = 0x20, /⋆ no lock within the last ~2 seconds ⋆/ - FE_REINIT = 0x40 /⋆ frontend was reinitialized, ⋆/ - } fe_status_t; /⋆ application is recommned to reset ⋆/ +typedef enum fe_status { + FE_HAS_SIGNAL = 0x01, + FE_HAS_CARRIER = 0x02, + FE_HAS_VITERBI = 0x04, + FE_HAS_SYNC = 0x08, + FE_HAS_LOCK = 0x10, + FE_TIMEDOUT = 0x20, + FE_REINIT = 0x40, +} fe_status_t; </programlisting> -<para>to indicate the current state and/or state changes of the frontend hardware. -</para> +<para>to indicate the current state and/or state changes of the frontend hardware: +</para> + +<informaltable><tgroup cols="2"><tbody> +<row> +<entry align="char">FE_HAS_SIGNAL</entry> +<entry align="char">The frontend has found something above the noise level</entry> +</row><row> +<entry align="char">FE_HAS_CARRIER</entry> +<entry align="char">The frontend has found a DVB signal</entry> +</row><row> +<entry align="char">FE_HAS_VITERBI</entry> +<entry align="char">The frontend FEC code is stable</entry> +</row><row> +<entry align="char">FE_HAS_SYNC</entry> +<entry align="char">Syncronization bytes was found</entry> +</row><row> +<entry align="char">FE_HAS_LOCK</entry> +<entry align="char">The DVB were locked and everything is working</entry> +</row><row> +<entry align="char">FE_TIMEDOUT</entry> +<entry align="char">no lock within the last about 2 seconds</entry> +</row><row> +<entry align="char">FE_REINIT</entry> +<entry align="char">The frontend was reinitialized, application is +recommended to reset DiSEqC, tone and parameters</entry> +</row> +</tbody></tgroup></informaltable> </section> @@ -238,7 +265,7 @@ and to add newer delivery systems.</para> <constant>FE_GET_PROPERTY/FE_SET_PROPERTY</constant></link> instead, in order to be able to support the newer System Delivery like DVB-S2, DVB-T2, DVB-C2, ISDB, etc.</para> -<para>All kinds of parameters are combined as an union in the FrontendParameters structure:</para> +<para>All kinds of parameters are combined as an union in the FrontendParameters structure: <programlisting> struct dvb_frontend_parameters { uint32_t frequency; /⋆ (absolute) frequency in Hz for QAM/OFDM ⋆/ @@ -251,12 +278,13 @@ struct dvb_frontend_parameters { struct dvb_vsb_parameters vsb; } u; }; -</programlisting> +</programlisting></para> <para>In the case of QPSK frontends the <constant>frequency</constant> field specifies the intermediate frequency, i.e. the offset which is effectively added to the local oscillator frequency (LOF) of the LNB. The intermediate frequency has to be specified in units of kHz. For QAM and OFDM frontends the <constant>frequency</constant> specifies the absolute frequency and is given in Hz. </para> + <section id="dvb-qpsk-parameters"> <title>QPSK parameters</title> <para>For satellite QPSK frontends you have to use the <constant>dvb_qpsk_parameters</constant> structure:</para> @@ -321,8 +349,8 @@ itself. <section id="fe-code-rate-t"> <title>frontend code rate</title> <para>The possible values for the <constant>fec_inner</constant> field used on -<link refend="dvb-qpsk-parameters"><constant>struct dvb_qpsk_parameters</constant></link> and -<link refend="dvb-qam-parameters"><constant>struct dvb_qam_parameters</constant></link> are: +<link linkend="dvb-qpsk-parameters"><constant>struct dvb_qpsk_parameters</constant></link> and +<link linkend="dvb-qam-parameters"><constant>struct dvb_qam_parameters</constant></link> are: </para> <programlisting> typedef enum fe_code_rate { @@ -347,9 +375,9 @@ detection. <section id="fe-modulation-t"> <title>frontend modulation type for QAM, OFDM and VSB</title> <para>For cable and terrestrial frontends, e. g. for -<link refend="dvb-qam-parameters"><constant>struct dvb_qpsk_parameters</constant></link>, -<link refend="dvb-ofdm-parameters"><constant>struct dvb_qam_parameters</constant></link> and -<link refend="dvb-vsb-parameters"><constant>struct dvb_qam_parameters</constant></link>, +<link linkend="dvb-qam-parameters"><constant>struct dvb_qpsk_parameters</constant></link>, +<link linkend="dvb-ofdm-parameters"><constant>struct dvb_qam_parameters</constant></link> and +<link linkend="dvb-vsb-parameters"><constant>struct dvb_qam_parameters</constant></link>, it needs to specify the quadrature modulation mode which can be one of the following: </para> <programlisting> @@ -370,8 +398,8 @@ it needs to specify the quadrature modulation mode which can be one of the follo } fe_modulation_t; </programlisting> </section> -<para>Finally, there are several more parameters for OFDM: -</para> +<section> +<title>More OFDM parameters</title> <section id="fe-transmit-mode-t"> <title>Number of carriers per channel</title> <programlisting> @@ -427,6 +455,7 @@ typedef enum fe_hierarchy { } fe_hierarchy_t; </programlisting> </section> +</section> </section> diff --git a/Documentation/DocBook/media/dvb/intro.xml b/Documentation/DocBook/media/dvb/intro.xml index 170064a3dc8f..2048b53d19b9 100644 --- a/Documentation/DocBook/media/dvb/intro.xml +++ b/Documentation/DocBook/media/dvb/intro.xml @@ -205,7 +205,7 @@ a partial path like:</para> additional include file <emphasis role="tt">linux/dvb/version.h</emphasis> exists, which defines the constant <emphasis role="tt">DVB_API_VERSION</emphasis>. This document -describes <emphasis role="tt">DVB_API_VERSION 5.4</emphasis>. +describes <emphasis role="tt">DVB_API_VERSION 5.8</emphasis>. </para> </section> diff --git a/Documentation/DocBook/media/dvb/kdapi.xml b/Documentation/DocBook/media/dvb/kdapi.xml index 6c67481eaa4b..6c11ec52cbee 100644 --- a/Documentation/DocBook/media/dvb/kdapi.xml +++ b/Documentation/DocBook/media/dvb/kdapi.xml @@ -2,7 +2,7 @@ <para>The kernel demux API defines a driver-internal interface for registering low-level, hardware specific driver to a hardware independent demux layer. It is only of interest for DVB device driver writers. The header file for this API is named <emphasis role="tt">demux.h</emphasis> and located in -<emphasis role="tt">drivers/media/dvb/dvb-core</emphasis>. +<emphasis role="tt">drivers/media/dvb-core</emphasis>. </para> <para>Maintainer note: This section must be reviewed. It is probably out of date. </para> diff --git a/Documentation/DocBook/media/dvb/net.xml b/Documentation/DocBook/media/dvb/net.xml index 67d37e5ce597..a193e86941b5 100644 --- a/Documentation/DocBook/media/dvb/net.xml +++ b/Documentation/DocBook/media/dvb/net.xml @@ -26,4 +26,131 @@ struct dvb_net_if { <title>DVB net Function Calls</title> <para>To be written… </para> + +<section id="NET_ADD_IF" +role="subsection"><title>NET_ADD_IF</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl is undocumented. Documentation is welcome.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(fd, int request = NET_ADD_IF, + struct dvb_net_if *if);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals NET_ADD_IF for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>struct dvb_net_if *if +</para> +</entry><entry + align="char"> +<para>Undocumented.</para> +</entry> + </row></tbody></tgroup></informaltable> +&return-value-dvb; +</section> + +<section id="NET_REMOVE_IF" +role="subsection"><title>NET_REMOVE_IF</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl is undocumented. Documentation is welcome.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(fd, int request = NET_REMOVE_IF); +</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals NET_REMOVE_IF for this command.</para> +</entry> + </row></tbody></tgroup></informaltable> +&return-value-dvb; +</section> + +<section id="NET_GET_IF" +role="subsection"><title>NET_GET_IF</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl is undocumented. Documentation is welcome.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(fd, int request = NET_GET_IF, + struct dvb_net_if *if);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals NET_GET_IF for this command.</para> +</entry> + </row><row><entry + align="char"> +<para>struct dvb_net_if *if +</para> +</entry><entry + align="char"> +<para>Undocumented.</para> +</entry> + </row></tbody></tgroup></informaltable> +&return-value-dvb; +</section> </section> diff --git a/Documentation/DocBook/media/dvb/video.xml b/Documentation/DocBook/media/dvb/video.xml index 25fb823226b4..3ea1ca7e785e 100644 --- a/Documentation/DocBook/media/dvb/video.xml +++ b/Documentation/DocBook/media/dvb/video.xml @@ -15,6 +15,10 @@ the audio and video device as well as the video4linux device. <para>The ioctls that deal with SPUs (sub picture units) and navigation packets are only supported on some MPEG decoders made for DVD playback. </para> +<para> +These ioctls were also used by V4L2 to control MPEG decoders implemented in V4L2. The use +of these ioctls for that purpose has been made obsolete and proper V4L2 ioctls or controls +have been created to replace that functionality.</para> <section id="video_types"> <title>Video Data Types</title> @@ -55,7 +59,7 @@ typedef enum { </section> <section id="video-stream-source-t"> -<title>video stream source</title> +<title>video_stream_source_t</title> <para>The video stream source is set through the VIDEO_SELECT_SOURCE call and can take the following values, depending on whether we are replaying from an internal (demuxer) or external (user write) source. @@ -76,7 +80,7 @@ call. </section> <section id="video-play-state-t"> -<title>video play state</title> +<title>video_play_state_t</title> <para>The following values can be returned by the VIDEO_GET_STATUS call representing the state of video playback. </para> @@ -90,9 +94,9 @@ typedef enum { </section> <section id="video-command"> +<title>struct video_command</title> <para>The structure must be zeroed before use by the application This ensures it can be extended safely in the future.</para> -<title>struct video-command</title> <programlisting> struct video_command { __u32 cmd; @@ -121,7 +125,7 @@ struct video_command { </section> <section id="video-size-t"> -<title>struct video_size-t</title> +<title>video_size_t</title> <programlisting> typedef struct { int w; @@ -217,7 +221,7 @@ bits set according to the hardwares capabilities. </section> <section id="video-system"> -<title>video system</title> +<title>video_system_t</title> <para>A call to VIDEO_SET_SYSTEM sets the desired video system for TV output. The following system types can be set: </para> @@ -263,7 +267,7 @@ call expects the following format for that information: </section> <section id="video-spu"> -<title>video SPU</title> +<title>struct video_spu</title> <para>Calling VIDEO_SET_SPU deactivates or activates SPU decoding, according to the following format: </para> @@ -277,12 +281,12 @@ following format: </section> <section id="video-spu-palette"> -<title>video SPU palette</title> +<title>struct video_spu_palette</title> <para>The following structure is used to set the SPU palette by calling VIDEO_SPU_PALETTE: </para> <programlisting> typedef - struct video_spu_palette{ + struct video_spu_palette { int length; uint8_t ⋆palette; } video_spu_palette_t; @@ -290,13 +294,13 @@ following format: </section> <section id="video-navi-pack"> -<title>video NAVI pack</title> +<title>struct video_navi_pack</title> <para>In order to get the navigational data the following structure has to be passed to the ioctl VIDEO_GET_NAVI: </para> <programlisting> typedef - struct video_navi_pack{ + struct video_navi_pack { int length; /⋆ 0 ... 1024 ⋆/ uint8_t data[1024]; } video_navi_pack_t; @@ -305,7 +309,7 @@ VIDEO_GET_NAVI: <section id="video-attributes-t"> -<title>video attributes</title> +<title>video_attributes_t</title> <para>The following attributes can be set by a call to VIDEO_SET_ATTRIBUTES: </para> <programlisting> @@ -541,6 +545,8 @@ VIDEO_GET_NAVI: role="subsection"><title>VIDEO_STOP</title> <para>DESCRIPTION </para> +<para>This ioctl is for DVB devices only. To control a V4L2 decoder use the V4L2 +&VIDIOC-DECODER-CMD; instead.</para> <informaltable><tgroup cols="1"><tbody><row><entry align="char"> <para>This ioctl call asks the Video Device to stop playing the current stream. @@ -598,6 +604,8 @@ role="subsection"><title>VIDEO_STOP</title> role="subsection"><title>VIDEO_PLAY</title> <para>DESCRIPTION </para> +<para>This ioctl is for DVB devices only. To control a V4L2 decoder use the V4L2 +&VIDIOC-DECODER-CMD; instead.</para> <informaltable><tgroup cols="1"><tbody><row><entry align="char"> <para>This ioctl call asks the Video Device to start playing a video stream from the @@ -634,6 +642,8 @@ role="subsection"><title>VIDEO_PLAY</title> role="subsection"><title>VIDEO_FREEZE</title> <para>DESCRIPTION </para> +<para>This ioctl is for DVB devices only. To control a V4L2 decoder use the V4L2 +&VIDIOC-DECODER-CMD; instead.</para> <informaltable><tgroup cols="1"><tbody><row><entry align="char"> <para>This ioctl call suspends the live video stream being played. Decoding @@ -674,6 +684,8 @@ role="subsection"><title>VIDEO_FREEZE</title> role="subsection"><title>VIDEO_CONTINUE</title> <para>DESCRIPTION </para> +<para>This ioctl is for DVB devices only. To control a V4L2 decoder use the V4L2 +&VIDIOC-DECODER-CMD; instead.</para> <informaltable><tgroup cols="1"><tbody><row><entry align="char"> <para>This ioctl call restarts decoding and playing processes of the video stream @@ -710,6 +722,9 @@ role="subsection"><title>VIDEO_CONTINUE</title> role="subsection"><title>VIDEO_SELECT_SOURCE</title> <para>DESCRIPTION </para> +<para>This ioctl is for DVB devices only. This ioctl was also supported by the +V4L2 ivtv driver, but that has been replaced by the ivtv-specific +<constant>IVTV_IOC_PASSTHROUGH_MODE</constant> ioctl.</para> <informaltable><tgroup cols="1"><tbody><row><entry align="char"> <para>This ioctl call informs the video device which source shall be used for the input @@ -845,10 +860,160 @@ role="subsection"><title>VIDEO_GET_STATUS</title> </row></tbody></tgroup></informaltable> &return-value-dvb; +</section><section id="VIDEO_GET_FRAME_COUNT" +role="subsection"><title>VIDEO_GET_FRAME_COUNT</title> +<para>DESCRIPTION +</para> +<para>This ioctl is obsolete. Do not use in new drivers. For V4L2 decoders this +ioctl has been replaced by the <constant>V4L2_CID_MPEG_VIDEO_DEC_FRAME</constant> control.</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call asks the Video Device to return the number of displayed frames +since the decoder was started.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = + VIDEO_GET_FRAME_COUNT, __u64 *pts);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals VIDEO_GET_FRAME_COUNT for this + command.</para> +</entry> + </row><row><entry + align="char"> +<para>__u64 *pts +</para> +</entry><entry + align="char"> +<para>Returns the number of frames displayed since the decoder was started. +</para> +</entry> + </row></tbody></tgroup></informaltable> +&return-value-dvb; + +</section><section id="VIDEO_GET_PTS" +role="subsection"><title>VIDEO_GET_PTS</title> +<para>DESCRIPTION +</para> +<para>This ioctl is obsolete. Do not use in new drivers. For V4L2 decoders this +ioctl has been replaced by the <constant>V4L2_CID_MPEG_VIDEO_DEC_PTS</constant> control.</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call asks the Video Device to return the current PTS timestamp.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = + VIDEO_GET_PTS, __u64 *pts);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals VIDEO_GET_PTS for this + command.</para> +</entry> + </row><row><entry + align="char"> +<para>__u64 *pts +</para> +</entry><entry + align="char"> +<para>Returns the 33-bit timestamp as defined in ITU T-REC-H.222.0 / ISO/IEC 13818-1. +</para> +<para> +The PTS should belong to the currently played +frame if possible, but may also be a value close to it +like the PTS of the last decoded frame or the last PTS +extracted by the PES parser.</para> +</entry> + </row></tbody></tgroup></informaltable> +&return-value-dvb; + +</section><section id="VIDEO_GET_FRAME_RATE" +role="subsection"><title>VIDEO_GET_FRAME_RATE</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl call asks the Video Device to return the current framerate.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = + VIDEO_GET_FRAME_RATE, unsigned int *rate);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals VIDEO_GET_FRAME_RATE for this + command.</para> +</entry> + </row><row><entry + align="char"> +<para>unsigned int *rate +</para> +</entry><entry + align="char"> +<para>Returns the framerate in number of frames per 1000 seconds. +</para> +</entry> + </row></tbody></tgroup></informaltable> +&return-value-dvb; + </section><section id="VIDEO_GET_EVENT" role="subsection"><title>VIDEO_GET_EVENT</title> <para>DESCRIPTION </para> +<para>This ioctl is for DVB devices only. To get events from a V4L2 decoder use the V4L2 +&VIDIOC-DQEVENT; ioctl instead.</para> <informaltable><tgroup cols="1"><tbody><row><entry align="char"> <para>This ioctl call returns an event of type video_event if available. If an event is @@ -914,6 +1079,152 @@ role="subsection"><title>VIDEO_GET_EVENT</title> </entry> </row></tbody></tgroup></informaltable> +</section><section id="VIDEO_COMMAND" +role="subsection"><title>VIDEO_COMMAND</title> +<para>DESCRIPTION +</para> +<para>This ioctl is obsolete. Do not use in new drivers. For V4L2 decoders this +ioctl has been replaced by the &VIDIOC-DECODER-CMD; ioctl.</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl commands the decoder. The <constant>video_command</constant> struct +is a subset of the <constant>v4l2_decoder_cmd</constant> struct, so refer to the +&VIDIOC-DECODER-CMD; documentation for more information.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = + VIDEO_COMMAND, struct video_command *cmd);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals VIDEO_COMMAND for this + command.</para> +</entry> + </row><row><entry + align="char"> +<para>struct video_command *cmd +</para> +</entry><entry + align="char"> +<para>Commands the decoder. +</para> +</entry> + </row></tbody></tgroup></informaltable> +&return-value-dvb; + +</section><section id="VIDEO_TRY_COMMAND" +role="subsection"><title>VIDEO_TRY_COMMAND</title> +<para>DESCRIPTION +</para> +<para>This ioctl is obsolete. Do not use in new drivers. For V4L2 decoders this +ioctl has been replaced by the &VIDIOC-TRY-DECODER-CMD; ioctl.</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl tries a decoder command. The <constant>video_command</constant> struct +is a subset of the <constant>v4l2_decoder_cmd</constant> struct, so refer to the +&VIDIOC-TRY-DECODER-CMD; documentation for more information.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = + VIDEO_TRY_COMMAND, struct video_command *cmd);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals VIDEO_TRY_COMMAND for this + command.</para> +</entry> + </row><row><entry + align="char"> +<para>struct video_command *cmd +</para> +</entry><entry + align="char"> +<para>Try a decoder command. +</para> +</entry> + </row></tbody></tgroup></informaltable> +&return-value-dvb; + +</section><section id="VIDEO_GET_SIZE" +role="subsection"><title>VIDEO_GET_SIZE</title> +<para>DESCRIPTION +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>This ioctl returns the size and aspect ratio.</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>SYNOPSIS +</para> +<informaltable><tgroup cols="1"><tbody><row><entry + align="char"> +<para>int ioctl(int fd, int request = + VIDEO_GET_SIZE, video_size_t *size);</para> +</entry> + </row></tbody></tgroup></informaltable> +<para>PARAMETERS +</para> +<informaltable><tgroup cols="2"><tbody><row><entry + align="char"> +<para>int fd</para> +</entry><entry + align="char"> +<para>File descriptor returned by a previous call to open().</para> +</entry> + </row><row><entry + align="char"> +<para>int request</para> +</entry><entry + align="char"> +<para>Equals VIDEO_GET_SIZE for this + command.</para> +</entry> + </row><row><entry + align="char"> +<para>video_size_t *size +</para> +</entry><entry + align="char"> +<para>Returns the size and aspect ratio. +</para> +</entry> + </row></tbody></tgroup></informaltable> +&return-value-dvb; + </section><section id="VIDEO_SET_DISPLAY_FORMAT" role="subsection"><title>VIDEO_SET_DISPLAY_FORMAT</title> <para>DESCRIPTION diff --git a/Documentation/DocBook/media/v4l/biblio.xml b/Documentation/DocBook/media/v4l/biblio.xml index 1078e45f189f..d2eb79e41a01 100644 --- a/Documentation/DocBook/media/v4l/biblio.xml +++ b/Documentation/DocBook/media/v4l/biblio.xml @@ -178,23 +178,23 @@ Signal - NTSC for Studio Applications"</title> 1125-Line High-Definition Production"</title> </biblioentry> - <biblioentry id="en50067"> - <abbrev>EN 50067</abbrev> + <biblioentry id="iec62106"> + <abbrev>IEC 62106</abbrev> <authorgroup> - <corpauthor>European Committee for Electrotechnical Standardization -(<ulink url="http://www.cenelec.eu">http://www.cenelec.eu</ulink>)</corpauthor> + <corpauthor>International Electrotechnical Commission +(<ulink url="http://www.iec.ch">http://www.iec.ch</ulink>)</corpauthor> </authorgroup> <title>Specification of the radio data system (RDS) for VHF/FM sound broadcasting in the frequency range from 87,5 to 108,0 MHz</title> </biblioentry> <biblioentry id="nrsc4"> - <abbrev>NRSC-4</abbrev> + <abbrev>NRSC-4-B</abbrev> <authorgroup> <corpauthor>National Radio Systems Committee (<ulink url="http://www.nrscstandards.org">http://www.nrscstandards.org</ulink>)</corpauthor> </authorgroup> - <title>NRSC-4: United States RBDS Standard</title> + <title>NRSC-4-B: United States RBDS Standard</title> </biblioentry> <biblioentry id="iso12232"> @@ -226,4 +226,44 @@ in the frequency range from 87,5 to 108,0 MHz</title> <title>VESA and Industry Standards and Guidelines for Computer Display Monitor Timing (DMT)</title> </biblioentry> + <biblioentry id="vesaedid"> + <abbrev>EDID</abbrev> + <authorgroup> + <corpauthor>Video Electronics Standards Association +(<ulink url="http://www.vesa.org">http://www.vesa.org</ulink>)</corpauthor> + </authorgroup> + <title>VESA Enhanced Extended Display Identification Data Standard</title> + <subtitle>Release A, Revision 2</subtitle> + </biblioentry> + + <biblioentry id="hdcp"> + <abbrev>HDCP</abbrev> + <authorgroup> + <corpauthor>Digital Content Protection LLC +(<ulink url="http://www.digital-cp.com">http://www.digital-cp.com</ulink>)</corpauthor> + </authorgroup> + <title>High-bandwidth Digital Content Protection System</title> + <subtitle>Revision 1.3</subtitle> + </biblioentry> + + <biblioentry id="hdmi"> + <abbrev>HDMI</abbrev> + <authorgroup> + <corpauthor>HDMI Licensing LLC +(<ulink url="http://www.hdmi.org">http://www.hdmi.org</ulink>)</corpauthor> + </authorgroup> + <title>High-Definition Multimedia Interface</title> + <subtitle>Specification Version 1.4a</subtitle> + </biblioentry> + + <biblioentry id="dp"> + <abbrev>DP</abbrev> + <authorgroup> + <corpauthor>Video Electronics Standards Association +(<ulink url="http://www.vesa.org">http://www.vesa.org</ulink>)</corpauthor> + </authorgroup> + <title>VESA DisplayPort Standard</title> + <subtitle>Version 1, Revision 2</subtitle> + </biblioentry> + </bibliography> diff --git a/Documentation/DocBook/media/v4l/common.xml b/Documentation/DocBook/media/v4l/common.xml index b91d25313b63..73c6847436c9 100644 --- a/Documentation/DocBook/media/v4l/common.xml +++ b/Documentation/DocBook/media/v4l/common.xml @@ -564,7 +564,7 @@ automatically.</para> <para>To query and select the standard used by the current video input or output applications call the &VIDIOC-G-STD; and &VIDIOC-S-STD; ioctl, respectively. The <emphasis>received</emphasis> -standard can be sensed with the &VIDIOC-QUERYSTD; ioctl. Note parameter of all these ioctls is a pointer to a &v4l2-std-id; type (a standard set), <emphasis>not</emphasis> an index into the standard enumeration.<footnote> +standard can be sensed with the &VIDIOC-QUERYSTD; ioctl. Note that the parameter of all these ioctls is a pointer to a &v4l2-std-id; type (a standard set), <emphasis>not</emphasis> an index into the standard enumeration.<footnote> <para>An alternative to the current scheme is to use pointers to indices as arguments of <constant>VIDIOC_G_STD</constant> and <constant>VIDIOC_S_STD</constant>, the &v4l2-input; and @@ -588,30 +588,28 @@ switch to a standard by &v4l2-std-id;.</para> </footnote> Drivers must implement all video standard ioctls when the device has one or more video inputs or outputs.</para> - <para>Special rules apply to USB cameras where the notion of video -standards makes little sense. More generally any capture device, -output devices accordingly, which is <itemizedlist> + <para>Special rules apply to devices such as USB cameras where the notion of video +standards makes little sense. More generally for any capture or output device +which is: <itemizedlist> <listitem> <para>incapable of capturing fields or frames at the nominal rate of the video standard, or</para> </listitem> <listitem> - <para>where <link linkend="buffer">timestamps</link> refer -to the instant the field or frame was received by the driver, not the -capture time, or</para> - </listitem> - <listitem> - <para>where <link linkend="buffer">sequence numbers</link> -refer to the frames received by the driver, not the captured -frames.</para> + <para>that does not support the video standard formats at all.</para> </listitem> </itemizedlist> Here the driver shall set the <structfield>std</structfield> field of &v4l2-input; and &v4l2-output; -to zero, the <constant>VIDIOC_G_STD</constant>, +to zero and the <constant>VIDIOC_G_STD</constant>, <constant>VIDIOC_S_STD</constant>, <constant>VIDIOC_QUERYSTD</constant> and <constant>VIDIOC_ENUMSTD</constant> ioctls shall return the -&EINVAL;.<footnote> +&ENOTTY;.<footnote> + <para>See <xref linkend="buffer" /> for a rationale.</para> + <para>Applications can make use of the <xref linkend="input-capabilities" /> and +<xref linkend="output-capabilities"/> flags to determine whether the video standard ioctls +are available for the device.</para> +&ENOTTY;. <para>See <xref linkend="buffer" /> for a rationale. Probably even USB cameras follow some well known video standard. It might have been better to explicitly indicate elsewhere if a device cannot live @@ -626,9 +624,9 @@ up to normal expectations, instead of this exception.</para> &v4l2-standard; standard; if (-1 == ioctl (fd, &VIDIOC-G-STD;, &std_id)) { - /* Note when VIDIOC_ENUMSTD always returns EINVAL this + /* Note when VIDIOC_ENUMSTD always returns ENOTTY this is no video device or it falls under the USB exception, - and VIDIOC_G_STD returning EINVAL is no error. */ + and VIDIOC_G_STD returning ENOTTY is no error. */ perror ("VIDIOC_G_STD"); exit (EXIT_FAILURE); diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index faa0fd14666a..4fdf6b562d1c 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -1476,7 +1476,7 @@ follows.<informaltable> </row> <row> <entry><constant>V4L2_BUF_TYPE_PRIVATE_BASE</constant></entry> - <entry><constant>V4L2_BUF_TYPE_PRIVATE</constant></entry> + <entry><constant>V4L2_BUF_TYPE_PRIVATE</constant> (but this is deprecated)</entry> </row> </tbody> </tgroup> @@ -2468,21 +2468,9 @@ that used it. It was originally scheduled for removal in 2.6.35. <structfield>reserved2</structfield> and removed <constant>V4L2_BUF_FLAG_INPUT</constant>.</para> </listitem> - </orderedlist> - </section> - - <section> - <title>V4L2 in Linux 3.6</title> - <orderedlist> <listitem> <para>Added V4L2_CAP_VIDEO_M2M and V4L2_CAP_VIDEO_M2M_MPLANE capabilities.</para> </listitem> - </orderedlist> - </section> - - <section> - <title>V4L2 in Linux 3.6</title> - <orderedlist> <listitem> <para>Added support for frequency band enumerations: &VIDIOC-ENUM-FREQ-BANDS;.</para> </listitem> @@ -2567,29 +2555,6 @@ and may change in the future.</para> <para>Video Output Overlay (OSD) Interface, <xref linkend="osd" />.</para> </listitem> - <listitem> - <para><constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY</constant>, - &v4l2-buf-type;, <xref linkend="v4l2-buf-type" />.</para> - </listitem> - <listitem> - <para><constant>V4L2_CAP_VIDEO_OUTPUT_OVERLAY</constant>, -&VIDIOC-QUERYCAP; ioctl, <xref linkend="device-capabilities" />.</para> - </listitem> - <listitem> - <para>&VIDIOC-ENUM-FRAMESIZES; and -&VIDIOC-ENUM-FRAMEINTERVALS; ioctls.</para> - </listitem> - <listitem> - <para>&VIDIOC-G-ENC-INDEX; ioctl.</para> - </listitem> - <listitem> - <para>&VIDIOC-ENCODER-CMD; and &VIDIOC-TRY-ENCODER-CMD; -ioctls.</para> - </listitem> - <listitem> - <para>&VIDIOC-DECODER-CMD; and &VIDIOC-TRY-DECODER-CMD; -ioctls.</para> - </listitem> <listitem> <para>&VIDIOC-DBG-G-REGISTER; and &VIDIOC-DBG-S-REGISTER; ioctls.</para> @@ -2615,11 +2580,11 @@ ioctls.</para> and &VIDIOC-SUBDEV-S-SELECTION; ioctls.</para> </listitem> <listitem> - <para><link linkend="v4l2-auto-focus-area"><constant> - V4L2_CID_AUTO_FOCUS_AREA</constant></link> control.</para> + <para>Support for frequency band enumeration: &VIDIOC-ENUM-FREQ-BANDS; ioctl.</para> </listitem> <listitem> - <para>Support for frequency band enumeration: &VIDIOC-ENUM-FREQ-BANDS; ioctl.</para> + <para>Vendor and device specific media bus pixel formats. + <xref linkend="v4l2-mbus-vendor-spec-fmts" />.</para> </listitem> </itemizedlist> </section> diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index b0964fb4e834..7fe5be1d3bbb 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -1586,7 +1586,6 @@ frame counter of the frame that is currently displayed (decoded). This value is the decoder is started.</entry> </row> - <row><entry></entry></row> <row> <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_DECODER_SLICE_INTERFACE</constant> </entry> @@ -2270,6 +2269,14 @@ Applicable to the MPEG1, MPEG2, MPEG4 encoders.</entry> </row> <row><entry></entry></row> + <row id="v4l2-mpeg-video-vbv-delay"> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VBV_DELAY</constant> </entry> + <entry>integer</entry> + </row><row><entry spanname="descr">Sets the initial delay in milliseconds for +VBV buffer control.</entry> + </row> + + <row><entry></entry></row> <row> <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE</constant> </entry> <entry>integer</entry> @@ -2334,6 +2341,265 @@ Applicable to the MPEG4 decoder.</entry> </row><row><entry spanname="descr">vop_time_increment value for MPEG4. Applicable to the MPEG4 encoder.</entry> </row> + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_SEI_FRAME_PACKING</constant> </entry> + <entry>boolean</entry> + </row> + <row><entry spanname="descr">Enable generation of frame packing supplemental enhancement information in the encoded bitstream. +The frame packing SEI message contains the arrangement of L and R planes for 3D viewing. Applicable to the H264 encoder.</entry> + </row> + + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_SEI_FP_CURRENT_FRAME_0</constant> </entry> + <entry>boolean</entry> + </row> + <row><entry spanname="descr">Sets current frame as frame0 in frame packing SEI. +Applicable to the H264 encoder.</entry> + </row> + + <row><entry></entry></row> + <row id="v4l2-mpeg-video-h264-sei-fp-arrangement-type"> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE</constant> </entry> + <entry>enum v4l2_mpeg_video_h264_sei_fp_arrangement_type</entry> + </row> + <row><entry spanname="descr">Frame packing arrangement type for H264 SEI. +Applicable to the H264 encoder. +Possible values are:</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_CHEKERBOARD</constant> </entry> + <entry>Pixels are alternatively from L and R.</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_COLUMN</constant> </entry> + <entry>L and R are interlaced by column.</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_ROW</constant> </entry> + <entry>L and R are interlaced by row.</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_SIDE_BY_SIDE</constant> </entry> + <entry>L is on the left, R on the right.</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_TOP_BOTTOM</constant> </entry> + <entry>L is on top, R on bottom.</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_TEMPORAL</constant> </entry> + <entry>One view per frame.</entry> + </row> + </tbody> + </entrytbl> + </row> + + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_FMO</constant> </entry> + <entry>boolean</entry> + </row> + <row><entry spanname="descr">Enables flexible macroblock ordering in the encoded bitstream. It is a technique +used for restructuring the ordering of macroblocks in pictures. Applicable to the H264 encoder.</entry> + </row> + + <row><entry></entry></row> + <row id="v4l2-mpeg-video-h264-fmo-map-type"> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_FMO_MAP_TYPE</constant> </entry> + <entry>enum v4l2_mpeg_video_h264_fmo_map_type</entry> + </row> + <row><entry spanname="descr">When using FMO, the map type divides the image in different scan patterns of macroblocks. +Applicable to the H264 encoder. +Possible values are:</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_INTERLEAVED_SLICES</constant> </entry> + <entry>Slices are interleaved one after other with macroblocks in run length order.</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_SCATTERED_SLICES</constant> </entry> + <entry>Scatters the macroblocks based on a mathematical function known to both encoder and decoder.</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_FOREGROUND_WITH_LEFT_OVER</constant> </entry> + <entry>Macroblocks arranged in rectangular areas or regions of interest.</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_BOX_OUT</constant> </entry> + <entry>Slice groups grow in a cyclic way from centre to outwards.</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_RASTER_SCAN</constant> </entry> + <entry>Slice groups grow in raster scan pattern from left to right.</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_WIPE_SCAN</constant> </entry> + <entry>Slice groups grow in wipe scan pattern from top to bottom.</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_EXPLICIT</constant> </entry> + <entry>User defined map type.</entry> + </row> + </tbody> + </entrytbl> + </row> + + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_FMO_SLICE_GROUP</constant> </entry> + <entry>integer</entry> + </row> + <row><entry spanname="descr">Number of slice groups in FMO. +Applicable to the H264 encoder.</entry> + </row> + + <row><entry></entry></row> + <row id="v4l2-mpeg-video-h264-fmo-change-direction"> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_FMO_CHANGE_DIRECTION</constant> </entry> + <entry>enum v4l2_mpeg_video_h264_fmo_change_dir</entry> + </row> + <row><entry spanname="descr">Specifies a direction of the slice group change for raster and wipe maps. +Applicable to the H264 encoder. +Possible values are:</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_MPEG_VIDEO_H264_FMO_CHANGE_DIR_RIGHT</constant> </entry> + <entry>Raster scan or wipe right.</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_VIDEO_H264_FMO_CHANGE_DIR_LEFT</constant> </entry> + <entry>Reverse raster scan or wipe left.</entry> + </row> + </tbody> + </entrytbl> + </row> + + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_FMO_CHANGE_RATE</constant> </entry> + <entry>integer</entry> + </row> + <row><entry spanname="descr">Specifies the size of the first slice group for raster and wipe map. +Applicable to the H264 encoder.</entry> + </row> + + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_FMO_RUN_LENGTH</constant> </entry> + <entry>integer</entry> + </row> + <row><entry spanname="descr">Specifies the number of consecutive macroblocks for the interleaved map. +Applicable to the H264 encoder.</entry> + </row> + + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_ASO</constant> </entry> + <entry>boolean</entry> + </row> + <row><entry spanname="descr">Enables arbitrary slice ordering in encoded bitstream. +Applicable to the H264 encoder.</entry> + </row> + + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_ASO_SLICE_ORDER</constant> </entry> + <entry>integer</entry> + </row><row><entry spanname="descr">Specifies the slice order in ASO. Applicable to the H264 encoder. +The supplied 32-bit integer is interpreted as follows (bit +0 = least significant bit):</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry>Bit 0:15</entry> + <entry>Slice ID</entry> + </row> + <row> + <entry>Bit 16:32</entry> + <entry>Slice position or order</entry> + </row> + </tbody> + </entrytbl> + </row> + + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING</constant> </entry> + <entry>boolean</entry> + </row> + <row><entry spanname="descr">Enables H264 hierarchical coding. +Applicable to the H264 encoder.</entry> + </row> + + <row><entry></entry></row> + <row id="v4l2-mpeg-video-h264-hierarchical-coding-type"> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_TYPE</constant> </entry> + <entry>enum v4l2_mpeg_video_h264_hierarchical_coding_type</entry> + </row> + <row><entry spanname="descr">Specifies the hierarchical coding type. +Applicable to the H264 encoder. +Possible values are:</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_MPEG_VIDEO_H264_HIERARCHICAL_CODING_B</constant> </entry> + <entry>Hierarchical B coding.</entry> + </row> + <row> + <entry><constant>V4L2_MPEG_VIDEO_H264_HIERARCHICAL_CODING_P</constant> </entry> + <entry>Hierarchical P coding.</entry> + </row> + </tbody> + </entrytbl> + </row> + + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_LAYER</constant> </entry> + <entry>integer</entry> + </row> + <row><entry spanname="descr">Specifies the number of hierarchical coding layers. +Applicable to the H264 encoder.</entry> + </row> + + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_LAYER_QP</constant> </entry> + <entry>integer</entry> + </row><row><entry spanname="descr">Specifies a user defined QP for each layer. Applicable to the H264 encoder. +The supplied 32-bit integer is interpreted as follows (bit +0 = least significant bit):</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry>Bit 0:15</entry> + <entry>QP value</entry> + </row> + <row> + <entry>Bit 16:32</entry> + <entry>Layer number</entry> + </row> + </tbody> + </entrytbl> + </row> + </tbody> </tgroup> </table> @@ -3505,7 +3771,7 @@ This encodes up to 31 pre-defined programme types.</entry> </row> <row><entry spanname="descr">Sets the Programme Service name (PS_NAME) for transmission. It is intended for static display on a receiver. It is the primary aid to listeners in programme service -identification and selection. In Annex E of <xref linkend="en50067" />, the RDS specification, +identification and selection. In Annex E of <xref linkend="iec62106" />, the RDS specification, there is a full description of the correct character encoding for Programme Service name strings. Also from RDS specification, PS is usually a single eight character text. However, it is also possible to find receivers which can scroll strings sized as 8 x N characters. So, this control must be configured @@ -3519,7 +3785,7 @@ with steps of 8 characters. The result is it must always contain a string with s what is being broadcasted. RDS Radio Text can be applied when broadcaster wishes to transmit longer PS names, programme-related information or any other text. In these cases, RadioText should be used in addition to <constant>V4L2_CID_RDS_TX_PS_NAME</constant>. The encoding for Radio Text strings is also fully described -in Annex E of <xref linkend="en50067" />. The length of Radio Text strings depends on which RDS Block is being +in Annex E of <xref linkend="iec62106" />. The length of Radio Text strings depends on which RDS Block is being used to transmit it, either 32 (2A block) or 64 (2B block). However, it is also possible to find receivers which can scroll strings sized as 32 x N or 64 x N characters. So, this control must be configured with steps of 32 or 64 characters. The result is it must always contain a string with size multiple of 32 or 64. </entry> @@ -3650,7 +3916,7 @@ manually or automatically if set to zero. Unit, range and step are driver-specif </table> <para>For more details about RDS specification, refer to -<xref linkend="en50067" /> document, from CENELEC.</para> +<xref linkend="iec62106" /> document, from CENELEC.</para> </section> <section id="flash-controls"> @@ -3717,232 +3983,231 @@ interface and may change in the future.</para> use case involving camera or individually. </para> - </section> + <table pgwide="1" frame="none" id="flash-control-id"> + <title>Flash Control IDs</title> + + <tgroup cols="4"> + <colspec colname="c1" colwidth="1*" /> + <colspec colname="c2" colwidth="6*" /> + <colspec colname="c3" colwidth="2*" /> + <colspec colname="c4" colwidth="6*" /> + <spanspec namest="c1" nameend="c2" spanname="id" /> + <spanspec namest="c2" nameend="c4" spanname="descr" /> + <thead> + <row> + <entry spanname="id" align="left">ID</entry> + <entry align="left">Type</entry> + </row><row rowsep="1"><entry spanname="descr" align="left">Description</entry> + </row> + </thead> + <tbody valign="top"> + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_FLASH_CLASS</constant></entry> + <entry>class</entry> + </row> + <row> + <entry spanname="descr">The FLASH class descriptor.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_FLASH_LED_MODE</constant></entry> + <entry>menu</entry> + </row> + <row id="v4l2-flash-led-mode"> + <entry spanname="descr">Defines the mode of the flash LED, + the high-power white LED attached to the flash controller. + Setting this control may not be possible in presence of + some faults. See V4L2_CID_FLASH_FAULT.</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_FLASH_LED_MODE_NONE</constant></entry> + <entry>Off.</entry> + </row> + <row> + <entry><constant>V4L2_FLASH_LED_MODE_FLASH</constant></entry> + <entry>Flash mode.</entry> + </row> + <row> + <entry><constant>V4L2_FLASH_LED_MODE_TORCH</constant></entry> + <entry>Torch mode. See V4L2_CID_FLASH_TORCH_INTENSITY.</entry> + </row> + </tbody> + </entrytbl> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_FLASH_STROBE_SOURCE</constant></entry> + <entry>menu</entry> + </row> + <row id="v4l2-flash-strobe-source"><entry + spanname="descr">Defines the source of the flash LED + strobe.</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_FLASH_STROBE_SOURCE_SOFTWARE</constant></entry> + <entry>The flash strobe is triggered by using + the V4L2_CID_FLASH_STROBE control.</entry> + </row> + <row> + <entry><constant>V4L2_FLASH_STROBE_SOURCE_EXTERNAL</constant></entry> + <entry>The flash strobe is triggered by an + external source. Typically this is a sensor, + which makes it possible to synchronises the + flash strobe start to exposure start.</entry> + </row> + </tbody> + </entrytbl> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_FLASH_STROBE</constant></entry> + <entry>button</entry> + </row> + <row> + <entry spanname="descr">Strobe flash. Valid when + V4L2_CID_FLASH_LED_MODE is set to + V4L2_FLASH_LED_MODE_FLASH and V4L2_CID_FLASH_STROBE_SOURCE + is set to V4L2_FLASH_STROBE_SOURCE_SOFTWARE. Setting this + control may not be possible in presence of some faults. + See V4L2_CID_FLASH_FAULT.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_FLASH_STROBE_STOP</constant></entry> + <entry>button</entry> + </row> + <row><entry spanname="descr">Stop flash strobe immediately.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_FLASH_STROBE_STATUS</constant></entry> + <entry>boolean</entry> + </row> + <row> + <entry spanname="descr">Strobe status: whether the flash + is strobing at the moment or not. This is a read-only + control.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_FLASH_TIMEOUT</constant></entry> + <entry>integer</entry> + </row> + <row> + <entry spanname="descr">Hardware timeout for flash. The + flash strobe is stopped after this period of time has + passed from the start of the strobe.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_FLASH_INTENSITY</constant></entry> + <entry>integer</entry> + </row> + <row> + <entry spanname="descr">Intensity of the flash strobe when + the flash LED is in flash mode + (V4L2_FLASH_LED_MODE_FLASH). The unit should be milliamps + (mA) if possible.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_FLASH_TORCH_INTENSITY</constant></entry> + <entry>integer</entry> + </row> + <row> + <entry spanname="descr">Intensity of the flash LED in + torch mode (V4L2_FLASH_LED_MODE_TORCH). The unit should be + milliamps (mA) if possible. Setting this control may not + be possible in presence of some faults. See + V4L2_CID_FLASH_FAULT.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_FLASH_INDICATOR_INTENSITY</constant></entry> + <entry>integer</entry> + </row> + <row> + <entry spanname="descr">Intensity of the indicator LED. + The indicator LED may be fully independent of the flash + LED. The unit should be microamps (uA) if possible.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_FLASH_FAULT</constant></entry> + <entry>bitmask</entry> + </row> + <row> + <entry spanname="descr">Faults related to the flash. The + faults tell about specific problems in the flash chip + itself or the LEDs attached to it. Faults may prevent + further use of some of the flash controls. In particular, + V4L2_CID_FLASH_LED_MODE is set to V4L2_FLASH_LED_MODE_NONE + if the fault affects the flash LED. Exactly which faults + have such an effect is chip dependent. Reading the faults + resets the control and returns the chip to a usable state + if possible.</entry> + </row> + <row> + <entrytbl spanname="descr" cols="2"> + <tbody valign="top"> + <row> + <entry><constant>V4L2_FLASH_FAULT_OVER_VOLTAGE</constant></entry> + <entry>Flash controller voltage to the flash LED + has exceeded the limit specific to the flash + controller.</entry> + </row> + <row> + <entry><constant>V4L2_FLASH_FAULT_TIMEOUT</constant></entry> + <entry>The flash strobe was still on when + the timeout set by the user --- + V4L2_CID_FLASH_TIMEOUT control --- has expired. + Not all flash controllers may set this in all + such conditions.</entry> + </row> + <row> + <entry><constant>V4L2_FLASH_FAULT_OVER_TEMPERATURE</constant></entry> + <entry>The flash controller has overheated.</entry> + </row> + <row> + <entry><constant>V4L2_FLASH_FAULT_SHORT_CIRCUIT</constant></entry> + <entry>The short circuit protection of the flash + controller has been triggered.</entry> + </row> + <row> + <entry><constant>V4L2_FLASH_FAULT_OVER_CURRENT</constant></entry> + <entry>Current in the LED power supply has exceeded the limit + specific to the flash controller.</entry> + </row> + <row> + <entry><constant>V4L2_FLASH_FAULT_INDICATOR</constant></entry> + <entry>The flash controller has detected a short or open + circuit condition on the indicator LED.</entry> + </row> + </tbody> + </entrytbl> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_FLASH_CHARGE</constant></entry> + <entry>boolean</entry> + </row> + <row><entry spanname="descr">Enable or disable charging of the xenon + flash capacitor.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_FLASH_READY</constant></entry> + <entry>boolean</entry> + </row> + <row> + <entry spanname="descr">Is the flash ready to strobe? + Xenon flashes require their capacitors charged before + strobing. LED flashes often require a cooldown period + after strobe during which another strobe will not be + possible. This is a read-only control.</entry> + </row> + <row><entry></entry></row> + </tbody> + </tgroup> + </table> + </section> </section> - - <table pgwide="1" frame="none" id="flash-control-id"> - <title>Flash Control IDs</title> - - <tgroup cols="4"> - <colspec colname="c1" colwidth="1*" /> - <colspec colname="c2" colwidth="6*" /> - <colspec colname="c3" colwidth="2*" /> - <colspec colname="c4" colwidth="6*" /> - <spanspec namest="c1" nameend="c2" spanname="id" /> - <spanspec namest="c2" nameend="c4" spanname="descr" /> - <thead> - <row> - <entry spanname="id" align="left">ID</entry> - <entry align="left">Type</entry> - </row><row rowsep="1"><entry spanname="descr" align="left">Description</entry> - </row> - </thead> - <tbody valign="top"> - <row><entry></entry></row> - <row> - <entry spanname="id"><constant>V4L2_CID_FLASH_CLASS</constant></entry> - <entry>class</entry> - </row> - <row> - <entry spanname="descr">The FLASH class descriptor.</entry> - </row> - <row> - <entry spanname="id"><constant>V4L2_CID_FLASH_LED_MODE</constant></entry> - <entry>menu</entry> - </row> - <row id="v4l2-flash-led-mode"> - <entry spanname="descr">Defines the mode of the flash LED, - the high-power white LED attached to the flash controller. - Setting this control may not be possible in presence of - some faults. See V4L2_CID_FLASH_FAULT.</entry> - </row> - <row> - <entrytbl spanname="descr" cols="2"> - <tbody valign="top"> - <row> - <entry><constant>V4L2_FLASH_LED_MODE_NONE</constant></entry> - <entry>Off.</entry> - </row> - <row> - <entry><constant>V4L2_FLASH_LED_MODE_FLASH</constant></entry> - <entry>Flash mode.</entry> - </row> - <row> - <entry><constant>V4L2_FLASH_LED_MODE_TORCH</constant></entry> - <entry>Torch mode. See V4L2_CID_FLASH_TORCH_INTENSITY.</entry> - </row> - </tbody> - </entrytbl> - </row> - <row> - <entry spanname="id"><constant>V4L2_CID_FLASH_STROBE_SOURCE</constant></entry> - <entry>menu</entry> - </row> - <row id="v4l2-flash-strobe-source"><entry - spanname="descr">Defines the source of the flash LED - strobe.</entry> - </row> - <row> - <entrytbl spanname="descr" cols="2"> - <tbody valign="top"> - <row> - <entry><constant>V4L2_FLASH_STROBE_SOURCE_SOFTWARE</constant></entry> - <entry>The flash strobe is triggered by using - the V4L2_CID_FLASH_STROBE control.</entry> - </row> - <row> - <entry><constant>V4L2_FLASH_STROBE_SOURCE_EXTERNAL</constant></entry> - <entry>The flash strobe is triggered by an - external source. Typically this is a sensor, - which makes it possible to synchronises the - flash strobe start to exposure start.</entry> - </row> - </tbody> - </entrytbl> - </row> - <row> - <entry spanname="id"><constant>V4L2_CID_FLASH_STROBE</constant></entry> - <entry>button</entry> - </row> - <row> - <entry spanname="descr">Strobe flash. Valid when - V4L2_CID_FLASH_LED_MODE is set to - V4L2_FLASH_LED_MODE_FLASH and V4L2_CID_FLASH_STROBE_SOURCE - is set to V4L2_FLASH_STROBE_SOURCE_SOFTWARE. Setting this - control may not be possible in presence of some faults. - See V4L2_CID_FLASH_FAULT.</entry> - </row> - <row> - <entry spanname="id"><constant>V4L2_CID_FLASH_STROBE_STOP</constant></entry> - <entry>button</entry> - </row> - <row><entry spanname="descr">Stop flash strobe immediately.</entry> - </row> - <row> - <entry spanname="id"><constant>V4L2_CID_FLASH_STROBE_STATUS</constant></entry> - <entry>boolean</entry> - </row> - <row> - <entry spanname="descr">Strobe status: whether the flash - is strobing at the moment or not. This is a read-only - control.</entry> - </row> - <row> - <entry spanname="id"><constant>V4L2_CID_FLASH_TIMEOUT</constant></entry> - <entry>integer</entry> - </row> - <row> - <entry spanname="descr">Hardware timeout for flash. The - flash strobe is stopped after this period of time has - passed from the start of the strobe.</entry> - </row> - <row> - <entry spanname="id"><constant>V4L2_CID_FLASH_INTENSITY</constant></entry> - <entry>integer</entry> - </row> - <row> - <entry spanname="descr">Intensity of the flash strobe when - the flash LED is in flash mode - (V4L2_FLASH_LED_MODE_FLASH). The unit should be milliamps - (mA) if possible.</entry> - </row> - <row> - <entry spanname="id"><constant>V4L2_CID_FLASH_TORCH_INTENSITY</constant></entry> - <entry>integer</entry> - </row> - <row> - <entry spanname="descr">Intensity of the flash LED in - torch mode (V4L2_FLASH_LED_MODE_TORCH). The unit should be - milliamps (mA) if possible. Setting this control may not - be possible in presence of some faults. See - V4L2_CID_FLASH_FAULT.</entry> - </row> - <row> - <entry spanname="id"><constant>V4L2_CID_FLASH_INDICATOR_INTENSITY</constant></entry> - <entry>integer</entry> - </row> - <row> - <entry spanname="descr">Intensity of the indicator LED. - The indicator LED may be fully independent of the flash - LED. The unit should be microamps (uA) if possible.</entry> - </row> - <row> - <entry spanname="id"><constant>V4L2_CID_FLASH_FAULT</constant></entry> - <entry>bitmask</entry> - </row> - <row> - <entry spanname="descr">Faults related to the flash. The - faults tell about specific problems in the flash chip - itself or the LEDs attached to it. Faults may prevent - further use of some of the flash controls. In particular, - V4L2_CID_FLASH_LED_MODE is set to V4L2_FLASH_LED_MODE_NONE - if the fault affects the flash LED. Exactly which faults - have such an effect is chip dependent. Reading the faults - resets the control and returns the chip to a usable state - if possible.</entry> - </row> - <row> - <entrytbl spanname="descr" cols="2"> - <tbody valign="top"> - <row> - <entry><constant>V4L2_FLASH_FAULT_OVER_VOLTAGE</constant></entry> - <entry>Flash controller voltage to the flash LED - has exceeded the limit specific to the flash - controller.</entry> - </row> - <row> - <entry><constant>V4L2_FLASH_FAULT_TIMEOUT</constant></entry> - <entry>The flash strobe was still on when - the timeout set by the user --- - V4L2_CID_FLASH_TIMEOUT control --- has expired. - Not all flash controllers may set this in all - such conditions.</entry> - </row> - <row> - <entry><constant>V4L2_FLASH_FAULT_OVER_TEMPERATURE</constant></entry> - <entry>The flash controller has overheated.</entry> - </row> - <row> - <entry><constant>V4L2_FLASH_FAULT_SHORT_CIRCUIT</constant></entry> - <entry>The short circuit protection of the flash - controller has been triggered.</entry> - </row> - <row> - <entry><constant>V4L2_FLASH_FAULT_OVER_CURRENT</constant></entry> - <entry>Current in the LED power supply has exceeded the limit - specific to the flash controller.</entry> - </row> - <row> - <entry><constant>V4L2_FLASH_FAULT_INDICATOR</constant></entry> - <entry>The flash controller has detected a short or open - circuit condition on the indicator LED.</entry> - </row> - </tbody> - </entrytbl> - </row> - <row> - <entry spanname="id"><constant>V4L2_CID_FLASH_CHARGE</constant></entry> - <entry>boolean</entry> - </row> - <row><entry spanname="descr">Enable or disable charging of the xenon - flash capacitor.</entry> - </row> - <row> - <entry spanname="id"><constant>V4L2_CID_FLASH_READY</constant></entry> - <entry>boolean</entry> - </row> - <row> - <entry spanname="descr">Is the flash ready to strobe? - Xenon flashes require their capacitors charged before - strobing. LED flashes often require a cooldown period - after strobe during which another strobe will not be - possible. This is a read-only control.</entry> - </row> - <row><entry></entry></row> - </tbody> - </tgroup> - </table> </section> <section id="jpeg-controls"> @@ -4268,6 +4533,177 @@ interface and may change in the future.</para> pixels / second. </entry> </row> + <row> + <entry spanname="id"><constant>V4L2_CID_TEST_PATTERN</constant></entry> + <entry>menu</entry> + </row> + <row id="v4l2-test-pattern"> + <entry spanname="descr"> Some capture/display/sensor devices have + the capability to generate test pattern images. These hardware + specific test patterns can be used to test if a device is working + properly.</entry> + </row> + <row><entry></entry></row> + </tbody> + </tgroup> + </table> + + </section> + + <section id="dv-controls"> + <title>Digital Video Control Reference</title> + + <note> + <title>Experimental</title> + + <para>This is an <link + linkend="experimental">experimental</link> interface and may + change in the future.</para> + </note> + + <para> + The Digital Video control class is intended to control receivers + and transmitters for <ulink url="http://en.wikipedia.org/wiki/Vga">VGA</ulink>, + <ulink url="http://en.wikipedia.org/wiki/Digital_Visual_Interface">DVI</ulink> + (Digital Visual Interface), HDMI (<xref linkend="hdmi" />) and DisplayPort (<xref linkend="dp" />). + These controls are generally expected to be private to the receiver or transmitter + subdevice that implements them, so they are only exposed on the + <filename>/dev/v4l-subdev*</filename> device node. + </para> + + <para>Note that these devices can have multiple input or output pads which are + hooked up to e.g. HDMI connectors. Even though the subdevice will receive or + transmit video from/to only one of those pads, the other pads can still be + active when it comes to EDID (Extended Display Identification Data, + <xref linkend="vesaedid" />) and HDCP (High-bandwidth Digital Content + Protection System, <xref linkend="hdcp" />) processing, allowing the device + to do the fairly slow EDID/HDCP handling in advance. This allows for quick + switching between connectors.</para> + + <para>These pads appear in several of the controls in this section as + bitmasks, one bit for each pad. Bit 0 corresponds to pad 0, bit 1 to pad 1, + etc. The maximum value of the control is the set of valid pads.</para> + + <table pgwide="1" frame="none" id="dv-control-id"> + <title>Digital Video Control IDs</title> + + <tgroup cols="4"> + <colspec colname="c1" colwidth="1*" /> + <colspec colname="c2" colwidth="6*" /> + <colspec colname="c3" colwidth="2*" /> + <colspec colname="c4" colwidth="6*" /> + <spanspec namest="c1" nameend="c2" spanname="id" /> + <spanspec namest="c2" nameend="c4" spanname="descr" /> + <thead> + <row> + <entry spanname="id" align="left">ID</entry> + <entry align="left">Type</entry> + </row><row rowsep="1"><entry spanname="descr" align="left">Description</entry> + </row> + </thead> + <tbody valign="top"> + <row><entry></entry></row> + <row> + <entry spanname="id"><constant>V4L2_CID_DV_CLASS</constant></entry> + <entry>class</entry> + </row> + <row> + <entry spanname="descr">The Digital Video class descriptor.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_DV_TX_HOTPLUG</constant></entry> + <entry>bitmask</entry> + </row> + <row> + <entry spanname="descr">Many connectors have a hotplug pin which is high + if EDID information is available from the source. This control shows the + state of the hotplug pin as seen by the transmitter. + Each bit corresponds to an output pad on the transmitter. If an output pad + does not have an associated hotplug pin, then the bit for that pad will be 0. + This read-only control is applicable to DVI-D, HDMI and DisplayPort connectors. + </entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_DV_TX_RXSENSE</constant></entry> + <entry>bitmask</entry> + </row> + <row> + <entry spanname="descr">Rx Sense is the detection of pull-ups on the TMDS + clock lines. This normally means that the sink has left/entered standby (i.e. + the transmitter can sense that the receiver is ready to receive video). + Each bit corresponds to an output pad on the transmitter. If an output pad + does not have an associated Rx Sense, then the bit for that pad will be 0. + This read-only control is applicable to DVI-D and HDMI devices. + </entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_DV_TX_EDID_PRESENT</constant></entry> + <entry>bitmask</entry> + </row> + <row> + <entry spanname="descr">When the transmitter sees the hotplug signal from the + receiver it will attempt to read the EDID. If set, then the transmitter has read + at least the first block (= 128 bytes). + Each bit corresponds to an output pad on the transmitter. If an output pad + does not support EDIDs, then the bit for that pad will be 0. + This read-only control is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors. + </entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_DV_TX_MODE</constant></entry> + <entry id="v4l2-dv-tx-mode">enum v4l2_dv_tx_mode</entry> + </row> + <row> + <entry spanname="descr">HDMI transmitters can transmit in DVI-D mode (just video) + or in HDMI mode (video + audio + auxiliary data). This control selects which mode + to use: V4L2_DV_TX_MODE_DVI_D or V4L2_DV_TX_MODE_HDMI. + This control is applicable to HDMI connectors. + </entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_DV_TX_RGB_RANGE</constant></entry> + <entry id="v4l2-dv-rgb-range">enum v4l2_dv_rgb_range</entry> + </row> + <row> + <entry spanname="descr">Select the quantization range for RGB output. V4L2_DV_RANGE_AUTO + follows the RGB quantization range specified in the standard for the video interface + (ie. <xref linkend="cea861" /> for HDMI). V4L2_DV_RANGE_LIMITED and V4L2_DV_RANGE_FULL override the standard + to be compatible with sinks that have not implemented the standard correctly + (unfortunately quite common for HDMI and DVI-D). Full range allows all possible values to be + used whereas limited range sets the range to (16 << (N-8)) - (235 << (N-8)) + where N is the number of bits per component. + This control is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors. + </entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_DV_RX_POWER_PRESENT</constant></entry> + <entry>bitmask</entry> + </row> + <row> + <entry spanname="descr">Detects whether the receiver receives power from the source + (e.g. HDMI carries 5V on one of the pins). This is often used to power an eeprom + which contains EDID information, such that the source can read the EDID even if + the sink is in standby/power off. + Each bit corresponds to an input pad on the transmitter. If an input pad + cannot detect whether power is present, then the bit for that pad will be 0. + This read-only control is applicable to DVI-D, HDMI and DisplayPort connectors. + </entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_DV_RX_RGB_RANGE</constant></entry> + <entry>enum v4l2_dv_rgb_range</entry> + </row> + <row> + <entry spanname="descr">Select the quantization range for RGB input. V4L2_DV_RANGE_AUTO + follows the RGB quantization range specified in the standard for the video interface + (ie. <xref linkend="cea861" /> for HDMI). V4L2_DV_RANGE_LIMITED and V4L2_DV_RANGE_FULL override the standard + to be compatible with sources that have not implemented the standard correctly + (unfortunately quite common for HDMI and DVI-D). Full range allows all possible values to be + used whereas limited range sets the range to (16 << (N-8)) - (235 << (N-8)) + where N is the number of bits per component. + This control is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors. + </entry> + </row> <row><entry></entry></row> </tbody> </tgroup> diff --git a/Documentation/DocBook/media/v4l/dev-osd.xml b/Documentation/DocBook/media/v4l/dev-osd.xml index 479d9433869a..dd91d6134e8c 100644 --- a/Documentation/DocBook/media/v4l/dev-osd.xml +++ b/Documentation/DocBook/media/v4l/dev-osd.xml @@ -1,13 +1,6 @@ <title>Video Output Overlay Interface</title> <subtitle>Also known as On-Screen Display (OSD)</subtitle> - <note> - <title>Experimental</title> - - <para>This is an <link linkend="experimental">experimental</link> -interface and may change in the future.</para> - </note> - <para>Some video output devices can overlay a framebuffer image onto the outgoing video signal. Applications can set up such an overlay using this interface, which borrows structures and ioctls of the <link diff --git a/Documentation/DocBook/media/v4l/dev-rds.xml b/Documentation/DocBook/media/v4l/dev-rds.xml index 38883a419e65..be2f33737323 100644 --- a/Documentation/DocBook/media/v4l/dev-rds.xml +++ b/Documentation/DocBook/media/v4l/dev-rds.xml @@ -6,7 +6,7 @@ information, on an inaudible audio subcarrier of a radio program. This interface is aimed at devices capable of receiving and/or transmitting RDS information.</para> - <para>For more information see the core RDS standard <xref linkend="en50067" /> + <para>For more information see the core RDS standard <xref linkend="iec62106" /> and the RBDS standard <xref linkend="nrsc4" />.</para> <para>Note that the RBDS standard as is used in the USA is almost identical diff --git a/Documentation/DocBook/media/v4l/dev-subdev.xml b/Documentation/DocBook/media/v4l/dev-subdev.xml index a3d9dd093268..d15aaf83f56f 100644 --- a/Documentation/DocBook/media/v4l/dev-subdev.xml +++ b/Documentation/DocBook/media/v4l/dev-subdev.xml @@ -374,29 +374,29 @@ rectangle --- if it is supported by the hardware.</para> <orderedlist> - <listitem>Sink pad format. The user configures the sink pad + <listitem><para>Sink pad format. The user configures the sink pad format. This format defines the parameters of the image the - entity receives through the pad for further processing.</listitem> + entity receives through the pad for further processing.</para></listitem> - <listitem>Sink pad actual crop selection. The sink pad crop - defines the crop performed to the sink pad format.</listitem> + <listitem><para>Sink pad actual crop selection. The sink pad crop + defines the crop performed to the sink pad format.</para></listitem> - <listitem>Sink pad actual compose selection. The size of the + <listitem><para>Sink pad actual compose selection. The size of the sink pad compose rectangle defines the scaling ratio compared to the size of the sink pad crop rectangle. The location of the compose rectangle specifies the location of the actual sink compose rectangle in the sink compose bounds - rectangle.</listitem> + rectangle.</para></listitem> - <listitem>Source pad actual crop selection. Crop on the source + <listitem><para>Source pad actual crop selection. Crop on the source pad defines crop performed to the image in the sink compose - bounds rectangle.</listitem> + bounds rectangle.</para></listitem> - <listitem>Source pad format. The source pad format defines the + <listitem><para>Source pad format. The source pad format defines the output pixel format of the subdev, as well as the other parameters with the exception of the image width and height. Width and height are defined by the size of the source pad - actual crop selection.</listitem> + actual crop selection.</para></listitem> </orderedlist> <para>Accessing any of the above rectangles not supported by the diff --git a/Documentation/DocBook/media/v4l/gen-errors.xml b/Documentation/DocBook/media/v4l/gen-errors.xml index 5bbf3ce1973a..7e29a4e1f696 100644 --- a/Documentation/DocBook/media/v4l/gen-errors.xml +++ b/Documentation/DocBook/media/v4l/gen-errors.xml @@ -7,6 +7,15 @@ <tbody valign="top"> <!-- Keep it ordered alphabetically --> <row> + <entry>EAGAIN (aka EWOULDBLOCK)</entry> + <entry>The ioctl can't be handled because the device is in state where + it can't perform it. This could happen for example in case where + device is sleeping and ioctl is performed to query statistics. + It is also returned when the ioctl would need to wait + for an event, but the device was opened in non-blocking mode. + </entry> + </row> + <row> <entry>EBADF</entry> <entry>The file descriptor is not a valid.</entry> </row> @@ -51,21 +60,11 @@ for periodic transfers (up to 80% of the USB bandwidth).</entry> </row> <row> - <entry>ENOSYS or EOPNOTSUPP</entry> - <entry>Function not available for this device (dvb API only. Will likely - be replaced anytime soon by ENOTTY).</entry> - </row> - <row> <entry>EPERM</entry> <entry>Permission denied. Can be returned if the device needs write permission, or some special capabilities is needed (e. g. root)</entry> </row> - <row> - <entry>EWOULDBLOCK</entry> - <entry>Operation would block. Used when the ioctl would need to wait - for an event, but the device was opened in non-blocking mode.</entry> - </row> </tbody> </tgroup> </table> diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 1885cc0755cb..b5d1cbdc558b 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -613,8 +613,8 @@ field is independent of the <structfield>timestamp</structfield> and <entry>__u32</entry> <entry><structfield>sequence</structfield></entry> <entry></entry> - <entry>Set by the driver, counting the frames in the -sequence.</entry> + <entry>Set by the driver, counting the frames (not fields!) in +sequence. This field is set for both input and output devices.</entry> </row> <row> <entry spanname="hspan"><para>In <link @@ -677,26 +677,24 @@ memory, set by the application. See <xref linkend="userp" /> for details. <entry><structfield>length</structfield></entry> <entry></entry> <entry>Size of the buffer (not the payload) in bytes for the - single-planar API. For the multi-planar API should contain the - number of elements in the <structfield>planes</structfield> array. + single-planar API. For the multi-planar API the application sets + this to the number of elements in the <structfield>planes</structfield> + array. The driver will fill in the actual number of valid elements in + that array. </entry> </row> <row> <entry>__u32</entry> <entry><structfield>reserved2</structfield></entry> <entry></entry> - <entry>A place holder for future extensions and custom -(driver defined) buffer types -<constant>V4L2_BUF_TYPE_PRIVATE</constant> and higher. Applications + <entry>A place holder for future extensions. Applications should set this to 0.</entry> </row> <row> <entry>__u32</entry> <entry><structfield>reserved</structfield></entry> <entry></entry> - <entry>A place holder for future extensions and custom -(driver defined) buffer types -<constant>V4L2_BUF_TYPE_PRIVATE</constant> and higher. Applications + <entry>A place holder for future extensions. Applications should set this to 0.</entry> </row> </tbody> @@ -827,14 +825,7 @@ should set this to 0.</entry> <entry><constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY</constant></entry> <entry>8</entry> <entry>Buffer for video output overlay (OSD), see <xref - linkend="osd" />. Status: <link -linkend="experimental">Experimental</link>.</entry> - </row> - <row> - <entry><constant>V4L2_BUF_TYPE_PRIVATE</constant></entry> - <entry>0x80</entry> - <entry>This and higher values are reserved for custom -(driver defined) buffer types.</entry> + linkend="osd" />.</entry> </row> </tbody> </tgroup> diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml b/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml index 5274c24d11e0..a990b34d911a 100644 --- a/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml +++ b/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml @@ -1,11 +1,13 @@ - <refentry id="V4L2-PIX-FMT-NV12M"> + <refentry> <refmeta> - <refentrytitle>V4L2_PIX_FMT_NV12M ('NM12')</refentrytitle> + <refentrytitle>V4L2_PIX_FMT_NV12M ('NM12'), V4L2_PIX_FMT_NV21M ('NM21'), V4L2_PIX_FMT_NV12MT_16X16</refentrytitle> &manvol; </refmeta> <refnamediv> - <refname> <constant>V4L2_PIX_FMT_NV12M</constant></refname> - <refpurpose>Variation of <constant>V4L2_PIX_FMT_NV12</constant> with planes + <refname id="V4L2-PIX-FMT-NV12M"><constant>V4L2_PIX_FMT_NV12M</constant></refname> + <refname id="V4L2-PIX-FMT-NV21M"><constant>V4L2_PIX_FMT_NV21M</constant></refname> + <refname id="V4L2-PIX-FMT-NV12MT_16X16"><constant>V4L2_PIX_FMT_NV12MT_16X16</constant></refname> + <refpurpose>Variation of <constant>V4L2_PIX_FMT_NV12</constant> and <constant>V4L2_PIX_FMT_NV21</constant> with planes non contiguous in memory. </refpurpose> </refnamediv> <refsect1> @@ -22,7 +24,12 @@ The CbCr plane is the same width, in bytes, as the Y plane (and of the image), but is half as tall in pixels. Each CbCr pair belongs to four pixels. For example, Cb<subscript>0</subscript>/Cr<subscript>0</subscript> belongs to Y'<subscript>00</subscript>, Y'<subscript>01</subscript>, -Y'<subscript>10</subscript>, Y'<subscript>11</subscript>. </para> +Y'<subscript>10</subscript>, Y'<subscript>11</subscript>. +<constant>V4L2_PIX_FMT_NV12MT_16X16</constant> is the tiled version of +<constant>V4L2_PIX_FMT_NV12M</constant> with 16x16 macroblock tiles. Here pixels +are arranged in 16x16 2D tiles and tiles are arranged in linear order in memory. +<constant>V4L2_PIX_FMT_NV21M</constant> is the same as <constant>V4L2_PIX_FMT_NV12M</constant> +except the Cb and Cr bytes are swapped, the CrCb plane starts with a Cr byte.</para> <para><constant>V4L2_PIX_FMT_NV12M</constant> is intended to be used only in drivers and applications that support the multi-planar API, diff --git a/Documentation/DocBook/media/v4l/pixfmt-srggb10dpcm8.xml b/Documentation/DocBook/media/v4l/pixfmt-srggb10dpcm8.xml index 8eace3e2e7d4..2d3f0b1aefe0 100644 --- a/Documentation/DocBook/media/v4l/pixfmt-srggb10dpcm8.xml +++ b/Documentation/DocBook/media/v4l/pixfmt-srggb10dpcm8.xml @@ -22,8 +22,7 @@ with 10 bits per colour compressed to 8 bits each, using DPCM compression. DPCM, differential pulse-code modulation, is lossy. Each colour component consumes 8 bits of memory. In other respects - this format is similar to <xref - linkend="pixfmt-srggb10">.</xref></para> + this format is similar to <xref linkend="pixfmt-srggb10" />.</para> </refsect1> </refentry> diff --git a/Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml b/Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml new file mode 100644 index 000000000000..2330667907c7 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-yvu420m.xml @@ -0,0 +1,154 @@ + <refentry id="V4L2-PIX-FMT-YVU420M"> + <refmeta> + <refentrytitle>V4L2_PIX_FMT_YVU420M ('YM21')</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname> <constant>V4L2_PIX_FMT_YVU420M</constant></refname> + <refpurpose>Variation of <constant>V4L2_PIX_FMT_YVU420</constant> + with planes non contiguous in memory. </refpurpose> + </refnamediv> + + <refsect1> + <title>Description</title> + + <para>This is a multi-planar format, as opposed to a packed format. +The three components are separated into three sub-images or planes. + +The Y plane is first. The Y plane has one byte per pixel. The Cr data +constitutes the second plane which is half the width and half +the height of the Y plane (and of the image). Each Cr belongs to four +pixels, a two-by-two square of the image. For example, +Cr<subscript>0</subscript> belongs to Y'<subscript>00</subscript>, +Y'<subscript>01</subscript>, Y'<subscript>10</subscript>, and +Y'<subscript>11</subscript>. The Cb data, just like the Cr plane, constitutes +the third plane. </para> + + <para>If the Y plane has pad bytes after each row, then the Cr +and Cb planes have half as many pad bytes after their rows. In other +words, two Cx rows (including padding) is exactly as long as one Y row +(including padding).</para> + + <para><constant>V4L2_PIX_FMT_YVU420M</constant> is intended to be +used only in drivers and applications that support the multi-planar API, +described in <xref linkend="planar-apis"/>. </para> + + <example> + <title><constant>V4L2_PIX_FMT_YVU420M</constant> 4 × 4 +pixel image</title> + + <formalpara> + <title>Byte Order.</title> + <para>Each cell is one byte. + <informaltable frame="none"> + <tgroup cols="5" align="center"> + <colspec align="left" colwidth="2*" /> + <tbody valign="top"> + <row> + <entry>start0 + 0:</entry> + <entry>Y'<subscript>00</subscript></entry> + <entry>Y'<subscript>01</subscript></entry> + <entry>Y'<subscript>02</subscript></entry> + <entry>Y'<subscript>03</subscript></entry> + </row> + <row> + <entry>start0 + 4:</entry> + <entry>Y'<subscript>10</subscript></entry> + <entry>Y'<subscript>11</subscript></entry> + <entry>Y'<subscript>12</subscript></entry> + <entry>Y'<subscript>13</subscript></entry> + </row> + <row> + <entry>start0 + 8:</entry> + <entry>Y'<subscript>20</subscript></entry> + <entry>Y'<subscript>21</subscript></entry> + <entry>Y'<subscript>22</subscript></entry> + <entry>Y'<subscript>23</subscript></entry> + </row> + <row> + <entry>start0 + 12:</entry> + <entry>Y'<subscript>30</subscript></entry> + <entry>Y'<subscript>31</subscript></entry> + <entry>Y'<subscript>32</subscript></entry> + <entry>Y'<subscript>33</subscript></entry> + </row> + <row><entry></entry></row> + <row> + <entry>start1 + 0:</entry> + <entry>Cr<subscript>00</subscript></entry> + <entry>Cr<subscript>01</subscript></entry> + </row> + <row> + <entry>start1 + 2:</entry> + <entry>Cr<subscript>10</subscript></entry> + <entry>Cr<subscript>11</subscript></entry> + </row> + <row><entry></entry></row> + <row> + <entry>start2 + 0:</entry> + <entry>Cb<subscript>00</subscript></entry> + <entry>Cb<subscript>01</subscript></entry> + </row> + <row> + <entry>start2 + 2:</entry> + <entry>Cb<subscript>10</subscript></entry> + <entry>Cb<subscript>11</subscript></entry> + </row> + </tbody> + </tgroup> + </informaltable> + </para> + </formalpara> + + <formalpara> + <title>Color Sample Location.</title> + <para> + <informaltable frame="none"> + <tgroup cols="7" align="center"> + <tbody valign="top"> + <row> + <entry></entry> + <entry>0</entry><entry></entry><entry>1</entry><entry></entry> + <entry>2</entry><entry></entry><entry>3</entry> + </row> + <row> + <entry>0</entry> + <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry></entry><entry>Y</entry> + </row> + <row> + <entry></entry> + <entry></entry><entry>C</entry><entry></entry><entry></entry> + <entry></entry><entry>C</entry><entry></entry> + </row> + <row> + <entry>1</entry> + <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry></entry><entry>Y</entry> + </row> + <row> + <entry></entry> + </row> + <row> + <entry>2</entry> + <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry></entry><entry>Y</entry> + </row> + <row> + <entry></entry> + <entry></entry><entry>C</entry><entry></entry><entry></entry> + <entry></entry><entry>C</entry><entry></entry> + </row> + <row> + <entry>3</entry> + <entry>Y</entry><entry></entry><entry>Y</entry><entry></entry> + <entry>Y</entry><entry></entry><entry>Y</entry> + </row> + </tbody> + </tgroup> + </informaltable> + </para> + </formalpara> + </example> + </refsect1> + </refentry> diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml index e58934c92895..bf94f417592c 100644 --- a/Documentation/DocBook/media/v4l/pixfmt.xml +++ b/Documentation/DocBook/media/v4l/pixfmt.xml @@ -708,6 +708,7 @@ information.</para> &sub-y41p; &sub-yuv420; &sub-yuv420m; + &sub-yvu420m; &sub-yuv410; &sub-yuv422p; &sub-yuv411p; @@ -757,6 +758,11 @@ extended control <constant>V4L2_CID_MPEG_STREAM_TYPE</constant>, see <entry>'AVC1'</entry> <entry>H264 video elementary stream without start codes.</entry> </row> + <row id="V4L2-PIX-FMT-H264-MVC"> + <entry><constant>V4L2_PIX_FMT_H264_MVC</constant></entry> + <entry>'MVC'</entry> + <entry>H264 MVC video elementary stream.</entry> + </row> <row id="V4L2-PIX-FMT-H263"> <entry><constant>V4L2_PIX_FMT_H263</constant></entry> <entry>'H263'</entry> @@ -792,6 +798,11 @@ extended control <constant>V4L2_CID_MPEG_STREAM_TYPE</constant>, see <entry>'VC1L'</entry> <entry>VC1, SMPTE 421M Annex L compliant stream.</entry> </row> + <row id="V4L2-PIX-FMT-VP8"> + <entry><constant>V4L2_PIX_FMT_VP8</constant></entry> + <entry>'VP8'</entry> + <entry>VP8 video elementary stream.</entry> + </row> </tbody> </tgroup> </table> @@ -995,6 +1006,34 @@ the other bits are set to 0.</entry> <entry>Old 6-bit greyscale format. Only the most significant 6 bits of each byte are used, the other bits are set to 0.</entry> </row> + <row id="V4L2-PIX-FMT-S5C-UYVY-JPG"> + <entry><constant>V4L2_PIX_FMT_S5C_UYVY_JPG</constant></entry> + <entry>'S5CI'</entry> + <entry>Two-planar format used by Samsung S5C73MX cameras. The +first plane contains interleaved JPEG and UYVY image data, followed by meta data +in form of an array of offsets to the UYVY data blocks. The actual pointer array +follows immediately the interleaved JPEG/UYVY data, the number of entries in +this array equals the height of the UYVY image. Each entry is a 4-byte unsigned +integer in big endian order and it's an offset to a single pixel line of the +UYVY image. The first plane can start either with JPEG or UYVY data chunk. The +size of a single UYVY block equals the UYVY image's width multiplied by 2. The +size of a JPEG chunk depends on the image and can vary with each line. +<para>The second plane, at an offset of 4084 bytes, contains a 4-byte offset to +the pointer array in the first plane. This offset is followed by a 4-byte value +indicating size of the pointer array. All numbers in the second plane are also +in big endian order. Remaining data in the second plane is undefined. The +information in the second plane allows to easily find location of the pointer +array, which can be different for each frame. The size of the pointer array is +constant for given UYVY image height.</para> +<para>In order to extract UYVY and JPEG frames an application can initially set +a data pointer to the start of first plane and then add an offset from the first +entry of the pointers table. Such a pointer indicates start of an UYVY image +pixel line. Whole UYVY line can be copied to a separate buffer. These steps +should be repeated for each line, i.e. the number of entries in the pointer +array. Anything what's in between the UYVY lines is JPEG data and should be +concatenated to form the JPEG stream. </para> +</entry> + </row> </tbody> </tgroup> </table> diff --git a/Documentation/DocBook/media/v4l/selection-api.xml b/Documentation/DocBook/media/v4l/selection-api.xml index e7ed5077834d..4c238ce068b0 100644 --- a/Documentation/DocBook/media/v4l/selection-api.xml +++ b/Documentation/DocBook/media/v4l/selection-api.xml @@ -40,6 +40,7 @@ cropping and composing rectangles have the same size.</para> <section> <title>Selection targets</title> + <para> <figure id="sel-targets-capture"> <title>Cropping and composing targets</title> <mediaobject> @@ -52,12 +53,12 @@ cropping and composing rectangles have the same size.</para> </textobject> </mediaobject> </figure> + </para> + <para>See <xref linkend="v4l2-selection-targets" /> for more + information.</para> </section> - See <xref linkend="v4l2-selection-targets" /> for more - information. - <section> <title>Configuration</title> @@ -216,18 +217,17 @@ composing and cropping operations by setting the appropriate targets. The V4L2 API lacks any support for composing to and cropping from an image inside a memory buffer. The application could configure a capture device to fill only a part of an image by abusing V4L2 API. Cropping a smaller image from a larger -one is achieved by setting the field <structfield> -&v4l2-pix-format;::bytesperline </structfield>. Introducing an image offsets -could be done by modifying field <structfield> &v4l2-buffer;::m:userptr -</structfield> before calling <constant> VIDIOC_QBUF </constant>. Those +one is achieved by setting the field +&v4l2-pix-format;<structfield>::bytesperline</structfield>. Introducing an image offsets +could be done by modifying field &v4l2-buffer;<structfield>::m_userptr</structfield> +before calling <constant> VIDIOC_QBUF </constant>. Those operations should be avoided because they are not portable (endianness), and do not work for macroblock and Bayer formats and mmap buffers. The selection API deals with configuration of buffer cropping/composing in a clear, intuitive and portable way. Next, with the selection API the concepts of the padded target -and constraints flags are introduced. Finally, <structname> &v4l2-crop; -</structname> and <structname> &v4l2-cropcap; </structname> have no reserved -fields. Therefore there is no way to extend their functionality. The new -<structname> &v4l2-selection; </structname> provides a lot of place for future +and constraints flags are introduced. Finally, &v4l2-crop; and &v4l2-cropcap; +have no reserved fields. Therefore there is no way to extend their functionality. +The new &v4l2-selection; provides a lot of place for future extensions. Driver developers are encouraged to implement only selection API. The former cropping API would be simulated using the new one. </para> diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 49c532ebbbbe..a0a936455fae 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -2565,5 +2565,49 @@ </tgroup> </table> </section> + + <section id="v4l2-mbus-vendor-spec-fmts"> + <title>Vendor and Device Specific Formats</title> + + <note> + <title>Experimental</title> + <para>This is an <link linkend="experimental">experimental</link> +interface and may change in the future.</para> + </note> + + <para>This section lists complex data formats that are either vendor or + device specific. + </para> + + <para>The following table lists the existing vendor and device specific + formats.</para> + + <table pgwide="0" frame="none" id="v4l2-mbus-pixelcode-vendor-specific"> + <title>Vendor and device specific formats</title> + <tgroup cols="3"> + <colspec colname="id" align="left" /> + <colspec colname="code" align="left"/> + <colspec colname="remarks" align="left"/> + <thead> + <row> + <entry>Identifier</entry> + <entry>Code</entry> + <entry>Comments</entry> + </row> + </thead> + <tbody valign="top"> + <row id="V4L2-MBUS-FMT-S5C-UYVY-JPEG-1X8"> + <entry>V4L2_MBUS_FMT_S5C_UYVY_JPEG_1X8</entry> + <entry>0x5001</entry> + <entry> + Interleaved raw UYVY and JPEG image format with embedded + meta-data used by Samsung S3C73MX camera sensors. + </entry> + </row> + </tbody> + </tgroup> + </table> + </section> + </section> </section> diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index eee6908c749f..10ccde9d16d0 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -145,9 +145,12 @@ applications. --> <authorinitials>hv</authorinitials> <revremark>Added VIDIOC_ENUM_FREQ_BANDS. </revremark> + </revision> + + <revision> <revnumber>3.5</revnumber> <date>2012-05-07</date> - <authorinitials>sa, sn</authorinitials> + <authorinitials>sa, sn, hv</authorinitials> <revremark>Added V4L2_CTRL_TYPE_INTEGER_MENU and V4L2 subdev selections API. Improved the description of V4L2_CID_COLORFX control, added V4L2_CID_COLORFX_CBCR control. @@ -158,11 +161,8 @@ applications. --> V4L2_CID_3A_LOCK, V4L2_CID_AUTO_FOCUS_START, V4L2_CID_AUTO_FOCUS_STOP, V4L2_CID_AUTO_FOCUS_STATUS and V4L2_CID_AUTO_FOCUS_RANGE. - </revremark> - <date>2012-05-01</date> - <authorinitials>hv</authorinitials> - <revremark>Added VIDIOC_ENUM_DV_TIMINGS, VIDIOC_QUERY_DV_TIMINGS and - VIDIOC_DV_TIMINGS_CAP. + Added VIDIOC_ENUM_DV_TIMINGS, VIDIOC_QUERY_DV_TIMINGS and + VIDIOC_DV_TIMINGS_CAP. </revremark> </revision> @@ -472,7 +472,7 @@ and discussions on the V4L mailing list.</revremark> </partinfo> <title>Video for Linux Two API Specification</title> - <subtitle>Revision 3.5</subtitle> + <subtitle>Revision 3.6</subtitle> <chapter id="common"> &sub-common; @@ -581,6 +581,7 @@ and discussions on the V4L mailing list.</revremark> &sub-subdev-enum-frame-size; &sub-subdev-enum-mbus-code; &sub-subdev-g-crop; + &sub-subdev-g-edid; &sub-subdev-g-fmt; &sub-subdev-g-frame-interval; &sub-subdev-g-selection; diff --git a/Documentation/DocBook/media/v4l/vidioc-cropcap.xml b/Documentation/DocBook/media/v4l/vidioc-cropcap.xml index f1bac2c6e978..bf7cc979fdfa 100644 --- a/Documentation/DocBook/media/v4l/vidioc-cropcap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-cropcap.xml @@ -59,6 +59,9 @@ constant except when switching the video standard. Remember this switch can occur implicit when switching the video input or output.</para> + <para>This ioctl must be implemented for video capture or output devices that +support cropping and/or scaling and/or have non-square pixels, and for overlay devices.</para> + <table pgwide="1" frame="none" id="v4l2-cropcap"> <title>struct <structname>v4l2_cropcap</structname></title> <tgroup cols="3"> @@ -70,10 +73,10 @@ output.</para> <entry>Type of the data stream, set by the application. Only these types are valid here: <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>, +<constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>, <constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant>, -<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>, and custom (driver -defined) types with code <constant>V4L2_BUF_TYPE_PRIVATE</constant> -and higher. See <xref linkend="v4l2-buf-type" />.</entry> +<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant> and +<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>. See <xref linkend="v4l2-buf-type" />.</entry> </row> <row> <entry>struct <link linkend="v4l2-rect-crop">v4l2_rect</link></entry> @@ -156,8 +159,7 @@ on 22 Oct 2002 subject "Re:[V4L][patches!] Re:v4l2/kernel-2.5" --> <term><errorcode>EINVAL</errorcode></term> <listitem> <para>The &v4l2-cropcap; <structfield>type</structfield> is -invalid. This is not permitted for video capture, output and overlay devices, -which must support <constant>VIDIOC_CROPCAP</constant>.</para> +invalid.</para> </listitem> </varlistentry> </variablelist> diff --git a/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml index 74b87f6e480a..9215627b04c7 100644 --- a/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml +++ b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml @@ -49,13 +49,6 @@ <refsect1> <title>Description</title> - <note> - <title>Experimental</title> - - <para>This is an <link linkend="experimental">experimental</link> -interface and may change in the future.</para> - </note> - <para>These ioctls control an audio/video (usually MPEG-) decoder. <constant>VIDIOC_DECODER_CMD</constant> sends a command to the decoder, <constant>VIDIOC_TRY_DECODER_CMD</constant> can be used to diff --git a/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml b/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml index f431b3ba79bd..0619ca5d2d36 100644 --- a/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml +++ b/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml @@ -49,13 +49,6 @@ <refsect1> <title>Description</title> - <note> - <title>Experimental</title> - - <para>This is an <link linkend="experimental">experimental</link> -interface and may change in the future.</para> - </note> - <para>These ioctls control an audio/video (usually MPEG-) encoder. <constant>VIDIOC_ENCODER_CMD</constant> sends a command to the encoder, <constant>VIDIOC_TRY_ENCODER_CMD</constant> can be used to diff --git a/Documentation/DocBook/media/v4l/vidioc-enum-dv-presets.xml b/Documentation/DocBook/media/v4l/vidioc-enum-dv-presets.xml index 509f0012d2a6..fced5fb0dbf0 100644 --- a/Documentation/DocBook/media/v4l/vidioc-enum-dv-presets.xml +++ b/Documentation/DocBook/media/v4l/vidioc-enum-dv-presets.xml @@ -229,6 +229,12 @@ intended for the user.</entry> is out of bounds.</para> </listitem> </varlistentry> + <varlistentry> + <term><errorcode>ENODATA</errorcode></term> + <listitem> + <para>Digital video presets are not supported for this input or output.</para> + </listitem> + </varlistentry> </variablelist> </refsect1> </refentry> diff --git a/Documentation/DocBook/media/v4l/vidioc-enum-dv-timings.xml b/Documentation/DocBook/media/v4l/vidioc-enum-dv-timings.xml index 24c3bf4fd29a..b3e17c1dfaf5 100644 --- a/Documentation/DocBook/media/v4l/vidioc-enum-dv-timings.xml +++ b/Documentation/DocBook/media/v4l/vidioc-enum-dv-timings.xml @@ -106,6 +106,12 @@ application.</entry> is out of bounds.</para> </listitem> </varlistentry> + <varlistentry> + <term><errorcode>ENODATA</errorcode></term> + <listitem> + <para>Digital video presets are not supported for this input or output.</para> + </listitem> + </varlistentry> </variablelist> </refsect1> </refentry> diff --git a/Documentation/DocBook/media/v4l/vidioc-enum-fmt.xml b/Documentation/DocBook/media/v4l/vidioc-enum-fmt.xml index 81ebe48317fe..f8dfeed34fca 100644 --- a/Documentation/DocBook/media/v4l/vidioc-enum-fmt.xml +++ b/Documentation/DocBook/media/v4l/vidioc-enum-fmt.xml @@ -58,6 +58,9 @@ structure. Drivers fill the rest of the structure or return an incrementing by one until <errorcode>EINVAL</errorcode> is returned.</para> + <para>Note that after switching input or output the list of enumerated image +formats may be different.</para> + <table pgwide="1" frame="none" id="v4l2-fmtdesc"> <title>struct <structname>v4l2_fmtdesc</structname></title> <tgroup cols="3"> @@ -78,10 +81,8 @@ Only these types are valid here: <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>, <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE</constant>, <constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant>, -<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant>, -<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>, and custom (driver -defined) types with code <constant>V4L2_BUF_TYPE_PRIVATE</constant> -and higher. See <xref linkend="v4l2-buf-type" />.</entry> +<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE</constant> and +<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>. See <xref linkend="v4l2-buf-type" />.</entry> </row> <row> <entry>__u32</entry> diff --git a/Documentation/DocBook/media/v4l/vidioc-enum-framesizes.xml b/Documentation/DocBook/media/v4l/vidioc-enum-framesizes.xml index f77a13f486d7..a78454b5abcd 100644 --- a/Documentation/DocBook/media/v4l/vidioc-enum-framesizes.xml +++ b/Documentation/DocBook/media/v4l/vidioc-enum-framesizes.xml @@ -50,13 +50,6 @@ and pixel format and receives a frame width and height.</para> <refsect1> <title>Description</title> - <note> - <title>Experimental</title> - - <para>This is an <link linkend="experimental">experimental</link> -interface and may change in the future.</para> - </note> - <para>This ioctl allows applications to enumerate all frame sizes (&ie; width and height in pixels) that the device supports for the given pixel format.</para> diff --git a/Documentation/DocBook/media/v4l/vidioc-enuminput.xml b/Documentation/DocBook/media/v4l/vidioc-enuminput.xml index 46d5a044a537..3c9a81305ad4 100644 --- a/Documentation/DocBook/media/v4l/vidioc-enuminput.xml +++ b/Documentation/DocBook/media/v4l/vidioc-enuminput.xml @@ -283,7 +283,7 @@ input/output interface to linux-media@vger.kernel.org on 19 Oct 2009. <entry>This input supports setting DV presets by using VIDIOC_S_DV_PRESET.</entry> </row> <row> - <entry><constant>V4L2_IN_CAP_CUSTOM_TIMINGS</constant></entry> + <entry><constant>V4L2_IN_CAP_DV_TIMINGS</constant></entry> <entry>0x00000002</entry> <entry>This input supports setting video timings by using VIDIOC_S_DV_TIMINGS.</entry> </row> diff --git a/Documentation/DocBook/media/v4l/vidioc-enumoutput.xml b/Documentation/DocBook/media/v4l/vidioc-enumoutput.xml index 428020000ef0..f4ab0798545d 100644 --- a/Documentation/DocBook/media/v4l/vidioc-enumoutput.xml +++ b/Documentation/DocBook/media/v4l/vidioc-enumoutput.xml @@ -168,7 +168,7 @@ input/output interface to linux-media@vger.kernel.org on 19 Oct 2009. <entry>This output supports setting DV presets by using VIDIOC_S_DV_PRESET.</entry> </row> <row> - <entry><constant>V4L2_OUT_CAP_CUSTOM_TIMINGS</constant></entry> + <entry><constant>V4L2_OUT_CAP_DV_TIMINGS</constant></entry> <entry>0x00000002</entry> <entry>This output supports setting video timings by using VIDIOC_S_DV_TIMINGS.</entry> </row> diff --git a/Documentation/DocBook/media/v4l/vidioc-enumstd.xml b/Documentation/DocBook/media/v4l/vidioc-enumstd.xml index 3a5fc5405f96..8065099401d1 100644 --- a/Documentation/DocBook/media/v4l/vidioc-enumstd.xml +++ b/Documentation/DocBook/media/v4l/vidioc-enumstd.xml @@ -378,6 +378,12 @@ system)</para></footnote></para></entry> is out of bounds.</para> </listitem> </varlistentry> + <varlistentry> + <term><errorcode>ENODATA</errorcode></term> + <listitem> + <para>Standard video timings are not supported for this input or output.</para> + </listitem> + </varlistentry> </variablelist> </refsect1> </refentry> diff --git a/Documentation/DocBook/media/v4l/vidioc-g-crop.xml b/Documentation/DocBook/media/v4l/vidioc-g-crop.xml index c4ff3b1887fb..75c6a93de3c1 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-crop.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-crop.xml @@ -104,10 +104,8 @@ changed and <constant>VIDIOC_S_CROP</constant> returns the <entry><structfield>type</structfield></entry> <entry>Type of the data stream, set by the application. Only these types are valid here: <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant>, -<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant>, -<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>, and custom (driver -defined) types with code <constant>V4L2_BUF_TYPE_PRIVATE</constant> -and higher. See <xref linkend="v4l2-buf-type" />.</entry> +<constant>V4L2_BUF_TYPE_VIDEO_OUTPUT</constant> and +<constant>V4L2_BUF_TYPE_VIDEO_OVERLAY</constant>. See <xref linkend="v4l2-buf-type" />.</entry> </row> <row> <entry>&v4l2-rect;</entry> diff --git a/Documentation/DocBook/media/v4l/vidioc-g-dv-preset.xml b/Documentation/DocBook/media/v4l/vidioc-g-dv-preset.xml index 61be9fa3803a..b9ea37634f6c 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-dv-preset.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-dv-preset.xml @@ -78,6 +78,12 @@ If the preset is not supported, it returns an &EINVAL; </para> </listitem> </varlistentry> <varlistentry> + <term><errorcode>ENODATA</errorcode></term> + <listitem> + <para>Digital video presets are not supported for this input or output.</para> + </listitem> + </varlistentry> + <varlistentry> <term><errorcode>EBUSY</errorcode></term> <listitem> <para>The device is busy and therefore can not change the preset.</para> @@ -104,7 +110,4 @@ If the preset is not supported, it returns an &EINVAL; </para> </tgroup> </table> </refsect1> - <refsect1> - &return-value; - </refsect1> </refentry> diff --git a/Documentation/DocBook/media/v4l/vidioc-g-dv-timings.xml b/Documentation/DocBook/media/v4l/vidioc-g-dv-timings.xml index eda1a2991bbe..72369707bd77 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-dv-timings.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-dv-timings.xml @@ -56,7 +56,9 @@ a pointer to the &v4l2-dv-timings; structure as argument. If the ioctl is not su or the timing values are not correct, the driver returns &EINVAL;.</para> <para>The <filename>linux/v4l2-dv-timings.h</filename> header can be used to get the timings of the formats in the <xref linkend="cea861" /> and <xref linkend="vesadmt" /> -standards.</para> +standards. If the current input or output does not support DV timings (e.g. if +&VIDIOC-ENUMINPUT; does not set the <constant>V4L2_IN_CAP_DV_TIMINGS</constant> flag), then +&ENODATA; is returned.</para> </refsect1> <refsect1> @@ -71,6 +73,12 @@ standards.</para> </listitem> </varlistentry> <varlistentry> + <term><errorcode>ENODATA</errorcode></term> + <listitem> + <para>Digital video timings are not supported for this input or output.</para> + </listitem> + </varlistentry> + <varlistentry> <term><errorcode>EBUSY</errorcode></term> <listitem> <para>The device is busy and therefore can not change the timings.</para> @@ -320,7 +328,4 @@ detected or used depends on the hardware. </tgroup> </table> </refsect1> - <refsect1> - &return-value; - </refsect1> </refentry> diff --git a/Documentation/DocBook/media/v4l/vidioc-g-enc-index.xml b/Documentation/DocBook/media/v4l/vidioc-g-enc-index.xml index 2aef02c9044e..be25029a16f1 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-enc-index.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-enc-index.xml @@ -48,13 +48,6 @@ <refsect1> <title>Description</title> - <note> - <title>Experimental</title> - - <para>This is an <link linkend="experimental">experimental</link> -interface and may change in the future.</para> - </note> - <para>The <constant>VIDIOC_G_ENC_INDEX</constant> ioctl provides meta data about a compressed video stream the same or another application currently reads from the driver, which is useful for diff --git a/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml b/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml index 52acff193a6f..ee8f56e1bac0 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml @@ -81,7 +81,7 @@ the application calls the <constant>VIDIOC_S_FMT</constant> ioctl with a pointer to a <structname>v4l2_format</structname> structure the driver checks and adjusts the parameters against hardware abilities. Drivers -should not return an error code unless the input is ambiguous, this is +should not return an error code unless the <structfield>type</structfield> field is invalid, this is a mechanism to fathom device capabilities and to approach parameters acceptable for both the application and driver. On success the driver may program the hardware, allocate resources and generally prepare for @@ -107,6 +107,10 @@ disabling I/O or possibly time consuming hardware preparations. Although strongly recommended drivers are not required to implement this ioctl.</para> + <para>The format as returned by <constant>VIDIOC_TRY_FMT</constant> +must be identical to what <constant>VIDIOC_S_FMT</constant> returns for +the same input or output.</para> + <table pgwide="1" frame="none" id="v4l2-format"> <title>struct <structname>v4l2_format</structname></title> <tgroup cols="4"> @@ -170,9 +174,7 @@ capture and output devices.</entry> <entry></entry> <entry>__u8</entry> <entry><structfield>raw_data</structfield>[200]</entry> - <entry>Place holder for future extensions and custom -(driver defined) formats with <structfield>type</structfield> -<constant>V4L2_BUF_TYPE_PRIVATE</constant> and higher.</entry> + <entry>Place holder for future extensions.</entry> </row> </tbody> </tgroup> @@ -187,8 +189,7 @@ capture and output devices.</entry> <term><errorcode>EINVAL</errorcode></term> <listitem> <para>The &v4l2-format; <structfield>type</structfield> -field is invalid, the requested buffer type not supported, or the -format is not supported with this buffer type.</para> +field is invalid or the requested buffer type not supported.</para> </listitem> </varlistentry> </variablelist> diff --git a/Documentation/DocBook/media/v4l/vidioc-g-parm.xml b/Documentation/DocBook/media/v4l/vidioc-g-parm.xml index f83d2cdd1185..9058224d1bbf 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-parm.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-parm.xml @@ -108,9 +108,7 @@ devices.</para> <entry></entry> <entry>__u8</entry> <entry><structfield>raw_data</structfield>[200]</entry> - <entry>A place holder for future extensions and custom -(driver defined) buffer types <constant>V4L2_BUF_TYPE_PRIVATE</constant> and -higher.</entry> + <entry>A place holder for future extensions.</entry> </row> </tbody> </tgroup> diff --git a/Documentation/DocBook/media/v4l/vidioc-g-selection.xml b/Documentation/DocBook/media/v4l/vidioc-g-selection.xml index f76d8a6d9b92..b11ec75e21a1 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-selection.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-selection.xml @@ -152,12 +152,10 @@ satisfactory parameters have been negotiated. If constraints flags have to be violated at then ERANGE is returned. The error indicates that <emphasis> there exist no rectangle </emphasis> that satisfies the constraints.</para> - </refsect1> - <para>Selection targets and flags are documented in <xref linkend="v4l2-selections-common"/>.</para> - <section> + <para> <figure id="sel-const-adjust"> <title>Size adjustments with constraint flags.</title> <mediaobject> @@ -170,9 +168,9 @@ exist no rectangle </emphasis> that satisfies the constraints.</para> </textobject> </mediaobject> </figure> - </section> + </para> - <refsect1> + <para> <table pgwide="1" frame="none" id="v4l2-selection"> <title>struct <structname>v4l2_selection</structname></title> <tgroup cols="3"> @@ -208,6 +206,7 @@ exist no rectangle </emphasis> that satisfies the constraints.</para> </tbody> </tgroup> </table> + </para> </refsect1> <refsect1> diff --git a/Documentation/DocBook/media/v4l/vidioc-g-std.xml b/Documentation/DocBook/media/v4l/vidioc-g-std.xml index 99ff1a016220..4a898417de28 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-std.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-std.xml @@ -72,7 +72,9 @@ flags, being a write-only ioctl it does not return the actual new standard as the current input does not support the requested standard the driver returns an &EINVAL;. When the standard set is ambiguous drivers may return <errorcode>EINVAL</errorcode> or choose any of the requested -standards.</para> +standards. If the current input or output does not support standard video timings (e.g. if +&VIDIOC-ENUMINPUT; does not set the <constant>V4L2_IN_CAP_STD</constant> flag), then +&ENODATA; is returned.</para> </refsect1> <refsect1> @@ -85,6 +87,12 @@ standards.</para> <para>The <constant>VIDIOC_S_STD</constant> parameter was unsuitable.</para> </listitem> </varlistentry> + <varlistentry> + <term><errorcode>ENODATA</errorcode></term> + <listitem> + <para>Standard video timings are not supported for this input or output.</para> + </listitem> + </varlistentry> </variablelist> </refsect1> </refentry> diff --git a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml index 701138f1209d..6cc82010c736 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml @@ -354,6 +354,12 @@ radio tuners.</entry> <entry>The &VIDIOC-ENUM-FREQ-BANDS; ioctl can be used to enumerate the available frequency bands.</entry> </row> + <row> + <entry><constant>V4L2_TUNER_CAP_HWSEEK_PROG_LIM</constant></entry> + <entry>0x0800</entry> + <entry>The range to search when using the hardware seek functionality + is programmable, see &VIDIOC-S-HW-FREQ-SEEK; for details.</entry> + </row> </tbody> </tgroup> </table> diff --git a/Documentation/DocBook/media/v4l/vidioc-qbuf.xml b/Documentation/DocBook/media/v4l/vidioc-qbuf.xml index 77ff5be0809d..2d37abefce13 100644 --- a/Documentation/DocBook/media/v4l/vidioc-qbuf.xml +++ b/Documentation/DocBook/media/v4l/vidioc-qbuf.xml @@ -121,8 +121,7 @@ remaining fields or returns an error code. The driver may also set field. It indicates a non-critical (recoverable) streaming error. In such case the application may continue as normal, but should be aware that data in the dequeued buffer might be corrupted. When using the multi-planar API, the -planes array does not have to be passed; the <structfield>m.planes</structfield> -member must be set to NULL in that case.</para> +planes array must be passed in as well.</para> <para>By default <constant>VIDIOC_DQBUF</constant> blocks when no buffer is in the outgoing queue. When the @@ -155,6 +154,8 @@ or no buffers have been allocated yet, or the <structfield>userptr</structfield> or <structfield>length</structfield> are invalid.</para> </listitem> + </varlistentry> + <varlistentry> <term><errorcode>EIO</errorcode></term> <listitem> <para><constant>VIDIOC_DQBUF</constant> failed due to an diff --git a/Documentation/DocBook/media/v4l/vidioc-query-dv-preset.xml b/Documentation/DocBook/media/v4l/vidioc-query-dv-preset.xml index 1bc8aeb3ff1f..68b49d09e245 100644 --- a/Documentation/DocBook/media/v4l/vidioc-query-dv-preset.xml +++ b/Documentation/DocBook/media/v4l/vidioc-query-dv-preset.xml @@ -65,5 +65,14 @@ returned.</para> <refsect1> &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>ENODATA</errorcode></term> + <listitem> + <para>Digital video presets are not supported for this input or output.</para> + </listitem> + </varlistentry> + </variablelist> </refsect1> </refentry> diff --git a/Documentation/DocBook/media/v4l/vidioc-query-dv-timings.xml b/Documentation/DocBook/media/v4l/vidioc-query-dv-timings.xml index 44935a0ffcf0..e185f149e0a1 100644 --- a/Documentation/DocBook/media/v4l/vidioc-query-dv-timings.xml +++ b/Documentation/DocBook/media/v4l/vidioc-query-dv-timings.xml @@ -78,6 +78,12 @@ capabilities in order to give more precise feedback to the user. <variablelist> <varlistentry> + <term><errorcode>ENODATA</errorcode></term> + <listitem> + <para>Digital video timings are not supported for this input or output.</para> + </listitem> + </varlistentry> + <varlistentry> <term><errorcode>ENOLINK</errorcode></term> <listitem> <para>No timings could be detected because no signal was found. diff --git a/Documentation/DocBook/media/v4l/vidioc-querybuf.xml b/Documentation/DocBook/media/v4l/vidioc-querybuf.xml index 6e414d7b6df7..a597155c052d 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querybuf.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querybuf.xml @@ -48,8 +48,8 @@ <refsect1> <title>Description</title> - <para>This ioctl is part of the <link linkend="mmap">memory -mapping</link> I/O method. It can be used to query the status of a + <para>This ioctl is part of the <link linkend="mmap">streaming +</link> I/O method. It can be used to query the status of a buffer at any time after buffers have been allocated with the &VIDIOC-REQBUFS; ioctl.</para> @@ -71,6 +71,7 @@ the structure.</para> <para>In the <structfield>flags</structfield> field the <constant>V4L2_BUF_FLAG_MAPPED</constant>, +<constant>V4L2_BUF_FLAG_PREPARED</constant>, <constant>V4L2_BUF_FLAG_QUEUED</constant> and <constant>V4L2_BUF_FLAG_DONE</constant> flags will be valid. The <structfield>memory</structfield> field will be set to the current @@ -79,8 +80,10 @@ contains the offset of the buffer from the start of the device memory, the <structfield>length</structfield> field its size. For the multi-planar API, fields <structfield>m.mem_offset</structfield> and <structfield>length</structfield> in the <structfield>m.planes</structfield> -array elements will be used instead. The driver may or may not set the remaining -fields and flags, they are meaningless in this context.</para> +array elements will be used instead and the <structfield>length</structfield> +field of &v4l2-buffer; is set to the number of filled-in array elements. +The driver may or may not set the remaining fields and flags, they are +meaningless in this context.</para> <para>The <structname>v4l2_buffer</structname> structure is specified in <xref linkend="buffer" />.</para> diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index f33dd746b66b..4c70215ae03f 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml @@ -90,11 +90,13 @@ ambiguities.</entry> <entry>__u8</entry> <entry><structfield>bus_info</structfield>[32]</entry> <entry>Location of the device in the system, a -NUL-terminated ASCII string. For example: "PCI Slot 4". This +NUL-terminated ASCII string. For example: "PCI:0000:05:06.0". This information is intended for users, to distinguish multiple -identical devices. If no such information is available the field may -simply count the devices controlled by the driver, or contain the -empty string (<structfield>bus_info</structfield>[0] = 0).<!-- XXX pci_dev->slot_name example --></entry> +identical devices. If no such information is available the field must +simply count the devices controlled by the driver ("platform:vivi-000"). +The bus_info must start with "PCI:" for PCI boards, "PCIe:" for PCI Express boards, +"usb-" for USB devices, "I2C:" for i2c devices, "ISA:" for ISA devices, +"parport" for parallel port devices and "platform:" for platform devices.</entry> </row> <row> <entry>__u32</entry> diff --git a/Documentation/DocBook/media/v4l/vidioc-querystd.xml b/Documentation/DocBook/media/v4l/vidioc-querystd.xml index 4b79c7c04ed6..fe80a183d957 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querystd.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querystd.xml @@ -62,5 +62,13 @@ current video input or output.</para> <refsect1> &return-value; + <variablelist> + <varlistentry> + <term><errorcode>ENODATA</errorcode></term> + <listitem> + <para>Standard video timings are not supported for this input or output.</para> + </listitem> + </varlistentry> + </variablelist> </refsect1> </refentry> diff --git a/Documentation/DocBook/media/v4l/vidioc-reqbufs.xml b/Documentation/DocBook/media/v4l/vidioc-reqbufs.xml index d7c95057bc51..2b50ef2007f3 100644 --- a/Documentation/DocBook/media/v4l/vidioc-reqbufs.xml +++ b/Documentation/DocBook/media/v4l/vidioc-reqbufs.xml @@ -109,9 +109,8 @@ as the &v4l2-format; <structfield>type</structfield> field. See <xref <row> <entry>__u32</entry> <entry><structfield>reserved</structfield>[2]</entry> - <entry>A place holder for future extensions and custom -(driver defined) buffer types <constant>V4L2_BUF_TYPE_PRIVATE</constant> and -higher. This array should be zeroed by applications.</entry> + <entry>A place holder for future extensions. This array should +be zeroed by applications.</entry> </row> </tbody> </tgroup> diff --git a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml index 3dd1bec6d3c7..5b379e752194 100644 --- a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml +++ b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml @@ -75,6 +75,9 @@ seek is started.</para> <para>This ioctl is supported if the <constant>V4L2_CAP_HW_FREQ_SEEK</constant> capability is set.</para> + <para>If this ioctl is called from a non-blocking filehandle, then &EAGAIN; is + returned and no seek takes place.</para> + <table pgwide="1" frame="none" id="v4l2-hw-freq-seek"> <title>struct <structname>v4l2_hw_freq_seek</structname></title> <tgroup cols="3"> @@ -158,6 +161,13 @@ fields is wrong.</para> </listitem> </varlistentry> <varlistentry> + <term><errorcode>EAGAIN</errorcode></term> + <listitem> + <para>Attempted to call <constant>VIDIOC_S_HW_FREQ_SEEK</constant> + with the filehandle in non-blocking mode.</para> + </listitem> + </varlistentry> + <varlistentry> <term><errorcode>ENODATA</errorcode></term> <listitem> <para>The hardware seek found no channels.</para> diff --git a/Documentation/DocBook/media/v4l/vidioc-streamon.xml b/Documentation/DocBook/media/v4l/vidioc-streamon.xml index 81cca4569050..716ea15e54a1 100644 --- a/Documentation/DocBook/media/v4l/vidioc-streamon.xml +++ b/Documentation/DocBook/media/v4l/vidioc-streamon.xml @@ -74,7 +74,12 @@ not transmitted yet. I/O returns to the same state as after calling stream type. This is the same as &v4l2-requestbuffers; <structfield>type</structfield>.</para> - <para>Note applications can be preempted for unknown periods right + <para>If <constant>VIDIOC_STREAMON</constant> is called when streaming +is already in progress, or if <constant>VIDIOC_STREAMOFF</constant> is called +when streaming is already stopped, then the ioctl does nothing and 0 is +returned.</para> + + <para>Note that applications can be preempted for unknown periods right before or after the <constant>VIDIOC_STREAMON</constant> or <constant>VIDIOC_STREAMOFF</constant> calls, there is no notion of starting or stopping "now". Buffer timestamps can be used to diff --git a/Documentation/DocBook/media/v4l/vidioc-subdev-g-edid.xml b/Documentation/DocBook/media/v4l/vidioc-subdev-g-edid.xml new file mode 100644 index 000000000000..bbd18f0e6ede --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-subdev-g-edid.xml @@ -0,0 +1,152 @@ +<refentry id="vidioc-subdev-g-edid"> + <refmeta> + <refentrytitle>ioctl VIDIOC_SUBDEV_G_EDID, VIDIOC_SUBDEV_S_EDID</refentrytitle> + &manvol; + </refmeta> + + <refnamediv> + <refname>VIDIOC_SUBDEV_G_EDID</refname> + <refname>VIDIOC_SUBDEV_S_EDID</refname> + <refpurpose>Get or set the EDID of a video receiver/transmitter</refpurpose> + </refnamediv> + + <refsynopsisdiv> + <funcsynopsis> + <funcprototype> + <funcdef>int <function>ioctl</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>int <parameter>request</parameter></paramdef> + <paramdef>struct v4l2_subdev_edid *<parameter>argp</parameter></paramdef> + </funcprototype> + </funcsynopsis> + <funcsynopsis> + <funcprototype> + <funcdef>int <function>ioctl</function></funcdef> + <paramdef>int <parameter>fd</parameter></paramdef> + <paramdef>int <parameter>request</parameter></paramdef> + <paramdef>const struct v4l2_subdev_edid *<parameter>argp</parameter></paramdef> + </funcprototype> + </funcsynopsis> + </refsynopsisdiv> + + <refsect1> + <title>Arguments</title> + + <variablelist> + <varlistentry> + <term><parameter>fd</parameter></term> + <listitem> + <para>&fd;</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>request</parameter></term> + <listitem> + <para>VIDIOC_SUBDEV_G_EDID, VIDIOC_SUBDEV_S_EDID</para> + </listitem> + </varlistentry> + <varlistentry> + <term><parameter>argp</parameter></term> + <listitem> + <para></para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> + + <refsect1> + <title>Description</title> + <para>These ioctls can be used to get or set an EDID associated with an input pad + from a receiver or an output pad of a transmitter subdevice.</para> + + <para>To get the EDID data the application has to fill in the <structfield>pad</structfield>, + <structfield>start_block</structfield>, <structfield>blocks</structfield> and <structfield>edid</structfield> + fields and call <constant>VIDIOC_SUBDEV_G_EDID</constant>. The current EDID from block + <structfield>start_block</structfield> and of size <structfield>blocks</structfield> + will be placed in the memory <structfield>edid</structfield> points to. The <structfield>edid</structfield> + pointer must point to memory at least <structfield>blocks</structfield> * 128 bytes + large (the size of one block is 128 bytes).</para> + + <para>If there are fewer blocks than specified, then the driver will set <structfield>blocks</structfield> + to the actual number of blocks. If there are no EDID blocks available at all, then the error code + ENODATA is set.</para> + + <para>If blocks have to be retrieved from the sink, then this call will block until they + have been read.</para> + + <para>To set the EDID blocks of a receiver the application has to fill in the <structfield>pad</structfield>, + <structfield>blocks</structfield> and <structfield>edid</structfield> fields and set + <structfield>start_block</structfield> to 0. It is not possible to set part of an EDID, + it is always all or nothing. Setting the EDID data is only valid for receivers as it makes + no sense for a transmitter.</para> + + <para>The driver assumes that the full EDID is passed in. If there are more EDID blocks than + the hardware can handle then the EDID is not written, but instead the error code E2BIG is set + and <structfield>blocks</structfield> is set to the maximum that the hardware supports. + If <structfield>start_block</structfield> is any + value other than 0 then the error code EINVAL is set.</para> + + <para>To disable an EDID you set <structfield>blocks</structfield> to 0. Depending on the + hardware this will drive the hotplug pin low and/or block the source from reading the EDID + data in some way. In any case, the end result is the same: the EDID is no longer available. + </para> + + <table pgwide="1" frame="none" id="v4l2-subdev-edid"> + <title>struct <structname>v4l2_subdev_edid</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>pad</structfield></entry> + <entry>Pad for which to get/set the EDID blocks.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>start_block</structfield></entry> + <entry>Read the EDID from starting with this block. Must be 0 when setting + the EDID.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>blocks</structfield></entry> + <entry>The number of blocks to get or set. Must be less or equal to 256 (the + maximum number of blocks as defined by the standard). When you set the EDID and + <structfield>blocks</structfield> is 0, then the EDID is disabled or erased.</entry> + </row> + <row> + <entry>__u8 *</entry> + <entry><structfield>edid</structfield></entry> + <entry>Pointer to memory that contains the EDID. The minimum size is + <structfield>blocks</structfield> * 128.</entry> + </row> + <row> + <entry>__u32</entry> + <entry><structfield>reserved</structfield>[5]</entry> + <entry>Reserved for future extensions. Applications and drivers must + set the array to zero.</entry> + </row> + </tbody> + </tgroup> + </table> + </refsect1> + + <refsect1> + &return-value; + + <variablelist> + <varlistentry> + <term><errorcode>ENODATA</errorcode></term> + <listitem> + <para>The EDID data is not available.</para> + </listitem> + </varlistentry> + <varlistentry> + <term><errorcode>E2BIG</errorcode></term> + <listitem> + <para>The EDID data you provided is more than the hardware can handle.</para> + </listitem> + </varlistentry> + </variablelist> + </refsect1> +</refentry> diff --git a/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml b/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml index f33cc814a01d..1ba9e999af3f 100644 --- a/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml +++ b/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml @@ -69,23 +69,22 @@ more information on how each selection target affects the image processing pipeline inside the subdevice.</para> - <section> + <refsect2> <title>Types of selection targets</title> <para>There are two types of selection targets: actual and bounds. The actual targets are the targets which configure the hardware. The BOUNDS target will return a rectangle that contain all possible actual rectangles.</para> - </section> + </refsect2> - <section> + <refsect2> <title>Discovering supported features</title> <para>To discover which targets are supported, the user can perform <constant>VIDIOC_SUBDEV_G_SELECTION</constant> on them. Any unsupported target will return <constant>EINVAL</constant>.</para> - </section> <para>Selection targets and flags are documented in <xref linkend="v4l2-selections-common"/>.</para> @@ -132,6 +131,7 @@ </tbody> </tgroup> </table> + </refsect2> </refsect1> diff --git a/Documentation/DocBook/media_api.tmpl b/Documentation/DocBook/media_api.tmpl index 4e8e8985cc17..f2413acfe241 100644 --- a/Documentation/DocBook/media_api.tmpl +++ b/Documentation/DocBook/media_api.tmpl @@ -29,7 +29,7 @@ <title>LINUX MEDIA INFRASTRUCTURE API</title> <copyright> - <year>2009-2011</year> + <year>2009-2012</year> <holder>LinuxTV Developers</holder> </copyright> @@ -53,7 +53,7 @@ Foundation. A copy of the license is included in the chapter entitled video and radio straming devices, including video cameras, analog and digital TV receiver cards, AM/FM receiver cards, streaming capture devices.</para> - <para>It is divided into three parts.</para> + <para>It is divided into four parts.</para> <para>The first part covers radio, capture, cameras and analog TV devices.</para> <para>The second part covers the @@ -62,7 +62,8 @@ Foundation. A copy of the license is included in the chapter entitled in fact it covers several different video standards including DVB-T, DVB-S, DVB-C and ATSC. The API is currently being updated to documment support also for DVB-S2, ISDB-T and ISDB-S.</para> - <para>The third part covers Remote Controller API</para> + <para>The third part covers the Remote Controller API.</para> + <para>The fourth part covers the Media Controller API.</para> <para>For additional information and for the latest development code, see: <ulink url="http://linuxtv.org">http://linuxtv.org</ulink>.</para> <para>For discussing improvements, reporting troubles, sending new drivers, etc, please mail to: <ulink url="http://vger.kernel.org/vger-lists.html#linux-media">Linux Media Mailing List (LMML).</ulink>.</para> @@ -87,7 +88,7 @@ Foundation. A copy of the license is included in the chapter entitled </author> </authorgroup> <copyright> - <year>2009-2011</year> + <year>2009-2012</year> <holder>Mauro Carvalho Chehab</holder> </copyright> diff --git a/Documentation/DocBook/mtdnand.tmpl b/Documentation/DocBook/mtdnand.tmpl index e0aedb7a7827..fe122d6e686f 100644 --- a/Documentation/DocBook/mtdnand.tmpl +++ b/Documentation/DocBook/mtdnand.tmpl @@ -1216,8 +1216,6 @@ in this page</entry> #define NAND_BBT_LASTBLOCK 0x00000010 /* The bbt is at the given page, else we must scan for the bbt */ #define NAND_BBT_ABSPAGE 0x00000020 -/* The bbt is at the given page, else we must scan for the bbt */ -#define NAND_BBT_SEARCH 0x00000040 /* bbt is stored per chip on multichip devices */ #define NAND_BBT_PERCHIP 0x00000080 /* bbt has a version counter at offset veroffs */ diff --git a/Documentation/DocBook/networking.tmpl b/Documentation/DocBook/networking.tmpl index 59ad69a9d777..29df25016c7c 100644 --- a/Documentation/DocBook/networking.tmpl +++ b/Documentation/DocBook/networking.tmpl @@ -56,7 +56,7 @@ !Enet/core/filter.c </sect1> <sect1><title>Generic Network Statistics</title> -!Iinclude/linux/gen_stats.h +!Iinclude/uapi/linux/gen_stats.h !Enet/core/gen_stats.c !Enet/core/gen_estimator.c </sect1> @@ -80,7 +80,7 @@ !Enet/wimax/op-rfkill.c !Enet/wimax/stack.c !Iinclude/net/wimax.h -!Iinclude/linux/wimax.h +!Iinclude/uapi/linux/wimax.h </sect1> </chapter> diff --git a/Documentation/IPMI.txt b/Documentation/IPMI.txt index b2bea15137d2..16eb4c9e9233 100644 --- a/Documentation/IPMI.txt +++ b/Documentation/IPMI.txt @@ -42,13 +42,7 @@ The driver interface depends on your hardware. If your system properly provides the SMBIOS info for IPMI, the driver will detect it and just work. If you have a board with a standard interface (These will generally be either "KCS", "SMIC", or "BT", consult your hardware -manual), choose the 'IPMI SI handler' option. A driver also exists -for direct I2C access to the IPMI management controller. Some boards -support this, but it is unknown if it will work on every board. For -this, choose 'IPMI SMBus handler', but be ready to try to do some -figuring to see if it will work on your system if the SMBIOS/APCI -information is wrong or not present. It is fairly safe to have both -these enabled and let the drivers auto-detect what is present. +manual), choose the 'IPMI SI handler' option. You should generally enable ACPI on your system, as systems with IPMI can have ACPI tables describing them. @@ -58,8 +52,7 @@ their job correctly, the IPMI controller should be automatically detected (via ACPI or SMBIOS tables) and should just work. Sadly, many boards do not have this information. The driver attempts standard defaults, but they may not work. If you fall into this -situation, you need to read the section below named 'The SI Driver' or -"The SMBus Driver" on how to hand-configure your system. +situation, you need to read the section below named 'The SI Driver'. IPMI defines a standard watchdog timer. You can enable this with the 'IPMI Watchdog Timer' config option. If you compile the driver into @@ -104,12 +97,7 @@ driver, each open file for this device ties in to the message handler as an IPMI user. ipmi_si - A driver for various system interfaces. This supports KCS, -SMIC, and BT interfaces. Unless you have an SMBus interface or your -own custom interface, you probably need to use this. - -ipmi_smb - A driver for accessing BMCs on the SMBus. It uses the -I2C kernel driver's SMBus interfaces to send and receive IPMI messages -over the SMBus. +SMIC, and BT interfaces. ipmi_watchdog - IPMI requires systems to have a very capable watchdog timer. This driver implements the standard Linux watchdog timer @@ -482,53 +470,6 @@ for specifying an interface. Note that when removing an interface, only the first three parameters (si type, address type, and address) are used for the comparison. Any options are ignored for removing. -The SMBus Driver ----------------- - -The SMBus driver allows up to 4 SMBus devices to be configured in the -system. By default, the driver will register any SMBus interfaces it finds -in the I2C address range of 0x20 to 0x4f on any adapter. You can change this -at module load time (for a module) with: - - modprobe ipmi_smb.o - addr=<adapter1>,<i2caddr1>[,<adapter2>,<i2caddr2>[,...]] - dbg=<flags1>,<flags2>... - [defaultprobe=1] [dbg_probe=1] - -The addresses are specified in pairs, the first is the adapter ID and the -second is the I2C address on that adapter. - -The debug flags are bit flags for each BMC found, they are: -IPMI messages: 1, driver state: 2, timing: 4, I2C probe: 8 - -Setting smb_defaultprobe to zero disabled the default probing of SMBus -interfaces at address range 0x20 to 0x4f. This means that only the -BMCs specified on the smb_addr line will be detected. - -Setting smb_dbg_probe to 1 will enable debugging of the probing and -detection process for BMCs on the SMBusses. - -Discovering the IPMI compliant BMC on the SMBus can cause devices -on the I2C bus to fail. The SMBus driver writes a "Get Device ID" IPMI -message as a block write to the I2C bus and waits for a response. -This action can be detrimental to some I2C devices. It is highly recommended -that the known I2c address be given to the SMBus driver in the smb_addr -parameter. The default address range will not be used when a smb_addr -parameter is provided. - -When compiled into the kernel, the addresses can be specified on the -kernel command line as: - - ipmb_smb.addr=<adapter1>,<i2caddr1>[,<adapter2>,<i2caddr2>[,...]] - ipmi_smb.dbg=<flags1>,<flags2>... - ipmi_smb.defaultprobe=0 ipmi_smb.dbg_probe=1 - -These are the same options as on the module command line. - -Note that you might need some I2C changes if CONFIG_IPMI_PANIC_EVENT -is enabled along with this, so the I2C driver knows to run to -completion during sending a panic event. - Other Pieces ------------ diff --git a/Documentation/aoe/aoe.txt b/Documentation/aoe/aoe.txt index 5f5aa16047ff..bfc9cb19abcd 100644 --- a/Documentation/aoe/aoe.txt +++ b/Documentation/aoe/aoe.txt @@ -1,8 +1,16 @@ -The EtherDrive (R) HOWTO for users of 2.6 kernels is found at ... +ATA over Ethernet is a network protocol that provides simple access to +block storage on the LAN. - http://www.coraid.com/SUPPORT/EtherDrive-HBA + http://support.coraid.com/documents/AoEr11.txt - It has many tips and hints! +The EtherDrive (R) HOWTO for 2.6 and 3.x kernels is found at ... + + http://support.coraid.com/support/linux/EtherDrive-2.6-HOWTO.html + +It has many tips and hints! Please see, especially, recommended +tunings for virtual memory: + + http://support.coraid.com/support/linux/EtherDrive-2.6-HOWTO-5.html#ss5.19 The aoetools are userland programs that are designed to work with this driver. The aoetools are on sourceforge. @@ -23,20 +31,12 @@ CREATING DEVICE NODES There is a udev-install.sh script that shows how to install these rules on your system. - If you are not using udev, two scripts are provided in - Documentation/aoe as examples of static device node creation for - using the aoe driver. - - rm -rf /dev/etherd - sh Documentation/aoe/mkdevs.sh /dev/etherd - - ... or to make just one shelf's worth of block device nodes ... - - sh Documentation/aoe/mkshelf.sh /dev/etherd 0 - There is also an autoload script that shows how to edit /etc/modprobe.d/aoe.conf to ensure that the aoe module is loaded when - necessary. + necessary. Preloading the aoe module is preferable to autoloading, + however, because AoE discovery takes a few seconds. It can be + confusing when an AoE device is not present the first time the a + command is run but appears a second later. USING DEVICE NODES @@ -51,9 +51,9 @@ USING DEVICE NODES "echo > /dev/etherd/discover" tells the driver to find out what AoE devices are available. - These character devices may disappear and be replaced by sysfs - counterparts. Using the commands in aoetools insulates users from - these implementation details. + In the future these character devices may disappear and be replaced + by sysfs counterparts. Using the commands in aoetools insulates + users from these implementation details. The block devices are named like this: @@ -76,8 +76,8 @@ USING SYSFS The netif attribute is the network interface on the localhost through which we are communicating with the remote AoE device. - There is a script in this directory that formats this information - in a convenient way. Users with aoetools can use the aoe-stat + There is a script in this directory that formats this information in + a convenient way. Users with aoetools should use the aoe-stat command. root@makki root# sh Documentation/aoe/status.sh @@ -121,3 +121,21 @@ DRIVER OPTIONS usage example for the module parameter. modprobe aoe_iflist="eth1 eth3" + + The aoe_deadsecs module parameter determines the maximum number of + seconds that the driver will wait for an AoE device to provide a + response to an AoE command. After aoe_deadsecs seconds have + elapsed, the AoE device will be marked as "down". + + The aoe_maxout module parameter has a default of 128. This is the + maximum number of unresponded packets that will be sent to an AoE + target at one time. + + The aoe_dyndevs module parameter defaults to 1, meaning that the + driver will assign a block device minor number to a discovered AoE + target based on the order of its discovery. With dynamic minor + device numbers in use, a greater range of AoE shelf and slot + addresses can be supported. Users with udev will never have to + think about minor numbers. Using aoe_dyndevs=0 allows device nodes + to be pre-created using a static minor-number scheme with the + aoe-mkshelf script in the aoetools. diff --git a/Documentation/aoe/mkdevs.sh b/Documentation/aoe/mkdevs.sh deleted file mode 100644 index 44c0ab702432..000000000000 --- a/Documentation/aoe/mkdevs.sh +++ /dev/null @@ -1,41 +0,0 @@ -#!/bin/sh - -n_shelves=${n_shelves:-10} -n_partitions=${n_partitions:-16} - -if test "$#" != "1"; then - echo "Usage: sh `basename $0` {dir}" 1>&2 - echo " n_partitions=16 sh `basename $0` {dir}" 1>&2 - exit 1 -fi -dir=$1 - -MAJOR=152 - -echo "Creating AoE devnode files in $dir ..." - -set -e - -mkdir -p $dir - -# (Status info is in sysfs. See status.sh.) -# rm -f $dir/stat -# mknod -m 0400 $dir/stat c $MAJOR 1 -rm -f $dir/err -mknod -m 0400 $dir/err c $MAJOR 2 -rm -f $dir/discover -mknod -m 0200 $dir/discover c $MAJOR 3 -rm -f $dir/interfaces -mknod -m 0200 $dir/interfaces c $MAJOR 4 -rm -f $dir/revalidate -mknod -m 0200 $dir/revalidate c $MAJOR 5 -rm -f $dir/flush -mknod -m 0200 $dir/flush c $MAJOR 6 - -export n_partitions -mkshelf=`echo $0 | sed 's!mkdevs!mkshelf!'` -i=0 -while test $i -lt $n_shelves; do - sh -xc "sh $mkshelf $dir $i" - i=`expr $i + 1` -done diff --git a/Documentation/aoe/mkshelf.sh b/Documentation/aoe/mkshelf.sh deleted file mode 100644 index 32615814271c..000000000000 --- a/Documentation/aoe/mkshelf.sh +++ /dev/null @@ -1,28 +0,0 @@ -#! /bin/sh - -if test "$#" != "2"; then - echo "Usage: sh `basename $0` {dir} {shelfaddress}" 1>&2 - echo " n_partitions=16 sh `basename $0` {dir} {shelfaddress}" 1>&2 - exit 1 -fi -n_partitions=${n_partitions:-16} -dir=$1 -shelf=$2 -nslots=16 -maxslot=`echo $nslots 1 - p | dc` -MAJOR=152 - -set -e - -minor=`echo $nslots \* $shelf \* $n_partitions | bc` -endp=`echo $n_partitions - 1 | bc` -for slot in `seq 0 $maxslot`; do - for part in `seq 0 $endp`; do - name=e$shelf.$slot - test "$part" != "0" && name=${name}p$part - rm -f $dir/$name - mknod -m 0660 $dir/$name b $MAJOR $minor - - minor=`expr $minor + 1` - done -done diff --git a/Documentation/aoe/status.sh b/Documentation/aoe/status.sh index 751f3be514b8..eeec7baae57a 100644 --- a/Documentation/aoe/status.sh +++ b/Documentation/aoe/status.sh @@ -1,5 +1,8 @@ #! /bin/sh # collate and present sysfs information about AoE storage +# +# A more complete version of this script is aoe-stat, in the +# aoetools. set -e format="%8s\t%8s\t%8s\n" diff --git a/Documentation/arm/Booting b/Documentation/arm/Booting index a341d87d276e..0c1f475fdf36 100644 --- a/Documentation/arm/Booting +++ b/Documentation/arm/Booting @@ -154,13 +154,33 @@ In either case, the following conditions must be met: - CPU mode All forms of interrupts must be disabled (IRQs and FIQs) - The CPU must be in SVC mode. (A special exception exists for Angel) + + For CPUs which do not include the ARM virtualization extensions, the + CPU must be in SVC mode. (A special exception exists for Angel) + + CPUs which include support for the virtualization extensions can be + entered in HYP mode in order to enable the kernel to make full use of + these extensions. This is the recommended boot method for such CPUs, + unless the virtualisations are already in use by a pre-installed + hypervisor. + + If the kernel is not entered in HYP mode for any reason, it must be + entered in SVC mode. - Caches, MMUs The MMU must be off. Instruction cache may be on or off. Data cache must be off. + If the kernel is entered in HYP mode, the above requirements apply to + the HYP mode configuration in addition to the ordinary PL1 (privileged + kernel modes) configuration. In addition, all traps into the + hypervisor must be disabled, and PL1 access must be granted for all + peripherals and CPU resources for which this is architecturally + possible. Except for entering in HYP mode, the system configuration + should be such that a kernel which does not include support for the + virtualization extensions can boot correctly without extra help. + - The boot loader is expected to call the kernel image by jumping directly to the first instruction of the kernel image. diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt index e418dc0a7086..8df5e8e6dceb 100644 --- a/Documentation/block/biodoc.txt +++ b/Documentation/block/biodoc.txt @@ -465,7 +465,6 @@ struct bio { bio_end_io_t *bi_end_io; /* bi_end_io (bio) */ atomic_t bi_cnt; /* pin count: free when it hits zero */ void *bi_private; - bio_destructor_t *bi_destructor; /* bi_destructor (bio) */ }; With this multipage bio design: @@ -647,10 +646,6 @@ for a non-clone bio. There are the 6 pools setup for different size biovecs, so bio_alloc(gfp_mask, nr_iovecs) will allocate a vec_list of the given size from these slabs. -The bi_destructor() routine takes into account the possibility of the bio -having originated from a different source (see later discussions on -n/w to block transfers and kvec_cb) - The bio_get() routine may be used to hold an extra reference on a bio prior to i/o submission, if the bio fields are likely to be accessed after the i/o is issued (since the bio may otherwise get freed in case i/o completion diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt index 4372e6b8a353..c07f7b4fb88d 100644 --- a/Documentation/cgroups/memory.txt +++ b/Documentation/cgroups/memory.txt @@ -18,16 +18,16 @@ from the rest of the system. The article on LWN [12] mentions some probable uses of the memory controller. The memory controller can be used to a. Isolate an application or a group of applications - Memory hungry applications can be isolated and limited to a smaller + Memory-hungry applications can be isolated and limited to a smaller amount of memory. -b. Create a cgroup with limited amount of memory, this can be used +b. Create a cgroup with a limited amount of memory; this can be used as a good alternative to booting with mem=XXXX. c. Virtualization solutions can control the amount of memory they want to assign to a virtual machine instance. d. A CD/DVD burner could control the amount of memory used by the rest of the system to ensure that burning does not fail due to lack of available memory. -e. There are several other use cases, find one or use the controller just +e. There are several other use cases; find one or use the controller just for fun (to learn and hack on the VM subsystem). Current Status: linux-2.6.34-mmotm(development version of 2010/April) @@ -38,12 +38,12 @@ Features: - optionally, memory+swap usage can be accounted and limited. - hierarchical accounting - soft limit - - moving(recharging) account at moving a task is selectable. + - moving (recharging) account at moving a task is selectable. - usage threshold notifier - oom-killer disable knob and oom-notifier - Root cgroup has no limit controls. - Kernel memory support is work in progress, and the current version provides + Kernel memory support is a work in progress, and the current version provides basically functionality. (See Section 2.7) Brief summary of control files. @@ -144,9 +144,9 @@ Figure 1 shows the important aspects of the controller 3. Each page has a pointer to the page_cgroup, which in turn knows the cgroup it belongs to -The accounting is done as follows: mem_cgroup_charge() is invoked to setup +The accounting is done as follows: mem_cgroup_charge() is invoked to set up the necessary data structures and check if the cgroup that is being charged -is over its limit. If it is then reclaim is invoked on the cgroup. +is over its limit. If it is, then reclaim is invoked on the cgroup. More details can be found in the reclaim section of this document. If everything goes well, a page meta-data-structure called page_cgroup is updated. page_cgroup has its own LRU on cgroup. @@ -163,13 +163,13 @@ for earlier. A file page will be accounted for as Page Cache when it's inserted into inode (radix-tree). While it's mapped into the page tables of processes, duplicate accounting is carefully avoided. -A RSS page is unaccounted when it's fully unmapped. A PageCache page is +An RSS page is unaccounted when it's fully unmapped. A PageCache page is unaccounted when it's removed from radix-tree. Even if RSS pages are fully unmapped (by kswapd), they may exist as SwapCache in the system until they -are really freed. Such SwapCaches also also accounted. +are really freed. Such SwapCaches are also accounted. A swapped-in page is not accounted until it's mapped. -Note: The kernel does swapin-readahead and read multiple swaps at once. +Note: The kernel does swapin-readahead and reads multiple swaps at once. This means swapped-in pages may contain pages for other tasks than a task causing page fault. So, we avoid accounting at swap-in I/O. @@ -209,7 +209,7 @@ memsw.limit_in_bytes. Example: Assume a system with 4G of swap. A task which allocates 6G of memory (by mistake) under 2G memory limitation will use all swap. In this case, setting memsw.limit_in_bytes=3G will prevent bad use of swap. -By using memsw limit, you can avoid system OOM which can be caused by swap +By using the memsw limit, you can avoid system OOM which can be caused by swap shortage. * why 'memory+swap' rather than swap. @@ -217,7 +217,7 @@ The global LRU(kswapd) can swap out arbitrary pages. Swap-out means to move account from memory to swap...there is no change in usage of memory+swap. In other words, when we want to limit the usage of swap without affecting global LRU, memory+swap limit is better than just limiting swap from -OS point of view. +an OS point of view. * What happens when a cgroup hits memory.memsw.limit_in_bytes When a cgroup hits memory.memsw.limit_in_bytes, it's useless to do swap-out @@ -236,7 +236,7 @@ an OOM routine is invoked to select and kill the bulkiest task in the cgroup. (See 10. OOM Control below.) The reclaim algorithm has not been modified for cgroups, except that -pages that are selected for reclaiming come from the per cgroup LRU +pages that are selected for reclaiming come from the per-cgroup LRU list. NOTE: Reclaim does not work for the root cgroup, since we cannot set any @@ -316,7 +316,7 @@ We can check the usage: # cat /sys/fs/cgroup/memory/0/memory.usage_in_bytes 1216512 -A successful write to this file does not guarantee a successful set of +A successful write to this file does not guarantee a successful setting of this limit to the value written into the file. This can be due to a number of factors, such as rounding up to page boundaries or the total availability of memory on the system. The user is required to re-read @@ -350,7 +350,7 @@ Trying usual test under memory controller is always helpful. 4.1 Troubleshooting Sometimes a user might find that the application under a cgroup is -terminated by OOM killer. There are several causes for this: +terminated by the OOM killer. There are several causes for this: 1. The cgroup limit is too low (just too low to do anything useful) 2. The user is using anonymous memory and swap is turned off or too low @@ -358,7 +358,7 @@ terminated by OOM killer. There are several causes for this: A sync followed by echo 1 > /proc/sys/vm/drop_caches will help get rid of some of the pages cached in the cgroup (page cache pages). -To know what happens, disable OOM_Kill by 10. OOM Control(see below) and +To know what happens, disabling OOM_Kill as per "10. OOM Control" (below) and seeing what happens will be helpful. 4.2 Task migration @@ -399,10 +399,10 @@ About use_hierarchy, see Section 6. Almost all pages tracked by this memory cgroup will be unmapped and freed. Some pages cannot be freed because they are locked or in-use. Such pages are - moved to parent(if use_hierarchy==1) or root (if use_hierarchy==0) and this + moved to parent (if use_hierarchy==1) or root (if use_hierarchy==0) and this cgroup will be empty. - Typical use case of this interface is that calling this before rmdir(). + The typical use case for this interface is before calling rmdir(). Because rmdir() moves all pages to parent, some out-of-use page caches can be moved to the parent. If you want to avoid that, force_empty will be useful. @@ -486,7 +486,7 @@ You can reset failcnt by writing 0 to failcnt file. For efficiency, as other kernel components, memory cgroup uses some optimization to avoid unnecessary cacheline false sharing. usage_in_bytes is affected by the -method and doesn't show 'exact' value of memory(and swap) usage, it's an fuzz +method and doesn't show 'exact' value of memory (and swap) usage, it's a fuzz value for efficient access. (Of course, when necessary, it's synchronized.) If you want to know more exact memory usage, you should use RSS+CACHE(+SWAP) value in memory.stat(see 5.2). @@ -496,8 +496,8 @@ value in memory.stat(see 5.2). This is similar to numa_maps but operates on a per-memcg basis. This is useful for providing visibility into the numa locality information within an memcg since the pages are allowed to be allocated from any physical -node. One of the usecases is evaluating application performance by -combining this information with the application's cpu allocation. +node. One of the use cases is evaluating application performance by +combining this information with the application's CPU allocation. We export "total", "file", "anon" and "unevictable" pages per-node for each memcg. The ouput format of memory.numa_stat is: @@ -561,10 +561,10 @@ are pushed back to their soft limits. If the soft limit of each control group is very high, they are pushed back as much as possible to make sure that one control group does not starve the others of memory. -Please note that soft limits is a best effort feature, it comes with +Please note that soft limits is a best-effort feature; it comes with no guarantees, but it does its best to make sure that when memory is heavily contended for, memory is allocated based on the soft limit -hints/setup. Currently soft limit based reclaim is setup such that +hints/setup. Currently soft limit based reclaim is set up such that it gets invoked from balance_pgdat (kswapd). 7.1 Interface @@ -592,7 +592,7 @@ page tables. 8.1 Interface -This feature is disabled by default. It can be enabled(and disabled again) by +This feature is disabled by default. It can be enabledi (and disabled again) by writing to memory.move_charge_at_immigrate of the destination cgroup. If you want to enable it: @@ -601,8 +601,8 @@ If you want to enable it: Note: Each bits of move_charge_at_immigrate has its own meaning about what type of charges should be moved. See 8.2 for details. -Note: Charges are moved only when you move mm->owner, IOW, a leader of a thread - group. +Note: Charges are moved only when you move mm->owner, in other words, + a leader of a thread group. Note: If we cannot find enough space for the task in the destination cgroup, we try to make space by reclaiming memory. Task migration may fail if we cannot make enough space. @@ -612,25 +612,25 @@ And if you want disable it again: # echo 0 > memory.move_charge_at_immigrate -8.2 Type of charges which can be move +8.2 Type of charges which can be moved -Each bits of move_charge_at_immigrate has its own meaning about what type of -charges should be moved. But in any cases, it must be noted that an account of -a page or a swap can be moved only when it is charged to the task's current(old) -memory cgroup. +Each bit in move_charge_at_immigrate has its own meaning about what type of +charges should be moved. But in any case, it must be noted that an account of +a page or a swap can be moved only when it is charged to the task's current +(old) memory cgroup. bit | what type of charges would be moved ? -----+------------------------------------------------------------------------ - 0 | A charge of an anonymous page(or swap of it) used by the target task. - | You must enable Swap Extension(see 2.4) to enable move of swap charges. + 0 | A charge of an anonymous page (or swap of it) used by the target task. + | You must enable Swap Extension (see 2.4) to enable move of swap charges. -----+------------------------------------------------------------------------ - 1 | A charge of file pages(normal file, tmpfs file(e.g. ipc shared memory) + 1 | A charge of file pages (normal file, tmpfs file (e.g. ipc shared memory) | and swaps of tmpfs file) mmapped by the target task. Unlike the case of - | anonymous pages, file pages(and swaps) in the range mmapped by the task + | anonymous pages, file pages (and swaps) in the range mmapped by the task | will be moved even if the task hasn't done page fault, i.e. they might | not be the task's "RSS", but other task's "RSS" that maps the same file. - | And mapcount of the page is ignored(the page can be moved even if - | page_mapcount(page) > 1). You must enable Swap Extension(see 2.4) to + | And mapcount of the page is ignored (the page can be moved even if + | page_mapcount(page) > 1). You must enable Swap Extension (see 2.4) to | enable move of swap charges. 8.3 TODO @@ -640,11 +640,11 @@ memory cgroup. 9. Memory thresholds -Memory cgroup implements memory thresholds using cgroups notification +Memory cgroup implements memory thresholds using the cgroups notification API (see cgroups.txt). It allows to register multiple memory and memsw thresholds and gets notifications when it crosses. -To register a threshold application need: +To register a threshold, an application must: - create an eventfd using eventfd(2); - open memory.usage_in_bytes or memory.memsw.usage_in_bytes; - write string like "<event_fd> <fd of memory.usage_in_bytes> <threshold>" to @@ -659,24 +659,24 @@ It's applicable for root and non-root cgroup. memory.oom_control file is for OOM notification and other controls. -Memory cgroup implements OOM notifier using cgroup notification +Memory cgroup implements OOM notifier using the cgroup notification API (See cgroups.txt). It allows to register multiple OOM notification delivery and gets notification when OOM happens. -To register a notifier, application need: +To register a notifier, an application must: - create an eventfd using eventfd(2) - open memory.oom_control file - write string like "<event_fd> <fd of memory.oom_control>" to cgroup.event_control -Application will be notified through eventfd when OOM happens. -OOM notification doesn't work for root cgroup. +The application will be notified through eventfd when OOM happens. +OOM notification doesn't work for the root cgroup. -You can disable OOM-killer by writing "1" to memory.oom_control file, as: +You can disable the OOM-killer by writing "1" to memory.oom_control file, as: #echo 1 > memory.oom_control -This operation is only allowed to the top cgroup of sub-hierarchy. +This operation is only allowed to the top cgroup of a sub-hierarchy. If OOM-killer is disabled, tasks under cgroup will hang/sleep in memory cgroup's OOM-waitqueue when they request accountable memory. diff --git a/Documentation/crypto/asymmetric-keys.txt b/Documentation/crypto/asymmetric-keys.txt new file mode 100644 index 000000000000..b7675904a747 --- /dev/null +++ b/Documentation/crypto/asymmetric-keys.txt @@ -0,0 +1,312 @@ + ============================================= + ASYMMETRIC / PUBLIC-KEY CRYPTOGRAPHY KEY TYPE + ============================================= + +Contents: + + - Overview. + - Key identification. + - Accessing asymmetric keys. + - Signature verification. + - Asymmetric key subtypes. + - Instantiation data parsers. + + +======== +OVERVIEW +======== + +The "asymmetric" key type is designed to be a container for the keys used in +public-key cryptography, without imposing any particular restrictions on the +form or mechanism of the cryptography or form of the key. + +The asymmetric key is given a subtype that defines what sort of data is +associated with the key and provides operations to describe and destroy it. +However, no requirement is made that the key data actually be stored in the +key. + +A completely in-kernel key retention and operation subtype can be defined, but +it would also be possible to provide access to cryptographic hardware (such as +a TPM) that might be used to both retain the relevant key and perform +operations using that key. In such a case, the asymmetric key would then +merely be an interface to the TPM driver. + +Also provided is the concept of a data parser. Data parsers are responsible +for extracting information from the blobs of data passed to the instantiation +function. The first data parser that recognises the blob gets to set the +subtype of the key and define the operations that can be done on that key. + +A data parser may interpret the data blob as containing the bits representing a +key, or it may interpret it as a reference to a key held somewhere else in the +system (for example, a TPM). + + +================== +KEY IDENTIFICATION +================== + +If a key is added with an empty name, the instantiation data parsers are given +the opportunity to pre-parse a key and to determine the description the key +should be given from the content of the key. + +This can then be used to refer to the key, either by complete match or by +partial match. The key type may also use other criteria to refer to a key. + +The asymmetric key type's match function can then perform a wider range of +comparisons than just the straightforward comparison of the description with +the criterion string: + + (1) If the criterion string is of the form "id:<hexdigits>" then the match + function will examine a key's fingerprint to see if the hex digits given + after the "id:" match the tail. For instance: + + keyctl search @s asymmetric id:5acc2142 + + will match a key with fingerprint: + + 1A00 2040 7601 7889 DE11 882C 3823 04AD 5ACC 2142 + + (2) If the criterion string is of the form "<subtype>:<hexdigits>" then the + match will match the ID as in (1), but with the added restriction that + only keys of the specified subtype (e.g. tpm) will be matched. For + instance: + + keyctl search @s asymmetric tpm:5acc2142 + +Looking in /proc/keys, the last 8 hex digits of the key fingerprint are +displayed, along with the subtype: + + 1a39e171 I----- 1 perm 3f010000 0 0 asymmetri modsign.0: DSA 5acc2142 [] + + +========================= +ACCESSING ASYMMETRIC KEYS +========================= + +For general access to asymmetric keys from within the kernel, the following +inclusion is required: + + #include <crypto/public_key.h> + +This gives access to functions for dealing with asymmetric / public keys. +Three enums are defined there for representing public-key cryptography +algorithms: + + enum pkey_algo + +digest algorithms used by those: + + enum pkey_hash_algo + +and key identifier representations: + + enum pkey_id_type + +Note that the key type representation types are required because key +identifiers from different standards aren't necessarily compatible. For +instance, PGP generates key identifiers by hashing the key data plus some +PGP-specific metadata, whereas X.509 has arbitrary certificate identifiers. + +The operations defined upon a key are: + + (1) Signature verification. + +Other operations are possible (such as encryption) with the same key data +required for verification, but not currently supported, and others +(eg. decryption and signature generation) require extra key data. + + +SIGNATURE VERIFICATION +---------------------- + +An operation is provided to perform cryptographic signature verification, using +an asymmetric key to provide or to provide access to the public key. + + int verify_signature(const struct key *key, + const struct public_key_signature *sig); + +The caller must have already obtained the key from some source and can then use +it to check the signature. The caller must have parsed the signature and +transferred the relevant bits to the structure pointed to by sig. + + struct public_key_signature { + u8 *digest; + u8 digest_size; + enum pkey_hash_algo pkey_hash_algo : 8; + u8 nr_mpi; + union { + MPI mpi[2]; + ... + }; + }; + +The algorithm used must be noted in sig->pkey_hash_algo, and all the MPIs that +make up the actual signature must be stored in sig->mpi[] and the count of MPIs +placed in sig->nr_mpi. + +In addition, the data must have been digested by the caller and the resulting +hash must be pointed to by sig->digest and the size of the hash be placed in +sig->digest_size. + +The function will return 0 upon success or -EKEYREJECTED if the signature +doesn't match. + +The function may also return -ENOTSUPP if an unsupported public-key algorithm +or public-key/hash algorithm combination is specified or the key doesn't +support the operation; -EBADMSG or -ERANGE if some of the parameters have weird +data; or -ENOMEM if an allocation can't be performed. -EINVAL can be returned +if the key argument is the wrong type or is incompletely set up. + + +======================= +ASYMMETRIC KEY SUBTYPES +======================= + +Asymmetric keys have a subtype that defines the set of operations that can be +performed on that key and that determines what data is attached as the key +payload. The payload format is entirely at the whim of the subtype. + +The subtype is selected by the key data parser and the parser must initialise +the data required for it. The asymmetric key retains a reference on the +subtype module. + +The subtype definition structure can be found in: + + #include <keys/asymmetric-subtype.h> + +and looks like the following: + + struct asymmetric_key_subtype { + struct module *owner; + const char *name; + + void (*describe)(const struct key *key, struct seq_file *m); + void (*destroy)(void *payload); + int (*verify_signature)(const struct key *key, + const struct public_key_signature *sig); + }; + +Asymmetric keys point to this with their type_data[0] member. + +The owner and name fields should be set to the owning module and the name of +the subtype. Currently, the name is only used for print statements. + +There are a number of operations defined by the subtype: + + (1) describe(). + + Mandatory. This allows the subtype to display something in /proc/keys + against the key. For instance the name of the public key algorithm type + could be displayed. The key type will display the tail of the key + identity string after this. + + (2) destroy(). + + Mandatory. This should free the memory associated with the key. The + asymmetric key will look after freeing the fingerprint and releasing the + reference on the subtype module. + + (3) verify_signature(). + + Optional. These are the entry points for the key usage operations. + Currently there is only the one defined. If not set, the caller will be + given -ENOTSUPP. The subtype may do anything it likes to implement an + operation, including offloading to hardware. + + +========================== +INSTANTIATION DATA PARSERS +========================== + +The asymmetric key type doesn't generally want to store or to deal with a raw +blob of data that holds the key data. It would have to parse it and error +check it each time it wanted to use it. Further, the contents of the blob may +have various checks that can be performed on it (eg. self-signatures, validity +dates) and may contain useful data about the key (identifiers, capabilities). + +Also, the blob may represent a pointer to some hardware containing the key +rather than the key itself. + +Examples of blob formats for which parsers could be implemented include: + + - OpenPGP packet stream [RFC 4880]. + - X.509 ASN.1 stream. + - Pointer to TPM key. + - Pointer to UEFI key. + +During key instantiation each parser in the list is tried until one doesn't +return -EBADMSG. + +The parser definition structure can be found in: + + #include <keys/asymmetric-parser.h> + +and looks like the following: + + struct asymmetric_key_parser { + struct module *owner; + const char *name; + + int (*parse)(struct key_preparsed_payload *prep); + }; + +The owner and name fields should be set to the owning module and the name of +the parser. + +There is currently only a single operation defined by the parser, and it is +mandatory: + + (1) parse(). + + This is called to preparse the key from the key creation and update paths. + In particular, it is called during the key creation _before_ a key is + allocated, and as such, is permitted to provide the key's description in + the case that the caller declines to do so. + + The caller passes a pointer to the following struct with all of the fields + cleared, except for data, datalen and quotalen [see + Documentation/security/keys.txt]. + + struct key_preparsed_payload { + char *description; + void *type_data[2]; + void *payload; + const void *data; + size_t datalen; + size_t quotalen; + }; + + The instantiation data is in a blob pointed to by data and is datalen in + size. The parse() function is not permitted to change these two values at + all, and shouldn't change any of the other values _unless_ they are + recognise the blob format and will not return -EBADMSG to indicate it is + not theirs. + + If the parser is happy with the blob, it should propose a description for + the key and attach it to ->description, ->type_data[0] should be set to + point to the subtype to be used, ->payload should be set to point to the + initialised data for that subtype, ->type_data[1] should point to a hex + fingerprint and quotalen should be updated to indicate how much quota this + key should account for. + + When clearing up, the data attached to ->type_data[1] and ->description + will be kfree()'d and the data attached to ->payload will be passed to the + subtype's ->destroy() method to be disposed of. A module reference for + the subtype pointed to by ->type_data[0] will be put. + + + If the data format is not recognised, -EBADMSG should be returned. If it + is recognised, but the key cannot for some reason be set up, some other + negative error code should be returned. On success, 0 should be returned. + + The key's fingerprint string may be partially matched upon. For a + public-key algorithm such as RSA and DSA this will likely be a printable + hex version of the key's fingerprint. + +Functions are provided to register and unregister parsers: + + int register_asymmetric_key_parser(struct asymmetric_key_parser *parser); + void unregister_asymmetric_key_parser(struct asymmetric_key_parser *subtype); + +Parsers may not have the same name. The names are otherwise only used for +displaying in debugging messages. diff --git a/Documentation/device-mapper/dm-raid.txt b/Documentation/device-mapper/dm-raid.txt index 1c1844957166..728c38c242d6 100644 --- a/Documentation/device-mapper/dm-raid.txt +++ b/Documentation/device-mapper/dm-raid.txt @@ -132,3 +132,12 @@ Here we can see the RAID type is raid4, there are 5 devices - all of which are 'A'live, and the array is 2/490221568 complete with recovery. Faulty or missing devices are marked 'D'. Devices that are out-of-sync are marked 'a'. + + +Version History +--------------- +1.0.0 Initial version. Support for RAID 4/5/6 +1.1.0 Added support for RAID 1 +1.2.0 Handle creation of arrays that contain failed devices. +1.3.0 Added support for RAID 10 +1.3.1 Allow device replacement/rebuild for RAID 10 diff --git a/Documentation/devicetree/bindings/arm/arm-boards b/Documentation/devicetree/bindings/arm/arm-boards index 91f26148af79..fc81a7d6b0f1 100644 --- a/Documentation/devicetree/bindings/arm/arm-boards +++ b/Documentation/devicetree/bindings/arm/arm-boards @@ -1,3 +1,15 @@ +ARM Integrator/AP (Application Platform) and Integrator/CP (Compact Platform) +----------------------------------------------------------------------------- +ARM's oldest Linux-supported platform with connectors for different core +tiles of ARMv4, ARMv5 and ARMv6 type. + +Required properties (in root node): + compatible = "arm,integrator-ap"; /* Application Platform */ + compatible = "arm,integrator-cp"; /* Compact Platform */ + +FPGA type interrupt controllers, see the versatile-fpga-irq binding doc. + + ARM Versatile Application and Platform Baseboards ------------------------------------------------- ARM's development hardware platform with connectors for customizable diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.txt b/Documentation/devicetree/bindings/arm/atmel-at91.txt index ecc81e368715..d187e9f7cf1c 100644 --- a/Documentation/devicetree/bindings/arm/atmel-at91.txt +++ b/Documentation/devicetree/bindings/arm/atmel-at91.txt @@ -8,7 +8,7 @@ PIT Timer required properties: shared across all System Controller members. TC/TCLIB Timer required properties: -- compatible: Should be "atmel,<chip>-pit". +- compatible: Should be "atmel,<chip>-tcb". <chip> can be "at91rm9200" or "at91sam9x5" - reg: Should contain registers location and length - interrupts: Should contain all interrupts for the TC block diff --git a/Documentation/devicetree/bindings/arm/davinci/nand.txt b/Documentation/devicetree/bindings/arm/davinci/nand.txt new file mode 100644 index 000000000000..e37241f1fdd8 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/davinci/nand.txt @@ -0,0 +1,51 @@ +* Texas Instruments Davinci NAND + +This file provides information, what the device node for the +davinci nand interface contain. + +Required properties: +- compatible: "ti,davinci-nand"; +- reg : contain 2 offset/length values: + - offset and length for the access window + - offset and length for accessing the aemif control registers +- ti,davinci-chipselect: Indicates on the davinci_nand driver which + chipselect is used for accessing the nand. + +Recommended properties : +- ti,davinci-mask-ale: mask for ale +- ti,davinci-mask-cle: mask for cle +- ti,davinci-mask-chipsel: mask for chipselect +- ti,davinci-ecc-mode: ECC mode valid values for davinci driver: + - "none" + - "soft" + - "hw" +- ti,davinci-ecc-bits: used ECC bits, currently supported 1 or 4. +- ti,davinci-nand-buswidth: buswidth 8 or 16 +- ti,davinci-nand-use-bbt: use flash based bad block table support. + +Example (enbw_cmc board): +aemif@60000000 { + compatible = "ti,davinci-aemif"; + #address-cells = <2>; + #size-cells = <1>; + reg = <0x68000000 0x80000>; + ranges = <2 0 0x60000000 0x02000000 + 3 0 0x62000000 0x02000000 + 4 0 0x64000000 0x02000000 + 5 0 0x66000000 0x02000000 + 6 0 0x68000000 0x02000000>; + nand@3,0 { + compatible = "ti,davinci-nand"; + reg = <3 0x0 0x807ff + 6 0x0 0x8000>; + #address-cells = <1>; + #size-cells = <1>; + ti,davinci-chipselect = <1>; + ti,davinci-mask-ale = <0>; + ti,davinci-mask-cle = <0>; + ti,davinci-mask-chipsel = <0>; + ti,davinci-ecc-mode = "hw"; + ti,davinci-ecc-bits = <4>; + ti,davinci-nand-use-bbt; + }; +}; diff --git a/Documentation/devicetree/bindings/arm/versatile-fpga-irq.txt b/Documentation/devicetree/bindings/arm/versatile-fpga-irq.txt new file mode 100644 index 000000000000..9989eda755d9 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/versatile-fpga-irq.txt @@ -0,0 +1,31 @@ +* ARM Versatile FPGA interrupt controller + +One or more FPGA IRQ controllers can be synthesized in an ARM reference board +such as the Integrator or Versatile family. The output of these different +controllers are OR:ed together and fed to the CPU tile's IRQ input. Each +instance can handle up to 32 interrupts. + +Required properties: +- compatible: "arm,versatile-fpga-irq" +- interrupt-controller: Identifies the node as an interrupt controller +- #interrupt-cells: The number of cells to define the interrupts. Must be 1 + as the FPGA IRQ controller has no configuration options for interrupt + sources. The cell is a u32 and defines the interrupt number. +- reg: The register bank for the FPGA interrupt controller. +- clear-mask: a u32 number representing the mask written to clear all IRQs + on the controller at boot for example. +- valid-mask: a u32 number representing a bit mask determining which of + the interrupts are valid. Unconnected/unused lines are set to 0, and + the system till not make it possible for devices to request these + interrupts. + +Example: + +pic: pic@14000000 { + compatible = "arm,versatile-fpga-irq"; + #interrupt-cells = <1>; + interrupt-controller; + reg = <0x14000000 0x100>; + clear-mask = <0xffffffff>; + valid-mask = <0x003fffff>; +}; diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt new file mode 100644 index 000000000000..0f7b9c2109f8 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/xen.txt @@ -0,0 +1,25 @@ +* Xen hypervisor device tree bindings + +Xen ARM virtual platforms shall have a top-level "hypervisor" node with +the following properties: + +- compatible: + compatible = "xen,xen-<version>", "xen,xen"; + where <version> is the version of the Xen ABI of the platform. + +- reg: specifies the base physical address and size of a region in + memory where the grant table should be mapped to, using an + HYPERVISOR_memory_op hypercall. The memory region is large enough to map + the whole grant table (it is larger or equal to gnttab_max_grant_frames()). + +- interrupts: the interrupt used by Xen to inject event notifications. + A GIC node is also required. + + +Example (assuming #address-cells = <2> and #size-cells = <2>): + +hypervisor { + compatible = "xen,xen-4.3", "xen,xen"; + reg = <0 0xb0000000 0 0x20000>; + interrupts = <1 15 0xf08>; +}; diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt index bf57ecd5d73a..bd7ce120bc13 100644 --- a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt +++ b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt @@ -9,6 +9,7 @@ Copyright (C) 2008-2011 Freescale Semiconductor Inc. -Run Time Integrity Check (RTIC) Node -Run Time Integrity Check (RTIC) Memory Node -Secure Non-Volatile Storage (SNVS) Node + -Secure Non-Volatile Storage (SNVS) Low Power (LP) RTC Node -Full Example NOTE: the SEC 4 is also known as Freescale's Cryptographic Accelerator @@ -294,6 +295,27 @@ Secure Non-Volatile Storage (SNVS) Node address and length of the SEC4 configuration registers. + - #address-cells + Usage: required + Value type: <u32> + Definition: A standard property. Defines the number of cells + for representing physical addresses in child nodes. Must + have a value of 1. + + - #size-cells + Usage: required + Value type: <u32> + Definition: A standard property. Defines the number of cells + for representing the size of physical addresses in + child nodes. Must have a value of 1. + + - ranges + Usage: required + Value type: <prop-encoded-array> + Definition: A standard property. Specifies the physical address + range of the SNVS register space. A triplet that includes + the child address, parent address, & length. + - interrupts Usage: required Value type: <prop_encoded-array> @@ -314,11 +336,34 @@ EXAMPLE sec_mon@314000 { compatible = "fsl,sec-v4.0-mon"; reg = <0x314000 0x1000>; + ranges = <0 0x314000 0x1000>; interrupt-parent = <&mpic>; interrupts = <93 2>; }; ===================================================================== +Secure Non-Volatile Storage (SNVS) Low Power (LP) RTC Node + + A SNVS child node that defines SNVS LP RTC. + + - compatible + Usage: required + Value type: <string> + Definition: Must include "fsl,sec-v4.0-mon-rtc-lp". + + - reg + Usage: required + Value type: <prop-encoded-array> + Definition: A standard property. Specifies the physical + address and length of the SNVS LP configuration registers. + +EXAMPLE + sec_mon_rtc_lp@314000 { + compatible = "fsl,sec-v4.0-mon-rtc-lp"; + reg = <0x34 0x58>; + }; + +===================================================================== FULL EXAMPLE crypto: crypto@300000 { @@ -390,8 +435,14 @@ FULL EXAMPLE sec_mon: sec_mon@314000 { compatible = "fsl,sec-v4.0-mon"; reg = <0x314000 0x1000>; + ranges = <0 0x314000 0x1000>; interrupt-parent = <&mpic>; interrupts = <93 2>; + + sec_mon_rtc_lp@34 { + compatible = "fsl,sec-v4.0-mon-rtc-lp"; + reg = <0x34 0x58>; + }; }; ===================================================================== diff --git a/Documentation/devicetree/bindings/crypto/mv_cesa.txt b/Documentation/devicetree/bindings/crypto/mv_cesa.txt new file mode 100644 index 000000000000..47229b1a594b --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/mv_cesa.txt @@ -0,0 +1,20 @@ +Marvell Cryptographic Engines And Security Accelerator + +Required properties: +- compatible : should be "marvell,orion-crypto" +- reg : base physical address of the engine and length of memory mapped + region, followed by base physical address of sram and its memory + length +- reg-names : "regs" , "sram"; +- interrupts : interrupt number + +Examples: + + crypto@30000 { + compatible = "marvell,orion-crypto"; + reg = <0x30000 0x10000>, + <0x4000000 0x800>; + reg-names = "regs" , "sram"; + interrupts = <22>; + status = "okay"; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-fan.txt b/Documentation/devicetree/bindings/gpio/gpio-fan.txt new file mode 100644 index 000000000000..2dd457a3469a --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-fan.txt @@ -0,0 +1,25 @@ +Bindings for fan connected to GPIO lines + +Required properties: +- compatible : "gpio-fan" +- gpios: Specifies the pins that map to bits in the control value, + ordered MSB-->LSB. +- gpio-fan,speed-map: A mapping of possible fan RPM speeds and the + control value that should be set to achieve them. This array + must have the RPM values in ascending order. + +Optional properties: +- alarm-gpios: This pin going active indicates something is wrong with + the fan, and a udev event will be fired. + +Examples: + + gpio_fan { + compatible = "gpio-fan"; + gpios = <&gpio1 14 1 + &gpio1 13 1>; + gpio-fan,speed-map = <0 0 + 3000 1 + 6000 2>; + alarm-gpios = <&gpio1 15 1>; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt b/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt new file mode 100644 index 000000000000..a6f3bec1da7d --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-mvebu.txt @@ -0,0 +1,53 @@ +* Marvell EBU GPIO controller + +Required properties: + +- compatible : Should be "marvell,orion-gpio", "marvell,mv78200-gpio" + or "marvell,armadaxp-gpio". "marvell,orion-gpio" should be used for + Orion, Kirkwood, Dove, Discovery (except MV78200) and Armada + 370. "marvell,mv78200-gpio" should be used for the Discovery + MV78200. "marvel,armadaxp-gpio" should be used for all Armada XP + SoCs (MV78230, MV78260, MV78460). + +- reg: Address and length of the register set for the device. Only one + entry is expected, except for the "marvell,armadaxp-gpio" variant + for which two entries are expected: one for the general registers, + one for the per-cpu registers. + +- interrupts: The list of interrupts that are used for all the pins + managed by this GPIO bank. There can be more than one interrupt + (example: 1 interrupt per 8 pins on Armada XP, which means 4 + interrupts per bank of 32 GPIOs). + +- interrupt-controller: identifies the node as an interrupt controller + +- #interrupt-cells: specifies the number of cells needed to encode an + interrupt source. Should be two. + The first cell is the GPIO number. + The second cell is used to specify flags: + bits[3:0] trigger type and level flags: + 1 = low-to-high edge triggered. + 2 = high-to-low edge triggered. + 4 = active high level-sensitive. + 8 = active low level-sensitive. + +- gpio-controller: marks the device node as a gpio controller + +- ngpios: number of GPIOs this controller has + +- #gpio-cells: Should be two. The first cell is the pin number. The + second cell is reserved for flags, unused at the moment. + +Example: + + gpio0: gpio@d0018100 { + compatible = "marvell,armadaxp-gpio"; + reg = <0xd0018100 0x40>, + <0xd0018800 0x30>; + ngpios = <32>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + interrupts = <16>, <17>, <18>, <19>; + }; diff --git a/Documentation/devicetree/bindings/i2c/atmel-i2c.txt b/Documentation/devicetree/bindings/i2c/atmel-i2c.txt new file mode 100644 index 000000000000..b689a0d9441c --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/atmel-i2c.txt @@ -0,0 +1,30 @@ +I2C for Atmel platforms + +Required properties : +- compatible : Must be "atmel,at91rm9200-i2c", "atmel,at91sam9261-i2c", + "atmel,at91sam9260-i2c", "atmel,at91sam9g20-i2c", "atmel,at91sam9g10-i2c" + or "atmel,at91sam9x5-i2c" +- reg: physical base address of the controller and length of memory mapped + region. +- interrupts: interrupt number to the cpu. +- #address-cells = <1>; +- #size-cells = <0>; + +Optional properties: +- Child nodes conforming to i2c bus binding + +Examples : + +i2c0: i2c@fff84000 { + compatible = "atmel,at91sam9g20-i2c"; + reg = <0xfff84000 0x100>; + interrupts = <12 4 6>; + #address-cells = <1>; + #size-cells = <0>; + + 24c512@50 { + compatible = "24c512"; + reg = <0x50>; + pagesize = <128>; + } +} diff --git a/Documentation/devicetree/bindings/i2c/davinci.txt b/Documentation/devicetree/bindings/i2c/davinci.txt new file mode 100644 index 000000000000..2dc935b4113d --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/davinci.txt @@ -0,0 +1,28 @@ +* Texas Instruments Davinci I2C + +This file provides information, what the device node for the +davinci i2c interface contain. + +Required properties: +- compatible: "ti,davinci-i2c"; +- reg : Offset and length of the register set for the device + +Recommended properties : +- interrupts : standard interrupt property. +- clock-frequency : desired I2C bus clock frequency in Hz. + +Example (enbw_cmc board): + i2c@1c22000 { + compatible = "ti,davinci-i2c"; + reg = <0x22000 0x1000>; + clock-frequency = <100000>; + interrupts = <15>; + interrupt-parent = <&intc>; + #address-cells = <1>; + #size-cells = <0>; + + dtt@48 { + compatible = "national,lm75"; + reg = <0x48>; + }; + }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-mxs.txt b/Documentation/devicetree/bindings/i2c/i2c-mxs.txt index 30ac3a0557f7..7a3fe9e5f4cb 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mxs.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mxs.txt @@ -6,6 +6,7 @@ Required properties: - interrupts: Should contain ERROR and DMA interrupts - clock-frequency: Desired I2C bus clock frequency in Hz. Only 100000Hz and 400000Hz modes are supported. +- fsl,i2c-dma-channel: APBX DMA channel for the I2C Examples: @@ -16,4 +17,5 @@ i2c0: i2c@80058000 { reg = <0x80058000 2000>; interrupts = <111 68>; clock-frequency = <100000>; + fsl,i2c-dma-channel = <6>; }; diff --git a/Documentation/devicetree/bindings/i2c/nomadik.txt b/Documentation/devicetree/bindings/i2c/nomadik.txt new file mode 100644 index 000000000000..72065b0ff680 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/nomadik.txt @@ -0,0 +1,23 @@ +I2C for Nomadik based systems + +Required (non-standard) properties: + - Nil + +Recommended (non-standard) properties: + - clock-frequency : Maximum bus clock frequency for the device + +Optional (non-standard) properties: + - Nil + +Example : + +i2c@80004000 { + compatible = "stericsson,db8500-i2c", "st,nomadik-i2c"; + reg = <0x80004000 0x1000>; + interrupts = <0 21 0x4>; + #address-cells = <1>; + #size-cells = <0>; + v-i2c-supply = <&db8500_vape_reg>; + + clock-frequency = <400000>; +}; diff --git a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt index 548892c08c59..7da578d72123 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt @@ -7,7 +7,7 @@ as "armctrl" in the SoC documentation, hence naming of this binding. Required properties: -- compatible : should be "brcm,bcm2835-armctrl-ic.txt" +- compatible : should be "brcm,bcm2835-armctrl-ic" - reg : Specifies base physical address and size of the registers. - interrupt-controller : Identifies the node as an interrupt controller - #interrupt-cells : Specifies the number of cells needed to encode an diff --git a/Documentation/devicetree/bindings/mfd/88pm860x.txt b/Documentation/devicetree/bindings/mfd/88pm860x.txt new file mode 100644 index 000000000000..63f3ee33759c --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/88pm860x.txt @@ -0,0 +1,85 @@ +* Marvell 88PM860x Power Management IC + +Required parent device properties: +- compatible : "marvell,88pm860x" +- reg : the I2C slave address for the 88pm860x chip +- interrupts : IRQ line for the 88pm860x chip +- interrupt-controller: describes the 88pm860x as an interrupt controller (has its own domain) +- #interrupt-cells : should be 1. + - The cell is the 88pm860x local IRQ number + +Optional parent device properties: +- marvell,88pm860x-irq-read-clr: inicates whether interrupt status is cleared by read +- marvell,88pm860x-slave-addr: 88pm860x are two chips solution. <reg> stores the I2C address + of one chip, and this property stores the I2C address of + another chip. + +88pm860x consists of a large and varied group of sub-devices: + +Device Supply Names Description +------ ------------ ----------- +88pm860x-onkey : : On key +88pm860x-rtc : : RTC +88pm8607 : : Regulators +88pm860x-backlight : : Backlight +88pm860x-led : : Led +88pm860x-touch : : Touchscreen + +Example: + + pmic: 88pm860x@34 { + compatible = "marvell,88pm860x"; + reg = <0x34>; + interrupts = <4>; + interrupt-parent = <&intc>; + interrupt-controller; + #interrupt-cells = <1>; + + marvell,88pm860x-irq-read-clr; + marvell,88pm860x-slave-addr = <0x11>; + + regulators { + BUCK1 { + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1500000>; + regulator-boot-on; + regulator-always-on; + }; + LDO1 { + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <2800000>; + regulator-boot-on; + regulator-always-on; + }; + }; + rtc { + marvell,88pm860x-vrtc = <1>; + }; + touch { + marvell,88pm860x-gpadc-prebias = <1>; + marvell,88pm860x-gpadc-slot-cycle = <1>; + marvell,88pm860x-tsi-prebias = <6>; + marvell,88pm860x-pen-prebias = <16>; + marvell,88pm860x-pen-prechg = <2>; + marvell,88pm860x-resistor-X = <300>; + }; + backlights { + backlight-0 { + marvell,88pm860x-iset = <4>; + marvell,88pm860x-pwm = <3>; + }; + backlight-2 { + }; + }; + leds { + led0-red { + marvell,88pm860x-iset = <12>; + }; + led0-green { + marvell,88pm860x-iset = <12>; + }; + led0-blue { + marvell,88pm860x-iset = <12>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/syscon.txt b/Documentation/devicetree/bindings/mfd/syscon.txt new file mode 100644 index 000000000000..fe8150bb3248 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/syscon.txt @@ -0,0 +1,20 @@ +* System Controller Registers R/W driver + +System controller node represents a register region containing a set +of miscellaneous registers. The registers are not cohesive enough to +represent as any specific type of device. The typical use-case is for +some other node's driver, or platform-specific code, to acquire a +reference to the syscon node (e.g. by phandle, node path, or search +using a specific compatible value), interrogate the node (or associated +OS driver) to determine the location of the registers, and access the +registers directly. + +Required properties: +- compatible: Should contain "syscon". +- reg: the register region can be accessed from syscon + +Examples: +gpr: iomuxc-gpr@020e0000 { + compatible = "fsl,imx6q-iomuxc-gpr", "syscon"; + reg = <0x020e0000 0x38>; +}; diff --git a/Documentation/devicetree/bindings/mfd/tps65910.txt b/Documentation/devicetree/bindings/mfd/tps65910.txt index db03599ae4dc..2e3304888ffc 100644 --- a/Documentation/devicetree/bindings/mfd/tps65910.txt +++ b/Documentation/devicetree/bindings/mfd/tps65910.txt @@ -59,6 +59,8 @@ Optional properties: in TPS6591X datasheet) - ti,en-gpio-sleep: enable sleep control for gpios There should be 9 entries here, one for each gpio. +- ti,system-power-controller: Telling whether or not this pmic is controlling + the system power. Regulator Optional properties: - ti,regulator-ext-sleep-control: enable external sleep @@ -79,6 +81,8 @@ Example: #interrupt-cells = <2>; interrupt-controller; + ti,system-power-controller; + ti,vmbch-threshold = 0; ti,vmbch2-threshold = 0; ti,en-ck32k-xtal; diff --git a/Documentation/devicetree/bindings/mfd/twl4030-audio.txt b/Documentation/devicetree/bindings/mfd/twl4030-audio.txt new file mode 100644 index 000000000000..414d2ae0adf6 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/twl4030-audio.txt @@ -0,0 +1,46 @@ +Texas Instruments TWL family (twl4030) audio module + +The audio module inside the TWL family consist of an audio codec and a vibra +driver. + +Required properties: +- compatible : must be "ti,twl4030-audio" + +Optional properties, nodes: + +Audio functionality: +- codec { }: Need to be present if the audio functionality is used. Within this + section the following options can be used: +- ti,digimic_delay: Delay need after enabling the digimic to reduce artifacts + from the start of the recorded sample (in ms) +-ti,ramp_delay_value: HS ramp delay configuration to reduce pop noise +-ti,hs_extmute: Use external mute for HS pop reduction +-ti,hs_extmute_gpio: Use external GPIO to control the external mute +-ti,offset_cncl_path: Offset cancellation path selection, refer to TRM for the + valid values. + +Vibra functionality +- ti,enable-vibra: Need to be set to <1> if the vibra functionality is used. if + missing or it is 0, the vibra functionality is disabled. + +Example: +&i2c1 { + clock-frequency = <2600000>; + + twl: twl@48 { + reg = <0x48>; + interrupts = <7>; /* SYS_NIRQ cascaded to intc */ + interrupt-parent = <&intc>; + + twl_audio: audio { + compatible = "ti,twl4030-audio"; + + ti,enable-vibra = <1>; + + codec { + ti,ramp_delay_value = <3>; + }; + + }; + }; +}; diff --git a/Documentation/devicetree/bindings/mfd/twl6040.txt b/Documentation/devicetree/bindings/mfd/twl6040.txt index c855240f3a0e..0f5dd709d752 100644 --- a/Documentation/devicetree/bindings/mfd/twl6040.txt +++ b/Documentation/devicetree/bindings/mfd/twl6040.txt @@ -1,7 +1,7 @@ Texas Instruments TWL6040 family -The TWL6040s are 8-channel high quality low-power audio codecs providing audio -and vibra functionality on OMAP4+ platforms. +The TWL6040s are 8-channel high quality low-power audio codecs providing audio, +vibra and GPO functionality on OMAP4+ platforms. They are connected ot the host processor via i2c for commands, McPDM for audio data and commands. @@ -10,6 +10,8 @@ Required properties: - reg: must be 0x4b for i2c address - interrupts: twl6040 has one interrupt line connecteded to the main SoC - interrupt-parent: The parent interrupt controller +- gpio-controller: +- #gpio-cells = <1>: twl6040 provides GPO lines. - twl6040,audpwron-gpio: Power on GPIO line for the twl6040 - vio-supply: Regulator for the twl6040 VIO supply @@ -37,7 +39,6 @@ Example: &i2c1 { twl6040: twl@4b { compatible = "ti,twl6040"; - reg = <0x4b>; interrupts = <0 119 4>; interrupt-parent = <&gic>; @@ -60,3 +61,5 @@ Example: }; }; }; + +/include/ "twl6040.dtsi" diff --git a/Documentation/devicetree/bindings/misc/ifm-csi.txt b/Documentation/devicetree/bindings/misc/ifm-csi.txt new file mode 100644 index 000000000000..5bdfffb0b9f7 --- /dev/null +++ b/Documentation/devicetree/bindings/misc/ifm-csi.txt @@ -0,0 +1,41 @@ +IFM camera sensor interface on mpc5200 LocalPlus bus + +Required properties: +- compatible: "ifm,o2d-csi" +- reg: specifies sensor chip select number and associated address range +- interrupts: external interrupt line number and interrupt sense mode + of the interrupt line signaling frame valid events +- gpios: three gpio-specifiers for "capture", "reset" and "master enable" + GPIOs (strictly in this order). +- ifm,csi-clk-handle: the phandle to a node in the DT describing the sensor + clock generator. This node is usually a general purpose timer controller. +- ifm,csi-addr-bus-width: address bus width (valid values are 16, 24, 25) +- ifm,csi-data-bus-width: data bus width (valid values are 8 and 16) +- ifm,csi-wait-cycles: sensor bus wait cycles + +Optional properties: +- ifm,csi-byte-swap: if this property is present, the byte swapping on + the bus will be enabled. + +Example: + + csi@3,0 { + compatible = "ifm,o2d-csi"; + reg = <3 0 0x00100000>; /* CS 3, 1 MiB range */ + interrupts = <1 1 2>; /* IRQ1, edge falling */ + + ifm,csi-clk-handle = <&timer7>; + gpios = <&gpio_simple 23 0 /* image_capture */ + &gpio_simple 26 0 /* image_reset */ + &gpio_simple 29 0>; /* image_master_en */ + + ifm,csi-addr-bus-width = <24>; + ifm,csi-data-bus-width = <8>; + ifm,csi-wait-cycles = <0>; + }; + +The base address of the used chip select is specified in the +ranges property of the parent localbus node, for example: + + ranges = <0 0 0xff000000 0x01000000 + 3 0 0xe3000000 0x00100000>; diff --git a/Documentation/devicetree/bindings/mmc/atmel-hsmci.txt b/Documentation/devicetree/bindings/mmc/atmel-hsmci.txt new file mode 100644 index 000000000000..0a85c70cd30a --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/atmel-hsmci.txt @@ -0,0 +1,68 @@ +* Atmel High Speed MultiMedia Card Interface + +This controller on atmel products provides an interface for MMC, SD and SDIO +types of memory cards. + +This file documents differences between the core properties described +by mmc.txt and the properties used by the atmel-mci driver. + +1) MCI node + +Required properties: +- compatible: should be "atmel,hsmci" +- #address-cells: should be one. The cell is the slot id. +- #size-cells: should be zero. +- at least one slot node + +The node contains child nodes for each slot that the platform uses + +Example MCI node: + +mmc0: mmc@f0008000 { + compatible = "atmel,hsmci"; + reg = <0xf0008000 0x600>; + interrupts = <12 4>; + #address-cells = <1>; + #size-cells = <0>; + + [ child node definitions...] +}; + +2) slot nodes + +Required properties: +- reg: should contain the slot id. +- bus-width: number of data lines connected to the controller + +Optional properties: +- cd-gpios: specify GPIOs for card detection +- cd-inverted: invert the value of external card detect gpio line +- wp-gpios: specify GPIOs for write protection + +Example slot node: + +slot@0 { + reg = <0>; + bus-width = <4>; + cd-gpios = <&pioD 15 0> + cd-inverted; +}; + +Example full MCI node: +mmc0: mmc@f0008000 { + compatible = "atmel,hsmci"; + reg = <0xf0008000 0x600>; + interrupts = <12 4>; + #address-cells = <1>; + #size-cells = <0>; + slot@0 { + reg = <0>; + bus-width = <4>; + cd-gpios = <&pioD 15 0> + cd-inverted; + }; + slot@1 { + reg = <1>; + bus-width = <4>; + }; +}; diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt new file mode 100644 index 000000000000..792768953330 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt @@ -0,0 +1,87 @@ +* Samsung Exynos specific extensions to the Synopsis Designware Mobile + Storage Host Controller + +The Synopsis designware mobile storage host controller is used to interface +a SoC with storage medium such as eMMC or SD/MMC cards. This file documents +differences between the core Synopsis dw mshc controller properties described +by synposis-dw-mshc.txt and the properties used by the Samsung Exynos specific +extensions to the Synopsis Designware Mobile Storage Host Controller. + +Required Properties: + +* compatible: should be + - "samsung,exynos4210-dw-mshc": for controllers with Samsung Exynos4210 + specific extentions. + - "samsung,exynos4412-dw-mshc": for controllers with Samsung Exynos4412 + specific extentions. + - "samsung,exynos5250-dw-mshc": for controllers with Samsung Exynos5250 + specific extentions. + +* samsung,dw-mshc-ciu-div: Specifies the divider value for the card interface + unit (ciu) clock. This property is applicable only for Exynos5 SoC's and + ignored for Exynos4 SoC's. The valid range of divider value is 0 to 7. + +* samsung,dw-mshc-sdr-timing: Specifies the value of CIU clock phase shift value + in transmit mode and CIU clock phase shift value in receive mode for single + data rate mode operation. Refer notes below for the order of the cells and the + valid values. + +* samsung,dw-mshc-ddr-timing: Specifies the value of CUI clock phase shift value + in transmit mode and CIU clock phase shift value in receive mode for double + data rate mode operation. Refer notes below for the order of the cells and the + valid values. + + Notes for the sdr-timing and ddr-timing values: + + The order of the cells should be + - First Cell: CIU clock phase shift value for tx mode. + - Second Cell: CIU clock phase shift value for rx mode. + + Valid values for SDR and DDR CIU clock timing for Exynos5250: + - valid value for tx phase shift and rx phase shift is 0 to 7. + - when CIU clock divider value is set to 3, all possible 8 phase shift + values can be used. + - if CIU clock divider value is 0 (that is divide by 1), both tx and rx + phase shift clocks should be 0. + +Required properties for a slot: + +* gpios: specifies a list of gpios used for command, clock and data bus. The + first gpio is the command line and the second gpio is the clock line. The + rest of the gpios (depending on the bus-width property) are the data lines in + no particular order. The format of the gpio specifier depends on the gpio + controller. + +Example: + + The MSHC controller node can be split into two portions, SoC specific and + board specific portions as listed below. + + dwmmc0@12200000 { + compatible = "samsung,exynos5250-dw-mshc"; + reg = <0x12200000 0x1000>; + interrupts = <0 75 0>; + #address-cells = <1>; + #size-cells = <0>; + }; + + dwmmc0@12200000 { + num-slots = <1>; + supports-highspeed; + broken-cd; + fifo-depth = <0x80>; + card-detect-delay = <200>; + samsung,dw-mshc-ciu-div = <3>; + samsung,dw-mshc-sdr-timing = <2 3>; + samsung,dw-mshc-ddr-timing = <1 2>; + + slot@0 { + reg = <0>; + bus-width = <8>; + gpios = <&gpc0 0 2 0 3>, <&gpc0 1 2 0 3>, + <&gpc1 0 2 3 3>, <&gpc1 1 2 3 3>, + <&gpc1 2 2 3 3>, <&gpc1 3 2 3 3>, + <&gpc0 3 2 3 3>, <&gpc0 4 2 3 3>, + <&gpc0 5 2 3 3>, <&gpc0 6 2 3 3>; + }; + }; diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt index 8a6811f4a02f..8e2e0ba2f486 100644 --- a/Documentation/devicetree/bindings/mmc/mmc.txt +++ b/Documentation/devicetree/bindings/mmc/mmc.txt @@ -9,12 +9,17 @@ Interpreted by the OF core: Required properties: - bus-width: Number of data lines, can be <1>, <4>, or <8> +Card detection: +If no property below is supplied, standard SDHCI card detect is used. +Only one of the properties in this section should be supplied: + - broken-cd: There is no card detection available; polling must be used. + - cd-gpios: Specify GPIOs for card detection, see gpio binding + - non-removable: non-removable slot (like eMMC); assume always present. + Optional properties: -- cd-gpios: Specify GPIOs for card detection, see gpio binding - wp-gpios: Specify GPIOs for write protection, see gpio binding - cd-inverted: when present, polarity on the cd gpio line is inverted - wp-inverted: when present, polarity on the wp gpio line is inverted -- non-removable: non-removable slot (like eMMC) - max-frequency: maximum operating clock frequency Example: diff --git a/Documentation/devicetree/bindings/mmc/pxa-mmc.txt b/Documentation/devicetree/bindings/mmc/pxa-mmc.txt new file mode 100644 index 000000000000..b7025de7dced --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/pxa-mmc.txt @@ -0,0 +1,25 @@ +* PXA MMC drivers + +Driver bindings for the PXA MCI (MMC/SDIO) interfaces + +Required properties: +- compatible: Should be "marvell,pxa-mmc". +- vmmc-supply: A regulator for VMMC + +Optional properties: +- marvell,detect-delay-ms: sets the detection delay timeout in ms. +- marvell,gpio-power: GPIO spec for the card power enable pin + +This file documents differences between the core properties in mmc.txt +and the properties used by the pxa-mmc driver. + +Examples: + +mmc0: mmc@41100000 { + compatible = "marvell,pxa-mmc"; + reg = <0x41100000 0x1000>; + interrupts = <23>; + cd-gpios = <&gpio 23 0>; + wp-gpios = <&gpio 24 0>; +}; + diff --git a/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt new file mode 100644 index 000000000000..630a7d7f4718 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt @@ -0,0 +1,53 @@ +* Samsung's SDHCI Controller device tree bindings + +Samsung's SDHCI controller is used as a connectivity interface with external +MMC, SD and eMMC storage mediums. This file documents differences between the +core mmc properties described by mmc.txt and the properties used by the +Samsung implmentation of the SDHCI controller. + +Note: The mmc core bindings documentation states that if none of the core +card-detect bindings are used, then the standard sdhci card detect mechanism +is used. The Samsung's SDHCI controller bindings extends this as listed below. + +[A] The property "samsung,cd-pinmux-gpio" can be used as stated in the + "Optional Board Specific Properties" section below. + +[B] If core card-detect bindings and "samsung,cd-pinmux-gpio" property + is not specified, it is assumed that there is no card detection + mechanism used. + +Required SoC Specific Properties: +- compatible: should be one of the following + - "samsung,s3c6410-sdhci": For controllers compatible with s3c6410 sdhci + controller. + - "samsung,exynos4210-sdhci": For controllers compatible with Exynos4 sdhci + controller. + +Required Board Specific Properties: +- gpios: Should specify the gpios used for clock, command and data lines. The + gpio specifier format depends on the gpio controller. + +Optional Board Specific Properties: +- samsung,cd-pinmux-gpio: Specifies the card detect line that is routed + through a pinmux to the card-detect pin of the card slot. This property + should be used only if none of the mmc core card-detect properties are + used. + +Example: + sdhci@12530000 { + compatible = "samsung,exynos4210-sdhci"; + reg = <0x12530000 0x100>; + interrupts = <0 75 0>; + bus-width = <4>; + cd-gpios = <&gpk2 2 2 3 3>; + gpios = <&gpk2 0 2 0 3>, /* clock line */ + <&gpk2 1 2 0 3>, /* command line */ + <&gpk2 3 2 3 3>, /* data line 0 */ + <&gpk2 4 2 3 3>, /* data line 1 */ + <&gpk2 5 2 3 3>, /* data line 2 */ + <&gpk2 6 2 3 3>; /* data line 3 */ + }; + + Note: This example shows both SoC specific and board specific properties + in a single device node. The properties can be actually be seperated + into SoC specific node and board specific node. diff --git a/Documentation/devicetree/bindings/mmc/sdhci-dove.txt b/Documentation/devicetree/bindings/mmc/sdhci-dove.txt new file mode 100644 index 000000000000..ae9aab9abcd7 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/sdhci-dove.txt @@ -0,0 +1,14 @@ +* Marvell sdhci-dove controller + +This file documents differences between the core properties in mmc.txt +and the properties used by the sdhci-pxav2 and sdhci-pxav3 drivers. + +- compatible: Should be "marvell,dove-sdhci". + +Example: + +sdio0: sdio@92000 { + compatible = "marvell,dove-sdhci"; + reg = <0x92000 0x100>; + interrupts = <35>; +}; diff --git a/Documentation/devicetree/bindings/mmc/sdhci-spear.txt b/Documentation/devicetree/bindings/mmc/sdhci-spear.txt new file mode 100644 index 000000000000..fd3643e7e467 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/sdhci-spear.txt @@ -0,0 +1,18 @@ +* SPEAr SDHCI Controller + +This file documents differences between the core properties in mmc.txt +and the properties used by the sdhci-spear driver. + +Required properties: +- compatible: "st,spear300-sdhci" + +Optional properties: +- cd-gpios: card detect gpio, with zero flags. + +Example: + + sdhci@fc000000 { + compatible = "st,spear300-sdhci"; + reg = <0xfc000000 0x1000>; + cd-gpios = <&gpio0 6 0>; + }; diff --git a/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt new file mode 100644 index 000000000000..06cd32d08052 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt @@ -0,0 +1,79 @@ +* Synopsis Designware Mobile Storage Host Controller + +The Synopsis designware mobile storage host controller is used to interface +a SoC with storage medium such as eMMC or SD/MMC cards. This file documents +differences between the core mmc properties described by mmc.txt and the +properties used by the Synopsis Designware Mobile Storage Host Controller. + +Required Properties: + +* compatible: should be + - snps,dw-mshc: for controllers compliant with synopsis dw-mshc. +* #address-cells: should be 1. +* #size-cells: should be 0. + +# Slots: The slot specific information are contained within child-nodes with + each child-node representing a supported slot. There should be atleast one + child node representing a card slot. The name of the child node representing + the slot is recommended to be slot@n where n is the unique number of the slot + connnected to the controller. The following are optional properties which + can be included in the slot child node. + + * reg: specifies the physical slot number. The valid values of this + property is 0 to (num-slots -1), where num-slots is the value + specified by the num-slots property. + + * bus-width: as documented in mmc core bindings. + + * wp-gpios: specifies the write protect gpio line. The format of the + gpio specifier depends on the gpio controller. If the write-protect + line is not available, this property is optional. + +Optional properties: + +* num-slots: specifies the number of slots supported by the controller. + The number of physical slots actually used could be equal or less than the + value specified by num-slots. If this property is not specified, the value + of num-slot property is assumed to be 1. + +* fifo-depth: The maximum size of the tx/rx fifo's. If this property is not + specified, the default value of the fifo size is determined from the + controller registers. + +* card-detect-delay: Delay in milli-seconds before detecting card after card + insert event. The default value is 0. + +* supports-highspeed: Enables support for high speed cards (upto 50MHz) + +* broken-cd: as documented in mmc core bindings. + +Aliases: + +- All the MSHC controller nodes should be represented in the aliases node using + the following format 'mshc{n}' where n is a unique number for the alias. + +Example: + +The MSHC controller node can be split into two portions, SoC specific and +board specific portions as listed below. + + dwmmc0@12200000 { + compatible = "snps,dw-mshc"; + reg = <0x12200000 0x1000>; + interrupts = <0 75 0>; + #address-cells = <1>; + #size-cells = <0>; + }; + + dwmmc0@12200000 { + num-slots = <1>; + supports-highspeed; + broken-cd; + fifo-depth = <0x80>; + card-detect-delay = <200>; + + slot@0 { + reg = <0>; + bus-width = <8>; + }; + }; diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.txt b/Documentation/devicetree/bindings/mtd/atmel-nand.txt index a20069502f5a..d555421ea49f 100644 --- a/Documentation/devicetree/bindings/mtd/atmel-nand.txt +++ b/Documentation/devicetree/bindings/mtd/atmel-nand.txt @@ -3,7 +3,9 @@ Atmel NAND flash Required properties: - compatible : "atmel,at91rm9200-nand". - reg : should specify localbus address and size used for the chip, - and if availlable the ECC. + and hardware ECC controller if available. + If the hardware ECC is PMECC, it should contain address and size for + PMECC, PMECC Error Location controller and ROM which has lookup tables. - atmel,nand-addr-offset : offset for the address latch. - atmel,nand-cmd-offset : offset for the command latch. - #address-cells, #size-cells : Must be present if the device has sub-nodes @@ -16,6 +18,15 @@ Optional properties: - nand-ecc-mode : String, operation mode of the NAND ecc mode, soft by default. Supported values are: "none", "soft", "hw", "hw_syndrome", "hw_oob_first", "soft_bch". +- atmel,has-pmecc : boolean to enable Programmable Multibit ECC hardware. + Only supported by at91sam9x5 or later sam9 product. +- atmel,pmecc-cap : error correct capability for Programmable Multibit ECC + Controller. Supported values are: 2, 4, 8, 12, 24. +- atmel,pmecc-sector-size : sector size for ECC computation. Supported values + are: 512, 1024. +- atmel,pmecc-lookup-table-offset : includes two offsets of lookup table in ROM + for different sector size. First one is for sector size 512, the next is for + sector size 1024. - nand-bus-width : 8 or 16 bus width if not present 8 - nand-on-flash-bbt: boolean to enable on flash bbt option if not present false @@ -39,3 +50,30 @@ nand0: nand@40000000,0 { ... }; }; + +/* for PMECC supported chips */ +nand0: nand@40000000 { + compatible = "atmel,at91rm9200-nand"; + #address-cells = <1>; + #size-cells = <1>; + reg = < 0x40000000 0x10000000 /* bus addr & size */ + 0xffffe000 0x00000600 /* PMECC addr & size */ + 0xffffe600 0x00000200 /* PMECC ERRLOC addr & size */ + 0x00100000 0x00100000 /* ROM addr & size */ + >; + atmel,nand-addr-offset = <21>; /* ale */ + atmel,nand-cmd-offset = <22>; /* cle */ + nand-on-flash-bbt; + nand-ecc-mode = "hw"; + atmel,has-pmecc; /* enable PMECC */ + atmel,pmecc-cap = <2>; + atmel,pmecc-sector-size = <512>; + atmel,pmecc-lookup-table-offset = <0x8000 0x10000>; + gpios = <&pioD 5 0 /* rdy */ + &pioD 4 0 /* nce */ + 0 /* cd */ + >; + partition@0 { + ... + }; +}; diff --git a/Documentation/devicetree/bindings/mtd/gpmi-nand.txt b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt index 1a5bbd346d22..3fb3f9015365 100644 --- a/Documentation/devicetree/bindings/mtd/gpmi-nand.txt +++ b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt @@ -12,6 +12,10 @@ Required properties: - interrupt-names : The interrupt names "gpmi-dma", "bch"; - fsl,gpmi-dma-channel : Should contain the dma channel it uses. +Optional properties: + - nand-on-flash-bbt: boolean to enable on flash bbt option if not + present false + The device tree may optionally contain sub-nodes describing partitions of the address space. See partition.txt for more detail. diff --git a/Documentation/devicetree/bindings/mtd/lpc32xx-mlc.txt b/Documentation/devicetree/bindings/mtd/lpc32xx-mlc.txt new file mode 100644 index 000000000000..d0a37252eb22 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/lpc32xx-mlc.txt @@ -0,0 +1,50 @@ +NXP LPC32xx SoC NAND MLC controller + +Required properties: +- compatible: "nxp,lpc3220-mlc" +- reg: Address and size of the controller +- interrupts: The NAND interrupt specification +- gpios: GPIO specification for NAND write protect + +The following required properties are very controller specific. See the LPC32xx +User Manual 7.5.14 MLC NAND Timing Register (the values here are specified in +Hz, to make them independent of actual clock speed and to provide for good +accuracy:) +- nxp,tcea_delay: TCEA_DELAY +- nxp,busy_delay: BUSY_DELAY +- nxp,nand_ta: NAND_TA +- nxp,rd_high: RD_HIGH +- nxp,rd_low: RD_LOW +- nxp,wr_high: WR_HIGH +- nxp,wr_low: WR_LOW + +Optional subnodes: +- Partitions, see Documentation/devicetree/bindings/mtd/partition.txt + +Example: + + mlc: flash@200A8000 { + compatible = "nxp,lpc3220-mlc"; + reg = <0x200A8000 0x11000>; + interrupts = <11 0>; + #address-cells = <1>; + #size-cells = <1>; + + nxp,tcea-delay = <333333333>; + nxp,busy-delay = <10000000>; + nxp,nand-ta = <18181818>; + nxp,rd-high = <31250000>; + nxp,rd-low = <45454545>; + nxp,wr-high = <40000000>; + nxp,wr-low = <83333333>; + gpios = <&gpio 5 19 1>; /* GPO_P3 19, active low */ + + mtd0@00000000 { + label = "boot"; + reg = <0x00000000 0x00064000>; + read-only; + }; + + ... + + }; diff --git a/Documentation/devicetree/bindings/mtd/lpc32xx-slc.txt b/Documentation/devicetree/bindings/mtd/lpc32xx-slc.txt new file mode 100644 index 000000000000..d94edc0fc554 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/lpc32xx-slc.txt @@ -0,0 +1,52 @@ +NXP LPC32xx SoC NAND SLC controller + +Required properties: +- compatible: "nxp,lpc3220-slc" +- reg: Address and size of the controller +- nand-on-flash-bbt: Use bad block table on flash +- gpios: GPIO specification for NAND write protect + +The following required properties are very controller specific. See the LPC32xx +User Manual: +- nxp,wdr-clks: Delay before Ready signal is tested on write (W_RDY) +- nxp,rdr-clks: Delay before Ready signal is tested on read (R_RDY) +(The following values are specified in Hz, to make them independent of actual +clock speed:) +- nxp,wwidth: Write pulse width (W_WIDTH) +- nxp,whold: Write hold time (W_HOLD) +- nxp,wsetup: Write setup time (W_SETUP) +- nxp,rwidth: Read pulse width (R_WIDTH) +- nxp,rhold: Read hold time (R_HOLD) +- nxp,rsetup: Read setup time (R_SETUP) + +Optional subnodes: +- Partitions, see Documentation/devicetree/bindings/mtd/partition.txt + +Example: + + slc: flash@20020000 { + compatible = "nxp,lpc3220-slc"; + reg = <0x20020000 0x1000>; + #address-cells = <1>; + #size-cells = <1>; + + nxp,wdr-clks = <14>; + nxp,wwidth = <40000000>; + nxp,whold = <100000000>; + nxp,wsetup = <100000000>; + nxp,rdr-clks = <14>; + nxp,rwidth = <40000000>; + nxp,rhold = <66666666>; + nxp,rsetup = <100000000>; + nand-on-flash-bbt; + gpios = <&gpio 5 19 1>; /* GPO_P3 19, active low */ + + mtd0@00000000 { + label = "phy3250-boot"; + reg = <0x00000000 0x00064000>; + read-only; + }; + + ... + + }; diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt index a63c2bd7de2b..94de19b8f16b 100644 --- a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt +++ b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt @@ -16,6 +16,13 @@ file systems on embedded devices. - #address-cells, #size-cells : Must be present if the device has sub-nodes representing partitions (see below). In this case both #address-cells and #size-cells must be equal to 1. + - no-unaligned-direct-access: boolean to disable the default direct + mapping of the flash. + On some platforms (e.g. MPC5200) a direct 1:1 mapping may cause + problems with JFFS2 usage, as the local bus (LPB) doesn't support + unaligned accesses as implemented in the JFFS2 code via memcpy(). + By defining "no-unaligned-direct-access", the flash will not be + exposed directly to the MTD users (e.g. JFFS2) any more. For JEDEC compatible devices, the following additional properties are defined: diff --git a/Documentation/devicetree/bindings/pinctrl/lantiq,falcon-pinumx.txt b/Documentation/devicetree/bindings/pinctrl/lantiq,falcon-pinumx.txt new file mode 100644 index 000000000000..daa768956069 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/lantiq,falcon-pinumx.txt @@ -0,0 +1,83 @@ +Lantiq FALCON pinmux controller + +Required properties: +- compatible: "lantiq,pinctrl-falcon" +- reg: Should contain the physical address and length of the gpio/pinmux + register range + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +Lantiq's pin configuration nodes act as a container for an abitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin, a group, or a list of pins or groups. This configuration can include the +mux function to select on those group(s), and two pin configuration parameters: +pull-up and open-drain + +The name of each subnode is not important as long as it is unique; all subnodes +should be enumerated and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. + +We support 2 types of nodes. + +Definition of mux function groups: + +Required subnode-properties: +- lantiq,groups : An array of strings. Each string contains the name of a group. + Valid values for these names are listed below. +- lantiq,function: A string containing the name of the function to mux to the + group. Valid values for function names are listed below. + +Valid values for group and function names: + + mux groups: + por, ntr, ntr8k, hrst, mdio, bootled, asc0, spi, spi cs0, spi cs1, i2c, + jtag, slic, pcm, asc1 + + functions: + rst, ntr, mdio, led, asc, spi, i2c, jtag, slic, pcm + + +Definition of pin configurations: + +Required subnode-properties: +- lantiq,pins : An array of strings. Each string contains the name of a pin. + Valid values for these names are listed below. + +Optional subnode-properties: +- lantiq,pull: Integer, representing the pull-down/up to apply to the pin. + 0: none, 1: down +- lantiq,drive-current: Boolean, enables drive-current +- lantiq,slew-rate: Boolean, enables slew-rate + +Example: + pinmux0 { + compatible = "lantiq,pinctrl-falcon"; + pinctrl-names = "default"; + pinctrl-0 = <&state_default>; + + state_default: pinmux { + asc0 { + lantiq,groups = "asc0"; + lantiq,function = "asc"; + }; + ntr { + lantiq,groups = "ntr8k"; + lantiq,function = "ntr"; + }; + i2c { + lantiq,groups = "i2c"; + lantiq,function = "i2c"; + }; + hrst { + lantiq,groups = "hrst"; + lantiq,function = "rst"; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/lantiq,xway-pinumx.txt b/Documentation/devicetree/bindings/pinctrl/lantiq,xway-pinumx.txt new file mode 100644 index 000000000000..b5469db1d7ad --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/lantiq,xway-pinumx.txt @@ -0,0 +1,97 @@ +Lantiq XWAY pinmux controller + +Required properties: +- compatible: "lantiq,pinctrl-xway" or "lantiq,pinctrl-xr9" +- reg: Should contain the physical address and length of the gpio/pinmux + register range + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +Lantiq's pin configuration nodes act as a container for an abitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin, a group, or a list of pins or groups. This configuration can include the +mux function to select on those group(s), and two pin configuration parameters: +pull-up and open-drain + +The name of each subnode is not important as long as it is unique; all subnodes +should be enumerated and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. + +We support 2 types of nodes. + +Definition of mux function groups: + +Required subnode-properties: +- lantiq,groups : An array of strings. Each string contains the name of a group. + Valid values for these names are listed below. +- lantiq,function: A string containing the name of the function to mux to the + group. Valid values for function names are listed below. + +Valid values for group and function names: + + mux groups: + exin0, exin1, exin2, jtag, ebu a23, ebu a24, ebu a25, ebu clk, ebu cs1, + ebu wait, nand ale, nand cs1, nand cle, spi, spi_cs1, spi_cs2, spi_cs3, + spi_cs4, spi_cs5, spi_cs6, asc0, asc0 cts rts, stp, nmi , gpt1, gpt2, + gpt3, clkout0, clkout1, clkout2, clkout3, gnt1, gnt2, gnt3, req1, req2, + req3 + + additional mux groups (XR9 only): + mdio, nand rdy, nand rd, exin3, exin4, gnt4, req4 + + functions: + spi, asc, cgu, jtag, exin, stp, gpt, nmi, pci, ebu, mdio + + + +Definition of pin configurations: + +Required subnode-properties: +- lantiq,pins : An array of strings. Each string contains the name of a pin. + Valid values for these names are listed below. + +Optional subnode-properties: +- lantiq,pull: Integer, representing the pull-down/up to apply to the pin. + 0: none, 1: down, 2: up. +- lantiq,open-drain: Boolean, enables open-drain on the defined pin. + +Valid values for XWAY pin names: + Pinconf pins can be referenced via the names io0-io31. + +Valid values for XR9 pin names: + Pinconf pins can be referenced via the names io0-io55. + +Example: + gpio: pinmux@E100B10 { + compatible = "lantiq,pinctrl-xway"; + pinctrl-names = "default"; + pinctrl-0 = <&state_default>; + + #gpio-cells = <2>; + gpio-controller; + reg = <0xE100B10 0xA0>; + + state_default: pinmux { + stp { + lantiq,groups = "stp"; + lantiq,function = "stp"; + }; + pci { + lantiq,groups = "gnt1"; + lantiq,function = "pci"; + }; + conf_out { + lantiq,pins = "io4", "io5", "io6"; /* stp */ + lantiq,open-drain; + lantiq,pull = <0>; + }; + }; + }; + diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt new file mode 100644 index 000000000000..01ef408e205f --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt @@ -0,0 +1,95 @@ +* Marvell Armada 370 SoC pinctrl driver for mpp + +Please refer to marvell,mvebu-pinctrl.txt in this directory for common binding +part and usage. + +Required properties: +- compatible: "marvell,88f6710-pinctrl" + +Available mpp pins/groups and functions: +Note: brackets (x) are not part of the mpp name for marvell,function and given +only for more detailed description in this document. + +name pins functions +================================================================================ +mpp0 0 gpio, uart0(rxd) +mpp1 1 gpo, uart0(txd) +mpp2 2 gpio, i2c0(sck), uart0(txd) +mpp3 3 gpio, i2c0(sda), uart0(rxd) +mpp4 4 gpio, cpu_pd(vdd) +mpp5 5 gpo, ge0(txclko), uart1(txd), spi1(clk), audio(mclk) +mpp6 6 gpio, ge0(txd0), sata0(prsnt), tdm(rst), audio(sdo) +mpp7 7 gpo, ge0(txd1), tdm(tdx), audio(lrclk) +mpp8 8 gpio, ge0(txd2), uart0(rts), tdm(drx), audio(bclk) +mpp9 9 gpo, ge0(txd3), uart1(txd), sd0(clk), audio(spdifo) +mpp10 10 gpio, ge0(txctl), uart0(cts), tdm(fsync), audio(sdi) +mpp11 11 gpio, ge0(rxd0), uart1(rxd), sd0(cmd), spi0(cs1), + sata1(prsnt), spi1(cs1) +mpp12 12 gpio, ge0(rxd1), i2c1(sda), sd0(d0), spi1(cs0), + audio(spdifi) +mpp13 13 gpio, ge0(rxd2), i2c1(sck), sd0(d1), tdm(pclk), + audio(rmclk) +mpp14 14 gpio, ge0(rxd3), pcie(clkreq0), sd0(d2), spi1(mosi), + spi0(cs2) +mpp15 15 gpio, ge0(rxctl), pcie(clkreq1), sd0(d3), spi1(miso), + spi0(cs3) +mpp16 16 gpio, ge0(rxclk), uart1(rxd), tdm(int), audio(extclk) +mpp17 17 gpo, ge(mdc) +mpp18 18 gpio, ge(mdio) +mpp19 19 gpio, ge0(txclk), ge1(txclkout), tdm(pclk) +mpp20 20 gpo, ge0(txd4), ge1(txd0) +mpp21 21 gpo, ge0(txd5), ge1(txd1), uart1(txd) +mpp22 22 gpo, ge0(txd6), ge1(txd2), uart0(rts) +mpp23 23 gpo, ge0(txd7), ge1(txd3), spi1(mosi) +mpp24 24 gpio, ge0(col), ge1(txctl), spi1(cs0) +mpp25 25 gpio, ge0(rxerr), ge1(rxd0), uart1(rxd) +mpp26 26 gpio, ge0(crs), ge1(rxd1), spi1(miso) +mpp27 27 gpio, ge0(rxd4), ge1(rxd2), uart0(cts) +mpp28 28 gpio, ge0(rxd5), ge1(rxd3) +mpp29 29 gpio, ge0(rxd6), ge1(rxctl), i2c1(sda) +mpp30 30 gpio, ge0(rxd7), ge1(rxclk), i2c1(sck) +mpp31 31 gpio, tclk, ge0(txerr) +mpp32 32 gpio, spi0(cs0) +mpp33 33 gpio, dev(bootcs), spi0(cs0) +mpp34 34 gpo, dev(wen0), spi0(mosi) +mpp35 35 gpo, dev(oen), spi0(sck) +mpp36 36 gpo, dev(a1), spi0(miso) +mpp37 37 gpo, dev(a0), sata0(prsnt) +mpp38 38 gpio, dev(ready), uart1(cts), uart0(cts) +mpp39 39 gpo, dev(ad0), audio(spdifo) +mpp40 40 gpio, dev(ad1), uart1(rts), uart0(rts) +mpp41 41 gpio, dev(ad2), uart1(rxd) +mpp42 42 gpo, dev(ad3), uart1(txd) +mpp43 43 gpo, dev(ad4), audio(bclk) +mpp44 44 gpo, dev(ad5), audio(mclk) +mpp45 45 gpo, dev(ad6), audio(lrclk) +mpp46 46 gpo, dev(ad7), audio(sdo) +mpp47 47 gpo, dev(ad8), sd0(clk), audio(spdifo) +mpp48 48 gpio, dev(ad9), uart0(rts), sd0(cmd), sata1(prsnt), + spi0(cs1) +mpp49 49 gpio, dev(ad10), pcie(clkreq1), sd0(d0), spi1(cs0), + audio(spdifi) +mpp50 50 gpio, dev(ad11), uart0(cts), sd0(d1), spi1(miso), + audio(rmclk) +mpp51 51 gpio, dev(ad12), i2c1(sda), sd0(d2), spi1(mosi) +mpp52 52 gpio, dev(ad13), i2c1(sck), sd0(d3), spi1(sck) +mpp53 53 gpio, dev(ad14), sd0(clk), tdm(pclk), spi0(cs2), + pcie(clkreq1) +mpp54 54 gpo, dev(ad15), tdm(dtx) +mpp55 55 gpio, dev(cs1), uart1(txd), tdm(rst), sata1(prsnt), + sata0(prsnt) +mpp56 56 gpio, dev(cs2), uart1(cts), uart0(cts), spi0(cs3), + pcie(clkreq0), spi1(cs1) +mpp57 57 gpio, dev(cs3), uart1(rxd), tdm(fsync), sata0(prsnt), + audio(sdo) +mpp58 58 gpio, dev(cs0), uart1(rts), tdm(int), audio(extclk), + uart0(rts) +mpp59 59 gpo, dev(ale0), uart1(rts), uart0(rts), audio(bclk) +mpp60 60 gpio, dev(ale1), uart1(rxd), sata0(prsnt), pcie(rst-out), + audio(sdi) +mpp61 61 gpo, dev(wen1), uart1(txd), audio(rclk) +mpp62 62 gpio, dev(a2), uart1(cts), tdm(drx), pcie(clkreq0), + audio(mclk), uart0(cts) +mpp63 63 gpo, spi0(sck), tclk +mpp64 64 gpio, spi0(miso), spi0-1(cs1) +mpp65 65 gpio, spi0(mosi), spi0-1(cs2) diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt new file mode 100644 index 000000000000..bfa0a2e5e0cb --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt @@ -0,0 +1,100 @@ +* Marvell Armada XP SoC pinctrl driver for mpp + +Please refer to marvell,mvebu-pinctrl.txt in this directory for common binding +part and usage. + +Required properties: +- compatible: "marvell,mv78230-pinctrl", "marvell,mv78260-pinctrl", + "marvell,mv78460-pinctrl" + +This driver supports all Armada XP variants, i.e. mv78230, mv78260, and mv78460. + +Available mpp pins/groups and functions: +Note: brackets (x) are not part of the mpp name for marvell,function and given +only for more detailed description in this document. + +* Marvell Armada XP (all variants) + +name pins functions +================================================================================ +mpp0 0 gpio, ge0(txclko), lcd(d0) +mpp1 1 gpio, ge0(txd0), lcd(d1) +mpp2 2 gpio, ge0(txd1), lcd(d2) +mpp3 3 gpio, ge0(txd2), lcd(d3) +mpp4 4 gpio, ge0(txd3), lcd(d4) +mpp5 5 gpio, ge0(txctl), lcd(d5) +mpp6 6 gpio, ge0(rxd0), lcd(d6) +mpp7 7 gpio, ge0(rxd1), lcd(d7) +mpp8 8 gpio, ge0(rxd2), lcd(d8) +mpp9 9 gpio, ge0(rxd3), lcd(d9) +mpp10 10 gpio, ge0(rxctl), lcd(d10) +mpp11 11 gpio, ge0(rxclk), lcd(d11) +mpp12 12 gpio, ge0(txd4), ge1(txd0), lcd(d12) +mpp13 13 gpio, ge0(txd5), ge1(txd1), lcd(d13) +mpp14 14 gpio, ge0(txd6), ge1(txd2), lcd(d15) +mpp15 15 gpio, ge0(txd7), ge1(txd3), lcd(d16) +mpp16 16 gpio, ge0(txd7), ge1(txd3), lcd(d16) +mpp17 17 gpio, ge0(col), ge1(txctl), lcd(d17) +mpp18 18 gpio, ge0(rxerr), ge1(rxd0), lcd(d18), ptp(trig) +mpp19 19 gpio, ge0(crs), ge1(rxd1), lcd(d19), ptp(evreq) +mpp20 20 gpio, ge0(rxd4), ge1(rxd2), lcd(d20), ptp(clk) +mpp21 21 gpio, ge0(rxd5), ge1(rxd3), lcd(d21), mem(bat) +mpp22 22 gpio, ge0(rxd6), ge1(rxctl), lcd(d22), sata0(prsnt) +mpp23 23 gpio, ge0(rxd7), ge1(rxclk), lcd(d23), sata1(prsnt) +mpp24 24 gpio, lcd(hsync), sata1(prsnt), nf(bootcs-re), tdm(rst) +mpp25 25 gpio, lcd(vsync), sata0(prsnt), nf(bootcs-we), tdm(pclk) +mpp26 26 gpio, lcd(clk), tdm(fsync), vdd(cpu1-pd) +mpp27 27 gpio, lcd(e), tdm(dtx), ptp(trig) +mpp28 28 gpio, lcd(pwm), tdm(drx), ptp(evreq) +mpp29 29 gpio, lcd(ref-clk), tdm(int0), ptp(clk), vdd(cpu0-pd) +mpp30 30 gpio, tdm(int1), sd0(clk) +mpp31 31 gpio, tdm(int2), sd0(cmd), vdd(cpu0-pd) +mpp32 32 gpio, tdm(int3), sd0(d0), vdd(cpu1-pd) +mpp33 33 gpio, tdm(int4), sd0(d1), mem(bat) +mpp34 34 gpio, tdm(int5), sd0(d2), sata0(prsnt) +mpp35 35 gpio, tdm(int6), sd0(d3), sata1(prsnt) +mpp36 36 gpio, spi(mosi) +mpp37 37 gpio, spi(miso) +mpp38 38 gpio, spi(sck) +mpp39 39 gpio, spi(cs0) +mpp40 40 gpio, spi(cs1), uart2(cts), lcd(vga-hsync), vdd(cpu1-pd), + pcie(clkreq0) +mpp41 41 gpio, spi(cs2), uart2(rts), lcd(vga-vsync), sata1(prsnt), + pcie(clkreq1) +mpp42 42 gpio, uart2(rxd), uart0(cts), tdm(int7), tdm-1(timer), + vdd(cpu0-pd) +mpp43 43 gpio, uart2(txd), uart0(rts), spi(cs3), pcie(rstout), + vdd(cpu2-3-pd){1} +mpp44 44 gpio, uart2(cts), uart3(rxd), spi(cs4), pcie(clkreq2), + mem(bat) +mpp45 45 gpio, uart2(rts), uart3(txd), spi(cs5), sata1(prsnt) +mpp46 46 gpio, uart3(rts), uart1(rts), spi(cs6), sata0(prsnt) +mpp47 47 gpio, uart3(cts), uart1(cts), spi(cs7), pcie(clkreq3), + ref(clkout) +mpp48 48 gpio, tclk, dev(burst/last) + +* Marvell Armada XP (mv78260 and mv78460 only) + +name pins functions +================================================================================ +mpp49 49 gpio, dev(we3) +mpp50 50 gpio, dev(we2) +mpp51 51 gpio, dev(ad16) +mpp52 52 gpio, dev(ad17) +mpp53 53 gpio, dev(ad18) +mpp54 54 gpio, dev(ad19) +mpp55 55 gpio, dev(ad20), vdd(cpu0-pd) +mpp56 56 gpio, dev(ad21), vdd(cpu1-pd) +mpp57 57 gpio, dev(ad22), vdd(cpu2-3-pd){1} +mpp58 58 gpio, dev(ad23) +mpp59 59 gpio, dev(ad24) +mpp60 60 gpio, dev(ad25) +mpp61 61 gpio, dev(ad26) +mpp62 62 gpio, dev(ad27) +mpp63 63 gpio, dev(ad28) +mpp64 64 gpio, dev(ad29) +mpp65 65 gpio, dev(ad30) +mpp66 66 gpio, dev(ad31) + +Notes: +* {1} vdd(cpu2-3-pd) only available on mv78460. diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt new file mode 100644 index 000000000000..a648aaad6110 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt @@ -0,0 +1,72 @@ +* Marvell Dove SoC pinctrl driver for mpp + +Please refer to marvell,mvebu-pinctrl.txt in this directory for common binding +part and usage. + +Required properties: +- compatible: "marvell,dove-pinctrl" +- clocks: (optional) phandle of pdma clock + +Available mpp pins/groups and functions: +Note: brackets (x) are not part of the mpp name for marvell,function and given +only for more detailed description in this document. + +name pins functions +================================================================================ +mpp0 0 gpio, pmu, uart2(rts), sdio0(cd), lcd0(pwm) +mpp1 1 gpio, pmu, uart2(cts), sdio0(wp), lcd1(pwm) +mpp2 2 gpio, pmu, uart2(txd), sdio0(buspwr), sata(prsnt), + uart1(rts) +mpp3 3 gpio, pmu, uart2(rxd), sdio0(ledctrl), sata(act), + uart1(cts), lcd-spi(cs1) +mpp4 4 gpio, pmu, uart3(rts), sdio1(cd), spi1(miso) +mpp5 5 gpio, pmu, uart3(cts), sdio1(wp), spi1(cs) +mpp6 6 gpio, pmu, uart3(txd), sdio1(buspwr), spi1(mosi) +mpp7 7 gpio, pmu, uart3(rxd), sdio1(ledctrl), spi1(sck) +mpp8 8 gpio, pmu, watchdog(rstout) +mpp9 9 gpio, pmu, pex1(clkreq) +mpp10 10 gpio, pmu, ssp(sclk) +mpp11 11 gpio, pmu, sata(prsnt), sata-1(act), sdio0(ledctrl), + sdio1(ledctrl), pex0(clkreq) +mpp12 12 gpio, pmu, uart2(rts), audio0(extclk), sdio1(cd), sata(act) +mpp13 13 gpio, pmu, uart2(cts), audio1(extclk), sdio1(wp), + ssp(extclk) +mpp14 14 gpio, pmu, uart2(txd), sdio1(buspwr), ssp(rxd) +mpp15 15 gpio, pmu, uart2(rxd), sdio1(ledctrl), ssp(sfrm) +mpp16 16 gpio, uart3(rts), sdio0(cd), ac97(sdi1), lcd-spi(cs1) +mpp17 17 gpio, uart3(cts), sdio0(wp), ac97(sdi2), twsi(sda), + ac97-1(sysclko) +mpp18 18 gpio, uart3(txd), sdio0(buspwr), ac97(sdi3), lcd0(pwm) +mpp19 19 gpio, uart3(rxd), sdio0(ledctrl), twsi(sck) +mpp20 20 gpio, sdio0(cd), sdio1(cd), spi1(miso), lcd-spi(miso), + ac97(sysclko) +mpp21 21 gpio, sdio0(wp), sdio1(wp), spi1(cs), lcd-spi(cs0), + uart1(cts), ssp(sfrm) +mpp22 22 gpio, sdio0(buspwr), sdio1(buspwr), spi1(mosi), + lcd-spi(mosi), uart1(cts), ssp(txd) +mpp23 23 gpio, sdio0(ledctrl), sdio1(ledctrl), spi1(sck), + lcd-spi(sck), ssp(sclk) +mpp_camera 24-39 gpio, camera +mpp_sdio0 40-45 gpio, sdio0 +mpp_sdio1 46-51 gpio, sdio1 +mpp_audio1 52-57 gpio, i2s1/spdifo, i2s1, spdifo, twsi, ssp/spdifo, ssp, + ssp/twsi +mpp_spi0 58-61 gpio, spi0 +mpp_uart1 62-63 gpio, uart1 +mpp_nand 64-71 gpo, nand +audio0 - i2s, ac97 +twsi - none, opt1, opt2, opt3 + +Notes: +* group "mpp_audio1" allows the following functions and gpio pins: + - gpio : gpio on pins 52-57 + - i2s1/spdifo : audio1 i2s on pins 52-55 and spdifo on 57, no gpios + - i2s1 : audio1 i2s on pins 52-55, gpio on pins 56,57 + - spdifo : spdifo on pin 57, gpio on pins 52-55 + - twsi : twsi on pins 56,57, gpio on pins 52-55 + - ssp/spdifo : ssp on pins 52-55, spdifo on pin 57, no gpios + - ssp : ssp on pins 52-55, gpio on pins 56,57 + - ssp/twsi : ssp on pins 52-55, twsi on pins 56,57, no gpios +* group "audio0" internally muxes i2s0 or ac97 controller to the dedicated + audio0 pins. +* group "twsi" internally muxes twsi controller to the dedicated or option pins. diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt new file mode 100644 index 000000000000..361bccb7ec89 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt @@ -0,0 +1,279 @@ +* Marvell Kirkwood SoC pinctrl driver for mpp + +Please refer to marvell,mvebu-pinctrl.txt in this directory for common binding +part and usage. + +Required properties: +- compatible: "marvell,88f6180-pinctrl", + "marvell,88f6190-pinctrl", "marvell,88f6192-pinctrl", + "marvell,88f6281-pinctrl", "marvell,88f6282-pinctrl" + +This driver supports all kirkwood variants, i.e. 88f6180, 88f619x, and 88f628x. + +Available mpp pins/groups and functions: +Note: brackets (x) are not part of the mpp name for marvell,function and given +only for more detailed description in this document. + +* Marvell Kirkwood 88f6180 + +name pins functions +================================================================================ +mpp0 0 gpio, nand(io2), spi(cs) +mpp1 1 gpo, nand(io3), spi(mosi) +mpp2 2 gpo, nand(io4), spi(sck) +mpp3 3 gpo, nand(io5), spi(miso) +mpp4 4 gpio, nand(io6), uart0(rxd), ptp(clk) +mpp5 5 gpo, nand(io7), uart0(txd), ptp(trig) +mpp6 6 sysrst(out), spi(mosi), ptp(trig) +mpp7 7 gpo, pex(rsto), spi(cs), ptp(trig) +mpp8 8 gpio, twsi0(sda), uart0(rts), uart1(rts), ptp(clk), + mii(col) +mpp9 9 gpio, twsi(sck), uart0(cts), uart1(cts), ptp(evreq), + mii(crs) +mpp10 10 gpo, spi(sck), uart0(txd), ptp(trig) +mpp11 11 gpio, spi(miso), uart0(rxd), ptp(clk), ptp-1(evreq), + ptp-2(trig) +mpp12 12 gpo, sdio(clk) +mpp13 13 gpio, sdio(cmd), uart1(txd) +mpp14 14 gpio, sdio(d0), uart1(rxd), mii(col) +mpp15 15 gpio, sdio(d1), uart0(rts), uart1(txd) +mpp16 16 gpio, sdio(d2), uart0(cts), uart1(rxd), mii(crs) +mpp17 17 gpio, sdio(d3) +mpp18 18 gpo, nand(io0) +mpp19 19 gpo, nand(io1) +mpp20 20 gpio, mii(rxerr) +mpp21 21 gpio, audio(spdifi) +mpp22 22 gpio, audio(spdifo) +mpp23 23 gpio, audio(rmclk) +mpp24 24 gpio, audio(bclk) +mpp25 25 gpio, audio(sdo) +mpp26 26 gpio, audio(lrclk) +mpp27 27 gpio, audio(mclk) +mpp28 28 gpio, audio(sdi) +mpp29 29 gpio, audio(extclk) + +* Marvell Kirkwood 88f6190 + +name pins functions +================================================================================ +mpp0 0 gpio, nand(io2), spi(cs) +mpp1 1 gpo, nand(io3), spi(mosi) +mpp2 2 gpo, nand(io4), spi(sck) +mpp3 3 gpo, nand(io5), spi(miso) +mpp4 4 gpio, nand(io6), uart0(rxd), ptp(clk) +mpp5 5 gpo, nand(io7), uart0(txd), ptp(trig), sata0(act) +mpp6 6 sysrst(out), spi(mosi), ptp(trig) +mpp7 7 gpo, pex(rsto), spi(cs), ptp(trig) +mpp8 8 gpio, twsi0(sda), uart0(rts), uart1(rts), ptp(clk), + mii(col), mii-1(rxerr) +mpp9 9 gpio, twsi(sck), uart0(cts), uart1(cts), ptp(evreq), + mii(crs), sata0(prsnt) +mpp10 10 gpo, spi(sck), uart0(txd), ptp(trig) +mpp11 11 gpio, spi(miso), uart0(rxd), ptp(clk), ptp-1(evreq), + ptp-2(trig), sata0(act) +mpp12 12 gpo, sdio(clk) +mpp13 13 gpio, sdio(cmd), uart1(txd) +mpp14 14 gpio, sdio(d0), uart1(rxd), mii(col) +mpp15 15 gpio, sdio(d1), uart0(rts), uart1(txd), sata0(act) +mpp16 16 gpio, sdio(d2), uart0(cts), uart1(rxd), mii(crs) +mpp17 17 gpio, sdio(d3), sata0(prsnt) +mpp18 18 gpo, nand(io0) +mpp19 19 gpo, nand(io1) +mpp20 20 gpio, ge1(txd0) +mpp21 21 gpio, ge1(txd1), sata0(act) +mpp22 22 gpio, ge1(txd2) +mpp23 23 gpio, ge1(txd3), sata0(prsnt) +mpp24 24 gpio, ge1(rxd0) +mpp25 25 gpio, ge1(rxd1) +mpp26 26 gpio, ge1(rxd2) +mpp27 27 gpio, ge1(rxd3) +mpp28 28 gpio, ge1(col) +mpp29 29 gpio, ge1(txclk) +mpp30 30 gpio, ge1(rxclk) +mpp31 31 gpio, ge1(rxclk) +mpp32 32 gpio, ge1(txclko) +mpp33 33 gpo, ge1(txclk) +mpp34 34 gpio, ge1(txen) +mpp35 35 gpio, ge1(rxerr), sata0(act), mii(rxerr) + +* Marvell Kirkwood 88f6192 + +name pins functions +================================================================================ +mpp0 0 gpio, nand(io2), spi(cs) +mpp1 1 gpo, nand(io3), spi(mosi) +mpp2 2 gpo, nand(io4), spi(sck) +mpp3 3 gpo, nand(io5), spi(miso) +mpp4 4 gpio, nand(io6), uart0(rxd), ptp(clk), sata1(act) +mpp5 5 gpo, nand(io7), uart0(txd), ptp(trig), sata0(act) +mpp6 6 sysrst(out), spi(mosi), ptp(trig) +mpp7 7 gpo, pex(rsto), spi(cs), ptp(trig) +mpp8 8 gpio, twsi0(sda), uart0(rts), uart1(rts), ptp(clk), + mii(col), mii-1(rxerr), sata1(prsnt) +mpp9 9 gpio, twsi(sck), uart0(cts), uart1(cts), ptp(evreq), + mii(crs), sata0(prsnt) +mpp10 10 gpo, spi(sck), uart0(txd), ptp(trig), sata1(act) +mpp11 11 gpio, spi(miso), uart0(rxd), ptp(clk), ptp-1(evreq), + ptp-2(trig), sata0(act) +mpp12 12 gpo, sdio(clk) +mpp13 13 gpio, sdio(cmd), uart1(txd) +mpp14 14 gpio, sdio(d0), uart1(rxd), mii(col), sata1(prsnt) +mpp15 15 gpio, sdio(d1), uart0(rts), uart1(txd), sata0(act) +mpp16 16 gpio, sdio(d2), uart0(cts), uart1(rxd), mii(crs), + sata1(act) +mpp17 17 gpio, sdio(d3), sata0(prsnt) +mpp18 18 gpo, nand(io0) +mpp19 19 gpo, nand(io1) +mpp20 20 gpio, ge1(txd0), ts(mp0), tdm(tx0ql), audio(spdifi), + sata1(act) +mpp21 21 gpio, ge1(txd1), sata0(act), ts(mp1), tdm(rx0ql), + audio(spdifo) +mpp22 22 gpio, ge1(txd2), ts(mp2), tdm(tx2ql), audio(rmclk), + sata1(prsnt) +mpp23 23 gpio, ge1(txd3), sata0(prsnt), ts(mp3), tdm(rx2ql), + audio(bclk) +mpp24 24 gpio, ge1(rxd0), ts(mp4), tdm(spi-cs0), audio(sdo) +mpp25 25 gpio, ge1(rxd1), ts(mp5), tdm(spi-sck), audio(lrclk) +mpp26 26 gpio, ge1(rxd2), ts(mp6), tdm(spi-miso), audio(mclk) +mpp27 27 gpio, ge1(rxd3), ts(mp7), tdm(spi-mosi), audio(sdi) +mpp28 28 gpio, ge1(col), ts(mp8), tdm(int), audio(extclk) +mpp29 29 gpio, ge1(txclk), ts(mp9), tdm(rst) +mpp30 30 gpio, ge1(rxclk), ts(mp10), tdm(pclk) +mpp31 31 gpio, ge1(rxclk), ts(mp11), tdm(fs) +mpp32 32 gpio, ge1(txclko), ts(mp12), tdm(drx) +mpp33 33 gpo, ge1(txclk), tdm(drx) +mpp34 34 gpio, ge1(txen), tdm(spi-cs1) +mpp35 35 gpio, ge1(rxerr), sata0(act), mii(rxerr), tdm(tx0ql) + +* Marvell Kirkwood 88f6281 + +name pins functions +================================================================================ +mpp0 0 gpio, nand(io2), spi(cs) +mpp1 1 gpo, nand(io3), spi(mosi) +mpp2 2 gpo, nand(io4), spi(sck) +mpp3 3 gpo, nand(io5), spi(miso) +mpp4 4 gpio, nand(io6), uart0(rxd), ptp(clk), sata1(act) +mpp5 5 gpo, nand(io7), uart0(txd), ptp(trig), sata0(act) +mpp6 6 sysrst(out), spi(mosi), ptp(trig) +mpp7 7 gpo, pex(rsto), spi(cs), ptp(trig) +mpp8 8 gpio, twsi0(sda), uart0(rts), uart1(rts), ptp(clk), + mii(col), mii-1(rxerr), sata1(prsnt) +mpp9 9 gpio, twsi(sck), uart0(cts), uart1(cts), ptp(evreq), + mii(crs), sata0(prsnt) +mpp10 10 gpo, spi(sck), uart0(txd), ptp(trig), sata1(act) +mpp11 11 gpio, spi(miso), uart0(rxd), ptp(clk), ptp-1(evreq), + ptp-2(trig), sata0(act) +mpp12 12 gpio, sdio(clk) +mpp13 13 gpio, sdio(cmd), uart1(txd) +mpp14 14 gpio, sdio(d0), uart1(rxd), mii(col), sata1(prsnt) +mpp15 15 gpio, sdio(d1), uart0(rts), uart1(txd), sata0(act) +mpp16 16 gpio, sdio(d2), uart0(cts), uart1(rxd), mii(crs), + sata1(act) +mpp17 17 gpio, sdio(d3), sata0(prsnt) +mpp18 18 gpo, nand(io0) +mpp19 19 gpo, nand(io1) +mpp20 20 gpio, ge1(txd0), ts(mp0), tdm(tx0ql), audio(spdifi), + sata1(act) +mpp21 21 gpio, ge1(txd1), sata0(act), ts(mp1), tdm(rx0ql), + audio(spdifo) +mpp22 22 gpio, ge1(txd2), ts(mp2), tdm(tx2ql), audio(rmclk), + sata1(prsnt) +mpp23 23 gpio, ge1(txd3), sata0(prsnt), ts(mp3), tdm(rx2ql), + audio(bclk) +mpp24 24 gpio, ge1(rxd0), ts(mp4), tdm(spi-cs0), audio(sdo) +mpp25 25 gpio, ge1(rxd1), ts(mp5), tdm(spi-sck), audio(lrclk) +mpp26 26 gpio, ge1(rxd2), ts(mp6), tdm(spi-miso), audio(mclk) +mpp27 27 gpio, ge1(rxd3), ts(mp7), tdm(spi-mosi), audio(sdi) +mpp28 28 gpio, ge1(col), ts(mp8), tdm(int), audio(extclk) +mpp29 29 gpio, ge1(txclk), ts(mp9), tdm(rst) +mpp30 30 gpio, ge1(rxclk), ts(mp10), tdm(pclk) +mpp31 31 gpio, ge1(rxclk), ts(mp11), tdm(fs) +mpp32 32 gpio, ge1(txclko), ts(mp12), tdm(drx) +mpp33 33 gpo, ge1(txclk), tdm(drx) +mpp34 34 gpio, ge1(txen), tdm(spi-cs1), sata1(act) +mpp35 35 gpio, ge1(rxerr), sata0(act), mii(rxerr), tdm(tx0ql) +mpp36 36 gpio, ts(mp0), tdm(spi-cs1), audio(spdifi) +mpp37 37 gpio, ts(mp1), tdm(tx2ql), audio(spdifo) +mpp38 38 gpio, ts(mp2), tdm(rx2ql), audio(rmclk) +mpp39 39 gpio, ts(mp3), tdm(spi-cs0), audio(bclk) +mpp40 40 gpio, ts(mp4), tdm(spi-sck), audio(sdo) +mpp41 41 gpio, ts(mp5), tdm(spi-miso), audio(lrclk) +mpp42 42 gpio, ts(mp6), tdm(spi-mosi), audio(mclk) +mpp43 43 gpio, ts(mp7), tdm(int), audio(sdi) +mpp44 44 gpio, ts(mp8), tdm(rst), audio(extclk) +mpp45 45 gpio, ts(mp9), tdm(pclk) +mpp46 46 gpio, ts(mp10), tdm(fs) +mpp47 47 gpio, ts(mp11), tdm(drx) +mpp48 48 gpio, ts(mp12), tdm(dtx) +mpp49 49 gpio, ts(mp9), tdm(rx0ql), ptp(clk) + +* Marvell Kirkwood 88f6282 + +name pins functions +================================================================================ +mpp0 0 gpio, nand(io2), spi(cs) +mpp1 1 gpo, nand(io3), spi(mosi) +mpp2 2 gpo, nand(io4), spi(sck) +mpp3 3 gpo, nand(io5), spi(miso) +mpp4 4 gpio, nand(io6), uart0(rxd), sata1(act), lcd(hsync) +mpp5 5 gpo, nand(io7), uart0(txd), sata0(act), lcd(vsync) +mpp6 6 sysrst(out), spi(mosi) +mpp7 7 gpo, spi(cs), lcd(pwm) +mpp8 8 gpio, twsi0(sda), uart0(rts), uart1(rts), mii(col), + mii-1(rxerr), sata1(prsnt) +mpp9 9 gpio, twsi(sck), uart0(cts), uart1(cts), mii(crs), + sata0(prsnt) +mpp10 10 gpo, spi(sck), uart0(txd), sata1(act) +mpp11 11 gpio, spi(miso), uart0(rxd), sata0(act) +mpp12 12 gpo, sdio(clk), audio(spdifo), spi(mosi), twsi(sda) +mpp13 13 gpio, sdio(cmd), uart1(txd), audio(rmclk), lcd(pwm) +mpp14 14 gpio, sdio(d0), uart1(rxd), mii(col), sata1(prsnt), + audio(spdifi), audio-1(sdi) +mpp15 15 gpio, sdio(d1), uart0(rts), uart1(txd), sata0(act), + spi(cs) +mpp16 16 gpio, sdio(d2), uart0(cts), uart1(rxd), mii(crs), + sata1(act), lcd(extclk) +mpp17 17 gpio, sdio(d3), sata0(prsnt), sata1(act), twsi1(sck) +mpp18 18 gpo, nand(io0), pex(clkreq) +mpp19 19 gpo, nand(io1) +mpp20 20 gpio, ge1(txd0), ts(mp0), tdm(tx0ql), audio(spdifi), + sata1(act), lcd(d0) +mpp21 21 gpio, ge1(txd1), sata0(act), ts(mp1), tdm(rx0ql), + audio(spdifo), lcd(d1) +mpp22 22 gpio, ge1(txd2), ts(mp2), tdm(tx2ql), audio(rmclk), + sata1(prsnt), lcd(d2) +mpp23 23 gpio, ge1(txd3), sata0(prsnt), ts(mp3), tdm(rx2ql), + audio(bclk), lcd(d3) +mpp24 24 gpio, ge1(rxd0), ts(mp4), tdm(spi-cs0), audio(sdo), + lcd(d4) +mpp25 25 gpio, ge1(rxd1), ts(mp5), tdm(spi-sck), audio(lrclk), + lcd(d5) +mpp26 26 gpio, ge1(rxd2), ts(mp6), tdm(spi-miso), audio(mclk), + lcd(d6) +mpp27 27 gpio, ge1(rxd3), ts(mp7), tdm(spi-mosi), audio(sdi), + lcd(d7) +mpp28 28 gpio, ge1(col), ts(mp8), tdm(int), audio(extclk), + lcd(d8) +mpp29 29 gpio, ge1(txclk), ts(mp9), tdm(rst), lcd(d9) +mpp30 30 gpio, ge1(rxclk), ts(mp10), tdm(pclk), lcd(d10) +mpp31 31 gpio, ge1(rxclk), ts(mp11), tdm(fs), lcd(d11) +mpp32 32 gpio, ge1(txclko), ts(mp12), tdm(drx), lcd(d12) +mpp33 33 gpo, ge1(txclk), tdm(drx), lcd(d13) +mpp34 34 gpio, ge1(txen), tdm(spi-cs1), sata1(act), lcd(d14) +mpp35 35 gpio, ge1(rxerr), sata0(act), mii(rxerr), tdm(tx0ql), + lcd(d15) +mpp36 36 gpio, ts(mp0), tdm(spi-cs1), audio(spdifi), twsi1(sda) +mpp37 37 gpio, ts(mp1), tdm(tx2ql), audio(spdifo), twsi1(sck) +mpp38 38 gpio, ts(mp2), tdm(rx2ql), audio(rmclk), lcd(d18) +mpp39 39 gpio, ts(mp3), tdm(spi-cs0), audio(bclk), lcd(d19) +mpp40 40 gpio, ts(mp4), tdm(spi-sck), audio(sdo), lcd(d20) +mpp41 41 gpio, ts(mp5), tdm(spi-miso), audio(lrclk), lcd(d21) +mpp42 42 gpio, ts(mp6), tdm(spi-mosi), audio(mclk), lcd(d22) +mpp43 43 gpio, ts(mp7), tdm(int), audio(sdi), lcd(d23) +mpp44 44 gpio, ts(mp8), tdm(rst), audio(extclk), lcd(clk) +mpp45 45 gpio, ts(mp9), tdm(pclk), lcd(e) +mpp46 46 gpio, ts(mp10), tdm(fs), lcd(hsync) +mpp47 47 gpio, ts(mp11), tdm(drx), lcd(vsync) +mpp48 48 gpio, ts(mp12), tdm(dtx), lcd(d16) +mpp49 49 gpo, tdm(rx0ql), pex(clkreq), lcd(d17) diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt new file mode 100644 index 000000000000..0a26c3aa4e6d --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt @@ -0,0 +1,46 @@ +* Marvell SoC pinctrl core driver for mpp + +The pinctrl driver enables Marvell SoCs to configure the multi-purpose pins +(mpp) to a specific function. For each SoC family there is a SoC specific +driver using this core driver. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase "pin configuration node". + +A Marvell SoC pin configuration node is a node of a group of pins which can +be used for a specific device or function. Each node requires one or more +mpp pins or group of pins and a mpp function common to all pins. + +Required properties for pinctrl driver: +- compatible: "marvell,<soc>-pinctrl" + Please refer to each marvell,<soc>-pinctrl.txt binding doc for supported SoCs. + +Required properties for pin configuration node: +- marvell,pins: string array of mpp pins or group of pins to be muxed. +- marvell,function: string representing a function to mux to for all + marvell,pins given in this pin configuration node. The function has to be + common for all marvell,pins. Please refer to marvell,<soc>-pinctrl.txt for + valid pin/pin group names and available function names for each SoC. + +Examples: + +uart1: serial@12100 { + compatible = "ns16550a"; + reg = <0x12100 0x100>; + reg-shift = <2>; + interrupts = <7>; + + pinctrl-0 = <&pmx_uart1_sw>; + pinctrl-names = "default"; +}; + +pinctrl: pinctrl@d0200 { + compatible = "marvell,dove-pinctrl"; + reg = <0xd0200 0x20>; + + pmx_uart1_sw: pmx-uart1-sw { + marvell,pins = "mpp_uart1"; + marvell,function = "uart1"; + }; +}; diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.txt index c8e578263ce2..683fde93c4fb 100644 --- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.txt +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra20-pinmux.txt @@ -93,7 +93,7 @@ Valid values for pin and group names are: With some exceptions, these support nvidia,high-speed-mode, nvidia,schmitt, nvidia,low-power-mode, nvidia,pull-down-strength, - nvidia,pull-up-strength, nvidia,slew_rate-rising, nvidia,slew_rate-falling. + nvidia,pull-up-strength, nvidia,slew-rate-rising, nvidia,slew-rate-falling. drive_ao1, drive_ao2, drive_at1, drive_at2, drive_cdev1, drive_cdev2, drive_csus, drive_dap1, drive_dap2, drive_dap3, drive_dap4, drive_dbg, diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.txt index c275b70349c1..6f426ed7009e 100644 --- a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.txt +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra30-pinmux.txt @@ -83,7 +83,7 @@ Valid values for pin and group names are: drive groups: These all support nvidia,pull-down-strength, nvidia,pull-up-strength, - nvidia,slew_rate-rising, nvidia,slew_rate-falling. Most but not all + nvidia,slew-rate-rising, nvidia,slew-rate-falling. Most but not all support nvidia,high-speed-mode, nvidia,schmitt, nvidia,low-power-mode. ao1, ao2, at1, at2, at3, at4, at5, cdev1, cdev2, cec, crt, csus, dap1, diff --git a/Documentation/devicetree/bindings/powerpc/fsl/ifc.txt b/Documentation/devicetree/bindings/powerpc/fsl/ifc.txt index 939a26d541f6..d5e370450ac0 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/ifc.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/ifc.txt @@ -12,9 +12,12 @@ Properties: - #size-cells : Either one or two, depending on how large each chipselect can be. - reg : Offset and length of the register set for the device -- interrupts : IFC has two interrupts. The first one is the "common" - interrupt(CM_EVTER_STAT), and second is the NAND interrupt - (NAND_EVTER_STAT). +- interrupts: IFC may have one or two interrupts. If two interrupt + specifiers are present, the first is the "common" + interrupt (CM_EVTER_STAT), and the second is the NAND + interrupt (NAND_EVTER_STAT). If there is only one, + that interrupt reports both types of event. + - ranges : Each range corresponds to a single chipselect, and covers the entire access window as configured. diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt b/Documentation/devicetree/bindings/pwm/imx-pwm.txt new file mode 100644 index 000000000000..8522bfbccfd7 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/imx-pwm.txt @@ -0,0 +1,17 @@ +Freescale i.MX PWM controller + +Required properties: +- compatible: should be "fsl,<soc>-pwm" +- reg: physical base address and length of the controller's registers +- #pwm-cells: should be 2. The first cell specifies the per-chip index + of the PWM to use and the second cell is the period in nanoseconds. +- interrupts: The interrupt for the pwm controller + +Example: + +pwm1: pwm@53fb4000 { + #pwm-cells = <2>; + compatible = "fsl,imx53-pwm", "fsl,imx27-pwm"; + reg = <0x53fb4000 0x4000>; + interrupts = <61>; +}; diff --git a/Documentation/devicetree/bindings/pwm/mxs-pwm.txt b/Documentation/devicetree/bindings/pwm/mxs-pwm.txt index 11963e4d6bc4..9e3f8f1d46a2 100644 --- a/Documentation/devicetree/bindings/pwm/mxs-pwm.txt +++ b/Documentation/devicetree/bindings/pwm/mxs-pwm.txt @@ -4,7 +4,7 @@ Required properties: - compatible: should be "fsl,imx23-pwm" - reg: physical base address and length of the controller's registers - #pwm-cells: should be 2. The first cell specifies the per-chip index - of the PWM to use and the second cell is the duty cycle in nanoseconds. + of the PWM to use and the second cell is the period in nanoseconds. - fsl,pwm-number: the number of PWM devices Example: diff --git a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt index bbbeedb4ec05..01438ecd6628 100644 --- a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt +++ b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt @@ -7,7 +7,7 @@ Required properties: - reg: physical base address and length of the controller's registers - #pwm-cells: On Tegra the number of cells used to specify a PWM is 2. The first cell specifies the per-chip index of the PWM to use and the second - cell is the duty cycle in nanoseconds. + cell is the period in nanoseconds. Example: diff --git a/Documentation/devicetree/bindings/regulator/88pm860x.txt b/Documentation/devicetree/bindings/regulator/88pm860x.txt new file mode 100644 index 000000000000..1267b3e1a2cc --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/88pm860x.txt @@ -0,0 +1,30 @@ +Marvell 88PM860x regulator + +Required properties: +- compatible: "marvell,88pm860x" +- reg: I2C slave address +- regulators: A node that houses a sub-node for each regulator within the + device. Each sub-node is identified using the regulator-compatible + property, with valid values listed below. + +Example: + + pmic: 88pm860x@34 { + compatible = "marvell,88pm860x"; + reg = <0x34>; + + regulators { + BUCK1 { + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1500000>; + regulator-boot-on; + regulator-always-on; + }; + BUCK3 { + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <3000000>; + regulator-boot-on; + regulator-always-on; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/max8907.txt b/Documentation/devicetree/bindings/regulator/max8907.txt new file mode 100644 index 000000000000..371eccd1cd68 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/max8907.txt @@ -0,0 +1,69 @@ +MAX8907 regulator + +Required properties: +- compatible: "maxim,max8907" +- reg: I2C slave address +- interrupts: The interrupt output of the controller +- mbatt-supply: The input supply for MBATT, BBAT, SDBY, VRTC. +- in-v1-supply: The input supply for SD1. +- in-v2-supply: The input supply for SD2. +- in-v3-supply: The input supply for SD3. +- in1-supply: The input supply for LDO1. +... +- in20-supply: The input supply for LDO20. +- regulators: A node that houses a sub-node for each regulator within the + device. Each sub-node is identified using the node's name (or the deprecated + regulator-compatible property if present), with valid values listed below. + The content of each sub-node is defined by the standard binding for + regulators; see regulator.txt. + +Optional properties: +- maxim,system-power-controller: Boolean property indicating that the PMIC + controls the overall system power. + +The valid names for regulators are: + + sd1, sd2, sd3, ldo1, ldo2, ldo3, ldo4, ldo5, ldo6, ldo7, ldo8, ldo9, ldo10, + ldo11, ldo12, ldo13, ldo14, ldo15, ldo16, ldo17, ldo18, ldo19, ldo20, out5v, + out33v, bbat, sdby, vrtc. + +Example: + + max8907@3c { + compatible = "maxim,max8907"; + reg = <0x3c>; + interrupts = <0 86 0x4>; + + maxim,system-power-controller; + + mbatt-supply = <&some_reg>; + in-v1-supply = <&mbatt_reg>; + ... + in1-supply = <&mbatt_reg>; + ... + + regulators { + mbatt_reg: mbatt { + regulator-name = "vbat_pmu"; + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <5000000>; + regulator-always-on; + }; + + sd1 { + regulator-name = "nvvdd_sv1,vdd_cpu_pmu"; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1000000>; + regulator-always-on; + }; + + sd2 { + regulator-name = "nvvdd_sv2,vdd_core"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + regulator-always-on; + }; +... + }; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/tps6586x.txt b/Documentation/devicetree/bindings/regulator/tps6586x.txt index 07b9ef6e49d5..8b40cac24d93 100644 --- a/Documentation/devicetree/bindings/regulator/tps6586x.txt +++ b/Documentation/devicetree/bindings/regulator/tps6586x.txt @@ -22,6 +22,10 @@ Required properties: - vinldo678-supply: The input supply for the LDO6, LDO7 and LDO8 - vinldo9-supply: The input supply for the LDO9 +Optional properties: +- ti,system-power-controller: Telling whether or not this pmic is controlling + the system power. + Each regulator is defined using the standard binding for regulators. Note: LDO5 and LDO_RTC is supplied by SYS regulator internally and driver @@ -37,6 +41,8 @@ Example: #gpio-cells = <2>; gpio-controller; + ti,system-power-controller; + sys-supply = <&some_reg>; vin-sm0-supply = <&some_reg>; vin-sm1-supply = <&some_reg>; diff --git a/Documentation/devicetree/bindings/rtc/snvs-rtc.txt b/Documentation/devicetree/bindings/rtc/snvs-rtc.txt new file mode 100644 index 000000000000..fb61ed77ada3 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/snvs-rtc.txt @@ -0,0 +1 @@ +See Documentation/devicetree/bindings/crypto/fsl-sec4.txt for details. diff --git a/Documentation/devicetree/bindings/sound/cs4270.txt b/Documentation/devicetree/bindings/sound/cs4270.txt new file mode 100644 index 000000000000..6b222f9b8ef5 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/cs4270.txt @@ -0,0 +1,21 @@ +CS4270 audio CODEC + +The driver for this device currently only supports I2C. + +Required properties: + + - compatible : "cirrus,cs4270" + + - reg : the I2C address of the device for I2C + +Optional properties: + + - reset-gpio : a GPIO spec for the reset pin. If specified, it will be + deasserted before communication to the codec starts. + +Example: + +codec: cs4270@48 { + compatible = "cirrus,cs4270"; + reg = <0x48>; +}; diff --git a/Documentation/devicetree/bindings/sound/cs4271.txt b/Documentation/devicetree/bindings/sound/cs4271.txt new file mode 100644 index 000000000000..c81b5fd5a5bc --- /dev/null +++ b/Documentation/devicetree/bindings/sound/cs4271.txt @@ -0,0 +1,36 @@ +Cirrus Logic CS4271 DT bindings + +This driver supports both the I2C and the SPI bus. + +Required properties: + + - compatible: "cirrus,cs4271" + +For required properties on SPI, please consult +Documentation/devicetree/bindings/spi/spi-bus.txt + +Required properties on I2C: + + - reg: the i2c address + + +Optional properties: + + - reset-gpio: a GPIO spec to define which pin is connected to the chip's + !RESET pin + +Examples: + + codec_i2c: cs4271@10 { + compatible = "cirrus,cs4271"; + reg = <0x10>; + reset-gpio = <&gpio 23 0>; + }; + + codec_spi: cs4271@0 { + compatible = "cirrus,cs4271"; + reg = <0x0>; + reset-gpio = <&gpio 23 0>; + spi-max-frequency = <6000000>; + }; + diff --git a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt new file mode 100644 index 000000000000..374e145c2ef1 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt @@ -0,0 +1,45 @@ +Texas Instruments McASP controller + +Required properties: +- compatible : + "ti,dm646x-mcasp-audio" : for DM646x platforms + "ti,da830-mcasp-audio" : for both DA830 & DA850 platforms + "ti,omap2-mcasp-audio" : for OMAP2 platforms (TI81xx, AM33xx) + +- reg : Should contain McASP registers offset and length +- interrupts : Interrupt number for McASP +- op-mode : I2S/DIT ops mode. +- tdm-slots : Slots for TDM operation. +- num-serializer : Serializers used by McASP. +- serial-dir : A list of serializer pin mode. The list number should be equal + to "num-serializer" parameter. Each entry is a number indication + serializer pin direction. (0 - INACTIVE, 1 - TX, 2 - RX) + + +Optional properties: + +- ti,hwmods : Must be "mcasp<n>", n is controller instance starting 0 +- tx-num-evt : FIFO levels. +- rx-num-evt : FIFO levels. +- sram-size-playback : size of sram to be allocated during playback +- sram-size-capture : size of sram to be allocated during capture + +Example: + +mcasp0: mcasp0@1d00000 { + compatible = "ti,da830-mcasp-audio"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x100000 0x3000>; + interrupts = <82 83>; + op-mode = <0>; /* MCASP_IIS_MODE */ + tdm-slots = <2>; + num-serializer = <16>; + serial-dir = < + 0 0 0 0 /* 0: INACTIVE, 1: TX, 2: RX */ + 0 0 0 0 + 0 0 0 1 + 2 0 0 0 >; + tx-num-evt = <1>; + rx-num-evt = <1>; +}; diff --git a/Documentation/devicetree/bindings/sound/omap-abe-twl6040.txt b/Documentation/devicetree/bindings/sound/omap-abe-twl6040.txt new file mode 100644 index 000000000000..65dec876cb2d --- /dev/null +++ b/Documentation/devicetree/bindings/sound/omap-abe-twl6040.txt @@ -0,0 +1,91 @@ +* Texas Instruments OMAP4+ and twl6040 based audio setups + +Required properties: +- compatible: "ti,abe-twl6040" +- ti,model: Name of the sound card ( for example "SDP4430") +- ti,mclk-freq: MCLK frequency for HPPLL operation +- ti,mcpdm: phandle for the McPDM node +- ti,twl6040: phandle for the twl6040 core node +- ti,audio-routing: List of connections between audio components. + Each entry is a pair of strings, the first being the connection's sink, + the second being the connection's source. + +Optional properties: +- ti,dmic: phandle for the OMAP dmic node if the machine have it connected +- ti,jack_detection: Need to be set to <1> if the board capable to detect jack + insertion, removal. + +Available audio endpoints for the audio-routing table: + +Board connectors: + * Headset Stereophone + * Earphone Spk + * Ext Spk + * Line Out + * Vibrator + * Headset Mic + * Main Handset Mic + * Sub Handset Mic + * Line In + * Digital Mic + +twl6040 pins: + * HSOL + * HSOR + * EP + * HFL + * HFR + * AUXL + * AUXR + * VIBRAL + * VIBRAR + * HSMIC + * MAINMIC + * SUBMIC + * AFML + * AFMR + + * Headset Mic Bias + * Main Mic Bias + * Digital Mic1 Bias + * Digital Mic2 Bias + +Digital mic pins: + * DMic + +Example: + +sound { + compatible = "ti,abe-twl6040"; + ti,model = "SDP4430"; + + ti,jack-detection = <1>; + ti,mclk-freq = <38400000>; + + ti,mcpdm = <&mcpdm>; + ti,dmic = <&dmic>; + + ti,twl6040 = <&twl6040>; + + /* Audio routing */ + ti,audio-routing = + "Headset Stereophone", "HSOL", + "Headset Stereophone", "HSOR", + "Earphone Spk", "EP", + "Ext Spk", "HFL", + "Ext Spk", "HFR", + "Line Out", "AUXL", + "Line Out", "AUXR", + "Vibrator", "VIBRAL", + "Vibrator", "VIBRAR", + "HSMIC", "Headset Mic", + "Headset Mic", "Headset Mic Bias", + "MAINMIC", "Main Handset Mic", + "Main Handset Mic", "Main Mic Bias", + "SUBMIC", "Sub Handset Mic", + "Sub Handset Mic", "Main Mic Bias", + "AFML", "Line In", + "AFMR", "Line In", + "DMic", "Digital Mic", + "Digital Mic", "Digital Mic1 Bias"; +}; diff --git a/Documentation/devicetree/bindings/sound/omap-mcbsp.txt b/Documentation/devicetree/bindings/sound/omap-mcbsp.txt new file mode 100644 index 000000000000..17cce4490456 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/omap-mcbsp.txt @@ -0,0 +1,37 @@ +* Texas Instruments OMAP2+ McBSP module + +Required properties: +- compatible: "ti,omap2420-mcbsp" for McBSP on OMAP2420 + "ti,omap2430-mcbsp" for McBSP on OMAP2430 + "ti,omap3-mcbsp" for McBSP on OMAP3 + "ti,omap4-mcbsp" for McBSP on OMAP4 and newer SoC +- reg: Register location and size, for OMAP4+ as an array: + <MPU access base address, size>, + <L3 interconnect address, size>; +- reg-names: Array of strings associated with the address space +- interrupts: Interrupt numbers for the McBSP port, as an array in case the + McBSP IP have more interrupt lines: + <OCP compliant irq>, + <TX irq>, + <RX irq>; +- interrupt-names: Array of strings associated with the interrupt numbers +- interrupt-parent: The parent interrupt controller +- ti,buffer-size: Size of the FIFO on the port (OMAP2430 and newer SoC) +- ti,hwmods: Name of the hwmod associated to the McBSP port + +Example: + +mcbsp2: mcbsp@49022000 { + compatible = "ti,omap3-mcbsp"; + reg = <0x49022000 0xff>, + <0x49028000 0xff>; + reg-names = "mpu", "sidetone"; + interrupts = <0 17 0x4>, /* OCP compliant interrupt */ + <0 62 0x4>, /* TX interrupt */ + <0 63 0x4>, /* RX interrupt */ + <0 4 0x4>; /* Sidetone */ + interrupt-names = "common", "tx", "rx", "sidetone"; + interrupt-parent = <&intc>; + ti,buffer-size = <1280>; + ti,hwmods = "mcbsp2"; +}; diff --git a/Documentation/devicetree/bindings/sound/omap-twl4030.txt b/Documentation/devicetree/bindings/sound/omap-twl4030.txt new file mode 100644 index 000000000000..6fae51c7f766 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/omap-twl4030.txt @@ -0,0 +1,17 @@ +* Texas Instruments SoC with twl4030 based audio setups + +Required properties: +- compatible: "ti,omap-twl4030" +- ti,model: Name of the sound card (for example "omap3beagle") +- ti,mcbsp: phandle for the McBSP node +- ti,codec: phandle for the twl4030 audio node + +Example: + +sound { + compatible = "ti,omap-twl4030"; + ti,model = "omap3beagle"; + + ti,mcbsp = <&mcbsp2>; + ti,codec = <&twl_audio>; +}; diff --git a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt new file mode 100644 index 000000000000..e7b98f41fa5f --- /dev/null +++ b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt @@ -0,0 +1,20 @@ +Texas Instruments - tlv320aic3x Codec module + +The tlv320aic3x serial control bus communicates through I2C protocols + +Required properties: +- compatible - "string" - "ti,tlv320aic3x" +- reg - <int> - I2C slave address + + +Optional properties: + +- gpio-reset - gpio pin number used for codec reset +- ai3x-gpio-func - <array of 2 int> - AIC3X_GPIO1 & AIC3X_GPIO2 Functionality + +Example: + +tlv320aic3x: tlv320aic3x@1b { + compatible = "ti,tlv320aic3x"; + reg = <0x1b>; +}; diff --git a/Documentation/devicetree/bindings/spi/spi-octeon.txt b/Documentation/devicetree/bindings/spi/spi-octeon.txt new file mode 100644 index 000000000000..431add192342 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-octeon.txt @@ -0,0 +1,33 @@ +Cavium, Inc. OCTEON SOC SPI master controller. + +Required properties: +- compatible : "cavium,octeon-3010-spi" +- reg : The register base for the controller. +- interrupts : One interrupt, used by the controller. +- #address-cells : <1>, as required by generic SPI binding. +- #size-cells : <0>, also as required by generic SPI binding. + +Child nodes as per the generic SPI binding. + +Example: + + spi@1070000001000 { + compatible = "cavium,octeon-3010-spi"; + reg = <0x10700 0x00001000 0x0 0x100>; + interrupts = <0 58>; + #address-cells = <1>; + #size-cells = <0>; + + eeprom@0 { + compatible = "st,m95256", "atmel,at25"; + reg = <0>; + spi-max-frequency = <5000000>; + spi-cpha; + spi-cpol; + + pagesize = <64>; + size = <32768>; + address-width = <16>; + }; + }; + diff --git a/Documentation/devicetree/bindings/timer/brcm,bcm2835-system-timer.txt b/Documentation/devicetree/bindings/timer/brcm,bcm2835-system-timer.txt index 2de21c2acf55..844bd5fbd04c 100644 --- a/Documentation/devicetree/bindings/timer/brcm,bcm2835-system-timer.txt +++ b/Documentation/devicetree/bindings/timer/brcm,bcm2835-system-timer.txt @@ -7,7 +7,7 @@ free running counter values, and generates an interrupt. Required properties: -- compatible : should be "brcm,bcm2835-system-timer.txt" +- compatible : should be "brcm,bcm2835-system-timer" - reg : Specifies base physical address and size of the registers. - interrupts : A list of 4 interrupt sinks; one per timer channel. - clock-frequency : The frequency of the clock that drives the counter, in Hz. diff --git a/Documentation/devicetree/bindings/video/backlight/88pm860x.txt b/Documentation/devicetree/bindings/video/backlight/88pm860x.txt new file mode 100644 index 000000000000..261df2799315 --- /dev/null +++ b/Documentation/devicetree/bindings/video/backlight/88pm860x.txt @@ -0,0 +1,15 @@ +88pm860x-backlight bindings + +Optional properties: + - marvell,88pm860x-iset: Current supplies on backlight device. + - marvell,88pm860x-pwm: PWM frequency on backlight device. + +Example: + + backlights { + backlight-0 { + marvell,88pm860x-iset = <4>; + marvell,88pm860x-pwm = <3>; + }; + backlight-2 { + }; diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt index 950856bd2e39..43cff70465ab 100644 --- a/Documentation/driver-model/devres.txt +++ b/Documentation/driver-model/devres.txt @@ -284,3 +284,7 @@ CLOCK PINCTRL devm_pinctrl_get() devm_pinctrl_put() + +PWM + devm_pwm_get() + devm_pwm_put() diff --git a/Documentation/dvb/README.dvb-usb b/Documentation/dvb/README.dvb-usb index c4d963a67d6f..8eb92264ee04 100644 --- a/Documentation/dvb/README.dvb-usb +++ b/Documentation/dvb/README.dvb-usb @@ -30,7 +30,7 @@ with the device via the bus. The connection between the DVB-API-functionality is done via callbacks, assigned in a static device-description (struct dvb_usb_device) each device-driver has to have. -For an example have a look in drivers/media/dvb/dvb-usb/vp7045*. +For an example have a look in drivers/media/usb/dvb-usb/vp7045*. Objective is to migrate all the usb-devices (dibusb, cinergyT2, maybe the ttusb; flexcop-usb already benefits from the generic flexcop-device) to use diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware index 12d3952e83d5..32bc56b13b1c 100755 --- a/Documentation/dvb/get_dvb_firmware +++ b/Documentation/dvb/get_dvb_firmware @@ -116,7 +116,7 @@ sub tda10045 { sub tda10046 { my $sourcefile = "TT_PCI_2.19h_28_11_2006.zip"; - my $url = "http://www.tt-download.com/download/updates/219/$sourcefile"; + my $url = "http://technotrend.com.ua/download/software/219/$sourcefile"; my $hash = "6a7e1e2f2644b162ff0502367553c72d"; my $outfile = "dvb-fe-tda10046.fw"; my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 1); diff --git a/Documentation/filesystems/ext4.txt b/Documentation/filesystems/ext4.txt index 1b7f9acbcbbe..104322bf378c 100644 --- a/Documentation/filesystems/ext4.txt +++ b/Documentation/filesystems/ext4.txt @@ -375,6 +375,16 @@ dioread_nolock locking. If the dioread_nolock option is specified Because of the restrictions this options comprises it is off by default (e.g. dioread_lock). +max_dir_size_kb=n This limits the size of directories so that any + attempt to expand them beyond the specified + limit in kilobytes will cause an ENOSPC error. + This is useful in memory constrained + environments, where a very large directory can + cause severe performance problems or even + provoke the Out Of Memory killer. (For example, + if there is only 512mb memory available, a 176mb + directory may seriously cramp the system's style.) + i_version Enable 64-bit inode version support. This option is off by default. diff --git a/Documentation/filesystems/nfs/nfs.txt b/Documentation/filesystems/nfs/nfs.txt index f50f26ce6cd0..f2571c8bef74 100644 --- a/Documentation/filesystems/nfs/nfs.txt +++ b/Documentation/filesystems/nfs/nfs.txt @@ -12,9 +12,47 @@ and work is in progress on adding support for minor version 1 of the NFSv4 protocol. The purpose of this document is to provide information on some of the -upcall interfaces that are used in order to provide the NFS client with -some of the information that it requires in order to fully comply with -the NFS spec. +special features of the NFS client that can be configured by system +administrators. + + +The nfs4_unique_id parameter +============================ + +NFSv4 requires clients to identify themselves to servers with a unique +string. File open and lock state shared between one client and one server +is associated with this identity. To support robust NFSv4 state recovery +and transparent state migration, this identity string must not change +across client reboots. + +Without any other intervention, the Linux client uses a string that contains +the local system's node name. System administrators, however, often do not +take care to ensure that node names are fully qualified and do not change +over the lifetime of a client system. Node names can have other +administrative requirements that require particular behavior that does not +work well as part of an nfs_client_id4 string. + +The nfs.nfs4_unique_id boot parameter specifies a unique string that can be +used instead of a system's node name when an NFS client identifies itself to +a server. Thus, if the system's node name is not unique, or it changes, its +nfs.nfs4_unique_id stays the same, preventing collision with other clients +or loss of state during NFS reboot recovery or transparent state migration. + +The nfs.nfs4_unique_id string is typically a UUID, though it can contain +anything that is believed to be unique across all NFS clients. An +nfs4_unique_id string should be chosen when a client system is installed, +just as a system's root file system gets a fresh UUID in its label at +install time. + +The string should remain fixed for the lifetime of the client. It can be +changed safely if care is taken that the client shuts down cleanly and all +outstanding NFSv4 state has expired, to prevent loss of NFSv4 state. + +This string can be stored in an NFS client's grub.conf, or it can be provided +via a net boot facility such as PXE. It may also be specified as an nfs.ko +module parameter. Specifying a uniquifier string is not support for NFS +clients running in containers. + The DNS resolver ================ diff --git a/Documentation/filesystems/nfs/nfsd-admin-interfaces.txt b/Documentation/filesystems/nfs/nfsd-admin-interfaces.txt new file mode 100644 index 000000000000..56a96fb08a73 --- /dev/null +++ b/Documentation/filesystems/nfs/nfsd-admin-interfaces.txt @@ -0,0 +1,41 @@ +Administrative interfaces for nfsd +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +Note that normally these interfaces are used only by the utilities in +nfs-utils. + +nfsd is controlled mainly by pseudofiles under the "nfsd" filesystem, +which is normally mounted at /proc/fs/nfsd/. + +The server is always started by the first write of a nonzero value to +nfsd/threads. + +Before doing that, NFSD can be told which sockets to listen on by +writing to nfsd/portlist; that write may be: + + - an ascii-encoded file descriptor, which should refer to a + bound (and listening, for tcp) socket, or + - "transportname port", where transportname is currently either + "udp", "tcp", or "rdma". + +If nfsd is started without doing any of these, then it will create one +udp and one tcp listener at port 2049 (see nfsd_init_socks). + +On startup, nfsd and lockd grace periods start. + +nfsd is shut down by a write of 0 to nfsd/threads. All locks and state +are thrown away at that point. + +Between startup and shutdown, the number of threads may be adjusted up +or down by additional writes to nfsd/threads or by writes to +nfsd/pool_threads. + +For more detail about files under nfsd/ and what they control, see +fs/nfsd/nfsctl.c; most of them have detailed comments. + +Implementation notes +^^^^^^^^^^^^^^^^^^^^ + +Note that the rpc server requires the caller to serialize addition and +removal of listening sockets, and startup and shutdown of the server. +For nfsd this is done using nfsd_mutex. diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index fb0a6aeb936c..a1793d670cd0 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -33,7 +33,7 @@ Table of Contents 2 Modifying System Parameters 3 Per-Process Parameters - 3.1 /proc/<pid>/oom_adj & /proc/<pid>/oom_score_adj - Adjust the oom-killer + 3.1 /proc/<pid>/oom_score_adj - Adjust the oom-killer score 3.2 /proc/<pid>/oom_score - Display current oom-killer score 3.3 /proc/<pid>/io - Display the IO accounting fields @@ -1320,10 +1320,10 @@ of the kernel. CHAPTER 3: PER-PROCESS PARAMETERS ------------------------------------------------------------------------------ -3.1 /proc/<pid>/oom_adj & /proc/<pid>/oom_score_adj- Adjust the oom-killer score +3.1 /proc/<pid>/oom_score_adj- Adjust the oom-killer score -------------------------------------------------------------------------------- -These file can be used to adjust the badness heuristic used to select which +This file can be used to adjust the badness heuristic used to select which process gets killed in out of memory conditions. The badness heuristic assigns a value to each candidate task ranging from 0 @@ -1361,22 +1361,10 @@ same system, cpuset, mempolicy, or memory controller resources to use at least equivalent to discounting 50% of the task's allowed memory from being considered as scoring against the task. -For backwards compatibility with previous kernels, /proc/<pid>/oom_adj may also -be used to tune the badness score. Its acceptable values range from -16 -(OOM_ADJUST_MIN) to +15 (OOM_ADJUST_MAX) and a special value of -17 -(OOM_DISABLE) to disable oom killing entirely for that task. Its value is -scaled linearly with /proc/<pid>/oom_score_adj. - -Writing to /proc/<pid>/oom_score_adj or /proc/<pid>/oom_adj will change the -other with its scaled value. - The value of /proc/<pid>/oom_score_adj may be reduced no lower than the last value set by a CAP_SYS_RESOURCE process. To reduce the value any lower requires CAP_SYS_RESOURCE. -NOTICE: /proc/<pid>/oom_adj is deprecated and will be removed, please see -Documentation/feature-removal-schedule.txt. - Caveat: when a parent task is selected, the oom killer will sacrifice any first generation children with separate address spaces instead, if possible. This avoids servers and important system daemons from being killed and loses the @@ -1387,9 +1375,7 @@ minimal amount of work. ------------------------------------------------------------- This file can be used to check the current score used by the oom-killer is for -any given <pid>. Use it together with /proc/<pid>/oom_adj to tune which -process should be killed in an out-of-memory situation. - +any given <pid>. 3.3 /proc/<pid>/io - Display the IO accounting fields ------------------------------------------------------- diff --git a/Documentation/firmware_class/README b/Documentation/firmware_class/README index 7eceaff63f5f..815b711bcd85 100644 --- a/Documentation/firmware_class/README +++ b/Documentation/firmware_class/README @@ -18,32 +18,40 @@ High level behavior (mixed): ============================ - kernel(driver): calls request_firmware(&fw_entry, $FIRMWARE, device) - - userspace: + 1), kernel(driver): + - calls request_firmware(&fw_entry, $FIRMWARE, device) + - kernel searchs the fimware image with name $FIRMWARE directly + in the below search path of root filesystem: + "/lib/firmware/updates/" UTS_RELEASE, + "/lib/firmware/updates", + "/lib/firmware/" UTS_RELEASE, + "/lib/firmware" + - If found, goto 7), else goto 2) + + 2), userspace: - /sys/class/firmware/xxx/{loading,data} appear. - hotplug gets called with a firmware identifier in $FIRMWARE and the usual hotplug environment. - hotplug: echo 1 > /sys/class/firmware/xxx/loading - kernel: Discard any previous partial load. + 3), kernel: Discard any previous partial load. - userspace: + 4), userspace: - hotplug: cat appropriate_firmware_image > \ /sys/class/firmware/xxx/data - kernel: grows a buffer in PAGE_SIZE increments to hold the image as it + 5), kernel: grows a buffer in PAGE_SIZE increments to hold the image as it comes in. - userspace: + 6), userspace: - hotplug: echo 0 > /sys/class/firmware/xxx/loading - kernel: request_firmware() returns and the driver has the firmware + 7), kernel: request_firmware() returns and the driver has the firmware image in fw_entry->{data,size}. If something went wrong request_firmware() returns non-zero and fw_entry is set to NULL. - kernel(driver): Driver code calls release_firmware(fw_entry) releasing + 8), kernel(driver): Driver code calls release_firmware(fw_entry) releasing the firmware image and any related resource. High level behavior (driver code): diff --git a/Documentation/hwmon/coretemp b/Documentation/hwmon/coretemp index c86b50c03ea8..f17256f069ba 100644 --- a/Documentation/hwmon/coretemp +++ b/Documentation/hwmon/coretemp @@ -105,6 +105,7 @@ Process Processor TjMax(C) 330/230 125 E680/660/640/620 90 E680T/660T/640T/620T 110 + CE4170/4150/4110 110 45nm Core2 Processors Solo ULV SU3500/3300 100 diff --git a/Documentation/hwmon/da9052 b/Documentation/hwmon/da9052 index ef898553638e..5bc51346b689 100644 --- a/Documentation/hwmon/da9052 +++ b/Documentation/hwmon/da9052 @@ -56,6 +56,6 @@ The junction temperature is calculated: The junction temperature attribute is supported by the driver. The battery temperature is calculated: - Degree Celcius = 1 / (t1 + 1/298)- 273 + Degree Celsius = 1 / (t1 + 1/298)- 273 where t1 = (1/B)* ln(( ADCval * 2.5)/(R25*ITBAT*255)) Default values of R25, B, ITBAT are 10e3, 3380 and 50e-6 respectively. diff --git a/Documentation/hwmon/max1619 b/Documentation/hwmon/max1619 index d6f8d9cd7d7f..e6d87398cc8f 100644 --- a/Documentation/hwmon/max1619 +++ b/Documentation/hwmon/max1619 @@ -9,7 +9,7 @@ Supported chips: http://pdfserv.maxim-ic.com/en/ds/MAX1619.pdf Authors: - Alexey Fisher <fishor@mail.ru>, + Oleksij Rempel <bug-track@fisher-privat.net>, Jean Delvare <khali@linux-fr.org> Description diff --git a/Documentation/hwmon/submitting-patches b/Documentation/hwmon/submitting-patches index 790f774a3032..843751c41fea 100644 --- a/Documentation/hwmon/submitting-patches +++ b/Documentation/hwmon/submitting-patches @@ -60,8 +60,7 @@ increase the chances of your change being accepted. * Add the driver to Kconfig and Makefile in alphabetical order. -* Make sure that all dependencies are listed in Kconfig. For new drivers, it - is most likely prudent to add a dependency on EXPERIMENTAL. +* Make sure that all dependencies are listed in Kconfig. * Avoid forward declarations if you can. Rearrange the code if necessary. diff --git a/Documentation/hwmon/twl4030-madc-hwmon b/Documentation/hwmon/twl4030-madc-hwmon index ef7984317cec..c3a3a5be10ad 100644 --- a/Documentation/hwmon/twl4030-madc-hwmon +++ b/Documentation/hwmon/twl4030-madc-hwmon @@ -41,5 +41,5 @@ Channel Signal The Sysfs nodes will represent the voltage in the units of mV, the temperature channel shows the converted temperature in -degree celcius. The Battery charging current channel represents +degree Celsius. The Battery charging current channel represents battery charging current in mA. diff --git a/Documentation/i2c/busses/i2c-viapro b/Documentation/i2c/busses/i2c-viapro index 2e758b0e9456..b88f91ae580e 100644 --- a/Documentation/i2c/busses/i2c-viapro +++ b/Documentation/i2c/busses/i2c-viapro @@ -20,7 +20,10 @@ Supported adapters: Datasheet: available on http://linux.via.com.tw * VIA Technologies, Inc. VX855/VX875 - Datasheet: Availability unknown + Datasheet: available on http://linux.via.com.tw + + * VIA Technologies, Inc. VX900 + Datasheet: available on http://linux.via.com.tw Authors: Kyösti Mälkki <kmalkki@cc.hut.fi>, @@ -57,6 +60,7 @@ Your lspci -n listing must show one of these : device 1106:8324 (CX700) device 1106:8353 (VX800/VX820) device 1106:8409 (VX855/VX875) + device 1106:8410 (VX900) If none of these show up, you should look in the BIOS for settings like enable ACPI / SMBus or even USB. diff --git a/Documentation/i2c/muxes/i2c-mux-gpio b/Documentation/i2c/muxes/i2c-mux-gpio index bd9b2299b739..d4d91a53fc39 100644 --- a/Documentation/i2c/muxes/i2c-mux-gpio +++ b/Documentation/i2c/muxes/i2c-mux-gpio @@ -63,3 +63,21 @@ static struct platform_device myboard_i2cmux = { .platform_data = &myboard_i2cmux_data, }, }; + +If you don't know the absolute GPIO pin numbers at registration time, +you can instead provide a chip name (.chip_name) and relative GPIO pin +numbers, and the i2c-gpio-mux driver will do the work for you, +including deferred probing if the GPIO chip isn't immediately +available. + +Device Registration +------------------- + +When registering your i2c-gpio-mux device, you should pass the number +of any GPIO pin it uses as the device ID. This guarantees that every +instance has a different ID. + +Alternatively, if you don't need a stable device name, you can simply +pass PLATFORM_DEVID_AUTO as the device ID, and the platform core will +assign a dynamic ID to your device. If you do not know the absolute +GPIO pin numbers at registration time, this is even the only option. diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index 849b771c5e03..2152b0e7237d 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -178,7 +178,6 @@ Code Seq#(hex) Include File Comments 'V' C0 linux/ivtv.h conflict! 'V' C0 media/davinci/vpfe_capture.h conflict! 'V' C0 media/si4713.h conflict! -'V' C0-CF drivers/media/video/mxb.h conflict! 'W' 00-1F linux/watchdog.h conflict! 'W' 00-1F linux/wanrouter.h conflict! 'W' 00-3F sound/asound.h conflict! @@ -204,8 +203,6 @@ Code Seq#(hex) Include File Comments 'c' A0-AF arch/x86/include/asm/msr.h conflict! 'd' 00-FF linux/char/drm/drm/h conflict! 'd' 02-40 pcmcia/ds.h conflict! -'d' 10-3F drivers/media/video/dabusb.h conflict! -'d' C0-CF drivers/media/video/saa7191.h conflict! 'd' F0-FF linux/digi1.h 'e' all linux/digi1.h conflict! 'e' 00-1F drivers/net/irda/irtty-sir.h conflict! @@ -267,9 +264,7 @@ Code Seq#(hex) Include File Comments 'v' 00-1F linux/ext2_fs.h conflict! 'v' 00-1F linux/fs.h conflict! 'v' 00-0F linux/sonypi.h conflict! -'v' C0-DF media/pwc-ioctl.h conflict! 'v' C0-FF linux/meye.h conflict! -'v' D0-DF drivers/media/video/cpia2/cpia2dev.h conflict! 'w' all CERN SCI driver 'y' 00-1F packet based user level communications <mailto:zapman@interlan.net> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index f777fa96243d..9776f068306b 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1593,6 +1593,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted. log everything. Information is printed at KERN_DEBUG so loglevel=8 may also need to be specified. + module.sig_enforce + [KNL] When CONFIG_MODULE_SIG is set, this means that + modules without (valid) signatures will fail to load. + Note that if CONFIG_MODULE_SIG_ENFORCE is set, that + is always true, so this option does nothing. + mousedev.tap_time= [MOUSE] Maximum time between finger touching and leaving touchpad surface for touch to be considered @@ -1730,6 +1736,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. will be autodetected by the client, and it will fall back to using the idmapper. To turn off this behaviour, set the value to '0'. + nfs.nfs4_unique_id= + [NFS4] Specify an additional fixed unique ident- + ification string that NFSv4 clients can insert into + their nfs_client_id4 string. This is typically a + UUID that is generated at system install time. nfs.send_implementation_id = [NFSv4.1] Send client implementation identification diff --git a/Documentation/leds/leds-lp5523.txt b/Documentation/leds/leds-lp5523.txt index fad2feb8b7ce..c2743f59f9ac 100644 --- a/Documentation/leds/leds-lp5523.txt +++ b/Documentation/leds/leds-lp5523.txt @@ -10,8 +10,22 @@ Contact: Samu Onkalo (samu.p.onkalo-at-nokia.com) Description ----------- LP5523 can drive up to 9 channels. Leds can be controlled directly via -the led class control interface. Channels have generic names: -lp5523:channelx where x is 0...8 +the led class control interface. +The name of each channel is configurable in the platform data - name and label. +There are three options to make the channel name. + +a) Define the 'name' in the platform data +To make specific channel name, then use 'name' platform data. +/sys/class/leds/R1 (name: 'R1') +/sys/class/leds/B1 (name: 'B1') + +b) Use the 'label' with no 'name' field +For one device name with channel number, then use 'label'. +/sys/class/leds/RGB:channelN (label: 'RGB', N: 0 ~ 8) + +c) Default +If both fields are NULL, 'lp5523' is used by default. +/sys/class/leds/lp5523:channelN (N: 0 ~ 8) The chip provides 3 engines. Each engine can control channels without interaction from the main CPU. Details of the micro engine code can be found @@ -46,12 +60,13 @@ Note - chan_nr can have values between 0 and 8. static struct lp5523_led_config lp5523_led_config[] = { { + .name = "D1", .chan_nr = 0, .led_current = 50, .max_current = 130, }, ... - }, { + { .chan_nr = 8, .led_current = 50, .max_current = 130, diff --git a/Documentation/memory.txt b/Documentation/memory.txt deleted file mode 100644 index 802efe58647c..000000000000 --- a/Documentation/memory.txt +++ /dev/null @@ -1,33 +0,0 @@ -There are several classic problems related to memory on Linux -systems. - - 1) There are some motherboards that will not cache above - a certain quantity of memory. If you have one of these - motherboards, your system will be SLOWER, not faster - as you add more memory. Consider exchanging your - motherboard. - -All of these problems can be addressed with the "mem=XXXM" boot option -(where XXX is the size of RAM to use in megabytes). -It can also tell Linux to use less memory than is actually installed. -If you use "mem=" on a machine with PCI, consider using "memmap=" to avoid -physical address space collisions. - -See the documentation of your boot loader (LILO, grub, loadlin, etc.) about -how to pass options to the kernel. - -There are other memory problems which Linux cannot deal with. Random -corruption of memory is usually a sign of serious hardware trouble. -Try: - - * Reducing memory settings in the BIOS to the most conservative - timings. - - * Adding a cooling fan. - - * Not overclocking your CPU. - - * Having the memory tested in a memory tester or exchanged - with the vendor. Consider testing it with memtest86 yourself. - - * Exchanging your CPU, cache, or motherboard for one that works. diff --git a/Documentation/percpu-rw-semaphore.txt b/Documentation/percpu-rw-semaphore.txt new file mode 100644 index 000000000000..7d3c82431909 --- /dev/null +++ b/Documentation/percpu-rw-semaphore.txt @@ -0,0 +1,27 @@ +Percpu rw semaphores +-------------------- + +Percpu rw semaphores is a new read-write semaphore design that is +optimized for locking for reading. + +The problem with traditional read-write semaphores is that when multiple +cores take the lock for reading, the cache line containing the semaphore +is bouncing between L1 caches of the cores, causing performance +degradation. + +Locking for reading is very fast, it uses RCU and it avoids any atomic +instruction in the lock and unlock path. On the other hand, locking for +writing is very expensive, it calls synchronize_rcu() that can take +hundreds of milliseconds. + +The lock is declared with "struct percpu_rw_semaphore" type. +The lock is initialized percpu_init_rwsem, it returns 0 on success and +-ENOMEM on allocation failure. +The lock must be freed with percpu_free_rwsem to avoid memory leak. + +The lock is locked for read with percpu_down_read, percpu_up_read and +for write with percpu_down_write, percpu_up_write. + +The idea of using RCU for optimized rw-lock was introduced by +Eric Dumazet <eric.dumazet@gmail.com>. +The code was written by Mikulas Patocka <mpatocka@redhat.com> diff --git a/Documentation/power/power_supply_class.txt b/Documentation/power/power_supply_class.txt index 2f0ddc15b5ac..9c647bd7c5a9 100644 --- a/Documentation/power/power_supply_class.txt +++ b/Documentation/power/power_supply_class.txt @@ -81,6 +81,9 @@ This defines trickle and fast charges. For batteries that are already charged or discharging, 'n/a' can be displayed (or 'unknown', if the status is not known). +AUTHENTIC - indicates the power supply (battery or charger) connected +to the platform is authentic(1) or non authentic(0). + HEALTH - represents health of the battery, values corresponds to POWER_SUPPLY_HEALTH_*, defined in battery.h. @@ -113,8 +116,12 @@ be negative; there is no empty or full value. It is only useful for relative, time-based measurements. CONSTANT_CHARGE_CURRENT - constant charge current programmed by charger. +CONSTANT_CHARGE_CURRENT_MAX - maximum charge current supported by the +power supply object. CONSTANT_CHARGE_VOLTAGE - constant charge voltage programmed by charger. +CONSTANT_CHARGE_VOLTAGE_MAX - maximum charge voltage supported by the +power supply object. ENERGY_FULL, ENERGY_EMPTY - same as above but for energy. diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt index 7561d7ed8e11..8ffb274367c7 100644 --- a/Documentation/printk-formats.txt +++ b/Documentation/printk-formats.txt @@ -69,6 +69,7 @@ MAC/FDDI addresses: %pMR 05:04:03:02:01:00 %pMF 00-01-02-03-04-05 %pm 000102030405 + %pmR 050403020100 For printing 6-byte MAC/FDDI addresses in hex notation. The 'M' and 'm' specifiers result in a printed address with ('M') or without ('m') byte diff --git a/Documentation/prio_tree.txt b/Documentation/prio_tree.txt deleted file mode 100644 index 3aa68f9a117b..000000000000 --- a/Documentation/prio_tree.txt +++ /dev/null @@ -1,107 +0,0 @@ -The prio_tree.c code indexes vmas using 3 different indexes: - * heap_index = vm_pgoff + vm_size_in_pages : end_vm_pgoff - * radix_index = vm_pgoff : start_vm_pgoff - * size_index = vm_size_in_pages - -A regular radix-priority-search-tree indexes vmas using only heap_index and -radix_index. The conditions for indexing are: - * ->heap_index >= ->left->heap_index && - ->heap_index >= ->right->heap_index - * if (->heap_index == ->left->heap_index) - then ->radix_index < ->left->radix_index; - * if (->heap_index == ->right->heap_index) - then ->radix_index < ->right->radix_index; - * nodes are hashed to left or right subtree using radix_index - similar to a pure binary radix tree. - -A regular radix-priority-search-tree helps to store and query -intervals (vmas). However, a regular radix-priority-search-tree is only -suitable for storing vmas with different radix indices (vm_pgoff). - -Therefore, the prio_tree.c extends the regular radix-priority-search-tree -to handle many vmas with the same vm_pgoff. Such vmas are handled in -2 different ways: 1) All vmas with the same radix _and_ heap indices are -linked using vm_set.list, 2) if there are many vmas with the same radix -index, but different heap indices and if the regular radix-priority-search -tree cannot index them all, we build an overflow-sub-tree that indexes such -vmas using heap and size indices instead of heap and radix indices. For -example, in the figure below some vmas with vm_pgoff = 0 (zero) are -indexed by regular radix-priority-search-tree whereas others are pushed -into an overflow-subtree. Note that all vmas in an overflow-sub-tree have -the same vm_pgoff (radix_index) and if necessary we build different -overflow-sub-trees to handle each possible radix_index. For example, -in figure we have 3 overflow-sub-trees corresponding to radix indices -0, 2, and 4. - -In the final tree the first few (prio_tree_root->index_bits) levels -are indexed using heap and radix indices whereas the overflow-sub-trees below -those levels (i.e. levels prio_tree_root->index_bits + 1 and higher) are -indexed using heap and size indices. In overflow-sub-trees the size_index -is used for hashing the nodes to appropriate places. - -Now, an example prio_tree: - - vmas are represented [radix_index, size_index, heap_index] - i.e., [start_vm_pgoff, vm_size_in_pages, end_vm_pgoff] - -level prio_tree_root->index_bits = 3 ------ - _ - 0 [0,7,7] | - / \ | - ------------------ ------------ | Regular - / \ | radix priority - 1 [1,6,7] [4,3,7] | search tree - / \ / \ | - ------- ----- ------ ----- | heap-and-radix - / \ / \ | indexed - 2 [0,6,6] [2,5,7] [5,2,7] [6,1,7] | - / \ / \ / \ / \ | - 3 [0,5,5] [1,5,6] [2,4,6] [3,4,7] [4,2,6] [5,1,6] [6,0,6] [7,0,7] | - / / / _ - / / / _ - 4 [0,4,4] [2,3,5] [4,1,5] | - / / / | - 5 [0,3,3] [2,2,4] [4,0,4] | Overflow-sub-trees - / / | - 6 [0,2,2] [2,1,3] | heap-and-size - / / | indexed - 7 [0,1,1] [2,0,2] | - / | - 8 [0,0,0] | - _ - -Note that we use prio_tree_root->index_bits to optimize the height -of the heap-and-radix indexed tree. Since prio_tree_root->index_bits is -set according to the maximum end_vm_pgoff mapped, we are sure that all -bits (in vm_pgoff) above prio_tree_root->index_bits are 0 (zero). Therefore, -we only use the first prio_tree_root->index_bits as radix_index. -Whenever index_bits is increased in prio_tree_expand, we shuffle the tree -to make sure that the first prio_tree_root->index_bits levels of the tree -is indexed properly using heap and radix indices. - -We do not optimize the height of overflow-sub-trees using index_bits. -The reason is: there can be many such overflow-sub-trees and all of -them have to be suffled whenever the index_bits increases. This may involve -walking the whole prio_tree in prio_tree_insert->prio_tree_expand code -path which is not desirable. Hence, we do not optimize the height of the -heap-and-size indexed overflow-sub-trees using prio_tree->index_bits. -Instead the overflow sub-trees are indexed using full BITS_PER_LONG bits -of size_index. This may lead to skewed sub-trees because most of the -higher significant bits of the size_index are likely to be 0 (zero). In -the example above, all 3 overflow-sub-trees are skewed. This may marginally -affect the performance. However, processes rarely map many vmas with the -same start_vm_pgoff but different end_vm_pgoffs. Therefore, we normally -do not require overflow-sub-trees to index all vmas. - -From the above discussion it is clear that the maximum height of -a prio_tree can be prio_tree_root->index_bits + BITS_PER_LONG. -However, in most of the common cases we do not need overflow-sub-trees, -so the tree height in the common cases will be prio_tree_root->index_bits. - -It is fair to mention here that the prio_tree_root->index_bits -is increased on demand, however, the index_bits is not decreased when -vmas are removed from the prio_tree. That's tricky to do. Hence, it's -left as a home work problem. - - diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt index 554290ebab94..7d2b4c9b544b 100644 --- a/Documentation/pwm.txt +++ b/Documentation/pwm.txt @@ -36,7 +36,8 @@ Legacy users can request a PWM device using pwm_request() and free it after usage with pwm_free(). New users should use the pwm_get() function and pass to it the consumer -device or a consumer name. pwm_put() is used to free the PWM device. +device or a consumer name. pwm_put() is used to free the PWM device. Managed +variants of these functions, devm_pwm_get() and devm_pwm_put(), also exist. After being requested a PWM has to be configured using: diff --git a/Documentation/ramoops.txt b/Documentation/ramoops.txt index 197ad59ab9bf..69b3cac4749d 100644 --- a/Documentation/ramoops.txt +++ b/Documentation/ramoops.txt @@ -102,9 +102,7 @@ related hangs. The functions call chain log is stored in a "ftrace-ramoops" file. Here is an example of usage: # mount -t debugfs debugfs /sys/kernel/debug/ - # cd /sys/kernel/debug/tracing - # echo function > current_tracer - # echo 1 > options/func_pstore + # echo 1 > /sys/kernel/debug/pstore/record_ftrace # reboot -f [...] # mount -t pstore pstore /mnt/ diff --git a/Documentation/rbtree.txt b/Documentation/rbtree.txt index 8d32d85a5234..61b6c48871a0 100644 --- a/Documentation/rbtree.txt +++ b/Documentation/rbtree.txt @@ -193,24 +193,55 @@ Example: Support for Augmented rbtrees ----------------------------- -Augmented rbtree is an rbtree with "some" additional data stored in each node. -This data can be used to augment some new functionality to rbtree. -Augmented rbtree is an optional feature built on top of basic rbtree -infrastructure. An rbtree user who wants this feature will have to call the -augmentation functions with the user provided augmentation callback -when inserting and erasing nodes. - -On insertion, the user must call rb_augment_insert() once the new node is in -place. This will cause the augmentation function callback to be called for -each node between the new node and the root which has been affected by the -insertion. - -When erasing a node, the user must call rb_augment_erase_begin() first to -retrieve the deepest node on the rebalance path. Then, after erasing the -original node, the user must call rb_augment_erase_end() with the deepest -node found earlier. This will cause the augmentation function to be called -for each affected node between the deepest node and the root. - +Augmented rbtree is an rbtree with "some" additional data stored in +each node, where the additional data for node N must be a function of +the contents of all nodes in the subtree rooted at N. This data can +be used to augment some new functionality to rbtree. Augmented rbtree +is an optional feature built on top of basic rbtree infrastructure. +An rbtree user who wants this feature will have to call the augmentation +functions with the user provided augmentation callback when inserting +and erasing nodes. + +C files implementing augmented rbtree manipulation must include +<linux/rbtree_augmented.h> instead of <linus/rbtree.h>. Note that +linux/rbtree_augmented.h exposes some rbtree implementations details +you are not expected to rely on; please stick to the documented APIs +there and do not include <linux/rbtree_augmented.h> from header files +either so as to minimize chances of your users accidentally relying on +such implementation details. + +On insertion, the user must update the augmented information on the path +leading to the inserted node, then call rb_link_node() as usual and +rb_augment_inserted() instead of the usual rb_insert_color() call. +If rb_augment_inserted() rebalances the rbtree, it will callback into +a user provided function to update the augmented information on the +affected subtrees. + +When erasing a node, the user must call rb_erase_augmented() instead of +rb_erase(). rb_erase_augmented() calls back into user provided functions +to updated the augmented information on affected subtrees. + +In both cases, the callbacks are provided through struct rb_augment_callbacks. +3 callbacks must be defined: + +- A propagation callback, which updates the augmented value for a given + node and its ancestors, up to a given stop point (or NULL to update + all the way to the root). + +- A copy callback, which copies the augmented value for a given subtree + to a newly assigned subtree root. + +- A tree rotation callback, which copies the augmented value for a given + subtree to a newly assigned subtree root AND recomputes the augmented + information for the former subtree root. + +The compiled code for rb_erase_augmented() may inline the propagation and +copy callbacks, which results in a large function, so each augmented rbtree +user should have a single rb_erase_augmented() call site in order to limit +compiled code size. + + +Sample usage: Interval tree is an example of augmented rb tree. Reference - "Introduction to Algorithms" by Cormen, Leiserson, Rivest and Stein. @@ -230,26 +261,132 @@ and its immediate children. And this will be used in O(log n) lookup for lowest match (lowest start address among all possible matches) with something like: -find_lowest_match(lo, hi, node) +struct interval_tree_node * +interval_tree_first_match(struct rb_root *root, + unsigned long start, unsigned long last) { - lowest_match = NULL; - while (node) { - if (max_hi(node->left) > lo) { - // Lowest overlap if any must be on left side - node = node->left; - } else if (overlap(lo, hi, node)) { - lowest_match = node; - break; - } else if (lo > node->lo) { - // Lowest overlap if any must be on right side - node = node->right; - } else { - break; + struct interval_tree_node *node; + + if (!root->rb_node) + return NULL; + node = rb_entry(root->rb_node, struct interval_tree_node, rb); + + while (true) { + if (node->rb.rb_left) { + struct interval_tree_node *left = + rb_entry(node->rb.rb_left, + struct interval_tree_node, rb); + if (left->__subtree_last >= start) { + /* + * Some nodes in left subtree satisfy Cond2. + * Iterate to find the leftmost such node N. + * If it also satisfies Cond1, that's the match + * we are looking for. Otherwise, there is no + * matching interval as nodes to the right of N + * can't satisfy Cond1 either. + */ + node = left; + continue; + } } + if (node->start <= last) { /* Cond1 */ + if (node->last >= start) /* Cond2 */ + return node; /* node is leftmost match */ + if (node->rb.rb_right) { + node = rb_entry(node->rb.rb_right, + struct interval_tree_node, rb); + if (node->__subtree_last >= start) + continue; + } + } + return NULL; /* No match */ + } +} + +Insertion/removal are defined using the following augmented callbacks: + +static inline unsigned long +compute_subtree_last(struct interval_tree_node *node) +{ + unsigned long max = node->last, subtree_last; + if (node->rb.rb_left) { + subtree_last = rb_entry(node->rb.rb_left, + struct interval_tree_node, rb)->__subtree_last; + if (max < subtree_last) + max = subtree_last; + } + if (node->rb.rb_right) { + subtree_last = rb_entry(node->rb.rb_right, + struct interval_tree_node, rb)->__subtree_last; + if (max < subtree_last) + max = subtree_last; + } + return max; +} + +static void augment_propagate(struct rb_node *rb, struct rb_node *stop) +{ + while (rb != stop) { + struct interval_tree_node *node = + rb_entry(rb, struct interval_tree_node, rb); + unsigned long subtree_last = compute_subtree_last(node); + if (node->__subtree_last == subtree_last) + break; + node->__subtree_last = subtree_last; + rb = rb_parent(&node->rb); } - return lowest_match; } -Finding exact match will be to first find lowest match and then to follow -successor nodes looking for exact match, until the start of a node is beyond -the hi value we are looking for. +static void augment_copy(struct rb_node *rb_old, struct rb_node *rb_new) +{ + struct interval_tree_node *old = + rb_entry(rb_old, struct interval_tree_node, rb); + struct interval_tree_node *new = + rb_entry(rb_new, struct interval_tree_node, rb); + + new->__subtree_last = old->__subtree_last; +} + +static void augment_rotate(struct rb_node *rb_old, struct rb_node *rb_new) +{ + struct interval_tree_node *old = + rb_entry(rb_old, struct interval_tree_node, rb); + struct interval_tree_node *new = + rb_entry(rb_new, struct interval_tree_node, rb); + + new->__subtree_last = old->__subtree_last; + old->__subtree_last = compute_subtree_last(old); +} + +static const struct rb_augment_callbacks augment_callbacks = { + augment_propagate, augment_copy, augment_rotate +}; + +void interval_tree_insert(struct interval_tree_node *node, + struct rb_root *root) +{ + struct rb_node **link = &root->rb_node, *rb_parent = NULL; + unsigned long start = node->start, last = node->last; + struct interval_tree_node *parent; + + while (*link) { + rb_parent = *link; + parent = rb_entry(rb_parent, struct interval_tree_node, rb); + if (parent->__subtree_last < last) + parent->__subtree_last = last; + if (start < parent->start) + link = &parent->rb.rb_left; + else + link = &parent->rb.rb_right; + } + + node->__subtree_last = last; + rb_link_node(&node->rb, rb_parent, link); + rb_insert_augmented(&node->rb, root, &augment_callbacks); +} + +void interval_tree_remove(struct interval_tree_node *node, + struct rb_root *root) +{ + rb_erase_augmented(&node->rb, root, &augment_callbacks); +} diff --git a/Documentation/rtc.txt b/Documentation/rtc.txt index 250160469d83..32aa4002de4a 100644 --- a/Documentation/rtc.txt +++ b/Documentation/rtc.txt @@ -119,8 +119,9 @@ three different userspace interfaces: * /sys/class/rtc/rtcN ... sysfs attributes support readonly access to some RTC attributes. - * /proc/driver/rtc ... the first RTC (rtc0) may expose itself - using a procfs interface. More information is (currently) shown + * /proc/driver/rtc ... the system clock RTC may expose itself + using a procfs interface. If there is no RTC for the system clock, + rtc0 is used by default. More information is (currently) shown here than through sysfs. The RTC Class framework supports a wide variety of RTCs, ranging from those diff --git a/Documentation/scsi/ChangeLog.megaraid_sas b/Documentation/scsi/ChangeLog.megaraid_sas index 3a3079411a3d..da03146c182a 100644 --- a/Documentation/scsi/ChangeLog.megaraid_sas +++ b/Documentation/scsi/ChangeLog.megaraid_sas @@ -1,3 +1,16 @@ +Release Date : Mon. Oct 1, 2012 17:00:00 PST 2012 - + (emaild-id:megaraidlinux@lsi.com) + Adam Radford +Current Version : 06.504.01.00-rc1 +Old Version : 00.00.06.18-rc1 + 1. Removed un-needed completion_lock spinlock calls. + 2. Add module param for configurable MSI-X vector count. + 3. Load io_request DataLength in bytes. + 4. Add array boundary check for SystemPD. + 5. Add SystemPD FastPath support. + 6. Remove duplicate code. + 7. Version, Changelog, Copyright update. +------------------------------------------------------------------------------- Release Date : Tue. Jun 17, 2012 17:00:00 PST 2012 - (emaild-id:megaraidlinux@lsi.com) Adam Radford/Kashyap Desai diff --git a/Documentation/security/keys.txt b/Documentation/security/keys.txt index aa0dbd74b71b..7d9ca92022d8 100644 --- a/Documentation/security/keys.txt +++ b/Documentation/security/keys.txt @@ -412,6 +412,10 @@ The main syscalls are: to the keyring. In this case, an error will be generated if the process does not have permission to write to the keyring. + If the key type supports it, if the description is NULL or an empty + string, the key type will try and generate a description from the content + of the payload. + The payload is optional, and the pointer can be NULL if not required by the type. The payload is plen in size, and plen can be zero for an empty payload. @@ -1114,12 +1118,53 @@ The structure has a number of fields, some of which are mandatory: it should return 0. - (*) int (*instantiate)(struct key *key, const void *data, size_t datalen); + (*) int (*preparse)(struct key_preparsed_payload *prep); + + This optional method permits the key type to attempt to parse payload + before a key is created (add key) or the key semaphore is taken (update or + instantiate key). The structure pointed to by prep looks like: + + struct key_preparsed_payload { + char *description; + void *type_data[2]; + void *payload; + const void *data; + size_t datalen; + size_t quotalen; + }; + + Before calling the method, the caller will fill in data and datalen with + the payload blob parameters; quotalen will be filled in with the default + quota size from the key type and the rest will be cleared. + + If a description can be proposed from the payload contents, that should be + attached as a string to the description field. This will be used for the + key description if the caller of add_key() passes NULL or "". + + The method can attach anything it likes to type_data[] and payload. These + are merely passed along to the instantiate() or update() operations. + + The method should return 0 if success ful or a negative error code + otherwise. + + + (*) void (*free_preparse)(struct key_preparsed_payload *prep); + + This method is only required if the preparse() method is provided, + otherwise it is unused. It cleans up anything attached to the + description, type_data and payload fields of the key_preparsed_payload + struct as filled in by the preparse() method. + + + (*) int (*instantiate)(struct key *key, struct key_preparsed_payload *prep); This method is called to attach a payload to a key during construction. The payload attached need not bear any relation to the data passed to this function. + The prep->data and prep->datalen fields will define the original payload + blob. If preparse() was supplied then other fields may be filled in also. + If the amount of data attached to the key differs from the size in keytype->def_datalen, then key_payload_reserve() should be called. @@ -1135,6 +1180,9 @@ The structure has a number of fields, some of which are mandatory: If this type of key can be updated, then this method should be provided. It is called to update a key's payload from the blob of data provided. + The prep->data and prep->datalen fields will define the original payload + blob. If preparse() was supplied then other fields may be filled in also. + key_payload_reserve() should be called if the data length might change before any changes are actually made. Note that if this succeeds, the type is committed to changing the key because it's already been altered, so all diff --git a/Documentation/smsc_ece1099.txt b/Documentation/smsc_ece1099.txt new file mode 100644 index 000000000000..6b492e82b43d --- /dev/null +++ b/Documentation/smsc_ece1099.txt @@ -0,0 +1,56 @@ +What is smsc-ece1099? +---------------------- + +The ECE1099 is a 40-Pin 3.3V Keyboard Scan Expansion +or GPIO Expansion device. The device supports a keyboard +scan matrix of 23x8. The device is connected to a Master +via the SMSC BC-Link interface or via the SMBus. +Keypad scan Input(KSI) and Keypad Scan Output(KSO) signals +are multiplexed with GPIOs. + +Interrupt generation +-------------------- + +Interrupts can be generated by an edge detection on a GPIO +pin or an edge detection on one of the bus interface pins. +Interrupts can also be detected on the keyboard scan interface. +The bus interrupt pin (BC_INT# or SMBUS_INT#) is asserted if +any bit in one of the Interrupt Status registers is 1 and +the corresponding Interrupt Mask bit is also 1. + +In order for software to determine which device is the source +of an interrupt, it should first read the Group Interrupt Status Register +to determine which Status register group is a source for the interrupt. +Software should read both the Status register and the associated Mask register, +then AND the two values together. Bits that are 1 in the result of the AND +are active interrupts. Software clears an interrupt by writing a 1 to the +corresponding bit in the Status register. + +Communication Protocol +---------------------- + +- SMbus slave Interface + The host processor communicates with the ECE1099 device + through a series of read/write registers via the SMBus + interface. SMBus is a serial communication protocol between + a computer host and its peripheral devices. The SMBus data + rate is 10KHz minimum to 400 KHz maximum + +- Slave Bus Interface + The ECE1099 device SMBus implementation is a subset of the + SMBus interface to the host. The device is a slave-only SMBus device. + The implementation in the device is a subset of SMBus since it + only supports four protocols. + + The Write Byte, Read Byte, Send Byte, and Receive Byte protocols are the + only valid SMBus protocols for the device. + +- BC-LinkTM Interface + The BC-Link is a proprietary bus that allows communication + between a Master device and a Companion device. The Master + device uses this serial bus to read and write registers + located on the Companion device. The bus comprises three signals, + BC_CLK, BC_DAT and BC_INT#. The Master device always provides the + clock, BC_CLK, and the Companion device is the source for an + independent asynchronous interrupt signal, BC_INT#. The ECE1099 + supports BC-Link speeds up to 24MHz. diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt index 4e4d0bc9816f..d90d8ec2853d 100644 --- a/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/Documentation/sound/alsa/ALSA-Configuration.txt @@ -860,8 +860,14 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. [Multiple options for each card instance] model - force the model name - position_fix - Fix DMA pointer (0 = auto, 1 = use LPIB, 2 = POSBUF, - 3 = VIACOMBO, 4 = COMBO) + position_fix - Fix DMA pointer + -1 = system default: choose appropriate one per controller + hardware + 0 = auto: falls back to LPIB when POSBUF doesn't work + 1 = use LPIB + 2 = POSBUF: use position buffer + 3 = VIACOMBO: VIA-specific workaround for capture + 4 = COMBO: use LPIB for playback, auto for capture stream probe_mask - Bitmask to probe codecs (default = -1, meaning all slots) When the bit 8 (0x100) is set, the lower 8 bits are used as the "fixed" codec slots; i.e. the driver probes the diff --git a/Documentation/sound/alsa/Channel-Mapping-API.txt b/Documentation/sound/alsa/Channel-Mapping-API.txt new file mode 100644 index 000000000000..3c43d1a4ca0e --- /dev/null +++ b/Documentation/sound/alsa/Channel-Mapping-API.txt @@ -0,0 +1,153 @@ +ALSA PCM channel-mapping API +============================ + Takashi Iwai <tiwai@suse.de> + +GENERAL +------- + +The channel mapping API allows user to query the possible channel maps +and the current channel map, also optionally to modify the channel map +of the current stream. + +A channel map is an array of position for each PCM channel. +Typically, a stereo PCM stream has a channel map of + { front_left, front_right } +while a 4.0 surround PCM stream has a channel map of + { front left, front right, rear left, rear right }. + +The problem, so far, was that we had no standard channel map +explicitly, and applications had no way to know which channel +corresponds to which (speaker) position. Thus, applications applied +wrong channels for 5.1 outputs, and you hear suddenly strange sound +from rear. Or, some devices secretly assume that center/LFE is the +third/fourth channels while others that C/LFE as 5th/6th channels. + +Also, some devices such as HDMI are configurable for different speaker +positions even with the same number of total channels. However, there +was no way to specify this because of lack of channel map +specification. These are the main motivations for the new channel +mapping API. + + +DESIGN +------ + +Actually, "the channel mapping API" doesn't introduce anything new in +the kernel/user-space ABI perspective. It uses only the existing +control element features. + +As a ground design, each PCM substream may contain a control element +providing the channel mapping information and configuration. This +element is specified by: + iface = SNDRV_CTL_ELEM_IFACE_PCM + name = "Playback Channel Map" or "Capture Channel Map" + device = the same device number for the assigned PCM substream + index = the same index number for the assigned PCM substream + +Note the name is different depending on the PCM substream direction. + +Each control element provides at least the TLV read operation and the +read operation. Optionally, the write operation can be provided to +allow user to change the channel map dynamically. + +* TLV + +The TLV operation gives the list of available channel +maps. A list item of a channel map is usually a TLV of + type data-bytes ch0 ch1 ch2... +where type is the TLV type value, the second argument is the total +bytes (not the numbers) of channel values, and the rest are the +position value for each channel. + +As a TLV type, either SNDRV_CTL_TLVT_CHMAP_FIXED, +SNDRV_CTL_TLV_CHMAP_VAR or SNDRV_CTL_TLVT_CHMAP_PAIRED can be used. +The _FIXED type is for a channel map with the fixed channel position +while the latter two are for flexible channel positions. _VAR type is +for a channel map where all channels are freely swappable and _PAIRED +type is where pair-wise channels are swappable. For example, when you +have {FL/FR/RL/RR} channel map, _PAIRED type would allow you to swap +only {RL/RR/FL/FR} while _VAR type would allow even swapping FL and +RR. + +These new TLV types are defined in sound/tlv.h. + +The available channel position values are defined in sound/asound.h, +here is a cut: + +/* channel positions */ +enum { + SNDRV_CHMAP_UNKNOWN = 0, + SNDRV_CHMAP_NA, /* N/A, silent */ + SNDRV_CHMAP_MONO, /* mono stream */ + /* this follows the alsa-lib mixer channel value + 3 */ + SNDRV_CHMAP_FL, /* front left */ + SNDRV_CHMAP_FR, /* front right */ + SNDRV_CHMAP_RL, /* rear left */ + SNDRV_CHMAP_RR, /* rear right */ + SNDRV_CHMAP_FC, /* front center */ + SNDRV_CHMAP_LFE, /* LFE */ + SNDRV_CHMAP_SL, /* side left */ + SNDRV_CHMAP_SR, /* side right */ + SNDRV_CHMAP_RC, /* rear center */ + /* new definitions */ + SNDRV_CHMAP_FLC, /* front left center */ + SNDRV_CHMAP_FRC, /* front right center */ + SNDRV_CHMAP_RLC, /* rear left center */ + SNDRV_CHMAP_RRC, /* rear right center */ + SNDRV_CHMAP_FLW, /* front left wide */ + SNDRV_CHMAP_FRW, /* front right wide */ + SNDRV_CHMAP_FLH, /* front left high */ + SNDRV_CHMAP_FCH, /* front center high */ + SNDRV_CHMAP_FRH, /* front right high */ + SNDRV_CHMAP_TC, /* top center */ + SNDRV_CHMAP_TFL, /* top front left */ + SNDRV_CHMAP_TFR, /* top front right */ + SNDRV_CHMAP_TFC, /* top front center */ + SNDRV_CHMAP_TRL, /* top rear left */ + SNDRV_CHMAP_TRR, /* top rear right */ + SNDRV_CHMAP_TRC, /* top rear center */ + SNDRV_CHMAP_LAST = SNDRV_CHMAP_TRC, +}; + +When a PCM stream can provide more than one channel map, you can +provide multiple channel maps in a TLV container type. The TLV data +to be returned will contain such as: + SNDRV_CTL_TLVT_CONTAINER 96 + SNDRV_CTL_TLVT_CHMAP_FIXED 4 SNDRV_CHMAP_FC + SNDRV_CTL_TLVT_CHMAP_FIXED 8 SNDRV_CHMAP_FL SNDRV_CHMAP_FR + SNDRV_CTL_TLVT_CHMAP_FIXED 16 NDRV_CHMAP_FL SNDRV_CHMAP_FR \ + SNDRV_CHMAP_RL SNDRV_CHMAP_RR + +The channel position is provided in LSB 16bits. The upper bits are +used for bit flags. + +#define SNDRV_CHMAP_POSITION_MASK 0xffff +#define SNDRV_CHMAP_PHASE_INVERSE (0x01 << 16) +#define SNDRV_CHMAP_DRIVER_SPEC (0x02 << 16) + +SNDRV_CHMAP_PHASE_INVERSE indicates the channel is phase inverted, +(thus summing left and right channels would result in almost silence). +Some digital mic devices have this. + +When SNDRV_CHMAP_DRIVER_SPEC is set, all the channel position values +don't follow the standard definition above but driver-specific. + +* READ OPERATION + +The control read operation is for providing the current channel map of +the given stream. The control element returns an integer array +containing the position of each channel. + +When this is performed before the number of the channel is specified +(i.e. hw_params is set), it should return all channels set to +UNKNOWN. + +* WRITE OPERATION + +The control write operation is optional, and only for devices that can +change the channel configuration on the fly, such as HDMI. User needs +to pass an integer value containing the valid channel positions for +all channels of the assigned PCM substream. + +This operation is allowed only at PCM PREPARED state. When called in +other states, it shall return an error. diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index a92bba816843..16dfe57f1731 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -74,7 +74,8 @@ CMI9880 AD1882 / AD1882A ================ - 3stack 3-stack mode (default) + 3stack 3-stack mode + 3stack-automute 3-stack with automute front HP (default) 6stack 6-stack mode AD1884A / AD1883 / AD1984A / AD1984B diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index 6d78841fd416..2907ba6c3607 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt @@ -181,6 +181,8 @@ core_pattern is used to specify a core dumpfile pattern name. %p pid %u uid %g gid + %d dump mode, matches PR_SET_DUMPABLE and + /proc/sys/fs/suid_dumpable %s signal number %t UNIX time of dump %h hostname diff --git a/Documentation/sysrq.txt b/Documentation/sysrq.txt index 642f84495b29..2a4cdda4828e 100644 --- a/Documentation/sysrq.txt +++ b/Documentation/sysrq.txt @@ -116,6 +116,7 @@ On all - write a character to /proc/sysrq-trigger. e.g.: 'w' - Dumps tasks that are in uninterruptable (blocked) state. 'x' - Used by xmon interface on ppc/powerpc platforms. + Show global PMU Registers on sparc64. 'y' - Show global CPU Registers [SPARC-64 specific] diff --git a/Documentation/target/tcm_mod_builder.py b/Documentation/target/tcm_mod_builder.py index a78879b01f09..3fe0d812dcec 100755 --- a/Documentation/target/tcm_mod_builder.py +++ b/Documentation/target/tcm_mod_builder.py @@ -402,8 +402,6 @@ def tcm_mod_build_configfs(proto_ident, fabric_mod_dir_var, fabric_mod_name): buf += " .queue_data_in = " + fabric_mod_name + "_queue_data_in,\n" buf += " .queue_status = " + fabric_mod_name + "_queue_status,\n" buf += " .queue_tm_rsp = " + fabric_mod_name + "_queue_tm_rsp,\n" - buf += " .get_fabric_sense_len = " + fabric_mod_name + "_get_fabric_sense_len,\n" - buf += " .set_fabric_sense_len = " + fabric_mod_name + "_set_fabric_sense_len,\n" buf += " .is_state_remove = " + fabric_mod_name + "_is_state_remove,\n" buf += " /*\n" buf += " * Setup function pointers for generic logic in target_core_fabric_configfs.c\n" @@ -906,20 +904,6 @@ def tcm_mod_dump_fabric_ops(proto_ident, fabric_mod_dir_var, fabric_mod_name): buf += "}\n\n" bufi += "int " + fabric_mod_name + "_queue_tm_rsp(struct se_cmd *);\n" - if re.search('get_fabric_sense_len\)\(', fo): - buf += "u16 " + fabric_mod_name + "_get_fabric_sense_len(void)\n" - buf += "{\n" - buf += " return 0;\n" - buf += "}\n\n" - bufi += "u16 " + fabric_mod_name + "_get_fabric_sense_len(void);\n" - - if re.search('set_fabric_sense_len\)\(', fo): - buf += "u16 " + fabric_mod_name + "_set_fabric_sense_len(struct se_cmd *se_cmd, u32 sense_length)\n" - buf += "{\n" - buf += " return 0;\n" - buf += "}\n\n" - bufi += "u16 " + fabric_mod_name + "_set_fabric_sense_len(struct se_cmd *, u32);\n" - if re.search('is_state_remove\)\(', fo): buf += "int " + fabric_mod_name + "_is_state_remove(struct se_cmd *se_cmd)\n" buf += "{\n" diff --git a/Documentation/thermal/cpu-cooling-api.txt b/Documentation/thermal/cpu-cooling-api.txt new file mode 100644 index 000000000000..fca24c931ec8 --- /dev/null +++ b/Documentation/thermal/cpu-cooling-api.txt @@ -0,0 +1,32 @@ +CPU cooling APIs How To +=================================== + +Written by Amit Daniel Kachhap <amit.kachhap@linaro.org> + +Updated: 12 May 2012 + +Copyright (c) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com) + +0. Introduction + +The generic cpu cooling(freq clipping) provides registration/unregistration APIs +to the caller. The binding of the cooling devices to the trip point is left for +the user. The registration APIs returns the cooling device pointer. + +1. cpu cooling APIs + +1.1 cpufreq registration/unregistration APIs +1.1.1 struct thermal_cooling_device *cpufreq_cooling_register( + struct cpumask *clip_cpus) + + This interface function registers the cpufreq cooling device with the name + "thermal-cpufreq-%x". This api can support multiple instances of cpufreq + cooling devices. + + clip_cpus: cpumask of cpus where the frequency constraints will happen. + +1.1.2 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) + + This interface function unregisters the "thermal-cpufreq-%x" cooling device. + + cdev: Cooling device pointer which has to be unregistered. diff --git a/Documentation/hwmon/exynos4_tmu b/Documentation/thermal/exynos_thermal index c3c6b41db607..2b46f67b1ccb 100644 --- a/Documentation/hwmon/exynos4_tmu +++ b/Documentation/thermal/exynos_thermal @@ -46,36 +46,7 @@ The threshold levels are defined as follows: The threshold and each trigger_level are set through the corresponding registers. -When an interrupt occurs, this driver notify user space of -one of four threshold levels for the interrupt -through kobject_uevent_env and sysfs_notify functions. +When an interrupt occurs, this driver notify kernel thermal framework +with the function exynos4_report_trigger. Although an interrupt condition for level_0 can be set, -it is not notified to user space through sysfs_notify function. - -Sysfs Interface ---------------- -name name of the temperature sensor - RO - -temp1_input temperature - RO - -temp1_max temperature for level_1 interrupt - RO - -temp1_crit temperature for level_2 interrupt - RO - -temp1_emergency temperature for level_3 interrupt - RO - -temp1_max_alarm alarm for level_1 interrupt - RO - -temp1_crit_alarm - alarm for level_2 interrupt - RO - -temp1_emergency_alarm - alarm for level_3 interrupt - RO +it can be used to synchronize the cooling action. diff --git a/Documentation/thermal/sysfs-api.txt b/Documentation/thermal/sysfs-api.txt index c087dbcf3535..ca1a1a34970e 100644 --- a/Documentation/thermal/sysfs-api.txt +++ b/Documentation/thermal/sysfs-api.txt @@ -84,7 +84,8 @@ temperature) and throttle appropriate devices. 1.3 interface for binding a thermal zone device with a thermal cooling device 1.3.1 int thermal_zone_bind_cooling_device(struct thermal_zone_device *tz, - int trip, struct thermal_cooling_device *cdev); + int trip, struct thermal_cooling_device *cdev, + unsigned long upper, unsigned long lower); This interface function bind a thermal cooling device to the certain trip point of a thermal zone device. @@ -93,6 +94,12 @@ temperature) and throttle appropriate devices. cdev: thermal cooling device trip: indicates which trip point the cooling devices is associated with in this thermal zone. + upper:the Maximum cooling state for this trip point. + THERMAL_NO_LIMIT means no upper limit, + and the cooling device can be in max_state. + lower:the Minimum cooling state can be used for this trip point. + THERMAL_NO_LIMIT means no lower limit, + and the cooling device can be in cooling state 0. 1.3.2 int thermal_zone_unbind_cooling_device(struct thermal_zone_device *tz, int trip, struct thermal_cooling_device *cdev); diff --git a/Documentation/video4linux/CARDLIST.cx23885 b/Documentation/video4linux/CARDLIST.cx23885 index 652aecd13199..1299b5e82d7f 100644 --- a/Documentation/video4linux/CARDLIST.cx23885 +++ b/Documentation/video4linux/CARDLIST.cx23885 @@ -35,3 +35,4 @@ 34 -> TerraTec Cinergy T PCIe Dual [153b:117e] 35 -> TeVii S471 [d471:9022] 36 -> Hauppauge WinTV-HVR1255 [0070:2259] + 37 -> Prof Revolution DVB-S2 8000 [8000:3034] diff --git a/Documentation/video4linux/CQcam.txt b/Documentation/video4linux/CQcam.txt index 6e680fec1e9c..0b69e4ee8e31 100644 --- a/Documentation/video4linux/CQcam.txt +++ b/Documentation/video4linux/CQcam.txt @@ -18,7 +18,7 @@ Table of Contents 1.0 Introduction - The file ../../drivers/media/video/c-qcam.c is a device driver for + The file ../../drivers/media/parport/c-qcam.c is a device driver for the Logitech (nee Connectix) parallel port interface color CCD camera. This is a fairly inexpensive device for capturing images. Logitech does not currently provide information for developers, but many people diff --git a/Documentation/video4linux/README.davinci-vpbe b/Documentation/video4linux/README.davinci-vpbe index 7a460b0685bb..dc9a297f49c3 100644 --- a/Documentation/video4linux/README.davinci-vpbe +++ b/Documentation/video4linux/README.davinci-vpbe @@ -5,22 +5,22 @@ File partitioning ----------------- V4L2 display device driver - drivers/media/video/davinci/vpbe_display.c - drivers/media/video/davinci/vpbe_display.h + drivers/media/platform/davinci/vpbe_display.c + drivers/media/platform/davinci/vpbe_display.h VPBE display controller - drivers/media/video/davinci/vpbe.c - drivers/media/video/davinci/vpbe.h + drivers/media/platform/davinci/vpbe.c + drivers/media/platform/davinci/vpbe.h VPBE venc sub device driver - drivers/media/video/davinci/vpbe_venc.c - drivers/media/video/davinci/vpbe_venc.h - drivers/media/video/davinci/vpbe_venc_regs.h + drivers/media/platform/davinci/vpbe_venc.c + drivers/media/platform/davinci/vpbe_venc.h + drivers/media/platform/davinci/vpbe_venc_regs.h VPBE osd driver - drivers/media/video/davinci/vpbe_osd.c - drivers/media/video/davinci/vpbe_osd.h - drivers/media/video/davinci/vpbe_osd_regs.h + drivers/media/platform/davinci/vpbe_osd.c + drivers/media/platform/davinci/vpbe_osd.h + drivers/media/platform/davinci/vpbe_osd_regs.h Functional partitioning ----------------------- diff --git a/Documentation/video4linux/fimc.txt b/Documentation/video4linux/fimc.txt index eb049708f3e4..fd02d9a4930a 100644 --- a/Documentation/video4linux/fimc.txt +++ b/Documentation/video4linux/fimc.txt @@ -10,7 +10,7 @@ data from LCD controller (FIMD) through the SoC internal writeback data path. There are multiple FIMC instances in the SoCs (up to 4), having slightly different capabilities, like pixel alignment constraints, rotator availability, LCD writeback support, etc. The driver is located at -drivers/media/video/s5p-fimc directory. +drivers/media/platform/s5p-fimc directory. 1. Supported SoCs ================= @@ -36,21 +36,21 @@ Not currently supported: ===================== - media device driver - drivers/media/video/s5p-fimc/fimc-mdevice.[ch] + drivers/media/platform/s5p-fimc/fimc-mdevice.[ch] - camera capture video device driver - drivers/media/video/s5p-fimc/fimc-capture.c + drivers/media/platform/s5p-fimc/fimc-capture.c - MIPI-CSI2 receiver subdev - drivers/media/video/s5p-fimc/mipi-csis.[ch] + drivers/media/platform/s5p-fimc/mipi-csis.[ch] - video post-processor (mem-to-mem) - drivers/media/video/s5p-fimc/fimc-core.c + drivers/media/platform/s5p-fimc/fimc-core.c - common files - drivers/media/video/s5p-fimc/fimc-core.h - drivers/media/video/s5p-fimc/fimc-reg.h - drivers/media/video/s5p-fimc/regs-fimc.h + drivers/media/platform/s5p-fimc/fimc-core.h + drivers/media/platform/s5p-fimc/fimc-reg.h + drivers/media/platform/s5p-fimc/regs-fimc.h 4. User space interfaces ======================== diff --git a/Documentation/video4linux/omap3isp.txt b/Documentation/video4linux/omap3isp.txt index 5dd1439b61fd..b9a9f83b1587 100644 --- a/Documentation/video4linux/omap3isp.txt +++ b/Documentation/video4linux/omap3isp.txt @@ -12,7 +12,7 @@ Introduction ============ This file documents the Texas Instruments OMAP 3 Image Signal Processor (ISP) -driver located under drivers/media/video/omap3isp. The original driver was +driver located under drivers/media/platform/omap3isp. The original driver was written by Texas Instruments but since that it has been rewritten (twice) at Nokia. diff --git a/Documentation/video4linux/v4l2-controls.txt b/Documentation/video4linux/v4l2-controls.txt index 43da22b89728..cfe52c798d74 100644 --- a/Documentation/video4linux/v4l2-controls.txt +++ b/Documentation/video4linux/v4l2-controls.txt @@ -136,11 +136,25 @@ Or alternatively for integer menu controls, by calling v4l2_ctrl_new_int_menu: const struct v4l2_ctrl_ops *ops, u32 id, s32 max, s32 def, const s64 *qmenu_int); +Standard menu controls with a driver specific menu are added by calling +v4l2_ctrl_new_std_menu_items: + + struct v4l2_ctrl *v4l2_ctrl_new_std_menu_items( + struct v4l2_ctrl_handler *hdl, + const struct v4l2_ctrl_ops *ops, u32 id, s32 max, + s32 skip_mask, s32 def, const char * const *qmenu); + These functions are typically called right after the v4l2_ctrl_handler_init: static const s64 exp_bias_qmenu[] = { -2, -1, 0, 1, 2 }; + static const char * const test_pattern[] = { + "Disabled", + "Vertical Bars", + "Solid Black", + "Solid White", + }; v4l2_ctrl_handler_init(&foo->ctrl_handler, nr_of_controls); v4l2_ctrl_new_std(&foo->ctrl_handler, &foo_ctrl_ops, @@ -156,6 +170,9 @@ These functions are typically called right after the v4l2_ctrl_handler_init: ARRAY_SIZE(exp_bias_qmenu) - 1, ARRAY_SIZE(exp_bias_qmenu) / 2 - 1, exp_bias_qmenu); + v4l2_ctrl_new_std_menu_items(&foo->ctrl_handler, &foo_ctrl_ops, + V4L2_CID_TEST_PATTERN, ARRAY_SIZE(test_pattern) - 1, 0, + 0, test_pattern); ... if (foo->ctrl_handler.error) { int err = foo->ctrl_handler.error; @@ -185,6 +202,13 @@ v4l2_ctrl_new_std_menu in that it doesn't have the mask argument and takes as the last argument an array of signed 64-bit integers that form an exact menu item list. +The v4l2_ctrl_new_std_menu_items function is very similar to +v4l2_ctrl_new_std_menu but takes an extra parameter qmenu, which is the driver +specific menu for an otherwise standard menu control. A good example for this +control is the test pattern control for capture/display/sensors devices that +have the capability to generate test patterns. These test patterns are hardware +specific, so the contents of the menu will vary from device to device. + Note that if something fails, the function will return NULL or an error and set ctrl_handler->error to the error code. If ctrl_handler->error was already set, then it will just return and do nothing. This is also true for @@ -594,7 +618,11 @@ handler and finally add the first handler to the second. For example: v4l2_ctrl_new_std(&radio_ctrl_handler, &radio_ops, V4L2_CID_AUDIO_MUTE, ...); v4l2_ctrl_new_std(&video_ctrl_handler, &video_ops, V4L2_CID_BRIGHTNESS, ...); v4l2_ctrl_new_std(&video_ctrl_handler, &video_ops, V4L2_CID_CONTRAST, ...); - v4l2_ctrl_add_handler(&video_ctrl_handler, &radio_ctrl_handler); + v4l2_ctrl_add_handler(&video_ctrl_handler, &radio_ctrl_handler, NULL); + +The last argument to v4l2_ctrl_add_handler() is a filter function that allows +you to filter which controls will be added. Set it to NULL if you want to add +all controls. Or you can add specific controls to a handler: diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index 89318be6c1d2..32bfe926e8d7 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -583,11 +583,19 @@ You should also set these fields: - name: set to something descriptive and unique. +- vfl_dir: set this to VFL_DIR_RX for capture devices (VFL_DIR_RX has value 0, + so this is normally already the default), set to VFL_DIR_TX for output + devices and VFL_DIR_M2M for mem2mem (codec) devices. + - fops: set to the v4l2_file_operations struct. - ioctl_ops: if you use the v4l2_ioctl_ops to simplify ioctl maintenance (highly recommended to use this and it might become compulsory in the - future!), then set this to your v4l2_ioctl_ops struct. + future!), then set this to your v4l2_ioctl_ops struct. The vfl_type and + vfl_dir fields are used to disable ops that do not match the type/dir + combination. E.g. VBI ops are disabled for non-VBI nodes, and output ops + are disabled for a capture device. This makes it possible to provide + just one v4l2_ioctl_ops struct for both vbi and video nodes. - lock: leave to NULL if you want to do all the locking in the driver. Otherwise you give it a pointer to a struct mutex_lock and before the @@ -1054,4 +1062,4 @@ The first event type in the class is reserved for future use, so the first available event type is 'class base + 1'. An example on how the V4L2 events may be used can be found in the OMAP -3 ISP driver (drivers/media/video/omap3isp). +3 ISP driver (drivers/media/platform/omap3isp). diff --git a/Documentation/video4linux/videobuf b/Documentation/video4linux/videobuf index 1d00d7f15b8f..3ffe9e960b6f 100644 --- a/Documentation/video4linux/videobuf +++ b/Documentation/video4linux/videobuf @@ -349,7 +349,7 @@ again. Developers who are interested in more information can go into the relevant header files; there are a few low-level functions declared there which have not been talked about here. Also worthwhile is the vivi driver -(drivers/media/video/vivi.c), which is maintained as an example of how V4L2 +(drivers/media/platform/vivi.c), which is maintained as an example of how V4L2 drivers should be written. Vivi only uses the vmalloc() API, but it's good enough to get started with. Note also that all of these calls are exported GPL-only, so they will not be available to non-GPL kernel modules. diff --git a/Documentation/virtual/uml/UserModeLinux-HOWTO.txt b/Documentation/virtual/uml/UserModeLinux-HOWTO.txt index 77dfecf4e2d6..a5f8436753e7 100644 --- a/Documentation/virtual/uml/UserModeLinux-HOWTO.txt +++ b/Documentation/virtual/uml/UserModeLinux-HOWTO.txt @@ -3591,7 +3591,7 @@ Looking at the source shows that the fault happened during a call to - copy_to_user to copy the data into the kernel: + copy_from_user to copy the data into the kernel: 107 count -= chars; diff --git a/Documentation/vm/unevictable-lru.txt b/Documentation/vm/unevictable-lru.txt index fa206cccf89f..a68db7692ee8 100644 --- a/Documentation/vm/unevictable-lru.txt +++ b/Documentation/vm/unevictable-lru.txt @@ -197,12 +197,8 @@ the pages are also "rescued" from the unevictable list in the process of freeing them. page_evictable() also checks for mlocked pages by testing an additional page -flag, PG_mlocked (as wrapped by PageMlocked()). If the page is NOT mlocked, -and a non-NULL VMA is supplied, page_evictable() will check whether the VMA is -VM_LOCKED via is_mlocked_vma(). is_mlocked_vma() will SetPageMlocked() and -update the appropriate statistics if the vma is VM_LOCKED. This method allows -efficient "culling" of pages in the fault path that are being faulted in to -VM_LOCKED VMAs. +flag, PG_mlocked (as wrapped by PageMlocked()), which is set when a page is +faulted into a VM_LOCKED vma, or found in a vma being VM_LOCKED. VMSCAN'S HANDLING OF UNEVICTABLE PAGES @@ -371,8 +367,8 @@ mlock_fixup() filters several classes of "special" VMAs: mlock_fixup() will call make_pages_present() in the hugetlbfs VMA range to allocate the huge pages and populate the ptes. -3) VMAs with VM_DONTEXPAND or VM_RESERVED are generally userspace mappings of - kernel pages, such as the VDSO page, relay channel pages, etc. These pages +3) VMAs with VM_DONTEXPAND are generally userspace mappings of kernel pages, + such as the VDSO page, relay channel pages, etc. These pages are inherently unevictable and are not managed on the LRU lists. mlock_fixup() treats these VMAs the same as hugetlbfs VMAs. It calls make_pages_present() to populate the ptes. @@ -651,7 +647,7 @@ PAGE RECLAIM IN shrink_*_list() ------------------------------- shrink_active_list() culls any obviously unevictable pages - i.e. -!page_evictable(page, NULL) - diverting these to the unevictable list. +!page_evictable(page) - diverting these to the unevictable list. However, shrink_active_list() only sees unevictable pages that made it onto the active/inactive lru lists. Note that these pages do not have PageUnevictable set - otherwise they would be on the unevictable list and shrink_active_list diff --git a/Documentation/zh_CN/IRQ.txt b/Documentation/zh_CN/IRQ.txt new file mode 100644 index 000000000000..956026d5cf82 --- /dev/null +++ b/Documentation/zh_CN/IRQ.txt @@ -0,0 +1,39 @@ +Chinese translated version of Documentation/IRQ.txt + +If you have any comment or update to the content, please contact the +original document maintainer directly. However, if you have a problem +communicating in English you can also ask the Chinese maintainer for +help. Contact the Chinese maintainer if this translation is outdated +or if there is a problem with the translation. + +Maintainer: Eric W. Biederman <ebiederman@xmission.com> +Chinese maintainer: Fu Wei <tekkamanninja@gmail.com> +--------------------------------------------------------------------- +Documentation/IRQ.txt 的中文翻译 + +如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文 +交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻 +译存在问题，请联系中文版维护者。 +英文版维护者： Eric W. Biederman <ebiederman@xmission.com> +中文版维护者： 傅炜 Fu Wei <tekkamanninja@gmail.com> +中文版翻译者： 傅炜 Fu Wei <tekkamanninja@gmail.com> +中文版校译者： 傅炜 Fu Wei <tekkamanninja@gmail.com> + + +以下为正文 +--------------------------------------------------------------------- +何为 IRQ? + +一个 IRQ 是来自某个设备的一个中断请求。目前，它们可以来自一个硬件引脚， +或来自一个数据包。多个设备可能连接到同个硬件引脚，从而共享一个 IRQ。 + +一个 IRQ 编号是用于告知硬件中断源的内核标识。通常情况下，这是一个 +全局 irq_desc 数组的索引，但是除了在 linux/interrupt.h 中的实现， +具体的细节是体系结构特定的。 + +一个 IRQ 编号是设备上某个可能的中断源的枚举。通常情况下，枚举的编号是 +该引脚在系统内中断控制器的所有输入引脚中的编号。对于 ISA 总线中的情况， +枚举的是在两个 i8259 中断控制器中 16 个输入引脚。 + +架构可以对 IRQ 编号指定额外的含义，在硬件涉及任何手工配置的情况下， +是被提倡的。ISA 的 IRQ 是一个分配这类额外含义的典型例子。 diff --git a/Documentation/zh_CN/arm64/booting.txt b/Documentation/zh_CN/arm64/booting.txt new file mode 100644 index 000000000000..28fa325b7461 --- /dev/null +++ b/Documentation/zh_CN/arm64/booting.txt @@ -0,0 +1,156 @@ +Chinese translated version of Documentation/arm64/booting.txt + +If you have any comment or update to the content, please contact the +original document maintainer directly. However, if you have a problem +communicating in English you can also ask the Chinese maintainer for +help. Contact the Chinese maintainer if this translation is outdated +or if there is a problem with the translation. + +Maintainer: Will Deacon <will.deacon@arm.com> +Chinese maintainer: Fu Wei <tekkamanninja@gmail.com> +--------------------------------------------------------------------- +Documentation/arm64/booting.txt 的中文翻译 + +如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文 +交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻 +译存在问题，请联系中文版维护者。 + +英文版维护者： Will Deacon <will.deacon@arm.com> +中文版维护者： 傅炜 Fu Wei <tekkamanninja@gmail.com> +中文版翻译者： 傅炜 Fu Wei <tekkamanninja@gmail.com> +中文版校译者： 傅炜 Fu Wei <tekkamanninja@gmail.com> + +以下为正文 +--------------------------------------------------------------------- + 启动 AArch64 Linux + ================== + +作者: Will Deacon <will.deacon@arm.com> +日期: 2012 年 09 月 07 日 + +本文档基于 Russell King 的 ARM 启动文档，且适用于所有公开发布的 +AArch64 Linux 内核代码。 + +AArch64 异常模型由多个异常级别（EL0 - EL3）组成，对于 EL0 和 EL1 +异常级有对应的安全和非安全模式。EL2 是系统管理级，且仅存在于 +非安全模式下。EL3 是最高特权级，且仅存在于安全模式下。 + +基于本文档的目的，我们将简单地使用‘引导装载程序’（‘boot loader’） +这个术语来定义在将控制权交给 Linux 内核前 CPU 上执行的所有软件。 +这可能包含安全监控和系统管理代码，或者它可能只是一些用于准备最小启动 +环境的指令。 + +基本上，引导装载程序（至少）应实现以下操作： + +1、设置和初始化 RAM +2、设置设备树数据 +3、解压内核映像 +4、调用内核映像 + + +1、设置和初始化 RAM +----------------- + +必要性: 强制 + +引导装载程序应该找到并初始化系统中所有内核用于保持系统变量数据的 RAM。 +这个操作的执行是设备依赖的。（它可能使用内部算法来自动定位和计算所有 +RAM，或可能使用对这个设备已知的 RAM 信息，还可能使用任何引导装载程序 +设计者想到的匹配方法。） + + +2、设置设备树数据 +--------------- + +必要性: 强制 + +设备树数据块（dtb）大小必须不大于 2 MB，且位于从内核映像起始算起第一个 +512MB 内的 2MB 边界上。这使得内核可以通过初始页表中的单个节描述符来 +映射此数据块。 + + +3、解压内核映像 +------------- + +必要性: 可选 + +AArch64 内核当前没有提供自解压代码，因此如果使用了压缩内核映像文件 +（比如 Image.gz），则需要通过引导装载程序（使用 gzip 等）来进行解压。 +若引导装载程序没有实现这个需求，就要使用非压缩内核映像文件。 + + +4、调用内核映像 +------------- + +必要性: 强制 + +已解压的内核映像包含一个 32 字节的头，内容如下： + + u32 magic = 0x14000008; /* 跳转到 stext, 小端 */ + u32 res0 = 0; /* 保留 */ + u64 text_offset; /* 映像装载偏移 */ + u64 res1 = 0; /* 保留 */ + u64 res2 = 0; /* 保留 */ + +映像必须位于系统 RAM 起始处的特定偏移（当前是 0x80000）。系统 RAM +的起始地址必须是以 2MB 对齐的。 + +在跳转入内核前，必须符合以下状态： + +- 停止所有 DMA 设备，这样内存数据就不会因为虚假网络包或磁盘数据而 + 被破坏。这可能可以节省你许多的调试时间。 + +- 主 CPU 通用寄存器设置 + x0 = 系统 RAM 中设备树数据块（dtb）的物理地址。 + x1 = 0 (保留，将来可能使用) + x2 = 0 (保留，将来可能使用) + x3 = 0 (保留，将来可能使用) + +- CPU 模式 + 所有形式的中断必须在 PSTATE.DAIF 中被屏蔽（Debug、SError、IRQ + 和 FIQ）。 + CPU 必须处于 EL2（推荐，可访问虚拟化扩展）或非安全 EL1 模式下。 + +- 高速缓存、MMU + MMU 必须关闭。 + 指令缓存开启或关闭都可以。 + 数据缓存必须关闭且无效。 + 外部高速缓存（如果存在）必须配置并禁用。 + +- 架构计时器 + CNTFRQ 必须设定为计时器的频率。 + 如果在 EL1 模式下进入内核，则 CNTHCTL_EL2 中的 EL1PCTEN (bit 0) + 必须置位。 + +- 一致性 + 通过内核启动的所有 CPU 在内核入口地址上必须处于相同的一致性域中。 + 这可能要根据具体实现来定义初始化过程，以使能每个CPU上对维护操作的 + 接收。 + +- 系统寄存器 + 在进入内核映像的异常级中，所有构架中可写的系统寄存器必须通过软件 + 在一个更高的异常级别下初始化，以防止在 未知 状态下运行。 + +引导装载程序必须在每个 CPU 处于以下状态时跳入内核入口： + +- 主 CPU 必须直接跳入内核映像的第一条指令。通过此 CPU 传递的设备树 + 数据块必须在每个 CPU 节点中包含以下内容： + + 1、‘enable-method’属性。目前，此字段支持的值仅为字符串“spin-table”。 + + 2、‘cpu-release-addr’标识一个 64-bit、初始化为零的内存位置。 + + 引导装载程序必须生成这些设备树属性，并在跳入内核入口之前将其插入 + 数据块。 + +- 任何辅助 CPU 必须在内存保留区（通过设备树中的 /memreserve/ 域传递 + 给内核）中自旋于内核之外，轮询它们的 cpu-release-addr 位置（必须 + 包含在保留区中）。可通过插入 wfe 指令来降低忙循环开销，而主 CPU 将 + 发出 sev 指令。当对 cpu-release-addr 所指位置的读取操作返回非零值 + 时，CPU 必须直接跳入此值所指向的地址。 + +- 辅助 CPU 通用寄存器设置 + x0 = 0 (保留，将来可能使用) + x1 = 0 (保留，将来可能使用) + x2 = 0 (保留，将来可能使用) + x3 = 0 (保留，将来可能使用) diff --git a/Documentation/zh_CN/arm64/memory.txt b/Documentation/zh_CN/arm64/memory.txt new file mode 100644 index 000000000000..83b519314706 --- /dev/null +++ b/Documentation/zh_CN/arm64/memory.txt @@ -0,0 +1,93 @@ +Chinese translated version of Documentation/arm64/memory.txt + +If you have any comment or update to the content, please contact the +original document maintainer directly. However, if you have a problem +communicating in English you can also ask the Chinese maintainer for +help. Contact the Chinese maintainer if this translation is outdated +or if there is a problem with the translation. + +Maintainer: Catalin Marinas <catalin.marinas@arm.com> +Chinese maintainer: Fu Wei <tekkamanninja@gmail.com> +--------------------------------------------------------------------- +Documentation/arm64/memory.txt 的中文翻译 + +如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文 +交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻 +译存在问题，请联系中文版维护者。 + +英文版维护者： Catalin Marinas <catalin.marinas@arm.com> +中文版维护者： 傅炜 Fu Wei <tekkamanninja@gmail.com> +中文版翻译者： 傅炜 Fu Wei <tekkamanninja@gmail.com> +中文版校译者： 傅炜 Fu Wei <tekkamanninja@gmail.com> + +以下为正文 +--------------------------------------------------------------------- + Linux 在 AArch64 中的内存布局 + =========================== + +作者: Catalin Marinas <catalin.marinas@arm.com> +日期: 2012 年 02 月 20 日 + +本文档描述 AArch64 Linux 内核所使用的虚拟内存布局。此构架可以实现 +页大小为 4KB 的 4 级转换表和页大小为 64KB 的 3 级转换表。 + +AArch64 Linux 使用页大小为 4KB 的 3 级转换表配置，对于用户和内核 +都有 39-bit (512GB) 的虚拟地址空间。对于页大小为 64KB的配置，仅 +使用 2 级转换表，但内存布局相同。 + +用户地址空间的 63:39 位为 0，而内核地址空间的相应位为 1。TTBRx 的 +选择由虚拟地址的 63 位给出。swapper_pg_dir 仅包含内核（全局）映射， +而用户 pgd 仅包含用户（非全局）映射。swapper_pgd_dir 地址被写入 +TTBR1 中，且从不写入 TTBR0。 + + +AArch64 Linux 内存布局： + +起始地址 结束地址 大小 用途 +----------------------------------------------------------------------- +0000000000000000 0000007fffffffff 512GB 用户空间 + +ffffff8000000000 ffffffbbfffcffff ~240GB vmalloc + +ffffffbbfffd0000 ffffffbcfffdffff 64KB [防护页] + +ffffffbbfffe0000 ffffffbcfffeffff 64KB PCI I/O 空间 + +ffffffbbffff0000 ffffffbcffffffff 64KB [防护页] + +ffffffbc00000000 ffffffbdffffffff 8GB vmemmap + +ffffffbe00000000 ffffffbffbffffff ~8GB [防护页，未来用于 vmmemap] + +ffffffbffc000000 ffffffbfffffffff 64MB 模块 + +ffffffc000000000 ffffffffffffffff 256GB 内存空间 + + +4KB 页大小的转换表查找： + ++--------+--------+--------+--------+--------+--------+--------+--------+ +|63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0| ++--------+--------+--------+--------+--------+--------+--------+--------+ + | | | | | | + | | | | | v + | | | | | [11:0] 页内偏移 + | | | | +-> [20:12] L3 索引 + | | | +-----------> [29:21] L2 索引 + | | +---------------------> [38:30] L1 索引 + | +-------------------------------> [47:39] L0 索引 (未使用) + +-------------------------------------------------> [63] TTBR0/1 + + +64KB 页大小的转换表查找： + ++--------+--------+--------+--------+--------+--------+--------+--------+ +|63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0| ++--------+--------+--------+--------+--------+--------+--------+--------+ + | | | | | + | | | | v + | | | | [15:0] 页内偏移 + | | | +----------> [28:16] L3 索引 + | | +--------------------------> [41:29] L2 索引 (仅使用 38:29 ) + | +-------------------------------> [47:42] L1 索引 (未使用) + +-------------------------------------------------> [63] TTBR0/1 |