diff options
Diffstat (limited to 'Documentation')
97 files changed, 1855 insertions, 762 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index c8a8eb1a2b11..793acf999e9e 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -270,8 +270,8 @@ m68k/ - directory with info about Linux on Motorola 68k architecture. mailbox.txt - How to write drivers for the common mailbox framework (IPC). -md-cluster.txt - - info on shared-device RAID MD cluster. +md/ + - directory with info about Linux Software RAID media/ - info on media drivers: uAPI, kAPI and driver documentation. memory-barriers.txt diff --git a/Documentation/ABI/testing/configfs-rdma_cm b/Documentation/ABI/testing/configfs-rdma_cm index 5c389aaf5291..74f9506f42e7 100644 --- a/Documentation/ABI/testing/configfs-rdma_cm +++ b/Documentation/ABI/testing/configfs-rdma_cm @@ -20,3 +20,11 @@ Description: RDMA-CM based connections from HCA <hca> at port <port-num> will be initiated with this RoCE type as default. The possible RoCE types are either "IB/RoCE v1" or "RoCE v2". This parameter has RW access. + +What: /config/rdma_cm/<hca>/ports/<port-num>/default_roce_tos +Date: February 7, 2017 +KernelVersion: 4.11.0 +Description: RDMA-CM QPs from HCA <hca> at port <port-num> + will be created with this TOS as default. + This can be overridden by using the rdma_set_option API. + The possible RoCE TOS values are 0-255. diff --git a/Documentation/PCI/MSI-HOWTO.txt b/Documentation/PCI/MSI-HOWTO.txt index cd9c9f6a7cd9..1e37138027a3 100644 --- a/Documentation/PCI/MSI-HOWTO.txt +++ b/Documentation/PCI/MSI-HOWTO.txt @@ -162,8 +162,6 @@ The following old APIs to enable and disable MSI or MSI-X interrupts should not be used in new code: pci_enable_msi() /* deprecated */ - pci_enable_msi_range() /* deprecated */ - pci_enable_msi_exact() /* deprecated */ pci_disable_msi() /* deprecated */ pci_enable_msix_range() /* deprecated */ pci_enable_msix_exact() /* deprecated */ @@ -268,5 +266,5 @@ or disabled (0). If 0 is found in any of the msi_bus files belonging to bridges between the PCI root and the device, MSIs are disabled. It is also worth checking the device driver to see whether it supports MSIs. -For example, it may contain calls to pci_enable_msi_range() or -pci_enable_msix_range(). +For example, it may contain calls to pci_irq_alloc_vectors() with the +PCI_IRQ_MSI or PCI_IRQ_MSIX flags. diff --git a/Documentation/PCI/PCIEBUS-HOWTO.txt b/Documentation/PCI/PCIEBUS-HOWTO.txt index 6bd5f372adec..15f0bb3b5045 100644 --- a/Documentation/PCI/PCIEBUS-HOWTO.txt +++ b/Documentation/PCI/PCIEBUS-HOWTO.txt @@ -161,21 +161,13 @@ Since all service drivers of a PCI-PCI Bridge Port device are allowed to run simultaneously, below lists a few of possible resource conflicts with proposed solutions. -6.1 MSI Vector Resource - -The MSI capability structure enables a device software driver to call -pci_enable_msi to request MSI based interrupts. Once MSI interrupts -are enabled on a device, it stays in this mode until a device driver -calls pci_disable_msi to disable MSI interrupts and revert back to -INTx emulation mode. Since service drivers of the same PCI-PCI Bridge -port share the same physical device, if an individual service driver -calls pci_enable_msi/pci_disable_msi it may result unpredictable -behavior. For example, two service drivers run simultaneously on the -same physical Root Port. Both service drivers call pci_enable_msi to -request MSI based interrupts. A service driver may not know whether -any other service drivers have run on this Root Port. If either one -of them calls pci_disable_msi, it puts the other service driver -in a wrong interrupt mode. +6.1 MSI and MSI-X Vector Resource + +Once MSI or MSI-X interrupts are enabled on a device, it stays in this +mode until they are disabled again. Since service drivers of the same +PCI-PCI Bridge port share the same physical device, if an individual +service driver enables or disables MSI/MSI-X mode it may result +unpredictable behavior. To avoid this situation all service drivers are not permitted to switch interrupt mode on its device. The PCI Express Port Bus driver @@ -187,17 +179,6 @@ driver. Service drivers should use (struct pcie_device*)dev->irq to call request_irq/free_irq. In addition, the interrupt mode is stored in the field interrupt_mode of struct pcie_device. -6.2 MSI-X Vector Resources - -Similar to the MSI a device driver for an MSI-X capable device can -call pci_enable_msix to request MSI-X interrupts. All service drivers -are not permitted to switch interrupt mode on its device. The PCI -Express Port Bus driver is responsible for determining the interrupt -mode and this should be transparent to service drivers. Any attempt -by service driver to call pci_enable_msix/pci_disable_msix may -result unpredictable behavior. Service drivers should use -(struct pcie_device*)dev->irq and call request_irq/free_irq. - 6.3 PCI Memory/IO Mapped Regions Service drivers for PCI Express Power Management (PME), Advanced diff --git a/Documentation/PCI/pci-error-recovery.txt b/Documentation/PCI/pci-error-recovery.txt index ac26869c7db4..da3b2176d5da 100644 --- a/Documentation/PCI/pci-error-recovery.txt +++ b/Documentation/PCI/pci-error-recovery.txt @@ -78,7 +78,6 @@ struct pci_error_handlers { int (*error_detected)(struct pci_dev *dev, enum pci_channel_state); int (*mmio_enabled)(struct pci_dev *dev); - int (*link_reset)(struct pci_dev *dev); int (*slot_reset)(struct pci_dev *dev); void (*resume)(struct pci_dev *dev); }; @@ -104,8 +103,7 @@ if it implements any, it must implement error_detected(). If a callback is not implemented, the corresponding feature is considered unsupported. For example, if mmio_enabled() and resume() aren't there, then it is assumed that the driver is not doing any direct recovery and requires -a slot reset. If link_reset() is not implemented, the card is assumed to -not care about link resets. Typically a driver will want to know about +a slot reset. Typically a driver will want to know about a slot_reset(). The actual steps taken by a platform to recover from a PCI error @@ -232,25 +230,9 @@ proceeds to STEP 4 (Slot Reset) STEP 3: Link Reset ------------------ -The platform resets the link, and then calls the link_reset() callback -on all affected device drivers. This is a PCI-Express specific state +The platform resets the link. This is a PCI-Express specific step and is done whenever a non-fatal error has been detected that can be -"solved" by resetting the link. This call informs the driver of the -reset and the driver should check to see if the device appears to be -in working condition. - -The driver is not supposed to restart normal driver I/O operations -at this point. It should limit itself to "probing" the device to -check its recoverability status. If all is right, then the platform -will call resume() once all drivers have ack'd link_reset(). - - Result codes: - (identical to STEP 3 (MMIO Enabled) - -The platform then proceeds to either STEP 4 (Slot Reset) or STEP 5 -(Resume Operations). - ->>> The current powerpc implementation does not implement this callback. +"solved" by resetting the link. STEP 4: Slot Reset ------------------ diff --git a/Documentation/PCI/pci.txt b/Documentation/PCI/pci.txt index 77f49dc5be23..611a75e4366e 100644 --- a/Documentation/PCI/pci.txt +++ b/Documentation/PCI/pci.txt @@ -382,18 +382,18 @@ The fundamental difference between MSI and MSI-X is how multiple "vectors" get allocated. MSI requires contiguous blocks of vectors while MSI-X can allocate several individual ones. -MSI capability can be enabled by calling pci_enable_msi() or -pci_enable_msix() before calling request_irq(). This causes -the PCI support to program CPU vector data into the PCI device -capability registers. - -If your PCI device supports both, try to enable MSI-X first. -Only one can be enabled at a time. Many architectures, chip-sets, -or BIOSes do NOT support MSI or MSI-X and the call to pci_enable_msi/msix -will fail. This is important to note since many drivers have -two (or more) interrupt handlers: one for MSI/MSI-X and another for IRQs. -They choose which handler to register with request_irq() based on the -return value from pci_enable_msi/msix(). +MSI capability can be enabled by calling pci_alloc_irq_vectors() with the +PCI_IRQ_MSI and/or PCI_IRQ_MSIX flags before calling request_irq(). This +causes the PCI support to program CPU vector data into the PCI device +capability registers. Many architectures, chip-sets, or BIOSes do NOT +support MSI or MSI-X and a call to pci_alloc_irq_vectors with just +the PCI_IRQ_MSI and PCI_IRQ_MSIX flags will fail, so try to always +specify PCI_IRQ_LEGACY as well. + +Drivers that have different interrupt handlers for MSI/MSI-X and +legacy INTx should chose the right one based on the msi_enabled +and msix_enabled flags in the pci_dev structure after calling +pci_alloc_irq_vectors. There are (at least) two really good reasons for using MSI: 1) MSI is an exclusive interrupt vector by definition. diff --git a/Documentation/admin-guide/md.rst b/Documentation/admin-guide/md.rst index e449fb5f277c..1e61bf50595c 100644 --- a/Documentation/admin-guide/md.rst +++ b/Documentation/admin-guide/md.rst @@ -725,3 +725,8 @@ These currently include: to 1. Setting this to 0 disables bypass accounting and requires preread stripes to wait until all full-width stripe- writes are complete. Valid values are 0 to stripe_cache_size. + + journal_mode (currently raid5 only) + The cache mode for raid5. raid5 could include an extra disk for + caching. The mode can be "write-throuth" and "write-back". The + default is "write-through". diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README index cd0243302bc1..d7b1f016bd62 100644 --- a/Documentation/arm/sunxi/README +++ b/Documentation/arm/sunxi/README @@ -63,10 +63,18 @@ SunXi family + User Manual http://dl.linux-sunxi.org/A33/A33%20user%20manual%20release%201.1.pdf + - Allwinner H2+ (sun8i) + + No document available now, but is known to be working properly with + H3 drivers and memory map. + - Allwinner H3 (sun8i) + Datasheet http://dl.linux-sunxi.org/H3/Allwinner_H3_Datasheet_V1.0.pdf + - Allwinner V3s (sun8i) + + Datasheet + http://linux-sunxi.org/File:Allwinner_V3s_Datasheet_V1.0.pdf + * Quad ARM Cortex-A15, Quad ARM Cortex-A7 based SoCs - Allwinner A80 + Datasheet diff --git a/Documentation/crypto/api-digest.rst b/Documentation/crypto/api-digest.rst index 07356fa99200..7a1e670d6ce1 100644 --- a/Documentation/crypto/api-digest.rst +++ b/Documentation/crypto/api-digest.rst @@ -14,7 +14,7 @@ Asynchronous Message Digest API :doc: Asynchronous Message Digest API .. kernel-doc:: include/crypto/hash.h - :functions: crypto_alloc_ahash crypto_free_ahash crypto_ahash_init crypto_ahash_digestsize crypto_ahash_reqtfm crypto_ahash_reqsize crypto_ahash_setkey crypto_ahash_finup crypto_ahash_final crypto_ahash_digest crypto_ahash_export crypto_ahash_import + :functions: crypto_alloc_ahash crypto_free_ahash crypto_ahash_init crypto_ahash_digestsize crypto_ahash_reqtfm crypto_ahash_reqsize crypto_ahash_statesize crypto_ahash_setkey crypto_ahash_finup crypto_ahash_final crypto_ahash_digest crypto_ahash_export crypto_ahash_import Asynchronous Hash Request Handle -------------------------------- diff --git a/Documentation/crypto/api-skcipher.rst b/Documentation/crypto/api-skcipher.rst index b20028a361a9..4eec4a93f7e3 100644 --- a/Documentation/crypto/api-skcipher.rst +++ b/Documentation/crypto/api-skcipher.rst @@ -59,4 +59,4 @@ Synchronous Block Cipher API - Deprecated :doc: Synchronous Block Cipher API .. kernel-doc:: include/linux/crypto.h - :functions: crypto_alloc_blkcipher rypto_free_blkcipher crypto_has_blkcipher crypto_blkcipher_name crypto_blkcipher_ivsize crypto_blkcipher_blocksize crypto_blkcipher_setkey crypto_blkcipher_encrypt crypto_blkcipher_encrypt_iv crypto_blkcipher_decrypt crypto_blkcipher_decrypt_iv crypto_blkcipher_set_iv crypto_blkcipher_get_iv + :functions: crypto_alloc_blkcipher crypto_free_blkcipher crypto_has_blkcipher crypto_blkcipher_name crypto_blkcipher_ivsize crypto_blkcipher_blocksize crypto_blkcipher_setkey crypto_blkcipher_encrypt crypto_blkcipher_encrypt_iv crypto_blkcipher_decrypt crypto_blkcipher_decrypt_iv crypto_blkcipher_set_iv crypto_blkcipher_get_iv diff --git a/Documentation/devicetree/bindings/arm/axentia.txt b/Documentation/devicetree/bindings/arm/axentia.txt new file mode 100644 index 000000000000..ea3fb96ae465 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/axentia.txt @@ -0,0 +1,19 @@ +Device tree bindings for Axentia ARM devices +============================================ + +Linea CPU module +---------------- + +Required root node properties: +compatible = "axentia,linea", + "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5"; +and following the rules from atmel-at91.txt for a sama5d31 SoC. + + +TSE-850 v3 board +---------------- + +Required root node properties: +compatible = "axentia,tse850v3", "axentia,linea", + "atmel,sama5d31", "atmel,sama5d3", "atmel,sama5"; +and following the rules from above for the axentia,linea CPU module. diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index a1bcfeed5f24..698ad1f097fa 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -158,6 +158,7 @@ nodes to be present and contain the properties described below. "arm,cortex-a53" "arm,cortex-a57" "arm,cortex-a72" + "arm,cortex-a73" "arm,cortex-m0" "arm,cortex-m0+" "arm,cortex-m1" @@ -202,6 +203,7 @@ nodes to be present and contain the properties described below. "marvell,armada-380-smp" "marvell,armada-390-smp" "marvell,armada-xp-smp" + "marvell,98dx3236-smp" "mediatek,mt6589-smp" "mediatek,mt81xx-tz-smp" "qcom,gcc-msm8660" diff --git a/Documentation/devicetree/bindings/arm/davinci.txt b/Documentation/devicetree/bindings/arm/davinci.txt index f0841ce725b5..715622c36260 100644 --- a/Documentation/devicetree/bindings/arm/davinci.txt +++ b/Documentation/devicetree/bindings/arm/davinci.txt @@ -13,6 +13,10 @@ EnBW AM1808 based CMC board Required root node properties: - compatible = "enbw,cmc", "ti,da850; +LEGO MINDSTORMS EV3 (AM1808 based) +Required root node properties: + - compatible = "lego,ev3", "ti,da850"; + Generic DaVinci Boards ---------------------- diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt index d6ee9c6e1dbb..c9c567ae227f 100644 --- a/Documentation/devicetree/bindings/arm/fsl.txt +++ b/Documentation/devicetree/bindings/arm/fsl.txt @@ -108,7 +108,7 @@ status. - compatible: Should contain a chip-specific compatible string, Chip-specific strings are of the form "fsl,<chip>-scfg", The following <chip>s are known to be supported: - ls1021a, ls1043a, ls1046a, ls2080a. + ls1012a, ls1021a, ls1043a, ls1046a, ls2080a. - reg: should contain base address and length of SCFG memory-mapped registers @@ -126,7 +126,7 @@ core start address and release the secondary core from holdoff and startup. - compatible: Should contain a chip-specific compatible string, Chip-specific strings are of the form "fsl,<chip>-dcfg", The following <chip>s are known to be supported: - ls1021a, ls1043a, ls1046a, ls2080a. + ls1012a, ls1021a, ls1043a, ls1046a, ls2080a. - reg : should contain base address and length of DCFG memory-mapped registers @@ -139,6 +139,22 @@ Example: Freescale ARMv8 based Layerscape SoC family Device Tree Bindings ---------------------------------------------------------------- +LS1012A SoC +Required root node properties: + - compatible = "fsl,ls1012a"; + +LS1012A ARMv8 based RDB Board +Required root node properties: + - compatible = "fsl,ls1012a-rdb", "fsl,ls1012a"; + +LS1012A ARMv8 based FRDM Board +Required root node properties: + - compatible = "fsl,ls1012a-frdm", "fsl,ls1012a"; + +LS1012A ARMv8 based QDS Board +Required root node properties: + - compatible = "fsl,ls1012a-qds", "fsl,ls1012a"; + LS1043A SoC Required root node properties: - compatible = "fsl,ls1043a"; diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt index 7df79a715611..f1c1e21a8110 100644 --- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt +++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt @@ -1,5 +1,9 @@ Hisilicon Platforms Device Tree Bindings ---------------------------------------------------- +Hi3660 SoC +Required root node properties: + - compatible = "hisilicon,hi3660"; + Hi4511 Board Required root node properties: - compatible = "hisilicon,hi3620-hi4511"; diff --git a/Documentation/devicetree/bindings/arm/marvell/98dx3236-resume-ctrl.txt b/Documentation/devicetree/bindings/arm/marvell/98dx3236-resume-ctrl.txt new file mode 100644 index 000000000000..26eb9d3aa630 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/marvell/98dx3236-resume-ctrl.txt @@ -0,0 +1,16 @@ +Resume Control +-------------- +Available on Marvell SOCs: 98DX3336 and 98DX4251 + +Required properties: + +- compatible: must be "marvell,98dx3336-resume-ctrl" + +- reg: Should contain resume control registers location and length + +Example: + +resume@20980 { + compatible = "marvell,98dx3336-resume-ctrl"; + reg = <0x20980 0x10>; +}; diff --git a/Documentation/devicetree/bindings/arm/marvell/98dx3236.txt b/Documentation/devicetree/bindings/arm/marvell/98dx3236.txt new file mode 100644 index 000000000000..64e8c73fc5ab --- /dev/null +++ b/Documentation/devicetree/bindings/arm/marvell/98dx3236.txt @@ -0,0 +1,23 @@ +Marvell 98DX3236, 98DX3336 and 98DX4251 Platforms Device Tree Bindings +---------------------------------------------------------------------- + +Boards with a SoC of the Marvell 98DX3236, 98DX3336 and 98DX4251 families +shall have the following property: + +Required root node property: + +compatible: must contain "marvell,armadaxp-98dx3236" + +In addition, boards using the Marvell 98DX3336 SoC shall have the +following property: + +Required root node property: + +compatible: must contain "marvell,armadaxp-98dx3336" + +In addition, boards using the Marvell 98DX4251 SoC shall have the +following property: + +Required root node property: + +compatible: must contain "marvell,armadaxp-98dx4251" diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt index 05f95c3ed7d4..8219b2c6bb29 100644 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt @@ -151,6 +151,9 @@ Boards: - AM335X SBC-T335 : single board computer, built around the Sitara AM3352/4 compatible = "compulab,sbc-t335", "compulab,cm-t335", "ti,am33xx" +- AM335X phyCORE-AM335x: Development kit + compatible = "phytec,am335x-pcm-953", "phytec,am335x-phycore-som", "ti,am33xx" + - OMAP5 EVM : Evaluation Module compatible = "ti,omap5-evm", "ti,omap5" diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt index 253bf9b86690..c9502634316d 100644 --- a/Documentation/devicetree/bindings/arm/shmobile.txt +++ b/Documentation/devicetree/bindings/arm/shmobile.txt @@ -75,7 +75,7 @@ Boards: compatible = "renesas,rskrza1", "renesas,r7s72100" - Salvator-X (RTP0RC7795SIPB0010S) compatible = "renesas,salvator-x", "renesas,r8a7795"; - - Salvator-X + - Salvator-X (RTP0RC7796SIPB0011S) compatible = "renesas,salvator-x", "renesas,r8a7796"; - SILK (RTP0RC7794LCB00011S) compatible = "renesas,silk", "renesas,r8a7794" diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt index 4d6467cc2aa2..d2c46449b4eb 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.txt +++ b/Documentation/devicetree/bindings/arm/sunxi.txt @@ -12,6 +12,7 @@ using one of the following compatible strings: allwinner,sun8i-a23 allwinner,sun8i-a33 allwinner,sun8i-a83t + allwinner,sun8i-h2-plus allwinner,sun8i-h3 allwinner,sun9i-a80 allwinner,sun50i-a64 diff --git a/Documentation/devicetree/bindings/ata/ahci-da850.txt b/Documentation/devicetree/bindings/ata/ahci-da850.txt new file mode 100644 index 000000000000..5f8193417725 --- /dev/null +++ b/Documentation/devicetree/bindings/ata/ahci-da850.txt @@ -0,0 +1,18 @@ +Device tree binding for the TI DA850 AHCI SATA Controller +--------------------------------------------------------- + +Required properties: + - compatible: must be "ti,da850-ahci" + - reg: physical base addresses and sizes of the two register regions + used by the controller: the register map as defined by the + AHCI 1.1 standard and the Power Down Control Register (PWRDN) + for enabling/disabling the SATA clock receiver + - interrupts: interrupt specifier (refer to the interrupt binding) + +Example: + + sata: sata@218000 { + compatible = "ti,da850-ahci"; + reg = <0x218000 0x2000>, <0x22c018 0x4>; + interrupts = <67>; + }; diff --git a/Documentation/devicetree/bindings/clock/qoriq-clock.txt b/Documentation/devicetree/bindings/clock/qoriq-clock.txt index df9cb5ac5f72..aa3526f229a7 100644 --- a/Documentation/devicetree/bindings/clock/qoriq-clock.txt +++ b/Documentation/devicetree/bindings/clock/qoriq-clock.txt @@ -31,6 +31,7 @@ Required properties: * "fsl,t4240-clockgen" * "fsl,b4420-clockgen" * "fsl,b4860-clockgen" + * "fsl,ls1012a-clockgen" * "fsl,ls1021a-clockgen" * "fsl,ls1043a-clockgen" * "fsl,ls1046a-clockgen" diff --git a/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt b/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt index 0532d815dae3..8f19d87cbf24 100644 --- a/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt +++ b/Documentation/devicetree/bindings/clock/st,stm32-rcc.txt @@ -17,6 +17,9 @@ Required properties: property, containing a phandle to the clock device node, an index selecting between gated clocks and other clocks and an index specifying the clock to use. +- clocks: External oscillator clock phandle + - high speed external clock signal (HSE) + - external I2S clock (I2S_CKIN) Example: @@ -25,6 +28,7 @@ Example: #clock-cells = <2> compatible = "st,stm32f42xx-rcc", "st,stm32-rcc"; reg = <0x40023800 0x400>; + clocks = <&clk_hse>, <&clk_i2s_ckin>; }; Specifying gated clocks @@ -66,6 +70,19 @@ The secondary index is bound with the following magic numbers: 0 SYSTICK 1 FCLK + 2 CLK_LSI (low-power clock source) + 3 CLK_LSE (generated from a 32.768 kHz low-speed external + crystal or ceramic resonator) + 4 CLK_HSE_RTC (HSE division factor for RTC clock) + 5 CLK_RTC (real-time clock) + 6 PLL_VCO_I2S (vco frequency of I2S pll) + 7 PLL_VCO_SAI (vco frequency of SAI pll) + 8 CLK_LCD (LCD-TFT) + 9 CLK_I2S (I2S clocks) + 10 CLK_SAI1 (audio clocks) + 11 CLK_SAI2 + 12 CLK_I2SQ_PDIV (post divisor of pll i2s q divisor) + 13 CLK_SAIQ_PDIV (post divisor of pll sai q divisor) Example: diff --git a/Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt b/Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt new file mode 100644 index 000000000000..29b6007568eb --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt @@ -0,0 +1,22 @@ +The Broadcom Secure Processing Unit (SPU) hardware supports symmetric +cryptographic offload for Broadcom SoCs. A SoC may have multiple SPU hardware +blocks. + +Required properties: +- compatible: Should be one of the following: + brcm,spum-crypto - for devices with SPU-M hardware + brcm,spu2-crypto - for devices with SPU2 hardware + brcm,spu2-v2-crypto - for devices with enhanced SPU2 hardware features like SHA3 + and Rabin Fingerprint support + brcm,spum-nsp-crypto - for the Northstar Plus variant of the SPU-M hardware + +- reg: Should contain SPU registers location and length. +- mboxes: The mailbox channel to be used to communicate with the SPU. + Mailbox channels correspond to DMA rings on the device. + +Example: + crypto@612d0000 { + compatible = "brcm,spum-crypto"; + reg = <0 0x612d0000 0 0x900>; + mboxes = <&pdc0 0>; + }; diff --git a/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt b/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt new file mode 100644 index 000000000000..c204725e5873 --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/mediatek-crypto.txt @@ -0,0 +1,27 @@ +MediaTek cryptographic accelerators + +Required properties: +- compatible: Should be "mediatek,eip97-crypto" +- reg: Address and length of the register set for the device +- interrupts: Should contain the five crypto engines interrupts in numeric + order. These are global system and four descriptor rings. +- clocks: the clock used by the core +- clock-names: the names of the clock listed in the clocks property. These are + "ethif", "cryp" +- power-domains: Must contain a reference to the PM domain. + + +Example: + crypto: crypto@1b240000 { + compatible = "mediatek,eip97-crypto"; + reg = <0 0x1b240000 0 0x20000>; + interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_LOW>, + <GIC_SPI 83 IRQ_TYPE_LEVEL_LOW>, + <GIC_SPI 84 IRQ_TYPE_LEVEL_LOW>, + <GIC_SPI 91 IRQ_TYPE_LEVEL_LOW>, + <GIC_SPI 97 IRQ_TYPE_LEVEL_LOW>; + clocks = <&topckgen CLK_TOP_ETHIF_SEL>, + <ðsys CLK_ETHSYS_CRYPTO>; + clock-names = "ethif","cryp"; + power-domains = <&scpsys MT2701_POWER_DOMAIN_ETH>; + }; diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt index e2768703ac2b..34c7fddcea39 100644 --- a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt +++ b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt @@ -56,6 +56,18 @@ Required properties for V3D: - interrupts: The interrupt number See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt +Required properties for DSI: +- compatible: Should be "brcm,bcm2835-dsi0" or "brcm,bcm2835-dsi1" +- reg: Physical base address and length of the DSI block's registers +- interrupts: The interrupt number + See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt +- clocks: a) phy: The DSI PLL clock feeding the DSI analog PHY + b) escape: The DSI ESC clock from CPRMAN + c) pixel: The DSI pixel clock from CPRMAN +- clock-output-names: + The 3 clocks output from the DSI analog PHY: dsi[01]_byte, + dsi[01]_ddr2, and dsi[01]_ddr + [1] Documentation/devicetree/bindings/media/video-interfaces.txt Example: @@ -99,6 +111,29 @@ dpi: dpi@7e208000 { }; }; +dsi1: dsi@7e700000 { + compatible = "brcm,bcm2835-dsi1"; + reg = <0x7e700000 0x8c>; + interrupts = <2 12>; + #address-cells = <1>; + #size-cells = <0>; + #clock-cells = <1>; + + clocks = <&clocks BCM2835_PLLD_DSI1>, + <&clocks BCM2835_CLOCK_DSI1E>, + <&clocks BCM2835_CLOCK_DSI1P>; + clock-names = "phy", "escape", "pixel"; + + clock-output-names = "dsi1_byte", "dsi1_ddr2", "dsi1_ddr"; + + pitouchscreen: panel@0 { + compatible = "raspberrypi,touchscreen"; + reg = <0>; + + <...> + }; +}; + vec: vec@7e806000 { compatible = "brcm,bcm2835-vec"; reg = <0x7e806000 0x1000>; diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt index 6532a59c9b43..00ea670b8c4d 100644 --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt @@ -38,10 +38,22 @@ The following input format properties are required except in "rgb 1x" and - adi,input-justification: The input bit justification ("left", "evenly", "right"). +- avdd-supply: A 1.8V supply that powers up the AVDD pin on the chip. +- dvdd-supply: A 1.8V supply that powers up the DVDD pin on the chip. +- pvdd-supply: A 1.8V supply that powers up the PVDD pin on the chip. +- dvdd-3v-supply: A 3.3V supply that powers up the pin called DVDD_3V + on the chip. +- bgvdd-supply: A 1.8V supply that powers up the BGVDD pin. This is + needed only for ADV7511. + The following properties are required for ADV7533: - adi,dsi-lanes: Number of DSI data lanes connected to the DSI host. It should be one of 1, 2, 3 or 4. +- a2vdd-supply: 1.8V supply that powers up the A2VDD pin on the chip. +- v3p3-supply: A 3.3V supply that powers up the V3P3 pin on the chip. +- v1p2-supply: A supply that powers up the V1P2 pin on the chip. It can be + either 1.2V or 1.8V. Optional properties: diff --git a/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt b/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt index 5e9a84d6e5f1..33bf981fbe33 100644 --- a/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt +++ b/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt @@ -1,52 +1,33 @@ -DesignWare HDMI bridge bindings - -Required properties: -- compatible: platform specific such as: - * "snps,dw-hdmi-tx" - * "fsl,imx6q-hdmi" - * "fsl,imx6dl-hdmi" - * "rockchip,rk3288-dw-hdmi" -- reg: Physical base address and length of the controller's registers. -- interrupts: The HDMI interrupt number -- clocks, clock-names : must have the phandles to the HDMI iahb and isfr clocks, - as described in Documentation/devicetree/bindings/clock/clock-bindings.txt, - the clocks are soc specific, the clock-names should be "iahb", "isfr" --port@[X]: SoC specific port nodes with endpoint definitions as defined - in Documentation/devicetree/bindings/media/video-interfaces.txt, - please refer to the SoC specific binding document: - * Documentation/devicetree/bindings/display/imx/hdmi.txt - * Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt - -Optional properties -- reg-io-width: the width of the reg:1,4, default set to 1 if not present -- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing, - if the property is omitted, a functionally reduced I2C bus - controller on DW HDMI is probed -- clocks, clock-names: phandle to the HDMI CEC clock, name should be "cec" - -Example: - hdmi: hdmi@0120000 { - compatible = "fsl,imx6q-hdmi"; - reg = <0x00120000 0x9000>; - interrupts = <0 115 0x04>; - gpr = <&gpr>; - clocks = <&clks 123>, <&clks 124>; - clock-names = "iahb", "isfr"; - ddc-i2c-bus = <&i2c2>; - - port@0 { - reg = <0>; - - hdmi_mux_0: endpoint { - remote-endpoint = <&ipu1_di0_hdmi>; - }; - }; - - port@1 { - reg = <1>; - - hdmi_mux_1: endpoint { - remote-endpoint = <&ipu1_di1_hdmi>; - }; - }; - }; +Synopsys DesignWare HDMI TX Encoder +=================================== + +This document defines device tree properties for the Synopsys DesignWare HDMI +TX Encoder (DWC HDMI TX). It doesn't constitue a device tree binding +specification by itself but is meant to be referenced by platform-specific +device tree bindings. + +When referenced from platform device tree bindings the properties defined in +this document are defined as follows. The platform device tree bindings are +responsible for defining whether each property is required or optional. + +- reg: Memory mapped base address and length of the DWC HDMI TX registers. + +- reg-io-width: Width of the registers specified by the reg property. The + value is expressed in bytes and must be equal to 1 or 4 if specified. The + register width defaults to 1 if the property is not present. + +- interrupts: Reference to the DWC HDMI TX interrupt. + +- clocks: References to all the clocks specified in the clock-names property + as specified in Documentation/devicetree/bindings/clock/clock-bindings.txt. + +- clock-names: The DWC HDMI TX uses the following clocks. + + - "iahb" is the bus clock for either AHB and APB (mandatory). + - "isfr" is the internal register configuration clock (mandatory). + - "cec" is the HDMI CEC controller main clock (optional). + +- ports: The connectivity of the DWC HDMI TX with the rest of the system is + expressed in using ports as specified in the device graph bindings defined + in Documentation/devicetree/bindings/graph.txt. The numbering of the ports + is platform-specific. diff --git a/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt new file mode 100644 index 000000000000..6ec1a880ac18 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/ti,ths8135.txt @@ -0,0 +1,46 @@ +THS8135 Video DAC +----------------- + +This is the binding for Texas Instruments THS8135 Video DAC bridge. + +Required properties: + +- compatible: Must be "ti,ths8135" + +Required nodes: + +This device has two video ports. Their connections are modelled using the OF +graph bindings specified in Documentation/devicetree/bindings/graph.txt. + +- Video port 0 for RGB input +- Video port 1 for VGA output + +Example +------- + +vga-bridge { + compatible = "ti,ths8135"; + #address-cells = <1>; + #size-cells = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + vga_bridge_in: endpoint { + remote-endpoint = <&lcdc_out_vga>; + }; + }; + + port@1 { + reg = <1>; + + vga_bridge_out: endpoint { + remote-endpoint = <&vga_con_in>; + }; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/display/exynos/exynos7-decon.txt b/Documentation/devicetree/bindings/display/exynos/exynos7-decon.txt index 027d6c210f7e..9e2e7f6f7609 100644 --- a/Documentation/devicetree/bindings/display/exynos/exynos7-decon.txt +++ b/Documentation/devicetree/bindings/display/exynos/exynos7-decon.txt @@ -33,7 +33,7 @@ Required properties: - i80-if-timings: timing configuration for lcd i80 interface support. Optional Properties: -- samsung,power-domain: a phandle to DECON power domain node. +- power-domains: a phandle to DECON power domain node. - display-timings: timing settings for DECON, as described in document [1]. Can be used in case timings cannot be provided otherwise or to override timings provided by the panel. diff --git a/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt index 38dc9d60eef8..305a0e72a900 100644 --- a/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt +++ b/Documentation/devicetree/bindings/display/hisilicon/hisi-ade.txt @@ -16,7 +16,7 @@ Required properties: "clk_ade_core" for the ADE core clock. "clk_codec_jpeg" for the media NOC QoS clock, which use the same clock with jpeg codec. - "clk_ade_pix" for the ADE pixel clok. + "clk_ade_pix" for the ADE pixel clock. - assigned-clocks: Should contain "clk_ade_core" and "clk_codec_jpeg" clocks' phandle + clock-specifier pairs. - assigned-clock-rates: clock rates, one for each entry in assigned-clocks. diff --git a/Documentation/devicetree/bindings/display/imx/hdmi.txt b/Documentation/devicetree/bindings/display/imx/hdmi.txt index 1b756cf9afb0..66a8f86e5d12 100644 --- a/Documentation/devicetree/bindings/display/imx/hdmi.txt +++ b/Documentation/devicetree/bindings/display/imx/hdmi.txt @@ -1,29 +1,36 @@ -Device-Tree bindings for HDMI Transmitter +Freescale i.MX6 DWC HDMI TX Encoder +=================================== -HDMI Transmitter -================ +The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP +with a companion PHY IP. + +These DT bindings follow the Synopsys DWC HDMI TX bindings defined in +Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the +following device-specific properties. -The HDMI Transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP -with accompanying PHY IP. Required properties: - - #address-cells : should be <1> - - #size-cells : should be <0> - - compatible : should be "fsl,imx6q-hdmi" or "fsl,imx6dl-hdmi". - - gpr : should be <&gpr>. - The phandle points to the iomuxc-gpr region containing the HDMI - multiplexer control register. - - clocks, clock-names : phandles to the HDMI iahb and isrf clocks, as described - in Documentation/devicetree/bindings/clock/clock-bindings.txt and - Documentation/devicetree/bindings/clock/imx6q-clock.txt. - - port@[0-4]: Up to four port nodes with endpoint definitions as defined in - Documentation/devicetree/bindings/media/video-interfaces.txt, - corresponding to the four inputs to the HDMI multiplexer. - -Optional properties: - - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing - -example: + +- compatible : Shall be one of "fsl,imx6q-hdmi" or "fsl,imx6dl-hdmi". +- reg: See dw_hdmi.txt. +- interrupts: HDMI interrupt number +- clocks: See dw_hdmi.txt. +- clock-names: Shall contain "iahb" and "isfr" as defined in dw_hdmi.txt. +- ports: See dw_hdmi.txt. The DWC HDMI shall have between one and four ports, + numbered 0 to 3, corresponding to the four inputs of the HDMI multiplexer. + Each port shall have a single endpoint. +- gpr : Shall contain a phandle to the iomuxc-gpr region containing the HDMI + multiplexer control register. + +Optional properties + +- ddc-i2c-bus: The HDMI DDC bus can be connected to either a system I2C master + or the functionally-reduced I2C master contained in the DWC HDMI. When + connected to a system I2C master this property contains a phandle to that + I2C master controller. + + +Example: gpr: iomuxc-gpr@020e0000 { /* ... */ diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt b/Documentation/devicetree/bindings/display/msm/gpu.txt index 67d0a58dbb77..43fac0fe09bb 100644 --- a/Documentation/devicetree/bindings/display/msm/gpu.txt +++ b/Documentation/devicetree/bindings/display/msm/gpu.txt @@ -1,23 +1,19 @@ Qualcomm adreno/snapdragon GPU Required properties: -- compatible: "qcom,adreno-3xx" +- compatible: "qcom,adreno-XYZ.W", "qcom,adreno" + for example: "qcom,adreno-306.0", "qcom,adreno" + Note that you need to list the less specific "qcom,adreno" (since this + is what the device is matched on), in addition to the more specific + with the chip-id. - reg: Physical base address and length of the controller's registers. - interrupts: The interrupt signal from the gpu. - clocks: device clocks See ../clocks/clock-bindings.txt for details. - clock-names: the following clocks are required: - * "core_clk" - * "iface_clk" - * "mem_iface_clk" -- qcom,chipid: gpu chip-id. Note this may become optional for future - devices if we can reliably read the chipid from hw -- qcom,gpu-pwrlevels: list of operating points - - compatible: "qcom,gpu-pwrlevels" - - for each qcom,gpu-pwrlevel: - - qcom,gpu-freq: requested gpu clock speed - - NOTE: downstream android driver defines additional parameters to - configure memory bandwidth scaling per OPP. + * "core" + * "iface" + * "mem_iface" Example: @@ -25,28 +21,18 @@ Example: ... gpu: qcom,kgsl-3d0@4300000 { - compatible = "qcom,adreno-3xx"; + compatible = "qcom,adreno-320.2", "qcom,adreno"; reg = <0x04300000 0x20000>; reg-names = "kgsl_3d0_reg_memory"; interrupts = <GIC_SPI 80 0>; interrupt-names = "kgsl_3d0_irq"; clock-names = - "core_clk", - "iface_clk", - "mem_iface_clk"; + "core", + "iface", + "mem_iface"; clocks = <&mmcc GFX3D_CLK>, <&mmcc GFX3D_AHB_CLK>, <&mmcc MMSS_IMEM_AHB_CLK>; - qcom,chipid = <0x03020100>; - qcom,gpu-pwrlevels { - compatible = "qcom,gpu-pwrlevels"; - qcom,gpu-pwrlevel@0 { - qcom,gpu-freq = <450000000>; - }; - qcom,gpu-pwrlevel@1 { - qcom,gpu-freq = <27000000>; - }; - }; }; }; diff --git a/Documentation/devicetree/bindings/display/multi-inno,mi0283qt.txt b/Documentation/devicetree/bindings/display/multi-inno,mi0283qt.txt new file mode 100644 index 000000000000..eed48c3d4875 --- /dev/null +++ b/Documentation/devicetree/bindings/display/multi-inno,mi0283qt.txt @@ -0,0 +1,27 @@ +Multi-Inno MI0283QT display panel + +Required properties: +- compatible: "multi-inno,mi0283qt". + +The node for this driver must be a child node of a SPI controller, hence +all mandatory properties described in ../spi/spi-bus.txt must be specified. + +Optional properties: +- dc-gpios: D/C pin. The presence/absence of this GPIO determines + the panel interface mode (IM[3:0] pins): + - present: IM=x110 4-wire 8-bit data serial interface + - absent: IM=x101 3-wire 9-bit data serial interface +- reset-gpios: Reset pin +- power-supply: A regulator node for the supply voltage. +- backlight: phandle of the backlight device attached to the panel +- rotation: panel rotation in degrees counter clockwise (0,90,180,270) + +Example: + mi0283qt@0{ + compatible = "multi-inno,mi0283qt"; + reg = <0>; + spi-max-frequency = <32000000>; + rotation = <90>; + dc-gpios = <&gpio 25 0>; + backlight = <&backlight>; + }; diff --git a/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt b/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt new file mode 100644 index 000000000000..b258d6a91ec6 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/boe,nv101wxmn51.txt @@ -0,0 +1,7 @@ +BOE OPTOELECTRONICS TECHNOLOGY 10.1" WXGA TFT LCD panel + +Required properties: +- compatible: should be "boe,nv101wxmn51" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/display/panel/netron-dy,e231732.txt b/Documentation/devicetree/bindings/display/panel/netron-dy,e231732.txt new file mode 100644 index 000000000000..c6d06b5eab51 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/netron-dy,e231732.txt @@ -0,0 +1,7 @@ +Netron-DY E231732 7.0" WSVGA TFT LCD panel + +Required properties: +- compatible: should be "netron-dy,e231732" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/display/panel/panel.txt b/Documentation/devicetree/bindings/display/panel/panel.txt new file mode 100644 index 000000000000..e2e6867852b8 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/panel.txt @@ -0,0 +1,4 @@ +Common display properties +------------------------- + +- rotation: Display rotation in degrees counter clockwise (0,90,180,270) diff --git a/Documentation/devicetree/bindings/display/panel/tianma,tm070jdhg30.txt b/Documentation/devicetree/bindings/display/panel/tianma,tm070jdhg30.txt new file mode 100644 index 000000000000..eb9501a82e25 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/tianma,tm070jdhg30.txt @@ -0,0 +1,7 @@ +Tianma Micro-electronics TM070JDHG30 7.0" WXGA TFT LCD panel + +Required properties: +- compatible: should be "tianma,tm070jdhg30" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt index 668091f27674..046076c6b277 100644 --- a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt +++ b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt @@ -1,24 +1,39 @@ -Rockchip specific extensions to the Synopsys Designware HDMI -================================ +Rockchip DWC HDMI TX Encoder +============================ + +The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP +with a companion PHY IP. + +These DT bindings follow the Synopsys DWC HDMI TX bindings defined in +Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the +following device-specific properties. + Required properties: -- compatible: "rockchip,rk3288-dw-hdmi"; -- reg: Physical base address and length of the controller's registers. -- clocks: phandle to hdmi iahb and isfr clocks. -- clock-names: should be "iahb" "isfr" -- rockchip,grf: this soc should set GRF regs to mux vopl/vopb. + +- compatible: Shall contain "rockchip,rk3288-dw-hdmi". +- reg: See dw_hdmi.txt. +- reg-io-width: See dw_hdmi.txt. Shall be 4. - interrupts: HDMI interrupt number -- ports: contain a port node with endpoint definitions as defined in - Documentation/devicetree/bindings/media/video-interfaces.txt. For - vopb,set the reg = <0> and set the reg = <1> for vopl. -- reg-io-width: the width of the reg:1,4, the value should be 4 on - rk3288 platform +- clocks: See dw_hdmi.txt. +- clock-names: Shall contain "iahb" and "isfr" as defined in dw_hdmi.txt. +- ports: See dw_hdmi.txt. The DWC HDMI shall have a single port numbered 0 + corresponding to the video input of the controller. The port shall have two + endpoints, numbered 0 and 1, connected respectively to the vopb and vopl. +- rockchip,grf: Shall reference the GRF to mux vopl/vopb. Optional properties -- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing -- clocks, clock-names: phandle to the HDMI CEC clock, name should be "cec" + +- ddc-i2c-bus: The HDMI DDC bus can be connected to either a system I2C master + or the functionally-reduced I2C master contained in the DWC HDMI. When + connected to a system I2C master this property contains a phandle to that + I2C master controller. +- clock-names: See dw_hdmi.txt. The "cec" clock is optional. +- clock-names: May contain "cec" as defined in dw_hdmi.txt. + Example: + hdmi: hdmi@ff980000 { compatible = "rockchip,rk3288-dw-hdmi"; reg = <0xff980000 0x20000>; diff --git a/Documentation/devicetree/bindings/display/zte,vou.txt b/Documentation/devicetree/bindings/display/zte,vou.txt index 740e5bd2e4f7..9c356284232b 100644 --- a/Documentation/devicetree/bindings/display/zte,vou.txt +++ b/Documentation/devicetree/bindings/display/zte,vou.txt @@ -49,6 +49,15 @@ Required properties: "osc_clk" "xclk" +* TV Encoder output device + +Required properties: + - compatible: should be "zte,zx296718-tvenc" + - reg: Physical base address and length of the TVENC device IO region + - zte,tvenc-power-control: the phandle to SYSCTRL block followed by two + integer cells. The first cell is the offset of SYSCTRL register used + to control TV Encoder DAC power, and the second cell is the bit mask. + Example: vou: vou@1440000 { @@ -81,4 +90,10 @@ vou: vou@1440000 { <&topcrm HDMI_XCLK>; clock-names = "osc_cec", "osc_clk", "xclk"; }; + + tvenc: tvenc@2000 { + compatible = "zte,zx296718-tvenc"; + reg = <0x2000 0x1000>; + zte,tvenc-power-control = <&sysctrl 0x170 0x10>; + }; }; diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt b/Documentation/devicetree/bindings/eeprom/eeprom.txt index 735bc94444bb..5696eb508e95 100644 --- a/Documentation/devicetree/bindings/eeprom/eeprom.txt +++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt @@ -10,6 +10,8 @@ Required properties: "catalyst,24c32" + "microchip,24c128" + "ramtron,24c64" "renesas,r1ex24002" diff --git a/Documentation/devicetree/bindings/gpio/cortina,gemini-gpio.txt b/Documentation/devicetree/bindings/gpio/cortina,gemini-gpio.txt new file mode 100644 index 000000000000..5c9246c054e5 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/cortina,gemini-gpio.txt @@ -0,0 +1,24 @@ +Cortina Systems Gemini GPIO Controller + +Required properties: + +- compatible : Must be "cortina,gemini-gpio" +- reg : Should contain registers location and length +- interrupts : Should contain the interrupt line for the GPIO block +- gpio-controller : marks this as a GPIO controller +- #gpio-cells : Should be 2, see gpio/gpio.txt +- interrupt-controller : marks this as an interrupt controller +- #interrupt-cells : a standard two-cell interrupt flag, see + interrupt-controller/interrupts.txt + +Example: + +gpio@4d000000 { + compatible = "cortina,gemini-gpio"; + reg = <0x4d000000 0x100>; + interrupts = <22 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; +}; diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt index 08dd15f89ba9..e63935710011 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt @@ -29,6 +29,10 @@ Required properties: onsemi,pca9654 exar,xra1202 +Optional properties: + - reset-gpios: GPIO specification for the RESET input. This is an + active low signal to the PCA953x. + Example: diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt index 68d28f62a6f4..84ede036f73d 100644 --- a/Documentation/devicetree/bindings/gpio/gpio.txt +++ b/Documentation/devicetree/bindings/gpio/gpio.txt @@ -187,10 +187,10 @@ gpio-controller's driver probe function. Each GPIO hog definition is represented as a child node of the GPIO controller. Required properties: -- gpio-hog: A property specifying that this child node represent a GPIO hog. -- gpios: Store the GPIO information (id, flags, ...). Shall contain the - number of cells specified in its parent node (GPIO controller - node). +- gpio-hog: A property specifying that this child node represents a GPIO hog. +- gpios: Store the GPIO information (id, flags, ...) for each GPIO to + affect. Shall contain an integer multiple of the number of cells + specified in its parent node (GPIO controller node). Only one of the following properties scanned in the order shown below. This means that when multiple properties are present they will be searched in the order presented below and the first match is taken as the intended diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt new file mode 100644 index 000000000000..476f5ea6c627 --- /dev/null +++ b/Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt @@ -0,0 +1,81 @@ +ARM Mali Utgard GPU +=================== + +Required properties: + - compatible + * Must be one of the following: + + "arm,mali-300" + + "arm,mali-400" + + "arm,mali-450" + * And, optionally, one of the vendor specific compatible: + + allwinner,sun4i-a10-mali + + allwinner,sun7i-a20-mali + + amlogic,meson-gxbb-mali + + amlogic,meson-gxl-mali + + stericsson,db8500-mali + + - reg: Physical base address and length of the GPU registers + + - interrupts: an entry for each entry in interrupt-names. + See ../interrupt-controller/interrupts.txt for details. + + - interrupt-names: + * ppX: Pixel Processor X interrupt (X from 0 to 7) + * ppmmuX: Pixel Processor X MMU interrupt (X from 0 to 7) + * pp: Pixel Processor broadcast interrupt (mali-450 only) + * gp: Geometry Processor interrupt + * gpmmu: Geometry Processor MMU interrupt + + - clocks: an entry for each entry in clock-names + - clock-names: + * bus: bus clock for the GPU + * core: clock driving the GPU itself + +Optional properties: + - interrupt-names and interrupts: + * pmu: Power Management Unit interrupt, if implemented in hardware + +Vendor-specific bindings +------------------------ + +The Mali GPU is integrated very differently from one SoC to +another. In order to accomodate those differences, you have the option +to specify one more vendor-specific compatible, among: + + - allwinner,sun4i-a10-mali + Required properties: + * resets: phandle to the reset line for the GPU + + - allwinner,sun7i-a20-mali + Required properties: + * resets: phandle to the reset line for the GPU + + - stericsson,db8500-mali + Required properties: + * interrupt-names and interrupts: + + combined: combined interrupt of all of the above lines + +Example: + +mali: gpu@1c40000 { + compatible = "allwinner,sun7i-a20-mali", "arm,mali-400"; + reg = <0x01c40000 0x10000>; + interrupts = <GIC_SPI 97 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "gp", + "gpmmu", + "pp0", + "ppmmu0", + "pp1", + "ppmmu1", + "pmu"; + clocks = <&ccu CLK_BUS_GPU>, <&ccu CLK_GPU>; + clock-names = "bus", "core"; + resets = <&ccu RST_BUS_GPU>; +}; + diff --git a/Documentation/devicetree/bindings/input/cypress,tm2-touchkey.txt b/Documentation/devicetree/bindings/input/cypress,tm2-touchkey.txt new file mode 100644 index 000000000000..635f62c756ee --- /dev/null +++ b/Documentation/devicetree/bindings/input/cypress,tm2-touchkey.txt @@ -0,0 +1,27 @@ +Samsung tm2-touchkey + +Required properties: +- compatible: must be "cypress,tm2-touchkey" +- reg: I2C address of the chip. +- interrupt-parent: a phandle for the interrupt controller (see interrupt + binding[0]). +- interrupts: interrupt to which the chip is connected (see interrupt + binding[0]). +- vcc-supply : internal regulator output. 1.8V +- vdd-supply : power supply for IC 3.3V + +[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt + +Example: + &i2c0 { + /* ... */ + + touchkey@20 { + compatible = "cypress,tm2-touchkey"; + reg = <0x20>; + interrupt-parent = <&gpa3>; + interrupts = <2 IRQ_TYPE_EDGE_FALLING>; + vcc-supply=<&ldo32_reg>; + vdd-supply=<&ldo33_reg>; + }; + }; diff --git a/Documentation/devicetree/bindings/input/mpr121-touchkey.txt b/Documentation/devicetree/bindings/input/mpr121-touchkey.txt new file mode 100644 index 000000000000..b7c61ee5841b --- /dev/null +++ b/Documentation/devicetree/bindings/input/mpr121-touchkey.txt @@ -0,0 +1,30 @@ +* Freescale MPR121 Controllor + +Required Properties: +- compatible: Should be "fsl,mpr121-touchkey" +- reg: The I2C slave address of the device. +- interrupts: The interrupt number to the cpu. +- vdd-supply: Phandle to the Vdd power supply. +- linux,keycodes: Specifies an array of numeric keycode values to + be used for reporting button presses. The array can + contain up to 12 entries. + +Optional Properties: +- wakeup-source: Use any event on keypad as wakeup event. +- autorepeat: Enable autorepeat feature. + +Example: + +#include "dt-bindings/input/input.h" + + touchkey: mpr121@5a { + compatible = "fsl,mpr121-touchkey"; + reg = <0x5a>; + interrupt-parent = <&gpio1>; + interrupts = <28 2>; + autorepeat; + vdd-supply = <&ldo4_reg>; + linux,keycodes = <KEY_0>, <KEY_1>, <KEY_2>, <KEY_3>, + <KEY_4> <KEY_5>, <KEY_6>, <KEY_7>, + <KEY_8>, <KEY_9>, <KEY_A>, <KEY_B>; + }; diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.txt b/Documentation/devicetree/bindings/input/pwm-beeper.txt index be332ae4f2d6..529408b4431a 100644 --- a/Documentation/devicetree/bindings/input/pwm-beeper.txt +++ b/Documentation/devicetree/bindings/input/pwm-beeper.txt @@ -5,3 +5,19 @@ Registers a PWM device as beeper. Required properties: - compatible: should be "pwm-beeper" - pwms: phandle to the physical PWM device + +Optional properties: +- amp-supply: phandle to a regulator that acts as an amplifier for the beeper + +Example: + +beeper_amp: amplifier { + compatible = "fixed-regulator"; + gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>; +}; + +beeper { + compatible = "pwm-beeper"; + pwms = <&pwm0>; + amp-supply = <&beeper_amp>; +}; diff --git a/Documentation/devicetree/bindings/input/touchscreen/zet6223.txt b/Documentation/devicetree/bindings/input/touchscreen/zet6223.txt new file mode 100644 index 000000000000..fe6a1feef703 --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/zet6223.txt @@ -0,0 +1,32 @@ +Zeitec ZET6223 I2C touchscreen controller + +Required properties: +- compatible : "zeitec,zet6223" +- reg : I2C slave address of the chip (0x76) +- interrupt-parent : a phandle pointing to the interrupt controller + serving the interrupt for this chip +- interrupts : interrupt specification for the zet6223 interrupt + +Optional properties: + +- vio-supply : Specification for VIO supply (1.8V or 3.3V, + depending on system interface needs). +- vcc-supply : Specification for 3.3V VCC supply. +- touchscreen-size-x : See touchscreen.txt +- touchscreen-size-y : See touchscreen.txt +- touchscreen-inverted-x : See touchscreen.txt +- touchscreen-inverted-y : See touchscreen.txt +- touchscreen-swapped-x-y : See touchscreen.txt + +Example: + +i2c@00000000 { + + zet6223: touchscreen@76 { + compatible = "zeitec,zet6223"; + reg = <0x76>; + interrupt-parent = <&pio>; + interrupts = <6 11 IRQ_TYPE_EDGE_FALLING> + }; + +}; diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt index 5393e2a45a42..560d8a727b8f 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt @@ -111,7 +111,7 @@ Example: #interrupt-cells = <3>; interrupt-controller; reg = <0x2c001000 0x1000>, - <0x2c002000 0x1000>, + <0x2c002000 0x2000>, <0x2c004000 0x2000>, <0x2c006000 0x2000>; interrupts = <1 9 0xf04>; diff --git a/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt b/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt new file mode 100644 index 000000000000..aea5370efd97 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/aspeed-gfx.txt @@ -0,0 +1,17 @@ +* Device tree bindings for Aspeed SoC Display Controller (GFX) + +The Aspeed SoC Display Controller primarily does as its name suggests, but also +participates in pinmux requests on the g5 SoCs. It is therefore considered a +syscon device. + +Required properties: +- compatible: "aspeed,ast2500-gfx", "syscon" +- reg: contains offset/length value of the GFX memory + region. + +Example: + +gfx: display@1e6e6000 { + compatible = "aspeed,ast2500-gfx", "syscon"; + reg = <0x1e6e6000 0x1000>; +}; diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt new file mode 100644 index 000000000000..514d82ced95b --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt @@ -0,0 +1,137 @@ +====================================================================== +Device tree bindings for the Aspeed Low Pin Count (LPC) Bus Controller +====================================================================== + +The LPC bus is a means to bridge a host CPU to a number of low-bandwidth +peripheral devices, replacing the use of the ISA bus in the age of PCI[0]. The +primary use case of the Aspeed LPC controller is as a slave on the bus +(typically in a Baseboard Management Controller SoC), but under certain +conditions it can also take the role of bus master. + +The LPC controller is represented as a multi-function device to account for the +mix of functionality it provides. The principle split is between the register +layout at the start of the I/O space which is, to quote the Aspeed datasheet, +"basically compatible with the [LPC registers from the] popular BMC controller +H8S/2168[1]", and everything else, where everything else is an eclectic +collection of functions with a esoteric register layout. "Everything else", +here labeled the "host" portion of the controller, includes, but is not limited +to: + +* An IPMI Block Transfer[2] Controller + +* An LPC Host Controller: Manages LPC functions such as host vs slave mode, the + physical properties of some LPC pins, configuration of serial IRQs, and + APB-to-LPC bridging amonst other functions. + +* An LPC Host Interface Controller: Manages functions exposed to the host such + as LPC firmware hub cycles, configuration of the LPC-to-AHB mapping, UART + management and bus snoop configuration. + +* A set of SuperIO[3] scratch registers: Enables implementation of e.g. custom + hardware management protocols for handover between the host and baseboard + management controller. + +Additionally the state of the LPC controller influences the pinmux +configuration, therefore the host portion of the controller is exposed as a +syscon as a means to arbitrate access. + +[0] http://www.intel.com/design/chipsets/industry/25128901.pdf +[1] https://www.renesas.com/en-sg/doc/products/mpumcu/001/rej09b0078_h8s2168.pdf?key=7c88837454702128622bee53acbda8f4 +[2] http://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ipmi-second-gen-interface-spec-v2-rev1-1.pdf +[3] https://en.wikipedia.org/wiki/Super_I/O + +Required properties +=================== + +- compatible: One of: + "aspeed,ast2400-lpc", "simple-mfd" + "aspeed,ast2500-lpc", "simple-mfd" + +- reg: contains the physical address and length values of the Aspeed + LPC memory region. + +- #address-cells: <1> +- #size-cells: <1> +- ranges: Maps 0 to the physical address and length of the LPC memory + region + +Required LPC Child nodes +======================== + +BMC Node +-------- + +- compatible: One of: + "aspeed,ast2400-lpc-bmc" + "aspeed,ast2500-lpc-bmc" + +- reg: contains the physical address and length values of the + H8S/2168-compatible LPC controller memory region + +Host Node +--------- + +- compatible: One of: + "aspeed,ast2400-lpc-host", "simple-mfd", "syscon" + "aspeed,ast2500-lpc-host", "simple-mfd", "syscon" + +- reg: contains the address and length values of the host-related + register space for the Aspeed LPC controller + +- #address-cells: <1> +- #size-cells: <1> +- ranges: Maps 0 to the address and length of the host-related LPC memory + region + +Example: + +lpc: lpc@1e789000 { + compatible = "aspeed,ast2500-lpc", "simple-mfd"; + reg = <0x1e789000 0x1000>; + + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x1e789000 0x1000>; + + lpc_bmc: lpc-bmc@0 { + compatible = "aspeed,ast2500-lpc-bmc"; + reg = <0x0 0x80>; + }; + + lpc_host: lpc-host@80 { + compatible = "aspeed,ast2500-lpc-host", "simple-mfd", "syscon"; + reg = <0x80 0x1e0>; + reg-io-width = <4>; + + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0x80 0x1e0>; + }; +}; + +Host Node Children +================== + +LPC Host Controller +------------------- + +The Aspeed LPC Host Controller configures the Low Pin Count (LPC) bus behaviour +between the host and the baseboard management controller. The registers exist +in the "host" portion of the Aspeed LPC controller, which must be the parent of +the LPC host controller node. + +Required properties: + +- compatible: One of: + "aspeed,ast2400-lhc"; + "aspeed,ast2500-lhc"; + +- reg: contains offset/length values of the LHC memory regions. In the + AST2400 and AST2500 there are two regions. + +Example: + +lhc: lhc@20 { + compatible = "aspeed,ast2500-lhc"; + reg = <0x20 0x24 0x48 0x8>; +}; diff --git a/Documentation/devicetree/bindings/mfd/mfd.txt b/Documentation/devicetree/bindings/mfd/mfd.txt index af9d6931a1a2..bcb6abb9d413 100644 --- a/Documentation/devicetree/bindings/mfd/mfd.txt +++ b/Documentation/devicetree/bindings/mfd/mfd.txt @@ -19,12 +19,22 @@ Optional properties: - compatible : "simple-mfd" - this signifies that the operating system should consider all subnodes of the MFD device as separate devices akin to how - "simple-bus" inidicates when to see subnodes as children for a simple + "simple-bus" indicates when to see subnodes as children for a simple memory-mapped bus. For more complex devices, when the nexus driver has to probe registers to figure out what child devices exist etc, this should not be used. In the latter case the child devices will be determined by the operating system. +- ranges: Describes the address mapping relationship to the parent. Should set + the child's base address to 0, the physical address within parent's address + space, and the length of the address map. + +- #address-cells: Specifies the number of cells used to represent physical base + addresses. Must be present if ranges is used. + +- #size-cells: Specifies the number of cells used to represent the size of an + address. Must be present if ranges is used. + Example: foo@1000 { diff --git a/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt b/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt new file mode 100644 index 000000000000..15bc885f9df4 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt @@ -0,0 +1,31 @@ +Motorola CPCAP PMIC device tree binding + +Required properties: +- compatible : One or both of "motorola,cpcap" or "ste,6556002" +- reg : SPI chip select +- interrupt-parent : The parent interrupt controller +- interrupts : The interrupt line the device is connected to +- interrupt-controller : Marks the device node as an interrupt controller +- #interrupt-cells : The number of cells to describe an IRQ, should be 2 +- #address-cells : Child device offset number of cells, should be 1 +- #size-cells : Child device size number of cells, should be 0 +- spi-max-frequency : Typically set to 3000000 +- spi-cs-high : SPI chip select direction + +Example: + +&mcspi1 { + cpcap: pmic@0 { + compatible = "motorola,cpcap", "ste,6556002"; + reg = <0>; /* cs0 */ + interrupt-parent = <&gpio1>; + interrupts = <7 IRQ_TYPE_EDGE_RISING>; + interrupt-controller; + #interrupt-cells = <2>; + #address-cells = <1>; + #size-cells = <0>; + spi-max-frequency = <3000000>; + spi-cs-high; + }; +}; + diff --git a/Documentation/devicetree/bindings/mfd/mt6397.txt b/Documentation/devicetree/bindings/mfd/mt6397.txt index 949c85f8d02c..c568d52af5af 100644 --- a/Documentation/devicetree/bindings/mfd/mt6397.txt +++ b/Documentation/devicetree/bindings/mfd/mt6397.txt @@ -34,6 +34,10 @@ Optional subnodes: - clk Required properties: - compatible: "mediatek,mt6397-clk" +- led + Required properties: + - compatible: "mediatek,mt6323-led" + see Documentation/devicetree/bindings/leds/leds-mt6323.txt Example: pwrap: pwrap@1000f000 { diff --git a/Documentation/devicetree/bindings/misc/atmel-ssc.txt b/Documentation/devicetree/bindings/misc/atmel-ssc.txt index efc98ea1f23d..f8629bb73945 100644 --- a/Documentation/devicetree/bindings/misc/atmel-ssc.txt +++ b/Documentation/devicetree/bindings/misc/atmel-ssc.txt @@ -24,6 +24,8 @@ Optional properties: this parameter to choose where the clock from. - By default the clock is from TK pin, if the clock from RK pin, this property is needed. + - #sound-dai-cells: Should contain <0>. + - This property makes the SSC into an automatically registered DAI. Examples: - PDC transfer: diff --git a/Documentation/devicetree/bindings/net/marvell,prestera.txt b/Documentation/devicetree/bindings/net/marvell,prestera.txt new file mode 100644 index 000000000000..5fbab29718e8 --- /dev/null +++ b/Documentation/devicetree/bindings/net/marvell,prestera.txt @@ -0,0 +1,50 @@ +Marvell Prestera Switch Chip bindings +------------------------------------- + +Required properties: +- compatible: one of the following + "marvell,prestera-98dx3236", + "marvell,prestera-98dx3336", + "marvell,prestera-98dx4251", +- reg: address and length of the register set for the device. +- interrupts: interrupt for the device + +Optional properties: +- dfx: phandle reference to the "DFX Server" node + +Example: + +switch { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 MBUS_ID(0x03, 0x00) 0 0x100000>; + + packet-processor@0 { + compatible = "marvell,prestera-98dx3236"; + reg = <0 0x4000000>; + interrupts = <33>, <34>, <35>; + dfx = <&dfx>; + }; +}; + +DFX Server bindings +------------------- + +Required properties: +- compatible: must be "marvell,dfx-server" +- reg: address and length of the register set for the device. + +Example: + +dfx-registers { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 MBUS_ID(0x08, 0x00) 0 0x100000>; + + dfx: dfx@0 { + compatible = "marvell,dfx-server"; + reg = <0 0x100000>; + }; +}; diff --git a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt index 59c2f47aa303..b7fa3b97986d 100644 --- a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt +++ b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt @@ -42,3 +42,40 @@ Hip05 Example (note that Hip06 is the same except compatible): 0x0 0 0 4 &mbigen_pcie 4 13>; status = "ok"; }; + +HiSilicon Hip06/Hip07 PCIe host bridge DT (almost-ECAM) description. +The properties and their meanings are identical to those described in +host-generic-pci.txt except as listed below. + +Properties of the host controller node that differ from +host-generic-pci.txt: + +- compatible : Must be "hisilicon,pcie-almost-ecam" + +- reg : Two entries: First the ECAM configuration space for any + other bus underneath the root bus. Second, the base + and size of the HiSilicon host bridge registers include + the RC's own config space. + +Example: + pcie0: pcie@a0090000 { + compatible = "hisilicon,pcie-almost-ecam"; + reg = <0 0xb0000000 0 0x2000000>, /* ECAM configuration space */ + <0 0xa0090000 0 0x10000>; /* host bridge registers */ + bus-range = <0 31>; + msi-map = <0x0000 &its_dsa 0x0000 0x2000>; + msi-map-mask = <0xffff>; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + dma-coherent; + ranges = <0x02000000 0 0xb2000000 0x0 0xb2000000 0 0x5ff0000 + 0x01000000 0 0 0 0xb7ff0000 0 0x10000>; + #interrupt-cells = <1>; + interrupt-map-mask = <0xf800 0 0 7>; + interrupt-map = <0x0 0 0 1 &mbigen_pcie0 650 4 + 0x0 0 0 2 &mbigen_pcie0 650 4 + 0x0 0 0 3 &mbigen_pcie0 650 4 + 0x0 0 0 4 &mbigen_pcie0 650 4>; + status = "ok"; + }; diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt index 08c716b2c6b6..2de6f65ecfb1 100644 --- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt +++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt @@ -78,7 +78,8 @@ and the following optional properties: multiple lanes. If this property is not found, we assume that the value is 0. - reset-gpios: optional gpio to PERST# -- reset-delay-us: delay in us to wait after reset de-assertion +- reset-delay-us: delay in us to wait after reset de-assertion, if not + specified will default to 100ms, as required by the PCIe specification. Example: diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt b/Documentation/devicetree/bindings/pci/rcar-pci.txt index eee518db90b9..34712d6fd253 100644 --- a/Documentation/devicetree/bindings/pci/rcar-pci.txt +++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt @@ -6,6 +6,7 @@ compatible: "renesas,pcie-r8a7779" for the R8A7779 SoC; "renesas,pcie-r8a7791" for the R8A7791 SoC; "renesas,pcie-r8a7793" for the R8A7793 SoC; "renesas,pcie-r8a7795" for the R8A7795 SoC; + "renesas,pcie-r8a7796" for the R8A7796 SoC; "renesas,pcie-rcar-gen2" for a generic R-Car Gen2 compatible device. "renesas,pcie-rcar-gen3" for a generic R-Car Gen3 compatible device. diff --git a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt index 71aeda1ca055..1453a734c2f5 100644 --- a/Documentation/devicetree/bindings/pci/rockchip-pcie.txt +++ b/Documentation/devicetree/bindings/pci/rockchip-pcie.txt @@ -43,6 +43,8 @@ Required properties: - interrupt-map-mask and interrupt-map: standard PCI properties Optional Property: +- aspm-no-l0s: RC won't support ASPM L0s. This property is needed if + using 24MHz OSC for RC's PHY. - ep-gpios: contain the entry for pre-reset gpio - num-lanes: number of lanes to use - vpcie3v3-supply: The phandle to the 3.3v regulator to use for PCIe. diff --git a/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt b/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt index 4f9d23d2ed67..7d3b09474657 100644 --- a/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt +++ b/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt @@ -7,8 +7,19 @@ Required properties: - compatible: "samsung,exynos5440-pcie" - reg: base addresses and lengths of the pcie controller, the phy controller, additional register for the phy controller. + (Registers for the phy controller are DEPRECATED. + Use the PHY framework.) +- reg-names : First name should be set to "elbi". + And use the "config" instead of getting the confgiruation address space + from "ranges". + NOTE: When use the "config" property, reg-names must be set. - interrupts: A list of interrupt outputs for level interrupt, pulse interrupt, special interrupt. +- phys: From PHY binding. Phandle for the Generic PHY. + Refer to Documentation/devicetree/bindings/phy/samsung-phy.txt + +Other common properties refer to + Documentation/devicetree/binding/pci/designware-pcie.txt Example: @@ -54,6 +65,24 @@ SoC specific DT Entry: num-lanes = <4>; }; +With using PHY framework: + pcie_phy0: pcie-phy@270000 { + ... + reg = <0x270000 0x1000>, <0x271000 0x40>; + reg-names = "phy", "block"; + ... + }; + + pcie@290000 { + ... + reg = <0x290000 0x1000>, <0x40000000 0x1000>; + reg-names = "elbi", "config"; + phys = <&pcie_phy0>; + ranges = <0x81000000 0 0 0x60001000 0 0x00010000 + 0x82000000 0 0x60011000 0x60011000 0 0x1ffef000>; + ... + }; + Board specific DT Entry: pcie@290000 { diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt index 9872ba8546bd..ab80bfe31cb3 100644 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt @@ -191,3 +191,20 @@ Example: usbdrdphy0 = &usb3_phy0; usbdrdphy1 = &usb3_phy1; }; + +Samsung Exynos SoC series PCIe PHY controller +-------------------------------------------------- +Required properties: +- compatible : Should be set to "samsung,exynos5440-pcie-phy" +- #phy-cells : Must be zero +- reg : a register used by phy driver. + - First is for phy register, second is for block register. +- reg-names : Must be set to "phy" and "block". + +Example: + pcie_phy0: pcie-phy@270000 { + #phy-cells = <0>; + compatible = "samsung,exynos5440-pcie-phy"; + reg = <0x270000 0x1000>, <0x271000 0x40>; + reg-names = "phy", "block"; + }; diff --git a/Documentation/devicetree/bindings/power/pd-samsung.txt b/Documentation/devicetree/bindings/power/pd-samsung.txt index 4e947372a693..7eb9674e9687 100644 --- a/Documentation/devicetree/bindings/power/pd-samsung.txt +++ b/Documentation/devicetree/bindings/power/pd-samsung.txt @@ -6,12 +6,15 @@ to gate power to one or more peripherals on the processor. Required Properties: - compatible: should be one of the following. * samsung,exynos4210-pd - for exynos4210 type power domain. + * samsung,exynos5433-pd - for exynos5433 type power domain. - reg: physical base address of the controller and length of memory mapped region. - #power-domain-cells: number of cells in power domain specifier; must be 0. Optional Properties: +- label: Human readable string with domain name. Will be visible in userspace + to let user to distinguish between multiple domains in SoC. - clocks: List of clock handles. The parent clocks of the input clocks to the devices in this power domain are set to oscclk before power gating and restored back after powering on a domain. This is required for @@ -38,6 +41,7 @@ Example: compatible = "samsung,exynos4210-pd"; reg = <0x10023C00 0x10>; #power-domain-cells = <0>; + label = "LCD0"; }; mfc_pd: power-domain@10044060 { @@ -46,6 +50,7 @@ Example: clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MOUT_USER_ACLK333>; clock-names = "oscclk", "clk0"; #power-domain-cells = <0>; + label = "MFC"; }; See Documentation/devicetree/bindings/power/power_domain.txt for description diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt index b85885a298d8..75ad7b8df0b1 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt +++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt @@ -9,6 +9,7 @@ on the Qualcomm ADSP Hexagon core. Definition: must be one of: "qcom,msm8974-adsp-pil" "qcom,msm8996-adsp-pil" + "qcom,msm8996-slpi-pil" - interrupts-extended: Usage: required @@ -24,13 +25,13 @@ on the Qualcomm ADSP Hexagon core. - clocks: Usage: required Value type: <prop-encoded-array> - Definition: reference to the xo clock to be held on behalf of the - booting Hexagon core + Definition: reference to the xo clock and optionally aggre2 clock to be + held on behalf of the booting Hexagon core - clock-names: Usage: required Value type: <stringlist> - Definition: must be "xo" + Definition: must be "xo" and optionally include "aggre2" - cx-supply: Usage: required @@ -38,6 +39,12 @@ on the Qualcomm ADSP Hexagon core. Definition: reference to the regulator to be held on behalf of the booting Hexagon core +- px-supply: + Usage: required + Value type: <phandle> + Definition: reference to the px regulator to be held on behalf of the + booting Hexagon core + - memory-region: Usage: required Value type: <phandle> @@ -96,3 +103,31 @@ ADSP, as it is found on MSM8974 boards. qcom,smd-edge = <1>; }; }; + +The following example describes the resources needed to boot control the +SLPI, as it is found on MSM8996 boards. + + slpi { + compatible = "qcom,msm8996-slpi-pil"; + interrupts-extended = <&intc 0 390 IRQ_TYPE_EDGE_RISING>, + <&slpi_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, + <&slpi_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, + <&slpi_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, + <&slpi_smp2p_in 3 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "wdog", + "fatal", + "ready", + "handover", + "stop-ack"; + + clocks = <&rpmcc MSM8996_RPM_SMD_XO_CLK_SRC>, + <&rpmcc MSM8996_RPM_SMD_AGGR2_NOC_CLK>; + clock-names = "xo", "aggre2"; + + cx-supply = <&pm8994_l26>; + px-supply = <&pm8994_lvs2>; + + memory-region = <&slpi_region>; + qcom,smem-states = <&slpi_smp2p_out 0>; + qcom,smem-state-names = "stop"; + }; diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt index 57cb49ec55ca..92347fe6890e 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt +++ b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt @@ -7,7 +7,9 @@ on the Qualcomm Hexagon core. Usage: required Value type: <string> Definition: must be one of: - "qcom,q6v5-pil" + "qcom,q6v5-pil", + "qcom,msm8916-mss-pil", + "qcom,msm8974-mss-pil" - reg: Usage: required diff --git a/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt new file mode 100644 index 000000000000..2bf3344b2a02 --- /dev/null +++ b/Documentation/devicetree/bindings/reset/hisilicon,hi3660-reset.txt @@ -0,0 +1,43 @@ +Hisilicon System Reset Controller +====================================== + +Please also refer to reset.txt in this directory for common reset +controller binding usage. + +The reset controller registers are part of the system-ctl block on +hi3660 SoC. + +Required properties: +- compatible: should be + "hisilicon,hi3660-reset" +- hisi,rst-syscon: phandle of the reset's syscon. +- #reset-cells : Specifies the number of cells needed to encode a + reset source. The type shall be a <u32> and the value shall be 2. + + Cell #1 : offset of the reset assert control + register from the syscon register base + offset + 4: deassert control register + offset + 8: status control register + Cell #2 : bit position of the reset in the reset control register + +Example: + iomcu: iomcu@ffd7e000 { + compatible = "hisilicon,hi3660-iomcu", "syscon"; + reg = <0x0 0xffd7e000 0x0 0x1000>; + }; + + iomcu_rst: iomcu_rst_controller { + compatible = "hisilicon,hi3660-reset"; + hisi,rst-syscon = <&iomcu>; + #reset-cells = <2>; + }; + +Specifying reset lines connected to IP modules +============================================== +example: + + i2c0: i2c@..... { + ... + resets = <&iomcu_rst 0x20 3>; /* offset: 0x20; bit: 3 */ + ... + }; diff --git a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt index 164c7f34c451..c516d24959f2 100644 --- a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt +++ b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt @@ -63,7 +63,7 @@ Example: -------- The following example demonstrates a syscon node, the reset controller node using the syscon node, and a consumer (a DSP device) on the TI Keystone 2 -Edison SoC. +66AK2E SoC. / { soc { @@ -71,13 +71,13 @@ Edison SoC. compatible = "syscon", "simple-mfd"; reg = <0x02350000 0x1000>; - pscrst: psc-reset { + pscrst: reset-controller { compatible = "ti,k2e-pscrst", "ti,syscon-reset"; #reset-cells = <1>; ti,reset-bits = < - 0xa3c 8 0xa3c 8 0x83c 8 (ASSERT_SET|DEASSERT_CLEAR|STATUS_SET) /* 0: pcrst-dsp0 */ - 0xa40 5 0xa44 3 0 0 (ASSERT_SET|DEASSERT_CLEAR|STATUS_NONE) /* 1: pcrst-example */ + 0xa3c 8 0xa3c 8 0x83c 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 0: dsp0 */ + 0xa40 5 0xa44 3 0 0 (ASSERT_SET | DEASSERT_CLEAR | STATUS_NONE) /* 1: example */ >; }; }; diff --git a/Documentation/devicetree/bindings/reset/uniphier-reset.txt b/Documentation/devicetree/bindings/reset/uniphier-reset.txt index 5020524cddeb..83ab0f599c40 100644 --- a/Documentation/devicetree/bindings/reset/uniphier-reset.txt +++ b/Documentation/devicetree/bindings/reset/uniphier-reset.txt @@ -6,14 +6,14 @@ System reset Required properties: - compatible: should be one of the following: - "socionext,uniphier-sld3-reset" - for sLD3 SoC. - "socionext,uniphier-ld4-reset" - for LD4 SoC. - "socionext,uniphier-pro4-reset" - for Pro4 SoC. - "socionext,uniphier-sld8-reset" - for sLD8 SoC. - "socionext,uniphier-pro5-reset" - for Pro5 SoC. - "socionext,uniphier-pxs2-reset" - for PXs2/LD6b SoC. - "socionext,uniphier-ld11-reset" - for LD11 SoC. - "socionext,uniphier-ld20-reset" - for LD20 SoC. + "socionext,uniphier-sld3-reset" - for sLD3 SoC + "socionext,uniphier-ld4-reset" - for LD4 SoC + "socionext,uniphier-pro4-reset" - for Pro4 SoC + "socionext,uniphier-sld8-reset" - for sLD8 SoC + "socionext,uniphier-pro5-reset" - for Pro5 SoC + "socionext,uniphier-pxs2-reset" - for PXs2/LD6b SoC + "socionext,uniphier-ld11-reset" - for LD11 SoC + "socionext,uniphier-ld20-reset" - for LD20 SoC - #reset-cells: should be 1. Example: @@ -37,14 +37,15 @@ Media I/O (MIO) reset, SD reset Required properties: - compatible: should be one of the following: - "socionext,uniphier-sld3-mio-reset" - for sLD3 SoC. - "socionext,uniphier-ld4-mio-reset" - for LD4 SoC. - "socionext,uniphier-pro4-mio-reset" - for Pro4 SoC. - "socionext,uniphier-sld8-mio-reset" - for sLD8 SoC. - "socionext,uniphier-pro5-sd-reset" - for Pro5 SoC. - "socionext,uniphier-pxs2-sd-reset" - for PXs2/LD6b SoC. - "socionext,uniphier-ld11-mio-reset" - for LD11 SoC. - "socionext,uniphier-ld20-sd-reset" - for LD20 SoC. + "socionext,uniphier-sld3-mio-reset" - for sLD3 SoC + "socionext,uniphier-ld4-mio-reset" - for LD4 SoC + "socionext,uniphier-pro4-mio-reset" - for Pro4 SoC + "socionext,uniphier-sld8-mio-reset" - for sLD8 SoC + "socionext,uniphier-pro5-sd-reset" - for Pro5 SoC + "socionext,uniphier-pxs2-sd-reset" - for PXs2/LD6b SoC + "socionext,uniphier-ld11-mio-reset" - for LD11 SoC (MIO) + "socionext,uniphier-ld11-sd-reset" - for LD11 SoC (SD) + "socionext,uniphier-ld20-sd-reset" - for LD20 SoC - #reset-cells: should be 1. Example: @@ -68,13 +69,13 @@ Peripheral reset Required properties: - compatible: should be one of the following: - "socionext,uniphier-ld4-peri-reset" - for LD4 SoC. - "socionext,uniphier-pro4-peri-reset" - for Pro4 SoC. - "socionext,uniphier-sld8-peri-reset" - for sLD8 SoC. - "socionext,uniphier-pro5-peri-reset" - for Pro5 SoC. - "socionext,uniphier-pxs2-peri-reset" - for PXs2/LD6b SoC. - "socionext,uniphier-ld11-peri-reset" - for LD11 SoC. - "socionext,uniphier-ld20-peri-reset" - for LD20 SoC. + "socionext,uniphier-ld4-peri-reset" - for LD4 SoC + "socionext,uniphier-pro4-peri-reset" - for Pro4 SoC + "socionext,uniphier-sld8-peri-reset" - for sLD8 SoC + "socionext,uniphier-pro5-peri-reset" - for Pro5 SoC + "socionext,uniphier-pxs2-peri-reset" - for PXs2/LD6b SoC + "socionext,uniphier-ld11-peri-reset" - for LD11 SoC + "socionext,uniphier-ld20-peri-reset" - for LD20 SoC - #reset-cells: should be 1. Example: diff --git a/Documentation/devicetree/bindings/reset/zte,zx2967-reset.txt b/Documentation/devicetree/bindings/reset/zte,zx2967-reset.txt new file mode 100644 index 000000000000..b015508f9780 --- /dev/null +++ b/Documentation/devicetree/bindings/reset/zte,zx2967-reset.txt @@ -0,0 +1,20 @@ +ZTE zx2967 SoCs Reset Controller +======================================= + +Please also refer to reset.txt in this directory for common reset +controller binding usage. + +Required properties: +- compatible: should be one of the following. + * zte,zx296718-reset +- reg: physical base address of the controller and length of memory mapped + region. +- #reset-cells: must be 1. + +example: + + reset: reset-controller@1461060 { + compatible = "zte,zx296718-reset"; + reg = <0x01461060 0x8>; + #reset-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.txt b/Documentation/devicetree/bindings/soc/rockchip/grf.txt index 013e71a2cdc7..c6e62cb30712 100644 --- a/Documentation/devicetree/bindings/soc/rockchip/grf.txt +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.txt @@ -5,11 +5,13 @@ is composed of many registers for system control. From RK3368 SoCs, the GRF is divided into two sections, - GRF, used for general non-secure system, +- SGRF, used for general secure system, - PMUGRF, used for always on system Required Properties: - compatible: GRF should be one of the followings + - "rockchip,rk3036-grf", "syscon": for rk3036 - "rockchip,rk3066-grf", "syscon": for rk3066 - "rockchip,rk3188-grf", "syscon": for rk3188 - "rockchip,rk3228-grf", "syscon": for rk3228 @@ -19,6 +21,8 @@ Required Properties: - compatible: PMUGRF should be one of the followings - "rockchip,rk3368-pmugrf", "syscon": for rk3368 - "rockchip,rk3399-pmugrf", "syscon": for rk3399 +- compatible: SGRF should be one of the following + - "rockchip,rk3288-sgrf", "syscon": for rk3288 - reg: physical base address of the controller and length of memory mapped region. diff --git a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt index f909ce06afc4..01bfb6745fbd 100644 --- a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt +++ b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt @@ -6,6 +6,7 @@ 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. + "rockchip,rk3328-power-controller" - for RK3328 SoCs. "rockchip,rk3368-power-controller" - for RK3368 SoCs. "rockchip,rk3399-power-controller" - for RK3399 SoCs. - #power-domain-cells: Number of cells in a power-domain specifier. @@ -16,6 +17,7 @@ Required properties for power domain controller: 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. + "include/dt-bindings/power/rk3328-power.h" - for RK3328 type power domain. "include/dt-bindings/power/rk3368-power.h" - for RK3368 type power domain. "include/dt-bindings/power/rk3399-power.h" - for RK3399 type power domain. - clocks (optional): phandles to clocks which need to be enabled while power domain @@ -90,6 +92,7 @@ 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. + "include/dt-bindings/power/rk3328-power.h" - for rk3328 type power domain. "include/dt-bindings/power/rk3368-power.h" - for rk3368 type power domain. "include/dt-bindings/power/rk3399-power.h" - for rk3399 type power domain. diff --git a/Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt b/Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt new file mode 100644 index 000000000000..7629de1c2c72 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/zte/pd-2967xx.txt @@ -0,0 +1,19 @@ +* ZTE zx2967 family Power Domains + +zx2967 family includes support for multiple power domains which are used +to gate power to one or more peripherals on the processor. + +Required Properties: + - compatible: should be one of the following. + * zte,zx296718-pcu - for zx296718 power domain. + - reg: physical base address of the controller and length of memory mapped + region. + - #power-domain-cells: Must be 1. + +Example: + + pcu_domain: pcu@117000 { + compatible = "zte,zx296718-pcu"; + reg = <0x00117000 0x1000>; + #power-domain-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt b/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt index 5b9b38f578bb..fdb25b492514 100644 --- a/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt +++ b/Documentation/devicetree/bindings/sound/axentia,tse850-pcm5142.txt @@ -2,8 +2,7 @@ Devicetree bindings for the Axentia TSE-850 audio complex Required properties: - compatible: "axentia,tse850-pcm5142" - - axentia,ssc-controller: The phandle of the atmel SSC controller used as - cpu dai. + - axentia,cpu-dai: The phandle of the cpu dai. - axentia,audio-codec: The phandle of the PCM5142 codec. - axentia,add-gpios: gpio specifier that controls the mixer. - axentia,loop1-gpios: gpio specifier that controls loop relays on channel 1. @@ -43,6 +42,12 @@ the PCM5142 codec. Example: + &ssc0 { + #sound-dai-cells = <0>; + + status = "okay"; + }; + &i2c { codec: pcm5142@4c { compatible = "ti,pcm5142"; @@ -77,7 +82,7 @@ Example: sound { compatible = "axentia,tse850-pcm5142"; - axentia,ssc-controller = <&ssc0>; + axentia,cpu-dai = <&ssc0>; axentia,audio-codec = <&codec>; axentia,add-gpios = <&pioA 8 GPIO_ACTIVE_LOW>; diff --git a/Documentation/devicetree/bindings/sound/es8328.txt b/Documentation/devicetree/bindings/sound/es8328.txt index 30ea8a318ae9..33fbf058c997 100644 --- a/Documentation/devicetree/bindings/sound/es8328.txt +++ b/Documentation/devicetree/bindings/sound/es8328.txt @@ -4,7 +4,7 @@ This device supports both I2C and SPI. Required properties: - - compatible : "everest,es8328" + - compatible : Should be "everest,es8328" or "everest,es8388" - DVDD-supply : Regulator providing digital core supply voltage 1.8 - 3.6V - AVDD-supply : Regulator providing analog supply voltage 3.3V - PVDD-supply : Regulator providing digital IO supply voltage 1.8 - 3.6V diff --git a/Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt b/Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt index 3e623a724e55..9800a560e0c2 100644 --- a/Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt +++ b/Documentation/devicetree/bindings/sound/mt2701-afe-pcm.txt @@ -4,6 +4,7 @@ Required properties: - compatible = "mediatek,mt2701-audio"; - reg: register location and size - interrupts: Should contain AFE interrupt +- power-domains: should define the power domain - clock-names: should have these clock names: "infra_sys_audio_clk", "top_audio_mux1_sel", @@ -58,6 +59,7 @@ Example: <0 0x112A0000 0 0x20000>; interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_LOW>, <GIC_SPI 132 IRQ_TYPE_LEVEL_LOW>; + power-domains = <&scpsys MT2701_POWER_DOMAIN_IFR_MSC>; clocks = <&infracfg CLK_INFRA_AUDIO>, <&topckgen CLK_TOP_AUD_MUX1_SEL>, <&topckgen CLK_TOP_AUD_MUX2_SEL>, diff --git a/Documentation/devicetree/bindings/sound/nau8540.txt b/Documentation/devicetree/bindings/sound/nau8540.txt new file mode 100644 index 000000000000..307a76528320 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nau8540.txt @@ -0,0 +1,16 @@ +NAU85L40 audio CODEC + +This device supports I2C only. + +Required properties: + + - compatible : "nuvoton,nau8540" + + - reg : the I2C address of the device. + +Example: + +codec: nau8540@1c { + compatible = "nuvoton,nau8540"; + reg = <0x1c>; +}; diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3288-hdmi-analog.txt b/Documentation/devicetree/bindings/sound/rockchip,rk3288-hdmi-analog.txt new file mode 100644 index 000000000000..2539e1d68107 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/rockchip,rk3288-hdmi-analog.txt @@ -0,0 +1,36 @@ +ROCKCHIP RK3288 with HDMI and analog audio + +Required properties: +- compatible: "rockchip,rk3288-hdmi-analog" +- rockchip,model: The user-visible name of this sound complex +- rockchip,i2s-controller: The phandle of the Rockchip I2S controller that's + connected to the CODEC +- rockchip,audio-codec: The phandle of the analog audio codec. +- rockchip,routing: A list of the connections between audio components. + Each entry is a pair of strings, the first being the + connection's sink, the second being the connection's + source. For this driver the first string should always be + "Analog". + +Optionnal properties: +- rockchip,hp-en-gpios = The phandle of the GPIO that power up/down the + headphone (when the analog output is an headphone). +- rockchip,hp-det-gpios = The phandle of the GPIO that detects the headphone + (when the analog output is an headphone). +- pinctrl-names, pinctrl-0: Please refer to pinctrl-bindings.txt + +Example: + +sound { + compatible = "rockchip,rockchip-audio-es8388"; + rockchip,model = "Analog audio output"; + rockchip,i2s-controller = <&i2s>; + rockchip,audio-codec = <&es8388>; + rockchip,routing = "Analog", "LOUT2", + "Analog", "ROUT2"; + rockchip,hp-en-gpios = <&gpio8 0 GPIO_ACTIVE_HIGH>; + rockchip,hp-det-gpios = <&gpio7 7 GPIO_ACTIVE_HIGH>; + pinctrl-names = "default"; + pinctrl-0 = <&headphone>; +}; + diff --git a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt index 7b526ec64991..f4adc58f82ba 100644 --- a/Documentation/devicetree/bindings/sound/sun4i-i2s.txt +++ b/Documentation/devicetree/bindings/sound/sun4i-i2s.txt @@ -7,6 +7,7 @@ Required properties: - compatible: should be one of the followings - "allwinner,sun4i-a10-i2s" + - "allwinner,sun6i-a31-i2s" - reg: physical base address of the controller and length of memory mapped region. - interrupts: should contain the I2S interrupt. @@ -19,6 +20,10 @@ Required properties: - "mod" : module clock for the I2S controller - #sound-dai-cells : Must be equal to 0 +Required properties for the following compatibles: + - "allwinner,sun6i-a31-i2s" +- resets: phandle to the reset line for this codec + Example: i2s0: i2s@01c22400 { diff --git a/Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt b/Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt new file mode 100644 index 000000000000..399b1b4bae22 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/sun8i-a33-codec.txt @@ -0,0 +1,63 @@ +Allwinner SUN8I audio codec +------------------------------------ + +On Sun8i-A33 SoCs, the audio is separated in different parts: + - A DAI driver. It uses the "sun4i-i2s" driver which is + documented here: + Documentation/devicetree/bindings/sound/sun4i-i2s.txt + - An analog part of the codec which is handled as PRCM registers. + See Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt + - An digital part of the codec which is documented in this current + binding documentation. + - And finally, an audio card which links all the above components. + The simple-audio card will be used. + See Documentation/devicetree/bindings/sound/simple-card.txt + +This bindings documentation exposes Sun8i codec (digital part). + +Required properties: +- compatible: must be "allwinner,sun8i-a33-codec" +- reg: must contain the registers location and length +- interrupts: must contain the codec interrupt +- clocks: a list of phandle + clock-specifer pairs, one for each entry + in clock-names. +- clock-names: should contain followings: + - "bus": the parent APB clock for this controller + - "mod": the parent module clock + +Here is an example to add a sound card and the codec binding on sun8i SoCs that +are similar to A33 using simple-card: + + sound { + compatible = "simple-audio-card"; + simple-audio-card,name = "sun8i-a33-audio"; + simple-audio-card,format = "i2s"; + simple-audio-card,frame-master = <&link_codec>; + simple-audio-card,bitclock-master = <&link_codec>; + simple-audio-card,mclk-fs = <512>; + simple-audio-card,aux-devs = <&codec_analog>; + simple-audio-card,routing = + "Left DAC", "Digital Left DAC", + "Right DAC", "Digital Right DAC"; + + simple-audio-card,cpu { + sound-dai = <&dai>; + }; + + link_codec: simple-audio-card,codec { + sound-dai = <&codec>; + }; + + soc@01c00000 { + [...] + + audio-codec@1c22e00 { + #sound-dai-cells = <0>; + compatible = "allwinner,sun8i-a33-codec"; + reg = <0x01c22e00 0x400>; + interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&ccu CLK_BUS_CODEC>, <&ccu CLK_AC_DIG>; + clock-names = "bus", "mod"; + }; + }; + diff --git a/Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt b/Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt index 0230c4d20506..fe0a65e6d629 100644 --- a/Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt +++ b/Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt @@ -10,6 +10,7 @@ Required properties: - compatible : should be one of the following: - "allwinner,sun4i-a10-spdif": for the Allwinner A10 SoC - "allwinner,sun6i-a31-spdif": for the Allwinner A31 SoC + - "allwinner,sun8i-h3-spdif": for the Allwinner H3 SoC - reg : Offset and length of the register set for the device. diff --git a/Documentation/devicetree/bindings/sound/zte,zx-i2s.txt b/Documentation/devicetree/bindings/sound/zte,zx-i2s.txt index 7e5aa6f6b5a1..292ad5083704 100644 --- a/Documentation/devicetree/bindings/sound/zte,zx-i2s.txt +++ b/Documentation/devicetree/bindings/sound/zte,zx-i2s.txt @@ -1,10 +1,12 @@ ZTE ZX296702 I2S controller Required properties: - - compatible : Must be "zte,zx296702-i2s" + - compatible : Must be one of: + "zte,zx296718-i2s", "zte,zx296702-i2s" + "zte,zx296702-i2s" - reg : Must contain I2S core's registers location and length - clocks : Pairs of phandle and specifier referencing the controller's clocks. - - clock-names: "tx" for the clock to the I2S interface. + - clock-names: "wclk" for the wclk, "pclk" for the pclk to the I2S interface. - dmas: Pairs of phandle and specifier for the DMA channel that is used by the core. The core expects two dma channels for transmit. - dma-names : Must be "tx" and "rx" @@ -16,12 +18,12 @@ please check: * dma/dma.txt Example: - i2s0: i2s0@0b005000 { + i2s0: i2s@b005000 { #sound-dai-cells = <0>; - compatible = "zte,zx296702-i2s"; + compatible = "zte,zx296718-i2s", "zte,zx296702-i2s"; reg = <0x0b005000 0x1000>; - clocks = <&lsp0clk ZX296702_I2S0_DIV>; - clock-names = "tx"; + clocks = <&audiocrm AUDIO_I2S0_WCLK>, <&audiocrm AUDIO_I2S0_PCLK>; + clock-names = "wclk", "pclk"; interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>; dmas = <&dma 5>, <&dma 6>; dma-names = "tx", "rx"; diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 1d0bb2c9def4..bd0ed3cb4994 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -164,11 +164,14 @@ kosagi Sutajio Ko-Usagi PTE Ltd. kyo Kyocera Corporation lacie LaCie lantiq Lantiq Semiconductor +lego LEGO Systems A/S lenovo Lenovo Group Ltd. lg LG Corporation +licheepi Lichee Pi linux Linux-specific binding lltc Linear Technology Corporation lsi LSI Corp. (LSI Logic) +lwn Liebherr-Werk Nenzing GmbH macnica Macnica Americas marvell Marvell Technology Group Ltd. maxim Maxim Integrated Products @@ -192,6 +195,7 @@ mpl MPL AG mqmaker mqmaker Inc. msi Micro-Star International Co. Ltd. mti Imagination Technologies Ltd. (formerly MIPS Technologies Inc.) +multi-inno Multi-Inno Technology Co.,Ltd mundoreader Mundo Reader S.L. murata Murata Manufacturing Co., Ltd. mxicy Macronix International Co., Ltd. @@ -201,6 +205,7 @@ nec NEC LCD Technologies, Ltd. neonode Neonode Inc. netgear NETGEAR netlogic Broadcom Corporation (formerly NetLogic Microsystems) +netron-dy Netron DY netxeon Shenzhen Netxeon Technology CO., LTD nexbox Nexbox newhaven Newhaven Display International @@ -232,6 +237,7 @@ pine64 Pine64 pixcir PIXCIR MICROELECTRONICS Co., Ltd plathome Plat'Home Co., Ltd. plda PLDA +poslab Poslab Technology Co., Ltd. powervr PowerVR (deprecated, use img) pulsedlight PulsedLight, Inc qca Qualcomm Atheros, Inc. @@ -301,6 +307,7 @@ technologic Technologic Systems terasic Terasic Inc. thine THine Electronics, Inc. ti Texas Instruments +tianma Tianma Micro-electronics Co., Ltd. tlm Trusted Logic Mobility topeet Topeet toradex Toradex AG @@ -333,7 +340,9 @@ x-powers X-Powers xes Extreme Engineering Solutions (X-ES) xillybus Xillybus Ltd. xlnx Xilinx +xunlong Shenzhen Xunlong Software CO.,Limited zarlink Zarlink Semiconductor +zeitec ZEITEC Semiconductor Co., LTD. zii Zodiac Inflight Innovations zte ZTE Corp. zyxel ZyXEL Communications Corp. diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt deleted file mode 100644 index ca44c5820585..000000000000 --- a/Documentation/dma-buf-sharing.txt +++ /dev/null @@ -1,482 +0,0 @@ - DMA Buffer Sharing API Guide - ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - - Sumit Semwal - <sumit dot semwal at linaro dot org> - <sumit dot semwal at ti dot com> - -This document serves as a guide to device-driver writers on what is the dma-buf -buffer sharing API, how to use it for exporting and using shared buffers. - -Any device driver which wishes to be a part of DMA buffer sharing, can do so as -either the 'exporter' of buffers, or the 'user' of buffers. - -Say a driver A wants to use buffers created by driver B, then we call B as the -exporter, and A as buffer-user. - -The exporter -- implements and manages operations[1] for the buffer -- allows other users to share the buffer by using dma_buf sharing APIs, -- manages the details of buffer allocation, -- decides about the actual backing storage where this allocation happens, -- takes care of any migration of scatterlist - for all (shared) users of this - buffer, - -The buffer-user -- is one of (many) sharing users of the buffer. -- doesn't need to worry about how the buffer is allocated, or where. -- needs a mechanism to get access to the scatterlist that makes up this buffer - in memory, mapped into its own address space, so it can access the same area - of memory. - -dma-buf operations for device dma only --------------------------------------- - -The dma_buf buffer sharing API usage contains the following steps: - -1. Exporter announces that it wishes to export a buffer -2. Userspace gets the file descriptor associated with the exported buffer, and - passes it around to potential buffer-users based on use case -3. Each buffer-user 'connects' itself to the buffer -4. When needed, buffer-user requests access to the buffer from exporter -5. When finished with its use, the buffer-user notifies end-of-DMA to exporter -6. when buffer-user is done using this buffer completely, it 'disconnects' - itself from the buffer. - - -1. Exporter's announcement of buffer export - - The buffer exporter announces its wish to export a buffer. In this, it - connects its own private buffer data, provides implementation for operations - that can be performed on the exported dma_buf, and flags for the file - associated with this buffer. All these fields are filled in struct - dma_buf_export_info, defined via the DEFINE_DMA_BUF_EXPORT_INFO macro. - - Interface: - DEFINE_DMA_BUF_EXPORT_INFO(exp_info) - struct dma_buf *dma_buf_export(struct dma_buf_export_info *exp_info) - - If this succeeds, dma_buf_export allocates a dma_buf structure, and - returns a pointer to the same. It also associates an anonymous file with this - buffer, so it can be exported. On failure to allocate the dma_buf object, - it returns NULL. - - 'exp_name' in struct dma_buf_export_info is the name of exporter - to - facilitate information while debugging. It is set to KBUILD_MODNAME by - default, so exporters don't have to provide a specific name, if they don't - wish to. - - DEFINE_DMA_BUF_EXPORT_INFO macro defines the struct dma_buf_export_info, - zeroes it out and pre-populates exp_name in it. - - -2. Userspace gets a handle to pass around to potential buffer-users - - Userspace entity requests for a file-descriptor (fd) which is a handle to the - anonymous file associated with the buffer. It can then share the fd with other - drivers and/or processes. - - Interface: - int dma_buf_fd(struct dma_buf *dmabuf, int flags) - - This API installs an fd for the anonymous file associated with this buffer; - returns either 'fd', or error. - -3. Each buffer-user 'connects' itself to the buffer - - Each buffer-user now gets a reference to the buffer, using the fd passed to - it. - - Interface: - struct dma_buf *dma_buf_get(int fd) - - This API will return a reference to the dma_buf, and increment refcount for - it. - - After this, the buffer-user needs to attach its device with the buffer, which - helps the exporter to know of device buffer constraints. - - Interface: - struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf, - struct device *dev) - - This API returns reference to an attachment structure, which is then used - for scatterlist operations. It will optionally call the 'attach' dma_buf - operation, if provided by the exporter. - - The dma-buf sharing framework does the bookkeeping bits related to managing - the list of all attachments to a buffer. - -Until this stage, the buffer-exporter has the option to choose not to actually -allocate the backing storage for this buffer, but wait for the first buffer-user -to request use of buffer for allocation. - - -4. When needed, buffer-user requests access to the buffer - - Whenever a buffer-user wants to use the buffer for any DMA, it asks for - access to the buffer using dma_buf_map_attachment API. At least one attach to - the buffer must have happened before map_dma_buf can be called. - - Interface: - struct sg_table * dma_buf_map_attachment(struct dma_buf_attachment *, - enum dma_data_direction); - - This is a wrapper to dma_buf->ops->map_dma_buf operation, which hides the - "dma_buf->ops->" indirection from the users of this interface. - - In struct dma_buf_ops, map_dma_buf is defined as - struct sg_table * (*map_dma_buf)(struct dma_buf_attachment *, - enum dma_data_direction); - - It is one of the buffer operations that must be implemented by the exporter. - It should return the sg_table containing scatterlist for this buffer, mapped - into caller's address space. - - If this is being called for the first time, the exporter can now choose to - scan through the list of attachments for this buffer, collate the requirements - of the attached devices, and choose an appropriate backing storage for the - buffer. - - Based on enum dma_data_direction, it might be possible to have multiple users - accessing at the same time (for reading, maybe), or any other kind of sharing - that the exporter might wish to make available to buffer-users. - - map_dma_buf() operation can return -EINTR if it is interrupted by a signal. - - -5. When finished, the buffer-user notifies end-of-DMA to exporter - - Once the DMA for the current buffer-user is over, it signals 'end-of-DMA' to - the exporter using the dma_buf_unmap_attachment API. - - Interface: - void dma_buf_unmap_attachment(struct dma_buf_attachment *, - struct sg_table *); - - This is a wrapper to dma_buf->ops->unmap_dma_buf() operation, which hides the - "dma_buf->ops->" indirection from the users of this interface. - - In struct dma_buf_ops, unmap_dma_buf is defined as - void (*unmap_dma_buf)(struct dma_buf_attachment *, - struct sg_table *, - enum dma_data_direction); - - unmap_dma_buf signifies the end-of-DMA for the attachment provided. Like - map_dma_buf, this API also must be implemented by the exporter. - - -6. when buffer-user is done using this buffer, it 'disconnects' itself from the - buffer. - - After the buffer-user has no more interest in using this buffer, it should - disconnect itself from the buffer: - - - it first detaches itself from the buffer. - - Interface: - void dma_buf_detach(struct dma_buf *dmabuf, - struct dma_buf_attachment *dmabuf_attach); - - This API removes the attachment from the list in dmabuf, and optionally calls - dma_buf->ops->detach(), if provided by exporter, for any housekeeping bits. - - - Then, the buffer-user returns the buffer reference to exporter. - - Interface: - void dma_buf_put(struct dma_buf *dmabuf); - - This API then reduces the refcount for this buffer. - - If, as a result of this call, the refcount becomes 0, the 'release' file - operation related to this fd is called. It calls the dmabuf->ops->release() - operation in turn, and frees the memory allocated for dmabuf when exported. - -NOTES: -- Importance of attach-detach and {map,unmap}_dma_buf operation pairs - The attach-detach calls allow the exporter to figure out backing-storage - constraints for the currently-interested devices. This allows preferential - allocation, and/or migration of pages across different types of storage - available, if possible. - - Bracketing of DMA access with {map,unmap}_dma_buf operations is essential - to allow just-in-time backing of storage, and migration mid-way through a - use-case. - -- Migration of backing storage if needed - If after - - at least one map_dma_buf has happened, - - and the backing storage has been allocated for this buffer, - another new buffer-user intends to attach itself to this buffer, it might - be allowed, if possible for the exporter. - - In case it is allowed by the exporter: - if the new buffer-user has stricter 'backing-storage constraints', and the - exporter can handle these constraints, the exporter can just stall on the - map_dma_buf until all outstanding access is completed (as signalled by - unmap_dma_buf). - Once all users have finished accessing and have unmapped this buffer, the - exporter could potentially move the buffer to the stricter backing-storage, - and then allow further {map,unmap}_dma_buf operations from any buffer-user - from the migrated backing-storage. - - If the exporter cannot fulfill the backing-storage constraints of the new - buffer-user device as requested, dma_buf_attach() would return an error to - denote non-compatibility of the new buffer-sharing request with the current - buffer. - - If the exporter chooses not to allow an attach() operation once a - map_dma_buf() API has been called, it simply returns an error. - -Kernel cpu access to a dma-buf buffer object --------------------------------------------- - -The motivation to allow cpu access from the kernel to a dma-buf object from the -importers side are: -- fallback operations, e.g. if the devices is connected to a usb bus and the - kernel needs to shuffle the data around first before sending it away. -- full transparency for existing users on the importer side, i.e. userspace - should not notice the difference between a normal object from that subsystem - and an imported one backed by a dma-buf. This is really important for drm - opengl drivers that expect to still use all the existing upload/download - paths. - -Access to a dma_buf from the kernel context involves three steps: - -1. Prepare access, which invalidate any necessary caches and make the object - available for cpu access. -2. Access the object page-by-page with the dma_buf map apis -3. Finish access, which will flush any necessary cpu caches and free reserved - resources. - -1. Prepare access - - Before an importer can access a dma_buf object with the cpu from the kernel - context, it needs to notify the exporter of the access that is about to - happen. - - Interface: - int dma_buf_begin_cpu_access(struct dma_buf *dmabuf, - enum dma_data_direction direction) - - This allows the exporter to ensure that the memory is actually available for - cpu access - the exporter might need to allocate or swap-in and pin the - backing storage. The exporter also needs to ensure that cpu access is - coherent for the access direction. The direction can be used by the exporter - to optimize the cache flushing, i.e. access with a different direction (read - instead of write) might return stale or even bogus data (e.g. when the - exporter needs to copy the data to temporary storage). - - This step might fail, e.g. in oom conditions. - -2. Accessing the buffer - - To support dma_buf objects residing in highmem cpu access is page-based using - an api similar to kmap. Accessing a dma_buf is done in aligned chunks of - PAGE_SIZE size. Before accessing a chunk it needs to be mapped, which returns - a pointer in kernel virtual address space. Afterwards the chunk needs to be - unmapped again. There is no limit on how often a given chunk can be mapped - and unmapped, i.e. the importer does not need to call begin_cpu_access again - before mapping the same chunk again. - - Interfaces: - void *dma_buf_kmap(struct dma_buf *, unsigned long); - void dma_buf_kunmap(struct dma_buf *, unsigned long, void *); - - There are also atomic variants of these interfaces. Like for kmap they - facilitate non-blocking fast-paths. Neither the importer nor the exporter (in - the callback) is allowed to block when using these. - - Interfaces: - void *dma_buf_kmap_atomic(struct dma_buf *, unsigned long); - void dma_buf_kunmap_atomic(struct dma_buf *, unsigned long, void *); - - For importers all the restrictions of using kmap apply, like the limited - supply of kmap_atomic slots. Hence an importer shall only hold onto at most 2 - atomic dma_buf kmaps at the same time (in any given process context). - - dma_buf kmap calls outside of the range specified in begin_cpu_access are - undefined. If the range is not PAGE_SIZE aligned, kmap needs to succeed on - the partial chunks at the beginning and end but may return stale or bogus - data outside of the range (in these partial chunks). - - Note that these calls need to always succeed. The exporter needs to complete - any preparations that might fail in begin_cpu_access. - - For some cases the overhead of kmap can be too high, a vmap interface - is introduced. This interface should be used very carefully, as vmalloc - space is a limited resources on many architectures. - - Interfaces: - void *dma_buf_vmap(struct dma_buf *dmabuf) - void dma_buf_vunmap(struct dma_buf *dmabuf, void *vaddr) - - The vmap call can fail if there is no vmap support in the exporter, or if it - runs out of vmalloc space. Fallback to kmap should be implemented. Note that - the dma-buf layer keeps a reference count for all vmap access and calls down - into the exporter's vmap function only when no vmapping exists, and only - unmaps it once. Protection against concurrent vmap/vunmap calls is provided - by taking the dma_buf->lock mutex. - -3. Finish access - - When the importer is done accessing the CPU, it needs to announce this to - the exporter (to facilitate cache flushing and unpinning of any pinned - resources). The result of any dma_buf kmap calls after end_cpu_access is - undefined. - - Interface: - void dma_buf_end_cpu_access(struct dma_buf *dma_buf, - enum dma_data_direction dir); - - -Direct Userspace Access/mmap Support ------------------------------------- - -Being able to mmap an export dma-buf buffer object has 2 main use-cases: -- CPU fallback processing in a pipeline and -- supporting existing mmap interfaces in importers. - -1. CPU fallback processing in a pipeline - - In many processing pipelines it is sometimes required that the cpu can access - the data in a dma-buf (e.g. for thumbnail creation, snapshots, ...). To avoid - the need to handle this specially in userspace frameworks for buffer sharing - it's ideal if the dma_buf fd itself can be used to access the backing storage - from userspace using mmap. - - Furthermore Android's ION framework already supports this (and is otherwise - rather similar to dma-buf from a userspace consumer side with using fds as - handles, too). So it's beneficial to support this in a similar fashion on - dma-buf to have a good transition path for existing Android userspace. - - No special interfaces, userspace simply calls mmap on the dma-buf fd, making - sure that the cache synchronization ioctl (DMA_BUF_IOCTL_SYNC) is *always* - used when the access happens. Note that DMA_BUF_IOCTL_SYNC can fail with - -EAGAIN or -EINTR, in which case it must be restarted. - - Some systems might need some sort of cache coherency management e.g. when - CPU and GPU domains are being accessed through dma-buf at the same time. To - circumvent this problem there are begin/end coherency markers, that forward - directly to existing dma-buf device drivers vfunc hooks. Userspace can make - use of those markers through the DMA_BUF_IOCTL_SYNC ioctl. The sequence - would be used like following: - - mmap dma-buf fd - - for each drawing/upload cycle in CPU 1. SYNC_START ioctl, 2. read/write - to mmap area 3. SYNC_END ioctl. This can be repeated as often as you - want (with the new data being consumed by the GPU or say scanout device) - - munmap once you don't need the buffer any more - - For correctness and optimal performance, it is always required to use - SYNC_START and SYNC_END before and after, respectively, when accessing the - mapped address. Userspace cannot rely on coherent access, even when there - are systems where it just works without calling these ioctls. - -2. Supporting existing mmap interfaces in importers - - Similar to the motivation for kernel cpu access it is again important that - the userspace code of a given importing subsystem can use the same interfaces - with a imported dma-buf buffer object as with a native buffer object. This is - especially important for drm where the userspace part of contemporary OpenGL, - X, and other drivers is huge, and reworking them to use a different way to - mmap a buffer rather invasive. - - The assumption in the current dma-buf interfaces is that redirecting the - initial mmap is all that's needed. A survey of some of the existing - subsystems shows that no driver seems to do any nefarious thing like syncing - up with outstanding asynchronous processing on the device or allocating - special resources at fault time. So hopefully this is good enough, since - adding interfaces to intercept pagefaults and allow pte shootdowns would - increase the complexity quite a bit. - - Interface: - int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *, - unsigned long); - - If the importing subsystem simply provides a special-purpose mmap call to set - up a mapping in userspace, calling do_mmap with dma_buf->file will equally - achieve that for a dma-buf object. - -3. Implementation notes for exporters - - Because dma-buf buffers have invariant size over their lifetime, the dma-buf - core checks whether a vma is too large and rejects such mappings. The - exporter hence does not need to duplicate this check. - - Because existing importing subsystems might presume coherent mappings for - userspace, the exporter needs to set up a coherent mapping. If that's not - possible, it needs to fake coherency by manually shooting down ptes when - leaving the cpu domain and flushing caches at fault time. Note that all the - dma_buf files share the same anon inode, hence the exporter needs to replace - the dma_buf file stored in vma->vm_file with it's own if pte shootdown is - required. This is because the kernel uses the underlying inode's address_space - for vma tracking (and hence pte tracking at shootdown time with - unmap_mapping_range). - - If the above shootdown dance turns out to be too expensive in certain - scenarios, we can extend dma-buf with a more explicit cache tracking scheme - for userspace mappings. But the current assumption is that using mmap is - always a slower path, so some inefficiencies should be acceptable. - - Exporters that shoot down mappings (for any reasons) shall not do any - synchronization at fault time with outstanding device operations. - Synchronization is an orthogonal issue to sharing the backing storage of a - buffer and hence should not be handled by dma-buf itself. This is explicitly - mentioned here because many people seem to want something like this, but if - different exporters handle this differently, buffer sharing can fail in - interesting ways depending upong the exporter (if userspace starts depending - upon this implicit synchronization). - -Other Interfaces Exposed to Userspace on the dma-buf FD ------------------------------------------------------- - -- Since kernel 3.12 the dma-buf FD supports the llseek system call, but only - with offset=0 and whence=SEEK_END|SEEK_SET. SEEK_SET is supported to allow - the usual size discover pattern size = SEEK_END(0); SEEK_SET(0). Every other - llseek operation will report -EINVAL. - - If llseek on dma-buf FDs isn't support the kernel will report -ESPIPE for all - cases. Userspace can use this to detect support for discovering the dma-buf - size using llseek. - -Miscellaneous notes -------------------- - -- Any exporters or users of the dma-buf buffer sharing framework must have - a 'select DMA_SHARED_BUFFER' in their respective Kconfigs. - -- In order to avoid fd leaks on exec, the FD_CLOEXEC flag must be set - on the file descriptor. This is not just a resource leak, but a - potential security hole. It could give the newly exec'd application - access to buffers, via the leaked fd, to which it should otherwise - not be permitted access. - - The problem with doing this via a separate fcntl() call, versus doing it - atomically when the fd is created, is that this is inherently racy in a - multi-threaded app[3]. The issue is made worse when it is library code - opening/creating the file descriptor, as the application may not even be - aware of the fd's. - - To avoid this problem, userspace must have a way to request O_CLOEXEC - flag be set when the dma-buf fd is created. So any API provided by - the exporting driver to create a dmabuf fd must provide a way to let - userspace control setting of O_CLOEXEC flag passed in to dma_buf_fd(). - -- If an exporter needs to manually flush caches and hence needs to fake - coherency for mmap support, it needs to be able to zap all the ptes pointing - at the backing storage. Now linux mm needs a struct address_space associated - with the struct file stored in vma->vm_file to do that with the function - unmap_mapping_range. But the dma_buf framework only backs every dma_buf fd - with the anon_file struct file, i.e. all dma_bufs share the same file. - - Hence exporters need to setup their own file (and address_space) association - by setting vma->vm_file and adjusting vma->vm_pgoff in the dma_buf mmap - callback. In the specific case of a gem driver the exporter could use the - shmem file already provided by gem (and set vm_pgoff = 0). Exporters can then - zap ptes by unmapping the corresponding range of the struct address_space - associated with their own file. - -References: -[1] struct dma_buf_ops in include/linux/dma-buf.h -[2] All interfaces mentioned above defined in include/linux/dma-buf.h -[3] https://lwn.net/Articles/236486/ diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index a9b457a4b949..31671b469627 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -17,6 +17,98 @@ shared or exclusive fence(s) associated with the buffer. Shared DMA Buffers ------------------ +This document serves as a guide to device-driver writers on what is the dma-buf +buffer sharing API, how to use it for exporting and using shared buffers. + +Any device driver which wishes to be a part of DMA buffer sharing, can do so as +either the 'exporter' of buffers, or the 'user' or 'importer' of buffers. + +Say a driver A wants to use buffers created by driver B, then we call B as the +exporter, and A as buffer-user/importer. + +The exporter + + - implements and manages operations in :c:type:`struct dma_buf_ops + <dma_buf_ops>` for the buffer, + - allows other users to share the buffer by using dma_buf sharing APIs, + - manages the details of buffer allocation, wrapped int a :c:type:`struct + dma_buf <dma_buf>`, + - decides about the actual backing storage where this allocation happens, + - and takes care of any migration of scatterlist - for all (shared) users of + this buffer. + +The buffer-user + + - is one of (many) sharing users of the buffer. + - doesn't need to worry about how the buffer is allocated, or where. + - and needs a mechanism to get access to the scatterlist that makes up this + buffer in memory, mapped into its own address space, so it can access the + same area of memory. This interface is provided by :c:type:`struct + dma_buf_attachment <dma_buf_attachment>`. + +Any exporters or users of the dma-buf buffer sharing framework must have a +'select DMA_SHARED_BUFFER' in their respective Kconfigs. + +Userspace Interface Notes +~~~~~~~~~~~~~~~~~~~~~~~~~ + +Mostly a DMA buffer file descriptor is simply an opaque object for userspace, +and hence the generic interface exposed is very minimal. There's a few things to +consider though: + +- Since kernel 3.12 the dma-buf FD supports the llseek system call, but only + with offset=0 and whence=SEEK_END|SEEK_SET. SEEK_SET is supported to allow + the usual size discover pattern size = SEEK_END(0); SEEK_SET(0). Every other + llseek operation will report -EINVAL. + + If llseek on dma-buf FDs isn't support the kernel will report -ESPIPE for all + cases. Userspace can use this to detect support for discovering the dma-buf + size using llseek. + +- In order to avoid fd leaks on exec, the FD_CLOEXEC flag must be set + on the file descriptor. This is not just a resource leak, but a + potential security hole. It could give the newly exec'd application + access to buffers, via the leaked fd, to which it should otherwise + not be permitted access. + + The problem with doing this via a separate fcntl() call, versus doing it + atomically when the fd is created, is that this is inherently racy in a + multi-threaded app[3]. The issue is made worse when it is library code + opening/creating the file descriptor, as the application may not even be + aware of the fd's. + + To avoid this problem, userspace must have a way to request O_CLOEXEC + flag be set when the dma-buf fd is created. So any API provided by + the exporting driver to create a dmabuf fd must provide a way to let + userspace control setting of O_CLOEXEC flag passed in to dma_buf_fd(). + +- Memory mapping the contents of the DMA buffer is also supported. See the + discussion below on `CPU Access to DMA Buffer Objects`_ for the full details. + +- The DMA buffer FD is also pollable, see `Fence Poll Support`_ below for + details. + +Basic Operation and Device DMA Access +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: drivers/dma-buf/dma-buf.c + :doc: dma buf device access + +CPU Access to DMA Buffer Objects +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: drivers/dma-buf/dma-buf.c + :doc: cpu access + +Fence Poll Support +~~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: drivers/dma-buf/dma-buf.c + :doc: fence polling + +Kernel Functions and Structures Reference +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + .. kernel-doc:: drivers/dma-buf/dma-buf.c :export: diff --git a/Documentation/gpio/driver.txt b/Documentation/gpio/driver.txt index ad8f0c0cd13f..fc1d2f83564d 100644 --- a/Documentation/gpio/driver.txt +++ b/Documentation/gpio/driver.txt @@ -41,34 +41,71 @@ In the gpiolib framework each GPIO controller is packaged as a "struct gpio_chip" (see linux/gpio/driver.h for its complete definition) with members common to each controller of that type: - - methods to establish GPIO direction - - methods used to access GPIO values - - method to return the IRQ number associated to a given GPIO + - methods to establish GPIO line direction + - methods used to access GPIO line values + - method to set electrical configuration to a a given GPIO line + - method to return the IRQ number associated to a given GPIO line - flag saying whether calls to its methods may sleep + - optional line names array to identify lines - optional debugfs dump method (showing extra state like pullup config) - optional base number (will be automatically assigned if omitted) - - label for diagnostics and GPIOs mapping using platform data + - optional label for diagnostics and GPIO chip mapping using platform data The code implementing a gpio_chip should support multiple instances of the controller, possibly using the driver model. That code will configure each -gpio_chip and issue gpiochip_add(). Removing a GPIO controller should be rare; -use gpiochip_remove() when it is unavoidable. +gpio_chip and issue gpiochip_add[_data]() or devm_gpiochip_add_data(). +Removing a GPIO controller should be rare; use [devm_]gpiochip_remove() when +it is unavoidable. -Most often a gpio_chip is part of an instance-specific structure with state not +Often a gpio_chip is part of an instance-specific structure with states not exposed by the GPIO interfaces, such as addressing, power management, and more. -Chips such as codecs will have complex non-GPIO state. +Chips such as audio codecs will have complex non-GPIO states. Any debugfs dump method should normally ignore signals which haven't been requested as GPIOs. They can use gpiochip_is_requested(), which returns either NULL or the label associated with that GPIO when it was requested. -RT_FULL: GPIO driver should not use spinlock_t or any sleepable APIs +RT_FULL: the GPIO driver should not use spinlock_t or any sleepable APIs (like PM runtime) in its gpio_chip implementation (.get/.set and direction control callbacks) if it is expected to call GPIO APIs from atomic context on -RT (inside hard IRQ handlers and similar contexts). Normally this should not be required. +GPIO electrical configuration +----------------------------- + +GPIOs can be configured for several electrical modes of operation by using the +.set_config() callback. Currently this API supports setting debouncing and +single-ended modes (open drain/open source). These settings are described +below. + +The .set_config() callback uses the same enumerators and configuration +semantics as the generic pin control drivers. This is not a coincidence: it is +possible to assign the .set_config() to the function gpiochip_generic_config() +which will result in pinctrl_gpio_set_config() being called and eventually +ending up in the pin control back-end "behind" the GPIO controller, usually +closer to the actual pins. This way the pin controller can manage the below +listed GPIO configurations. + + +GPIOs with debounce support +--------------------------- + +Debouncing is a configuration set to a pin indicating that it is connected to +a mechanical switch or button, or similar that may bounce. Bouncing means the +line is pulled high/low quickly at very short intervals for mechanical +reasons. This can result in the value being unstable or irqs fireing repeatedly +unless the line is debounced. + +Debouncing in practice involves setting up a timer when something happens on +the line, wait a little while and then sample the line again, so see if it +still has the same value (low or high). This could also be repeated by a clever +state machine, waiting for a line to become stable. In either case, it sets +a certain number of milliseconds for debouncing, or just "on/off" if that time +is not configurable. + + GPIOs with open drain/source support ------------------------------------ diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index 0c9abdc0ee31..4d4068855ec4 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -48,11 +48,17 @@ CRTC Abstraction ================ .. kernel-doc:: drivers/gpu/drm/drm_crtc.c - :export: + :doc: overview + +CRTC Functions Reference +-------------------------------- .. kernel-doc:: include/drm/drm_crtc.h :internal: +.. kernel-doc:: drivers/gpu/drm/drm_crtc.c + :export: + Frame Buffer Abstraction ======================== diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index cb5daffcd6be..f5760b140f13 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -34,25 +34,26 @@ TTM initialization ------------------ **Warning** - This section is outdated. -Drivers wishing to support TTM must fill out a drm_bo_driver -structure. The structure contains several fields with function pointers -for initializing the TTM, allocating and freeing memory, waiting for -command completion and fence synchronization, and memory migration. See -the radeon_ttm.c file for an example of usage. +Drivers wishing to support TTM must pass a filled :c:type:`ttm_bo_driver +<ttm_bo_driver>` structure to ttm_bo_device_init, together with an +initialized global reference to the memory manager. The ttm_bo_driver +structure contains several fields with function pointers for +initializing the TTM, allocating and freeing memory, waiting for command +completion and fence synchronization, and memory migration. -The ttm_global_reference structure is made up of several fields: +The :c:type:`struct drm_global_reference <drm_global_reference>` is made +up of several fields: .. code-block:: c - struct ttm_global_reference { + struct drm_global_reference { enum ttm_global_types global_type; size_t size; void *object; - int (*init) (struct ttm_global_reference *); - void (*release) (struct ttm_global_reference *); + int (*init) (struct drm_global_reference *); + void (*release) (struct drm_global_reference *); }; @@ -76,6 +77,12 @@ ttm_bo_global_release(), respectively. Also, like the previous object, ttm_global_item_ref() is used to create an initial reference count for the TTM, which will call your initialization function. +See the radeon_ttm.c file for an example of usage. + +.. kernel-doc:: drivers/gpu/drm/drm_global.c + :export: + + The Graphics Execution Manager (GEM) ==================================== @@ -284,10 +291,17 @@ To use :c:func:`drm_gem_mmap()`, drivers must fill the struct :c:type:`struct drm_driver <drm_driver>` gem_vm_ops field with a pointer to VM operations. -struct vm_operations_struct \*gem_vm_ops struct -vm_operations_struct { void (\*open)(struct vm_area_struct \* area); -void (\*close)(struct vm_area_struct \* area); int (\*fault)(struct -vm_area_struct \*vma, struct vm_fault \*vmf); }; +The VM operations is a :c:type:`struct vm_operations_struct <vm_operations_struct>` +made up of several fields, the more interesting ones being: + +.. code-block:: c + + struct vm_operations_struct { + void (*open)(struct vm_area_struct * area); + void (*close)(struct vm_area_struct * area); + int (*fault)(struct vm_fault *vmf); + }; + The open and close operations must update the GEM object reference count. Drivers can use the :c:func:`drm_gem_vm_open()` and @@ -303,6 +317,17 @@ created. Drivers that want to map the GEM object upfront instead of handling page faults can implement their own mmap file operation handler. +For platforms without MMU the GEM core provides a helper method +:c:func:`drm_gem_cma_get_unmapped_area`. The mmap() routines will call +this to get a proposed address for the mapping. + +To use :c:func:`drm_gem_cma_get_unmapped_area`, drivers must fill the +struct :c:type:`struct file_operations <file_operations>` get_unmapped_area +field with a pointer on :c:func:`drm_gem_cma_get_unmapped_area`. + +More detailed information about get_unmapped_area can be found in +Documentation/nommu-mmap.txt + Memory Coherency ---------------- @@ -442,7 +467,7 @@ LRU Scan/Eviction Support ------------------------- .. kernel-doc:: drivers/gpu/drm/drm_mm.c - :doc: lru scan roaster + :doc: lru scan roster DRM MM Range Allocator Function References ------------------------------------------ @@ -452,3 +477,9 @@ DRM MM Range Allocator Function References .. kernel-doc:: include/drm/drm_mm.h :internal: + +DRM Cache Handling +================== + +.. kernel-doc:: drivers/gpu/drm/drm_cache.c + :export: diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index de3ac9f90f8f..fcc228ef5bc4 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -156,8 +156,12 @@ other hand, a driver requires shared state between clients which is visible to user-space and accessible beyond open-file boundaries, they cannot support render nodes. + +Testing and validation +====================== + Validating changes with IGT -=========================== +--------------------------- There's a collection of tests that aims to cover the whole functionality of DRM drivers and that can be used to check that changes to DRM drivers or the @@ -193,6 +197,12 @@ run-tests.sh is a wrapper around piglit that will execute the tests matching the -t options. A report in HTML format will be available in ./results/html/index.html. Results can be compared with piglit. +Display CRC Support +------------------- + +.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c + :doc: CRC ABI + VBlank event handling ===================== @@ -209,16 +219,3 @@ DRM_IOCTL_MODESET_CTL mode setting, since on many devices the vertical blank counter is reset to 0 at some point during modeset. Modern drivers should not call this any more since with kernel mode setting it is a no-op. - -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 -chapter. - -Testing and validation -====================== - -.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c - :doc: CRC ABI diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 117d2ab7a5f7..b0d6709b8600 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -144,6 +144,15 @@ High Definition Audio .. kernel-doc:: include/drm/i915_component.h :internal: +Intel HDMI LPE Audio Support +---------------------------- + +.. kernel-doc:: drivers/gpu/drm/i915/intel_lpe_audio.c + :doc: LPE Audio integration for HDMI or DP playback + +.. kernel-doc:: drivers/gpu/drm/i915/intel_lpe_audio.c + :internal: + Panel Self Refresh PSR (PSR/SRD) -------------------------------- @@ -213,6 +222,18 @@ Video BIOS Table (VBT) .. kernel-doc:: drivers/gpu/drm/i915/intel_vbt_defs.h :internal: +Display PLLs +------------ + +.. kernel-doc:: drivers/gpu/drm/i915/intel_dpll_mgr.c + :doc: Display PLLs + +.. kernel-doc:: drivers/gpu/drm/i915/intel_dpll_mgr.c + :internal: + +.. kernel-doc:: drivers/gpu/drm/i915/intel_dpll_mgr.h + :internal: + Memory Management and Command Submission ======================================== @@ -356,4 +377,95 @@ switch_mm .. kernel-doc:: drivers/gpu/drm/i915/i915_trace.h :doc: switch_mm tracepoint +Perf +==== + +Overview +-------- +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :doc: i915 Perf Overview + +Comparison with Core Perf +------------------------- +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :doc: i915 Perf History and Comparison with Core Perf + +i915 Driver Entry Points +------------------------ + +This section covers the entrypoints exported outside of i915_perf.c to +integrate with drm/i915 and to handle the `DRM_I915_PERF_OPEN` ioctl. + +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_perf_init +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_perf_fini +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_perf_register +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_perf_unregister +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_perf_open_ioctl +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_perf_release + +i915 Perf Stream +---------------- + +This section covers the stream-semantics-agnostic structures and functions +for representing an i915 perf stream FD and associated file operations. + +.. kernel-doc:: drivers/gpu/drm/i915/i915_drv.h + :functions: i915_perf_stream +.. kernel-doc:: drivers/gpu/drm/i915/i915_drv.h + :functions: i915_perf_stream_ops + +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: read_properties_unlocked +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_perf_open_ioctl_locked +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_perf_destroy_locked +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_perf_read +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_perf_ioctl +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_perf_enable_locked +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_perf_disable_locked +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_perf_poll +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_perf_poll_locked + +i915 Perf Observation Architecture Stream +----------------------------------------- + +.. kernel-doc:: drivers/gpu/drm/i915/i915_drv.h + :functions: i915_oa_ops + +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_oa_stream_init +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_oa_read +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_oa_stream_enable +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_oa_stream_disable +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_oa_wait_unlocked +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :functions: i915_oa_poll_wait + +All i915 Perf Internals +----------------------- + +This section simply includes all currently documented i915 perf internals, in +no particular order, but may include some more minor utilities or platform +specific details than found in the more high-level sections. + +.. kernel-doc:: drivers/gpu/drm/i915/i915_perf.c + :internal: + .. WARNING: DOCPROC directive not supported: !Cdrivers/gpu/drm/i915/i915_irq.c diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst index 367d7c36b8e9..f81278a7c2cc 100644 --- a/Documentation/gpu/index.rst +++ b/Documentation/gpu/index.rst @@ -11,6 +11,7 @@ Linux GPU Driver Developer's Guide drm-kms-helpers drm-uapi i915 + tinydrm vga-switcheroo vgaarbiter diff --git a/Documentation/gpu/introduction.rst b/Documentation/gpu/introduction.rst index 1903595b5310..eb284eb748ba 100644 --- a/Documentation/gpu/introduction.rst +++ b/Documentation/gpu/introduction.rst @@ -23,13 +23,12 @@ For consistency this documentation uses American English. Abbreviations are written as all-uppercase, for example: DRM, KMS, IOCTL, CRTC, and so on. To aid in reading, documentations make full use of the markup characters kerneldoc provides: @parameter for function parameters, -@member for structure members, &structure to reference structures and -function() for functions. These all get automatically hyperlinked if -kerneldoc for the referenced objects exists. When referencing entries in -function vtables please use ->vfunc(). Note that kerneldoc does not -support referencing struct members directly, so please add a reference -to the vtable struct somewhere in the same paragraph or at least -section. +@member for structure members (within the same structure), &struct structure to +reference structures and function() for functions. These all get automatically +hyperlinked if kerneldoc for the referenced objects exists. When referencing +entries in function vtables (and structure members in general) please use +&vtable_name.vfunc. Unfortunately this does not yet yield a direct link to the +member, only the structure. Except in special situations (to separate locked from unlocked variants) locking requirements for functions aren't documented in the kerneldoc. @@ -49,3 +48,5 @@ section name should be all upper-case or not, and whether it should end in a colon or not. Go with the file-local style. Other common section names are "Notes" with information for dangerous or tricky corner cases, and "FIXME" where the interface could be cleaned up. + +Also read the :ref:`guidelines for the kernel documentation at large <doc_guide>`. diff --git a/Documentation/gpu/tinydrm.rst b/Documentation/gpu/tinydrm.rst new file mode 100644 index 000000000000..a913644bfc19 --- /dev/null +++ b/Documentation/gpu/tinydrm.rst @@ -0,0 +1,42 @@ +========================== +drm/tinydrm Driver library +========================== + +.. kernel-doc:: drivers/gpu/drm/tinydrm/core/tinydrm-core.c + :doc: overview + +Core functionality +================== + +.. kernel-doc:: drivers/gpu/drm/tinydrm/core/tinydrm-core.c + :doc: core + +.. kernel-doc:: include/drm/tinydrm/tinydrm.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/tinydrm/core/tinydrm-core.c + :export: + +.. kernel-doc:: drivers/gpu/drm/tinydrm/core/tinydrm-pipe.c + :export: + +Additional helpers +================== + +.. kernel-doc:: include/drm/tinydrm/tinydrm-helpers.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c + :export: + +MIPI DBI Compatible Controllers +=============================== + +.. kernel-doc:: drivers/gpu/drm/tinydrm/mipi-dbi.c + :doc: overview + +.. kernel-doc:: include/drm/tinydrm/mipi-dbi.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/tinydrm/mipi-dbi.c + :export: diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index 81c7f2bb7daf..08244bea5048 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -321,6 +321,7 @@ Code Seq#(hex) Include File Comments 0xB1 00-1F PPPoX <mailto:mostrows@styx.uwaterloo.ca> 0xB3 00 linux/mmc/ioctl.h 0xB4 00-0F linux/gpio.h <mailto:linux-gpio@vger.kernel.org> +0xB5 00-0F uapi/linux/rpmsg.h <mailto:linux-remoteproc@vger.kernel.org> 0xC0 00-0F linux/usb/iowarrior.h 0xCA 00-0F uapi/misc/cxl.h 0xCA 80-8F uapi/scsi/cxlflash_ioctl.h diff --git a/Documentation/md-cluster.txt b/Documentation/md/md-cluster.txt index 38883276d31c..38883276d31c 100644 --- a/Documentation/md-cluster.txt +++ b/Documentation/md/md-cluster.txt diff --git a/Documentation/md/raid5-cache.txt b/Documentation/md/raid5-cache.txt new file mode 100644 index 000000000000..2b210f295786 --- /dev/null +++ b/Documentation/md/raid5-cache.txt @@ -0,0 +1,109 @@ +RAID5 cache + +Raid 4/5/6 could include an extra disk for data cache besides normal RAID +disks. The role of RAID disks isn't changed with the cache disk. The cache disk +caches data to the RAID disks. The cache can be in write-through (supported +since 4.4) or write-back mode (supported since 4.10). mdadm (supported since +3.4) has a new option '--write-journal' to create array with cache. Please +refer to mdadm manual for details. By default (RAID array starts), the cache is +in write-through mode. A user can switch it to write-back mode by: + +echo "write-back" > /sys/block/md0/md/journal_mode + +And switch it back to write-through mode by: + +echo "write-through" > /sys/block/md0/md/journal_mode + +In both modes, all writes to the array will hit cache disk first. This means +the cache disk must be fast and sustainable. + +------------------------------------- +write-through mode: + +This mode mainly fixes the 'write hole' issue. For RAID 4/5/6 array, an unclean +shutdown can cause data in some stripes to not be in consistent state, eg, data +and parity don't match. The reason is that a stripe write involves several RAID +disks and it's possible the writes don't hit all RAID disks yet before the +unclean shutdown. We call an array degraded if it has inconsistent data. MD +tries to resync the array to bring it back to normal state. But before the +resync completes, any system crash will expose the chance of real data +corruption in the RAID array. This problem is called 'write hole'. + +The write-through cache will cache all data on cache disk first. After the data +is safe on the cache disk, the data will be flushed onto RAID disks. The +two-step write will guarantee MD can recover correct data after unclean +shutdown even the array is degraded. Thus the cache can close the 'write hole'. + +In write-through mode, MD reports IO completion to upper layer (usually +filesystems) after the data is safe on RAID disks, so cache disk failure +doesn't cause data loss. Of course cache disk failure means the array is +exposed to 'write hole' again. + +In write-through mode, the cache disk isn't required to be big. Several +hundreds megabytes are enough. + +-------------------------------------- +write-back mode: + +write-back mode fixes the 'write hole' issue too, since all write data is +cached on cache disk. But the main goal of 'write-back' cache is to speed up +write. If a write crosses all RAID disks of a stripe, we call it full-stripe +write. For non-full-stripe writes, MD must read old data before the new parity +can be calculated. These synchronous reads hurt write throughput. Some writes +which are sequential but not dispatched in the same time will suffer from this +overhead too. Write-back cache will aggregate the data and flush the data to +RAID disks only after the data becomes a full stripe write. This will +completely avoid the overhead, so it's very helpful for some workloads. A +typical workload which does sequential write followed by fsync is an example. + +In write-back mode, MD reports IO completion to upper layer (usually +filesystems) right after the data hits cache disk. The data is flushed to raid +disks later after specific conditions met. So cache disk failure will cause +data loss. + +In write-back mode, MD also caches data in memory. The memory cache includes +the same data stored on cache disk, so a power loss doesn't cause data loss. +The memory cache size has performance impact for the array. It's recommended +the size is big. A user can configure the size by: + +echo "2048" > /sys/block/md0/md/stripe_cache_size + +Too small cache disk will make the write aggregation less efficient in this +mode depending on the workloads. It's recommended to use a cache disk with at +least several gigabytes size in write-back mode. + +-------------------------------------- +The implementation: + +The write-through and write-back cache use the same disk format. The cache disk +is organized as a simple write log. The log consists of 'meta data' and 'data' +pairs. The meta data describes the data. It also includes checksum and sequence +ID for recovery identification. Data can be IO data and parity data. Data is +checksumed too. The checksum is stored in the meta data ahead of the data. The +checksum is an optimization because MD can write meta and data freely without +worry about the order. MD superblock has a field pointed to the valid meta data +of log head. + +The log implementation is pretty straightforward. The difficult part is the +order in which MD writes data to cache disk and RAID disks. Specifically, in +write-through mode, MD calculates parity for IO data, writes both IO data and +parity to the log, writes the data and parity to RAID disks after the data and +parity is settled down in log and finally the IO is finished. Read just reads +from raid disks as usual. + +In write-back mode, MD writes IO data to the log and reports IO completion. The +data is also fully cached in memory at that time, which means read must query +memory cache. If some conditions are met, MD will flush the data to RAID disks. +MD will calculate parity for the data and write parity into the log. After this +is finished, MD will write both data and parity into RAID disks, then MD can +release the memory cache. The flush conditions could be stripe becomes a full +stripe write, free cache disk space is low or free in-kernel memory cache space +is low. + +After an unclean shutdown, MD does recovery. MD reads all meta data and data +from the log. The sequence ID and checksum will help us detect corrupted meta +data and data. If MD finds a stripe with data and valid parities (1 parity for +raid4/5 and 2 for raid6), MD will write the data and parities to RAID disks. If +parities are incompleted, they are discarded. If part of data is corrupted, +they are discarded too. MD then loads valid data and writes them to RAID disks +in normal way. diff --git a/Documentation/sound/hd-audio/dp-mst.rst b/Documentation/sound/hd-audio/dp-mst.rst index 58b72437e6c3..1617459e332f 100644 --- a/Documentation/sound/hd-audio/dp-mst.rst +++ b/Documentation/sound/hd-audio/dp-mst.rst @@ -19,6 +19,23 @@ PCM === To be added +Pin Initialization +================== +Each pin may have several device entries (virtual pins). On Intel platform, +the device entries number is dynamically changed. If DP MST hub is connected, +it is in DP MST mode, and the device entries number is 3. Otherwise, the +device entries number is 1. + +To simplify the implementation, all the device entries will be initialized +when bootup no matter whether it is in DP MST mode or not. + +Connection list +=============== +DP MST reuses connection list code. The code can be reused because +device entries on the same pin have the same connection list. + +This means DP MST gets the device entry connection list without the +device entry setting. Jack ==== |