diff options
Diffstat (limited to 'Documentation')
285 files changed, 8577 insertions, 3184 deletions
diff --git a/Documentation/ABI/testing/sysfs-block-zram b/Documentation/ABI/testing/sysfs-block-zram index 3f0b9ae61d8c..70ec992514d0 100644 --- a/Documentation/ABI/testing/sysfs-block-zram +++ b/Documentation/ABI/testing/sysfs-block-zram @@ -43,6 +43,36 @@ Description: The invalid_io file is read-only and specifies the number of non-page-size-aligned I/O requests issued to this device. +What: /sys/block/zram<id>/failed_reads +Date: February 2014 +Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> +Description: + The failed_reads file is read-only and specifies the number of + failed reads happened on this device. + +What: /sys/block/zram<id>/failed_writes +Date: February 2014 +Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> +Description: + The failed_writes file is read-only and specifies the number of + failed writes happened on this device. + +What: /sys/block/zram<id>/max_comp_streams +Date: February 2014 +Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> +Description: + The max_comp_streams file is read-write and specifies the + number of backend's zcomp_strm compression streams (number of + concurrent compress operations). + +What: /sys/block/zram<id>/comp_algorithm +Date: February 2014 +Contact: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> +Description: + The comp_algorithm file is read-write and lets to show + available and selected compression algorithms, change + compression algorithm selection. + What: /sys/block/zram<id>/notify_free Date: August 2010 Contact: Nitin Gupta <ngupta@vflare.org> @@ -53,15 +83,6 @@ Description: is freed. This statistic is applicable only when this disk is being used as a swap disk. -What: /sys/block/zram<id>/discard -Date: August 2010 -Contact: Nitin Gupta <ngupta@vflare.org> -Description: - The discard file is read-only and specifies the number of - discard requests received by this device. These requests - provide information to block device regarding blocks which are - no longer used by filesystem. - What: /sys/block/zram<id>/zero_pages Date: August 2010 Contact: Nitin Gupta <ngupta@vflare.org> diff --git a/Documentation/ABI/testing/sysfs-bus-mdio b/Documentation/ABI/testing/sysfs-bus-mdio index 6349749ebc29..491baaf4285f 100644 --- a/Documentation/ABI/testing/sysfs-bus-mdio +++ b/Documentation/ABI/testing/sysfs-bus-mdio @@ -7,3 +7,23 @@ Description: by the device during bus enumeration, encoded in hexadecimal. This ID is used to match the device with the appropriate driver. + +What: /sys/bus/mdio_bus/devices/.../phy_interface +Date: February 2014 +KernelVersion: 3.15 +Contact: netdev@vger.kernel.org +Description: + This attribute contains the PHY interface as configured by the + Ethernet driver during bus enumeration, encoded in string. + This interface mode is used to configure the Ethernet MAC with the + appropriate mode for its data lines to the PHY hardware. + +What: /sys/bus/mdio_bus/devices/.../phy_has_fixups +Date: February 2014 +KernelVersion: 3.15 +Contact: netdev@vger.kernel.org +Description: + This attribute contains the boolean value whether a given PHY + device has had any "fixup" workaround running on it, encoded as + a boolean. This information is provided to help troubleshooting + PHY configurations. diff --git a/Documentation/ABI/testing/sysfs-class-net b/Documentation/ABI/testing/sysfs-class-net new file mode 100644 index 000000000000..d922060e455d --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-net @@ -0,0 +1,199 @@ +What: /sys/class/net/<iface>/addr_assign_type +Date: July 2010 +KernelVersion: 3.2 +Contact: netdev@vger.kernel.org +Description: + Indicates the address assignment type. Possible values are: + 0: permanent address + 1: randomly generated + 2: stolen from another device + 3: set using dev_set_mac_address + +What: /sys/class/net/<iface>/addr_len +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the hardware address size in bytes. + Values vary based on the lower-level protocol used by the + interface (Ethernet, FDDI, ATM, IEEE 802.15.4...). See + include/uapi/linux/if_*.h for actual values. + +What: /sys/class/net/<iface>/address +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Hardware address currently assigned to this interface. + Format is a string, e.g: 00:11:22:33:44:55 for an Ethernet MAC + address. + +What: /sys/class/net/<iface>/broadcast +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Hardware broadcast address for this interface. Format is a + string, e.g: ff:ff:ff:ff:ff:ff for an Ethernet broadcast MAC + address. + +What: /sys/class/net/<iface>/carrier +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the current physical link state of the interface. + Posssible values are: + 0: physical link is down + 1: physical link is up + + Note: some special devices, e.g: bonding and team drivers will + allow this attribute to be written to force a link state for + operating correctly and designating another fallback interface. + +What: /sys/class/net/<iface>/dev_id +Date: April 2008 +KernelVersion: 2.6.26 +Contact: netdev@vger.kernel.org +Description: + Indicates the device unique identifier. Format is an hexadecimal + value. This is used to disambiguate interfaces which might be + stacked (e.g: VLAN interfaces) but still have the same MAC + address as their parent device. + +What: /sys/class/net/<iface>/dormant +Date: March 2006 +KernelVersion: 2.6.17 +Contact: netdev@vger.kernel.org +Description: + Indicates whether the interface is in dormant state. Possible + values are: + 0: interface is not dormant + 1: interface is dormant + + This attribute can be used by supplicant software to signal that + the device is not usable unless some supplicant-based + authentication is performed (e.g: 802.1x). 'link_mode' attribute + will also reflect the dormant state. + +What: /sys/clas/net/<iface>/duplex +Date: October 2009 +KernelVersion: 2.6.33 +Contact: netdev@vger.kernel.org +Description: + Indicates the interface latest or current duplex value. Possible + values are: + half: half duplex + full: full duplex + + Note: This attribute is only valid for interfaces that implement + the ethtool get_settings method (mostly Ethernet). + +What: /sys/class/net/<iface>/flags +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the interface flags as a bitmask in hexadecimal. See + include/uapi/linux/if.h for a list of all possible values and + the flags semantics. + +What: /sys/class/net/<iface>/ifalias +Date: September 2008 +KernelVersion: 2.6.28 +Contact: netdev@vger.kernel.org +Description: + Indicates/stores an interface alias name as a string. This can + be used for system management purposes. + +What: /sys/class/net/<iface>/ifindex +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the system-wide interface unique index identifier as a + decimal number. This attribute is used for mapping an interface + identifier to an interface name. It is used throughout the + networking stack for specifying the interface specific + requests/events. + +What: /sys/class/net/<iface>/iflink +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the system-wide interface unique index identifier a + the interface is linked to. Format is decimal. This attribute is + used to resolve interfaces chaining, linking and stacking. + Physical interfaces have the same 'ifindex' and 'iflink' values. + +What: /sys/class/net/<iface>/link_mode +Date: March 2006 +KernelVersion: 2.6.17 +Contact: netdev@vger.kernel.org +Description: + Indicates the interface link mode, as a decimal number. This + attribute should be used in conjunction with 'dormant' attribute + to determine the interface usability. Possible values: + 0: default link mode + 1: dormant link mode + +What: /sys/class/net/<iface>/mtu +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the interface currently configured MTU value, in + bytes, and in decimal format. Specific values depends on the + lower-level interface protocol used. Ethernet devices will show + a 'mtu' attribute value of 1500 unless changed. + +What: /sys/calss/net/<iface>/netdev_group +Date: January 2011 +KernelVersion: 2.6.39 +Contact: netdev@vger.kernel.org +Description: + Indicates the interface network device group, as a decimal + integer. Default value is 0 which corresponds to the initial + network devices group. The group can be changed to affect + routing decisions (see: net/ipv4/fib_rules and + net/ipv6/fib6_rules.c). + +What: /sys/class/net/<iface>/operstate +Date: March 2006 +KernelVersion: 2.6.17 +Contact: netdev@vger.kernel.org +Description: + Indicates the interface RFC2863 operational state as a string. + Possible values are: + "unknown", "notpresent", "down", "lowerlayerdown", "testing", + "dormant", "up". + +What: /sys/class/net/<iface>/speed +Date: October 2009 +KernelVersion: 2.6.33 +Contact: netdev@vger.kernel.org +Description: + Indicates the interface latest or current speed value. Value is + an integer representing the link speed in Mbits/sec. + + Note: this attribute is only valid for interfaces that implement + the ethtool get_settings method (mostly Ethernet ). + +What: /sys/class/net/<iface>/tx_queue_len +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the interface transmit queue len in number of packets, + as an integer value. Value depend on the type of interface, + Ethernet network adapters have a default value of 1000 unless + configured otherwise + +What: /sys/class/net/<iface>/type +Date: April 2005 +KernelVersion: 2.6.12 +Contact: netdev@vger.kernel.org +Description: + Indicates the interface protocol type as a decimal value. See + include/uapi/linux/if_arp.h for all possible values. diff --git a/Documentation/ABI/testing/sysfs-class-net-mesh b/Documentation/ABI/testing/sysfs-class-net-mesh index 4793d3dff6af..c46406296631 100644 --- a/Documentation/ABI/testing/sysfs-class-net-mesh +++ b/Documentation/ABI/testing/sysfs-class-net-mesh @@ -76,6 +76,15 @@ Description: is used to classify clients as "isolated" by the Extended Isolation feature. +What: /sys/class/net/<mesh_iface>/mesh/multicast_mode +Date: Feb 2014 +Contact: Linus Lüssing <linus.luessing@web.de> +Description: + Indicates whether multicast optimizations are enabled + or disabled. If set to zero then all nodes in the + mesh are going to use classic flooding for any + multicast packet with no optimizations. + What: /sys/class/net/<mesh_iface>/mesh/network_coding Date: Nov 2012 Contact: Martin Hundeboll <martin@hundeboll.net> diff --git a/Documentation/ABI/testing/sysfs-class-rc b/Documentation/ABI/testing/sysfs-class-rc new file mode 100644 index 000000000000..b65674da43bb --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-rc @@ -0,0 +1,111 @@ +What: /sys/class/rc/ +Date: Apr 2010 +KernelVersion: 2.6.35 +Contact: Mauro Carvalho Chehab <m.chehab@samsung.com> +Description: + The rc/ class sub-directory belongs to the Remote Controller + core and provides a sysfs interface for configuring infrared + remote controller receivers. + +What: /sys/class/rc/rcN/ +Date: Apr 2010 +KernelVersion: 2.6.35 +Contact: Mauro Carvalho Chehab <m.chehab@samsung.com> +Description: + A /sys/class/rc/rcN directory is created for each remote + control receiver device where N is the number of the receiver. + +What: /sys/class/rc/rcN/protocols +Date: Jun 2010 +KernelVersion: 2.6.36 +Contact: Mauro Carvalho Chehab <m.chehab@samsung.com> +Description: + Reading this file returns a list of available protocols, + something like: + "rc5 [rc6] nec jvc [sony]" + Enabled protocols are shown in [] brackets. + Writing "+proto" will add a protocol to the list of enabled + protocols. + Writing "-proto" will remove a protocol from the list of enabled + protocols. + Writing "proto" will enable only "proto". + Writing "none" will disable all protocols. + Write fails with EINVAL if an invalid protocol combination or + unknown protocol name is used. + +What: /sys/class/rc/rcN/filter +Date: Jan 2014 +KernelVersion: 3.15 +Contact: Mauro Carvalho Chehab <m.chehab@samsung.com> +Description: + Sets the scancode filter expected value. + Use in combination with /sys/class/rc/rcN/filter_mask to set the + expected value of the bits set in the filter mask. + If the hardware supports it then scancodes which do not match + the filter will be ignored. Otherwise the write will fail with + an error. + This value may be reset to 0 if the current protocol is altered. + +What: /sys/class/rc/rcN/filter_mask +Date: Jan 2014 +KernelVersion: 3.15 +Contact: Mauro Carvalho Chehab <m.chehab@samsung.com> +Description: + Sets the scancode filter mask of bits to compare. + Use in combination with /sys/class/rc/rcN/filter to set the bits + of the scancode which should be compared against the expected + value. A value of 0 disables the filter to allow all valid + scancodes to be processed. + If the hardware supports it then scancodes which do not match + the filter will be ignored. Otherwise the write will fail with + an error. + This value may be reset to 0 if the current protocol is altered. + +What: /sys/class/rc/rcN/wakeup_protocols +Date: Feb 2014 +KernelVersion: 3.15 +Contact: Mauro Carvalho Chehab <m.chehab@samsung.com> +Description: + Reading this file returns a list of available protocols to use + for the wakeup filter, something like: + "rc5 rc6 nec jvc [sony]" + The enabled wakeup protocol is shown in [] brackets. + Writing "+proto" will add a protocol to the list of enabled + wakeup protocols. + Writing "-proto" will remove a protocol from the list of enabled + wakeup protocols. + Writing "proto" will use "proto" for wakeup events. + Writing "none" will disable wakeup. + Write fails with EINVAL if an invalid protocol combination or + unknown protocol name is used, or if wakeup is not supported by + the hardware. + +What: /sys/class/rc/rcN/wakeup_filter +Date: Jan 2014 +KernelVersion: 3.15 +Contact: Mauro Carvalho Chehab <m.chehab@samsung.com> +Description: + Sets the scancode wakeup filter expected value. + Use in combination with /sys/class/rc/rcN/wakeup_filter_mask to + set the expected value of the bits set in the wakeup filter mask + to trigger a system wake event. + If the hardware supports it and wakeup_filter_mask is not 0 then + scancodes which match the filter will wake the system from e.g. + suspend to RAM or power off. + Otherwise the write will fail with an error. + This value may be reset to 0 if the wakeup protocol is altered. + +What: /sys/class/rc/rcN/wakeup_filter_mask +Date: Jan 2014 +KernelVersion: 3.15 +Contact: Mauro Carvalho Chehab <m.chehab@samsung.com> +Description: + Sets the scancode wakeup filter mask of bits to compare. + Use in combination with /sys/class/rc/rcN/wakeup_filter to set + the bits of the scancode which should be compared against the + expected value to trigger a system wake event. + If the hardware supports it and wakeup_filter_mask is not 0 then + scancodes which match the filter will wake the system from e.g. + suspend to RAM or power off. + Otherwise the write will fail with an error. + This value may be reset to 0 if the wakeup protocol is altered. diff --git a/Documentation/ABI/testing/sysfs-devices-power b/Documentation/ABI/testing/sysfs-devices-power index 7dbf96b724ed..676fdf5f2a99 100644 --- a/Documentation/ABI/testing/sysfs-devices-power +++ b/Documentation/ABI/testing/sysfs-devices-power @@ -83,8 +83,10 @@ Contact: Rafael J. Wysocki <rjw@rjwysocki.net> Description: The /sys/devices/.../wakeup_count attribute contains the number of signaled wakeup events associated with the device. This - attribute is read-only. If the device is not enabled to wake up + attribute is read-only. If the device is not capable to wake up the system from sleep states, this attribute is not present. + If the device is not enabled to wake up the system from sleep + states, this attribute is empty. What: /sys/devices/.../power/wakeup_active_count Date: September 2010 @@ -93,8 +95,10 @@ Description: The /sys/devices/.../wakeup_active_count attribute contains the number of times the processing of wakeup events associated with the device was completed (at the kernel level). This attribute - is read-only. If the device is not enabled to wake up the - system from sleep states, this attribute is not present. + is read-only. If the device is not capable to wake up the + system from sleep states, this attribute is not present. If + the device is not enabled to wake up the system from sleep + states, this attribute is empty. What: /sys/devices/.../power/wakeup_abort_count Date: February 2012 @@ -104,8 +108,9 @@ Description: number of times the processing of a wakeup event associated with the device might have aborted system transition into a sleep state in progress. This attribute is read-only. If the device - is not enabled to wake up the system from sleep states, this - attribute is not present. + is not capable to wake up the system from sleep states, this + attribute is not present. If the device is not enabled to wake + up the system from sleep states, this attribute is empty. What: /sys/devices/.../power/wakeup_expire_count Date: February 2012 @@ -114,8 +119,10 @@ Description: The /sys/devices/.../wakeup_expire_count attribute contains the number of times a wakeup event associated with the device has been reported with a timeout that expired. This attribute is - read-only. If the device is not enabled to wake up the system - from sleep states, this attribute is not present. + read-only. If the device is not capable to wake up the system + from sleep states, this attribute is not present. If the + device is not enabled to wake up the system from sleep states, + this attribute is empty. What: /sys/devices/.../power/wakeup_active Date: September 2010 @@ -124,8 +131,10 @@ Description: The /sys/devices/.../wakeup_active attribute contains either 1, or 0, depending on whether or not a wakeup event associated with the device is being processed (1). This attribute is read-only. - If the device is not enabled to wake up the system from sleep - states, this attribute is not present. + If the device is not capable to wake up the system from sleep + states, this attribute is not present. If the device is not + enabled to wake up the system from sleep states, this attribute + is empty. What: /sys/devices/.../power/wakeup_total_time_ms Date: September 2010 @@ -134,8 +143,9 @@ Description: The /sys/devices/.../wakeup_total_time_ms attribute contains the total time of processing wakeup events associated with the device, in milliseconds. This attribute is read-only. If the - device is not enabled to wake up the system from sleep states, - this attribute is not present. + device is not capable to wake up the system from sleep states, + this attribute is not present. If the device is not enabled to + wake up the system from sleep states, this attribute is empty. What: /sys/devices/.../power/wakeup_max_time_ms Date: September 2010 @@ -144,8 +154,10 @@ Description: The /sys/devices/.../wakeup_max_time_ms attribute contains the maximum time of processing a single wakeup event associated with the device, in milliseconds. This attribute is read-only. - If the device is not enabled to wake up the system from sleep - states, this attribute is not present. + If the device is not capable to wake up the system from sleep + states, this attribute is not present. If the device is not + enabled to wake up the system from sleep states, this attribute + is empty. What: /sys/devices/.../power/wakeup_last_time_ms Date: September 2010 @@ -156,7 +168,8 @@ Description: signaling the last wakeup event associated with the device, in milliseconds. This attribute is read-only. If the device is not enabled to wake up the system from sleep states, this - attribute is not present. + attribute is not present. If the device is not enabled to wake + up the system from sleep states, this attribute is empty. What: /sys/devices/.../power/wakeup_prevent_sleep_time_ms Date: February 2012 @@ -165,9 +178,10 @@ Description: The /sys/devices/.../wakeup_prevent_sleep_time_ms attribute contains the total time the device has been preventing opportunistic transitions to sleep states from occurring. - This attribute is read-only. If the device is not enabled to + This attribute is read-only. If the device is not capable to wake up the system from sleep states, this attribute is not - present. + present. If the device is not enabled to wake up the system + from sleep states, this attribute is empty. What: /sys/devices/.../power/autosuspend_delay_ms Date: September 2010 diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index 32b0809203dd..62dd72522d6e 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -55,3 +55,15 @@ Date: January 2014 Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com> Description: Controls the number of trials to find a victim segment. + +What: /sys/fs/f2fs/<disk>/dir_level +Date: March 2014 +Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com> +Description: + Controls the directory level for large directory. + +What: /sys/fs/f2fs/<disk>/ram_thresh +Date: March 2014 +Contact: "Jaegeuk Kim" <jaegeuk.kim@samsung.com> +Description: + Controls the memory footprint used by f2fs. diff --git a/Documentation/ABI/testing/sysfs-module b/Documentation/ABI/testing/sysfs-module index 47064c2b1f79..0aac02e7fb0e 100644 --- a/Documentation/ABI/testing/sysfs-module +++ b/Documentation/ABI/testing/sysfs-module @@ -49,3 +49,4 @@ Description: Module taint flags: O - out-of-tree module F - force-loaded module C - staging driver module + E - unsigned module diff --git a/Documentation/ABI/testing/sysfs-ptp b/Documentation/ABI/testing/sysfs-ptp index 05aeedf17794..44806a678f12 100644 --- a/Documentation/ABI/testing/sysfs-ptp +++ b/Documentation/ABI/testing/sysfs-ptp @@ -54,6 +54,26 @@ Description: This file contains the number of programmable periodic output channels offered by the PTP hardware clock. +What: /sys/class/ptp/ptpN/n_pins +Date: March 2014 +Contact: Richard Cochran <richardcochran@gmail.com> +Description: + This file contains the number of programmable pins + offered by the PTP hardware clock. + +What: /sys/class/ptp/ptpN/pins +Date: March 2014 +Contact: Richard Cochran <richardcochran@gmail.com> +Description: + This directory contains one file for each programmable + pin offered by the PTP hardware clock. The file name + is the hardware dependent pin name. Reading from this + file produces two numbers, the assigned function (see + the PTP_PF_ enumeration values in linux/ptp_clock.h) + and the channel number. The function and channel + assignment may be changed by two writing numbers into + the file. + What: /sys/class/ptp/ptpN/pps_avaiable Date: September 2010 Contact: Richard Cochran <richardcochran@gmail.com> diff --git a/Documentation/DocBook/80211.tmpl b/Documentation/DocBook/80211.tmpl index 46ad6faee9ab..044b76436e83 100644 --- a/Documentation/DocBook/80211.tmpl +++ b/Documentation/DocBook/80211.tmpl @@ -98,6 +98,8 @@ !Finclude/net/cfg80211.h priv_to_wiphy !Finclude/net/cfg80211.h set_wiphy_dev !Finclude/net/cfg80211.h wdev_priv +!Finclude/net/cfg80211.h ieee80211_iface_limit +!Finclude/net/cfg80211.h ieee80211_iface_combination </chapter> <chapter> <title>Actions and configuration</title> diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index 8d96ebf524e9..b444f2e8fe32 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -16,7 +16,7 @@ DOCBOOKS := z8530book.xml device-drivers.xml \ alsa-driver-api.xml writing-an-alsa-driver.xml \ tracepoint.xml drm.xml media_api.xml w1.xml -include $(srctree)/Documentation/DocBook/media/Makefile +include Documentation/DocBook/media/Makefile ### # The build process is as follows (targets): @@ -36,6 +36,7 @@ PS_METHOD = $(prefer-db2x) # The targets that may be used. PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs cleandocs +targets += $(DOCBOOKS) BOOKS := $(addprefix $(obj)/,$(DOCBOOKS)) xmldocs: $(BOOKS) sgmldocs: xmldocs @@ -58,14 +59,14 @@ mandocs: $(MAN) installmandocs: mandocs mkdir -p /usr/local/man/man9/ - install Documentation/DocBook/man/*.9.gz /usr/local/man/man9/ + install $(obj)/man/*.9.gz /usr/local/man/man9/ ### #External programs used KERNELDOC = $(srctree)/scripts/kernel-doc DOCPROC = $(objtree)/scripts/docproc -XMLTOFLAGS = -m $(srctree)/Documentation/DocBook/stylesheet.xsl +XMLTOFLAGS = -m $(srctree)/$(src)/stylesheet.xsl XMLTOFLAGS += --skip-validation ### @@ -87,21 +88,9 @@ define rule_docproc ) > $(dir $@).$(notdir $@).cmd endef -%.xml: %.tmpl FORCE +%.xml: %.tmpl $(KERNELDOC) $(DOCPROC) FORCE $(call if_changed_rule,docproc) -### -#Read in all saved dependency files -cmd_files := $(wildcard $(foreach f,$(BOOKS),$(dir $(f)).$(notdir $(f)).cmd)) - -ifneq ($(cmd_files),) - include $(cmd_files) -endif - -### -# Changes in kernel-doc force a rebuild of all documentation -$(BOOKS): $(KERNELDOC) - # Tell kbuild to always build the programs always := $(hostprogs-y) @@ -139,7 +128,7 @@ quiet_cmd_db2pdf = PDF $@ index = index.html -main_idx = Documentation/DocBook/$(index) +main_idx = $(obj)/$(index) build_main_index = rm -rf $(main_idx); \ echo '<h1>Linux Kernel HTML Documentation</h1>' >> $(main_idx) && \ echo '<h2>Kernel Version: $(KERNELVERSION)</h2>' >> $(main_idx) && \ @@ -148,7 +137,7 @@ build_main_index = rm -rf $(main_idx); \ quiet_cmd_db2html = HTML $@ cmd_db2html = xmlto html $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \ echo '<a HREF="$(patsubst %.html,%,$(notdir $@))/index.html"> \ - $(patsubst %.html,%,$(notdir $@))</a><p>' > $@ + $(patsubst %.html,%,$(notdir $@))</a><p>' > $@ %.html: %.xml @(which xmlto > /dev/null 2>&1) || \ diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index ed1d6d289022..702c4474919c 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -29,12 +29,26 @@ </address> </affiliation> </author> + <author> + <firstname>Daniel</firstname> + <surname>Vetter</surname> + <contrib>Contributions all over the place</contrib> + <affiliation> + <orgname>Intel Corporation</orgname> + <address> + <email>daniel.vetter@ffwll.ch</email> + </address> + </affiliation> + </author> </authorgroup> <copyright> <year>2008-2009</year> - <year>2012</year> + <year>2013-2014</year> <holder>Intel Corporation</holder> + </copyright> + <copyright> + <year>2012</year> <holder>Laurent Pinchart</holder> </copyright> @@ -60,7 +74,15 @@ <toc></toc> - <!-- Introduction --> +<part id="drmCore"> + <title>DRM Core</title> + <partintro> + <para> + This first part of the DRM Developer's Guide documents core DRM code, + helper libraries for writting drivers and generic userspace interfaces + exposed by DRM drivers. + </para> + </partintro> <chapter id="drmIntroduction"> <title>Introduction</title> @@ -264,8 +286,8 @@ char *date;</synopsis> <para> The <methodname>load</methodname> method is the driver and device initialization entry point. The method is responsible for allocating and - initializing driver private data, specifying supported performance - counters, performing resource allocation and mapping (e.g. acquiring + initializing driver private data, performing resource allocation and + mapping (e.g. acquiring clocks, mapping registers or allocating command buffers), initializing the memory manager (<xref linkend="drm-memory-management"/>), installing the IRQ handler (<xref linkend="drm-irq-registration"/>), setting up @@ -295,7 +317,7 @@ char *date;</synopsis> their <methodname>load</methodname> method called with flags to 0. </para> <sect3> - <title>Driver Private & Performance Counters</title> + <title>Driver Private Data</title> <para> The driver private hangs off the main <structname>drm_device</structname> structure and can be used for @@ -307,14 +329,6 @@ char *date;</synopsis> <structname>drm_device</structname>.<structfield>dev_priv</structfield> set to NULL when the driver is unloaded. </para> - <para> - DRM supports several counters which were used for rough performance - characterization. This stat counter system is deprecated and should not - be used. If performance monitoring is desired, the developer should - investigate and potentially enhance the kernel perf and tracing - infrastructure to export GPU related performance information for - consumption by performance monitoring tools and applications. - </para> </sect3> <sect3 id="drm-irq-registration"> <title>IRQ Registration</title> @@ -697,55 +711,16 @@ char *date;</synopsis> respectively. The conversion is handled by the DRM core without any driver-specific support. </para> - <para> - Similar to global names, GEM file descriptors are also used to share GEM - objects across processes. They offer additional security: as file - descriptors must be explicitly sent over UNIX domain sockets to be shared - between applications, they can't be guessed like the globally unique GEM - names. - </para> - <para> - Drivers that support GEM file descriptors, also known as the DRM PRIME - API, must set the DRIVER_PRIME bit in the struct - <structname>drm_driver</structname> - <structfield>driver_features</structfield> field, and implement the - <methodname>prime_handle_to_fd</methodname> and - <methodname>prime_fd_to_handle</methodname> operations. - </para> - <para> - <synopsis>int (*prime_handle_to_fd)(struct drm_device *dev, - struct drm_file *file_priv, uint32_t handle, - uint32_t flags, int *prime_fd); - int (*prime_fd_to_handle)(struct drm_device *dev, - struct drm_file *file_priv, int prime_fd, - uint32_t *handle);</synopsis> - Those two operations convert a handle to a PRIME file descriptor and - vice versa. Drivers must use the kernel dma-buf buffer sharing framework - to manage the PRIME file descriptors. - </para> - <para> - While non-GEM drivers must implement the operations themselves, GEM - drivers must use the <function>drm_gem_prime_handle_to_fd</function> - and <function>drm_gem_prime_fd_to_handle</function> helper functions. - Those helpers rely on the driver - <methodname>gem_prime_export</methodname> and - <methodname>gem_prime_import</methodname> operations to create a dma-buf - instance from a GEM object (dma-buf exporter role) and to create a GEM - object from a dma-buf instance (dma-buf importer role). - </para> - <para> - <synopsis>struct dma_buf * (*gem_prime_export)(struct drm_device *dev, - struct drm_gem_object *obj, - int flags); - struct drm_gem_object * (*gem_prime_import)(struct drm_device *dev, - struct dma_buf *dma_buf);</synopsis> - These two operations are mandatory for GEM drivers that support DRM - PRIME. - </para> - <sect4> - <title>DRM PRIME Helper Functions Reference</title> -!Pdrivers/gpu/drm/drm_prime.c PRIME Helpers - </sect4> + <para> + GEM also supports buffer sharing with dma-buf file descriptors through + PRIME. GEM-based drivers must use the provided helpers functions to + implement the exporting and importing correctly. See <xref linkend="drm-prime-support" />. + Since sharing file descriptors is inherently more secure than the + easily guessable and global GEM names it is the preferred buffer + sharing mechanism. Sharing buffers through GEM names is only supported + for legacy userspace. Furthermore PRIME also allows cross-device + buffer sharing since it is based on dma-bufs. + </para> </sect3> <sect3 id="drm-gem-objects-mapping"> <title>GEM Objects Mapping</title> @@ -830,62 +805,6 @@ char *date;</synopsis> </para> </sect3> <sect3> - <title>Dumb GEM Objects</title> - <para> - The GEM API doesn't standardize GEM objects creation and leaves it to - driver-specific ioctls. While not an issue for full-fledged graphics - stacks that include device-specific userspace components (in libdrm for - instance), this limit makes DRM-based early boot graphics unnecessarily - complex. - </para> - <para> - Dumb GEM objects partly alleviate the problem by providing a standard - API to create dumb buffers suitable for scanout, which can then be used - to create KMS frame buffers. - </para> - <para> - To support dumb GEM objects drivers must implement the - <methodname>dumb_create</methodname>, - <methodname>dumb_destroy</methodname> and - <methodname>dumb_map_offset</methodname> operations. - </para> - <itemizedlist> - <listitem> - <synopsis>int (*dumb_create)(struct drm_file *file_priv, struct drm_device *dev, - struct drm_mode_create_dumb *args);</synopsis> - <para> - The <methodname>dumb_create</methodname> operation creates a GEM - object suitable for scanout based on the width, height and depth - from the struct <structname>drm_mode_create_dumb</structname> - argument. It fills the argument's <structfield>handle</structfield>, - <structfield>pitch</structfield> and <structfield>size</structfield> - fields with a handle for the newly created GEM object and its line - pitch and size in bytes. - </para> - </listitem> - <listitem> - <synopsis>int (*dumb_destroy)(struct drm_file *file_priv, struct drm_device *dev, - uint32_t handle);</synopsis> - <para> - The <methodname>dumb_destroy</methodname> operation destroys a dumb - GEM object created by <methodname>dumb_create</methodname>. - </para> - </listitem> - <listitem> - <synopsis>int (*dumb_map_offset)(struct drm_file *file_priv, struct drm_device *dev, - uint32_t handle, uint64_t *offset);</synopsis> - <para> - The <methodname>dumb_map_offset</methodname> operation associates an - mmap fake offset with the GEM object given by the handle and returns - it. Drivers must use the - <function>drm_gem_create_mmap_offset</function> function to - associate the fake offset as described in - <xref linkend="drm-gem-objects-mapping"/>. - </para> - </listitem> - </itemizedlist> - </sect3> - <sect3> <title>Memory Coherency</title> <para> When mapped to the device or used in a command buffer, backing pages @@ -924,7 +843,99 @@ char *date;</synopsis> abstracted from the client in libdrm. </para> </sect3> - </sect2> + <sect3> + <title>GEM Function Reference</title> +!Edrivers/gpu/drm/drm_gem.c + </sect3> + </sect2> + <sect2> + <title>VMA Offset Manager</title> +!Pdrivers/gpu/drm/drm_vma_manager.c vma offset manager +!Edrivers/gpu/drm/drm_vma_manager.c +!Iinclude/drm/drm_vma_manager.h + </sect2> + <sect2 id="drm-prime-support"> + <title>PRIME Buffer Sharing</title> + <para> + PRIME is the cross device buffer sharing framework in drm, originally + created for the OPTIMUS range of multi-gpu platforms. To userspace + PRIME buffers are dma-buf based file descriptors. + </para> + <sect3> + <title>Overview and Driver Interface</title> + <para> + Similar to GEM global names, PRIME file descriptors are + also used to share buffer objects across processes. They offer + additional security: as file descriptors must be explicitly sent over + UNIX domain sockets to be shared between applications, they can't be + guessed like the globally unique GEM names. + </para> + <para> + Drivers that support the PRIME + API must set the DRIVER_PRIME bit in the struct + <structname>drm_driver</structname> + <structfield>driver_features</structfield> field, and implement the + <methodname>prime_handle_to_fd</methodname> and + <methodname>prime_fd_to_handle</methodname> operations. + </para> + <para> + <synopsis>int (*prime_handle_to_fd)(struct drm_device *dev, + struct drm_file *file_priv, uint32_t handle, + uint32_t flags, int *prime_fd); +int (*prime_fd_to_handle)(struct drm_device *dev, + struct drm_file *file_priv, int prime_fd, + uint32_t *handle);</synopsis> + Those two operations convert a handle to a PRIME file descriptor and + vice versa. Drivers must use the kernel dma-buf buffer sharing framework + to manage the PRIME file descriptors. Similar to the mode setting + API PRIME is agnostic to the underlying buffer object manager, as + long as handles are 32bit unsinged integers. + </para> + <para> + While non-GEM drivers must implement the operations themselves, GEM + drivers must use the <function>drm_gem_prime_handle_to_fd</function> + and <function>drm_gem_prime_fd_to_handle</function> helper functions. + Those helpers rely on the driver + <methodname>gem_prime_export</methodname> and + <methodname>gem_prime_import</methodname> operations to create a dma-buf + instance from a GEM object (dma-buf exporter role) and to create a GEM + object from a dma-buf instance (dma-buf importer role). + </para> + <para> + <synopsis>struct dma_buf * (*gem_prime_export)(struct drm_device *dev, + struct drm_gem_object *obj, + int flags); +struct drm_gem_object * (*gem_prime_import)(struct drm_device *dev, + struct dma_buf *dma_buf);</synopsis> + These two operations are mandatory for GEM drivers that support + PRIME. + </para> + </sect3> + <sect3> + <title>PRIME Helper Functions</title> +!Pdrivers/gpu/drm/drm_prime.c PRIME Helpers + </sect3> + </sect2> + <sect2> + <title>PRIME Function References</title> +!Edrivers/gpu/drm/drm_prime.c + </sect2> + <sect2> + <title>DRM MM Range Allocator</title> + <sect3> + <title>Overview</title> +!Pdrivers/gpu/drm/drm_mm.c Overview + </sect3> + <sect3> + <title>LRU Scan/Eviction Support</title> +!Pdrivers/gpu/drm/drm_mm.c lru scan roaster + </sect3> + </sect2> + <sect2> + <title>DRM MM Range Allocator Function References</title> +!Edrivers/gpu/drm/drm_mm.c +!Iinclude/drm/drm_mm.h + </sect2> </sect1> <!-- Internals: mode setting --> @@ -953,6 +964,11 @@ int max_width, max_height;</synopsis> </listitem> </itemizedlist> <sect2> + <title>Display Modes Function Reference</title> +!Iinclude/drm/drm_modes.h +!Edrivers/gpu/drm/drm_modes.c + </sect2> + <sect2> <title>Frame Buffer Creation</title> <synopsis>struct drm_framebuffer *(*fb_create)(struct drm_device *dev, struct drm_file *file_priv, @@ -968,9 +984,11 @@ int max_width, max_height;</synopsis> Frame buffers rely on the underneath memory manager for low-level memory operations. When creating a frame buffer applications pass a memory handle (or a list of memory handles for multi-planar formats) through - the <parameter>drm_mode_fb_cmd2</parameter> argument. This document - assumes that the driver uses GEM, those handles thus reference GEM - objects. + the <parameter>drm_mode_fb_cmd2</parameter> argument. For drivers using + GEM as their userspace buffer management interface this would be a GEM + handle. Drivers are however free to use their own backing storage object + handles, e.g. vmwgfx directly exposes special TTM handles to userspace + and so expects TTM handles in the create ioctl and not GEM handles. </para> <para> Drivers must first validate the requested frame buffer parameters passed @@ -992,7 +1010,7 @@ int max_width, max_height;</synopsis> </para> <para> - The initailization of the new framebuffer instance is finalized with a + The initialization of the new framebuffer instance is finalized with a call to <function>drm_framebuffer_init</function> which takes a pointer to DRM frame buffer operations (struct <structname>drm_framebuffer_funcs</structname>). Note that this function @@ -1042,7 +1060,7 @@ int max_width, max_height;</synopsis> <para> The lifetime of a drm framebuffer is controlled with a reference count, drivers can grab additional references with - <function>drm_framebuffer_reference</function> </para> and drop them + <function>drm_framebuffer_reference</function>and drop them again with <function>drm_framebuffer_unreference</function>. For driver-private framebuffers for which the last reference is never dropped (e.g. for the fbdev framebuffer when the struct @@ -1050,6 +1068,72 @@ int max_width, max_height;</synopsis> helper struct) drivers can manually clean up a framebuffer at module unload time with <function>drm_framebuffer_unregister_private</function>. + </para> + </sect2> + <sect2> + <title>Dumb Buffer Objects</title> + <para> + The KMS API doesn't standardize backing storage object creation and + leaves it to driver-specific ioctls. Furthermore actually creating a + buffer object even for GEM-based drivers is done through a + driver-specific ioctl - GEM only has a common userspace interface for + sharing and destroying objects. While not an issue for full-fledged + graphics stacks that include device-specific userspace components (in + libdrm for instance), this limit makes DRM-based early boot graphics + unnecessarily complex. + </para> + <para> + Dumb objects partly alleviate the problem by providing a standard + API to create dumb buffers suitable for scanout, which can then be used + to create KMS frame buffers. + </para> + <para> + To support dumb objects drivers must implement the + <methodname>dumb_create</methodname>, + <methodname>dumb_destroy</methodname> and + <methodname>dumb_map_offset</methodname> operations. + </para> + <itemizedlist> + <listitem> + <synopsis>int (*dumb_create)(struct drm_file *file_priv, struct drm_device *dev, + struct drm_mode_create_dumb *args);</synopsis> + <para> + The <methodname>dumb_create</methodname> operation creates a driver + object (GEM or TTM handle) suitable for scanout based on the + width, height and depth from the struct + <structname>drm_mode_create_dumb</structname> argument. It fills the + argument's <structfield>handle</structfield>, + <structfield>pitch</structfield> and <structfield>size</structfield> + fields with a handle for the newly created object and its line + pitch and size in bytes. + </para> + </listitem> + <listitem> + <synopsis>int (*dumb_destroy)(struct drm_file *file_priv, struct drm_device *dev, + uint32_t handle);</synopsis> + <para> + The <methodname>dumb_destroy</methodname> operation destroys a dumb + object created by <methodname>dumb_create</methodname>. + </para> + </listitem> + <listitem> + <synopsis>int (*dumb_map_offset)(struct drm_file *file_priv, struct drm_device *dev, + uint32_t handle, uint64_t *offset);</synopsis> + <para> + The <methodname>dumb_map_offset</methodname> operation associates an + mmap fake offset with the object given by the handle and returns + it. Drivers must use the + <function>drm_gem_create_mmap_offset</function> function to + associate the fake offset as described in + <xref linkend="drm-gem-objects-mapping"/>. + </para> + </listitem> + </itemizedlist> + <para> + Note that dumb objects may not be used for gpu acceleration, as has been + attempted on some ARM embedded platforms. Such drivers really must have + a hardware-specific ioctl to allocate suitable buffer objects. + </para> </sect2> <sect2> <title>Output Polling</title> @@ -1110,7 +1194,7 @@ int max_width, max_height;</synopsis> pointer to CRTC functions. </para> </sect3> - <sect3> + <sect3 id="drm-kms-crtcops"> <title>CRTC Operations</title> <sect4> <title>Set Configuration</title> @@ -1130,8 +1214,11 @@ int max_width, max_height;</synopsis> This operation is called with the mode config lock held. </para> <note><para> - FIXME: How should set_config interact with DPMS? If the CRTC is - suspended, should it be resumed? + Note that the drm core has no notion of restoring the mode setting + state after resume, since all resume handling is in the full + responsibility of the driver. The common mode setting helper library + though provides a helper which can be used for this: + <function>drm_helper_resume_force_mode</function>. </para></note> </sect4> <sect4> @@ -1248,15 +1335,47 @@ int max_width, max_height;</synopsis> optionally scale it to a destination size. The result is then blended with or overlayed on top of a CRTC. </para> + <para> + The DRM core recognizes three types of planes: + <itemizedlist> + <listitem> + DRM_PLANE_TYPE_PRIMARY represents a "main" plane for a CRTC. Primary + planes are the planes operated upon by by CRTC modesetting and flipping + operations described in <xref linkend="drm-kms-crtcops"/>. + </listitem> + <listitem> + DRM_PLANE_TYPE_CURSOR represents a "cursor" plane for a CRTC. Cursor + planes are the planes operated upon by the DRM_IOCTL_MODE_CURSOR and + DRM_IOCTL_MODE_CURSOR2 ioctls. + </listitem> + <listitem> + DRM_PLANE_TYPE_OVERLAY represents all non-primary, non-cursor planes. + Some drivers refer to these types of planes as "sprites" internally. + </listitem> + </itemizedlist> + For compatibility with legacy userspace, only overlay planes are made + available to userspace by default. Userspace clients may set the + DRM_CLIENT_CAP_UNIVERSAL_PLANES client capability bit to indicate that + they wish to receive a universal plane list containing all plane types. + </para> <sect3> <title>Plane Initialization</title> <para> - Planes are optional. To create a plane, a KMS drivers allocates and + To create a plane, a KMS drivers allocates and zeroes an instances of struct <structname>drm_plane</structname> (possibly as part of a larger structure) and registers it with a call - to <function>drm_plane_init</function>. The function takes a bitmask + to <function>drm_universal_plane_init</function>. The function takes a bitmask of the CRTCs that can be associated with the plane, a pointer to the - plane functions and a list of format supported formats. + plane functions, a list of format supported formats, and the type of + plane (primary, cursor, or overlay) being initialized. + </para> + <para> + Cursor and overlay planes are optional. All drivers should provide + one primary plane per CRTC (although this requirement may change in + the future); drivers that do not wish to provide special handling for + primary planes may make use of the helper functions described in + <xref linkend="drm-kms-planehelpers"/> to create and register a + primary plane with standard capabilities. </para> </sect3> <sect3> @@ -1687,7 +1806,7 @@ void intel_crt_init(struct drm_device *dev) <sect1> <title>Mode Setting Helper Functions</title> <para> - The CRTC, encoder and connector functions provided by the drivers + The plane, CRTC, encoder and connector functions provided by the drivers implement the DRM API. They're called by the DRM core and ioctl handlers to handle device state changes and configuration request. As implementing those functions often requires logic not specific to drivers, mid-layer @@ -1695,8 +1814,8 @@ void intel_crt_init(struct drm_device *dev) </para> <para> The DRM core contains one mid-layer implementation. The mid-layer provides - implementations of several CRTC, encoder and connector functions (called - from the top of the mid-layer) that pre-process requests and call + implementations of several plane, CRTC, encoder and connector functions + (called from the top of the mid-layer) that pre-process requests and call lower-level functions provided by the driver (at the bottom of the mid-layer). For instance, the <function>drm_crtc_helper_set_config</function> function can be used to @@ -2134,7 +2253,7 @@ void intel_crt_init(struct drm_device *dev) set the <structfield>display_info</structfield> <structfield>width_mm</structfield> and <structfield>height_mm</structfield> fields if they haven't been set - already (for instance at initilization time when a fixed-size panel is + already (for instance at initialization time when a fixed-size panel is attached to the connector). The mode <structfield>width_mm</structfield> and <structfield>height_mm</structfield> fields are only used internally during EDID parsing and should not be set when creating modes manually. @@ -2196,10 +2315,19 @@ void intel_crt_init(struct drm_device *dev) !Edrivers/gpu/drm/drm_flip_work.c </sect2> <sect2> - <title>VMA Offset Manager</title> -!Pdrivers/gpu/drm/drm_vma_manager.c vma offset manager -!Edrivers/gpu/drm/drm_vma_manager.c -!Iinclude/drm/drm_vma_manager.h + <title>HDMI Infoframes Helper Reference</title> + <para> + Strictly speaking this is not a DRM helper library but generally useable + by any driver interfacing with HDMI outputs like v4l or alsa drivers. + But it nicely fits into the overall topic of mode setting helper + libraries and hence is also included here. + </para> +!Iinclude/linux/hdmi.h +!Edrivers/video/hdmi.c + </sect2> + <sect2> + <title id="drm-kms-planehelpers">Plane Helper Reference</title> +!Edrivers/gpu/drm/drm_plane_helper.c Plane Helpers </sect2> </sect1> @@ -2561,42 +2689,44 @@ int num_ioctls;</synopsis> </para> </sect2> </sect1> - <sect1> - <title>Command submission & fencing</title> + <title>Legacy Support Code</title> <para> - This should cover a few device-specific command submission - implementations. + The section very brievely covers some of the old legacy support code which + is only used by old DRM drivers which have done a so-called shadow-attach + to the underlying device instead of registering as a real driver. This + also includes some of the old generic buffer mangement and command + submission code. Do not use any of this in new and modern drivers. </para> - </sect1> - - <!-- Internals: suspend/resume --> - <sect1> - <title>Suspend/Resume</title> - <para> - The DRM core provides some suspend/resume code, but drivers wanting full - suspend/resume support should provide save() and restore() functions. - These are called at suspend, hibernate, or resume time, and should perform - any state save or restore required by your device across suspend or - hibernate states. - </para> - <synopsis>int (*suspend) (struct drm_device *, pm_message_t state); -int (*resume) (struct drm_device *);</synopsis> - <para> - Those are legacy suspend and resume methods. New driver should use the - power management interface provided by their bus type (usually through - the struct <structname>device_driver</structname> dev_pm_ops) and set - these methods to NULL. - </para> - </sect1> + <sect2> + <title>Legacy Suspend/Resume</title> + <para> + The DRM core provides some suspend/resume code, but drivers wanting full + suspend/resume support should provide save() and restore() functions. + These are called at suspend, hibernate, or resume time, and should perform + any state save or restore required by your device across suspend or + hibernate states. + </para> + <synopsis>int (*suspend) (struct drm_device *, pm_message_t state); + int (*resume) (struct drm_device *);</synopsis> + <para> + Those are legacy suspend and resume methods which + <emphasis>only</emphasis> work with the legacy shadow-attach driver + registration functions. New driver should use the power management + interface provided by their bus type (usually through + the struct <structname>device_driver</structname> dev_pm_ops) and set + these methods to NULL. + </para> + </sect2> - <sect1> - <title>DMA services</title> - <para> - This should cover how DMA mapping etc. is supported by the core. - These functions are deprecated and should not be used. - </para> + <sect2> + <title>Legacy DMA Services</title> + <para> + This should cover how DMA mapping etc. is supported by the core. + These functions are deprecated and should not be used. + </para> + </sect2> </sect1> </chapter> @@ -2658,8 +2788,8 @@ int (*resume) (struct drm_device *);</synopsis> DRM core provides multiple character-devices for user-space to use. Depending on which device is opened, user-space can perform a different set of operations (mainly ioctls). The primary node is always created - and called <term>card<num></term>. Additionally, a currently - unused control node, called <term>controlD<num></term> is also + and called card<num>. Additionally, a currently + unused control node, called controlD<num> is also created. The primary node provides all legacy operations and historically was the only interface used by userspace. With KMS, the control node was introduced. However, the planned KMS control interface @@ -2674,21 +2804,21 @@ int (*resume) (struct drm_device *);</synopsis> nodes were introduced. Render nodes solely serve render clients, that is, no modesetting or privileged ioctls can be issued on render nodes. Only non-global rendering commands are allowed. If a driver supports - render nodes, it must advertise it via the <term>DRIVER_RENDER</term> + render nodes, it must advertise it via the DRIVER_RENDER DRM driver capability. If not supported, the primary node must be used for render clients together with the legacy drmAuth authentication procedure. </para> <para> If a driver advertises render node support, DRM core will create a - separate render node called <term>renderD<num></term>. There will + separate render node called renderD<num>. There will be one render node per device. No ioctls except PRIME-related ioctls - will be allowed on this node. Especially <term>GEM_OPEN</term> will be + will be allowed on this node. Especially GEM_OPEN will be explicitly prohibited. Render nodes are designed to avoid the buffer-leaks, which occur if clients guess the flink names or mmap offsets on the legacy interface. Additionally to this basic interface, drivers must mark their driver-dependent render-only ioctls as - <term>DRM_RENDER_ALLOW</term> so render clients can use them. Driver + DRM_RENDER_ALLOW so render clients can use them. Driver authors must be careful not to allow any privileged ioctls on render nodes. </para> @@ -2749,15 +2879,73 @@ int (*resume) (struct drm_device *);</synopsis> </sect1> </chapter> +</part> +<part id="drmDrivers"> + <title>DRM Drivers</title> - <!-- API reference --> + <partintro> + <para> + This second part of the DRM Developer's Guide documents driver code, + implementation details and also all the driver-specific userspace + interfaces. Especially since all hardware-acceleration interfaces to + userspace are driver specific for efficiency and other reasons these + interfaces can be rather substantial. Hence every driver has its own + chapter. + </para> + </partintro> - <appendix id="drmDriverApi"> - <title>DRM Driver API</title> + <chapter id="drmI915"> + <title>drm/i915 Intel GFX Driver</title> <para> - Include auto-generated API reference here (need to reference it - from paragraphs above too). + The drm/i915 driver supports all (with the exception of some very early + models) integrated GFX chipsets with both Intel display and rendering + blocks. This excludes a set of SoC platforms with an SGX rendering unit, + those have basic support through the gma500 drm driver. </para> - </appendix> + <sect1> + <title>Display Hardware Handling</title> + <para> + This section covers everything related to the display hardware including + the mode setting infrastructure, plane, sprite and cursor handling and + display, output probing and related topics. + </para> + <sect2> + <title>Mode Setting Infrastructure</title> + <para> + The i915 driver is thus far the only DRM driver which doesn't use the + common DRM helper code to implement mode setting sequences. Thus it + has its own tailor-made infrastructure for executing a display + configuration change. + </para> + </sect2> + <sect2> + <title>Plane Configuration</title> + <para> + This section covers plane configuration and composition with the + primary plane, sprites, cursors and overlays. This includes the + infrastructure to do atomic vsync'ed updates of all this state and + also tightly coupled topics like watermark setup and computation, + framebuffer compression and panel self refresh. + </para> + </sect2> + <sect2> + <title>Output Probing</title> + <para> + This section covers output probing and related infrastructure like the + hotplug interrupt storm detection and mitigation code. Note that the + i915 driver still uses most of the common DRM helper code for output + probing, so those sections fully apply. + </para> + </sect2> + </sect1> + <sect1> + <title>Memory Management and Command Submission</title> + <para> + This sections covers all things related to the GEM implementation in the + i915 driver. + </para> + </sect1> + </chapter> +</part> </book> diff --git a/Documentation/DocBook/kernel-hacking.tmpl b/Documentation/DocBook/kernel-hacking.tmpl index d0758b241b23..e84f09467cd7 100644 --- a/Documentation/DocBook/kernel-hacking.tmpl +++ b/Documentation/DocBook/kernel-hacking.tmpl @@ -671,7 +671,7 @@ printk(KERN_INFO "my ip: %pI4\n", &ipaddress); <sect1 id="routines-local-irqs"> <title><function>local_irq_save()</function>/<function>local_irq_restore()</function> - <filename class="headerfile">include/asm/system.h</filename> + <filename class="headerfile">include/linux/irqflags.h</filename> </title> <para> @@ -850,16 +850,6 @@ printk(KERN_INFO "my ip: %pI4\n", &ipaddress); <returnvalue>-ERESTARTSYS</returnvalue> if a signal is received. The <function>wait_event()</function> version ignores signals. </para> - <para> - Do not use the <function>sleep_on()</function> function family - - it is very easy to accidentally introduce races; almost certainly - one of the <function>wait_event()</function> family will do, or a - loop around <function>schedule_timeout()</function>. If you choose - to loop around <function>schedule_timeout()</function> remember - you must set the task state (with - <function>set_current_state()</function>) on each iteration to avoid - busy-looping. - </para> </sect1> diff --git a/Documentation/DocBook/media/dvb/demux.xml b/Documentation/DocBook/media/dvb/demux.xml index 86de89cfbd67..c8683d66f059 100644 --- a/Documentation/DocBook/media/dvb/demux.xml +++ b/Documentation/DocBook/media/dvb/demux.xml @@ -1042,7 +1042,14 @@ role="subsection"><title>DMX_ADD_PID</title> </para> <informaltable><tgroup cols="1"><tbody><row><entry align="char"> -<para>This ioctl is undocumented. Documentation is welcome.</para> +<para>This ioctl call allows to add multiple PIDs to a transport stream filter +previously set up with DMX_SET_PES_FILTER and output equal to DMX_OUT_TSDEMUX_TAP. +</para></entry></row><row><entry align="char"><para> +It is used by readers of /dev/dvb/adapterX/demuxY. +</para></entry></row><row><entry align="char"><para> +It may be called at any time, i.e. before or after the first filter on the +shared file descriptor was started. It makes it possible to record multiple +services without the need to de-multiplex or re-multiplex TS packets.</para> </entry> </row></tbody></tgroup></informaltable> <para>SYNOPSIS @@ -1075,7 +1082,7 @@ role="subsection"><title>DMX_ADD_PID</title> </para> </entry><entry align="char"> -<para>Undocumented.</para> +<para>PID number to be filtered.</para> </entry> </row></tbody></tgroup></informaltable> &return-value-dvb; @@ -1087,7 +1094,15 @@ role="subsection"><title>DMX_REMOVE_PID</title> </para> <informaltable><tgroup cols="1"><tbody><row><entry align="char"> -<para>This ioctl is undocumented. Documentation is welcome.</para> +<para>This ioctl call allows to remove a PID when multiple PIDs are set on a +transport stream filter, e. g. a filter previously set up with output equal to +DMX_OUT_TSDEMUX_TAP, created via either DMX_SET_PES_FILTER or DMX_ADD_PID. +</para></entry></row><row><entry align="char"><para> +It is used by readers of /dev/dvb/adapterX/demuxY. +</para></entry></row><row><entry align="char"><para> +It may be called at any time, i.e. before or after the first filter on the +shared file descriptor was started. It makes it possible to record multiple +services without the need to de-multiplex or re-multiplex TS packets.</para> </entry> </row></tbody></tgroup></informaltable> <para>SYNOPSIS @@ -1120,7 +1135,7 @@ role="subsection"><title>DMX_REMOVE_PID</title> </para> </entry><entry align="char"> -<para>Undocumented.</para> +<para>PID of the PES filter to be removed.</para> </entry> </row></tbody></tgroup></informaltable> &return-value-dvb; diff --git a/Documentation/DocBook/media/dvb/dvbapi.xml b/Documentation/DocBook/media/dvb/dvbapi.xml index 0197bcc7842d..4c15396c67e5 100644 --- a/Documentation/DocBook/media/dvb/dvbapi.xml +++ b/Documentation/DocBook/media/dvb/dvbapi.xml @@ -18,7 +18,7 @@ <firstname>Mauro</firstname> <othername role="mi">Carvalho</othername> <surname>Chehab</surname> -<affiliation><address><email>mchehab@redhat.com</email></address></affiliation> +<affiliation><address><email>m.chehab@samsung.com</email></address></affiliation> <contrib>Ported document to Docbook XML.</contrib> </author> </authorgroup> @@ -28,7 +28,7 @@ <holder>Convergence GmbH</holder> </copyright> <copyright> - <year>2009-2012</year> + <year>2009-2014</year> <holder>Mauro Carvalho Chehab</holder> </copyright> diff --git a/Documentation/DocBook/media/dvb/frontend.xml b/Documentation/DocBook/media/dvb/frontend.xml index 0d6e81bd9ed2..8a6a6ff27af5 100644 --- a/Documentation/DocBook/media/dvb/frontend.xml +++ b/Documentation/DocBook/media/dvb/frontend.xml @@ -744,7 +744,7 @@ typedef enum fe_hierarchy { </para> <informaltable><tgroup cols="1"><tbody><row><entry align="char"> -<para>int ioctl(int fd, int request = <link linkend="FE_READ_SNR">FE_READ_SNR</link>, int16_t +<para>int ioctl(int fd, int request = <link linkend="FE_READ_SNR">FE_READ_SNR</link>, uint16_t ⋆snr);</para> </entry> </row></tbody></tgroup></informaltable> @@ -766,7 +766,7 @@ typedef enum fe_hierarchy { </entry> </row><row><entry align="char"> -<para>int16_t *snr</para> +<para>uint16_t *snr</para> </entry><entry align="char"> <para>The signal-to-noise ratio is stored into *snr.</para> @@ -791,7 +791,7 @@ typedef enum fe_hierarchy { <informaltable><tgroup cols="1"><tbody><row><entry align="char"> <para>int ioctl( int fd, int request = - <link linkend="FE_READ_SIGNAL_STRENGTH">FE_READ_SIGNAL_STRENGTH</link>, int16_t ⋆strength);</para> + <link linkend="FE_READ_SIGNAL_STRENGTH">FE_READ_SIGNAL_STRENGTH</link>, uint16_t ⋆strength);</para> </entry> </row></tbody></tgroup></informaltable> @@ -814,7 +814,7 @@ typedef enum fe_hierarchy { </entry> </row><row><entry align="char"> -<para>int16_t *strength</para> +<para>uint16_t *strength</para> </entry><entry align="char"> <para>The signal strength value is stored into *strength.</para> diff --git a/Documentation/DocBook/media/v4l/common.xml b/Documentation/DocBook/media/v4l/common.xml index 1ddf354aa997..71f6bf9e735e 100644 --- a/Documentation/DocBook/media/v4l/common.xml +++ b/Documentation/DocBook/media/v4l/common.xml @@ -38,70 +38,41 @@ the basic concepts applicable to all devices.</para> <para>V4L2 drivers are implemented as kernel modules, loaded manually by the system administrator or automatically when a device is -first opened. The driver modules plug into the "videodev" kernel +first discovered. The driver modules plug into the "videodev" kernel module. It provides helper functions and a common application interface specified in this document.</para> <para>Each driver thus loaded registers one or more device nodes -with major number 81 and a minor number between 0 and 255. Assigning -minor numbers to V4L2 devices is entirely up to the system administrator, -this is primarily intended to solve conflicts between devices.<footnote> - <para>Access permissions are associated with character -device special files, hence we must ensure device numbers cannot -change with the module load order. To this end minor numbers are no -longer automatically assigned by the "videodev" module as in V4L but -requested by the driver. The defaults will suffice for most people -unless two drivers compete for the same minor numbers.</para> - </footnote> The module options to select minor numbers are named -after the device special file with a "_nr" suffix. For example "video_nr" -for <filename>/dev/video</filename> video capture devices. The number is -an offset to the base minor number associated with the device type. -<footnote> - <para>In earlier versions of the V4L2 API the module options -where named after the device special file with a "unit_" prefix, expressing -the minor number itself, not an offset. Rationale for this change is unknown. -Lastly the naming and semantics are just a convention among driver writers, -the point to note is that minor numbers are not supposed to be hardcoded -into drivers.</para> - </footnote> When the driver supports multiple devices of the same -type more than one minor number can be assigned, separated by commas: -<informalexample> +with major number 81 and a minor number between 0 and 255. Minor numbers +are allocated dynamically unless the kernel is compiled with the kernel +option CONFIG_VIDEO_FIXED_MINOR_RANGES. In that case minor numbers are +allocated in ranges depending on the device node type (video, radio, etc.).</para> + + <para>Many drivers support "video_nr", "radio_nr" or "vbi_nr" +module options to select specific video/radio/vbi node numbers. This allows +the user to request that the device node is named e.g. /dev/video5 instead +of leaving it to chance. When the driver supports multiple devices of the same +type more than one device node number can be assigned, separated by commas: + <informalexample> <screen> -> insmod mydriver.o video_nr=0,1 radio_nr=0,1</screen> +> modprobe mydriver video_nr=0,1 radio_nr=0,1</screen> </informalexample></para> <para>In <filename>/etc/modules.conf</filename> this may be written as: <informalexample> <screen> -alias char-major-81-0 mydriver -alias char-major-81-1 mydriver -alias char-major-81-64 mydriver <co id="alias" /> -options mydriver video_nr=0,1 radio_nr=0,1 <co id="options" /> +options mydriver video_nr=0,1 radio_nr=0,1 </screen> - <calloutlist> - <callout arearefs="alias"> - <para>When an application attempts to open a device -special file with major number 81 and minor number 0, 1, or 64, load -"mydriver" (and the "videodev" module it depends upon).</para> - </callout> - <callout arearefs="options"> - <para>Register the first two video capture devices with -minor number 0 and 1 (base number is 0), the first two radio device -with minor number 64 and 65 (base 64).</para> - </callout> - </calloutlist> - </informalexample> When no minor number is given as module -option the driver supplies a default. <xref linkend="devices" /> -recommends the base minor numbers to be used for the various device -types. Obviously minor numbers must be unique. When the number is -already in use the <emphasis>offending device</emphasis> will not be -registered. <!-- Blessed by Linus Torvalds on -linux-kernel@vger.kernel.org, 2002-11-20. --></para> - - <para>By convention system administrators create various -character device special files with these major and minor numbers in -the <filename>/dev</filename> directory. The names recommended for the -different V4L2 device types are listed in <xref linkend="devices" />. + </informalexample> When no device node number is given as module +option the driver supplies a default.</para> + + <para>Normally udev will create the device nodes in /dev automatically +for you. If udev is not installed, then you need to enable the +CONFIG_VIDEO_FIXED_MINOR_RANGES kernel option in order to be able to correctly +relate a minor number to a device node number. I.e., you need to be certain +that minor number 5 maps to device node name video5. With this kernel option +different device types have different minor number ranges. These ranges are +listed in <xref linkend="devices" />. </para> <para>The creation of character special files (with @@ -110,85 +81,66 @@ devices cannot be opened by major and minor number. That means applications cannot <emphasis>reliable</emphasis> scan for loaded or installed drivers. The user must enter a device name, or the application can try the conventional device names.</para> - - <para>Under the device filesystem (devfs) the minor number -options are ignored. V4L2 drivers (or by proxy the "videodev" module) -automatically create the required device files in the -<filename>/dev/v4l</filename> directory using the conventional device -names above.</para> </section> <section id="related"> <title>Related Devices</title> - <para>Devices can support several related functions. For example -video capturing, video overlay and VBI capturing are related because -these functions share, amongst other, the same video input and tuner -frequency. V4L and earlier versions of V4L2 used the same device name -and minor number for video capturing and overlay, but different ones -for VBI. Experience showed this approach has several problems<footnote> - <para>Given a device file name one cannot reliable find -related devices. For once names are arbitrary and in a system with -multiple devices, where only some support VBI capturing, a -<filename>/dev/video2</filename> is not necessarily related to -<filename>/dev/vbi2</filename>. The V4L -<constant>VIDIOCGUNIT</constant> ioctl would require a search for a -device file with a particular major and minor number.</para> - </footnote>, and to make things worse the V4L videodev module -used to prohibit multiple opens of a device.</para> - - <para>As a remedy the present version of the V4L2 API relaxed the -concept of device types with specific names and minor numbers. For -compatibility with old applications drivers must still register different -minor numbers to assign a default function to the device. But if related -functions are supported by the driver they must be available under all -registered minor numbers. The desired function can be selected after -opening the device as described in <xref linkend="devices" />.</para> - - <para>Imagine a driver supporting video capturing, video -overlay, raw VBI capturing, and FM radio reception. It registers three -devices with minor number 0, 64 and 224 (this numbering scheme is -inherited from the V4L API). Regardless if -<filename>/dev/video</filename> (81, 0) or -<filename>/dev/vbi</filename> (81, 224) is opened the application can -select any one of the video capturing, overlay or VBI capturing -functions. Without programming (e. g. reading from the device -with <application>dd</application> or <application>cat</application>) -<filename>/dev/video</filename> captures video images, while -<filename>/dev/vbi</filename> captures raw VBI data. -<filename>/dev/radio</filename> (81, 64) is invariable a radio device, -unrelated to the video functions. Being unrelated does not imply the -devices can be used at the same time, however. The &func-open; -function may very well return an &EBUSY;.</para> + <para>Devices can support several functions. For example +video capturing, VBI capturing and radio support.</para> + + <para>The V4L2 API creates different nodes for each of these functions.</para> + + <para>The V4L2 API was designed with the idea that one device node could support +all functions. However, in practice this never worked: this 'feature' +was never used by applications and many drivers did not support it and if +they did it was certainly never tested. In addition, switching a device +node between different functions only works when using the streaming I/O +API, not with the read()/write() API.</para> + + <para>Today each device node supports just one function.</para> <para>Besides video input or output the hardware may also support audio sampling or playback. If so, these functions are -implemented as OSS or ALSA PCM devices and eventually OSS or ALSA -audio mixer. The V4L2 API makes no provisions yet to find these -related devices. If you have an idea please write to the linux-media -mailing list: &v4l-ml;.</para> +implemented as ALSA PCM devices with optional ALSA audio mixer +devices.</para> + + <para>One problem with all these devices is that the V4L2 API +makes no provisions to find these related devices. Some really +complex devices use the Media Controller (see <xref linkend="media_controller" />) +which can be used for this purpose. But most drivers do not use it, +and while some code exists that uses sysfs to discover related devices +(see libmedia_dev in the <ulink url="http://git.linuxtv.org/v4l-utils/">v4l-utils</ulink> +git repository), there is no library yet that can provide a single API towards +both Media Controller-based devices and devices that do not use the Media Controller. +If you want to work on this please write to the linux-media mailing list: &v4l-ml;.</para> </section> <section> <title>Multiple Opens</title> - <para>In general, V4L2 devices can be opened more than once. + <para>V4L2 devices can be opened more than once.<footnote><para> +There are still some old and obscure drivers that have not been updated to +allow for multiple opens. This implies that for such drivers &func-open; can +return an &EBUSY; when the device is already in use.</para></footnote> When this is supported by the driver, users can for example start a "panel" application to change controls like brightness or audio volume, while another application captures video and audio. In other words, panel -applications are comparable to an OSS or ALSA audio mixer application. -When a device supports multiple functions like capturing and overlay -<emphasis>simultaneously</emphasis>, multiple opens allow concurrent -use of the device by forked processes or specialized applications.</para> - - <para>Multiple opens are optional, although drivers should -permit at least concurrent accesses without data exchange, &ie; panel -applications. This implies &func-open; can return an &EBUSY; when the -device is already in use, as well as &func-ioctl; functions initiating -data exchange (namely the &VIDIOC-S-FMT; ioctl), and the &func-read; -and &func-write; functions.</para> - - <para>Mere opening a V4L2 device does not grant exclusive +applications are comparable to an ALSA audio mixer application. +Just opening a V4L2 device should not change the state of the device.<footnote> +<para>Unfortunately, opening a radio device often switches the state of the +device to radio mode in many drivers. This behavior should be fixed eventually +as it violates the V4L2 specification.</para></footnote></para> + + <para>Once an application has allocated the memory buffers needed for +streaming data (by calling the &VIDIOC-REQBUFS; or &VIDIOC-CREATE-BUFS; ioctls, +or implicitly by calling the &func-read; or &func-write; functions) that +application (filehandle) becomes the owner of the device. It is no longer +allowed to make changes that would affect the buffer sizes (e.g. by calling +the &VIDIOC-S-FMT; ioctl) and other applications are no longer allowed to allocate +buffers or start or stop streaming. The &EBUSY; will be returned instead.</para> + + <para>Merely opening a V4L2 device does not grant exclusive access.<footnote> <para>Drivers could recognize the <constant>O_EXCL</constant> open flag. Presently this is not required, @@ -206,12 +158,7 @@ additional access privileges using the priority mechanism described in <para>V4L2 drivers should not support multiple applications reading or writing the same data stream on a device by copying buffers, time multiplexing or similar means. This is better handled by -a proxy application in user space. When the driver supports stream -sharing anyway it must be implemented transparently. The V4L2 API does -not specify how conflicts are solved. <!-- For example O_EXCL when the -application does not want to be preempted, PROT_READ mmapped buffers -which can be mapped twice, what happens when image formats do not -match etc.--></para> +a proxy application in user space.</para> </section> <section> @@ -240,15 +187,15 @@ methods</link> supported by the device.</para> <para>Starting with kernel version 3.1, VIDIOC-QUERYCAP will return the V4L2 API version used by the driver, with generally matches the Kernel version. -There's no need of using &VIDIOC-QUERYCAP; to check if an specific ioctl is -supported, the V4L2 core now returns ENOIOCTLCMD if a driver doesn't provide +There's no need of using &VIDIOC-QUERYCAP; to check if a specific ioctl is +supported, the V4L2 core now returns ENOTTY if a driver doesn't provide support for an ioctl.</para> <para>Other features can be queried by calling the respective ioctl, for example &VIDIOC-ENUMINPUT; to learn about the number, types and names of video connectors on the device. Although abstraction is a major objective of this API, the -ioctl also allows driver specific applications to reliable identify +&VIDIOC-QUERYCAP; ioctl also allows driver specific applications to reliably identify the driver.</para> <para>All V4L2 drivers must support @@ -278,9 +225,7 @@ Applications requiring a different priority will usually call the &VIDIOC-QUERYCAP; ioctl.</para> <para>Ioctls changing driver properties, such as &VIDIOC-S-INPUT;, -return an &EBUSY; after another application obtained higher priority. -An event mechanism to notify applications about asynchronous property -changes has been proposed but not added yet.</para> +return an &EBUSY; after another application obtained higher priority.</para> </section> <section id="video"> @@ -288,9 +233,9 @@ changes has been proposed but not added yet.</para> <para>Video inputs and outputs are physical connectors of a device. These can be for example RF connectors (antenna/cable), CVBS -a.k.a. Composite Video, S-Video or RGB connectors. Only video and VBI -capture devices have inputs, output devices have outputs, at least one -each. Radio devices have no video inputs or outputs.</para> +a.k.a. Composite Video, S-Video or RGB connectors. Video and VBI +capture devices have inputs. Video and VBI output devices have outputs, +at least one each. Radio devices have no video inputs or outputs.</para> <para>To learn about the number and attributes of the available inputs and outputs applications can enumerate them with the @@ -299,30 +244,13 @@ available inputs and outputs applications can enumerate them with the ioctl also contains signal status information applicable when the current video input is queried.</para> - <para>The &VIDIOC-G-INPUT; and &VIDIOC-G-OUTPUT; ioctl return the + <para>The &VIDIOC-G-INPUT; and &VIDIOC-G-OUTPUT; ioctls return the index of the current video input or output. To select a different input or output applications call the &VIDIOC-S-INPUT; and -&VIDIOC-S-OUTPUT; ioctl. Drivers must implement all the input ioctls +&VIDIOC-S-OUTPUT; ioctls. Drivers must implement all the input ioctls when the device has one or more inputs, all the output ioctls when the device has one or more outputs.</para> - <!-- - <figure id=io-tree> - <title>Input and output enumeration is the root of most device properties.</title> - <mediaobject> - <imageobject> - <imagedata fileref="links.pdf" format="ps" /> - </imageobject> - <imageobject> - <imagedata fileref="links.gif" format="gif" /> - </imageobject> - <textobject> - <phrase>Links between various device property structures.</phrase> - </textobject> - </mediaobject> - </figure> - --> - <example> <title>Information about the current video input</title> @@ -330,20 +258,20 @@ device has one or more outputs.</para> &v4l2-input; input; int index; -if (-1 == ioctl (fd, &VIDIOC-G-INPUT;, &index)) { - perror ("VIDIOC_G_INPUT"); - exit (EXIT_FAILURE); +if (-1 == ioctl(fd, &VIDIOC-G-INPUT;, &index)) { + perror("VIDIOC_G_INPUT"); + exit(EXIT_FAILURE); } -memset (&input, 0, sizeof (input)); +memset(&input, 0, sizeof(input)); input.index = index; -if (-1 == ioctl (fd, &VIDIOC-ENUMINPUT;, &input)) { - perror ("VIDIOC_ENUMINPUT"); - exit (EXIT_FAILURE); +if (-1 == ioctl(fd, &VIDIOC-ENUMINPUT;, &input)) { + perror("VIDIOC_ENUMINPUT"); + exit(EXIT_FAILURE); } -printf ("Current input: %s\n", input.name); +printf("Current input: %s\n", input.name); </programlisting> </example> @@ -355,9 +283,9 @@ int index; index = 0; -if (-1 == ioctl (fd, &VIDIOC-S-INPUT;, &index)) { - perror ("VIDIOC_S_INPUT"); - exit (EXIT_FAILURE); +if (-1 == ioctl(fd, &VIDIOC-S-INPUT;, &index)) { + perror("VIDIOC_S_INPUT"); + exit(EXIT_FAILURE); } </programlisting> </example> @@ -397,7 +325,7 @@ available inputs and outputs applications can enumerate them with the also contains signal status information applicable when the current audio input is queried.</para> - <para>The &VIDIOC-G-AUDIO; and &VIDIOC-G-AUDOUT; ioctl report + <para>The &VIDIOC-G-AUDIO; and &VIDIOC-G-AUDOUT; ioctls report the current audio input and output, respectively. Note that, unlike &VIDIOC-G-INPUT; and &VIDIOC-G-OUTPUT; these ioctls return a structure as <constant>VIDIOC_ENUMAUDIO</constant> and @@ -408,11 +336,11 @@ applications call the &VIDIOC-S-AUDIO; ioctl. To select an audio output (which presently has no changeable properties) applications call the &VIDIOC-S-AUDOUT; ioctl.</para> - <para>Drivers must implement all input ioctls when the device -has one or more inputs, all output ioctls when the device has one -or more outputs. When the device has any audio inputs or outputs the -driver must set the <constant>V4L2_CAP_AUDIO</constant> flag in the -&v4l2-capability; returned by the &VIDIOC-QUERYCAP; ioctl.</para> + <para>Drivers must implement all audio input ioctls when the device +has multiple selectable audio inputs, all audio output ioctls when the +device has multiple selectable audio outputs. When the device has any +audio inputs or outputs the driver must set the <constant>V4L2_CAP_AUDIO</constant> +flag in the &v4l2-capability; returned by the &VIDIOC-QUERYCAP; ioctl.</para> <example> <title>Information about the current audio input</title> @@ -420,14 +348,14 @@ driver must set the <constant>V4L2_CAP_AUDIO</constant> flag in the <programlisting> &v4l2-audio; audio; -memset (&audio, 0, sizeof (audio)); +memset(&audio, 0, sizeof(audio)); -if (-1 == ioctl (fd, &VIDIOC-G-AUDIO;, &audio)) { - perror ("VIDIOC_G_AUDIO"); - exit (EXIT_FAILURE); +if (-1 == ioctl(fd, &VIDIOC-G-AUDIO;, &audio)) { + perror("VIDIOC_G_AUDIO"); + exit(EXIT_FAILURE); } -printf ("Current input: %s\n", audio.name); +printf("Current input: %s\n", audio.name); </programlisting> </example> @@ -437,13 +365,13 @@ printf ("Current input: %s\n", audio.name); <programlisting> &v4l2-audio; audio; -memset (&audio, 0, sizeof (audio)); /* clear audio.mode, audio.reserved */ +memset(&audio, 0, sizeof(audio)); /* clear audio.mode, audio.reserved */ audio.index = 0; -if (-1 == ioctl (fd, &VIDIOC-S-AUDIO;, &audio)) { - perror ("VIDIOC_S_AUDIO"); - exit (EXIT_FAILURE); +if (-1 == ioctl(fd, &VIDIOC-S-AUDIO;, &audio)) { + perror("VIDIOC_S_AUDIO"); + exit(EXIT_FAILURE); } </programlisting> </example> @@ -468,7 +396,7 @@ the tuner.</para> video inputs.</para> <para>To query and change tuner properties applications use the -&VIDIOC-G-TUNER; and &VIDIOC-S-TUNER; ioctl, respectively. The +&VIDIOC-G-TUNER; and &VIDIOC-S-TUNER; ioctls, respectively. The &v4l2-tuner; returned by <constant>VIDIOC_G_TUNER</constant> also contains signal status information applicable when the tuner of the current video or radio input is queried. Note that @@ -533,7 +461,7 @@ standards or variations of standards. Each video input and output may support another set of standards. This set is reported by the <structfield>std</structfield> field of &v4l2-input; and &v4l2-output; returned by the &VIDIOC-ENUMINPUT; and -&VIDIOC-ENUMOUTPUT; ioctl, respectively.</para> +&VIDIOC-ENUMOUTPUT; ioctls, respectively.</para> <para>V4L2 defines one bit for each analog video standard currently in use worldwide, and sets aside bits for driver defined @@ -564,28 +492,10 @@ 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 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 -&v4l2-output; <structfield>std</structfield> field would be a set of -indices like <structfield>audioset</structfield>.</para> - <para>Indices are consistent with the rest of the API -and identify the standard unambiguously. In the present scheme of -things an enumerated standard is looked up by &v4l2-std-id;. Now the -standards supported by the inputs of a device can overlap. Just -assume the tuner and composite input in the example above both -exist on a device. An enumeration of "PAL-B/G", "PAL-H/I" suggests -a choice which does not exist. We cannot merge or omit sets, because -applications would be unable to find the standards reported by -<constant>VIDIOC_G_STD</constant>. That leaves separate enumerations -for each input. Also selecting a standard by &v4l2-std-id; can be -ambiguous. Advantage of this method is that applications need not -identify the standard indirectly, after enumerating.</para><para>So in -summary, the lookup itself is unavoidable. The difference is only -whether the lookup is necessary to find an enumerated standard or to -switch to a standard by &v4l2-std-id;.</para> - </footnote> Drivers must implement all video standard ioctls +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. Drivers must implement all video standard ioctls when the device has one or more video inputs or outputs.</para> <para>Special rules apply to devices such as USB cameras where the notion of video @@ -604,17 +514,10 @@ 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 -&ENOTTY;.<footnote> - <para>See <xref linkend="buffer" /> for a rationale.</para> +&ENOTTY; or the &EINVAL;.</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> - - <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 -up to normal expectations, instead of this exception.</para> - </footnote></para> +can be used with the given input or output.</para> <example> <title>Information about the current video standard</title> @@ -623,22 +526,22 @@ up to normal expectations, instead of this exception.</para> &v4l2-std-id; std_id; &v4l2-standard; standard; -if (-1 == ioctl (fd, &VIDIOC-G-STD;, &std_id)) { +if (-1 == ioctl(fd, &VIDIOC-G-STD;, &std_id)) { /* Note when VIDIOC_ENUMSTD always returns ENOTTY this is no video device or it falls under the USB exception, and VIDIOC_G_STD returning ENOTTY is no error. */ - perror ("VIDIOC_G_STD"); - exit (EXIT_FAILURE); + perror("VIDIOC_G_STD"); + exit(EXIT_FAILURE); } -memset (&standard, 0, sizeof (standard)); +memset(&standard, 0, sizeof(standard)); standard.index = 0; -while (0 == ioctl (fd, &VIDIOC-ENUMSTD;, &standard)) { +while (0 == ioctl(fd, &VIDIOC-ENUMSTD;, &standard)) { if (standard.id & std_id) { - printf ("Current video standard: %s\n", standard.name); - exit (EXIT_SUCCESS); + printf("Current video standard: %s\n", standard.name); + exit(EXIT_SUCCESS); } standard.index++; @@ -648,8 +551,8 @@ while (0 == ioctl (fd, &VIDIOC-ENUMSTD;, &standard)) { empty unless this device falls under the USB exception. */ if (errno == EINVAL || standard.index == 0) { - perror ("VIDIOC_ENUMSTD"); - exit (EXIT_FAILURE); + perror("VIDIOC_ENUMSTD"); + exit(EXIT_FAILURE); } </programlisting> </example> @@ -662,26 +565,26 @@ input</title> &v4l2-input; input; &v4l2-standard; standard; -memset (&input, 0, sizeof (input)); +memset(&input, 0, sizeof(input)); -if (-1 == ioctl (fd, &VIDIOC-G-INPUT;, &input.index)) { - perror ("VIDIOC_G_INPUT"); - exit (EXIT_FAILURE); +if (-1 == ioctl(fd, &VIDIOC-G-INPUT;, &input.index)) { + perror("VIDIOC_G_INPUT"); + exit(EXIT_FAILURE); } -if (-1 == ioctl (fd, &VIDIOC-ENUMINPUT;, &input)) { - perror ("VIDIOC_ENUM_INPUT"); - exit (EXIT_FAILURE); +if (-1 == ioctl(fd, &VIDIOC-ENUMINPUT;, &input)) { + perror("VIDIOC_ENUM_INPUT"); + exit(EXIT_FAILURE); } -printf ("Current input %s supports:\n", input.name); +printf("Current input %s supports:\n", input.name); -memset (&standard, 0, sizeof (standard)); +memset(&standard, 0, sizeof(standard)); standard.index = 0; -while (0 == ioctl (fd, &VIDIOC-ENUMSTD;, &standard)) { +while (0 == ioctl(fd, &VIDIOC-ENUMSTD;, &standard)) { if (standard.id & input.std) - printf ("%s\n", standard.name); + printf("%s\n", standard.name); standard.index++; } @@ -690,8 +593,8 @@ while (0 == ioctl (fd, &VIDIOC-ENUMSTD;, &standard)) { empty unless this device falls under the USB exception. */ if (errno != EINVAL || standard.index == 0) { - perror ("VIDIOC_ENUMSTD"); - exit (EXIT_FAILURE); + perror("VIDIOC_ENUMSTD"); + exit(EXIT_FAILURE); } </programlisting> </example> @@ -703,21 +606,21 @@ if (errno != EINVAL || standard.index == 0) { &v4l2-input; input; &v4l2-std-id; std_id; -memset (&input, 0, sizeof (input)); +memset(&input, 0, sizeof(input)); -if (-1 == ioctl (fd, &VIDIOC-G-INPUT;, &input.index)) { - perror ("VIDIOC_G_INPUT"); - exit (EXIT_FAILURE); +if (-1 == ioctl(fd, &VIDIOC-G-INPUT;, &input.index)) { + perror("VIDIOC_G_INPUT"); + exit(EXIT_FAILURE); } -if (-1 == ioctl (fd, &VIDIOC-ENUMINPUT;, &input)) { - perror ("VIDIOC_ENUM_INPUT"); - exit (EXIT_FAILURE); +if (-1 == ioctl(fd, &VIDIOC-ENUMINPUT;, &input)) { + perror("VIDIOC_ENUM_INPUT"); + exit(EXIT_FAILURE); } if (0 == (input.std & V4L2_STD_PAL_BG)) { - fprintf (stderr, "Oops. B/G PAL is not supported.\n"); - exit (EXIT_FAILURE); + fprintf(stderr, "Oops. B/G PAL is not supported.\n"); + exit(EXIT_FAILURE); } /* Note this is also supposed to work when only B @@ -725,9 +628,9 @@ if (0 == (input.std & V4L2_STD_PAL_BG)) { std_id = V4L2_STD_PAL_BG; -if (-1 == ioctl (fd, &VIDIOC-S-STD;, &std_id)) { - perror ("VIDIOC_S_STD"); - exit (EXIT_FAILURE); +if (-1 == ioctl(fd, &VIDIOC-S-STD;, &std_id)) { + perror("VIDIOC_S_STD"); + exit(EXIT_FAILURE); } </programlisting> </example> @@ -740,26 +643,25 @@ corresponding video timings. Today there are many more different hardware interf such as High Definition TV interfaces (HDMI), VGA, DVI connectors etc., that carry video signals and there is a need to extend the API to select the video timings for these interfaces. Since it is not possible to extend the &v4l2-std-id; due to -the limited bits available, a new set of IOCTLs was added to set/get video timings at -the input and output: </para><itemizedlist> - <listitem> - <para>DV Timings: This will allow applications to define detailed -video timings for the interface. This includes parameters such as width, height, -polarities, frontporch, backporch etc. The <filename>linux/v4l2-dv-timings.h</filename> +the limited bits available, a new set of ioctls was added to set/get video timings at +the input and output.</para> + + <para>These ioctls deal with the detailed digital video timings that define +each video format. This includes parameters such as the active video width and height, +signal polarities, frontporches, backporches, sync widths etc. 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> - </listitem> - </itemizedlist> - <para>To enumerate and query the attributes of the DV timings supported by a device, + + <para>To enumerate and query the attributes of the DV timings supported by a device applications use the &VIDIOC-ENUM-DV-TIMINGS; and &VIDIOC-DV-TIMINGS-CAP; ioctls. - To set DV timings for the device, applications use the + To set DV timings for the device applications use the &VIDIOC-S-DV-TIMINGS; ioctl and to get current DV timings they use the &VIDIOC-G-DV-TIMINGS; ioctl. To detect the DV timings as seen by the video receiver applications use the &VIDIOC-QUERY-DV-TIMINGS; ioctl.</para> <para>Applications can make use of the <xref linkend="input-capabilities" /> and -<xref linkend="output-capabilities"/> flags to decide what ioctls are available to set the -video timings for the device.</para> +<xref linkend="output-capabilities"/> flags to determine whether the digital video ioctls +can be used with the given input or output.</para> </section> &sub-controls; diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index 86c6dd2f6b8a..eee6f0f4aa43 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2535,6 +2535,16 @@ fields changed from _s32 to _u32. </orderedlist> </section> + <section> + <title>V4L2 in Linux 3.15</title> + <orderedlist> + <listitem> + <para>Added Software Defined Radio (SDR) Interface. + </para> + </listitem> + </orderedlist> + </section> + <section id="other"> <title>Relation of V4L2 to other Linux multimedia APIs</title> @@ -2651,6 +2661,9 @@ ioctls.</para> <listitem> <para>Exporting DMABUF files using &VIDIOC-EXPBUF; ioctl.</para> </listitem> + <listitem> + <para>Software Defined Radio (SDR) Interface, <xref linkend="sdr" />.</para> + </listitem> </itemizedlist> </section> diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index a5a3188e5af7..47198eef75a4 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -2258,6 +2258,26 @@ Applicable to the MPEG1, MPEG2, MPEG4 encoders.</entry> VBV buffer control.</entry> </row> + <row><entry></entry></row> + <row id="v4l2-mpeg-video-hor-search-range"> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE</constant> </entry> + <entry>integer</entry> + </row> + <row><entry spanname="descr">Horizontal search range defines maximum horizontal search area in pixels +to search and match for the present Macroblock (MB) in the reference picture. This V4L2 control macro is used to set +horizontal search range for motion estimation module in video encoder.</entry> + </row> + + <row><entry></entry></row> + <row id="v4l2-mpeg-video-vert-search-range"> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE</constant> </entry> + <entry>integer</entry> + </row> + <row><entry spanname="descr">Vertical search range defines maximum vertical search area in pixels +to search and match for the present Macroblock (MB) in the reference picture. This V4L2 control macro is used to set +vertical search range for motion estimation module in video encoder.</entry> + </row> + <row><entry></entry></row> <row> <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE</constant> </entry> @@ -4370,6 +4390,24 @@ interface and may change in the future.</para> <entry>The flash controller has detected a short or open circuit condition on the indicator LED.</entry> </row> + <row> + <entry><constant>V4L2_FLASH_FAULT_UNDER_VOLTAGE</constant></entry> + <entry>Flash controller voltage to the flash LED + has been below the minimum limit specific to the flash + controller.</entry> + </row> + <row> + <entry><constant>V4L2_FLASH_FAULT_INPUT_VOLTAGE</constant></entry> + <entry>The input voltage of the flash controller is below + the limit under which strobing the flash at full current + will not be possible.The condition persists until this flag + is no longer set.</entry> + </row> + <row> + <entry><constant>V4L2_FLASH_FAULT_LED_OVER_TEMPERATURE</constant></entry> + <entry>The temperature of the LED has exceeded its + allowed upper limit.</entry> + </row> </tbody> </entrytbl> </row> @@ -4971,4 +5009,142 @@ defines possible values for de-emphasis. Here they are:</entry> </table> </section> + + <section id="rf-tuner-controls"> + <title>RF Tuner Control Reference</title> + + <para> +The RF Tuner (RF_TUNER) class includes controls for common features of devices +having RF tuner. + </para> + <para> +In this context, RF tuner is radio receiver circuit between antenna and +demodulator. It receives radio frequency (RF) from the antenna and converts that +received signal to lower intermediate frequency (IF) or baseband frequency (BB). +Tuners that could do baseband output are often called Zero-IF tuners. Older +tuners were typically simple PLL tuners inside a metal box, whilst newer ones +are highly integrated chips without a metal box "silicon tuners". These controls +are mostly applicable for new feature rich silicon tuners, just because older +tuners does not have much adjustable features. + </para> + <para> +For more information about RF tuners see +<ulink url="http://en.wikipedia.org/wiki/Tuner_%28radio%29">Tuner (radio)</ulink> +and +<ulink url="http://en.wikipedia.org/wiki/RF_front_end">RF front end</ulink> +from Wikipedia. + </para> + + <table pgwide="1" frame="none" id="rf-tuner-control-id"> + <title>RF_TUNER 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_RF_TUNER_CLASS</constant> </entry> + <entry>class</entry> + </row><row><entry spanname="descr">The RF_TUNER class +descriptor. Calling &VIDIOC-QUERYCTRL; for this control will return a +description of this control class.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RF_TUNER_BANDWIDTH_AUTO</constant> </entry> + <entry>boolean</entry> + </row> + <row> + <entry spanname="descr">Enables/disables tuner radio channel +bandwidth configuration. In automatic mode bandwidth configuration is performed +by the driver.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RF_TUNER_BANDWIDTH</constant> </entry> + <entry>integer</entry> + </row> + <row> + <entry spanname="descr">Filter(s) on tuner signal path are used to +filter signal according to receiving party needs. Driver configures filters to +fulfill desired bandwidth requirement. Used when V4L2_CID_RF_TUNER_BANDWIDTH_AUTO is not +set. Unit is in Hz. The range and step are driver-specific.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RF_TUNER_LNA_GAIN_AUTO</constant> </entry> + <entry>boolean</entry> + </row> + <row> + <entry spanname="descr">Enables/disables LNA automatic gain control (AGC)</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RF_TUNER_MIXER_GAIN_AUTO</constant> </entry> + <entry>boolean</entry> + </row> + <row> + <entry spanname="descr">Enables/disables mixer automatic gain control (AGC)</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RF_TUNER_IF_GAIN_AUTO</constant> </entry> + <entry>boolean</entry> + </row> + <row> + <entry spanname="descr">Enables/disables IF automatic gain control (AGC)</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RF_TUNER_LNA_GAIN</constant> </entry> + <entry>integer</entry> + </row> + <row> + <entry spanname="descr">LNA (low noise amplifier) gain is first +gain stage on the RF tuner signal path. It is located very close to tuner +antenna input. Used when <constant>V4L2_CID_RF_TUNER_LNA_GAIN_AUTO</constant> is not set. +The range and step are driver-specific.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RF_TUNER_MIXER_GAIN</constant> </entry> + <entry>integer</entry> + </row> + <row> + <entry spanname="descr">Mixer gain is second gain stage on the RF +tuner signal path. It is located inside mixer block, where RF signal is +down-converted by the mixer. Used when <constant>V4L2_CID_RF_TUNER_MIXER_GAIN_AUTO</constant> +is not set. The range and step are driver-specific.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RF_TUNER_IF_GAIN</constant> </entry> + <entry>integer</entry> + </row> + <row> + <entry spanname="descr">IF gain is last gain stage on the RF tuner +signal path. It is located on output of RF tuner. It controls signal level of +intermediate frequency output or baseband output. Used when +<constant>V4L2_CID_RF_TUNER_IF_GAIN_AUTO</constant> is not set. The range and step are +driver-specific.</entry> + </row> + <row> + <entry spanname="id"><constant>V4L2_CID_RF_TUNER_PLL_LOCK</constant> </entry> + <entry>boolean</entry> + </row> + <row> + <entry spanname="descr">Is synthesizer PLL locked? RF tuner is +receiving given frequency when that control is set. This is a read-only control. +</entry> + </row> + </tbody> + </tgroup> + </table> + </section> </section> diff --git a/Documentation/DocBook/media/v4l/dev-osd.xml b/Documentation/DocBook/media/v4l/dev-osd.xml index dd91d6134e8c..54853329140b 100644 --- a/Documentation/DocBook/media/v4l/dev-osd.xml +++ b/Documentation/DocBook/media/v4l/dev-osd.xml @@ -56,18 +56,18 @@ framebuffer device.</para> unsigned int i; int fb_fd; -if (-1 == ioctl (fd, VIDIOC_G_FBUF, &fbuf)) { - perror ("VIDIOC_G_FBUF"); - exit (EXIT_FAILURE); +if (-1 == ioctl(fd, VIDIOC_G_FBUF, &fbuf)) { + perror("VIDIOC_G_FBUF"); + exit(EXIT_FAILURE); } -for (i = 0; i > 30; ++i) { +for (i = 0; i < 30; i++) { char dev_name[16]; struct fb_fix_screeninfo si; - snprintf (dev_name, sizeof (dev_name), "/dev/fb%u", i); + snprintf(dev_name, sizeof(dev_name), "/dev/fb%u", i); - fb_fd = open (dev_name, O_RDWR); + fb_fd = open(dev_name, O_RDWR); if (-1 == fb_fd) { switch (errno) { case ENOENT: /* no such file */ @@ -75,19 +75,19 @@ for (i = 0; i > 30; ++i) { continue; default: - perror ("open"); - exit (EXIT_FAILURE); + perror("open"); + exit(EXIT_FAILURE); } } - if (0 == ioctl (fb_fd, FBIOGET_FSCREENINFO, &si)) { - if (si.smem_start == (unsigned long) fbuf.base) + if (0 == ioctl(fb_fd, FBIOGET_FSCREENINFO, &si)) { + if (si.smem_start == (unsigned long)fbuf.base) break; } else { /* Apparently not a framebuffer device. */ } - close (fb_fd); + close(fb_fd); fb_fd = -1; } diff --git a/Documentation/DocBook/media/v4l/dev-sdr.xml b/Documentation/DocBook/media/v4l/dev-sdr.xml new file mode 100644 index 000000000000..dc14804f5436 --- /dev/null +++ b/Documentation/DocBook/media/v4l/dev-sdr.xml @@ -0,0 +1,110 @@ + <title>Software Defined Radio Interface (SDR)</title> + + <note> + <title>Experimental</title> + <para>This is an <link linkend="experimental"> experimental </link> + interface and may change in the future.</para> + </note> + + <para> +SDR is an abbreviation of Software Defined Radio, the radio device +which uses application software for modulation or demodulation. This interface +is intended for controlling and data streaming of such devices. + </para> + + <para> +SDR devices are accessed through character device special files named +<filename>/dev/swradio0</filename> to <filename>/dev/swradio255</filename> +with major number 81 and dynamically allocated minor numbers 0 to 255. + </para> + + <section> + <title>Querying Capabilities</title> + + <para> +Devices supporting the SDR receiver interface set the +<constant>V4L2_CAP_SDR_CAPTURE</constant> and +<constant>V4L2_CAP_TUNER</constant> flag in the +<structfield>capabilities</structfield> field of &v4l2-capability; +returned by the &VIDIOC-QUERYCAP; ioctl. That flag means the device has an +Analog to Digital Converter (ADC), which is a mandatory element for the SDR receiver. +At least one of the read/write, streaming or asynchronous I/O methods must +be supported. + </para> + </section> + + <section> + <title>Supplemental Functions</title> + + <para> +SDR devices can support <link linkend="control">controls</link>, and must +support the <link linkend="tuner">tuner</link> ioctls. Tuner ioctls are used +for setting the ADC sampling rate (sampling frequency) and the possible RF tuner +frequency. + </para> + + <para> +The <constant>V4L2_TUNER_ADC</constant> tuner type is used for ADC tuners, and +the <constant>V4L2_TUNER_RF</constant> tuner type is used for RF tuners. The +tuner index of the RF tuner (if any) must always follow the ADC tuner index. +Normally the ADC tuner is #0 and the RF tuner is #1. + </para> + + <para> +The &VIDIOC-S-HW-FREQ-SEEK; ioctl is not supported. + </para> + </section> + + <section> + <title>Data Format Negotiation</title> + + <para> +The SDR capture device uses the <link linkend="format">format</link> ioctls to +select the capture format. Both the sampling resolution and the data streaming +format are bound to that selectable format. In addition to the basic +<link linkend="format">format</link> ioctls, the &VIDIOC-ENUM-FMT; ioctl +must be supported as well. + </para> + + <para> +To use the <link linkend="format">format</link> ioctls applications set the +<structfield>type</structfield> field of a &v4l2-format; to +<constant>V4L2_BUF_TYPE_SDR_CAPTURE</constant> and use the &v4l2-sdr-format; +<structfield>sdr</structfield> member of the <structfield>fmt</structfield> +union as needed per the desired operation. +Currently only the <structfield>pixelformat</structfield> field of +&v4l2-sdr-format; is used. The content of that field is the V4L2 fourcc code +of the data format. + </para> + + <table pgwide="1" frame="none" id="v4l2-sdr-format"> + <title>struct <structname>v4l2_sdr_format</structname></title> + <tgroup cols="3"> + &cs-str; + <tbody valign="top"> + <row> + <entry>__u32</entry> + <entry><structfield>pixelformat</structfield></entry> + <entry> +The data format or type of compression, set by the application. This is a +little endian <link linkend="v4l2-fourcc">four character code</link>. +V4L2 defines SDR formats in <xref linkend="sdr-formats" />. + </entry> + </row> + <row> + <entry>__u8</entry> + <entry><structfield>reserved[28]</structfield></entry> + <entry>This array is reserved for future extensions. +Drivers and applications must set it to zero.</entry> + </row> + </tbody> + </tgroup> + </table> + + <para> +An SDR device may support <link linkend="rw">read/write</link> +and/or streaming (<link linkend="mmap">memory mapping</link> +or <link linkend="userp">user pointer</link>) I/O. + </para> + + </section> diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 2c4c068dde83..97a69bf6f3eb 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -339,8 +339,8 @@ returns immediately with an &EAGAIN; when no buffer is available. The queues as a side effect. Since there is no notion of doing anything "now" on a multitasking system, if an application needs to synchronize with another event it should examine the &v4l2-buffer; -<structfield>timestamp</structfield> of captured buffers, or set the -field before enqueuing buffers for output.</para> +<structfield>timestamp</structfield> of captured or outputted buffers. +</para> <para>Drivers implementing memory mapping I/O must support the <constant>VIDIOC_REQBUFS</constant>, @@ -457,7 +457,7 @@ queues and unlocks all buffers as a side effect. Since there is no notion of doing anything "now" on a multitasking system, if an application needs to synchronize with another event it should examine the &v4l2-buffer; <structfield>timestamp</structfield> of captured -buffers, or set the field before enqueuing buffers for output.</para> +or outputted buffers.</para> <para>Drivers implementing user pointer I/O must support the <constant>VIDIOC_REQBUFS</constant>, @@ -620,8 +620,7 @@ returns immediately with an &EAGAIN; when no buffer is available. The unlocks all buffers as a side effect. Since there is no notion of doing anything "now" on a multitasking system, if an application needs to synchronize with another event it should examine the &v4l2-buffer; -<structfield>timestamp</structfield> of captured buffers, or set the field -before enqueuing buffers for output.</para> +<structfield>timestamp</structfield> of captured or outputted buffers.</para> <para>Drivers implementing DMABUF importing I/O must support the <constant>VIDIOC_REQBUFS</constant>, <constant>VIDIOC_QBUF</constant>, @@ -654,38 +653,19 @@ plane, are stored in struct <structname>v4l2_plane</structname> instead. In that case, struct <structname>v4l2_buffer</structname> contains an array of plane structures.</para> - <para>Nominally timestamps refer to the first data byte transmitted. -In practice however the wide range of hardware covered by the V4L2 API -limits timestamp accuracy. Often an interrupt routine will -sample the system clock shortly after the field or frame was stored -completely in memory. So applications must expect a constant -difference up to one field or frame period plus a small (few scan -lines) random error. The delay and error can be much -larger due to compression or transmission over an external bus when -the frames are not properly stamped by the sender. This is frequently -the case with USB cameras. Here timestamps refer to the instant the -field or frame was received by the driver, not the capture time. These -devices identify by not enumerating any video standards, see <xref -linkend="standard" />.</para> - - <para>Similar limitations apply to output timestamps. Typically -the video hardware locks to a clock controlling the video timing, the -horizontal and vertical synchronization pulses. At some point in the -line sequence, possibly the vertical blanking, an interrupt routine -samples the system clock, compares against the timestamp and programs -the hardware to repeat the previous field or frame, or to display the -buffer contents.</para> - - <para>Apart of limitations of the video device and natural -inaccuracies of all clocks, it should be noted system time itself is -not perfectly stable. It can be affected by power saving cycles, -warped to insert leap seconds, or even turned back or forth by the -system administrator affecting long term measurements. <footnote> - <para>Since no other Linux multimedia -API supports unadjusted time it would be foolish to introduce here. We -must use a universally supported clock to synchronize different media, -hence time of day.</para> - </footnote></para> + <para>Dequeued video buffers come with timestamps. The driver + decides at which part of the frame and with which clock the + timestamp is taken. Please see flags in the masks + <constant>V4L2_BUF_FLAG_TIMESTAMP_MASK</constant> and + <constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant> in <xref + linkend="buffer-flags" />. These flags are always valid and constant + across all buffers during the whole video stream. Changes in these + flags may take place as a side effect of &VIDIOC-S-INPUT; or + &VIDIOC-S-OUTPUT; however. The + <constant>V4L2_BUF_FLAG_TIMESTAMP_COPY</constant> timestamp type + which is used by e.g. on mem-to-mem devices is an exception to the + rule: the timestamp source flags are copied from the OUTPUT video + buffer to the CAPTURE video buffer.</para> <table frame="none" pgwide="1" id="v4l2-buffer"> <title>struct <structname>v4l2_buffer</structname></title> @@ -696,10 +676,11 @@ hence time of day.</para> <entry>__u32</entry> <entry><structfield>index</structfield></entry> <entry></entry> - <entry>Number of the buffer, set by the application. This -field is only used for <link linkend="mmap">memory mapping</link> I/O -and can range from zero to the number of buffers allocated -with the &VIDIOC-REQBUFS; ioctl (&v4l2-requestbuffers; <structfield>count</structfield>) minus one.</entry> + <entry>Number of the buffer, set by the application except +when calling &VIDIOC-DQBUF;, then it is set by the driver. +This field can range from zero to the number of buffers allocated +with the &VIDIOC-REQBUFS; ioctl (&v4l2-requestbuffers; <structfield>count</structfield>), +plus any buffers allocated with &VIDIOC-CREATE-BUFS; minus one.</entry> </row> <row> <entry>__u32</entry> @@ -718,7 +699,7 @@ linkend="v4l2-buf-type" /></entry> buffer. It depends on the negotiated data format and may change with each buffer for compressed variable size data like JPEG images. Drivers must set this field when <structfield>type</structfield> -refers to an input stream, applications when an output stream.</entry> +refers to an input stream, applications when it refers to an output stream.</entry> </row> <row> <entry>__u32</entry> @@ -735,7 +716,7 @@ linkend="buffer-flags" />.</entry> buffer, see <xref linkend="v4l2-field" />. This field is not used when the buffer contains VBI data. Drivers must set it when <structfield>type</structfield> refers to an input stream, -applications when an output stream.</entry> +applications when it refers to an output stream.</entry> </row> <row> <entry>struct timeval</entry> @@ -745,15 +726,13 @@ applications when an output stream.</entry> byte was captured, as returned by the <function>clock_gettime()</function> function for the relevant clock id; see <constant>V4L2_BUF_FLAG_TIMESTAMP_*</constant> in - <xref linkend="buffer-flags" />. For output streams the data - will not be displayed before this time, secondary to the nominal - frame rate determined by the current video standard in enqueued - order. Applications can for example zero this field to display - frames as soon as possible. The driver stores the time at which - the first data byte was actually sent out in the - <structfield>timestamp</structfield> field. This permits + <xref linkend="buffer-flags" />. For output streams the driver + stores the time at which the last data byte was actually sent out + in the <structfield>timestamp</structfield> field. This permits applications to monitor the drift between the video and system - clock.</para></entry> + clock. For output streams that use <constant>V4L2_BUF_FLAG_TIMESTAMP_COPY</constant> + the application has to fill in the timestamp which will be copied + by the driver to the capture stream.</para></entry> </row> <row> <entry>&v4l2-timecode;</entry> @@ -846,7 +825,8 @@ is the file descriptor associated with a DMABUF buffer.</entry> <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 the application sets + single-planar API. This is set by the driver based on the calls to + &VIDIOC-REQBUFS; and/or &VIDIOC-CREATE-BUFS;. 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. @@ -880,13 +860,15 @@ should set this to 0.</entry> <entry><structfield>bytesused</structfield></entry> <entry></entry> <entry>The number of bytes occupied by data in the plane - (its payload).</entry> + (its payload). Drivers must set this field when <structfield>type</structfield> + refers to an input stream, applications when it refers to an output stream.</entry> </row> <row> <entry>__u32</entry> <entry><structfield>length</structfield></entry> <entry></entry> - <entry>Size in bytes of the plane (not its payload).</entry> + <entry>Size in bytes of the plane (not its payload). This is set by the driver + based on the calls to &VIDIOC-REQBUFS; and/or &VIDIOC-CREATE-BUFS;.</entry> </row> <row> <entry>union</entry> @@ -925,7 +907,9 @@ should set this to 0.</entry> <entry>__u32</entry> <entry><structfield>data_offset</structfield></entry> <entry></entry> - <entry>Offset in bytes to video data in the plane, if applicable. + <entry>Offset in bytes to video data in the plane. + Drivers must set this field when <structfield>type</structfield> + refers to an input stream, applications when it refers to an output stream. </entry> </row> <row> @@ -1005,6 +989,12 @@ should set this to 0.</entry> <entry>Buffer for video output overlay (OSD), see <xref linkend="osd" />.</entry> </row> + <row> + <entry><constant>V4L2_BUF_TYPE_SDR_CAPTURE</constant></entry> + <entry>11</entry> + <entry>Buffer for Software Defined Radio (SDR), see <xref + linkend="sdr" />.</entry> + </row> </tbody> </tgroup> </table> @@ -1016,7 +1006,7 @@ should set this to 0.</entry> <tbody valign="top"> <row> <entry><constant>V4L2_BUF_FLAG_MAPPED</constant></entry> - <entry>0x0001</entry> + <entry>0x00000001</entry> <entry>The buffer resides in device memory and has been mapped into the application's address space, see <xref linkend="mmap" /> for details. Drivers set or clear this flag when the @@ -1026,7 +1016,7 @@ Drivers set or clear this flag when the </row> <row> <entry><constant>V4L2_BUF_FLAG_QUEUED</constant></entry> - <entry>0x0002</entry> + <entry>0x00000002</entry> <entry>Internally drivers maintain two buffer queues, an incoming and outgoing queue. When this flag is set, the buffer is currently on the incoming queue. It automatically moves to the @@ -1039,7 +1029,7 @@ cleared.</entry> </row> <row> <entry><constant>V4L2_BUF_FLAG_DONE</constant></entry> - <entry>0x0004</entry> + <entry>0x00000004</entry> <entry>When this flag is set, the buffer is currently on the outgoing queue, ready to be dequeued from the driver. Drivers set or clear this flag when the <constant>VIDIOC_QUERYBUF</constant> ioctl @@ -1049,11 +1039,11 @@ buffer cannot be on both queues at the same time, the <constant>V4L2_BUF_FLAG_QUEUED</constant> and <constant>V4L2_BUF_FLAG_DONE</constant> flag are mutually exclusive. They can be both cleared however, then the buffer is in "dequeued" -state, in the application domain to say so.</entry> +state, in the application domain so to say.</entry> </row> <row> <entry><constant>V4L2_BUF_FLAG_ERROR</constant></entry> - <entry>0x0040</entry> + <entry>0x00000040</entry> <entry>When this flag is set, the buffer has been dequeued successfully, although the data might have been corrupted. This is recoverable, streaming may continue as normal and @@ -1063,35 +1053,43 @@ state, in the application domain to say so.</entry> </row> <row> <entry><constant>V4L2_BUF_FLAG_KEYFRAME</constant></entry> - <entry>0x0008</entry> + <entry>0x00000008</entry> <entry>Drivers set or clear this flag when calling the <constant>VIDIOC_DQBUF</constant> ioctl. It may be set by video capture devices when the buffer contains a compressed image which is a -key frame (or field), &ie; can be decompressed on its own.</entry> +key frame (or field), &ie; can be decompressed on its own. Also know as +an I-frame. Applications can set this bit when <structfield>type</structfield> +refers to an output stream.</entry> </row> <row> <entry><constant>V4L2_BUF_FLAG_PFRAME</constant></entry> - <entry>0x0010</entry> + <entry>0x00000010</entry> <entry>Similar to <constant>V4L2_BUF_FLAG_KEYFRAME</constant> this flags predicted frames or fields which contain only differences to a -previous key frame.</entry> +previous key frame. Applications can set this bit when <structfield>type</structfield> +refers to an output stream.</entry> </row> <row> <entry><constant>V4L2_BUF_FLAG_BFRAME</constant></entry> - <entry>0x0020</entry> - <entry>Similar to <constant>V4L2_BUF_FLAG_PFRAME</constant> - this is a bidirectional predicted frame or field. [ooc tbd]</entry> + <entry>0x00000020</entry> + <entry>Similar to <constant>V4L2_BUF_FLAG_KEYFRAME</constant> +this flags a bi-directional predicted frame or field which contains only +the differences between the current frame and both the preceding and following +key frames to specify its content. Applications can set this bit when +<structfield>type</structfield> refers to an output stream.</entry> </row> <row> <entry><constant>V4L2_BUF_FLAG_TIMECODE</constant></entry> - <entry>0x0100</entry> + <entry>0x00000100</entry> <entry>The <structfield>timecode</structfield> field is valid. Drivers set or clear this flag when the <constant>VIDIOC_DQBUF</constant> -ioctl is called.</entry> +ioctl is called. Applications can set this bit and the corresponding +<structfield>timecode</structfield> structure when <structfield>type</structfield> +refers to an output stream.</entry> </row> <row> <entry><constant>V4L2_BUF_FLAG_PREPARED</constant></entry> - <entry>0x0400</entry> + <entry>0x00000400</entry> <entry>The buffer has been prepared for I/O and can be queued by the application. Drivers set or clear this flag when the <link linkend="vidioc-querybuf">VIDIOC_QUERYBUF</link>, <link @@ -1101,7 +1099,7 @@ application. Drivers set or clear this flag when the </row> <row> <entry><constant>V4L2_BUF_FLAG_NO_CACHE_INVALIDATE</constant></entry> - <entry>0x0800</entry> + <entry>0x00000800</entry> <entry>Caches do not have to be invalidated for this buffer. Typically applications shall use this flag if the data captured in the buffer is not going to be touched by the CPU, instead the buffer will, probably, be @@ -1110,7 +1108,7 @@ passed on to a DMA-capable hardware unit for further processing or output. </row> <row> <entry><constant>V4L2_BUF_FLAG_NO_CACHE_CLEAN</constant></entry> - <entry>0x1000</entry> + <entry>0x00001000</entry> <entry>Caches do not have to be cleaned for this buffer. Typically applications shall use this flag for output buffers if the data in this buffer has not been created by the CPU but by some DMA-capable unit, @@ -1118,7 +1116,7 @@ in which case caches have not been used.</entry> </row> <row> <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MASK</constant></entry> - <entry>0xe000</entry> + <entry>0x0000e000</entry> <entry>Mask for timestamp types below. To test the timestamp type, mask out bits not belonging to timestamp type by performing a logical and operation with buffer @@ -1126,7 +1124,7 @@ in which case caches have not been used.</entry> </row> <row> <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN</constant></entry> - <entry>0x0000</entry> + <entry>0x00000000</entry> <entry>Unknown timestamp type. This type is used by drivers before Linux 3.9 and may be either monotonic (see below) or realtime (wall clock). Monotonic clock has been @@ -1139,7 +1137,7 @@ in which case caches have not been used.</entry> </row> <row> <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC</constant></entry> - <entry>0x2000</entry> + <entry>0x00002000</entry> <entry>The buffer timestamp has been taken from the <constant>CLOCK_MONOTONIC</constant> clock. To access the same clock outside V4L2, use @@ -1147,10 +1145,42 @@ in which case caches have not been used.</entry> </row> <row> <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_COPY</constant></entry> - <entry>0x4000</entry> + <entry>0x00004000</entry> <entry>The CAPTURE buffer timestamp has been taken from the corresponding OUTPUT buffer. This flag applies only to mem2mem devices.</entry> </row> + <row> + <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant></entry> + <entry>0x00070000</entry> + <entry>Mask for timestamp sources below. The timestamp source + defines the point of time the timestamp is taken in relation to + the frame. Logical 'and' operation between the + <structfield>flags</structfield> field and + <constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant> produces the + value of the timestamp source. Applications must set the timestamp + source when <structfield>type</structfield> refers to an output stream + and <constant>V4L2_BUF_FLAG_TIMESTAMP_COPY</constant> is set.</entry> + </row> + <row> + <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_EOF</constant></entry> + <entry>0x00000000</entry> + <entry>End Of Frame. The buffer timestamp has been taken + when the last pixel of the frame has been received or the + last pixel of the frame has been transmitted. In practice, + software generated timestamps will typically be read from + the clock a small amount of time after the last pixel has + been received or transmitten, depending on the system and + other activity in it.</entry> + </row> + <row> + <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_SOE</constant></entry> + <entry>0x00010000</entry> + <entry>Start Of Exposure. The buffer timestamp has been + taken when the exposure of the frame has begun. This is + only valid for the + <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant> buffer + type.</entry> + </row> </tbody> </tgroup> </table> @@ -1440,10 +1470,9 @@ or application, depending on data direction, must set &v4l2-buffer; <constant>V4L2_FIELD_BOTTOM</constant>. Any two successive fields pair to build a frame. If fields are successive, without any dropped fields between them (fields can drop individually), can be determined from -the &v4l2-buffer; <structfield>sequence</structfield> field. Image -sizes refer to the frame, not fields. This format cannot be selected -when using the read/write I/O method.<!-- Where it's indistinguishable -from V4L2_FIELD_SEQ_*. --></entry> +the &v4l2-buffer; <structfield>sequence</structfield> field. This format +cannot be selected when using the read/write I/O method since there +is no way to communicate if a field was a top or bottom field.</entry> </row> <row> <entry><constant>V4L2_FIELD_INTERLACED_TB</constant></entry> diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml index c51d5a4cda09..fb2b5e35d665 100644 --- a/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml +++ b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml @@ -12,18 +12,17 @@ <refsect1> <title>Description</title> - <para>This is a multi-planar, two-plane version of the YUV 4:2:0 format. + <para>This is a multi-planar, two-plane version of the YUV 4:2:2 format. The three components are separated into two sub-images or planes. <constant>V4L2_PIX_FMT_NV16M</constant> differs from <constant>V4L2_PIX_FMT_NV16 </constant> in that the two planes are non-contiguous in memory, i.e. the chroma -plane does not necessarily immediately follows the luma plane. +plane does not necessarily immediately follow the luma plane. The luminance data occupies the first plane. The Y plane has one byte per pixel. In the second plane there is chrominance data with alternating chroma samples. The CbCr plane is the same width and height, in bytes, as the Y plane. -Each CbCr pair belongs to four pixels. For example, +Each CbCr pair belongs to two 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>. +Y'<subscript>00</subscript>, Y'<subscript>01</subscript>. <constant>V4L2_PIX_FMT_NV61M</constant> is the same as <constant>V4L2_PIX_FMT_NV16M</constant> except the Cb and Cr bytes are swapped, the CrCb plane starts with a Cr byte.</para> diff --git a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml index 166c8d65e4f7..e1c4f8b4c0b3 100644 --- a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml +++ b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml @@ -121,14 +121,14 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para> <entry><constant>V4L2_PIX_FMT_RGB332</constant></entry> <entry>'RGB1'</entry> <entry></entry> - <entry>b<subscript>1</subscript></entry> - <entry>b<subscript>0</subscript></entry> - <entry>g<subscript>2</subscript></entry> - <entry>g<subscript>1</subscript></entry> - <entry>g<subscript>0</subscript></entry> <entry>r<subscript>2</subscript></entry> <entry>r<subscript>1</subscript></entry> <entry>r<subscript>0</subscript></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> </row> <row id="V4L2-PIX-FMT-RGB444"> <entry><constant>V4L2_PIX_FMT_RGB444</constant></entry> @@ -159,18 +159,18 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para> <entry>g<subscript>2</subscript></entry> <entry>g<subscript>1</subscript></entry> <entry>g<subscript>0</subscript></entry> - <entry>r<subscript>4</subscript></entry> - <entry>r<subscript>3</subscript></entry> - <entry>r<subscript>2</subscript></entry> - <entry>r<subscript>1</subscript></entry> - <entry>r<subscript>0</subscript></entry> - <entry></entry> - <entry>a</entry> <entry>b<subscript>4</subscript></entry> <entry>b<subscript>3</subscript></entry> <entry>b<subscript>2</subscript></entry> <entry>b<subscript>1</subscript></entry> <entry>b<subscript>0</subscript></entry> + <entry></entry> + <entry>a</entry> + <entry>r<subscript>4</subscript></entry> + <entry>r<subscript>3</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> <entry>g<subscript>4</subscript></entry> <entry>g<subscript>3</subscript></entry> </row> @@ -181,17 +181,17 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para> <entry>g<subscript>2</subscript></entry> <entry>g<subscript>1</subscript></entry> <entry>g<subscript>0</subscript></entry> - <entry>r<subscript>4</subscript></entry> - <entry>r<subscript>3</subscript></entry> - <entry>r<subscript>2</subscript></entry> - <entry>r<subscript>1</subscript></entry> - <entry>r<subscript>0</subscript></entry> - <entry></entry> <entry>b<subscript>4</subscript></entry> <entry>b<subscript>3</subscript></entry> <entry>b<subscript>2</subscript></entry> <entry>b<subscript>1</subscript></entry> <entry>b<subscript>0</subscript></entry> + <entry></entry> + <entry>r<subscript>4</subscript></entry> + <entry>r<subscript>3</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> <entry>g<subscript>5</subscript></entry> <entry>g<subscript>4</subscript></entry> <entry>g<subscript>3</subscript></entry> @@ -201,32 +201,32 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para> <entry>'RGBQ'</entry> <entry></entry> <entry>a</entry> - <entry>b<subscript>4</subscript></entry> - <entry>b<subscript>3</subscript></entry> - <entry>b<subscript>2</subscript></entry> - <entry>b<subscript>1</subscript></entry> - <entry>b<subscript>0</subscript></entry> - <entry>g<subscript>4</subscript></entry> - <entry>g<subscript>3</subscript></entry> - <entry></entry> - <entry>g<subscript>2</subscript></entry> - <entry>g<subscript>1</subscript></entry> - <entry>g<subscript>0</subscript></entry> <entry>r<subscript>4</subscript></entry> <entry>r<subscript>3</subscript></entry> <entry>r<subscript>2</subscript></entry> <entry>r<subscript>1</subscript></entry> <entry>r<subscript>0</subscript></entry> - </row> - <row id="V4L2-PIX-FMT-RGB565X"> - <entry><constant>V4L2_PIX_FMT_RGB565X</constant></entry> - <entry>'RGBR'</entry> + <entry>g<subscript>4</subscript></entry> + <entry>g<subscript>3</subscript></entry> <entry></entry> + <entry>g<subscript>2</subscript></entry> + <entry>g<subscript>1</subscript></entry> + <entry>g<subscript>0</subscript></entry> <entry>b<subscript>4</subscript></entry> <entry>b<subscript>3</subscript></entry> <entry>b<subscript>2</subscript></entry> <entry>b<subscript>1</subscript></entry> <entry>b<subscript>0</subscript></entry> + </row> + <row id="V4L2-PIX-FMT-RGB565X"> + <entry><constant>V4L2_PIX_FMT_RGB565X</constant></entry> + <entry>'RGBR'</entry> + <entry></entry> + <entry>r<subscript>4</subscript></entry> + <entry>r<subscript>3</subscript></entry> + <entry>r<subscript>2</subscript></entry> + <entry>r<subscript>1</subscript></entry> + <entry>r<subscript>0</subscript></entry> <entry>g<subscript>5</subscript></entry> <entry>g<subscript>4</subscript></entry> <entry>g<subscript>3</subscript></entry> @@ -234,11 +234,11 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para> <entry>g<subscript>2</subscript></entry> <entry>g<subscript>1</subscript></entry> <entry>g<subscript>0</subscript></entry> - <entry>r<subscript>4</subscript></entry> - <entry>r<subscript>3</subscript></entry> - <entry>r<subscript>2</subscript></entry> - <entry>r<subscript>1</subscript></entry> - <entry>r<subscript>0</subscript></entry> + <entry>b<subscript>4</subscript></entry> + <entry>b<subscript>3</subscript></entry> + <entry>b<subscript>2</subscript></entry> + <entry>b<subscript>1</subscript></entry> + <entry>b<subscript>0</subscript></entry> </row> <row id="V4L2-PIX-FMT-BGR666"> <entry><constant>V4L2_PIX_FMT_BGR666</constant></entry> @@ -385,6 +385,15 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para> <entry><constant>V4L2_PIX_FMT_RGB32</constant></entry> <entry>'RGB4'</entry> <entry></entry> + <entry>a<subscript>7</subscript></entry> + <entry>a<subscript>6</subscript></entry> + <entry>a<subscript>5</subscript></entry> + <entry>a<subscript>4</subscript></entry> + <entry>a<subscript>3</subscript></entry> + <entry>a<subscript>2</subscript></entry> + <entry>a<subscript>1</subscript></entry> + <entry>a<subscript>0</subscript></entry> + <entry></entry> <entry>r<subscript>7</subscript></entry> <entry>r<subscript>6</subscript></entry> <entry>r<subscript>5</subscript></entry> @@ -411,25 +420,16 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para> <entry>b<subscript>2</subscript></entry> <entry>b<subscript>1</subscript></entry> <entry>b<subscript>0</subscript></entry> - <entry></entry> - <entry>a<subscript>7</subscript></entry> - <entry>a<subscript>6</subscript></entry> - <entry>a<subscript>5</subscript></entry> - <entry>a<subscript>4</subscript></entry> - <entry>a<subscript>3</subscript></entry> - <entry>a<subscript>2</subscript></entry> - <entry>a<subscript>1</subscript></entry> - <entry>a<subscript>0</subscript></entry> </row> </tbody> </tgroup> </table> - <para>Bit 7 is the most significant bit. The value of a = alpha + <para>Bit 7 is the most significant bit. The value of the a = alpha bits is undefined when reading from the driver, ignored when writing to the driver, except when alpha blending has been negotiated for a <link linkend="overlay">Video Overlay</link> or <link linkend="osd"> -Video Output Overlay</link> or when alpha component has been configured +Video Output Overlay</link> or when the alpha component has been configured for a <link linkend="capture">Video Capture</link> by means of <link linkend="v4l2-alpha-component"> <constant>V4L2_CID_ALPHA_COMPONENT </constant> </link> control.</para> @@ -512,421 +512,6 @@ image</title> </formalpara> </example> - <important> - <para>Drivers may interpret these formats differently.</para> - </important> - - <para>Some RGB formats above are uncommon and were probably -defined in error. Drivers may interpret them as in <xref - linkend="rgb-formats-corrected" />.</para> - - <table pgwide="1" frame="none" id="rgb-formats-corrected"> - <title>Packed RGB Image Formats (corrected)</title> - <tgroup cols="37" align="center"> - <colspec colname="id" align="left" /> - <colspec colname="fourcc" /> - <colspec colname="bit" /> - - <colspec colnum="4" colname="b07" align="center" /> - <colspec colnum="5" colname="b06" align="center" /> - <colspec colnum="6" colname="b05" align="center" /> - <colspec colnum="7" colname="b04" align="center" /> - <colspec colnum="8" colname="b03" align="center" /> - <colspec colnum="9" colname="b02" align="center" /> - <colspec colnum="10" colname="b01" align="center" /> - <colspec colnum="11" colname="b00" align="center" /> - - <colspec colnum="13" colname="b17" align="center" /> - <colspec colnum="14" colname="b16" align="center" /> - <colspec colnum="15" colname="b15" align="center" /> - <colspec colnum="16" colname="b14" align="center" /> - <colspec colnum="17" colname="b13" align="center" /> - <colspec colnum="18" colname="b12" align="center" /> - <colspec colnum="19" colname="b11" align="center" /> - <colspec colnum="20" colname="b10" align="center" /> - - <colspec colnum="22" colname="b27" align="center" /> - <colspec colnum="23" colname="b26" align="center" /> - <colspec colnum="24" colname="b25" align="center" /> - <colspec colnum="25" colname="b24" align="center" /> - <colspec colnum="26" colname="b23" align="center" /> - <colspec colnum="27" colname="b22" align="center" /> - <colspec colnum="28" colname="b21" align="center" /> - <colspec colnum="29" colname="b20" align="center" /> - - <colspec colnum="31" colname="b37" align="center" /> - <colspec colnum="32" colname="b36" align="center" /> - <colspec colnum="33" colname="b35" align="center" /> - <colspec colnum="34" colname="b34" align="center" /> - <colspec colnum="35" colname="b33" align="center" /> - <colspec colnum="36" colname="b32" align="center" /> - <colspec colnum="37" colname="b31" align="center" /> - <colspec colnum="38" colname="b30" align="center" /> - - <spanspec namest="b07" nameend="b00" spanname="b0" /> - <spanspec namest="b17" nameend="b10" spanname="b1" /> - <spanspec namest="b27" nameend="b20" spanname="b2" /> - <spanspec namest="b37" nameend="b30" spanname="b3" /> - <thead> - <row> - <entry>Identifier</entry> - <entry>Code</entry> - <entry> </entry> - <entry spanname="b0">Byte 0 in memory</entry> - <entry spanname="b1">Byte 1</entry> - <entry spanname="b2">Byte 2</entry> - <entry spanname="b3">Byte 3</entry> - </row> - <row> - <entry> </entry> - <entry> </entry> - <entry>Bit</entry> - <entry>7</entry> - <entry>6</entry> - <entry>5</entry> - <entry>4</entry> - <entry>3</entry> - <entry>2</entry> - <entry>1</entry> - <entry>0</entry> - <entry> </entry> - <entry>7</entry> - <entry>6</entry> - <entry>5</entry> - <entry>4</entry> - <entry>3</entry> - <entry>2</entry> - <entry>1</entry> - <entry>0</entry> - <entry> </entry> - <entry>7</entry> - <entry>6</entry> - <entry>5</entry> - <entry>4</entry> - <entry>3</entry> - <entry>2</entry> - <entry>1</entry> - <entry>0</entry> - <entry> </entry> - <entry>7</entry> - <entry>6</entry> - <entry>5</entry> - <entry>4</entry> - <entry>3</entry> - <entry>2</entry> - <entry>1</entry> - <entry>0</entry> - </row> - </thead> - <tbody valign="top"> - <row><!-- id="V4L2-PIX-FMT-RGB332" --> - <entry><constant>V4L2_PIX_FMT_RGB332</constant></entry> - <entry>'RGB1'</entry> - <entry></entry> - <entry>r<subscript>2</subscript></entry> - <entry>r<subscript>1</subscript></entry> - <entry>r<subscript>0</subscript></entry> - <entry>g<subscript>2</subscript></entry> - <entry>g<subscript>1</subscript></entry> - <entry>g<subscript>0</subscript></entry> - <entry>b<subscript>1</subscript></entry> - <entry>b<subscript>0</subscript></entry> - </row> - <row><!-- id="V4L2-PIX-FMT-RGB444" --> - <entry><constant>V4L2_PIX_FMT_RGB444</constant></entry> - <entry>'R444'</entry> - <entry></entry> - <entry>g<subscript>3</subscript></entry> - <entry>g<subscript>2</subscript></entry> - <entry>g<subscript>1</subscript></entry> - <entry>g<subscript>0</subscript></entry> - <entry>b<subscript>3</subscript></entry> - <entry>b<subscript>2</subscript></entry> - <entry>b<subscript>1</subscript></entry> - <entry>b<subscript>0</subscript></entry> - <entry></entry> - <entry>a<subscript>3</subscript></entry> - <entry>a<subscript>2</subscript></entry> - <entry>a<subscript>1</subscript></entry> - <entry>a<subscript>0</subscript></entry> - <entry>r<subscript>3</subscript></entry> - <entry>r<subscript>2</subscript></entry> - <entry>r<subscript>1</subscript></entry> - <entry>r<subscript>0</subscript></entry> - </row> - <row><!-- id="V4L2-PIX-FMT-RGB555" --> - <entry><constant>V4L2_PIX_FMT_RGB555</constant></entry> - <entry>'RGBO'</entry> - <entry></entry> - <entry>g<subscript>2</subscript></entry> - <entry>g<subscript>1</subscript></entry> - <entry>g<subscript>0</subscript></entry> - <entry>b<subscript>4</subscript></entry> - <entry>b<subscript>3</subscript></entry> - <entry>b<subscript>2</subscript></entry> - <entry>b<subscript>1</subscript></entry> - <entry>b<subscript>0</subscript></entry> - <entry></entry> - <entry>a</entry> - <entry>r<subscript>4</subscript></entry> - <entry>r<subscript>3</subscript></entry> - <entry>r<subscript>2</subscript></entry> - <entry>r<subscript>1</subscript></entry> - <entry>r<subscript>0</subscript></entry> - <entry>g<subscript>4</subscript></entry> - <entry>g<subscript>3</subscript></entry> - </row> - <row><!-- id="V4L2-PIX-FMT-RGB565" --> - <entry><constant>V4L2_PIX_FMT_RGB565</constant></entry> - <entry>'RGBP'</entry> - <entry></entry> - <entry>g<subscript>2</subscript></entry> - <entry>g<subscript>1</subscript></entry> - <entry>g<subscript>0</subscript></entry> - <entry>b<subscript>4</subscript></entry> - <entry>b<subscript>3</subscript></entry> - <entry>b<subscript>2</subscript></entry> - <entry>b<subscript>1</subscript></entry> - <entry>b<subscript>0</subscript></entry> - <entry></entry> - <entry>r<subscript>4</subscript></entry> - <entry>r<subscript>3</subscript></entry> - <entry>r<subscript>2</subscript></entry> - <entry>r<subscript>1</subscript></entry> - <entry>r<subscript>0</subscript></entry> - <entry>g<subscript>5</subscript></entry> - <entry>g<subscript>4</subscript></entry> - <entry>g<subscript>3</subscript></entry> - </row> - <row><!-- id="V4L2-PIX-FMT-RGB555X" --> - <entry><constant>V4L2_PIX_FMT_RGB555X</constant></entry> - <entry>'RGBQ'</entry> - <entry></entry> - <entry>a</entry> - <entry>r<subscript>4</subscript></entry> - <entry>r<subscript>3</subscript></entry> - <entry>r<subscript>2</subscript></entry> - <entry>r<subscript>1</subscript></entry> - <entry>r<subscript>0</subscript></entry> - <entry>g<subscript>4</subscript></entry> - <entry>g<subscript>3</subscript></entry> - <entry></entry> - <entry>g<subscript>2</subscript></entry> - <entry>g<subscript>1</subscript></entry> - <entry>g<subscript>0</subscript></entry> - <entry>b<subscript>4</subscript></entry> - <entry>b<subscript>3</subscript></entry> - <entry>b<subscript>2</subscript></entry> - <entry>b<subscript>1</subscript></entry> - <entry>b<subscript>0</subscript></entry> - </row> - <row><!-- id="V4L2-PIX-FMT-RGB565X" --> - <entry><constant>V4L2_PIX_FMT_RGB565X</constant></entry> - <entry>'RGBR'</entry> - <entry></entry> - <entry>r<subscript>4</subscript></entry> - <entry>r<subscript>3</subscript></entry> - <entry>r<subscript>2</subscript></entry> - <entry>r<subscript>1</subscript></entry> - <entry>r<subscript>0</subscript></entry> - <entry>g<subscript>5</subscript></entry> - <entry>g<subscript>4</subscript></entry> - <entry>g<subscript>3</subscript></entry> - <entry></entry> - <entry>g<subscript>2</subscript></entry> - <entry>g<subscript>1</subscript></entry> - <entry>g<subscript>0</subscript></entry> - <entry>b<subscript>4</subscript></entry> - <entry>b<subscript>3</subscript></entry> - <entry>b<subscript>2</subscript></entry> - <entry>b<subscript>1</subscript></entry> - <entry>b<subscript>0</subscript></entry> - </row> - <row><!-- id="V4L2-PIX-FMT-BGR666" --> - <entry><constant>V4L2_PIX_FMT_BGR666</constant></entry> - <entry>'BGRH'</entry> - <entry></entry> - <entry>b<subscript>5</subscript></entry> - <entry>b<subscript>4</subscript></entry> - <entry>b<subscript>3</subscript></entry> - <entry>b<subscript>2</subscript></entry> - <entry>b<subscript>1</subscript></entry> - <entry>b<subscript>0</subscript></entry> - <entry>g<subscript>5</subscript></entry> - <entry>g<subscript>4</subscript></entry> - <entry></entry> - <entry>g<subscript>3</subscript></entry> - <entry>g<subscript>2</subscript></entry> - <entry>g<subscript>1</subscript></entry> - <entry>g<subscript>0</subscript></entry> - <entry>r<subscript>5</subscript></entry> - <entry>r<subscript>4</subscript></entry> - <entry>r<subscript>3</subscript></entry> - <entry>r<subscript>2</subscript></entry> - <entry></entry> - <entry>r<subscript>1</subscript></entry> - <entry>r<subscript>0</subscript></entry> - <entry></entry> - <entry></entry> - <entry></entry> - <entry></entry> - <entry></entry> - <entry></entry> - <entry></entry> - <entry></entry> - <entry></entry> - <entry></entry> - <entry></entry> - <entry></entry> - <entry></entry> - <entry></entry> - </row> - <row><!-- id="V4L2-PIX-FMT-BGR24" --> - <entry><constant>V4L2_PIX_FMT_BGR24</constant></entry> - <entry>'BGR3'</entry> - <entry></entry> - <entry>b<subscript>7</subscript></entry> - <entry>b<subscript>6</subscript></entry> - <entry>b<subscript>5</subscript></entry> - <entry>b<subscript>4</subscript></entry> - <entry>b<subscript>3</subscript></entry> - <entry>b<subscript>2</subscript></entry> - <entry>b<subscript>1</subscript></entry> - <entry>b<subscript>0</subscript></entry> - <entry></entry> - <entry>g<subscript>7</subscript></entry> - <entry>g<subscript>6</subscript></entry> - <entry>g<subscript>5</subscript></entry> - <entry>g<subscript>4</subscript></entry> - <entry>g<subscript>3</subscript></entry> - <entry>g<subscript>2</subscript></entry> - <entry>g<subscript>1</subscript></entry> - <entry>g<subscript>0</subscript></entry> - <entry></entry> - <entry>r<subscript>7</subscript></entry> - <entry>r<subscript>6</subscript></entry> - <entry>r<subscript>5</subscript></entry> - <entry>r<subscript>4</subscript></entry> - <entry>r<subscript>3</subscript></entry> - <entry>r<subscript>2</subscript></entry> - <entry>r<subscript>1</subscript></entry> - <entry>r<subscript>0</subscript></entry> - </row> - <row><!-- id="V4L2-PIX-FMT-RGB24" --> - <entry><constant>V4L2_PIX_FMT_RGB24</constant></entry> - <entry>'RGB3'</entry> - <entry></entry> - <entry>r<subscript>7</subscript></entry> - <entry>r<subscript>6</subscript></entry> - <entry>r<subscript>5</subscript></entry> - <entry>r<subscript>4</subscript></entry> - <entry>r<subscript>3</subscript></entry> - <entry>r<subscript>2</subscript></entry> - <entry>r<subscript>1</subscript></entry> - <entry>r<subscript>0</subscript></entry> - <entry></entry> - <entry>g<subscript>7</subscript></entry> - <entry>g<subscript>6</subscript></entry> - <entry>g<subscript>5</subscript></entry> - <entry>g<subscript>4</subscript></entry> - <entry>g<subscript>3</subscript></entry> - <entry>g<subscript>2</subscript></entry> - <entry>g<subscript>1</subscript></entry> - <entry>g<subscript>0</subscript></entry> - <entry></entry> - <entry>b<subscript>7</subscript></entry> - <entry>b<subscript>6</subscript></entry> - <entry>b<subscript>5</subscript></entry> - <entry>b<subscript>4</subscript></entry> - <entry>b<subscript>3</subscript></entry> - <entry>b<subscript>2</subscript></entry> - <entry>b<subscript>1</subscript></entry> - <entry>b<subscript>0</subscript></entry> - </row> - <row><!-- id="V4L2-PIX-FMT-BGR32" --> - <entry><constant>V4L2_PIX_FMT_BGR32</constant></entry> - <entry>'BGR4'</entry> - <entry></entry> - <entry>b<subscript>7</subscript></entry> - <entry>b<subscript>6</subscript></entry> - <entry>b<subscript>5</subscript></entry> - <entry>b<subscript>4</subscript></entry> - <entry>b<subscript>3</subscript></entry> - <entry>b<subscript>2</subscript></entry> - <entry>b<subscript>1</subscript></entry> - <entry>b<subscript>0</subscript></entry> - <entry></entry> - <entry>g<subscript>7</subscript></entry> - <entry>g<subscript>6</subscript></entry> - <entry>g<subscript>5</subscript></entry> - <entry>g<subscript>4</subscript></entry> - <entry>g<subscript>3</subscript></entry> - <entry>g<subscript>2</subscript></entry> - <entry>g<subscript>1</subscript></entry> - <entry>g<subscript>0</subscript></entry> - <entry></entry> - <entry>r<subscript>7</subscript></entry> - <entry>r<subscript>6</subscript></entry> - <entry>r<subscript>5</subscript></entry> - <entry>r<subscript>4</subscript></entry> - <entry>r<subscript>3</subscript></entry> - <entry>r<subscript>2</subscript></entry> - <entry>r<subscript>1</subscript></entry> - <entry>r<subscript>0</subscript></entry> - <entry></entry> - <entry>a<subscript>7</subscript></entry> - <entry>a<subscript>6</subscript></entry> - <entry>a<subscript>5</subscript></entry> - <entry>a<subscript>4</subscript></entry> - <entry>a<subscript>3</subscript></entry> - <entry>a<subscript>2</subscript></entry> - <entry>a<subscript>1</subscript></entry> - <entry>a<subscript>0</subscript></entry> - </row> - <row><!-- id="V4L2-PIX-FMT-RGB32" --> - <entry><constant>V4L2_PIX_FMT_RGB32</constant></entry> - <entry>'RGB4'</entry> - <entry></entry> - <entry>a<subscript>7</subscript></entry> - <entry>a<subscript>6</subscript></entry> - <entry>a<subscript>5</subscript></entry> - <entry>a<subscript>4</subscript></entry> - <entry>a<subscript>3</subscript></entry> - <entry>a<subscript>2</subscript></entry> - <entry>a<subscript>1</subscript></entry> - <entry>a<subscript>0</subscript></entry> - <entry></entry> - <entry>r<subscript>7</subscript></entry> - <entry>r<subscript>6</subscript></entry> - <entry>r<subscript>5</subscript></entry> - <entry>r<subscript>4</subscript></entry> - <entry>r<subscript>3</subscript></entry> - <entry>r<subscript>2</subscript></entry> - <entry>r<subscript>1</subscript></entry> - <entry>r<subscript>0</subscript></entry> - <entry></entry> - <entry>g<subscript>7</subscript></entry> - <entry>g<subscript>6</subscript></entry> - <entry>g<subscript>5</subscript></entry> - <entry>g<subscript>4</subscript></entry> - <entry>g<subscript>3</subscript></entry> - <entry>g<subscript>2</subscript></entry> - <entry>g<subscript>1</subscript></entry> - <entry>g<subscript>0</subscript></entry> - <entry></entry> - <entry>b<subscript>7</subscript></entry> - <entry>b<subscript>6</subscript></entry> - <entry>b<subscript>5</subscript></entry> - <entry>b<subscript>4</subscript></entry> - <entry>b<subscript>3</subscript></entry> - <entry>b<subscript>2</subscript></entry> - <entry>b<subscript>1</subscript></entry> - <entry>b<subscript>0</subscript></entry> - </row> - </tbody> - </tgroup> - </table> - <para>A test utility to determine which RGB formats a driver actually supports is available from the LinuxTV v4l-dvb repository. See &v4l-dvb; for access instructions.</para> diff --git a/Documentation/DocBook/media/v4l/pixfmt-sdr-cu08.xml b/Documentation/DocBook/media/v4l/pixfmt-sdr-cu08.xml new file mode 100644 index 000000000000..2d80104c178b --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-sdr-cu08.xml @@ -0,0 +1,44 @@ +<refentry id="V4L2-SDR-FMT-CU08"> + <refmeta> + <refentrytitle>V4L2_SDR_FMT_CU8 ('CU08')</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname> + <constant>V4L2_SDR_FMT_CU8</constant> + </refname> + <refpurpose>Complex unsigned 8-bit IQ sample</refpurpose> + </refnamediv> + <refsect1> + <title>Description</title> + <para> +This format contains sequence of complex number samples. Each complex number +consist two parts, called In-phase and Quadrature (IQ). Both I and Q are +represented as a 8 bit unsigned number. I value comes first and Q value after +that. + </para> + <example> + <title><constant>V4L2_SDR_FMT_CU8</constant> 1 sample</title> + <formalpara> + <title>Byte Order.</title> + <para>Each cell is one byte. + <informaltable frame="none"> + <tgroup cols="2" align="center"> + <colspec align="left" colwidth="2*" /> + <tbody valign="top"> + <row> + <entry>start + 0:</entry> + <entry>I'<subscript>0</subscript></entry> + </row> + <row> + <entry>start + 1:</entry> + <entry>Q'<subscript>0</subscript></entry> + </row> + </tbody> + </tgroup> + </informaltable> + </para> + </formalpara> + </example> + </refsect1> +</refentry> diff --git a/Documentation/DocBook/media/v4l/pixfmt-sdr-cu16le.xml b/Documentation/DocBook/media/v4l/pixfmt-sdr-cu16le.xml new file mode 100644 index 000000000000..26288ffa9071 --- /dev/null +++ b/Documentation/DocBook/media/v4l/pixfmt-sdr-cu16le.xml @@ -0,0 +1,46 @@ +<refentry id="V4L2-SDR-FMT-CU16LE"> + <refmeta> + <refentrytitle>V4L2_SDR_FMT_CU16LE ('CU16')</refentrytitle> + &manvol; + </refmeta> + <refnamediv> + <refname> + <constant>V4L2_SDR_FMT_CU16LE</constant> + </refname> + <refpurpose>Complex unsigned 16-bit little endian IQ sample</refpurpose> + </refnamediv> + <refsect1> + <title>Description</title> + <para> +This format contains sequence of complex number samples. Each complex number +consist two parts, called In-phase and Quadrature (IQ). Both I and Q are +represented as a 16 bit unsigned little endian number. I value comes first +and Q value after that. + </para> + <example> + <title><constant>V4L2_SDR_FMT_CU16LE</constant> 1 sample</title> + <formalpara> + <title>Byte Order.</title> + <para>Each cell is one byte. + <informaltable frame="none"> + <tgroup cols="3" align="center"> + <colspec align="left" colwidth="2*" /> + <tbody valign="top"> + <row> + <entry>start + 0:</entry> + <entry>I'<subscript>0[7:0]</subscript></entry> + <entry>I'<subscript>0[15:8]</subscript></entry> + </row> + <row> + <entry>start + 2:</entry> + <entry>Q'<subscript>0[7:0]</subscript></entry> + <entry>Q'<subscript>0[15:8]</subscript></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 72d72bd67d0a..ea514d6075c5 100644 --- a/Documentation/DocBook/media/v4l/pixfmt.xml +++ b/Documentation/DocBook/media/v4l/pixfmt.xml @@ -25,7 +25,12 @@ capturing and output, for overlay frame buffer formats see also <row> <entry>__u32</entry> <entry><structfield>height</structfield></entry> - <entry>Image height in pixels.</entry> + <entry>Image height in pixels. If <structfield>field</structfield> is + one of <constant>V4L2_FIELD_TOP</constant>, <constant>V4L2_FIELD_BOTTOM</constant> + or <constant>V4L2_FIELD_ALTERNATE</constant> then height refers to the + number of lines in the field, otherwise it refers to the number of + lines in the frame (which is twice the field height for interlaced + formats).</entry> </row> <row> <entry spanname="hspan">Applications set these fields to @@ -54,7 +59,7 @@ linkend="reserved-formats" /></entry> can request to capture or output only the top or bottom field, or both fields interlaced or sequentially stored in one buffer or alternating in separate buffers. Drivers return the actual field order selected. -For details see <xref linkend="field-order" />.</entry> +For more details on fields see <xref linkend="field-order" />.</entry> </row> <row> <entry>__u32</entry> @@ -81,7 +86,10 @@ plane and is divided by the same factor as the example the Cb and Cr planes of a YUV 4:2:0 image have half as many padding bytes following each line as the Y plane. To avoid ambiguities drivers must return a <structfield>bytesperline</structfield> value -rounded up to a multiple of the scale factor.</para></entry> +rounded up to a multiple of the scale factor.</para> +<para>For compressed formats the <structfield>bytesperline</structfield> +value makes no sense. Applications and drivers must set this to 0 in +that case.</para></entry> </row> <row> <entry>__u32</entry> @@ -97,7 +105,8 @@ hold an image.</entry> <entry>&v4l2-colorspace;</entry> <entry><structfield>colorspace</structfield></entry> <entry>This information supplements the -<structfield>pixelformat</structfield> and must be set by the driver, +<structfield>pixelformat</structfield> and must be set by the driver for +capture streams and by the application for output streams, see <xref linkend="colorspaces" />.</entry> </row> <row> @@ -135,7 +144,7 @@ set this field to zero.</entry> <entry>__u16</entry> <entry><structfield>bytesperline</structfield></entry> <entry>Distance in bytes between the leftmost pixels in two adjacent - lines.</entry> + lines. See &v4l2-pix-format;.</entry> </row> <row> <entry>__u16</entry> @@ -154,12 +163,12 @@ set this field to zero.</entry> <row> <entry>__u32</entry> <entry><structfield>width</structfield></entry> - <entry>Image width in pixels.</entry> + <entry>Image width in pixels. See &v4l2-pix-format;.</entry> </row> <row> <entry>__u32</entry> <entry><structfield>height</structfield></entry> - <entry>Image height in pixels.</entry> + <entry>Image height in pixels. See &v4l2-pix-format;.</entry> </row> <row> <entry>__u32</entry> @@ -811,6 +820,17 @@ extended control <constant>V4L2_CID_MPEG_STREAM_TYPE</constant>, see </table> </section> + <section id="sdr-formats"> + <title>SDR Formats</title> + + <para>These formats are used for <link linkend="sdr">SDR Capture</link> +interface only.</para> + + &sub-sdr-cu08; + &sub-sdr-cu16le; + + </section> + <section id="pixfmt-reserved"> <title>Reserved Format Identifiers</title> diff --git a/Documentation/DocBook/media/v4l/remote_controllers.xml b/Documentation/DocBook/media/v4l/remote_controllers.xml index 160e464d44b7..5124a6c4daa8 100644 --- a/Documentation/DocBook/media/v4l/remote_controllers.xml +++ b/Documentation/DocBook/media/v4l/remote_controllers.xml @@ -1,10 +1,152 @@ +<partinfo> +<authorgroup> +<author> +<firstname>Mauro</firstname> +<surname>Chehab</surname> +<othername role="mi">Carvalho</othername> +<affiliation><address><email>m.chehab@samsung.com</email></address></affiliation> +<contrib>Initial version.</contrib> +</author> +</authorgroup> +<copyright> + <year>2009-2014</year> + <holder>Mauro Carvalho Chehab</holder> +</copyright> + +<revhistory> +<!-- Put document revisions here, newest first. --> +<revision> +<revnumber>3.15</revnumber> +<date>2014-02-06</date> +<authorinitials>mcc</authorinitials> +<revremark>Added the interface description and the RC sysfs class description.</revremark> +</revision> +<revision> +<revnumber>1.0</revnumber> +<date>2009-09-06</date> +<authorinitials>mcc</authorinitials> +<revremark>Initial revision</revremark> +</revision> +</revhistory> +</partinfo> + + <title>Remote Controller API</title> + <chapter id="remote_controllers"> + <title>Remote Controllers</title> + <section id="Remote_controllers_Intro"> <title>Introduction</title> <para>Currently, most analog and digital devices have a Infrared input for remote controllers. Each manufacturer has their own type of control. It is not rare for the same manufacturer to ship different types of controls, depending on the device.</para> +<para>A Remote Controller interface is mapped as a normal evdev/input interface, just like a keyboard or a mouse. +So, it uses all ioctls already defined for any other input devices.</para> +<para>However, remove controllers are more flexible than a normal input device, as the IR +receiver (and/or transmitter) can be used in conjunction with a wide variety of different IR remotes.</para> +<para>In order to allow flexibility, the Remote Controller subsystem allows controlling the +RC-specific attributes via <link linkend="remote_controllers_sysfs_nodes">the sysfs class nodes</link>.</para> +</section> + +<section id="remote_controllers_sysfs_nodes"> +<title>Remote Controller's sysfs nodes</title> +<para>As defined at <constant>Documentation/ABI/testing/sysfs-class-rc</constant>, those are the sysfs nodes that control the Remote Controllers:</para> + +<section id="sys_class_rc"> +<title>/sys/class/rc/</title> +<para>The <constant>/sys/class/rc/</constant> class sub-directory belongs to the Remote Controller +core and provides a sysfs interface for configuring infrared remote controller receivers. +</para> + +</section> +<section id="sys_class_rc_rcN"> +<title>/sys/class/rc/rcN/</title> +<para>A <constant>/sys/class/rc/rcN</constant> directory is created for each remote + control receiver device where N is the number of the receiver.</para> + +</section> +<section id="sys_class_rc_rcN_protocols"> +<title>/sys/class/rc/rcN/protocols</title> +<para>Reading this file returns a list of available protocols, something like:</para> +<para><constant>rc5 [rc6] nec jvc [sony]</constant></para> +<para>Enabled protocols are shown in [] brackets.</para> +<para>Writing "+proto" will add a protocol to the list of enabled protocols.</para> +<para>Writing "-proto" will remove a protocol from the list of enabled protocols.</para> +<para>Writing "proto" will enable only "proto".</para> +<para>Writing "none" will disable all protocols.</para> +<para>Write fails with EINVAL if an invalid protocol combination or unknown protocol name is used.</para> + +</section> +<section id="sys_class_rc_rcN_filter"> +<title>/sys/class/rc/rcN/filter</title> +<para>Sets the scancode filter expected value.</para> +<para>Use in combination with <constant>/sys/class/rc/rcN/filter_mask</constant> to set the +expected value of the bits set in the filter mask. +If the hardware supports it then scancodes which do not match +the filter will be ignored. Otherwise the write will fail with +an error.</para> +<para>This value may be reset to 0 if the current protocol is altered.</para> + +</section> +<section id="sys_class_rc_rcN_filter_mask"> +<title>/sys/class/rc/rcN/filter_mask</title> +<para>Sets the scancode filter mask of bits to compare. +Use in combination with <constant>/sys/class/rc/rcN/filter</constant> to set the bits +of the scancode which should be compared against the expected +value. A value of 0 disables the filter to allow all valid +scancodes to be processed.</para> +<para>If the hardware supports it then scancodes which do not match +the filter will be ignored. Otherwise the write will fail with +an error.</para> +<para>This value may be reset to 0 if the current protocol is altered.</para> + +</section> +<section id="sys_class_rc_rcN_wakeup_protocols"> +<title>/sys/class/rc/rcN/wakeup_protocols</title> +<para>Reading this file returns a list of available protocols to use for the +wakeup filter, something like:</para> +<para><constant>rc5 rc6 nec jvc [sony]</constant></para> +<para>The enabled wakeup protocol is shown in [] brackets.</para> +<para>Writing "+proto" will add a protocol to the list of enabled wakeup +protocols.</para> +<para>Writing "-proto" will remove a protocol from the list of enabled wakeup +protocols.</para> +<para>Writing "proto" will use "proto" for wakeup events.</para> +<para>Writing "none" will disable wakeup.</para> +<para>Write fails with EINVAL if an invalid protocol combination or unknown +protocol name is used, or if wakeup is not supported by the hardware.</para> + +</section> +<section id="sys_class_rc_rcN_wakeup_filter"> +<title>/sys/class/rc/rcN/wakeup_filter</title> +<para>Sets the scancode wakeup filter expected value. +Use in combination with <constant>/sys/class/rc/rcN/wakeup_filter_mask</constant> to +set the expected value of the bits set in the wakeup filter mask +to trigger a system wake event.</para> +<para>If the hardware supports it and wakeup_filter_mask is not 0 then +scancodes which match the filter will wake the system from e.g. +suspend to RAM or power off. +Otherwise the write will fail with an error.</para> +<para>This value may be reset to 0 if the wakeup protocol is altered.</para> + +</section> +<section id="sys_class_rc_rcN_wakeup_filter_mask"> +<title>/sys/class/rc/rcN/wakeup_filter_mask</title> +<para>Sets the scancode wakeup filter mask of bits to compare. +Use in combination with <constant>/sys/class/rc/rcN/wakeup_filter</constant> to set +the bits of the scancode which should be compared against the +expected value to trigger a system wake event.</para> +<para>If the hardware supports it and wakeup_filter_mask is not 0 then +scancodes which match the filter will wake the system from e.g. +suspend to RAM or power off. +Otherwise the write will fail with an error.</para> +<para>This value may be reset to 0 if the wakeup protocol is altered.</para> +</section> +</section> + +<section id="Remote_controllers_tables"> +<title>Remote controller tables</title> <para>Unfortunately, for several years, there was no effort to create uniform IR keycodes for different devices. This caused the same IR keyname to be mapped completely differently on different IR devices. This resulted that the same IR keyname to be mapped completely different on @@ -175,3 +317,4 @@ keymapping.</para> </section> &sub-lirc_device_interface; +</chapter> diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index 74b7f27af71a..b445161b912c 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -70,7 +70,7 @@ MPEG stream embedded, sliced VBI data format in this specification. Remote Controller chapter.</contrib> <affiliation> <address> - <email>mchehab@redhat.com</email> + <email>m.chehab@samsung.com</email> </address> </affiliation> </author> @@ -107,6 +107,16 @@ Remote Controller chapter.</contrib> </address> </affiliation> </author> + <author> + <firstname>Antti</firstname> + <surname>Palosaari</surname> + <contrib>SDR API.</contrib> + <affiliation> + <address> + <email>crope@iki.fi</email> + </address> + </affiliation> + </author> </authorgroup> <copyright> @@ -125,6 +135,7 @@ Remote Controller chapter.</contrib> <year>2011</year> <year>2012</year> <year>2013</year> + <year>2014</year> <holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab, Pawel Osciak</holder> @@ -141,6 +152,16 @@ structs, ioctls) must be noted in more detail in the history chapter applications. --> <revision> + <revnumber>3.15</revnumber> + <date>2014-02-03</date> + <authorinitials>hv, ap</authorinitials> + <revremark>Update several sections of "Common API Elements": "Opening and Closing Devices" +"Querying Capabilities", "Application Priority", "Video Inputs and Outputs", "Audio Inputs and Outputs" +"Tuners and Modulators", "Video Standards" and "Digital Video (DV) Timings". Added SDR API. + </revremark> + </revision> + + <revision> <revnumber>3.14</revnumber> <date>2013-11-25</date> <authorinitials>rr</authorinitials> @@ -537,6 +558,7 @@ and discussions on the V4L mailing list.</revremark> <section id="ttx"> &sub-dev-teletext; </section> <section id="radio"> &sub-dev-radio; </section> <section id="rds"> &sub-dev-rds; </section> + <section id="sdr"> &sub-dev-sdr; </section> <section id="event"> &sub-dev-event; </section> <section id="subdev"> &sub-dev-subdev; </section> </chapter> @@ -585,6 +607,7 @@ and discussions on the V4L mailing list.</revremark> &sub-g-crop; &sub-g-ctrl; &sub-g-dv-timings; + &sub-g-edid; &sub-g-enc-index; &sub-g-ext-ctrls; &sub-g-fbuf; @@ -616,7 +639,6 @@ 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-enum-freq-bands.xml b/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml index 6541ba0175ed..4e8ea65f7282 100644 --- a/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml +++ b/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml @@ -100,7 +100,7 @@ See <xref linkend="v4l2-tuner-type" /></entry> <entry><structfield>capability</structfield></entry> <entry spanname="hspan">The tuner/modulator capability flags for this frequency band, see <xref linkend="tuner-capability" />. The <constant>V4L2_TUNER_CAP_LOW</constant> -capability must be the same for all frequency bands of the selected tuner/modulator. +or <constant>V4L2_TUNER_CAP_1HZ</constant> capability must be the same for all frequency bands of the selected tuner/modulator. So either all bands have that capability set, or none of them have that capability.</entry> </row> <row> @@ -109,7 +109,8 @@ So either all bands have that capability set, or none of them have that capabili <entry spanname="hspan">The lowest tunable frequency in units of 62.5 kHz, or if the <structfield>capability</structfield> flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 -Hz, for this frequency band.</entry> +Hz, for this frequency band. A 1 Hz unit is used when the <structfield>capability</structfield> flag +<constant>V4L2_TUNER_CAP_1HZ</constant> is set.</entry> </row> <row> <entry>__u32</entry> @@ -117,7 +118,8 @@ Hz, for this frequency band.</entry> <entry spanname="hspan">The highest tunable frequency in units of 62.5 kHz, or if the <structfield>capability</structfield> flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 -Hz, for this frequency band.</entry> +Hz, for this frequency band. A 1 Hz unit is used when the <structfield>capability</structfield> flag +<constant>V4L2_TUNER_CAP_1HZ</constant> is set.</entry> </row> <row> <entry>__u32</entry> diff --git a/Documentation/DocBook/media/v4l/vidioc-subdev-g-edid.xml b/Documentation/DocBook/media/v4l/vidioc-g-edid.xml index bbd18f0e6ede..ce4563b87131 100644 --- a/Documentation/DocBook/media/v4l/vidioc-subdev-g-edid.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-edid.xml @@ -1,12 +1,12 @@ -<refentry id="vidioc-subdev-g-edid"> +<refentry id="vidioc-g-edid"> <refmeta> - <refentrytitle>ioctl VIDIOC_SUBDEV_G_EDID, VIDIOC_SUBDEV_S_EDID</refentrytitle> + <refentrytitle>ioctl VIDIOC_G_EDID, VIDIOC_S_EDID</refentrytitle> &manvol; </refmeta> <refnamediv> - <refname>VIDIOC_SUBDEV_G_EDID</refname> - <refname>VIDIOC_SUBDEV_S_EDID</refname> + <refname>VIDIOC_G_EDID</refname> + <refname>VIDIOC_S_EDID</refname> <refpurpose>Get or set the EDID of a video receiver/transmitter</refpurpose> </refnamediv> @@ -16,7 +16,7 @@ <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> + <paramdef>struct v4l2_edid *<parameter>argp</parameter></paramdef> </funcprototype> </funcsynopsis> <funcsynopsis> @@ -24,7 +24,7 @@ <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> + <paramdef>const struct v4l2_edid *<parameter>argp</parameter></paramdef> </funcprototype> </funcsynopsis> </refsynopsisdiv> @@ -42,7 +42,7 @@ <varlistentry> <term><parameter>request</parameter></term> <listitem> - <para>VIDIOC_SUBDEV_G_EDID, VIDIOC_SUBDEV_S_EDID</para> + <para>VIDIOC_G_EDID, VIDIOC_S_EDID</para> </listitem> </varlistentry> <varlistentry> @@ -56,12 +56,20 @@ <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>These ioctls can be used to get or set an EDID associated with an input + from a receiver or an output of a transmitter device. They can be + used with subdevice nodes (/dev/v4l-subdevX) or with video nodes (/dev/videoX).</para> + + <para>When used with video nodes the <structfield>pad</structfield> field represents the + input (for video capture devices) or output (for video output devices) index as + is returned by &VIDIOC-ENUMINPUT; and &VIDIOC-ENUMOUTPUT; respectively. When used + with subdevice nodes the <structfield>pad</structfield> field represents the + input or output pad of the subdevice. If there is no EDID support for the given + <structfield>pad</structfield> value, then the &EINVAL; will be returned.</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 + fields and call <constant>VIDIOC_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 @@ -91,15 +99,17 @@ 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> + <table pgwide="1" frame="none" id="v4l2-edid"> + <title>struct <structname>v4l2_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> + <entry>Pad for which to get/set the EDID blocks. When used with a video device + node the pad represents the input or output index as returned by + &VIDIOC-ENUMINPUT; and &VIDIOC-ENUMOUTPUT; respectively.</entry> </row> <row> <entry>__u32</entry> diff --git a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml index b3bb9575b2e0..e9f6735c0823 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml @@ -327,7 +327,12 @@ These controls are described in <xref These controls are described in <xref linkend="fm-rx-controls" />.</entry> </row> - + <row> + <entry><constant>V4L2_CTRL_CLASS_RF_TUNER</constant></entry> + <entry>0xa20000</entry> + <entry>The class containing RF tuner controls. +These controls are described in <xref linkend="rf-tuner-controls" />.</entry> + </row> </tbody> </tgroup> </table> diff --git a/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml b/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml index ee8f56e1bac0..4fe19a7a9a31 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml @@ -172,6 +172,13 @@ capture and output devices.</entry> </row> <row> <entry></entry> + <entry>&v4l2-sdr-format;</entry> + <entry><structfield>sdr</structfield></entry> + <entry>Definition of a data format, see +<xref linkend="pixfmt" />, used by SDR capture devices.</entry> + </row> + <row> + <entry></entry> <entry>__u8</entry> <entry><structfield>raw_data</structfield>[200]</entry> <entry>Place holder for future extensions.</entry> diff --git a/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml b/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml index c7a1c462e724..d1034fb61d15 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml @@ -109,9 +109,10 @@ See <xref linkend="v4l2-tuner-type" /></entry> <entry>__u32</entry> <entry><structfield>frequency</structfield></entry> <entry>Tuning frequency in units of 62.5 kHz, or if the -&v4l2-tuner; or &v4l2-modulator; <structfield>capabilities</structfield> flag +&v4l2-tuner; or &v4l2-modulator; <structfield>capability</structfield> flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 -Hz.</entry> +Hz. A 1 Hz unit is used when the <structfield>capability</structfield> flag +<constant>V4L2_TUNER_CAP_1HZ</constant> is set.</entry> </row> <row> <entry>__u32</entry> diff --git a/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml b/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml index 7f4ac7e41fa8..7068b599a00d 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml @@ -113,7 +113,8 @@ change for example with the current video standard.</entry> <entry>The lowest tunable frequency in units of 62.5 KHz, or if the <structfield>capability</structfield> flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 -Hz.</entry> +Hz, or if the <structfield>capability</structfield> flag +<constant>V4L2_TUNER_CAP_1HZ</constant> is set, in units of 1 Hz.</entry> </row> <row> <entry>__u32</entry> @@ -121,7 +122,8 @@ Hz.</entry> <entry>The highest tunable frequency in units of 62.5 KHz, or if the <structfield>capability</structfield> flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 -Hz.</entry> +Hz, or if the <structfield>capability</structfield> flag +<constant>V4L2_TUNER_CAP_1HZ</constant> is set, in units of 1 Hz.</entry> </row> <row> <entry>__u32</entry> diff --git a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml index 6cc82010c736..b0d865933da6 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml @@ -134,7 +134,9 @@ the structure refers to a radio tuner the <entry spanname="hspan">The lowest tunable frequency in units of 62.5 kHz, or if the <structfield>capability</structfield> flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 -Hz. If multiple frequency bands are supported, then +Hz, or if the <structfield>capability</structfield> flag +<constant>V4L2_TUNER_CAP_1HZ</constant> is set, in units of 1 Hz. +If multiple frequency bands are supported, then <structfield>rangelow</structfield> is the lowest frequency of all the frequency bands.</entry> </row> @@ -144,7 +146,9 @@ of all the frequency bands.</entry> <entry spanname="hspan">The highest tunable frequency in units of 62.5 kHz, or if the <structfield>capability</structfield> flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5 -Hz. If multiple frequency bands are supported, then +Hz, or if the <structfield>capability</structfield> flag +<constant>V4L2_TUNER_CAP_1HZ</constant> is set, in units of 1 Hz. +If multiple frequency bands are supported, then <structfield>rangehigh</structfield> is the highest frequency of all the frequency bands.</entry> </row> @@ -270,7 +274,7 @@ applications must set the array to zero.</entry> <entry><constant>V4L2_TUNER_CAP_LOW</constant></entry> <entry>0x0001</entry> <entry>When set, tuning frequencies are expressed in units of -62.5 Hz, otherwise in units of 62.5 kHz.</entry> +62.5 Hz instead of 62.5 kHz.</entry> </row> <row> <entry><constant>V4L2_TUNER_CAP_NORM</constant></entry> @@ -360,6 +364,11 @@ radio tuners.</entry> <entry>The range to search when using the hardware seek functionality is programmable, see &VIDIOC-S-HW-FREQ-SEEK; for details.</entry> </row> + <row> + <entry><constant>V4L2_TUNER_CAP_1HZ</constant></entry> + <entry>0x1000</entry> + <entry>When set, tuning frequencies are expressed in units of 1 Hz instead of 62.5 kHz.</entry> + </row> </tbody> </tgroup> </table> diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index d5a3c97b206a..370d49d6fb64 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml @@ -296,6 +296,12 @@ modulator programming see <xref linkend="tuner" />.</entry> </row> <row> + <entry><constant>V4L2_CAP_SDR_CAPTURE</constant></entry> + <entry>0x00100000</entry> + <entry>The device supports the +<link linkend="sdr">SDR Capture</link> interface.</entry> + </row> + <row> <entry><constant>V4L2_CAP_READWRITE</constant></entry> <entry>0x01000000</entry> <entry>The device supports the <link 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 5b379e752194..a5fc4c4880f3 100644 --- a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml +++ b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml @@ -121,7 +121,9 @@ field and the &v4l2-tuner; <structfield>index</structfield> field.</entry> <entry>If non-zero, the lowest tunable frequency of the band to search in units of 62.5 kHz, or if the &v4l2-tuner; <structfield>capability</structfield> field has the -<constant>V4L2_TUNER_CAP_LOW</constant> flag set, in units of 62.5 Hz. +<constant>V4L2_TUNER_CAP_LOW</constant> flag set, in units of 62.5 Hz or if the &v4l2-tuner; +<structfield>capability</structfield> field has the +<constant>V4L2_TUNER_CAP_1HZ</constant> flag set, in units of 1 Hz. If <structfield>rangelow</structfield> is zero a reasonable default value is used.</entry> </row> @@ -131,7 +133,9 @@ is used.</entry> <entry>If non-zero, the highest tunable frequency of the band to search in units of 62.5 kHz, or if the &v4l2-tuner; <structfield>capability</structfield> field has the -<constant>V4L2_TUNER_CAP_LOW</constant> flag set, in units of 62.5 Hz. +<constant>V4L2_TUNER_CAP_LOW</constant> flag set, in units of 62.5 Hz or if the &v4l2-tuner; +<structfield>capability</structfield> field has the +<constant>V4L2_TUNER_CAP_1HZ</constant> flag set, in units of 1 Hz. If <structfield>rangehigh</structfield> is zero a reasonable default value is used.</entry> </row> diff --git a/Documentation/DocBook/media/v4l/vidioc-streamon.xml b/Documentation/DocBook/media/v4l/vidioc-streamon.xml index 65dff55079d7..df2c63d07bac 100644 --- a/Documentation/DocBook/media/v4l/vidioc-streamon.xml +++ b/Documentation/DocBook/media/v4l/vidioc-streamon.xml @@ -52,16 +52,24 @@ <para>The <constant>VIDIOC_STREAMON</constant> and <constant>VIDIOC_STREAMOFF</constant> ioctl start and stop the capture or output process during streaming (<link linkend="mmap">memory -mapping</link> or <link linkend="userp">user pointer</link>) I/O.</para> +mapping</link>, <link linkend="userp">user pointer</link> or +<link linkend="dmabuf">DMABUF</link>) I/O.</para> - <para>Specifically the capture hardware is disabled and no input + <para>Capture hardware is disabled and no input buffers are filled (if there are any empty buffers in the incoming queue) until <constant>VIDIOC_STREAMON</constant> has been called. -Accordingly the output hardware is disabled, no video signal is +Output hardware is disabled and no video signal is produced until <constant>VIDIOC_STREAMON</constant> has been called. The ioctl will succeed when at least one output buffer is in the incoming queue.</para> + <para>Memory-to-memory devices will not start until +<constant>VIDIOC_STREAMON</constant> has been called for both the capture +and output stream types.</para> + + <para>If <constant>VIDIOC_STREAMON</constant> fails then any already +queued buffers will remain queued.</para> + <para>The <constant>VIDIOC_STREAMOFF</constant> ioctl, apart of aborting or finishing any DMA in progress, unlocks any user pointer buffers locked in physical memory, and it removes all buffers from the @@ -70,14 +78,22 @@ dequeued yet will be lost, likewise all images enqueued for output but not transmitted yet. I/O returns to the same state as after calling &VIDIOC-REQBUFS; and can be restarted accordingly.</para> + <para>If buffers have been queued with &VIDIOC-QBUF; and +<constant>VIDIOC_STREAMOFF</constant> is called without ever having +called <constant>VIDIOC_STREAMON</constant>, then those queued buffers +will also be removed from the incoming queue and all are returned to the +same state as after calling &VIDIOC-REQBUFS; and can be restarted +accordingly.</para> + <para>Both ioctls take a pointer to an integer, the desired buffer or stream type. This is the same as &v4l2-requestbuffers; <structfield>type</structfield>.</para> <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> +when streaming is already stopped, then 0 is returned. Nothing happens in the +case of <constant>VIDIOC_STREAMON</constant>, but <constant>VIDIOC_STREAMOFF</constant> +will return queued buffers to their starting state as mentioned above.</para> <para>Note that applications can be preempted for unknown periods right before or after the <constant>VIDIOC_STREAMON</constant> or @@ -93,7 +109,7 @@ synchronize with other events.</para> <varlistentry> <term><errorcode>EINVAL</errorcode></term> <listitem> - <para>The buffer<structfield>type</structfield> is not supported, + <para>The buffer <structfield>type</structfield> is not supported, or no buffers have been allocated (memory mapping) or enqueued (output) yet.</para> </listitem> diff --git a/Documentation/DocBook/media_api.tmpl b/Documentation/DocBook/media_api.tmpl index ab56f89c8642..4decb46bfa76 100644 --- a/Documentation/DocBook/media_api.tmpl +++ b/Documentation/DocBook/media_api.tmpl @@ -34,22 +34,20 @@ <book id="media_api"> <bookinfo> -<title>LINUX MEDIA INFRASTRUCTURE API</title> - -<copyright> - <year>2009-2012</year> - <holder>LinuxTV Developers</holder> -</copyright> - -<legalnotice> - -<para>Permission is granted to copy, distribute and/or modify -this document under the terms of the GNU Free Documentation License, -Version 1.1 or any later version published by the Free Software -Foundation. A copy of the license is included in the chapter entitled -"GNU Free Documentation License"</para> -</legalnotice> - + <title>LINUX MEDIA INFRASTRUCTURE API</title> + + <copyright> + <year>2009-2014</year> + <holder>LinuxTV Developers</holder> + </copyright> + + <legalnotice> + <para>Permission is granted to copy, distribute and/or modify + this document under the terms of the GNU Free Documentation License, + Version 1.1 or any later version published by the Free Software + Foundation. A copy of the license is included in the chapter entitled + "GNU Free Documentation License"</para> + </legalnotice> </bookinfo> <toc></toc> <!-- autogenerated --> @@ -60,10 +58,11 @@ Foundation. A copy of the license is included in the chapter entitled <para>This document covers the Linux Kernel to Userspace API's used by video and radio streaming devices, including video cameras, analog and digital TV receiver cards, AM/FM receiver cards, - streaming capture devices.</para> + streaming capture and output devices, codec devices and remote + controllers.</para> <para>It is divided into four parts.</para> - <para>The first part covers radio, capture, - cameras and analog TV devices.</para> + <para>The first part covers radio, video capture and output, + cameras, analog TV devices and codecs.</para> <para>The second part covers the API used for digital TV and Internet reception via one of the several digital tv standards. While it is called as DVB API, @@ -75,55 +74,14 @@ Foundation. A copy of the license is included in the chapter entitled <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> - </preface> -<part id="v4l2spec"> -&sub-v4l2; -</part> -<part id="dvbapi"> -&sub-dvbapi; -</part> -<part id="v4ldvb_common"> -<partinfo> -<authorgroup> -<author> -<firstname>Mauro</firstname> -<surname>Chehab</surname> -<othername role="mi">Carvalho</othername> -<affiliation><address><email>mchehab@redhat.com</email></address></affiliation> -<contrib>Initial version.</contrib> -</author> -</authorgroup> -<copyright> - <year>2009-2012</year> - <holder>Mauro Carvalho Chehab</holder> -</copyright> - -<revhistory> -<!-- Put document revisions here, newest first. --> -<revision> -<revnumber>1.0.0</revnumber> -<date>2009-09-06</date> -<authorinitials>mcc</authorinitials> -<revremark>Initial revision</revremark> -</revision> -</revhistory> -</partinfo> - -<title>Remote Controller API</title> -<chapter id="remote_controllers"> -&sub-remote_controllers; -</chapter> -</part> -<part id="media_common"> -&sub-media-controller; -</part> - -<chapter id="gen_errors"> -&sub-gen-errors; -</chapter> +<part id="v4l2spec">&sub-v4l2;</part> +<part id="dvbapi">&sub-dvbapi;</part> +<part id="remotes">&sub-remote_controllers;</part> +<part id="media_common">&sub-media-controller;</part> +<chapter id="gen_errors">&sub-gen-errors;</chapter> &sub-fdl-appendix; diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 26b1e31d5a13..2a8e89e13e45 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -14,7 +14,10 @@ Read Documentation/SubmitChecklist for a list of items to check before submitting code. If you are submitting a driver, also read Documentation/SubmittingDrivers. - +Many of these steps describe the default behavior of the git version +control system; if you use git to prepare your patches, you'll find much +of the mechanical work done for you, though you'll still need to prepare +and document a sensible set of patches. -------------------------------------------- SECTION 1 - CREATING AND SENDING YOUR CHANGE @@ -25,7 +28,9 @@ SECTION 1 - CREATING AND SENDING YOUR CHANGE 1) "diff -up" ------------ -Use "diff -up" or "diff -uprN" to create patches. +Use "diff -up" or "diff -uprN" to create patches. git generates patches +in this form by default; if you're using git, you can skip this section +entirely. All changes to the Linux kernel occur in the form of patches, as generated by diff(1). When creating your patch, make sure to create it @@ -66,19 +71,14 @@ Make sure your patch does not include any extra files which do not belong in a patch submission. Make sure to review your patch -after- generated it with diff(1), to ensure accuracy. -If your changes produce a lot of deltas, you may want to look into -splitting them into individual patches which modify things in -logical stages. This will facilitate easier reviewing by other -kernel developers, very important if you want your patch accepted. -There are a number of scripts which can aid in this: - -Quilt: -http://savannah.nongnu.org/projects/quilt +If your changes produce a lot of deltas, you need to split them into +individual patches which modify things in logical stages; see section +#3. This will facilitate easier reviewing by other kernel developers, +very important if you want your patch accepted. -Andrew Morton's patch scripts: -http://userweb.kernel.org/~akpm/stuff/patch-scripts.tar.gz -Instead of these scripts, quilt is the recommended patch management -tool (see above). +If you're using git, "git rebase -i" can help you with this process. If +you're not using git, quilt <http://savannah.nongnu.org/projects/quilt> +is another popular alternative. @@ -106,8 +106,21 @@ I.e., the patch (series) and its description should be self-contained. This benefits both the patch merger(s) and reviewers. Some reviewers probably didn't even receive earlier versions of the patch. +Describe your changes in imperative mood, e.g. "make xyzzy do frotz" +instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy +to do frotz", as if you are giving orders to the codebase to change +its behaviour. + If the patch fixes a logged bug entry, refer to that bug entry by -number and URL. +number and URL. If the patch follows from a mailing list discussion, +give a URL to the mailing list archive; use the https://lkml.kernel.org/ +redirector with a Message-Id, to ensure that the links cannot become +stale. + +However, try to make your explanation understandable without external +resources. In addition to giving a URL to a mailing list archive or +bug, summarize the relevant points of the discussion that led to the +patch as submitted. If you want to refer to a specific commit, don't just refer to the SHA-1 ID of the commit. Please also include the oneline summary of @@ -594,7 +607,8 @@ patch. If you are going to include a diffstat after the "---" marker, please use diffstat options "-p 1 -w 70" so that filenames are listed from the top of the kernel source tree and don't use too much horizontal -space (easily fit in 80 columns, maybe with some indentation). +space (easily fit in 80 columns, maybe with some indentation). (git +generates appropriate diffstats by default.) See more details on the proper patch format in the following references. @@ -725,7 +739,7 @@ SECTION 3 - REFERENCES ---------------------- Andrew Morton, "The perfect patch" (tpp). - <http://userweb.kernel.org/~akpm/stuff/tpp.txt> + <http://www.ozlabs.org/~akpm/stuff/tpp.txt> Jeff Garzik, "Linux kernel patch submission format". <http://linux.yyz.us/patch-format.html> @@ -738,7 +752,7 @@ Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer". <http://www.kroah.com/log/linux/maintainer-05.html> NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people! - <http://marc.theaimsgroup.com/?l=linux-kernel&m=112112749912944&w=2> + <https://lkml.org/lkml/2005/7/11/336> Kernel Documentation/CodingStyle: <http://users.sosdg.org/~qiyong/lxr/source/Documentation/CodingStyle> diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README index 5a930c1528ad..2cce5401e323 100644 --- a/Documentation/arm/Marvell/README +++ b/Documentation/arm/Marvell/README @@ -83,14 +83,24 @@ EBU Armada family 88F6710 88F6707 88F6W11 + Product Brief: http://www.marvell.com/embedded-processors/armada-300/assets/Marvell_ARMADA_370_SoC.pdf + + Armada 375 Flavors: + 88F6720 + Product Brief: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA_375_SoC-01_product_brief.pdf + + Armada 380/385 Flavors: + 88F6810 + 88F6820 + 88F6828 Armada XP Flavors: MV78230 MV78260 MV78460 NOTE: not to be confused with the non-SMP 78xx0 SoCs + Product Brief: http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf - Product Brief: http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf No public datasheet available. Core: Sheeva ARMv7 compatible @@ -224,6 +234,11 @@ Berlin family (Digital Entertainment) Core: Marvell PJ4B (ARMv7), Tauros3 L2CC Homepage: http://www.marvell.com/digital-entertainment/armada-1500/ Product Brief: http://www.marvell.com/digital-entertainment/armada-1500/assets/Marvell-ARMADA-1500-Product-Brief.pdf + 88DE3114, Armada 1500 Pro + Design name: BG2-Q + Core: Quad Core ARM Cortex-A9, PL310 L2CC + Homepage: http://www.marvell.com/digital-entertainment/armada-1500-pro/ + Product Brief: http://www.marvell.com/digital-entertainment/armada-1500-pro/assets/Marvell_ARMADA_1500_PRO-01_product_brief.pdf 88DE???? Design name: BG3 Core: ARM Cortex-A15, CA15 integrated L2CC diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt index a9691cc48fe3..beb754e87c65 100644 --- a/Documentation/arm64/booting.txt +++ b/Documentation/arm64/booting.txt @@ -111,8 +111,14 @@ Before jumping into the kernel, the following conditions must be met: - Caches, MMUs The MMU must be off. Instruction cache may be on or off. - Data cache must be off and invalidated. - External caches (if present) must be configured and disabled. + The address range corresponding to the loaded kernel image must be + cleaned to the PoC. In the presence of a system cache or other + coherent masters with caches enabled, this will typically require + cache maintenance by VA rather than set/way operations. + System caches which respect the architected cache maintenance by VA + operations must be configured and may be enabled. + System caches which do not respect architected cache maintenance by VA + operations (not recommended) must be configured and disabled. - Architected timers CNTFRQ must be programmed with the timer frequency and CNTVOFF must diff --git a/Documentation/arm64/memory.txt b/Documentation/arm64/memory.txt index 85e24c4f215c..d50fa618371b 100644 --- a/Documentation/arm64/memory.txt +++ b/Documentation/arm64/memory.txt @@ -39,7 +39,7 @@ ffffffbffa000000 ffffffbffaffffff 16MB PCI I/O space ffffffbffb000000 ffffffbffbbfffff 12MB [guard] -ffffffbffbc00000 ffffffbffbdfffff 2MB earlyprintk device +ffffffbffbc00000 ffffffbffbdfffff 2MB fixed mappings ffffffbffbe00000 ffffffbffbffffff 2MB [guard] @@ -66,7 +66,7 @@ fffffdfffa000000 fffffdfffaffffff 16MB PCI I/O space fffffdfffb000000 fffffdfffbbfffff 12MB [guard] -fffffdfffbc00000 fffffdfffbdfffff 2MB earlyprintk device +fffffdfffbc00000 fffffdfffbdfffff 2MB fixed mappings fffffdfffbe00000 fffffdfffbffffff 2MB [guard] diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt index 2eccddffa6c8..0595c3f56ccf 100644 --- a/Documentation/blockdev/zram.txt +++ b/Documentation/blockdev/zram.txt @@ -21,7 +21,43 @@ Following shows a typical sequence of steps for using zram. This creates 4 devices: /dev/zram{0,1,2,3} (num_devices parameter is optional. Default: 1) -2) Set Disksize +2) Set max number of compression streams + Compression backend may use up to max_comp_streams compression streams, + thus allowing up to max_comp_streams concurrent compression operations. + By default, compression backend uses single compression stream. + + Examples: + #show max compression streams number + cat /sys/block/zram0/max_comp_streams + + #set max compression streams number to 3 + echo 3 > /sys/block/zram0/max_comp_streams + +Note: +In order to enable compression backend's multi stream support max_comp_streams +must be initially set to desired concurrency level before ZRAM device +initialisation. Once the device initialised as a single stream compression +backend (max_comp_streams equals to 1), you will see error if you try to change +the value of max_comp_streams because single stream compression backend +implemented as a special case by lock overhead issue and does not support +dynamic max_comp_streams. Only multi stream backend supports dynamic +max_comp_streams adjustment. + +3) Select compression algorithm + Using comp_algorithm device attribute one can see available and + currently selected (shown in square brackets) compression algortithms, + change selected compression algorithm (once the device is initialised + there is no way to change compression algorithm). + + Examples: + #show supported compression algorithms + cat /sys/block/zram0/comp_algorithm + lzo [lz4] + + #select lzo compression algorithm + echo lzo > /sys/block/zram0/comp_algorithm + +4) Set Disksize Set disk size by writing the value to sysfs node 'disksize'. The value can be either in bytes or you can use mem suffixes. Examples: @@ -33,32 +69,38 @@ Following shows a typical sequence of steps for using zram. echo 512M > /sys/block/zram0/disksize echo 1G > /sys/block/zram0/disksize -3) Activate: +Note: +There is little point creating a zram of greater than twice the size of memory +since we expect a 2:1 compression ratio. Note that zram uses about 0.1% of the +size of the disk when not in use so a huge zram is wasteful. + +5) Activate: mkswap /dev/zram0 swapon /dev/zram0 mkfs.ext4 /dev/zram1 mount /dev/zram1 /tmp -4) Stats: +6) Stats: Per-device statistics are exported as various nodes under /sys/block/zram<id>/ disksize num_reads num_writes + failed_reads + failed_writes invalid_io notify_free - discard zero_pages orig_data_size compr_data_size mem_used_total -5) Deactivate: +7) Deactivate: swapoff /dev/zram0 umount /dev/zram1 -6) Reset: +8) Reset: Write any positive value to 'reset' sysfs node echo 1 > /sys/block/zram0/reset echo 1 > /sys/block/zram1/reset diff --git a/Documentation/cgroups/memcg_test.txt b/Documentation/cgroups/memcg_test.txt index ce94a83a7d9a..80ac454704b8 100644 --- a/Documentation/cgroups/memcg_test.txt +++ b/Documentation/cgroups/memcg_test.txt @@ -24,7 +24,7 @@ Please note that implementation details can be changed. a page/swp_entry may be charged (usage += PAGE_SIZE) at - mem_cgroup_newpage_charge() + mem_cgroup_charge_anon() Called at new page fault and Copy-On-Write. mem_cgroup_try_charge_swapin() @@ -32,7 +32,7 @@ Please note that implementation details can be changed. Followed by charge-commit-cancel protocol. (With swap accounting) At commit, a charge recorded in swap_cgroup is removed. - mem_cgroup_cache_charge() + mem_cgroup_charge_file() Called at add_to_page_cache() mem_cgroup_cache_charge_swapin() diff --git a/Documentation/cgroups/resource_counter.txt b/Documentation/cgroups/resource_counter.txt index 5108afb3645c..762ca54eb929 100644 --- a/Documentation/cgroups/resource_counter.txt +++ b/Documentation/cgroups/resource_counter.txt @@ -76,15 +76,7 @@ to work with it. limit_fail_at parameter is set to the particular res_counter element where the charging failed. - d. int res_counter_charge_locked - (struct res_counter *rc, unsigned long val, bool force) - - The same as res_counter_charge(), but it must not acquire/release the - res_counter->lock internally (it must be called with res_counter->lock - held). The force parameter indicates whether we can bypass the limit. - - e. u64 res_counter_uncharge[_locked] - (struct res_counter *rc, unsigned long val) + d. u64 res_counter_uncharge(struct res_counter *rc, unsigned long val) When a resource is released (freed) it should be de-accounted from the resource counter it was accounted to. This is called @@ -93,7 +85,7 @@ to work with it. The _locked routines imply that the res_counter->lock is taken. - f. u64 res_counter_uncharge_until + e. u64 res_counter_uncharge_until (struct res_counter *rc, struct res_counter *top, unsigned long val) diff --git a/Documentation/clk.txt b/Documentation/clk.txt index 699ef2a323b1..c9c399af7c08 100644 --- a/Documentation/clk.txt +++ b/Documentation/clk.txt @@ -255,3 +255,37 @@ are sorted out. To bypass this disabling, include "clk_ignore_unused" in the bootargs to the kernel. + + Part 7 - Locking + +The common clock framework uses two global locks, the prepare lock and the +enable lock. + +The enable lock is a spinlock and is held across calls to the .enable, +.disable and .is_enabled operations. Those operations are thus not allowed to +sleep, and calls to the clk_enable(), clk_disable() and clk_is_enabled() API +functions are allowed in atomic context. + +The prepare lock is a mutex and is held across calls to all other operations. +All those operations are allowed to sleep, and calls to the corresponding API +functions are not allowed in atomic context. + +This effectively divides operations in two groups from a locking perspective. + +Drivers don't need to manually protect resources shared between the operations +of one group, regardless of whether those resources are shared by multiple +clocks or not. However, access to resources that are shared between operations +of the two groups needs to be protected by the drivers. An example of such a +resource would be a register that controls both the clock rate and the clock +enable/disable state. + +The clock framework is reentrant, in that a driver is allowed to call clock +framework functions from within its implementation of clock operations. This +can for instance cause a .set_rate operation of one clock being called from +within the .set_rate operation of another clock. This case must be considered +in the driver implementations, but the code flow is usually controlled by the +driver in that case. + +Note that locking must also be considered when code outside of the common +clock framework needs to access resources used by the clock operations. This +is considered out of scope of this document. diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt index be675d2d15a7..a0b005d2bd95 100644 --- a/Documentation/cpu-hotplug.txt +++ b/Documentation/cpu-hotplug.txt @@ -312,12 +312,57 @@ things will happen if a notifier in path sent a BAD notify code. Q: I don't see my action being called for all CPUs already up and running? A: Yes, CPU notifiers are called only when new CPUs are on-lined or offlined. If you need to perform some action for each cpu already in the system, then + do this: for_each_online_cpu(i) { foobar_cpu_callback(&foobar_cpu_notifier, CPU_UP_PREPARE, i); foobar_cpu_callback(&foobar_cpu_notifier, CPU_ONLINE, i); } + However, if you want to register a hotplug callback, as well as perform + some initialization for CPUs that are already online, then do this: + + Version 1: (Correct) + --------- + + cpu_notifier_register_begin(); + + for_each_online_cpu(i) { + foobar_cpu_callback(&foobar_cpu_notifier, + CPU_UP_PREPARE, i); + foobar_cpu_callback(&foobar_cpu_notifier, + CPU_ONLINE, i); + } + + /* Note the use of the double underscored version of the API */ + __register_cpu_notifier(&foobar_cpu_notifier); + + cpu_notifier_register_done(); + + Note that the following code is *NOT* the right way to achieve this, + because it is prone to an ABBA deadlock between the cpu_add_remove_lock + and the cpu_hotplug.lock. + + Version 2: (Wrong!) + --------- + + get_online_cpus(); + + for_each_online_cpu(i) { + foobar_cpu_callback(&foobar_cpu_notifier, + CPU_UP_PREPARE, i); + foobar_cpu_callback(&foobar_cpu_notifier, + CPU_ONLINE, i); + } + + register_cpu_notifier(&foobar_cpu_notifier); + + put_online_cpus(); + + So always use the first version shown above when you want to register + callbacks as well as initialize the already online CPUs. + + Q: If i would like to develop cpu hotplug support for a new architecture, what do i need at a minimum? A: The following are what is required for CPU hotplug infrastructure to work diff --git a/Documentation/device-mapper/era.txt b/Documentation/device-mapper/era.txt new file mode 100644 index 000000000000..3c6d01be3560 --- /dev/null +++ b/Documentation/device-mapper/era.txt @@ -0,0 +1,108 @@ +Introduction +============ + +dm-era is a target that behaves similar to the linear target. In +addition it keeps track of which blocks were written within a user +defined period of time called an 'era'. Each era target instance +maintains the current era as a monotonically increasing 32-bit +counter. + +Use cases include tracking changed blocks for backup software, and +partially invalidating the contents of a cache to restore cache +coherency after rolling back a vendor snapshot. + +Constructor +=========== + + era <metadata dev> <origin dev> <block size> + + metadata dev : fast device holding the persistent metadata + origin dev : device holding data blocks that may change + block size : block size of origin data device, granularity that is + tracked by the target + +Messages +======== + +None of the dm messages take any arguments. + +checkpoint +---------- + +Possibly move to a new era. You shouldn't assume the era has +incremented. After sending this message, you should check the +current era via the status line. + +take_metadata_snap +------------------ + +Create a clone of the metadata, to allow a userland process to read it. + +drop_metadata_snap +------------------ + +Drop the metadata snapshot. + +Status +====== + +<metadata block size> <#used metadata blocks>/<#total metadata blocks> +<current era> <held metadata root | '-'> + +metadata block size : Fixed block size for each metadata block in + sectors +#used metadata blocks : Number of metadata blocks used +#total metadata blocks : Total number of metadata blocks +current era : The current era +held metadata root : The location, in blocks, of the metadata root + that has been 'held' for userspace read + access. '-' indicates there is no held root + +Detailed use case +================= + +The scenario of invalidating a cache when rolling back a vendor +snapshot was the primary use case when developing this target: + +Taking a vendor snapshot +------------------------ + +- Send a checkpoint message to the era target +- Make a note of the current era in its status line +- Take vendor snapshot (the era and snapshot should be forever + associated now). + +Rolling back to an vendor snapshot +---------------------------------- + +- Cache enters passthrough mode (see: dm-cache's docs in cache.txt) +- Rollback vendor storage +- Take metadata snapshot +- Ascertain which blocks have been written since the snapshot was taken + by checking each block's era +- Invalidate those blocks in the caching software +- Cache returns to writeback/writethrough mode + +Memory usage +============ + +The target uses a bitset to record writes in the current era. It also +has a spare bitset ready for switching over to a new era. Other than +that it uses a few 4k blocks for updating metadata. + + (4 * nr_blocks) bytes + buffers + +Resilience +========== + +Metadata is updated on disk before a write to a previously unwritten +block is performed. As such dm-era should not be effected by a hard +crash such as power failure. + +Userland tools +============== + +Userland tools are found in the increasingly poorly named +thin-provisioning-tools project: + + https://github.com/jthornber/thin-provisioning-tools diff --git a/Documentation/devices.txt b/Documentation/devices.txt index 087d2122b204..87b4c5e82d39 100644 --- a/Documentation/devices.txt +++ b/Documentation/devices.txt @@ -353,6 +353,7 @@ Your cooperation is appreciated. 133 = /dev/exttrp External device trap 134 = /dev/apm_bios Advanced Power Management BIOS 135 = /dev/rtc Real Time Clock + 137 = /dev/vhci Bluetooth virtual HCI driver 139 = /dev/openprom SPARC OpenBoot PROM 140 = /dev/relay8 Berkshire Products Octal relay card 141 = /dev/relay16 Berkshire Products ISO-16 relay card @@ -1493,10 +1494,17 @@ Your cooperation is appreciated. 64 = /dev/radio0 Radio device ... 127 = /dev/radio63 Radio device + 128 = /dev/swradio0 Software Defined Radio device + ... + 191 = /dev/swradio63 Software Defined Radio device 224 = /dev/vbi0 Vertical blank interrupt ... 255 = /dev/vbi31 Vertical blank interrupt + Minor numbers are allocated dynamically unless + CONFIG_VIDEO_FIXED_MINOR_RANGES (default n) + configuration option is set. + 81 block I2O hard disk 0 = /dev/i2o/hdq 17th I2O hard disk, whole disk 16 = /dev/i2o/hdr 18th I2O hard disk, whole disk diff --git a/Documentation/devicetree/bindings/arm/armada-375.txt b/Documentation/devicetree/bindings/arm/armada-375.txt new file mode 100644 index 000000000000..867d0b80cb8f --- /dev/null +++ b/Documentation/devicetree/bindings/arm/armada-375.txt @@ -0,0 +1,9 @@ +Marvell Armada 375 Platforms Device Tree Bindings +------------------------------------------------- + +Boards with a SoC of the Marvell Armada 375 family shall have the +following property: + +Required root node property: + +compatible: must contain "marvell,armada375" diff --git a/Documentation/devicetree/bindings/arm/armada-38x.txt b/Documentation/devicetree/bindings/arm/armada-38x.txt new file mode 100644 index 000000000000..11f2330a6554 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/armada-38x.txt @@ -0,0 +1,10 @@ +Marvell Armada 38x Platforms Device Tree Bindings +------------------------------------------------- + +Boards with a SoC of the Marvell Armada 38x family shall have the +following property: + +Required root node property: + + - compatible: must contain either "marvell,armada380" or + "marvell,armada385" depending on the variant of the SoC being used. diff --git a/Documentation/devicetree/bindings/arm/bcm/bcm21664.txt b/Documentation/devicetree/bindings/arm/bcm/bcm21664.txt new file mode 100644 index 000000000000..e0774255e1a6 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/bcm/bcm21664.txt @@ -0,0 +1,15 @@ +Broadcom BCM21664 device tree bindings +-------------------------------------- + +This document describes the device tree bindings for boards with the BCM21664 +SoC. + +Required root node property: + - compatible: brcm,bcm21664 + +Example: + / { + model = "BCM21664 SoC"; + compatible = "brcm,bcm21664"; + [...] + } diff --git a/Documentation/devicetree/bindings/arm/bcm/kona-resetmgr.txt b/Documentation/devicetree/bindings/arm/bcm/kona-resetmgr.txt new file mode 100644 index 000000000000..93f31ca1ef4b --- /dev/null +++ b/Documentation/devicetree/bindings/arm/bcm/kona-resetmgr.txt @@ -0,0 +1,14 @@ +Broadcom Kona Family Reset Manager +---------------------------------- + +The reset manager is used on the Broadcom BCM21664 SoC. + +Required properties: + - compatible: brcm,bcm21664-resetmgr + - reg: memory address & range + +Example: + brcm,resetmgr@35001f00 { + compatible = "brcm,bcm21664-resetmgr"; + reg = <0x35001f00 0x24>; + }; diff --git a/Documentation/devicetree/bindings/arm/bcm4708.txt b/Documentation/devicetree/bindings/arm/bcm4708.txt new file mode 100644 index 000000000000..6b0f49f6f499 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/bcm4708.txt @@ -0,0 +1,8 @@ +Broadcom BCM4708 device tree bindings +------------------------------------------- + +Boards with the BCM4708 SoC shall have the following properties: + +Required root node property: + +compatible = "brcm,bcm4708"; diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index 91304353eea4..333f4aea3029 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -180,7 +180,11 @@ nodes to be present and contain the properties described below. be one of: "spin-table" "psci" - # On ARM 32-bit systems this property is optional. + # On ARM 32-bit systems this property is optional and + can be one of: + "qcom,gcc-msm8660" + "qcom,kpss-acc-v1" + "qcom,kpss-acc-v2" - cpu-release-addr Usage: required for systems that have an "enable-method" @@ -191,6 +195,21 @@ nodes to be present and contain the properties described below. property identifying a 64-bit zero-initialised memory location. + - qcom,saw + Usage: required for systems that have an "enable-method" + property value of "qcom,kpss-acc-v1" or + "qcom,kpss-acc-v2" + Value type: <phandle> + Definition: Specifies the SAW[1] node associated with this CPU. + + - qcom,acc + Usage: required for systems that have an "enable-method" + property value of "qcom,kpss-acc-v1" or + "qcom,kpss-acc-v2" + Value type: <phandle> + Definition: Specifies the ACC[2] node associated with this CPU. + + Example 1 (dual-cluster big.LITTLE system 32-bit): cpus { @@ -382,3 +401,7 @@ cpus { cpu-release-addr = <0 0x20000000>; }; }; + +-- +[1] arm/msm/qcom,saw2.txt +[2] arm/msm/qcom,kpss-acc.txt diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt index bae0d87a38b2..5573c08d3180 100644 --- a/Documentation/devicetree/bindings/arm/gic.txt +++ b/Documentation/devicetree/bindings/arm/gic.txt @@ -50,6 +50,11 @@ Optional regions, used when the GIC doesn't have banked registers. The offset is cpu-offset * cpu-nr. +- arm,routable-irqs : Total number of gic irq inputs which are not directly + connected from the peripherals, but are routed dynamically + by a crossbar/multiplexer preceding the GIC. The GIC irq + input line is assigned dynamically when the corresponding + peripheral's crossbar line is mapped. Example: intc: interrupt-controller@fff11000 { @@ -57,6 +62,7 @@ Example: #interrupt-cells = <3>; #address-cells = <1>; interrupt-controller; + arm,routable-irqs = <160>; reg = <0xfff11000 0x1000>, <0xfff10100 0x100>; }; diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt index 8c7a4653508d..df0a452b8526 100644 --- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt +++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt @@ -30,3 +30,17 @@ Example: resume-offset = <0x308>; reboot-offset = <0x4>; }; + +PCTRL: Peripheral misc control register + +Required Properties: +- compatible: "hisilicon,pctrl" +- reg: Address and size of pctrl. + +Example: + + /* for Hi3620 */ + pctrl: pctrl@fca09000 { + compatible = "hisilicon,pctrl"; + reg = <0xfca09000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/arm/keystone/keystone.txt b/Documentation/devicetree/bindings/arm/keystone/keystone.txt index 63c0e6ae5cf7..59d7a46f85eb 100644 --- a/Documentation/devicetree/bindings/arm/keystone/keystone.txt +++ b/Documentation/devicetree/bindings/arm/keystone/keystone.txt @@ -8,3 +8,13 @@ Required properties: - compatible: All TI specific devices present in Keystone SOC should be in the form "ti,keystone-*". Generic devices like gic, arch_timers, ns16550 type UART should use the specified compatible for those devices. + +Boards: +- Keystone 2 Hawking/Kepler EVM + compatible = "ti,k2hk-evm","ti,keystone" + +- Keystone 2 Lamarr EVM + compatible = "ti,k2l-evm","ti,keystone" + +- Keystone 2 Edison EVM + compatible = "ti,k2e-evm","ti,keystone" diff --git a/Documentation/devicetree/bindings/arm/marvell,berlin.txt b/Documentation/devicetree/bindings/arm/marvell,berlin.txt index 737afa5f8148..0677003e1476 100644 --- a/Documentation/devicetree/bindings/arm/marvell,berlin.txt +++ b/Documentation/devicetree/bindings/arm/marvell,berlin.txt @@ -12,6 +12,7 @@ SoC and board used. Currently known SoC compatibles are: "marvell,berlin2" for Marvell Armada 1500 (BG2, 88DE3100), "marvell,berlin2cd" for Marvell Armada 1500-mini (BG2CD, 88DE3005) "marvell,berlin2ct" for Marvell Armada ? (BG2CT, 88DE????) + "marvell,berlin2q" for Marvell Armada 1500-pro (BG2Q, 88DE3114) "marvell,berlin3" for Marvell Armada ? (BG3, 88DE????) * Example: diff --git a/Documentation/devicetree/bindings/arm/mrvl/feroceon.txt b/Documentation/devicetree/bindings/arm/mrvl/feroceon.txt new file mode 100644 index 000000000000..0d244b999d10 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mrvl/feroceon.txt @@ -0,0 +1,16 @@ +* Marvell Feroceon Cache + +Required properties: +- compatible : Should be either "marvell,feroceon-cache" or + "marvell,kirkwood-cache". + +Optional properties: +- reg : Address of the L2 cache control register. Mandatory for + "marvell,kirkwood-cache", not used by "marvell,feroceon-cache" + + +Example: + l2: l2-cache@20128 { + compatible = "marvell,kirkwood-cache"; + reg = <0x20128 0x4>; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt new file mode 100644 index 000000000000..1333db9acfee --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt @@ -0,0 +1,30 @@ +Krait Processor Sub-system (KPSS) Application Clock Controller (ACC) + +The KPSS ACC provides clock, power domain, and reset control to a Krait CPU. +There is one ACC register region per CPU within the KPSS remapped region as +well as an alias register region that remaps accesses to the ACC associated +with the CPU accessing the region. + +PROPERTIES + +- compatible: + Usage: required + Value type: <string> + Definition: should be one of: + "qcom,kpss-acc-v1" + "qcom,kpss-acc-v2" + +- reg: + Usage: required + Value type: <prop-encoded-array> + Definition: the first element specifies the base address and size of + the register region. An optional second element specifies + the base address and size of the alias register region. + +Example: + + clock-controller@2088000 { + compatible = "qcom,kpss-acc-v2"; + reg = <0x02088000 0x1000>, + <0x02008000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt new file mode 100644 index 000000000000..1505fb8e131a --- /dev/null +++ b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt @@ -0,0 +1,35 @@ +SPM AVS Wrapper 2 (SAW2) + +The SAW2 is a wrapper around the Subsystem Power Manager (SPM) and the +Adaptive Voltage Scaling (AVS) hardware. The SPM is a programmable +micro-controller that transitions a piece of hardware (like a processor or +subsystem) into and out of low power modes via a direct connection to +the PMIC. It can also be wired up to interact with other processors in the +system, notifying them when a low power state is entered or exited. + +PROPERTIES + +- compatible: + Usage: required + Value type: <string> + Definition: shall contain "qcom,saw2". A more specific value should be + one of: + "qcom,saw2-v1" + "qcom,saw2-v1.1" + "qcom,saw2-v2" + "qcom,saw2-v2.1" + +- reg: + Usage: required + Value type: <prop-encoded-array> + Definition: the first element specifies the base address and size of + the register region. An optional second element specifies + the base address and size of the alias register region. + + +Example: + + regulator@2099000 { + compatible = "qcom,saw2"; + reg = <0x02099000 0x1000>, <0x02009000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/arm/mvebu-system-controller.txt b/Documentation/devicetree/bindings/arm/mvebu-system-controller.txt index 081c6a786c8a..d24ab2ebf8a7 100644 --- a/Documentation/devicetree/bindings/arm/mvebu-system-controller.txt +++ b/Documentation/devicetree/bindings/arm/mvebu-system-controller.txt @@ -1,12 +1,13 @@ MVEBU System Controller ----------------------- -MVEBU (Marvell SOCs: Armada 370/XP, Dove, mv78xx0, Kirkwood, Orion5x) +MVEBU (Marvell SOCs: Armada 370/375/XP, Dove, mv78xx0, Kirkwood, Orion5x) Required properties: - compatible: one of: - "marvell,orion-system-controller" - "marvell,armada-370-xp-system-controller" + - "marvell,armada-375-system-controller" - reg: Should contain system controller registers location and length. Example: diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt b/Documentation/devicetree/bindings/arm/omap/crossbar.txt new file mode 100644 index 000000000000..fb88585cfb93 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt @@ -0,0 +1,27 @@ +Some socs have a large number of interrupts requests to service +the needs of its many peripherals and subsystems. All of the +interrupt lines from the subsystems are not needed at the same +time, so they have to be muxed to the irq-controller appropriately. +In such places a interrupt controllers are preceded by an CROSSBAR +that provides flexibility in muxing the device requests to the controller +inputs. + +Required properties: +- compatible : Should be "ti,irq-crossbar" +- reg: Base address and the size of the crossbar registers. +- ti,max-irqs: Total number of irqs available at the interrupt controller. +- ti,reg-size: Size of a individual register in bytes. Every individual + register is assumed to be of same size. Valid sizes are 1, 2, 4. +- ti,irqs-reserved: List of the reserved irq lines that are not muxed using + crossbar. These interrupt lines are reserved in the soc, + so crossbar bar driver should not consider them as free + lines. + +Examples: + crossbar_mpu: @4a020000 { + compatible = "ti,irq-crossbar"; + reg = <0x4a002a48 0x130>; + ti,max-irqs = <160>; + ti,reg-size = <2>; + ti,irqs-reserved = <0 1 2 3 5 6 131 132 139 140>; + }; diff --git a/Documentation/devicetree/bindings/arm/omap/dmm.txt b/Documentation/devicetree/bindings/arm/omap/dmm.txt new file mode 100644 index 000000000000..8bd6d0a238a8 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/omap/dmm.txt @@ -0,0 +1,22 @@ +OMAP Dynamic Memory Manager (DMM) bindings + +The dynamic memory manager (DMM) is a module located immediately in front of the +SDRAM controllers (called EMIFs on OMAP). DMM manages various aspects of memory +accesses such as priority generation amongst initiators, configuration of SDRAM +interleaving, optimizing transfer of 2D block objects, and provide MMU-like page +translation for initiators which need contiguous dma bus addresses. + +Required properties: +- compatible: Should contain "ti,omap4-dmm" for OMAP4 family + Should contain "ti,omap5-dmm" for OMAP5 and DRA7x family +- reg: Contains DMM register address range (base address and length) +- interrupts: Should contain an interrupt-specifier for DMM_IRQ. +- ti,hwmods: Name of the hwmod associated to DMM, which is typically "dmm" + +Example: + +dmm@4e000000 { + compatible = "ti,omap4-dmm"; + reg = <0x4e000000 0x800>; + ti,hwmods = "dmm"; +}; diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt index af9b4a0d902b..36ede19a1630 100644 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt @@ -99,6 +99,9 @@ Boards: - OMAP4 PandaBoard : Low cost community board compatible = "ti,omap4-panda", "ti,omap4430" +- OMAP4 DuoVero with Parlor : Commercial expansion board with daughter board + compatible = "gumstix,omap4-duovero-parlor", "gumstix,omap4-duovero", "ti,omap4430", "ti,omap4"; + - OMAP3 EVM : Software Development Board for OMAP35x, AM/DM37x compatible = "ti,omap3-evm", "ti,omap3" @@ -114,5 +117,8 @@ Boards: - AM43x EPOS EVM compatible = "ti,am43x-epos-evm", "ti,am4372", "ti,am43" +- AM437x GP EVM + compatible = "ti,am437x-gp-evm", "ti,am4372", "ti,am43" + - DRA7 EVM: Software Developement Board for DRA7XX compatible = "ti,dra7-evm", "ti,dra7" diff --git a/Documentation/devicetree/bindings/arm/pmu.txt b/Documentation/devicetree/bindings/arm/pmu.txt index 3e1e498fea96..fe5cef8976cb 100644 --- a/Documentation/devicetree/bindings/arm/pmu.txt +++ b/Documentation/devicetree/bindings/arm/pmu.txt @@ -9,6 +9,7 @@ Required properties: - compatible : should be one of "arm,armv8-pmuv3" "arm,cortex-a15-pmu" + "arm,cortex-a12-pmu" "arm,cortex-a9-pmu" "arm,cortex-a8-pmu" "arm,cortex-a7-pmu" @@ -16,7 +17,14 @@ Required properties: "arm,arm11mpcore-pmu" "arm,arm1176-pmu" "arm,arm1136-pmu" -- interrupts : 1 combined interrupt or 1 per core. + "qcom,krait-pmu" +- interrupts : 1 combined interrupt or 1 per core. If the interrupt is a per-cpu + interrupt (PPI) then 1 interrupt should be specified. + +Optional properties: + +- qcom,no-pc-write : Indicates that this PMU doesn't support the 0xc and 0xd + events. Example: diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu.txt b/Documentation/devicetree/bindings/arm/rockchip/pmu.txt new file mode 100644 index 000000000000..3ee9b428b2f7 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/rockchip/pmu.txt @@ -0,0 +1,16 @@ +Rockchip power-management-unit: +------------------------------- + +The pmu is used to turn off and on different power domains of the SoCs +This includes the power to the CPU cores. + +Required node properties: +- compatible value : = "rockchip,rk3066-pmu"; +- reg : physical base address and the size of the registers window + +Example: + + pmu@20004000 { + compatible = "rockchip,rk3066-pmu"; + reg = <0x20004000 0x100>; + }; diff --git a/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt b/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt new file mode 100644 index 000000000000..d9416fb8db6f --- /dev/null +++ b/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt @@ -0,0 +1,30 @@ +Rockchip SRAM for smp bringup: +------------------------------ + +Rockchip's smp-capable SoCs use the first part of the sram for the bringup +of the cores. Once the core gets powered up it executes the code that is +residing at the very beginning of the sram. + +Therefore a reserved section sub-node has to be added to the mmio-sram +declaration. + +Required sub-node properties: +- compatible : should be "rockchip,rk3066-smp-sram" + +The rest of the properties should follow the generic mmio-sram discription +found in ../../misc/sram.txt + +Example: + + sram: sram@10080000 { + compatible = "mmio-sram"; + reg = <0x10080000 0x10000>; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + smp-sram@10080000 { + compatible = "rockchip,rk3066-smp-sram"; + reg = <0x10080000 0x50>; + }; + }; diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt b/Documentation/devicetree/bindings/arm/samsung/pmu.txt new file mode 100644 index 000000000000..f1f155255f28 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt @@ -0,0 +1,15 @@ +SAMSUNG Exynos SoC series PMU Registers + +Properties: + - compatible : should contain two values. First value must be one from following list: + - "samsung,exynos5250-pmu" - for Exynos5250 SoC, + - "samsung,exynos5420-pmu" - for Exynos5420 SoC. + second value must be always "syscon". + + - reg : offset and length of the register set. + +Example : +pmu_system_controller: system-controller@10040000 { + compatible = "samsung,exynos5250-pmu", "syscon"; + reg = <0x10040000 0x5000>; +}; diff --git a/Documentation/devicetree/bindings/arm/topology.txt b/Documentation/devicetree/bindings/arm/topology.txt index 4aa20e7a424e..1061faf5f602 100644 --- a/Documentation/devicetree/bindings/arm/topology.txt +++ b/Documentation/devicetree/bindings/arm/topology.txt @@ -75,9 +75,10 @@ The cpu-map node can only contain three types of child nodes: whose bindings are described in paragraph 3. -The nodes describing the CPU topology (cluster/core/thread) can only be -defined within the cpu-map node. -Any other configuration is consider invalid and therefore must be ignored. +The nodes describing the CPU topology (cluster/core/thread) can only +be defined within the cpu-map node and every core/thread in the system +must be defined within the topology. Any other configuration is +invalid and therefore must be ignored. =========================================== 2.1 - cpu-map child nodes naming convention diff --git a/Documentation/devicetree/bindings/ata/exynos-sata-phy.txt b/Documentation/devicetree/bindings/ata/exynos-sata-phy.txt deleted file mode 100644 index 37824fac688e..000000000000 --- a/Documentation/devicetree/bindings/ata/exynos-sata-phy.txt +++ /dev/null @@ -1,14 +0,0 @@ -* Samsung SATA PHY Controller - -SATA PHY nodes are defined to describe on-chip SATA Physical layer controllers. -Each SATA PHY controller should have its own node. - -Required properties: -- compatible : compatible list, contains "samsung,exynos5-sata-phy" -- reg : <registers mapping> - -Example: - sata@ffe07000 { - compatible = "samsung,exynos5-sata-phy"; - reg = <0xffe07000 0x1000>; - }; diff --git a/Documentation/devicetree/bindings/ata/exynos-sata.txt b/Documentation/devicetree/bindings/ata/exynos-sata.txt index 0849f1025e34..cb48448247ea 100644 --- a/Documentation/devicetree/bindings/ata/exynos-sata.txt +++ b/Documentation/devicetree/bindings/ata/exynos-sata.txt @@ -4,14 +4,27 @@ SATA nodes are defined to describe on-chip Serial ATA controllers. Each SATA controller should have its own node. Required properties: -- compatible : compatible list, contains "samsung,exynos5-sata" -- interrupts : <interrupt mapping for SATA IRQ> -- reg : <registers mapping> -- samsung,sata-freq : <frequency in MHz> +- compatible : compatible list, contains "samsung,exynos5-sata" +- interrupts : <interrupt mapping for SATA IRQ> +- reg : <registers mapping> +- samsung,sata-freq : <frequency in MHz> +- phys : Must contain exactly one entry as specified + in phy-bindings.txt +- phy-names : Must be "sata-phy" + +Optional properties: +- clocks : Must contain an entry for each entry in clock-names. +- clock-names : Shall be "sata" for the external SATA bus clock, + and "sclk_sata" for the internal controller clock. Example: - sata@ffe08000 { - compatible = "samsung,exynos5-sata"; - reg = <0xffe08000 0x1000>; - interrupts = <115>; - }; + sata@122f0000 { + compatible = "snps,dwc-ahci"; + samsung,sata-freq = <66>; + reg = <0x122f0000 0x1ff>; + interrupts = <0 115 0>; + clocks = <&clock 277>, <&clock 143>; + clock-names = "sata", "sclk_sata"; + phys = <&sata_phy>; + phy-names = "sata-phy"; + }; diff --git a/Documentation/devicetree/bindings/bus/imx-weim.txt b/Documentation/devicetree/bindings/bus/imx-weim.txt index 0fd76c405208..6630d842c7a3 100644 --- a/Documentation/devicetree/bindings/bus/imx-weim.txt +++ b/Documentation/devicetree/bindings/bus/imx-weim.txt @@ -8,7 +8,12 @@ The actual devices are instantiated from the child nodes of a WEIM node. Required properties: - - compatible: Should be set to "fsl,<soc>-weim" + - compatible: Should contain one of the following: + "fsl,imx1-weim" + "fsl,imx27-weim" + "fsl,imx51-weim" + "fsl,imx50-weim" + "fsl,imx6q-weim" - reg: A resource specifier for the register space (see the example below) - clocks: the clock, see the example below. @@ -19,6 +24,26 @@ Required properties: <cs-number> 0 <physical address of mapping> <size> +Optional properties: + + - fsl,weim-cs-gpr: For "fsl,imx50-weim" and "fsl,imx6q-weim" type of + devices, it should be the phandle to the system General + Purpose Register controller that contains WEIM CS GPR + register, e.g. IOMUXC_GPR1 on i.MX6Q. IOMUXC_GPR1[11:0] + should be set up as one of the following 4 possible + values depending on the CS space configuration. + + IOMUXC_GPR1[11:0] CS0 CS1 CS2 CS3 + --------------------------------------------- + 05 128M 0M 0M 0M + 033 64M 64M 0M 0M + 0113 64M 32M 32M 0M + 01111 32M 32M 32M 32M + + In case that the property is absent, the reset value or + what bootloader sets up in IOMUXC_GPR1[11:0] will be + used. + Timing property for child nodes. It is mandatory, not optional. - fsl,weim-cs-timing: The timing array, contains timing values for the @@ -43,6 +68,7 @@ Example for an imx6q-sabreauto board, the NOR flash connected to the WEIM: #address-cells = <2>; #size-cells = <1>; ranges = <0 0 0x08000000 0x08000000>; + fsl,weim-cs-gpr = <&gpr>; nor@0,0 { compatible = "cfi-flash"; diff --git a/Documentation/devicetree/bindings/clock/altr_socfpga.txt b/Documentation/devicetree/bindings/clock/altr_socfpga.txt index 0045433eae1f..5dfd145d3ccf 100644 --- a/Documentation/devicetree/bindings/clock/altr_socfpga.txt +++ b/Documentation/devicetree/bindings/clock/altr_socfpga.txt @@ -23,3 +23,8 @@ Optional properties: and the bit index. - div-reg : For "socfpga-gate-clk", div-reg contains the divider register, bit shift, and width. +- clk-phase : For the sdmmc_clk, contains the value of the clock phase that controls + the SDMMC CIU clock. The first value is the clk_sample(smpsel), and the second + value is the cclk_in_drv(drvsel). The clk-phase is used to enable the correct + hold/delay times that is needed for the SD/MMC CIU clock. The values of both + can be 0-315 degrees, in 45 degree increments. diff --git a/Documentation/devicetree/bindings/clock/arm-integrator.txt b/Documentation/devicetree/bindings/clock/arm-integrator.txt new file mode 100644 index 000000000000..652914b17b95 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/arm-integrator.txt @@ -0,0 +1,34 @@ +Clock bindings for ARM Integrator Core Module clocks + +Auxilary Oscillator Clock + +This is a configurable clock fed from a 24 MHz chrystal, +used for generating e.g. video clocks. It is located on the +core module and there is only one of these. + +This clock node *must* be a subnode of the core module, since +it obtains the base address for it's address range from its +parent node. + + +Required properties: +- compatible: must be "arm,integrator-cm-auxosc" +- #clock-cells: must be <0> + +Optional properties: +- clocks: parent clock(s) + +Example: + +core-module@10000000 { + xtal24mhz: xtal24mhz@24M { + #clock-cells = <0>; + compatible = "fixed-clock"; + clock-frequency = <24000000>; + }; + auxosc: cm_aux_osc@25M { + #clock-cells = <0>; + compatible = "arm,integrator-cm-auxosc"; + clocks = <&xtal24mhz>; + }; +}; diff --git a/Documentation/devicetree/bindings/clock/axi-clkgen.txt b/Documentation/devicetree/bindings/clock/axi-clkgen.txt index 028b493e97ff..20e1704e7df2 100644 --- a/Documentation/devicetree/bindings/clock/axi-clkgen.txt +++ b/Documentation/devicetree/bindings/clock/axi-clkgen.txt @@ -5,7 +5,7 @@ This binding uses the common clock binding[1]. [1] Documentation/devicetree/bindings/clock/clock-bindings.txt Required properties: -- compatible : shall be "adi,axi-clkgen". +- compatible : shall be "adi,axi-clkgen-1.00.a" or "adi,axi-clkgen-2.00.a". - #clock-cells : from common clock binding; Should always be set to 0. - reg : Address and length of the axi-clkgen register set. - clocks : Phandle and clock specifier for the parent clock. diff --git a/Documentation/devicetree/bindings/clock/clock-bindings.txt b/Documentation/devicetree/bindings/clock/clock-bindings.txt index 7c52c29d99fa..700e7aac3717 100644 --- a/Documentation/devicetree/bindings/clock/clock-bindings.txt +++ b/Documentation/devicetree/bindings/clock/clock-bindings.txt @@ -44,6 +44,23 @@ For example: clocks by index. The names should reflect the clock output signal names for the device. +clock-indices: If the identifyng number for the clocks in the node + is not linear from zero, then the this mapping allows + the mapping of identifiers into the clock-output-names + array. + +For example, if we have two clocks <&oscillator 1> and <&oscillator 3>: + + oscillator { + compatible = "myclocktype"; + #clock-cells = <1>; + clock-indices = <1>, <3>; + clock-output-names = "clka", "clkb"; + } + + This ensures we do not have any empty nodes in clock-output-names + + ==Clock consumers== Required properties: diff --git a/Documentation/devicetree/bindings/clock/exynos4-clock.txt b/Documentation/devicetree/bindings/clock/exynos4-clock.txt index a2ac2d9ac71a..f5a5b19ed3b2 100644 --- a/Documentation/devicetree/bindings/clock/exynos4-clock.txt +++ b/Documentation/devicetree/bindings/clock/exynos4-clock.txt @@ -15,259 +15,12 @@ Required Properties: - #clock-cells: should be 1. -The following is the list of clocks generated by the controller. Each clock is -assigned an identifier and client nodes use this identifier to specify the -clock which they consume. Some of the clocks are available only on a particular -Exynos4 SoC and this is specified where applicable. - - - [Core Clocks] - - Clock ID SoC (if specific) - ----------------------------------------------- - - xxti 1 - xusbxti 2 - fin_pll 3 - fout_apll 4 - fout_mpll 5 - fout_epll 6 - fout_vpll 7 - sclk_apll 8 - sclk_mpll 9 - sclk_epll 10 - sclk_vpll 11 - arm_clk 12 - aclk200 13 - aclk100 14 - aclk160 15 - aclk133 16 - mout_mpll_user_t 17 Exynos4x12 - mout_mpll_user_c 18 Exynos4x12 - mout_core 19 - mout_apll 20 - - - [Clock Gate for Special Clocks] - - Clock ID SoC (if specific) - ----------------------------------------------- - - sclk_fimc0 128 - sclk_fimc1 129 - sclk_fimc2 130 - sclk_fimc3 131 - sclk_cam0 132 - sclk_cam1 133 - sclk_csis0 134 - sclk_csis1 135 - sclk_hdmi 136 - sclk_mixer 137 - sclk_dac 138 - sclk_pixel 139 - sclk_fimd0 140 - sclk_mdnie0 141 Exynos4412 - sclk_mdnie_pwm0 12 142 Exynos4412 - sclk_mipi0 143 - sclk_audio0 144 - sclk_mmc0 145 - sclk_mmc1 146 - sclk_mmc2 147 - sclk_mmc3 148 - sclk_mmc4 149 - sclk_sata 150 Exynos4210 - sclk_uart0 151 - sclk_uart1 152 - sclk_uart2 153 - sclk_uart3 154 - sclk_uart4 155 - sclk_audio1 156 - sclk_audio2 157 - sclk_spdif 158 - sclk_spi0 159 - sclk_spi1 160 - sclk_spi2 161 - sclk_slimbus 162 - sclk_fimd1 163 Exynos4210 - sclk_mipi1 164 Exynos4210 - sclk_pcm1 165 - sclk_pcm2 166 - sclk_i2s1 167 - sclk_i2s2 168 - sclk_mipihsi 169 Exynos4412 - sclk_mfc 170 - sclk_pcm0 171 - sclk_g3d 172 - sclk_pwm_isp 173 Exynos4x12 - sclk_spi0_isp 174 Exynos4x12 - sclk_spi1_isp 175 Exynos4x12 - sclk_uart_isp 176 Exynos4x12 - sclk_fimg2d 177 - - [Peripheral Clock Gates] - - Clock ID SoC (if specific) - ----------------------------------------------- - - fimc0 256 - fimc1 257 - fimc2 258 - fimc3 259 - csis0 260 - csis1 261 - jpeg 262 - smmu_fimc0 263 - smmu_fimc1 264 - smmu_fimc2 265 - smmu_fimc3 266 - smmu_jpeg 267 - vp 268 - mixer 269 - tvenc 270 Exynos4210 - hdmi 271 - smmu_tv 272 - mfc 273 - smmu_mfcl 274 - smmu_mfcr 275 - g3d 276 - g2d 277 - rotator 278 Exynos4210 - mdma 279 Exynos4210 - smmu_g2d 280 Exynos4210 - smmu_rotator 281 Exynos4210 - smmu_mdma 282 Exynos4210 - fimd0 283 - mie0 284 - mdnie0 285 Exynos4412 - dsim0 286 - smmu_fimd0 287 - fimd1 288 Exynos4210 - mie1 289 Exynos4210 - dsim1 290 Exynos4210 - smmu_fimd1 291 Exynos4210 - pdma0 292 - pdma1 293 - pcie_phy 294 - sata_phy 295 Exynos4210 - tsi 296 - sdmmc0 297 - sdmmc1 298 - sdmmc2 299 - sdmmc3 300 - sdmmc4 301 - sata 302 Exynos4210 - sromc 303 - usb_host 304 - usb_device 305 - pcie 306 - onenand 307 - nfcon 308 - smmu_pcie 309 - gps 310 - smmu_gps 311 - uart0 312 - uart1 313 - uart2 314 - uart3 315 - uart4 316 - i2c0 317 - i2c1 318 - i2c2 319 - i2c3 320 - i2c4 321 - i2c5 322 - i2c6 323 - i2c7 324 - i2c_hdmi 325 - tsadc 326 - spi0 327 - spi1 328 - spi2 329 - i2s1 330 - i2s2 331 - pcm0 332 - i2s0 333 - pcm1 334 - pcm2 335 - pwm 336 - slimbus 337 - spdif 338 - ac97 339 - modemif 340 - chipid 341 - sysreg 342 - hdmi_cec 343 - mct 344 - wdt 345 - rtc 346 - keyif 347 - audss 348 - mipi_hsi 349 Exynos4210 - mdma2 350 Exynos4210 - pixelasyncm0 351 - pixelasyncm1 352 - fimc_lite0 353 Exynos4x12 - fimc_lite1 354 Exynos4x12 - ppmuispx 355 Exynos4x12 - ppmuispmx 356 Exynos4x12 - fimc_isp 357 Exynos4x12 - fimc_drc 358 Exynos4x12 - fimc_fd 359 Exynos4x12 - mcuisp 360 Exynos4x12 - gicisp 361 Exynos4x12 - smmu_isp 362 Exynos4x12 - smmu_drc 363 Exynos4x12 - smmu_fd 364 Exynos4x12 - smmu_lite0 365 Exynos4x12 - smmu_lite1 366 Exynos4x12 - mcuctl_isp 367 Exynos4x12 - mpwm_isp 368 Exynos4x12 - i2c0_isp 369 Exynos4x12 - i2c1_isp 370 Exynos4x12 - mtcadc_isp 371 Exynos4x12 - pwm_isp 372 Exynos4x12 - wdt_isp 373 Exynos4x12 - uart_isp 374 Exynos4x12 - asyncaxim 375 Exynos4x12 - smmu_ispcx 376 Exynos4x12 - spi0_isp 377 Exynos4x12 - spi1_isp 378 Exynos4x12 - pwm_isp_sclk 379 Exynos4x12 - spi0_isp_sclk 380 Exynos4x12 - spi1_isp_sclk 381 Exynos4x12 - uart_isp_sclk 382 Exynos4x12 - tmu_apbif 383 - - [Mux Clocks] - - Clock ID SoC (if specific) - ----------------------------------------------- - - mout_fimc0 384 - mout_fimc1 385 - mout_fimc2 386 - mout_fimc3 387 - mout_cam0 388 - mout_cam1 389 - mout_csis0 390 - mout_csis1 391 - mout_g3d0 392 - mout_g3d1 393 - mout_g3d 394 - aclk400_mcuisp 395 Exynos4x12 - - [Div Clocks] - - Clock ID SoC (if specific) - ----------------------------------------------- - - div_isp0 450 Exynos4x12 - div_isp1 451 Exynos4x12 - div_mcuisp0 452 Exynos4x12 - div_mcuisp1 453 Exynos4x12 - div_aclk200 454 Exynos4x12 - div_aclk400_mcuisp 455 Exynos4x12 +Each clock is assigned an identifier and client nodes can use this identifier +to specify the clock which they consume. +All available clocks are defined as preprocessor macros in +dt-bindings/clock/exynos4.h header and can be used in device +tree sources. Example 1: An example of a clock controller node is listed below. @@ -285,6 +38,6 @@ Example 2: UART controller node that consumes the clock generated by the clock compatible = "samsung,exynos4210-uart"; reg = <0x13820000 0x100>; interrupts = <0 54 0>; - clocks = <&clock 314>, <&clock 153>; + clocks = <&clock CLK_UART2>, <&clock CLK_SCLK_UART2>; clock-names = "uart", "clk_uart_baud0"; }; diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt index 72ce617dea82..536eacd1063f 100644 --- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt +++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt @@ -13,163 +13,12 @@ Required Properties: - #clock-cells: should be 1. -The following is the list of clocks generated by the controller. Each clock is -assigned an identifier and client nodes use this identifier to specify the -clock which they consume. - - - [Core Clocks] - - Clock ID - ---------------------------- - - fin_pll 1 - - [Clock Gate for Special Clocks] - - Clock ID - ---------------------------- - - sclk_cam_bayer 128 - sclk_cam0 129 - sclk_cam1 130 - sclk_gscl_wa 131 - sclk_gscl_wb 132 - sclk_fimd1 133 - sclk_mipi1 134 - sclk_dp 135 - sclk_hdmi 136 - sclk_pixel 137 - sclk_audio0 138 - sclk_mmc0 139 - sclk_mmc1 140 - sclk_mmc2 141 - sclk_mmc3 142 - sclk_sata 143 - sclk_usb3 144 - sclk_jpeg 145 - sclk_uart0 146 - sclk_uart1 147 - sclk_uart2 148 - sclk_uart3 149 - sclk_pwm 150 - sclk_audio1 151 - sclk_audio2 152 - sclk_spdif 153 - sclk_spi0 154 - sclk_spi1 155 - sclk_spi2 156 - div_i2s1 157 - div_i2s2 158 - sclk_hdmiphy 159 - div_pcm0 160 - - - [Peripheral Clock Gates] - - Clock ID - ---------------------------- - - gscl0 256 - gscl1 257 - gscl2 258 - gscl3 259 - gscl_wa 260 - gscl_wb 261 - smmu_gscl0 262 - smmu_gscl1 263 - smmu_gscl2 264 - smmu_gscl3 265 - mfc 266 - smmu_mfcl 267 - smmu_mfcr 268 - rotator 269 - jpeg 270 - mdma1 271 - smmu_rotator 272 - smmu_jpeg 273 - smmu_mdma1 274 - pdma0 275 - pdma1 276 - sata 277 - usbotg 278 - mipi_hsi 279 - sdmmc0 280 - sdmmc1 281 - sdmmc2 282 - sdmmc3 283 - sromc 284 - usb2 285 - usb3 286 - sata_phyctrl 287 - sata_phyi2c 288 - uart0 289 - uart1 290 - uart2 291 - uart3 292 - uart4 293 - i2c0 294 - i2c1 295 - i2c2 296 - i2c3 297 - i2c4 298 - i2c5 299 - i2c6 300 - i2c7 301 - i2c_hdmi 302 - adc 303 - spi0 304 - spi1 305 - spi2 306 - i2s1 307 - i2s2 308 - pcm1 309 - pcm2 310 - pwm 311 - spdif 312 - ac97 313 - hsi2c0 314 - hsi2c1 315 - hs12c2 316 - hs12c3 317 - chipid 318 - sysreg 319 - pmu 320 - cmu_top 321 - cmu_core 322 - cmu_mem 323 - tzpc0 324 - tzpc1 325 - tzpc2 326 - tzpc3 327 - tzpc4 328 - tzpc5 329 - tzpc6 330 - tzpc7 331 - tzpc8 332 - tzpc9 333 - hdmi_cec 334 - mct 335 - wdt 336 - rtc 337 - tmu 338 - fimd1 339 - mie1 340 - dsim0 341 - dp 342 - mixer 343 - hdmi 344 - g2d 345 - mdma0 346 - smmu_mdma0 347 - - - [Clock Muxes] - - Clock ID - ---------------------------- - mout_hdmi 1024 +Each clock is assigned an identifier and client nodes can use this identifier +to specify the clock which they consume. +All available clocks are defined as preprocessor macros in +dt-bindings/clock/exynos5250.h header and can be used in device +tree sources. Example 1: An example of a clock controller node is listed below. @@ -187,6 +36,6 @@ Example 2: UART controller node that consumes the clock generated by the clock compatible = "samsung,exynos4210-uart"; reg = <0x13820000 0x100>; interrupts = <0 54 0>; - clocks = <&clock 314>, <&clock 153>; + clocks = <&clock CLK_UART2>, <&clock CLK_SCLK_UART2>; clock-names = "uart", "clk_uart_baud0"; }; diff --git a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt index 458f34789e5d..ca88c97a8562 100644 --- a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt +++ b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt @@ -13,184 +13,12 @@ Required Properties: - #clock-cells: should be 1. -The following is the list of clocks generated by the controller. Each clock is -assigned an identifier and client nodes use this identifier to specify the -clock which they consume. +Each clock is assigned an identifier and client nodes can use this identifier +to specify the clock which they consume. - - [Core Clocks] - - Clock ID - ---------------------------- - - fin_pll 1 - - [Clock Gate for Special Clocks] - - Clock ID - ---------------------------- - sclk_uart0 128 - sclk_uart1 129 - sclk_uart2 130 - sclk_uart3 131 - sclk_mmc0 132 - sclk_mmc1 133 - sclk_mmc2 134 - sclk_spi0 135 - sclk_spi1 136 - sclk_spi2 137 - sclk_i2s1 138 - sclk_i2s2 139 - sclk_pcm1 140 - sclk_pcm2 141 - sclk_spdif 142 - sclk_hdmi 143 - sclk_pixel 144 - sclk_dp1 145 - sclk_mipi1 146 - sclk_fimd1 147 - sclk_maudio0 148 - sclk_maupcm0 149 - sclk_usbd300 150 - sclk_usbd301 151 - sclk_usbphy300 152 - sclk_usbphy301 153 - sclk_unipro 154 - sclk_pwm 155 - sclk_gscl_wa 156 - sclk_gscl_wb 157 - sclk_hdmiphy 158 - - [Peripheral Clock Gates] - - Clock ID - ---------------------------- - - aclk66_peric 256 - uart0 257 - uart1 258 - uart2 259 - uart3 260 - i2c0 261 - i2c1 262 - i2c2 263 - i2c3 264 - i2c4 265 - i2c5 266 - i2c6 267 - i2c7 268 - i2c_hdmi 269 - tsadc 270 - spi0 271 - spi1 272 - spi2 273 - keyif 274 - i2s1 275 - i2s2 276 - pcm1 277 - pcm2 278 - pwm 279 - spdif 280 - i2c8 281 - i2c9 282 - i2c10 283 - aclk66_psgen 300 - chipid 301 - sysreg 302 - tzpc0 303 - tzpc1 304 - tzpc2 305 - tzpc3 306 - tzpc4 307 - tzpc5 308 - tzpc6 309 - tzpc7 310 - tzpc8 311 - tzpc9 312 - hdmi_cec 313 - seckey 314 - mct 315 - wdt 316 - rtc 317 - tmu 318 - tmu_gpu 319 - pclk66_gpio 330 - aclk200_fsys2 350 - mmc0 351 - mmc1 352 - mmc2 353 - sromc 354 - ufs 355 - aclk200_fsys 360 - tsi 361 - pdma0 362 - pdma1 363 - rtic 364 - usbh20 365 - usbd300 366 - usbd301 377 - aclk400_mscl 380 - mscl0 381 - mscl1 382 - mscl2 383 - smmu_mscl0 384 - smmu_mscl1 385 - smmu_mscl2 386 - aclk333 400 - mfc 401 - smmu_mfcl 402 - smmu_mfcr 403 - aclk200_disp1 410 - dsim1 411 - dp1 412 - hdmi 413 - aclk300_disp1 420 - fimd1 421 - smmu_fimd1 422 - aclk166 430 - mixer 431 - aclk266 440 - rotator 441 - mdma1 442 - smmu_rotator 443 - smmu_mdma1 444 - aclk300_jpeg 450 - jpeg 451 - jpeg2 452 - smmu_jpeg 453 - aclk300_gscl 460 - smmu_gscl0 461 - smmu_gscl1 462 - gscl_wa 463 - gscl_wb 464 - gscl0 465 - gscl1 466 - clk_3aa 467 - aclk266_g2d 470 - sss 471 - slim_sss 472 - mdma0 473 - aclk333_g2d 480 - g2d 481 - aclk333_432_gscl 490 - smmu_3aa 491 - smmu_fimcl0 492 - smmu_fimcl1 493 - smmu_fimcl3 494 - fimc_lite3 495 - aclk_g3d 500 - g3d 501 - smmu_mixer 502 - - Mux ID - ---------------------------- - - mout_hdmi 640 - - Divider ID - ---------------------------- - - dout_pixel 768 +All available clocks are defined as preprocessor macros in +dt-bindings/clock/exynos5420.h header and can be used in device +tree sources. Example 1: An example of a clock controller node is listed below. @@ -208,6 +36,6 @@ Example 2: UART controller node that consumes the clock generated by the clock compatible = "samsung,exynos4210-uart"; reg = <0x13820000 0x100>; interrupts = <0 54 0>; - clocks = <&clock 259>, <&clock 130>; + clocks = <&clock CLK_UART2>, <&clock CLK_SCLK_UART2>; clock-names = "uart", "clk_uart_baud0"; }; diff --git a/Documentation/devicetree/bindings/clock/exynos5440-clock.txt b/Documentation/devicetree/bindings/clock/exynos5440-clock.txt index 9955dc9c7d96..5f7005f73058 100644 --- a/Documentation/devicetree/bindings/clock/exynos5440-clock.txt +++ b/Documentation/devicetree/bindings/clock/exynos5440-clock.txt @@ -12,45 +12,12 @@ Required Properties: - #clock-cells: should be 1. -The following is the list of clocks generated by the controller. Each clock is -assigned an identifier and client nodes use this identifier to specify the -clock which they consume. - - - [Core Clocks] - - Clock ID - ---------------------------- - - xtal 1 - arm_clk 2 - - [Peripheral Clock Gates] - - Clock ID - ---------------------------- - - spi_baud 16 - pb0_250 17 - pr0_250 18 - pr1_250 19 - b_250 20 - b_125 21 - b_200 22 - sata 23 - usb 24 - gmac0 25 - cs250 26 - pb0_250_o 27 - pr0_250_o 28 - pr1_250_o 29 - b_250_o 30 - b_125_o 31 - b_200_o 32 - sata_o 33 - usb_o 34 - gmac0_o 35 - cs250_o 36 +Each clock is assigned an identifier and client nodes can use this identifier +to specify the clock which they consume. + +All available clocks are defined as preprocessor macros in +dt-bindings/clock/exynos5440.h header and can be used in device +tree sources. Example: An example of a clock controller node is listed below. diff --git a/Documentation/devicetree/bindings/clock/hi3620-clock.txt b/Documentation/devicetree/bindings/clock/hi3620-clock.txt index 4b71ab41be53..dad6269f52c5 100644 --- a/Documentation/devicetree/bindings/clock/hi3620-clock.txt +++ b/Documentation/devicetree/bindings/clock/hi3620-clock.txt @@ -7,6 +7,7 @@ Required Properties: - compatible: should be one of the following. - "hisilicon,hi3620-clock" - controller compatible with Hi3620 SoC. + - "hisilicon,hi3620-mmc-clock" - controller specific for Hi3620 mmc. - reg: physical base address of the controller and length of memory mapped region. diff --git a/Documentation/devicetree/bindings/clock/imx25-clock.txt b/Documentation/devicetree/bindings/clock/imx25-clock.txt index db4f2f05c4d0..ceaf31346d5c 100644 --- a/Documentation/devicetree/bindings/clock/imx25-clock.txt +++ b/Documentation/devicetree/bindings/clock/imx25-clock.txt @@ -139,6 +139,9 @@ clocks and IDs. uart5_ipg 124 reserved 125 wdt_ipg 126 + cko_div 127 + cko_sel 128 + clo 129 Examples: diff --git a/Documentation/devicetree/bindings/clock/moxa,moxart-clock.txt b/Documentation/devicetree/bindings/clock/moxa,moxart-clock.txt new file mode 100644 index 000000000000..fedea84314a1 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/moxa,moxart-clock.txt @@ -0,0 +1,48 @@ +Device Tree Clock bindings for arch-moxart + +This binding uses the common clock binding[1]. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt + +MOXA ART SoCs allow to determine PLL output and APB frequencies +by reading registers holding multiplier and divisor information. + + +PLL: + +Required properties: +- compatible : Must be "moxa,moxart-pll-clock" +- #clock-cells : Should be 0 +- reg : Should contain registers location and length +- clocks : Should contain phandle + clock-specifier for the parent clock + +Optional properties: +- clock-output-names : Should contain clock name + + +APB: + +Required properties: +- compatible : Must be "moxa,moxart-apb-clock" +- #clock-cells : Should be 0 +- reg : Should contain registers location and length +- clocks : Should contain phandle + clock-specifier for the parent clock + +Optional properties: +- clock-output-names : Should contain clock name + + +For example: + + clk_pll: clk_pll@98100000 { + compatible = "moxa,moxart-pll-clock"; + #clock-cells = <0>; + reg = <0x98100000 0x34>; + }; + + clk_apb: clk_apb@98100000 { + compatible = "moxa,moxart-apb-clock"; + #clock-cells = <0>; + reg = <0x98100000 0x34>; + clocks = <&clk_pll>; + }; diff --git a/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt index 1e662948661e..307a503c5db8 100644 --- a/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt +++ b/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt @@ -11,6 +11,18 @@ The following is a list of provided IDs and clock names on Armada 370/XP: 3 = hclk (DRAM control clock) 4 = dramclk (DDR clock) +The following is a list of provided IDs and clock names on Armada 375: + 0 = tclk (Internal Bus clock) + 1 = cpuclk (CPU clock) + 2 = l2clk (L2 Cache clock) + 3 = ddrclk (DDR clock) + +The following is a list of provided IDs and clock names on Armada 380/385: + 0 = tclk (Internal Bus clock) + 1 = cpuclk (CPU clock) + 2 = l2clk (L2 Cache clock) + 3 = ddrclk (DDR clock) + The following is a list of provided IDs and clock names on Kirkwood and Dove: 0 = tclk (Internal Bus clock) 1 = cpuclk (CPU0 clock) @@ -20,6 +32,8 @@ The following is a list of provided IDs and clock names on Kirkwood and Dove: Required properties: - compatible : shall be one of the following: "marvell,armada-370-core-clock" - For Armada 370 SoC core clocks + "marvell,armada-375-core-clock" - For Armada 375 SoC core clocks + "marvell,armada-380-core-clock" - For Armada 380/385 SoC core clocks "marvell,armada-xp-core-clock" - For Armada XP SoC core clocks "marvell,dove-core-clock" - for Dove SoC core clocks "marvell,kirkwood-core-clock" - for Kirkwood SoC (except mv88f6180) diff --git a/Documentation/devicetree/bindings/clock/mvebu-corediv-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-corediv-clock.txt index c62391fc0e39..520562a7dc2a 100644 --- a/Documentation/devicetree/bindings/clock/mvebu-corediv-clock.txt +++ b/Documentation/devicetree/bindings/clock/mvebu-corediv-clock.txt @@ -4,7 +4,10 @@ The following is a list of provided IDs and clock names on Armada 370/XP: 0 = nand (NAND clock) Required properties: -- compatible : must be "marvell,armada-370-corediv-clock" +- compatible : must be "marvell,armada-370-corediv-clock", + "marvell,armada-375-corediv-clock", + "marvell,armada-380-corediv-clock", + - reg : must be the register address of Core Divider control register - #clock-cells : from common clock binding; shall be set to 1 - clocks : must be set to the parent's phandle diff --git a/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt index fc2910fa7e45..76477be742b2 100644 --- a/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt +++ b/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt @@ -1,9 +1,10 @@ * Gated Clock bindings for Marvell EBU SoCs -Marvell Armada 370/XP, Dove and Kirkwood allow some peripheral clocks to be -gated to save some power. The clock consumer should specify the desired clock -by having the clock ID in its "clocks" phandle cell. The clock ID is directly -mapped to the corresponding clock gating control bit in HW to ease manual clock +Marvell Armada 370/375/380/385/XP, Dove and Kirkwood allow some +peripheral clocks to be gated to save some power. The clock consumer +should specify the desired clock by having the clock ID in its +"clocks" phandle cell. The clock ID is directly mapped to the +corresponding clock gating control bit in HW to ease manual clock lookup in datasheet. The following is a list of provided IDs for Armada 370: @@ -22,6 +23,60 @@ ID Clock Peripheral 28 ddr DDR Cntrl 30 sata1 SATA Host 0 +The following is a list of provided IDs for Armada 375: +ID Clock Peripheral +----------------------------------- +2 mu Management Unit +3 pp Packet Processor +4 ptp PTP +5 pex0 PCIe 0 Clock out +6 pex1 PCIe 1 Clock out +8 audio Audio Cntrl +11 nd_clk Nand Flash Cntrl +14 sata0_link SATA 0 Link +15 sata0_core SATA 0 Core +16 usb3 USB3 Host +17 sdio SDHCI Host +18 usb USB Host +19 gop Gigabit Ethernet MAC +20 sata1_link SATA 1 Link +21 sata1_core SATA 1 Core +22 xor0 XOR DMA 0 +23 xor1 XOR DMA 0 +24 copro Coprocessor +25 tdm Time Division Mplx +28 crypto0_enc Cryptographic Unit Port 0 Encryption +29 crypto0_core Cryptographic Unit Port 0 Core +30 crypto1_enc Cryptographic Unit Port 1 Encryption +31 crypto1_core Cryptographic Unit Port 1 Core + +The following is a list of provided IDs for Armada 380/385: +ID Clock Peripheral +----------------------------------- +0 audio Audio +2 ge2 Gigabit Ethernet 2 +3 ge1 Gigabit Ethernet 1 +4 ge0 Gigabit Ethernet 0 +5 pex1 PCIe 1 +6 pex2 PCIe 2 +7 pex3 PCIe 3 +8 pex0 PCIe 0 +9 usb3h0 USB3 Host 0 +10 usb3h1 USB3 Host 1 +11 usb3d USB3 Device +13 bm Buffer Management +14 crypto0z Cryptographic 0 Z +15 sata0 SATA 0 +16 crypto1z Cryptographic 1 Z +17 sdio SDIO +18 usb2 USB 2 +21 crypto1 Cryptographic 1 +22 xor0 XOR 0 +23 crypto0 Cryptographic 0 +25 tdm Time Division Multiplexing +28 xor1 XOR 1 +30 sata1 SATA 1 + The following is a list of provided IDs for Armada XP: ID Clock Peripheral ----------------------------------- @@ -95,6 +150,8 @@ ID Clock Peripheral Required properties: - compatible : shall be one of the following: "marvell,armada-370-gating-clock" - for Armada 370 SoC clock gating + "marvell,armada-375-gating-clock" - for Armada 375 SoC clock gating + "marvell,armada-380-gating-clock" - for Armada 380/385 SoC clock gating "marvell,armada-xp-gating-clock" - for Armada XP SoC clock gating "marvell,dove-gating-clock" - for Dove SoC clock gating "marvell,kirkwood-gating-clock" - for Kirkwood SoC clock gating diff --git a/Documentation/devicetree/bindings/clock/renesas,rz-cpg-clocks.txt b/Documentation/devicetree/bindings/clock/renesas,rz-cpg-clocks.txt new file mode 100644 index 000000000000..98a257492522 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/renesas,rz-cpg-clocks.txt @@ -0,0 +1,29 @@ +* Renesas RZ Clock Pulse Generator (CPG) + +The CPG generates core clocks for the RZ SoCs. It includes the PLL, variable +CPU and GPU clocks, and several fixed ratio dividers. + +Required Properties: + + - compatible: Must be one of + - "renesas,r7s72100-cpg-clocks" for the r7s72100 CPG + - "renesas,rz-cpg-clocks" for the generic RZ CPG + - reg: Base address and length of the memory resource used by the CPG + - clocks: References to possible parent clocks. Order must match clock modes + in the datasheet. For the r7s72100, this is extal, usb_x1. + - #clock-cells: Must be 1 + - clock-output-names: The names of the clocks. Supported clocks are "pll", + "i", and "g" + + +Example +------- + + cpg_clocks: cpg_clocks@fcfe0000 { + #clock-cells = <1>; + compatible = "renesas,r7s72100-cpg-clocks", + "renesas,rz-cpg-clocks"; + reg = <0xfcfe0000 0x18>; + clocks = <&extal_clk>, <&usb_x1_clk>; + clock-output-names = "pll", "i", "g"; + }; diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen-divmux.txt b/Documentation/devicetree/bindings/clock/st/st,clkgen-divmux.txt new file mode 100644 index 000000000000..ae56315fcec5 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-divmux.txt @@ -0,0 +1,49 @@ +Binding for a ST divider and multiplexer clock driver. + +This binding uses the common clock binding[1]. +Base address is located to the parent node. See clock binding[2] + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt +[2] Documentation/devicetree/bindings/clock/st/st,clkgen.txt + +Required properties: + +- compatible : shall be: + "st,clkgena-divmux-c65-hs", "st,clkgena-divmux" + "st,clkgena-divmux-c65-ls", "st,clkgena-divmux" + "st,clkgena-divmux-c32-odf0", "st,clkgena-divmux" + "st,clkgena-divmux-c32-odf1", "st,clkgena-divmux" + "st,clkgena-divmux-c32-odf2", "st,clkgena-divmux" + "st,clkgena-divmux-c32-odf3", "st,clkgena-divmux" + +- #clock-cells : From common clock binding; shall be set to 1. + +- clocks : From common clock binding + +- clock-output-names : From common clock binding. + +Example: + + clockgenA@fd345000 { + reg = <0xfd345000 0xb50>; + + CLK_M_A1_DIV1: CLK_M_A1_DIV1 { + #clock-cells = <1>; + compatible = "st,clkgena-divmux-c32-odf1", + "st,clkgena-divmux"; + + clocks = <&CLK_M_A1_OSC_PREDIV>, + <&CLK_M_A1_PLL0 1>, /* PLL0 PHI1 */ + <&CLK_M_A1_PLL1 1>; /* PLL1 PHI1 */ + + clock-output-names = "CLK_M_RX_ICN_TS", + "CLK_M_RX_ICN_VDP_0", + "", /* Unused */ + "CLK_M_PRV_T1_BUS", + "CLK_M_ICN_REG_12", + "CLK_M_ICN_REG_10", + "", /* Unused */ + "CLK_M_ICN_ST231"; + }; + }; + diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt b/Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt new file mode 100644 index 000000000000..943e0808e212 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt @@ -0,0 +1,36 @@ +Binding for a ST multiplexed clock driver. + +This binding supports only simple indexed multiplexers, it does not +support table based parent index to hardware value translations. + +This binding uses the common clock binding[1]. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt + +Required properties: + +- compatible : shall be: + "st,stih416-clkgenc-vcc-hd", "st,clkgen-mux" + "st,stih416-clkgenf-vcc-fvdp", "st,clkgen-mux" + "st,stih416-clkgenf-vcc-hva", "st,clkgen-mux" + "st,stih416-clkgenf-vcc-hd", "st,clkgen-mux" + "st,stih416-clkgenf-vcc-sd", "st,clkgen-mux" + "st,stih415-clkgen-a9-mux", "st,clkgen-mux" + "st,stih416-clkgen-a9-mux", "st,clkgen-mux" + + +- #clock-cells : from common clock binding; shall be set to 0. + +- reg : A Base address and length of the register set. + +- clocks : from common clock binding + +Example: + + CLK_M_HVA: CLK_M_HVA { + #clock-cells = <0>; + compatible = "st,stih416-clkgenf-vcc-hva", "st,clkgen-mux"; + reg = <0xfd690868 4>; + + clocks = <&CLOCKGEN_F 1>, <&CLK_M_A1_DIV0 3>; + }; diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt b/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt new file mode 100644 index 000000000000..81eb3855ab92 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt @@ -0,0 +1,48 @@ +Binding for a ST pll clock driver. + +This binding uses the common clock binding[1]. +Base address is located to the parent node. See clock binding[2] + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt +[2] Documentation/devicetree/bindings/clock/st/st,clkgen.txt + +Required properties: + +- compatible : shall be: + "st,clkgena-prediv-c65", "st,clkgena-prediv" + "st,clkgena-prediv-c32", "st,clkgena-prediv" + + "st,clkgena-plls-c65" + "st,plls-c32-a1x-0", "st,clkgen-plls-c32" + "st,plls-c32-a1x-1", "st,clkgen-plls-c32" + "st,stih415-plls-c32-a9", "st,clkgen-plls-c32" + "st,stih415-plls-c32-ddr", "st,clkgen-plls-c32" + "st,stih416-plls-c32-a9", "st,clkgen-plls-c32" + "st,stih416-plls-c32-ddr", "st,clkgen-plls-c32" + + "st,stih415-gpu-pll-c32", "st,clkgengpu-pll-c32" + "st,stih416-gpu-pll-c32", "st,clkgengpu-pll-c32" + + +- #clock-cells : From common clock binding; shall be set to 1. + +- clocks : From common clock binding + +- clock-output-names : From common clock binding. + +Example: + + clockgenA@fee62000 { + reg = <0xfee62000 0xb48>; + + CLK_S_A0_PLL: CLK_S_A0_PLL { + #clock-cells = <1>; + compatible = "st,clkgena-plls-c65"; + + clocks = <&CLK_SYSIN>; + + clock-output-names = "CLK_S_A0_PLL0_HS", + "CLK_S_A0_PLL0_LS", + "CLK_S_A0_PLL1"; + }; + }; diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen-prediv.txt b/Documentation/devicetree/bindings/clock/st/st,clkgen-prediv.txt new file mode 100644 index 000000000000..566c9d79ed32 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-prediv.txt @@ -0,0 +1,36 @@ +Binding for a ST pre-divider clock driver. + +This binding uses the common clock binding[1]. +Base address is located to the parent node. See clock binding[2] + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt +[2] Documentation/devicetree/bindings/clock/st/st,clkgen.txt + +Required properties: + +- compatible : shall be: + "st,clkgena-prediv-c65", "st,clkgena-prediv" + "st,clkgena-prediv-c32", "st,clkgena-prediv" + +- #clock-cells : From common clock binding; shall be set to 0. + +- clocks : From common clock binding + +- clock-output-names : From common clock binding. + +Example: + + clockgenA@fd345000 { + reg = <0xfd345000 0xb50>; + + CLK_M_A2_OSC_PREDIV: CLK_M_A2_OSC_PREDIV { + #clock-cells = <0>; + compatible = "st,clkgena-prediv-c32", + "st,clkgena-prediv"; + + clocks = <&CLK_SYSIN>; + + clock-output-names = "CLK_M_A2_OSC_PREDIV"; + }; + }; + diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen-vcc.txt b/Documentation/devicetree/bindings/clock/st/st,clkgen-vcc.txt new file mode 100644 index 000000000000..4e3ff28b04c3 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-vcc.txt @@ -0,0 +1,53 @@ +Binding for a type of STMicroelectronics clock crossbar (VCC). + +The crossbar can take up to 4 input clocks and control up to 16 +output clocks. Not all inputs or outputs have to be in use in a +particular instantiation. Each output can be individually enabled, +select any of the input clocks and apply a divide (by 1,2,4 or 8) to +that selected clock. + +This binding uses the common clock binding[1]. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt + +Required properties: + +- compatible : shall be: + "st,stih416-clkgenc", "st,vcc" + "st,stih416-clkgenf", "st,vcc" + +- #clock-cells : from common clock binding; shall be set to 1. + +- reg : A Base address and length of the register set. + +- clocks : from common clock binding + +- clock-output-names : From common clock binding. The block has 16 + clock outputs but not all of them in a specific instance + have to be used in the SoC. If a clock name is left as + an empty string then no clock will be created for the + output associated with that string index. If fewer than + 16 strings are provided then no clocks will be created + for the remaining outputs. + +Example: + + CLOCKGEN_C_VCC: CLOCKGEN_C_VCC { + #clock-cells = <1>; + compatible = "st,stih416-clkgenc", "st,clkgen-vcc"; + reg = <0xfe8308ac 12>; + + clocks = <&CLK_S_VCC_HD>, <&CLOCKGEN_C 1>, + <&CLK_S_TMDS_FROMPHY>, <&CLOCKGEN_C 2>; + + clock-output-names = + "CLK_S_PIX_HDMI", "CLK_S_PIX_DVO", + "CLK_S_OUT_DVO", "CLK_S_PIX_HD", + "CLK_S_HDDAC", "CLK_S_DENC", + "CLK_S_SDDAC", "CLK_S_PIX_MAIN", + "CLK_S_PIX_AUX", "CLK_S_STFE_FRC_0", + "CLK_S_REF_MCRU", "CLK_S_SLAVE_MCRU", + "CLK_S_TMDS_HDMI", "CLK_S_HDMI_REJECT_PLL", + "CLK_S_THSENS"; + }; + diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen.txt b/Documentation/devicetree/bindings/clock/st/st,clkgen.txt new file mode 100644 index 000000000000..49ec5ae18b5b --- /dev/null +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen.txt @@ -0,0 +1,83 @@ +Binding for a Clockgen hardware block found on +certain STMicroelectronics consumer electronics SoC devices. + +A Clockgen node can contain pll, diviser or multiplexer nodes. + +We will find only the base address of the Clockgen, this base +address is common of all subnode. + + clockgen_node { + reg = <>; + + pll_node { + ... + }; + + prediv_node { + ... + }; + + divmux_node { + ... + }; + + quadfs_node { + ... + }; + ... + }; + +This binding uses the common clock binding[1]. +Each subnode should use the binding discribe in [2]..[4] + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt +[2] Documentation/devicetree/bindings/clock/st,quadfs.txt +[3] Documentation/devicetree/bindings/clock/st,quadfs.txt +[4] Documentation/devicetree/bindings/clock/st,quadfs.txt + +Required properties: +- reg : A Base address and length of the register set. + +Example: + + clockgenA@fee62000 { + + reg = <0xfee62000 0xb48>; + + CLK_S_A0_PLL: CLK_S_A0_PLL { + #clock-cells = <1>; + compatible = "st,clkgena-plls-c65"; + + clocks = <&CLK_SYSIN>; + + clock-output-names = "CLK_S_A0_PLL0_HS", + "CLK_S_A0_PLL0_LS", + "CLK_S_A0_PLL1"; + }; + + CLK_S_A0_OSC_PREDIV: CLK_S_A0_OSC_PREDIV { + #clock-cells = <0>; + compatible = "st,clkgena-prediv-c65", + "st,clkgena-prediv"; + + clocks = <&CLK_SYSIN>; + + clock-output-names = "CLK_S_A0_OSC_PREDIV"; + }; + + CLK_S_A0_HS: CLK_S_A0_HS { + #clock-cells = <1>; + compatible = "st,clkgena-divmux-c65-hs", + "st,clkgena-divmux"; + + clocks = <&CLK_S_A0_OSC_PREDIV>, + <&CLK_S_A0_PLL 0>, /* PLL0 HS */ + <&CLK_S_A0_PLL 2>; /* PLL1 */ + + clock-output-names = "CLK_S_FDMA_0", + "CLK_S_FDMA_1", + ""; /* CLK_S_JIT_SENSE */ + /* Fourth output unused */ + }; + }; + diff --git a/Documentation/devicetree/bindings/clock/st/st,quadfs.txt b/Documentation/devicetree/bindings/clock/st/st,quadfs.txt new file mode 100644 index 000000000000..ec86d62ca283 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/st/st,quadfs.txt @@ -0,0 +1,45 @@ +Binding for a type of quad channel digital frequency synthesizer found on +certain STMicroelectronics consumer electronics SoC devices. + +This version contains a programmable PLL which can generate up to 216, 432 +or 660MHz (from a 30MHz oscillator input) as the input to the digital +synthesizers. + +This binding uses the common clock binding[1]. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt + +Required properties: +- compatible : shall be: + "st,stih416-quadfs216", "st,quadfs" + "st,stih416-quadfs432", "st,quadfs" + "st,stih416-quadfs660-E", "st,quadfs" + "st,stih416-quadfs660-F", "st,quadfs" + +- #clock-cells : from common clock binding; shall be set to 1. + +- reg : A Base address and length of the register set. + +- clocks : from common clock binding + +- clock-output-names : From common clock binding. The block has 4 + clock outputs but not all of them in a specific instance + have to be used in the SoC. If a clock name is left as + an empty string then no clock will be created for the + output associated with that string index. If fewer than + 4 strings are provided then no clocks will be created + for the remaining outputs. + +Example: + + CLOCKGEN_E: CLOCKGEN_E { + #clock-cells = <1>; + compatible = "st,stih416-quadfs660-E", "st,quadfs"; + reg = <0xfd3208bc 0xB0>; + + clocks = <&CLK_SYSIN>; + clock-output-names = "CLK_M_PIX_MDTP_0", + "CLK_M_PIX_MDTP_1", + "CLK_M_PIX_MDTP_2", + "CLK_M_MPELPC"; + }; diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt index c2cb7621ad2d..a5160d8cbb5f 100644 --- a/Documentation/devicetree/bindings/clock/sunxi.txt +++ b/Documentation/devicetree/bindings/clock/sunxi.txt @@ -6,37 +6,41 @@ This binding uses the common clock binding[1]. Required properties: - compatible : shall be one of the following: - "allwinner,sun4i-osc-clk" - for a gatable oscillator - "allwinner,sun4i-pll1-clk" - for the main PLL clock and PLL4 + "allwinner,sun4i-a10-osc-clk" - for a gatable oscillator + "allwinner,sun4i-a10-pll1-clk" - for the main PLL clock and PLL4 "allwinner,sun6i-a31-pll1-clk" - for the main PLL clock on A31 - "allwinner,sun4i-pll5-clk" - for the PLL5 clock - "allwinner,sun4i-pll6-clk" - for the PLL6 clock - "allwinner,sun4i-cpu-clk" - for the CPU multiplexer clock - "allwinner,sun4i-axi-clk" - for the AXI clock - "allwinner,sun4i-axi-gates-clk" - for the AXI gates - "allwinner,sun4i-ahb-clk" - for the AHB clock - "allwinner,sun4i-ahb-gates-clk" - for the AHB gates on A10 + "allwinner,sun4i-a10-pll5-clk" - for the PLL5 clock + "allwinner,sun4i-a10-pll6-clk" - for the PLL6 clock + "allwinner,sun6i-a31-pll6-clk" - for the PLL6 clock on A31 + "allwinner,sun4i-a10-cpu-clk" - for the CPU multiplexer clock + "allwinner,sun4i-a10-axi-clk" - for the AXI clock + "allwinner,sun4i-a10-axi-gates-clk" - for the AXI gates + "allwinner,sun4i-a10-ahb-clk" - for the AHB clock + "allwinner,sun4i-a10-ahb-gates-clk" - for the AHB gates on A10 "allwinner,sun5i-a13-ahb-gates-clk" - for the AHB gates on A13 "allwinner,sun5i-a10s-ahb-gates-clk" - for the AHB gates on A10s "allwinner,sun7i-a20-ahb-gates-clk" - for the AHB gates on A20 "allwinner,sun6i-a31-ahb1-mux-clk" - for the AHB1 multiplexer on A31 "allwinner,sun6i-a31-ahb1-gates-clk" - for the AHB1 gates on A31 - "allwinner,sun4i-apb0-clk" - for the APB0 clock - "allwinner,sun4i-apb0-gates-clk" - for the APB0 gates on A10 + "allwinner,sun4i-a10-apb0-clk" - for the APB0 clock + "allwinner,sun4i-a10-apb0-gates-clk" - for the APB0 gates on A10 "allwinner,sun5i-a13-apb0-gates-clk" - for the APB0 gates on A13 "allwinner,sun5i-a10s-apb0-gates-clk" - for the APB0 gates on A10s "allwinner,sun7i-a20-apb0-gates-clk" - for the APB0 gates on A20 - "allwinner,sun4i-apb1-clk" - for the APB1 clock - "allwinner,sun4i-apb1-mux-clk" - for the APB1 clock muxing - "allwinner,sun4i-apb1-gates-clk" - for the APB1 gates on A10 + "allwinner,sun4i-a10-apb1-clk" - for the APB1 clock + "allwinner,sun4i-a10-apb1-mux-clk" - for the APB1 clock muxing + "allwinner,sun4i-a10-apb1-gates-clk" - for the APB1 gates on A10 "allwinner,sun5i-a13-apb1-gates-clk" - for the APB1 gates on A13 "allwinner,sun5i-a10s-apb1-gates-clk" - for the APB1 gates on A10s "allwinner,sun6i-a31-apb1-gates-clk" - for the APB1 gates on A31 "allwinner,sun7i-a20-apb1-gates-clk" - for the APB1 gates on A20 "allwinner,sun6i-a31-apb2-div-clk" - for the APB2 gates on A31 "allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31 - "allwinner,sun4i-mod0-clk" - for the module 0 family of clocks + "allwinner,sun4i-a10-mod0-clk" - for the module 0 family of clocks "allwinner,sun7i-a20-out-clk" - for the external output clocks + "allwinner,sun7i-a20-gmac-clk" - for the GMAC clock module on A20/A31 + "allwinner,sun4i-a10-usb-clk" - for usb gates + resets on A10 / A20 + "allwinner,sun5i-a13-usb-clk" - for usb gates + resets on A13 Required properties for all clocks: - reg : shall be the control register address for the clock. @@ -44,10 +48,17 @@ Required properties for all clocks: multiplexed clocks, the list order must match the hardware programming order. - #clock-cells : from common clock binding; shall be set to 0 except for - "allwinner,*-gates-clk" where it shall be set to 1 + "allwinner,*-gates-clk", "allwinner,sun4i-pll5-clk" and + "allwinner,sun4i-pll6-clk" where it shall be set to 1 +- clock-output-names : shall be the corresponding names of the outputs. + If the clock module only has one output, the name shall be the + module name. -Additionally, "allwinner,*-gates-clk" clocks require: -- clock-output-names : the corresponding gate names that the clock controls +And "allwinner,*-usb-clk" clocks also require: +- reset-cells : shall be set to 1 + +For "allwinner,sun7i-a20-gmac-clk", the parent clocks shall be fixed rate +dummy clocks at 25 MHz and 125 MHz, respectively. See example. Clock consumers should specify the desired clocks they use with a "clocks" phandle cell. Consumers that are using a gated clock should @@ -56,23 +67,68 @@ offset of the bit controlling this particular gate in the register. For example: -osc24M: osc24M@01c20050 { +osc24M: clk@01c20050 { #clock-cells = <0>; - compatible = "allwinner,sun4i-osc-clk"; + compatible = "allwinner,sun4i-a10-osc-clk"; reg = <0x01c20050 0x4>; clocks = <&osc24M_fixed>; + clock-output-names = "osc24M"; }; -pll1: pll1@01c20000 { +pll1: clk@01c20000 { #clock-cells = <0>; - compatible = "allwinner,sun4i-pll1-clk"; + compatible = "allwinner,sun4i-a10-pll1-clk"; reg = <0x01c20000 0x4>; clocks = <&osc24M>; + clock-output-names = "pll1"; +}; + +pll5: clk@01c20020 { + #clock-cells = <1>; + compatible = "allwinner,sun4i-pll5-clk"; + reg = <0x01c20020 0x4>; + clocks = <&osc24M>; + clock-output-names = "pll5_ddr", "pll5_other"; }; cpu: cpu@01c20054 { #clock-cells = <0>; - compatible = "allwinner,sun4i-cpu-clk"; + compatible = "allwinner,sun4i-a10-cpu-clk"; reg = <0x01c20054 0x4>; clocks = <&osc32k>, <&osc24M>, <&pll1>; + clock-output-names = "cpu"; +}; + +mmc0_clk: clk@01c20088 { + #clock-cells = <0>; + compatible = "allwinner,sun4i-mod0-clk"; + reg = <0x01c20088 0x4>; + clocks = <&osc24M>, <&pll6 1>, <&pll5 1>; + clock-output-names = "mmc0"; +}; + +mii_phy_tx_clk: clk@2 { + #clock-cells = <0>; + compatible = "fixed-clock"; + clock-frequency = <25000000>; + clock-output-names = "mii_phy_tx"; +}; + +gmac_int_tx_clk: clk@3 { + #clock-cells = <0>; + compatible = "fixed-clock"; + clock-frequency = <125000000>; + clock-output-names = "gmac_int_tx"; +}; + +gmac_clk: clk@01c20164 { + #clock-cells = <0>; + compatible = "allwinner,sun7i-a20-gmac-clk"; + reg = <0x01c20164 0x4>; + /* + * The first clock must be fixed at 25MHz; + * the second clock must be fixed at 125MHz + */ + clocks = <&mii_phy_tx_clk>, <&gmac_int_tx_clk>; + clock-output-names = "gmac"; }; diff --git a/Documentation/devicetree/bindings/clock/zynq-7000.txt b/Documentation/devicetree/bindings/clock/zynq-7000.txt index 17b4a94916d6..d93746cf2975 100644 --- a/Documentation/devicetree/bindings/clock/zynq-7000.txt +++ b/Documentation/devicetree/bindings/clock/zynq-7000.txt @@ -14,6 +14,7 @@ for all clock consumers of PS clocks. Required properties: - #clock-cells : Must be 1 - compatible : "xlnx,ps7-clkc" + - reg : SLCR offset and size taken via syscon < 0x100 0x100 > - ps-clk-frequency : Frequency of the oscillator providing ps_clk in HZ (usually 33 MHz oscillators are used for Zynq platforms) - clock-output-names : List of strings used to name the clock outputs. Shall be @@ -87,10 +88,11 @@ Clock outputs: 47: dbg_apb Example: - clkc: clkc { + clkc: clkc@100 { #clock-cells = <1>; compatible = "xlnx,ps7-clkc"; ps-clk-frequency = <33333333>; + reg = <0x100 0x100>; clock-output-names = "armpll", "ddrpll", "iopll", "cpu_6or4x", "cpu_3or2x", "cpu_2x", "cpu_1x", "ddr2x", "ddr3x", "dci", "lqspi", "smc", "pcap", "gem0", "gem1", diff --git a/Documentation/devicetree/bindings/dma/fsl-edma.txt b/Documentation/devicetree/bindings/dma/fsl-edma.txt new file mode 100644 index 000000000000..191d7bd8a6fe --- /dev/null +++ b/Documentation/devicetree/bindings/dma/fsl-edma.txt @@ -0,0 +1,76 @@ +* Freescale enhanced Direct Memory Access(eDMA) Controller + + The eDMA channels have multiplex capability by programmble memory-mapped +registers. channels are split into two groups, called DMAMUX0 and DMAMUX1, +specific DMA request source can only be multiplexed by any channel of certain +group, DMAMUX0 or DMAMUX1, but not both. + +* eDMA Controller +Required properties: +- compatible : + - "fsl,vf610-edma" for eDMA used similar to that on Vybrid vf610 SoC +- reg : Specifies base physical address(s) and size of the eDMA registers. + The 1st region is eDMA control register's address and size. + The 2nd and the 3rd regions are programmable channel multiplexing + control register's address and size. +- interrupts : A list of interrupt-specifiers, one for each entry in + interrupt-names. +- interrupt-names : Should contain: + "edma-tx" - the transmission interrupt + "edma-err" - the error interrupt +- #dma-cells : Must be <2>. + The 1st cell specifies the DMAMUX(0 for DMAMUX0 and 1 for DMAMUX1). + Specific request source can only be multiplexed by specific channels + group called DMAMUX. + The 2nd cell specifies the request source(slot) ID. + See the SoC's reference manual for all the supported request sources. +- dma-channels : Number of channels supported by the controller +- clock-names : A list of channel group clock names. Should contain: + "dmamux0" - clock name of mux0 group + "dmamux1" - clock name of mux1 group +- clocks : A list of phandle and clock-specifier pairs, one for each entry in + clock-names. + +Optional properties: +- big-endian: If present registers and hardware scatter/gather descriptors + of the eDMA are implemented in big endian mode, otherwise in little + mode. + + +Examples: + +edma0: dma-controller@40018000 { + #dma-cells = <2>; + compatible = "fsl,vf610-edma"; + reg = <0x40018000 0x2000>, + <0x40024000 0x1000>, + <0x40025000 0x1000>; + interrupts = <0 8 IRQ_TYPE_LEVEL_HIGH>, + <0 9 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "edma-tx", "edma-err"; + dma-channels = <32>; + clock-names = "dmamux0", "dmamux1"; + clocks = <&clks VF610_CLK_DMAMUX0>, + <&clks VF610_CLK_DMAMUX1>; +}; + + +* DMA clients +DMA client drivers that uses the DMA function must use the format described +in the dma.txt file, using a two-cell specifier for each channel: the 1st +specifies the channel group(DMAMUX) in which this request can be multiplexed, +and the 2nd specifies the request source. + +Examples: + +sai2: sai@40031000 { + compatible = "fsl,vf610-sai"; + reg = <0x40031000 0x1000>; + interrupts = <0 86 IRQ_TYPE_LEVEL_HIGH>; + clock-names = "sai"; + clocks = <&clks VF610_CLK_SAI2>; + dma-names = "tx", "rx"; + dmas = <&edma0 0 21>, + <&edma0 0 20>; + status = "disabled"; +}; diff --git a/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt new file mode 100644 index 000000000000..d75a9d767022 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/qcom_bam_dma.txt @@ -0,0 +1,41 @@ +QCOM BAM DMA controller + +Required properties: +- compatible: must contain "qcom,bam-v1.4.0" for MSM8974 +- reg: Address range for DMA registers +- interrupts: Should contain the one interrupt shared by all channels +- #dma-cells: must be <1>, the cell in the dmas property of the client device + represents the channel number +- clocks: required clock +- clock-names: must contain "bam_clk" entry +- qcom,ee : indicates the active Execution Environment identifier (0-7) used in + the secure world. + +Example: + + uart-bam: dma@f9984000 = { + compatible = "qcom,bam-v1.4.0"; + reg = <0xf9984000 0x15000>; + interrupts = <0 94 0>; + clocks = <&gcc GCC_BAM_DMA_AHB_CLK>; + clock-names = "bam_clk"; + #dma-cells = <1>; + qcom,ee = <0>; + }; + +DMA clients must use the format described in the dma.txt file, using a two cell +specifier for each channel. + +Example: + serial@f991e000 { + compatible = "qcom,msm-uart"; + reg = <0xf991e000 0x1000> + <0xf9944000 0x19000>; + interrupts = <0 108 0>; + clocks = <&gcc GCC_BLSP1_UART2_APPS_CLK>, + <&gcc GCC_BLSP1_AHB_CLK>; + clock-names = "core", "iface"; + + dmas = <&uart-bam 0>, <&uart-bam 1>; + dma-names = "rx", "tx"; + }; diff --git a/Documentation/devicetree/bindings/dma/sirfsoc-dma.txt b/Documentation/devicetree/bindings/dma/sirfsoc-dma.txt new file mode 100644 index 000000000000..ecbc96ad36f8 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/sirfsoc-dma.txt @@ -0,0 +1,43 @@ +* CSR SiRFSoC DMA controller + +See dma.txt first + +Required properties: +- compatible: Should be "sirf,prima2-dmac" or "sirf,marco-dmac" +- reg: Should contain DMA registers location and length. +- interrupts: Should contain one interrupt shared by all channel +- #dma-cells: must be <1>. used to represent the number of integer + cells in the dmas property of client device. +- clocks: clock required + +Example: + +Controller: +dmac0: dma-controller@b00b0000 { + compatible = "sirf,prima2-dmac"; + reg = <0xb00b0000 0x10000>; + interrupts = <12>; + clocks = <&clks 24>; + #dma-cells = <1>; +}; + + +Client: +Fill the specific dma request line in dmas. In the below example, spi0 read +channel request line is 9 of the 2nd dma controller, while write channel uses +4 of the 2nd dma controller; spi1 read channel request line is 12 of the 1st +dma controller, while write channel uses 13 of the 1st dma controller: + +spi0: spi@b00d0000 { + compatible = "sirf,prima2-spi"; + dmas = <&dmac1 9>, + <&dmac1 4>; + dma-names = "rx", "tx"; +}; + +spi1: spi@b0170000 { + compatible = "sirf,prima2-spi"; + dmas = <&dmac0 12>, + <&dmac0 13>; + dma-names = "rx", "tx"; +}; diff --git a/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt new file mode 100644 index 000000000000..52b93b2c6748 --- /dev/null +++ b/Documentation/devicetree/bindings/drm/bridge/ptn3460.txt @@ -0,0 +1,27 @@ +ptn3460 bridge bindings + +Required properties: + - compatible: "nxp,ptn3460" + - reg: i2c address of the bridge + - powerdown-gpio: OF device-tree gpio specification + - reset-gpio: OF device-tree gpio specification + - edid-emulation: The EDID emulation entry to use + +-------+------------+------------------+ + | Value | Resolution | Description | + | 0 | 1024x768 | NXP Generic | + | 1 | 1920x1080 | NXP Generic | + | 2 | 1920x1080 | NXP Generic | + | 3 | 1600x900 | Samsung LTM200KT | + | 4 | 1920x1080 | Samsung LTM230HT | + | 5 | 1366x768 | NXP Generic | + | 6 | 1600x900 | ChiMei M215HGE | + +-------+------------+------------------+ + +Example: + lvds-bridge@20 { + compatible = "nxp,ptn3460"; + reg = <0x20>; + powerdown-gpio = <&gpy2 5 1 0 0>; + reset-gpio = <&gpx1 5 1 0 0>; + edid-emulation = <5>; + }; diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt new file mode 100644 index 000000000000..d7df01c5bb3a --- /dev/null +++ b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt @@ -0,0 +1,27 @@ +Device-Tree bindings for the NXP TDA998x HDMI transmitter + +Required properties; + - compatible: must be "nxp,tda998x" + +Optional properties: + - interrupts: interrupt number and trigger type + default: polling + + - pinctrl-0: pin control group to be used for + screen plug/unplug interrupt. + + - pinctrl-names: must contain a "default" entry. + + - video-ports: 24 bits value which defines how the video controller + output is wired to the TDA998x input - default: <0x230145> + +Example: + + tda998x: hdmi-encoder { + compatible = "nxp,tda998x"; + reg = <0x70>; + interrupt-parent = <&gpio0>; + interrupts = <27 2>; /* falling edge */ + pinctrl-0 = <&pmx_camera>; + pinctrl-names = "default"; + }; diff --git a/Documentation/devicetree/bindings/gpio/cirrus,clps711x-mctrl-gpio.txt b/Documentation/devicetree/bindings/gpio/cirrus,clps711x-mctrl-gpio.txt new file mode 100644 index 000000000000..94ae9f82dcf8 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/cirrus,clps711x-mctrl-gpio.txt @@ -0,0 +1,17 @@ +* ARM Cirrus Logic CLPS711X SYSFLG1 MCTRL GPIOs + +Required properties: +- compatible: Should contain "cirrus,clps711x-mctrl-gpio". +- gpio-controller: Marks the device node as a gpio controller. +- #gpio-cells: Should be two. The first cell is the pin number and + the second cell is used to specify the gpio polarity: + 0 = Active high, + 1 = Active low. + +Example: + sysgpio: sysgpio { + compatible = "cirrus,ep7312-mctrl-gpio", + "cirrus,clps711x-mctrl-gpio"; + gpio-controller; + #gpio-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt index a2e839d6e338..5079ba7d6568 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt @@ -1,13 +1,17 @@ -Davinci GPIO controller bindings +Davinci/Keystone GPIO controller bindings Required Properties: -- compatible: should be "ti,dm6441-gpio" +- compatible: should be "ti,dm6441-gpio", "ti,keystone-gpio" - reg: Physical base address of the controller and the size of memory mapped registers. - gpio-controller : Marks the device node as a gpio controller. +- #gpio-cells : Should be two. + - first cell is the pin number + - second cell is used to specify optional parameters (unused) + - interrupt-parent: phandle of the parent interrupt controller. - interrupts: Array of GPIO interrupt number. Only banked or unbanked IRQs are @@ -27,6 +31,7 @@ Example: gpio: gpio@1e26000 { compatible = "ti,dm6441-gpio"; gpio-controller; + #gpio-cells = <2>; reg = <0x226000 0x1000>; interrupt-parent = <&intc>; interrupts = <42 IRQ_TYPE_EDGE_BOTH 43 IRQ_TYPE_EDGE_BOTH @@ -39,3 +44,19 @@ gpio: gpio@1e26000 { interrupt-controller; #interrupt-cells = <2>; }; + +leds { + compatible = "gpio-leds"; + + led1 { + label = "davinci:green:usr1"; + gpios = <&gpio 10 GPIO_ACTIVE_HIGH>; + ... + }; + + led2 { + label = "davinci:red:debug1"; + gpios = <&gpio 11 GPIO_ACTIVE_HIGH>; + ... + }; +}; diff --git a/Documentation/devicetree/bindings/gpio/gpio-zevio.txt b/Documentation/devicetree/bindings/gpio/gpio-zevio.txt new file mode 100644 index 000000000000..a37bd9ae2730 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-zevio.txt @@ -0,0 +1,16 @@ +Zevio GPIO controller + +Required properties: +- compatible: Should be "lsi,zevio-gpio" +- reg: Address and length of the register set for the device +- #gpio-cells: Should be two. The first cell is the pin number and the + second cell is used to specify optional parameters (currently unused). +- gpio-controller: Marks the device node as a GPIO controller. + +Example: + gpio: gpio@90000000 { + compatible = "lsi,zevio-gpio"; + reg = <0x90000000 0x1000>; + gpio-controller; + #gpio-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt index 0c85bb6e3a80..3fb8f53071b8 100644 --- a/Documentation/devicetree/bindings/gpio/gpio.txt +++ b/Documentation/devicetree/bindings/gpio/gpio.txt @@ -13,11 +13,11 @@ properties, each containing a 'gpio-list': gpio-specifier : Array of #gpio-cells specifying specific gpio (controller specific) -GPIO properties should be named "[<name>-]gpios". Exact +GPIO properties should be named "[<name>-]gpios". The exact meaning of each gpios property must be documented in the device tree binding for each device. -For example, the following could be used to describe gpios pins to use +For example, the following could be used to describe GPIO pins used as chip select lines; with chip selects 0, 1 and 3 populated, and chip select 2 left empty: @@ -44,35 +44,79 @@ whether pin is open-drain and whether pin is logically inverted. Exact meaning of each specifier cell is controller specific, and must be documented in the device tree binding for the device. -Example of the node using GPIOs: +Example of a node using GPIOs: node { gpios = <&qe_pio_e 18 0>; }; In this example gpio-specifier is "18 0" and encodes GPIO pin number, -and empty GPIO flags as accepted by the "qe_pio_e" gpio-controller. +and GPIO flags as accepted by the "qe_pio_e" gpio-controller. + +1.1) GPIO specifier best practices +---------------------------------- + +A gpio-specifier should contain a flag indicating the GPIO polarity; active- +high or active-low. If it does, the follow best practices should be followed: + +The gpio-specifier's polarity flag should represent the physical level at the +GPIO controller that achieves (or represents, for inputs) a logically asserted +value at the device. The exact definition of logically asserted should be +defined by the binding for the device. If the board inverts the signal between +the GPIO controller and the device, then the gpio-specifier will represent the +opposite physical level than the signal at the device's pin. + +When the device's signal polarity is configurable, the binding for the +device must either: + +a) Define a single static polarity for the signal, with the expectation that +any software using that binding would statically program the device to use +that signal polarity. + +The static choice of polarity may be either: + +a1) (Preferred) Dictated by a binding-specific DT property. + +or: + +a2) Defined statically by the DT binding itself. + +In particular, the polarity cannot be derived from the gpio-specifier, since +that would prevent the DT from separately representing the two orthogonal +concepts of configurable signal polarity in the device, and possible board- +level signal inversion. + +or: + +b) Pick a single option for device signal polarity, and document this choice +in the binding. The gpio-specifier should represent the polarity of the signal +(at the GPIO controller) assuming that the device is configured for this +particular signal polarity choice. If software chooses to program the device +to generate or receive a signal of the opposite polarity, software will be +responsible for correctly interpreting (inverting) the GPIO signal at the GPIO +controller. 2) gpio-controller nodes ------------------------ -Every GPIO controller node must both an empty "gpio-controller" -property, and have #gpio-cells contain the size of the gpio-specifier. +Every GPIO controller node must contain both an empty "gpio-controller" +property, and a #gpio-cells integer property, which indicates the number of +cells in a gpio-specifier. Example of two SOC GPIO banks defined as gpio-controller nodes: qe_pio_a: gpio-controller@1400 { - #gpio-cells = <2>; compatible = "fsl,qe-pario-bank-a", "fsl,qe-pario-bank"; reg = <0x1400 0x18>; gpio-controller; + #gpio-cells = <2>; }; qe_pio_e: gpio-controller@1460 { - #gpio-cells = <2>; compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank"; reg = <0x1460 0x18>; gpio-controller; + #gpio-cells = <2>; }; 2.1) gpio- and pin-controller interaction diff --git a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt new file mode 100644 index 000000000000..dd5d2c0394b1 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt @@ -0,0 +1,60 @@ +* Synopsys DesignWare APB GPIO controller + +Required properties: +- compatible : Should contain "snps,dw-apb-gpio" +- reg : Address and length of the register set for the device. +- #address-cells : should be 1 (for addressing port subnodes). +- #size-cells : should be 0 (port subnodes). + +The GPIO controller has a configurable number of ports, each of which are +represented as child nodes with the following properties: + +Required properties: +- compatible : "snps,dw-apb-gpio-port" +- gpio-controller : Marks the device node as a gpio controller. +- #gpio-cells : Should be two. The first cell is the pin number and + the second cell is used to specify the gpio polarity: + 0 = active high + 1 = active low +- reg : The integer port index of the port, a single cell. + +Optional properties: +- interrupt-controller : The first port may be configured to be an interrupt +controller. +- #interrupt-cells : Specifies the number of cells needed to encode an + interrupt. Shall be set to 2. The first cell defines the interrupt number, + the second encodes the triger flags encoded as described in + Documentation/devicetree/bindings/interrupts.txt +- interrupt-parent : The parent interrupt controller. +- interrupts : The interrupt to the parent controller raised when GPIOs + generate the interrupts. +- snps,nr-gpios : The number of pins in the port, a single cell. + +Example: + +gpio: gpio@20000 { + compatible = "snps,dw-apb-gpio"; + reg = <0x20000 0x1000>; + #address-cells = <1>; + #size-cells = <0>; + + porta: gpio-controller@0 { + compatible = "snps,dw-apb-gpio-port"; + gpio-controller; + #gpio-cells = <2>; + snps,nr-gpios = <8>; + reg = <0>; + interrupt-controller; + #interrupt-cells = <2>; + interrupt-parent = <&vic1>; + interrupts = <0>; + }; + + portb: gpio-controller@1 { + compatible = "snps,dw-apb-gpio-port"; + gpio-controller; + #gpio-cells = <2>; + snps,nr-gpios = <8>; + reg = <1>; + }; +}; diff --git a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt index efaeec8961b6..efa8b8451f93 100644 --- a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt +++ b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt @@ -190,6 +190,48 @@ of the following host1x client modules: - nvidia,edid: supplies a binary EDID blob - nvidia,panel: phandle of a display panel +- sor: serial output resource + + Required properties: + - compatible: "nvidia,tegra124-sor" + - reg: Physical base address and length of the controller's registers. + - interrupts: The interrupt outputs from the controller. + - clocks: Must contain an entry for each entry in clock-names. + See ../clocks/clock-bindings.txt for details. + - clock-names: Must include the following entries: + - sor: clock input for the SOR hardware + - parent: input for the pixel clock + - dp: reference clock for the SOR clock + - safe: safe reference for the SOR clock during power up + - resets: Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. + - reset-names: Must include the following entries: + - sor + + Optional properties: + - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing + - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection + - nvidia,edid: supplies a binary EDID blob + - nvidia,panel: phandle of a display panel + + Optional properties when driving an eDP output: + - nvidia,dpaux: phandle to a DispayPort AUX interface + +- dpaux: DisplayPort AUX interface + - compatible: "nvidia,tegra124-dpaux" + - reg: Physical base address and length of the controller's registers. + - interrupts: The interrupt outputs from the controller. + - clocks: Must contain an entry for each entry in clock-names. + See ../clocks/clock-bindings.txt for details. + - clock-names: Must include the following entries: + - dpaux: clock input for the DPAUX hardware + - parent: reference clock + - resets: Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. + - reset-names: Must include the following entries: + - dpaux + - vdd-supply: phandle of a supply that powers the DisplayPort link + Example: / { diff --git a/Documentation/devicetree/bindings/i2c/i2c-at91.txt b/Documentation/devicetree/bindings/i2c/i2c-at91.txt index 4fade84bea16..388f0a275fba 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-at91.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-at91.txt @@ -12,6 +12,7 @@ Required properties : - clocks: phandles to input clocks. Optional properties: +- clock-frequency: Desired I2C bus frequency in Hz, otherwise defaults to 100000 - Child nodes conforming to i2c bus binding Examples : @@ -23,6 +24,7 @@ i2c0: i2c@fff84000 { #address-cells = <1>; #size-cells = <0>; clocks = <&twi0_clk>; + clock-frequency = <400000>; 24c512@50 { compatible = "24c512"; diff --git a/Documentation/devicetree/bindings/i2c/i2c-cadence.txt b/Documentation/devicetree/bindings/i2c/i2c-cadence.txt new file mode 100644 index 000000000000..7cb0b5608f49 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-cadence.txt @@ -0,0 +1,24 @@ +Binding for the Cadence I2C controller + +Required properties: + - reg: Physical base address and size of the controller's register area. + - compatible: Compatibility string. Must be 'cdns,i2c-r1p10'. + - clocks: Input clock specifier. Refer to common clock bindings. + - interrupts: Interrupt specifier. Refer to interrupt bindings. + - #address-cells: Should be 1. + - #size-cells: Should be 0. + +Optional properties: + - clock-frequency: Desired operating frequency, in Hz, of the bus. + - clock-names: Input clock name, should be 'pclk'. + +Example: + i2c@e0004000 { + compatible = "cdns,i2c-r1p10"; + clocks = <&clkc 38>; + interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>; + reg = <0xe0004000 0x1000>; + clock-frequency = <400000>; + #address-cells = <1>; + #size-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-designware.txt b/Documentation/devicetree/bindings/i2c/i2c-designware.txt index 7fd7fa25e9b0..5199b0c8cf7a 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-designware.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-designware.txt @@ -14,6 +14,12 @@ Optional properties : - i2c-sda-hold-time-ns : should contain the SDA hold time in nanoseconds. This option is only supported in hardware blocks version 1.11a or newer. + - i2c-scl-falling-time : should contain the SCL falling time in nanoseconds. + This value which is by default 300ns is used to compute the tLOW period. + + - i2c-sda-falling-time : should contain the SDA falling time in nanoseconds. + This value which is by default 300ns is used to compute the tHIGH period. + Example : i2c@f0000 { @@ -34,4 +40,6 @@ Example : interrupts = <12 1>; clock-frequency = <400000>; i2c-sda-hold-time-ns = <300>; + i2c-sda-falling-time-ns = <300>; + i2c-scl-falling-time-ns = <300>; }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-efm32.txt b/Documentation/devicetree/bindings/i2c/i2c-efm32.txt new file mode 100644 index 000000000000..fc15ac519437 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-efm32.txt @@ -0,0 +1,34 @@ +* Energymicro efm32 i2c controller + +Required properties : + + - reg : Offset and length of the register set for the device + - compatible : should be "energymicro,efm32-i2c" + - interrupts : the interrupt number + - clocks : reference to the module clock + +Recommended properties : + + - clock-frequency : maximal I2C bus clock frequency in Hz. + - efm32,location : Decides the location of the USART I/O pins. + Allowed range : [0 .. 6] + +Example: + i2c0: i2c@4000a000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "energymicro,efm32-i2c"; + reg = <0x4000a000 0x400>; + interrupts = <9>; + clocks = <&cmu clk_HFPERCLKI2C0>; + clock-frequency = <100000>; + status = "ok"; + efm32,location = <3>; + + eeprom@50 { + compatible = "microchip,24c02"; + reg = <0x50>; + pagesize = <16>; + }; + }; + diff --git a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt index 582b4652a82a..befd4fb4764f 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt @@ -4,12 +4,16 @@ Required properties : - reg : Offset and length of the register set for the device - - compatible : Should be "marvell,mv64xxx-i2c" or "allwinner,sun4i-i2c" - or "marvell,mv78230-i2c" or "marvell,mv78230-a0-i2c" - Note: Only use "marvell,mv78230-a0-i2c" for a very rare, - initial version of the SoC which had broken offload - support. Linux auto-detects this and sets it - appropriately. + - compatible : Should be either: + - "allwinner,sun4i-i2c" + - "allwinner,sun6i-a31-i2c" + - "marvell,mv64xxx-i2c" + - "marvell,mv78230-i2c" + - "marvell,mv78230-a0-i2c" + * Note: Only use "marvell,mv78230-a0-i2c" for a + very rare, initial version of the SoC which + had broken offload support. Linux + auto-detects this and sets it appropriately. - interrupts : The interrupt number Optional properties : @@ -17,6 +21,10 @@ Optional properties : - clock-frequency : Desired I2C bus clock frequency in Hz. If not set the default frequency is 100kHz + - resets : phandle to the parent reset controller. Mandatory + whenever you're using the "allwinner,sun6i-a31-i2c" + compatible. + Examples: i2c@11000 { diff --git a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt index 897cfcd5ce92..dd8b2dd1edeb 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt @@ -6,6 +6,7 @@ Required properties: "renesas,i2c-r8a7778" "renesas,i2c-r8a7779" "renesas,i2c-r8a7790" + "renesas,i2c-r8a7791" - reg: physical base address of the controller and length of memory mapped region. - interrupts: interrupt specifier. @@ -13,11 +14,16 @@ Required properties: Optional properties: - clock-frequency: desired I2C bus clock frequency in Hz. The absence of this propoerty indicates the default frequency 100 kHz. +- clocks: clock specifier. Examples : -i2c0: i2c@e6500000 { - compatible = "renesas,i2c-rcar-h2"; - reg = <0 0xe6500000 0 0x428>; - interrupts = <0 174 0x4>; +i2c0: i2c@e6508000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "renesas,i2c-r8a7791"; + reg = <0 0xe6508000 0 0x40>; + interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&mstp9_clks R8A7791_CLK_I2C0>; + clock-frequency = <400000>; }; diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt b/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt new file mode 100644 index 000000000000..dc71754a56af --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt @@ -0,0 +1,40 @@ +Qualcomm Universal Peripheral (QUP) I2C controller + +Required properties: + - compatible: Should be: + * "qcom,i2c-qup-v1.1.1" for 8660, 8960 and 8064. + * "qcom,i2c-qup-v2.1.1" for 8974 v1. + * "qcom,i2c-qup-v2.2.1" for 8974 v2 and later. + - reg: Should contain QUP register address and length. + - interrupts: Should contain I2C interrupt. + + - clocks: A list of phandles + clock-specifiers, one for each entry in + clock-names. + - clock-names: Should contain: + * "core" for the core clock + * "iface" for the AHB clock + + - #address-cells: Should be <1> Address cells for i2c device address + - #size-cells: Should be <0> as i2c addresses have no size component + +Optional properties: + - clock-frequency: Should specify the desired i2c bus clock frequency in Hz, + defaults to 100kHz if omitted. + +Child nodes should conform to i2c bus binding. + +Example: + + i2c@f9924000 { + compatible = "qcom,i2c-qup-v2.2.1"; + reg = <0xf9924000 0x1000>; + interrupts = <0 96 0>; + + clocks = <&gcc GCC_BLSP1_QUP2_I2C_APPS_CLK>, <&gcc GCC_BLSP1_AHB_CLK>; + clock-names = "core", "iface"; + + clock-frequency = <355000>; + + #address-cells = <1>; + #size-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt index f47e56bcf78d..71724d026ffa 100644 --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt @@ -59,6 +59,7 @@ plx,pex8648 48-Lane, 12-Port PCI Express Gen 2 (5.0 GT/s) Switch ramtron,24c64 i2c serial eeprom (24cxx) ricoh,rs5c372a I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC samsung,24ad0xd1 S524AD0XF1 (128K/256K-bit Serial EEPROM for Low Power) +sii,s35390a 2-wire CMOS real-time clock st-micro,24c256 i2c serial eeprom (24cxx) stm,m41t00 Serial Access TIMEKEEPER stm,m41t62 Serial real-time clock (RTC) with alarm diff --git a/Documentation/devicetree/bindings/arm/atmel-adc.txt b/Documentation/devicetree/bindings/iio/adc/at91_adc.txt index 9a1175b46f49..0f813dec5e08 100644 --- a/Documentation/devicetree/bindings/arm/atmel-adc.txt +++ b/Documentation/devicetree/bindings/iio/adc/at91_adc.txt @@ -8,32 +8,32 @@ Required properties: - clock-names: tuple listing input clock names. Required elements: "adc_clk", "adc_op_clk". - clocks: phandles to input clocks. - - atmel,adc-channels-used: Bitmask of the channels muxed and enable for this + - atmel,adc-channels-used: Bitmask of the channels muxed and enabled for this device - atmel,adc-startup-time: Startup Time of the ADC in microseconds as defined in the datasheet - atmel,adc-vref: Reference voltage in millivolts for the conversions - - atmel,adc-res: List of resolution in bits supported by the ADC. List size + - atmel,adc-res: List of resolutions in bits supported by the ADC. List size must be two at least. - atmel,adc-res-names: Contains one identifier string for each resolution in atmel,adc-res property. "lowres" and "highres" identifiers are required. Optional properties: - - atmel,adc-use-external: Boolean to enable of external triggers + - atmel,adc-use-external-triggers: Boolean to enable the external triggers - atmel,adc-use-res: String corresponding to an identifier from atmel,adc-res-names property. If not specified, the highest resolution will be used. - atmel,adc-sleep-mode: Boolean to enable sleep mode when no conversion - atmel,adc-sample-hold-time: Sample and Hold Time in microseconds - - atmel,adc-ts-wires: Number of touch screen wires. Should be 4 or 5. If this - value is set, then adc driver will enable touch screen + - atmel,adc-ts-wires: Number of touchscreen wires. Should be 4 or 5. If this + value is set, then the adc driver will enable touchscreen support. - NOTE: when adc touch screen enabled, the adc hardware trigger will be - disabled. Since touch screen will occupied the trigger register. + NOTE: when adc touchscreen is enabled, the adc hardware trigger will be + disabled. Since touchscreen will occupy the trigger register. - atmel,adc-ts-pressure-threshold: a pressure threshold for touchscreen. It - make touch detect more precision. - + makes touch detection more precise. + Optional trigger Nodes: - Required properties: * trigger-name: Name of the trigger exposed to the user @@ -44,42 +44,43 @@ Optional trigger Nodes: Examples: adc0: adc@fffb0000 { + #address-cells = <1>; + #size-cells = <0>; compatible = "atmel,at91sam9260-adc"; reg = <0xfffb0000 0x100>; - interrupts = <20 4>; + interrupts = <20 IRQ_TYPE_LEVEL_HIGH 0>; clocks = <&adc_clk>, <&adc_op_clk>; clock-names = "adc_clk", "adc_op_clk"; - atmel,adc-channel-base = <0x30>; atmel,adc-channels-used = <0xff>; - atmel,adc-drdy-mask = <0x10000>; - atmel,adc-num-channels = <8>; atmel,adc-startup-time = <40>; - atmel,adc-status-register = <0x1c>; - atmel,adc-trigger-register = <0x08>; - atmel,adc-use-external; + atmel,adc-use-external-triggers; atmel,adc-vref = <3300>; atmel,adc-res = <8 10>; atmel,adc-res-names = "lowres", "highres"; atmel,adc-use-res = "lowres"; trigger@0 { + reg = <0>; trigger-name = "external-rising"; trigger-value = <0x1>; trigger-external; }; trigger@1 { + reg = <1>; trigger-name = "external-falling"; trigger-value = <0x2>; trigger-external; }; trigger@2 { + reg = <2>; trigger-name = "external-any"; trigger-value = <0x3>; trigger-external; }; trigger@3 { + reg = <3>; trigger-name = "continuous"; trigger-value = <0x6>; }; diff --git a/Documentation/devicetree/bindings/iio/adc/twl4030-madc.txt b/Documentation/devicetree/bindings/iio/adc/twl4030-madc.txt new file mode 100644 index 000000000000..6bdd21404b57 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/twl4030-madc.txt @@ -0,0 +1,24 @@ +* TWL4030 Monitoring Analog to Digital Converter (MADC) + +The MADC subsystem in the TWL4030 consists of a 10-bit ADC +combined with a 16-input analog multiplexer. + +Required properties: + - compatible: Should contain "ti,twl4030-madc". + - interrupts: IRQ line for the MADC submodule. + - #io-channel-cells: Should be set to <1>. + +Optional properties: + - ti,system-uses-second-madc-irq: boolean, set if the second madc irq register + should be used, which is intended to be used + by Co-Processors (e.g. a modem). + +Example: + +&twl { + madc { + compatible = "ti,twl4030-madc"; + interrupts = <3>; + #io-channel-cells = <1>; + }; +}; diff --git a/Documentation/devicetree/bindings/input/clps711x-keypad.txt b/Documentation/devicetree/bindings/input/clps711x-keypad.txt new file mode 100644 index 000000000000..e68d2bbc6c07 --- /dev/null +++ b/Documentation/devicetree/bindings/input/clps711x-keypad.txt @@ -0,0 +1,27 @@ +* Cirrus Logic CLPS711X matrix keypad device tree bindings + +Required Properties: +- compatible: Shall contain "cirrus,clps711x-keypad". +- row-gpios: List of GPIOs used as row lines. +- poll-interval: Poll interval time in milliseconds. +- linux,keymap: The definition can be found at + bindings/input/matrix-keymap.txt. + +Optional Properties: +- autorepeat: Enable autorepeat feature. + +Example: + keypad { + compatible = "cirrus,ep7312-keypad", "cirrus,clps711x-keypad"; + autorepeat; + poll-interval = <120>; + row-gpios = <&porta 0 0>, + <&porta 1 0>; + + linux,keymap = < + MATRIX_KEY(0, 0, KEY_UP) + MATRIX_KEY(0, 1, KEY_DOWN) + MATRIX_KEY(1, 0, KEY_LEFT) + MATRIX_KEY(1, 1, KEY_RIGHT) + >; + }; diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt b/Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt new file mode 100644 index 000000000000..7d8cb92831d7 --- /dev/null +++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt @@ -0,0 +1,89 @@ +Qualcomm PM8xxx PMIC Keypad + +PROPERTIES + +- compatible: + Usage: required + Value type: <string> + Definition: must be one of: + "qcom,pm8058-keypad" + "qcom,pm8921-keypad" + +- reg: + Usage: required + Value type: <prop-encoded-array> + Definition: address of keypad control register + +- interrupts: + Usage: required + Value type: <prop-encoded-array> + Definition: the first interrupt specifies the key sense interrupt + and the second interrupt specifies the key stuck interrupt. + The format of the specifier is defined by the binding + document describing the node's interrupt parent. + +- linux,keymap: + Usage: required + Value type: <prop-encoded-array> + Definition: the linux keymap. More information can be found in + input/matrix-keymap.txt. + +- linux,keypad-no-autorepeat: + Usage: optional + Value type: <bool> + Definition: don't enable autorepeat feature. + +- linux,keypad-wakeup: + Usage: optional + Value type: <bool> + Definition: use any event on keypad as wakeup event. + +- keypad,num-rows: + Usage: required + Value type: <u32> + Definition: number of rows in the keymap. More information can be found + in input/matrix-keymap.txt. + +- keypad,num-columns: + Usage: required + Value type: <u32> + Definition: number of columns in the keymap. More information can be + found in input/matrix-keymap.txt. + +- debounce: + Usage: optional + Value type: <u32> + Definition: time in microseconds that key must be pressed or release + for key sense interrupt to trigger. + +- scan-delay: + Usage: optional + Value type: <u32> + Definition: time in microseconds to pause between successive scans + of the matrix array. + +- row-hold: + Usage: optional + Value type: <u32> + Definition: time in nanoseconds to pause between scans of each row in + the matrix array. + +EXAMPLE + + keypad@148 { + compatible = "qcom,pm8921-keypad"; + reg = <0x148>; + interrupt-parent = <&pmicintc>; + interrupts = <74 1>, <75 1>; + linux,keymap = < + MATRIX_KEY(0, 0, KEY_VOLUMEUP) + MATRIX_KEY(0, 1, KEY_VOLUMEDOWN) + MATRIX_KEY(0, 2, KEY_CAMERA_FOCUS) + MATRIX_KEY(0, 3, KEY_CAMERA) + >; + keypad,num-rows = <1>; + keypad,num-columns = <5>; + debounce = <15>; + scan-delay = <32>; + row-hold = <91500>; + }; diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-pwrkey.txt b/Documentation/devicetree/bindings/input/qcom,pm8xxx-pwrkey.txt new file mode 100644 index 000000000000..588536cc96ed --- /dev/null +++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-pwrkey.txt @@ -0,0 +1,46 @@ +Qualcomm PM8xxx PMIC Power Key + +PROPERTIES + +- compatible: + Usage: required + Value type: <string> + Definition: must be one of: + "qcom,pm8058-pwrkey" + "qcom,pm8921-pwrkey" + +- reg: + Usage: required + Value type: <prop-encoded-array> + Definition: address of power key control register + +- interrupts: + Usage: required + Value type: <prop-encoded-array> + Definition: the first interrupt specifies the key release interrupt + and the second interrupt specifies the key press interrupt. + The format of the specifier is defined by the binding + document describing the node's interrupt parent. + +- debounce: + Usage: optional + Value type: <u32> + Definition: time in microseconds that key must be pressed or release + for state change interrupt to trigger. + +- pull-up: + Usage: optional + Value type: <empty> + Definition: presence of this property indicates that the KPDPWR_N pin + should be configured for pull up. + +EXAMPLE + + pwrkey@1c { + compatible = "qcom,pm8921-pwrkey"; + reg = <0x1c>; + interrupt-parent = <&pmicintc>; + interrupts = <50 1>, <51 1>; + debounce = <15625>; + pull-up; + }; diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.txt b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.txt new file mode 100644 index 000000000000..4ed467b1e402 --- /dev/null +++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.txt @@ -0,0 +1,22 @@ +Qualcomm PM8xxx PMIC Vibrator + +PROPERTIES + +- compatible: + Usage: required + Value type: <string> + Definition: must be one of: + "qcom,pm8058-vib" + "qcom,pm8921-vib" + +- reg: + Usage: required + Value type: <prop-encoded-array> + Definition: address of vibration control register + +EXAMPLE + + vibrator@4a { + compatible = "qcom,pm8058-vib"; + reg = <0x4a>; + }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt new file mode 100644 index 000000000000..76db96704a60 --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt @@ -0,0 +1,55 @@ +FocalTech EDT-FT5x06 Polytouch driver +===================================== + +There are 3 variants of the chip for various touch panel sizes +FT5206GE1 2.8" .. 3.8" +FT5306DE4 4.3" .. 7" +FT5406EE8 7" .. 8.9" + +The software interface is identical for all those chips, so that +currently there is no need for the driver to distinguish between the +different chips. Nevertheless distinct compatible strings are used so +that a distinction can be added if necessary without changing the DT +bindings. + + +Required properties: + - compatible: "edt,edt-ft5206" + or: "edt,edt-ft5306" + or: "edt,edt-ft5406" + + - reg: I2C slave address of the chip (0x38) + - interrupt-parent: a phandle pointing to the interrupt controller + serving the interrupt for this chip + - interrupts: interrupt specification for the touchdetect + interrupt + +Optional properties: + - reset-gpios: GPIO specification for the RESET input + - wake-gpios: GPIO specification for the WAKE input + + - pinctrl-names: should be "default" + - pinctrl-0: a phandle pointing to the pin settings for the + control gpios + + - threshold: allows setting the "click"-threshold in the range + from 20 to 80. + + - gain: allows setting the sensitivity in the range from 0 to + 31. Note that lower values indicate higher + sensitivity. + + - offset: allows setting the edge compensation in the range from + 0 to 31. + +Example: + polytouch: edt-ft5x06@38 { + compatible = "edt,edt-ft5406", "edt,edt-ft5x06"; + reg = <0x38>; + pinctrl-names = "default"; + pinctrl-0 = <&edt_ft5x06_pins>; + interrupt-parent = <&gpio2>; + interrupts = <5 0>; + reset-gpios = <&gpio2 6 1>; + wake-gpios = <&gpio4 9 0>; + }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt b/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt new file mode 100644 index 000000000000..2faf1f1fa39e --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt @@ -0,0 +1,30 @@ +* Neonode infrared touchscreen controller + +Required properties: +- compatible: must be "neonode,zforce" +- reg: I2C address of the chip +- interrupts: interrupt to which the chip is connected +- gpios: gpios the chip is connected to + first one is the interrupt gpio and second one the reset gpio +- x-size: horizontal resolution of touchscreen +- y-size: vertical resolution of touchscreen + +Example: + + i2c@00000000 { + /* ... */ + + zforce_ts@50 { + compatible = "neonode,zforce"; + reg = <0x50>; + interrupts = <2 0>; + + gpios = <&gpio5 6 0>, /* INT */ + <&gpio5 9 0>; /* RST */ + + x-size = <800>; + y-size = <600>; + }; + + /* ... */ + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/cirrus,clps711x-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/cirrus,clps711x-intc.txt new file mode 100644 index 000000000000..759339c34e4f --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/cirrus,clps711x-intc.txt @@ -0,0 +1,41 @@ +Cirrus Logic CLPS711X Interrupt Controller + +Required properties: + +- compatible: Should be "cirrus,clps711x-intc". +- reg: Specifies base physical address of the registers set. +- interrupt-controller: Identifies the node as an interrupt controller. +- #interrupt-cells: Specifies the number of cells needed to encode an + interrupt source. The value shall be 1. + +The interrupt sources are as follows: +ID Name Description +--------------------------- +1: BLINT Battery low (FIQ) +3: MCINT Media changed (FIQ) +4: CSINT CODEC sound +5: EINT1 External 1 +6: EINT2 External 2 +7: EINT3 External 3 +8: TC1OI TC1 under flow +9: TC2OI TC2 under flow +10: RTCMI RTC compare match +11: TINT 64Hz tick +12: UTXINT1 UART1 transmit FIFO half empty +13: URXINT1 UART1 receive FIFO half full +14: UMSINT UART1 modem status changed +15: SSEOTI SSI1 end of transfer +16: KBDINT Keyboard +17: SS2RX SSI2 receive FIFO half or greater full +18: SS2TX SSI2 transmit FIFO less than half empty +28: UTXINT2 UART2 transmit FIFO half empty +29: URXINT2 UART2 receive FIFO half full +32: DAIINT DAI interface (FIQ) + +Example: + intc: interrupt-controller { + compatible = "cirrus,clps711x-intc"; + reg = <0x80000000 0x4000>; + interrupt-controller; + #interrupt-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt index e34c6cdd8ba8..f284b99402bc 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt @@ -48,6 +48,12 @@ conditions. from the mmu-masters towards memory) node for this SMMU. +- calxeda,smmu-secure-config-access : Enable proper handling of buggy + implementations that always use secure access to + SMMU configuration registers. In this case non-secure + aliases of secure registers have to be used during + SMMU configuration. + Example: smmu { diff --git a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt new file mode 100644 index 000000000000..42531dc387aa --- /dev/null +++ b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt @@ -0,0 +1,26 @@ +OMAP2+ IOMMU + +Required properties: +- compatible : Should be one of, + "ti,omap2-iommu" for OMAP2/OMAP3 IOMMU instances + "ti,omap4-iommu" for OMAP4/OMAP5 IOMMU instances + "ti,dra7-iommu" for DRA7xx IOMMU instances +- ti,hwmods : Name of the hwmod associated with the IOMMU instance +- reg : Address space for the configuration registers +- interrupts : Interrupt specifier for the IOMMU instance + +Optional properties: +- ti,#tlb-entries : Number of entries in the translation look-aside buffer. + Should be either 8 or 32 (default: 32) +- ti,iommu-bus-err-back : Indicates the IOMMU instance supports throwing + back a bus error response on MMU faults. + +Example: + /* OMAP3 ISP MMU */ + mmu_isp: mmu@480bd400 { + compatible = "ti,omap2-iommu"; + reg = <0x480bd400 0x80>; + interrupts = <24>; + ti,hwmods = "mmu_isp"; + ti,#tlb-entries = <8>; + }; diff --git a/Documentation/devicetree/bindings/leds/leds-gpio.txt b/Documentation/devicetree/bindings/leds/leds-gpio.txt index df1b3080f6b8..f77148f372ea 100644 --- a/Documentation/devicetree/bindings/leds/leds-gpio.txt +++ b/Documentation/devicetree/bindings/leds/leds-gpio.txt @@ -21,6 +21,8 @@ LED sub-node properties: on). The "keep" setting will keep the LED at whatever its current state is, without producing a glitch. The default is off if this property is not present. +- retain-state-suspended: (optional) The suspend state can be retained.Such + as charge-led gpio. Examples: @@ -50,3 +52,13 @@ run-control { default-state = "on"; }; }; + +leds { + compatible = "gpio-leds"; + + charger-led { + gpios = <&gpio1 2 0>; + linux,default-trigger = "max8903-charger-charging"; + retain-state-suspended; + }; +}; diff --git a/Documentation/devicetree/bindings/media/img-ir-rev1.txt b/Documentation/devicetree/bindings/media/img-ir-rev1.txt new file mode 100644 index 000000000000..5434ce61b925 --- /dev/null +++ b/Documentation/devicetree/bindings/media/img-ir-rev1.txt @@ -0,0 +1,34 @@ +* ImgTec Infrared (IR) decoder version 1 + +This binding is for Imagination Technologies' Infrared decoder block, +specifically major revision 1. + +Required properties: +- compatible: Should be "img,ir-rev1" +- reg: Physical base address of the controller and length of + memory mapped region. +- interrupts: The interrupt specifier to the cpu. + +Optional properties: +- clocks: List of clock specifiers as described in standard + clock bindings. + Up to 3 clocks may be specified in the following order: + 1st: Core clock (defaults to 32.768KHz if omitted). + 2nd: System side (fast) clock. + 3rd: Power modulation clock. +- clock-names: List of clock names corresponding to the clocks + specified in the clocks property. + Accepted clock names are: + "core": Core clock. + "sys": System clock. + "mod": Power modulation clock. + +Example: + + ir@02006200 { + compatible = "img,ir-rev1"; + reg = <0x02006200 0x100>; + interrupts = <29 4>; + clocks = <&clk_32khz>; + clock-names = "core"; + }; diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt b/Documentation/devicetree/bindings/media/samsung-fimc.txt index 96312f6c4c26..922d6f8e74be 100644 --- a/Documentation/devicetree/bindings/media/samsung-fimc.txt +++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt @@ -15,11 +15,21 @@ Common 'camera' node Required properties: -- compatible : must be "samsung,fimc", "simple-bus" -- clocks : list of clock specifiers, corresponding to entries in - the clock-names property; -- clock-names : must contain "sclk_cam0", "sclk_cam1", "pxl_async0", - "pxl_async1" entries, matching entries in the clocks property. +- compatible: must be "samsung,fimc", "simple-bus" +- clocks: list of clock specifiers, corresponding to entries in + the clock-names property; +- clock-names : must contain "sclk_cam0", "sclk_cam1", "pxl_async0", + "pxl_async1" entries, matching entries in the clocks property. + +- #clock-cells: from the common clock bindings (../clock/clock-bindings.txt), + must be 1. A clock provider is associated with the 'camera' node and it should + be referenced by external sensors that use clocks provided by the SoC on + CAM_*_CLKOUT pins. The clock specifier cell stores an index of a clock. + The indices are 0, 1 for CAM_A_CLKOUT, CAM_B_CLKOUT clocks respectively. + +- clock-output-names: from the common clock bindings, should contain names of + clocks registered by the camera subsystem corresponding to CAM_A_CLKOUT, + CAM_B_CLKOUT output clocks respectively. The pinctrl bindings defined in ../pinctrl/pinctrl-bindings.txt must be used to define a required pinctrl state named "default" and optional pinctrl states: @@ -32,6 +42,7 @@ way around. The 'camera' node must include at least one 'fimc' child node. + 'fimc' device nodes ------------------- @@ -88,8 +99,8 @@ port nodes specifies data input - 0, 1 indicates input A, B respectively. Optional properties -- samsung,camclk-out : specifies clock output for remote sensor, - 0 - CAM_A_CLKOUT, 1 - CAM_B_CLKOUT; +- samsung,camclk-out (deprecated) : specifies clock output for remote sensor, + 0 - CAM_A_CLKOUT, 1 - CAM_B_CLKOUT; Image sensor nodes ------------------ @@ -97,8 +108,6 @@ Image sensor nodes The sensor device nodes should be added to their control bus controller (e.g. I2C0) nodes and linked to a port node in the csis or the parallel-ports node, using the common video interfaces bindings, defined in video-interfaces.txt. -The implementation of this bindings requires clock-frequency property to be -present in the sensor device nodes. Example: @@ -114,7 +123,7 @@ Example: vddio-supply = <...>; clock-frequency = <24000000>; - clocks = <...>; + clocks = <&camera 1>; clock-names = "mclk"; port { @@ -135,7 +144,7 @@ Example: vddio-supply = <...>; clock-frequency = <24000000>; - clocks = <...>; + clocks = <&camera 0>; clock-names = "mclk"; port { @@ -149,12 +158,17 @@ Example: camera { compatible = "samsung,fimc", "simple-bus"; - #address-cells = <1>; - #size-cells = <1>; - status = "okay"; - + clocks = <&clock 132>, <&clock 133>, <&clock 351>, + <&clock 352>; + clock-names = "sclk_cam0", "sclk_cam1", "pxl_async0", + "pxl_async1"; + #clock-cells = <1>; + clock-output-names = "cam_a_clkout", "cam_b_clkout"; pinctrl-names = "default"; pinctrl-0 = <&cam_port_a_clk_active>; + status = "okay"; + #address-cells = <1>; + #size-cells = <1>; /* parallel camera ports */ parallel-ports { diff --git a/Documentation/devicetree/bindings/media/samsung-s5c73m3.txt b/Documentation/devicetree/bindings/media/samsung-s5c73m3.txt new file mode 100644 index 000000000000..2c85c4538a6d --- /dev/null +++ b/Documentation/devicetree/bindings/media/samsung-s5c73m3.txt @@ -0,0 +1,97 @@ +Samsung S5C73M3 8Mp camera ISP +------------------------------ + +The S5C73M3 camera ISP supports MIPI CSI-2 and parallel (ITU-R BT.656) video +data busses. The I2C bus is the main control bus and additionally the SPI bus +is used, mostly for transferring the firmware to and from the device. Two +slave device nodes corresponding to these control bus interfaces are required +and should be placed under respective bus controller nodes. + +I2C slave device node +--------------------- + +Required properties: + +- compatible : "samsung,s5c73m3"; +- reg : I2C slave address of the sensor; +- vdd-int-supply : digital power supply (1.2V); +- vdda-supply : analog power supply (1.2V); +- vdd-reg-supply : regulator input power supply (2.8V); +- vddio-host-supply : host I/O power supply (1.8V to 2.8V); +- vddio-cis-supply : CIS I/O power supply (1.2V to 1.8V); +- vdd-af-supply : lens power supply (2.8V); +- xshutdown-gpios : specifier of GPIO connected to the XSHUTDOWN pin; +- standby-gpios : specifier of GPIO connected to the STANDBY pin; +- clocks : should contain list of phandle and clock specifier pairs + according to common clock bindings for the clocks described + in the clock-names property; +- clock-names : should contain "cis_extclk" entry for the CIS_EXTCLK clock; + +Optional properties: + +- clock-frequency : the frequency at which the "cis_extclk" clock should be + configured to operate, in Hz; if this property is not + specified default 24 MHz value will be used. + +The common video interfaces bindings (see video-interfaces.txt) should be used +to specify link from the S5C73M3 to an external image data receiver. The S5C73M3 +device node should contain one 'port' child node with an 'endpoint' subnode for +this purpose. The data link from a raw image sensor to the S5C73M3 can be +similarly specified, but it is optional since the S5C73M3 ISP and a raw image +sensor are usually inseparable and form a hybrid module. + +Following properties are valid for the endpoint node(s): + +endpoint subnode +---------------- + +- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in + video-interfaces.txt. This sensor doesn't support data lane remapping + and physical lane indexes in subsequent elements of the array should + be only consecutive ascending values. + +SPI device node +--------------- + +Required properties: + +- compatible : "samsung,s5c73m3"; + +For more details see description of the SPI busses bindings +(../spi/spi-bus.txt) and bindings of a specific bus controller. + +Example: + +i2c@138A000000 { + ... + s5c73m3@3c { + compatible = "samsung,s5c73m3"; + reg = <0x3c>; + vdd-int-supply = <&buck9_reg>; + vdda-supply = <&ldo17_reg>; + vdd-reg-supply = <&cam_io_reg>; + vddio-host-supply = <&ldo18_reg>; + vddio-cis-supply = <&ldo9_reg>; + vdd-af-supply = <&cam_af_reg>; + clock-frequency = <24000000>; + clocks = <&clk 0>; + clock-names = "cis_extclk"; + reset-gpios = <&gpf1 3 1>; + standby-gpios = <&gpm0 1 1>; + port { + s5c73m3_ep: endpoint { + remote-endpoint = <&csis0_ep>; + data-lanes = <1 2 3 4>; + }; + }; + }; +}; + +spi@1392000 { + ... + s5c73m3_spi: s5c73m3@0 { + compatible = "samsung,s5c73m3"; + reg = <0>; + ... + }; +}; diff --git a/Documentation/devicetree/bindings/media/samsung-s5k6a3.txt b/Documentation/devicetree/bindings/media/samsung-s5k6a3.txt new file mode 100644 index 000000000000..cce01e82f3e3 --- /dev/null +++ b/Documentation/devicetree/bindings/media/samsung-s5k6a3.txt @@ -0,0 +1,33 @@ +Samsung S5K6A3(YX) raw image sensor +--------------------------------- + +S5K6A3(YX) is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces +and CCI (I2C compatible) control bus. + +Required properties: + +- compatible : "samsung,s5k6a3"; +- reg : I2C slave address of the sensor; +- svdda-supply : core voltage supply; +- svddio-supply : I/O voltage supply; +- afvdd-supply : AF (actuator) voltage supply; +- gpios : specifier of a GPIO connected to the RESET pin; +- clocks : should contain list of phandle and clock specifier pairs + according to common clock bindings for the clocks described + in the clock-names property; +- clock-names : should contain "extclk" entry for the sensor's EXTCLK clock; + +Optional properties: + +- clock-frequency : the frequency at which the "extclk" clock should be + configured to operate, in Hz; if this property is not + specified default 24 MHz value will be used. + +The common video interfaces bindings (see video-interfaces.txt) should be +used to specify link to the image data receiver. The S5K6A3(YX) device +node should contain one 'port' child node with an 'endpoint' subnode. + +Following properties are valid for the endpoint node: + +- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in + video-interfaces.txt. The sensor supports only one data lane. diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt index 0e295c9d8937..36a0c3d8c726 100644 --- a/Documentation/devicetree/bindings/mfd/arizona.txt +++ b/Documentation/devicetree/bindings/mfd/arizona.txt @@ -5,9 +5,10 @@ of analogue I/O. Required properties: - - compatible : one of the following chip-specific strings: - "wlf,wm5102" - "wlf,wm5110" + - compatible : One of the following chip-specific strings: + "wlf,wm5102" + "wlf,wm5110" + "wlf,wm8997" - reg : I2C slave address when connected using I2C, chip select number when using SPI. @@ -25,8 +26,9 @@ Required properties: - #gpio-cells : Must be 2. The first cell is the pin number and the second cell is used to specify optional parameters (currently unused). - - AVDD1-supply, DBVDD1-supply, DBVDD2-supply, DBVDD3-supply, CPVDD-supply, - SPKVDDL-supply, SPKVDDR-supply : power supplies for the device, as covered + - AVDD-supply, DBVDD1-supply, DBVDD2-supply, DBVDD3-supply (wm5102, wm5110), + CPVDD-supply, SPKVDDL-supply (wm5102, wm5110), SPKVDDR-supply (wm5102, + wm5110), SPKVDD-supply (wm8997) : Power supplies for the device, as covered in Documentation/devicetree/bindings/regulator/regulator.txt Optional properties: @@ -46,6 +48,7 @@ codec: wm5102@1a { compatible = "wlf,wm5102"; reg = <0x1a>; interrupts = <347>; + interrupt-controller; #interrupt-cells = <2>; interrupt-parent = <&gic>; @@ -53,10 +56,10 @@ codec: wm5102@1a { #gpio-cells = <2>; wlf,gpio-defaults = < - 0x00000000, /* AIF1TXLRCLK */ - 0xffffffff, - 0xffffffff, - 0xffffffff, - 0xffffffff, + 0x00000000 /* AIF1TXLRCLK */ + 0xffffffff + 0xffffffff + 0xffffffff + 0xffffffff >; }; diff --git a/Documentation/devicetree/bindings/mfd/bcm590xx.txt b/Documentation/devicetree/bindings/mfd/bcm590xx.txt new file mode 100644 index 000000000000..1fe30e2b10da --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/bcm590xx.txt @@ -0,0 +1,37 @@ +------------------------------- +BCM590xx Power Management Units +------------------------------- + +Required properties: +- compatible: "brcm,bcm59056" +- reg: I2C slave address +- interrupts: interrupt for the PMU. Generic interrupt client node bindings + are described in interrupt-controller/interrupts.txt + +------------------ +Voltage Regulators +------------------ + +Optional child nodes: +- regulators: container node for regulators following the generic + regulator binding in regulator/regulator.txt + + The valid regulator node names for BCM59056 are: + rfldo, camldo1, camldo2, simldo1, simldo2, sdldo, sdxldo, + mmcldo1, mmcldo2, audldo, micldo, usbldo, vibldo, + csr, iosr1, iosr2, msr, sdsr1, sdsr2, vsr + +Example: + pmu: bcm59056@8 { + compatible = "brcm,bcm59056"; + reg = <0x08>; + interrupts = <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>; + regulators { + rfldo_reg: rfldo { + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <3300000>; + }; + + ... + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/da9055.txt b/Documentation/devicetree/bindings/mfd/da9055.txt new file mode 100644 index 000000000000..6dab34d34fce --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/da9055.txt @@ -0,0 +1,72 @@ +* Dialog DA9055 Power Management Integrated Circuit (PMIC) + +DA9055 consists of a large and varied group of sub-devices (I2C Only): + +Device Supply Names Description +------ ------------ ----------- +da9055-gpio : : GPIOs +da9055-regulator : : Regulators +da9055-onkey : : On key +da9055-rtc : : RTC +da9055-hwmon : : ADC +da9055-watchdog : : Watchdog + +The CODEC device in DA9055 has a separate, configurable I2C address and so +is instantiated separately from the PMIC. + +For details on accompanying CODEC I2C device, see the following: +Documentation/devicetree/bindings/sound/da9055.txt + +====== + +Required properties: +- compatible : Should be "dlg,da9055-pmic" +- reg: Specifies the I2C slave address (defaults to 0x5a but can be modified) +- interrupt-parent: Specifies the phandle of the interrupt controller to which + the IRQs from da9055 are delivered to. +- interrupts: IRQ line info for da9055 chip. +- interrupt-controller: da9055 has internal IRQs (has own IRQ domain). +- #interrupt-cells: Should be 1, is the local IRQ number for da9055. + +Sub-nodes: +- regulators : Contain the regulator nodes. The DA9055 regulators are + bound using their names as listed below: + + buck1 : regulator BUCK1 + buck2 : regulator BUCK2 + ldo1 : regulator LDO1 + ldo2 : regulator LDO2 + ldo3 : regulator LDO3 + ldo4 : regulator LDO4 + ldo5 : regulator LDO5 + ldo6 : regulator LDO6 + + The bindings details of individual regulator device can be found in: + Documentation/devicetree/bindings/regulator/regulator.txt + + +Example: + + pmic: da9055-pmic@5a { + compatible = "dlg,da9055-pmic"; + reg = <0x5a>; + interrupt-parent = <&intc>; + interrupts = <5 IRQ_TYPE_LEVEL_LOW>; + interrupt-controller; + #interrupt-cells = <1>; + + regulators { + buck1: BUCK1 { + regulator-min-microvolt = <725000>; + regulator-max-microvolt = <2075000>; + }; + buck2: BUCK2 { + regulator-min-microvolt = <925000>; + regulator-max-microvolt = <2500000>; + }; + ldo1: LDO1 { + regulator-min-microvolt = <900000>; + regulator-max-microvolt = <3300000>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/mc13xxx.txt b/Documentation/devicetree/bindings/mfd/mc13xxx.txt index abd9e3cb2db7..1413f39912d3 100644 --- a/Documentation/devicetree/bindings/mfd/mc13xxx.txt +++ b/Documentation/devicetree/bindings/mfd/mc13xxx.txt @@ -10,9 +10,44 @@ Optional properties: - fsl,mc13xxx-uses-touch : Indicate the touchscreen controller is being used Sub-nodes: +- leds : Contain the led nodes and initial register values in property + "led-control". Number of register depends of used IC, for MC13783 is 6, + for MC13892 is 4, for MC34708 is 1. See datasheet for bits definitions of + these registers. + - #address-cells: Must be 1. + - #size-cells: Must be 0. + Each led node should contain "reg", which used as LED ID (described below). + Optional properties "label" and "linux,default-trigger" is described in + Documentation/devicetree/bindings/leds/common.txt. - regulators : Contain the regulator nodes. The regulators are bound using their names as listed below with their registers and bits for enabling. +MC13783 LED IDs: + 0 : Main display + 1 : AUX display + 2 : Keypad + 3 : Red 1 + 4 : Green 1 + 5 : Blue 1 + 6 : Red 2 + 7 : Green 2 + 8 : Blue 2 + 9 : Red 3 + 10 : Green 3 + 11 : Blue 3 + +MC13892 LED IDs: + 0 : Main display + 1 : AUX display + 2 : Keypad + 3 : Red + 4 : Green + 5 : Blue + +MC34708 LED IDs: + 0 : Charger Red + 1 : Charger Green + MC13783 regulators: sw1a : regulator SW1A (register 24, bit 0) sw1b : regulator SW1B (register 25, bit 0) @@ -89,6 +124,18 @@ ecspi@70010000 { /* ECSPI1 */ interrupt-parent = <&gpio0>; interrupts = <8>; + leds { + #address-cells = <1>; + #size-cells = <0>; + led-control = <0x000 0x000 0x0e0 0x000>; + + sysled { + reg = <3>; + label = "system:red:live"; + linux,default-trigger = "heartbeat"; + }; + }; + regulators { sw1_reg: mc13892__sw1 { regulator-min-microvolt = <600000>; diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt index b381fa696bf9..4721b2d521e4 100644 --- a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt +++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt @@ -32,6 +32,29 @@ Optional properties: - single-ulpi-bypass: Must be present if the controller contains a single ULPI bypass control bit. e.g. OMAP3 silicon <= ES2.1 +- clocks: a list of phandles and clock-specifier pairs, one for each entry in + clock-names. + +- clock-names: should include: + For OMAP3 + * "usbhost_120m_fck" - 120MHz Functional clock. + + For OMAP4+ + * "refclk_60m_int" - 60MHz internal reference clock for UTMI clock mux + * "refclk_60m_ext_p1" - 60MHz external ref. clock for Port 1's UTMI clock mux. + * "refclk_60m_ext_p2" - 60MHz external ref. clock for Port 2's UTMI clock mux + * "utmi_p1_gfclk" - Port 1 UTMI clock mux. + * "utmi_p2_gfclk" - Port 2 UTMI clock mux. + * "usb_host_hs_utmi_p1_clk" - Port 1 UTMI clock gate. + * "usb_host_hs_utmi_p2_clk" - Port 2 UTMI clock gate. + * "usb_host_hs_utmi_p3_clk" - Port 3 UTMI clock gate. + * "usb_host_hs_hsic480m_p1_clk" - Port 1 480MHz HSIC clock gate. + * "usb_host_hs_hsic480m_p2_clk" - Port 2 480MHz HSIC clock gate. + * "usb_host_hs_hsic480m_p3_clk" - Port 3 480MHz HSIC clock gate. + * "usb_host_hs_hsic60m_p1_clk" - Port 1 60MHz HSIC clock gate. + * "usb_host_hs_hsic60m_p2_clk" - Port 2 60MHz HSIC clock gate. + * "usb_host_hs_hsic60m_p3_clk" - Port 3 60MHz HSIC clock gate. + Required properties if child node exists: - #address-cells: Must be 1 diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt b/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt index 62fe69724e3b..c58d70437fce 100644 --- a/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt +++ b/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt @@ -7,6 +7,16 @@ Required properties: - interrupts : should contain the TLL module's interrupt - ti,hwmod : must contain "usb_tll_hs" +Optional properties: + +- clocks: a list of phandles and clock-specifier pairs, one for each entry in + clock-names. + +- clock-names: should include: + * "usb_tll_hs_usb_ch0_clk" - USB TLL channel 0 clock + * "usb_tll_hs_usb_ch1_clk" - USB TLL channel 1 clock + * "usb_tll_hs_usb_ch2_clk" - USB TLL channel 2 clock + Example: usbhstll: usbhstll@4a062000 { diff --git a/Documentation/devicetree/bindings/mfd/qcom,pm8xxx.txt b/Documentation/devicetree/bindings/mfd/qcom,pm8xxx.txt new file mode 100644 index 000000000000..03518dc8b6bd --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/qcom,pm8xxx.txt @@ -0,0 +1,96 @@ +Qualcomm PM8xxx PMIC multi-function devices + +The PM8xxx family of Power Management ICs are used to provide regulated +voltages and other various functionality to Qualcomm SoCs. + += PROPERTIES + +- compatible: + Usage: required + Value type: <string> + Definition: must be one of: + "qcom,pm8058" + "qcom,pm8921" + +- #address-cells: + Usage: required + Value type: <u32> + Definition: must be 1 + +- #size-cells: + Usage: required + Value type: <u32> + Definition: must be 0 + +- interrupts: + Usage: required + Value type: <prop-encoded-array> + Definition: specifies the interrupt that indicates a subdevice + has generated an interrupt (summary interrupt). The + format of the specifier is defined by the binding document + describing the node's interrupt parent. + +- #interrupt-cells: + Usage: required + Value type : <u32> + Definition: must be 2. Specifies the number of cells needed to encode + an interrupt source. The 1st cell contains the interrupt + number. The 2nd cell is the trigger type and level flags + encoded as follows: + + 1 = low-to-high edge triggered + 2 = high-to-low edge triggered + 4 = active high level-sensitive + 8 = active low level-sensitive + +- interrupt-controller: + Usage: required + Value type: <empty> + Definition: identifies this node as an interrupt controller + += SUBCOMPONENTS + +The PMIC contains multiple independent functions, each described in a subnode. +The below bindings specify the set of valid subnodes. + +== Real-Time Clock + +- compatible: + Usage: required + Value type: <string> + Definition: must be one of: + "qcom,pm8058-rtc" + "qcom,pm8921-rtc" + +- reg: + Usage: required + Value type: <prop-encoded-array> + Definition: single entry specifying the base address of the RTC registers + +- interrupts: + Usage: required + Value type: <prop-encoded-array> + Definition: single entry specifying the RTC's alarm interrupt + +- allow-set-time: + Usage: optional + Value type: <empty> + Definition: indicates that the setting of RTC time is allowed by + the host CPU + += EXAMPLE + + pmicintc: pmic@0 { + compatible = "qcom,pm8921"; + interrupts = <104 8>; + #interrupt-cells = <2>; + interrupt-controller; + #address-cells = <1>; + #size-cells = <0>; + + rtc@11d { + compatible = "qcom,pm8921-rtc"; + reg = <0x11d>; + interrupts = <0x27 0>; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt b/Documentation/devicetree/bindings/mfd/s2mps11.txt index f69bec294f02..802e839b0829 100644 --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt @@ -16,20 +16,25 @@ Optional properties: - interrupts: Interrupt specifiers for interrupt sources. Optional nodes: -- clocks: s2mps11 provides three(AP/CP/BT) buffered 32.768 KHz outputs, so to - register these as clocks with common clock framework instantiate a sub-node - named "clocks". It uses the common clock binding documented in : +- clocks: s2mps11 and s5m8767 provide three(AP/CP/BT) buffered 32.768 KHz + outputs, so to register these as clocks with common clock framework + instantiate a sub-node named "clocks". It uses the common clock binding + documented in : [Documentation/devicetree/bindings/clock/clock-bindings.txt] + The s2mps14 provides two (AP/BT) buffered 32.768 KHz outputs. - #clock-cells: should be 1. - The following is the list of clocks generated by the controller. Each clock is assigned an identifier and client nodes use this identifier to specify the clock which they consume. - Clock ID - ---------------------- - 32KhzAP 0 - 32KhzCP 1 - 32KhzBT 2 + Clock ID Devices + ---------------------------------------------------------- + 32KhzAP 0 S2MPS11, S2MPS14, S5M8767 + 32KhzCP 1 S2MPS11, S5M8767 + 32KhzBT 2 S2MPS11, S2MPS14, S5M8767 + + - compatible: Should be one of: "samsung,s2mps11-clk", "samsung,s2mps14-clk", + "samsung,s5m8767-clk" - regulators: The regulators of s2mps11 that have to be instantiated should be included in a sub-node named 'regulators'. Regulator nodes included in this @@ -75,7 +80,8 @@ Example: compatible = "samsung,s2mps11-pmic"; reg = <0x66>; - s2m_osc: clocks{ + s2m_osc: clocks { + compatible = "samsung,s2mps11-clk"; #clock-cells = 1; clock-output-names = "xx", "yy", "zz"; }; diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt index 458b57f199af..9dce540771fb 100644 --- a/Documentation/devicetree/bindings/mmc/mmc.txt +++ b/Documentation/devicetree/bindings/mmc/mmc.txt @@ -26,9 +26,18 @@ Optional properties: this system, even if the controller claims it is. - cap-sd-highspeed: SD high-speed timing is supported - cap-mmc-highspeed: MMC high-speed timing is supported +- sd-uhs-sdr12: SD UHS SDR12 speed is supported +- sd-uhs-sdr25: SD UHS SDR25 speed is supported +- sd-uhs-sdr50: SD UHS SDR50 speed is supported +- sd-uhs-sdr104: SD UHS SDR104 speed is supported +- sd-uhs-ddr50: SD UHS DDR50 speed is supported - cap-power-off-card: powering off the card is safe - cap-sdio-irq: enable SDIO IRQ signalling on this interface - full-pwr-cycle: full power cycle of the card is supported +- mmc-highspeed-ddr-1_8v: eMMC high-speed DDR mode(1.8V I/O) is supported +- mmc-highspeed-ddr-1_2v: eMMC high-speed DDR mode(1.2V I/O) is supported +- mmc-hs200-1_8v: eMMC HS200 mode(1.8V I/O) is supported +- mmc-hs200-1_2v: eMMC HS200 mode(1.2V I/O) is supported *NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers line polarity properties, we have to fix the meaning of the "normal" and "inverted" diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt new file mode 100644 index 000000000000..81b33b5b20fc --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt @@ -0,0 +1,55 @@ +* Qualcomm SDHCI controller (sdhci-msm) + +This file documents differences between the core properties in mmc.txt +and the properties used by the sdhci-msm driver. + +Required properties: +- compatible: Should contain "qcom,sdhci-msm-v4". +- reg: Base address and length of the register in the following order: + - Host controller register map (required) + - SD Core register map (required) +- interrupts: Should contain an interrupt-specifiers for the interrupts: + - Host controller interrupt (required) +- pinctrl-names: Should contain only one value - "default". +- pinctrl-0: Should specify pin control groups used for this controller. +- clocks: A list of phandle + clock-specifier pairs for the clocks listed in clock-names. +- clock-names: Should contain the following: + "iface" - Main peripheral bus clock (PCLK/HCLK - AHB Bus clock) (required) + "core" - SDC MMC clock (MCLK) (required) + "bus" - SDCC bus voter clock (optional) + +Example: + + sdhc_1: sdhci@f9824900 { + compatible = "qcom,sdhci-msm-v4"; + reg = <0xf9824900 0x11c>, <0xf9824000 0x800>; + interrupts = <0 123 0>; + bus-width = <8>; + non-removable; + + vmmc = <&pm8941_l20>; + vqmmc = <&pm8941_s3>; + + pinctrl-names = "default"; + pinctrl-0 = <&sdc1_clk &sdc1_cmd &sdc1_data>; + + clocks = <&gcc GCC_SDCC1_APPS_CLK>, <&gcc GCC_SDCC1_AHB_CLK>; + clock-names = "core", "iface"; + }; + + sdhc_2: sdhci@f98a4900 { + compatible = "qcom,sdhci-msm-v4"; + reg = <0xf98a4900 0x11c>, <0xf98a4000 0x800>; + interrupts = <0 125 0>; + bus-width = <4>; + cd-gpios = <&msmgpio 62 0x1>; + + vmmc = <&pm8941_l21>; + vqmmc = <&pm8941_l13>; + + pinctrl-names = "default"; + pinctrl-0 = <&sdc2_clk &sdc2_cmd &sdc2_data>; + + clocks = <&gcc GCC_SDCC2_APPS_CLK>, <&gcc GCC_SDCC2_AHB_CLK>; + clock-names = "core", "iface"; + }; diff --git a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt index dbe98a3c183a..86223c3eda90 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt +++ b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt @@ -4,7 +4,14 @@ This file documents differences between the core properties in mmc.txt and the properties used by the sdhci-pxav2 and sdhci-pxav3 drivers. Required properties: -- compatible: Should be "mrvl,pxav2-mmc" or "mrvl,pxav3-mmc". +- compatible: Should be "mrvl,pxav2-mmc", "mrvl,pxav3-mmc" or + "marvell,armada-380-sdhci". +- reg: + * for "mrvl,pxav2-mmc" and "mrvl,pxav3-mmc", one register area for + the SDHCI registers. + * for "marvell,armada-380-sdhci", two register areas. The first one + for the SDHCI registers themselves, and the second one for the + AXI/Mbus bridge registers of the SDHCI unit. Optional properties: - mrvl,clk-delay-cycles: Specify a number of cycles to delay for tuning. @@ -19,3 +26,11 @@ sdhci@d4280800 { non-removable; mrvl,clk-delay-cycles = <31>; }; + +sdhci@d8000 { + compatible = "marvell,armada-380-sdhci"; + reg = <0xd8000 0x1000>, <0xdc000 0x100>; + interrupts = <0 25 0x4>; + clocks = <&gateclk 17>; + mrvl,clk-delay-cycles = <0x1F>; +}; diff --git a/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt new file mode 100644 index 000000000000..4897bea7e3f8 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt @@ -0,0 +1,23 @@ +* Altera SOCFPGA specific extensions to the Synopsys Designware Mobile + Storage Host Controller + +The Synopsys 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 Synopsys dw mshc controller properties described +by synopsys-dw-mshc.txt and the properties used by the Altera SOCFPGA specific +extensions to the Synopsys Designware Mobile Storage Host Controller. + +Required Properties: + +* compatible: should be + - "altr,socfpga-dw-mshc": for Altera's SOCFPGA platform + +Example: + + mmc: dwmmc0@ff704000 { + compatible = "altr,socfpga-dw-mshc"; + reg = <0xff704000 0x1000>; + interrupts = <0 129 4>; + #address-cells = <1>; + #size-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt index 8c8908ab84ba..ce8056116fb0 100644 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt @@ -10,6 +10,7 @@ Required properties: - compatible: Should be "ti,omap2-hsmmc", for OMAP2 controllers Should be "ti,omap3-hsmmc", for OMAP3 controllers + Should be "ti,omap3-pre-es3-hsmmc" for OMAP3 controllers pre ES3.0 Should be "ti,omap4-hsmmc", for OMAP4 controllers - ti,hwmods: Must be "mmc<n>", n is controller instance starting 1 diff --git a/Documentation/devicetree/bindings/mtd/nand.txt b/Documentation/devicetree/bindings/mtd/nand.txt index 03855c8c492a..b53f92e252d4 100644 --- a/Documentation/devicetree/bindings/mtd/nand.txt +++ b/Documentation/devicetree/bindings/mtd/nand.txt @@ -5,3 +5,17 @@ "soft_bch". - 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 + +- nand-ecc-strength: integer representing the number of bits to correct + per ECC step. + +- nand-ecc-step-size: integer representing the number of data bytes + that are covered by a single ECC step. + +The ECC strength and ECC step size properties define the correction capability +of a controller. Together, they say a controller can correct "{strength} bit +errors per {size} bytes". + +The interpretation of these parameters is implementation-defined, so not all +implementations must support all possible combinations. However, implementations +are encouraged to further specify the value(s) they support. diff --git a/Documentation/devicetree/bindings/mtd/st-fsm.txt b/Documentation/devicetree/bindings/mtd/st-fsm.txt new file mode 100644 index 000000000000..c2489391c437 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/st-fsm.txt @@ -0,0 +1,26 @@ +* ST-Microelectronics SPI FSM Serial (NOR) Flash Controller + +Required properties: + - compatible : Should be "st,spi-fsm" + - reg : Contains register's location and length. + - reg-names : Should contain the reg names "spi-fsm" + - interrupts : The interrupt number + - pinctrl-0 : Standard Pinctrl phandle (see: pinctrl/pinctrl-bindings.txt) + +Optional properties: + - st,syscfg : Phandle to boot-device system configuration registers + - st,boot-device-reg : Address of the aforementioned boot-device register(s) + - st,boot-device-spi : Expected boot-device value if booted via this device + +Example: + spifsm: spifsm@fe902000{ + compatible = "st,spi-fsm"; + reg = <0xfe902000 0x1000>; + reg-names = "spi-fsm"; + pinctrl-0 = <&pinctrl_fsm>; + st,syscfg = <&syscfg_rear>; + st,boot-device-reg = <0x958>; + st,boot-device-spi = <0x1a>; + status = "okay"; + }; + diff --git a/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt b/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt index 863d5b8155c7..10640b17c866 100644 --- a/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt +++ b/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt @@ -5,13 +5,9 @@ Required properties: "allwinner,sun4i-emac") - reg: address and length of the register set for the device. - interrupts: interrupt for the device -- phy: A phandle to a phy node defining the PHY address (as the reg - property, a single integer). +- phy: see ethernet.txt file in the same directory. - clocks: A phandle to the reference clock for this device -Optional properties: -- (local-)mac-address: mac address to be used by this driver - Example: emac: ethernet@01c0b000 { diff --git a/Documentation/devicetree/bindings/net/altera_tse.txt b/Documentation/devicetree/bindings/net/altera_tse.txt new file mode 100644 index 000000000000..a706297998e9 --- /dev/null +++ b/Documentation/devicetree/bindings/net/altera_tse.txt @@ -0,0 +1,114 @@ +* Altera Triple-Speed Ethernet MAC driver (TSE) + +Required properties: +- compatible: Should be "altr,tse-1.0" for legacy SGDMA based TSE, and should + be "altr,tse-msgdma-1.0" for the preferred MSGDMA based TSE. + ALTR is supported for legacy device trees, but is deprecated. + altr should be used for all new designs. +- reg: Address and length of the register set for the device. It contains + the information of registers in the same order as described by reg-names +- reg-names: Should contain the reg names + "control_port": MAC configuration space region + "tx_csr": xDMA Tx dispatcher control and status space region + "tx_desc": MSGDMA Tx dispatcher descriptor space region + "rx_csr" : xDMA Rx dispatcher control and status space region + "rx_desc": MSGDMA Rx dispatcher descriptor space region + "rx_resp": MSGDMA Rx dispatcher response space region + "s1": SGDMA descriptor memory +- interrupts: Should contain the TSE interrupts and it's mode. +- interrupt-names: Should contain the interrupt names + "rx_irq": xDMA Rx dispatcher interrupt + "tx_irq": xDMA Tx dispatcher interrupt +- rx-fifo-depth: MAC receive FIFO buffer depth in bytes +- tx-fifo-depth: MAC transmit FIFO buffer depth in bytes +- phy-mode: See ethernet.txt in the same directory. +- phy-handle: See ethernet.txt in the same directory. +- phy-addr: See ethernet.txt in the same directory. A configuration should + include phy-handle or phy-addr. +- altr,has-supplementary-unicast: + If present, TSE supports additional unicast addresses. + Otherwise additional unicast addresses are not supported. +- altr,has-hash-multicast-filter: + If present, TSE supports a hash based multicast filter. + Otherwise, hash-based multicast filtering is not supported. + +- mdio device tree subnode: When the TSE has a phy connected to its local + mdio, there must be device tree subnode with the following + required properties: + + - compatible: Must be "altr,tse-mdio". + - #address-cells: Must be <1>. + - #size-cells: Must be <0>. + + For each phy on the mdio bus, there must be a node with the following + fields: + + - reg: phy id used to communicate to phy. + - device_type: Must be "ethernet-phy". + +Optional properties: +- local-mac-address: See ethernet.txt in the same directory. +- max-frame-size: See ethernet.txt in the same directory. + +Example: + + tse_sub_0_eth_tse_0: ethernet@0x1,00000000 { + compatible = "altr,tse-msgdma-1.0"; + reg = <0x00000001 0x00000000 0x00000400>, + <0x00000001 0x00000460 0x00000020>, + <0x00000001 0x00000480 0x00000020>, + <0x00000001 0x000004A0 0x00000008>, + <0x00000001 0x00000400 0x00000020>, + <0x00000001 0x00000420 0x00000020>; + reg-names = "control_port", "rx_csr", "rx_desc", "rx_resp", "tx_csr", "tx_desc"; + interrupt-parent = <&hps_0_arm_gic_0>; + interrupts = <0 41 4>, <0 40 4>; + interrupt-names = "rx_irq", "tx_irq"; + rx-fifo-depth = <2048>; + tx-fifo-depth = <2048>; + address-bits = <48>; + max-frame-size = <1500>; + local-mac-address = [ 00 00 00 00 00 00 ]; + phy-mode = "gmii"; + altr,has-supplementary-unicast; + altr,has-hash-multicast-filter; + phy-handle = <&phy0>; + mdio { + compatible = "altr,tse-mdio"; + #address-cells = <1>; + #size-cells = <0>; + phy0: ethernet-phy@0 { + reg = <0x0>; + device_type = "ethernet-phy"; + }; + + phy1: ethernet-phy@1 { + reg = <0x1>; + device_type = "ethernet-phy"; + }; + + }; + }; + + tse_sub_1_eth_tse_0: ethernet@0x1,00001000 { + compatible = "altr,tse-msgdma-1.0"; + reg = <0x00000001 0x00001000 0x00000400>, + <0x00000001 0x00001460 0x00000020>, + <0x00000001 0x00001480 0x00000020>, + <0x00000001 0x000014A0 0x00000008>, + <0x00000001 0x00001400 0x00000020>, + <0x00000001 0x00001420 0x00000020>; + reg-names = "control_port", "rx_csr", "rx_desc", "rx_resp", "tx_csr", "tx_desc"; + interrupt-parent = <&hps_0_arm_gic_0>; + interrupts = <0 43 4>, <0 42 4>; + interrupt-names = "rx_irq", "tx_irq"; + rx-fifo-depth = <2048>; + tx-fifo-depth = <2048>; + address-bits = <48>; + max-frame-size = <1500>; + local-mac-address = [ 00 00 00 00 00 00 ]; + phy-mode = "gmii"; + altr,has-supplementary-unicast; + altr,has-hash-multicast-filter; + phy-handle = <&phy1>; + }; diff --git a/Documentation/devicetree/bindings/net/arc_emac.txt b/Documentation/devicetree/bindings/net/arc_emac.txt index bcbc3f009158..7fbb027218a1 100644 --- a/Documentation/devicetree/bindings/net/arc_emac.txt +++ b/Documentation/devicetree/bindings/net/arc_emac.txt @@ -6,19 +6,12 @@ Required properties: - interrupts: Should contain the EMAC interrupts - clock-frequency: CPU frequency. It is needed to calculate and set polling period of EMAC. -- max-speed: Maximum supported data-rate in Mbit/s. In some HW configurations -bandwidth of external memory controller might be a limiting factor. That's why -it's required to specify which data-rate is supported on current SoC or FPGA. -For example if only 10 Mbit/s is supported (10BASE-T) set "10". If 100 Mbit/s is -supported (100BASE-TX) set "100". -- phy: PHY device attached to the EMAC via MDIO bus +- max-speed: see ethernet.txt file in the same directory. +- phy: see ethernet.txt file in the same directory. Child nodes of the driver are the individual PHY devices connected to the MDIO bus. They must have a "reg" property given the PHY address on the MDIO bus. -Optional properties: -- mac-address: 6 bytes, mac address - Examples: ethernet@c0fc2000 { diff --git a/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt b/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt new file mode 100644 index 000000000000..f2febb94550e --- /dev/null +++ b/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt @@ -0,0 +1,121 @@ +* Broadcom BCM7xxx Ethernet Controller (GENET) + +Required properties: +- compatible: should contain one of "brcm,genet-v1", "brcm,genet-v2", + "brcm,genet-v3", "brcm,genet-v4". +- reg: address and length of the register set for the device +- interrupts: must be two cells, the first cell is the general purpose + interrupt line, while the second cell is the interrupt for the ring + RX and TX queues operating in ring mode +- phy-mode: see ethernet.txt file in the same directory +- #address-cells: should be 1 +- #size-cells: should be 1 + +Optional properties: +- clocks: When provided, must be two phandles to the functional clocks nodes + of the GENET block. The first phandle is the main GENET clock used during + normal operation, while the second phandle is the Wake-on-LAN clock. +- clock-names: When provided, names of the functional clock phandles, first + name should be "enet" and second should be "enet-wol". + +- phy-handle: See ethernet.txt file in the same directory; used to describe + configurations where a PHY (internal or external) is used. + +- fixed-link: When the GENET interface is connected to a MoCA hardware block or + when operating in a RGMII to RGMII type of connection, or when the MDIO bus is + voluntarily disabled, this property should be used to describe the "fixed link". + See Documentation/devicetree/bindings/net/fsl-tsec-phy.txt for information on + the property specifics + +Required child nodes: + +- mdio bus node: this node should always be present regarless of the PHY + configuration of the GENET instance + +MDIO bus node required properties: + +- compatible: should contain one of "brcm,genet-mdio-v1", "brcm,genet-mdio-v2" + "brcm,genet-mdio-v3", "brcm,genet-mdio-v4", the version has to match the + parent node compatible property (e.g: brcm,genet-v4 pairs with + brcm,genet-mdio-v4) +- reg: address and length relative to the parent node base register address +- #address-cells: address cell for MDIO bus addressing, should be 1 +- #size-cells: size of the cells for MDIO bus addressing, should be 0 + +Ethernet PHY node properties: + +See Documentation/devicetree/bindings/net/phy.txt for the list of required and +optional properties. + +Internal Gigabit PHY example: + +ethernet@f0b60000 { + phy-mode = "internal"; + phy-handle = <&phy1>; + mac-address = [ 00 10 18 36 23 1a ]; + compatible = "brcm,genet-v4"; + #address-cells = <0x1>; + #size-cells = <0x1>; + reg = <0xf0b60000 0xfc4c>; + interrupts = <0x0 0x14 0x0>, <0x0 0x15 0x0>; + + mdio@e14 { + compatible = "brcm,genet-mdio-v4"; + #address-cells = <0x1>; + #size-cells = <0x0>; + reg = <0xe14 0x8>; + + phy1: ethernet-phy@1 { + max-speed = <1000>; + reg = <0x1>; + compatible = "brcm,28nm-gphy", "ethernet-phy-ieee802.3-c22"; + }; + }; +}; + +MoCA interface / MAC to MAC example: + +ethernet@f0b80000 { + phy-mode = "moca"; + fixed-link = <1 0 1000 0 0>; + mac-address = [ 00 10 18 36 24 1a ]; + compatible = "brcm,genet-v4"; + #address-cells = <0x1>; + #size-cells = <0x1>; + reg = <0xf0b80000 0xfc4c>; + interrupts = <0x0 0x16 0x0>, <0x0 0x17 0x0>; + + mdio@e14 { + compatible = "brcm,genet-mdio-v4"; + #address-cells = <0x1>; + #size-cells = <0x0>; + reg = <0xe14 0x8>; + }; +}; + + +External MDIO-connected Gigabit PHY/switch: + +ethernet@f0ba0000 { + phy-mode = "rgmii"; + phy-handle = <&phy0>; + mac-address = [ 00 10 18 36 26 1a ]; + compatible = "brcm,genet-v4"; + #address-cells = <0x1>; + #size-cells = <0x1>; + reg = <0xf0ba0000 0xfc4c>; + interrupts = <0x0 0x18 0x0>, <0x0 0x19 0x0>; + + mdio@0e14 { + compatible = "brcm,genet-mdio-v4"; + #address-cells = <0x1>; + #size-cells = <0x0>; + reg = <0xe14 0x8>; + + phy0: ethernet-phy@0 { + max-speed = <1000>; + reg = <0x0>; + compatible = "brcm,bcm53125", "ethernet-phy-ieee802.3-c22"; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/net/can/sja1000.txt b/Documentation/devicetree/bindings/net/can/sja1000.txt index f2105a47ec87..b4a6d53fb01a 100644 --- a/Documentation/devicetree/bindings/net/can/sja1000.txt +++ b/Documentation/devicetree/bindings/net/can/sja1000.txt @@ -12,6 +12,10 @@ Required properties: Optional properties: +- reg-io-width : Specify the size (in bytes) of the IO accesses that + should be performed on the device. Valid value is 1, 2 or 4. + Default to 1 (8 bits). + - nxp,external-clock-frequency : Frequency of the external oscillator clock in Hz. Note that the internal clock frequency used by the SJA1000 is half of that value. If not specified, a default value diff --git a/Documentation/devicetree/bindings/net/cavium-mix.txt b/Documentation/devicetree/bindings/net/cavium-mix.txt index 5da628db68bf..8d7c3096390f 100644 --- a/Documentation/devicetree/bindings/net/cavium-mix.txt +++ b/Documentation/devicetree/bindings/net/cavium-mix.txt @@ -18,12 +18,7 @@ Properties: - interrupts: Two interrupt specifiers. The first is the MIX interrupt routing and the second the routing for the AGL interrupts. -- mac-address: Optional, the MAC address to assign to the device. - -- local-mac-address: Optional, the MAC address to assign to the device - if mac-address is not specified. - -- phy-handle: Optional, a phandle for the PHY device connected to this device. +- phy-handle: Optional, see ethernet.txt file in the same directory. Example: ethernet@1070000100800 { diff --git a/Documentation/devicetree/bindings/net/cavium-pip.txt b/Documentation/devicetree/bindings/net/cavium-pip.txt index d4c53ba04b3b..7dbd158810d2 100644 --- a/Documentation/devicetree/bindings/net/cavium-pip.txt +++ b/Documentation/devicetree/bindings/net/cavium-pip.txt @@ -35,12 +35,7 @@ Properties for PIP port which is a child the PIP interface: - reg: The port number within the interface group. -- mac-address: Optional, the MAC address to assign to the device. - -- local-mac-address: Optional, the MAC address to assign to the device - if mac-address is not specified. - -- phy-handle: Optional, a phandle for the PHY device connected to this device. +- phy-handle: Optional, see ethernet.txt file in the same directory. Example: diff --git a/Documentation/devicetree/bindings/net/cdns-emac.txt b/Documentation/devicetree/bindings/net/cdns-emac.txt index 09055c2495f0..abd67c13d344 100644 --- a/Documentation/devicetree/bindings/net/cdns-emac.txt +++ b/Documentation/devicetree/bindings/net/cdns-emac.txt @@ -6,11 +6,7 @@ Required properties: or the generic form: "cdns,emac". - reg: Address and length of the register set for the device - interrupts: Should contain macb interrupt -- phy-mode: String, operation mode of the PHY interface. - Supported values are: "mii", "rmii". - -Optional properties: -- local-mac-address: 6 bytes, mac address +- phy-mode: see ethernet.txt file in the same directory. Examples: diff --git a/Documentation/devicetree/bindings/net/cpsw.txt b/Documentation/devicetree/bindings/net/cpsw.txt index 05d660e4ac64..ae2b8b7f9c38 100644 --- a/Documentation/devicetree/bindings/net/cpsw.txt +++ b/Documentation/devicetree/bindings/net/cpsw.txt @@ -28,9 +28,8 @@ Optional properties: Slave Properties: Required properties: - phy_id : Specifies slave phy id -- phy-mode : The interface between the SoC and the PHY (a string - that of_get_phy_mode() can understand) -- mac-address : Specifies slave MAC address +- phy-mode : See ethernet.txt file in the same directory +- mac-address : See ethernet.txt file in the same directory Optional properties: - dual_emac_res_vlan : Specifies VID to be used to segregate the ports diff --git a/Documentation/devicetree/bindings/net/davicom-dm9000.txt b/Documentation/devicetree/bindings/net/davicom-dm9000.txt index 2d39c990e641..28767ed7c1bd 100644 --- a/Documentation/devicetree/bindings/net/davicom-dm9000.txt +++ b/Documentation/devicetree/bindings/net/davicom-dm9000.txt @@ -9,8 +9,6 @@ Required properties: - interrupts : interrupt specifier specific to interrupt controller Optional properties: -- local-mac-address : A bytestring of 6 bytes specifying Ethernet MAC address - to use (from firmware or bootloader) - davicom,no-eeprom : Configuration EEPROM is not available - davicom,ext-phy : Use external PHY diff --git a/Documentation/devicetree/bindings/net/davinci_emac.txt b/Documentation/devicetree/bindings/net/davinci_emac.txt index 6e356d15154a..032808843f90 100644 --- a/Documentation/devicetree/bindings/net/davinci_emac.txt +++ b/Documentation/devicetree/bindings/net/davinci_emac.txt @@ -17,9 +17,8 @@ Required properties: Miscellaneous Interrupt> Optional properties: -- phy-handle: Contains a phandle to an Ethernet PHY. +- phy-handle: See ethernet.txt file in the same directory. If absent, davinci_emac driver defaults to 100/FULL. -- local-mac-address : 6 bytes, mac address - ti,davinci-rmii-en: 1 byte, 1 means use RMII - ti,davinci-no-bd-ram: boolean, does EMAC have BD RAM? diff --git a/Documentation/devicetree/bindings/net/ethernet.txt b/Documentation/devicetree/bindings/net/ethernet.txt new file mode 100644 index 000000000000..3fc360523bc9 --- /dev/null +++ b/Documentation/devicetree/bindings/net/ethernet.txt @@ -0,0 +1,25 @@ +The following properties are common to the Ethernet controllers: + +- local-mac-address: array of 6 bytes, specifies the MAC address that was + assigned to the network device; +- mac-address: array of 6 bytes, specifies the MAC address that was last used by + the boot program; should be used in cases where the MAC address assigned to + the device by the boot program is different from the "local-mac-address" + property; +- max-speed: number, specifies maximum speed in Mbit/s supported by the device; +- max-frame-size: number, maximum transfer unit (IEEE defined MTU), rather than + the maximum frame size (there's contradiction in ePAPR). +- phy-mode: string, operation mode of the PHY interface; supported values are + "mii", "gmii", "sgmii", "qsgmii", "tbi", "rev-mii", "rmii", "rgmii", "rgmii-id", + "rgmii-rxid", "rgmii-txid", "rtbi", "smii", "xgmii"; this is now a de-facto + standard property; +- phy-connection-type: the same as "phy-mode" property but described in ePAPR; +- phy-handle: phandle, specifies a reference to a node representing a PHY + device; this property is described in ePAPR and so preferred; +- phy: the same as "phy-handle" property, not recommended for new bindings. +- phy-device: the same as "phy-handle" property, not recommended for new + bindings. + +Child nodes of the Ethernet controller are typically the individual PHY devices +connected via the MDIO bus (sometimes the MDIO bus controller is separate). +They are described in the phy.txt file in this same directory. diff --git a/Documentation/devicetree/bindings/net/fsl-fec.txt b/Documentation/devicetree/bindings/net/fsl-fec.txt index 845ff848d895..6bc84adb10c0 100644 --- a/Documentation/devicetree/bindings/net/fsl-fec.txt +++ b/Documentation/devicetree/bindings/net/fsl-fec.txt @@ -4,12 +4,9 @@ Required properties: - compatible : Should be "fsl,<soc>-fec" - reg : Address and length of the register set for the device - interrupts : Should contain fec interrupt -- phy-mode : String, operation mode of the PHY interface. - Supported values are: "mii", "gmii", "sgmii", "tbi", "rmii", - "rgmii", "rgmii-id", "rgmii-rxid", "rgmii-txid", "rtbi", "smii". +- phy-mode : See ethernet.txt file in the same directory Optional properties: -- local-mac-address : 6 bytes, mac address - phy-reset-gpios : Should specify the gpio for phy reset - phy-reset-duration : Reset duration in milliseconds. Should present only if property "phy-reset-gpios" is available. Missing the property diff --git a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt index d2ea4605d078..737cdef4f903 100644 --- a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt +++ b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt @@ -38,22 +38,17 @@ Properties: - model : Model of the device. Can be "TSEC", "eTSEC", or "FEC" - compatible : Should be "gianfar" - reg : Offset and length of the register set for the device - - local-mac-address : List of bytes representing the ethernet address of - this controller - interrupts : For FEC devices, the first interrupt is the device's interrupt. For TSEC and eTSEC devices, the first interrupt is transmit, the second is receive, and the third is error. - - phy-handle : The phandle for the PHY connected to this ethernet - controller. + - phy-handle : See ethernet.txt file in the same directory. - fixed-link : <a b c d e> where a is emulated phy id - choose any, but unique to the all specified fixed-links, b is duplex - 0 half, 1 full, c is link speed - d#10/d#100/d#1000, d is pause - 0 no pause, 1 pause, e is asym_pause - 0 no asym_pause, 1 asym_pause. - - phy-connection-type : a string naming the controller/PHY interface type, - i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id", "sgmii", - "tbi", or "rtbi". This property is only really needed if the connection - is of type "rgmii-id", as all other connection types are detected by - hardware. + - phy-connection-type : See ethernet.txt file in the same directory. + This property is only really needed if the connection is of type + "rgmii-id", as all other connection types are detected by hardware. - fsl,magic-packet : If present, indicates that the hardware supports waking up via magic packet. - bd-stash : If present, indicates that the hardware supports stashing diff --git a/Documentation/devicetree/bindings/net/lpc-eth.txt b/Documentation/devicetree/bindings/net/lpc-eth.txt index 585021acd178..b92e927808b6 100644 --- a/Documentation/devicetree/bindings/net/lpc-eth.txt +++ b/Documentation/devicetree/bindings/net/lpc-eth.txt @@ -6,10 +6,9 @@ Required properties: - interrupts: Should contain ethernet controller interrupt Optional properties: -- phy-mode: String, operation mode of the PHY interface. - Supported values are: "mii", "rmii" (default) +- phy-mode: See ethernet.txt file in the same directory. If the property is + absent, "rmii" is assumed. - use-iram: Use LPC32xx internal SRAM (IRAM) for DMA buffering -- local-mac-address : 6 bytes, mac address Example: diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt index 70af2ec12b09..aaa696414f57 100644 --- a/Documentation/devicetree/bindings/net/macb.txt +++ b/Documentation/devicetree/bindings/net/macb.txt @@ -8,16 +8,12 @@ Required properties: the Cadence GEM, or the generic form: "cdns,gem". - reg: Address and length of the register set for the device - interrupts: Should contain macb interrupt -- phy-mode: String, operation mode of the PHY interface. - Supported values are: "mii", "rmii", "gmii", "rgmii". +- phy-mode: See ethernet.txt file in the same directory. - clock-names: Tuple listing input clock names. Required elements: 'pclk', 'hclk' Optional elements: 'tx_clk' - clocks: Phandles to input clocks. -Optional properties: -- local-mac-address: 6 bytes, mac address - Examples: macb0: ethernet@fffc4000 { diff --git a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt index 859a6fa7569c..750d577e8083 100644 --- a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt +++ b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt @@ -4,10 +4,8 @@ Required properties: - compatible: should be "marvell,armada-370-neta". - reg: address and length of the register set for the device. - interrupts: interrupt for the device -- phy: A phandle to a phy node defining the PHY address (as the reg - property, a single integer). -- phy-mode: The interface between the SoC and the PHY (a string that - of_get_phy_mode() can understand) +- phy: See ethernet.txt file in the same directory. +- phy-mode: See ethernet.txt file in the same directory - clocks: a pointer to the reference clock for this device. Example: diff --git a/Documentation/devicetree/bindings/net/marvell-orion-net.txt b/Documentation/devicetree/bindings/net/marvell-orion-net.txt index c233b6114242..bce52b2ec55e 100644 --- a/Documentation/devicetree/bindings/net/marvell-orion-net.txt +++ b/Documentation/devicetree/bindings/net/marvell-orion-net.txt @@ -36,7 +36,7 @@ Required port properties: "marvell,kirkwood-eth-port". - reg: port number relative to ethernet controller, shall be 0, 1, or 2. - interrupts: port interrupt. - - local-mac-address: 6 bytes MAC address. + - local-mac-address: See ethernet.txt file in the same directory. Optional port properties: - marvell,tx-queue-size: size of the transmit ring buffer. @@ -48,7 +48,7 @@ Optional port properties: and - - phy-handle: phandle reference to ethernet PHY. + - phy-handle: See ethernet.txt file in the same directory. or diff --git a/Documentation/devicetree/bindings/net/micrel-ks8851.txt b/Documentation/devicetree/bindings/net/micrel-ks8851.txt index 4fc392763611..d54d0cc79487 100644 --- a/Documentation/devicetree/bindings/net/micrel-ks8851.txt +++ b/Documentation/devicetree/bindings/net/micrel-ks8851.txt @@ -6,5 +6,4 @@ Required properties: - interrupts : interrupt connection Optional properties: -- local-mac-address : Ethernet mac address to use - vdd-supply: supply for Ethernet mac diff --git a/Documentation/devicetree/bindings/net/micrel.txt b/Documentation/devicetree/bindings/net/micrel.txt new file mode 100644 index 000000000000..98a3e61f9ee8 --- /dev/null +++ b/Documentation/devicetree/bindings/net/micrel.txt @@ -0,0 +1,18 @@ +Micrel PHY properties. + +These properties cover the base properties Micrel PHYs. + +Optional properties: + + - micrel,led-mode : LED mode value to set for PHYs with configurable LEDs. + + Configure the LED mode with single value. The list of PHYs and + the bits that are currently supported: + + KSZ8001: register 0x1e, bits 15..14 + KSZ8041: register 0x1e, bits 15..14 + KSZ8021: register 0x1f, bits 5..4 + KSZ8031: register 0x1f, bits 5..4 + KSZ8051: register 0x1f, bits 5..4 + + See the respective PHY datasheet for the mode values. diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt new file mode 100644 index 000000000000..8dd3ef7bc56b --- /dev/null +++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt @@ -0,0 +1,34 @@ +* Texas Instruments TRF7970A RFID/NFC/15693 Transceiver + +Required properties: +- compatible: Should be "ti,trf7970a". +- spi-max-frequency: Maximum SPI frequency (<= 2000000). +- interrupt-parent: phandle of parent interrupt handler. +- interrupts: A single interrupt specifier. +- ti,enable-gpios: Two GPIO entries used for 'EN' and 'EN2' pins on the + TRF7970A. +- vin-supply: Regulator for supply voltage to VIN pin + +Optional SoC Specific Properties: +- pinctrl-names: Contains only one value - "default". +- pintctrl-0: Specifies the pin control groups used for this controller. + +Example (for ARM-based BeagleBone with TRF7970A on SPI1): + +&spi1 { + status = "okay"; + + nfc@0 { + compatible = "ti,trf7970a"; + reg = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&trf7970a_default>; + spi-max-frequency = <2000000>; + interrupt-parent = <&gpio2>; + interrupts = <14 0>; + ti,enable-gpios = <&gpio2 2 GPIO_ACTIVE_LOW>, + <&gpio2 5 GPIO_ACTIVE_LOW>; + vin-supply = <&ldo3_reg>; + status = "okay"; + }; +}; diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt index 58307d0931c8..5b8c58903077 100644 --- a/Documentation/devicetree/bindings/net/phy.txt +++ b/Documentation/devicetree/bindings/net/phy.txt @@ -21,10 +21,18 @@ Optional Properties: elements. - max-speed: Maximum PHY supported speed (10, 100, 1000...) + If the phy's identifier is known then the list may contain an entry + of the form: "ethernet-phy-idAAAA.BBBB" where + AAAA - The value of the 16 bit Phy Identifier 1 register as + 4 hex digits. This is the chip vendor OUI bits 3:18 + BBBB - The value of the 16 bit Phy Identifier 2 register as + 4 hex digits. This is the chip vendor OUI bits 19:24, + followed by 10 bits of a vendor specific ID. + Example: ethernet-phy@0 { - compatible = "ethernet-phy-ieee802.3-c22"; + compatible = "ethernet-phy-id0141.0e90", "ethernet-phy-ieee802.3-c22"; interrupt-parent = <40000>; interrupts = <35 1>; reg = <0>; diff --git a/Documentation/devicetree/bindings/net/samsung-sxgbe.txt b/Documentation/devicetree/bindings/net/samsung-sxgbe.txt new file mode 100644 index 000000000000..989f6c95cfd5 --- /dev/null +++ b/Documentation/devicetree/bindings/net/samsung-sxgbe.txt @@ -0,0 +1,52 @@ +* Samsung 10G Ethernet driver (SXGBE) + +Required properties: +- compatible: Should be "samsung,sxgbe-v2.0a" +- reg: Address and length of the register set for the device +- interrupt-parent: Should be the phandle for the interrupt controller + that services interrupts for this device +- interrupts: Should contain the SXGBE interrupts + These interrupts are ordered by fixed and follows variable + trasmit DMA interrupts, receive DMA interrupts and lpi interrupt. + index 0 - this is fixed common interrupt of SXGBE and it is always + available. + index 1 to 25 - 8 variable trasmit interrupts, variable 16 receive interrupts + and 1 optional lpi interrupt. +- phy-mode: String, operation mode of the PHY interface. + Supported values are: "sgmii", "xgmii". +- samsung,pbl: Integer, Programmable Burst Length. + Supported values are 1, 2, 4, 8, 16, or 32. +- samsung,burst-map: Integer, Program the possible bursts supported by sxgbe + This is an interger and represents allowable DMA bursts when fixed burst. + Allowable range is 0x01-0x3F. When this field is set fixed burst is enabled. + When fixed length is needed for burst mode, it can be set within allowable + range. + +Optional properties: +- mac-address: 6 bytes, mac address +- max-frame-size: Maximum Transfer Unit (IEEE defined MTU), rather + than the maximum frame size. + +Example: + + aliases { + ethernet0 = <&sxgbe0>; + }; + + sxgbe0: ethernet@1a040000 { + compatible = "samsung,sxgbe-v2.0a"; + reg = <0 0x1a040000 0 0x10000>; + interrupt-parent = <&gic>; + interrupts = <0 209 4>, <0 185 4>, <0 186 4>, <0 187 4>, + <0 188 4>, <0 189 4>, <0 190 4>, <0 191 4>, + <0 192 4>, <0 193 4>, <0 194 4>, <0 195 4>, + <0 196 4>, <0 197 4>, <0 198 4>, <0 199 4>, + <0 200 4>, <0 201 4>, <0 202 4>, <0 203 4>, + <0 204 4>, <0 205 4>, <0 206 4>, <0 207 4>, + <0 208 4>, <0 210 4>; + samsung,pbl = <0x08> + samsung,burst-map = <0x20> + mac-address = [ 00 11 22 33 44 55 ]; /* Filled in by U-Boot */ + max-frame-size = <9000>; + phy-mode = "xgmii"; + }; diff --git a/Documentation/devicetree/bindings/net/sh_eth.txt b/Documentation/devicetree/bindings/net/sh_eth.txt new file mode 100644 index 000000000000..e7106b50dbdc --- /dev/null +++ b/Documentation/devicetree/bindings/net/sh_eth.txt @@ -0,0 +1,55 @@ +* Renesas Electronics SH EtherMAC + +This file provides information on what the device node for the SH EtherMAC +interface contains. + +Required properties: +- compatible: "renesas,gether-r8a7740" if the device is a part of R8A7740 SoC. + "renesas,ether-r8a7778" if the device is a part of R8A7778 SoC. + "renesas,ether-r8a7779" if the device is a part of R8A7779 SoC. + "renesas,ether-r8a7790" if the device is a part of R8A7790 SoC. + "renesas,ether-r8a7791" if the device is a part of R8A7791 SoC. + "renesas,ether-r7s72100" if the device is a part of R7S72100 SoC. +- reg: offset and length of (1) the E-DMAC/feLic register block (required), + (2) the TSU register block (optional). +- interrupts: interrupt specifier for the sole interrupt. +- phy-mode: see ethernet.txt file in the same directory. +- phy-handle: see ethernet.txt file in the same directory. +- #address-cells: number of address cells for the MDIO bus, must be equal to 1. +- #size-cells: number of size cells on the MDIO bus, must be equal to 0. +- clocks: clock phandle and specifier pair. +- pinctrl-0: phandle, referring to a default pin configuration node. + +Optional properties: +- interrupt-parent: the phandle for the interrupt controller that services + interrupts for this device. +- pinctrl-names: pin configuration state name ("default"). +- renesas,no-ether-link: boolean, specify when a board does not provide a proper + Ether LINK signal. +- renesas,ether-link-active-low: boolean, specify when the Ether LINK signal is + active-low instead of normal active-high. + +Example (Lager board): + + ethernet@ee700000 { + compatible = "renesas,ether-r8a7790"; + reg = <0 0xee700000 0 0x400>; + interrupt-parent = <&gic>; + interrupts = <0 162 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&mstp8_clks R8A7790_CLK_ETHER>; + phy-mode = "rmii"; + phy-handle = <&phy1>; + pinctrl-0 = <ðer_pins>; + pinctrl-names = "default"; + renesas,ether-link-active-low; + #address-cells = <1>; + #size-cells = <0>; + + phy1: ethernet-phy@1 { + reg = <1>; + interrupt-parent = <&irqc0>; + interrupts = <0 IRQ_TYPE_LEVEL_LOW>; + pinctrl-0 = <&phy1_pins>; + pinctrl-names = "default"; + }; + }; diff --git a/Documentation/devicetree/bindings/net/smsc-lan91c111.txt b/Documentation/devicetree/bindings/net/smsc-lan91c111.txt index 5a41a8658daa..0f8487b88822 100644 --- a/Documentation/devicetree/bindings/net/smsc-lan91c111.txt +++ b/Documentation/devicetree/bindings/net/smsc-lan91c111.txt @@ -6,8 +6,7 @@ Required properties: - interrupts : interrupt connection Optional properties: -- phy-device : phandle to Ethernet phy -- local-mac-address : Ethernet mac address to use +- phy-device : see ethernet.txt file in the same directory - reg-io-width : Mask of sizes (in bytes) of the IO accesses that are supported on the device. Valid value for SMSC LAN91c111 are 1, 2 or 4. If it's omitted or invalid, the size would be 2 meaning diff --git a/Documentation/devicetree/bindings/net/smsc911x.txt b/Documentation/devicetree/bindings/net/smsc911x.txt index adb5b5744ecd..3fed3c124411 100644 --- a/Documentation/devicetree/bindings/net/smsc911x.txt +++ b/Documentation/devicetree/bindings/net/smsc911x.txt @@ -6,9 +6,7 @@ Required properties: - interrupts : Should contain SMSC LAN interrupt line - interrupt-parent : Should be the phandle for the interrupt controller that services interrupts for this device -- phy-mode : String, operation mode of the PHY interface. - Supported values are: "mii", "gmii", "sgmii", "tbi", "rmii", - "rgmii", "rgmii-id", "rgmii-rxid", "rgmii-txid", "rtbi", "smii". +- phy-mode : See ethernet.txt file in the same directory Optional properties: - reg-shift : Specify the quantity to shift the register offsets by @@ -23,7 +21,6 @@ Optional properties: external PHY - smsc,save-mac-address : Indicates that mac address needs to be saved before resetting the controller -- local-mac-address : 6 bytes, mac address Examples: diff --git a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt new file mode 100644 index 000000000000..636f0ac4e223 --- /dev/null +++ b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt @@ -0,0 +1,27 @@ +Altera SOCFPGA SoC DWMAC controller + +This is a variant of the dwmac/stmmac driver an inherits all descriptions +present in Documentation/devicetree/bindings/net/stmmac.txt. + +The device node has additional properties: + +Required properties: + - compatible : Should contain "altr,socfpga-stmmac" along with + "snps,dwmac" and any applicable more detailed + designware version numbers documented in stmmac.txt + - altr,sysmgr-syscon : Should be the phandle to the system manager node that + encompasses the glue register, the register offset, and the register shift. + +Example: + +gmac0: ethernet@ff700000 { + compatible = "altr,socfpga-stmmac", "snps,dwmac-3.70a", "snps,dwmac"; + altr,sysmgr-syscon = <&sysmgr 0x60 0>; + status = "disabled"; + reg = <0xff700000 0x2000>; + interrupts = <0 115 4>; + interrupt-names = "macirq"; + mac-address = [00 00 00 00 00 00];/* Filled in by U-Boot */ + clocks = <&emac_0_clk>; + clocks-names = "stmmaceth"; +}; diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt index 9d92d42140f2..80c1fb8bfbb8 100644 --- a/Documentation/devicetree/bindings/net/stmmac.txt +++ b/Documentation/devicetree/bindings/net/stmmac.txt @@ -10,8 +10,7 @@ Required properties: - interrupt-names: Should contain the interrupt names "macirq" "eth_wake_irq" if this interrupt is supported in the "interrupts" property -- phy-mode: String, operation mode of the PHY interface. - Supported values are: "mii", "rmii", "gmii", "rgmii". +- phy-mode: See ethernet.txt file in the same directory. - snps,reset-gpio gpio number for phy reset. - snps,reset-active-low boolean flag to indicate if phy reset is active low. - snps,reset-delays-us is triplet of delays @@ -28,12 +27,14 @@ Required properties: ignored if force_thresh_dma_mode is set. Optional properties: -- mac-address: 6 bytes, mac address - resets: Should contain a phandle to the STMMAC reset signal, if any - reset-names: Should contain the reset signal name "stmmaceth", if a reset phandle is given -- max-frame-size: Maximum Transfer Unit (IEEE defined MTU), rather - than the maximum frame size. +- max-frame-size: See ethernet.txt file in the same directory +- clocks: If present, the first clock should be the GMAC main clock, + further clocks may be specified in derived bindings. +- clocks-names: One name for each entry in the clocks property, the + first one should be "stmmaceth". Examples: @@ -46,4 +47,6 @@ Examples: mac-address = [000000000000]; /* Filled in by U-Boot */ max-frame-size = <3800>; phy-mode = "gmii"; + clocks = <&clock>; + clock-names = "stmmaceth">; }; diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt new file mode 100644 index 000000000000..189ae5cad8f7 --- /dev/null +++ b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt @@ -0,0 +1,39 @@ +* Texas Instruments wl1251 wireless lan controller + +The wl1251 chip can be connected via SPI or via SDIO. This +document describes the binding for the SPI connected chip. + +Required properties: +- compatible : Should be "ti,wl1251" +- reg : Chip select address of device +- spi-max-frequency : Maximum SPI clocking speed of device in Hz +- interrupts : Should contain interrupt line +- interrupt-parent : Should be the phandle for the interrupt controller + that services interrupts for this device +- vio-supply : phandle to regulator providing VIO +- ti,power-gpio : GPIO connected to chip's PMEN pin + +Optional properties: +- ti,wl1251-has-eeprom : boolean, the wl1251 has an eeprom connected, which + provides configuration data (calibration, MAC, ...) +- Please consult Documentation/devicetree/bindings/spi/spi-bus.txt + for optional SPI connection related properties, + +Examples: + +&spi1 { + wl1251@0 { + compatible = "ti,wl1251"; + + reg = <0>; + spi-max-frequency = <48000000>; + spi-cpol; + spi-cpha; + + interrupt-parent = <&gpio2>; + interrupts = <10 IRQ_TYPE_NONE>; /* gpio line 42 */ + + vio-supply = <&vio>; + ti,power-gpio = <&gpio3 23 GPIO_ACTIVE_HIGH>; /* 87 */ + }; +}; diff --git a/Documentation/devicetree/bindings/panel/lg,ld070wx3-sl01.txt b/Documentation/devicetree/bindings/panel/lg,ld070wx3-sl01.txt new file mode 100644 index 000000000000..5e649cb9aa1a --- /dev/null +++ b/Documentation/devicetree/bindings/panel/lg,ld070wx3-sl01.txt @@ -0,0 +1,7 @@ +LG Corporation 7" WXGA TFT LCD panel + +Required properties: +- compatible: should be "lg,ld070wx3-sl01" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/lg,lh500wx1-sd03.txt b/Documentation/devicetree/bindings/panel/lg,lh500wx1-sd03.txt new file mode 100644 index 000000000000..a04fd2b2e73d --- /dev/null +++ b/Documentation/devicetree/bindings/panel/lg,lh500wx1-sd03.txt @@ -0,0 +1,7 @@ +LG Corporation 5" HD TFT LCD panel + +Required properties: +- compatible: should be "lg,lh500wx1-sd03" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/lg,lp129qe.txt b/Documentation/devicetree/bindings/panel/lg,lp129qe.txt new file mode 100644 index 000000000000..9f262e0c5a2e --- /dev/null +++ b/Documentation/devicetree/bindings/panel/lg,lp129qe.txt @@ -0,0 +1,7 @@ +LG 12.9" (2560x1700 pixels) TFT LCD panel + +Required properties: +- compatible: should be "lg,lp129qe" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/samsung,ld9040.txt b/Documentation/devicetree/bindings/panel/samsung,ld9040.txt new file mode 100644 index 000000000000..07c36c3f7b52 --- /dev/null +++ b/Documentation/devicetree/bindings/panel/samsung,ld9040.txt @@ -0,0 +1,66 @@ +Samsung LD9040 AMOLED LCD parallel RGB panel with SPI control bus + +Required properties: + - compatible: "samsung,ld9040" + - reg: address of the panel on SPI bus + - vdd3-supply: core voltage supply + - vci-supply: voltage supply for analog circuits + - reset-gpios: a GPIO spec for the reset pin + - display-timings: timings for the connected panel according to [1] + +The panel must obey rules for SPI slave device specified in document [2]. + +Optional properties: + - power-on-delay: delay after turning regulators on [ms] + - reset-delay: delay after reset sequence [ms] + - panel-width-mm: physical panel width [mm] + - panel-height-mm: physical panel height [mm] + +The device node can contain one 'port' child node with one child +'endpoint' node, according to the bindings defined in [3]. This +node should describe panel's video bus. + +[1]: Documentation/devicetree/bindings/video/display-timing.txt +[2]: Documentation/devicetree/bindings/spi/spi-bus.txt +[3]: Documentation/devicetree/bindings/media/video-interfaces.txt + +Example: + + lcd@0 { + compatible = "samsung,ld9040"; + reg = <0>; + vdd3-supply = <&ldo7_reg>; + vci-supply = <&ldo17_reg>; + reset-gpios = <&gpy4 5 0>; + spi-max-frequency = <1200000>; + spi-cpol; + spi-cpha; + power-on-delay = <10>; + reset-delay = <10>; + panel-width-mm = <90>; + panel-height-mm = <154>; + + display-timings { + timing { + clock-frequency = <23492370>; + hactive = <480>; + vactive = <800>; + hback-porch = <16>; + hfront-porch = <16>; + vback-porch = <2>; + vfront-porch = <28>; + hsync-len = <2>; + vsync-len = <1>; + hsync-active = <0>; + vsync-active = <0>; + de-active = <0>; + pixelclk-active = <0>; + }; + }; + + port { + lcd_ep: endpoint { + remote-endpoint = <&fimd_dpi_ep>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e8aa0.txt b/Documentation/devicetree/bindings/panel/samsung,s6e8aa0.txt new file mode 100644 index 000000000000..e7ee988e3156 --- /dev/null +++ b/Documentation/devicetree/bindings/panel/samsung,s6e8aa0.txt @@ -0,0 +1,56 @@ +Samsung S6E8AA0 AMOLED LCD 5.3 inch panel + +Required properties: + - compatible: "samsung,s6e8aa0" + - reg: the virtual channel number of a DSI peripheral + - vdd3-supply: core voltage supply + - vci-supply: voltage supply for analog circuits + - reset-gpios: a GPIO spec for the reset pin + - display-timings: timings for the connected panel as described by [1] + +Optional properties: + - power-on-delay: delay after turning regulators on [ms] + - reset-delay: delay after reset sequence [ms] + - init-delay: delay after initialization sequence [ms] + - panel-width-mm: physical panel width [mm] + - panel-height-mm: physical panel height [mm] + - flip-horizontal: boolean to flip image horizontally + - flip-vertical: boolean to flip image vertically + +The device node can contain one 'port' child node with one child +'endpoint' node, according to the bindings defined in [2]. This +node should describe panel's video bus. + +[1]: Documentation/devicetree/bindings/video/display-timing.txt +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt + +Example: + + panel { + compatible = "samsung,s6e8aa0"; + reg = <0>; + vdd3-supply = <&vcclcd_reg>; + vci-supply = <&vlcd_reg>; + reset-gpios = <&gpy4 5 0>; + power-on-delay= <50>; + reset-delay = <100>; + init-delay = <100>; + panel-width-mm = <58>; + panel-height-mm = <103>; + flip-horizontal; + flip-vertical; + + display-timings { + timing0: timing-0 { + clock-frequency = <57153600>; + hactive = <720>; + vactive = <1280>; + hfront-porch = <5>; + hback-porch = <5>; + hsync-len = <5>; + vfront-porch = <13>; + vback-porch = <1>; + vsync-len = <2>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt index 24cee06915c9..c300391e8d3e 100644 --- a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt @@ -42,6 +42,10 @@ Required properties: - 0xc2000000: prefetchable memory region Please refer to the standard PCI bus binding document for a more detailed explanation. +- #interrupt-cells: Size representation for interrupts (must be 1) +- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties + Please refer to the standard PCI bus binding document for a more detailed + explanation. - clocks: Must contain an entry for each entry in clock-names. See ../clocks/clock-bindings.txt for details. - clock-names: Must include the following entries: @@ -86,6 +90,10 @@ SoC DTSI: 0 99 0x04>; /* MSI interrupt */ interrupt-names = "intr", "msi"; + #interrupt-cells = <1>; + interrupt-map-mask = <0 0 0 0>; + interrupt-map = <0 0 0 0 &intc GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>; + bus-range = <0x00 0xff>; #address-cells = <3>; #size-cells = <2>; diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt index 28f9edb8f19c..b422e38946d7 100644 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt @@ -74,3 +74,43 @@ phy-consumer@12340000 { Refer to DT bindings documentation of particular PHY consumer devices for more information about required PHYs and the way of specification. + +Samsung SATA PHY Controller +--------------------------- + +SATA PHY nodes are defined to describe on-chip SATA Physical layer controllers. +Each SATA PHY controller should have its own node. + +Required properties: +- compatible : compatible list, contains "samsung,exynos5250-sata-phy" +- reg : offset and length of the SATA PHY register set; +- #phy-cells : must be zero +- clocks : must be exactly one entry +- clock-names : must be "sata_phyctrl" +- samsung,exynos-sataphy-i2c-phandle : a phandle to the I2C device, no arguments +- samsung,syscon-phandle : a phandle to the PMU system controller, no arguments + +Example: + sata_phy: sata-phy@12170000 { + compatible = "samsung,exynos5250-sata-phy"; + reg = <0x12170000 0x1ff>; + clocks = <&clock 287>; + clock-names = "sata_phyctrl"; + #phy-cells = <0>; + samsung,exynos-sataphy-i2c-phandle = <&sata_phy_i2c>; + samsung,syscon-phandle = <&pmu_syscon>; + }; + +Device-Tree bindings for sataphy i2c client driver +-------------------------------------------------- + +Required properties: +compatible: Should be "samsung,exynos-sataphy-i2c" +- reg: I2C address of the sataphy i2c device. + +Example: + + sata_phy_i2c:sata-phy@38 { + compatible = "samsung,exynos-sataphy-i2c"; + reg = <0x38>; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt index c119debe6bab..67a5db95f189 100644 --- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt @@ -119,7 +119,7 @@ Optional Properties (for HDMI pins): Example: // pin controller node pinctrl@35004800 { - compatible = "brcmbcm11351-pinctrl"; + compatible = "brcm,bcm11351-pinctrl"; reg = <0x35004800 0x430>; // pin configuration node diff --git a/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt index 0347d8350d94..af25e77c0e0c 100644 --- a/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt +++ b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt @@ -6,8 +6,11 @@ Orion5x SoCs. Sending the character 'A', at 19200 baud, tells the microcontroller to turn the power off. This driver adds a handler to pm_power_off which is called to turn the power off. +Synology NAS devices use a similar scheme, but a different baud rate, +9600, and a different character, '1'. + Required Properties: -- compatible: Should be "qnap,power-off" +- compatible: Should be "qnap,power-off" or "synology,power-off" - reg: Address and length of the register set for UART1 - clocks: tclk clock diff --git a/Documentation/devicetree/bindings/pwm/cirrus,clps711x-pwm.txt b/Documentation/devicetree/bindings/pwm/cirrus,clps711x-pwm.txt new file mode 100644 index 000000000000..a183db48f910 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/cirrus,clps711x-pwm.txt @@ -0,0 +1,16 @@ +* Cirris Logic CLPS711X PWM controller + +Required properties: +- compatible: Shall contain "cirrus,clps711x-pwm". +- reg: Physical base address and length of the controller's registers. +- clocks: phandle + clock specifier pair of the PWM reference clock. +- #pwm-cells: Should be 1. The cell specifies the index of the channel. + +Example: + pwm: pwm@80000400 { + compatible = "cirrus,ep7312-pwm", + "cirrus,clps711x-pwm"; + reg = <0x80000400 0x4>; + clocks = <&clks 8>; + #pwm-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt b/Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt new file mode 100644 index 000000000000..0bda229a6171 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt @@ -0,0 +1,35 @@ +Freescale FlexTimer Module (FTM) PWM controller + +Required properties: +- compatible: Should be "fsl,vf610-ftm-pwm". +- reg: Physical base address and length of the controller's registers +- #pwm-cells: Should be 3. See pwm.txt in this directory for a description of + the cells format. +- clock-names: Should include the following module clock source entries: + "ftm_sys" (module clock, also can be used as counter clock), + "ftm_ext" (external counter clock), + "ftm_fix" (fixed counter clock), + "ftm_cnt_clk_en" (external and fixed counter clock enable/disable). +- clocks: Must contain a phandle and clock specifier for each entry in + clock-names, please see clock/clock-bindings.txt for details of the property + values. +- pinctrl-names: Must contain a "default" entry. +- pinctrl-NNN: One property must exist for each entry in pinctrl-names. + See pinctrl/pinctrl-bindings.txt for details of the property values. + + +Example: + +pwm0: pwm@40038000 { + compatible = "fsl,vf610-ftm-pwm"; + reg = <0x40038000 0x1000>; + #pwm-cells = <3>; + clock-names = "ftm_sys", "ftm_ext", + "ftm_fix", "ftm_cnt_clk_en"; + clocks = <&clks VF610_CLK_FTM0>, + <&clks VF610_CLK_FTM0_EXT_SEL>, + <&clks VF610_CLK_FTM0_FIX_SEL>, + <&clks VF610_CLK_FTM0_EXT_FIX_EN>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_pwm0_1>; +}; diff --git a/Documentation/devicetree/bindings/regulator/pbias-regulator.txt b/Documentation/devicetree/bindings/regulator/pbias-regulator.txt new file mode 100644 index 000000000000..32aa26f1e434 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/pbias-regulator.txt @@ -0,0 +1,27 @@ +PBIAS internal regulator for SD card dual voltage i/o pads on OMAP SoCs. + +Required properties: +- compatible: + - "ti,pbias-omap" for OMAP2, OMAP3, OMAP4, OMAP5, DRA7. +- reg: pbias register offset from syscon base and size of pbias register. +- syscon : phandle of the system control module +- regulator-name : should be + pbias_mmc_omap2430 for OMAP2430, OMAP3 SoCs + pbias_sim_omap3 for OMAP3 SoCs + pbias_mmc_omap4 for OMAP4 SoCs + pbias_mmc_omap5 for OMAP5 and DRA7 SoC + +Optional properties: +- Any optional property defined in bindings/regulator/regulator.txt + +Example: + + pbias_regulator: pbias_regulator { + compatible = "ti,pbias-omap"; + reg = <0 0x4>; + syscon = <&omap5_padconf_global>; + pbias_mmc_reg: pbias_mmc_omap5 { + regulator-name = "pbias_mmc_omap5"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3000000>; + }; diff --git a/Documentation/devicetree/bindings/reset/sirf,rstc.txt b/Documentation/devicetree/bindings/reset/sirf,rstc.txt new file mode 100644 index 000000000000..0505de742d30 --- /dev/null +++ b/Documentation/devicetree/bindings/reset/sirf,rstc.txt @@ -0,0 +1,42 @@ +CSR SiRFSoC Reset Controller +====================================== + +Please also refer to reset.txt in this directory for common reset +controller binding usage. + +Required properties: +- compatible: Should be "sirf,prima2-rstc" or "sirf,marco-rstc" +- reg: should be register base and length as documented in the + datasheet +- #reset-cells: 1, see below + +example: + +rstc: reset-controller@88010000 { + compatible = "sirf,prima2-rstc"; + reg = <0x88010000 0x1000>; + #reset-cells = <1>; +}; + +Specifying reset lines connected to IP modules +============================================== + +The reset controller(rstc) manages various reset sources. This module provides +reset signals for most blocks in system. Those device nodes should specify the +reset line on the rstc in their resets property, containing a phandle to the +rstc device node and a RESET_INDEX specifying which module to reset, as described +in reset.txt. + +For SiRFSoC, RESET_INDEX is just reset_bit defined in SW_RST0 and SW_RST1 registers. +For modules whose rest_bit is in SW_RST0, its RESET_INDEX is 0~31. For modules whose +rest_bit is in SW_RST1, its RESET_INDEX is 32~63. + +example: + +vpp@90020000 { + compatible = "sirf,prima2-vpp"; + reg = <0x90020000 0x10000>; + interrupts = <31>; + clocks = <&clks 35>; + resets = <&rstc 6>; +}; diff --git a/Documentation/devicetree/bindings/reset/st,sti-powerdown.txt b/Documentation/devicetree/bindings/reset/st,sti-powerdown.txt new file mode 100644 index 000000000000..5ab26b7e9d35 --- /dev/null +++ b/Documentation/devicetree/bindings/reset/st,sti-powerdown.txt @@ -0,0 +1,47 @@ +STMicroelectronics STi family Sysconfig Peripheral Powerdown Reset Controller +============================================================================= + +This binding describes a reset controller device that is used to enable and +disable on-chip peripheral controllers such as USB and SATA, using +"powerdown" control bits found in the STi family SoC system configuration +registers. These have been grouped together into a single reset controller +device for convenience. + +The actual action taken when powerdown is asserted is hardware dependent. +However, when asserted it may not be possible to access the hardware's +registers and after an assert/deassert sequence the hardware's previous state +may no longer be valid. + +Please refer to reset.txt in this directory for common reset +controller binding usage. + +Required properties: +- compatible: Should be "st,<chip>-powerdown" + ex: "st,stih415-powerdown", "st,stih416-powerdown" +- #reset-cells: 1, see below + +example: + + powerdown: powerdown-controller { + #reset-cells = <1>; + compatible = "st,stih415-powerdown"; + }; + + +Specifying powerdown control of devices +======================================= + +Device nodes should specify the reset channel required in their "resets" +property, containing a phandle to the powerdown device node and an +index specifying which channel to use, as described in reset.txt + +example: + + usb1: usb@fe200000 { + resets = <&powerdown STIH41X_USB1_POWERDOWN>; + }; + +Macro definitions for the supported reset channels can be found in: + +include/dt-bindings/reset-controller/stih415-resets.h +include/dt-bindings/reset-controller/stih416-resets.h diff --git a/Documentation/devicetree/bindings/reset/st,sti-softreset.txt b/Documentation/devicetree/bindings/reset/st,sti-softreset.txt new file mode 100644 index 000000000000..a8d3d3c25ca2 --- /dev/null +++ b/Documentation/devicetree/bindings/reset/st,sti-softreset.txt @@ -0,0 +1,46 @@ +STMicroelectronics STi family Sysconfig Peripheral SoftReset Controller +============================================================================= + +This binding describes a reset controller device that is used to enable and +disable on-chip peripheral controllers such as USB and SATA, using +"softreset" control bits found in the STi family SoC system configuration +registers. + +The actual action taken when softreset is asserted is hardware dependent. +However, when asserted it may not be possible to access the hardware's +registers and after an assert/deassert sequence the hardware's previous state +may no longer be valid. + +Please refer to reset.txt in this directory for common reset +controller binding usage. + +Required properties: +- compatible: Should be "st,<chip>-softreset" example: + "st,stih415-softreset" or "st,stih416-softreset"; +- #reset-cells: 1, see below + +example: + + softreset: softreset-controller { + #reset-cells = <1>; + compatible = "st,stih415-softreset"; + }; + + +Specifying softreset control of devices +======================================= + +Device nodes should specify the reset channel required in their "resets" +property, containing a phandle to the softreset device node and an +index specifying which channel to use, as described in reset.txt + +example: + + ethernet0{ + resets = <&softreset STIH415_ETH0_SOFTRESET>; + }; + +Macro definitions for the supported reset channels can be found in: + +include/dt-bindings/reset-controller/stih415-resets.h +include/dt-bindings/reset-controller/stih416-resets.h diff --git a/Documentation/devicetree/bindings/rtc/sunxi-rtc.txt b/Documentation/devicetree/bindings/rtc/sunxi-rtc.txt index 7cb9dbf34878..6983aad376c3 100644 --- a/Documentation/devicetree/bindings/rtc/sunxi-rtc.txt +++ b/Documentation/devicetree/bindings/rtc/sunxi-rtc.txt @@ -3,7 +3,7 @@ RTC controller for the Allwinner A10/A20 Required properties: -- compatible : Should be "allwinner,sun4i-rtc" or "allwinner,sun7i-a20-rtc" +- compatible : Should be "allwinner,sun4i-a10-rtc" or "allwinner,sun7i-a20-rtc" - reg: physical base address of the controller and length of memory mapped region. - interrupts: IRQ line for the RTC. @@ -11,7 +11,7 @@ Required properties: Example: rtc: rtc@01c20d00 { - compatible = "allwinner,sun4i-rtc"; + compatible = "allwinner,sun4i-a10-rtc"; reg = <0x01c20d00 0x20>; interrupts = <24>; }; diff --git a/Documentation/devicetree/bindings/serial/atmel-usart.txt b/Documentation/devicetree/bindings/serial/atmel-usart.txt index 9c5d19ac935c..17c1042b2df8 100644 --- a/Documentation/devicetree/bindings/serial/atmel-usart.txt +++ b/Documentation/devicetree/bindings/serial/atmel-usart.txt @@ -13,6 +13,8 @@ Required properties: Optional properties: - atmel,use-dma-rx: use of PDC or DMA for receiving data - atmel,use-dma-tx: use of PDC or DMA for transmitting data +- rts-gpios: specify a GPIO for RTS line. It will use specified PIO instead of the peripheral + function pin for the USART RTS feature. If unsure, don't specify this property. - add dma bindings for dma transfer: - dmas: DMA specifier, consisting of a phandle to DMA controller node, memory peripheral interface and USART DMA channel ID, FIFO configuration. @@ -33,6 +35,7 @@ Example: clock-names = "usart"; atmel,use-dma-rx; atmel,use-dma-tx; + rts-gpios = <&pioD 15 0>; }; - use DMA: diff --git a/Documentation/devicetree/bindings/serial/efm32-uart.txt b/Documentation/devicetree/bindings/serial/efm32-uart.txt index 1984bdfbd545..3ca01336b837 100644 --- a/Documentation/devicetree/bindings/serial/efm32-uart.txt +++ b/Documentation/devicetree/bindings/serial/efm32-uart.txt @@ -1,7 +1,7 @@ * Energymicro efm32 UART Required properties: -- compatible : Should be "efm32,uart" +- compatible : Should be "energymicro,efm32-uart" - reg : Address and length of the register set - interrupts : Should contain uart interrupt @@ -13,7 +13,7 @@ Optional properties: Example: uart@0x4000c400 { - compatible = "efm32,uart"; + compatible = "energymicro,efm32-uart"; reg = <0x4000c400 0x400>; interrupts = <15>; efm32,location = <0>; diff --git a/Documentation/devicetree/bindings/sound/fsl,ssi.txt b/Documentation/devicetree/bindings/sound/fsl,ssi.txt index b93e9a91e30e..3aa4a8f528f4 100644 --- a/Documentation/devicetree/bindings/sound/fsl,ssi.txt +++ b/Documentation/devicetree/bindings/sound/fsl,ssi.txt @@ -20,15 +20,6 @@ Required properties: have. - interrupt-parent: The phandle for the interrupt controller that services interrupts for this device. -- fsl,mode: The operating mode for the SSI interface. - "i2s-slave" - I2S mode, SSI is clock slave - "i2s-master" - I2S mode, SSI is clock master - "lj-slave" - left-justified mode, SSI is clock slave - "lj-master" - l.j. mode, SSI is clock master - "rj-slave" - right-justified mode, SSI is clock slave - "rj-master" - r.j., SSI is clock master - "ac97-slave" - AC97 mode, SSI is clock slave - "ac97-master" - AC97 mode, SSI is clock master - fsl,playback-dma: Phandle to a node for the DMA channel to use for playback of audio. This is typically dictated by SOC design. See the notes below. @@ -47,6 +38,9 @@ Required properties: be connected together, and SRFS and STFS be connected together. This would still allow different sample sizes, but not different sample rates. + - clocks: "ipg" - Required clock for the SSI unit + "baud" - Required clock for SSI master mode. Otherwise this + clock is not used Required are also ac97 link bindings if ac97 is used. See Documentation/devicetree/bindings/sound/soc-ac97link.txt for the necessary @@ -64,6 +58,15 @@ Optional properties: Documentation/devicetree/bindings/dma/dma.txt. - dma-names: Two dmas have to be defined, "tx" and "rx", if fsl,imx-fiq is not defined. +- fsl,mode: The operating mode for the SSI interface. + "i2s-slave" - I2S mode, SSI is clock slave + "i2s-master" - I2S mode, SSI is clock master + "lj-slave" - left-justified mode, SSI is clock slave + "lj-master" - l.j. mode, SSI is clock master + "rj-slave" - right-justified mode, SSI is clock slave + "rj-master" - r.j., SSI is clock master + "ac97-slave" - AC97 mode, SSI is clock slave + "ac97-master" - AC97 mode, SSI is clock master Child 'codec' node required properties: - compatible: Compatible list, contains the name of the codec diff --git a/Documentation/devicetree/bindings/spi/efm32-spi.txt b/Documentation/devicetree/bindings/spi/efm32-spi.txt index 8f081c96a4fa..130cd17e3680 100644 --- a/Documentation/devicetree/bindings/spi/efm32-spi.txt +++ b/Documentation/devicetree/bindings/spi/efm32-spi.txt @@ -8,7 +8,13 @@ Required properties: - interrupts: pair specifying rx and tx irq - clocks: phandle to the spi clock - cs-gpios: see spi-bus.txt -- efm32,location: Value to write to the ROUTE register's LOCATION bitfield to configure the pinmux for the device, see datasheet for values. + +Recommended properties : +- efm32,location: Value to write to the ROUTE register's LOCATION bitfield to + configure the pinmux for the device, see datasheet for values. + If "efm32,location" property is not provided, keeping what is + already configured in the hardware, so its either the reset + default 0 or whatever the bootloader did. Example: diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt b/Documentation/devicetree/bindings/usb/atmel-usb.txt index 55f51af08bc7..bc2222ca3f2a 100644 --- a/Documentation/devicetree/bindings/usb/atmel-usb.txt +++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt @@ -57,8 +57,8 @@ Required properties: - ep childnode: To specify the number of endpoints and their properties. Optional properties: - - atmel,vbus-gpio: If present, specifies a gpio that needs to be - activated for the bus to be powered. + - atmel,vbus-gpio: If present, specifies a gpio that allows to detect whether + vbus is present (USB is connected). Required child node properties: - name: Name of the endpoint. diff --git a/Documentation/devicetree/bindings/usb/ehci-omap.txt b/Documentation/devicetree/bindings/usb/ehci-omap.txt index 485a9a1efa7a..3dc231c832b0 100644 --- a/Documentation/devicetree/bindings/usb/ehci-omap.txt +++ b/Documentation/devicetree/bindings/usb/ehci-omap.txt @@ -21,7 +21,7 @@ Documentation/devicetree/bindings/mfd/omap-usb-host.txt Example for OMAP4: usbhsehci: ehci@4a064c00 { - compatible = "ti,ehci-omap", "usb-ehci"; + compatible = "ti,ehci-omap"; reg = <0x4a064c00 0x400>; interrupts = <0 77 0x4>; }; diff --git a/Documentation/devicetree/bindings/usb/ohci-omap3.txt b/Documentation/devicetree/bindings/usb/ohci-omap3.txt index 14ab42812a8e..ce8c47cff6d0 100644 --- a/Documentation/devicetree/bindings/usb/ohci-omap3.txt +++ b/Documentation/devicetree/bindings/usb/ohci-omap3.txt @@ -9,7 +9,7 @@ Required properties: Example for OMAP4: usbhsohci: ohci@4a064800 { - compatible = "ti,ohci-omap3", "usb-ohci"; + compatible = "ti,ohci-omap3"; reg = <0x4a064800 0x400>; interrupts = <0 76 0x4>; }; diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 95465d57eb31..8c27e5c26620 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -35,11 +35,13 @@ dallas Maxim Integrated Products (formerly Dallas Semiconductor) davicom DAVICOM Semiconductor, Inc. dlink D-Link Systems, Inc. denx Denx Software Engineering +dmo Data Modul AG edt Emerging Display Technologies emmicro EM Microelectronic epfl Ecole Polytechnique Fédérale de Lausanne epson Seiko Epson Corp. est ESTeem Wireless Modems +eukrea Eukréa Electromatique fsl Freescale Semiconductor GEFanuc GE Fanuc Intelligent Platforms Embedded Systems, Inc. gef GE Fanuc Intelligent Platforms Embedded Systems, Inc. @@ -83,10 +85,12 @@ picochip Picochip Ltd powervr PowerVR (deprecated, use img) qca Qualcomm Atheros, Inc. qcom Qualcomm Technologies, Inc +qnap QNAP Systems, Inc. ralink Mediatek/Ralink Technology Corp. ramtron Ramtron International realtek Realtek Semiconductor Corp. renesas Renesas Electronics Corporation +ricoh Ricoh Co. Ltd. rockchip Fuzhou Rockchip Electronics Co., Ltd samsung Samsung Semiconductor sbs Smart Battery System @@ -94,6 +98,7 @@ schindler Schindler sil Silicon Image silabs Silicon Laboratories simtek +sii Seiko Instruments, Inc. sirf SiRF Technology, Inc. smsc Standard Microsystems Corporation snps Synopsys, Inc. @@ -101,12 +106,15 @@ spansion Spansion Inc. st STMicroelectronics ste ST-Ericsson stericsson ST-Ericsson +synology Synology, Inc. ti Texas Instruments tlm Trusted Logic Mobility +toradex Toradex AG toshiba Toshiba Corporation toumaz Toumaz v3 V3 Semiconductor via VIA Technologies, Inc. +voipac Voipac Technologies s.r.o. winbond Winbond Electronics corp. wlf Wolfson Microelectronics wm Wondermedia Technologies, Inc. diff --git a/Documentation/devicetree/bindings/video/analog-tv-connector.txt b/Documentation/devicetree/bindings/video/analog-tv-connector.txt new file mode 100644 index 000000000000..0218fcdc1299 --- /dev/null +++ b/Documentation/devicetree/bindings/video/analog-tv-connector.txt @@ -0,0 +1,25 @@ +Analog TV Connector +=================== + +Required properties: +- compatible: "composite-connector" or "svideo-connector" + +Optional properties: +- label: a symbolic name for the connector + +Required nodes: +- Video port for TV input + +Example +------- + +tv: connector { + compatible = "composite-connector"; + label = "tv"; + + port { + tv_connector_in: endpoint { + remote-endpoint = <&venc_out>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/video/backlight/gpio-backlight.txt b/Documentation/devicetree/bindings/video/backlight/gpio-backlight.txt new file mode 100644 index 000000000000..321be6640533 --- /dev/null +++ b/Documentation/devicetree/bindings/video/backlight/gpio-backlight.txt @@ -0,0 +1,16 @@ +gpio-backlight bindings + +Required properties: + - compatible: "gpio-backlight" + - gpios: describes the gpio that is used for enabling/disabling the backlight. + refer to bindings/gpio/gpio.txt for more details. + +Optional properties: + - default-on: enable the backlight at boot. + +Example: + backlight { + compatible = "gpio-backlight"; + gpios = <&gpio3 4 GPIO_ACTIVE_HIGH>; + default-on; + }; diff --git a/Documentation/devicetree/bindings/video/dvi-connector.txt b/Documentation/devicetree/bindings/video/dvi-connector.txt new file mode 100644 index 000000000000..fc53f7c60bc6 --- /dev/null +++ b/Documentation/devicetree/bindings/video/dvi-connector.txt @@ -0,0 +1,35 @@ +DVI Connector +============== + +Required properties: +- compatible: "dvi-connector" + +Optional properties: +- label: a symbolic name for the connector +- ddc-i2c-bus: phandle to the i2c bus that is connected to DVI DDC +- analog: the connector has DVI analog pins +- digital: the connector has DVI digital pins +- dual-link: the connector has pins for DVI dual-link + +Required nodes: +- Video port for DVI input + +Note: One (or both) of 'analog' or 'digital' must be set. + +Example +------- + +dvi0: connector@0 { + compatible = "dvi-connector"; + label = "dvi"; + + digital; + + ddc-i2c-bus = <&i2c3>; + + port { + dvi_connector_in: endpoint { + remote-endpoint = <&tfp410_out>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt b/Documentation/devicetree/bindings/video/exynos_dp.txt index 3289d76a21d0..57ccdde02c3a 100644 --- a/Documentation/devicetree/bindings/video/exynos_dp.txt +++ b/Documentation/devicetree/bindings/video/exynos_dp.txt @@ -49,6 +49,8 @@ Required properties for dp-controller: -samsung,lane-count: number of lanes supported by the panel. LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4 + - display-timings: timings for the connected panel as described by + Documentation/devicetree/bindings/video/display-timing.txt Optional properties for dp-controller: -interlaced: @@ -84,4 +86,19 @@ Board Specific portion: samsung,color-depth = <1>; samsung,link-rate = <0x0a>; samsung,lane-count = <4>; + + display-timings { + native-mode = <&lcd_timing>; + lcd_timing: 1366x768 { + clock-frequency = <70589280>; + hactive = <1366>; + vactive = <768>; + hfront-porch = <40>; + hback-porch = <40>; + hsync-len = <32>; + vback-porch = <10>; + vfront-porch = <12>; + vsync-len = <6>; + }; + }; }; diff --git a/Documentation/devicetree/bindings/video/exynos_dsim.txt b/Documentation/devicetree/bindings/video/exynos_dsim.txt new file mode 100644 index 000000000000..33b5730d07ba --- /dev/null +++ b/Documentation/devicetree/bindings/video/exynos_dsim.txt @@ -0,0 +1,80 @@ +Exynos MIPI DSI Master + +Required properties: + - compatible: "samsung,exynos4210-mipi-dsi" + - reg: physical base address and length of the registers set for the device + - interrupts: should contain DSI interrupt + - clocks: list of clock specifiers, must contain an entry for each required + entry in clock-names + - clock-names: should include "bus_clk"and "pll_clk" entries + - phys: list of phy specifiers, must contain an entry for each required + entry in phy-names + - phy-names: should include "dsim" entry + - vddcore-supply: MIPI DSIM Core voltage supply (e.g. 1.1V) + - vddio-supply: MIPI DSIM I/O and PLL voltage supply (e.g. 1.8V) + - samsung,pll-clock-frequency: specifies frequency of the "pll_clk" clock + - #address-cells, #size-cells: should be set respectively to <1> and <0> + according to DSI host bindings (see MIPI DSI bindings [1]) + +Optional properties: + - samsung,power-domain: a phandle to DSIM power domain node + +Child nodes: + Should contain DSI peripheral nodes (see MIPI DSI bindings [1]). + +Video interfaces: + Device node can contain video interface port nodes according to [2]. + The following are properties specific to those nodes: + + port node: + - reg: (required) can be 0 for input RGB/I80 port or 1 for DSI port; + + endpoint node of DSI port (reg = 1): + - samsung,burst-clock-frequency: specifies DSI frequency in high-speed burst + mode + - samsung,esc-clock-frequency: specifies DSI frequency in escape mode + +[1]: Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt + +Example: + + dsi@11C80000 { + compatible = "samsung,exynos4210-mipi-dsi"; + reg = <0x11C80000 0x10000>; + interrupts = <0 79 0>; + clocks = <&clock 286>, <&clock 143>; + clock-names = "bus_clk", "pll_clk"; + phys = <&mipi_phy 1>; + phy-names = "dsim"; + vddcore-supply = <&vusb_reg>; + vddio-supply = <&vmipi_reg>; + samsung,power-domain = <&pd_lcd0>; + #address-cells = <1>; + #size-cells = <0>; + samsung,pll-clock-frequency = <24000000>; + + panel@1 { + reg = <0>; + ... + port { + panel_ep: endpoint { + remote-endpoint = <&dsi_ep>; + }; + }; + }; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@1 { + dsi_ep: endpoint { + reg = <0>; + samsung,burst-clock-frequency = <500000000>; + samsung,esc-clock-frequency = <20000000>; + remote-endpoint = <&panel_ep>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index 50decf8e1b90..f9187a259259 100644 --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt @@ -25,6 +25,9 @@ Required properties: sclk_pixel. - clock-names: aliases as per driver requirements for above clock IDs: "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi". +- ddc: phandle to the hdmi ddc node +- phy: phandle to the hdmi phy node + Example: hdmi { @@ -32,4 +35,6 @@ Example: reg = <0x14530000 0x100000>; interrupts = <0 95 0>; hpd-gpio = <&gpx3 7 1>; + ddc = <&hdmi_ddc_node>; + phy = <&hdmi_phy_node>; }; diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt index 46da08db186a..0329f60d431e 100644 --- a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt +++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt @@ -15,8 +15,12 @@ Required nodes: - fsl,pcr: LCDC PCR value Optional properties: +- lcd-supply: Regulator for LCD supply voltage. - fsl,dmacr: DMA Control Register value. This is optional. By default, the register is not modified as recommended by the datasheet. +- fsl,lpccr: Contrast Control Register value. This property provides the + default value for the contrast control register. + If that property is ommited, the register is zeroed. - fsl,lscr1: LCDC Sharp Configuration Register value. Example: diff --git a/Documentation/devicetree/bindings/video/hdmi-connector.txt b/Documentation/devicetree/bindings/video/hdmi-connector.txt new file mode 100644 index 000000000000..ccccc19e2573 --- /dev/null +++ b/Documentation/devicetree/bindings/video/hdmi-connector.txt @@ -0,0 +1,28 @@ +HDMI Connector +============== + +Required properties: +- compatible: "hdmi-connector" +- type: the HDMI connector type: "a", "b", "c", "d" or "e" + +Optional properties: +- label: a symbolic name for the connector + +Required nodes: +- Video port for HDMI input + +Example +------- + +hdmi0: connector@1 { + compatible = "hdmi-connector"; + label = "hdmi"; + + type = "a"; + + port { + hdmi_connector_in: endpoint { + remote-endpoint = <&tpd12s015_out>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/video/panel-dsi-cm.txt b/Documentation/devicetree/bindings/video/panel-dsi-cm.txt new file mode 100644 index 000000000000..dce48eb9db57 --- /dev/null +++ b/Documentation/devicetree/bindings/video/panel-dsi-cm.txt @@ -0,0 +1,29 @@ +Generic MIPI DSI Command Mode Panel +=================================== + +Required properties: +- compatible: "panel-dsi-cm" + +Optional properties: +- label: a symbolic name for the panel +- reset-gpios: panel reset gpio +- te-gpios: panel TE gpio + +Required nodes: +- Video port for DSI input + +Example +------- + +lcd0: display { + compatible = "tpo,taal", "panel-dsi-cm"; + label = "lcd0"; + + reset-gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; + + port { + lcd0_in: endpoint { + remote-endpoint = <&dsi1_out_ep>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt b/Documentation/devicetree/bindings/video/samsung-fimd.txt index 778838a0336a..2dad41b689af 100644 --- a/Documentation/devicetree/bindings/video/samsung-fimd.txt +++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt @@ -39,6 +39,23 @@ Required properties: Optional Properties: - samsung,power-domain: a phandle to FIMD power domain node. +- samsung,invert-vden: video enable signal is inverted +- samsung,invert-vclk: video clock signal is inverted +- display-timings: timing settings for FIMD, as described in document [1]. + Can be used in case timings cannot be provided otherwise + or to override timings provided by the panel. + +The device node can contain 'port' child nodes according to the bindings defined +in [2]. The following are properties specific to those nodes: +- reg: (required) port index, can be: + 0 - for CAMIF0 input, + 1 - for CAMIF1 input, + 2 - for CAMIF2 input, + 3 - for parallel output, + 4 - for write-back interface + +[1]: Documentation/devicetree/bindings/video/display-timing.txt +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt Example: diff --git a/Documentation/devicetree/bindings/video/sony,acx565akm.txt b/Documentation/devicetree/bindings/video/sony,acx565akm.txt new file mode 100644 index 000000000000..e12333280749 --- /dev/null +++ b/Documentation/devicetree/bindings/video/sony,acx565akm.txt @@ -0,0 +1,30 @@ +Sony ACX565AKM SDI Panel +======================== + +Required properties: +- compatible: "sony,acx565akm" + +Optional properties: +- label: a symbolic name for the panel +- reset-gpios: panel reset gpio + +Required nodes: +- Video port for SDI input + +Example +------- + +acx565akm@2 { + compatible = "sony,acx565akm"; + spi-max-frequency = <6000000>; + reg = <2>; + + label = "lcd"; + reset-gpios = <&gpio3 26 GPIO_ACTIVE_HIGH>; /* 90 */ + + port { + lcd_in: endpoint { + remote-endpoint = <&sdi_out>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/video/ti,omap-dss.txt b/Documentation/devicetree/bindings/video/ti,omap-dss.txt new file mode 100644 index 000000000000..d5f1a3fe3109 --- /dev/null +++ b/Documentation/devicetree/bindings/video/ti,omap-dss.txt @@ -0,0 +1,211 @@ +Texas Instruments OMAP Display Subsystem +======================================== + +Generic Description +------------------- + +This document is a generic description of the OMAP Display Subsystem bindings. +Binding details for each OMAP SoC version are described in respective binding +documentation. + +The OMAP Display Subsystem (DSS) hardware consists of DSS Core, DISPC module and +a number of encoder modules. All DSS versions contain DSS Core and DISPC, but +the encoder modules vary. + +The DSS Core is the parent of the other DSS modules, and manages clock routing, +integration to the SoC, etc. + +DISPC is the display controller, which reads pixels from the memory and outputs +a RGB pixel stream to encoders. + +The encoder modules encode the received RGB pixel stream to a video output like +HDMI, MIPI DPI, etc. + +Video Ports +----------- + +The DSS Core and the encoders have video port outputs. The structure of the +video ports is described in Documentation/devicetree/bindings/video/video- +ports.txt, and the properties for the ports and endpoints for each encoder are +described in the SoC's DSS binding documentation. + +The video ports are used to describe the connections to external hardware, like +panels or external encoders. + +Aliases +------- + +The board dts file may define aliases for displays to assign "displayX" style +name for each display. If no aliases are defined, a semi-random number is used +for the display. + +Example +------- + +A shortened example of the DSS description for OMAP4, with non-relevant parts +removed, defined in omap4.dtsi: + +dss: dss@58000000 { + compatible = "ti,omap4-dss"; + reg = <0x58000000 0x80>; + status = "disabled"; + ti,hwmods = "dss_core"; + clocks = <&dss_dss_clk>; + clock-names = "fck"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + dispc@58001000 { + compatible = "ti,omap4-dispc"; + reg = <0x58001000 0x1000>; + interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>; + ti,hwmods = "dss_dispc"; + clocks = <&dss_dss_clk>; + clock-names = "fck"; + }; + + hdmi: encoder@58006000 { + compatible = "ti,omap4-hdmi"; + reg = <0x58006000 0x200>, + <0x58006200 0x100>, + <0x58006300 0x100>, + <0x58006400 0x1000>; + reg-names = "wp", "pll", "phy", "core"; + interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>; + status = "disabled"; + ti,hwmods = "dss_hdmi"; + clocks = <&dss_48mhz_clk>, <&dss_sys_clk>; + clock-names = "fck", "sys_clk"; + }; +}; + +A shortened example of the board description for OMAP4 Panda board, defined in +omap4-panda.dts. + +The Panda board has a DVI and a HDMI connector, and the board contains a TFP410 +chip (MIPI DPI to DVI encoder) and a TPD12S015 chip (HDMI ESD protection & level +shifter). The video pipelines for the connectors are formed as follows: + +DSS Core --(MIPI DPI)--> TFP410 --(DVI)--> DVI Connector +OMAP HDMI --(HDMI)--> TPD12S015 --(HDMI)--> HDMI Connector + +/ { + aliases { + display0 = &dvi0; + display1 = &hdmi0; + }; + + tfp410: encoder@0 { + compatible = "ti,tfp410"; + gpios = <&gpio1 0 GPIO_ACTIVE_LOW>; /* 0, power-down */ + + pinctrl-names = "default"; + pinctrl-0 = <&tfp410_pins>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + tfp410_in: endpoint@0 { + remote-endpoint = <&dpi_out>; + }; + }; + + port@1 { + reg = <1>; + + tfp410_out: endpoint@0 { + remote-endpoint = <&dvi_connector_in>; + }; + }; + }; + }; + + dvi0: connector@0 { + compatible = "dvi-connector"; + label = "dvi"; + + i2c-bus = <&i2c3>; + + port { + dvi_connector_in: endpoint { + remote-endpoint = <&tfp410_out>; + }; + }; + }; + + tpd12s015: encoder@1 { + compatible = "ti,tpd12s015"; + + pinctrl-names = "default"; + pinctrl-0 = <&tpd12s015_pins>; + + gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>, /* 60, CT CP HPD */ + <&gpio2 9 GPIO_ACTIVE_HIGH>, /* 41, LS OE */ + <&gpio2 31 GPIO_ACTIVE_HIGH>; /* 63, HPD */ + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + tpd12s015_in: endpoint@0 { + remote-endpoint = <&hdmi_out>; + }; + }; + + port@1 { + reg = <1>; + + tpd12s015_out: endpoint@0 { + remote-endpoint = <&hdmi_connector_in>; + }; + }; + }; + }; + + hdmi0: connector@1 { + compatible = "hdmi-connector"; + label = "hdmi"; + + port { + hdmi_connector_in: endpoint { + remote-endpoint = <&tpd12s015_out>; + }; + }; + }; +}; + +&dss { + status = "ok"; + + pinctrl-names = "default"; + pinctrl-0 = <&dss_dpi_pins>; + + port { + dpi_out: endpoint { + remote-endpoint = <&tfp410_in>; + data-lines = <24>; + }; + }; +}; + +&hdmi { + status = "ok"; + vdda-supply = <&vdac>; + + pinctrl-names = "default"; + pinctrl-0 = <&dss_hdmi_pins>; + + port { + hdmi_out: endpoint { + remote-endpoint = <&tpd12s015_in>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/video/ti,omap2-dss.txt b/Documentation/devicetree/bindings/video/ti,omap2-dss.txt new file mode 100644 index 000000000000..fa8bb2ed1170 --- /dev/null +++ b/Documentation/devicetree/bindings/video/ti,omap2-dss.txt @@ -0,0 +1,54 @@ +Texas Instruments OMAP2 Display Subsystem +========================================= + +See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic +description about OMAP Display Subsystem bindings. + +DSS Core +-------- + +Required properties: +- compatible: "ti,omap2-dss" +- reg: address and length of the register space +- ti,hwmods: "dss_core" + +Optional nodes: +- Video port for DPI output + +DPI Endpoint required properties: +- data-lines: number of lines used + + +DISPC +----- + +Required properties: +- compatible: "ti,omap2-dispc" +- reg: address and length of the register space +- ti,hwmods: "dss_dispc" +- interrupts: the DISPC interrupt + + +RFBI +---- + +Required properties: +- compatible: "ti,omap2-rfbi" +- reg: address and length of the register space +- ti,hwmods: "dss_rfbi" + + +VENC +---- + +Required properties: +- compatible: "ti,omap2-venc" +- reg: address and length of the register space +- ti,hwmods: "dss_venc" +- vdda-supply: power supply for DAC + +VENC Endpoint required properties: + +Required properties: +- ti,invert-polarity: invert the polarity of the video signal +- ti,channels: 1 for composite, 2 for s-video diff --git a/Documentation/devicetree/bindings/video/ti,omap3-dss.txt b/Documentation/devicetree/bindings/video/ti,omap3-dss.txt new file mode 100644 index 000000000000..0023fa4b1328 --- /dev/null +++ b/Documentation/devicetree/bindings/video/ti,omap3-dss.txt @@ -0,0 +1,83 @@ +Texas Instruments OMAP3 Display Subsystem +========================================= + +See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic +description about OMAP Display Subsystem bindings. + +DSS Core +-------- + +Required properties: +- compatible: "ti,omap3-dss" +- reg: address and length of the register space +- ti,hwmods: "dss_core" +- clocks: handle to fclk +- clock-names: "fck" + +Optional nodes: +- Video ports: + - Port 0: DPI output + - Port 1: SDI output + +DPI Endpoint required properties: +- data-lines: number of lines used + +SDI Endpoint required properties: +- datapairs: number of datapairs used + + +DISPC +----- + +Required properties: +- compatible: "ti,omap3-dispc" +- reg: address and length of the register space +- ti,hwmods: "dss_dispc" +- interrupts: the DISPC interrupt +- clocks: handle to fclk +- clock-names: "fck" + + +RFBI +---- + +Required properties: +- compatible: "ti,omap3-rfbi" +- reg: address and length of the register space +- ti,hwmods: "dss_rfbi" +- clocks: handles to fclk and iclk +- clock-names: "fck", "ick" + + +VENC +---- + +Required properties: +- compatible: "ti,omap3-venc" +- reg: address and length of the register space +- ti,hwmods: "dss_venc" +- vdda-supply: power supply for DAC +- clocks: handle to fclk +- clock-names: "fck" + +VENC Endpoint required properties: +- ti,invert-polarity: invert the polarity of the video signal +- ti,channels: 1 for composite, 2 for s-video + + +DSI +--- + +Required properties: +- compatible: "ti,omap3-dsi" +- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll' +- reg-names: "proto", "phy", "pll" +- interrupts: the DSI interrupt line +- ti,hwmods: "dss_dsi1" +- vdd-supply: power supply for DSI +- clocks: handles to fclk and pll clock +- clock-names: "fck", "sys_clk" + +DSI Endpoint required properties: +- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-, + DATA1+, DATA1-, ... diff --git a/Documentation/devicetree/bindings/video/ti,omap4-dss.txt b/Documentation/devicetree/bindings/video/ti,omap4-dss.txt new file mode 100644 index 000000000000..f85d6fcfa705 --- /dev/null +++ b/Documentation/devicetree/bindings/video/ti,omap4-dss.txt @@ -0,0 +1,111 @@ +Texas Instruments OMAP4 Display Subsystem +========================================= + +See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic +description about OMAP Display Subsystem bindings. + +DSS Core +-------- + +Required properties: +- compatible: "ti,omap4-dss" +- reg: address and length of the register space +- ti,hwmods: "dss_core" +- clocks: handle to fclk +- clock-names: "fck" + +Required nodes: +- DISPC + +Optional nodes: +- DSS Submodules: RFBI, VENC, DSI, HDMI +- Video port for DPI output + +DPI Endpoint required properties: +- data-lines: number of lines used + + +DISPC +----- + +Required properties: +- compatible: "ti,omap4-dispc" +- reg: address and length of the register space +- ti,hwmods: "dss_dispc" +- interrupts: the DISPC interrupt +- clocks: handle to fclk +- clock-names: "fck" + + +RFBI +---- + +Required properties: +- compatible: "ti,omap4-rfbi" +- reg: address and length of the register space +- ti,hwmods: "dss_rfbi" +- clocks: handles to fclk and iclk +- clock-names: "fck", "ick" + +Optional nodes: +- Video port for RFBI output +- RFBI controlled peripherals + + +VENC +---- + +Required properties: +- compatible: "ti,omap4-venc" +- reg: address and length of the register space +- ti,hwmods: "dss_venc" +- vdda-supply: power supply for DAC +- clocks: handle to fclk +- clock-names: "fck" + +Optional nodes: +- Video port for VENC output + +VENC Endpoint required properties: +- ti,invert-polarity: invert the polarity of the video signal +- ti,channels: 1 for composite, 2 for s-video + + +DSI +--- + +Required properties: +- compatible: "ti,omap4-dsi" +- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll' +- reg-names: "proto", "phy", "pll" +- interrupts: the DSI interrupt line +- ti,hwmods: "dss_dsi1" or "dss_dsi2" +- vdd-supply: power supply for DSI +- clocks: handles to fclk and pll clock +- clock-names: "fck", "sys_clk" + +Optional nodes: +- Video port for DSI output +- DSI controlled peripherals + +DSI Endpoint required properties: +- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-, + DATA1+, DATA1-, ... + + +HDMI +---- + +Required properties: +- compatible: "ti,omap4-hdmi" +- reg: addresses and lengths of the register spaces for 'wp', 'pll', 'phy', + 'core' +- reg-names: "wp", "pll", "phy", "core" +- interrupts: the HDMI interrupt line +- ti,hwmods: "dss_hdmi" +- vdda-supply: vdda power supply +- clocks: handles to fclk and pll clock +- clock-names: "fck", "sys_clk" + +Optional nodes: +- Video port for HDMI output diff --git a/Documentation/devicetree/bindings/video/ti,tfp410.txt b/Documentation/devicetree/bindings/video/ti,tfp410.txt new file mode 100644 index 000000000000..2cbe32a3d0bb --- /dev/null +++ b/Documentation/devicetree/bindings/video/ti,tfp410.txt @@ -0,0 +1,41 @@ +TFP410 DPI to DVI encoder +========================= + +Required properties: +- compatible: "ti,tfp410" + +Optional properties: +- powerdown-gpios: power-down gpio + +Required nodes: +- Video port 0 for DPI input +- Video port 1 for DVI output + +Example +------- + +tfp410: encoder@0 { + compatible = "ti,tfp410"; + powerdown-gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + tfp410_in: endpoint@0 { + remote-endpoint = <&dpi_out>; + }; + }; + + port@1 { + reg = <1>; + + tfp410_out: endpoint@0 { + remote-endpoint = <&dvi_connector_in>; + }; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/video/ti,tpd12s015.txt b/Documentation/devicetree/bindings/video/ti,tpd12s015.txt new file mode 100644 index 000000000000..26e6d32e3f20 --- /dev/null +++ b/Documentation/devicetree/bindings/video/ti,tpd12s015.txt @@ -0,0 +1,44 @@ +TPD12S015 HDMI level shifter and ESD protection chip +==================================================== + +Required properties: +- compatible: "ti,tpd12s015" + +Optional properties: +- gpios: CT CP HPD, LS OE and HPD gpios + +Required nodes: +- Video port 0 for HDMI input +- Video port 1 for HDMI output + +Example +------- + +tpd12s015: encoder@1 { + compatible = "ti,tpd12s015"; + + gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>, /* 60, CT CP HPD */ + <&gpio2 9 GPIO_ACTIVE_HIGH>, /* 41, LS OE */ + <&gpio2 31 GPIO_ACTIVE_HIGH>; /* 63, HPD */ + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + tpd12s015_in: endpoint@0 { + remote-endpoint = <&hdmi_out>; + }; + }; + + port@1 { + reg = <1>; + + tpd12s015_out: endpoint@0 { + remote-endpoint = <&hdmi_connector_in>; + }; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/watchdog/marvel.txt b/Documentation/devicetree/bindings/watchdog/marvel.txt index 5dc8d30061ce..de11eb4c121f 100644 --- a/Documentation/devicetree/bindings/watchdog/marvel.txt +++ b/Documentation/devicetree/bindings/watchdog/marvel.txt @@ -3,17 +3,24 @@ Required Properties: - Compatibility : "marvell,orion-wdt" -- reg : Address of the timer registers + "marvell,armada-370-wdt" + "marvell,armada-xp-wdt" + +- reg : Should contain two entries: first one with the + timer control address, second one with the + rstout enable address. Optional properties: +- interrupts : Contains the IRQ for watchdog expiration - timeout-sec : Contains the watchdog timeout in seconds Example: wdt@20300 { compatible = "marvell,orion-wdt"; - reg = <0x20300 0x28>; + reg = <0x20300 0x28>, <0x20108 0x4>; + interrupts = <3>; timeout-sec = <10>; status = "okay"; }; diff --git a/Documentation/dontdiff b/Documentation/dontdiff index b89a739a3276..9de9813d0ec5 100644 --- a/Documentation/dontdiff +++ b/Documentation/dontdiff @@ -1,5 +1,6 @@ *.a *.aux +*.bc *.bin *.bz2 *.cis @@ -21,6 +22,7 @@ *.i *.jpeg *.ko +*.ll *.log *.lst *.lzma @@ -35,6 +37,7 @@ *.out *.patch *.pdf +*.plist *.png *.pot *.ps diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware index 5d5ee4c13fa6..d91b8be80b66 100755 --- a/Documentation/dvb/get_dvb_firmware +++ b/Documentation/dvb/get_dvb_firmware @@ -28,8 +28,8 @@ use IO::Handle; "opera1", "cx231xx", "cx18", "cx23885", "pvrusb2", "mpc718", "af9015", "ngene", "az6027", "lme2510_lg", "lme2510c_s7395", "lme2510c_s7395_old", "drxk", "drxk_terratec_h5", - "drxk_hauppauge_hvr930c", "tda10071", "it9135", "it9137", - "drxk_pctv", "drxk_terratec_htc_stick", "sms1xxx_hcw"); + "drxk_hauppauge_hvr930c", "tda10071", "it9135", "drxk_pctv", + "drxk_terratec_htc_stick", "sms1xxx_hcw"); # Check args syntax() if (scalar(@ARGV) != 1); @@ -727,24 +727,6 @@ sub it9135 { "$fwfile1 $fwfile2" } -sub it9137 { - my $url = "http://kworld.server261.com/kworld/CD/ITE_TiVme/V1.00/"; - my $zipfile = "Driver_V10.323.1.0412.100412.zip"; - my $hash = "79b597dc648698ed6820845c0c9d0d37"; - my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 0); - my $drvfile = "Driver_V10.323.1.0412.100412/Data/x86/IT9135BDA.sys"; - my $fwfile = "dvb-usb-it9137-01.fw"; - - checkstandard(); - - wgetfile($zipfile, $url . $zipfile); - verify($zipfile, $hash); - unzip($zipfile, $tmpdir); - extract("$tmpdir/$drvfile", 69632, 5731, "$fwfile"); - - "$fwfile" -} - sub tda10071 { my $sourcefile = "PCTV_460e_reference.zip"; my $url = "ftp://ftp.pctvsystems.com/TV/driver/PCTV%2070e%2080e%20100e%20320e%20330e%20800e/"; diff --git a/Documentation/dvb/it9137.txt b/Documentation/dvb/it9137.txt deleted file mode 100644 index 9e6726eead90..000000000000 --- a/Documentation/dvb/it9137.txt +++ /dev/null @@ -1,9 +0,0 @@ -To extract firmware for Kworld UB499-2T (id 1b80:e409) you need to copy the -following file(s) to this directory. - -IT9135BDA.sys Dated Mon 22 Mar 2010 02:20:08 GMT - -extract using dd -dd if=IT9135BDA.sys ibs=1 skip=69632 count=5731 of=dvb-usb-it9137-01.fw - -copy to default firmware location. diff --git a/Documentation/edac.txt b/Documentation/edac.txt index 56c7e936430f..cb4c2cefd45a 100644 --- a/Documentation/edac.txt +++ b/Documentation/edac.txt @@ -6,7 +6,7 @@ Written by Doug Thompson <dougthompson@xmission.com> 7 Dec 2005 17 Jul 2007 Updated -(c) Mauro Carvalho Chehab <mchehab@redhat.com> +(c) Mauro Carvalho Chehab 05 Aug 2009 Nehalem interface EDAC is maintained and written by: diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index 5b0c083d7c0e..eba790134253 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking @@ -47,6 +47,8 @@ prototypes: int (*mknod) (struct inode *,struct dentry *,umode_t,dev_t); int (*rename) (struct inode *, struct dentry *, struct inode *, struct dentry *); + int (*rename2) (struct inode *, struct dentry *, + struct inode *, struct dentry *, unsigned int); int (*readlink) (struct dentry *, char __user *,int); void * (*follow_link) (struct dentry *, struct nameidata *); void (*put_link) (struct dentry *, struct nameidata *, void *); @@ -78,6 +80,7 @@ mkdir: yes unlink: yes (both) rmdir: yes (both) (see below) rename: yes (all) (see below) +rename2: yes (all) (see below) readlink: no follow_link: no put_link: no @@ -96,7 +99,8 @@ tmpfile: no Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_mutex on victim. - cross-directory ->rename() has (per-superblock) ->s_vfs_rename_sem. + cross-directory ->rename() and rename2() has (per-superblock) +->s_vfs_rename_sem. See Documentation/filesystems/directory-locking for more detailed discussion of the locking scheme for directory operations. @@ -198,7 +202,7 @@ prototypes: unsigned long *); int (*migratepage)(struct address_space *, struct page *, struct page *); int (*launder_page)(struct page *); - int (*is_partially_uptodate)(struct page *, read_descriptor_t *, unsigned long); + int (*is_partially_uptodate)(struct page *, unsigned long, unsigned long); int (*error_remove_page)(struct address_space *, struct page *); int (*swap_activate)(struct file *); int (*swap_deactivate)(struct file *); @@ -525,6 +529,7 @@ locking rules: open: yes close: yes fault: yes can return with page locked +map_pages: yes page_mkwrite: yes can return with page locked access: yes @@ -536,6 +541,15 @@ the page, then ensure it is not already truncated (the page lock will block subsequent truncate), and then return with VM_FAULT_LOCKED, and the page locked. The VM will unlock the page. + ->map_pages() is called when VM asks to map easy accessible pages. +Filesystem should find and map pages associated with offsets from "pgoff" +till "max_pgoff". ->map_pages() is called with page table locked and must +not block. If it's not possible to reach a page without blocking, +filesystem should skip it. Filesystem should use do_set_pte() to setup +page table entry. Pointer to entry associated with offset "pgoff" is +passed in "pte" field in vm_fault structure. Pointers to entries for other +offsets should be calculated relative to "pte". + ->page_mkwrite() is called when a previously read-only pte is about to become writeable. The filesystem again must ensure that there are no truncate/invalidate races, and then return with the page locked. If diff --git a/Documentation/filesystems/affs.txt b/Documentation/filesystems/affs.txt index 81ac488e3758..71b63c2b9841 100644 --- a/Documentation/filesystems/affs.txt +++ b/Documentation/filesystems/affs.txt @@ -49,6 +49,10 @@ mode=mode Sets the mode flags to the given (octal) value, regardless This is useful since most of the plain AmigaOS files will map to 600. +nofilenametruncate + The file system will return an error when filename exceeds + standard maximum filename length (30 characters). + reserved=num Sets the number of reserved blocks at the start of the partition to num. You should never need this option. Default is 2. @@ -181,9 +185,8 @@ tested, though several hundred MB have been read and written using this fs. For a most up-to-date list of bugs please consult fs/affs/Changes. -Filenames are truncated to 30 characters without warning (this -can be changed by setting the compile-time option AFFS_NO_TRUNCATE -in include/linux/amigaffs.h). +By default, filenames are truncated to 30 characters without warning. +'nofilenametruncate' mount option can change that behavior. Case is ignored by the affs in filename matching, but Linux shells do care about the case. Example (with /wb being an affs mounted fs): diff --git a/Documentation/filesystems/f2fs.txt b/Documentation/filesystems/f2fs.txt index b8d284975f0f..25311e113e75 100644 --- a/Documentation/filesystems/f2fs.txt +++ b/Documentation/filesystems/f2fs.txt @@ -122,6 +122,10 @@ disable_ext_identify Disable the extension list configured by mkfs, so f2fs inline_xattr Enable the inline xattrs feature. inline_data Enable the inline data feature: New created small(<~3.4k) files can be written into inode block. +flush_merge Merge concurrent cache_flush commands as much as possible + to eliminate redundant command issues. If the underlying + device handles the cache_flush command relatively slowly, + recommend to enable this option. ================================================================================ DEBUGFS ENTRIES @@ -169,9 +173,11 @@ Files in /sys/fs/f2fs/<devname> reclaim_segments This parameter controls the number of prefree segments to be reclaimed. If the number of prefree - segments is larger than this number, f2fs tries to - conduct checkpoint to reclaim the prefree segments - to free segments. By default, 100 segments, 200MB. + segments is larger than the number of segments + in the proportion to the percentage over total + volume size, f2fs tries to conduct checkpoint to + reclaim the prefree segments to free segments. + By default, 5% over total # of segments. max_small_discards This parameter controls the number of discard commands that consist small blocks less than 2MB. @@ -195,6 +201,17 @@ Files in /sys/fs/f2fs/<devname> cleaning operations. The default value is 4096 which covers 8GB block address range. + dir_level This parameter controls the directory level to + support large directory. If a directory has a + number of files, it can reduce the file lookup + latency by increasing this dir_level value. + Otherwise, it needs to decrease this value to + reduce the space overhead. The default value is 0. + + ram_thresh This parameter controls the memory footprint used + by free nids and cached nat entries. By default, + 10 is set, which indicates 10 MB / 1 GB RAM. + ================================================================================ USAGE ================================================================================ @@ -444,9 +461,11 @@ The number of blocks and buckets are determined by, # of blocks in level #n = | `- 4, Otherwise - ,- 2^n, if n < MAX_DIR_HASH_DEPTH / 2, + ,- 2^ (n + dir_level), + | if n < MAX_DIR_HASH_DEPTH / 2, # of buckets in level #n = | - `- 2^((MAX_DIR_HASH_DEPTH / 2) - 1), Otherwise + `- 2^((MAX_DIR_HASH_DEPTH / 2 + dir_level) - 1), + Otherwise When F2FS finds a file name in a directory, at first a hash value of the file name is calculated. Then, F2FS scans the hash table in level #0 to find the diff --git a/Documentation/filesystems/nilfs2.txt b/Documentation/filesystems/nilfs2.txt index 06887d46ccf2..41c3d332acc9 100644 --- a/Documentation/filesystems/nilfs2.txt +++ b/Documentation/filesystems/nilfs2.txt @@ -25,9 +25,8 @@ available from the following download page. At least "mkfs.nilfs2", cleaner or garbage collector) are required. Details on the tools are described in the man pages included in the package. -Project web page: http://www.nilfs.org/en/ -Download page: http://www.nilfs.org/en/download.html -Git tree web page: http://www.nilfs.org/git/ +Project web page: http://nilfs.sourceforge.net/ +Download page: http://nilfs.sourceforge.net/en/download.html List info: http://vger.kernel.org/vger-lists.html#linux-nilfs Caveats @@ -111,6 +110,13 @@ Table of NILFS2 specific ioctls nilfs_resize utilities and by nilfs_cleanerd daemon. + NILFS_IOCTL_SET_SUINFO Modify segment usage info of requested + segments. This ioctl is used by + nilfs_cleanerd daemon to skip unnecessary + cleaning operation of segments and reduce + performance penalty or wear of flash device + due to redundant move of in-use blocks. + NILFS_IOCTL_GET_SUSTAT Return segment usage statistics. This ioctl is used in lssu, nilfs_resize utilities and by nilfs_cleanerd daemon. diff --git a/Documentation/filesystems/ntfs.txt b/Documentation/filesystems/ntfs.txt index 791af8dac065..61947facfc07 100644 --- a/Documentation/filesystems/ntfs.txt +++ b/Documentation/filesystems/ntfs.txt @@ -455,8 +455,6 @@ not have this problem with odd numbers of sectors. ChangeLog ========= -Note, a technical ChangeLog aimed at kernel hackers is in fs/ntfs/ChangeLog. - 2.1.30: - Fix writev() (it kept writing the first segment over and over again instead of moving onto subsequent segments). diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting index fe2b7ae6f962..0f3a1390bf00 100644 --- a/Documentation/filesystems/porting +++ b/Documentation/filesystems/porting @@ -295,9 +295,9 @@ in the beginning of ->setattr unconditionally. ->clear_inode() and ->delete_inode() are gone; ->evict_inode() should be used instead. It gets called whenever the inode is evicted, whether it has remaining links or not. Caller does *not* evict the pagecache or inode-associated -metadata buffers; getting rid of those is responsibility of method, as it had -been for ->delete_inode(). Caller makes sure async writeback cannot be running -for the inode while (or after) ->evict_inode() is called. +metadata buffers; the method has to use truncate_inode_pages_final() to get rid +of those. Caller makes sure async writeback cannot be running for the inode while +(or after) ->evict_inode() is called. ->drop_inode() returns int now; it's called on final iput() with inode->i_lock held and it returns true if filesystems wants the inode to be diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index f00bee144add..8b9cd8eb3f91 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -1648,18 +1648,21 @@ pids, so one need to either stop or freeze processes being inspected if precise results are needed. -3.7 /proc/<pid>/fdinfo/<fd> - Information about opened file +3.8 /proc/<pid>/fdinfo/<fd> - Information about opened file --------------------------------------------------------------- This file provides information associated with an opened file. The regular -files have at least two fields -- 'pos' and 'flags'. The 'pos' represents -the current offset of the opened file in decimal form [see lseek(2) for -details] and 'flags' denotes the octal O_xxx mask the file has been -created with [see open(2) for details]. +files have at least three fields -- 'pos', 'flags' and mnt_id. The 'pos' +represents the current offset of the opened file in decimal form [see lseek(2) +for details], 'flags' denotes the octal O_xxx mask the file has been +created with [see open(2) for details] and 'mnt_id' represents mount ID of +the file system containing the opened file [see 3.5 /proc/<pid>/mountinfo +for details]. A typical output is pos: 0 flags: 0100002 + mnt_id: 19 The files such as eventfd, fsnotify, signalfd, epoll among the regular pos/flags pair provide additional information particular to the objects they represent. @@ -1668,6 +1671,7 @@ pair provide additional information particular to the objects they represent. ~~~~~~~~~~~~~ pos: 0 flags: 04002 + mnt_id: 9 eventfd-count: 5a where 'eventfd-count' is hex value of a counter. @@ -1676,6 +1680,7 @@ pair provide additional information particular to the objects they represent. ~~~~~~~~~~~~~~ pos: 0 flags: 04002 + mnt_id: 9 sigmask: 0000000000000200 where 'sigmask' is hex value of the signal mask associated @@ -1685,6 +1690,7 @@ pair provide additional information particular to the objects they represent. ~~~~~~~~~~~ pos: 0 flags: 02 + mnt_id: 9 tfd: 5 events: 1d data: ffffffffffffffff where 'tfd' is a target file descriptor number in decimal form, @@ -1718,6 +1724,7 @@ pair provide additional information particular to the objects they represent. pos: 0 flags: 02 + mnt_id: 9 fanotify flags:10 event-flags:0 fanotify mnt_id:12 mflags:40 mask:38 ignored_mask:40000003 fanotify ino:4f969 sdev:800013 mflags:0 mask:3b ignored_mask:40000000 fhandle-bytes:8 fhandle-type:1 f_handle:69f90400c275b5b4 diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index c53784c119c8..617f6d70c077 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt @@ -347,6 +347,8 @@ struct inode_operations { int (*mknod) (struct inode *,struct dentry *,umode_t,dev_t); int (*rename) (struct inode *, struct dentry *, struct inode *, struct dentry *); + int (*rename2) (struct inode *, struct dentry *, + struct inode *, struct dentry *, unsigned int); int (*readlink) (struct dentry *, char __user *,int); void * (*follow_link) (struct dentry *, struct nameidata *); void (*put_link) (struct dentry *, struct nameidata *, void *); @@ -414,6 +416,20 @@ otherwise noted. rename: called by the rename(2) system call to rename the object to have the parent and name given by the second inode and dentry. + rename2: this has an additional flags argument compared to rename. + If no flags are supported by the filesystem then this method + need not be implemented. If some flags are supported then the + filesystem must return -EINVAL for any unsupported or unknown + flags. Currently the following flags are implemented: + (1) RENAME_NOREPLACE: this flag indicates that if the target + of the rename exists the rename should fail with -EEXIST + instead of replacing the target. The VFS already checks for + existence, so for local filesystems the RENAME_NOREPLACE + implementation is equivalent to plain rename. + (2) RENAME_EXCHANGE: exchange source and target. Both must + exist; this is checked by the VFS. Unlike plain rename, + source and target may be of different type. + readlink: called by the readlink(2) system call. Only required if you want to support reading symbolic links @@ -580,7 +596,7 @@ struct address_space_operations { /* migrate the contents of a page to the specified target */ int (*migratepage) (struct page *, struct page *); int (*launder_page) (struct page *); - int (*is_partially_uptodate) (struct page *, read_descriptor_t *, + int (*is_partially_uptodate) (struct page *, unsigned long, unsigned long); void (*is_dirty_writeback) (struct page *, bool *, bool *); int (*error_remove_page) (struct mapping *mapping, struct page *page); diff --git a/Documentation/gpio/consumer.txt b/Documentation/gpio/consumer.txt index e42f77d8d4ca..09854fe59307 100644 --- a/Documentation/gpio/consumer.txt +++ b/Documentation/gpio/consumer.txt @@ -154,6 +154,7 @@ raw line value: void gpiod_set_raw_value(struct gpio_desc *desc, int value) int gpiod_get_raw_value_cansleep(const struct gpio_desc *desc) void gpiod_set_raw_value_cansleep(struct gpio_desc *desc, int value) + int gpiod_direction_output_raw(struct gpio_desc *desc, int value) The active-low state of a GPIO can also be queried using the following call: diff --git a/Documentation/gpio/driver.txt b/Documentation/gpio/driver.txt index 9da0bfa74781..f73cc7b5dc85 100644 --- a/Documentation/gpio/driver.txt +++ b/Documentation/gpio/driver.txt @@ -62,6 +62,37 @@ Any debugfs dump method should normally ignore signals which haven't been requested as GPIOs. They can use gpiochip_is_requested(), which returns either NULL or the label associated with that GPIO when it was requested. + +GPIO drivers providing IRQs +--------------------------- +It is custom that GPIO drivers (GPIO chips) are also providing interrupts, +most often cascaded off a parent interrupt controller, and in some special +cases the GPIO logic is melded with a SoC's primary interrupt controller. + +The IRQ portions of the GPIO block are implemented using an irqchip, using +the header <linux/irq.h>. So basically such a driver is utilizing two sub- +systems simultaneously: gpio and irq. + +It is legal for any IRQ consumer to request an IRQ from any irqchip no matter +if that is a combined GPIO+IRQ driver. The basic premise is that gpio_chip and +irq_chip are orthogonal, and offering their services independent of each +other. + +gpiod_to_irq() is just a convenience function to figure out the IRQ for a +certain GPIO line and should not be relied upon to have been called before +the IRQ is used. + +So always prepare the hardware and make it ready for action in respective +callbacks from the GPIO and irqchip APIs. Do not rely on gpiod_to_irq() having +been called first. + +This orthogonality leads to ambiguities that we need to solve: if there is +competition inside the subsystem which side is using the resource (a certain +GPIO line and register for example) it needs to deny certain operations and +keep track of usage inside of the gpiolib subsystem. This is why the API +below exists. + + Locking IRQ usage ----------------- Input GPIOs can be used as IRQ signals. When this happens, a driver is requested @@ -73,3 +104,7 @@ This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock is released: void gpiod_unlock_as_irq(struct gpio_desc *desc) + +When implementing an irqchip inside a GPIO driver, these two functions should +typically be called in the .startup() and .shutdown() callbacks from the +irqchip. diff --git a/Documentation/hwmon/it87 b/Documentation/hwmon/it87 index 0c1635082c99..fe80e9adebfa 100644 --- a/Documentation/hwmon/it87 +++ b/Documentation/hwmon/it87 @@ -2,7 +2,7 @@ Kernel driver it87 ================== Supported chips: - * IT8603E + * IT8603E/IT8623E Prefix: 'it8603' Addresses scanned: from Super I/O config space (8 I/O ports) Datasheet: Not publicly available @@ -94,9 +94,9 @@ motherboard models. Description ----------- -This driver implements support for the IT8603E, IT8705F, IT8712F, IT8716F, -IT8718F, IT8720F, IT8721F, IT8726F, IT8728F, IT8758E, IT8771E, IT8772E, -IT8782F, IT8783E/F, and SiS950 chips. +This driver implements support for the IT8603E, IT8623E, IT8705F, IT8712F, +IT8716F, IT8718F, IT8720F, IT8721F, IT8726F, IT8728F, IT8758E, IT8771E, +IT8772E, IT8782F, IT8783E/F, and SiS950 chips. These chips are 'Super I/O chips', supporting floppy disks, infrared ports, joysticks and other miscellaneous stuff. For hardware monitoring, they @@ -133,7 +133,7 @@ to userspace applications. The IT8728F, IT8771E, and IT8772E are considered compatible with the IT8721F, until a datasheet becomes available (hopefully.) -The IT8603E is a custom design, hardware monitoring part is similar to +The IT8603E/IT8623E is a custom design, hardware monitoring part is similar to IT8728F. It only supports 16-bit fan mode, the full speed mode of the fan is not supported (value 0 of pwmX_enable). diff --git a/Documentation/hwmon/k10temp b/Documentation/hwmon/k10temp index 4dfdc8f83633..ee6d30ec1522 100644 --- a/Documentation/hwmon/k10temp +++ b/Documentation/hwmon/k10temp @@ -11,8 +11,8 @@ Supported chips: Socket S1G2: Athlon (X2), Sempron (X2), Turion X2 (Ultra) * AMD Family 12h processors: "Llano" (E2/A4/A6/A8-Series) * AMD Family 14h processors: "Brazos" (C/E/G/Z-Series) -* AMD Family 15h processors: "Bulldozer" (FX-Series), "Trinity" -* AMD Family 16h processors: "Kabini" +* AMD Family 15h processors: "Bulldozer" (FX-Series), "Trinity", "Kaveri" +* AMD Family 16h processors: "Kabini", "Mullins" Prefix: 'k10temp' Addresses scanned: PCI space @@ -46,7 +46,7 @@ Description ----------- This driver permits reading of the internal temperature sensor of AMD -Family 10h/11h/12h/14h/15h processors. +Family 10h/11h/12h/14h/15h/16h processors. All these processors have a sensor, but on those for Socket F or AM2+, the sensor may return inconsistent values (erratum 319). The driver diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801 index aaaf069306a3..adf5e33e8312 100644 --- a/Documentation/i2c/busses/i2c-i801 +++ b/Documentation/i2c/busses/i2c-i801 @@ -26,6 +26,7 @@ Supported adapters: * Intel Wellsburg (PCH) * Intel Coleto Creek (PCH) * Intel Wildcat Point-LP (PCH) + * Intel BayTrail (SOC) Datasheets: Publicly available at the Intel website On Intel Patsburg and later chipsets, both the normal host SMBus controller diff --git a/Documentation/i2c/functionality b/Documentation/i2c/functionality index b0ff2ab596ce..4556a3eb87c4 100644 --- a/Documentation/i2c/functionality +++ b/Documentation/i2c/functionality @@ -46,7 +46,7 @@ A few combinations of the above flags are also defined for your convenience: and write_block_data commands I2C_FUNC_SMBUS_I2C_BLOCK Handles the SMBus read_i2c_block_data and write_i2c_block_data commands - I2C_FUNC_SMBUS_EMUL Handles all SMBus commands than can be + I2C_FUNC_SMBUS_EMUL Handles all SMBus commands that can be emulated by a real I2C adapter (using the transparent emulation layer) diff --git a/Documentation/i2c/i2c-protocol b/Documentation/i2c/i2c-protocol index 0b3e62d1f77a..ff6d6cee6c7e 100644 --- a/Documentation/i2c/i2c-protocol +++ b/Documentation/i2c/i2c-protocol @@ -6,8 +6,8 @@ Key to symbols S (1 bit) : Start bit P (1 bit) : Stop bit Rd/Wr (1 bit) : Read/Write bit. Rd equals 1, Wr equals 0. -A, NA (1 bit) : Accept and reverse accept bit. -Addr (7 bits): I2C 7 bit address. Note that this can be expanded as usual to +A, NA (1 bit) : Accept and reverse accept bit. +Addr (7 bits): I2C 7 bit address. Note that this can be expanded as usual to get a 10 bit I2C address. Comm (8 bits): Command byte, a data byte which often selects a register on the device. @@ -49,11 +49,20 @@ a byte read, followed by a byte write: Modified transactions ===================== -The following modifications to the I2C protocol can also be generated, -with the exception of I2C_M_NOSTART these are usually only needed to -work around device issues: +The following modifications to the I2C protocol can also be generated by +setting these flags for i2c messages. With the exception of I2C_M_NOSTART, they +are usually only needed to work around device issues: - Flag I2C_M_NOSTART: +I2C_M_IGNORE_NAK: + Normally message is interrupted immediately if there is [NA] from the + client. Setting this flag treats any [NA] as [A], and all of + message is sent. + These messages may still fail to SCL lo->hi timeout. + +I2C_M_NO_RD_ACK: + In a read message, master A/NA bit is skipped. + +I2C_M_NOSTART: In a combined transaction, no 'S Addr Wr/Rd [A]' is generated at some point. For example, setting I2C_M_NOSTART on the second partial message generates something like: @@ -67,17 +76,13 @@ work around device issues: I2C device but may also be used between direction changes by some rare devices. - Flags I2C_M_REV_DIR_ADDR +I2C_M_REV_DIR_ADDR: This toggles the Rd/Wr flag. That is, if you want to do a write, but need to emit an Rd instead of a Wr, or vice versa, you set this flag. For example: S Addr Rd [A] Data [A] Data [A] ... [A] Data [A] P - Flags I2C_M_IGNORE_NAK - Normally message is interrupted immediately if there is [NA] from the - client. Setting this flag treats any [NA] as [A], and all of - message is sent. - These messages may still fail to SCL lo->hi timeout. - - Flags I2C_M_NO_RD_ACK - In a read message, master A/NA bit is skipped. +I2C_M_STOP: + Force a stop condition (P) after the message. Some I2C related protocols + like SCCB require that. Normally, you really don't want to get interrupted + between the messages of one transfer. diff --git a/Documentation/irqflags-tracing.txt b/Documentation/irqflags-tracing.txt index 67aa71e73035..f6da05670e16 100644 --- a/Documentation/irqflags-tracing.txt +++ b/Documentation/irqflags-tracing.txt @@ -22,13 +22,6 @@ rather straightforward and risk-free manner. Architectures that want to support this need to do a couple of code-organizational changes first: -- move their irq-flags manipulation code from their asm/system.h header - to asm/irqflags.h - -- rename local_irq_disable()/etc to raw_local_irq_disable()/etc. so that - the linux/irqflags.h code can inject callbacks and can construct the - real local_irq_disable()/etc APIs. - - add and enable TRACE_IRQFLAGS_SUPPORT in their arch level Kconfig file and then a couple of functional changes are needed as well to implement diff --git a/Documentation/ja_JP/HOWTO b/Documentation/ja_JP/HOWTO index 0091a8215ac1..b61885c35ce1 100644 --- a/Documentation/ja_JP/HOWTO +++ b/Documentation/ja_JP/HOWTO @@ -315,7 +315,7 @@ Andrew Morton が Linux-kernel メーリングリストにカーネルリリー もし、3.x.y カーネルが存在しない場合には、番号が一番大きい 3.x が 最新の安定版カーネルです。 -3.x.y は "stable" チーム <stable@kernel.org> でメンテされており、必 +3.x.y は "stable" チーム <stable@vger.kernel.org> でメンテされており、必 要に応じてリリースされます。通常のリリース期間は 2週間毎ですが、差し迫っ た問題がなければもう少し長くなることもあります。セキュリティ関連の問題 の場合はこれに対してだいたいの場合、すぐにリリースがされます。 diff --git a/Documentation/ja_JP/SubmittingPatches b/Documentation/ja_JP/SubmittingPatches index 97f78dd0c085..5d6ae639bfa0 100644 --- a/Documentation/ja_JP/SubmittingPatches +++ b/Documentation/ja_JP/SubmittingPatches @@ -98,11 +98,6 @@ dontdiff ファイルには Linux カーネルのビルドプロセスの過程 Quilt: http://savannah.nongnu.org/projects/quilt -Andrew Morton's patch scripts: -http://userweb.kernel.org/~akpm/stuff/patch-scripts.tar.gz -このリンクの先のスクリプトの代わりとして、quilt がパッチマネジメント -ツールとして推奨されています(上のリンクを見てください)。 - 2) パッチに対する説明 パッチの中の変更点に対する技術的な詳細について説明してください。 @@ -695,7 +690,7 @@ gcc においては、マクロと同じくらい軽いです。 ---------------------- Andrew Morton, "The perfect patch" (tpp). - <http://userweb.kernel.org/~akpm/stuff/tpp.txt> + <http://www.ozlabs.org/~akpm/stuff/tpp.txt> Jeff Garzik, "Linux kernel patch submission format". <http://linux.yyz.us/patch-format.html> @@ -707,7 +702,7 @@ Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer". <http://www.kroah.com/log/2006/01/11/> NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people! - <http://marc.theaimsgroup.com/?l=linux-kernel&m=112112749912944&w=2> + <https://lkml.org/lkml/2005/7/11/336> Kernel Documentation/CodingStyle: <http://users.sosdg.org/~qiyong/lxr/source/Documentation/CodingStyle> diff --git a/Documentation/ja_JP/stable_kernel_rules.txt b/Documentation/ja_JP/stable_kernel_rules.txt index 14265837c4ce..9dbda9b5d21e 100644 --- a/Documentation/ja_JP/stable_kernel_rules.txt +++ b/Documentation/ja_JP/stable_kernel_rules.txt @@ -50,16 +50,16 @@ linux-2.6.29/Documentation/stable_kernel_rules.txt -stable ツリーにパッチを送付する手続き- - - 上記の規則に従っているかを確認した後に、stable@kernel.org にパッチ + - 上記の規則に従っているかを確認した後に、stable@vger.kernel.org にパッチ を送る。 - 送信者はパッチがキューに受け付けられた際には ACK を、却下された場合 には NAK を受け取る。この反応は開発者たちのスケジュールによって、数 日かかる場合がある。 - もし受け取られたら、パッチは他の開発者たちと関連するサブシステムの メンテナーによるレビューのために -stable キューに追加される。 - - パッチに stable@kernel.org のアドレスが付加されているときには、それ + - パッチに stable@vger.kernel.org のアドレスが付加されているときには、それ が Linus のツリーに入る時に自動的に stable チームに email される。 - - セキュリティパッチはこのエイリアス (stable@kernel.org) に送られるべ + - セキュリティパッチはこのエイリアス (stable@vger.kernel.org) に送られるべ きではなく、代わりに security@kernel.org のアドレスに送られる。 レビューサイクル- diff --git a/Documentation/kbuild/kconfig-language.txt b/Documentation/kbuild/kconfig-language.txt index c420676c6fe3..350f733bf2c7 100644 --- a/Documentation/kbuild/kconfig-language.txt +++ b/Documentation/kbuild/kconfig-language.txt @@ -157,6 +157,10 @@ applicable everywhere (see syntax). to the build environment (if this is desired, it can be done via another symbol). + - "allnoconfig_y" + This declares the symbol as one that should have the value y when + using "allnoconfig". Used for symbols that hide other symbols. + Menu dependencies ----------------- diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index bc3478581f67..43842177b771 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -804,13 +804,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted. dhash_entries= [KNL] Set number of hash buckets for dentry cache. - digi= [HW,SERIAL] - IO parameters + enable/disable command. - - digiepca= [HW,SERIAL] - See drivers/char/README.epca and - Documentation/serial/digiepca.txt. - disable= [IPV6] See Documentation/networking/ipv6.txt. @@ -884,6 +877,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. Enable debug messages at boot time. See Documentation/dynamic-debug-howto.txt for details. + early_ioremap_debug [KNL] + Enable debug messages in early_ioremap support. This + is useful for tracking down temporary early mappings + which are not unmapped. + earlycon= [KNL] Output early console device and options. uart[8250],io,<addr>[,options] uart[8250],mmio,<addr>[,options] @@ -2558,6 +2556,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted. pcmv= [HW,PCMCIA] BadgePAD 4 + pd_ignore_unused + [PM] + Keep all power-domains already enabled by bootloader on, + even if no driver has claimed them. This is useful + for debug and development, but should not be + needed on a platform with proper driver support. + pd. [PARIDE] See Documentation/blockdev/paride.txt. @@ -2927,9 +2932,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted. rhash_entries= [KNL,NET] Set number of hash buckets for route cache - riscom8= [HW,SERIAL] - Format: <io_board1>[,<io_board2>[,...<io_boardN>]] - ro [KNL] Mount root device read-only on boot root= [KNL] Root filesystem @@ -3071,9 +3073,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted. sonypi.*= [HW] Sony Programmable I/O Control Device driver See Documentation/laptops/sonypi.txt - specialix= [HW,SERIAL] Specialix multi-serial port adapter - See Documentation/serial/specialix.txt. - spia_io_base= [HW,MTD] spia_fio_base= spia_pedr= diff --git a/Documentation/kmemleak.txt b/Documentation/kmemleak.txt index b6e39739a36d..a7563ec4ea7b 100644 --- a/Documentation/kmemleak.txt +++ b/Documentation/kmemleak.txt @@ -11,9 +11,7 @@ with the difference that the orphan objects are not freed but only reported via /sys/kernel/debug/kmemleak. A similar method is used by the Valgrind tool (memcheck --leak-check) to detect the memory leaks in user-space applications. - -Please check DEBUG_KMEMLEAK dependencies in lib/Kconfig.debug for supported -architectures. +Kmemleak is supported on x86, arm, powerpc, sparc, sh, microblaze, ppc, mips, s390, metag and tile. Usage ----- @@ -53,7 +51,8 @@ Memory scanning parameters can be modified at run-time by writing to the (default 600, 0 to stop the automatic scanning) scan - trigger a memory scan clear - clear list of current memory leak suspects, done by - marking all current reported unreferenced objects grey + marking all current reported unreferenced objects grey, + or free all kmemleak objects if kmemleak has been disabled. dump=<addr> - dump information about the object found at <addr> Kmemleak can also be disabled at boot-time by passing "kmemleak=off" on @@ -68,7 +67,7 @@ Basic Algorithm The memory allocations via kmalloc, vmalloc, kmem_cache_alloc and friends are traced and the pointers, together with additional -information like size and stack trace, are stored in a prio search tree. +information like size and stack trace, are stored in a rbtree. The corresponding freeing function calls are tracked and the pointers removed from the kmemleak data structures. @@ -84,7 +83,7 @@ The scanning algorithm steps: 1. mark all objects as white (remaining white objects will later be considered orphan) 2. scan the memory starting with the data section and stacks, checking - the values against the addresses stored in the prio search tree. If + the values against the addresses stored in the rbtree. If a pointer to a white object is found, the object is added to the gray list 3. scan the gray objects for matching addresses (some white objects @@ -120,6 +119,18 @@ Then as usual to get your report with: # cat /sys/kernel/debug/kmemleak +Freeing kmemleak internal objects +--------------------------------- + +To allow access to previosuly found memory leaks after kmemleak has been +disabled by the user or due to an fatal error, internal kmemleak objects +won't be freed when kmemleak is disabled, and those objects may occupy +a large part of physical memory. + +In this situation, you may reclaim memory with: + + # echo clear > /sys/kernel/debug/kmemleak + Kmemleak API ------------ diff --git a/Documentation/magic-number.txt b/Documentation/magic-number.txt index 76d80a64bbe1..4c8e142db2ef 100644 --- a/Documentation/magic-number.txt +++ b/Documentation/magic-number.txt @@ -63,8 +63,6 @@ Magic Name Number Structure File PG_MAGIC 'P' pg_{read,write}_hdr include/linux/pg.h CMAGIC 0x0111 user include/linux/a.out.h MKISS_DRIVER_MAGIC 0x04bf mkiss_channel drivers/net/mkiss.h -RISCOM8_MAGIC 0x0907 riscom_port drivers/char/riscom8.h -SPECIALIX_MAGIC 0x0907 specialix_port drivers/char/specialix_io8.h HDLC_MAGIC 0x239e n_hdlc drivers/char/n_hdlc.c APM_BIOS_MAGIC 0x4101 apm_user arch/x86/kernel/apm_32.c CYCLADES_MAGIC 0x4359 cyclades_port include/linux/cyclades.h @@ -82,7 +80,6 @@ STRIP_MAGIC 0x5303 strip drivers/net/strip.c X25_ASY_MAGIC 0x5303 x25_asy drivers/net/x25_asy.h SIXPACK_MAGIC 0x5304 sixpack drivers/net/hamradio/6pack.h AX25_MAGIC 0x5316 ax_disp drivers/net/mkiss.h -ESP_MAGIC 0x53ee esp_struct drivers/char/esp.h TTY_MAGIC 0x5401 tty_struct include/linux/tty.h MGSL_MAGIC 0x5401 mgsl_info drivers/char/synclink.c TTY_DRIVER_MAGIC 0x5402 tty_driver include/linux/tty_driver.h @@ -94,13 +91,10 @@ USB_BLUETOOTH_MAGIC 0x6d02 usb_bluetooth drivers/usb/class/bluetty.c RFCOMM_TTY_MAGIC 0x6d02 net/bluetooth/rfcomm/tty.c USB_SERIAL_PORT_MAGIC 0x7301 usb_serial_port drivers/usb/serial/usb-serial.h CG_MAGIC 0x00090255 ufs_cylinder_group include/linux/ufs_fs.h -A2232_MAGIC 0x000a2232 gs_port drivers/char/ser_a2232.h RPORT_MAGIC 0x00525001 r_port drivers/char/rocket_int.h LSEMAGIC 0x05091998 lse drivers/fc4/fc.c GDTIOCTL_MAGIC 0x06030f07 gdth_iowr_str drivers/scsi/gdth_ioctl.h RIEBL_MAGIC 0x09051990 drivers/net/atarilance.c -RIO_MAGIC 0x12345678 gs_port drivers/char/rio/rio_linux.c -SX_MAGIC 0x12345678 gs_port drivers/char/sx.h NBD_REQUEST_MAGIC 0x12560953 nbd_request include/linux/nbd.h RED_MAGIC2 0x170fc2a5 (any) mm/slab.c BAYCOM_MAGIC 0x19730510 baycom_state drivers/net/baycom_epp.c @@ -116,7 +110,6 @@ ISDN_ASYNC_MAGIC 0x49344C01 modem_info include/linux/isdn.h CTC_ASYNC_MAGIC 0x49344C01 ctc_tty_info drivers/s390/net/ctctty.c ISDN_NET_MAGIC 0x49344C02 isdn_net_local_s drivers/isdn/i4l/isdn_net_lib.h SAVEKMSG_MAGIC2 0x4B4D5347 savekmsg arch/*/amiga/config.c -STLI_BOARDMAGIC 0x4bc6c825 stlibrd include/linux/istallion.h CS_STATE_MAGIC 0x4c4f4749 cs_state sound/oss/cs46xx.c SLAB_C_MAGIC 0x4f17a36d kmem_cache mm/slab.c COW_MAGIC 0x4f4f4f4d cow_header_v1 arch/um/drivers/ubd_user.c @@ -127,10 +120,8 @@ SCC_MAGIC 0x52696368 gs_port drivers/char/scc.h SAVEKMSG_MAGIC1 0x53415645 savekmsg arch/*/amiga/config.c GDA_MAGIC 0x58464552 gda arch/mips/include/asm/sn/gda.h RED_MAGIC1 0x5a2cf071 (any) mm/slab.c -STL_PORTMAGIC 0x5a7182c9 stlport include/linux/stallion.h EEPROM_MAGIC_VALUE 0x5ab478d2 lanai_dev drivers/atm/lanai.c HDLCDRV_MAGIC 0x5ac6e778 hdlcdrv_state include/linux/hdlcdrv.h -EPCA_MAGIC 0x5c6df104 channel include/linux/epca.h PCXX_MAGIC 0x5c6df104 channel drivers/char/pcxx.h KV_MAGIC 0x5f4b565f kernel_vars_s arch/mips/include/asm/sn/klkernvars.h I810_STATE_MAGIC 0x63657373 i810_state sound/oss/i810_audio.c @@ -142,17 +133,14 @@ SLOT_MAGIC 0x67267322 slot drivers/hotplug/acpiphp.h LO_MAGIC 0x68797548 nbd_device include/linux/nbd.h OPROFILE_MAGIC 0x6f70726f super_block drivers/oprofile/oprofilefs.h M3_STATE_MAGIC 0x734d724d m3_state sound/oss/maestro3.c -STL_PANELMAGIC 0x7ef621a1 stlpanel include/linux/stallion.h VMALLOC_MAGIC 0x87654320 snd_alloc_track sound/core/memory.c KMALLOC_MAGIC 0x87654321 snd_alloc_track sound/core/memory.c PWC_MAGIC 0x89DC10AB pwc_device drivers/usb/media/pwc.h NBD_REPLY_MAGIC 0x96744668 nbd_reply include/linux/nbd.h -STL_BOARDMAGIC 0xa2267f52 stlbrd include/linux/stallion.h ENI155_MAGIC 0xa54b872d midway_eprom drivers/atm/eni.h SCI_MAGIC 0xbabeface gs_port drivers/char/sh-sci.h CODA_MAGIC 0xC0DAC0DA coda_file_info fs/coda/coda_fs_i.h DPMEM_MAGIC 0xc0ffee11 gdt_pci_sram drivers/scsi/gdth.h -STLI_PORTMAGIC 0xe671c7a1 stliport include/linux/istallion.h YAM_MAGIC 0xF10A7654 yam_port drivers/net/hamradio/yam.c CCB_MAGIC 0xf2691ad2 ccb drivers/scsi/ncr53c8xx.c QUEUE_MAGIC_FREE 0xf7e1c9a3 queue_entry drivers/scsi/arm/queue.c diff --git a/Documentation/module-signing.txt b/Documentation/module-signing.txt index 09b583e38907..09c2382ad055 100644 --- a/Documentation/module-signing.txt +++ b/Documentation/module-signing.txt @@ -53,7 +53,8 @@ This has a number of options available: If this is off (ie. "permissive"), then modules for which the key is not available and modules that are unsigned are permitted, but the kernel will - be marked as being tainted. + be marked as being tainted, and the concerned modules will be marked as + tainted, shown with the character 'E'. If this is on (ie. "restrictive"), only modules that have a valid signature that can be verified by a public key in the kernel's possession diff --git a/Documentation/networking/altera_tse.txt b/Documentation/networking/altera_tse.txt new file mode 100644 index 000000000000..3f24df8c6e65 --- /dev/null +++ b/Documentation/networking/altera_tse.txt @@ -0,0 +1,263 @@ + Altera Triple-Speed Ethernet MAC driver + +Copyright (C) 2008-2014 Altera Corporation + +This is the driver for the Altera Triple-Speed Ethernet (TSE) controllers +using the SGDMA and MSGDMA soft DMA IP components. The driver uses the +platform bus to obtain component resources. The designs used to test this +driver were built for a Cyclone(R) V SOC FPGA board, a Cyclone(R) V FPGA board, +and tested with ARM and NIOS processor hosts seperately. The anticipated use +cases are simple communications between an embedded system and an external peer +for status and simple configuration of the embedded system. + +For more information visit www.altera.com and www.rocketboards.org. Support +forums for the driver may be found on www.rocketboards.org, and a design used +to test this driver may be found there as well. Support is also available from +the maintainer of this driver, found in MAINTAINERS. + +The Triple-Speed Ethernet, SGDMA, and MSGDMA components are all soft IP +components that can be assembled and built into an FPGA using the Altera +Quartus toolchain. Quartus 13.1 and 14.0 were used to build the design that +this driver was tested against. The sopc2dts tool is used to create the +device tree for the driver, and may be found at rocketboards.org. + +The driver probe function examines the device tree and determines if the +Triple-Speed Ethernet instance is using an SGDMA or MSGDMA component. The +probe function then installs the appropriate set of DMA routines to +initialize, setup transmits, receives, and interrupt handling primitives for +the respective configurations. + +The SGDMA component is to be deprecated in the near future (over the next 1-2 +years as of this writing in early 2014) in favor of the MSGDMA component. +SGDMA support is included for existing designs and reference in case a +developer wishes to support their own soft DMA logic and driver support. Any +new designs should not use the SGDMA. + +The SGDMA supports only a single transmit or receive operation at a time, and +therefore will not perform as well compared to the MSGDMA soft IP. Please +visit www.altera.com for known, documented SGDMA errata. + +Scatter-gather DMA is not supported by the SGDMA or MSGDMA at this time. +Scatter-gather DMA will be added to a future maintenance update to this +driver. + +Jumbo frames are not supported at this time. + +The driver limits PHY operations to 10/100Mbps, and has not yet been fully +tested for 1Gbps. This support will be added in a future maintenance update. + +1) Kernel Configuration +The kernel configuration option is ALTERA_TSE: + Device Drivers ---> Network device support ---> Ethernet driver support ---> + Altera Triple-Speed Ethernet MAC support (ALTERA_TSE) + +2) Driver parameters list: + debug: message level (0: no output, 16: all); + dma_rx_num: Number of descriptors in the RX list (default is 64); + dma_tx_num: Number of descriptors in the TX list (default is 64). + +3) Command line options +Driver parameters can be also passed in command line by using: + altera_tse=dma_rx_num:128,dma_tx_num:512 + +4) Driver information and notes + +4.1) Transmit process +When the driver's transmit routine is called by the kernel, it sets up a +transmit descriptor by calling the underlying DMA transmit routine (SGDMA or +MSGDMA), and initites a transmit operation. Once the transmit is complete, an +interrupt is driven by the transmit DMA logic. The driver handles the transmit +completion in the context of the interrupt handling chain by recycling +resource required to send and track the requested transmit operation. + +4.2) Receive process +The driver will post receive buffers to the receive DMA logic during driver +intialization. Receive buffers may or may not be queued depending upon the +underlying DMA logic (MSGDMA is able queue receive buffers, SGDMA is not able +to queue receive buffers to the SGDMA receive logic). When a packet is +received, the DMA logic generates an interrupt. The driver handles a receive +interrupt by obtaining the DMA receive logic status, reaping receive +completions until no more receive completions are available. + +4.3) Interrupt Mitigation +The driver is able to mitigate the number of its DMA interrupts +using NAPI for receive operations. Interrupt mitigation is not yet supported +for transmit operations, but will be added in a future maintenance release. + +4.4) Ethtool support +Ethtool is supported. Driver statistics and internal errors can be taken using: +ethtool -S ethX command. It is possible to dump registers etc. + +4.5) PHY Support +The driver is compatible with PAL to work with PHY and GPHY devices. + +4.7) List of source files: + o Kconfig + o Makefile + o altera_tse_main.c: main network device driver + o altera_tse_ethtool.c: ethtool support + o altera_tse.h: private driver structure and common definitions + o altera_msgdma.h: MSGDMA implementation function definitions + o altera_sgdma.h: SGDMA implementation function definitions + o altera_msgdma.c: MSGDMA implementation + o altera_sgdma.c: SGDMA implementation + o altera_sgdmahw.h: SGDMA register and descriptor definitions + o altera_msgdmahw.h: MSGDMA register and descriptor definitions + o altera_utils.c: Driver utility functions + o altera_utils.h: Driver utility function definitions + +5) Debug Information + +The driver exports debug information such as internal statistics, +debug information, MAC and DMA registers etc. + +A user may use the ethtool support to get statistics: +e.g. using: ethtool -S ethX (that shows the statistics counters) +or sees the MAC registers: e.g. using: ethtool -d ethX + +The developer can also use the "debug" module parameter to get +further debug information. + +6) Statistics Support + +The controller and driver support a mix of IEEE standard defined statistics, +RFC defined statistics, and driver or Altera defined statistics. The four +specifications containing the standard definitions for these statistics are +as follows: + + o IEEE 802.3-2012 - IEEE Standard for Ethernet. + o RFC 2863 found at http://www.rfc-editor.org/rfc/rfc2863.txt. + o RFC 2819 found at http://www.rfc-editor.org/rfc/rfc2819.txt. + o Altera Triple Speed Ethernet User Guide, found at http://www.altera.com + +The statistics supported by the TSE and the device driver are as follows: + +"tx_packets" is equivalent to aFramesTransmittedOK defined in IEEE 802.3-2012, +Section 5.2.2.1.2. This statistics is the count of frames that are successfully +transmitted. + +"rx_packets" is equivalent to aFramesReceivedOK defined in IEEE 802.3-2012, +Section 5.2.2.1.5. This statistic is the count of frames that are successfully +received. This count does not include any error packets such as CRC errors, +length errors, or alignment errors. + +"rx_crc_errors" is equivalent to aFrameCheckSequenceErrors defined in IEEE +802.3-2012, Section 5.2.2.1.6. This statistic is the count of frames that are +an integral number of bytes in length and do not pass the CRC test as the frame +is received. + +"rx_align_errors" is equivalent to aAlignmentErrors defined in IEEE 802.3-2012, +Section 5.2.2.1.7. This statistic is the count of frames that are not an +integral number of bytes in length and do not pass the CRC test as the frame is +received. + +"tx_bytes" is equivalent to aOctetsTransmittedOK defined in IEEE 802.3-2012, +Section 5.2.2.1.8. This statistic is the count of data and pad bytes +successfully transmitted from the interface. + +"rx_bytes" is equivalent to aOctetsReceivedOK defined in IEEE 802.3-2012, +Section 5.2.2.1.14. This statistic is the count of data and pad bytes +successfully received by the controller. + +"tx_pause" is equivalent to aPAUSEMACCtrlFramesTransmitted defined in IEEE +802.3-2012, Section 30.3.4.2. This statistic is a count of PAUSE frames +transmitted from the network controller. + +"rx_pause" is equivalent to aPAUSEMACCtrlFramesReceived defined in IEEE +802.3-2012, Section 30.3.4.3. This statistic is a count of PAUSE frames +received by the network controller. + +"rx_errors" is equivalent to ifInErrors defined in RFC 2863. This statistic is +a count of the number of packets received containing errors that prevented the +packet from being delivered to a higher level protocol. + +"tx_errors" is equivalent to ifOutErrors defined in RFC 2863. This statistic +is a count of the number of packets that could not be transmitted due to errors. + +"rx_unicast" is equivalent to ifInUcastPkts defined in RFC 2863. This +statistic is a count of the number of packets received that were not addressed +to the broadcast address or a multicast group. + +"rx_multicast" is equivalent to ifInMulticastPkts defined in RFC 2863. This +statistic is a count of the number of packets received that were addressed to +a multicast address group. + +"rx_broadcast" is equivalent to ifInBroadcastPkts defined in RFC 2863. This +statistic is a count of the number of packets received that were addressed to +the broadcast address. + +"tx_discards" is equivalent to ifOutDiscards defined in RFC 2863. This +statistic is the number of outbound packets not transmitted even though an +error was not detected. An example of a reason this might occur is to free up +internal buffer space. + +"tx_unicast" is equivalent to ifOutUcastPkts defined in RFC 2863. This +statistic counts the number of packets transmitted that were not addressed to +a multicast group or broadcast address. + +"tx_multicast" is equivalent to ifOutMulticastPkts defined in RFC 2863. This +statistic counts the number of packets transmitted that were addressed to a +multicast group. + +"tx_broadcast" is equivalent to ifOutBroadcastPkts defined in RFC 2863. This +statistic counts the number of packets transmitted that were addressed to a +broadcast address. + +"ether_drops" is equivalent to etherStatsDropEvents defined in RFC 2819. +This statistic counts the number of packets dropped due to lack of internal +controller resources. + +"rx_total_bytes" is equivalent to etherStatsOctets defined in RFC 2819. +This statistic counts the total number of bytes received by the controller, +including error and discarded packets. + +"rx_total_packets" is equivalent to etherStatsPkts defined in RFC 2819. +This statistic counts the total number of packets received by the controller, +including error, discarded, unicast, multicast, and broadcast packets. + +"rx_undersize" is equivalent to etherStatsUndersizePkts defined in RFC 2819. +This statistic counts the number of correctly formed packets received less +than 64 bytes long. + +"rx_oversize" is equivalent to etherStatsOversizePkts defined in RFC 2819. +This statistic counts the number of correctly formed packets greater than 1518 +bytes long. + +"rx_64_bytes" is equivalent to etherStatsPkts64Octets defined in RFC 2819. +This statistic counts the total number of packets received that were 64 octets +in length. + +"rx_65_127_bytes" is equivalent to etherStatsPkts65to127Octets defined in RFC +2819. This statistic counts the total number of packets received that were +between 65 and 127 octets in length inclusive. + +"rx_128_255_bytes" is equivalent to etherStatsPkts128to255Octets defined in +RFC 2819. This statistic is the total number of packets received that were +between 128 and 255 octets in length inclusive. + +"rx_256_511_bytes" is equivalent to etherStatsPkts256to511Octets defined in +RFC 2819. This statistic is the total number of packets received that were +between 256 and 511 octets in length inclusive. + +"rx_512_1023_bytes" is equivalent to etherStatsPkts512to1023Octets defined in +RFC 2819. This statistic is the total number of packets received that were +between 512 and 1023 octets in length inclusive. + +"rx_1024_1518_bytes" is equivalent to etherStatsPkts1024to1518Octets define +in RFC 2819. This statistic is the total number of packets received that were +between 1024 and 1518 octets in length inclusive. + +"rx_gte_1519_bytes" is a statistic defined specific to the behavior of the +Altera TSE. This statistics counts the number of received good and errored +frames between the length of 1519 and the maximum frame length configured +in the frm_length register. See the Altera TSE User Guide for More details. + +"rx_jabbers" is equivalent to etherStatsJabbers defined in RFC 2819. This +statistic is the total number of packets received that were longer than 1518 +octets, and had either a bad CRC with an integral number of octets (CRC Error) +or a bad CRC with a non-integral number of octets (Alignment Error). + +"rx_runts" is equivalent to etherStatsFragments defined in RFC 2819. This +statistic is the total number of packets received that were less than 64 octets +in length and had either a bad CRC with an integral number of octets (CRC +error) or a bad CRC with a non-integral number of octets (Alignment Error). diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt index 5cdb22971d19..a383c00392d0 100644 --- a/Documentation/networking/bonding.txt +++ b/Documentation/networking/bonding.txt @@ -270,16 +270,15 @@ arp_ip_target arp_validate Specifies whether or not ARP probes and replies should be - validated in the active-backup mode. This causes the ARP - monitor to examine the incoming ARP requests and replies, and - only consider a slave to be up if it is receiving the - appropriate ARP traffic. + validated in any mode that supports arp monitoring, or whether + non-ARP traffic should be filtered (disregarded) for link + monitoring purposes. Possible values are: none or 0 - No validation is performed. This is the default. + No validation or filtering is performed. active or 1 @@ -293,31 +292,68 @@ arp_validate Validation is performed for all slaves. - For the active slave, the validation checks ARP replies to - confirm that they were generated by an arp_ip_target. Since - backup slaves do not typically receive these replies, the - validation performed for backup slaves is on the ARP request - sent out via the active slave. It is possible that some - switch or network configurations may result in situations - wherein the backup slaves do not receive the ARP requests; in - such a situation, validation of backup slaves must be - disabled. - - The validation of ARP requests on backup slaves is mainly - helping bonding to decide which slaves are more likely to - work in case of the active slave failure, it doesn't really - guarantee that the backup slave will work if it's selected - as the next active slave. - - This option is useful in network configurations in which - multiple bonding hosts are concurrently issuing ARPs to one or - more targets beyond a common switch. Should the link between - the switch and target fail (but not the switch itself), the - probe traffic generated by the multiple bonding instances will - fool the standard ARP monitor into considering the links as - still up. Use of the arp_validate option can resolve this, as - the ARP monitor will only consider ARP requests and replies - associated with its own instance of bonding. + filter or 4 + + Filtering is applied to all slaves. No validation is + performed. + + filter_active or 5 + + Filtering is applied to all slaves, validation is performed + only for the active slave. + + filter_backup or 6 + + Filtering is applied to all slaves, validation is performed + only for backup slaves. + + Validation: + + Enabling validation causes the ARP monitor to examine the incoming + ARP requests and replies, and only consider a slave to be up if it + is receiving the appropriate ARP traffic. + + For an active slave, the validation checks ARP replies to confirm + that they were generated by an arp_ip_target. Since backup slaves + do not typically receive these replies, the validation performed + for backup slaves is on the broadcast ARP request sent out via the + active slave. It is possible that some switch or network + configurations may result in situations wherein the backup slaves + do not receive the ARP requests; in such a situation, validation + of backup slaves must be disabled. + + The validation of ARP requests on backup slaves is mainly helping + bonding to decide which slaves are more likely to work in case of + the active slave failure, it doesn't really guarantee that the + backup slave will work if it's selected as the next active slave. + + Validation is useful in network configurations in which multiple + bonding hosts are concurrently issuing ARPs to one or more targets + beyond a common switch. Should the link between the switch and + target fail (but not the switch itself), the probe traffic + generated by the multiple bonding instances will fool the standard + ARP monitor into considering the links as still up. Use of + validation can resolve this, as the ARP monitor will only consider + ARP requests and replies associated with its own instance of + bonding. + + Filtering: + + Enabling filtering causes the ARP monitor to only use incoming ARP + packets for link availability purposes. Arriving packets that are + not ARPs are delivered normally, but do not count when determining + if a slave is available. + + Filtering operates by only considering the reception of ARP + packets (any ARP packet, regardless of source or destination) when + determining if a slave has received traffic for link availability + purposes. + + Filtering is useful in network configurations in which significant + levels of third party broadcast traffic would fool the standard + ARP monitor into considering the links as still up. Use of + filtering can resolve this, as only ARP traffic is considered for + link availability purposes. This option was added in bonding version 3.1.0. diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt index 0cbe6ec22d6f..2fa44cbe81b7 100644 --- a/Documentation/networking/can.txt +++ b/Documentation/networking/can.txt @@ -1017,7 +1017,7 @@ solution for a couple of reasons: in case of a bus-off condition after the specified delay time in milliseconds. By default it's off. - "bitrate 125000 sample_point 0.875" + "bitrate 125000 sample-point 0.875" Shows the real bit-rate in bits/sec and the sample-point in the range 0.000..0.999. If the calculation of bit-timing parameters is enabled in the kernel (CONFIG_CAN_CALC_BITTIMING=y), the diff --git a/Documentation/networking/filter.txt b/Documentation/networking/filter.txt index a06b48d2f5cc..81f940f4e884 100644 --- a/Documentation/networking/filter.txt +++ b/Documentation/networking/filter.txt @@ -546,6 +546,130 @@ ffffffffa0069c8f + <x>: For BPF JIT developers, bpf_jit_disasm, bpf_asm and bpf_dbg provides a useful toolchain for developing and testing the kernel's JIT compiler. +BPF kernel internals +-------------------- +Internally, for the kernel interpreter, a different BPF instruction set +format with similar underlying principles from BPF described in previous +paragraphs is being used. However, the instruction set format is modelled +closer to the underlying architecture to mimic native instruction sets, so +that a better performance can be achieved (more details later). + +It is designed to be JITed with one to one mapping, which can also open up +the possibility for GCC/LLVM compilers to generate optimized BPF code through +a BPF backend that performs almost as fast as natively compiled code. + +The new instruction set was originally designed with the possible goal in +mind to write programs in "restricted C" and compile into BPF with a optional +GCC/LLVM backend, so that it can just-in-time map to modern 64-bit CPUs with +minimal performance overhead over two steps, that is, C -> BPF -> native code. + +Currently, the new format is being used for running user BPF programs, which +includes seccomp BPF, classic socket filters, cls_bpf traffic classifier, +team driver's classifier for its load-balancing mode, netfilter's xt_bpf +extension, PTP dissector/classifier, and much more. They are all internally +converted by the kernel into the new instruction set representation and run +in the extended interpreter. For in-kernel handlers, this all works +transparently by using sk_unattached_filter_create() for setting up the +filter, resp. sk_unattached_filter_destroy() for destroying it. The macro +SK_RUN_FILTER(filter, ctx) transparently invokes the right BPF function to +run the filter. 'filter' is a pointer to struct sk_filter that we got from +sk_unattached_filter_create(), and 'ctx' the given context (e.g. skb pointer). +All constraints and restrictions from sk_chk_filter() apply before a +conversion to the new layout is being done behind the scenes! + +Currently, for JITing, the user BPF format is being used and current BPF JIT +compilers reused whenever possible. In other words, we do not (yet!) perform +a JIT compilation in the new layout, however, future work will successively +migrate traditional JIT compilers into the new instruction format as well, so +that they will profit from the very same benefits. Thus, when speaking about +JIT in the following, a JIT compiler (TBD) for the new instruction format is +meant in this context. + +Some core changes of the new internal format: + +- Number of registers increase from 2 to 10: + + The old format had two registers A and X, and a hidden frame pointer. The + new layout extends this to be 10 internal registers and a read-only frame + pointer. Since 64-bit CPUs are passing arguments to functions via registers + the number of args from BPF program to in-kernel function is restricted + to 5 and one register is used to accept return value from an in-kernel + function. Natively, x86_64 passes first 6 arguments in registers, aarch64/ + sparcv9/mips64 have 7 - 8 registers for arguments; x86_64 has 6 callee saved + registers, and aarch64/sparcv9/mips64 have 11 or more callee saved registers. + + Therefore, BPF calling convention is defined as: + + * R0 - return value from in-kernel function + * R1 - R5 - arguments from BPF program to in-kernel function + * R6 - R9 - callee saved registers that in-kernel function will preserve + * R10 - read-only frame pointer to access stack + + Thus, all BPF registers map one to one to HW registers on x86_64, aarch64, + etc, and BPF calling convention maps directly to ABIs used by the kernel on + 64-bit architectures. + + On 32-bit architectures JIT may map programs that use only 32-bit arithmetic + and may let more complex programs to be interpreted. + + R0 - R5 are scratch registers and BPF program needs spill/fill them if + necessary across calls. Note that there is only one BPF program (== one BPF + main routine) and it cannot call other BPF functions, it can only call + predefined in-kernel functions, though. + +- Register width increases from 32-bit to 64-bit: + + Still, the semantics of the original 32-bit ALU operations are preserved + via 32-bit subregisters. All BPF registers are 64-bit with 32-bit lower + subregisters that zero-extend into 64-bit if they are being written to. + That behavior maps directly to x86_64 and arm64 subregister definition, but + makes other JITs more difficult. + + 32-bit architectures run 64-bit internal BPF programs via interpreter. + Their JITs may convert BPF programs that only use 32-bit subregisters into + native instruction set and let the rest being interpreted. + + Operation is 64-bit, because on 64-bit architectures, pointers are also + 64-bit wide, and we want to pass 64-bit values in/out of kernel functions, + so 32-bit BPF registers would otherwise require to define register-pair + ABI, thus, there won't be able to use a direct BPF register to HW register + mapping and JIT would need to do combine/split/move operations for every + register in and out of the function, which is complex, bug prone and slow. + Another reason is the use of atomic 64-bit counters. + +- Conditional jt/jf targets replaced with jt/fall-through: + + While the original design has constructs such as "if (cond) jump_true; + else jump_false;", they are being replaced into alternative constructs like + "if (cond) jump_true; /* else fall-through */". + +- Introduces bpf_call insn and register passing convention for zero overhead + calls from/to other kernel functions: + + After a kernel function call, R1 - R5 are reset to unreadable and R0 has a + return type of the function. Since R6 - R9 are callee saved, their state is + preserved across the call. + +Also in the new design, BPF is limited to 4096 insns, which means that any +program will terminate quickly and will only call a fixed number of kernel +functions. Original BPF and the new format are two operand instructions, +which helps to do one-to-one mapping between BPF insn and x86 insn during JIT. + +The input context pointer for invoking the interpreter function is generic, +its content is defined by a specific use case. For seccomp register R1 points +to seccomp_data, for converted BPF filters R1 points to a skb. + +A program, that is translated internally consists of the following elements: + + op:16, jt:8, jf:8, k:32 ==> op:8, a_reg:4, x_reg:4, off:16, imm:32 + +Just like the original BPF, the new format runs within a controlled environment, +is deterministic and the kernel can easily prove that. The safety of the program +can be determined in two steps: first step does depth-first-search to disallow +loops and other CFG validation; second step starts from the first insn and +descends all possible paths. It simulates execution of every insn and observes +the state change of registers and stack. + Misc ---- @@ -561,3 +685,4 @@ the underlying architecture. Jay Schulist <jschlst@samba.org> Daniel Borkmann <dborkman@redhat.com> +Alexei Starovoitov <ast@plumgrid.com> diff --git a/Documentation/networking/gianfar.txt b/Documentation/networking/gianfar.txt index ad474ea07d07..ba1daea7f2e4 100644 --- a/Documentation/networking/gianfar.txt +++ b/Documentation/networking/gianfar.txt @@ -1,38 +1,8 @@ The Gianfar Ethernet Driver -Sysfs File description Author: Andy Fleming <afleming@freescale.com> Updated: 2005-07-28 -SYSFS - -Several of the features of the gianfar driver are controlled -through sysfs files. These are: - -bd_stash: -To stash RX Buffer Descriptors in the L2, echo 'on' or '1' to -bd_stash, echo 'off' or '0' to disable - -rx_stash_len: -To stash the first n bytes of the packet in L2, echo the number -of bytes to buf_stash_len. echo 0 to disable. - -WARNING: You could really screw these up if you set them too low or high! -fifo_threshold: -To change the number of bytes the controller needs in the -fifo before it starts transmission, echo the number of bytes to -fifo_thresh. Range should be 0-511. - -fifo_starve: -When the FIFO has less than this many bytes during a transmit, it -enters starve mode, and increases the priority of TX memory -transactions. To change, echo the number of bytes to -fifo_starve. Range should be 0-511. - -fifo_starve_off: -Once in starve mode, the FIFO remains there until it has this -many bytes. To change, echo the number of bytes to -fifo_starve_off. Range should be 0-511. CHECKSUM OFFLOADING diff --git a/Documentation/networking/igb.txt b/Documentation/networking/igb.txt index 4ebbd659256f..43d3549366a0 100644 --- a/Documentation/networking/igb.txt +++ b/Documentation/networking/igb.txt @@ -36,54 +36,6 @@ Default Value: 0 This parameter adds support for SR-IOV. It causes the driver to spawn up to max_vfs worth of virtual function. -QueuePairs ----------- -Valid Range: 0-1 -Default Value: 1 (TX and RX will be paired onto one interrupt vector) - -If set to 0, when MSI-X is enabled, the TX and RX will attempt to occupy -separate vectors. - -This option can be overridden to 1 if there are not sufficient interrupts -available. This can occur if any combination of RSS, VMDQ, and max_vfs -results in more than 4 queues being used. - -Node ----- -Valid Range: 0-n -Default Value: -1 (off) - - 0 - n: where n is the number of the NUMA node that should be used to - allocate memory for this adapter port. - -1: uses the driver default of allocating memory on whichever processor is - running insmod/modprobe. - - The Node parameter will allow you to pick which NUMA node you want to have - the adapter allocate memory from. All driver structures, in-memory queues, - and receive buffers will be allocated on the node specified. This parameter - is only useful when interrupt affinity is specified, otherwise some portion - of the time the interrupt could run on a different core than the memory is - allocated on, causing slower memory access and impacting throughput, CPU, or - both. - -EEE ---- -Valid Range: 0-1 -Default Value: 1 (enabled) - - A link between two EEE-compliant devices will result in periodic bursts of - data followed by long periods where in the link is in an idle state. This Low - Power Idle (LPI) state is supported in both 1Gbps and 100Mbps link speeds. - NOTE: EEE support requires autonegotiation. - -DMAC ----- -Valid Range: 0-1 -Default Value: 1 (enabled) - Enables or disables DMA Coalescing feature. - - - Additional Configurations ========================= diff --git a/Documentation/networking/phy.txt b/Documentation/networking/phy.txt index ebf270719402..3544c98401fd 100644 --- a/Documentation/networking/phy.txt +++ b/Documentation/networking/phy.txt @@ -48,7 +48,7 @@ The MDIO bus time, so it is safe for them to block, waiting for an interrupt to signal the operation is complete - 2) A reset function is necessary. This is used to return the bus to an + 2) A reset function is optional. This is used to return the bus to an initialized state. 3) A probe function is needed. This function should set up anything the bus @@ -253,16 +253,25 @@ Writing a PHY driver Each driver consists of a number of function pointers: + soft_reset: perform a PHY software reset config_init: configures PHY into a sane state after a reset. For instance, a Davicom PHY requires descrambling disabled. probe: Allocate phy->priv, optionally refuse to bind. PHY may not have been reset or had fixups run yet. suspend/resume: power management config_aneg: Changes the speed/duplex/negotiation settings + aneg_done: Determines the auto-negotiation result read_status: Reads the current speed/duplex/negotiation settings ack_interrupt: Clear a pending interrupt + did_interrupt: Checks if the PHY generated an interrupt config_intr: Enable or disable interrupts remove: Does any driver take-down + ts_info: Queries about the HW timestamping status + hwtstamp: Set the PHY HW timestamping configuration + rxtstamp: Requests a receive timestamp at the PHY level for a 'skb' + txtsamp: Requests a transmit timestamp at the PHY level for a 'skb' + set_wol: Enable Wake-on-LAN at the PHY level + get_wol: Get the Wake-on-LAN status at the PHY level Of these, only config_aneg and read_status are required to be assigned by the driver code. The rest are optional. Also, it is diff --git a/Documentation/networking/pktgen.txt b/Documentation/networking/pktgen.txt index 5a61a240a652..0e30c7845b2b 100644 --- a/Documentation/networking/pktgen.txt +++ b/Documentation/networking/pktgen.txt @@ -102,13 +102,18 @@ Examples: The 'minimum' MAC is what you set with dstmac. pgset "flag [name]" Set a flag to determine behaviour. Current flags - are: IPSRC_RND #IP Source is random (between min/max), - IPDST_RND, UDPSRC_RND, - UDPDST_RND, MACSRC_RND, MACDST_RND + are: IPSRC_RND # IP source is random (between min/max) + IPDST_RND # IP destination is random + UDPSRC_RND, UDPDST_RND, + MACSRC_RND, MACDST_RND + TXSIZE_RND, IPV6, MPLS_RND, VID_RND, SVID_RND + FLOW_SEQ, QUEUE_MAP_RND # queue map random QUEUE_MAP_CPU # queue map mirrors smp_processor_id() - IPSEC # Make IPsec encapsulation for packet + UDPCSUM, + IPSEC # IPsec encapsulation (needs CONFIG_XFRM) + NODE_ALLOC # node specific memory allocation pgset spi SPI_VALUE Set specific SA used to transform packet. @@ -233,13 +238,22 @@ udp_dst_max flag IPSRC_RND - TXSIZE_RND IPDST_RND UDPSRC_RND UDPDST_RND MACSRC_RND MACDST_RND + TXSIZE_RND + IPV6 + MPLS_RND + VID_RND + SVID_RND + FLOW_SEQ + QUEUE_MAP_RND + QUEUE_MAP_CPU + UDPCSUM IPSEC + NODE_ALLOC dst_min dst_max diff --git a/Documentation/networking/rxrpc.txt b/Documentation/networking/rxrpc.txt index b89bc82eed46..16a924c486bf 100644 --- a/Documentation/networking/rxrpc.txt +++ b/Documentation/networking/rxrpc.txt @@ -27,6 +27,8 @@ Contents of this document: (*) AF_RXRPC kernel interface. + (*) Configurable parameters. + ======== OVERVIEW @@ -864,3 +866,82 @@ The kernel interface functions are as follows: This is used to allocate a null RxRPC key that can be used to indicate anonymous security for a particular domain. + + +======================= +CONFIGURABLE PARAMETERS +======================= + +The RxRPC protocol driver has a number of configurable parameters that can be +adjusted through sysctls in /proc/net/rxrpc/: + + (*) req_ack_delay + + The amount of time in milliseconds after receiving a packet with the + request-ack flag set before we honour the flag and actually send the + requested ack. + + Usually the other side won't stop sending packets until the advertised + reception window is full (to a maximum of 255 packets), so delaying the + ACK permits several packets to be ACK'd in one go. + + (*) soft_ack_delay + + The amount of time in milliseconds after receiving a new packet before we + generate a soft-ACK to tell the sender that it doesn't need to resend. + + (*) idle_ack_delay + + The amount of time in milliseconds after all the packets currently in the + received queue have been consumed before we generate a hard-ACK to tell + the sender it can free its buffers, assuming no other reason occurs that + we would send an ACK. + + (*) resend_timeout + + The amount of time in milliseconds after transmitting a packet before we + transmit it again, assuming no ACK is received from the receiver telling + us they got it. + + (*) max_call_lifetime + + The maximum amount of time in seconds that a call may be in progress + before we preemptively kill it. + + (*) dead_call_expiry + + The amount of time in seconds before we remove a dead call from the call + list. Dead calls are kept around for a little while for the purpose of + repeating ACK and ABORT packets. + + (*) connection_expiry + + The amount of time in seconds after a connection was last used before we + remove it from the connection list. Whilst a connection is in existence, + it serves as a placeholder for negotiated security; when it is deleted, + the security must be renegotiated. + + (*) transport_expiry + + The amount of time in seconds after a transport was last used before we + remove it from the transport list. Whilst a transport is in existence, it + serves to anchor the peer data and keeps the connection ID counter. + + (*) rxrpc_rx_window_size + + The size of the receive window in packets. This is the maximum number of + unconsumed received packets we're willing to hold in memory for any + particular call. + + (*) rxrpc_rx_mtu + + The maximum packet MTU size that we're willing to receive in bytes. This + indicates to the peer whether we're willing to accept jumbo packets. + + (*) rxrpc_rx_jumbo_max + + The maximum number of packets that we're willing to accept in a jumbo + packet. Non-terminal packets in a jumbo packet must contain a four byte + header plus exactly 1412 bytes of data. The terminal packet must contain + a four byte header plus any amount of data. In any event, a jumbo packet + may not exceed rxrpc_rx_mtu in size. diff --git a/Documentation/networking/tcp.txt b/Documentation/networking/tcp.txt index 7d11bb5dc30a..bdc4c0db51e1 100644 --- a/Documentation/networking/tcp.txt +++ b/Documentation/networking/tcp.txt @@ -30,7 +30,7 @@ A congestion control mechanism can be registered through functions in tcp_cong.c. The functions used by the congestion control mechanism are registered via passing a tcp_congestion_ops struct to tcp_register_congestion_control. As a minimum name, ssthresh, -cong_avoid, min_cwnd must be valid. +cong_avoid must be valid. Private data for a congestion control mechanism is stored in tp->ca_priv. tcp_ca(tp) returns a pointer to this space. This is preallocated space - it diff --git a/Documentation/networking/timestamping.txt b/Documentation/networking/timestamping.txt index 048c92b487f6..bc3554124903 100644 --- a/Documentation/networking/timestamping.txt +++ b/Documentation/networking/timestamping.txt @@ -202,6 +202,9 @@ Time stamps for outgoing packets are to be generated as follows: and not free the skb. A driver not supporting hardware time stamping doesn't do that. A driver must never touch sk_buff::tstamp! It is used to store software generated time stamps by the network subsystem. +- Driver should call skb_tx_timestamp() as close to passing sk_buff to hardware + as possible. skb_tx_timestamp() provides a software time stamp if requested + and hardware timestamping is not possible (SKBTX_IN_PROGRESS not set). - As soon as the driver has sent the packet and/or obtained a hardware time stamp for it, it passes the time stamp back by calling skb_hwtstamp_tx() with the original skb, the raw @@ -212,6 +215,3 @@ Time stamps for outgoing packets are to be generated as follows: this would occur at a later time in the processing pipeline than other software time stamping and therefore could lead to unexpected deltas between time stamps. -- If the driver did not set the SKBTX_IN_PROGRESS flag (see above), then - dev_hard_start_xmit() checks whether software time stamping - is wanted as fallback and potentially generates the time stamp. diff --git a/Documentation/oops-tracing.txt b/Documentation/oops-tracing.txt index 13032c0140d4..e3155995ddd8 100644 --- a/Documentation/oops-tracing.txt +++ b/Documentation/oops-tracing.txt @@ -265,6 +265,9 @@ characters, each representing a particular tainted value. 13: 'O' if an externally-built ("out-of-tree") module has been loaded. + 14: 'E' if an unsigned module has been loaded in a kernel supporting + module signature. + The primary reason for the 'Tainted: ' string is to tell kernel debuggers if this is a clean kernel or if anything unusual has occurred. Tainting is permanent: even if an offending module is diff --git a/Documentation/ptp/testptp.c b/Documentation/ptp/testptp.c index 4aba0436da65..f1ac2dae999e 100644 --- a/Documentation/ptp/testptp.c +++ b/Documentation/ptp/testptp.c @@ -19,6 +19,7 @@ */ #include <errno.h> #include <fcntl.h> +#include <inttypes.h> #include <math.h> #include <signal.h> #include <stdio.h> @@ -120,11 +121,19 @@ static void usage(char *progname) " -i val index for event/trigger\n" " -k val measure the time offset between system and phc clock\n" " for 'val' times (Maximum 25)\n" + " -l list the current pin configuration\n" + " -L pin,val configure pin index 'pin' with function 'val'\n" + " the channel index is taken from the '-i' option\n" + " 'val' specifies the auxiliary function:\n" + " 0 - none\n" + " 1 - external time stamp\n" + " 2 - periodic output\n" " -p val enable output with a period of 'val' nanoseconds\n" " -P val enable or disable (val=1|0) the system clock PPS\n" " -s set the ptp clock time from the system time\n" " -S set the system time from the ptp clock time\n" - " -t val shift the ptp clock time by 'val' seconds\n", + " -t val shift the ptp clock time by 'val' seconds\n" + " -T val set the ptp clock time to 'val' seconds\n", progname); } @@ -134,6 +143,7 @@ int main(int argc, char *argv[]) struct ptp_extts_event event; struct ptp_extts_request extts_request; struct ptp_perout_request perout_request; + struct ptp_pin_desc desc; struct timespec ts; struct timex tx; @@ -156,12 +166,15 @@ int main(int argc, char *argv[]) int extts = 0; int gettime = 0; int index = 0; + int list_pins = 0; int oneshot = 0; int pct_offset = 0; int n_samples = 0; int periodic = 0; int perout = -1; + int pin_index = -1, pin_func; int pps = -1; + int seconds = 0; int settime = 0; int64_t t1, t2, tp; @@ -169,7 +182,7 @@ int main(int argc, char *argv[]) progname = strrchr(argv[0], '/'); progname = progname ? 1+progname : argv[0]; - while (EOF != (c = getopt(argc, argv, "a:A:cd:e:f:ghi:k:p:P:sSt:v"))) { + while (EOF != (c = getopt(argc, argv, "a:A:cd:e:f:ghi:k:lL:p:P:sSt:T:v"))) { switch (c) { case 'a': oneshot = atoi(optarg); @@ -199,6 +212,16 @@ int main(int argc, char *argv[]) pct_offset = 1; n_samples = atoi(optarg); break; + case 'l': + list_pins = 1; + break; + case 'L': + cnt = sscanf(optarg, "%d,%d", &pin_index, &pin_func); + if (cnt != 2) { + usage(progname); + return -1; + } + break; case 'p': perout = atoi(optarg); break; @@ -214,6 +237,10 @@ int main(int argc, char *argv[]) case 't': adjtime = atoi(optarg); break; + case 'T': + settime = 3; + seconds = atoi(optarg); + break; case 'h': usage(progname); return 0; @@ -245,12 +272,14 @@ int main(int argc, char *argv[]) " %d programmable alarms\n" " %d external time stamp channels\n" " %d programmable periodic signals\n" - " %d pulse per second\n", + " %d pulse per second\n" + " %d programmable pins\n", caps.max_adj, caps.n_alarm, caps.n_ext_ts, caps.n_per_out, - caps.pps); + caps.pps, + caps.n_pins); } } @@ -304,6 +333,16 @@ int main(int argc, char *argv[]) } } + if (settime == 3) { + ts.tv_sec = seconds; + ts.tv_nsec = 0; + if (clock_settime(clkid, &ts)) { + perror("clock_settime"); + } else { + puts("set time okay"); + } + } + if (extts) { memset(&extts_request, 0, sizeof(extts_request)); extts_request.index = index; @@ -331,6 +370,24 @@ int main(int argc, char *argv[]) } } + if (list_pins) { + int n_pins = 0; + if (ioctl(fd, PTP_CLOCK_GETCAPS, &caps)) { + perror("PTP_CLOCK_GETCAPS"); + } else { + n_pins = caps.n_pins; + } + for (i = 0; i < n_pins; i++) { + desc.index = i; + if (ioctl(fd, PTP_PIN_GETFUNC, &desc)) { + perror("PTP_PIN_GETFUNC"); + break; + } + printf("name %s index %u func %u chan %u\n", + desc.name, desc.index, desc.func, desc.chan); + } + } + if (oneshot) { install_handler(SIGALRM, handle_alarm); /* Create a timer. */ @@ -392,6 +449,18 @@ int main(int argc, char *argv[]) } } + if (pin_index >= 0) { + memset(&desc, 0, sizeof(desc)); + desc.index = pin_index; + desc.func = pin_func; + desc.chan = index; + if (ioctl(fd, PTP_PIN_SETFUNC, &desc)) { + perror("PTP_PIN_SETFUNC"); + } else { + puts("set pin function okay"); + } + } + if (pps != -1) { int enable = pps ? 1 : 0; if (ioctl(fd, PTP_ENABLE_PPS, enable)) { @@ -428,14 +497,14 @@ int main(int argc, char *argv[]) interval = t2 - t1; offset = (t2 + t1) / 2 - tp; - printf("system time: %ld.%ld\n", + printf("system time: %" PRId64 ".%u\n", (pct+2*i)->sec, (pct+2*i)->nsec); - printf("phc time: %ld.%ld\n", + printf("phc time: %" PRId64 ".%u\n", (pct+2*i+1)->sec, (pct+2*i+1)->nsec); - printf("system time: %ld.%ld\n", + printf("system time: %" PRId64 ".%u\n", (pct+2*i+2)->sec, (pct+2*i+2)->nsec); - printf("system/phc clock time offset is %ld ns\n" - "system clock time delay is %ld ns\n", + printf("system/phc clock time offset is %" PRId64 " ns\n" + "system clock time delay is %" PRId64 " ns\n", offset, interval); } diff --git a/Documentation/rapidio/sysfs.txt b/Documentation/rapidio/sysfs.txt index 271438c0617f..47ce9a5336e1 100644 --- a/Documentation/rapidio/sysfs.txt +++ b/Documentation/rapidio/sysfs.txt @@ -2,8 +2,8 @@ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -1. Device Subdirectories ------------------------- +1. RapidIO Device Subdirectories +-------------------------------- For each RapidIO device, the RapidIO subsystem creates files in an individual subdirectory with the following name, /sys/bus/rapidio/devices/<device_name>. @@ -25,8 +25,8 @@ seen by the enumerating host (destID = 1): NOTE: An enumerating or discovering endpoint does not create a sysfs entry for itself, this is why an endpoint with destID=1 is not shown in the list. -2. Attributes Common for All Devices ------------------------------------- +2. Attributes Common for All RapidIO Devices +-------------------------------------------- Each device subdirectory contains the following informational read-only files: @@ -52,16 +52,16 @@ This attribute is similar in behavior to the "config" attribute of PCI devices and provides an access to the RapidIO device registers using standard file read and write operations. -3. Endpoint Device Attributes ------------------------------ +3. RapidIO Endpoint Device Attributes +------------------------------------- Currently Linux RapidIO subsystem does not create any endpoint specific sysfs attributes. It is possible that RapidIO master port drivers and endpoint device drivers will add their device-specific sysfs attributes but such attributes are outside the scope of this document. -4. Switch Device Attributes ---------------------------- +4. RapidIO Switch Device Attributes +----------------------------------- RapidIO switches have additional attributes in sysfs. RapidIO subsystem supports common and device-specific sysfs attributes for switches. Because switches are @@ -106,3 +106,53 @@ attribute: for that controller always will be 0. To initiate RapidIO enumeration/discovery on all available mports a user must write '-1' (or RIO_MPORT_ANY) into this attribute file. + + +6. RapidIO Bus Controllers/Ports +-------------------------------- + +On-chip RapidIO controllers and PCIe-to-RapidIO bridges (referenced as +"Master Port" or "mport") are presented in sysfs as the special class of +devices: "rapidio_port". + +The /sys/class/rapidio_port subdirectory contains individual subdirectories +named as "rapidioN" where N = mport ID registered with RapidIO subsystem. + +NOTE: An mport ID is not a RapidIO destination ID assigned to a given local +mport device. + +Each mport device subdirectory in addition to standard entries contains the +following device-specific attributes: + + port_destid - reports RapidIO destination ID assigned to the given RapidIO + mport device. If value 0xFFFFFFFF is returned this means that + no valid destination ID have been assigned to the mport (yet). + Normally, before enumeration/discovery have been executed only + fabric enumerating mports have a valid destination ID assigned + to them using "hdid=..." rapidio module parameter. + sys_size - reports RapidIO common transport system size: + 0 = small (8-bit destination ID, max. 256 devices), + 1 = large (16-bit destination ID, max. 65536 devices). + +After enumeration or discovery was performed for a given mport device, +the corresponding subdirectory will also contain subdirectories for each +child RapidIO device connected to the mport. Naming conventions for RapidIO +devices are described in Section 1 above. + +The example below shows mport device subdirectory with several child RapidIO +devices attached to it. + +[rio@rapidio ~]$ ls /sys/class/rapidio_port/rapidio0/ -l +total 0 +drwxr-xr-x 3 root root 0 Feb 11 15:10 00:e:0001 +drwxr-xr-x 3 root root 0 Feb 11 15:10 00:e:0004 +drwxr-xr-x 3 root root 0 Feb 11 15:10 00:e:0007 +drwxr-xr-x 3 root root 0 Feb 11 15:10 00:s:0002 +drwxr-xr-x 3 root root 0 Feb 11 15:10 00:s:0003 +drwxr-xr-x 3 root root 0 Feb 11 15:10 00:s:0005 +lrwxrwxrwx 1 root root 0 Feb 11 15:11 device -> ../../../0000:01:00.0 +-r--r--r-- 1 root root 4096 Feb 11 15:11 port_destid +drwxr-xr-x 2 root root 0 Feb 11 15:11 power +lrwxrwxrwx 1 root root 0 Feb 11 15:04 subsystem -> ../../../../../../class/rapidio_port +-r--r--r-- 1 root root 4096 Feb 11 15:11 sys_size +-rw-r--r-- 1 root root 4096 Feb 11 15:04 uevent diff --git a/Documentation/scheduler/sched-arch.txt b/Documentation/scheduler/sched-arch.txt index 9290de703450..a2f27bbf2cba 100644 --- a/Documentation/scheduler/sched-arch.txt +++ b/Documentation/scheduler/sched-arch.txt @@ -8,7 +8,7 @@ Context switch By default, the switch_to arch function is called with the runqueue locked. This is usually not a problem unless switch_to may need to take the runqueue lock. This is usually due to a wake up operation in -the context switch. See arch/ia64/include/asm/system.h for an example. +the context switch. See arch/ia64/include/asm/switch_to.h for an example. To request the scheduler call switch_to with the runqueue unlocked, you must `#define __ARCH_WANT_UNLOCKED_CTXSW` in a header file diff --git a/Documentation/serial/00-INDEX b/Documentation/serial/00-INDEX index f9c6b5ed03e7..8021a9f29fc5 100644 --- a/Documentation/serial/00-INDEX +++ b/Documentation/serial/00-INDEX @@ -2,23 +2,15 @@ - this file. README.cycladesZ - info on Cyclades-Z firmware loading. -digiepca.txt - - info on Digi Intl. {PC,PCI,EISA}Xx and Xem series cards. driver - intro to the low level serial driver. moxa-smartio - file with info on installing/using Moxa multiport serial driver. n_gsm.txt - GSM 0710 tty multiplexer howto. -riscom8.txt - - notes on using the RISCom/8 multi-port serial driver. rocket.txt - info on the Comtrol RocketPort multiport serial driver. serial-rs485.txt - info about RS485 structures and support in the kernel. -specialix.txt - - info on hardware/driver for specialix IO8+ multiport serial card. -sx.txt - - info on the Specialix SX/SI multiport serial driver. tty.txt - guide to the locking policies of the tty layer. diff --git a/Documentation/serial/digiepca.txt b/Documentation/serial/digiepca.txt deleted file mode 100644 index f2560e22f2c9..000000000000 --- a/Documentation/serial/digiepca.txt +++ /dev/null @@ -1,98 +0,0 @@ -NOTE: This driver is obsolete. Digi provides a 2.6 driver (dgdm) at -http://www.digi.com for PCI cards. They no longer maintain this driver, -and have no 2.6 driver for ISA cards. - -This driver requires a number of user-space tools. They can be acquired from -http://www.digi.com, but only works with 2.4 kernels. - - -The Digi Intl. epca driver. ----------------------------- -The Digi Intl. epca driver for Linux supports the following boards: - -Digi PC/Xem, PC/Xr, PC/Xe, PC/Xi, PC/Xeve -Digi EISA/Xem, PCI/Xem, PCI/Xr - -Limitations: ------------- -Currently the driver only autoprobes for supported PCI boards. - -The Linux MAKEDEV command does not support generating the Digiboard -Devices. Users executing digiConfig to setup EISA and PC series cards -will have their device nodes automatically constructed (cud?? for ~CLOCAL, -and ttyD?? for CLOCAL). Users wishing to boot their board from the LILO -prompt, or those users booting PCI cards may use buildDIGI to construct -the necessary nodes. - -Notes: ------- -This driver may be configured via LILO. For users who have already configured -their driver using digiConfig, configuring from LILO will override previous -settings. Multiple boards may be configured by issuing multiple LILO command -lines. For examples see the bottom of this document. - -Device names start at 0 and continue up. Beware of this as previous Digi -drivers started device names with 1. - -PCI boards are auto-detected and configured by the driver. PCI boards will -be allocated device numbers (internally) beginning with the lowest PCI slot -first. In other words a PCI card in slot 3 will always have higher device -nodes than a PCI card in slot 1. - -LILO config examples: ---------------------- -Using LILO's APPEND command, a string of comma separated identifiers or -integers can be used to configure supported boards. The six values in order -are: - - Enable/Disable this card or Override, - Type of card: PC/Xe (AccelePort) (0), PC/Xeve (1), PC/Xem or PC/Xr (2), - EISA/Xem (3), PC/64Xe (4), PC/Xi (5), - Enable/Disable alternate pin arrangement, - Number of ports on this card, - I/O Port where card is configured (in HEX if using string identifiers), - Base of memory window (in HEX if using string identifiers), - -NOTE : PCI boards are auto-detected and configured. Do not attempt to -configure PCI boards with the LILO append command. If you wish to override -previous configuration data (As set by digiConfig), but you do not wish to -configure any specific card (Example if there are PCI cards in the system) -the following override command will accomplish this: --> append="digi=2" - -Samples: - append="digiepca=E,PC/Xe,D,16,200,D0000" - or - append="digi=1,0,0,16,512,851968" - -Supporting Tools: ------------------ -Supporting tools include digiDload, digiConfig, buildPCI, and ditty. See -drivers/char/README.epca for more details. Note, -this driver REQUIRES that digiDload be executed prior to it being used. -Failure to do this will result in an ENODEV error. - -Documentation: --------------- -Complete documentation for this product may be found in the tool package. - -Sources of information and support: ------------------------------------ -Digi Intl. support site for this product: - --> http://www.digi.com - -Acknowledgments: ----------------- -Much of this work (And even text) was derived from a similar document -supporting the original public domain DigiBoard driver Copyright (C) -1994,1995 Troy De Jongh. Many thanks to Christoph Lameter -(christoph@lameter.com) and Mike McLagan (mike.mclagan@linux.org) who authored -and contributed to the original document. - -Changelog: ----------- -10-29-04: Update status of driver, remove dead links in document - James Nelson <james4765@gmail.com> - -2000 (?) Original Document diff --git a/Documentation/serial/riscom8.txt b/Documentation/serial/riscom8.txt deleted file mode 100644 index 14f61fdad7ca..000000000000 --- a/Documentation/serial/riscom8.txt +++ /dev/null @@ -1,36 +0,0 @@ -* NOTE - this is an unmaintained driver. The original author cannot be located. - -SDL Communications is now SBS Technologies, and does not have any -information on these ancient ISA cards on their website. - -James Nelson <james4765@gmail.com> - 12-12-2004 - - This is the README for RISCom/8 multi-port serial driver - (C) 1994-1996 D.Gorodchanin - See file LICENSE for terms and conditions. - -NOTE: English is not my native language. - I'm sorry for any mistakes in this text. - -Misc. notes for RISCom/8 serial driver, in no particular order :) - -1) This driver can support up to 4 boards at time. - Use string "riscom8=0xXXX,0xXXX,0xXXX,0xXXX" at LILO prompt, for - setting I/O base addresses for boards. If you compile driver - as module use modprobe options "iobase=0xXXX iobase1=0xXXX iobase2=..." - -2) The driver partially supports famous 'setserial' program, you can use almost - any of its options, excluding port & irq settings. - -3) There are some misc. defines at the beginning of riscom8.c, please read the - comments and try to change some of them in case of problems. - -4) I consider the current state of the driver as BETA. - -5) SDL Communications WWW page is http://www.sdlcomm.com. - -6) You can use the MAKEDEV program to create RISCom/8 /dev/ttyL* entries. - -7) Minor numbers for first board are 0-7, for second 8-15, etc. - -22 Apr 1996. diff --git a/Documentation/serial/specialix.txt b/Documentation/serial/specialix.txt deleted file mode 100644 index 6eb6f3a3331c..000000000000 --- a/Documentation/serial/specialix.txt +++ /dev/null @@ -1,383 +0,0 @@ - - specialix.txt -- specialix IO8+ multiport serial driver readme. - - - - Copyright (C) 1997 Roger Wolff (R.E.Wolff@BitWizard.nl) - - Specialix pays for the development and support of this driver. - Please DO contact io8-linux@specialix.co.uk if you require - support. - - This driver was developed in the BitWizard linux device - driver service. If you require a linux device driver for your - product, please contact devices@BitWizard.nl for a quote. - - This code is firmly based on the riscom/8 serial driver, - written by Dmitry Gorodchanin. The specialix IO8+ card - programming information was obtained from the CL-CD1865 Data - Book, and Specialix document number 6200059: IO8+ Hardware - Functional Specification, augmented by document number 6200088: - Merak Hardware Functional Specification. (IO8+/PCI is also - called Merak) - - - This program is free software; you can redistribute it and/or - modify it under the terms of the GNU General Public License as - published by the Free Software Foundation; either version 2 of - the License, or (at your option) any later version. - - This program is distributed in the hope that it will be - useful, but WITHOUT ANY WARRANTY; without even the implied - warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR - PURPOSE. See the GNU General Public License for more details. - - You should have received a copy of the GNU General Public - License along with this program; if not, write to the Free - Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, - USA. - - -Intro -===== - - -This file contains some random information, that I like to have online -instead of in a manual that can get lost. Ever misplace your Linux -kernel sources? And the manual of one of the boards in your computer? - - -Addresses and interrupts -======================== - -Address dip switch settings: -The dip switch sets bits 2-9 of the IO address. - - 9 8 7 6 5 4 3 2 - +-----------------+ - 0 | X X X X X X X | - | | = IoBase = 0x100 - 1 | X | - +-----------------+ ------ RS232 connectors ----> - - | | | - edge connector - | | | - V V V - -Base address 0x100 caused a conflict in one of my computers once. I -haven't the foggiest why. My Specialix card is now at 0x180. My -other computer runs just fine with the Specialix card at 0x100.... -The card occupies 4 addresses, but actually only two are really used. - -The PCI version doesn't have any dip switches. The BIOS assigns -an IO address. - -The driver now still autoprobes at 0x100, 0x180, 0x250 and 0x260. If -that causes trouble for you, please report that. I'll remove -autoprobing then. - -The driver will tell the card what IRQ to use, so you don't have to -change any jumpers to change the IRQ. Just use a command line -argument (irq=xx) to the insmod program to set the interrupt. - -The BIOS assigns the IRQ on the PCI version. You have no say in what -IRQ to use in that case. - -If your specialix cards are not at the default locations, you can use -the kernel command line argument "specialix=io0,irq0,io1,irq1...". -Here "io0" is the io address for the first card, and "irq0" is the -irq line that the first card should use. And so on. - -Examples. - -You use the driver as a module and have three cards at 0x100, 0x250 -and 0x180. And some way or another you want them detected in that -order. Moreover irq 12 is taken (e.g. by your PS/2 mouse). - - insmod specialix.o iobase=0x100,0x250,0x180 irq=9,11,15 - -The same three cards, but now in the kernel would require you to -add - - specialix=0x100,9,0x250,11,0x180,15 - -to the command line. This would become - - append="specialix=0x100,9,0x250,11,0x180,15" - -in your /etc/lilo.conf file if you use lilo. - -The Specialix driver is slightly odd: It allows you to have the second -or third card detected without having a first card. This has -advantages and disadvantages. A slot that isn't filled by an ISA card, -might be filled if a PCI card is detected. Thus if you have an ISA -card at 0x250 and a PCI card, you would get: - -sx0: specialix IO8+ Board at 0x100 not found. -sx1: specialix IO8+ Board at 0x180 not found. -sx2: specialix IO8+ board detected at 0x250, IRQ 12, CD1865 Rev. B. -sx3: specialix IO8+ Board at 0x260 not found. -sx0: specialix IO8+ board detected at 0xd800, IRQ 9, CD1865 Rev. B. - -This would happen if you don't give any probe hints to the driver. -If you would specify: - - specialix=0x250,11 - -you'd get the following messages: - -sx0: specialix IO8+ board detected at 0x250, IRQ 11, CD1865 Rev. B. -sx1: specialix IO8+ board detected at 0xd800, IRQ 9, CD1865 Rev. B. - -ISA probing is aborted after the IO address you gave is exhausted, and -the PCI card is now detected as the second card. The ISA card is now -also forced to IRQ11.... - - -Baud rates -========== - -The rev 1.2 and below boards use a CL-CD1864. These chips can only -do 64kbit. The rev 1.3 and newer boards use a CL-CD1865. These chips -are officially capable of 115k2. - -The Specialix card uses a 25MHz crystal (in times two mode, which in -fact is a divided by two mode). This is not enough to reach the rated -115k2 on all ports at the same time. With this clock rate you can only -do 37% of this rate. This means that at 115k2 on all ports you are -going to lose characters (The chip cannot handle that many incoming -bits at this clock rate.) (Yes, you read that correctly: there is a -limit to the number of -=bits=- per second that the chip can handle.) - -If you near the "limit" you will first start to see a graceful -degradation in that the chip cannot keep the transmitter busy at all -times. However with a central clock this slow, you can also get it to -miss incoming characters. The driver will print a warning message when -you are outside the official specs. The messages usually show up in -the file /var/log/messages . - -The specialix card cannot reliably do 115k2. If you use it, you have -to do "extensive testing" (*) to verify if it actually works. - -When "mgetty" communicates with my modem at 115k2 it reports: -got: +++[0d]ATQ0V1H0[0d][0d][8a]O[cb][0d][8a] - ^^^^ ^^^^ ^^^^ - -The three characters that have the "^^^" under them have suffered a -bit error in the highest bit. In conclusion: I've tested it, and found -that it simply DOESN'T work for me. I also suspect that this is also -caused by the baud rate being just a little bit out of tune. - -I upgraded the crystal to 66Mhz on one of my Specialix cards. Works -great! Contact me for details. (Voids warranty, requires a steady hand -and more such restrictions....) - - -(*) Cirrus logic CD1864 databook, page 40. - - -Cables for the Specialix IO8+ -============================= - -The pinout of the connectors on the IO8+ is: - - pin short direction long name - name - Pin 1 DCD input Data Carrier Detect - Pin 2 RXD input Receive - Pin 3 DTR/RTS output Data Terminal Ready/Ready To Send - Pin 4 GND - Ground - Pin 5 TXD output Transmit - Pin 6 CTS input Clear To Send - - - -- 6 5 4 3 2 1 -- - | | - | | - | | - | | - +----- -----+ - |__________| - clip - - Front view of an RJ12 connector. Cable moves "into" the paper. - (the plug is ready to plug into your mouth this way...) - - - NULL cable. I don't know who is going to use these except for - testing purposes, but I tested the cards with this cable. (It - took quite a while to figure out, so I'm not going to delete - it. So there! :-) - - - This end goes This end needs - straight into the some twists in - RJ12 plug. the wiring. - IO8+ RJ12 IO8+ RJ12 - 1 DCD white - - - - 1 DCD - 2 RXD black 5 TXD - 3 DTR/RTS red 6 CTS - 4 GND green 4 GND - 5 TXD yellow 2 RXD - 6 CTS blue 3 DTR/RTS - - - Same NULL cable, but now sorted on the second column. - - 1 DCD white - - - - 1 DCD - 5 TXD yellow 2 RXD - 6 CTS blue 3 DTR/RTS - 4 GND green 4 GND - 2 RXD black 5 TXD - 3 DTR/RTS red 6 CTS - - - - This is a modem cable usable for hardware handshaking: - RJ12 DB25 DB9 - 1 DCD white 8 DCD 1 DCD - 2 RXD black 3 RXD 2 RXD - 3 DTR/RTS red 4 RTS 7 RTS - 4 GND green 7 GND 5 GND - 5 TXD yellow 2 TXD 3 TXD - 6 CTS blue 5 CTS 8 CTS - +---- 6 DSR 6 DSR - +---- 20 DTR 4 DTR - - This is a modem cable usable for software handshaking: - It allows you to reset the modem using the DTR ioctls. - I (REW) have never tested this, "but xxxxxxxxxxxxx - says that it works." If you test this, please - tell me and I'll fill in your name on the xxx's. - - RJ12 DB25 DB9 - 1 DCD white 8 DCD 1 DCD - 2 RXD black 3 RXD 2 RXD - 3 DTR/RTS red 20 DTR 4 DTR - 4 GND green 7 GND 5 GND - 5 TXD yellow 2 TXD 3 TXD - 6 CTS blue 5 CTS 8 CTS - +---- 6 DSR 6 DSR - +---- 4 RTS 7 RTS - - I bought a 6 wire flat cable. It was colored as indicated. - Check that yours is the same before you trust me on this. - - -Hardware handshaking issues. -============================ - -The driver can be told to operate in two different ways. The default -behaviour is specialix.sx_rtscts = 0 where the pin behaves as DTR when -hardware handshaking is off. It behaves as the RTS hardware -handshaking signal when hardware handshaking is selected. - -When you use this, you have to use the appropriate cable. The -cable will either be compatible with hardware handshaking or with -software handshaking. So switching on the fly is not really an -option. - -I actually prefer to use the "specialix.sx_rtscts=1" option. -This makes the DTR/RTS pin always an RTS pin, and ioctls to -change DTR are always ignored. I have a cable that is configured -for this. - - -Ports and devices -================= - -Port 0 is the one furthest from the card-edge connector. - -Devices: - -You should make the devices as follows: - -bash -cd /dev -for i in 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 \ - 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 -do - echo -n "$i " - mknod /dev/ttyW$i c 75 $i - mknod /dev/cuw$i c 76 $i -done -echo "" - -If your system doesn't come with these devices preinstalled, bug your -linux-vendor about this. They have had ample time to get this -implemented by now. - -You cannot have more than 4 boards in one computer. The card only -supports 4 different interrupts. If you really want this, contact me -about this and I'll give you a few tips (requires soldering iron).... - -If you have enough PCI slots, you can probably use more than 4 PCI -versions of the card though.... - -The PCI version of the card cannot adhere to the mechanical part of -the PCI spec because the 8 serial connectors are simply too large. If -it doesn't fit in your computer, bring back the card. - - ------------------------------------------------------------------------- - - - Fixed bugs and restrictions: - - During initialization, interrupts are blindly turned on. - Having a shadow variable would cause an extra memory - access on every IO instruction. - - The interrupt (on the card) should be disabled when we - don't allocate the Linux end of the interrupt. This allows - a different driver/card to use it while all ports are not in - use..... (a la standard serial port) - == An extra _off variant of the sx_in and sx_out macros are - now available. They don't set the interrupt enable bit. - These are used during initialization. Normal operation uses - the old variant which enables the interrupt line. - - RTS/DTR issue needs to be implemented according to - specialix' spec. - I kind of like the "determinism" of the current - implementation. Compile time flag? - == Ok. Compile time flag! Default is how Specialix likes it. - == Now a config time flag! Gets saved in your config file. Neat! - - Can you set the IO address from the lilo command line? - If you need this, bug me about it, I'll make it. - == Hah! No bugging needed. Fixed! :-) - - Cirrus logic hasn't gotten back to me yet why the CD1865 can - and the CD1864 can't do 115k2. I suspect that this is - because the CD1864 is not rated for 33MHz operation. - Therefore the CD1864 versions of the card can't do 115k2 on - all ports just like the CD1865 versions. The driver does - not block 115k2 on CD1864 cards. - == I called the Cirrus Logic representative here in Holland. - The CD1864 databook is identical to the CD1865 databook, - except for an extra warning at the end. Similar Bit errors - have been observed in testing at 115k2 on both an 1865 and - a 1864 chip. I see no reason why I would prohibit 115k2 on - 1864 chips and not do it on 1865 chips. Actually there is - reason to prohibit it on BOTH chips. I print a warning. - If you use 115k2, you're on your own. - - A spiky CD may send spurious HUPs. Also in CLOCAL??? - -- A fix for this turned out to be counter productive. - Different fix? Current behaviour is acceptable? - -- Maybe the current implementation is correct. If anybody - gets bitten by this, please report, and it will get fixed. - - -- Testing revealed that when in CLOCAL, the problem doesn't - occur. As warned for in the CD1865 manual, the chip may - send modem intr's on a spike. We could filter those out, - but that would be a cludge anyway (You'd still risk getting - a spurious HUP when two spikes occur.)..... - - - - Bugs & restrictions: - - This is a difficult card to autoprobe. - You have to WRITE to the address register to even - read-probe a CD186x register. Disable autodetection? - -- Specialix: any suggestions? - - diff --git a/Documentation/serial/sx.txt b/Documentation/serial/sx.txt deleted file mode 100644 index cb4efa0fb5cc..000000000000 --- a/Documentation/serial/sx.txt +++ /dev/null @@ -1,294 +0,0 @@ - - sx.txt -- specialix SX/SI multiport serial driver readme. - - - - Copyright (C) 1997 Roger Wolff (R.E.Wolff@BitWizard.nl) - - Specialix pays for the development and support of this driver. - Please DO contact support@specialix.co.uk if you require - support. - - This driver was developed in the BitWizard linux device - driver service. If you require a linux device driver for your - product, please contact devices@BitWizard.nl for a quote. - - (History) - There used to be an SI driver by Simon Allan. This is a complete - rewrite from scratch. Just a few lines-of-code have been snatched. - - (Sources) - Specialix document number 6210028: SX Host Card and Download Code - Software Functional Specification. - - (Copying) - This program is free software; you can redistribute it and/or - modify it under the terms of the GNU General Public License as - published by the Free Software Foundation; either version 2 of - the License, or (at your option) any later version. - - This program is distributed in the hope that it will be - useful, but WITHOUT ANY WARRANTY; without even the implied - warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR - PURPOSE. See the GNU General Public License for more details. - - You should have received a copy of the GNU General Public - License along with this program; if not, write to the Free - Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, - USA. - - (Addendum) - I'd appreciate it that if you have fixes, that you send them - to me first. - - -Introduction -============ - -This file contains some random information, that I like to have online -instead of in a manual that can get lost. Ever misplace your Linux -kernel sources? And the manual of one of the boards in your computer? - - -Theory of operation -=================== - -An important thing to know is that the driver itself doesn't have the -firmware for the card. This means that you need the separate package -"sx_firmware". For now you can get the source at - - ftp://ftp.bitwizard.nl/specialix/sx_firmware_<version>.tgz - -The firmware load needs a "misc" device, so you'll need to enable the -"Support for user misc device modules" in your kernel configuration. -The misc device needs to be called "/dev/specialix_sxctl". It needs -misc major 10, and minor number 167 (assigned by HPA). The section -on creating device files below also creates this device. - -After loading the sx.o module into your kernel, the driver will report -the number of cards detected, but because it doesn't have any -firmware, it will not be able to determine the number of ports. Only -when you then run "sx_firmware" will the firmware be downloaded and -the rest of the driver initialized. At that time the sx_firmware -program will report the number of ports installed. - -In contrast with many other multi port serial cards, some of the data -structures are only allocated when the card knows the number of ports -that are connected. This means we won't waste memory for 120 port -descriptor structures when you only have 8 ports. If you experience -problems due to this, please report them: I haven't seen any. - - -Interrupts -========== - -A multi port serial card, would generate a horrendous amount of -interrupts if it would interrupt the CPU for every received -character. Even more than 10 years ago, the trick not to use -interrupts but to poll the serial cards was invented. - -The SX card allow us to do this two ways. First the card limits its -own interrupt rate to a rate that won't overwhelm the CPU. Secondly, -we could forget about the cards interrupt completely and use the -internal timer for this purpose. - -Polling the card can take up to a few percent of your CPU. Using the -interrupts would be better if you have most of the ports idle. Using -timer-based polling is better if your card almost always has work to -do. You save the separate interrupt in that case. - -In any case, it doesn't really matter all that much. - -The most common problem with interrupts is that for ISA cards in a PCI -system the BIOS has to be told to configure that interrupt as "legacy -ISA". Otherwise the card can pull on the interrupt line all it wants -but the CPU won't see this. - -If you can't get the interrupt to work, remember that polling mode is -more efficient (provided you actually use the card intensively). - - -Allowed Configurations -====================== - -Some configurations are disallowed. Even though at a glance they might -seem to work, they are known to lockup the bus between the host card -and the device concentrators. You should respect the drivers decision -not to support certain configurations. It's there for a reason. - -Warning: Seriously technical stuff ahead. Executive summary: Don't use -SX cards except configured at a 64k boundary. Skip the next paragraph. - -The SX cards can theoretically be placed at a 32k boundary. So for -instance you can put an SX card at 0xc8000-0xd7fff. This is not a -"recommended configuration". ISA cards have to tell the bus controller -how they like their timing. Due to timing issues they have to do this -based on which 64k window the address falls into. This means that the -32k window below and above the SX card have to use exactly the same -timing as the SX card. That reportedly works for other SX cards. But -you're still left with two useless 32k windows that should not be used -by anybody else. - - -Configuring the driver -====================== - -PCI cards are always detected. The driver auto-probes for ISA cards at -some sensible addresses. Please report if the auto-probe causes trouble -in your system, or when a card isn't detected. - -I'm afraid I haven't implemented "kernel command line parameters" yet. -This means that if the default doesn't work for you, you shouldn't use -the compiled-into-the-kernel version of the driver. Use a module -instead. If you convince me that you need this, I'll make it for -you. Deal? - -I'm afraid that the module parameters are a bit clumsy. If you have a -better idea, please tell me. - -You can specify several parameters: - - sx_poll: number of jiffies between timer-based polls. - - Set this to "0" to disable timer based polls. - Initialization of cards without a working interrupt - will fail. - - Set this to "1" if you want a polling driver. - (on Intel: 100 polls per second). If you don't use - fast baud rates, you might consider a value like "5". - (If you don't know how to do the math, use 1). - - sx_slowpoll: Number of jiffies between timer-based polls. - Set this to "100" to poll once a second. - This should get the card out of a stall if the driver - ever misses an interrupt. I've never seen this happen, - and if it does, that's a bug. Tell me. - - sx_maxints: Number of interrupts to request from the card. - The card normally limits interrupts to about 100 per - second to offload the host CPU. You can increase this - number to reduce latency on the card a little. - Note that if you give a very high number you can overload - your CPU as well as the CPU on the host card. This setting - is inaccurate and not recommended for SI cards (But it - works). - - sx_irqmask: The mask of allowable IRQs to use. I suggest you set - this to 0 (disable IRQs all together) and use polling if - the assignment of IRQs becomes problematic. This is defined - as the sum of (1 << irq) 's that you want to allow. So - sx_irqmask of 8 (1 << 3) specifies that only irq 3 may - be used by the SX driver. If you want to specify to the - driver: "Either irq 11 or 12 is ok for you to use", then - specify (1 << 11) | (1 << 12) = 0x1800 . - - sx_debug: You can enable different sorts of debug traces with this. - At "-1" all debugging traces are active. You'll get several - times more debugging output than you'll get characters - transmitted. - - -Baud rates -========== - -Theoretically new SXDCs should be capable of more than 460k -baud. However the line drivers usually give up before that. Also the -CPU on the card may not be able to handle 8 channels going at full -blast at that speed. Moreover, the buffers are not large enough to -allow operation with 100 interrupts per second. You'll have to realize -that the card has a 256 byte buffer, so you'll have to increase the -number of interrupts per second if you have more than 256*100 bytes -per second to transmit. If you do any performance testing in this -area, I'd be glad to hear from you... - -(Psst Linux users..... I think the Linux driver is more efficient than -the driver for other OSes. If you can and want to benchmark them -against each other, be my guest, and report your findings...... :-) - - -Ports and devices -================= - -Port 0 is the top connector on the module closest to the host -card. Oh, the ports on the SXDCs and TAs are labelled from 1 to 8 -instead of from 0 to 7, as they are numbered by linux. I'm stubborn in -this: I know for sure that I wouldn't be able to calculate which port -is which anymore if I would change that.... - - -Devices: - -You should make the device files as follows: - -#!/bin/sh -# (I recommend that you cut-and-paste this into a file and run that) -cd /dev -t=0 -mknod specialix_sxctl c 10 167 -while [ $t -lt 64 ] - do - echo -n "$t " - mknod ttyX$t c 32 $t - mknod cux$t c 33 $t - t=`expr $t + 1` -done -echo "" -rm /etc/psdevtab -ps > /dev/null - - -This creates 64 devices. If you have more, increase the constant on -the line with "while". The devices start at 0, as is customary on -Linux. Specialix seems to like starting the numbering at 1. - -If your system doesn't come with these devices pre-installed, bug your -linux-vendor about this. They should have these devices -"pre-installed" before the new millennium. The "ps" stuff at the end -is to "tell" ps that the new devices exist. - -Officially the maximum number of cards per computer is 4. This driver -however supports as many cards in one machine as you want. You'll run -out of interrupts after a few, but you can switch to polled operation -then. At about 256 ports (More than 8 cards), we run out of minor -device numbers. Sorry. I suggest you buy a second computer.... (Or -switch to RIO). - ------------------------------------------------------------------------- - - - Fixed bugs and restrictions: - - Hangup processing. - -- Done. - - - the write path in generic_serial (lockup / oops). - -- Done (Ugly: not the way I want it. Copied from serial.c). - - - write buffer isn't flushed at close. - -- Done. I still seem to lose a few chars at close. - Sorry. I think that this is a firmware issue. (-> Specialix) - - - drain hardware before changing termios - - Change debug on the fly. - - ISA free irq -1. (no firmware loaded). - - adding c8000 as a probe address. Added warning. - - Add a RAMtest for the RAM on the card.c - - Crash when opening a port "way" of the number of allowed ports. - (for example opening port 60 when there are only 24 ports attached) - - Sometimes the use-count strays a bit. After a few hours of - testing the use count is sometimes "3". If you are not like - me and can remember what you did to get it that way, I'd - appreciate an Email. Possibly fixed. Tell me if anyone still - sees this. - - TAs don't work right if you don't connect all the modem control - signals. SXDCs do. T225 firmware problem -> Specialix. - (Mostly fixed now, I think. Tell me if you encounter this!) - - Bugs & restrictions: - - - Arbitrary baud rates. Requires firmware update. (-> Specialix) - - - Low latency (mostly firmware, -> Specialix) - - - diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt index b0714d8f678a..cbc2f03056bd 100644 --- a/Documentation/stable_kernel_rules.txt +++ b/Documentation/stable_kernel_rules.txt @@ -39,7 +39,7 @@ Procedure for submitting patches to the -stable tree: the stable tree without anything else needing to be done by the author or subsystem maintainer. - If the patch requires other patches as prerequisites which can be - cherry-picked than this can be specified in the following format in + cherry-picked, then this can be specified in the following format in the sign-off area: Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index ec8be46bf48d..9886c3d57fc2 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt @@ -317,6 +317,7 @@ for more than this value report a warning. This file shows up if CONFIG_DETECT_HUNG_TASK is enabled. 0: means infinite timeout - no checking done. +Possible values to set are in range {0..LONG_MAX/HZ}. ============================================================== @@ -785,6 +786,8 @@ can be ORed together: 1024 - A module from drivers/staging was loaded. 2048 - The system is working around a severe firmware bug. 4096 - An out-of-tree module has been loaded. +8192 - An unsigned module has been loaded in a kernel supporting module + signature. ============================================================== diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index d614a9b6a280..dd9d0e33b443 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt @@ -175,18 +175,39 @@ Setting this to zero disables periodic writeback altogether. drop_caches -Writing to this will cause the kernel to drop clean caches, dentries and -inodes from memory, causing that memory to become free. +Writing to this will cause the kernel to drop clean caches, as well as +reclaimable slab objects like dentries and inodes. Once dropped, their +memory becomes free. To free pagecache: echo 1 > /proc/sys/vm/drop_caches -To free dentries and inodes: +To free reclaimable slab objects (includes dentries and inodes): echo 2 > /proc/sys/vm/drop_caches -To free pagecache, dentries and inodes: +To free slab objects and pagecache: echo 3 > /proc/sys/vm/drop_caches -As this is a non-destructive operation and dirty objects are not freeable, the -user should run `sync' first. +This is a non-destructive operation and will not free any dirty objects. +To increase the number of objects freed by this operation, the user may run +`sync' prior to writing to /proc/sys/vm/drop_caches. This will minimize the +number of dirty objects on the system and create more candidates to be +dropped. + +This file is not a means to control the growth of the various kernel caches +(inodes, dentries, pagecache, etc...) These objects are automatically +reclaimed by the kernel when memory is needed elsewhere on the system. + +Use of this file can cause performance problems. Since it discards cached +objects, it may cost a significant amount of I/O and CPU to recreate the +dropped objects, especially if they were under heavy use. Because of this, +use outside of a testing or debugging environment is not recommended. + +You may see informational messages in your kernel log when this file is +used: + + cat (1234): drop_caches: 3 + +These are informational only. They do not mean that anything is wrong +with your system. To disable them, echo 4 (bit 3) into drop_caches. ============================================================== diff --git a/Documentation/trace/ftrace-design.txt b/Documentation/trace/ftrace-design.txt index 79fcafc7fd64..3f669b9e8852 100644 --- a/Documentation/trace/ftrace-design.txt +++ b/Documentation/trace/ftrace-design.txt @@ -358,11 +358,8 @@ Every arch has an init callback function. If you need to do something early on to initialize some state, this is the time to do that. Otherwise, this simple function below should be sufficient for most people: -int __init ftrace_dyn_arch_init(void *data) +int __init ftrace_dyn_arch_init(void) { - /* return value is done indirectly via data */ - *(unsigned long *)data = 0; - return 0; } diff --git a/Documentation/video4linux/CARDLIST.bttv b/Documentation/video4linux/CARDLIST.bttv index f14475011fea..2f6e93597ce0 100644 --- a/Documentation/video4linux/CARDLIST.bttv +++ b/Documentation/video4linux/CARDLIST.bttv @@ -163,3 +163,4 @@ 162 -> Adlink MPG24 163 -> Bt848 Capture 14MHz 164 -> CyberVision CV06 (SV) +165 -> Kworld V-Stream Xpert TV PVR878 diff --git a/Documentation/video4linux/CARDLIST.cx23885 b/Documentation/video4linux/CARDLIST.cx23885 index 9f056d512e35..fc009d0ee7d6 100644 --- a/Documentation/video4linux/CARDLIST.cx23885 +++ b/Documentation/video4linux/CARDLIST.cx23885 @@ -31,10 +31,13 @@ 30 -> NetUP Dual DVB-T/C-CI RF [1b55:e2e4] 31 -> Leadtek Winfast PxDVR3200 H XC4000 [107d:6f39] 32 -> MPX-885 - 33 -> Mygica X8507 [14f1:8502] + 33 -> Mygica X8502/X8507 ISDB-T [14f1:8502] 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] 38 -> Hauppauge WinTV-HVR4400 [0070:c108,0070:c138,0070:c12a,0070:c1f8] 39 -> AVerTV Hybrid Express Slim HC81R [1461:d939] + 40 -> TurboSight TBS 6981 [6981:8888] + 41 -> TurboSight TBS 6980 [6980:8888] + 42 -> Leadtek Winfast PxPVR2200 [107d:6f21] diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx index e81864405102..e085b1243b45 100644 --- a/Documentation/video4linux/CARDLIST.em28xx +++ b/Documentation/video4linux/CARDLIST.em28xx @@ -57,6 +57,7 @@ 56 -> Pinnacle Hybrid Pro (330e) (em2882) [2304:0226] 57 -> Kworld PlusTV HD Hybrid 330 (em2883) [eb1a:a316] 58 -> Compro VideoMate ForYou/Stereo (em2820/em2840) [185b:2041] + 59 -> Pinnacle PCTV HD Mini (em2874) [2304:023f] 60 -> Hauppauge WinTV HVR 850 (em2883) [2040:651f] 61 -> Pixelview PlayTV Box 4 USB 2.0 (em2820/em2840) 62 -> Gadmei TVR200 (em2820/em2840) @@ -86,3 +87,8 @@ 86 -> PCTV QuatroStick nano (520e) (em2884) [2013:0251] 87 -> Terratec Cinergy HTC USB XS (em2884) [0ccd:008e,0ccd:00ac] 88 -> C3 Tech Digital Duo HDTV/SDTV USB (em2884) [1b80:e755] + 89 -> Delock 61959 (em2874) [1b80:e1cc] + 90 -> KWorld USB ATSC TV Stick UB435-Q V2 (em2874) [1b80:e346] + 91 -> SpeedLink Vicious And Devine Laplace webcam (em2765) [1ae7:9003,1ae7:9004] + 92 -> PCTV DVB-S2 Stick (461e) (em28178) + 93 -> KWorld USB ATSC TV Stick UB435-Q V3 (em2874) [1b80:e34c] diff --git a/Documentation/video4linux/fimc.txt b/Documentation/video4linux/fimc.txt index e51f1b5b7324..7d6e160724bd 100644 --- a/Documentation/video4linux/fimc.txt +++ b/Documentation/video4linux/fimc.txt @@ -151,9 +151,8 @@ CONFIG_S5P_DEV_FIMC1 \ CONFIG_S5P_DEV_FIMC2 | optional CONFIG_S5P_DEV_FIMC3 | CONFIG_S5P_SETUP_FIMC / -CONFIG_S5P_SETUP_MIPIPHY \ -CONFIG_S5P_DEV_CSIS0 | optional for MIPI-CSI interface -CONFIG_S5P_DEV_CSIS1 / +CONFIG_S5P_DEV_CSIS0 \ optional for MIPI-CSI interface +CONFIG_S5P_DEV_CSIS1 / Except that, relevant s5p_device_fimc? should be registered in the machine code in addition to a "s5p-fimc-md" platform device to which the media device driver diff --git a/Documentation/video4linux/gspca.txt b/Documentation/video4linux/gspca.txt index 1e6b6531bbcc..d2ba80bb7af5 100644 --- a/Documentation/video4linux/gspca.txt +++ b/Documentation/video4linux/gspca.txt @@ -55,6 +55,7 @@ zc3xx 0458:700f Genius VideoCam Web V2 sonixj 0458:7025 Genius Eye 311Q sn9c20x 0458:7029 Genius Look 320s sonixj 0458:702e Genius Slim 310 NB +sn9c20x 0458:7045 Genius Look 1320 V2 sn9c20x 0458:704a Genius Slim 1320 sn9c20x 0458:704c Genius i-Look 1321 sn9c20x 045e:00f4 LifeCam VX-6000 (SN9C20x + OV9650) diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt index 6c4866b49eb5..667a43361706 100644 --- a/Documentation/video4linux/v4l2-framework.txt +++ b/Documentation/video4linux/v4l2-framework.txt @@ -34,6 +34,10 @@ So this framework sets up the basic building blocks that all drivers need and this same framework should make it much easier to refactor common code into utility functions shared by all drivers. +A good example to look at as a reference is the v4l2-pci-skeleton.c +source that is available in this directory. It is a skeleton driver for +a PCI capture card, and demonstrates how to use the V4L2 driver +framework. It can be used as a template for real PCI video capture driver. Structure of a driver --------------------- @@ -768,6 +772,7 @@ types exist: VFL_TYPE_GRABBER: videoX for video input/output devices VFL_TYPE_VBI: vbiX for vertical blank data (i.e. closed captions, teletext) VFL_TYPE_RADIO: radioX for radio tuners +VFL_TYPE_SDR: swradioX for Software Defined Radio tuners The last argument gives you a certain amount of control over the device device node number used (i.e. the X in videoX). Normally you will pass -1 diff --git a/Documentation/video4linux/v4l2-pci-skeleton.c b/Documentation/video4linux/v4l2-pci-skeleton.c new file mode 100644 index 000000000000..3a1c0d2dafce --- /dev/null +++ b/Documentation/video4linux/v4l2-pci-skeleton.c @@ -0,0 +1,913 @@ +/* + * This is a V4L2 PCI Skeleton Driver. It gives an initial skeleton source + * for use with other PCI drivers. + * + * This skeleton PCI driver assumes that the card has an S-Video connector as + * input 0 and an HDMI connector as input 1. + * + * Copyright 2014 Cisco Systems, Inc. and/or its affiliates. All rights reserved. + * + * This program is free software; you may redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF + * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS + * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN + * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN + * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE + * SOFTWARE. + */ + +#include <linux/types.h> +#include <linux/kernel.h> +#include <linux/module.h> +#include <linux/init.h> +#include <linux/kmod.h> +#include <linux/mutex.h> +#include <linux/pci.h> +#include <linux/interrupt.h> +#include <linux/videodev2.h> +#include <linux/v4l2-dv-timings.h> +#include <media/v4l2-device.h> +#include <media/v4l2-dev.h> +#include <media/v4l2-ioctl.h> +#include <media/v4l2-dv-timings.h> +#include <media/v4l2-ctrls.h> +#include <media/v4l2-event.h> +#include <media/videobuf2-dma-contig.h> + +MODULE_DESCRIPTION("V4L2 PCI Skeleton Driver"); +MODULE_AUTHOR("Hans Verkuil"); +MODULE_LICENSE("GPL v2"); +MODULE_DEVICE_TABLE(pci, skeleton_pci_tbl); + +/** + * struct skeleton - All internal data for one instance of device + * @pdev: PCI device + * @v4l2_dev: top-level v4l2 device struct + * @vdev: video node structure + * @ctrl_handler: control handler structure + * @lock: ioctl serialization mutex + * @std: current SDTV standard + * @timings: current HDTV timings + * @format: current pix format + * @input: current video input (0 = SDTV, 1 = HDTV) + * @queue: vb2 video capture queue + * @alloc_ctx: vb2 contiguous DMA context + * @qlock: spinlock controlling access to buf_list and sequence + * @buf_list: list of buffers queued for DMA + * @sequence: frame sequence counter + */ +struct skeleton { + struct pci_dev *pdev; + struct v4l2_device v4l2_dev; + struct video_device vdev; + struct v4l2_ctrl_handler ctrl_handler; + struct mutex lock; + v4l2_std_id std; + struct v4l2_dv_timings timings; + struct v4l2_pix_format format; + unsigned input; + + struct vb2_queue queue; + struct vb2_alloc_ctx *alloc_ctx; + + spinlock_t qlock; + struct list_head buf_list; + unsigned int sequence; +}; + +struct skel_buffer { + struct vb2_buffer vb; + struct list_head list; +}; + +static inline struct skel_buffer *to_skel_buffer(struct vb2_buffer *vb2) +{ + return container_of(vb2, struct skel_buffer, vb); +} + +static const struct pci_device_id skeleton_pci_tbl[] = { + /* { PCI_DEVICE(PCI_VENDOR_ID_, PCI_DEVICE_ID_) }, */ + { 0, } +}; + +/* + * HDTV: this structure has the capabilities of the HDTV receiver. + * It is used to constrain the huge list of possible formats based + * upon the hardware capabilities. + */ +static const struct v4l2_dv_timings_cap skel_timings_cap = { + .type = V4L2_DV_BT_656_1120, + /* keep this initialization for compatibility with GCC < 4.4.6 */ + .reserved = { 0 }, + V4L2_INIT_BT_TIMINGS( + 720, 1920, /* min/max width */ + 480, 1080, /* min/max height */ + 27000000, 74250000, /* min/max pixelclock*/ + V4L2_DV_BT_STD_CEA861, /* Supported standards */ + /* capabilities */ + V4L2_DV_BT_CAP_INTERLACED | V4L2_DV_BT_CAP_PROGRESSIVE + ) +}; + +/* + * Supported SDTV standards. This does the same job as skel_timings_cap, but + * for standard TV formats. + */ +#define SKEL_TVNORMS V4L2_STD_ALL + +/* + * Interrupt handler: typically interrupts happen after a new frame has been + * captured. It is the job of the handler to remove the new frame from the + * internal list and give it back to the vb2 framework, updating the sequence + * counter and timestamp at the same time. + */ +static irqreturn_t skeleton_irq(int irq, void *dev_id) +{ +#ifdef TODO + struct skeleton *skel = dev_id; + + /* handle interrupt */ + + /* Once a new frame has been captured, mark it as done like this: */ + if (captured_new_frame) { + ... + spin_lock(&skel->qlock); + list_del(&new_buf->list); + spin_unlock(&skel->qlock); + new_buf->vb.v4l2_buf.sequence = skel->sequence++; + v4l2_get_timestamp(&new_buf->vb.v4l2_buf.timestamp); + vb2_buffer_done(&new_buf->vb, VB2_BUF_STATE_DONE); + } +#endif + return IRQ_HANDLED; +} + +/* + * Setup the constraints of the queue: besides setting the number of planes + * per buffer and the size and allocation context of each plane, it also + * checks if sufficient buffers have been allocated. Usually 3 is a good + * minimum number: many DMA engines need a minimum of 2 buffers in the + * queue and you need to have another available for userspace processing. + */ +static int queue_setup(struct vb2_queue *vq, const struct v4l2_format *fmt, + unsigned int *nbuffers, unsigned int *nplanes, + unsigned int sizes[], void *alloc_ctxs[]) +{ + struct skeleton *skel = vb2_get_drv_priv(vq); + + if (vq->num_buffers + *nbuffers < 3) + *nbuffers = 3 - vq->num_buffers; + + if (fmt && fmt->fmt.pix.sizeimage < skel->format.sizeimage) + return -EINVAL; + *nplanes = 1; + sizes[0] = fmt ? fmt->fmt.pix.sizeimage : skel->format.sizeimage; + alloc_ctxs[0] = skel->alloc_ctx; + return 0; +} + +/* + * Prepare the buffer for queueing to the DMA engine: check and set the + * payload size and fill in the field. Note: if the format's field is + * V4L2_FIELD_ALTERNATE, then vb->v4l2_buf.field should be set in the + * interrupt handler since that's usually where you know if the TOP or + * BOTTOM field has been captured. + */ +static int buffer_prepare(struct vb2_buffer *vb) +{ + struct skeleton *skel = vb2_get_drv_priv(vb->vb2_queue); + unsigned long size = skel->format.sizeimage; + + if (vb2_plane_size(vb, 0) < size) { + dev_err(&skel->pdev->dev, "buffer too small (%lu < %lu)\n", + vb2_plane_size(vb, 0), size); + return -EINVAL; + } + + vb2_set_plane_payload(vb, 0, size); + vb->v4l2_buf.field = skel->format.field; + return 0; +} + +/* + * Queue this buffer to the DMA engine. + */ +static void buffer_queue(struct vb2_buffer *vb) +{ + struct skeleton *skel = vb2_get_drv_priv(vb->vb2_queue); + struct skel_buffer *buf = to_skel_buffer(vb); + unsigned long flags; + + spin_lock_irqsave(&skel->qlock, flags); + list_add_tail(&buf->list, &skel->buf_list); + + /* TODO: Update any DMA pointers if necessary */ + + spin_unlock_irqrestore(&skel->qlock, flags); +} + +static void return_all_buffers(struct skeleton *skel, + enum vb2_buffer_state state) +{ + struct skel_buffer *buf, *node; + unsigned long flags; + + spin_lock_irqsave(&skel->qlock, flags); + list_for_each_entry_safe(buf, node, &skel->buf_list, list) { + vb2_buffer_done(&buf->vb, state); + list_del(&buf->list); + } + spin_unlock_irqrestore(&skel->qlock, flags); +} + +/* + * Start streaming. First check if the minimum number of buffers have been + * queued. If not, then return -ENOBUFS and the vb2 framework will call + * this function again the next time a buffer has been queued until enough + * buffers are available to actually start the DMA engine. + */ +static int start_streaming(struct vb2_queue *vq, unsigned int count) +{ + struct skeleton *skel = vb2_get_drv_priv(vq); + int ret = 0; + + skel->sequence = 0; + + /* TODO: start DMA */ + + if (ret) { + /* + * In case of an error, return all active buffers to the + * QUEUED state + */ + return_all_buffers(skel, VB2_BUF_STATE_QUEUED); + } + return ret; +} + +/* + * Stop the DMA engine. Any remaining buffers in the DMA queue are dequeued + * and passed on to the vb2 framework marked as STATE_ERROR. + */ +static int stop_streaming(struct vb2_queue *vq) +{ + struct skeleton *skel = vb2_get_drv_priv(vq); + + /* TODO: stop DMA */ + + /* Release all active buffers */ + return_all_buffers(skel, VB2_BUF_STATE_ERROR); + return 0; +} + +/* + * The vb2 queue ops. Note that since q->lock is set we can use the standard + * vb2_ops_wait_prepare/finish helper functions. If q->lock would be NULL, + * then this driver would have to provide these ops. + */ +static struct vb2_ops skel_qops = { + .queue_setup = queue_setup, + .buf_prepare = buffer_prepare, + .buf_queue = buffer_queue, + .start_streaming = start_streaming, + .stop_streaming = stop_streaming, + .wait_prepare = vb2_ops_wait_prepare, + .wait_finish = vb2_ops_wait_finish, +}; + +/* + * Required ioctl querycap. Note that the version field is prefilled with + * the version of the kernel. + */ +static int skeleton_querycap(struct file *file, void *priv, + struct v4l2_capability *cap) +{ + struct skeleton *skel = video_drvdata(file); + + strlcpy(cap->driver, KBUILD_MODNAME, sizeof(cap->driver)); + strlcpy(cap->card, "V4L2 PCI Skeleton", sizeof(cap->card)); + snprintf(cap->bus_info, sizeof(cap->bus_info), "PCI:%s", + pci_name(skel->pdev)); + cap->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_READWRITE | + V4L2_CAP_STREAMING; + cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS; + return 0; +} + +/* + * Helper function to check and correct struct v4l2_pix_format. It's used + * not only in VIDIOC_TRY/S_FMT, but also elsewhere if changes to the SDTV + * standard, HDTV timings or the video input would require updating the + * current format. + */ +static void skeleton_fill_pix_format(struct skeleton *skel, + struct v4l2_pix_format *pix) +{ + pix->pixelformat = V4L2_PIX_FMT_YUYV; + if (skel->input == 0) { + /* S-Video input */ + pix->width = 720; + pix->height = (skel->std & V4L2_STD_525_60) ? 480 : 576; + pix->field = V4L2_FIELD_INTERLACED; + pix->colorspace = V4L2_COLORSPACE_SMPTE170M; + } else { + /* HDMI input */ + pix->width = skel->timings.bt.width; + pix->height = skel->timings.bt.height; + if (skel->timings.bt.interlaced) + pix->field = V4L2_FIELD_INTERLACED; + else + pix->field = V4L2_FIELD_NONE; + pix->colorspace = V4L2_COLORSPACE_REC709; + } + + /* + * The YUYV format is four bytes for every two pixels, so bytesperline + * is width * 2. + */ + pix->bytesperline = pix->width * 2; + pix->sizeimage = pix->bytesperline * pix->height; + pix->priv = 0; +} + +static int skeleton_try_fmt_vid_cap(struct file *file, void *priv, + struct v4l2_format *f) +{ + struct skeleton *skel = video_drvdata(file); + struct v4l2_pix_format *pix = &f->fmt.pix; + + /* + * Due to historical reasons providing try_fmt with an unsupported + * pixelformat will return -EINVAL for video receivers. Webcam drivers, + * however, will silently correct the pixelformat. Some video capture + * applications rely on this behavior... + */ + if (pix->pixelformat != V4L2_PIX_FMT_YUYV) + return -EINVAL; + skeleton_fill_pix_format(skel, pix); + return 0; +} + +static int skeleton_s_fmt_vid_cap(struct file *file, void *priv, + struct v4l2_format *f) +{ + struct skeleton *skel = video_drvdata(file); + int ret; + + ret = skeleton_try_fmt_vid_cap(file, priv, f); + if (ret) + return ret; + + /* + * It is not allowed to change the format while buffers for use with + * streaming have already been allocated. + */ + if (vb2_is_busy(&skel->queue)) + return -EBUSY; + + /* TODO: change format */ + skel->format = f->fmt.pix; + return 0; +} + +static int skeleton_g_fmt_vid_cap(struct file *file, void *priv, + struct v4l2_format *f) +{ + struct skeleton *skel = video_drvdata(file); + + f->fmt.pix = skel->format; + return 0; +} + +static int skeleton_enum_fmt_vid_cap(struct file *file, void *priv, + struct v4l2_fmtdesc *f) +{ + if (f->index != 0) + return -EINVAL; + + strlcpy(f->description, "4:2:2, packed, YUYV", sizeof(f->description)); + f->pixelformat = V4L2_PIX_FMT_YUYV; + f->flags = 0; + return 0; +} + +static int skeleton_s_std(struct file *file, void *priv, v4l2_std_id std) +{ + struct skeleton *skel = video_drvdata(file); + + /* S_STD is not supported on the HDMI input */ + if (skel->input) + return -ENODATA; + + /* + * No change, so just return. Some applications call S_STD again after + * the buffers for streaming have been set up, so we have to allow for + * this behavior. + */ + if (std == skel->std) + return 0; + + /* + * Changing the standard implies a format change, which is not allowed + * while buffers for use with streaming have already been allocated. + */ + if (vb2_is_busy(&skel->queue)) + return -EBUSY; + + /* TODO: handle changing std */ + + skel->std = std; + + /* Update the internal format */ + skeleton_fill_pix_format(skel, &skel->format); + return 0; +} + +static int skeleton_g_std(struct file *file, void *priv, v4l2_std_id *std) +{ + struct skeleton *skel = video_drvdata(file); + + /* G_STD is not supported on the HDMI input */ + if (skel->input) + return -ENODATA; + + *std = skel->std; + return 0; +} + +/* + * Query the current standard as seen by the hardware. This function shall + * never actually change the standard, it just detects and reports. + * The framework will initially set *std to tvnorms (i.e. the set of + * supported standards by this input), and this function should just AND + * this value. If there is no signal, then *std should be set to 0. + */ +static int skeleton_querystd(struct file *file, void *priv, v4l2_std_id *std) +{ + struct skeleton *skel = video_drvdata(file); + + /* QUERY_STD is not supported on the HDMI input */ + if (skel->input) + return -ENODATA; + +#ifdef TODO + /* + * Query currently seen standard. Initial value of *std is + * V4L2_STD_ALL. This function should look something like this: + */ + get_signal_info(); + if (no_signal) { + *std = 0; + return 0; + } + /* Use signal information to reduce the number of possible standards */ + if (signal_has_525_lines) + *std &= V4L2_STD_525_60; + else + *std &= V4L2_STD_625_50; +#endif + return 0; +} + +static int skeleton_s_dv_timings(struct file *file, void *_fh, + struct v4l2_dv_timings *timings) +{ + struct skeleton *skel = video_drvdata(file); + + /* S_DV_TIMINGS is not supported on the S-Video input */ + if (skel->input == 0) + return -ENODATA; + + /* Quick sanity check */ + if (!v4l2_valid_dv_timings(timings, &skel_timings_cap, NULL, NULL)) + return -EINVAL; + + /* Check if the timings are part of the CEA-861 timings. */ + if (!v4l2_find_dv_timings_cap(timings, &skel_timings_cap, + 0, NULL, NULL)) + return -EINVAL; + + /* Return 0 if the new timings are the same as the current timings. */ + if (v4l2_match_dv_timings(timings, &skel->timings, 0)) + return 0; + + /* + * Changing the timings implies a format change, which is not allowed + * while buffers for use with streaming have already been allocated. + */ + if (vb2_is_busy(&skel->queue)) + return -EBUSY; + + /* TODO: Configure new timings */ + + /* Save timings */ + skel->timings = *timings; + + /* Update the internal format */ + skeleton_fill_pix_format(skel, &skel->format); + return 0; +} + +static int skeleton_g_dv_timings(struct file *file, void *_fh, + struct v4l2_dv_timings *timings) +{ + struct skeleton *skel = video_drvdata(file); + + /* G_DV_TIMINGS is not supported on the S-Video input */ + if (skel->input == 0) + return -ENODATA; + + *timings = skel->timings; + return 0; +} + +static int skeleton_enum_dv_timings(struct file *file, void *_fh, + struct v4l2_enum_dv_timings *timings) +{ + struct skeleton *skel = video_drvdata(file); + + /* ENUM_DV_TIMINGS is not supported on the S-Video input */ + if (skel->input == 0) + return -ENODATA; + + return v4l2_enum_dv_timings_cap(timings, &skel_timings_cap, + NULL, NULL); +} + +/* + * Query the current timings as seen by the hardware. This function shall + * never actually change the timings, it just detects and reports. + * If no signal is detected, then return -ENOLINK. If the hardware cannot + * lock to the signal, then return -ENOLCK. If the signal is out of range + * of the capabilities of the system (e.g., it is possible that the receiver + * can lock but that the DMA engine it is connected to cannot handle + * pixelclocks above a certain frequency), then -ERANGE is returned. + */ +static int skeleton_query_dv_timings(struct file *file, void *_fh, + struct v4l2_dv_timings *timings) +{ + struct skeleton *skel = video_drvdata(file); + + /* QUERY_DV_TIMINGS is not supported on the S-Video input */ + if (skel->input == 0) + return -ENODATA; + +#ifdef TODO + /* + * Query currently seen timings. This function should look + * something like this: + */ + detect_timings(); + if (no_signal) + return -ENOLINK; + if (cannot_lock_to_signal) + return -ENOLCK; + if (signal_out_of_range_of_capabilities) + return -ERANGE; + + /* Useful for debugging */ + v4l2_print_dv_timings(skel->v4l2_dev.name, "query_dv_timings:", + timings, true); +#endif + return 0; +} + +static int skeleton_dv_timings_cap(struct file *file, void *fh, + struct v4l2_dv_timings_cap *cap) +{ + struct skeleton *skel = video_drvdata(file); + + /* DV_TIMINGS_CAP is not supported on the S-Video input */ + if (skel->input == 0) + return -ENODATA; + *cap = skel_timings_cap; + return 0; +} + +static int skeleton_enum_input(struct file *file, void *priv, + struct v4l2_input *i) +{ + if (i->index > 1) + return -EINVAL; + + i->type = V4L2_INPUT_TYPE_CAMERA; + if (i->index == 0) { + i->std = SKEL_TVNORMS; + strlcpy(i->name, "S-Video", sizeof(i->name)); + i->capabilities = V4L2_IN_CAP_STD; + } else { + i->std = 0; + strlcpy(i->name, "HDMI", sizeof(i->name)); + i->capabilities = V4L2_IN_CAP_DV_TIMINGS; + } + return 0; +} + +static int skeleton_s_input(struct file *file, void *priv, unsigned int i) +{ + struct skeleton *skel = video_drvdata(file); + + if (i > 1) + return -EINVAL; + + /* + * Changing the input implies a format change, which is not allowed + * while buffers for use with streaming have already been allocated. + */ + if (vb2_is_busy(&skel->queue)) + return -EBUSY; + + skel->input = i; + /* + * Update tvnorms. The tvnorms value is used by the core to implement + * VIDIOC_ENUMSTD so it has to be correct. If tvnorms == 0, then + * ENUMSTD will return -ENODATA. + */ + skel->vdev.tvnorms = i ? 0 : SKEL_TVNORMS; + + /* Update the internal format */ + skeleton_fill_pix_format(skel, &skel->format); + return 0; +} + +static int skeleton_g_input(struct file *file, void *priv, unsigned int *i) +{ + struct skeleton *skel = video_drvdata(file); + + *i = skel->input; + return 0; +} + +/* The control handler. */ +static int skeleton_s_ctrl(struct v4l2_ctrl *ctrl) +{ + /*struct skeleton *skel = + container_of(ctrl->handler, struct skeleton, ctrl_handler);*/ + + switch (ctrl->id) { + case V4L2_CID_BRIGHTNESS: + /* TODO: set brightness to ctrl->val */ + break; + case V4L2_CID_CONTRAST: + /* TODO: set contrast to ctrl->val */ + break; + case V4L2_CID_SATURATION: + /* TODO: set saturation to ctrl->val */ + break; + case V4L2_CID_HUE: + /* TODO: set hue to ctrl->val */ + break; + default: + return -EINVAL; + } + return 0; +} + +/* ------------------------------------------------------------------ + File operations for the device + ------------------------------------------------------------------*/ + +static const struct v4l2_ctrl_ops skel_ctrl_ops = { + .s_ctrl = skeleton_s_ctrl, +}; + +/* + * The set of all supported ioctls. Note that all the streaming ioctls + * use the vb2 helper functions that take care of all the locking and + * that also do ownership tracking (i.e. only the filehandle that requested + * the buffers can call the streaming ioctls, all other filehandles will + * receive -EBUSY if they attempt to call the same streaming ioctls). + * + * The last three ioctls also use standard helper functions: these implement + * standard behavior for drivers with controls. + */ +static const struct v4l2_ioctl_ops skel_ioctl_ops = { + .vidioc_querycap = skeleton_querycap, + .vidioc_try_fmt_vid_cap = skeleton_try_fmt_vid_cap, + .vidioc_s_fmt_vid_cap = skeleton_s_fmt_vid_cap, + .vidioc_g_fmt_vid_cap = skeleton_g_fmt_vid_cap, + .vidioc_enum_fmt_vid_cap = skeleton_enum_fmt_vid_cap, + + .vidioc_g_std = skeleton_g_std, + .vidioc_s_std = skeleton_s_std, + .vidioc_querystd = skeleton_querystd, + + .vidioc_s_dv_timings = skeleton_s_dv_timings, + .vidioc_g_dv_timings = skeleton_g_dv_timings, + .vidioc_enum_dv_timings = skeleton_enum_dv_timings, + .vidioc_query_dv_timings = skeleton_query_dv_timings, + .vidioc_dv_timings_cap = skeleton_dv_timings_cap, + + .vidioc_enum_input = skeleton_enum_input, + .vidioc_g_input = skeleton_g_input, + .vidioc_s_input = skeleton_s_input, + + .vidioc_reqbufs = vb2_ioctl_reqbufs, + .vidioc_create_bufs = vb2_ioctl_create_bufs, + .vidioc_querybuf = vb2_ioctl_querybuf, + .vidioc_qbuf = vb2_ioctl_qbuf, + .vidioc_dqbuf = vb2_ioctl_dqbuf, + .vidioc_expbuf = vb2_ioctl_expbuf, + .vidioc_streamon = vb2_ioctl_streamon, + .vidioc_streamoff = vb2_ioctl_streamoff, + + .vidioc_log_status = v4l2_ctrl_log_status, + .vidioc_subscribe_event = v4l2_ctrl_subscribe_event, + .vidioc_unsubscribe_event = v4l2_event_unsubscribe, +}; + +/* + * The set of file operations. Note that all these ops are standard core + * helper functions. + */ +static const struct v4l2_file_operations skel_fops = { + .owner = THIS_MODULE, + .open = v4l2_fh_open, + .release = vb2_fop_release, + .unlocked_ioctl = video_ioctl2, + .read = vb2_fop_read, + .mmap = vb2_fop_mmap, + .poll = vb2_fop_poll, +}; + +/* + * The initial setup of this device instance. Note that the initial state of + * the driver should be complete. So the initial format, standard, timings + * and video input should all be initialized to some reasonable value. + */ +static int skeleton_probe(struct pci_dev *pdev, const struct pci_device_id *ent) +{ + /* The initial timings are chosen to be 720p60. */ + static const struct v4l2_dv_timings timings_def = + V4L2_DV_BT_CEA_1280X720P60; + struct skeleton *skel; + struct video_device *vdev; + struct v4l2_ctrl_handler *hdl; + struct vb2_queue *q; + int ret; + + /* Enable PCI */ + ret = pci_enable_device(pdev); + if (ret) + return ret; + ret = pci_set_dma_mask(pdev, DMA_BIT_MASK(32)); + if (ret) { + dev_err(&pdev->dev, "no suitable DMA available.\n"); + goto disable_pci; + } + + /* Allocate a new instance */ + skel = devm_kzalloc(&pdev->dev, sizeof(struct skeleton), GFP_KERNEL); + if (!skel) + return -ENOMEM; + + /* Allocate the interrupt */ + ret = devm_request_irq(&pdev->dev, pdev->irq, + skeleton_irq, 0, KBUILD_MODNAME, skel); + if (ret) { + dev_err(&pdev->dev, "request_irq failed\n"); + goto disable_pci; + } + skel->pdev = pdev; + + /* Fill in the initial format-related settings */ + skel->timings = timings_def; + skel->std = V4L2_STD_625_50; + skeleton_fill_pix_format(skel, &skel->format); + + /* Initialize the top-level structure */ + ret = v4l2_device_register(&pdev->dev, &skel->v4l2_dev); + if (ret) + goto disable_pci; + + mutex_init(&skel->lock); + + /* Add the controls */ + hdl = &skel->ctrl_handler; + v4l2_ctrl_handler_init(hdl, 4); + v4l2_ctrl_new_std(hdl, &skel_ctrl_ops, + V4L2_CID_BRIGHTNESS, 0, 255, 1, 127); + v4l2_ctrl_new_std(hdl, &skel_ctrl_ops, + V4L2_CID_CONTRAST, 0, 255, 1, 16); + v4l2_ctrl_new_std(hdl, &skel_ctrl_ops, + V4L2_CID_SATURATION, 0, 255, 1, 127); + v4l2_ctrl_new_std(hdl, &skel_ctrl_ops, + V4L2_CID_HUE, -128, 127, 1, 0); + if (hdl->error) { + ret = hdl->error; + goto free_hdl; + } + skel->v4l2_dev.ctrl_handler = hdl; + + /* Initialize the vb2 queue */ + q = &skel->queue; + q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE; + q->io_modes = VB2_MMAP | VB2_DMABUF | VB2_READ; + q->drv_priv = skel; + q->buf_struct_size = sizeof(struct skel_buffer); + q->ops = &skel_qops; + q->mem_ops = &vb2_dma_contig_memops; + q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC; + /* + * Assume that this DMA engine needs to have at least two buffers + * available before it can be started. The start_streaming() op + * won't be called until at least this many buffers are queued up. + */ + q->min_buffers_needed = 2; + /* + * The serialization lock for the streaming ioctls. This is the same + * as the main serialization lock, but if some of the non-streaming + * ioctls could take a long time to execute, then you might want to + * have a different lock here to prevent VIDIOC_DQBUF from being + * blocked while waiting for another action to finish. This is + * generally not needed for PCI devices, but USB devices usually do + * want a separate lock here. + */ + q->lock = &skel->lock; + /* + * Since this driver can only do 32-bit DMA we must make sure that + * the vb2 core will allocate the buffers in 32-bit DMA memory. + */ + q->gfp_flags = GFP_DMA32; + ret = vb2_queue_init(q); + if (ret) + goto free_hdl; + + skel->alloc_ctx = vb2_dma_contig_init_ctx(&pdev->dev); + if (IS_ERR(skel->alloc_ctx)) { + dev_err(&pdev->dev, "Can't allocate buffer context"); + ret = PTR_ERR(skel->alloc_ctx); + goto free_hdl; + } + INIT_LIST_HEAD(&skel->buf_list); + spin_lock_init(&skel->qlock); + + /* Initialize the video_device structure */ + vdev = &skel->vdev; + strlcpy(vdev->name, KBUILD_MODNAME, sizeof(vdev->name)); + /* + * There is nothing to clean up, so release is set to an empty release + * function. The release callback must be non-NULL. + */ + vdev->release = video_device_release_empty; + vdev->fops = &skel_fops, + vdev->ioctl_ops = &skel_ioctl_ops, + /* + * The main serialization lock. All ioctls are serialized by this + * lock. Exception: if q->lock is set, then the streaming ioctls + * are serialized by that separate lock. + */ + vdev->lock = &skel->lock; + vdev->queue = q; + vdev->v4l2_dev = &skel->v4l2_dev; + /* Supported SDTV standards, if any */ + vdev->tvnorms = SKEL_TVNORMS; + /* If this bit is set, then the v4l2 core will provide the support + * for the VIDIOC_G/S_PRIORITY ioctls. This flag will eventually + * go away once all drivers have been converted to use struct v4l2_fh. + */ + set_bit(V4L2_FL_USE_FH_PRIO, &vdev->flags); + video_set_drvdata(vdev, skel); + + ret = video_register_device(vdev, VFL_TYPE_GRABBER, -1); + if (ret) + goto free_ctx; + + dev_info(&pdev->dev, "V4L2 PCI Skeleton Driver loaded\n"); + return 0; + +free_ctx: + vb2_dma_contig_cleanup_ctx(skel->alloc_ctx); +free_hdl: + v4l2_ctrl_handler_free(&skel->ctrl_handler); + v4l2_device_unregister(&skel->v4l2_dev); +disable_pci: + pci_disable_device(pdev); + return ret; +} + +static void skeleton_remove(struct pci_dev *pdev) +{ + struct v4l2_device *v4l2_dev = pci_get_drvdata(pdev); + struct skeleton *skel = container_of(v4l2_dev, struct skeleton, v4l2_dev); + + video_unregister_device(&skel->vdev); + v4l2_ctrl_handler_free(&skel->ctrl_handler); + vb2_dma_contig_cleanup_ctx(skel->alloc_ctx); + v4l2_device_unregister(&skel->v4l2_dev); + pci_disable_device(skel->pdev); +} + +static struct pci_driver skeleton_driver = { + .name = KBUILD_MODNAME, + .probe = skeleton_probe, + .remove = skeleton_remove, + .id_table = skeleton_pci_tbl, +}; + +module_pci_driver(skeleton_driver); diff --git a/Documentation/zh_CN/HOWTO b/Documentation/zh_CN/HOWTO index 6c914aa87e71..54ea24ff63c7 100644 --- a/Documentation/zh_CN/HOWTO +++ b/Documentation/zh_CN/HOWTO @@ -237,7 +237,7 @@ kernel.org网站的pub/linux/kernel/v2.6/目录下找到它。它的开发遵循 如果没有2.6.x.y版本内核存在，那么最新的2.6.x版本内核就相当于是当前的稳定 版内核。 -2.6.x.y版本由“稳定版”小组（邮件地址<stable@kernel.org>）维护，一般隔周发 +2.6.x.y版本由“稳定版”小组（邮件地址<stable@vger.kernel.org>）维护，一般隔周发 布新版本。 内核源码中的Documentation/stable_kernel_rules.txt文件具体描述了可被稳定 diff --git a/Documentation/zh_CN/SubmittingPatches b/Documentation/zh_CN/SubmittingPatches index be0bd4725062..1d3a10f8746b 100644 --- a/Documentation/zh_CN/SubmittingPatches +++ b/Documentation/zh_CN/SubmittingPatches @@ -82,10 +82,6 @@ Documentation/SubmittingDrivers 。 Quilt: http://savannah.nongnu.org/projects/quilt -Andrew Morton 的补丁脚本: -http://userweb.kernel.org/~akpm/stuff/patch-scripts.tar.gz -作为这些脚本的替代，quilt 是值得推荐的补丁管理工具(看上面的链接)。 - 2)描述你的改动。 描述你的改动包含的技术细节。 @@ -394,7 +390,7 @@ Static inline 函数相比宏来说，是好得多的选择。Static inline 函 ---------------- Andrew Morton, "The perfect patch" (tpp). - <http://userweb.kernel.org/~akpm/stuff/tpp.txt> + <http://www.ozlabs.org/~akpm/stuff/tpp.txt> Jeff Garzik, "Linux kernel patch submission format". <http://linux.yyz.us/patch-format.html> @@ -406,7 +402,7 @@ Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer". <http://www.kroah.com/log/2006/01/11/> NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people! - <http://marc.theaimsgroup.com/?l=linux-kernel&m=112112749912944&w=2> + <https://lkml.org/lkml/2005/7/11/336> Kernel Documentation/CodingStyle: <http://sosdg.org/~coywolf/lxr/source/Documentation/CodingStyle> diff --git a/Documentation/zh_CN/io_ordering.txt b/Documentation/zh_CN/io_ordering.txt new file mode 100644 index 000000000000..e592daf4e014 --- /dev/null +++ b/Documentation/zh_CN/io_ordering.txt @@ -0,0 +1,67 @@ +Chinese translated version of Documentation/io_orderings.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. + +Chinese maintainer: Lin Yongting <linyongting@gmail.com> +--------------------------------------------------------------------- +Documentation/io_ordering.txt 的中文翻译 + +如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文 +交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻 +译存在问题，请联系中文版维护者。 + +中文版维护者： 林永听 Lin Yongting <linyongting@gmail.com> +中文版翻译者： 林永听 Lin Yongting <linyongting@gmail.com> +中文版校译者： 林永听 Lin Yongting <linyongting@gmail.com> + + +以下为正文 +--------------------------------------------------------------------- + +在某些平台上，所谓的内存映射I/O是弱顺序。在这些平台上，驱动开发者有责任 +保证I/O内存映射地址的写操作按程序图意的顺序达到设备。通常读取一个“安全” +设备寄存器或桥寄存器，触发IO芯片清刷未处理的写操作到达设备后才处理读操作， +而达到保证目的。驱动程序通常在spinlock保护的临界区退出之前使用这种技术。 +这也可以保证后面的写操作只在前面的写操作之后到达设备（这非常类似于内存 +屏障操作，mb()，不过仅适用于I/O）。 + +假设一个设备驱动程的具体例子： + + ... +CPU A: spin_lock_irqsave(&dev_lock, flags) +CPU A: val = readl(my_status); +CPU A: ... +CPU A: writel(newval, ring_ptr); +CPU A: spin_unlock_irqrestore(&dev_lock, flags) + ... +CPU B: spin_lock_irqsave(&dev_lock, flags) +CPU B: val = readl(my_status); +CPU B: ... +CPU B: writel(newval2, ring_ptr); +CPU B: spin_unlock_irqrestore(&dev_lock, flags) + ... + +上述例子中，设备可能会先接收到newval2的值，然后接收到newval的值，问题就 +发生了。不过很容易通过下面方法来修复： + + ... +CPU A: spin_lock_irqsave(&dev_lock, flags) +CPU A: val = readl(my_status); +CPU A: ... +CPU A: writel(newval, ring_ptr); +CPU A: (void)readl(safe_register); /* 配置寄存器？*/ +CPU A: spin_unlock_irqrestore(&dev_lock, flags) + ... +CPU B: spin_lock_irqsave(&dev_lock, flags) +CPU B: val = readl(my_status); +CPU B: ... +CPU B: writel(newval2, ring_ptr); +CPU B: (void)readl(safe_register); /* 配置寄存器？*/ +CPU B: spin_unlock_irqrestore(&dev_lock, flags) + +在解决方案中，读取safe_register寄存器，触发IO芯片清刷未处理的写操作， +再处理后面的读操作，防止引发数据不一致问题。 diff --git a/Documentation/zh_CN/magic-number.txt b/Documentation/zh_CN/magic-number.txt index 2ebe539f5450..dfb72a5c63e9 100644 --- a/Documentation/zh_CN/magic-number.txt +++ b/Documentation/zh_CN/magic-number.txt @@ -63,8 +63,6 @@ struct tty_ldisc { PG_MAGIC 'P' pg_{read,write}_hdr include/linux/pg.h CMAGIC 0x0111 user include/linux/a.out.h MKISS_DRIVER_MAGIC 0x04bf mkiss_channel drivers/net/mkiss.h -RISCOM8_MAGIC 0x0907 riscom_port drivers/char/riscom8.h -SPECIALIX_MAGIC 0x0907 specialix_port drivers/char/specialix_io8.h HDLC_MAGIC 0x239e n_hdlc drivers/char/n_hdlc.c APM_BIOS_MAGIC 0x4101 apm_user arch/x86/kernel/apm_32.c CYCLADES_MAGIC 0x4359 cyclades_port include/linux/cyclades.h @@ -82,7 +80,6 @@ STRIP_MAGIC 0x5303 strip drivers/net/strip.c X25_ASY_MAGIC 0x5303 x25_asy drivers/net/x25_asy.h SIXPACK_MAGIC 0x5304 sixpack drivers/net/hamradio/6pack.h AX25_MAGIC 0x5316 ax_disp drivers/net/mkiss.h -ESP_MAGIC 0x53ee esp_struct drivers/char/esp.h TTY_MAGIC 0x5401 tty_struct include/linux/tty.h MGSL_MAGIC 0x5401 mgsl_info drivers/char/synclink.c TTY_DRIVER_MAGIC 0x5402 tty_driver include/linux/tty_driver.h @@ -94,13 +91,10 @@ USB_BLUETOOTH_MAGIC 0x6d02 usb_bluetooth drivers/usb/class/bluetty.c RFCOMM_TTY_MAGIC 0x6d02 net/bluetooth/rfcomm/tty.c USB_SERIAL_PORT_MAGIC 0x7301 usb_serial_port drivers/usb/serial/usb-serial.h CG_MAGIC 0x00090255 ufs_cylinder_group include/linux/ufs_fs.h -A2232_MAGIC 0x000a2232 gs_port drivers/char/ser_a2232.h RPORT_MAGIC 0x00525001 r_port drivers/char/rocket_int.h LSEMAGIC 0x05091998 lse drivers/fc4/fc.c GDTIOCTL_MAGIC 0x06030f07 gdth_iowr_str drivers/scsi/gdth_ioctl.h RIEBL_MAGIC 0x09051990 drivers/net/atarilance.c -RIO_MAGIC 0x12345678 gs_port drivers/char/rio/rio_linux.c -SX_MAGIC 0x12345678 gs_port drivers/char/sx.h NBD_REQUEST_MAGIC 0x12560953 nbd_request include/linux/nbd.h RED_MAGIC2 0x170fc2a5 (any) mm/slab.c BAYCOM_MAGIC 0x19730510 baycom_state drivers/net/baycom_epp.c @@ -116,7 +110,6 @@ ISDN_ASYNC_MAGIC 0x49344C01 modem_info include/linux/isdn.h CTC_ASYNC_MAGIC 0x49344C01 ctc_tty_info drivers/s390/net/ctctty.c ISDN_NET_MAGIC 0x49344C02 isdn_net_local_s drivers/isdn/i4l/isdn_net_lib.h SAVEKMSG_MAGIC2 0x4B4D5347 savekmsg arch/*/amiga/config.c -STLI_BOARDMAGIC 0x4bc6c825 stlibrd include/linux/istallion.h CS_STATE_MAGIC 0x4c4f4749 cs_state sound/oss/cs46xx.c SLAB_C_MAGIC 0x4f17a36d kmem_cache mm/slab.c COW_MAGIC 0x4f4f4f4d cow_header_v1 arch/um/drivers/ubd_user.c @@ -127,10 +120,8 @@ SCC_MAGIC 0x52696368 gs_port drivers/char/scc.h SAVEKMSG_MAGIC1 0x53415645 savekmsg arch/*/amiga/config.c GDA_MAGIC 0x58464552 gda arch/mips/include/asm/sn/gda.h RED_MAGIC1 0x5a2cf071 (any) mm/slab.c -STL_PORTMAGIC 0x5a7182c9 stlport include/linux/stallion.h EEPROM_MAGIC_VALUE 0x5ab478d2 lanai_dev drivers/atm/lanai.c HDLCDRV_MAGIC 0x5ac6e778 hdlcdrv_state include/linux/hdlcdrv.h -EPCA_MAGIC 0x5c6df104 channel include/linux/epca.h PCXX_MAGIC 0x5c6df104 channel drivers/char/pcxx.h KV_MAGIC 0x5f4b565f kernel_vars_s arch/mips/include/asm/sn/klkernvars.h I810_STATE_MAGIC 0x63657373 i810_state sound/oss/i810_audio.c @@ -142,17 +133,14 @@ SLOT_MAGIC 0x67267322 slot drivers/hotplug/acpiphp.h LO_MAGIC 0x68797548 nbd_device include/linux/nbd.h OPROFILE_MAGIC 0x6f70726f super_block drivers/oprofile/oprofilefs.h M3_STATE_MAGIC 0x734d724d m3_state sound/oss/maestro3.c -STL_PANELMAGIC 0x7ef621a1 stlpanel include/linux/stallion.h VMALLOC_MAGIC 0x87654320 snd_alloc_track sound/core/memory.c KMALLOC_MAGIC 0x87654321 snd_alloc_track sound/core/memory.c PWC_MAGIC 0x89DC10AB pwc_device drivers/usb/media/pwc.h NBD_REPLY_MAGIC 0x96744668 nbd_reply include/linux/nbd.h -STL_BOARDMAGIC 0xa2267f52 stlbrd include/linux/stallion.h ENI155_MAGIC 0xa54b872d midway_eprom drivers/atm/eni.h SCI_MAGIC 0xbabeface gs_port drivers/char/sh-sci.h CODA_MAGIC 0xC0DAC0DA coda_file_info include/linux/coda_fs_i.h DPMEM_MAGIC 0xc0ffee11 gdt_pci_sram drivers/scsi/gdth.h -STLI_PORTMAGIC 0xe671c7a1 stliport include/linux/istallion.h YAM_MAGIC 0xF10A7654 yam_port drivers/net/hamradio/yam.c CCB_MAGIC 0xf2691ad2 ccb drivers/scsi/ncr53c8xx.c QUEUE_MAGIC_FREE 0xf7e1c9a3 queue_entry drivers/scsi/arm/queue.c diff --git a/Documentation/zh_CN/stable_kernel_rules.txt b/Documentation/zh_CN/stable_kernel_rules.txt index b5b9b0ab02fd..26ea5ed7cd9c 100644 --- a/Documentation/zh_CN/stable_kernel_rules.txt +++ b/Documentation/zh_CN/stable_kernel_rules.txt @@ -42,7 +42,7 @@ Documentation/stable_kernel_rules.txt 的中文翻译 向稳定版代码树提交补丁的过程： - - 在确认了补丁符合以上的规则后，将补丁发送到stable@kernel.org。 + - 在确认了补丁符合以上的规则后，将补丁发送到stable@vger.kernel.org。 - 如果补丁被接受到队列里，发送者会收到一个ACK回复，如果没有被接受，收 到的是NAK回复。回复需要几天的时间，这取决于开发者的时间安排。 - 被接受的补丁会被加到稳定版本队列里，等待其他开发者的审查。 |