diff options
Diffstat (limited to 'Documentation')
102 files changed, 2241 insertions, 1235 deletions
diff --git a/Documentation/ABI/testing/sysfs-driver-st b/Documentation/ABI/testing/sysfs-driver-st new file mode 100644 index 000000000000..ba5d77008a85 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-st @@ -0,0 +1,12 @@ +What: /sys/bus/scsi/drivers/st/debug_flag +Date: October 2015 +Kernel Version: ?.? +Contact: shane.seymour@hpe.com +Description: + This file allows you to turn debug output from the st driver + off if you write a '0' to the file or on if you write a '1'. + Note that debug output requires that the module be compiled + with the #define DEBUG set to a non-zero value (this is the + default). If DEBUG is set to 0 then this file will not + appear in sysfs as its presence is conditional upon debug + output support being compiled into the module. diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt index 8d065d6ec956..1e98a7e6bccc 100644 --- a/Documentation/DMA-API.txt +++ b/Documentation/DMA-API.txt @@ -142,19 +142,6 @@ Part Ic - DMA addressing limitations ------------------------------------ int -dma_supported(struct device *dev, u64 mask) - -Checks to see if the device can support DMA to the memory described by -mask. - -Returns: 1 if it can and 0 if it can't. - -Notes: This routine merely tests to see if the mask is possible. It -won't change the current mask settings. It is more intended as an -internal API for use by the platform than an external API for use by -driver writers. - -int dma_set_mask_and_coherent(struct device *dev, u64 mask) Checks to see if the mask is possible and updates the device diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index d2544961b67a..91f6d89bb19f 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -14,7 +14,7 @@ DOCBOOKS := z8530book.xml device-drivers.xml \ genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \ 80211.xml debugobjects.xml sh.xml regulator.xml \ alsa-driver-api.xml writing-an-alsa-driver.xml \ - tracepoint.xml drm.xml media_api.xml w1.xml \ + tracepoint.xml gpu.xml media_api.xml w1.xml \ writing_musb_glue_layer.xml crypto-API.xml iio.xml include Documentation/DocBook/media/Makefile diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/gpu.tmpl index 9ddf8c6cb887..201dcd3c2e9d 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/gpu.tmpl @@ -2,9 +2,9 @@ <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []> -<book id="drmDevelopersGuide"> +<book id="gpuDevelopersGuide"> <bookinfo> - <title>Linux DRM Developer's Guide</title> + <title>Linux GPU Driver Developer's Guide</title> <authorgroup> <author> @@ -40,6 +40,16 @@ </address> </affiliation> </author> + <author> + <firstname>Lukas</firstname> + <surname>Wunner</surname> + <contrib>vga_switcheroo documentation</contrib> + <affiliation> + <address> + <email>lukas@wunner.de</email> + </address> + </affiliation> + </author> </authorgroup> <copyright> @@ -51,6 +61,10 @@ <year>2012</year> <holder>Laurent Pinchart</holder> </copyright> + <copyright> + <year>2015</year> + <holder>Lukas Wunner</holder> + </copyright> <legalnotice> <para> @@ -69,6 +83,13 @@ <revremark>Added extensive documentation about driver internals. </revremark> </revision> + <revision> + <revnumber>1.1</revnumber> + <date>2015-10-11</date> + <authorinitials>LW</authorinitials> + <revremark>Added vga_switcheroo documentation. + </revremark> + </revision> </revhistory> </bookinfo> @@ -78,9 +99,9 @@ <title>DRM Core</title> <partintro> <para> - This first part of the DRM Developer's Guide documents core DRM code, - helper libraries for writing drivers and generic userspace interfaces - exposed by DRM drivers. + This first part of the GPU Driver Developer's Guide documents core DRM + code, helper libraries for writing drivers and generic userspace + interfaces exposed by DRM drivers. </para> </partintro> @@ -138,14 +159,10 @@ <para> At the core of every DRM driver is a <structname>drm_driver</structname> structure. Drivers typically statically initialize a drm_driver structure, - and then pass it to one of the <function>drm_*_init()</function> functions - to register it with the DRM subsystem. - </para> - <para> - Newer drivers that no longer require a <structname>drm_bus</structname> - structure can alternatively use the low-level device initialization and - registration functions such as <function>drm_dev_alloc()</function> and - <function>drm_dev_register()</function> directly. + and then pass it to <function>drm_dev_alloc()</function> to allocate a + device instance. After the device instance is fully initialized it can be + registered (which makes it accessible from userspace) using + <function>drm_dev_register()</function>. </para> <para> The <structname>drm_driver</structname> structure contains static @@ -296,83 +313,12 @@ char *date;</synopsis> </sect3> </sect2> <sect2> - <title>Device Registration</title> - <para> - A number of functions are provided to help with device registration. - The functions deal with PCI and platform devices, respectively. - </para> -!Edrivers/gpu/drm/drm_pci.c -!Edrivers/gpu/drm/drm_platform.c - <para> - New drivers that no longer rely on the services provided by the - <structname>drm_bus</structname> structure can call the low-level - device registration functions directly. The - <function>drm_dev_alloc()</function> function can be used to allocate - and initialize a new <structname>drm_device</structname> structure. - Drivers will typically want to perform some additional setup on this - structure, such as allocating driver-specific data and storing a - pointer to it in the DRM device's <structfield>dev_private</structfield> - field. Drivers should also set the device's unique name using the - <function>drm_dev_set_unique()</function> function. After it has been - set up a device can be registered with the DRM subsystem by calling - <function>drm_dev_register()</function>. This will cause the device to - be exposed to userspace and will call the driver's - <structfield>.load()</structfield> implementation. When a device is - removed, the DRM device can safely be unregistered and freed by calling - <function>drm_dev_unregister()</function> followed by a call to - <function>drm_dev_unref()</function>. - </para> + <title>Device Instance and Driver Handling</title> +!Pdrivers/gpu/drm/drm_drv.c driver instance overview !Edrivers/gpu/drm/drm_drv.c </sect2> <sect2> <title>Driver Load</title> - <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, 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 - vertical blanking handling (<xref linkend="drm-vertical-blank"/>), mode - setting (<xref linkend="drm-mode-setting"/>) and initial output - configuration (<xref linkend="drm-kms-init"/>). - </para> - <note><para> - If compatibility is a concern (e.g. with drivers converted over from - User Mode Setting to Kernel Mode Setting), care must be taken to prevent - device initialization and control that is incompatible with currently - active userspace drivers. For instance, if user level mode setting - drivers are in use, it would be problematic to perform output discovery - & configuration at load time. Likewise, if user-level drivers - unaware of memory management are in use, memory management and command - buffer setup may need to be omitted. These requirements are - driver-specific, and care needs to be taken to keep both old and new - applications and libraries working. - </para></note> - <synopsis>int (*load) (struct drm_device *, unsigned long flags);</synopsis> - <para> - The method takes two arguments, a pointer to the newly created - <structname>drm_device</structname> and flags. The flags are used to - pass the <structfield>driver_data</structfield> field of the device id - corresponding to the device passed to <function>drm_*_init()</function>. - Only PCI devices currently use this, USB and platform DRM drivers have - their <methodname>load</methodname> method called with flags to 0. - </para> - <sect3> - <title>Driver Private Data</title> - <para> - The driver private hangs off the main - <structname>drm_device</structname> structure and can be used for - tracking various device-specific bits of information, like register - offsets, command buffer status, register state for suspend/resume, etc. - At load time, a driver may simply allocate one and set - <structname>drm_device</structname>.<structfield>dev_priv</structfield> - appropriately; it should be freed and - <structname>drm_device</structname>.<structfield>dev_priv</structfield> - set to NULL when the driver is unloaded. - </para> - </sect3> <sect3 id="drm-irq-registration"> <title>IRQ Registration</title> <para> @@ -465,6 +411,18 @@ char *date;</synopsis> </para> </sect3> </sect2> + <sect2> + <title>Bus-specific Device Registration and PCI Support</title> + <para> + A number of functions are provided to help with device registration. + The functions deal with PCI and platform devices respectively and are + only provided for historical reasons. These are all deprecated and + shouldn't be used in new drivers. Besides that there's a few + helpers for pci drivers. + </para> +!Edrivers/gpu/drm/drm_pci.c +!Edrivers/gpu/drm/drm_platform.c + </sect2> </sect1> <!-- Internals: memory management --> @@ -3646,10 +3604,11 @@ void (*postclose) (struct drm_device *, struct drm_file *);</synopsis> plane properties to default value, so that a subsequent open of the device will not inherit state from the previous user. It can also be used to execute delayed power switching state changes, e.g. in - conjunction with the vga-switcheroo infrastructure. Beyond that KMS - drivers should not do any further cleanup. Only legacy UMS drivers might - need to clean up device state so that the vga console or an independent - fbdev driver could take over. + conjunction with the vga_switcheroo infrastructure (see + <xref linkend="vga_switcheroo"/>). Beyond that KMS drivers should not + do any further cleanup. Only legacy UMS drivers might need to clean up + device state so that the vga console or an independent fbdev driver + could take over. </para> </sect2> <sect2> @@ -3747,11 +3706,14 @@ int num_ioctls;</synopsis> </para></listitem> <listitem><para> DRM_UNLOCKED - The ioctl handler will be called without locking - the DRM global mutex + the DRM global mutex. This is the enforced default for kms drivers + (i.e. using the DRIVER_MODESET flag) and hence shouldn't be used + any more for new drivers. </para></listitem> </itemizedlist> </para> </para> +!Edrivers/gpu/drm/drm_ioctl.c </sect2> </sect1> <sect1> @@ -3949,8 +3911,8 @@ int num_ioctls;</synopsis> <partintro> <para> - This second part of the DRM Developer's Guide documents driver code, - implementation details and also all the driver-specific userspace + This second part of the GPU Driver 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 @@ -4051,6 +4013,7 @@ int num_ioctls;</synopsis> <title>High Definition Audio</title> !Pdrivers/gpu/drm/i915/intel_audio.c High Definition Audio over HDMI and Display Port !Idrivers/gpu/drm/i915/intel_audio.c +!Iinclude/drm/i915_component.h </sect2> <sect2> <title>Panel Self Refresh PSR (PSR/SRD)</title> @@ -4238,6 +4201,20 @@ int num_ioctls;</synopsis> </sect2> </sect1> <sect1> + <title>GuC-based Command Submission</title> + <sect2> + <title>GuC</title> +!Pdrivers/gpu/drm/i915/intel_guc_loader.c GuC-specific firmware loader +!Idrivers/gpu/drm/i915/intel_guc_loader.c + </sect2> + <sect2> + <title>GuC Client</title> +!Pdrivers/gpu/drm/i915/i915_guc_submission.c GuC-based command submissison +!Idrivers/gpu/drm/i915/i915_guc_submission.c + </sect2> + </sect1> + + <sect1> <title> Tracing </title> <para> This sections covers all things related to the tracepoints implemented in @@ -4260,4 +4237,50 @@ int num_ioctls;</synopsis> </chapter> !Cdrivers/gpu/drm/i915/i915_irq.c </part> + +<part id="vga_switcheroo"> + <title>vga_switcheroo</title> + <partintro> +!Pdrivers/gpu/vga/vga_switcheroo.c Overview + </partintro> + + <chapter id="modes_of_use"> + <title>Modes of Use</title> + <sect1> + <title>Manual switching and manual power control</title> +!Pdrivers/gpu/vga/vga_switcheroo.c Manual switching and manual power control + </sect1> + <sect1> + <title>Driver power control</title> +!Pdrivers/gpu/vga/vga_switcheroo.c Driver power control + </sect1> + </chapter> + + <chapter id="pubfunctions"> + <title>Public functions</title> +!Edrivers/gpu/vga/vga_switcheroo.c + </chapter> + + <chapter id="pubstructures"> + <title>Public structures</title> +!Finclude/linux/vga_switcheroo.h vga_switcheroo_handler +!Finclude/linux/vga_switcheroo.h vga_switcheroo_client_ops + </chapter> + + <chapter id="pubconstants"> + <title>Public constants</title> +!Finclude/linux/vga_switcheroo.h vga_switcheroo_client_id +!Finclude/linux/vga_switcheroo.h vga_switcheroo_state + </chapter> + + <chapter id="privstructures"> + <title>Private structures</title> +!Fdrivers/gpu/vga/vga_switcheroo.c vgasr_priv +!Fdrivers/gpu/vga/vga_switcheroo.c vga_switcheroo_client + </chapter> + +!Cdrivers/gpu/vga/vga_switcheroo.c +!Cinclude/linux/vga_switcheroo.h +</part> + </book> diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 4710e4afef19..d603fa078235 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -718,8 +718,21 @@ generates appropriate diffstats by default.) See more details on the proper patch format in the following references. +15) Explicit In-Reply-To headers +-------------------------------- + +It can be helpful to manually add In-Reply-To: headers to a patch +(e.g., when using "git send email") to associate the patch with +previous relevant discussion, e.g. to link a bug fix to the email with +the bug report. However, for a multi-patch series, it is generally +best to avoid using In-Reply-To: to link to older versions of the +series. This way multiple versions of the patch don't become an +unmanageable forest of references in email clients. If a link is +helpful, you can use the https://lkml.kernel.org/ redirector (e.g., in +the cover email text) to link to an earlier version of the patch series. + -15) Sending "git pull" requests +16) Sending "git pull" requests ------------------------------- If you have a series of patches, it may be most convenient to have the diff --git a/Documentation/acpi/i2c-muxes.txt b/Documentation/acpi/i2c-muxes.txt new file mode 100644 index 000000000000..9fcc4f0b885e --- /dev/null +++ b/Documentation/acpi/i2c-muxes.txt @@ -0,0 +1,58 @@ +ACPI I2C Muxes +-------------- + +Describing an I2C device hierarchy that includes I2C muxes requires an ACPI +Device () scope per mux channel. + +Consider this topology: + ++------+ +------+ +| SMB1 |-->| MUX0 |--CH00--> i2c client A (0x50) +| | | 0x70 |--CH01--> i2c client B (0x50) ++------+ +------+ + +which corresponds to the following ASL: + +Device (SMB1) +{ + Name (_HID, ...) + Device (MUX0) + { + Name (_HID, ...) + Name (_CRS, ResourceTemplate () { + I2cSerialBus (0x70, ControllerInitiated, I2C_SPEED, + AddressingMode7Bit, "^SMB1", 0x00, + ResourceConsumer,,) + } + + Device (CH00) + { + Name (_ADR, 0) + + Device (CLIA) + { + Name (_HID, ...) + Name (_CRS, ResourceTemplate () { + I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED, + AddressingMode7Bit, "^CH00", 0x00, + ResourceConsumer,,) + } + } + } + + Device (CH01) + { + Name (_ADR, 1) + + Device (CLIB) + { + Name (_HID, ...) + Name (_CRS, ResourceTemplate () { + I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED, + AddressingMode7Bit, "^CH01", 0x00, + ResourceConsumer,,) + } + } + } + } +} diff --git a/Documentation/arm/Samsung/Bootloader-interface.txt b/Documentation/arm/Samsung/Bootloader-interface.txt index df8d4fb85939..ed494ac0beb2 100644 --- a/Documentation/arm/Samsung/Bootloader-interface.txt +++ b/Documentation/arm/Samsung/Bootloader-interface.txt @@ -19,7 +19,7 @@ executing kernel. Address: sysram_ns_base_addr Offset Value Purpose ============================================================================= -0x08 exynos_cpu_resume_ns System suspend +0x08 exynos_cpu_resume_ns, mcpm_entry_point System suspend 0x0c 0x00000bad (Magic cookie) System suspend 0x1c exynos4_secondary_startup Secondary CPU boot 0x1c + 4*cpu exynos4_secondary_startup (Exynos4412) Secondary CPU boot @@ -56,7 +56,8 @@ Offset Value Purpose Address: pmu_base_addr Offset Value Purpose ============================================================================= -0x0908 Non-zero (only Exynos3250) Secondary CPU boot up indicator +0x0908 Non-zero Secondary CPU boot up indicator + on Exynos3250 and Exynos542x 4. Glossary diff --git a/Documentation/arm/keystone/knav-qmss.txt b/Documentation/arm/keystone/knav-qmss.txt new file mode 100644 index 000000000000..fcdb9fd5f53a --- /dev/null +++ b/Documentation/arm/keystone/knav-qmss.txt @@ -0,0 +1,56 @@ +* Texas Instruments Keystone Navigator Queue Management SubSystem driver + +Driver source code path + drivers/soc/ti/knav_qmss.c + drivers/soc/ti/knav_qmss_acc.c + +The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of +the main hardware sub system which forms the backbone of the Keystone +multi-core Navigator. QMSS consist of queue managers, packed-data structure +processors(PDSP), linking RAM, descriptor pools and infrastructure +Packet DMA. +The Queue Manager is a hardware module that is responsible for accelerating +management of the packet queues. Packets are queued/de-queued by writing or +reading descriptor address to a particular memory mapped location. The PDSPs +perform QMSS related functions like accumulation, QoS, or event management. +Linking RAM registers are used to link the descriptors which are stored in +descriptor RAM. Descriptor RAM is configurable as internal or external memory. +The QMSS driver manages the PDSP setups, linking RAM regions, +queue pool management (allocation, push, pop and notify) and descriptor +pool management. + +knav qmss driver provides a set of APIs to drivers to open/close qmss queues, +allocate descriptor pools, map the descriptors, push/pop to queues etc. For +details of the available APIs, please refers to include/linux/soc/ti/knav_qmss.h + +DT documentation is available at +Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt + +Accumulator QMSS queues using PDSP firmware +============================================ +The QMSS PDSP firmware support accumulator channel that can monitor a single +queue or multiple contiguous queues. drivers/soc/ti/knav_qmss_acc.c is the +driver that interface with the accumulator PDSP. This configures +accumulator channels defined in DTS (example in DT documentation) to monitor +1 or 32 queues per channel. More description on the firmware is available in +CPPI/QMSS Low Level Driver document (docs/CPPI_QMSS_LLD_SDS.pdf) at + git://git.ti.com/keystone-rtos/qmss-lld.git + +k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin firmware supports upto 48 accumulator +channels. This firmware is available under ti-keystone folder of +firmware.git at + git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git + +To use copy the firmware image to lib/firmware folder of the initramfs or +ubifs file system and provide a sym link to k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin +in the file system and boot up the kernel. User would see + + "firmware file ks2_qmss_pdsp_acc48.bin downloaded for PDSP" + +in the boot up log if loading of firmware to PDSP is successful. + +Use of accumulated queues requires the firmware image to be present in the +file system. The driver doesn't acc queues to the supported queue range if +PDSP is not running in the SoC. The API call fails if there is a queue open +request to an acc queue and PDSP is not running. So make sure to copy firmware +to file system before using these queue types. diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README index 5e38e1582f95..430d279a8df3 100644 --- a/Documentation/arm/sunxi/README +++ b/Documentation/arm/sunxi/README @@ -25,7 +25,7 @@ SunXi family + Datasheet http://dl.linux-sunxi.org/A10s/A10s%20Datasheet%20-%20v1.20%20%282012-03-27%29.pdf - - Allwinner A13 (sun5i) + - Allwinner A13 / R8 (sun5i) + Datasheet http://dl.linux-sunxi.org/A13/A13%20Datasheet%20-%20v1.12%20%282012-03-29%29.pdf + User Manual diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt index 973884a1bacf..1dfee20eee74 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.txt +++ b/Documentation/devicetree/bindings/arm/amlogic.txt @@ -9,6 +9,12 @@ Boards with the Amlogic Meson8 SoC shall have the following properties: Required root node property: compatible: "amlogic,meson8"; +Boards with the Amlogic Meson8b SoC shall have the following properties: + Required root node property: + compatible: "amlogic,meson8b"; + Board compatible values: - - "geniatech,atv1200" - - "minix,neo-x8" + - "geniatech,atv1200" (Meson6) + - "minix,neo-x8" (Meson8) + - "tronfy,mxq" (Meson8b) + - "hardkernel,odroid-c1" (Meson8b) diff --git a/Documentation/devicetree/bindings/arm/apm/scu.txt b/Documentation/devicetree/bindings/arm/apm/scu.txt new file mode 100644 index 000000000000..b45be06625fd --- /dev/null +++ b/Documentation/devicetree/bindings/arm/apm/scu.txt @@ -0,0 +1,17 @@ +APM X-GENE SoC series SCU Registers + +This system clock unit contain various register that control block resets, +clock enable/disables, clock divisors and other deepsleep registers. + +Properties: + - compatible : should contain two values. First value must be: + - "apm,xgene-scu" + second value must be always "syscon". + + - reg : offset and length of the register set. + +Example : + scu: system-clk-controller@17000000 { + compatible = "apm,xgene-scu","syscon"; + reg = <0x0 0x17000000 0x0 0x400>; + }; diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt new file mode 100644 index 000000000000..86302de67c2c --- /dev/null +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt @@ -0,0 +1,188 @@ +System Control and Power Interface (SCPI) Message Protocol +---------------------------------------------------------- + +Firmware implementing the SCPI described in ARM document number ARM DUI 0922B +("ARM Compute Subsystem SCP: Message Interface Protocols")[0] can be used +by Linux to initiate various system control and power operations. + +Required properties: + +- compatible : should be "arm,scpi" +- mboxes: List of phandle and mailbox channel specifiers + All the channels reserved by remote SCP firmware for use by + SCPI message protocol should be specified in any order +- shmem : List of phandle pointing to the shared memory(SHM) area between the + processors using these mailboxes for IPC, one for each mailbox + SHM can be any memory reserved for the purpose of this communication + between the processors. + +See Documentation/devicetree/bindings/mailbox/mailbox.txt +for more details about the generic mailbox controller and +client driver bindings. + +Clock bindings for the clocks based on SCPI Message Protocol +------------------------------------------------------------ + +This binding uses the common clock binding[1]. + +Container Node +============== +Required properties: +- compatible : should be "arm,scpi-clocks" + All the clocks provided by SCP firmware via SCPI message + protocol much be listed as sub-nodes under this node. + +Sub-nodes +========= +Required properties: +- compatible : shall include one of the following + "arm,scpi-dvfs-clocks" - all the clocks that are variable and index based. + These clocks don't provide an entire range of values between the + limits but only discrete points within the range. The firmware + provides the mapping for each such operating frequency and the + index associated with it. The firmware also manages the + voltage scaling appropriately with the clock scaling. + "arm,scpi-variable-clocks" - all the clocks that are variable and provide full + range within the specified range. The firmware provides the + range of values within a specified range. + +Other required properties for all clocks(all from common clock binding): +- #clock-cells : Should be 1. Contains the Clock ID value used by SCPI commands. +- clock-output-names : shall be the corresponding names of the outputs. +- clock-indices: The identifying number for the clocks(i.e.clock_id) in the + node. It can be non linear and hence provide the mapping of identifiers + into the clock-output-names array. + +SRAM and Shared Memory for SCPI +------------------------------- + +A small area of SRAM is reserved for SCPI communication between application +processors and SCP. + +Required properties: +- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM on Juno + +The rest of the properties should follow the generic mmio-sram description +found in ../../misc/sysram.txt + +Each sub-node represents the reserved area for SCPI. + +Required sub-node properties: +- reg : The base offset and size of the reserved area with the SRAM +- compatible : should be "arm,juno-scp-shmem" for Non-secure SRAM based + shared memory on Juno platforms + +Sensor bindings for the sensors based on SCPI Message Protocol +-------------------------------------------------------------- +SCPI provides an API to access the various sensors on the SoC. + +Required properties: +- compatible : should be "arm,scpi-sensors". +- #thermal-sensor-cells: should be set to 1. This property follows the + thermal device tree bindings[2]. + + Valid cell values are raw identifiers (Sensor + ID) as used by the firmware. Refer to + platform documentation for your + implementation for the IDs to use. For Juno + R0 and Juno R1 refer to [3]. + +[0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt +[2] Documentation/devicetree/bindings/thermal/thermal.txt +[3] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/apas03s22.html + +Example: + +sram: sram@50000000 { + compatible = "arm,juno-sram-ns", "mmio-sram"; + reg = <0x0 0x50000000 0x0 0x10000>; + + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x0 0x50000000 0x10000>; + + cpu_scp_lpri: scp-shmem@0 { + compatible = "arm,juno-scp-shmem"; + reg = <0x0 0x200>; + }; + + cpu_scp_hpri: scp-shmem@200 { + compatible = "arm,juno-scp-shmem"; + reg = <0x200 0x200>; + }; +}; + +mailbox: mailbox0@40000000 { + .... + #mbox-cells = <1>; +}; + +scpi_protocol: scpi@2e000000 { + compatible = "arm,scpi"; + mboxes = <&mailbox 0 &mailbox 1>; + shmem = <&cpu_scp_lpri &cpu_scp_hpri>; + + clocks { + compatible = "arm,scpi-clocks"; + + scpi_dvfs: scpi_clocks@0 { + compatible = "arm,scpi-dvfs-clocks"; + #clock-cells = <1>; + clock-indices = <0>, <1>, <2>; + clock-output-names = "atlclk", "aplclk","gpuclk"; + }; + scpi_clk: scpi_clocks@3 { + compatible = "arm,scpi-variable-clocks"; + #clock-cells = <1>; + clock-indices = <3>, <4>; + clock-output-names = "pxlclk0", "pxlclk1"; + }; + }; + + scpi_sensors0: sensors { + compatible = "arm,scpi-sensors"; + #thermal-sensor-cells = <1>; + }; +}; + +cpu@0 { + ... + reg = <0 0>; + clocks = <&scpi_dvfs 0>; +}; + +hdlcd@7ff60000 { + ... + reg = <0 0x7ff60000 0 0x1000>; + clocks = <&scpi_clk 4>; +}; + +thermal-zones { + soc_thermal { + polling-delay-passive = <100>; + polling-delay = <1000>; + + /* sensor ID */ + thermal-sensors = <&scpi_sensors0 3>; + ... + }; +}; + +In the above example, the #clock-cells is set to 1 as required. +scpi_dvfs has 3 output clocks namely: atlclk, aplclk, and gpuclk with 0, +1 and 2 as clock-indices. scpi_clk has 2 output clocks namely: pxlclk0 +and pxlclk1 with 3 and 4 as clock-indices. + +The first consumer in the example is cpu@0 and it has '0' as the clock +specifier which points to the first entry in the output clocks of +scpi_dvfs i.e. "atlclk". + +Similarly the second example is hdlcd@7ff60000 and it has pxlclk1 as input +clock. '4' in the clock specifier here points to the second entry +in the output clocks of scpi_clocks i.e. "pxlclk1" + +The thermal-sensors property in the soc_thermal node uses the +temperature sensor provided by SCP firmware to setup a thermal +zone. The ID "3" is the sensor identifier for the temperature sensor +as used by the firmware. diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt b/Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt index 430608ec09f0..0d0c1ae81bed 100644 --- a/Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt @@ -20,6 +20,25 @@ system control is required: - compatible: "brcm,bcm<chip_id>-hif-cpubiuctrl", "syscon" - compatible: "brcm,bcm<chip_id>-hif-continuation", "syscon" +hif-cpubiuctrl node +------------------- +SoCs with Broadcom Brahma15 ARM-based CPUs have a specific Bus Interface Unit +(BIU) block which controls and interfaces the CPU complex to the different +Memory Controller Ports (MCP), one per memory controller (MEMC). This BIU block +offers a feature called Write Pairing which consists in collapsing two adjacent +cache lines into a single (bursted) write transaction towards the memory +controller (MEMC) to maximize write bandwidth. + +Required properties: + + - compatible: must be "brcm,bcm7445-hif-cpubiuctrl", "syscon" + +Optional properties: + + - brcm,write-pairing: + Boolean property, which when present indicates that the chip + supports write-pairing. + example: rdb { #address-cells = <1>; @@ -35,6 +54,7 @@ example: hif_cpubiuctrl: syscon@3e2400 { compatible = "brcm,bcm7445-hif-cpubiuctrl", "syscon"; reg = <0x3e2400 0x5b4>; + brcm,write-pairing; }; hif_continuation: syscon@452000 { @@ -43,8 +63,7 @@ example: }; }; -Lastly, nodes that allow for support of SMP initialization and reboot are -required: +Nodes that allow for support of SMP initialization and reboot are required: smpboot ------- @@ -95,3 +114,142 @@ example: compatible = "brcm,brcmstb-reboot"; syscon = <&sun_top_ctrl 0x304 0x308>; }; + + + +Power management +---------------- + +For power management (particularly, S2/S3/S5 system suspend), the following SoC +components are needed: + += Always-On control block (AON CTRL) + +This hardware provides control registers for the "always-on" (even in low-power +modes) hardware, such as the Power Management State Machine (PMSM). + +Required properties: +- compatible : should contain "brcm,brcmstb-aon-ctrl" +- reg : the register start and length for the AON CTRL block + +Example: + +aon-ctrl@410000 { + compatible = "brcm,brcmstb-aon-ctrl"; + reg = <0x410000 0x400>; +}; + += Memory controllers + +A Broadcom STB SoC typically has a number of independent memory controllers, +each of which may have several associated hardware blocks, which are versioned +independently (control registers, DDR PHYs, etc.). One might consider +describing these controllers as a parent "memory controllers" block, which +contains N sub-nodes (one for each controller in the system), each of which is +associated with a number of hardware register resources (e.g., its PHY). See +the example device tree snippet below. + +== MEMC (MEMory Controller) + +Represents a single memory controller instance. + +Required properties: +- compatible : should contain "brcm,brcmstb-memc" and "simple-bus" + +Should contain subnodes for any of the following relevant hardware resources: + +== DDR PHY control + +Control registers for this memory controller's DDR PHY. + +Required properties: +- compatible : should contain one of these + "brcm,brcmstb-ddr-phy-v225.1" + "brcm,brcmstb-ddr-phy-v240.1" + "brcm,brcmstb-ddr-phy-v240.2" + +- reg : the DDR PHY register range + +== DDR SHIMPHY + +Control registers for this memory controller's DDR SHIMPHY. + +Required properties: +- compatible : should contain "brcm,brcmstb-ddr-shimphy-v1.0" +- reg : the DDR SHIMPHY register range + +== MEMC DDR control + +Sequencer DRAM parameters and control registers. Used for Self-Refresh +Power-Down (SRPD), among other things. + +Required properties: +- compatible : should contain "brcm,brcmstb-memc-ddr" +- reg : the MEMC DDR register range + +Example: + +memory_controllers { + ranges; + compatible = "simple-bus"; + + memc@0 { + compatible = "brcm,brcmstb-memc", "simple-bus"; + ranges; + + ddr-phy@f1106000 { + compatible = "brcm,brcmstb-ddr-phy-v240.1"; + reg = <0xf1106000 0x21c>; + }; + + shimphy@f1108000 { + compatible = "brcm,brcmstb-ddr-shimphy-v1.0"; + reg = <0xf1108000 0xe4>; + }; + + memc-ddr@f1102000 { + reg = <0xf1102000 0x800>; + compatible = "brcm,brcmstb-memc-ddr"; + }; + }; + + memc@1 { + compatible = "brcm,brcmstb-memc", "simple-bus"; + ranges; + + ddr-phy@f1186000 { + compatible = "brcm,brcmstb-ddr-phy-v240.1"; + reg = <0xf1186000 0x21c>; + }; + + shimphy@f1188000 { + compatible = "brcm,brcmstb-ddr-shimphy-v1.0"; + reg = <0xf1188000 0xe4>; + }; + + memc-ddr@f1182000 { + reg = <0xf1182000 0x800>; + compatible = "brcm,brcmstb-memc-ddr"; + }; + }; + + memc@2 { + compatible = "brcm,brcmstb-memc", "simple-bus"; + ranges; + + ddr-phy@f1206000 { + compatible = "brcm,brcmstb-ddr-phy-v240.1"; + reg = <0xf1206000 0x21c>; + }; + + shimphy@f1208000 { + compatible = "brcm,brcmstb-ddr-shimphy-v1.0"; + reg = <0xf1208000 0xe4>; + }; + + memc-ddr@f1202000 { + reg = <0xf1202000 0x800>; + compatible = "brcm,brcmstb-memc-ddr"; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,nsp.txt b/Documentation/devicetree/bindings/arm/bcm/brcm,nsp.txt new file mode 100644 index 000000000000..eae53e4556be --- /dev/null +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,nsp.txt @@ -0,0 +1,34 @@ +Broadcom Northstar Plus device tree bindings +-------------------------------------------- + +Broadcom Northstar Plus family of SoCs are used for switching control +and management applications as well as residential router/gateway +applications. The SoC features dual core Cortex A9 ARM CPUs, integrating +several peripheral interfaces including multiple Gigabit Ethernet PHYs, +DDR3 memory, PCIE Gen-2, USB 2.0 and USB 3.0, serial and NAND flash, +SATA and several other IO controllers. + +Boards with Northstar Plus SoCs shall have the following properties: + +Required root node property: + +BCM58522 +compatible = "brcm,bcm58522", "brcm,nsp"; + +BCM58525 +compatible = "brcm,bcm58525", "brcm,nsp"; + +BCM58535 +compatible = "brcm,bcm58535", "brcm,nsp"; + +BCM58622 +compatible = "brcm,bcm58622", "brcm,nsp"; + +BCM58623 +compatible = "brcm,bcm58623", "brcm,nsp"; + +BCM58625 +compatible = "brcm,bcm58625", "brcm,nsp"; + +BCM88312 +compatible = "brcm,bcm88312", "brcm,nsp"; diff --git a/Documentation/devicetree/bindings/arm/coherency-fabric.txt b/Documentation/devicetree/bindings/arm/coherency-fabric.txt index 8dd46617c889..9b5c3f620e65 100644 --- a/Documentation/devicetree/bindings/arm/coherency-fabric.txt +++ b/Documentation/devicetree/bindings/arm/coherency-fabric.txt @@ -27,6 +27,11 @@ Required properties: * For "marvell,armada-380-coherency-fabric", only one pair is needed for the per-CPU fabric registers. +Optional properties: + +- broken-idle: boolean to set when the Idle mode is not supported by the + hardware. + Examples: coherency-fabric@d0020200 { diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index 91e6e5c478d0..3a07a87fef20 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -195,6 +195,8 @@ nodes to be present and contain the properties described below. "marvell,armada-380-smp" "marvell,armada-390-smp" "marvell,armada-xp-smp" + "mediatek,mt6589-smp" + "mediatek,mt81xx-tz-smp" "qcom,gcc-msm8660" "qcom,kpss-acc-v1" "qcom,kpss-acc-v2" diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt index 2a3ba73f0c5c..34c88b0c7ab4 100644 --- a/Documentation/devicetree/bindings/arm/fsl.txt +++ b/Documentation/devicetree/bindings/arm/fsl.txt @@ -128,10 +128,18 @@ Example: reg = <0x0 0x1ee0000 0x0 0x10000>; }; -Freescale LS2085A SoC Device Tree Bindings ------------------------------------------- +Freescale ARMv8 based Layerscape SoC family Device Tree Bindings +---------------------------------------------------------------- -LS2085A ARMv8 based Simulator model +LS2080A ARMv8 based Simulator model Required root node properties: - - compatible = "fsl,ls2085a-simu", "fsl,ls2085a"; + - compatible = "fsl,ls2080a-simu", "fsl,ls2080a"; + +LS2080A ARMv8 based QDS Board +Required root node properties: + - compatible = "fsl,ls2080a-qds", "fsl,ls2080a"; + +LS2080A ARMv8 based RDB Board +Required root node properties: + - compatible = "fsl,ls2080a-rdb", "fsl,ls2080a"; diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt index 764c738bb3ba..6ac7c000af22 100644 --- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt +++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt @@ -20,6 +20,10 @@ HiKey Board Required root node properties: - compatible = "hisilicon,hi6220-hikey", "hisilicon,hi6220"; +HiP05 D02 Board +Required root node properties: + - compatible = "hisilicon,hip05-d02"; + Hisilicon system controller Required properties: diff --git a/Documentation/devicetree/bindings/arm/keystone/keystone.txt b/Documentation/devicetree/bindings/arm/keystone/keystone.txt index 59d7a46f85eb..3090a8a008c0 100644 --- a/Documentation/devicetree/bindings/arm/keystone/keystone.txt +++ b/Documentation/devicetree/bindings/arm/keystone/keystone.txt @@ -9,12 +9,26 @@ Required properties: the form "ti,keystone-*". Generic devices like gic, arch_timers, ns16550 type UART should use the specified compatible for those devices. +SoC families: + +- Keystone 2 generic SoC: + compatible = "ti,keystone" + +SoCs: + +- Keystone 2 Hawking/Kepler + compatible = "ti,k2hk", "ti,keystone" +- Keystone 2 Lamarr + compatible = "ti,k2l", "ti,keystone" +- Keystone 2 Edison + compatible = "ti,k2e", "ti,keystone" + Boards: - Keystone 2 Hawking/Kepler EVM - compatible = "ti,k2hk-evm","ti,keystone" + compatible = "ti,k2hk-evm", "ti,k2hk", "ti,keystone" - Keystone 2 Lamarr EVM - compatible = "ti,k2l-evm","ti,keystone" + compatible = "ti,k2l-evm", "ti, k2l", "ti,keystone" - Keystone 2 Edison EVM - compatible = "ti,k2e-evm","ti,keystone" + compatible = "ti,k2e-evm", "ti,k2e", "ti,keystone" diff --git a/Documentation/devicetree/bindings/arm/mvebu-cpu-config.txt b/Documentation/devicetree/bindings/arm/mvebu-cpu-config.txt new file mode 100644 index 000000000000..2cdcd716da40 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mvebu-cpu-config.txt @@ -0,0 +1,20 @@ +MVEBU CPU Config registers +-------------------------- + +MVEBU (Marvell SOCs: Armada 370/XP) + +Required properties: + +- compatible: one of: + - "marvell,armada-370-cpu-config" + - "marvell,armada-xp-cpu-config" + +- reg: Should contain CPU config registers location and length, in + their per-CPU variant + +Example: + + cpu-config@21000 { + compatible = "marvell,armada-xp-cpu-config"; + reg = <0x21000 0x8>; + }; diff --git a/Documentation/devicetree/bindings/arm/pmu.txt b/Documentation/devicetree/bindings/arm/pmu.txt index 4b7c3d9b29bb..97ba45af04fc 100644 --- a/Documentation/devicetree/bindings/arm/pmu.txt +++ b/Documentation/devicetree/bindings/arm/pmu.txt @@ -7,6 +7,7 @@ representation in the device tree should be done as under:- Required properties: - compatible : should be one of + "apm,potenza-pmu" "arm,armv8-pmuv3" "arm.cortex-a57-pmu" "arm.cortex-a53-pmu" diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt index 5aa40ede0e99..a9adab84e2fe 100644 --- a/Documentation/devicetree/bindings/arm/psci.txt +++ b/Documentation/devicetree/bindings/arm/psci.txt @@ -31,6 +31,10 @@ Main node required properties: support, but are permitted to be present for compatibility with existing software when "arm,psci" is later in the compatible list. + * "arm,psci-1.0" : for implementations complying to PSCI 1.0. PSCI 1.0 is + backward compatible with PSCI 0.2 with minor specification updates, + as defined in the PSCI specification[2]. + - method : The method of calling the PSCI firmware. Permitted values are: @@ -100,3 +104,5 @@ Case 3: PSCI v0.2 and PSCI v0.1. [1] Kernel documentation - ARM idle states bindings Documentation/devicetree/bindings/arm/idle-states.txt +[2] Power State Coordination Interface (PSCI) specification + http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt index af58cd74aeff..8e985dd2f181 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.txt +++ b/Documentation/devicetree/bindings/arm/rockchip.txt @@ -17,6 +17,10 @@ Rockchip platforms device tree bindings Required root node properties: - compatible = "radxa,rock", "rockchip,rk3188"; +- Radxa Rock2 Square board: + Required root node properties: + - compatible = "radxa,rock2-square", "rockchip,rk3288"; + - Firefly Firefly-RK3288 board: Required root node properties: - compatible = "firefly,firefly-rk3288", "rockchip,rk3288"; @@ -31,6 +35,13 @@ Rockchip platforms device tree bindings Required root node properties: - compatible = "netxeon,r89", "rockchip,rk3288"; +- Google Jaq (Haier Chromebook 11 and more): + Required root node properties: + - compatible = "google,veyron-jaq-rev5", "google,veyron-jaq-rev4", + "google,veyron-jaq-rev3", "google,veyron-jaq-rev2", + "google,veyron-jaq-rev1", "google,veyron-jaq", + "google,veyron", "rockchip,rk3288"; + - Google Jerry (Hisense Chromebook C11 and more): Required root node properties: - compatible = "google,veyron-jerry-rev7", "google,veyron-jerry-rev6", diff --git a/Documentation/devicetree/bindings/arm/samsung-boards.txt b/Documentation/devicetree/bindings/arm/samsung-boards.txt deleted file mode 100644 index 43589d2466a7..000000000000 --- a/Documentation/devicetree/bindings/arm/samsung-boards.txt +++ /dev/null @@ -1,27 +0,0 @@ -* Samsung's Exynos SoC based boards - -Required root node properties: - - compatible = should be one or more of the following. - - "samsung,monk" - for Exynos3250-based Samsung Simband board. - - "samsung,rinato" - for Exynos3250-based Samsung Gear2 board. - - "samsung,smdkv310" - for Exynos4210-based Samsung SMDKV310 eval board. - - "samsung,trats" - for Exynos4210-based Tizen Reference board. - - "samsung,universal_c210" - for Exynos4210-based Samsung board. - - "samsung,smdk4412", - for Exynos4412-based Samsung SMDK4412 eval board. - - "samsung,trats2" - for Exynos4412-based Tizen Reference board. - - "samsung,smdk5250" - for Exynos5250-based Samsung SMDK5250 eval board. - - "samsung,xyref5260" - for Exynos5260-based Samsung board. - - "samsung,smdk5410" - for Exynos5410-based Samsung SMDK5410 eval board. - - "samsung,smdk5420" - for Exynos5420-based Samsung SMDK5420 eval board. - - "samsung,sd5v1" - for Exynos5440-based Samsung board. - - "samsung,ssdk5440" - for Exynos5440-based Samsung board. - -Optional: - - firmware node, specifying presence and type of secure firmware: - - compatible: only "samsung,secure-firmware" is currently supported - - reg: address of non-secure SYSRAM used for communication with firmware - - firmware@0203F000 { - compatible = "samsung,secure-firmware"; - reg = <0x0203F000 0x1000>; - }; diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt new file mode 100644 index 000000000000..12129c011c8f --- /dev/null +++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt @@ -0,0 +1,69 @@ +* Samsung's Exynos SoC based boards + +Required root node properties: + - compatible = should be one or more of the following. + - "samsung,monk" - for Exynos3250-based Samsung Simband board. + - "samsung,rinato" - for Exynos3250-based Samsung Gear2 board. + - "samsung,smdkv310" - for Exynos4210-based Samsung SMDKV310 eval board. + - "samsung,trats" - for Exynos4210-based Tizen Reference board. + - "samsung,universal_c210" - for Exynos4210-based Samsung board. + - "samsung,smdk4412", - for Exynos4412-based Samsung SMDK4412 eval board. + - "samsung,trats2" - for Exynos4412-based Tizen Reference board. + - "samsung,smdk5250" - for Exynos5250-based Samsung SMDK5250 eval board. + - "samsung,xyref5260" - for Exynos5260-based Samsung board. + - "samsung,smdk5410" - for Exynos5410-based Samsung SMDK5410 eval board. + - "samsung,smdk5420" - for Exynos5420-based Samsung SMDK5420 eval board. + - "samsung,sd5v1" - for Exynos5440-based Samsung board. + - "samsung,ssdk5440" - for Exynos5440-based Samsung board. + +* Other companies Exynos SoC based + * FriendlyARM + - "friendlyarm,tiny4412" - for Exynos4412-based FriendlyARM + TINY4412 board. + + * Google + - "google,pi" - for Exynos5800-based Google Peach Pi + Rev 10+ board, + also: "google,pi-rev16", "google,pi-rev15", "google,pi-rev14", + "google,pi-rev13", "google,pi-rev12", "google,pi-rev11", + "google,pi-rev10", "google,peach". + + - "google,pit" - for Exynos5420-based Google Peach Pit + Rev 6+ (Exynos5420), + also: "google,pit-rev16", "google,pit-rev15", "google,pit-rev14", + "google,pit-rev13", "google,pit-rev12", "google,pit-rev11", + "google,pit-rev10", "google,pit-rev9", "google,pit-rev8", + "google,pit-rev7", "google,pit-rev6", "google,peach". + + - "google,snow-rev4" - for Exynos5250-based Google Snow board, + also: "google,snow" + - "google,snow-rev5" - for Exynos5250-based Google Snow + Rev 5+ board. + - "google,spring" - for Exynos5250-based Google Spring board. + + * Hardkernel + - "hardkernel,odroid-u3" - for Exynos4412-based Hardkernel Odroid U3. + - "hardkernel,odroid-x" - for Exynos4412-based Hardkernel Odroid X. + - "hardkernel,odroid-x2" - for Exynos4412-based Hardkernel Odroid X2. + - "hardkernel,odroid-xu3" - for Exynos5422-based Hardkernel Odroid XU3. + - "hardkernel,odroid-xu3-lite" - for Exynos5422-based Hardkernel + Odroid XU3 Lite board. + - "hardkernel,odroid-xu4" - for Exynos5422-based Hardkernel Odroid XU4. + + * Insignal + - "insignal,arndale" - for Exynos5250-based Insignal Arndale board. + - "insignal,arndale-octa" - for Exynos5420-based Insignal Arndale + Octa board. + - "insignal,origen" - for Exynos4210-based Insignal Origen board. + - "insignal,origen4412 - for Exynos4412-based Insignal Origen board. + + +Optional nodes: + - firmware node, specifying presence and type of secure firmware: + - compatible: only "samsung,secure-firmware" is currently supported + - reg: address of non-secure SYSRAM used for communication with firmware + + firmware@0203F000 { + compatible = "samsung,secure-firmware"; + reg = <0x0203F000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt index c4f19b2e7dd9..40bb9007cd0d 100644 --- a/Documentation/devicetree/bindings/arm/shmobile.txt +++ b/Documentation/devicetree/bindings/arm/shmobile.txt @@ -39,8 +39,6 @@ Boards: compatible = "renesas,armadillo800eva" - BOCK-W compatible = "renesas,bockw", "renesas,r8a7778" - - BOCK-W - Reference Device Tree Implementation - compatible = "renesas,bockw-reference", "renesas,r8a7778" - Genmai (RTK772100BC00000BR) compatible = "renesas,genmai", "renesas,r7s72100" - Gose @@ -57,7 +55,7 @@ Boards: compatible = "renesas,lager", "renesas,r8a7790" - Marzen compatible = "renesas,marzen", "renesas,r8a7779" - -Note: Reference Device Tree Implementations are temporary implementations - to ease the migration from platform devices to Device Tree, and are - intended to be removed in the future. + - Porter (M2-LCDP) + compatible = "renesas,porter", "renesas,r8a7791" + - SILK (RTP0RC7794LCB00011S) + compatible = "renesas,silk", "renesas,r8a7794" diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt index 67da20539540..bb9b0faa919d 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.txt +++ b/Documentation/devicetree/bindings/arm/sunxi.txt @@ -6,6 +6,7 @@ using one of the following compatible strings: allwinner,sun4i-a10 allwinner,sun5i-a10s allwinner,sun5i-a13 + allwinner,sun5i-r8 allwinner,sun6i-a31 allwinner,sun7i-a20 allwinner,sun8i-a23 diff --git a/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt new file mode 100644 index 000000000000..d27a646f48a9 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt @@ -0,0 +1,60 @@ +UniPhier outer cache controller + +UniPhier SoCs are integrated with a full-custom outer cache controller system. +All of them have a level 2 cache controller, and some have a level 3 cache +controller as well. + +Required properties: +- compatible: should be "socionext,uniphier-system-cache" +- reg: offsets and lengths of the register sets for the device. It should + contain 3 regions: control register, revision register, operation register, + in this order. +- cache-unified: specifies the cache is a unified cache. +- cache-size: specifies the size in bytes of the cache +- cache-sets: specifies the number of associativity sets of the cache +- cache-line-size: specifies the line size in bytes +- cache-level: specifies the level in the cache hierarchy. The value should + be 2 for L2 cache, 3 for L3 cache, etc. + +Optional properties: +- next-level-cache: phandle to the next level cache if present. The next level + cache should be also compatible with "socionext,uniphier-system-cache". + +The L2 cache must exist to use the L3 cache; the cache hierarchy must be +indicated correctly with "next-level-cache" properties. + +Example 1 (system with L2): + l2: l2-cache@500c0000 { + compatible = "socionext,uniphier-system-cache"; + reg = <0x500c0000 0x2000>, <0x503c0100 0x4>, + <0x506c0000 0x400>; + cache-unified; + cache-size = <0x80000>; + cache-sets = <256>; + cache-line-size = <128>; + cache-level = <2>; + }; + +Example 2 (system with L2 and L3): + l2: l2-cache@500c0000 { + compatible = "socionext,uniphier-system-cache"; + reg = <0x500c0000 0x2000>, <0x503c0100 0x8>, + <0x506c0000 0x400>; + cache-unified; + cache-size = <0x200000>; + cache-sets = <512>; + cache-line-size = <128>; + cache-level = <2>; + next-level-cache = <&l3>; + }; + + l3: l3-cache@500c8000 { + compatible = "socionext,uniphier-system-cache"; + reg = <0x500c8000 0x2000>, <0x503c8100 0x8>, + <0x506c8000 0x400>; + cache-unified; + cache-size = <0x400000>; + cache-sets = <512>; + cache-line-size = <256>; + cache-level = <3>; + }; diff --git a/Documentation/devicetree/bindings/powerpc/fsl/board.txt b/Documentation/devicetree/bindings/board/fsl-board.txt index cff38bdbc0e4..fb7b03ec2071 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt +++ b/Documentation/devicetree/bindings/board/fsl-board.txt @@ -21,11 +21,14 @@ Example: This is the memory-mapped registers for on board FPGA. -Required properities: +Required properties: - compatible: should be a board-specific string followed by a string indicating the type of FPGA. Example: - "fsl,<board>-fpga", "fsl,fpga-pixis" + "fsl,<board>-fpga", "fsl,fpga-pixis", or + "fsl,<board>-fpga", "fsl,fpga-qixis" - reg: should contain the address and the length of the FPGA register set. + +Optional properties: - interrupt-parent: should specify phandle for the interrupt controller. - interrupts: should specify event (wakeup) IRQ. @@ -38,6 +41,13 @@ Example (P1022DS): interrupts = <8 8 0 0>; }; +Example (LS2080A-RDB): + + cpld@3,0 { + compatible = "fsl,ls2080ardb-fpga", "fsl,fpga-qixis"; + reg = <0x3 0 0x10000>; + }; + * Freescale BCSR GPIO banks Some BCSR registers act as simple GPIO controllers, each such diff --git a/Documentation/devicetree/bindings/bus/sunxi-rsb.txt b/Documentation/devicetree/bindings/bus/sunxi-rsb.txt new file mode 100644 index 000000000000..3dd28343b6ce --- /dev/null +++ b/Documentation/devicetree/bindings/bus/sunxi-rsb.txt @@ -0,0 +1,47 @@ +Allwinner Reduced Serial Bus (RSB) controller + +The RSB controller found on later Allwinner SoCs is an SMBus like 2 wire +serial bus with 1 master and up to 15 slaves. It is represented by a node +for the controller itself, and child nodes representing the slave devices. + +Required properties : + + - reg : Offset and length of the register set for the controller. + - compatible : Shall be "allwinner,sun8i-a23-rsb". + - interrupts : The interrupt line associated to the RSB controller. + - clocks : The gate clk associated to the RSB controller. + - resets : The reset line associated to the RSB controller. + - #address-cells : shall be 1 + - #size-cells : shall be 0 + +Optional properties : + + - clock-frequency : Desired RSB bus clock frequency in Hz. Maximum is 20MHz. + If not set this defaults to 3MHz. + +Child nodes: + +An RSB controller node can contain zero or more child nodes representing +slave devices on the bus. Child 'reg' properties should contain the slave +device's hardware address. The hardware address is hardwired in the device, +which can normally be found in the datasheet. + +Example: + + rsb@01f03400 { + compatible = "allwinner,sun8i-a23-rsb"; + reg = <0x01f03400 0x400>; + interrupts = <0 39 4>; + clocks = <&apb0_gates 3>; + clock-frequency = <3000000>; + resets = <&apb0_rst 3>; + #address-cells = <1>; + #size-cells = <0>; + + pmic@3e3 { + compatible = "..."; + reg = <0x3e3>; + + /* ... */ + }; + }; diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt b/Documentation/devicetree/bindings/clock/qcom,gcc.txt index 54c23f34f194..152dfaab2575 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt +++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt @@ -18,10 +18,14 @@ Required properties : - #clock-cells : shall contain 1 - #reset-cells : shall contain 1 +Optional properties : +- #power-domain-cells : shall contain 1 + Example: clock-controller@900000 { compatible = "qcom,gcc-msm8960"; reg = <0x900000 0x4000>; #clock-cells = <1>; #reset-cells = <1>; + #power-domain-cells = <1>; }; diff --git a/Documentation/devicetree/bindings/clock/qcom,mmcc.txt b/Documentation/devicetree/bindings/clock/qcom,mmcc.txt index 29ebf84d25af..34e7614d5074 100644 --- a/Documentation/devicetree/bindings/clock/qcom,mmcc.txt +++ b/Documentation/devicetree/bindings/clock/qcom,mmcc.txt @@ -14,10 +14,14 @@ Required properties : - #clock-cells : shall contain 1 - #reset-cells : shall contain 1 +Optional properties : +- #power-domain-cells : shall contain 1 + Example: clock-controller@4000000 { compatible = "qcom,mmcc-msm8960"; reg = <0x4000000 0x1000>; #clock-cells = <1>; #reset-cells = <1>; + #power-domain-cells = <1>; }; diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt new file mode 100644 index 000000000000..56a961aa5061 --- /dev/null +++ b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt @@ -0,0 +1,65 @@ +Broadcom VC4 (VideoCore4) GPU + +The VC4 device present on the Raspberry Pi includes a display system +with HDMI output and the HVS (Hardware Video Scaler) for compositing +display planes. + +Required properties for VC4: +- compatible: Should be "brcm,bcm2835-vc4" + +Required properties for Pixel Valve: +- compatible: Should be one of "brcm,bcm2835-pixelvalve0", + "brcm,bcm2835-pixelvalve1", or "brcm,bcm2835-pixelvalve2" +- reg: Physical base address and length of the PV's registers +- interrupts: The interrupt number + See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt + +Required properties for HVS: +- compatible: Should be "brcm,bcm2835-hvs" +- reg: Physical base address and length of the HVS's registers +- interrupts: The interrupt number + See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt + +Required properties for HDMI +- compatible: Should be "brcm,bcm2835-hdmi" +- reg: Physical base address and length of the two register ranges + ("HDMI" and "HD", in that order) +- interrupts: The interrupt numbers + See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt +- ddc: phandle of the I2C controller used for DDC EDID probing +- clocks: a) hdmi: The HDMI state machine clock + b) pixel: The pixel clock. + +Optional properties for HDMI: +- hpd-gpios: The GPIO pin for HDMI hotplug detect (if it doesn't appear + as an interrupt/status bit in the HDMI controller + itself). See bindings/pinctrl/brcm,bcm2835-gpio.txt + +Example: +pixelvalve@7e807000 { + compatible = "brcm,bcm2835-pixelvalve2"; + reg = <0x7e807000 0x100>; + interrupts = <2 10>; /* pixelvalve */ +}; + +hvs@7e400000 { + compatible = "brcm,bcm2835-hvs"; + reg = <0x7e400000 0x6000>; + interrupts = <2 1>; +}; + +hdmi: hdmi@7e902000 { + compatible = "brcm,bcm2835-hdmi"; + reg = <0x7e902000 0x600>, + <0x7e808000 0x100>; + interrupts = <2 8>, <2 9>; + ddc = <&i2c2>; + hpd-gpios = <&gpio 46 GPIO_ACTIVE_HIGH>; + clocks = <&clocks BCM2835_PLLH_PIX>, + <&clocks BCM2835_CLOCK_HSM>; + clock-names = "pixel", "hdmi"; +}; + +vc4: gpu { + compatible = "brcm,bcm2835-vc4"; +}; diff --git a/Documentation/devicetree/bindings/display/msm/hdmi.txt b/Documentation/devicetree/bindings/display/msm/hdmi.txt index e926239e1101..379ee2ea9a3d 100644 --- a/Documentation/devicetree/bindings/display/msm/hdmi.txt +++ b/Documentation/devicetree/bindings/display/msm/hdmi.txt @@ -2,6 +2,7 @@ Qualcomm adreno/snapdragon hdmi output Required properties: - compatible: one of the following + * "qcom,hdmi-tx-8996" * "qcom,hdmi-tx-8994" * "qcom,hdmi-tx-8084" * "qcom,hdmi-tx-8974" @@ -21,6 +22,7 @@ Required properties: Optional properties: - qcom,hdmi-tx-mux-en-gpio: hdmi mux enable pin - qcom,hdmi-tx-mux-sel-gpio: hdmi mux select pin +- power-domains: reference to the power domain(s), if available. - pinctrl-names: the pin control state names; should contain "default" - pinctrl-0: the default pinctrl state (active) - pinctrl-1: the "sleep" pinctrl state @@ -35,6 +37,7 @@ Example: reg-names = "core_physical"; reg = <0x04a00000 0x1000>; interrupts = <GIC_SPI 79 0>; + power-domains = <&mmcc MDSS_GDSC>; clock-names = "core_clk", "master_iface_clk", diff --git a/Documentation/devicetree/bindings/display/msm/mdp.txt b/Documentation/devicetree/bindings/display/msm/mdp.txt index 1a0598e5279d..0833edaba4c3 100644 --- a/Documentation/devicetree/bindings/display/msm/mdp.txt +++ b/Documentation/devicetree/bindings/display/msm/mdp.txt @@ -11,13 +11,14 @@ Required properties: - clock-names: the following clocks are required: * "core_clk" * "iface_clk" - * "lut_clk" * "src_clk" * "hdmi_clk" * "mpd_clk" Optional properties: - gpus: phandle for gpu device +- clock-names: the following clocks are optional: + * "lut_clk" Example: diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt b/Documentation/devicetree/bindings/display/renesas,du.txt index c902323928f7..eccd4f4867b2 100644 --- a/Documentation/devicetree/bindings/display/renesas,du.txt +++ b/Documentation/devicetree/bindings/display/renesas,du.txt @@ -5,7 +5,9 @@ Required Properties: - compatible: must be one of the following. - "renesas,du-r8a7779" for R8A7779 (R-Car H1) compatible DU - "renesas,du-r8a7790" for R8A7790 (R-Car H2) compatible DU - - "renesas,du-r8a7791" for R8A7791 (R-Car M2) compatible DU + - "renesas,du-r8a7791" for R8A7791 (R-Car M2-W) compatible DU + - "renesas,du-r8a7793" for R8A7793 (R-Car M2-N) compatible DU + - "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU - reg: A list of base address and length of each memory resource, one for each entry in the reg-names property. @@ -22,9 +24,9 @@ Required Properties: - clock-names: Name of the clocks. This property is model-dependent. - R8A7779 uses a single functional clock. The clock doesn't need to be named. - - R8A7790 and R8A7791 use one functional clock per channel and one clock - per LVDS encoder. The functional clocks must be named "du.x" with "x" - being the channel numerical index. The LVDS clocks must be named + - R8A779[0134] use one functional clock per channel and one clock per LVDS + encoder (if available). The functional clocks must be named "du.x" with + "x" being the channel numerical index. The LVDS clocks must be named "lvds.x" with "x" being the LVDS encoder numerical index. - In addition to the functional and encoder clocks, all DU versions also support externally supplied pixel clocks. Those clocks are optional. @@ -43,7 +45,9 @@ corresponding to each DU output. ----------------------------------------------------------------------------- R8A7779 (H1) DPAD 0 DPAD 1 - R8A7790 (H2) DPAD LVDS 0 LVDS 1 - R8A7791 (M2) DPAD LVDS 0 - + R8A7791 (M2-W) DPAD LVDS 0 - + R8A7793 (M2-N) DPAD LVDS 0 - + R8A7794 (E2) DPAD 0 DPAD 1 - Example: R8A7790 (R-Car H2) DU diff --git a/Documentation/devicetree/bindings/display/ssd1307fb.txt b/Documentation/devicetree/bindings/display/ssd1307fb.txt index d1be78db63f5..eb31ed47a283 100644 --- a/Documentation/devicetree/bindings/display/ssd1307fb.txt +++ b/Documentation/devicetree/bindings/display/ssd1307fb.txt @@ -2,7 +2,8 @@ Required properties: - compatible: Should be "solomon,<chip>fb-<bus>". The only supported bus for - now is i2c, and the supported chips are ssd1305, ssd1306 and ssd1307. + now is i2c, and the supported chips are ssd1305, ssd1306, ssd1307 and + ssd1309. - reg: Should contain address of the controller on the I2C bus. Most likely 0x3c or 0x3d - pwm: Should contain the pwm to use according to the OF device tree PWM diff --git a/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt b/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt index 63a48928f3a8..b152a75dceae 100644 --- a/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt +++ b/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt @@ -2,9 +2,10 @@ Texas Instruments DMA Crossbar (DMA request router) Required properties: - compatible: "ti,dra7-dma-crossbar" for DRA7xx DMA crossbar + "ti,am335x-edma-crossbar" for AM335x and AM437x - reg: Memory map for accessing module -- #dma-cells: Should be set to <1>. - Clients should use the crossbar request number (input) +- #dma-cells: Should be set to to match with the DMA controller's dma-cells + for ti,dra7-dma-crossbar and <3> for ti,am335x-edma-crossbar. - dma-requests: Number of DMA requests the crossbar can receive - dma-masters: phandle pointing to the DMA controller @@ -14,6 +15,15 @@ The DMA controller node need to have the following poroperties: Optional properties: - ti,dma-safe-map: Safe routing value for unused request lines +Notes: +When requesting channel via ti,dra7-dma-crossbar, the DMA clinet must request +the DMA event number as crossbar ID (input to the DMA crossbar). + +For ti,am335x-edma-crossbar: the meaning of parameters of dmas for clients: +dmas = <&edma_xbar 12 0 1>; where <12> is the DMA request number, <0> is the TC +the event should be assigned and <1> is the mux selection for in the crossbar. +When mux 0 is used the DMA channel can be requested directly from edma node. + Example: /* DMA controller */ @@ -47,6 +57,7 @@ uart1: serial@4806a000 { ti,hwmods = "uart1"; clock-frequency = <48000000>; status = "disabled"; + /* Requesting crossbar input 49 and 50 */ dmas = <&sdma_xbar 49>, <&sdma_xbar 50>; dma-names = "tx", "rx"; }; diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt index 5ba525a10035..d3d0a4fb1c73 100644 --- a/Documentation/devicetree/bindings/dma/ti-edma.txt +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt @@ -1,4 +1,119 @@ -TI EDMA +Texas Instruments eDMA + +The eDMA3 consists of two components: Channel controller (CC) and Transfer +Controller(s) (TC). The CC is the main entry for DMA users since it is +responsible for the DMA channel handling, while the TCs are responsible to +execute the actual DMA tansfer. + +------------------------------------------------------------------------------ +eDMA3 Channel Controller + +Required properties: +- compatible: "ti,edma3-tpcc" for the channel controller(s) +- #dma-cells: Should be set to <2>. The first number is the DMA request + number and the second is the TC the channel is serviced on. +- reg: Memory map of eDMA CC +- reg-names: "edma3_cc" +- interrupts: Interrupt lines for CCINT, MPERR and CCERRINT. +- interrupt-names: "edma3_ccint", "emda3_mperr" and "edma3_ccerrint" +- ti,tptcs: List of TPTCs associated with the eDMA in the following form: + <&tptc_phandle TC_priority_number>. The highest priority is 0. + +Optional properties: +- ti,hwmods: Name of the hwmods associated to the eDMA CC +- ti,edma-memcpy-channels: List of channels allocated to be used for memcpy, iow + these channels will be SW triggered channels. The list must + contain 16 bits numbers, see example. +- ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used by + the driver, they are allocated to be used by for example the + DSP. See example. + +------------------------------------------------------------------------------ +eDMA3 Transfer Controller + +Required properties: +- compatible: "ti,edma3-tptc" for the transfer controller(s) +- reg: Memory map of eDMA TC +- interrupts: Interrupt number for TCerrint. + +Optional properties: +- ti,hwmods: Name of the hwmods associated to the given eDMA TC +- interrupt-names: "edma3_tcerrint" + +------------------------------------------------------------------------------ +Example: + +edma: edma@49000000 { + compatible = "ti,edma3-tpcc"; + ti,hwmods = "tpcc"; + reg = <0x49000000 0x10000>; + reg-names = "edma3_cc"; + interrupts = <12 13 14>; + interrupt-names = "edma3_ccint", "emda3_mperr", "edma3_ccerrint"; + dma-requests = <64>; + #dma-cells = <2>; + + ti,tptcs = <&edma_tptc0 7>, <&edma_tptc1 7>, <&edma_tptc2 0>; + + /* Channel 20 and 21 is allocated for memcpy */ + ti,edma-memcpy-channels = /bits/ 16 <20 21>; + /* The following PaRAM slots are reserved: 35-45 and 100-110 */ + ti,edma-reserved-slot-ranges = /bits/ 16 <35 10>, + /bits/ 16 <100 10>; +}; + +edma_tptc0: tptc@49800000 { + compatible = "ti,edma3-tptc"; + ti,hwmods = "tptc0"; + reg = <0x49800000 0x100000>; + interrupts = <112>; + interrupt-names = "edm3_tcerrint"; +}; + +edma_tptc1: tptc@49900000 { + compatible = "ti,edma3-tptc"; + ti,hwmods = "tptc1"; + reg = <0x49900000 0x100000>; + interrupts = <113>; + interrupt-names = "edm3_tcerrint"; +}; + +edma_tptc2: tptc@49a00000 { + compatible = "ti,edma3-tptc"; + ti,hwmods = "tptc2"; + reg = <0x49a00000 0x100000>; + interrupts = <114>; + interrupt-names = "edm3_tcerrint"; +}; + +sham: sham@53100000 { + compatible = "ti,omap4-sham"; + ti,hwmods = "sham"; + reg = <0x53100000 0x200>; + interrupts = <109>; + /* DMA channel 36 executed on eDMA TC0 - low priority queue */ + dmas = <&edma 36 0>; + dma-names = "rx"; +}; + +mcasp0: mcasp@48038000 { + compatible = "ti,am33xx-mcasp-audio"; + ti,hwmods = "mcasp0"; + reg = <0x48038000 0x2000>, + <0x46000000 0x400000>; + reg-names = "mpu", "dat"; + interrupts = <80>, <81>; + interrupt-names = "tx", "rx"; + status = "disabled"; + /* DMA channels 8 and 9 executed on eDMA TC2 - high priority queue */ + dmas = <&edma 8 2>, + <&edma 9 2>; + dma-names = "tx", "rx"; +}; + +------------------------------------------------------------------------------ +DEPRECATED binding, new DTS files must use the ti,edma3-tpcc/ti,edma3-tptc +binding. Required properties: - compatible : "ti,edma3" diff --git a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt index 805ddcd79a57..f2455c50533d 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt @@ -1,9 +1,9 @@ -* Freescale MPC512x/MPC8xxx GPIO controller +* Freescale MPC512x/MPC8xxx/Layerscape GPIO controller Required properties: - compatible : Should be "fsl,<soc>-gpio" The following <soc>s are known to be supported: - mpc5121, mpc5125, mpc8349, mpc8572, mpc8610, pq3, qoriq + mpc5121, mpc5125, mpc8349, mpc8572, mpc8610, pq3, qoriq. - reg : Address and length of the register set for the device - interrupts : Should be the port interrupt shared by all 32 pins. - #gpio-cells : Should be two. The first cell is the pin number and diff --git a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt index 610757ce4492..c6d533202d3e 100644 --- a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt +++ b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt @@ -3,10 +3,35 @@ Bindings for a fan connected to the PWM lines Required properties: - compatible : "pwm-fan" - pwms : the PWM that is used to control the PWM fan +- cooling-levels : PWM duty cycle values in a range from 0 to 255 + which correspond to thermal cooling states Example: - pwm-fan { + fan0: pwm-fan { compatible = "pwm-fan"; - status = "okay"; + cooling-min-state = <0>; + cooling-max-state = <3>; + #cooling-cells = <2>; pwms = <&pwm 0 10000 0>; + cooling-levels = <0 102 170 230>; }; + + thermal-zones { + cpu_thermal: cpu-thermal { + thermal-sensors = <&tmu 0>; + polling-delay-passive = <0>; + polling-delay = <0>; + trips { + cpu_alert1: cpu-alert1 { + temperature = <100000>; /* millicelsius */ + hysteresis = <2000>; /* millicelsius */ + type = "passive"; + }; + }; + cooling-maps { + map0 { + trip = <&cpu_alert1>; + cooling-device = <&fan0 0 1>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-davinci.txt b/Documentation/devicetree/bindings/i2c/i2c-davinci.txt index a4e1cbc810c1..5b123e0e4cc2 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-davinci.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-davinci.txt @@ -1,10 +1,10 @@ -* Texas Instruments Davinci I2C +* Texas Instruments Davinci/Keystone I2C This file provides information, what the device node for the -davinci i2c interface contain. +davinci/keystone i2c interface contains. Required properties: -- compatible: "ti,davinci-i2c"; +- compatible: "ti,davinci-i2c" or "ti,keystone-i2c"; - reg : Offset and length of the register set for the device Recommended properties : diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx.txt b/Documentation/devicetree/bindings/i2c/i2c-imx.txt index ce4311d726ae..eab5836ba7f9 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-imx.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-imx.txt @@ -14,6 +14,10 @@ Optional properties: The absence of the propoerty indicates the default frequency 100 kHz. - dmas: A list of two dma specifiers, one for each entry in dma-names. - dma-names: should contain "tx" and "rx". +- scl-gpios: specify the gpio related to SCL pin +- sda-gpios: specify the gpio related to SDA pin +- pinctrl: add extra pinctrl to configure i2c pins to gpio function for i2c + bus recovery, call it "gpio" state Examples: @@ -37,4 +41,9 @@ i2c0: i2c@40066000 { /* i2c0 on vf610 */ dmas = <&edma0 0 50>, <&edma0 0 51>; dma-names = "rx","tx"; + pinctrl-names = "default", "gpio"; + pinctrl-0 = <&pinctrl_i2c1>; + pinctrl-1 = <&pinctrl_i2c1_gpio>; + scl-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH>; + sda-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt index 16b3e07aa98f..ea406eb20fa5 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt @@ -10,6 +10,7 @@ Required properties: "renesas,i2c-r8a7792" "renesas,i2c-r8a7793" "renesas,i2c-r8a7794" + "renesas,i2c-r8a7795" - reg: physical base address of the controller and length of memory mapped region. - interrupts: interrupt specifier. diff --git a/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt b/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt index 2bfc6e7ed094..214f94c25d37 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt @@ -10,6 +10,7 @@ Required properties: - "renesas,iic-r8a7792" (R-Car V2H) - "renesas,iic-r8a7793" (R-Car M2-N) - "renesas,iic-r8a7794" (R-Car E2) + - "renesas,iic-r8a7795" (R-Car H3) - "renesas,iic-sh73a0" (SH-Mobile AG5) - reg : address start and address range size of device - interrupts : interrupt of device diff --git a/Documentation/devicetree/bindings/i2c/i2c-uniphier-f.txt b/Documentation/devicetree/bindings/i2c/i2c-uniphier-f.txt new file mode 100644 index 000000000000..27fc6f8c798b --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-uniphier-f.txt @@ -0,0 +1,25 @@ +UniPhier I2C controller (FIFO-builtin) + +Required properties: +- compatible: should be "socionext,uniphier-fi2c". +- #address-cells: should be 1. +- #size-cells: should be 0. +- reg: offset and length of the register set for the device. +- interrupts: a single interrupt specifier. +- clocks: phandle to the input clock. + +Optional properties: +- clock-frequency: desired I2C bus frequency in Hz. The maximum supported + value is 400000. Defaults to 100000 if not specified. + +Examples: + + i2c0: i2c@58780000 { + compatible = "socionext,uniphier-fi2c"; + reg = <0x58780000 0x80>; + #address-cells = <1>; + #size-cells = <0>; + interrupts = <0 41 4>; + clocks = <&i2c_clk>; + clock-frequency = <100000>; + }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-uniphier.txt b/Documentation/devicetree/bindings/i2c/i2c-uniphier.txt new file mode 100644 index 000000000000..26f9d95b3436 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-uniphier.txt @@ -0,0 +1,25 @@ +UniPhier I2C controller (FIFO-less) + +Required properties: +- compatible: should be "socionext,uniphier-i2c". +- #address-cells: should be 1. +- #size-cells: should be 0. +- reg: offset and length of the register set for the device. +- interrupts: a single interrupt specifier. +- clocks: phandle to the input clock. + +Optional properties: +- clock-frequency: desired I2C bus frequency in Hz. The maximum supported + value is 400000. Defaults to 100000 if not specified. + +Examples: + + i2c0: i2c@58400000 { + compatible = "socionext,uniphier-i2c"; + reg = <0x58400000 0x40>; + #address-cells = <1>; + #size-cells = <0>; + interrupts = <0 41 1>; + clocks = <&i2c_clk>; + clock-frequency = <100000>; + }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt index 09089a6d69ed..b80c04b0e5c0 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt @@ -1,14 +1,15 @@ -* Texas Instruments tsc2005 touchscreen controller +* Texas Instruments tsc2004 and tsc2005 touchscreen controllers Required properties: - - compatible : "ti,tsc2005" - - reg : SPI device address - - spi-max-frequency : Maximal SPI speed + - compatible : "ti,tsc2004" or "ti,tsc2005" + - reg : Device address - interrupts : IRQ specifier - - reset-gpios : GPIO specifier - - vio-supply : Regulator specifier + - spi-max-frequency : Maximum SPI clocking speed of the device + (for tsc2005) Optional properties: + - vio-supply : Regulator specifier + - reset-gpios : GPIO specifier for the controller reset line - ti,x-plate-ohms : integer, resistance of the touchscreen's X plates in ohm (defaults to 280) - ti,esd-recovery-timeout-ms : integer, if the touchscreen does not respond after @@ -18,6 +19,27 @@ Optional properties: Example: +&i2c3 { + tsc2004@48 { + compatible = "ti,tsc2004"; + reg = <0x48>; + vio-supply = <&vio>; + + reset-gpios = <&gpio4 8 GPIO_ACTIVE_HIGH>; + interrupts-extended = <&gpio1 27 IRQ_TYPE_EDGE_RISING>; + + touchscreen-fuzz-x = <4>; + touchscreen-fuzz-y = <7>; + touchscreen-fuzz-pressure = <2>; + touchscreen-size-x = <4096>; + touchscreen-size-y = <4096>; + touchscreen-max-pressure = <2048>; + + ti,x-plate-ohms = <280>; + ti,esd-recovery-timeout-ms = <8000>; + }; +} + &mcspi1 { tsc2005@0 { compatible = "ti,tsc2005"; diff --git a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt index 729543c47046..bc620fe32a70 100644 --- a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt +++ b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt @@ -47,7 +47,7 @@ Required properties: - clocks: Required if the System MMU is needed to gate its clock. - power-domains: Required if the System MMU is needed to gate its power. Please refer to the following document: - Documentation/devicetree/bindings/arm/exynos/power_domain.txt + Documentation/devicetree/bindings/power/pd-samsung.txt Examples: gsc_0: gsc@13e00000 { diff --git a/Documentation/devicetree/bindings/memory-controllers/arm,pl172.txt b/Documentation/devicetree/bindings/memory-controllers/arm,pl172.txt index e6df32f9986d..22b77ee02f58 100644 --- a/Documentation/devicetree/bindings/memory-controllers/arm,pl172.txt +++ b/Documentation/devicetree/bindings/memory-controllers/arm,pl172.txt @@ -1,8 +1,9 @@ -* Device tree bindings for ARM PL172 MultiPort Memory Controller +* Device tree bindings for ARM PL172/PL175/PL176 MultiPort Memory Controller Required properties: -- compatible: "arm,pl172", "arm,primecell" +- compatible: Must be "arm,primecell" and exactly one from + "arm,pl172", "arm,pl175" or "arm,pl176". - reg: Must contains offset/length value for controller. @@ -56,7 +57,8 @@ Optional child cs node config properties: - mpmc,extended-wait: Enable extended wait. -- mpmc,buffer-enable: Enable write buffer. +- mpmc,buffer-enable: Enable write buffer, option is not supported by + PL175 and PL176 controllers. - mpmc,write-protect: Enable write protect. diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas-memory-controllers.txt b/Documentation/devicetree/bindings/memory-controllers/renesas-memory-controllers.txt index c64b7925cd09..9f78e6c82740 100644 --- a/Documentation/devicetree/bindings/memory-controllers/renesas-memory-controllers.txt +++ b/Documentation/devicetree/bindings/memory-controllers/renesas-memory-controllers.txt @@ -24,9 +24,9 @@ Required properties: Optional properties: - interrupts: Must contain a list of interrupt specifiers for memory controller interrupts, if available. - - interrupts-names: Must contain a list of interrupt names corresponding to - the interrupts in the interrupts property, if available. - Valid interrupt names are: + - interrupt-names: Must contain a list of interrupt names corresponding to + the interrupts in the interrupts property, if available. + Valid interrupt names are: - "sec" (secure interrupt) - "temp" (normal (temperature) interrupt) - power-domains: Must contain a reference to the PM domain that the memory diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt b/Documentation/devicetree/bindings/mfd/s2mps11.txt index a42adda944bf..09b94c97faac 100644 --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt @@ -22,6 +22,10 @@ Optional properties: - samsung,s2mps11-wrstbi-ground: Indicates that WRSTBI pin of PMIC is pulled down. When the system is suspended it will always go down thus triggerring unwanted buck warm reset (setting buck voltages to default values). +- samsung,s2mps11-acokb-ground: Indicates that ACOKB pin of S2MPS11 PMIC is + connected to the ground so the PMIC must manually set PWRHOLD bit in CTRL1 + register to turn off the power. Usually the ACOKB is pulled up to VBATT so + when PWRHOLD pin goes low, the rising ACOKB will trigger power off. Optional nodes: - clocks: s2mps11, s2mps13, s2mps15 and s5m8767 provide three(AP/CP/BT) buffered 32.768 diff --git a/Documentation/devicetree/bindings/mips/img/xilfpga.txt b/Documentation/devicetree/bindings/mips/img/xilfpga.txt new file mode 100644 index 000000000000..57e7ee942166 --- /dev/null +++ b/Documentation/devicetree/bindings/mips/img/xilfpga.txt @@ -0,0 +1,83 @@ +Imagination University Program MIPSfpga +======================================= + +Under the Imagination University Program, a microAptiv UP core has been +released for academic usage. + +As we are dealing with a MIPS core instantiated on an FPGA, specifications +are fluid and can be varied in RTL. + +This binding document is provided as baseline guidance for the example +project provided by IMG. + +The example project runs on the Nexys4DDR board by Digilent powered by +the ARTIX-7 FPGA by Xilinx. + +Relevant details about the example project and the Nexys4DDR board: + +- microAptiv UP core m14Kc +- 50MHz clock speed +- 128Mbyte DDR RAM at 0x0000_0000 +- 8Kbyte RAM at 0x1000_0000 +- axi_intc at 0x1020_0000 +- axi_uart16550 at 0x1040_0000 +- axi_gpio at 0x1060_0000 +- axi_i2c at 0x10A0_0000 +- custom_gpio at 0x10C0_0000 +- axi_ethernetlite at 0x10E0_0000 +- 8Kbyte BootRAM at 0x1FC0_0000 + +Required properties: +-------------------- + - compatible: Must include "digilent,nexys4ddr","img,xilfpga". + +CPU nodes: +---------- +A "cpus" node is required. Required properties: + - #address-cells: Must be 1. + - #size-cells: Must be 0. +A CPU sub-node is also required for at least CPU 0. Required properties: + - device_type: Must be "cpu". + - compatible: Must be "mips,m14Kc". + - reg: Must be <0>. + - clocks: phandle to ext clock for fixed-clock received by MIPS core. + +Example: + + compatible = "img,xilfpga","digilent,nexys4ddr"; + cpus { + #address-cells = <1>; + #size-cells = <0>; + + cpu0: cpu@0 { + device_type = "cpu"; + compatible = "mips,m14Kc"; + reg = <0>; + clocks = <&ext>; + }; + }; + + ext: ext { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <50000000>; + }; + +Boot protocol: +-------------- + +The BootRAM is a writeable "RAM" in FPGA at 0x1FC0_0000. +This is for easy reprogrammibility via JTAG. + +The BootRAM initializes the cache and the axi_uart peripheral. + +DDR initialization is already handled by a HW IP block. + +When the example project bitstream is loaded, the cpu_reset button +needs to be pressed. + +The bootram initializes the cache and axi_uart. +Then outputs MIPSFPGA\n\r on the serial port on the Nexys4DDR board. + +At this point, the board is ready to load the Linux kernel +vmlinux file via JTAG. diff --git a/Documentation/devicetree/bindings/net/cpsw.txt b/Documentation/devicetree/bindings/net/cpsw.txt index 4efca560adda..9853f8e70966 100644 --- a/Documentation/devicetree/bindings/net/cpsw.txt +++ b/Documentation/devicetree/bindings/net/cpsw.txt @@ -48,6 +48,11 @@ Optional properties: - mac-address : See ethernet.txt file in the same directory - phy-handle : See ethernet.txt file in the same directory +Slave sub-nodes: +- fixed-link : See fixed-link.txt file in the same directory + Either the properties phy_id and phy-mode, + or the sub-node fixed-link can be specified + Note: "ti,hwmods" field is used to fetch the base address and irq resources from TI, omap hwmod data base during device registration. Future plan is to migrate hwmod data base contents into device tree diff --git a/Documentation/devicetree/bindings/pci/arm,juno-r1-pcie.txt b/Documentation/devicetree/bindings/pci/arm,juno-r1-pcie.txt new file mode 100644 index 000000000000..f7514c170a32 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/arm,juno-r1-pcie.txt @@ -0,0 +1,10 @@ +* ARM Juno R1 PCIe interface + +This PCIe host controller is based on PLDA XpressRICH3-AXI IP +and thus inherits all the common properties defined in plda,xpressrich3-axi.txt +as well as the base properties defined in host-generic-pci.txt. + +Required properties: + - compatible: "arm,juno-r1-pcie" + - dma-coherent: The host controller bridges the AXI transactions into PCIe bus + in a manner that makes the DMA operations to appear coherent to the CPUs. diff --git a/Documentation/devicetree/bindings/pci/plda,xpressrich3-axi.txt b/Documentation/devicetree/bindings/pci/plda,xpressrich3-axi.txt new file mode 100644 index 000000000000..f3f75bfb42bc --- /dev/null +++ b/Documentation/devicetree/bindings/pci/plda,xpressrich3-axi.txt @@ -0,0 +1,12 @@ +* PLDA XpressRICH3-AXI host controller + +The PLDA XpressRICH3-AXI host controller can be configured in a manner that +makes it compliant with the SBSA[1] standard published by ARM Ltd. For those +scenarios, the host-generic-pci.txt bindings apply with the following additions +to the compatible property: + +Required properties: + - compatible: should contain "plda,xpressrich3-axi" to identify the IP used. + + +[1] http://infocenter.arm.com/help/topic/com.arm.doc.den0029a/ diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt b/Documentation/devicetree/bindings/power/pd-samsung.txt index e151057d92f0..4e947372a693 100644 --- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt +++ b/Documentation/devicetree/bindings/power/pd-samsung.txt @@ -43,9 +43,8 @@ Example: mfc_pd: power-domain@10044060 { compatible = "samsung,exynos4210-pd"; reg = <0x10044060 0x20>; - clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MOUT_SW_ACLK333>, - <&clock CLK_MOUT_USER_ACLK333>; - clock-names = "oscclk", "pclk0", "clk0"; + clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MOUT_USER_ACLK333>; + clock-names = "oscclk", "clk0"; #power-domain-cells = <0>; }; diff --git a/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.txt b/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.txt new file mode 100644 index 000000000000..d9254a6da5ed --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.txt @@ -0,0 +1,20 @@ +Broadcom BCM7038 PWM controller (BCM7xxx Set Top Box PWM controller) + +Required properties: + +- compatible: must be "brcm,bcm7038-pwm" +- reg: physical base address and length for this controller +- #pwm-cells: should be 2. See pwm.txt in this directory for a description + of the cells format +- clocks: a phandle to the reference clock for this block which is fed through + its internal variable clock frequency generator + + +Example: + + pwm: pwm@f0408000 { + compatible = "brcm,bcm7038-pwm"; + reg = <0xf0408000 0x28>; + #pwm-cells = <2>; + clocks = <&upg_fixed>; + }; diff --git a/Documentation/devicetree/bindings/pwm/pwm-berlin.txt b/Documentation/devicetree/bindings/pwm/pwm-berlin.txt new file mode 100644 index 000000000000..82cbe16fcbbc --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/pwm-berlin.txt @@ -0,0 +1,17 @@ +Berlin PWM controller + +Required properties: +- compatible: should be "marvell,berlin-pwm" +- reg: physical base address and length of the controller's registers +- clocks: phandle to the input clock +- #pwm-cells: should be 3. See pwm.txt in this directory for a description of + the cells format. + +Example: + +pwm: pwm@f7f20000 { + compatible = "marvell,berlin-pwm"; + reg = <0xf7f20000 0x40>; + clocks = <&chip_clk CLKID_CFG>; + #pwm-cells = <3>; +} diff --git a/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt new file mode 100644 index 000000000000..f8f59baf6b67 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt @@ -0,0 +1,42 @@ +MediaTek display PWM controller + +Required properties: + - compatible: should be "mediatek,<name>-disp-pwm": + - "mediatek,mt8173-disp-pwm": found on mt8173 SoC. + - "mediatek,mt6595-disp-pwm": found on mt6595 SoC. + - reg: physical base address and length of the controller's registers. + - #pwm-cells: must be 2. See pwm.txt in this directory for a description of + the cell format. + - clocks: phandle and clock specifier of the PWM reference clock. + - clock-names: must contain the following: + - "main": clock used to generate PWM signals. + - "mm": sync signals from the modules of mmsys. + - pinctrl-names: Must contain a "default" entry. + - pinctrl-0: One property must exist for each entry in pinctrl-names. + See pinctrl/pinctrl-bindings.txt for details of the property values. + +Example: + pwm0: pwm@1401e000 { + compatible = "mediatek,mt8173-disp-pwm", + "mediatek,mt6595-disp-pwm"; + reg = <0 0x1401e000 0 0x1000>; + #pwm-cells = <2>; + clocks = <&mmsys CLK_MM_DISP_PWM026M>, + <&mmsys CLK_MM_DISP_PWM0MM>; + clock-names = "main", "mm"; + pinctrl-names = "default"; + pinctrl-0 = <&disp_pwm0_pins>; + }; + + backlight_lcd: backlight_lcd { + compatible = "pwm-backlight"; + pwms = <&pwm0 0 1000000>; + brightness-levels = < + 0 16 32 48 64 80 96 112 + 128 144 160 176 192 208 224 240 + 255 + >; + default-brightness-level = <9>; + power-supply = <&mt6397_vio18_reg>; + enable-gpios = <&pio 95 GPIO_ACTIVE_HIGH>; + }; diff --git a/Documentation/devicetree/bindings/pwm/pwm-sun4i.txt b/Documentation/devicetree/bindings/pwm/pwm-sun4i.txt index ae0273e19506..cf6068b8e974 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-sun4i.txt +++ b/Documentation/devicetree/bindings/pwm/pwm-sun4i.txt @@ -3,6 +3,8 @@ Allwinner sun4i and sun7i SoC PWM controller Required properties: - compatible: should be one of: - "allwinner,sun4i-a10-pwm" + - "allwinner,sun5i-a10s-pwm" + - "allwinner,sun5i-a13-pwm" - "allwinner,sun7i-a20-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 diff --git a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt new file mode 100644 index 000000000000..0822a083fc57 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt @@ -0,0 +1,26 @@ +* Renesas R-Car PWM Timer Controller + +Required Properties: +- compatible: should be "renesas,pwm-rcar" and one of the following. + - "renesas,pwm-r8a7778": for R-Car M1A + - "renesas,pwm-r8a7779": for R-Car H1 + - "renesas,pwm-r8a7790": for R-Car H2 + - "renesas,pwm-r8a7791": for R-Car M2-W + - "renesas,pwm-r8a7794": for R-Car E2 +- reg: base address and length of the registers block for the PWM. +- #pwm-cells: should be 2. See pwm.txt in this directory for a description of + the cells format. +- clocks: clock phandle and specifier pair. +- pinctrl-0: phandle, referring to a default pin configuration node. +- pinctrl-names: Set to "default". + +Example: R8A7790 (R-Car H2) PWM Timer node + + pwm0: pwm@e6e30000 { + compatible = "renesas,pwm-r8a7790", "renesas,pwm-rcar"; + reg = <0 0xe6e30000 0 0x8>; + #pwm-cells = <2>; + clocks = <&mstp5_clks R8A7790_CLK_PWM>; + pinctrl-0 = <&pwm0_pins>; + pinctrl-names = "default"; + }; diff --git a/Documentation/devicetree/bindings/rtc/dallas,ds1390.txt b/Documentation/devicetree/bindings/rtc/dallas,ds1390.txt new file mode 100644 index 000000000000..8e76f2648796 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/dallas,ds1390.txt @@ -0,0 +1,18 @@ +* Dallas DS1390 SPI Serial Real-Time Clock + +Required properties: +- compatible: Should contain "dallas,ds1390". +- reg: SPI address for chip + +Optional properties: +- trickle-resistor-ohms : Selected resistor for trickle charger + Values usable for ds1390 are 250, 2000, 4000 + Should be given if trickle charger should be enabled +- trickle-diode-disable : Do not use internal trickle charger diode + Should be given if internal trickle charger diode should be disabled +Example: + ds1390: rtc@68 { + compatible = "dallas,ds1390"; + trickle-resistor-ohms = <250>; + reg = <0>; + }; diff --git a/Documentation/devicetree/bindings/rtc/pcf8563.txt b/Documentation/devicetree/bindings/rtc/pcf8563.txt new file mode 100644 index 000000000000..72f6d2c9665e --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/pcf8563.txt @@ -0,0 +1,25 @@ +* Philips PCF8563/Epson RTC8564 Real Time Clock + +Philips PCF8563/Epson RTC8564 Real Time Clock + +Required properties: +see: Documentation/devicetree/bindings/i2c/trivial-devices.txt + +Optional property: +- #clock-cells: Should be 0. +- clock-output-names: + overwrite the default clock name "pcf8563-clkout" + +Example: + +pcf8563: pcf8563@51 { + compatible = "nxp,pcf8563"; + reg = <0x51>; + #clock-cells = <0>; +}; + +device { +... + clocks = <&pcf8563>; +... +}; diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt index c0511142b39c..a6c8afc8385a 100644 --- a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt +++ b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt @@ -17,9 +17,9 @@ Required properties: - reg: Address range of the SCPSYS unit - infracfg: must contain a phandle to the infracfg controller - clock, clock-names: clocks according to the common clock binding. - The clocks needed "mm" and "mfg". These are the - clocks which hardware needs to be enabled before - enabling certain power domains. + The clocks needed "mm", "mfg", "venc" and "venc_lt". + These are the clocks which hardware needs to be enabled + before enabling certain power domains. Example: @@ -30,7 +30,9 @@ Example: infracfg = <&infracfg>; clocks = <&clk26m>, <&topckgen CLK_TOP_MM_SEL>; - clock-names = "mfg", "mm"; + <&topckgen CLK_TOP_VENC_SEL>, + <&topckgen CLK_TOP_VENC_LT_SEL>; + clock-names = "mfg", "mm", "venc", "venc_lt"; }; Example consumer: diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smem.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,smem.txt new file mode 100644 index 000000000000..9326cdf6e1b1 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smem.txt @@ -0,0 +1,57 @@ +Qualcomm Shared Memory Manager binding + +This binding describes the Qualcomm Shared Memory Manager, used to share data +between various subsystems and OSes in Qualcomm platforms. + +- compatible: + Usage: required + Value type: <stringlist> + Definition: must be: + "qcom,smem" + +- memory-region: + Usage: required + Value type: <prop-encoded-array> + Definition: handle to memory reservation for main SMEM memory region. + +- qcom,rpm-msg-ram: + Usage: required + Value type: <prop-encoded-array> + Definition: handle to RPM message memory resource + +- hwlocks: + Usage: required + Value type: <prop-encoded-array> + Definition: reference to a hwspinlock used to protect allocations from + the shared memory + += EXAMPLE +The following example shows the SMEM setup for MSM8974, with a main SMEM region +at 0xfa00000 and the RPM message ram at 0xfc428000: + + reserved-memory { + #address-cells = <1>; + #size-cells = <1>; + ranges; + + smem_region: smem@fa00000 { + reg = <0xfa00000 0x200000>; + no-map; + }; + }; + + smem@fa00000 { + compatible = "qcom,smem"; + + memory-region = <&smem_region>; + qcom,rpm-msg-ram = <&rpm_msg_ram>; + + hwlocks = <&tcsr_mutex 3>; + }; + + soc { + rpm_msg_ram: memory@fc428000 { + compatible = "qcom,rpm-msg-ram"; + reg = <0xfc428000 0x4000>; + }; + }; diff --git a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt new file mode 100644 index 000000000000..112756e11802 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt @@ -0,0 +1,46 @@ +* Rockchip Power Domains + +Rockchip processors include support for multiple power domains which can be +powered up/down by software based on different application scenes to save power. + +Required properties for power domain controller: +- compatible: Should be one of the following. + "rockchip,rk3288-power-controller" - for RK3288 SoCs. +- #power-domain-cells: Number of cells in a power-domain specifier. + Should be 1 for multiple PM domains. +- #address-cells: Should be 1. +- #size-cells: Should be 0. + +Required properties for power domain sub nodes: +- reg: index of the power domain, should use macros in: + "include/dt-bindings/power/rk3288-power.h" - for RK3288 type power domain. +- clocks (optional): phandles to clocks which need to be enabled while power domain + switches state. + +Example: + + power: power-controller { + compatible = "rockchip,rk3288-power-controller"; + #power-domain-cells = <1>; + #address-cells = <1>; + #size-cells = <0>; + + pd_gpu { + reg = <RK3288_PD_GPU>; + clocks = <&cru ACLK_GPU>; + }; + }; + +Node of a device using power domains must have a power-domains property, +containing a phandle to the power device node and an index specifying which +power domain to use. +The index should use macros in: + "include/dt-bindings/power/rk3288-power.h" - for rk3288 type power domain. + +Example of the node using power domain: + + node { + /* ... */ + power-domains = <&power RK3288_PD_GPU>; + /* ... */ + }; diff --git a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt index d8e8cdb733f9..d1ce21a4904d 100644 --- a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt +++ b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt @@ -221,7 +221,6 @@ qmss: qmss@2a40000 { #size-cells = <1>; ranges; pdsp0@0x2a10000 { - firmware = "keystone/qmss_pdsp_acc48_k2_le_1_0_0_8.fw"; reg = <0x2a10000 0x1000>, <0x2a0f000 0x100>, <0x2a0c000 0x3c8>, diff --git a/Documentation/devicetree/bindings/sound/ak4554.c b/Documentation/devicetree/bindings/sound/ak4554.txt index 934fa02754b3..934fa02754b3 100644 --- a/Documentation/devicetree/bindings/sound/ak4554.c +++ b/Documentation/devicetree/bindings/sound/ak4554.txt diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt index ef802de4957a..b38200d2583a 100644 --- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt @@ -12,6 +12,11 @@ Required properties: - resets : Must contain an entry for each entry in reset-names. See ../reset/reset.txt for details. - reset-names : Must include the name "tsadc-apb". +- pinctrl-names : The pin control state names; +- pinctrl-0 : The "init" pinctrl state, it will be set before device probe. +- pinctrl-1 : The "default" pinctrl state, it will be set after reset the + TSADC controller. +- pinctrl-2 : The "sleep" pinctrl state, it will be in for suspend. - #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description. - rockchip,hw-tshut-temp : The hardware-controlled shutdown temperature value. - rockchip,hw-tshut-mode : The hardware-controlled shutdown mode 0:CRU 1:GPIO. @@ -27,8 +32,10 @@ tsadc: tsadc@ff280000 { clock-names = "tsadc", "apb_pclk"; resets = <&cru SRST_TSADC>; reset-names = "tsadc-apb"; - pinctrl-names = "default"; - pinctrl-0 = <&otp_out>; + pinctrl-names = "init", "default", "sleep"; + pinctrl-0 = <&otp_gpio>; + pinctrl-1 = <&otp_out>; + pinctrl-2 = <&otp_gpio>; #thermal-sensor-cells = <1>; rockchip,hw-tshut-temp = <95000>; rockchip,hw-tshut-mode = <0>; diff --git a/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt b/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt index 0c9222d27fae..6299dd8de339 100644 --- a/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt +++ b/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt @@ -10,6 +10,8 @@ to the silicon temperature. Required properties: - compatible : Should be: + - "ti,omap34xx-bandgap" : for OMAP34xx bandgap + - "ti,omap36xx-bandgap" : for OMAP36xx bandgap - "ti,omap4430-bandgap" : for OMAP4430 bandgap - "ti,omap4460-bandgap" : for OMAP4460 bandgap - "ti,omap4470-bandgap" : for OMAP4470 bandgap @@ -25,6 +27,18 @@ to each bandgap version, because the mapping may change from soc to soc, apart of depending on available features. Example: +OMAP34xx: +bandgap { + reg = <0x48002524 0x4>; + compatible = "ti,omap34xx-bandgap"; +}; + +OMAP36xx: +bandgap { + reg = <0x48002524 0x4>; + compatible = "ti,omap36xx-bandgap"; +}; + OMAP4430: bandgap { reg = <0x4a002260 0x4 0x4a00232C 0x4>; diff --git a/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt b/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt index 53a3029b7589..64083bc5633c 100644 --- a/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt +++ b/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt @@ -3,10 +3,12 @@ Mediatek MT6577, MT6572 and MT6589 Timers Required properties: - compatible should contain: - * "mediatek,mt6589-timer" for MT6589 compatible timers * "mediatek,mt6580-timer" for MT6580 compatible timers - * "mediatek,mt6577-timer" for all compatible timers (MT6589, MT6580, - MT6577) + * "mediatek,mt6589-timer" for MT6589 compatible timers + * "mediatek,mt8127-timer" for MT8127 compatible timers + * "mediatek,mt8135-timer" for MT8135 compatible timers + * "mediatek,mt8173-timer" for MT8173 compatible timers + * "mediatek,mt6577-timer" for MT6577 and all above compatible timers - reg: Should contain location and length for timers register. - clocks: Clocks driving the timer hardware. This list should include two clocks. The order is system clock and as second clock the RTC clock. diff --git a/Documentation/devicetree/bindings/ufs/ufs-qcom.txt b/Documentation/devicetree/bindings/ufs/ufs-qcom.txt new file mode 100644 index 000000000000..070baf4d7d97 --- /dev/null +++ b/Documentation/devicetree/bindings/ufs/ufs-qcom.txt @@ -0,0 +1,58 @@ +* Qualcomm Technologies Inc Universal Flash Storage (UFS) PHY + +UFSPHY nodes are defined to describe on-chip UFS PHY hardware macro. +Each UFS PHY node should have its own node. + +To bind UFS PHY with UFS host controller, the controller node should +contain a phandle reference to UFS PHY node. + +Required properties: +- compatible : compatible list, contains "qcom,ufs-phy-qmp-20nm" + or "qcom,ufs-phy-qmp-14nm" according to the relevant phy in use. +- reg : should contain PHY register address space (mandatory), +- reg-names : indicates various resources passed to driver (via reg proptery) by name. + Required "reg-names" is "phy_mem". +- #phy-cells : This property shall be set to 0 +- vdda-phy-supply : phandle to main PHY supply for analog domain +- vdda-pll-supply : phandle to PHY PLL and Power-Gen block power supply +- clocks : List of phandle and clock specifier pairs +- clock-names : List of clock input name strings sorted in the same + order as the clocks property. "ref_clk_src", "ref_clk", + "tx_iface_clk" & "rx_iface_clk" are mandatory but + "ref_clk_parent" is optional + +Optional properties: +- vdda-phy-max-microamp : specifies max. load that can be drawn from phy supply +- vdda-pll-max-microamp : specifies max. load that can be drawn from pll supply +- vddp-ref-clk-supply : phandle to UFS device ref_clk pad power supply +- vddp-ref-clk-max-microamp : specifies max. load that can be drawn from this supply +- vddp-ref-clk-always-on : specifies if this supply needs to be kept always on + +Example: + + ufsphy1: ufsphy@0xfc597000 { + compatible = "qcom,ufs-phy-qmp-20nm"; + reg = <0xfc597000 0x800>; + reg-names = "phy_mem"; + #phy-cells = <0>; + vdda-phy-supply = <&pma8084_l4>; + vdda-pll-supply = <&pma8084_l12>; + vdda-phy-max-microamp = <50000>; + vdda-pll-max-microamp = <1000>; + clock-names = "ref_clk_src", + "ref_clk_parent", + "ref_clk", + "tx_iface_clk", + "rx_iface_clk"; + clocks = <&clock_rpm clk_ln_bb_clk>, + <&clock_gcc clk_pcie_1_phy_ldo >, + <&clock_gcc clk_ufs_phy_ldo>, + <&clock_gcc clk_gcc_ufs_tx_cfg_clk>, + <&clock_gcc clk_gcc_ufs_rx_cfg_clk>; + }; + + ufshc@0xfc598000 { + ... + phys = <&ufsphy1>; + phy-names = "ufsphy"; + }; diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt index 53579197eca2..03c0e989e020 100644 --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt @@ -4,11 +4,18 @@ UFSHC nodes are defined to describe on-chip UFS host controllers. Each UFS controller instance should have its own node. Required properties: -- compatible : compatible list, contains "jedec,ufs-1.1" +- compatible : must contain "jedec,ufs-1.1", may also list one or more + of the following: + "qcom,msm8994-ufshc" + "qcom,msm8996-ufshc" + "qcom,ufshc" - interrupts : <interrupt mapping for UFS host controller IRQ> - reg : <registers mapping> Optional properties: +- phys : phandle to UFS PHY node +- phy-names : the string "ufsphy" when is found in a node, along + with "phys" attribute, provides phandle to UFS PHY node - vdd-hba-supply : phandle to UFS host controller supply regulator node - vcc-supply : phandle to VCC supply regulator node - vccq-supply : phandle to VCCQ supply regulator node @@ -54,4 +61,6 @@ Example: clocks = <&core 0>, <&ref 0>, <&iface 0>; clock-names = "core_clk", "ref_clk", "iface_clk"; freq-table-hz = <100000000 200000000>, <0 0>, <0 0>; + phys = <&ufsphy1>; + phy-names = "ufsphy"; }; diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt index 9ff48e0defb4..fb2ad0acedbd 100644 --- a/Documentation/devicetree/bindings/usb/dwc3.txt +++ b/Documentation/devicetree/bindings/usb/dwc3.txt @@ -1,6 +1,7 @@ synopsys DWC3 CORE -DWC3- USB3 CONTROLLER +DWC3- USB3 CONTROLLER. Complies to the generic USB binding properties + as described in 'usb/generic.txt' Required properties: - compatible: must be "snps,dwc3" diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 8c6cef73e0d7..55df1d444e9f 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -34,6 +34,7 @@ avago Avago Technologies avic Shanghai AVIC Optoelectronics Co., Ltd. axis Axis Communications AB bosch Bosch Sensortec GmbH +boundary Boundary Devices Inc. brcm Broadcom Corporation buffalo Buffalo, Inc. calxeda Calxeda @@ -171,6 +172,7 @@ pericom Pericom Technology Inc. phytec PHYTEC Messtechnik GmbH picochip Picochip Ltd plathome Plat'Home Co., Ltd. +plda PLDA pixcir PIXCIR MICROELECTRONICS Co., Ltd pulsedlight PulsedLight, Inc powervr PowerVR (deprecated, use img) @@ -228,6 +230,7 @@ toradex Toradex AG toshiba Toshiba Corporation toumaz Toumaz tplink TP-LINK Technologies Co., Ltd. +tronfy Tronfy truly Truly Semiconductors Limited upisemi uPI Semiconductor Corp. usi Universal Scientific Industrial Co., Ltd. diff --git a/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt new file mode 100644 index 000000000000..84122270be8f --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt @@ -0,0 +1,19 @@ +BCM7038 Watchdog timer + +Required properties: + +- compatible : should be "brcm,bcm7038-wdt" +- reg : Specifies base physical address and size of the registers. + +Optional properties: + +- clocks: The clock running the watchdog. If no clock is found the + driver will default to 27000000 Hz. + +Example: + +watchdog@f040a7e8 { + compatible = "brcm,bcm7038-wdt"; + clocks = <&upg_fixed>; + reg = <0xf040a7e8 0x16>; +}; diff --git a/Documentation/dontdiff b/Documentation/dontdiff index 9de9813d0ec5..8ea834f6b289 100644 --- a/Documentation/dontdiff +++ b/Documentation/dontdiff @@ -165,7 +165,6 @@ mach-types.h machtypes.h map map_hugetlb -media mconf miboot* mk_elfconfig diff --git a/Documentation/email-clients.txt b/Documentation/email-clients.txt index aba85b39a400..2d485dea8cec 100644 --- a/Documentation/email-clients.txt +++ b/Documentation/email-clients.txt @@ -176,11 +176,47 @@ To use 'vim' with mutt: if you want to include the patch inline. (a)ttach works fine without "set paste". +You can also generate patches with 'git format-patch' and then use Mutt +to send them: + $ mutt -H 0001-some-bug-fix.patch + Config options: It should work with default settings. However, it's a good idea to set the "send_charset" to: set send_charset="us-ascii:utf-8" +Mutt is highly customizable. Here is a minimum configuration to start +using Mutt to send patches through Gmail: + +# .muttrc +# ================ IMAP ==================== +set imap_user = 'yourusername@gmail.com' +set imap_pass = 'yourpassword' +set spoolfile = imaps://imap.gmail.com/INBOX +set folder = imaps://imap.gmail.com/ +set record="imaps://imap.gmail.com/[Gmail]/Sent Mail" +set postponed="imaps://imap.gmail.com/[Gmail]/Drafts" +set mbox="imaps://imap.gmail.com/[Gmail]/All Mail" + +# ================ SMTP ==================== +set smtp_url = "smtp://username@smtp.gmail.com:587/" +set smtp_pass = $imap_pass +set ssl_force_tls = yes # Require encrypted connection + +# ================ Composition ==================== +set editor = `echo \$EDITOR` +set edit_headers = yes # See the headers when editing +set charset = UTF-8 # value of $LANG; also fallback for send_charset +# Sender, email address, and sign-off line must match +unset use_domain # because joe@localhost is just embarrassing +set realname = "YOUR NAME" +set from = "username@gmail.com" +set use_from = yes + +The Mutt docs have lots more information: + http://dev.mutt.org/trac/wiki/UseCases/Gmail + http://dev.mutt.org/doc/manual.html + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Pine (TUI) diff --git a/Documentation/filesystems/Makefile b/Documentation/filesystems/Makefile index 13483d192ebb..883010ce5e35 100644 --- a/Documentation/filesystems/Makefile +++ b/Documentation/filesystems/Makefile @@ -1,5 +1,3 @@ -subdir-y := configfs - # List of programs to build hostprogs-y := dnotify_test diff --git a/Documentation/filesystems/configfs/Makefile b/Documentation/filesystems/configfs/Makefile deleted file mode 100644 index be7ec5e67dbc..000000000000 --- a/Documentation/filesystems/configfs/Makefile +++ /dev/null @@ -1,3 +0,0 @@ -ifneq ($(CONFIG_CONFIGFS_FS),) -obj-m += configfs_example_explicit.o configfs_example_macros.o -endif diff --git a/Documentation/filesystems/configfs/configfs.txt b/Documentation/filesystems/configfs/configfs.txt index b40fec9d3f53..af68efdbbfad 100644 --- a/Documentation/filesystems/configfs/configfs.txt +++ b/Documentation/filesystems/configfs/configfs.txt @@ -160,12 +160,6 @@ among other things. For that, it needs a type. struct configfs_item_operations { void (*release)(struct config_item *); - ssize_t (*show_attribute)(struct config_item *, - struct configfs_attribute *, - char *); - ssize_t (*store_attribute)(struct config_item *, - struct configfs_attribute *, - const char *, size_t); int (*allow_link)(struct config_item *src, struct config_item *target); int (*drop_link)(struct config_item *src, @@ -183,9 +177,7 @@ The most basic function of a config_item_type is to define what operations can be performed on a config_item. All items that have been allocated dynamically will need to provide the ct_item_ops->release() method. This method is called when the config_item's reference count -reaches zero. Items that wish to display an attribute need to provide -the ct_item_ops->show_attribute() method. Similarly, storing a new -attribute value uses the store_attribute() method. +reaches zero. [struct configfs_attribute] @@ -193,6 +185,8 @@ attribute value uses the store_attribute() method. char *ca_name; struct module *ca_owner; umode_t ca_mode; + ssize_t (*show)(struct config_item *, char *); + ssize_t (*store)(struct config_item *, const char *, size_t); }; When a config_item wants an attribute to appear as a file in the item's @@ -202,10 +196,10 @@ config_item_type->ct_attrs. When the item appears in configfs, the attribute file will appear with the configfs_attribute->ca_name filename. configfs_attribute->ca_mode specifies the file permissions. -If an attribute is readable and the config_item provides a -ct_item_ops->show_attribute() method, that method will be called -whenever userspace asks for a read(2) on the attribute. The converse -will happen for write(2). +If an attribute is readable and provides a ->show method, that method will +be called whenever userspace asks for a read(2) on the attribute. If an +attribute is writable and provides a ->store method, that method will be +be called whenever userspace asks for a write(2) on the attribute. [struct config_group] @@ -311,20 +305,10 @@ the subsystem must be ready for it. [An Example] The best example of these basic concepts is the simple_children -subsystem/group and the simple_child item in configfs_example_explicit.c -and configfs_example_macros.c. It shows a trivial object displaying and -storing an attribute, and a simple group creating and destroying these -children. - -The only difference between configfs_example_explicit.c and -configfs_example_macros.c is how the attributes of the childless item -are defined. The childless item has extended attributes, each with -their own show()/store() operation. This follows a convention commonly -used in sysfs. configfs_example_explicit.c creates these attributes -by explicitly defining the structures involved. Conversely -configfs_example_macros.c uses some convenience macros from configfs.h -to define the attributes. These macros are similar to their sysfs -counterparts. +subsystem/group and the simple_child item in +samples/configfs/configfs_sample.c. It shows a trivial object displaying +and storing an attribute, and a simple group creating and destroying +these children. [Hierarchy Navigation and the Subsystem Mutex] diff --git a/Documentation/filesystems/configfs/configfs_example_explicit.c b/Documentation/filesystems/configfs/configfs_example_explicit.c deleted file mode 100644 index 1420233dfa55..000000000000 --- a/Documentation/filesystems/configfs/configfs_example_explicit.c +++ /dev/null @@ -1,483 +0,0 @@ -/* - * vim: noexpandtab ts=8 sts=0 sw=8: - * - * configfs_example_explicit.c - This file is a demonstration module - * containing a number of configfs subsystems. It explicitly defines - * each structure without using the helper macros defined in - * configfs.h. - * - * 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., 59 Temple Place - Suite 330, - * Boston, MA 021110-1307, USA. - * - * Based on sysfs: - * sysfs is Copyright (C) 2001, 2002, 2003 Patrick Mochel - * - * configfs Copyright (C) 2005 Oracle. All rights reserved. - */ - -#include <linux/init.h> -#include <linux/module.h> -#include <linux/slab.h> - -#include <linux/configfs.h> - - - -/* - * 01-childless - * - * This first example is a childless subsystem. It cannot create - * any config_items. It just has attributes. - * - * Note that we are enclosing the configfs_subsystem inside a container. - * This is not necessary if a subsystem has no attributes directly - * on the subsystem. See the next example, 02-simple-children, for - * such a subsystem. - */ - -struct childless { - struct configfs_subsystem subsys; - int showme; - int storeme; -}; - -struct childless_attribute { - struct configfs_attribute attr; - ssize_t (*show)(struct childless *, char *); - ssize_t (*store)(struct childless *, const char *, size_t); -}; - -static inline struct childless *to_childless(struct config_item *item) -{ - return item ? container_of(to_configfs_subsystem(to_config_group(item)), struct childless, subsys) : NULL; -} - -static ssize_t childless_showme_read(struct childless *childless, - char *page) -{ - ssize_t pos; - - pos = sprintf(page, "%d\n", childless->showme); - childless->showme++; - - return pos; -} - -static ssize_t childless_storeme_read(struct childless *childless, - char *page) -{ - return sprintf(page, "%d\n", childless->storeme); -} - -static ssize_t childless_storeme_write(struct childless *childless, - const char *page, - size_t count) -{ - unsigned long tmp; - char *p = (char *) page; - - tmp = simple_strtoul(p, &p, 10); - if ((*p != '\0') && (*p != '\n')) - return -EINVAL; - - if (tmp > INT_MAX) - return -ERANGE; - - childless->storeme = tmp; - - return count; -} - -static ssize_t childless_description_read(struct childless *childless, - char *page) -{ - return sprintf(page, -"[01-childless]\n" -"\n" -"The childless subsystem is the simplest possible subsystem in\n" -"configfs. It does not support the creation of child config_items.\n" -"It only has a few attributes. In fact, it isn't much different\n" -"than a directory in /proc.\n"); -} - -static struct childless_attribute childless_attr_showme = { - .attr = { .ca_owner = THIS_MODULE, .ca_name = "showme", .ca_mode = S_IRUGO }, - .show = childless_showme_read, -}; -static struct childless_attribute childless_attr_storeme = { - .attr = { .ca_owner = THIS_MODULE, .ca_name = "storeme", .ca_mode = S_IRUGO | S_IWUSR }, - .show = childless_storeme_read, - .store = childless_storeme_write, -}; -static struct childless_attribute childless_attr_description = { - .attr = { .ca_owner = THIS_MODULE, .ca_name = "description", .ca_mode = S_IRUGO }, - .show = childless_description_read, -}; - -static struct configfs_attribute *childless_attrs[] = { - &childless_attr_showme.attr, - &childless_attr_storeme.attr, - &childless_attr_description.attr, - NULL, -}; - -static ssize_t childless_attr_show(struct config_item *item, - struct configfs_attribute *attr, - char *page) -{ - struct childless *childless = to_childless(item); - struct childless_attribute *childless_attr = - container_of(attr, struct childless_attribute, attr); - ssize_t ret = 0; - - if (childless_attr->show) - ret = childless_attr->show(childless, page); - return ret; -} - -static ssize_t childless_attr_store(struct config_item *item, - struct configfs_attribute *attr, - const char *page, size_t count) -{ - struct childless *childless = to_childless(item); - struct childless_attribute *childless_attr = - container_of(attr, struct childless_attribute, attr); - ssize_t ret = -EINVAL; - - if (childless_attr->store) - ret = childless_attr->store(childless, page, count); - return ret; -} - -static struct configfs_item_operations childless_item_ops = { - .show_attribute = childless_attr_show, - .store_attribute = childless_attr_store, -}; - -static struct config_item_type childless_type = { - .ct_item_ops = &childless_item_ops, - .ct_attrs = childless_attrs, - .ct_owner = THIS_MODULE, -}; - -static struct childless childless_subsys = { - .subsys = { - .su_group = { - .cg_item = { - .ci_namebuf = "01-childless", - .ci_type = &childless_type, - }, - }, - }, -}; - - -/* ----------------------------------------------------------------- */ - -/* - * 02-simple-children - * - * This example merely has a simple one-attribute child. Note that - * there is no extra attribute structure, as the child's attribute is - * known from the get-go. Also, there is no container for the - * subsystem, as it has no attributes of its own. - */ - -struct simple_child { - struct config_item item; - int storeme; -}; - -static inline struct simple_child *to_simple_child(struct config_item *item) -{ - return item ? container_of(item, struct simple_child, item) : NULL; -} - -static struct configfs_attribute simple_child_attr_storeme = { - .ca_owner = THIS_MODULE, - .ca_name = "storeme", - .ca_mode = S_IRUGO | S_IWUSR, -}; - -static struct configfs_attribute *simple_child_attrs[] = { - &simple_child_attr_storeme, - NULL, -}; - -static ssize_t simple_child_attr_show(struct config_item *item, - struct configfs_attribute *attr, - char *page) -{ - ssize_t count; - struct simple_child *simple_child = to_simple_child(item); - - count = sprintf(page, "%d\n", simple_child->storeme); - - return count; -} - -static ssize_t simple_child_attr_store(struct config_item *item, - struct configfs_attribute *attr, - const char *page, size_t count) -{ - struct simple_child *simple_child = to_simple_child(item); - unsigned long tmp; - char *p = (char *) page; - - tmp = simple_strtoul(p, &p, 10); - if (!p || (*p && (*p != '\n'))) - return -EINVAL; - - if (tmp > INT_MAX) - return -ERANGE; - - simple_child->storeme = tmp; - - return count; -} - -static void simple_child_release(struct config_item *item) -{ - kfree(to_simple_child(item)); -} - -static struct configfs_item_operations simple_child_item_ops = { - .release = simple_child_release, - .show_attribute = simple_child_attr_show, - .store_attribute = simple_child_attr_store, -}; - -static struct config_item_type simple_child_type = { - .ct_item_ops = &simple_child_item_ops, - .ct_attrs = simple_child_attrs, - .ct_owner = THIS_MODULE, -}; - - -struct simple_children { - struct config_group group; -}; - -static inline struct simple_children *to_simple_children(struct config_item *item) -{ - return item ? container_of(to_config_group(item), struct simple_children, group) : NULL; -} - -static struct config_item *simple_children_make_item(struct config_group *group, const char *name) -{ - struct simple_child *simple_child; - - simple_child = kzalloc(sizeof(struct simple_child), GFP_KERNEL); - if (!simple_child) - return ERR_PTR(-ENOMEM); - - config_item_init_type_name(&simple_child->item, name, - &simple_child_type); - - simple_child->storeme = 0; - - return &simple_child->item; -} - -static struct configfs_attribute simple_children_attr_description = { - .ca_owner = THIS_MODULE, - .ca_name = "description", - .ca_mode = S_IRUGO, -}; - -static struct configfs_attribute *simple_children_attrs[] = { - &simple_children_attr_description, - NULL, -}; - -static ssize_t simple_children_attr_show(struct config_item *item, - struct configfs_attribute *attr, - char *page) -{ - return sprintf(page, -"[02-simple-children]\n" -"\n" -"This subsystem allows the creation of child config_items. These\n" -"items have only one attribute that is readable and writeable.\n"); -} - -static void simple_children_release(struct config_item *item) -{ - kfree(to_simple_children(item)); -} - -static struct configfs_item_operations simple_children_item_ops = { - .release = simple_children_release, - .show_attribute = simple_children_attr_show, -}; - -/* - * Note that, since no extra work is required on ->drop_item(), - * no ->drop_item() is provided. - */ -static struct configfs_group_operations simple_children_group_ops = { - .make_item = simple_children_make_item, -}; - -static struct config_item_type simple_children_type = { - .ct_item_ops = &simple_children_item_ops, - .ct_group_ops = &simple_children_group_ops, - .ct_attrs = simple_children_attrs, - .ct_owner = THIS_MODULE, -}; - -static struct configfs_subsystem simple_children_subsys = { - .su_group = { - .cg_item = { - .ci_namebuf = "02-simple-children", - .ci_type = &simple_children_type, - }, - }, -}; - - -/* ----------------------------------------------------------------- */ - -/* - * 03-group-children - * - * This example reuses the simple_children group from above. However, - * the simple_children group is not the subsystem itself, it is a - * child of the subsystem. Creation of a group in the subsystem creates - * a new simple_children group. That group can then have simple_child - * children of its own. - */ - -static struct config_group *group_children_make_group(struct config_group *group, const char *name) -{ - struct simple_children *simple_children; - - simple_children = kzalloc(sizeof(struct simple_children), - GFP_KERNEL); - if (!simple_children) - return ERR_PTR(-ENOMEM); - - config_group_init_type_name(&simple_children->group, name, - &simple_children_type); - - return &simple_children->group; -} - -static struct configfs_attribute group_children_attr_description = { - .ca_owner = THIS_MODULE, - .ca_name = "description", - .ca_mode = S_IRUGO, -}; - -static struct configfs_attribute *group_children_attrs[] = { - &group_children_attr_description, - NULL, -}; - -static ssize_t group_children_attr_show(struct config_item *item, - struct configfs_attribute *attr, - char *page) -{ - return sprintf(page, -"[03-group-children]\n" -"\n" -"This subsystem allows the creation of child config_groups. These\n" -"groups are like the subsystem simple-children.\n"); -} - -static struct configfs_item_operations group_children_item_ops = { - .show_attribute = group_children_attr_show, -}; - -/* - * Note that, since no extra work is required on ->drop_item(), - * no ->drop_item() is provided. - */ -static struct configfs_group_operations group_children_group_ops = { - .make_group = group_children_make_group, -}; - -static struct config_item_type group_children_type = { - .ct_item_ops = &group_children_item_ops, - .ct_group_ops = &group_children_group_ops, - .ct_attrs = group_children_attrs, - .ct_owner = THIS_MODULE, -}; - -static struct configfs_subsystem group_children_subsys = { - .su_group = { - .cg_item = { - .ci_namebuf = "03-group-children", - .ci_type = &group_children_type, - }, - }, -}; - -/* ----------------------------------------------------------------- */ - -/* - * We're now done with our subsystem definitions. - * For convenience in this module, here's a list of them all. It - * allows the init function to easily register them. Most modules - * will only have one subsystem, and will only call register_subsystem - * on it directly. - */ -static struct configfs_subsystem *example_subsys[] = { - &childless_subsys.subsys, - &simple_children_subsys, - &group_children_subsys, - NULL, -}; - -static int __init configfs_example_init(void) -{ - int ret; - int i; - struct configfs_subsystem *subsys; - - for (i = 0; example_subsys[i]; i++) { - subsys = example_subsys[i]; - - config_group_init(&subsys->su_group); - mutex_init(&subsys->su_mutex); - ret = configfs_register_subsystem(subsys); - if (ret) { - printk(KERN_ERR "Error %d while registering subsystem %s\n", - ret, - subsys->su_group.cg_item.ci_namebuf); - goto out_unregister; - } - } - - return 0; - -out_unregister: - for (i--; i >= 0; i--) - configfs_unregister_subsystem(example_subsys[i]); - - return ret; -} - -static void __exit configfs_example_exit(void) -{ - int i; - - for (i = 0; example_subsys[i]; i++) - configfs_unregister_subsystem(example_subsys[i]); -} - -module_init(configfs_example_init); -module_exit(configfs_example_exit); -MODULE_LICENSE("GPL"); diff --git a/Documentation/filesystems/configfs/configfs_example_macros.c b/Documentation/filesystems/configfs/configfs_example_macros.c deleted file mode 100644 index 327dfbc640a9..000000000000 --- a/Documentation/filesystems/configfs/configfs_example_macros.c +++ /dev/null @@ -1,446 +0,0 @@ -/* - * vim: noexpandtab ts=8 sts=0 sw=8: - * - * configfs_example_macros.c - This file is a demonstration module - * containing a number of configfs subsystems. It uses the helper - * macros defined by configfs.h - * - * 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., 59 Temple Place - Suite 330, - * Boston, MA 021110-1307, USA. - * - * Based on sysfs: - * sysfs is Copyright (C) 2001, 2002, 2003 Patrick Mochel - * - * configfs Copyright (C) 2005 Oracle. All rights reserved. - */ - -#include <linux/init.h> -#include <linux/module.h> -#include <linux/slab.h> - -#include <linux/configfs.h> - - - -/* - * 01-childless - * - * This first example is a childless subsystem. It cannot create - * any config_items. It just has attributes. - * - * Note that we are enclosing the configfs_subsystem inside a container. - * This is not necessary if a subsystem has no attributes directly - * on the subsystem. See the next example, 02-simple-children, for - * such a subsystem. - */ - -struct childless { - struct configfs_subsystem subsys; - int showme; - int storeme; -}; - -static inline struct childless *to_childless(struct config_item *item) -{ - return item ? container_of(to_configfs_subsystem(to_config_group(item)), struct childless, subsys) : NULL; -} - -CONFIGFS_ATTR_STRUCT(childless); -#define CHILDLESS_ATTR(_name, _mode, _show, _store) \ -struct childless_attribute childless_attr_##_name = __CONFIGFS_ATTR(_name, _mode, _show, _store) -#define CHILDLESS_ATTR_RO(_name, _show) \ -struct childless_attribute childless_attr_##_name = __CONFIGFS_ATTR_RO(_name, _show); - -static ssize_t childless_showme_read(struct childless *childless, - char *page) -{ - ssize_t pos; - - pos = sprintf(page, "%d\n", childless->showme); - childless->showme++; - - return pos; -} - -static ssize_t childless_storeme_read(struct childless *childless, - char *page) -{ - return sprintf(page, "%d\n", childless->storeme); -} - -static ssize_t childless_storeme_write(struct childless *childless, - const char *page, - size_t count) -{ - unsigned long tmp; - char *p = (char *) page; - - tmp = simple_strtoul(p, &p, 10); - if (!p || (*p && (*p != '\n'))) - return -EINVAL; - - if (tmp > INT_MAX) - return -ERANGE; - - childless->storeme = tmp; - - return count; -} - -static ssize_t childless_description_read(struct childless *childless, - char *page) -{ - return sprintf(page, -"[01-childless]\n" -"\n" -"The childless subsystem is the simplest possible subsystem in\n" -"configfs. It does not support the creation of child config_items.\n" -"It only has a few attributes. In fact, it isn't much different\n" -"than a directory in /proc.\n"); -} - -CHILDLESS_ATTR_RO(showme, childless_showme_read); -CHILDLESS_ATTR(storeme, S_IRUGO | S_IWUSR, childless_storeme_read, - childless_storeme_write); -CHILDLESS_ATTR_RO(description, childless_description_read); - -static struct configfs_attribute *childless_attrs[] = { - &childless_attr_showme.attr, - &childless_attr_storeme.attr, - &childless_attr_description.attr, - NULL, -}; - -CONFIGFS_ATTR_OPS(childless); -static struct configfs_item_operations childless_item_ops = { - .show_attribute = childless_attr_show, - .store_attribute = childless_attr_store, -}; - -static struct config_item_type childless_type = { - .ct_item_ops = &childless_item_ops, - .ct_attrs = childless_attrs, - .ct_owner = THIS_MODULE, -}; - -static struct childless childless_subsys = { - .subsys = { - .su_group = { - .cg_item = { - .ci_namebuf = "01-childless", - .ci_type = &childless_type, - }, - }, - }, -}; - - -/* ----------------------------------------------------------------- */ - -/* - * 02-simple-children - * - * This example merely has a simple one-attribute child. Note that - * there is no extra attribute structure, as the child's attribute is - * known from the get-go. Also, there is no container for the - * subsystem, as it has no attributes of its own. - */ - -struct simple_child { - struct config_item item; - int storeme; -}; - -static inline struct simple_child *to_simple_child(struct config_item *item) -{ - return item ? container_of(item, struct simple_child, item) : NULL; -} - -static struct configfs_attribute simple_child_attr_storeme = { - .ca_owner = THIS_MODULE, - .ca_name = "storeme", - .ca_mode = S_IRUGO | S_IWUSR, -}; - -static struct configfs_attribute *simple_child_attrs[] = { - &simple_child_attr_storeme, - NULL, -}; - -static ssize_t simple_child_attr_show(struct config_item *item, - struct configfs_attribute *attr, - char *page) -{ - ssize_t count; - struct simple_child *simple_child = to_simple_child(item); - - count = sprintf(page, "%d\n", simple_child->storeme); - - return count; -} - -static ssize_t simple_child_attr_store(struct config_item *item, - struct configfs_attribute *attr, - const char *page, size_t count) -{ - struct simple_child *simple_child = to_simple_child(item); - unsigned long tmp; - char *p = (char *) page; - - tmp = simple_strtoul(p, &p, 10); - if (!p || (*p && (*p != '\n'))) - return -EINVAL; - - if (tmp > INT_MAX) - return -ERANGE; - - simple_child->storeme = tmp; - - return count; -} - -static void simple_child_release(struct config_item *item) -{ - kfree(to_simple_child(item)); -} - -static struct configfs_item_operations simple_child_item_ops = { - .release = simple_child_release, - .show_attribute = simple_child_attr_show, - .store_attribute = simple_child_attr_store, -}; - -static struct config_item_type simple_child_type = { - .ct_item_ops = &simple_child_item_ops, - .ct_attrs = simple_child_attrs, - .ct_owner = THIS_MODULE, -}; - - -struct simple_children { - struct config_group group; -}; - -static inline struct simple_children *to_simple_children(struct config_item *item) -{ - return item ? container_of(to_config_group(item), struct simple_children, group) : NULL; -} - -static struct config_item *simple_children_make_item(struct config_group *group, const char *name) -{ - struct simple_child *simple_child; - - simple_child = kzalloc(sizeof(struct simple_child), GFP_KERNEL); - if (!simple_child) - return ERR_PTR(-ENOMEM); - - config_item_init_type_name(&simple_child->item, name, - &simple_child_type); - - simple_child->storeme = 0; - - return &simple_child->item; -} - -static struct configfs_attribute simple_children_attr_description = { - .ca_owner = THIS_MODULE, - .ca_name = "description", - .ca_mode = S_IRUGO, -}; - -static struct configfs_attribute *simple_children_attrs[] = { - &simple_children_attr_description, - NULL, -}; - -static ssize_t simple_children_attr_show(struct config_item *item, - struct configfs_attribute *attr, - char *page) -{ - return sprintf(page, -"[02-simple-children]\n" -"\n" -"This subsystem allows the creation of child config_items. These\n" -"items have only one attribute that is readable and writeable.\n"); -} - -static void simple_children_release(struct config_item *item) -{ - kfree(to_simple_children(item)); -} - -static struct configfs_item_operations simple_children_item_ops = { - .release = simple_children_release, - .show_attribute = simple_children_attr_show, -}; - -/* - * Note that, since no extra work is required on ->drop_item(), - * no ->drop_item() is provided. - */ -static struct configfs_group_operations simple_children_group_ops = { - .make_item = simple_children_make_item, -}; - -static struct config_item_type simple_children_type = { - .ct_item_ops = &simple_children_item_ops, - .ct_group_ops = &simple_children_group_ops, - .ct_attrs = simple_children_attrs, - .ct_owner = THIS_MODULE, -}; - -static struct configfs_subsystem simple_children_subsys = { - .su_group = { - .cg_item = { - .ci_namebuf = "02-simple-children", - .ci_type = &simple_children_type, - }, - }, -}; - - -/* ----------------------------------------------------------------- */ - -/* - * 03-group-children - * - * This example reuses the simple_children group from above. However, - * the simple_children group is not the subsystem itself, it is a - * child of the subsystem. Creation of a group in the subsystem creates - * a new simple_children group. That group can then have simple_child - * children of its own. - */ - -static struct config_group *group_children_make_group(struct config_group *group, const char *name) -{ - struct simple_children *simple_children; - - simple_children = kzalloc(sizeof(struct simple_children), - GFP_KERNEL); - if (!simple_children) - return ERR_PTR(-ENOMEM); - - config_group_init_type_name(&simple_children->group, name, - &simple_children_type); - - return &simple_children->group; -} - -static struct configfs_attribute group_children_attr_description = { - .ca_owner = THIS_MODULE, - .ca_name = "description", - .ca_mode = S_IRUGO, -}; - -static struct configfs_attribute *group_children_attrs[] = { - &group_children_attr_description, - NULL, -}; - -static ssize_t group_children_attr_show(struct config_item *item, - struct configfs_attribute *attr, - char *page) -{ - return sprintf(page, -"[03-group-children]\n" -"\n" -"This subsystem allows the creation of child config_groups. These\n" -"groups are like the subsystem simple-children.\n"); -} - -static struct configfs_item_operations group_children_item_ops = { - .show_attribute = group_children_attr_show, -}; - -/* - * Note that, since no extra work is required on ->drop_item(), - * no ->drop_item() is provided. - */ -static struct configfs_group_operations group_children_group_ops = { - .make_group = group_children_make_group, -}; - -static struct config_item_type group_children_type = { - .ct_item_ops = &group_children_item_ops, - .ct_group_ops = &group_children_group_ops, - .ct_attrs = group_children_attrs, - .ct_owner = THIS_MODULE, -}; - -static struct configfs_subsystem group_children_subsys = { - .su_group = { - .cg_item = { - .ci_namebuf = "03-group-children", - .ci_type = &group_children_type, - }, - }, -}; - -/* ----------------------------------------------------------------- */ - -/* - * We're now done with our subsystem definitions. - * For convenience in this module, here's a list of them all. It - * allows the init function to easily register them. Most modules - * will only have one subsystem, and will only call register_subsystem - * on it directly. - */ -static struct configfs_subsystem *example_subsys[] = { - &childless_subsys.subsys, - &simple_children_subsys, - &group_children_subsys, - NULL, -}; - -static int __init configfs_example_init(void) -{ - int ret; - int i; - struct configfs_subsystem *subsys; - - for (i = 0; example_subsys[i]; i++) { - subsys = example_subsys[i]; - - config_group_init(&subsys->su_group); - mutex_init(&subsys->su_mutex); - ret = configfs_register_subsystem(subsys); - if (ret) { - printk(KERN_ERR "Error %d while registering subsystem %s\n", - ret, - subsys->su_group.cg_item.ci_namebuf); - goto out_unregister; - } - } - - return 0; - -out_unregister: - for (i--; i >= 0; i--) - configfs_unregister_subsystem(example_subsys[i]); - - return ret; -} - -static void __exit configfs_example_exit(void) -{ - int i; - - for (i = 0; example_subsys[i]; i++) - configfs_unregister_subsystem(example_subsys[i]); -} - -module_init(configfs_example_init); -module_exit(configfs_example_exit); -MODULE_LICENSE("GPL"); diff --git a/Documentation/filesystems/gfs2-glocks.txt b/Documentation/filesystems/gfs2-glocks.txt index fcc79957be63..1fb12f9dfe48 100644 --- a/Documentation/filesystems/gfs2-glocks.txt +++ b/Documentation/filesystems/gfs2-glocks.txt @@ -5,7 +5,7 @@ This documents the basic principles of the glock state machine internals. Each glock (struct gfs2_glock in fs/gfs2/incore.h) has two main (internal) locks: - 1. A spinlock (gl_spin) which protects the internal state such + 1. A spinlock (gl_lockref.lock) which protects the internal state such as gl_state, gl_target and the list of holders (gl_holders) 2. A non-blocking bit lock, GLF_LOCK, which is used to prevent other threads from making calls to the DLM, etc. at the same time. If a @@ -82,8 +82,8 @@ rather than via the glock. Locking rules for glock operations: -Operation | GLF_LOCK bit lock held | gl_spin spinlock held ------------------------------------------------------------------ +Operation | GLF_LOCK bit lock held | gl_lockref.lock spinlock held +------------------------------------------------------------------------- go_xmote_th | Yes | No go_xmote_bh | Yes | No go_inval | Yes | No diff --git a/Documentation/filesystems/overlayfs.txt b/Documentation/filesystems/overlayfs.txt index 6db0e5d1da07..28091457b71a 100644 --- a/Documentation/filesystems/overlayfs.txt +++ b/Documentation/filesystems/overlayfs.txt @@ -1,4 +1,5 @@ -Written by: Neil Brown <neilb@suse.de> +Written by: Neil Brown +Please see MAINTAINERS file for where to send questions. Overlay Filesystem ================== diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index 1e4a6cc1b6ea..402ab99e409f 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -1605,16 +1605,16 @@ Documentation/accounting. --------------------------------------------------------------- When a process is dumped, all anonymous memory is written to a core file as long as the size of the core file isn't limited. But sometimes we don't want -to dump some memory segments, for example, huge shared memory. Conversely, -sometimes we want to save file-backed memory segments into a core file, not -only the individual files. +to dump some memory segments, for example, huge shared memory or DAX. +Conversely, sometimes we want to save file-backed memory segments into a core +file, not only the individual files. /proc/<pid>/coredump_filter allows you to customize which memory segments will be dumped when the <pid> process is dumped. coredump_filter is a bitmask of memory types. If a bit of the bitmask is set, memory segments of the corresponding memory type are dumped, otherwise they are not dumped. -The following 7 memory types are supported: +The following 9 memory types are supported: - (bit 0) anonymous private memory - (bit 1) anonymous shared memory - (bit 2) file-backed private memory @@ -1623,20 +1623,22 @@ The following 7 memory types are supported: effective only if the bit 2 is cleared) - (bit 5) hugetlb private memory - (bit 6) hugetlb shared memory + - (bit 7) DAX private memory + - (bit 8) DAX shared memory Note that MMIO pages such as frame buffer are never dumped and vDSO pages are always dumped regardless of the bitmask status. - Note bit 0-4 doesn't effect any hugetlb memory. hugetlb memory are only - effected by bit 5-6. + Note that bits 0-4 don't affect hugetlb or DAX memory. hugetlb memory is + only affected by bit 5-6, and DAX is only affected by bits 7-8. -Default value of coredump_filter is 0x23; this means all anonymous memory -segments and hugetlb private memory are dumped. +The default value of coredump_filter is 0x33; this means all anonymous memory +segments, ELF header pages and hugetlb private memory are dumped. If you don't want to dump all shared memory segments attached to pid 1234, -write 0x21 to the process's proc file. +write 0x31 to the process's proc file. - $ echo 0x21 > /proc/1234/coredump_filter + $ echo 0x31 > /proc/1234/coredump_filter When a new process is created, the process inherits the bitmask status from its parent. It is useful to set up coredump_filter before the program runs. diff --git a/Documentation/hwmon/scpi-hwmon b/Documentation/hwmon/scpi-hwmon new file mode 100644 index 000000000000..4cfcdf2d5eab --- /dev/null +++ b/Documentation/hwmon/scpi-hwmon @@ -0,0 +1,33 @@ +Kernel driver scpi-hwmon +======================== + +Supported chips: + * Chips based on ARM System Control Processor Interface + Addresses scanned: - + Datasheet: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/index.html + +Author: Punit Agrawal <punit.agrawal@arm.com> + +Description +----------- + +This driver supports hardware monitoring for SoC's based on the ARM +System Control Processor (SCP) implementing the System Control +Processor Interface (SCPI). The following sensor types are supported +by the SCP - + + * temperature + * voltage + * current + * power + +The SCP interface provides an API to query the available sensors and +their values which are then exported to userspace by this driver. + +Usage Notes +----------- + +The driver relies on device tree node to indicate the presence of SCPI +support in the kernel. See +Documentation/devicetree/bindings/arm/arm,scpi.txt for details of the +devicetree node.
\ No newline at end of file diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801 index 82f48f774afb..6a4b1af724f8 100644 --- a/Documentation/i2c/busses/i2c-i801 +++ b/Documentation/i2c/busses/i2c-i801 @@ -30,6 +30,8 @@ Supported adapters: * Intel BayTrail (SOC) * Intel Sunrise Point-H (PCH) * Intel Sunrise Point-LP (PCH) + * Intel DNV (SOC) + * Intel Broxton (SOC) Datasheets: Publicly available at the Intel website On Intel Patsburg and later chipsets, both the normal host SMBus controller diff --git a/Documentation/kbuild/Kconfig.recursion-issue-01 b/Documentation/kbuild/Kconfig.recursion-issue-01 new file mode 100644 index 000000000000..e8877db0461f --- /dev/null +++ b/Documentation/kbuild/Kconfig.recursion-issue-01 @@ -0,0 +1,57 @@ +# Simple Kconfig recursive issue +# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +# +# Test with: +# +# make KBUILD_KCONFIG=Documentation/kbuild/Kconfig.recursion-issue-01 allnoconfig +# +# This Kconfig file has a simple recursive dependency issue. In order to +# understand why this recursive dependency issue occurs lets consider what +# Kconfig needs to address. We iterate over what Kconfig needs to address +# by stepping through the questions it needs to address sequentially. +# +# * What values are possible for CORE? +# +# CORE_BELL_A_ADVANCED selects CORE, which means that it influences the values +# that are possible for CORE. So for example if CORE_BELL_A_ADVANCED is 'y', +# CORE must be 'y' too. +# +# * What influences CORE_BELL_A_ADVANCED ? +# +# As the name implies CORE_BELL_A_ADVANCED is an advanced feature of +# CORE_BELL_A so naturally it depends on CORE_BELL_A. So if CORE_BELL_A is 'y' +# we know CORE_BELL_A_ADVANCED can be 'y' too. +# +# * What influences CORE_BELL_A ? +# +# CORE_BELL_A depends on CORE, so CORE influences CORE_BELL_A. +# +# But that is a problem, because this means that in order to determine +# what values are possible for CORE we ended up needing to address questions +# regarding possible values of CORE itself again. Answering the original +# question of what are the possible values of CORE would make the kconfig +# tools run in a loop. When this happens Kconfig exits and complains about +# the "recursive dependency detected" error. +# +# Reading the Documentation/kbuild/Kconfig.recursion-issue-01 file it may be +# obvious that an easy to solution to this problem should just be the removal +# of the "select CORE" from CORE_BELL_A_ADVANCED as that is implicit already +# since CORE_BELL_A depends on CORE. Recursive dependency issues are not always +# so trivial to resolve, we provide another example below of practical +# implications of this recursive issue where the solution is perhaps not so +# easy to understand. Note that matching semantics on the dependency on +# CORE also consist of a solution to this recursive problem. + +mainmenu "Simple example to demo kconfig recursive dependency issue" + +config CORE + tristate + +config CORE_BELL_A + tristate + depends on CORE + +config CORE_BELL_A_ADVANCED + tristate + depends on CORE_BELL_A + select CORE diff --git a/Documentation/kbuild/Kconfig.recursion-issue-02 b/Documentation/kbuild/Kconfig.recursion-issue-02 new file mode 100644 index 000000000000..b9fd56c4b57e --- /dev/null +++ b/Documentation/kbuild/Kconfig.recursion-issue-02 @@ -0,0 +1,63 @@ +# Cumulative Kconfig recursive issue +# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +# +# Test with: +# +# make KBUILD_KCONFIG=Documentation/kbuild/Kconfig.recursion-issue-02 allnoconfig +# +# The recursive limitations with Kconfig has some non intuitive implications on +# kconfig sematics which are documented here. One known practical implication +# of the recursive limitation is that drivers cannot negate features from other +# drivers if they share a common core requirement and use disjoint semantics to +# annotate those requirements, ie, some drivers use "depends on" while others +# use "select". For instance it means if a driver A and driver B share the same +# core requirement, and one uses "select" while the other uses "depends on" to +# annotate this, all features that driver A selects cannot now be negated by +# driver B. +# +# A perhaps not so obvious implication of this is that, if semantics on these +# core requirements are not carefully synced, as drivers evolve features +# they select or depend on end up becoming shared requirements which cannot be +# negated by other drivers. +# +# The example provided in Documentation/kbuild/Kconfig.recursion-issue-02 +# describes a simple driver core layout of example features a kernel might +# have. Let's assume we have some CORE functionality, then the kernel has a +# series of bells and whistles it desires to implement, its not so advanced so +# it only supports bells at this time: CORE_BELL_A and CORE_BELL_B. If +# CORE_BELL_A has some advanced feature CORE_BELL_A_ADVANCED which selects +# CORE_BELL_A then CORE_BELL_A ends up becoming a common BELL feature which +# other bells in the system cannot negate. The reason for this issue is +# due to the disjoint use of semantics on expressing each bell's relationship +# with CORE, one uses "depends on" while the other uses "select". Another +# more important reason is that kconfig does not check for dependencies listed +# under 'select' for a symbol, when such symbols are selected kconfig them +# as mandatory required symbols. For more details on the heavy handed nature +# of select refer to Documentation/kbuild/Kconfig.select-break +# +# To fix this the "depends on CORE" must be changed to "select CORE", or the +# "select CORE" must be changed to "depends on CORE". +# +# For an example real world scenario issue refer to the attempt to remove +# "select FW_LOADER" [0], in the end the simple alternative solution to this +# problem consisted on matching semantics with newly introduced features. +# +# [0] http://lkml.kernel.org/r/1432241149-8762-1-git-send-email-mcgrof@do-not-panic.com + +mainmenu "Simple example to demo cumulative kconfig recursive dependency implication" + +config CORE + tristate + +config CORE_BELL_A + tristate + depends on CORE + +config CORE_BELL_A_ADVANCED + tristate + select CORE_BELL_A + +config CORE_BELL_B + tristate + depends on !CORE_BELL_A + select CORE diff --git a/Documentation/kbuild/Kconfig.select-break b/Documentation/kbuild/Kconfig.select-break new file mode 100644 index 000000000000..365ceb3424b1 --- /dev/null +++ b/Documentation/kbuild/Kconfig.select-break @@ -0,0 +1,33 @@ +# Select broken dependency issue +# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +# +# Test with: +# +# make KBUILD_KCONFIG=Documentation/kbuild/Kconfig.select-break menuconfig +# +# kconfig will not complain and enable this layout for configuration. This is +# currently a feature of kconfig, given select was designed to be heavy handed. +# Kconfig currently does not check the list of symbols listed on a symbol's +# "select" list, this is done on purpose to help load a set of known required +# symbols. Because of this use of select should be used with caution. An +# example of this issue is below. +# +# The option B and C are clearly contradicting with respect to A. +# However, when A is set, C can be set as well because Kconfig does not +# visit the dependencies of the select target (in this case B). And since +# Kconfig does not visit the dependencies, it breaks the dependencies of B +# (!A). + +mainmenu "Simple example to demo kconfig select broken dependency issue" + +config A + bool "CONFIG A" + +config B + bool "CONFIG B" + depends on !A + +config C + bool "CONFIG C" + depends on A + select B diff --git a/Documentation/kbuild/kconfig-language.txt b/Documentation/kbuild/kconfig-language.txt index 350f733bf2c7..c52856da0cad 100644 --- a/Documentation/kbuild/kconfig-language.txt +++ b/Documentation/kbuild/kconfig-language.txt @@ -393,3 +393,164 @@ config FOO depends on BAR && m limits FOO to module (=m) or disabled (=n). + +Kconfig recursive dependency limitations +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If you've hit the Kconfig error: "recursive dependency detected" you've run +into a recursive dependency issue with Kconfig, a recursive dependency can be +summarized as a circular dependency. The kconfig tools need to ensure that +Kconfig files comply with specified configuration requirements. In order to do +that kconfig must determine the values that are possible for all Kconfig +symbols, this is currently not possible if there is a circular relation +between two or more Kconfig symbols. For more details refer to the "Simple +Kconfig recursive issue" subsection below. Kconfig does not do recursive +dependency resolution; this has a few implications for Kconfig file writers. +We'll first explain why this issues exists and then provide an example +technical limitation which this brings upon Kconfig developers. Eager +developers wishing to try to address this limitation should read the next +subsections. + +Simple Kconfig recursive issue +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Read: Documentation/kbuild/Kconfig.recursion-issue-01 + +Test with: + +make KBUILD_KCONFIG=Documentation/kbuild/Kconfig.recursion-issue-01 allnoconfig + +Cumulative Kconfig recursive issue +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Read: Documentation/kbuild/Kconfig.recursion-issue-02 + +Test with: + +make KBUILD_KCONFIG=Documentation/kbuild/Kconfig.recursion-issue-02 allnoconfig + +Practical solutions to kconfig recursive issue +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Developers who run into the recursive Kconfig issue have three options +at their disposal. We document them below and also provide a list of +historical issues resolved through these different solutions. + + a) Remove any superfluous "select FOO" or "depends on FOO" + b) Match dependency semantics: + b1) Swap all "select FOO" to "depends on FOO" or, + b2) Swap all "depends on FOO" to "select FOO" + +The resolution to a) can be tested with the sample Kconfig file +Documentation/kbuild/Kconfig.recursion-issue-01 through the removal +of the "select CORE" from CORE_BELL_A_ADVANCED as that is implicit already +since CORE_BELL_A depends on CORE. At times it may not be possible to remove +some dependency criteria, for such cases you can work with solution b). + +The two different resolutions for b) can be tested in the sample Kconfig file +Documentation/kbuild/Kconfig.recursion-issue-02. + +Below is a list of examples of prior fixes for these types of recursive issues; +all errors appear to involve one or more select's and one or more "depends on". + +commit fix +====== === +06b718c01208 select A -> depends on A +c22eacfe82f9 depends on A -> depends on B +6a91e854442c select A -> depends on A +118c565a8f2e select A -> select B +f004e5594705 select A -> depends on A +c7861f37b4c6 depends on A -> (null) +80c69915e5fb select A -> (null) (1) +c2218e26c0d0 select A -> depends on A (1) +d6ae99d04e1c select A -> depends on A +95ca19cf8cbf select A -> depends on A +8f057d7bca54 depends on A -> (null) +8f057d7bca54 depends on A -> select A +a0701f04846e select A -> depends on A +0c8b92f7f259 depends on A -> (null) +e4e9e0540928 select A -> depends on A (2) +7453ea886e87 depends on A > (null) (1) +7b1fff7e4fdf select A -> depends on A +86c747d2a4f0 select A -> depends on A +d9f9ab51e55e select A -> depends on A +0c51a4d8abd6 depends on A -> select A (3) +e98062ed6dc4 select A -> depends on A (3) +91e5d284a7f1 select A -> (null) + +(1) Partial (or no) quote of error. +(2) That seems to be the gist of that fix. +(3) Same error. + +Future kconfig work +~~~~~~~~~~~~~~~~~~~ + +Work on kconfig is welcomed on both areas of clarifying semantics and on +evaluating the use of a full SAT solver for it. A full SAT solver can be +desirable to enable more complex dependency mappings and / or queries, +for instance on possible use case for a SAT solver could be that of handling +the current known recursive dependency issues. It is not known if this would +address such issues but such evaluation is desirable. If support for a full SAT +solver proves too complex or that it cannot address recursive dependency issues +Kconfig should have at least clear and well defined semantics which also +addresses and documents limitations or requirements such as the ones dealing +with recursive dependencies. + +Further work on both of these areas is welcomed on Kconfig. We elaborate +on both of these in the next two subsections. + +Semantics of Kconfig +~~~~~~~~~~~~~~~~~~~~ + +The use of Kconfig is broad, Linux is now only one of Kconfig's users: +one study has completed a broad analysis of Kconfig use in 12 projects [0]. +Despite its widespread use, and although this document does a reasonable job +in documenting basic Kconfig syntax a more precise definition of Kconfig +semantics is welcomed. One project deduced Kconfig semantics through +the use of the xconfig configurator [1]. Work should be done to confirm if +the deduced semantics matches our intended Kconfig design goals. + +Having well defined semantics can be useful for tools for practical +evaluation of depenencies, for instance one such use known case was work to +express in boolean abstraction of the inferred semantics of Kconfig to +translate Kconfig logic into boolean formulas and run a SAT solver on this to +find dead code / features (always inactive), 114 dead features were found in +Linux using this methodology [1] (Section 8: Threats to validity). + +Confirming this could prove useful as Kconfig stands as one of the the leading +industrial variability modeling languages [1] [2]. Its study would help +evaluate practical uses of such languages, their use was only theoretical +and real world requirements were not well understood. As it stands though +only reverse engineering techniques have been used to deduce semantics from +variability modeling languages such as Kconfig [3]. + +[0] http://www.eng.uwaterloo.ca/~shshe/kconfig_semantics.pdf +[1] http://gsd.uwaterloo.ca/sites/default/files/vm-2013-berger.pdf +[2] http://gsd.uwaterloo.ca/sites/default/files/ase241-berger_0.pdf +[3] http://gsd.uwaterloo.ca/sites/default/files/icse2011.pdf + +Full SAT solver for Kconfig +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Although SAT solvers [0] haven't yet been used by Kconfig directly, as noted in +the previous subsection, work has been done however to express in boolean +abstraction the inferred semantics of Kconfig to translate Kconfig logic into +boolean formulas and run a SAT solver on it [1]. Another known related project +is CADOS [2] (former VAMOS [3]) and the tools, mainly undertaker [4], which has +been introduced first with [5]. The basic concept of undertaker is to exract +variability models from Kconfig, and put them together with a propositional +formula extracted from CPP #ifdefs and build-rules into a SAT solver in order +to find dead code, dead files, and dead symbols. If using a SAT solver is +desirable on Kconfig one approach would be to evaluate repurposing such efforts +somehow on Kconfig. There is enough interest from mentors of existing projects +to not only help advise how to integrate this work upstream but also help +maintain it long term. Interested developers should visit: + +http://kernelnewbies.org/KernelProjects/kconfig-sat + +[0] http://www.cs.cornell.edu/~sabhar/chapters/SATSolvers-KR-Handbook.pdf +[1] http://gsd.uwaterloo.ca/sites/default/files/vm-2013-berger.pdf +[2] https://cados.cs.fau.de +[3] https://vamos.cs.fau.de +[4] https://undertaker.cs.fau.de +[5] https://www4.cs.fau.de/Publications/2011/tartler_11_eurosys.pdf diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 84c0214b64a7..f8aae632f02f 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -932,11 +932,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. The filter can be disabled or changed to another driver later using sysfs. - drm_kms_helper.edid_firmware=[<connector>:]<file> - Broken monitors, graphic adapters and KVMs may - send no or incorrect EDID data sets. This parameter - allows to specify an EDID data set in the - /lib/firmware directory that is used instead. + drm_kms_helper.edid_firmware=[<connector>:]<file>[,[<connector>:]<file>] + Broken monitors, graphic adapters, KVMs and EDIDless + panels may send no or incorrect EDID data sets. + This parameter allows to specify an EDID data sets + in the /lib/firmware directory that are used instead. Generic built-in EDID data sets are used, if one of edid/1024x768.bin, edid/1280x1024.bin, edid/1680x1050.bin, or edid/1920x1080.bin is given @@ -945,7 +945,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted. available in Documentation/EDID/HOWTO.txt. An EDID data set will only be used for a particular connector, if its name and a colon are prepended to the EDID - name. + name. Each connector may use a unique EDID data + set by separating the files with a comma. An EDID + data set with no connector name will be used for + any connectors not explicitly specified. dscc4.setup= [NET] diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt index 4636b94518da..05fd83bb3596 100644 --- a/Documentation/networking/can.txt +++ b/Documentation/networking/can.txt @@ -681,7 +681,7 @@ solution for a couple of reasons: addr.can_family = AF_CAN; addr.can_ifindex = ifr.ifr_ifindex; - connect(s, (struct sockaddr *)&addr, sizeof(addr)) + connect(s, (struct sockaddr *)&addr, sizeof(addr)); (..) diff --git a/Documentation/networking/filter.txt b/Documentation/networking/filter.txt index 135581f015e1..96da119a47e7 100644 --- a/Documentation/networking/filter.txt +++ b/Documentation/networking/filter.txt @@ -596,9 +596,9 @@ skb pointer). All constraints and restrictions from bpf_check_classic() apply before a conversion to the new layout is being done behind the scenes! Currently, the classic BPF format is being used for JITing on most of the -architectures. Only x86-64 performs JIT compilation from eBPF instruction set, -however, future work will migrate other JIT compilers as well, so that they -will profit from the very same benefits. +architectures. x86-64, aarch64 and s390x perform JIT compilation from eBPF +instruction set, however, future work will migrate other JIT compilers as well, +so that they will profit from the very same benefits. Some core changes of the new internal format: diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index 05915be86235..2ea4c45cf1c8 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -709,7 +709,7 @@ tcp_limit_output_bytes - INTEGER typical pfifo_fast qdiscs. tcp_limit_output_bytes limits the number of bytes on qdisc or device to reduce artificial RTT/cwnd and reduce bufferbloat. - Default: 131072 + Default: 262144 tcp_challenge_ack_limit - INTEGER Limits number of Challenge ACK sent per second, as recommended diff --git a/Documentation/nvdimm/nvdimm.txt b/Documentation/nvdimm/nvdimm.txt index 197a0b6b0582..e894de69915a 100644 --- a/Documentation/nvdimm/nvdimm.txt +++ b/Documentation/nvdimm/nvdimm.txt @@ -62,6 +62,12 @@ DAX: File system extensions to bypass the page cache and block layer to mmap persistent memory, from a PMEM block device, directly into a process address space. +DSM: Device Specific Method: ACPI method to to control specific +device - in this case the firmware. + +DCR: NVDIMM Control Region Structure defined in ACPI 6 Section 5.2.25.5. +It defines a vendor-id, device-id, and interface format for a given DIMM. + BTT: Block Translation Table: Persistent memory is byte addressable. Existing software may have an expectation that the power-fail-atomicity of writes is at least one sector, 512 bytes. The BTT is an indirection @@ -133,16 +139,16 @@ device driver: registered, can be immediately attached to nd_pmem. 2. BLK (nd_blk.ko): This driver performs I/O using a set of platform - defined apertures. A set of apertures will all access just one DIMM. - Multiple windows allow multiple concurrent accesses, much like + defined apertures. A set of apertures will access just one DIMM. + Multiple windows (apertures) allow multiple concurrent accesses, much like tagged-command-queuing, and would likely be used by different threads or different CPUs. The NFIT specification defines a standard format for a BLK-aperture, but the spec also allows for vendor specific layouts, and non-NFIT BLK - implementations may other designs for BLK I/O. For this reason "nd_blk" - calls back into platform-specific code to perform the I/O. One such - implementation is defined in the "Driver Writer's Guide" and "DSM + implementations may have other designs for BLK I/O. For this reason + "nd_blk" calls back into platform-specific code to perform the I/O. + One such implementation is defined in the "Driver Writer's Guide" and "DSM Interface Example". @@ -152,7 +158,7 @@ Why BLK? While PMEM provides direct byte-addressable CPU-load/store access to NVDIMM storage, it does not provide the best system RAS (recovery, availability, and serviceability) model. An access to a corrupted -system-physical-address address causes a cpu exception while an access +system-physical-address address causes a CPU exception while an access to a corrupted address through an BLK-aperture causes that block window to raise an error status in a register. The latter is more aligned with the standard error model that host-bus-adapter attached disks present. @@ -162,7 +168,7 @@ data could be interleaved in an opaque hardware specific manner across several DIMMs. PMEM vs BLK -BLK-apertures solve this RAS problem, but their presence is also the +BLK-apertures solve these RAS problems, but their presence is also the major contributing factor to the complexity of the ND subsystem. They complicate the implementation because PMEM and BLK alias in DPA space. Any given DIMM's DPA-range may contribute to one or more @@ -220,8 +226,8 @@ socket. Each unique interface (BLK or PMEM) to DPA space is identified by a region device with a dynamically assigned id (REGION0 - REGION5). 1. The first portion of DIMM0 and DIMM1 are interleaved as REGION0. A - single PMEM namespace is created in the REGION0-SPA-range that spans - DIMM0 and DIMM1 with a user-specified name of "pm0.0". Some of that + single PMEM namespace is created in the REGION0-SPA-range that spans most + of DIMM0 and DIMM1 with a user-specified name of "pm0.0". Some of that interleaved system-physical-address range is reclaimed as BLK-aperture accessed space starting at DPA-offset (a) into each DIMM. In that reclaimed space we create two BLK-aperture "namespaces" from REGION2 and @@ -230,13 +236,13 @@ by a region device with a dynamically assigned id (REGION0 - REGION5). 2. In the last portion of DIMM0 and DIMM1 we have an interleaved system-physical-address range, REGION1, that spans those two DIMMs as - well as DIMM2 and DIMM3. Some of REGION1 allocated to a PMEM namespace - named "pm1.0" the rest is reclaimed in 4 BLK-aperture namespaces (for + well as DIMM2 and DIMM3. Some of REGION1 is allocated to a PMEM namespace + named "pm1.0", the rest is reclaimed in 4 BLK-aperture namespaces (for each DIMM in the interleave set), "blk2.1", "blk3.1", "blk4.0", and "blk5.0". 3. The portion of DIMM2 and DIMM3 that do not participate in the REGION1 - interleaved system-physical-address range (i.e. the DPA address below + interleaved system-physical-address range (i.e. the DPA address past offset (b) are also included in the "blk4.0" and "blk5.0" namespaces. Note, that this example shows that BLK-aperture namespaces don't need to be contiguous in DPA-space. @@ -252,15 +258,15 @@ LIBNVDIMM Kernel Device Model and LIBNDCTL Userspace API What follows is a description of the LIBNVDIMM sysfs layout and a corresponding object hierarchy diagram as viewed through the LIBNDCTL -api. The example sysfs paths and diagrams are relative to the Example +API. The example sysfs paths and diagrams are relative to the Example NVDIMM Platform which is also the LIBNVDIMM bus used in the LIBNDCTL unit test. LIBNDCTL: Context -Every api call in the LIBNDCTL library requires a context that holds the +Every API call in the LIBNDCTL library requires a context that holds the logging parameters and other library instance state. The library is based on the libabc template: -https://git.kernel.org/cgit/linux/kernel/git/kay/libabc.git/ +https://git.kernel.org/cgit/linux/kernel/git/kay/libabc.git LIBNDCTL: instantiate a new library context example @@ -409,7 +415,7 @@ Bit 31:28 Reserved LIBNVDIMM/LIBNDCTL: Region ---------------------- -A generic REGION device is registered for each PMEM range orBLK-aperture +A generic REGION device is registered for each PMEM range or BLK-aperture set. Per the example there are 6 regions: 2 PMEM and 4 BLK-aperture sets on the "nfit_test.0" bus. The primary role of regions are to be a container of "mappings". A mapping is a tuple of <DIMM, @@ -509,7 +515,7 @@ At first glance it seems since NFIT defines just PMEM and BLK interface types that we should simply name REGION devices with something derived from those type names. However, the ND subsystem explicitly keeps the REGION name generic and expects userspace to always consider the -region-attributes for 4 reasons: +region-attributes for four reasons: 1. There are already more than two REGION and "namespace" types. For PMEM there are two subtypes. As mentioned previously we have PMEM where @@ -698,8 +704,8 @@ static int configure_namespace(struct ndctl_region *region, Why the Term "namespace"? - 1. Why not "volume" for instance? "volume" ran the risk of confusing ND - as a volume manager like device-mapper. + 1. Why not "volume" for instance? "volume" ran the risk of confusing + ND (libnvdimm subsystem) to a volume manager like device-mapper. 2. The term originated to describe the sub-devices that can be created within a NVME controller (see the nvme specification: @@ -774,13 +780,14 @@ block" needs to be destroyed. Note, that to destroy a BTT the media needs to be written in raw mode. By default, the kernel will autodetect the presence of a BTT and disable raw mode. This autodetect behavior can be suppressed by enabling raw mode for the namespace via the -ndctl_namespace_set_raw_mode() api. +ndctl_namespace_set_raw_mode() API. Summary LIBNDCTL Diagram ------------------------ -For the given example above, here is the view of the objects as seen by the LIBNDCTL api: +For the given example above, here is the view of the objects as seen by the +LIBNDCTL API: +---+ |CTX| +---------+ +--------------+ +---------------+ +-+-+ +-> REGION0 +---> NAMESPACE0.0 +--> PMEM8 "pm0.0" | diff --git a/Documentation/scsi/st.txt b/Documentation/scsi/st.txt index f29fa550665a..b3211af63b79 100644 --- a/Documentation/scsi/st.txt +++ b/Documentation/scsi/st.txt @@ -569,7 +569,9 @@ Debugging code is now compiled in by default but debugging is turned off with the kernel module parameter debug_flag defaulting to 0. Debugging can still be switched on and off with an ioctl. To enable debug at module load time add debug_flag=1 to the module load options, the -debugging output is not voluminous. +debugging output is not voluminous. Debugging can also be enabled +and disabled by writing a '0' (disable) or '1' (enable) to the sysfs +file /sys/bus/scsi/drivers/st/debug_flag. If the tape seems to hang, I would be very interested to hear where the driver is waiting. With the command 'ps -l' you can see the state diff --git a/Documentation/spi/pxa2xx b/Documentation/spi/pxa2xx index 3352f97430e4..13a0b7fb192f 100644 --- a/Documentation/spi/pxa2xx +++ b/Documentation/spi/pxa2xx @@ -22,15 +22,10 @@ Typically a SPI master is defined in the arch/.../mach-*/board-*.c as a found in include/linux/spi/pxa2xx_spi.h: struct pxa2xx_spi_master { - u32 clock_enable; u16 num_chipselect; u8 enable_dma; }; -The "pxa2xx_spi_master.clock_enable" field is used to enable/disable the -corresponding SSP peripheral block in the "Clock Enable Register (CKEN"). See -the "PXA2xx Developer Manual" section "Clocks and Power Management". - The "pxa2xx_spi_master.num_chipselect" field is used to determine the number of slave device (chips) attached to this SPI master. @@ -57,7 +52,6 @@ static struct resource pxa_spi_nssp_resources[] = { }; static struct pxa2xx_spi_master pxa_nssp_master_info = { - .clock_enable = CKEN_NSSP, /* NSSP Peripheral clock */ .num_chipselect = 1, /* Matches the number of chips attached to NSSP */ .enable_dma = 1, /* Enables NSSP DMA */ }; diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index a4482fceacec..f72370b440b1 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt @@ -639,7 +639,7 @@ and don't use much of it. The default value is 0. See Documentation/vm/overcommit-accounting and -security/commoncap.c::cap_vm_enough_memory() for more information. +mm/mmap.c::__vm_enough_memory() for more information. ============================================================== diff --git a/Documentation/target/tcm_mod_builder.py b/Documentation/target/tcm_mod_builder.py index cda56df9b8a7..7d370c9b1450 100755 --- a/Documentation/target/tcm_mod_builder.py +++ b/Documentation/target/tcm_mod_builder.py @@ -203,8 +203,6 @@ def tcm_mod_build_configfs(proto_ident, fabric_mod_dir_var, fabric_mod_name): buf += "#include <scsi/scsi_proto.h>\n\n" buf += "#include <target/target_core_base.h>\n" buf += "#include <target/target_core_fabric.h>\n" - buf += "#include <target/target_core_fabric_configfs.h>\n" - buf += "#include <target/configfs_macros.h>\n\n" buf += "#include \"" + fabric_mod_name + "_base.h\"\n" buf += "#include \"" + fabric_mod_name + "_fabric.h\"\n\n" @@ -283,19 +281,6 @@ def tcm_mod_build_configfs(proto_ident, fabric_mod_dir_var, fabric_mod_name): buf += " struct " + fabric_mod_name + "_" + fabric_mod_port + ", " + fabric_mod_port + "_wwn);\n" buf += " kfree(" + fabric_mod_port + ");\n" buf += "}\n\n" - buf += "static ssize_t " + fabric_mod_name + "_wwn_show_attr_version(\n" - buf += " struct target_fabric_configfs *tf,\n" - buf += " char *page)\n" - buf += "{\n" - buf += " return sprintf(page, \"" + fabric_mod_name.upper() + " fabric module %s on %s/%s\"\n" - buf += " \"on \"UTS_RELEASE\"\\n\", " + fabric_mod_name.upper() + "_VERSION, utsname()->sysname,\n" - buf += " utsname()->machine);\n" - buf += "}\n\n" - buf += "TF_WWN_ATTR_RO(" + fabric_mod_name + ", version);\n\n" - buf += "static struct configfs_attribute *" + fabric_mod_name + "_wwn_attrs[] = {\n" - buf += " &" + fabric_mod_name + "_wwn_version.attr,\n" - buf += " NULL,\n" - buf += "};\n\n" buf += "static const struct target_core_fabric_ops " + fabric_mod_name + "_ops = {\n" buf += " .module = THIS_MODULE,\n" @@ -328,8 +313,6 @@ def tcm_mod_build_configfs(proto_ident, fabric_mod_dir_var, fabric_mod_name): buf += " .fabric_drop_wwn = " + fabric_mod_name + "_drop_" + fabric_mod_port + ",\n" buf += " .fabric_make_tpg = " + fabric_mod_name + "_make_tpg,\n" buf += " .fabric_drop_tpg = " + fabric_mod_name + "_drop_tpg,\n" - buf += "\n" - buf += " .tfc_wwn_attrs = " + fabric_mod_name + "_wwn_attrs,\n" buf += "};\n\n" buf += "static int __init " + fabric_mod_name + "_init(void)\n" |
