From b4b7ff4b08e691656c9d77c758fc355833128ac0 Mon Sep 17 00:00:00 2001 From: André Fabian Silva Delgado Date: Wed, 20 Jan 2016 14:01:31 -0300 Subject: Linux-libre 4.4-gnu --- .../ABI/obsolete/sysfs-driver-hid-roccat-arvo | 53 + .../ABI/obsolete/sysfs-driver-hid-roccat-isku | 153 + .../ABI/obsolete/sysfs-driver-hid-roccat-koneplus | 99 +- .../ABI/obsolete/sysfs-driver-hid-roccat-konepure | 105 + .../ABI/obsolete/sysfs-driver-hid-roccat-kovaplus | 50 + .../ABI/obsolete/sysfs-driver-hid-roccat-lua | 7 + .../ABI/obsolete/sysfs-driver-hid-roccat-pyra | 50 + .../ABI/obsolete/sysfs-driver-hid-roccat-ryos | 178 + .../ABI/obsolete/sysfs-driver-hid-roccat-savu | 76 + Documentation/ABI/stable/sysfs-class-tpm | 4 +- Documentation/ABI/stable/sysfs-firmware-opal-elog | 2 +- Documentation/ABI/testing/configfs-stp-policy | 48 + Documentation/ABI/testing/sysfs-block | 7 + .../ABI/testing/sysfs-bus-coresight-devices-etm3x | 83 +- Documentation/ABI/testing/sysfs-bus-iio | 32 + Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 | 43 + .../ABI/testing/sysfs-bus-iio-chemical-vz89x | 7 + .../ABI/testing/sysfs-bus-iio-humidity-hdc100x | 9 + Documentation/ABI/testing/sysfs-bus-iio-meas-spec | 8 + .../ABI/testing/sysfs-bus-iio-trigger-sysfs | 22 + .../ABI/testing/sysfs-bus-intel_th-devices-gth | 49 + .../ABI/testing/sysfs-bus-intel_th-devices-msc | 33 + .../ABI/testing/sysfs-bus-intel_th-devices-pti | 24 + .../ABI/testing/sysfs-bus-intel_th-output-devices | 13 + Documentation/ABI/testing/sysfs-bus-mei | 7 + Documentation/ABI/testing/sysfs-bus-usb | 20 + Documentation/ABI/testing/sysfs-class-fpga-manager | 37 + Documentation/ABI/testing/sysfs-class-mic.txt | 29 +- Documentation/ABI/testing/sysfs-class-power | 58 + Documentation/ABI/testing/sysfs-class-stm | 14 + Documentation/ABI/testing/sysfs-class-stm_source | 11 + Documentation/ABI/testing/sysfs-driver-hid-corsair | 15 + .../ABI/testing/sysfs-driver-hid-roccat-arvo | 53 - .../ABI/testing/sysfs-driver-hid-roccat-isku | 153 - .../ABI/testing/sysfs-driver-hid-roccat-koneplus | 96 - .../ABI/testing/sysfs-driver-hid-roccat-konepure | 105 - .../ABI/testing/sysfs-driver-hid-roccat-kovaplus | 49 - .../ABI/testing/sysfs-driver-hid-roccat-lua | 7 - .../ABI/testing/sysfs-driver-hid-roccat-pyra | 49 - .../ABI/testing/sysfs-driver-hid-roccat-ryos | 178 - .../ABI/testing/sysfs-driver-hid-roccat-savu | 76 - Documentation/ABI/testing/sysfs-driver-ppi | 19 +- Documentation/ABI/testing/sysfs-driver-st | 12 + Documentation/ABI/testing/sysfs-fs-f2fs | 12 + Documentation/ABI/testing/sysfs-power | 12 + Documentation/Changes | 1 + Documentation/DMA-API-HOWTO.txt | 5 + Documentation/DMA-API.txt | 19 +- Documentation/DocBook/.gitignore | 2 + Documentation/DocBook/80211.tmpl | 5 +- Documentation/DocBook/Makefile | 8 +- Documentation/DocBook/alsa-driver-api.tmpl | 2 + Documentation/DocBook/device-drivers.tmpl | 81 +- Documentation/DocBook/drm.tmpl | 4263 ------------------- Documentation/DocBook/gpu.tmpl | 4286 ++++++++++++++++++++ Documentation/DocBook/iio.tmpl | 2 +- Documentation/DocBook/media/dvb/dvbapi.xml | 3 - Documentation/DocBook/media/dvb/kdapi.xml | 2309 ----------- Documentation/DocBook/media/v4l/biblio.xml | 18 + Documentation/DocBook/media/v4l/compat.xml | 20 + Documentation/DocBook/media/v4l/controls.xml | 14 + Documentation/DocBook/media/v4l/dev-sdr.xml | 32 +- Documentation/DocBook/media/v4l/io.xml | 10 +- Documentation/DocBook/media/v4l/pixfmt.xml | 111 +- Documentation/DocBook/media/v4l/v4l2.xml | 13 +- .../DocBook/media/v4l/vidioc-encoder-cmd.xml | 2 +- .../DocBook/media/v4l/vidioc-g-ext-ctrls.xml | 7 + Documentation/DocBook/media/v4l/vidioc-g-fmt.xml | 2 +- .../DocBook/media/v4l/vidioc-g-modulator.xml | 14 +- Documentation/DocBook/media/v4l/vidioc-g-tuner.xml | 16 + .../DocBook/media/v4l/vidioc-querycap.xml | 6 + .../DocBook/media/v4l/vidioc-queryctrl.xml | 21 +- Documentation/DocBook/media_api.tmpl | 2 +- Documentation/DocBook/writing-an-alsa-driver.tmpl | 19 +- Documentation/IPMI.txt | 7 +- Documentation/IRQ-domain.txt | 8 +- Documentation/RCU/stallwarn.txt | 7 + Documentation/RCU/torture.txt | 39 +- Documentation/RCU/trace.txt | 32 +- Documentation/RCU/whatisRCU.txt | 6 +- Documentation/SubmittingPatches | 23 +- Documentation/acpi/enumeration.txt | 11 +- Documentation/acpi/i2c-muxes.txt | 58 + Documentation/arm/SA1100/Victor | 16 - Documentation/arm/Samsung/Bootloader-interface.txt | 5 +- Documentation/arm/keystone/Overview.txt | 18 - Documentation/arm/keystone/knav-qmss.txt | 35 + Documentation/arm/memory.txt | 2 +- Documentation/arm/sunxi/README | 2 +- Documentation/arm/uefi.txt | 4 - Documentation/arm64/booting.txt | 18 +- Documentation/atomic_ops.txt | 4 + Documentation/block/null_blk.txt | 3 + Documentation/block/pr.txt | 119 + Documentation/blockdev/zram.txt | 44 +- Documentation/cgroups/blkio-controller.txt | 2 +- Documentation/cgroups/cgroups.txt | 4 + Documentation/cgroups/freezer-subsystem.txt | 2 +- Documentation/cgroups/unified-hierarchy.txt | 27 +- Documentation/crypto/asymmetric-keys.txt | 27 +- Documentation/device-mapper/delay.txt | 1 + .../devicetree/bindings/arc/archs-idu-intc.txt | 46 - .../devicetree/bindings/arc/archs-intc.txt | 22 - .../devicetree/bindings/arc/interrupts.txt | 24 - Documentation/devicetree/bindings/arm/amlogic.txt | 10 +- Documentation/devicetree/bindings/arm/apm/scu.txt | 17 + Documentation/devicetree/bindings/arm/arm,scpi.txt | 188 + .../devicetree/bindings/arm/bcm/brcm,brcmstb.txt | 162 +- .../devicetree/bindings/arm/bcm/brcm,nsp.txt | 34 + .../devicetree/bindings/arm/calxeda/combophy.txt | 17 - .../devicetree/bindings/arm/calxeda/mem-ctrlr.txt | 16 - .../devicetree/bindings/arm/coherency-fabric.txt | 5 + Documentation/devicetree/bindings/arm/cpus.txt | 2 + .../devicetree/bindings/arm/davinci/cp-intc.txt | 27 - .../bindings/arm/exynos/power_domain.txt | 53 - Documentation/devicetree/bindings/arm/fsl.txt | 16 +- Documentation/devicetree/bindings/arm/gic-v3.txt | 123 - Documentation/devicetree/bindings/arm/gic.txt | 152 - .../bindings/arm/hisilicon/hisilicon.txt | 21 + .../devicetree/bindings/arm/keystone/keystone.txt | 20 +- .../devicetree/bindings/arm/lpc32xx-mic.txt | 38 - .../bindings/arm/mediatek/mediatek,imgsys.txt | 22 + .../bindings/arm/mediatek/mediatek,mmsys.txt | 22 + .../bindings/arm/mediatek/mediatek,sysirq.txt | 32 - .../bindings/arm/mediatek/mediatek,vdecsys.txt | 22 + .../bindings/arm/mediatek/mediatek,vencltsys.txt | 22 + .../bindings/arm/mediatek/mediatek,vencsys.txt | 22 + .../devicetree/bindings/arm/mrvl/intc.txt | 60 - .../devicetree/bindings/arm/mvebu-cpu-config.txt | 20 + .../devicetree/bindings/arm/omap/intc.txt | 27 - Documentation/devicetree/bindings/arm/pmu.txt | 3 + Documentation/devicetree/bindings/arm/psci.txt | 6 + Documentation/devicetree/bindings/arm/rockchip.txt | 11 + .../devicetree/bindings/arm/samsung-boards.txt | 27 - .../bindings/arm/samsung/interrupt-combiner.txt | 52 - .../bindings/arm/samsung/samsung-boards.txt | 69 + Documentation/devicetree/bindings/arm/shmobile.txt | 10 +- .../devicetree/bindings/arm/spear/shirq.txt | 48 - Documentation/devicetree/bindings/arm/sunxi.txt | 1 + .../devicetree/bindings/arm/tegra/nvidia,nvec.txt | 21 + Documentation/devicetree/bindings/arm/twd.txt | 5 + .../bindings/arm/uniphier/cache-uniphier.txt | 60 + .../devicetree/bindings/arm/versatile-fpga-irq.txt | 36 - Documentation/devicetree/bindings/arm/vic.txt | 41 - .../bindings/arm/vt8500/via,vt8500-intc.txt | 16 - .../devicetree/bindings/ata/ahci-fsl-qoriq.txt | 21 + .../devicetree/bindings/ata/ahci-platform.txt | 2 - .../devicetree/bindings/board/fsl-board.txt | 112 + .../devicetree/bindings/bus/sunxi-rsb.txt | 47 + .../devicetree/bindings/c6x/interrupt.txt | 104 - Documentation/devicetree/bindings/chosen.txt | 8 + .../devicetree/bindings/clock/at91-clock.txt | 35 + .../bindings/clock/brcm,bcm2835-cprman.txt | 45 + .../bindings/clock/brcm,iproc-clocks.txt | 78 + .../devicetree/bindings/clock/qcom,gcc.txt | 4 + .../devicetree/bindings/clock/qcom,mmcc.txt | 4 + .../devicetree/bindings/clock/qoriq-clock.txt | 61 +- .../bindings/clock/renesas,cpg-div6-clocks.txt | 2 +- .../devicetree/bindings/clock/renesas,cpg-mssr.txt | 69 + .../devicetree/bindings/clock/silabs,si514.txt | 24 + .../devicetree/bindings/clock/st/st,clkgen-pll.txt | 1 + .../devicetree/bindings/cris/interrupts.txt | 23 - .../devicetree/bindings/crypto/fsl-sec4.txt | 4 +- .../devicetree/bindings/display/arm,pl11x.txt | 109 + .../bindings/display/armada/marvell,dove-lcd.txt | 30 + .../devicetree/bindings/display/atmel,lcdc.txt | 89 + .../devicetree/bindings/display/atmel/hlcdc-dc.txt | 53 + .../devicetree/bindings/display/brcm,bcm-vc4.txt | 65 + .../bindings/display/bridge/adi,adv7123.txt | 50 + .../bindings/display/bridge/adi,adv7511.txt | 88 + .../devicetree/bindings/display/bridge/dw_hdmi.txt | 50 + .../devicetree/bindings/display/bridge/ps8622.txt | 31 + .../devicetree/bindings/display/bridge/ptn3460.txt | 39 + .../devicetree/bindings/display/bridge/tda998x.txt | 29 + .../bindings/display/bridge/thine,thc63lvdm83d.txt | 50 + .../bindings/display/cirrus,clps711x-fb.txt | 47 + .../display/connector/analog-tv-connector.txt | 25 + .../bindings/display/connector/dvi-connector.txt | 35 + .../bindings/display/connector/hdmi-connector.txt | 29 + .../bindings/display/connector/vga-connector.txt | 36 + .../bindings/display/exynos/exynos-mic.txt | 51 + .../bindings/display/exynos/exynos5433-decon.txt | 65 + .../bindings/display/exynos/exynos7-decon.txt | 68 + .../bindings/display/exynos/exynos_dp.txt | 120 + .../bindings/display/exynos/exynos_dsim.txt | 103 + .../bindings/display/exynos/exynos_hdmi.txt | 43 + .../bindings/display/exynos/exynos_hdmiddc.txt | 15 + .../bindings/display/exynos/exynos_hdmiphy.txt | 15 + .../bindings/display/exynos/exynos_mixer.txt | 26 + .../bindings/display/exynos/samsung-fimd.txt | 110 + .../devicetree/bindings/display/fsl,dcu.txt | 22 + .../devicetree/bindings/display/imx/fsl,imx-fb.txt | 55 + .../bindings/display/imx/fsl-imx-drm.txt | 105 + .../devicetree/bindings/display/imx/hdmi.txt | 58 + .../devicetree/bindings/display/imx/ldb.txt | 146 + .../bindings/display/marvell,pxa2xx-lcdc.txt | 34 + .../devicetree/bindings/display/mipi-dsi-bus.txt | 98 + .../devicetree/bindings/display/msm/dsi.txt | 149 + .../devicetree/bindings/display/msm/edp.txt | 60 + .../devicetree/bindings/display/msm/gpu.txt | 52 + .../devicetree/bindings/display/msm/hdmi.txt | 58 + .../devicetree/bindings/display/msm/mdp.txt | 49 + .../devicetree/bindings/display/mxsfb.txt | 49 + .../display/panel/ampire,am800480r3tmqwa1h.txt | 7 + .../bindings/display/panel/auo,b080uan01.txt | 7 + .../bindings/display/panel/auo,b101aw03.txt | 7 + .../bindings/display/panel/auo,b101ean01.txt | 7 + .../bindings/display/panel/auo,b101xtn01.txt | 7 + .../bindings/display/panel/auo,b116xw03.txt | 7 + .../bindings/display/panel/auo,b133htn01.txt | 7 + .../bindings/display/panel/auo,b133xtn01.txt | 7 + .../bindings/display/panel/avic,tm070ddh03.txt | 7 + .../display/panel/chunghwa,claa101wa01a.txt | 7 + .../display/panel/chunghwa,claa101wb03.txt | 7 + .../bindings/display/panel/display-timing.txt | 110 + .../bindings/display/panel/edt,et057090dhu.txt | 7 + .../bindings/display/panel/edt,et070080dh6.txt | 10 + .../bindings/display/panel/edt,etm0700g0dh6.txt | 10 + .../display/panel/foxlink,fl500wvr00-a0t.txt | 7 + .../display/panel/giantplus,gpg482739qs5.txt | 7 + .../bindings/display/panel/hannstar,hsd070pww1.txt | 7 + .../bindings/display/panel/hannstar,hsd100pxn1.txt | 7 + .../bindings/display/panel/hit,tx23d38vm0caa.txt | 7 + .../bindings/display/panel/innolux,at043tn24.txt | 7 + .../bindings/display/panel/innolux,g121i1-l01.txt | 7 + .../bindings/display/panel/innolux,n116bge.txt | 7 + .../bindings/display/panel/innolux,n156bge-l21.txt | 7 + .../bindings/display/panel/innolux,zj070na-01p.txt | 7 + .../bindings/display/panel/lg,lb070wv8.txt | 7 + .../bindings/display/panel/lg,ld070wx3-sl01.txt | 7 + .../bindings/display/panel/lg,lg4573.txt | 19 + .../bindings/display/panel/lg,lh500wx1-sd03.txt | 7 + .../bindings/display/panel/lg,lp129qe.txt | 7 + .../bindings/display/panel/lgphilips,lb035q02.txt | 33 + .../bindings/display/panel/nec,nl4827hc19-05b.txt | 7 + .../display/panel/okaya,rs800480t-7x0gp.txt | 7 + .../display/panel/ortustech,com43h4m85ulc.txt | 7 + .../display/panel/panasonic,vvx10f004b00.txt | 7 + .../bindings/display/panel/panel-dpi.txt | 45 + .../bindings/display/panel/panel-dsi-cm.txt | 29 + .../bindings/display/panel/samsung,ld9040.txt | 66 + .../bindings/display/panel/samsung,ltn101nt05.txt | 7 + .../display/panel/samsung,ltn140at29-301.txt | 7 + .../bindings/display/panel/samsung,s6e8aa0.txt | 56 + .../bindings/display/panel/sharp,lq101r1sx01.txt | 49 + .../bindings/display/panel/sharp,ls037v7dw01.txt | 43 + .../display/panel/shelly,sca07010-bfn-lnn.txt | 7 + .../bindings/display/panel/simple-panel.txt | 21 + .../bindings/display/panel/sony,acx565akm.txt | 30 + .../bindings/display/panel/toppoly,td028ttec1.txt | 30 + .../bindings/display/panel/tpo,td043mtea1.txt | 33 + .../devicetree/bindings/display/renesas,du.txt | 92 + .../bindings/display/rockchip/dw_hdmi-rockchip.txt | 46 + .../bindings/display/rockchip/rockchip-drm.txt | 19 + .../bindings/display/rockchip/rockchip-vop.txt | 58 + .../bindings/display/simple-framebuffer-sunxi.txt | 33 + .../bindings/display/simple-framebuffer.txt | 86 + .../devicetree/bindings/display/sm501fb.txt | 34 + .../devicetree/bindings/display/ssd1289fb.txt | 13 + .../devicetree/bindings/display/ssd1307fb.txt | 50 + .../devicetree/bindings/display/st,stih4xx.txt | 241 ++ .../display/tegra/nvidia,tegra114-mipi.txt | 41 + .../display/tegra/nvidia,tegra20-host1x.txt | 380 ++ .../devicetree/bindings/display/ti/ti,dra7-dss.txt | 69 + .../devicetree/bindings/display/ti/ti,omap-dss.txt | 211 + .../bindings/display/ti/ti,omap2-dss.txt | 54 + .../bindings/display/ti/ti,omap3-dss.txt | 83 + .../bindings/display/ti/ti,omap4-dss.txt | 115 + .../bindings/display/ti/ti,omap5-dss.txt | 96 + .../devicetree/bindings/display/ti/ti,opa362.txt | 38 + .../devicetree/bindings/display/ti/ti,tfp410.txt | 41 + .../bindings/display/ti/ti,tpd12s015.txt | 44 + .../devicetree/bindings/display/tilcdc/panel.txt | 66 + .../devicetree/bindings/display/tilcdc/tfp410.txt | 21 + .../devicetree/bindings/display/tilcdc/tilcdc.txt | 56 + .../devicetree/bindings/display/via,vt8500-fb.txt | 36 + .../bindings/display/wm,prizm-ge-rops.txt | 13 + .../devicetree/bindings/display/wm,wm8505-fb.txt | 33 + .../devicetree/bindings/dma/ti-dma-crossbar.txt | 15 +- Documentation/devicetree/bindings/dma/ti-edma.txt | 115 +- .../bindings/drm/armada/marvell,dove-lcd.txt | 30 - .../devicetree/bindings/drm/atmel/hlcdc-dc.txt | 53 - .../devicetree/bindings/drm/bridge/dw_hdmi.txt | 50 - .../devicetree/bindings/drm/i2c/tda998x.txt | 29 - .../devicetree/bindings/drm/imx/fsl-imx-drm.txt | 105 - Documentation/devicetree/bindings/drm/imx/hdmi.txt | 58 - Documentation/devicetree/bindings/drm/imx/ldb.txt | 146 - Documentation/devicetree/bindings/drm/msm/dsi.txt | 149 - Documentation/devicetree/bindings/drm/msm/edp.txt | 60 - Documentation/devicetree/bindings/drm/msm/gpu.txt | 52 - Documentation/devicetree/bindings/drm/msm/hdmi.txt | 55 - Documentation/devicetree/bindings/drm/msm/mdp.txt | 48 - .../devicetree/bindings/drm/tilcdc/panel.txt | 66 - .../devicetree/bindings/drm/tilcdc/tfp410.txt | 21 - .../devicetree/bindings/drm/tilcdc/tilcdc.txt | 56 - .../devicetree/bindings/edac/apm-xgene-edac.txt | 23 + Documentation/devicetree/bindings/eeprom.txt | 28 - Documentation/devicetree/bindings/eeprom/at25.txt | 35 + .../devicetree/bindings/eeprom/eeprom.txt | 28 + .../devicetree/bindings/extcon/extcon-arizona.txt | 15 + Documentation/devicetree/bindings/fb/mxsfb.txt | 49 - Documentation/devicetree/bindings/fb/sm501fb.txt | 34 - .../bindings/fpga/altera-socfpga-fpga-mgr.txt | 2 +- .../bindings/fpga/xilinx-zynq-fpga-mgr.txt | 19 + .../devicetree/bindings/gpio/gpio-mpc8xxx.txt | 8 +- .../devicetree/bindings/gpio/gpio-msm.txt | 26 - .../devicetree/bindings/gpio/gpio-pca953x.txt | 1 + .../devicetree/bindings/gpio/gpio-zynq.txt | 9 + Documentation/devicetree/bindings/gpio/gpio.txt | 41 +- .../devicetree/bindings/gpio/netxbig-gpio-ext.txt | 22 + .../bindings/gpu/nvidia,tegra20-host1x.txt | 380 -- .../devicetree/bindings/gpu/st,stih4xx.txt | 241 -- .../devicetree/bindings/hid/hid-over-i2c.txt | 28 - Documentation/devicetree/bindings/hwmon/ina209.txt | 18 - Documentation/devicetree/bindings/hwmon/ina2xx.txt | 1 + .../devicetree/bindings/hwmon/pwm-fan.txt | 29 +- .../devicetree/bindings/hwrng/atmel-trng.txt | 16 - .../bindings/hwrng/brcm,iproc-rng200.txt | 12 - .../devicetree/bindings/hwrng/omap_rng.txt | 22 - .../devicetree/bindings/hwrng/timeriomem_rng.txt | 18 - .../devicetree/bindings/i2c/i2c-davinci.txt | 6 +- Documentation/devicetree/bindings/i2c/i2c-imx.txt | 9 + Documentation/devicetree/bindings/i2c/i2c-rcar.txt | 1 + .../devicetree/bindings/i2c/i2c-sh_mobile.txt | 1 + .../devicetree/bindings/i2c/i2c-uniphier-f.txt | 25 + .../devicetree/bindings/i2c/i2c-uniphier.txt | 25 + .../devicetree/bindings/i2c/trivial-devices.txt | 3 +- .../devicetree/bindings/iio/accel/lis302.txt | 119 + .../devicetree/bindings/iio/accel/mma8452.txt | 24 + .../devicetree/bindings/iio/adc/hi8435.txt | 21 + .../devicetree/bindings/iio/dac/ti,dac7512.txt | 20 + .../devicetree/bindings/iio/light/apds9960.txt | 22 + .../devicetree/bindings/iio/light/us5182d.txt | 34 + .../devicetree/bindings/iio/pressure/bmp085.txt | 24 + .../devicetree/bindings/input/ads7846.txt | 3 +- .../devicetree/bindings/input/da9062-onkey.txt | 32 + .../devicetree/bindings/input/gpio-keys-polled.txt | 10 +- .../devicetree/bindings/input/gpio-keys.txt | 1 + .../bindings/input/gpio-matrix-keypad.txt | 1 + .../devicetree/bindings/input/hid-over-i2c.txt | 28 + .../bindings/input/nvidia,tegra20-kbc.txt | 3 +- .../bindings/input/qcom,pm8xxx-keypad.txt | 1 + .../devicetree/bindings/input/rotary-encoder.txt | 10 + .../devicetree/bindings/input/samsung-keypad.txt | 3 +- .../devicetree/bindings/input/sun4i-lradc-keys.txt | 2 +- .../bindings/input/touchscreen/edt-ft5x06.txt | 8 +- .../input/touchscreen/focaltech-ft6236.txt | 35 + .../bindings/input/touchscreen/goodix.txt | 14 + .../bindings/input/touchscreen/pixcir_i2c_ts.txt | 4 +- .../bindings/input/touchscreen/ts4800-ts.txt | 11 + .../bindings/input/touchscreen/tsc2005.txt | 34 +- .../bindings/interrupt-controller/arm,gic-v3.txt | 123 + .../bindings/interrupt-controller/arm,gic.txt | 168 + .../arm,versatile-fpga-irq.txt | 36 + .../bindings/interrupt-controller/arm,vic.txt | 41 + .../interrupt-controller/axis,crisv32-intc.txt | 23 + .../interrupt-controller/img,meta-intc.txt | 82 + .../bindings/interrupt-controller/img,pdc-intc.txt | 105 + .../interrupt-controller/intel,ce4100-ioapic.txt | 26 + .../interrupt-controller/mediatek,sysirq.txt | 32 + .../bindings/interrupt-controller/mrvl,intc.txt | 60 + .../interrupt-controller/nxp,lpc3220-mic.txt | 38 + .../bindings/interrupt-controller/open-pic.txt | 98 + .../bindings/interrupt-controller/renesas,irqc.txt | 1 + .../samsung,exynos4210-combiner.txt | 52 + .../interrupt-controller/snps,arc700-intc.txt | 24 + .../interrupt-controller/snps,archs-idu-intc.txt | 46 + .../interrupt-controller/snps,archs-intc.txt | 22 + .../interrupt-controller/st,spear3xx-shirq.txt | 48 + .../interrupt-controller/ti,c64x+megamod-pic.txt | 104 + .../bindings/interrupt-controller/ti,cp-intc.txt | 27 + .../interrupt-controller/ti,omap2-intc.txt | 27 + .../interrupt-controller/via,vt8500-intc.txt | 16 + .../devicetree/bindings/iommu/arm,smmu-v3.txt | 19 + .../devicetree/bindings/iommu/samsung,sysmmu.txt | 2 +- .../devicetree/bindings/iommu/ti,omap-iommu.txt | 27 + .../bindings/leds/backlight/88pm860x.txt | 15 + .../bindings/leds/backlight/gpio-backlight.txt | 16 + .../devicetree/bindings/leds/backlight/lp855x.txt | 70 + .../bindings/leds/backlight/max8925-backlight.txt | 10 + .../bindings/leds/backlight/pm8941-wled.txt | 42 + .../bindings/leds/backlight/pwm-backlight.txt | 35 + .../bindings/leds/backlight/sky81452-backlight.txt | 29 + .../bindings/leds/backlight/tps65217-backlight.txt | 27 + .../devicetree/bindings/leds/leds-aat1290.txt | 8 +- .../devicetree/bindings/leds/leds-bcm6328.txt | 10 + .../devicetree/bindings/leds/leds-netxbig.txt | 92 + .../devicetree/bindings/mailbox/omap-mailbox.txt | 8 + .../devicetree/bindings/mailbox/sti-mailbox.txt | 51 + .../bindings/media/exynos-jpeg-codec.txt | 3 +- .../bindings/memory-controllers/arm,pl172.txt | 8 +- .../memory-controllers/calxeda-ddr-ctrlr.txt | 16 + .../renesas-memory-controllers.txt | 6 +- .../devicetree/bindings/metag/meta-intc.txt | 82 - .../devicetree/bindings/metag/pdc-intc.txt | 105 - Documentation/devicetree/bindings/mfd/arizona.txt | 15 +- .../devicetree/bindings/mfd/atmel-flexcom.txt | 63 + .../devicetree/bindings/mfd/atmel-hlcdc.txt | 2 +- Documentation/devicetree/bindings/mfd/axp20x.txt | 4 +- Documentation/devicetree/bindings/mfd/cros-ec.txt | 4 + Documentation/devicetree/bindings/mfd/da9150.txt | 33 +- Documentation/devicetree/bindings/mfd/s2mps11.txt | 28 +- Documentation/devicetree/bindings/mfd/sky81452.txt | 2 +- Documentation/devicetree/bindings/mfd/tc3589x.txt | 1 + .../devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt | 98 - .../bindings/mipi/nvidia,tegra114-mipi.txt | 41 - .../devicetree/bindings/mips/img/xilfpga.txt | 83 + Documentation/devicetree/bindings/misc/at25.txt | 35 - Documentation/devicetree/bindings/misc/bmp085.txt | 24 - Documentation/devicetree/bindings/misc/lis302.txt | 119 - Documentation/devicetree/bindings/misc/sram.txt | 16 + .../devicetree/bindings/misc/ti,dac7512.txt | 20 - .../devicetree/bindings/mmc/fsl-esdhc.txt | 2 + Documentation/devicetree/bindings/mmc/mmc.txt | 6 +- Documentation/devicetree/bindings/mmc/mtk-sd.txt | 11 +- .../devicetree/bindings/mmc/renesas,mmcif.txt | 5 +- .../devicetree/bindings/mmc/rockchip-dw-mshc.txt | 13 + .../devicetree/bindings/mmc/synopsys-dw-mshc.txt | 25 + .../devicetree/bindings/mtd/fsmc-nand.txt | 6 + .../devicetree/bindings/mtd/partition.txt | 76 +- .../devicetree/bindings/mtd/vf610-nfc.txt | 59 + .../devicetree/bindings/net/apm-xgene-enet.txt | 10 + .../devicetree/bindings/net/brcm,iproc-mdio.txt | 23 + .../devicetree/bindings/net/can/sun4i_can.txt | 36 + Documentation/devicetree/bindings/net/cpsw.txt | 14 +- .../devicetree/bindings/net/fsl-tsec-phy.txt | 4 + .../bindings/net/hisilicon-hip04-net.txt | 4 +- .../devicetree/bindings/net/hisilicon-hns-dsaf.txt | 49 + .../devicetree/bindings/net/hisilicon-hns-mdio.txt | 22 + .../devicetree/bindings/net/hisilicon-hns-nic.txt | 47 + .../bindings/net/ieee802154/mrf24j40.txt | 20 + .../bindings/net/marvell-armada-370-neta.txt | 6 + .../devicetree/bindings/net/maxim,ds26522.txt | 13 + .../devicetree/bindings/net/nfc/nfcmrvl.txt | 61 +- .../devicetree/bindings/net/nfc/st-nci-i2c.txt | 7 + .../devicetree/bindings/net/nfc/st-nci-spi.txt | 9 +- .../devicetree/bindings/net/renesas,ravb.txt | 69 +- .../devicetree/bindings/nvec/nvidia,nvec.txt | 21 - .../devicetree/bindings/nvmem/imx-ocotp.txt | 20 + .../devicetree/bindings/nvmem/mxs-ocotp.txt | 25 + .../devicetree/bindings/nvmem/rockchip-efuse.txt | 38 + .../devicetree/bindings/nvmem/vf610-ocotp.txt | 19 + Documentation/devicetree/bindings/open-pic.txt | 98 - .../bindings/panel/ampire,am800480r3tmqwa1h.txt | 7 - .../devicetree/bindings/panel/auo,b080uan01.txt | 7 - .../devicetree/bindings/panel/auo,b101aw03.txt | 7 - .../devicetree/bindings/panel/auo,b101ean01.txt | 7 - .../devicetree/bindings/panel/auo,b101xtn01.txt | 7 - .../devicetree/bindings/panel/auo,b116xw03.txt | 7 - .../devicetree/bindings/panel/auo,b133htn01.txt | 7 - .../devicetree/bindings/panel/auo,b133xtn01.txt | 7 - .../devicetree/bindings/panel/avic,tm070ddh03.txt | 7 - .../bindings/panel/chunghwa,claa101wa01a.txt | 7 - .../bindings/panel/chunghwa,claa101wb03.txt | 7 - .../devicetree/bindings/panel/edt,et057090dhu.txt | 7 - .../devicetree/bindings/panel/edt,et070080dh6.txt | 10 - .../devicetree/bindings/panel/edt,etm0700g0dh6.txt | 10 - .../bindings/panel/foxlink,fl500wvr00-a0t.txt | 7 - .../bindings/panel/giantplus,gpg482739qs5.txt | 7 - .../bindings/panel/hannstar,hsd070pww1.txt | 7 - .../bindings/panel/hannstar,hsd100pxn1.txt | 7 - .../bindings/panel/hit,tx23d38vm0caa.txt | 7 - .../bindings/panel/innolux,at043tn24.txt | 7 - .../bindings/panel/innolux,g121i1-l01.txt | 7 - .../devicetree/bindings/panel/innolux,n116bge.txt | 7 - .../bindings/panel/innolux,n156bge-l21.txt | 7 - .../bindings/panel/innolux,zj070na-01p.txt | 7 - .../devicetree/bindings/panel/lg,lb070wv8.txt | 7 - .../devicetree/bindings/panel/lg,ld070wx3-sl01.txt | 7 - .../devicetree/bindings/panel/lg,lg4573.txt | 19 - .../devicetree/bindings/panel/lg,lh500wx1-sd03.txt | 7 - .../devicetree/bindings/panel/lg,lp129qe.txt | 7 - .../bindings/panel/nec,nl4827hc19-05b.txt | 7 - .../bindings/panel/okaya,rs800480t-7x0gp.txt | 7 - .../bindings/panel/ortustech,com43h4m85ulc.txt | 7 - .../bindings/panel/panasonic,vvx10f004b00.txt | 7 - .../devicetree/bindings/panel/samsung,ld9040.txt | 66 - .../bindings/panel/samsung,ltn101nt05.txt | 7 - .../bindings/panel/samsung,ltn140at29-301.txt | 7 - .../devicetree/bindings/panel/samsung,s6e8aa0.txt | 56 - .../bindings/panel/sharp,lq101r1sx01.txt | 49 - .../bindings/panel/shelly,sca07010-bfn-lnn.txt | 7 - .../devicetree/bindings/panel/simple-panel.txt | 21 - .../devicetree/bindings/pci/altera-pcie-msi.txt | 28 + .../devicetree/bindings/pci/altera-pcie.txt | 49 + .../devicetree/bindings/pci/arm,juno-r1-pcie.txt | 10 + .../devicetree/bindings/pci/brcm,iproc-pcie.txt | 20 + .../devicetree/bindings/pci/designware-pcie.txt | 12 +- .../devicetree/bindings/pci/hisilicon-pcie.txt | 44 + .../devicetree/bindings/pci/host-generic-pci.txt | 5 +- .../devicetree/bindings/pci/layerscape-pci.txt | 14 +- Documentation/devicetree/bindings/pci/pci-msi.txt | 220 + Documentation/devicetree/bindings/pci/pci.txt | 4 +- .../bindings/pci/plda,xpressrich3-axi.txt | 12 + .../bindings/phy/brcm,cygnus-pcie-phy.txt | 47 + .../devicetree/bindings/phy/calxeda-combophy.txt | 17 + .../devicetree/bindings/phy/keystone-usb-phy.txt | 20 + .../devicetree/bindings/phy/mxs-usb-phy.txt | 21 + .../bindings/phy/nvidia,tegra20-usb-phy.txt | 72 + .../devicetree/bindings/phy/phy-mt65xx-usb.txt | 68 + .../devicetree/bindings/phy/qcom,usb-8x16-phy.txt | 76 + .../devicetree/bindings/phy/samsung-phy.txt | 3 + .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 1 + .../bindings/pinctrl/atmel,at91-pio4-pinctrl.txt | 90 + .../devicetree/bindings/pinctrl/berlin,pinctrl.txt | 5 +- .../bindings/pinctrl/brcm,cygnus-gpio.txt | 16 +- .../bindings/pinctrl/fsl,imx7d-pinctrl.txt | 63 +- .../bindings/pinctrl/renesas,pfc-pinctrl.txt | 1 + .../devicetree/bindings/power/bq24257.txt | 53 +- .../devicetree/bindings/power/da9150-fg.txt | 23 + .../devicetree/bindings/power/pd-samsung.txt | 52 + .../devicetree/bindings/power/wakeup-source.txt | 71 + .../bindings/power_supply/axp20x_usb_power.txt | 34 + .../devicetree/bindings/power_supply/qcom_smbb.txt | 131 + .../bindings/power_supply/tps65217_charger.txt | 12 + .../devicetree/bindings/powerpc/fsl/board.txt | 102 - .../bindings/powerpc/fsl/mpc512x_lpbfifo.txt | 21 + .../devicetree/bindings/pwm/brcm,bcm7038-pwm.txt | 20 + .../devicetree/bindings/pwm/pwm-berlin.txt | 17 + .../devicetree/bindings/pwm/pwm-mtk-disp.txt | 42 + .../devicetree/bindings/pwm/pwm-sun4i.txt | 2 + .../devicetree/bindings/pwm/renesas,pwm-rcar.txt | 26 + .../bindings/regulator/act8865-regulator.txt | 3 + .../bindings/regulator/anatop-regulator.txt | 1 + .../bindings/regulator/arizona-regulator.txt | 17 + .../devicetree/bindings/regulator/max77802.txt | 25 +- .../devicetree/bindings/regulator/regulator.txt | 1 + .../devicetree/bindings/regulator/tps65023.txt | 60 + .../devicetree/bindings/rng/atmel-trng.txt | 16 + .../devicetree/bindings/rng/brcm,iproc-rng200.txt | 12 + Documentation/devicetree/bindings/rng/omap_rng.txt | 22 + .../bindings/rng/samsung,exynos-rng4.txt | 17 + Documentation/devicetree/bindings/rng/st,rng.txt | 15 + .../devicetree/bindings/rng/st,stm32-rng.txt | 21 + .../devicetree/bindings/rng/timeriomem_rng.txt | 18 + .../devicetree/bindings/rtc/dallas,ds1390.txt | 18 + .../devicetree/bindings/rtc/isil,isl12057.txt | 10 +- Documentation/devicetree/bindings/rtc/pcf8563.txt | 25 + Documentation/devicetree/bindings/rtc/rtc-opal.txt | 5 +- .../devicetree/bindings/serial/ingenic,uart.txt | 3 +- .../devicetree/bindings/serial/mrvl,pxa-ssp.txt | 1 - Documentation/devicetree/bindings/serial/pl011.txt | 2 +- .../devicetree/bindings/serial/qcom,msm-uartdm.txt | 6 + .../bindings/serial/renesas,sci-serial.txt | 2 + .../bindings/serial/snps-dw-apb-uart.txt | 3 + .../devicetree/bindings/soc/mediatek/scpsys.txt | 10 +- .../devicetree/bindings/soc/qcom/qcom,smem.txt | 57 + .../bindings/soc/rockchip/power_domain.txt | 46 + .../bindings/soc/ti/keystone-navigator-qmss.txt | 1 - Documentation/devicetree/bindings/sound/ak4554.c | 11 - Documentation/devicetree/bindings/sound/ak4554.txt | 11 + Documentation/devicetree/bindings/sound/ak4613.txt | 17 + Documentation/devicetree/bindings/sound/ak4642.txt | 22 +- .../devicetree/bindings/sound/atmel-classd.txt | 52 + Documentation/devicetree/bindings/sound/da7213.txt | 41 + Documentation/devicetree/bindings/sound/da7219.txt | 106 + .../devicetree/bindings/sound/fsl-asoc-card.txt | 10 +- .../devicetree/bindings/sound/nau8825.txt | 102 + .../devicetree/bindings/sound/renesas,rsnd.txt | 7 + .../devicetree/bindings/sound/rockchip-i2s.txt | 6 +- .../devicetree/bindings/sound/rockchip-spdif.txt | 40 + Documentation/devicetree/bindings/sound/rt5640.txt | 9 +- .../devicetree/bindings/sound/sun4i-codec.txt | 27 + .../devicetree/bindings/sound/tdm-slot.txt | 11 +- .../bindings/spi/brcm,bcm2835-aux-spi.txt | 38 + .../devicetree/bindings/spi/spi-mt65xx.txt | 9 +- .../bindings/thermal/rockchip-thermal.txt | 15 +- .../devicetree/bindings/thermal/ti_soc_thermal.txt | 14 + .../bindings/timer/mediatek,mtk-timer.txt | 8 +- Documentation/devicetree/bindings/ufs/ufs-qcom.txt | 58 + .../devicetree/bindings/ufs/ufshcd-pltfrm.txt | 11 +- .../devicetree/bindings/usb/ci-hdrc-usb2.txt | 27 +- Documentation/devicetree/bindings/usb/dwc3.txt | 6 +- .../devicetree/bindings/usb/keystone-phy.txt | 20 - Documentation/devicetree/bindings/usb/mxs-phy.txt | 21 - .../bindings/usb/nvidia,tegra20-usb-phy.txt | 72 - .../devicetree/bindings/usb/qcom,usb-8x16-phy.txt | 76 - .../devicetree/bindings/usb/samsung-usbphy.txt | 117 - .../devicetree/bindings/vendor-prefixes.txt | 10 + .../devicetree/bindings/video/adi,adv7123.txt | 50 - .../devicetree/bindings/video/adi,adv7511.txt | 88 - .../bindings/video/analog-tv-connector.txt | 25 - .../devicetree/bindings/video/arm,pl11x.txt | 109 - .../devicetree/bindings/video/atmel,lcdc.txt | 89 - .../bindings/video/backlight/88pm860x.txt | 15 - .../bindings/video/backlight/gpio-backlight.txt | 16 - .../devicetree/bindings/video/backlight/lp855x.txt | 70 - .../bindings/video/backlight/max8925-backlight.txt | 10 - .../bindings/video/backlight/pm8941-wled.txt | 40 - .../bindings/video/backlight/pwm-backlight.txt | 35 - .../video/backlight/sky81452-backlight.txt | 29 - .../video/backlight/tps65217-backlight.txt | 27 - .../devicetree/bindings/video/bridge/ps8622.txt | 31 - .../devicetree/bindings/video/bridge/ptn3460.txt | 39 - .../bindings/video/cirrus,clps711x-fb.txt | 47 - .../devicetree/bindings/video/display-timing.txt | 110 - .../devicetree/bindings/video/dvi-connector.txt | 35 - .../devicetree/bindings/video/dw_hdmi-rockchip.txt | 46 - .../devicetree/bindings/video/exynos-mic.txt | 51 - .../devicetree/bindings/video/exynos5433-decon.txt | 65 - .../devicetree/bindings/video/exynos7-decon.txt | 68 - .../devicetree/bindings/video/exynos_dp.txt | 120 - .../devicetree/bindings/video/exynos_dsim.txt | 103 - .../devicetree/bindings/video/exynos_hdmi.txt | 43 - .../devicetree/bindings/video/exynos_hdmiddc.txt | 15 - .../devicetree/bindings/video/exynos_hdmiphy.txt | 15 - .../devicetree/bindings/video/exynos_mixer.txt | 26 - .../devicetree/bindings/video/fsl,dcu.txt | 22 - .../devicetree/bindings/video/fsl,imx-fb.txt | 55 - .../devicetree/bindings/video/hdmi-connector.txt | 29 - .../bindings/video/lgphilips,lb035q02.txt | 33 - .../devicetree/bindings/video/panel-dpi.txt | 45 - .../devicetree/bindings/video/panel-dsi-cm.txt | 29 - .../devicetree/bindings/video/renesas,du.txt | 88 - .../devicetree/bindings/video/rockchip-drm.txt | 19 - .../devicetree/bindings/video/rockchip-vop.txt | 58 - .../devicetree/bindings/video/samsung-fimd.txt | 110 - .../bindings/video/sharp,ls037v7dw01.txt | 43 - .../bindings/video/simple-framebuffer-sunxi.txt | 33 - .../bindings/video/simple-framebuffer.txt | 86 - .../devicetree/bindings/video/sony,acx565akm.txt | 30 - .../devicetree/bindings/video/ssd1289fb.txt | 13 - .../devicetree/bindings/video/ssd1307fb.txt | 49 - .../devicetree/bindings/video/thine,thc63lvdm83d | 50 - .../devicetree/bindings/video/ti,dra7-dss.txt | 69 - .../devicetree/bindings/video/ti,omap-dss.txt | 211 - .../devicetree/bindings/video/ti,omap2-dss.txt | 54 - .../devicetree/bindings/video/ti,omap3-dss.txt | 83 - .../devicetree/bindings/video/ti,omap4-dss.txt | 115 - .../devicetree/bindings/video/ti,omap5-dss.txt | 96 - .../devicetree/bindings/video/ti,opa362.txt | 38 - .../devicetree/bindings/video/ti,tfp410.txt | 41 - .../devicetree/bindings/video/ti,tpd12s015.txt | 44 - .../bindings/video/toppoly,td028ttec1.txt | 30 - .../devicetree/bindings/video/tpo,td043mtea1.txt | 33 - .../devicetree/bindings/video/vga-connector.txt | 36 - .../devicetree/bindings/video/via,vt8500-fb.txt | 36 - .../devicetree/bindings/video/wm,prizm-ge-rops.txt | 13 - .../devicetree/bindings/video/wm,wm8505-fb.txt | 33 - Documentation/devicetree/bindings/w1/omap-hdq.txt | 7 +- .../bindings/watchdog/brcm,bcm7038-wdt.txt | 19 + .../devicetree/bindings/x86/interrupt.txt | 26 - Documentation/dontdiff | 1 - Documentation/driver-model/platform.txt | 14 + Documentation/edac.txt | 46 + Documentation/email-clients.txt | 38 +- .../features/debug/KASAN/arch-support.txt | 2 +- Documentation/features/vm/THP/arch-support.txt | 2 +- .../features/vm/pte_special/arch-support.txt | 2 +- Documentation/filesystems/Makefile | 2 - Documentation/filesystems/aufs/README | 9 +- Documentation/filesystems/configfs/Makefile | 3 - Documentation/filesystems/configfs/configfs.txt | 38 +- .../configfs/configfs_example_explicit.c | 483 --- .../filesystems/configfs/configfs_example_macros.c | 446 -- Documentation/filesystems/debugfs.txt | 2 +- Documentation/filesystems/f2fs.txt | 3 +- Documentation/filesystems/gfs2-glocks.txt | 6 +- Documentation/filesystems/nfs/nfsroot.txt | 3 + Documentation/filesystems/overlayfs.txt | 3 +- Documentation/filesystems/path-lookup.md | 1297 ++++++ Documentation/filesystems/path-lookup.txt | 2 +- Documentation/filesystems/proc.txt | 44 +- Documentation/filesystems/sysfs-tagging.txt | 14 +- Documentation/filesystems/sysfs.txt | 9 +- Documentation/fpga/fpga-mgr.txt | 171 + Documentation/gpio/board.txt | 10 +- Documentation/gpio/driver.txt | 80 + Documentation/gpio/sysfs.txt | 6 +- Documentation/hw_random.txt | 8 +- Documentation/hwmon/lm75 | 5 +- Documentation/hwmon/max31790 | 37 + Documentation/hwmon/scpi-hwmon | 33 + Documentation/i2c/busses/i2c-i801 | 3 + Documentation/input/rotary-encoder.txt | 9 +- Documentation/input/userio.txt | 70 + Documentation/ioctl/ioctl-number.txt | 4 + Documentation/kasan.txt | 46 +- Documentation/kbuild/Kconfig.recursion-issue-01 | 57 + Documentation/kbuild/Kconfig.recursion-issue-02 | 63 + Documentation/kbuild/Kconfig.select-break | 33 + Documentation/kbuild/kconfig-language.txt | 161 + Documentation/kernel-docs.txt | 14 +- Documentation/kernel-parameters.txt | 72 +- Documentation/kselftest.txt | 16 + Documentation/locking/lockstat.txt | 2 +- Documentation/locking/locktorture.txt | 3 + Documentation/lockup-watchdogs.txt | 5 +- Documentation/memory-barriers.txt | 65 +- Documentation/mic/mic_overview.txt | 31 +- Documentation/mic/mpssd/mpss | 4 +- Documentation/mic/mpssd/mpssd.c | 362 +- Documentation/mic/mpssd/mpssd.h | 1 + Documentation/misc-devices/apds990x.txt | 2 +- Documentation/misc-devices/isl29003 | 2 +- Documentation/misc-devices/max6875 | 2 +- Documentation/mmc/mmc-dev-attrs.txt | 10 - Documentation/networking/can.txt | 99 +- Documentation/networking/e100.txt | 14 - Documentation/networking/filter.txt | 6 +- Documentation/networking/ieee802154.txt | 8 +- Documentation/networking/ip-sysctl.txt | 25 +- Documentation/networking/ipvs-sysctl.txt | 10 + Documentation/networking/l2tp.txt | 7 +- Documentation/networking/switchdev.txt | 65 +- Documentation/networking/vrf.txt | 301 +- Documentation/nvdimm/nvdimm.txt | 49 +- Documentation/printk-formats.txt | 29 + Documentation/rbtree.txt | 2 +- Documentation/scsi/st.txt | 4 +- Documentation/security/Smack.txt | 10 + Documentation/security/keys.txt | 41 +- Documentation/serial/driver | 10 +- Documentation/serial/tty.txt | 60 +- Documentation/sound/alsa/hda_codec.txt | 322 -- Documentation/spi/pxa2xx | 6 - Documentation/sysctl/kernel.txt | 12 + Documentation/sysctl/vm.txt | 2 +- Documentation/target/tcm_mod_builder.py | 17 - Documentation/trace/events.txt | 18 + Documentation/trace/ftrace.txt | 23 + Documentation/trace/intel_th.txt | 99 + Documentation/trace/stm.txt | 80 + Documentation/usb/authorization.txt | 31 + Documentation/video4linux/CARDLIST.saa7134 | 1 + Documentation/video4linux/v4l2-pci-skeleton.c | 4 +- Documentation/virtual/kvm/api.txt | 56 +- Documentation/virtual/kvm/arm/vgic-mapped-irqs.txt | 187 + Documentation/virtual/kvm/devices/arm-vgic.txt | 18 +- Documentation/virtual/kvm/devices/vm.txt | 2 +- Documentation/virtual/kvm/locking.txt | 12 + Documentation/virtual/kvm/ppc-pv.txt | 2 +- Documentation/vm/balance | 14 +- Documentation/vm/page_migration | 27 +- Documentation/vm/slub.txt | 59 + Documentation/vm/split_page_table_lock | 4 +- Documentation/vm/transhuge.txt | 10 + Documentation/vm/unevictable-lru.txt | 120 +- Documentation/w1/masters/omap-hdq | 6 + Documentation/zh_CN/filesystems/sysfs.txt | 2 +- 740 files changed, 22704 insertions(+), 17195 deletions(-) create mode 100644 Documentation/ABI/obsolete/sysfs-driver-hid-roccat-arvo create mode 100644 Documentation/ABI/obsolete/sysfs-driver-hid-roccat-isku create mode 100644 Documentation/ABI/obsolete/sysfs-driver-hid-roccat-konepure create mode 100644 Documentation/ABI/obsolete/sysfs-driver-hid-roccat-lua create mode 100644 Documentation/ABI/obsolete/sysfs-driver-hid-roccat-ryos create mode 100644 Documentation/ABI/obsolete/sysfs-driver-hid-roccat-savu create mode 100644 Documentation/ABI/testing/configfs-stp-policy create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-humidity-hdc100x create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-meas-spec create mode 100644 Documentation/ABI/testing/sysfs-bus-intel_th-devices-gth create mode 100644 Documentation/ABI/testing/sysfs-bus-intel_th-devices-msc create mode 100644 Documentation/ABI/testing/sysfs-bus-intel_th-devices-pti create mode 100644 Documentation/ABI/testing/sysfs-bus-intel_th-output-devices create mode 100644 Documentation/ABI/testing/sysfs-class-fpga-manager create mode 100644 Documentation/ABI/testing/sysfs-class-stm create mode 100644 Documentation/ABI/testing/sysfs-class-stm_source create mode 100644 Documentation/ABI/testing/sysfs-driver-hid-corsair delete mode 100644 Documentation/ABI/testing/sysfs-driver-hid-roccat-arvo delete mode 100644 Documentation/ABI/testing/sysfs-driver-hid-roccat-isku delete mode 100644 Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus delete mode 100644 Documentation/ABI/testing/sysfs-driver-hid-roccat-konepure delete mode 100644 Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus delete mode 100644 Documentation/ABI/testing/sysfs-driver-hid-roccat-lua delete mode 100644 Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra delete mode 100644 Documentation/ABI/testing/sysfs-driver-hid-roccat-ryos delete mode 100644 Documentation/ABI/testing/sysfs-driver-hid-roccat-savu create mode 100644 Documentation/ABI/testing/sysfs-driver-st delete mode 100644 Documentation/DocBook/drm.tmpl create mode 100644 Documentation/DocBook/gpu.tmpl delete mode 100644 Documentation/DocBook/media/dvb/kdapi.xml create mode 100644 Documentation/acpi/i2c-muxes.txt delete mode 100644 Documentation/arm/SA1100/Victor create mode 100644 Documentation/arm/keystone/knav-qmss.txt create mode 100644 Documentation/block/pr.txt delete mode 100644 Documentation/devicetree/bindings/arc/archs-idu-intc.txt delete mode 100644 Documentation/devicetree/bindings/arc/archs-intc.txt delete mode 100644 Documentation/devicetree/bindings/arc/interrupts.txt create mode 100644 Documentation/devicetree/bindings/arm/apm/scu.txt create mode 100644 Documentation/devicetree/bindings/arm/arm,scpi.txt create mode 100644 Documentation/devicetree/bindings/arm/bcm/brcm,nsp.txt delete mode 100644 Documentation/devicetree/bindings/arm/calxeda/combophy.txt delete mode 100644 Documentation/devicetree/bindings/arm/calxeda/mem-ctrlr.txt delete mode 100644 Documentation/devicetree/bindings/arm/davinci/cp-intc.txt delete mode 100644 Documentation/devicetree/bindings/arm/exynos/power_domain.txt delete mode 100644 Documentation/devicetree/bindings/arm/gic-v3.txt delete mode 100644 Documentation/devicetree/bindings/arm/gic.txt delete mode 100644 Documentation/devicetree/bindings/arm/lpc32xx-mic.txt create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt delete mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,sysirq.txt create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt create mode 100644 Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt delete mode 100644 Documentation/devicetree/bindings/arm/mrvl/intc.txt create mode 100644 Documentation/devicetree/bindings/arm/mvebu-cpu-config.txt delete mode 100644 Documentation/devicetree/bindings/arm/omap/intc.txt delete mode 100644 Documentation/devicetree/bindings/arm/samsung-boards.txt delete mode 100644 Documentation/devicetree/bindings/arm/samsung/interrupt-combiner.txt create mode 100644 Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt delete mode 100644 Documentation/devicetree/bindings/arm/spear/shirq.txt create mode 100644 Documentation/devicetree/bindings/arm/tegra/nvidia,nvec.txt create mode 100644 Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt delete mode 100644 Documentation/devicetree/bindings/arm/versatile-fpga-irq.txt delete mode 100644 Documentation/devicetree/bindings/arm/vic.txt delete mode 100644 Documentation/devicetree/bindings/arm/vt8500/via,vt8500-intc.txt create mode 100644 Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt create mode 100644 Documentation/devicetree/bindings/board/fsl-board.txt create mode 100644 Documentation/devicetree/bindings/bus/sunxi-rsb.txt delete mode 100644 Documentation/devicetree/bindings/c6x/interrupt.txt create mode 100644 Documentation/devicetree/bindings/clock/brcm,bcm2835-cprman.txt create mode 100644 Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt create mode 100644 Documentation/devicetree/bindings/clock/silabs,si514.txt delete mode 100644 Documentation/devicetree/bindings/cris/interrupts.txt create mode 100644 Documentation/devicetree/bindings/display/arm,pl11x.txt create mode 100644 Documentation/devicetree/bindings/display/armada/marvell,dove-lcd.txt create mode 100644 Documentation/devicetree/bindings/display/atmel,lcdc.txt create mode 100644 Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt create mode 100644 Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt create mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7123.txt create mode 100644 Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt create mode 100644 Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt create mode 100644 Documentation/devicetree/bindings/display/bridge/ps8622.txt create mode 100644 Documentation/devicetree/bindings/display/bridge/ptn3460.txt create mode 100644 Documentation/devicetree/bindings/display/bridge/tda998x.txt create mode 100644 Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt create mode 100644 Documentation/devicetree/bindings/display/cirrus,clps711x-fb.txt create mode 100644 Documentation/devicetree/bindings/display/connector/analog-tv-connector.txt create mode 100644 Documentation/devicetree/bindings/display/connector/dvi-connector.txt create mode 100644 Documentation/devicetree/bindings/display/connector/hdmi-connector.txt create mode 100644 Documentation/devicetree/bindings/display/connector/vga-connector.txt create mode 100644 Documentation/devicetree/bindings/display/exynos/exynos-mic.txt create mode 100644 Documentation/devicetree/bindings/display/exynos/exynos5433-decon.txt create mode 100644 Documentation/devicetree/bindings/display/exynos/exynos7-decon.txt create mode 100644 Documentation/devicetree/bindings/display/exynos/exynos_dp.txt create mode 100644 Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt create mode 100644 Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt create mode 100644 Documentation/devicetree/bindings/display/exynos/exynos_hdmiddc.txt create mode 100644 Documentation/devicetree/bindings/display/exynos/exynos_hdmiphy.txt create mode 100644 Documentation/devicetree/bindings/display/exynos/exynos_mixer.txt create mode 100644 Documentation/devicetree/bindings/display/exynos/samsung-fimd.txt create mode 100644 Documentation/devicetree/bindings/display/fsl,dcu.txt create mode 100644 Documentation/devicetree/bindings/display/imx/fsl,imx-fb.txt create mode 100644 Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt create mode 100644 Documentation/devicetree/bindings/display/imx/hdmi.txt create mode 100644 Documentation/devicetree/bindings/display/imx/ldb.txt create mode 100644 Documentation/devicetree/bindings/display/marvell,pxa2xx-lcdc.txt create mode 100644 Documentation/devicetree/bindings/display/mipi-dsi-bus.txt create mode 100644 Documentation/devicetree/bindings/display/msm/dsi.txt create mode 100644 Documentation/devicetree/bindings/display/msm/edp.txt create mode 100644 Documentation/devicetree/bindings/display/msm/gpu.txt create mode 100644 Documentation/devicetree/bindings/display/msm/hdmi.txt create mode 100644 Documentation/devicetree/bindings/display/msm/mdp.txt create mode 100644 Documentation/devicetree/bindings/display/mxsfb.txt create mode 100644 Documentation/devicetree/bindings/display/panel/ampire,am800480r3tmqwa1h.txt create mode 100644 Documentation/devicetree/bindings/display/panel/auo,b080uan01.txt create mode 100644 Documentation/devicetree/bindings/display/panel/auo,b101aw03.txt create mode 100644 Documentation/devicetree/bindings/display/panel/auo,b101ean01.txt create mode 100644 Documentation/devicetree/bindings/display/panel/auo,b101xtn01.txt create mode 100644 Documentation/devicetree/bindings/display/panel/auo,b116xw03.txt create mode 100644 Documentation/devicetree/bindings/display/panel/auo,b133htn01.txt create mode 100644 Documentation/devicetree/bindings/display/panel/auo,b133xtn01.txt create mode 100644 Documentation/devicetree/bindings/display/panel/avic,tm070ddh03.txt create mode 100644 Documentation/devicetree/bindings/display/panel/chunghwa,claa101wa01a.txt create mode 100644 Documentation/devicetree/bindings/display/panel/chunghwa,claa101wb03.txt create mode 100644 Documentation/devicetree/bindings/display/panel/display-timing.txt create mode 100644 Documentation/devicetree/bindings/display/panel/edt,et057090dhu.txt create mode 100644 Documentation/devicetree/bindings/display/panel/edt,et070080dh6.txt create mode 100644 Documentation/devicetree/bindings/display/panel/edt,etm0700g0dh6.txt create mode 100644 Documentation/devicetree/bindings/display/panel/foxlink,fl500wvr00-a0t.txt create mode 100644 Documentation/devicetree/bindings/display/panel/giantplus,gpg482739qs5.txt create mode 100644 Documentation/devicetree/bindings/display/panel/hannstar,hsd070pww1.txt create mode 100644 Documentation/devicetree/bindings/display/panel/hannstar,hsd100pxn1.txt create mode 100644 Documentation/devicetree/bindings/display/panel/hit,tx23d38vm0caa.txt create mode 100644 Documentation/devicetree/bindings/display/panel/innolux,at043tn24.txt create mode 100644 Documentation/devicetree/bindings/display/panel/innolux,g121i1-l01.txt create mode 100644 Documentation/devicetree/bindings/display/panel/innolux,n116bge.txt create mode 100644 Documentation/devicetree/bindings/display/panel/innolux,n156bge-l21.txt create mode 100644 Documentation/devicetree/bindings/display/panel/innolux,zj070na-01p.txt create mode 100644 Documentation/devicetree/bindings/display/panel/lg,lb070wv8.txt create mode 100644 Documentation/devicetree/bindings/display/panel/lg,ld070wx3-sl01.txt create mode 100644 Documentation/devicetree/bindings/display/panel/lg,lg4573.txt create mode 100644 Documentation/devicetree/bindings/display/panel/lg,lh500wx1-sd03.txt create mode 100644 Documentation/devicetree/bindings/display/panel/lg,lp129qe.txt create mode 100644 Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.txt create mode 100644 Documentation/devicetree/bindings/display/panel/nec,nl4827hc19-05b.txt create mode 100644 Documentation/devicetree/bindings/display/panel/okaya,rs800480t-7x0gp.txt create mode 100644 Documentation/devicetree/bindings/display/panel/ortustech,com43h4m85ulc.txt create mode 100644 Documentation/devicetree/bindings/display/panel/panasonic,vvx10f004b00.txt create mode 100644 Documentation/devicetree/bindings/display/panel/panel-dpi.txt create mode 100644 Documentation/devicetree/bindings/display/panel/panel-dsi-cm.txt create mode 100644 Documentation/devicetree/bindings/display/panel/samsung,ld9040.txt create mode 100644 Documentation/devicetree/bindings/display/panel/samsung,ltn101nt05.txt create mode 100644 Documentation/devicetree/bindings/display/panel/samsung,ltn140at29-301.txt create mode 100644 Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.txt create mode 100644 Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.txt create mode 100644 Documentation/devicetree/bindings/display/panel/sharp,ls037v7dw01.txt create mode 100644 Documentation/devicetree/bindings/display/panel/shelly,sca07010-bfn-lnn.txt create mode 100644 Documentation/devicetree/bindings/display/panel/simple-panel.txt create mode 100644 Documentation/devicetree/bindings/display/panel/sony,acx565akm.txt create mode 100644 Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt create mode 100644 Documentation/devicetree/bindings/display/panel/tpo,td043mtea1.txt create mode 100644 Documentation/devicetree/bindings/display/renesas,du.txt create mode 100644 Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt create mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip-drm.txt create mode 100644 Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt create mode 100644 Documentation/devicetree/bindings/display/simple-framebuffer-sunxi.txt create mode 100644 Documentation/devicetree/bindings/display/simple-framebuffer.txt create mode 100644 Documentation/devicetree/bindings/display/sm501fb.txt create mode 100644 Documentation/devicetree/bindings/display/ssd1289fb.txt create mode 100644 Documentation/devicetree/bindings/display/ssd1307fb.txt create mode 100644 Documentation/devicetree/bindings/display/st,stih4xx.txt create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.txt create mode 100644 Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt create mode 100644 Documentation/devicetree/bindings/display/ti/ti,dra7-dss.txt create mode 100644 Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt create mode 100644 Documentation/devicetree/bindings/display/ti/ti,omap2-dss.txt create mode 100644 Documentation/devicetree/bindings/display/ti/ti,omap3-dss.txt create mode 100644 Documentation/devicetree/bindings/display/ti/ti,omap4-dss.txt create mode 100644 Documentation/devicetree/bindings/display/ti/ti,omap5-dss.txt create mode 100644 Documentation/devicetree/bindings/display/ti/ti,opa362.txt create mode 100644 Documentation/devicetree/bindings/display/ti/ti,tfp410.txt create mode 100644 Documentation/devicetree/bindings/display/ti/ti,tpd12s015.txt create mode 100644 Documentation/devicetree/bindings/display/tilcdc/panel.txt create mode 100644 Documentation/devicetree/bindings/display/tilcdc/tfp410.txt create mode 100644 Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt create mode 100644 Documentation/devicetree/bindings/display/via,vt8500-fb.txt create mode 100644 Documentation/devicetree/bindings/display/wm,prizm-ge-rops.txt create mode 100644 Documentation/devicetree/bindings/display/wm,wm8505-fb.txt delete mode 100644 Documentation/devicetree/bindings/drm/armada/marvell,dove-lcd.txt delete mode 100644 Documentation/devicetree/bindings/drm/atmel/hlcdc-dc.txt delete mode 100644 Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt delete mode 100644 Documentation/devicetree/bindings/drm/i2c/tda998x.txt delete mode 100644 Documentation/devicetree/bindings/drm/imx/fsl-imx-drm.txt delete mode 100644 Documentation/devicetree/bindings/drm/imx/hdmi.txt delete mode 100644 Documentation/devicetree/bindings/drm/imx/ldb.txt delete mode 100644 Documentation/devicetree/bindings/drm/msm/dsi.txt delete mode 100644 Documentation/devicetree/bindings/drm/msm/edp.txt delete mode 100644 Documentation/devicetree/bindings/drm/msm/gpu.txt delete mode 100644 Documentation/devicetree/bindings/drm/msm/hdmi.txt delete mode 100644 Documentation/devicetree/bindings/drm/msm/mdp.txt delete mode 100644 Documentation/devicetree/bindings/drm/tilcdc/panel.txt delete mode 100644 Documentation/devicetree/bindings/drm/tilcdc/tfp410.txt delete mode 100644 Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt delete mode 100644 Documentation/devicetree/bindings/eeprom.txt create mode 100644 Documentation/devicetree/bindings/eeprom/at25.txt create mode 100644 Documentation/devicetree/bindings/eeprom/eeprom.txt create mode 100644 Documentation/devicetree/bindings/extcon/extcon-arizona.txt delete mode 100644 Documentation/devicetree/bindings/fb/mxsfb.txt delete mode 100644 Documentation/devicetree/bindings/fb/sm501fb.txt create mode 100644 Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.txt delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-msm.txt create mode 100644 Documentation/devicetree/bindings/gpio/netxbig-gpio-ext.txt delete mode 100644 Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt delete mode 100644 Documentation/devicetree/bindings/gpu/st,stih4xx.txt delete mode 100644 Documentation/devicetree/bindings/hid/hid-over-i2c.txt delete mode 100644 Documentation/devicetree/bindings/hwmon/ina209.txt delete mode 100644 Documentation/devicetree/bindings/hwrng/atmel-trng.txt delete mode 100644 Documentation/devicetree/bindings/hwrng/brcm,iproc-rng200.txt delete mode 100644 Documentation/devicetree/bindings/hwrng/omap_rng.txt delete mode 100644 Documentation/devicetree/bindings/hwrng/timeriomem_rng.txt create mode 100644 Documentation/devicetree/bindings/i2c/i2c-uniphier-f.txt create mode 100644 Documentation/devicetree/bindings/i2c/i2c-uniphier.txt create mode 100644 Documentation/devicetree/bindings/iio/accel/lis302.txt create mode 100644 Documentation/devicetree/bindings/iio/accel/mma8452.txt create mode 100644 Documentation/devicetree/bindings/iio/adc/hi8435.txt create mode 100644 Documentation/devicetree/bindings/iio/dac/ti,dac7512.txt create mode 100644 Documentation/devicetree/bindings/iio/light/apds9960.txt create mode 100644 Documentation/devicetree/bindings/iio/light/us5182d.txt create mode 100644 Documentation/devicetree/bindings/iio/pressure/bmp085.txt create mode 100644 Documentation/devicetree/bindings/input/da9062-onkey.txt create mode 100644 Documentation/devicetree/bindings/input/hid-over-i2c.txt create mode 100644 Documentation/devicetree/bindings/input/touchscreen/focaltech-ft6236.txt create mode 100644 Documentation/devicetree/bindings/input/touchscreen/ts4800-ts.txt create mode 100644 Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt create mode 100644 Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt create mode 100644 Documentation/devicetree/bindings/interrupt-controller/arm,versatile-fpga-irq.txt create mode 100644 Documentation/devicetree/bindings/interrupt-controller/arm,vic.txt create mode 100644 Documentation/devicetree/bindings/interrupt-controller/axis,crisv32-intc.txt create mode 100644 Documentation/devicetree/bindings/interrupt-controller/img,meta-intc.txt create mode 100644 Documentation/devicetree/bindings/interrupt-controller/img,pdc-intc.txt create mode 100644 Documentation/devicetree/bindings/interrupt-controller/intel,ce4100-ioapic.txt create mode 100644 Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt create mode 100644 Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.txt create mode 100644 Documentation/devicetree/bindings/interrupt-controller/nxp,lpc3220-mic.txt create mode 100644 Documentation/devicetree/bindings/interrupt-controller/open-pic.txt create mode 100644 Documentation/devicetree/bindings/interrupt-controller/samsung,exynos4210-combiner.txt create mode 100644 Documentation/devicetree/bindings/interrupt-controller/snps,arc700-intc.txt create mode 100644 Documentation/devicetree/bindings/interrupt-controller/snps,archs-idu-intc.txt create mode 100644 Documentation/devicetree/bindings/interrupt-controller/snps,archs-intc.txt create mode 100644 Documentation/devicetree/bindings/interrupt-controller/st,spear3xx-shirq.txt create mode 100644 Documentation/devicetree/bindings/interrupt-controller/ti,c64x+megamod-pic.txt create mode 100644 Documentation/devicetree/bindings/interrupt-controller/ti,cp-intc.txt create mode 100644 Documentation/devicetree/bindings/interrupt-controller/ti,omap2-intc.txt create mode 100644 Documentation/devicetree/bindings/interrupt-controller/via,vt8500-intc.txt create mode 100644 Documentation/devicetree/bindings/leds/backlight/88pm860x.txt create mode 100644 Documentation/devicetree/bindings/leds/backlight/gpio-backlight.txt create mode 100644 Documentation/devicetree/bindings/leds/backlight/lp855x.txt create mode 100644 Documentation/devicetree/bindings/leds/backlight/max8925-backlight.txt create mode 100644 Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt create mode 100644 Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt create mode 100644 Documentation/devicetree/bindings/leds/backlight/sky81452-backlight.txt create mode 100644 Documentation/devicetree/bindings/leds/backlight/tps65217-backlight.txt create mode 100644 Documentation/devicetree/bindings/leds/leds-netxbig.txt create mode 100644 Documentation/devicetree/bindings/mailbox/sti-mailbox.txt create mode 100644 Documentation/devicetree/bindings/memory-controllers/calxeda-ddr-ctrlr.txt delete mode 100644 Documentation/devicetree/bindings/metag/meta-intc.txt delete mode 100644 Documentation/devicetree/bindings/metag/pdc-intc.txt create mode 100644 Documentation/devicetree/bindings/mfd/atmel-flexcom.txt delete mode 100644 Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt delete mode 100644 Documentation/devicetree/bindings/mipi/nvidia,tegra114-mipi.txt create mode 100644 Documentation/devicetree/bindings/mips/img/xilfpga.txt delete mode 100644 Documentation/devicetree/bindings/misc/at25.txt delete mode 100644 Documentation/devicetree/bindings/misc/bmp085.txt delete mode 100644 Documentation/devicetree/bindings/misc/lis302.txt delete mode 100644 Documentation/devicetree/bindings/misc/ti,dac7512.txt create mode 100644 Documentation/devicetree/bindings/mtd/vf610-nfc.txt create mode 100644 Documentation/devicetree/bindings/net/brcm,iproc-mdio.txt create mode 100644 Documentation/devicetree/bindings/net/can/sun4i_can.txt create mode 100644 Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt create mode 100644 Documentation/devicetree/bindings/net/hisilicon-hns-mdio.txt create mode 100644 Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt create mode 100644 Documentation/devicetree/bindings/net/ieee802154/mrf24j40.txt create mode 100644 Documentation/devicetree/bindings/net/maxim,ds26522.txt delete mode 100644 Documentation/devicetree/bindings/nvec/nvidia,nvec.txt create mode 100644 Documentation/devicetree/bindings/nvmem/imx-ocotp.txt create mode 100644 Documentation/devicetree/bindings/nvmem/mxs-ocotp.txt create mode 100644 Documentation/devicetree/bindings/nvmem/rockchip-efuse.txt create mode 100644 Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt delete mode 100644 Documentation/devicetree/bindings/open-pic.txt delete mode 100644 Documentation/devicetree/bindings/panel/ampire,am800480r3tmqwa1h.txt delete mode 100644 Documentation/devicetree/bindings/panel/auo,b080uan01.txt delete mode 100644 Documentation/devicetree/bindings/panel/auo,b101aw03.txt delete mode 100644 Documentation/devicetree/bindings/panel/auo,b101ean01.txt delete mode 100644 Documentation/devicetree/bindings/panel/auo,b101xtn01.txt delete mode 100644 Documentation/devicetree/bindings/panel/auo,b116xw03.txt delete mode 100644 Documentation/devicetree/bindings/panel/auo,b133htn01.txt delete mode 100644 Documentation/devicetree/bindings/panel/auo,b133xtn01.txt delete mode 100644 Documentation/devicetree/bindings/panel/avic,tm070ddh03.txt delete mode 100644 Documentation/devicetree/bindings/panel/chunghwa,claa101wa01a.txt delete mode 100644 Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt delete mode 100644 Documentation/devicetree/bindings/panel/edt,et057090dhu.txt delete mode 100644 Documentation/devicetree/bindings/panel/edt,et070080dh6.txt delete mode 100644 Documentation/devicetree/bindings/panel/edt,etm0700g0dh6.txt delete mode 100644 Documentation/devicetree/bindings/panel/foxlink,fl500wvr00-a0t.txt delete mode 100644 Documentation/devicetree/bindings/panel/giantplus,gpg482739qs5.txt delete mode 100644 Documentation/devicetree/bindings/panel/hannstar,hsd070pww1.txt delete mode 100644 Documentation/devicetree/bindings/panel/hannstar,hsd100pxn1.txt delete mode 100644 Documentation/devicetree/bindings/panel/hit,tx23d38vm0caa.txt delete mode 100644 Documentation/devicetree/bindings/panel/innolux,at043tn24.txt delete mode 100644 Documentation/devicetree/bindings/panel/innolux,g121i1-l01.txt delete mode 100644 Documentation/devicetree/bindings/panel/innolux,n116bge.txt delete mode 100644 Documentation/devicetree/bindings/panel/innolux,n156bge-l21.txt delete mode 100644 Documentation/devicetree/bindings/panel/innolux,zj070na-01p.txt delete mode 100644 Documentation/devicetree/bindings/panel/lg,lb070wv8.txt delete mode 100644 Documentation/devicetree/bindings/panel/lg,ld070wx3-sl01.txt delete mode 100644 Documentation/devicetree/bindings/panel/lg,lg4573.txt delete mode 100644 Documentation/devicetree/bindings/panel/lg,lh500wx1-sd03.txt delete mode 100644 Documentation/devicetree/bindings/panel/lg,lp129qe.txt delete mode 100644 Documentation/devicetree/bindings/panel/nec,nl4827hc19-05b.txt delete mode 100644 Documentation/devicetree/bindings/panel/okaya,rs800480t-7x0gp.txt delete mode 100644 Documentation/devicetree/bindings/panel/ortustech,com43h4m85ulc.txt delete mode 100644 Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt delete mode 100644 Documentation/devicetree/bindings/panel/samsung,ld9040.txt delete mode 100644 Documentation/devicetree/bindings/panel/samsung,ltn101nt05.txt delete mode 100644 Documentation/devicetree/bindings/panel/samsung,ltn140at29-301.txt delete mode 100644 Documentation/devicetree/bindings/panel/samsung,s6e8aa0.txt delete mode 100644 Documentation/devicetree/bindings/panel/sharp,lq101r1sx01.txt delete mode 100644 Documentation/devicetree/bindings/panel/shelly,sca07010-bfn-lnn.txt delete mode 100644 Documentation/devicetree/bindings/panel/simple-panel.txt create mode 100644 Documentation/devicetree/bindings/pci/altera-pcie-msi.txt create mode 100644 Documentation/devicetree/bindings/pci/altera-pcie.txt create mode 100644 Documentation/devicetree/bindings/pci/arm,juno-r1-pcie.txt create mode 100644 Documentation/devicetree/bindings/pci/hisilicon-pcie.txt create mode 100644 Documentation/devicetree/bindings/pci/pci-msi.txt create mode 100644 Documentation/devicetree/bindings/pci/plda,xpressrich3-axi.txt create mode 100644 Documentation/devicetree/bindings/phy/brcm,cygnus-pcie-phy.txt create mode 100644 Documentation/devicetree/bindings/phy/calxeda-combophy.txt create mode 100644 Documentation/devicetree/bindings/phy/keystone-usb-phy.txt create mode 100644 Documentation/devicetree/bindings/phy/mxs-usb-phy.txt create mode 100644 Documentation/devicetree/bindings/phy/nvidia,tegra20-usb-phy.txt create mode 100644 Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt create mode 100644 Documentation/devicetree/bindings/phy/qcom,usb-8x16-phy.txt create mode 100644 Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt create mode 100644 Documentation/devicetree/bindings/power/da9150-fg.txt create mode 100644 Documentation/devicetree/bindings/power/pd-samsung.txt create mode 100644 Documentation/devicetree/bindings/power/wakeup-source.txt create mode 100644 Documentation/devicetree/bindings/power_supply/axp20x_usb_power.txt create mode 100644 Documentation/devicetree/bindings/power_supply/qcom_smbb.txt create mode 100644 Documentation/devicetree/bindings/power_supply/tps65217_charger.txt delete mode 100644 Documentation/devicetree/bindings/powerpc/fsl/board.txt create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/mpc512x_lpbfifo.txt create mode 100644 Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.txt create mode 100644 Documentation/devicetree/bindings/pwm/pwm-berlin.txt create mode 100644 Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt create mode 100644 Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt create mode 100644 Documentation/devicetree/bindings/regulator/arizona-regulator.txt create mode 100644 Documentation/devicetree/bindings/regulator/tps65023.txt create mode 100644 Documentation/devicetree/bindings/rng/atmel-trng.txt create mode 100644 Documentation/devicetree/bindings/rng/brcm,iproc-rng200.txt create mode 100644 Documentation/devicetree/bindings/rng/omap_rng.txt create mode 100644 Documentation/devicetree/bindings/rng/samsung,exynos-rng4.txt create mode 100644 Documentation/devicetree/bindings/rng/st,rng.txt create mode 100644 Documentation/devicetree/bindings/rng/st,stm32-rng.txt create mode 100644 Documentation/devicetree/bindings/rng/timeriomem_rng.txt create mode 100644 Documentation/devicetree/bindings/rtc/dallas,ds1390.txt create mode 100644 Documentation/devicetree/bindings/rtc/pcf8563.txt create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smem.txt create mode 100644 Documentation/devicetree/bindings/soc/rockchip/power_domain.txt delete mode 100644 Documentation/devicetree/bindings/sound/ak4554.c create mode 100644 Documentation/devicetree/bindings/sound/ak4554.txt create mode 100644 Documentation/devicetree/bindings/sound/ak4613.txt create mode 100644 Documentation/devicetree/bindings/sound/atmel-classd.txt create mode 100644 Documentation/devicetree/bindings/sound/da7213.txt create mode 100644 Documentation/devicetree/bindings/sound/da7219.txt create mode 100644 Documentation/devicetree/bindings/sound/nau8825.txt create mode 100644 Documentation/devicetree/bindings/sound/rockchip-spdif.txt create mode 100644 Documentation/devicetree/bindings/sound/sun4i-codec.txt create mode 100644 Documentation/devicetree/bindings/spi/brcm,bcm2835-aux-spi.txt create mode 100644 Documentation/devicetree/bindings/ufs/ufs-qcom.txt delete mode 100644 Documentation/devicetree/bindings/usb/keystone-phy.txt delete mode 100644 Documentation/devicetree/bindings/usb/mxs-phy.txt delete mode 100644 Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt delete mode 100644 Documentation/devicetree/bindings/usb/qcom,usb-8x16-phy.txt delete mode 100644 Documentation/devicetree/bindings/usb/samsung-usbphy.txt delete mode 100644 Documentation/devicetree/bindings/video/adi,adv7123.txt delete mode 100644 Documentation/devicetree/bindings/video/adi,adv7511.txt delete mode 100644 Documentation/devicetree/bindings/video/analog-tv-connector.txt delete mode 100644 Documentation/devicetree/bindings/video/arm,pl11x.txt delete mode 100644 Documentation/devicetree/bindings/video/atmel,lcdc.txt delete mode 100644 Documentation/devicetree/bindings/video/backlight/88pm860x.txt delete mode 100644 Documentation/devicetree/bindings/video/backlight/gpio-backlight.txt delete mode 100644 Documentation/devicetree/bindings/video/backlight/lp855x.txt delete mode 100644 Documentation/devicetree/bindings/video/backlight/max8925-backlight.txt delete mode 100644 Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt delete mode 100644 Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt delete mode 100644 Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt delete mode 100644 Documentation/devicetree/bindings/video/backlight/tps65217-backlight.txt delete mode 100644 Documentation/devicetree/bindings/video/bridge/ps8622.txt delete mode 100644 Documentation/devicetree/bindings/video/bridge/ptn3460.txt delete mode 100644 Documentation/devicetree/bindings/video/cirrus,clps711x-fb.txt delete mode 100644 Documentation/devicetree/bindings/video/display-timing.txt delete mode 100644 Documentation/devicetree/bindings/video/dvi-connector.txt delete mode 100644 Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt delete mode 100644 Documentation/devicetree/bindings/video/exynos-mic.txt delete mode 100644 Documentation/devicetree/bindings/video/exynos5433-decon.txt delete mode 100644 Documentation/devicetree/bindings/video/exynos7-decon.txt delete mode 100644 Documentation/devicetree/bindings/video/exynos_dp.txt delete mode 100644 Documentation/devicetree/bindings/video/exynos_dsim.txt delete mode 100644 Documentation/devicetree/bindings/video/exynos_hdmi.txt delete mode 100644 Documentation/devicetree/bindings/video/exynos_hdmiddc.txt delete mode 100644 Documentation/devicetree/bindings/video/exynos_hdmiphy.txt delete mode 100644 Documentation/devicetree/bindings/video/exynos_mixer.txt delete mode 100644 Documentation/devicetree/bindings/video/fsl,dcu.txt delete mode 100644 Documentation/devicetree/bindings/video/fsl,imx-fb.txt delete mode 100644 Documentation/devicetree/bindings/video/hdmi-connector.txt delete mode 100644 Documentation/devicetree/bindings/video/lgphilips,lb035q02.txt delete mode 100644 Documentation/devicetree/bindings/video/panel-dpi.txt delete mode 100644 Documentation/devicetree/bindings/video/panel-dsi-cm.txt delete mode 100644 Documentation/devicetree/bindings/video/renesas,du.txt delete mode 100644 Documentation/devicetree/bindings/video/rockchip-drm.txt delete mode 100644 Documentation/devicetree/bindings/video/rockchip-vop.txt delete mode 100644 Documentation/devicetree/bindings/video/samsung-fimd.txt delete mode 100644 Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt delete mode 100644 Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt delete mode 100644 Documentation/devicetree/bindings/video/simple-framebuffer.txt delete mode 100644 Documentation/devicetree/bindings/video/sony,acx565akm.txt delete mode 100644 Documentation/devicetree/bindings/video/ssd1289fb.txt delete mode 100644 Documentation/devicetree/bindings/video/ssd1307fb.txt delete mode 100644 Documentation/devicetree/bindings/video/thine,thc63lvdm83d delete mode 100644 Documentation/devicetree/bindings/video/ti,dra7-dss.txt delete mode 100644 Documentation/devicetree/bindings/video/ti,omap-dss.txt delete mode 100644 Documentation/devicetree/bindings/video/ti,omap2-dss.txt delete mode 100644 Documentation/devicetree/bindings/video/ti,omap3-dss.txt delete mode 100644 Documentation/devicetree/bindings/video/ti,omap4-dss.txt delete mode 100644 Documentation/devicetree/bindings/video/ti,omap5-dss.txt delete mode 100644 Documentation/devicetree/bindings/video/ti,opa362.txt delete mode 100644 Documentation/devicetree/bindings/video/ti,tfp410.txt delete mode 100644 Documentation/devicetree/bindings/video/ti,tpd12s015.txt delete mode 100644 Documentation/devicetree/bindings/video/toppoly,td028ttec1.txt delete mode 100644 Documentation/devicetree/bindings/video/tpo,td043mtea1.txt delete mode 100644 Documentation/devicetree/bindings/video/vga-connector.txt delete mode 100644 Documentation/devicetree/bindings/video/via,vt8500-fb.txt delete mode 100644 Documentation/devicetree/bindings/video/wm,prizm-ge-rops.txt delete mode 100644 Documentation/devicetree/bindings/video/wm,wm8505-fb.txt create mode 100644 Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt delete mode 100644 Documentation/devicetree/bindings/x86/interrupt.txt delete mode 100644 Documentation/filesystems/configfs/Makefile delete mode 100644 Documentation/filesystems/configfs/configfs_example_explicit.c delete mode 100644 Documentation/filesystems/configfs/configfs_example_macros.c create mode 100644 Documentation/filesystems/path-lookup.md create mode 100644 Documentation/fpga/fpga-mgr.txt create mode 100644 Documentation/hwmon/max31790 create mode 100644 Documentation/hwmon/scpi-hwmon create mode 100644 Documentation/input/userio.txt create mode 100644 Documentation/kbuild/Kconfig.recursion-issue-01 create mode 100644 Documentation/kbuild/Kconfig.recursion-issue-02 create mode 100644 Documentation/kbuild/Kconfig.select-break delete mode 100644 Documentation/sound/alsa/hda_codec.txt create mode 100644 Documentation/trace/intel_th.txt create mode 100644 Documentation/trace/stm.txt create mode 100644 Documentation/virtual/kvm/arm/vgic-mapped-irqs.txt (limited to 'Documentation') diff --git a/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-arvo b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-arvo new file mode 100644 index 000000000..55e281b00 --- /dev/null +++ b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-arvo @@ -0,0 +1,53 @@ +What: /sys/bus/usb/devices/-:./::./arvo/roccatarvo/actual_profile +Date: Januar 2011 +Contact: Stefan Achatz +Description: The integer value of this attribute ranges from 1-5. + When read, this attribute returns the number of the actual + profile which is also the profile that's active on device startup. + When written this attribute activates the selected profile + immediately. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./arvo/roccatarvo/button +Date: Januar 2011 +Contact: Stefan Achatz +Description: The keyboard can store short macros with consist of 1 button with + several modifier keys internally. + When written, this file lets one set the sequence for a specific + button for a specific profile. Button and profile numbers are + included in written data. The data has to be 24 bytes long. + This file is writeonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./arvo/roccatarvo/info +Date: Januar 2011 +Contact: Stefan Achatz +Description: When read, this file returns some info about the device like the + installed firmware version. + The size of the data is 8 bytes in size. + This file is readonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./arvo/roccatarvo/key_mask +Date: Januar 2011 +Contact: Stefan Achatz +Description: The keyboard lets the user deactivate 5 certain keys like the + windows and application keys, to protect the user from the outcome + of accidentally pressing them. + The integer value of this attribute has bits 0-4 set depending + on the state of the corresponding key. + When read, this file returns the current state of the buttons. + When written, the given buttons are activated/deactivated + immediately. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./arvo/roccatarvo/mode_key +Date: Januar 2011 +Contact: Stefan Achatz +Description: The keyboard has a condensed layout without num-lock key. + Instead it uses a mode-key which activates a gaming mode where + the assignment of the number block changes. + The integer value of this attribute ranges from 0 (OFF) to 1 (ON). + When read, this file returns the actual state of the key. + When written, the key is activated/deactivated immediately. +Users: http://roccat.sourceforge.net diff --git a/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-isku b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-isku new file mode 100644 index 000000000..c601d0f2a --- /dev/null +++ b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-isku @@ -0,0 +1,153 @@ +What: /sys/bus/usb/devices/-:./::./isku/roccatisku/actual_profile +Date: June 2011 +Contact: Stefan Achatz +Description: The integer value of this attribute ranges from 0-4. + When read, this attribute returns the number of the actual + profile. This value is persistent, so its equivalent to the + profile that's active when the device is powered on next time. + When written, this file sets the number of the startup profile + and the device activates this profile immediately. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./isku/roccatisku/info +Date: June 2011 +Contact: Stefan Achatz +Description: When read, this file returns general data like firmware version. + The data is 6 bytes long. + This file is readonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./isku/roccatisku/key_mask +Date: June 2011 +Contact: Stefan Achatz +Description: When written, this file lets one deactivate certain keys like + windows and application keys, to prevent accidental presses. + Profile number for which this settings occur is included in + written data. The data has to be 6 bytes long. + Before reading this file, control has to be written to select + which profile to read. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./isku/roccatisku/keys_capslock +Date: June 2011 +Contact: Stefan Achatz +Description: When written, this file lets one set the function of the + capslock key for a specific profile. Profile number is included + in written data. The data has to be 6 bytes long. + Before reading this file, control has to be written to select + which profile to read. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./isku/roccatisku/keys_easyzone +Date: June 2011 +Contact: Stefan Achatz +Description: When written, this file lets one set the function of the + easyzone keys for a specific profile. Profile number is included + in written data. The data has to be 65 bytes long. + Before reading this file, control has to be written to select + which profile to read. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./isku/roccatisku/keys_function +Date: June 2011 +Contact: Stefan Achatz +Description: When written, this file lets one set the function of the + function keys for a specific profile. Profile number is included + in written data. The data has to be 41 bytes long. + Before reading this file, control has to be written to select + which profile to read. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./isku/roccatisku/keys_macro +Date: June 2011 +Contact: Stefan Achatz +Description: When written, this file lets one set the function of the macro + keys for a specific profile. Profile number is included in + written data. The data has to be 35 bytes long. + Before reading this file, control has to be written to select + which profile to read. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./isku/roccatisku/keys_media +Date: June 2011 +Contact: Stefan Achatz +Description: When written, this file lets one set the function of the media + keys for a specific profile. Profile number is included in + written data. The data has to be 29 bytes long. + Before reading this file, control has to be written to select + which profile to read. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./isku/roccatisku/keys_thumbster +Date: June 2011 +Contact: Stefan Achatz +Description: When written, this file lets one set the function of the + thumbster keys for a specific profile. Profile number is included + in written data. The data has to be 23 bytes long. + Before reading this file, control has to be written to select + which profile to read. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./isku/roccatisku/last_set +Date: June 2011 +Contact: Stefan Achatz +Description: When written, this file lets one set the time in secs since + epoch in which the last configuration took place. + The data has to be 20 bytes long. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./isku/roccatisku/light +Date: June 2011 +Contact: Stefan Achatz +Description: When written, this file lets one set the backlight intensity for + a specific profile. Profile number is included in written data. + The data has to be 10 bytes long for Isku, IskuFX needs 16 bytes + of data. + Before reading this file, control has to be written to select + which profile to read. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./isku/roccatisku/macro +Date: June 2011 +Contact: Stefan Achatz +Description: When written, this file lets one store macros with max 500 + keystrokes for a specific button for a specific profile. + Button and profile numbers are included in written data. + The data has to be 2083 bytes long. + Before reading this file, control has to be written to select + which profile and key to read. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./isku/roccatisku/reset +Date: November 2012 +Contact: Stefan Achatz +Description: When written, this file lets one reset the device. + The data has to be 3 bytes long. + This file is writeonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./isku/roccatisku/control +Date: June 2011 +Contact: Stefan Achatz +Description: When written, this file lets one select which data from which + profile will be read next. The data has to be 3 bytes long. + This file is writeonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./isku/roccatisku/talk +Date: June 2011 +Contact: Stefan Achatz +Description: When written, this file lets one trigger easyshift functionality + from the host. + The data has to be 16 bytes long. + This file is writeonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./isku/roccatisku/talkfx +Date: February 2013 +Contact: Stefan Achatz +Description: When written, this file lets one trigger temporary color schemes + from the host. + The data has to be 16 bytes long. + This file is writeonly. +Users: http://roccat.sourceforge.net diff --git a/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus index 833fd5992..545e69f43 100644 --- a/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus +++ b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus @@ -1,3 +1,14 @@ +What: /sys/bus/usb/devices/-:./::./koneplus/roccatkoneplus/actual_profile +Date: October 2010 +Contact: Stefan Achatz +Description: The integer value of this attribute ranges from 0-4. + When read, this attribute returns the number of the actual + profile. This value is persistent, so its equivalent to the + profile that's active when the mouse is powered on next time. + When written, this file sets the number of the startup profile + and the mouse activates this profile immediately. +Users: http://roccat.sourceforge.net + What: /sys/bus/usb/devices/-:./::./koneplus/roccatkoneplus/startup_profile Date: October 2010 Contact: Stefan Achatz @@ -22,6 +33,40 @@ Description: When read, this file returns the raw integer version number of the Please read binary attribute info which contains firmware version. Users: http://roccat.sourceforge.net +What: /sys/bus/usb/devices/-:./::./koneplus/roccatkoneplus/info +Date: November 2012 +Contact: Stefan Achatz +Description: When read, this file returns general data like firmware version. + When written, the device can be reset. + The data is 8 bytes long. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./koneplus/roccatkoneplus/macro +Date: October 2010 +Contact: Stefan Achatz +Description: The mouse can store a macro with max 500 key/button strokes + internally. + When written, this file lets one set the sequence for a specific + button for a specific profile. Button and profile numbers are + included in written data. The data has to be 2082 bytes long. + This file is writeonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./koneplus/roccatkoneplus/profile_buttons +Date: August 2010 +Contact: Stefan Achatz +Description: The mouse can store 5 profiles which can be switched by the + press of a button. A profile is split in settings and buttons. + profile_buttons holds information about button layout. + When written, this file lets one write the respective profile + buttons back to the mouse. The data has to be 77 bytes long. + The mouse will reject invalid data. + Which profile to write is determined by the profile number + contained in the data. + Before reading this file, control has to be written to select + which profile to read. +Users: http://roccat.sourceforge.net + What: /sys/bus/usb/devices/-:./::./koneplus/roccatkoneplus/profile[1-5]_buttons Date: August 2010 Contact: Stefan Achatz @@ -34,6 +79,22 @@ Description: The mouse can store 5 profiles which can be switched by the Write control to select profile and read profile_buttons instead. Users: http://roccat.sourceforge.net +What: /sys/bus/usb/devices/-:./::./koneplus/roccatkoneplus/profile_settings +Date: October 2010 +Contact: Stefan Achatz +Description: The mouse can store 5 profiles which can be switched by the + press of a button. A profile is split in settings and buttons. + profile_settings holds information like resolution, sensitivity + and light effects. + When written, this file lets one write the respective profile + settings back to the mouse. The data has to be 43 bytes long. + The mouse will reject invalid data. + Which profile to write is determined by the profile number + contained in the data. + Before reading this file, control has to be written to select + which profile to read. +Users: http://roccat.sourceforge.net + What: /sys/bus/usb/devices/-:./::./koneplus/roccatkoneplus/profile[1-5]_settings Date: August 2010 Contact: Stefan Achatz @@ -45,4 +106,40 @@ Description: The mouse can store 5 profiles which can be switched by the The returned data is 43 bytes in size. This file is readonly. Write control to select profile and read profile_settings instead. -Users: http://roccat.sourceforge.net \ No newline at end of file +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./koneplus/roccatkoneplus/sensor +Date: October 2010 +Contact: Stefan Achatz +Description: The mouse has a tracking- and a distance-control-unit. These + can be activated/deactivated and the lift-off distance can be + set. The data has to be 6 bytes long. + This file is writeonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./koneplus/roccatkoneplus/talk +Date: May 2011 +Contact: Stefan Achatz +Description: Used to active some easy* functions of the mouse from outside. + The data has to be 16 bytes long. + This file is writeonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./koneplus/roccatkoneplus/tcu +Date: October 2010 +Contact: Stefan Achatz +Description: When written a calibration process for the tracking control unit + can be initiated/cancelled. Also lets one read/write sensor + registers. + The data has to be 4 bytes long. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./koneplus/roccatkoneplus/tcu_image +Date: October 2010 +Contact: Stefan Achatz +Description: When read the mouse returns a 30x30 pixel image of the + sampled underground. This works only in the course of a + calibration process initiated with tcu. + The returned data is 1028 bytes in size. + This file is readonly. +Users: http://roccat.sourceforge.net diff --git a/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-konepure b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-konepure new file mode 100644 index 000000000..41a9b7fbf --- /dev/null +++ b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-konepure @@ -0,0 +1,105 @@ +What: /sys/bus/usb/devices/-:./::./konepure/roccatkonepure/actual_profile +Date: December 2012 +Contact: Stefan Achatz +Description: The mouse can store 5 profiles which can be switched by the + press of a button. actual_profile holds number of actual profile. + This value is persistent, so its value determines the profile + that's active when the mouse is powered on next time. + When written, the mouse activates the set profile immediately. + The data has to be 3 bytes long. + The mouse will reject invalid data. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./konepure/roccatkonepure/control +Date: December 2012 +Contact: Stefan Achatz +Description: When written, this file lets one select which data from which + profile will be read next. The data has to be 3 bytes long. + This file is writeonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./konepure/roccatkonepure/info +Date: December 2012 +Contact: Stefan Achatz +Description: When read, this file returns general data like firmware version. + When written, the device can be reset. + The data is 6 bytes long. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./konepure/roccatkonepure/macro +Date: December 2012 +Contact: Stefan Achatz +Description: The mouse can store a macro with max 500 key/button strokes + internally. + When written, this file lets one set the sequence for a specific + button for a specific profile. Button and profile numbers are + included in written data. The data has to be 2082 bytes long. + This file is writeonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./konepure/roccatkonepure/profile_buttons +Date: December 2012 +Contact: Stefan Achatz +Description: The mouse can store 5 profiles which can be switched by the + press of a button. A profile is split in settings and buttons. + profile_buttons holds information about button layout. + When written, this file lets one write the respective profile + buttons back to the mouse. The data has to be 59 bytes long. + The mouse will reject invalid data. + Which profile to write is determined by the profile number + contained in the data. + Before reading this file, control has to be written to select + which profile to read. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./konepure/roccatkonepure/profile_settings +Date: December 2012 +Contact: Stefan Achatz +Description: The mouse can store 5 profiles which can be switched by the + press of a button. A profile is split in settings and buttons. + profile_settings holds information like resolution, sensitivity + and light effects. + When written, this file lets one write the respective profile + settings back to the mouse. The data has to be 31 bytes long. + The mouse will reject invalid data. + Which profile to write is determined by the profile number + contained in the data. + Before reading this file, control has to be written to select + which profile to read. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./konepure/roccatkonepure/sensor +Date: December 2012 +Contact: Stefan Achatz +Description: The mouse has a tracking- and a distance-control-unit. These + can be activated/deactivated and the lift-off distance can be + set. The data has to be 6 bytes long. + This file is writeonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./konepure/roccatkonepure/talk +Date: December 2012 +Contact: Stefan Achatz +Description: Used to active some easy* functions of the mouse from outside. + The data has to be 16 bytes long. + This file is writeonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./konepure/roccatkonepure/tcu +Date: December 2012 +Contact: Stefan Achatz +Description: When written a calibration process for the tracking control unit + can be initiated/cancelled. Also lets one read/write sensor + registers. + The data has to be 4 bytes long. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./konepure/roccatkonepure/tcu_image +Date: December 2012 +Contact: Stefan Achatz +Description: When read the mouse returns a 30x30 pixel image of the + sampled underground. This works only in the course of a + calibration process initiated with tcu. + The returned data is 1028 bytes in size. + This file is readonly. +Users: http://roccat.sourceforge.net diff --git a/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-kovaplus b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-kovaplus index 4a98e02b6..ab01631e1 100644 --- a/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-kovaplus +++ b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-kovaplus @@ -8,6 +8,17 @@ Description: The integer value of this attribute ranges from 1-4. Has never been used. If bookkeeping is done, it's done in userland tools. Users: http://roccat.sourceforge.net +What: /sys/bus/usb/devices/-:./::./kovaplus/roccatkovaplus/actual_profile +Date: January 2011 +Contact: Stefan Achatz +Description: The integer value of this attribute ranges from 0-4. + When read, this attribute returns the number of the active + profile. + When written, the mouse activates this profile immediately. + The profile that's active when powered down is the same that's + active when the mouse is powered on. +Users: http://roccat.sourceforge.net + What: /sys/bus/usb/devices/-:./::./kovaplus/roccatkovaplus/actual_sensitivity_x Date: January 2011 Contact: Stefan Achatz @@ -40,6 +51,29 @@ Description: When read, this file returns the raw integer version number of the Obsoleted by binary sysfs attribute "info". Users: http://roccat.sourceforge.net +What: /sys/bus/usb/devices/-:./::./kovaplus/roccatkovaplus/info +Date: November 2012 +Contact: Stefan Achatz +Description: When read, this file returns general data like firmware version. + When written, the device can be reset. + The data is 6 bytes long. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./kovaplus/roccatkovaplus/profile_buttons +Date: January 2011 +Contact: Stefan Achatz +Description: The mouse can store 5 profiles which can be switched by the + press of a button. A profile is split in settings and buttons. + profile_buttons holds information about button layout. + When written, this file lets one write the respective profile + buttons back to the mouse. The data has to be 23 bytes long. + The mouse will reject invalid data. + Which profile to write is determined by the profile number + contained in the data. + Before reading this file, control has to be written to select + which profile to read. +Users: http://roccat.sourceforge.net + What: /sys/bus/usb/devices/-:./::./kovaplus/roccatkovaplus/profile[1-5]_buttons Date: January 2011 Contact: Stefan Achatz @@ -52,6 +86,22 @@ Description: The mouse can store 5 profiles which can be switched by the Write control to select profile and read profile_buttons instead. Users: http://roccat.sourceforge.net +What: /sys/bus/usb/devices/-:./::./kovaplus/roccatkovaplus/profile_settings +Date: January 2011 +Contact: Stefan Achatz +Description: The mouse can store 5 profiles which can be switched by the + press of a button. A profile is split in settings and buttons. + profile_settings holds information like resolution, sensitivity + and light effects. + When written, this file lets one write the respective profile + settings back to the mouse. The data has to be 16 bytes long. + The mouse will reject invalid data. + Which profile to write is determined by the profile number + contained in the data. + Before reading this file, control has to be written to select + which profile to read. +Users: http://roccat.sourceforge.net + What: /sys/bus/usb/devices/-:./::./kovaplus/roccatkovaplus/profile[1-5]_settings Date: January 2011 Contact: Stefan Achatz diff --git a/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-lua b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-lua new file mode 100644 index 000000000..31c6c4c8b --- /dev/null +++ b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-lua @@ -0,0 +1,7 @@ +What: /sys/bus/usb/devices/-:./control +Date: October 2012 +Contact: Stefan Achatz +Description: When written, cpi, button and light settings can be configured. + When read, actual cpi setting and sensor data are returned. + The data has to be 8 bytes long. +Users: http://roccat.sourceforge.net diff --git a/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-pyra b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-pyra index 87ac87e95..16020b31a 100644 --- a/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-pyra +++ b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-pyra @@ -37,6 +37,29 @@ Description: When read, this file returns the raw integer version number of the Please use binary attribute "info" which provides this information. Users: http://roccat.sourceforge.net +What: /sys/bus/usb/devices/-:./::./pyra/roccatpyra/info +Date: November 2012 +Contact: Stefan Achatz +Description: When read, this file returns general data like firmware version. + When written, the device can be reset. + The data is 6 bytes long. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./pyra/roccatpyra/profile_buttons +Date: August 2010 +Contact: Stefan Achatz +Description: The mouse can store 5 profiles which can be switched by the + press of a button. A profile is split in settings and buttons. + profile_buttons holds information about button layout. + When written, this file lets one write the respective profile + buttons back to the mouse. The data has to be 19 bytes long. + The mouse will reject invalid data. + Which profile to write is determined by the profile number + contained in the data. + Before reading this file, control has to be written to select + which profile to read. +Users: http://roccat.sourceforge.net + What: /sys/bus/usb/devices/-:./::./pyra/roccatpyra/profile[1-5]_buttons Date: August 2010 Contact: Stefan Achatz @@ -49,6 +72,22 @@ Description: The mouse can store 5 profiles which can be switched by the Write control to select profile and read profile_buttons instead. Users: http://roccat.sourceforge.net +What: /sys/bus/usb/devices/-:./::./pyra/roccatpyra/profile_settings +Date: August 2010 +Contact: Stefan Achatz +Description: The mouse can store 5 profiles which can be switched by the + press of a button. A profile is split in settings and buttons. + profile_settings holds information like resolution, sensitivity + and light effects. + When written, this file lets one write the respective profile + settings back to the mouse. The data has to be 13 bytes long. + The mouse will reject invalid data. + Which profile to write is determined by the profile number + contained in the data. + Before reading this file, control has to be written to select + which profile to read. +Users: http://roccat.sourceforge.net + What: /sys/bus/usb/devices/-:./::./pyra/roccatpyra/profile[1-5]_settings Date: August 2010 Contact: Stefan Achatz @@ -62,6 +101,17 @@ Description: The mouse can store 5 profiles which can be switched by the Write control to select profile and read profile_settings instead. Users: http://roccat.sourceforge.net +What: /sys/bus/usb/devices/-:./::./pyra/roccatpyra/settings +Date: August 2010 +Contact: Stefan Achatz +Description: When read, this file returns the settings stored in the mouse. + The size of the data is 3 bytes and holds information on the + startup_profile. + When written, this file lets write settings back to the mouse. + The data has to be 3 bytes long. The mouse will reject invalid + data. +Users: http://roccat.sourceforge.net + What: /sys/bus/usb/devices/-:./::./pyra/roccatpyra/startup_profile Date: August 2010 Contact: Stefan Achatz diff --git a/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-ryos b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-ryos new file mode 100644 index 000000000..1d6a8cf9d --- /dev/null +++ b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-ryos @@ -0,0 +1,178 @@ +What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/control +Date: October 2013 +Contact: Stefan Achatz +Description: When written, this file lets one select which data from which + profile will be read next. The data has to be 3 bytes long. + This file is writeonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/profile +Date: October 2013 +Contact: Stefan Achatz +Description: The mouse can store 5 profiles which can be switched by the + press of a button. profile holds index of actual profile. + This value is persistent, so its value determines the profile + that's active when the device is powered on next time. + When written, the device activates the set profile immediately. + The data has to be 3 bytes long. + The device will reject invalid data. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/keys_primary +Date: October 2013 +Contact: Stefan Achatz +Description: When written, this file lets one set the default of all keys for + a specific profile. Profile index is included in written data. + The data has to be 125 bytes long. + Before reading this file, control has to be written to select + which profile to read. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/keys_function +Date: October 2013 +Contact: Stefan Achatz +Description: When written, this file lets one set the function of the + function keys for a specific profile. Profile index is included + in written data. The data has to be 95 bytes long. + Before reading this file, control has to be written to select + which profile to read. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/keys_macro +Date: October 2013 +Contact: Stefan Achatz +Description: When written, this file lets one set the function of the macro + keys for a specific profile. Profile index is included in + written data. The data has to be 35 bytes long. + Before reading this file, control has to be written to select + which profile to read. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/keys_thumbster +Date: October 2013 +Contact: Stefan Achatz +Description: When written, this file lets one set the function of the + thumbster keys for a specific profile. Profile index is included + in written data. The data has to be 23 bytes long. + Before reading this file, control has to be written to select + which profile to read. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/keys_extra +Date: October 2013 +Contact: Stefan Achatz +Description: When written, this file lets one set the function of the + capslock and function keys for a specific profile. Profile index + is included in written data. The data has to be 8 bytes long. + Before reading this file, control has to be written to select + which profile to read. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/keys_easyzone +Date: October 2013 +Contact: Stefan Achatz +Description: When written, this file lets one set the function of the + easyzone keys for a specific profile. Profile index is included + in written data. The data has to be 294 bytes long. + Before reading this file, control has to be written to select + which profile to read. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/key_mask +Date: October 2013 +Contact: Stefan Achatz +Description: When written, this file lets one deactivate certain keys like + windows and application keys, to prevent accidental presses. + Profile index for which this settings occur is included in + written data. The data has to be 6 bytes long. + Before reading this file, control has to be written to select + which profile to read. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/light +Date: October 2013 +Contact: Stefan Achatz +Description: When written, this file lets one set the backlight intensity for + a specific profile. Profile index is included in written data. + This attribute is only valid for the glow and pro variant. + The data has to be 16 bytes long. + Before reading this file, control has to be written to select + which profile to read. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/macro +Date: October 2013 +Contact: Stefan Achatz +Description: When written, this file lets one store macros with max 480 + keystrokes for a specific button for a specific profile. + Button and profile indexes are included in written data. + The data has to be 2002 bytes long. + Before reading this file, control has to be written to select + which profile and key to read. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/info +Date: October 2013 +Contact: Stefan Achatz +Description: When read, this file returns general data like firmware version. + The data is 8 bytes long. + This file is readonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/reset +Date: October 2013 +Contact: Stefan Achatz +Description: When written, this file lets one reset the device. + The data has to be 3 bytes long. + This file is writeonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/talk +Date: October 2013 +Contact: Stefan Achatz +Description: When written, this file lets one trigger easyshift functionality + from the host. + The data has to be 16 bytes long. + This file is writeonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/light_control +Date: October 2013 +Contact: Stefan Achatz +Description: When written, this file lets one switch between stored and custom + light settings. + This attribute is only valid for the pro variant. + The data has to be 8 bytes long. + This file is writeonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/stored_lights +Date: October 2013 +Contact: Stefan Achatz +Description: When written, this file lets one set per-key lighting for different + layers. + This attribute is only valid for the pro variant. + The data has to be 1382 bytes long. + Before reading this file, control has to be written to select + which profile to read. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/custom_lights +Date: October 2013 +Contact: Stefan Achatz +Description: When written, this file lets one set the actual per-key lighting. + This attribute is only valid for the pro variant. + The data has to be 20 bytes long. + This file is writeonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/light_macro +Date: October 2013 +Contact: Stefan Achatz +Description: When written, this file lets one set a light macro that is looped + whenever the device gets in dimness mode. + This attribute is only valid for the pro variant. + The data has to be 2002 bytes long. + Before reading this file, control has to be written to select + which profile to read. +Users: http://roccat.sourceforge.net diff --git a/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-savu b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-savu new file mode 100644 index 000000000..f1e02a98b --- /dev/null +++ b/Documentation/ABI/obsolete/sysfs-driver-hid-roccat-savu @@ -0,0 +1,76 @@ +What: /sys/bus/usb/devices/-:./::./savu/roccatsavu/buttons +Date: Mai 2012 +Contact: Stefan Achatz +Description: The mouse can store 5 profiles which can be switched by the + press of a button. A profile is split into general settings and + button settings. buttons holds informations about button layout. + When written, this file lets one write the respective profile + buttons to the mouse. The data has to be 47 bytes long. + The mouse will reject invalid data. + Which profile to write is determined by the profile number + contained in the data. + Before reading this file, control has to be written to select + which profile to read. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./savu/roccatsavu/control +Date: Mai 2012 +Contact: Stefan Achatz +Description: When written, this file lets one select which data from which + profile will be read next. The data has to be 3 bytes long. + This file is writeonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./savu/roccatsavu/general +Date: Mai 2012 +Contact: Stefan Achatz +Description: The mouse can store 5 profiles which can be switched by the + press of a button. A profile is split into general settings and + button settings. profile holds informations like resolution, sensitivity + and light effects. + When written, this file lets one write the respective profile + settings back to the mouse. The data has to be 43 bytes long. + The mouse will reject invalid data. + Which profile to write is determined by the profile number + contained in the data. + This file is writeonly. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./savu/roccatsavu/info +Date: Mai 2012 +Contact: Stefan Achatz +Description: When read, this file returns general data like firmware version. + When written, the device can be reset. + The data is 8 bytes long. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./savu/roccatsavu/macro +Date: Mai 2012 +Contact: Stefan Achatz +Description: When written, this file lets one store macros with max 500 + keystrokes for a specific button for a specific profile. + Button and profile numbers are included in written data. + The data has to be 2083 bytes long. + Before reading this file, control has to be written to select + which profile and key to read. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./savu/roccatsavu/profile +Date: Mai 2012 +Contact: Stefan Achatz +Description: The mouse can store 5 profiles which can be switched by the + press of a button. profile holds number of actual profile. + This value is persistent, so its value determines the profile + that's active when the mouse is powered on next time. + When written, the mouse activates the set profile immediately. + The data has to be 3 bytes long. + The mouse will reject invalid data. +Users: http://roccat.sourceforge.net + +What: /sys/bus/usb/devices/-:./::./savu/roccatsavu/sensor +Date: July 2012 +Contact: Stefan Achatz +Description: The mouse has a Avago ADNS-3090 sensor. + This file allows reading and writing of the mouse sensors registers. + The data has to be 4 bytes long. +Users: http://roccat.sourceforge.net diff --git a/Documentation/ABI/stable/sysfs-class-tpm b/Documentation/ABI/stable/sysfs-class-tpm index 9f790eebb..c0e23830f 100644 --- a/Documentation/ABI/stable/sysfs-class-tpm +++ b/Documentation/ABI/stable/sysfs-class-tpm @@ -116,7 +116,7 @@ Description: The "pubek" property will return the TPM's public endorsement owner's authorization. Since the TPM driver doesn't store any secrets, it can't authorize its own request for the pubek, making it unaccessible. The public endorsement key is gener- - ated at TPM menufacture time and exists for the life of the + ated at TPM manufacture time and exists for the life of the chip. Example output: @@ -163,7 +163,7 @@ Date: April 2006 KernelVersion: 2.6.17 Contact: tpmdd-devel@lists.sf.net Description: The "temp_deactivated" property returns a '1' if the chip has - been temporarily dectivated, usually until the next power + been temporarily deactivated, usually until the next power cycle. Whether a warm boot (reboot) will clear a TPM chip from a temp_deactivated state is platform specific. diff --git a/Documentation/ABI/stable/sysfs-firmware-opal-elog b/Documentation/ABI/stable/sysfs-firmware-opal-elog index e1f3058f5..2536434d4 100644 --- a/Documentation/ABI/stable/sysfs-firmware-opal-elog +++ b/Documentation/ABI/stable/sysfs-firmware-opal-elog @@ -57,4 +57,4 @@ Description: Shortly after acknowledging it, the log entry will be removed from sysfs. Reading this file will list the supported - operations (curently just acknowledge). \ No newline at end of file + operations (currently just acknowledge). diff --git a/Documentation/ABI/testing/configfs-stp-policy b/Documentation/ABI/testing/configfs-stp-policy new file mode 100644 index 000000000..421ce6825 --- /dev/null +++ b/Documentation/ABI/testing/configfs-stp-policy @@ -0,0 +1,48 @@ +What: /config/stp-policy +Date: June 2015 +KernelVersion: 4.3 +Description: + This group contains policies mandating Master/Channel allocation + for software sources wishing to send trace data over an STM + device. + +What: /config/stp-policy/. +Date: June 2015 +KernelVersion: 4.3 +Description: + This group is the root of a policy; its name is a concatenation + of an stm device name to which this policy applies and an + arbitrary string. If part doesn't match an existing + stm device, mkdir will fail with ENODEV; if that device already + has a policy assigned to it, mkdir will fail with EBUSY. + +What: /config/stp-policy/./device +Date: June 2015 +KernelVersion: 4.3 +Description: + STM device to which this policy applies, read only. Same as the + component of its parent directory. + +What: /config/stp-policy/./ +Date: June 2015 +KernelVersion: 4.3 +Description: + Policy node is a string identifier that software clients will + use to request a master/channel to be allocated and assigned to + them. + +What: /config/stp-policy/.//masters +Date: June 2015 +KernelVersion: 4.3 +Description: + Range of masters from which to allocate for users of this node. + Write two numbers: the first master and the last master number. + +What: /config/stp-policy/.//channels +Date: June 2015 +KernelVersion: 4.3 +Description: + Range of channels from which to allocate for users of this node. + Write two numbers: the first channel and the last channel + number. + diff --git a/Documentation/ABI/testing/sysfs-block b/Documentation/ABI/testing/sysfs-block index 8df003963..71d184dbb 100644 --- a/Documentation/ABI/testing/sysfs-block +++ b/Documentation/ABI/testing/sysfs-block @@ -60,6 +60,13 @@ Description: Indicates whether a storage device is capable of storing integrity metadata. Set if the device is T10 PI-capable. +What: /sys/block//integrity/protection_interval_bytes +Date: July 2015 +Contact: Martin K. Petersen +Description: + Describes the number of data bytes which are protected + by one integrity tuple. Typically the device's logical + block size. What: /sys/block//integrity/write_generate Date: June 2008 diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x index d72ca1736..924265a12 100644 --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x @@ -8,13 +8,6 @@ Description: (RW) Enable/disable tracing on this specific trace entiry. of coresight components linking the source to the sink is configured and managed automatically by the coresight framework. -What: /sys/bus/coresight/devices/.[etm|ptm]/status -Date: November 2014 -KernelVersion: 3.19 -Contact: Mathieu Poirier -Description: (R) List various control and status registers. The specific - layout and content is driver specific. - What: /sys/bus/coresight/devices/.[etm|ptm]/addr_idx Date: November 2014 KernelVersion: 3.19 @@ -251,3 +244,79 @@ Date: November 2014 KernelVersion: 3.19 Contact: Mathieu Poirier Description: (RW) Define the event that controls the trigger. + +What: /sys/bus/coresight/devices/.[etm|ptm]/cpu +Date: October 2015 +KernelVersion: 4.4 +Contact: Mathieu Poirier +Description: (RO) Holds the cpu number this tracer is affined to. + +What: /sys/bus/coresight/devices/.[etm|ptm]/mgmt/etmccr +Date: September 2015 +KernelVersion: 4.4 +Contact: Mathieu Poirier +Description: (RO) Print the content of the ETM Configuration Code register + (0x004). The value is read directly from the HW. + +What: /sys/bus/coresight/devices/.[etm|ptm]/mgmt/etmccer +Date: September 2015 +KernelVersion: 4.4 +Contact: Mathieu Poirier +Description: (RO) Print the content of the ETM Configuration Code Extension + register (0x1e8). The value is read directly from the HW. + +What: /sys/bus/coresight/devices/.[etm|ptm]/mgmt/etmscr +Date: September 2015 +KernelVersion: 4.4 +Contact: Mathieu Poirier +Description: (RO) Print the content of the ETM System Configuration + register (0x014). The value is read directly from the HW. + +What: /sys/bus/coresight/devices/.[etm|ptm]/mgmt/etmidr +Date: September 2015 +KernelVersion: 4.4 +Contact: Mathieu Poirier +Description: (RO) Print the content of the ETM ID register (0x1e4). The + value is read directly from the HW. + +What: /sys/bus/coresight/devices/.[etm|ptm]/mgmt/etmcr +Date: September 2015 +KernelVersion: 4.4 +Contact: Mathieu Poirier +Description: (RO) Print the content of the ETM Main Control register (0x000). + The value is read directly from the HW. + +What: /sys/bus/coresight/devices/.[etm|ptm]/mgmt/etmtraceidr +Date: September 2015 +KernelVersion: 4.4 +Contact: Mathieu Poirier +Description: (RO) Print the content of the ETM Trace ID register (0x200). + The value is read directly from the HW. + +What: /sys/bus/coresight/devices/.[etm|ptm]/mgmt/etmteevr +Date: September 2015 +KernelVersion: 4.4 +Contact: Mathieu Poirier +Description: (RO) Print the content of the ETM Trace Enable Event register + (0x020). The value is read directly from the HW. + +What: /sys/bus/coresight/devices/.[etm|ptm]/mgmt/etmtsscr +Date: September 2015 +KernelVersion: 4.4 +Contact: Mathieu Poirier +Description: (RO) Print the content of the ETM Trace Start/Stop Conrol + register (0x018). The value is read directly from the HW. + +What: /sys/bus/coresight/devices/.[etm|ptm]/mgmt/etmtecr1 +Date: September 2015 +KernelVersion: 4.4 +Contact: Mathieu Poirier +Description: (RO) Print the content of the ETM Enable Conrol #1 + register (0x024). The value is read directly from the HW. + +What: /sys/bus/coresight/devices/.[etm|ptm]/mgmt/etmtecr2 +Date: September 2015 +KernelVersion: 4.4 +Contact: Mathieu Poirier +Description: (RO) Print the content of the ETM Enable Conrol #2 + register (0x01c). The value is read directly from the HW. diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 42d360fe6..0439c2aaf 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -581,6 +581,7 @@ What: /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_rising_en What: /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_falling_en What: /sys/.../iio:deviceX/events/in_voltageY_thresh_rising_en What: /sys/.../iio:deviceX/events/in_voltageY_thresh_falling_en +What: /sys/.../iio:deviceX/events/in_voltageY_thresh_either_en What: /sys/.../iio:deviceX/events/in_tempY_thresh_rising_en What: /sys/.../iio:deviceX/events/in_tempY_thresh_falling_en KernelVersion: 2.6.37 @@ -1459,3 +1460,34 @@ Description: measurements and return the average value as output data. Each value resulted from [_name]_oversampling_ratio measurements is considered as one sample for [_name]_sampling_frequency. + +What: /sys/bus/iio/devices/iio:deviceX/in_concentration_raw +What: /sys/bus/iio/devices/iio:deviceX/in_concentrationX_raw +What: /sys/bus/iio/devices/iio:deviceX/in_concentration_co2_raw +What: /sys/bus/iio/devices/iio:deviceX/in_concentrationX_co2_raw +What: /sys/bus/iio/devices/iio:deviceX/in_concentration_voc_raw +What: /sys/bus/iio/devices/iio:deviceX/in_concentrationX_voc_raw +KernelVersion: 4.3 +Contact: linux-iio@vger.kernel.org +Description: + Raw (unscaled no offset etc.) percentage reading of a substance. + +What: /sys/bus/iio/devices/iio:deviceX/in_resistance_raw +What: /sys/bus/iio/devices/iio:deviceX/in_resistanceX_raw +What: /sys/bus/iio/devices/iio:deviceX/out_resistance_raw +What: /sys/bus/iio/devices/iio:deviceX/out_resistanceX_raw +KernelVersion: 4.3 +Contact: linux-iio@vger.kernel.org +Description: + Raw (unscaled no offset etc.) resistance reading that can be processed + into an ohm value. + +What: /sys/bus/iio/devices/iio:deviceX/heater_enable +KernelVersion: 4.1.0 +Contact: linux-iio@vger.kernel.org +Description: + '1' (enable) or '0' (disable) specifying the enable + of heater function. Same reading values apply + This ABI is especially applicable for humidity sensors + to heatup the device and get rid of any condensation + in some humidity environment diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 b/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 new file mode 100644 index 000000000..f30b4c424 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 @@ -0,0 +1,43 @@ +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_sensing_mode +Date: August 2015 +KernelVersion: 4.2.0 +Contact: source@cogentembedded.com +Description: + Program sensor type for threshold detector inputs. + Could be either "GND-Open" or "Supply-Open" mode. Y is a + threshold detector input channel. Channels 0..7, 8..15, 16..23 + and 24..31 has common sensor types. + +What: /sys/bus/iio/devices/iio:deviceX/events/in_voltageY_thresh_falling_value +Date: August 2015 +KernelVersion: 4.2.0 +Contact: source@cogentembedded.com +Description: + Channel Y low voltage threshold. If sensor input voltage goes lower then + this value then the threshold falling event is pushed. + Depending on in_voltageY_sensing_mode the low voltage threshold + is separately set for "GND-Open" and "Supply-Open" modes. + Channels 0..31 have common low threshold values, but could have different + sensing_modes. + The low voltage threshold range is between 2..21V. + Hysteresis between low and high thresholds can not be lower then 2 and + can not be odd. + If falling threshold results hysteresis to odd value then rising + threshold is automatically subtracted by one. + +What: /sys/bus/iio/devices/iio:deviceX/events/in_voltageY_thresh_rising_value +Date: August 2015 +KernelVersion: 4.2.0 +Contact: source@cogentembedded.com +Description: + Channel Y high voltage threshold. If sensor input voltage goes higher then + this value then the threshold rising event is pushed. + Depending on in_voltageY_sensing_mode the high voltage threshold + is separately set for "GND-Open" and "Supply-Open" modes. + Channels 0..31 have common high threshold values, but could have different + sensing_modes. + The high voltage threshold range is between 3..22V. + Hysteresis between low and high thresholds can not be lower then 2 and + can not be odd. + If rising threshold results hysteresis to odd value then falling + threshold is automatically appended by one. diff --git a/Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x b/Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x new file mode 100644 index 000000000..c0c1ea924 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x @@ -0,0 +1,7 @@ +What: /sys/bus/iio/devices/iio:deviceX/in_concentration_VOC_short_raw +Date: September 2015 +KernelVersion: 4.3 +Contact: Matt Ranostay +Description: + Get the raw calibration VOC value from the sensor. + This value has little application outside of calibration. diff --git a/Documentation/ABI/testing/sysfs-bus-iio-humidity-hdc100x b/Documentation/ABI/testing/sysfs-bus-iio-humidity-hdc100x new file mode 100644 index 000000000..b72bb6255 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-humidity-hdc100x @@ -0,0 +1,9 @@ +What: /sys/bus/iio/devices/iio:deviceX/out_current_heater_raw +What: /sys/bus/iio/devices/iio:deviceX/out_current_heater_raw_available +KernelVersion: 4.3 +Contact: linux-iio@vger.kernel.org +Description: + Controls the heater device within the humidity sensor to get + rid of excess condensation. + + Valid control values are 0 = OFF, and 1 = ON. diff --git a/Documentation/ABI/testing/sysfs-bus-iio-meas-spec b/Documentation/ABI/testing/sysfs-bus-iio-meas-spec new file mode 100644 index 000000000..1a6265e92 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-meas-spec @@ -0,0 +1,8 @@ +What: /sys/bus/iio/devices/iio:deviceX/battery_low +KernelVersion: 4.1.0 +Contact: linux-iio@vger.kernel.org +Description: + Reading returns either '1' or '0'. '1' means that the + battery level supplied to sensor is below 2.25V. + This ABI is available for tsys02d, htu21, ms8607 + This ABI is available for htu21, ms8607 diff --git a/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs b/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs index bbb039237..04ac62305 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs +++ b/Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs @@ -18,3 +18,25 @@ Description: trigger. In order to associate the trigger with an IIO device one should write this name string to /sys/bus/iio/devices/iio:deviceY/trigger/current_trigger. + +What: /sys/bus/iio/devices/iio_sysfs_trigger/add_trigger +KernelVersion: 2.6.39 +Contact: linux-iio@vger.kernel.org +Description: + This attribute is provided by the iio-trig-sysfs stand-alone + driver and it is used to activate the creation of a new trigger. + In order to achieve this, one should write a positive integer + into the associated file, which will serve as the id of the + trigger. If the trigger with the specified id is already present + in the system, an invalid argument message will be returned. + +What: /sys/bus/iio/devices/iio_sysfs_trigger/remove_trigger +KernelVersion: 2.6.39 +Contact: linux-iio@vger.kernel.org +Description: + This attribute is used to unregister and delete a previously + created trigger from the list of available triggers. In order to + achieve this, one should write a positive integer into the + associated file, representing the id of the trigger that needs + to be removed. If the trigger can't be found, an invalid + argument message will be returned to the user. diff --git a/Documentation/ABI/testing/sysfs-bus-intel_th-devices-gth b/Documentation/ABI/testing/sysfs-bus-intel_th-devices-gth new file mode 100644 index 000000000..22d084384 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-intel_th-devices-gth @@ -0,0 +1,49 @@ +What: /sys/bus/intel_th/devices/-gth/masters/* +Date: June 2015 +KernelVersion: 4.3 +Contact: Alexander Shishkin +Description: (RW) Configure output ports for STP masters. Writing -1 + disables a master; any + +What: /sys/bus/intel_th/devices/-gth/outputs/[0-7]_port +Date: June 2015 +KernelVersion: 4.3 +Contact: Alexander Shishkin +Description: (RO) Output port type: + 0: not present, + 1: MSU (Memory Storage Unit) + 2: CTP (Common Trace Port) + 4: PTI (MIPI PTI). + +What: /sys/bus/intel_th/devices/-gth/outputs/[0-7]_drop +Date: June 2015 +KernelVersion: 4.3 +Contact: Alexander Shishkin +Description: (RW) Data retention policy setting: keep (0) or drop (1) + incoming data while output port is in reset. + +What: /sys/bus/intel_th/devices/-gth/outputs/[0-7]_null +Date: June 2015 +KernelVersion: 4.3 +Contact: Alexander Shishkin +Description: (RW) STP NULL packet generation: enabled (1) or disabled (0). + +What: /sys/bus/intel_th/devices/-gth/outputs/[0-7]_flush +Date: June 2015 +KernelVersion: 4.3 +Contact: Alexander Shishkin +Description: (RW) Force flush data from byte packing buffer for the output + port. + +What: /sys/bus/intel_th/devices/-gth/outputs/[0-7]_reset +Date: June 2015 +KernelVersion: 4.3 +Contact: Alexander Shishkin +Description: (RO) Output port is in reset (1). + +What: /sys/bus/intel_th/devices/-gth/outputs/[0-7]_smcfreq +Date: June 2015 +KernelVersion: 4.3 +Contact: Alexander Shishkin +Description: (RW) STP sync packet frequency for the port. Specifies the + number of clocks between mainenance packets. diff --git a/Documentation/ABI/testing/sysfs-bus-intel_th-devices-msc b/Documentation/ABI/testing/sysfs-bus-intel_th-devices-msc new file mode 100644 index 000000000..b940c5d91 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-intel_th-devices-msc @@ -0,0 +1,33 @@ +What: /sys/bus/intel_th/devices/-msc/wrap +Date: June 2015 +KernelVersion: 4.3 +Contact: Alexander Shishkin +Description: (RW) Configure MSC buffer wrapping. 1 == wrapping enabled. + +What: /sys/bus/intel_th/devices/-msc/mode +Date: June 2015 +KernelVersion: 4.3 +Contact: Alexander Shishkin +Description: (RW) Configure MSC operating mode: + - "single", for contiguous buffer mode (high-order alloc); + - "multi", for multiblock mode; + - "ExI", for DCI handler mode; + - "debug", for debug mode. + If operating mode changes, existing buffer is deallocated, + provided there are no active users and tracing is not enabled, + otherwise the write will fail. + +What: /sys/bus/intel_th/devices/-msc/nr_pages +Date: June 2015 +KernelVersion: 4.3 +Contact: Alexander Shishkin +Description: (RW) Configure MSC buffer size for "single" or "multi" modes. + In single mode, this is a single number of pages, has to be + power of 2. In multiblock mode, this is a comma-separated list + of numbers of pages for each window to be allocated. Number of + windows is not limited. + Writing to this file deallocates existing buffer (provided + there are no active users and tracing is not enabled) and then + allocates a new one. + + diff --git a/Documentation/ABI/testing/sysfs-bus-intel_th-devices-pti b/Documentation/ABI/testing/sysfs-bus-intel_th-devices-pti new file mode 100644 index 000000000..df0b24fd0 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-intel_th-devices-pti @@ -0,0 +1,24 @@ +What: /sys/bus/intel_th/devices/-pti/mode +Date: June 2015 +KernelVersion: 4.3 +Contact: Alexander Shishkin +Description: (RW) Configure PTI output width. Currently supported values + are 4, 8, 12, 16. + +What: /sys/bus/intel_th/devices/-pti/freerunning_clock +Date: June 2015 +KernelVersion: 4.3 +Contact: Alexander Shishkin +Description: (RW) 0: PTI trace clock acts as a strobe which only toggles + when there is trace data to send. 1: PTI trace clock is a + free-running clock. + +What: /sys/bus/intel_th/devices/-pti/clock_divider +Date: June 2015 +KernelVersion: 4.3 +Contact: Alexander Shishkin +Description: (RW) Configure PTI port clock divider: + - 0: Intel TH clock rate, + - 1: 1/2 Intel TH clock rate, + - 2: 1/4 Intel TH clock rate, + - 3: 1/8 Intel TH clock rate. diff --git a/Documentation/ABI/testing/sysfs-bus-intel_th-output-devices b/Documentation/ABI/testing/sysfs-bus-intel_th-output-devices new file mode 100644 index 000000000..4d48a9451 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-intel_th-output-devices @@ -0,0 +1,13 @@ +What: /sys/bus/intel_th/devices/-/active +Date: June 2015 +KernelVersion: 4.3 +Contact: Alexander Shishkin +Description: (RW) Writes of 1 or 0 enable or disable trace output to this + output device. Reads return current status. + +What: /sys/bus/intel_th/devices/-msc/port +Date: June 2015 +KernelVersion: 4.3 +Contact: Alexander Shishkin +Description: (RO) Port number, corresponding to this output device on the + switch (GTH). diff --git a/Documentation/ABI/testing/sysfs-bus-mei b/Documentation/ABI/testing/sysfs-bus-mei index 20e4d1638..6bd45346a 100644 --- a/Documentation/ABI/testing/sysfs-bus-mei +++ b/Documentation/ABI/testing/sysfs-bus-mei @@ -19,3 +19,10 @@ KernelVersion: 4.2 Contact: Tomas Winkler Description: Stores mei client device uuid Format: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx + +What: /sys/bus/mei/devices/.../version +Date: Aug 2015 +KernelVersion: 4.3 +Contact: Tomas Winkler +Description: Stores mei client protocol version + Format: %d diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb index 864637f25..3a4abfc44 100644 --- a/Documentation/ABI/testing/sysfs-bus-usb +++ b/Documentation/ABI/testing/sysfs-bus-usb @@ -1,3 +1,23 @@ +What: /sys/bus/usb/devices/INTERFACE/authorized +Date: August 2015 +Description: + This allows to authorize (1) or deauthorize (0) + individual interfaces instead a whole device + in contrast to the device authorization. + If a deauthorized interface will be authorized + so the driver probing must be triggered manually + by writing INTERFACE to /sys/bus/usb/drivers_probe + This allows to avoid side-effects with drivers + that need multiple interfaces. + A deauthorized interface cannot be probed or claimed. + +What: /sys/bus/usb/devices/usbX/interface_authorized_default +Date: August 2015 +Description: + This is used as value that determines if interfaces + would be authorized by default. + The value can be 1 or 0. It's by default 1. + What: /sys/bus/usb/device/.../authorized Date: July 2008 KernelVersion: 2.6.26 diff --git a/Documentation/ABI/testing/sysfs-class-fpga-manager b/Documentation/ABI/testing/sysfs-class-fpga-manager new file mode 100644 index 000000000..23056c532 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-fpga-manager @@ -0,0 +1,37 @@ +What: /sys/class/fpga_manager//name +Date: August 2015 +KernelVersion: 4.3 +Contact: Alan Tull +Description: Name of low level fpga manager driver. + +What: /sys/class/fpga_manager//state +Date: August 2015 +KernelVersion: 4.3 +Contact: Alan Tull +Description: Read fpga manager state as a string. + The intent is to provide enough detail that if something goes + wrong during FPGA programming (something that the driver can't + fix) then userspace can know, i.e. if the firmware request + fails, that could be due to not being able to find the firmware + file. + + This is a superset of FPGA states and fpga manager driver + states. The fpga manager driver is walking through these steps + to get the FPGA into a known operating state. It's a sequence, + though some steps may get skipped. Valid FPGA states will vary + by manufacturer; this is a superset. + + * unknown = can't determine state + * power off = FPGA power is off + * power up = FPGA reports power is up + * reset = FPGA held in reset state + * firmware request = firmware class request in progress + * firmware request error = firmware request failed + * write init = preparing FPGA for programming + * write init error = Error while preparing FPGA for + programming + * write = FPGA ready to receive image data + * write error = Error while programming + * write complete = Doing post programming steps + * write complete error = Error while doing post programming + * operating = FPGA is programmed and operating diff --git a/Documentation/ABI/testing/sysfs-class-mic.txt b/Documentation/ABI/testing/sysfs-class-mic.txt index 13f48afc5..d45eed2bf 100644 --- a/Documentation/ABI/testing/sysfs-class-mic.txt +++ b/Documentation/ABI/testing/sysfs-class-mic.txt @@ -41,18 +41,15 @@ Description: When read, this entry provides the current state of an Intel MIC device in the context of the card OS. Possible values that will be read are: - "offline" - The MIC device is ready to boot the card OS. On + "ready" - The MIC device is ready to boot the card OS. On reading this entry after an OSPM resume, a "boot" has to be written to this entry if the card was previously shutdown during OSPM suspend. - "online" - The MIC device has initiated booting a card OS. + "booting" - The MIC device has initiated booting a card OS. + "online" - The MIC device has completed boot and is online "shutting_down" - The card OS is shutting down. + "resetting" - A reset has been initiated for the MIC device "reset_failed" - The MIC device has failed to reset. - "suspending" - The MIC device is currently being prepared for - suspend. On reading this entry, a "suspend" has to be written - to the state sysfs entry to ensure the card is shutdown during - OSPM suspend. - "suspended" - The MIC device has been suspended. When written, this sysfs entry triggers different state change operations depending upon the current state of the card OS. @@ -62,8 +59,6 @@ Description: sysfs entries. "reset" - Initiates device reset. "shutdown" - Initiates card OS shutdown. - "suspend" - Initiates card OS shutdown and also marks the card - as suspended. What: /sys/class/mic/mic(x)/shutdown_status Date: October 2013 @@ -126,7 +121,7 @@ Description: the card. This sysfs entry can be written with the following valid strings: a) linux - Boot a Linux image. - b) elf - Boot an elf image for flash updates. + b) flash - Boot an image for flash updates. What: /sys/class/mic/mic(x)/log_buf_addr Date: October 2013 @@ -155,3 +150,17 @@ Description: daemon to set the log buffer length address. The correct log buffer length address to be written can be found in the System.map file of the card OS. + +What: /sys/class/mic/mic(x)/heartbeat_enable +Date: March 2015 +KernelVersion: 3.20 +Contact: Ashutosh Dixit +Description: + The MIC drivers detect and inform user space about card crashes + via a heartbeat mechanism (see the description of + shutdown_status above). User space can turn off this + notification by setting heartbeat_enable to 0 and enable it by + setting this entry to 1. If this notification is disabled it is + the responsibility of user space to detect card crashes via + alternative means such as a network ping. This setting is + enabled by default. diff --git a/Documentation/ABI/testing/sysfs-class-power b/Documentation/ABI/testing/sysfs-class-power index 369d2a2d7..fa05719f9 100644 --- a/Documentation/ABI/testing/sysfs-class-power +++ b/Documentation/ABI/testing/sysfs-class-power @@ -74,3 +74,61 @@ Description: Valid values: - 0 - 70 (minutes), step by 10 (rounded down) + +What: /sys/class/power_supply/bq24257-charger/ovp_voltage +Date: October 2015 +KernelVersion: 4.4.0 +Contact: Andreas Dannenberg +Description: + This entry configures the overvoltage protection feature of bq24257- + type charger devices. This feature protects the device and other + components against damage from overvoltage on the input supply. See + device datasheet for details. + + Valid values: + - 6000000, 6500000, 7000000, 8000000, 9000000, 9500000, 10000000, + 10500000 (all uV) + +What: /sys/class/power_supply/bq24257-charger/in_dpm_voltage +Date: October 2015 +KernelVersion: 4.4.0 +Contact: Andreas Dannenberg +Description: + This entry configures the input dynamic power path management voltage of + bq24257-type charger devices. Once the supply drops to the configured + voltage, the input current limit is reduced down to prevent the further + drop of the supply. When the IC enters this mode, the charge current is + lower than the set value. See device datasheet for details. + + Valid values: + - 4200000, 4280000, 4360000, 4440000, 4520000, 4600000, 4680000, + 4760000 (all uV) + +What: /sys/class/power_supply/bq24257-charger/high_impedance_enable +Date: October 2015 +KernelVersion: 4.4.0 +Contact: Andreas Dannenberg +Description: + This entry allows enabling the high-impedance mode of bq24257-type + charger devices. If enabled, it places the charger IC into low power + standby mode with the switch mode controller disabled. When disabled, + the charger operates normally. See device datasheet for details. + + Valid values: + - 1: enabled + - 0: disabled + +What: /sys/class/power_supply/bq24257-charger/sysoff_enable +Date: October 2015 +KernelVersion: 4.4.0 +Contact: Andreas Dannenberg +Description: + This entry allows enabling the sysoff mode of bq24257-type charger + devices. If enabled and the input is removed, the internal battery FET + is turned off in order to reduce the leakage from the BAT pin to less + than 1uA. Note that on some devices/systems this disconnects the battery + from the system. See device datasheet for details. + + Valid values: + - 1: enabled + - 0: disabled diff --git a/Documentation/ABI/testing/sysfs-class-stm b/Documentation/ABI/testing/sysfs-class-stm new file mode 100644 index 000000000..c9aa4f3fc --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-stm @@ -0,0 +1,14 @@ +What: /sys/class/stm//masters +Date: June 2015 +KernelVersion: 4.3 +Contact: Alexander Shishkin +Description: + Shows first and last available to software master numbers on + this STM device. + +What: /sys/class/stm//channels +Date: June 2015 +KernelVersion: 4.3 +Contact: Alexander Shishkin +Description: + Shows the number of channels per master on this STM device. diff --git a/Documentation/ABI/testing/sysfs-class-stm_source b/Documentation/ABI/testing/sysfs-class-stm_source new file mode 100644 index 000000000..57b8dd39b --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-stm_source @@ -0,0 +1,11 @@ +What: /sys/class/stm_source//stm_source_link +Date: June 2015 +KernelVersion: 4.3 +Contact: Alexander Shishkin +Description: + stm_source device linkage to stm device, where its tracing data + is directed. Reads return an existing connection or "" if + this stm_source is not connected to any stm device yet. + Write an existing (registered) stm device's name here to + connect that device. If a device is already connected to this + stm_source, it will first be disconnected. diff --git a/Documentation/ABI/testing/sysfs-driver-hid-corsair b/Documentation/ABI/testing/sysfs-driver-hid-corsair new file mode 100644 index 000000000..b8827f0f1 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-hid-corsair @@ -0,0 +1,15 @@ +What: /sys/bus/drivers/corsair//macro_mode +Date: August 2015 +KernelVersion: 4.2 +Contact: Clement Vuchener +Description: Get/set the current playback mode. "SW" for software mode + where G-keys triggers their regular key codes. "HW" for + hardware playback mode where the G-keys play their macro + from the on-board memory. + + +What: /sys/bus/drivers/corsair//current_profile +Date: August 2015 +KernelVersion: 4.2 +Contact: Clement Vuchener +Description: Get/set the current selected profile. Values are from 1 to 3. diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-arvo b/Documentation/ABI/testing/sysfs-driver-hid-roccat-arvo deleted file mode 100644 index 55e281b00..000000000 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-arvo +++ /dev/null @@ -1,53 +0,0 @@ -What: /sys/bus/usb/devices/-:./::./arvo/roccatarvo/actual_profile -Date: Januar 2011 -Contact: Stefan Achatz -Description: The integer value of this attribute ranges from 1-5. - When read, this attribute returns the number of the actual - profile which is also the profile that's active on device startup. - When written this attribute activates the selected profile - immediately. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./arvo/roccatarvo/button -Date: Januar 2011 -Contact: Stefan Achatz -Description: The keyboard can store short macros with consist of 1 button with - several modifier keys internally. - When written, this file lets one set the sequence for a specific - button for a specific profile. Button and profile numbers are - included in written data. The data has to be 24 bytes long. - This file is writeonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./arvo/roccatarvo/info -Date: Januar 2011 -Contact: Stefan Achatz -Description: When read, this file returns some info about the device like the - installed firmware version. - The size of the data is 8 bytes in size. - This file is readonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./arvo/roccatarvo/key_mask -Date: Januar 2011 -Contact: Stefan Achatz -Description: The keyboard lets the user deactivate 5 certain keys like the - windows and application keys, to protect the user from the outcome - of accidentally pressing them. - The integer value of this attribute has bits 0-4 set depending - on the state of the corresponding key. - When read, this file returns the current state of the buttons. - When written, the given buttons are activated/deactivated - immediately. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./arvo/roccatarvo/mode_key -Date: Januar 2011 -Contact: Stefan Achatz -Description: The keyboard has a condensed layout without num-lock key. - Instead it uses a mode-key which activates a gaming mode where - the assignment of the number block changes. - The integer value of this attribute ranges from 0 (OFF) to 1 (ON). - When read, this file returns the actual state of the key. - When written, the key is activated/deactivated immediately. -Users: http://roccat.sourceforge.net diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-isku b/Documentation/ABI/testing/sysfs-driver-hid-roccat-isku deleted file mode 100644 index c601d0f2a..000000000 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-isku +++ /dev/null @@ -1,153 +0,0 @@ -What: /sys/bus/usb/devices/-:./::./isku/roccatisku/actual_profile -Date: June 2011 -Contact: Stefan Achatz -Description: The integer value of this attribute ranges from 0-4. - When read, this attribute returns the number of the actual - profile. This value is persistent, so its equivalent to the - profile that's active when the device is powered on next time. - When written, this file sets the number of the startup profile - and the device activates this profile immediately. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./isku/roccatisku/info -Date: June 2011 -Contact: Stefan Achatz -Description: When read, this file returns general data like firmware version. - The data is 6 bytes long. - This file is readonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./isku/roccatisku/key_mask -Date: June 2011 -Contact: Stefan Achatz -Description: When written, this file lets one deactivate certain keys like - windows and application keys, to prevent accidental presses. - Profile number for which this settings occur is included in - written data. The data has to be 6 bytes long. - Before reading this file, control has to be written to select - which profile to read. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./isku/roccatisku/keys_capslock -Date: June 2011 -Contact: Stefan Achatz -Description: When written, this file lets one set the function of the - capslock key for a specific profile. Profile number is included - in written data. The data has to be 6 bytes long. - Before reading this file, control has to be written to select - which profile to read. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./isku/roccatisku/keys_easyzone -Date: June 2011 -Contact: Stefan Achatz -Description: When written, this file lets one set the function of the - easyzone keys for a specific profile. Profile number is included - in written data. The data has to be 65 bytes long. - Before reading this file, control has to be written to select - which profile to read. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./isku/roccatisku/keys_function -Date: June 2011 -Contact: Stefan Achatz -Description: When written, this file lets one set the function of the - function keys for a specific profile. Profile number is included - in written data. The data has to be 41 bytes long. - Before reading this file, control has to be written to select - which profile to read. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./isku/roccatisku/keys_macro -Date: June 2011 -Contact: Stefan Achatz -Description: When written, this file lets one set the function of the macro - keys for a specific profile. Profile number is included in - written data. The data has to be 35 bytes long. - Before reading this file, control has to be written to select - which profile to read. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./isku/roccatisku/keys_media -Date: June 2011 -Contact: Stefan Achatz -Description: When written, this file lets one set the function of the media - keys for a specific profile. Profile number is included in - written data. The data has to be 29 bytes long. - Before reading this file, control has to be written to select - which profile to read. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./isku/roccatisku/keys_thumbster -Date: June 2011 -Contact: Stefan Achatz -Description: When written, this file lets one set the function of the - thumbster keys for a specific profile. Profile number is included - in written data. The data has to be 23 bytes long. - Before reading this file, control has to be written to select - which profile to read. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./isku/roccatisku/last_set -Date: June 2011 -Contact: Stefan Achatz -Description: When written, this file lets one set the time in secs since - epoch in which the last configuration took place. - The data has to be 20 bytes long. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./isku/roccatisku/light -Date: June 2011 -Contact: Stefan Achatz -Description: When written, this file lets one set the backlight intensity for - a specific profile. Profile number is included in written data. - The data has to be 10 bytes long for Isku, IskuFX needs 16 bytes - of data. - Before reading this file, control has to be written to select - which profile to read. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./isku/roccatisku/macro -Date: June 2011 -Contact: Stefan Achatz -Description: When written, this file lets one store macros with max 500 - keystrokes for a specific button for a specific profile. - Button and profile numbers are included in written data. - The data has to be 2083 bytes long. - Before reading this file, control has to be written to select - which profile and key to read. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./isku/roccatisku/reset -Date: November 2012 -Contact: Stefan Achatz -Description: When written, this file lets one reset the device. - The data has to be 3 bytes long. - This file is writeonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./isku/roccatisku/control -Date: June 2011 -Contact: Stefan Achatz -Description: When written, this file lets one select which data from which - profile will be read next. The data has to be 3 bytes long. - This file is writeonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./isku/roccatisku/talk -Date: June 2011 -Contact: Stefan Achatz -Description: When written, this file lets one trigger easyshift functionality - from the host. - The data has to be 16 bytes long. - This file is writeonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./isku/roccatisku/talkfx -Date: February 2013 -Contact: Stefan Achatz -Description: When written, this file lets one trigger temporary color schemes - from the host. - The data has to be 16 bytes long. - This file is writeonly. -Users: http://roccat.sourceforge.net diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus b/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus deleted file mode 100644 index 7bd776f9c..000000000 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus +++ /dev/null @@ -1,96 +0,0 @@ -What: /sys/bus/usb/devices/-:./::./koneplus/roccatkoneplus/actual_profile -Date: October 2010 -Contact: Stefan Achatz -Description: The integer value of this attribute ranges from 0-4. - When read, this attribute returns the number of the actual - profile. This value is persistent, so its equivalent to the - profile that's active when the mouse is powered on next time. - When written, this file sets the number of the startup profile - and the mouse activates this profile immediately. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./koneplus/roccatkoneplus/info -Date: November 2012 -Contact: Stefan Achatz -Description: When read, this file returns general data like firmware version. - When written, the device can be reset. - The data is 8 bytes long. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./koneplus/roccatkoneplus/macro -Date: October 2010 -Contact: Stefan Achatz -Description: The mouse can store a macro with max 500 key/button strokes - internally. - When written, this file lets one set the sequence for a specific - button for a specific profile. Button and profile numbers are - included in written data. The data has to be 2082 bytes long. - This file is writeonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./koneplus/roccatkoneplus/profile_buttons -Date: August 2010 -Contact: Stefan Achatz -Description: The mouse can store 5 profiles which can be switched by the - press of a button. A profile is split in settings and buttons. - profile_buttons holds information about button layout. - When written, this file lets one write the respective profile - buttons back to the mouse. The data has to be 77 bytes long. - The mouse will reject invalid data. - Which profile to write is determined by the profile number - contained in the data. - Before reading this file, control has to be written to select - which profile to read. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./koneplus/roccatkoneplus/profile_settings -Date: October 2010 -Contact: Stefan Achatz -Description: The mouse can store 5 profiles which can be switched by the - press of a button. A profile is split in settings and buttons. - profile_settings holds information like resolution, sensitivity - and light effects. - When written, this file lets one write the respective profile - settings back to the mouse. The data has to be 43 bytes long. - The mouse will reject invalid data. - Which profile to write is determined by the profile number - contained in the data. - Before reading this file, control has to be written to select - which profile to read. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./koneplus/roccatkoneplus/sensor -Date: October 2010 -Contact: Stefan Achatz -Description: The mouse has a tracking- and a distance-control-unit. These - can be activated/deactivated and the lift-off distance can be - set. The data has to be 6 bytes long. - This file is writeonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./koneplus/roccatkoneplus/talk -Date: May 2011 -Contact: Stefan Achatz -Description: Used to active some easy* functions of the mouse from outside. - The data has to be 16 bytes long. - This file is writeonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./koneplus/roccatkoneplus/tcu -Date: October 2010 -Contact: Stefan Achatz -Description: When written a calibration process for the tracking control unit - can be initiated/cancelled. Also lets one read/write sensor - registers. - The data has to be 4 bytes long. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./koneplus/roccatkoneplus/tcu_image -Date: October 2010 -Contact: Stefan Achatz -Description: When read the mouse returns a 30x30 pixel image of the - sampled underground. This works only in the course of a - calibration process initiated with tcu. - The returned data is 1028 bytes in size. - This file is readonly. -Users: http://roccat.sourceforge.net diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-konepure b/Documentation/ABI/testing/sysfs-driver-hid-roccat-konepure deleted file mode 100644 index 41a9b7fbf..000000000 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-konepure +++ /dev/null @@ -1,105 +0,0 @@ -What: /sys/bus/usb/devices/-:./::./konepure/roccatkonepure/actual_profile -Date: December 2012 -Contact: Stefan Achatz -Description: The mouse can store 5 profiles which can be switched by the - press of a button. actual_profile holds number of actual profile. - This value is persistent, so its value determines the profile - that's active when the mouse is powered on next time. - When written, the mouse activates the set profile immediately. - The data has to be 3 bytes long. - The mouse will reject invalid data. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./konepure/roccatkonepure/control -Date: December 2012 -Contact: Stefan Achatz -Description: When written, this file lets one select which data from which - profile will be read next. The data has to be 3 bytes long. - This file is writeonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./konepure/roccatkonepure/info -Date: December 2012 -Contact: Stefan Achatz -Description: When read, this file returns general data like firmware version. - When written, the device can be reset. - The data is 6 bytes long. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./konepure/roccatkonepure/macro -Date: December 2012 -Contact: Stefan Achatz -Description: The mouse can store a macro with max 500 key/button strokes - internally. - When written, this file lets one set the sequence for a specific - button for a specific profile. Button and profile numbers are - included in written data. The data has to be 2082 bytes long. - This file is writeonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./konepure/roccatkonepure/profile_buttons -Date: December 2012 -Contact: Stefan Achatz -Description: The mouse can store 5 profiles which can be switched by the - press of a button. A profile is split in settings and buttons. - profile_buttons holds information about button layout. - When written, this file lets one write the respective profile - buttons back to the mouse. The data has to be 59 bytes long. - The mouse will reject invalid data. - Which profile to write is determined by the profile number - contained in the data. - Before reading this file, control has to be written to select - which profile to read. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./konepure/roccatkonepure/profile_settings -Date: December 2012 -Contact: Stefan Achatz -Description: The mouse can store 5 profiles which can be switched by the - press of a button. A profile is split in settings and buttons. - profile_settings holds information like resolution, sensitivity - and light effects. - When written, this file lets one write the respective profile - settings back to the mouse. The data has to be 31 bytes long. - The mouse will reject invalid data. - Which profile to write is determined by the profile number - contained in the data. - Before reading this file, control has to be written to select - which profile to read. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./konepure/roccatkonepure/sensor -Date: December 2012 -Contact: Stefan Achatz -Description: The mouse has a tracking- and a distance-control-unit. These - can be activated/deactivated and the lift-off distance can be - set. The data has to be 6 bytes long. - This file is writeonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./konepure/roccatkonepure/talk -Date: December 2012 -Contact: Stefan Achatz -Description: Used to active some easy* functions of the mouse from outside. - The data has to be 16 bytes long. - This file is writeonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./konepure/roccatkonepure/tcu -Date: December 2012 -Contact: Stefan Achatz -Description: When written a calibration process for the tracking control unit - can be initiated/cancelled. Also lets one read/write sensor - registers. - The data has to be 4 bytes long. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./konepure/roccatkonepure/tcu_image -Date: December 2012 -Contact: Stefan Achatz -Description: When read the mouse returns a 30x30 pixel image of the - sampled underground. This works only in the course of a - calibration process initiated with tcu. - The returned data is 1028 bytes in size. - This file is readonly. -Users: http://roccat.sourceforge.net diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus b/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus deleted file mode 100644 index a10404f15..000000000 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus +++ /dev/null @@ -1,49 +0,0 @@ -What: /sys/bus/usb/devices/-:./::./kovaplus/roccatkovaplus/actual_profile -Date: January 2011 -Contact: Stefan Achatz -Description: The integer value of this attribute ranges from 0-4. - When read, this attribute returns the number of the active - profile. - When written, the mouse activates this profile immediately. - The profile that's active when powered down is the same that's - active when the mouse is powered on. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./kovaplus/roccatkovaplus/info -Date: November 2012 -Contact: Stefan Achatz -Description: When read, this file returns general data like firmware version. - When written, the device can be reset. - The data is 6 bytes long. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./kovaplus/roccatkovaplus/profile_buttons -Date: January 2011 -Contact: Stefan Achatz -Description: The mouse can store 5 profiles which can be switched by the - press of a button. A profile is split in settings and buttons. - profile_buttons holds information about button layout. - When written, this file lets one write the respective profile - buttons back to the mouse. The data has to be 23 bytes long. - The mouse will reject invalid data. - Which profile to write is determined by the profile number - contained in the data. - Before reading this file, control has to be written to select - which profile to read. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./kovaplus/roccatkovaplus/profile_settings -Date: January 2011 -Contact: Stefan Achatz -Description: The mouse can store 5 profiles which can be switched by the - press of a button. A profile is split in settings and buttons. - profile_settings holds information like resolution, sensitivity - and light effects. - When written, this file lets one write the respective profile - settings back to the mouse. The data has to be 16 bytes long. - The mouse will reject invalid data. - Which profile to write is determined by the profile number - contained in the data. - Before reading this file, control has to be written to select - which profile to read. -Users: http://roccat.sourceforge.net diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-lua b/Documentation/ABI/testing/sysfs-driver-hid-roccat-lua deleted file mode 100644 index 31c6c4c8b..000000000 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-lua +++ /dev/null @@ -1,7 +0,0 @@ -What: /sys/bus/usb/devices/-:./control -Date: October 2012 -Contact: Stefan Achatz -Description: When written, cpi, button and light settings can be configured. - When read, actual cpi setting and sensor data are returned. - The data has to be 8 bytes long. -Users: http://roccat.sourceforge.net diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra b/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra deleted file mode 100644 index 9fa9de30d..000000000 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra +++ /dev/null @@ -1,49 +0,0 @@ -What: /sys/bus/usb/devices/-:./::./pyra/roccatpyra/info -Date: November 2012 -Contact: Stefan Achatz -Description: When read, this file returns general data like firmware version. - When written, the device can be reset. - The data is 6 bytes long. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./pyra/roccatpyra/profile_settings -Date: August 2010 -Contact: Stefan Achatz -Description: The mouse can store 5 profiles which can be switched by the - press of a button. A profile is split in settings and buttons. - profile_settings holds information like resolution, sensitivity - and light effects. - When written, this file lets one write the respective profile - settings back to the mouse. The data has to be 13 bytes long. - The mouse will reject invalid data. - Which profile to write is determined by the profile number - contained in the data. - Before reading this file, control has to be written to select - which profile to read. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./pyra/roccatpyra/profile_buttons -Date: August 2010 -Contact: Stefan Achatz -Description: The mouse can store 5 profiles which can be switched by the - press of a button. A profile is split in settings and buttons. - profile_buttons holds information about button layout. - When written, this file lets one write the respective profile - buttons back to the mouse. The data has to be 19 bytes long. - The mouse will reject invalid data. - Which profile to write is determined by the profile number - contained in the data. - Before reading this file, control has to be written to select - which profile to read. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./pyra/roccatpyra/settings -Date: August 2010 -Contact: Stefan Achatz -Description: When read, this file returns the settings stored in the mouse. - The size of the data is 3 bytes and holds information on the - startup_profile. - When written, this file lets write settings back to the mouse. - The data has to be 3 bytes long. The mouse will reject invalid - data. -Users: http://roccat.sourceforge.net diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-ryos b/Documentation/ABI/testing/sysfs-driver-hid-roccat-ryos deleted file mode 100644 index 1d6a8cf9d..000000000 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-ryos +++ /dev/null @@ -1,178 +0,0 @@ -What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/control -Date: October 2013 -Contact: Stefan Achatz -Description: When written, this file lets one select which data from which - profile will be read next. The data has to be 3 bytes long. - This file is writeonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/profile -Date: October 2013 -Contact: Stefan Achatz -Description: The mouse can store 5 profiles which can be switched by the - press of a button. profile holds index of actual profile. - This value is persistent, so its value determines the profile - that's active when the device is powered on next time. - When written, the device activates the set profile immediately. - The data has to be 3 bytes long. - The device will reject invalid data. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/keys_primary -Date: October 2013 -Contact: Stefan Achatz -Description: When written, this file lets one set the default of all keys for - a specific profile. Profile index is included in written data. - The data has to be 125 bytes long. - Before reading this file, control has to be written to select - which profile to read. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/keys_function -Date: October 2013 -Contact: Stefan Achatz -Description: When written, this file lets one set the function of the - function keys for a specific profile. Profile index is included - in written data. The data has to be 95 bytes long. - Before reading this file, control has to be written to select - which profile to read. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/keys_macro -Date: October 2013 -Contact: Stefan Achatz -Description: When written, this file lets one set the function of the macro - keys for a specific profile. Profile index is included in - written data. The data has to be 35 bytes long. - Before reading this file, control has to be written to select - which profile to read. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/keys_thumbster -Date: October 2013 -Contact: Stefan Achatz -Description: When written, this file lets one set the function of the - thumbster keys for a specific profile. Profile index is included - in written data. The data has to be 23 bytes long. - Before reading this file, control has to be written to select - which profile to read. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/keys_extra -Date: October 2013 -Contact: Stefan Achatz -Description: When written, this file lets one set the function of the - capslock and function keys for a specific profile. Profile index - is included in written data. The data has to be 8 bytes long. - Before reading this file, control has to be written to select - which profile to read. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/keys_easyzone -Date: October 2013 -Contact: Stefan Achatz -Description: When written, this file lets one set the function of the - easyzone keys for a specific profile. Profile index is included - in written data. The data has to be 294 bytes long. - Before reading this file, control has to be written to select - which profile to read. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/key_mask -Date: October 2013 -Contact: Stefan Achatz -Description: When written, this file lets one deactivate certain keys like - windows and application keys, to prevent accidental presses. - Profile index for which this settings occur is included in - written data. The data has to be 6 bytes long. - Before reading this file, control has to be written to select - which profile to read. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/light -Date: October 2013 -Contact: Stefan Achatz -Description: When written, this file lets one set the backlight intensity for - a specific profile. Profile index is included in written data. - This attribute is only valid for the glow and pro variant. - The data has to be 16 bytes long. - Before reading this file, control has to be written to select - which profile to read. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/macro -Date: October 2013 -Contact: Stefan Achatz -Description: When written, this file lets one store macros with max 480 - keystrokes for a specific button for a specific profile. - Button and profile indexes are included in written data. - The data has to be 2002 bytes long. - Before reading this file, control has to be written to select - which profile and key to read. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/info -Date: October 2013 -Contact: Stefan Achatz -Description: When read, this file returns general data like firmware version. - The data is 8 bytes long. - This file is readonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/reset -Date: October 2013 -Contact: Stefan Achatz -Description: When written, this file lets one reset the device. - The data has to be 3 bytes long. - This file is writeonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/talk -Date: October 2013 -Contact: Stefan Achatz -Description: When written, this file lets one trigger easyshift functionality - from the host. - The data has to be 16 bytes long. - This file is writeonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/light_control -Date: October 2013 -Contact: Stefan Achatz -Description: When written, this file lets one switch between stored and custom - light settings. - This attribute is only valid for the pro variant. - The data has to be 8 bytes long. - This file is writeonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/stored_lights -Date: October 2013 -Contact: Stefan Achatz -Description: When written, this file lets one set per-key lighting for different - layers. - This attribute is only valid for the pro variant. - The data has to be 1382 bytes long. - Before reading this file, control has to be written to select - which profile to read. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/custom_lights -Date: October 2013 -Contact: Stefan Achatz -Description: When written, this file lets one set the actual per-key lighting. - This attribute is only valid for the pro variant. - The data has to be 20 bytes long. - This file is writeonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./ryos/roccatryos/light_macro -Date: October 2013 -Contact: Stefan Achatz -Description: When written, this file lets one set a light macro that is looped - whenever the device gets in dimness mode. - This attribute is only valid for the pro variant. - The data has to be 2002 bytes long. - Before reading this file, control has to be written to select - which profile to read. -Users: http://roccat.sourceforge.net diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-savu b/Documentation/ABI/testing/sysfs-driver-hid-roccat-savu deleted file mode 100644 index f1e02a98b..000000000 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-savu +++ /dev/null @@ -1,76 +0,0 @@ -What: /sys/bus/usb/devices/-:./::./savu/roccatsavu/buttons -Date: Mai 2012 -Contact: Stefan Achatz -Description: The mouse can store 5 profiles which can be switched by the - press of a button. A profile is split into general settings and - button settings. buttons holds informations about button layout. - When written, this file lets one write the respective profile - buttons to the mouse. The data has to be 47 bytes long. - The mouse will reject invalid data. - Which profile to write is determined by the profile number - contained in the data. - Before reading this file, control has to be written to select - which profile to read. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./savu/roccatsavu/control -Date: Mai 2012 -Contact: Stefan Achatz -Description: When written, this file lets one select which data from which - profile will be read next. The data has to be 3 bytes long. - This file is writeonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./savu/roccatsavu/general -Date: Mai 2012 -Contact: Stefan Achatz -Description: The mouse can store 5 profiles which can be switched by the - press of a button. A profile is split into general settings and - button settings. profile holds informations like resolution, sensitivity - and light effects. - When written, this file lets one write the respective profile - settings back to the mouse. The data has to be 43 bytes long. - The mouse will reject invalid data. - Which profile to write is determined by the profile number - contained in the data. - This file is writeonly. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./savu/roccatsavu/info -Date: Mai 2012 -Contact: Stefan Achatz -Description: When read, this file returns general data like firmware version. - When written, the device can be reset. - The data is 8 bytes long. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./savu/roccatsavu/macro -Date: Mai 2012 -Contact: Stefan Achatz -Description: When written, this file lets one store macros with max 500 - keystrokes for a specific button for a specific profile. - Button and profile numbers are included in written data. - The data has to be 2083 bytes long. - Before reading this file, control has to be written to select - which profile and key to read. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./savu/roccatsavu/profile -Date: Mai 2012 -Contact: Stefan Achatz -Description: The mouse can store 5 profiles which can be switched by the - press of a button. profile holds number of actual profile. - This value is persistent, so its value determines the profile - that's active when the mouse is powered on next time. - When written, the mouse activates the set profile immediately. - The data has to be 3 bytes long. - The mouse will reject invalid data. -Users: http://roccat.sourceforge.net - -What: /sys/bus/usb/devices/-:./::./savu/roccatsavu/sensor -Date: July 2012 -Contact: Stefan Achatz -Description: The mouse has a Avago ADNS-3090 sensor. - This file allows reading and writing of the mouse sensors registers. - The data has to be 4 bytes long. -Users: http://roccat.sourceforge.net diff --git a/Documentation/ABI/testing/sysfs-driver-ppi b/Documentation/ABI/testing/sysfs-driver-ppi index 7d1435bc9..9921ef285 100644 --- a/Documentation/ABI/testing/sysfs-driver-ppi +++ b/Documentation/ABI/testing/sysfs-driver-ppi @@ -1,4 +1,4 @@ -What: /sys/devices/pnp0//ppi/ +What: /sys/class/tpm/tpmX/ppi/ Date: August 2012 Kernel Version: 3.6 Contact: xiaoyan.zhang@intel.com @@ -8,9 +8,14 @@ Description: folder makes sense. The folder path can be got by command 'find /sys/ -name 'pcrs''. For the detail information of PPI, please refer to the PPI specification from + http://www.trustedcomputinggroup.org/ -What: /sys/devices/pnp0//ppi/version + In Linux 4.2 ppi was moved to the character device directory. + A symlink from tpmX/device/ppi to tpmX/ppi to provide backwards + compatibility. + +What: /sys/class/tpm/tpmX/ppi/version Date: August 2012 Contact: xiaoyan.zhang@intel.com Description: @@ -18,7 +23,7 @@ Description: platform. This file is readonly. -What: /sys/devices/pnp0//ppi/request +What: /sys/class/tpm/tpmX/ppi/request Date: August 2012 Contact: xiaoyan.zhang@intel.com Description: @@ -28,7 +33,7 @@ Description: integer value range from 1 to 160, and 0 means no request. This file can be read and written. -What: /sys/devices/pnp0/00:/ppi/response +What: /sys/class/tpm/tpmX/ppi/response Date: August 2012 Contact: xiaoyan.zhang@intel.com Description: @@ -37,7 +42,7 @@ Description: : ". This file is readonly. -What: /sys/devices/pnp0//ppi/transition_action +What: /sys/class/tpm/tpmX/ppi/transition_action Date: August 2012 Contact: xiaoyan.zhang@intel.com Description: @@ -47,7 +52,7 @@ Description: description>". This file is readonly. -What: /sys/devices/pnp0//ppi/tcg_operations +What: /sys/class/tpm/tpmX/ppi/tcg_operations Date: August 2012 Contact: xiaoyan.zhang@intel.com Description: @@ -58,7 +63,7 @@ Description: This attribute is only supported by PPI version 1.2+. This file is readonly. -What: /sys/devices/pnp0//ppi/vs_operations +What: /sys/class/tpm/tpmX/ppi/vs_operations Date: August 2012 Contact: xiaoyan.zhang@intel.com Description: diff --git a/Documentation/ABI/testing/sysfs-driver-st b/Documentation/ABI/testing/sysfs-driver-st new file mode 100644 index 000000000..ba5d77008 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-st @@ -0,0 +1,12 @@ +What: /sys/bus/scsi/drivers/st/debug_flag +Date: October 2015 +Kernel Version: ?.? +Contact: shane.seymour@hpe.com +Description: + This file allows you to turn debug output from the st driver + off if you write a '0' to the file or on if you write a '1'. + Note that debug output requires that the module be compiled + with the #define DEBUG set to a non-zero value (this is the + default). If DEBUG is set to 0 then this file will not + appear in sysfs as its presence is conditional upon debug + output support being compiled into the module. diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index 2c4cc4200..0345f2d1c 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -80,3 +80,15 @@ Date: February 2015 Contact: "Jaegeuk Kim" Description: Controls the trimming rate in batch mode. + +What: /sys/fs/f2fs//cp_interval +Date: October 2015 +Contact: "Jaegeuk Kim" +Description: + Controls the checkpoint timing. + +What: /sys/fs/f2fs//ra_nid_pages +Date: October 2015 +Contact: "Chao Yu" +Description: + Controls the count of nid pages to be readaheaded. diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power index f45518163..50b368d49 100644 --- a/Documentation/ABI/testing/sysfs-power +++ b/Documentation/ABI/testing/sysfs-power @@ -256,3 +256,15 @@ Description: Writing a "1" enables this printing while writing a "0" disables it. The default value is "0". Reading from this file will display the current value. + +What: /sys/power/pm_wakeup_irq +Date: April 2015 +Contact: Alexandra Yates +Description: + The /sys/power/pm_wakeup_irq file reports to user space the IRQ + number of the first wakeup interrupt (that is, the first + interrupt from an IRQ line armed for system wakeup) seen by the + kernel during the most recent system suspend/resume cycle. + + This output is useful for system wakeup diagnostics of spurious + wakeup interrupts. diff --git a/Documentation/Changes b/Documentation/Changes index f447f0516..ec97b77c8 100644 --- a/Documentation/Changes +++ b/Documentation/Changes @@ -44,6 +44,7 @@ o grub 0.93 # grub --version || grub-insta o mcelog 0.6 # mcelog --version o iptables 1.4.2 # iptables -V o openssl & libcrypto 1.0.0 # openssl version +o bc 1.06.95 # bc --version Kernel compilation diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt index 55b70b903..d69b3fc64 100644 --- a/Documentation/DMA-API-HOWTO.txt +++ b/Documentation/DMA-API-HOWTO.txt @@ -681,6 +681,11 @@ or: as appropriate. +PLEASE NOTE: The 'nents' argument to dma_sync_sg_for_cpu() and + dma_sync_sg_for_device() must be the same passed to + dma_map_sg(). It is _NOT_ the count returned by + dma_map_sg(). + After the last DMA transfer call one of the DMA unmap routines dma_unmap_{single,sg}(). If you don't touch the data from the first dma_map_*() call till dma_unmap_*(), then you don't have to call the diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt index edccacd4f..1e98a7e6b 100644 --- a/Documentation/DMA-API.txt +++ b/Documentation/DMA-API.txt @@ -141,19 +141,6 @@ memory back to the pool before you destroy it. Part Ic - DMA addressing limitations ------------------------------------ -int -dma_supported(struct device *dev, u64 mask) - -Checks to see if the device can support DMA to the memory described by -mask. - -Returns: 1 if it can and 0 if it can't. - -Notes: This routine merely tests to see if the mask is possible. It -won't change the current mask settings. It is more intended as an -internal API for use by the platform than an external API for use by -driver writers. - int dma_set_mask_and_coherent(struct device *dev, u64 mask) @@ -340,7 +327,7 @@ accessed sg->address and sg->length as shown above. void dma_unmap_sg(struct device *dev, struct scatterlist *sg, - int nhwentries, enum dma_data_direction direction) + int nents, enum dma_data_direction direction) Unmap the previously mapped scatter/gather list. All the parameters must be the same as those and passed in to the scatter/gather mapping @@ -356,10 +343,10 @@ void dma_sync_single_for_device(struct device *dev, dma_addr_t dma_handle, size_t size, enum dma_data_direction direction) void -dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg, int nelems, +dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg, int nents, enum dma_data_direction direction) void -dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg, int nelems, +dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg, int nents, enum dma_data_direction direction) Synchronise a single contiguous or scatter/gather mapping for the CPU diff --git a/Documentation/DocBook/.gitignore b/Documentation/DocBook/.gitignore index 7ebd5465d..e05da3f7a 100644 --- a/Documentation/DocBook/.gitignore +++ b/Documentation/DocBook/.gitignore @@ -11,5 +11,7 @@ *.png *.gif *.svg +*.proc +*.db media-indices.tmpl media-entities.tmpl diff --git a/Documentation/DocBook/80211.tmpl b/Documentation/DocBook/80211.tmpl index aac9357d4..f9b9ad789 100644 --- a/Documentation/DocBook/80211.tmpl +++ b/Documentation/DocBook/80211.tmpl @@ -154,8 +154,9 @@ !Finclude/net/cfg80211.h cfg80211_scan_request !Finclude/net/cfg80211.h cfg80211_scan_done !Finclude/net/cfg80211.h cfg80211_bss -!Finclude/net/cfg80211.h cfg80211_inform_bss_width_frame -!Finclude/net/cfg80211.h cfg80211_inform_bss_width +!Finclude/net/cfg80211.h cfg80211_inform_bss +!Finclude/net/cfg80211.h cfg80211_inform_bss_frame_data +!Finclude/net/cfg80211.h cfg80211_inform_bss_data !Finclude/net/cfg80211.h cfg80211_unlink_bss !Finclude/net/cfg80211.h cfg80211_find_ie !Finclude/net/cfg80211.h ieee80211_bss_get_ie diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index 93eff6438..91f6d89bb 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -14,7 +14,7 @@ DOCBOOKS := z8530book.xml device-drivers.xml \ genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \ 80211.xml debugobjects.xml sh.xml regulator.xml \ alsa-driver-api.xml writing-an-alsa-driver.xml \ - tracepoint.xml drm.xml media_api.xml w1.xml \ + tracepoint.xml gpu.xml media_api.xml w1.xml \ writing_musb_glue_layer.xml crypto-API.xml iio.xml include Documentation/DocBook/media/Makefile @@ -69,6 +69,12 @@ installmandocs: mandocs KERNELDOCXMLREF = $(srctree)/scripts/kernel-doc-xml-ref KERNELDOC = $(srctree)/scripts/kernel-doc DOCPROC = $(objtree)/scripts/docproc +CHECK_LC_CTYPE = $(objtree)/scripts/check-lc_ctype + +# Use a fixed encoding - UTF-8 if the C library has support built-in +# or ASCII if not +LC_CTYPE := $(call try-run, LC_CTYPE=C.UTF-8 $(CHECK_LC_CTYPE),C.UTF-8,C) +export LC_CTYPE XMLTOFLAGS = -m $(srctree)/$(src)/stylesheet.xsl XMLTOFLAGS += --skip-validation diff --git a/Documentation/DocBook/alsa-driver-api.tmpl b/Documentation/DocBook/alsa-driver-api.tmpl index e94a10bb4..53f439dcc 100644 --- a/Documentation/DocBook/alsa-driver-api.tmpl +++ b/Documentation/DocBook/alsa-driver-api.tmpl @@ -112,6 +112,8 @@ !Esound/soc/soc-devres.c !Esound/soc/soc-io.c !Esound/soc/soc-pcm.c +!Esound/soc/soc-ops.c +!Esound/soc/soc-compress.c ASoC DAPM API !Esound/soc/soc-dapm.c diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index 1d6008d51..42a2d8593 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -221,6 +221,9 @@ X!Isound/sound_firmware.c Media Devices Video2Linux devices +!Iinclude/media/tuner.h +!Iinclude/media/tuner-types.h +!Iinclude/media/tveeprom.h !Iinclude/media/v4l2-async.h !Iinclude/media/v4l2-ctrls.h !Iinclude/media/v4l2-dv-timings.h @@ -231,6 +234,7 @@ X!Isound/sound_firmware.c !Iinclude/media/v4l2-of.h !Iinclude/media/v4l2-subdev.h !Iinclude/media/videobuf2-core.h +!Iinclude/media/videobuf2-v4l2.h !Iinclude/media/videobuf2-memops.h Digital TV (DVB) devices @@ -239,15 +243,82 @@ X!Isound/sound_firmware.c !Idrivers/media/dvb-core/dvb_math.h !Idrivers/media/dvb-core/dvb_ringbuffer.h !Idrivers/media/dvb-core/dvbdev.h - - Remote Controller devices + Digital TV Demux API + The kernel demux API defines a driver-internal interface for + registering low-level, hardware specific driver to a hardware + independent demux layer. It is only of interest for Digital TV + device driver writers. The header file for this API is named + demux.h and located in + drivers/media/dvb-core. + + The demux API should be implemented for each demux in the + system. It is used to select the TS source of a demux and to manage + the demux resources. When the demux client allocates a resource via + the demux API, it receives a pointer to the API of that + resource. + Each demux receives its TS input from a DVB front-end or from + memory, as set via this demux API. In a system with more than one + front-end, the API can be used to select one of the DVB front-ends + as a TS source for a demux, unless this is fixed in the HW platform. + The demux API only controls front-ends regarding to their connections + with demuxes; the APIs used to set the other front-end parameters, + such as tuning, are not defined in this document. + The functions that implement the abstract interface demux should + be defined static or module private and registered to the Demux + core for external access. It is not necessary to implement every + function in the struct dmx_demux. For example, + a demux interface might support Section filtering, but not PES + filtering. The API client is expected to check the value of any + function pointer before calling the function: the value of NULL means + that the “function is not available”. + Whenever the functions of the demux API modify shared data, + the possibilities of lost update and race condition problems should + be addressed, e.g. by protecting parts of code with mutexes. + Note that functions called from a bottom half context must not + sleep. Even a simple memory allocation without using GFP_ATOMIC can + result in a kernel thread being put to sleep if swapping is needed. + For example, the Linux kernel calls the functions of a network device + interface from a bottom half context. Thus, if a demux API function + is called from network device code, the function must not sleep. + + + +
+ Demux Callback API + This kernel-space API comprises the callback functions that + deliver filtered data to the demux client. Unlike the other DVB + kABIs, these functions are provided by the client and called from + the demux code. + The function pointers of this abstract interface are not + packed into a structure as in the other demux APIs, because the + callback functions are registered and used independent of each + other. As an example, it is possible for the API client to provide + several callback functions for receiving TS packets and no + callbacks for PES packets or sections. + The functions that implement the callback API need not be + re-entrant: when a demux driver calls one of these functions, + the driver is not allowed to call the function again before + the original call returns. If a callback is triggered by a + hardware interrupt, it is recommended to use the Linux + “bottom half” mechanism or start a tasklet instead of + making the callback function call directly from a hardware + interrupt. + This mechanism is implemented by + dmx_ts_cb() and + dmx_section_cb(). +
+ +!Idrivers/media/dvb-core/demux.h + + Remote Controller devices !Iinclude/media/rc-core.h - - Media Controller devices +!Iinclude/media/lirc_dev.h + + Media Controller devices !Iinclude/media/media-device.h !Iinclude/media/media-devnode.h !Iinclude/media/media-entity.h - + diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl deleted file mode 100644 index 9ddf8c6cb..000000000 --- a/Documentation/DocBook/drm.tmpl +++ /dev/null @@ -1,4263 +0,0 @@ - - - - - - Linux DRM Developer's Guide - - - - Jesse - Barnes - Initial version - - Intel Corporation -
- jesse.barnes@intel.com -
- - - - Laurent - Pinchart - Driver internals - - Ideas on board SPRL -
- laurent.pinchart@ideasonboard.com -
- - - - Daniel - Vetter - Contributions all over the place - - Intel Corporation -
- daniel.vetter@ffwll.ch -
- - - - - - 2008-2009 - 2013-2014 - Intel Corporation - - - 2012 - Laurent Pinchart - - - - - The contents of this file may be used under the terms of the GNU - General Public License version 2 (the "GPL") as distributed in - the kernel source COPYING file. - - - - - - - 1.0 - 2012-07-13 - LP - Added extensive documentation about driver internals. - - - - - - - - - DRM Core - - - This first part of the DRM Developer's Guide documents core DRM code, - helper libraries for writing drivers and generic userspace interfaces - exposed by DRM drivers. - - - - - Introduction - - The Linux DRM layer contains code intended to support the needs - of complex graphics devices, usually containing programmable - pipelines well suited to 3D graphics acceleration. Graphics - drivers in the kernel may make use of DRM functions to make - tasks like memory management, interrupt handling and DMA easier, - and provide a uniform interface to applications. - - - A note on versions: this guide covers features found in the DRM - tree, including the TTM memory manager, output configuration and - mode setting, and the new vblank internals, in addition to all - the regular features found in current kernels. - - - [Insert diagram of typical DRM stack here] - - - - - - - DRM Internals - - This chapter documents DRM internals relevant to driver authors - and developers working to add support for the latest features to - existing drivers. - - - First, we go over some typical driver initialization - requirements, like setting up command buffers, creating an - initial output configuration, and initializing core services. - Subsequent sections cover core internals in more detail, - providing implementation notes and examples. - - - The DRM layer provides several services to graphics drivers, - many of them driven by the application interfaces it provides - through libdrm, the library that wraps most of the DRM ioctls. - These include vblank event handling, memory - management, output management, framebuffer management, command - submission & fencing, suspend/resume support, and DMA - services. - - - - - - Driver Initialization - - At the core of every DRM driver is a drm_driver - structure. Drivers typically statically initialize a drm_driver structure, - and then pass it to one of the drm_*_init() functions - to register it with the DRM subsystem. - - - Newer drivers that no longer require a drm_bus - structure can alternatively use the low-level device initialization and - registration functions such as drm_dev_alloc() and - drm_dev_register() directly. - - - The drm_driver structure contains static - information that describes the driver and features it supports, and - pointers to methods that the DRM core will call to implement the DRM API. - We will first go through the drm_driver static - information fields, and will then describe individual operations in - details as they get used in later sections. - - - Driver Information - - Driver Features - - Drivers inform the DRM core about their requirements and supported - features by setting appropriate flags in the - driver_features field. Since those flags - influence the DRM core behaviour since registration time, most of them - must be set to registering the drm_driver - instance. - - u32 driver_features; - - Driver Feature Flags - - DRIVER_USE_AGP - - Driver uses AGP interface, the DRM core will manage AGP resources. - - - - DRIVER_REQUIRE_AGP - - Driver needs AGP interface to function. AGP initialization failure - will become a fatal error. - - - - DRIVER_PCI_DMA - - Driver is capable of PCI DMA, mapping of PCI DMA buffers to - userspace will be enabled. Deprecated. - - - - DRIVER_SG - - Driver can perform scatter/gather DMA, allocation and mapping of - scatter/gather buffers will be enabled. Deprecated. - - - - DRIVER_HAVE_DMA - - Driver supports DMA, the userspace DMA API will be supported. - Deprecated. - - - - DRIVER_HAVE_IRQDRIVER_IRQ_SHARED - - DRIVER_HAVE_IRQ indicates whether the driver has an IRQ handler - managed by the DRM Core. The core will support simple IRQ handler - installation when the flag is set. The installation process is - described in . - DRIVER_IRQ_SHARED indicates whether the device & handler - support shared IRQs (note that this is required of PCI drivers). - - - - DRIVER_GEM - - Driver use the GEM memory manager. - - - - DRIVER_MODESET - - Driver supports mode setting interfaces (KMS). - - - - DRIVER_PRIME - - Driver implements DRM PRIME buffer sharing. - - - - DRIVER_RENDER - - Driver supports dedicated render nodes. - - - - DRIVER_ATOMIC - - Driver supports atomic properties. In this case the driver - must implement appropriate obj->atomic_get_property() vfuncs - for any modeset objects with driver specific properties. - - - - - - Major, Minor and Patchlevel - int major; -int minor; -int patchlevel; - - The DRM core identifies driver versions by a major, minor and patch - level triplet. The information is printed to the kernel log at - initialization time and passed to userspace through the - DRM_IOCTL_VERSION ioctl. - - - The major and minor numbers are also used to verify the requested driver - API version passed to DRM_IOCTL_SET_VERSION. When the driver API changes - between minor versions, applications can call DRM_IOCTL_SET_VERSION to - select a specific version of the API. If the requested major isn't equal - to the driver major, or the requested minor is larger than the driver - minor, the DRM_IOCTL_SET_VERSION call will return an error. Otherwise - the driver's set_version() method will be called with the requested - version. - - - - Name, Description and Date - char *name; -char *desc; -char *date; - - The driver name is printed to the kernel log at initialization time, - used for IRQ registration and passed to userspace through - DRM_IOCTL_VERSION. - - - The driver description is a purely informative string passed to - userspace through the DRM_IOCTL_VERSION ioctl and otherwise unused by - the kernel. - - - The driver date, formatted as YYYYMMDD, is meant to identify the date of - the latest modification to the driver. However, as most drivers fail to - update it, its value is mostly useless. The DRM core prints it to the - kernel log at initialization time and passes it to userspace through the - DRM_IOCTL_VERSION ioctl. - - - - - Device Registration - - A number of functions are provided to help with device registration. - The functions deal with PCI and platform devices, respectively. - -!Edrivers/gpu/drm/drm_pci.c -!Edrivers/gpu/drm/drm_platform.c - - New drivers that no longer rely on the services provided by the - drm_bus structure can call the low-level - device registration functions directly. The - drm_dev_alloc() function can be used to allocate - and initialize a new drm_device structure. - Drivers will typically want to perform some additional setup on this - structure, such as allocating driver-specific data and storing a - pointer to it in the DRM device's dev_private - field. Drivers should also set the device's unique name using the - drm_dev_set_unique() function. After it has been - set up a device can be registered with the DRM subsystem by calling - drm_dev_register(). This will cause the device to - be exposed to userspace and will call the driver's - .load() implementation. When a device is - removed, the DRM device can safely be unregistered and freed by calling - drm_dev_unregister() followed by a call to - drm_dev_unref(). - -!Edrivers/gpu/drm/drm_drv.c - - - Driver Load - - The load method is the driver and device - initialization entry point. The method is responsible for allocating and - initializing driver private data, performing resource allocation and - mapping (e.g. acquiring - clocks, mapping registers or allocating command buffers), initializing - the memory manager (), installing - the IRQ handler (), setting up - vertical blanking handling (), mode - setting () and initial output - configuration (). - - - If compatibility is a concern (e.g. with drivers converted over from - User Mode Setting to Kernel Mode Setting), care must be taken to prevent - device initialization and control that is incompatible with currently - active userspace drivers. For instance, if user level mode setting - drivers are in use, it would be problematic to perform output discovery - & configuration at load time. Likewise, if user-level drivers - unaware of memory management are in use, memory management and command - buffer setup may need to be omitted. These requirements are - driver-specific, and care needs to be taken to keep both old and new - applications and libraries working. - - int (*load) (struct drm_device *, unsigned long flags); - - The method takes two arguments, a pointer to the newly created - drm_device and flags. The flags are used to - pass the driver_data field of the device id - corresponding to the device passed to drm_*_init(). - Only PCI devices currently use this, USB and platform DRM drivers have - their load method called with flags to 0. - - - Driver Private Data - - The driver private hangs off the main - drm_device structure and can be used for - tracking various device-specific bits of information, like register - offsets, command buffer status, register state for suspend/resume, etc. - At load time, a driver may simply allocate one and set - drm_device.dev_priv - appropriately; it should be freed and - drm_device.dev_priv - set to NULL when the driver is unloaded. - - - - IRQ Registration - - The DRM core tries to facilitate IRQ handler registration and - unregistration by providing drm_irq_install and - drm_irq_uninstall functions. Those functions only - support a single interrupt per device, devices that use more than one - IRQs need to be handled manually. - - - Managed IRQ Registration - - drm_irq_install starts by calling the - irq_preinstall driver operation. The operation - is optional and must make sure that the interrupt will not get fired by - clearing all pending interrupt flags or disabling the interrupt. - - - The passed-in IRQ will then be requested by a call to - request_irq. If the DRIVER_IRQ_SHARED driver - feature flag is set, a shared (IRQF_SHARED) IRQ handler will be - requested. - - - The IRQ handler function must be provided as the mandatory irq_handler - driver operation. It will get passed directly to - request_irq and thus has the same prototype as all - IRQ handlers. It will get called with a pointer to the DRM device as the - second argument. - - - Finally the function calls the optional - irq_postinstall driver operation. The operation - usually enables interrupts (excluding the vblank interrupt, which is - enabled separately), but drivers may choose to enable/disable interrupts - at a different time. - - - drm_irq_uninstall is similarly used to uninstall an - IRQ handler. It starts by waking up all processes waiting on a vblank - interrupt to make sure they don't hang, and then calls the optional - irq_uninstall driver operation. The operation - must disable all hardware interrupts. Finally the function frees the IRQ - by calling free_irq. - - - - Manual IRQ Registration - - Drivers that require multiple interrupt handlers can't use the managed - IRQ registration functions. In that case IRQs must be registered and - unregistered manually (usually with the request_irq - and free_irq functions, or their devm_* equivalent). - - - When manually registering IRQs, drivers must not set the DRIVER_HAVE_IRQ - driver feature flag, and must not provide the - irq_handler driver operation. They must set the - drm_device irq_enabled - field to 1 upon registration of the IRQs, and clear it to 0 after - unregistering the IRQs. - - - - - Memory Manager Initialization - - Every DRM driver requires a memory manager which must be initialized at - load time. DRM currently contains two memory managers, the Translation - Table Manager (TTM) and the Graphics Execution Manager (GEM). - This document describes the use of the GEM memory manager only. See - for details. - - - - Miscellaneous Device Configuration - - Another task that may be necessary for PCI devices during configuration - is mapping the video BIOS. On many devices, the VBIOS describes device - configuration, LCD panel timings (if any), and contains flags indicating - device state. Mapping the BIOS can be done using the pci_map_rom() call, - a convenience function that takes care of mapping the actual ROM, - whether it has been shadowed into memory (typically at address 0xc0000) - or exists on the PCI device in the ROM BAR. Note that after the ROM has - been mapped and any necessary information has been extracted, it should - be unmapped; on many devices, the ROM address decoder is shared with - other BARs, so leaving it mapped could cause undesired behaviour like - hangs or memory corruption. - - - - - - - - - - Memory management - - Modern Linux systems require large amount of graphics memory to store - frame buffers, textures, vertices and other graphics-related data. Given - the very dynamic nature of many of that data, managing graphics memory - efficiently is thus crucial for the graphics stack and plays a central - role in the DRM infrastructure. - - - The DRM core includes two memory managers, namely Translation Table Maps - (TTM) and Graphics Execution Manager (GEM). TTM was the first DRM memory - manager to be developed and tried to be a one-size-fits-them all - solution. It provides a single userspace API to accommodate the need of - all hardware, supporting both Unified Memory Architecture (UMA) devices - and devices with dedicated video RAM (i.e. most discrete video cards). - This resulted in a large, complex piece of code that turned out to be - hard to use for driver development. - - - GEM started as an Intel-sponsored project in reaction to TTM's - complexity. Its design philosophy is completely different: instead of - providing a solution to every graphics memory-related problems, GEM - identified common code between drivers and created a support library to - share it. GEM has simpler initialization and execution requirements than - TTM, but has no video RAM management capabilities and is thus limited to - UMA devices. - - - The Translation Table Manager (TTM) - - TTM design background and information belongs here. - - - TTM initialization - 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. - - - The ttm_global_reference structure is made up of several fields: - - - struct ttm_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 *); - }; - - - There should be one global reference structure for your memory - manager as a whole, and there will be others for each object - created by the memory manager at runtime. Your global TTM should - have a type of TTM_GLOBAL_TTM_MEM. The size field for the global - object should be sizeof(struct ttm_mem_global), and the init and - release hooks should point at your driver-specific init and - release routines, which probably eventually call - ttm_mem_global_init and ttm_mem_global_release, respectively. - - - Once your global TTM accounting structure is set up and initialized - by calling ttm_global_item_ref() on it, - you need to create a buffer object TTM to - provide a pool for buffer object allocation by clients and the - kernel itself. The type of this object should be TTM_GLOBAL_TTM_BO, - and its size should be sizeof(struct ttm_bo_global). Again, - driver-specific init and release functions may be provided, - likely eventually calling ttm_bo_global_init() and - 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. - - - - - The Graphics Execution Manager (GEM) - - The GEM design approach has resulted in a memory manager that doesn't - provide full coverage of all (or even all common) use cases in its - userspace or kernel API. GEM exposes a set of standard memory-related - operations to userspace and a set of helper functions to drivers, and let - drivers implement hardware-specific operations with their own private API. - - - The GEM userspace API is described in the - GEM - the Graphics - Execution Manager article on LWN. While slightly - outdated, the document provides a good overview of the GEM API principles. - Buffer allocation and read and write operations, described as part of the - common GEM API, are currently implemented using driver-specific ioctls. - - - GEM is data-agnostic. It manages abstract buffer objects without knowing - what individual buffers contain. APIs that require knowledge of buffer - contents or purpose, such as buffer allocation or synchronization - primitives, are thus outside of the scope of GEM and must be implemented - using driver-specific ioctls. - - - On a fundamental level, GEM involves several operations: - - Memory allocation and freeing - Command execution - Aperture management at command execution time - - Buffer object allocation is relatively straightforward and largely - provided by Linux's shmem layer, which provides memory to back each - object. - - - Device-specific operations, such as command execution, pinning, buffer - read & write, mapping, and domain ownership transfers are left to - driver-specific ioctls. - - - GEM Initialization - - Drivers that use GEM must set the DRIVER_GEM bit in the struct - drm_driver - driver_features field. The DRM core will - then automatically initialize the GEM core before calling the - load operation. Behind the scene, this will - create a DRM Memory Manager object which provides an address space - pool for object allocation. - - - In a KMS configuration, drivers need to allocate and initialize a - command ring buffer following core GEM initialization if required by - the hardware. UMA devices usually have what is called a "stolen" - memory region, which provides space for the initial framebuffer and - large, contiguous memory regions required by the device. This space is - typically not managed by GEM, and must be initialized separately into - its own DRM MM object. - - - - GEM Objects Creation - - GEM splits creation of GEM objects and allocation of the memory that - backs them in two distinct operations. - - - GEM objects are represented by an instance of struct - drm_gem_object. Drivers usually need to extend - GEM objects with private information and thus create a driver-specific - GEM object structure type that embeds an instance of struct - drm_gem_object. - - - To create a GEM object, a driver allocates memory for an instance of its - specific GEM object type and initializes the embedded struct - drm_gem_object with a call to - drm_gem_object_init. The function takes a pointer to - the DRM device, a pointer to the GEM object and the buffer object size - in bytes. - - - GEM uses shmem to allocate anonymous pageable memory. - drm_gem_object_init will create an shmfs file of - the requested size and store it into the struct - drm_gem_object filp - field. The memory is used as either main storage for the object when the - graphics hardware uses system memory directly or as a backing store - otherwise. - - - Drivers are responsible for the actual physical pages allocation by - calling shmem_read_mapping_page_gfp for each page. - Note that they can decide to allocate pages when initializing the GEM - object, or to delay allocation until the memory is needed (for instance - when a page fault occurs as a result of a userspace memory access or - when the driver needs to start a DMA transfer involving the memory). - - - Anonymous pageable memory allocation is not always desired, for instance - when the hardware requires physically contiguous system memory as is - often the case in embedded devices. Drivers can create GEM objects with - no shmfs backing (called private GEM objects) by initializing them with - a call to drm_gem_private_object_init instead of - drm_gem_object_init. Storage for private GEM - objects must be managed by drivers. - - - Drivers that do not need to extend GEM objects with private information - can call the drm_gem_object_alloc function to - allocate and initialize a struct drm_gem_object - instance. The GEM core will call the optional driver - gem_init_object operation after initializing - the GEM object with drm_gem_object_init. - int (*gem_init_object) (struct drm_gem_object *obj); - - - No alloc-and-init function exists for private GEM objects. - - - - GEM Objects Lifetime - - All GEM objects are reference-counted by the GEM core. References can be - acquired and release by calling drm_gem_object_reference - and drm_gem_object_unreference respectively. The - caller must hold the drm_device - struct_mutex lock. As a convenience, GEM - provides the drm_gem_object_reference_unlocked and - drm_gem_object_unreference_unlocked functions that - can be called without holding the lock. - - - When the last reference to a GEM object is released the GEM core calls - the drm_driver - gem_free_object operation. That operation is - mandatory for GEM-enabled drivers and must free the GEM object and all - associated resources. - - - void (*gem_free_object) (struct drm_gem_object *obj); - Drivers are responsible for freeing all GEM object resources, including - the resources created by the GEM core. If an mmap offset has been - created for the object (in which case - drm_gem_object::map_list::map - is not NULL) it must be freed by a call to - drm_gem_free_mmap_offset. The shmfs backing store - must be released by calling drm_gem_object_release - (that function can safely be called if no shmfs backing store has been - created). - - - - GEM Objects Naming - - Communication between userspace and the kernel refers to GEM objects - using local handles, global names or, more recently, file descriptors. - All of those are 32-bit integer values; the usual Linux kernel limits - apply to the file descriptors. - - - GEM handles are local to a DRM file. Applications get a handle to a GEM - object through a driver-specific ioctl, and can use that handle to refer - to the GEM object in other standard or driver-specific ioctls. Closing a - DRM file handle frees all its GEM handles and dereferences the - associated GEM objects. - - - To create a handle for a GEM object drivers call - drm_gem_handle_create. The function takes a pointer - to the DRM file and the GEM object and returns a locally unique handle. - When the handle is no longer needed drivers delete it with a call to - drm_gem_handle_delete. Finally the GEM object - associated with a handle can be retrieved by a call to - drm_gem_object_lookup. - - - Handles don't take ownership of GEM objects, they only take a reference - to the object that will be dropped when the handle is destroyed. To - avoid leaking GEM objects, drivers must make sure they drop the - reference(s) they own (such as the initial reference taken at object - creation time) as appropriate, without any special consideration for the - handle. For example, in the particular case of combined GEM object and - handle creation in the implementation of the - dumb_create operation, drivers must drop the - initial reference to the GEM object before returning the handle. - - - GEM names are similar in purpose to handles but are not local to DRM - files. They can be passed between processes to reference a GEM object - globally. Names can't be used directly to refer to objects in the DRM - API, applications must convert handles to names and names to handles - using the DRM_IOCTL_GEM_FLINK and DRM_IOCTL_GEM_OPEN ioctls - respectively. The conversion is handled by the DRM core without any - driver-specific support. - - - GEM also supports buffer sharing with dma-buf file descriptors through - PRIME. GEM-based drivers must use the provided helpers functions to - implement the exporting and importing correctly. See . - Since sharing file descriptors is inherently more secure than the - easily guessable and global GEM names it is the preferred buffer - sharing mechanism. Sharing buffers through GEM names is only supported - for legacy userspace. Furthermore PRIME also allows cross-device - buffer sharing since it is based on dma-bufs. - - - - GEM Objects Mapping - - Because mapping operations are fairly heavyweight GEM favours - read/write-like access to buffers, implemented through driver-specific - ioctls, over mapping buffers to userspace. However, when random access - to the buffer is needed (to perform software rendering for instance), - direct access to the object can be more efficient. - - - The mmap system call can't be used directly to map GEM objects, as they - don't have their own file handle. Two alternative methods currently - co-exist to map GEM objects to userspace. The first method uses a - driver-specific ioctl to perform the mapping operation, calling - do_mmap under the hood. This is often considered - dubious, seems to be discouraged for new GEM-enabled drivers, and will - thus not be described here. - - - The second method uses the mmap system call on the DRM file handle. - void *mmap(void *addr, size_t length, int prot, int flags, int fd, - off_t offset); - DRM identifies the GEM object to be mapped by a fake offset passed - through the mmap offset argument. Prior to being mapped, a GEM object - must thus be associated with a fake offset. To do so, drivers must call - drm_gem_create_mmap_offset on the object. The - function allocates a fake offset range from a pool and stores the - offset divided by PAGE_SIZE in - obj->map_list.hash.key. Care must be taken not to - call drm_gem_create_mmap_offset if a fake offset - has already been allocated for the object. This can be tested by - obj->map_list.map being non-NULL. - - - Once allocated, the fake offset value - (obj->map_list.hash.key << PAGE_SHIFT) - must be passed to the application in a driver-specific way and can then - be used as the mmap offset argument. - - - The GEM core provides a helper method drm_gem_mmap - to handle object mapping. The method can be set directly as the mmap - file operation handler. It will look up the GEM object based on the - offset value and set the VMA operations to the - drm_driver gem_vm_ops - field. Note that drm_gem_mmap doesn't map memory to - userspace, but relies on the driver-provided fault handler to map pages - individually. - - - To use drm_gem_mmap, drivers must fill the struct - 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 open and close - operations must update the GEM object reference count. Drivers can use - the drm_gem_vm_open and - drm_gem_vm_close helper functions directly as open - and close handlers. - - - The fault operation handler is responsible for mapping individual pages - to userspace when a page fault occurs. Depending on the memory - allocation scheme, drivers can allocate pages at fault time, or can - decide to allocate memory for the GEM object at the time the object is - created. - - - Drivers that want to map the GEM object upfront instead of handling page - faults can implement their own mmap file operation handler. - - - - Memory Coherency - - When mapped to the device or used in a command buffer, backing pages - for an object are flushed to memory and marked write combined so as to - be coherent with the GPU. Likewise, if the CPU accesses an object - after the GPU has finished rendering to the object, then the object - must be made coherent with the CPU's view of memory, usually involving - GPU cache flushing of various kinds. This core CPU<->GPU - coherency management is provided by a device-specific ioctl, which - evaluates an object's current domain and performs any necessary - flushing or synchronization to put the object into the desired - coherency domain (note that the object may be busy, i.e. an active - render target; in that case, setting the domain blocks the client and - waits for rendering to complete before performing any necessary - flushing operations). - - - - Command Execution - - Perhaps the most important GEM function for GPU devices is providing a - command execution interface to clients. Client programs construct - command buffers containing references to previously allocated memory - objects, and then submit them to GEM. At that point, GEM takes care to - bind all the objects into the GTT, execute the buffer, and provide - necessary synchronization between clients accessing the same buffers. - This often involves evicting some objects from the GTT and re-binding - others (a fairly expensive operation), and providing relocation - support which hides fixed GTT offsets from clients. Clients must take - care not to submit command buffers that reference more objects than - can fit in the GTT; otherwise, GEM will reject them and no rendering - will occur. Similarly, if several objects in the buffer require fence - registers to be allocated for correct rendering (e.g. 2D blits on - pre-965 chips), care must be taken not to require more fence registers - than are available to the client. Such resource management should be - abstracted from the client in libdrm. - - - - GEM Function Reference -!Edrivers/gpu/drm/drm_gem.c - - - - VMA Offset Manager -!Pdrivers/gpu/drm/drm_vma_manager.c vma offset manager -!Edrivers/gpu/drm/drm_vma_manager.c -!Iinclude/drm/drm_vma_manager.h - - - PRIME Buffer Sharing - - PRIME is the cross device buffer sharing framework in drm, originally - created for the OPTIMUS range of multi-gpu platforms. To userspace - PRIME buffers are dma-buf based file descriptors. - - - Overview and Driver Interface - - Similar to GEM global names, PRIME file descriptors are - also used to share buffer objects across processes. They offer - additional security: as file descriptors must be explicitly sent over - UNIX domain sockets to be shared between applications, they can't be - guessed like the globally unique GEM names. - - - Drivers that support the PRIME - API must set the DRIVER_PRIME bit in the struct - drm_driver - driver_features field, and implement the - prime_handle_to_fd and - prime_fd_to_handle operations. - - - int (*prime_handle_to_fd)(struct drm_device *dev, - struct drm_file *file_priv, uint32_t handle, - uint32_t flags, int *prime_fd); -int (*prime_fd_to_handle)(struct drm_device *dev, - struct drm_file *file_priv, int prime_fd, - uint32_t *handle); - Those two operations convert a handle to a PRIME file descriptor and - vice versa. Drivers must use the kernel dma-buf buffer sharing framework - to manage the PRIME file descriptors. Similar to the mode setting - API PRIME is agnostic to the underlying buffer object manager, as - long as handles are 32bit unsigned integers. - - - While non-GEM drivers must implement the operations themselves, GEM - drivers must use the drm_gem_prime_handle_to_fd - and drm_gem_prime_fd_to_handle helper functions. - Those helpers rely on the driver - gem_prime_export and - gem_prime_import operations to create a dma-buf - instance from a GEM object (dma-buf exporter role) and to create a GEM - object from a dma-buf instance (dma-buf importer role). - - - struct dma_buf * (*gem_prime_export)(struct drm_device *dev, - struct drm_gem_object *obj, - int flags); -struct drm_gem_object * (*gem_prime_import)(struct drm_device *dev, - struct dma_buf *dma_buf); - These two operations are mandatory for GEM drivers that support - PRIME. - - - - PRIME Helper Functions -!Pdrivers/gpu/drm/drm_prime.c PRIME Helpers - - - - PRIME Function References -!Edrivers/gpu/drm/drm_prime.c - - - DRM MM Range Allocator - - Overview -!Pdrivers/gpu/drm/drm_mm.c Overview - - - LRU Scan/Eviction Support -!Pdrivers/gpu/drm/drm_mm.c lru scan roaster - - - - DRM MM Range Allocator Function References -!Edrivers/gpu/drm/drm_mm.c -!Iinclude/drm/drm_mm.h - - - CMA Helper Functions Reference -!Pdrivers/gpu/drm/drm_gem_cma_helper.c cma helpers -!Edrivers/gpu/drm/drm_gem_cma_helper.c -!Iinclude/drm/drm_gem_cma_helper.h - - - - - - - Mode Setting - - Drivers must initialize the mode setting core by calling - drm_mode_config_init on the DRM device. The function - initializes the drm_device - mode_config field and never fails. Once done, - mode configuration must be setup by initializing the following fields. - - - - int min_width, min_height; -int max_width, max_height; - - Minimum and maximum width and height of the frame buffers in pixel - units. - - - - struct drm_mode_config_funcs *funcs; - Mode setting functions. - - - - Display Modes Function Reference -!Iinclude/drm/drm_modes.h -!Edrivers/gpu/drm/drm_modes.c - - - Atomic Mode Setting Function Reference -!Edrivers/gpu/drm/drm_atomic.c - - - Frame Buffer Creation - struct drm_framebuffer *(*fb_create)(struct drm_device *dev, - struct drm_file *file_priv, - struct drm_mode_fb_cmd2 *mode_cmd); - - Frame buffers are abstract memory objects that provide a source of - pixels to scanout to a CRTC. Applications explicitly request the - creation of frame buffers through the DRM_IOCTL_MODE_ADDFB(2) ioctls and - receive an opaque handle that can be passed to the KMS CRTC control, - plane configuration and page flip functions. - - - Frame buffers rely on the underneath memory manager for low-level memory - operations. When creating a frame buffer applications pass a memory - handle (or a list of memory handles for multi-planar formats) through - the drm_mode_fb_cmd2 argument. For drivers using - GEM as their userspace buffer management interface this would be a GEM - handle. Drivers are however free to use their own backing storage object - handles, e.g. vmwgfx directly exposes special TTM handles to userspace - and so expects TTM handles in the create ioctl and not GEM handles. - - - Drivers must first validate the requested frame buffer parameters passed - through the mode_cmd argument. In particular this is where invalid - sizes, pixel formats or pitches can be caught. - - - If the parameters are deemed valid, drivers then create, initialize and - return an instance of struct drm_framebuffer. - If desired the instance can be embedded in a larger driver-specific - structure. Drivers must fill its width, - height, pitches, - offsets, depth, - bits_per_pixel and - pixel_format fields from the values passed - through the drm_mode_fb_cmd2 argument. They - should call the drm_helper_mode_fill_fb_struct - helper function to do so. - - - - The initialization of the new framebuffer instance is finalized with a - call to drm_framebuffer_init which takes a pointer - to DRM frame buffer operations (struct - drm_framebuffer_funcs). Note that this function - publishes the framebuffer and so from this point on it can be accessed - concurrently from other threads. Hence it must be the last step in the - driver's framebuffer initialization sequence. Frame buffer operations - are - - - int (*create_handle)(struct drm_framebuffer *fb, - struct drm_file *file_priv, unsigned int *handle); - - Create a handle to the frame buffer underlying memory object. If - the frame buffer uses a multi-plane format, the handle will - reference the memory object associated with the first plane. - - - Drivers call drm_gem_handle_create to create - the handle. - - - - void (*destroy)(struct drm_framebuffer *framebuffer); - - Destroy the frame buffer object and frees all associated - resources. Drivers must call - drm_framebuffer_cleanup to free resources - allocated by the DRM core for the frame buffer object, and must - make sure to unreference all memory objects associated with the - frame buffer. Handles created by the - create_handle operation are released by - the DRM core. - - - - int (*dirty)(struct drm_framebuffer *framebuffer, - struct drm_file *file_priv, unsigned flags, unsigned color, - struct drm_clip_rect *clips, unsigned num_clips); - - This optional operation notifies the driver that a region of the - frame buffer has changed in response to a DRM_IOCTL_MODE_DIRTYFB - ioctl call. - - - - - - The lifetime of a drm framebuffer is controlled with a reference count, - drivers can grab additional references with - drm_framebuffer_referenceand drop them - again with drm_framebuffer_unreference. For - driver-private framebuffers for which the last reference is never - dropped (e.g. for the fbdev framebuffer when the struct - drm_framebuffer is embedded into the fbdev - helper struct) drivers can manually clean up a framebuffer at module - unload time with - drm_framebuffer_unregister_private. - - - - Dumb Buffer Objects - - The KMS API doesn't standardize backing storage object creation and - leaves it to driver-specific ioctls. Furthermore actually creating a - buffer object even for GEM-based drivers is done through a - driver-specific ioctl - GEM only has a common userspace interface for - sharing and destroying objects. While not an issue for full-fledged - graphics stacks that include device-specific userspace components (in - libdrm for instance), this limit makes DRM-based early boot graphics - unnecessarily complex. - - - Dumb objects partly alleviate the problem by providing a standard - API to create dumb buffers suitable for scanout, which can then be used - to create KMS frame buffers. - - - To support dumb objects drivers must implement the - dumb_create, - dumb_destroy and - dumb_map_offset operations. - - - - int (*dumb_create)(struct drm_file *file_priv, struct drm_device *dev, - struct drm_mode_create_dumb *args); - - The dumb_create operation creates a driver - object (GEM or TTM handle) suitable for scanout based on the - width, height and depth from the struct - drm_mode_create_dumb argument. It fills the - argument's handle, - pitch and size - fields with a handle for the newly created object and its line - pitch and size in bytes. - - - - int (*dumb_destroy)(struct drm_file *file_priv, struct drm_device *dev, - uint32_t handle); - - The dumb_destroy operation destroys a dumb - object created by dumb_create. - - - - int (*dumb_map_offset)(struct drm_file *file_priv, struct drm_device *dev, - uint32_t handle, uint64_t *offset); - - The dumb_map_offset operation associates an - mmap fake offset with the object given by the handle and returns - it. Drivers must use the - drm_gem_create_mmap_offset function to - associate the fake offset as described in - . - - - - - Note that dumb objects may not be used for gpu acceleration, as has been - attempted on some ARM embedded platforms. Such drivers really must have - a hardware-specific ioctl to allocate suitable buffer objects. - - - - Output Polling - void (*output_poll_changed)(struct drm_device *dev); - - This operation notifies the driver that the status of one or more - connectors has changed. Drivers that use the fb helper can just call the - drm_fb_helper_hotplug_event function to handle this - operation. - - - - Locking - - Beside some lookup structures with their own locking (which is hidden - behind the interface functions) most of the modeset state is protected - by the dev-<mode_config.lock mutex and additionally - per-crtc locks to allow cursor updates, pageflips and similar operations - to occur concurrently with background tasks like output detection. - Operations which cross domains like a full modeset always grab all - locks. Drivers there need to protect resources shared between crtcs with - additional locking. They also need to be careful to always grab the - relevant crtc locks if a modset functions touches crtc state, e.g. for - load detection (which does only grab the mode_config.lock - to allow concurrent screen updates on live crtcs). - - - - - - - - KMS Initialization and Cleanup - - A KMS device is abstracted and exposed as a set of planes, CRTCs, encoders - and connectors. KMS drivers must thus create and initialize all those - objects at load time after initializing mode setting. - - - CRTCs (struct <structname>drm_crtc</structname>) - - A CRTC is an abstraction representing a part of the chip that contains a - pointer to a scanout buffer. Therefore, the number of CRTCs available - determines how many independent scanout buffers can be active at any - given time. The CRTC structure contains several fields to support this: - a pointer to some video memory (abstracted as a frame buffer object), a - display mode, and an (x, y) offset into the video memory to support - panning or configurations where one piece of video memory spans multiple - CRTCs. - - - CRTC Initialization - - A KMS device must create and register at least one struct - drm_crtc instance. The instance is allocated - and zeroed by the driver, possibly as part of a larger structure, and - registered with a call to drm_crtc_init with a - pointer to CRTC functions. - - - - CRTC Operations - - Set Configuration - int (*set_config)(struct drm_mode_set *set); - - Apply a new CRTC configuration to the device. The configuration - specifies a CRTC, a frame buffer to scan out from, a (x,y) position in - the frame buffer, a display mode and an array of connectors to drive - with the CRTC if possible. - - - If the frame buffer specified in the configuration is NULL, the driver - must detach all encoders connected to the CRTC and all connectors - attached to those encoders and disable them. - - - This operation is called with the mode config lock held. - - - Note that the drm core has no notion of restoring the mode setting - state after resume, since all resume handling is in the full - responsibility of the driver. The common mode setting helper library - though provides a helper which can be used for this: - drm_helper_resume_force_mode. - - - - Page Flipping - int (*page_flip)(struct drm_crtc *crtc, struct drm_framebuffer *fb, - struct drm_pending_vblank_event *event); - - Schedule a page flip to the given frame buffer for the CRTC. This - operation is called with the mode config mutex held. - - - Page flipping is a synchronization mechanism that replaces the frame - buffer being scanned out by the CRTC with a new frame buffer during - vertical blanking, avoiding tearing. When an application requests a page - flip the DRM core verifies that the new frame buffer is large enough to - be scanned out by the CRTC in the currently configured mode and then - calls the CRTC page_flip operation with a - pointer to the new frame buffer. - - - The page_flip operation schedules a page flip. - Once any pending rendering targeting the new frame buffer has - completed, the CRTC will be reprogrammed to display that frame buffer - after the next vertical refresh. The operation must return immediately - without waiting for rendering or page flip to complete and must block - any new rendering to the frame buffer until the page flip completes. - - - If a page flip can be successfully scheduled the driver must set the - drm_crtc->fb field to the new framebuffer pointed to - by fb. This is important so that the reference counting - on framebuffers stays balanced. - - - If a page flip is already pending, the - page_flip operation must return - -EBUSY. - - - To synchronize page flip to vertical blanking the driver will likely - need to enable vertical blanking interrupts. It should call - drm_vblank_get for that purpose, and call - drm_vblank_put after the page flip completes. - - - If the application has requested to be notified when page flip completes - the page_flip operation will be called with a - non-NULL event argument pointing to a - drm_pending_vblank_event instance. Upon page - flip completion the driver must call drm_send_vblank_event - to fill in the event and send to wake up any waiting processes. - This can be performed with - event_lock, flags); - ... - drm_send_vblank_event(dev, pipe, event); - spin_unlock_irqrestore(&dev->event_lock, flags); - ]]> - - - FIXME: Could drivers that don't need to wait for rendering to complete - just add the event to dev->vblank_event_list and - let the DRM core handle everything, as for "normal" vertical blanking - events? - - - While waiting for the page flip to complete, the - event->base.link list head can be used freely by - the driver to store the pending event in a driver-specific list. - - - If the file handle is closed before the event is signaled, drivers must - take care to destroy the event in their - preclose operation (and, if needed, call - drm_vblank_put). - - - - Miscellaneous - - - void (*set_property)(struct drm_crtc *crtc, - struct drm_property *property, uint64_t value); - - Set the value of the given CRTC property to - value. See - for more information about properties. - - - - void (*gamma_set)(struct drm_crtc *crtc, u16 *r, u16 *g, u16 *b, - uint32_t start, uint32_t size); - - Apply a gamma table to the device. The operation is optional. - - - - void (*destroy)(struct drm_crtc *crtc); - - Destroy the CRTC when not needed anymore. See - . - - - - - - - - Planes (struct <structname>drm_plane</structname>) - - A plane represents an image source that can be blended with or overlayed - on top of a CRTC during the scanout process. Planes are associated with - a frame buffer to crop a portion of the image memory (source) and - optionally scale it to a destination size. The result is then blended - with or overlayed on top of a CRTC. - - - The DRM core recognizes three types of planes: - - - DRM_PLANE_TYPE_PRIMARY represents a "main" plane for a CRTC. Primary - planes are the planes operated upon by CRTC modesetting and flipping - operations described in . - - - DRM_PLANE_TYPE_CURSOR represents a "cursor" plane for a CRTC. Cursor - planes are the planes operated upon by the DRM_IOCTL_MODE_CURSOR and - DRM_IOCTL_MODE_CURSOR2 ioctls. - - - DRM_PLANE_TYPE_OVERLAY represents all non-primary, non-cursor planes. - Some drivers refer to these types of planes as "sprites" internally. - - - For compatibility with legacy userspace, only overlay planes are made - available to userspace by default. Userspace clients may set the - DRM_CLIENT_CAP_UNIVERSAL_PLANES client capability bit to indicate that - they wish to receive a universal plane list containing all plane types. - - - Plane Initialization - - To create a plane, a KMS drivers allocates and - zeroes an instances of struct drm_plane - (possibly as part of a larger structure) and registers it with a call - to drm_universal_plane_init. The function takes a bitmask - of the CRTCs that can be associated with the plane, a pointer to the - plane functions, a list of format supported formats, and the type of - plane (primary, cursor, or overlay) being initialized. - - - Cursor and overlay planes are optional. All drivers should provide - one primary plane per CRTC (although this requirement may change in - the future); drivers that do not wish to provide special handling for - primary planes may make use of the helper functions described in - to create and register a - primary plane with standard capabilities. - - - - Plane Operations - - - int (*update_plane)(struct drm_plane *plane, struct drm_crtc *crtc, - struct drm_framebuffer *fb, int crtc_x, int crtc_y, - unsigned int crtc_w, unsigned int crtc_h, - uint32_t src_x, uint32_t src_y, - uint32_t src_w, uint32_t src_h); - - Enable and configure the plane to use the given CRTC and frame buffer. - - - The source rectangle in frame buffer memory coordinates is given by - the src_x, src_y, - src_w and src_h - parameters (as 16.16 fixed point values). Devices that don't support - subpixel plane coordinates can ignore the fractional part. - - - The destination rectangle in CRTC coordinates is given by the - crtc_x, crtc_y, - crtc_w and crtc_h - parameters (as integer values). Devices scale the source rectangle to - the destination rectangle. If scaling is not supported, and the source - rectangle size doesn't match the destination rectangle size, the - driver must return a -EINVAL error. - - - - int (*disable_plane)(struct drm_plane *plane); - - Disable the plane. The DRM core calls this method in response to a - DRM_IOCTL_MODE_SETPLANE ioctl call with the frame buffer ID set to 0. - Disabled planes must not be processed by the CRTC. - - - - void (*destroy)(struct drm_plane *plane); - - Destroy the plane when not needed anymore. See - . - - - - - - - Encoders (struct <structname>drm_encoder</structname>) - - An encoder takes pixel data from a CRTC and converts it to a format - suitable for any attached connectors. On some devices, it may be - possible to have a CRTC send data to more than one encoder. In that - case, both encoders would receive data from the same scanout buffer, - resulting in a "cloned" display configuration across the connectors - attached to each encoder. - - - Encoder Initialization - - As for CRTCs, a KMS driver must create, initialize and register at - least one struct drm_encoder instance. The - instance is allocated and zeroed by the driver, possibly as part of a - larger structure. - - - Drivers must initialize the struct drm_encoder - possible_crtcs and - possible_clones fields before registering the - encoder. Both fields are bitmasks of respectively the CRTCs that the - encoder can be connected to, and sibling encoders candidate for cloning. - - - After being initialized, the encoder must be registered with a call to - drm_encoder_init. The function takes a pointer to - the encoder functions and an encoder type. Supported types are - - - DRM_MODE_ENCODER_DAC for VGA and analog on DVI-I/DVI-A - - - DRM_MODE_ENCODER_TMDS for DVI, HDMI and (embedded) DisplayPort - - - DRM_MODE_ENCODER_LVDS for display panels - - - DRM_MODE_ENCODER_TVDAC for TV output (Composite, S-Video, Component, - SCART) - - - DRM_MODE_ENCODER_VIRTUAL for virtual machine displays - - - - - Encoders must be attached to a CRTC to be used. DRM drivers leave - encoders unattached at initialization time. Applications (or the fbdev - compatibility layer when implemented) are responsible for attaching the - encoders they want to use to a CRTC. - - - - Encoder Operations - - - void (*destroy)(struct drm_encoder *encoder); - - Called to destroy the encoder when not needed anymore. See - . - - - - void (*set_property)(struct drm_plane *plane, - struct drm_property *property, uint64_t value); - - Set the value of the given plane property to - value. See - for more information about properties. - - - - - - - Connectors (struct <structname>drm_connector</structname>) - - A connector is the final destination for pixel data on a device, and - usually connects directly to an external display device like a monitor - or laptop panel. A connector can only be attached to one encoder at a - time. The connector is also the structure where information about the - attached display is kept, so it contains fields for display data, EDID - data, DPMS & connection status, and information about modes - supported on the attached displays. - - - Connector Initialization - - Finally a KMS driver must create, initialize, register and attach at - least one struct drm_connector instance. The - instance is created as other KMS objects and initialized by setting the - following fields. - - - - interlace_allowed - - Whether the connector can handle interlaced modes. - - - - doublescan_allowed - - Whether the connector can handle doublescan. - - - - display_info - - - Display information is filled from EDID information when a display - is detected. For non hot-pluggable displays such as flat panels in - embedded systems, the driver should initialize the - display_info.width_mm - and - display_info.height_mm - fields with the physical size of the display. - - - - polled - - Connector polling mode, a combination of - - - DRM_CONNECTOR_POLL_HPD - - The connector generates hotplug events and doesn't need to be - periodically polled. The CONNECT and DISCONNECT flags must not - be set together with the HPD flag. - - - - DRM_CONNECTOR_POLL_CONNECT - - Periodically poll the connector for connection. - - - - DRM_CONNECTOR_POLL_DISCONNECT - - Periodically poll the connector for disconnection. - - - - Set to 0 for connectors that don't support connection status - discovery. - - - - - The connector is then registered with a call to - drm_connector_init with a pointer to the connector - functions and a connector type, and exposed through sysfs with a call to - drm_connector_register. - - - Supported connector types are - - DRM_MODE_CONNECTOR_VGA - DRM_MODE_CONNECTOR_DVII - DRM_MODE_CONNECTOR_DVID - DRM_MODE_CONNECTOR_DVIA - DRM_MODE_CONNECTOR_Composite - DRM_MODE_CONNECTOR_SVIDEO - DRM_MODE_CONNECTOR_LVDS - DRM_MODE_CONNECTOR_Component - DRM_MODE_CONNECTOR_9PinDIN - DRM_MODE_CONNECTOR_DisplayPort - DRM_MODE_CONNECTOR_HDMIA - DRM_MODE_CONNECTOR_HDMIB - DRM_MODE_CONNECTOR_TV - DRM_MODE_CONNECTOR_eDP - DRM_MODE_CONNECTOR_VIRTUAL - - - - Connectors must be attached to an encoder to be used. For devices that - map connectors to encoders 1:1, the connector should be attached at - initialization time with a call to - drm_mode_connector_attach_encoder. The driver must - also set the drm_connector - encoder field to point to the attached - encoder. - - - Finally, drivers must initialize the connectors state change detection - with a call to drm_kms_helper_poll_init. If at - least one connector is pollable but can't generate hotplug interrupts - (indicated by the DRM_CONNECTOR_POLL_CONNECT and - DRM_CONNECTOR_POLL_DISCONNECT connector flags), a delayed work will - automatically be queued to periodically poll for changes. Connectors - that can generate hotplug interrupts must be marked with the - DRM_CONNECTOR_POLL_HPD flag instead, and their interrupt handler must - call drm_helper_hpd_irq_event. The function will - queue a delayed work to check the state of all connectors, but no - periodic polling will be done. - - - - Connector Operations - - Unless otherwise state, all operations are mandatory. - - - DPMS - void (*dpms)(struct drm_connector *connector, int mode); - - The DPMS operation sets the power state of a connector. The mode - argument is one of - - DRM_MODE_DPMS_ON - DRM_MODE_DPMS_STANDBY - DRM_MODE_DPMS_SUSPEND - DRM_MODE_DPMS_OFF - - - - In all but DPMS_ON mode the encoder to which the connector is attached - should put the display in low-power mode by driving its signals - appropriately. If more than one connector is attached to the encoder - care should be taken not to change the power state of other displays as - a side effect. Low-power mode should be propagated to the encoders and - CRTCs when all related connectors are put in low-power mode. - - - - Modes - int (*fill_modes)(struct drm_connector *connector, uint32_t max_width, - uint32_t max_height); - - Fill the mode list with all supported modes for the connector. If the - max_width and max_height - arguments are non-zero, the implementation must ignore all modes wider - than max_width or higher than - max_height. - - - The connector must also fill in this operation its - display_info - width_mm and - height_mm fields with the connected display - physical size in millimeters. The fields should be set to 0 if the value - isn't known or is not applicable (for instance for projector devices). - - - - Connection Status - - The connection status is updated through polling or hotplug events when - supported (see ). The status - value is reported to userspace through ioctls and must not be used - inside the driver, as it only gets initialized by a call to - drm_mode_getconnector from userspace. - - enum drm_connector_status (*detect)(struct drm_connector *connector, - bool force); - - Check to see if anything is attached to the connector. The - force parameter is set to false whilst polling or - to true when checking the connector due to user request. - force can be used by the driver to avoid - expensive, destructive operations during automated probing. - - - Return connector_status_connected if something is connected to the - connector, connector_status_disconnected if nothing is connected and - connector_status_unknown if the connection state isn't known. - - - Drivers should only return connector_status_connected if the connection - status has really been probed as connected. Connectors that can't detect - the connection status, or failed connection status probes, should return - connector_status_unknown. - - - - Miscellaneous - - - void (*set_property)(struct drm_connector *connector, - struct drm_property *property, uint64_t value); - - Set the value of the given connector property to - value. See - for more information about properties. - - - - void (*destroy)(struct drm_connector *connector); - - Destroy the connector when not needed anymore. See - . - - - - - - - - Cleanup - - The DRM core manages its objects' lifetime. When an object is not needed - anymore the core calls its destroy function, which must clean up and - free every resource allocated for the object. Every - drm_*_init call must be matched with a - corresponding drm_*_cleanup call to cleanup CRTCs - (drm_crtc_cleanup), planes - (drm_plane_cleanup), encoders - (drm_encoder_cleanup) and connectors - (drm_connector_cleanup). Furthermore, connectors - that have been added to sysfs must be removed by a call to - drm_connector_unregister before calling - drm_connector_cleanup. - - - Connectors state change detection must be cleanup up with a call to - drm_kms_helper_poll_fini. - - - - Output discovery and initialization example - base; - drm_connector_init(dev, &intel_output->base, - &intel_crt_connector_funcs, DRM_MODE_CONNECTOR_VGA); - - drm_encoder_init(dev, &intel_output->enc, &intel_crt_enc_funcs, - DRM_MODE_ENCODER_DAC); - - drm_mode_connector_attach_encoder(&intel_output->base, - &intel_output->enc); - - /* Set up the DDC bus. */ - intel_output->ddc_bus = intel_i2c_create(dev, GPIOA, "CRTDDC_A"); - if (!intel_output->ddc_bus) { - dev_printk(KERN_ERR, &dev->pdev->dev, "DDC bus registration " - "failed.\n"); - return; - } - - intel_output->type = INTEL_OUTPUT_ANALOG; - connector->interlace_allowed = 0; - connector->doublescan_allowed = 0; - - drm_encoder_helper_add(&intel_output->enc, &intel_crt_helper_funcs); - drm_connector_helper_add(connector, &intel_crt_connector_helper_funcs); - - drm_connector_register(connector); -}]]> - - In the example above (taken from the i915 driver), a CRTC, connector and - encoder combination is created. A device-specific i2c bus is also - created for fetching EDID data and performing monitor detection. Once - the process is complete, the new connector is registered with sysfs to - make its properties available to applications. - - - - KMS API Functions -!Edrivers/gpu/drm/drm_crtc.c - - - KMS Data Structures -!Iinclude/drm/drm_crtc.h - - - KMS Locking -!Pdrivers/gpu/drm/drm_modeset_lock.c kms locking -!Iinclude/drm/drm_modeset_lock.h -!Edrivers/gpu/drm/drm_modeset_lock.c - - - - - - - Mode Setting Helper Functions - - The plane, CRTC, encoder and connector functions provided by the drivers - implement the DRM API. They're called by the DRM core and ioctl handlers - to handle device state changes and configuration request. As implementing - those functions often requires logic not specific to drivers, mid-layer - helper functions are available to avoid duplicating boilerplate code. - - - The DRM core contains one mid-layer implementation. The mid-layer provides - implementations of several plane, CRTC, encoder and connector functions - (called from the top of the mid-layer) that pre-process requests and call - lower-level functions provided by the driver (at the bottom of the - mid-layer). For instance, the - drm_crtc_helper_set_config function can be used to - fill the struct drm_crtc_funcs - set_config field. When called, it will split - the set_config operation in smaller, simpler - operations and call the driver to handle them. - - - To use the mid-layer, drivers call drm_crtc_helper_add, - drm_encoder_helper_add and - drm_connector_helper_add functions to install their - mid-layer bottom operations handlers, and fill the - drm_crtc_funcs, - drm_encoder_funcs and - drm_connector_funcs structures with pointers to - the mid-layer top API functions. Installing the mid-layer bottom operation - handlers is best done right after registering the corresponding KMS object. - - - The mid-layer is not split between CRTC, encoder and connector operations. - To use it, a driver must provide bottom functions for all of the three KMS - entities. - - - Helper Functions - - - int drm_crtc_helper_set_config(struct drm_mode_set *set); - - The drm_crtc_helper_set_config helper function - is a CRTC set_config implementation. It - first tries to locate the best encoder for each connector by calling - the connector best_encoder helper - operation. - - - After locating the appropriate encoders, the helper function will - call the mode_fixup encoder and CRTC helper - operations to adjust the requested mode, or reject it completely in - which case an error will be returned to the application. If the new - configuration after mode adjustment is identical to the current - configuration the helper function will return without performing any - other operation. - - - If the adjusted mode is identical to the current mode but changes to - the frame buffer need to be applied, the - drm_crtc_helper_set_config function will call - the CRTC mode_set_base helper operation. If - the adjusted mode differs from the current mode, or if the - mode_set_base helper operation is not - provided, the helper function performs a full mode set sequence by - calling the prepare, - mode_set and - commit CRTC and encoder helper operations, - in that order. - - - - void drm_helper_connector_dpms(struct drm_connector *connector, int mode); - - The drm_helper_connector_dpms helper function - is a connector dpms implementation that - tracks power state of connectors. To use the function, drivers must - provide dpms helper operations for CRTCs - and encoders to apply the DPMS state to the device. - - - The mid-layer doesn't track the power state of CRTCs and encoders. - The dpms helper operations can thus be - called with a mode identical to the currently active mode. - - - - int drm_helper_probe_single_connector_modes(struct drm_connector *connector, - uint32_t maxX, uint32_t maxY); - - The drm_helper_probe_single_connector_modes helper - function is a connector fill_modes - implementation that updates the connection status for the connector - and then retrieves a list of modes by calling the connector - get_modes helper operation. - - - If the helper operation returns no mode, and if the connector status - is connector_status_connected, standard VESA DMT modes up to - 1024x768 are automatically added to the modes list by a call to - drm_add_modes_noedid. - - - The function then filters out modes larger than - max_width and max_height - if specified. It finally calls the optional connector - mode_valid helper operation for each mode in - the probed list to check whether the mode is valid for the connector. - - - - - - CRTC Helper Operations - - - bool (*mode_fixup)(struct drm_crtc *crtc, - const struct drm_display_mode *mode, - struct drm_display_mode *adjusted_mode); - - Let CRTCs adjust the requested mode or reject it completely. This - operation returns true if the mode is accepted (possibly after being - adjusted) or false if it is rejected. - - - The mode_fixup operation should reject the - mode if it can't reasonably use it. The definition of "reasonable" - is currently fuzzy in this context. One possible behaviour would be - to set the adjusted mode to the panel timings when a fixed-mode - panel is used with hardware capable of scaling. Another behaviour - would be to accept any input mode and adjust it to the closest mode - supported by the hardware (FIXME: This needs to be clarified). - - - - int (*mode_set_base)(struct drm_crtc *crtc, int x, int y, - struct drm_framebuffer *old_fb) - - Move the CRTC on the current frame buffer (stored in - crtc->fb) to position (x,y). Any of the frame - buffer, x position or y position may have been modified. - - - This helper operation is optional. If not provided, the - drm_crtc_helper_set_config function will fall - back to the mode_set helper operation. - - - FIXME: Why are x and y passed as arguments, as they can be accessed - through crtc->x and - crtc->y? - - - - void (*prepare)(struct drm_crtc *crtc); - - Prepare the CRTC for mode setting. This operation is called after - validating the requested mode. Drivers use it to perform - device-specific operations required before setting the new mode. - - - - int (*mode_set)(struct drm_crtc *crtc, struct drm_display_mode *mode, - struct drm_display_mode *adjusted_mode, int x, int y, - struct drm_framebuffer *old_fb); - - Set a new mode, position and frame buffer. Depending on the device - requirements, the mode can be stored internally by the driver and - applied in the commit operation, or - programmed to the hardware immediately. - - - The mode_set operation returns 0 on success - or a negative error code if an error occurs. - - - - void (*commit)(struct drm_crtc *crtc); - - Commit a mode. This operation is called after setting the new mode. - Upon return the device must use the new mode and be fully - operational. - - - - - - Encoder Helper Operations - - - bool (*mode_fixup)(struct drm_encoder *encoder, - const struct drm_display_mode *mode, - struct drm_display_mode *adjusted_mode); - - Let encoders adjust the requested mode or reject it completely. This - operation returns true if the mode is accepted (possibly after being - adjusted) or false if it is rejected. See the - mode_fixup CRTC helper - operation for an explanation of the allowed adjustments. - - - - void (*prepare)(struct drm_encoder *encoder); - - Prepare the encoder for mode setting. This operation is called after - validating the requested mode. Drivers use it to perform - device-specific operations required before setting the new mode. - - - - void (*mode_set)(struct drm_encoder *encoder, - struct drm_display_mode *mode, - struct drm_display_mode *adjusted_mode); - - Set a new mode. Depending on the device requirements, the mode can - be stored internally by the driver and applied in the - commit operation, or programmed to the - hardware immediately. - - - - void (*commit)(struct drm_encoder *encoder); - - Commit a mode. This operation is called after setting the new mode. - Upon return the device must use the new mode and be fully - operational. - - - - - - Connector Helper Operations - - - struct drm_encoder *(*best_encoder)(struct drm_connector *connector); - - Return a pointer to the best encoder for the connecter. Device that - map connectors to encoders 1:1 simply return the pointer to the - associated encoder. This operation is mandatory. - - - - int (*get_modes)(struct drm_connector *connector); - - Fill the connector's probed_modes list - by parsing EDID data with drm_add_edid_modes, - adding standard VESA DMT modes with drm_add_modes_noedid, - or calling drm_mode_probed_add directly for every - supported mode and return the number of modes it has detected. This - operation is mandatory. - - - Note that the caller function will automatically add standard VESA - DMT modes up to 1024x768 if the get_modes - helper operation returns no mode and if the connector status is - connector_status_connected. There is no need to call - drm_add_edid_modes manually in that case. - - - When adding modes manually the driver creates each mode with a call to - drm_mode_create and must fill the following fields. - - - __u32 type; - - Mode type bitmask, a combination of - - - DRM_MODE_TYPE_BUILTIN - not used? - - - DRM_MODE_TYPE_CLOCK_C - not used? - - - DRM_MODE_TYPE_CRTC_C - not used? - - - - DRM_MODE_TYPE_PREFERRED - The preferred mode for the connector - - - not used? - - - - DRM_MODE_TYPE_DEFAULT - not used? - - - DRM_MODE_TYPE_USERDEF - not used? - - - DRM_MODE_TYPE_DRIVER - - - The mode has been created by the driver (as opposed to - to user-created modes). - - - - - Drivers must set the DRM_MODE_TYPE_DRIVER bit for all modes they - create, and set the DRM_MODE_TYPE_PREFERRED bit for the preferred - mode. - - - - __u32 clock; - Pixel clock frequency in kHz unit - - - __u16 hdisplay, hsync_start, hsync_end, htotal; - __u16 vdisplay, vsync_start, vsync_end, vtotal; - Horizontal and vertical timing information - <----------------><-------------><--------------> - - //////////////////////| - ////////////////////// | - ////////////////////// |.................. ................ - _______________ - - <----- [hv]display -----> - <------------- [hv]sync_start ------------> - <--------------------- [hv]sync_end ---------------------> - <-------------------------------- [hv]total -----------------------------> -]]> - - - __u16 hskew; - __u16 vscan; - Unknown - - - __u32 flags; - - Mode flags, a combination of - - - DRM_MODE_FLAG_PHSYNC - - Horizontal sync is active high - - - - DRM_MODE_FLAG_NHSYNC - - Horizontal sync is active low - - - - DRM_MODE_FLAG_PVSYNC - - Vertical sync is active high - - - - DRM_MODE_FLAG_NVSYNC - - Vertical sync is active low - - - - DRM_MODE_FLAG_INTERLACE - - Mode is interlaced - - - - DRM_MODE_FLAG_DBLSCAN - - Mode uses doublescan - - - - DRM_MODE_FLAG_CSYNC - - Mode uses composite sync - - - - DRM_MODE_FLAG_PCSYNC - - Composite sync is active high - - - - DRM_MODE_FLAG_NCSYNC - - Composite sync is active low - - - - DRM_MODE_FLAG_HSKEW - - hskew provided (not used?) - - - - DRM_MODE_FLAG_BCAST - - not used? - - - - DRM_MODE_FLAG_PIXMUX - - not used? - - - - DRM_MODE_FLAG_DBLCLK - - not used? - - - - DRM_MODE_FLAG_CLKDIV2 - - ? - - - - - - Note that modes marked with the INTERLACE or DBLSCAN flags will be - filtered out by - drm_helper_probe_single_connector_modes if - the connector's interlace_allowed or - doublescan_allowed field is set to 0. - - - - char name[DRM_DISPLAY_MODE_LEN]; - - Mode name. The driver must call - drm_mode_set_name to fill the mode name from - hdisplay, - vdisplay and interlace flag after - filling the corresponding fields. - - - - - - The vrefresh value is computed by - drm_helper_probe_single_connector_modes. - - - When parsing EDID data, drm_add_edid_modes fills the - connector display_info - width_mm and - height_mm fields. When creating modes - manually the get_modes helper operation must - set the display_info - width_mm and - height_mm fields if they haven't been set - already (for instance at initialization time when a fixed-size panel is - attached to the connector). The mode width_mm - and height_mm fields are only used internally - during EDID parsing and should not be set when creating modes manually. - - - - int (*mode_valid)(struct drm_connector *connector, - struct drm_display_mode *mode); - - Verify whether a mode is valid for the connector. Return MODE_OK for - supported modes and one of the enum drm_mode_status values (MODE_*) - for unsupported modes. This operation is optional. - - - As the mode rejection reason is currently not used beside for - immediately removing the unsupported mode, an implementation can - return MODE_BAD regardless of the exact reason why the mode is not - valid. - - - Note that the mode_valid helper operation is - only called for modes detected by the device, and - not for modes set by the user through the CRTC - set_config operation. - - - - - - Atomic Modeset Helper Functions Reference - - Overview -!Pdrivers/gpu/drm/drm_atomic_helper.c overview - - - Implementing Asynchronous Atomic Commit -!Pdrivers/gpu/drm/drm_atomic_helper.c implementing async commit - - - Atomic State Reset and Initialization -!Pdrivers/gpu/drm/drm_atomic_helper.c atomic state reset and initialization - -!Iinclude/drm/drm_atomic_helper.h -!Edrivers/gpu/drm/drm_atomic_helper.c - - - Modeset Helper Functions Reference -!Iinclude/drm/drm_crtc_helper.h -!Edrivers/gpu/drm/drm_crtc_helper.c -!Pdrivers/gpu/drm/drm_crtc_helper.c overview - - - Output Probing Helper Functions Reference -!Pdrivers/gpu/drm/drm_probe_helper.c output probing helper overview -!Edrivers/gpu/drm/drm_probe_helper.c - - - fbdev Helper Functions Reference -!Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers -!Edrivers/gpu/drm/drm_fb_helper.c -!Iinclude/drm/drm_fb_helper.h - - - Display Port Helper Functions Reference -!Pdrivers/gpu/drm/drm_dp_helper.c dp helpers -!Iinclude/drm/drm_dp_helper.h -!Edrivers/gpu/drm/drm_dp_helper.c - - - Display Port MST Helper Functions Reference -!Pdrivers/gpu/drm/drm_dp_mst_topology.c dp mst helper -!Iinclude/drm/drm_dp_mst_helper.h -!Edrivers/gpu/drm/drm_dp_mst_topology.c - - - MIPI DSI Helper Functions Reference -!Pdrivers/gpu/drm/drm_mipi_dsi.c dsi helpers -!Iinclude/drm/drm_mipi_dsi.h -!Edrivers/gpu/drm/drm_mipi_dsi.c - - - EDID Helper Functions Reference -!Edrivers/gpu/drm/drm_edid.c - - - Rectangle Utilities Reference -!Pinclude/drm/drm_rect.h rect utils -!Iinclude/drm/drm_rect.h -!Edrivers/gpu/drm/drm_rect.c - - - Flip-work Helper Reference -!Pinclude/drm/drm_flip_work.h flip utils -!Iinclude/drm/drm_flip_work.h -!Edrivers/gpu/drm/drm_flip_work.c - - - HDMI Infoframes Helper Reference - - Strictly speaking this is not a DRM helper library but generally useable - by any driver interfacing with HDMI outputs like v4l or alsa drivers. - But it nicely fits into the overall topic of mode setting helper - libraries and hence is also included here. - -!Iinclude/linux/hdmi.h -!Edrivers/video/hdmi.c - - - Plane Helper Reference -!Edrivers/gpu/drm/drm_plane_helper.c -!Pdrivers/gpu/drm/drm_plane_helper.c overview - - - Tile group -!Pdrivers/gpu/drm/drm_crtc.c Tile group - - - Bridges - - Overview -!Pdrivers/gpu/drm/drm_bridge.c overview - - - Default bridge callback sequence -!Pdrivers/gpu/drm/drm_bridge.c bridge callbacks - -!Edrivers/gpu/drm/drm_bridge.c - - - - - - - KMS Properties - - Drivers may need to expose additional parameters to applications than - those described in the previous sections. KMS supports attaching - properties to CRTCs, connectors and planes and offers a userspace API to - list, get and set the property values. - - - Properties are identified by a name that uniquely defines the property - purpose, and store an associated value. For all property types except blob - properties the value is a 64-bit unsigned integer. - - - KMS differentiates between properties and property instances. Drivers - first create properties and then create and associate individual instances - of those properties to objects. A property can be instantiated multiple - times and associated with different objects. Values are stored in property - instances, and all other property information are stored in the property - and shared between all instances of the property. - - - Every property is created with a type that influences how the KMS core - handles the property. Supported property types are - - - DRM_MODE_PROP_RANGE - Range properties report their minimum and maximum - admissible values. The KMS core verifies that values set by - application fit in that range. - - - DRM_MODE_PROP_ENUM - Enumerated properties take a numerical value that - ranges from 0 to the number of enumerated values defined by the - property minus one, and associate a free-formed string name to each - value. Applications can retrieve the list of defined value-name pairs - and use the numerical value to get and set property instance values. - - - - DRM_MODE_PROP_BITMASK - Bitmask properties are enumeration properties that - additionally restrict all enumerated values to the 0..63 range. - Bitmask property instance values combine one or more of the - enumerated bits defined by the property. - - - DRM_MODE_PROP_BLOB - Blob properties store a binary blob without any format - restriction. The binary blobs are created as KMS standalone objects, - and blob property instance values store the ID of their associated - blob object. - Blob properties are only used for the connector EDID property - and cannot be created by drivers. - - - - - To create a property drivers call one of the following functions depending - on the property type. All property creation functions take property flags - and name, as well as type-specific arguments. - - - struct drm_property *drm_property_create_range(struct drm_device *dev, int flags, - const char *name, - uint64_t min, uint64_t max); - Create a range property with the given minimum and maximum - values. - - - struct drm_property *drm_property_create_enum(struct drm_device *dev, int flags, - const char *name, - const struct drm_prop_enum_list *props, - int num_values); - Create an enumerated property. The props - argument points to an array of num_values - value-name pairs. - - - struct drm_property *drm_property_create_bitmask(struct drm_device *dev, - int flags, const char *name, - const struct drm_prop_enum_list *props, - int num_values); - Create a bitmask property. The props - argument points to an array of num_values - value-name pairs. - - - - - Properties can additionally be created as immutable, in which case they - will be read-only for applications but can be modified by the driver. To - create an immutable property drivers must set the DRM_MODE_PROP_IMMUTABLE - flag at property creation time. - - - When no array of value-name pairs is readily available at property - creation time for enumerated or range properties, drivers can create - the property using the drm_property_create function - and manually add enumeration value-name pairs by calling the - drm_property_add_enum function. Care must be taken to - properly specify the property type through the flags - argument. - - - After creating properties drivers can attach property instances to CRTC, - connector and plane objects by calling the - drm_object_attach_property. The function takes a - pointer to the target object, a pointer to the previously created property - and an initial instance value. - - - Existing KMS Properties - - The following table gives description of drm properties exposed by various - modules/drivers. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Owner Module/DriversGroupProperty NameTypeProperty ValuesObject attachedDescription/Restrictions
DRMGeneric“rotation”BITMASK{ 0, "rotate-0" }, - { 1, "rotate-90" }, - { 2, "rotate-180" }, - { 3, "rotate-270" }, - { 4, "reflect-x" }, - { 5, "reflect-y" }CRTC, Planerotate-(degrees) rotates the image by the specified amount in degrees - in counter clockwise direction. reflect-x and reflect-y reflects the - image along the specified axis prior to rotation
Connector“EDID”BLOB | IMMUTABLE0ConnectorContains id of edid blob ptr object.
“DPMS”ENUM{ “On”, “Standby”, “Suspend”, “Off” }ConnectorContains DPMS operation mode value.
“PATH”BLOB | IMMUTABLE0ConnectorContains topology path to a connector.
“TILE”BLOB | IMMUTABLE0ConnectorContains tiling information for a connector.
“CRTC_ID”OBJECTDRM_MODE_OBJECT_CRTCConnectorCRTC that connector is attached to (atomic)
Plane“type”ENUM | IMMUTABLE{ "Overlay", "Primary", "Cursor" }PlanePlane type
“SRC_X”RANGEMin=0, Max=UINT_MAXPlaneScanout source x coordinate in 16.16 fixed point (atomic)
“SRC_Y”RANGEMin=0, Max=UINT_MAXPlaneScanout source y coordinate in 16.16 fixed point (atomic)
“SRC_W”RANGEMin=0, Max=UINT_MAXPlaneScanout source width in 16.16 fixed point (atomic)
“SRC_H”RANGEMin=0, Max=UINT_MAXPlaneScanout source height in 16.16 fixed point (atomic)
“CRTC_X”SIGNED_RANGEMin=INT_MIN, Max=INT_MAXPlaneScanout CRTC (destination) x coordinate (atomic)
“CRTC_Y”SIGNED_RANGEMin=INT_MIN, Max=INT_MAXPlaneScanout CRTC (destination) y coordinate (atomic)
“CRTC_W”RANGEMin=0, Max=UINT_MAXPlaneScanout CRTC (destination) width (atomic)
“CRTC_H”RANGEMin=0, Max=UINT_MAXPlaneScanout CRTC (destination) height (atomic)
“FB_ID”OBJECTDRM_MODE_OBJECT_FBPlaneScanout framebuffer (atomic)
“CRTC_ID”OBJECTDRM_MODE_OBJECT_CRTCPlaneCRTC that plane is attached to (atomic)
DVI-I“subconnector”ENUM{ “Unknown”, “DVI-D”, “DVI-A” }ConnectorTBD
“select subconnector”ENUM{ “Automatic”, “DVI-D”, “DVI-A” }ConnectorTBD
TV“subconnector”ENUM{ "Unknown", "Composite", "SVIDEO", "Component", "SCART" }ConnectorTBD
“select subconnector”ENUM{ "Automatic", "Composite", "SVIDEO", "Component", "SCART" }ConnectorTBD
“mode”ENUM{ "NTSC_M", "NTSC_J", "NTSC_443", "PAL_B" } etc.ConnectorTBD
“left margin”RANGEMin=0, Max=100ConnectorTBD
“right margin”RANGEMin=0, Max=100ConnectorTBD
“top margin”RANGEMin=0, Max=100ConnectorTBD
“bottom margin”RANGEMin=0, Max=100ConnectorTBD
“brightness”RANGEMin=0, Max=100ConnectorTBD
“contrast”RANGEMin=0, Max=100ConnectorTBD
“flicker reduction”RANGEMin=0, Max=100ConnectorTBD
“overscan”RANGEMin=0, Max=100ConnectorTBD
“saturation”RANGEMin=0, Max=100ConnectorTBD
“hue”RANGEMin=0, Max=100ConnectorTBD
Virtual GPU“suggested X”RANGEMin=0, Max=0xffffffffConnectorproperty to suggest an X offset for a connector
“suggested Y”RANGEMin=0, Max=0xffffffffConnectorproperty to suggest an Y offset for a connector
Optional“scaling mode”ENUM{ "None", "Full", "Center", "Full aspect" }ConnectorTBD
"aspect ratio"ENUM{ "None", "4:3", "16:9" }ConnectorDRM property to set aspect ratio from user space app. - This enum is made generic to allow addition of custom aspect - ratios.
“dirty”ENUM | IMMUTABLE{ "Off", "On", "Annotate" }ConnectorTBD
i915Generic"Broadcast RGB"ENUM{ "Automatic", "Full", "Limited 16:235" }ConnectorTBD
“audio”ENUM{ "force-dvi", "off", "auto", "on" }ConnectorTBD
SDVO-TV“mode”ENUM{ "NTSC_M", "NTSC_J", "NTSC_443", "PAL_B" } etc.ConnectorTBD
"left_margin"RANGEMin=0, Max= SDVO dependentConnectorTBD
"right_margin"RANGEMin=0, Max= SDVO dependentConnectorTBD
"top_margin"RANGEMin=0, Max= SDVO dependentConnectorTBD
"bottom_margin"RANGEMin=0, Max= SDVO dependentConnectorTBD
“hpos”RANGEMin=0, Max= SDVO dependentConnectorTBD
“vpos”RANGEMin=0, Max= SDVO dependentConnectorTBD
“contrast”RANGEMin=0, Max= SDVO dependentConnectorTBD
“saturation”RANGEMin=0, Max= SDVO dependentConnectorTBD
“hue”RANGEMin=0, Max= SDVO dependentConnectorTBD
“sharpness”RANGEMin=0, Max= SDVO dependentConnectorTBD
“flicker_filter”RANGEMin=0, Max= SDVO dependentConnectorTBD
“flicker_filter_adaptive”RANGEMin=0, Max= SDVO dependentConnectorTBD
“flicker_filter_2d”RANGEMin=0, Max= SDVO dependentConnectorTBD
“tv_chroma_filter”RANGEMin=0, Max= SDVO dependentConnectorTBD
“tv_luma_filter”RANGEMin=0, Max= SDVO dependentConnectorTBD
“dot_crawl”RANGEMin=0, Max=1ConnectorTBD
SDVO-TV/LVDS“brightness”RANGEMin=0, Max= SDVO dependentConnectorTBD
CDV gma-500Generic"Broadcast RGB"ENUM{ “Full”, “Limited 16:235” }ConnectorTBD
"Broadcast RGB"ENUM{ “off”, “auto”, “on” }ConnectorTBD
PoulsboGeneric“backlight”RANGEMin=0, Max=100ConnectorTBD
SDVO-TV“mode”ENUM{ "NTSC_M", "NTSC_J", "NTSC_443", "PAL_B" } etc.ConnectorTBD
"left_margin"RANGEMin=0, Max= SDVO dependentConnectorTBD
"right_margin"RANGEMin=0, Max= SDVO dependentConnectorTBD
"top_margin"RANGEMin=0, Max= SDVO dependentConnectorTBD
"bottom_margin"RANGEMin=0, Max= SDVO dependentConnectorTBD
“hpos”RANGEMin=0, Max= SDVO dependentConnectorTBD
“vpos”RANGEMin=0, Max= SDVO dependentConnectorTBD
“contrast”RANGEMin=0, Max= SDVO dependentConnectorTBD
“saturation”RANGEMin=0, Max= SDVO dependentConnectorTBD
“hue”RANGEMin=0, Max= SDVO dependentConnectorTBD
“sharpness”RANGEMin=0, Max= SDVO dependentConnectorTBD
“flicker_filter”RANGEMin=0, Max= SDVO dependentConnectorTBD
“flicker_filter_adaptive”RANGEMin=0, Max= SDVO dependentConnectorTBD
“flicker_filter_2d”RANGEMin=0, Max= SDVO dependentConnectorTBD
“tv_chroma_filter”RANGEMin=0, Max= SDVO dependentConnectorTBD
“tv_luma_filter”RANGEMin=0, Max= SDVO dependentConnectorTBD
“dot_crawl”RANGEMin=0, Max=1ConnectorTBD
SDVO-TV/LVDS“brightness”RANGEMin=0, Max= SDVO dependentConnectorTBD
armadaCRTC"CSC_YUV"ENUM{ "Auto" , "CCIR601", "CCIR709" }CRTCTBD
"CSC_RGB"ENUM{ "Auto", "Computer system", "Studio" }CRTCTBD
Overlay"colorkey"RANGEMin=0, Max=0xffffffPlaneTBD
"colorkey_min"RANGEMin=0, Max=0xffffffPlaneTBD
"colorkey_max"RANGEMin=0, Max=0xffffffPlaneTBD
"colorkey_val"RANGEMin=0, Max=0xffffffPlaneTBD
"colorkey_alpha"RANGEMin=0, Max=0xffffffPlaneTBD
"colorkey_mode"ENUM{ "disabled", "Y component", "U component" - , "V component", "RGB", “R component", "G component", "B component" }PlaneTBD
"brightness"RANGEMin=0, Max=256 + 255PlaneTBD
"contrast"RANGEMin=0, Max=0x7fffPlaneTBD
"saturation"RANGEMin=0, Max=0x7fffPlaneTBD
exynosCRTC“mode”ENUM{ "normal", "blank" }CRTCTBD
Overlay“zpos”RANGEMin=0, Max=MAX_PLANE-1PlaneTBD
i2c/ch7006_drvGeneric“scale”RANGEMin=0, Max=2ConnectorTBD
TV“mode”ENUM{ "PAL", "PAL-M","PAL-N"}, ”PAL-Nc" - , "PAL-60", "NTSC-M", "NTSC-J" }ConnectorTBD
nouveauNV10 Overlay"colorkey"RANGEMin=0, Max=0x01ffffffPlaneTBD
“contrast”RANGEMin=0, Max=8192-1PlaneTBD
“brightness”RANGEMin=0, Max=1024PlaneTBD
“hue”RANGEMin=0, Max=359PlaneTBD
“saturation”RANGEMin=0, Max=8192-1PlaneTBD
“iturbt_709”RANGEMin=0, Max=1PlaneTBD
Nv04 Overlay“colorkey”RANGEMin=0, Max=0x01ffffffPlaneTBD
“brightness”RANGEMin=0, Max=1024PlaneTBD
Display“dithering mode”ENUM{ "auto", "off", "on" }ConnectorTBD
“dithering depth”ENUM{ "auto", "off", "on", "static 2x2", "dynamic 2x2", "temporal" }ConnectorTBD
“underscan”ENUM{ "auto", "6 bpc", "8 bpc" }ConnectorTBD
“underscan hborder”RANGEMin=0, Max=128ConnectorTBD
“underscan vborder”RANGEMin=0, Max=128ConnectorTBD
“vibrant hue”RANGEMin=0, Max=180ConnectorTBD
“color vibrance”RANGEMin=0, Max=200ConnectorTBD
omapGeneric“zorder”RANGEMin=0, Max=3CRTC, PlaneTBD
qxlGeneric“hotplug_mode_update"RANGEMin=0, Max=1ConnectorTBD
radeonDVI-I“coherent”RANGEMin=0, Max=1ConnectorTBD
DAC enable load detect“load detection”RANGEMin=0, Max=1ConnectorTBD
TV Standard"tv standard"ENUM{ "ntsc", "pal", "pal-m", "pal-60", "ntsc-j" - , "scart-pal", "pal-cn", "secam" }ConnectorTBD
legacy TMDS PLL detect"tmds_pll"ENUM{ "driver", "bios" }-TBD
Underscan"underscan"ENUM{ "off", "on", "auto" }ConnectorTBD
"underscan hborder"RANGEMin=0, Max=128ConnectorTBD
"underscan vborder"RANGEMin=0, Max=128ConnectorTBD
Audio“audio”ENUM{ "off", "on", "auto" }ConnectorTBD
FMT Dithering“dither”ENUM{ "off", "on" }ConnectorTBD
rcar-duGeneric"alpha"RANGEMin=0, Max=255PlaneTBD
"colorkey"RANGEMin=0, Max=0x01ffffffPlaneTBD
"zpos"RANGEMin=1, Max=7PlaneTBD
- - - - - - - Vertical Blanking - - Vertical blanking plays a major role in graphics rendering. To achieve - tear-free display, users must synchronize page flips and/or rendering to - vertical blanking. The DRM API offers ioctls to perform page flips - synchronized to vertical blanking and wait for vertical blanking. - - - The DRM core handles most of the vertical blanking management logic, which - involves filtering out spurious interrupts, keeping race-free blanking - counters, coping with counter wrap-around and resets and keeping use - counts. It relies on the driver to generate vertical blanking interrupts - and optionally provide a hardware vertical blanking counter. Drivers must - implement the following operations. - - - - int (*enable_vblank) (struct drm_device *dev, int crtc); -void (*disable_vblank) (struct drm_device *dev, int crtc); - - Enable or disable vertical blanking interrupts for the given CRTC. - - - - u32 (*get_vblank_counter) (struct drm_device *dev, int crtc); - - Retrieve the value of the vertical blanking counter for the given - CRTC. If the hardware maintains a vertical blanking counter its value - should be returned. Otherwise drivers can use the - drm_vblank_count helper function to handle this - operation. - - - - - Drivers must initialize the vertical blanking handling core with a call to - drm_vblank_init in their - load operation. The function will set the struct - drm_device - vblank_disable_allowed field to 0. This will - keep vertical blanking interrupts enabled permanently until the first mode - set operation, where vblank_disable_allowed is - set to 1. The reason behind this is not clear. Drivers can set the field - to 1 after calling drm_vblank_init to make vertical - blanking interrupts dynamically managed from the beginning. - - - Vertical blanking interrupts can be enabled by the DRM core or by drivers - themselves (for instance to handle page flipping operations). The DRM core - maintains a vertical blanking use count to ensure that the interrupts are - not disabled while a user still needs them. To increment the use count, - drivers call drm_vblank_get. Upon return vertical - blanking interrupts are guaranteed to be enabled. - - - To decrement the use count drivers call - drm_vblank_put. Only when the use count drops to zero - will the DRM core disable the vertical blanking interrupts after a delay - by scheduling a timer. The delay is accessible through the vblankoffdelay - module parameter or the drm_vblank_offdelay global - variable and expressed in milliseconds. Its default value is 5000 ms. - Zero means never disable, and a negative value means disable immediately. - Drivers may override the behaviour by setting the - drm_device - vblank_disable_immediate flag, which when set - causes vblank interrupts to be disabled immediately regardless of the - drm_vblank_offdelay value. The flag should only be set if there's a - properly working hardware vblank counter present. - - - When a vertical blanking interrupt occurs drivers only need to call the - drm_handle_vblank function to account for the - interrupt. - - - Resources allocated by drm_vblank_init must be freed - with a call to drm_vblank_cleanup in the driver - unload operation handler. - - - Vertical Blanking and Interrupt Handling Functions Reference -!Edrivers/gpu/drm/drm_irq.c -!Finclude/drm/drmP.h drm_crtc_vblank_waitqueue - - - - - - - Open/Close, File Operations and IOCTLs - - Open and Close - int (*firstopen) (struct drm_device *); -void (*lastclose) (struct drm_device *); -int (*open) (struct drm_device *, struct drm_file *); -void (*preclose) (struct drm_device *, struct drm_file *); -void (*postclose) (struct drm_device *, struct drm_file *); - Open and close handlers. None of those methods are mandatory. - - - The firstopen method is called by the DRM core - for legacy UMS (User Mode Setting) drivers only when an application - opens a device that has no other opened file handle. UMS drivers can - implement it to acquire device resources. KMS drivers can't use the - method and must acquire resources in the load - method instead. - - - Similarly the lastclose method is called when - the last application holding a file handle opened on the device closes - it, for both UMS and KMS drivers. Additionally, the method is also - called at module unload time or, for hot-pluggable devices, when the - device is unplugged. The firstopen and - lastclose calls can thus be unbalanced. - - - The open method is called every time the device - is opened by an application. Drivers can allocate per-file private data - in this method and store them in the struct - drm_file driver_priv - field. Note that the open method is called - before firstopen. - - - The close operation is split into preclose and - postclose methods. Drivers must stop and - cleanup all per-file operations in the preclose - method. For instance pending vertical blanking and page flip events must - be cancelled. No per-file operation is allowed on the file handle after - returning from the preclose method. - - - Finally the postclose method is called as the - last step of the close operation, right before calling the - lastclose method if no other open file handle - exists for the device. Drivers that have allocated per-file private data - in the open method should free it here. - - - The lastclose method should restore CRTC and - plane properties to default value, so that a subsequent open of the - device will not inherit state from the previous user. It can also be - used to execute delayed power switching state changes, e.g. in - conjunction with the vga-switcheroo infrastructure. Beyond that KMS - drivers should not do any further cleanup. Only legacy UMS drivers might - need to clean up device state so that the vga console or an independent - fbdev driver could take over. - - - - File Operations - const struct file_operations *fops - File operations for the DRM device node. - - Drivers must define the file operations structure that forms the DRM - userspace API entry point, even though most of those operations are - implemented in the DRM core. The open, - release and ioctl - operations are handled by - - .owner = THIS_MODULE, - .open = drm_open, - .release = drm_release, - .unlocked_ioctl = drm_ioctl, - #ifdef CONFIG_COMPAT - .compat_ioctl = drm_compat_ioctl, - #endif - - - - Drivers that implement private ioctls that requires 32/64bit - compatibility support must provide their own - compat_ioctl handler that processes private - ioctls and calls drm_compat_ioctl for core ioctls. - - - The read and poll - operations provide support for reading DRM events and polling them. They - are implemented by - - .poll = drm_poll, - .read = drm_read, - .llseek = no_llseek, - - - - The memory mapping implementation varies depending on how the driver - manages memory. Pre-GEM drivers will use drm_mmap, - while GEM-aware drivers will use drm_gem_mmap. See - . - - .mmap = drm_gem_mmap, - - - - No other file operation is supported by the DRM API. - - - - IOCTLs - struct drm_ioctl_desc *ioctls; -int num_ioctls; - Driver-specific ioctls descriptors table. - - Driver-specific ioctls numbers start at DRM_COMMAND_BASE. The ioctls - descriptors table is indexed by the ioctl number offset from the base - value. Drivers can use the DRM_IOCTL_DEF_DRV() macro to initialize the - table entries. - - - DRM_IOCTL_DEF_DRV(ioctl, func, flags) - - ioctl is the ioctl name. Drivers must define - the DRM_##ioctl and DRM_IOCTL_##ioctl macros to the ioctl number - offset from DRM_COMMAND_BASE and the ioctl number respectively. The - first macro is private to the device while the second must be exposed - to userspace in a public header. - - - func is a pointer to the ioctl handler function - compatible with the drm_ioctl_t type. - typedef int drm_ioctl_t(struct drm_device *dev, void *data, - struct drm_file *file_priv); - - - flags is a bitmask combination of the following - values. It restricts how the ioctl is allowed to be called. - - - DRM_AUTH - Only authenticated callers allowed - - - DRM_MASTER - The ioctl can only be called on the master file - handle - - - DRM_ROOT_ONLY - Only callers with the SYSADMIN capability allowed - - - DRM_CONTROL_ALLOW - The ioctl can only be called on a control - device - - - DRM_UNLOCKED - The ioctl handler will be called without locking - the DRM global mutex - - - - - - - - Legacy Support Code - - The section very briefly covers some of the old legacy support code which - is only used by old DRM drivers which have done a so-called shadow-attach - to the underlying device instead of registering as a real driver. This - also includes some of the old generic buffer management and command - submission code. Do not use any of this in new and modern drivers. - - - - Legacy Suspend/Resume - - The DRM core provides some suspend/resume code, but drivers wanting full - suspend/resume support should provide save() and restore() functions. - These are called at suspend, hibernate, or resume time, and should perform - any state save or restore required by your device across suspend or - hibernate states. - - int (*suspend) (struct drm_device *, pm_message_t state); - int (*resume) (struct drm_device *); - - Those are legacy suspend and resume methods which - only work with the legacy shadow-attach driver - registration functions. New driver should use the power management - interface provided by their bus type (usually through - the struct device_driver dev_pm_ops) and set - these methods to NULL. - - - - - Legacy DMA Services - - This should cover how DMA mapping etc. is supported by the core. - These functions are deprecated and should not be used. - - - - - - - - - - - Userland interfaces - - The DRM core exports several interfaces to applications, - generally intended to be used through corresponding libdrm - wrapper functions. In addition, drivers export device-specific - interfaces for use by userspace drivers & device-aware - applications through ioctls and sysfs files. - - - External interfaces include: memory mapping, context management, - DMA operations, AGP management, vblank control, fence - management, memory management, and output management. - - - Cover generic ioctls and sysfs layout here. We only need high-level - info, since man pages should cover the rest. - - - - - - Render nodes - - DRM core provides multiple character-devices for user-space to use. - Depending on which device is opened, user-space can perform a different - set of operations (mainly ioctls). The primary node is always created - and called card<num>. Additionally, a currently - unused control node, called controlD<num> is also - created. The primary node provides all legacy operations and - historically was the only interface used by userspace. With KMS, the - control node was introduced. However, the planned KMS control interface - has never been written and so the control node stays unused to date. - - - With the increased use of offscreen renderers and GPGPU applications, - clients no longer require running compositors or graphics servers to - make use of a GPU. But the DRM API required unprivileged clients to - authenticate to a DRM-Master prior to getting GPU access. To avoid this - step and to grant clients GPU access without authenticating, render - nodes were introduced. Render nodes solely serve render clients, that - is, no modesetting or privileged ioctls can be issued on render nodes. - Only non-global rendering commands are allowed. If a driver supports - render nodes, it must advertise it via the DRIVER_RENDER - DRM driver capability. If not supported, the primary node must be used - for render clients together with the legacy drmAuth authentication - procedure. - - - If a driver advertises render node support, DRM core will create a - separate render node called renderD<num>. There will - be one render node per device. No ioctls except PRIME-related ioctls - will be allowed on this node. Especially GEM_OPEN will be - explicitly prohibited. Render nodes are designed to avoid the - buffer-leaks, which occur if clients guess the flink names or mmap - offsets on the legacy interface. Additionally to this basic interface, - drivers must mark their driver-dependent render-only ioctls as - DRM_RENDER_ALLOW so render clients can use them. Driver - authors must be careful not to allow any privileged ioctls on render - nodes. - - - With render nodes, user-space can now control access to the render node - via basic file-system access-modes. A running graphics server which - authenticates clients on the privileged primary/legacy node is no longer - required. Instead, a client can open the render node and is immediately - granted GPU access. Communication between clients (or servers) is done - via PRIME. FLINK from render node to legacy node is not supported. New - clients must not use the insecure FLINK interface. - - - Besides dropping all modeset/global ioctls, render nodes also drop the - DRM-Master concept. There is no reason to associate render clients with - a DRM-Master as they are independent of any graphics server. Besides, - they must work without any running master, anyway. - Drivers must be able to run without a master object if they support - render nodes. If, on the 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. - - - - - - - VBlank event handling - - The DRM core exposes two vertical blank related ioctls: - - - DRM_IOCTL_WAIT_VBLANK - - - This takes a struct drm_wait_vblank structure as its argument, - and it is used to block or request a signal when a specified - vblank event occurs. - - - - - DRM_IOCTL_MODESET_CTL - - - This was only used for user-mode-settind drivers around - modesetting changes to allow the kernel to update the vblank - interrupt after 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. - - - - - - - - - - - DRM Drivers - - - - This second part of the DRM Developer's Guide documents driver code, - implementation details and also all the driver-specific userspace - interfaces. Especially since all hardware-acceleration interfaces to - userspace are driver specific for efficiency and other reasons these - interfaces can be rather substantial. Hence every driver has its own - chapter. - - - - - drm/i915 Intel GFX Driver - - The drm/i915 driver supports all (with the exception of some very early - models) integrated GFX chipsets with both Intel display and rendering - blocks. This excludes a set of SoC platforms with an SGX rendering unit, - those have basic support through the gma500 drm driver. - - - Core Driver Infrastructure - - This section covers core driver infrastructure used by both the display - and the GEM parts of the driver. - - - Runtime Power Management -!Pdrivers/gpu/drm/i915/intel_runtime_pm.c runtime pm -!Idrivers/gpu/drm/i915/intel_runtime_pm.c -!Idrivers/gpu/drm/i915/intel_uncore.c - - - Interrupt Handling -!Pdrivers/gpu/drm/i915/i915_irq.c interrupt handling -!Fdrivers/gpu/drm/i915/i915_irq.c intel_irq_init intel_irq_init_hw intel_hpd_init -!Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_disable_interrupts -!Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_enable_interrupts - - - Intel GVT-g Guest Support(vGPU) -!Pdrivers/gpu/drm/i915/i915_vgpu.c Intel GVT-g guest support -!Idrivers/gpu/drm/i915/i915_vgpu.c - - - - Display Hardware Handling - - This section covers everything related to the display hardware including - the mode setting infrastructure, plane, sprite and cursor handling and - display, output probing and related topics. - - - Mode Setting Infrastructure - - The i915 driver is thus far the only DRM driver which doesn't use the - common DRM helper code to implement mode setting sequences. Thus it - has its own tailor-made infrastructure for executing a display - configuration change. - - - - Frontbuffer Tracking -!Pdrivers/gpu/drm/i915/intel_frontbuffer.c frontbuffer tracking -!Idrivers/gpu/drm/i915/intel_frontbuffer.c -!Fdrivers/gpu/drm/i915/i915_gem.c i915_gem_track_fb - - - Display FIFO Underrun Reporting -!Pdrivers/gpu/drm/i915/intel_fifo_underrun.c fifo underrun handling -!Idrivers/gpu/drm/i915/intel_fifo_underrun.c - - - Plane Configuration - - This section covers plane configuration and composition with the - primary plane, sprites, cursors and overlays. This includes the - infrastructure to do atomic vsync'ed updates of all this state and - also tightly coupled topics like watermark setup and computation, - framebuffer compression and panel self refresh. - - - - Atomic Plane Helpers -!Pdrivers/gpu/drm/i915/intel_atomic_plane.c atomic plane helpers -!Idrivers/gpu/drm/i915/intel_atomic_plane.c - - - Output Probing - - This section covers output probing and related infrastructure like the - hotplug interrupt storm detection and mitigation code. Note that the - i915 driver still uses most of the common DRM helper code for output - probing, so those sections fully apply. - - - - Hotplug -!Pdrivers/gpu/drm/i915/intel_hotplug.c Hotplug -!Idrivers/gpu/drm/i915/intel_hotplug.c - - - High Definition Audio -!Pdrivers/gpu/drm/i915/intel_audio.c High Definition Audio over HDMI and Display Port -!Idrivers/gpu/drm/i915/intel_audio.c - - - Panel Self Refresh PSR (PSR/SRD) -!Pdrivers/gpu/drm/i915/intel_psr.c Panel Self Refresh (PSR/SRD) -!Idrivers/gpu/drm/i915/intel_psr.c - - - Frame Buffer Compression (FBC) -!Pdrivers/gpu/drm/i915/intel_fbc.c Frame Buffer Compression (FBC) -!Idrivers/gpu/drm/i915/intel_fbc.c - - - Display Refresh Rate Switching (DRRS) -!Pdrivers/gpu/drm/i915/intel_dp.c Display Refresh Rate Switching (DRRS) -!Fdrivers/gpu/drm/i915/intel_dp.c intel_dp_set_drrs_state -!Fdrivers/gpu/drm/i915/intel_dp.c intel_edp_drrs_enable -!Fdrivers/gpu/drm/i915/intel_dp.c intel_edp_drrs_disable -!Fdrivers/gpu/drm/i915/intel_dp.c intel_edp_drrs_invalidate -!Fdrivers/gpu/drm/i915/intel_dp.c intel_edp_drrs_flush -!Fdrivers/gpu/drm/i915/intel_dp.c intel_dp_drrs_init - - - - DPIO -!Pdrivers/gpu/drm/i915/i915_reg.h DPIO - - Dual channel PHY (VLV/CHV/BXT) - - - - - - - - - - - - - - - - - - CH0 - CH1 - - - - - CMN/PLL/REF - CMN/PLL/REF - - - PCS01 - PCS23 - PCS01 - PCS23 - - - TX0 - TX1 - TX2 - TX3 - TX0 - TX1 - TX2 - TX3 - - - DDI0 - DDI1 - - - -
- - Single channel PHY (CHV/BXT) - - - - - - - - - - - CH0 - - - - - CMN/PLL/REF - - - PCS01 - PCS23 - - - TX0 - TX1 - TX2 - TX3 - - - DDI2 - - - -
- - - - CSR firmware support for DMC -!Pdrivers/gpu/drm/i915/intel_csr.c csr support for dmc -!Idrivers/gpu/drm/i915/intel_csr.c - - - - - Memory Management and Command Submission - - This sections covers all things related to the GEM implementation in the - i915 driver. - - - Batchbuffer Parsing -!Pdrivers/gpu/drm/i915/i915_cmd_parser.c batch buffer command parser -!Idrivers/gpu/drm/i915/i915_cmd_parser.c - - - Batchbuffer Pools -!Pdrivers/gpu/drm/i915/i915_gem_batch_pool.c batch pool -!Idrivers/gpu/drm/i915/i915_gem_batch_pool.c - - - Logical Rings, Logical Ring Contexts and Execlists -!Pdrivers/gpu/drm/i915/intel_lrc.c Logical Rings, Logical Ring Contexts and Execlists -!Idrivers/gpu/drm/i915/intel_lrc.c - - - Global GTT views -!Pdrivers/gpu/drm/i915/i915_gem_gtt.c Global GTT views -!Idrivers/gpu/drm/i915/i915_gem_gtt.c - - - GTT Fences and Swizzling -!Idrivers/gpu/drm/i915/i915_gem_fence.c - - Global GTT Fence Handling -!Pdrivers/gpu/drm/i915/i915_gem_fence.c fence register handling - - - Hardware Tiling and Swizzling Details -!Pdrivers/gpu/drm/i915/i915_gem_fence.c tiling swizzling details - - - - Object Tiling IOCTLs -!Idrivers/gpu/drm/i915/i915_gem_tiling.c -!Pdrivers/gpu/drm/i915/i915_gem_tiling.c buffer object tiling - - - Buffer Object Eviction - - This section documents the interface functions for evicting buffer - objects to make space available in the virtual gpu address spaces. - Note that this is mostly orthogonal to shrinking buffer objects - caches, which has the goal to make main memory (shared with the gpu - through the unified memory architecture) available. - -!Idrivers/gpu/drm/i915/i915_gem_evict.c - - - Buffer Object Memory Shrinking - - This section documents the interface function for shrinking memory - usage of buffer object caches. Shrinking is used to make main memory - available. Note that this is mostly orthogonal to evicting buffer - objects, which has the goal to make space in gpu virtual address - spaces. - -!Idrivers/gpu/drm/i915/i915_gem_shrinker.c - - - - Tracing - - This sections covers all things related to the tracepoints implemented in - the i915 driver. - - - i915_ppgtt_create and i915_ppgtt_release -!Pdrivers/gpu/drm/i915/i915_trace.h i915_ppgtt_create and i915_ppgtt_release tracepoints - - - i915_context_create and i915_context_free -!Pdrivers/gpu/drm/i915/i915_trace.h i915_context_create and i915_context_free tracepoints - - - switch_mm -!Pdrivers/gpu/drm/i915/i915_trace.h switch_mm tracepoint - - - - -!Cdrivers/gpu/drm/i915/i915_irq.c - - diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl new file mode 100644 index 000000000..201dcd3c2 --- /dev/null +++ b/Documentation/DocBook/gpu.tmpl @@ -0,0 +1,4286 @@ + + + + + + Linux GPU Driver Developer's Guide + + + + Jesse + Barnes + Initial version + + Intel Corporation +
+ jesse.barnes@intel.com +
+ + + + Laurent + Pinchart + Driver internals + + Ideas on board SPRL +
+ laurent.pinchart@ideasonboard.com +
+ + + + Daniel + Vetter + Contributions all over the place + + Intel Corporation +
+ daniel.vetter@ffwll.ch +
+ + + + Lukas + Wunner + vga_switcheroo documentation + +
+ lukas@wunner.de +
+ + + + + + 2008-2009 + 2013-2014 + Intel Corporation + + + 2012 + Laurent Pinchart + + + 2015 + Lukas Wunner + + + + + The contents of this file may be used under the terms of the GNU + General Public License version 2 (the "GPL") as distributed in + the kernel source COPYING file. + + + + + + + 1.0 + 2012-07-13 + LP + Added extensive documentation about driver internals. + + + + 1.1 + 2015-10-11 + LW + Added vga_switcheroo documentation. + + + + + + + + + DRM Core + + + This first part of the GPU Driver Developer's Guide documents core DRM + code, helper libraries for writing drivers and generic userspace + interfaces exposed by DRM drivers. + + + + + Introduction + + The Linux DRM layer contains code intended to support the needs + of complex graphics devices, usually containing programmable + pipelines well suited to 3D graphics acceleration. Graphics + drivers in the kernel may make use of DRM functions to make + tasks like memory management, interrupt handling and DMA easier, + and provide a uniform interface to applications. + + + A note on versions: this guide covers features found in the DRM + tree, including the TTM memory manager, output configuration and + mode setting, and the new vblank internals, in addition to all + the regular features found in current kernels. + + + [Insert diagram of typical DRM stack here] + + + + + + + DRM Internals + + This chapter documents DRM internals relevant to driver authors + and developers working to add support for the latest features to + existing drivers. + + + First, we go over some typical driver initialization + requirements, like setting up command buffers, creating an + initial output configuration, and initializing core services. + Subsequent sections cover core internals in more detail, + providing implementation notes and examples. + + + The DRM layer provides several services to graphics drivers, + many of them driven by the application interfaces it provides + through libdrm, the library that wraps most of the DRM ioctls. + These include vblank event handling, memory + management, output management, framebuffer management, command + submission & fencing, suspend/resume support, and DMA + services. + + + + + + Driver Initialization + + At the core of every DRM driver is a drm_driver + structure. Drivers typically statically initialize a drm_driver structure, + and then pass it to drm_dev_alloc() to allocate a + device instance. After the device instance is fully initialized it can be + registered (which makes it accessible from userspace) using + drm_dev_register(). + + + The drm_driver structure contains static + information that describes the driver and features it supports, and + pointers to methods that the DRM core will call to implement the DRM API. + We will first go through the drm_driver static + information fields, and will then describe individual operations in + details as they get used in later sections. + + + Driver Information + + Driver Features + + Drivers inform the DRM core about their requirements and supported + features by setting appropriate flags in the + driver_features field. Since those flags + influence the DRM core behaviour since registration time, most of them + must be set to registering the drm_driver + instance. + + u32 driver_features; + + Driver Feature Flags + + DRIVER_USE_AGP + + Driver uses AGP interface, the DRM core will manage AGP resources. + + + + DRIVER_REQUIRE_AGP + + Driver needs AGP interface to function. AGP initialization failure + will become a fatal error. + + + + DRIVER_PCI_DMA + + Driver is capable of PCI DMA, mapping of PCI DMA buffers to + userspace will be enabled. Deprecated. + + + + DRIVER_SG + + Driver can perform scatter/gather DMA, allocation and mapping of + scatter/gather buffers will be enabled. Deprecated. + + + + DRIVER_HAVE_DMA + + Driver supports DMA, the userspace DMA API will be supported. + Deprecated. + + + + DRIVER_HAVE_IRQDRIVER_IRQ_SHARED + + DRIVER_HAVE_IRQ indicates whether the driver has an IRQ handler + managed by the DRM Core. The core will support simple IRQ handler + installation when the flag is set. The installation process is + described in . + DRIVER_IRQ_SHARED indicates whether the device & handler + support shared IRQs (note that this is required of PCI drivers). + + + + DRIVER_GEM + + Driver use the GEM memory manager. + + + + DRIVER_MODESET + + Driver supports mode setting interfaces (KMS). + + + + DRIVER_PRIME + + Driver implements DRM PRIME buffer sharing. + + + + DRIVER_RENDER + + Driver supports dedicated render nodes. + + + + DRIVER_ATOMIC + + Driver supports atomic properties. In this case the driver + must implement appropriate obj->atomic_get_property() vfuncs + for any modeset objects with driver specific properties. + + + + + + Major, Minor and Patchlevel + int major; +int minor; +int patchlevel; + + The DRM core identifies driver versions by a major, minor and patch + level triplet. The information is printed to the kernel log at + initialization time and passed to userspace through the + DRM_IOCTL_VERSION ioctl. + + + The major and minor numbers are also used to verify the requested driver + API version passed to DRM_IOCTL_SET_VERSION. When the driver API changes + between minor versions, applications can call DRM_IOCTL_SET_VERSION to + select a specific version of the API. If the requested major isn't equal + to the driver major, or the requested minor is larger than the driver + minor, the DRM_IOCTL_SET_VERSION call will return an error. Otherwise + the driver's set_version() method will be called with the requested + version. + + + + Name, Description and Date + char *name; +char *desc; +char *date; + + The driver name is printed to the kernel log at initialization time, + used for IRQ registration and passed to userspace through + DRM_IOCTL_VERSION. + + + The driver description is a purely informative string passed to + userspace through the DRM_IOCTL_VERSION ioctl and otherwise unused by + the kernel. + + + The driver date, formatted as YYYYMMDD, is meant to identify the date of + the latest modification to the driver. However, as most drivers fail to + update it, its value is mostly useless. The DRM core prints it to the + kernel log at initialization time and passes it to userspace through the + DRM_IOCTL_VERSION ioctl. + + + + + Device Instance and Driver Handling +!Pdrivers/gpu/drm/drm_drv.c driver instance overview +!Edrivers/gpu/drm/drm_drv.c + + + Driver Load + + IRQ Registration + + The DRM core tries to facilitate IRQ handler registration and + unregistration by providing drm_irq_install and + drm_irq_uninstall functions. Those functions only + support a single interrupt per device, devices that use more than one + IRQs need to be handled manually. + + + Managed IRQ Registration + + drm_irq_install starts by calling the + irq_preinstall driver operation. The operation + is optional and must make sure that the interrupt will not get fired by + clearing all pending interrupt flags or disabling the interrupt. + + + The passed-in IRQ will then be requested by a call to + request_irq. If the DRIVER_IRQ_SHARED driver + feature flag is set, a shared (IRQF_SHARED) IRQ handler will be + requested. + + + The IRQ handler function must be provided as the mandatory irq_handler + driver operation. It will get passed directly to + request_irq and thus has the same prototype as all + IRQ handlers. It will get called with a pointer to the DRM device as the + second argument. + + + Finally the function calls the optional + irq_postinstall driver operation. The operation + usually enables interrupts (excluding the vblank interrupt, which is + enabled separately), but drivers may choose to enable/disable interrupts + at a different time. + + + drm_irq_uninstall is similarly used to uninstall an + IRQ handler. It starts by waking up all processes waiting on a vblank + interrupt to make sure they don't hang, and then calls the optional + irq_uninstall driver operation. The operation + must disable all hardware interrupts. Finally the function frees the IRQ + by calling free_irq. + + + + Manual IRQ Registration + + Drivers that require multiple interrupt handlers can't use the managed + IRQ registration functions. In that case IRQs must be registered and + unregistered manually (usually with the request_irq + and free_irq functions, or their devm_* equivalent). + + + When manually registering IRQs, drivers must not set the DRIVER_HAVE_IRQ + driver feature flag, and must not provide the + irq_handler driver operation. They must set the + drm_device irq_enabled + field to 1 upon registration of the IRQs, and clear it to 0 after + unregistering the IRQs. + + + + + Memory Manager Initialization + + Every DRM driver requires a memory manager which must be initialized at + load time. DRM currently contains two memory managers, the Translation + Table Manager (TTM) and the Graphics Execution Manager (GEM). + This document describes the use of the GEM memory manager only. See + for details. + + + + Miscellaneous Device Configuration + + Another task that may be necessary for PCI devices during configuration + is mapping the video BIOS. On many devices, the VBIOS describes device + configuration, LCD panel timings (if any), and contains flags indicating + device state. Mapping the BIOS can be done using the pci_map_rom() call, + a convenience function that takes care of mapping the actual ROM, + whether it has been shadowed into memory (typically at address 0xc0000) + or exists on the PCI device in the ROM BAR. Note that after the ROM has + been mapped and any necessary information has been extracted, it should + be unmapped; on many devices, the ROM address decoder is shared with + other BARs, so leaving it mapped could cause undesired behaviour like + hangs or memory corruption. + + + + + + Bus-specific Device Registration and PCI Support + + A number of functions are provided to help with device registration. + The functions deal with PCI and platform devices respectively and are + only provided for historical reasons. These are all deprecated and + shouldn't be used in new drivers. Besides that there's a few + helpers for pci drivers. + +!Edrivers/gpu/drm/drm_pci.c +!Edrivers/gpu/drm/drm_platform.c + + + + + + + Memory management + + Modern Linux systems require large amount of graphics memory to store + frame buffers, textures, vertices and other graphics-related data. Given + the very dynamic nature of many of that data, managing graphics memory + efficiently is thus crucial for the graphics stack and plays a central + role in the DRM infrastructure. + + + The DRM core includes two memory managers, namely Translation Table Maps + (TTM) and Graphics Execution Manager (GEM). TTM was the first DRM memory + manager to be developed and tried to be a one-size-fits-them all + solution. It provides a single userspace API to accommodate the need of + all hardware, supporting both Unified Memory Architecture (UMA) devices + and devices with dedicated video RAM (i.e. most discrete video cards). + This resulted in a large, complex piece of code that turned out to be + hard to use for driver development. + + + GEM started as an Intel-sponsored project in reaction to TTM's + complexity. Its design philosophy is completely different: instead of + providing a solution to every graphics memory-related problems, GEM + identified common code between drivers and created a support library to + share it. GEM has simpler initialization and execution requirements than + TTM, but has no video RAM management capabilities and is thus limited to + UMA devices. + + + The Translation Table Manager (TTM) + + TTM design background and information belongs here. + + + TTM initialization + 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. + + + The ttm_global_reference structure is made up of several fields: + + + struct ttm_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 *); + }; + + + There should be one global reference structure for your memory + manager as a whole, and there will be others for each object + created by the memory manager at runtime. Your global TTM should + have a type of TTM_GLOBAL_TTM_MEM. The size field for the global + object should be sizeof(struct ttm_mem_global), and the init and + release hooks should point at your driver-specific init and + release routines, which probably eventually call + ttm_mem_global_init and ttm_mem_global_release, respectively. + + + Once your global TTM accounting structure is set up and initialized + by calling ttm_global_item_ref() on it, + you need to create a buffer object TTM to + provide a pool for buffer object allocation by clients and the + kernel itself. The type of this object should be TTM_GLOBAL_TTM_BO, + and its size should be sizeof(struct ttm_bo_global). Again, + driver-specific init and release functions may be provided, + likely eventually calling ttm_bo_global_init() and + 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. + + + + + The Graphics Execution Manager (GEM) + + The GEM design approach has resulted in a memory manager that doesn't + provide full coverage of all (or even all common) use cases in its + userspace or kernel API. GEM exposes a set of standard memory-related + operations to userspace and a set of helper functions to drivers, and let + drivers implement hardware-specific operations with their own private API. + + + The GEM userspace API is described in the + GEM - the Graphics + Execution Manager article on LWN. While slightly + outdated, the document provides a good overview of the GEM API principles. + Buffer allocation and read and write operations, described as part of the + common GEM API, are currently implemented using driver-specific ioctls. + + + GEM is data-agnostic. It manages abstract buffer objects without knowing + what individual buffers contain. APIs that require knowledge of buffer + contents or purpose, such as buffer allocation or synchronization + primitives, are thus outside of the scope of GEM and must be implemented + using driver-specific ioctls. + + + On a fundamental level, GEM involves several operations: + + Memory allocation and freeing + Command execution + Aperture management at command execution time + + Buffer object allocation is relatively straightforward and largely + provided by Linux's shmem layer, which provides memory to back each + object. + + + Device-specific operations, such as command execution, pinning, buffer + read & write, mapping, and domain ownership transfers are left to + driver-specific ioctls. + + + GEM Initialization + + Drivers that use GEM must set the DRIVER_GEM bit in the struct + drm_driver + driver_features field. The DRM core will + then automatically initialize the GEM core before calling the + load operation. Behind the scene, this will + create a DRM Memory Manager object which provides an address space + pool for object allocation. + + + In a KMS configuration, drivers need to allocate and initialize a + command ring buffer following core GEM initialization if required by + the hardware. UMA devices usually have what is called a "stolen" + memory region, which provides space for the initial framebuffer and + large, contiguous memory regions required by the device. This space is + typically not managed by GEM, and must be initialized separately into + its own DRM MM object. + + + + GEM Objects Creation + + GEM splits creation of GEM objects and allocation of the memory that + backs them in two distinct operations. + + + GEM objects are represented by an instance of struct + drm_gem_object. Drivers usually need to extend + GEM objects with private information and thus create a driver-specific + GEM object structure type that embeds an instance of struct + drm_gem_object. + + + To create a GEM object, a driver allocates memory for an instance of its + specific GEM object type and initializes the embedded struct + drm_gem_object with a call to + drm_gem_object_init. The function takes a pointer to + the DRM device, a pointer to the GEM object and the buffer object size + in bytes. + + + GEM uses shmem to allocate anonymous pageable memory. + drm_gem_object_init will create an shmfs file of + the requested size and store it into the struct + drm_gem_object filp + field. The memory is used as either main storage for the object when the + graphics hardware uses system memory directly or as a backing store + otherwise. + + + Drivers are responsible for the actual physical pages allocation by + calling shmem_read_mapping_page_gfp for each page. + Note that they can decide to allocate pages when initializing the GEM + object, or to delay allocation until the memory is needed (for instance + when a page fault occurs as a result of a userspace memory access or + when the driver needs to start a DMA transfer involving the memory). + + + Anonymous pageable memory allocation is not always desired, for instance + when the hardware requires physically contiguous system memory as is + often the case in embedded devices. Drivers can create GEM objects with + no shmfs backing (called private GEM objects) by initializing them with + a call to drm_gem_private_object_init instead of + drm_gem_object_init. Storage for private GEM + objects must be managed by drivers. + + + Drivers that do not need to extend GEM objects with private information + can call the drm_gem_object_alloc function to + allocate and initialize a struct drm_gem_object + instance. The GEM core will call the optional driver + gem_init_object operation after initializing + the GEM object with drm_gem_object_init. + int (*gem_init_object) (struct drm_gem_object *obj); + + + No alloc-and-init function exists for private GEM objects. + + + + GEM Objects Lifetime + + All GEM objects are reference-counted by the GEM core. References can be + acquired and release by calling drm_gem_object_reference + and drm_gem_object_unreference respectively. The + caller must hold the drm_device + struct_mutex lock. As a convenience, GEM + provides the drm_gem_object_reference_unlocked and + drm_gem_object_unreference_unlocked functions that + can be called without holding the lock. + + + When the last reference to a GEM object is released the GEM core calls + the drm_driver + gem_free_object operation. That operation is + mandatory for GEM-enabled drivers and must free the GEM object and all + associated resources. + + + void (*gem_free_object) (struct drm_gem_object *obj); + Drivers are responsible for freeing all GEM object resources, including + the resources created by the GEM core. If an mmap offset has been + created for the object (in which case + drm_gem_object::map_list::map + is not NULL) it must be freed by a call to + drm_gem_free_mmap_offset. The shmfs backing store + must be released by calling drm_gem_object_release + (that function can safely be called if no shmfs backing store has been + created). + + + + GEM Objects Naming + + Communication between userspace and the kernel refers to GEM objects + using local handles, global names or, more recently, file descriptors. + All of those are 32-bit integer values; the usual Linux kernel limits + apply to the file descriptors. + + + GEM handles are local to a DRM file. Applications get a handle to a GEM + object through a driver-specific ioctl, and can use that handle to refer + to the GEM object in other standard or driver-specific ioctls. Closing a + DRM file handle frees all its GEM handles and dereferences the + associated GEM objects. + + + To create a handle for a GEM object drivers call + drm_gem_handle_create. The function takes a pointer + to the DRM file and the GEM object and returns a locally unique handle. + When the handle is no longer needed drivers delete it with a call to + drm_gem_handle_delete. Finally the GEM object + associated with a handle can be retrieved by a call to + drm_gem_object_lookup. + + + Handles don't take ownership of GEM objects, they only take a reference + to the object that will be dropped when the handle is destroyed. To + avoid leaking GEM objects, drivers must make sure they drop the + reference(s) they own (such as the initial reference taken at object + creation time) as appropriate, without any special consideration for the + handle. For example, in the particular case of combined GEM object and + handle creation in the implementation of the + dumb_create operation, drivers must drop the + initial reference to the GEM object before returning the handle. + + + GEM names are similar in purpose to handles but are not local to DRM + files. They can be passed between processes to reference a GEM object + globally. Names can't be used directly to refer to objects in the DRM + API, applications must convert handles to names and names to handles + using the DRM_IOCTL_GEM_FLINK and DRM_IOCTL_GEM_OPEN ioctls + respectively. The conversion is handled by the DRM core without any + driver-specific support. + + + GEM also supports buffer sharing with dma-buf file descriptors through + PRIME. GEM-based drivers must use the provided helpers functions to + implement the exporting and importing correctly. See . + Since sharing file descriptors is inherently more secure than the + easily guessable and global GEM names it is the preferred buffer + sharing mechanism. Sharing buffers through GEM names is only supported + for legacy userspace. Furthermore PRIME also allows cross-device + buffer sharing since it is based on dma-bufs. + + + + GEM Objects Mapping + + Because mapping operations are fairly heavyweight GEM favours + read/write-like access to buffers, implemented through driver-specific + ioctls, over mapping buffers to userspace. However, when random access + to the buffer is needed (to perform software rendering for instance), + direct access to the object can be more efficient. + + + The mmap system call can't be used directly to map GEM objects, as they + don't have their own file handle. Two alternative methods currently + co-exist to map GEM objects to userspace. The first method uses a + driver-specific ioctl to perform the mapping operation, calling + do_mmap under the hood. This is often considered + dubious, seems to be discouraged for new GEM-enabled drivers, and will + thus not be described here. + + + The second method uses the mmap system call on the DRM file handle. + void *mmap(void *addr, size_t length, int prot, int flags, int fd, + off_t offset); + DRM identifies the GEM object to be mapped by a fake offset passed + through the mmap offset argument. Prior to being mapped, a GEM object + must thus be associated with a fake offset. To do so, drivers must call + drm_gem_create_mmap_offset on the object. The + function allocates a fake offset range from a pool and stores the + offset divided by PAGE_SIZE in + obj->map_list.hash.key. Care must be taken not to + call drm_gem_create_mmap_offset if a fake offset + has already been allocated for the object. This can be tested by + obj->map_list.map being non-NULL. + + + Once allocated, the fake offset value + (obj->map_list.hash.key << PAGE_SHIFT) + must be passed to the application in a driver-specific way and can then + be used as the mmap offset argument. + + + The GEM core provides a helper method drm_gem_mmap + to handle object mapping. The method can be set directly as the mmap + file operation handler. It will look up the GEM object based on the + offset value and set the VMA operations to the + drm_driver gem_vm_ops + field. Note that drm_gem_mmap doesn't map memory to + userspace, but relies on the driver-provided fault handler to map pages + individually. + + + To use drm_gem_mmap, drivers must fill the struct + 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 open and close + operations must update the GEM object reference count. Drivers can use + the drm_gem_vm_open and + drm_gem_vm_close helper functions directly as open + and close handlers. + + + The fault operation handler is responsible for mapping individual pages + to userspace when a page fault occurs. Depending on the memory + allocation scheme, drivers can allocate pages at fault time, or can + decide to allocate memory for the GEM object at the time the object is + created. + + + Drivers that want to map the GEM object upfront instead of handling page + faults can implement their own mmap file operation handler. + + + + Memory Coherency + + When mapped to the device or used in a command buffer, backing pages + for an object are flushed to memory and marked write combined so as to + be coherent with the GPU. Likewise, if the CPU accesses an object + after the GPU has finished rendering to the object, then the object + must be made coherent with the CPU's view of memory, usually involving + GPU cache flushing of various kinds. This core CPU<->GPU + coherency management is provided by a device-specific ioctl, which + evaluates an object's current domain and performs any necessary + flushing or synchronization to put the object into the desired + coherency domain (note that the object may be busy, i.e. an active + render target; in that case, setting the domain blocks the client and + waits for rendering to complete before performing any necessary + flushing operations). + + + + Command Execution + + Perhaps the most important GEM function for GPU devices is providing a + command execution interface to clients. Client programs construct + command buffers containing references to previously allocated memory + objects, and then submit them to GEM. At that point, GEM takes care to + bind all the objects into the GTT, execute the buffer, and provide + necessary synchronization between clients accessing the same buffers. + This often involves evicting some objects from the GTT and re-binding + others (a fairly expensive operation), and providing relocation + support which hides fixed GTT offsets from clients. Clients must take + care not to submit command buffers that reference more objects than + can fit in the GTT; otherwise, GEM will reject them and no rendering + will occur. Similarly, if several objects in the buffer require fence + registers to be allocated for correct rendering (e.g. 2D blits on + pre-965 chips), care must be taken not to require more fence registers + than are available to the client. Such resource management should be + abstracted from the client in libdrm. + + + + GEM Function Reference +!Edrivers/gpu/drm/drm_gem.c + + + + VMA Offset Manager +!Pdrivers/gpu/drm/drm_vma_manager.c vma offset manager +!Edrivers/gpu/drm/drm_vma_manager.c +!Iinclude/drm/drm_vma_manager.h + + + PRIME Buffer Sharing + + PRIME is the cross device buffer sharing framework in drm, originally + created for the OPTIMUS range of multi-gpu platforms. To userspace + PRIME buffers are dma-buf based file descriptors. + + + Overview and Driver Interface + + Similar to GEM global names, PRIME file descriptors are + also used to share buffer objects across processes. They offer + additional security: as file descriptors must be explicitly sent over + UNIX domain sockets to be shared between applications, they can't be + guessed like the globally unique GEM names. + + + Drivers that support the PRIME + API must set the DRIVER_PRIME bit in the struct + drm_driver + driver_features field, and implement the + prime_handle_to_fd and + prime_fd_to_handle operations. + + + int (*prime_handle_to_fd)(struct drm_device *dev, + struct drm_file *file_priv, uint32_t handle, + uint32_t flags, int *prime_fd); +int (*prime_fd_to_handle)(struct drm_device *dev, + struct drm_file *file_priv, int prime_fd, + uint32_t *handle); + Those two operations convert a handle to a PRIME file descriptor and + vice versa. Drivers must use the kernel dma-buf buffer sharing framework + to manage the PRIME file descriptors. Similar to the mode setting + API PRIME is agnostic to the underlying buffer object manager, as + long as handles are 32bit unsigned integers. + + + While non-GEM drivers must implement the operations themselves, GEM + drivers must use the drm_gem_prime_handle_to_fd + and drm_gem_prime_fd_to_handle helper functions. + Those helpers rely on the driver + gem_prime_export and + gem_prime_import operations to create a dma-buf + instance from a GEM object (dma-buf exporter role) and to create a GEM + object from a dma-buf instance (dma-buf importer role). + + + struct dma_buf * (*gem_prime_export)(struct drm_device *dev, + struct drm_gem_object *obj, + int flags); +struct drm_gem_object * (*gem_prime_import)(struct drm_device *dev, + struct dma_buf *dma_buf); + These two operations are mandatory for GEM drivers that support + PRIME. + + + + PRIME Helper Functions +!Pdrivers/gpu/drm/drm_prime.c PRIME Helpers + + + + PRIME Function References +!Edrivers/gpu/drm/drm_prime.c + + + DRM MM Range Allocator + + Overview +!Pdrivers/gpu/drm/drm_mm.c Overview + + + LRU Scan/Eviction Support +!Pdrivers/gpu/drm/drm_mm.c lru scan roaster + + + + DRM MM Range Allocator Function References +!Edrivers/gpu/drm/drm_mm.c +!Iinclude/drm/drm_mm.h + + + CMA Helper Functions Reference +!Pdrivers/gpu/drm/drm_gem_cma_helper.c cma helpers +!Edrivers/gpu/drm/drm_gem_cma_helper.c +!Iinclude/drm/drm_gem_cma_helper.h + + + + + + + Mode Setting + + Drivers must initialize the mode setting core by calling + drm_mode_config_init on the DRM device. The function + initializes the drm_device + mode_config field and never fails. Once done, + mode configuration must be setup by initializing the following fields. + + + + int min_width, min_height; +int max_width, max_height; + + Minimum and maximum width and height of the frame buffers in pixel + units. + + + + struct drm_mode_config_funcs *funcs; + Mode setting functions. + + + + Display Modes Function Reference +!Iinclude/drm/drm_modes.h +!Edrivers/gpu/drm/drm_modes.c + + + Atomic Mode Setting Function Reference +!Edrivers/gpu/drm/drm_atomic.c + + + Frame Buffer Creation + struct drm_framebuffer *(*fb_create)(struct drm_device *dev, + struct drm_file *file_priv, + struct drm_mode_fb_cmd2 *mode_cmd); + + Frame buffers are abstract memory objects that provide a source of + pixels to scanout to a CRTC. Applications explicitly request the + creation of frame buffers through the DRM_IOCTL_MODE_ADDFB(2) ioctls and + receive an opaque handle that can be passed to the KMS CRTC control, + plane configuration and page flip functions. + + + Frame buffers rely on the underneath memory manager for low-level memory + operations. When creating a frame buffer applications pass a memory + handle (or a list of memory handles for multi-planar formats) through + the drm_mode_fb_cmd2 argument. For drivers using + GEM as their userspace buffer management interface this would be a GEM + handle. Drivers are however free to use their own backing storage object + handles, e.g. vmwgfx directly exposes special TTM handles to userspace + and so expects TTM handles in the create ioctl and not GEM handles. + + + Drivers must first validate the requested frame buffer parameters passed + through the mode_cmd argument. In particular this is where invalid + sizes, pixel formats or pitches can be caught. + + + If the parameters are deemed valid, drivers then create, initialize and + return an instance of struct drm_framebuffer. + If desired the instance can be embedded in a larger driver-specific + structure. Drivers must fill its width, + height, pitches, + offsets, depth, + bits_per_pixel and + pixel_format fields from the values passed + through the drm_mode_fb_cmd2 argument. They + should call the drm_helper_mode_fill_fb_struct + helper function to do so. + + + + The initialization of the new framebuffer instance is finalized with a + call to drm_framebuffer_init which takes a pointer + to DRM frame buffer operations (struct + drm_framebuffer_funcs). Note that this function + publishes the framebuffer and so from this point on it can be accessed + concurrently from other threads. Hence it must be the last step in the + driver's framebuffer initialization sequence. Frame buffer operations + are + + + int (*create_handle)(struct drm_framebuffer *fb, + struct drm_file *file_priv, unsigned int *handle); + + Create a handle to the frame buffer underlying memory object. If + the frame buffer uses a multi-plane format, the handle will + reference the memory object associated with the first plane. + + + Drivers call drm_gem_handle_create to create + the handle. + + + + void (*destroy)(struct drm_framebuffer *framebuffer); + + Destroy the frame buffer object and frees all associated + resources. Drivers must call + drm_framebuffer_cleanup to free resources + allocated by the DRM core for the frame buffer object, and must + make sure to unreference all memory objects associated with the + frame buffer. Handles created by the + create_handle operation are released by + the DRM core. + + + + int (*dirty)(struct drm_framebuffer *framebuffer, + struct drm_file *file_priv, unsigned flags, unsigned color, + struct drm_clip_rect *clips, unsigned num_clips); + + This optional operation notifies the driver that a region of the + frame buffer has changed in response to a DRM_IOCTL_MODE_DIRTYFB + ioctl call. + + + + + + The lifetime of a drm framebuffer is controlled with a reference count, + drivers can grab additional references with + drm_framebuffer_referenceand drop them + again with drm_framebuffer_unreference. For + driver-private framebuffers for which the last reference is never + dropped (e.g. for the fbdev framebuffer when the struct + drm_framebuffer is embedded into the fbdev + helper struct) drivers can manually clean up a framebuffer at module + unload time with + drm_framebuffer_unregister_private. + + + + Dumb Buffer Objects + + The KMS API doesn't standardize backing storage object creation and + leaves it to driver-specific ioctls. Furthermore actually creating a + buffer object even for GEM-based drivers is done through a + driver-specific ioctl - GEM only has a common userspace interface for + sharing and destroying objects. While not an issue for full-fledged + graphics stacks that include device-specific userspace components (in + libdrm for instance), this limit makes DRM-based early boot graphics + unnecessarily complex. + + + Dumb objects partly alleviate the problem by providing a standard + API to create dumb buffers suitable for scanout, which can then be used + to create KMS frame buffers. + + + To support dumb objects drivers must implement the + dumb_create, + dumb_destroy and + dumb_map_offset operations. + + + + int (*dumb_create)(struct drm_file *file_priv, struct drm_device *dev, + struct drm_mode_create_dumb *args); + + The dumb_create operation creates a driver + object (GEM or TTM handle) suitable for scanout based on the + width, height and depth from the struct + drm_mode_create_dumb argument. It fills the + argument's handle, + pitch and size + fields with a handle for the newly created object and its line + pitch and size in bytes. + + + + int (*dumb_destroy)(struct drm_file *file_priv, struct drm_device *dev, + uint32_t handle); + + The dumb_destroy operation destroys a dumb + object created by dumb_create. + + + + int (*dumb_map_offset)(struct drm_file *file_priv, struct drm_device *dev, + uint32_t handle, uint64_t *offset); + + The dumb_map_offset operation associates an + mmap fake offset with the object given by the handle and returns + it. Drivers must use the + drm_gem_create_mmap_offset function to + associate the fake offset as described in + . + + + + + Note that dumb objects may not be used for gpu acceleration, as has been + attempted on some ARM embedded platforms. Such drivers really must have + a hardware-specific ioctl to allocate suitable buffer objects. + + + + Output Polling + void (*output_poll_changed)(struct drm_device *dev); + + This operation notifies the driver that the status of one or more + connectors has changed. Drivers that use the fb helper can just call the + drm_fb_helper_hotplug_event function to handle this + operation. + + + + Locking + + Beside some lookup structures with their own locking (which is hidden + behind the interface functions) most of the modeset state is protected + by the dev-<mode_config.lock mutex and additionally + per-crtc locks to allow cursor updates, pageflips and similar operations + to occur concurrently with background tasks like output detection. + Operations which cross domains like a full modeset always grab all + locks. Drivers there need to protect resources shared between crtcs with + additional locking. They also need to be careful to always grab the + relevant crtc locks if a modset functions touches crtc state, e.g. for + load detection (which does only grab the mode_config.lock + to allow concurrent screen updates on live crtcs). + + + + + + + + KMS Initialization and Cleanup + + A KMS device is abstracted and exposed as a set of planes, CRTCs, encoders + and connectors. KMS drivers must thus create and initialize all those + objects at load time after initializing mode setting. + + + CRTCs (struct <structname>drm_crtc</structname>) + + A CRTC is an abstraction representing a part of the chip that contains a + pointer to a scanout buffer. Therefore, the number of CRTCs available + determines how many independent scanout buffers can be active at any + given time. The CRTC structure contains several fields to support this: + a pointer to some video memory (abstracted as a frame buffer object), a + display mode, and an (x, y) offset into the video memory to support + panning or configurations where one piece of video memory spans multiple + CRTCs. + + + CRTC Initialization + + A KMS device must create and register at least one struct + drm_crtc instance. The instance is allocated + and zeroed by the driver, possibly as part of a larger structure, and + registered with a call to drm_crtc_init with a + pointer to CRTC functions. + + + + CRTC Operations + + Set Configuration + int (*set_config)(struct drm_mode_set *set); + + Apply a new CRTC configuration to the device. The configuration + specifies a CRTC, a frame buffer to scan out from, a (x,y) position in + the frame buffer, a display mode and an array of connectors to drive + with the CRTC if possible. + + + If the frame buffer specified in the configuration is NULL, the driver + must detach all encoders connected to the CRTC and all connectors + attached to those encoders and disable them. + + + This operation is called with the mode config lock held. + + + Note that the drm core has no notion of restoring the mode setting + state after resume, since all resume handling is in the full + responsibility of the driver. The common mode setting helper library + though provides a helper which can be used for this: + drm_helper_resume_force_mode. + + + + Page Flipping + int (*page_flip)(struct drm_crtc *crtc, struct drm_framebuffer *fb, + struct drm_pending_vblank_event *event); + + Schedule a page flip to the given frame buffer for the CRTC. This + operation is called with the mode config mutex held. + + + Page flipping is a synchronization mechanism that replaces the frame + buffer being scanned out by the CRTC with a new frame buffer during + vertical blanking, avoiding tearing. When an application requests a page + flip the DRM core verifies that the new frame buffer is large enough to + be scanned out by the CRTC in the currently configured mode and then + calls the CRTC page_flip operation with a + pointer to the new frame buffer. + + + The page_flip operation schedules a page flip. + Once any pending rendering targeting the new frame buffer has + completed, the CRTC will be reprogrammed to display that frame buffer + after the next vertical refresh. The operation must return immediately + without waiting for rendering or page flip to complete and must block + any new rendering to the frame buffer until the page flip completes. + + + If a page flip can be successfully scheduled the driver must set the + drm_crtc->fb field to the new framebuffer pointed to + by fb. This is important so that the reference counting + on framebuffers stays balanced. + + + If a page flip is already pending, the + page_flip operation must return + -EBUSY. + + + To synchronize page flip to vertical blanking the driver will likely + need to enable vertical blanking interrupts. It should call + drm_vblank_get for that purpose, and call + drm_vblank_put after the page flip completes. + + + If the application has requested to be notified when page flip completes + the page_flip operation will be called with a + non-NULL event argument pointing to a + drm_pending_vblank_event instance. Upon page + flip completion the driver must call drm_send_vblank_event + to fill in the event and send to wake up any waiting processes. + This can be performed with + event_lock, flags); + ... + drm_send_vblank_event(dev, pipe, event); + spin_unlock_irqrestore(&dev->event_lock, flags); + ]]> + + + FIXME: Could drivers that don't need to wait for rendering to complete + just add the event to dev->vblank_event_list and + let the DRM core handle everything, as for "normal" vertical blanking + events? + + + While waiting for the page flip to complete, the + event->base.link list head can be used freely by + the driver to store the pending event in a driver-specific list. + + + If the file handle is closed before the event is signaled, drivers must + take care to destroy the event in their + preclose operation (and, if needed, call + drm_vblank_put). + + + + Miscellaneous + + + void (*set_property)(struct drm_crtc *crtc, + struct drm_property *property, uint64_t value); + + Set the value of the given CRTC property to + value. See + for more information about properties. + + + + void (*gamma_set)(struct drm_crtc *crtc, u16 *r, u16 *g, u16 *b, + uint32_t start, uint32_t size); + + Apply a gamma table to the device. The operation is optional. + + + + void (*destroy)(struct drm_crtc *crtc); + + Destroy the CRTC when not needed anymore. See + . + + + + + + + + Planes (struct <structname>drm_plane</structname>) + + A plane represents an image source that can be blended with or overlayed + on top of a CRTC during the scanout process. Planes are associated with + a frame buffer to crop a portion of the image memory (source) and + optionally scale it to a destination size. The result is then blended + with or overlayed on top of a CRTC. + + + The DRM core recognizes three types of planes: + + + DRM_PLANE_TYPE_PRIMARY represents a "main" plane for a CRTC. Primary + planes are the planes operated upon by CRTC modesetting and flipping + operations described in . + + + DRM_PLANE_TYPE_CURSOR represents a "cursor" plane for a CRTC. Cursor + planes are the planes operated upon by the DRM_IOCTL_MODE_CURSOR and + DRM_IOCTL_MODE_CURSOR2 ioctls. + + + DRM_PLANE_TYPE_OVERLAY represents all non-primary, non-cursor planes. + Some drivers refer to these types of planes as "sprites" internally. + + + For compatibility with legacy userspace, only overlay planes are made + available to userspace by default. Userspace clients may set the + DRM_CLIENT_CAP_UNIVERSAL_PLANES client capability bit to indicate that + they wish to receive a universal plane list containing all plane types. + + + Plane Initialization + + To create a plane, a KMS drivers allocates and + zeroes an instances of struct drm_plane + (possibly as part of a larger structure) and registers it with a call + to drm_universal_plane_init. The function takes a bitmask + of the CRTCs that can be associated with the plane, a pointer to the + plane functions, a list of format supported formats, and the type of + plane (primary, cursor, or overlay) being initialized. + + + Cursor and overlay planes are optional. All drivers should provide + one primary plane per CRTC (although this requirement may change in + the future); drivers that do not wish to provide special handling for + primary planes may make use of the helper functions described in + to create and register a + primary plane with standard capabilities. + + + + Plane Operations + + + int (*update_plane)(struct drm_plane *plane, struct drm_crtc *crtc, + struct drm_framebuffer *fb, int crtc_x, int crtc_y, + unsigned int crtc_w, unsigned int crtc_h, + uint32_t src_x, uint32_t src_y, + uint32_t src_w, uint32_t src_h); + + Enable and configure the plane to use the given CRTC and frame buffer. + + + The source rectangle in frame buffer memory coordinates is given by + the src_x, src_y, + src_w and src_h + parameters (as 16.16 fixed point values). Devices that don't support + subpixel plane coordinates can ignore the fractional part. + + + The destination rectangle in CRTC coordinates is given by the + crtc_x, crtc_y, + crtc_w and crtc_h + parameters (as integer values). Devices scale the source rectangle to + the destination rectangle. If scaling is not supported, and the source + rectangle size doesn't match the destination rectangle size, the + driver must return a -EINVAL error. + + + + int (*disable_plane)(struct drm_plane *plane); + + Disable the plane. The DRM core calls this method in response to a + DRM_IOCTL_MODE_SETPLANE ioctl call with the frame buffer ID set to 0. + Disabled planes must not be processed by the CRTC. + + + + void (*destroy)(struct drm_plane *plane); + + Destroy the plane when not needed anymore. See + . + + + + + + + Encoders (struct <structname>drm_encoder</structname>) + + An encoder takes pixel data from a CRTC and converts it to a format + suitable for any attached connectors. On some devices, it may be + possible to have a CRTC send data to more than one encoder. In that + case, both encoders would receive data from the same scanout buffer, + resulting in a "cloned" display configuration across the connectors + attached to each encoder. + + + Encoder Initialization + + As for CRTCs, a KMS driver must create, initialize and register at + least one struct drm_encoder instance. The + instance is allocated and zeroed by the driver, possibly as part of a + larger structure. + + + Drivers must initialize the struct drm_encoder + possible_crtcs and + possible_clones fields before registering the + encoder. Both fields are bitmasks of respectively the CRTCs that the + encoder can be connected to, and sibling encoders candidate for cloning. + + + After being initialized, the encoder must be registered with a call to + drm_encoder_init. The function takes a pointer to + the encoder functions and an encoder type. Supported types are + + + DRM_MODE_ENCODER_DAC for VGA and analog on DVI-I/DVI-A + + + DRM_MODE_ENCODER_TMDS for DVI, HDMI and (embedded) DisplayPort + + + DRM_MODE_ENCODER_LVDS for display panels + + + DRM_MODE_ENCODER_TVDAC for TV output (Composite, S-Video, Component, + SCART) + + + DRM_MODE_ENCODER_VIRTUAL for virtual machine displays + + + + + Encoders must be attached to a CRTC to be used. DRM drivers leave + encoders unattached at initialization time. Applications (or the fbdev + compatibility layer when implemented) are responsible for attaching the + encoders they want to use to a CRTC. + + + + Encoder Operations + + + void (*destroy)(struct drm_encoder *encoder); + + Called to destroy the encoder when not needed anymore. See + . + + + + void (*set_property)(struct drm_plane *plane, + struct drm_property *property, uint64_t value); + + Set the value of the given plane property to + value. See + for more information about properties. + + + + + + + Connectors (struct <structname>drm_connector</structname>) + + A connector is the final destination for pixel data on a device, and + usually connects directly to an external display device like a monitor + or laptop panel. A connector can only be attached to one encoder at a + time. The connector is also the structure where information about the + attached display is kept, so it contains fields for display data, EDID + data, DPMS & connection status, and information about modes + supported on the attached displays. + + + Connector Initialization + + Finally a KMS driver must create, initialize, register and attach at + least one struct drm_connector instance. The + instance is created as other KMS objects and initialized by setting the + following fields. + + + + interlace_allowed + + Whether the connector can handle interlaced modes. + + + + doublescan_allowed + + Whether the connector can handle doublescan. + + + + display_info + + + Display information is filled from EDID information when a display + is detected. For non hot-pluggable displays such as flat panels in + embedded systems, the driver should initialize the + display_info.width_mm + and + display_info.height_mm + fields with the physical size of the display. + + + + polled + + Connector polling mode, a combination of + + + DRM_CONNECTOR_POLL_HPD + + The connector generates hotplug events and doesn't need to be + periodically polled. The CONNECT and DISCONNECT flags must not + be set together with the HPD flag. + + + + DRM_CONNECTOR_POLL_CONNECT + + Periodically poll the connector for connection. + + + + DRM_CONNECTOR_POLL_DISCONNECT + + Periodically poll the connector for disconnection. + + + + Set to 0 for connectors that don't support connection status + discovery. + + + + + The connector is then registered with a call to + drm_connector_init with a pointer to the connector + functions and a connector type, and exposed through sysfs with a call to + drm_connector_register. + + + Supported connector types are + + DRM_MODE_CONNECTOR_VGA + DRM_MODE_CONNECTOR_DVII + DRM_MODE_CONNECTOR_DVID + DRM_MODE_CONNECTOR_DVIA + DRM_MODE_CONNECTOR_Composite + DRM_MODE_CONNECTOR_SVIDEO + DRM_MODE_CONNECTOR_LVDS + DRM_MODE_CONNECTOR_Component + DRM_MODE_CONNECTOR_9PinDIN + DRM_MODE_CONNECTOR_DisplayPort + DRM_MODE_CONNECTOR_HDMIA + DRM_MODE_CONNECTOR_HDMIB + DRM_MODE_CONNECTOR_TV + DRM_MODE_CONNECTOR_eDP + DRM_MODE_CONNECTOR_VIRTUAL + + + + Connectors must be attached to an encoder to be used. For devices that + map connectors to encoders 1:1, the connector should be attached at + initialization time with a call to + drm_mode_connector_attach_encoder. The driver must + also set the drm_connector + encoder field to point to the attached + encoder. + + + Finally, drivers must initialize the connectors state change detection + with a call to drm_kms_helper_poll_init. If at + least one connector is pollable but can't generate hotplug interrupts + (indicated by the DRM_CONNECTOR_POLL_CONNECT and + DRM_CONNECTOR_POLL_DISCONNECT connector flags), a delayed work will + automatically be queued to periodically poll for changes. Connectors + that can generate hotplug interrupts must be marked with the + DRM_CONNECTOR_POLL_HPD flag instead, and their interrupt handler must + call drm_helper_hpd_irq_event. The function will + queue a delayed work to check the state of all connectors, but no + periodic polling will be done. + + + + Connector Operations + + Unless otherwise state, all operations are mandatory. + + + DPMS + void (*dpms)(struct drm_connector *connector, int mode); + + The DPMS operation sets the power state of a connector. The mode + argument is one of + + DRM_MODE_DPMS_ON + DRM_MODE_DPMS_STANDBY + DRM_MODE_DPMS_SUSPEND + DRM_MODE_DPMS_OFF + + + + In all but DPMS_ON mode the encoder to which the connector is attached + should put the display in low-power mode by driving its signals + appropriately. If more than one connector is attached to the encoder + care should be taken not to change the power state of other displays as + a side effect. Low-power mode should be propagated to the encoders and + CRTCs when all related connectors are put in low-power mode. + + + + Modes + int (*fill_modes)(struct drm_connector *connector, uint32_t max_width, + uint32_t max_height); + + Fill the mode list with all supported modes for the connector. If the + max_width and max_height + arguments are non-zero, the implementation must ignore all modes wider + than max_width or higher than + max_height. + + + The connector must also fill in this operation its + display_info + width_mm and + height_mm fields with the connected display + physical size in millimeters. The fields should be set to 0 if the value + isn't known or is not applicable (for instance for projector devices). + + + + Connection Status + + The connection status is updated through polling or hotplug events when + supported (see ). The status + value is reported to userspace through ioctls and must not be used + inside the driver, as it only gets initialized by a call to + drm_mode_getconnector from userspace. + + enum drm_connector_status (*detect)(struct drm_connector *connector, + bool force); + + Check to see if anything is attached to the connector. The + force parameter is set to false whilst polling or + to true when checking the connector due to user request. + force can be used by the driver to avoid + expensive, destructive operations during automated probing. + + + Return connector_status_connected if something is connected to the + connector, connector_status_disconnected if nothing is connected and + connector_status_unknown if the connection state isn't known. + + + Drivers should only return connector_status_connected if the connection + status has really been probed as connected. Connectors that can't detect + the connection status, or failed connection status probes, should return + connector_status_unknown. + + + + Miscellaneous + + + void (*set_property)(struct drm_connector *connector, + struct drm_property *property, uint64_t value); + + Set the value of the given connector property to + value. See + for more information about properties. + + + + void (*destroy)(struct drm_connector *connector); + + Destroy the connector when not needed anymore. See + . + + + + + + + + Cleanup + + The DRM core manages its objects' lifetime. When an object is not needed + anymore the core calls its destroy function, which must clean up and + free every resource allocated for the object. Every + drm_*_init call must be matched with a + corresponding drm_*_cleanup call to cleanup CRTCs + (drm_crtc_cleanup), planes + (drm_plane_cleanup), encoders + (drm_encoder_cleanup) and connectors + (drm_connector_cleanup). Furthermore, connectors + that have been added to sysfs must be removed by a call to + drm_connector_unregister before calling + drm_connector_cleanup. + + + Connectors state change detection must be cleanup up with a call to + drm_kms_helper_poll_fini. + + + + Output discovery and initialization example + base; + drm_connector_init(dev, &intel_output->base, + &intel_crt_connector_funcs, DRM_MODE_CONNECTOR_VGA); + + drm_encoder_init(dev, &intel_output->enc, &intel_crt_enc_funcs, + DRM_MODE_ENCODER_DAC); + + drm_mode_connector_attach_encoder(&intel_output->base, + &intel_output->enc); + + /* Set up the DDC bus. */ + intel_output->ddc_bus = intel_i2c_create(dev, GPIOA, "CRTDDC_A"); + if (!intel_output->ddc_bus) { + dev_printk(KERN_ERR, &dev->pdev->dev, "DDC bus registration " + "failed.\n"); + return; + } + + intel_output->type = INTEL_OUTPUT_ANALOG; + connector->interlace_allowed = 0; + connector->doublescan_allowed = 0; + + drm_encoder_helper_add(&intel_output->enc, &intel_crt_helper_funcs); + drm_connector_helper_add(connector, &intel_crt_connector_helper_funcs); + + drm_connector_register(connector); +}]]> + + In the example above (taken from the i915 driver), a CRTC, connector and + encoder combination is created. A device-specific i2c bus is also + created for fetching EDID data and performing monitor detection. Once + the process is complete, the new connector is registered with sysfs to + make its properties available to applications. + + + + KMS API Functions +!Edrivers/gpu/drm/drm_crtc.c + + + KMS Data Structures +!Iinclude/drm/drm_crtc.h + + + KMS Locking +!Pdrivers/gpu/drm/drm_modeset_lock.c kms locking +!Iinclude/drm/drm_modeset_lock.h +!Edrivers/gpu/drm/drm_modeset_lock.c + + + + + + + Mode Setting Helper Functions + + The plane, CRTC, encoder and connector functions provided by the drivers + implement the DRM API. They're called by the DRM core and ioctl handlers + to handle device state changes and configuration request. As implementing + those functions often requires logic not specific to drivers, mid-layer + helper functions are available to avoid duplicating boilerplate code. + + + The DRM core contains one mid-layer implementation. The mid-layer provides + implementations of several plane, CRTC, encoder and connector functions + (called from the top of the mid-layer) that pre-process requests and call + lower-level functions provided by the driver (at the bottom of the + mid-layer). For instance, the + drm_crtc_helper_set_config function can be used to + fill the struct drm_crtc_funcs + set_config field. When called, it will split + the set_config operation in smaller, simpler + operations and call the driver to handle them. + + + To use the mid-layer, drivers call drm_crtc_helper_add, + drm_encoder_helper_add and + drm_connector_helper_add functions to install their + mid-layer bottom operations handlers, and fill the + drm_crtc_funcs, + drm_encoder_funcs and + drm_connector_funcs structures with pointers to + the mid-layer top API functions. Installing the mid-layer bottom operation + handlers is best done right after registering the corresponding KMS object. + + + The mid-layer is not split between CRTC, encoder and connector operations. + To use it, a driver must provide bottom functions for all of the three KMS + entities. + + + Helper Functions + + + int drm_crtc_helper_set_config(struct drm_mode_set *set); + + The drm_crtc_helper_set_config helper function + is a CRTC set_config implementation. It + first tries to locate the best encoder for each connector by calling + the connector best_encoder helper + operation. + + + After locating the appropriate encoders, the helper function will + call the mode_fixup encoder and CRTC helper + operations to adjust the requested mode, or reject it completely in + which case an error will be returned to the application. If the new + configuration after mode adjustment is identical to the current + configuration the helper function will return without performing any + other operation. + + + If the adjusted mode is identical to the current mode but changes to + the frame buffer need to be applied, the + drm_crtc_helper_set_config function will call + the CRTC mode_set_base helper operation. If + the adjusted mode differs from the current mode, or if the + mode_set_base helper operation is not + provided, the helper function performs a full mode set sequence by + calling the prepare, + mode_set and + commit CRTC and encoder helper operations, + in that order. + + + + void drm_helper_connector_dpms(struct drm_connector *connector, int mode); + + The drm_helper_connector_dpms helper function + is a connector dpms implementation that + tracks power state of connectors. To use the function, drivers must + provide dpms helper operations for CRTCs + and encoders to apply the DPMS state to the device. + + + The mid-layer doesn't track the power state of CRTCs and encoders. + The dpms helper operations can thus be + called with a mode identical to the currently active mode. + + + + int drm_helper_probe_single_connector_modes(struct drm_connector *connector, + uint32_t maxX, uint32_t maxY); + + The drm_helper_probe_single_connector_modes helper + function is a connector fill_modes + implementation that updates the connection status for the connector + and then retrieves a list of modes by calling the connector + get_modes helper operation. + + + If the helper operation returns no mode, and if the connector status + is connector_status_connected, standard VESA DMT modes up to + 1024x768 are automatically added to the modes list by a call to + drm_add_modes_noedid. + + + The function then filters out modes larger than + max_width and max_height + if specified. It finally calls the optional connector + mode_valid helper operation for each mode in + the probed list to check whether the mode is valid for the connector. + + + + + + CRTC Helper Operations + + + bool (*mode_fixup)(struct drm_crtc *crtc, + const struct drm_display_mode *mode, + struct drm_display_mode *adjusted_mode); + + Let CRTCs adjust the requested mode or reject it completely. This + operation returns true if the mode is accepted (possibly after being + adjusted) or false if it is rejected. + + + The mode_fixup operation should reject the + mode if it can't reasonably use it. The definition of "reasonable" + is currently fuzzy in this context. One possible behaviour would be + to set the adjusted mode to the panel timings when a fixed-mode + panel is used with hardware capable of scaling. Another behaviour + would be to accept any input mode and adjust it to the closest mode + supported by the hardware (FIXME: This needs to be clarified). + + + + int (*mode_set_base)(struct drm_crtc *crtc, int x, int y, + struct drm_framebuffer *old_fb) + + Move the CRTC on the current frame buffer (stored in + crtc->fb) to position (x,y). Any of the frame + buffer, x position or y position may have been modified. + + + This helper operation is optional. If not provided, the + drm_crtc_helper_set_config function will fall + back to the mode_set helper operation. + + + FIXME: Why are x and y passed as arguments, as they can be accessed + through crtc->x and + crtc->y? + + + + void (*prepare)(struct drm_crtc *crtc); + + Prepare the CRTC for mode setting. This operation is called after + validating the requested mode. Drivers use it to perform + device-specific operations required before setting the new mode. + + + + int (*mode_set)(struct drm_crtc *crtc, struct drm_display_mode *mode, + struct drm_display_mode *adjusted_mode, int x, int y, + struct drm_framebuffer *old_fb); + + Set a new mode, position and frame buffer. Depending on the device + requirements, the mode can be stored internally by the driver and + applied in the commit operation, or + programmed to the hardware immediately. + + + The mode_set operation returns 0 on success + or a negative error code if an error occurs. + + + + void (*commit)(struct drm_crtc *crtc); + + Commit a mode. This operation is called after setting the new mode. + Upon return the device must use the new mode and be fully + operational. + + + + + + Encoder Helper Operations + + + bool (*mode_fixup)(struct drm_encoder *encoder, + const struct drm_display_mode *mode, + struct drm_display_mode *adjusted_mode); + + Let encoders adjust the requested mode or reject it completely. This + operation returns true if the mode is accepted (possibly after being + adjusted) or false if it is rejected. See the + mode_fixup CRTC helper + operation for an explanation of the allowed adjustments. + + + + void (*prepare)(struct drm_encoder *encoder); + + Prepare the encoder for mode setting. This operation is called after + validating the requested mode. Drivers use it to perform + device-specific operations required before setting the new mode. + + + + void (*mode_set)(struct drm_encoder *encoder, + struct drm_display_mode *mode, + struct drm_display_mode *adjusted_mode); + + Set a new mode. Depending on the device requirements, the mode can + be stored internally by the driver and applied in the + commit operation, or programmed to the + hardware immediately. + + + + void (*commit)(struct drm_encoder *encoder); + + Commit a mode. This operation is called after setting the new mode. + Upon return the device must use the new mode and be fully + operational. + + + + + + Connector Helper Operations + + + struct drm_encoder *(*best_encoder)(struct drm_connector *connector); + + Return a pointer to the best encoder for the connecter. Device that + map connectors to encoders 1:1 simply return the pointer to the + associated encoder. This operation is mandatory. + + + + int (*get_modes)(struct drm_connector *connector); + + Fill the connector's probed_modes list + by parsing EDID data with drm_add_edid_modes, + adding standard VESA DMT modes with drm_add_modes_noedid, + or calling drm_mode_probed_add directly for every + supported mode and return the number of modes it has detected. This + operation is mandatory. + + + Note that the caller function will automatically add standard VESA + DMT modes up to 1024x768 if the get_modes + helper operation returns no mode and if the connector status is + connector_status_connected. There is no need to call + drm_add_edid_modes manually in that case. + + + When adding modes manually the driver creates each mode with a call to + drm_mode_create and must fill the following fields. + + + __u32 type; + + Mode type bitmask, a combination of + + + DRM_MODE_TYPE_BUILTIN + not used? + + + DRM_MODE_TYPE_CLOCK_C + not used? + + + DRM_MODE_TYPE_CRTC_C + not used? + + + + DRM_MODE_TYPE_PREFERRED - The preferred mode for the connector + + + not used? + + + + DRM_MODE_TYPE_DEFAULT + not used? + + + DRM_MODE_TYPE_USERDEF + not used? + + + DRM_MODE_TYPE_DRIVER + + + The mode has been created by the driver (as opposed to + to user-created modes). + + + + + Drivers must set the DRM_MODE_TYPE_DRIVER bit for all modes they + create, and set the DRM_MODE_TYPE_PREFERRED bit for the preferred + mode. + + + + __u32 clock; + Pixel clock frequency in kHz unit + + + __u16 hdisplay, hsync_start, hsync_end, htotal; + __u16 vdisplay, vsync_start, vsync_end, vtotal; + Horizontal and vertical timing information + <----------------><-------------><--------------> + + //////////////////////| + ////////////////////// | + ////////////////////// |.................. ................ + _______________ + + <----- [hv]display -----> + <------------- [hv]sync_start ------------> + <--------------------- [hv]sync_end ---------------------> + <-------------------------------- [hv]total -----------------------------> +]]> + + + __u16 hskew; + __u16 vscan; + Unknown + + + __u32 flags; + + Mode flags, a combination of + + + DRM_MODE_FLAG_PHSYNC + + Horizontal sync is active high + + + + DRM_MODE_FLAG_NHSYNC + + Horizontal sync is active low + + + + DRM_MODE_FLAG_PVSYNC + + Vertical sync is active high + + + + DRM_MODE_FLAG_NVSYNC + + Vertical sync is active low + + + + DRM_MODE_FLAG_INTERLACE + + Mode is interlaced + + + + DRM_MODE_FLAG_DBLSCAN + + Mode uses doublescan + + + + DRM_MODE_FLAG_CSYNC + + Mode uses composite sync + + + + DRM_MODE_FLAG_PCSYNC + + Composite sync is active high + + + + DRM_MODE_FLAG_NCSYNC + + Composite sync is active low + + + + DRM_MODE_FLAG_HSKEW + + hskew provided (not used?) + + + + DRM_MODE_FLAG_BCAST + + not used? + + + + DRM_MODE_FLAG_PIXMUX + + not used? + + + + DRM_MODE_FLAG_DBLCLK + + not used? + + + + DRM_MODE_FLAG_CLKDIV2 + + ? + + + + + + Note that modes marked with the INTERLACE or DBLSCAN flags will be + filtered out by + drm_helper_probe_single_connector_modes if + the connector's interlace_allowed or + doublescan_allowed field is set to 0. + + + + char name[DRM_DISPLAY_MODE_LEN]; + + Mode name. The driver must call + drm_mode_set_name to fill the mode name from + hdisplay, + vdisplay and interlace flag after + filling the corresponding fields. + + + + + + The vrefresh value is computed by + drm_helper_probe_single_connector_modes. + + + When parsing EDID data, drm_add_edid_modes fills the + connector display_info + width_mm and + height_mm fields. When creating modes + manually the get_modes helper operation must + set the display_info + width_mm and + height_mm fields if they haven't been set + already (for instance at initialization time when a fixed-size panel is + attached to the connector). The mode width_mm + and height_mm fields are only used internally + during EDID parsing and should not be set when creating modes manually. + + + + int (*mode_valid)(struct drm_connector *connector, + struct drm_display_mode *mode); + + Verify whether a mode is valid for the connector. Return MODE_OK for + supported modes and one of the enum drm_mode_status values (MODE_*) + for unsupported modes. This operation is optional. + + + As the mode rejection reason is currently not used beside for + immediately removing the unsupported mode, an implementation can + return MODE_BAD regardless of the exact reason why the mode is not + valid. + + + Note that the mode_valid helper operation is + only called for modes detected by the device, and + not for modes set by the user through the CRTC + set_config operation. + + + + + + Atomic Modeset Helper Functions Reference + + Overview +!Pdrivers/gpu/drm/drm_atomic_helper.c overview + + + Implementing Asynchronous Atomic Commit +!Pdrivers/gpu/drm/drm_atomic_helper.c implementing async commit + + + Atomic State Reset and Initialization +!Pdrivers/gpu/drm/drm_atomic_helper.c atomic state reset and initialization + +!Iinclude/drm/drm_atomic_helper.h +!Edrivers/gpu/drm/drm_atomic_helper.c + + + Modeset Helper Functions Reference +!Iinclude/drm/drm_crtc_helper.h +!Edrivers/gpu/drm/drm_crtc_helper.c +!Pdrivers/gpu/drm/drm_crtc_helper.c overview + + + Output Probing Helper Functions Reference +!Pdrivers/gpu/drm/drm_probe_helper.c output probing helper overview +!Edrivers/gpu/drm/drm_probe_helper.c + + + fbdev Helper Functions Reference +!Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers +!Edrivers/gpu/drm/drm_fb_helper.c +!Iinclude/drm/drm_fb_helper.h + + + Display Port Helper Functions Reference +!Pdrivers/gpu/drm/drm_dp_helper.c dp helpers +!Iinclude/drm/drm_dp_helper.h +!Edrivers/gpu/drm/drm_dp_helper.c + + + Display Port MST Helper Functions Reference +!Pdrivers/gpu/drm/drm_dp_mst_topology.c dp mst helper +!Iinclude/drm/drm_dp_mst_helper.h +!Edrivers/gpu/drm/drm_dp_mst_topology.c + + + MIPI DSI Helper Functions Reference +!Pdrivers/gpu/drm/drm_mipi_dsi.c dsi helpers +!Iinclude/drm/drm_mipi_dsi.h +!Edrivers/gpu/drm/drm_mipi_dsi.c + + + EDID Helper Functions Reference +!Edrivers/gpu/drm/drm_edid.c + + + Rectangle Utilities Reference +!Pinclude/drm/drm_rect.h rect utils +!Iinclude/drm/drm_rect.h +!Edrivers/gpu/drm/drm_rect.c + + + Flip-work Helper Reference +!Pinclude/drm/drm_flip_work.h flip utils +!Iinclude/drm/drm_flip_work.h +!Edrivers/gpu/drm/drm_flip_work.c + + + HDMI Infoframes Helper Reference + + Strictly speaking this is not a DRM helper library but generally useable + by any driver interfacing with HDMI outputs like v4l or alsa drivers. + But it nicely fits into the overall topic of mode setting helper + libraries and hence is also included here. + +!Iinclude/linux/hdmi.h +!Edrivers/video/hdmi.c + + + Plane Helper Reference +!Edrivers/gpu/drm/drm_plane_helper.c +!Pdrivers/gpu/drm/drm_plane_helper.c overview + + + Tile group +!Pdrivers/gpu/drm/drm_crtc.c Tile group + + + Bridges + + Overview +!Pdrivers/gpu/drm/drm_bridge.c overview + + + Default bridge callback sequence +!Pdrivers/gpu/drm/drm_bridge.c bridge callbacks + +!Edrivers/gpu/drm/drm_bridge.c + + + + + + + KMS Properties + + Drivers may need to expose additional parameters to applications than + those described in the previous sections. KMS supports attaching + properties to CRTCs, connectors and planes and offers a userspace API to + list, get and set the property values. + + + Properties are identified by a name that uniquely defines the property + purpose, and store an associated value. For all property types except blob + properties the value is a 64-bit unsigned integer. + + + KMS differentiates between properties and property instances. Drivers + first create properties and then create and associate individual instances + of those properties to objects. A property can be instantiated multiple + times and associated with different objects. Values are stored in property + instances, and all other property information are stored in the property + and shared between all instances of the property. + + + Every property is created with a type that influences how the KMS core + handles the property. Supported property types are + + + DRM_MODE_PROP_RANGE + Range properties report their minimum and maximum + admissible values. The KMS core verifies that values set by + application fit in that range. + + + DRM_MODE_PROP_ENUM + Enumerated properties take a numerical value that + ranges from 0 to the number of enumerated values defined by the + property minus one, and associate a free-formed string name to each + value. Applications can retrieve the list of defined value-name pairs + and use the numerical value to get and set property instance values. + + + + DRM_MODE_PROP_BITMASK + Bitmask properties are enumeration properties that + additionally restrict all enumerated values to the 0..63 range. + Bitmask property instance values combine one or more of the + enumerated bits defined by the property. + + + DRM_MODE_PROP_BLOB + Blob properties store a binary blob without any format + restriction. The binary blobs are created as KMS standalone objects, + and blob property instance values store the ID of their associated + blob object. + Blob properties are only used for the connector EDID property + and cannot be created by drivers. + + + + + To create a property drivers call one of the following functions depending + on the property type. All property creation functions take property flags + and name, as well as type-specific arguments. + + + struct drm_property *drm_property_create_range(struct drm_device *dev, int flags, + const char *name, + uint64_t min, uint64_t max); + Create a range property with the given minimum and maximum + values. + + + struct drm_property *drm_property_create_enum(struct drm_device *dev, int flags, + const char *name, + const struct drm_prop_enum_list *props, + int num_values); + Create an enumerated property. The props + argument points to an array of num_values + value-name pairs. + + + struct drm_property *drm_property_create_bitmask(struct drm_device *dev, + int flags, const char *name, + const struct drm_prop_enum_list *props, + int num_values); + Create a bitmask property. The props + argument points to an array of num_values + value-name pairs. + + + + + Properties can additionally be created as immutable, in which case they + will be read-only for applications but can be modified by the driver. To + create an immutable property drivers must set the DRM_MODE_PROP_IMMUTABLE + flag at property creation time. + + + When no array of value-name pairs is readily available at property + creation time for enumerated or range properties, drivers can create + the property using the drm_property_create function + and manually add enumeration value-name pairs by calling the + drm_property_add_enum function. Care must be taken to + properly specify the property type through the flags + argument. + + + After creating properties drivers can attach property instances to CRTC, + connector and plane objects by calling the + drm_object_attach_property. The function takes a + pointer to the target object, a pointer to the previously created property + and an initial instance value. + + + Existing KMS Properties + + The following table gives description of drm properties exposed by various + modules/drivers. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Owner Module/DriversGroupProperty NameTypeProperty ValuesObject attachedDescription/Restrictions
DRMGeneric“rotation”BITMASK{ 0, "rotate-0" }, + { 1, "rotate-90" }, + { 2, "rotate-180" }, + { 3, "rotate-270" }, + { 4, "reflect-x" }, + { 5, "reflect-y" }CRTC, Planerotate-(degrees) rotates the image by the specified amount in degrees + in counter clockwise direction. reflect-x and reflect-y reflects the + image along the specified axis prior to rotation
Connector“EDID”BLOB | IMMUTABLE0ConnectorContains id of edid blob ptr object.
“DPMS”ENUM{ “On”, “Standby”, “Suspend”, “Off” }ConnectorContains DPMS operation mode value.
“PATH”BLOB | IMMUTABLE0ConnectorContains topology path to a connector.
“TILE”BLOB | IMMUTABLE0ConnectorContains tiling information for a connector.
“CRTC_ID”OBJECTDRM_MODE_OBJECT_CRTCConnectorCRTC that connector is attached to (atomic)
Plane“type”ENUM | IMMUTABLE{ "Overlay", "Primary", "Cursor" }PlanePlane type
“SRC_X”RANGEMin=0, Max=UINT_MAXPlaneScanout source x coordinate in 16.16 fixed point (atomic)
“SRC_Y”RANGEMin=0, Max=UINT_MAXPlaneScanout source y coordinate in 16.16 fixed point (atomic)
“SRC_W”RANGEMin=0, Max=UINT_MAXPlaneScanout source width in 16.16 fixed point (atomic)
“SRC_H”RANGEMin=0, Max=UINT_MAXPlaneScanout source height in 16.16 fixed point (atomic)
“CRTC_X”SIGNED_RANGEMin=INT_MIN, Max=INT_MAXPlaneScanout CRTC (destination) x coordinate (atomic)
“CRTC_Y”SIGNED_RANGEMin=INT_MIN, Max=INT_MAXPlaneScanout CRTC (destination) y coordinate (atomic)
“CRTC_W”RANGEMin=0, Max=UINT_MAXPlaneScanout CRTC (destination) width (atomic)
“CRTC_H”RANGEMin=0, Max=UINT_MAXPlaneScanout CRTC (destination) height (atomic)
“FB_ID”OBJECTDRM_MODE_OBJECT_FBPlaneScanout framebuffer (atomic)
“CRTC_ID”OBJECTDRM_MODE_OBJECT_CRTCPlaneCRTC that plane is attached to (atomic)
DVI-I“subconnector”ENUM{ “Unknown”, “DVI-D”, “DVI-A” }ConnectorTBD
“select subconnector”ENUM{ “Automatic”, “DVI-D”, “DVI-A” }ConnectorTBD
TV“subconnector”ENUM{ "Unknown", "Composite", "SVIDEO", "Component", "SCART" }ConnectorTBD
“select subconnector”ENUM{ "Automatic", "Composite", "SVIDEO", "Component", "SCART" }ConnectorTBD
“mode”ENUM{ "NTSC_M", "NTSC_J", "NTSC_443", "PAL_B" } etc.ConnectorTBD
“left margin”RANGEMin=0, Max=100ConnectorTBD
“right margin”RANGEMin=0, Max=100ConnectorTBD
“top margin”RANGEMin=0, Max=100ConnectorTBD
“bottom margin”RANGEMin=0, Max=100ConnectorTBD
“brightness”RANGEMin=0, Max=100ConnectorTBD
“contrast”RANGEMin=0, Max=100ConnectorTBD
“flicker reduction”RANGEMin=0, Max=100ConnectorTBD
“overscan”RANGEMin=0, Max=100ConnectorTBD
“saturation”RANGEMin=0, Max=100ConnectorTBD
“hue”RANGEMin=0, Max=100ConnectorTBD
Virtual GPU“suggested X”RANGEMin=0, Max=0xffffffffConnectorproperty to suggest an X offset for a connector
“suggested Y”RANGEMin=0, Max=0xffffffffConnectorproperty to suggest an Y offset for a connector
Optional“scaling mode”ENUM{ "None", "Full", "Center", "Full aspect" }ConnectorTBD
"aspect ratio"ENUM{ "None", "4:3", "16:9" }ConnectorDRM property to set aspect ratio from user space app. + This enum is made generic to allow addition of custom aspect + ratios.
“dirty”ENUM | IMMUTABLE{ "Off", "On", "Annotate" }ConnectorTBD
i915Generic"Broadcast RGB"ENUM{ "Automatic", "Full", "Limited 16:235" }ConnectorTBD
“audio”ENUM{ "force-dvi", "off", "auto", "on" }ConnectorTBD
SDVO-TV“mode”ENUM{ "NTSC_M", "NTSC_J", "NTSC_443", "PAL_B" } etc.ConnectorTBD
"left_margin"RANGEMin=0, Max= SDVO dependentConnectorTBD
"right_margin"RANGEMin=0, Max= SDVO dependentConnectorTBD
"top_margin"RANGEMin=0, Max= SDVO dependentConnectorTBD
"bottom_margin"RANGEMin=0, Max= SDVO dependentConnectorTBD
“hpos”RANGEMin=0, Max= SDVO dependentConnectorTBD
“vpos”RANGEMin=0, Max= SDVO dependentConnectorTBD
“contrast”RANGEMin=0, Max= SDVO dependentConnectorTBD
“saturation”RANGEMin=0, Max= SDVO dependentConnectorTBD
“hue”RANGEMin=0, Max= SDVO dependentConnectorTBD
“sharpness”RANGEMin=0, Max= SDVO dependentConnectorTBD
“flicker_filter”RANGEMin=0, Max= SDVO dependentConnectorTBD
“flicker_filter_adaptive”RANGEMin=0, Max= SDVO dependentConnectorTBD
“flicker_filter_2d”RANGEMin=0, Max= SDVO dependentConnectorTBD
“tv_chroma_filter”RANGEMin=0, Max= SDVO dependentConnectorTBD
“tv_luma_filter”RANGEMin=0, Max= SDVO dependentConnectorTBD
“dot_crawl”RANGEMin=0, Max=1ConnectorTBD
SDVO-TV/LVDS“brightness”RANGEMin=0, Max= SDVO dependentConnectorTBD
CDV gma-500Generic"Broadcast RGB"ENUM{ “Full”, “Limited 16:235” }ConnectorTBD
"Broadcast RGB"ENUM{ “off”, “auto”, “on” }ConnectorTBD
PoulsboGeneric“backlight”RANGEMin=0, Max=100ConnectorTBD
SDVO-TV“mode”ENUM{ "NTSC_M", "NTSC_J", "NTSC_443", "PAL_B" } etc.ConnectorTBD
"left_margin"RANGEMin=0, Max= SDVO dependentConnectorTBD
"right_margin"RANGEMin=0, Max= SDVO dependentConnectorTBD
"top_margin"RANGEMin=0, Max= SDVO dependentConnectorTBD
"bottom_margin"RANGEMin=0, Max= SDVO dependentConnectorTBD
“hpos”RANGEMin=0, Max= SDVO dependentConnectorTBD
“vpos”RANGEMin=0, Max= SDVO dependentConnectorTBD
“contrast”RANGEMin=0, Max= SDVO dependentConnectorTBD
“saturation”RANGEMin=0, Max= SDVO dependentConnectorTBD
“hue”RANGEMin=0, Max= SDVO dependentConnectorTBD
“sharpness”RANGEMin=0, Max= SDVO dependentConnectorTBD
“flicker_filter”RANGEMin=0, Max= SDVO dependentConnectorTBD
“flicker_filter_adaptive”RANGEMin=0, Max= SDVO dependentConnectorTBD
“flicker_filter_2d”RANGEMin=0, Max= SDVO dependentConnectorTBD
“tv_chroma_filter”RANGEMin=0, Max= SDVO dependentConnectorTBD
“tv_luma_filter”RANGEMin=0, Max= SDVO dependentConnectorTBD
“dot_crawl”RANGEMin=0, Max=1ConnectorTBD
SDVO-TV/LVDS“brightness”RANGEMin=0, Max= SDVO dependentConnectorTBD
armadaCRTC"CSC_YUV"ENUM{ "Auto" , "CCIR601", "CCIR709" }CRTCTBD
"CSC_RGB"ENUM{ "Auto", "Computer system", "Studio" }CRTCTBD
Overlay"colorkey"RANGEMin=0, Max=0xffffffPlaneTBD
"colorkey_min"RANGEMin=0, Max=0xffffffPlaneTBD
"colorkey_max"RANGEMin=0, Max=0xffffffPlaneTBD
"colorkey_val"RANGEMin=0, Max=0xffffffPlaneTBD
"colorkey_alpha"RANGEMin=0, Max=0xffffffPlaneTBD
"colorkey_mode"ENUM{ "disabled", "Y component", "U component" + , "V component", "RGB", “R component", "G component", "B component" }PlaneTBD
"brightness"RANGEMin=0, Max=256 + 255PlaneTBD
"contrast"RANGEMin=0, Max=0x7fffPlaneTBD
"saturation"RANGEMin=0, Max=0x7fffPlaneTBD
exynosCRTC“mode”ENUM{ "normal", "blank" }CRTCTBD
Overlay“zpos”RANGEMin=0, Max=MAX_PLANE-1PlaneTBD
i2c/ch7006_drvGeneric“scale”RANGEMin=0, Max=2ConnectorTBD
TV“mode”ENUM{ "PAL", "PAL-M","PAL-N"}, ”PAL-Nc" + , "PAL-60", "NTSC-M", "NTSC-J" }ConnectorTBD
nouveauNV10 Overlay"colorkey"RANGEMin=0, Max=0x01ffffffPlaneTBD
“contrast”RANGEMin=0, Max=8192-1PlaneTBD
“brightness”RANGEMin=0, Max=1024PlaneTBD
“hue”RANGEMin=0, Max=359PlaneTBD
“saturation”RANGEMin=0, Max=8192-1PlaneTBD
“iturbt_709”RANGEMin=0, Max=1PlaneTBD
Nv04 Overlay“colorkey”RANGEMin=0, Max=0x01ffffffPlaneTBD
“brightness”RANGEMin=0, Max=1024PlaneTBD
Display“dithering mode”ENUM{ "auto", "off", "on" }ConnectorTBD
“dithering depth”ENUM{ "auto", "off", "on", "static 2x2", "dynamic 2x2", "temporal" }ConnectorTBD
“underscan”ENUM{ "auto", "6 bpc", "8 bpc" }ConnectorTBD
“underscan hborder”RANGEMin=0, Max=128ConnectorTBD
“underscan vborder”RANGEMin=0, Max=128ConnectorTBD
“vibrant hue”RANGEMin=0, Max=180ConnectorTBD
“color vibrance”RANGEMin=0, Max=200ConnectorTBD
omapGeneric“zorder”RANGEMin=0, Max=3CRTC, PlaneTBD
qxlGeneric“hotplug_mode_update"RANGEMin=0, Max=1ConnectorTBD
radeonDVI-I“coherent”RANGEMin=0, Max=1ConnectorTBD
DAC enable load detect“load detection”RANGEMin=0, Max=1ConnectorTBD
TV Standard"tv standard"ENUM{ "ntsc", "pal", "pal-m", "pal-60", "ntsc-j" + , "scart-pal", "pal-cn", "secam" }ConnectorTBD
legacy TMDS PLL detect"tmds_pll"ENUM{ "driver", "bios" }-TBD
Underscan"underscan"ENUM{ "off", "on", "auto" }ConnectorTBD
"underscan hborder"RANGEMin=0, Max=128ConnectorTBD
"underscan vborder"RANGEMin=0, Max=128ConnectorTBD
Audio“audio”ENUM{ "off", "on", "auto" }ConnectorTBD
FMT Dithering“dither”ENUM{ "off", "on" }ConnectorTBD
rcar-duGeneric"alpha"RANGEMin=0, Max=255PlaneTBD
"colorkey"RANGEMin=0, Max=0x01ffffffPlaneTBD
"zpos"RANGEMin=1, Max=7PlaneTBD
+ + + + + + + Vertical Blanking + + Vertical blanking plays a major role in graphics rendering. To achieve + tear-free display, users must synchronize page flips and/or rendering to + vertical blanking. The DRM API offers ioctls to perform page flips + synchronized to vertical blanking and wait for vertical blanking. + + + The DRM core handles most of the vertical blanking management logic, which + involves filtering out spurious interrupts, keeping race-free blanking + counters, coping with counter wrap-around and resets and keeping use + counts. It relies on the driver to generate vertical blanking interrupts + and optionally provide a hardware vertical blanking counter. Drivers must + implement the following operations. + + + + int (*enable_vblank) (struct drm_device *dev, int crtc); +void (*disable_vblank) (struct drm_device *dev, int crtc); + + Enable or disable vertical blanking interrupts for the given CRTC. + + + + u32 (*get_vblank_counter) (struct drm_device *dev, int crtc); + + Retrieve the value of the vertical blanking counter for the given + CRTC. If the hardware maintains a vertical blanking counter its value + should be returned. Otherwise drivers can use the + drm_vblank_count helper function to handle this + operation. + + + + + Drivers must initialize the vertical blanking handling core with a call to + drm_vblank_init in their + load operation. The function will set the struct + drm_device + vblank_disable_allowed field to 0. This will + keep vertical blanking interrupts enabled permanently until the first mode + set operation, where vblank_disable_allowed is + set to 1. The reason behind this is not clear. Drivers can set the field + to 1 after calling drm_vblank_init to make vertical + blanking interrupts dynamically managed from the beginning. + + + Vertical blanking interrupts can be enabled by the DRM core or by drivers + themselves (for instance to handle page flipping operations). The DRM core + maintains a vertical blanking use count to ensure that the interrupts are + not disabled while a user still needs them. To increment the use count, + drivers call drm_vblank_get. Upon return vertical + blanking interrupts are guaranteed to be enabled. + + + To decrement the use count drivers call + drm_vblank_put. Only when the use count drops to zero + will the DRM core disable the vertical blanking interrupts after a delay + by scheduling a timer. The delay is accessible through the vblankoffdelay + module parameter or the drm_vblank_offdelay global + variable and expressed in milliseconds. Its default value is 5000 ms. + Zero means never disable, and a negative value means disable immediately. + Drivers may override the behaviour by setting the + drm_device + vblank_disable_immediate flag, which when set + causes vblank interrupts to be disabled immediately regardless of the + drm_vblank_offdelay value. The flag should only be set if there's a + properly working hardware vblank counter present. + + + When a vertical blanking interrupt occurs drivers only need to call the + drm_handle_vblank function to account for the + interrupt. + + + Resources allocated by drm_vblank_init must be freed + with a call to drm_vblank_cleanup in the driver + unload operation handler. + + + Vertical Blanking and Interrupt Handling Functions Reference +!Edrivers/gpu/drm/drm_irq.c +!Finclude/drm/drmP.h drm_crtc_vblank_waitqueue + + + + + + + Open/Close, File Operations and IOCTLs + + Open and Close + int (*firstopen) (struct drm_device *); +void (*lastclose) (struct drm_device *); +int (*open) (struct drm_device *, struct drm_file *); +void (*preclose) (struct drm_device *, struct drm_file *); +void (*postclose) (struct drm_device *, struct drm_file *); + Open and close handlers. None of those methods are mandatory. + + + The firstopen method is called by the DRM core + for legacy UMS (User Mode Setting) drivers only when an application + opens a device that has no other opened file handle. UMS drivers can + implement it to acquire device resources. KMS drivers can't use the + method and must acquire resources in the load + method instead. + + + Similarly the lastclose method is called when + the last application holding a file handle opened on the device closes + it, for both UMS and KMS drivers. Additionally, the method is also + called at module unload time or, for hot-pluggable devices, when the + device is unplugged. The firstopen and + lastclose calls can thus be unbalanced. + + + The open method is called every time the device + is opened by an application. Drivers can allocate per-file private data + in this method and store them in the struct + drm_file driver_priv + field. Note that the open method is called + before firstopen. + + + The close operation is split into preclose and + postclose methods. Drivers must stop and + cleanup all per-file operations in the preclose + method. For instance pending vertical blanking and page flip events must + be cancelled. No per-file operation is allowed on the file handle after + returning from the preclose method. + + + Finally the postclose method is called as the + last step of the close operation, right before calling the + lastclose method if no other open file handle + exists for the device. Drivers that have allocated per-file private data + in the open method should free it here. + + + The lastclose method should restore CRTC and + plane properties to default value, so that a subsequent open of the + device will not inherit state from the previous user. It can also be + used to execute delayed power switching state changes, e.g. in + conjunction with the vga_switcheroo infrastructure (see + ). Beyond that KMS drivers should not + do any further cleanup. Only legacy UMS drivers might need to clean up + device state so that the vga console or an independent fbdev driver + could take over. + + + + File Operations + const struct file_operations *fops + File operations for the DRM device node. + + Drivers must define the file operations structure that forms the DRM + userspace API entry point, even though most of those operations are + implemented in the DRM core. The open, + release and ioctl + operations are handled by + + .owner = THIS_MODULE, + .open = drm_open, + .release = drm_release, + .unlocked_ioctl = drm_ioctl, + #ifdef CONFIG_COMPAT + .compat_ioctl = drm_compat_ioctl, + #endif + + + + Drivers that implement private ioctls that requires 32/64bit + compatibility support must provide their own + compat_ioctl handler that processes private + ioctls and calls drm_compat_ioctl for core ioctls. + + + The read and poll + operations provide support for reading DRM events and polling them. They + are implemented by + + .poll = drm_poll, + .read = drm_read, + .llseek = no_llseek, + + + + The memory mapping implementation varies depending on how the driver + manages memory. Pre-GEM drivers will use drm_mmap, + while GEM-aware drivers will use drm_gem_mmap. See + . + + .mmap = drm_gem_mmap, + + + + No other file operation is supported by the DRM API. + + + + IOCTLs + struct drm_ioctl_desc *ioctls; +int num_ioctls; + Driver-specific ioctls descriptors table. + + Driver-specific ioctls numbers start at DRM_COMMAND_BASE. The ioctls + descriptors table is indexed by the ioctl number offset from the base + value. Drivers can use the DRM_IOCTL_DEF_DRV() macro to initialize the + table entries. + + + DRM_IOCTL_DEF_DRV(ioctl, func, flags) + + ioctl is the ioctl name. Drivers must define + the DRM_##ioctl and DRM_IOCTL_##ioctl macros to the ioctl number + offset from DRM_COMMAND_BASE and the ioctl number respectively. The + first macro is private to the device while the second must be exposed + to userspace in a public header. + + + func is a pointer to the ioctl handler function + compatible with the drm_ioctl_t type. + typedef int drm_ioctl_t(struct drm_device *dev, void *data, + struct drm_file *file_priv); + + + flags is a bitmask combination of the following + values. It restricts how the ioctl is allowed to be called. + + + DRM_AUTH - Only authenticated callers allowed + + + DRM_MASTER - The ioctl can only be called on the master file + handle + + + DRM_ROOT_ONLY - Only callers with the SYSADMIN capability allowed + + + DRM_CONTROL_ALLOW - The ioctl can only be called on a control + device + + + DRM_UNLOCKED - The ioctl handler will be called without locking + the DRM global mutex. This is the enforced default for kms drivers + (i.e. using the DRIVER_MODESET flag) and hence shouldn't be used + any more for new drivers. + + + + +!Edrivers/gpu/drm/drm_ioctl.c + + + + Legacy Support Code + + The section very briefly covers some of the old legacy support code which + is only used by old DRM drivers which have done a so-called shadow-attach + to the underlying device instead of registering as a real driver. This + also includes some of the old generic buffer management and command + submission code. Do not use any of this in new and modern drivers. + + + + Legacy Suspend/Resume + + The DRM core provides some suspend/resume code, but drivers wanting full + suspend/resume support should provide save() and restore() functions. + These are called at suspend, hibernate, or resume time, and should perform + any state save or restore required by your device across suspend or + hibernate states. + + int (*suspend) (struct drm_device *, pm_message_t state); + int (*resume) (struct drm_device *); + + Those are legacy suspend and resume methods which + only work with the legacy shadow-attach driver + registration functions. New driver should use the power management + interface provided by their bus type (usually through + the struct device_driver dev_pm_ops) and set + these methods to NULL. + + + + + Legacy DMA Services + + This should cover how DMA mapping etc. is supported by the core. + These functions are deprecated and should not be used. + + + + + + + + + + + Userland interfaces + + The DRM core exports several interfaces to applications, + generally intended to be used through corresponding libdrm + wrapper functions. In addition, drivers export device-specific + interfaces for use by userspace drivers & device-aware + applications through ioctls and sysfs files. + + + External interfaces include: memory mapping, context management, + DMA operations, AGP management, vblank control, fence + management, memory management, and output management. + + + Cover generic ioctls and sysfs layout here. We only need high-level + info, since man pages should cover the rest. + + + + + + Render nodes + + DRM core provides multiple character-devices for user-space to use. + Depending on which device is opened, user-space can perform a different + set of operations (mainly ioctls). The primary node is always created + and called card<num>. Additionally, a currently + unused control node, called controlD<num> is also + created. The primary node provides all legacy operations and + historically was the only interface used by userspace. With KMS, the + control node was introduced. However, the planned KMS control interface + has never been written and so the control node stays unused to date. + + + With the increased use of offscreen renderers and GPGPU applications, + clients no longer require running compositors or graphics servers to + make use of a GPU. But the DRM API required unprivileged clients to + authenticate to a DRM-Master prior to getting GPU access. To avoid this + step and to grant clients GPU access without authenticating, render + nodes were introduced. Render nodes solely serve render clients, that + is, no modesetting or privileged ioctls can be issued on render nodes. + Only non-global rendering commands are allowed. If a driver supports + render nodes, it must advertise it via the DRIVER_RENDER + DRM driver capability. If not supported, the primary node must be used + for render clients together with the legacy drmAuth authentication + procedure. + + + If a driver advertises render node support, DRM core will create a + separate render node called renderD<num>. There will + be one render node per device. No ioctls except PRIME-related ioctls + will be allowed on this node. Especially GEM_OPEN will be + explicitly prohibited. Render nodes are designed to avoid the + buffer-leaks, which occur if clients guess the flink names or mmap + offsets on the legacy interface. Additionally to this basic interface, + drivers must mark their driver-dependent render-only ioctls as + DRM_RENDER_ALLOW so render clients can use them. Driver + authors must be careful not to allow any privileged ioctls on render + nodes. + + + With render nodes, user-space can now control access to the render node + via basic file-system access-modes. A running graphics server which + authenticates clients on the privileged primary/legacy node is no longer + required. Instead, a client can open the render node and is immediately + granted GPU access. Communication between clients (or servers) is done + via PRIME. FLINK from render node to legacy node is not supported. New + clients must not use the insecure FLINK interface. + + + Besides dropping all modeset/global ioctls, render nodes also drop the + DRM-Master concept. There is no reason to associate render clients with + a DRM-Master as they are independent of any graphics server. Besides, + they must work without any running master, anyway. + Drivers must be able to run without a master object if they support + render nodes. If, on the 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. + + + + + + + VBlank event handling + + The DRM core exposes two vertical blank related ioctls: + + + DRM_IOCTL_WAIT_VBLANK + + + This takes a struct drm_wait_vblank structure as its argument, + and it is used to block or request a signal when a specified + vblank event occurs. + + + + + DRM_IOCTL_MODESET_CTL + + + This was only used for user-mode-settind drivers around + modesetting changes to allow the kernel to update the vblank + interrupt after 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. + + + + + + + + + + + DRM Drivers + + + + 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. + + + + + drm/i915 Intel GFX Driver + + The drm/i915 driver supports all (with the exception of some very early + models) integrated GFX chipsets with both Intel display and rendering + blocks. This excludes a set of SoC platforms with an SGX rendering unit, + those have basic support through the gma500 drm driver. + + + Core Driver Infrastructure + + This section covers core driver infrastructure used by both the display + and the GEM parts of the driver. + + + Runtime Power Management +!Pdrivers/gpu/drm/i915/intel_runtime_pm.c runtime pm +!Idrivers/gpu/drm/i915/intel_runtime_pm.c +!Idrivers/gpu/drm/i915/intel_uncore.c + + + Interrupt Handling +!Pdrivers/gpu/drm/i915/i915_irq.c interrupt handling +!Fdrivers/gpu/drm/i915/i915_irq.c intel_irq_init intel_irq_init_hw intel_hpd_init +!Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_disable_interrupts +!Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_enable_interrupts + + + Intel GVT-g Guest Support(vGPU) +!Pdrivers/gpu/drm/i915/i915_vgpu.c Intel GVT-g guest support +!Idrivers/gpu/drm/i915/i915_vgpu.c + + + + Display Hardware Handling + + This section covers everything related to the display hardware including + the mode setting infrastructure, plane, sprite and cursor handling and + display, output probing and related topics. + + + Mode Setting Infrastructure + + The i915 driver is thus far the only DRM driver which doesn't use the + common DRM helper code to implement mode setting sequences. Thus it + has its own tailor-made infrastructure for executing a display + configuration change. + + + + Frontbuffer Tracking +!Pdrivers/gpu/drm/i915/intel_frontbuffer.c frontbuffer tracking +!Idrivers/gpu/drm/i915/intel_frontbuffer.c +!Fdrivers/gpu/drm/i915/i915_gem.c i915_gem_track_fb + + + Display FIFO Underrun Reporting +!Pdrivers/gpu/drm/i915/intel_fifo_underrun.c fifo underrun handling +!Idrivers/gpu/drm/i915/intel_fifo_underrun.c + + + Plane Configuration + + This section covers plane configuration and composition with the + primary plane, sprites, cursors and overlays. This includes the + infrastructure to do atomic vsync'ed updates of all this state and + also tightly coupled topics like watermark setup and computation, + framebuffer compression and panel self refresh. + + + + Atomic Plane Helpers +!Pdrivers/gpu/drm/i915/intel_atomic_plane.c atomic plane helpers +!Idrivers/gpu/drm/i915/intel_atomic_plane.c + + + Output Probing + + This section covers output probing and related infrastructure like the + hotplug interrupt storm detection and mitigation code. Note that the + i915 driver still uses most of the common DRM helper code for output + probing, so those sections fully apply. + + + + Hotplug +!Pdrivers/gpu/drm/i915/intel_hotplug.c Hotplug +!Idrivers/gpu/drm/i915/intel_hotplug.c + + + High Definition Audio +!Pdrivers/gpu/drm/i915/intel_audio.c High Definition Audio over HDMI and Display Port +!Idrivers/gpu/drm/i915/intel_audio.c +!Iinclude/drm/i915_component.h + + + Panel Self Refresh PSR (PSR/SRD) +!Pdrivers/gpu/drm/i915/intel_psr.c Panel Self Refresh (PSR/SRD) +!Idrivers/gpu/drm/i915/intel_psr.c + + + Frame Buffer Compression (FBC) +!Pdrivers/gpu/drm/i915/intel_fbc.c Frame Buffer Compression (FBC) +!Idrivers/gpu/drm/i915/intel_fbc.c + + + Display Refresh Rate Switching (DRRS) +!Pdrivers/gpu/drm/i915/intel_dp.c Display Refresh Rate Switching (DRRS) +!Fdrivers/gpu/drm/i915/intel_dp.c intel_dp_set_drrs_state +!Fdrivers/gpu/drm/i915/intel_dp.c intel_edp_drrs_enable +!Fdrivers/gpu/drm/i915/intel_dp.c intel_edp_drrs_disable +!Fdrivers/gpu/drm/i915/intel_dp.c intel_edp_drrs_invalidate +!Fdrivers/gpu/drm/i915/intel_dp.c intel_edp_drrs_flush +!Fdrivers/gpu/drm/i915/intel_dp.c intel_dp_drrs_init + + + + DPIO +!Pdrivers/gpu/drm/i915/i915_reg.h DPIO + + Dual channel PHY (VLV/CHV/BXT) + + + + + + + + + + + + + + + + + + CH0 + CH1 + + + + + CMN/PLL/REF + CMN/PLL/REF + + + PCS01 + PCS23 + PCS01 + PCS23 + + + TX0 + TX1 + TX2 + TX3 + TX0 + TX1 + TX2 + TX3 + + + DDI0 + DDI1 + + + +
+ + Single channel PHY (CHV/BXT) + + + + + + + + + + + CH0 + + + + + CMN/PLL/REF + + + PCS01 + PCS23 + + + TX0 + TX1 + TX2 + TX3 + + + DDI2 + + + +
+ + + + CSR firmware support for DMC +!Pdrivers/gpu/drm/i915/intel_csr.c csr support for dmc +!Idrivers/gpu/drm/i915/intel_csr.c + + + + + Memory Management and Command Submission + + This sections covers all things related to the GEM implementation in the + i915 driver. + + + Batchbuffer Parsing +!Pdrivers/gpu/drm/i915/i915_cmd_parser.c batch buffer command parser +!Idrivers/gpu/drm/i915/i915_cmd_parser.c + + + Batchbuffer Pools +!Pdrivers/gpu/drm/i915/i915_gem_batch_pool.c batch pool +!Idrivers/gpu/drm/i915/i915_gem_batch_pool.c + + + Logical Rings, Logical Ring Contexts and Execlists +!Pdrivers/gpu/drm/i915/intel_lrc.c Logical Rings, Logical Ring Contexts and Execlists +!Idrivers/gpu/drm/i915/intel_lrc.c + + + Global GTT views +!Pdrivers/gpu/drm/i915/i915_gem_gtt.c Global GTT views +!Idrivers/gpu/drm/i915/i915_gem_gtt.c + + + GTT Fences and Swizzling +!Idrivers/gpu/drm/i915/i915_gem_fence.c + + Global GTT Fence Handling +!Pdrivers/gpu/drm/i915/i915_gem_fence.c fence register handling + + + Hardware Tiling and Swizzling Details +!Pdrivers/gpu/drm/i915/i915_gem_fence.c tiling swizzling details + + + + Object Tiling IOCTLs +!Idrivers/gpu/drm/i915/i915_gem_tiling.c +!Pdrivers/gpu/drm/i915/i915_gem_tiling.c buffer object tiling + + + Buffer Object Eviction + + This section documents the interface functions for evicting buffer + objects to make space available in the virtual gpu address spaces. + Note that this is mostly orthogonal to shrinking buffer objects + caches, which has the goal to make main memory (shared with the gpu + through the unified memory architecture) available. + +!Idrivers/gpu/drm/i915/i915_gem_evict.c + + + Buffer Object Memory Shrinking + + This section documents the interface function for shrinking memory + usage of buffer object caches. Shrinking is used to make main memory + available. Note that this is mostly orthogonal to evicting buffer + objects, which has the goal to make space in gpu virtual address + spaces. + +!Idrivers/gpu/drm/i915/i915_gem_shrinker.c + + + + GuC-based Command Submission + + GuC +!Pdrivers/gpu/drm/i915/intel_guc_loader.c GuC-specific firmware loader +!Idrivers/gpu/drm/i915/intel_guc_loader.c + + + GuC Client +!Pdrivers/gpu/drm/i915/i915_guc_submission.c GuC-based command submissison +!Idrivers/gpu/drm/i915/i915_guc_submission.c + + + + + Tracing + + This sections covers all things related to the tracepoints implemented in + the i915 driver. + + + i915_ppgtt_create and i915_ppgtt_release +!Pdrivers/gpu/drm/i915/i915_trace.h i915_ppgtt_create and i915_ppgtt_release tracepoints + + + i915_context_create and i915_context_free +!Pdrivers/gpu/drm/i915/i915_trace.h i915_context_create and i915_context_free tracepoints + + + switch_mm +!Pdrivers/gpu/drm/i915/i915_trace.h switch_mm tracepoint + + + + +!Cdrivers/gpu/drm/i915/i915_irq.c + + + + vga_switcheroo + +!Pdrivers/gpu/vga/vga_switcheroo.c Overview + + + + Modes of Use + + Manual switching and manual power control +!Pdrivers/gpu/vga/vga_switcheroo.c Manual switching and manual power control + + + Driver power control +!Pdrivers/gpu/vga/vga_switcheroo.c Driver power control + + + + + Public functions +!Edrivers/gpu/vga/vga_switcheroo.c + + + + Public structures +!Finclude/linux/vga_switcheroo.h vga_switcheroo_handler +!Finclude/linux/vga_switcheroo.h vga_switcheroo_client_ops + + + + Public constants +!Finclude/linux/vga_switcheroo.h vga_switcheroo_client_id +!Finclude/linux/vga_switcheroo.h vga_switcheroo_state + + + + Private structures +!Fdrivers/gpu/vga/vga_switcheroo.c vgasr_priv +!Fdrivers/gpu/vga/vga_switcheroo.c vga_switcheroo_client + + +!Cdrivers/gpu/vga/vga_switcheroo.c +!Cinclude/linux/vga_switcheroo.h + + + diff --git a/Documentation/DocBook/iio.tmpl b/Documentation/DocBook/iio.tmpl index 06bb53de5..98be32267 100644 --- a/Documentation/DocBook/iio.tmpl +++ b/Documentation/DocBook/iio.tmpl @@ -578,7 +578,7 @@ work together. IIO triggered buffer setup -!Edrivers/iio/industrialio-triggered-buffer.c +!Edrivers/iio/buffer/industrialio-triggered-buffer.c !Finclude/linux/iio/iio.h iio_buffer_setup_ops diff --git a/Documentation/DocBook/media/dvb/dvbapi.xml b/Documentation/DocBook/media/dvb/dvbapi.xml index 858fd7d17..8576481e2 100644 --- a/Documentation/DocBook/media/dvb/dvbapi.xml +++ b/Documentation/DocBook/media/dvb/dvbapi.xml @@ -125,9 +125,6 @@ Added ISDB-T test originally written by Patrick Boettcher &sub-audio; - - &sub-kdapi; - &sub-examples; diff --git a/Documentation/DocBook/media/dvb/kdapi.xml b/Documentation/DocBook/media/dvb/kdapi.xml deleted file mode 100644 index 68bcd33a8..000000000 --- a/Documentation/DocBook/media/dvb/kdapi.xml +++ /dev/null @@ -1,2309 +0,0 @@ -Kernel Demux API -The kernel demux API defines a driver-internal interface for registering low-level, -hardware specific driver to a hardware independent demux layer. It is only of interest for -DVB device driver writers. The header file for this API is named demux.h and located in -">drivers/media/dvb-core. - -Maintainer note: This section must be reviewed. It is probably out of date. - - -
-Kernel Demux Data Types - - -
-dmx_success_t - - typedef enum { - DMX_OK = 0, /⋆ Received Ok ⋆/ - DMX_LENGTH_ERROR, /⋆ Incorrect length ⋆/ - DMX_OVERRUN_ERROR, /⋆ Receiver ring buffer overrun ⋆/ - DMX_CRC_ERROR, /⋆ Incorrect CRC ⋆/ - DMX_FRAME_ERROR, /⋆ Frame alignment error ⋆/ - DMX_FIFO_ERROR, /⋆ Receiver FIFO overrun ⋆/ - DMX_MISSED_ERROR /⋆ Receiver missed packet ⋆/ - } dmx_success_t; - - -
-
-TS filter types - - /⋆--------------------------------------------------------------------------⋆/ - /⋆ TS packet reception ⋆/ - /⋆--------------------------------------------------------------------------⋆/ - - /⋆ TS filter type for set_type() ⋆/ - - #define TS_PACKET 1 /⋆ send TS packets (188 bytes) to callback (default) ⋆/ - #define TS_PAYLOAD_ONLY 2 /⋆ in case TS_PACKET is set, only send the TS - payload (<=184 bytes per packet) to callback ⋆/ - #define TS_DECODER 4 /⋆ send stream to built-in decoder (if present) ⋆/ - - -
-
-dmx_ts_pes_t -The structure - - - typedef enum - { - DMX_TS_PES_AUDIO, /⋆ also send packets to audio decoder (if it exists) ⋆/ - DMX_TS_PES_VIDEO, /⋆ ... ⋆/ - DMX_TS_PES_TELETEXT, - DMX_TS_PES_SUBTITLE, - DMX_TS_PES_PCR, - DMX_TS_PES_OTHER, - } dmx_ts_pes_t; - -describes the PES type for filters which write to a built-in decoder. The correspond (and -should be kept identical) to the types in the demux device. - - - struct dmx_ts_feed_s { - int is_filtering; /⋆ Set to non-zero when filtering in progress ⋆/ - struct dmx_demux_s⋆ parent; /⋆ Back-pointer ⋆/ - void⋆ priv; /⋆ Pointer to private data of the API client ⋆/ - int (⋆set) (struct dmx_ts_feed_s⋆ feed, - __u16 pid, - size_t callback_length, - size_t circular_buffer_size, - int descramble, - struct timespec timeout); - int (⋆start_filtering) (struct dmx_ts_feed_s⋆ feed); - int (⋆stop_filtering) (struct dmx_ts_feed_s⋆ feed); - int (⋆set_type) (struct dmx_ts_feed_s⋆ feed, - int type, - dmx_ts_pes_t pes_type); - }; - - typedef struct dmx_ts_feed_s dmx_ts_feed_t; - - - /⋆--------------------------------------------------------------------------⋆/ - /⋆ PES packet reception (not supported yet) ⋆/ - /⋆--------------------------------------------------------------------------⋆/ - - typedef struct dmx_pes_filter_s { - struct dmx_pes_s⋆ parent; /⋆ Back-pointer ⋆/ - void⋆ priv; /⋆ Pointer to private data of the API client ⋆/ - } dmx_pes_filter_t; - - - typedef struct dmx_pes_feed_s { - int is_filtering; /⋆ Set to non-zero when filtering in progress ⋆/ - struct dmx_demux_s⋆ parent; /⋆ Back-pointer ⋆/ - void⋆ priv; /⋆ Pointer to private data of the API client ⋆/ - int (⋆set) (struct dmx_pes_feed_s⋆ feed, - __u16 pid, - size_t circular_buffer_size, - int descramble, - struct timespec timeout); - int (⋆start_filtering) (struct dmx_pes_feed_s⋆ feed); - int (⋆stop_filtering) (struct dmx_pes_feed_s⋆ feed); - int (⋆allocate_filter) (struct dmx_pes_feed_s⋆ feed, - dmx_pes_filter_t⋆⋆ filter); - int (⋆release_filter) (struct dmx_pes_feed_s⋆ feed, - dmx_pes_filter_t⋆ filter); - } dmx_pes_feed_t; - - - typedef struct { - __u8 filter_value [DMX_MAX_FILTER_SIZE]; - __u8 filter_mask [DMX_MAX_FILTER_SIZE]; - struct dmx_section_feed_s⋆ parent; /⋆ Back-pointer ⋆/ - void⋆ priv; /⋆ Pointer to private data of the API client ⋆/ - } dmx_section_filter_t; - - - struct dmx_section_feed_s { - int is_filtering; /⋆ Set to non-zero when filtering in progress ⋆/ - struct dmx_demux_s⋆ parent; /⋆ Back-pointer ⋆/ - void⋆ priv; /⋆ Pointer to private data of the API client ⋆/ - int (⋆set) (struct dmx_section_feed_s⋆ feed, - __u16 pid, - size_t circular_buffer_size, - int descramble, - int check_crc); - int (⋆allocate_filter) (struct dmx_section_feed_s⋆ feed, - dmx_section_filter_t⋆⋆ filter); - int (⋆release_filter) (struct dmx_section_feed_s⋆ feed, - dmx_section_filter_t⋆ filter); - int (⋆start_filtering) (struct dmx_section_feed_s⋆ feed); - int (⋆stop_filtering) (struct dmx_section_feed_s⋆ feed); - }; - typedef struct dmx_section_feed_s dmx_section_feed_t; - - /⋆--------------------------------------------------------------------------⋆/ - /⋆ Callback functions ⋆/ - /⋆--------------------------------------------------------------------------⋆/ - - typedef int (⋆dmx_ts_cb) ( __u8 ⋆ buffer1, - size_t buffer1_length, - __u8 ⋆ buffer2, - size_t buffer2_length, - dmx_ts_feed_t⋆ source, - dmx_success_t success); - - typedef int (⋆dmx_section_cb) ( __u8 ⋆ buffer1, - size_t buffer1_len, - __u8 ⋆ buffer2, - size_t buffer2_len, - dmx_section_filter_t ⋆ source, - dmx_success_t success); - - typedef int (⋆dmx_pes_cb) ( __u8 ⋆ buffer1, - size_t buffer1_len, - __u8 ⋆ buffer2, - size_t buffer2_len, - dmx_pes_filter_t⋆ source, - dmx_success_t success); - - /⋆--------------------------------------------------------------------------⋆/ - /⋆ DVB Front-End ⋆/ - /⋆--------------------------------------------------------------------------⋆/ - - typedef enum { - DMX_OTHER_FE = 0, - DMX_SATELLITE_FE, - DMX_CABLE_FE, - DMX_TERRESTRIAL_FE, - DMX_LVDS_FE, - DMX_ASI_FE, /⋆ DVB-ASI interface ⋆/ - DMX_MEMORY_FE - } dmx_frontend_source_t; - - typedef struct { - /⋆ The following char⋆ fields point to NULL terminated strings ⋆/ - char⋆ id; /⋆ Unique front-end identifier ⋆/ - char⋆ vendor; /⋆ Name of the front-end vendor ⋆/ - char⋆ model; /⋆ Name of the front-end model ⋆/ - struct list_head connectivity_list; /⋆ List of front-ends that can - be connected to a particular - demux ⋆/ - void⋆ priv; /⋆ Pointer to private data of the API client ⋆/ - dmx_frontend_source_t source; - } dmx_frontend_t; - - /⋆--------------------------------------------------------------------------⋆/ - /⋆ MPEG-2 TS Demux ⋆/ - /⋆--------------------------------------------------------------------------⋆/ - - /⋆ - ⋆ Flags OR'ed in the capabilites field of struct dmx_demux_s. - ⋆/ - - #define DMX_TS_FILTERING 1 - #define DMX_PES_FILTERING 2 - #define DMX_SECTION_FILTERING 4 - #define DMX_MEMORY_BASED_FILTERING 8 /⋆ write() available ⋆/ - #define DMX_CRC_CHECKING 16 - #define DMX_TS_DESCRAMBLING 32 - #define DMX_SECTION_PAYLOAD_DESCRAMBLING 64 - #define DMX_MAC_ADDRESS_DESCRAMBLING 128 - - -
-
-demux_demux_t - - /⋆ - ⋆ DMX_FE_ENTRY(): Casts elements in the list of registered - ⋆ front-ends from the generic type struct list_head - ⋆ to the type ⋆ dmx_frontend_t - ⋆. - ⋆/ - - #define DMX_FE_ENTRY(list) list_entry(list, dmx_frontend_t, connectivity_list) - - struct dmx_demux_s { - /⋆ The following char⋆ fields point to NULL terminated strings ⋆/ - char⋆ id; /⋆ Unique demux identifier ⋆/ - char⋆ vendor; /⋆ Name of the demux vendor ⋆/ - char⋆ model; /⋆ Name of the demux model ⋆/ - __u32 capabilities; /⋆ Bitfield of capability flags ⋆/ - dmx_frontend_t⋆ frontend; /⋆ Front-end connected to the demux ⋆/ - struct list_head reg_list; /⋆ List of registered demuxes ⋆/ - void⋆ priv; /⋆ Pointer to private data of the API client ⋆/ - int users; /⋆ Number of users ⋆/ - int (⋆open) (struct dmx_demux_s⋆ demux); - int (⋆close) (struct dmx_demux_s⋆ demux); - int (⋆write) (struct dmx_demux_s⋆ demux, const char⋆ buf, size_t count); - int (⋆allocate_ts_feed) (struct dmx_demux_s⋆ demux, - dmx_ts_feed_t⋆⋆ feed, - dmx_ts_cb callback); - int (⋆release_ts_feed) (struct dmx_demux_s⋆ demux, - dmx_ts_feed_t⋆ feed); - int (⋆allocate_pes_feed) (struct dmx_demux_s⋆ demux, - dmx_pes_feed_t⋆⋆ feed, - dmx_pes_cb callback); - int (⋆release_pes_feed) (struct dmx_demux_s⋆ demux, - dmx_pes_feed_t⋆ feed); - int (⋆allocate_section_feed) (struct dmx_demux_s⋆ demux, - dmx_section_feed_t⋆⋆ feed, - dmx_section_cb callback); - int (⋆release_section_feed) (struct dmx_demux_s⋆ demux, - dmx_section_feed_t⋆ feed); - int (⋆descramble_mac_address) (struct dmx_demux_s⋆ demux, - __u8⋆ buffer1, - size_t buffer1_length, - __u8⋆ buffer2, - size_t buffer2_length, - __u16 pid); - int (⋆descramble_section_payload) (struct dmx_demux_s⋆ demux, - __u8⋆ buffer1, - size_t buffer1_length, - __u8⋆ buffer2, size_t buffer2_length, - __u16 pid); - int (⋆add_frontend) (struct dmx_demux_s⋆ demux, - dmx_frontend_t⋆ frontend); - int (⋆remove_frontend) (struct dmx_demux_s⋆ demux, - dmx_frontend_t⋆ frontend); - struct list_head⋆ (⋆get_frontends) (struct dmx_demux_s⋆ demux); - int (⋆connect_frontend) (struct dmx_demux_s⋆ demux, - dmx_frontend_t⋆ frontend); - int (⋆disconnect_frontend) (struct dmx_demux_s⋆ demux); - - - /⋆ added because js cannot keep track of these himself ⋆/ - int (⋆get_pes_pids) (struct dmx_demux_s⋆ demux, __u16 ⋆pids); - }; - typedef struct dmx_demux_s dmx_demux_t; - - -
-
-Demux directory - - /⋆ - ⋆ DMX_DIR_ENTRY(): Casts elements in the list of registered - ⋆ demuxes from the generic type struct list_head⋆ to the type dmx_demux_t - ⋆. - ⋆/ - - #define DMX_DIR_ENTRY(list) list_entry(list, dmx_demux_t, reg_list) - - int dmx_register_demux (dmx_demux_t⋆ demux); - int dmx_unregister_demux (dmx_demux_t⋆ demux); - struct list_head⋆ dmx_get_demuxes (void); - -
-
-Demux Directory API -The demux directory is a Linux kernel-wide facility for registering and accessing the -MPEG-2 TS demuxes in the system. Run-time registering and unregistering of demux drivers -is possible using this API. - -All demux drivers in the directory implement the abstract interface dmx_demux_t. - - -
dmx_register_demux() -DESCRIPTION - - -This function makes a demux driver interface available to the Linux kernel. It is - usually called by the init_module() function of the kernel module that contains - the demux driver. The caller of this function is responsible for allocating - dynamic or static memory for the demux structure and for initializing its fields - before calling this function. The memory allocated for the demux structure - must not be freed before calling dmx_unregister_demux(), - - -SYNOPSIS - - -int dmx_register_demux ( dmx_demux_t ⋆demux ) - - -PARAMETERS - - -dmx_demux_t* - demux - -Pointer to the demux structure. - - -RETURNS - - -0 - -The function was completed without errors. - - --EEXIST - -A demux with the same value of the id field already stored - in the directory. - - --ENOSPC - -No space left in the directory. - - - -
dmx_unregister_demux() -DESCRIPTION - - -This function is called to indicate that the given demux interface is no - longer available. The caller of this function is responsible for freeing the - memory of the demux structure, if it was dynamically allocated before calling - dmx_register_demux(). The cleanup_module() function of the kernel module - that contains the demux driver should call this function. Note that this function - fails if the demux is currently in use, i.e., release_demux() has not been called - for the interface. - - -SYNOPSIS - - -int dmx_unregister_demux ( dmx_demux_t ⋆demux ) - - -PARAMETERS - - -dmx_demux_t* - demux - -Pointer to the demux structure which is to be - unregistered. - - -RETURNS - - -0 - -The function was completed without errors. - - -ENODEV - -The specified demux is not registered in the demux - directory. - - -EBUSY - -The specified demux is currently in use. - - - -
dmx_get_demuxes() -DESCRIPTION - - -Provides the caller with the list of registered demux interfaces, using the - standard list structure defined in the include file linux/list.h. The include file - demux.h defines the macro DMX_DIR_ENTRY() for converting an element of - the generic type struct list_head* to the type dmx_demux_t*. The caller must - not free the memory of any of the elements obtained via this function call. - - -SYNOPSIS - - -struct list_head ⋆dmx_get_demuxes () - - -PARAMETERS - - -none - - -RETURNS - - -struct list_head * - -A list of demux interfaces, or NULL in the case of an - empty list. - - -
-
-Demux API -The demux API should be implemented for each demux in the system. It is used to select -the TS source of a demux and to manage the demux resources. When the demux -client allocates a resource via the demux API, it receives a pointer to the API of that -resource. - -Each demux receives its TS input from a DVB front-end or from memory, as set via the -demux API. In a system with more than one front-end, the API can be used to select one of -the DVB front-ends as a TS source for a demux, unless this is fixed in the HW platform. The -demux API only controls front-ends regarding their connections with demuxes; the APIs -used to set the other front-end parameters, such as tuning, are not defined in this -document. - -The functions that implement the abstract interface demux should be defined static or -module private and registered to the Demux Directory for external access. It is not necessary -to implement every function in the demux_t struct, however (for example, a demux interface -might support Section filtering, but not TS or PES filtering). The API client is expected to -check the value of any function pointer before calling the function: the value of NULL means -“function not available”. - -Whenever the functions of the demux API modify shared data, the possibilities of lost -update and race condition problems should be addressed, e.g. by protecting parts of code with -mutexes. This is especially important on multi-processor hosts. - -Note that functions called from a bottom half context must not sleep, at least in the 2.2.x -kernels. Even a simple memory allocation can result in a kernel thread being put to sleep if -swapping is needed. For example, the Linux kernel calls the functions of a network device -interface from a bottom half context. Thus, if a demux API function is called from network -device code, the function must not sleep. - - - -
-open() -DESCRIPTION - - -This function reserves the demux for use by the caller and, if necessary, - initializes the demux. When the demux is no longer needed, the function close() - should be called. It should be possible for multiple clients to access the demux - at the same time. Thus, the function implementation should increment the - demux usage count when open() is called and decrement it when close() is - called. - - -SYNOPSIS - - -int open ( demux_t⋆ demux ); - - -PARAMETERS - - -demux_t* demux - -Pointer to the demux API and instance data. - - -RETURNS - - -0 - -The function was completed without errors. - - --EUSERS - -Maximum usage count reached. - - --EINVAL - -Bad parameter. - - - -
-
-close() -DESCRIPTION - - -This function reserves the demux for use by the caller and, if necessary, - initializes the demux. When the demux is no longer needed, the function close() - should be called. It should be possible for multiple clients to access the demux - at the same time. Thus, the function implementation should increment the - demux usage count when open() is called and decrement it when close() is - called. - - -SYNOPSIS - - -int close(demux_t⋆ demux); - - -PARAMETERS - - -demux_t* demux - -Pointer to the demux API and instance data. - - -RETURNS - - -0 - -The function was completed without errors. - - --ENODEV - -The demux was not in use. - - --EINVAL - -Bad parameter. - - - -
-
-write() -DESCRIPTION - - -This function provides the demux driver with a memory buffer containing TS - packets. Instead of receiving TS packets from the DVB front-end, the demux - driver software will read packets from memory. Any clients of this demux - with active TS, PES or Section filters will receive filtered data via the Demux - callback API (see 0). The function returns when all the data in the buffer has - been consumed by the demux. Demux hardware typically cannot read TS from - memory. If this is the case, memory-based filtering has to be implemented - entirely in software. - - -SYNOPSIS - - -int write(demux_t⋆ demux, const char⋆ buf, size_t - count); - - -PARAMETERS - - -demux_t* demux - -Pointer to the demux API and instance data. - - -const char* buf - -Pointer to the TS data in kernel-space memory. - - -size_t length - -Length of the TS data. - - -RETURNS - - -0 - -The function was completed without errors. - - --ENOSYS - -The command is not implemented. - - --EINVAL - -Bad parameter. - - - -
allocate_ts_feed() -DESCRIPTION - - -Allocates a new TS feed, which is used to filter the TS packets carrying a - certain PID. The TS feed normally corresponds to a hardware PID filter on the - demux chip. - - -SYNOPSIS - - -int allocate_ts_feed(dmx_demux_t⋆ demux, - dmx_ts_feed_t⋆⋆ feed, dmx_ts_cb callback); - - -PARAMETERS - - -demux_t* demux - -Pointer to the demux API and instance data. - - -dmx_ts_feed_t** - feed - -Pointer to the TS feed API and instance data. - - -dmx_ts_cb callback - -Pointer to the callback function for passing received TS - packet - - -RETURNS - - -0 - -The function was completed without errors. - - --EBUSY - -No more TS feeds available. - - --ENOSYS - -The command is not implemented. - - --EINVAL - -Bad parameter. - - - -
release_ts_feed() -DESCRIPTION - - -Releases the resources allocated with allocate_ts_feed(). Any filtering in - progress on the TS feed should be stopped before calling this function. - - -SYNOPSIS - - -int release_ts_feed(dmx_demux_t⋆ demux, - dmx_ts_feed_t⋆ feed); - - -PARAMETERS - - -demux_t* demux - -Pointer to the demux API and instance data. - - -dmx_ts_feed_t* feed - -Pointer to the TS feed API and instance data. - - -RETURNS - - -0 - -The function was completed without errors. - - --EINVAL - -Bad parameter. - - - -
allocate_section_feed() -DESCRIPTION - - -Allocates a new section feed, i.e. a demux resource for filtering and receiving - sections. On platforms with hardware support for section filtering, a section - feed is directly mapped to the demux HW. On other platforms, TS packets are - first PID filtered in hardware and a hardware section filter then emulated in - software. The caller obtains an API pointer of type dmx_section_feed_t as an - out parameter. Using this API the caller can set filtering parameters and start - receiving sections. - - -SYNOPSIS - - -int allocate_section_feed(dmx_demux_t⋆ demux, - dmx_section_feed_t ⋆⋆feed, dmx_section_cb callback); - - -PARAMETERS - - -demux_t *demux - -Pointer to the demux API and instance data. - - -dmx_section_feed_t - **feed - -Pointer to the section feed API and instance data. - - -dmx_section_cb - callback - -Pointer to the callback function for passing received - sections. - - -RETURNS - - -0 - -The function was completed without errors. - - --EBUSY - -No more section feeds available. - - --ENOSYS - -The command is not implemented. - - --EINVAL - -Bad parameter. - - - -
release_section_feed() -DESCRIPTION - - -Releases the resources allocated with allocate_section_feed(), including - allocated filters. Any filtering in progress on the section feed should be stopped - before calling this function. - - -SYNOPSIS - - -int release_section_feed(dmx_demux_t⋆ demux, - dmx_section_feed_t ⋆feed); - - -PARAMETERS - - -demux_t *demux - -Pointer to the demux API and instance data. - - -dmx_section_feed_t - *feed - -Pointer to the section feed API and instance data. - - -RETURNS - - -0 - -The function was completed without errors. - - --EINVAL - -Bad parameter. - - - -
descramble_mac_address() -DESCRIPTION - - -This function runs a descrambling algorithm on the destination MAC - address field of a DVB Datagram Section, replacing the original address - with its un-encrypted version. Otherwise, the description on the function - descramble_section_payload() applies also to this function. - - -SYNOPSIS - - -int descramble_mac_address(dmx_demux_t⋆ demux, __u8 - ⋆buffer1, size_t buffer1_length, __u8 ⋆buffer2, - size_t buffer2_length, __u16 pid); - - -PARAMETERS - - -dmx_demux_t - *demux - -Pointer to the demux API and instance data. - - -__u8 *buffer1 - -Pointer to the first byte of the section. - - -size_t buffer1_length - -Length of the section data, including headers and CRC, - in buffer1. - - -__u8* buffer2 - -Pointer to the tail of the section data, or NULL. The - pointer has a non-NULL value if the section wraps past - the end of a circular buffer. - - -size_t buffer2_length - -Length of the section data, including headers and CRC, - in buffer2. - - -__u16 pid - -The PID on which the section was received. Useful - for obtaining the descrambling key, e.g. from a DVB - Common Access facility. - - -RETURNS - - -0 - -The function was completed without errors. - - --ENOSYS - -No descrambling facility available. - - --EINVAL - -Bad parameter. - - - -
descramble_section_payload() -DESCRIPTION - - -This function runs a descrambling algorithm on the payload of a DVB - Datagram Section, replacing the original payload with its un-encrypted - version. The function will be called from the demux API implementation; - the API client need not call this function directly. Section-level scrambling - algorithms are currently standardized only for DVB-RCC (return channel - over 2-directional cable TV network) systems. For all other DVB networks, - encryption schemes are likely to be proprietary to each data broadcaster. Thus, - it is expected that this function pointer will have the value of NULL (i.e., - function not available) in most demux API implementations. Nevertheless, it - should be possible to use the function pointer as a hook for dynamically adding - a “plug-in” descrambling facility to a demux driver. - - -While this function is not needed with hardware-based section descrambling, - the descramble_section_payload function pointer can be used to override the - default hardware-based descrambling algorithm: if the function pointer has a - non-NULL value, the corresponding function should be used instead of any - descrambling hardware. - - -SYNOPSIS - - -int descramble_section_payload(dmx_demux_t⋆ demux, - __u8 ⋆buffer1, size_t buffer1_length, __u8 ⋆buffer2, - size_t buffer2_length, __u16 pid); - - -PARAMETERS - - -dmx_demux_t - *demux - -Pointer to the demux API and instance data. - - -__u8 *buffer1 - -Pointer to the first byte of the section. - - -size_t buffer1_length - -Length of the section data, including headers and CRC, - in buffer1. - - -__u8 *buffer2 - -Pointer to the tail of the section data, or NULL. The - pointer has a non-NULL value if the section wraps past - the end of a circular buffer. - - -size_t buffer2_length - -Length of the section data, including headers and CRC, - in buffer2. - - -__u16 pid - -The PID on which the section was received. Useful - for obtaining the descrambling key, e.g. from a DVB - Common Access facility. - - -RETURNS - - -0 - -The function was completed without errors. - - --ENOSYS - -No descrambling facility available. - - --EINVAL - -Bad parameter. - - - -
add_frontend() -DESCRIPTION - - -Registers a connectivity between a demux and a front-end, i.e., indicates that - the demux can be connected via a call to connect_frontend() to use the given - front-end as a TS source. The client of this function has to allocate dynamic or - static memory for the frontend structure and initialize its fields before calling - this function. This function is normally called during the driver initialization. - The caller must not free the memory of the frontend struct before successfully - calling remove_frontend(). - - -SYNOPSIS - - -int add_frontend(dmx_demux_t ⋆demux, dmx_frontend_t - ⋆frontend); - - -PARAMETERS - - -dmx_demux_t* - demux - -Pointer to the demux API and instance data. - - -dmx_frontend_t* - frontend - -Pointer to the front-end instance data. - - -RETURNS - - -0 - -The function was completed without errors. - - --EEXIST - -A front-end with the same value of the id field already - registered. - - --EINUSE - -The demux is in use. - - --ENOMEM - -No more front-ends can be added. - - --EINVAL - -Bad parameter. - - - -
remove_frontend() -DESCRIPTION - - -Indicates that the given front-end, registered by a call to add_frontend(), can - no longer be connected as a TS source by this demux. The function should be - called when a front-end driver or a demux driver is removed from the system. - If the front-end is in use, the function fails with the return value of -EBUSY. - After successfully calling this function, the caller can free the memory of - the frontend struct if it was dynamically allocated before the add_frontend() - operation. - - -SYNOPSIS - - -int remove_frontend(dmx_demux_t⋆ demux, - dmx_frontend_t⋆ frontend); - - -PARAMETERS - - -dmx_demux_t* - demux - -Pointer to the demux API and instance data. - - -dmx_frontend_t* - frontend - -Pointer to the front-end instance data. - - -RETURNS - - -0 - -The function was completed without errors. - - --EINVAL - -Bad parameter. - - --EBUSY - -The front-end is in use, i.e. a call to connect_frontend() - has not been followed by a call to disconnect_frontend(). - - - -
get_frontends() -DESCRIPTION - - -Provides the APIs of the front-ends that have been registered for this demux. - Any of the front-ends obtained with this call can be used as a parameter for - connect_frontend(). - - -The include file demux.h contains the macro DMX_FE_ENTRY() for - converting an element of the generic type struct list_head* to the type - dmx_frontend_t*. The caller must not free the memory of any of the elements - obtained via this function call. - - -SYNOPSIS - - -struct list_head⋆ get_frontends(dmx_demux_t⋆ demux); - - -PARAMETERS - - -dmx_demux_t* - demux - -Pointer to the demux API and instance data. - - -RETURNS - - -dmx_demux_t* - -A list of front-end interfaces, or NULL in the case of an - empty list. - - - -
connect_frontend() -DESCRIPTION - - -Connects the TS output of the front-end to the input of the demux. A demux - can only be connected to a front-end registered to the demux with the function - add_frontend(). - - -It may or may not be possible to connect multiple demuxes to the same - front-end, depending on the capabilities of the HW platform. When not used, - the front-end should be released by calling disconnect_frontend(). - - -SYNOPSIS - - -int connect_frontend(dmx_demux_t⋆ demux, - dmx_frontend_t⋆ frontend); - - -PARAMETERS - - -dmx_demux_t* - demux - -Pointer to the demux API and instance data. - - -dmx_frontend_t* - frontend - -Pointer to the front-end instance data. - - -RETURNS - - -0 - -The function was completed without errors. - - --EINVAL - -Bad parameter. - - --EBUSY - -The front-end is in use. - - - -
disconnect_frontend() -DESCRIPTION - - -Disconnects the demux and a front-end previously connected by a - connect_frontend() call. - - -SYNOPSIS - - -int disconnect_frontend(dmx_demux_t⋆ demux); - - -PARAMETERS - - -dmx_demux_t* - demux - -Pointer to the demux API and instance data. - - -RETURNS - - -0 - -The function was completed without errors. - - --EINVAL - -Bad parameter. - - -
-
-Demux Callback API -This kernel-space API comprises the callback functions that deliver filtered data to the -demux client. Unlike the other APIs, these API functions are provided by the client and called -from the demux code. - -The function pointers of this abstract interface are not packed into a structure as in the -other demux APIs, because the callback functions are registered and used independent -of each other. As an example, it is possible for the API client to provide several -callback functions for receiving TS packets and no callbacks for PES packets or -sections. - -The functions that implement the callback API need not be re-entrant: when a demux -driver calls one of these functions, the driver is not allowed to call the function again before -the original call returns. If a callback is triggered by a hardware interrupt, it is recommended -to use the Linux “bottom half” mechanism or start a tasklet instead of making the callback -function call directly from a hardware interrupt. - - -
dmx_ts_cb() -DESCRIPTION - - -This function, provided by the client of the demux API, is called from the - demux code. The function is only called when filtering on this TS feed has - been enabled using the start_filtering() function. - - -Any TS packets that match the filter settings are copied to a circular buffer. The - filtered TS packets are delivered to the client using this callback function. The - size of the circular buffer is controlled by the circular_buffer_size parameter - of the set() function in the TS Feed API. It is expected that the buffer1 and - buffer2 callback parameters point to addresses within the circular buffer, but - other implementations are also possible. Note that the called party should not - try to free the memory the buffer1 and buffer2 parameters point to. - - -When this function is called, the buffer1 parameter typically points to the - start of the first undelivered TS packet within a circular buffer. The buffer2 - buffer parameter is normally NULL, except when the received TS packets have - crossed the last address of the circular buffer and ”wrapped” to the beginning - of the buffer. In the latter case the buffer1 parameter would contain an address - within the circular buffer, while the buffer2 parameter would contain the first - address of the circular buffer. - - -The number of bytes delivered with this function (i.e. buffer1_length + - buffer2_length) is usually equal to the value of callback_length parameter - given in the set() function, with one exception: if a timeout occurs before - receiving callback_length bytes of TS data, any undelivered packets are - immediately delivered to the client by calling this function. The timeout - duration is controlled by the set() function in the TS Feed API. - - -If a TS packet is received with errors that could not be fixed by the TS-level - forward error correction (FEC), the Transport_error_indicator flag of the TS - packet header should be set. The TS packet should not be discarded, as - the error can possibly be corrected by a higher layer protocol. If the called - party is slow in processing the callback, it is possible that the circular buffer - eventually fills up. If this happens, the demux driver should discard any TS - packets received while the buffer is full. The error should be indicated to the - client on the next callback by setting the success parameter to the value of - DMX_OVERRUN_ERROR. - - -The type of data returned to the callback can be selected by the new - function int (*set_type) (struct dmx_ts_feed_s* feed, int type, dmx_ts_pes_t - pes_type) which is part of the dmx_ts_feed_s struct (also cf. to the - include file ost/demux.h) The type parameter decides if the raw TS packet - (TS_PACKET) or just the payload (TS_PACKET—TS_PAYLOAD_ONLY) - should be returned. If additionally the TS_DECODER bit is set the stream - will also be sent to the hardware MPEG decoder. In this case, the second - flag decides as what kind of data the stream should be interpreted. The - possible choices are one of DMX_TS_PES_AUDIO, DMX_TS_PES_VIDEO, - DMX_TS_PES_TELETEXT, DMX_TS_PES_SUBTITLE, - DMX_TS_PES_PCR, or DMX_TS_PES_OTHER. - - -SYNOPSIS - - -int dmx_ts_cb(__u8⋆ buffer1, size_t buffer1_length, - __u8⋆ buffer2, size_t buffer2_length, dmx_ts_feed_t⋆ - source, dmx_success_t success); - - -PARAMETERS - - -__u8* buffer1 - -Pointer to the start of the filtered TS packets. - - -size_t buffer1_length - -Length of the TS data in buffer1. - - -__u8* buffer2 - -Pointer to the tail of the filtered TS packets, or NULL. - - -size_t buffer2_length - -Length of the TS data in buffer2. - - -dmx_ts_feed_t* - source - -Indicates which TS feed is the source of the callback. - - -dmx_success_t - success - -Indicates if there was an error in TS reception. - - -RETURNS - - -0 - -Continue filtering. - - --1 - -Stop filtering - has the same effect as a call to - stop_filtering() on the TS Feed API. - - - -
dmx_section_cb() -DESCRIPTION - - -This function, provided by the client of the demux API, is called from the - demux code. The function is only called when filtering of sections has been - enabled using the function start_filtering() of the section feed API. When the - demux driver has received a complete section that matches at least one section - filter, the client is notified via this callback function. Normally this function is - called for each received section; however, it is also possible to deliver multiple - sections with one callback, for example when the system load is high. If an - error occurs while receiving a section, this function should be called with - the corresponding error type set in the success field, whether or not there is - data to deliver. The Section Feed implementation should maintain a circular - buffer for received sections. However, this is not necessary if the Section Feed - API is implemented as a client of the TS Feed API, because the TS Feed - implementation then buffers the received data. The size of the circular buffer - can be configured using the set() function in the Section Feed API. If there - is no room in the circular buffer when a new section is received, the section - must be discarded. If this happens, the value of the success parameter should - be DMX_OVERRUN_ERROR on the next callback. - - -SYNOPSIS - - -int dmx_section_cb(__u8⋆ buffer1, size_t - buffer1_length, __u8⋆ buffer2, size_t - buffer2_length, dmx_section_filter_t⋆ source, - dmx_success_t success); - - -PARAMETERS - - -__u8* buffer1 - -Pointer to the start of the filtered section, e.g. within the - circular buffer of the demux driver. - - -size_t buffer1_length - -Length of the filtered section data in buffer1, including - headers and CRC. - - -__u8* buffer2 - -Pointer to the tail of the filtered section data, or NULL. - Useful to handle the wrapping of a circular buffer. - - -size_t buffer2_length - -Length of the filtered section data in buffer2, including - headers and CRC. - - -dmx_section_filter_t* - filter - -Indicates the filter that triggered the callback. - - -dmx_success_t - success - -Indicates if there was an error in section reception. - - -RETURNS - - -0 - -Continue filtering. - - --1 - -Stop filtering - has the same effect as a call to - stop_filtering() on the Section Feed API. - - -
-
-TS Feed API -A TS feed is typically mapped to a hardware PID filter on the demux chip. -Using this API, the client can set the filtering properties to start/stop filtering TS -packets on a particular TS feed. The API is defined as an abstract interface of the type -dmx_ts_feed_t. - -The functions that implement the interface should be defined static or module private. The -client can get the handle of a TS feed API by calling the function allocate_ts_feed() in the -demux API. - - -
set() -DESCRIPTION - - -This function sets the parameters of a TS feed. Any filtering in progress on the - TS feed must be stopped before calling this function. - - -SYNOPSIS - - -int set ( dmx_ts_feed_t⋆ feed, __u16 pid, size_t - callback_length, size_t circular_buffer_size, int - descramble, struct timespec timeout); - - -PARAMETERS - - -dmx_ts_feed_t* feed - -Pointer to the TS feed API and instance data. - - -__u16 pid - -PID value to filter. Only the TS packets carrying the - specified PID will be passed to the API client. - - -size_t - callback_length - -Number of bytes to deliver with each call to the - dmx_ts_cb() callback function. The value of this - parameter should be a multiple of 188. - - -size_t - circular_buffer_size - -Size of the circular buffer for the filtered TS packets. - - -int descramble - -If non-zero, descramble the filtered TS packets. - - -struct timespec - timeout - -Maximum time to wait before delivering received TS - packets to the client. - - -RETURNS - - -0 - -The function was completed without errors. - - --ENOMEM - -Not enough memory for the requested buffer size. - - --ENOSYS - -No descrambling facility available for TS. - - --EINVAL - -Bad parameter. - - - -
start_filtering() -DESCRIPTION - - -Starts filtering TS packets on this TS feed, according to its settings. The PID - value to filter can be set by the API client. All matching TS packets are - delivered asynchronously to the client, using the callback function registered - with allocate_ts_feed(). - - -SYNOPSIS - - -int start_filtering(dmx_ts_feed_t⋆ feed); - - -PARAMETERS - - -dmx_ts_feed_t* feed - -Pointer to the TS feed API and instance data. - - -RETURNS - - -0 - -The function was completed without errors. - - --EINVAL - -Bad parameter. - - - -
stop_filtering() -DESCRIPTION - - -Stops filtering TS packets on this TS feed. - - -SYNOPSIS - - -int stop_filtering(dmx_ts_feed_t⋆ feed); - - -PARAMETERS - - -dmx_ts_feed_t* feed - -Pointer to the TS feed API and instance data. - - -RETURNS - - -0 - -The function was completed without errors. - - --EINVAL - -Bad parameter. - - -
-
-Section Feed API -A section feed is a resource consisting of a PID filter and a set of section filters. Using this -API, the client can set the properties of a section feed and to start/stop filtering. The API is -defined as an abstract interface of the type dmx_section_feed_t. The functions that implement -the interface should be defined static or module private. The client can get the handle of -a section feed API by calling the function allocate_section_feed() in the demux -API. - -On demux platforms that provide section filtering in hardware, the Section Feed API -implementation provides a software wrapper for the demux hardware. Other platforms may -support only PID filtering in hardware, requiring that TS packets are converted to sections in -software. In the latter case the Section Feed API implementation can be a client of the TS -Feed API. - - -
-
-set() -DESCRIPTION - - -This function sets the parameters of a section feed. Any filtering in progress on - the section feed must be stopped before calling this function. If descrambling - is enabled, the payload_scrambling_control and address_scrambling_control - fields of received DVB datagram sections should be observed. If either one is - non-zero, the section should be descrambled either in hardware or using the - functions descramble_mac_address() and descramble_section_payload() of the - demux API. Note that according to the MPEG-2 Systems specification, only - the payloads of private sections can be scrambled while the rest of the section - data must be sent in the clear. - - -SYNOPSIS - - -int set(dmx_section_feed_t⋆ feed, __u16 pid, size_t - circular_buffer_size, int descramble, int - check_crc); - - -PARAMETERS - - -dmx_section_feed_t* - feed - -Pointer to the section feed API and instance data. - - -__u16 pid - -PID value to filter; only the TS packets carrying the - specified PID will be accepted. - - -size_t - circular_buffer_size - -Size of the circular buffer for filtered sections. - - -int descramble - -If non-zero, descramble any sections that are scrambled. - - -int check_crc - -If non-zero, check the CRC values of filtered sections. - - -RETURNS - - -0 - -The function was completed without errors. - - --ENOMEM - -Not enough memory for the requested buffer size. - - --ENOSYS - -No descrambling facility available for sections. - - --EINVAL - -Bad parameters. - - - -
allocate_filter() -DESCRIPTION - - -This function is used to allocate a section filter on the demux. It should only be - called when no filtering is in progress on this section feed. If a filter cannot be - allocated, the function fails with -ENOSPC. See in section ?? for the format of - the section filter. - - -The bitfields filter_mask and filter_value should only be modified when no - filtering is in progress on this section feed. filter_mask controls which bits of - filter_value are compared with the section headers/payload. On a binary value - of 1 in filter_mask, the corresponding bits are compared. The filter only accepts - sections that are equal to filter_value in all the tested bit positions. Any changes - to the values of filter_mask and filter_value are guaranteed to take effect only - when the start_filtering() function is called next time. The parent pointer in - the struct is initialized by the API implementation to the value of the feed - parameter. The priv pointer is not used by the API implementation, and can - thus be freely utilized by the caller of this function. Any data pointed to by the - priv pointer is available to the recipient of the dmx_section_cb() function call. - - -While the maximum section filter length (DMX_MAX_FILTER_SIZE) is - currently set at 16 bytes, hardware filters of that size are not available on all - platforms. Therefore, section filtering will often take place first in hardware, - followed by filtering in software for the header bytes that were not covered - by a hardware filter. The filter_mask field can be checked to determine how - many bytes of the section filter are actually used, and if the hardware filter will - suffice. Additionally, software-only section filters can optionally be allocated - to clients when all hardware section filters are in use. Note that on most demux - hardware it is not possible to filter on the section_length field of the section - header – thus this field is ignored, even though it is included in filter_value and - filter_mask fields. - - -SYNOPSIS - - -int allocate_filter(dmx_section_feed_t⋆ feed, - dmx_section_filter_t⋆⋆ filter); - - -PARAMETERS - - -dmx_section_feed_t* - feed - -Pointer to the section feed API and instance data. - - -dmx_section_filter_t** - filter - -Pointer to the allocated filter. - - -RETURNS - - -0 - -The function was completed without errors. - - --ENOSPC - -No filters of given type and length available. - - --EINVAL - -Bad parameters. - - - -
release_filter() -DESCRIPTION - - -This function releases all the resources of a previously allocated section filter. - The function should not be called while filtering is in progress on this section - feed. After calling this function, the caller should not try to dereference the - filter pointer. - - -SYNOPSIS - - -int release_filter ( dmx_section_feed_t⋆ feed, - dmx_section_filter_t⋆ filter); - - -PARAMETERS - - -dmx_section_feed_t* - feed - -Pointer to the section feed API and instance data. - - -dmx_section_filter_t* - filter - -I/O Pointer to the instance data of a section filter. - - -RETURNS - - -0 - -The function was completed without errors. - - --ENODEV - -No such filter allocated. - - --EINVAL - -Bad parameter. - - - -
start_filtering() -DESCRIPTION - - -Starts filtering sections on this section feed, according to its settings. Sections - are first filtered based on their PID and then matched with the section - filters allocated for this feed. If the section matches the PID filter and - at least one section filter, it is delivered to the API client. The section - is delivered asynchronously using the callback function registered with - allocate_section_feed(). - - -SYNOPSIS - - -int start_filtering ( dmx_section_feed_t⋆ feed ); - - -PARAMETERS - - -dmx_section_feed_t* - feed - -Pointer to the section feed API and instance data. - - -RETURNS - - -0 - -The function was completed without errors. - - --EINVAL - -Bad parameter. - - - -
stop_filtering() -DESCRIPTION - - -Stops filtering sections on this section feed. Note that any changes to the - filtering parameters (filter_value, filter_mask, etc.) should only be made when - filtering is stopped. - - -SYNOPSIS - - -int stop_filtering ( dmx_section_feed_t⋆ feed ); - - -PARAMETERS - - -dmx_section_feed_t* - feed - -Pointer to the section feed API and instance data. - - -RETURNS - - -0 - -The function was completed without errors. - - --EINVAL - -Bad parameter. - - - -
diff --git a/Documentation/DocBook/media/v4l/biblio.xml b/Documentation/DocBook/media/v4l/biblio.xml index fdee6b3f3..9beb30f00 100644 --- a/Documentation/DocBook/media/v4l/biblio.xml +++ b/Documentation/DocBook/media/v4l/biblio.xml @@ -177,6 +177,24 @@ Signal - NTSC for Studio Applications" 1125-Line High-Definition Production" + + SMPTE RP 431-2 + + Society of Motion Picture and Television Engineers +(http://www.smpte.org) + + SMPTE RP 431-2:2011 "D-Cinema Quality - Reference Projector and Environment" + + + + SMPTE ST 2084 + + Society of Motion Picture and Television Engineers +(http://www.smpte.org) + + SMPTE ST 2084:2014 "High Dynamic Range Electro-Optical Transfer Function of Master Reference Displays" + + sRGB diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index a0aef85d3..5701a08ed 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2591,6 +2591,26 @@ and &v4l2-mbus-framefmt;. +
+ V4L2 in Linux 4.4 + + + Renamed V4L2_TUNER_ADC to +V4L2_TUNER_SDR. The use of +V4L2_TUNER_ADC is deprecated now. + + + + Added V4L2_CID_RF_TUNER_RF_GAIN +RF Tuner control. + + + Added transmitter support for Software Defined Radio (SDR) +Interface. + + +
+
Relation of V4L2 to other Linux multimedia APIs diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 33aece541..f13a42909 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -5417,6 +5417,18 @@ set. Unit is in Hz. The range and step are driver-specific. Enables/disables IF automatic gain control (AGC) + + V4L2_CID_RF_TUNER_RF_GAIN  + integer + + + The RF amplifier is the very first +amplifier on the receiver signal path, just right after the antenna input. +The difference between the LNA gain and the RF gain in this document is that +the LNA gain is integrated in the tuner chip while the RF gain is a separate +chip. There may be both RF and LNA gain controls in the same device. +The range and step are driver-specific. + V4L2_CID_RF_TUNER_LNA_GAIN  integer @@ -5425,6 +5437,8 @@ set. Unit is in Hz. The range and step are driver-specific. LNA (low noise amplifier) gain is first gain stage on the RF tuner signal path. It is located very close to tuner antenna input. Used when V4L2_CID_RF_TUNER_LNA_GAIN_AUTO is not set. +See V4L2_CID_RF_TUNER_RF_GAIN to understand how RF gain +and LNA gain differs from the each others. The range and step are driver-specific. diff --git a/Documentation/DocBook/media/v4l/dev-sdr.xml b/Documentation/DocBook/media/v4l/dev-sdr.xml index f8903568a..a659771f7 100644 --- a/Documentation/DocBook/media/v4l/dev-sdr.xml +++ b/Documentation/DocBook/media/v4l/dev-sdr.xml @@ -28,6 +28,16 @@ Devices supporting the SDR receiver interface set the capabilities field of &v4l2-capability; returned by the &VIDIOC-QUERYCAP; ioctl. That flag means the device has an Analog to Digital Converter (ADC), which is a mandatory element for the SDR receiver. + + +Devices supporting the SDR transmitter interface set the +V4L2_CAP_SDR_OUTPUT and +V4L2_CAP_MODULATOR flag in the +capabilities field of &v4l2-capability; +returned by the &VIDIOC-QUERYCAP; ioctl. That flag means the device has an +Digital to Analog Converter (DAC), which is a mandatory element for the SDR transmitter. + + At least one of the read/write, streaming or asynchronous I/O methods must be supported. @@ -39,15 +49,16 @@ be supported. SDR devices can support controls, and must support the tuner ioctls. Tuner ioctls are used -for setting the ADC sampling rate (sampling frequency) and the possible RF tuner -frequency. +for setting the ADC/DAC sampling rate (sampling frequency) and the possible +radio frequency (RF). -The V4L2_TUNER_ADC tuner type is used for ADC tuners, and -the V4L2_TUNER_RF tuner type is used for RF tuners. The -tuner index of the RF tuner (if any) must always follow the ADC tuner index. -Normally the ADC tuner is #0 and the RF tuner is #1. +The V4L2_TUNER_SDR tuner type is used for setting SDR +device ADC/DAC frequency, and the V4L2_TUNER_RF +tuner type is used for setting radio frequency. +The tuner index of the RF tuner (if any) must always follow the SDR tuner index. +Normally the SDR tuner is #0 and the RF tuner is #1. @@ -59,9 +70,9 @@ The &VIDIOC-S-HW-FREQ-SEEK; ioctl is not supported. Data Format Negotiation -The SDR capture device uses the format ioctls to -select the capture format. Both the sampling resolution and the data streaming -format are bound to that selectable format. In addition to the basic +The SDR device uses the format ioctls to +select the capture and output format. Both the sampling resolution and the data +streaming format are bound to that selectable format. In addition to the basic format ioctls, the &VIDIOC-ENUM-FMT; ioctl must be supported as well. @@ -69,7 +80,8 @@ must be supported as well. To use the format ioctls applications set the type field of a &v4l2-format; to -V4L2_BUF_TYPE_SDR_CAPTURE and use the &v4l2-sdr-format; +V4L2_BUF_TYPE_SDR_CAPTURE or +V4L2_BUF_TYPE_SDR_OUTPUT and use the &v4l2-sdr-format; sdr member of the fmt union as needed per the desired operation. Currently there is two fields, pixelformat and diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 7bbc2a489..da654031e 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -1006,8 +1006,14 @@ must set this to 0. V4L2_BUF_TYPE_SDR_CAPTURE 11 - Buffer for Software Defined Radio (SDR), see . + Buffer for Software Defined Radio (SDR) capture stream, see + . + + + V4L2_BUF_TYPE_SDR_OUTPUT + 12 + Buffer for Software Defined Radio (SDR) output stream, see + . diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml index 965ea9167..d871245d2 100644 --- a/Documentation/DocBook/media/v4l/pixfmt.xml +++ b/Documentation/DocBook/media/v4l/pixfmt.xml @@ -539,6 +539,10 @@ colorspaces except for BT.2020 which uses limited range R'G'B' quantization.V4L2_COLORSPACE_BT2020 See . + + V4L2_COLORSPACE_DCI_P3 + See . + V4L2_COLORSPACE_SMPTE240M See . @@ -601,6 +605,14 @@ colorspaces except for BT.2020 which uses limited range R'G'B' quantization.V4L2_XFER_FUNC_NONE Do not use a transfer function (i.e. use linear RGB values). + + V4L2_XFER_FUNC_DCI_P3 + Use the DCI-P3 transfer function. + + + V4L2_XFER_FUNC_SMPTE2084 + Use the SMPTE 2084 transfer function. + @@ -1154,6 +1166,68 @@ clamped to the range [-0.5…0.5]. The Y'CbCr quantization is limited range clamped to the range [-0.5…0.5]. The Yc'CbcCrc quantization is limited range.
+
+ Colorspace DCI-P3 (<constant>V4L2_COLORSPACE_DCI_P3</constant>) + The standard defines the colorspace used by cinema +projectors that use the DCI-P3 colorspace. +The default transfer function is V4L2_XFER_FUNC_DCI_P3. +The default Y'CbCr encoding is V4L2_YCBCR_ENC_709. Note that this +colorspace does not specify a Y'CbCr encoding since it is not meant to be encoded +to Y'CbCr. So this default Y'CbCr encoding was picked because it is the HDTV +encoding. The default Y'CbCr quantization is limited range. The chromaticities of +the primary colors and the white reference are: + + DCI-P3 Chromaticities + + &cs-str; + + + Color + x + y + + + + + Red + 0.6800 + 0.3200 + + + Green + 0.2650 + 0.6900 + + + Blue + 0.1500 + 0.0600 + + + White Reference + 0.3140 + 0.3510 + + + +
+ + + Transfer function: + + L' = L1/2.6 + + + + Inverse Transfer function: + + L = L'2.6 + + + + Y'CbCr encoding is not specified. V4L2 defaults to Rec. 709. +
+
Colorspace SMPTE 240M (<constant>V4L2_COLORSPACE_SMPTE240M</constant>) The standard was an interim standard used during @@ -1402,6 +1476,41 @@ and V4L2_QUANTIZATION_FULL_RANGE.
+
+ Detailed Transfer Function Descriptions +
+ Transfer Function SMPTE 2084 (<constant>V4L2_XFER_FUNC_SMPTE2084</constant>) + The standard defines the transfer function used by +High Dynamic Range content. + + + Constants: + + m1 = (2610 / 4096) / 4 + m2 = (2523 / 4096) * 128 + c1 = 3424 / 4096 + c2 = (2413 / 4096) * 32 + c3 = (2392 / 4096) * 32 + + + + Transfer function: + + L' = ((c1 + c2 * Lm1) / (1 + c3 * Lm1))m2 + + + + + + Inverse Transfer function: + + L = (max(L'1/m2 - c1, 0) / (c2 - c3 * L'1/m2))1/m1 + + + +
+
+
Indexed Format @@ -1623,7 +1732,7 @@ extended control V4L2_CID_MPEG_STREAM_TYPE, see
SDR Formats - These formats are used for SDR Capture + These formats are used for SDR interface only. &sub-sdr-cu08; diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index e98caa1c3..7e6164335 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -151,9 +151,18 @@ Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab, structs, ioctls) must be noted in more detail in the history chapter (compat.xml), along with the possible impact on existing drivers and applications. --> + + 4.4 + 2015-05-26 + ap + Renamed V4L2_TUNER_ADC to V4L2_TUNER_SDR. +Added V4L2_CID_RF_TUNER_RF_GAIN control. +Added transmitter support for Software Defined Radio (SDR) Interface. + + - 3.21 + 4.1 2015-02-13 mcc Fix documentation for media controller device nodes and add support for DVB device nodes. @@ -557,7 +566,7 @@ and discussions on the V4L mailing list. Video for Linux Two API Specification - Revision 3.19 + Revision 4.4 &sub-common; diff --git a/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml b/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml index fc1d4625a..70a4a08e9 100644 --- a/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml +++ b/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml @@ -130,7 +130,7 @@ encoding will continue until the end of the current Group Of Pictures, otherwise encoding will stop immediately. When the encoder is already stopped, this command does nothing. mem2mem encoders will send a V4L2_EVENT_EOS event -when the last frame has been decoded and all frames are ready to be dequeued and +when the last frame has been encoded and all frames are ready to be dequeued and will set the V4L2_BUF_FLAG_LAST buffer flag on the last buffer of the capture queue to indicate there will be no new buffers produced to dequeue. This buffer may be empty, indicated by the driver setting the diff --git a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml index c5bdbfcc4..842536aae 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml @@ -197,6 +197,13 @@ Valid if this control is of type V4L2_CTRL_TYPE_U8. p_u16 A pointer to a matrix control of unsigned 16-bit values. Valid if this control is of type V4L2_CTRL_TYPE_U16. + + + + __u32 * + p_u32 + A pointer to a matrix control of unsigned 32-bit values. +Valid if this control is of type V4L2_CTRL_TYPE_U32. diff --git a/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml b/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml index 4fe19a7a9..ffcb44825 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml @@ -175,7 +175,7 @@ capture and output devices. &v4l2-sdr-format; sdr Definition of a data format, see -, used by SDR capture devices. +, used by SDR capture and output devices. diff --git a/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml b/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml index 7068b599a..96e17b344 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml @@ -78,6 +78,12 @@ different audio modulation if the request cannot be satisfied. However this is a write-only ioctl, it does not return the actual audio modulation selected. + SDR specific modulator types are +V4L2_TUNER_SDR and V4L2_TUNER_RF. +For SDR devices txsubchans field must be +initialized to zero. +The term 'modulator' means SDR transmitter in this context. + To change the radio frequency the &VIDIOC-S-FREQUENCY; ioctl is available. @@ -140,7 +146,13 @@ indicator, for example a stereo pilot tone. __u32 - reserved[4] + type + Type of the modulator, see . + + + __u32 + reserved[3] Reserved for future extensions. Drivers and applications must set the array to zero. diff --git a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml index b0d865933..459b7e561 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml @@ -80,6 +80,12 @@ if the requested mode is invalid or unsupported. Since this is a write-only ioctl, it does not return the actually selected audio mode. + SDR specific tuner types are +V4L2_TUNER_SDR and V4L2_TUNER_RF. +For SDR devices audmode field must be +initialized to zero. +The term 'tuner' means SDR receiver in this context. + To change the radio frequency the &VIDIOC-S-FREQUENCY; ioctl is available. @@ -261,6 +267,16 @@ applications must set the array to zero. 2 + + V4L2_TUNER_SDR + 4 + + + + V4L2_TUNER_RF + 5 + + diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index 20fda75a0..cd82148de 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml @@ -306,6 +306,12 @@ modulator programming see 0x00200000 The device supports the &v4l2-pix-format; extended fields. + + + V4L2_CAP_SDR_OUTPUT + 0x00400000 + The device supports the +SDR Output interface. V4L2_CAP_READWRITE diff --git a/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml b/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml index 6ec39c698..55b7582cf 100644 --- a/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml +++ b/Documentation/DocBook/media/v4l/vidioc-queryctrl.xml @@ -101,8 +101,9 @@ prematurely end the enumeration). next supported non-compound control, or EINVAL if there is none. In addition, the V4L2_CTRL_FLAG_NEXT_COMPOUND flag can be specified to enumerate all compound controls (i.e. controls -with type ≥ V4L2_CTRL_COMPOUND_TYPES). Specify both -V4L2_CTRL_FLAG_NEXT_CTRL and +with type ≥ V4L2_CTRL_COMPOUND_TYPES and/or array +control, in other words controls that contain more than one value). +Specify both V4L2_CTRL_FLAG_NEXT_CTRL and V4L2_CTRL_FLAG_NEXT_COMPOUND in order to enumerate all controls, compound or not. Drivers which do not support these flags yet always return EINVAL. @@ -422,7 +423,7 @@ the array to zero. any An integer-valued control ranging from minimum to maximum inclusive. The step value indicates the increment between -values which are actually different on the hardware. +values. V4L2_CTRL_TYPE_BOOLEAN @@ -518,7 +519,7 @@ Older drivers which do not support this feature return an any An unsigned 8-bit valued control ranging from minimum to maximum inclusive. The step value indicates the increment between -values which are actually different on the hardware. +values. @@ -528,7 +529,17 @@ values which are actually different on the hardware. any An unsigned 16-bit valued control ranging from minimum to maximum inclusive. The step value indicates the increment between -values which are actually different on the hardware. +values. + + + + V4L2_CTRL_TYPE_U32 + any + any + any + An unsigned 32-bit valued control ranging from minimum to +maximum inclusive. The step value indicates the increment between +values. diff --git a/Documentation/DocBook/media_api.tmpl b/Documentation/DocBook/media_api.tmpl index f3f5fe5b6..92037033f 100644 --- a/Documentation/DocBook/media_api.tmpl +++ b/Documentation/DocBook/media_api.tmpl @@ -38,7 +38,7 @@ LINUX MEDIA INFRASTRUCTURE API - 2009-2014 + 2009-2015 LinuxTV Developers diff --git a/Documentation/DocBook/writing-an-alsa-driver.tmpl b/Documentation/DocBook/writing-an-alsa-driver.tmpl index 84ef6a901..a27ab9f53 100644 --- a/Documentation/DocBook/writing-an-alsa-driver.tmpl +++ b/Documentation/DocBook/writing-an-alsa-driver.tmpl @@ -2181,10 +2181,6 @@ struct _snd_pcm_runtime { struct snd_pcm_hardware hw; struct snd_pcm_hw_constraints hw_constraints; - /* -- interrupt callbacks -- */ - void (*transfer_ack_begin)(struct snd_pcm_substream *substream); - void (*transfer_ack_end)(struct snd_pcm_substream *substream); - /* -- timer -- */ unsigned int timer_resolution; /* timer resolution */ @@ -2209,9 +2205,8 @@ struct _snd_pcm_runtime { For the operators (callbacks) of each sound driver, most of these records are supposed to be read-only. Only the PCM middle-layer changes / updates them. The exceptions are - the hardware description (hw), interrupt callbacks - (transfer_ack_xxx), DMA buffer information, and the private - data. Besides, if you use the standard buffer allocation + the hardware description (hw) DMA buffer information and the + private data. Besides, if you use the standard buffer allocation method via snd_pcm_lib_malloc_pages(), you don't need to set the DMA buffer information by yourself. @@ -2538,16 +2533,6 @@ struct _snd_pcm_runtime {
-
- Interrupt Callbacks - - The field transfer_ack_begin and - transfer_ack_end are called at - the beginning and at the end of - snd_pcm_period_elapsed(), respectively. - -
-
diff --git a/Documentation/IPMI.txt b/Documentation/IPMI.txt index 31d1d6588..c0d8788e7 100644 --- a/Documentation/IPMI.txt +++ b/Documentation/IPMI.txt @@ -587,7 +587,7 @@ used to control it: modprobe ipmi_watchdog timeout= pretimeout= action= preaction= preop= start_now=x - nowayout=x ifnum_to_use=n + nowayout=x ifnum_to_use=n panic_wdt_timeout= ifnum_to_use specifies which interface the watchdog timer should use. The default is -1, which means to pick the first one registered. @@ -597,7 +597,9 @@ is the amount of seconds before the reset that the pre-timeout panic will occur (if pretimeout is zero, then pretimeout will not be enabled). Note that the pretimeout is the time before the final timeout. So if the timeout is 50 seconds and the pretimeout is 10 seconds, then the pretimeout -will occur in 40 second (10 seconds before the timeout). +will occur in 40 second (10 seconds before the timeout). The panic_wdt_timeout +is the value of timeout which is set on kernel panic, in order to let actions +such as kdump to occur during panic. The action may be "reset", "power_cycle", or "power_off", and specifies what to do when the timer times out, and defaults to @@ -634,6 +636,7 @@ for configuring the watchdog: ipmi_watchdog.preop= ipmi_watchdog.start_now=x ipmi_watchdog.nowayout=x + ipmi_watchdog.panic_wdt_timeout= The options are the same as the module parameter options. diff --git a/Documentation/IRQ-domain.txt b/Documentation/IRQ-domain.txt index 3a8e15cba..8d990bde8 100644 --- a/Documentation/IRQ-domain.txt +++ b/Documentation/IRQ-domain.txt @@ -32,9 +32,9 @@ top of the irq_alloc_desc*() API. An irq_domain to manage mapping is preferred over interrupt controller drivers open coding their own reverse mapping scheme. -irq_domain also implements translation from Device Tree interrupt -specifiers to hwirq numbers, and can be easily extended to support -other IRQ topology data sources. +irq_domain also implements translation from an abstract irq_fwspec +structure to hwirq numbers (Device Tree and ACPI GSI so far), and can +be easily extended to support other IRQ topology data sources. === irq_domain usage === An interrupt controller driver creates and registers an irq_domain by @@ -184,7 +184,7 @@ There are four major interfaces to use hierarchy irq_domain: related resources associated with these interrupts. 3) irq_domain_activate_irq(): activate interrupt controller hardware to deliver the interrupt. -3) irq_domain_deactivate_irq(): deactivate interrupt controller hardware +4) irq_domain_deactivate_irq(): deactivate interrupt controller hardware to stop delivering the interrupt. Following changes are needed to support hierarchy irq_domain. diff --git a/Documentation/RCU/stallwarn.txt b/Documentation/RCU/stallwarn.txt index efb945487..0f7fb4298 100644 --- a/Documentation/RCU/stallwarn.txt +++ b/Documentation/RCU/stallwarn.txt @@ -205,6 +205,13 @@ o For !CONFIG_PREEMPT kernels, a CPU looping anywhere in the behavior, you might need to replace some of the cond_resched() calls with calls to cond_resched_rcu_qs(). +o Booting Linux using a console connection that is too slow to + keep up with the boot-time console-message rate. For example, + a 115Kbaud serial console can be -way- too slow to keep up + with boot-time message rates, and will frequently result in + RCU CPU stall warning messages. Especially if you have added + debug printk()s. + o Anything that prevents RCU's grace-period kthreads from running. This can result in the "All QSes seen" console-log message. This message will include information on when the kthread last diff --git a/Documentation/RCU/torture.txt b/Documentation/RCU/torture.txt index dac02a621..118e7c176 100644 --- a/Documentation/RCU/torture.txt +++ b/Documentation/RCU/torture.txt @@ -166,40 +166,27 @@ test_no_idle_hz Whether or not to test the ability of RCU to operate in torture_type The type of RCU to test, with string values as follows: - "rcu": rcu_read_lock(), rcu_read_unlock() and call_rcu(). - - "rcu_sync": rcu_read_lock(), rcu_read_unlock(), and - synchronize_rcu(). - - "rcu_expedited": rcu_read_lock(), rcu_read_unlock(), and - synchronize_rcu_expedited(). + "rcu": rcu_read_lock(), rcu_read_unlock() and call_rcu(), + along with expedited, synchronous, and polling + variants. "rcu_bh": rcu_read_lock_bh(), rcu_read_unlock_bh(), and - call_rcu_bh(). - - "rcu_bh_sync": rcu_read_lock_bh(), rcu_read_unlock_bh(), - and synchronize_rcu_bh(). + call_rcu_bh(), along with expedited and synchronous + variants. - "rcu_bh_expedited": rcu_read_lock_bh(), rcu_read_unlock_bh(), - and synchronize_rcu_bh_expedited(). + "rcu_busted": This tests an intentionally incorrect version + of RCU in order to help test rcutorture itself. "srcu": srcu_read_lock(), srcu_read_unlock() and - call_srcu(). - - "srcu_sync": srcu_read_lock(), srcu_read_unlock() and - synchronize_srcu(). - - "srcu_expedited": srcu_read_lock(), srcu_read_unlock() and - synchronize_srcu_expedited(). + call_srcu(), along with expedited and + synchronous variants. "sched": preempt_disable(), preempt_enable(), and - call_rcu_sched(). - - "sched_sync": preempt_disable(), preempt_enable(), and - synchronize_sched(). + call_rcu_sched(), along with expedited, + synchronous, and polling variants. - "sched_expedited": preempt_disable(), preempt_enable(), and - synchronize_sched_expedited(). + "tasks": voluntary context switch and call_rcu_tasks(), + along with expedited and synchronous variants. Defaults to "rcu". diff --git a/Documentation/RCU/trace.txt b/Documentation/RCU/trace.txt index 97f17e9de..ec6998b1b 100644 --- a/Documentation/RCU/trace.txt +++ b/Documentation/RCU/trace.txt @@ -56,14 +56,14 @@ rcuboost: The output of "cat rcu/rcu_preempt/rcudata" looks as follows: - 0!c=30455 g=30456 pq=1/0 qp=1 dt=126535/140000000000000/0 df=2002 of=4 ql=0/0 qs=N... b=10 ci=74572 nci=0 co=1131 ca=716 - 1!c=30719 g=30720 pq=1/0 qp=0 dt=132007/140000000000000/0 df=1874 of=10 ql=0/0 qs=N... b=10 ci=123209 nci=0 co=685 ca=982 - 2!c=30150 g=30151 pq=1/1 qp=1 dt=138537/140000000000000/0 df=1707 of=8 ql=0/0 qs=N... b=10 ci=80132 nci=0 co=1328 ca=1458 - 3 c=31249 g=31250 pq=1/1 qp=0 dt=107255/140000000000000/0 df=1749 of=6 ql=0/450 qs=NRW. b=10 ci=151700 nci=0 co=509 ca=622 - 4!c=29502 g=29503 pq=1/0 qp=1 dt=83647/140000000000000/0 df=965 of=5 ql=0/0 qs=N... b=10 ci=65643 nci=0 co=1373 ca=1521 - 5 c=31201 g=31202 pq=1/0 qp=1 dt=70422/0/0 df=535 of=7 ql=0/0 qs=.... b=10 ci=58500 nci=0 co=764 ca=698 - 6!c=30253 g=30254 pq=1/0 qp=1 dt=95363/140000000000000/0 df=780 of=5 ql=0/0 qs=N... b=10 ci=100607 nci=0 co=1414 ca=1353 - 7 c=31178 g=31178 pq=1/0 qp=0 dt=91536/0/0 df=547 of=4 ql=0/0 qs=.... b=10 ci=109819 nci=0 co=1115 ca=969 + 0!c=30455 g=30456 cnq=1/0:1 dt=126535/140000000000000/0 df=2002 of=4 ql=0/0 qs=N... b=10 ci=74572 nci=0 co=1131 ca=716 + 1!c=30719 g=30720 cnq=1/0:0 dt=132007/140000000000000/0 df=1874 of=10 ql=0/0 qs=N... b=10 ci=123209 nci=0 co=685 ca=982 + 2!c=30150 g=30151 cnq=1/1:1 dt=138537/140000000000000/0 df=1707 of=8 ql=0/0 qs=N... b=10 ci=80132 nci=0 co=1328 ca=1458 + 3 c=31249 g=31250 cnq=1/1:0 dt=107255/140000000000000/0 df=1749 of=6 ql=0/450 qs=NRW. b=10 ci=151700 nci=0 co=509 ca=622 + 4!c=29502 g=29503 cnq=1/0:1 dt=83647/140000000000000/0 df=965 of=5 ql=0/0 qs=N... b=10 ci=65643 nci=0 co=1373 ca=1521 + 5 c=31201 g=31202 cnq=1/0:1 dt=70422/0/0 df=535 of=7 ql=0/0 qs=.... b=10 ci=58500 nci=0 co=764 ca=698 + 6!c=30253 g=30254 cnq=1/0:1 dt=95363/140000000000000/0 df=780 of=5 ql=0/0 qs=N... b=10 ci=100607 nci=0 co=1414 ca=1353 + 7 c=31178 g=31178 cnq=1/0:0 dt=91536/0/0 df=547 of=4 ql=0/0 qs=.... b=10 ci=109819 nci=0 co=1115 ca=969 This file has one line per CPU, or eight for this 8-CPU system. The fields are as follows: @@ -188,14 +188,14 @@ o "ca" is the number of RCU callbacks that have been adopted by this Kernels compiled with CONFIG_RCU_BOOST=y display the following from /debug/rcu/rcu_preempt/rcudata: - 0!c=12865 g=12866 pq=1/0 qp=1 dt=83113/140000000000000/0 df=288 of=11 ql=0/0 qs=N... kt=0/O ktl=944 b=10 ci=60709 nci=0 co=748 ca=871 - 1 c=14407 g=14408 pq=1/0 qp=0 dt=100679/140000000000000/0 df=378 of=7 ql=0/119 qs=NRW. kt=0/W ktl=9b6 b=10 ci=109740 nci=0 co=589 ca=485 - 2 c=14407 g=14408 pq=1/0 qp=0 dt=105486/0/0 df=90 of=9 ql=0/89 qs=NRW. kt=0/W ktl=c0c b=10 ci=83113 nci=0 co=533 ca=490 - 3 c=14407 g=14408 pq=1/0 qp=0 dt=107138/0/0 df=142 of=8 ql=0/188 qs=NRW. kt=0/W ktl=b96 b=10 ci=121114 nci=0 co=426 ca=290 - 4 c=14405 g=14406 pq=1/0 qp=1 dt=50238/0/0 df=706 of=7 ql=0/0 qs=.... kt=0/W ktl=812 b=10 ci=34929 nci=0 co=643 ca=114 - 5!c=14168 g=14169 pq=1/0 qp=0 dt=45465/140000000000000/0 df=161 of=11 ql=0/0 qs=N... kt=0/O ktl=b4d b=10 ci=47712 nci=0 co=677 ca=722 - 6 c=14404 g=14405 pq=1/0 qp=0 dt=59454/0/0 df=94 of=6 ql=0/0 qs=.... kt=0/W ktl=e57 b=10 ci=55597 nci=0 co=701 ca=811 - 7 c=14407 g=14408 pq=1/0 qp=1 dt=68850/0/0 df=31 of=8 ql=0/0 qs=.... kt=0/W ktl=14bd b=10 ci=77475 nci=0 co=508 ca=1042 + 0!c=12865 g=12866 cnq=1/0:1 dt=83113/140000000000000/0 df=288 of=11 ql=0/0 qs=N... kt=0/O ktl=944 b=10 ci=60709 nci=0 co=748 ca=871 + 1 c=14407 g=14408 cnq=1/0:0 dt=100679/140000000000000/0 df=378 of=7 ql=0/119 qs=NRW. kt=0/W ktl=9b6 b=10 ci=109740 nci=0 co=589 ca=485 + 2 c=14407 g=14408 cnq=1/0:0 dt=105486/0/0 df=90 of=9 ql=0/89 qs=NRW. kt=0/W ktl=c0c b=10 ci=83113 nci=0 co=533 ca=490 + 3 c=14407 g=14408 cnq=1/0:0 dt=107138/0/0 df=142 of=8 ql=0/188 qs=NRW. kt=0/W ktl=b96 b=10 ci=121114 nci=0 co=426 ca=290 + 4 c=14405 g=14406 cnq=1/0:1 dt=50238/0/0 df=706 of=7 ql=0/0 qs=.... kt=0/W ktl=812 b=10 ci=34929 nci=0 co=643 ca=114 + 5!c=14168 g=14169 cnq=1/0:0 dt=45465/140000000000000/0 df=161 of=11 ql=0/0 qs=N... kt=0/O ktl=b4d b=10 ci=47712 nci=0 co=677 ca=722 + 6 c=14404 g=14405 cnq=1/0:0 dt=59454/0/0 df=94 of=6 ql=0/0 qs=.... kt=0/W ktl=e57 b=10 ci=55597 nci=0 co=701 ca=811 + 7 c=14407 g=14408 cnq=1/0:1 dt=68850/0/0 df=31 of=8 ql=0/0 qs=.... kt=0/W ktl=14bd b=10 ci=77475 nci=0 co=508 ca=1042 This is similar to the output discussed above, but contains the following additional fields: diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt index adc218400..dc49c6712 100644 --- a/Documentation/RCU/whatisRCU.txt +++ b/Documentation/RCU/whatisRCU.txt @@ -364,7 +364,7 @@ uses of RCU may be found in listRCU.txt, arrayRCU.txt, and NMI-RCU.txt. }; DEFINE_SPINLOCK(foo_mutex); - struct foo *gbl_foo; + struct foo __rcu *gbl_foo; /* * Create a new struct foo that is the same as the one currently @@ -386,7 +386,7 @@ uses of RCU may be found in listRCU.txt, arrayRCU.txt, and NMI-RCU.txt. new_fp = kmalloc(sizeof(*new_fp), GFP_KERNEL); spin_lock(&foo_mutex); - old_fp = gbl_foo; + old_fp = rcu_dereference_protected(gbl_foo, lockdep_is_held(&foo_mutex)); *new_fp = *old_fp; new_fp->a = new_a; rcu_assign_pointer(gbl_foo, new_fp); @@ -487,7 +487,7 @@ The foo_update_a() function might then be written as follows: new_fp = kmalloc(sizeof(*new_fp), GFP_KERNEL); spin_lock(&foo_mutex); - old_fp = gbl_foo; + old_fp = rcu_dereference_protected(gbl_foo, lockdep_is_held(&foo_mutex)); *new_fp = *old_fp; new_fp->a = new_a; rcu_assign_pointer(gbl_foo, new_fp); diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index fd89b04d3..d603fa078 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -659,8 +659,8 @@ succinct and descriptive, but that is what a well-written summary should do. The "summary phrase" may be prefixed by tags enclosed in square -brackets: "Subject: [PATCH tag] ". The tags are not -considered part of the summary phrase, but describe how the patch +brackets: "Subject: [PATCH ...] ". The tags are +not considered part of the summary phrase, but describe how the patch should be treated. Common tags might include a version descriptor if the multiple versions of the patch have been sent out in response to comments (i.e., "v1, v2, v3"), or "RFC" to indicate a request for @@ -672,8 +672,8 @@ the patch series. A couple of example Subjects: - Subject: [patch 2/5] ext2: improve scalability of bitmap searching - Subject: [PATCHv2 001/207] x86: fix eflags tracking + Subject: [PATCH 2/5] ext2: improve scalability of bitmap searching + Subject: [PATCH v2 01/27] x86: fix eflags tracking The "from" line must be the very first line in the message body, and has the form: @@ -718,8 +718,21 @@ generates appropriate diffstats by default.) See more details on the proper patch format in the following references. +15) Explicit In-Reply-To headers +-------------------------------- + +It can be helpful to manually add In-Reply-To: headers to a patch +(e.g., when using "git send email") to associate the patch with +previous relevant discussion, e.g. to link a bug fix to the email with +the bug report. However, for a multi-patch series, it is generally +best to avoid using In-Reply-To: to link to older versions of the +series. This way multiple versions of the patch don't become an +unmanageable forest of references in email clients. If a link is +helpful, you can use the https://lkml.kernel.org/ redirector (e.g., in +the cover email text) to link to an earlier version of the patch series. + -15) Sending "git pull" requests +16) Sending "git pull" requests ------------------------------- If you have a series of patches, it may be most convenient to have the diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt index b731b292e..a91ec5af5 100644 --- a/Documentation/acpi/enumeration.txt +++ b/Documentation/acpi/enumeration.txt @@ -347,13 +347,18 @@ For the first case, the MFD drivers do not need to do anything. The resulting child platform device will have its ACPI_COMPANION() set to point to the parent device. -If the ACPI namespace has a device that we can match using an ACPI id, -the id should be set like: +If the ACPI namespace has a device that we can match using an ACPI id or ACPI +adr, the cell should be set like: + + static struct mfd_cell_acpi_match my_subdevice_cell_acpi_match = { + .pnpid = "XYZ0001", + .adr = 0, + }; static struct mfd_cell my_subdevice_cell = { .name = "my_subdevice", /* set the resources relative to the parent */ - .acpi_pnpid = "XYZ0001", + .acpi_match = &my_subdevice_cell_acpi_match, }; The ACPI id "XYZ0001" is then used to lookup an ACPI device directly under diff --git a/Documentation/acpi/i2c-muxes.txt b/Documentation/acpi/i2c-muxes.txt new file mode 100644 index 000000000..9fcc4f0b8 --- /dev/null +++ b/Documentation/acpi/i2c-muxes.txt @@ -0,0 +1,58 @@ +ACPI I2C Muxes +-------------- + +Describing an I2C device hierarchy that includes I2C muxes requires an ACPI +Device () scope per mux channel. + +Consider this topology: + ++------+ +------+ +| SMB1 |-->| MUX0 |--CH00--> i2c client A (0x50) +| | | 0x70 |--CH01--> i2c client B (0x50) ++------+ +------+ + +which corresponds to the following ASL: + +Device (SMB1) +{ + Name (_HID, ...) + Device (MUX0) + { + Name (_HID, ...) + Name (_CRS, ResourceTemplate () { + I2cSerialBus (0x70, ControllerInitiated, I2C_SPEED, + AddressingMode7Bit, "^SMB1", 0x00, + ResourceConsumer,,) + } + + Device (CH00) + { + Name (_ADR, 0) + + Device (CLIA) + { + Name (_HID, ...) + Name (_CRS, ResourceTemplate () { + I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED, + AddressingMode7Bit, "^CH00", 0x00, + ResourceConsumer,,) + } + } + } + + Device (CH01) + { + Name (_ADR, 1) + + Device (CLIB) + { + Name (_HID, ...) + Name (_CRS, ResourceTemplate () { + I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED, + AddressingMode7Bit, "^CH01", 0x00, + ResourceConsumer,,) + } + } + } + } +} diff --git a/Documentation/arm/SA1100/Victor b/Documentation/arm/SA1100/Victor deleted file mode 100644 index 9cff415da..000000000 --- a/Documentation/arm/SA1100/Victor +++ /dev/null @@ -1,16 +0,0 @@ -Victor is known as a "digital talking book player" manufactured by -VisuAide, Inc. to be used by blind people. - -For more information related to Victor, see: - - http://www.humanware.com/en-usa/products - -Of course Victor is using Linux as its main operating system. -The Victor implementation for Linux is maintained by Nicolas Pitre: - - nico@visuaide.com - nico@fluxnic.net - -For any comments, please feel free to contact me through the above -addresses. - diff --git a/Documentation/arm/Samsung/Bootloader-interface.txt b/Documentation/arm/Samsung/Bootloader-interface.txt index df8d4fb85..ed494ac0b 100644 --- a/Documentation/arm/Samsung/Bootloader-interface.txt +++ b/Documentation/arm/Samsung/Bootloader-interface.txt @@ -19,7 +19,7 @@ executing kernel. Address: sysram_ns_base_addr Offset Value Purpose ============================================================================= -0x08 exynos_cpu_resume_ns System suspend +0x08 exynos_cpu_resume_ns, mcpm_entry_point System suspend 0x0c 0x00000bad (Magic cookie) System suspend 0x1c exynos4_secondary_startup Secondary CPU boot 0x1c + 4*cpu exynos4_secondary_startup (Exynos4412) Secondary CPU boot @@ -56,7 +56,8 @@ Offset Value Purpose Address: pmu_base_addr Offset Value Purpose ============================================================================= -0x0908 Non-zero (only Exynos3250) Secondary CPU boot up indicator +0x0908 Non-zero Secondary CPU boot up indicator + on Exynos3250 and Exynos542x 4. Glossary diff --git a/Documentation/arm/keystone/Overview.txt b/Documentation/arm/keystone/Overview.txt index f17bc4c9d..400c0c270 100644 --- a/Documentation/arm/keystone/Overview.txt +++ b/Documentation/arm/keystone/Overview.txt @@ -49,24 +49,6 @@ specified through DTS. Following are the DTS used:- The device tree documentation for the keystone machines are located at Documentation/devicetree/bindings/arm/keystone/keystone.txt -Known issues & workaround -------------------------- - -Some of the device drivers used on keystone are re-used from that from -DaVinci and other TI SoCs. These device drivers may use clock APIs directly. -Some of the keystone specific drivers such as netcp uses run time power -management API instead to enable clock. As this API has limitations on -keystone, following workaround is needed to boot Linux. - - Add 'clk_ignore_unused' to the bootargs env variable in u-boot. Otherwise - clock frameworks will try to disable clocks that are unused and disable - the hardware. This is because netcp related power domain and clock - domains are enabled in u-boot as run time power management API currently - doesn't enable clocks for netcp due to a limitation. This workaround is - expected to be removed in the future when proper API support becomes - available. Until then, this work around is needed. - - Document Author --------------- Murali Karicheri diff --git a/Documentation/arm/keystone/knav-qmss.txt b/Documentation/arm/keystone/knav-qmss.txt new file mode 100644 index 000000000..d119e0236 --- /dev/null +++ b/Documentation/arm/keystone/knav-qmss.txt @@ -0,0 +1,35 @@ +* Texas Instruments Keystone Navigator Queue Management SubSystem driver + +Driver source code path + drivers/soc/ti/knav_qmss.c + drivers/soc/ti/knav_qmss_acc.c + +The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of +the main hardware sub system which forms the backbone of the Keystone +multi-core Navigator. QMSS consist of queue managers, packed-data structure +processors(PDSP), linking RAM, descriptor pools and infrastructure +Packet DMA. +The Queue Manager is a hardware module that is responsible for accelerating +management of the packet queues. Packets are queued/de-queued by writing or +reading descriptor address to a particular memory mapped location. The PDSPs +perform QMSS related functions like accumulation, QoS, or event management. +Linking RAM registers are used to link the descriptors which are stored in +descriptor RAM. Descriptor RAM is configurable as internal or external memory. +The QMSS driver manages the PDSP setups, linking RAM regions, +queue pool management (allocation, push, pop and notify) and descriptor +pool management. + +knav qmss driver provides a set of APIs to drivers to open/close qmss queues, +allocate descriptor pools, map the descriptors, push/pop to queues etc. For +details of the available APIs, please refers to include/linux/soc/ti/knav_qmss.h + +DT documentation is available at +Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt + +Accumulator QMSS queues using PDSP firmware +============================================ +The QMSS PDSP firmware support accumulator channel that can monitor a single +queue or multiple contiguous queues. drivers/soc/ti/knav_qmss_acc.c is the +driver that interface with the accumulator PDSP. This configures +accumulator channels defined in DTS (example in DT documentation) to monitor +1 or 32 queues per channel. /*(DEBLOBBED)*/ diff --git a/Documentation/arm/memory.txt b/Documentation/arm/memory.txt index 4178ebda6..546a39048 100644 --- a/Documentation/arm/memory.txt +++ b/Documentation/arm/memory.txt @@ -54,7 +54,7 @@ VMALLOC_START VMALLOC_END-1 vmalloc() / ioremap() space. located here through iotable_init(). VMALLOC_START is based upon the value of the high_memory variable, and VMALLOC_END - is equal to 0xff000000. + is equal to 0xff800000. PAGE_OFFSET high_memory-1 Kernel direct-mapped RAM region. This maps the platforms RAM, and typically diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README index 5e38e1582..430d279a8 100644 --- a/Documentation/arm/sunxi/README +++ b/Documentation/arm/sunxi/README @@ -25,7 +25,7 @@ SunXi family + Datasheet http://dl.linux-sunxi.org/A10s/A10s%20Datasheet%20-%20v1.20%20%282012-03-27%29.pdf - - Allwinner A13 (sun5i) + - Allwinner A13 / R8 (sun5i) + Datasheet http://dl.linux-sunxi.org/A13/A13%20Datasheet%20-%20v1.12%20%282012-03-29%29.pdf + User Manual diff --git a/Documentation/arm/uefi.txt b/Documentation/arm/uefi.txt index d60030a1b..6543a0ade 100644 --- a/Documentation/arm/uefi.txt +++ b/Documentation/arm/uefi.txt @@ -58,7 +58,3 @@ linux,uefi-mmap-desc-size | 32-bit | Size in bytes of each entry in the UEFI -------------------------------------------------------------------------------- linux,uefi-mmap-desc-ver | 32-bit | Version of the mmap descriptor format. -------------------------------------------------------------------------------- -linux,uefi-stub-kern-ver | string | Copy of linux_banner from build. --------------------------------------------------------------------------------- - -For verbose debug messages, specify 'uefi_debug' on the kernel command line. diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt index 7d9d3c228..701d39d31 100644 --- a/Documentation/arm64/booting.txt +++ b/Documentation/arm64/booting.txt @@ -104,7 +104,12 @@ Header notes: - The flags field (introduced in v3.17) is a little-endian 64-bit field composed as follows: Bit 0: Kernel endianness. 1 if BE, 0 if LE. - Bits 1-63: Reserved. + Bit 1-2: Kernel Page size. + 0 - Unspecified. + 1 - 4K + 2 - 16K + 3 - 64K + Bits 3-63: Reserved. - When image_size is zero, a bootloader should attempt to keep as much memory as possible free for use by the kernel immediately after the @@ -173,13 +178,22 @@ Before jumping into the kernel, the following conditions must be met: the kernel image will be entered must be initialised by software at a higher exception level to prevent execution in an UNKNOWN state. - For systems with a GICv3 interrupt controller: + For systems with a GICv3 interrupt controller to be used in v3 mode: - If EL3 is present: ICC_SRE_EL3.Enable (bit 3) must be initialiased to 0b1. ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b1. - If the kernel is entered at EL1: ICC.SRE_EL2.Enable (bit 3) must be initialised to 0b1 ICC_SRE_EL2.SRE (bit 0) must be initialised to 0b1. + - The DT or ACPI tables must describe a GICv3 interrupt controller. + + For systems with a GICv3 interrupt controller to be used in + compatibility (v2) mode: + - If EL3 is present: + ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b0. + - If the kernel is entered at EL1: + ICC_SRE_EL2.SRE (bit 0) must be initialised to 0b0. + - The DT or ACPI tables must describe a GICv2 interrupt controller. The requirements described above for CPU mode, caches, MMUs, architected timers, coherency and system registers apply to all CPUs. All CPUs must diff --git a/Documentation/atomic_ops.txt b/Documentation/atomic_ops.txt index b19fc34ef..c9d1cacb4 100644 --- a/Documentation/atomic_ops.txt +++ b/Documentation/atomic_ops.txt @@ -542,6 +542,10 @@ The routines xchg() and cmpxchg() must provide the same exact memory-barrier semantics as the atomic and bit operations returning values. +Note: If someone wants to use xchg(), cmpxchg() and their variants, +linux/atomic.h should be included rather than asm/cmpxchg.h, unless +the code is in arch/* and can take care of itself. + Spinlocks and rwlocks have memory barrier expectations as well. The rule to follow is simple: diff --git a/Documentation/block/null_blk.txt b/Documentation/block/null_blk.txt index 2f6c6ff71..d8880ca30 100644 --- a/Documentation/block/null_blk.txt +++ b/Documentation/block/null_blk.txt @@ -70,3 +70,6 @@ use_per_node_hctx=[0/1]: Default: 0 parameter. 1: The multi-queue block layer is instantiated with a hardware dispatch queue for each CPU node in the system. + +use_lightnvm=[0/1]: Default: 0 + Register device with LightNVM. Requires blk-mq to be used. diff --git a/Documentation/block/pr.txt b/Documentation/block/pr.txt new file mode 100644 index 000000000..d3eb1ca65 --- /dev/null +++ b/Documentation/block/pr.txt @@ -0,0 +1,119 @@ + +Block layer support for Persistent Reservations +=============================================== + +The Linux kernel supports a user space interface for simplified +Persistent Reservations which map to block devices that support +these (like SCSI). Persistent Reservations allow restricting +access to block devices to specific initiators in a shared storage +setup. + +This document gives a general overview of the support ioctl commands. +For a more detailed reference please refer the the SCSI Primary +Commands standard, specifically the section on Reservations and the +"PERSISTENT RESERVE IN" and "PERSISTENT RESERVE OUT" commands. + +All implementations are expected to ensure the reservations survive +a power loss and cover all connections in a multi path environment. +These behaviors are optional in SPC but will be automatically applied +by Linux. + + +The following types of reservations are supported: +-------------------------------------------------- + + - PR_WRITE_EXCLUSIVE + + Only the initiator that owns the reservation can write to the + device. Any initiator can read from the device. + + - PR_EXCLUSIVE_ACCESS + + Only the initiator that owns the reservation can access the + device. + + - PR_WRITE_EXCLUSIVE_REG_ONLY + + Only initiators with a registered key can write to the device, + Any initiator can read from the device. + + - PR_EXCLUSIVE_ACCESS_REG_ONLY + + Only initiators with a registered key can access the device. + + - PR_WRITE_EXCLUSIVE_ALL_REGS + + Only initiators with a registered key can write to the device, + Any initiator can read from the device. + All initiators with a registered key are considered reservation + holders. + Please reference the SPC spec on the meaning of a reservation + holder if you want to use this type. + + - PR_EXCLUSIVE_ACCESS_ALL_REGS + + Only initiators with a registered key can access the device. + All initiators with a registered key are considered reservation + holders. + Please reference the SPC spec on the meaning of a reservation + holder if you want to use this type. + + +The following ioctl are supported: +---------------------------------- + +1. IOC_PR_REGISTER + +This ioctl command registers a new reservation if the new_key argument +is non-null. If no existing reservation exists old_key must be zero, +if an existing reservation should be replaced old_key must contain +the old reservation key. + +If the new_key argument is 0 it unregisters the existing reservation passed +in old_key. + + +2. IOC_PR_RESERVE + +This ioctl command reserves the device and thus restricts access for other +devices based on the type argument. The key argument must be the existing +reservation key for the device as acquired by the IOC_PR_REGISTER, +IOC_PR_REGISTER_IGNORE, IOC_PR_PREEMPT or IOC_PR_PREEMPT_ABORT commands. + + +3. IOC_PR_RELEASE + +This ioctl command releases the reservation specified by key and flags +and thus removes any access restriction implied by it. + + +4. IOC_PR_PREEMPT + +This ioctl command releases the existing reservation referred to by +old_key and replaces it with a a new reservation of type for the +reservation key new_key. + + +5. IOC_PR_PREEMPT_ABORT + +This ioctl command works like IOC_PR_PREEMPT except that it also aborts +any outstanding command sent over a connection identified by old_key. + +6. IOC_PR_CLEAR + +This ioctl command unregisters both key and any other reservation key +registered with the device and drops any existing reservation. + + +Flags +----- + +All the ioctls have a flag field. Currently only one flag is supported: + + - PR_FL_IGNORE_KEY + + Ignore the existing reservation key. This is commonly supported for + IOC_PR_REGISTER, and some implementation may support the flag for + IOC_PR_RESERVE. + +For all unknown flags the kernel will return -EOPNOTSUPP. diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt index 62435bb25..5bda5031c 100644 --- a/Documentation/blockdev/zram.txt +++ b/Documentation/blockdev/zram.txt @@ -14,8 +14,43 @@ Statistics for individual zram devices are exported through sysfs nodes at * Usage +There are several ways to configure and manage zram device(-s): +a) using zram and zram_control sysfs attributes +b) using zramctl utility, provided by util-linux (util-linux@vger.kernel.org). + +In this document we will describe only 'manual' zram configuration steps, +IOW, zram and zram_control sysfs attributes. + +In order to get a better idea about zramctl please consult util-linux +documentation, zramctl man-page or `zramctl --help'. Please be informed +that zram maintainers do not develop/maintain util-linux or zramctl, should +you have any questions please contact util-linux@vger.kernel.org + Following shows a typical sequence of steps for using zram. +WARNING +======= +For the sake of simplicity we skip error checking parts in most of the +examples below. However, it is your sole responsibility to handle errors. + +zram sysfs attributes always return negative values in case of errors. +The list of possible return codes: +-EBUSY -- an attempt to modify an attribute that cannot be changed once +the device has been initialised. Please reset device first; +-ENOMEM -- zram was not able to allocate enough memory to fulfil your +needs; +-EINVAL -- invalid input has been provided. + +If you use 'echo', the returned value that is changed by 'echo' utility, +and, in general case, something like: + + echo 3 > /sys/block/zram0/max_comp_streams + if [ $? -ne 0 ]; + handle_error + fi + +should suffice. + 1) Load Module: modprobe zram num_devices=4 This creates 4 devices: /dev/zram{0,1,2,3} @@ -47,7 +82,7 @@ max_comp_streams adjustment. 3) Select compression algorithm Using comp_algorithm device attribute one can see available and - currently selected (shown in square brackets) compression algortithms, + currently selected (shown in square brackets) compression algorithms, change selected compression algorithm (once the device is initialised there is no way to change compression algorithm). @@ -119,7 +154,7 @@ execute 8) Stats: Per-device statistics are exported as various nodes under /sys/block/zram/ -A brief description of exported device attritbutes. For more details please +A brief description of exported device attributes. For more details please read Documentation/ABI/testing/sysfs-block-zram. Name access description @@ -140,8 +175,9 @@ zero_pages RO the number of zero filled pages written to this disk orig_data_size RO uncompressed size of data stored in this disk compr_data_size RO compressed size of data stored in this disk mem_used_total RO the amount of memory allocated for this disk -mem_used_max RW the maximum amount memory zram have consumed to - store compressed data +mem_used_max RW the maximum amount of memory zram have consumed to + store the data (to reset this counter to the actual + current value, write 1 to this attribute) mem_limit RW the maximum amount of memory ZRAM can use to store the compressed data pages_compacted RO the number of pages freed during compaction diff --git a/Documentation/cgroups/blkio-controller.txt b/Documentation/cgroups/blkio-controller.txt index 12686bec3..52fa9f353 100644 --- a/Documentation/cgroups/blkio-controller.txt +++ b/Documentation/cgroups/blkio-controller.txt @@ -59,7 +59,7 @@ cgroups. Here is what you can do. - At macro level, first dd should finish first. To get more precise data, keep on looking at (with the help of script), at blkio.disk_time and blkio.disk_sectors files of both test1 and test2 groups. This will tell how - much disk time (in milli seconds), each group got and how many secotors each + much disk time (in milliseconds), each group got and how many sectors each group dispatched to the disk. We provide fairness in terms of disk time, so ideally io.disk_time of cgroups should be in proportion to the weight. diff --git a/Documentation/cgroups/cgroups.txt b/Documentation/cgroups/cgroups.txt index f935fac1e..c6256ae98 100644 --- a/Documentation/cgroups/cgroups.txt +++ b/Documentation/cgroups/cgroups.txt @@ -637,6 +637,10 @@ void exit(struct task_struct *task) Called during task exit. +void free(struct task_struct *task) + +Called when the task_struct is freed. + void bind(struct cgroup *root) (cgroup_mutex held by caller) diff --git a/Documentation/cgroups/freezer-subsystem.txt b/Documentation/cgroups/freezer-subsystem.txt index c96a72cbb..e831cb2b8 100644 --- a/Documentation/cgroups/freezer-subsystem.txt +++ b/Documentation/cgroups/freezer-subsystem.txt @@ -50,7 +50,7 @@ being frozen. This allows the bash example above and gdb to run as expected. The cgroup freezer is hierarchical. Freezing a cgroup freezes all -tasks beloning to the cgroup and all its descendant cgroups. Each +tasks belonging to the cgroup and all its descendant cgroups. Each cgroup has its own state (self-state) and the state inherited from the parent (parent-state). Iff both states are THAWED, the cgroup is THAWED. diff --git a/Documentation/cgroups/unified-hierarchy.txt b/Documentation/cgroups/unified-hierarchy.txt index e0975c2cf..781b1d475 100644 --- a/Documentation/cgroups/unified-hierarchy.txt +++ b/Documentation/cgroups/unified-hierarchy.txt @@ -107,12 +107,6 @@ root of unified hierarchy can be bound to other hierarchies. This allows mixing unified hierarchy with the traditional multiple hierarchies in a fully backward compatible way. -For development purposes, the following boot parameter makes all -controllers to appear on the unified hierarchy whether supported or -not. - - cgroup__DEVEL__legacy_files_on_dfl - A controller can be moved across hierarchies only after the controller is no longer referenced in its current hierarchy. Because per-cgroup controller states are destroyed asynchronously and controllers may @@ -341,11 +335,11 @@ is riddled with issues. unnecessarily complicated and probably done this way because event delivery itself was expensive. -Unified hierarchy implements an interface file "cgroup.populated" -which can be used to monitor whether the cgroup's subhierarchy has -tasks in it or not. Its value is 0 if there is no task in the cgroup -and its descendants; otherwise, 1. poll and [id]notify events are -triggered when the value changes. +Unified hierarchy implements "populated" field in "cgroup.events" +interface file which can be used to monitor whether the cgroup's +subhierarchy has tasks in it or not. Its value is 0 if there is no +task in the cgroup and its descendants; otherwise, 1. poll and +[id]notify events are triggered when the value changes. This is significantly lighter and simpler and trivially allows delegating management of subhierarchy - subhierarchy monitoring can @@ -374,6 +368,10 @@ supported and the interface files "release_agent" and - The "cgroup.clone_children" file is removed. +- /proc/PID/cgroup keeps reporting the cgroup that a zombie belonged + to before exiting. If the cgroup is removed before the zombie is + reaped, " (deleted)" is appeneded to the path. + 5-3. Controller File Conventions @@ -435,6 +433,11 @@ may be specified in any order and not all pairs have to be specified. the first entry in the file. Specific entries can use "default" as its value to indicate inheritance of the default value. +- For events which are not very high frequency, an interface file + "events" should be created which lists event key value pairs. + Whenever a notifiable event happens, file modified event should be + generated on the file. + 5-4. Per-Controller Changes @@ -491,7 +494,7 @@ may be specified in any order and not all pairs have to be specified. ${R|W}BPS are read/write bytes per second and ${R|W}IOPS are read/write IOs per second. "max" indicates no limit. Writing to the file follows the same format but the individual - settings may be ommitted or specified in any order. + settings may be omitted or specified in any order. This file is available only on non-root cgroups. diff --git a/Documentation/crypto/asymmetric-keys.txt b/Documentation/crypto/asymmetric-keys.txt index b7675904a..8c07e0ea6 100644 --- a/Documentation/crypto/asymmetric-keys.txt +++ b/Documentation/crypto/asymmetric-keys.txt @@ -186,7 +186,7 @@ and looks like the following: const struct public_key_signature *sig); }; -Asymmetric keys point to this with their type_data[0] member. +Asymmetric keys point to this with their payload[asym_subtype] member. The owner and name fields should be set to the owning module and the name of the subtype. Currently, the name is only used for print statements. @@ -269,8 +269,7 @@ mandatory: struct key_preparsed_payload { char *description; - void *type_data[2]; - void *payload; + void *payload[4]; const void *data; size_t datalen; size_t quotalen; @@ -283,16 +282,18 @@ mandatory: not theirs. If the parser is happy with the blob, it should propose a description for - the key and attach it to ->description, ->type_data[0] should be set to - point to the subtype to be used, ->payload should be set to point to the - initialised data for that subtype, ->type_data[1] should point to a hex - fingerprint and quotalen should be updated to indicate how much quota this - key should account for. - - When clearing up, the data attached to ->type_data[1] and ->description - will be kfree()'d and the data attached to ->payload will be passed to the - subtype's ->destroy() method to be disposed of. A module reference for - the subtype pointed to by ->type_data[0] will be put. + the key and attach it to ->description, ->payload[asym_subtype] should be + set to point to the subtype to be used, ->payload[asym_crypto] should be + set to point to the initialised data for that subtype, + ->payload[asym_key_ids] should point to one or more hex fingerprints and + quotalen should be updated to indicate how much quota this key should + account for. + + When clearing up, the data attached to ->payload[asym_key_ids] and + ->description will be kfree()'d and the data attached to + ->payload[asm_crypto] will be passed to the subtype's ->destroy() method + to be disposed of. A module reference for the subtype pointed to by + ->payload[asym_subtype] will be put. If the data format is not recognised, -EBADMSG should be returned. If it diff --git a/Documentation/device-mapper/delay.txt b/Documentation/device-mapper/delay.txt index 15adc5535..a07b5927f 100644 --- a/Documentation/device-mapper/delay.txt +++ b/Documentation/device-mapper/delay.txt @@ -8,6 +8,7 @@ Parameters: [ ] With separate write parameters, the first set is only used for reads. +Offsets are specified in sectors. Delays are specified in milliseconds. Example scripts diff --git a/Documentation/devicetree/bindings/arc/archs-idu-intc.txt b/Documentation/devicetree/bindings/arc/archs-idu-intc.txt deleted file mode 100644 index 0dcb7c7d3..000000000 --- a/Documentation/devicetree/bindings/arc/archs-idu-intc.txt +++ /dev/null @@ -1,46 +0,0 @@ -* ARC-HS Interrupt Distribution Unit - - This optional 2nd level interrupt controller can be used in SMP configurations for - dynamic IRQ routing, load balancing of common/external IRQs towards core intc. - -Properties: - -- compatible: "snps,archs-idu-intc" -- interrupt-controller: This is an interrupt controller. -- interrupt-parent: -- #interrupt-cells: Must be <2>. -- interrupts: <...> specifies the upstream core irqs - - First cell specifies the "common" IRQ from peripheral to IDU - Second cell specifies the irq distribution mode to cores - 0=Round Robin; 1=cpu0, 2=cpu1, 4=cpu2, 8=cpu3 - - intc accessed via the special ARC AUX register interface, hence "reg" property - is not specified. - -Example: - core_intc: core-interrupt-controller { - compatible = "snps,archs-intc"; - interrupt-controller; - #interrupt-cells = <1>; - }; - - idu_intc: idu-interrupt-controller { - compatible = "snps,archs-idu-intc"; - interrupt-controller; - interrupt-parent = <&core_intc>; - - /* - * - * distribution: 0=RR; 1=cpu0, 2=cpu1, 4=cpu2, 8=cpu3 - */ - #interrupt-cells = <2>; - - /* upstream core irqs: downstream these are "COMMON" irq 0,1.. */ - interrupts = <24 25 26 27 28 29 30 31>; - }; - - some_device: serial@c0fc1000 { - interrupt-parent = <&idu_intc>; - interrupts = <0 0>; /* upstream idu IRQ #24, Round Robin */ - }; diff --git a/Documentation/devicetree/bindings/arc/archs-intc.txt b/Documentation/devicetree/bindings/arc/archs-intc.txt deleted file mode 100644 index 69f326d6a..000000000 --- a/Documentation/devicetree/bindings/arc/archs-intc.txt +++ /dev/null @@ -1,22 +0,0 @@ -* ARC-HS incore Interrupt Controller (Provided by cores implementing ARCv2 ISA) - -Properties: - -- compatible: "snps,archs-intc" -- interrupt-controller: This is an interrupt controller. -- #interrupt-cells: Must be <1>. - - Single Cell "interrupts" property of a device specifies the IRQ number - between 16 to 256 - - intc accessed via the special ARC AUX register interface, hence "reg" property - is not specified. - -Example: - - intc: interrupt-controller { - compatible = "snps,archs-intc"; - interrupt-controller; - #interrupt-cells = <1>; - interrupts = <16 17 18 19 20 21 22 23 24 25>; - }; diff --git a/Documentation/devicetree/bindings/arc/interrupts.txt b/Documentation/devicetree/bindings/arc/interrupts.txt deleted file mode 100644 index 9a5d56243..000000000 --- a/Documentation/devicetree/bindings/arc/interrupts.txt +++ /dev/null @@ -1,24 +0,0 @@ -* ARC700 incore Interrupt Controller - - The core interrupt controller provides 32 prioritised interrupts (2 levels) - to ARC700 core. - -Properties: - -- compatible: "snps,arc700-intc" -- interrupt-controller: This is an interrupt controller. -- #interrupt-cells: Must be <1>. - - Single Cell "interrupts" property of a device specifies the IRQ number - between 0 to 31 - - intc accessed via the special ARC AUX register interface, hence "reg" property - is not specified. - -Example: - - intc: interrupt-controller { - compatible = "snps,arc700-intc"; - interrupt-controller; - #interrupt-cells = <1>; - }; diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt index 973884a1b..1dfee20ee 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.txt +++ b/Documentation/devicetree/bindings/arm/amlogic.txt @@ -9,6 +9,12 @@ Boards with the Amlogic Meson8 SoC shall have the following properties: Required root node property: compatible: "amlogic,meson8"; +Boards with the Amlogic Meson8b SoC shall have the following properties: + Required root node property: + compatible: "amlogic,meson8b"; + Board compatible values: - - "geniatech,atv1200" - - "minix,neo-x8" + - "geniatech,atv1200" (Meson6) + - "minix,neo-x8" (Meson8) + - "tronfy,mxq" (Meson8b) + - "hardkernel,odroid-c1" (Meson8b) diff --git a/Documentation/devicetree/bindings/arm/apm/scu.txt b/Documentation/devicetree/bindings/arm/apm/scu.txt new file mode 100644 index 000000000..b45be0662 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/apm/scu.txt @@ -0,0 +1,17 @@ +APM X-GENE SoC series SCU Registers + +This system clock unit contain various register that control block resets, +clock enable/disables, clock divisors and other deepsleep registers. + +Properties: + - compatible : should contain two values. First value must be: + - "apm,xgene-scu" + second value must be always "syscon". + + - reg : offset and length of the register set. + +Example : + scu: system-clk-controller@17000000 { + compatible = "apm,xgene-scu","syscon"; + reg = <0x0 0x17000000 0x0 0x400>; + }; diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt new file mode 100644 index 000000000..86302de67 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/arm,scpi.txt @@ -0,0 +1,188 @@ +System Control and Power Interface (SCPI) Message Protocol +---------------------------------------------------------- + +Firmware implementing the SCPI described in ARM document number ARM DUI 0922B +("ARM Compute Subsystem SCP: Message Interface Protocols")[0] can be used +by Linux to initiate various system control and power operations. + +Required properties: + +- compatible : should be "arm,scpi" +- mboxes: List of phandle and mailbox channel specifiers + All the channels reserved by remote SCP firmware for use by + SCPI message protocol should be specified in any order +- shmem : List of phandle pointing to the shared memory(SHM) area between the + processors using these mailboxes for IPC, one for each mailbox + SHM can be any memory reserved for the purpose of this communication + between the processors. + +See Documentation/devicetree/bindings/mailbox/mailbox.txt +for more details about the generic mailbox controller and +client driver bindings. + +Clock bindings for the clocks based on SCPI Message Protocol +------------------------------------------------------------ + +This binding uses the common clock binding[1]. + +Container Node +============== +Required properties: +- compatible : should be "arm,scpi-clocks" + All the clocks provided by SCP firmware via SCPI message + protocol much be listed as sub-nodes under this node. + +Sub-nodes +========= +Required properties: +- compatible : shall include one of the following + "arm,scpi-dvfs-clocks" - all the clocks that are variable and index based. + These clocks don't provide an entire range of values between the + limits but only discrete points within the range. The firmware + provides the mapping for each such operating frequency and the + index associated with it. The firmware also manages the + voltage scaling appropriately with the clock scaling. + "arm,scpi-variable-clocks" - all the clocks that are variable and provide full + range within the specified range. The firmware provides the + range of values within a specified range. + +Other required properties for all clocks(all from common clock binding): +- #clock-cells : Should be 1. Contains the Clock ID value used by SCPI commands. +- clock-output-names : shall be the corresponding names of the outputs. +- clock-indices: The identifying number for the clocks(i.e.clock_id) in the + node. It can be non linear and hence provide the mapping of identifiers + into the clock-output-names array. + +SRAM and Shared Memory for SCPI +------------------------------- + +A small area of SRAM is reserved for SCPI communication between application +processors and SCP. + +Required properties: +- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM on Juno + +The rest of the properties should follow the generic mmio-sram description +found in ../../misc/sysram.txt + +Each sub-node represents the reserved area for SCPI. + +Required sub-node properties: +- reg : The base offset and size of the reserved area with the SRAM +- compatible : should be "arm,juno-scp-shmem" for Non-secure SRAM based + shared memory on Juno platforms + +Sensor bindings for the sensors based on SCPI Message Protocol +-------------------------------------------------------------- +SCPI provides an API to access the various sensors on the SoC. + +Required properties: +- compatible : should be "arm,scpi-sensors". +- #thermal-sensor-cells: should be set to 1. This property follows the + thermal device tree bindings[2]. + + Valid cell values are raw identifiers (Sensor + ID) as used by the firmware. Refer to + platform documentation for your + implementation for the IDs to use. For Juno + R0 and Juno R1 refer to [3]. + +[0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt +[2] Documentation/devicetree/bindings/thermal/thermal.txt +[3] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/apas03s22.html + +Example: + +sram: sram@50000000 { + compatible = "arm,juno-sram-ns", "mmio-sram"; + reg = <0x0 0x50000000 0x0 0x10000>; + + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x0 0x50000000 0x10000>; + + cpu_scp_lpri: scp-shmem@0 { + compatible = "arm,juno-scp-shmem"; + reg = <0x0 0x200>; + }; + + cpu_scp_hpri: scp-shmem@200 { + compatible = "arm,juno-scp-shmem"; + reg = <0x200 0x200>; + }; +}; + +mailbox: mailbox0@40000000 { + .... + #mbox-cells = <1>; +}; + +scpi_protocol: scpi@2e000000 { + compatible = "arm,scpi"; + mboxes = <&mailbox 0 &mailbox 1>; + shmem = <&cpu_scp_lpri &cpu_scp_hpri>; + + clocks { + compatible = "arm,scpi-clocks"; + + scpi_dvfs: scpi_clocks@0 { + compatible = "arm,scpi-dvfs-clocks"; + #clock-cells = <1>; + clock-indices = <0>, <1>, <2>; + clock-output-names = "atlclk", "aplclk","gpuclk"; + }; + scpi_clk: scpi_clocks@3 { + compatible = "arm,scpi-variable-clocks"; + #clock-cells = <1>; + clock-indices = <3>, <4>; + clock-output-names = "pxlclk0", "pxlclk1"; + }; + }; + + scpi_sensors0: sensors { + compatible = "arm,scpi-sensors"; + #thermal-sensor-cells = <1>; + }; +}; + +cpu@0 { + ... + reg = <0 0>; + clocks = <&scpi_dvfs 0>; +}; + +hdlcd@7ff60000 { + ... + reg = <0 0x7ff60000 0 0x1000>; + clocks = <&scpi_clk 4>; +}; + +thermal-zones { + soc_thermal { + polling-delay-passive = <100>; + polling-delay = <1000>; + + /* sensor ID */ + thermal-sensors = <&scpi_sensors0 3>; + ... + }; +}; + +In the above example, the #clock-cells is set to 1 as required. +scpi_dvfs has 3 output clocks namely: atlclk, aplclk, and gpuclk with 0, +1 and 2 as clock-indices. scpi_clk has 2 output clocks namely: pxlclk0 +and pxlclk1 with 3 and 4 as clock-indices. + +The first consumer in the example is cpu@0 and it has '0' as the clock +specifier which points to the first entry in the output clocks of +scpi_dvfs i.e. "atlclk". + +Similarly the second example is hdlcd@7ff60000 and it has pxlclk1 as input +clock. '4' in the clock specifier here points to the second entry +in the output clocks of scpi_clocks i.e. "pxlclk1" + +The thermal-sensors property in the soc_thermal node uses the +temperature sensor provided by SCP firmware to setup a thermal +zone. The ID "3" is the sensor identifier for the temperature sensor +as used by the firmware. diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt b/Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt index 430608ec0..0d0c1ae81 100644 --- a/Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt @@ -20,6 +20,25 @@ system control is required: - compatible: "brcm,bcm-hif-cpubiuctrl", "syscon" - compatible: "brcm,bcm-hif-continuation", "syscon" +hif-cpubiuctrl node +------------------- +SoCs with Broadcom Brahma15 ARM-based CPUs have a specific Bus Interface Unit +(BIU) block which controls and interfaces the CPU complex to the different +Memory Controller Ports (MCP), one per memory controller (MEMC). This BIU block +offers a feature called Write Pairing which consists in collapsing two adjacent +cache lines into a single (bursted) write transaction towards the memory +controller (MEMC) to maximize write bandwidth. + +Required properties: + + - compatible: must be "brcm,bcm7445-hif-cpubiuctrl", "syscon" + +Optional properties: + + - brcm,write-pairing: + Boolean property, which when present indicates that the chip + supports write-pairing. + example: rdb { #address-cells = <1>; @@ -35,6 +54,7 @@ example: hif_cpubiuctrl: syscon@3e2400 { compatible = "brcm,bcm7445-hif-cpubiuctrl", "syscon"; reg = <0x3e2400 0x5b4>; + brcm,write-pairing; }; hif_continuation: syscon@452000 { @@ -43,8 +63,7 @@ example: }; }; -Lastly, nodes that allow for support of SMP initialization and reboot are -required: +Nodes that allow for support of SMP initialization and reboot are required: smpboot ------- @@ -95,3 +114,142 @@ example: compatible = "brcm,brcmstb-reboot"; syscon = <&sun_top_ctrl 0x304 0x308>; }; + + + +Power management +---------------- + +For power management (particularly, S2/S3/S5 system suspend), the following SoC +components are needed: + += Always-On control block (AON CTRL) + +This hardware provides control registers for the "always-on" (even in low-power +modes) hardware, such as the Power Management State Machine (PMSM). + +Required properties: +- compatible : should contain "brcm,brcmstb-aon-ctrl" +- reg : the register start and length for the AON CTRL block + +Example: + +aon-ctrl@410000 { + compatible = "brcm,brcmstb-aon-ctrl"; + reg = <0x410000 0x400>; +}; + += Memory controllers + +A Broadcom STB SoC typically has a number of independent memory controllers, +each of which may have several associated hardware blocks, which are versioned +independently (control registers, DDR PHYs, etc.). One might consider +describing these controllers as a parent "memory controllers" block, which +contains N sub-nodes (one for each controller in the system), each of which is +associated with a number of hardware register resources (e.g., its PHY). See +the example device tree snippet below. + +== MEMC (MEMory Controller) + +Represents a single memory controller instance. + +Required properties: +- compatible : should contain "brcm,brcmstb-memc" and "simple-bus" + +Should contain subnodes for any of the following relevant hardware resources: + +== DDR PHY control + +Control registers for this memory controller's DDR PHY. + +Required properties: +- compatible : should contain one of these + "brcm,brcmstb-ddr-phy-v225.1" + "brcm,brcmstb-ddr-phy-v240.1" + "brcm,brcmstb-ddr-phy-v240.2" + +- reg : the DDR PHY register range + +== DDR SHIMPHY + +Control registers for this memory controller's DDR SHIMPHY. + +Required properties: +- compatible : should contain "brcm,brcmstb-ddr-shimphy-v1.0" +- reg : the DDR SHIMPHY register range + +== MEMC DDR control + +Sequencer DRAM parameters and control registers. Used for Self-Refresh +Power-Down (SRPD), among other things. + +Required properties: +- compatible : should contain "brcm,brcmstb-memc-ddr" +- reg : the MEMC DDR register range + +Example: + +memory_controllers { + ranges; + compatible = "simple-bus"; + + memc@0 { + compatible = "brcm,brcmstb-memc", "simple-bus"; + ranges; + + ddr-phy@f1106000 { + compatible = "brcm,brcmstb-ddr-phy-v240.1"; + reg = <0xf1106000 0x21c>; + }; + + shimphy@f1108000 { + compatible = "brcm,brcmstb-ddr-shimphy-v1.0"; + reg = <0xf1108000 0xe4>; + }; + + memc-ddr@f1102000 { + reg = <0xf1102000 0x800>; + compatible = "brcm,brcmstb-memc-ddr"; + }; + }; + + memc@1 { + compatible = "brcm,brcmstb-memc", "simple-bus"; + ranges; + + ddr-phy@f1186000 { + compatible = "brcm,brcmstb-ddr-phy-v240.1"; + reg = <0xf1186000 0x21c>; + }; + + shimphy@f1188000 { + compatible = "brcm,brcmstb-ddr-shimphy-v1.0"; + reg = <0xf1188000 0xe4>; + }; + + memc-ddr@f1182000 { + reg = <0xf1182000 0x800>; + compatible = "brcm,brcmstb-memc-ddr"; + }; + }; + + memc@2 { + compatible = "brcm,brcmstb-memc", "simple-bus"; + ranges; + + ddr-phy@f1206000 { + compatible = "brcm,brcmstb-ddr-phy-v240.1"; + reg = <0xf1206000 0x21c>; + }; + + shimphy@f1208000 { + compatible = "brcm,brcmstb-ddr-shimphy-v1.0"; + reg = <0xf1208000 0xe4>; + }; + + memc-ddr@f1202000 { + reg = <0xf1202000 0x800>; + compatible = "brcm,brcmstb-memc-ddr"; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/arm/bcm/brcm,nsp.txt b/Documentation/devicetree/bindings/arm/bcm/brcm,nsp.txt new file mode 100644 index 000000000..eae53e455 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/bcm/brcm,nsp.txt @@ -0,0 +1,34 @@ +Broadcom Northstar Plus device tree bindings +-------------------------------------------- + +Broadcom Northstar Plus family of SoCs are used for switching control +and management applications as well as residential router/gateway +applications. The SoC features dual core Cortex A9 ARM CPUs, integrating +several peripheral interfaces including multiple Gigabit Ethernet PHYs, +DDR3 memory, PCIE Gen-2, USB 2.0 and USB 3.0, serial and NAND flash, +SATA and several other IO controllers. + +Boards with Northstar Plus SoCs shall have the following properties: + +Required root node property: + +BCM58522 +compatible = "brcm,bcm58522", "brcm,nsp"; + +BCM58525 +compatible = "brcm,bcm58525", "brcm,nsp"; + +BCM58535 +compatible = "brcm,bcm58535", "brcm,nsp"; + +BCM58622 +compatible = "brcm,bcm58622", "brcm,nsp"; + +BCM58623 +compatible = "brcm,bcm58623", "brcm,nsp"; + +BCM58625 +compatible = "brcm,bcm58625", "brcm,nsp"; + +BCM88312 +compatible = "brcm,bcm88312", "brcm,nsp"; diff --git a/Documentation/devicetree/bindings/arm/calxeda/combophy.txt b/Documentation/devicetree/bindings/arm/calxeda/combophy.txt deleted file mode 100644 index 6622bdb2e..000000000 --- a/Documentation/devicetree/bindings/arm/calxeda/combophy.txt +++ /dev/null @@ -1,17 +0,0 @@ -Calxeda Highbank Combination Phys for SATA - -Properties: -- compatible : Should be "calxeda,hb-combophy" -- #phy-cells: Should be 1. -- reg : Address and size for Combination Phy registers. -- phydev: device ID for programming the combophy. - -Example: - - combophy5: combo-phy@fff5d000 { - compatible = "calxeda,hb-combophy"; - #phy-cells = <1>; - reg = <0xfff5d000 0x1000>; - phydev = <31>; - }; - diff --git a/Documentation/devicetree/bindings/arm/calxeda/mem-ctrlr.txt b/Documentation/devicetree/bindings/arm/calxeda/mem-ctrlr.txt deleted file mode 100644 index 049675944..000000000 --- a/Documentation/devicetree/bindings/arm/calxeda/mem-ctrlr.txt +++ /dev/null @@ -1,16 +0,0 @@ -Calxeda DDR memory controller - -Properties: -- compatible : Should be: - - "calxeda,hb-ddr-ctrl" for ECX-1000 - - "calxeda,ecx-2000-ddr-ctrl" for ECX-2000 -- reg : Address and size for DDR controller registers. -- interrupts : Interrupt for DDR controller. - -Example: - - memory-controller@fff00000 { - compatible = "calxeda,hb-ddr-ctrl"; - reg = <0xfff00000 0x1000>; - interrupts = <0 91 4>; - }; diff --git a/Documentation/devicetree/bindings/arm/coherency-fabric.txt b/Documentation/devicetree/bindings/arm/coherency-fabric.txt index 8dd46617c..9b5c3f620 100644 --- a/Documentation/devicetree/bindings/arm/coherency-fabric.txt +++ b/Documentation/devicetree/bindings/arm/coherency-fabric.txt @@ -27,6 +27,11 @@ Required properties: * For "marvell,armada-380-coherency-fabric", only one pair is needed for the per-CPU fabric registers. +Optional properties: + +- broken-idle: boolean to set when the Idle mode is not supported by the + hardware. + Examples: coherency-fabric@d0020200 { diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index 91e6e5c47..3a07a87fe 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -195,6 +195,8 @@ nodes to be present and contain the properties described below. "marvell,armada-380-smp" "marvell,armada-390-smp" "marvell,armada-xp-smp" + "mediatek,mt6589-smp" + "mediatek,mt81xx-tz-smp" "qcom,gcc-msm8660" "qcom,kpss-acc-v1" "qcom,kpss-acc-v2" diff --git a/Documentation/devicetree/bindings/arm/davinci/cp-intc.txt b/Documentation/devicetree/bindings/arm/davinci/cp-intc.txt deleted file mode 100644 index 597e8a089..000000000 --- a/Documentation/devicetree/bindings/arm/davinci/cp-intc.txt +++ /dev/null @@ -1,27 +0,0 @@ -* TI Common Platform Interrupt Controller - -Common Platform Interrupt Controller (cp_intc) is used on -OMAP-L1x SoCs and can support several configurable number -of interrupts. - -Main node required properties: - -- compatible : should be: - "ti,cp-intc" -- interrupt-controller : Identifies the node as an interrupt controller -- #interrupt-cells : Specifies the number of cells needed to encode an - interrupt source. The type shall be a and the value shall be 1. - - The cell contains the interrupt number in the range [0-128]. -- ti,intc-size: Number of interrupts handled by the interrupt controller. -- reg: physical base address and size of the intc registers map. - -Example: - - intc: interrupt-controller@1 { - compatible = "ti,cp-intc"; - interrupt-controller; - #interrupt-cells = <1>; - ti,intc-size = <101>; - reg = <0xfffee000 0x2000>; - }; diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt deleted file mode 100644 index e151057d9..000000000 --- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt +++ /dev/null @@ -1,53 +0,0 @@ -* Samsung Exynos Power Domains - -Exynos processors include 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. - * samsung,exynos4210-pd - for exynos4210 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: -- 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 - all domains which are powered on and off and not required for unused - domains. -- clock-names: The following clocks can be specified: - - oscclk: Oscillator clock. - - clkN: Input clocks to the devices in this power domain. These clocks - will be reparented to oscclk before swithing power domain off. - Their original parent will be brought back after turning on - the domain. Maximum of 4 clocks (N = 0 to 3) are supported. - - asbN: Clocks required by asynchronous bridges (ASB) present in - the power domain. These clock should be enabled during power - domain on/off operations. -- power-domains: phandle pointing to the parent power domain, for more details - see Documentation/devicetree/bindings/power/power_domain.txt - -Node of a device using power domains must have a power-domains property -defined with a phandle to respective power domain. - -Example: - - lcd0: power-domain-lcd0 { - compatible = "samsung,exynos4210-pd"; - reg = <0x10023C00 0x10>; - #power-domain-cells = <0>; - }; - - mfc_pd: power-domain@10044060 { - compatible = "samsung,exynos4210-pd"; - reg = <0x10044060 0x20>; - clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MOUT_SW_ACLK333>, - <&clock CLK_MOUT_USER_ACLK333>; - clock-names = "oscclk", "pclk0", "clk0"; - #power-domain-cells = <0>; - }; - -See Documentation/devicetree/bindings/power/power_domain.txt for description -of consumer-side bindings. diff --git a/Documentation/devicetree/bindings/arm/fsl.txt b/Documentation/devicetree/bindings/arm/fsl.txt index 2a3ba73f0..34c88b0c7 100644 --- a/Documentation/devicetree/bindings/arm/fsl.txt +++ b/Documentation/devicetree/bindings/arm/fsl.txt @@ -128,10 +128,18 @@ Example: reg = <0x0 0x1ee0000 0x0 0x10000>; }; -Freescale LS2085A SoC Device Tree Bindings ------------------------------------------- +Freescale ARMv8 based Layerscape SoC family Device Tree Bindings +---------------------------------------------------------------- -LS2085A ARMv8 based Simulator model +LS2080A ARMv8 based Simulator model Required root node properties: - - compatible = "fsl,ls2085a-simu", "fsl,ls2085a"; + - compatible = "fsl,ls2080a-simu", "fsl,ls2080a"; + +LS2080A ARMv8 based QDS Board +Required root node properties: + - compatible = "fsl,ls2080a-qds", "fsl,ls2080a"; + +LS2080A ARMv8 based RDB Board +Required root node properties: + - compatible = "fsl,ls2080a-rdb", "fsl,ls2080a"; diff --git a/Documentation/devicetree/bindings/arm/gic-v3.txt b/Documentation/devicetree/bindings/arm/gic-v3.txt deleted file mode 100644 index 7803e77d8..000000000 --- a/Documentation/devicetree/bindings/arm/gic-v3.txt +++ /dev/null @@ -1,123 +0,0 @@ -* ARM Generic Interrupt Controller, version 3 - -AArch64 SMP cores are often associated with a GICv3, providing Private -Peripheral Interrupts (PPI), Shared Peripheral Interrupts (SPI), -Software Generated Interrupts (SGI), and Locality-specific Peripheral -Interrupts (LPI). - -Main node required properties: - -- compatible : should at least contain "arm,gic-v3". -- interrupt-controller : Identifies the node as an interrupt controller -- #interrupt-cells : Specifies the number of cells needed to encode an - interrupt source. Must be a single cell with a value of at least 3. - - The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI - interrupts. Other values are reserved for future use. - - The 2nd cell contains the interrupt number for the interrupt type. - SPI interrupts are in the range [0-987]. PPI interrupts are in the - range [0-15]. - - The 3rd cell is the flags, encoded as follows: - bits[3:0] trigger type and level flags. - 1 = edge triggered - 4 = level triggered - - Cells 4 and beyond are reserved for future use. When the 1st cell - has a value of 0 or 1, cells 4 and beyond act as padding, and may be - ignored. It is recommended that padding cells have a value of 0. - -- reg : Specifies base physical address(s) and size of the GIC - registers, in the following order: - - GIC Distributor interface (GICD) - - GIC Redistributors (GICR), one range per redistributor region - - GIC CPU interface (GICC) - - GIC Hypervisor interface (GICH) - - GIC Virtual CPU interface (GICV) - - GICC, GICH and GICV are optional. - -- interrupts : Interrupt source of the VGIC maintenance interrupt. - -Optional - -- redistributor-stride : If using padding pages, specifies the stride - of consecutive redistributors. Must be a multiple of 64kB. - -- #redistributor-regions: The number of independent contiguous regions - occupied by the redistributors. Required if more than one such - region is present. - -Sub-nodes: - -GICv3 has one or more Interrupt Translation Services (ITS) that are -used to route Message Signalled Interrupts (MSI) to the CPUs. - -These nodes must have the following properties: -- compatible : Should at least contain "arm,gic-v3-its". -- msi-controller : Boolean property. Identifies the node as an MSI controller -- #msi-cells: Must be <1>. The single msi-cell is the DeviceID of the device - which will generate the MSI. -- reg: Specifies the base physical address and size of the ITS - registers. - -The main GIC node must contain the appropriate #address-cells, -#size-cells and ranges properties for the reg property of all ITS -nodes. - -Examples: - - gic: interrupt-controller@2cf00000 { - compatible = "arm,gic-v3"; - #interrupt-cells = <3>; - #address-cells = <2>; - #size-cells = <2>; - ranges; - interrupt-controller; - reg = <0x0 0x2f000000 0 0x10000>, // GICD - <0x0 0x2f100000 0 0x200000>, // GICR - <0x0 0x2c000000 0 0x2000>, // GICC - <0x0 0x2c010000 0 0x2000>, // GICH - <0x0 0x2c020000 0 0x2000>; // GICV - interrupts = <1 9 4>; - - gic-its@2c200000 { - compatible = "arm,gic-v3-its"; - msi-controller; - #msi-cells = <1>; - reg = <0x0 0x2c200000 0 0x200000>; - }; - }; - - gic: interrupt-controller@2c010000 { - compatible = "arm,gic-v3"; - #interrupt-cells = <3>; - #address-cells = <2>; - #size-cells = <2>; - ranges; - interrupt-controller; - redistributor-stride = <0x0 0x40000>; // 256kB stride - #redistributor-regions = <2>; - reg = <0x0 0x2c010000 0 0x10000>, // GICD - <0x0 0x2d000000 0 0x800000>, // GICR 1: CPUs 0-31 - <0x0 0x2e000000 0 0x800000>; // GICR 2: CPUs 32-63 - <0x0 0x2c040000 0 0x2000>, // GICC - <0x0 0x2c060000 0 0x2000>, // GICH - <0x0 0x2c080000 0 0x2000>; // GICV - interrupts = <1 9 4>; - - gic-its@2c200000 { - compatible = "arm,gic-v3-its"; - msi-controller; - #msi-cells = <1>; - reg = <0x0 0x2c200000 0 0x200000>; - }; - - gic-its@2c400000 { - compatible = "arm,gic-v3-its"; - msi-controller; - #msi-cells = <1>; - reg = <0x0 0x2c400000 0 0x200000>; - }; - }; diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt deleted file mode 100644 index 2da059a47..000000000 --- a/Documentation/devicetree/bindings/arm/gic.txt +++ /dev/null @@ -1,152 +0,0 @@ -* ARM Generic Interrupt Controller - -ARM SMP cores are often associated with a GIC, providing per processor -interrupts (PPI), shared processor interrupts (SPI) and software -generated interrupts (SGI). - -Primary GIC is attached directly to the CPU and typically has PPIs and SGIs. -Secondary GICs are cascaded into the upward interrupt controller and do not -have PPIs or SGIs. - -Main node required properties: - -- compatible : should be one of: - "arm,gic-400" - "arm,cortex-a15-gic" - "arm,cortex-a9-gic" - "arm,cortex-a7-gic" - "arm,arm11mp-gic" - "brcm,brahma-b15-gic" - "arm,arm1176jzf-devchip-gic" - "qcom,msm-8660-qgic" - "qcom,msm-qgic2" -- interrupt-controller : Identifies the node as an interrupt controller -- #interrupt-cells : Specifies the number of cells needed to encode an - interrupt source. The type shall be a and the value shall be 3. - - The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI - interrupts. - - The 2nd cell contains the interrupt number for the interrupt type. - SPI interrupts are in the range [0-987]. PPI interrupts are in the - range [0-15]. - - The 3rd cell is the flags, encoded as follows: - bits[3:0] trigger type and level flags. - 1 = low-to-high edge triggered - 2 = high-to-low edge triggered (invalid for SPIs) - 4 = active high level-sensitive - 8 = active low level-sensitive (invalid for SPIs). - bits[15:8] PPI interrupt cpu mask. Each bit corresponds to each of - the 8 possible cpus attached to the GIC. A bit set to '1' indicated - the interrupt is wired to that CPU. Only valid for PPI interrupts. - Also note that the configurability of PPI interrupts is IMPLEMENTATION - DEFINED and as such not guaranteed to be present (most SoC available - in 2014 seem to ignore the setting of this flag and use the hardware - default value). - -- reg : Specifies base physical address(s) and size of the GIC registers. The - first region is the GIC distributor register base and size. The 2nd region is - the GIC cpu interface register base and size. - -Optional -- interrupts : Interrupt source of the parent interrupt controller on - secondary GICs, or VGIC maintenance interrupt on primary GIC (see - below). - -- cpu-offset : per-cpu offset within the distributor and cpu interface - regions, used when the GIC doesn't have banked registers. The offset is - cpu-offset * cpu-nr. - -Example: - - intc: interrupt-controller@fff11000 { - compatible = "arm,cortex-a9-gic"; - #interrupt-cells = <3>; - #address-cells = <1>; - interrupt-controller; - reg = <0xfff11000 0x1000>, - <0xfff10100 0x100>; - }; - - -* GIC virtualization extensions (VGIC) - -For ARM cores that support the virtualization extensions, additional -properties must be described (they only exist if the GIC is the -primary interrupt controller). - -Required properties: - -- reg : Additional regions specifying the base physical address and - size of the VGIC registers. The first additional region is the GIC - virtual interface control register base and size. The 2nd additional - region is the GIC virtual cpu interface register base and size. - -- interrupts : VGIC maintenance interrupt. - -Example: - - interrupt-controller@2c001000 { - compatible = "arm,cortex-a15-gic"; - #interrupt-cells = <3>; - interrupt-controller; - reg = <0x2c001000 0x1000>, - <0x2c002000 0x1000>, - <0x2c004000 0x2000>, - <0x2c006000 0x2000>; - interrupts = <1 9 0xf04>; - }; - - -* GICv2m extension for MSI/MSI-x support (Optional) - -Certain revisions of GIC-400 supports MSI/MSI-x via V2M register frame(s). -This is enabled by specifying v2m sub-node(s). - -Required properties: - -- compatible : The value here should contain "arm,gic-v2m-frame". - -- msi-controller : Identifies the node as an MSI controller. - -- reg : GICv2m MSI interface register base and size - -Optional properties: - -- arm,msi-base-spi : When the MSI_TYPER register contains an incorrect - value, this property should contain the SPI base of - the MSI frame, overriding the HW value. - -- arm,msi-num-spis : When the MSI_TYPER register contains an incorrect - value, this property should contain the number of - SPIs assigned to the frame, overriding the HW value. - -Example: - - interrupt-controller@e1101000 { - compatible = "arm,gic-400"; - #interrupt-cells = <3>; - #address-cells = <2>; - #size-cells = <2>; - interrupt-controller; - interrupts = <1 8 0xf04>; - ranges = <0 0 0 0xe1100000 0 0x100000>; - reg = <0x0 0xe1110000 0 0x01000>, - <0x0 0xe112f000 0 0x02000>, - <0x0 0xe1140000 0 0x10000>, - <0x0 0xe1160000 0 0x10000>; - v2m0: v2m@0x8000 { - compatible = "arm,gic-v2m-frame"; - msi-controller; - reg = <0x0 0x80000 0 0x1000>; - }; - - .... - - v2mN: v2m@0x9000 { - compatible = "arm,gic-v2m-frame"; - msi-controller; - reg = <0x0 0x90000 0 0x1000>; - }; - }; diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt index c733e28e1..6ac7c000a 100644 --- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt +++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt @@ -20,6 +20,10 @@ HiKey Board Required root node properties: - compatible = "hisilicon,hi6220-hikey", "hisilicon,hi6220"; +HiP05 D02 Board +Required root node properties: + - compatible = "hisilicon,hip05-d02"; + Hisilicon system controller Required properties: @@ -166,6 +170,23 @@ Example: reboot-offset = <0x4>; }; +----------------------------------------------------------------------- +Hisilicon HiP05 PCIe-SAS system controller + +Required properties: +- compatible : "hisilicon,pcie-sas-subctrl", "syscon"; +- reg : Register address and size + +The HiP05 PCIe-SAS system controller is shared by PCIe and SAS controllers in +HiP05 Soc to implement some basic configurations. + +Example: + /* for HiP05 PCIe-SAS system */ + pcie_sas: system_controller@0xb0000000 { + compatible = "hisilicon,pcie-sas-subctrl", "syscon"; + reg = <0xb0000000 0x10000>; + }; + ----------------------------------------------------------------------- Hisilicon CPU controller diff --git a/Documentation/devicetree/bindings/arm/keystone/keystone.txt b/Documentation/devicetree/bindings/arm/keystone/keystone.txt index 59d7a46f8..3090a8a00 100644 --- a/Documentation/devicetree/bindings/arm/keystone/keystone.txt +++ b/Documentation/devicetree/bindings/arm/keystone/keystone.txt @@ -9,12 +9,26 @@ Required properties: the form "ti,keystone-*". Generic devices like gic, arch_timers, ns16550 type UART should use the specified compatible for those devices. +SoC families: + +- Keystone 2 generic SoC: + compatible = "ti,keystone" + +SoCs: + +- Keystone 2 Hawking/Kepler + compatible = "ti,k2hk", "ti,keystone" +- Keystone 2 Lamarr + compatible = "ti,k2l", "ti,keystone" +- Keystone 2 Edison + compatible = "ti,k2e", "ti,keystone" + Boards: - Keystone 2 Hawking/Kepler EVM - compatible = "ti,k2hk-evm","ti,keystone" + compatible = "ti,k2hk-evm", "ti,k2hk", "ti,keystone" - Keystone 2 Lamarr EVM - compatible = "ti,k2l-evm","ti,keystone" + compatible = "ti,k2l-evm", "ti, k2l", "ti,keystone" - Keystone 2 Edison EVM - compatible = "ti,k2e-evm","ti,keystone" + compatible = "ti,k2e-evm", "ti,k2e", "ti,keystone" diff --git a/Documentation/devicetree/bindings/arm/lpc32xx-mic.txt b/Documentation/devicetree/bindings/arm/lpc32xx-mic.txt deleted file mode 100644 index 539adca19..000000000 --- a/Documentation/devicetree/bindings/arm/lpc32xx-mic.txt +++ /dev/null @@ -1,38 +0,0 @@ -* NXP LPC32xx Main Interrupt Controller - (MIC, including SIC1 and SIC2 secondary controllers) - -Required properties: -- compatible: Should be "nxp,lpc3220-mic" -- interrupt-controller: Identifies the node as an interrupt controller. -- interrupt-parent: Empty for the interrupt controller itself -- #interrupt-cells: The number of cells to define the interrupts. Should be 2. - The first cell is the IRQ number - The second cell is used to specify mode: - 1 = low-to-high edge triggered - 2 = high-to-low edge triggered - 4 = active high level-sensitive - 8 = active low level-sensitive - Default for internal sources should be set to 4 (active high). -- reg: Should contain MIC registers location and length - -Examples: - /* - * MIC - */ - mic: interrupt-controller@40008000 { - compatible = "nxp,lpc3220-mic"; - interrupt-controller; - interrupt-parent; - #interrupt-cells = <2>; - reg = <0x40008000 0xC000>; - }; - - /* - * ADC - */ - adc@40048000 { - compatible = "nxp,lpc3220-adc"; - reg = <0x40048000 0x1000>; - interrupt-parent = <&mic>; - interrupts = <39 4>; - }; diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt new file mode 100644 index 000000000..b1f2ce17d --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,imgsys.txt @@ -0,0 +1,22 @@ +Mediatek imgsys controller +============================ + +The Mediatek imgsys controller provides various clocks to the system. + +Required Properties: + +- compatible: Should be: + - "mediatek,mt8173-imgsys", "syscon" +- #clock-cells: Must be 1 + +The imgsys controller uses the common clk binding from +Documentation/devicetree/bindings/clock/clock-bindings.txt +The available clocks are defined in dt-bindings/clock/mt*-clk.h. + +Example: + +imgsys: clock-controller@15000000 { + compatible = "mediatek,mt8173-imgsys", "syscon"; + reg = <0 0x15000000 0 0x1000>; + #clock-cells = <1>; +}; diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt new file mode 100644 index 000000000..4385946ea --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.txt @@ -0,0 +1,22 @@ +Mediatek mmsys controller +============================ + +The Mediatek mmsys controller provides various clocks to the system. + +Required Properties: + +- compatible: Should be: + - "mediatek,mt8173-mmsys", "syscon" +- #clock-cells: Must be 1 + +The mmsys controller uses the common clk binding from +Documentation/devicetree/bindings/clock/clock-bindings.txt +The available clocks are defined in dt-bindings/clock/mt*-clk.h. + +Example: + +mmsys: clock-controller@14000000 { + compatible = "mediatek,mt8173-mmsys", "syscon"; + reg = <0 0x14000000 0 0x1000>; + #clock-cells = <1>; +}; diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,sysirq.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,sysirq.txt deleted file mode 100644 index afef6a85a..000000000 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,sysirq.txt +++ /dev/null @@ -1,32 +0,0 @@ -+Mediatek 65xx/67xx/81xx sysirq - -Mediatek SOCs sysirq support controllable irq inverter for each GIC SPI -interrupt. - -Required properties: -- compatible: should be one of: - "mediatek,mt8173-sysirq" - "mediatek,mt8135-sysirq" - "mediatek,mt8127-sysirq" - "mediatek,mt6795-sysirq" - "mediatek,mt6592-sysirq" - "mediatek,mt6589-sysirq" - "mediatek,mt6582-sysirq" - "mediatek,mt6580-sysirq" - "mediatek,mt6577-sysirq" -- interrupt-controller : Identifies the node as an interrupt controller -- #interrupt-cells : Use the same format as specified by GIC in - Documentation/devicetree/bindings/arm/gic.txt -- interrupt-parent: phandle of irq parent for sysirq. The parent must - use the same interrupt-cells format as GIC. -- reg: Physical base address of the intpol registers and length of memory - mapped region. - -Example: - sysirq: interrupt-controller@10200100 { - compatible = "mediatek,mt6589-sysirq", "mediatek,mt6577-sysirq"; - interrupt-controller; - #interrupt-cells = <3>; - interrupt-parent = <&gic>; - reg = <0 0x10200100 0 0x1c>; - }; diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt new file mode 100644 index 000000000..1faacf1c1 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vdecsys.txt @@ -0,0 +1,22 @@ +Mediatek vdecsys controller +============================ + +The Mediatek vdecsys controller provides various clocks to the system. + +Required Properties: + +- compatible: Should be: + - "mediatek,mt8173-vdecsys", "syscon" +- #clock-cells: Must be 1 + +The vdecsys controller uses the common clk binding from +Documentation/devicetree/bindings/clock/clock-bindings.txt +The available clocks are defined in dt-bindings/clock/mt*-clk.h. + +Example: + +vdecsys: clock-controller@16000000 { + compatible = "mediatek,mt8173-vdecsys", "syscon"; + reg = <0 0x16000000 0 0x1000>; + #clock-cells = <1>; +}; diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt new file mode 100644 index 000000000..3cc299fd7 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencltsys.txt @@ -0,0 +1,22 @@ +Mediatek vencltsys controller +============================ + +The Mediatek vencltsys controller provides various clocks to the system. + +Required Properties: + +- compatible: Should be: + - "mediatek,mt8173-vencltsys", "syscon" +- #clock-cells: Must be 1 + +The vencltsys controller uses the common clk binding from +Documentation/devicetree/bindings/clock/clock-bindings.txt +The available clocks are defined in dt-bindings/clock/mt*-clk.h. + +Example: + +vencltsys: clock-controller@19000000 { + compatible = "mediatek,mt8173-vencltsys", "syscon"; + reg = <0 0x19000000 0 0x1000>; + #clock-cells = <1>; +}; diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt new file mode 100644 index 000000000..5bb2866a2 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,vencsys.txt @@ -0,0 +1,22 @@ +Mediatek vencsys controller +============================ + +The Mediatek vencsys controller provides various clocks to the system. + +Required Properties: + +- compatible: Should be: + - "mediatek,mt8173-vencsys", "syscon" +- #clock-cells: Must be 1 + +The vencsys controller uses the common clk binding from +Documentation/devicetree/bindings/clock/clock-bindings.txt +The available clocks are defined in dt-bindings/clock/mt*-clk.h. + +Example: + +vencsys: clock-controller@18000000 { + compatible = "mediatek,mt8173-vencsys", "syscon"; + reg = <0 0x18000000 0 0x1000>; + #clock-cells = <1>; +}; diff --git a/Documentation/devicetree/bindings/arm/mrvl/intc.txt b/Documentation/devicetree/bindings/arm/mrvl/intc.txt deleted file mode 100644 index 8b53273cb..000000000 --- a/Documentation/devicetree/bindings/arm/mrvl/intc.txt +++ /dev/null @@ -1,60 +0,0 @@ -* Marvell MMP Interrupt controller - -Required properties: -- compatible : Should be "mrvl,mmp-intc", "mrvl,mmp2-intc" or - "mrvl,mmp2-mux-intc" -- reg : Address and length of the register set of the interrupt controller. - If the interrupt controller is intc, address and length means the range - of the whold interrupt controller. If the interrupt controller is mux-intc, - address and length means one register. Since address of mux-intc is in the - range of intc. mux-intc is secondary interrupt controller. -- reg-names : Name of the register set of the interrupt controller. It's - only required in mux-intc interrupt controller. -- interrupts : Should be the port interrupt shared by mux interrupts. It's - only required in mux-intc interrupt controller. -- interrupt-controller : Identifies the node as an interrupt controller. -- #interrupt-cells : Specifies the number of cells needed to encode an - interrupt source. -- mrvl,intc-nr-irqs : Specifies the number of interrupts in the interrupt - controller. -- mrvl,clr-mfp-irq : Specifies the interrupt that needs to clear MFP edge - detection first. - -Example: - intc: interrupt-controller@d4282000 { - compatible = "mrvl,mmp2-intc"; - interrupt-controller; - #interrupt-cells = <1>; - reg = <0xd4282000 0x1000>; - mrvl,intc-nr-irqs = <64>; - }; - - intcmux4@d4282150 { - compatible = "mrvl,mmp2-mux-intc"; - interrupts = <4>; - interrupt-controller; - #interrupt-cells = <1>; - reg = <0x150 0x4>, <0x168 0x4>; - reg-names = "mux status", "mux mask"; - mrvl,intc-nr-irqs = <2>; - }; - -* Marvell Orion Interrupt controller - -Required properties -- compatible : Should be "marvell,orion-intc". -- #interrupt-cells: Specifies the number of cells needed to encode an - interrupt source. Supported value is <1>. -- interrupt-controller : Declare this node to be an interrupt controller. -- reg : Interrupt mask address. A list of 4 byte ranges, one per controller. - One entry in the list represents 32 interrupts. - -Example: - - intc: interrupt-controller { - compatible = "marvell,orion-intc", "marvell,intc"; - interrupt-controller; - #interrupt-cells = <1>; - reg = <0xfed20204 0x04>, - <0xfed20214 0x04>; - }; diff --git a/Documentation/devicetree/bindings/arm/mvebu-cpu-config.txt b/Documentation/devicetree/bindings/arm/mvebu-cpu-config.txt new file mode 100644 index 000000000..2cdcd716d --- /dev/null +++ b/Documentation/devicetree/bindings/arm/mvebu-cpu-config.txt @@ -0,0 +1,20 @@ +MVEBU CPU Config registers +-------------------------- + +MVEBU (Marvell SOCs: Armada 370/XP) + +Required properties: + +- compatible: one of: + - "marvell,armada-370-cpu-config" + - "marvell,armada-xp-cpu-config" + +- reg: Should contain CPU config registers location and length, in + their per-CPU variant + +Example: + + cpu-config@21000 { + compatible = "marvell,armada-xp-cpu-config"; + reg = <0x21000 0x8>; + }; diff --git a/Documentation/devicetree/bindings/arm/omap/intc.txt b/Documentation/devicetree/bindings/arm/omap/intc.txt deleted file mode 100644 index f2583e6ec..000000000 --- a/Documentation/devicetree/bindings/arm/omap/intc.txt +++ /dev/null @@ -1,27 +0,0 @@ -* OMAP Interrupt Controller - -OMAP2/3 are using a TI interrupt controller that can support several -configurable number of interrupts. - -Main node required properties: - -- compatible : should be: - "ti,omap2-intc" -- interrupt-controller : Identifies the node as an interrupt controller -- #interrupt-cells : Specifies the number of cells needed to encode an - interrupt source. The type shall be a and the value shall be 1. - - The cell contains the interrupt number in the range [0-128]. -- ti,intc-size: Number of interrupts handled by the interrupt controller. -- reg: physical base address and size of the intc registers map. - -Example: - - intc: interrupt-controller@1 { - compatible = "ti,omap2-intc"; - interrupt-controller; - #interrupt-cells = <1>; - ti,intc-size = <96>; - reg = <0x48200000 0x1000>; - }; - diff --git a/Documentation/devicetree/bindings/arm/pmu.txt b/Documentation/devicetree/bindings/arm/pmu.txt index 435251fa9..97ba45af0 100644 --- a/Documentation/devicetree/bindings/arm/pmu.txt +++ b/Documentation/devicetree/bindings/arm/pmu.txt @@ -7,7 +7,10 @@ representation in the device tree should be done as under:- Required properties: - compatible : should be one of + "apm,potenza-pmu" "arm,armv8-pmuv3" + "arm.cortex-a57-pmu" + "arm.cortex-a53-pmu" "arm,cortex-a17-pmu" "arm,cortex-a15-pmu" "arm,cortex-a12-pmu" diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt index 5aa40ede0..a9adab84e 100644 --- a/Documentation/devicetree/bindings/arm/psci.txt +++ b/Documentation/devicetree/bindings/arm/psci.txt @@ -31,6 +31,10 @@ Main node required properties: support, but are permitted to be present for compatibility with existing software when "arm,psci" is later in the compatible list. + * "arm,psci-1.0" : for implementations complying to PSCI 1.0. PSCI 1.0 is + backward compatible with PSCI 0.2 with minor specification updates, + as defined in the PSCI specification[2]. + - method : The method of calling the PSCI firmware. Permitted values are: @@ -100,3 +104,5 @@ Case 3: PSCI v0.2 and PSCI v0.1. [1] Kernel documentation - ARM idle states bindings Documentation/devicetree/bindings/arm/idle-states.txt +[2] Power State Coordination Interface (PSCI) specification + http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt index af58cd74a..8e985dd2f 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.txt +++ b/Documentation/devicetree/bindings/arm/rockchip.txt @@ -17,6 +17,10 @@ Rockchip platforms device tree bindings Required root node properties: - compatible = "radxa,rock", "rockchip,rk3188"; +- Radxa Rock2 Square board: + Required root node properties: + - compatible = "radxa,rock2-square", "rockchip,rk3288"; + - Firefly Firefly-RK3288 board: Required root node properties: - compatible = "firefly,firefly-rk3288", "rockchip,rk3288"; @@ -31,6 +35,13 @@ Rockchip platforms device tree bindings Required root node properties: - compatible = "netxeon,r89", "rockchip,rk3288"; +- Google Jaq (Haier Chromebook 11 and more): + Required root node properties: + - compatible = "google,veyron-jaq-rev5", "google,veyron-jaq-rev4", + "google,veyron-jaq-rev3", "google,veyron-jaq-rev2", + "google,veyron-jaq-rev1", "google,veyron-jaq", + "google,veyron", "rockchip,rk3288"; + - Google Jerry (Hisense Chromebook C11 and more): Required root node properties: - compatible = "google,veyron-jerry-rev7", "google,veyron-jerry-rev6", diff --git a/Documentation/devicetree/bindings/arm/samsung-boards.txt b/Documentation/devicetree/bindings/arm/samsung-boards.txt deleted file mode 100644 index 43589d246..000000000 --- a/Documentation/devicetree/bindings/arm/samsung-boards.txt +++ /dev/null @@ -1,27 +0,0 @@ -* Samsung's Exynos SoC based boards - -Required root node properties: - - compatible = should be one or more of the following. - - "samsung,monk" - for Exynos3250-based Samsung Simband board. - - "samsung,rinato" - for Exynos3250-based Samsung Gear2 board. - - "samsung,smdkv310" - for Exynos4210-based Samsung SMDKV310 eval board. - - "samsung,trats" - for Exynos4210-based Tizen Reference board. - - "samsung,universal_c210" - for Exynos4210-based Samsung board. - - "samsung,smdk4412", - for Exynos4412-based Samsung SMDK4412 eval board. - - "samsung,trats2" - for Exynos4412-based Tizen Reference board. - - "samsung,smdk5250" - for Exynos5250-based Samsung SMDK5250 eval board. - - "samsung,xyref5260" - for Exynos5260-based Samsung board. - - "samsung,smdk5410" - for Exynos5410-based Samsung SMDK5410 eval board. - - "samsung,smdk5420" - for Exynos5420-based Samsung SMDK5420 eval board. - - "samsung,sd5v1" - for Exynos5440-based Samsung board. - - "samsung,ssdk5440" - for Exynos5440-based Samsung board. - -Optional: - - firmware node, specifying presence and type of secure firmware: - - compatible: only "samsung,secure-firmware" is currently supported - - reg: address of non-secure SYSRAM used for communication with firmware - - firmware@0203F000 { - compatible = "samsung,secure-firmware"; - reg = <0x0203F000 0x1000>; - }; diff --git a/Documentation/devicetree/bindings/arm/samsung/interrupt-combiner.txt b/Documentation/devicetree/bindings/arm/samsung/interrupt-combiner.txt deleted file mode 100644 index 9e5f73412..000000000 --- a/Documentation/devicetree/bindings/arm/samsung/interrupt-combiner.txt +++ /dev/null @@ -1,52 +0,0 @@ -* Samsung Exynos Interrupt Combiner Controller - -Samsung's Exynos4 architecture includes a interrupt combiner controller which -can combine interrupt sources as a group and provide a single interrupt request -for the group. The interrupt request from each group are connected to a parent -interrupt controller, such as GIC in case of Exynos4210. - -The interrupt combiner controller consists of multiple combiners. Up to eight -interrupt sources can be connected to a combiner. The combiner outputs one -combined interrupt for its eight interrupt sources. The combined interrupt -is usually connected to a parent interrupt controller. - -A single node in the device tree is used to describe the interrupt combiner -controller module (which includes multiple combiners). A combiner in the -interrupt controller module shares config/control registers with other -combiners. For example, a 32-bit interrupt enable/disable config register -can accommodate up to 4 interrupt combiners (with each combiner supporting -up to 8 interrupt sources). - -Required properties: -- compatible: should be "samsung,exynos4210-combiner". -- interrupt-controller: Identifies the node as an interrupt controller. -- #interrupt-cells: should be <2>. The meaning of the cells are - * First Cell: Combiner Group Number. - * Second Cell: Interrupt number within the group. -- reg: Base address and size of interrupt combiner registers. -- interrupts: The list of interrupts generated by the combiners which are then - connected to a parent interrupt controller. The format of the interrupt - specifier depends in the interrupt parent controller. - -Optional properties: -- samsung,combiner-nr: The number of interrupt combiners supported. If this - property is not specified, the default number of combiners is assumed - to be 16. -- interrupt-parent: pHandle of the parent interrupt controller, if not - inherited from the parent node. - - -Example: - - The following is a an example from the Exynos4210 SoC dtsi file. - - combiner:interrupt-controller@10440000 { - compatible = "samsung,exynos4210-combiner"; - interrupt-controller; - #interrupt-cells = <2>; - reg = <0x10440000 0x1000>; - interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>, - <0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>, - <0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>, - <0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>; - }; diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt new file mode 100644 index 000000000..12129c011 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt @@ -0,0 +1,69 @@ +* Samsung's Exynos SoC based boards + +Required root node properties: + - compatible = should be one or more of the following. + - "samsung,monk" - for Exynos3250-based Samsung Simband board. + - "samsung,rinato" - for Exynos3250-based Samsung Gear2 board. + - "samsung,smdkv310" - for Exynos4210-based Samsung SMDKV310 eval board. + - "samsung,trats" - for Exynos4210-based Tizen Reference board. + - "samsung,universal_c210" - for Exynos4210-based Samsung board. + - "samsung,smdk4412", - for Exynos4412-based Samsung SMDK4412 eval board. + - "samsung,trats2" - for Exynos4412-based Tizen Reference board. + - "samsung,smdk5250" - for Exynos5250-based Samsung SMDK5250 eval board. + - "samsung,xyref5260" - for Exynos5260-based Samsung board. + - "samsung,smdk5410" - for Exynos5410-based Samsung SMDK5410 eval board. + - "samsung,smdk5420" - for Exynos5420-based Samsung SMDK5420 eval board. + - "samsung,sd5v1" - for Exynos5440-based Samsung board. + - "samsung,ssdk5440" - for Exynos5440-based Samsung board. + +* Other companies Exynos SoC based + * FriendlyARM + - "friendlyarm,tiny4412" - for Exynos4412-based FriendlyARM + TINY4412 board. + + * Google + - "google,pi" - for Exynos5800-based Google Peach Pi + Rev 10+ board, + also: "google,pi-rev16", "google,pi-rev15", "google,pi-rev14", + "google,pi-rev13", "google,pi-rev12", "google,pi-rev11", + "google,pi-rev10", "google,peach". + + - "google,pit" - for Exynos5420-based Google Peach Pit + Rev 6+ (Exynos5420), + also: "google,pit-rev16", "google,pit-rev15", "google,pit-rev14", + "google,pit-rev13", "google,pit-rev12", "google,pit-rev11", + "google,pit-rev10", "google,pit-rev9", "google,pit-rev8", + "google,pit-rev7", "google,pit-rev6", "google,peach". + + - "google,snow-rev4" - for Exynos5250-based Google Snow board, + also: "google,snow" + - "google,snow-rev5" - for Exynos5250-based Google Snow + Rev 5+ board. + - "google,spring" - for Exynos5250-based Google Spring board. + + * Hardkernel + - "hardkernel,odroid-u3" - for Exynos4412-based Hardkernel Odroid U3. + - "hardkernel,odroid-x" - for Exynos4412-based Hardkernel Odroid X. + - "hardkernel,odroid-x2" - for Exynos4412-based Hardkernel Odroid X2. + - "hardkernel,odroid-xu3" - for Exynos5422-based Hardkernel Odroid XU3. + - "hardkernel,odroid-xu3-lite" - for Exynos5422-based Hardkernel + Odroid XU3 Lite board. + - "hardkernel,odroid-xu4" - for Exynos5422-based Hardkernel Odroid XU4. + + * Insignal + - "insignal,arndale" - for Exynos5250-based Insignal Arndale board. + - "insignal,arndale-octa" - for Exynos5420-based Insignal Arndale + Octa board. + - "insignal,origen" - for Exynos4210-based Insignal Origen board. + - "insignal,origen4412 - for Exynos4412-based Insignal Origen board. + + +Optional nodes: + - firmware node, specifying presence and type of secure firmware: + - compatible: only "samsung,secure-firmware" is currently supported + - reg: address of non-secure SYSRAM used for communication with firmware + + firmware@0203F000 { + compatible = "samsung,secure-firmware"; + reg = <0x0203F000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt index c4f19b2e7..40bb9007c 100644 --- a/Documentation/devicetree/bindings/arm/shmobile.txt +++ b/Documentation/devicetree/bindings/arm/shmobile.txt @@ -39,8 +39,6 @@ Boards: compatible = "renesas,armadillo800eva" - BOCK-W compatible = "renesas,bockw", "renesas,r8a7778" - - BOCK-W - Reference Device Tree Implementation - compatible = "renesas,bockw-reference", "renesas,r8a7778" - Genmai (RTK772100BC00000BR) compatible = "renesas,genmai", "renesas,r7s72100" - Gose @@ -57,7 +55,7 @@ Boards: compatible = "renesas,lager", "renesas,r8a7790" - Marzen compatible = "renesas,marzen", "renesas,r8a7779" - -Note: Reference Device Tree Implementations are temporary implementations - to ease the migration from platform devices to Device Tree, and are - intended to be removed in the future. + - Porter (M2-LCDP) + compatible = "renesas,porter", "renesas,r8a7791" + - SILK (RTP0RC7794LCB00011S) + compatible = "renesas,silk", "renesas,r8a7794" diff --git a/Documentation/devicetree/bindings/arm/spear/shirq.txt b/Documentation/devicetree/bindings/arm/spear/shirq.txt deleted file mode 100644 index 715a013ed..000000000 --- a/Documentation/devicetree/bindings/arm/spear/shirq.txt +++ /dev/null @@ -1,48 +0,0 @@ -* SPEAr Shared IRQ layer (shirq) - -SPEAr3xx architecture includes shared/multiplexed irqs for certain set -of devices. The multiplexor provides a single interrupt to parent -interrupt controller (VIC) on behalf of a group of devices. - -There can be multiple groups available on SPEAr3xx variants but not -exceeding 4. The number of devices in a group can differ, further they -may share same set of status/mask registers spanning across different -bit masks. Also in some cases the group may not have enable or other -registers. This makes software little complex. - -A single node in the device tree is used to describe the shared -interrupt multiplexor (one node for all groups). A group in the -interrupt controller shares config/control registers with other groups. -For example, a 32-bit interrupt enable/disable config register can -accommodate up to 4 interrupt groups. - -Required properties: - - compatible: should be, either of - - "st,spear300-shirq" - - "st,spear310-shirq" - - "st,spear320-shirq" - - interrupt-controller: Identifies the node as an interrupt controller. - - #interrupt-cells: should be <1> which basically contains the offset - (starting from 0) of interrupts for all the groups. - - reg: Base address and size of shirq registers. - - interrupts: The list of interrupts generated by the groups which are - then connected to a parent interrupt controller. Each group is - associated with one of the interrupts, hence number of interrupts (to - parent) is equal to number of groups. The format of the interrupt - specifier depends in the interrupt parent controller. - - Optional properties: - - interrupt-parent: pHandle of the parent interrupt controller, if not - inherited from the parent node. - -Example: - -The following is an example from the SPEAr320 SoC dtsi file. - -shirq: interrupt-controller@0xb3000000 { - compatible = "st,spear320-shirq"; - reg = <0xb3000000 0x1000>; - interrupts = <28 29 30 1>; - #interrupt-cells = <1>; - interrupt-controller; -}; diff --git a/Documentation/devicetree/bindings/arm/sunxi.txt b/Documentation/devicetree/bindings/arm/sunxi.txt index 67da20539..bb9b0faa9 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.txt +++ b/Documentation/devicetree/bindings/arm/sunxi.txt @@ -6,6 +6,7 @@ using one of the following compatible strings: allwinner,sun4i-a10 allwinner,sun5i-a10s allwinner,sun5i-a13 + allwinner,sun5i-r8 allwinner,sun6i-a31 allwinner,sun7i-a20 allwinner,sun8i-a23 diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,nvec.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,nvec.txt new file mode 100644 index 000000000..5ae601e7f --- /dev/null +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,nvec.txt @@ -0,0 +1,21 @@ +NVIDIA compliant embedded controller + +Required properties: +- compatible : should be "nvidia,nvec". +- reg : the iomem of the i2c slave controller +- interrupts : the interrupt line of the i2c slave controller +- clock-frequency : the frequency of the i2c bus +- gpios : the gpio used for ec request +- slave-addr: the i2c address of the slave controller +- clocks : Must contain an entry for each entry in clock-names. + See ../clocks/clock-bindings.txt for details. +- clock-names : Must include the following entries: + Tegra20/Tegra30: + - div-clk + - fast-clk + Tegra114: + - div-clk +- resets : Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. +- reset-names : Must include the following entries: + - i2c diff --git a/Documentation/devicetree/bindings/arm/twd.txt b/Documentation/devicetree/bindings/arm/twd.txt index 75b861093..383ea19c2 100644 --- a/Documentation/devicetree/bindings/arm/twd.txt +++ b/Documentation/devicetree/bindings/arm/twd.txt @@ -19,6 +19,11 @@ interrupts. - reg : Specify the base address and the size of the TWD timer register window. +Optional + +- always-on : a boolean property. If present, the timer is powered through + an always-on power domain, therefore it never loses context. + Example: twd-timer@2c000600 { diff --git a/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt new file mode 100644 index 000000000..d27a646f4 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt @@ -0,0 +1,60 @@ +UniPhier outer cache controller + +UniPhier SoCs are integrated with a full-custom outer cache controller system. +All of them have a level 2 cache controller, and some have a level 3 cache +controller as well. + +Required properties: +- compatible: should be "socionext,uniphier-system-cache" +- reg: offsets and lengths of the register sets for the device. It should + contain 3 regions: control register, revision register, operation register, + in this order. +- cache-unified: specifies the cache is a unified cache. +- cache-size: specifies the size in bytes of the cache +- cache-sets: specifies the number of associativity sets of the cache +- cache-line-size: specifies the line size in bytes +- cache-level: specifies the level in the cache hierarchy. The value should + be 2 for L2 cache, 3 for L3 cache, etc. + +Optional properties: +- next-level-cache: phandle to the next level cache if present. The next level + cache should be also compatible with "socionext,uniphier-system-cache". + +The L2 cache must exist to use the L3 cache; the cache hierarchy must be +indicated correctly with "next-level-cache" properties. + +Example 1 (system with L2): + l2: l2-cache@500c0000 { + compatible = "socionext,uniphier-system-cache"; + reg = <0x500c0000 0x2000>, <0x503c0100 0x4>, + <0x506c0000 0x400>; + cache-unified; + cache-size = <0x80000>; + cache-sets = <256>; + cache-line-size = <128>; + cache-level = <2>; + }; + +Example 2 (system with L2 and L3): + l2: l2-cache@500c0000 { + compatible = "socionext,uniphier-system-cache"; + reg = <0x500c0000 0x2000>, <0x503c0100 0x8>, + <0x506c0000 0x400>; + cache-unified; + cache-size = <0x200000>; + cache-sets = <512>; + cache-line-size = <128>; + cache-level = <2>; + next-level-cache = <&l3>; + }; + + l3: l3-cache@500c8000 { + compatible = "socionext,uniphier-system-cache"; + reg = <0x500c8000 0x2000>, <0x503c8100 0x8>, + <0x506c8000 0x400>; + cache-unified; + cache-size = <0x400000>; + cache-sets = <512>; + cache-line-size = <256>; + cache-level = <3>; + }; diff --git a/Documentation/devicetree/bindings/arm/versatile-fpga-irq.txt b/Documentation/devicetree/bindings/arm/versatile-fpga-irq.txt deleted file mode 100644 index c9cf605bb..000000000 --- a/Documentation/devicetree/bindings/arm/versatile-fpga-irq.txt +++ /dev/null @@ -1,36 +0,0 @@ -* ARM Versatile FPGA interrupt controller - -One or more FPGA IRQ controllers can be synthesized in an ARM reference board -such as the Integrator or Versatile family. The output of these different -controllers are OR:ed together and fed to the CPU tile's IRQ input. Each -instance can handle up to 32 interrupts. - -Required properties: -- compatible: "arm,versatile-fpga-irq" -- interrupt-controller: Identifies the node as an interrupt controller -- #interrupt-cells: The number of cells to define the interrupts. Must be 1 - as the FPGA IRQ controller has no configuration options for interrupt - sources. The cell is a u32 and defines the interrupt number. -- reg: The register bank for the FPGA interrupt controller. -- clear-mask: a u32 number representing the mask written to clear all IRQs - on the controller at boot for example. -- valid-mask: a u32 number representing a bit mask determining which of - the interrupts are valid. Unconnected/unused lines are set to 0, and - the system till not make it possible for devices to request these - interrupts. - -Example: - -pic: pic@14000000 { - compatible = "arm,versatile-fpga-irq"; - #interrupt-cells = <1>; - interrupt-controller; - reg = <0x14000000 0x100>; - clear-mask = <0xffffffff>; - valid-mask = <0x003fffff>; -}; - -Optional properties: -- interrupts: if the FPGA IRQ controller is cascaded, i.e. if its IRQ - output is simply connected to the input of another IRQ controller, - then the parent IRQ shall be specified in this property. diff --git a/Documentation/devicetree/bindings/arm/vic.txt b/Documentation/devicetree/bindings/arm/vic.txt deleted file mode 100644 index dd527216c..000000000 --- a/Documentation/devicetree/bindings/arm/vic.txt +++ /dev/null @@ -1,41 +0,0 @@ -* ARM Vectored Interrupt Controller - -One or more Vectored Interrupt Controllers (VIC's) can be connected in an ARM -system for interrupt routing. For multiple controllers they can either be -nested or have the outputs wire-OR'd together. - -Required properties: - -- compatible : should be one of - "arm,pl190-vic" - "arm,pl192-vic" -- interrupt-controller : Identifies the node as an interrupt controller -- #interrupt-cells : The number of cells to define the interrupts. Must be 1 as - the VIC has no configuration options for interrupt sources. The cell is a u32 - and defines the interrupt number. -- reg : The register bank for the VIC. - -Optional properties: - -- interrupts : Interrupt source for parent controllers if the VIC is nested. -- valid-mask : A one cell big bit mask of valid interrupt sources. Each bit - represents single interrupt source, starting from source 0 at LSb and ending - at source 31 at MSb. A bit that is set means that the source is wired and - clear means otherwise. If unspecified, defaults to all valid. -- valid-wakeup-mask : A one cell big bit mask of interrupt sources that can be - configured as wake up source for the system. Order of bits is the same as for - valid-mask property. A set bit means that this interrupt source can be - configured as a wake up source for the system. If unspecied, defaults to all - interrupt sources configurable as wake up sources. - -Example: - - vic0: interrupt-controller@60000 { - compatible = "arm,pl192-vic"; - interrupt-controller; - #interrupt-cells = <1>; - reg = <0x60000 0x1000>; - - valid-mask = <0xffffff7f>; - valid-wakeup-mask = <0x0000ff7f>; - }; diff --git a/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-intc.txt b/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-intc.txt deleted file mode 100644 index 0a4ce1051..000000000 --- a/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-intc.txt +++ /dev/null @@ -1,16 +0,0 @@ -VIA/Wondermedia VT8500 Interrupt Controller ------------------------------------------------------ - -Required properties: -- compatible : "via,vt8500-intc" -- reg : Should contain 1 register ranges(address and length) -- #interrupt-cells : should be <1> - -Example: - - intc: interrupt-controller@d8140000 { - compatible = "via,vt8500-intc"; - interrupt-controller; - reg = <0xd8140000 0x10000>; - #interrupt-cells = <1>; - }; diff --git a/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt b/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt new file mode 100644 index 000000000..032a7606b --- /dev/null +++ b/Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt @@ -0,0 +1,21 @@ +Binding for Freescale QorIQ AHCI SATA Controller + +Required properties: + - reg: Physical base address and size of the controller's register area. + - compatible: Compatibility string. Must be 'fsl,-ahci', where + chip could be ls1021a, ls2080a, ls1043a etc. + - clocks: Input clock specifier. Refer to common clock bindings. + - interrupts: Interrupt specifier. Refer to interrupt binding. + +Optional properties: + - dma-coherent: Enable AHCI coherent DMA operation. + - reg-names: register area names when there are more than 1 register area. + +Examples: + sata@3200000 { + compatible = "fsl,ls1021a-ahci"; + reg = <0x0 0x3200000 0x0 0x10000>; + interrupts = ; + clocks = <&platform_clk 1>; + dma-coherent; + }; diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt b/Documentation/devicetree/bindings/ata/ahci-platform.txt index a2321819e..c2340eeeb 100644 --- a/Documentation/devicetree/bindings/ata/ahci-platform.txt +++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt @@ -16,8 +16,6 @@ Required properties: - "snps,dwc-ahci" - "snps,exynos5440-ahci" - "snps,spear-ahci" - - "fsl,qoriq-ahci" : for qoriq series socs which include ls1021, ls2085, etc. - - "fsl,-ahci" : chip could be ls1021, ls2085 etc. - "generic-ahci" - interrupts : - reg : diff --git a/Documentation/devicetree/bindings/board/fsl-board.txt b/Documentation/devicetree/bindings/board/fsl-board.txt new file mode 100644 index 000000000..fb7b03ec2 --- /dev/null +++ b/Documentation/devicetree/bindings/board/fsl-board.txt @@ -0,0 +1,112 @@ +Freescale Reference Board Bindings + +This document describes device tree bindings for various devices that +exist on some Freescale reference boards. + +* Board Control and Status (BCSR) + +Required properties: + + - compatible : Should be "fsl,-bcsr" + - reg : Offset and length of the register set for the device + +Example: + + bcsr@f8000000 { + compatible = "fsl,mpc8360mds-bcsr"; + reg = ; + }; + +* Freescale on-board FPGA + +This is the memory-mapped registers for on board FPGA. + +Required properties: +- compatible: should be a board-specific string followed by a string + indicating the type of FPGA. Example: + "fsl,-fpga", "fsl,fpga-pixis", or + "fsl,-fpga", "fsl,fpga-qixis" +- reg: should contain the address and the length of the FPGA register set. + +Optional properties: +- interrupt-parent: should specify phandle for the interrupt controller. +- interrupts: should specify event (wakeup) IRQ. + +Example (P1022DS): + + board-control@3,0 { + compatible = "fsl,p1022ds-fpga", "fsl,fpga-ngpixis"; + reg = <3 0 0x30>; + interrupt-parent = <&mpic>; + interrupts = <8 8 0 0>; + }; + +Example (LS2080A-RDB): + + cpld@3,0 { + compatible = "fsl,ls2080ardb-fpga", "fsl,fpga-qixis"; + reg = <0x3 0 0x10000>; + }; + +* Freescale BCSR GPIO banks + +Some BCSR registers act as simple GPIO controllers, each such +register can be represented by the gpio-controller node. + +Required properities: +- compatible : Should be "fsl,-bcsr-gpio". +- reg : Should contain the address and the length of the GPIO bank + register. +- #gpio-cells : Should be two. The first cell is the pin number and the + second cell is used to specify optional parameters (currently unused). +- gpio-controller : Marks the port as GPIO controller. + +Example: + + bcsr@1,0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "fsl,mpc8360mds-bcsr"; + reg = <1 0 0x8000>; + ranges = <0 1 0 0x8000>; + + bcsr13: gpio-controller@d { + #gpio-cells = <2>; + compatible = "fsl,mpc8360mds-bcsr-gpio"; + reg = <0xd 1>; + gpio-controller; + }; + }; + +* Freescale on-board FPGA connected on I2C bus + +Some Freescale boards like BSC9132QDS have on board FPGA connected on +the i2c bus. + +Required properties: +- compatible: Should be a board-specific string followed by a string + indicating the type of FPGA. Example: + "fsl,-fpga", "fsl,fpga-qixis-i2c" +- reg: Should contain the address of the FPGA + +Example: + fpga: fpga@66 { + compatible = "fsl,bsc9132qds-fpga", "fsl,fpga-qixis-i2c"; + reg = <0x66>; + }; + +* Freescale on-board CPLD + +Some Freescale boards like T1040RDB have an on board CPLD connected. + +Required properties: +- compatible: Should be a board-specific string like "fsl,-cpld" + Example: + "fsl,t1040rdb-cpld", "fsl,t1042rdb-cpld", "fsl,t1042rdb_pi-cpld" +- reg: should describe CPLD registers + +Example: + cpld@3,0 { + compatible = "fsl,t1040rdb-cpld"; + reg = <3 0 0x300>; + }; diff --git a/Documentation/devicetree/bindings/bus/sunxi-rsb.txt b/Documentation/devicetree/bindings/bus/sunxi-rsb.txt new file mode 100644 index 000000000..3dd28343b --- /dev/null +++ b/Documentation/devicetree/bindings/bus/sunxi-rsb.txt @@ -0,0 +1,47 @@ +Allwinner Reduced Serial Bus (RSB) controller + +The RSB controller found on later Allwinner SoCs is an SMBus like 2 wire +serial bus with 1 master and up to 15 slaves. It is represented by a node +for the controller itself, and child nodes representing the slave devices. + +Required properties : + + - reg : Offset and length of the register set for the controller. + - compatible : Shall be "allwinner,sun8i-a23-rsb". + - interrupts : The interrupt line associated to the RSB controller. + - clocks : The gate clk associated to the RSB controller. + - resets : The reset line associated to the RSB controller. + - #address-cells : shall be 1 + - #size-cells : shall be 0 + +Optional properties : + + - clock-frequency : Desired RSB bus clock frequency in Hz. Maximum is 20MHz. + If not set this defaults to 3MHz. + +Child nodes: + +An RSB controller node can contain zero or more child nodes representing +slave devices on the bus. Child 'reg' properties should contain the slave +device's hardware address. The hardware address is hardwired in the device, +which can normally be found in the datasheet. + +Example: + + rsb@01f03400 { + compatible = "allwinner,sun8i-a23-rsb"; + reg = <0x01f03400 0x400>; + interrupts = <0 39 4>; + clocks = <&apb0_gates 3>; + clock-frequency = <3000000>; + resets = <&apb0_rst 3>; + #address-cells = <1>; + #size-cells = <0>; + + pmic@3e3 { + compatible = "..."; + reg = <0x3e3>; + + /* ... */ + }; + }; diff --git a/Documentation/devicetree/bindings/c6x/interrupt.txt b/Documentation/devicetree/bindings/c6x/interrupt.txt deleted file mode 100644 index 42bb796cc..000000000 --- a/Documentation/devicetree/bindings/c6x/interrupt.txt +++ /dev/null @@ -1,104 +0,0 @@ -C6X Interrupt Chips -------------------- - -* C64X+ Core Interrupt Controller - - The core interrupt controller provides 16 prioritized interrupts to the - C64X+ core. Priority 0 and 1 are used for reset and NMI respectively. - Priority 2 and 3 are reserved. Priority 4-15 are used for interrupt - sources coming from outside the core. - - Required properties: - -------------------- - - compatible: Should be "ti,c64x+core-pic"; - - #interrupt-cells: <1> - - Interrupt Specifier Definition - ------------------------------ - Single cell specifying the core interrupt priority level (4-15) where - 4 is highest priority and 15 is lowest priority. - - Example - ------- - core_pic: interrupt-controller@0 { - interrupt-controller; - #interrupt-cells = <1>; - compatible = "ti,c64x+core-pic"; - }; - - - -* C64x+ Megamodule Interrupt Controller - - The megamodule PIC consists of four interrupt mupliplexers each of which - combine up to 32 interrupt inputs into a single interrupt output which - may be cascaded into the core interrupt controller. The megamodule PIC - has a total of 12 outputs cascading into the core interrupt controller. - One for each core interrupt priority level. In addition to the combined - interrupt sources, individual megamodule interrupts may be cascaded to - the core interrupt controller. When an individual interrupt is cascaded, - it is no longer handled through a megamodule interrupt combiner and is - considered to have the core interrupt controller as the parent. - - Required properties: - -------------------- - - compatible: "ti,c64x+megamod-pic" - - interrupt-controller - - #interrupt-cells: <1> - - reg: base address and size of register area - - interrupt-parent: must be core interrupt controller - - interrupts: This should have four cells; one for each interrupt combiner. - The cells contain the core priority interrupt to which the - corresponding combiner output is wired. - - Optional properties: - -------------------- - - ti,c64x+megamod-pic-mux: Array of 12 cells correspnding to the 12 core - priority interrupts. The first cell corresponds to - core priority 4 and the last cell corresponds to - core priority 15. The value of each cell is the - megamodule interrupt source which is MUXed to - the core interrupt corresponding to the cell - position. Allowed values are 4 - 127. Mapping for - interrupts 0 - 3 (combined interrupt sources) are - ignored. - - Interrupt Specifier Definition - ------------------------------ - Single cell specifying the megamodule interrupt source (4-127). Note that - interrupts mapped directly to the core with "ti,c64x+megamod-pic-mux" will - use the core interrupt controller as their parent and the specifier will - be the core priority level, not the megamodule interrupt number. - - Examples - -------- - megamod_pic: interrupt-controller@1800000 { - compatible = "ti,c64x+megamod-pic"; - interrupt-controller; - #interrupt-cells = <1>; - reg = <0x1800000 0x1000>; - interrupt-parent = <&core_pic>; - interrupts = < 12 13 14 15 >; - }; - - This is a minimal example where all individual interrupts go through a - combiner. Combiner-0 is mapped to core interrupt 12, combiner-1 is mapped - to interrupt 13, etc. - - - megamod_pic: interrupt-controller@1800000 { - compatible = "ti,c64x+megamod-pic"; - interrupt-controller; - #interrupt-cells = <1>; - reg = <0x1800000 0x1000>; - interrupt-parent = <&core_pic>; - interrupts = < 12 13 14 15 >; - ti,c64x+megamod-pic-mux = < 0 0 0 0 - 32 0 0 0 - 0 0 0 0 >; - }; - - This the same as the first example except that megamodule interrupt 32 is - mapped directly to core priority interrupt 8. The node using this interrupt - must set the core controller as its interrupt parent and use 8 in the - interrupt specifier value. diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt index ed838f453..6ae9d82d4 100644 --- a/Documentation/devicetree/bindings/chosen.txt +++ b/Documentation/devicetree/bindings/chosen.txt @@ -44,3 +44,11 @@ Implementation note: Linux will look for the property "linux,stdout-path" or on PowerPC "stdout" if "stdout-path" is not found. However, the "linux,stdout-path" and "stdout" properties are deprecated. New platforms should only use the "stdout-path" property. + +linux,booted-from-kexec +----------------------- + +This property is set (currently only on PowerPC, and only needed on +book3e) by some versions of kexec-tools to tell the new kernel that it +is being booted by kexec, as the booting environment may differ (e.g. +a different secondary CPU release mechanism) diff --git a/Documentation/devicetree/bindings/clock/at91-clock.txt b/Documentation/devicetree/bindings/clock/at91-clock.txt index 5ba645069..181bc8ac4 100644 --- a/Documentation/devicetree/bindings/clock/at91-clock.txt +++ b/Documentation/devicetree/bindings/clock/at91-clock.txt @@ -77,6 +77,9 @@ Required properties: "atmel,sama5d4-clk-h32mx": at91 h32mx clock + "atmel,sama5d2-clk-generated": + at91 generated clock + Required properties for SCKC node: - reg : defines the IO memory reserved for the SCKC. - #size-cells : shall be 0 (reg is used to encode clk id). @@ -461,3 +464,35 @@ For example: compatible = "atmel,sama5d4-clk-h32mx"; clocks = <&mck>; }; + +Required properties for generated clocks: +- #size-cells : shall be 0 (reg is used to encode clk id). +- #address-cells : shall be 1 (reg is used to encode clk id). +- clocks : shall be the generated clock source phandles. + e.g. clocks = <&clk32k>, <&main>, <&plladiv>, <&utmi>, <&mck>, <&audio_pll_pmc>; +- name: device tree node describing a specific generated clock. + * #clock-cells : from common clock binding; shall be set to 0. + * reg: peripheral id. See Atmel's datasheets to get a full + list of peripheral ids. + * atmel,clk-output-range : minimum and maximum clock frequency + (two u32 fields). + +For example: + gck { + compatible = "atmel,sama5d2-clk-generated"; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&clk32k>, <&main>, <&plladiv>, <&utmi>, <&mck>, <&audio_pll_pmc>; + + tcb0_gclk: tcb0_gclk { + #clock-cells = <0>; + reg = <35>; + atmel,clk-output-range = <0 83000000>; + }; + + pwm_gclk: pwm_gclk { + #clock-cells = <0>; + reg = <38>; + atmel,clk-output-range = <0 83000000>; + }; + }; diff --git a/Documentation/devicetree/bindings/clock/brcm,bcm2835-cprman.txt b/Documentation/devicetree/bindings/clock/brcm,bcm2835-cprman.txt new file mode 100644 index 000000000..e56a1df3a --- /dev/null +++ b/Documentation/devicetree/bindings/clock/brcm,bcm2835-cprman.txt @@ -0,0 +1,45 @@ +Broadcom BCM2835 CPRMAN clocks + +This binding uses the common clock binding: + Documentation/devicetree/bindings/clock/clock-bindings.txt + +The CPRMAN clock controller generates clocks in the audio power domain +of the BCM2835. There is a level of PLLs deriving from an external +oscillator, a level of PLL dividers that produce channels off of the +few PLLs, and a level of mostly-generic clock generators sourcing from +the PLL channels. Most other hardware components source from the +clock generators, but a few (like the ARM or HDMI) will source from +the PLL dividers directly. + +Required properties: +- compatible: Should be "brcm,bcm2835-cprman" +- #clock-cells: Should be <1>. The permitted clock-specifier values can be + found in include/dt-bindings/clock/bcm2835.h +- reg: Specifies base physical address and size of the registers +- clocks: The external oscillator clock phandle + +Example: + + clk_osc: clock@3 { + compatible = "fixed-clock"; + reg = <3>; + #clock-cells = <0>; + clock-output-names = "osc"; + clock-frequency = <19200000>; + }; + + clocks: cprman@7e101000 { + compatible = "brcm,bcm2835-cprman"; + #clock-cells = <1>; + reg = <0x7e101000 0x2000>; + clocks = <&clk_osc>; + }; + + i2c0: i2c@7e205000 { + compatible = "brcm,bcm2835-i2c"; + reg = <0x7e205000 0x1000>; + interrupts = <2 21>; + clocks = <&clocks BCM2835_CLOCK_VPU>; + #address-cells = <1>; + #size-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt index da8d9bb57..ede65a55e 100644 --- a/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt +++ b/Documentation/devicetree/bindings/clock/brcm,iproc-clocks.txt @@ -130,3 +130,81 @@ These clock IDs are defined in: ch3_unused mipipll 4 BCM_CYGNUS_MIPIPLL_CH3_UNUSED ch4_unused mipipll 5 BCM_CYGNUS_MIPIPLL_CH4_UNUSED ch5_unused mipipll 6 BCM_CYGNUS_MIPIPLL_CH5_UNUSED + +Northstar and Northstar Plus +------ +PLL and leaf clock compatible strings for Northstar and Northstar Plus are: + "brcm,nsp-armpll" + "brcm,nsp-genpll" + "brcm,nsp-lcpll0" + +The following table defines the set of PLL/clock index and ID for Northstar and +Northstar Plus. These clock IDs are defined in: + "include/dt-bindings/clock/bcm-nsp.h" + + Clock Source Index ID + --- ----- ----- --------- + crystal N/A N/A N/A + + armpll crystal N/A N/A + + genpll crystal 0 BCM_NSP_GENPLL + phy genpll 1 BCM_NSP_GENPLL_PHY_CLK + ethernetclk genpll 2 BCM_NSP_GENPLL_ENET_SW_CLK + usbclk genpll 3 BCM_NSP_GENPLL_USB_PHY_REF_CLK + iprocfast genpll 4 BCM_NSP_GENPLL_IPROCFAST_CLK + sata1 genpll 5 BCM_NSP_GENPLL_SATA1_CLK + sata2 genpll 6 BCM_NSP_GENPLL_SATA2_CLK + + lcpll0 crystal 0 BCM_NSP_LCPLL0 + pcie_phy lcpll0 1 BCM_NSP_LCPLL0_PCIE_PHY_REF_CLK + sdio lcpll0 2 BCM_NSP_LCPLL0_SDIO_CLK + ddr_phy lcpll0 3 BCM_NSP_LCPLL0_DDR_PHY_CLK + +Northstar 2 +----------- +PLL and leaf clock compatible strings for Northstar 2 are: + "brcm,ns2-genpll-scr" + "brcm,ns2-genpll-sw" + "brcm,ns2-lcpll-ddr" + "brcm,ns2-lcpll-ports" + +The following table defines the set of PLL/clock index and ID for Northstar 2. +These clock IDs are defined in: + "include/dt-bindings/clock/bcm-ns2.h" + + Clock Source Index ID + --- ----- ----- --------- + crystal N/A N/A N/A + + genpll_scr crystal 0 BCM_NS2_GENPLL_SCR + scr genpll_scr 1 BCM_NS2_GENPLL_SCR_SCR_CLK + fs genpll_scr 2 BCM_NS2_GENPLL_SCR_FS_CLK + audio_ref genpll_scr 3 BCM_NS2_GENPLL_SCR_AUDIO_CLK + ch3_unused genpll_scr 4 BCM_NS2_GENPLL_SCR_CH3_UNUSED + ch4_unused genpll_scr 5 BCM_NS2_GENPLL_SCR_CH4_UNUSED + ch5_unused genpll_scr 6 BCM_NS2_GENPLL_SCR_CH5_UNUSED + + genpll_sw crystal 0 BCM_NS2_GENPLL_SW + rpe genpll_sw 1 BCM_NS2_GENPLL_SW_RPE_CLK + 250 genpll_sw 2 BCM_NS2_GENPLL_SW_250_CLK + nic genpll_sw 3 BCM_NS2_GENPLL_SW_NIC_CLK + chimp genpll_sw 4 BCM_NS2_GENPLL_SW_CHIMP_CLK + port genpll_sw 5 BCM_NS2_GENPLL_SW_PORT_CLK + sdio genpll_sw 6 BCM_NS2_GENPLL_SW_SDIO_CLK + + lcpll_ddr crystal 0 BCM_NS2_LCPLL_DDR + pcie_sata_usb lcpll_ddr 1 BCM_NS2_LCPLL_DDR_PCIE_SATA_USB_CLK + ddr lcpll_ddr 2 BCM_NS2_LCPLL_DDR_DDR_CLK + ch2_unused lcpll_ddr 3 BCM_NS2_LCPLL_DDR_CH2_UNUSED + ch3_unused lcpll_ddr 4 BCM_NS2_LCPLL_DDR_CH3_UNUSED + ch4_unused lcpll_ddr 5 BCM_NS2_LCPLL_DDR_CH4_UNUSED + ch5_unused lcpll_ddr 6 BCM_NS2_LCPLL_DDR_CH5_UNUSED + + lcpll_ports crystal 0 BCM_NS2_LCPLL_PORTS + wan lcpll_ports 1 BCM_NS2_LCPLL_PORTS_WAN_CLK + rgmii lcpll_ports 2 BCM_NS2_LCPLL_PORTS_RGMII_CLK + ch2_unused lcpll_ports 3 BCM_NS2_LCPLL_PORTS_CH2_UNUSED + ch3_unused lcpll_ports 4 BCM_NS2_LCPLL_PORTS_CH3_UNUSED + ch4_unused lcpll_ports 5 BCM_NS2_LCPLL_PORTS_CH4_UNUSED + ch5_unused lcpll_ports 6 BCM_NS2_LCPLL_PORTS_CH5_UNUSED diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt b/Documentation/devicetree/bindings/clock/qcom,gcc.txt index 54c23f34f..152dfaab2 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt +++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt @@ -18,10 +18,14 @@ Required properties : - #clock-cells : shall contain 1 - #reset-cells : shall contain 1 +Optional properties : +- #power-domain-cells : shall contain 1 + Example: clock-controller@900000 { compatible = "qcom,gcc-msm8960"; reg = <0x900000 0x4000>; #clock-cells = <1>; #reset-cells = <1>; + #power-domain-cells = <1>; }; diff --git a/Documentation/devicetree/bindings/clock/qcom,mmcc.txt b/Documentation/devicetree/bindings/clock/qcom,mmcc.txt index 29ebf84d2..34e7614d5 100644 --- a/Documentation/devicetree/bindings/clock/qcom,mmcc.txt +++ b/Documentation/devicetree/bindings/clock/qcom,mmcc.txt @@ -14,10 +14,14 @@ Required properties : - #clock-cells : shall contain 1 - #reset-cells : shall contain 1 +Optional properties : +- #power-domain-cells : shall contain 1 + Example: clock-controller@4000000 { compatible = "qcom,mmcc-msm8960"; reg = <0x4000000 0x1000>; #clock-cells = <1>; #reset-cells = <1>; + #power-domain-cells = <1>; }; diff --git a/Documentation/devicetree/bindings/clock/qoriq-clock.txt b/Documentation/devicetree/bindings/clock/qoriq-clock.txt index df4a259a6..16a3ec433 100644 --- a/Documentation/devicetree/bindings/clock/qoriq-clock.txt +++ b/Documentation/devicetree/bindings/clock/qoriq-clock.txt @@ -1,6 +1,6 @@ * Clock Block on Freescale QorIQ Platforms -Freescale qoriq chips take primary clocking input from the external +Freescale QorIQ chips take primary clocking input from the external SYSCLK signal. The SYSCLK input (frequency) is multiplied using multiple phase locked loops (PLL) to create a variety of frequencies which can then be passed to a variety of internal logic, including @@ -13,14 +13,16 @@ which the chip complies. Chassis Version Example Chips --------------- ------------- 1.0 p4080, p5020, p5040 -2.0 t4240, b4860, t1040 +2.0 t4240, b4860 1. Clock Block Binding Required properties: -- compatible: Should contain a specific clock block compatible string - and a single chassis clock compatible string. - Clock block strings include, but not limited to, one of the: +- compatible: Should contain a chip-specific clock block compatible + string and (if applicable) may contain a chassis-version clock + compatible string. + + Chip-specific strings are of the form "fsl,-clockgen", such as: * "fsl,p2041-clockgen" * "fsl,p3041-clockgen" * "fsl,p4080-clockgen" @@ -30,15 +32,14 @@ Required properties: * "fsl,b4420-clockgen" * "fsl,b4860-clockgen" * "fsl,ls1021a-clockgen" - Chassis clock strings include: + Chassis-version clock strings include: * "fsl,qoriq-clockgen-1.0": for chassis 1.0 clocks * "fsl,qoriq-clockgen-2.0": for chassis 2.0 clocks - reg: Describes the address of the device's resources within the address space defined by its parent bus, and resource zero represents the clock register set -- clock-frequency: Input system clock frequency -Recommended properties: +Optional properties: - ranges: Allows valid translation between child's address space and parent's. Must be present if the device has sub-nodes. - #address-cells: Specifies the number of cells used to represent @@ -47,8 +48,46 @@ Recommended properties: - #size-cells: Specifies the number of cells used to represent the size of an address. Must be present if the device has sub-nodes and set to 1 if present +- clock-frequency: Input system clock frequency (SYSCLK) +- clocks: If clock-frequency is not specified, sysclk may be provided + as an input clock. Either clock-frequency or clocks must be + provided. + +2. Clock Provider + +The clockgen node should act as a clock provider, though in older device +trees the children of the clockgen node are the clock providers. + +When the clockgen node is a clock provider, #clock-cells = <2>. +The first cell of the clock specifier is the clock type, and the +second cell is the clock index for the specified type. + + Type# Name Index Cell + 0 sysclk must be 0 + 1 cmux index (n in CLKCnCSR) + 2 hwaccel index (n in CLKCGnHWACSR) + 3 fman 0 for fm1, 1 for fm2 + 4 platform pll 0=pll, 1=pll/2, 2=pll/3, 3=pll/4 + +3. Example + + clockgen: global-utilities@e1000 { + compatible = "fsl,p5020-clockgen", "fsl,qoriq-clockgen-1.0"; + clock-frequency = <133333333>; + reg = <0xe1000 0x1000>; + #clock-cells = <2>; + }; + + fman@400000 { + ... + clocks = <&clockgen 3 0>; + ... + }; +} +4. Legacy Child Nodes -2. Clock Provider/Consumer Binding +NOTE: These nodes are deprecated. Kernels should continue to support +device trees with these nodes, but new device trees should not use them. Most of the bindings are from the common clock binding[1]. [1] Documentation/devicetree/bindings/clock/clock-bindings.txt @@ -82,7 +121,7 @@ Recommended properties: - reg: Should be the offset and length of clock block base address. The length should be 4. -Example for clock block and clock provider: +Legacy Example: / { clockgen: global-utilities@e1000 { compatible = "fsl,p5020-clockgen", "fsl,qoriq-clockgen-1.0"; @@ -142,7 +181,7 @@ Example for clock block and clock provider: }; }; -Example for clock consumer: +Example for legacy clock consumer: / { cpu0: PowerPC,e5500@0 { diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clocks.txt b/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clocks.txt index 5ddb68418..38dcf0370 100644 --- a/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clocks.txt +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clocks.txt @@ -1,7 +1,7 @@ * Renesas CPG DIV6 Clock The CPG DIV6 clocks are variable factor clocks provided by the Clock Pulse -Generator (CPG). They clock input is divided by a configurable factor from 1 +Generator (CPG). Their clock input is divided by a configurable factor from 1 to 64. Required Properties: diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt new file mode 100644 index 000000000..59297d34b --- /dev/null +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt @@ -0,0 +1,69 @@ +* Renesas Clock Pulse Generator / Module Standby and Software Reset + +On Renesas ARM SoCs (SH/R-Mobile, R-Car, RZ), the CPG (Clock Pulse Generator) +and MSSR (Module Standby and Software Reset) blocks are intimately connected, +and share the same register block. + +They provide the following functionalities: + - The CPG block generates various core clocks, + - The MSSR block provides two functions: + 1. Module Standby, providing a Clock Domain to control the clock supply + to individual SoC devices, + 2. Reset Control, to perform a software reset of individual SoC devices. + +Required Properties: + - compatible: Must be one of: + - "renesas,r8a7795-cpg-mssr" for the r8a7795 SoC + + - reg: Base address and length of the memory resource used by the CPG/MSSR + block + + - clocks: References to external parent clocks, one entry for each entry in + clock-names + - clock-names: List of external parent clock names. Valid names are: + - "extal" (r8a7795) + - "extalr" (r8a7795) + + - #clock-cells: Must be 2 + - For CPG core clocks, the two clock specifier cells must be "CPG_CORE" + and a core clock reference, as defined in + . + - For module clocks, the two clock specifier cells must be "CPG_MOD" and + a module number, as defined in the datasheet. + + - #power-domain-cells: Must be 0 + - SoC devices that are part of the CPG/MSSR Clock Domain and can be + power-managed through Module Standby should refer to the CPG device + node in their "power-domains" property, as documented by the generic PM + Domain bindings in + Documentation/devicetree/bindings/power/power_domain.txt. + + +Examples +-------- + + - CPG device node: + + cpg: clock-controller@e6150000 { + compatible = "renesas,r8a7795-cpg-mssr"; + reg = <0 0xe6150000 0 0x1000>; + clocks = <&extal_clk>, <&extalr_clk>; + clock-names = "extal", "extalr"; + #clock-cells = <2>; + #power-domain-cells = <0>; + }; + + + - CPG/MSSR Clock Domain member device node: + + scif2: serial@e6e88000 { + compatible = "renesas,scif-r8a7795", "renesas,scif"; + reg = <0 0xe6e88000 0 64>; + interrupts = ; + clocks = <&cpg CPG_MOD 310>; + clock-names = "sci_ick"; + dmas = <&dmac1 0x13>, <&dmac1 0x12>; + dma-names = "tx", "rx"; + power-domains = <&cpg>; + status = "disabled"; + }; diff --git a/Documentation/devicetree/bindings/clock/silabs,si514.txt b/Documentation/devicetree/bindings/clock/silabs,si514.txt new file mode 100644 index 000000000..ea1a9dbc6 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/silabs,si514.txt @@ -0,0 +1,24 @@ +Binding for Silicon Labs 514 programmable I2C clock generator. + +Reference +This binding uses the common clock binding[1]. Details about the device can be +found in the datasheet[2]. + +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt +[2] Si514 datasheet + http://www.silabs.com/Support%20Documents/TechnicalDocs/si514.pdf + +Required properties: + - compatible: Shall be "silabs,si514" + - reg: I2C device address. + - #clock-cells: From common clock bindings: Shall be 0. + +Optional properties: + - clock-output-names: From common clock bindings. Recommended to be "si514". + +Example: + si514: clock-generator@55 { + reg = <0x55>; + #clock-cells = <0>; + compatible = "silabs,si514"; + }; diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt b/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt index d8b168ebd..844b3a097 100644 --- a/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt @@ -23,6 +23,7 @@ Required properties: "st,stih407-plls-c32-a9", "st,clkgen-plls-c32" "sst,plls-c32-cx_0", "st,clkgen-plls-c32" "sst,plls-c32-cx_1", "st,clkgen-plls-c32" + "st,stih418-plls-c28-a9", "st,clkgen-plls-c32" "st,stih415-gpu-pll-c32", "st,clkgengpu-pll-c32" "st,stih416-gpu-pll-c32", "st,clkgengpu-pll-c32" diff --git a/Documentation/devicetree/bindings/cris/interrupts.txt b/Documentation/devicetree/bindings/cris/interrupts.txt deleted file mode 100644 index e8b123b0a..000000000 --- a/Documentation/devicetree/bindings/cris/interrupts.txt +++ /dev/null @@ -1,23 +0,0 @@ -* CRISv32 Interrupt Controller - -Interrupt controller for the CRISv32 SoCs. - -Main node required properties: - -- compatible : should be: - "axis,crisv32-intc" -- interrupt-controller : Identifies the node as an interrupt controller -- #interrupt-cells : Specifies the number of cells needed to encode an - interrupt source. The type shall be a and the value shall be 1. -- reg: physical base address and size of the intc registers map. - -Example: - - intc: interrupt-controller { - compatible = "axis,crisv32-intc"; - reg = <0xb001c000 0x1000>; - interrupt-controller; - #interrupt-cells = <1>; - }; - - diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt index 6831d025e..adeca34c5 100644 --- a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt +++ b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt @@ -441,7 +441,7 @@ EXAMPLE: regmap = <&snvs>; interrupts = <0 4 0x4> linux,keycode = <116>; /* KEY_POWER */ - wakeup; + wakeup-source; }; ===================================================================== @@ -530,7 +530,7 @@ FULL EXAMPLE regmap = <&sec_mon>; interrupts = <0 4 0x4>; linux,keycode = <116>; /* KEY_POWER */ - wakeup; + wakeup-source; }; }; diff --git a/Documentation/devicetree/bindings/display/arm,pl11x.txt b/Documentation/devicetree/bindings/display/arm,pl11x.txt new file mode 100644 index 000000000..3e3039a8a --- /dev/null +++ b/Documentation/devicetree/bindings/display/arm,pl11x.txt @@ -0,0 +1,109 @@ +* ARM PrimeCell Color LCD Controller PL110/PL111 + +See also Documentation/devicetree/bindings/arm/primecell.txt + +Required properties: + +- compatible: must be one of: + "arm,pl110", "arm,primecell" + "arm,pl111", "arm,primecell" + +- reg: base address and size of the control registers block + +- interrupt-names: either the single entry "combined" representing a + combined interrupt output (CLCDINTR), or the four entries + "mbe", "vcomp", "lnbu", "fuf" representing the individual + CLCDMBEINTR, CLCDVCOMPINTR, CLCDLNBUINTR, CLCDFUFINTR interrupts + +- interrupts: contains an interrupt specifier for each entry in + interrupt-names + +- clock-names: should contain "clcdclk" and "apb_pclk" + +- clocks: contains phandle and clock specifier pairs for the entries + in the clock-names property. See + Documentation/devicetree/binding/clock/clock-bindings.txt + +Optional properties: + +- memory-region: phandle to a node describing memory (see + Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt) + to be used for the framebuffer; if not present, the framebuffer + may be located anywhere in the memory + +- max-memory-bandwidth: maximum bandwidth in bytes per second that the + cell's memory interface can handle; if not present, the memory + interface is fast enough to handle all possible video modes + +Required sub-nodes: + +- port: describes LCD panel signals, following the common binding + for video transmitter interfaces; see + Documentation/devicetree/bindings/media/video-interfaces.txt; + when it is a TFT panel, the port's endpoint must define the + following property: + + - arm,pl11x,tft-r0g0b0-pads: an array of three 32-bit values, + defining the way CLD pads are wired up; first value + contains index of the "CLD" external pin (pad) used + as R0 (first bit of the red component), second value + index of the pad used as G0, third value index of the + pad used as B0, see also "LCD panel signal multiplexing + details" paragraphs in the PL110/PL111 Technical + Reference Manuals; this implicitly defines available + color modes, for example: + - PL111 TFT 4:4:4 panel: + arm,pl11x,tft-r0g0b0-pads = <4 15 20>; + - PL110 TFT (1:)5:5:5 panel: + arm,pl11x,tft-r0g0b0-pads = <1 7 13>; + - PL111 TFT (1:)5:5:5 panel: + arm,pl11x,tft-r0g0b0-pads = <3 11 19>; + - PL111 TFT 5:6:5 panel: + arm,pl11x,tft-r0g0b0-pads = <3 10 19>; + - PL110 and PL111 TFT 8:8:8 panel: + arm,pl11x,tft-r0g0b0-pads = <0 8 16>; + - PL110 and PL111 TFT 8:8:8 panel, R & B components swapped: + arm,pl11x,tft-r0g0b0-pads = <16 8 0>; + + +Example: + + clcd@10020000 { + compatible = "arm,pl111", "arm,primecell"; + reg = <0x10020000 0x1000>; + interrupt-names = "combined"; + interrupts = <0 44 4>; + clocks = <&oscclk1>, <&oscclk2>; + clock-names = "clcdclk", "apb_pclk"; + max-memory-bandwidth = <94371840>; /* Bps, 1024x768@60 16bpp */ + + port { + clcd_pads: endpoint { + remote-endpoint = <&clcd_panel>; + arm,pl11x,tft-r0g0b0-pads = <0 8 16>; + }; + }; + + }; + + panel { + compatible = "panel-dpi"; + + port { + clcd_panel: endpoint { + remote-endpoint = <&clcd_pads>; + }; + }; + + panel-timing { + clock-frequency = <25175000>; + hactive = <640>; + hback-porch = <40>; + hfront-porch = <24>; + hsync-len = <96>; + vactive = <480>; + vback-porch = <32>; + vfront-porch = <11>; + vsync-len = <2>; + }; + }; diff --git a/Documentation/devicetree/bindings/display/armada/marvell,dove-lcd.txt b/Documentation/devicetree/bindings/display/armada/marvell,dove-lcd.txt new file mode 100644 index 000000000..46525ea3e --- /dev/null +++ b/Documentation/devicetree/bindings/display/armada/marvell,dove-lcd.txt @@ -0,0 +1,30 @@ +Device Tree bindings for Armada DRM CRTC driver + +Required properties: + - compatible: value should be "marvell,dove-lcd". + - reg: base address and size of the LCD controller + - interrupts: single interrupt number for the LCD controller + - port: video output port with endpoints, as described by graph.txt + +Optional properties: + + - clocks: as described by clock-bindings.txt + - clock-names: as described by clock-bindings.txt + "axiclk" - axi bus clock for pixel clock + "plldivider" - pll divider clock for pixel clock + "ext_ref_clk0" - external clock 0 for pixel clock + "ext_ref_clk1" - external clock 1 for pixel clock + +Note: all clocks are optional but at least one must be specified. +Further clocks may be added in the future according to requirements of +different SoCs. + +Example: + + lcd0: lcd-controller@820000 { + compatible = "marvell,dove-lcd"; + reg = <0x820000 0x1000>; + interrupts = <47>; + clocks = <&si5351 0>; + clock-names = "ext_ref_clk_1"; + }; diff --git a/Documentation/devicetree/bindings/display/atmel,lcdc.txt b/Documentation/devicetree/bindings/display/atmel,lcdc.txt new file mode 100644 index 000000000..ecb8da063 --- /dev/null +++ b/Documentation/devicetree/bindings/display/atmel,lcdc.txt @@ -0,0 +1,89 @@ +Atmel LCDC Framebuffer +----------------------------------------------------- + +Required properties: +- compatible : + "atmel,at91sam9261-lcdc" , + "atmel,at91sam9263-lcdc" , + "atmel,at91sam9g10-lcdc" , + "atmel,at91sam9g45-lcdc" , + "atmel,at91sam9g45es-lcdc" , + "atmel,at91sam9rl-lcdc" , + "atmel,at32ap-lcdc" +- reg : Should contain 1 register ranges(address and length). + Can contain an additional register range(address and length) + for fixed framebuffer memory. Useful for dedicated memories. +- interrupts : framebuffer controller interrupt +- display: a phandle pointing to the display node + +Required nodes: +- display: a display node is required to initialize the lcd panel + This should be in the board dts. +- default-mode: a videomode within the display with timing parameters + as specified below. + +Optional properties: +- lcd-supply: Regulator for LCD supply voltage. + +Example: + + fb0: fb@0x00500000 { + compatible = "atmel,at91sam9g45-lcdc"; + reg = <0x00500000 0x1000>; + interrupts = <23 3 0>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_fb>; + display = <&display0>; + status = "okay"; + #address-cells = <1>; + #size-cells = <1>; + + }; + +Example for fixed framebuffer memory: + + fb0: fb@0x00500000 { + compatible = "atmel,at91sam9263-lcdc"; + reg = <0x00700000 0x1000 0x70000000 0x200000>; + [...] + }; + +Atmel LCDC Display +----------------------------------------------------- +Required properties (as per of_videomode_helper): + + - atmel,dmacon: dma controller configuration + - atmel,lcdcon2: lcd controller configuration + - atmel,guard-time: lcd guard time (Delay in frame periods) + - bits-per-pixel: lcd panel bit-depth. + +Optional properties (as per of_videomode_helper): + - atmel,lcdcon-backlight: enable backlight + - atmel,lcdcon-backlight-inverted: invert backlight PWM polarity + - atmel,lcd-wiring-mode: lcd wiring mode "RGB" or "BRG" + - atmel,power-control-gpio: gpio to power on or off the LCD (as many as needed) + +Example: + display0: display { + bits-per-pixel = <32>; + atmel,lcdcon-backlight; + atmel,dmacon = <0x1>; + atmel,lcdcon2 = <0x80008002>; + atmel,guard-time = <9>; + atmel,lcd-wiring-mode = <1>; + + display-timings { + native-mode = <&timing0>; + timing0: timing0 { + clock-frequency = <9000000>; + hactive = <480>; + vactive = <272>; + hback-porch = <1>; + hfront-porch = <1>; + vback-porch = <40>; + vfront-porch = <1>; + hsync-len = <45>; + vsync-len = <1>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt b/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt new file mode 100644 index 000000000..ebc1a914b --- /dev/null +++ b/Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt @@ -0,0 +1,53 @@ +Device-Tree bindings for Atmel's HLCDC (High LCD Controller) DRM driver + +The Atmel HLCDC Display Controller is subdevice of the HLCDC MFD device. +See ../mfd/atmel-hlcdc.txt for more details. + +Required properties: + - compatible: value should be "atmel,hlcdc-display-controller" + - pinctrl-names: the pin control state names. Should contain "default". + - pinctrl-0: should contain the default pinctrl states. + - #address-cells: should be set to 1. + - #size-cells: should be set to 0. + +Required children nodes: + Children nodes are encoding available output ports and their connections + to external devices using the OF graph reprensentation (see ../graph.txt). + At least one port node is required. + +Example: + + hlcdc: hlcdc@f0030000 { + compatible = "atmel,sama5d3-hlcdc"; + reg = <0xf0030000 0x2000>; + interrupts = <36 IRQ_TYPE_LEVEL_HIGH 0>; + clocks = <&lcdc_clk>, <&lcdck>, <&clk32k>; + clock-names = "periph_clk","sys_clk", "slow_clk"; + status = "disabled"; + + hlcdc-display-controller { + compatible = "atmel,hlcdc-display-controller"; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_lcd_base &pinctrl_lcd_rgb888>; + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0>; + + hlcdc_panel_output: endpoint@0 { + reg = <0>; + remote-endpoint = <&panel_input>; + }; + }; + }; + + hlcdc_pwm: hlcdc-pwm { + compatible = "atmel,hlcdc-pwm"; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_lcd_pwm>; + #pwm-cells = <3>; + }; + }; diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt new file mode 100644 index 000000000..56a961aa5 --- /dev/null +++ b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt @@ -0,0 +1,65 @@ +Broadcom VC4 (VideoCore4) GPU + +The VC4 device present on the Raspberry Pi includes a display system +with HDMI output and the HVS (Hardware Video Scaler) for compositing +display planes. + +Required properties for VC4: +- compatible: Should be "brcm,bcm2835-vc4" + +Required properties for Pixel Valve: +- compatible: Should be one of "brcm,bcm2835-pixelvalve0", + "brcm,bcm2835-pixelvalve1", or "brcm,bcm2835-pixelvalve2" +- reg: Physical base address and length of the PV's registers +- interrupts: The interrupt number + See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt + +Required properties for HVS: +- compatible: Should be "brcm,bcm2835-hvs" +- reg: Physical base address and length of the HVS's registers +- interrupts: The interrupt number + See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt + +Required properties for HDMI +- compatible: Should be "brcm,bcm2835-hdmi" +- reg: Physical base address and length of the two register ranges + ("HDMI" and "HD", in that order) +- interrupts: The interrupt numbers + See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt +- ddc: phandle of the I2C controller used for DDC EDID probing +- clocks: a) hdmi: The HDMI state machine clock + b) pixel: The pixel clock. + +Optional properties for HDMI: +- hpd-gpios: The GPIO pin for HDMI hotplug detect (if it doesn't appear + as an interrupt/status bit in the HDMI controller + itself). See bindings/pinctrl/brcm,bcm2835-gpio.txt + +Example: +pixelvalve@7e807000 { + compatible = "brcm,bcm2835-pixelvalve2"; + reg = <0x7e807000 0x100>; + interrupts = <2 10>; /* pixelvalve */ +}; + +hvs@7e400000 { + compatible = "brcm,bcm2835-hvs"; + reg = <0x7e400000 0x6000>; + interrupts = <2 1>; +}; + +hdmi: hdmi@7e902000 { + compatible = "brcm,bcm2835-hdmi"; + reg = <0x7e902000 0x600>, + <0x7e808000 0x100>; + interrupts = <2 8>, <2 9>; + ddc = <&i2c2>; + hpd-gpios = <&gpio 46 GPIO_ACTIVE_HIGH>; + clocks = <&clocks BCM2835_PLLH_PIX>, + <&clocks BCM2835_CLOCK_HSM>; + clock-names = "pixel", "hdmi"; +}; + +vc4: gpu { + compatible = "brcm,bcm2835-vc4"; +}; diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7123.txt b/Documentation/devicetree/bindings/display/bridge/adi,adv7123.txt new file mode 100644 index 000000000..a6b2b2b8f --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7123.txt @@ -0,0 +1,50 @@ +Analog Device ADV7123 Video DAC +------------------------------- + +The ADV7123 is a digital-to-analog converter that outputs VGA signals from a +parallel video input. + +Required properties: + +- compatible: Should be "adi,adv7123" + +Optional properties: + +- psave-gpios: Power save control GPIO + +Required nodes: + +The ADV7123 has two video ports. Their connections are modeled using the OF +graph bindings specified in Documentation/devicetree/bindings/graph.txt. + +- Video port 0 for DPI input +- Video port 1 for VGA output + + +Example +------- + + adv7123: encoder@0 { + compatible = "adi,adv7123"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + adv7123_in: endpoint@0 { + remote-endpoint = <&dpi_out>; + }; + }; + + port@1 { + reg = <1>; + + adv7123_out: endpoint@0 { + remote-endpoint = <&vga_connector_in>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt new file mode 100644 index 000000000..96c25ee01 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt @@ -0,0 +1,88 @@ +Analog Device ADV7511(W)/13 HDMI Encoders +----------------------------------------- + +The ADV7511, ADV7511W and ADV7513 are HDMI audio and video transmitters +compatible with HDMI 1.4 and DVI 1.0. They support color space conversion, +S/PDIF, CEC and HDCP. + +Required properties: + +- compatible: Should be one of "adi,adv7511", "adi,adv7511w" or "adi,adv7513" +- reg: I2C slave address + +The ADV7511 supports a large number of input data formats that differ by their +color depth, color format, clock mode, bit justification and random +arrangement of components on the data bus. The combination of the following +properties describe the input and map directly to the video input tables of the +ADV7511 datasheet that document all the supported combinations. + +- adi,input-depth: Number of bits per color component at the input (8, 10 or + 12). +- adi,input-colorspace: The input color space, one of "rgb", "yuv422" or + "yuv444". +- adi,input-clock: The input clock type, one of "1x" (one clock cycle per + pixel), "2x" (two clock cycles per pixel), "ddr" (one clock cycle per pixel, + data driven on both edges). + +The following input format properties are required except in "rgb 1x" and +"yuv444 1x" modes, in which case they must not be specified. + +- adi,input-style: The input components arrangement variant (1, 2 or 3), as + listed in the input format tables in the datasheet. +- adi,input-justification: The input bit justification ("left", "evenly", + "right"). + +Optional properties: + +- interrupts: Specifier for the ADV7511 interrupt +- pd-gpios: Specifier for the GPIO connected to the power down signal + +- adi,clock-delay: Video data clock delay relative to the pixel clock, in ps + (-1200 ps .. 1600 ps). Defaults to no delay. +- adi,embedded-sync: The input uses synchronization signals embedded in the + data stream (similar to BT.656). Defaults to separate H/V synchronization + signals. + +Required nodes: + +The ADV7511 has two video ports. Their connections are modelled using the OF +graph bindings specified in Documentation/devicetree/bindings/graph.txt. + +- Video port 0 for the RGB or YUV input +- Video port 1 for the HDMI output + + +Example +------- + + adv7511w: hdmi@39 { + compatible = "adi,adv7511w"; + reg = <39>; + interrupt-parent = <&gpio3>; + interrupts = <29 IRQ_TYPE_EDGE_FALLING>; + + adi,input-depth = <8>; + adi,input-colorspace = "rgb"; + adi,input-clock = "1x"; + adi,input-style = <1>; + adi,input-justification = "evenly"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + adv7511w_in: endpoint { + remote-endpoint = <&dpi_out>; + }; + }; + + port@1 { + reg = <1>; + adv7511_out: endpoint { + remote-endpoint = <&hdmi_connector_in>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt b/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt new file mode 100644 index 000000000..dc1452f0d --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt @@ -0,0 +1,50 @@ +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 +- 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>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/bridge/ps8622.txt b/Documentation/devicetree/bindings/display/bridge/ps8622.txt new file mode 100644 index 000000000..c989c3807 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/ps8622.txt @@ -0,0 +1,31 @@ +ps8622-bridge bindings + +Required properties: + - compatible: "parade,ps8622" or "parade,ps8625" + - reg: first i2c address of the bridge + - sleep-gpios: OF device-tree gpio specification for PD_ pin. + - reset-gpios: OF device-tree gpio specification for RST_ pin. + +Optional properties: + - lane-count: number of DP lanes to use + - use-external-pwm: backlight will be controlled by an external PWM + - video interfaces: Device node can contain video interface port + nodes for panel according to [1]. + +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt + +Example: + lvds-bridge@48 { + compatible = "parade,ps8622"; + reg = <0x48>; + sleep-gpios = <&gpc3 6 1 0 0>; + reset-gpios = <&gpc3 1 1 0 0>; + lane-count = <1>; + ports { + port@0 { + bridge_out: endpoint { + remote-endpoint = <&panel_in>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/bridge/ptn3460.txt b/Documentation/devicetree/bindings/display/bridge/ptn3460.txt new file mode 100644 index 000000000..361971ba1 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/ptn3460.txt @@ -0,0 +1,39 @@ +ptn3460 bridge bindings + +Required properties: + - compatible: "nxp,ptn3460" + - reg: i2c address of the bridge + - powerdown-gpio: OF device-tree gpio specification for PD_N pin. + - reset-gpio: OF device-tree gpio specification for RST_N pin. + - edid-emulation: The EDID emulation entry to use + +-------+------------+------------------+ + | Value | Resolution | Description | + | 0 | 1024x768 | NXP Generic | + | 1 | 1920x1080 | NXP Generic | + | 2 | 1920x1080 | NXP Generic | + | 3 | 1600x900 | Samsung LTM200KT | + | 4 | 1920x1080 | Samsung LTM230HT | + | 5 | 1366x768 | NXP Generic | + | 6 | 1600x900 | ChiMei M215HGE | + +-------+------------+------------------+ + + - video interfaces: Device node can contain video interface port + nodes for panel according to [1]. + +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt + +Example: + lvds-bridge@20 { + compatible = "nxp,ptn3460"; + reg = <0x20>; + powerdown-gpio = <&gpy2 5 1 0 0>; + reset-gpio = <&gpx1 5 1 0 0>; + edid-emulation = <5>; + ports { + port@0 { + bridge_out: endpoint { + remote-endpoint = <&panel_in>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/bridge/tda998x.txt b/Documentation/devicetree/bindings/display/bridge/tda998x.txt new file mode 100644 index 000000000..e9e4bce40 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/tda998x.txt @@ -0,0 +1,29 @@ +Device-Tree bindings for the NXP TDA998x HDMI transmitter + +Required properties; + - compatible: must be "nxp,tda998x" + + - reg: I2C address + +Optional properties: + - interrupts: interrupt number and trigger type + default: polling + + - pinctrl-0: pin control group to be used for + screen plug/unplug interrupt. + + - pinctrl-names: must contain a "default" entry. + + - video-ports: 24 bits value which defines how the video controller + output is wired to the TDA998x input - default: <0x230145> + +Example: + + tda998x: hdmi-encoder { + compatible = "nxp,tda998x"; + reg = <0x70>; + interrupt-parent = <&gpio0>; + interrupts = <27 2>; /* falling edge */ + pinctrl-0 = <&pmx_camera>; + pinctrl-names = "default"; + }; diff --git a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt new file mode 100644 index 000000000..527e236e9 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvdm83d.txt @@ -0,0 +1,50 @@ +THine Electronics THC63LVDM83D LVDS serializer +---------------------------------------------- + +The THC63LVDM83D is an LVDS serializer designed to support pixel data +transmission between a host and a flat panel. + +Required properties: + +- compatible: Should be "thine,thc63lvdm83d" + +Optional properties: + +- pwdn-gpios: Power down control GPIO + +Required nodes: + +The THC63LVDM83D has two video ports. Their connections are modeled using the +OFgraph bindings specified in Documentation/devicetree/bindings/graph.txt. + +- Video port 0 for CMOS/TTL input +- Video port 1 for LVDS output + + +Example +------- + + lvds_enc: encoder@0 { + compatible = "thine,thc63lvdm83d"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + lvds_enc_in: endpoint@0 { + remote-endpoint = <&rgb_out>; + }; + }; + + port@1 { + reg = <1>; + + lvds_enc_out: endpoint@0 { + remote-endpoint = <&panel_in>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/cirrus,clps711x-fb.txt b/Documentation/devicetree/bindings/display/cirrus,clps711x-fb.txt new file mode 100644 index 000000000..d685be898 --- /dev/null +++ b/Documentation/devicetree/bindings/display/cirrus,clps711x-fb.txt @@ -0,0 +1,47 @@ +* Currus Logic CLPS711X Framebuffer + +Required properties: +- compatible: Shall contain "cirrus,clps711x-fb". +- reg : Physical base address and length of the controller's registers + + location and size of the framebuffer memory. +- clocks : phandle + clock specifier pair of the FB reference clock. +- display : phandle to a display node as described in + Documentation/devicetree/bindings/display/display-timing.txt. + Additionally, the display node has to define properties: + - bits-per-pixel: Bits per pixel. + - ac-prescale : LCD AC bias frequency. This frequency is the required + AC bias frequency for a given manufacturer's LCD plate. + - cmap-invert : Invert the color levels (Optional). + +Optional properties: +- lcd-supply: Regulator for LCD supply voltage. + +Example: + fb: fb@800002c0 { + compatible = "cirrus,ep7312-fb", "cirrus,clps711x-fb"; + reg = <0x800002c0 0xd44>, <0x60000000 0xc000>; + clocks = <&clks 2>; + lcd-supply = <®5v0>; + display = <&display>; + }; + + display: display { + model = "320x240x4"; + native-mode = <&timing0>; + bits-per-pixel = <4>; + ac-prescale = <17>; + + display-timings { + timing0: 320x240 { + hactive = <320>; + hback-porch = <0>; + hfront-porch = <0>; + hsync-len = <0>; + vactive = <240>; + vback-porch = <0>; + vfront-porch = <0>; + vsync-len = <0>; + clock-frequency = <6500000>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/connector/analog-tv-connector.txt b/Documentation/devicetree/bindings/display/connector/analog-tv-connector.txt new file mode 100644 index 000000000..0c0970c21 --- /dev/null +++ b/Documentation/devicetree/bindings/display/connector/analog-tv-connector.txt @@ -0,0 +1,25 @@ +Analog TV Connector +=================== + +Required properties: +- compatible: "composite-video-connector" or "svideo-connector" + +Optional properties: +- label: a symbolic name for the connector + +Required nodes: +- Video port for TV input + +Example +------- + +tv: connector { + compatible = "composite-video-connector"; + label = "tv"; + + port { + tv_connector_in: endpoint { + remote-endpoint = <&venc_out>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/display/connector/dvi-connector.txt b/Documentation/devicetree/bindings/display/connector/dvi-connector.txt new file mode 100644 index 000000000..fc53f7c60 --- /dev/null +++ b/Documentation/devicetree/bindings/display/connector/dvi-connector.txt @@ -0,0 +1,35 @@ +DVI Connector +============== + +Required properties: +- compatible: "dvi-connector" + +Optional properties: +- label: a symbolic name for the connector +- ddc-i2c-bus: phandle to the i2c bus that is connected to DVI DDC +- analog: the connector has DVI analog pins +- digital: the connector has DVI digital pins +- dual-link: the connector has pins for DVI dual-link + +Required nodes: +- Video port for DVI input + +Note: One (or both) of 'analog' or 'digital' must be set. + +Example +------- + +dvi0: connector@0 { + compatible = "dvi-connector"; + label = "dvi"; + + digital; + + ddc-i2c-bus = <&i2c3>; + + port { + dvi_connector_in: endpoint { + remote-endpoint = <&tfp410_out>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt b/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt new file mode 100644 index 000000000..acd5668b1 --- /dev/null +++ b/Documentation/devicetree/bindings/display/connector/hdmi-connector.txt @@ -0,0 +1,29 @@ +HDMI Connector +============== + +Required properties: +- compatible: "hdmi-connector" +- type: the HDMI connector type: "a", "b", "c", "d" or "e" + +Optional properties: +- label: a symbolic name for the connector +- hpd-gpios: HPD GPIO number + +Required nodes: +- Video port for HDMI input + +Example +------- + +hdmi0: connector@1 { + compatible = "hdmi-connector"; + label = "hdmi"; + + type = "a"; + + port { + hdmi_connector_in: endpoint { + remote-endpoint = <&tpd12s015_out>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/display/connector/vga-connector.txt b/Documentation/devicetree/bindings/display/connector/vga-connector.txt new file mode 100644 index 000000000..c727f298e --- /dev/null +++ b/Documentation/devicetree/bindings/display/connector/vga-connector.txt @@ -0,0 +1,36 @@ +VGA Connector +============= + +Required properties: + +- compatible: "vga-connector" + +Optional properties: + +- label: a symbolic name for the connector corresponding to a hardware label +- ddc-i2c-bus: phandle to the I2C bus that is connected to VGA DDC + +Required nodes: + +The VGA connector internal connections are modeled using the OF graph bindings +specified in Documentation/devicetree/bindings/graph.txt. + +The VGA connector has a single port that must be connected to a video source +port. + + +Example +------- + +vga0: connector@0 { + compatible = "vga-connector"; + label = "vga"; + + ddc-i2c-bus = <&i2c3>; + + port { + vga_connector_in: endpoint { + remote-endpoint = <&adv7123_out>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/display/exynos/exynos-mic.txt b/Documentation/devicetree/bindings/display/exynos/exynos-mic.txt new file mode 100644 index 000000000..0fba2ee64 --- /dev/null +++ b/Documentation/devicetree/bindings/display/exynos/exynos-mic.txt @@ -0,0 +1,51 @@ +Device-Tree bindings for Samsung Exynos SoC mobile image compressor (MIC) + +MIC (mobile image compressor) resides between decon and mipi dsi. Mipi dsi is +not capable to transfer high resoltuion frame data as decon can send. MIC +solves this problem by compressing the frame data by 1/2 before it is +transferred through mipi dsi. The compressed frame data must be uncompressed in +the panel PCB. + +Required properties: +- compatible: value should be "samsung,exynos5433-mic". +- reg: physical base address and length of the MIC registers set and system + register of mic. +- clocks: must include clock specifiers corresponding to entries in the + clock-names property. +- clock-names: list of clock names sorted in the same order as the clocks + property. Must contain "pclk_mic0", "sclk_rgb_vclk_to_mic0". +- samsung,disp-syscon: the reference node for syscon for DISP block. +- ports: contains a port which is connected to decon node and dsi node. + address-cells and size-cells must 1 and 0, respectively. +- port: contains an endpoint node which is connected to the endpoint in the + decon node or dsi node. The reg value must be 0 and 1 respectively. + +Example: +SoC specific DT entry: +mic: mic@13930000 { + compatible = "samsung,exynos5433-mic"; + reg = <0x13930000 0x48>; + clocks = <&cmu_disp CLK_PCLK_MIC0>, + <&cmu_disp CLK_SCLK_RGB_VCLK_TO_MIC0>; + clock-names = "pclk_mic0", "sclk_rgb_vclk_to_mic0"; + samsung,disp-syscon = <&syscon_disp>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + mic_to_decon: endpoint { + remote-endpoint = <&decon_to_mic>; + }; + }; + + port@1 { + reg = <1>; + mic_to_dsi: endpoint { + remote-endpoint = <&dsi_to_mic>; + }; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/display/exynos/exynos5433-decon.txt b/Documentation/devicetree/bindings/display/exynos/exynos5433-decon.txt new file mode 100644 index 000000000..377afbf51 --- /dev/null +++ b/Documentation/devicetree/bindings/display/exynos/exynos5433-decon.txt @@ -0,0 +1,65 @@ +Device-Tree bindings for Samsung Exynos SoC display controller (DECON) + +DECON (Display and Enhancement Controller) is the Display Controller for the +Exynos series of SoCs which transfers the image data from a video memory +buffer to an external LCD interface. + +Required properties: +- compatible: value should be "samsung,exynos5433-decon"; +- reg: physical base address and length of the DECON registers set. +- interrupts: should contain a list of all DECON IP block interrupts in the + order: VSYNC, LCD_SYSTEM. The interrupt specifier format + depends on the interrupt controller used. +- interrupt-names: should contain the interrupt names: "vsync", "lcd_sys" + in the same order as they were listed in the interrupts + property. +- clocks: must include clock specifiers corresponding to entries in the + clock-names property. +- clock-names: list of clock names sorted in the same order as the clocks + property. Must contain "aclk_decon", "aclk_smmu_decon0x", + "aclk_xiu_decon0x", "pclk_smmu_decon0x", clk_decon_vclk", + "sclk_decon_eclk" +- ports: contains a port which is connected to mic node. address-cells and + size-cells must 1 and 0, respectively. +- port: contains an endpoint node which is connected to the endpoint in the mic + node. The reg value muset be 0. +- i80-if-timings: specify whether the panel which is connected to decon uses + i80 lcd interface or mipi video interface. This node contains + no timing information as that of fimd does. Because there is + no register in decon to specify i80 interface timing value, + it is not needed, but make it remain to use same kind of node + in fimd and exynos7 decon. + +Example: +SoC specific DT entry: +decon: decon@13800000 { + compatible = "samsung,exynos5433-decon"; + reg = <0x13800000 0x2104>; + clocks = <&cmu_disp CLK_ACLK_DECON>, <&cmu_disp CLK_ACLK_SMMU_DECON0X>, + <&cmu_disp CLK_ACLK_XIU_DECON0X>, + <&cmu_disp CLK_PCLK_SMMU_DECON0X>, + <&cmu_disp CLK_SCLK_DECON_VCLK>, + <&cmu_disp CLK_SCLK_DECON_ECLK>; + clock-names = "aclk_decon", "aclk_smmu_decon0x", "aclk_xiu_decon0x", + "pclk_smmu_decon0x", "sclk_decon_vclk", "sclk_decon_eclk"; + interrupt-names = "vsync", "lcd_sys"; + interrupts = <0 202 0>, <0 203 0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + decon_to_mic: endpoint { + remote-endpoint = <&mic_to_decon>; + }; + }; + }; +}; + +Board specific DT entry: +&decon { + i80-if-timings { + }; +}; diff --git a/Documentation/devicetree/bindings/display/exynos/exynos7-decon.txt b/Documentation/devicetree/bindings/display/exynos/exynos7-decon.txt new file mode 100644 index 000000000..3938caacf --- /dev/null +++ b/Documentation/devicetree/bindings/display/exynos/exynos7-decon.txt @@ -0,0 +1,68 @@ +Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON) + +DECON (Display and Enhancement Controller) is the Display Controller for the +Exynos7 series of SoCs which transfers the image data from a video memory +buffer to an external LCD interface. + +Required properties: +- compatible: value should be "samsung,exynos7-decon"; + +- reg: physical base address and length of the DECON registers set. + +- interrupt-parent: should be the phandle of the decon controller's + parent interrupt controller. + +- interrupts: should contain a list of all DECON IP block interrupts in the + order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier + format depends on the interrupt controller used. + +- interrupt-names: should contain the interrupt names: "fifo", "vsync", + "lcd_sys", in the same order as they were listed in the interrupts + property. + +- pinctrl-0: pin control group to be used for this controller. + +- pinctrl-names: must contain a "default" entry. + +- clocks: must include clock specifiers corresponding to entries in the + clock-names property. + +- clock-names: list of clock names sorted in the same order as the clocks + property. Must contain "pclk_decon0", "aclk_decon0", + "decon0_eclk", "decon0_vclk". +- i80-if-timings: timing configuration for lcd i80 interface support. + +Optional Properties: +- samsung,power-domain: 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. + +[1]: Documentation/devicetree/bindings/display/display-timing.txt + +Example: + +SoC specific DT entry: + + decon@13930000 { + compatible = "samsung,exynos7-decon"; + interrupt-parent = <&combiner>; + reg = <0x13930000 0x1000>; + interrupt-names = "lcd_sys", "vsync", "fifo"; + interrupts = <0 188 0>, <0 189 0>, <0 190 0>; + clocks = <&clock_disp PCLK_DECON_INT>, + <&clock_disp ACLK_DECON_INT>, + <&clock_disp SCLK_DECON_INT_ECLK>, + <&clock_disp SCLK_DECON_INT_EXTCLKPLL>; + clock-names = "pclk_decon0", "aclk_decon0", "decon0_eclk", + "decon0_vclk"; + status = "disabled"; + }; + +Board specific DT entry: + + decon@13930000 { + pinctrl-0 = <&lcd_clk &pwm1_out>; + pinctrl-names = "default"; + status = "okay"; + }; diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt new file mode 100644 index 000000000..64693f2eb --- /dev/null +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dp.txt @@ -0,0 +1,120 @@ +The Exynos display port interface should be configured based on +the type of panel connected to it. + +We use two nodes: + -dp-controller node + -dptx-phy node(defined inside dp-controller node) + +For the DP-PHY initialization, we use the dptx-phy node. +Required properties for dptx-phy: deprecated, use phys and phy-names + -reg: deprecated + Base address of DP PHY register. + -samsung,enable-mask: deprecated + The bit-mask used to enable/disable DP PHY. + +For the Panel initialization, we read data from dp-controller node. +Required properties for dp-controller: + -compatible: + should be "samsung,exynos5-dp". + -reg: + physical base address of the controller and length + of memory mapped region. + -interrupts: + interrupt combiner values. + -clocks: + from common clock binding: handle to dp clock. + -clock-names: + from common clock binding: Shall be "dp". + -interrupt-parent: + phandle to Interrupt combiner node. + -phys: + from general PHY binding: the phandle for the PHY device. + -phy-names: + from general PHY binding: Should be "dp". + -samsung,color-space: + input video data format. + COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2 + -samsung,dynamic-range: + dynamic range for input video data. + VESA = 0, CEA = 1 + -samsung,ycbcr-coeff: + YCbCr co-efficients for input video. + COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1 + -samsung,color-depth: + number of bits per colour component. + COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3 + -samsung,link-rate: + link rate supported by the panel. + LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A + -samsung,lane-count: + number of lanes supported by the panel. + LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4 + - display-timings: timings for the connected panel as described by + Documentation/devicetree/bindings/display/display-timing.txt + +Optional properties for dp-controller: + -interlaced: + interlace scan mode. + Progressive if defined, Interlaced if not defined + -vsync-active-high: + VSYNC polarity configuration. + High if defined, Low if not defined + -hsync-active-high: + HSYNC polarity configuration. + High if defined, Low if not defined + -samsung,hpd-gpio: + Hotplug detect GPIO. + Indicates which GPIO should be used for hotplug + detection + -video interfaces: Device node can contain video interface port + nodes according to [1]. + +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt + +Example: + +SOC specific portion: + dp-controller { + compatible = "samsung,exynos5-dp"; + reg = <0x145b0000 0x10000>; + interrupts = <10 3>; + interrupt-parent = <&combiner>; + clocks = <&clock 342>; + clock-names = "dp"; + + phys = <&dp_phy>; + phy-names = "dp"; + }; + +Board Specific portion: + dp-controller { + samsung,color-space = <0>; + samsung,dynamic-range = <0>; + samsung,ycbcr-coeff = <0>; + samsung,color-depth = <1>; + samsung,link-rate = <0x0a>; + samsung,lane-count = <4>; + + display-timings { + native-mode = <&lcd_timing>; + lcd_timing: 1366x768 { + clock-frequency = <70589280>; + hactive = <1366>; + vactive = <768>; + hfront-porch = <40>; + hback-porch = <40>; + hsync-len = <32>; + vback-porch = <10>; + vfront-porch = <12>; + vsync-len = <6>; + }; + }; + + ports { + port@0 { + dp_out: endpoint { + remote-endpoint = <&bridge_in>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt new file mode 100644 index 000000000..0e6f0c024 --- /dev/null +++ b/Documentation/devicetree/bindings/display/exynos/exynos_dsim.txt @@ -0,0 +1,103 @@ +Exynos MIPI DSI Master + +Required properties: + - compatible: value should be one of the following + "samsung,exynos3250-mipi-dsi" /* for Exynos3250/3472 SoCs */ + "samsung,exynos4210-mipi-dsi" /* for Exynos4 SoCs */ + "samsung,exynos4415-mipi-dsi" /* for Exynos4415 SoC */ + "samsung,exynos5410-mipi-dsi" /* for Exynos5410/5420/5440 SoCs */ + "samsung,exynos5433-mipi-dsi" /* for Exynos5433 SoCs */ + - reg: physical base address and length of the registers set for the device + - interrupts: should contain DSI interrupt + - clocks: list of clock specifiers, must contain an entry for each required + entry in clock-names + - clock-names: should include "bus_clk"and "sclk_mipi" entries + the use of "pll_clk" is deprecated + - phys: list of phy specifiers, must contain an entry for each required + entry in phy-names + - phy-names: should include "dsim" entry + - vddcore-supply: MIPI DSIM Core voltage supply (e.g. 1.1V) + - vddio-supply: MIPI DSIM I/O and PLL voltage supply (e.g. 1.8V) + - samsung,pll-clock-frequency: specifies frequency of the oscillator clock + - #address-cells, #size-cells: should be set respectively to <1> and <0> + according to DSI host bindings (see MIPI DSI bindings [1]) + +Optional properties: + - power-domains: a phandle to DSIM power domain node + +Child nodes: + Should contain DSI peripheral nodes (see MIPI DSI bindings [1]). + +Video interfaces: + Device node can contain video interface port nodes according to [2]. + The following are properties specific to those nodes: + + port node inbound: + - reg: (required) must be 0. + port node outbound: + - reg: (required) must be 1. + + endpoint node connected from mic node (reg = 0): + - remote-endpoint: specifies the endpoint in mic node. This node is required + for Exynos5433 mipi dsi. So mic can access to panel node + thoughout this dsi node. + endpoint node connected to panel node (reg = 1): + - remote-endpoint: specifies the endpoint in panel node. This node is + required in all kinds of exynos mipi dsi to represent + the connection between mipi dsi and panel. + - samsung,burst-clock-frequency: specifies DSI frequency in high-speed burst + mode + - samsung,esc-clock-frequency: specifies DSI frequency in escape mode + +[1]: Documentation/devicetree/bindings/display/mipi-dsi-bus.txt +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt + +Example: + + dsi@11C80000 { + compatible = "samsung,exynos4210-mipi-dsi"; + reg = <0x11C80000 0x10000>; + interrupts = <0 79 0>; + clocks = <&clock 286>, <&clock 143>; + clock-names = "bus_clk", "sclk_mipi"; + phys = <&mipi_phy 1>; + phy-names = "dsim"; + vddcore-supply = <&vusb_reg>; + vddio-supply = <&vmipi_reg>; + power-domains = <&pd_lcd0>; + #address-cells = <1>; + #size-cells = <0>; + samsung,pll-clock-frequency = <24000000>; + + panel@1 { + reg = <0>; + ... + port { + panel_ep: endpoint { + remote-endpoint = <&dsi_ep>; + }; + }; + }; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + decon_to_mic: endpoint { + remote-endpoint = <&mic_to_decon>; + }; + }; + + port@1 { + reg = <1>; + dsi_ep: endpoint { + reg = <0>; + samsung,burst-clock-frequency = <500000000>; + samsung,esc-clock-frequency = <20000000>; + remote-endpoint = <&panel_ep>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt b/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt new file mode 100644 index 000000000..1fd8cf9cb --- /dev/null +++ b/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt @@ -0,0 +1,43 @@ +Device-Tree bindings for drm hdmi driver + +Required properties: +- compatible: value should be one among the following: + 1) "samsung,exynos5-hdmi" + 2) "samsung,exynos4210-hdmi" + 3) "samsung,exynos4212-hdmi" + 4) "samsung,exynos5420-hdmi" +- reg: physical base address of the hdmi and length of memory mapped + region. +- interrupts: interrupt number to the cpu. +- hpd-gpio: following information about the hotplug gpio pin. + a) phandle of the gpio controller node. + b) pin number within the gpio controller. + c) optional flags and pull up/down. +- clocks: list of clock IDs from SoC clock driver. + a) hdmi: Gate of HDMI IP bus clock. + b) sclk_hdmi: Gate of HDMI special clock. + c) sclk_pixel: Pixel special clock, one of the two possible inputs of + HDMI clock mux. + d) sclk_hdmiphy: HDMI PHY clock output, one of two possible inputs of + HDMI clock mux. + e) mout_hdmi: It is required by the driver to switch between the 2 + parents i.e. sclk_pixel and sclk_hdmiphy. If hdmiphy is stable + after configuration, parent is set to sclk_hdmiphy else + sclk_pixel. +- clock-names: aliases as per driver requirements for above clock IDs: + "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi". +- ddc: phandle to the hdmi ddc node +- phy: phandle to the hdmi phy node +- samsung,syscon-phandle: phandle for system controller node for PMU. + +Example: + + hdmi { + compatible = "samsung,exynos4212-hdmi"; + reg = <0x14530000 0x100000>; + interrupts = <0 95 0>; + hpd-gpio = <&gpx3 7 1>; + ddc = <&hdmi_ddc_node>; + phy = <&hdmi_phy_node>; + samsung,syscon-phandle = <&pmu_system_controller>; + }; diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_hdmiddc.txt b/Documentation/devicetree/bindings/display/exynos/exynos_hdmiddc.txt new file mode 100644 index 000000000..41eee9715 --- /dev/null +++ b/Documentation/devicetree/bindings/display/exynos/exynos_hdmiddc.txt @@ -0,0 +1,15 @@ +Device-Tree bindings for hdmiddc driver + +Required properties: +- compatible: value should be one of the following + 1) "samsung,exynos5-hdmiddc" + 2) "samsung,exynos4210-hdmiddc" + +- reg: I2C address of the hdmiddc device. + +Example: + + hdmiddc { + compatible = "samsung,exynos4210-hdmiddc"; + reg = <0x50>; + }; diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_hdmiphy.txt b/Documentation/devicetree/bindings/display/exynos/exynos_hdmiphy.txt new file mode 100644 index 000000000..162f641f7 --- /dev/null +++ b/Documentation/devicetree/bindings/display/exynos/exynos_hdmiphy.txt @@ -0,0 +1,15 @@ +Device-Tree bindings for hdmiphy driver + +Required properties: +- compatible: value should be one of the following: + 1) "samsung,exynos5-hdmiphy" + 2) "samsung,exynos4210-hdmiphy". + 3) "samsung,exynos4212-hdmiphy". +- reg: I2C address of the hdmiphy device. + +Example: + + hdmiphy { + compatible = "samsung,exynos4210-hdmiphy"; + reg = <0x38>; + }; diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_mixer.txt b/Documentation/devicetree/bindings/display/exynos/exynos_mixer.txt new file mode 100644 index 000000000..3e38128f8 --- /dev/null +++ b/Documentation/devicetree/bindings/display/exynos/exynos_mixer.txt @@ -0,0 +1,26 @@ +Device-Tree bindings for mixer driver + +Required properties: +- compatible: value should be one of the following: + 1) "samsung,exynos5-mixer" + 2) "samsung,exynos4210-mixer" + 3) "samsung,exynos4212-mixer" + 4) "samsung,exynos5250-mixer" + 5) "samsung,exynos5420-mixer" + +- reg: physical base address of the mixer and length of memory mapped + region. +- interrupts: interrupt number to the cpu. +- clocks: list of clock IDs from SoC clock driver. + a) mixer: Gate of Mixer IP bus clock. + b) sclk_hdmi: HDMI Special clock, one of the two possible inputs of + mixer mux. + c) hdmi: Gate of HDMI IP bus clock, needed together with sclk_hdmi. + +Example: + + mixer { + compatible = "samsung,exynos5250-mixer"; + reg = <0x14450000 0x10000>; + interrupts = <0 94 0>; + }; diff --git a/Documentation/devicetree/bindings/display/exynos/samsung-fimd.txt b/Documentation/devicetree/bindings/display/exynos/samsung-fimd.txt new file mode 100644 index 000000000..27c3ce0db --- /dev/null +++ b/Documentation/devicetree/bindings/display/exynos/samsung-fimd.txt @@ -0,0 +1,110 @@ +Device-Tree bindings for Samsung SoC display controller (FIMD) + +FIMD (Fully Interactive Mobile Display) is the Display Controller for the +Samsung series of SoCs which transfers the image data from a video memory +buffer to an external LCD interface. + +Required properties: +- compatible: value should be one of the following + "samsung,s3c2443-fimd"; /* for S3C24XX SoCs */ + "samsung,s3c6400-fimd"; /* for S3C64XX SoCs */ + "samsung,s5pv210-fimd"; /* for S5PV210 SoC */ + "samsung,exynos3250-fimd"; /* for Exynos3250/3472 SoCs */ + "samsung,exynos4210-fimd"; /* for Exynos4 SoCs */ + "samsung,exynos4415-fimd"; /* for Exynos4415 SoC */ + "samsung,exynos5250-fimd"; /* for Exynos5 SoCs */ + +- reg: physical base address and length of the FIMD registers set. + +- interrupt-parent: should be the phandle of the fimd controller's + parent interrupt controller. + +- interrupts: should contain a list of all FIMD IP block interrupts in the + order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier + format depends on the interrupt controller used. + +- interrupt-names: should contain the interrupt names: "fifo", "vsync", + "lcd_sys", in the same order as they were listed in the interrupts + property. + +- pinctrl-0: pin control group to be used for this controller. + +- pinctrl-names: must contain a "default" entry. + +- clocks: must include clock specifiers corresponding to entries in the + clock-names property. + +- clock-names: list of clock names sorted in the same order as the clocks + property. Must contain "sclk_fimd" and "fimd". + +Optional Properties: +- power-domains: a phandle to FIMD power domain node. +- samsung,invert-vden: video enable signal is inverted +- samsung,invert-vclk: video clock signal is inverted +- display-timings: timing settings for FIMD, as described in document [1]. + Can be used in case timings cannot be provided otherwise + or to override timings provided by the panel. +- samsung,sysreg: handle to syscon used to control the system registers +- i80-if-timings: timing configuration for lcd i80 interface support. + - cs-setup: clock cycles for the active period of address signal is enabled + until chip select is enabled. + If not specified, the default value(0) will be used. + - wr-setup: clock cycles for the active period of CS signal is enabled until + write signal is enabled. + If not specified, the default value(0) will be used. + - wr-active: clock cycles for the active period of CS is enabled. + If not specified, the default value(1) will be used. + - wr-hold: clock cycles for the active period of CS is disabled until write + signal is disabled. + If not specified, the default value(0) will be used. + + The parameters are defined as: + + VCLK(internal) __|??????|_____|??????|_____|??????|_____|??????|_____|?? + : : : : : + Address Output --:| : : : + Chip Select ???????????????|____________:____________:____________|?? + | wr-setup+1 | | wr-hold+1 | + |<---------->| |<---------->| + Write Enable ????????????????????????????|____________|??????????????? + | wr-active+1| + |<---------->| + Video Data ------------------------------ + +The device node can contain 'port' child nodes according to the bindings defined +in [2]. The following are properties specific to those nodes: +- reg: (required) port index, can be: + 0 - for CAMIF0 input, + 1 - for CAMIF1 input, + 2 - for CAMIF2 input, + 3 - for parallel output, + 4 - for write-back interface + +[1]: Documentation/devicetree/bindings/display/display-timing.txt +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt + +Example: + +SoC specific DT entry: + + fimd@11c00000 { + compatible = "samsung,exynos4210-fimd"; + interrupt-parent = <&combiner>; + reg = <0x11c00000 0x20000>; + interrupt-names = "fifo", "vsync", "lcd_sys"; + interrupts = <11 0>, <11 1>, <11 2>; + clocks = <&clock 140>, <&clock 283>; + clock-names = "sclk_fimd", "fimd"; + power-domains = <&pd_lcd0>; + status = "disabled"; + }; + +Board specific DT entry: + + fimd@11c00000 { + pinctrl-0 = <&lcd_clk &lcd_data24 &pwm1_out>; + pinctrl-names = "default"; + status = "okay"; + }; diff --git a/Documentation/devicetree/bindings/display/fsl,dcu.txt b/Documentation/devicetree/bindings/display/fsl,dcu.txt new file mode 100644 index 000000000..ebf1be9ae --- /dev/null +++ b/Documentation/devicetree/bindings/display/fsl,dcu.txt @@ -0,0 +1,22 @@ +Device Tree bindings for Freescale DCU DRM Driver + +Required properties: +- compatible: Should be one of + * "fsl,ls1021a-dcu". + * "fsl,vf610-dcu". + +- reg: Address and length of the register set for dcu. +- clocks: From common clock binding: handle to dcu clock. +- clock-names: From common clock binding: Shall be "dcu". +- big-endian Boolean property, LS1021A DCU registers are big-endian. +- fsl,panel: The phandle to panel node. + +Examples: +dcu: dcu@2ce0000 { + compatible = "fsl,ls1021a-dcu"; + reg = <0x0 0x2ce0000 0x0 0x10000>; + clocks = <&platform_clk 0>; + clock-names = "dcu"; + big-endian; + fsl,panel = <&panel>; +}; diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx-fb.txt b/Documentation/devicetree/bindings/display/imx/fsl,imx-fb.txt new file mode 100644 index 000000000..00d5f8ea7 --- /dev/null +++ b/Documentation/devicetree/bindings/display/imx/fsl,imx-fb.txt @@ -0,0 +1,55 @@ +Freescale imx21 Framebuffer + +This framebuffer driver supports devices imx1, imx21, imx25, and imx27. + +Required properties: +- compatible : "fsl,-fb", chip should be imx1 or imx21 +- reg : Should contain 1 register ranges(address and length) +- interrupts : One interrupt of the fb dev + +Required nodes: +- display: Phandle to a display node as described in + Documentation/devicetree/bindings/display/display-timing.txt + Additional, the display node has to define properties: + - bits-per-pixel: Bits per pixel + - fsl,pcr: LCDC PCR value + +Optional properties: +- lcd-supply: Regulator for LCD supply voltage. +- fsl,dmacr: DMA Control Register value. This is optional. By default, the + register is not modified as recommended by the datasheet. +- fsl,lpccr: Contrast Control Register value. This property provides the + default value for the contrast control register. + If that property is omitted, the register is zeroed. +- fsl,lscr1: LCDC Sharp Configuration Register value. + +Example: + + imxfb: fb@10021000 { + compatible = "fsl,imx21-fb"; + interrupts = <61>; + reg = <0x10021000 0x1000>; + display = <&display0>; + }; + + ... + + display0: display0 { + model = "Primeview-PD050VL1"; + native-mode = <&timing_disp0>; + bits-per-pixel = <16>; + fsl,pcr = <0xf0c88080>; /* non-standard but required */ + display-timings { + timing_disp0: 640x480 { + hactive = <640>; + vactive = <480>; + hback-porch = <112>; + hfront-porch = <36>; + hsync-len = <32>; + vback-porch = <33>; + vfront-porch = <33>; + vsync-len = <2>; + clock-frequency = <25000000>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt b/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt new file mode 100644 index 000000000..971c3eedb --- /dev/null +++ b/Documentation/devicetree/bindings/display/imx/fsl-imx-drm.txt @@ -0,0 +1,105 @@ +Freescale i.MX DRM master device +================================ + +The freescale i.MX DRM master device is a virtual device needed to list all +IPU or other display interface nodes that comprise the graphics subsystem. + +Required properties: +- compatible: Should be "fsl,imx-display-subsystem" +- ports: Should contain a list of phandles pointing to display interface ports + of IPU devices + +example: + +display-subsystem { + compatible = "fsl,display-subsystem"; + ports = <&ipu_di0>; +}; + + +Freescale i.MX IPUv3 +==================== + +Required properties: +- compatible: Should be "fsl,-ipu" +- reg: should be register base and length as documented in the + datasheet +- interrupts: Should contain sync interrupt and error interrupt, + in this order. +- resets: phandle pointing to the system reset controller and + reset line index, see reset/fsl,imx-src.txt for details +Optional properties: +- port@[0-3]: Port nodes with endpoint definitions as defined in + Documentation/devicetree/bindings/media/video-interfaces.txt. + Ports 0 and 1 should correspond to CSI0 and CSI1, + ports 2 and 3 should correspond to DI0 and DI1, respectively. + +example: + +ipu: ipu@18000000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "fsl,imx53-ipu"; + reg = <0x18000000 0x080000000>; + interrupts = <11 10>; + resets = <&src 2>; + + ipu_di0: port@2 { + reg = <2>; + + ipu_di0_disp0: endpoint { + remote-endpoint = <&display_in>; + }; + }; +}; + +Parallel display support +======================== + +Required properties: +- compatible: Should be "fsl,imx-parallel-display" +Optional properties: +- interface_pix_fmt: How this display is connected to the + display interface. Currently supported types: "rgb24", "rgb565", "bgr666" + and "lvds666". +- edid: verbatim EDID data block describing attached display. +- ddc: phandle describing the i2c bus handling the display data + channel +- port@[0-1]: Port nodes with endpoint definitions as defined in + Documentation/devicetree/bindings/media/video-interfaces.txt. + Port 0 is the input port connected to the IPU display interface, + port 1 is the output port connected to a panel. + +example: + +display@di0 { + compatible = "fsl,imx-parallel-display"; + edid = [edid-data]; + interface-pix-fmt = "rgb24"; + + port@0 { + reg = <0>; + + display_in: endpoint { + remote-endpoint = <&ipu_di0_disp0>; + }; + }; + + port@1 { + reg = <1>; + + display_out: endpoint { + remote-endpoint = <&panel_in>; + }; + }; +}; + +panel { + ... + + port { + panel_in: endpoint { + remote-endpoint = <&display_out>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/display/imx/hdmi.txt b/Documentation/devicetree/bindings/display/imx/hdmi.txt new file mode 100644 index 000000000..1b756cf9a --- /dev/null +++ b/Documentation/devicetree/bindings/display/imx/hdmi.txt @@ -0,0 +1,58 @@ +Device-Tree bindings for HDMI Transmitter + +HDMI Transmitter +================ + +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: + + gpr: iomuxc-gpr@020e0000 { + /* ... */ + }; + + hdmi: hdmi@0120000 { + #address-cells = <1>; + #size-cells = <0>; + 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>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/imx/ldb.txt b/Documentation/devicetree/bindings/display/imx/ldb.txt new file mode 100644 index 000000000..0a175d991 --- /dev/null +++ b/Documentation/devicetree/bindings/display/imx/ldb.txt @@ -0,0 +1,146 @@ +Device-Tree bindings for LVDS Display Bridge (ldb) + +LVDS Display Bridge +=================== + +The LVDS Display Bridge device tree node contains up to two lvds-channel +nodes describing each of the two LVDS encoder channels of the bridge. + +Required properties: + - #address-cells : should be <1> + - #size-cells : should be <0> + - compatible : should be "fsl,imx53-ldb" or "fsl,imx6q-ldb". + Both LDB versions are similar, but i.MX6 has an additional + multiplexer in the front to select any of the four IPU display + interfaces as input for each LVDS channel. + - gpr : should be <&gpr> on i.MX53 and i.MX6q. + The phandle points to the iomuxc-gpr region containing the LVDS + control register. +- clocks, clock-names : phandles to the LDB divider and selector clocks and to + the display interface selector clocks, as described in + Documentation/devicetree/bindings/clock/clock-bindings.txt + The following clocks are expected on i.MX53: + "di0_pll" - LDB LVDS channel 0 mux + "di1_pll" - LDB LVDS channel 1 mux + "di0" - LDB LVDS channel 0 gate + "di1" - LDB LVDS channel 1 gate + "di0_sel" - IPU1 DI0 mux + "di1_sel" - IPU1 DI1 mux + On i.MX6q the following additional clocks are needed: + "di2_sel" - IPU2 DI0 mux + "di3_sel" - IPU2 DI1 mux + The needed clock numbers for each are documented in + Documentation/devicetree/bindings/clock/imx5-clock.txt, and in + Documentation/devicetree/bindings/clock/imx6q-clock.txt. + +Optional properties: + - pinctrl-names : should be "default" on i.MX53, not used on i.MX6q + - pinctrl-0 : a phandle pointing to LVDS pin settings on i.MX53, + not used on i.MX6q + - fsl,dual-channel : boolean. if it exists, only LVDS channel 0 should + be configured - one input will be distributed on both outputs in dual + channel mode + +LVDS Channel +============ + +Each LVDS Channel has to contain either an of graph link to a panel device node +or a display-timings node that describes the video timings for the connected +LVDS display as well as the fsl,data-mapping and fsl,data-width properties. + +Required properties: + - reg : should be <0> or <1> + - port: Input and output port nodes with endpoint definitions as defined in + Documentation/devicetree/bindings/graph.txt. + On i.MX5, the internal two-input-multiplexer is used. Due to hardware + limitations, only one input port (port@[0,1]) can be used for each channel + (lvds-channel@[0,1], respectively). + On i.MX6, there should be four input ports (port@[0-3]) that correspond + to the four LVDS multiplexer inputs. + A single output port (port@2 on i.MX5, port@4 on i.MX6) must be connected + to a panel input port. Optionally, the output port can be left out if + display-timings are used instead. + +Optional properties (required if display-timings are used): + - display-timings : A node that describes the display timings as defined in + Documentation/devicetree/bindings/display/display-timing.txt. + - fsl,data-mapping : should be "spwg" or "jeida" + This describes how the color bits are laid out in the + serialized LVDS signal. + - fsl,data-width : should be <18> or <24> + +example: + +gpr: iomuxc-gpr@53fa8000 { + /* ... */ +}; + +ldb: ldb@53fa8008 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "fsl,imx53-ldb"; + gpr = <&gpr>; + clocks = <&clks IMX5_CLK_LDB_DI0_SEL>, + <&clks IMX5_CLK_LDB_DI1_SEL>, + <&clks IMX5_CLK_IPU_DI0_SEL>, + <&clks IMX5_CLK_IPU_DI1_SEL>, + <&clks IMX5_CLK_LDB_DI0_GATE>, + <&clks IMX5_CLK_LDB_DI1_GATE>; + clock-names = "di0_pll", "di1_pll", + "di0_sel", "di1_sel", + "di0", "di1"; + + /* Using an of-graph endpoint link to connect the panel */ + lvds-channel@0 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0>; + + port@0 { + reg = <0>; + + lvds0_in: endpoint { + remote-endpoint = <&ipu_di0_lvds0>; + }; + }; + + port@2 { + reg = <2>; + + lvds0_out: endpoint { + remote-endpoint = <&panel_in>; + }; + }; + }; + + /* Using display-timings and fsl,data-mapping/width instead */ + lvds-channel@1 { + #address-cells = <1>; + #size-cells = <0>; + reg = <1>; + fsl,data-mapping = "spwg"; + fsl,data-width = <24>; + + display-timings { + /* ... */ + }; + + port@1 { + reg = <1>; + + lvds1_in: endpoint { + remote-endpoint = <&ipu_di1_lvds1>; + }; + }; + }; +}; + +panel: lvds-panel { + /* ... */ + + port { + panel_in: endpoint { + remote-endpoint = <&lvds0_out>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/display/marvell,pxa2xx-lcdc.txt b/Documentation/devicetree/bindings/display/marvell,pxa2xx-lcdc.txt new file mode 100644 index 000000000..309c47f25 --- /dev/null +++ b/Documentation/devicetree/bindings/display/marvell,pxa2xx-lcdc.txt @@ -0,0 +1,34 @@ +PXA LCD Controller +------------------ + +Required properties: + - compatible : one of these + "marvell,pxa2xx-lcdc", + "marvell,pxa270-lcdc", + "marvell,pxa300-lcdc" + - reg : should contain 1 register range (address and length). + - interrupts : framebuffer controller interrupt. + - clocks: phandle to input clocks + +Required nodes: + - port: connection to the LCD panel (see video-interfaces.txt) + This node must have its properties bus-width and remote-endpoint set. + If the panel is not a TFT color panel, then a "lcd-type" property in + the panel should specify the panel type. + This panel node should be in the board dts. + +Example: + lcd-controller@40500000 { + compatible = "marvell,pxa2xx-lcdc"; + reg = <0x44000000 0x10000>; + interrupts = <17>; + clocks = <&clks CLK_LCD>; + status = "okay"; + + port { + lcdc_out: endpoint { + remote-endpoint = <&panel_in>; + bus-width = <16>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt new file mode 100644 index 000000000..973c27273 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt @@ -0,0 +1,98 @@ +MIPI DSI (Display Serial Interface) busses +========================================== + +The MIPI Display Serial Interface specifies a serial bus and a protocol for +communication between a host and up to four peripherals. This document will +define the syntax used to represent a DSI bus in a device tree. + +This document describes DSI bus-specific properties only or defines existing +standard properties in the context of the DSI bus. + +Each DSI host provides a DSI bus. The DSI host controller's node contains a +set of properties that characterize the bus. Child nodes describe individual +peripherals on that bus. + +The following assumes that only a single peripheral is connected to a DSI +host. Experience shows that this is true for the large majority of setups. + +DSI host +-------- + +In addition to the standard properties and those defined by the parent bus of +a DSI host, the following properties apply to a node representing a DSI host. + +Required properties: +- #address-cells: The number of cells required to represent an address on the + bus. DSI peripherals are addressed using a 2-bit virtual channel number, so + a maximum of 4 devices can be addressed on a single bus. Hence the value of + this property should be 1. +- #size-cells: Should be 0. There are cases where it makes sense to use a + different value here. See below. + +DSI peripheral +-------------- + +Peripherals are represented as child nodes of the DSI host's node. Properties +described here apply to all DSI peripherals, but individual bindings may want +to define additional, device-specific properties. + +Required properties: +- reg: The virtual channel number of a DSI peripheral. Must be in the range + from 0 to 3. + +Some DSI peripherals respond to more than a single virtual channel. In that +case two alternative representations can be chosen: +- The reg property can take multiple entries, one for each virtual channel + that the peripheral responds to. +- If the virtual channels that a peripheral responds to are consecutive, the + #size-cells can be set to 1. The first cell of each entry in the reg + property is the number of the first virtual channel and the second cell is + the number of consecutive virtual channels. + +Example +------- + + dsi-host { + ... + + #address-cells = <1>; + #size-cells = <0>; + + /* peripheral responds to virtual channel 0 */ + peripheral@0 { + compatible = "..."; + reg = <0>; + }; + + ... + }; + + dsi-host { + ... + + #address-cells = <1>; + #size-cells = <0>; + + /* peripheral responds to virtual channels 0 and 2 */ + peripheral@0 { + compatible = "..."; + reg = <0, 2>; + }; + + ... + }; + + dsi-host { + ... + + #address-cells = <1>; + #size-cells = <1>; + + /* peripheral responds to virtual channels 1, 2 and 3 */ + peripheral@1 { + compatible = "..."; + reg = <1 3>; + }; + + ... + }; diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt b/Documentation/devicetree/bindings/display/msm/dsi.txt new file mode 100644 index 000000000..f344b9e49 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dsi.txt @@ -0,0 +1,149 @@ +Qualcomm Technologies Inc. adreno/snapdragon DSI output + +DSI Controller: +Required properties: +- compatible: + * "qcom,mdss-dsi-ctrl" +- reg: Physical base address and length of the registers of controller +- reg-names: The names of register regions. The following regions are required: + * "dsi_ctrl" +- qcom,dsi-host-index: The ID of DSI controller hardware instance. This should + be 0 or 1, since we have 2 DSI controllers at most for now. +- interrupts: The interrupt signal from the DSI block. +- power-domains: Should be <&mmcc MDSS_GDSC>. +- clocks: device clocks + See Documentation/devicetree/bindings/clocks/clock-bindings.txt for details. +- clock-names: the following clocks are required: + * "bus_clk" + * "byte_clk" + * "core_clk" + * "core_mmss_clk" + * "iface_clk" + * "mdp_core_clk" + * "pixel_clk" +- vdd-supply: phandle to vdd regulator device node +- vddio-supply: phandle to vdd-io regulator device node +- vdda-supply: phandle to vdda regulator device node +- qcom,dsi-phy: phandle to DSI PHY device node + +Optional properties: +- panel@0: Node of panel connected to this DSI controller. + See files in Documentation/devicetree/bindings/display/panel/ for each supported + panel. +- qcom,dual-dsi-mode: Boolean value indicating if the DSI controller is + driving a panel which needs 2 DSI links. +- qcom,master-dsi: Boolean value indicating if the DSI controller is driving + the master link of the 2-DSI panel. +- qcom,sync-dual-dsi: Boolean value indicating if the DSI controller is + driving a 2-DSI panel whose 2 links need receive command simultaneously. +- interrupt-parent: phandle to the MDP block if the interrupt signal is routed + through MDP block +- pinctrl-names: the pin control state names; should contain "default" +- pinctrl-0: the default pinctrl state (active) +- pinctrl-n: the "sleep" pinctrl state +- port: DSI controller output port. This contains one endpoint subnode, with its + remote-endpoint set to the phandle of the connected panel's endpoint. + See Documentation/devicetree/bindings/graph.txt for device graph info. + +DSI PHY: +Required properties: +- compatible: Could be the following + * "qcom,dsi-phy-28nm-hpm" + * "qcom,dsi-phy-28nm-lp" + * "qcom,dsi-phy-20nm" +- reg: Physical base address and length of the registers of PLL, PHY and PHY + regulator +- reg-names: The names of register regions. The following regions are required: + * "dsi_pll" + * "dsi_phy" + * "dsi_phy_regulator" +- qcom,dsi-phy-index: The ID of DSI PHY hardware instance. This should + be 0 or 1, since we have 2 DSI PHYs at most for now. +- power-domains: Should be <&mmcc MDSS_GDSC>. +- clocks: device clocks + See Documentation/devicetree/bindings/clocks/clock-bindings.txt for details. +- clock-names: the following clocks are required: + * "iface_clk" +- vddio-supply: phandle to vdd-io regulator device node + +Optional properties: +- qcom,dsi-phy-regulator-ldo-mode: Boolean value indicating if the LDO mode PHY + regulator is wanted. + +Example: + mdss_dsi0: qcom,mdss_dsi@fd922800 { + compatible = "qcom,mdss-dsi-ctrl"; + qcom,dsi-host-index = <0>; + interrupt-parent = <&mdss_mdp>; + interrupts = <4 0>; + reg-names = "dsi_ctrl"; + reg = <0xfd922800 0x200>; + power-domains = <&mmcc MDSS_GDSC>; + clock-names = + "bus_clk", + "byte_clk", + "core_clk", + "core_mmss_clk", + "iface_clk", + "mdp_core_clk", + "pixel_clk"; + clocks = + <&mmcc MDSS_AXI_CLK>, + <&mmcc MDSS_BYTE0_CLK>, + <&mmcc MDSS_ESC0_CLK>, + <&mmcc MMSS_MISC_AHB_CLK>, + <&mmcc MDSS_AHB_CLK>, + <&mmcc MDSS_MDP_CLK>, + <&mmcc MDSS_PCLK0_CLK>; + vdda-supply = <&pma8084_l2>; + vdd-supply = <&pma8084_l22>; + vddio-supply = <&pma8084_l12>; + + qcom,dsi-phy = <&mdss_dsi_phy0>; + + qcom,dual-dsi-mode; + qcom,master-dsi; + qcom,sync-dual-dsi; + + pinctrl-names = "default", "sleep"; + pinctrl-0 = <&mdss_dsi_active>; + pinctrl-1 = <&mdss_dsi_suspend>; + + panel: panel@0 { + compatible = "sharp,lq101r1sx01"; + reg = <0>; + link2 = <&secondary>; + + power-supply = <...>; + backlight = <...>; + + port { + panel_in: endpoint { + remote-endpoint = <&dsi0_out>; + }; + }; + }; + + port { + dsi0_out: endpoint { + remote-endpoint = <&panel_in>; + }; + }; + }; + + mdss_dsi_phy0: qcom,mdss_dsi_phy@fd922a00 { + compatible = "qcom,dsi-phy-28nm-hpm"; + qcom,dsi-phy-index = <0>; + reg-names = + "dsi_pll", + "dsi_phy", + "dsi_phy_regulator"; + reg = <0xfd922a00 0xd4>, + <0xfd922b00 0x2b0>, + <0xfd922d80 0x7b>; + clock-names = "iface_clk"; + clocks = <&mmcc MDSS_AHB_CLK>; + vddio-supply = <&pma8084_l12>; + + qcom,dsi-phy-regulator-ldo-mode; + }; diff --git a/Documentation/devicetree/bindings/display/msm/edp.txt b/Documentation/devicetree/bindings/display/msm/edp.txt new file mode 100644 index 000000000..3a20f6ea5 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/edp.txt @@ -0,0 +1,60 @@ +Qualcomm Technologies Inc. adreno/snapdragon eDP output + +Required properties: +- compatible: + * "qcom,mdss-edp" +- reg: Physical base address and length of the registers of controller and PLL +- reg-names: The names of register regions. The following regions are required: + * "edp" + * "pll_base" +- interrupts: The interrupt signal from the eDP block. +- power-domains: Should be <&mmcc MDSS_GDSC>. +- clocks: device clocks + See Documentation/devicetree/bindings/clocks/clock-bindings.txt for details. +- clock-names: the following clocks are required: + * "core_clk" + * "iface_clk" + * "mdp_core_clk" + * "pixel_clk" + * "link_clk" +- #clock-cells: The value should be 1. +- vdda-supply: phandle to vdda regulator device node +- lvl-vdd-supply: phandle to regulator device node which is used to supply power + to HPD receiving chip +- panel-en-gpios: GPIO pin to supply power to panel. +- panel-hpd-gpios: GPIO pin used for eDP hpd. + + +Optional properties: +- interrupt-parent: phandle to the MDP block if the interrupt signal is routed + through MDP block + +Example: + mdss_edp: qcom,mdss_edp@fd923400 { + compatible = "qcom,mdss-edp"; + reg-names = + "edp", + "pll_base"; + reg = <0xfd923400 0x700>, + <0xfd923a00 0xd4>; + interrupt-parent = <&mdss_mdp>; + interrupts = <12 0>; + power-domains = <&mmcc MDSS_GDSC>; + clock-names = + "core_clk", + "pixel_clk", + "iface_clk", + "link_clk", + "mdp_core_clk"; + clocks = + <&mmcc MDSS_EDPAUX_CLK>, + <&mmcc MDSS_EDPPIXEL_CLK>, + <&mmcc MDSS_AHB_CLK>, + <&mmcc MDSS_EDPLINK_CLK>, + <&mmcc MDSS_MDP_CLK>; + #clock-cells = <1>; + vdda-supply = <&pma8084_l12>; + lvl-vdd-supply = <&lvl_vreg>; + panel-en-gpios = <&tlmm 137 0>; + panel-hpd-gpios = <&tlmm 103 0>; + }; diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt b/Documentation/devicetree/bindings/display/msm/gpu.txt new file mode 100644 index 000000000..67d0a58db --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/gpu.txt @@ -0,0 +1,52 @@ +Qualcomm adreno/snapdragon GPU + +Required properties: +- compatible: "qcom,adreno-3xx" +- 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. + +Example: + +/ { + ... + + gpu: qcom,kgsl-3d0@4300000 { + compatible = "qcom,adreno-3xx"; + reg = <0x04300000 0x20000>; + reg-names = "kgsl_3d0_reg_memory"; + interrupts = ; + interrupt-names = "kgsl_3d0_irq"; + clock-names = + "core_clk", + "iface_clk", + "mem_iface_clk"; + 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/msm/hdmi.txt b/Documentation/devicetree/bindings/display/msm/hdmi.txt new file mode 100644 index 000000000..379ee2ea9 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/hdmi.txt @@ -0,0 +1,58 @@ +Qualcomm adreno/snapdragon hdmi output + +Required properties: +- compatible: one of the following + * "qcom,hdmi-tx-8996" + * "qcom,hdmi-tx-8994" + * "qcom,hdmi-tx-8084" + * "qcom,hdmi-tx-8974" + * "qcom,hdmi-tx-8660" + * "qcom,hdmi-tx-8960" +- reg: Physical base address and length of the controller's registers +- reg-names: "core_physical" +- interrupts: The interrupt signal from the hdmi block. +- clocks: device clocks + See ../clocks/clock-bindings.txt for details. +- qcom,hdmi-tx-ddc-clk-gpio: ddc clk pin +- qcom,hdmi-tx-ddc-data-gpio: ddc data pin +- qcom,hdmi-tx-hpd-gpio: hpd pin +- core-vdda-supply: phandle to supply regulator +- hdmi-mux-supply: phandle to mux regulator + +Optional properties: +- qcom,hdmi-tx-mux-en-gpio: hdmi mux enable pin +- qcom,hdmi-tx-mux-sel-gpio: hdmi mux select pin +- power-domains: reference to the power domain(s), if available. +- pinctrl-names: the pin control state names; should contain "default" +- pinctrl-0: the default pinctrl state (active) +- pinctrl-1: the "sleep" pinctrl state + +Example: + +/ { + ... + + hdmi: qcom,hdmi-tx-8960@4a00000 { + compatible = "qcom,hdmi-tx-8960"; + reg-names = "core_physical"; + reg = <0x04a00000 0x1000>; + interrupts = ; + power-domains = <&mmcc MDSS_GDSC>; + clock-names = + "core_clk", + "master_iface_clk", + "slave_iface_clk"; + clocks = + <&mmcc HDMI_APP_CLK>, + <&mmcc HDMI_M_AHB_CLK>, + <&mmcc HDMI_S_AHB_CLK>; + qcom,hdmi-tx-ddc-clk = <&msmgpio 70 GPIO_ACTIVE_HIGH>; + qcom,hdmi-tx-ddc-data = <&msmgpio 71 GPIO_ACTIVE_HIGH>; + qcom,hdmi-tx-hpd = <&msmgpio 72 GPIO_ACTIVE_HIGH>; + core-vdda-supply = <&pm8921_hdmi_mvs>; + hdmi-mux-supply = <&ext_3p3v>; + pinctrl-names = "default", "sleep"; + pinctrl-0 = <&hpd_active &ddc_active &cec_active>; + pinctrl-1 = <&hpd_suspend &ddc_suspend &cec_suspend>; + }; +}; diff --git a/Documentation/devicetree/bindings/display/msm/mdp.txt b/Documentation/devicetree/bindings/display/msm/mdp.txt new file mode 100644 index 000000000..0833edaba --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/mdp.txt @@ -0,0 +1,49 @@ +Qualcomm adreno/snapdragon display controller + +Required properties: +- compatible: + * "qcom,mdp" - mdp4 +- reg: Physical base address and length of the controller's registers. +- interrupts: The interrupt signal from the display controller. +- connectors: array of phandles for output device(s) +- clocks: device clocks + See ../clocks/clock-bindings.txt for details. +- clock-names: the following clocks are required: + * "core_clk" + * "iface_clk" + * "src_clk" + * "hdmi_clk" + * "mpd_clk" + +Optional properties: +- gpus: phandle for gpu device +- clock-names: the following clocks are optional: + * "lut_clk" + +Example: + +/ { + ... + + mdp: qcom,mdp@5100000 { + compatible = "qcom,mdp"; + reg = <0x05100000 0xf0000>; + interrupts = ; + connectors = <&hdmi>; + gpus = <&gpu>; + clock-names = + "core_clk", + "iface_clk", + "lut_clk", + "src_clk", + "hdmi_clk", + "mdp_clk"; + clocks = + <&mmcc MDP_SRC>, + <&mmcc MDP_AHB_CLK>, + <&mmcc MDP_LUT_CLK>, + <&mmcc TV_SRC>, + <&mmcc HDMI_TV_CLK>, + <&mmcc MDP_TV_CLK>; + }; +}; diff --git a/Documentation/devicetree/bindings/display/mxsfb.txt b/Documentation/devicetree/bindings/display/mxsfb.txt new file mode 100644 index 000000000..96ec5179c --- /dev/null +++ b/Documentation/devicetree/bindings/display/mxsfb.txt @@ -0,0 +1,49 @@ +* Freescale MXS LCD Interface (LCDIF) + +Required properties: +- compatible: Should be "fsl,-lcdif". Supported chips include + imx23 and imx28. +- reg: Address and length of the register set for lcdif +- interrupts: Should contain lcdif interrupts +- display : phandle to display node (see below for details) + +* display node + +Required properties: +- bits-per-pixel : <16> for RGB565, <32> for RGB888/666. +- bus-width : number of data lines. Could be <8>, <16>, <18> or <24>. + +Required sub-node: +- display-timings : Refer to binding doc display-timing.txt for details. + +Examples: + +lcdif@80030000 { + compatible = "fsl,imx28-lcdif"; + reg = <0x80030000 2000>; + interrupts = <38 86>; + + display: display { + bits-per-pixel = <32>; + bus-width = <24>; + + display-timings { + native-mode = <&timing0>; + timing0: timing0 { + clock-frequency = <33500000>; + hactive = <800>; + vactive = <480>; + hfront-porch = <164>; + hback-porch = <89>; + hsync-len = <10>; + vback-porch = <23>; + vfront-porch = <10>; + vsync-len = <10>; + hsync-active = <0>; + vsync-active = <0>; + de-active = <1>; + pixelclk-active = <0>; + }; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/display/panel/ampire,am800480r3tmqwa1h.txt b/Documentation/devicetree/bindings/display/panel/ampire,am800480r3tmqwa1h.txt new file mode 100644 index 000000000..83e2cae1c --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/ampire,am800480r3tmqwa1h.txt @@ -0,0 +1,7 @@ +Ampire AM-800480R3TMQW-A1H 7.0" WVGA TFT LCD panel + +Required properties: +- compatible: should be "ampire,am800480r3tmqwa1h" + +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/auo,b080uan01.txt b/Documentation/devicetree/bindings/display/panel/auo,b080uan01.txt new file mode 100644 index 000000000..bae0e2b51 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/auo,b080uan01.txt @@ -0,0 +1,7 @@ +AU Optronics Corporation 8.0" WUXGA TFT LCD panel + +Required properties: +- compatible: should be "auo,b101ean01" + +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/auo,b101aw03.txt b/Documentation/devicetree/bindings/display/panel/auo,b101aw03.txt new file mode 100644 index 000000000..72e088a4f --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/auo,b101aw03.txt @@ -0,0 +1,7 @@ +AU Optronics Corporation 10.1" WSVGA TFT LCD panel + +Required properties: +- compatible: should be "auo,b101aw03" + +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/auo,b101ean01.txt b/Documentation/devicetree/bindings/display/panel/auo,b101ean01.txt new file mode 100644 index 000000000..3590b0741 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/auo,b101ean01.txt @@ -0,0 +1,7 @@ +AU Optronics Corporation 10.1" WSVGA TFT LCD panel + +Required properties: +- compatible: should be "auo,b101ean01" + +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/auo,b101xtn01.txt b/Documentation/devicetree/bindings/display/panel/auo,b101xtn01.txt new file mode 100644 index 000000000..889d511d6 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/auo,b101xtn01.txt @@ -0,0 +1,7 @@ +AU Optronics Corporation 10.1" WXGA TFT LCD panel + +Required properties: +- compatible: should be "auo,b101xtn01" + +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/auo,b116xw03.txt b/Documentation/devicetree/bindings/display/panel/auo,b116xw03.txt new file mode 100644 index 000000000..690d0a568 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/auo,b116xw03.txt @@ -0,0 +1,7 @@ +AU Optronics Corporation 11.6" HD (1366x768) color TFT-LCD panel + +Required properties: +- compatible: should be "auo,b116xw03" + +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/auo,b133htn01.txt b/Documentation/devicetree/bindings/display/panel/auo,b133htn01.txt new file mode 100644 index 000000000..302226b5b --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/auo,b133htn01.txt @@ -0,0 +1,7 @@ +AU Optronics Corporation 13.3" FHD (1920x1080) color TFT-LCD panel + +Required properties: +- compatible: should be "auo,b133htn01" + +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/auo,b133xtn01.txt b/Documentation/devicetree/bindings/display/panel/auo,b133xtn01.txt new file mode 100644 index 000000000..7443b7c76 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/auo,b133xtn01.txt @@ -0,0 +1,7 @@ +AU Optronics Corporation 13.3" WXGA (1366x768) TFT LCD panel + +Required properties: +- compatible: should be "auo,b133xtn01" + +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/avic,tm070ddh03.txt b/Documentation/devicetree/bindings/display/panel/avic,tm070ddh03.txt new file mode 100644 index 000000000..b6f2f3e8f --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/avic,tm070ddh03.txt @@ -0,0 +1,7 @@ +Shanghai AVIC Optoelectronics 7" 1024x600 color TFT-LCD panel + +Required properties: +- compatible: should be "avic,tm070ddh03" + +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/chunghwa,claa101wa01a.txt b/Documentation/devicetree/bindings/display/panel/chunghwa,claa101wa01a.txt new file mode 100644 index 000000000..f24614e4d --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/chunghwa,claa101wa01a.txt @@ -0,0 +1,7 @@ +Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel + +Required properties: +- compatible: should be "chunghwa,claa101wa01a" + +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/chunghwa,claa101wb03.txt b/Documentation/devicetree/bindings/display/panel/chunghwa,claa101wb03.txt new file mode 100644 index 000000000..0ab2c05a4 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/chunghwa,claa101wb03.txt @@ -0,0 +1,7 @@ +Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel + +Required properties: +- compatible: should be "chunghwa,claa101wb03" + +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/display-timing.txt b/Documentation/devicetree/bindings/display/panel/display-timing.txt new file mode 100644 index 000000000..e1d4a0b59 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/display-timing.txt @@ -0,0 +1,110 @@ +display-timing bindings +======================= + +display-timings node +-------------------- + +required properties: + - none + +optional properties: + - native-mode: The native mode for the display, in case multiple modes are + provided. When omitted, assume the first node is the native. + +timing subnode +-------------- + +required properties: + - hactive, vactive: display resolution + - hfront-porch, hback-porch, hsync-len: horizontal display timing parameters + in pixels + vfront-porch, vback-porch, vsync-len: vertical display timing parameters in + lines + - clock-frequency: display clock in Hz + +optional properties: + - hsync-active: hsync pulse is active low/high/ignored + - vsync-active: vsync pulse is active low/high/ignored + - de-active: data-enable pulse is active low/high/ignored + - pixelclk-active: with + - active high = drive pixel data on rising edge/ + sample data on falling edge + - active low = drive pixel data on falling edge/ + sample data on rising edge + - ignored = ignored + - interlaced (bool): boolean to enable interlaced mode + - doublescan (bool): boolean to enable doublescan mode + - doubleclk (bool): boolean to enable doubleclock mode + +All the optional properties that are not bool follow the following logic: + <1>: high active + <0>: low active + omitted: not used on hardware + +There are different ways of describing the capabilities of a display. The +devicetree representation corresponds to the one commonly found in datasheets +for displays. If a display supports multiple signal timings, the native-mode +can be specified. + +The parameters are defined as: + + +----------+-------------------------------------+----------+-------+ + | | ↑ | | | + | | |vback_porch | | | + | | ↓ | | | + +----------#######################################----------+-------+ + | # ↑ # | | + | # | # | | + | hback # | # hfront | hsync | + | porch # | hactive # porch | len | + |<-------->#<-------+--------------------------->#<-------->|<----->| + | # | # | | + | # |vactive # | | + | # | # | | + | # ↓ # | | + +----------#######################################----------+-------+ + | | ↑ | | | + | | |vfront_porch | | | + | | ↓ | | | + +----------+-------------------------------------+----------+-------+ + | | ↑ | | | + | | |vsync_len | | | + | | ↓ | | | + +----------+-------------------------------------+----------+-------+ + +Example: + + display-timings { + native-mode = <&timing0>; + timing0: 1080p24 { + /* 1920x1080p24 */ + clock-frequency = <52000000>; + hactive = <1920>; + vactive = <1080>; + hfront-porch = <25>; + hback-porch = <25>; + hsync-len = <25>; + vback-porch = <2>; + vfront-porch = <2>; + vsync-len = <2>; + hsync-active = <1>; + }; + }; + +Every required property also supports the use of ranges, so the commonly used +datasheet description with minimum, typical and maximum values can be used. + +Example: + + timing1: timing { + /* 1920x1080p24 */ + clock-frequency = <148500000>; + hactive = <1920>; + vactive = <1080>; + hsync-len = <0 44 60>; + hfront-porch = <80 88 95>; + hback-porch = <100 148 160>; + vfront-porch = <0 4 6>; + vback-porch = <0 36 50>; + vsync-len = <0 5 6>; + }; diff --git a/Documentation/devicetree/bindings/display/panel/edt,et057090dhu.txt b/Documentation/devicetree/bindings/display/panel/edt,et057090dhu.txt new file mode 100644 index 000000000..4903d7b1d --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/edt,et057090dhu.txt @@ -0,0 +1,7 @@ +Emerging Display Technology Corp. 5.7" VGA TFT LCD panel + +Required properties: +- compatible: should be "edt,et057090dhu" + +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/edt,et070080dh6.txt b/Documentation/devicetree/bindings/display/panel/edt,et070080dh6.txt new file mode 100644 index 000000000..20cb38e83 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/edt,et070080dh6.txt @@ -0,0 +1,10 @@ +Emerging Display Technology Corp. ET070080DH6 7.0" WVGA TFT LCD panel + +Required properties: +- compatible: should be "edt,et070080dh6" + +This panel is the same as ETM0700G0DH6 except for the touchscreen. +ET070080DH6 is the model with resistive touch. + +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/edt,etm0700g0dh6.txt b/Documentation/devicetree/bindings/display/panel/edt,etm0700g0dh6.txt new file mode 100644 index 000000000..ee4b18053 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/edt,etm0700g0dh6.txt @@ -0,0 +1,10 @@ +Emerging Display Technology Corp. ETM0700G0DH6 7.0" WVGA TFT LCD panel + +Required properties: +- compatible: should be "edt,etm0700g0dh6" + +This panel is the same as ET070080DH6 except for the touchscreen. +ETM0700G0DH6 is the model with capacitive multitouch. + +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/foxlink,fl500wvr00-a0t.txt b/Documentation/devicetree/bindings/display/panel/foxlink,fl500wvr00-a0t.txt new file mode 100644 index 000000000..b47f9d87b --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/foxlink,fl500wvr00-a0t.txt @@ -0,0 +1,7 @@ +Foxlink Group 5" WVGA TFT LCD panel + +Required properties: +- compatible: should be "foxlink,fl500wvr00-a0t" + +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/giantplus,gpg482739qs5.txt b/Documentation/devicetree/bindings/display/panel/giantplus,gpg482739qs5.txt new file mode 100644 index 000000000..24b0b6244 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/giantplus,gpg482739qs5.txt @@ -0,0 +1,7 @@ +GiantPlus GPG48273QS5 4.3" (480x272) WQVGA TFT LCD panel + +Required properties: +- compatible: should be "giantplus,gpg48273qs5" + +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/hannstar,hsd070pww1.txt b/Documentation/devicetree/bindings/display/panel/hannstar,hsd070pww1.txt new file mode 100644 index 000000000..7da1d5c03 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/hannstar,hsd070pww1.txt @@ -0,0 +1,7 @@ +HannStar Display Corp. HSD070PWW1 7.0" WXGA TFT LCD panel + +Required properties: +- compatible: should be "hannstar,hsd070pww1" + +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/hannstar,hsd100pxn1.txt b/Documentation/devicetree/bindings/display/panel/hannstar,hsd100pxn1.txt new file mode 100644 index 000000000..8270319a9 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/hannstar,hsd100pxn1.txt @@ -0,0 +1,7 @@ +HannStar Display Corp. HSD100PXN1 10.1" XGA LVDS panel + +Required properties: +- compatible: should be "hannstar,hsd100pxn1" + +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/hit,tx23d38vm0caa.txt b/Documentation/devicetree/bindings/display/panel/hit,tx23d38vm0caa.txt new file mode 100644 index 000000000..04caaae19 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/hit,tx23d38vm0caa.txt @@ -0,0 +1,7 @@ +Hitachi Ltd. Corporation 9" WVGA (800x480) TFT LCD panel + +Required properties: +- compatible: should be "hit,tx23d38vm0caa" + +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/innolux,at043tn24.txt b/Documentation/devicetree/bindings/display/panel/innolux,at043tn24.txt new file mode 100644 index 000000000..4104226b6 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/innolux,at043tn24.txt @@ -0,0 +1,7 @@ +Innolux AT043TN24 4.3" WQVGA TFT LCD panel + +Required properties: +- compatible: should be "innolux,at043tn24" + +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/innolux,g121i1-l01.txt b/Documentation/devicetree/bindings/display/panel/innolux,g121i1-l01.txt new file mode 100644 index 000000000..2743b07cd --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/innolux,g121i1-l01.txt @@ -0,0 +1,7 @@ +Innolux Corporation 12.1" WXGA (1280x800) TFT LCD panel + +Required properties: +- compatible: should be "innolux,g121i1-l01" + +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/innolux,n116bge.txt b/Documentation/devicetree/bindings/display/panel/innolux,n116bge.txt new file mode 100644 index 000000000..081bb939e --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/innolux,n116bge.txt @@ -0,0 +1,7 @@ +Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel + +Required properties: +- compatible: should be "innolux,n116bge" + +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/innolux,n156bge-l21.txt b/Documentation/devicetree/bindings/display/panel/innolux,n156bge-l21.txt new file mode 100644 index 000000000..7825844aa --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/innolux,n156bge-l21.txt @@ -0,0 +1,7 @@ +InnoLux 15.6" WXGA TFT LCD panel + +Required properties: +- compatible: should be "innolux,n156bge-l21" + +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/innolux,zj070na-01p.txt b/Documentation/devicetree/bindings/display/panel/innolux,zj070na-01p.txt new file mode 100644 index 000000000..824f87f15 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/innolux,zj070na-01p.txt @@ -0,0 +1,7 @@ +Innolux Corporation 7.0" WSVGA (1024x600) TFT LCD panel + +Required properties: +- compatible: should be "innolux,zj070na-01p" + +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/lg,lb070wv8.txt b/Documentation/devicetree/bindings/display/panel/lg,lb070wv8.txt new file mode 100644 index 000000000..a7588e525 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/lg,lb070wv8.txt @@ -0,0 +1,7 @@ +LG 7" (800x480 pixels) TFT LCD panel + +Required properties: +- compatible: should be "lg,lb070wv8" + +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/lg,ld070wx3-sl01.txt b/Documentation/devicetree/bindings/display/panel/lg,ld070wx3-sl01.txt new file mode 100644 index 000000000..5e649cb9a --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/lg,ld070wx3-sl01.txt @@ -0,0 +1,7 @@ +LG Corporation 7" WXGA TFT LCD panel + +Required properties: +- compatible: should be "lg,ld070wx3-sl01" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/display/panel/lg,lg4573.txt b/Documentation/devicetree/bindings/display/panel/lg,lg4573.txt new file mode 100644 index 000000000..824441f4e --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/lg,lg4573.txt @@ -0,0 +1,19 @@ +LG LG4573 TFT Liquid Crystal Display with SPI control bus + +Required properties: + - compatible: "lg,lg4573" + - reg: address of the panel on the SPI bus + +The panel must obey rules for SPI slave device specified in document [1]. + +[1]: Documentation/devicetree/bindings/spi/spi-bus.txt + +Example: + + lcd_panel: display@0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "lg,lg4573"; + spi-max-frequency = <10000000>; + reg = <0>; + }; diff --git a/Documentation/devicetree/bindings/display/panel/lg,lh500wx1-sd03.txt b/Documentation/devicetree/bindings/display/panel/lg,lh500wx1-sd03.txt new file mode 100644 index 000000000..a04fd2b2e --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/lg,lh500wx1-sd03.txt @@ -0,0 +1,7 @@ +LG Corporation 5" HD TFT LCD panel + +Required properties: +- compatible: should be "lg,lh500wx1-sd03" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/display/panel/lg,lp129qe.txt b/Documentation/devicetree/bindings/display/panel/lg,lp129qe.txt new file mode 100644 index 000000000..9f262e0c5 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/lg,lp129qe.txt @@ -0,0 +1,7 @@ +LG 12.9" (2560x1700 pixels) TFT LCD panel + +Required properties: +- compatible: should be "lg,lp129qe" + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.txt b/Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.txt new file mode 100644 index 000000000..1a1e653e5 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/lgphilips,lb035q02.txt @@ -0,0 +1,33 @@ +LG.Philips LB035Q02 Panel +========================= + +Required properties: +- compatible: "lgphilips,lb035q02" +- enable-gpios: panel enable gpio + +Optional properties: +- label: a symbolic name for the panel + +Required nodes: +- Video port for DPI input + +Example +------- + +lcd-panel: panel@0 { + compatible = "lgphilips,lb035q02"; + reg = <0>; + spi-max-frequency = <100000>; + spi-cpol; + spi-cpha; + + label = "lcd"; + + enable-gpios = <&gpio7 7 0>; + + port { + lcd_in: endpoint { + remote-endpoint = <&dpi_out>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/display/panel/nec,nl4827hc19-05b.txt b/Documentation/devicetree/bindings/display/panel/nec,nl4827hc19-05b.txt new file mode 100644 index 000000000..8e1914d1e --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/nec,nl4827hc19-05b.txt @@ -0,0 +1,7 @@ +NEC LCD Technologies,Ltd. WQVGA TFT LCD panel + +Required properties: +- compatible: should be "nec,nl4827hc19-05b" + +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/okaya,rs800480t-7x0gp.txt b/Documentation/devicetree/bindings/display/panel/okaya,rs800480t-7x0gp.txt new file mode 100644 index 000000000..ddf8e211d --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/okaya,rs800480t-7x0gp.txt @@ -0,0 +1,7 @@ +OKAYA Electric America, Inc. RS800480T-7X0GP 7" WVGA LCD panel + +Required properties: +- compatible: should be "okaya,rs800480t-7x0gp" + +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/ortustech,com43h4m85ulc.txt b/Documentation/devicetree/bindings/display/panel/ortustech,com43h4m85ulc.txt new file mode 100644 index 000000000..de19e9398 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/ortustech,com43h4m85ulc.txt @@ -0,0 +1,7 @@ +OrtusTech COM43H4M85ULC Blanview 3.7" TFT-LCD panel + +Required properties: +- compatible: should be "ortustech,com43h4m85ulc" + +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/panasonic,vvx10f004b00.txt b/Documentation/devicetree/bindings/display/panel/panasonic,vvx10f004b00.txt new file mode 100644 index 000000000..d328b0341 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/panasonic,vvx10f004b00.txt @@ -0,0 +1,7 @@ +Panasonic Corporation 10.1" WUXGA TFT LCD panel + +Required properties: +- compatible: should be "panasonic,vvx10f004b00" + +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-dpi.txt b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt new file mode 100644 index 000000000..216c894d4 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt @@ -0,0 +1,45 @@ +Generic MIPI DPI Panel +====================== + +Required properties: +- compatible: "panel-dpi" + +Optional properties: +- label: a symbolic name for the panel +- enable-gpios: panel enable gpio + +Required nodes: +- "panel-timing" containing video timings + (Documentation/devicetree/bindings/display/display-timing.txt) +- Video port for DPI input + +Example +------- + +lcd0: display@0 { + compatible = "samsung,lte430wq-f0c", "panel-dpi"; + label = "lcd"; + + port { + lcd_in: endpoint { + remote-endpoint = <&dpi_out>; + }; + }; + + panel-timing { + clock-frequency = <9200000>; + hactive = <480>; + vactive = <272>; + hfront-porch = <8>; + hback-porch = <4>; + hsync-len = <41>; + vback-porch = <2>; + vfront-porch = <4>; + vsync-len = <10>; + + hsync-active = <0>; + vsync-active = <0>; + de-active = <1>; + pixelclk-active = <1>; + }; +}; diff --git a/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.txt b/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.txt new file mode 100644 index 000000000..dce48eb9d --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/panel-dsi-cm.txt @@ -0,0 +1,29 @@ +Generic MIPI DSI Command Mode Panel +=================================== + +Required properties: +- compatible: "panel-dsi-cm" + +Optional properties: +- label: a symbolic name for the panel +- reset-gpios: panel reset gpio +- te-gpios: panel TE gpio + +Required nodes: +- Video port for DSI input + +Example +------- + +lcd0: display { + compatible = "tpo,taal", "panel-dsi-cm"; + label = "lcd0"; + + reset-gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; + + port { + lcd0_in: endpoint { + remote-endpoint = <&dsi1_out_ep>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/display/panel/samsung,ld9040.txt b/Documentation/devicetree/bindings/display/panel/samsung,ld9040.txt new file mode 100644 index 000000000..fc595d9b9 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/samsung,ld9040.txt @@ -0,0 +1,66 @@ +Samsung LD9040 AMOLED LCD parallel RGB panel with SPI control bus + +Required properties: + - compatible: "samsung,ld9040" + - reg: address of the panel on SPI bus + - vdd3-supply: core voltage supply + - vci-supply: voltage supply for analog circuits + - reset-gpios: a GPIO spec for the reset pin + - display-timings: timings for the connected panel according to [1] + +The panel must obey rules for SPI slave device specified in document [2]. + +Optional properties: + - power-on-delay: delay after turning regulators on [ms] + - reset-delay: delay after reset sequence [ms] + - panel-width-mm: physical panel width [mm] + - panel-height-mm: physical panel height [mm] + +The device node can contain one 'port' child node with one child +'endpoint' node, according to the bindings defined in [3]. This +node should describe panel's video bus. + +[1]: Documentation/devicetree/bindings/display/display-timing.txt +[2]: Documentation/devicetree/bindings/spi/spi-bus.txt +[3]: Documentation/devicetree/bindings/media/video-interfaces.txt + +Example: + + lcd@0 { + compatible = "samsung,ld9040"; + reg = <0>; + vdd3-supply = <&ldo7_reg>; + vci-supply = <&ldo17_reg>; + reset-gpios = <&gpy4 5 0>; + spi-max-frequency = <1200000>; + spi-cpol; + spi-cpha; + power-on-delay = <10>; + reset-delay = <10>; + panel-width-mm = <90>; + panel-height-mm = <154>; + + display-timings { + timing { + clock-frequency = <23492370>; + hactive = <480>; + vactive = <800>; + hback-porch = <16>; + hfront-porch = <16>; + vback-porch = <2>; + vfront-porch = <28>; + hsync-len = <2>; + vsync-len = <1>; + hsync-active = <0>; + vsync-active = <0>; + de-active = <0>; + pixelclk-active = <0>; + }; + }; + + port { + lcd_ep: endpoint { + remote-endpoint = <&fimd_dpi_ep>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/panel/samsung,ltn101nt05.txt b/Documentation/devicetree/bindings/display/panel/samsung,ltn101nt05.txt new file mode 100644 index 000000000..ef522c6bb --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/samsung,ltn101nt05.txt @@ -0,0 +1,7 @@ +Samsung Electronics 10.1" WSVGA TFT LCD panel + +Required properties: +- compatible: should be "samsung,ltn101nt05" + +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/samsung,ltn140at29-301.txt b/Documentation/devicetree/bindings/display/panel/samsung,ltn140at29-301.txt new file mode 100644 index 000000000..e7f969d89 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/samsung,ltn140at29-301.txt @@ -0,0 +1,7 @@ +Samsung Electronics 14" WXGA (1366x768) TFT LCD panel + +Required properties: +- compatible: should be "samsung,ltn140at29-301" + +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/samsung,s6e8aa0.txt b/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.txt new file mode 100644 index 000000000..25701c81b --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e8aa0.txt @@ -0,0 +1,56 @@ +Samsung S6E8AA0 AMOLED LCD 5.3 inch panel + +Required properties: + - compatible: "samsung,s6e8aa0" + - reg: the virtual channel number of a DSI peripheral + - vdd3-supply: core voltage supply + - vci-supply: voltage supply for analog circuits + - reset-gpios: a GPIO spec for the reset pin + - display-timings: timings for the connected panel as described by [1] + +Optional properties: + - power-on-delay: delay after turning regulators on [ms] + - reset-delay: delay after reset sequence [ms] + - init-delay: delay after initialization sequence [ms] + - panel-width-mm: physical panel width [mm] + - panel-height-mm: physical panel height [mm] + - flip-horizontal: boolean to flip image horizontally + - flip-vertical: boolean to flip image vertically + +The device node can contain one 'port' child node with one child +'endpoint' node, according to the bindings defined in [2]. This +node should describe panel's video bus. + +[1]: Documentation/devicetree/bindings/display/display-timing.txt +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt + +Example: + + panel { + compatible = "samsung,s6e8aa0"; + reg = <0>; + vdd3-supply = <&vcclcd_reg>; + vci-supply = <&vlcd_reg>; + reset-gpios = <&gpy4 5 0>; + power-on-delay= <50>; + reset-delay = <100>; + init-delay = <100>; + panel-width-mm = <58>; + panel-height-mm = <103>; + flip-horizontal; + flip-vertical; + + display-timings { + timing0: timing-0 { + clock-frequency = <57153600>; + hactive = <720>; + vactive = <1280>; + hfront-porch = <5>; + hback-porch = <5>; + hsync-len = <5>; + vfront-porch = <13>; + vback-porch = <1>; + vsync-len = <2>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.txt b/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.txt new file mode 100644 index 000000000..f522bb8e4 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/sharp,lq101r1sx01.txt @@ -0,0 +1,49 @@ +Sharp Microelectronics 10.1" WQXGA TFT LCD panel + +This panel requires a dual-channel DSI host to operate. It supports two modes: +- left-right: each channel drives the left or right half of the screen +- even-odd: each channel drives the even or odd lines of the screen + +Each of the DSI channels controls a separate DSI peripheral. The peripheral +driven by the first link (DSI-LINK1), left or even, is considered the primary +peripheral and controls the device. The 'link2' property contains a phandle +to the peripheral driven by the second link (DSI-LINK2, right or odd). + +Note that in video mode the DSI-LINK1 interface always provides the left/even +pixels and DSI-LINK2 always provides the right/odd pixels. In command mode it +is possible to program either link to drive the left/even or right/odd pixels +but for the sake of consistency this binding assumes that the same assignment +is chosen as for video mode. + +Required properties: +- compatible: should be "sharp,lq101r1sx01" +- reg: DSI virtual channel of the peripheral + +Required properties (for DSI-LINK1 only): +- link2: phandle to the DSI peripheral on the secondary link. Note that the + presence of this property marks the containing node as DSI-LINK1. +- power-supply: phandle of the regulator that provides the supply voltage + +Optional properties (for DSI-LINK1 only): +- backlight: phandle of the backlight device attached to the panel + +Example: + + dsi@54300000 { + panel: panel@0 { + compatible = "sharp,lq101r1sx01"; + reg = <0>; + + link2 = <&secondary>; + + power-supply = <...>; + backlight = <...>; + }; + }; + + dsi@54400000 { + secondary: panel@0 { + compatible = "sharp,lq101r1sx01"; + reg = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/display/panel/sharp,ls037v7dw01.txt b/Documentation/devicetree/bindings/display/panel/sharp,ls037v7dw01.txt new file mode 100644 index 000000000..0cc8981e9 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/sharp,ls037v7dw01.txt @@ -0,0 +1,43 @@ +SHARP LS037V7DW01 TFT-LCD panel +=================================== + +Required properties: +- compatible: "sharp,ls037v7dw01" + +Optional properties: +- label: a symbolic name for the panel +- enable-gpios: a GPIO spec for the optional enable pin. + This pin is the INI pin as specified in the LS037V7DW01.pdf file. +- reset-gpios: a GPIO spec for the optional reset pin. + This pin is the RESB pin as specified in the LS037V7DW01.pdf file. +- mode-gpios: a GPIO + ordered MO, LR, and UD as specified in the LS037V7DW01.pdf file. + +Required nodes: +- Video port for DPI input + +This panel can have zero to five GPIOs to configure to change configuration +between QVGA and VGA mode and the scan direction. As these pins can be also +configured with external pulls, all the GPIOs are considered optional with holes +in the array. + +Example +------- + +Example when connected to a omap2+ based device: + +lcd0: display { + compatible = "sharp,ls037v7dw01"; + power-supply = <&lcd_3v3>; + enable-gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>; /* gpio152, lcd INI */ + reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd RESB */ + mode-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH /* gpio154, lcd MO */ + &gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */ + &gpio1 3 GPIO_ACTIVE_HIGH>; /* gpio3, lcd UD */ + + port { + lcd_in: endpoint { + remote-endpoint = <&dpi_out>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/display/panel/shelly,sca07010-bfn-lnn.txt b/Documentation/devicetree/bindings/display/panel/shelly,sca07010-bfn-lnn.txt new file mode 100644 index 000000000..fc1ea9e26 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/shelly,sca07010-bfn-lnn.txt @@ -0,0 +1,7 @@ +Shelly SCA07010-BFN-LNN 7.0" WVGA TFT LCD panel + +Required properties: +- compatible: should be "shelly,sca07010-bfn-lnn" + +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/simple-panel.txt b/Documentation/devicetree/bindings/display/panel/simple-panel.txt new file mode 100644 index 000000000..1341bbf4a --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/simple-panel.txt @@ -0,0 +1,21 @@ +Simple display panel + +Required properties: +- power-supply: regulator to provide the supply voltage + +Optional properties: +- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing +- enable-gpios: GPIO pin to enable or disable the panel +- backlight: phandle of the backlight device attached to the panel + +Example: + + panel: panel { + compatible = "cptt,claa101wb01"; + ddc-i2c-bus = <&panelddc>; + + power-supply = <&vdd_pnl_reg>; + enable-gpios = <&gpio 90 0>; + + backlight = <&backlight>; + }; diff --git a/Documentation/devicetree/bindings/display/panel/sony,acx565akm.txt b/Documentation/devicetree/bindings/display/panel/sony,acx565akm.txt new file mode 100644 index 000000000..e12333280 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/sony,acx565akm.txt @@ -0,0 +1,30 @@ +Sony ACX565AKM SDI Panel +======================== + +Required properties: +- compatible: "sony,acx565akm" + +Optional properties: +- label: a symbolic name for the panel +- reset-gpios: panel reset gpio + +Required nodes: +- Video port for SDI input + +Example +------- + +acx565akm@2 { + compatible = "sony,acx565akm"; + spi-max-frequency = <6000000>; + reg = <2>; + + label = "lcd"; + reset-gpios = <&gpio3 26 GPIO_ACTIVE_HIGH>; /* 90 */ + + port { + lcd_in: endpoint { + remote-endpoint = <&sdi_out>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt b/Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt new file mode 100644 index 000000000..7175dc374 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/toppoly,td028ttec1.txt @@ -0,0 +1,30 @@ +Toppoly TD028TTEC1 Panel +======================== + +Required properties: +- compatible: "toppoly,td028ttec1" + +Optional properties: +- label: a symbolic name for the panel + +Required nodes: +- Video port for DPI input + +Example +------- + +lcd-panel: td028ttec1@0 { + compatible = "toppoly,td028ttec1"; + reg = <0>; + spi-max-frequency = <100000>; + spi-cpol; + spi-cpha; + + label = "lcd"; + port { + lcd_in: endpoint { + remote-endpoint = <&dpi_out>; + }; + }; +}; + diff --git a/Documentation/devicetree/bindings/display/panel/tpo,td043mtea1.txt b/Documentation/devicetree/bindings/display/panel/tpo,td043mtea1.txt new file mode 100644 index 000000000..ec6d62975 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/tpo,td043mtea1.txt @@ -0,0 +1,33 @@ +TPO TD043MTEA1 Panel +==================== + +Required properties: +- compatible: "tpo,td043mtea1" +- reset-gpios: panel reset gpio + +Optional properties: +- label: a symbolic name for the panel + +Required nodes: +- Video port for DPI input + +Example +------- + +lcd-panel: panel@0 { + compatible = "tpo,td043mtea1"; + reg = <0>; + spi-max-frequency = <100000>; + spi-cpol; + spi-cpha; + + label = "lcd"; + + reset-gpios = <&gpio7 7 0>; + + port { + lcd_in: endpoint { + remote-endpoint = <&dpi_out>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt b/Documentation/devicetree/bindings/display/renesas,du.txt new file mode 100644 index 000000000..eccd4f486 --- /dev/null +++ b/Documentation/devicetree/bindings/display/renesas,du.txt @@ -0,0 +1,92 @@ +* Renesas R-Car Display Unit (DU) + +Required Properties: + + - compatible: must be one of the following. + - "renesas,du-r8a7779" for R8A7779 (R-Car H1) compatible DU + - "renesas,du-r8a7790" for R8A7790 (R-Car H2) compatible DU + - "renesas,du-r8a7791" for R8A7791 (R-Car M2-W) compatible DU + - "renesas,du-r8a7793" for R8A7793 (R-Car M2-N) compatible DU + - "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU + + - reg: A list of base address and length of each memory resource, one for + each entry in the reg-names property. + - reg-names: Name of the memory resources. The DU requires one memory + resource for the DU core (named "du") and one memory resource for each + LVDS encoder (named "lvds.x" with "x" being the LVDS controller numerical + index). + + - interrupt-parent: phandle of the parent interrupt controller. + - interrupts: Interrupt specifiers for the DU interrupts. + + - clocks: A list of phandles + clock-specifier pairs, one for each entry in + the clock-names property. + - clock-names: Name of the clocks. This property is model-dependent. + - R8A7779 uses a single functional clock. The clock doesn't need to be + named. + - R8A779[0134] use one functional clock per channel and one clock per LVDS + encoder (if available). The functional clocks must be named "du.x" with + "x" being the channel numerical index. The LVDS clocks must be named + "lvds.x" with "x" being the LVDS encoder numerical index. + - In addition to the functional and encoder clocks, all DU versions also + support externally supplied pixel clocks. Those clocks are optional. + When supplied they must be named "dclkin.x" with "x" being the input + clock numerical index. + +Required nodes: + +The connections to the DU output video ports are modeled using the OF graph +bindings specified in Documentation/devicetree/bindings/graph.txt. + +The following table lists for each supported model the port number +corresponding to each DU output. + + Port 0 Port1 Port2 +----------------------------------------------------------------------------- + R8A7779 (H1) DPAD 0 DPAD 1 - + R8A7790 (H2) DPAD LVDS 0 LVDS 1 + R8A7791 (M2-W) DPAD LVDS 0 - + R8A7793 (M2-N) DPAD LVDS 0 - + R8A7794 (E2) DPAD 0 DPAD 1 - + + +Example: R8A7790 (R-Car H2) DU + + du: du@feb00000 { + compatible = "renesas,du-r8a7790"; + reg = <0 0xfeb00000 0 0x70000>, + <0 0xfeb90000 0 0x1c>, + <0 0xfeb94000 0 0x1c>; + reg-names = "du", "lvds.0", "lvds.1"; + interrupt-parent = <&gic>; + interrupts = <0 256 IRQ_TYPE_LEVEL_HIGH>, + <0 268 IRQ_TYPE_LEVEL_HIGH>, + <0 269 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&mstp7_clks R8A7790_CLK_DU0>, + <&mstp7_clks R8A7790_CLK_DU1>, + <&mstp7_clks R8A7790_CLK_DU2>, + <&mstp7_clks R8A7790_CLK_LVDS0>, + <&mstp7_clks R8A7790_CLK_LVDS1>; + clock-names = "du.0", "du.1", "du.2", "lvds.0", "lvds.1"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + du_out_rgb: endpoint { + }; + }; + port@1 { + reg = <1>; + du_out_lvds0: endpoint { + }; + }; + port@2 { + reg = <2>; + du_out_lvds1: endpoint { + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt new file mode 100644 index 000000000..668091f27 --- /dev/null +++ b/Documentation/devicetree/bindings/display/rockchip/dw_hdmi-rockchip.txt @@ -0,0 +1,46 @@ +Rockchip specific extensions to the Synopsys Designware HDMI +================================ + +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. +- 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 + +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" + +Example: +hdmi: hdmi@ff980000 { + compatible = "rockchip,rk3288-dw-hdmi"; + reg = <0xff980000 0x20000>; + reg-io-width = <4>; + ddc-i2c-bus = <&i2c5>; + rockchip,grf = <&grf>; + interrupts = ; + clocks = <&cru PCLK_HDMI_CTRL>, <&cru SCLK_HDMI_HDCP>; + clock-names = "iahb", "isfr"; + status = "disabled"; + ports { + hdmi_in: port { + #address-cells = <1>; + #size-cells = <0>; + hdmi_in_vopb: endpoint@0 { + reg = <0>; + remote-endpoint = <&vopb_out_hdmi>; + }; + hdmi_in_vopl: endpoint@1 { + reg = <1>; + remote-endpoint = <&vopl_out_hdmi>; + }; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.txt b/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.txt new file mode 100644 index 000000000..5707af893 --- /dev/null +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.txt @@ -0,0 +1,19 @@ +Rockchip DRM master device +================================ + +The Rockchip DRM master device is a virtual device needed to list all +vop devices or other display interface nodes that comprise the +graphics subsystem. + +Required properties: +- compatible: Should be "rockchip,display-subsystem" +- ports: Should contain a list of phandles pointing to display interface port + of vop devices. vop definitions as defined in + Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt + +example: + +display-subsystem { + compatible = "rockchip,display-subsystem"; + ports = <&vopl_out>, <&vopb_out>; +}; diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt new file mode 100644 index 000000000..d15351f23 --- /dev/null +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt @@ -0,0 +1,58 @@ +device-tree bindings for rockchip soc display controller (vop) + +VOP (Visual Output Processor) is the Display Controller for the Rockchip +series of SoCs which transfers the image data from a video memory +buffer to an external LCD interface. + +Required properties: +- compatible: value should be one of the following + "rockchip,rk3288-vop"; + +- interrupts: should contain a list of all VOP IP block interrupts in the + order: VSYNC, LCD_SYSTEM. The interrupt specifier + format depends on the interrupt controller used. + +- clocks: must include clock specifiers corresponding to entries in the + clock-names property. + +- clock-names: Must contain + aclk_vop: for ddr buffer transfer. + hclk_vop: for ahb bus to R/W the phy regs. + dclk_vop: pixel clock. + +- resets: Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. +- reset-names: Must include the following entries: + - axi + - ahb + - dclk + +- iommus: required a iommu node + +- port: A port node with endpoint definitions as defined in + Documentation/devicetree/bindings/media/video-interfaces.txt. + +Example: +SoC specific DT entry: + vopb: vopb@ff930000 { + compatible = "rockchip,rk3288-vop"; + reg = <0xff930000 0x19c>; + interrupts = ; + clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>; + clock-names = "aclk_vop", "dclk_vop", "hclk_vop"; + resets = <&cru SRST_LCDC1_AXI>, <&cru SRST_LCDC1_AHB>, <&cru SRST_LCDC1_DCLK>; + reset-names = "axi", "ahb", "dclk"; + iommus = <&vopb_mmu>; + vopb_out: port { + #address-cells = <1>; + #size-cells = <0>; + vopb_out_edp: endpoint@0 { + reg = <0>; + remote-endpoint=<&edp_in_vopb>; + }; + vopb_out_hdmi: endpoint@1 { + reg = <1>; + remote-endpoint=<&hdmi_in_vopb>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer-sunxi.txt b/Documentation/devicetree/bindings/display/simple-framebuffer-sunxi.txt new file mode 100644 index 000000000..c46ba641a --- /dev/null +++ b/Documentation/devicetree/bindings/display/simple-framebuffer-sunxi.txt @@ -0,0 +1,33 @@ +Sunxi specific Simple Framebuffer bindings + +This binding documents sunxi specific extensions to the simple-framebuffer +bindings. The sunxi simplefb u-boot code relies on the devicetree containing +pre-populated simplefb nodes. + +These extensions are intended so that u-boot can select the right node based +on which pipeline is being used. As such they are solely intended for +firmware / bootloader use, and the OS should ignore them. + +Required properties: +- compatible: "allwinner,simple-framebuffer" +- allwinner,pipeline, one of: + "de_be0-lcd0" + "de_be1-lcd1" + "de_be0-lcd0-hdmi" + "de_be1-lcd1-hdmi" + +Example: + +chosen { + #address-cells = <1>; + #size-cells = <1>; + ranges; + + framebuffer@0 { + compatible = "allwinner,simple-framebuffer", "simple-framebuffer"; + allwinner,pipeline = "de_be0-lcd0-hdmi"; + clocks = <&pll5 1>, <&ahb_gates 36>, <&ahb_gates 43>, + <&ahb_gates 44>; + status = "disabled"; + }; +}; diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer.txt b/Documentation/devicetree/bindings/display/simple-framebuffer.txt new file mode 100644 index 000000000..4474ef6e0 --- /dev/null +++ b/Documentation/devicetree/bindings/display/simple-framebuffer.txt @@ -0,0 +1,86 @@ +Simple Framebuffer + +A simple frame-buffer describes a frame-buffer setup by firmware or +the bootloader, with the assumption that the display hardware has already +been set up to scan out from the memory pointed to by the reg property. + +Since simplefb nodes represent runtime information they must be sub-nodes of +the chosen node (*). Simplefb nodes must be named "framebuffer@
". + +If the devicetree contains nodes for the display hardware used by a simplefb, +then the simplefb node must contain a property called "display", which +contains a phandle pointing to the primary display hw node, so that the OS +knows which simplefb to disable when handing over control to a driver for the +real hardware. The bindings for the hw nodes must specify which node is +considered the primary node. + +It is advised to add display# aliases to help the OS determine how to number +things. If display# aliases are used, then if the simplefb node contains a +"display" property then the /aliases/display# path must point to the display +hw node the "display" property points to, otherwise it must point directly +to the simplefb node. + +If a simplefb node represents the preferred console for user interaction, +then the chosen node's stdout-path property should point to it, or to the +primary display hw node, as with display# aliases. If display aliases are +used then it should be set to the alias instead. + +It is advised that devicetree files contain pre-filled, disabled framebuffer +nodes, so that the firmware only needs to update the mode information and +enable them. This way if e.g. later on support for more display clocks get +added, the simplefb nodes will already contain this info and the firmware +does not need to be updated. + +If pre-filled framebuffer nodes are used, the firmware may need extra +information to find the right node. In that case an extra platform specific +compatible and platform specific properties should be used and documented, +see e.g. simple-framebuffer-sunxi.txt . + +Required properties: +- compatible: "simple-framebuffer" +- reg: Should contain the location and size of the framebuffer memory. +- width: The width of the framebuffer in pixels. +- height: The height of the framebuffer in pixels. +- stride: The number of bytes in each line of the framebuffer. +- format: The format of the framebuffer surface. Valid values are: + - r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b). + - a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r). + +Optional properties: +- clocks : List of clocks used by the framebuffer. Clocks listed here + are expected to already be configured correctly. The OS must + ensure these clocks are not modified or disabled while the + simple framebuffer remains active. +- display : phandle pointing to the primary display hardware node + +Example: + +aliases { + display0 = &lcdc0; +} + +chosen { + framebuffer0: framebuffer@1d385000 { + compatible = "simple-framebuffer"; + reg = <0x1d385000 (1600 * 1200 * 2)>; + width = <1600>; + height = <1200>; + stride = <(1600 * 2)>; + format = "r5g6b5"; + clocks = <&ahb_gates 36>, <&ahb_gates 43>, <&ahb_gates 44>; + display = <&lcdc0>; + }; + stdout-path = "display0"; +}; + +soc@01c00000 { + lcdc0: lcdc@1c0c000 { + compatible = "allwinner,sun4i-a10-lcdc"; + ... + }; +}; + + +*) Older devicetree files may have a compatible = "simple-framebuffer" node +in a different place, operating systems must first enumerate any compatible +nodes found under chosen and then check for other compatible nodes. diff --git a/Documentation/devicetree/bindings/display/sm501fb.txt b/Documentation/devicetree/bindings/display/sm501fb.txt new file mode 100644 index 000000000..9d9f00980 --- /dev/null +++ b/Documentation/devicetree/bindings/display/sm501fb.txt @@ -0,0 +1,34 @@ +* SM SM501 + +The SM SM501 is a LCD controller, with proper hardware, it can also +drive DVI monitors. + +Required properties: +- compatible : should be "smi,sm501". +- reg : contain two entries: + - First entry: System Configuration register + - Second entry: IO space (Display Controller register) +- interrupts : SMI interrupt to the cpu should be described here. +- interrupt-parent : the phandle for the interrupt controller that + services interrupts for this device. + +Optional properties: +- mode : select a video mode: + x[-][@] +- edid : verbatim EDID data block describing attached display. + Data from the detailed timing descriptor will be used to + program the display controller. +- little-endian: available on big endian systems, to + set different foreign endian. +- big-endian: available on little endian systems, to + set different foreign endian. + +Example for MPC5200: + display@1,0 { + compatible = "smi,sm501"; + reg = <1 0x00000000 0x00800000 + 1 0x03e00000 0x00200000>; + interrupts = <1 1 3>; + mode = "640x480-32@60"; + edid = [edid-data]; + }; diff --git a/Documentation/devicetree/bindings/display/ssd1289fb.txt b/Documentation/devicetree/bindings/display/ssd1289fb.txt new file mode 100644 index 000000000..4fcd5e68c --- /dev/null +++ b/Documentation/devicetree/bindings/display/ssd1289fb.txt @@ -0,0 +1,13 @@ +* Solomon SSD1289 Framebuffer Driver + +Required properties: + - compatible: Should be "solomon,ssd1289fb". The only supported bus for + now is lbc. + - reg: Should contain address of the controller on the LBC bus. The detail + was described in Documentation/devicetree/bindings/powerpc/fsl/lbc.txt + +Examples: +display@2,0 { + compatible = "solomon,ssd1289fb"; + reg = <0x2 0x0000 0x0004>; +}; diff --git a/Documentation/devicetree/bindings/display/ssd1307fb.txt b/Documentation/devicetree/bindings/display/ssd1307fb.txt new file mode 100644 index 000000000..eb31ed47a --- /dev/null +++ b/Documentation/devicetree/bindings/display/ssd1307fb.txt @@ -0,0 +1,50 @@ +* Solomon SSD1307 Framebuffer Driver + +Required properties: + - compatible: Should be "solomon,fb-". The only supported bus for + now is i2c, and the supported chips are ssd1305, ssd1306, ssd1307 and + ssd1309. + - reg: Should contain address of the controller on the I2C bus. Most likely + 0x3c or 0x3d + - pwm: Should contain the pwm to use according to the OF device tree PWM + specification [0]. Only required for the ssd1307. + - reset-gpios: Should contain the GPIO used to reset the OLED display + - solomon,height: Height in pixel of the screen driven by the controller + - solomon,width: Width in pixel of the screen driven by the controller + - solomon,page-offset: Offset of pages (band of 8 pixels) that the screen is + mapped to. + +Optional properties: + - reset-active-low: Is the reset gpio is active on physical low? + - solomon,segment-no-remap: Display needs normal (non-inverted) data column + to segment mapping + - solomon,com-seq: Display uses sequential COM pin configuration + - solomon,com-lrremap: Display uses left-right COM pin remap + - solomon,com-invdir: Display uses inverted COM pin scan direction + - solomon,com-offset: Number of the COM pin wired to the first display line + - solomon,prechargep1: Length of deselect period (phase 1) in clock cycles. + - solomon,prechargep2: Length of precharge period (phase 2) in clock cycles. + This needs to be the higher, the higher the capacitance + of the OLED's pixels is + +[0]: Documentation/devicetree/bindings/pwm/pwm.txt + +Examples: +ssd1307: oled@3c { + compatible = "solomon,ssd1307fb-i2c"; + reg = <0x3c>; + pwms = <&pwm 4 3000>; + reset-gpios = <&gpio2 7>; + reset-active-low; +}; + +ssd1306: oled@3c { + compatible = "solomon,ssd1306fb-i2c"; + reg = <0x3c>; + pwms = <&pwm 4 3000>; + reset-gpios = <&gpio2 7>; + reset-active-low; + solomon,com-lrremap; + solomon,com-invdir; + solomon,com-offset = <32>; +}; diff --git a/Documentation/devicetree/bindings/display/st,stih4xx.txt b/Documentation/devicetree/bindings/display/st,stih4xx.txt new file mode 100644 index 000000000..a352ed30c --- /dev/null +++ b/Documentation/devicetree/bindings/display/st,stih4xx.txt @@ -0,0 +1,241 @@ +STMicroelectronics stih4xx platforms + +- sti-vtg: video timing generator + Required properties: + - compatible: "st,vtg" + - reg: Physical base address of the IP registers and length of memory mapped region. + Optional properties: + - interrupts : VTG interrupt number to the CPU. + - st,slave: phandle on a slave vtg + +- sti-vtac: video timing advanced inter dye communication Rx and TX + Required properties: + - compatible: "st,vtac-main" or "st,vtac-aux" + - reg: Physical base address of the IP registers and length of memory mapped region. + - clocks: from common clock binding: handle hardware IP needed clocks, the + number of clocks may depend of the SoC type. + See ../clocks/clock-bindings.txt for details. + - clock-names: names of the clocks listed in clocks property in the same + order. + +- sti-display-subsystem: Master device for DRM sub-components + This device must be the parent of all the sub-components and is responsible + of bind them. + Required properties: + - compatible: "st,sti-display-subsystem" + - ranges: to allow probing of subdevices + +- sti-compositor: frame compositor engine + must be a child of sti-display-subsystem + Required properties: + - compatible: "st,stih-compositor" + - reg: Physical base address of the IP registers and length of memory mapped region. + - clocks: from common clock binding: handle hardware IP needed clocks, the + number of clocks may depend of the SoC type. + See ../clocks/clock-bindings.txt for details. + - clock-names: names of the clocks listed in clocks property in the same + order. + - resets: resets to be used by the device + See ../reset/reset.txt for details. + - reset-names: names of the resets listed in resets property in the same + order. + - st,vtg: phandle(s) on vtg device (main and aux) nodes. + +- sti-tvout: video out hardware block + must be a child of sti-display-subsystem + Required properties: + - compatible: "st,stih-tvout" + - reg: Physical base address of the IP registers and length of memory mapped region. + - reg-names: names of the mapped memory regions listed in regs property in + the same order. + - resets: resets to be used by the device + See ../reset/reset.txt for details. + - reset-names: names of the resets listed in resets property in the same + order. + +- sti-hdmi: hdmi output block + must be a child of sti-display-subsystem + Required properties: + - compatible: "st,stih-hdmi"; + - reg: Physical base address of the IP registers and length of memory mapped region. + - reg-names: names of the mapped memory regions listed in regs property in + the same order. + - interrupts : HDMI interrupt number to the CPU. + - interrupt-names: names of the interrupts listed in interrupts property in + the same order + - clocks: from common clock binding: handle hardware IP needed clocks, the + number of clocks may depend of the SoC type. + - clock-names: names of the clocks listed in clocks property in the same + order. + - ddc: phandle of an I2C controller used for DDC EDID probing + +sti-hda: + Required properties: + must be a child of sti-display-subsystem + - compatible: "st,stih-hda" + - reg: Physical base address of the IP registers and length of memory mapped region. + - reg-names: names of the mapped memory regions listed in regs property in + the same order. + - clocks: from common clock binding: handle hardware IP needed clocks, the + number of clocks may depend of the SoC type. + See ../clocks/clock-bindings.txt for details. + - clock-names: names of the clocks listed in clocks property in the same + order. + +sti-dvo: + Required properties: + must be a child of sti-display-subsystem + - compatible: "st,stih-dvo" + - reg: Physical base address of the IP registers and length of memory mapped region. + - reg-names: names of the mapped memory regions listed in regs property in + the same order. + - clocks: from common clock binding: handle hardware IP needed clocks, the + number of clocks may depend of the SoC type. + See ../clocks/clock-bindings.txt for details. + - clock-names: names of the clocks listed in clocks property in the same + order. + - pinctrl-0: pin control handle + - pinctrl-names: names of the pin control states to use + - sti,panel: phandle of the panel connected to the DVO output + +sti-hqvdp: + must be a child of sti-display-subsystem + Required properties: + - compatible: "st,stih-hqvdp" + - reg: Physical base address of the IP registers and length of memory mapped region. + - clocks: from common clock binding: handle hardware IP needed clocks, the + number of clocks may depend of the SoC type. + See ../clocks/clock-bindings.txt for details. + - clock-names: names of the clocks listed in clocks property in the same + order. + - resets: resets to be used by the device + See ../reset/reset.txt for details. + - reset-names: names of the resets listed in resets property in the same + order. + - st,vtg: phandle on vtg main device node. + +Example: + +/ { + ... + + vtg_main_slave: sti-vtg-main-slave@fe85A800 { + compatible = "st,vtg"; + reg = <0xfe85A800 0x300>; + interrupts = ; + }; + + vtg_main: sti-vtg-main-master@fd348000 { + compatible = "st,vtg"; + reg = <0xfd348000 0x400>; + st,slave = <&vtg_main_slave>; + }; + + vtg_aux_slave: sti-vtg-aux-slave@fd348400 { + compatible = "st,vtg"; + reg = <0xfe858200 0x300>; + interrupts = ; + }; + + vtg_aux: sti-vtg-aux-master@fd348400 { + compatible = "st,vtg"; + reg = <0xfd348400 0x400>; + st,slave = <&vtg_aux_slave>; + }; + + + sti-vtac-rx-main@fee82800 { + compatible = "st,vtac-main"; + reg = <0xfee82800 0x200>; + clock-names = "vtac"; + clocks = <&clk_m_a2_div0 CLK_M_VTAC_MAIN_PHY>; + }; + + sti-vtac-rx-aux@fee82a00 { + compatible = "st,vtac-aux"; + reg = <0xfee82a00 0x200>; + clock-names = "vtac"; + clocks = <&clk_m_a2_div0 CLK_M_VTAC_AUX_PHY>; + }; + + sti-vtac-tx-main@fd349000 { + compatible = "st,vtac-main"; + reg = <0xfd349000 0x200>, <0xfd320000 0x10000>; + clock-names = "vtac"; + clocks = <&clk_s_a1_hs CLK_S_VTAC_TX_PHY>; + }; + + sti-vtac-tx-aux@fd349200 { + compatible = "st,vtac-aux"; + reg = <0xfd349200 0x200>, <0xfd320000 0x10000>; + clock-names = "vtac"; + clocks = <&clk_s_a1_hs CLK_S_VTAC_TX_PHY>; + }; + + sti-display-subsystem { + compatible = "st,sti-display-subsystem"; + ranges; + + sti-compositor@fd340000 { + compatible = "st,stih416-compositor"; + reg = <0xfd340000 0x1000>; + clock-names = "compo_main", "compo_aux", + "pix_main", "pix_aux"; + clocks = <&clk_m_a2_div1 CLK_M_COMPO_MAIN>, <&clk_m_a2_div1 CLK_M_COMPO_AUX>, + <&clockgen_c_vcc CLK_S_PIX_MAIN>, <&clockgen_c_vcc CLK_S_PIX_AUX>; + reset-names = "compo-main", "compo-aux"; + resets = <&softreset STIH416_COMPO_M_SOFTRESET>, <&softreset STIH416_COMPO_A_SOFTRESET>; + st,vtg = <&vtg_main>, <&vtg_aux>; + }; + + sti-tvout@fe000000 { + compatible = "st,stih416-tvout"; + reg = <0xfe000000 0x1000>, <0xfe85a000 0x400>, <0xfe830000 0x10000>; + reg-names = "tvout-reg", "hda-reg", "syscfg"; + reset-names = "tvout"; + resets = <&softreset STIH416_HDTVOUT_SOFTRESET>; + }; + + sti-hdmi@fe85c000 { + compatible = "st,stih416-hdmi"; + reg = <0xfe85c000 0x1000>, <0xfe830000 0x10000>; + reg-names = "hdmi-reg", "syscfg"; + interrupts = ; + interrupt-names = "irq"; + clock-names = "pix", "tmds", "phy", "audio"; + clocks = <&clockgen_c_vcc CLK_S_PIX_HDMI>, <&clockgen_c_vcc CLK_S_TMDS_HDMI>, <&clockgen_c_vcc CLK_S_HDMI_REJECT_PLL>, <&clockgen_b1 CLK_S_PCM_0>; + }; + + sti-hda@fe85a000 { + compatible = "st,stih416-hda"; + reg = <0xfe85a000 0x400>, <0xfe83085c 0x4>; + reg-names = "hda-reg", "video-dacs-ctrl"; + clock-names = "pix", "hddac"; + clocks = <&clockgen_c_vcc CLK_S_PIX_HD>, <&clockgen_c_vcc CLK_S_HDDAC>; + }; + + sti-dvo@8d00400 { + compatible = "st,stih407-dvo"; + reg = <0x8d00400 0x200>; + reg-names = "dvo-reg"; + clock-names = "dvo_pix", "dvo", + "main_parent", "aux_parent"; + clocks = <&clk_s_d2_flexgen CLK_PIX_DVO>, <&clk_s_d2_flexgen CLK_DVO>, + <&clk_s_d2_quadfs 0>, <&clk_s_d2_quadfs 1>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_dvo>; + sti,panel = <&panel_dvo>; + }; + + sti-hqvdp@9c000000 { + compatible = "st,stih407-hqvdp"; + reg = <0x9C00000 0x100000>; + clock-names = "hqvdp", "pix_main"; + clocks = <&clk_s_c0_flexgen CLK_MAIN_DISP>, <&clk_s_d2_flexgen CLK_PIX_MAIN_DISP>; + reset-names = "hqvdp"; + resets = <&softreset STIH407_HDQVDP_SOFTRESET>; + st,vtg = <&vtg_main>; + }; + }; + ... +}; diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.txt b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.txt new file mode 100644 index 000000000..e4a25cedc --- /dev/null +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra114-mipi.txt @@ -0,0 +1,41 @@ +NVIDIA Tegra MIPI pad calibration controller + +Required properties: +- compatible: "nvidia,tegra-mipi" +- reg: Physical base address and length of the controller's registers. +- clocks: Must contain an entry for each entry in clock-names. + See ../clocks/clock-bindings.txt for details. +- clock-names: Must include the following entries: + - mipi-cal +- #nvidia,mipi-calibrate-cells: Should be 1. The cell is a bitmask of the pads + that need to be calibrated for a given device. + +User nodes need to contain an nvidia,mipi-calibrate property that has a +phandle to refer to the calibration controller node and a bitmask of the pads +that need to be calibrated. + +Example: + + mipi: mipi@700e3000 { + compatible = "nvidia,tegra114-mipi"; + reg = <0x700e3000 0x100>; + clocks = <&tegra_car TEGRA114_CLK_MIPI_CAL>; + clock-names = "mipi-cal"; + #nvidia,mipi-calibrate-cells = <1>; + }; + + ... + + host1x@50000000 { + ... + + dsi@54300000 { + ... + + nvidia,mipi-calibrate = <&mipi 0x060>; + + ... + }; + + ... + }; diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt new file mode 100644 index 000000000..a3bd8c050 --- /dev/null +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt @@ -0,0 +1,380 @@ +NVIDIA Tegra host1x + +Required properties: +- compatible: "nvidia,tegra-host1x" +- reg: Physical base address and length of the controller's registers. +- interrupts: The interrupt outputs from the controller. +- #address-cells: The number of cells used to represent physical base addresses + in the host1x address space. Should be 1. +- #size-cells: The number of cells used to represent the size of an address + range in the host1x address space. Should be 1. +- ranges: The mapping of the host1x address space to the CPU address space. +- clocks: Must contain one entry, for the module clock. + See ../clocks/clock-bindings.txt for details. +- resets: Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. +- reset-names: Must include the following entries: + - host1x + +The host1x top-level node defines a number of children, each representing one +of the following host1x client modules: + +- mpe: video encoder + + Required properties: + - compatible: "nvidia,tegra-mpe" + - reg: Physical base address and length of the controller's registers. + - interrupts: The interrupt outputs from the controller. + - clocks: Must contain one entry, for the module clock. + See ../clocks/clock-bindings.txt for details. + - resets: Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. + - reset-names: Must include the following entries: + - mpe + +- vi: video input + + Required properties: + - compatible: "nvidia,tegra-vi" + - reg: Physical base address and length of the controller's registers. + - interrupts: The interrupt outputs from the controller. + - clocks: Must contain one entry, for the module clock. + See ../clocks/clock-bindings.txt for details. + - resets: Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. + - reset-names: Must include the following entries: + - vi + +- epp: encoder pre-processor + + Required properties: + - compatible: "nvidia,tegra-epp" + - reg: Physical base address and length of the controller's registers. + - interrupts: The interrupt outputs from the controller. + - clocks: Must contain one entry, for the module clock. + See ../clocks/clock-bindings.txt for details. + - resets: Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. + - reset-names: Must include the following entries: + - epp + +- isp: image signal processor + + Required properties: + - compatible: "nvidia,tegra-isp" + - reg: Physical base address and length of the controller's registers. + - interrupts: The interrupt outputs from the controller. + - clocks: Must contain one entry, for the module clock. + See ../clocks/clock-bindings.txt for details. + - resets: Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. + - reset-names: Must include the following entries: + - isp + +- gr2d: 2D graphics engine + + Required properties: + - compatible: "nvidia,tegra-gr2d" + - reg: Physical base address and length of the controller's registers. + - interrupts: The interrupt outputs from the controller. + - clocks: Must contain one entry, for the module clock. + See ../clocks/clock-bindings.txt for details. + - resets: Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. + - reset-names: Must include the following entries: + - 2d + +- gr3d: 3D graphics engine + + Required properties: + - compatible: "nvidia,tegra-gr3d" + - reg: Physical base address and length of the controller's registers. + - clocks: Must contain an entry for each entry in clock-names. + See ../clocks/clock-bindings.txt for details. + - clock-names: Must include the following entries: + (This property may be omitted if the only clock in the list is "3d") + - 3d + This MUST be the first entry. + - 3d2 (Only required on SoCs with two 3D clocks) + - resets: Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. + - reset-names: Must include the following entries: + - 3d + - 3d2 (Only required on SoCs with two 3D clocks) + +- dc: display controller + + Required properties: + - compatible: "nvidia,tegra-dc" + - reg: Physical base address and length of the controller's registers. + - interrupts: The interrupt outputs from the controller. + - clocks: Must contain an entry for each entry in clock-names. + See ../clocks/clock-bindings.txt for details. + - clock-names: Must include the following entries: + - dc + This MUST be the first entry. + - parent + - resets: Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. + - reset-names: Must include the following entries: + - dc + - nvidia,head: The number of the display controller head. This is used to + setup the various types of output to receive video data from the given + head. + + Each display controller node has a child node, named "rgb", that represents + the RGB output associated with the controller. It can take the following + optional properties: + - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing + - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection + - nvidia,edid: supplies a binary EDID blob + - nvidia,panel: phandle of a display panel + +- hdmi: High Definition Multimedia Interface + + Required properties: + - compatible: "nvidia,tegra-hdmi" + - reg: Physical base address and length of the controller's registers. + - interrupts: The interrupt outputs from the controller. + - hdmi-supply: supply for the +5V HDMI connector pin + - vdd-supply: regulator for supply voltage + - pll-supply: regulator for PLL + - clocks: Must contain an entry for each entry in clock-names. + See ../clocks/clock-bindings.txt for details. + - clock-names: Must include the following entries: + - hdmi + This MUST be the first entry. + - parent + - resets: Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. + - reset-names: Must include the following entries: + - hdmi + + Optional properties: + - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing + - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection + - nvidia,edid: supplies a binary EDID blob + - nvidia,panel: phandle of a display panel + +- tvo: TV encoder output + + Required properties: + - compatible: "nvidia,tegra-tvo" + - reg: Physical base address and length of the controller's registers. + - interrupts: The interrupt outputs from the controller. + - clocks: Must contain one entry, for the module clock. + See ../clocks/clock-bindings.txt for details. + +- dsi: display serial interface + + Required properties: + - compatible: "nvidia,tegra-dsi" + - reg: Physical base address and length of the controller's registers. + - clocks: Must contain an entry for each entry in clock-names. + See ../clocks/clock-bindings.txt for details. + - clock-names: Must include the following entries: + - dsi + This MUST be the first entry. + - lp + - parent + - resets: Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. + - reset-names: Must include the following entries: + - dsi + - avdd-dsi-supply: phandle of a supply that powers the DSI controller + - nvidia,mipi-calibrate: Should contain a phandle and a specifier specifying + which pads are used by this DSI output and need to be calibrated. See also + ../display/tegra/nvidia,tegra114-mipi.txt. + + Optional properties: + - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing + - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection + - nvidia,edid: supplies a binary EDID blob + - nvidia,panel: phandle of a display panel + - nvidia,ganged-mode: contains a phandle to a second DSI controller to gang + up with in order to support up to 8 data lanes + +- sor: serial output resource + + Required properties: + - compatible: Should be: + - "nvidia,tegra124-sor": for Tegra124 and Tegra132 + - "nvidia,tegra132-sor": for Tegra132 + - "nvidia,tegra210-sor": for Tegra210 + - "nvidia,tegra210-sor1": for Tegra210 + - reg: Physical base address and length of the controller's registers. + - interrupts: The interrupt outputs from the controller. + - clocks: Must contain an entry for each entry in clock-names. + See ../clocks/clock-bindings.txt for details. + - clock-names: Must include the following entries: + - sor: clock input for the SOR hardware + - parent: input for the pixel clock + - dp: reference clock for the SOR clock + - safe: safe reference for the SOR clock during power up + - resets: Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. + - reset-names: Must include the following entries: + - sor + + Optional properties: + - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing + - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection + - nvidia,edid: supplies a binary EDID blob + - nvidia,panel: phandle of a display panel + + Optional properties when driving an eDP output: + - nvidia,dpaux: phandle to a DispayPort AUX interface + +- dpaux: DisplayPort AUX interface + - compatible: For Tegra124, must contain "nvidia,tegra124-dpaux". Otherwise, + must contain '"nvidia,-dpaux", "nvidia,tegra124-dpaux"', where + is tegra132. + - reg: Physical base address and length of the controller's registers. + - interrupts: The interrupt outputs from the controller. + - clocks: Must contain an entry for each entry in clock-names. + See ../clocks/clock-bindings.txt for details. + - clock-names: Must include the following entries: + - dpaux: clock input for the DPAUX hardware + - parent: reference clock + - resets: Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. + - reset-names: Must include the following entries: + - dpaux + - vdd-supply: phandle of a supply that powers the DisplayPort link + +Example: + +/ { + ... + + host1x { + compatible = "nvidia,tegra20-host1x", "simple-bus"; + reg = <0x50000000 0x00024000>; + interrupts = <0 65 0x04 /* mpcore syncpt */ + 0 67 0x04>; /* mpcore general */ + clocks = <&tegra_car TEGRA20_CLK_HOST1X>; + resets = <&tegra_car 28>; + reset-names = "host1x"; + + #address-cells = <1>; + #size-cells = <1>; + + ranges = <0x54000000 0x54000000 0x04000000>; + + mpe { + compatible = "nvidia,tegra20-mpe"; + reg = <0x54040000 0x00040000>; + interrupts = <0 68 0x04>; + clocks = <&tegra_car TEGRA20_CLK_MPE>; + resets = <&tegra_car 60>; + reset-names = "mpe"; + }; + + vi { + compatible = "nvidia,tegra20-vi"; + reg = <0x54080000 0x00040000>; + interrupts = <0 69 0x04>; + clocks = <&tegra_car TEGRA20_CLK_VI>; + resets = <&tegra_car 100>; + reset-names = "vi"; + }; + + epp { + compatible = "nvidia,tegra20-epp"; + reg = <0x540c0000 0x00040000>; + interrupts = <0 70 0x04>; + clocks = <&tegra_car TEGRA20_CLK_EPP>; + resets = <&tegra_car 19>; + reset-names = "epp"; + }; + + isp { + compatible = "nvidia,tegra20-isp"; + reg = <0x54100000 0x00040000>; + interrupts = <0 71 0x04>; + clocks = <&tegra_car TEGRA20_CLK_ISP>; + resets = <&tegra_car 23>; + reset-names = "isp"; + }; + + gr2d { + compatible = "nvidia,tegra20-gr2d"; + reg = <0x54140000 0x00040000>; + interrupts = <0 72 0x04>; + clocks = <&tegra_car TEGRA20_CLK_GR2D>; + resets = <&tegra_car 21>; + reset-names = "2d"; + }; + + gr3d { + compatible = "nvidia,tegra20-gr3d"; + reg = <0x54180000 0x00040000>; + clocks = <&tegra_car TEGRA20_CLK_GR3D>; + resets = <&tegra_car 24>; + reset-names = "3d"; + }; + + dc@54200000 { + compatible = "nvidia,tegra20-dc"; + reg = <0x54200000 0x00040000>; + interrupts = <0 73 0x04>; + clocks = <&tegra_car TEGRA20_CLK_DISP1>, + <&tegra_car TEGRA20_CLK_PLL_P>; + clock-names = "dc", "parent"; + resets = <&tegra_car 27>; + reset-names = "dc"; + + rgb { + status = "disabled"; + }; + }; + + dc@54240000 { + compatible = "nvidia,tegra20-dc"; + reg = <0x54240000 0x00040000>; + interrupts = <0 74 0x04>; + clocks = <&tegra_car TEGRA20_CLK_DISP2>, + <&tegra_car TEGRA20_CLK_PLL_P>; + clock-names = "dc", "parent"; + resets = <&tegra_car 26>; + reset-names = "dc"; + + rgb { + status = "disabled"; + }; + }; + + hdmi { + compatible = "nvidia,tegra20-hdmi"; + reg = <0x54280000 0x00040000>; + interrupts = <0 75 0x04>; + clocks = <&tegra_car TEGRA20_CLK_HDMI>, + <&tegra_car TEGRA20_CLK_PLL_D_OUT0>; + clock-names = "hdmi", "parent"; + resets = <&tegra_car 51>; + reset-names = "hdmi"; + status = "disabled"; + }; + + tvo { + compatible = "nvidia,tegra20-tvo"; + reg = <0x542c0000 0x00040000>; + interrupts = <0 76 0x04>; + clocks = <&tegra_car TEGRA20_CLK_TVO>; + status = "disabled"; + }; + + dsi { + compatible = "nvidia,tegra20-dsi"; + reg = <0x54300000 0x00040000>; + clocks = <&tegra_car TEGRA20_CLK_DSI>, + <&tegra_car TEGRA20_CLK_PLL_D_OUT0>; + clock-names = "dsi", "parent"; + resets = <&tegra_car 48>; + reset-names = "dsi"; + status = "disabled"; + }; + }; + + ... +}; diff --git a/Documentation/devicetree/bindings/display/ti/ti,dra7-dss.txt b/Documentation/devicetree/bindings/display/ti/ti,dra7-dss.txt new file mode 100644 index 000000000..c30f9ec18 --- /dev/null +++ b/Documentation/devicetree/bindings/display/ti/ti,dra7-dss.txt @@ -0,0 +1,69 @@ +Texas Instruments DRA7x Display Subsystem +========================================= + +See Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt for generic +description about OMAP Display Subsystem bindings. + +DSS Core +-------- + +Required properties: +- compatible: "ti,dra7-dss" +- reg: address and length of the register spaces for 'dss' +- ti,hwmods: "dss_core" +- clocks: handle to fclk +- clock-names: "fck" +- syscon: phandle to control module core syscon node + +Optional properties: + +Some DRA7xx SoCs have one dedicated video PLL, some have two. These properties +can be used to describe the video PLLs: + +- reg: address and length of the register spaces for 'pll1_clkctrl', + 'pll1', 'pll2_clkctrl', 'pll2' +- clocks: handle to video1 pll clock and video2 pll clock +- clock-names: "video1_clk" and "video2_clk" + +Required nodes: +- DISPC + +Optional nodes: +- DSS Submodules: HDMI +- Video port for DPI output + +DPI Endpoint required properties: +- data-lines: number of lines used + + +DISPC +----- + +Required properties: +- compatible: "ti,dra7-dispc" +- reg: address and length of the register space +- ti,hwmods: "dss_dispc" +- interrupts: the DISPC interrupt +- clocks: handle to fclk +- clock-names: "fck" + +HDMI +---- + +Required properties: +- compatible: "ti,dra7-hdmi" +- reg: addresses and lengths of the register spaces for 'wp', 'pll', 'phy', + 'core' +- reg-names: "wp", "pll", "phy", "core" +- interrupts: the HDMI interrupt line +- ti,hwmods: "dss_hdmi" +- vdda-supply: vdda power supply +- clocks: handles to fclk and pll clock +- clock-names: "fck", "sys_clk" + +Optional nodes: +- Video port for HDMI output + +HDMI Endpoint optional properties: +- lanes: list of 8 pin numbers for the HDMI lanes: CLK+, CLK-, D0+, D0-, + D1+, D1-, D2+, D2-. (default: 0,1,2,3,4,5,6,7) diff --git a/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt b/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt new file mode 100644 index 000000000..e1ef29569 --- /dev/null +++ b/Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt @@ -0,0 +1,211 @@ +Texas Instruments OMAP Display Subsystem +======================================== + +Generic Description +------------------- + +This document is a generic description of the OMAP Display Subsystem bindings. +Binding details for each OMAP SoC version are described in respective binding +documentation. + +The OMAP Display Subsystem (DSS) hardware consists of DSS Core, DISPC module and +a number of encoder modules. All DSS versions contain DSS Core and DISPC, but +the encoder modules vary. + +The DSS Core is the parent of the other DSS modules, and manages clock routing, +integration to the SoC, etc. + +DISPC is the display controller, which reads pixels from the memory and outputs +a RGB pixel stream to encoders. + +The encoder modules encode the received RGB pixel stream to a video output like +HDMI, MIPI DPI, etc. + +Video Ports +----------- + +The DSS Core and the encoders have video port outputs. The structure of the +video ports is described in Documentation/devicetree/bindings/graph.txt, +and the properties for the ports and endpoints for each encoder are +described in the SoC's DSS binding documentation. + +The video ports are used to describe the connections to external hardware, like +panels or external encoders. + +Aliases +------- + +The board dts file may define aliases for displays to assign "displayX" style +name for each display. If no aliases are defined, a semi-random number is used +for the display. + +Example +------- + +A shortened example of the DSS description for OMAP4, with non-relevant parts +removed, defined in omap4.dtsi: + +dss: dss@58000000 { + compatible = "ti,omap4-dss"; + reg = <0x58000000 0x80>; + status = "disabled"; + ti,hwmods = "dss_core"; + clocks = <&dss_dss_clk>; + clock-names = "fck"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + dispc@58001000 { + compatible = "ti,omap4-dispc"; + reg = <0x58001000 0x1000>; + interrupts = ; + ti,hwmods = "dss_dispc"; + clocks = <&dss_dss_clk>; + clock-names = "fck"; + }; + + hdmi: encoder@58006000 { + compatible = "ti,omap4-hdmi"; + reg = <0x58006000 0x200>, + <0x58006200 0x100>, + <0x58006300 0x100>, + <0x58006400 0x1000>; + reg-names = "wp", "pll", "phy", "core"; + interrupts = ; + status = "disabled"; + ti,hwmods = "dss_hdmi"; + clocks = <&dss_48mhz_clk>, <&dss_sys_clk>; + clock-names = "fck", "sys_clk"; + }; +}; + +A shortened example of the board description for OMAP4 Panda board, defined in +omap4-panda.dts. + +The Panda board has a DVI and a HDMI connector, and the board contains a TFP410 +chip (MIPI DPI to DVI encoder) and a TPD12S015 chip (HDMI ESD protection & level +shifter). The video pipelines for the connectors are formed as follows: + +DSS Core --(MIPI DPI)--> TFP410 --(DVI)--> DVI Connector +OMAP HDMI --(HDMI)--> TPD12S015 --(HDMI)--> HDMI Connector + +/ { + aliases { + display0 = &dvi0; + display1 = &hdmi0; + }; + + tfp410: encoder@0 { + compatible = "ti,tfp410"; + gpios = <&gpio1 0 GPIO_ACTIVE_LOW>; /* 0, power-down */ + + pinctrl-names = "default"; + pinctrl-0 = <&tfp410_pins>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + tfp410_in: endpoint@0 { + remote-endpoint = <&dpi_out>; + }; + }; + + port@1 { + reg = <1>; + + tfp410_out: endpoint@0 { + remote-endpoint = <&dvi_connector_in>; + }; + }; + }; + }; + + dvi0: connector@0 { + compatible = "dvi-connector"; + label = "dvi"; + + i2c-bus = <&i2c3>; + + port { + dvi_connector_in: endpoint { + remote-endpoint = <&tfp410_out>; + }; + }; + }; + + tpd12s015: encoder@1 { + compatible = "ti,tpd12s015"; + + pinctrl-names = "default"; + pinctrl-0 = <&tpd12s015_pins>; + + gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>, /* 60, CT CP HPD */ + <&gpio2 9 GPIO_ACTIVE_HIGH>, /* 41, LS OE */ + <&gpio2 31 GPIO_ACTIVE_HIGH>; /* 63, HPD */ + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + tpd12s015_in: endpoint@0 { + remote-endpoint = <&hdmi_out>; + }; + }; + + port@1 { + reg = <1>; + + tpd12s015_out: endpoint@0 { + remote-endpoint = <&hdmi_connector_in>; + }; + }; + }; + }; + + hdmi0: connector@1 { + compatible = "hdmi-connector"; + label = "hdmi"; + + port { + hdmi_connector_in: endpoint { + remote-endpoint = <&tpd12s015_out>; + }; + }; + }; +}; + +&dss { + status = "ok"; + + pinctrl-names = "default"; + pinctrl-0 = <&dss_dpi_pins>; + + port { + dpi_out: endpoint { + remote-endpoint = <&tfp410_in>; + data-lines = <24>; + }; + }; +}; + +&hdmi { + status = "ok"; + vdda-supply = <&vdac>; + + pinctrl-names = "default"; + pinctrl-0 = <&dss_hdmi_pins>; + + port { + hdmi_out: endpoint { + remote-endpoint = <&tpd12s015_in>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/display/ti/ti,omap2-dss.txt b/Documentation/devicetree/bindings/display/ti/ti,omap2-dss.txt new file mode 100644 index 000000000..afcd5a86c --- /dev/null +++ b/Documentation/devicetree/bindings/display/ti/ti,omap2-dss.txt @@ -0,0 +1,54 @@ +Texas Instruments OMAP2 Display Subsystem +========================================= + +See Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt for generic +description about OMAP Display Subsystem bindings. + +DSS Core +-------- + +Required properties: +- compatible: "ti,omap2-dss" +- reg: address and length of the register space +- ti,hwmods: "dss_core" + +Optional nodes: +- Video port for DPI output + +DPI Endpoint required properties: +- data-lines: number of lines used + + +DISPC +----- + +Required properties: +- compatible: "ti,omap2-dispc" +- reg: address and length of the register space +- ti,hwmods: "dss_dispc" +- interrupts: the DISPC interrupt + + +RFBI +---- + +Required properties: +- compatible: "ti,omap2-rfbi" +- reg: address and length of the register space +- ti,hwmods: "dss_rfbi" + + +VENC +---- + +Required properties: +- compatible: "ti,omap2-venc" +- reg: address and length of the register space +- ti,hwmods: "dss_venc" +- vdda-supply: power supply for DAC + +VENC Endpoint required properties: + +Required properties: +- ti,invert-polarity: invert the polarity of the video signal +- ti,channels: 1 for composite, 2 for s-video diff --git a/Documentation/devicetree/bindings/display/ti/ti,omap3-dss.txt b/Documentation/devicetree/bindings/display/ti/ti,omap3-dss.txt new file mode 100644 index 000000000..dc66e1447 --- /dev/null +++ b/Documentation/devicetree/bindings/display/ti/ti,omap3-dss.txt @@ -0,0 +1,83 @@ +Texas Instruments OMAP3 Display Subsystem +========================================= + +See Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt for generic +description about OMAP Display Subsystem bindings. + +DSS Core +-------- + +Required properties: +- compatible: "ti,omap3-dss" +- reg: address and length of the register space +- ti,hwmods: "dss_core" +- clocks: handle to fclk +- clock-names: "fck" + +Optional nodes: +- Video ports: + - Port 0: DPI output + - Port 1: SDI output + +DPI Endpoint required properties: +- data-lines: number of lines used + +SDI Endpoint required properties: +- datapairs: number of datapairs used + + +DISPC +----- + +Required properties: +- compatible: "ti,omap3-dispc" +- reg: address and length of the register space +- ti,hwmods: "dss_dispc" +- interrupts: the DISPC interrupt +- clocks: handle to fclk +- clock-names: "fck" + + +RFBI +---- + +Required properties: +- compatible: "ti,omap3-rfbi" +- reg: address and length of the register space +- ti,hwmods: "dss_rfbi" +- clocks: handles to fclk and iclk +- clock-names: "fck", "ick" + + +VENC +---- + +Required properties: +- compatible: "ti,omap3-venc" +- reg: address and length of the register space +- ti,hwmods: "dss_venc" +- vdda-supply: power supply for DAC +- clocks: handle to fclk +- clock-names: "fck" + +VENC Endpoint required properties: +- ti,invert-polarity: invert the polarity of the video signal +- ti,channels: 1 for composite, 2 for s-video + + +DSI +--- + +Required properties: +- compatible: "ti,omap3-dsi" +- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll' +- reg-names: "proto", "phy", "pll" +- interrupts: the DSI interrupt line +- ti,hwmods: "dss_dsi1" +- vdd-supply: power supply for DSI +- clocks: handles to fclk and pll clock +- clock-names: "fck", "sys_clk" + +DSI Endpoint required properties: +- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-, + DATA1+, DATA1-, ... diff --git a/Documentation/devicetree/bindings/display/ti/ti,omap4-dss.txt b/Documentation/devicetree/bindings/display/ti/ti,omap4-dss.txt new file mode 100644 index 000000000..bc624db88 --- /dev/null +++ b/Documentation/devicetree/bindings/display/ti/ti,omap4-dss.txt @@ -0,0 +1,115 @@ +Texas Instruments OMAP4 Display Subsystem +========================================= + +See Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt for generic +description about OMAP Display Subsystem bindings. + +DSS Core +-------- + +Required properties: +- compatible: "ti,omap4-dss" +- reg: address and length of the register space +- ti,hwmods: "dss_core" +- clocks: handle to fclk +- clock-names: "fck" + +Required nodes: +- DISPC + +Optional nodes: +- DSS Submodules: RFBI, VENC, DSI, HDMI +- Video port for DPI output + +DPI Endpoint required properties: +- data-lines: number of lines used + + +DISPC +----- + +Required properties: +- compatible: "ti,omap4-dispc" +- reg: address and length of the register space +- ti,hwmods: "dss_dispc" +- interrupts: the DISPC interrupt +- clocks: handle to fclk +- clock-names: "fck" + + +RFBI +---- + +Required properties: +- compatible: "ti,omap4-rfbi" +- reg: address and length of the register space +- ti,hwmods: "dss_rfbi" +- clocks: handles to fclk and iclk +- clock-names: "fck", "ick" + +Optional nodes: +- Video port for RFBI output +- RFBI controlled peripherals + + +VENC +---- + +Required properties: +- compatible: "ti,omap4-venc" +- reg: address and length of the register space +- ti,hwmods: "dss_venc" +- vdda-supply: power supply for DAC +- clocks: handle to fclk +- clock-names: "fck" + +Optional nodes: +- Video port for VENC output + +VENC Endpoint required properties: +- ti,invert-polarity: invert the polarity of the video signal +- ti,channels: 1 for composite, 2 for s-video + + +DSI +--- + +Required properties: +- compatible: "ti,omap4-dsi" +- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll' +- reg-names: "proto", "phy", "pll" +- interrupts: the DSI interrupt line +- ti,hwmods: "dss_dsi1" or "dss_dsi2" +- vdd-supply: power supply for DSI +- clocks: handles to fclk and pll clock +- clock-names: "fck", "sys_clk" + +Optional nodes: +- Video port for DSI output +- DSI controlled peripherals + +DSI Endpoint required properties: +- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-, + DATA1+, DATA1-, ... + + +HDMI +---- + +Required properties: +- compatible: "ti,omap4-hdmi" +- reg: addresses and lengths of the register spaces for 'wp', 'pll', 'phy', + 'core' +- reg-names: "wp", "pll", "phy", "core" +- interrupts: the HDMI interrupt line +- ti,hwmods: "dss_hdmi" +- vdda-supply: vdda power supply +- clocks: handles to fclk and pll clock +- clock-names: "fck", "sys_clk" + +Optional nodes: +- Video port for HDMI output + +HDMI Endpoint optional properties: +- lanes: list of 8 pin numbers for the HDMI lanes: CLK+, CLK-, D0+, D0-, + D1+, D1-, D2+, D2-. (default: 0,1,2,3,4,5,6,7) diff --git a/Documentation/devicetree/bindings/display/ti/ti,omap5-dss.txt b/Documentation/devicetree/bindings/display/ti/ti,omap5-dss.txt new file mode 100644 index 000000000..118a486c4 --- /dev/null +++ b/Documentation/devicetree/bindings/display/ti/ti,omap5-dss.txt @@ -0,0 +1,96 @@ +Texas Instruments OMAP5 Display Subsystem +========================================= + +See Documentation/devicetree/bindings/display/ti/ti,omap-dss.txt for generic +description about OMAP Display Subsystem bindings. + +DSS Core +-------- + +Required properties: +- compatible: "ti,omap5-dss" +- reg: address and length of the register space +- ti,hwmods: "dss_core" +- clocks: handle to fclk +- clock-names: "fck" + +Required nodes: +- DISPC + +Optional nodes: +- DSS Submodules: RFBI, DSI, HDMI +- Video port for DPI output + +DPI Endpoint required properties: +- data-lines: number of lines used + + +DISPC +----- + +Required properties: +- compatible: "ti,omap5-dispc" +- reg: address and length of the register space +- ti,hwmods: "dss_dispc" +- interrupts: the DISPC interrupt +- clocks: handle to fclk +- clock-names: "fck" + + +RFBI +---- + +Required properties: +- compatible: "ti,omap5-rfbi" +- reg: address and length of the register space +- ti,hwmods: "dss_rfbi" +- clocks: handles to fclk and iclk +- clock-names: "fck", "ick" + +Optional nodes: +- Video port for RFBI output +- RFBI controlled peripherals + + +DSI +--- + +Required properties: +- compatible: "ti,omap5-dsi" +- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll' +- reg-names: "proto", "phy", "pll" +- interrupts: the DSI interrupt line +- ti,hwmods: "dss_dsi1" or "dss_dsi2" +- vdd-supply: power supply for DSI +- clocks: handles to fclk and pll clock +- clock-names: "fck", "sys_clk" + +Optional nodes: +- Video port for DSI output +- DSI controlled peripherals + +DSI Endpoint required properties: +- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-, + DATA1+, DATA1-, ... + + +HDMI +---- + +Required properties: +- compatible: "ti,omap5-hdmi" +- reg: addresses and lengths of the register spaces for 'wp', 'pll', 'phy', + 'core' +- reg-names: "wp", "pll", "phy", "core" +- interrupts: the HDMI interrupt line +- ti,hwmods: "dss_hdmi" +- vdda-supply: vdda power supply +- clocks: handles to fclk and pll clock +- clock-names: "fck", "sys_clk" + +Optional nodes: +- Video port for HDMI output + +HDMI Endpoint optional properties: +- lanes: list of 8 pin numbers for the HDMI lanes: CLK+, CLK-, D0+, D0-, + D1+, D1-, D2+, D2-. (default: 0,1,2,3,4,5,6,7) diff --git a/Documentation/devicetree/bindings/display/ti/ti,opa362.txt b/Documentation/devicetree/bindings/display/ti/ti,opa362.txt new file mode 100644 index 000000000..f96083c0b --- /dev/null +++ b/Documentation/devicetree/bindings/display/ti/ti,opa362.txt @@ -0,0 +1,38 @@ +OPA362 analog video amplifier + +Required properties: +- compatible: "ti,opa362" +- enable-gpios: enable/disable output gpio + +Required node: +- Video port 0 for opa362 input +- Video port 1 for opa362 output + +Example: + +tv_amp: opa362 { + compatible = "ti,opa362"; + enable-gpios = <&gpio1 23 0>; /* GPIO to enable video out amplifier */ + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + opa_in: endpoint@0 { + remote-endpoint = <&venc_out>; + }; + }; + + port@1 { + reg = <1>; + opa_out: endpoint@0 { + remote-endpoint = <&tv_connector_in>; + }; + }; + }; +}; + + + diff --git a/Documentation/devicetree/bindings/display/ti/ti,tfp410.txt b/Documentation/devicetree/bindings/display/ti/ti,tfp410.txt new file mode 100644 index 000000000..2cbe32a3d --- /dev/null +++ b/Documentation/devicetree/bindings/display/ti/ti,tfp410.txt @@ -0,0 +1,41 @@ +TFP410 DPI to DVI encoder +========================= + +Required properties: +- compatible: "ti,tfp410" + +Optional properties: +- powerdown-gpios: power-down gpio + +Required nodes: +- Video port 0 for DPI input +- Video port 1 for DVI output + +Example +------- + +tfp410: encoder@0 { + compatible = "ti,tfp410"; + powerdown-gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + tfp410_in: endpoint@0 { + remote-endpoint = <&dpi_out>; + }; + }; + + port@1 { + reg = <1>; + + tfp410_out: endpoint@0 { + remote-endpoint = <&dvi_connector_in>; + }; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/display/ti/ti,tpd12s015.txt b/Documentation/devicetree/bindings/display/ti/ti,tpd12s015.txt new file mode 100644 index 000000000..26e6d32e3 --- /dev/null +++ b/Documentation/devicetree/bindings/display/ti/ti,tpd12s015.txt @@ -0,0 +1,44 @@ +TPD12S015 HDMI level shifter and ESD protection chip +==================================================== + +Required properties: +- compatible: "ti,tpd12s015" + +Optional properties: +- gpios: CT CP HPD, LS OE and HPD gpios + +Required nodes: +- Video port 0 for HDMI input +- Video port 1 for HDMI output + +Example +------- + +tpd12s015: encoder@1 { + compatible = "ti,tpd12s015"; + + gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>, /* 60, CT CP HPD */ + <&gpio2 9 GPIO_ACTIVE_HIGH>, /* 41, LS OE */ + <&gpio2 31 GPIO_ACTIVE_HIGH>; /* 63, HPD */ + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + tpd12s015_in: endpoint@0 { + remote-endpoint = <&hdmi_out>; + }; + }; + + port@1 { + reg = <1>; + + tpd12s015_out: endpoint@0 { + remote-endpoint = <&hdmi_connector_in>; + }; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/display/tilcdc/panel.txt b/Documentation/devicetree/bindings/display/tilcdc/panel.txt new file mode 100644 index 000000000..f20b31cdc --- /dev/null +++ b/Documentation/devicetree/bindings/display/tilcdc/panel.txt @@ -0,0 +1,66 @@ +Device-Tree bindings for tilcdc DRM generic panel output driver + +Required properties: + - compatible: value should be "ti,tilcdc,panel". + - panel-info: configuration info to configure LCDC correctly for the panel + - ac-bias: AC Bias Pin Frequency + - ac-bias-intrpt: AC Bias Pin Transitions per Interrupt + - dma-burst-sz: DMA burst size + - bpp: Bits per pixel + - fdd: FIFO DMA Request Delay + - sync-edge: Horizontal and Vertical Sync Edge: 0=rising 1=falling + - sync-ctrl: Horizontal and Vertical Sync: Control: 0=ignore + - raster-order: Raster Data Order Select: 1=Most-to-least 0=Least-to-most + - fifo-th: DMA FIFO threshold + - display-timings: typical videomode of lcd panel. Multiple video modes + can be listed if the panel supports multiple timings, but the 'native-mode' + should be the preferred/default resolution. Refer to + Documentation/devicetree/bindings/display/display-timing.txt for display + timing binding details. + +Optional properties: +- backlight: phandle of the backlight device attached to the panel +- enable-gpios: GPIO pin to enable or disable the panel + +Recommended properties: + - pinctrl-names, pinctrl-0: the pincontrol settings to configure + muxing properly for pins that connect to TFP410 device + +Example: + + /* Settings for CDTech_S035Q01 / LCD3 cape: */ + lcd3 { + compatible = "ti,tilcdc,panel"; + pinctrl-names = "default"; + pinctrl-0 = <&bone_lcd3_cape_lcd_pins>; + backlight = <&backlight>; + enable-gpios = <&gpio3 19 0>; + + panel-info { + ac-bias = <255>; + ac-bias-intrpt = <0>; + dma-burst-sz = <16>; + bpp = <16>; + fdd = <0x80>; + sync-edge = <0>; + sync-ctrl = <1>; + raster-order = <0>; + fifo-th = <0>; + }; + display-timings { + native-mode = <&timing0>; + timing0: 320x240 { + hactive = <320>; + vactive = <240>; + hback-porch = <21>; + hfront-porch = <58>; + hsync-len = <47>; + vback-porch = <11>; + vfront-porch = <23>; + vsync-len = <2>; + clock-frequency = <8000000>; + hsync-active = <0>; + vsync-active = <0>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/tilcdc/tfp410.txt b/Documentation/devicetree/bindings/display/tilcdc/tfp410.txt new file mode 100644 index 000000000..a58ae7756 --- /dev/null +++ b/Documentation/devicetree/bindings/display/tilcdc/tfp410.txt @@ -0,0 +1,21 @@ +Device-Tree bindings for tilcdc DRM TFP410 output driver + +Required properties: + - compatible: value should be "ti,tilcdc,tfp410". + - i2c: the phandle for the i2c device to use for DDC + +Recommended properties: + - pinctrl-names, pinctrl-0: the pincontrol settings to configure + muxing properly for pins that connect to TFP410 device + - powerdn-gpio: the powerdown GPIO, pulled low to power down the + TFP410 device (for DPMS_OFF) + +Example: + + dvicape { + compatible = "ti,tilcdc,tfp410"; + i2c = <&i2c2>; + pinctrl-names = "default"; + pinctrl-0 = <&bone_dvi_cape_dvi_00A1_pins>; + powerdn-gpio = <&gpio2 31 0>; + }; diff --git a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt new file mode 100644 index 000000000..2136ee81e --- /dev/null +++ b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt @@ -0,0 +1,56 @@ +Device-Tree bindings for tilcdc DRM driver + +Required properties: + - compatible: value should be "ti,am33xx-tilcdc". + - interrupts: the interrupt number + - reg: base address and size of the LCDC device + +Recommended properties: + - interrupt-parent: the phandle for the interrupt controller that + services interrupts for this device. + - ti,hwmods: Name of the hwmod associated to the LCDC + +Optional properties: + - max-bandwidth: The maximum pixels per second that the memory + interface / lcd controller combination can sustain + - max-width: The maximum horizontal pixel width supported by + the lcd controller. + - max-pixelclock: The maximum pixel clock that can be supported + by the lcd controller in KHz. + +Optional nodes: + + - port/ports: to describe a connection to an external encoder. The + binding follows Documentation/devicetree/bindings/graph.txt and + suppors a single port with a single endpoint. + +Example: + + fb: fb@4830e000 { + compatible = "ti,am33xx-tilcdc"; + reg = <0x4830e000 0x1000>; + interrupt-parent = <&intc>; + interrupts = <36>; + ti,hwmods = "lcdc"; + + port { + lcdc_0: endpoint@0 { + remote-endpoint = <&hdmi_0>; + }; + }; + }; + + tda19988: tda19988 { + compatible = "nxp,tda998x"; + reg = <0x70>; + + pinctrl-names = "default", "off"; + pinctrl-0 = <&nxp_hdmi_bonelt_pins>; + pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>; + + port { + hdmi_0: endpoint@0 { + remote-endpoint = <&lcdc_0>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/via,vt8500-fb.txt b/Documentation/devicetree/bindings/display/via,vt8500-fb.txt new file mode 100644 index 000000000..2871e218a --- /dev/null +++ b/Documentation/devicetree/bindings/display/via,vt8500-fb.txt @@ -0,0 +1,36 @@ +VIA VT8500 Framebuffer +----------------------------------------------------- + +Required properties: +- compatible : "via,vt8500-fb" +- reg : Should contain 1 register ranges(address and length) +- interrupts : framebuffer controller interrupt +- bits-per-pixel : bit depth of framebuffer (16 or 32) + +Required subnodes: +- display-timings: see display-timing.txt for information + +Example: + + fb@d8050800 { + compatible = "via,vt8500-fb"; + reg = <0xd800e400 0x400>; + interrupts = <12>; + bits-per-pixel = <16>; + + display-timings { + native-mode = <&timing0>; + timing0: 800x480 { + clock-frequency = <0>; /* unused but required */ + hactive = <800>; + vactive = <480>; + hfront-porch = <40>; + hback-porch = <88>; + hsync-len = <0>; + vback-porch = <32>; + vfront-porch = <11>; + vsync-len = <1>; + }; + }; + }; + diff --git a/Documentation/devicetree/bindings/display/wm,prizm-ge-rops.txt b/Documentation/devicetree/bindings/display/wm,prizm-ge-rops.txt new file mode 100644 index 000000000..a850fa011 --- /dev/null +++ b/Documentation/devicetree/bindings/display/wm,prizm-ge-rops.txt @@ -0,0 +1,13 @@ +VIA/Wondermedia Graphics Engine Controller +----------------------------------------------------- + +Required properties: +- compatible : "wm,prizm-ge-rops" +- reg : Should contain 1 register ranges(address and length) + +Example: + + ge_rops@d8050400 { + compatible = "wm,prizm-ge-rops"; + reg = <0xd8050400 0x100>; + }; diff --git a/Documentation/devicetree/bindings/display/wm,wm8505-fb.txt b/Documentation/devicetree/bindings/display/wm,wm8505-fb.txt new file mode 100644 index 000000000..0bcadb284 --- /dev/null +++ b/Documentation/devicetree/bindings/display/wm,wm8505-fb.txt @@ -0,0 +1,33 @@ +Wondermedia WM8505 Framebuffer +----------------------------------------------------- + +Required properties: +- compatible : "wm,wm8505-fb" +- reg : Should contain 1 register ranges(address and length) +- bits-per-pixel : bit depth of framebuffer (16 or 32) + +Required subnodes: +- display-timings: see display-timing.txt for information + +Example: + + fb@d8051700 { + compatible = "wm,wm8505-fb"; + reg = <0xd8051700 0x200>; + bits-per-pixel = <16>; + + display-timings { + native-mode = <&timing0>; + timing0: 800x480 { + clock-frequency = <0>; /* unused but required */ + hactive = <800>; + vactive = <480>; + hfront-porch = <40>; + hback-porch = <88>; + hsync-len = <0>; + vback-porch = <32>; + vfront-porch = <11>; + vsync-len = <1>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt b/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt index 63a48928f..b152a75dc 100644 --- a/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt +++ b/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt @@ -2,9 +2,10 @@ Texas Instruments DMA Crossbar (DMA request router) Required properties: - compatible: "ti,dra7-dma-crossbar" for DRA7xx DMA crossbar + "ti,am335x-edma-crossbar" for AM335x and AM437x - reg: Memory map for accessing module -- #dma-cells: Should be set to <1>. - Clients should use the crossbar request number (input) +- #dma-cells: Should be set to to match with the DMA controller's dma-cells + for ti,dra7-dma-crossbar and <3> for ti,am335x-edma-crossbar. - dma-requests: Number of DMA requests the crossbar can receive - dma-masters: phandle pointing to the DMA controller @@ -14,6 +15,15 @@ The DMA controller node need to have the following poroperties: Optional properties: - ti,dma-safe-map: Safe routing value for unused request lines +Notes: +When requesting channel via ti,dra7-dma-crossbar, the DMA clinet must request +the DMA event number as crossbar ID (input to the DMA crossbar). + +For ti,am335x-edma-crossbar: the meaning of parameters of dmas for clients: +dmas = <&edma_xbar 12 0 1>; where <12> is the DMA request number, <0> is the TC +the event should be assigned and <1> is the mux selection for in the crossbar. +When mux 0 is used the DMA channel can be requested directly from edma node. + Example: /* DMA controller */ @@ -47,6 +57,7 @@ uart1: serial@4806a000 { ti,hwmods = "uart1"; clock-frequency = <48000000>; status = "disabled"; + /* Requesting crossbar input 49 and 50 */ dmas = <&sdma_xbar 49>, <&sdma_xbar 50>; dma-names = "tx", "rx"; }; diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt index 5ba525a10..079b42a81 100644 --- a/Documentation/devicetree/bindings/dma/ti-edma.txt +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt @@ -1,4 +1,117 @@ -TI EDMA +Texas Instruments eDMA + +The eDMA3 consists of two components: Channel controller (CC) and Transfer +Controller(s) (TC). The CC is the main entry for DMA users since it is +responsible for the DMA channel handling, while the TCs are responsible to +execute the actual DMA tansfer. + +------------------------------------------------------------------------------ +eDMA3 Channel Controller + +Required properties: +- compatible: "ti,edma3-tpcc" for the channel controller(s) +- #dma-cells: Should be set to <2>. The first number is the DMA request + number and the second is the TC the channel is serviced on. +- reg: Memory map of eDMA CC +- reg-names: "edma3_cc" +- interrupts: Interrupt lines for CCINT, MPERR and CCERRINT. +- interrupt-names: "edma3_ccint", "emda3_mperr" and "edma3_ccerrint" +- ti,tptcs: List of TPTCs associated with the eDMA in the following form: + <&tptc_phandle TC_priority_number>. The highest priority is 0. + +Optional properties: +- ti,hwmods: Name of the hwmods associated to the eDMA CC +- ti,edma-memcpy-channels: List of channels allocated to be used for memcpy, iow + these channels will be SW triggered channels. See example. +- ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used by + the driver, they are allocated to be used by for example the + DSP. See example. + +------------------------------------------------------------------------------ +eDMA3 Transfer Controller + +Required properties: +- compatible: "ti,edma3-tptc" for the transfer controller(s) +- reg: Memory map of eDMA TC +- interrupts: Interrupt number for TCerrint. + +Optional properties: +- ti,hwmods: Name of the hwmods associated to the given eDMA TC +- interrupt-names: "edma3_tcerrint" + +------------------------------------------------------------------------------ +Example: + +edma: edma@49000000 { + compatible = "ti,edma3-tpcc"; + ti,hwmods = "tpcc"; + reg = <0x49000000 0x10000>; + reg-names = "edma3_cc"; + interrupts = <12 13 14>; + interrupt-names = "edma3_ccint", "emda3_mperr", "edma3_ccerrint"; + dma-requests = <64>; + #dma-cells = <2>; + + ti,tptcs = <&edma_tptc0 7>, <&edma_tptc1 7>, <&edma_tptc2 0>; + + /* Channel 20 and 21 is allocated for memcpy */ + ti,edma-memcpy-channels = <20 21>; + /* The following PaRAM slots are reserved: 35-44 and 100-109 */ + ti,edma-reserved-slot-ranges = <35 10>, <100 10>; +}; + +edma_tptc0: tptc@49800000 { + compatible = "ti,edma3-tptc"; + ti,hwmods = "tptc0"; + reg = <0x49800000 0x100000>; + interrupts = <112>; + interrupt-names = "edm3_tcerrint"; +}; + +edma_tptc1: tptc@49900000 { + compatible = "ti,edma3-tptc"; + ti,hwmods = "tptc1"; + reg = <0x49900000 0x100000>; + interrupts = <113>; + interrupt-names = "edm3_tcerrint"; +}; + +edma_tptc2: tptc@49a00000 { + compatible = "ti,edma3-tptc"; + ti,hwmods = "tptc2"; + reg = <0x49a00000 0x100000>; + interrupts = <114>; + interrupt-names = "edm3_tcerrint"; +}; + +sham: sham@53100000 { + compatible = "ti,omap4-sham"; + ti,hwmods = "sham"; + reg = <0x53100000 0x200>; + interrupts = <109>; + /* DMA channel 36 executed on eDMA TC0 - low priority queue */ + dmas = <&edma 36 0>; + dma-names = "rx"; +}; + +mcasp0: mcasp@48038000 { + compatible = "ti,am33xx-mcasp-audio"; + ti,hwmods = "mcasp0"; + reg = <0x48038000 0x2000>, + <0x46000000 0x400000>; + reg-names = "mpu", "dat"; + interrupts = <80>, <81>; + interrupt-names = "tx", "rx"; + status = "disabled"; + /* DMA channels 8 and 9 executed on eDMA TC2 - high priority queue */ + dmas = <&edma 8 2>, + <&edma 9 2>; + dma-names = "tx", "rx"; +}; + +------------------------------------------------------------------------------ +DEPRECATED binding, new DTS files must use the ti,edma3-tpcc/ti,edma3-tptc +binding. Required properties: - compatible : "ti,edma3" diff --git a/Documentation/devicetree/bindings/drm/armada/marvell,dove-lcd.txt b/Documentation/devicetree/bindings/drm/armada/marvell,dove-lcd.txt deleted file mode 100644 index 46525ea3e..000000000 --- a/Documentation/devicetree/bindings/drm/armada/marvell,dove-lcd.txt +++ /dev/null @@ -1,30 +0,0 @@ -Device Tree bindings for Armada DRM CRTC driver - -Required properties: - - compatible: value should be "marvell,dove-lcd". - - reg: base address and size of the LCD controller - - interrupts: single interrupt number for the LCD controller - - port: video output port with endpoints, as described by graph.txt - -Optional properties: - - - clocks: as described by clock-bindings.txt - - clock-names: as described by clock-bindings.txt - "axiclk" - axi bus clock for pixel clock - "plldivider" - pll divider clock for pixel clock - "ext_ref_clk0" - external clock 0 for pixel clock - "ext_ref_clk1" - external clock 1 for pixel clock - -Note: all clocks are optional but at least one must be specified. -Further clocks may be added in the future according to requirements of -different SoCs. - -Example: - - lcd0: lcd-controller@820000 { - compatible = "marvell,dove-lcd"; - reg = <0x820000 0x1000>; - interrupts = <47>; - clocks = <&si5351 0>; - clock-names = "ext_ref_clk_1"; - }; diff --git a/Documentation/devicetree/bindings/drm/atmel/hlcdc-dc.txt b/Documentation/devicetree/bindings/drm/atmel/hlcdc-dc.txt deleted file mode 100644 index ebc1a914b..000000000 --- a/Documentation/devicetree/bindings/drm/atmel/hlcdc-dc.txt +++ /dev/null @@ -1,53 +0,0 @@ -Device-Tree bindings for Atmel's HLCDC (High LCD Controller) DRM driver - -The Atmel HLCDC Display Controller is subdevice of the HLCDC MFD device. -See ../mfd/atmel-hlcdc.txt for more details. - -Required properties: - - compatible: value should be "atmel,hlcdc-display-controller" - - pinctrl-names: the pin control state names. Should contain "default". - - pinctrl-0: should contain the default pinctrl states. - - #address-cells: should be set to 1. - - #size-cells: should be set to 0. - -Required children nodes: - Children nodes are encoding available output ports and their connections - to external devices using the OF graph reprensentation (see ../graph.txt). - At least one port node is required. - -Example: - - hlcdc: hlcdc@f0030000 { - compatible = "atmel,sama5d3-hlcdc"; - reg = <0xf0030000 0x2000>; - interrupts = <36 IRQ_TYPE_LEVEL_HIGH 0>; - clocks = <&lcdc_clk>, <&lcdck>, <&clk32k>; - clock-names = "periph_clk","sys_clk", "slow_clk"; - status = "disabled"; - - hlcdc-display-controller { - compatible = "atmel,hlcdc-display-controller"; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_lcd_base &pinctrl_lcd_rgb888>; - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - #address-cells = <1>; - #size-cells = <0>; - reg = <0>; - - hlcdc_panel_output: endpoint@0 { - reg = <0>; - remote-endpoint = <&panel_input>; - }; - }; - }; - - hlcdc_pwm: hlcdc-pwm { - compatible = "atmel,hlcdc-pwm"; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_lcd_pwm>; - #pwm-cells = <3>; - }; - }; diff --git a/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt b/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt deleted file mode 100644 index a905c1413..000000000 --- a/Documentation/devicetree/bindings/drm/bridge/dw_hdmi.txt +++ /dev/null @@ -1,50 +0,0 @@ -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/drm/imx/hdmi.txt - * Documentation/devicetree/bindings/video/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 -- 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>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt b/Documentation/devicetree/bindings/drm/i2c/tda998x.txt deleted file mode 100644 index e9e4bce40..000000000 --- a/Documentation/devicetree/bindings/drm/i2c/tda998x.txt +++ /dev/null @@ -1,29 +0,0 @@ -Device-Tree bindings for the NXP TDA998x HDMI transmitter - -Required properties; - - compatible: must be "nxp,tda998x" - - - reg: I2C address - -Optional properties: - - interrupts: interrupt number and trigger type - default: polling - - - pinctrl-0: pin control group to be used for - screen plug/unplug interrupt. - - - pinctrl-names: must contain a "default" entry. - - - video-ports: 24 bits value which defines how the video controller - output is wired to the TDA998x input - default: <0x230145> - -Example: - - tda998x: hdmi-encoder { - compatible = "nxp,tda998x"; - reg = <0x70>; - interrupt-parent = <&gpio0>; - interrupts = <27 2>; /* falling edge */ - pinctrl-0 = <&pmx_camera>; - pinctrl-names = "default"; - }; diff --git a/Documentation/devicetree/bindings/drm/imx/fsl-imx-drm.txt b/Documentation/devicetree/bindings/drm/imx/fsl-imx-drm.txt deleted file mode 100644 index 971c3eedb..000000000 --- a/Documentation/devicetree/bindings/drm/imx/fsl-imx-drm.txt +++ /dev/null @@ -1,105 +0,0 @@ -Freescale i.MX DRM master device -================================ - -The freescale i.MX DRM master device is a virtual device needed to list all -IPU or other display interface nodes that comprise the graphics subsystem. - -Required properties: -- compatible: Should be "fsl,imx-display-subsystem" -- ports: Should contain a list of phandles pointing to display interface ports - of IPU devices - -example: - -display-subsystem { - compatible = "fsl,display-subsystem"; - ports = <&ipu_di0>; -}; - - -Freescale i.MX IPUv3 -==================== - -Required properties: -- compatible: Should be "fsl,-ipu" -- reg: should be register base and length as documented in the - datasheet -- interrupts: Should contain sync interrupt and error interrupt, - in this order. -- resets: phandle pointing to the system reset controller and - reset line index, see reset/fsl,imx-src.txt for details -Optional properties: -- port@[0-3]: Port nodes with endpoint definitions as defined in - Documentation/devicetree/bindings/media/video-interfaces.txt. - Ports 0 and 1 should correspond to CSI0 and CSI1, - ports 2 and 3 should correspond to DI0 and DI1, respectively. - -example: - -ipu: ipu@18000000 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "fsl,imx53-ipu"; - reg = <0x18000000 0x080000000>; - interrupts = <11 10>; - resets = <&src 2>; - - ipu_di0: port@2 { - reg = <2>; - - ipu_di0_disp0: endpoint { - remote-endpoint = <&display_in>; - }; - }; -}; - -Parallel display support -======================== - -Required properties: -- compatible: Should be "fsl,imx-parallel-display" -Optional properties: -- interface_pix_fmt: How this display is connected to the - display interface. Currently supported types: "rgb24", "rgb565", "bgr666" - and "lvds666". -- edid: verbatim EDID data block describing attached display. -- ddc: phandle describing the i2c bus handling the display data - channel -- port@[0-1]: Port nodes with endpoint definitions as defined in - Documentation/devicetree/bindings/media/video-interfaces.txt. - Port 0 is the input port connected to the IPU display interface, - port 1 is the output port connected to a panel. - -example: - -display@di0 { - compatible = "fsl,imx-parallel-display"; - edid = [edid-data]; - interface-pix-fmt = "rgb24"; - - port@0 { - reg = <0>; - - display_in: endpoint { - remote-endpoint = <&ipu_di0_disp0>; - }; - }; - - port@1 { - reg = <1>; - - display_out: endpoint { - remote-endpoint = <&panel_in>; - }; - }; -}; - -panel { - ... - - port { - panel_in: endpoint { - remote-endpoint = <&display_out>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/drm/imx/hdmi.txt b/Documentation/devicetree/bindings/drm/imx/hdmi.txt deleted file mode 100644 index 1b756cf9a..000000000 --- a/Documentation/devicetree/bindings/drm/imx/hdmi.txt +++ /dev/null @@ -1,58 +0,0 @@ -Device-Tree bindings for HDMI Transmitter - -HDMI Transmitter -================ - -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: - - gpr: iomuxc-gpr@020e0000 { - /* ... */ - }; - - hdmi: hdmi@0120000 { - #address-cells = <1>; - #size-cells = <0>; - 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>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/drm/imx/ldb.txt b/Documentation/devicetree/bindings/drm/imx/ldb.txt deleted file mode 100644 index 9a2136643..000000000 --- a/Documentation/devicetree/bindings/drm/imx/ldb.txt +++ /dev/null @@ -1,146 +0,0 @@ -Device-Tree bindings for LVDS Display Bridge (ldb) - -LVDS Display Bridge -=================== - -The LVDS Display Bridge device tree node contains up to two lvds-channel -nodes describing each of the two LVDS encoder channels of the bridge. - -Required properties: - - #address-cells : should be <1> - - #size-cells : should be <0> - - compatible : should be "fsl,imx53-ldb" or "fsl,imx6q-ldb". - Both LDB versions are similar, but i.MX6 has an additional - multiplexer in the front to select any of the four IPU display - interfaces as input for each LVDS channel. - - gpr : should be <&gpr> on i.MX53 and i.MX6q. - The phandle points to the iomuxc-gpr region containing the LVDS - control register. -- clocks, clock-names : phandles to the LDB divider and selector clocks and to - the display interface selector clocks, as described in - Documentation/devicetree/bindings/clock/clock-bindings.txt - The following clocks are expected on i.MX53: - "di0_pll" - LDB LVDS channel 0 mux - "di1_pll" - LDB LVDS channel 1 mux - "di0" - LDB LVDS channel 0 gate - "di1" - LDB LVDS channel 1 gate - "di0_sel" - IPU1 DI0 mux - "di1_sel" - IPU1 DI1 mux - On i.MX6q the following additional clocks are needed: - "di2_sel" - IPU2 DI0 mux - "di3_sel" - IPU2 DI1 mux - The needed clock numbers for each are documented in - Documentation/devicetree/bindings/clock/imx5-clock.txt, and in - Documentation/devicetree/bindings/clock/imx6q-clock.txt. - -Optional properties: - - pinctrl-names : should be "default" on i.MX53, not used on i.MX6q - - pinctrl-0 : a phandle pointing to LVDS pin settings on i.MX53, - not used on i.MX6q - - fsl,dual-channel : boolean. if it exists, only LVDS channel 0 should - be configured - one input will be distributed on both outputs in dual - channel mode - -LVDS Channel -============ - -Each LVDS Channel has to contain either an of graph link to a panel device node -or a display-timings node that describes the video timings for the connected -LVDS display as well as the fsl,data-mapping and fsl,data-width properties. - -Required properties: - - reg : should be <0> or <1> - - port: Input and output port nodes with endpoint definitions as defined in - Documentation/devicetree/bindings/graph.txt. - On i.MX5, the internal two-input-multiplexer is used. Due to hardware - limitations, only one input port (port@[0,1]) can be used for each channel - (lvds-channel@[0,1], respectively). - On i.MX6, there should be four input ports (port@[0-3]) that correspond - to the four LVDS multiplexer inputs. - A single output port (port@2 on i.MX5, port@4 on i.MX6) must be connected - to a panel input port. Optionally, the output port can be left out if - display-timings are used instead. - -Optional properties (required if display-timings are used): - - display-timings : A node that describes the display timings as defined in - Documentation/devicetree/bindings/video/display-timing.txt. - - fsl,data-mapping : should be "spwg" or "jeida" - This describes how the color bits are laid out in the - serialized LVDS signal. - - fsl,data-width : should be <18> or <24> - -example: - -gpr: iomuxc-gpr@53fa8000 { - /* ... */ -}; - -ldb: ldb@53fa8008 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "fsl,imx53-ldb"; - gpr = <&gpr>; - clocks = <&clks IMX5_CLK_LDB_DI0_SEL>, - <&clks IMX5_CLK_LDB_DI1_SEL>, - <&clks IMX5_CLK_IPU_DI0_SEL>, - <&clks IMX5_CLK_IPU_DI1_SEL>, - <&clks IMX5_CLK_LDB_DI0_GATE>, - <&clks IMX5_CLK_LDB_DI1_GATE>; - clock-names = "di0_pll", "di1_pll", - "di0_sel", "di1_sel", - "di0", "di1"; - - /* Using an of-graph endpoint link to connect the panel */ - lvds-channel@0 { - #address-cells = <1>; - #size-cells = <0>; - reg = <0>; - - port@0 { - reg = <0>; - - lvds0_in: endpoint { - remote-endpoint = <&ipu_di0_lvds0>; - }; - }; - - port@2 { - reg = <2>; - - lvds0_out: endpoint { - remote-endpoint = <&panel_in>; - }; - }; - }; - - /* Using display-timings and fsl,data-mapping/width instead */ - lvds-channel@1 { - #address-cells = <1>; - #size-cells = <0>; - reg = <1>; - fsl,data-mapping = "spwg"; - fsl,data-width = <24>; - - display-timings { - /* ... */ - }; - - port@1 { - reg = <1>; - - lvds1_in: endpoint { - remote-endpoint = <&ipu_di1_lvds1>; - }; - }; - }; -}; - -panel: lvds-panel { - /* ... */ - - port { - panel_in: endpoint { - remote-endpoint = <&lvds0_out>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/drm/msm/dsi.txt b/Documentation/devicetree/bindings/drm/msm/dsi.txt deleted file mode 100644 index d56923cd5..000000000 --- a/Documentation/devicetree/bindings/drm/msm/dsi.txt +++ /dev/null @@ -1,149 +0,0 @@ -Qualcomm Technologies Inc. adreno/snapdragon DSI output - -DSI Controller: -Required properties: -- compatible: - * "qcom,mdss-dsi-ctrl" -- reg: Physical base address and length of the registers of controller -- reg-names: The names of register regions. The following regions are required: - * "dsi_ctrl" -- qcom,dsi-host-index: The ID of DSI controller hardware instance. This should - be 0 or 1, since we have 2 DSI controllers at most for now. -- interrupts: The interrupt signal from the DSI block. -- power-domains: Should be <&mmcc MDSS_GDSC>. -- clocks: device clocks - See Documentation/devicetree/bindings/clocks/clock-bindings.txt for details. -- clock-names: the following clocks are required: - * "bus_clk" - * "byte_clk" - * "core_clk" - * "core_mmss_clk" - * "iface_clk" - * "mdp_core_clk" - * "pixel_clk" -- vdd-supply: phandle to vdd regulator device node -- vddio-supply: phandle to vdd-io regulator device node -- vdda-supply: phandle to vdda regulator device node -- qcom,dsi-phy: phandle to DSI PHY device node - -Optional properties: -- panel@0: Node of panel connected to this DSI controller. - See files in Documentation/devicetree/bindings/panel/ for each supported - panel. -- qcom,dual-dsi-mode: Boolean value indicating if the DSI controller is - driving a panel which needs 2 DSI links. -- qcom,master-dsi: Boolean value indicating if the DSI controller is driving - the master link of the 2-DSI panel. -- qcom,sync-dual-dsi: Boolean value indicating if the DSI controller is - driving a 2-DSI panel whose 2 links need receive command simultaneously. -- interrupt-parent: phandle to the MDP block if the interrupt signal is routed - through MDP block -- pinctrl-names: the pin control state names; should contain "default" -- pinctrl-0: the default pinctrl state (active) -- pinctrl-n: the "sleep" pinctrl state -- port: DSI controller output port. This contains one endpoint subnode, with its - remote-endpoint set to the phandle of the connected panel's endpoint. - See Documentation/devicetree/bindings/graph.txt for device graph info. - -DSI PHY: -Required properties: -- compatible: Could be the following - * "qcom,dsi-phy-28nm-hpm" - * "qcom,dsi-phy-28nm-lp" - * "qcom,dsi-phy-20nm" -- reg: Physical base address and length of the registers of PLL, PHY and PHY - regulator -- reg-names: The names of register regions. The following regions are required: - * "dsi_pll" - * "dsi_phy" - * "dsi_phy_regulator" -- qcom,dsi-phy-index: The ID of DSI PHY hardware instance. This should - be 0 or 1, since we have 2 DSI PHYs at most for now. -- power-domains: Should be <&mmcc MDSS_GDSC>. -- clocks: device clocks - See Documentation/devicetree/bindings/clocks/clock-bindings.txt for details. -- clock-names: the following clocks are required: - * "iface_clk" -- vddio-supply: phandle to vdd-io regulator device node - -Optional properties: -- qcom,dsi-phy-regulator-ldo-mode: Boolean value indicating if the LDO mode PHY - regulator is wanted. - -Example: - mdss_dsi0: qcom,mdss_dsi@fd922800 { - compatible = "qcom,mdss-dsi-ctrl"; - qcom,dsi-host-index = <0>; - interrupt-parent = <&mdss_mdp>; - interrupts = <4 0>; - reg-names = "dsi_ctrl"; - reg = <0xfd922800 0x200>; - power-domains = <&mmcc MDSS_GDSC>; - clock-names = - "bus_clk", - "byte_clk", - "core_clk", - "core_mmss_clk", - "iface_clk", - "mdp_core_clk", - "pixel_clk"; - clocks = - <&mmcc MDSS_AXI_CLK>, - <&mmcc MDSS_BYTE0_CLK>, - <&mmcc MDSS_ESC0_CLK>, - <&mmcc MMSS_MISC_AHB_CLK>, - <&mmcc MDSS_AHB_CLK>, - <&mmcc MDSS_MDP_CLK>, - <&mmcc MDSS_PCLK0_CLK>; - vdda-supply = <&pma8084_l2>; - vdd-supply = <&pma8084_l22>; - vddio-supply = <&pma8084_l12>; - - qcom,dsi-phy = <&mdss_dsi_phy0>; - - qcom,dual-dsi-mode; - qcom,master-dsi; - qcom,sync-dual-dsi; - - pinctrl-names = "default", "sleep"; - pinctrl-0 = <&mdss_dsi_active>; - pinctrl-1 = <&mdss_dsi_suspend>; - - panel: panel@0 { - compatible = "sharp,lq101r1sx01"; - reg = <0>; - link2 = <&secondary>; - - power-supply = <...>; - backlight = <...>; - - port { - panel_in: endpoint { - remote-endpoint = <&dsi0_out>; - }; - }; - }; - - port { - dsi0_out: endpoint { - remote-endpoint = <&panel_in>; - }; - }; - }; - - mdss_dsi_phy0: qcom,mdss_dsi_phy@fd922a00 { - compatible = "qcom,dsi-phy-28nm-hpm"; - qcom,dsi-phy-index = <0>; - reg-names = - "dsi_pll", - "dsi_phy", - "dsi_phy_regulator"; - reg = <0xfd922a00 0xd4>, - <0xfd922b00 0x2b0>, - <0xfd922d80 0x7b>; - clock-names = "iface_clk"; - clocks = <&mmcc MDSS_AHB_CLK>; - vddio-supply = <&pma8084_l12>; - - qcom,dsi-phy-regulator-ldo-mode; - }; diff --git a/Documentation/devicetree/bindings/drm/msm/edp.txt b/Documentation/devicetree/bindings/drm/msm/edp.txt deleted file mode 100644 index 3a20f6ea5..000000000 --- a/Documentation/devicetree/bindings/drm/msm/edp.txt +++ /dev/null @@ -1,60 +0,0 @@ -Qualcomm Technologies Inc. adreno/snapdragon eDP output - -Required properties: -- compatible: - * "qcom,mdss-edp" -- reg: Physical base address and length of the registers of controller and PLL -- reg-names: The names of register regions. The following regions are required: - * "edp" - * "pll_base" -- interrupts: The interrupt signal from the eDP block. -- power-domains: Should be <&mmcc MDSS_GDSC>. -- clocks: device clocks - See Documentation/devicetree/bindings/clocks/clock-bindings.txt for details. -- clock-names: the following clocks are required: - * "core_clk" - * "iface_clk" - * "mdp_core_clk" - * "pixel_clk" - * "link_clk" -- #clock-cells: The value should be 1. -- vdda-supply: phandle to vdda regulator device node -- lvl-vdd-supply: phandle to regulator device node which is used to supply power - to HPD receiving chip -- panel-en-gpios: GPIO pin to supply power to panel. -- panel-hpd-gpios: GPIO pin used for eDP hpd. - - -Optional properties: -- interrupt-parent: phandle to the MDP block if the interrupt signal is routed - through MDP block - -Example: - mdss_edp: qcom,mdss_edp@fd923400 { - compatible = "qcom,mdss-edp"; - reg-names = - "edp", - "pll_base"; - reg = <0xfd923400 0x700>, - <0xfd923a00 0xd4>; - interrupt-parent = <&mdss_mdp>; - interrupts = <12 0>; - power-domains = <&mmcc MDSS_GDSC>; - clock-names = - "core_clk", - "pixel_clk", - "iface_clk", - "link_clk", - "mdp_core_clk"; - clocks = - <&mmcc MDSS_EDPAUX_CLK>, - <&mmcc MDSS_EDPPIXEL_CLK>, - <&mmcc MDSS_AHB_CLK>, - <&mmcc MDSS_EDPLINK_CLK>, - <&mmcc MDSS_MDP_CLK>; - #clock-cells = <1>; - vdda-supply = <&pma8084_l12>; - lvl-vdd-supply = <&lvl_vreg>; - panel-en-gpios = <&tlmm 137 0>; - panel-hpd-gpios = <&tlmm 103 0>; - }; diff --git a/Documentation/devicetree/bindings/drm/msm/gpu.txt b/Documentation/devicetree/bindings/drm/msm/gpu.txt deleted file mode 100644 index 67d0a58db..000000000 --- a/Documentation/devicetree/bindings/drm/msm/gpu.txt +++ /dev/null @@ -1,52 +0,0 @@ -Qualcomm adreno/snapdragon GPU - -Required properties: -- compatible: "qcom,adreno-3xx" -- 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. - -Example: - -/ { - ... - - gpu: qcom,kgsl-3d0@4300000 { - compatible = "qcom,adreno-3xx"; - reg = <0x04300000 0x20000>; - reg-names = "kgsl_3d0_reg_memory"; - interrupts = ; - interrupt-names = "kgsl_3d0_irq"; - clock-names = - "core_clk", - "iface_clk", - "mem_iface_clk"; - 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/drm/msm/hdmi.txt b/Documentation/devicetree/bindings/drm/msm/hdmi.txt deleted file mode 100644 index e926239e1..000000000 --- a/Documentation/devicetree/bindings/drm/msm/hdmi.txt +++ /dev/null @@ -1,55 +0,0 @@ -Qualcomm adreno/snapdragon hdmi output - -Required properties: -- compatible: one of the following - * "qcom,hdmi-tx-8994" - * "qcom,hdmi-tx-8084" - * "qcom,hdmi-tx-8974" - * "qcom,hdmi-tx-8660" - * "qcom,hdmi-tx-8960" -- reg: Physical base address and length of the controller's registers -- reg-names: "core_physical" -- interrupts: The interrupt signal from the hdmi block. -- clocks: device clocks - See ../clocks/clock-bindings.txt for details. -- qcom,hdmi-tx-ddc-clk-gpio: ddc clk pin -- qcom,hdmi-tx-ddc-data-gpio: ddc data pin -- qcom,hdmi-tx-hpd-gpio: hpd pin -- core-vdda-supply: phandle to supply regulator -- hdmi-mux-supply: phandle to mux regulator - -Optional properties: -- qcom,hdmi-tx-mux-en-gpio: hdmi mux enable pin -- qcom,hdmi-tx-mux-sel-gpio: hdmi mux select pin -- pinctrl-names: the pin control state names; should contain "default" -- pinctrl-0: the default pinctrl state (active) -- pinctrl-1: the "sleep" pinctrl state - -Example: - -/ { - ... - - hdmi: qcom,hdmi-tx-8960@4a00000 { - compatible = "qcom,hdmi-tx-8960"; - reg-names = "core_physical"; - reg = <0x04a00000 0x1000>; - interrupts = ; - clock-names = - "core_clk", - "master_iface_clk", - "slave_iface_clk"; - clocks = - <&mmcc HDMI_APP_CLK>, - <&mmcc HDMI_M_AHB_CLK>, - <&mmcc HDMI_S_AHB_CLK>; - qcom,hdmi-tx-ddc-clk = <&msmgpio 70 GPIO_ACTIVE_HIGH>; - qcom,hdmi-tx-ddc-data = <&msmgpio 71 GPIO_ACTIVE_HIGH>; - qcom,hdmi-tx-hpd = <&msmgpio 72 GPIO_ACTIVE_HIGH>; - core-vdda-supply = <&pm8921_hdmi_mvs>; - hdmi-mux-supply = <&ext_3p3v>; - pinctrl-names = "default", "sleep"; - pinctrl-0 = <&hpd_active &ddc_active &cec_active>; - pinctrl-1 = <&hpd_suspend &ddc_suspend &cec_suspend>; - }; -}; diff --git a/Documentation/devicetree/bindings/drm/msm/mdp.txt b/Documentation/devicetree/bindings/drm/msm/mdp.txt deleted file mode 100644 index 1a0598e52..000000000 --- a/Documentation/devicetree/bindings/drm/msm/mdp.txt +++ /dev/null @@ -1,48 +0,0 @@ -Qualcomm adreno/snapdragon display controller - -Required properties: -- compatible: - * "qcom,mdp" - mdp4 -- reg: Physical base address and length of the controller's registers. -- interrupts: The interrupt signal from the display controller. -- connectors: array of phandles for output device(s) -- clocks: device clocks - See ../clocks/clock-bindings.txt for details. -- clock-names: the following clocks are required: - * "core_clk" - * "iface_clk" - * "lut_clk" - * "src_clk" - * "hdmi_clk" - * "mpd_clk" - -Optional properties: -- gpus: phandle for gpu device - -Example: - -/ { - ... - - mdp: qcom,mdp@5100000 { - compatible = "qcom,mdp"; - reg = <0x05100000 0xf0000>; - interrupts = ; - connectors = <&hdmi>; - gpus = <&gpu>; - clock-names = - "core_clk", - "iface_clk", - "lut_clk", - "src_clk", - "hdmi_clk", - "mdp_clk"; - clocks = - <&mmcc MDP_SRC>, - <&mmcc MDP_AHB_CLK>, - <&mmcc MDP_LUT_CLK>, - <&mmcc TV_SRC>, - <&mmcc HDMI_TV_CLK>, - <&mmcc MDP_TV_CLK>; - }; -}; diff --git a/Documentation/devicetree/bindings/drm/tilcdc/panel.txt b/Documentation/devicetree/bindings/drm/tilcdc/panel.txt deleted file mode 100644 index 4ab9e2300..000000000 --- a/Documentation/devicetree/bindings/drm/tilcdc/panel.txt +++ /dev/null @@ -1,66 +0,0 @@ -Device-Tree bindings for tilcdc DRM generic panel output driver - -Required properties: - - compatible: value should be "ti,tilcdc,panel". - - panel-info: configuration info to configure LCDC correctly for the panel - - ac-bias: AC Bias Pin Frequency - - ac-bias-intrpt: AC Bias Pin Transitions per Interrupt - - dma-burst-sz: DMA burst size - - bpp: Bits per pixel - - fdd: FIFO DMA Request Delay - - sync-edge: Horizontal and Vertical Sync Edge: 0=rising 1=falling - - sync-ctrl: Horizontal and Vertical Sync: Control: 0=ignore - - raster-order: Raster Data Order Select: 1=Most-to-least 0=Least-to-most - - fifo-th: DMA FIFO threshold - - display-timings: typical videomode of lcd panel. Multiple video modes - can be listed if the panel supports multiple timings, but the 'native-mode' - should be the preferred/default resolution. Refer to - Documentation/devicetree/bindings/video/display-timing.txt for display - timing binding details. - -Optional properties: -- backlight: phandle of the backlight device attached to the panel -- enable-gpios: GPIO pin to enable or disable the panel - -Recommended properties: - - pinctrl-names, pinctrl-0: the pincontrol settings to configure - muxing properly for pins that connect to TFP410 device - -Example: - - /* Settings for CDTech_S035Q01 / LCD3 cape: */ - lcd3 { - compatible = "ti,tilcdc,panel"; - pinctrl-names = "default"; - pinctrl-0 = <&bone_lcd3_cape_lcd_pins>; - backlight = <&backlight>; - enable-gpios = <&gpio3 19 0>; - - panel-info { - ac-bias = <255>; - ac-bias-intrpt = <0>; - dma-burst-sz = <16>; - bpp = <16>; - fdd = <0x80>; - sync-edge = <0>; - sync-ctrl = <1>; - raster-order = <0>; - fifo-th = <0>; - }; - display-timings { - native-mode = <&timing0>; - timing0: 320x240 { - hactive = <320>; - vactive = <240>; - hback-porch = <21>; - hfront-porch = <58>; - hsync-len = <47>; - vback-porch = <11>; - vfront-porch = <23>; - vsync-len = <2>; - clock-frequency = <8000000>; - hsync-active = <0>; - vsync-active = <0>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/drm/tilcdc/tfp410.txt b/Documentation/devicetree/bindings/drm/tilcdc/tfp410.txt deleted file mode 100644 index a58ae7756..000000000 --- a/Documentation/devicetree/bindings/drm/tilcdc/tfp410.txt +++ /dev/null @@ -1,21 +0,0 @@ -Device-Tree bindings for tilcdc DRM TFP410 output driver - -Required properties: - - compatible: value should be "ti,tilcdc,tfp410". - - i2c: the phandle for the i2c device to use for DDC - -Recommended properties: - - pinctrl-names, pinctrl-0: the pincontrol settings to configure - muxing properly for pins that connect to TFP410 device - - powerdn-gpio: the powerdown GPIO, pulled low to power down the - TFP410 device (for DPMS_OFF) - -Example: - - dvicape { - compatible = "ti,tilcdc,tfp410"; - i2c = <&i2c2>; - pinctrl-names = "default"; - pinctrl-0 = <&bone_dvi_cape_dvi_00A1_pins>; - powerdn-gpio = <&gpio2 31 0>; - }; diff --git a/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt deleted file mode 100644 index 2136ee81e..000000000 --- a/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt +++ /dev/null @@ -1,56 +0,0 @@ -Device-Tree bindings for tilcdc DRM driver - -Required properties: - - compatible: value should be "ti,am33xx-tilcdc". - - interrupts: the interrupt number - - reg: base address and size of the LCDC device - -Recommended properties: - - interrupt-parent: the phandle for the interrupt controller that - services interrupts for this device. - - ti,hwmods: Name of the hwmod associated to the LCDC - -Optional properties: - - max-bandwidth: The maximum pixels per second that the memory - interface / lcd controller combination can sustain - - max-width: The maximum horizontal pixel width supported by - the lcd controller. - - max-pixelclock: The maximum pixel clock that can be supported - by the lcd controller in KHz. - -Optional nodes: - - - port/ports: to describe a connection to an external encoder. The - binding follows Documentation/devicetree/bindings/graph.txt and - suppors a single port with a single endpoint. - -Example: - - fb: fb@4830e000 { - compatible = "ti,am33xx-tilcdc"; - reg = <0x4830e000 0x1000>; - interrupt-parent = <&intc>; - interrupts = <36>; - ti,hwmods = "lcdc"; - - port { - lcdc_0: endpoint@0 { - remote-endpoint = <&hdmi_0>; - }; - }; - }; - - tda19988: tda19988 { - compatible = "nxp,tda998x"; - reg = <0x70>; - - pinctrl-names = "default", "off"; - pinctrl-0 = <&nxp_hdmi_bonelt_pins>; - pinctrl-1 = <&nxp_hdmi_bonelt_off_pins>; - - port { - hdmi_0: endpoint@0 { - remote-endpoint = <&lcdc_0>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/edac/apm-xgene-edac.txt b/Documentation/devicetree/bindings/edac/apm-xgene-edac.txt index 78edb8000..78e2a31c5 100644 --- a/Documentation/devicetree/bindings/edac/apm-xgene-edac.txt +++ b/Documentation/devicetree/bindings/edac/apm-xgene-edac.txt @@ -5,6 +5,8 @@ The follow error types are supported: memory controller - Memory controller PMD (L1/L2) - Processor module unit (PMD) L1/L2 cache + L3 - L3 cache controller + SoC - SoC IP's such as Ethernet, SATA, and etc The following section describes the EDAC DT node binding. @@ -30,6 +32,17 @@ Required properties for PMD subnode: - reg : First resource shall be the PMD resource. - pmd-controller : Instance number of the PMD controller. +Required properties for L3 subnode: +- compatible : Shall be "apm,xgene-edac-l3" or + "apm,xgene-edac-l3-v2". +- reg : First resource shall be the L3 EDAC resource. + +Required properties for SoC subnode: +- compatible : Shall be "apm,xgene-edac-soc-v1" for revision 1 or + "apm,xgene-edac-l3-soc" for general value reporting + only. +- reg : First resource shall be the SoC EDAC resource. + Example: csw: csw@7e200000 { compatible = "apm,xgene-csw", "syscon"; @@ -76,4 +89,14 @@ Example: reg = <0x0 0x7c000000 0x0 0x200000>; pmd-controller = <0>; }; + + edacl3@7e600000 { + compatible = "apm,xgene-edac-l3"; + reg = <0x0 0x7e600000 0x0 0x1000>; + }; + + edacsoc@7e930000 { + compatible = "apm,xgene-edac-soc-v1"; + reg = <0x0 0x7e930000 0x0 0x1000>; + }; }; diff --git a/Documentation/devicetree/bindings/eeprom.txt b/Documentation/devicetree/bindings/eeprom.txt deleted file mode 100644 index 4342c10de..000000000 --- a/Documentation/devicetree/bindings/eeprom.txt +++ /dev/null @@ -1,28 +0,0 @@ -EEPROMs (I2C) - -Required properties: - - - compatible : should be "," - If there is no specific driver for , a generic - driver based on is selected. Possible types are: - 24c00, 24c01, 24c02, 24c04, 24c08, 24c16, 24c32, 24c64, - 24c128, 24c256, 24c512, 24c1024, spd - - - reg : the I2C address of the EEPROM - -Optional properties: - - - pagesize : the length of the pagesize for writing. Please consult the - manual of your device, that value varies a lot. A wrong value - may result in data loss! If not specified, a safety value of - '1' is used which will be very slow. - - - read-only: this parameterless property disables writes to the eeprom - -Example: - -eeprom@52 { - compatible = "atmel,24c32"; - reg = <0x52>; - pagesize = <32>; -}; diff --git a/Documentation/devicetree/bindings/eeprom/at25.txt b/Documentation/devicetree/bindings/eeprom/at25.txt new file mode 100644 index 000000000..1d3447165 --- /dev/null +++ b/Documentation/devicetree/bindings/eeprom/at25.txt @@ -0,0 +1,35 @@ +EEPROMs (SPI) compatible with Atmel at25. + +Required properties: +- compatible : "atmel,at25". +- reg : chip select number +- spi-max-frequency : max spi frequency to use +- pagesize : size of the eeprom page +- size : total eeprom size in bytes +- address-width : number of address bits (one of 8, 16, or 24) + +Optional properties: +- spi-cpha : SPI shifted clock phase, as per spi-bus bindings. +- spi-cpol : SPI inverse clock polarity, as per spi-bus bindings. +- read-only : this parameter-less property disables writes to the eeprom + +Obsolete legacy properties are can be used in place of "size", "pagesize", +"address-width", and "read-only": +- at25,byte-len : total eeprom size in bytes +- at25,addr-mode : addr-mode flags, as defined in include/linux/spi/eeprom.h +- at25,page-size : size of the eeprom page + +Additional compatible properties are also allowed. + +Example: + at25@0 { + compatible = "atmel,at25", "st,m95256"; + reg = <0> + spi-max-frequency = <5000000>; + spi-cpha; + spi-cpol; + + pagesize = <64>; + size = <32768>; + address-width = <16>; + }; diff --git a/Documentation/devicetree/bindings/eeprom/eeprom.txt b/Documentation/devicetree/bindings/eeprom/eeprom.txt new file mode 100644 index 000000000..4342c10de --- /dev/null +++ b/Documentation/devicetree/bindings/eeprom/eeprom.txt @@ -0,0 +1,28 @@ +EEPROMs (I2C) + +Required properties: + + - compatible : should be "," + If there is no specific driver for , a generic + driver based on is selected. Possible types are: + 24c00, 24c01, 24c02, 24c04, 24c08, 24c16, 24c32, 24c64, + 24c128, 24c256, 24c512, 24c1024, spd + + - reg : the I2C address of the EEPROM + +Optional properties: + + - pagesize : the length of the pagesize for writing. Please consult the + manual of your device, that value varies a lot. A wrong value + may result in data loss! If not specified, a safety value of + '1' is used which will be very slow. + + - read-only: this parameterless property disables writes to the eeprom + +Example: + +eeprom@52 { + compatible = "atmel,24c32"; + reg = <0x52>; + pagesize = <32>; +}; diff --git a/Documentation/devicetree/bindings/extcon/extcon-arizona.txt b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt new file mode 100644 index 000000000..e1705fae6 --- /dev/null +++ b/Documentation/devicetree/bindings/extcon/extcon-arizona.txt @@ -0,0 +1,15 @@ +Cirrus Logic Arizona class audio SoCs + +These devices are audio SoCs with extensive digital capabilities and a range +of analogue I/O. + +This document lists Extcon specific bindings, see the primary binding document: + ../mfd/arizona.txt + +Optional properties: + + - wlf,hpdet-channel : Headphone detection channel. + ARIZONA_ACCDET_MODE_HPL or 1 - Headphone detect mode is set to HPDETL + ARIZONA_ACCDET_MODE_HPR or 2 - Headphone detect mode is set to HPDETR + If this node is not mentioned or if the value is unknown, then + headphone detection mode is set to HPDETL. diff --git a/Documentation/devicetree/bindings/fb/mxsfb.txt b/Documentation/devicetree/bindings/fb/mxsfb.txt deleted file mode 100644 index 96ec5179c..000000000 --- a/Documentation/devicetree/bindings/fb/mxsfb.txt +++ /dev/null @@ -1,49 +0,0 @@ -* Freescale MXS LCD Interface (LCDIF) - -Required properties: -- compatible: Should be "fsl,-lcdif". Supported chips include - imx23 and imx28. -- reg: Address and length of the register set for lcdif -- interrupts: Should contain lcdif interrupts -- display : phandle to display node (see below for details) - -* display node - -Required properties: -- bits-per-pixel : <16> for RGB565, <32> for RGB888/666. -- bus-width : number of data lines. Could be <8>, <16>, <18> or <24>. - -Required sub-node: -- display-timings : Refer to binding doc display-timing.txt for details. - -Examples: - -lcdif@80030000 { - compatible = "fsl,imx28-lcdif"; - reg = <0x80030000 2000>; - interrupts = <38 86>; - - display: display { - bits-per-pixel = <32>; - bus-width = <24>; - - display-timings { - native-mode = <&timing0>; - timing0: timing0 { - clock-frequency = <33500000>; - hactive = <800>; - vactive = <480>; - hfront-porch = <164>; - hback-porch = <89>; - hsync-len = <10>; - vback-porch = <23>; - vfront-porch = <10>; - vsync-len = <10>; - hsync-active = <0>; - vsync-active = <0>; - de-active = <1>; - pixelclk-active = <0>; - }; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/fb/sm501fb.txt b/Documentation/devicetree/bindings/fb/sm501fb.txt deleted file mode 100644 index 9d9f00980..000000000 --- a/Documentation/devicetree/bindings/fb/sm501fb.txt +++ /dev/null @@ -1,34 +0,0 @@ -* SM SM501 - -The SM SM501 is a LCD controller, with proper hardware, it can also -drive DVI monitors. - -Required properties: -- compatible : should be "smi,sm501". -- reg : contain two entries: - - First entry: System Configuration register - - Second entry: IO space (Display Controller register) -- interrupts : SMI interrupt to the cpu should be described here. -- interrupt-parent : the phandle for the interrupt controller that - services interrupts for this device. - -Optional properties: -- mode : select a video mode: - x[-][@] -- edid : verbatim EDID data block describing attached display. - Data from the detailed timing descriptor will be used to - program the display controller. -- little-endian: available on big endian systems, to - set different foreign endian. -- big-endian: available on little endian systems, to - set different foreign endian. - -Example for MPC5200: - display@1,0 { - compatible = "smi,sm501"; - reg = <1 0x00000000 0x00800000 - 1 0x03e00000 0x00200000>; - interrupts = <1 1 3>; - mode = "640x480-32@60"; - edid = [edid-data]; - }; diff --git a/Documentation/devicetree/bindings/fpga/altera-socfpga-fpga-mgr.txt b/Documentation/devicetree/bindings/fpga/altera-socfpga-fpga-mgr.txt index 9b027a615..d52f33404 100644 --- a/Documentation/devicetree/bindings/fpga/altera-socfpga-fpga-mgr.txt +++ b/Documentation/devicetree/bindings/fpga/altera-socfpga-fpga-mgr.txt @@ -9,7 +9,7 @@ Required properties: Example: - hps_0_fpgamgr: fpgamgr@0xff706000 { + hps_0_fpgamgr: fpgamgr@ff706000 { compatible = "altr,socfpga-fpga-mgr"; reg = <0xFF706000 0x1000 0xFFB90000 0x1000>; diff --git a/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.txt b/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.txt new file mode 100644 index 000000000..7018aa896 --- /dev/null +++ b/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.txt @@ -0,0 +1,19 @@ +Xilinx Zynq FPGA Manager + +Required properties: +- compatible: should contain "xlnx,zynq-devcfg-1.0" +- reg: base address and size for memory mapped io +- interrupts: interrupt for the FPGA manager device +- clocks: phandle for clocks required operation +- clock-names: name for the clock, should be "ref_clk" +- syscon: phandle for access to SLCR registers + +Example: + devcfg: devcfg@f8007000 { + compatible = "xlnx,zynq-devcfg-1.0"; + reg = <0xf8007000 0x100>; + interrupts = <0 8 4>; + clocks = <&clkc 12>; + clock-names = "ref_clk"; + syscon = <&slcr>; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt index 805ddcd79..120bc4971 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt @@ -1,9 +1,9 @@ -* Freescale MPC512x/MPC8xxx GPIO controller +* Freescale MPC512x/MPC8xxx/Layerscape GPIO controller Required properties: - compatible : Should be "fsl,-gpio" The following s are known to be supported: - mpc5121, mpc5125, mpc8349, mpc8572, mpc8610, pq3, qoriq + mpc5121, mpc5125, mpc8349, mpc8572, mpc8610, pq3, qoriq. - reg : Address and length of the register set for the device - interrupts : Should be the port interrupt shared by all 32 pins. - #gpio-cells : Should be two. The first cell is the pin number and @@ -11,6 +11,10 @@ Required properties: 0 = active high 1 = active low +Optional properties: +- little-endian : GPIO registers are used as little endian. If not + present registers are used as big endian by default. + Example: gpio0: gpio@1100 { diff --git a/Documentation/devicetree/bindings/gpio/gpio-msm.txt b/Documentation/devicetree/bindings/gpio/gpio-msm.txt deleted file mode 100644 index ac20e68a0..000000000 --- a/Documentation/devicetree/bindings/gpio/gpio-msm.txt +++ /dev/null @@ -1,26 +0,0 @@ -MSM GPIO controller bindings - -Required properties: -- compatible: - - "qcom,msm-gpio" for MSM controllers -- #gpio-cells : Should be two. - - first cell is the pin number - - second cell is used to specify optional parameters (unused) -- gpio-controller : Marks the device node as a GPIO controller. -- #interrupt-cells : Should be 2. -- interrupt-controller: Mark the device node as an interrupt controller -- interrupts : Specify the TLMM summary interrupt number -- ngpio : Specify the number of MSM GPIOs - -Example: - - msmgpio: gpio@fd510000 { - compatible = "qcom,msm-gpio"; - gpio-controller; - #gpio-cells = <2>; - interrupt-controller; - #interrupt-cells = <2>; - reg = <0xfd510000 0x4000>; - interrupts = <0 208 0>; - ngpio = <150>; - }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt index b9a42f294..13df9933f 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-pca953x.txt @@ -24,6 +24,7 @@ Required properties: ti,tca6408 ti,tca6416 ti,tca6424 + ti,tca9539 exar,xra1202 Example: diff --git a/Documentation/devicetree/bindings/gpio/gpio-zynq.txt b/Documentation/devicetree/bindings/gpio/gpio-zynq.txt index db4c6a663..7b542657f 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-zynq.txt +++ b/Documentation/devicetree/bindings/gpio/gpio-zynq.txt @@ -12,6 +12,13 @@ Required properties: - interrupts : Interrupt specifier (see interrupt bindings for details) - interrupt-parent : Must be core interrupt controller +- interrupt-controller : Marks the device node as an interrupt controller. +- #interrupt-cells : Should be 2. The first cell is the GPIO number. + The second cell bits[3:0] is used to specify trigger type and level flags: + 1 = low-to-high edge triggered. + 2 = high-to-low edge triggered. + 4 = active high level-sensitive. + 8 = active low level-sensitive. - reg : Address and length of the register set for the device Example: @@ -22,5 +29,7 @@ Example: gpio-controller; interrupt-parent = <&intc>; interrupts = <0 20 4>; + interrupt-controller; + #interrupt-cells = <2>; reg = <0xe000a000 0x1000>; }; diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt index 82d40e250..069cdf6f9 100644 --- a/Documentation/devicetree/bindings/gpio/gpio.txt +++ b/Documentation/devicetree/bindings/gpio/gpio.txt @@ -54,9 +54,13 @@ only uses one. gpio-specifier may encode: bank, pin position inside the bank, whether pin is open-drain and whether pin is logically inverted. + Exact meaning of each specifier cell is controller specific, and must -be documented in the device tree binding for the device. Use the macros -defined in include/dt-bindings/gpio/gpio.h whenever possible: +be documented in the device tree binding for the device. + +Most controllers are however specifying a generic flag bitfield +in the last cell, so for these, use the macros defined in +include/dt-bindings/gpio/gpio.h whenever possible: Example of a node using GPIOs: @@ -67,6 +71,15 @@ Example of a node using GPIOs: GPIO_ACTIVE_HIGH is 0, so in this example gpio-specifier is "18 0" and encodes GPIO pin number, and GPIO flags as accepted by the "qe_pio_e" gpio-controller. +Optional standard bitfield specifiers for the last cell: + +- Bit 0: 0 means active high, 1 means active low +- Bit 1: 1 means single-ended wiring, see: + https://en.wikipedia.org/wiki/Single-ended_triode + When used with active-low, this means open drain/collector, see: + https://en.wikipedia.org/wiki/Open_collector + When used with active-high, this means open source/emitter + 1.1) GPIO specifier best practices ---------------------------------- @@ -118,6 +131,30 @@ Every GPIO controller node must contain both an empty "gpio-controller" property, and a #gpio-cells integer property, which indicates the number of cells in a gpio-specifier. +Optionally, a GPIO controller may have a "ngpios" property. This property +indicates the number of in-use slots of available slots for GPIOs. The +typical example is something like this: the hardware register is 32 bits +wide, but only 18 of the bits have a physical counterpart. The driver is +generally written so that all 32 bits can be used, but the IP block is reused +in a lot of designs, some using all 32 bits, some using 18 and some using +12. In this case, setting "ngpios = <18>;" informs the driver that only the +first 18 GPIOs, at local offset 0 .. 17, are in use. + +If these GPIOs do not happen to be the first N GPIOs at offset 0...N-1, an +additional bitmask is needed to specify which GPIOs are actually in use, +and which are dummies. The bindings for this case has not yet been +specified, but should be specified if/when such hardware appears. + +Example: + +gpio-controller@00000000 { + compatible = "foo"; + reg = <0x00000000 0x1000>; + gpio-controller; + #gpio-cells = <2>; + ngpios = <18>; +} + The GPIO chip may contain GPIO hog definitions. GPIO hogging is a mechanism providing automatic GPIO request and configuration as part of the gpio-controller's driver probe function. diff --git a/Documentation/devicetree/bindings/gpio/netxbig-gpio-ext.txt b/Documentation/devicetree/bindings/gpio/netxbig-gpio-ext.txt new file mode 100644 index 000000000..50ec2e690 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/netxbig-gpio-ext.txt @@ -0,0 +1,22 @@ +Binding for the GPIO extension bus found on some LaCie/Seagate boards +(Example: 2Big/5Big Network v2, 2Big NAS). + +Required properties: +- compatible: "lacie,netxbig-gpio-ext". +- addr-gpios: GPIOs representing the address register (LSB -> MSB). +- data-gpios: GPIOs representing the data register (LSB -> MSB). +- enable-gpio: latches the new configuration (address, data) on raising edge. + +Example: + +netxbig_gpio_ext: netxbig-gpio-ext { + compatible = "lacie,netxbig-gpio-ext"; + + addr-gpios = <&gpio1 15 GPIO_ACTIVE_HIGH + &gpio1 16 GPIO_ACTIVE_HIGH + &gpio1 17 GPIO_ACTIVE_HIGH>; + data-gpios = <&gpio1 12 GPIO_ACTIVE_HIGH + &gpio1 13 GPIO_ACTIVE_HIGH + &gpio1 14 GPIO_ACTIVE_HIGH>; + enable-gpio = <&gpio0 29 GPIO_ACTIVE_HIGH>; +}; diff --git a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt deleted file mode 100644 index e685610d3..000000000 --- a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt +++ /dev/null @@ -1,380 +0,0 @@ -NVIDIA Tegra host1x - -Required properties: -- compatible: "nvidia,tegra-host1x" -- reg: Physical base address and length of the controller's registers. -- interrupts: The interrupt outputs from the controller. -- #address-cells: The number of cells used to represent physical base addresses - in the host1x address space. Should be 1. -- #size-cells: The number of cells used to represent the size of an address - range in the host1x address space. Should be 1. -- ranges: The mapping of the host1x address space to the CPU address space. -- clocks: Must contain one entry, for the module clock. - See ../clocks/clock-bindings.txt for details. -- resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. -- reset-names: Must include the following entries: - - host1x - -The host1x top-level node defines a number of children, each representing one -of the following host1x client modules: - -- mpe: video encoder - - Required properties: - - compatible: "nvidia,tegra-mpe" - - reg: Physical base address and length of the controller's registers. - - interrupts: The interrupt outputs from the controller. - - clocks: Must contain one entry, for the module clock. - See ../clocks/clock-bindings.txt for details. - - resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. - - reset-names: Must include the following entries: - - mpe - -- vi: video input - - Required properties: - - compatible: "nvidia,tegra-vi" - - reg: Physical base address and length of the controller's registers. - - interrupts: The interrupt outputs from the controller. - - clocks: Must contain one entry, for the module clock. - See ../clocks/clock-bindings.txt for details. - - resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. - - reset-names: Must include the following entries: - - vi - -- epp: encoder pre-processor - - Required properties: - - compatible: "nvidia,tegra-epp" - - reg: Physical base address and length of the controller's registers. - - interrupts: The interrupt outputs from the controller. - - clocks: Must contain one entry, for the module clock. - See ../clocks/clock-bindings.txt for details. - - resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. - - reset-names: Must include the following entries: - - epp - -- isp: image signal processor - - Required properties: - - compatible: "nvidia,tegra-isp" - - reg: Physical base address and length of the controller's registers. - - interrupts: The interrupt outputs from the controller. - - clocks: Must contain one entry, for the module clock. - See ../clocks/clock-bindings.txt for details. - - resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. - - reset-names: Must include the following entries: - - isp - -- gr2d: 2D graphics engine - - Required properties: - - compatible: "nvidia,tegra-gr2d" - - reg: Physical base address and length of the controller's registers. - - interrupts: The interrupt outputs from the controller. - - clocks: Must contain one entry, for the module clock. - See ../clocks/clock-bindings.txt for details. - - resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. - - reset-names: Must include the following entries: - - 2d - -- gr3d: 3D graphics engine - - Required properties: - - compatible: "nvidia,tegra-gr3d" - - reg: Physical base address and length of the controller's registers. - - clocks: Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. - - clock-names: Must include the following entries: - (This property may be omitted if the only clock in the list is "3d") - - 3d - This MUST be the first entry. - - 3d2 (Only required on SoCs with two 3D clocks) - - resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. - - reset-names: Must include the following entries: - - 3d - - 3d2 (Only required on SoCs with two 3D clocks) - -- dc: display controller - - Required properties: - - compatible: "nvidia,tegra-dc" - - reg: Physical base address and length of the controller's registers. - - interrupts: The interrupt outputs from the controller. - - clocks: Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. - - clock-names: Must include the following entries: - - dc - This MUST be the first entry. - - parent - - resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. - - reset-names: Must include the following entries: - - dc - - nvidia,head: The number of the display controller head. This is used to - setup the various types of output to receive video data from the given - head. - - Each display controller node has a child node, named "rgb", that represents - the RGB output associated with the controller. It can take the following - optional properties: - - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing - - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection - - nvidia,edid: supplies a binary EDID blob - - nvidia,panel: phandle of a display panel - -- hdmi: High Definition Multimedia Interface - - Required properties: - - compatible: "nvidia,tegra-hdmi" - - reg: Physical base address and length of the controller's registers. - - interrupts: The interrupt outputs from the controller. - - hdmi-supply: supply for the +5V HDMI connector pin - - vdd-supply: regulator for supply voltage - - pll-supply: regulator for PLL - - clocks: Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. - - clock-names: Must include the following entries: - - hdmi - This MUST be the first entry. - - parent - - resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. - - reset-names: Must include the following entries: - - hdmi - - Optional properties: - - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing - - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection - - nvidia,edid: supplies a binary EDID blob - - nvidia,panel: phandle of a display panel - -- tvo: TV encoder output - - Required properties: - - compatible: "nvidia,tegra-tvo" - - reg: Physical base address and length of the controller's registers. - - interrupts: The interrupt outputs from the controller. - - clocks: Must contain one entry, for the module clock. - See ../clocks/clock-bindings.txt for details. - -- dsi: display serial interface - - Required properties: - - compatible: "nvidia,tegra-dsi" - - reg: Physical base address and length of the controller's registers. - - clocks: Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. - - clock-names: Must include the following entries: - - dsi - This MUST be the first entry. - - lp - - parent - - resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. - - reset-names: Must include the following entries: - - dsi - - avdd-dsi-supply: phandle of a supply that powers the DSI controller - - nvidia,mipi-calibrate: Should contain a phandle and a specifier specifying - which pads are used by this DSI output and need to be calibrated. See also - ../mipi/nvidia,tegra114-mipi.txt. - - Optional properties: - - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing - - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection - - nvidia,edid: supplies a binary EDID blob - - nvidia,panel: phandle of a display panel - - nvidia,ganged-mode: contains a phandle to a second DSI controller to gang - up with in order to support up to 8 data lanes - -- sor: serial output resource - - Required properties: - - compatible: Should be: - - "nvidia,tegra124-sor": for Tegra124 and Tegra132 - - "nvidia,tegra132-sor": for Tegra132 - - "nvidia,tegra210-sor": for Tegra210 - - "nvidia,tegra210-sor1": for Tegra210 - - reg: Physical base address and length of the controller's registers. - - interrupts: The interrupt outputs from the controller. - - clocks: Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. - - clock-names: Must include the following entries: - - sor: clock input for the SOR hardware - - parent: input for the pixel clock - - dp: reference clock for the SOR clock - - safe: safe reference for the SOR clock during power up - - resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. - - reset-names: Must include the following entries: - - sor - - Optional properties: - - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing - - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection - - nvidia,edid: supplies a binary EDID blob - - nvidia,panel: phandle of a display panel - - Optional properties when driving an eDP output: - - nvidia,dpaux: phandle to a DispayPort AUX interface - -- dpaux: DisplayPort AUX interface - - compatible: For Tegra124, must contain "nvidia,tegra124-dpaux". Otherwise, - must contain '"nvidia,-dpaux", "nvidia,tegra124-dpaux"', where - is tegra132. - - reg: Physical base address and length of the controller's registers. - - interrupts: The interrupt outputs from the controller. - - clocks: Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. - - clock-names: Must include the following entries: - - dpaux: clock input for the DPAUX hardware - - parent: reference clock - - resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. - - reset-names: Must include the following entries: - - dpaux - - vdd-supply: phandle of a supply that powers the DisplayPort link - -Example: - -/ { - ... - - host1x { - compatible = "nvidia,tegra20-host1x", "simple-bus"; - reg = <0x50000000 0x00024000>; - interrupts = <0 65 0x04 /* mpcore syncpt */ - 0 67 0x04>; /* mpcore general */ - clocks = <&tegra_car TEGRA20_CLK_HOST1X>; - resets = <&tegra_car 28>; - reset-names = "host1x"; - - #address-cells = <1>; - #size-cells = <1>; - - ranges = <0x54000000 0x54000000 0x04000000>; - - mpe { - compatible = "nvidia,tegra20-mpe"; - reg = <0x54040000 0x00040000>; - interrupts = <0 68 0x04>; - clocks = <&tegra_car TEGRA20_CLK_MPE>; - resets = <&tegra_car 60>; - reset-names = "mpe"; - }; - - vi { - compatible = "nvidia,tegra20-vi"; - reg = <0x54080000 0x00040000>; - interrupts = <0 69 0x04>; - clocks = <&tegra_car TEGRA20_CLK_VI>; - resets = <&tegra_car 100>; - reset-names = "vi"; - }; - - epp { - compatible = "nvidia,tegra20-epp"; - reg = <0x540c0000 0x00040000>; - interrupts = <0 70 0x04>; - clocks = <&tegra_car TEGRA20_CLK_EPP>; - resets = <&tegra_car 19>; - reset-names = "epp"; - }; - - isp { - compatible = "nvidia,tegra20-isp"; - reg = <0x54100000 0x00040000>; - interrupts = <0 71 0x04>; - clocks = <&tegra_car TEGRA20_CLK_ISP>; - resets = <&tegra_car 23>; - reset-names = "isp"; - }; - - gr2d { - compatible = "nvidia,tegra20-gr2d"; - reg = <0x54140000 0x00040000>; - interrupts = <0 72 0x04>; - clocks = <&tegra_car TEGRA20_CLK_GR2D>; - resets = <&tegra_car 21>; - reset-names = "2d"; - }; - - gr3d { - compatible = "nvidia,tegra20-gr3d"; - reg = <0x54180000 0x00040000>; - clocks = <&tegra_car TEGRA20_CLK_GR3D>; - resets = <&tegra_car 24>; - reset-names = "3d"; - }; - - dc@54200000 { - compatible = "nvidia,tegra20-dc"; - reg = <0x54200000 0x00040000>; - interrupts = <0 73 0x04>; - clocks = <&tegra_car TEGRA20_CLK_DISP1>, - <&tegra_car TEGRA20_CLK_PLL_P>; - clock-names = "dc", "parent"; - resets = <&tegra_car 27>; - reset-names = "dc"; - - rgb { - status = "disabled"; - }; - }; - - dc@54240000 { - compatible = "nvidia,tegra20-dc"; - reg = <0x54240000 0x00040000>; - interrupts = <0 74 0x04>; - clocks = <&tegra_car TEGRA20_CLK_DISP2>, - <&tegra_car TEGRA20_CLK_PLL_P>; - clock-names = "dc", "parent"; - resets = <&tegra_car 26>; - reset-names = "dc"; - - rgb { - status = "disabled"; - }; - }; - - hdmi { - compatible = "nvidia,tegra20-hdmi"; - reg = <0x54280000 0x00040000>; - interrupts = <0 75 0x04>; - clocks = <&tegra_car TEGRA20_CLK_HDMI>, - <&tegra_car TEGRA20_CLK_PLL_D_OUT0>; - clock-names = "hdmi", "parent"; - resets = <&tegra_car 51>; - reset-names = "hdmi"; - status = "disabled"; - }; - - tvo { - compatible = "nvidia,tegra20-tvo"; - reg = <0x542c0000 0x00040000>; - interrupts = <0 76 0x04>; - clocks = <&tegra_car TEGRA20_CLK_TVO>; - status = "disabled"; - }; - - dsi { - compatible = "nvidia,tegra20-dsi"; - reg = <0x54300000 0x00040000>; - clocks = <&tegra_car TEGRA20_CLK_DSI>, - <&tegra_car TEGRA20_CLK_PLL_D_OUT0>; - clock-names = "dsi", "parent"; - resets = <&tegra_car 48>; - reset-names = "dsi"; - status = "disabled"; - }; - }; - - ... -}; diff --git a/Documentation/devicetree/bindings/gpu/st,stih4xx.txt b/Documentation/devicetree/bindings/gpu/st,stih4xx.txt deleted file mode 100644 index a36dfce00..000000000 --- a/Documentation/devicetree/bindings/gpu/st,stih4xx.txt +++ /dev/null @@ -1,241 +0,0 @@ -STMicroelectronics stih4xx platforms - -- sti-vtg: video timing generator - Required properties: - - compatible: "st,vtg" - - reg: Physical base address of the IP registers and length of memory mapped region. - Optional properties: - - interrupts : VTG interrupt number to the CPU. - - st,slave: phandle on a slave vtg - -- sti-vtac: video timing advanced inter dye communication Rx and TX - Required properties: - - compatible: "st,vtac-main" or "st,vtac-aux" - - reg: Physical base address of the IP registers and length of memory mapped region. - - clocks: from common clock binding: handle hardware IP needed clocks, the - number of clocks may depend of the SoC type. - See ../clocks/clock-bindings.txt for details. - - clock-names: names of the clocks listed in clocks property in the same - order. - -- sti-display-subsystem: Master device for DRM sub-components - This device must be the parent of all the sub-components and is responsible - of bind them. - Required properties: - - compatible: "st,sti-display-subsystem" - - ranges: to allow probing of subdevices - -- sti-compositor: frame compositor engine - must be a child of sti-display-subsystem - Required properties: - - compatible: "st,stih-compositor" - - reg: Physical base address of the IP registers and length of memory mapped region. - - clocks: from common clock binding: handle hardware IP needed clocks, the - number of clocks may depend of the SoC type. - See ../clocks/clock-bindings.txt for details. - - clock-names: names of the clocks listed in clocks property in the same - order. - - resets: resets to be used by the device - See ../reset/reset.txt for details. - - reset-names: names of the resets listed in resets property in the same - order. - - st,vtg: phandle(s) on vtg device (main and aux) nodes. - -- sti-tvout: video out hardware block - must be a child of sti-display-subsystem - Required properties: - - compatible: "st,stih-tvout" - - reg: Physical base address of the IP registers and length of memory mapped region. - - reg-names: names of the mapped memory regions listed in regs property in - the same order. - - resets: resets to be used by the device - See ../reset/reset.txt for details. - - reset-names: names of the resets listed in resets property in the same - order. - -- sti-hdmi: hdmi output block - must be a child of sti-display-subsystem - Required properties: - - compatible: "st,stih-hdmi"; - - reg: Physical base address of the IP registers and length of memory mapped region. - - reg-names: names of the mapped memory regions listed in regs property in - the same order. - - interrupts : HDMI interrupt number to the CPU. - - interrupt-names: name of the interrupts listed in interrupts property in - the same order - - clocks: from common clock binding: handle hardware IP needed clocks, the - number of clocks may depend of the SoC type. - - clock-names: names of the clocks listed in clocks property in the same - order. - - ddc: phandle of an I2C controller used for DDC EDID probing - -sti-hda: - Required properties: - must be a child of sti-display-subsystem - - compatible: "st,stih-hda" - - reg: Physical base address of the IP registers and length of memory mapped region. - - reg-names: names of the mapped memory regions listed in regs property in - the same order. - - clocks: from common clock binding: handle hardware IP needed clocks, the - number of clocks may depend of the SoC type. - See ../clocks/clock-bindings.txt for details. - - clock-names: names of the clocks listed in clocks property in the same - order. - -sti-dvo: - Required properties: - must be a child of sti-display-subsystem - - compatible: "st,stih-dvo" - - reg: Physical base address of the IP registers and length of memory mapped region. - - reg-names: names of the mapped memory regions listed in regs property in - the same order. - - clocks: from common clock binding: handle hardware IP needed clocks, the - number of clocks may depend of the SoC type. - See ../clocks/clock-bindings.txt for details. - - clock-names: names of the clocks listed in clocks property in the same - order. - - pinctrl-0: pin control handle - - pinctrl-name: names of the pin control to use - - sti,panel: phandle of the panel connected to the DVO output - -sti-hqvdp: - must be a child of sti-display-subsystem - Required properties: - - compatible: "st,stih-hqvdp" - - reg: Physical base address of the IP registers and length of memory mapped region. - - clocks: from common clock binding: handle hardware IP needed clocks, the - number of clocks may depend of the SoC type. - See ../clocks/clock-bindings.txt for details. - - clock-names: names of the clocks listed in clocks property in the same - order. - - resets: resets to be used by the device - See ../reset/reset.txt for details. - - reset-names: names of the resets listed in resets property in the same - order. - - st,vtg: phandle on vtg main device node. - -Example: - -/ { - ... - - vtg_main_slave: sti-vtg-main-slave@fe85A800 { - compatible = "st,vtg"; - reg = <0xfe85A800 0x300>; - interrupts = ; - }; - - vtg_main: sti-vtg-main-master@fd348000 { - compatible = "st,vtg"; - reg = <0xfd348000 0x400>; - st,slave = <&vtg_main_slave>; - }; - - vtg_aux_slave: sti-vtg-aux-slave@fd348400 { - compatible = "st,vtg"; - reg = <0xfe858200 0x300>; - interrupts = ; - }; - - vtg_aux: sti-vtg-aux-master@fd348400 { - compatible = "st,vtg"; - reg = <0xfd348400 0x400>; - st,slave = <&vtg_aux_slave>; - }; - - - sti-vtac-rx-main@fee82800 { - compatible = "st,vtac-main"; - reg = <0xfee82800 0x200>; - clock-names = "vtac"; - clocks = <&clk_m_a2_div0 CLK_M_VTAC_MAIN_PHY>; - }; - - sti-vtac-rx-aux@fee82a00 { - compatible = "st,vtac-aux"; - reg = <0xfee82a00 0x200>; - clock-names = "vtac"; - clocks = <&clk_m_a2_div0 CLK_M_VTAC_AUX_PHY>; - }; - - sti-vtac-tx-main@fd349000 { - compatible = "st,vtac-main"; - reg = <0xfd349000 0x200>, <0xfd320000 0x10000>; - clock-names = "vtac"; - clocks = <&clk_s_a1_hs CLK_S_VTAC_TX_PHY>; - }; - - sti-vtac-tx-aux@fd349200 { - compatible = "st,vtac-aux"; - reg = <0xfd349200 0x200>, <0xfd320000 0x10000>; - clock-names = "vtac"; - clocks = <&clk_s_a1_hs CLK_S_VTAC_TX_PHY>; - }; - - sti-display-subsystem { - compatible = "st,sti-display-subsystem"; - ranges; - - sti-compositor@fd340000 { - compatible = "st,stih416-compositor"; - reg = <0xfd340000 0x1000>; - clock-names = "compo_main", "compo_aux", - "pix_main", "pix_aux"; - clocks = <&clk_m_a2_div1 CLK_M_COMPO_MAIN>, <&clk_m_a2_div1 CLK_M_COMPO_AUX>, - <&clockgen_c_vcc CLK_S_PIX_MAIN>, <&clockgen_c_vcc CLK_S_PIX_AUX>; - reset-names = "compo-main", "compo-aux"; - resets = <&softreset STIH416_COMPO_M_SOFTRESET>, <&softreset STIH416_COMPO_A_SOFTRESET>; - st,vtg = <&vtg_main>, <&vtg_aux>; - }; - - sti-tvout@fe000000 { - compatible = "st,stih416-tvout"; - reg = <0xfe000000 0x1000>, <0xfe85a000 0x400>, <0xfe830000 0x10000>; - reg-names = "tvout-reg", "hda-reg", "syscfg"; - reset-names = "tvout"; - resets = <&softreset STIH416_HDTVOUT_SOFTRESET>; - }; - - sti-hdmi@fe85c000 { - compatible = "st,stih416-hdmi"; - reg = <0xfe85c000 0x1000>, <0xfe830000 0x10000>; - reg-names = "hdmi-reg", "syscfg"; - interrupts = ; - interrupt-names = "irq"; - clock-names = "pix", "tmds", "phy", "audio"; - clocks = <&clockgen_c_vcc CLK_S_PIX_HDMI>, <&clockgen_c_vcc CLK_S_TMDS_HDMI>, <&clockgen_c_vcc CLK_S_HDMI_REJECT_PLL>, <&clockgen_b1 CLK_S_PCM_0>; - }; - - sti-hda@fe85a000 { - compatible = "st,stih416-hda"; - reg = <0xfe85a000 0x400>, <0xfe83085c 0x4>; - reg-names = "hda-reg", "video-dacs-ctrl"; - clock-names = "pix", "hddac"; - clocks = <&clockgen_c_vcc CLK_S_PIX_HD>, <&clockgen_c_vcc CLK_S_HDDAC>; - }; - - sti-dvo@8d00400 { - compatible = "st,stih407-dvo"; - reg = <0x8d00400 0x200>; - reg-names = "dvo-reg"; - clock-names = "dvo_pix", "dvo", - "main_parent", "aux_parent"; - clocks = <&clk_s_d2_flexgen CLK_PIX_DVO>, <&clk_s_d2_flexgen CLK_DVO>, - <&clk_s_d2_quadfs 0>, <&clk_s_d2_quadfs 1>; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_dvo>; - sti,panel = <&panel_dvo>; - }; - - sti-hqvdp@9c000000 { - compatible = "st,stih407-hqvdp"; - reg = <0x9C00000 0x100000>; - clock-names = "hqvdp", "pix_main"; - clocks = <&clk_s_c0_flexgen CLK_MAIN_DISP>, <&clk_s_d2_flexgen CLK_PIX_MAIN_DISP>; - reset-names = "hqvdp"; - resets = <&softreset STIH407_HDQVDP_SOFTRESET>; - st,vtg = <&vtg_main>; - }; - }; - ... -}; diff --git a/Documentation/devicetree/bindings/hid/hid-over-i2c.txt b/Documentation/devicetree/bindings/hid/hid-over-i2c.txt deleted file mode 100644 index 488edcb26..000000000 --- a/Documentation/devicetree/bindings/hid/hid-over-i2c.txt +++ /dev/null @@ -1,28 +0,0 @@ -* HID over I2C Device-Tree bindings - -HID over I2C provides support for various Human Interface Devices over the -I2C bus. These devices can be for example touchpads, keyboards, touch screens -or sensors. - -The specification has been written by Microsoft and is currently available here: -http://msdn.microsoft.com/en-us/library/windows/hardware/hh852380.aspx - -If this binding is used, the kernel module i2c-hid will handle the communication -with the device and the generic hid core layer will handle the protocol. - -Required properties: -- compatible: must be "hid-over-i2c" -- reg: i2c slave address -- hid-descr-addr: HID descriptor address -- interrupt-parent: the phandle for the interrupt controller -- interrupts: interrupt line - -Example: - - i2c-hid-dev@2c { - compatible = "hid-over-i2c"; - reg = <0x2c>; - hid-descr-addr = <0x0020>; - interrupt-parent = <&gpx3>; - interrupts = <3 2>; - }; diff --git a/Documentation/devicetree/bindings/hwmon/ina209.txt b/Documentation/devicetree/bindings/hwmon/ina209.txt deleted file mode 100644 index 9dd2bee80..000000000 --- a/Documentation/devicetree/bindings/hwmon/ina209.txt +++ /dev/null @@ -1,18 +0,0 @@ -ina209 properties - -Required properties: -- compatible: Must be "ti,ina209" -- reg: I2C address - -Optional properties: - -- shunt-resistor - Shunt resistor value in micro-Ohm - -Example: - -temp-sensor@4c { - compatible = "ti,ina209"; - reg = <0x4c>; - shunt-resistor = <5000>; -}; diff --git a/Documentation/devicetree/bindings/hwmon/ina2xx.txt b/Documentation/devicetree/bindings/hwmon/ina2xx.txt index a2ad85d7e..9bcd5e878 100644 --- a/Documentation/devicetree/bindings/hwmon/ina2xx.txt +++ b/Documentation/devicetree/bindings/hwmon/ina2xx.txt @@ -2,6 +2,7 @@ ina2xx properties Required properties: - compatible: Must be one of the following: + - "ti,ina209" for ina209 - "ti,ina219" for ina219 - "ti,ina220" for ina220 - "ti,ina226" for ina226 diff --git a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt index 610757ce4..c6d533202 100644 --- a/Documentation/devicetree/bindings/hwmon/pwm-fan.txt +++ b/Documentation/devicetree/bindings/hwmon/pwm-fan.txt @@ -3,10 +3,35 @@ Bindings for a fan connected to the PWM lines Required properties: - compatible : "pwm-fan" - pwms : the PWM that is used to control the PWM fan +- cooling-levels : PWM duty cycle values in a range from 0 to 255 + which correspond to thermal cooling states Example: - pwm-fan { + fan0: pwm-fan { compatible = "pwm-fan"; - status = "okay"; + cooling-min-state = <0>; + cooling-max-state = <3>; + #cooling-cells = <2>; pwms = <&pwm 0 10000 0>; + cooling-levels = <0 102 170 230>; }; + + thermal-zones { + cpu_thermal: cpu-thermal { + thermal-sensors = <&tmu 0>; + polling-delay-passive = <0>; + polling-delay = <0>; + trips { + cpu_alert1: cpu-alert1 { + temperature = <100000>; /* millicelsius */ + hysteresis = <2000>; /* millicelsius */ + type = "passive"; + }; + }; + cooling-maps { + map0 { + trip = <&cpu_alert1>; + cooling-device = <&fan0 0 1>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/hwrng/atmel-trng.txt b/Documentation/devicetree/bindings/hwrng/atmel-trng.txt deleted file mode 100644 index 4ac5aaa2d..000000000 --- a/Documentation/devicetree/bindings/hwrng/atmel-trng.txt +++ /dev/null @@ -1,16 +0,0 @@ -Atmel TRNG (True Random Number Generator) block - -Required properties: -- compatible : Should be "atmel,at91sam9g45-trng" -- reg : Offset and length of the register set of this block -- interrupts : the interrupt number for the TRNG block -- clocks: should contain the TRNG clk source - -Example: - -trng@fffcc000 { - compatible = "atmel,at91sam9g45-trng"; - reg = <0xfffcc000 0x4000>; - interrupts = <6 IRQ_TYPE_LEVEL_HIGH 0>; - clocks = <&trng_clk>; -}; diff --git a/Documentation/devicetree/bindings/hwrng/brcm,iproc-rng200.txt b/Documentation/devicetree/bindings/hwrng/brcm,iproc-rng200.txt deleted file mode 100644 index e25a45666..000000000 --- a/Documentation/devicetree/bindings/hwrng/brcm,iproc-rng200.txt +++ /dev/null @@ -1,12 +0,0 @@ -HWRNG support for the iproc-rng200 driver - -Required properties: -- compatible : "brcm,iproc-rng200" -- reg : base address and size of control register block - -Example: - -rng { - compatible = "brcm,iproc-rng200"; - reg = <0x18032000 0x28>; -}; diff --git a/Documentation/devicetree/bindings/hwrng/omap_rng.txt b/Documentation/devicetree/bindings/hwrng/omap_rng.txt deleted file mode 100644 index 6a62acd86..000000000 --- a/Documentation/devicetree/bindings/hwrng/omap_rng.txt +++ /dev/null @@ -1,22 +0,0 @@ -OMAP SoC HWRNG Module - -Required properties: - -- compatible : Should contain entries for this and backward compatible - RNG versions: - - "ti,omap2-rng" for OMAP2. - - "ti,omap4-rng" for OMAP4, OMAP5 and AM33XX. - Note that these two versions are incompatible. -- ti,hwmods: Name of the hwmod associated with the RNG module -- reg : Offset and length of the register set for the module -- interrupts : the interrupt number for the RNG module. - Only used for "ti,omap4-rng". - -Example: -/* AM335x */ -rng: rng@48310000 { - compatible = "ti,omap4-rng"; - ti,hwmods = "rng"; - reg = <0x48310000 0x2000>; - interrupts = <111>; -}; diff --git a/Documentation/devicetree/bindings/hwrng/timeriomem_rng.txt b/Documentation/devicetree/bindings/hwrng/timeriomem_rng.txt deleted file mode 100644 index 6616d1586..000000000 --- a/Documentation/devicetree/bindings/hwrng/timeriomem_rng.txt +++ /dev/null @@ -1,18 +0,0 @@ -HWRNG support for the timeriomem_rng driver - -Required properties: -- compatible : "timeriomem_rng" -- reg : base address to sample from -- period : wait time in microseconds to use between samples - -N.B. currently 'reg' must be four bytes wide and aligned - -Example: - -hwrng@44 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "timeriomem_rng"; - reg = <0x44 0x04>; - period = <1000000>; -}; diff --git a/Documentation/devicetree/bindings/i2c/i2c-davinci.txt b/Documentation/devicetree/bindings/i2c/i2c-davinci.txt index a4e1cbc81..5b123e0e4 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-davinci.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-davinci.txt @@ -1,10 +1,10 @@ -* Texas Instruments Davinci I2C +* Texas Instruments Davinci/Keystone I2C This file provides information, what the device node for the -davinci i2c interface contain. +davinci/keystone i2c interface contains. Required properties: -- compatible: "ti,davinci-i2c"; +- compatible: "ti,davinci-i2c" or "ti,keystone-i2c"; - reg : Offset and length of the register set for the device Recommended properties : diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx.txt b/Documentation/devicetree/bindings/i2c/i2c-imx.txt index ce4311d72..eab5836ba 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-imx.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-imx.txt @@ -14,6 +14,10 @@ Optional properties: The absence of the propoerty indicates the default frequency 100 kHz. - dmas: A list of two dma specifiers, one for each entry in dma-names. - dma-names: should contain "tx" and "rx". +- scl-gpios: specify the gpio related to SCL pin +- sda-gpios: specify the gpio related to SDA pin +- pinctrl: add extra pinctrl to configure i2c pins to gpio function for i2c + bus recovery, call it "gpio" state Examples: @@ -37,4 +41,9 @@ i2c0: i2c@40066000 { /* i2c0 on vf610 */ dmas = <&edma0 0 50>, <&edma0 0 51>; dma-names = "rx","tx"; + pinctrl-names = "default", "gpio"; + pinctrl-0 = <&pinctrl_i2c1>; + pinctrl-1 = <&pinctrl_i2c1_gpio>; + scl-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH>; + sda-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt index 16b3e07aa..ea406eb20 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt @@ -10,6 +10,7 @@ Required properties: "renesas,i2c-r8a7792" "renesas,i2c-r8a7793" "renesas,i2c-r8a7794" + "renesas,i2c-r8a7795" - reg: physical base address of the controller and length of memory mapped region. - interrupts: interrupt specifier. diff --git a/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt b/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt index 2bfc6e7ed..214f94c25 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt @@ -10,6 +10,7 @@ Required properties: - "renesas,iic-r8a7792" (R-Car V2H) - "renesas,iic-r8a7793" (R-Car M2-N) - "renesas,iic-r8a7794" (R-Car E2) + - "renesas,iic-r8a7795" (R-Car H3) - "renesas,iic-sh73a0" (SH-Mobile AG5) - reg : address start and address range size of device - interrupts : interrupt of device diff --git a/Documentation/devicetree/bindings/i2c/i2c-uniphier-f.txt b/Documentation/devicetree/bindings/i2c/i2c-uniphier-f.txt new file mode 100644 index 000000000..27fc6f8c7 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-uniphier-f.txt @@ -0,0 +1,25 @@ +UniPhier I2C controller (FIFO-builtin) + +Required properties: +- compatible: should be "socionext,uniphier-fi2c". +- #address-cells: should be 1. +- #size-cells: should be 0. +- reg: offset and length of the register set for the device. +- interrupts: a single interrupt specifier. +- clocks: phandle to the input clock. + +Optional properties: +- clock-frequency: desired I2C bus frequency in Hz. The maximum supported + value is 400000. Defaults to 100000 if not specified. + +Examples: + + i2c0: i2c@58780000 { + compatible = "socionext,uniphier-fi2c"; + reg = <0x58780000 0x80>; + #address-cells = <1>; + #size-cells = <0>; + interrupts = <0 41 4>; + clocks = <&i2c_clk>; + clock-frequency = <100000>; + }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-uniphier.txt b/Documentation/devicetree/bindings/i2c/i2c-uniphier.txt new file mode 100644 index 000000000..26f9d95b3 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-uniphier.txt @@ -0,0 +1,25 @@ +UniPhier I2C controller (FIFO-less) + +Required properties: +- compatible: should be "socionext,uniphier-i2c". +- #address-cells: should be 1. +- #size-cells: should be 0. +- reg: offset and length of the register set for the device. +- interrupts: a single interrupt specifier. +- clocks: phandle to the input clock. + +Optional properties: +- clock-frequency: desired I2C bus frequency in Hz. The maximum supported + value is 400000. Defaults to 100000 if not specified. + +Examples: + + i2c0: i2c@58400000 { + compatible = "socionext,uniphier-i2c"; + reg = <0x58400000 0x40>; + #address-cells = <1>; + #size-cells = <0>; + interrupts = <0 41 1>; + clocks = <&i2c_clk>; + clock-frequency = <100000>; + }; diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt index d77d412cb..c50cf13c8 100644 --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt @@ -54,7 +54,6 @@ epson,rx8581 I2C-BUS INTERFACE REAL TIME CLOCK MODULE fsl,mag3110 MAG3110: Xtrinsic High Accuracy, 3D Magnetometer fsl,mc13892 MC13892: Power Management Integrated Circuit (PMIC) for i.MX35/51 fsl,mma8450 MMA8450Q: Xtrinsic Low-power, 3-axis Xtrinsic Accelerometer -fsl,mma8452 MMA8452Q: 3-axis 12-bit / 8-bit Digital Accelerometer fsl,mpr121 MPR121: Proximity Capacitive Touch Sensor Controller fsl,sgtl5000 SGTL5000: Ultra Low-Power Audio Codec gmt,g751 G751: Digital Temperature Sensor and Thermal Watchdog with Two-Wire Interface @@ -80,6 +79,7 @@ oki,ml86v7667 OKI ML86V7667 video decoder ovti,ov5642 OV5642: Color CMOS QSXGA (5-megapixel) Image Sensor with OmniBSI and Embedded TrueFocus pericom,pt7c4338 Real-time Clock Module plx,pex8648 48-Lane, 12-Port PCI Express Gen 2 (5.0 GT/s) Switch +pulsedlight,lidar-lite-v2 Pulsedlight LIDAR range-finding sensor ramtron,24c64 i2c serial eeprom (24cxx) ricoh,r2025sd I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC ricoh,r2221tl I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC @@ -88,6 +88,7 @@ ricoh,rs5c372b I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC ricoh,rv5c386 I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC ricoh,rv5c387a I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC samsung,24ad0xd1 S524AD0XF1 (128K/256K-bit Serial EEPROM for Low Power) +sgx,vz89x SGX Sensortech VZ89X Sensors sii,s35390a 2-wire CMOS real-time clock skyworks,sky81452 Skyworks SKY81452: Six-Channel White LED Driver with Touch Panel Bias Supply st-micro,24c256 i2c serial eeprom (24cxx) diff --git a/Documentation/devicetree/bindings/iio/accel/lis302.txt b/Documentation/devicetree/bindings/iio/accel/lis302.txt new file mode 100644 index 000000000..2a19bff96 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/accel/lis302.txt @@ -0,0 +1,119 @@ +LIS302 accelerometer devicetree bindings + +This device is matched via its bus drivers, and has a number of properties +that apply in on the generic device (independent from the bus). + + +Required properties for the SPI bindings: + - compatible: should be set to "st,lis3lv02d_spi" + - reg: the chipselect index + - spi-max-frequency: maximal bus speed, should be set to 1000000 unless + constrained by external circuitry + - interrupts: the interrupt generated by the device + +Required properties for the I2C bindings: + - compatible: should be set to "st,lis3lv02d" + - reg: i2c slave address + - Vdd-supply: The input supply for Vdd + - Vdd_IO-supply: The input supply for Vdd_IO + + +Optional properties for all bus drivers: + + - st,click-single-{x,y,z}: if present, tells the device to issue an + interrupt on single click events on the + x/y/z axis. + - st,click-double-{x,y,z}: if present, tells the device to issue an + interrupt on double click events on the + x/y/z axis. + - st,click-thresh-{x,y,z}: set the x/y/z axis threshold + - st,click-click-time-limit: click time limit, from 0 to 127.5msec + with step of 0.5 msec + - st,click-latency: click latency, from 0 to 255 msec with + step of 1 msec. + - st,click-window: click window, from 0 to 255 msec with + step of 1 msec. + - st,irq{1,2}-disable: disable IRQ 1/2 + - st,irq{1,2}-ff-wu-1: raise IRQ 1/2 on FF_WU_1 condition + - st,irq{1,2}-ff-wu-2: raise IRQ 1/2 on FF_WU_2 condition + - st,irq{1,2}-data-ready: raise IRQ 1/2 on data ready contition + - st,irq{1,2}-click: raise IRQ 1/2 on click condition + - st,irq-open-drain: consider IRQ lines open-drain + - st,irq-active-low: make IRQ lines active low + - st,wu-duration-1: duration register for Free-Fall/Wake-Up + interrupt 1 + - st,wu-duration-2: duration register for Free-Fall/Wake-Up + interrupt 2 + - st,wakeup-{x,y,z}-{lo,hi}: set wakeup condition on x/y/z axis for + upper/lower limit + - st,wakeup-threshold: set wakeup threshold + - st,wakeup2-{x,y,z}-{lo,hi}: set wakeup condition on x/y/z axis for + upper/lower limit for second wakeup + engine. + - st,wakeup2-threshold: set wakeup threshold for second wakeup + engine. + - st,highpass-cutoff-hz=: 1, 2, 4 or 8 for 1Hz, 2Hz, 4Hz or 8Hz of + highpass cut-off frequency + - st,hipass{1,2}-disable: disable highpass 1/2. + - st,default-rate=: set the default rate + - st,axis-{x,y,z}=: set the axis to map to the three coordinates. + Negative values can be used for inverted axis. + - st,{min,max}-limit-{x,y,z} set the min/max limits for x/y/z axis + (used by self-test) + + +Example for a SPI device node: + + lis302@0 { + compatible = "st,lis302dl-spi"; + reg = <0>; + spi-max-frequency = <1000000>; + interrupt-parent = <&gpio>; + interrupts = <104 0>; + + st,click-single-x; + st,click-single-y; + st,click-single-z; + st,click-thresh-x = <10>; + st,click-thresh-y = <10>; + st,click-thresh-z = <10>; + st,irq1-click; + st,irq2-click; + st,wakeup-x-lo; + st,wakeup-x-hi; + st,wakeup-y-lo; + st,wakeup-y-hi; + st,wakeup-z-lo; + st,wakeup-z-hi; + }; + +Example for a I2C device node: + + lis331dlh: lis331dlh@18 { + compatible = "st,lis331dlh", "st,lis3lv02d"; + reg = <0x18>; + Vdd-supply = <&lis3_reg>; + Vdd_IO-supply = <&lis3_reg>; + + st,click-single-x; + st,click-single-y; + st,click-single-z; + st,click-thresh-x = <10>; + st,click-thresh-y = <10>; + st,click-thresh-z = <10>; + st,irq1-click; + st,irq2-click; + st,wakeup-x-lo; + st,wakeup-x-hi; + st,wakeup-y-lo; + st,wakeup-y-hi; + st,wakeup-z-lo; + st,wakeup-z-hi; + st,min-limit-x = <120>; + st,min-limit-y = <120>; + st,min-limit-z = <140>; + st,max-limit-x = <550>; + st,max-limit-y = <550>; + st,max-limit-z = <750>; + }; + diff --git a/Documentation/devicetree/bindings/iio/accel/mma8452.txt b/Documentation/devicetree/bindings/iio/accel/mma8452.txt new file mode 100644 index 000000000..e3c37467d --- /dev/null +++ b/Documentation/devicetree/bindings/iio/accel/mma8452.txt @@ -0,0 +1,24 @@ +Freescale MMA8452Q, MMA8453Q, MMA8652FC or MMA8653FC triaxial accelerometer + +Required properties: + + - compatible: should contain one of + * "fsl,mma8452" + * "fsl,mma8453" + * "fsl,mma8652" + * "fsl,mma8653" + - reg: the I2C address of the chip + +Optional properties: + + - interrupt-parent: should be the phandle for the interrupt controller + - interrupts: interrupt mapping for GPIO IRQ + +Example: + + mma8453fc@1d { + compatible = "fsl,mma8453"; + reg = <0x1d>; + interrupt-parent = <&gpio1>; + interrupts = <5 0>; + }; diff --git a/Documentation/devicetree/bindings/iio/adc/hi8435.txt b/Documentation/devicetree/bindings/iio/adc/hi8435.txt new file mode 100644 index 000000000..3b0348c5e --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/hi8435.txt @@ -0,0 +1,21 @@ +Holt Integrated Circuits HI-8435 threshold detector bindings + +Required properties: + - compatible: should be "holt,hi8435" + - reg: spi chip select number for the device + +Recommended properties: + - spi-max-frequency: definition as per + Documentation/devicetree/bindings/spi/spi-bus.txt + +Optional properties: + - gpios: GPIO used for controlling the reset pin + +Example: +sensor@0 { + compatible = "holt,hi8435"; + reg = <0>; + gpios = <&gpio6 1 0>; + + spi-max-frequency = <1000000>; +}; diff --git a/Documentation/devicetree/bindings/iio/dac/ti,dac7512.txt b/Documentation/devicetree/bindings/iio/dac/ti,dac7512.txt new file mode 100644 index 000000000..1db45939d --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/ti,dac7512.txt @@ -0,0 +1,20 @@ +TI DAC7512 DEVICETREE BINDINGS + +Required properties: + + - "compatible" Must be set to "ti,dac7512" + +Property rules described in Documentation/devicetree/bindings/spi/spi-bus.txt +apply. In particular, "reg" and "spi-max-frequency" properties must be given. + + +Example: + + spi_master { + dac7512: dac7512@0 { + compatible = "ti,dac7512"; + reg = <0>; /* CS0 */ + spi-max-frequency = <1000000>; + }; + }; + diff --git a/Documentation/devicetree/bindings/iio/light/apds9960.txt b/Documentation/devicetree/bindings/iio/light/apds9960.txt new file mode 100644 index 000000000..174b709f1 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/light/apds9960.txt @@ -0,0 +1,22 @@ +* Avago APDS9960 gesture/RGB/ALS/proximity sensor + +http://www.avagotech.com/docs/AV02-4191EN + +Required properties: + + - compatible: must be "avago,apds9960" + - reg: the I2c address of the sensor + - interrupt-parent: should be the phandle for the interrupt controller + - interrupts : the sole interrupt generated by the device + + Refer to interrupt-controller/interrupts.txt for generic interrupt client + node bindings. + +Example: + +apds9960@39 { + compatible = "avago,apds9960"; + reg = <0x39>; + interrupt-parent = <&gpio1>; + interrupts = <16 1>; +}; diff --git a/Documentation/devicetree/bindings/iio/light/us5182d.txt b/Documentation/devicetree/bindings/iio/light/us5182d.txt new file mode 100644 index 000000000..6f0a53014 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/light/us5182d.txt @@ -0,0 +1,34 @@ +* UPISEMI us5182d I2C ALS and Proximity sensor + +Required properties: +- compatible: must be "upisemi,usd5182" +- reg: the I2C address of the device + +Optional properties: +- upisemi,glass-coef: glass attenuation factor - compensation factor of + resolution 1000 for material transmittance. +- upisemi,dark-ths: array of 8 elements containing 16-bit thresholds (adc + counts) corresponding to every scale. +- upisemi,upper-dark-gain: 8-bit dark gain compensation factor(4 int and 4 + fractional bits - Q4.4) applied when light > threshold +- upisemi,lower-dark-gain: 8-bit dark gain compensation factor(4 int and 4 + fractional bits - Q4.4) applied when light < threshold + +If the optional properties are not specified these factors will default to the +values in the below example. +The glass-coef defaults to no compensation for the covering material. +The threshold array defaults to experimental values that work with US5182D +sensor on evaluation board - roughly between 12-32 lux. +There will be no dark-gain compensation by default when ALS > thresh +(0 * dark-gain), and a 1.35 compensation factor when ALS < thresh. + +Example: + + usd5182@39 { + compatible = "upisemi,usd5182"; + reg = <0x39>; + upisemi,glass-coef = < 1000 >; + upisemi,dark-ths = /bits/ 16 <170 200 512 512 800 2000 4000 8000>; + upisemi,upper-dark-gain = /bits/ 8 <0x00>; + upisemi,lower-dark-gain = /bits/ 8 <0x16>; + }; diff --git a/Documentation/devicetree/bindings/iio/pressure/bmp085.txt b/Documentation/devicetree/bindings/iio/pressure/bmp085.txt new file mode 100644 index 000000000..d7a6deb6b --- /dev/null +++ b/Documentation/devicetree/bindings/iio/pressure/bmp085.txt @@ -0,0 +1,24 @@ +BMP085/BMP18x digital pressure sensors + +Required properties: +- compatible: bosch,bmp085 + +Optional properties: +- chip-id: configurable chip id for non-default chip revisions +- temp-measurement-period: temperature measurement period (milliseconds) +- default-oversampling: default oversampling value to be used at startup, + value range is 0-3 with rising sensitivity. +- interrupt-parent: should be the phandle for the interrupt controller +- interrupts: interrupt mapping for IRQ + +Example: + +pressure@77 { + compatible = "bosch,bmp085"; + reg = <0x77>; + chip-id = <10>; + temp-measurement-period = <100>; + default-oversampling = <2>; + interrupt-parent = <&gpio0>; + interrupts = <25 IRQ_TYPE_EDGE_RISING>; +}; diff --git a/Documentation/devicetree/bindings/input/ads7846.txt b/Documentation/devicetree/bindings/input/ads7846.txt index df8b12794..33a1638b6 100644 --- a/Documentation/devicetree/bindings/input/ads7846.txt +++ b/Documentation/devicetree/bindings/input/ads7846.txt @@ -65,6 +65,7 @@ Optional properties: pendown-gpio GPIO handle describing the pin the !PENIRQ line is connected to. wakeup-source use any event on touchscreen as wakeup event. + (Legacy property support: "linux,wakeup") Example for a TSC2046 chip connected to an McSPI controller of an OMAP SoC:: @@ -86,6 +87,6 @@ Example for a TSC2046 chip connected to an McSPI controller of an OMAP SoC:: ti,x-plate-ohms = /bits/ 16 <40>; ti,pressure-max = /bits/ 16 <255>; - linux,wakeup; + wakeup-source; }; }; diff --git a/Documentation/devicetree/bindings/input/da9062-onkey.txt b/Documentation/devicetree/bindings/input/da9062-onkey.txt new file mode 100644 index 000000000..ab0e0488f --- /dev/null +++ b/Documentation/devicetree/bindings/input/da9062-onkey.txt @@ -0,0 +1,32 @@ +* Dialog DA9062/63 OnKey Module + +This module is part of the DA9062/DA9063. For more details about entire +chips see Documentation/devicetree/bindings/mfd/da9062.txt and +Documentation/devicetree/bindings/mfd/da9063.txt + +This module provides KEY_POWER, KEY_SLEEP and events. + +Required properties: + +- compatible: should be one of: + dlg,da9062-onkey + dlg,da9063-onkey + +Optional properties: + + - dlg,disable-key-power : Disable power-down using a long key-press. If this + entry exists the OnKey driver will remove support for the KEY_POWER key + press. If this entry does not exist then by default the key-press + triggered power down is enabled and the OnKey will support both KEY_POWER + and KEY_SLEEP. + +Example: + + pmic0: da9062@58 { + + onkey { + compatible = "dlg,da9063-onkey"; + dlg,disable-key-power; + }; + + }; diff --git a/Documentation/devicetree/bindings/input/gpio-keys-polled.txt b/Documentation/devicetree/bindings/input/gpio-keys-polled.txt index 5b91f5a3b..95d0fb11a 100644 --- a/Documentation/devicetree/bindings/input/gpio-keys-polled.txt +++ b/Documentation/devicetree/bindings/input/gpio-keys-polled.txt @@ -13,14 +13,22 @@ Subnode properties: - gpios: OF device-tree gpio specification. - label: Descriptive name of the key. - - linux,code: Keycode to emit. + - linux,code: Key / Axis code to emit. Optional subnode-properties: - linux,input-type: Specify event type this button/key generates. If not specified defaults to <1> == EV_KEY. + - linux,input-value: If linux,input-type is EV_ABS or EV_REL then this + value is sent for events this button generates when pressed. + EV_ABS/EV_REL axis will generate an event with a value of 0 when + all buttons with linux,input-type == type and linux,code == axis + are released. This value is interpreted as a signed 32 bit value, + e.g. to make a button generate a value of -1 use: + linux,input-value = <0xffffffff>; /* -1 */ - debounce-interval: Debouncing interval time in milliseconds. If not specified defaults to 5. - wakeup-source: Boolean, button can wake-up the system. + (Legacy property supported: "gpio-key,wakeup") Example nodes: diff --git a/Documentation/devicetree/bindings/input/gpio-keys.txt b/Documentation/devicetree/bindings/input/gpio-keys.txt index 072bf7573..cf1333d1d 100644 --- a/Documentation/devicetree/bindings/input/gpio-keys.txt +++ b/Documentation/devicetree/bindings/input/gpio-keys.txt @@ -24,6 +24,7 @@ Optional subnode-properties: - debounce-interval: Debouncing interval time in milliseconds. If not specified defaults to 5. - wakeup-source: Boolean, button can wake-up the system. + (Legacy property supported: "gpio-key,wakeup") - linux,can-disable: Boolean, indicates that button is connected to dedicated (not shared) interrupt which can be disabled to suppress events from the button. diff --git a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt index 4d86059c3..d0ea09ba2 100644 --- a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt +++ b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt @@ -20,6 +20,7 @@ Required Properties: Optional Properties: - linux,no-autorepeat: do no enable autorepeat feature. - wakeup-source: use any event on keypad as wakeup event. + (Legacy property supported: "linux,wakeup") - debounce-delay-ms: debounce interval in milliseconds - col-scan-delay-us: delay, measured in microseconds, that is needed before we can scan keypad after activating column gpio diff --git a/Documentation/devicetree/bindings/input/hid-over-i2c.txt b/Documentation/devicetree/bindings/input/hid-over-i2c.txt new file mode 100644 index 000000000..488edcb26 --- /dev/null +++ b/Documentation/devicetree/bindings/input/hid-over-i2c.txt @@ -0,0 +1,28 @@ +* HID over I2C Device-Tree bindings + +HID over I2C provides support for various Human Interface Devices over the +I2C bus. These devices can be for example touchpads, keyboards, touch screens +or sensors. + +The specification has been written by Microsoft and is currently available here: +http://msdn.microsoft.com/en-us/library/windows/hardware/hh852380.aspx + +If this binding is used, the kernel module i2c-hid will handle the communication +with the device and the generic hid core layer will handle the protocol. + +Required properties: +- compatible: must be "hid-over-i2c" +- reg: i2c slave address +- hid-descr-addr: HID descriptor address +- interrupt-parent: the phandle for the interrupt controller +- interrupts: interrupt line + +Example: + + i2c-hid-dev@2c { + compatible = "hid-over-i2c"; + reg = <0x2c>; + hid-descr-addr = <0x0020>; + interrupt-parent = <&gpx3>; + interrupts = <3 2>; + }; diff --git a/Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt b/Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt index 0382b8bd6..1faa7292e 100644 --- a/Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt +++ b/Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt @@ -29,7 +29,8 @@ matrix-keyboard bindings: - nvidia,debounce-delay-ms: delay in milliseconds per row scan for debouncing - nvidia,repeat-delay-ms: delay in milliseconds before repeat starts - nvidia,ghost-filter: enable ghost filtering for this device -- nvidia,wakeup-source: configure keyboard as a wakeup source for suspend/resume +- wakeup-source: configure keyboard as a wakeup source for suspend/resume + (Legacy property supported: "nvidia,wakeup-source") Example: diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt b/Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt index ee6215681..4a9dc6ba9 100644 --- a/Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt +++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt @@ -37,6 +37,7 @@ PROPERTIES Usage: optional Value type: Definition: use any event on keypad as wakeup event. + (Legacy property supported: "linux,keypad-wakeup") - keypad,num-rows: Usage: required diff --git a/Documentation/devicetree/bindings/input/rotary-encoder.txt b/Documentation/devicetree/bindings/input/rotary-encoder.txt index 331549593..de99cbbbf 100644 --- a/Documentation/devicetree/bindings/input/rotary-encoder.txt +++ b/Documentation/devicetree/bindings/input/rotary-encoder.txt @@ -14,7 +14,17 @@ Optional properties: device, hence no steps need to be passed. - rotary-encoder,rollover: Automatic rollove when the rotary value becomes greater than the specified steps or smaller than 0. For absolute axis only. +- rotary-encoder,steps-per-period: Number of steps (stable states) per period. + The values have the following meaning: + 1: Full-period mode (default) + 2: Half-period mode + 4: Quarter-period mode +- wakeup-source: Boolean, rotary encoder can wake up the system. + +Deprecated properties: - rotary-encoder,half-period: Makes the driver work on half-period mode. + This property is deprecated. Instead, a 'steps-per-period ' value should + be used, such as "rotary-encoder,steps-per-period = <2>". See Documentation/input/rotary-encoder.txt for more information. diff --git a/Documentation/devicetree/bindings/input/samsung-keypad.txt b/Documentation/devicetree/bindings/input/samsung-keypad.txt index 863e77f61..5305e74e5 100644 --- a/Documentation/devicetree/bindings/input/samsung-keypad.txt +++ b/Documentation/devicetree/bindings/input/samsung-keypad.txt @@ -38,6 +38,7 @@ Required Board Specific Properties: Optional Properties: - wakeup-source: use any event on keypad as wakeup event. + (Legacy property supported: "linux,input-wakeup") Optional Properties specific to linux: - linux,keypad-no-autorepeat: do no enable autorepeat feature. @@ -51,7 +52,7 @@ Example: samsung,keypad-num-rows = <2>; samsung,keypad-num-columns = <8>; linux,input-no-autorepeat; - linux,input-wakeup; + wakeup-source; pinctrl-names = "default"; pinctrl-0 = <&keypad_rows &keypad_columns>; diff --git a/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt b/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt index b9c32f6fd..4357e498e 100644 --- a/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt +++ b/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt @@ -12,7 +12,7 @@ Each key is represented as a sub-node of "allwinner,sun4i-a10-lradc-keys": Required subnode-properties: - label: Descriptive name of the key. - linux,code: Keycode to emit. - - channel: Channel this key is attached to, mut be 0 or 1. + - channel: Channel this key is attached to, must be 0 or 1. - voltage: Voltage in µV at lradc input when this key is pressed. Example: diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt index 76db96704..f99528da1 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt @@ -5,6 +5,7 @@ There are 3 variants of the chip for various touch panel sizes FT5206GE1 2.8" .. 3.8" FT5306DE4 4.3" .. 7" FT5406EE8 7" .. 8.9" +FT5506EEG 7" .. 8.9" The software interface is identical for all those chips, so that currently there is no need for the driver to distinguish between the @@ -17,6 +18,7 @@ Required properties: - compatible: "edt,edt-ft5206" or: "edt,edt-ft5306" or: "edt,edt-ft5406" + or: "edt,edt-ft5506" - reg: I2C slave address of the chip (0x38) - interrupt-parent: a phandle pointing to the interrupt controller @@ -49,7 +51,7 @@ Example: pinctrl-names = "default"; pinctrl-0 = <&edt_ft5x06_pins>; interrupt-parent = <&gpio2>; - interrupts = <5 0>; - reset-gpios = <&gpio2 6 1>; - wake-gpios = <&gpio4 9 0>; + interrupts = <5 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = <&gpio2 6 GPIO_ACTIVE_LOW>; + wake-gpios = <&gpio4 9 GPIO_ACTIVE_HIGH>; }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/focaltech-ft6236.txt b/Documentation/devicetree/bindings/input/touchscreen/focaltech-ft6236.txt new file mode 100644 index 000000000..777521da3 --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/focaltech-ft6236.txt @@ -0,0 +1,35 @@ +* FocalTech FT6236 I2C touchscreen controller + +Required properties: + - compatible : "focaltech,ft6236" + - reg : I2C slave address of the chip (0x38) + - interrupt-parent : a phandle pointing to the interrupt controller + serving the interrupt for this chip + - interrupts : interrupt specification for the touch controller + interrupt + - reset-gpios : GPIO specification for the RSTN input + - touchscreen-size-x : horizontal resolution of touchscreen (in pixels) + - touchscreen-size-y : vertical resolution of touchscreen (in pixels) + +Optional properties: + - touchscreen-fuzz-x : horizontal noise value of the absolute input + device (in pixels) + - touchscreen-fuzz-y : vertical noise value of the absolute input + device (in pixels) + - touchscreen-inverted-x : X axis is inverted (boolean) + - touchscreen-inverted-y : Y axis is inverted (boolean) + - touchscreen-swapped-x-y: X and Y axis are swapped (boolean) + Swapping is done after inverting the axis + +Example: + + ft6x06@38 { + compatible = "focaltech,ft6236"; + reg = <0x38>; + interrupt-parent = <&gpio>; + interrupts = <23 2>; + touchscreen-size-x = <320>; + touchscreen-size-y = <480>; + touchscreen-inverted-x; + touchscreen-swapped-x-y; + }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt index 8ba98eec7..c98757a69 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt @@ -13,6 +13,17 @@ Required properties: - interrupt-parent : Interrupt controller to which the chip is connected - interrupts : Interrupt to which the chip is connected +Optional properties: + + - irq-gpios : GPIO pin used for IRQ. The driver uses the + interrupt gpio pin as output to reset the device. + - reset-gpios : GPIO pin used for reset + + - touchscreen-inverted-x : X axis is inverted (boolean) + - touchscreen-inverted-y : Y axis is inverted (boolean) + - touchscreen-swapped-x-y : X and Y axis are swapped (boolean) + (swapping is done after inverting the axis) + Example: i2c@00000000 { @@ -23,6 +34,9 @@ Example: reg = <0x5d>; interrupt-parent = <&gpio>; interrupts = <0 0>; + + irq-gpios = <&gpio1 0 0>; + reset-gpios = <&gpio1 1 0>; }; /* ... */ diff --git a/Documentation/devicetree/bindings/input/touchscreen/pixcir_i2c_ts.txt b/Documentation/devicetree/bindings/input/touchscreen/pixcir_i2c_ts.txt index 8eb240a28..697a3e783 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/pixcir_i2c_ts.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/pixcir_i2c_ts.txt @@ -9,7 +9,9 @@ Required properties: - touchscreen-size-y: vertical resolution of touchscreen (in pixels) Optional properties: -- reset-gpio: GPIO connected to the RESET line of the chip +- reset-gpios: GPIO connected to the RESET line of the chip +- enable-gpios: GPIO connected to the ENABLE line of the chip +- wake-gpios: GPIO connected to the WAKE line of the chip Example: diff --git a/Documentation/devicetree/bindings/input/touchscreen/ts4800-ts.txt b/Documentation/devicetree/bindings/input/touchscreen/ts4800-ts.txt new file mode 100644 index 000000000..4c1c092c2 --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/ts4800-ts.txt @@ -0,0 +1,11 @@ +* TS-4800 Touchscreen bindings + +Required properties: +- compatible: must be "technologic,ts4800-ts" +- reg: physical base address of the controller and length of memory mapped + region. +- syscon: phandle / integers array that points to the syscon node which + describes the FPGA's syscon registers. + - phandle to FPGA's syscon + - offset to the touchscreen register + - offset to the touchscreen enable bit diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt index 09089a6d6..b80c04b0e 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt @@ -1,14 +1,15 @@ -* Texas Instruments tsc2005 touchscreen controller +* Texas Instruments tsc2004 and tsc2005 touchscreen controllers Required properties: - - compatible : "ti,tsc2005" - - reg : SPI device address - - spi-max-frequency : Maximal SPI speed + - compatible : "ti,tsc2004" or "ti,tsc2005" + - reg : Device address - interrupts : IRQ specifier - - reset-gpios : GPIO specifier - - vio-supply : Regulator specifier + - spi-max-frequency : Maximum SPI clocking speed of the device + (for tsc2005) Optional properties: + - vio-supply : Regulator specifier + - reset-gpios : GPIO specifier for the controller reset line - ti,x-plate-ohms : integer, resistance of the touchscreen's X plates in ohm (defaults to 280) - ti,esd-recovery-timeout-ms : integer, if the touchscreen does not respond after @@ -18,6 +19,27 @@ Optional properties: Example: +&i2c3 { + tsc2004@48 { + compatible = "ti,tsc2004"; + reg = <0x48>; + vio-supply = <&vio>; + + reset-gpios = <&gpio4 8 GPIO_ACTIVE_HIGH>; + interrupts-extended = <&gpio1 27 IRQ_TYPE_EDGE_RISING>; + + touchscreen-fuzz-x = <4>; + touchscreen-fuzz-y = <7>; + touchscreen-fuzz-pressure = <2>; + touchscreen-size-x = <4096>; + touchscreen-size-y = <4096>; + touchscreen-max-pressure = <2048>; + + ti,x-plate-ohms = <280>; + ti,esd-recovery-timeout-ms = <8000>; + }; +} + &mcspi1 { tsc2005@0 { compatible = "ti,tsc2005"; diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt new file mode 100644 index 000000000..7803e77d8 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.txt @@ -0,0 +1,123 @@ +* ARM Generic Interrupt Controller, version 3 + +AArch64 SMP cores are often associated with a GICv3, providing Private +Peripheral Interrupts (PPI), Shared Peripheral Interrupts (SPI), +Software Generated Interrupts (SGI), and Locality-specific Peripheral +Interrupts (LPI). + +Main node required properties: + +- compatible : should at least contain "arm,gic-v3". +- interrupt-controller : Identifies the node as an interrupt controller +- #interrupt-cells : Specifies the number of cells needed to encode an + interrupt source. Must be a single cell with a value of at least 3. + + The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI + interrupts. Other values are reserved for future use. + + The 2nd cell contains the interrupt number for the interrupt type. + SPI interrupts are in the range [0-987]. PPI interrupts are in the + range [0-15]. + + The 3rd cell is the flags, encoded as follows: + bits[3:0] trigger type and level flags. + 1 = edge triggered + 4 = level triggered + + Cells 4 and beyond are reserved for future use. When the 1st cell + has a value of 0 or 1, cells 4 and beyond act as padding, and may be + ignored. It is recommended that padding cells have a value of 0. + +- reg : Specifies base physical address(s) and size of the GIC + registers, in the following order: + - GIC Distributor interface (GICD) + - GIC Redistributors (GICR), one range per redistributor region + - GIC CPU interface (GICC) + - GIC Hypervisor interface (GICH) + - GIC Virtual CPU interface (GICV) + + GICC, GICH and GICV are optional. + +- interrupts : Interrupt source of the VGIC maintenance interrupt. + +Optional + +- redistributor-stride : If using padding pages, specifies the stride + of consecutive redistributors. Must be a multiple of 64kB. + +- #redistributor-regions: The number of independent contiguous regions + occupied by the redistributors. Required if more than one such + region is present. + +Sub-nodes: + +GICv3 has one or more Interrupt Translation Services (ITS) that are +used to route Message Signalled Interrupts (MSI) to the CPUs. + +These nodes must have the following properties: +- compatible : Should at least contain "arm,gic-v3-its". +- msi-controller : Boolean property. Identifies the node as an MSI controller +- #msi-cells: Must be <1>. The single msi-cell is the DeviceID of the device + which will generate the MSI. +- reg: Specifies the base physical address and size of the ITS + registers. + +The main GIC node must contain the appropriate #address-cells, +#size-cells and ranges properties for the reg property of all ITS +nodes. + +Examples: + + gic: interrupt-controller@2cf00000 { + compatible = "arm,gic-v3"; + #interrupt-cells = <3>; + #address-cells = <2>; + #size-cells = <2>; + ranges; + interrupt-controller; + reg = <0x0 0x2f000000 0 0x10000>, // GICD + <0x0 0x2f100000 0 0x200000>, // GICR + <0x0 0x2c000000 0 0x2000>, // GICC + <0x0 0x2c010000 0 0x2000>, // GICH + <0x0 0x2c020000 0 0x2000>; // GICV + interrupts = <1 9 4>; + + gic-its@2c200000 { + compatible = "arm,gic-v3-its"; + msi-controller; + #msi-cells = <1>; + reg = <0x0 0x2c200000 0 0x200000>; + }; + }; + + gic: interrupt-controller@2c010000 { + compatible = "arm,gic-v3"; + #interrupt-cells = <3>; + #address-cells = <2>; + #size-cells = <2>; + ranges; + interrupt-controller; + redistributor-stride = <0x0 0x40000>; // 256kB stride + #redistributor-regions = <2>; + reg = <0x0 0x2c010000 0 0x10000>, // GICD + <0x0 0x2d000000 0 0x800000>, // GICR 1: CPUs 0-31 + <0x0 0x2e000000 0 0x800000>; // GICR 2: CPUs 32-63 + <0x0 0x2c040000 0 0x2000>, // GICC + <0x0 0x2c060000 0 0x2000>, // GICH + <0x0 0x2c080000 0 0x2000>; // GICV + interrupts = <1 9 4>; + + gic-its@2c200000 { + compatible = "arm,gic-v3-its"; + msi-controller; + #msi-cells = <1>; + reg = <0x0 0x2c200000 0 0x200000>; + }; + + gic-its@2c400000 { + compatible = "arm,gic-v3-its"; + msi-controller; + #msi-cells = <1>; + reg = <0x0 0x2c400000 0 0x200000>; + }; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt new file mode 100644 index 000000000..cc56021eb --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.txt @@ -0,0 +1,168 @@ +* ARM Generic Interrupt Controller + +ARM SMP cores are often associated with a GIC, providing per processor +interrupts (PPI), shared processor interrupts (SPI) and software +generated interrupts (SGI). + +Primary GIC is attached directly to the CPU and typically has PPIs and SGIs. +Secondary GICs are cascaded into the upward interrupt controller and do not +have PPIs or SGIs. + +Main node required properties: + +- compatible : should be one of: + "arm,arm1176jzf-devchip-gic" + "arm,arm11mp-gic" + "arm,cortex-a15-gic" + "arm,cortex-a7-gic" + "arm,cortex-a9-gic" + "arm,gic-400" + "arm,pl390" + "brcm,brahma-b15-gic" + "qcom,msm-8660-qgic" + "qcom,msm-qgic2" +- interrupt-controller : Identifies the node as an interrupt controller +- #interrupt-cells : Specifies the number of cells needed to encode an + interrupt source. The type shall be a and the value shall be 3. + + The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI + interrupts. + + The 2nd cell contains the interrupt number for the interrupt type. + SPI interrupts are in the range [0-987]. PPI interrupts are in the + range [0-15]. + + The 3rd cell is the flags, encoded as follows: + bits[3:0] trigger type and level flags. + 1 = low-to-high edge triggered + 2 = high-to-low edge triggered (invalid for SPIs) + 4 = active high level-sensitive + 8 = active low level-sensitive (invalid for SPIs). + bits[15:8] PPI interrupt cpu mask. Each bit corresponds to each of + the 8 possible cpus attached to the GIC. A bit set to '1' indicated + the interrupt is wired to that CPU. Only valid for PPI interrupts. + Also note that the configurability of PPI interrupts is IMPLEMENTATION + DEFINED and as such not guaranteed to be present (most SoC available + in 2014 seem to ignore the setting of this flag and use the hardware + default value). + +- reg : Specifies base physical address(s) and size of the GIC registers. The + first region is the GIC distributor register base and size. The 2nd region is + the GIC cpu interface register base and size. + +Optional +- interrupts : Interrupt source of the parent interrupt controller on + secondary GICs, or VGIC maintenance interrupt on primary GIC (see + below). + +- cpu-offset : per-cpu offset within the distributor and cpu interface + regions, used when the GIC doesn't have banked registers. The offset is + cpu-offset * cpu-nr. + +- clocks : List of phandle and clock-specific pairs, one for each entry + in clock-names. +- clock-names : List of names for the GIC clock input(s). Valid clock names + depend on the GIC variant: + "ic_clk" (for "arm,arm11mp-gic") + "PERIPHCLKEN" (for "arm,cortex-a15-gic") + "PERIPHCLK", "PERIPHCLKEN" (for "arm,cortex-a9-gic") + "clk" (for "arm,gic-400") + "gclk" (for "arm,pl390") + +- power-domains : A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle, used when the GIC + is part of a Power or Clock Domain. + + +Example: + + intc: interrupt-controller@fff11000 { + compatible = "arm,cortex-a9-gic"; + #interrupt-cells = <3>; + #address-cells = <1>; + interrupt-controller; + reg = <0xfff11000 0x1000>, + <0xfff10100 0x100>; + }; + + +* GIC virtualization extensions (VGIC) + +For ARM cores that support the virtualization extensions, additional +properties must be described (they only exist if the GIC is the +primary interrupt controller). + +Required properties: + +- reg : Additional regions specifying the base physical address and + size of the VGIC registers. The first additional region is the GIC + virtual interface control register base and size. The 2nd additional + region is the GIC virtual cpu interface register base and size. + +- interrupts : VGIC maintenance interrupt. + +Example: + + interrupt-controller@2c001000 { + compatible = "arm,cortex-a15-gic"; + #interrupt-cells = <3>; + interrupt-controller; + reg = <0x2c001000 0x1000>, + <0x2c002000 0x1000>, + <0x2c004000 0x2000>, + <0x2c006000 0x2000>; + interrupts = <1 9 0xf04>; + }; + + +* GICv2m extension for MSI/MSI-x support (Optional) + +Certain revisions of GIC-400 supports MSI/MSI-x via V2M register frame(s). +This is enabled by specifying v2m sub-node(s). + +Required properties: + +- compatible : The value here should contain "arm,gic-v2m-frame". + +- msi-controller : Identifies the node as an MSI controller. + +- reg : GICv2m MSI interface register base and size + +Optional properties: + +- arm,msi-base-spi : When the MSI_TYPER register contains an incorrect + value, this property should contain the SPI base of + the MSI frame, overriding the HW value. + +- arm,msi-num-spis : When the MSI_TYPER register contains an incorrect + value, this property should contain the number of + SPIs assigned to the frame, overriding the HW value. + +Example: + + interrupt-controller@e1101000 { + compatible = "arm,gic-400"; + #interrupt-cells = <3>; + #address-cells = <2>; + #size-cells = <2>; + interrupt-controller; + interrupts = <1 8 0xf04>; + ranges = <0 0 0 0xe1100000 0 0x100000>; + reg = <0x0 0xe1110000 0 0x01000>, + <0x0 0xe112f000 0 0x02000>, + <0x0 0xe1140000 0 0x10000>, + <0x0 0xe1160000 0 0x10000>; + v2m0: v2m@0x8000 { + compatible = "arm,gic-v2m-frame"; + msi-controller; + reg = <0x0 0x80000 0 0x1000>; + }; + + .... + + v2mN: v2m@0x9000 { + compatible = "arm,gic-v2m-frame"; + msi-controller; + reg = <0x0 0x90000 0 0x1000>; + }; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,versatile-fpga-irq.txt b/Documentation/devicetree/bindings/interrupt-controller/arm,versatile-fpga-irq.txt new file mode 100644 index 000000000..c9cf605bb --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,versatile-fpga-irq.txt @@ -0,0 +1,36 @@ +* ARM Versatile FPGA interrupt controller + +One or more FPGA IRQ controllers can be synthesized in an ARM reference board +such as the Integrator or Versatile family. The output of these different +controllers are OR:ed together and fed to the CPU tile's IRQ input. Each +instance can handle up to 32 interrupts. + +Required properties: +- compatible: "arm,versatile-fpga-irq" +- interrupt-controller: Identifies the node as an interrupt controller +- #interrupt-cells: The number of cells to define the interrupts. Must be 1 + as the FPGA IRQ controller has no configuration options for interrupt + sources. The cell is a u32 and defines the interrupt number. +- reg: The register bank for the FPGA interrupt controller. +- clear-mask: a u32 number representing the mask written to clear all IRQs + on the controller at boot for example. +- valid-mask: a u32 number representing a bit mask determining which of + the interrupts are valid. Unconnected/unused lines are set to 0, and + the system till not make it possible for devices to request these + interrupts. + +Example: + +pic: pic@14000000 { + compatible = "arm,versatile-fpga-irq"; + #interrupt-cells = <1>; + interrupt-controller; + reg = <0x14000000 0x100>; + clear-mask = <0xffffffff>; + valid-mask = <0x003fffff>; +}; + +Optional properties: +- interrupts: if the FPGA IRQ controller is cascaded, i.e. if its IRQ + output is simply connected to the input of another IRQ controller, + then the parent IRQ shall be specified in this property. diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,vic.txt b/Documentation/devicetree/bindings/interrupt-controller/arm,vic.txt new file mode 100644 index 000000000..dd527216c --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,vic.txt @@ -0,0 +1,41 @@ +* ARM Vectored Interrupt Controller + +One or more Vectored Interrupt Controllers (VIC's) can be connected in an ARM +system for interrupt routing. For multiple controllers they can either be +nested or have the outputs wire-OR'd together. + +Required properties: + +- compatible : should be one of + "arm,pl190-vic" + "arm,pl192-vic" +- interrupt-controller : Identifies the node as an interrupt controller +- #interrupt-cells : The number of cells to define the interrupts. Must be 1 as + the VIC has no configuration options for interrupt sources. The cell is a u32 + and defines the interrupt number. +- reg : The register bank for the VIC. + +Optional properties: + +- interrupts : Interrupt source for parent controllers if the VIC is nested. +- valid-mask : A one cell big bit mask of valid interrupt sources. Each bit + represents single interrupt source, starting from source 0 at LSb and ending + at source 31 at MSb. A bit that is set means that the source is wired and + clear means otherwise. If unspecified, defaults to all valid. +- valid-wakeup-mask : A one cell big bit mask of interrupt sources that can be + configured as wake up source for the system. Order of bits is the same as for + valid-mask property. A set bit means that this interrupt source can be + configured as a wake up source for the system. If unspecied, defaults to all + interrupt sources configurable as wake up sources. + +Example: + + vic0: interrupt-controller@60000 { + compatible = "arm,pl192-vic"; + interrupt-controller; + #interrupt-cells = <1>; + reg = <0x60000 0x1000>; + + valid-mask = <0xffffff7f>; + valid-wakeup-mask = <0x0000ff7f>; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/axis,crisv32-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/axis,crisv32-intc.txt new file mode 100644 index 000000000..e8b123b0a --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/axis,crisv32-intc.txt @@ -0,0 +1,23 @@ +* CRISv32 Interrupt Controller + +Interrupt controller for the CRISv32 SoCs. + +Main node required properties: + +- compatible : should be: + "axis,crisv32-intc" +- interrupt-controller : Identifies the node as an interrupt controller +- #interrupt-cells : Specifies the number of cells needed to encode an + interrupt source. The type shall be a and the value shall be 1. +- reg: physical base address and size of the intc registers map. + +Example: + + intc: interrupt-controller { + compatible = "axis,crisv32-intc"; + reg = <0xb001c000 0x1000>; + interrupt-controller; + #interrupt-cells = <1>; + }; + + diff --git a/Documentation/devicetree/bindings/interrupt-controller/img,meta-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/img,meta-intc.txt new file mode 100644 index 000000000..80994adab --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/img,meta-intc.txt @@ -0,0 +1,82 @@ +* Meta External Trigger Controller Binding + +This binding specifies what properties must be available in the device tree +representation of a Meta external trigger controller. + +Required properties: + + - compatible: Specifies the compatibility list for the interrupt controller. + The type shall be and the value shall include "img,meta-intc". + + - num-banks: Specifies the number of interrupt banks (each of which can + handle 32 interrupt sources). + + - interrupt-controller: The presence of this property identifies the node + as an interrupt controller. No property value shall be defined. + + - #interrupt-cells: Specifies the number of cells needed to encode an + interrupt source. The type shall be a and the value shall be 2. + + - #address-cells: Specifies the number of cells needed to encode an + address. The type shall be and the value shall be 0. As such, + 'interrupt-map' nodes do not have to specify a parent unit address. + +Optional properties: + + - no-mask: The controller doesn't have any mask registers. + +* Interrupt Specifier Definition + + Interrupt specifiers consists of 2 cells encoded as follows: + + - <1st-cell>: The interrupt-number that identifies the interrupt source. + + - <2nd-cell>: The Linux interrupt flags containing level-sense information, + encoded as follows: + 1 = edge triggered + 4 = level-sensitive + +* Examples + +Example 1: + + /* + * Meta external trigger block + */ + intc: intc { + // This is an interrupt controller node. + interrupt-controller; + + // No address cells so that 'interrupt-map' nodes which + // reference this interrupt controller node do not need a parent + // address specifier. + #address-cells = <0>; + + // Two cells to encode interrupt sources. + #interrupt-cells = <2>; + + // Number of interrupt banks + num-banks = <2>; + + // No HWMASKEXT is available (specify on Chorus2 and Comet ES1) + no-mask; + + // Compatible with Meta hardware trigger block. + compatible = "img,meta-intc"; + }; + +Example 2: + + /* + * An interrupt generating device that is wired to a Meta external + * trigger block. + */ + uart1: uart@0x02004c00 { + // Interrupt source '5' that is level-sensitive. + // Note that there are only two cells as specified in the + // interrupt parent's '#interrupt-cells' property. + interrupts = <5 4 /* level */>; + + // The interrupt controller that this device is wired to. + interrupt-parent = <&intc>; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/img,pdc-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/img,pdc-intc.txt new file mode 100644 index 000000000..a69118550 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/img,pdc-intc.txt @@ -0,0 +1,105 @@ +* ImgTec Powerdown Controller (PDC) Interrupt Controller Binding + +This binding specifies what properties must be available in the device tree +representation of a PDC IRQ controller. This has a number of input interrupt +lines which can wake the system, and are passed on through output interrupt +lines. + +Required properties: + + - compatible: Specifies the compatibility list for the interrupt controller. + The type shall be and the value shall include "img,pdc-intc". + + - reg: Specifies the base PDC physical address(s) and size(s) of the + addressable register space. The type shall be . + + - interrupt-controller: The presence of this property identifies the node + as an interrupt controller. No property value shall be defined. + + - #interrupt-cells: Specifies the number of cells needed to encode an + interrupt source. The type shall be a and the value shall be 2. + + - num-perips: Number of waking peripherals. + + - num-syswakes: Number of SysWake inputs. + + - interrupts: List of interrupt specifiers. The first specifier shall be the + shared SysWake interrupt, and remaining specifies shall be PDC peripheral + interrupts in order. + +* Interrupt Specifier Definition + + Interrupt specifiers consists of 2 cells encoded as follows: + + - <1st-cell>: The interrupt-number that identifies the interrupt source. + 0-7: Peripheral interrupts + 8-15: SysWake interrupts + + - <2nd-cell>: The level-sense information, encoded using the Linux interrupt + flags as follows (only 4 valid for peripheral interrupts): + 0 = none (decided by software) + 1 = low-to-high edge triggered + 2 = high-to-low edge triggered + 3 = both edge triggered + 4 = active-high level-sensitive (required for perip irqs) + 8 = active-low level-sensitive + +* Examples + +Example 1: + + /* + * TZ1090 PDC block + */ + pdc: pdc@0x02006000 { + // This is an interrupt controller node. + interrupt-controller; + + // Three cells to encode interrupt sources. + #interrupt-cells = <2>; + + // Offset address of 0x02006000 and size of 0x1000. + reg = <0x02006000 0x1000>; + + // Compatible with Meta hardware trigger block. + compatible = "img,pdc-intc"; + + // Three peripherals are connected. + num-perips = <3>; + + // Four SysWakes are connected. + num-syswakes = <4>; + + interrupts = <18 4 /* level */>, /* Syswakes */ + <30 4 /* level */>, /* Peripheral 0 (RTC) */ + <29 4 /* level */>, /* Peripheral 1 (IR) */ + <31 4 /* level */>; /* Peripheral 2 (WDT) */ + }; + +Example 2: + + /* + * An SoC peripheral that is wired through the PDC. + */ + rtc0 { + // The interrupt controller that this device is wired to. + interrupt-parent = <&pdc>; + + // Interrupt source Peripheral 0 + interrupts = <0 /* Peripheral 0 (RTC) */ + 4> /* IRQ_TYPE_LEVEL_HIGH */ + }; + +Example 3: + + /* + * An interrupt generating device that is wired to a SysWake pin. + */ + touchscreen0 { + // The interrupt controller that this device is wired to. + interrupt-parent = <&pdc>; + + // Interrupt source SysWake 0 that is active-low level-sensitive + interrupts = <8 /* SysWake0 */ + 8 /* IRQ_TYPE_LEVEL_LOW */>; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/intel,ce4100-ioapic.txt b/Documentation/devicetree/bindings/interrupt-controller/intel,ce4100-ioapic.txt new file mode 100644 index 000000000..7d19f494f --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/intel,ce4100-ioapic.txt @@ -0,0 +1,26 @@ +Interrupt chips +--------------- + +* Intel I/O Advanced Programmable Interrupt Controller (IO APIC) + + Required properties: + -------------------- + compatible = "intel,ce4100-ioapic"; + #interrupt-cells = <2>; + + Device's interrupt property: + + interrupts =

; + + The first number (P) represents the interrupt pin which is wired to the + IO APIC. The second number (S) represents the sense of interrupt which + should be configured and can be one of: + 0 - Edge Rising + 1 - Level Low + 2 - Level High + 3 - Edge Falling + +* Local APIC + Required property: + + compatible = "intel,ce4100-lapic"; diff --git a/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt new file mode 100644 index 000000000..afef6a85a --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/mediatek,sysirq.txt @@ -0,0 +1,32 @@ ++Mediatek 65xx/67xx/81xx sysirq + +Mediatek SOCs sysirq support controllable irq inverter for each GIC SPI +interrupt. + +Required properties: +- compatible: should be one of: + "mediatek,mt8173-sysirq" + "mediatek,mt8135-sysirq" + "mediatek,mt8127-sysirq" + "mediatek,mt6795-sysirq" + "mediatek,mt6592-sysirq" + "mediatek,mt6589-sysirq" + "mediatek,mt6582-sysirq" + "mediatek,mt6580-sysirq" + "mediatek,mt6577-sysirq" +- interrupt-controller : Identifies the node as an interrupt controller +- #interrupt-cells : Use the same format as specified by GIC in + Documentation/devicetree/bindings/arm/gic.txt +- interrupt-parent: phandle of irq parent for sysirq. The parent must + use the same interrupt-cells format as GIC. +- reg: Physical base address of the intpol registers and length of memory + mapped region. + +Example: + sysirq: interrupt-controller@10200100 { + compatible = "mediatek,mt6589-sysirq", "mediatek,mt6577-sysirq"; + interrupt-controller; + #interrupt-cells = <3>; + interrupt-parent = <&gic>; + reg = <0 0x10200100 0 0x1c>; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.txt b/Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.txt new file mode 100644 index 000000000..8b53273cb --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/mrvl,intc.txt @@ -0,0 +1,60 @@ +* Marvell MMP Interrupt controller + +Required properties: +- compatible : Should be "mrvl,mmp-intc", "mrvl,mmp2-intc" or + "mrvl,mmp2-mux-intc" +- reg : Address and length of the register set of the interrupt controller. + If the interrupt controller is intc, address and length means the range + of the whold interrupt controller. If the interrupt controller is mux-intc, + address and length means one register. Since address of mux-intc is in the + range of intc. mux-intc is secondary interrupt controller. +- reg-names : Name of the register set of the interrupt controller. It's + only required in mux-intc interrupt controller. +- interrupts : Should be the port interrupt shared by mux interrupts. It's + only required in mux-intc interrupt controller. +- interrupt-controller : Identifies the node as an interrupt controller. +- #interrupt-cells : Specifies the number of cells needed to encode an + interrupt source. +- mrvl,intc-nr-irqs : Specifies the number of interrupts in the interrupt + controller. +- mrvl,clr-mfp-irq : Specifies the interrupt that needs to clear MFP edge + detection first. + +Example: + intc: interrupt-controller@d4282000 { + compatible = "mrvl,mmp2-intc"; + interrupt-controller; + #interrupt-cells = <1>; + reg = <0xd4282000 0x1000>; + mrvl,intc-nr-irqs = <64>; + }; + + intcmux4@d4282150 { + compatible = "mrvl,mmp2-mux-intc"; + interrupts = <4>; + interrupt-controller; + #interrupt-cells = <1>; + reg = <0x150 0x4>, <0x168 0x4>; + reg-names = "mux status", "mux mask"; + mrvl,intc-nr-irqs = <2>; + }; + +* Marvell Orion Interrupt controller + +Required properties +- compatible : Should be "marvell,orion-intc". +- #interrupt-cells: Specifies the number of cells needed to encode an + interrupt source. Supported value is <1>. +- interrupt-controller : Declare this node to be an interrupt controller. +- reg : Interrupt mask address. A list of 4 byte ranges, one per controller. + One entry in the list represents 32 interrupts. + +Example: + + intc: interrupt-controller { + compatible = "marvell,orion-intc", "marvell,intc"; + interrupt-controller; + #interrupt-cells = <1>; + reg = <0xfed20204 0x04>, + <0xfed20214 0x04>; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/nxp,lpc3220-mic.txt b/Documentation/devicetree/bindings/interrupt-controller/nxp,lpc3220-mic.txt new file mode 100644 index 000000000..539adca19 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/nxp,lpc3220-mic.txt @@ -0,0 +1,38 @@ +* NXP LPC32xx Main Interrupt Controller + (MIC, including SIC1 and SIC2 secondary controllers) + +Required properties: +- compatible: Should be "nxp,lpc3220-mic" +- interrupt-controller: Identifies the node as an interrupt controller. +- interrupt-parent: Empty for the interrupt controller itself +- #interrupt-cells: The number of cells to define the interrupts. Should be 2. + The first cell is the IRQ number + The second cell is used to specify mode: + 1 = low-to-high edge triggered + 2 = high-to-low edge triggered + 4 = active high level-sensitive + 8 = active low level-sensitive + Default for internal sources should be set to 4 (active high). +- reg: Should contain MIC registers location and length + +Examples: + /* + * MIC + */ + mic: interrupt-controller@40008000 { + compatible = "nxp,lpc3220-mic"; + interrupt-controller; + interrupt-parent; + #interrupt-cells = <2>; + reg = <0x40008000 0xC000>; + }; + + /* + * ADC + */ + adc@40048000 { + compatible = "nxp,lpc3220-adc"; + reg = <0x40048000 0x1000>; + interrupt-parent = <&mic>; + interrupts = <39 4>; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/open-pic.txt b/Documentation/devicetree/bindings/interrupt-controller/open-pic.txt new file mode 100644 index 000000000..909a902df --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/open-pic.txt @@ -0,0 +1,98 @@ +* Open PIC Binding + +This binding specifies what properties must be available in the device tree +representation of an Open PIC compliant interrupt controller. This binding is +based on the binding defined for Open PIC in [1] and is a superset of that +binding. + +Required properties: + + NOTE: Many of these descriptions were paraphrased here from [1] to aid + readability. + + - compatible: Specifies the compatibility list for the PIC. The type + shall be and the value shall include "open-pic". + + - reg: Specifies the base physical address(s) and size(s) of this + PIC's addressable register space. The type shall be . + + - interrupt-controller: The presence of this property identifies the node + as an Open PIC. No property value shall be defined. + + - #interrupt-cells: Specifies the number of cells needed to encode an + interrupt source. The type shall be a and the value shall be 2. + + - #address-cells: Specifies the number of cells needed to encode an + address. The type shall be and the value shall be 0. As such, + 'interrupt-map' nodes do not have to specify a parent unit address. + +Optional properties: + + - pic-no-reset: The presence of this property indicates that the PIC + shall not be reset during runtime initialization. No property value shall + be defined. The presence of this property also mandates that any + initialization related to interrupt sources shall be limited to sources + explicitly referenced in the device tree. + +* Interrupt Specifier Definition + + Interrupt specifiers consists of 2 cells encoded as + follows: + + - <1st-cell>: The interrupt-number that identifies the interrupt source. + + - <2nd-cell>: The level-sense information, encoded as follows: + 0 = low-to-high edge triggered + 1 = active low level-sensitive + 2 = active high level-sensitive + 3 = high-to-low edge triggered + +* Examples + +Example 1: + + /* + * An Open PIC interrupt controller + */ + mpic: pic@40000 { + // This is an interrupt controller node. + interrupt-controller; + + // No address cells so that 'interrupt-map' nodes which reference + // this Open PIC node do not need a parent address specifier. + #address-cells = <0>; + + // Two cells to encode interrupt sources. + #interrupt-cells = <2>; + + // Offset address of 0x40000 and size of 0x40000. + reg = <0x40000 0x40000>; + + // Compatible with Open PIC. + compatible = "open-pic"; + + // The PIC shall not be reset. + pic-no-reset; + }; + +Example 2: + + /* + * An interrupt generating device that is wired to an Open PIC. + */ + serial0: serial@4500 { + // Interrupt source '42' that is active high level-sensitive. + // Note that there are only two cells as specified in the interrupt + // parent's '#interrupt-cells' property. + interrupts = <42 2>; + + // The interrupt controller that this device is wired to. + interrupt-parent = <&mpic>; + }; + +* References + +[1] Power.org (TM) Standard for Embedded Power Architecture (TM) Platform + Requirements (ePAPR), Version 1.0, July 2008. + (http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf) + diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt b/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt index 63633bdea..ae5054c27 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.txt @@ -10,6 +10,7 @@ Required properties: - "renesas,irqc-r8a7792" (R-Car V2H) - "renesas,irqc-r8a7793" (R-Car M2-N) - "renesas,irqc-r8a7794" (R-Car E2) + - "renesas,intc-ex-r8a7795" (R-Car H3) - #interrupt-cells: has to be <2>: an interrupt index and flags, as defined in interrupts.txt in this directory - clocks: Must contain a reference to the functional clock. diff --git a/Documentation/devicetree/bindings/interrupt-controller/samsung,exynos4210-combiner.txt b/Documentation/devicetree/bindings/interrupt-controller/samsung,exynos4210-combiner.txt new file mode 100644 index 000000000..9e5f73412 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/samsung,exynos4210-combiner.txt @@ -0,0 +1,52 @@ +* Samsung Exynos Interrupt Combiner Controller + +Samsung's Exynos4 architecture includes a interrupt combiner controller which +can combine interrupt sources as a group and provide a single interrupt request +for the group. The interrupt request from each group are connected to a parent +interrupt controller, such as GIC in case of Exynos4210. + +The interrupt combiner controller consists of multiple combiners. Up to eight +interrupt sources can be connected to a combiner. The combiner outputs one +combined interrupt for its eight interrupt sources. The combined interrupt +is usually connected to a parent interrupt controller. + +A single node in the device tree is used to describe the interrupt combiner +controller module (which includes multiple combiners). A combiner in the +interrupt controller module shares config/control registers with other +combiners. For example, a 32-bit interrupt enable/disable config register +can accommodate up to 4 interrupt combiners (with each combiner supporting +up to 8 interrupt sources). + +Required properties: +- compatible: should be "samsung,exynos4210-combiner". +- interrupt-controller: Identifies the node as an interrupt controller. +- #interrupt-cells: should be <2>. The meaning of the cells are + * First Cell: Combiner Group Number. + * Second Cell: Interrupt number within the group. +- reg: Base address and size of interrupt combiner registers. +- interrupts: The list of interrupts generated by the combiners which are then + connected to a parent interrupt controller. The format of the interrupt + specifier depends in the interrupt parent controller. + +Optional properties: +- samsung,combiner-nr: The number of interrupt combiners supported. If this + property is not specified, the default number of combiners is assumed + to be 16. +- interrupt-parent: pHandle of the parent interrupt controller, if not + inherited from the parent node. + + +Example: + + The following is a an example from the Exynos4210 SoC dtsi file. + + combiner:interrupt-controller@10440000 { + compatible = "samsung,exynos4210-combiner"; + interrupt-controller; + #interrupt-cells = <2>; + reg = <0x10440000 0x1000>; + interrupts = <0 0 0>, <0 1 0>, <0 2 0>, <0 3 0>, + <0 4 0>, <0 5 0>, <0 6 0>, <0 7 0>, + <0 8 0>, <0 9 0>, <0 10 0>, <0 11 0>, + <0 12 0>, <0 13 0>, <0 14 0>, <0 15 0>; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/snps,arc700-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/snps,arc700-intc.txt new file mode 100644 index 000000000..9a5d56243 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/snps,arc700-intc.txt @@ -0,0 +1,24 @@ +* ARC700 incore Interrupt Controller + + The core interrupt controller provides 32 prioritised interrupts (2 levels) + to ARC700 core. + +Properties: + +- compatible: "snps,arc700-intc" +- interrupt-controller: This is an interrupt controller. +- #interrupt-cells: Must be <1>. + + Single Cell "interrupts" property of a device specifies the IRQ number + between 0 to 31 + + intc accessed via the special ARC AUX register interface, hence "reg" property + is not specified. + +Example: + + intc: interrupt-controller { + compatible = "snps,arc700-intc"; + interrupt-controller; + #interrupt-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/snps,archs-idu-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/snps,archs-idu-intc.txt new file mode 100644 index 000000000..0dcb7c7d3 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/snps,archs-idu-intc.txt @@ -0,0 +1,46 @@ +* ARC-HS Interrupt Distribution Unit + + This optional 2nd level interrupt controller can be used in SMP configurations for + dynamic IRQ routing, load balancing of common/external IRQs towards core intc. + +Properties: + +- compatible: "snps,archs-idu-intc" +- interrupt-controller: This is an interrupt controller. +- interrupt-parent: +- #interrupt-cells: Must be <2>. +- interrupts: <...> specifies the upstream core irqs + + First cell specifies the "common" IRQ from peripheral to IDU + Second cell specifies the irq distribution mode to cores + 0=Round Robin; 1=cpu0, 2=cpu1, 4=cpu2, 8=cpu3 + + intc accessed via the special ARC AUX register interface, hence "reg" property + is not specified. + +Example: + core_intc: core-interrupt-controller { + compatible = "snps,archs-intc"; + interrupt-controller; + #interrupt-cells = <1>; + }; + + idu_intc: idu-interrupt-controller { + compatible = "snps,archs-idu-intc"; + interrupt-controller; + interrupt-parent = <&core_intc>; + + /* + * + * distribution: 0=RR; 1=cpu0, 2=cpu1, 4=cpu2, 8=cpu3 + */ + #interrupt-cells = <2>; + + /* upstream core irqs: downstream these are "COMMON" irq 0,1.. */ + interrupts = <24 25 26 27 28 29 30 31>; + }; + + some_device: serial@c0fc1000 { + interrupt-parent = <&idu_intc>; + interrupts = <0 0>; /* upstream idu IRQ #24, Round Robin */ + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/snps,archs-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/snps,archs-intc.txt new file mode 100644 index 000000000..69f326d6a --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/snps,archs-intc.txt @@ -0,0 +1,22 @@ +* ARC-HS incore Interrupt Controller (Provided by cores implementing ARCv2 ISA) + +Properties: + +- compatible: "snps,archs-intc" +- interrupt-controller: This is an interrupt controller. +- #interrupt-cells: Must be <1>. + + Single Cell "interrupts" property of a device specifies the IRQ number + between 16 to 256 + + intc accessed via the special ARC AUX register interface, hence "reg" property + is not specified. + +Example: + + intc: interrupt-controller { + compatible = "snps,archs-intc"; + interrupt-controller; + #interrupt-cells = <1>; + interrupts = <16 17 18 19 20 21 22 23 24 25>; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/st,spear3xx-shirq.txt b/Documentation/devicetree/bindings/interrupt-controller/st,spear3xx-shirq.txt new file mode 100644 index 000000000..715a013ed --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/st,spear3xx-shirq.txt @@ -0,0 +1,48 @@ +* SPEAr Shared IRQ layer (shirq) + +SPEAr3xx architecture includes shared/multiplexed irqs for certain set +of devices. The multiplexor provides a single interrupt to parent +interrupt controller (VIC) on behalf of a group of devices. + +There can be multiple groups available on SPEAr3xx variants but not +exceeding 4. The number of devices in a group can differ, further they +may share same set of status/mask registers spanning across different +bit masks. Also in some cases the group may not have enable or other +registers. This makes software little complex. + +A single node in the device tree is used to describe the shared +interrupt multiplexor (one node for all groups). A group in the +interrupt controller shares config/control registers with other groups. +For example, a 32-bit interrupt enable/disable config register can +accommodate up to 4 interrupt groups. + +Required properties: + - compatible: should be, either of + - "st,spear300-shirq" + - "st,spear310-shirq" + - "st,spear320-shirq" + - interrupt-controller: Identifies the node as an interrupt controller. + - #interrupt-cells: should be <1> which basically contains the offset + (starting from 0) of interrupts for all the groups. + - reg: Base address and size of shirq registers. + - interrupts: The list of interrupts generated by the groups which are + then connected to a parent interrupt controller. Each group is + associated with one of the interrupts, hence number of interrupts (to + parent) is equal to number of groups. The format of the interrupt + specifier depends in the interrupt parent controller. + + Optional properties: + - interrupt-parent: pHandle of the parent interrupt controller, if not + inherited from the parent node. + +Example: + +The following is an example from the SPEAr320 SoC dtsi file. + +shirq: interrupt-controller@0xb3000000 { + compatible = "st,spear320-shirq"; + reg = <0xb3000000 0x1000>; + interrupts = <28 29 30 1>; + #interrupt-cells = <1>; + interrupt-controller; +}; diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,c64x+megamod-pic.txt b/Documentation/devicetree/bindings/interrupt-controller/ti,c64x+megamod-pic.txt new file mode 100644 index 000000000..42bb796cc --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/ti,c64x+megamod-pic.txt @@ -0,0 +1,104 @@ +C6X Interrupt Chips +------------------- + +* C64X+ Core Interrupt Controller + + The core interrupt controller provides 16 prioritized interrupts to the + C64X+ core. Priority 0 and 1 are used for reset and NMI respectively. + Priority 2 and 3 are reserved. Priority 4-15 are used for interrupt + sources coming from outside the core. + + Required properties: + -------------------- + - compatible: Should be "ti,c64x+core-pic"; + - #interrupt-cells: <1> + + Interrupt Specifier Definition + ------------------------------ + Single cell specifying the core interrupt priority level (4-15) where + 4 is highest priority and 15 is lowest priority. + + Example + ------- + core_pic: interrupt-controller@0 { + interrupt-controller; + #interrupt-cells = <1>; + compatible = "ti,c64x+core-pic"; + }; + + + +* C64x+ Megamodule Interrupt Controller + + The megamodule PIC consists of four interrupt mupliplexers each of which + combine up to 32 interrupt inputs into a single interrupt output which + may be cascaded into the core interrupt controller. The megamodule PIC + has a total of 12 outputs cascading into the core interrupt controller. + One for each core interrupt priority level. In addition to the combined + interrupt sources, individual megamodule interrupts may be cascaded to + the core interrupt controller. When an individual interrupt is cascaded, + it is no longer handled through a megamodule interrupt combiner and is + considered to have the core interrupt controller as the parent. + + Required properties: + -------------------- + - compatible: "ti,c64x+megamod-pic" + - interrupt-controller + - #interrupt-cells: <1> + - reg: base address and size of register area + - interrupt-parent: must be core interrupt controller + - interrupts: This should have four cells; one for each interrupt combiner. + The cells contain the core priority interrupt to which the + corresponding combiner output is wired. + + Optional properties: + -------------------- + - ti,c64x+megamod-pic-mux: Array of 12 cells correspnding to the 12 core + priority interrupts. The first cell corresponds to + core priority 4 and the last cell corresponds to + core priority 15. The value of each cell is the + megamodule interrupt source which is MUXed to + the core interrupt corresponding to the cell + position. Allowed values are 4 - 127. Mapping for + interrupts 0 - 3 (combined interrupt sources) are + ignored. + + Interrupt Specifier Definition + ------------------------------ + Single cell specifying the megamodule interrupt source (4-127). Note that + interrupts mapped directly to the core with "ti,c64x+megamod-pic-mux" will + use the core interrupt controller as their parent and the specifier will + be the core priority level, not the megamodule interrupt number. + + Examples + -------- + megamod_pic: interrupt-controller@1800000 { + compatible = "ti,c64x+megamod-pic"; + interrupt-controller; + #interrupt-cells = <1>; + reg = <0x1800000 0x1000>; + interrupt-parent = <&core_pic>; + interrupts = < 12 13 14 15 >; + }; + + This is a minimal example where all individual interrupts go through a + combiner. Combiner-0 is mapped to core interrupt 12, combiner-1 is mapped + to interrupt 13, etc. + + + megamod_pic: interrupt-controller@1800000 { + compatible = "ti,c64x+megamod-pic"; + interrupt-controller; + #interrupt-cells = <1>; + reg = <0x1800000 0x1000>; + interrupt-parent = <&core_pic>; + interrupts = < 12 13 14 15 >; + ti,c64x+megamod-pic-mux = < 0 0 0 0 + 32 0 0 0 + 0 0 0 0 >; + }; + + This the same as the first example except that megamodule interrupt 32 is + mapped directly to core priority interrupt 8. The node using this interrupt + must set the core controller as its interrupt parent and use 8 in the + interrupt specifier value. diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,cp-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/ti,cp-intc.txt new file mode 100644 index 000000000..597e8a089 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/ti,cp-intc.txt @@ -0,0 +1,27 @@ +* TI Common Platform Interrupt Controller + +Common Platform Interrupt Controller (cp_intc) is used on +OMAP-L1x SoCs and can support several configurable number +of interrupts. + +Main node required properties: + +- compatible : should be: + "ti,cp-intc" +- interrupt-controller : Identifies the node as an interrupt controller +- #interrupt-cells : Specifies the number of cells needed to encode an + interrupt source. The type shall be a and the value shall be 1. + + The cell contains the interrupt number in the range [0-128]. +- ti,intc-size: Number of interrupts handled by the interrupt controller. +- reg: physical base address and size of the intc registers map. + +Example: + + intc: interrupt-controller@1 { + compatible = "ti,cp-intc"; + interrupt-controller; + #interrupt-cells = <1>; + ti,intc-size = <101>; + reg = <0xfffee000 0x2000>; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,omap2-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/ti,omap2-intc.txt new file mode 100644 index 000000000..f2583e6ec --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/ti,omap2-intc.txt @@ -0,0 +1,27 @@ +* OMAP Interrupt Controller + +OMAP2/3 are using a TI interrupt controller that can support several +configurable number of interrupts. + +Main node required properties: + +- compatible : should be: + "ti,omap2-intc" +- interrupt-controller : Identifies the node as an interrupt controller +- #interrupt-cells : Specifies the number of cells needed to encode an + interrupt source. The type shall be a and the value shall be 1. + + The cell contains the interrupt number in the range [0-128]. +- ti,intc-size: Number of interrupts handled by the interrupt controller. +- reg: physical base address and size of the intc registers map. + +Example: + + intc: interrupt-controller@1 { + compatible = "ti,omap2-intc"; + interrupt-controller; + #interrupt-cells = <1>; + ti,intc-size = <96>; + reg = <0x48200000 0x1000>; + }; + diff --git a/Documentation/devicetree/bindings/interrupt-controller/via,vt8500-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/via,vt8500-intc.txt new file mode 100644 index 000000000..0a4ce1051 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/via,vt8500-intc.txt @@ -0,0 +1,16 @@ +VIA/Wondermedia VT8500 Interrupt Controller +----------------------------------------------------- + +Required properties: +- compatible : "via,vt8500-intc" +- reg : Should contain 1 register ranges(address and length) +- #interrupt-cells : should be <1> + +Example: + + intc: interrupt-controller@d8140000 { + compatible = "via,vt8500-intc"; + interrupt-controller; + reg = <0xd8140000 0x10000>; + #interrupt-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt index 3443e0f83..947863acc 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt +++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.txt @@ -36,5 +36,24 @@ the PCIe specification. NOTE: this only applies to the SMMU itself, not masters connected upstream of the SMMU. +- msi-parent : See the generic MSI binding described in + devicetree/bindings/interrupt-controller/msi.txt + for a description of the msi-parent property. + - hisilicon,broken-prefetch-cmd : Avoid sending CMD_PREFETCH_* commands to the SMMU. + +** Example + + smmu@2b400000 { + compatible = "arm,smmu-v3"; + reg = <0x0 0x2b400000 0x0 0x20000>; + interrupts = , + , + , + ; + interrupt-names = "eventq", "priq", "cmdq-sync", "gerror"; + dma-coherent; + #iommu-cells = <0>; + msi-parent = <&its 0xff0000>; + }; diff --git a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt index 729543c47..bc620fe32 100644 --- a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt +++ b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt @@ -47,7 +47,7 @@ Required properties: - clocks: Required if the System MMU is needed to gate its clock. - power-domains: Required if the System MMU is needed to gate its power. Please refer to the following document: - Documentation/devicetree/bindings/arm/exynos/power_domain.txt + Documentation/devicetree/bindings/power/pd-samsung.txt Examples: gsc_0: gsc@13e00000 { diff --git a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt index 869699925..4bd10dd88 100644 --- a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt +++ b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt @@ -4,6 +4,7 @@ Required properties: - compatible : Should be one of, "ti,omap2-iommu" for OMAP2/OMAP3 IOMMU instances "ti,omap4-iommu" for OMAP4/OMAP5 IOMMU instances + "ti,dra7-dsp-iommu" for DRA7xx DSP IOMMU instances "ti,dra7-iommu" for DRA7xx IOMMU instances - ti,hwmods : Name of the hwmod associated with the IOMMU instance - reg : Address space for the configuration registers @@ -19,6 +20,13 @@ Optional properties: Should be either 8 or 32 (default: 32) - ti,iommu-bus-err-back : Indicates the IOMMU instance supports throwing back a bus error response on MMU faults. +- ti,syscon-mmuconfig : Should be a pair of the phandle to the DSP_SYSTEM + syscon node that contains the additional control + register for enabling the MMU, and the MMU instance + number (0-indexed) within the sub-system. This property + is required for DSP IOMMU instances on DRA7xx SoCs. The + instance number should be 0 for DSP MDMA MMUs and 1 for + DSP EDMA MMUs. Example: /* OMAP3 ISP MMU */ @@ -30,3 +38,22 @@ Example: ti,hwmods = "mmu_isp"; ti,#tlb-entries = <8>; }; + + /* DRA74x DSP2 MMUs */ + mmu0_dsp2: mmu@41501000 { + compatible = "ti,dra7-dsp-iommu"; + reg = <0x41501000 0x100>; + interrupts = ; + ti,hwmods = "mmu0_dsp2"; + #iommu-cells = <0>; + ti,syscon-mmuconfig = <&dsp2_system 0x0>; + }; + + mmu1_dsp2: mmu@41502000 { + compatible = "ti,dra7-dsp-iommu"; + reg = <0x41502000 0x100>; + interrupts = ; + ti,hwmods = "mmu1_dsp2"; + #iommu-cells = <0>; + ti,syscon-mmuconfig = <&dsp2_system 0x1>; + }; diff --git a/Documentation/devicetree/bindings/leds/backlight/88pm860x.txt b/Documentation/devicetree/bindings/leds/backlight/88pm860x.txt new file mode 100644 index 000000000..261df2799 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/backlight/88pm860x.txt @@ -0,0 +1,15 @@ +88pm860x-backlight bindings + +Optional properties: + - marvell,88pm860x-iset: Current supplies on backlight device. + - marvell,88pm860x-pwm: PWM frequency on backlight device. + +Example: + + backlights { + backlight-0 { + marvell,88pm860x-iset = <4>; + marvell,88pm860x-pwm = <3>; + }; + backlight-2 { + }; diff --git a/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.txt b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.txt new file mode 100644 index 000000000..321be6640 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.txt @@ -0,0 +1,16 @@ +gpio-backlight bindings + +Required properties: + - compatible: "gpio-backlight" + - gpios: describes the gpio that is used for enabling/disabling the backlight. + refer to bindings/gpio/gpio.txt for more details. + +Optional properties: + - default-on: enable the backlight at boot. + +Example: + backlight { + compatible = "gpio-backlight"; + gpios = <&gpio3 4 GPIO_ACTIVE_HIGH>; + default-on; + }; diff --git a/Documentation/devicetree/bindings/leds/backlight/lp855x.txt b/Documentation/devicetree/bindings/leds/backlight/lp855x.txt new file mode 100644 index 000000000..0a3ecbc3a --- /dev/null +++ b/Documentation/devicetree/bindings/leds/backlight/lp855x.txt @@ -0,0 +1,70 @@ +lp855x bindings + +Required properties: + - compatible: "ti,lp8550", "ti,lp8551", "ti,lp8552", "ti,lp8553", + "ti,lp8555", "ti,lp8556", "ti,lp8557" + - reg: I2C slave address (u8) + - dev-ctrl: Value of DEVICE CONTROL register (u8). It depends on the device. + +Optional properties: + - bl-name: Backlight device name (string) + - init-brt: Initial value of backlight brightness (u8) + - pwm-period: PWM period value. Set only PWM input mode used (u32) + - rom-addr: Register address of ROM area to be updated (u8) + - rom-val: Register value to be updated (u8) + - power-supply: Regulator which controls the 3V rail + +Example: + + /* LP8555 */ + backlight@2c { + compatible = "ti,lp8555"; + reg = <0x2c>; + + dev-ctrl = /bits/ 8 <0x00>; + pwm-period = <10000>; + + /* 4V OV, 4 output LED0 string enabled */ + rom_14h { + rom-addr = /bits/ 8 <0x14>; + rom-val = /bits/ 8 <0xcf>; + }; + + /* Heavy smoothing, 24ms ramp time step */ + rom_15h { + rom-addr = /bits/ 8 <0x15>; + rom-val = /bits/ 8 <0xc7>; + }; + + /* 4 output LED1 string enabled */ + rom_19h { + rom-addr = /bits/ 8 <0x19>; + rom-val = /bits/ 8 <0x0f>; + }; + }; + + /* LP8556 */ + backlight@2c { + compatible = "ti,lp8556"; + reg = <0x2c>; + + bl-name = "lcd-bl"; + dev-ctrl = /bits/ 8 <0x85>; + init-brt = /bits/ 8 <0x10>; + }; + + /* LP8557 */ + backlight@2c { + compatible = "ti,lp8557"; + reg = <0x2c>; + power-supply = <&backlight_vdd>; + + dev-ctrl = /bits/ 8 <0x41>; + init-brt = /bits/ 8 <0x0a>; + + /* 4V OV, 4 output LED string enabled */ + rom_14h { + rom-addr = /bits/ 8 <0x14>; + rom-val = /bits/ 8 <0xcf>; + }; + }; diff --git a/Documentation/devicetree/bindings/leds/backlight/max8925-backlight.txt b/Documentation/devicetree/bindings/leds/backlight/max8925-backlight.txt new file mode 100644 index 000000000..b4cffdaa4 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/backlight/max8925-backlight.txt @@ -0,0 +1,10 @@ +88pm860x-backlight bindings + +Optional properties: + - maxim,max8925-dual-string: whether support dual string + +Example: + + backlights { + maxim,max8925-dual-string = <0>; + }; diff --git a/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt b/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt new file mode 100644 index 000000000..e5b294daf --- /dev/null +++ b/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt @@ -0,0 +1,42 @@ +Binding for Qualcomm PM8941 WLED driver + +Required properties: +- compatible: should be "qcom,pm8941-wled" +- reg: slave address + +Optional properties: +- default-brightness: brightness value on boot, value from: 0-4095 + default: 2048 +- label: The name of the backlight device +- qcom,cs-out: bool; enable current sink output +- qcom,cabc: bool; enable content adaptive backlight control +- qcom,ext-gen: bool; use externally generated modulator signal to dim +- qcom,current-limit: mA; per-string current limit; value from 0 to 25 + default: 20mA +- qcom,current-boost-limit: mA; boost current limit; one of: + 105, 385, 525, 805, 980, 1260, 1400, 1680 + default: 805mA +- qcom,switching-freq: kHz; switching frequency; one of: + 600, 640, 685, 738, 800, 872, 960, 1066, 1200, 1371, + 1600, 1920, 2400, 3200, 4800, 9600, + default: 1600kHz +- qcom,ovp: V; Over-voltage protection limit; one of: + 27, 29, 32, 35 + default: 29V +- qcom,num-strings: #; number of led strings attached; value from 1 to 3 + default: 2 + +Example: + +pm8941-wled@d800 { + compatible = "qcom,pm8941-wled"; + reg = <0xd800>; + label = "backlight"; + + qcom,cs-out; + qcom,current-limit = <20>; + qcom,current-boost-limit = <805>; + qcom,switching-freq = <1600>; + qcom,ovp = <29>; + qcom,num-strings = <2>; +}; diff --git a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt new file mode 100644 index 000000000..764db86d4 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt @@ -0,0 +1,35 @@ +pwm-backlight bindings + +Required properties: + - compatible: "pwm-backlight" + - pwms: OF device-tree PWM specification (see PWM binding[0]) + - brightness-levels: Array of distinct brightness levels. Typically these + are in the range from 0 to 255, but any range starting at 0 will do. + The actual brightness level (PWM duty cycle) will be interpolated + from these values. 0 means a 0% duty cycle (darkest/off), while the + last value in the array represents a 100% duty cycle (brightest). + - default-brightness-level: the default brightness level (index into the + array defined by the "brightness-levels" property) + - power-supply: regulator for supply voltage + +Optional properties: + - pwm-names: a list of names for the PWM devices specified in the + "pwms" property (see PWM binding[0]) + - enable-gpios: contains a single GPIO specifier for the GPIO which enables + and disables the backlight (see GPIO binding[1]) + +[0]: Documentation/devicetree/bindings/pwm/pwm.txt +[1]: Documentation/devicetree/bindings/gpio/gpio.txt + +Example: + + backlight { + compatible = "pwm-backlight"; + pwms = <&pwm 0 5000000>; + + brightness-levels = <0 4 8 16 32 64 128 255>; + default-brightness-level = <6>; + + power-supply = <&vdd_bl_reg>; + enable-gpios = <&gpio 58 0>; + }; diff --git a/Documentation/devicetree/bindings/leds/backlight/sky81452-backlight.txt b/Documentation/devicetree/bindings/leds/backlight/sky81452-backlight.txt new file mode 100644 index 000000000..8bf2940f5 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/backlight/sky81452-backlight.txt @@ -0,0 +1,29 @@ +SKY81452-backlight bindings + +Required properties: +- compatible : Must be "skyworks,sky81452-backlight" + +Optional properties: +- name : Name of backlight device. Default is 'lcd-backlight'. +- gpios : GPIO to use to EN pin. + See Documentation/devicetree/bindings/gpio/gpio.txt +- led-sources : List of enabled channels from 0 to 5. + See Documentation/devicetree/bindings/leds/common.txt +- skyworks,ignore-pwm : Ignore both PWM input +- skyworks,dpwm-mode : Enable DPWM dimming mode, otherwise Analog dimming. +- skyworks,phase-shift : Enable phase shift mode +- skyworks,short-detection-threshold-volt + : It should be one of 4, 5, 6 and 7V. +- skyworks,current-limit-mA + : It should be 2300mA or 2750mA. + +Example: + + backlight { + compatible = "skyworks,sky81452-backlight"; + name = "pwm-backlight"; + led-sources = <0 1 2 5>; + skyworks,ignore-pwm; + skyworks,phase-shift; + skyworks,current-limit-mA = <2300>; + }; diff --git a/Documentation/devicetree/bindings/leds/backlight/tps65217-backlight.txt b/Documentation/devicetree/bindings/leds/backlight/tps65217-backlight.txt new file mode 100644 index 000000000..5fb9279ac --- /dev/null +++ b/Documentation/devicetree/bindings/leds/backlight/tps65217-backlight.txt @@ -0,0 +1,27 @@ +TPS65217 family of regulators + +The TPS65217 chip contains a boost converter and current sinks which can be +used to drive LEDs for use as backlights. + +Required properties: +- compatible: "ti,tps65217" +- reg: I2C slave address +- backlight: node for specifying WLED1 and WLED2 lines in TPS65217 +- isel: selection bit, valid values: 1 for ISEL1 (low-level) and 2 for ISEL2 (high-level) +- fdim: PWM dimming frequency, valid values: 100, 200, 500, 1000 +- default-brightness: valid values: 0-100 + +Each regulator is defined using the standard binding for regulators. + +Example: + + tps: tps@24 { + reg = <0x24>; + compatible = "ti,tps65217"; + backlight { + isel = <1>; /* 1 - ISET1, 2 ISET2 */ + fdim = <100>; /* TPS65217_BL_FDIM_100HZ */ + default-brightness = <50>; + }; + }; + diff --git a/Documentation/devicetree/bindings/leds/leds-aat1290.txt b/Documentation/devicetree/bindings/leds/leds-aat1290.txt index c05ed91a4..85c0c5861 100644 --- a/Documentation/devicetree/bindings/leds/leds-aat1290.txt +++ b/Documentation/devicetree/bindings/leds/leds-aat1290.txt @@ -27,9 +27,9 @@ Required properties of the LED child node: - flash-max-microamp : see Documentation/devicetree/bindings/leds/common.txt Maximum flash LED supply current can be calculated using following formula: I = 1A * 162kohm / Rset. -- flash-timeout-us : see Documentation/devicetree/bindings/leds/common.txt - Maximum flash timeout can be calculated using following - formula: T = 8.82 * 10^9 * Ct. +- flash-max-timeout-us : see Documentation/devicetree/bindings/leds/common.txt + Maximum flash timeout can be calculated using following + formula: T = 8.82 * 10^9 * Ct. Optional properties of the LED child node: - label : see Documentation/devicetree/bindings/leds/common.txt @@ -54,7 +54,7 @@ aat1290 { label = "aat1290-flash"; led-max-microamp = <520833>; flash-max-microamp = <1012500>; - flash-timeout-us = <1940000>; + flash-max-timeout-us = <1940000>; }; }; diff --git a/Documentation/devicetree/bindings/leds/leds-bcm6328.txt b/Documentation/devicetree/bindings/leds/leds-bcm6328.txt index f9e36adc0..3f48c1eaf 100644 --- a/Documentation/devicetree/bindings/leds/leds-bcm6328.txt +++ b/Documentation/devicetree/bindings/leds/leds-bcm6328.txt @@ -29,6 +29,14 @@ Required properties: Optional properties: - brcm,serial-leds : Boolean, enables Serial LEDs. Default : false + - brcm,serial-mux : Boolean, enables Serial LEDs multiplexing. + Default : false + - brcm,serial-clk-low : Boolean, makes clock signal active low. + Default : false + - brcm,serial-dat-low : Boolean, makes data signal active low. + Default : false + - brcm,serial-shift-inv : Boolean, inverts Serial LEDs shift direction. + Default : false Each LED is represented as a sub-node of the brcm,bcm6328-leds device. @@ -110,6 +118,8 @@ Scenario 2 : BCM63268 with Serial/GPHY0 LEDs #size-cells = <0>; reg = <0x10001900 0x24>; brcm,serial-leds; + brcm,serial-dat-low; + brcm,serial-shift-inv; gphy0_spd0@0 { reg = <0>; diff --git a/Documentation/devicetree/bindings/leds/leds-netxbig.txt b/Documentation/devicetree/bindings/leds/leds-netxbig.txt new file mode 100644 index 000000000..5ef92a26d --- /dev/null +++ b/Documentation/devicetree/bindings/leds/leds-netxbig.txt @@ -0,0 +1,92 @@ +Binding for the CPLD LEDs (GPIO extension bus) found on some LaCie/Seagate +boards (Example: 2Big/5Big Network v2, 2Big NAS). + +Required properties: +- compatible: "lacie,netxbig-leds". +- gpio-ext: Phandle for the gpio-ext bus. + +Optional properties: +- timers: Timer array. Each timer entry is represented by three integers: + Mode (gpio-ext bus), delay_on and delay_off. + +Each LED is represented as a sub-node of the netxbig-leds device. + +Required sub-node properties: +- mode-addr: Mode register address on gpio-ext bus. +- mode-val: Mode to value mapping. Each entry is represented by two integers: + A mode and the corresponding value on the gpio-ext bus. +- bright-addr: Brightness register address on gpio-ext bus. +- max-brightness: Maximum brightness value. + +Optional sub-node properties: +- label: Name for this LED. If omitted, the label is taken from the node name. +- linux,default-trigger: Trigger assigned to the LED. + +Example: + +netxbig-leds { + compatible = "lacie,netxbig-leds"; + + gpio-ext = &gpio_ext; + + timers = ; + + blue-power { + label = "netxbig:blue:power"; + mode-addr = <0>; + mode-val = ; + bright-addr = <1>; + max-brightness = <7>; + }; + red-power { + label = "netxbig:red:power"; + mode-addr = <0>; + mode-val = ; + bright-addr = <1>; + max-brightness = <7>; + }; + blue-sata0 { + label = "netxbig:blue:sata0"; + mode-addr = <3>; + mode-val = ; + bright-addr = <2>; + max-brightness = <7>; + }; + red-sata0 { + label = "netxbig:red:sata0"; + mode-addr = <3>; + mode-val = ; + bright-addr = <2>; + max-brightness = <7>; + }; + blue-sata1 { + label = "netxbig:blue:sata1"; + mode-addr = <4>; + mode-val = ; + bright-addr = <2>; + max-brightness = <7>; + }; + red-sata1 { + label = "netxbig:red:sata1"; + mode-addr = <4>; + mode-val = ; + bright-addr = <2>; + max-brightness = <7>; + }; +}; diff --git a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt index d1a043339..9b40c4925 100644 --- a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt +++ b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt @@ -75,6 +75,14 @@ data that represent the following: Cell #3 (usr_id) - mailbox user id for identifying the interrupt line associated with generating a tx/rx fifo interrupt. +Optional Properties: +-------------------- +- ti,mbox-send-noirq: Quirk flag to allow the client user of this sub-mailbox + to send messages without triggering a Tx ready interrupt, + and to control the Tx ticker. Should be used only on + sub-mailboxes used to communicate with WkupM3 remote + processor on AM33xx/AM43xx SoCs. + Mailbox Users: ============== A device needing to communicate with a target processor device should specify diff --git a/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt b/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt new file mode 100644 index 000000000..b61eec920 --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/sti-mailbox.txt @@ -0,0 +1,51 @@ +ST Microelectronics Mailbox Driver + +Each ST Mailbox IP currently consists of 4 instances of 32 channels. Messages +are passed between Application and Remote processors using shared memory. + +Controller +---------- + +Required properties: +- compatible : Should be "st,stih407-mailbox" +- reg : Offset and length of the device's register set +- mbox-name : Name of the mailbox +- #mbox-cells: : Must be 2 + <&phandle instance channel direction> + phandle : Label name of controller + instance : Instance number + channel : Channel number + +Optional properties +- interrupts : Contains the IRQ line for a Rx mailbox + +Example: + +mailbox0: mailbox@0 { + compatible = "st,stih407-mailbox"; + reg = <0x08f00000 0x1000>; + interrupts = ; + #mbox-cells = <2>; + mbox-name = "a9"; +}; + +Client +------ + +Required properties: +- compatible : Many (See the client docs) +- reg : Shared (between Application and Remote) memory address +- mboxes : Standard property to specify a Mailbox (See ./mailbox.txt) + Cells must match 'mbox-cells' (See Controller docs above) + +Optional properties +- mbox-names : Name given to channels seen in the 'mboxes' property. + +Example: + +mailbox_test { + compatible = "mailbox_test"; + reg = <0x[shared_memory_address], [shared_memory_size]>; + mboxes = <&mailbox2 0 1>, <&mailbox0 2 1>; + mbox-names = "tx", "rx"; +}; diff --git a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt index 4ef45636e..38941db23 100644 --- a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt +++ b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt @@ -4,7 +4,8 @@ Required properties: - compatible : should be one of: "samsung,s5pv210-jpeg", "samsung,exynos4210-jpeg", - "samsung,exynos3250-jpeg", "samsung,exynos5420-jpeg"; + "samsung,exynos3250-jpeg", "samsung,exynos5420-jpeg", + "samsung,exynos5433-jpeg"; - reg : address and length of the JPEG codec IP register set; - interrupts : specifies the JPEG codec IP interrupt; - clock-names : should contain: diff --git a/Documentation/devicetree/bindings/memory-controllers/arm,pl172.txt b/Documentation/devicetree/bindings/memory-controllers/arm,pl172.txt index e6df32f99..22b77ee02 100644 --- a/Documentation/devicetree/bindings/memory-controllers/arm,pl172.txt +++ b/Documentation/devicetree/bindings/memory-controllers/arm,pl172.txt @@ -1,8 +1,9 @@ -* Device tree bindings for ARM PL172 MultiPort Memory Controller +* Device tree bindings for ARM PL172/PL175/PL176 MultiPort Memory Controller Required properties: -- compatible: "arm,pl172", "arm,primecell" +- compatible: Must be "arm,primecell" and exactly one from + "arm,pl172", "arm,pl175" or "arm,pl176". - reg: Must contains offset/length value for controller. @@ -56,7 +57,8 @@ Optional child cs node config properties: - mpmc,extended-wait: Enable extended wait. -- mpmc,buffer-enable: Enable write buffer. +- mpmc,buffer-enable: Enable write buffer, option is not supported by + PL175 and PL176 controllers. - mpmc,write-protect: Enable write protect. diff --git a/Documentation/devicetree/bindings/memory-controllers/calxeda-ddr-ctrlr.txt b/Documentation/devicetree/bindings/memory-controllers/calxeda-ddr-ctrlr.txt new file mode 100644 index 000000000..049675944 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/calxeda-ddr-ctrlr.txt @@ -0,0 +1,16 @@ +Calxeda DDR memory controller + +Properties: +- compatible : Should be: + - "calxeda,hb-ddr-ctrl" for ECX-1000 + - "calxeda,ecx-2000-ddr-ctrl" for ECX-2000 +- reg : Address and size for DDR controller registers. +- interrupts : Interrupt for DDR controller. + +Example: + + memory-controller@fff00000 { + compatible = "calxeda,hb-ddr-ctrl"; + reg = <0xfff00000 0x1000>; + interrupts = <0 91 4>; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas-memory-controllers.txt b/Documentation/devicetree/bindings/memory-controllers/renesas-memory-controllers.txt index c64b7925c..9f78e6c82 100644 --- a/Documentation/devicetree/bindings/memory-controllers/renesas-memory-controllers.txt +++ b/Documentation/devicetree/bindings/memory-controllers/renesas-memory-controllers.txt @@ -24,9 +24,9 @@ Required properties: Optional properties: - interrupts: Must contain a list of interrupt specifiers for memory controller interrupts, if available. - - interrupts-names: Must contain a list of interrupt names corresponding to - the interrupts in the interrupts property, if available. - Valid interrupt names are: + - interrupt-names: Must contain a list of interrupt names corresponding to + the interrupts in the interrupts property, if available. + Valid interrupt names are: - "sec" (secure interrupt) - "temp" (normal (temperature) interrupt) - power-domains: Must contain a reference to the PM domain that the memory diff --git a/Documentation/devicetree/bindings/metag/meta-intc.txt b/Documentation/devicetree/bindings/metag/meta-intc.txt deleted file mode 100644 index 80994adab..000000000 --- a/Documentation/devicetree/bindings/metag/meta-intc.txt +++ /dev/null @@ -1,82 +0,0 @@ -* Meta External Trigger Controller Binding - -This binding specifies what properties must be available in the device tree -representation of a Meta external trigger controller. - -Required properties: - - - compatible: Specifies the compatibility list for the interrupt controller. - The type shall be and the value shall include "img,meta-intc". - - - num-banks: Specifies the number of interrupt banks (each of which can - handle 32 interrupt sources). - - - interrupt-controller: The presence of this property identifies the node - as an interrupt controller. No property value shall be defined. - - - #interrupt-cells: Specifies the number of cells needed to encode an - interrupt source. The type shall be a and the value shall be 2. - - - #address-cells: Specifies the number of cells needed to encode an - address. The type shall be and the value shall be 0. As such, - 'interrupt-map' nodes do not have to specify a parent unit address. - -Optional properties: - - - no-mask: The controller doesn't have any mask registers. - -* Interrupt Specifier Definition - - Interrupt specifiers consists of 2 cells encoded as follows: - - - <1st-cell>: The interrupt-number that identifies the interrupt source. - - - <2nd-cell>: The Linux interrupt flags containing level-sense information, - encoded as follows: - 1 = edge triggered - 4 = level-sensitive - -* Examples - -Example 1: - - /* - * Meta external trigger block - */ - intc: intc { - // This is an interrupt controller node. - interrupt-controller; - - // No address cells so that 'interrupt-map' nodes which - // reference this interrupt controller node do not need a parent - // address specifier. - #address-cells = <0>; - - // Two cells to encode interrupt sources. - #interrupt-cells = <2>; - - // Number of interrupt banks - num-banks = <2>; - - // No HWMASKEXT is available (specify on Chorus2 and Comet ES1) - no-mask; - - // Compatible with Meta hardware trigger block. - compatible = "img,meta-intc"; - }; - -Example 2: - - /* - * An interrupt generating device that is wired to a Meta external - * trigger block. - */ - uart1: uart@0x02004c00 { - // Interrupt source '5' that is level-sensitive. - // Note that there are only two cells as specified in the - // interrupt parent's '#interrupt-cells' property. - interrupts = <5 4 /* level */>; - - // The interrupt controller that this device is wired to. - interrupt-parent = <&intc>; - }; diff --git a/Documentation/devicetree/bindings/metag/pdc-intc.txt b/Documentation/devicetree/bindings/metag/pdc-intc.txt deleted file mode 100644 index a69118550..000000000 --- a/Documentation/devicetree/bindings/metag/pdc-intc.txt +++ /dev/null @@ -1,105 +0,0 @@ -* ImgTec Powerdown Controller (PDC) Interrupt Controller Binding - -This binding specifies what properties must be available in the device tree -representation of a PDC IRQ controller. This has a number of input interrupt -lines which can wake the system, and are passed on through output interrupt -lines. - -Required properties: - - - compatible: Specifies the compatibility list for the interrupt controller. - The type shall be and the value shall include "img,pdc-intc". - - - reg: Specifies the base PDC physical address(s) and size(s) of the - addressable register space. The type shall be . - - - interrupt-controller: The presence of this property identifies the node - as an interrupt controller. No property value shall be defined. - - - #interrupt-cells: Specifies the number of cells needed to encode an - interrupt source. The type shall be a and the value shall be 2. - - - num-perips: Number of waking peripherals. - - - num-syswakes: Number of SysWake inputs. - - - interrupts: List of interrupt specifiers. The first specifier shall be the - shared SysWake interrupt, and remaining specifies shall be PDC peripheral - interrupts in order. - -* Interrupt Specifier Definition - - Interrupt specifiers consists of 2 cells encoded as follows: - - - <1st-cell>: The interrupt-number that identifies the interrupt source. - 0-7: Peripheral interrupts - 8-15: SysWake interrupts - - - <2nd-cell>: The level-sense information, encoded using the Linux interrupt - flags as follows (only 4 valid for peripheral interrupts): - 0 = none (decided by software) - 1 = low-to-high edge triggered - 2 = high-to-low edge triggered - 3 = both edge triggered - 4 = active-high level-sensitive (required for perip irqs) - 8 = active-low level-sensitive - -* Examples - -Example 1: - - /* - * TZ1090 PDC block - */ - pdc: pdc@0x02006000 { - // This is an interrupt controller node. - interrupt-controller; - - // Three cells to encode interrupt sources. - #interrupt-cells = <2>; - - // Offset address of 0x02006000 and size of 0x1000. - reg = <0x02006000 0x1000>; - - // Compatible with Meta hardware trigger block. - compatible = "img,pdc-intc"; - - // Three peripherals are connected. - num-perips = <3>; - - // Four SysWakes are connected. - num-syswakes = <4>; - - interrupts = <18 4 /* level */>, /* Syswakes */ - <30 4 /* level */>, /* Peripheral 0 (RTC) */ - <29 4 /* level */>, /* Peripheral 1 (IR) */ - <31 4 /* level */>; /* Peripheral 2 (WDT) */ - }; - -Example 2: - - /* - * An SoC peripheral that is wired through the PDC. - */ - rtc0 { - // The interrupt controller that this device is wired to. - interrupt-parent = <&pdc>; - - // Interrupt source Peripheral 0 - interrupts = <0 /* Peripheral 0 (RTC) */ - 4> /* IRQ_TYPE_LEVEL_HIGH */ - }; - -Example 3: - - /* - * An interrupt generating device that is wired to a SysWake pin. - */ - touchscreen0 { - // The interrupt controller that this device is wired to. - interrupt-parent = <&pdc>; - - // Interrupt source SysWake 0 that is active-low level-sensitive - interrupts = <8 /* SysWake0 */ - 8 /* IRQ_TYPE_LEVEL_LOW */>; - }; diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt index a8fee60dc..18be0cbfb 100644 --- a/Documentation/devicetree/bindings/mfd/arizona.txt +++ b/Documentation/devicetree/bindings/mfd/arizona.txt @@ -44,7 +44,6 @@ Required properties: Optional properties: - wlf,reset : GPIO specifier for the GPIO controlling /RESET - - wlf,ldoena : GPIO specifier for the GPIO controlling LDOENA - wlf,gpio-defaults : A list of GPIO configuration register values. Defines for the appropriate values can found in . If @@ -67,21 +66,13 @@ Optional properties: present, the number of values should be less than or equal to the number of inputs, unspecified inputs will use the chip default. - - wlf,hpdet-channel : Headphone detection channel. - ARIZONA_ACCDET_MODE_HPL or 1 - Headphone detect mode is set to HPDETL - ARIZONA_ACCDET_MODE_HPR or 2 - Headphone detect mode is set to HPDETR - If this node is not mentioned or if the value is unknown, then - headphone detection mode is set to HPDETL. - - DCVDD-supply, MICVDD-supply : Power supplies, only need to be specified if they are being externally supplied. As covered in Documentation/devicetree/bindings/regulator/regulator.txt -Optional subnodes: - - ldo1 : Initial data for the LDO1 regulator, as covered in - Documentation/devicetree/bindings/regulator/regulator.txt - - micvdd : Initial data for the MICVDD regulator, as covered in - Documentation/devicetree/bindings/regulator/regulator.txt +Also see child specific device properties: + Regulator - ../regulator/arizona-regulator.txt + Extcon - ../extcon/extcon-arizona.txt Example: diff --git a/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt new file mode 100644 index 000000000..692300117 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt @@ -0,0 +1,63 @@ +* Device tree bindings for Atmel Flexcom (Flexible Serial Communication Unit) + +The Atmel Flexcom is just a wrapper which embeds a SPI controller, an I2C +controller and an USART. Only one function can be used at a time and is chosen +at boot time according to the device tree. + +Required properties: +- compatible: Should be "atmel,sama5d2-flexcom" +- reg: Should be the offset/length value for Flexcom dedicated + I/O registers (without USART, TWI or SPI registers). +- clocks: Should be the Flexcom peripheral clock from PMC. +- #address-cells: Should be <1> +- #size-cells: Should be <1> +- ranges: Should be one range for the full I/O register region + (including USART, TWI and SPI registers). +- atmel,flexcom-mode: Should be one of the following values: + - <1> for USART + - <2> for SPI + - <3> for I2C + +Required child: +A single available child device of type matching the "atmel,flexcom-mode" +property. + +The phandle provided by the clocks property of the child is the same as one for +the Flexcom parent. + +For other properties, please refer to the documentations of the respective +device: +- ../serial/atmel-usart.txt +- ../spi/spi_atmel.txt +- ../i2c/i2c-at91.txt + +Example: + +flexcom@f8034000 { + compatible = "atmel,sama5d2-flexcom"; + reg = <0xf8034000 0x200>; + clocks = <&flx0_clk>; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0x0 0xf8034000 0x800>; + atmel,flexcom-mode = <2>; + + spi@400 { + compatible = "atmel,at91rm9200-spi"; + reg = <0x400 0x200>; + interrupts = <19 IRQ_TYPE_LEVEL_HIGH 7>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_flx0_default>; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&flx0_clk>; + clock-names = "spi_clk"; + atmel,fifo-size = <32>; + + mtd_dataflash@0 { + compatible = "atmel,at25f512b"; + reg = <0>; + spi-max-frequency = <20000000>; + }; + }; +}; diff --git a/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt b/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt index ad5d90482..670831b29 100644 --- a/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt +++ b/Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt @@ -15,7 +15,7 @@ Required properties: The HLCDC IP exposes two subdevices: - a PWM chip: see ../pwm/atmel-hlcdc-pwm.txt - - a Display Controller: see ../drm/atmel-hlcdc-dc.txt + - a Display Controller: see ../display/atmel-hlcdc-dc.txt Example: diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt index 41811223e..a474359dd 100644 --- a/Documentation/devicetree/bindings/mfd/axp20x.txt +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt @@ -60,8 +60,8 @@ DCDC2 : DC-DC buck : vin2-supply DCDC3 : DC-DC buck : vin3-supply DCDC4 : DC-DC buck : vin4-supply DCDC5 : DC-DC buck : vin5-supply -DC1SW : On/Off Switch : dcdc1-supply : DCDC1 secondary output -DC5LDO : LDO : dcdc5-supply : input from DCDC5 +DC1SW : On/Off Switch : : DCDC1 secondary output +DC5LDO : LDO : : input from DCDC5 ALDO1 : LDO : aldoin-supply : shared supply ALDO2 : LDO : aldoin-supply : shared supply ALDO3 : LDO : aldoin-supply : shared supply diff --git a/Documentation/devicetree/bindings/mfd/cros-ec.txt b/Documentation/devicetree/bindings/mfd/cros-ec.txt index 1777916e9..136e0c2da 100644 --- a/Documentation/devicetree/bindings/mfd/cros-ec.txt +++ b/Documentation/devicetree/bindings/mfd/cros-ec.txt @@ -34,6 +34,10 @@ Required properties (LPC): - compatible: "google,cros-ec-lpc" - reg: List of (IO address, size) pairs defining the interface uses +Optional properties (all): +- google,has-vbc-nvram: Some implementations of the EC include a small + nvram space used to store verified boot context data. This boolean flag + is used to specify whether this nvram is present or not. Example for I2C: diff --git a/Documentation/devicetree/bindings/mfd/da9150.txt b/Documentation/devicetree/bindings/mfd/da9150.txt index d0588eaa0..fd4dca7f4 100644 --- a/Documentation/devicetree/bindings/mfd/da9150.txt +++ b/Documentation/devicetree/bindings/mfd/da9150.txt @@ -6,6 +6,7 @@ Device Description ------ ----------- da9150-gpadc : General Purpose ADC da9150-charger : Battery Charger +da9150-fg : Battery Fuel-Gauge ====== @@ -16,13 +17,13 @@ Required properties: the IRQs from da9150 are delivered to. - interrupts: IRQ line info for da9150 chip. - interrupt-controller: da9150 has internal IRQs (own IRQ domain). - (See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt for + (See ../interrupt-controller/interrupts.txt for further information relating to interrupt properties) Sub-devices: -- da9150-gpadc: See Documentation/devicetree/bindings/iio/adc/da9150-gpadc.txt -- da9150-charger: See Documentation/devicetree/bindings/power/da9150-charger.txt - +- da9150-gpadc: See ../iio/adc/da9150-gpadc.txt +- da9150-charger: See ../power/da9150-charger.txt +- da9150-fg: See ../power/da9150-fg.txt Example: @@ -34,10 +35,28 @@ Example: interrupt-controller; gpadc: da9150-gpadc { - ... + compatible = "dlg,da9150-gpadc"; + #io-channel-cells = <1>; + }; + + charger { + compatible = "dlg,da9150-charger"; + + io-channels = <&gpadc 0>, + <&gpadc 2>, + <&gpadc 8>, + <&gpadc 5>; + io-channel-names = "CHAN_IBUS", + "CHAN_VBUS", + "CHAN_TJUNC", + "CHAN_VBAT"; }; - da9150-charger { - ... + fuel-gauge { + compatible = "dlg,da9150-fuel-gauge"; + + dlg,update-interval = <10000>; + dlg,warn-soc-level = /bits/ 8 <15>; + dlg,crit-soc-level = /bits/ 8 <5> }; }; diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt b/Documentation/devicetree/bindings/mfd/s2mps11.txt index 57a045016..09b94c97f 100644 --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt @@ -1,5 +1,5 @@ -* Samsung S2MPS11, S2MPS13, S2MPS14 and S2MPU02 Voltage and Current Regulator +* Samsung S2MPS11/13/14/15 and S2MPU02 Voltage and Current Regulator The Samsung S2MPS11 is a multi-function device which includes voltage and current regulators, RTC, charger controller and other sub-blocks. It is @@ -7,17 +7,28 @@ interfaced to the host controller using an I2C interface. Each sub-block is addressed by the host system using different I2C slave addresses. Required properties: -- compatible: Should be "samsung,s2mps11-pmic" or "samsung,s2mps13-pmic" - or "samsung,s2mps14-pmic" or "samsung,s2mpu02-pmic". +- compatible: Should be one of the following + - "samsung,s2mps11-pmic" + - "samsung,s2mps13-pmic" + - "samsung,s2mps14-pmic" + - "samsung,s2mps15-pmic" + - "samsung,s2mpu02-pmic". - reg: Specifies the I2C slave address of the pmic block. It should be 0x66. Optional properties: - interrupt-parent: Specifies the phandle of the interrupt controller to which the interrupts from s2mps11 are delivered to. - interrupts: Interrupt specifiers for interrupt sources. +- samsung,s2mps11-wrstbi-ground: Indicates that WRSTBI pin of PMIC is pulled + down. When the system is suspended it will always go down thus triggerring + unwanted buck warm reset (setting buck voltages to default values). +- samsung,s2mps11-acokb-ground: Indicates that ACOKB pin of S2MPS11 PMIC is + connected to the ground so the PMIC must manually set PWRHOLD bit in CTRL1 + register to turn off the power. Usually the ACOKB is pulled up to VBATT so + when PWRHOLD pin goes low, the rising ACOKB will trigger power off. Optional nodes: -- clocks: s2mps11, s2mps13 and s5m8767 provide three(AP/CP/BT) buffered 32.768 +- clocks: s2mps11, s2mps13, s2mps15 and s5m8767 provide three(AP/CP/BT) buffered 32.768 KHz outputs, so to register these as clocks with common clock framework instantiate a sub-node named "clocks". It uses the common clock binding documented in : @@ -30,12 +41,13 @@ Optional nodes: the clock which they consume. Clock ID Devices ---------------------------------------------------------- - 32KhzAP 0 S2MPS11, S2MPS13, S2MPS14, S5M8767 - 32KhzCP 1 S2MPS11, S2MPS13, S5M8767 - 32KhzBT 2 S2MPS11, S2MPS13, S2MPS14, S5M8767 + 32KhzAP 0 S2MPS11, S2MPS13, S2MPS14, S2MPS15, S5M8767 + 32KhzCP 1 S2MPS11, S2MPS13, S2MPS15, S5M8767 + 32KhzBT 2 S2MPS11, S2MPS13, S2MPS14, S2MPS15, S5M8767 - compatible: Should be one of: "samsung,s2mps11-clk", "samsung,s2mps13-clk", "samsung,s2mps14-clk", "samsung,s5m8767-clk" + The s2msp15 uses the same compatible as s2mps13, as both provides similar clocks. - regulators: The regulators of s2mps11 that have to be instantiated should be included in a sub-node named 'regulators'. Regulator nodes included in this @@ -83,6 +95,7 @@ as per the datasheet of s2mps11. - S2MPS11: 1 to 38 - S2MPS13: 1 to 40 - S2MPS14: 1 to 25 + - S2MPS15: 1 to 27 - S2MPU02: 1 to 28 - Example: LDO1, LDO2, LDO28 - BUCKn @@ -90,6 +103,7 @@ as per the datasheet of s2mps11. - S2MPS11: 1 to 10 - S2MPS13: 1 to 10 - S2MPS14: 1 to 5 + - S2MPS15: 1 to 10 - S2MPU02: 1 to 7 - Example: BUCK1, BUCK2, BUCK9 diff --git a/Documentation/devicetree/bindings/mfd/sky81452.txt b/Documentation/devicetree/bindings/mfd/sky81452.txt index 35181794a..511764acd 100644 --- a/Documentation/devicetree/bindings/mfd/sky81452.txt +++ b/Documentation/devicetree/bindings/mfd/sky81452.txt @@ -6,7 +6,7 @@ Required properties: Required child nodes: - backlight : container node for backlight following the binding - in video/backlight/sky81452-backlight.txt + in leds/backlight/sky81452-backlight.txt - regulator : container node for regulators following the binding in regulator/sky81452-regulator.txt diff --git a/Documentation/devicetree/bindings/mfd/tc3589x.txt b/Documentation/devicetree/bindings/mfd/tc3589x.txt index 37bf7f1aa..23fc2f21f 100644 --- a/Documentation/devicetree/bindings/mfd/tc3589x.txt +++ b/Documentation/devicetree/bindings/mfd/tc3589x.txt @@ -56,6 +56,7 @@ Optional nodes: bindings/input/matrix-keymap.txt - linux,no-autorepeat: do no enable autorepeat feature. - wakeup-source: use any event on keypad as wakeup event. + (Legacy property supported: "linux,wakeup") Example: diff --git a/Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt b/Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt deleted file mode 100644 index 973c27273..000000000 --- a/Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt +++ /dev/null @@ -1,98 +0,0 @@ -MIPI DSI (Display Serial Interface) busses -========================================== - -The MIPI Display Serial Interface specifies a serial bus and a protocol for -communication between a host and up to four peripherals. This document will -define the syntax used to represent a DSI bus in a device tree. - -This document describes DSI bus-specific properties only or defines existing -standard properties in the context of the DSI bus. - -Each DSI host provides a DSI bus. The DSI host controller's node contains a -set of properties that characterize the bus. Child nodes describe individual -peripherals on that bus. - -The following assumes that only a single peripheral is connected to a DSI -host. Experience shows that this is true for the large majority of setups. - -DSI host --------- - -In addition to the standard properties and those defined by the parent bus of -a DSI host, the following properties apply to a node representing a DSI host. - -Required properties: -- #address-cells: The number of cells required to represent an address on the - bus. DSI peripherals are addressed using a 2-bit virtual channel number, so - a maximum of 4 devices can be addressed on a single bus. Hence the value of - this property should be 1. -- #size-cells: Should be 0. There are cases where it makes sense to use a - different value here. See below. - -DSI peripheral --------------- - -Peripherals are represented as child nodes of the DSI host's node. Properties -described here apply to all DSI peripherals, but individual bindings may want -to define additional, device-specific properties. - -Required properties: -- reg: The virtual channel number of a DSI peripheral. Must be in the range - from 0 to 3. - -Some DSI peripherals respond to more than a single virtual channel. In that -case two alternative representations can be chosen: -- The reg property can take multiple entries, one for each virtual channel - that the peripheral responds to. -- If the virtual channels that a peripheral responds to are consecutive, the - #size-cells can be set to 1. The first cell of each entry in the reg - property is the number of the first virtual channel and the second cell is - the number of consecutive virtual channels. - -Example -------- - - dsi-host { - ... - - #address-cells = <1>; - #size-cells = <0>; - - /* peripheral responds to virtual channel 0 */ - peripheral@0 { - compatible = "..."; - reg = <0>; - }; - - ... - }; - - dsi-host { - ... - - #address-cells = <1>; - #size-cells = <0>; - - /* peripheral responds to virtual channels 0 and 2 */ - peripheral@0 { - compatible = "..."; - reg = <0, 2>; - }; - - ... - }; - - dsi-host { - ... - - #address-cells = <1>; - #size-cells = <1>; - - /* peripheral responds to virtual channels 1, 2 and 3 */ - peripheral@1 { - compatible = "..."; - reg = <1 3>; - }; - - ... - }; diff --git a/Documentation/devicetree/bindings/mipi/nvidia,tegra114-mipi.txt b/Documentation/devicetree/bindings/mipi/nvidia,tegra114-mipi.txt deleted file mode 100644 index e4a25cedc..000000000 --- a/Documentation/devicetree/bindings/mipi/nvidia,tegra114-mipi.txt +++ /dev/null @@ -1,41 +0,0 @@ -NVIDIA Tegra MIPI pad calibration controller - -Required properties: -- compatible: "nvidia,tegra-mipi" -- reg: Physical base address and length of the controller's registers. -- clocks: Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. -- clock-names: Must include the following entries: - - mipi-cal -- #nvidia,mipi-calibrate-cells: Should be 1. The cell is a bitmask of the pads - that need to be calibrated for a given device. - -User nodes need to contain an nvidia,mipi-calibrate property that has a -phandle to refer to the calibration controller node and a bitmask of the pads -that need to be calibrated. - -Example: - - mipi: mipi@700e3000 { - compatible = "nvidia,tegra114-mipi"; - reg = <0x700e3000 0x100>; - clocks = <&tegra_car TEGRA114_CLK_MIPI_CAL>; - clock-names = "mipi-cal"; - #nvidia,mipi-calibrate-cells = <1>; - }; - - ... - - host1x@50000000 { - ... - - dsi@54300000 { - ... - - nvidia,mipi-calibrate = <&mipi 0x060>; - - ... - }; - - ... - }; diff --git a/Documentation/devicetree/bindings/mips/img/xilfpga.txt b/Documentation/devicetree/bindings/mips/img/xilfpga.txt new file mode 100644 index 000000000..57e7ee942 --- /dev/null +++ b/Documentation/devicetree/bindings/mips/img/xilfpga.txt @@ -0,0 +1,83 @@ +Imagination University Program MIPSfpga +======================================= + +Under the Imagination University Program, a microAptiv UP core has been +released for academic usage. + +As we are dealing with a MIPS core instantiated on an FPGA, specifications +are fluid and can be varied in RTL. + +This binding document is provided as baseline guidance for the example +project provided by IMG. + +The example project runs on the Nexys4DDR board by Digilent powered by +the ARTIX-7 FPGA by Xilinx. + +Relevant details about the example project and the Nexys4DDR board: + +- microAptiv UP core m14Kc +- 50MHz clock speed +- 128Mbyte DDR RAM at 0x0000_0000 +- 8Kbyte RAM at 0x1000_0000 +- axi_intc at 0x1020_0000 +- axi_uart16550 at 0x1040_0000 +- axi_gpio at 0x1060_0000 +- axi_i2c at 0x10A0_0000 +- custom_gpio at 0x10C0_0000 +- axi_ethernetlite at 0x10E0_0000 +- 8Kbyte BootRAM at 0x1FC0_0000 + +Required properties: +-------------------- + - compatible: Must include "digilent,nexys4ddr","img,xilfpga". + +CPU nodes: +---------- +A "cpus" node is required. Required properties: + - #address-cells: Must be 1. + - #size-cells: Must be 0. +A CPU sub-node is also required for at least CPU 0. Required properties: + - device_type: Must be "cpu". + - compatible: Must be "mips,m14Kc". + - reg: Must be <0>. + - clocks: phandle to ext clock for fixed-clock received by MIPS core. + +Example: + + compatible = "img,xilfpga","digilent,nexys4ddr"; + cpus { + #address-cells = <1>; + #size-cells = <0>; + + cpu0: cpu@0 { + device_type = "cpu"; + compatible = "mips,m14Kc"; + reg = <0>; + clocks = <&ext>; + }; + }; + + ext: ext { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <50000000>; + }; + +Boot protocol: +-------------- + +The BootRAM is a writeable "RAM" in FPGA at 0x1FC0_0000. +This is for easy reprogrammibility via JTAG. + +The BootRAM initializes the cache and the axi_uart peripheral. + +DDR initialization is already handled by a HW IP block. + +When the example project bitstream is loaded, the cpu_reset button +needs to be pressed. + +The bootram initializes the cache and axi_uart. +Then outputs MIPSFPGA\n\r on the serial port on the Nexys4DDR board. + +At this point, the board is ready to load the Linux kernel +vmlinux file via JTAG. diff --git a/Documentation/devicetree/bindings/misc/at25.txt b/Documentation/devicetree/bindings/misc/at25.txt deleted file mode 100644 index 1d3447165..000000000 --- a/Documentation/devicetree/bindings/misc/at25.txt +++ /dev/null @@ -1,35 +0,0 @@ -EEPROMs (SPI) compatible with Atmel at25. - -Required properties: -- compatible : "atmel,at25". -- reg : chip select number -- spi-max-frequency : max spi frequency to use -- pagesize : size of the eeprom page -- size : total eeprom size in bytes -- address-width : number of address bits (one of 8, 16, or 24) - -Optional properties: -- spi-cpha : SPI shifted clock phase, as per spi-bus bindings. -- spi-cpol : SPI inverse clock polarity, as per spi-bus bindings. -- read-only : this parameter-less property disables writes to the eeprom - -Obsolete legacy properties are can be used in place of "size", "pagesize", -"address-width", and "read-only": -- at25,byte-len : total eeprom size in bytes -- at25,addr-mode : addr-mode flags, as defined in include/linux/spi/eeprom.h -- at25,page-size : size of the eeprom page - -Additional compatible properties are also allowed. - -Example: - at25@0 { - compatible = "atmel,at25", "st,m95256"; - reg = <0> - spi-max-frequency = <5000000>; - spi-cpha; - spi-cpol; - - pagesize = <64>; - size = <32768>; - address-width = <16>; - }; diff --git a/Documentation/devicetree/bindings/misc/bmp085.txt b/Documentation/devicetree/bindings/misc/bmp085.txt deleted file mode 100644 index d7a6deb6b..000000000 --- a/Documentation/devicetree/bindings/misc/bmp085.txt +++ /dev/null @@ -1,24 +0,0 @@ -BMP085/BMP18x digital pressure sensors - -Required properties: -- compatible: bosch,bmp085 - -Optional properties: -- chip-id: configurable chip id for non-default chip revisions -- temp-measurement-period: temperature measurement period (milliseconds) -- default-oversampling: default oversampling value to be used at startup, - value range is 0-3 with rising sensitivity. -- interrupt-parent: should be the phandle for the interrupt controller -- interrupts: interrupt mapping for IRQ - -Example: - -pressure@77 { - compatible = "bosch,bmp085"; - reg = <0x77>; - chip-id = <10>; - temp-measurement-period = <100>; - default-oversampling = <2>; - interrupt-parent = <&gpio0>; - interrupts = <25 IRQ_TYPE_EDGE_RISING>; -}; diff --git a/Documentation/devicetree/bindings/misc/lis302.txt b/Documentation/devicetree/bindings/misc/lis302.txt deleted file mode 100644 index 2a19bff96..000000000 --- a/Documentation/devicetree/bindings/misc/lis302.txt +++ /dev/null @@ -1,119 +0,0 @@ -LIS302 accelerometer devicetree bindings - -This device is matched via its bus drivers, and has a number of properties -that apply in on the generic device (independent from the bus). - - -Required properties for the SPI bindings: - - compatible: should be set to "st,lis3lv02d_spi" - - reg: the chipselect index - - spi-max-frequency: maximal bus speed, should be set to 1000000 unless - constrained by external circuitry - - interrupts: the interrupt generated by the device - -Required properties for the I2C bindings: - - compatible: should be set to "st,lis3lv02d" - - reg: i2c slave address - - Vdd-supply: The input supply for Vdd - - Vdd_IO-supply: The input supply for Vdd_IO - - -Optional properties for all bus drivers: - - - st,click-single-{x,y,z}: if present, tells the device to issue an - interrupt on single click events on the - x/y/z axis. - - st,click-double-{x,y,z}: if present, tells the device to issue an - interrupt on double click events on the - x/y/z axis. - - st,click-thresh-{x,y,z}: set the x/y/z axis threshold - - st,click-click-time-limit: click time limit, from 0 to 127.5msec - with step of 0.5 msec - - st,click-latency: click latency, from 0 to 255 msec with - step of 1 msec. - - st,click-window: click window, from 0 to 255 msec with - step of 1 msec. - - st,irq{1,2}-disable: disable IRQ 1/2 - - st,irq{1,2}-ff-wu-1: raise IRQ 1/2 on FF_WU_1 condition - - st,irq{1,2}-ff-wu-2: raise IRQ 1/2 on FF_WU_2 condition - - st,irq{1,2}-data-ready: raise IRQ 1/2 on data ready contition - - st,irq{1,2}-click: raise IRQ 1/2 on click condition - - st,irq-open-drain: consider IRQ lines open-drain - - st,irq-active-low: make IRQ lines active low - - st,wu-duration-1: duration register for Free-Fall/Wake-Up - interrupt 1 - - st,wu-duration-2: duration register for Free-Fall/Wake-Up - interrupt 2 - - st,wakeup-{x,y,z}-{lo,hi}: set wakeup condition on x/y/z axis for - upper/lower limit - - st,wakeup-threshold: set wakeup threshold - - st,wakeup2-{x,y,z}-{lo,hi}: set wakeup condition on x/y/z axis for - upper/lower limit for second wakeup - engine. - - st,wakeup2-threshold: set wakeup threshold for second wakeup - engine. - - st,highpass-cutoff-hz=: 1, 2, 4 or 8 for 1Hz, 2Hz, 4Hz or 8Hz of - highpass cut-off frequency - - st,hipass{1,2}-disable: disable highpass 1/2. - - st,default-rate=: set the default rate - - st,axis-{x,y,z}=: set the axis to map to the three coordinates. - Negative values can be used for inverted axis. - - st,{min,max}-limit-{x,y,z} set the min/max limits for x/y/z axis - (used by self-test) - - -Example for a SPI device node: - - lis302@0 { - compatible = "st,lis302dl-spi"; - reg = <0>; - spi-max-frequency = <1000000>; - interrupt-parent = <&gpio>; - interrupts = <104 0>; - - st,click-single-x; - st,click-single-y; - st,click-single-z; - st,click-thresh-x = <10>; - st,click-thresh-y = <10>; - st,click-thresh-z = <10>; - st,irq1-click; - st,irq2-click; - st,wakeup-x-lo; - st,wakeup-x-hi; - st,wakeup-y-lo; - st,wakeup-y-hi; - st,wakeup-z-lo; - st,wakeup-z-hi; - }; - -Example for a I2C device node: - - lis331dlh: lis331dlh@18 { - compatible = "st,lis331dlh", "st,lis3lv02d"; - reg = <0x18>; - Vdd-supply = <&lis3_reg>; - Vdd_IO-supply = <&lis3_reg>; - - st,click-single-x; - st,click-single-y; - st,click-single-z; - st,click-thresh-x = <10>; - st,click-thresh-y = <10>; - st,click-thresh-z = <10>; - st,irq1-click; - st,irq2-click; - st,wakeup-x-lo; - st,wakeup-x-hi; - st,wakeup-y-lo; - st,wakeup-y-hi; - st,wakeup-z-lo; - st,wakeup-z-hi; - st,min-limit-x = <120>; - st,min-limit-y = <120>; - st,min-limit-z = <140>; - st,max-limit-x = <550>; - st,max-limit-y = <550>; - st,max-limit-z = <750>; - }; - diff --git a/Documentation/devicetree/bindings/misc/sram.txt b/Documentation/devicetree/bindings/misc/sram.txt index 36cbe5aea..42ee9438b 100644 --- a/Documentation/devicetree/bindings/misc/sram.txt +++ b/Documentation/devicetree/bindings/misc/sram.txt @@ -33,6 +33,12 @@ Optional properties in the area nodes: - compatible : standard definition, should contain a vendor specific string in the form ,[-] +- pool : indicates that the particular reserved SRAM area is addressable + and in use by another device or devices +- export : indicates that the reserved SRAM area may be accessed outside + of the kernel, e.g. by bootloader or userspace +- label : the name for the reserved partition, if omitted, the label + is taken from the node name excluding the unit address. Example: @@ -48,4 +54,14 @@ sram: sram@5c000000 { compatible = "socvendor,smp-sram"; reg = <0x100 0x50>; }; + + device-sram@1000 { + reg = <0x1000 0x1000>; + pool; + }; + + exported@20000 { + reg = <0x20000 0x20000>; + export; + }; }; diff --git a/Documentation/devicetree/bindings/misc/ti,dac7512.txt b/Documentation/devicetree/bindings/misc/ti,dac7512.txt deleted file mode 100644 index 1db45939d..000000000 --- a/Documentation/devicetree/bindings/misc/ti,dac7512.txt +++ /dev/null @@ -1,20 +0,0 @@ -TI DAC7512 DEVICETREE BINDINGS - -Required properties: - - - "compatible" Must be set to "ti,dac7512" - -Property rules described in Documentation/devicetree/bindings/spi/spi-bus.txt -apply. In particular, "reg" and "spi-max-frequency" properties must be given. - - -Example: - - spi_master { - dac7512: dac7512@0 { - compatible = "ti,dac7512"; - reg = <0>; /* CS0 */ - spi-max-frequency = <1000000>; - }; - }; - diff --git a/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt b/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt index b7943f3f9..dedfb02c7 100644 --- a/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt +++ b/Documentation/devicetree/bindings/mmc/fsl-esdhc.txt @@ -22,6 +22,8 @@ Optional properties: - voltage-ranges : two cells are required, first cell specifies minimum slot voltage (mV), second cell specifies maximum slot voltage (mV). Several ranges could be specified. + - little-endian : If the host controller is little-endian mode, specify + this property. The default endian mode is big-endian. Example: diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt index 0384fc3f6..ed23b9bed 100644 --- a/Documentation/devicetree/bindings/mmc/mmc.txt +++ b/Documentation/devicetree/bindings/mmc/mmc.txt @@ -37,6 +37,7 @@ Optional properties: - sd-uhs-sdr104: SD UHS SDR104 speed is supported - sd-uhs-ddr50: SD UHS DDR50 speed is supported - cap-power-off-card: powering off the card is safe +- cap-mmc-hw-reset: eMMC hardware reset is supported - cap-sdio-irq: enable SDIO IRQ signalling on this interface - full-pwr-cycle: full power cycle of the card is supported - mmc-ddr-1_8v: eMMC high-speed DDR mode(1.8V I/O) is supported @@ -67,7 +68,8 @@ polarity is in effect. Optional SDIO properties: - keep-power-in-suspend: Preserves card power during a suspend/resume cycle -- enable-sdio-wakeup: Enables wake up of host system on SDIO IRQ assertion +- wakeup-source: Enables wake up of host system on SDIO IRQ assertion + (Legacy property supported: "enable-sdio-wakeup") MMC power sequences: @@ -117,7 +119,7 @@ sdhci@ab000000 { wp-gpios = <&gpio 70 0>; max-frequency = <50000000>; keep-power-in-suspend; - enable-sdio-wakeup; + wakeup-source; mmc-pwrseq = <&sdhci0_pwrseq> } diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt b/Documentation/devicetree/bindings/mmc/mtk-sd.txt index a1adfa495..0120c7f11 100644 --- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt @@ -17,6 +17,11 @@ Required properties: - vmmc-supply: power to the Core - vqmmc-supply: power to the IO +Optional properties: +- assigned-clocks: PLL of the source clock +- assigned-clock-parents: parent of source clock, used for HS400 mode to get 400Mhz source clock +- hs400-ds-delay: HS400 DS delay setting + Examples: mmc0: mmc@11230000 { compatible = "mediatek,mt8173-mmc", "mediatek,mt8135-mmc"; @@ -24,9 +29,13 @@ mmc0: mmc@11230000 { interrupts = ; vmmc-supply = <&mt6397_vemc_3v3_reg>; vqmmc-supply = <&mt6397_vio18_reg>; - clocks = <&pericfg CLK_PERI_MSDC30_0>, <&topckgen CLK_TOP_MSDC50_0_H_SEL>; + clocks = <&pericfg CLK_PERI_MSDC30_0>, + <&topckgen CLK_TOP_MSDC50_0_H_SEL>; clock-names = "source", "hclk"; pinctrl-names = "default", "state_uhs"; pinctrl-0 = <&mmc0_pins_default>; pinctrl-1 = <&mmc0_pins_uhs>; + assigned-clocks = <&topckgen CLK_TOP_MSDC50_0_SEL>; + assigned-clock-parents = <&topckgen CLK_TOP_MSDCPLL_D2>; + hs400-ds-delay = <0x14015>; }; diff --git a/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt b/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt index d38942f6c..cae29eb57 100644 --- a/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt +++ b/Documentation/devicetree/bindings/mmc/renesas,mmcif.txt @@ -6,11 +6,12 @@ and the properties used by the MMCIF device. Required properties: -- compatible: must contain one of the following +- compatible: should be "renesas,mmcif-", "renesas,sh-mmcif" as a + fallback. Examples with are: - "renesas,mmcif-r8a7740" for the MMCIF found in r8a7740 SoCs - "renesas,mmcif-r8a7790" for the MMCIF found in r8a7790 SoCs - "renesas,mmcif-r8a7791" for the MMCIF found in r8a7791 SoCs - - "renesas,sh-mmcif" for the generic MMCIF + - "renesas,mmcif-r8a7794" for the MMCIF found in r8a7794 SoCs - clocks: reference to the functional clock diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt index c327c2d6f..3dc13b68f 100644 --- a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt +++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt @@ -14,6 +14,19 @@ Required Properties: before RK3288 - "rockchip,rk3288-dw-mshc": for Rockchip RK3288 +Optional Properties: +* clocks: from common clock binding: if ciu_drive and ciu_sample are + specified in clock-names, should contain handles to these clocks. + +* clock-names: Apart from the clock-names described in synopsys-dw-mshc.txt + two more clocks "ciu-drive" and "ciu-sample" are supported. They are used + to control the clock phases, "ciu-sample" is required for tuning high- + speed modes. + +* rockchip,default-sample-phase: The default phase to set ciu_sample at + probing, low speeds or in case where all phases work at tuning time. + If not specified 0 deg will be used. + Example: rkdwmmc0@12200000 { diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt index 346c6095a..8636f5ae9 100644 --- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt +++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt @@ -75,6 +75,12 @@ Optional properties: * vmmc-supply: The phandle to the regulator to use for vmmc. If this is specified we'll defer probe until we can find this regulator. +* dmas: List of DMA specifiers with the controller specific format as described + in the generic DMA client binding. Refer to dma.txt for details. + +* dma-names: request names for generic DMA client binding. Must be "rx-tx". + Refer to dma.txt for details. + Aliases: - All the MSHC controller nodes should be represented in the aliases node using @@ -95,6 +101,23 @@ board specific portions as listed below. #size-cells = <0>; }; +[board specific internal DMA resources] + + dwmmc0@12200000 { + clock-frequency = <400000000>; + clock-freq-min-max = <400000 200000000>; + num-slots = <1>; + broken-cd; + fifo-depth = <0x80>; + card-detect-delay = <200>; + vmmc-supply = <&buck8>; + bus-width = <8>; + cap-mmc-highspeed; + cap-sd-highspeed; + }; + +[board specific generic DMA request binding] + dwmmc0@12200000 { clock-frequency = <400000000>; clock-freq-min-max = <400000 200000000>; @@ -106,4 +129,6 @@ board specific portions as listed below. bus-width = <8>; cap-mmc-highspeed; cap-sd-highspeed; + dmas = <&pdma 12>; + dma-names = "rx-tx"; }; diff --git a/Documentation/devicetree/bindings/mtd/fsmc-nand.txt b/Documentation/devicetree/bindings/mtd/fsmc-nand.txt index 5235cbc55..32636eb77 100644 --- a/Documentation/devicetree/bindings/mtd/fsmc-nand.txt +++ b/Documentation/devicetree/bindings/mtd/fsmc-nand.txt @@ -30,6 +30,12 @@ Optional properties: command is asserted. Zero means one cycle, 255 means 256 cycles. - bank: default NAND bank to use (0-3 are valid, 0 is the default). +- nand-ecc-mode : see nand.txt +- nand-ecc-strength : see nand.txt +- nand-ecc-step-size : see nand.txt + +Can support 1-bit HW ECC (default) or if stronger correction is required, +software-based BCH. Example: diff --git a/Documentation/devicetree/bindings/mtd/partition.txt b/Documentation/devicetree/bindings/mtd/partition.txt index 8e5557da1..1c63e4065 100644 --- a/Documentation/devicetree/bindings/mtd/partition.txt +++ b/Documentation/devicetree/bindings/mtd/partition.txt @@ -4,10 +4,19 @@ Partitions can be represented by sub-nodes of an mtd device. This can be used on platforms which have strong conventions about which portions of a flash are used for what purposes, but which don't use an on-flash partition table such as RedBoot. -NOTE: if the sub-node has a compatible string, then it is not a partition. -#address-cells & #size-cells must both be present in the mtd device. There are -two valid values for both: +The partition table should be a subnode of the mtd node and should be named +'partitions'. This node should have the following property: +- compatible : (required) must be "fixed-partitions" +Partitions are then defined in subnodes of the partitions node. + +For backwards compatibility partitions as direct subnodes of the mtd device are +supported. This use is discouraged. +NOTE: also for backwards compatibility, direct subnodes that have a compatible +string are not considered partitions, as they may be used for other bindings. + +#address-cells & #size-cells must both be present in the partitions subnode of the +mtd device. There are two valid values for both: <1>: for partitions that require a single 32-bit cell to represent their size/address (aka the value is below 4 GiB) <2>: for partitions that require two 32-bit cells to represent their @@ -28,44 +37,53 @@ Examples: flash@0 { - #address-cells = <1>; - #size-cells = <1>; + partitions { + compatible = "fixed-partitions"; + #address-cells = <1>; + #size-cells = <1>; - partition@0 { - label = "u-boot"; - reg = <0x0000000 0x100000>; - read-only; - }; + partition@0 { + label = "u-boot"; + reg = <0x0000000 0x100000>; + read-only; + }; - uimage@100000 { - reg = <0x0100000 0x200000>; + uimage@100000 { + reg = <0x0100000 0x200000>; + }; }; }; flash@1 { - #address-cells = <1>; - #size-cells = <2>; + partitions { + compatible = "fixed-partitions"; + #address-cells = <1>; + #size-cells = <2>; - /* a 4 GiB partition */ - partition@0 { - label = "filesystem"; - reg = <0x00000000 0x1 0x00000000>; + /* a 4 GiB partition */ + partition@0 { + label = "filesystem"; + reg = <0x00000000 0x1 0x00000000>; + }; }; }; flash@2 { - #address-cells = <2>; - #size-cells = <2>; + partitions { + compatible = "fixed-partitions"; + #address-cells = <2>; + #size-cells = <2>; - /* an 8 GiB partition */ - partition@0 { - label = "filesystem #1"; - reg = <0x0 0x00000000 0x2 0x00000000>; - }; + /* an 8 GiB partition */ + partition@0 { + label = "filesystem #1"; + reg = <0x0 0x00000000 0x2 0x00000000>; + }; - /* a 4 GiB partition */ - partition@200000000 { - label = "filesystem #2"; - reg = <0x2 0x00000000 0x1 0x00000000>; + /* a 4 GiB partition */ + partition@200000000 { + label = "filesystem #2"; + reg = <0x2 0x00000000 0x1 0x00000000>; + }; }; }; diff --git a/Documentation/devicetree/bindings/mtd/vf610-nfc.txt b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt new file mode 100644 index 000000000..c96eeb65f --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt @@ -0,0 +1,59 @@ +Freescale's NAND flash controller (NFC) + +This variant of the Freescale NAND flash controller (NFC) can be found on +Vybrid (vf610), MPC5125, MCF54418 and Kinetis K70. + +Required properties: +- compatible: Should be set to "fsl,vf610-nfc". +- reg: address range of the NFC. +- interrupts: interrupt of the NFC. +- #address-cells: shall be set to 1. Encode the nand CS. +- #size-cells : shall be set to 0. +- assigned-clocks: main clock from the SoC, for Vybrid <&clks VF610_CLK_NFC>; +- assigned-clock-rates: The NAND bus timing is derived from this clock + rate and should not exceed maximum timing for any NAND memory chip + in a board stuffing. Typical NAND memory timings derived from this + clock are found in the SoC hardware reference manual. Furthermore, + there might be restrictions on maximum rates when using hardware ECC. + +- #address-cells, #size-cells : Must be present if the device has sub-nodes + representing partitions. + +Required children nodes: +Children nodes represent the available nand chips. Currently the driver can +only handle one NAND chip. + +Required properties: +- compatible: Should be set to "fsl,vf610-nfc-cs". +- nand-bus-width: see nand.txt +- nand-ecc-mode: see nand.txt + +Required properties for hardware ECC: +- nand-ecc-strength: supported strengths are 24 and 32 bit (see nand.txt) +- nand-ecc-step-size: step size equals page size, currently only 2k pages are + supported +- nand-on-flash-bbt: see nand.txt + +Example: + + nfc: nand@400e0000 { + compatible = "fsl,vf610-nfc"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x400e0000 0x4000>; + interrupts = ; + clocks = <&clks VF610_CLK_NFC>; + clock-names = "nfc"; + assigned-clocks = <&clks VF610_CLK_NFC>; + assigned-clock-rates = <33000000>; + + nand@0 { + compatible = "fsl,vf610-nfc-nandcs"; + reg = <0>; + nand-bus-width = <8>; + nand-ecc-mode = "hw"; + nand-ecc-strength = <32>; + nand-ecc-step-size = <2048>; + nand-on-flash-bbt; + }; + }; diff --git a/Documentation/devicetree/bindings/net/apm-xgene-enet.txt b/Documentation/devicetree/bindings/net/apm-xgene-enet.txt index f55aa280d..078060a97 100644 --- a/Documentation/devicetree/bindings/net/apm-xgene-enet.txt +++ b/Documentation/devicetree/bindings/net/apm-xgene-enet.txt @@ -37,6 +37,14 @@ Required properties for ethernet interfaces that have external PHY: Optional properties: - status: Should be "ok" or "disabled" for enabled/disabled. Default is "ok". +- tx-delay: Delay value for RGMII bridge TX clock. + Valid values are between 0 to 7, that maps to + 417, 717, 1020, 1321, 1611, 1913, 2215, 2514 ps + Default value is 4, which corresponds to 1611 ps +- rx-delay: Delay value for RGMII bridge RX clock. + Valid values are between 0 to 7, that maps to + 273, 589, 899, 1222, 1480, 1806, 2147, 2464 ps + Default value is 2, which corresponds to 899 ps Example: menetclk: menetclk { @@ -72,5 +80,7 @@ Example: /* Board-specific peripheral configurations */ &menet { + tx-delay = <4>; + rx-delay = <2>; status = "ok"; }; diff --git a/Documentation/devicetree/bindings/net/brcm,iproc-mdio.txt b/Documentation/devicetree/bindings/net/brcm,iproc-mdio.txt new file mode 100644 index 000000000..8ba9ed11d --- /dev/null +++ b/Documentation/devicetree/bindings/net/brcm,iproc-mdio.txt @@ -0,0 +1,23 @@ +* Broadcom iProc MDIO bus controller + +Required properties: +- compatible: should be "brcm,iproc-mdio" +- reg: address and length of the register set for the MDIO interface +- #size-cells: must be 1 +- #address-cells: must be 0 + +Child nodes of this MDIO bus controller node are standard Ethernet PHY device +nodes as described in Documentation/devicetree/bindings/net/phy.txt + +Example: + +mdio@18002000 { + compatible = "brcm,iproc-mdio"; + reg = <0x18002000 0x8>; + #size-cells = <1>; + #address-cells = <0>; + + enet-gphy@0 { + reg = <0>; + }; +}; diff --git a/Documentation/devicetree/bindings/net/can/sun4i_can.txt b/Documentation/devicetree/bindings/net/can/sun4i_can.txt new file mode 100644 index 000000000..84ed1909d --- /dev/null +++ b/Documentation/devicetree/bindings/net/can/sun4i_can.txt @@ -0,0 +1,36 @@ +Allwinner A10/A20 CAN controller Device Tree Bindings +----------------------------------------------------- + +Required properties: +- compatible: "allwinner,sun4i-a10-can" +- reg: physical base address and size of the Allwinner A10/A20 CAN register map. +- interrupts: interrupt specifier for the sole interrupt. +- clock: phandle and clock specifier. + +Example +------- + +SoC common .dtsi file: + + can0_pins_a: can0@0 { + allwinner,pins = "PH20","PH21"; + allwinner,function = "can"; + allwinner,drive = <0>; + allwinner,pull = <0>; + }; +... + can0: can@01c2bc00 { + compatible = "allwinner,sun4i-a10-can"; + reg = <0x01c2bc00 0x400>; + interrupts = <0 26 4>; + clocks = <&apb1_gates 4>; + status = "disabled"; + }; + +Board specific .dts file: + + can0: can@01c2bc00 { + pinctrl-names = "default"; + pinctrl-0 = <&can0_pins_a>; + status = "okay"; + }; diff --git a/Documentation/devicetree/bindings/net/cpsw.txt b/Documentation/devicetree/bindings/net/cpsw.txt index a2cae4eb4..28a4781ab 100644 --- a/Documentation/devicetree/bindings/net/cpsw.txt +++ b/Documentation/devicetree/bindings/net/cpsw.txt @@ -30,17 +30,29 @@ Optional properties: - dual_emac : Specifies Switch to act as Dual EMAC - syscon : Phandle to the system control device node, which is the control module device of the am33x +- mode-gpios : Should be added if one/multiple gpio lines are + required to be driven so that cpsw data lines + can be connected to the phy via selective mux. + For example in dra72x-evm, pcf gpio has to be + driven low so that cpsw slave 0 and phy data + lines are connected via mux. + Slave Properties: Required properties: -- phy_id : Specifies slave phy id - phy-mode : See ethernet.txt file in the same directory Optional properties: - dual_emac_res_vlan : Specifies VID to be used to segregate the ports - mac-address : See ethernet.txt file in the same directory +- phy_id : Specifies slave phy id - phy-handle : See ethernet.txt file in the same directory +Slave sub-nodes: +- fixed-link : See fixed-link.txt file in the same directory + Either the property phy_id, or the sub-node + fixed-link can be specified + Note: "ti,hwmods" field is used to fetch the base address and irq resources from TI, omap hwmod data base during device registration. Future plan is to migrate hwmod data base contents into device tree diff --git a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt index 1e97532a0..db74f0dc2 100644 --- a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt +++ b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt @@ -57,6 +57,10 @@ Properties: "rgmii-id", as all other connection types are detected by hardware. - fsl,magic-packet : If present, indicates that the hardware supports waking up via magic packet. + - fsl,wake-on-filer : If present, indicates that the hardware supports + waking up by Filer General Purpose Interrupt (FGPI) asserted on the + Rx int line. This is an advanced power management capability allowing + certain packet types (user) defined by filer rules to wake up the system. - bd-stash : If present, indicates that the hardware supports stashing buffer descriptors in the L2. - rx-stash-len : Denotes the number of bytes of a received buffer to stash diff --git a/Documentation/devicetree/bindings/net/hisilicon-hip04-net.txt b/Documentation/devicetree/bindings/net/hisilicon-hip04-net.txt index 988fc694b..d1df8a00e 100644 --- a/Documentation/devicetree/bindings/net/hisilicon-hip04-net.txt +++ b/Documentation/devicetree/bindings/net/hisilicon-hip04-net.txt @@ -32,13 +32,13 @@ Required properties: Required properties: -- compatible: should be "hisilicon,hip04-mdio". +- compatible: should be "hisilicon,mdio". - Inherits from MDIO bus node binding [2] [2] Documentation/devicetree/bindings/net/phy.txt Example: mdio { - compatible = "hisilicon,hip04-mdio"; + compatible = "hisilicon,mdio"; reg = <0x28f1000 0x1000>; #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt b/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt new file mode 100644 index 000000000..80411b2f0 --- /dev/null +++ b/Documentation/devicetree/bindings/net/hisilicon-hns-dsaf.txt @@ -0,0 +1,49 @@ +Hisilicon DSA Fabric device controller + +Required properties: +- compatible: should be "hisilicon,hns-dsaf-v1" or "hisilicon,hns-dsaf-v2". + "hisilicon,hns-dsaf-v1" is for hip05. + "hisilicon,hns-dsaf-v2" is for Hi1610 and Hi1612. +- dsa-name: dsa fabric name who provide this interface. + should be "dsafX", X is the dsaf id. +- mode: dsa fabric mode string. only support one of dsaf modes like these: + "2port-64vf", + "6port-16rss", + "6port-16vf". +- interrupt-parent: the interrupt parent of this device. +- interrupts: should contain the DSA Fabric and rcb interrupt. +- reg: specifies base physical address(es) and size of the device registers. + The first region is external interface control register base and size. + The second region is SerDes base register and size. + The third region is the PPE register base and size. + The fourth region is dsa fabric base register and size. + The fifth region is cpld base register and size, it is not required if do not use cpld. +- phy-handle: phy handle of physicl port, 0 if not any phy device. see ethernet.txt [1]. +- buf-size: rx buffer size, should be 16-1024. +- desc-num: number of description in TX and RX queue, should be 512, 1024, 2048 or 4096. + +[1] Documentation/devicetree/bindings/net/phy.txt + +Example: + +dsa: dsa@c7000000 { + compatible = "hisilicon,hns-dsaf-v1"; + dsa_name = "dsaf0"; + mode = "6port-16rss"; + interrupt-parent = <&mbigen_dsa>; + reg = <0x0 0xC0000000 0x0 0x420000 + 0x0 0xC2000000 0x0 0x300000 + 0x0 0xc5000000 0x0 0x890000 + 0x0 0xc7000000 0x0 0x60000>; + phy-handle = <0 0 0 0 &soc0_phy4 &soc0_phy5 0 0>; + interrupts = <131 4>,<132 4>, <133 4>,<134 4>, + <135 4>,<136 4>, <137 4>,<138 4>, + <139 4>,<140 4>, <141 4>,<142 4>, + <143 4>,<144 4>, <145 4>,<146 4>, + <147 4>,<148 4>, <384 1>,<385 1>, + <386 1>,<387 1>, <388 1>,<389 1>, + <390 1>,<391 1>, + buf-size = <4096>; + desc-num = <1024>; + dma-coherent; +}; diff --git a/Documentation/devicetree/bindings/net/hisilicon-hns-mdio.txt b/Documentation/devicetree/bindings/net/hisilicon-hns-mdio.txt new file mode 100644 index 000000000..9c23fdf25 --- /dev/null +++ b/Documentation/devicetree/bindings/net/hisilicon-hns-mdio.txt @@ -0,0 +1,22 @@ +Hisilicon MDIO bus controller + +Properties: +- compatible: "hisilicon,mdio","hisilicon,hns-mdio". +- reg: The base address of the MDIO bus controller register bank. +- #address-cells: Must be <1>. +- #size-cells: Must be <0>. MDIO addresses have no size component. + +Typically an MDIO bus might have several children. + +Example: + mdio@803c0000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "hisilicon,hns-mdio","hisilicon,mdio"; + reg = <0x0 0x803c0000 0x0 0x10000>; + + ethernet-phy@0 { + ... + reg = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt b/Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt new file mode 100644 index 000000000..41d19be70 --- /dev/null +++ b/Documentation/devicetree/bindings/net/hisilicon-hns-nic.txt @@ -0,0 +1,47 @@ +Hisilicon Network Subsystem NIC controller + +Required properties: +- compatible: "hisilicon,hns-nic-v1" or "hisilicon,hns-nic-v2". + "hisilicon,hns-nic-v1" is for hip05. + "hisilicon,hns-nic-v2" is for Hi1610 and Hi1612. +- ae-name: accelerator name who provides this interface, + is simply a name referring to the name of name in the accelerator node. +- port-id: is the index of port provided by DSAF (the accelerator). DSAF can + connect to 8 PHYs. Port 0 to 1 are both used for adminstration purpose. They + are called debug ports. + + The remaining 6 PHYs are taken according to the mode of DSAF. + + In NIC mode of DSAF, all 6 PHYs are taken as ethernet ports to the CPU. The + port-id can be 2 to 7. Here is the diagram: + +-----+---------------+ + | CPU | + +-+-+-+---+-+-+-+-+-+-+ + | | | | | | | | + debug service + port port + (0,1) (2-7) + + In Switch mode of DSAF, all 6 PHYs are taken as physical ports connect to a + LAN Switch while the CPU side assume itself have one single NIC connect to + this switch. In this case, the port-id will be 2 only. + +-----+---------------+ + | CPU | + +-+-+-+---+-+-+-+-+-+-+ + | | service| port(2) + debug +------------+ + port | switch | + (0,1) +-+-+-+-+-+-++ + | | | | | | + external port + +- local-mac-address: mac addr of the ethernet interface + +Example: + + ethernet@0{ + compatible = "hisilicon,hns-nic-v1"; + ae-name = "dsaf0"; + port-id = <0>; + local-mac-address = [a2 14 e4 4b 56 76]; + }; diff --git a/Documentation/devicetree/bindings/net/ieee802154/mrf24j40.txt b/Documentation/devicetree/bindings/net/ieee802154/mrf24j40.txt new file mode 100644 index 000000000..a4ed2efb5 --- /dev/null +++ b/Documentation/devicetree/bindings/net/ieee802154/mrf24j40.txt @@ -0,0 +1,20 @@ +* MRF24J40 IEEE 802.15.4 * + +Required properties: + - compatible: should be "microchip,mrf24j40", "microchip,mrf24j40ma", + or "microchip,mrf24j40mc" depends on your transceiver + board + - spi-max-frequency: maximal bus speed, should be set something under or equal + 10000000 + - reg: the chipselect index + - interrupts: the interrupt generated by the device. + +Example: + + mrf24j40ma@0 { + compatible = "microchip,mrf24j40ma"; + spi-max-frequency = <8500000>; + reg = <0>; + interrupts = <19 8>; + interrupt-parent = <&gpio3>; + }; diff --git a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt index f5a8ca29a..aeea50c84 100644 --- a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt +++ b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt @@ -8,6 +8,11 @@ Required properties: - phy-mode: See ethernet.txt file in the same directory - clocks: a pointer to the reference clock for this device. +Optional properties: +- tx-csum-limit: maximum mtu supported by port that allow TX checksum. + Value is presented in bytes. If not used, by default 1600B is set for + "marvell,armada-370-neta" and 9800B for others. + Example: ethernet@d0070000 { @@ -15,6 +20,7 @@ ethernet@d0070000 { reg = <0xd0070000 0x2500>; interrupts = <8>; clocks = <&gate_clk 4>; + tx-csum-limit = <9800> status = "okay"; phy = <&phy0>; phy-mode = "rgmii-id"; diff --git a/Documentation/devicetree/bindings/net/maxim,ds26522.txt b/Documentation/devicetree/bindings/net/maxim,ds26522.txt new file mode 100644 index 000000000..ee8bb725f --- /dev/null +++ b/Documentation/devicetree/bindings/net/maxim,ds26522.txt @@ -0,0 +1,13 @@ +* Maxim (Dallas) DS26522 Dual T1/E1/J1 Transceiver + +Required properties: +- compatible: Should contain "maxim,ds26522". +- reg: SPI CS. +- spi-max-frequency: SPI clock. + +Example: + slic@1 { + compatible = "maxim,ds26522"; + reg = <1>; + spi-max-frequency = <2000000>; /* input clock */ + }; diff --git a/Documentation/devicetree/bindings/net/nfc/nfcmrvl.txt b/Documentation/devicetree/bindings/net/nfc/nfcmrvl.txt index 7c4a0cc37..76df91738 100644 --- a/Documentation/devicetree/bindings/net/nfc/nfcmrvl.txt +++ b/Documentation/devicetree/bindings/net/nfc/nfcmrvl.txt @@ -1,7 +1,10 @@ * Marvell International Ltd. NCI NFC Controller Required properties: -- compatible: Should be "mrvl,nfc-uart". +- compatible: Should be: + - "marvell,nfc-uart" or "mrvl,nfc-uart" for UART devices + - "marvell,nfc-i2c" for I2C devices + - "marvell,nfc-spi" for SPI devices Optional SoC specific properties: - pinctrl-names: Contains only one value - "default". @@ -13,13 +16,19 @@ Optional UART-based chip specific properties: - flow-control: Specifies that the chip is using RTS/CTS. - break-control: Specifies that the chip needs specific break management. +Optional I2C-based chip specific properties: +- i2c-int-falling: Specifies that the chip read event shall be trigged on + falling edge. +- i2c-int-rising: Specifies that the chip read event shall be trigged on + rising edge. + Example (for ARM-based BeagleBoard Black with 88W8887 on UART5): &uart5 { status = "okay"; nfcmrvluart: nfcmrvluart@5 { - compatible = "mrvl,nfc-uart"; + compatible = "marvell,nfc-uart"; reset-n-io = <&gpio3 16 0>; @@ -27,3 +36,51 @@ Example (for ARM-based BeagleBoard Black with 88W8887 on UART5): flow-control; } }; + + +Example (for ARM-based BeagleBoard Black with 88W8887 on I2C1): + +&i2c1 { + status = "okay"; + clock-frequency = <400000>; + + nfcmrvli2c0: i2c@1 { + compatible = "marvell,nfc-i2c"; + + reg = <0x8>; + + /* I2C INT configuration */ + interrupt-parent = <&gpio3>; + interrupts = <21 0>; + + /* I2C INT trigger configuration */ + i2c-int-rising; + + /* Reset IO */ + reset-n-io = <&gpio3 19 0>; + }; +}; + + +Example (for ARM-based BeagleBoard Black on SPI0): + +&spi0 { + + mrvlnfcspi0: spi@0 { + compatible = "marvell,nfc-spi"; + + reg = <0>; + + /* SPI Bus configuration */ + spi-max-frequency = <3000000>; + spi-cpha; + spi-cpol; + + /* SPI INT configuration */ + interrupt-parent = <&gpio1>; + interrupts = <17 0>; + + /* Reset IO */ + reset-n-io = <&gpio3 19 0>; + }; +}; diff --git a/Documentation/devicetree/bindings/net/nfc/st-nci-i2c.txt b/Documentation/devicetree/bindings/net/nfc/st-nci-i2c.txt index d707588ed..263732e88 100644 --- a/Documentation/devicetree/bindings/net/nfc/st-nci-i2c.txt +++ b/Documentation/devicetree/bindings/net/nfc/st-nci-i2c.txt @@ -11,6 +11,10 @@ Required properties: Optional SoC Specific Properties: - pinctrl-names: Contains only one value - "default". - pintctrl-0: Specifies the pin control groups used for this controller. +- ese-present: Specifies that an ese is physically connected to the nfc +controller. +- uicc-present: Specifies that the uicc swp signal can be physically +connected to the nfc controller. Example (for ARM-based BeagleBoard xM with ST21NFCB on I2C2): @@ -29,5 +33,8 @@ Example (for ARM-based BeagleBoard xM with ST21NFCB on I2C2): interrupts = <2 IRQ_TYPE_LEVEL_HIGH>; reset-gpios = <&gpio5 29 GPIO_ACTIVE_HIGH>; + + ese-present; + uicc-present; }; }; diff --git a/Documentation/devicetree/bindings/net/nfc/st-nci-spi.txt b/Documentation/devicetree/bindings/net/nfc/st-nci-spi.txt index 525681b6d..711ca85a3 100644 --- a/Documentation/devicetree/bindings/net/nfc/st-nci-spi.txt +++ b/Documentation/devicetree/bindings/net/nfc/st-nci-spi.txt @@ -2,7 +2,7 @@ Required properties: - compatible: Should be "st,st21nfcb-spi" -- spi-max-frequency: Maximum SPI frequency (<= 10000000). +- spi-max-frequency: Maximum SPI frequency (<= 4000000). - interrupt-parent: phandle for the interrupt gpio controller - interrupts: GPIO interrupt to which the chip is connected - reset-gpios: Output GPIO pin used to reset the ST21NFCB @@ -10,6 +10,10 @@ Required properties: Optional SoC Specific Properties: - pinctrl-names: Contains only one value - "default". - pintctrl-0: Specifies the pin control groups used for this controller. +- ese-present: Specifies that an ese is physically connected to the nfc +controller. +- uicc-present: Specifies that the uicc swp signal can be physically +connected to the nfc controller. Example (for ARM-based BeagleBoard xM with ST21NFCB on SPI4): @@ -27,5 +31,8 @@ Example (for ARM-based BeagleBoard xM with ST21NFCB on SPI4): interrupts = <2 IRQ_TYPE_EDGE_RISING>; reset-gpios = <&gpio5 29 GPIO_ACTIVE_HIGH>; + + ese-present; + uicc-present; }; }; diff --git a/Documentation/devicetree/bindings/net/renesas,ravb.txt b/Documentation/devicetree/bindings/net/renesas,ravb.txt index 1fd883143..b486f3f5f 100644 --- a/Documentation/devicetree/bindings/net/renesas,ravb.txt +++ b/Documentation/devicetree/bindings/net/renesas,ravb.txt @@ -6,8 +6,12 @@ interface contains. Required properties: - compatible: "renesas,etheravb-r8a7790" if the device is a part of R8A7790 SoC. "renesas,etheravb-r8a7794" if the device is a part of R8A7794 SoC. + "renesas,etheravb-r8a7795" if the device is a part of R8A7795 SoC. - reg: offset and length of (1) the register block and (2) the stream buffer. -- interrupts: interrupt specifier for the sole interrupt. +- interrupts: A list of interrupt-specifiers, one for each entry in + interrupt-names. + If interrupt-names is not present, an interrupt specifier + for a single muxed interrupt. - phy-mode: see ethernet.txt file in the same directory. - phy-handle: see ethernet.txt file in the same directory. - #address-cells: number of address cells for the MDIO bus, must be equal to 1. @@ -18,6 +22,12 @@ Required properties: Optional properties: - interrupt-parent: the phandle for the interrupt controller that services interrupts for this device. +- interrupt-names: A list of interrupt names. + For the R8A7795 SoC this property is mandatory; + it should include one entry per channel, named "ch%u", + where %u is the channel number ranging from 0 to 24. + For other SoCs this property is optional; if present + it should contain "mux" for a single muxed interrupt. - pinctrl-names: pin configuration state name ("default"). - renesas,no-ether-link: boolean, specify when a board does not provide a proper AVB_LINK signal. @@ -27,13 +37,46 @@ Optional properties: Example: ethernet@e6800000 { - compatible = "renesas,etheravb-r8a7790"; - reg = <0 0xe6800000 0 0x800>, <0 0xee0e8000 0 0x4000>; + compatible = "renesas,etheravb-r8a7795"; + reg = <0 0xe6800000 0 0x800>, <0 0xe6a00000 0 0x10000>; interrupt-parent = <&gic>; - interrupts = <0 163 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&mstp8_clks R8A7790_CLK_ETHERAVB>; - phy-mode = "rmii"; + interrupts = , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + ; + interrupt-names = "ch0", "ch1", "ch2", "ch3", + "ch4", "ch5", "ch6", "ch7", + "ch8", "ch9", "ch10", "ch11", + "ch12", "ch13", "ch14", "ch15", + "ch16", "ch17", "ch18", "ch19", + "ch20", "ch21", "ch22", "ch23", + "ch24"; + clocks = <&mstp8_clks R8A7795_CLK_ETHERAVB>; + power-domains = <&cpg_clocks>; + phy-mode = "rgmii-id"; phy-handle = <&phy0>; + pinctrl-0 = <ðer_pins>; pinctrl-names = "default"; renesas,no-ether-link; @@ -41,8 +84,20 @@ Example: #size-cells = <0>; phy0: ethernet-phy@0 { + rxc-skew-ps = <900>; + rxdv-skew-ps = <0>; + rxd0-skew-ps = <0>; + rxd1-skew-ps = <0>; + rxd2-skew-ps = <0>; + rxd3-skew-ps = <0>; + txc-skew-ps = <900>; + txen-skew-ps = <0>; + txd0-skew-ps = <0>; + txd1-skew-ps = <0>; + txd2-skew-ps = <0>; + txd3-skew-ps = <0>; reg = <0>; interrupt-parent = <&gpio2>; - interrupts = <15 IRQ_TYPE_LEVEL_LOW>; + interrupts = <11 IRQ_TYPE_LEVEL_LOW>; }; }; diff --git a/Documentation/devicetree/bindings/nvec/nvidia,nvec.txt b/Documentation/devicetree/bindings/nvec/nvidia,nvec.txt deleted file mode 100644 index 5ae601e7f..000000000 --- a/Documentation/devicetree/bindings/nvec/nvidia,nvec.txt +++ /dev/null @@ -1,21 +0,0 @@ -NVIDIA compliant embedded controller - -Required properties: -- compatible : should be "nvidia,nvec". -- reg : the iomem of the i2c slave controller -- interrupts : the interrupt line of the i2c slave controller -- clock-frequency : the frequency of the i2c bus -- gpios : the gpio used for ec request -- slave-addr: the i2c address of the slave controller -- clocks : Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. -- clock-names : Must include the following entries: - Tegra20/Tegra30: - - div-clk - - fast-clk - Tegra114: - - div-clk -- resets : Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. -- reset-names : Must include the following entries: - - i2c diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt new file mode 100644 index 000000000..383d5889e --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt @@ -0,0 +1,20 @@ +Freescale i.MX6 On-Chip OTP Controller (OCOTP) device tree bindings + +This binding represents the on-chip eFuse OTP controller found on +i.MX6Q/D, i.MX6DL/S, i.MX6SL, and i.MX6SX SoCs. + +Required properties: +- compatible: should be one of + "fsl,imx6q-ocotp" (i.MX6Q/D/DL/S), + "fsl,imx6sl-ocotp" (i.MX6SL), or + "fsl,imx6sx-ocotp" (i.MX6SX), followed by "syscon". +- reg: Should contain the register base and length. +- clocks: Should contain a phandle pointing to the gated peripheral clock. + +Example: + + ocotp: ocotp@021bc000 { + compatible = "fsl,imx6q-ocotp", "syscon"; + reg = <0x021bc000 0x4000>; + clocks = <&clks IMX6QDL_CLK_IIM>; + }; diff --git a/Documentation/devicetree/bindings/nvmem/mxs-ocotp.txt b/Documentation/devicetree/bindings/nvmem/mxs-ocotp.txt new file mode 100644 index 000000000..daebce9e6 --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/mxs-ocotp.txt @@ -0,0 +1,25 @@ +On-Chip OTP Memory for Freescale i.MX23/i.MX28 + +Required properties : +- compatible : + - "fsl,imx23-ocotp" for i.MX23 + - "fsl,imx28-ocotp" for i.MX28 +- #address-cells : Should be 1 +- #size-cells : Should be 1 +- reg : Address and length of OTP controller registers +- clocks : Should contain a reference to the hbus clock + += Data cells = +Are child nodes of mxs-ocotp, bindings of which as described in +bindings/nvmem/nvmem.txt + +Example for i.MX28: + + ocotp: ocotp@8002c000 { + compatible = "fsl,imx28-ocotp", "fsl,ocotp"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0x8002c000 0x2000>; + clocks = <&clks 25>; + status = "okay"; + }; diff --git a/Documentation/devicetree/bindings/nvmem/rockchip-efuse.txt b/Documentation/devicetree/bindings/nvmem/rockchip-efuse.txt new file mode 100644 index 000000000..8f86ab3b1 --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/rockchip-efuse.txt @@ -0,0 +1,38 @@ += Rockchip eFuse device tree bindings = + +Required properties: +- compatible: Should be "rockchip,rockchip-efuse" +- reg: Should contain the registers location and exact eFuse size +- clocks: Should be the clock id of eFuse +- clock-names: Should be "pclk_efuse" + += Data cells = +Are child nodes of eFuse, bindings of which as described in +bindings/nvmem/nvmem.txt + +Example: + + efuse: efuse@ffb40000 { + compatible = "rockchip,rockchip-efuse"; + reg = <0xffb40000 0x20>; + #address-cells = <1>; + #size-cells = <1>; + clocks = <&cru PCLK_EFUSE256>; + clock-names = "pclk_efuse"; + + /* Data cells */ + cpu_leakage: cpu_leakage { + reg = <0x17 0x1>; + }; + }; + += Data consumers = +Are device nodes which consume nvmem data cells. + +Example: + + cpu_leakage { + ... + nvmem-cells = <&cpu_leakage>; + nvmem-cell-names = "cpu_leakage"; + }; diff --git a/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt b/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt new file mode 100644 index 000000000..56ed481c3 --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/vf610-ocotp.txt @@ -0,0 +1,19 @@ +On-Chip OTP Memory for Freescale Vybrid + +Required Properties: + compatible: + - "fsl,vf610-ocotp" for VF5xx/VF6xx + #address-cells : Should be 1 + #size-cells : Should be 1 + reg : Address and length of OTP controller and fuse map registers + clocks : ipg clock we associate with the OCOTP peripheral + +Example for Vybrid VF5xx/VF6xx: + + ocotp: ocotp@400a5000 { + compatible = "fsl,vf610-ocotp"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0x400a5000 0xCF0>; + clocks = <&clks VF610_CLK_OCOTP>; + }; diff --git a/Documentation/devicetree/bindings/open-pic.txt b/Documentation/devicetree/bindings/open-pic.txt deleted file mode 100644 index 909a902df..000000000 --- a/Documentation/devicetree/bindings/open-pic.txt +++ /dev/null @@ -1,98 +0,0 @@ -* Open PIC Binding - -This binding specifies what properties must be available in the device tree -representation of an Open PIC compliant interrupt controller. This binding is -based on the binding defined for Open PIC in [1] and is a superset of that -binding. - -Required properties: - - NOTE: Many of these descriptions were paraphrased here from [1] to aid - readability. - - - compatible: Specifies the compatibility list for the PIC. The type - shall be and the value shall include "open-pic". - - - reg: Specifies the base physical address(s) and size(s) of this - PIC's addressable register space. The type shall be . - - - interrupt-controller: The presence of this property identifies the node - as an Open PIC. No property value shall be defined. - - - #interrupt-cells: Specifies the number of cells needed to encode an - interrupt source. The type shall be a and the value shall be 2. - - - #address-cells: Specifies the number of cells needed to encode an - address. The type shall be and the value shall be 0. As such, - 'interrupt-map' nodes do not have to specify a parent unit address. - -Optional properties: - - - pic-no-reset: The presence of this property indicates that the PIC - shall not be reset during runtime initialization. No property value shall - be defined. The presence of this property also mandates that any - initialization related to interrupt sources shall be limited to sources - explicitly referenced in the device tree. - -* Interrupt Specifier Definition - - Interrupt specifiers consists of 2 cells encoded as - follows: - - - <1st-cell>: The interrupt-number that identifies the interrupt source. - - - <2nd-cell>: The level-sense information, encoded as follows: - 0 = low-to-high edge triggered - 1 = active low level-sensitive - 2 = active high level-sensitive - 3 = high-to-low edge triggered - -* Examples - -Example 1: - - /* - * An Open PIC interrupt controller - */ - mpic: pic@40000 { - // This is an interrupt controller node. - interrupt-controller; - - // No address cells so that 'interrupt-map' nodes which reference - // this Open PIC node do not need a parent address specifier. - #address-cells = <0>; - - // Two cells to encode interrupt sources. - #interrupt-cells = <2>; - - // Offset address of 0x40000 and size of 0x40000. - reg = <0x40000 0x40000>; - - // Compatible with Open PIC. - compatible = "open-pic"; - - // The PIC shall not be reset. - pic-no-reset; - }; - -Example 2: - - /* - * An interrupt generating device that is wired to an Open PIC. - */ - serial0: serial@4500 { - // Interrupt source '42' that is active high level-sensitive. - // Note that there are only two cells as specified in the interrupt - // parent's '#interrupt-cells' property. - interrupts = <42 2>; - - // The interrupt controller that this device is wired to. - interrupt-parent = <&mpic>; - }; - -* References - -[1] Power.org (TM) Standard for Embedded Power Architecture (TM) Platform - Requirements (ePAPR), Version 1.0, July 2008. - (http://www.power.org/resources/downloads/Power_ePAPR_APPROVED_v1.0.pdf) - diff --git a/Documentation/devicetree/bindings/panel/ampire,am800480r3tmqwa1h.txt b/Documentation/devicetree/bindings/panel/ampire,am800480r3tmqwa1h.txt deleted file mode 100644 index 83e2cae1c..000000000 --- a/Documentation/devicetree/bindings/panel/ampire,am800480r3tmqwa1h.txt +++ /dev/null @@ -1,7 +0,0 @@ -Ampire AM-800480R3TMQW-A1H 7.0" WVGA TFT LCD panel - -Required properties: -- compatible: should be "ampire,am800480r3tmqwa1h" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/auo,b080uan01.txt b/Documentation/devicetree/bindings/panel/auo,b080uan01.txt deleted file mode 100644 index bae0e2b51..000000000 --- a/Documentation/devicetree/bindings/panel/auo,b080uan01.txt +++ /dev/null @@ -1,7 +0,0 @@ -AU Optronics Corporation 8.0" WUXGA TFT LCD panel - -Required properties: -- compatible: should be "auo,b101ean01" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/auo,b101aw03.txt b/Documentation/devicetree/bindings/panel/auo,b101aw03.txt deleted file mode 100644 index 72e088a4f..000000000 --- a/Documentation/devicetree/bindings/panel/auo,b101aw03.txt +++ /dev/null @@ -1,7 +0,0 @@ -AU Optronics Corporation 10.1" WSVGA TFT LCD panel - -Required properties: -- compatible: should be "auo,b101aw03" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/auo,b101ean01.txt b/Documentation/devicetree/bindings/panel/auo,b101ean01.txt deleted file mode 100644 index 3590b0741..000000000 --- a/Documentation/devicetree/bindings/panel/auo,b101ean01.txt +++ /dev/null @@ -1,7 +0,0 @@ -AU Optronics Corporation 10.1" WSVGA TFT LCD panel - -Required properties: -- compatible: should be "auo,b101ean01" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/auo,b101xtn01.txt b/Documentation/devicetree/bindings/panel/auo,b101xtn01.txt deleted file mode 100644 index 889d511d6..000000000 --- a/Documentation/devicetree/bindings/panel/auo,b101xtn01.txt +++ /dev/null @@ -1,7 +0,0 @@ -AU Optronics Corporation 10.1" WXGA TFT LCD panel - -Required properties: -- compatible: should be "auo,b101xtn01" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/auo,b116xw03.txt b/Documentation/devicetree/bindings/panel/auo,b116xw03.txt deleted file mode 100644 index 690d0a568..000000000 --- a/Documentation/devicetree/bindings/panel/auo,b116xw03.txt +++ /dev/null @@ -1,7 +0,0 @@ -AU Optronics Corporation 11.6" HD (1366x768) color TFT-LCD panel - -Required properties: -- compatible: should be "auo,b116xw03" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/auo,b133htn01.txt b/Documentation/devicetree/bindings/panel/auo,b133htn01.txt deleted file mode 100644 index 302226b5b..000000000 --- a/Documentation/devicetree/bindings/panel/auo,b133htn01.txt +++ /dev/null @@ -1,7 +0,0 @@ -AU Optronics Corporation 13.3" FHD (1920x1080) color TFT-LCD panel - -Required properties: -- compatible: should be "auo,b133htn01" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/auo,b133xtn01.txt b/Documentation/devicetree/bindings/panel/auo,b133xtn01.txt deleted file mode 100644 index 7443b7c76..000000000 --- a/Documentation/devicetree/bindings/panel/auo,b133xtn01.txt +++ /dev/null @@ -1,7 +0,0 @@ -AU Optronics Corporation 13.3" WXGA (1366x768) TFT LCD panel - -Required properties: -- compatible: should be "auo,b133xtn01" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/avic,tm070ddh03.txt b/Documentation/devicetree/bindings/panel/avic,tm070ddh03.txt deleted file mode 100644 index b6f2f3e8f..000000000 --- a/Documentation/devicetree/bindings/panel/avic,tm070ddh03.txt +++ /dev/null @@ -1,7 +0,0 @@ -Shanghai AVIC Optoelectronics 7" 1024x600 color TFT-LCD panel - -Required properties: -- compatible: should be "avic,tm070ddh03" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/chunghwa,claa101wa01a.txt b/Documentation/devicetree/bindings/panel/chunghwa,claa101wa01a.txt deleted file mode 100644 index f24614e4d..000000000 --- a/Documentation/devicetree/bindings/panel/chunghwa,claa101wa01a.txt +++ /dev/null @@ -1,7 +0,0 @@ -Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel - -Required properties: -- compatible: should be "chunghwa,claa101wa01a" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt b/Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt deleted file mode 100644 index 0ab2c05a4..000000000 --- a/Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt +++ /dev/null @@ -1,7 +0,0 @@ -Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel - -Required properties: -- compatible: should be "chunghwa,claa101wb03" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/edt,et057090dhu.txt b/Documentation/devicetree/bindings/panel/edt,et057090dhu.txt deleted file mode 100644 index 4903d7b1d..000000000 --- a/Documentation/devicetree/bindings/panel/edt,et057090dhu.txt +++ /dev/null @@ -1,7 +0,0 @@ -Emerging Display Technology Corp. 5.7" VGA TFT LCD panel - -Required properties: -- compatible: should be "edt,et057090dhu" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/edt,et070080dh6.txt b/Documentation/devicetree/bindings/panel/edt,et070080dh6.txt deleted file mode 100644 index 20cb38e83..000000000 --- a/Documentation/devicetree/bindings/panel/edt,et070080dh6.txt +++ /dev/null @@ -1,10 +0,0 @@ -Emerging Display Technology Corp. ET070080DH6 7.0" WVGA TFT LCD panel - -Required properties: -- compatible: should be "edt,et070080dh6" - -This panel is the same as ETM0700G0DH6 except for the touchscreen. -ET070080DH6 is the model with resistive touch. - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/edt,etm0700g0dh6.txt b/Documentation/devicetree/bindings/panel/edt,etm0700g0dh6.txt deleted file mode 100644 index ee4b18053..000000000 --- a/Documentation/devicetree/bindings/panel/edt,etm0700g0dh6.txt +++ /dev/null @@ -1,10 +0,0 @@ -Emerging Display Technology Corp. ETM0700G0DH6 7.0" WVGA TFT LCD panel - -Required properties: -- compatible: should be "edt,etm0700g0dh6" - -This panel is the same as ET070080DH6 except for the touchscreen. -ETM0700G0DH6 is the model with capacitive multitouch. - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/foxlink,fl500wvr00-a0t.txt b/Documentation/devicetree/bindings/panel/foxlink,fl500wvr00-a0t.txt deleted file mode 100644 index b47f9d87b..000000000 --- a/Documentation/devicetree/bindings/panel/foxlink,fl500wvr00-a0t.txt +++ /dev/null @@ -1,7 +0,0 @@ -Foxlink Group 5" WVGA TFT LCD panel - -Required properties: -- compatible: should be "foxlink,fl500wvr00-a0t" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/giantplus,gpg482739qs5.txt b/Documentation/devicetree/bindings/panel/giantplus,gpg482739qs5.txt deleted file mode 100644 index 24b0b6244..000000000 --- a/Documentation/devicetree/bindings/panel/giantplus,gpg482739qs5.txt +++ /dev/null @@ -1,7 +0,0 @@ -GiantPlus GPG48273QS5 4.3" (480x272) WQVGA TFT LCD panel - -Required properties: -- compatible: should be "giantplus,gpg48273qs5" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/hannstar,hsd070pww1.txt b/Documentation/devicetree/bindings/panel/hannstar,hsd070pww1.txt deleted file mode 100644 index 7da1d5c03..000000000 --- a/Documentation/devicetree/bindings/panel/hannstar,hsd070pww1.txt +++ /dev/null @@ -1,7 +0,0 @@ -HannStar Display Corp. HSD070PWW1 7.0" WXGA TFT LCD panel - -Required properties: -- compatible: should be "hannstar,hsd070pww1" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/hannstar,hsd100pxn1.txt b/Documentation/devicetree/bindings/panel/hannstar,hsd100pxn1.txt deleted file mode 100644 index 8270319a9..000000000 --- a/Documentation/devicetree/bindings/panel/hannstar,hsd100pxn1.txt +++ /dev/null @@ -1,7 +0,0 @@ -HannStar Display Corp. HSD100PXN1 10.1" XGA LVDS panel - -Required properties: -- compatible: should be "hannstar,hsd100pxn1" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/hit,tx23d38vm0caa.txt b/Documentation/devicetree/bindings/panel/hit,tx23d38vm0caa.txt deleted file mode 100644 index 04caaae19..000000000 --- a/Documentation/devicetree/bindings/panel/hit,tx23d38vm0caa.txt +++ /dev/null @@ -1,7 +0,0 @@ -Hitachi Ltd. Corporation 9" WVGA (800x480) TFT LCD panel - -Required properties: -- compatible: should be "hit,tx23d38vm0caa" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/innolux,at043tn24.txt b/Documentation/devicetree/bindings/panel/innolux,at043tn24.txt deleted file mode 100644 index 4104226b6..000000000 --- a/Documentation/devicetree/bindings/panel/innolux,at043tn24.txt +++ /dev/null @@ -1,7 +0,0 @@ -Innolux AT043TN24 4.3" WQVGA TFT LCD panel - -Required properties: -- compatible: should be "innolux,at043tn24" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/innolux,g121i1-l01.txt b/Documentation/devicetree/bindings/panel/innolux,g121i1-l01.txt deleted file mode 100644 index 2743b07cd..000000000 --- a/Documentation/devicetree/bindings/panel/innolux,g121i1-l01.txt +++ /dev/null @@ -1,7 +0,0 @@ -Innolux Corporation 12.1" WXGA (1280x800) TFT LCD panel - -Required properties: -- compatible: should be "innolux,g121i1-l01" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/innolux,n116bge.txt b/Documentation/devicetree/bindings/panel/innolux,n116bge.txt deleted file mode 100644 index 081bb939e..000000000 --- a/Documentation/devicetree/bindings/panel/innolux,n116bge.txt +++ /dev/null @@ -1,7 +0,0 @@ -Innolux Corporation 11.6" WXGA (1366x768) TFT LCD panel - -Required properties: -- compatible: should be "innolux,n116bge" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/innolux,n156bge-l21.txt b/Documentation/devicetree/bindings/panel/innolux,n156bge-l21.txt deleted file mode 100644 index 7825844aa..000000000 --- a/Documentation/devicetree/bindings/panel/innolux,n156bge-l21.txt +++ /dev/null @@ -1,7 +0,0 @@ -InnoLux 15.6" WXGA TFT LCD panel - -Required properties: -- compatible: should be "innolux,n156bge-l21" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/innolux,zj070na-01p.txt b/Documentation/devicetree/bindings/panel/innolux,zj070na-01p.txt deleted file mode 100644 index 824f87f15..000000000 --- a/Documentation/devicetree/bindings/panel/innolux,zj070na-01p.txt +++ /dev/null @@ -1,7 +0,0 @@ -Innolux Corporation 7.0" WSVGA (1024x600) TFT LCD panel - -Required properties: -- compatible: should be "innolux,zj070na-01p" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/lg,lb070wv8.txt b/Documentation/devicetree/bindings/panel/lg,lb070wv8.txt deleted file mode 100644 index a7588e525..000000000 --- a/Documentation/devicetree/bindings/panel/lg,lb070wv8.txt +++ /dev/null @@ -1,7 +0,0 @@ -LG 7" (800x480 pixels) TFT LCD panel - -Required properties: -- compatible: should be "lg,lb070wv8" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/lg,ld070wx3-sl01.txt b/Documentation/devicetree/bindings/panel/lg,ld070wx3-sl01.txt deleted file mode 100644 index 5e649cb9a..000000000 --- a/Documentation/devicetree/bindings/panel/lg,ld070wx3-sl01.txt +++ /dev/null @@ -1,7 +0,0 @@ -LG Corporation 7" WXGA TFT LCD panel - -Required properties: -- compatible: should be "lg,ld070wx3-sl01" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/lg,lg4573.txt b/Documentation/devicetree/bindings/panel/lg,lg4573.txt deleted file mode 100644 index 824441f4e..000000000 --- a/Documentation/devicetree/bindings/panel/lg,lg4573.txt +++ /dev/null @@ -1,19 +0,0 @@ -LG LG4573 TFT Liquid Crystal Display with SPI control bus - -Required properties: - - compatible: "lg,lg4573" - - reg: address of the panel on the SPI bus - -The panel must obey rules for SPI slave device specified in document [1]. - -[1]: Documentation/devicetree/bindings/spi/spi-bus.txt - -Example: - - lcd_panel: display@0 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "lg,lg4573"; - spi-max-frequency = <10000000>; - reg = <0>; - }; diff --git a/Documentation/devicetree/bindings/panel/lg,lh500wx1-sd03.txt b/Documentation/devicetree/bindings/panel/lg,lh500wx1-sd03.txt deleted file mode 100644 index a04fd2b2e..000000000 --- a/Documentation/devicetree/bindings/panel/lg,lh500wx1-sd03.txt +++ /dev/null @@ -1,7 +0,0 @@ -LG Corporation 5" HD TFT LCD panel - -Required properties: -- compatible: should be "lg,lh500wx1-sd03" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/lg,lp129qe.txt b/Documentation/devicetree/bindings/panel/lg,lp129qe.txt deleted file mode 100644 index 9f262e0c5..000000000 --- a/Documentation/devicetree/bindings/panel/lg,lp129qe.txt +++ /dev/null @@ -1,7 +0,0 @@ -LG 12.9" (2560x1700 pixels) TFT LCD panel - -Required properties: -- compatible: should be "lg,lp129qe" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/nec,nl4827hc19-05b.txt b/Documentation/devicetree/bindings/panel/nec,nl4827hc19-05b.txt deleted file mode 100644 index 8e1914d1e..000000000 --- a/Documentation/devicetree/bindings/panel/nec,nl4827hc19-05b.txt +++ /dev/null @@ -1,7 +0,0 @@ -NEC LCD Technologies,Ltd. WQVGA TFT LCD panel - -Required properties: -- compatible: should be "nec,nl4827hc19-05b" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/okaya,rs800480t-7x0gp.txt b/Documentation/devicetree/bindings/panel/okaya,rs800480t-7x0gp.txt deleted file mode 100644 index ddf8e211d..000000000 --- a/Documentation/devicetree/bindings/panel/okaya,rs800480t-7x0gp.txt +++ /dev/null @@ -1,7 +0,0 @@ -OKAYA Electric America, Inc. RS800480T-7X0GP 7" WVGA LCD panel - -Required properties: -- compatible: should be "okaya,rs800480t-7x0gp" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/ortustech,com43h4m85ulc.txt b/Documentation/devicetree/bindings/panel/ortustech,com43h4m85ulc.txt deleted file mode 100644 index de19e9398..000000000 --- a/Documentation/devicetree/bindings/panel/ortustech,com43h4m85ulc.txt +++ /dev/null @@ -1,7 +0,0 @@ -OrtusTech COM43H4M85ULC Blanview 3.7" TFT-LCD panel - -Required properties: -- compatible: should be "ortustech,com43h4m85ulc" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt b/Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt deleted file mode 100644 index d328b0341..000000000 --- a/Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt +++ /dev/null @@ -1,7 +0,0 @@ -Panasonic Corporation 10.1" WUXGA TFT LCD panel - -Required properties: -- compatible: should be "panasonic,vvx10f004b00" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/samsung,ld9040.txt b/Documentation/devicetree/bindings/panel/samsung,ld9040.txt deleted file mode 100644 index 07c36c3f7..000000000 --- a/Documentation/devicetree/bindings/panel/samsung,ld9040.txt +++ /dev/null @@ -1,66 +0,0 @@ -Samsung LD9040 AMOLED LCD parallel RGB panel with SPI control bus - -Required properties: - - compatible: "samsung,ld9040" - - reg: address of the panel on SPI bus - - vdd3-supply: core voltage supply - - vci-supply: voltage supply for analog circuits - - reset-gpios: a GPIO spec for the reset pin - - display-timings: timings for the connected panel according to [1] - -The panel must obey rules for SPI slave device specified in document [2]. - -Optional properties: - - power-on-delay: delay after turning regulators on [ms] - - reset-delay: delay after reset sequence [ms] - - panel-width-mm: physical panel width [mm] - - panel-height-mm: physical panel height [mm] - -The device node can contain one 'port' child node with one child -'endpoint' node, according to the bindings defined in [3]. This -node should describe panel's video bus. - -[1]: Documentation/devicetree/bindings/video/display-timing.txt -[2]: Documentation/devicetree/bindings/spi/spi-bus.txt -[3]: Documentation/devicetree/bindings/media/video-interfaces.txt - -Example: - - lcd@0 { - compatible = "samsung,ld9040"; - reg = <0>; - vdd3-supply = <&ldo7_reg>; - vci-supply = <&ldo17_reg>; - reset-gpios = <&gpy4 5 0>; - spi-max-frequency = <1200000>; - spi-cpol; - spi-cpha; - power-on-delay = <10>; - reset-delay = <10>; - panel-width-mm = <90>; - panel-height-mm = <154>; - - display-timings { - timing { - clock-frequency = <23492370>; - hactive = <480>; - vactive = <800>; - hback-porch = <16>; - hfront-porch = <16>; - vback-porch = <2>; - vfront-porch = <28>; - hsync-len = <2>; - vsync-len = <1>; - hsync-active = <0>; - vsync-active = <0>; - de-active = <0>; - pixelclk-active = <0>; - }; - }; - - port { - lcd_ep: endpoint { - remote-endpoint = <&fimd_dpi_ep>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/panel/samsung,ltn101nt05.txt b/Documentation/devicetree/bindings/panel/samsung,ltn101nt05.txt deleted file mode 100644 index ef522c6bb..000000000 --- a/Documentation/devicetree/bindings/panel/samsung,ltn101nt05.txt +++ /dev/null @@ -1,7 +0,0 @@ -Samsung Electronics 10.1" WSVGA TFT LCD panel - -Required properties: -- compatible: should be "samsung,ltn101nt05" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/samsung,ltn140at29-301.txt b/Documentation/devicetree/bindings/panel/samsung,ltn140at29-301.txt deleted file mode 100644 index e7f969d89..000000000 --- a/Documentation/devicetree/bindings/panel/samsung,ltn140at29-301.txt +++ /dev/null @@ -1,7 +0,0 @@ -Samsung Electronics 14" WXGA (1366x768) TFT LCD panel - -Required properties: -- compatible: should be "samsung,ltn140at29-301" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e8aa0.txt b/Documentation/devicetree/bindings/panel/samsung,s6e8aa0.txt deleted file mode 100644 index e7ee988e3..000000000 --- a/Documentation/devicetree/bindings/panel/samsung,s6e8aa0.txt +++ /dev/null @@ -1,56 +0,0 @@ -Samsung S6E8AA0 AMOLED LCD 5.3 inch panel - -Required properties: - - compatible: "samsung,s6e8aa0" - - reg: the virtual channel number of a DSI peripheral - - vdd3-supply: core voltage supply - - vci-supply: voltage supply for analog circuits - - reset-gpios: a GPIO spec for the reset pin - - display-timings: timings for the connected panel as described by [1] - -Optional properties: - - power-on-delay: delay after turning regulators on [ms] - - reset-delay: delay after reset sequence [ms] - - init-delay: delay after initialization sequence [ms] - - panel-width-mm: physical panel width [mm] - - panel-height-mm: physical panel height [mm] - - flip-horizontal: boolean to flip image horizontally - - flip-vertical: boolean to flip image vertically - -The device node can contain one 'port' child node with one child -'endpoint' node, according to the bindings defined in [2]. This -node should describe panel's video bus. - -[1]: Documentation/devicetree/bindings/video/display-timing.txt -[2]: Documentation/devicetree/bindings/media/video-interfaces.txt - -Example: - - panel { - compatible = "samsung,s6e8aa0"; - reg = <0>; - vdd3-supply = <&vcclcd_reg>; - vci-supply = <&vlcd_reg>; - reset-gpios = <&gpy4 5 0>; - power-on-delay= <50>; - reset-delay = <100>; - init-delay = <100>; - panel-width-mm = <58>; - panel-height-mm = <103>; - flip-horizontal; - flip-vertical; - - display-timings { - timing0: timing-0 { - clock-frequency = <57153600>; - hactive = <720>; - vactive = <1280>; - hfront-porch = <5>; - hback-porch = <5>; - hsync-len = <5>; - vfront-porch = <13>; - vback-porch = <1>; - vsync-len = <2>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/panel/sharp,lq101r1sx01.txt b/Documentation/devicetree/bindings/panel/sharp,lq101r1sx01.txt deleted file mode 100644 index f522bb8e4..000000000 --- a/Documentation/devicetree/bindings/panel/sharp,lq101r1sx01.txt +++ /dev/null @@ -1,49 +0,0 @@ -Sharp Microelectronics 10.1" WQXGA TFT LCD panel - -This panel requires a dual-channel DSI host to operate. It supports two modes: -- left-right: each channel drives the left or right half of the screen -- even-odd: each channel drives the even or odd lines of the screen - -Each of the DSI channels controls a separate DSI peripheral. The peripheral -driven by the first link (DSI-LINK1), left or even, is considered the primary -peripheral and controls the device. The 'link2' property contains a phandle -to the peripheral driven by the second link (DSI-LINK2, right or odd). - -Note that in video mode the DSI-LINK1 interface always provides the left/even -pixels and DSI-LINK2 always provides the right/odd pixels. In command mode it -is possible to program either link to drive the left/even or right/odd pixels -but for the sake of consistency this binding assumes that the same assignment -is chosen as for video mode. - -Required properties: -- compatible: should be "sharp,lq101r1sx01" -- reg: DSI virtual channel of the peripheral - -Required properties (for DSI-LINK1 only): -- link2: phandle to the DSI peripheral on the secondary link. Note that the - presence of this property marks the containing node as DSI-LINK1. -- power-supply: phandle of the regulator that provides the supply voltage - -Optional properties (for DSI-LINK1 only): -- backlight: phandle of the backlight device attached to the panel - -Example: - - dsi@54300000 { - panel: panel@0 { - compatible = "sharp,lq101r1sx01"; - reg = <0>; - - link2 = <&secondary>; - - power-supply = <...>; - backlight = <...>; - }; - }; - - dsi@54400000 { - secondary: panel@0 { - compatible = "sharp,lq101r1sx01"; - reg = <0>; - }; - }; diff --git a/Documentation/devicetree/bindings/panel/shelly,sca07010-bfn-lnn.txt b/Documentation/devicetree/bindings/panel/shelly,sca07010-bfn-lnn.txt deleted file mode 100644 index fc1ea9e26..000000000 --- a/Documentation/devicetree/bindings/panel/shelly,sca07010-bfn-lnn.txt +++ /dev/null @@ -1,7 +0,0 @@ -Shelly SCA07010-BFN-LNN 7.0" WVGA TFT LCD panel - -Required properties: -- compatible: should be "shelly,sca07010-bfn-lnn" - -This binding is compatible with the simple-panel binding, which is specified -in simple-panel.txt in this directory. diff --git a/Documentation/devicetree/bindings/panel/simple-panel.txt b/Documentation/devicetree/bindings/panel/simple-panel.txt deleted file mode 100644 index 1341bbf4a..000000000 --- a/Documentation/devicetree/bindings/panel/simple-panel.txt +++ /dev/null @@ -1,21 +0,0 @@ -Simple display panel - -Required properties: -- power-supply: regulator to provide the supply voltage - -Optional properties: -- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing -- enable-gpios: GPIO pin to enable or disable the panel -- backlight: phandle of the backlight device attached to the panel - -Example: - - panel: panel { - compatible = "cptt,claa101wb01"; - ddc-i2c-bus = <&panelddc>; - - power-supply = <&vdd_pnl_reg>; - enable-gpios = <&gpio 90 0>; - - backlight = <&backlight>; - }; diff --git a/Documentation/devicetree/bindings/pci/altera-pcie-msi.txt b/Documentation/devicetree/bindings/pci/altera-pcie-msi.txt new file mode 100644 index 000000000..09cd3bc4d --- /dev/null +++ b/Documentation/devicetree/bindings/pci/altera-pcie-msi.txt @@ -0,0 +1,28 @@ +* Altera PCIe MSI controller + +Required properties: +- compatible: should contain "altr,msi-1.0" +- reg: specifies the physical base address of the controller and + the length of the memory mapped region. +- reg-names: must include the following entries: + "csr": CSR registers + "vector_slave": vectors slave port region +- interrupt-parent: interrupt source phandle. +- interrupts: specifies the interrupt source of the parent interrupt + controller. The format of the interrupt specifier depends on the + parent interrupt controller. +- num-vectors: number of vectors, range 1 to 32. +- msi-controller: indicates that this is MSI controller node + + +Example +msi0: msi@0xFF200000 { + compatible = "altr,msi-1.0"; + reg = <0xFF200000 0x00000010 + 0xFF200010 0x00000080>; + reg-names = "csr", "vector_slave"; + interrupt-parent = <&hps_0_arm_gic_0>; + interrupts = <0 42 4>; + msi-controller; + num-vectors = <32>; +}; diff --git a/Documentation/devicetree/bindings/pci/altera-pcie.txt b/Documentation/devicetree/bindings/pci/altera-pcie.txt new file mode 100644 index 000000000..2951a6a50 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/altera-pcie.txt @@ -0,0 +1,49 @@ +* Altera PCIe controller + +Required properties: +- compatible : should contain "altr,pcie-root-port-1.0" +- reg: a list of physical base address and length for TXS and CRA. +- reg-names: must include the following entries: + "Txs": TX slave port region + "Cra": Control register access region +- interrupt-parent: interrupt source phandle. +- interrupts: specifies the interrupt source of the parent interrupt controller. + The format of the interrupt specifier depends on the parent interrupt + controller. +- device_type: must be "pci" +- #address-cells: set to <3> +- #size-cells: set to <2> +- #interrupt-cells: set to <1> +- ranges: describes the translation of addresses for root ports and standard + PCI regions. +- interrupt-map-mask and interrupt-map: standard PCI properties to define the + mapping of the PCIe interface to interrupt numbers. + +Optional properties: +- msi-parent: Link to the hardware entity that serves as the MSI controller for this PCIe + controller. +- bus-range: PCI bus numbers covered + +Example + pcie_0: pcie@0xc00000000 { + compatible = "altr,pcie-root-port-1.0"; + reg = <0xc0000000 0x20000000>, + <0xff220000 0x00004000>; + reg-names = "Txs", "Cra"; + interrupt-parent = <&hps_0_arm_gic_0>; + interrupts = <0 40 4>; + interrupt-controller; + #interrupt-cells = <1>; + bus-range = <0x0 0xFF>; + device_type = "pci"; + msi-parent = <&msi_to_gic_gen_0>; + #address-cells = <3>; + #size-cells = <2>; + interrupt-map-mask = <0 0 0 7>; + interrupt-map = <0 0 0 1 &pcie_0 1>, + <0 0 0 2 &pcie_0 2>, + <0 0 0 3 &pcie_0 3>, + <0 0 0 4 &pcie_0 4>; + ranges = <0x82000000 0x00000000 0x00000000 0xc0000000 0x00000000 0x10000000 + 0x82000000 0x00000000 0x10000000 0xd0000000 0x00000000 0x10000000>; + }; diff --git a/Documentation/devicetree/bindings/pci/arm,juno-r1-pcie.txt b/Documentation/devicetree/bindings/pci/arm,juno-r1-pcie.txt new file mode 100644 index 000000000..f7514c170 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/arm,juno-r1-pcie.txt @@ -0,0 +1,10 @@ +* ARM Juno R1 PCIe interface + +This PCIe host controller is based on PLDA XpressRICH3-AXI IP +and thus inherits all the common properties defined in plda,xpressrich3-axi.txt +as well as the base properties defined in host-generic-pci.txt. + +Required properties: + - compatible: "arm,juno-r1-pcie" + - dma-coherent: The host controller bridges the AXI transactions into PCIe bus + in a manner that makes the DMA operations to appear coherent to the CPUs. diff --git a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt index f7ce50e38..45c2a8094 100644 --- a/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt +++ b/Documentation/devicetree/bindings/pci/brcm,iproc-pcie.txt @@ -17,6 +17,21 @@ Optional properties: - phys: phandle of the PCIe PHY device - phy-names: must be "pcie-phy" +- brcm,pcie-ob: Some iProc SoCs do not have the outbound address mapping done +by the ASIC after power on reset. In this case, SW needs to configure it + +If the brcm,pcie-ob property is present, the following properties become +effective: + +Required: +- brcm,pcie-ob-axi-offset: The offset from the AXI address to the internal +address used by the iProc PCIe core (not the PCIe address) +- brcm,pcie-ob-window-size: The outbound address mapping window size (in MB) + +Optional: +- brcm,pcie-ob-oarr-size: Some iProc SoCs need the OARR size bit to be set to +increase the outbound window size + Example: pcie0: pcie@18012000 { compatible = "brcm,iproc-pcie"; @@ -38,6 +53,11 @@ Example: phys = <&phy 0 5>; phy-names = "pcie-phy"; + + brcm,pcie-ob; + brcm,pcie-ob-oarr-size; + brcm,pcie-ob-axi-offset = <0x00000000>; + brcm,pcie-ob-window-size = <256>; }; pcie1: pcie@18013000 { diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt b/Documentation/devicetree/bindings/pci/designware-pcie.txt index 9f4faa8e8..5b0853df9 100644 --- a/Documentation/devicetree/bindings/pci/designware-pcie.txt +++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt @@ -15,14 +15,16 @@ Required properties: to define the mapping of the PCIe interface to interrupt numbers. - num-lanes: number of lanes to use -- clocks: Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. -- clock-names: Must include the following entries: - - "pcie" - - "pcie_bus" Optional properties: +- num-lanes: number of lanes to use (this property should be specified unless + the link is brought already up in BIOS) - reset-gpio: gpio pin number of power good signal - bus-range: PCI bus numbers covered (it is recommended for new devicetrees to specify this property, to keep backwards compatibility a range of 0x00-0xff is assumed if not present) +- clocks: Must contain an entry for each entry in clock-names. + See ../clocks/clock-bindings.txt for details. +- clock-names: Must include the following entries: + - "pcie" + - "pcie_bus" diff --git a/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt new file mode 100644 index 000000000..17c6ed9c6 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/hisilicon-pcie.txt @@ -0,0 +1,44 @@ +HiSilicon PCIe host bridge DT description + +HiSilicon PCIe host controller is based on Designware PCI core. +It shares common functions with PCIe Designware core driver and inherits +common properties defined in +Documentation/devicetree/bindings/pci/designware-pci.txt. + +Additional properties are described here: + +Required properties: +- compatible: Should contain "hisilicon,hip05-pcie". +- reg: Should contain rc_dbi, config registers location and length. +- reg-names: Must include the following entries: + "rc_dbi": controller configuration registers; + "config": PCIe configuration space registers. +- msi-parent: Should be its_pcie which is an ITS receiving MSI interrupts. +- port-id: Should be 0, 1, 2 or 3. + +Optional properties: +- status: Either "ok" or "disabled". +- dma-coherent: Present if DMA operations are coherent. + +Example: + pcie@0xb0080000 { + compatible = "hisilicon,hip05-pcie", "snps,dw-pcie"; + reg = <0 0xb0080000 0 0x10000>, <0x220 0x00000000 0 0x2000>; + reg-names = "rc_dbi", "config"; + bus-range = <0 15>; + msi-parent = <&its_pcie>; + #address-cells = <3>; + #size-cells = <2>; + device_type = "pci"; + dma-coherent; + ranges = <0x82000000 0 0x00000000 0x220 0x00000000 0 0x10000000>; + num-lanes = <8>; + port-id = <1>; + #interrupts-cells = <1>; + interrupts-map-mask = <0xf800 0 0 7>; + interrupts-map = <0x0 0 0 1 &mbigen_pcie 1 10 + 0x0 0 0 2 &mbigen_pcie 2 11 + 0x0 0 0 3 &mbigen_pcie 3 12 + 0x0 0 0 4 &mbigen_pcie 4 13>; + status = "ok"; + }; diff --git a/Documentation/devicetree/bindings/pci/host-generic-pci.txt b/Documentation/devicetree/bindings/pci/host-generic-pci.txt index cf3e205e0..3f1d3fca6 100644 --- a/Documentation/devicetree/bindings/pci/host-generic-pci.txt +++ b/Documentation/devicetree/bindings/pci/host-generic-pci.txt @@ -34,8 +34,9 @@ Properties of the host controller node: - #size-cells : Must be 2. - reg : The Configuration Space base address and size, as accessed - from the parent bus. - + from the parent bus. The base address corresponds to + the first bus in the "bus-range" property. If no + "bus-range" is specified, this will be bus 0 (the default). Properties of the /chosen node: diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt b/Documentation/devicetree/bindings/pci/layerscape-pci.txt index 6286f049b..e3767857d 100644 --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt @@ -1,10 +1,20 @@ Freescale Layerscape PCIe controller -This PCIe host controller is based on the Synopsis Designware PCIe IP +This PCIe host controller is based on the Synopsys DesignWare PCIe IP and thus inherits all the common properties defined in designware-pcie.txt. +This controller derives its clocks from the Reset Configuration Word (RCW) +which is used to describe the PLL settings at the time of chip-reset. + +Also as per the available Reference Manuals, there is no specific 'version' +register available in the Freescale PCIe controller register set, +which can allow determining the underlying DesignWare PCIe controller version +information. + Required properties: -- compatible: should contain the platform identifier such as "fsl,ls1021a-pcie" +- compatible: should contain the platform identifier such as: + "fsl,ls1021a-pcie", "snps,dw-pcie" + "fsl,ls2080a-pcie", "snps,dw-pcie" - reg: base addresses and lengths of the PCIe controller - interrupts: A list of interrupt outputs of the controller. Must contain an entry for each entry in the interrupt-names property. diff --git a/Documentation/devicetree/bindings/pci/pci-msi.txt b/Documentation/devicetree/bindings/pci/pci-msi.txt new file mode 100644 index 000000000..9b3cc817d --- /dev/null +++ b/Documentation/devicetree/bindings/pci/pci-msi.txt @@ -0,0 +1,220 @@ +This document describes the generic device tree binding for describing the +relationship between PCI devices and MSI controllers. + +Each PCI device under a root complex is uniquely identified by its Requester ID +(AKA RID). A Requester ID is a triplet of a Bus number, Device number, and +Function number. + +For the purpose of this document, when treated as a numeric value, a RID is +formatted such that: + +* Bits [15:8] are the Bus number. +* Bits [7:3] are the Device number. +* Bits [2:0] are the Function number. +* Any other bits required for padding must be zero. + +MSIs may be distinguished in part through the use of sideband data accompanying +writes. In the case of PCI devices, this sideband data may be derived from the +Requester ID. A mechanism is required to associate a device with both the MSI +controllers it can address, and the sideband data that will be associated with +its writes to those controllers. + +For generic MSI bindings, see +Documentation/devicetree/bindings/interrupt-controller/msi.txt. + + +PCI root complex +================ + +Optional properties +------------------- + +- msi-map: Maps a Requester ID to an MSI controller and associated + msi-specifier data. The property is an arbitrary number of tuples of + (rid-base,msi-controller,msi-base,length), where: + + * rid-base is a single cell describing the first RID matched by the entry. + + * msi-controller is a single phandle to an MSI controller + + * msi-base is an msi-specifier describing the msi-specifier produced for the + first RID matched by the entry. + + * length is a single cell describing how many consecutive RIDs are matched + following the rid-base. + + Any RID r in the interval [rid-base, rid-base + length) is associated with + the listed msi-controller, with the msi-specifier (r - rid-base + msi-base). + +- msi-map-mask: A mask to be applied to each Requester ID prior to being mapped + to an msi-specifier per the msi-map property. + +- msi-parent: Describes the MSI parent of the root complex itself. Where + the root complex and MSI controller do not pass sideband data with MSI + writes, this property may be used to describe the MSI controller(s) + used by PCI devices under the root complex, if defined as such in the + binding for the root complex. + + +Example (1) +=========== + +/ { + #address-cells = <1>; + #size-cells = <1>; + + msi: msi-controller@a { + reg = <0xa 0x1>; + compatible = "vendor,some-controller"; + msi-controller; + #msi-cells = <1>; + }; + + pci: pci@f { + reg = <0xf 0x1>; + compatible = "vendor,pcie-root-complex"; + device_type = "pci"; + + /* + * The sideband data provided to the MSI controller is + * the RID, identity-mapped. + */ + msi-map = <0x0 &msi_a 0x0 0x10000>, + }; +}; + + +Example (2) +=========== + +/ { + #address-cells = <1>; + #size-cells = <1>; + + msi: msi-controller@a { + reg = <0xa 0x1>; + compatible = "vendor,some-controller"; + msi-controller; + #msi-cells = <1>; + }; + + pci: pci@f { + reg = <0xf 0x1>; + compatible = "vendor,pcie-root-complex"; + device_type = "pci"; + + /* + * The sideband data provided to the MSI controller is + * the RID, masked to only the device and function bits. + */ + msi-map = <0x0 &msi_a 0x0 0x100>, + msi-map-mask = <0xff> + }; +}; + + +Example (3) +=========== + +/ { + #address-cells = <1>; + #size-cells = <1>; + + msi: msi-controller@a { + reg = <0xa 0x1>; + compatible = "vendor,some-controller"; + msi-controller; + #msi-cells = <1>; + }; + + pci: pci@f { + reg = <0xf 0x1>; + compatible = "vendor,pcie-root-complex"; + device_type = "pci"; + + /* + * The sideband data provided to the MSI controller is + * the RID, but the high bit of the bus number is + * ignored. + */ + msi-map = <0x0000 &msi 0x0000 0x8000>, + <0x8000 &msi 0x0000 0x8000>; + }; +}; + + +Example (4) +=========== + +/ { + #address-cells = <1>; + #size-cells = <1>; + + msi: msi-controller@a { + reg = <0xa 0x1>; + compatible = "vendor,some-controller"; + msi-controller; + #msi-cells = <1>; + }; + + pci: pci@f { + reg = <0xf 0x1>; + compatible = "vendor,pcie-root-complex"; + device_type = "pci"; + + /* + * The sideband data provided to the MSI controller is + * the RID, but the high bit of the bus number is + * negated. + */ + msi-map = <0x0000 &msi 0x8000 0x8000>, + <0x8000 &msi 0x0000 0x8000>; + }; +}; + + +Example (5) +=========== + +/ { + #address-cells = <1>; + #size-cells = <1>; + + msi_a: msi-controller@a { + reg = <0xa 0x1>; + compatible = "vendor,some-controller"; + msi-controller; + #msi-cells = <1>; + }; + + msi_b: msi-controller@b { + reg = <0xb 0x1>; + compatible = "vendor,some-controller"; + msi-controller; + #msi-cells = <1>; + }; + + msi_c: msi-controller@c { + reg = <0xc 0x1>; + compatible = "vendor,some-controller"; + msi-controller; + #msi-cells = <1>; + }; + + pci: pci@c { + reg = <0xf 0x1>; + compatible = "vendor,pcie-root-complex"; + device_type = "pci"; + + /* + * The sideband data provided to MSI controller a is the + * RID, but the high bit of the bus number is negated. + * The sideband data provided to MSI controller b is the + * RID, identity-mapped. + * MSI controller c is not addressable. + */ + msi-map = <0x0000 &msi_a 0x8000 0x08000>, + <0x8000 &msi_a 0x0000 0x08000>, + <0x0000 &msi_b 0x0000 0x10000>; + }; +}; diff --git a/Documentation/devicetree/bindings/pci/pci.txt b/Documentation/devicetree/bindings/pci/pci.txt index f8fbe9af7..08dcfad09 100644 --- a/Documentation/devicetree/bindings/pci/pci.txt +++ b/Documentation/devicetree/bindings/pci/pci.txt @@ -1,12 +1,12 @@ PCI bus bridges have standardized Device Tree bindings: PCI Bus Binding to: IEEE Std 1275-1994 -http://www.openfirmware.org/ofwg/bindings/pci/pci2_1.pdf +http://www.firmware.org/1275/bindings/pci/pci2_1.pdf And for the interrupt mapping part: Open Firmware Recommended Practice: Interrupt Mapping -http://www.openfirmware.org/1275/practice/imap/imap0_9d.pdf +http://www.firmware.org/1275/practice/imap/imap0_9d.pdf Additionally to the properties specified in the above standards a host bridge driver implementation may support the following properties: diff --git a/Documentation/devicetree/bindings/pci/plda,xpressrich3-axi.txt b/Documentation/devicetree/bindings/pci/plda,xpressrich3-axi.txt new file mode 100644 index 000000000..f3f75bfb4 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/plda,xpressrich3-axi.txt @@ -0,0 +1,12 @@ +* PLDA XpressRICH3-AXI host controller + +The PLDA XpressRICH3-AXI host controller can be configured in a manner that +makes it compliant with the SBSA[1] standard published by ARM Ltd. For those +scenarios, the host-generic-pci.txt bindings apply with the following additions +to the compatible property: + +Required properties: + - compatible: should contain "plda,xpressrich3-axi" to identify the IP used. + + +[1] http://infocenter.arm.com/help/topic/com.arm.doc.den0029a/ diff --git a/Documentation/devicetree/bindings/phy/brcm,cygnus-pcie-phy.txt b/Documentation/devicetree/bindings/phy/brcm,cygnus-pcie-phy.txt new file mode 100644 index 000000000..761c4bc24 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/brcm,cygnus-pcie-phy.txt @@ -0,0 +1,47 @@ +Broadcom Cygnus PCIe PHY + +Required properties: +- compatible: must be "brcm,cygnus-pcie-phy" +- reg: base address and length of the PCIe PHY block +- #address-cells: must be 1 +- #size-cells: must be 0 + +Each PCIe PHY should be represented by a child node + +Required properties For the child node: +- reg: the PHY ID +0 - PCIe RC 0 +1 - PCIe RC 1 +- #phy-cells: must be 0 + +Example: + pcie_phy: phy@0301d0a0 { + compatible = "brcm,cygnus-pcie-phy"; + reg = <0x0301d0a0 0x14>; + + pcie0_phy: phy@0 { + reg = <0>; + #phy-cells = <0>; + }; + + pcie1_phy: phy@1 { + reg = <1>; + #phy-cells = <0>; + }; + }; + + /* users of the PCIe phy */ + + pcie0: pcie@18012000 { + ... + ... + phys = <&pcie0_phy>; + phy-names = "pcie-phy"; + }; + + pcie1: pcie@18013000 { + ... + ... + phys = ; + phy-names = "pcie-phy"; + }; diff --git a/Documentation/devicetree/bindings/phy/calxeda-combophy.txt b/Documentation/devicetree/bindings/phy/calxeda-combophy.txt new file mode 100644 index 000000000..6622bdb2e --- /dev/null +++ b/Documentation/devicetree/bindings/phy/calxeda-combophy.txt @@ -0,0 +1,17 @@ +Calxeda Highbank Combination Phys for SATA + +Properties: +- compatible : Should be "calxeda,hb-combophy" +- #phy-cells: Should be 1. +- reg : Address and size for Combination Phy registers. +- phydev: device ID for programming the combophy. + +Example: + + combophy5: combo-phy@fff5d000 { + compatible = "calxeda,hb-combophy"; + #phy-cells = <1>; + reg = <0xfff5d000 0x1000>; + phydev = <31>; + }; + diff --git a/Documentation/devicetree/bindings/phy/keystone-usb-phy.txt b/Documentation/devicetree/bindings/phy/keystone-usb-phy.txt new file mode 100644 index 000000000..f37b3a863 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/keystone-usb-phy.txt @@ -0,0 +1,20 @@ +TI Keystone USB PHY + +Required properties: + - compatible: should be "ti,keystone-usbphy". + - #address-cells, #size-cells : should be '1' if the device has sub-nodes + with 'reg' property. + - reg : Address and length of the usb phy control register set. + +The main purpose of this PHY driver is to enable the USB PHY reference clock +gate on the Keystone SOC for both the USB2 and USB3 PHY. Otherwise it is just +an NOP PHY driver. Hence this node is referenced as both the usb2 and usb3 +phy node in the USB Glue layer driver node. + +usb_phy: usb_phy@2620738 { + compatible = "ti,keystone-usbphy"; + #address-cells = <1>; + #size-cells = <1>; + reg = <0x2620738 32>; + status = "disabled"; +}; diff --git a/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt b/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt new file mode 100644 index 000000000..379b84a56 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt @@ -0,0 +1,21 @@ +* Freescale MXS USB Phy Device + +Required properties: +- compatible: should contain: + * "fsl,imx23-usbphy" for imx23 and imx28 + * "fsl,imx6q-usbphy" for imx6dq and imx6dl + * "fsl,imx6sl-usbphy" for imx6sl + * "fsl,vf610-usbphy" for Vybrid vf610 + * "fsl,imx6sx-usbphy" for imx6sx + "fsl,imx23-usbphy" is still a fallback for other strings +- reg: Should contain registers location and length +- interrupts: Should contain phy interrupt +- fsl,anatop: phandle for anatop register, it is only for imx6 SoC series + +Example: +usbphy1: usbphy@020c9000 { + compatible = "fsl,imx6q-usbphy", "fsl,imx23-usbphy"; + reg = <0x020c9000 0x1000>; + interrupts = <0 44 0x04>; + fsl,anatop = <&anatop>; +}; diff --git a/Documentation/devicetree/bindings/phy/nvidia,tegra20-usb-phy.txt b/Documentation/devicetree/bindings/phy/nvidia,tegra20-usb-phy.txt new file mode 100644 index 000000000..a9aa79fb9 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/nvidia,tegra20-usb-phy.txt @@ -0,0 +1,72 @@ +Tegra SOC USB PHY + +The device node for Tegra SOC USB PHY: + +Required properties : + - compatible : For Tegra20, must contain "nvidia,tegra20-usb-phy". + For Tegra30, must contain "nvidia,tegra30-usb-phy". Otherwise, must contain + "nvidia,-usb-phy" plus at least one of the above, where is + tegra114, tegra124, tegra132, or tegra210. + - reg : Defines the following set of registers, in the order listed: + - The PHY's own register set. + Always present. + - The register set of the PHY containing the UTMI pad control registers. + Present if-and-only-if phy_type == utmi. + - phy_type : Should be one of "utmi", "ulpi" or "hsic". + - clocks : Defines the clocks listed in the clock-names property. + - clock-names : The following clock names must be present: + - reg: The clock needed to access the PHY's own registers. This is the + associated EHCI controller's clock. Always present. + - pll_u: PLL_U. Always present. + - timer: The timeout clock (clk_m). Present if phy_type == utmi. + - utmi-pads: The clock needed to access the UTMI pad control registers. + Present if phy_type == utmi. + - ulpi-link: The clock Tegra provides to the ULPI PHY (cdev2). + Present if phy_type == ulpi, and ULPI link mode is in use. + - resets : Must contain an entry for each entry in reset-names. + See ../reset/reset.txt for details. + - reset-names : Must include the following entries: + - usb: The PHY's own reset signal. + - utmi-pads: The reset of the PHY containing the chip-wide UTMI pad control + registers. Required even if phy_type == ulpi. + +Required properties for phy_type == ulpi: + - nvidia,phy-reset-gpio : The GPIO used to reset the PHY. + +Required PHY timing params for utmi phy, for all chips: + - nvidia,hssync-start-delay : Number of 480 Mhz clock cycles to wait before + start of sync launches RxActive + - nvidia,elastic-limit : Variable FIFO Depth of elastic input store + - nvidia,idle-wait-delay : Number of 480 Mhz clock cycles of idle to wait + before declare IDLE. + - nvidia,term-range-adj : Range adjusment on terminations + - Either one of the following for HS driver output control: + - nvidia,xcvr-setup : integer, uses the provided value. + - nvidia,xcvr-setup-use-fuses : boolean, indicates that the value is read + from the on-chip fuses + If both are provided, nvidia,xcvr-setup-use-fuses takes precedence. + - nvidia,xcvr-lsfslew : LS falling slew rate control. + - nvidia,xcvr-lsrslew : LS rising slew rate control. + +Required PHY timing params for utmi phy, only on Tegra30 and above: + - nvidia,xcvr-hsslew : HS slew rate control. + - nvidia,hssquelch-level : HS squelch detector level. + - nvidia,hsdiscon-level : HS disconnect detector level. + +Optional properties: + - nvidia,has-legacy-mode : boolean indicates whether this controller can + operate in legacy mode (as APX 2500 / 2600). In legacy mode some + registers are accessed through the APB_MISC base address instead of + the USB controller. + - nvidia,is-wired : boolean. Indicates whether we can do certain kind of power + optimizations for the devices that are always connected. e.g. modem. + - dr_mode : dual role mode. Indicates the working mode for the PHY. Can be + "host", "peripheral", or "otg". Defaults to "host" if not defined. + host means this is a host controller + peripheral means it is device controller + otg means it can operate as either ("on the go") + - nvidia,has-utmi-pad-registers : boolean indicates whether this controller + contains the UTMI pad control registers common to all USB controllers. + +VBUS control (required for dr_mode == otg, optional for dr_mode == host): + - vbus-supply: regulator for VBUS diff --git a/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt new file mode 100644 index 000000000..00100cf3e --- /dev/null +++ b/Documentation/devicetree/bindings/phy/phy-mt65xx-usb.txt @@ -0,0 +1,68 @@ +mt65xx USB3.0 PHY binding +-------------------------- + +This binding describes a usb3.0 phy for mt65xx platforms of Medaitek SoC. + +Required properties (controller (parent) node): + - compatible : should be "mediatek,mt8173-u3phy" + - reg : offset and length of register for phy, exclude port's + register. + - clocks : a list of phandle + clock-specifier pairs, one for each + entry in clock-names + - clock-names : must contain + "u3phya_ref": for reference clock of usb3.0 analog phy. + +Required nodes : a sub-node is required for each port the controller + provides. Address range information including the usual + 'reg' property is used inside these nodes to describe + the controller's topology. + +Required properties (port (child) node): +- reg : address and length of the register set for the port. +- #phy-cells : should be 1 (See second example) + cell after port phandle is phy type from: + - PHY_TYPE_USB2 + - PHY_TYPE_USB3 + +Example: + +u3phy: usb-phy@11290000 { + compatible = "mediatek,mt8173-u3phy"; + reg = <0 0x11290000 0 0x800>; + clocks = <&apmixedsys CLK_APMIXED_REF2USB_TX>; + clock-names = "u3phya_ref"; + #address-cells = <2>; + #size-cells = <2>; + ranges; + status = "okay"; + + phy_port0: port@11290800 { + reg = <0 0x11290800 0 0x800>; + #phy-cells = <1>; + status = "okay"; + }; + + phy_port1: port@11291000 { + reg = <0 0x11291000 0 0x800>; + #phy-cells = <1>; + status = "okay"; + }; +}; + +Specifying phy control of devices +--------------------------------- + +Device nodes should specify the configuration required in their "phys" +property, containing a phandle to the phy port node and a device type; +phy-names for each port are optional. + +Example: + +#include + +usb30: usb@11270000 { + ... + phys = <&phy_port0 PHY_TYPE_USB3>; + phy-names = "usb3-0"; + ... +}; diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-8x16-phy.txt b/Documentation/devicetree/bindings/phy/qcom,usb-8x16-phy.txt new file mode 100644 index 000000000..2cb2168ce --- /dev/null +++ b/Documentation/devicetree/bindings/phy/qcom,usb-8x16-phy.txt @@ -0,0 +1,76 @@ +Qualcomm's APQ8016/MSM8916 USB transceiver controller + +- compatible: + Usage: required + Value type: + Definition: Should contain "qcom,usb-8x16-phy". + +- reg: + Usage: required + Value type: + Definition: USB PHY base address and length of the register map + +- clocks: + Usage: required + Value type: + Definition: See clock-bindings.txt section "consumers". List of + two clock specifiers for interface and core controller + clocks. + +- clock-names: + Usage: required + Value type: + Definition: Must contain "iface" and "core" strings. + +- vddcx-supply: + Usage: required + Value type: + Definition: phandle to the regulator VDCCX supply node. + +- v1p8-supply: + Usage: required + Value type: + Definition: phandle to the regulator 1.8V supply node. + +- v3p3-supply: + Usage: required + Value type: + Definition: phandle to the regulator 3.3V supply node. + +- resets: + Usage: required + Value type: + Definition: See reset.txt section "consumers". PHY reset specifier. + +- reset-names: + Usage: required + Value type: + Definition: Must contain "phy" string. + +- switch-gpio: + Usage: optional + Value type: + Definition: Some boards are using Dual SPDT USB Switch, witch is + controlled by GPIO to de/multiplex D+/D- USB lines + between connectors. + +Example: + usb_phy: phy@78d9000 { + compatible = "qcom,usb-8x16-phy"; + reg = <0x78d9000 0x400>; + + vddcx-supply = <&pm8916_s1_corner>; + v1p8-supply = <&pm8916_l7>; + v3p3-supply = <&pm8916_l13>; + + clocks = <&gcc GCC_USB_HS_AHB_CLK>, + <&gcc GCC_USB_HS_SYSTEM_CLK>; + clock-names = "iface", "core"; + + resets = <&gcc GCC_USB2A_PHY_BCR>; + reset-names = "phy"; + + // D+/D- lines: 1 - Routed to HUB, 0 - Device connector + switch-gpio = <&pm8916_gpios 4 GPIO_ACTIVE_HIGH>; + }; + diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt index 60c6f2a63..0289d3b07 100644 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt @@ -44,6 +44,9 @@ Required properties: - the "ref" clock is used to get the rate of the clock provided to the PHY module +Optional properties: +- vbus-supply: power-supply phandle for vbus power source + The first phandle argument in the PHY specifier identifies the PHY, its meaning is compatible dependent. For the currently supported SoCs (Exynos 4210 and Exynos 4212) it is as follows: diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt index 3c821cda1..b321b2678 100644 --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt @@ -17,6 +17,7 @@ Required properties: "allwinner,sun8i-a23-pinctrl" "allwinner,sun8i-a23-r-pinctrl" "allwinner,sun8i-a33-pinctrl" + "allwinner,sun8i-a83t-pinctrl" - reg: Should contain the register physical address and length for the pin controller. diff --git a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt new file mode 100644 index 000000000..61ac75706 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pio4-pinctrl.txt @@ -0,0 +1,90 @@ +* Atmel PIO4 Controller + +The Atmel PIO4 controller is used to select the function of a pin and to +configure it. + +Required properties: +- compatible: "atmel,sama5d2-pinctrl". +- reg: base address and length of the PIO controller. +- interrupts: interrupt outputs from the controller, one for each bank. +- interrupt-controller: mark the device node as an interrupt controller. +- #interrupt-cells: should be two. +- gpio-controller: mark the device node as a gpio controller. +- #gpio-cells: should be two. + +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for +a general description of GPIO and interrupt bindings. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices. + +Subnode format +Each node (or subnode) will list the pins it needs and how to configured these +pins. + + node { + pinmux = ; + GENERIC_PINCONFIG; + }; + +Required properties: +- pinmux: integer array. Each integer represents a pin number plus mux and +ioset settings. Use the macros from boot/dts/-pinfunc.h file to get the +right representation of the pin. + +Optional properties: +- GENERIC_PINCONFIG: generic pinconfig options to use, bias-disable, +bias-pull-down, bias-pull-up, drive-open-drain, input-schmitt-enable, +input-debounce, output-low, output-high. + +Example: + +#include + +... +{ + pioA: pinctrl@fc038000 { + compatible = "atmel,sama5d2-pinctrl"; + reg = <0xfc038000 0x600>; + interrupts = <18 IRQ_TYPE_LEVEL_HIGH 7>, + <68 IRQ_TYPE_LEVEL_HIGH 7>, + <69 IRQ_TYPE_LEVEL_HIGH 7>, + <70 IRQ_TYPE_LEVEL_HIGH 7>; + interrupt-controller; + #interrupt-cells = <2>; + gpio-controller; + #gpio-cells = <2>; + clocks = <&pioA_clk>; + + pinctrl_i2c0_default: i2c0_default { + pinmux = , + ; + bias-disable; + }; + + pinctrl_led_gpio_default: led_gpio_default { + pinmux = , + ; + bias-pull-up; + }; + + pinctrl_sdmmc1_default: sdmmc1_default { + cmd_data { + pinmux = , + , + , + , + ; + bias-pull-up; + }; + + ck_cd { + pinmux = , + ; + bias-disable; + }; + }; + ... + }; +}; +... diff --git a/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt index a8bb5e260..f8fa28ce1 100644 --- a/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/berlin,pinctrl.txt @@ -20,7 +20,10 @@ Required properties: "marvell,berlin2cd-soc-pinctrl", "marvell,berlin2cd-system-pinctrl", "marvell,berlin2q-soc-pinctrl", - "marvell,berlin2q-system-pinctrl" + "marvell,berlin2q-system-pinctrl", + "marvell,berlin4ct-avio-pinctrl", + "marvell,berlin4ct-soc-pinctrl", + "marvell,berlin4ct-system-pinctrl" Required subnode-properties: - groups: a list of strings describing the group names. diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt b/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt index 6540ca56b..16589fb6f 100644 --- a/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt +++ b/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt @@ -3,8 +3,8 @@ Broadcom Cygnus GPIO/PINCONF Controller Required properties: - compatible: - Must be "brcm,cygnus-ccm-gpio", "brcm,cygnus-asiu-gpio", or - "brcm,cygnus-crmu-gpio" + Must be "brcm,cygnus-ccm-gpio", "brcm,cygnus-asiu-gpio", + "brcm,cygnus-crmu-gpio" or "brcm,iproc-gpio" - reg: Define the base and range of the I/O address space that contains the Cygnus @@ -26,9 +26,13 @@ Optional properties: - interrupt-controller: Specifies that the node is an interrupt controller -- pinmux: - Specifies the phandle to the IOMUX device, where pins can be individually -muxed to GPIO +- gpio-ranges: + Specifies the mapping between gpio controller and pin-controllers pins. + This requires 4 fields in cells defined as - + 1. Phandle of pin-controller. + 2. GPIO base pin offset. + 3 Pin-control base pin offset. + 4. number of gpio pins which are linearly mapped from pin base. Supported generic PINCONF properties in child nodes: @@ -78,6 +82,8 @@ Example: gpio-controller; interrupts = ; interrupt-controller; + gpio-ranges = <&pinctrl 0 42 1>, + <&pinctrl 1 44 3>; }; /* diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt index 8bbf25d58..457b2c68d 100644 --- a/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt @@ -1,16 +1,42 @@ * Freescale i.MX7 Dual IOMUX Controller +iMX7D supports two iomuxc controllers, fsl,imx7d-iomuxc controller is similar +as previous iMX SoC generation and fsl,imx7d-iomuxc-lpsr which provides low +power state retention capabilities on gpios that are part of iomuxc-lpsr +(GPIO1_IO7..GPIO1_IO0). While iomuxc-lpsr provides its own set of registers for +mux and pad control settings, it shares the input select register from main +iomuxc controller for daisy chain settings, the fsl,input-sel property extends +fsl,imx-pinctrl driver to support iomuxc-lpsr controller. + +iomuxc_lpsr: iomuxc-lpsr@302c0000 { + compatible = "fsl,imx7d-iomuxc-lpsr"; + reg = <0x302c0000 0x10000>; + fsl,input-sel = <&iomuxc>; +}; + +iomuxc: iomuxc@30330000 { + compatible = "fsl,imx7d-iomuxc"; + reg = <0x30330000 0x10000>; +}; + +Pheriparials using pads from iomuxc-lpsr support low state retention power +state, under LPSR mode GPIO's state of pads are retain. + Please refer to fsl,imx-pinctrl.txt in this directory for common binding part and usage. Required properties: -- compatible: "fsl,imx7d-iomuxc" +- compatible: "fsl,imx7d-iomuxc" for main IOMUXC controller, or + "fsl,imx7d-iomuxc-lpsr" for Low Power State Retention IOMUXC controller. - fsl,pins: each entry consists of 6 integers and represents the mux and config setting for one pin. The first 5 integers are specified using a PIN_FUNC_ID macro, which can be found in imx7d-pinfunc.h under device tree source folder. The last integer CONFIG is the pad setting value like pull-up on this pin. Please refer to i.MX7 Dual Reference Manual for detailed CONFIG settings. +- fsl,input-sel: required property for iomuxc-lpsr controller, this property is + a phandle for main iomuxc controller which shares the input select register for + daisy chain settings. CONFIG bits definition: PAD_CTL_PUS_100K_DOWN (0 << 5) @@ -25,3 +51,38 @@ PAD_CTL_DSE_X1 (0 << 0) PAD_CTL_DSE_X2 (1 << 0) PAD_CTL_DSE_X3 (2 << 0) PAD_CTL_DSE_X4 (3 << 0) + +Examples: +While iomuxc-lpsr is intended to be used by dedicated peripherals to take +advantages of LPSR power mode, is also possible that an IP to use pads from +any of the iomux controllers. For example the I2C1 IP can use SCL pad from +iomuxc-lpsr controller and SDA pad from iomuxc controller as: + +i2c1: i2c@30a20000 { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_i2c1_1 &pinctrl_i2c1_2>; + status = "okay"; +}; + +iomuxc-lpsr@302c0000 { + compatible = "fsl,imx7d-iomuxc-lpsr"; + reg = <0x302c0000 0x10000>; + fsl,input-sel = <&iomuxc>; + + pinctrl_i2c1_1: i2c1grp-1 { + fsl,pins = < + MX7D_PAD_GPIO1_IO04__I2C1_SCL 0x4000007f + >; + }; +}; + +iomuxc@30330000 { + compatible = "fsl,imx7d-iomuxc"; + reg = <0x30330000 0x10000>; + + pinctrl_i2c1_2: i2c1grp-2 { + fsl,pins = < + MX7D_PAD_I2C1_SDA__I2C1_SDA 0x4000007f + >; + }; +}; diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt index 949693452..ffadb7a37 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt @@ -19,6 +19,7 @@ Required Properties: - "renesas,pfc-r8a7791": for R8A7791 (R-Car M2-W) compatible pin-controller. - "renesas,pfc-r8a7793": for R8A7793 (R-Car M2-N) compatible pin-controller. - "renesas,pfc-r8a7794": for R8A7794 (R-Car E2) compatible pin-controller. + - "renesas,pfc-r8a7795": for R8A7795 (R-Car H3) compatible pin-controller. - "renesas,pfc-sh73a0": for SH73A0 (SH-Mobile AG5) compatible pin-controller. - reg: Base address and length of each memory resource used by the pin diff --git a/Documentation/devicetree/bindings/power/bq24257.txt b/Documentation/devicetree/bindings/power/bq24257.txt index 5c9d3940d..d693702c9 100644 --- a/Documentation/devicetree/bindings/power/bq24257.txt +++ b/Documentation/devicetree/bindings/power/bq24257.txt @@ -1,21 +1,64 @@ -Binding for TI bq24257 Li-Ion Charger +Binding for TI bq24250/bq24251/bq24257 Li-Ion Charger Required properties: - compatible: Should contain one of the following: + * "ti,bq24250" + * "ti,bq24251" * "ti,bq24257" -- reg: integer, i2c address of the device. +- reg: integer, i2c address of the device. +- interrupt-parent: Should be the phandle for the interrupt controller. Use in + conjunction with "interrupts". +- interrupts: Interrupt mapping for GPIO IRQ (configure for both edges). Use in + conjunction with "interrupt-parent". - ti,battery-regulation-voltage: integer, maximum charging voltage in uV. -- ti,charge-current: integer, maximum charging current in uA. -- ti,termination-current: integer, charge will be terminated when current in - constant-voltage phase drops below this value (in uA). +- ti,charge-current: integer, maximum charging current in uA. +- ti,termination-current: integer, charge will be terminated when current in + constant-voltage phase drops below this value (in uA). + +Optional properties: +- pg-gpios: GPIO used for connecting the bq2425x device PG (Power Good) pin. + This pin is not available on all devices however it should be used if + possible as this is the recommended way to obtain the charger's input PG + state. If this pin is not specified a software-based approach for PG + detection is used. +- ti,current-limit: The maximum current to be drawn from the charger's input + (in uA). If this property is not specified, the input limit current is + set automatically using USB D+/D- signal based charger type detection. + If the hardware does not support the D+/D- based detection, a default + of 500,000 is used (=500mA) instead. +- ti,ovp-voltage: Configures the over voltage protection voltage (in uV). If + not specified a default of 6,5000,000 (=6.5V) is used. +- ti,in-dpm-voltage: Configures the threshold input voltage for the dynamic + power path management (in uV). If not specified a default of 4,360,000 + (=4.36V) is used. Example: bq24257 { compatible = "ti,bq24257"; reg = <0x6a>; + interrupt-parent = <&gpio1>; + interrupts = <16 IRQ_TYPE_EDGE_BOTH>; + + pg-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>; ti,battery-regulation-voltage = <4200000>; ti,charge-current = <1000000>; ti,termination-current = <50000>; }; + +Example: + +bq24250 { + compatible = "ti,bq24250"; + reg = <0x6a>; + interrupt-parent = <&gpio1>; + interrupts = <16 IRQ_TYPE_EDGE_BOTH>; + + ti,battery-regulation-voltage = <4200000>; + ti,charge-current = <500000>; + ti,termination-current = <50000>; + ti,current-limit = <900000>; + ti,ovp-voltage = <9500000>; + ti,in-dpm-voltage = <4440000>; +}; diff --git a/Documentation/devicetree/bindings/power/da9150-fg.txt b/Documentation/devicetree/bindings/power/da9150-fg.txt new file mode 100644 index 000000000..00236fe3e --- /dev/null +++ b/Documentation/devicetree/bindings/power/da9150-fg.txt @@ -0,0 +1,23 @@ +Dialog Semiconductor DA9150 Fuel-Gauge Power Supply bindings + +Required properties: +- compatible: "dlg,da9150-fuel-gauge" for DA9150 Fuel-Gauge Power Supply + +Optional properties: +- dlg,update-interval: Interval time (milliseconds) between battery level checks. +- dlg,warn-soc-level: Battery discharge level (%) where warning event raised. + [1 - 100] +- dlg,crit-soc-level: Battery discharge level (%) where critical event raised. + This value should be lower than the warning level. + [1 - 100] + + +Example: + + fuel-gauge { + compatible = "dlg,da9150-fuel-gauge"; + + dlg,update-interval = <10000>; + dlg,warn-soc-level = /bits/ 8 <15>; + dlg,crit-soc-level = /bits/ 8 <5>; + }; diff --git a/Documentation/devicetree/bindings/power/pd-samsung.txt b/Documentation/devicetree/bindings/power/pd-samsung.txt new file mode 100644 index 000000000..4e947372a --- /dev/null +++ b/Documentation/devicetree/bindings/power/pd-samsung.txt @@ -0,0 +1,52 @@ +* Samsung Exynos Power Domains + +Exynos processors include 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. + * samsung,exynos4210-pd - for exynos4210 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: +- 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 + all domains which are powered on and off and not required for unused + domains. +- clock-names: The following clocks can be specified: + - oscclk: Oscillator clock. + - clkN: Input clocks to the devices in this power domain. These clocks + will be reparented to oscclk before swithing power domain off. + Their original parent will be brought back after turning on + the domain. Maximum of 4 clocks (N = 0 to 3) are supported. + - asbN: Clocks required by asynchronous bridges (ASB) present in + the power domain. These clock should be enabled during power + domain on/off operations. +- power-domains: phandle pointing to the parent power domain, for more details + see Documentation/devicetree/bindings/power/power_domain.txt + +Node of a device using power domains must have a power-domains property +defined with a phandle to respective power domain. + +Example: + + lcd0: power-domain-lcd0 { + compatible = "samsung,exynos4210-pd"; + reg = <0x10023C00 0x10>; + #power-domain-cells = <0>; + }; + + mfc_pd: power-domain@10044060 { + compatible = "samsung,exynos4210-pd"; + reg = <0x10044060 0x20>; + clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MOUT_USER_ACLK333>; + clock-names = "oscclk", "clk0"; + #power-domain-cells = <0>; + }; + +See Documentation/devicetree/bindings/power/power_domain.txt for description +of consumer-side bindings. diff --git a/Documentation/devicetree/bindings/power/wakeup-source.txt b/Documentation/devicetree/bindings/power/wakeup-source.txt new file mode 100644 index 000000000..963c6dfd4 --- /dev/null +++ b/Documentation/devicetree/bindings/power/wakeup-source.txt @@ -0,0 +1,71 @@ +Specifying wakeup capability for devices +============================================ + +Any device nodes +---------------- +Nodes that describe devices which has wakeup capability must contain an +"wakeup-source" boolean property. + +Also, if device is marked as a wakeup source, then all the primary +interrupt(s) can be used as wakeup interrupt(s). + +However if the devices have dedicated interrupt as the wakeup source +then they need to specify/identify the same using device specific +interrupt name. In such cases only that interrupt can be used as wakeup +interrupt. + +List of legacy properties and respective binding document +--------------------------------------------------------- + +1. "enable-sdio-wakeup" Documentation/devicetree/bindings/mmc/mmc.txt +2. "gpio-key,wakeup" Documentation/devicetree/bindings/input/gpio-keys{,-polled}.txt +3. "has-tpo" Documentation/devicetree/bindings/rtc/rtc-opal.txt +4. "isil,irq2-can-wakeup-machine" Documentation/devicetree/bindings/rtc/isil,isl12057.txt +5. "linux,wakeup" Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt + Documentation/devicetree/bindings/mfd/tc3589x.txt + Documentation/devicetree/bindings/input/ads7846.txt +6. "linux,keypad-wakeup" Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt +7. "linux,input-wakeup" Documentation/devicetree/bindings/input/samsung-keypad.txt +8. "nvidia,wakeup-source" Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt + +Examples +-------- + +1. With "wakeup" interrupt name + + device@10000 { + compatible = "vendor,device-id"; + reg = <0x10000 0x1000>; + interrupts = <0 19 4>, <0 21 4>, <0 22 4>; + interrupt-names = "ack", "err", "wakeup"; + wakeup-source; + }; + +2. Without "wakeup" interrupt name + + embedded-controller { + compatible = "google,cros-ec-i2c"; + reg = <0x1e>; + interrupts = <6 0>; + interrupt-parent = <&gpx1>; + pinctrl-names = "default"; + pinctrl-0 = <&ec_irq>; + wakeup-source; + }; + +3. Without interrupts + + gpio_keys { + compatible = "gpio-keys"; + #address-cells = <1>; + #size-cells = <0>; + + button@1 { + debounce_interval = <50>; + wakeup-source; + linux,code = <116>; + label = "POWER"; + gpios = <&iofpga_gpio0 0 0x4>; + }; + [....] + }; diff --git a/Documentation/devicetree/bindings/power_supply/axp20x_usb_power.txt b/Documentation/devicetree/bindings/power_supply/axp20x_usb_power.txt new file mode 100644 index 000000000..862f4a49d --- /dev/null +++ b/Documentation/devicetree/bindings/power_supply/axp20x_usb_power.txt @@ -0,0 +1,34 @@ +AXP20x USB power supply + +Required Properties: +-compatible: "x-powers,axp202-usb-power-supply" + +This node is a subnode of the axp20x PMIC. + +Example: + +axp209: pmic@34 { + compatible = "x-powers,axp209"; + reg = <0x34>; + interrupt-parent = <&nmi_intc>; + interrupts = <0 IRQ_TYPE_LEVEL_LOW>; + interrupt-controller; + #interrupt-cells = <1>; + + regulators { + x-powers,dcdc-freq = <1500>; + + vdd_cpu: dcdc2 { + regulator-always-on; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1450000>; + regulator-name = "vdd-cpu"; + }; + + ... + }; + + usb-power-supply: usb-power-supply { + compatible = "x-powers,axp202-usb-power-supply"; + }; +}; diff --git a/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt b/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt new file mode 100644 index 000000000..65b88fac8 --- /dev/null +++ b/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt @@ -0,0 +1,131 @@ +Qualcomm Switch-Mode Battery Charger and Boost + +PROPERTIES +- compatible: + Usage: required + Value type: + Description: Must be one of: + - "qcom,pm8941-charger" + +- reg: + Usage: required + Value type: + Description: Base address of registers for SMBB block + +- interrupts: + Usage: required + Value type: + Description: The format of the specifier is defined by the binding document + describing the node's interrupt parent. Must contain one + specifier for each of the following interrupts, in order: + - charge done + - charge fast mode + - charge trickle mode + - battery temperature ok + - battery present + - charger disconnected + - USB-in valid + - DC-in valid + +- interrupt-names: + Usage: required + Value type: + Description: Must contain the following list, strictly ordered: + "chg-done", + "chg-fast", + "chg-trkl", + "bat-temp-ok", + "bat-present", + "chg-gone", + "usb-valid", + "dc-valid" + +- qcom,fast-charge-current-limit: + Usage: optional (default: 1A, or pre-configured value) + Value type: ; uA; range [100mA : 3A] + Description: Maximum charge current; May be clamped to safety limits. + +- qcom,fast-charge-low-threshold-voltage: + Usage: optional (default: 3.2V, or pre-configured value) + Value type: ; uV; range [2.1V : 3.6V] + Description: Battery voltage limit above which fast charging may operate; + Below this value linear or switch-mode auto-trickle-charging + will operate. + +- qcom,fast-charge-high-threshold-voltage: + Usage: optional (default: 4.2V, or pre-configured value) + Value type: ; uV; range [3.24V : 5V] + Description: Battery voltage limit below which fast charging may operate; + The fast charger will attempt to charge the battery to this + voltage. May be clamped to safety limits. + +- qcom,fast-charge-safe-voltage: + Usage: optional (default: 4.2V, or pre-configured value) + Value type: ; uV; range [3.24V : 5V] + Description: Maximum safe battery voltage; May be pre-set by bootloader, in + which case, setting this will harmlessly fail. The property + 'fast-charge-high-watermark' will be clamped by this value. + +- qcom,fast-charge-safe-current: + Usage: optional (default: 1A, or pre-configured value) + Value type: ; uA; range [100mA : 3A] + Description: Maximum safe battery charge current; May pre-set by bootloader, + in which case, setting this will harmlessly fail. The property + 'qcom,fast-charge-current-limit' will be clamped by this value. + +- qcom,auto-recharge-threshold-voltage: + Usage: optional (default: 4.1V, or pre-configured value) + Value type: ; uV; range [3.24V : 5V] + Description: Battery voltage limit below which auto-recharge functionality + will restart charging after end-of-charge; The high cutoff + limit for auto-recharge is 5% above this value. + +- qcom,minimum-input-voltage: + Usage: optional (default: 4.3V, or pre-configured value) + Value type: ; uV; range [4.2V : 9.6V] + Description: Input voltage level above which charging may operate + +- qcom,dc-current-limit: + Usage: optional (default: 100mA, or pre-configured value) + Value type: ; uA; range [100mA : 2.5A] + Description: Default DC charge current limit + +- qcom,disable-dc: + Usage: optional (default: false) + Value type: boolean: or + Description: Disable DC charger + +- qcom,jeita-extended-temp-range: + Usage: optional (default: false) + Value type: boolean: or + Description: Enable JEITA extended temperature range; This does *not* + adjust the maximum charge voltage or current in the extended + temperature range. It only allows charging when the battery + is in the extended temperature range. Voltage/current + regulation must be done externally to fully comply with + the JEITA safety guidelines if this flag is set. + +EXAMPLE +charger@1000 { + compatible = "qcom,pm8941-charger"; + reg = <0x1000 0x700>; + interrupts = <0x0 0x10 7 IRQ_TYPE_EDGE_BOTH>, + <0x0 0x10 5 IRQ_TYPE_EDGE_BOTH>, + <0x0 0x10 4 IRQ_TYPE_EDGE_BOTH>, + <0x0 0x12 1 IRQ_TYPE_EDGE_BOTH>, + <0x0 0x12 0 IRQ_TYPE_EDGE_BOTH>, + <0x0 0x13 2 IRQ_TYPE_EDGE_BOTH>, + <0x0 0x13 1 IRQ_TYPE_EDGE_BOTH>, + <0x0 0x14 1 IRQ_TYPE_EDGE_BOTH>; + interrupt-names = "chg-done", + "chg-fast", + "chg-trkl", + "bat-temp-ok", + "bat-present", + "chg-gone", + "usb-valid", + "dc-valid"; + + qcom,fast-charge-current-limit = <1000000>; + qcom,dc-charge-current-limit = <1000000>; +}; diff --git a/Documentation/devicetree/bindings/power_supply/tps65217_charger.txt b/Documentation/devicetree/bindings/power_supply/tps65217_charger.txt new file mode 100644 index 000000000..98d131ace --- /dev/null +++ b/Documentation/devicetree/bindings/power_supply/tps65217_charger.txt @@ -0,0 +1,12 @@ +TPS65217 Charger + +Required Properties: +-compatible: "ti,tps65217-charger" + +This node is a subnode of the tps65217 PMIC. + +Example: + + tps65217-charger { + compatible = "ti,tps65090-charger"; + }; diff --git a/Documentation/devicetree/bindings/powerpc/fsl/board.txt b/Documentation/devicetree/bindings/powerpc/fsl/board.txt deleted file mode 100644 index cff38bdbc..000000000 --- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt +++ /dev/null @@ -1,102 +0,0 @@ -Freescale Reference Board Bindings - -This document describes device tree bindings for various devices that -exist on some Freescale reference boards. - -* Board Control and Status (BCSR) - -Required properties: - - - compatible : Should be "fsl,-bcsr" - - reg : Offset and length of the register set for the device - -Example: - - bcsr@f8000000 { - compatible = "fsl,mpc8360mds-bcsr"; - reg = ; - }; - -* Freescale on-board FPGA - -This is the memory-mapped registers for on board FPGA. - -Required properities: -- compatible: should be a board-specific string followed by a string - indicating the type of FPGA. Example: - "fsl,-fpga", "fsl,fpga-pixis" -- reg: should contain the address and the length of the FPGA register set. -- interrupt-parent: should specify phandle for the interrupt controller. -- interrupts: should specify event (wakeup) IRQ. - -Example (P1022DS): - - board-control@3,0 { - compatible = "fsl,p1022ds-fpga", "fsl,fpga-ngpixis"; - reg = <3 0 0x30>; - interrupt-parent = <&mpic>; - interrupts = <8 8 0 0>; - }; - -* Freescale BCSR GPIO banks - -Some BCSR registers act as simple GPIO controllers, each such -register can be represented by the gpio-controller node. - -Required properities: -- compatible : Should be "fsl,-bcsr-gpio". -- reg : Should contain the address and the length of the GPIO bank - register. -- #gpio-cells : Should be two. The first cell is the pin number and the - second cell is used to specify optional parameters (currently unused). -- gpio-controller : Marks the port as GPIO controller. - -Example: - - bcsr@1,0 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "fsl,mpc8360mds-bcsr"; - reg = <1 0 0x8000>; - ranges = <0 1 0 0x8000>; - - bcsr13: gpio-controller@d { - #gpio-cells = <2>; - compatible = "fsl,mpc8360mds-bcsr-gpio"; - reg = <0xd 1>; - gpio-controller; - }; - }; - -* Freescale on-board FPGA connected on I2C bus - -Some Freescale boards like BSC9132QDS have on board FPGA connected on -the i2c bus. - -Required properties: -- compatible: Should be a board-specific string followed by a string - indicating the type of FPGA. Example: - "fsl,-fpga", "fsl,fpga-qixis-i2c" -- reg: Should contain the address of the FPGA - -Example: - fpga: fpga@66 { - compatible = "fsl,bsc9132qds-fpga", "fsl,fpga-qixis-i2c"; - reg = <0x66>; - }; - -* Freescale on-board CPLD - -Some Freescale boards like T1040RDB have an on board CPLD connected. - -Required properties: -- compatible: Should be a board-specific string like "fsl,-cpld" - Example: - "fsl,t1040rdb-cpld", "fsl,t1042rdb-cpld", "fsl,t1042rdb_pi-cpld" -- reg: should describe CPLD registers - -Example: - cpld@3,0 { - compatible = "fsl,t1040rdb-cpld"; - reg = <3 0 0x300>; - }; diff --git a/Documentation/devicetree/bindings/powerpc/fsl/mpc512x_lpbfifo.txt b/Documentation/devicetree/bindings/powerpc/fsl/mpc512x_lpbfifo.txt new file mode 100644 index 000000000..b3b392fe1 --- /dev/null +++ b/Documentation/devicetree/bindings/powerpc/fsl/mpc512x_lpbfifo.txt @@ -0,0 +1,21 @@ +Freescale MPC512x LocalPlus Bus FIFO (called SCLPC in the Reference Manual) + +Required properties: +- compatible: should be "fsl,mpc512x-lpbfifo"; +- reg: should contain the offset and length of SCLPC register set; +- interrupts: should contain the interrupt specifier for SCLPC; syntax of an + interrupt client node is described in interrupt-controller/interrupts.txt; +- dmas: should contain the DMA specifier for SCLPC as described at + dma/dma.txt and dma/mpc512x-dma.txt; +- dma-names: should be "rx-tx"; + +Example: + + sclpc@10100 { + compatible = "fsl,mpc512x-lpbfifo"; + reg = <0x10100 0x50>; + interrupts = <7 0x8>; + dmas = <&dma0 26>; + dma-names = "rx-tx"; + }; + diff --git a/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.txt b/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.txt new file mode 100644 index 000000000..d9254a6da --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.txt @@ -0,0 +1,20 @@ +Broadcom BCM7038 PWM controller (BCM7xxx Set Top Box PWM controller) + +Required properties: + +- compatible: must be "brcm,bcm7038-pwm" +- reg: physical base address and length for this controller +- #pwm-cells: should be 2. See pwm.txt in this directory for a description + of the cells format +- clocks: a phandle to the reference clock for this block which is fed through + its internal variable clock frequency generator + + +Example: + + pwm: pwm@f0408000 { + compatible = "brcm,bcm7038-pwm"; + reg = <0xf0408000 0x28>; + #pwm-cells = <2>; + clocks = <&upg_fixed>; + }; diff --git a/Documentation/devicetree/bindings/pwm/pwm-berlin.txt b/Documentation/devicetree/bindings/pwm/pwm-berlin.txt new file mode 100644 index 000000000..82cbe16fc --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/pwm-berlin.txt @@ -0,0 +1,17 @@ +Berlin PWM controller + +Required properties: +- compatible: should be "marvell,berlin-pwm" +- reg: physical base address and length of the controller's registers +- clocks: phandle to the input clock +- #pwm-cells: should be 3. See pwm.txt in this directory for a description of + the cells format. + +Example: + +pwm: pwm@f7f20000 { + compatible = "marvell,berlin-pwm"; + reg = <0xf7f20000 0x40>; + clocks = <&chip_clk CLKID_CFG>; + #pwm-cells = <3>; +} diff --git a/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt new file mode 100644 index 000000000..f8f59baf6 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt @@ -0,0 +1,42 @@ +MediaTek display PWM controller + +Required properties: + - compatible: should be "mediatek,-disp-pwm": + - "mediatek,mt8173-disp-pwm": found on mt8173 SoC. + - "mediatek,mt6595-disp-pwm": found on mt6595 SoC. + - reg: physical base address and length of the controller's registers. + - #pwm-cells: must be 2. See pwm.txt in this directory for a description of + the cell format. + - clocks: phandle and clock specifier of the PWM reference clock. + - clock-names: must contain the following: + - "main": clock used to generate PWM signals. + - "mm": sync signals from the modules of mmsys. + - pinctrl-names: Must contain a "default" entry. + - pinctrl-0: One property must exist for each entry in pinctrl-names. + See pinctrl/pinctrl-bindings.txt for details of the property values. + +Example: + pwm0: pwm@1401e000 { + compatible = "mediatek,mt8173-disp-pwm", + "mediatek,mt6595-disp-pwm"; + reg = <0 0x1401e000 0 0x1000>; + #pwm-cells = <2>; + clocks = <&mmsys CLK_MM_DISP_PWM026M>, + <&mmsys CLK_MM_DISP_PWM0MM>; + clock-names = "main", "mm"; + pinctrl-names = "default"; + pinctrl-0 = <&disp_pwm0_pins>; + }; + + backlight_lcd: backlight_lcd { + compatible = "pwm-backlight"; + pwms = <&pwm0 0 1000000>; + brightness-levels = < + 0 16 32 48 64 80 96 112 + 128 144 160 176 192 208 224 240 + 255 + >; + default-brightness-level = <9>; + power-supply = <&mt6397_vio18_reg>; + enable-gpios = <&pio 95 GPIO_ACTIVE_HIGH>; + }; diff --git a/Documentation/devicetree/bindings/pwm/pwm-sun4i.txt b/Documentation/devicetree/bindings/pwm/pwm-sun4i.txt index ae0273e19..cf6068b8e 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-sun4i.txt +++ b/Documentation/devicetree/bindings/pwm/pwm-sun4i.txt @@ -3,6 +3,8 @@ Allwinner sun4i and sun7i SoC PWM controller Required properties: - compatible: should be one of: - "allwinner,sun4i-a10-pwm" + - "allwinner,sun5i-a10s-pwm" + - "allwinner,sun5i-a13-pwm" - "allwinner,sun7i-a20-pwm" - reg: physical base address and length of the controller's registers - #pwm-cells: should be 3. See pwm.txt in this directory for a description of diff --git a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt new file mode 100644 index 000000000..0822a083f --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.txt @@ -0,0 +1,26 @@ +* Renesas R-Car PWM Timer Controller + +Required Properties: +- compatible: should be "renesas,pwm-rcar" and one of the following. + - "renesas,pwm-r8a7778": for R-Car M1A + - "renesas,pwm-r8a7779": for R-Car H1 + - "renesas,pwm-r8a7790": for R-Car H2 + - "renesas,pwm-r8a7791": for R-Car M2-W + - "renesas,pwm-r8a7794": for R-Car E2 +- reg: base address and length of the registers block for the PWM. +- #pwm-cells: should be 2. See pwm.txt in this directory for a description of + the cells format. +- clocks: clock phandle and specifier pair. +- pinctrl-0: phandle, referring to a default pin configuration node. +- pinctrl-names: Set to "default". + +Example: R8A7790 (R-Car H2) PWM Timer node + + pwm0: pwm@e6e30000 { + compatible = "renesas,pwm-r8a7790", "renesas,pwm-rcar"; + reg = <0 0xe6e30000 0 0x8>; + #pwm-cells = <2>; + clocks = <&mstp5_clks R8A7790_CLK_PWM>; + pinctrl-0 = <&pwm0_pins>; + pinctrl-names = "default"; + }; diff --git a/Documentation/devicetree/bindings/regulator/act8865-regulator.txt b/Documentation/devicetree/bindings/regulator/act8865-regulator.txt index e91485d11..6067d9830 100644 --- a/Documentation/devicetree/bindings/regulator/act8865-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/act8865-regulator.txt @@ -8,6 +8,8 @@ Required properties: Optional properties: - system-power-controller: Telling whether or not this pmic is controlling the system power. See Documentation/devicetree/bindings/power/power-controller.txt . +- active-semi,vsel-high: Indicates the VSEL pin is high. + If this property is missing, assume the VSEL pin is low(0). Optional input supply properties: - for act8600: @@ -49,6 +51,7 @@ Example: pmic: act8865@5b { compatible = "active-semi,act8865"; reg = <0x5b>; + active-semi,vsel-high; status = "disabled"; regulators { diff --git a/Documentation/devicetree/bindings/regulator/anatop-regulator.txt b/Documentation/devicetree/bindings/regulator/anatop-regulator.txt index 758eae240..37c4ea076 100644 --- a/Documentation/devicetree/bindings/regulator/anatop-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/anatop-regulator.txt @@ -13,6 +13,7 @@ Optional properties: - anatop-delay-reg-offset: Anatop MFD step time register offset - anatop-delay-bit-shift: Bit shift for the step time register - anatop-delay-bit-width: Number of bits used in the step time register +- vin-supply: The supply for this regulator Any property defined as part of the core regulator binding, defined in regulator.txt, can also be used. diff --git a/Documentation/devicetree/bindings/regulator/arizona-regulator.txt b/Documentation/devicetree/bindings/regulator/arizona-regulator.txt new file mode 100644 index 000000000..443564d77 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/arizona-regulator.txt @@ -0,0 +1,17 @@ +Cirrus Logic Arizona class audio SoCs + +These devices are audio SoCs with extensive digital capabilities and a range +of analogue I/O. + +This document lists regulator specific bindings, see the primary binding +document: + ../mfd/arizona.txt + +Optional properties: + - wlf,ldoena : GPIO specifier for the GPIO controlling LDOENA + +Optional subnodes: + - ldo1 : Initial data for the LDO1 regulator, as covered in + Documentation/devicetree/bindings/regulator/regulator.txt + - micvdd : Initial data for the MICVDD regulator, as covered in + Documentation/devicetree/bindings/regulator/regulator.txt diff --git a/Documentation/devicetree/bindings/regulator/max77802.txt b/Documentation/devicetree/bindings/regulator/max77802.txt index 79e547644..09d796ed4 100644 --- a/Documentation/devicetree/bindings/regulator/max77802.txt +++ b/Documentation/devicetree/bindings/regulator/max77802.txt @@ -8,7 +8,28 @@ regulators that can be controlled over I2C. Following properties should be present in main device node of the MFD chip. -Optional node: +Optional properties: +- inb1-supply: The input supply for BUCK1 +- inb2-supply: The input supply for BUCK2 +- inb3-supply: The input supply for BUCK3 +- inb4-supply: The input supply for BUCK4 +- inb5-supply: The input supply for BUCK5 +- inb6-supply: The input supply for BUCK6 +- inb7-supply: The input supply for BUCK7 +- inb8-supply: The input supply for BUCK8 +- inb9-supply: The input supply for BUCK9 +- inb10-supply: The input supply for BUCK10 +- inl1-supply: The input supply for LDO8 and LDO15 +- inl2-supply: The input supply for LDO17, LDO27, LDO30 and LDO35 +- inl3-supply: The input supply for LDO3, LDO5, LDO6 and LDO7 +- inl4-supply: The input supply for LDO10, LDO11, LDO13 and LDO14 +- inl5-supply: The input supply for LDO9 and LDO19 +- inl6-supply: The input supply for LDO4, LDO21, LDO24 and LDO33 +- inl7-supply: The input supply for LDO18, LDO20, LDO28 and LDO29 +- inl9-supply: The input supply for LDO12, LDO23, LDO25, LDO26, LDO32 and LDO34 +- inl10-supply: The input supply for LDO1 and LDO2 + +Optional nodes: - regulators : The regulators of max77802 have to be instantiated under subnode named "regulators" using the following format. @@ -58,6 +79,8 @@ Example: #address-cells = <1>; #size-cells = <0>; + inb1-supply = <&parent_reg>; + regulators { ldo1_reg: LDO1 { regulator-name = "vdd_1v0"; diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt index 24bd422ce..1d112fc45 100644 --- a/Documentation/devicetree/bindings/regulator/regulator.txt +++ b/Documentation/devicetree/bindings/regulator/regulator.txt @@ -11,6 +11,7 @@ Optional properties: - regulator-always-on: boolean, regulator should never be disabled - regulator-boot-on: bootloader/firmware enabled regulator - regulator-allow-bypass: allow the regulator to go into bypass mode +- regulator-allow-set-load: allow the regulator performance level to be configured - -supply: phandle to the parent supply/regulator node - regulator-ramp-delay: ramp delay for regulator(in uV/uS) For hardware which supports disabling ramp rate, it should be explicitly diff --git a/Documentation/devicetree/bindings/regulator/tps65023.txt b/Documentation/devicetree/bindings/regulator/tps65023.txt new file mode 100644 index 000000000..a4714e4da --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/tps65023.txt @@ -0,0 +1,60 @@ +TPS65023 family of regulators + +Required properties: +- compatible: Must be one of the following. + "ti,tps65020", + "ti,tps65021", + "ti,tps65023", +- reg: I2C slave address +- regulators: list of regulators provided by this controller, must be named + after their hardware counterparts: VDCDC[1-3] and LDO[1-2] +- regulators: This is the list of child nodes that specify the regulator + initialization data for defined regulators. The definition for each of + these nodes is defined using the standard binding for regulators found at + Documentation/devicetree/bindings/regulator/regulator.txt. + +Each regulator is defined using the standard binding for regulators. + +Example: + + tps65023@48 { + compatible = "ti,tps65023"; + reg = <0x48>; + + regulators { + VDCDC1 { + regulator-name = "vdd_mpu"; + regulator-always-on; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + }; + + VDCDC2 { + regulator-name = "vdd_core"; + regulator-always-on; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + }; + + VDCDC3 { + regulator-name = "vdd_io"; + regulator-always-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + }; + + LDO1 { + regulator-name = "vdd_usb18"; + regulator-always-on; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + }; + + LDO2 { + regulator-name = "vdd_usb33"; + regulator-always-on; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/rng/atmel-trng.txt b/Documentation/devicetree/bindings/rng/atmel-trng.txt new file mode 100644 index 000000000..4ac5aaa2d --- /dev/null +++ b/Documentation/devicetree/bindings/rng/atmel-trng.txt @@ -0,0 +1,16 @@ +Atmel TRNG (True Random Number Generator) block + +Required properties: +- compatible : Should be "atmel,at91sam9g45-trng" +- reg : Offset and length of the register set of this block +- interrupts : the interrupt number for the TRNG block +- clocks: should contain the TRNG clk source + +Example: + +trng@fffcc000 { + compatible = "atmel,at91sam9g45-trng"; + reg = <0xfffcc000 0x4000>; + interrupts = <6 IRQ_TYPE_LEVEL_HIGH 0>; + clocks = <&trng_clk>; +}; diff --git a/Documentation/devicetree/bindings/rng/brcm,iproc-rng200.txt b/Documentation/devicetree/bindings/rng/brcm,iproc-rng200.txt new file mode 100644 index 000000000..e25a45666 --- /dev/null +++ b/Documentation/devicetree/bindings/rng/brcm,iproc-rng200.txt @@ -0,0 +1,12 @@ +HWRNG support for the iproc-rng200 driver + +Required properties: +- compatible : "brcm,iproc-rng200" +- reg : base address and size of control register block + +Example: + +rng { + compatible = "brcm,iproc-rng200"; + reg = <0x18032000 0x28>; +}; diff --git a/Documentation/devicetree/bindings/rng/omap_rng.txt b/Documentation/devicetree/bindings/rng/omap_rng.txt new file mode 100644 index 000000000..6a62acd86 --- /dev/null +++ b/Documentation/devicetree/bindings/rng/omap_rng.txt @@ -0,0 +1,22 @@ +OMAP SoC HWRNG Module + +Required properties: + +- compatible : Should contain entries for this and backward compatible + RNG versions: + - "ti,omap2-rng" for OMAP2. + - "ti,omap4-rng" for OMAP4, OMAP5 and AM33XX. + Note that these two versions are incompatible. +- ti,hwmods: Name of the hwmod associated with the RNG module +- reg : Offset and length of the register set for the module +- interrupts : the interrupt number for the RNG module. + Only used for "ti,omap4-rng". + +Example: +/* AM335x */ +rng: rng@48310000 { + compatible = "ti,omap4-rng"; + ti,hwmods = "rng"; + reg = <0x48310000 0x2000>; + interrupts = <111>; +}; diff --git a/Documentation/devicetree/bindings/rng/samsung,exynos-rng4.txt b/Documentation/devicetree/bindings/rng/samsung,exynos-rng4.txt new file mode 100644 index 000000000..4ca8dd4d7 --- /dev/null +++ b/Documentation/devicetree/bindings/rng/samsung,exynos-rng4.txt @@ -0,0 +1,17 @@ +Exynos Pseudo Random Number Generator + +Required properties: + +- compatible : Should be "samsung,exynos4-rng". +- reg : Specifies base physical address and size of the registers map. +- clocks : Phandle to clock-controller plus clock-specifier pair. +- clock-names : "secss" as a clock name. + +Example: + + rng@10830400 { + compatible = "samsung,exynos4-rng"; + reg = <0x10830400 0x200>; + clocks = <&clock CLK_SSS>; + clock-names = "secss"; + }; diff --git a/Documentation/devicetree/bindings/rng/st,rng.txt b/Documentation/devicetree/bindings/rng/st,rng.txt new file mode 100644 index 000000000..35734bc28 --- /dev/null +++ b/Documentation/devicetree/bindings/rng/st,rng.txt @@ -0,0 +1,15 @@ +STMicroelectronics HW Random Number Generator +---------------------------------------------- + +Required parameters: +compatible : Should be "st,rng" +reg : Base address and size of IP's register map. +clocks : Phandle to device's clock (See: ../clocks/clock-bindings.txt) + +Example: + +rng@fee80000 { + compatible = "st,rng"; + reg = <0xfee80000 0x1000>; + clocks = <&clk_sysin>; +} diff --git a/Documentation/devicetree/bindings/rng/st,stm32-rng.txt b/Documentation/devicetree/bindings/rng/st,stm32-rng.txt new file mode 100644 index 000000000..47f04176f --- /dev/null +++ b/Documentation/devicetree/bindings/rng/st,stm32-rng.txt @@ -0,0 +1,21 @@ +STMicroelectronics STM32 HW RNG +=============================== + +The STM32 hardware random number generator is a simple fixed purpose IP and +is fully separated from other crypto functions. + +Required properties: + +- compatible : Should be "st,stm32-rng" +- reg : Should be register base and length as documented in the datasheet +- interrupts : The designated IRQ line for the RNG +- clocks : The clock needed to enable the RNG + +Example: + + rng: rng@50060800 { + compatible = "st,stm32-rng"; + reg = <0x50060800 0x400>; + interrupts = <80>; + clocks = <&rcc 0 38>; + }; diff --git a/Documentation/devicetree/bindings/rng/timeriomem_rng.txt b/Documentation/devicetree/bindings/rng/timeriomem_rng.txt new file mode 100644 index 000000000..6616d1586 --- /dev/null +++ b/Documentation/devicetree/bindings/rng/timeriomem_rng.txt @@ -0,0 +1,18 @@ +HWRNG support for the timeriomem_rng driver + +Required properties: +- compatible : "timeriomem_rng" +- reg : base address to sample from +- period : wait time in microseconds to use between samples + +N.B. currently 'reg' must be four bytes wide and aligned + +Example: + +hwrng@44 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "timeriomem_rng"; + reg = <0x44 0x04>; + period = <1000000>; +}; diff --git a/Documentation/devicetree/bindings/rtc/dallas,ds1390.txt b/Documentation/devicetree/bindings/rtc/dallas,ds1390.txt new file mode 100644 index 000000000..8e76f2648 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/dallas,ds1390.txt @@ -0,0 +1,18 @@ +* Dallas DS1390 SPI Serial Real-Time Clock + +Required properties: +- compatible: Should contain "dallas,ds1390". +- reg: SPI address for chip + +Optional properties: +- trickle-resistor-ohms : Selected resistor for trickle charger + Values usable for ds1390 are 250, 2000, 4000 + Should be given if trickle charger should be enabled +- trickle-diode-disable : Do not use internal trickle charger diode + Should be given if internal trickle charger diode should be disabled +Example: + ds1390: rtc@68 { + compatible = "dallas,ds1390"; + trickle-resistor-ohms = <250>; + reg = <0>; + }; diff --git a/Documentation/devicetree/bindings/rtc/isil,isl12057.txt b/Documentation/devicetree/bindings/rtc/isil,isl12057.txt index 501c39cea..cf83e0940 100644 --- a/Documentation/devicetree/bindings/rtc/isil,isl12057.txt +++ b/Documentation/devicetree/bindings/rtc/isil,isl12057.txt @@ -5,7 +5,7 @@ consisting of a compatible field, an address and possibly an interrupt line). Nonetheless, it also supports an option boolean property -("isil,irq2-can-wakeup-machine") to handle the specific use-case found +("wakeup-source") to handle the specific use-case found on at least three in-tree users of the chip (NETGEAR ReadyNAS 102, 104 and 2120 ARM-based NAS); On those devices, the IRQ#2 pin of the chip (associated with the alarm supported by the driver) is not connected @@ -22,9 +22,9 @@ Required properties supported by the device: Optional properties: - - "isil,irq2-can-wakeup-machine": mark the chip as a wakeup source, - independently of the availability of an IRQ line connected to the - SoC. + - "wakeup-source": mark the chip as a wakeup source, independently of + the availability of an IRQ line connected to the SoC. + (Legacy property supported: "isil,irq2-can-wakeup-machine") - "interrupt-parent", "interrupts": for passing the interrupt line of the SoC connected to IRQ#2 of the RTC chip. @@ -74,5 +74,5 @@ PMIC, allowing the device to be started based on configured alarm: isl12057: isl12057@68 { compatible = "isil,isl12057"; reg = <0x68>; - isil,irq2-can-wakeup-machine; + wakeup-source; }; diff --git a/Documentation/devicetree/bindings/rtc/pcf8563.txt b/Documentation/devicetree/bindings/rtc/pcf8563.txt new file mode 100644 index 000000000..72f6d2c96 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/pcf8563.txt @@ -0,0 +1,25 @@ +* Philips PCF8563/Epson RTC8564 Real Time Clock + +Philips PCF8563/Epson RTC8564 Real Time Clock + +Required properties: +see: Documentation/devicetree/bindings/i2c/trivial-devices.txt + +Optional property: +- #clock-cells: Should be 0. +- clock-output-names: + overwrite the default clock name "pcf8563-clkout" + +Example: + +pcf8563: pcf8563@51 { + compatible = "nxp,pcf8563"; + reg = <0x51>; + #clock-cells = <0>; +}; + +device { +... + clocks = <&pcf8563>; +... +}; diff --git a/Documentation/devicetree/bindings/rtc/rtc-opal.txt b/Documentation/devicetree/bindings/rtc/rtc-opal.txt index af87e5eca..a1734e5cb 100644 --- a/Documentation/devicetree/bindings/rtc/rtc-opal.txt +++ b/Documentation/devicetree/bindings/rtc/rtc-opal.txt @@ -5,12 +5,13 @@ Required properties: - comapatible: Should be "ibm,opal-rtc" Optional properties: -- has-tpo: Decides if the wakeup is supported or not. +- wakeup-source: Decides if the wakeup is supported or not + (Legacy property supported: "has-tpo") Example: rtc { compatible = "ibm,opal-rtc"; - has-tpo; + wakeup-source; phandle = <0x10000029>; linux,phandle = <0x10000029>; }; diff --git a/Documentation/devicetree/bindings/serial/ingenic,uart.txt b/Documentation/devicetree/bindings/serial/ingenic,uart.txt index c2d3b3abe..02cb7fe59 100644 --- a/Documentation/devicetree/bindings/serial/ingenic,uart.txt +++ b/Documentation/devicetree/bindings/serial/ingenic,uart.txt @@ -1,7 +1,8 @@ * Ingenic SoC UART Required properties: -- compatible : "ingenic,jz4740-uart" or "ingenic,jz4780-uart" +- compatible : "ingenic,jz4740-uart", "ingenic,jz4760-uart", + "ingenic,jz4775-uart" or "ingenic,jz4780-uart" - reg : offset and length of the register set for the device. - interrupts : should contain uart interrupt. - clocks : phandles to the module & baud clocks. diff --git a/Documentation/devicetree/bindings/serial/mrvl,pxa-ssp.txt b/Documentation/devicetree/bindings/serial/mrvl,pxa-ssp.txt index 669b8140d..d10cc06c0 100644 --- a/Documentation/devicetree/bindings/serial/mrvl,pxa-ssp.txt +++ b/Documentation/devicetree/bindings/serial/mrvl,pxa-ssp.txt @@ -10,7 +10,6 @@ Required properties: mvrl,pxa168-ssp mrvl,pxa910-ssp mrvl,ce4100-ssp - mrvl,lpss-ssp - reg: The memory base - dmas: Two dma phandles, one for rx, one for tx diff --git a/Documentation/devicetree/bindings/serial/pl011.txt b/Documentation/devicetree/bindings/serial/pl011.txt index cbae3d9a0..77863aefe 100644 --- a/Documentation/devicetree/bindings/serial/pl011.txt +++ b/Documentation/devicetree/bindings/serial/pl011.txt @@ -19,7 +19,7 @@ Optional properties: must correspond to the PCLK clocking the internal logic of the block. Just listing one clock (the first one) is deprecated. -- clocks-names: +- clock-names: When present, the first clock listed must be named "uartclk" and the second clock listed must be named "apb_pclk" diff --git a/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt b/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt index a2114c217..182777fac 100644 --- a/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt +++ b/Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt @@ -26,6 +26,12 @@ Required properties: Optional properties: - dmas: Should contain dma specifiers for transmit and receive channels - dma-names: Should contain "tx" for transmit and "rx" for receive channels +- qcom,tx-crci: Identificator for Client Rate Control Interface to be + used with TX DMA channel. Required when using DMA for transmission + with UARTDM v1.3 and bellow. +- qcom,rx-crci: Identificator for Client Rate Control Interface to be + used with RX DMA channel. Required when using DMA for reception + with UARTDM v1.3 and bellow. Note: Aliases may be defined to ensure the correct ordering of the UARTs. The alias serialN will result in the UART being assigned port N. If any diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt index e84b13a8e..73f825e5e 100644 --- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt +++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt @@ -23,6 +23,8 @@ Required properties: - "renesas,scifa-r8a7794" for R8A7794 (R-Car E2) SCIFA compatible UART. - "renesas,scifb-r8a7794" for R8A7794 (R-Car E2) SCIFB compatible UART. - "renesas,hscif-r8a7794" for R8A7794 (R-Car E2) HSCIF compatible UART. + - "renesas,scif-r8a7795" for R8A7795 (R-Car H3) SCIF compatible UART. + - "renesas,hscif-r8a7795" for R8A7795 (R-Car H3) HSCIF compatible UART. - "renesas,scifa-sh73a0" for SH73A0 (SH-Mobile AG5) SCIFA compatible UART. - "renesas,scifb-sh73a0" for SH73A0 (SH-Mobile AG5) SCIFB compatible UART. - "renesas,scif" for generic SCIF compatible UART. diff --git a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.txt b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.txt index 289c40ed7..12bbe9f22 100644 --- a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.txt +++ b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.txt @@ -15,6 +15,9 @@ The supplying peripheral clock can also be handled, needing a second property Required elements: "baudclk", "apb_pclk" Optional properties: +- snps,uart-16550-compatible : reflects the value of UART_16550_COMPATIBLE + configuration parameter. Define this if your UART does not implement the busy + functionality. - resets : phandle to the parent reset controller. - reg-shift : quantity to shift the register offsets by. If this property is not present then the register offsets are not shifted. diff --git a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt index c0511142b..a6c8afc83 100644 --- a/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt +++ b/Documentation/devicetree/bindings/soc/mediatek/scpsys.txt @@ -17,9 +17,9 @@ Required properties: - reg: Address range of the SCPSYS unit - infracfg: must contain a phandle to the infracfg controller - clock, clock-names: clocks according to the common clock binding. - The clocks needed "mm" and "mfg". These are the - clocks which hardware needs to be enabled before - enabling certain power domains. + The clocks needed "mm", "mfg", "venc" and "venc_lt". + These are the clocks which hardware needs to be enabled + before enabling certain power domains. Example: @@ -30,7 +30,9 @@ Example: infracfg = <&infracfg>; clocks = <&clk26m>, <&topckgen CLK_TOP_MM_SEL>; - clock-names = "mfg", "mm"; + <&topckgen CLK_TOP_VENC_SEL>, + <&topckgen CLK_TOP_VENC_LT_SEL>; + clock-names = "mfg", "mm", "venc", "venc_lt"; }; Example consumer: diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smem.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,smem.txt new file mode 100644 index 000000000..9326cdf6e --- /dev/null +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smem.txt @@ -0,0 +1,57 @@ +Qualcomm Shared Memory Manager binding + +This binding describes the Qualcomm Shared Memory Manager, used to share data +between various subsystems and OSes in Qualcomm platforms. + +- compatible: + Usage: required + Value type: + Definition: must be: + "qcom,smem" + +- memory-region: + Usage: required + Value type: + Definition: handle to memory reservation for main SMEM memory region. + +- qcom,rpm-msg-ram: + Usage: required + Value type: + Definition: handle to RPM message memory resource + +- hwlocks: + Usage: required + Value type: + Definition: reference to a hwspinlock used to protect allocations from + the shared memory + += EXAMPLE +The following example shows the SMEM setup for MSM8974, with a main SMEM region +at 0xfa00000 and the RPM message ram at 0xfc428000: + + reserved-memory { + #address-cells = <1>; + #size-cells = <1>; + ranges; + + smem_region: smem@fa00000 { + reg = <0xfa00000 0x200000>; + no-map; + }; + }; + + smem@fa00000 { + compatible = "qcom,smem"; + + memory-region = <&smem_region>; + qcom,rpm-msg-ram = <&rpm_msg_ram>; + + hwlocks = <&tcsr_mutex 3>; + }; + + soc { + rpm_msg_ram: memory@fc428000 { + compatible = "qcom,rpm-msg-ram"; + reg = <0xfc428000 0x4000>; + }; + }; diff --git a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt new file mode 100644 index 000000000..112756e11 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt @@ -0,0 +1,46 @@ +* Rockchip Power Domains + +Rockchip processors include support for multiple power domains which can be +powered up/down by software based on different application scenes to save power. + +Required properties for power domain controller: +- compatible: Should be one of the following. + "rockchip,rk3288-power-controller" - for RK3288 SoCs. +- #power-domain-cells: Number of cells in a power-domain specifier. + Should be 1 for multiple PM domains. +- #address-cells: Should be 1. +- #size-cells: Should be 0. + +Required properties for power domain sub nodes: +- reg: index of the power domain, should use macros in: + "include/dt-bindings/power/rk3288-power.h" - for RK3288 type power domain. +- clocks (optional): phandles to clocks which need to be enabled while power domain + switches state. + +Example: + + power: power-controller { + compatible = "rockchip,rk3288-power-controller"; + #power-domain-cells = <1>; + #address-cells = <1>; + #size-cells = <0>; + + pd_gpu { + reg = ; + clocks = <&cru ACLK_GPU>; + }; + }; + +Node of a device using power domains must have a power-domains property, +containing a phandle to the power device node and an index specifying which +power domain to use. +The index should use macros in: + "include/dt-bindings/power/rk3288-power.h" - for rk3288 type power domain. + +Example of the node using power domain: + + node { + /* ... */ + power-domains = <&power RK3288_PD_GPU>; + /* ... */ + }; diff --git a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt index fcf11e036..d1ce21a49 100644 --- a/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt +++ b/Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt @@ -221,7 +221,6 @@ qmss: qmss@2a40000 { #size-cells = <1>; ranges; pdsp0@0x2a10000 { - firmware = "/*(DEBLOBBED)*/"; reg = <0x2a10000 0x1000>, <0x2a0f000 0x100>, <0x2a0c000 0x3c8>, diff --git a/Documentation/devicetree/bindings/sound/ak4554.c b/Documentation/devicetree/bindings/sound/ak4554.c deleted file mode 100644 index 934fa0275..000000000 --- a/Documentation/devicetree/bindings/sound/ak4554.c +++ /dev/null @@ -1,11 +0,0 @@ -AK4554 ADC/DAC - -Required properties: - - - compatible : "asahi-kasei,ak4554" - -Example: - -ak4554-adc-dac { - compatible = "asahi-kasei,ak4554"; -}; diff --git a/Documentation/devicetree/bindings/sound/ak4554.txt b/Documentation/devicetree/bindings/sound/ak4554.txt new file mode 100644 index 000000000..934fa0275 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/ak4554.txt @@ -0,0 +1,11 @@ +AK4554 ADC/DAC + +Required properties: + + - compatible : "asahi-kasei,ak4554" + +Example: + +ak4554-adc-dac { + compatible = "asahi-kasei,ak4554"; +}; diff --git a/Documentation/devicetree/bindings/sound/ak4613.txt b/Documentation/devicetree/bindings/sound/ak4613.txt new file mode 100644 index 000000000..15a919522 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/ak4613.txt @@ -0,0 +1,17 @@ +AK4613 I2C transmitter + +This device supports I2C mode only. + +Required properties: + +- compatible : "asahi-kasei,ak4613" +- reg : The chip select number on the I2C bus + +Example: + +&i2c { + ak4613: ak4613@0x10 { + compatible = "asahi-kasei,ak4613"; + reg = <0x10>; + }; +}; diff --git a/Documentation/devicetree/bindings/sound/ak4642.txt b/Documentation/devicetree/bindings/sound/ak4642.txt index 623d4e70a..340784db6 100644 --- a/Documentation/devicetree/bindings/sound/ak4642.txt +++ b/Documentation/devicetree/bindings/sound/ak4642.txt @@ -7,7 +7,14 @@ Required properties: - compatible : "asahi-kasei,ak4642" or "asahi-kasei,ak4643" or "asahi-kasei,ak4648" - reg : The chip select number on the I2C bus -Example: +Optional properties: + + - #clock-cells : common clock binding; shall be set to 0 + - clocks : common clock binding; MCKI clock + - clock-frequency : common clock binding; frequency of MCKO + - clock-output-names : common clock binding; MCKO clock name + +Example 1: &i2c { ak4648: ak4648@0x12 { @@ -15,3 +22,16 @@ Example: reg = <0x12>; }; }; + +Example 2: + +&i2c { + ak4643: codec@12 { + compatible = "asahi-kasei,ak4643"; + reg = <0x12>; + #clock-cells = <0>; + clocks = <&audio_clock>; + clock-frequency = <12288000>; + clock-output-names = "ak4643_mcko"; + }; +}; diff --git a/Documentation/devicetree/bindings/sound/atmel-classd.txt b/Documentation/devicetree/bindings/sound/atmel-classd.txt new file mode 100644 index 000000000..0018451c4 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/atmel-classd.txt @@ -0,0 +1,52 @@ +* Atmel ClassD driver under ALSA SoC architecture + +Required properties: +- compatible + Should be "atmel,sama5d2-classd". +- reg + Should contain ClassD registers location and length. +- interrupts + Should contain the IRQ line for the ClassD. +- dmas + One DMA specifiers as described in atmel-dma.txt and dma.txt files. +- dma-names + Must be "tx". +- clock-names + Tuple listing input clock names. + Required elements: "pclk", "gclk" and "aclk". +- clocks + Please refer to clock-bindings.txt. + +Optional properties: +- pinctrl-names, pinctrl-0 + Please refer to pinctrl-bindings.txt. +- atmel,model + The user-visible name of this sound complex. + The default value is "CLASSD". +- atmel,pwm-type + PWM modulation type, "single" or "diff". + The default value is "single". +- atmel,non-overlap-time + Set non-overlapping time, the unit is nanosecond(ns). + There are four values, + <5>, <10>, <15>, <20>, the default value is <10>. + Non-overlapping will be disabled if not specified. + +Example: +classd: classd@fc048000 { + compatible = "atmel,sama5d2-classd"; + reg = <0xfc048000 0x100>; + interrupts = <59 IRQ_TYPE_LEVEL_HIGH 7>; + dmas = <&dma0 + (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1) + | AT91_XDMAC_DT_PERID(47))>; + dma-names = "tx"; + clocks = <&classd_clk>, <&classd_gclk>, <&audio_pll_pmc>; + clock-names = "pclk", "gclk", "aclk"; + + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_classd_default>; + atmel,model = "classd @ SAMA5D2-Xplained"; + atmel,pwm-type = "diff"; + atmel,non-overlap-time = <10>; +}; diff --git a/Documentation/devicetree/bindings/sound/da7213.txt b/Documentation/devicetree/bindings/sound/da7213.txt new file mode 100644 index 000000000..58902802d --- /dev/null +++ b/Documentation/devicetree/bindings/sound/da7213.txt @@ -0,0 +1,41 @@ +Dialog Semiconductor DA7213 Audio Codec bindings + +====== + +Required properties: +- compatible : Should be "dlg,da7213" +- reg: Specifies the I2C slave address + +Optional properties: +- clocks : phandle and clock specifier for codec MCLK. +- clock-names : Clock name string for 'clocks' attribute, should be "mclk". + +- dlg,micbias1-lvl : Voltage (mV) for Mic Bias 1 + [<1600>, <2200>, <2500>, <3000>] +- dlg,micbias2-lvl : Voltage (mV) for Mic Bias 2 + [<1600>, <2200>, <2500>, <3000>] +- dlg,dmic-data-sel : DMIC channel select based on clock edge. + ["lrise_rfall", "lfall_rrise"] +- dlg,dmic-samplephase : When to sample audio from DMIC. + ["on_clkedge", "between_clkedge"] +- dlg,dmic-clkrate : DMIC clock frequency (Hz). + [<1500000>, <3000000>] + +====== + +Example: + + codec_i2c: da7213@1a { + compatible = "dlg,da7213"; + reg = <0x1a>; + + clocks = <&clks 201>; + clock-names = "mclk"; + + dlg,micbias1-lvl = <2500>; + dlg,micbias2-lvl = <2500>; + + dlg,dmic-data-sel = "lrise_rfall"; + dlg,dmic-samplephase = "between_clkedge"; + dlg,dmic-clkrate = <3000000>; + }; diff --git a/Documentation/devicetree/bindings/sound/da7219.txt b/Documentation/devicetree/bindings/sound/da7219.txt new file mode 100644 index 000000000..1b7030911 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/da7219.txt @@ -0,0 +1,106 @@ +Dialog Semiconductor DA7219 Audio Codec bindings + +DA7219 is an audio codec with advanced accessory detect features. + +====== + +Required properties: +- compatible : Should be "dlg,da7219" +- reg: Specifies the I2C slave address + +- interrupt-parent : Specifies the phandle of the interrupt controller to which + the IRQs from DA7219 are delivered to. +- interrupts : IRQ line info for DA7219. + (See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt for + further information relating to interrupt properties) + +- VDD-supply: VDD power supply for the device +- VDDMIC-supply: VDDMIC power supply for the device +- VDDIO-supply: VDDIO power supply for the device + (See Documentation/devicetree/bindings/regulator/regulator.txt for further + information relating to regulators) + +Optional properties: +- interrupt-names : Name associated with interrupt line. Should be "wakeup" if + interrupt is to be used to wake system, otherwise "irq" should be used. +- wakeup-source: Flag to indicate this device can wake system (suspend/resume). + +- clocks : phandle and clock specifier for codec MCLK. +- clock-names : Clock name string for 'clocks' attribute, should be "mclk". + +- dlg,ldo-lvl : Required internal LDO voltage (mV) level for digital engine + [<1050>, <1100>, <1200>, <1400>] +- dlg,micbias-lvl : Voltage (mV) for Mic Bias + [<1800>, <2000>, <2200>, <2400>, <2600>] +- dlg,mic-amp-in-sel : Mic input source type + ["diff", "se_p", "se_n"] + +====== + +Child node - 'da7219_aad': + +Optional properties: +- dlg,micbias-pulse-lvl : Mic bias higher voltage pulse level (mV). + [<2800>, <2900>] +- dlg,micbias-pulse-time : Mic bias higher voltage pulse duration (ms) +- dlg,btn-cfg : Periodic button press measurements for 4-pole jack (ms) + [<2>, <5>, <10>, <50>, <100>, <200>, <500>] +- dlg,mic-det-thr : Impedance threshold for mic detection measurement (Ohms) + [<200>, <500>, <750>, <1000>] +- dlg,jack-ins-deb : Debounce time for jack insertion (ms) + [<5>, <10>, <20>, <50>, <100>, <200>, <500>, <1000>] +- dlg,jack-det-rate: Jack type detection latency (3/4 pole) + ["32ms_64ms", "64ms_128ms", "128ms_256ms", "256ms_512ms"] +- dlg,jack-rem-deb : Debounce time for jack removal (ms) + [<1>, <5>, <10>, <20>] +- dlg,a-d-btn-thr : Impedance threshold between buttons A and D + [0x0 - 0xFF] +- dlg,d-b-btn-thr : Impedance threshold between buttons D and B + [0x0 - 0xFF] +- dlg,b-c-btn-thr : Impedance threshold between buttons B and C + [0x0 - 0xFF] +- dlg,c-mic-btn-thr : Impedance threshold between button C and Mic + [0x0 - 0xFF] +- dlg,btn-avg : Number of 8-bit readings for averaged button measurement + [<1>, <2>, <4>, <8>] +- dlg,adc-1bit-rpt : Repeat count for 1-bit button measurement + [<1>, <2>, <4>, <8>] + +====== + +Example: + + codec: da7219@1a { + compatible = "dlg,da7219"; + reg = <0x1a>; + + interrupt-parent = <&gpio6>; + interrupts = <11 IRQ_TYPE_LEVEL_HIGH>; + + VDD-supply = <®_audio>; + VDDMIC-supply = <®_audio>; + VDDIO-supply = <®_audio>; + + clocks = <&clks 201>; + clock-names = "mclk"; + + dlg,ldo-lvl = <1200>; + dlg,micbias-lvl = <2600>; + dlg,mic-amp-in-sel = "diff"; + + da7219_aad { + dlg,btn-cfg = <50>; + dlg,mic-det-thr = <500>; + dlg,jack-ins-deb = <20>; + dlg,jack-det-rate = "32ms_64ms"; + dlg,jack-rem-deb = <1>; + + dlg,a-d-btn-thr = <0xa>; + dlg,d-b-btn-thr = <0x16>; + dlg,b-c-btn-thr = <0x21>; + dlg,c-mic-btn-thr = <0x3E>; + + dlg,btn-avg = <4>; + dlg,adc-1bit-rpt = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt index a96774c19..ce55c0a6f 100644 --- a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt +++ b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt @@ -13,13 +13,15 @@ So having this generic sound card allows all Freescale SoC users to benefit from the simplification of a new card support and the capability of the wide sample rates support through ASRC. -Note: The card is initially designed for those sound cards who use I2S and - PCM DAI formats. However, it'll be also possible to support those non - I2S/PCM type sound cards, such as S/PDIF audio and HDMI audio, as long - as the driver has been properly upgraded. +Note: The card is initially designed for those sound cards who use AC'97, I2S + and PCM DAI formats. However, it'll be also possible to support those non + AC'97/I2S/PCM type sound cards, such as S/PDIF audio and HDMI audio, as + long as the driver has been properly upgraded. The compatible list for this generic sound card currently: + "fsl,imx-audio-ac97" + "fsl,imx-audio-cs42888" "fsl,imx-audio-wm8962" diff --git a/Documentation/devicetree/bindings/sound/nau8825.txt b/Documentation/devicetree/bindings/sound/nau8825.txt new file mode 100644 index 000000000..d3374231c --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nau8825.txt @@ -0,0 +1,102 @@ +Nuvoton NAU8825 audio codec + +This device supports I2C only. + +Required properties: + - compatible : Must be "nuvoton,nau8825" + + - reg : the I2C address of the device. This is either 0x1a (CSB=0) or 0x1b (CSB=1). + +Optional properties: + - nuvoton,jkdet-enable: Enable jack detection via JKDET pin. + - nuvoton,jkdet-pull-enable: Enable JKDET pin pull. If set - pin pull enabled, + otherwise pin in high impedance state. + - nuvoton,jkdet-pull-up: Pull-up JKDET pin. If set then JKDET pin is pull up, otherwise pull down. + - nuvoton,jkdet-polarity: JKDET pin polarity. 0 - active high, 1 - active low. + + - nuvoton,vref-impedance: VREF Impedance selection + 0 - Open + 1 - 25 kOhm + 2 - 125 kOhm + 3 - 2.5 kOhm + + - nuvoton,micbias-voltage: Micbias voltage level. + 0 - VDDA + 1 - VDDA + 2 - VDDA * 1.1 + 3 - VDDA * 1.2 + 4 - VDDA * 1.3 + 5 - VDDA * 1.4 + 6 - VDDA * 1.53 + 7 - VDDA * 1.53 + + - nuvoton,sar-threshold-num: Number of buttons supported + - nuvoton,sar-threshold: Impedance threshold for each button. Array that contains up to 8 buttons configuration. SAR value is calculated as + SAR = 255 * MICBIAS / SAR_VOLTAGE * R / (2000 + R) + where MICBIAS is configured by 'nuvoton,micbias-voltage', SAR_VOLTAGE is configured by 'nuvoton,sar-voltage', R - button impedance. + Refer datasheet section 10.2 for more information about threshold calculation. + + - nuvoton,sar-hysteresis: Button impedance measurement hysteresis. + + - nuvoton,sar-voltage: Reference voltage for button impedance measurement. + 0 - VDDA + 1 - VDDA + 2 - VDDA * 1.1 + 3 - VDDA * 1.2 + 4 - VDDA * 1.3 + 5 - VDDA * 1.4 + 6 - VDDA * 1.53 + 7 - VDDA * 1.53 + + - nuvoton,sar-compare-time: SAR compare time + 0 - 500 ns + 1 - 1 us + 2 - 2 us + 3 - 4 us + + - nuvoton,sar-sampling-time: SAR sampling time + 0 - 2 us + 1 - 4 us + 2 - 8 us + 3 - 16 us + + - nuvoton,short-key-debounce: Button short key press debounce time. + 0 - 30 ms + 1 - 50 ms + 2 - 100 ms + 3 - 30 ms + + - nuvoton,jack-insert-debounce: number from 0 to 7 that sets debounce time to 2^(n+2) ms + - nuvoton,jack-eject-debounce: number from 0 to 7 that sets debounce time to 2^(n+2) ms + + - clocks: list of phandle and clock specifier pairs according to common clock bindings for the + clocks described in clock-names + - clock-names: should include "mclk" for the MCLK master clock + +Example: + + headset: nau8825@1a { + compatible = "nuvoton,nau8825"; + reg = <0x1a>; + interrupt-parent = <&gpio>; + interrupts = ; + nuvoton,jkdet-enable; + nuvoton,jkdet-pull-enable; + nuvoton,jkdet-pull-up; + nuvoton,jkdet-polarity = ; + nuvoton,vref-impedance = <2>; + nuvoton,micbias-voltage = <6>; + // Setup 4 buttons impedance according to Android specification + nuvoton,sar-threshold-num = <4>; + nuvoton,sar-threshold = <0xc 0x1e 0x38 0x60>; + nuvoton,sar-hysteresis = <1>; + nuvoton,sar-voltage = <0>; + nuvoton,sar-compare-time = <0>; + nuvoton,sar-sampling-time = <0>; + nuvoton,short-key-debounce = <2>; + nuvoton,jack-insert-debounce = <7>; + nuvoton,jack-eject-debounce = <7>; + + clock-names = "mclk"; + clocks = <&tegra_car TEGRA210_CLK_CLK_OUT_2>; + }; diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt index 1173395b5..c57cbd657 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt @@ -4,10 +4,12 @@ Required properties: - compatible : "renesas,rcar_sound-", fallbacks "renesas,rcar_sound-gen1" if generation1, and "renesas,rcar_sound-gen2" if generation2 + "renesas,rcar_sound-gen3" if generation3 Examples with soctypes are: - "renesas,rcar_sound-r8a7778" (R-Car M1A) - "renesas,rcar_sound-r8a7790" (R-Car H2) - "renesas,rcar_sound-r8a7791" (R-Car M2-W) + - "renesas,rcar_sound-r8a7795" (R-Car H3) - reg : Should contain the register physical address. required register is SRU/ADG/SSI if generation1 @@ -30,6 +32,11 @@ Required properties: - rcar_sound,dai : DAI contents. The number of DAI subnode should be same as HW. see below for detail. +- #sound-dai-cells : it must be 0 if your system is using single DAI + it must be 1 if your system is using multi DAI +- #clock-cells : it must be 0 if your system has audio_clkout + it must be 1 if your system has audio_clkout0/1/2/3 +- clock-frequency : for all audio_clkout0/1/2/3 SSI subnode properties: - interrupts : Should contain SSI interrupt for PIO transfer diff --git a/Documentation/devicetree/bindings/sound/rockchip-i2s.txt b/Documentation/devicetree/bindings/sound/rockchip-i2s.txt index 9b82c20b3..2267d249c 100644 --- a/Documentation/devicetree/bindings/sound/rockchip-i2s.txt +++ b/Documentation/devicetree/bindings/sound/rockchip-i2s.txt @@ -12,8 +12,6 @@ Required properties: - reg: physical base address of the controller and length of memory mapped region. - interrupts: should contain the I2S interrupt. -- #address-cells: should be 1. -- #size-cells: should be 0. - dmas: DMA specifiers for tx and rx dma. See the DMA client binding, Documentation/devicetree/bindings/dma/dma.txt - dma-names: should include "tx" and "rx". @@ -21,6 +19,7 @@ Required properties: - clock-names: should contain followings: - "i2s_hclk": clock for I2S BUS - "i2s_clk" : clock for I2S controller +- rockchip,capture-channels: max capture channels, if not set, 2 channels default. Example for rk3288 I2S controller: @@ -28,10 +27,9 @@ i2s@ff890000 { compatible = "rockchip,rk3288-i2s", "rockchip,rk3066-i2s"; reg = <0xff890000 0x10000>; interrupts = ; - #address-cells = <1>; - #size-cells = <0>; dmas = <&pdma1 0>, <&pdma1 1>; dma-names = "tx", "rx"; clock-names = "i2s_hclk", "i2s_clk"; clocks = <&cru HCLK_I2S0>, <&cru SCLK_I2S0>; + rockchip,capture-channels = <2>; }; diff --git a/Documentation/devicetree/bindings/sound/rockchip-spdif.txt b/Documentation/devicetree/bindings/sound/rockchip-spdif.txt new file mode 100644 index 000000000..e64dbdea7 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/rockchip-spdif.txt @@ -0,0 +1,40 @@ +* Rockchip SPDIF transceiver + +The S/PDIF audio block is a stereo transceiver that allows the +processor to receive and transmit digital audio via an coaxial cable or +a fibre cable. + +Required properties: + +- compatible: should be one of the following: + - "rockchip,rk3288-spdif", "rockchip,rk3188-spdif" or + "rockchip,rk3066-spdif" +- reg: physical base address of the controller and length of memory mapped + region. +- interrupts: should contain the SPDIF interrupt. +- dmas: DMA specifiers for tx dma. See the DMA client binding, + Documentation/devicetree/bindings/dma/dma.txt +- dma-names: should be "tx" +- clocks: a list of phandle + clock-specifier pairs, one for each entry + in clock-names. +- clock-names: should contain following: + - "hclk": clock for SPDIF controller + - "mclk" : clock for SPDIF bus + +Required properties on RK3288: + - rockchip,grf: the phandle of the syscon node for the general register + file (GRF) + +Example for the rk3188 SPDIF controller: + +spdif: spdif@0x1011e000 { + compatible = "rockchip,rk3188-spdif", "rockchip,rk3066-spdif"; + reg = <0x1011e000 0x2000>; + interrupts = ; + dmas = <&dmac1_s 8>; + dma-names = "tx"; + clock-names = "hclk", "mclk"; + clocks = <&cru HCLK_SPDIF>, <&cru SCLK_SPDIF>; + status = "disabled"; + #sound-dai-cells = <0>; +}; diff --git a/Documentation/devicetree/bindings/sound/rt5640.txt b/Documentation/devicetree/bindings/sound/rt5640.txt index bac4d9ac1..9e62f6eb3 100644 --- a/Documentation/devicetree/bindings/sound/rt5640.txt +++ b/Documentation/devicetree/bindings/sound/rt5640.txt @@ -14,7 +14,8 @@ Optional properties: - realtek,in1-differential - realtek,in2-differential - Boolean. Indicate MIC1/2 input are differential, rather than single-ended. +- realtek,in3-differential + Boolean. Indicate MIC1/2/3 input are differential, rather than single-ended. - realtek,ldo1-en-gpios : The GPIO that controls the CODEC's LDO1_EN pin. @@ -24,9 +25,11 @@ Pins on the device (for linking into audio routes) for RT5639/RT5640: * DMIC2 * MICBIAS1 * IN1P - * IN1R + * IN1N * IN2P - * IN2R + * IN2N + * IN3P + * IN3N * HPOL * HPOR * LOUTL diff --git a/Documentation/devicetree/bindings/sound/sun4i-codec.txt b/Documentation/devicetree/bindings/sound/sun4i-codec.txt new file mode 100644 index 000000000..c92966bd5 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/sun4i-codec.txt @@ -0,0 +1,27 @@ +* Allwinner A10 Codec + +Required properties: +- compatible: must be either "allwinner,sun4i-a10-codec" or + "allwinner,sun7i-a20-codec" +- reg: must contain the registers location and length +- interrupts: must contain the codec interrupt +- dmas: DMA channels for tx and rx dma. See the DMA client binding, + Documentation/devicetree/bindings/dma/dma.txt +- dma-names: should include "tx" and "rx". +- clocks: a list of phandle + clock-specifer pairs, one for each entry + in clock-names. +- clock-names: should contain followings: + - "apb": the parent APB clock for this controller + - "codec": the parent module clock + +Example: +codec: codec@01c22c00 { + #sound-dai-cells = <0>; + compatible = "allwinner,sun7i-a20-codec"; + reg = <0x01c22c00 0x40>; + interrupts = <0 30 4>; + clocks = <&apb0_gates 0>, <&codec_clk>; + clock-names = "apb", "codec"; + dmas = <&dma 0 19>, <&dma 0 19>; + dma-names = "rx", "tx"; +}; diff --git a/Documentation/devicetree/bindings/sound/tdm-slot.txt b/Documentation/devicetree/bindings/sound/tdm-slot.txt index 6a2c84247..34cf70e2c 100644 --- a/Documentation/devicetree/bindings/sound/tdm-slot.txt +++ b/Documentation/devicetree/bindings/sound/tdm-slot.txt @@ -4,11 +4,15 @@ This specifies audio DAI's TDM slot. TDM slot properties: dai-tdm-slot-num : Number of slots in use. -dai-tdm-slot-width : Width in bits for each slot. +dai-tdm-slot-width : Width in bits for each slot. +dai-tdm-slot-tx-mask : Transmit direction slot mask, optional +dai-tdm-slot-rx-mask : Receive direction slot mask, optional For instance: dai-tdm-slot-num = <2>; dai-tdm-slot-width = <8>; + dai-tdm-slot-tx-mask = <0 1>; + dai-tdm-slot-rx-mask = <1 0>; And for each spcified driver, there could be one .of_xlate_tdm_slot_mask() to specify a explicit mapping of the channels and the slots. If it's absent @@ -18,3 +22,8 @@ tx and rx masks. For snd_soc_of_xlate_tdm_slot_mask(), the tx and rx masks will use a 1 bit for an active slot as default, and the default active bits are at the LSB of the masks. + +The explicit masks are given as array of integers, where the first +number presents bit-0 (LSB), second presents bit-1, etc. Any non zero +number is considered 1 and 0 is 0. snd_soc_of_xlate_tdm_slot_mask() +does not do anything, if either mask is set non zero value. diff --git a/Documentation/devicetree/bindings/spi/brcm,bcm2835-aux-spi.txt b/Documentation/devicetree/bindings/spi/brcm,bcm2835-aux-spi.txt new file mode 100644 index 000000000..9887b0724 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/brcm,bcm2835-aux-spi.txt @@ -0,0 +1,38 @@ +Broadcom BCM2835 auxiliar SPI1/2 controller + +The BCM2835 contains two forms of SPI master controller, one known simply as +SPI0, and the other known as the "Universal SPI Master"; part of the +auxiliary block. This binding applies to the SPI1/2 controller. + +Required properties: +- compatible: Should be "brcm,bcm2835-aux-spi". +- reg: Should contain register location and length for the spi block +- interrupts: Should contain shared interrupt of the aux block +- clocks: The clock feeding the SPI controller - needs to + point to the auxiliar clock driver of the bcm2835, + as this clock will enable the output gate for the specific + clock. +- cs-gpios: the cs-gpios (native cs is NOT supported) + see also spi-bus.txt + +Example: + +spi1@7e215080 { + compatible = "brcm,bcm2835-aux-spi"; + reg = <0x7e215080 0x40>; + interrupts = <1 29>; + clocks = <&aux_clocks BCM2835_AUX_CLOCK_SPI1>; + #address-cells = <1>; + #size-cells = <0>; + cs-gpios = <&gpio 18>, <&gpio 17>, <&gpio 16>; +}; + +spi2@7e2150c0 { + compatible = "brcm,bcm2835-aux-spi"; + reg = <0x7e2150c0 0x40>; + interrupts = <1 29>; + clocks = <&aux_clocks BCM2835_AUX_CLOCK_SPI2>; + #address-cells = <1>; + #size-cells = <0>; + cs-gpios = <&gpio 43>, <&gpio 44>, <&gpio 45>; +}; diff --git a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt index 6160ffbcb..ce363c923 100644 --- a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt +++ b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt @@ -29,8 +29,11 @@ Required properties: muxes clock, and "spi-clk" for the clock gate. Optional properties: +-cs-gpios: see spi-bus.txt, only required for MT8173. + - mediatek,pad-select: specify which pins group(ck/mi/mo/cs) spi - controller used, this value should be 0~3, only required for MT8173. + controller used. This is a array, the element value should be 0~3, + only required for MT8173. 0: specify GPIO69,70,71,72 for spi pins. 1: specify GPIO102,103,104,105 for spi pins. 2: specify GPIO128,129,130,131 for spi pins. @@ -49,7 +52,7 @@ spi: spi@1100a000 { <&topckgen CLK_TOP_SPI_SEL>, <&pericfg CLK_PERI_SPI0>; clock-names = "parent-clk", "sel-clk", "spi-clk"; - - mediatek,pad-select = <0>; + cs-gpios = <&pio 105 GPIO_ACTIVE_LOW>, <&pio 72 GPIO_ACTIVE_LOW>; + mediatek,pad-select = <1>, <0>; status = "disabled"; }; diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt index ef802de49..0dfa60d88 100644 --- a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt @@ -1,7 +1,9 @@ * Temperature Sensor ADC (TSADC) on rockchip SoCs Required properties: -- compatible : "rockchip,rk3288-tsadc" +- compatible : should be "rockchip,-tsadc" + "rockchip,rk3288-tsadc": found on RK3288 SoCs + "rockchip,rk3368-tsadc": found on RK3368 SoCs - reg : physical base address of the controller and length of memory mapped region. - interrupts : The interrupt number to the cpu. The interrupt specifier format @@ -12,6 +14,11 @@ Required properties: - resets : Must contain an entry for each entry in reset-names. See ../reset/reset.txt for details. - reset-names : Must include the name "tsadc-apb". +- pinctrl-names : The pin control state names; +- pinctrl-0 : The "init" pinctrl state, it will be set before device probe. +- pinctrl-1 : The "default" pinctrl state, it will be set after reset the + TSADC controller. +- pinctrl-2 : The "sleep" pinctrl state, it will be in for suspend. - #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description. - rockchip,hw-tshut-temp : The hardware-controlled shutdown temperature value. - rockchip,hw-tshut-mode : The hardware-controlled shutdown mode 0:CRU 1:GPIO. @@ -27,8 +34,10 @@ tsadc: tsadc@ff280000 { clock-names = "tsadc", "apb_pclk"; resets = <&cru SRST_TSADC>; reset-names = "tsadc-apb"; - pinctrl-names = "default"; - pinctrl-0 = <&otp_out>; + pinctrl-names = "init", "default", "sleep"; + pinctrl-0 = <&otp_gpio>; + pinctrl-1 = <&otp_out>; + pinctrl-2 = <&otp_gpio>; #thermal-sensor-cells = <1>; rockchip,hw-tshut-temp = <95000>; rockchip,hw-tshut-mode = <0>; diff --git a/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt b/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt index 0c9222d27..6299dd8de 100644 --- a/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt +++ b/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt @@ -10,6 +10,8 @@ to the silicon temperature. Required properties: - compatible : Should be: + - "ti,omap34xx-bandgap" : for OMAP34xx bandgap + - "ti,omap36xx-bandgap" : for OMAP36xx bandgap - "ti,omap4430-bandgap" : for OMAP4430 bandgap - "ti,omap4460-bandgap" : for OMAP4460 bandgap - "ti,omap4470-bandgap" : for OMAP4470 bandgap @@ -25,6 +27,18 @@ to each bandgap version, because the mapping may change from soc to soc, apart of depending on available features. Example: +OMAP34xx: +bandgap { + reg = <0x48002524 0x4>; + compatible = "ti,omap34xx-bandgap"; +}; + +OMAP36xx: +bandgap { + reg = <0x48002524 0x4>; + compatible = "ti,omap36xx-bandgap"; +}; + OMAP4430: bandgap { reg = <0x4a002260 0x4 0x4a00232C 0x4>; diff --git a/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt b/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt index 53a3029b7..64083bc56 100644 --- a/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt +++ b/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt @@ -3,10 +3,12 @@ Mediatek MT6577, MT6572 and MT6589 Timers Required properties: - compatible should contain: - * "mediatek,mt6589-timer" for MT6589 compatible timers * "mediatek,mt6580-timer" for MT6580 compatible timers - * "mediatek,mt6577-timer" for all compatible timers (MT6589, MT6580, - MT6577) + * "mediatek,mt6589-timer" for MT6589 compatible timers + * "mediatek,mt8127-timer" for MT8127 compatible timers + * "mediatek,mt8135-timer" for MT8135 compatible timers + * "mediatek,mt8173-timer" for MT8173 compatible timers + * "mediatek,mt6577-timer" for MT6577 and all above compatible timers - reg: Should contain location and length for timers register. - clocks: Clocks driving the timer hardware. This list should include two clocks. The order is system clock and as second clock the RTC clock. diff --git a/Documentation/devicetree/bindings/ufs/ufs-qcom.txt b/Documentation/devicetree/bindings/ufs/ufs-qcom.txt new file mode 100644 index 000000000..070baf4d7 --- /dev/null +++ b/Documentation/devicetree/bindings/ufs/ufs-qcom.txt @@ -0,0 +1,58 @@ +* Qualcomm Technologies Inc Universal Flash Storage (UFS) PHY + +UFSPHY nodes are defined to describe on-chip UFS PHY hardware macro. +Each UFS PHY node should have its own node. + +To bind UFS PHY with UFS host controller, the controller node should +contain a phandle reference to UFS PHY node. + +Required properties: +- compatible : compatible list, contains "qcom,ufs-phy-qmp-20nm" + or "qcom,ufs-phy-qmp-14nm" according to the relevant phy in use. +- reg : should contain PHY register address space (mandatory), +- reg-names : indicates various resources passed to driver (via reg proptery) by name. + Required "reg-names" is "phy_mem". +- #phy-cells : This property shall be set to 0 +- vdda-phy-supply : phandle to main PHY supply for analog domain +- vdda-pll-supply : phandle to PHY PLL and Power-Gen block power supply +- clocks : List of phandle and clock specifier pairs +- clock-names : List of clock input name strings sorted in the same + order as the clocks property. "ref_clk_src", "ref_clk", + "tx_iface_clk" & "rx_iface_clk" are mandatory but + "ref_clk_parent" is optional + +Optional properties: +- vdda-phy-max-microamp : specifies max. load that can be drawn from phy supply +- vdda-pll-max-microamp : specifies max. load that can be drawn from pll supply +- vddp-ref-clk-supply : phandle to UFS device ref_clk pad power supply +- vddp-ref-clk-max-microamp : specifies max. load that can be drawn from this supply +- vddp-ref-clk-always-on : specifies if this supply needs to be kept always on + +Example: + + ufsphy1: ufsphy@0xfc597000 { + compatible = "qcom,ufs-phy-qmp-20nm"; + reg = <0xfc597000 0x800>; + reg-names = "phy_mem"; + #phy-cells = <0>; + vdda-phy-supply = <&pma8084_l4>; + vdda-pll-supply = <&pma8084_l12>; + vdda-phy-max-microamp = <50000>; + vdda-pll-max-microamp = <1000>; + clock-names = "ref_clk_src", + "ref_clk_parent", + "ref_clk", + "tx_iface_clk", + "rx_iface_clk"; + clocks = <&clock_rpm clk_ln_bb_clk>, + <&clock_gcc clk_pcie_1_phy_ldo >, + <&clock_gcc clk_ufs_phy_ldo>, + <&clock_gcc clk_gcc_ufs_tx_cfg_clk>, + <&clock_gcc clk_gcc_ufs_rx_cfg_clk>; + }; + + ufshc@0xfc598000 { + ... + phys = <&ufsphy1>; + phy-names = "ufsphy"; + }; diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt index 53579197e..03c0e989e 100644 --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt +++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt @@ -4,11 +4,18 @@ UFSHC nodes are defined to describe on-chip UFS host controllers. Each UFS controller instance should have its own node. Required properties: -- compatible : compatible list, contains "jedec,ufs-1.1" +- compatible : must contain "jedec,ufs-1.1", may also list one or more + of the following: + "qcom,msm8994-ufshc" + "qcom,msm8996-ufshc" + "qcom,ufshc" - interrupts : - reg : Optional properties: +- phys : phandle to UFS PHY node +- phy-names : the string "ufsphy" when is found in a node, along + with "phys" attribute, provides phandle to UFS PHY node - vdd-hba-supply : phandle to UFS host controller supply regulator node - vcc-supply : phandle to VCC supply regulator node - vccq-supply : phandle to VCCQ supply regulator node @@ -54,4 +61,6 @@ Example: clocks = <&core 0>, <&ref 0>, <&iface 0>; clock-names = "core_clk", "ref_clk", "iface_clk"; freq-table-hz = <100000000 200000000>, <0 0>, <0 0>; + phys = <&ufsphy1>; + phy-names = "ufsphy"; }; diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt index a057b75ba..781296bfb 100644 --- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt @@ -27,10 +27,6 @@ Optional properties: - vbus-supply: reference to the VBUS regulator - maximum-speed: limit the maximum connection speed to "full-speed". - tpl-support: TPL (Targeted Peripheral List) feature for targeted hosts -- fsl,usbmisc: (FSL only) phandler of non-core register device, with one - argument that indicate usb controller index -- disable-over-current: (FSL only) disable over current detect -- external-vbus-divider: (FSL only) enables off-chip resistor divider for Vbus - itc-setting: interrupt threshold control register control, the setting should be aligned with ITC bits at register USBCMD. - ahb-burst-config: it is vendor dependent, the required value should be @@ -41,11 +37,28 @@ Optional properties: - tx-burst-size-dword: it is vendor dependent, the tx burst size in dword (4 bytes), This register represents the maximum length of a the burst in 32-bit words while moving data from system memory to the USB - bus, changing this value takes effect only the SBUSCFG.AHBBRST is 0. + bus, the value of this property will only take effect if property + "ahb-burst-config" is set to 0, if this property is missing the reset + default of the hardware implementation will be used. - rx-burst-size-dword: it is vendor dependent, the rx burst size in dword (4 bytes), This register represents the maximum length of a the burst in 32-bit words while moving data from the USB bus to system memory, - changing this value takes effect only the SBUSCFG.AHBBRST is 0. + the value of this property will only take effect if property + "ahb-burst-config" is set to 0, if this property is missing the reset + default of the hardware implementation will be used. +- extcon: phandles to external connector devices. First phandle should point to + external connector, which provide "USB" cable events, the second should point + to external connector device, which provide "USB-HOST" cable events. If one + of the external connector devices is not required, empty <0> phandle should + be specified. +- phy-clkgate-delay-us: the delay time (us) between putting the PHY into + low power mode and gating the PHY clock. + +i.mx specific properties +- fsl,usbmisc: phandler of non-core register device, with one + argument that indicate usb controller index +- disable-over-current: disable over current detect +- external-vbus-divider: enables off-chip resistor divider for Vbus Example: @@ -62,4 +75,6 @@ Example: ahb-burst-config = <0x0>; tx-burst-size-dword = <0x10>; /* 64 bytes */ rx-burst-size-dword = <0x10>; + extcon = <0>, <&usb_id>; + phy-clkgate-delay-us = <400>; }; diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt index e12f34488..fb2ad0ace 100644 --- a/Documentation/devicetree/bindings/usb/dwc3.txt +++ b/Documentation/devicetree/bindings/usb/dwc3.txt @@ -1,6 +1,7 @@ synopsys DWC3 CORE -DWC3- USB3 CONTROLLER +DWC3- USB3 CONTROLLER. Complies to the generic USB binding properties + as described in 'usb/generic.txt' Required properties: - compatible: must be "snps,dwc3" @@ -42,6 +43,9 @@ Optional properties: - snps,hird-threshold: HIRD threshold - snps,hsphy_interface: High-Speed PHY interface selection between "utmi" for UTMI+ and "ulpi" for ULPI when the DWC_USB3_HSPHY_INTERFACE has value 3. + - snps,quirk-frame-length-adjustment: Value for GFLADJ_30MHZ field of GFLADJ + register for post-silicon frame length adjustment when the + fladj_30mhz_sdbnd signal is invalid or incorrect. This is usually a subnode to DWC3 glue to which it is connected. diff --git a/Documentation/devicetree/bindings/usb/keystone-phy.txt b/Documentation/devicetree/bindings/usb/keystone-phy.txt deleted file mode 100644 index f37b3a863..000000000 --- a/Documentation/devicetree/bindings/usb/keystone-phy.txt +++ /dev/null @@ -1,20 +0,0 @@ -TI Keystone USB PHY - -Required properties: - - compatible: should be "ti,keystone-usbphy". - - #address-cells, #size-cells : should be '1' if the device has sub-nodes - with 'reg' property. - - reg : Address and length of the usb phy control register set. - -The main purpose of this PHY driver is to enable the USB PHY reference clock -gate on the Keystone SOC for both the USB2 and USB3 PHY. Otherwise it is just -an NOP PHY driver. Hence this node is referenced as both the usb2 and usb3 -phy node in the USB Glue layer driver node. - -usb_phy: usb_phy@2620738 { - compatible = "ti,keystone-usbphy"; - #address-cells = <1>; - #size-cells = <1>; - reg = <0x2620738 32>; - status = "disabled"; -}; diff --git a/Documentation/devicetree/bindings/usb/mxs-phy.txt b/Documentation/devicetree/bindings/usb/mxs-phy.txt deleted file mode 100644 index 379b84a56..000000000 --- a/Documentation/devicetree/bindings/usb/mxs-phy.txt +++ /dev/null @@ -1,21 +0,0 @@ -* Freescale MXS USB Phy Device - -Required properties: -- compatible: should contain: - * "fsl,imx23-usbphy" for imx23 and imx28 - * "fsl,imx6q-usbphy" for imx6dq and imx6dl - * "fsl,imx6sl-usbphy" for imx6sl - * "fsl,vf610-usbphy" for Vybrid vf610 - * "fsl,imx6sx-usbphy" for imx6sx - "fsl,imx23-usbphy" is still a fallback for other strings -- reg: Should contain registers location and length -- interrupts: Should contain phy interrupt -- fsl,anatop: phandle for anatop register, it is only for imx6 SoC series - -Example: -usbphy1: usbphy@020c9000 { - compatible = "fsl,imx6q-usbphy", "fsl,imx23-usbphy"; - reg = <0x020c9000 0x1000>; - interrupts = <0 44 0x04>; - fsl,anatop = <&anatop>; -}; diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt deleted file mode 100644 index a9aa79fb9..000000000 --- a/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt +++ /dev/null @@ -1,72 +0,0 @@ -Tegra SOC USB PHY - -The device node for Tegra SOC USB PHY: - -Required properties : - - compatible : For Tegra20, must contain "nvidia,tegra20-usb-phy". - For Tegra30, must contain "nvidia,tegra30-usb-phy". Otherwise, must contain - "nvidia,-usb-phy" plus at least one of the above, where is - tegra114, tegra124, tegra132, or tegra210. - - reg : Defines the following set of registers, in the order listed: - - The PHY's own register set. - Always present. - - The register set of the PHY containing the UTMI pad control registers. - Present if-and-only-if phy_type == utmi. - - phy_type : Should be one of "utmi", "ulpi" or "hsic". - - clocks : Defines the clocks listed in the clock-names property. - - clock-names : The following clock names must be present: - - reg: The clock needed to access the PHY's own registers. This is the - associated EHCI controller's clock. Always present. - - pll_u: PLL_U. Always present. - - timer: The timeout clock (clk_m). Present if phy_type == utmi. - - utmi-pads: The clock needed to access the UTMI pad control registers. - Present if phy_type == utmi. - - ulpi-link: The clock Tegra provides to the ULPI PHY (cdev2). - Present if phy_type == ulpi, and ULPI link mode is in use. - - resets : Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. - - reset-names : Must include the following entries: - - usb: The PHY's own reset signal. - - utmi-pads: The reset of the PHY containing the chip-wide UTMI pad control - registers. Required even if phy_type == ulpi. - -Required properties for phy_type == ulpi: - - nvidia,phy-reset-gpio : The GPIO used to reset the PHY. - -Required PHY timing params for utmi phy, for all chips: - - nvidia,hssync-start-delay : Number of 480 Mhz clock cycles to wait before - start of sync launches RxActive - - nvidia,elastic-limit : Variable FIFO Depth of elastic input store - - nvidia,idle-wait-delay : Number of 480 Mhz clock cycles of idle to wait - before declare IDLE. - - nvidia,term-range-adj : Range adjusment on terminations - - Either one of the following for HS driver output control: - - nvidia,xcvr-setup : integer, uses the provided value. - - nvidia,xcvr-setup-use-fuses : boolean, indicates that the value is read - from the on-chip fuses - If both are provided, nvidia,xcvr-setup-use-fuses takes precedence. - - nvidia,xcvr-lsfslew : LS falling slew rate control. - - nvidia,xcvr-lsrslew : LS rising slew rate control. - -Required PHY timing params for utmi phy, only on Tegra30 and above: - - nvidia,xcvr-hsslew : HS slew rate control. - - nvidia,hssquelch-level : HS squelch detector level. - - nvidia,hsdiscon-level : HS disconnect detector level. - -Optional properties: - - nvidia,has-legacy-mode : boolean indicates whether this controller can - operate in legacy mode (as APX 2500 / 2600). In legacy mode some - registers are accessed through the APB_MISC base address instead of - the USB controller. - - nvidia,is-wired : boolean. Indicates whether we can do certain kind of power - optimizations for the devices that are always connected. e.g. modem. - - dr_mode : dual role mode. Indicates the working mode for the PHY. Can be - "host", "peripheral", or "otg". Defaults to "host" if not defined. - host means this is a host controller - peripheral means it is device controller - otg means it can operate as either ("on the go") - - nvidia,has-utmi-pad-registers : boolean indicates whether this controller - contains the UTMI pad control registers common to all USB controllers. - -VBUS control (required for dr_mode == otg, optional for dr_mode == host): - - vbus-supply: regulator for VBUS diff --git a/Documentation/devicetree/bindings/usb/qcom,usb-8x16-phy.txt b/Documentation/devicetree/bindings/usb/qcom,usb-8x16-phy.txt deleted file mode 100644 index 2cb2168ce..000000000 --- a/Documentation/devicetree/bindings/usb/qcom,usb-8x16-phy.txt +++ /dev/null @@ -1,76 +0,0 @@ -Qualcomm's APQ8016/MSM8916 USB transceiver controller - -- compatible: - Usage: required - Value type: - Definition: Should contain "qcom,usb-8x16-phy". - -- reg: - Usage: required - Value type: - Definition: USB PHY base address and length of the register map - -- clocks: - Usage: required - Value type: - Definition: See clock-bindings.txt section "consumers". List of - two clock specifiers for interface and core controller - clocks. - -- clock-names: - Usage: required - Value type: - Definition: Must contain "iface" and "core" strings. - -- vddcx-supply: - Usage: required - Value type: - Definition: phandle to the regulator VDCCX supply node. - -- v1p8-supply: - Usage: required - Value type: - Definition: phandle to the regulator 1.8V supply node. - -- v3p3-supply: - Usage: required - Value type: - Definition: phandle to the regulator 3.3V supply node. - -- resets: - Usage: required - Value type: - Definition: See reset.txt section "consumers". PHY reset specifier. - -- reset-names: - Usage: required - Value type: - Definition: Must contain "phy" string. - -- switch-gpio: - Usage: optional - Value type: - Definition: Some boards are using Dual SPDT USB Switch, witch is - controlled by GPIO to de/multiplex D+/D- USB lines - between connectors. - -Example: - usb_phy: phy@78d9000 { - compatible = "qcom,usb-8x16-phy"; - reg = <0x78d9000 0x400>; - - vddcx-supply = <&pm8916_s1_corner>; - v1p8-supply = <&pm8916_l7>; - v3p3-supply = <&pm8916_l13>; - - clocks = <&gcc GCC_USB_HS_AHB_CLK>, - <&gcc GCC_USB_HS_SYSTEM_CLK>; - clock-names = "iface", "core"; - - resets = <&gcc GCC_USB2A_PHY_BCR>; - reset-names = "phy"; - - // D+/D- lines: 1 - Routed to HUB, 0 - Device connector - switch-gpio = <&pm8916_gpios 4 GPIO_ACTIVE_HIGH>; - }; - diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt deleted file mode 100644 index 33fd3543f..000000000 --- a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt +++ /dev/null @@ -1,117 +0,0 @@ -SAMSUNG USB-PHY controllers - -** Samsung's usb 2.0 phy transceiver - -The Samsung's usb 2.0 phy transceiver is used for controlling -usb 2.0 phy for s3c-hsotg as well as ehci-s5p and ohci-exynos -usb controllers across Samsung SOCs. -TODO: Adding the PHY binding with controller(s) according to the under -development generic PHY driver. - -Required properties: - -Exynos4210: -- compatible : should be "samsung,exynos4210-usb2phy" -- reg : base physical address of the phy registers and length of memory mapped - region. -- clocks: Clock IDs array as required by the controller. -- clock-names: names of clock correseponding IDs clock property as requested - by the controller driver. - -Exynos5250: -- compatible : should be "samsung,exynos5250-usb2phy" -- reg : base physical address of the phy registers and length of memory mapped - region. - -Optional properties: -- #address-cells: should be '1' when usbphy node has a child node with 'reg' - property. -- #size-cells: should be '1' when usbphy node has a child node with 'reg' - property. -- ranges: allows valid translation between child's address space and parent's - address space. - -- The child node 'usbphy-sys' to the node 'usbphy' is for the system controller - interface for usb-phy. It should provide the following information required by - usb-phy controller to control phy. - - reg : base physical address of PHY_CONTROL registers. - The size of this register is the total sum of size of all PHY_CONTROL - registers that the SoC has. For example, the size will be - '0x4' in case we have only one PHY_CONTROL register (e.g. - OTHERS register in S3C64XX or USB_PHY_CONTROL register in S5PV210) - and, '0x8' in case we have two PHY_CONTROL registers (e.g. - USBDEVICE_PHY_CONTROL and USBHOST_PHY_CONTROL registers in exynos4x). - and so on. - -Example: - - Exynos4210 - - usbphy@125B0000 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "samsung,exynos4210-usb2phy"; - reg = <0x125B0000 0x100>; - ranges; - - clocks = <&clock 2>, <&clock 305>; - clock-names = "xusbxti", "otg"; - - usbphy-sys { - /* USB device and host PHY_CONTROL registers */ - reg = <0x10020704 0x8>; - }; - }; - - -** Samsung's usb 3.0 phy transceiver - -Starting exynso5250, Samsung's SoC have usb 3.0 phy transceiver -which is used for controlling usb 3.0 phy for dwc3-exynos usb 3.0 -controllers across Samsung SOCs. - -Required properties: - -Exynos5250: -- compatible : should be "samsung,exynos5250-usb3phy" -- reg : base physical address of the phy registers and length of memory mapped - region. -- clocks: Clock IDs array as required by the controller. -- clock-names: names of clocks correseponding to IDs in the clock property - as requested by the controller driver. - -Optional properties: -- #address-cells: should be '1' when usbphy node has a child node with 'reg' - property. -- #size-cells: should be '1' when usbphy node has a child node with 'reg' - property. -- ranges: allows valid translation between child's address space and parent's - address space. - -- The child node 'usbphy-sys' to the node 'usbphy' is for the system controller - interface for usb-phy. It should provide the following information required by - usb-phy controller to control phy. - - reg : base physical address of PHY_CONTROL registers. - The size of this register is the total sum of size of all PHY_CONTROL - registers that the SoC has. For example, the size will be - '0x4' in case we have only one PHY_CONTROL register (e.g. - OTHERS register in S3C64XX or USB_PHY_CONTROL register in S5PV210) - and, '0x8' in case we have two PHY_CONTROL registers (e.g. - USBDEVICE_PHY_CONTROL and USBHOST_PHY_CONTROL registers in exynos4x). - and so on. - -Example: - usbphy@12100000 { - compatible = "samsung,exynos5250-usb3phy"; - reg = <0x12100000 0x100>; - #address-cells = <1>; - #size-cells = <1>; - ranges; - - clocks = <&clock 1>, <&clock 286>; - clock-names = "ext_xtal", "usbdrd30"; - - usbphy-sys { - /* USB device and host PHY_CONTROL registers */ - reg = <0x10040704 0x8>; - }; - }; diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 82d2ac97a..55df1d444 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -34,6 +34,7 @@ avago Avago Technologies avic Shanghai AVIC Optoelectronics Co., Ltd. axis Axis Communications AB bosch Bosch Sensortec GmbH +boundary Boundary Devices Inc. brcm Broadcom Corporation buffalo Buffalo, Inc. calxeda Calxeda @@ -51,6 +52,7 @@ cirrus Cirrus Logic, Inc. cloudengines Cloud Engines, Inc. cnm Chips&Media, Inc. cnxt Conexant Systems, Inc. +compulab CompuLab Ltd. cortina Cortina Systems, Inc. cosmic Cosmic Circuits crystalfontz Crystalfontz America, Inc. @@ -82,6 +84,7 @@ everspin Everspin Technologies, Inc. excito Excito fcs Fairchild Semiconductor firefly Firefly +focaltech FocalTech Systems Co.,Ltd fsl Freescale Semiconductor GEFanuc GE Fanuc Intelligent Platforms Embedded Systems, Inc. gef GE Fanuc Intelligent Platforms Embedded Systems, Inc. @@ -101,6 +104,7 @@ himax Himax Technologies, Inc. hisilicon Hisilicon Limited. hit Hitachi Ltd. hitex Hitex Development Tools +holt Holt Integrated Circuits, Inc. honeywell Honeywell hp Hewlett Packard i2se I2SE GmbH @@ -168,7 +172,9 @@ pericom Pericom Technology Inc. phytec PHYTEC Messtechnik GmbH picochip Picochip Ltd plathome Plat'Home Co., Ltd. +plda PLDA pixcir PIXCIR MICROELECTRONICS Co., Ltd +pulsedlight PulsedLight, Inc powervr PowerVR (deprecated, use img) qca Qualcomm Atheros, Inc. qcom Qualcomm Technologies, Inc @@ -191,7 +197,9 @@ sbs Smart Battery System schindler Schindler seagate Seagate Technology PLC semtech Semtech Corporation +sgx SGX Sensortech sharp Sharp Corporation +sigma Sigma Designs, Inc. sil Silicon Image silabs Silicon Laboratories siliconmitus Silicon Mitus, Inc. @@ -222,7 +230,9 @@ toradex Toradex AG toshiba Toshiba Corporation toumaz Toumaz tplink TP-LINK Technologies Co., Ltd. +tronfy Tronfy truly Truly Semiconductors Limited +upisemi uPI Semiconductor Corp. usi Universal Scientific Industrial Co., Ltd. v3 V3 Semiconductor variscite Variscite Ltd. diff --git a/Documentation/devicetree/bindings/video/adi,adv7123.txt b/Documentation/devicetree/bindings/video/adi,adv7123.txt deleted file mode 100644 index a6b2b2b8f..000000000 --- a/Documentation/devicetree/bindings/video/adi,adv7123.txt +++ /dev/null @@ -1,50 +0,0 @@ -Analog Device ADV7123 Video DAC -------------------------------- - -The ADV7123 is a digital-to-analog converter that outputs VGA signals from a -parallel video input. - -Required properties: - -- compatible: Should be "adi,adv7123" - -Optional properties: - -- psave-gpios: Power save control GPIO - -Required nodes: - -The ADV7123 has two video ports. Their connections are modeled using the OF -graph bindings specified in Documentation/devicetree/bindings/graph.txt. - -- Video port 0 for DPI input -- Video port 1 for VGA output - - -Example -------- - - adv7123: encoder@0 { - compatible = "adi,adv7123"; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - - adv7123_in: endpoint@0 { - remote-endpoint = <&dpi_out>; - }; - }; - - port@1 { - reg = <1>; - - adv7123_out: endpoint@0 { - remote-endpoint = <&vga_connector_in>; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/video/adi,adv7511.txt b/Documentation/devicetree/bindings/video/adi,adv7511.txt deleted file mode 100644 index 96c25ee01..000000000 --- a/Documentation/devicetree/bindings/video/adi,adv7511.txt +++ /dev/null @@ -1,88 +0,0 @@ -Analog Device ADV7511(W)/13 HDMI Encoders ------------------------------------------ - -The ADV7511, ADV7511W and ADV7513 are HDMI audio and video transmitters -compatible with HDMI 1.4 and DVI 1.0. They support color space conversion, -S/PDIF, CEC and HDCP. - -Required properties: - -- compatible: Should be one of "adi,adv7511", "adi,adv7511w" or "adi,adv7513" -- reg: I2C slave address - -The ADV7511 supports a large number of input data formats that differ by their -color depth, color format, clock mode, bit justification and random -arrangement of components on the data bus. The combination of the following -properties describe the input and map directly to the video input tables of the -ADV7511 datasheet that document all the supported combinations. - -- adi,input-depth: Number of bits per color component at the input (8, 10 or - 12). -- adi,input-colorspace: The input color space, one of "rgb", "yuv422" or - "yuv444". -- adi,input-clock: The input clock type, one of "1x" (one clock cycle per - pixel), "2x" (two clock cycles per pixel), "ddr" (one clock cycle per pixel, - data driven on both edges). - -The following input format properties are required except in "rgb 1x" and -"yuv444 1x" modes, in which case they must not be specified. - -- adi,input-style: The input components arrangement variant (1, 2 or 3), as - listed in the input format tables in the datasheet. -- adi,input-justification: The input bit justification ("left", "evenly", - "right"). - -Optional properties: - -- interrupts: Specifier for the ADV7511 interrupt -- pd-gpios: Specifier for the GPIO connected to the power down signal - -- adi,clock-delay: Video data clock delay relative to the pixel clock, in ps - (-1200 ps .. 1600 ps). Defaults to no delay. -- adi,embedded-sync: The input uses synchronization signals embedded in the - data stream (similar to BT.656). Defaults to separate H/V synchronization - signals. - -Required nodes: - -The ADV7511 has two video ports. Their connections are modelled using the OF -graph bindings specified in Documentation/devicetree/bindings/graph.txt. - -- Video port 0 for the RGB or YUV input -- Video port 1 for the HDMI output - - -Example -------- - - adv7511w: hdmi@39 { - compatible = "adi,adv7511w"; - reg = <39>; - interrupt-parent = <&gpio3>; - interrupts = <29 IRQ_TYPE_EDGE_FALLING>; - - adi,input-depth = <8>; - adi,input-colorspace = "rgb"; - adi,input-clock = "1x"; - adi,input-style = <1>; - adi,input-justification = "evenly"; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - adv7511w_in: endpoint { - remote-endpoint = <&dpi_out>; - }; - }; - - port@1 { - reg = <1>; - adv7511_out: endpoint { - remote-endpoint = <&hdmi_connector_in>; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/video/analog-tv-connector.txt b/Documentation/devicetree/bindings/video/analog-tv-connector.txt deleted file mode 100644 index 0c0970c21..000000000 --- a/Documentation/devicetree/bindings/video/analog-tv-connector.txt +++ /dev/null @@ -1,25 +0,0 @@ -Analog TV Connector -=================== - -Required properties: -- compatible: "composite-video-connector" or "svideo-connector" - -Optional properties: -- label: a symbolic name for the connector - -Required nodes: -- Video port for TV input - -Example -------- - -tv: connector { - compatible = "composite-video-connector"; - label = "tv"; - - port { - tv_connector_in: endpoint { - remote-endpoint = <&venc_out>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/video/arm,pl11x.txt b/Documentation/devicetree/bindings/video/arm,pl11x.txt deleted file mode 100644 index 3e3039a8a..000000000 --- a/Documentation/devicetree/bindings/video/arm,pl11x.txt +++ /dev/null @@ -1,109 +0,0 @@ -* ARM PrimeCell Color LCD Controller PL110/PL111 - -See also Documentation/devicetree/bindings/arm/primecell.txt - -Required properties: - -- compatible: must be one of: - "arm,pl110", "arm,primecell" - "arm,pl111", "arm,primecell" - -- reg: base address and size of the control registers block - -- interrupt-names: either the single entry "combined" representing a - combined interrupt output (CLCDINTR), or the four entries - "mbe", "vcomp", "lnbu", "fuf" representing the individual - CLCDMBEINTR, CLCDVCOMPINTR, CLCDLNBUINTR, CLCDFUFINTR interrupts - -- interrupts: contains an interrupt specifier for each entry in - interrupt-names - -- clock-names: should contain "clcdclk" and "apb_pclk" - -- clocks: contains phandle and clock specifier pairs for the entries - in the clock-names property. See - Documentation/devicetree/binding/clock/clock-bindings.txt - -Optional properties: - -- memory-region: phandle to a node describing memory (see - Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt) - to be used for the framebuffer; if not present, the framebuffer - may be located anywhere in the memory - -- max-memory-bandwidth: maximum bandwidth in bytes per second that the - cell's memory interface can handle; if not present, the memory - interface is fast enough to handle all possible video modes - -Required sub-nodes: - -- port: describes LCD panel signals, following the common binding - for video transmitter interfaces; see - Documentation/devicetree/bindings/media/video-interfaces.txt; - when it is a TFT panel, the port's endpoint must define the - following property: - - - arm,pl11x,tft-r0g0b0-pads: an array of three 32-bit values, - defining the way CLD pads are wired up; first value - contains index of the "CLD" external pin (pad) used - as R0 (first bit of the red component), second value - index of the pad used as G0, third value index of the - pad used as B0, see also "LCD panel signal multiplexing - details" paragraphs in the PL110/PL111 Technical - Reference Manuals; this implicitly defines available - color modes, for example: - - PL111 TFT 4:4:4 panel: - arm,pl11x,tft-r0g0b0-pads = <4 15 20>; - - PL110 TFT (1:)5:5:5 panel: - arm,pl11x,tft-r0g0b0-pads = <1 7 13>; - - PL111 TFT (1:)5:5:5 panel: - arm,pl11x,tft-r0g0b0-pads = <3 11 19>; - - PL111 TFT 5:6:5 panel: - arm,pl11x,tft-r0g0b0-pads = <3 10 19>; - - PL110 and PL111 TFT 8:8:8 panel: - arm,pl11x,tft-r0g0b0-pads = <0 8 16>; - - PL110 and PL111 TFT 8:8:8 panel, R & B components swapped: - arm,pl11x,tft-r0g0b0-pads = <16 8 0>; - - -Example: - - clcd@10020000 { - compatible = "arm,pl111", "arm,primecell"; - reg = <0x10020000 0x1000>; - interrupt-names = "combined"; - interrupts = <0 44 4>; - clocks = <&oscclk1>, <&oscclk2>; - clock-names = "clcdclk", "apb_pclk"; - max-memory-bandwidth = <94371840>; /* Bps, 1024x768@60 16bpp */ - - port { - clcd_pads: endpoint { - remote-endpoint = <&clcd_panel>; - arm,pl11x,tft-r0g0b0-pads = <0 8 16>; - }; - }; - - }; - - panel { - compatible = "panel-dpi"; - - port { - clcd_panel: endpoint { - remote-endpoint = <&clcd_pads>; - }; - }; - - panel-timing { - clock-frequency = <25175000>; - hactive = <640>; - hback-porch = <40>; - hfront-porch = <24>; - hsync-len = <96>; - vactive = <480>; - vback-porch = <32>; - vfront-porch = <11>; - vsync-len = <2>; - }; - }; diff --git a/Documentation/devicetree/bindings/video/atmel,lcdc.txt b/Documentation/devicetree/bindings/video/atmel,lcdc.txt deleted file mode 100644 index ecb8da063..000000000 --- a/Documentation/devicetree/bindings/video/atmel,lcdc.txt +++ /dev/null @@ -1,89 +0,0 @@ -Atmel LCDC Framebuffer ------------------------------------------------------ - -Required properties: -- compatible : - "atmel,at91sam9261-lcdc" , - "atmel,at91sam9263-lcdc" , - "atmel,at91sam9g10-lcdc" , - "atmel,at91sam9g45-lcdc" , - "atmel,at91sam9g45es-lcdc" , - "atmel,at91sam9rl-lcdc" , - "atmel,at32ap-lcdc" -- reg : Should contain 1 register ranges(address and length). - Can contain an additional register range(address and length) - for fixed framebuffer memory. Useful for dedicated memories. -- interrupts : framebuffer controller interrupt -- display: a phandle pointing to the display node - -Required nodes: -- display: a display node is required to initialize the lcd panel - This should be in the board dts. -- default-mode: a videomode within the display with timing parameters - as specified below. - -Optional properties: -- lcd-supply: Regulator for LCD supply voltage. - -Example: - - fb0: fb@0x00500000 { - compatible = "atmel,at91sam9g45-lcdc"; - reg = <0x00500000 0x1000>; - interrupts = <23 3 0>; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_fb>; - display = <&display0>; - status = "okay"; - #address-cells = <1>; - #size-cells = <1>; - - }; - -Example for fixed framebuffer memory: - - fb0: fb@0x00500000 { - compatible = "atmel,at91sam9263-lcdc"; - reg = <0x00700000 0x1000 0x70000000 0x200000>; - [...] - }; - -Atmel LCDC Display ------------------------------------------------------ -Required properties (as per of_videomode_helper): - - - atmel,dmacon: dma controller configuration - - atmel,lcdcon2: lcd controller configuration - - atmel,guard-time: lcd guard time (Delay in frame periods) - - bits-per-pixel: lcd panel bit-depth. - -Optional properties (as per of_videomode_helper): - - atmel,lcdcon-backlight: enable backlight - - atmel,lcdcon-backlight-inverted: invert backlight PWM polarity - - atmel,lcd-wiring-mode: lcd wiring mode "RGB" or "BRG" - - atmel,power-control-gpio: gpio to power on or off the LCD (as many as needed) - -Example: - display0: display { - bits-per-pixel = <32>; - atmel,lcdcon-backlight; - atmel,dmacon = <0x1>; - atmel,lcdcon2 = <0x80008002>; - atmel,guard-time = <9>; - atmel,lcd-wiring-mode = <1>; - - display-timings { - native-mode = <&timing0>; - timing0: timing0 { - clock-frequency = <9000000>; - hactive = <480>; - vactive = <272>; - hback-porch = <1>; - hfront-porch = <1>; - vback-porch = <40>; - vfront-porch = <1>; - hsync-len = <45>; - vsync-len = <1>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/video/backlight/88pm860x.txt b/Documentation/devicetree/bindings/video/backlight/88pm860x.txt deleted file mode 100644 index 261df2799..000000000 --- a/Documentation/devicetree/bindings/video/backlight/88pm860x.txt +++ /dev/null @@ -1,15 +0,0 @@ -88pm860x-backlight bindings - -Optional properties: - - marvell,88pm860x-iset: Current supplies on backlight device. - - marvell,88pm860x-pwm: PWM frequency on backlight device. - -Example: - - backlights { - backlight-0 { - marvell,88pm860x-iset = <4>; - marvell,88pm860x-pwm = <3>; - }; - backlight-2 { - }; diff --git a/Documentation/devicetree/bindings/video/backlight/gpio-backlight.txt b/Documentation/devicetree/bindings/video/backlight/gpio-backlight.txt deleted file mode 100644 index 321be6640..000000000 --- a/Documentation/devicetree/bindings/video/backlight/gpio-backlight.txt +++ /dev/null @@ -1,16 +0,0 @@ -gpio-backlight bindings - -Required properties: - - compatible: "gpio-backlight" - - gpios: describes the gpio that is used for enabling/disabling the backlight. - refer to bindings/gpio/gpio.txt for more details. - -Optional properties: - - default-on: enable the backlight at boot. - -Example: - backlight { - compatible = "gpio-backlight"; - gpios = <&gpio3 4 GPIO_ACTIVE_HIGH>; - default-on; - }; diff --git a/Documentation/devicetree/bindings/video/backlight/lp855x.txt b/Documentation/devicetree/bindings/video/backlight/lp855x.txt deleted file mode 100644 index 0a3ecbc3a..000000000 --- a/Documentation/devicetree/bindings/video/backlight/lp855x.txt +++ /dev/null @@ -1,70 +0,0 @@ -lp855x bindings - -Required properties: - - compatible: "ti,lp8550", "ti,lp8551", "ti,lp8552", "ti,lp8553", - "ti,lp8555", "ti,lp8556", "ti,lp8557" - - reg: I2C slave address (u8) - - dev-ctrl: Value of DEVICE CONTROL register (u8). It depends on the device. - -Optional properties: - - bl-name: Backlight device name (string) - - init-brt: Initial value of backlight brightness (u8) - - pwm-period: PWM period value. Set only PWM input mode used (u32) - - rom-addr: Register address of ROM area to be updated (u8) - - rom-val: Register value to be updated (u8) - - power-supply: Regulator which controls the 3V rail - -Example: - - /* LP8555 */ - backlight@2c { - compatible = "ti,lp8555"; - reg = <0x2c>; - - dev-ctrl = /bits/ 8 <0x00>; - pwm-period = <10000>; - - /* 4V OV, 4 output LED0 string enabled */ - rom_14h { - rom-addr = /bits/ 8 <0x14>; - rom-val = /bits/ 8 <0xcf>; - }; - - /* Heavy smoothing, 24ms ramp time step */ - rom_15h { - rom-addr = /bits/ 8 <0x15>; - rom-val = /bits/ 8 <0xc7>; - }; - - /* 4 output LED1 string enabled */ - rom_19h { - rom-addr = /bits/ 8 <0x19>; - rom-val = /bits/ 8 <0x0f>; - }; - }; - - /* LP8556 */ - backlight@2c { - compatible = "ti,lp8556"; - reg = <0x2c>; - - bl-name = "lcd-bl"; - dev-ctrl = /bits/ 8 <0x85>; - init-brt = /bits/ 8 <0x10>; - }; - - /* LP8557 */ - backlight@2c { - compatible = "ti,lp8557"; - reg = <0x2c>; - power-supply = <&backlight_vdd>; - - dev-ctrl = /bits/ 8 <0x41>; - init-brt = /bits/ 8 <0x0a>; - - /* 4V OV, 4 output LED string enabled */ - rom_14h { - rom-addr = /bits/ 8 <0x14>; - rom-val = /bits/ 8 <0xcf>; - }; - }; diff --git a/Documentation/devicetree/bindings/video/backlight/max8925-backlight.txt b/Documentation/devicetree/bindings/video/backlight/max8925-backlight.txt deleted file mode 100644 index b4cffdaa4..000000000 --- a/Documentation/devicetree/bindings/video/backlight/max8925-backlight.txt +++ /dev/null @@ -1,10 +0,0 @@ -88pm860x-backlight bindings - -Optional properties: - - maxim,max8925-dual-string: whether support dual string - -Example: - - backlights { - maxim,max8925-dual-string = <0>; - }; diff --git a/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt b/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt deleted file mode 100644 index 424f8444a..000000000 --- a/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt +++ /dev/null @@ -1,40 +0,0 @@ -Binding for Qualcomm PM8941 WLED driver - -Required properties: -- compatible: should be "qcom,pm8941-wled" -- reg: slave address - -Optional properties: -- label: The name of the backlight device -- qcom,cs-out: bool; enable current sink output -- qcom,cabc: bool; enable content adaptive backlight control -- qcom,ext-gen: bool; use externally generated modulator signal to dim -- qcom,current-limit: mA; per-string current limit; value from 0 to 25 - default: 20mA -- qcom,current-boost-limit: mA; boost current limit; one of: - 105, 385, 525, 805, 980, 1260, 1400, 1680 - default: 805mA -- qcom,switching-freq: kHz; switching frequency; one of: - 600, 640, 685, 738, 800, 872, 960, 1066, 1200, 1371, - 1600, 1920, 2400, 3200, 4800, 9600, - default: 1600kHz -- qcom,ovp: V; Over-voltage protection limit; one of: - 27, 29, 32, 35 - default: 29V -- qcom,num-strings: #; number of led strings attached; value from 1 to 3 - default: 2 - -Example: - -pm8941-wled@d800 { - compatible = "qcom,pm8941-wled"; - reg = <0xd800>; - label = "backlight"; - - qcom,cs-out; - qcom,current-limit = <20>; - qcom,current-boost-limit = <805>; - qcom,switching-freq = <1600>; - qcom,ovp = <29>; - qcom,num-strings = <2>; -}; diff --git a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt deleted file mode 100644 index 764db86d4..000000000 --- a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt +++ /dev/null @@ -1,35 +0,0 @@ -pwm-backlight bindings - -Required properties: - - compatible: "pwm-backlight" - - pwms: OF device-tree PWM specification (see PWM binding[0]) - - brightness-levels: Array of distinct brightness levels. Typically these - are in the range from 0 to 255, but any range starting at 0 will do. - The actual brightness level (PWM duty cycle) will be interpolated - from these values. 0 means a 0% duty cycle (darkest/off), while the - last value in the array represents a 100% duty cycle (brightest). - - default-brightness-level: the default brightness level (index into the - array defined by the "brightness-levels" property) - - power-supply: regulator for supply voltage - -Optional properties: - - pwm-names: a list of names for the PWM devices specified in the - "pwms" property (see PWM binding[0]) - - enable-gpios: contains a single GPIO specifier for the GPIO which enables - and disables the backlight (see GPIO binding[1]) - -[0]: Documentation/devicetree/bindings/pwm/pwm.txt -[1]: Documentation/devicetree/bindings/gpio/gpio.txt - -Example: - - backlight { - compatible = "pwm-backlight"; - pwms = <&pwm 0 5000000>; - - brightness-levels = <0 4 8 16 32 64 128 255>; - default-brightness-level = <6>; - - power-supply = <&vdd_bl_reg>; - enable-gpios = <&gpio 58 0>; - }; diff --git a/Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt b/Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt deleted file mode 100644 index 8bf2940f5..000000000 --- a/Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt +++ /dev/null @@ -1,29 +0,0 @@ -SKY81452-backlight bindings - -Required properties: -- compatible : Must be "skyworks,sky81452-backlight" - -Optional properties: -- name : Name of backlight device. Default is 'lcd-backlight'. -- gpios : GPIO to use to EN pin. - See Documentation/devicetree/bindings/gpio/gpio.txt -- led-sources : List of enabled channels from 0 to 5. - See Documentation/devicetree/bindings/leds/common.txt -- skyworks,ignore-pwm : Ignore both PWM input -- skyworks,dpwm-mode : Enable DPWM dimming mode, otherwise Analog dimming. -- skyworks,phase-shift : Enable phase shift mode -- skyworks,short-detection-threshold-volt - : It should be one of 4, 5, 6 and 7V. -- skyworks,current-limit-mA - : It should be 2300mA or 2750mA. - -Example: - - backlight { - compatible = "skyworks,sky81452-backlight"; - name = "pwm-backlight"; - led-sources = <0 1 2 5>; - skyworks,ignore-pwm; - skyworks,phase-shift; - skyworks,current-limit-mA = <2300>; - }; diff --git a/Documentation/devicetree/bindings/video/backlight/tps65217-backlight.txt b/Documentation/devicetree/bindings/video/backlight/tps65217-backlight.txt deleted file mode 100644 index 5fb9279ac..000000000 --- a/Documentation/devicetree/bindings/video/backlight/tps65217-backlight.txt +++ /dev/null @@ -1,27 +0,0 @@ -TPS65217 family of regulators - -The TPS65217 chip contains a boost converter and current sinks which can be -used to drive LEDs for use as backlights. - -Required properties: -- compatible: "ti,tps65217" -- reg: I2C slave address -- backlight: node for specifying WLED1 and WLED2 lines in TPS65217 -- isel: selection bit, valid values: 1 for ISEL1 (low-level) and 2 for ISEL2 (high-level) -- fdim: PWM dimming frequency, valid values: 100, 200, 500, 1000 -- default-brightness: valid values: 0-100 - -Each regulator is defined using the standard binding for regulators. - -Example: - - tps: tps@24 { - reg = <0x24>; - compatible = "ti,tps65217"; - backlight { - isel = <1>; /* 1 - ISET1, 2 ISET2 */ - fdim = <100>; /* TPS65217_BL_FDIM_100HZ */ - default-brightness = <50>; - }; - }; - diff --git a/Documentation/devicetree/bindings/video/bridge/ps8622.txt b/Documentation/devicetree/bindings/video/bridge/ps8622.txt deleted file mode 100644 index c989c3807..000000000 --- a/Documentation/devicetree/bindings/video/bridge/ps8622.txt +++ /dev/null @@ -1,31 +0,0 @@ -ps8622-bridge bindings - -Required properties: - - compatible: "parade,ps8622" or "parade,ps8625" - - reg: first i2c address of the bridge - - sleep-gpios: OF device-tree gpio specification for PD_ pin. - - reset-gpios: OF device-tree gpio specification for RST_ pin. - -Optional properties: - - lane-count: number of DP lanes to use - - use-external-pwm: backlight will be controlled by an external PWM - - video interfaces: Device node can contain video interface port - nodes for panel according to [1]. - -[1]: Documentation/devicetree/bindings/media/video-interfaces.txt - -Example: - lvds-bridge@48 { - compatible = "parade,ps8622"; - reg = <0x48>; - sleep-gpios = <&gpc3 6 1 0 0>; - reset-gpios = <&gpc3 1 1 0 0>; - lane-count = <1>; - ports { - port@0 { - bridge_out: endpoint { - remote-endpoint = <&panel_in>; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/video/bridge/ptn3460.txt b/Documentation/devicetree/bindings/video/bridge/ptn3460.txt deleted file mode 100644 index 361971ba1..000000000 --- a/Documentation/devicetree/bindings/video/bridge/ptn3460.txt +++ /dev/null @@ -1,39 +0,0 @@ -ptn3460 bridge bindings - -Required properties: - - compatible: "nxp,ptn3460" - - reg: i2c address of the bridge - - powerdown-gpio: OF device-tree gpio specification for PD_N pin. - - reset-gpio: OF device-tree gpio specification for RST_N pin. - - edid-emulation: The EDID emulation entry to use - +-------+------------+------------------+ - | Value | Resolution | Description | - | 0 | 1024x768 | NXP Generic | - | 1 | 1920x1080 | NXP Generic | - | 2 | 1920x1080 | NXP Generic | - | 3 | 1600x900 | Samsung LTM200KT | - | 4 | 1920x1080 | Samsung LTM230HT | - | 5 | 1366x768 | NXP Generic | - | 6 | 1600x900 | ChiMei M215HGE | - +-------+------------+------------------+ - - - video interfaces: Device node can contain video interface port - nodes for panel according to [1]. - -[1]: Documentation/devicetree/bindings/media/video-interfaces.txt - -Example: - lvds-bridge@20 { - compatible = "nxp,ptn3460"; - reg = <0x20>; - powerdown-gpio = <&gpy2 5 1 0 0>; - reset-gpio = <&gpx1 5 1 0 0>; - edid-emulation = <5>; - ports { - port@0 { - bridge_out: endpoint { - remote-endpoint = <&panel_in>; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/video/cirrus,clps711x-fb.txt b/Documentation/devicetree/bindings/video/cirrus,clps711x-fb.txt deleted file mode 100644 index 6fc3c6ade..000000000 --- a/Documentation/devicetree/bindings/video/cirrus,clps711x-fb.txt +++ /dev/null @@ -1,47 +0,0 @@ -* Currus Logic CLPS711X Framebuffer - -Required properties: -- compatible: Shall contain "cirrus,clps711x-fb". -- reg : Physical base address and length of the controller's registers + - location and size of the framebuffer memory. -- clocks : phandle + clock specifier pair of the FB reference clock. -- display : phandle to a display node as described in - Documentation/devicetree/bindings/video/display-timing.txt. - Additionally, the display node has to define properties: - - bits-per-pixel: Bits per pixel. - - ac-prescale : LCD AC bias frequency. This frequency is the required - AC bias frequency for a given manufacturer's LCD plate. - - cmap-invert : Invert the color levels (Optional). - -Optional properties: -- lcd-supply: Regulator for LCD supply voltage. - -Example: - fb: fb@800002c0 { - compatible = "cirrus,ep7312-fb", "cirrus,clps711x-fb"; - reg = <0x800002c0 0xd44>, <0x60000000 0xc000>; - clocks = <&clks 2>; - lcd-supply = <®5v0>; - display = <&display>; - }; - - display: display { - model = "320x240x4"; - native-mode = <&timing0>; - bits-per-pixel = <4>; - ac-prescale = <17>; - - display-timings { - timing0: 320x240 { - hactive = <320>; - hback-porch = <0>; - hfront-porch = <0>; - hsync-len = <0>; - vactive = <240>; - vback-porch = <0>; - vfront-porch = <0>; - vsync-len = <0>; - clock-frequency = <6500000>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/video/display-timing.txt b/Documentation/devicetree/bindings/video/display-timing.txt deleted file mode 100644 index e1d4a0b59..000000000 --- a/Documentation/devicetree/bindings/video/display-timing.txt +++ /dev/null @@ -1,110 +0,0 @@ -display-timing bindings -======================= - -display-timings node --------------------- - -required properties: - - none - -optional properties: - - native-mode: The native mode for the display, in case multiple modes are - provided. When omitted, assume the first node is the native. - -timing subnode --------------- - -required properties: - - hactive, vactive: display resolution - - hfront-porch, hback-porch, hsync-len: horizontal display timing parameters - in pixels - vfront-porch, vback-porch, vsync-len: vertical display timing parameters in - lines - - clock-frequency: display clock in Hz - -optional properties: - - hsync-active: hsync pulse is active low/high/ignored - - vsync-active: vsync pulse is active low/high/ignored - - de-active: data-enable pulse is active low/high/ignored - - pixelclk-active: with - - active high = drive pixel data on rising edge/ - sample data on falling edge - - active low = drive pixel data on falling edge/ - sample data on rising edge - - ignored = ignored - - interlaced (bool): boolean to enable interlaced mode - - doublescan (bool): boolean to enable doublescan mode - - doubleclk (bool): boolean to enable doubleclock mode - -All the optional properties that are not bool follow the following logic: - <1>: high active - <0>: low active - omitted: not used on hardware - -There are different ways of describing the capabilities of a display. The -devicetree representation corresponds to the one commonly found in datasheets -for displays. If a display supports multiple signal timings, the native-mode -can be specified. - -The parameters are defined as: - - +----------+-------------------------------------+----------+-------+ - | | ↑ | | | - | | |vback_porch | | | - | | ↓ | | | - +----------#######################################----------+-------+ - | # ↑ # | | - | # | # | | - | hback # | # hfront | hsync | - | porch # | hactive # porch | len | - |<-------->#<-------+--------------------------->#<-------->|<----->| - | # | # | | - | # |vactive # | | - | # | # | | - | # ↓ # | | - +----------#######################################----------+-------+ - | | ↑ | | | - | | |vfront_porch | | | - | | ↓ | | | - +----------+-------------------------------------+----------+-------+ - | | ↑ | | | - | | |vsync_len | | | - | | ↓ | | | - +----------+-------------------------------------+----------+-------+ - -Example: - - display-timings { - native-mode = <&timing0>; - timing0: 1080p24 { - /* 1920x1080p24 */ - clock-frequency = <52000000>; - hactive = <1920>; - vactive = <1080>; - hfront-porch = <25>; - hback-porch = <25>; - hsync-len = <25>; - vback-porch = <2>; - vfront-porch = <2>; - vsync-len = <2>; - hsync-active = <1>; - }; - }; - -Every required property also supports the use of ranges, so the commonly used -datasheet description with minimum, typical and maximum values can be used. - -Example: - - timing1: timing { - /* 1920x1080p24 */ - clock-frequency = <148500000>; - hactive = <1920>; - vactive = <1080>; - hsync-len = <0 44 60>; - hfront-porch = <80 88 95>; - hback-porch = <100 148 160>; - vfront-porch = <0 4 6>; - vback-porch = <0 36 50>; - vsync-len = <0 5 6>; - }; diff --git a/Documentation/devicetree/bindings/video/dvi-connector.txt b/Documentation/devicetree/bindings/video/dvi-connector.txt deleted file mode 100644 index fc53f7c60..000000000 --- a/Documentation/devicetree/bindings/video/dvi-connector.txt +++ /dev/null @@ -1,35 +0,0 @@ -DVI Connector -============== - -Required properties: -- compatible: "dvi-connector" - -Optional properties: -- label: a symbolic name for the connector -- ddc-i2c-bus: phandle to the i2c bus that is connected to DVI DDC -- analog: the connector has DVI analog pins -- digital: the connector has DVI digital pins -- dual-link: the connector has pins for DVI dual-link - -Required nodes: -- Video port for DVI input - -Note: One (or both) of 'analog' or 'digital' must be set. - -Example -------- - -dvi0: connector@0 { - compatible = "dvi-connector"; - label = "dvi"; - - digital; - - ddc-i2c-bus = <&i2c3>; - - port { - dvi_connector_in: endpoint { - remote-endpoint = <&tfp410_out>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt b/Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt deleted file mode 100644 index 668091f27..000000000 --- a/Documentation/devicetree/bindings/video/dw_hdmi-rockchip.txt +++ /dev/null @@ -1,46 +0,0 @@ -Rockchip specific extensions to the Synopsys Designware HDMI -================================ - -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. -- 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 - -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" - -Example: -hdmi: hdmi@ff980000 { - compatible = "rockchip,rk3288-dw-hdmi"; - reg = <0xff980000 0x20000>; - reg-io-width = <4>; - ddc-i2c-bus = <&i2c5>; - rockchip,grf = <&grf>; - interrupts = ; - clocks = <&cru PCLK_HDMI_CTRL>, <&cru SCLK_HDMI_HDCP>; - clock-names = "iahb", "isfr"; - status = "disabled"; - ports { - hdmi_in: port { - #address-cells = <1>; - #size-cells = <0>; - hdmi_in_vopb: endpoint@0 { - reg = <0>; - remote-endpoint = <&vopb_out_hdmi>; - }; - hdmi_in_vopl: endpoint@1 { - reg = <1>; - remote-endpoint = <&vopl_out_hdmi>; - }; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/video/exynos-mic.txt b/Documentation/devicetree/bindings/video/exynos-mic.txt deleted file mode 100644 index 0fba2ee64..000000000 --- a/Documentation/devicetree/bindings/video/exynos-mic.txt +++ /dev/null @@ -1,51 +0,0 @@ -Device-Tree bindings for Samsung Exynos SoC mobile image compressor (MIC) - -MIC (mobile image compressor) resides between decon and mipi dsi. Mipi dsi is -not capable to transfer high resoltuion frame data as decon can send. MIC -solves this problem by compressing the frame data by 1/2 before it is -transferred through mipi dsi. The compressed frame data must be uncompressed in -the panel PCB. - -Required properties: -- compatible: value should be "samsung,exynos5433-mic". -- reg: physical base address and length of the MIC registers set and system - register of mic. -- clocks: must include clock specifiers corresponding to entries in the - clock-names property. -- clock-names: list of clock names sorted in the same order as the clocks - property. Must contain "pclk_mic0", "sclk_rgb_vclk_to_mic0". -- samsung,disp-syscon: the reference node for syscon for DISP block. -- ports: contains a port which is connected to decon node and dsi node. - address-cells and size-cells must 1 and 0, respectively. -- port: contains an endpoint node which is connected to the endpoint in the - decon node or dsi node. The reg value must be 0 and 1 respectively. - -Example: -SoC specific DT entry: -mic: mic@13930000 { - compatible = "samsung,exynos5433-mic"; - reg = <0x13930000 0x48>; - clocks = <&cmu_disp CLK_PCLK_MIC0>, - <&cmu_disp CLK_SCLK_RGB_VCLK_TO_MIC0>; - clock-names = "pclk_mic0", "sclk_rgb_vclk_to_mic0"; - samsung,disp-syscon = <&syscon_disp>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - mic_to_decon: endpoint { - remote-endpoint = <&decon_to_mic>; - }; - }; - - port@1 { - reg = <1>; - mic_to_dsi: endpoint { - remote-endpoint = <&dsi_to_mic>; - }; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/video/exynos5433-decon.txt b/Documentation/devicetree/bindings/video/exynos5433-decon.txt deleted file mode 100644 index 377afbf51..000000000 --- a/Documentation/devicetree/bindings/video/exynos5433-decon.txt +++ /dev/null @@ -1,65 +0,0 @@ -Device-Tree bindings for Samsung Exynos SoC display controller (DECON) - -DECON (Display and Enhancement Controller) is the Display Controller for the -Exynos series of SoCs which transfers the image data from a video memory -buffer to an external LCD interface. - -Required properties: -- compatible: value should be "samsung,exynos5433-decon"; -- reg: physical base address and length of the DECON registers set. -- interrupts: should contain a list of all DECON IP block interrupts in the - order: VSYNC, LCD_SYSTEM. The interrupt specifier format - depends on the interrupt controller used. -- interrupt-names: should contain the interrupt names: "vsync", "lcd_sys" - in the same order as they were listed in the interrupts - property. -- clocks: must include clock specifiers corresponding to entries in the - clock-names property. -- clock-names: list of clock names sorted in the same order as the clocks - property. Must contain "aclk_decon", "aclk_smmu_decon0x", - "aclk_xiu_decon0x", "pclk_smmu_decon0x", clk_decon_vclk", - "sclk_decon_eclk" -- ports: contains a port which is connected to mic node. address-cells and - size-cells must 1 and 0, respectively. -- port: contains an endpoint node which is connected to the endpoint in the mic - node. The reg value muset be 0. -- i80-if-timings: specify whether the panel which is connected to decon uses - i80 lcd interface or mipi video interface. This node contains - no timing information as that of fimd does. Because there is - no register in decon to specify i80 interface timing value, - it is not needed, but make it remain to use same kind of node - in fimd and exynos7 decon. - -Example: -SoC specific DT entry: -decon: decon@13800000 { - compatible = "samsung,exynos5433-decon"; - reg = <0x13800000 0x2104>; - clocks = <&cmu_disp CLK_ACLK_DECON>, <&cmu_disp CLK_ACLK_SMMU_DECON0X>, - <&cmu_disp CLK_ACLK_XIU_DECON0X>, - <&cmu_disp CLK_PCLK_SMMU_DECON0X>, - <&cmu_disp CLK_SCLK_DECON_VCLK>, - <&cmu_disp CLK_SCLK_DECON_ECLK>; - clock-names = "aclk_decon", "aclk_smmu_decon0x", "aclk_xiu_decon0x", - "pclk_smmu_decon0x", "sclk_decon_vclk", "sclk_decon_eclk"; - interrupt-names = "vsync", "lcd_sys"; - interrupts = <0 202 0>, <0 203 0>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - decon_to_mic: endpoint { - remote-endpoint = <&mic_to_decon>; - }; - }; - }; -}; - -Board specific DT entry: -&decon { - i80-if-timings { - }; -}; diff --git a/Documentation/devicetree/bindings/video/exynos7-decon.txt b/Documentation/devicetree/bindings/video/exynos7-decon.txt deleted file mode 100644 index f5f9c8d4a..000000000 --- a/Documentation/devicetree/bindings/video/exynos7-decon.txt +++ /dev/null @@ -1,68 +0,0 @@ -Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON) - -DECON (Display and Enhancement Controller) is the Display Controller for the -Exynos7 series of SoCs which transfers the image data from a video memory -buffer to an external LCD interface. - -Required properties: -- compatible: value should be "samsung,exynos7-decon"; - -- reg: physical base address and length of the DECON registers set. - -- interrupt-parent: should be the phandle of the decon controller's - parent interrupt controller. - -- interrupts: should contain a list of all DECON IP block interrupts in the - order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier - format depends on the interrupt controller used. - -- interrupt-names: should contain the interrupt names: "fifo", "vsync", - "lcd_sys", in the same order as they were listed in the interrupts - property. - -- pinctrl-0: pin control group to be used for this controller. - -- pinctrl-names: must contain a "default" entry. - -- clocks: must include clock specifiers corresponding to entries in the - clock-names property. - -- clock-names: list of clock names sorted in the same order as the clocks - property. Must contain "pclk_decon0", "aclk_decon0", - "decon0_eclk", "decon0_vclk". -- i80-if-timings: timing configuration for lcd i80 interface support. - -Optional Properties: -- samsung,power-domain: 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. - -[1]: Documentation/devicetree/bindings/video/display-timing.txt - -Example: - -SoC specific DT entry: - - decon@13930000 { - compatible = "samsung,exynos7-decon"; - interrupt-parent = <&combiner>; - reg = <0x13930000 0x1000>; - interrupt-names = "lcd_sys", "vsync", "fifo"; - interrupts = <0 188 0>, <0 189 0>, <0 190 0>; - clocks = <&clock_disp PCLK_DECON_INT>, - <&clock_disp ACLK_DECON_INT>, - <&clock_disp SCLK_DECON_INT_ECLK>, - <&clock_disp SCLK_DECON_INT_EXTCLKPLL>; - clock-names = "pclk_decon0", "aclk_decon0", "decon0_eclk", - "decon0_vclk"; - status = "disabled"; - }; - -Board specific DT entry: - - decon@13930000 { - pinctrl-0 = <&lcd_clk &pwm1_out>; - pinctrl-names = "default"; - status = "okay"; - }; diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt b/Documentation/devicetree/bindings/video/exynos_dp.txt deleted file mode 100644 index 7a3a9cdb8..000000000 --- a/Documentation/devicetree/bindings/video/exynos_dp.txt +++ /dev/null @@ -1,120 +0,0 @@ -The Exynos display port interface should be configured based on -the type of panel connected to it. - -We use two nodes: - -dp-controller node - -dptx-phy node(defined inside dp-controller node) - -For the DP-PHY initialization, we use the dptx-phy node. -Required properties for dptx-phy: deprecated, use phys and phy-names - -reg: deprecated - Base address of DP PHY register. - -samsung,enable-mask: deprecated - The bit-mask used to enable/disable DP PHY. - -For the Panel initialization, we read data from dp-controller node. -Required properties for dp-controller: - -compatible: - should be "samsung,exynos5-dp". - -reg: - physical base address of the controller and length - of memory mapped region. - -interrupts: - interrupt combiner values. - -clocks: - from common clock binding: handle to dp clock. - -clock-names: - from common clock binding: Shall be "dp". - -interrupt-parent: - phandle to Interrupt combiner node. - -phys: - from general PHY binding: the phandle for the PHY device. - -phy-names: - from general PHY binding: Should be "dp". - -samsung,color-space: - input video data format. - COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2 - -samsung,dynamic-range: - dynamic range for input video data. - VESA = 0, CEA = 1 - -samsung,ycbcr-coeff: - YCbCr co-efficients for input video. - COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1 - -samsung,color-depth: - number of bits per colour component. - COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3 - -samsung,link-rate: - link rate supported by the panel. - LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A - -samsung,lane-count: - number of lanes supported by the panel. - LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4 - - display-timings: timings for the connected panel as described by - Documentation/devicetree/bindings/video/display-timing.txt - -Optional properties for dp-controller: - -interlaced: - interlace scan mode. - Progressive if defined, Interlaced if not defined - -vsync-active-high: - VSYNC polarity configuration. - High if defined, Low if not defined - -hsync-active-high: - HSYNC polarity configuration. - High if defined, Low if not defined - -samsung,hpd-gpio: - Hotplug detect GPIO. - Indicates which GPIO should be used for hotplug - detection - -video interfaces: Device node can contain video interface port - nodes according to [1]. - -[1]: Documentation/devicetree/bindings/media/video-interfaces.txt - -Example: - -SOC specific portion: - dp-controller { - compatible = "samsung,exynos5-dp"; - reg = <0x145b0000 0x10000>; - interrupts = <10 3>; - interrupt-parent = <&combiner>; - clocks = <&clock 342>; - clock-names = "dp"; - - phys = <&dp_phy>; - phy-names = "dp"; - }; - -Board Specific portion: - dp-controller { - samsung,color-space = <0>; - samsung,dynamic-range = <0>; - samsung,ycbcr-coeff = <0>; - samsung,color-depth = <1>; - samsung,link-rate = <0x0a>; - samsung,lane-count = <4>; - - display-timings { - native-mode = <&lcd_timing>; - lcd_timing: 1366x768 { - clock-frequency = <70589280>; - hactive = <1366>; - vactive = <768>; - hfront-porch = <40>; - hback-porch = <40>; - hsync-len = <32>; - vback-porch = <10>; - vfront-porch = <12>; - vsync-len = <6>; - }; - }; - - ports { - port@0 { - dp_out: endpoint { - remote-endpoint = <&bridge_in>; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/video/exynos_dsim.txt b/Documentation/devicetree/bindings/video/exynos_dsim.txt deleted file mode 100644 index 0be036270..000000000 --- a/Documentation/devicetree/bindings/video/exynos_dsim.txt +++ /dev/null @@ -1,103 +0,0 @@ -Exynos MIPI DSI Master - -Required properties: - - compatible: value should be one of the following - "samsung,exynos3250-mipi-dsi" /* for Exynos3250/3472 SoCs */ - "samsung,exynos4210-mipi-dsi" /* for Exynos4 SoCs */ - "samsung,exynos4415-mipi-dsi" /* for Exynos4415 SoC */ - "samsung,exynos5410-mipi-dsi" /* for Exynos5410/5420/5440 SoCs */ - "samsung,exynos5433-mipi-dsi" /* for Exynos5433 SoCs */ - - reg: physical base address and length of the registers set for the device - - interrupts: should contain DSI interrupt - - clocks: list of clock specifiers, must contain an entry for each required - entry in clock-names - - clock-names: should include "bus_clk"and "sclk_mipi" entries - the use of "pll_clk" is deprecated - - phys: list of phy specifiers, must contain an entry for each required - entry in phy-names - - phy-names: should include "dsim" entry - - vddcore-supply: MIPI DSIM Core voltage supply (e.g. 1.1V) - - vddio-supply: MIPI DSIM I/O and PLL voltage supply (e.g. 1.8V) - - samsung,pll-clock-frequency: specifies frequency of the oscillator clock - - #address-cells, #size-cells: should be set respectively to <1> and <0> - according to DSI host bindings (see MIPI DSI bindings [1]) - -Optional properties: - - power-domains: a phandle to DSIM power domain node - -Child nodes: - Should contain DSI peripheral nodes (see MIPI DSI bindings [1]). - -Video interfaces: - Device node can contain video interface port nodes according to [2]. - The following are properties specific to those nodes: - - port node inbound: - - reg: (required) must be 0. - port node outbound: - - reg: (required) must be 1. - - endpoint node connected from mic node (reg = 0): - - remote-endpoint: specifies the endpoint in mic node. This node is required - for Exynos5433 mipi dsi. So mic can access to panel node - thoughout this dsi node. - endpoint node connected to panel node (reg = 1): - - remote-endpoint: specifies the endpoint in panel node. This node is - required in all kinds of exynos mipi dsi to represent - the connection between mipi dsi and panel. - - samsung,burst-clock-frequency: specifies DSI frequency in high-speed burst - mode - - samsung,esc-clock-frequency: specifies DSI frequency in escape mode - -[1]: Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt -[2]: Documentation/devicetree/bindings/media/video-interfaces.txt - -Example: - - dsi@11C80000 { - compatible = "samsung,exynos4210-mipi-dsi"; - reg = <0x11C80000 0x10000>; - interrupts = <0 79 0>; - clocks = <&clock 286>, <&clock 143>; - clock-names = "bus_clk", "sclk_mipi"; - phys = <&mipi_phy 1>; - phy-names = "dsim"; - vddcore-supply = <&vusb_reg>; - vddio-supply = <&vmipi_reg>; - power-domains = <&pd_lcd0>; - #address-cells = <1>; - #size-cells = <0>; - samsung,pll-clock-frequency = <24000000>; - - panel@1 { - reg = <0>; - ... - port { - panel_ep: endpoint { - remote-endpoint = <&dsi_ep>; - }; - }; - }; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - decon_to_mic: endpoint { - remote-endpoint = <&mic_to_decon>; - }; - }; - - port@1 { - reg = <1>; - dsi_ep: endpoint { - reg = <0>; - samsung,burst-clock-frequency = <500000000>; - samsung,esc-clock-frequency = <20000000>; - remote-endpoint = <&panel_ep>; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt b/Documentation/devicetree/bindings/video/exynos_hdmi.txt deleted file mode 100644 index 1fd8cf9cb..000000000 --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt +++ /dev/null @@ -1,43 +0,0 @@ -Device-Tree bindings for drm hdmi driver - -Required properties: -- compatible: value should be one among the following: - 1) "samsung,exynos5-hdmi" - 2) "samsung,exynos4210-hdmi" - 3) "samsung,exynos4212-hdmi" - 4) "samsung,exynos5420-hdmi" -- reg: physical base address of the hdmi and length of memory mapped - region. -- interrupts: interrupt number to the cpu. -- hpd-gpio: following information about the hotplug gpio pin. - a) phandle of the gpio controller node. - b) pin number within the gpio controller. - c) optional flags and pull up/down. -- clocks: list of clock IDs from SoC clock driver. - a) hdmi: Gate of HDMI IP bus clock. - b) sclk_hdmi: Gate of HDMI special clock. - c) sclk_pixel: Pixel special clock, one of the two possible inputs of - HDMI clock mux. - d) sclk_hdmiphy: HDMI PHY clock output, one of two possible inputs of - HDMI clock mux. - e) mout_hdmi: It is required by the driver to switch between the 2 - parents i.e. sclk_pixel and sclk_hdmiphy. If hdmiphy is stable - after configuration, parent is set to sclk_hdmiphy else - sclk_pixel. -- clock-names: aliases as per driver requirements for above clock IDs: - "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi". -- ddc: phandle to the hdmi ddc node -- phy: phandle to the hdmi phy node -- samsung,syscon-phandle: phandle for system controller node for PMU. - -Example: - - hdmi { - compatible = "samsung,exynos4212-hdmi"; - reg = <0x14530000 0x100000>; - interrupts = <0 95 0>; - hpd-gpio = <&gpx3 7 1>; - ddc = <&hdmi_ddc_node>; - phy = <&hdmi_phy_node>; - samsung,syscon-phandle = <&pmu_system_controller>; - }; diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt deleted file mode 100644 index 41eee9715..000000000 --- a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt +++ /dev/null @@ -1,15 +0,0 @@ -Device-Tree bindings for hdmiddc driver - -Required properties: -- compatible: value should be one of the following - 1) "samsung,exynos5-hdmiddc" - 2) "samsung,exynos4210-hdmiddc" - -- reg: I2C address of the hdmiddc device. - -Example: - - hdmiddc { - compatible = "samsung,exynos4210-hdmiddc"; - reg = <0x50>; - }; diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt deleted file mode 100644 index 162f641f7..000000000 --- a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt +++ /dev/null @@ -1,15 +0,0 @@ -Device-Tree bindings for hdmiphy driver - -Required properties: -- compatible: value should be one of the following: - 1) "samsung,exynos5-hdmiphy" - 2) "samsung,exynos4210-hdmiphy". - 3) "samsung,exynos4212-hdmiphy". -- reg: I2C address of the hdmiphy device. - -Example: - - hdmiphy { - compatible = "samsung,exynos4210-hdmiphy"; - reg = <0x38>; - }; diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt b/Documentation/devicetree/bindings/video/exynos_mixer.txt deleted file mode 100644 index 3e38128f8..000000000 --- a/Documentation/devicetree/bindings/video/exynos_mixer.txt +++ /dev/null @@ -1,26 +0,0 @@ -Device-Tree bindings for mixer driver - -Required properties: -- compatible: value should be one of the following: - 1) "samsung,exynos5-mixer" - 2) "samsung,exynos4210-mixer" - 3) "samsung,exynos4212-mixer" - 4) "samsung,exynos5250-mixer" - 5) "samsung,exynos5420-mixer" - -- reg: physical base address of the mixer and length of memory mapped - region. -- interrupts: interrupt number to the cpu. -- clocks: list of clock IDs from SoC clock driver. - a) mixer: Gate of Mixer IP bus clock. - b) sclk_hdmi: HDMI Special clock, one of the two possible inputs of - mixer mux. - c) hdmi: Gate of HDMI IP bus clock, needed together with sclk_hdmi. - -Example: - - mixer { - compatible = "samsung,exynos5250-mixer"; - reg = <0x14450000 0x10000>; - interrupts = <0 94 0>; - }; diff --git a/Documentation/devicetree/bindings/video/fsl,dcu.txt b/Documentation/devicetree/bindings/video/fsl,dcu.txt deleted file mode 100644 index ebf1be9ae..000000000 --- a/Documentation/devicetree/bindings/video/fsl,dcu.txt +++ /dev/null @@ -1,22 +0,0 @@ -Device Tree bindings for Freescale DCU DRM Driver - -Required properties: -- compatible: Should be one of - * "fsl,ls1021a-dcu". - * "fsl,vf610-dcu". - -- reg: Address and length of the register set for dcu. -- clocks: From common clock binding: handle to dcu clock. -- clock-names: From common clock binding: Shall be "dcu". -- big-endian Boolean property, LS1021A DCU registers are big-endian. -- fsl,panel: The phandle to panel node. - -Examples: -dcu: dcu@2ce0000 { - compatible = "fsl,ls1021a-dcu"; - reg = <0x0 0x2ce0000 0x0 0x10000>; - clocks = <&platform_clk 0>; - clock-names = "dcu"; - big-endian; - fsl,panel = <&panel>; -}; diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt deleted file mode 100644 index 8c8c2f4e4..000000000 --- a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt +++ /dev/null @@ -1,55 +0,0 @@ -Freescale imx21 Framebuffer - -This framebuffer driver supports devices imx1, imx21, imx25, and imx27. - -Required properties: -- compatible : "fsl,-fb", chip should be imx1 or imx21 -- reg : Should contain 1 register ranges(address and length) -- interrupts : One interrupt of the fb dev - -Required nodes: -- display: Phandle to a display node as described in - Documentation/devicetree/bindings/video/display-timing.txt - Additional, the display node has to define properties: - - bits-per-pixel: Bits per pixel - - fsl,pcr: LCDC PCR value - -Optional properties: -- lcd-supply: Regulator for LCD supply voltage. -- fsl,dmacr: DMA Control Register value. This is optional. By default, the - register is not modified as recommended by the datasheet. -- fsl,lpccr: Contrast Control Register value. This property provides the - default value for the contrast control register. - If that property is omitted, the register is zeroed. -- fsl,lscr1: LCDC Sharp Configuration Register value. - -Example: - - imxfb: fb@10021000 { - compatible = "fsl,imx21-fb"; - interrupts = <61>; - reg = <0x10021000 0x1000>; - display = <&display0>; - }; - - ... - - display0: display0 { - model = "Primeview-PD050VL1"; - native-mode = <&timing_disp0>; - bits-per-pixel = <16>; - fsl,pcr = <0xf0c88080>; /* non-standard but required */ - display-timings { - timing_disp0: 640x480 { - hactive = <640>; - vactive = <480>; - hback-porch = <112>; - hfront-porch = <36>; - hsync-len = <32>; - vback-porch = <33>; - vfront-porch = <33>; - vsync-len = <2>; - clock-frequency = <25000000>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/video/hdmi-connector.txt b/Documentation/devicetree/bindings/video/hdmi-connector.txt deleted file mode 100644 index acd5668b1..000000000 --- a/Documentation/devicetree/bindings/video/hdmi-connector.txt +++ /dev/null @@ -1,29 +0,0 @@ -HDMI Connector -============== - -Required properties: -- compatible: "hdmi-connector" -- type: the HDMI connector type: "a", "b", "c", "d" or "e" - -Optional properties: -- label: a symbolic name for the connector -- hpd-gpios: HPD GPIO number - -Required nodes: -- Video port for HDMI input - -Example -------- - -hdmi0: connector@1 { - compatible = "hdmi-connector"; - label = "hdmi"; - - type = "a"; - - port { - hdmi_connector_in: endpoint { - remote-endpoint = <&tpd12s015_out>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/video/lgphilips,lb035q02.txt b/Documentation/devicetree/bindings/video/lgphilips,lb035q02.txt deleted file mode 100644 index 1a1e653e5..000000000 --- a/Documentation/devicetree/bindings/video/lgphilips,lb035q02.txt +++ /dev/null @@ -1,33 +0,0 @@ -LG.Philips LB035Q02 Panel -========================= - -Required properties: -- compatible: "lgphilips,lb035q02" -- enable-gpios: panel enable gpio - -Optional properties: -- label: a symbolic name for the panel - -Required nodes: -- Video port for DPI input - -Example -------- - -lcd-panel: panel@0 { - compatible = "lgphilips,lb035q02"; - reg = <0>; - spi-max-frequency = <100000>; - spi-cpol; - spi-cpha; - - label = "lcd"; - - enable-gpios = <&gpio7 7 0>; - - port { - lcd_in: endpoint { - remote-endpoint = <&dpi_out>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/video/panel-dpi.txt b/Documentation/devicetree/bindings/video/panel-dpi.txt deleted file mode 100644 index a40180b05..000000000 --- a/Documentation/devicetree/bindings/video/panel-dpi.txt +++ /dev/null @@ -1,45 +0,0 @@ -Generic MIPI DPI Panel -====================== - -Required properties: -- compatible: "panel-dpi" - -Optional properties: -- label: a symbolic name for the panel -- enable-gpios: panel enable gpio - -Required nodes: -- "panel-timing" containing video timings - (Documentation/devicetree/bindings/video/display-timing.txt) -- Video port for DPI input - -Example -------- - -lcd0: display@0 { - compatible = "samsung,lte430wq-f0c", "panel-dpi"; - label = "lcd"; - - port { - lcd_in: endpoint { - remote-endpoint = <&dpi_out>; - }; - }; - - panel-timing { - clock-frequency = <9200000>; - hactive = <480>; - vactive = <272>; - hfront-porch = <8>; - hback-porch = <4>; - hsync-len = <41>; - vback-porch = <2>; - vfront-porch = <4>; - vsync-len = <10>; - - hsync-active = <0>; - vsync-active = <0>; - de-active = <1>; - pixelclk-active = <1>; - }; -}; diff --git a/Documentation/devicetree/bindings/video/panel-dsi-cm.txt b/Documentation/devicetree/bindings/video/panel-dsi-cm.txt deleted file mode 100644 index dce48eb9d..000000000 --- a/Documentation/devicetree/bindings/video/panel-dsi-cm.txt +++ /dev/null @@ -1,29 +0,0 @@ -Generic MIPI DSI Command Mode Panel -=================================== - -Required properties: -- compatible: "panel-dsi-cm" - -Optional properties: -- label: a symbolic name for the panel -- reset-gpios: panel reset gpio -- te-gpios: panel TE gpio - -Required nodes: -- Video port for DSI input - -Example -------- - -lcd0: display { - compatible = "tpo,taal", "panel-dsi-cm"; - label = "lcd0"; - - reset-gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>; - - port { - lcd0_in: endpoint { - remote-endpoint = <&dsi1_out_ep>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/video/renesas,du.txt b/Documentation/devicetree/bindings/video/renesas,du.txt deleted file mode 100644 index c90232392..000000000 --- a/Documentation/devicetree/bindings/video/renesas,du.txt +++ /dev/null @@ -1,88 +0,0 @@ -* Renesas R-Car Display Unit (DU) - -Required Properties: - - - compatible: must be one of the following. - - "renesas,du-r8a7779" for R8A7779 (R-Car H1) compatible DU - - "renesas,du-r8a7790" for R8A7790 (R-Car H2) compatible DU - - "renesas,du-r8a7791" for R8A7791 (R-Car M2) compatible DU - - - reg: A list of base address and length of each memory resource, one for - each entry in the reg-names property. - - reg-names: Name of the memory resources. The DU requires one memory - resource for the DU core (named "du") and one memory resource for each - LVDS encoder (named "lvds.x" with "x" being the LVDS controller numerical - index). - - - interrupt-parent: phandle of the parent interrupt controller. - - interrupts: Interrupt specifiers for the DU interrupts. - - - clocks: A list of phandles + clock-specifier pairs, one for each entry in - the clock-names property. - - clock-names: Name of the clocks. This property is model-dependent. - - R8A7779 uses a single functional clock. The clock doesn't need to be - named. - - R8A7790 and R8A7791 use one functional clock per channel and one clock - per LVDS encoder. The functional clocks must be named "du.x" with "x" - being the channel numerical index. The LVDS clocks must be named - "lvds.x" with "x" being the LVDS encoder numerical index. - - In addition to the functional and encoder clocks, all DU versions also - support externally supplied pixel clocks. Those clocks are optional. - When supplied they must be named "dclkin.x" with "x" being the input - clock numerical index. - -Required nodes: - -The connections to the DU output video ports are modeled using the OF graph -bindings specified in Documentation/devicetree/bindings/graph.txt. - -The following table lists for each supported model the port number -corresponding to each DU output. - - Port 0 Port1 Port2 ------------------------------------------------------------------------------ - R8A7779 (H1) DPAD 0 DPAD 1 - - R8A7790 (H2) DPAD LVDS 0 LVDS 1 - R8A7791 (M2) DPAD LVDS 0 - - - -Example: R8A7790 (R-Car H2) DU - - du: du@feb00000 { - compatible = "renesas,du-r8a7790"; - reg = <0 0xfeb00000 0 0x70000>, - <0 0xfeb90000 0 0x1c>, - <0 0xfeb94000 0 0x1c>; - reg-names = "du", "lvds.0", "lvds.1"; - interrupt-parent = <&gic>; - interrupts = <0 256 IRQ_TYPE_LEVEL_HIGH>, - <0 268 IRQ_TYPE_LEVEL_HIGH>, - <0 269 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&mstp7_clks R8A7790_CLK_DU0>, - <&mstp7_clks R8A7790_CLK_DU1>, - <&mstp7_clks R8A7790_CLK_DU2>, - <&mstp7_clks R8A7790_CLK_LVDS0>, - <&mstp7_clks R8A7790_CLK_LVDS1>; - clock-names = "du.0", "du.1", "du.2", "lvds.0", "lvds.1"; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - du_out_rgb: endpoint { - }; - }; - port@1 { - reg = <1>; - du_out_lvds0: endpoint { - }; - }; - port@2 { - reg = <2>; - du_out_lvds1: endpoint { - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/video/rockchip-drm.txt b/Documentation/devicetree/bindings/video/rockchip-drm.txt deleted file mode 100644 index 7fff58249..000000000 --- a/Documentation/devicetree/bindings/video/rockchip-drm.txt +++ /dev/null @@ -1,19 +0,0 @@ -Rockchip DRM master device -================================ - -The Rockchip DRM master device is a virtual device needed to list all -vop devices or other display interface nodes that comprise the -graphics subsystem. - -Required properties: -- compatible: Should be "rockchip,display-subsystem" -- ports: Should contain a list of phandles pointing to display interface port - of vop devices. vop definitions as defined in - Documentation/devicetree/bindings/video/rockchip-vop.txt - -example: - -display-subsystem { - compatible = "rockchip,display-subsystem"; - ports = <&vopl_out>, <&vopb_out>; -}; diff --git a/Documentation/devicetree/bindings/video/rockchip-vop.txt b/Documentation/devicetree/bindings/video/rockchip-vop.txt deleted file mode 100644 index d15351f23..000000000 --- a/Documentation/devicetree/bindings/video/rockchip-vop.txt +++ /dev/null @@ -1,58 +0,0 @@ -device-tree bindings for rockchip soc display controller (vop) - -VOP (Visual Output Processor) is the Display Controller for the Rockchip -series of SoCs which transfers the image data from a video memory -buffer to an external LCD interface. - -Required properties: -- compatible: value should be one of the following - "rockchip,rk3288-vop"; - -- interrupts: should contain a list of all VOP IP block interrupts in the - order: VSYNC, LCD_SYSTEM. The interrupt specifier - format depends on the interrupt controller used. - -- clocks: must include clock specifiers corresponding to entries in the - clock-names property. - -- clock-names: Must contain - aclk_vop: for ddr buffer transfer. - hclk_vop: for ahb bus to R/W the phy regs. - dclk_vop: pixel clock. - -- resets: Must contain an entry for each entry in reset-names. - See ../reset/reset.txt for details. -- reset-names: Must include the following entries: - - axi - - ahb - - dclk - -- iommus: required a iommu node - -- port: A port node with endpoint definitions as defined in - Documentation/devicetree/bindings/media/video-interfaces.txt. - -Example: -SoC specific DT entry: - vopb: vopb@ff930000 { - compatible = "rockchip,rk3288-vop"; - reg = <0xff930000 0x19c>; - interrupts = ; - clocks = <&cru ACLK_VOP0>, <&cru DCLK_VOP0>, <&cru HCLK_VOP0>; - clock-names = "aclk_vop", "dclk_vop", "hclk_vop"; - resets = <&cru SRST_LCDC1_AXI>, <&cru SRST_LCDC1_AHB>, <&cru SRST_LCDC1_DCLK>; - reset-names = "axi", "ahb", "dclk"; - iommus = <&vopb_mmu>; - vopb_out: port { - #address-cells = <1>; - #size-cells = <0>; - vopb_out_edp: endpoint@0 { - reg = <0>; - remote-endpoint=<&edp_in_vopb>; - }; - vopb_out_hdmi: endpoint@1 { - reg = <1>; - remote-endpoint=<&hdmi_in_vopb>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt b/Documentation/devicetree/bindings/video/samsung-fimd.txt deleted file mode 100644 index a8bbbde03..000000000 --- a/Documentation/devicetree/bindings/video/samsung-fimd.txt +++ /dev/null @@ -1,110 +0,0 @@ -Device-Tree bindings for Samsung SoC display controller (FIMD) - -FIMD (Fully Interactive Mobile Display) is the Display Controller for the -Samsung series of SoCs which transfers the image data from a video memory -buffer to an external LCD interface. - -Required properties: -- compatible: value should be one of the following - "samsung,s3c2443-fimd"; /* for S3C24XX SoCs */ - "samsung,s3c6400-fimd"; /* for S3C64XX SoCs */ - "samsung,s5pv210-fimd"; /* for S5PV210 SoC */ - "samsung,exynos3250-fimd"; /* for Exynos3250/3472 SoCs */ - "samsung,exynos4210-fimd"; /* for Exynos4 SoCs */ - "samsung,exynos4415-fimd"; /* for Exynos4415 SoC */ - "samsung,exynos5250-fimd"; /* for Exynos5 SoCs */ - -- reg: physical base address and length of the FIMD registers set. - -- interrupt-parent: should be the phandle of the fimd controller's - parent interrupt controller. - -- interrupts: should contain a list of all FIMD IP block interrupts in the - order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier - format depends on the interrupt controller used. - -- interrupt-names: should contain the interrupt names: "fifo", "vsync", - "lcd_sys", in the same order as they were listed in the interrupts - property. - -- pinctrl-0: pin control group to be used for this controller. - -- pinctrl-names: must contain a "default" entry. - -- clocks: must include clock specifiers corresponding to entries in the - clock-names property. - -- clock-names: list of clock names sorted in the same order as the clocks - property. Must contain "sclk_fimd" and "fimd". - -Optional Properties: -- power-domains: a phandle to FIMD power domain node. -- samsung,invert-vden: video enable signal is inverted -- samsung,invert-vclk: video clock signal is inverted -- display-timings: timing settings for FIMD, as described in document [1]. - Can be used in case timings cannot be provided otherwise - or to override timings provided by the panel. -- samsung,sysreg: handle to syscon used to control the system registers -- i80-if-timings: timing configuration for lcd i80 interface support. - - cs-setup: clock cycles for the active period of address signal is enabled - until chip select is enabled. - If not specified, the default value(0) will be used. - - wr-setup: clock cycles for the active period of CS signal is enabled until - write signal is enabled. - If not specified, the default value(0) will be used. - - wr-active: clock cycles for the active period of CS is enabled. - If not specified, the default value(1) will be used. - - wr-hold: clock cycles for the active period of CS is disabled until write - signal is disabled. - If not specified, the default value(0) will be used. - - The parameters are defined as: - - VCLK(internal) __|??????|_____|??????|_____|??????|_____|??????|_____|?? - : : : : : - Address Output --:| : : : - Chip Select ???????????????|____________:____________:____________|?? - | wr-setup+1 | | wr-hold+1 | - |<---------->| |<---------->| - Write Enable ????????????????????????????|____________|??????????????? - | wr-active+1| - |<---------->| - Video Data ------------------------------ - -The device node can contain 'port' child nodes according to the bindings defined -in [2]. The following are properties specific to those nodes: -- reg: (required) port index, can be: - 0 - for CAMIF0 input, - 1 - for CAMIF1 input, - 2 - for CAMIF2 input, - 3 - for parallel output, - 4 - for write-back interface - -[1]: Documentation/devicetree/bindings/video/display-timing.txt -[2]: Documentation/devicetree/bindings/media/video-interfaces.txt - -Example: - -SoC specific DT entry: - - fimd@11c00000 { - compatible = "samsung,exynos4210-fimd"; - interrupt-parent = <&combiner>; - reg = <0x11c00000 0x20000>; - interrupt-names = "fifo", "vsync", "lcd_sys"; - interrupts = <11 0>, <11 1>, <11 2>; - clocks = <&clock 140>, <&clock 283>; - clock-names = "sclk_fimd", "fimd"; - power-domains = <&pd_lcd0>; - status = "disabled"; - }; - -Board specific DT entry: - - fimd@11c00000 { - pinctrl-0 = <&lcd_clk &lcd_data24 &pwm1_out>; - pinctrl-names = "default"; - status = "okay"; - }; diff --git a/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt b/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt deleted file mode 100644 index 0cc8981e9..000000000 --- a/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt +++ /dev/null @@ -1,43 +0,0 @@ -SHARP LS037V7DW01 TFT-LCD panel -=================================== - -Required properties: -- compatible: "sharp,ls037v7dw01" - -Optional properties: -- label: a symbolic name for the panel -- enable-gpios: a GPIO spec for the optional enable pin. - This pin is the INI pin as specified in the LS037V7DW01.pdf file. -- reset-gpios: a GPIO spec for the optional reset pin. - This pin is the RESB pin as specified in the LS037V7DW01.pdf file. -- mode-gpios: a GPIO - ordered MO, LR, and UD as specified in the LS037V7DW01.pdf file. - -Required nodes: -- Video port for DPI input - -This panel can have zero to five GPIOs to configure to change configuration -between QVGA and VGA mode and the scan direction. As these pins can be also -configured with external pulls, all the GPIOs are considered optional with holes -in the array. - -Example -------- - -Example when connected to a omap2+ based device: - -lcd0: display { - compatible = "sharp,ls037v7dw01"; - power-supply = <&lcd_3v3>; - enable-gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>; /* gpio152, lcd INI */ - reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd RESB */ - mode-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH /* gpio154, lcd MO */ - &gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */ - &gpio1 3 GPIO_ACTIVE_HIGH>; /* gpio3, lcd UD */ - - port { - lcd_in: endpoint { - remote-endpoint = <&dpi_out>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt b/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt deleted file mode 100644 index c46ba641a..000000000 --- a/Documentation/devicetree/bindings/video/simple-framebuffer-sunxi.txt +++ /dev/null @@ -1,33 +0,0 @@ -Sunxi specific Simple Framebuffer bindings - -This binding documents sunxi specific extensions to the simple-framebuffer -bindings. The sunxi simplefb u-boot code relies on the devicetree containing -pre-populated simplefb nodes. - -These extensions are intended so that u-boot can select the right node based -on which pipeline is being used. As such they are solely intended for -firmware / bootloader use, and the OS should ignore them. - -Required properties: -- compatible: "allwinner,simple-framebuffer" -- allwinner,pipeline, one of: - "de_be0-lcd0" - "de_be1-lcd1" - "de_be0-lcd0-hdmi" - "de_be1-lcd1-hdmi" - -Example: - -chosen { - #address-cells = <1>; - #size-cells = <1>; - ranges; - - framebuffer@0 { - compatible = "allwinner,simple-framebuffer", "simple-framebuffer"; - allwinner,pipeline = "de_be0-lcd0-hdmi"; - clocks = <&pll5 1>, <&ahb_gates 36>, <&ahb_gates 43>, - <&ahb_gates 44>; - status = "disabled"; - }; -}; diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt deleted file mode 100644 index 4474ef6e0..000000000 --- a/Documentation/devicetree/bindings/video/simple-framebuffer.txt +++ /dev/null @@ -1,86 +0,0 @@ -Simple Framebuffer - -A simple frame-buffer describes a frame-buffer setup by firmware or -the bootloader, with the assumption that the display hardware has already -been set up to scan out from the memory pointed to by the reg property. - -Since simplefb nodes represent runtime information they must be sub-nodes of -the chosen node (*). Simplefb nodes must be named "framebuffer@

". - -If the devicetree contains nodes for the display hardware used by a simplefb, -then the simplefb node must contain a property called "display", which -contains a phandle pointing to the primary display hw node, so that the OS -knows which simplefb to disable when handing over control to a driver for the -real hardware. The bindings for the hw nodes must specify which node is -considered the primary node. - -It is advised to add display# aliases to help the OS determine how to number -things. If display# aliases are used, then if the simplefb node contains a -"display" property then the /aliases/display# path must point to the display -hw node the "display" property points to, otherwise it must point directly -to the simplefb node. - -If a simplefb node represents the preferred console for user interaction, -then the chosen node's stdout-path property should point to it, or to the -primary display hw node, as with display# aliases. If display aliases are -used then it should be set to the alias instead. - -It is advised that devicetree files contain pre-filled, disabled framebuffer -nodes, so that the firmware only needs to update the mode information and -enable them. This way if e.g. later on support for more display clocks get -added, the simplefb nodes will already contain this info and the firmware -does not need to be updated. - -If pre-filled framebuffer nodes are used, the firmware may need extra -information to find the right node. In that case an extra platform specific -compatible and platform specific properties should be used and documented, -see e.g. simple-framebuffer-sunxi.txt . - -Required properties: -- compatible: "simple-framebuffer" -- reg: Should contain the location and size of the framebuffer memory. -- width: The width of the framebuffer in pixels. -- height: The height of the framebuffer in pixels. -- stride: The number of bytes in each line of the framebuffer. -- format: The format of the framebuffer surface. Valid values are: - - r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b). - - a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r). - -Optional properties: -- clocks : List of clocks used by the framebuffer. Clocks listed here - are expected to already be configured correctly. The OS must - ensure these clocks are not modified or disabled while the - simple framebuffer remains active. -- display : phandle pointing to the primary display hardware node - -Example: - -aliases { - display0 = &lcdc0; -} - -chosen { - framebuffer0: framebuffer@1d385000 { - compatible = "simple-framebuffer"; - reg = <0x1d385000 (1600 * 1200 * 2)>; - width = <1600>; - height = <1200>; - stride = <(1600 * 2)>; - format = "r5g6b5"; - clocks = <&ahb_gates 36>, <&ahb_gates 43>, <&ahb_gates 44>; - display = <&lcdc0>; - }; - stdout-path = "display0"; -}; - -soc@01c00000 { - lcdc0: lcdc@1c0c000 { - compatible = "allwinner,sun4i-a10-lcdc"; - ... - }; -}; - - -*) Older devicetree files may have a compatible = "simple-framebuffer" node -in a different place, operating systems must first enumerate any compatible -nodes found under chosen and then check for other compatible nodes. diff --git a/Documentation/devicetree/bindings/video/sony,acx565akm.txt b/Documentation/devicetree/bindings/video/sony,acx565akm.txt deleted file mode 100644 index e12333280..000000000 --- a/Documentation/devicetree/bindings/video/sony,acx565akm.txt +++ /dev/null @@ -1,30 +0,0 @@ -Sony ACX565AKM SDI Panel -======================== - -Required properties: -- compatible: "sony,acx565akm" - -Optional properties: -- label: a symbolic name for the panel -- reset-gpios: panel reset gpio - -Required nodes: -- Video port for SDI input - -Example -------- - -acx565akm@2 { - compatible = "sony,acx565akm"; - spi-max-frequency = <6000000>; - reg = <2>; - - label = "lcd"; - reset-gpios = <&gpio3 26 GPIO_ACTIVE_HIGH>; /* 90 */ - - port { - lcd_in: endpoint { - remote-endpoint = <&sdi_out>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/video/ssd1289fb.txt b/Documentation/devicetree/bindings/video/ssd1289fb.txt deleted file mode 100644 index 4fcd5e68c..000000000 --- a/Documentation/devicetree/bindings/video/ssd1289fb.txt +++ /dev/null @@ -1,13 +0,0 @@ -* Solomon SSD1289 Framebuffer Driver - -Required properties: - - compatible: Should be "solomon,ssd1289fb". The only supported bus for - now is lbc. - - reg: Should contain address of the controller on the LBC bus. The detail - was described in Documentation/devicetree/bindings/powerpc/fsl/lbc.txt - -Examples: -display@2,0 { - compatible = "solomon,ssd1289fb"; - reg = <0x2 0x0000 0x0004>; -}; diff --git a/Documentation/devicetree/bindings/video/ssd1307fb.txt b/Documentation/devicetree/bindings/video/ssd1307fb.txt deleted file mode 100644 index d1be78db6..000000000 --- a/Documentation/devicetree/bindings/video/ssd1307fb.txt +++ /dev/null @@ -1,49 +0,0 @@ -* Solomon SSD1307 Framebuffer Driver - -Required properties: - - compatible: Should be "solomon,fb-". The only supported bus for - now is i2c, and the supported chips are ssd1305, ssd1306 and ssd1307. - - reg: Should contain address of the controller on the I2C bus. Most likely - 0x3c or 0x3d - - pwm: Should contain the pwm to use according to the OF device tree PWM - specification [0]. Only required for the ssd1307. - - reset-gpios: Should contain the GPIO used to reset the OLED display - - solomon,height: Height in pixel of the screen driven by the controller - - solomon,width: Width in pixel of the screen driven by the controller - - solomon,page-offset: Offset of pages (band of 8 pixels) that the screen is - mapped to. - -Optional properties: - - reset-active-low: Is the reset gpio is active on physical low? - - solomon,segment-no-remap: Display needs normal (non-inverted) data column - to segment mapping - - solomon,com-seq: Display uses sequential COM pin configuration - - solomon,com-lrremap: Display uses left-right COM pin remap - - solomon,com-invdir: Display uses inverted COM pin scan direction - - solomon,com-offset: Number of the COM pin wired to the first display line - - solomon,prechargep1: Length of deselect period (phase 1) in clock cycles. - - solomon,prechargep2: Length of precharge period (phase 2) in clock cycles. - This needs to be the higher, the higher the capacitance - of the OLED's pixels is - -[0]: Documentation/devicetree/bindings/pwm/pwm.txt - -Examples: -ssd1307: oled@3c { - compatible = "solomon,ssd1307fb-i2c"; - reg = <0x3c>; - pwms = <&pwm 4 3000>; - reset-gpios = <&gpio2 7>; - reset-active-low; -}; - -ssd1306: oled@3c { - compatible = "solomon,ssd1306fb-i2c"; - reg = <0x3c>; - pwms = <&pwm 4 3000>; - reset-gpios = <&gpio2 7>; - reset-active-low; - solomon,com-lrremap; - solomon,com-invdir; - solomon,com-offset = <32>; -}; diff --git a/Documentation/devicetree/bindings/video/thine,thc63lvdm83d b/Documentation/devicetree/bindings/video/thine,thc63lvdm83d deleted file mode 100644 index 527e236e9..000000000 --- a/Documentation/devicetree/bindings/video/thine,thc63lvdm83d +++ /dev/null @@ -1,50 +0,0 @@ -THine Electronics THC63LVDM83D LVDS serializer ----------------------------------------------- - -The THC63LVDM83D is an LVDS serializer designed to support pixel data -transmission between a host and a flat panel. - -Required properties: - -- compatible: Should be "thine,thc63lvdm83d" - -Optional properties: - -- pwdn-gpios: Power down control GPIO - -Required nodes: - -The THC63LVDM83D has two video ports. Their connections are modeled using the -OFgraph bindings specified in Documentation/devicetree/bindings/graph.txt. - -- Video port 0 for CMOS/TTL input -- Video port 1 for LVDS output - - -Example -------- - - lvds_enc: encoder@0 { - compatible = "thine,thc63lvdm83d"; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - - lvds_enc_in: endpoint@0 { - remote-endpoint = <&rgb_out>; - }; - }; - - port@1 { - reg = <1>; - - lvds_enc_out: endpoint@0 { - remote-endpoint = <&panel_in>; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/video/ti,dra7-dss.txt b/Documentation/devicetree/bindings/video/ti,dra7-dss.txt deleted file mode 100644 index f33a05137..000000000 --- a/Documentation/devicetree/bindings/video/ti,dra7-dss.txt +++ /dev/null @@ -1,69 +0,0 @@ -Texas Instruments DRA7x Display Subsystem -========================================= - -See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic -description about OMAP Display Subsystem bindings. - -DSS Core --------- - -Required properties: -- compatible: "ti,dra7-dss" -- reg: address and length of the register spaces for 'dss' -- ti,hwmods: "dss_core" -- clocks: handle to fclk -- clock-names: "fck" -- syscon: phandle to control module core syscon node - -Optional properties: - -Some DRA7xx SoCs have one dedicated video PLL, some have two. These properties -can be used to describe the video PLLs: - -- reg: address and length of the register spaces for 'pll1_clkctrl', - 'pll1', 'pll2_clkctrl', 'pll2' -- clocks: handle to video1 pll clock and video2 pll clock -- clock-names: "video1_clk" and "video2_clk" - -Required nodes: -- DISPC - -Optional nodes: -- DSS Submodules: HDMI -- Video port for DPI output - -DPI Endpoint required properties: -- data-lines: number of lines used - - -DISPC ------ - -Required properties: -- compatible: "ti,dra7-dispc" -- reg: address and length of the register space -- ti,hwmods: "dss_dispc" -- interrupts: the DISPC interrupt -- clocks: handle to fclk -- clock-names: "fck" - -HDMI ----- - -Required properties: -- compatible: "ti,dra7-hdmi" -- reg: addresses and lengths of the register spaces for 'wp', 'pll', 'phy', - 'core' -- reg-names: "wp", "pll", "phy", "core" -- interrupts: the HDMI interrupt line -- ti,hwmods: "dss_hdmi" -- vdda-supply: vdda power supply -- clocks: handles to fclk and pll clock -- clock-names: "fck", "sys_clk" - -Optional nodes: -- Video port for HDMI output - -HDMI Endpoint optional properties: -- lanes: list of 8 pin numbers for the HDMI lanes: CLK+, CLK-, D0+, D0-, - D1+, D1-, D2+, D2-. (default: 0,1,2,3,4,5,6,7) diff --git a/Documentation/devicetree/bindings/video/ti,omap-dss.txt b/Documentation/devicetree/bindings/video/ti,omap-dss.txt deleted file mode 100644 index e1ef29569..000000000 --- a/Documentation/devicetree/bindings/video/ti,omap-dss.txt +++ /dev/null @@ -1,211 +0,0 @@ -Texas Instruments OMAP Display Subsystem -======================================== - -Generic Description -------------------- - -This document is a generic description of the OMAP Display Subsystem bindings. -Binding details for each OMAP SoC version are described in respective binding -documentation. - -The OMAP Display Subsystem (DSS) hardware consists of DSS Core, DISPC module and -a number of encoder modules. All DSS versions contain DSS Core and DISPC, but -the encoder modules vary. - -The DSS Core is the parent of the other DSS modules, and manages clock routing, -integration to the SoC, etc. - -DISPC is the display controller, which reads pixels from the memory and outputs -a RGB pixel stream to encoders. - -The encoder modules encode the received RGB pixel stream to a video output like -HDMI, MIPI DPI, etc. - -Video Ports ------------ - -The DSS Core and the encoders have video port outputs. The structure of the -video ports is described in Documentation/devicetree/bindings/graph.txt, -and the properties for the ports and endpoints for each encoder are -described in the SoC's DSS binding documentation. - -The video ports are used to describe the connections to external hardware, like -panels or external encoders. - -Aliases -------- - -The board dts file may define aliases for displays to assign "displayX" style -name for each display. If no aliases are defined, a semi-random number is used -for the display. - -Example -------- - -A shortened example of the DSS description for OMAP4, with non-relevant parts -removed, defined in omap4.dtsi: - -dss: dss@58000000 { - compatible = "ti,omap4-dss"; - reg = <0x58000000 0x80>; - status = "disabled"; - ti,hwmods = "dss_core"; - clocks = <&dss_dss_clk>; - clock-names = "fck"; - #address-cells = <1>; - #size-cells = <1>; - ranges; - - dispc@58001000 { - compatible = "ti,omap4-dispc"; - reg = <0x58001000 0x1000>; - interrupts = ; - ti,hwmods = "dss_dispc"; - clocks = <&dss_dss_clk>; - clock-names = "fck"; - }; - - hdmi: encoder@58006000 { - compatible = "ti,omap4-hdmi"; - reg = <0x58006000 0x200>, - <0x58006200 0x100>, - <0x58006300 0x100>, - <0x58006400 0x1000>; - reg-names = "wp", "pll", "phy", "core"; - interrupts = ; - status = "disabled"; - ti,hwmods = "dss_hdmi"; - clocks = <&dss_48mhz_clk>, <&dss_sys_clk>; - clock-names = "fck", "sys_clk"; - }; -}; - -A shortened example of the board description for OMAP4 Panda board, defined in -omap4-panda.dts. - -The Panda board has a DVI and a HDMI connector, and the board contains a TFP410 -chip (MIPI DPI to DVI encoder) and a TPD12S015 chip (HDMI ESD protection & level -shifter). The video pipelines for the connectors are formed as follows: - -DSS Core --(MIPI DPI)--> TFP410 --(DVI)--> DVI Connector -OMAP HDMI --(HDMI)--> TPD12S015 --(HDMI)--> HDMI Connector - -/ { - aliases { - display0 = &dvi0; - display1 = &hdmi0; - }; - - tfp410: encoder@0 { - compatible = "ti,tfp410"; - gpios = <&gpio1 0 GPIO_ACTIVE_LOW>; /* 0, power-down */ - - pinctrl-names = "default"; - pinctrl-0 = <&tfp410_pins>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - - tfp410_in: endpoint@0 { - remote-endpoint = <&dpi_out>; - }; - }; - - port@1 { - reg = <1>; - - tfp410_out: endpoint@0 { - remote-endpoint = <&dvi_connector_in>; - }; - }; - }; - }; - - dvi0: connector@0 { - compatible = "dvi-connector"; - label = "dvi"; - - i2c-bus = <&i2c3>; - - port { - dvi_connector_in: endpoint { - remote-endpoint = <&tfp410_out>; - }; - }; - }; - - tpd12s015: encoder@1 { - compatible = "ti,tpd12s015"; - - pinctrl-names = "default"; - pinctrl-0 = <&tpd12s015_pins>; - - gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>, /* 60, CT CP HPD */ - <&gpio2 9 GPIO_ACTIVE_HIGH>, /* 41, LS OE */ - <&gpio2 31 GPIO_ACTIVE_HIGH>; /* 63, HPD */ - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - - tpd12s015_in: endpoint@0 { - remote-endpoint = <&hdmi_out>; - }; - }; - - port@1 { - reg = <1>; - - tpd12s015_out: endpoint@0 { - remote-endpoint = <&hdmi_connector_in>; - }; - }; - }; - }; - - hdmi0: connector@1 { - compatible = "hdmi-connector"; - label = "hdmi"; - - port { - hdmi_connector_in: endpoint { - remote-endpoint = <&tpd12s015_out>; - }; - }; - }; -}; - -&dss { - status = "ok"; - - pinctrl-names = "default"; - pinctrl-0 = <&dss_dpi_pins>; - - port { - dpi_out: endpoint { - remote-endpoint = <&tfp410_in>; - data-lines = <24>; - }; - }; -}; - -&hdmi { - status = "ok"; - vdda-supply = <&vdac>; - - pinctrl-names = "default"; - pinctrl-0 = <&dss_hdmi_pins>; - - port { - hdmi_out: endpoint { - remote-endpoint = <&tpd12s015_in>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/video/ti,omap2-dss.txt b/Documentation/devicetree/bindings/video/ti,omap2-dss.txt deleted file mode 100644 index fa8bb2ed1..000000000 --- a/Documentation/devicetree/bindings/video/ti,omap2-dss.txt +++ /dev/null @@ -1,54 +0,0 @@ -Texas Instruments OMAP2 Display Subsystem -========================================= - -See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic -description about OMAP Display Subsystem bindings. - -DSS Core --------- - -Required properties: -- compatible: "ti,omap2-dss" -- reg: address and length of the register space -- ti,hwmods: "dss_core" - -Optional nodes: -- Video port for DPI output - -DPI Endpoint required properties: -- data-lines: number of lines used - - -DISPC ------ - -Required properties: -- compatible: "ti,omap2-dispc" -- reg: address and length of the register space -- ti,hwmods: "dss_dispc" -- interrupts: the DISPC interrupt - - -RFBI ----- - -Required properties: -- compatible: "ti,omap2-rfbi" -- reg: address and length of the register space -- ti,hwmods: "dss_rfbi" - - -VENC ----- - -Required properties: -- compatible: "ti,omap2-venc" -- reg: address and length of the register space -- ti,hwmods: "dss_venc" -- vdda-supply: power supply for DAC - -VENC Endpoint required properties: - -Required properties: -- ti,invert-polarity: invert the polarity of the video signal -- ti,channels: 1 for composite, 2 for s-video diff --git a/Documentation/devicetree/bindings/video/ti,omap3-dss.txt b/Documentation/devicetree/bindings/video/ti,omap3-dss.txt deleted file mode 100644 index 0023fa4b1..000000000 --- a/Documentation/devicetree/bindings/video/ti,omap3-dss.txt +++ /dev/null @@ -1,83 +0,0 @@ -Texas Instruments OMAP3 Display Subsystem -========================================= - -See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic -description about OMAP Display Subsystem bindings. - -DSS Core --------- - -Required properties: -- compatible: "ti,omap3-dss" -- reg: address and length of the register space -- ti,hwmods: "dss_core" -- clocks: handle to fclk -- clock-names: "fck" - -Optional nodes: -- Video ports: - - Port 0: DPI output - - Port 1: SDI output - -DPI Endpoint required properties: -- data-lines: number of lines used - -SDI Endpoint required properties: -- datapairs: number of datapairs used - - -DISPC ------ - -Required properties: -- compatible: "ti,omap3-dispc" -- reg: address and length of the register space -- ti,hwmods: "dss_dispc" -- interrupts: the DISPC interrupt -- clocks: handle to fclk -- clock-names: "fck" - - -RFBI ----- - -Required properties: -- compatible: "ti,omap3-rfbi" -- reg: address and length of the register space -- ti,hwmods: "dss_rfbi" -- clocks: handles to fclk and iclk -- clock-names: "fck", "ick" - - -VENC ----- - -Required properties: -- compatible: "ti,omap3-venc" -- reg: address and length of the register space -- ti,hwmods: "dss_venc" -- vdda-supply: power supply for DAC -- clocks: handle to fclk -- clock-names: "fck" - -VENC Endpoint required properties: -- ti,invert-polarity: invert the polarity of the video signal -- ti,channels: 1 for composite, 2 for s-video - - -DSI ---- - -Required properties: -- compatible: "ti,omap3-dsi" -- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll' -- reg-names: "proto", "phy", "pll" -- interrupts: the DSI interrupt line -- ti,hwmods: "dss_dsi1" -- vdd-supply: power supply for DSI -- clocks: handles to fclk and pll clock -- clock-names: "fck", "sys_clk" - -DSI Endpoint required properties: -- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-, - DATA1+, DATA1-, ... diff --git a/Documentation/devicetree/bindings/video/ti,omap4-dss.txt b/Documentation/devicetree/bindings/video/ti,omap4-dss.txt deleted file mode 100644 index b8c29fbd1..000000000 --- a/Documentation/devicetree/bindings/video/ti,omap4-dss.txt +++ /dev/null @@ -1,115 +0,0 @@ -Texas Instruments OMAP4 Display Subsystem -========================================= - -See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic -description about OMAP Display Subsystem bindings. - -DSS Core --------- - -Required properties: -- compatible: "ti,omap4-dss" -- reg: address and length of the register space -- ti,hwmods: "dss_core" -- clocks: handle to fclk -- clock-names: "fck" - -Required nodes: -- DISPC - -Optional nodes: -- DSS Submodules: RFBI, VENC, DSI, HDMI -- Video port for DPI output - -DPI Endpoint required properties: -- data-lines: number of lines used - - -DISPC ------ - -Required properties: -- compatible: "ti,omap4-dispc" -- reg: address and length of the register space -- ti,hwmods: "dss_dispc" -- interrupts: the DISPC interrupt -- clocks: handle to fclk -- clock-names: "fck" - - -RFBI ----- - -Required properties: -- compatible: "ti,omap4-rfbi" -- reg: address and length of the register space -- ti,hwmods: "dss_rfbi" -- clocks: handles to fclk and iclk -- clock-names: "fck", "ick" - -Optional nodes: -- Video port for RFBI output -- RFBI controlled peripherals - - -VENC ----- - -Required properties: -- compatible: "ti,omap4-venc" -- reg: address and length of the register space -- ti,hwmods: "dss_venc" -- vdda-supply: power supply for DAC -- clocks: handle to fclk -- clock-names: "fck" - -Optional nodes: -- Video port for VENC output - -VENC Endpoint required properties: -- ti,invert-polarity: invert the polarity of the video signal -- ti,channels: 1 for composite, 2 for s-video - - -DSI ---- - -Required properties: -- compatible: "ti,omap4-dsi" -- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll' -- reg-names: "proto", "phy", "pll" -- interrupts: the DSI interrupt line -- ti,hwmods: "dss_dsi1" or "dss_dsi2" -- vdd-supply: power supply for DSI -- clocks: handles to fclk and pll clock -- clock-names: "fck", "sys_clk" - -Optional nodes: -- Video port for DSI output -- DSI controlled peripherals - -DSI Endpoint required properties: -- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-, - DATA1+, DATA1-, ... - - -HDMI ----- - -Required properties: -- compatible: "ti,omap4-hdmi" -- reg: addresses and lengths of the register spaces for 'wp', 'pll', 'phy', - 'core' -- reg-names: "wp", "pll", "phy", "core" -- interrupts: the HDMI interrupt line -- ti,hwmods: "dss_hdmi" -- vdda-supply: vdda power supply -- clocks: handles to fclk and pll clock -- clock-names: "fck", "sys_clk" - -Optional nodes: -- Video port for HDMI output - -HDMI Endpoint optional properties: -- lanes: list of 8 pin numbers for the HDMI lanes: CLK+, CLK-, D0+, D0-, - D1+, D1-, D2+, D2-. (default: 0,1,2,3,4,5,6,7) diff --git a/Documentation/devicetree/bindings/video/ti,omap5-dss.txt b/Documentation/devicetree/bindings/video/ti,omap5-dss.txt deleted file mode 100644 index 38ffc8fcd..000000000 --- a/Documentation/devicetree/bindings/video/ti,omap5-dss.txt +++ /dev/null @@ -1,96 +0,0 @@ -Texas Instruments OMAP5 Display Subsystem -========================================= - -See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic -description about OMAP Display Subsystem bindings. - -DSS Core --------- - -Required properties: -- compatible: "ti,omap5-dss" -- reg: address and length of the register space -- ti,hwmods: "dss_core" -- clocks: handle to fclk -- clock-names: "fck" - -Required nodes: -- DISPC - -Optional nodes: -- DSS Submodules: RFBI, DSI, HDMI -- Video port for DPI output - -DPI Endpoint required properties: -- data-lines: number of lines used - - -DISPC ------ - -Required properties: -- compatible: "ti,omap5-dispc" -- reg: address and length of the register space -- ti,hwmods: "dss_dispc" -- interrupts: the DISPC interrupt -- clocks: handle to fclk -- clock-names: "fck" - - -RFBI ----- - -Required properties: -- compatible: "ti,omap5-rfbi" -- reg: address and length of the register space -- ti,hwmods: "dss_rfbi" -- clocks: handles to fclk and iclk -- clock-names: "fck", "ick" - -Optional nodes: -- Video port for RFBI output -- RFBI controlled peripherals - - -DSI ---- - -Required properties: -- compatible: "ti,omap5-dsi" -- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll' -- reg-names: "proto", "phy", "pll" -- interrupts: the DSI interrupt line -- ti,hwmods: "dss_dsi1" or "dss_dsi2" -- vdd-supply: power supply for DSI -- clocks: handles to fclk and pll clock -- clock-names: "fck", "sys_clk" - -Optional nodes: -- Video port for DSI output -- DSI controlled peripherals - -DSI Endpoint required properties: -- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-, - DATA1+, DATA1-, ... - - -HDMI ----- - -Required properties: -- compatible: "ti,omap5-hdmi" -- reg: addresses and lengths of the register spaces for 'wp', 'pll', 'phy', - 'core' -- reg-names: "wp", "pll", "phy", "core" -- interrupts: the HDMI interrupt line -- ti,hwmods: "dss_hdmi" -- vdda-supply: vdda power supply -- clocks: handles to fclk and pll clock -- clock-names: "fck", "sys_clk" - -Optional nodes: -- Video port for HDMI output - -HDMI Endpoint optional properties: -- lanes: list of 8 pin numbers for the HDMI lanes: CLK+, CLK-, D0+, D0-, - D1+, D1-, D2+, D2-. (default: 0,1,2,3,4,5,6,7) diff --git a/Documentation/devicetree/bindings/video/ti,opa362.txt b/Documentation/devicetree/bindings/video/ti,opa362.txt deleted file mode 100644 index f96083c0b..000000000 --- a/Documentation/devicetree/bindings/video/ti,opa362.txt +++ /dev/null @@ -1,38 +0,0 @@ -OPA362 analog video amplifier - -Required properties: -- compatible: "ti,opa362" -- enable-gpios: enable/disable output gpio - -Required node: -- Video port 0 for opa362 input -- Video port 1 for opa362 output - -Example: - -tv_amp: opa362 { - compatible = "ti,opa362"; - enable-gpios = <&gpio1 23 0>; /* GPIO to enable video out amplifier */ - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - opa_in: endpoint@0 { - remote-endpoint = <&venc_out>; - }; - }; - - port@1 { - reg = <1>; - opa_out: endpoint@0 { - remote-endpoint = <&tv_connector_in>; - }; - }; - }; -}; - - - diff --git a/Documentation/devicetree/bindings/video/ti,tfp410.txt b/Documentation/devicetree/bindings/video/ti,tfp410.txt deleted file mode 100644 index 2cbe32a3d..000000000 --- a/Documentation/devicetree/bindings/video/ti,tfp410.txt +++ /dev/null @@ -1,41 +0,0 @@ -TFP410 DPI to DVI encoder -========================= - -Required properties: -- compatible: "ti,tfp410" - -Optional properties: -- powerdown-gpios: power-down gpio - -Required nodes: -- Video port 0 for DPI input -- Video port 1 for DVI output - -Example -------- - -tfp410: encoder@0 { - compatible = "ti,tfp410"; - powerdown-gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - - tfp410_in: endpoint@0 { - remote-endpoint = <&dpi_out>; - }; - }; - - port@1 { - reg = <1>; - - tfp410_out: endpoint@0 { - remote-endpoint = <&dvi_connector_in>; - }; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/video/ti,tpd12s015.txt b/Documentation/devicetree/bindings/video/ti,tpd12s015.txt deleted file mode 100644 index 26e6d32e3..000000000 --- a/Documentation/devicetree/bindings/video/ti,tpd12s015.txt +++ /dev/null @@ -1,44 +0,0 @@ -TPD12S015 HDMI level shifter and ESD protection chip -==================================================== - -Required properties: -- compatible: "ti,tpd12s015" - -Optional properties: -- gpios: CT CP HPD, LS OE and HPD gpios - -Required nodes: -- Video port 0 for HDMI input -- Video port 1 for HDMI output - -Example -------- - -tpd12s015: encoder@1 { - compatible = "ti,tpd12s015"; - - gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>, /* 60, CT CP HPD */ - <&gpio2 9 GPIO_ACTIVE_HIGH>, /* 41, LS OE */ - <&gpio2 31 GPIO_ACTIVE_HIGH>; /* 63, HPD */ - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - - tpd12s015_in: endpoint@0 { - remote-endpoint = <&hdmi_out>; - }; - }; - - port@1 { - reg = <1>; - - tpd12s015_out: endpoint@0 { - remote-endpoint = <&hdmi_connector_in>; - }; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/video/toppoly,td028ttec1.txt b/Documentation/devicetree/bindings/video/toppoly,td028ttec1.txt deleted file mode 100644 index 7175dc374..000000000 --- a/Documentation/devicetree/bindings/video/toppoly,td028ttec1.txt +++ /dev/null @@ -1,30 +0,0 @@ -Toppoly TD028TTEC1 Panel -======================== - -Required properties: -- compatible: "toppoly,td028ttec1" - -Optional properties: -- label: a symbolic name for the panel - -Required nodes: -- Video port for DPI input - -Example -------- - -lcd-panel: td028ttec1@0 { - compatible = "toppoly,td028ttec1"; - reg = <0>; - spi-max-frequency = <100000>; - spi-cpol; - spi-cpha; - - label = "lcd"; - port { - lcd_in: endpoint { - remote-endpoint = <&dpi_out>; - }; - }; -}; - diff --git a/Documentation/devicetree/bindings/video/tpo,td043mtea1.txt b/Documentation/devicetree/bindings/video/tpo,td043mtea1.txt deleted file mode 100644 index ec6d62975..000000000 --- a/Documentation/devicetree/bindings/video/tpo,td043mtea1.txt +++ /dev/null @@ -1,33 +0,0 @@ -TPO TD043MTEA1 Panel -==================== - -Required properties: -- compatible: "tpo,td043mtea1" -- reset-gpios: panel reset gpio - -Optional properties: -- label: a symbolic name for the panel - -Required nodes: -- Video port for DPI input - -Example -------- - -lcd-panel: panel@0 { - compatible = "tpo,td043mtea1"; - reg = <0>; - spi-max-frequency = <100000>; - spi-cpol; - spi-cpha; - - label = "lcd"; - - reset-gpios = <&gpio7 7 0>; - - port { - lcd_in: endpoint { - remote-endpoint = <&dpi_out>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/video/vga-connector.txt b/Documentation/devicetree/bindings/video/vga-connector.txt deleted file mode 100644 index c727f298e..000000000 --- a/Documentation/devicetree/bindings/video/vga-connector.txt +++ /dev/null @@ -1,36 +0,0 @@ -VGA Connector -============= - -Required properties: - -- compatible: "vga-connector" - -Optional properties: - -- label: a symbolic name for the connector corresponding to a hardware label -- ddc-i2c-bus: phandle to the I2C bus that is connected to VGA DDC - -Required nodes: - -The VGA connector internal connections are modeled using the OF graph bindings -specified in Documentation/devicetree/bindings/graph.txt. - -The VGA connector has a single port that must be connected to a video source -port. - - -Example -------- - -vga0: connector@0 { - compatible = "vga-connector"; - label = "vga"; - - ddc-i2c-bus = <&i2c3>; - - port { - vga_connector_in: endpoint { - remote-endpoint = <&adv7123_out>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/video/via,vt8500-fb.txt b/Documentation/devicetree/bindings/video/via,vt8500-fb.txt deleted file mode 100644 index 2871e218a..000000000 --- a/Documentation/devicetree/bindings/video/via,vt8500-fb.txt +++ /dev/null @@ -1,36 +0,0 @@ -VIA VT8500 Framebuffer ------------------------------------------------------ - -Required properties: -- compatible : "via,vt8500-fb" -- reg : Should contain 1 register ranges(address and length) -- interrupts : framebuffer controller interrupt -- bits-per-pixel : bit depth of framebuffer (16 or 32) - -Required subnodes: -- display-timings: see display-timing.txt for information - -Example: - - fb@d8050800 { - compatible = "via,vt8500-fb"; - reg = <0xd800e400 0x400>; - interrupts = <12>; - bits-per-pixel = <16>; - - display-timings { - native-mode = <&timing0>; - timing0: 800x480 { - clock-frequency = <0>; /* unused but required */ - hactive = <800>; - vactive = <480>; - hfront-porch = <40>; - hback-porch = <88>; - hsync-len = <0>; - vback-porch = <32>; - vfront-porch = <11>; - vsync-len = <1>; - }; - }; - }; - diff --git a/Documentation/devicetree/bindings/video/wm,prizm-ge-rops.txt b/Documentation/devicetree/bindings/video/wm,prizm-ge-rops.txt deleted file mode 100644 index a850fa011..000000000 --- a/Documentation/devicetree/bindings/video/wm,prizm-ge-rops.txt +++ /dev/null @@ -1,13 +0,0 @@ -VIA/Wondermedia Graphics Engine Controller ------------------------------------------------------ - -Required properties: -- compatible : "wm,prizm-ge-rops" -- reg : Should contain 1 register ranges(address and length) - -Example: - - ge_rops@d8050400 { - compatible = "wm,prizm-ge-rops"; - reg = <0xd8050400 0x100>; - }; diff --git a/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt b/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt deleted file mode 100644 index 0bcadb284..000000000 --- a/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt +++ /dev/null @@ -1,33 +0,0 @@ -Wondermedia WM8505 Framebuffer ------------------------------------------------------ - -Required properties: -- compatible : "wm,wm8505-fb" -- reg : Should contain 1 register ranges(address and length) -- bits-per-pixel : bit depth of framebuffer (16 or 32) - -Required subnodes: -- display-timings: see display-timing.txt for information - -Example: - - fb@d8051700 { - compatible = "wm,wm8505-fb"; - reg = <0xd8051700 0x200>; - bits-per-pixel = <16>; - - display-timings { - native-mode = <&timing0>; - timing0: 800x480 { - clock-frequency = <0>; /* unused but required */ - hactive = <800>; - vactive = <480>; - hfront-porch = <40>; - hback-porch = <88>; - hsync-len = <0>; - vback-porch = <32>; - vfront-porch = <11>; - vsync-len = <1>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/w1/omap-hdq.txt b/Documentation/devicetree/bindings/w1/omap-hdq.txt index fef794741..913c5f91a 100644 --- a/Documentation/devicetree/bindings/w1/omap-hdq.txt +++ b/Documentation/devicetree/bindings/w1/omap-hdq.txt @@ -1,11 +1,15 @@ * OMAP HDQ One wire bus master controller Required properties: -- compatible : should be "ti,omap3-1w" +- compatible : should be "ti,omap3-1w" or "ti,am4372-hdq" - reg : Address and length of the register set for the device - interrupts : interrupt line. - ti,hwmods : "hdq1w" +Optional properties: +- ti,mode: should be "hdq": HDQ mode "1w": one-wire mode. + If not specified HDQ mode is implied. + Example: - From omap3.dtsi @@ -14,4 +18,5 @@ Example: reg = <0x480b2000 0x1000>; interrupts = <58>; ti,hwmods = "hdq1w"; + ti,mode = "hdq"; }; diff --git a/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt new file mode 100644 index 000000000..84122270b --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/brcm,bcm7038-wdt.txt @@ -0,0 +1,19 @@ +BCM7038 Watchdog timer + +Required properties: + +- compatible : should be "brcm,bcm7038-wdt" +- reg : Specifies base physical address and size of the registers. + +Optional properties: + +- clocks: The clock running the watchdog. If no clock is found the + driver will default to 27000000 Hz. + +Example: + +watchdog@f040a7e8 { + compatible = "brcm,bcm7038-wdt"; + clocks = <&upg_fixed>; + reg = <0xf040a7e8 0x16>; +}; diff --git a/Documentation/devicetree/bindings/x86/interrupt.txt b/Documentation/devicetree/bindings/x86/interrupt.txt deleted file mode 100644 index 7d19f494f..000000000 --- a/Documentation/devicetree/bindings/x86/interrupt.txt +++ /dev/null @@ -1,26 +0,0 @@ -Interrupt chips ---------------- - -* Intel I/O Advanced Programmable Interrupt Controller (IO APIC) - - Required properties: - -------------------- - compatible = "intel,ce4100-ioapic"; - #interrupt-cells = <2>; - - Device's interrupt property: - - interrupts =

; - - The first number (P) represents the interrupt pin which is wired to the - IO APIC. The second number (S) represents the sense of interrupt which - should be configured and can be one of: - 0 - Edge Rising - 1 - Level Low - 2 - Level High - 3 - Edge Falling - -* Local APIC - Required property: - - compatible = "intel,ce4100-lapic"; diff --git a/Documentation/dontdiff b/Documentation/dontdiff index 43eb13d87..c6f4ff970 100644 --- a/Documentation/dontdiff +++ b/Documentation/dontdiff @@ -165,7 +165,6 @@ mach-types.h machtypes.h map map_hugetlb -media mconf miboot* mk_elfconfig diff --git a/Documentation/driver-model/platform.txt b/Documentation/driver-model/platform.txt index 07795ec51..e456696cf 100644 --- a/Documentation/driver-model/platform.txt +++ b/Documentation/driver-model/platform.txt @@ -63,6 +63,20 @@ runtime memory footprint: int platform_driver_probe(struct platform_driver *drv, int (*probe)(struct platform_device *)) +Kernel modules can be composed of several platform drivers. The platform core +provides helpers to register and unregister an array of drivers: + + int __platform_register_drivers(struct platform_driver * const *drivers, + unsigned int count, struct module *owner); + void platform_unregister_drivers(struct platform_driver * const *drivers, + unsigned int count); + +If one of the drivers fails to register, all drivers registered up to that +point will be unregistered in reverse order. Note that there is a convenience +macro that passes THIS_MODULE as owner parameter: + + #define platform_register_driver(drivers, count) + Device Enumeration ~~~~~~~~~~~~~~~~~~ diff --git a/Documentation/edac.txt b/Documentation/edac.txt index 0cf27a354..80841a2d6 100644 --- a/Documentation/edac.txt +++ b/Documentation/edac.txt @@ -744,6 +744,52 @@ exports one possible that some errors could be lost. With rdimm's, they display the contents of the registers +AMD64_EDAC REFERENCE DOCUMENTS USED +----------------------------------- +amd64_edac module is based on the following documents +(available from http://support.amd.com/en-us/search/tech-docs): + +1. Title: BIOS and Kernel Developer's Guide for AMD Athlon 64 and AMD + Opteron Processors + AMD publication #: 26094 + Revision: 3.26 + Link: http://support.amd.com/TechDocs/26094.PDF + +2. Title: BIOS and Kernel Developer's Guide for AMD NPT Family 0Fh + Processors + AMD publication #: 32559 + Revision: 3.00 + Issue Date: May 2006 + Link: http://support.amd.com/TechDocs/32559.pdf + +3. Title: BIOS and Kernel Developer's Guide (BKDG) For AMD Family 10h + Processors + AMD publication #: 31116 + Revision: 3.00 + Issue Date: September 07, 2007 + Link: http://support.amd.com/TechDocs/31116.pdf + +4. Title: BIOS and Kernel Developer's Guide (BKDG) for AMD Family 15h + Models 30h-3Fh Processors + AMD publication #: 49125 + Revision: 3.06 + Issue Date: 2/12/2015 (latest release) + Link: http://support.amd.com/TechDocs/49125_15h_Models_30h-3Fh_BKDG.pdf + +5. Title: BIOS and Kernel Developer's Guide (BKDG) for AMD Family 15h + Models 60h-6Fh Processors + AMD publication #: 50742 + Revision: 3.01 + Issue Date: 7/23/2015 (latest release) + Link: http://support.amd.com/TechDocs/50742_15h_Models_60h-6Fh_BKDG.pdf + +6. Title: BIOS and Kernel Developer's Guide (BKDG) for AMD Family 16h + Models 00h-0Fh Processors + AMD publication #: 48751 + Revision: 3.03 + Issue Date: 2/23/2015 (latest release) + Link: http://support.amd.com/TechDocs/48751_16h_bkdg.pdf + CREDITS: ======== diff --git a/Documentation/email-clients.txt b/Documentation/email-clients.txt index 3fa450881..2d485dea8 100644 --- a/Documentation/email-clients.txt +++ b/Documentation/email-clients.txt @@ -176,11 +176,47 @@ To use 'vim' with mutt: if you want to include the patch inline. (a)ttach works fine without "set paste". +You can also generate patches with 'git format-patch' and then use Mutt +to send them: + $ mutt -H 0001-some-bug-fix.patch + Config options: It should work with default settings. However, it's a good idea to set the "send_charset" to: set send_charset="us-ascii:utf-8" +Mutt is highly customizable. Here is a minimum configuration to start +using Mutt to send patches through Gmail: + +# .muttrc +# ================ IMAP ==================== +set imap_user = 'yourusername@gmail.com' +set imap_pass = 'yourpassword' +set spoolfile = imaps://imap.gmail.com/INBOX +set folder = imaps://imap.gmail.com/ +set record="imaps://imap.gmail.com/[Gmail]/Sent Mail" +set postponed="imaps://imap.gmail.com/[Gmail]/Drafts" +set mbox="imaps://imap.gmail.com/[Gmail]/All Mail" + +# ================ SMTP ==================== +set smtp_url = "smtp://username@smtp.gmail.com:587/" +set smtp_pass = $imap_pass +set ssl_force_tls = yes # Require encrypted connection + +# ================ Composition ==================== +set editor = `echo \$EDITOR` +set edit_headers = yes # See the headers when editing +set charset = UTF-8 # value of $LANG; also fallback for send_charset +# Sender, email address, and sign-off line must match +unset use_domain # because joe@localhost is just embarrassing +set realname = "YOUR NAME" +set from = "username@gmail.com" +set use_from = yes + +The Mutt docs have lots more information: + http://dev.mutt.org/trac/wiki/UseCases/Gmail + http://dev.mutt.org/doc/manual.html + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Pine (TUI) @@ -220,7 +256,7 @@ to coerce it into behaving. Compose dialog. Please note that "external editor" requires that your editor must not - fork, or in other words, the editor must not return before closing. + fork, or in other words, the editor must not return before closing. You may have to pass additional flags or change the settings of your editor. Most notably if you are using gvim then you must pass the -f option to gvim by putting "/usr/bin/gvim -f" (if the binary is in diff --git a/Documentation/features/debug/KASAN/arch-support.txt b/Documentation/features/debug/KASAN/arch-support.txt index 14531da2f..703f5784b 100644 --- a/Documentation/features/debug/KASAN/arch-support.txt +++ b/Documentation/features/debug/KASAN/arch-support.txt @@ -9,7 +9,7 @@ | alpha: | TODO | | arc: | TODO | | arm: | TODO | - | arm64: | TODO | + | arm64: | ok | | avr32: | TODO | | blackfin: | TODO | | c6x: | TODO | diff --git a/Documentation/features/vm/THP/arch-support.txt b/Documentation/features/vm/THP/arch-support.txt index df384e3e8..523f8307b 100644 --- a/Documentation/features/vm/THP/arch-support.txt +++ b/Documentation/features/vm/THP/arch-support.txt @@ -7,7 +7,7 @@ | arch |status| ----------------------- | alpha: | TODO | - | arc: | .. | + | arc: | ok | | arm: | ok | | arm64: | ok | | avr32: | .. | diff --git a/Documentation/features/vm/pte_special/arch-support.txt b/Documentation/features/vm/pte_special/arch-support.txt index aaaa21db6..3de5434c8 100644 --- a/Documentation/features/vm/pte_special/arch-support.txt +++ b/Documentation/features/vm/pte_special/arch-support.txt @@ -7,7 +7,7 @@ | arch |status| ----------------------- | alpha: | TODO | - | arc: | TODO | + | arc: | ok | | arm: | ok | | arm64: | ok | | avr32: | TODO | diff --git a/Documentation/filesystems/Makefile b/Documentation/filesystems/Makefile index 13483d192..883010ce5 100644 --- a/Documentation/filesystems/Makefile +++ b/Documentation/filesystems/Makefile @@ -1,5 +1,3 @@ -subdir-y := configfs - # List of programs to build hostprogs-y := dnotify_test diff --git a/Documentation/filesystems/aufs/README b/Documentation/filesystems/aufs/README index 2915102e0..e827ebfa8 100644 --- a/Documentation/filesystems/aufs/README +++ b/Documentation/filesystems/aufs/README @@ -106,7 +106,7 @@ git://git.kernel.org/.../torvalds/linux.git. And you cannot select CONFIG_AUFS_FS=m for this version, eg. you cannot build aufs4 as an external kernel module. Several extra patches are not included in this tree. Only -aufs4-standalone tree contains them. They are describe in the later +aufs4-standalone tree contains them. They are described in the later section "Configuration and Compilation." On the other hand, the aufs4-standalone tree has only aufs source files @@ -262,6 +262,13 @@ optional. When you meet some problems, they will help you. duplication of inode number, which is important for backup tools and other utilities. When you find aufs XINO files for tmpfs branch growing too much, try this patch. +- lockdep-debug.patch + Because aufs is not only an ordinary filesystem (callee of VFS), but + also a caller of VFS functions for branch filesystems, subclassing of + the internal locks for LOCKDEP is necessary. LOCKDEP is a debugging + feature of linux kernel. If you enable CONFIG_LOCKDEP, then you will + need to apply this debug patch to expand several constant values. + If don't know what LOCKDEP, then you don't have apply this patch. 4. Usage diff --git a/Documentation/filesystems/configfs/Makefile b/Documentation/filesystems/configfs/Makefile deleted file mode 100644 index be7ec5e67..000000000 --- a/Documentation/filesystems/configfs/Makefile +++ /dev/null @@ -1,3 +0,0 @@ -ifneq ($(CONFIG_CONFIGFS_FS),) -obj-m += configfs_example_explicit.o configfs_example_macros.o -endif diff --git a/Documentation/filesystems/configfs/configfs.txt b/Documentation/filesystems/configfs/configfs.txt index b40fec9d3..af68efdbb 100644 --- a/Documentation/filesystems/configfs/configfs.txt +++ b/Documentation/filesystems/configfs/configfs.txt @@ -160,12 +160,6 @@ among other things. For that, it needs a type. struct configfs_item_operations { void (*release)(struct config_item *); - ssize_t (*show_attribute)(struct config_item *, - struct configfs_attribute *, - char *); - ssize_t (*store_attribute)(struct config_item *, - struct configfs_attribute *, - const char *, size_t); int (*allow_link)(struct config_item *src, struct config_item *target); int (*drop_link)(struct config_item *src, @@ -183,9 +177,7 @@ The most basic function of a config_item_type is to define what operations can be performed on a config_item. All items that have been allocated dynamically will need to provide the ct_item_ops->release() method. This method is called when the config_item's reference count -reaches zero. Items that wish to display an attribute need to provide -the ct_item_ops->show_attribute() method. Similarly, storing a new -attribute value uses the store_attribute() method. +reaches zero. [struct configfs_attribute] @@ -193,6 +185,8 @@ attribute value uses the store_attribute() method. char *ca_name; struct module *ca_owner; umode_t ca_mode; + ssize_t (*show)(struct config_item *, char *); + ssize_t (*store)(struct config_item *, const char *, size_t); }; When a config_item wants an attribute to appear as a file in the item's @@ -202,10 +196,10 @@ config_item_type->ct_attrs. When the item appears in configfs, the attribute file will appear with the configfs_attribute->ca_name filename. configfs_attribute->ca_mode specifies the file permissions. -If an attribute is readable and the config_item provides a -ct_item_ops->show_attribute() method, that method will be called -whenever userspace asks for a read(2) on the attribute. The converse -will happen for write(2). +If an attribute is readable and provides a ->show method, that method will +be called whenever userspace asks for a read(2) on the attribute. If an +attribute is writable and provides a ->store method, that method will be +be called whenever userspace asks for a write(2) on the attribute. [struct config_group] @@ -311,20 +305,10 @@ the subsystem must be ready for it. [An Example] The best example of these basic concepts is the simple_children -subsystem/group and the simple_child item in configfs_example_explicit.c -and configfs_example_macros.c. It shows a trivial object displaying and -storing an attribute, and a simple group creating and destroying these -children. - -The only difference between configfs_example_explicit.c and -configfs_example_macros.c is how the attributes of the childless item -are defined. The childless item has extended attributes, each with -their own show()/store() operation. This follows a convention commonly -used in sysfs. configfs_example_explicit.c creates these attributes -by explicitly defining the structures involved. Conversely -configfs_example_macros.c uses some convenience macros from configfs.h -to define the attributes. These macros are similar to their sysfs -counterparts. +subsystem/group and the simple_child item in +samples/configfs/configfs_sample.c. It shows a trivial object displaying +and storing an attribute, and a simple group creating and destroying +these children. [Hierarchy Navigation and the Subsystem Mutex] diff --git a/Documentation/filesystems/configfs/configfs_example_explicit.c b/Documentation/filesystems/configfs/configfs_example_explicit.c deleted file mode 100644 index 1420233df..000000000 --- a/Documentation/filesystems/configfs/configfs_example_explicit.c +++ /dev/null @@ -1,483 +0,0 @@ -/* - * vim: noexpandtab ts=8 sts=0 sw=8: - * - * configfs_example_explicit.c - This file is a demonstration module - * containing a number of configfs subsystems. It explicitly defines - * each structure without using the helper macros defined in - * configfs.h. - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public - * License as published by the Free Software Foundation; either - * version 2 of the License, or (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - * General Public License for more details. - * - * You should have received a copy of the GNU General Public - * License along with this program; if not, write to the - * Free Software Foundation, Inc., 59 Temple Place - Suite 330, - * Boston, MA 021110-1307, USA. - * - * Based on sysfs: - * sysfs is Copyright (C) 2001, 2002, 2003 Patrick Mochel - * - * configfs Copyright (C) 2005 Oracle. All rights reserved. - */ - -#include -#include -#include - -#include - - - -/* - * 01-childless - * - * This first example is a childless subsystem. It cannot create - * any config_items. It just has attributes. - * - * Note that we are enclosing the configfs_subsystem inside a container. - * This is not necessary if a subsystem has no attributes directly - * on the subsystem. See the next example, 02-simple-children, for - * such a subsystem. - */ - -struct childless { - struct configfs_subsystem subsys; - int showme; - int storeme; -}; - -struct childless_attribute { - struct configfs_attribute attr; - ssize_t (*show)(struct childless *, char *); - ssize_t (*store)(struct childless *, const char *, size_t); -}; - -static inline struct childless *to_childless(struct config_item *item) -{ - return item ? container_of(to_configfs_subsystem(to_config_group(item)), struct childless, subsys) : NULL; -} - -static ssize_t childless_showme_read(struct childless *childless, - char *page) -{ - ssize_t pos; - - pos = sprintf(page, "%d\n", childless->showme); - childless->showme++; - - return pos; -} - -static ssize_t childless_storeme_read(struct childless *childless, - char *page) -{ - return sprintf(page, "%d\n", childless->storeme); -} - -static ssize_t childless_storeme_write(struct childless *childless, - const char *page, - size_t count) -{ - unsigned long tmp; - char *p = (char *) page; - - tmp = simple_strtoul(p, &p, 10); - if ((*p != '\0') && (*p != '\n')) - return -EINVAL; - - if (tmp > INT_MAX) - return -ERANGE; - - childless->storeme = tmp; - - return count; -} - -static ssize_t childless_description_read(struct childless *childless, - char *page) -{ - return sprintf(page, -"[01-childless]\n" -"\n" -"The childless subsystem is the simplest possible subsystem in\n" -"configfs. It does not support the creation of child config_items.\n" -"It only has a few attributes. In fact, it isn't much different\n" -"than a directory in /proc.\n"); -} - -static struct childless_attribute childless_attr_showme = { - .attr = { .ca_owner = THIS_MODULE, .ca_name = "showme", .ca_mode = S_IRUGO }, - .show = childless_showme_read, -}; -static struct childless_attribute childless_attr_storeme = { - .attr = { .ca_owner = THIS_MODULE, .ca_name = "storeme", .ca_mode = S_IRUGO | S_IWUSR }, - .show = childless_storeme_read, - .store = childless_storeme_write, -}; -static struct childless_attribute childless_attr_description = { - .attr = { .ca_owner = THIS_MODULE, .ca_name = "description", .ca_mode = S_IRUGO }, - .show = childless_description_read, -}; - -static struct configfs_attribute *childless_attrs[] = { - &childless_attr_showme.attr, - &childless_attr_storeme.attr, - &childless_attr_description.attr, - NULL, -}; - -static ssize_t childless_attr_show(struct config_item *item, - struct configfs_attribute *attr, - char *page) -{ - struct childless *childless = to_childless(item); - struct childless_attribute *childless_attr = - container_of(attr, struct childless_attribute, attr); - ssize_t ret = 0; - - if (childless_attr->show) - ret = childless_attr->show(childless, page); - return ret; -} - -static ssize_t childless_attr_store(struct config_item *item, - struct configfs_attribute *attr, - const char *page, size_t count) -{ - struct childless *childless = to_childless(item); - struct childless_attribute *childless_attr = - container_of(attr, struct childless_attribute, attr); - ssize_t ret = -EINVAL; - - if (childless_attr->store) - ret = childless_attr->store(childless, page, count); - return ret; -} - -static struct configfs_item_operations childless_item_ops = { - .show_attribute = childless_attr_show, - .store_attribute = childless_attr_store, -}; - -static struct config_item_type childless_type = { - .ct_item_ops = &childless_item_ops, - .ct_attrs = childless_attrs, - .ct_owner = THIS_MODULE, -}; - -static struct childless childless_subsys = { - .subsys = { - .su_group = { - .cg_item = { - .ci_namebuf = "01-childless", - .ci_type = &childless_type, - }, - }, - }, -}; - - -/* ----------------------------------------------------------------- */ - -/* - * 02-simple-children - * - * This example merely has a simple one-attribute child. Note that - * there is no extra attribute structure, as the child's attribute is - * known from the get-go. Also, there is no container for the - * subsystem, as it has no attributes of its own. - */ - -struct simple_child { - struct config_item item; - int storeme; -}; - -static inline struct simple_child *to_simple_child(struct config_item *item) -{ - return item ? container_of(item, struct simple_child, item) : NULL; -} - -static struct configfs_attribute simple_child_attr_storeme = { - .ca_owner = THIS_MODULE, - .ca_name = "storeme", - .ca_mode = S_IRUGO | S_IWUSR, -}; - -static struct configfs_attribute *simple_child_attrs[] = { - &simple_child_attr_storeme, - NULL, -}; - -static ssize_t simple_child_attr_show(struct config_item *item, - struct configfs_attribute *attr, - char *page) -{ - ssize_t count; - struct simple_child *simple_child = to_simple_child(item); - - count = sprintf(page, "%d\n", simple_child->storeme); - - return count; -} - -static ssize_t simple_child_attr_store(struct config_item *item, - struct configfs_attribute *attr, - const char *page, size_t count) -{ - struct simple_child *simple_child = to_simple_child(item); - unsigned long tmp; - char *p = (char *) page; - - tmp = simple_strtoul(p, &p, 10); - if (!p || (*p && (*p != '\n'))) - return -EINVAL; - - if (tmp > INT_MAX) - return -ERANGE; - - simple_child->storeme = tmp; - - return count; -} - -static void simple_child_release(struct config_item *item) -{ - kfree(to_simple_child(item)); -} - -static struct configfs_item_operations simple_child_item_ops = { - .release = simple_child_release, - .show_attribute = simple_child_attr_show, - .store_attribute = simple_child_attr_store, -}; - -static struct config_item_type simple_child_type = { - .ct_item_ops = &simple_child_item_ops, - .ct_attrs = simple_child_attrs, - .ct_owner = THIS_MODULE, -}; - - -struct simple_children { - struct config_group group; -}; - -static inline struct simple_children *to_simple_children(struct config_item *item) -{ - return item ? container_of(to_config_group(item), struct simple_children, group) : NULL; -} - -static struct config_item *simple_children_make_item(struct config_group *group, const char *name) -{ - struct simple_child *simple_child; - - simple_child = kzalloc(sizeof(struct simple_child), GFP_KERNEL); - if (!simple_child) - return ERR_PTR(-ENOMEM); - - config_item_init_type_name(&simple_child->item, name, - &simple_child_type); - - simple_child->storeme = 0; - - return &simple_child->item; -} - -static struct configfs_attribute simple_children_attr_description = { - .ca_owner = THIS_MODULE, - .ca_name = "description", - .ca_mode = S_IRUGO, -}; - -static struct configfs_attribute *simple_children_attrs[] = { - &simple_children_attr_description, - NULL, -}; - -static ssize_t simple_children_attr_show(struct config_item *item, - struct configfs_attribute *attr, - char *page) -{ - return sprintf(page, -"[02-simple-children]\n" -"\n" -"This subsystem allows the creation of child config_items. These\n" -"items have only one attribute that is readable and writeable.\n"); -} - -static void simple_children_release(struct config_item *item) -{ - kfree(to_simple_children(item)); -} - -static struct configfs_item_operations simple_children_item_ops = { - .release = simple_children_release, - .show_attribute = simple_children_attr_show, -}; - -/* - * Note that, since no extra work is required on ->drop_item(), - * no ->drop_item() is provided. - */ -static struct configfs_group_operations simple_children_group_ops = { - .make_item = simple_children_make_item, -}; - -static struct config_item_type simple_children_type = { - .ct_item_ops = &simple_children_item_ops, - .ct_group_ops = &simple_children_group_ops, - .ct_attrs = simple_children_attrs, - .ct_owner = THIS_MODULE, -}; - -static struct configfs_subsystem simple_children_subsys = { - .su_group = { - .cg_item = { - .ci_namebuf = "02-simple-children", - .ci_type = &simple_children_type, - }, - }, -}; - - -/* ----------------------------------------------------------------- */ - -/* - * 03-group-children - * - * This example reuses the simple_children group from above. However, - * the simple_children group is not the subsystem itself, it is a - * child of the subsystem. Creation of a group in the subsystem creates - * a new simple_children group. That group can then have simple_child - * children of its own. - */ - -static struct config_group *group_children_make_group(struct config_group *group, const char *name) -{ - struct simple_children *simple_children; - - simple_children = kzalloc(sizeof(struct simple_children), - GFP_KERNEL); - if (!simple_children) - return ERR_PTR(-ENOMEM); - - config_group_init_type_name(&simple_children->group, name, - &simple_children_type); - - return &simple_children->group; -} - -static struct configfs_attribute group_children_attr_description = { - .ca_owner = THIS_MODULE, - .ca_name = "description", - .ca_mode = S_IRUGO, -}; - -static struct configfs_attribute *group_children_attrs[] = { - &group_children_attr_description, - NULL, -}; - -static ssize_t group_children_attr_show(struct config_item *item, - struct configfs_attribute *attr, - char *page) -{ - return sprintf(page, -"[03-group-children]\n" -"\n" -"This subsystem allows the creation of child config_groups. These\n" -"groups are like the subsystem simple-children.\n"); -} - -static struct configfs_item_operations group_children_item_ops = { - .show_attribute = group_children_attr_show, -}; - -/* - * Note that, since no extra work is required on ->drop_item(), - * no ->drop_item() is provided. - */ -static struct configfs_group_operations group_children_group_ops = { - .make_group = group_children_make_group, -}; - -static struct config_item_type group_children_type = { - .ct_item_ops = &group_children_item_ops, - .ct_group_ops = &group_children_group_ops, - .ct_attrs = group_children_attrs, - .ct_owner = THIS_MODULE, -}; - -static struct configfs_subsystem group_children_subsys = { - .su_group = { - .cg_item = { - .ci_namebuf = "03-group-children", - .ci_type = &group_children_type, - }, - }, -}; - -/* ----------------------------------------------------------------- */ - -/* - * We're now done with our subsystem definitions. - * For convenience in this module, here's a list of them all. It - * allows the init function to easily register them. Most modules - * will only have one subsystem, and will only call register_subsystem - * on it directly. - */ -static struct configfs_subsystem *example_subsys[] = { - &childless_subsys.subsys, - &simple_children_subsys, - &group_children_subsys, - NULL, -}; - -static int __init configfs_example_init(void) -{ - int ret; - int i; - struct configfs_subsystem *subsys; - - for (i = 0; example_subsys[i]; i++) { - subsys = example_subsys[i]; - - config_group_init(&subsys->su_group); - mutex_init(&subsys->su_mutex); - ret = configfs_register_subsystem(subsys); - if (ret) { - printk(KERN_ERR "Error %d while registering subsystem %s\n", - ret, - subsys->su_group.cg_item.ci_namebuf); - goto out_unregister; - } - } - - return 0; - -out_unregister: - for (i--; i >= 0; i--) - configfs_unregister_subsystem(example_subsys[i]); - - return ret; -} - -static void __exit configfs_example_exit(void) -{ - int i; - - for (i = 0; example_subsys[i]; i++) - configfs_unregister_subsystem(example_subsys[i]); -} - -module_init(configfs_example_init); -module_exit(configfs_example_exit); -MODULE_LICENSE("GPL"); diff --git a/Documentation/filesystems/configfs/configfs_example_macros.c b/Documentation/filesystems/configfs/configfs_example_macros.c deleted file mode 100644 index 327dfbc64..000000000 --- a/Documentation/filesystems/configfs/configfs_example_macros.c +++ /dev/null @@ -1,446 +0,0 @@ -/* - * vim: noexpandtab ts=8 sts=0 sw=8: - * - * configfs_example_macros.c - This file is a demonstration module - * containing a number of configfs subsystems. It uses the helper - * macros defined by configfs.h - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public - * License as published by the Free Software Foundation; either - * version 2 of the License, or (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - * General Public License for more details. - * - * You should have received a copy of the GNU General Public - * License along with this program; if not, write to the - * Free Software Foundation, Inc., 59 Temple Place - Suite 330, - * Boston, MA 021110-1307, USA. - * - * Based on sysfs: - * sysfs is Copyright (C) 2001, 2002, 2003 Patrick Mochel - * - * configfs Copyright (C) 2005 Oracle. All rights reserved. - */ - -#include -#include -#include - -#include - - - -/* - * 01-childless - * - * This first example is a childless subsystem. It cannot create - * any config_items. It just has attributes. - * - * Note that we are enclosing the configfs_subsystem inside a container. - * This is not necessary if a subsystem has no attributes directly - * on the subsystem. See the next example, 02-simple-children, for - * such a subsystem. - */ - -struct childless { - struct configfs_subsystem subsys; - int showme; - int storeme; -}; - -static inline struct childless *to_childless(struct config_item *item) -{ - return item ? container_of(to_configfs_subsystem(to_config_group(item)), struct childless, subsys) : NULL; -} - -CONFIGFS_ATTR_STRUCT(childless); -#define CHILDLESS_ATTR(_name, _mode, _show, _store) \ -struct childless_attribute childless_attr_##_name = __CONFIGFS_ATTR(_name, _mode, _show, _store) -#define CHILDLESS_ATTR_RO(_name, _show) \ -struct childless_attribute childless_attr_##_name = __CONFIGFS_ATTR_RO(_name, _show); - -static ssize_t childless_showme_read(struct childless *childless, - char *page) -{ - ssize_t pos; - - pos = sprintf(page, "%d\n", childless->showme); - childless->showme++; - - return pos; -} - -static ssize_t childless_storeme_read(struct childless *childless, - char *page) -{ - return sprintf(page, "%d\n", childless->storeme); -} - -static ssize_t childless_storeme_write(struct childless *childless, - const char *page, - size_t count) -{ - unsigned long tmp; - char *p = (char *) page; - - tmp = simple_strtoul(p, &p, 10); - if (!p || (*p && (*p != '\n'))) - return -EINVAL; - - if (tmp > INT_MAX) - return -ERANGE; - - childless->storeme = tmp; - - return count; -} - -static ssize_t childless_description_read(struct childless *childless, - char *page) -{ - return sprintf(page, -"[01-childless]\n" -"\n" -"The childless subsystem is the simplest possible subsystem in\n" -"configfs. It does not support the creation of child config_items.\n" -"It only has a few attributes. In fact, it isn't much different\n" -"than a directory in /proc.\n"); -} - -CHILDLESS_ATTR_RO(showme, childless_showme_read); -CHILDLESS_ATTR(storeme, S_IRUGO | S_IWUSR, childless_storeme_read, - childless_storeme_write); -CHILDLESS_ATTR_RO(description, childless_description_read); - -static struct configfs_attribute *childless_attrs[] = { - &childless_attr_showme.attr, - &childless_attr_storeme.attr, - &childless_attr_description.attr, - NULL, -}; - -CONFIGFS_ATTR_OPS(childless); -static struct configfs_item_operations childless_item_ops = { - .show_attribute = childless_attr_show, - .store_attribute = childless_attr_store, -}; - -static struct config_item_type childless_type = { - .ct_item_ops = &childless_item_ops, - .ct_attrs = childless_attrs, - .ct_owner = THIS_MODULE, -}; - -static struct childless childless_subsys = { - .subsys = { - .su_group = { - .cg_item = { - .ci_namebuf = "01-childless", - .ci_type = &childless_type, - }, - }, - }, -}; - - -/* ----------------------------------------------------------------- */ - -/* - * 02-simple-children - * - * This example merely has a simple one-attribute child. Note that - * there is no extra attribute structure, as the child's attribute is - * known from the get-go. Also, there is no container for the - * subsystem, as it has no attributes of its own. - */ - -struct simple_child { - struct config_item item; - int storeme; -}; - -static inline struct simple_child *to_simple_child(struct config_item *item) -{ - return item ? container_of(item, struct simple_child, item) : NULL; -} - -static struct configfs_attribute simple_child_attr_storeme = { - .ca_owner = THIS_MODULE, - .ca_name = "storeme", - .ca_mode = S_IRUGO | S_IWUSR, -}; - -static struct configfs_attribute *simple_child_attrs[] = { - &simple_child_attr_storeme, - NULL, -}; - -static ssize_t simple_child_attr_show(struct config_item *item, - struct configfs_attribute *attr, - char *page) -{ - ssize_t count; - struct simple_child *simple_child = to_simple_child(item); - - count = sprintf(page, "%d\n", simple_child->storeme); - - return count; -} - -static ssize_t simple_child_attr_store(struct config_item *item, - struct configfs_attribute *attr, - const char *page, size_t count) -{ - struct simple_child *simple_child = to_simple_child(item); - unsigned long tmp; - char *p = (char *) page; - - tmp = simple_strtoul(p, &p, 10); - if (!p || (*p && (*p != '\n'))) - return -EINVAL; - - if (tmp > INT_MAX) - return -ERANGE; - - simple_child->storeme = tmp; - - return count; -} - -static void simple_child_release(struct config_item *item) -{ - kfree(to_simple_child(item)); -} - -static struct configfs_item_operations simple_child_item_ops = { - .release = simple_child_release, - .show_attribute = simple_child_attr_show, - .store_attribute = simple_child_attr_store, -}; - -static struct config_item_type simple_child_type = { - .ct_item_ops = &simple_child_item_ops, - .ct_attrs = simple_child_attrs, - .ct_owner = THIS_MODULE, -}; - - -struct simple_children { - struct config_group group; -}; - -static inline struct simple_children *to_simple_children(struct config_item *item) -{ - return item ? container_of(to_config_group(item), struct simple_children, group) : NULL; -} - -static struct config_item *simple_children_make_item(struct config_group *group, const char *name) -{ - struct simple_child *simple_child; - - simple_child = kzalloc(sizeof(struct simple_child), GFP_KERNEL); - if (!simple_child) - return ERR_PTR(-ENOMEM); - - config_item_init_type_name(&simple_child->item, name, - &simple_child_type); - - simple_child->storeme = 0; - - return &simple_child->item; -} - -static struct configfs_attribute simple_children_attr_description = { - .ca_owner = THIS_MODULE, - .ca_name = "description", - .ca_mode = S_IRUGO, -}; - -static struct configfs_attribute *simple_children_attrs[] = { - &simple_children_attr_description, - NULL, -}; - -static ssize_t simple_children_attr_show(struct config_item *item, - struct configfs_attribute *attr, - char *page) -{ - return sprintf(page, -"[02-simple-children]\n" -"\n" -"This subsystem allows the creation of child config_items. These\n" -"items have only one attribute that is readable and writeable.\n"); -} - -static void simple_children_release(struct config_item *item) -{ - kfree(to_simple_children(item)); -} - -static struct configfs_item_operations simple_children_item_ops = { - .release = simple_children_release, - .show_attribute = simple_children_attr_show, -}; - -/* - * Note that, since no extra work is required on ->drop_item(), - * no ->drop_item() is provided. - */ -static struct configfs_group_operations simple_children_group_ops = { - .make_item = simple_children_make_item, -}; - -static struct config_item_type simple_children_type = { - .ct_item_ops = &simple_children_item_ops, - .ct_group_ops = &simple_children_group_ops, - .ct_attrs = simple_children_attrs, - .ct_owner = THIS_MODULE, -}; - -static struct configfs_subsystem simple_children_subsys = { - .su_group = { - .cg_item = { - .ci_namebuf = "02-simple-children", - .ci_type = &simple_children_type, - }, - }, -}; - - -/* ----------------------------------------------------------------- */ - -/* - * 03-group-children - * - * This example reuses the simple_children group from above. However, - * the simple_children group is not the subsystem itself, it is a - * child of the subsystem. Creation of a group in the subsystem creates - * a new simple_children group. That group can then have simple_child - * children of its own. - */ - -static struct config_group *group_children_make_group(struct config_group *group, const char *name) -{ - struct simple_children *simple_children; - - simple_children = kzalloc(sizeof(struct simple_children), - GFP_KERNEL); - if (!simple_children) - return ERR_PTR(-ENOMEM); - - config_group_init_type_name(&simple_children->group, name, - &simple_children_type); - - return &simple_children->group; -} - -static struct configfs_attribute group_children_attr_description = { - .ca_owner = THIS_MODULE, - .ca_name = "description", - .ca_mode = S_IRUGO, -}; - -static struct configfs_attribute *group_children_attrs[] = { - &group_children_attr_description, - NULL, -}; - -static ssize_t group_children_attr_show(struct config_item *item, - struct configfs_attribute *attr, - char *page) -{ - return sprintf(page, -"[03-group-children]\n" -"\n" -"This subsystem allows the creation of child config_groups. These\n" -"groups are like the subsystem simple-children.\n"); -} - -static struct configfs_item_operations group_children_item_ops = { - .show_attribute = group_children_attr_show, -}; - -/* - * Note that, since no extra work is required on ->drop_item(), - * no ->drop_item() is provided. - */ -static struct configfs_group_operations group_children_group_ops = { - .make_group = group_children_make_group, -}; - -static struct config_item_type group_children_type = { - .ct_item_ops = &group_children_item_ops, - .ct_group_ops = &group_children_group_ops, - .ct_attrs = group_children_attrs, - .ct_owner = THIS_MODULE, -}; - -static struct configfs_subsystem group_children_subsys = { - .su_group = { - .cg_item = { - .ci_namebuf = "03-group-children", - .ci_type = &group_children_type, - }, - }, -}; - -/* ----------------------------------------------------------------- */ - -/* - * We're now done with our subsystem definitions. - * For convenience in this module, here's a list of them all. It - * allows the init function to easily register them. Most modules - * will only have one subsystem, and will only call register_subsystem - * on it directly. - */ -static struct configfs_subsystem *example_subsys[] = { - &childless_subsys.subsys, - &simple_children_subsys, - &group_children_subsys, - NULL, -}; - -static int __init configfs_example_init(void) -{ - int ret; - int i; - struct configfs_subsystem *subsys; - - for (i = 0; example_subsys[i]; i++) { - subsys = example_subsys[i]; - - config_group_init(&subsys->su_group); - mutex_init(&subsys->su_mutex); - ret = configfs_register_subsystem(subsys); - if (ret) { - printk(KERN_ERR "Error %d while registering subsystem %s\n", - ret, - subsys->su_group.cg_item.ci_namebuf); - goto out_unregister; - } - } - - return 0; - -out_unregister: - for (i--; i >= 0; i--) - configfs_unregister_subsystem(example_subsys[i]); - - return ret; -} - -static void __exit configfs_example_exit(void) -{ - int i; - - for (i = 0; example_subsys[i]; i++) - configfs_unregister_subsystem(example_subsys[i]); -} - -module_init(configfs_example_init); -module_exit(configfs_example_exit); -MODULE_LICENSE("GPL"); diff --git a/Documentation/filesystems/debugfs.txt b/Documentation/filesystems/debugfs.txt index 463f59573..4f45f7114 100644 --- a/Documentation/filesystems/debugfs.txt +++ b/Documentation/filesystems/debugfs.txt @@ -105,7 +105,7 @@ a variable of type size_t. Boolean values can be placed in debugfs with: struct dentry *debugfs_create_bool(const char *name, umode_t mode, - struct dentry *parent, u32 *value); + struct dentry *parent, bool *value); A read on the resulting file will yield either Y (for non-zero values) or N, followed by a newline. If written to, it will accept either upper- or diff --git a/Documentation/filesystems/f2fs.txt b/Documentation/filesystems/f2fs.txt index e2d5105b7..b102b4365 100644 --- a/Documentation/filesystems/f2fs.txt +++ b/Documentation/filesystems/f2fs.txt @@ -102,7 +102,8 @@ background_gc=%s Turn on/off cleaning operations, namely garbage collection, triggered in background when I/O subsystem is idle. If background_gc=on, it will turn on the garbage collection and if background_gc=off, garbage collection - will be truned off. + will be truned off. If background_gc=sync, it will turn + on synchronous garbage collection running in background. Default value for this option is on. So garbage collection is on by default. disable_roll_forward Disable the roll-forward recovery routine diff --git a/Documentation/filesystems/gfs2-glocks.txt b/Documentation/filesystems/gfs2-glocks.txt index fcc79957b..1fb12f9df 100644 --- a/Documentation/filesystems/gfs2-glocks.txt +++ b/Documentation/filesystems/gfs2-glocks.txt @@ -5,7 +5,7 @@ This documents the basic principles of the glock state machine internals. Each glock (struct gfs2_glock in fs/gfs2/incore.h) has two main (internal) locks: - 1. A spinlock (gl_spin) which protects the internal state such + 1. A spinlock (gl_lockref.lock) which protects the internal state such as gl_state, gl_target and the list of holders (gl_holders) 2. A non-blocking bit lock, GLF_LOCK, which is used to prevent other threads from making calls to the DLM, etc. at the same time. If a @@ -82,8 +82,8 @@ rather than via the glock. Locking rules for glock operations: -Operation | GLF_LOCK bit lock held | gl_spin spinlock held ------------------------------------------------------------------ +Operation | GLF_LOCK bit lock held | gl_lockref.lock spinlock held +------------------------------------------------------------------------- go_xmote_th | Yes | No go_xmote_bh | Yes | No go_inval | Yes | No diff --git a/Documentation/filesystems/nfs/nfsroot.txt b/Documentation/filesystems/nfs/nfsroot.txt index 2d66ed688..bb5ab6de5 100644 --- a/Documentation/filesystems/nfs/nfsroot.txt +++ b/Documentation/filesystems/nfs/nfsroot.txt @@ -157,6 +157,9 @@ ip=::::::: both: use both BOOTP and RARP but not DHCP (old option kept for backwards compatibility) + if dhcp is used, the client identifier can be used by following + format "ip=dhcp,client-id-type,client-id-value" + Default: any IP address of first nameserver. diff --git a/Documentation/filesystems/overlayfs.txt b/Documentation/filesystems/overlayfs.txt index 6db0e5d1d..28091457b 100644 --- a/Documentation/filesystems/overlayfs.txt +++ b/Documentation/filesystems/overlayfs.txt @@ -1,4 +1,5 @@ -Written by: Neil Brown +Written by: Neil Brown +Please see MAINTAINERS file for where to send questions. Overlay Filesystem ================== diff --git a/Documentation/filesystems/path-lookup.md b/Documentation/filesystems/path-lookup.md new file mode 100644 index 000000000..1b39e084a --- /dev/null +++ b/Documentation/filesystems/path-lookup.md @@ -0,0 +1,1297 @@ + + + + +Pathname lookup in Linux. +========================= + +This write-up is based on three articles published at lwn.net: + +- Pathname lookup in Linux +- RCU-walk: faster pathname lookup in Linux +- A walk among the symlinks + +Written by Neil Brown with help from Al Viro and Jon Corbet. + +Introduction +------------ + +The most obvious aspect of pathname lookup, which very little +exploration is needed to discover, is that it is complex. There are +many rules, special cases, and implementation alternatives that all +combine to confuse the unwary reader. Computer science has long been +acquainted with such complexity and has tools to help manage it. One +tool that we will make extensive use of is "divide and conquer". For +the early parts of the analysis we will divide off symlinks - leaving +them until the final part. Well before we get to symlinks we have +another major division based on the VFS's approach to locking which +will allow us to review "REF-walk" and "RCU-walk" separately. But we +are getting ahead of ourselves. There are some important low level +distinctions we need to clarify first. + +There are two sorts of ... +-------------------------- + +[`openat()`]: http://man7.org/linux/man-pages/man2/openat.2.html + +Pathnames (sometimes "file names"), used to identify objects in the +filesystem, will be familiar to most readers. They contain two sorts +of elements: "slashes" that are sequences of one or more "`/`" +characters, and "components" that are sequences of one or more +non-"`/`" characters. These form two kinds of paths. Those that +start with slashes are "absolute" and start from the filesystem root. +The others are "relative" and start from the current directory, or +from some other location specified by a file descriptor given to a +"xxx`at`" system call such as "[`openat()`]". + +[`execveat()`]: http://man7.org/linux/man-pages/man2/execveat.2.html + +It is tempting to describe the second kind as starting with a +component, but that isn't always accurate: a pathname can lack both +slashes and components, it can be empty, in other words. This is +generally forbidden in POSIX, but some of those "xxx`at`" system calls +in Linux permit it when the `AT_EMPTY_PATH` flag is given. For +example, if you have an open file descriptor on an executable file you +can execute it by calling [`execveat()`] passing the file descriptor, +an empty path, and the `AT_EMPTY_PATH` flag. + +These paths can be divided into two sections: the final component and +everything else. The "everything else" is the easy bit. In all cases +it must identify a directory that already exists, otherwise an error +such as `ENOENT` or `ENOTDIR` will be reported. + +The final component is not so simple. Not only do different system +calls interpret it quite differently (e.g. some create it, some do +not), but it might not even exist: neither the empty pathname nor the +pathname that is just slashes have a final component. If it does +exist, it could be "`.`" or "`..`" which are handled quite differently +from other components. + +[POSIX]: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_12 + +If a pathname ends with a slash, such as "`/tmp/foo/`" it might be +tempting to consider that to have an empty final component. In many +ways that would lead to correct results, but not always. In +particular, `mkdir()` and `rmdir()` each create or remove a directory named +by the final component, and they are required to work with pathnames +ending in "`/`". According to [POSIX] + +> A pathname that contains at least one non- <slash> character and +> that ends with one or more trailing <slash> characters shall not +> be resolved successfully unless the last pathname component before +> the trailing characters names an existing directory or a +> directory entry that is to be created for a directory immediately +> after the pathname is resolved. + +The Linux pathname walking code (mostly in `fs/namei.c`) deals with +all of these issues: breaking the path into components, handling the +"everything else" quite separately from the final component, and +checking that the trailing slash is not used where it isn't +permitted. It also addresses the important issue of concurrent +access. + +While one process is looking up a pathname, another might be making +changes that affect that lookup. One fairly extreme case is that if +"a/b" were renamed to "a/c/b" while another process were looking up +"a/b/..", that process might successfully resolve on "a/c". +Most races are much more subtle, and a big part of the task of +pathname lookup is to prevent them from having damaging effects. Many +of the possible races are seen most clearly in the context of the +"dcache" and an understanding of that is central to understanding +pathname lookup. + +More than just a cache. +----------------------- + +The "dcache" caches information about names in each filesystem to +make them quickly available for lookup. Each entry (known as a +"dentry") contains three significant fields: a component name, a +pointer to a parent dentry, and a pointer to the "inode" which +contains further information about the object in that parent with +the given name. The inode pointer can be `NULL` indicating that the +name doesn't exist in the parent. While there can be linkage in the +dentry of a directory to the dentries of the children, that linkage is +not used for pathname lookup, and so will not be considered here. + +The dcache has a number of uses apart from accelerating lookup. One +that will be particularly relevant is that it is closely integrated +with the mount table that records which filesystem is mounted where. +What the mount table actually stores is which dentry is mounted on top +of which other dentry. + +When considering the dcache, we have another of our "two types" +distinctions: there are two types of filesystems. + +Some filesystems ensure that the information in the dcache is always +completely accurate (though not necessarily complete). This can allow +the VFS to determine if a particular file does or doesn't exist +without checking with the filesystem, and means that the VFS can +protect the filesystem against certain races and other problems. +These are typically "local" filesystems such as ext3, XFS, and Btrfs. + +Other filesystems don't provide that guarantee because they cannot. +These are typically filesystems that are shared across a network, +whether remote filesystems like NFS and 9P, or cluster filesystems +like ocfs2 or cephfs. These filesystems allow the VFS to revalidate +cached information, and must provide their own protection against +awkward races. The VFS can detect these filesystems by the +`DCACHE_OP_REVALIDATE` flag being set in the dentry. + +REF-walk: simple concurrency management with refcounts and spinlocks +-------------------------------------------------------------------- + +With all of those divisions carefully classified, we can now start +looking at the actual process of walking along a path. In particular +we will start with the handling of the "everything else" part of a +pathname, and focus on the "REF-walk" approach to concurrency +management. This code is found in the `link_path_walk()` function, if +you ignore all the places that only run when "`LOOKUP_RCU`" +(indicating the use of RCU-walk) is set. + +[Meet the Lockers]: https://lwn.net/Articles/453685/ + +REF-walk is fairly heavy-handed with locks and reference counts. Not +as heavy-handed as in the old "big kernel lock" days, but certainly not +afraid of taking a lock when one is needed. It uses a variety of +different concurrency controls. A background understanding of the +various primitives is assumed, or can be gleaned from elsewhere such +as in [Meet the Lockers]. + +The locking mechanisms used by REF-walk include: + +### dentry->d_lockref ### + +This uses the lockref primitive to provide both a spinlock and a +reference count. The special-sauce of this primitive is that the +conceptual sequence "lock; inc_ref; unlock;" can often be performed +with a single atomic memory operation. + +Holding a reference on a dentry ensures that the dentry won't suddenly +be freed and used for something else, so the values in various fields +will behave as expected. It also protects the `->d_inode` reference +to the inode to some extent. + +The association between a dentry and its inode is fairly permanent. +For example, when a file is renamed, the dentry and inode move +together to the new location. When a file is created the dentry will +initially be negative (i.e. `d_inode` is `NULL`), and will be assigned +to the new inode as part of the act of creation. + +When a file is deleted, this can be reflected in the cache either by +setting `d_inode` to `NULL`, or by removing it from the hash table +(described shortly) used to look up the name in the parent directory. +If the dentry is still in use the second option is used as it is +perfectly legal to keep using an open file after it has been deleted +and having the dentry around helps. If the dentry is not otherwise in +use (i.e. if the refcount in `d_lockref` is one), only then will +`d_inode` be set to `NULL`. Doing it this way is more efficient for a +very common case. + +So as long as a counted reference is held to a dentry, a non-`NULL` `->d_inode` +value will never be changed. + +### dentry->d_lock ### + +`d_lock` is a synonym for the spinlock that is part of `d_lockref` above. +For our purposes, holding this lock protects against the dentry being +renamed or unlinked. In particular, its parent (`d_parent`), and its +name (`d_name`) cannot be changed, and it cannot be removed from the +dentry hash table. + +When looking for a name in a directory, REF-walk takes `d_lock` on +each candidate dentry that it finds in the hash table and then checks +that the parent and name are correct. So it doesn't lock the parent +while searching in the cache; it only locks children. + +When looking for the parent for a given name (to handle "`..`"), +REF-walk can take `d_lock` to get a stable reference to `d_parent`, +but it first tries a more lightweight approach. As seen in +`dget_parent()`, if a reference can be claimed on the parent, and if +subsequently `d_parent` can be seen to have not changed, then there is +no need to actually take the lock on the child. + +### rename_lock ### + +Looking up a given name in a given directory involves computing a hash +from the two values (the name and the dentry of the directory), +accessing that slot in a hash table, and searching the linked list +that is found there. + +When a dentry is renamed, the name and the parent dentry can both +change so the hash will almost certainly change too. This would move the +dentry to a different chain in the hash table. If a filename search +happened to be looking at a dentry that was moved in this way, +it might end up continuing the search down the wrong chain, +and so miss out on part of the correct chain. + +The name-lookup process (`d_lookup()`) does _not_ try to prevent this +from happening, but only to detect when it happens. +`rename_lock` is a seqlock that is updated whenever any dentry is +renamed. If `d_lookup` finds that a rename happened while it +unsuccessfully scanned a chain in the hash table, it simply tries +again. + +### inode->i_mutex ### + +`i_mutex` is a mutex that serializes all changes to a particular +directory. This ensures that, for example, an `unlink()` and a `rename()` +cannot both happen at the same time. It also keeps the directory +stable while the filesystem is asked to look up a name that is not +currently in the dcache. + +This has a complementary role to that of `d_lock`: `i_mutex` on a +directory protects all of the names in that directory, while `d_lock` +on a name protects just one name in a directory. Most changes to the +dcache hold `i_mutex` on the relevant directory inode and briefly take +`d_lock` on one or more the dentries while the change happens. One +exception is when idle dentries are removed from the dcache due to +memory pressure. This uses `d_lock`, but `i_mutex` plays no role. + +The mutex affects pathname lookup in two distinct ways. Firstly it +serializes lookup of a name in a directory. `walk_component()` uses +`lookup_fast()` first which, in turn, checks to see if the name is in the cache, +using only `d_lock` locking. If the name isn't found, then `walk_component()` +falls back to `lookup_slow()` which takes `i_mutex`, checks again that +the name isn't in the cache, and then calls in to the filesystem to get a +definitive answer. A new dentry will be added to the cache regardless of +the result. + +Secondly, when pathname lookup reaches the final component, it will +sometimes need to take `i_mutex` before performing the last lookup so +that the required exclusion can be achieved. How path lookup chooses +to take, or not take, `i_mutex` is one of the +issues addressed in a subsequent section. + +### mnt->mnt_count ### + +`mnt_count` is a per-CPU reference counter on "`mount`" structures. +Per-CPU here means that incrementing the count is cheap as it only +uses CPU-local memory, but checking if the count is zero is expensive as +it needs to check with every CPU. Taking a `mnt_count` reference +prevents the mount structure from disappearing as the result of regular +unmount operations, but does not prevent a "lazy" unmount. So holding +`mnt_count` doesn't ensure that the mount remains in the namespace and, +in particular, doesn't stabilize the link to the mounted-on dentry. It +does, however, ensure that the `mount` data structure remains coherent, +and it provides a reference to the root dentry of the mounted +filesystem. So a reference through `->mnt_count` provides a stable +reference to the mounted dentry, but not the mounted-on dentry. + +### mount_lock ### + +`mount_lock` is a global seqlock, a bit like `rename_lock`. It can be used to +check if any change has been made to any mount points. + +While walking down the tree (away from the root) this lock is used when +crossing a mount point to check that the crossing was safe. That is, +the value in the seqlock is read, then the code finds the mount that +is mounted on the current directory, if there is one, and increments +the `mnt_count`. Finally the value in `mount_lock` is checked against +the old value. If there is no change, then the crossing was safe. If there +was a change, the `mnt_count` is decremented and the whole process is +retried. + +When walking up the tree (towards the root) by following a ".." link, +a little more care is needed. In this case the seqlock (which +contains both a counter and a spinlock) is fully locked to prevent +any changes to any mount points while stepping up. This locking is +needed to stabilize the link to the mounted-on dentry, which the +refcount on the mount itself doesn't ensure. + +### RCU ### + +Finally the global (but extremely lightweight) RCU read lock is held +from time to time to ensure certain data structures don't get freed +unexpectedly. + +In particular it is held while scanning chains in the dcache hash +table, and the mount point hash table. + +Bringing it together with `struct nameidata` +-------------------------------------------- + +[First edition Unix]: http://minnie.tuhs.org/cgi-bin/utree.pl?file=V1/u2.s + +Throughout the process of walking a path, the current status is stored +in a `struct nameidata`, "namei" being the traditional name - dating +all the way back to [First Edition Unix] - of the function that +converts a "name" to an "inode". `struct nameidata` contains (among +other fields): + +### `struct path path` ### + +A `path` contains a `struct vfsmount` (which is +embedded in a `struct mount`) and a `struct dentry`. Together these +record the current status of the walk. They start out referring to the +starting point (the current working directory, the root directory, or some other +directory identified by a file descriptor), and are updated on each +step. A reference through `d_lockref` and `mnt_count` is always +held. + +### `struct qstr last` ### + +This is a string together with a length (i.e. _not_ `nul` terminated) +that is the "next" component in the pathname. + +### `int last_type` ### + +This is one of `LAST_NORM`, `LAST_ROOT`, `LAST_DOT`, `LAST_DOTDOT`, or +`LAST_BIND`. The `last` field is only valid if the type is +`LAST_NORM`. `LAST_BIND` is used when following a symlink and no +components of the symlink have been processed yet. Others should be +fairly self-explanatory. + +### `struct path root` ### + +This is used to hold a reference to the effective root of the +filesystem. Often that reference won't be needed, so this field is +only assigned the first time it is used, or when a non-standard root +is requested. Keeping a reference in the `nameidata` ensures that +only one root is in effect for the entire path walk, even if it races +with a `chroot()` system call. + +The root is needed when either of two conditions holds: (1) either the +pathname or a symbolic link starts with a "'/'", or (2) a "`..`" +component is being handled, since "`..`" from the root must always stay +at the root. The value used is usually the current root directory of +the calling process. An alternate root can be provided as when +`sysctl()` calls `file_open_root()`, and when NFSv4 or Btrfs call +`mount_subtree()`. In each case a pathname is being looked up in a very +specific part of the filesystem, and the lookup must not be allowed to +escape that subtree. It works a bit like a local `chroot()`. + +Ignoring the handling of symbolic links, we can now describe the +"`link_path_walk()`" function, which handles the lookup of everything +except the final component as: + +> Given a path (`name`) and a nameidata structure (`nd`), check that the +> current directory has execute permission and then advance `name` +> over one component while updating `last_type` and `last`. If that +> was the final component, then return, otherwise call +> `walk_component()` and repeat from the top. + +`walk_component()` is even easier. If the component is `LAST_DOTS`, +it calls `handle_dots()` which does the necessary locking as already +described. If it finds a `LAST_NORM` component it first calls +"`lookup_fast()`" which only looks in the dcache, but will ask the +filesystem to revalidate the result if it is that sort of filesystem. +If that doesn't get a good result, it calls "`lookup_slow()`" which +takes the `i_mutex`, rechecks the cache, and then asks the filesystem +to find a definitive answer. Each of these will call +`follow_managed()` (as described below) to handle any mount points. + +In the absence of symbolic links, `walk_component()` creates a new +`struct path` containing a counted reference to the new dentry and a +reference to the new `vfsmount` which is only counted if it is +different from the previous `vfsmount`. It then calls +`path_to_nameidata()` to install the new `struct path` in the +`struct nameidata` and drop the unneeded references. + +This "hand-over-hand" sequencing of getting a reference to the new +dentry before dropping the reference to the previous dentry may +seem obvious, but is worth pointing out so that we will recognize its +analogue in the "RCU-walk" version. + +Handling the final component. +----------------------------- + +`link_path_walk()` only walks as far as setting `nd->last` and +`nd->last_type` to refer to the final component of the path. It does +not call `walk_component()` that last time. Handling that final +component remains for the caller to sort out. Those callers are +`path_lookupat()`, `path_parentat()`, `path_mountpoint()` and +`path_openat()` each of which handles the differing requirements of +different system calls. + +`path_parentat()` is clearly the simplest - it just wraps a little bit +of housekeeping around `link_path_walk()` and returns the parent +directory and final component to the caller. The caller will be either +aiming to create a name (via `filename_create()`) or remove or rename +a name (in which case `user_path_parent()` is used). They will use +`i_mutex` to exclude other changes while they validate and then +perform their operation. + +`path_lookupat()` is nearly as simple - it is used when an existing +object is wanted such as by `stat()` or `chmod()`. It essentially just +calls `walk_component()` on the final component through a call to +`lookup_last()`. `path_lookupat()` returns just the final dentry. + +`path_mountpoint()` handles the special case of unmounting which must +not try to revalidate the mounted filesystem. It effectively +contains, through a call to `mountpoint_last()`, an alternate +implementation of `lookup_slow()` which skips that step. This is +important when unmounting a filesystem that is inaccessible, such as +one provided by a dead NFS server. + +Finally `path_openat()` is used for the `open()` system call; it +contains, in support functions starting with "`do_last()`", all the +complexity needed to handle the different subtleties of O_CREAT (with +or without O_EXCL), final "`/`" characters, and trailing symbolic +links. We will revisit this in the final part of this series, which +focuses on those symbolic links. "`do_last()`" will sometimes, but +not always, take `i_mutex`, depending on what it finds. + +Each of these, or the functions which call them, need to be alert to +the possibility that the final component is not `LAST_NORM`. If the +goal of the lookup is to create something, then any value for +`last_type` other than `LAST_NORM` will result in an error. For +example if `path_parentat()` reports `LAST_DOTDOT`, then the caller +won't try to create that name. They also check for trailing slashes +by testing `last.name[last.len]`. If there is any character beyond +the final component, it must be a trailing slash. + +Revalidation and automounts +--------------------------- + +Apart from symbolic links, there are only two parts of the "REF-walk" +process not yet covered. One is the handling of stale cache entries +and the other is automounts. + +On filesystems that require it, the lookup routines will call the +`->d_revalidate()` dentry method to ensure that the cached information +is current. This will often confirm validity or update a few details +from a server. In some cases it may find that there has been change +further up the path and that something that was thought to be valid +previously isn't really. When this happens the lookup of the whole +path is aborted and retried with the "`LOOKUP_REVAL`" flag set. This +forces revalidation to be more thorough. We will see more details of +this retry process in the next article. + +Automount points are locations in the filesystem where an attempt to +lookup a name can trigger changes to how that lookup should be +handled, in particular by mounting a filesystem there. These are +covered in greater detail in autofs4.txt in the Linux documentation +tree, but a few notes specifically related to path lookup are in order +here. + +The Linux VFS has a concept of "managed" dentries which is reflected +in function names such as "`follow_managed()`". There are three +potentially interesting things about these dentries corresponding +to three different flags that might be set in `dentry->d_flags`: + +### `DCACHE_MANAGE_TRANSIT` ### + +If this flag has been set, then the filesystem has requested that the +`d_manage()` dentry operation be called before handling any possible +mount point. This can perform two particular services: + +It can block to avoid races. If an automount point is being +unmounted, the `d_manage()` function will usually wait for that +process to complete before letting the new lookup proceed and possibly +trigger a new automount. + +It can selectively allow only some processes to transit through a +mount point. When a server process is managing automounts, it may +need to access a directory without triggering normal automount +processing. That server process can identify itself to the `autofs` +filesystem, which will then give it a special pass through +`d_manage()` by returning `-EISDIR`. + +### `DCACHE_MOUNTED` ### + +This flag is set on every dentry that is mounted on. As Linux +supports multiple filesystem namespaces, it is possible that the +dentry may not be mounted on in *this* namespace, just in some +other. So this flag is seen as a hint, not a promise. + +If this flag is set, and `d_manage()` didn't return `-EISDIR`, +`lookup_mnt()` is called to examine the mount hash table (honoring the +`mount_lock` described earlier) and possibly return a new `vfsmount` +and a new `dentry` (both with counted references). + +### `DCACHE_NEED_AUTOMOUNT` ### + +If `d_manage()` allowed us to get this far, and `lookup_mnt()` didn't +find a mount point, then this flag causes the `d_automount()` dentry +operation to be called. + +The `d_automount()` operation can be arbitrarily complex and may +communicate with server processes etc. but it should ultimately either +report that there was an error, that there was nothing to mount, or +should provide an updated `struct path` with new `dentry` and `vfsmount`. + +In the latter case, `finish_automount()` will be called to safely +install the new mount point into the mount table. + +There is no new locking of import here and it is important that no +locks (only counted references) are held over this processing due to +the very real possibility of extended delays. +This will become more important next time when we examine RCU-walk +which is particularly sensitive to delays. + +RCU-walk - faster pathname lookup in Linux +========================================== + +RCU-walk is another algorithm for performing pathname lookup in Linux. +It is in many ways similar to REF-walk and the two share quite a bit +of code. The significant difference in RCU-walk is how it allows for +the possibility of concurrent access. + +We noted that REF-walk is complex because there are numerous details +and special cases. RCU-walk reduces this complexity by simply +refusing to handle a number of cases -- it instead falls back to +REF-walk. The difficulty with RCU-walk comes from a different +direction: unfamiliarity. The locking rules when depending on RCU are +quite different from traditional locking, so we will spend a little extra +time when we come to those. + +Clear demarcation of roles +-------------------------- + +The easiest way to manage concurrency is to forcibly stop any other +thread from changing the data structures that a given thread is +looking at. In cases where no other thread would even think of +changing the data and lots of different threads want to read at the +same time, this can be very costly. Even when using locks that permit +multiple concurrent readers, the simple act of updating the count of +the number of current readers can impose an unwanted cost. So the +goal when reading a shared data structure that no other process is +changing is to avoid writing anything to memory at all. Take no +locks, increment no counts, leave no footprints. + +The REF-walk mechanism already described certainly doesn't follow this +principle, but then it is really designed to work when there may well +be other threads modifying the data. RCU-walk, in contrast, is +designed for the common situation where there are lots of frequent +readers and only occasional writers. This may not be common in all +parts of the filesystem tree, but in many parts it will be. For the +other parts it is important that RCU-walk can quickly fall back to +using REF-walk. + +Pathname lookup always starts in RCU-walk mode but only remains there +as long as what it is looking for is in the cache and is stable. It +dances lightly down the cached filesystem image, leaving no footprints +and carefully watching where it is, to be sure it doesn't trip. If it +notices that something has changed or is changing, or if something +isn't in the cache, then it tries to stop gracefully and switch to +REF-walk. + +This stopping requires getting a counted reference on the current +`vfsmount` and `dentry`, and ensuring that these are still valid - +that a path walk with REF-walk would have found the same entries. +This is an invariant that RCU-walk must guarantee. It can only make +decisions, such as selecting the next step, that are decisions which +REF-walk could also have made if it were walking down the tree at the +same time. If the graceful stop succeeds, the rest of the path is +processed with the reliable, if slightly sluggish, REF-walk. If +RCU-walk finds it cannot stop gracefully, it simply gives up and +restarts from the top with REF-walk. + +This pattern of "try RCU-walk, if that fails try REF-walk" can be +clearly seen in functions like `filename_lookup()`, +`filename_parentat()`, `filename_mountpoint()`, +`do_filp_open()`, and `do_file_open_root()`. These five +correspond roughly to the four `path_`* functions we met earlier, +each of which calls `link_path_walk()`. The `path_*` functions are +called using different mode flags until a mode is found which works. +They are first called with `LOOKUP_RCU` set to request "RCU-walk". If +that fails with the error `ECHILD` they are called again with no +special flag to request "REF-walk". If either of those report the +error `ESTALE` a final attempt is made with `LOOKUP_REVAL` set (and no +`LOOKUP_RCU`) to ensure that entries found in the cache are forcibly +revalidated - normally entries are only revalidated if the filesystem +determines that they are too old to trust. + +The `LOOKUP_RCU` attempt may drop that flag internally and switch to +REF-walk, but will never then try to switch back to RCU-walk. Places +that trip up RCU-walk are much more likely to be near the leaves and +so it is very unlikely that there will be much, if any, benefit from +switching back. + +RCU and seqlocks: fast and light +-------------------------------- + +RCU is, unsurprisingly, critical to RCU-walk mode. The +`rcu_read_lock()` is held for the entire time that RCU-walk is walking +down a path. The particular guarantee it provides is that the key +data structures - dentries, inodes, super_blocks, and mounts - will +not be freed while the lock is held. They might be unlinked or +invalidated in one way or another, but the memory will not be +repurposed so values in various fields will still be meaningful. This +is the only guarantee that RCU provides; everything else is done using +seqlocks. + +As we saw above, REF-walk holds a counted reference to the current +dentry and the current vfsmount, and does not release those references +before taking references to the "next" dentry or vfsmount. It also +sometimes takes the `d_lock` spinlock. These references and locks are +taken to prevent certain changes from happening. RCU-walk must not +take those references or locks and so cannot prevent such changes. +Instead, it checks to see if a change has been made, and aborts or +retries if it has. + +To preserve the invariant mentioned above (that RCU-walk may only make +decisions that REF-walk could have made), it must make the checks at +or near the same places that REF-walk holds the references. So, when +REF-walk increments a reference count or takes a spinlock, RCU-walk +samples the status of a seqlock using `read_seqcount_begin()` or a +similar function. When REF-walk decrements the count or drops the +lock, RCU-walk checks if the sampled status is still valid using +`read_seqcount_retry()` or similar. + +However, there is a little bit more to seqlocks than that. If +RCU-walk accesses two different fields in a seqlock-protected +structure, or accesses the same field twice, there is no a priori +guarantee of any consistency between those accesses. When consistency +is needed - which it usually is - RCU-walk must take a copy and then +use `read_seqcount_retry()` to validate that copy. + +`read_seqcount_retry()` not only checks the sequence number, but also +imposes a memory barrier so that no memory-read instruction from +*before* the call can be delayed until *after* the call, either by the +CPU or by the compiler. A simple example of this can be seen in +`slow_dentry_cmp()` which, for filesystems which do not use simple +byte-wise name equality, calls into the filesystem to compare a name +against a dentry. The length and name pointer are copied into local +variables, then `read_seqcount_retry()` is called to confirm the two +are consistent, and only then is `->d_compare()` called. When +standard filename comparison is used, `dentry_cmp()` is called +instead. Notably it does _not_ use `read_seqcount_retry()`, but +instead has a large comment explaining why the consistency guarantee +isn't necessary. A subsequent `read_seqcount_retry()` will be +sufficient to catch any problem that could occur at this point. + +With that little refresher on seqlocks out of the way we can look at +the bigger picture of how RCU-walk uses seqlocks. + +### `mount_lock` and `nd->m_seq` ### + +We already met the `mount_lock` seqlock when REF-walk used it to +ensure that crossing a mount point is performed safely. RCU-walk uses +it for that too, but for quite a bit more. + +Instead of taking a counted reference to each `vfsmount` as it +descends the tree, RCU-walk samples the state of `mount_lock` at the +start of the walk and stores this initial sequence number in the +`struct nameidata` in the `m_seq` field. This one lock and one +sequence number are used to validate all accesses to all `vfsmounts`, +and all mount point crossings. As changes to the mount table are +relatively rare, it is reasonable to fall back on REF-walk any time +that any "mount" or "unmount" happens. + +`m_seq` is checked (using `read_seqretry()`) at the end of an RCU-walk +sequence, whether switching to REF-walk for the rest of the path or +when the end of the path is reached. It is also checked when stepping +down over a mount point (in `__follow_mount_rcu()`) or up (in +`follow_dotdot_rcu()`). If it is ever found to have changed, the +whole RCU-walk sequence is aborted and the path is processed again by +REF-walk. + +If RCU-walk finds that `mount_lock` hasn't changed then it can be sure +that, had REF-walk taken counted references on each vfsmount, the +results would have been the same. This ensures the invariant holds, +at least for vfsmount structures. + +### `dentry->d_seq` and `nd->seq`. ### + +In place of taking a count or lock on `d_reflock`, RCU-walk samples +the per-dentry `d_seq` seqlock, and stores the sequence number in the +`seq` field of the nameidata structure, so `nd->seq` should always be +the current sequence number of `nd->dentry`. This number needs to be +revalidated after copying, and before using, the name, parent, or +inode of the dentry. + +The handling of the name we have already looked at, and the parent is +only accessed in `follow_dotdot_rcu()` which fairly trivially follows +the required pattern, though it does so for three different cases. + +When not at a mount point, `d_parent` is followed and its `d_seq` is +collected. When we are at a mount point, we instead follow the +`mnt->mnt_mountpoint` link to get a new dentry and collect its +`d_seq`. Then, after finally finding a `d_parent` to follow, we must +check if we have landed on a mount point and, if so, must find that +mount point and follow the `mnt->mnt_root` link. This would imply a +somewhat unusual, but certainly possible, circumstance where the +starting point of the path lookup was in part of the filesystem that +was mounted on, and so not visible from the root. + +The inode pointer, stored in `->d_inode`, is a little more +interesting. The inode will always need to be accessed at least +twice, once to determine if it is NULL and once to verify access +permissions. Symlink handling requires a validated inode pointer too. +Rather than revalidating on each access, a copy is made on the first +access and it is stored in the `inode` field of `nameidata` from where +it can be safely accessed without further validation. + +`lookup_fast()` is the only lookup routine that is used in RCU-mode, +`lookup_slow()` being too slow and requiring locks. It is in +`lookup_fast()` that we find the important "hand over hand" tracking +of the current dentry. + +The current `dentry` and current `seq` number are passed to +`__d_lookup_rcu()` which, on success, returns a new `dentry` and a +new `seq` number. `lookup_fast()` then copies the inode pointer and +revalidates the new `seq` number. It then validates the old `dentry` +with the old `seq` number one last time and only then continues. This +process of getting the `seq` number of the new dentry and then +checking the `seq` number of the old exactly mirrors the process of +getting a counted reference to the new dentry before dropping that for +the old dentry which we saw in REF-walk. + +### No `inode->i_mutex` or even `rename_lock` ### + +A mutex is a fairly heavyweight lock that can only be taken when it is +permissible to sleep. As `rcu_read_lock()` forbids sleeping, +`inode->i_mutex` plays no role in RCU-walk. If some other thread does +take `i_mutex` and modifies the directory in a way that RCU-walk needs +to notice, the result will be either that RCU-walk fails to find the +dentry that it is looking for, or it will find a dentry which +`read_seqretry()` won't validate. In either case it will drop down to +REF-walk mode which can take whatever locks are needed. + +Though `rename_lock` could be used by RCU-walk as it doesn't require +any sleeping, RCU-walk doesn't bother. REF-walk uses `rename_lock` to +protect against the possibility of hash chains in the dcache changing +while they are being searched. This can result in failing to find +something that actually is there. When RCU-walk fails to find +something in the dentry cache, whether it is really there or not, it +already drops down to REF-walk and tries again with appropriate +locking. This neatly handles all cases, so adding extra checks on +rename_lock would bring no significant value. + +`unlazy walk()` and `complete_walk()` +------------------------------------- + +That "dropping down to REF-walk" typically involves a call to +`unlazy_walk()`, so named because "RCU-walk" is also sometimes +referred to as "lazy walk". `unlazy_walk()` is called when +following the path down to the current vfsmount/dentry pair seems to +have proceeded successfully, but the next step is problematic. This +can happen if the next name cannot be found in the dcache, if +permission checking or name revalidation couldn't be achieved while +the `rcu_read_lock()` is held (which forbids sleeping), if an +automount point is found, or in a couple of cases involving symlinks. +It is also called from `complete_walk()` when the lookup has reached +the final component, or the very end of the path, depending on which +particular flavor of lookup is used. + +Other reasons for dropping out of RCU-walk that do not trigger a call +to `unlazy_walk()` are when some inconsistency is found that cannot be +handled immediately, such as `mount_lock` or one of the `d_seq` +seqlocks reporting a change. In these cases the relevant function +will return `-ECHILD` which will percolate up until it triggers a new +attempt from the top using REF-walk. + +For those cases where `unlazy_walk()` is an option, it essentially +takes a reference on each of the pointers that it holds (vfsmount, +dentry, and possibly some symbolic links) and then verifies that the +relevant seqlocks have not been changed. If there have been changes, +it, too, aborts with `-ECHILD`, otherwise the transition to REF-walk +has been a success and the lookup process continues. + +Taking a reference on those pointers is not quite as simple as just +incrementing a counter. That works to take a second reference if you +already have one (often indirectly through another object), but it +isn't sufficient if you don't actually have a counted reference at +all. For `dentry->d_lockref`, it is safe to increment the reference +counter to get a reference unless it has been explicitly marked as +"dead" which involves setting the counter to `-128`. +`lockref_get_not_dead()` achieves this. + +For `mnt->mnt_count` it is safe to take a reference as long as +`mount_lock` is then used to validate the reference. If that +validation fails, it may *not* be safe to just drop that reference in +the standard way of calling `mnt_put()` - an unmount may have +progressed too far. So the code in `legitimize_mnt()`, when it +finds that the reference it got might not be safe, checks the +`MNT_SYNC_UMOUNT` flag to determine if a simple `mnt_put()` is +correct, or if it should just decrement the count and pretend none of +this ever happened. + +Taking care in filesystems +--------------------------- + +RCU-walk depends almost entirely on cached information and often will +not call into the filesystem at all. However there are two places, +besides the already-mentioned component-name comparison, where the +file system might be included in RCU-walk, and it must know to be +careful. + +If the filesystem has non-standard permission-checking requirements - +such as a networked filesystem which may need to check with the server +- the `i_op->permission` interface might be called during RCU-walk. +In this case an extra "`MAY_NOT_BLOCK`" flag is passed so that it +knows not to sleep, but to return `-ECHILD` if it cannot complete +promptly. `i_op->permission` is given the inode pointer, not the +dentry, so it doesn't need to worry about further consistency checks. +However if it accesses any other filesystem data structures, it must +ensure they are safe to be accessed with only the `rcu_read_lock()` +held. This typically means they must be freed using `kfree_rcu()` or +similar. + +[`READ_ONCE()`]: https://lwn.net/Articles/624126/ + +If the filesystem may need to revalidate dcache entries, then +`d_op->d_revalidate` may be called in RCU-walk too. This interface +*is* passed the dentry but does not have access to the `inode` or the +`seq` number from the `nameidata`, so it needs to be extra careful +when accessing fields in the dentry. This "extra care" typically +involves using `ACCESS_ONCE()` or the newer [`READ_ONCE()`] to access +fields, and verifying the result is not NULL before using it. This +pattern can be see in `nfs_lookup_revalidate()`. + +A pair of patterns +------------------ + +In various places in the details of REF-walk and RCU-walk, and also in +the big picture, there are a couple of related patterns that are worth +being aware of. + +The first is "try quickly and check, if that fails try slowly". We +can see that in the high-level approach of first trying RCU-walk and +then trying REF-walk, and in places where `unlazy_walk()` is used to +switch to REF-walk for the rest of the path. We also saw it earlier +in `dget_parent()` when following a "`..`" link. It tries a quick way +to get a reference, then falls back to taking locks if needed. + +The second pattern is "try quickly and check, if that fails try +again - repeatedly". This is seen with the use of `rename_lock` and +`mount_lock` in REF-walk. RCU-walk doesn't make use of this pattern - +if anything goes wrong it is much safer to just abort and try a more +sedate approach. + +The emphasis here is "try quickly and check". It should probably be +"try quickly _and carefully,_ then check". The fact that checking is +needed is a reminder that the system is dynamic and only a limited +number of things are safe at all. The most likely cause of errors in +this whole process is assuming something is safe when in reality it +isn't. Careful consideration of what exactly guarantees the safety of +each access is sometimes necessary. + +A walk among the symlinks +========================= + +There are several basic issues that we will examine to understand the +handling of symbolic links: the symlink stack, together with cache +lifetimes, will help us understand the overall recursive handling of +symlinks and lead to the special care needed for the final component. +Then a consideration of access-time updates and summary of the various +flags controlling lookup will finish the story. + +The symlink stack +----------------- + +There are only two sorts of filesystem objects that can usefully +appear in a path prior to the final component: directories and symlinks. +Handling directories is quite straightforward: the new directory +simply becomes the starting point at which to interpret the next +component on the path. Handling symbolic links requires a bit more +work. + +Conceptually, symbolic links could be handled by editing the path. If +a component name refers to a symbolic link, then that component is +replaced by the body of the link and, if that body starts with a '/', +then all preceding parts of the path are discarded. This is what the +"`readlink -f`" command does, though it also edits out "`.`" and +"`..`" components. + +Directly editing the path string is not really necessary when looking +up a path, and discarding early components is pointless as they aren't +looked at anyway. Keeping track of all remaining components is +important, but they can of course be kept separately; there is no need +to concatenate them. As one symlink may easily refer to another, +which in turn can refer to a third, we may need to keep the remaining +components of several paths, each to be processed when the preceding +ones are completed. These path remnants are kept on a stack of +limited size. + +There are two reasons for placing limits on how many symlinks can +occur in a single path lookup. The most obvious is to avoid loops. +If a symlink referred to itself either directly or through +intermediaries, then following the symlink can never complete +successfully - the error `ELOOP` must be returned. Loops can be +detected without imposing limits, but limits are the simplest solution +and, given the second reason for restriction, quite sufficient. + +[outlined recently]: http://thread.gmane.org/gmane.linux.kernel/1934390/focus=1934550 + +The second reason was [outlined recently] by Linus: + +> Because it's a latency and DoS issue too. We need to react well to +> true loops, but also to "very deep" non-loops. It's not about memory +> use, it's about users triggering unreasonable CPU resources. + +Linux imposes a limit on the length of any pathname: `PATH_MAX`, which +is 4096. There are a number of reasons for this limit; not letting the +kernel spend too much time on just one path is one of them. With +symbolic links you can effectively generate much longer paths so some +sort of limit is needed for the same reason. Linux imposes a limit of +at most 40 symlinks in any one path lookup. It previously imposed a +further limit of eight on the maximum depth of recursion, but that was +raised to 40 when a separate stack was implemented, so there is now +just the one limit. + +The `nameidata` structure that we met in an earlier article contains a +small stack that can be used to store the remaining part of up to two +symlinks. In many cases this will be sufficient. If it isn't, a +separate stack is allocated with room for 40 symlinks. Pathname +lookup will never exceed that stack as, once the 40th symlink is +detected, an error is returned. + +It might seem that the name remnants are all that needs to be stored on +this stack, but we need a bit more. To see that, we need to move on to +cache lifetimes. + +Storage and lifetime of cached symlinks +--------------------------------------- + +Like other filesystem resources, such as inodes and directory +entries, symlinks are cached by Linux to avoid repeated costly access +to external storage. It is particularly important for RCU-walk to be +able to find and temporarily hold onto these cached entries, so that +it doesn't need to drop down into REF-walk. + +[object-oriented design pattern]: https://lwn.net/Articles/446317/ + +While each filesystem is free to make its own choice, symlinks are +typically stored in one of two places. Short symlinks are often +stored directly in the inode. When a filesystem allocates a `struct +inode` it typically allocates extra space to store private data (a +common [object-oriented design pattern] in the kernel). This will +sometimes include space for a symlink. The other common location is +in the page cache, which normally stores the content of files. The +pathname in a symlink can be seen as the content of that symlink and +can easily be stored in the page cache just like file content. + +When neither of these is suitable, the next most likely scenario is +that the filesystem will allocate some temporary memory and copy or +construct the symlink content into that memory whenever it is needed. + +When the symlink is stored in the inode, it has the same lifetime as +the inode which, itself, is protected by RCU or by a counted reference +on the dentry. This means that the mechanisms that pathname lookup +uses to access the dcache and icache (inode cache) safely are quite +sufficient for accessing some cached symlinks safely. In these cases, +the `i_link` pointer in the inode is set to point to wherever the +symlink is stored and it can be accessed directly whenever needed. + +When the symlink is stored in the page cache or elsewhere, the +situation is not so straightforward. A reference on a dentry or even +on an inode does not imply any reference on cached pages of that +inode, and even an `rcu_read_lock()` is not sufficient to ensure that +a page will not disappear. So for these symlinks the pathname lookup +code needs to ask the filesystem to provide a stable reference and, +significantly, needs to release that reference when it is finished +with it. + +Taking a reference to a cache page is often possible even in RCU-walk +mode. It does require making changes to memory, which is best avoided, +but that isn't necessarily a big cost and it is better than dropping +out of RCU-walk mode completely. Even filesystems that allocate +space to copy the symlink into can use `GFP_ATOMIC` to often successfully +allocate memory without the need to drop out of RCU-walk. If a +filesystem cannot successfully get a reference in RCU-walk mode, it +must return `-ECHILD` and `unlazy_walk()` will be called to return to +REF-walk mode in which the filesystem is allowed to sleep. + +The place for all this to happen is the `i_op->follow_link()` inode +method. In the present mainline code this is never actually called in +RCU-walk mode as the rewrite is not quite complete. It is likely that +in a future release this method will be passed an `inode` pointer when +called in RCU-walk mode so it both (1) knows to be careful, and (2) has the +validated pointer. Much like the `i_op->permission()` method we +looked at previously, `->follow_link()` would need to be careful that +all the data structures it references are safe to be accessed while +holding no counted reference, only the RCU lock. Though getting a +reference with `->follow_link()` is not yet done in RCU-walk mode, the +code is ready to release the reference when that does happen. + +This need to drop the reference to a symlink adds significant +complexity. It requires a reference to the inode so that the +`i_op->put_link()` inode operation can be called. In REF-walk, that +reference is kept implicitly through a reference to the dentry, so +keeping the `struct path` of the symlink is easiest. For RCU-walk, +the pointer to the inode is kept separately. To allow switching from +RCU-walk back to REF-walk in the middle of processing nested symlinks +we also need the seq number for the dentry so we can confirm that +switching back was safe. + +Finally, when providing a reference to a symlink, the filesystem also +provides an opaque "cookie" that must be passed to `->put_link()` so that it +knows what to free. This might be the allocated memory area, or a +pointer to the `struct page` in the page cache, or something else +completely. Only the filesystem knows what it is. + +In order for the reference to each symlink to be dropped when the walk completes, +whether in RCU-walk or REF-walk, the symlink stack needs to contain, +along with the path remnants: + +- the `struct path` to provide a reference to the inode in REF-walk +- the `struct inode *` to provide a reference to the inode in RCU-walk +- the `seq` to allow the path to be safely switched from RCU-walk to REF-walk +- the `cookie` that tells `->put_path()` what to put. + +This means that each entry in the symlink stack needs to hold five +pointers and an integer instead of just one pointer (the path +remnant). On a 64-bit system, this is about 40 bytes per entry; +with 40 entries it adds up to 1600 bytes total, which is less than +half a page. So it might seem like a lot, but is by no means +excessive. + +Note that, in a given stack frame, the path remnant (`name`) is not +part of the symlink that the other fields refer to. It is the remnant +to be followed once that symlink has been fully parsed. + +Following the symlink +--------------------- + +The main loop in `link_path_walk()` iterates seamlessly over all +components in the path and all of the non-final symlinks. As symlinks +are processed, the `name` pointer is adjusted to point to a new +symlink, or is restored from the stack, so that much of the loop +doesn't need to notice. Getting this `name` variable on and off the +stack is very straightforward; pushing and popping the references is +a little more complex. + +When a symlink is found, `walk_component()` returns the value `1` +(`0` is returned for any other sort of success, and a negative number +is, as usual, an error indicator). This causes `get_link()` to be +called; it then gets the link from the filesystem. Providing that +operation is successful, the old path `name` is placed on the stack, +and the new value is used as the `name` for a while. When the end of +the path is found (i.e. `*name` is `'\0'`) the old `name` is restored +off the stack and path walking continues. + +Pushing and popping the reference pointers (inode, cookie, etc.) is more +complex in part because of the desire to handle tail recursion. When +the last component of a symlink itself points to a symlink, we +want to pop the symlink-just-completed off the stack before pushing +the symlink-just-found to avoid leaving empty path remnants that would +just get in the way. + +It is most convenient to push the new symlink references onto the +stack in `walk_component()` immediately when the symlink is found; +`walk_component()` is also the last piece of code that needs to look at the +old symlink as it walks that last component. So it is quite +convenient for `walk_component()` to release the old symlink and pop +the references just before pushing the reference information for the +new symlink. It is guided in this by two flags; `WALK_GET`, which +gives it permission to follow a symlink if it finds one, and +`WALK_PUT`, which tells it to release the current symlink after it has been +followed. `WALK_PUT` is tested first, leading to a call to +`put_link()`. `WALK_GET` is tested subsequently (by +`should_follow_link()`) leading to a call to `pick_link()` which sets +up the stack frame. + +### Symlinks with no final component ### + +A pair of special-case symlinks deserve a little further explanation. +Both result in a new `struct path` (with mount and dentry) being set +up in the `nameidata`, and result in `get_link()` returning `NULL`. + +The more obvious case is a symlink to "`/`". All symlinks starting +with "`/`" are detected in `get_link()` which resets the `nameidata` +to point to the effective filesystem root. If the symlink only +contains "`/`" then there is nothing more to do, no components at all, +so `NULL` is returned to indicate that the symlink can be released and +the stack frame discarded. + +The other case involves things in `/proc` that look like symlinks but +aren't really. + +> $ ls -l /proc/self/fd/1 +> lrwx------ 1 neilb neilb 64 Jun 13 10:19 /proc/self/fd/1 -> /dev/pts/4 + +Every open file descriptor in any process is represented in `/proc` by +something that looks like a symlink. It is really a reference to the +target file, not just the name of it. When you `readlink` these +objects you get a name that might refer to the same file - unless it +has been unlinked or mounted over. When `walk_component()` follows +one of these, the `->follow_link()` method in "procfs" doesn't return +a string name, but instead calls `nd_jump_link()` which updates the +`nameidata` in place to point to that target. `->follow_link()` then +returns `NULL`. Again there is no final component and `get_link()` +reports this by leaving the `last_type` field of `nameidata` as +`LAST_BIND`. + +Following the symlink in the final component +-------------------------------------------- + +All this leads to `link_path_walk()` walking down every component, and +following all symbolic links it finds, until it reaches the final +component. This is just returned in the `last` field of `nameidata`. +For some callers, this is all they need; they want to create that +`last` name if it doesn't exist or give an error if it does. Other +callers will want to follow a symlink if one is found, and possibly +apply special handling to the last component of that symlink, rather +than just the last component of the original file name. These callers +potentially need to call `link_path_walk()` again and again on +successive symlinks until one is found that doesn't point to another +symlink. + +This case is handled by the relevant caller of `link_path_walk()`, such as +`path_lookupat()` using a loop that calls `link_path_walk()`, and then +handles the final component. If the final component is a symlink +that needs to be followed, then `trailing_symlink()` is called to set +things up properly and the loop repeats, calling `link_path_walk()` +again. This could loop as many as 40 times if the last component of +each symlink is another symlink. + +The various functions that examine the final component and possibly +report that it is a symlink are `lookup_last()`, `mountpoint_last()` +and `do_last()`, each of which use the same convention as +`walk_component()` of returning `1` if a symlink was found that needs +to be followed. + +Of these, `do_last()` is the most interesting as it is used for +opening a file. Part of `do_last()` runs with `i_mutex` held and this +part is in a separate function: `lookup_open()`. + +Explaining `do_last()` completely is beyond the scope of this article, +but a few highlights should help those interested in exploring the +code. + +1. Rather than just finding the target file, `do_last()` needs to open + it. If the file was found in the dcache, then `vfs_open()` is used for + this. If not, then `lookup_open()` will either call `atomic_open()` (if + the filesystem provides it) to combine the final lookup with the open, or + will perform the separate `lookup_real()` and `vfs_create()` steps + directly. In the later case the actual "open" of this newly found or + created file will be performed by `vfs_open()`, just as if the name + were found in the dcache. + +2. `vfs_open()` can fail with `-EOPENSTALE` if the cached information + wasn't quite current enough. Rather than restarting the lookup from + the top with `LOOKUP_REVAL` set, `lookup_open()` is called instead, + giving the filesystem a chance to resolve small inconsistencies. + If that doesn't work, only then is the lookup restarted from the top. + +3. An open with O_CREAT **does** follow a symlink in the final component, + unlike other creation system calls (like `mkdir`). So the sequence: + + > ln -s bar /tmp/foo + > echo hello > /tmp/foo + + will create a file called `/tmp/bar`. This is not permitted if + `O_EXCL` is set but otherwise is handled for an O_CREAT open much + like for a non-creating open: `should_follow_link()` returns `1`, and + so does `do_last()` so that `trailing_symlink()` gets called and the + open process continues on the symlink that was found. + +Updating the access time +------------------------ + +We previously said of RCU-walk that it would "take no locks, increment +no counts, leave no footprints." We have since seen that some +"footprints" can be needed when handling symlinks as a counted +reference (or even a memory allocation) may be needed. But these +footprints are best kept to a minimum. + +One other place where walking down a symlink can involve leaving +footprints in a way that doesn't affect directories is in updating access times. +In Unix (and Linux) every filesystem object has a "last accessed +time", or "`atime`". Passing through a directory to access a file +within is not considered to be an access for the purposes of +`atime`; only listing the contents of a directory can update its `atime`. +Symlinks are different it seems. Both reading a symlink (with `readlink()`) +and looking up a symlink on the way to some other destination can +update the atime on that symlink. + +[clearest statement]: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_08 + +It is not clear why this is the case; POSIX has little to say on the +subject. The [clearest statement] is that, if a particular implementation +updates a timestamp in a place not specified by POSIX, this must be +documented "except that any changes caused by pathname resolution need +not be documented". This seems to imply that POSIX doesn't really +care about access-time updates during pathname lookup. + +[Linux 1.3.87]: https://git.kernel.org/cgit/linux/kernel/git/history/history.git/diff/fs/ext2/symlink.c?id=f806c6db77b8eaa6e00dcfb6b567706feae8dbb8 + +An examination of history shows that prior to [Linux 1.3.87], the ext2 +filesystem, at least, didn't update atime when following a link. +Unfortunately we have no record of why that behavior was changed. + +In any case, access time must now be updated and that operation can be +quite complex. Trying to stay in RCU-walk while doing it is best +avoided. Fortunately it is often permitted to skip the `atime` +update. Because `atime` updates cause performance problems in various +areas, Linux supports the `relatime` mount option, which generally +limits the updates of `atime` to once per day on files that aren't +being changed (and symlinks never change once created). Even without +`relatime`, many filesystems record `atime` with a one-second +granularity, so only one update per second is required. + +It is easy to test if an `atime` update is needed while in RCU-walk +mode and, if it isn't, the update can be skipped and RCU-walk mode +continues. Only when an `atime` update is actually required does the +path walk drop down to REF-walk. All of this is handled in the +`get_link()` function. + +A few flags +----------- + +A suitable way to wrap up this tour of pathname walking is to list +the various flags that can be stored in the `nameidata` to guide the +lookup process. Many of these are only meaningful on the final +component, others reflect the current state of the pathname lookup. +And then there is `LOOKUP_EMPTY`, which doesn't fit conceptually with +the others. If this is not set, an empty pathname causes an error +very early on. If it is set, empty pathnames are not considered to be +an error. + +### Global state flags ### + +We have already met two global state flags: `LOOKUP_RCU` and +`LOOKUP_REVAL`. These select between one of three overall approaches +to lookup: RCU-walk, REF-walk, and REF-walk with forced revalidation. + +`LOOKUP_PARENT` indicates that the final component hasn't been reached +yet. This is primarily used to tell the audit subsystem the full +context of a particular access being audited. + +`LOOKUP_ROOT` indicates that the `root` field in the `nameidata` was +provided by the caller, so it shouldn't be released when it is no +longer needed. + +`LOOKUP_JUMPED` means that the current dentry was chosen not because +it had the right name but for some other reason. This happens when +following "`..`", following a symlink to `/`, crossing a mount point +or accessing a "`/proc/$PID/fd/$FD`" symlink. In this case the +filesystem has not been asked to revalidate the name (with +`d_revalidate()`). In such cases the inode may still need to be +revalidated, so `d_op->d_weak_revalidate()` is called if +`LOOKUP_JUMPED` is set when the look completes - which may be at the +final component or, when creating, unlinking, or renaming, at the penultimate component. + +### Final-component flags ### + +Some of these flags are only set when the final component is being +considered. Others are only checked for when considering that final +component. + +`LOOKUP_AUTOMOUNT` ensures that, if the final component is an automount +point, then the mount is triggered. Some operations would trigger it +anyway, but operations like `stat()` deliberately don't. `statfs()` +needs to trigger the mount but otherwise behaves a lot like `stat()`, so +it sets `LOOKUP_AUTOMOUNT`, as does "`quotactl()`" and the handling of +"`mount --bind`". + +`LOOKUP_FOLLOW` has a similar function to `LOOKUP_AUTOMOUNT` but for +symlinks. Some system calls set or clear it implicitly, while +others have API flags such as `AT_SYMLINK_FOLLOW` and +`UMOUNT_NOFOLLOW` to control it. Its effect is similar to +`WALK_GET` that we already met, but it is used in a different way. + +`LOOKUP_DIRECTORY` insists that the final component is a directory. +Various callers set this and it is also set when the final component +is found to be followed by a slash. + +Finally `LOOKUP_OPEN`, `LOOKUP_CREATE`, `LOOKUP_EXCL`, and +`LOOKUP_RENAME_TARGET` are not used directly by the VFS but are made +available to the filesystem and particularly the `->d_revalidate()` +method. A filesystem can choose not to bother revalidating too hard +if it knows that it will be asked to open or create the file soon. +These flags were previously useful for `->lookup()` too but with the +introduction of `->atomic_open()` they are less relevant there. + +End of the road +--------------- + +Despite its complexity, all this pathname lookup code appears to be +in good shape - various parts are certainly easier to understand now +than even a couple of releases ago. But that doesn't mean it is +"finished". As already mentioned, RCU-walk currently only follows +symlinks that are stored in the inode so, while it handles many ext4 +symlinks, it doesn't help with NFS, XFS, or Btrfs. That support +is not likely to be long delayed. diff --git a/Documentation/filesystems/path-lookup.txt b/Documentation/filesystems/path-lookup.txt index 3571667c7..9b8930f58 100644 --- a/Documentation/filesystems/path-lookup.txt +++ b/Documentation/filesystems/path-lookup.txt @@ -379,4 +379,4 @@ Papers and other documentation on dcache locking 2. http://lse.sourceforge.net/locking/dcache/dcache.html - +3. path-lookup.md in this directory. diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index 3a9d65c91..402ab99e4 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -175,6 +175,7 @@ read the file /proc/PID/status: VmLib: 1412 kB VmPTE: 20 kb VmSwap: 0 kB + HugetlbPages: 0 kB Threads: 1 SigQ: 0/28578 SigPnd: 0000000000000000 @@ -238,6 +239,7 @@ Table 1-2: Contents of the status files (as of 4.1) VmPTE size of page table entries VmPMD size of second level page tables VmSwap size of swap usage (the number of referred swapents) + HugetlbPages size of hugetlb memory portions Threads number of threads SigQ number of signals queued/max. number for queue SigPnd bitmap of pending signals for the thread @@ -424,12 +426,15 @@ Private_Clean: 0 kB Private_Dirty: 0 kB Referenced: 892 kB Anonymous: 0 kB +AnonHugePages: 0 kB +Shared_Hugetlb: 0 kB +Private_Hugetlb: 0 kB Swap: 0 kB SwapPss: 0 kB KernelPageSize: 4 kB MMUPageSize: 4 kB -Locked: 374 kB -VmFlags: rd ex mr mw me de +Locked: 0 kB +VmFlags: rd ex mr mw me dw the first of these lines shows the same information as is displayed for the mapping in /proc/PID/maps. The remaining lines show the size of the mapping @@ -449,9 +454,14 @@ accessed. "Anonymous" shows the amount of memory that does not belong to any file. Even a mapping associated with a file may contain anonymous pages: when MAP_PRIVATE and a page is modified, the file page is replaced by a private anonymous copy. -"Swap" shows how much would-be-anonymous memory is also used, but out on -swap. +"AnonHugePages" shows the ammount of memory backed by transparent hugepage. +"Shared_Hugetlb" and "Private_Hugetlb" show the ammounts of memory backed by +hugetlbfs page which is *not* counted in "RSS" or "PSS" field for historical +reasons. And these are not included in {Shared,Private}_{Clean,Dirty} field. +"Swap" shows how much would-be-anonymous memory is also used, but out on swap. "SwapPss" shows proportional swap share of this mapping. +"Locked" indicates whether the mapping is locked in memory or not. + "VmFlags" field deserves a separate description. This member represents the kernel flags associated with the particular virtual memory area in two letter encoded manner. The codes are the following: @@ -475,7 +485,6 @@ manner. The codes are the following: ac - area is accountable nr - swap space is not reserved for the area ht - area uses huge tlb pages - nl - non-linear mapping ar - architecture specific flag dd - do not include area into core dump sd - soft-dirty flag @@ -815,9 +824,6 @@ varies by architecture and compile options. The following is from a > cat /proc/meminfo -The "Locked" indicates whether the mapping is locked in memory or not. - - MemTotal: 16344972 kB MemFree: 13634064 kB MemAvailable: 14836172 kB @@ -1599,16 +1605,16 @@ Documentation/accounting. --------------------------------------------------------------- When a process is dumped, all anonymous memory is written to a core file as long as the size of the core file isn't limited. But sometimes we don't want -to dump some memory segments, for example, huge shared memory. Conversely, -sometimes we want to save file-backed memory segments into a core file, not -only the individual files. +to dump some memory segments, for example, huge shared memory or DAX. +Conversely, sometimes we want to save file-backed memory segments into a core +file, not only the individual files. /proc//coredump_filter allows you to customize which memory segments will be dumped when the process is dumped. coredump_filter is a bitmask of memory types. If a bit of the bitmask is set, memory segments of the corresponding memory type are dumped, otherwise they are not dumped. -The following 7 memory types are supported: +The following 9 memory types are supported: - (bit 0) anonymous private memory - (bit 1) anonymous shared memory - (bit 2) file-backed private memory @@ -1617,20 +1623,22 @@ The following 7 memory types are supported: effective only if the bit 2 is cleared) - (bit 5) hugetlb private memory - (bit 6) hugetlb shared memory + - (bit 7) DAX private memory + - (bit 8) DAX shared memory Note that MMIO pages such as frame buffer are never dumped and vDSO pages are always dumped regardless of the bitmask status. - Note bit 0-4 doesn't effect any hugetlb memory. hugetlb memory are only - effected by bit 5-6. + Note that bits 0-4 don't affect hugetlb or DAX memory. hugetlb memory is + only affected by bit 5-6, and DAX is only affected by bits 7-8. -Default value of coredump_filter is 0x23; this means all anonymous memory -segments and hugetlb private memory are dumped. +The default value of coredump_filter is 0x33; this means all anonymous memory +segments, ELF header pages and hugetlb private memory are dumped. If you don't want to dump all shared memory segments attached to pid 1234, -write 0x21 to the process's proc file. +write 0x31 to the process's proc file. - $ echo 0x21 > /proc/1234/coredump_filter + $ echo 0x31 > /proc/1234/coredump_filter When a new process is created, the process inherits the bitmask status from its parent. It is useful to set up coredump_filter before the program runs. diff --git a/Documentation/filesystems/sysfs-tagging.txt b/Documentation/filesystems/sysfs-tagging.txt index eb843e49c..c7c8e6438 100644 --- a/Documentation/filesystems/sysfs-tagging.txt +++ b/Documentation/filesystems/sysfs-tagging.txt @@ -17,13 +17,13 @@ the sysfs directory entries we ensure that we don't have conflicts in the directories and applications only see a limited set of the network devices. -Each sysfs directory entry may be tagged with zero or one -namespaces. A sysfs_dirent is augmented with a void *s_ns. If a -directory entry is tagged, then sysfs_dirent->s_flags will have a -flag between KOBJ_NS_TYPE_NONE and KOBJ_NS_TYPES, and s_ns will -point to the namespace to which it belongs. +Each sysfs directory entry may be tagged with a namespace via the +void *ns member of its kernfs_node. If a directory entry is tagged, +then kernfs_node->flags will have a flag between KOBJ_NS_TYPE_NONE +and KOBJ_NS_TYPES, and ns will point to the namespace to which it +belongs. -Each sysfs superblock's sysfs_super_info contains an array void +Each sysfs superblock's kernfs_super_info contains an array void *ns[KOBJ_NS_TYPES]. When a task in a tagging namespace kobj_nstype first mounts sysfs, a new superblock is created. It will be differentiated from other sysfs mounts by having its @@ -31,7 +31,7 @@ s_fs_info->ns[kobj_nstype] set to the new namespace. Note that through bind mounting and mounts propagation, a task can easily view the contents of other namespaces' sysfs mounts. Therefore, when a namespace exits, it will call kobj_ns_exit() to invalidate any -sysfs_dirent->s_ns pointers pointing to it. +kernfs_node->ns pointers pointing to it. Users of this interface: - define a type in the kobj_ns_type enumeration. diff --git a/Documentation/filesystems/sysfs.txt b/Documentation/filesystems/sysfs.txt index 9494afb94..24da7b32c 100644 --- a/Documentation/filesystems/sysfs.txt +++ b/Documentation/filesystems/sysfs.txt @@ -40,7 +40,7 @@ ancestors of object hierarchies; i.e. the subsystems the objects belong to. Sysfs internally stores a pointer to the kobject that implements a -directory in the sysfs_dirent object associated with the directory. In +directory in the kernfs_node object associated with the directory. In the past this kobject pointer has been used by sysfs to do reference counting directly on the kobject whenever the file is opened or closed. With the current sysfs implementation the kobject reference count is @@ -191,9 +191,10 @@ implementations: be called again, rearmed, to fill the buffer. - On write(2), sysfs expects the entire buffer to be passed during the - first write. Sysfs then passes the entire buffer to the store() - method. - + first write. Sysfs then passes the entire buffer to the store() method. + A terminating null is added after the data on stores. This makes + functions like sysfs_streq() safe to use. + When writing sysfs files, userspace processes should first read the entire file, modify the values it wishes to change, then write the entire buffer back. diff --git a/Documentation/fpga/fpga-mgr.txt b/Documentation/fpga/fpga-mgr.txt new file mode 100644 index 000000000..ce3e84fa9 --- /dev/null +++ b/Documentation/fpga/fpga-mgr.txt @@ -0,0 +1,171 @@ +FPGA Manager Core + +Alan Tull 2015 + +Overview +======== + +The FPGA manager core exports a set of functions for programming an FPGA with +an image. The API is manufacturer agnostic. All manufacturer specifics are +hidden away in a low level driver which registers a set of ops with the core. +The FPGA image data itself is very manufacturer specific, but for our purposes +it's just binary data. The FPGA manager core won't parse it. + + +API Functions: +============== + +To program the FPGA from a file or from a buffer: +------------------------------------------------- + + int fpga_mgr_buf_load(struct fpga_manager *mgr, u32 flags, + const char *buf, size_t count); + +Load the FPGA from an image which exists as a buffer in memory. + + int fpga_mgr_firmware_load(struct fpga_manager *mgr, u32 flags, + const char *image_name); + +Load the FPGA from an image which exists as a file. The image file must be on +the firmware search path (see the firmware class documentation). + +For both these functions, flags == 0 for normal full reconfiguration or +FPGA_MGR_PARTIAL_RECONFIG for partial reconfiguration. If successful, the FPGA +ends up in operating mode. Return 0 on success or a negative error code. + + +To get/put a reference to a FPGA manager: +----------------------------------------- + + struct fpga_manager *of_fpga_mgr_get(struct device_node *node); + + void fpga_mgr_put(struct fpga_manager *mgr); + +Given a DT node, get an exclusive reference to a FPGA manager or release +the reference. + + +To register or unregister the low level FPGA-specific driver: +------------------------------------------------------------- + + int fpga_mgr_register(struct device *dev, const char *name, + const struct fpga_manager_ops *mops, + void *priv); + + void fpga_mgr_unregister(struct device *dev); + +Use of these two functions is described below in "How To Support a new FPGA +device." + + +How to write an image buffer to a supported FPGA +================================================ +/* Include to get the API */ +#include + +/* device node that specifies the FPGA manager to use */ +struct device_node *mgr_node = ... + +/* FPGA image is in this buffer. count is size of the buffer. */ +char *buf = ... +int count = ... + +/* flags indicates whether to do full or partial reconfiguration */ +int flags = 0; + +int ret; + +/* Get exclusive control of FPGA manager */ +struct fpga_manager *mgr = of_fpga_mgr_get(mgr_node); + +/* Load the buffer to the FPGA */ +ret = fpga_mgr_buf_load(mgr, flags, buf, count); + +/* Release the FPGA manager */ +fpga_mgr_put(mgr); + + +How to write an image file to a supported FPGA +============================================== +/* Include to get the API */ +#include + +/* device node that specifies the FPGA manager to use */ +struct device_node *mgr_node = ... + +/* FPGA image is in this file which is in the firmware search path */ +const char *path = "fpga-image-9.rbf" + +/* flags indicates whether to do full or partial reconfiguration */ +int flags = 0; + +int ret; + +/* Get exclusive control of FPGA manager */ +struct fpga_manager *mgr = of_fpga_mgr_get(mgr_node); + +/* Get the firmware image (path) and load it to the FPGA */ +ret = fpga_mgr_firmware_load(mgr, flags, path); + +/* Release the FPGA manager */ +fpga_mgr_put(mgr); + + +How to support a new FPGA device +================================ +To add another FPGA manager, write a driver that implements a set of ops. The +probe function calls fpga_mgr_register(), such as: + +static const struct fpga_manager_ops socfpga_fpga_ops = { + .write_init = socfpga_fpga_ops_configure_init, + .write = socfpga_fpga_ops_configure_write, + .write_complete = socfpga_fpga_ops_configure_complete, + .state = socfpga_fpga_ops_state, +}; + +static int socfpga_fpga_probe(struct platform_device *pdev) +{ + struct device *dev = &pdev->dev; + struct socfpga_fpga_priv *priv; + int ret; + + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL); + if (!priv) + return -ENOMEM; + + /* ... do ioremaps, get interrupts, etc. and save + them in priv... */ + + return fpga_mgr_register(dev, "Altera SOCFPGA FPGA Manager", + &socfpga_fpga_ops, priv); +} + +static int socfpga_fpga_remove(struct platform_device *pdev) +{ + fpga_mgr_unregister(&pdev->dev); + + return 0; +} + + +The ops will implement whatever device specific register writes are needed to +do the programming sequence for this particular FPGA. These ops return 0 for +success or negative error codes otherwise. + +The programming sequence is: + 1. .write_init + 2. .write (may be called once or multiple times) + 3. .write_complete + +The .write_init function will prepare the FPGA to receive the image data. + +The .write function writes a buffer to the FPGA. The buffer may be contain the +whole FPGA image or may be a smaller chunk of an FPGA image. In the latter +case, this function is called multiple times for successive chunks. + +The .write_complete function is called after all the image has been written +to put the FPGA into operating mode. + +The ops include a .state function which will read the hardware FPGA manager and +return a code of type enum fpga_mgr_states. It doesn't result in a change in +hardware state. diff --git a/Documentation/gpio/board.txt b/Documentation/gpio/board.txt index f59c43b64..309217862 100644 --- a/Documentation/gpio/board.txt +++ b/Documentation/gpio/board.txt @@ -21,8 +21,8 @@ exact way to do it depends on the GPIO controller providing the GPIOs, see the device tree bindings for your controller. GPIOs mappings are defined in the consumer device's node, in a property named -either -gpios or -gpio, where is the function -the driver will request through gpiod_get(). For example: +-gpios, where is the function the driver will request +through gpiod_get(). For example: foo_device { compatible = "acme,foo"; @@ -31,9 +31,13 @@ the driver will request through gpiod_get(). For example: <&gpio 16 GPIO_ACTIVE_HIGH>, /* green */ <&gpio 17 GPIO_ACTIVE_HIGH>; /* blue */ - power-gpio = <&gpio 1 GPIO_ACTIVE_LOW>; + power-gpios = <&gpio 1 GPIO_ACTIVE_LOW>; }; +Properties named -gpio are also considered valid and old bindings use +it but are only supported for compatibility reasons and should not be used for +newer bindings since it has been deprecated. + This property will make GPIOs 15, 16 and 17 available to the driver under the "led" function, and GPIO 1 as the "power" GPIO: diff --git a/Documentation/gpio/driver.txt b/Documentation/gpio/driver.txt index 90d0f6aba..12a61948e 100644 --- a/Documentation/gpio/driver.txt +++ b/Documentation/gpio/driver.txt @@ -62,6 +62,11 @@ 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 +(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 drivers providing IRQs --------------------------- @@ -73,6 +78,13 @@ The IRQ portions of the GPIO block are implemented using an irqchip, using the header . So basically such a driver is utilizing two sub- systems simultaneously: gpio and irq. +RT_FULL: GPIO driver should not use spinlock_t or any sleepable APIs +(like PM runtime) as part of its irq_chip implementation on -RT. +- spinlock_t should be replaced with raw_spinlock_t [1]. +- If sleepable APIs have to be used, these can be done from the .irq_bus_lock() + and .irq_bus_unlock() callbacks, as these are the only slowpath callbacks + on an irqchip. Create the callbacks if needed [2]. + GPIO irqchips usually fall in one of two categories: * CHAINED GPIO irqchips: these are usually the type that is embedded on @@ -93,6 +105,38 @@ GPIO irqchips usually fall in one of two categories: Chained GPIO irqchips typically can NOT set the .can_sleep flag on struct gpio_chip, as everything happens directly in the callbacks. + RT_FULL: Note, chained IRQ handlers will not be forced threaded on -RT. + As result, spinlock_t or any sleepable APIs (like PM runtime) can't be used + in chained IRQ handler. + if required (and if it can't be converted to the nested threaded GPIO irqchip) + - chained IRQ handler can be converted to generic irq handler and this way + it will be threaded IRQ handler on -RT and hard IRQ handler on non-RT + (for example, see [3]). + Know W/A: The generic_handle_irq() is expected to be called with IRQ disabled, + so IRQ core will complain if it will be called from IRQ handler wich is forced + thread. The "fake?" raw lock can be used to W/A this problem: + + raw_spinlock_t wa_lock; + static irqreturn_t omap_gpio_irq_handler(int irq, void *gpiobank) + unsigned long wa_lock_flags; + raw_spin_lock_irqsave(&bank->wa_lock, wa_lock_flags); + generic_handle_irq(irq_find_mapping(bank->chip.irqdomain, bit)); + raw_spin_unlock_irqrestore(&bank->wa_lock, wa_lock_flags); + +* GENERIC CHAINED GPIO irqchips: these are the same as "CHAINED GPIO irqchips", + but chained IRQ handlers are not used. Instead GPIO IRQs dispatching is + performed by generic IRQ handler which is configured using request_irq(). + The GPIO irqchip will then end up calling something like this sequence in + its interrupt handler: + + static irqreturn_t gpio_rcar_irq_handler(int irq, void *dev_id) + for each detected GPIO IRQ + generic_handle_irq(...); + + RT_FULL: Such kind of handlers will be forced threaded on -RT, as result IRQ + core will complain that generic_handle_irq() is called with IRQ enabled and + the same W/A as for "CHAINED GPIO irqchips" can be applied. + * NESTED THREADED GPIO irqchips: these are off-chip GPIO expanders and any other GPIO irqchip residing on the other side of a sleeping bus. Of course such drivers that need slow bus traffic to read out IRQ status and similar, @@ -133,6 +177,13 @@ To use the helpers please keep the following in mind: the irqchip can initialize. E.g. .dev and .can_sleep shall be set up properly. +- Nominally set all handlers to handle_bad_irq() in the setup call and pass + handle_bad_irq() as flow handler parameter in gpiochip_irqchip_add() if it is + expected for GPIO driver that irqchip .set_type() callback have to be called + before using/enabling GPIO IRQ. Then set the handler to handle_level_irq() + and/or handle_edge_irq() in the irqchip .set_type() callback depending on + what your controller supports. + It is legal for any IRQ consumer to request an IRQ from any irqchip no matter if that is a combined GPIO+IRQ driver. The basic premise is that gpio_chip and irq_chip are orthogonal, and offering their services independent of each @@ -169,6 +220,31 @@ When implementing an irqchip inside a GPIO driver, these two functions should typically be called in the .startup() and .shutdown() callbacks from the irqchip. +Real-Time compliance for GPIO IRQ chips +--------------------------------------- + +Any provider of irqchips needs to be carefully tailored to support Real Time +preemption. It is desireable that all irqchips in the GPIO subsystem keep this +in mind and does the proper testing to assure they are real time-enabled. +So, pay attention on above " RT_FULL:" notes, please. +The following is a checklist to follow when preparing a driver for real +time-compliance: + +- ensure spinlock_t is not used as part irq_chip implementation; +- ensure that sleepable APIs are not used as part irq_chip implementation. + If sleepable APIs have to be used, these can be done from the .irq_bus_lock() + and .irq_bus_unlock() callbacks; +- Chained GPIO irqchips: ensure spinlock_t or any sleepable APIs are not used + from chained IRQ handler; +- Generic chained GPIO irqchips: take care about generic_handle_irq() calls and + apply corresponding W/A; +- Chained GPIO irqchips: get rid of chained IRQ handler and use generic irq + handler if possible :) +- regmap_mmio: Sry, but you are in trouble :( if MMIO regmap is used as for + GPIO IRQ chip implementation; +- Test your driver with the appropriate in-kernel real time test cases for both + level and edge IRQs. + Requesting self-owned GPIO pins ------------------------------- @@ -190,3 +266,7 @@ gpiochip_free_own_desc(). These functions must be used with care since they do not affect module use count. Do not use the functions to request gpio descriptors not owned by the calling driver. + +[1] http://www.spinics.net/lists/linux-omap/msg120425.html +[2] https://lkml.org/lkml/2015/9/25/494 +[3] https://lkml.org/lkml/2015/9/25/495 diff --git a/Documentation/gpio/sysfs.txt b/Documentation/gpio/sysfs.txt index 0700b5563..aeab01aa4 100644 --- a/Documentation/gpio/sysfs.txt +++ b/Documentation/gpio/sysfs.txt @@ -20,14 +20,14 @@ userspace GPIO can be used to determine system configuration data that standard kernels won't know about. And for some tasks, simple userspace GPIO drivers could be all that the system really needs. -DO NOT ABUSE SYFS TO CONTROL HARDWARE THAT HAS PROPER KERNEL DRIVERS. +DO NOT ABUSE SYSFS TO CONTROL HARDWARE THAT HAS PROPER KERNEL DRIVERS. PLEASE READ THE DOCUMENT NAMED "drivers-on-gpio.txt" IN THIS DOCUMENTATION DIRECTORY TO AVOID REINVENTING KERNEL WHEELS IN USERSPACE. I MEAN IT. REALLY. Paths in Sysfs -------------- -There are three kinds of entry in /sys/class/gpio: +There are three kinds of entries in /sys/class/gpio: - Control interfaces used to get userspace control over GPIOs; @@ -106,7 +106,7 @@ read-only attributes: "label" ... provided for diagnostics (not always unique) - "ngpio" ... how many GPIOs this manges (N to N + ngpio - 1) + "ngpio" ... how many GPIOs this manages (N to N + ngpio - 1) Board documentation should in most cases cover what GPIOs are used for what purposes. However, those numbers are not always stable; GPIOs on diff --git a/Documentation/hw_random.txt b/Documentation/hw_random.txt index 026e237bb..fce163490 100644 --- a/Documentation/hw_random.txt +++ b/Documentation/hw_random.txt @@ -3,7 +3,7 @@ Introduction: The hw_random framework is software that makes use of a special hardware feature on your CPU or motherboard, a Random Number Generator (RNG). The software has two parts: - a core providing the /dev/hw_random character device and its + a core providing the /dev/hwrng character device and its sysfs support, plus a hardware-specific driver that plugs into that core. @@ -14,7 +14,7 @@ Introduction: http://sourceforge.net/projects/gkernel/ - Those tools use /dev/hw_random to fill the kernel entropy pool, + Those tools use /dev/hwrng to fill the kernel entropy pool, which is used internally and exported by the /dev/urandom and /dev/random special files. @@ -32,13 +32,13 @@ Theory of operation: The rng-tools package uses such tests in "rngd", and lets you run them by hand with a "rngtest" utility. - /dev/hw_random is char device major 10, minor 183. + /dev/hwrng is char device major 10, minor 183. CLASS DEVICE. There is a /sys/class/misc/hw_random node with two unique attributes, "rng_available" and "rng_current". The "rng_available" attribute lists the hardware-specific drivers available, while "rng_current" lists the one which is currently - connected to /dev/hw_random. If your system has more than one + connected to /dev/hwrng. If your system has more than one RNG available, you may change the one used by writing a name from the list in "rng_available" into "rng_current". diff --git a/Documentation/hwmon/lm75 b/Documentation/hwmon/lm75 index 67691a0aa..ac95edfcd 100644 --- a/Documentation/hwmon/lm75 +++ b/Documentation/hwmon/lm75 @@ -42,8 +42,8 @@ Supported chips: Addresses scanned: none Datasheet: Publicly available at the ST website http://www.st.com/internet/analog/product/121769.jsp - * Texas Instruments TMP100, TMP101, TMP105, TMP112, TMP75, TMP175, TMP275 - Prefixes: 'tmp100', 'tmp101', 'tmp105', 'tmp112', 'tmp175', 'tmp75', 'tmp275' + * Texas Instruments TMP100, TMP101, TMP105, TMP112, TMP75, TMP75C, TMP175, TMP275 + Prefixes: 'tmp100', 'tmp101', 'tmp105', 'tmp112', 'tmp175', 'tmp75', 'tmp75c', 'tmp275' Addresses scanned: none Datasheet: Publicly available at the Texas Instruments website http://www.ti.com/product/tmp100 @@ -51,6 +51,7 @@ Supported chips: http://www.ti.com/product/tmp105 http://www.ti.com/product/tmp112 http://www.ti.com/product/tmp75 + http://www.ti.com/product/tmp75c http://www.ti.com/product/tmp175 http://www.ti.com/product/tmp275 * NXP LM75B diff --git a/Documentation/hwmon/max31790 b/Documentation/hwmon/max31790 new file mode 100644 index 000000000..855e62430 --- /dev/null +++ b/Documentation/hwmon/max31790 @@ -0,0 +1,37 @@ +Kernel driver max31790 +====================== + +Supported chips: + * Maxim MAX31790 + Prefix: 'max31790' + Addresses scanned: - + Datasheet: http://pdfserv.maximintegrated.com/en/ds/MAX31790.pdf + +Author: Il Han + + +Description +----------- + +This driver implements support for the Maxim MAX31790 chip. + +The MAX31790 controls the speeds of up to six fans using six independent +PWM outputs. The desired fan speeds (or PWM duty cycles) are written +through the I2C interface. The outputs drive "4-wire" fans directly, +or can be used to modulate the fan's power terminals using an external +pass transistor. + +Tachometer inputs monitor fan tachometer logic outputs for precise (+/-1%) +monitoring and control of fan RPM as well as detection of fan failure. +Six pins are dedicated tachometer inputs. Any of the six PWM outputs can +also be configured to serve as tachometer inputs. + + +Sysfs entries +------------- + +fan[1-12]_input RO fan tachometer speed in RPM +fan[1-12]_fault RO fan experienced fault +fan[1-6]_target RW desired fan speed in RPM +pwm[1-6]_enable RW regulator mode, 0=disabled, 1=manual mode, 2=rpm mode +pwm[1-6] RW fan target duty cycle (0-255) diff --git a/Documentation/hwmon/scpi-hwmon b/Documentation/hwmon/scpi-hwmon new file mode 100644 index 000000000..4cfcdf2d5 --- /dev/null +++ b/Documentation/hwmon/scpi-hwmon @@ -0,0 +1,33 @@ +Kernel driver scpi-hwmon +======================== + +Supported chips: + * Chips based on ARM System Control Processor Interface + Addresses scanned: - + Datasheet: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/index.html + +Author: Punit Agrawal + +Description +----------- + +This driver supports hardware monitoring for SoC's based on the ARM +System Control Processor (SCP) implementing the System Control +Processor Interface (SCPI). The following sensor types are supported +by the SCP - + + * temperature + * voltage + * current + * power + +The SCP interface provides an API to query the available sensors and +their values which are then exported to userspace by this driver. + +Usage Notes +----------- + +The driver relies on device tree node to indicate the presence of SCPI +support in the kernel. See +Documentation/devicetree/bindings/arm/arm,scpi.txt for details of the +devicetree node. \ No newline at end of file diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801 index 82f48f774..1bba38dd2 100644 --- a/Documentation/i2c/busses/i2c-i801 +++ b/Documentation/i2c/busses/i2c-i801 @@ -30,6 +30,9 @@ Supported adapters: * Intel BayTrail (SOC) * Intel Sunrise Point-H (PCH) * Intel Sunrise Point-LP (PCH) + * Intel DNV (SOC) + * Intel Broxton (SOC) + * Intel Lewisburg (PCH) Datasheets: Publicly available at the Intel website On Intel Patsburg and later chipsets, both the normal host SMBus controller diff --git a/Documentation/input/rotary-encoder.txt b/Documentation/input/rotary-encoder.txt index 5737e3590..46a74f0c5 100644 --- a/Documentation/input/rotary-encoder.txt +++ b/Documentation/input/rotary-encoder.txt @@ -9,8 +9,9 @@ peripherals with two wires. The outputs are phase-shifted by 90 degrees and by triggering on falling and rising edges, the turn direction can be determined. -Some encoders have both outputs low in stable states, whereas others also have -a stable state with both outputs high (half-period mode). +Some encoders have both outputs low in stable states, others also have +a stable state with both outputs high (half-period mode) and some have +a stable state in all steps (quarter-period mode). The phase diagram of these two outputs look like this: @@ -32,6 +33,9 @@ The phase diagram of these two outputs look like this: |<-->| one step (half-period mode) + |<>| + one step (quarter-period mode) + For more information, please see https://en.wikipedia.org/wiki/Rotary_encoder @@ -109,6 +113,7 @@ static struct rotary_encoder_platform_data my_rotary_encoder_info = { .inverted_a = 0, .inverted_b = 0, .half_period = false, + .wakeup_source = false, }; static struct platform_device rotary_encoder_device = { diff --git a/Documentation/input/userio.txt b/Documentation/input/userio.txt new file mode 100644 index 000000000..0880c0f44 --- /dev/null +++ b/Documentation/input/userio.txt @@ -0,0 +1,70 @@ + The userio Protocol + (c) 2015 Stephen Chandler Paul + Sponsored by Red Hat +-------------------------------------------------------------------------------- + +1. Introduction +~~~~~~~~~~~~~~~ + This module is intended to try to make the lives of input driver developers +easier by allowing them to test various serio devices (mainly the various +touchpads found on laptops) without having to have the physical device in front +of them. userio accomplishes this by allowing any privileged userspace program +to directly interact with the kernel's serio driver and control a virtual serio +port from there. + +2. Usage overview +~~~~~~~~~~~~~~~~~ + In order to interact with the userio kernel module, one simply opens the +/dev/userio character device in their applications. Commands are sent to the +kernel module by writing to the device, and any data received from the serio +driver is read as-is from the /dev/userio device. All of the structures and +macros you need to interact with the device are defined in and +. + +3. Command Structure +~~~~~~~~~~~~~~~~~~~~ + The struct used for sending commands to /dev/userio is as follows: + + struct userio_cmd { + __u8 type; + __u8 data; + }; + + "type" describes the type of command that is being sent. This can be any one +of the USERIO_CMD macros defined in . "data" is the argument +that goes along with the command. In the event that the command doesn't have an +argument, this field can be left untouched and will be ignored by the kernel. +Each command should be sent by writing the struct directly to the character +device. In the event that the command you send is invalid, an error will be +returned by the character device and a more descriptive error will be printed +to the kernel log. Only one command can be sent at a time, any additional data +written to the character device after the initial command will be ignored. + To close the virtual serio port, just close /dev/userio. + +4. Commands +~~~~~~~~~~~ + +4.1 USERIO_CMD_REGISTER +~~~~~~~~~~~~~~~~~~~~~~~ + Registers the port with the serio driver and begins transmitting data back and +forth. Registration can only be performed once a port type is set with +USERIO_CMD_SET_PORT_TYPE. Has no argument. + +4.2 USERIO_CMD_SET_PORT_TYPE +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + Sets the type of port we're emulating, where "data" is the port type being +set. Can be any of the macros from . For example: SERIO_8042 +would set the port type to be a normal PS/2 port. + +4.3 USERIO_CMD_SEND_INTERRUPT +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + Sends an interrupt through the virtual serio port to the serio driver, where +"data" is the interrupt data being sent. + +5. Userspace tools +~~~~~~~~~~~~~~~~~~ + The userio userspace tools are able to record PS/2 devices using some of the +debugging information from i8042, and play back the devices on /dev/userio. The +latest version of these tools can be found at: + + https://github.com/Lyude/ps2emu diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index 50b737402..4838bad42 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -81,6 +81,9 @@ Code Seq#(hex) Include File Comments 0x22 all scsi/sg.h '#' 00-3F IEEE 1394 Subsystem Block for the entire subsystem '$' 00-0F linux/perf_counter.h, linux/perf_event.h +'%' 00-0F include/uapi/linux/stm.h + System Trace Module subsystem + '&' 00-07 drivers/firewire/nosy-user.h '1' 00-1F PPS kit from Ulrich Windl @@ -149,6 +152,7 @@ Code Seq#(hex) Include File Comments 'K' all linux/kd.h 'L' 00-1F linux/loop.h conflict! 'L' 10-1F drivers/scsi/mpt2sas/mpt2sas_ctl.h conflict! +'L' 20-2F linux/lightnvm.h 'L' E0-FF linux/ppdd.h encrypted disk device driver 'M' all linux/soundcard.h conflict! diff --git a/Documentation/kasan.txt b/Documentation/kasan.txt index 0d32355a4..aa1e0c91e 100644 --- a/Documentation/kasan.txt +++ b/Documentation/kasan.txt @@ -1,36 +1,34 @@ -Kernel address sanitizer -================ +KernelAddressSanitizer (KASAN) +============================== 0. Overview =========== -Kernel Address sanitizer (KASan) is a dynamic memory error detector. It provides +KernelAddressSANitizer (KASAN) is a dynamic memory error detector. It provides a fast and comprehensive solution for finding use-after-free and out-of-bounds bugs. -KASan uses compile-time instrumentation for checking every memory access, -therefore you will need a gcc version of 4.9.2 or later. KASan could detect out -of bounds accesses to stack or global variables, but only if gcc 5.0 or later was -used to built the kernel. +KASAN uses compile-time instrumentation for checking every memory access, +therefore you will need a GCC version 4.9.2 or later. GCC 5.0 or later is +required for detection of out-of-bounds accesses to stack or global variables. -Currently KASan is supported only for x86_64 architecture and requires that the -kernel be built with the SLUB allocator. +Currently KASAN is supported only for x86_64 architecture and requires the +kernel to be built with the SLUB allocator. 1. Usage -========= +======== To enable KASAN configure kernel with: CONFIG_KASAN = y -and choose between CONFIG_KASAN_OUTLINE and CONFIG_KASAN_INLINE. Outline/inline -is compiler instrumentation types. The former produces smaller binary the -latter is 1.1 - 2 times faster. Inline instrumentation requires a gcc version -of 5.0 or later. +and choose between CONFIG_KASAN_OUTLINE and CONFIG_KASAN_INLINE. Outline and +inline are compiler instrumentation types. The former produces smaller binary +the latter is 1.1 - 2 times faster. Inline instrumentation requires a GCC +version 5.0 or later. Currently KASAN works only with the SLUB memory allocator. -For better bug detection and nicer report, enable CONFIG_STACKTRACE and put -at least 'slub_debug=U' in the boot cmdline. +For better bug detection and nicer reporting, enable CONFIG_STACKTRACE. To disable instrumentation for specific files or directories, add a line similar to the following to the respective kernel Makefile: @@ -42,7 +40,7 @@ similar to the following to the respective kernel Makefile: KASAN_SANITIZE := n 1.1 Error reports -========== +================= A typical out of bounds access report looks like this: @@ -119,14 +117,16 @@ Memory state around the buggy address: ffff8800693bc800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== -First sections describe slub object where bad access happened. -See 'SLUB Debug output' section in Documentation/vm/slub.txt for details. +The header of the report discribe what kind of bug happened and what kind of +access caused it. It's followed by the description of the accessed slub object +(see 'SLUB Debug output' section in Documentation/vm/slub.txt for details) and +the description of the accessed memory page. In the last section the report shows memory state around the accessed address. -Reading this part requires some more understanding of how KASAN works. +Reading this part requires some understanding of how KASAN works. -Each 8 bytes of memory are encoded in one shadow byte as accessible, -partially accessible, freed or they can be part of a redzone. +The state of each 8 aligned bytes of memory is encoded in one shadow byte. +Those 8 bytes can be accessible, partially accessible, freed or be a redzone. We use the following encoding for each shadow byte: 0 means that all 8 bytes of the corresponding memory region are accessible; number N (1 <= N <= 7) means that the first N bytes are accessible, and other (8 - N) bytes are not; @@ -139,7 +139,7 @@ the accessed address is partially accessible. 2. Implementation details -======================== +========================= From a high level, our approach to memory error detection is similar to that of kmemcheck: use shadow memory to record whether each byte of memory is safe diff --git a/Documentation/kbuild/Kconfig.recursion-issue-01 b/Documentation/kbuild/Kconfig.recursion-issue-01 new file mode 100644 index 000000000..e8877db04 --- /dev/null +++ b/Documentation/kbuild/Kconfig.recursion-issue-01 @@ -0,0 +1,57 @@ +# Simple Kconfig recursive issue +# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +# +# Test with: +# +# make KBUILD_KCONFIG=Documentation/kbuild/Kconfig.recursion-issue-01 allnoconfig +# +# This Kconfig file has a simple recursive dependency issue. In order to +# understand why this recursive dependency issue occurs lets consider what +# Kconfig needs to address. We iterate over what Kconfig needs to address +# by stepping through the questions it needs to address sequentially. +# +# * What values are possible for CORE? +# +# CORE_BELL_A_ADVANCED selects CORE, which means that it influences the values +# that are possible for CORE. So for example if CORE_BELL_A_ADVANCED is 'y', +# CORE must be 'y' too. +# +# * What influences CORE_BELL_A_ADVANCED ? +# +# As the name implies CORE_BELL_A_ADVANCED is an advanced feature of +# CORE_BELL_A so naturally it depends on CORE_BELL_A. So if CORE_BELL_A is 'y' +# we know CORE_BELL_A_ADVANCED can be 'y' too. +# +# * What influences CORE_BELL_A ? +# +# CORE_BELL_A depends on CORE, so CORE influences CORE_BELL_A. +# +# But that is a problem, because this means that in order to determine +# what values are possible for CORE we ended up needing to address questions +# regarding possible values of CORE itself again. Answering the original +# question of what are the possible values of CORE would make the kconfig +# tools run in a loop. When this happens Kconfig exits and complains about +# the "recursive dependency detected" error. +# +# Reading the Documentation/kbuild/Kconfig.recursion-issue-01 file it may be +# obvious that an easy to solution to this problem should just be the removal +# of the "select CORE" from CORE_BELL_A_ADVANCED as that is implicit already +# since CORE_BELL_A depends on CORE. Recursive dependency issues are not always +# so trivial to resolve, we provide another example below of practical +# implications of this recursive issue where the solution is perhaps not so +# easy to understand. Note that matching semantics on the dependency on +# CORE also consist of a solution to this recursive problem. + +mainmenu "Simple example to demo kconfig recursive dependency issue" + +config CORE + tristate + +config CORE_BELL_A + tristate + depends on CORE + +config CORE_BELL_A_ADVANCED + tristate + depends on CORE_BELL_A + select CORE diff --git a/Documentation/kbuild/Kconfig.recursion-issue-02 b/Documentation/kbuild/Kconfig.recursion-issue-02 new file mode 100644 index 000000000..b9fd56c4b --- /dev/null +++ b/Documentation/kbuild/Kconfig.recursion-issue-02 @@ -0,0 +1,63 @@ +# Cumulative Kconfig recursive issue +# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +# +# Test with: +# +# make KBUILD_KCONFIG=Documentation/kbuild/Kconfig.recursion-issue-02 allnoconfig +# +# The recursive limitations with Kconfig has some non intuitive implications on +# kconfig sematics which are documented here. One known practical implication +# of the recursive limitation is that drivers cannot negate features from other +# drivers if they share a common core requirement and use disjoint semantics to +# annotate those requirements, ie, some drivers use "depends on" while others +# use "select". For instance it means if a driver A and driver B share the same +# core requirement, and one uses "select" while the other uses "depends on" to +# annotate this, all features that driver A selects cannot now be negated by +# driver B. +# +# A perhaps not so obvious implication of this is that, if semantics on these +# core requirements are not carefully synced, as drivers evolve features +# they select or depend on end up becoming shared requirements which cannot be +# negated by other drivers. +# +# The example provided in Documentation/kbuild/Kconfig.recursion-issue-02 +# describes a simple driver core layout of example features a kernel might +# have. Let's assume we have some CORE functionality, then the kernel has a +# series of bells and whistles it desires to implement, its not so advanced so +# it only supports bells at this time: CORE_BELL_A and CORE_BELL_B. If +# CORE_BELL_A has some advanced feature CORE_BELL_A_ADVANCED which selects +# CORE_BELL_A then CORE_BELL_A ends up becoming a common BELL feature which +# other bells in the system cannot negate. The reason for this issue is +# due to the disjoint use of semantics on expressing each bell's relationship +# with CORE, one uses "depends on" while the other uses "select". Another +# more important reason is that kconfig does not check for dependencies listed +# under 'select' for a symbol, when such symbols are selected kconfig them +# as mandatory required symbols. For more details on the heavy handed nature +# of select refer to Documentation/kbuild/Kconfig.select-break +# +# To fix this the "depends on CORE" must be changed to "select CORE", or the +# "select CORE" must be changed to "depends on CORE". +# +# For an example real world scenario issue refer to the attempt to remove +# "select FW_LOADER" [0], in the end the simple alternative solution to this +# problem consisted on matching semantics with newly introduced features. +# +# [0] http://lkml.kernel.org/r/1432241149-8762-1-git-send-email-mcgrof@do-not-panic.com + +mainmenu "Simple example to demo cumulative kconfig recursive dependency implication" + +config CORE + tristate + +config CORE_BELL_A + tristate + depends on CORE + +config CORE_BELL_A_ADVANCED + tristate + select CORE_BELL_A + +config CORE_BELL_B + tristate + depends on !CORE_BELL_A + select CORE diff --git a/Documentation/kbuild/Kconfig.select-break b/Documentation/kbuild/Kconfig.select-break new file mode 100644 index 000000000..365ceb342 --- /dev/null +++ b/Documentation/kbuild/Kconfig.select-break @@ -0,0 +1,33 @@ +# Select broken dependency issue +# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +# +# Test with: +# +# make KBUILD_KCONFIG=Documentation/kbuild/Kconfig.select-break menuconfig +# +# kconfig will not complain and enable this layout for configuration. This is +# currently a feature of kconfig, given select was designed to be heavy handed. +# Kconfig currently does not check the list of symbols listed on a symbol's +# "select" list, this is done on purpose to help load a set of known required +# symbols. Because of this use of select should be used with caution. An +# example of this issue is below. +# +# The option B and C are clearly contradicting with respect to A. +# However, when A is set, C can be set as well because Kconfig does not +# visit the dependencies of the select target (in this case B). And since +# Kconfig does not visit the dependencies, it breaks the dependencies of B +# (!A). + +mainmenu "Simple example to demo kconfig select broken dependency issue" + +config A + bool "CONFIG A" + +config B + bool "CONFIG B" + depends on !A + +config C + bool "CONFIG C" + depends on A + select B diff --git a/Documentation/kbuild/kconfig-language.txt b/Documentation/kbuild/kconfig-language.txt index 350f733bf..c52856da0 100644 --- a/Documentation/kbuild/kconfig-language.txt +++ b/Documentation/kbuild/kconfig-language.txt @@ -393,3 +393,164 @@ config FOO depends on BAR && m limits FOO to module (=m) or disabled (=n). + +Kconfig recursive dependency limitations +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If you've hit the Kconfig error: "recursive dependency detected" you've run +into a recursive dependency issue with Kconfig, a recursive dependency can be +summarized as a circular dependency. The kconfig tools need to ensure that +Kconfig files comply with specified configuration requirements. In order to do +that kconfig must determine the values that are possible for all Kconfig +symbols, this is currently not possible if there is a circular relation +between two or more Kconfig symbols. For more details refer to the "Simple +Kconfig recursive issue" subsection below. Kconfig does not do recursive +dependency resolution; this has a few implications for Kconfig file writers. +We'll first explain why this issues exists and then provide an example +technical limitation which this brings upon Kconfig developers. Eager +developers wishing to try to address this limitation should read the next +subsections. + +Simple Kconfig recursive issue +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Read: Documentation/kbuild/Kconfig.recursion-issue-01 + +Test with: + +make KBUILD_KCONFIG=Documentation/kbuild/Kconfig.recursion-issue-01 allnoconfig + +Cumulative Kconfig recursive issue +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Read: Documentation/kbuild/Kconfig.recursion-issue-02 + +Test with: + +make KBUILD_KCONFIG=Documentation/kbuild/Kconfig.recursion-issue-02 allnoconfig + +Practical solutions to kconfig recursive issue +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Developers who run into the recursive Kconfig issue have three options +at their disposal. We document them below and also provide a list of +historical issues resolved through these different solutions. + + a) Remove any superfluous "select FOO" or "depends on FOO" + b) Match dependency semantics: + b1) Swap all "select FOO" to "depends on FOO" or, + b2) Swap all "depends on FOO" to "select FOO" + +The resolution to a) can be tested with the sample Kconfig file +Documentation/kbuild/Kconfig.recursion-issue-01 through the removal +of the "select CORE" from CORE_BELL_A_ADVANCED as that is implicit already +since CORE_BELL_A depends on CORE. At times it may not be possible to remove +some dependency criteria, for such cases you can work with solution b). + +The two different resolutions for b) can be tested in the sample Kconfig file +Documentation/kbuild/Kconfig.recursion-issue-02. + +Below is a list of examples of prior fixes for these types of recursive issues; +all errors appear to involve one or more select's and one or more "depends on". + +commit fix +====== === +06b718c01208 select A -> depends on A +c22eacfe82f9 depends on A -> depends on B +6a91e854442c select A -> depends on A +118c565a8f2e select A -> select B +f004e5594705 select A -> depends on A +c7861f37b4c6 depends on A -> (null) +80c69915e5fb select A -> (null) (1) +c2218e26c0d0 select A -> depends on A (1) +d6ae99d04e1c select A -> depends on A +95ca19cf8cbf select A -> depends on A +8f057d7bca54 depends on A -> (null) +8f057d7bca54 depends on A -> select A +a0701f04846e select A -> depends on A +0c8b92f7f259 depends on A -> (null) +e4e9e0540928 select A -> depends on A (2) +7453ea886e87 depends on A > (null) (1) +7b1fff7e4fdf select A -> depends on A +86c747d2a4f0 select A -> depends on A +d9f9ab51e55e select A -> depends on A +0c51a4d8abd6 depends on A -> select A (3) +e98062ed6dc4 select A -> depends on A (3) +91e5d284a7f1 select A -> (null) + +(1) Partial (or no) quote of error. +(2) That seems to be the gist of that fix. +(3) Same error. + +Future kconfig work +~~~~~~~~~~~~~~~~~~~ + +Work on kconfig is welcomed on both areas of clarifying semantics and on +evaluating the use of a full SAT solver for it. A full SAT solver can be +desirable to enable more complex dependency mappings and / or queries, +for instance on possible use case for a SAT solver could be that of handling +the current known recursive dependency issues. It is not known if this would +address such issues but such evaluation is desirable. If support for a full SAT +solver proves too complex or that it cannot address recursive dependency issues +Kconfig should have at least clear and well defined semantics which also +addresses and documents limitations or requirements such as the ones dealing +with recursive dependencies. + +Further work on both of these areas is welcomed on Kconfig. We elaborate +on both of these in the next two subsections. + +Semantics of Kconfig +~~~~~~~~~~~~~~~~~~~~ + +The use of Kconfig is broad, Linux is now only one of Kconfig's users: +one study has completed a broad analysis of Kconfig use in 12 projects [0]. +Despite its widespread use, and although this document does a reasonable job +in documenting basic Kconfig syntax a more precise definition of Kconfig +semantics is welcomed. One project deduced Kconfig semantics through +the use of the xconfig configurator [1]. Work should be done to confirm if +the deduced semantics matches our intended Kconfig design goals. + +Having well defined semantics can be useful for tools for practical +evaluation of depenencies, for instance one such use known case was work to +express in boolean abstraction of the inferred semantics of Kconfig to +translate Kconfig logic into boolean formulas and run a SAT solver on this to +find dead code / features (always inactive), 114 dead features were found in +Linux using this methodology [1] (Section 8: Threats to validity). + +Confirming this could prove useful as Kconfig stands as one of the the leading +industrial variability modeling languages [1] [2]. Its study would help +evaluate practical uses of such languages, their use was only theoretical +and real world requirements were not well understood. As it stands though +only reverse engineering techniques have been used to deduce semantics from +variability modeling languages such as Kconfig [3]. + +[0] http://www.eng.uwaterloo.ca/~shshe/kconfig_semantics.pdf +[1] http://gsd.uwaterloo.ca/sites/default/files/vm-2013-berger.pdf +[2] http://gsd.uwaterloo.ca/sites/default/files/ase241-berger_0.pdf +[3] http://gsd.uwaterloo.ca/sites/default/files/icse2011.pdf + +Full SAT solver for Kconfig +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Although SAT solvers [0] haven't yet been used by Kconfig directly, as noted in +the previous subsection, work has been done however to express in boolean +abstraction the inferred semantics of Kconfig to translate Kconfig logic into +boolean formulas and run a SAT solver on it [1]. Another known related project +is CADOS [2] (former VAMOS [3]) and the tools, mainly undertaker [4], which has +been introduced first with [5]. The basic concept of undertaker is to exract +variability models from Kconfig, and put them together with a propositional +formula extracted from CPP #ifdefs and build-rules into a SAT solver in order +to find dead code, dead files, and dead symbols. If using a SAT solver is +desirable on Kconfig one approach would be to evaluate repurposing such efforts +somehow on Kconfig. There is enough interest from mentors of existing projects +to not only help advise how to integrate this work upstream but also help +maintain it long term. Interested developers should visit: + +http://kernelnewbies.org/KernelProjects/kconfig-sat + +[0] http://www.cs.cornell.edu/~sabhar/chapters/SATSolvers-KR-Handbook.pdf +[1] http://gsd.uwaterloo.ca/sites/default/files/vm-2013-berger.pdf +[2] https://cados.cs.fau.de +[3] https://vamos.cs.fau.de +[4] https://undertaker.cs.fau.de +[5] https://www4.cs.fau.de/Publications/2011/tartler_11_eurosys.pdf diff --git a/Documentation/kernel-docs.txt b/Documentation/kernel-docs.txt index eda1eb145..08913361e 100644 --- a/Documentation/kernel-docs.txt +++ b/Documentation/kernel-docs.txt @@ -696,18 +696,18 @@ Memory related patches, HOWTOs, links, mm developers... Don't miss it if you are interested in memory management development! - * Name: "Kernel Newbies IRC Channel" + * Name: "Kernel Newbies IRC Channel and Website" URL: http://www.kernelnewbies.org Keywords: IRC, newbies, channel, asking doubts. - Description: #kernelnewbies on irc.openprojects.net. From the web - page: "#kernelnewbies is an IRC network dedicated to the 'newbie' + Description: #kernelnewbies on irc.oftc.net. + #kernelnewbies is an IRC network dedicated to the 'newbie' kernel hacker. The audience mostly consists of people who are learning about the kernel, working on kernel projects or professional kernel hackers that want to help less seasoned kernel - people. [...] #kernelnewbies is on the Open Projects IRC Network, - try irc.openprojects.net or irc..openprojects.net as your - server and then /join #kernelnewbies". It also hosts articles, - documents, FAQs... + people. + #kernelnewbies is on the OFTC IRC Network. + Try irc.oftc.net as your server and then /join #kernelnewbies. + The kernelnewbies website also hosts articles, documents, FAQs... * Name: "linux-kernel mailing list archives and search engines" URL: http://vger.kernel.org/vger-lists.html diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index f81afd315..ffad13fdf 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -167,7 +167,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted. acpi= [HW,ACPI,X86,ARM64] Advanced Configuration and Power Interface - Format: { force | off | strict | noirq | rsdt } + Format: { force | off | strict | noirq | rsdt | + copy_dsdt } force -- enable ACPI if default was off off -- disable ACPI if default was on noirq -- do not use ACPI for IRQ routing @@ -789,8 +790,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted. is passed, kernel could allocate physical memory region above 4G, that cause second kernel crash on system that require some amount of low memory, e.g. swiotlb - requires at least 64M+32K low memory. Kernel would - try to allocate 72M below 4G automatically. + requires at least 64M+32K low memory, also enough extra + low memory is needed to make sure DMA buffers for 32-bit + devices won't run out. Kernel would try to allocate at + at least 256M below 4G automatically. This one let user to specify own low range under 4G for second kernel instead. 0: to disable low allocation. @@ -929,11 +932,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. The filter can be disabled or changed to another driver later using sysfs. - drm_kms_helper.edid_firmware=[:] - Broken monitors, graphic adapters and KVMs may - send no or incorrect EDID data sets. This parameter - allows to specify an EDID data set in the - /lib/firmware directory that is used instead. + drm_kms_helper.edid_firmware=[:][,[:]] + Broken monitors, graphic adapters, KVMs and EDIDless + panels may send no or incorrect EDID data sets. + This parameter allows to specify an EDID data sets + in the /lib/firmware directory that are used instead. Generic built-in EDID data sets are used, if one of edid/1024x768.bin, edid/1280x1024.bin, edid/1680x1050.bin, or edid/1920x1080.bin is given @@ -942,7 +945,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted. available in Documentation/EDID/HOWTO.txt. An EDID data set will only be used for a particular connector, if its name and a colon are prepended to the EDID - name. + name. Each connector may use a unique EDID data + set by separating the files with a comma. An EDID + data set with no connector name will be used for + any connectors not explicitly specified. dscc4.setup= [NET] @@ -971,6 +977,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted. earlycon= [KNL] Output early console device and options. + When used with no options, the early console is + determined by the stdout-path property in device + tree's chosen node. + cdns, Start an early, polled-mode console on a cadence serial port at the specified address. The cadence serial port @@ -1023,6 +1033,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted. serial port must already be setup and configured. Options are not yet supported. + lpuart, + lpuart32, + Use early console provided by Freescale LP UART driver + found on Freescale Vybrid and QorIQ LS1021A processors. + A valid base address must be provided, and the serial + port must already be setup and configured. + earlyprintk= [X86,SH,BLACKFIN,ARM,M68k] earlyprintk=vga earlyprintk=efi @@ -1094,6 +1111,21 @@ bytes respectively. Such letter suffixes can also be entirely omitted. you are really sure that your UEFI does sane gc and fulfills the spec otherwise your board may brick. + efi_fake_mem= nn[KMG]@ss[KMG]:aa[,nn[KMG]@ss[KMG]:aa,..] [EFI; X86] + Add arbitrary attribute to specific memory range by + updating original EFI memory map. + Region of memory which aa attribute is added to is + from ss to ss+nn. + If efi_fake_mem=2G@4G:0x10000,2G@0x10a0000000:0x10000 + is specified, EFI_MEMORY_MORE_RELIABLE(0x10000) + attribute is added to range 0x100000000-0x180000000 and + 0x10a0000000-0x1120000000. + + Using this parameter you can do debugging of EFI memmap + related feature. For example, you can do debugging of + Address Range Mirroring feature even if your box + doesn't support it. + eisa_irq_edge= [PARISC,HW] See header of drivers/parisc/eisa.c. @@ -1246,6 +1278,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. Format: such that (rxsize & ~0x1fffc0) == 0. Default: 1024 + hardlockup_all_cpu_backtrace= + [KNL] Should the hard-lockup detector generate + backtraces on all cpus. + Format: + hashdist= [KNL,NUMA] Large hashes allocated during boot are distributed across NUMA nodes. Defaults on for 64-bit NUMA, off otherwise. @@ -1553,6 +1590,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. nosid disable Source ID checking no_x2apic_optout BIOS x2APIC opt-out request will be ignored + nopost disable Interrupt Posting iomem= Disable strict checking of access to MMIO memory strict regions from userspace. @@ -2314,11 +2352,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted. nmi_watchdog= [KNL,BUGS=X86] Debugging features for SMP kernels Format: [panic,][nopanic,][num] Valid num: 0 or 1 - 0 - turn nmi_watchdog off - 1 - turn nmi_watchdog on + 0 - turn hardlockup detector in nmi_watchdog off + 1 - turn hardlockup detector in nmi_watchdog on When panic is specified, panic when an NMI watchdog timeout occurs (or 'nopanic' to override the opposite - default). + default). To disable both hard and soft lockup detectors, + please see 'nowatchdog'. This is useful when you use a panic=... timeout and need the box quickly up again. @@ -3074,9 +3113,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted. cache-to-cache transfer latencies. rcutree.rcu_fanout_leaf= [KNL] - Increase the number of CPUs assigned to each - leaf rcu_node structure. Useful for very large - systems. + Change the number of CPUs assigned to each + leaf rcu_node structure. Useful for very + large systems, which will choose the value 64, + and for NUMA systems with large remote-access + latencies, which will choose a value aligned + with the appropriate hardware boundaries. rcutree.jiffies_till_sched_qs= [KNL] Set required age in jiffies for a diff --git a/Documentation/kselftest.txt b/Documentation/kselftest.txt index a87d840ba..9bbbcdc59 100644 --- a/Documentation/kselftest.txt +++ b/Documentation/kselftest.txt @@ -54,6 +54,22 @@ To run the hotplug tests: - note that some tests will require root privileges. +Install selftests +================= + +You can use kselftest_install.sh tool installs selftests in default +location which is tools/testing/selftests/kselftest or an user specified +location. + +To install selftests in default location: + $ cd tools/testing/selftests + $ ./kselftest_install.sh + +To install selftests in an user specified location: + $ cd tools/testing/selftests + $ ./kselftest_install.sh install_dir + + Contributing new tests ====================== diff --git a/Documentation/locking/lockstat.txt b/Documentation/locking/lockstat.txt index 568bbbace..5786ad2cd 100644 --- a/Documentation/locking/lockstat.txt +++ b/Documentation/locking/lockstat.txt @@ -12,7 +12,7 @@ Because things like lock contention can severely impact performance. - HOW Lockdep already has hooks in the lock functions and maps lock instances to -lock classes. We build on that (see Documentation/lokcing/lockdep-design.txt). +lock classes. We build on that (see Documentation/locking/lockdep-design.txt). The graph below shows the relation between the lock functions and the various hooks therein. diff --git a/Documentation/locking/locktorture.txt b/Documentation/locking/locktorture.txt index 619f2bb13..a2ef3a929 100644 --- a/Documentation/locking/locktorture.txt +++ b/Documentation/locking/locktorture.txt @@ -52,6 +52,9 @@ torture_type Type of lock to torture. By default, only spinlocks will o "mutex_lock": mutex_lock() and mutex_unlock() pairs. + o "rtmutex_lock": rtmutex_lock() and rtmutex_unlock() + pairs. Kernel must have CONFIG_RT_MUTEX=y. + o "rwsem_lock": read/write down() and up() semaphore pairs. torture_runnable Start locktorture at boot time in the case where the diff --git a/Documentation/lockup-watchdogs.txt b/Documentation/lockup-watchdogs.txt index 22dd6af2e..4a6e33e1a 100644 --- a/Documentation/lockup-watchdogs.txt +++ b/Documentation/lockup-watchdogs.txt @@ -20,8 +20,9 @@ kernel mode for more than 10 seconds (see "Implementation" below for details), without letting other interrupts have a chance to run. Similarly to the softlockup case, the current stack trace is displayed upon detection and the system will stay locked up unless the default -behavior is changed, which can be done through a compile time knob, -"BOOTPARAM_HARDLOCKUP_PANIC", and a kernel parameter, "nmi_watchdog" +behavior is changed, which can be done through a sysctl, +'hardlockup_panic', a compile time knob, "BOOTPARAM_HARDLOCKUP_PANIC", +and a kernel parameter, "nmi_watchdog" (see "Documentation/kernel-parameters.txt" for details). The panic option can be used in combination with panic_timeout (this diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 2ba8461b0..aef948730 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -617,16 +617,16 @@ case what's actually required is: However, stores are not speculated. This means that ordering -is- provided for load-store control dependencies, as in the following example: - q = READ_ONCE_CTRL(a); + q = READ_ONCE(a); if (q) { WRITE_ONCE(b, p); } Control dependencies pair normally with other types of barriers. That -said, please note that READ_ONCE_CTRL() is not optional! Without the -READ_ONCE_CTRL(), the compiler might combine the load from 'a' with -other loads from 'a', and the store to 'b' with other stores to 'b', -with possible highly counterintuitive effects on ordering. +said, please note that READ_ONCE() is not optional! Without the +READ_ONCE(), the compiler might combine the load from 'a' with other +loads from 'a', and the store to 'b' with other stores to 'b', with +possible highly counterintuitive effects on ordering. Worse yet, if the compiler is able to prove (say) that the value of variable 'a' is always non-zero, it would be well within its rights @@ -636,15 +636,12 @@ as follows: q = a; b = p; /* BUG: Compiler and CPU can both reorder!!! */ -Finally, the READ_ONCE_CTRL() includes an smp_read_barrier_depends() -that DEC Alpha needs in order to respect control depedencies. - -So don't leave out the READ_ONCE_CTRL(). +So don't leave out the READ_ONCE(). It is tempting to try to enforce ordering on identical stores on both branches of the "if" statement as follows: - q = READ_ONCE_CTRL(a); + q = READ_ONCE(a); if (q) { barrier(); WRITE_ONCE(b, p); @@ -658,7 +655,7 @@ branches of the "if" statement as follows: Unfortunately, current compilers will transform this as follows at high optimization levels: - q = READ_ONCE_CTRL(a); + q = READ_ONCE(a); barrier(); WRITE_ONCE(b, p); /* BUG: No ordering vs. load from a!!! */ if (q) { @@ -688,7 +685,7 @@ memory barriers, for example, smp_store_release(): In contrast, without explicit memory barriers, two-legged-if control ordering is guaranteed only when the stores differ, for example: - q = READ_ONCE_CTRL(a); + q = READ_ONCE(a); if (q) { WRITE_ONCE(b, p); do_something(); @@ -697,14 +694,14 @@ ordering is guaranteed only when the stores differ, for example: do_something_else(); } -The initial READ_ONCE_CTRL() is still required to prevent the compiler -from proving the value of 'a'. +The initial READ_ONCE() is still required to prevent the compiler from +proving the value of 'a'. In addition, you need to be careful what you do with the local variable 'q', otherwise the compiler might be able to guess the value and again remove the needed conditional. For example: - q = READ_ONCE_CTRL(a); + q = READ_ONCE(a); if (q % MAX) { WRITE_ONCE(b, p); do_something(); @@ -717,7 +714,7 @@ If MAX is defined to be 1, then the compiler knows that (q % MAX) is equal to zero, in which case the compiler is within its rights to transform the above code into the following: - q = READ_ONCE_CTRL(a); + q = READ_ONCE(a); WRITE_ONCE(b, p); do_something_else(); @@ -728,7 +725,7 @@ is gone, and the barrier won't bring it back. Therefore, if you are relying on this ordering, you should make sure that MAX is greater than one, perhaps as follows: - q = READ_ONCE_CTRL(a); + q = READ_ONCE(a); BUILD_BUG_ON(MAX <= 1); /* Order load from a with store to b. */ if (q % MAX) { WRITE_ONCE(b, p); @@ -745,7 +742,7 @@ of the 'if' statement. You must also be careful not to rely too much on boolean short-circuit evaluation. Consider this example: - q = READ_ONCE_CTRL(a); + q = READ_ONCE(a); if (q || 1 > 0) WRITE_ONCE(b, 1); @@ -753,7 +750,7 @@ Because the first condition cannot fault and the second condition is always true, the compiler can transform this example as following, defeating control dependency: - q = READ_ONCE_CTRL(a); + q = READ_ONCE(a); WRITE_ONCE(b, 1); This example underscores the need to ensure that the compiler cannot @@ -767,7 +764,7 @@ x and y both being zero: CPU 0 CPU 1 ======================= ======================= - r1 = READ_ONCE_CTRL(x); r2 = READ_ONCE_CTRL(y); + r1 = READ_ONCE(x); r2 = READ_ONCE(y); if (r1 > 0) if (r2 > 0) WRITE_ONCE(y, 1); WRITE_ONCE(x, 1); @@ -796,11 +793,6 @@ site: https://www.cl.cam.ac.uk/~pes20/ppcmem/index.html. In summary: - (*) Control dependencies must be headed by READ_ONCE_CTRL(). - Or, as a much less preferable alternative, interpose - smp_read_barrier_depends() between a READ_ONCE() and the - control-dependent write. - (*) Control dependencies can order prior loads against later stores. However, they do -not- guarantee any other sort of ordering: Not prior loads against later loads, nor prior stores against @@ -816,14 +808,13 @@ In summary: between the prior load and the subsequent store, and this conditional must involve the prior load. If the compiler is able to optimize the conditional away, it will have also optimized - away the ordering. Careful use of READ_ONCE_CTRL() READ_ONCE(), - and WRITE_ONCE() can help to preserve the needed conditional. + away the ordering. Careful use of READ_ONCE() and WRITE_ONCE() + can help to preserve the needed conditional. (*) Control dependencies require that the compiler avoid reordering the - dependency into nonexistence. Careful use of READ_ONCE_CTRL() - or smp_read_barrier_depends() can help to preserve your control - dependency. Please see the Compiler Barrier section for more - information. + dependency into nonexistence. Careful use of READ_ONCE() or + atomic{,64}_read() can help to preserve your control dependency. + Please see the Compiler Barrier section for more information. (*) Control dependencies pair normally with other types of barriers. @@ -1710,6 +1701,17 @@ There are some more advanced barrier functions: operations" subsection for information on where to use these. + (*) lockless_dereference(); + This can be thought of as a pointer-fetch wrapper around the + smp_read_barrier_depends() data-dependency barrier. + + This is also similar to rcu_dereference(), but in cases where + object lifetime is handled by some mechanism other than RCU, for + example, when the objects removed only when the system goes down. + In addition, lockless_dereference() is used in some data structures + that can be used both with and without RCU. + + (*) dma_wmb(); (*) dma_rmb(); @@ -1789,7 +1791,6 @@ The Linux kernel has a number of locking constructs: (*) mutexes (*) semaphores (*) R/W semaphores - (*) RCU In all cases there are variants on "ACQUIRE" operations and "RELEASE" operations for each construct. These operations all imply certain barriers: diff --git a/Documentation/mic/mic_overview.txt b/Documentation/mic/mic_overview.txt index 1a2f2c8ec..73f44fc3e 100644 --- a/Documentation/mic/mic_overview.txt +++ b/Documentation/mic/mic_overview.txt @@ -28,6 +28,10 @@ The Symmetric Communication Interface (SCIF (pronounced as skiff)) is a low level communications API across PCIe currently implemented for MIC. More details are available at scif_overview.txt. +The Coprocessor State Management (COSM) driver on the host allows for +boot, shutdown and reset of Intel MIC devices. It communicates with a COSM +"client" driver on the MIC cards over SCIF to perform these functions. + Here is a block diagram of the various components described above. The virtio backends are situated on the host rather than the card given better single threaded performance for the host compared to MIC, the ability of @@ -51,19 +55,20 @@ the fact that the virtio block storage backend can only be on the host. | | | Virtio over PCIe IOCTLs | | | +--------------------------+ +-----------+ | | | +-----------+ -| MIC DMA | | +----------+ | +-----------+ | | MIC DMA | -| Driver | | | SCIF | | | SCIF | | | Driver | -+-----------+ | +----------+ | +-----------+ | +-----------+ - | | | | | | | -+---------------+ | +-----+-----+ | +-----+-----+ | +---------------+ -|MIC virtual Bus| | |SCIF HW Bus| | |SCIF HW BUS| | |MIC virtual Bus| -+---------------+ | +-----------+ | +-----+-----+ | +---------------+ - | | | | | | | - | +--------------+ | | | +---------------+ | - | |Intel MIC | | | | |Intel MIC | | - +---|Card Driver +----+ | | |Host Driver | | - +--------------+ | +----+---------------+-----+ - | | | +| MIC DMA | | +------+ | +------+ +------+ | | MIC DMA | +| Driver | | | SCIF | | | SCIF | | COSM | | | Driver | ++-----------+ | +------+ | +------+ +--+---+ | +-----------+ + | | | | | | | | ++---------------+ | +------+ | +--+---+ +--+---+ | +----------------+ +|MIC virtual Bus| | |SCIF | | |SCIF | | COSM | | |MIC virtual Bus | ++---------------+ | |HW Bus| | |HW Bus| | Bus | | +----------------+ + | | +------+ | +--+---+ +------+ | | + | | | | | | | | + | +-----------+---+ | | | +---------------+ | + | |Intel MIC | | | | |Intel MIC | | + +---|Card Driver | | | | |Host Driver | | + +------------+--------+ | +----+---------------+-----+ + | | | +-------------------------------------------------------------+ | | | PCIe Bus | diff --git a/Documentation/mic/mpssd/mpss b/Documentation/mic/mpssd/mpss index 582aad481..09ea90931 100755 --- a/Documentation/mic/mpssd/mpss +++ b/Documentation/mic/mpssd/mpss @@ -119,10 +119,10 @@ stop() # Wait for the cards to go offline for f in $sysfs/* do - while [ "`cat $f/state`" != "offline" ] + while [ "`cat $f/state`" != "ready" ] do sleep 1 - echo -e "Waiting for "`basename $f`" to go offline" + echo -e "Waiting for "`basename $f`" to become ready" done done diff --git a/Documentation/mic/mpssd/mpssd.c b/Documentation/mic/mpssd/mpssd.c index 3c5c379fc..aaeafa18d 100644 --- a/Documentation/mic/mpssd/mpssd.c +++ b/Documentation/mic/mpssd/mpssd.c @@ -43,7 +43,7 @@ #include #include -static void init_mic(struct mic_info *mic); +static void *init_mic(void *arg); static FILE *logfp; static struct mic_info mic_list; @@ -116,19 +116,18 @@ static struct { .num = htole16(MIC_VRING_ENTRIES), }, #if GSO_ENABLED - .host_features = htole32( + .host_features = htole32( 1 << VIRTIO_NET_F_CSUM | 1 << VIRTIO_NET_F_GSO | 1 << VIRTIO_NET_F_GUEST_TSO4 | 1 << VIRTIO_NET_F_GUEST_TSO6 | - 1 << VIRTIO_NET_F_GUEST_ECN | - 1 << VIRTIO_NET_F_GUEST_UFO), + 1 << VIRTIO_NET_F_GUEST_ECN), #else .host_features = 0, #endif }; -static const char *mic_config_dir = "/etc/sysconfig/mic"; +static const char *mic_config_dir = "/etc/mpss"; static const char *virtblk_backend = "VIRTBLK_BACKEND"; static struct { struct mic_device_desc dd; @@ -192,7 +191,7 @@ tap_configure(struct mic_info *mic, char *dev) return ret; } - snprintf(ipaddr, IFNAMSIZ, "172.31.%d.254/24", mic->id); + snprintf(ipaddr, IFNAMSIZ, "172.31.%d.254/24", mic->id + 1); pid = fork(); if (pid == 0) { @@ -255,8 +254,7 @@ static int tun_alloc(struct mic_info *mic, char *dev) return err; } #if GSO_ENABLED - offload = TUN_F_CSUM | TUN_F_TSO4 | TUN_F_TSO6 | - TUN_F_TSO_ECN | TUN_F_UFO; + offload = TUN_F_CSUM | TUN_F_TSO4 | TUN_F_TSO6 | TUN_F_TSO_ECN; err = ioctl(fd, TUNSETOFFLOAD, offload); if (err < 0) { @@ -332,7 +330,6 @@ static struct mic_device_desc *get_device_desc(struct mic_info *mic, int type) return d; } mpsslog("%s %s %d not found\n", mic->name, __func__, type); - assert(0); return NULL; } @@ -415,6 +412,13 @@ mic_virtio_copy(struct mic_info *mic, int fd, return ret; } +static inline unsigned _vring_size(unsigned int num, unsigned long align) +{ + return ((sizeof(struct vring_desc) * num + sizeof(__u16) * (3 + num) + + align - 1) & ~(align - 1)) + + sizeof(__u16) * 3 + sizeof(struct vring_used_elem) * num; +} + /* * This initialization routine requires at least one * vring i.e. vr0. vr1 is optional. @@ -426,8 +430,9 @@ init_vr(struct mic_info *mic, int fd, int type, int vr_size; char *va; - vr_size = PAGE_ALIGN(vring_size(MIC_VRING_ENTRIES, - MIC_VIRTIO_RING_ALIGN) + sizeof(struct _mic_vring_info)); + vr_size = PAGE_ALIGN(_vring_size(MIC_VRING_ENTRIES, + MIC_VIRTIO_RING_ALIGN) + + sizeof(struct _mic_vring_info)); va = mmap(NULL, MIC_DEVICE_PAGE_END + vr_size * num_vq, PROT_READ, MAP_SHARED, fd, 0); if (MAP_FAILED == va) { @@ -439,25 +444,25 @@ init_vr(struct mic_info *mic, int fd, int type, set_dp(mic, type, va); vr0->va = (struct mic_vring *)&va[MIC_DEVICE_PAGE_END]; vr0->info = vr0->va + - vring_size(MIC_VRING_ENTRIES, MIC_VIRTIO_RING_ALIGN); + _vring_size(MIC_VRING_ENTRIES, MIC_VIRTIO_RING_ALIGN); vring_init(&vr0->vr, MIC_VRING_ENTRIES, vr0->va, MIC_VIRTIO_RING_ALIGN); mpsslog("%s %s vr0 %p vr0->info %p vr_size 0x%x vring 0x%x ", __func__, mic->name, vr0->va, vr0->info, vr_size, - vring_size(MIC_VRING_ENTRIES, MIC_VIRTIO_RING_ALIGN)); + _vring_size(MIC_VRING_ENTRIES, MIC_VIRTIO_RING_ALIGN)); mpsslog("magic 0x%x expected 0x%x\n", le32toh(vr0->info->magic), MIC_MAGIC + type); assert(le32toh(vr0->info->magic) == MIC_MAGIC + type); if (vr1) { vr1->va = (struct mic_vring *) &va[MIC_DEVICE_PAGE_END + vr_size]; - vr1->info = vr1->va + vring_size(MIC_VRING_ENTRIES, + vr1->info = vr1->va + _vring_size(MIC_VRING_ENTRIES, MIC_VIRTIO_RING_ALIGN); vring_init(&vr1->vr, MIC_VRING_ENTRIES, vr1->va, MIC_VIRTIO_RING_ALIGN); mpsslog("%s %s vr1 %p vr1->info %p vr_size 0x%x vring 0x%x ", __func__, mic->name, vr1->va, vr1->info, vr_size, - vring_size(MIC_VRING_ENTRIES, MIC_VIRTIO_RING_ALIGN)); + _vring_size(MIC_VRING_ENTRIES, MIC_VIRTIO_RING_ALIGN)); mpsslog("magic 0x%x expected 0x%x\n", le32toh(vr1->info->magic), MIC_MAGIC + type + 1); assert(le32toh(vr1->info->magic) == MIC_MAGIC + type + 1); @@ -466,16 +471,21 @@ done: return va; } -static void +static int wait_for_card_driver(struct mic_info *mic, int fd, int type) { struct pollfd pollfd; int err; struct mic_device_desc *desc = get_device_desc(mic, type); + __u8 prev_status; + if (!desc) + return -ENODEV; + prev_status = desc->status; pollfd.fd = fd; mpsslog("%s %s Waiting .... desc-> type %d status 0x%x\n", mic->name, __func__, type, desc->status); + while (1) { pollfd.events = POLLIN; pollfd.revents = 0; @@ -487,8 +497,13 @@ wait_for_card_driver(struct mic_info *mic, int fd, int type) } if (pollfd.revents) { - mpsslog("%s %s Waiting... desc-> type %d status 0x%x\n", - mic->name, __func__, type, desc->status); + if (desc->status != prev_status) { + mpsslog("%s %s Waiting... desc-> type %d " + "status 0x%x\n", + mic->name, __func__, type, + desc->status); + prev_status = desc->status; + } if (desc->status & VIRTIO_CONFIG_S_DRIVER_OK) { mpsslog("%s %s poll.revents %d\n", mic->name, __func__, pollfd.revents); @@ -499,6 +514,7 @@ wait_for_card_driver(struct mic_info *mic, int fd, int type) } } } + return 0; } /* Spin till we have some descriptors */ @@ -575,9 +591,16 @@ virtio_net(void *arg) __func__, strerror(errno)); continue; } - if (!(desc->status & VIRTIO_CONFIG_S_DRIVER_OK)) - wait_for_card_driver(mic, mic->mic_net.virtio_net_fd, - VIRTIO_ID_NET); + if (!(desc->status & VIRTIO_CONFIG_S_DRIVER_OK)) { + err = wait_for_card_driver(mic, + mic->mic_net.virtio_net_fd, + VIRTIO_ID_NET); + if (err) { + mpsslog("%s %s %d Exiting...\n", + mic->name, __func__, __LINE__); + break; + } + } /* * Check if there is data to be read from TUN and write to * virtio net fd if there is. @@ -786,10 +809,16 @@ virtio_console(void *arg) strerror(errno)); continue; } - if (!(desc->status & VIRTIO_CONFIG_S_DRIVER_OK)) - wait_for_card_driver(mic, - mic->mic_console.virtio_console_fd, - VIRTIO_ID_CONSOLE); + if (!(desc->status & VIRTIO_CONFIG_S_DRIVER_OK)) { + err = wait_for_card_driver(mic, + mic->mic_console.virtio_console_fd, + VIRTIO_ID_CONSOLE); + if (err) { + mpsslog("%s %s %d Exiting...\n", + mic->name, __func__, __LINE__); + break; + } + } if (console_poll[MONITOR_FD].revents & POLLIN) { copy.iov = iov0; @@ -1048,8 +1077,9 @@ stop_virtblk(struct mic_info *mic) { int vr_size, ret; - vr_size = PAGE_ALIGN(vring_size(MIC_VRING_ENTRIES, - MIC_VIRTIO_RING_ALIGN) + sizeof(struct _mic_vring_info)); + vr_size = PAGE_ALIGN(_vring_size(MIC_VRING_ENTRIES, + MIC_VIRTIO_RING_ALIGN) + + sizeof(struct _mic_vring_info)); ret = munmap(mic->mic_virtblk.block_dp, MIC_DEVICE_PAGE_END + vr_size * virtblk_dev_page.dd.num_vq); if (ret < 0) @@ -1131,6 +1161,10 @@ write_status(int fd, __u8 *status) return ioctl(fd, MIC_VIRTIO_COPY_DESC, ©); } +#ifndef VIRTIO_BLK_T_GET_ID +#define VIRTIO_BLK_T_GET_ID 8 +#endif + static void * virtio_block(void *arg) { @@ -1297,12 +1331,7 @@ reset(struct mic_info *mic) mpsslog("%s: %s %d state %s\n", mic->name, __func__, __LINE__, state); - /* - * If the shutdown was initiated by OSPM, the state stays - * in "suspended" which is also a valid condition for reset. - */ - if ((!strcmp(state, "offline")) || - (!strcmp(state, "suspended"))) { + if (!strcmp(state, "ready")) { free(state); break; } @@ -1331,34 +1360,50 @@ get_mic_shutdown_status(struct mic_info *mic, char *shutdown_status) assert(0); }; -static int get_mic_state(struct mic_info *mic, char *state) +static int get_mic_state(struct mic_info *mic) { - if (!strcmp(state, "offline")) - return MIC_OFFLINE; - if (!strcmp(state, "online")) - return MIC_ONLINE; - if (!strcmp(state, "shutting_down")) - return MIC_SHUTTING_DOWN; - if (!strcmp(state, "reset_failed")) - return MIC_RESET_FAILED; - if (!strcmp(state, "suspending")) - return MIC_SUSPENDING; - if (!strcmp(state, "suspended")) - return MIC_SUSPENDED; - mpsslog("%s: BUG invalid state %s\n", mic->name, state); - /* Invalid state */ - assert(0); + char *state = NULL; + enum mic_states mic_state; + + while (!state) { + state = readsysfs(mic->name, "state"); + sleep(1); + } + mpsslog("%s: %s %d state %s\n", + mic->name, __func__, __LINE__, state); + + if (!strcmp(state, "ready")) { + mic_state = MIC_READY; + } else if (!strcmp(state, "booting")) { + mic_state = MIC_BOOTING; + } else if (!strcmp(state, "online")) { + mic_state = MIC_ONLINE; + } else if (!strcmp(state, "shutting_down")) { + mic_state = MIC_SHUTTING_DOWN; + } else if (!strcmp(state, "reset_failed")) { + mic_state = MIC_RESET_FAILED; + } else if (!strcmp(state, "resetting")) { + mic_state = MIC_RESETTING; + } else { + mpsslog("%s: BUG invalid state %s\n", mic->name, state); + assert(0); + } + + free(state); + return mic_state; }; static void mic_handle_shutdown(struct mic_info *mic) { #define SHUTDOWN_TIMEOUT 60 - int i = SHUTDOWN_TIMEOUT, ret, stat = 0; + int i = SHUTDOWN_TIMEOUT; char *shutdown_status; while (i) { shutdown_status = readsysfs(mic->name, "shutdown_status"); - if (!shutdown_status) + if (!shutdown_status) { + sleep(1); continue; + } mpsslog("%s: %s %d shutdown_status %s\n", mic->name, __func__, __LINE__, shutdown_status); switch (get_mic_shutdown_status(mic, shutdown_status)) { @@ -1377,94 +1422,110 @@ static void mic_handle_shutdown(struct mic_info *mic) i--; } reset: - ret = kill(mic->pid, SIGTERM); - mpsslog("%s: %s %d kill pid %d ret %d\n", - mic->name, __func__, __LINE__, - mic->pid, ret); - if (!ret) { - ret = waitpid(mic->pid, &stat, - WIFSIGNALED(stat)); - mpsslog("%s: %s %d waitpid ret %d pid %d\n", - mic->name, __func__, __LINE__, - ret, mic->pid); - } - if (ret == mic->pid) - reset(mic); + if (!i) + mpsslog("%s: %s %d timing out waiting for shutdown_status %s\n", + mic->name, __func__, __LINE__, shutdown_status); + reset(mic); } -static void * -mic_config(void *arg) +static int open_state_fd(struct mic_info *mic) { - struct mic_info *mic = (struct mic_info *)arg; - char *state = NULL; char pathname[PATH_MAX]; - int fd, ret; - struct pollfd ufds[1]; - char value[4096]; + int fd; snprintf(pathname, PATH_MAX - 1, "%s/%s/%s", MICSYSFSDIR, mic->name, "state"); fd = open(pathname, O_RDONLY); - if (fd < 0) { + if (fd < 0) mpsslog("%s: opening file %s failed %s\n", mic->name, pathname, strerror(errno)); - goto error; + return fd; +} + +static int block_till_state_change(int fd, struct mic_info *mic) +{ + struct pollfd ufds[1]; + char value[PAGE_SIZE]; + int ret; + + ufds[0].fd = fd; + ufds[0].events = POLLERR | POLLPRI; + ret = poll(ufds, 1, -1); + if (ret < 0) { + mpsslog("%s: %s %d poll failed %s\n", + mic->name, __func__, __LINE__, strerror(errno)); + return ret; + } + + ret = lseek(fd, 0, SEEK_SET); + if (ret < 0) { + mpsslog("%s: %s %d Failed to seek to 0: %s\n", + mic->name, __func__, __LINE__, strerror(errno)); + return ret; + } + + ret = read(fd, value, sizeof(value)); + if (ret < 0) { + mpsslog("%s: %s %d Failed to read sysfs entry: %s\n", + mic->name, __func__, __LINE__, strerror(errno)); + return ret; + } + + return 0; +} + +static void * +mic_config(void *arg) +{ + struct mic_info *mic = (struct mic_info *)arg; + int fd, ret, stat = 0; + + fd = open_state_fd(mic); + if (fd < 0) { + mpsslog("%s: %s %d open state fd failed %s\n", + mic->name, __func__, __LINE__, strerror(errno)); + goto exit; } do { - ret = lseek(fd, 0, SEEK_SET); + ret = block_till_state_change(fd, mic); if (ret < 0) { - mpsslog("%s: Failed to seek to file start '%s': %s\n", - mic->name, pathname, strerror(errno)); - goto close_error1; + mpsslog("%s: %s %d block_till_state_change error %s\n", + mic->name, __func__, __LINE__, strerror(errno)); + goto close_exit; } - ret = read(fd, value, sizeof(value)); - if (ret < 0) { - mpsslog("%s: Failed to read sysfs entry '%s': %s\n", - mic->name, pathname, strerror(errno)); - goto close_error1; - } -retry: - state = readsysfs(mic->name, "state"); - if (!state) - goto retry; - mpsslog("%s: %s %d state %s\n", - mic->name, __func__, __LINE__, state); - switch (get_mic_state(mic, state)) { + + switch (get_mic_state(mic)) { case MIC_SHUTTING_DOWN: mic_handle_shutdown(mic); - goto close_error; - case MIC_SUSPENDING: - mic->boot_on_resume = 1; - setsysfs(mic->name, "state", "suspend"); - mic_handle_shutdown(mic); - goto close_error; - case MIC_OFFLINE: + break; + case MIC_READY: + case MIC_RESET_FAILED: + ret = kill(mic->pid, SIGTERM); + mpsslog("%s: %s %d kill pid %d ret %d\n", + mic->name, __func__, __LINE__, + mic->pid, ret); + if (!ret) { + ret = waitpid(mic->pid, &stat, + WIFSIGNALED(stat)); + mpsslog("%s: %s %d waitpid ret %d pid %d\n", + mic->name, __func__, __LINE__, + ret, mic->pid); + } if (mic->boot_on_resume) { setsysfs(mic->name, "state", "boot"); mic->boot_on_resume = 0; } - break; + goto close_exit; default: break; } - free(state); - - ufds[0].fd = fd; - ufds[0].events = POLLERR | POLLPRI; - ret = poll(ufds, 1, -1); - if (ret < 0) { - mpsslog("%s: poll failed %s\n", - mic->name, strerror(errno)); - goto close_error1; - } } while (1); -close_error: - free(state); -close_error1: + +close_exit: close(fd); -error: +exit: init_mic(mic); pthread_exit(NULL); } @@ -1477,15 +1538,15 @@ set_cmdline(struct mic_info *mic) len = snprintf(buffer, PATH_MAX, "clocksource=tsc highres=off nohz=off "); - len += snprintf(buffer + len, PATH_MAX - len, + len += snprintf(buffer + len, PATH_MAX, "cpufreq_on;corec6_off;pc3_off;pc6_off "); - len += snprintf(buffer + len, PATH_MAX - len, + len += snprintf(buffer + len, PATH_MAX, "ifcfg=static;address,172.31.%d.1;netmask,255.255.255.0", - mic->id); + mic->id + 1); setsysfs(mic->name, "cmdline", buffer); mpsslog("%s: Command line: \"%s\"\n", mic->name, buffer); - snprintf(buffer, PATH_MAX, "172.31.%d.1", mic->id); + snprintf(buffer, PATH_MAX, "172.31.%d.1", mic->id + 1); mpsslog("%s: IPADDR: \"%s\"\n", mic->name, buffer); } @@ -1541,8 +1602,6 @@ set_log_buf_info(struct mic_info *mic) close(fd); } -static void init_mic(struct mic_info *mic); - static void change_virtblk_backend(int x, siginfo_t *siginfo, void *p) { @@ -1553,8 +1612,16 @@ change_virtblk_backend(int x, siginfo_t *siginfo, void *p) } static void -init_mic(struct mic_info *mic) +set_mic_boot_params(struct mic_info *mic) +{ + set_log_buf_info(mic); + set_cmdline(mic); +} + +static void * +init_mic(void *arg) { + struct mic_info *mic = (struct mic_info *)arg; struct sigaction ignore = { .sa_flags = 0, .sa_handler = SIG_IGN @@ -1564,7 +1631,7 @@ init_mic(struct mic_info *mic) .sa_sigaction = change_virtblk_backend, }; char buffer[PATH_MAX]; - int err; + int err, fd; /* * Currently, one virtio block device is supported for each MIC card @@ -1577,12 +1644,38 @@ init_mic(struct mic_info *mic) * the MIC daemon. */ sigaction(SIGUSR1, &ignore, NULL); +retry: + fd = open_state_fd(mic); + if (fd < 0) { + mpsslog("%s: %s %d open state fd failed %s\n", + mic->name, __func__, __LINE__, strerror(errno)); + sleep(2); + goto retry; + } + + if (mic->restart) { + snprintf(buffer, PATH_MAX, "boot"); + setsysfs(mic->name, "state", buffer); + mpsslog("%s restarting mic %d\n", + mic->name, mic->restart); + mic->restart = 0; + } + + while (1) { + while (block_till_state_change(fd, mic)) { + mpsslog("%s: %s %d block_till_state_change error %s\n", + mic->name, __func__, __LINE__, strerror(errno)); + sleep(2); + continue; + } + + if (get_mic_state(mic) == MIC_BOOTING) + break; + } mic->pid = fork(); switch (mic->pid) { case 0: - set_log_buf_info(mic); - set_cmdline(mic); add_virtio_device(mic, &virtcons_dev_page.dd); add_virtio_device(mic, &virtnet_dev_page.dd); err = pthread_create(&mic->mic_console.console_thread, NULL, @@ -1612,24 +1705,29 @@ init_mic(struct mic_info *mic) mic->name, mic->id, errno); break; default: - if (mic->restart) { - snprintf(buffer, PATH_MAX, "boot"); - setsysfs(mic->name, "state", buffer); - mpsslog("%s restarting mic %d\n", - mic->name, mic->restart); - mic->restart = 0; - } - pthread_create(&mic->config_thread, NULL, mic_config, mic); + err = pthread_create(&mic->config_thread, NULL, + mic_config, mic); + if (err) + mpsslog("%s mic_config pthread_create failed %s\n", + mic->name, strerror(err)); } + + return NULL; } static void start_daemon(void) { struct mic_info *mic; + int err; - for (mic = mic_list.next; mic != NULL; mic = mic->next) - init_mic(mic); + for (mic = mic_list.next; mic; mic = mic->next) { + set_mic_boot_params(mic); + err = pthread_create(&mic->init_thread, NULL, init_mic, mic); + if (err) + mpsslog("%s init_mic pthread_create failed %s\n", + mic->name, strerror(err)); + } while (1) sleep(60); diff --git a/Documentation/mic/mpssd/mpssd.h b/Documentation/mic/mpssd/mpssd.h index f5f18b15d..8bd64944a 100644 --- a/Documentation/mic/mpssd/mpssd.h +++ b/Documentation/mic/mpssd/mpssd.h @@ -86,6 +86,7 @@ struct mic_info { int id; char *name; pthread_t config_thread; + pthread_t init_thread; pid_t pid; struct mic_console_info mic_console; struct mic_net_info mic_net; diff --git a/Documentation/misc-devices/apds990x.txt b/Documentation/misc-devices/apds990x.txt index d5408cade..454d95d62 100644 --- a/Documentation/misc-devices/apds990x.txt +++ b/Documentation/misc-devices/apds990x.txt @@ -30,7 +30,7 @@ lead to false interrupt, but that doesn't harm. ALS contains 4 different gain steps. Driver automatically selects suitable gain step. After each measurement, reliability of the results -is estimated and new measurement is trigged if necessary. +is estimated and new measurement is triggered if necessary. Platform data can provide tuned values to the conversion formulas if values are known. Otherwise plain sensor default values are used. diff --git a/Documentation/misc-devices/isl29003 b/Documentation/misc-devices/isl29003 index c4ff5f38e..80b952fd3 100644 --- a/Documentation/misc-devices/isl29003 +++ b/Documentation/misc-devices/isl29003 @@ -29,7 +29,7 @@ Detection The ISL29003 does not have an ID register which could be used to identify it, so the detection routine will just try to read from the configured I2C -addess and consider the device to be present as soon as it ACKs the +address and consider the device to be present as soon as it ACKs the transfer. diff --git a/Documentation/misc-devices/max6875 b/Documentation/misc-devices/max6875 index 1e89ee3cc..2f2bd0b17 100644 --- a/Documentation/misc-devices/max6875 +++ b/Documentation/misc-devices/max6875 @@ -22,7 +22,7 @@ At reset, the MAX6875 reads the configuration EEPROM into its configuration registers. The chip then begins to operate according to the values in the registers. -The Maxim MAX6874 is a similar, mostly compatible device, with more intputs +The Maxim MAX6874 is a similar, mostly compatible device, with more inputs and outputs: vin gpi vout MAX6874 6 4 8 diff --git a/Documentation/mmc/mmc-dev-attrs.txt b/Documentation/mmc/mmc-dev-attrs.txt index 189bab092..caa555706 100644 --- a/Documentation/mmc/mmc-dev-attrs.txt +++ b/Documentation/mmc/mmc-dev-attrs.txt @@ -72,13 +72,3 @@ Note on raw_rpmb_size_mult: "raw_rpmb_size_mult" is a mutliple of 128kB block. RPMB size in byte is calculated by using the following equation: RPMB partition size = 128kB x raw_rpmb_size_mult - -SD/MMC/SDIO Clock Gating Attribute -================================== - -Read and write access is provided to following attribute. -This attribute appears only if CONFIG_MMC_CLKGATE is enabled. - - clkgate_delay Tune the clock gating delay with desired value in milliseconds. - -echo > /sys/class/mmc_host/mmcX/clkgate_delay diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt index fd1a1aad4..05fd83bb3 100644 --- a/Documentation/networking/can.txt +++ b/Documentation/networking/can.txt @@ -681,7 +681,7 @@ solution for a couple of reasons: addr.can_family = AF_CAN; addr.can_ifindex = ifr.ifr_ifindex; - connect(s, (struct sockaddr *)&addr, sizeof(addr)) + connect(s, (struct sockaddr *)&addr, sizeof(addr)); (..) @@ -1018,25 +1018,34 @@ solution for a couple of reasons: $ ip link set can0 type can help Usage: ip link set DEVICE type can - [ bitrate BITRATE [ sample-point SAMPLE-POINT] ] | - [ tq TQ prop-seg PROP_SEG phase-seg1 PHASE-SEG1 - phase-seg2 PHASE-SEG2 [ sjw SJW ] ] - - [ loopback { on | off } ] - [ listen-only { on | off } ] - [ triple-sampling { on | off } ] - - [ restart-ms TIME-MS ] - [ restart ] - - Where: BITRATE := { 1..1000000 } - SAMPLE-POINT := { 0.000..0.999 } - TQ := { NUMBER } - PROP-SEG := { 1..8 } - PHASE-SEG1 := { 1..8 } - PHASE-SEG2 := { 1..8 } - SJW := { 1..4 } - RESTART-MS := { 0 | NUMBER } + [ bitrate BITRATE [ sample-point SAMPLE-POINT] ] | + [ tq TQ prop-seg PROP_SEG phase-seg1 PHASE-SEG1 + phase-seg2 PHASE-SEG2 [ sjw SJW ] ] + + [ dbitrate BITRATE [ dsample-point SAMPLE-POINT] ] | + [ dtq TQ dprop-seg PROP_SEG dphase-seg1 PHASE-SEG1 + dphase-seg2 PHASE-SEG2 [ dsjw SJW ] ] + + [ loopback { on | off } ] + [ listen-only { on | off } ] + [ triple-sampling { on | off } ] + [ one-shot { on | off } ] + [ berr-reporting { on | off } ] + [ fd { on | off } ] + [ fd-non-iso { on | off } ] + [ presume-ack { on | off } ] + + [ restart-ms TIME-MS ] + [ restart ] + + Where: BITRATE := { 1..1000000 } + SAMPLE-POINT := { 0.000..0.999 } + TQ := { NUMBER } + PROP-SEG := { 1..8 } + PHASE-SEG1 := { 1..8 } + PHASE-SEG2 := { 1..8 } + SJW := { 1..4 } + RESTART-MS := { 0 | NUMBER } - Display CAN device details and statistics: @@ -1178,7 +1187,55 @@ solution for a couple of reasons: The CAN device MTU can be retrieved e.g. with a SIOCGIFMTU ioctl() syscall. N.B. CAN FD capable devices can also handle and send legacy CAN frames. - FIXME: Add details about the CAN FD controller configuration when available. + When configuring CAN FD capable CAN controllers an additional 'data' bitrate + has to be set. This bitrate for the data phase of the CAN FD frame has to be + at least the bitrate which was configured for the arbitration phase. This + second bitrate is specified analogue to the first bitrate but the bitrate + setting keywords for the 'data' bitrate start with 'd' e.g. dbitrate, + dsample-point, dsjw or dtq and similar settings. When a data bitrate is set + within the configuration process the controller option "fd on" can be + specified to enable the CAN FD mode in the CAN controller. This controller + option also switches the device MTU to 72 (CANFD_MTU). + + The first CAN FD specification presented as whitepaper at the International + CAN Conference 2012 needed to be improved for data integrity reasons. + Therefore two CAN FD implementations have to be distinguished today: + + - ISO compliant: The ISO 11898-1:2015 CAN FD implementation (default) + - non-ISO compliant: The CAN FD implementation following the 2012 whitepaper + + Finally there are three types of CAN FD controllers: + + 1. ISO compliant (fixed) + 2. non-ISO compliant (fixed, like the M_CAN IP core v3.0.1 in m_can.c) + 3. ISO/non-ISO CAN FD controllers (switchable, like the PEAK PCAN-USB FD) + + The current ISO/non-ISO mode is announced by the CAN controller driver via + netlink and displayed by the 'ip' tool (controller option FD-NON-ISO). + The ISO/non-ISO-mode can be altered by setting 'fd-non-iso {on|off}' for + switchable CAN FD controllers only. + + Example configuring 500 kbit/s arbitration bitrate and 4 Mbit/s data bitrate: + + $ ip link set can0 up type can bitrate 500000 sample-point 0.75 \ + dbitrate 4000000 dsample-point 0.8 fd on + $ ip -details link show can0 + 5: can0: mtu 72 qdisc pfifo_fast state UNKNOWN \ + mode DEFAULT group default qlen 10 + link/can promiscuity 0 + can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0 + bitrate 500000 sample-point 0.750 + tq 50 prop-seg 14 phase-seg1 15 phase-seg2 10 sjw 1 + pcan_usb_pro_fd: tseg1 1..64 tseg2 1..16 sjw 1..16 brp 1..1024 \ + brp-inc 1 + dbitrate 4000000 dsample-point 0.800 + dtq 12 dprop-seg 7 dphase-seg1 8 dphase-seg2 4 dsjw 1 + pcan_usb_pro_fd: dtseg1 1..16 dtseg2 1..8 dsjw 1..4 dbrp 1..1024 \ + dbrp-inc 1 + clock 80000000 + + Example when 'fd-non-iso on' is added on this switchable CAN FD adapter: + can state ERROR-ACTIVE (berr-counter tx 0 rx 0) restart-ms 0 6.7 Supported CAN hardware diff --git a/Documentation/networking/e100.txt b/Documentation/networking/e100.txt index f862cf3af..42ddbd4b5 100644 --- a/Documentation/networking/e100.txt +++ b/Documentation/networking/e100.txt @@ -181,17 +181,3 @@ For general information, go to the Intel support website at: If an issue is identified with the released source code on the supported kernel with a supported adapter, email the specific information related to the issue to e1000-devel@lists.sourceforge.net. - - -License -======= - -This software program is released under the terms of a license agreement -between you ('Licensee') and Intel. Do not use or load this software or any -associated materials (collectively, the 'Software') until you have carefully -read the full terms and conditions of the file COPYING located in this software -package. By loading or using the Software, you agree to the terms of this -Agreement. If you do not agree with the terms of this Agreement, do not install -or use the Software. - -* Other names and brands may be claimed as the property of others. diff --git a/Documentation/networking/filter.txt b/Documentation/networking/filter.txt index 135581f01..96da119a4 100644 --- a/Documentation/networking/filter.txt +++ b/Documentation/networking/filter.txt @@ -596,9 +596,9 @@ skb pointer). All constraints and restrictions from bpf_check_classic() apply before a conversion to the new layout is being done behind the scenes! Currently, the classic BPF format is being used for JITing on most of the -architectures. Only x86-64 performs JIT compilation from eBPF instruction set, -however, future work will migrate other JIT compilers as well, so that they -will profit from the very same benefits. +architectures. x86-64, aarch64 and s390x perform JIT compilation from eBPF +instruction set, however, future work will migrate other JIT compilers as well, +so that they will profit from the very same benefits. Some core changes of the new internal format: diff --git a/Documentation/networking/ieee802154.txt b/Documentation/networking/ieee802154.txt index 1700756af..aa69ccc48 100644 --- a/Documentation/networking/ieee802154.txt +++ b/Documentation/networking/ieee802154.txt @@ -7,11 +7,11 @@ Introduction The IEEE 802.15.4 working group focuses on standardization of bottom two layers: Medium Access Control (MAC) and Physical (PHY). And there are mainly two options available for upper layers: - - ZigBee - proprietary protocol from ZigBee Alliance - - 6LowPAN - IPv6 networking over low rate personal area networks + - ZigBee - proprietary protocol from the ZigBee Alliance + - 6LoWPAN - IPv6 networking over low rate personal area networks -The Linux-ZigBee project goal is to provide complete implementation -of IEEE 802.15.4 and 6LoWPAN protocols. IEEE 802.15.4 is a stack +The linux-wpan project goal is to provide a complete implementation +of the IEEE 802.15.4 and 6LoWPAN protocols. IEEE 802.15.4 is a stack of protocols for organizing Low-Rate Wireless Personal Area Networks. The stack is composed of three main parts: diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index ebe94f2ca..2ea4c45cf 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -384,6 +384,14 @@ tcp_mem - vector of 3 INTEGERs: min, pressure, max Defaults are calculated at boot time from amount of available memory. +tcp_min_rtt_wlen - INTEGER + The window length of the windowed min filter to track the minimum RTT. + A shorter window lets a flow more quickly pick up new (higher) + minimum RTT when it is moved to a longer path (e.g., due to traffic + engineering). A longer window makes the filter more resistant to RTT + inflations such as transient congestion. The unit is seconds. + Default: 300 + tcp_moderate_rcvbuf - BOOLEAN If set, TCP performs receive buffer auto-tuning, attempting to automatically size the buffer (no greater than tcp_rmem[2]) to @@ -425,6 +433,15 @@ tcp_orphan_retries - INTEGER you should think about lowering this value, such sockets may consume significant resources. Cf. tcp_max_orphans. +tcp_recovery - INTEGER + This value is a bitmap to enable various experimental loss recovery + features. + + RACK: 0x1 enables the RACK loss detection for fast detection of lost + retransmissions and tail drops. + + Default: 0x1 + tcp_reordering - INTEGER Initial reordering level of packets in a TCP stream. TCP stack can then dynamically adjust flow reordering level @@ -692,7 +709,7 @@ tcp_limit_output_bytes - INTEGER typical pfifo_fast qdiscs. tcp_limit_output_bytes limits the number of bytes on qdisc or device to reduce artificial RTT/cwnd and reduce bufferbloat. - Default: 131072 + Default: 262144 tcp_challenge_ack_limit - INTEGER Limits number of Challenge ACK sent per second, as recommended @@ -1199,7 +1216,8 @@ tag - INTEGER xfrm4_gc_thresh - INTEGER The threshold at which we will start garbage collecting for IPv4 destination cache entries. At twice this value the system will - refuse new allocations. + refuse new allocations. The value must be set below the flowcache + limit (4096 * number of online cpus) to take effect. igmp_link_local_mcast_reports - BOOLEAN Enable IGMP reports for link local multicast groups in the @@ -1645,7 +1663,8 @@ ratelimit - INTEGER xfrm6_gc_thresh - INTEGER The threshold at which we will start garbage collecting for IPv6 destination cache entries. At twice this value the system will - refuse new allocations. + refuse new allocations. The value must be set below the flowcache + limit (4096 * number of online cpus) to take effect. IPv6 Update by: diff --git a/Documentation/networking/ipvs-sysctl.txt b/Documentation/networking/ipvs-sysctl.txt index 3ba709531..e6b1c025f 100644 --- a/Documentation/networking/ipvs-sysctl.txt +++ b/Documentation/networking/ipvs-sysctl.txt @@ -157,6 +157,16 @@ expire_quiescent_template - BOOLEAN persistence template if it is to be used to schedule a new connection and the destination server is quiescent. +ignore_tunneled - BOOLEAN + 0 - disabled (default) + not 0 - enabled + + If set, ipvs will set the ipvs_property on all packets which are of + unrecognized protocols. This prevents us from routing tunneled + protocols like ipip, which is useful to prevent rescheduling + packets that have been tunneled to the ipvs host (i.e. to prevent + ipvs routing loops when ipvs is also acting as a real server). + nat_icmp_send - BOOLEAN 0 - disabled (default) not 0 - enabled diff --git a/Documentation/networking/l2tp.txt b/Documentation/networking/l2tp.txt index c74434de2..4650a00ed 100644 --- a/Documentation/networking/l2tp.txt +++ b/Documentation/networking/l2tp.txt @@ -213,15 +213,12 @@ To create an L2TPv3 ethernet pseudowire between local host 192.168.1.1 and peer 192.168.1.2, using IP addresses 10.5.1.1 and 10.5.1.2 for the tunnel endpoints:- -# modprobe l2tp_eth -# modprobe l2tp_netlink - # ip l2tp add tunnel tunnel_id 1 peer_tunnel_id 1 udp_sport 5000 \ udp_dport 5000 encap udp local 192.168.1.1 remote 192.168.1.2 # ip l2tp add session tunnel_id 1 session_id 1 peer_session_id 1 -# ifconfig -a +# ip -s -d show dev l2tpeth0 # ip addr add 10.5.1.2/32 peer 10.5.1.1/32 dev l2tpeth0 -# ifconfig l2tpeth0 up +# ip li set dev l2tpeth0 up Choose IP addresses to be the address of a local IP interface and that of the remote system. The IP addresses of the l2tpeth0 interface can be diff --git a/Documentation/networking/switchdev.txt b/Documentation/networking/switchdev.txt index 476df0496..91994134e 100644 --- a/Documentation/networking/switchdev.txt +++ b/Documentation/networking/switchdev.txt @@ -115,7 +115,7 @@ Switch ID ^^^^^^^^^ The switchdev driver must implement the switchdev op switchdev_port_attr_get -for SWITCHDEV_ATTR_PORT_PARENT_ID for each port netdev, returning the same +for SWITCHDEV_ATTR_ID_PORT_PARENT_ID for each port netdev, returning the same physical ID for each port of a switch. The ID must be unique between switches on the same system. The ID does not need to be unique between switches on different systems. @@ -178,7 +178,7 @@ entries are installed, for example, using iproute2 bridge cmd: bridge fdb add ADDR dev DEV [vlan VID] [self] The driver should use the helper switchdev_port_fdb_xxx ops for ndo_fdb_xxx -ops, and handle add/delete/dump of SWITCHDEV_OBJ_PORT_FDB object using +ops, and handle add/delete/dump of SWITCHDEV_OBJ_ID_PORT_FDB object using switchdev_port_obj_xxx ops. XXX: what should be done if offloading this rule to hardware fails (for @@ -233,26 +233,27 @@ the bridge's FDB. It's possible, but not optimal, to enable learning on the device port and on the bridge port, and disable learning_sync. To support learning and learning_sync port attributes, the driver implements -switchdev op switchdev_port_attr_get/set for SWITCHDEV_ATTR_PORT_BRIDGE_FLAGS. -The driver should initialize the attributes to the hardware defaults. +switchdev op switchdev_port_attr_get/set for +SWITCHDEV_ATTR_PORT_ID_BRIDGE_FLAGS. The driver should initialize the attributes +to the hardware defaults. FDB Ageing ^^^^^^^^^^ -There are two FDB ageing models supported: 1) ageing by the device, and 2) -ageing by the kernel. Ageing by the device is preferred if many FDB entries -are supported. The driver calls call_switchdev_notifiers(SWITCHDEV_FDB_DEL, -...) to age out the FDB entry. In this model, ageing by the kernel should be -turned off. XXX: how to turn off ageing in kernel on a per-port basis or -otherwise prevent the kernel from ageing out the FDB entry? - -In the kernel ageing model, the standard bridge ageing mechanism is used to age -out stale FDB entries. To keep an FDB entry "alive", the driver should refresh -the FDB entry by calling call_switchdev_notifiers(SWITCHDEV_FDB_ADD, ...). The +The bridge will skip ageing FDB entries marked with NTF_EXT_LEARNED and it is +the responsibility of the port driver/device to age out these entries. If the +port device supports ageing, when the FDB entry expires, it will notify the +driver which in turn will notify the bridge with SWITCHDEV_FDB_DEL. If the +device does not support ageing, the driver can simulate ageing using a +garbage collection timer to monitor FBD entries. Expired entries will be +notified to the bridge using SWITCHDEV_FDB_DEL. See rocker driver for +example of driver running ageing timer. + +To keep an NTF_EXT_LEARNED entry "alive", the driver should refresh the FDB +entry by calling call_switchdev_notifiers(SWITCHDEV_FDB_ADD, ...). The notification will reset the FDB entry's last-used time to now. The driver should rate limit refresh notifications, for example, no more than once a -second. If the FDB entry expires, fdb_delete is called to remove entry from -the device. +second. (The last-used time is visible using the bridge -s fdb option). STP State Change on Port ^^^^^^^^^^^^^^^^^^^^^^^^ @@ -260,7 +261,7 @@ STP State Change on Port Internally or with a third-party STP protocol implementation (e.g. mstpd), the bridge driver maintains the STP state for ports, and will notify the switch driver of STP state change on a port using the switchdev op -switchdev_attr_port_set for SWITCHDEV_ATTR_PORT_STP_UPDATE. +switchdev_attr_port_set for SWITCHDEV_ATTR_PORT_ID_STP_UPDATE. State is one of BR_STATE_*. The switch driver can use STP state updates to update ingress packet filter list for the port. For example, if port is @@ -277,8 +278,8 @@ Flooding L2 domain For a given L2 VLAN domain, the switch device should flood multicast/broadcast and unknown unicast packets to all ports in domain, if allowed by port's current STP state. The switch driver, knowing which ports are within which -vlan L2 domain, can program the switch device for flooding. The packet should -also be sent to the port netdev for processing by the bridge driver. The +vlan L2 domain, can program the switch device for flooding. The packet may +be sent to the port netdev for processing by the bridge driver. The bridge should not reflood the packet to the same ports the device flooded, otherwise there will be duplicate packets on the wire. @@ -297,6 +298,9 @@ packets up to the bridge driver for flooding. This is not ideal as the number of ports scale in the L2 domain as the device is much more efficient at flooding packets that software. +If supported by the device, flood control can be offloaded to it, preventing +certain netdevs from flooding unicast traffic for which there is no FDB entry. + IGMP Snooping ^^^^^^^^^^^^^ @@ -316,9 +320,9 @@ SWITCHDEV_OBJ_IPV[4|6]_FIB object using switchdev_port_obj_xxx ops. switchdev_port_obj_add is used for both adding a new FIB entry to the device, or modifying an existing entry on the device. -XXX: Currently, only SWITCHDEV_OBJ_IPV4_FIB objects are supported. +XXX: Currently, only SWITCHDEV_OBJ_ID_IPV4_FIB objects are supported. -SWITCHDEV_OBJ_IPV4_FIB object passes: +SWITCHDEV_OBJ_ID_IPV4_FIB object passes: struct switchdev_obj_ipv4_fib { /* IPV4_FIB */ u32 dst; @@ -369,3 +373,22 @@ The driver can monitor for updates to arp_tbl using the netevent notifier NETEVENT_NEIGH_UPDATE. The device can be programmed with resolved nexthops for the routes as arp_tbl updates. The driver implements ndo_neigh_destroy to know when arp_tbl neighbor entries are purged from the port. + +Transaction item queue +^^^^^^^^^^^^^^^^^^^^^^ + +For switchdev ops attr_set and obj_add, there is a 2 phase transaction model +used. First phase is to "prepare" anything needed, including various checks, +memory allocation, etc. The goal is to handle the stuff that is not unlikely +to fail here. The second phase is to "commit" the actual changes. + +Switchdev provides an inftrastructure for sharing items (for example memory +allocations) between the two phases. + +The object created by a driver in "prepare" phase and it is queued up by: +switchdev_trans_item_enqueue() +During the "commit" phase, the driver gets the object by: +switchdev_trans_item_dequeue() + +If a transaction is aborted during "prepare" phase, switchdev code will handle +cleanup of the queued-up objects. diff --git a/Documentation/networking/vrf.txt b/Documentation/networking/vrf.txt index 031ef4a63..d52aa10cf 100644 --- a/Documentation/networking/vrf.txt +++ b/Documentation/networking/vrf.txt @@ -90,7 +90,304 @@ or to specify the output device using cmsg and IP_PKTINFO. Limitations ----------- -VRF device currently only works for IPv4. Support for IPv6 is under development. - Index of original ingress interface is not available via cmsg. Will address soon. + +################################################################################ + +Using iproute2 for VRFs +======================= +VRF devices do *not* have to start with 'vrf-'. That is a convention used here +for emphasis of the device type, similar to use of 'br' in bridge names. + +1. Create a VRF + + To instantiate a VRF device and associate it with a table: + $ ip link add dev NAME type vrf table ID + + Remember to add the ip rules as well: + $ ip ru add oif NAME table 10 + $ ip ru add iif NAME table 10 + $ ip -6 ru add oif NAME table 10 + $ ip -6 ru add iif NAME table 10 + + Without the rules route lookups are not directed to the table. + + For example: + $ ip link add dev vrf-blue type vrf table 10 + $ ip ru add pref 200 oif vrf-blue table 10 + $ ip ru add pref 200 iif vrf-blue table 10 + $ ip -6 ru add pref 200 oif vrf-blue table 10 + $ ip -6 ru add pref 200 iif vrf-blue table 10 + + +2. List VRFs + + To list VRFs that have been created: + $ ip [-d] link show type vrf + NOTE: The -d option is needed to show the table id + + For example: + $ ip -d link show type vrf + 11: vrf-mgmt: mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 + link/ether 72:b3:ba:91:e2:24 brd ff:ff:ff:ff:ff:ff promiscuity 0 + vrf table 1 addrgenmode eui64 + 12: vrf-red: mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 + link/ether b6:6f:6e:f6:da:73 brd ff:ff:ff:ff:ff:ff promiscuity 0 + vrf table 10 addrgenmode eui64 + 13: vrf-blue: mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 + link/ether 36:62:e8:7d:bb:8c brd ff:ff:ff:ff:ff:ff promiscuity 0 + vrf table 66 addrgenmode eui64 + 14: vrf-green: mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 + link/ether e6:28:b8:63:70:bb brd ff:ff:ff:ff:ff:ff promiscuity 0 + vrf table 81 addrgenmode eui64 + + + Or in brief output: + + $ ip -br link show type vrf + vrf-mgmt UP 72:b3:ba:91:e2:24 + vrf-red UP b6:6f:6e:f6:da:73 + vrf-blue UP 36:62:e8:7d:bb:8c + vrf-green UP e6:28:b8:63:70:bb + + +3. Assign a Network Interface to a VRF + + Network interfaces are assigned to a VRF by enslaving the netdevice to a + VRF device: + $ ip link set dev NAME master VRF-NAME + + On enslavement connected and local routes are automatically moved to the + table associated with the VRF device. + + For example: + $ ip link set dev eth0 master vrf-mgmt + + +4. Show Devices Assigned to a VRF + + To show devices that have been assigned to a specific VRF add the master + option to the ip command: + $ ip link show master VRF-NAME + + For example: + $ ip link show master vrf-red + 3: eth1: mtu 1500 qdisc pfifo_fast master vrf-red state UP mode DEFAULT group default qlen 1000 + link/ether 02:00:00:00:02:02 brd ff:ff:ff:ff:ff:ff + 4: eth2: mtu 1500 qdisc pfifo_fast master vrf-red state UP mode DEFAULT group default qlen 1000 + link/ether 02:00:00:00:02:03 brd ff:ff:ff:ff:ff:ff + 7: eth5: mtu 1500 qdisc noop master vrf-red state DOWN mode DEFAULT group default qlen 1000 + link/ether 02:00:00:00:02:06 brd ff:ff:ff:ff:ff:ff + + + Or using the brief output: + $ ip -br link show master vrf-red + eth1 UP 02:00:00:00:02:02 + eth2 UP 02:00:00:00:02:03 + eth5 DOWN 02:00:00:00:02:06 + + +5. Show Neighbor Entries for a VRF + + To list neighbor entries associated with devices enslaved to a VRF device + add the master option to the ip command: + $ ip [-6] neigh show master VRF-NAME + + For example: + $ ip neigh show master vrf-red + 10.2.1.254 dev eth1 lladdr a6:d9:c7:4f:06:23 REACHABLE + 10.2.2.254 dev eth2 lladdr 5e:54:01:6a:ee:80 REACHABLE + + $ ip -6 neigh show master vrf-red + 2002:1::64 dev eth1 lladdr a6:d9:c7:4f:06:23 REACHABLE + + +6. Show Addresses for a VRF + + To show addresses for interfaces associated with a VRF add the master + option to the ip command: + $ ip addr show master VRF-NAME + + For example: + $ ip addr show master vrf-red + 3: eth1: mtu 1500 qdisc pfifo_fast master vrf-red state UP group default qlen 1000 + link/ether 02:00:00:00:02:02 brd ff:ff:ff:ff:ff:ff + inet 10.2.1.2/24 brd 10.2.1.255 scope global eth1 + valid_lft forever preferred_lft forever + inet6 2002:1::2/120 scope global + valid_lft forever preferred_lft forever + inet6 fe80::ff:fe00:202/64 scope link + valid_lft forever preferred_lft forever + 4: eth2: mtu 1500 qdisc pfifo_fast master vrf-red state UP group default qlen 1000 + link/ether 02:00:00:00:02:03 brd ff:ff:ff:ff:ff:ff + inet 10.2.2.2/24 brd 10.2.2.255 scope global eth2 + valid_lft forever preferred_lft forever + inet6 2002:2::2/120 scope global + valid_lft forever preferred_lft forever + inet6 fe80::ff:fe00:203/64 scope link + valid_lft forever preferred_lft forever + 7: eth5: mtu 1500 qdisc noop master vrf-red state DOWN group default qlen 1000 + link/ether 02:00:00:00:02:06 brd ff:ff:ff:ff:ff:ff + + Or in brief format: + $ ip -br addr show master vrf-red + eth1 UP 10.2.1.2/24 2002:1::2/120 fe80::ff:fe00:202/64 + eth2 UP 10.2.2.2/24 2002:2::2/120 fe80::ff:fe00:203/64 + eth5 DOWN + + +7. Show Routes for a VRF + + To show routes for a VRF use the ip command to display the table associated + with the VRF device: + $ ip [-6] route show table ID + + For example: + $ ip route show table vrf-red + prohibit default + broadcast 10.2.1.0 dev eth1 proto kernel scope link src 10.2.1.2 + 10.2.1.0/24 dev eth1 proto kernel scope link src 10.2.1.2 + local 10.2.1.2 dev eth1 proto kernel scope host src 10.2.1.2 + broadcast 10.2.1.255 dev eth1 proto kernel scope link src 10.2.1.2 + broadcast 10.2.2.0 dev eth2 proto kernel scope link src 10.2.2.2 + 10.2.2.0/24 dev eth2 proto kernel scope link src 10.2.2.2 + local 10.2.2.2 dev eth2 proto kernel scope host src 10.2.2.2 + broadcast 10.2.2.255 dev eth2 proto kernel scope link src 10.2.2.2 + + $ ip -6 route show table vrf-red + local 2002:1:: dev lo proto none metric 0 pref medium + local 2002:1::2 dev lo proto none metric 0 pref medium + 2002:1::/120 dev eth1 proto kernel metric 256 pref medium + local 2002:2:: dev lo proto none metric 0 pref medium + local 2002:2::2 dev lo proto none metric 0 pref medium + 2002:2::/120 dev eth2 proto kernel metric 256 pref medium + local fe80:: dev lo proto none metric 0 pref medium + local fe80:: dev lo proto none metric 0 pref medium + local fe80::ff:fe00:202 dev lo proto none metric 0 pref medium + local fe80::ff:fe00:203 dev lo proto none metric 0 pref medium + fe80::/64 dev eth1 proto kernel metric 256 pref medium + fe80::/64 dev eth2 proto kernel metric 256 pref medium + ff00::/8 dev vrf-red metric 256 pref medium + ff00::/8 dev eth1 metric 256 pref medium + ff00::/8 dev eth2 metric 256 pref medium + + +8. Route Lookup for a VRF + + A test route lookup can be done for a VRF by adding the oif option to ip: + $ ip [-6] route get oif VRF-NAME ADDRESS + + For example: + $ ip route get 10.2.1.40 oif vrf-red + 10.2.1.40 dev eth1 table vrf-red src 10.2.1.2 + cache + + $ ip -6 route get 2002:1::32 oif vrf-red + 2002:1::32 from :: dev eth1 table vrf-red proto kernel src 2002:1::2 metric 256 pref medium + + +9. Removing Network Interface from a VRF + + Network interfaces are removed from a VRF by breaking the enslavement to + the VRF device: + $ ip link set dev NAME nomaster + + Connected routes are moved back to the default table and local entries are + moved to the local table. + + For example: + $ ip link set dev eth0 nomaster + +-------------------------------------------------------------------------------- + +Commands used in this example: + +cat >> /etc/iproute2/rt_tables < REGION0 +---> NAMESPACE0.0 +--> PMEM8 "pm0.0" | diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt index 2216eb187..b784c2701 100644 --- a/Documentation/printk-formats.txt +++ b/Documentation/printk-formats.txt @@ -23,6 +23,10 @@ Example: Reminder: sizeof() result is of type size_t. +The kernel's printf does not support %n. For obvious reasons, floating +point formats (%e, %f, %g, %a) are also not recognized. Use of any +unsupported specifier or length qualifier results in a WARN and early +return from vsnprintf. Raw pointer value SHOULD be printed with %p. The kernel supports the following extended format specifiers for pointer types: @@ -119,6 +123,7 @@ Raw buffer as an escaped string: If field width is omitted the 1 byte only will be escaped. Raw buffer as a hex string: + %*ph 00 01 02 ... 3f %*phC 00:01:02: ... :3f %*phD 00-01-02- ... -3f @@ -234,6 +239,7 @@ UUID/GUID addresses: Passed by reference. dentry names: + %pd{,2,3,4} %pD{,2,3,4} @@ -256,6 +262,8 @@ struct va_format: va_list *va; }; + Implements a "recursive vsnprintf". + Do not use this feature without some mechanism to verify the correctness of the format string and va_list arguments. @@ -284,6 +292,27 @@ bitmap and its derivatives such as cpumask and nodemask: Passed by reference. +Network device features: + + %pNF 0x000000000000c000 + + For printing netdev_features_t. + + Passed by reference. + +Command from struct task_struct + + %pT ls + + For printing executable name excluding path from struct + task_struct. + + Passed by reference. + +If you add other %p extensions, please extend lib/test_printf.c with +one or more test cases, if at all feasible. + + Thank you for your cooperation and attention. diff --git a/Documentation/rbtree.txt b/Documentation/rbtree.txt index 39873ef41..b9d9cc57b 100644 --- a/Documentation/rbtree.txt +++ b/Documentation/rbtree.txt @@ -203,7 +203,7 @@ functions with the user provided augmentation callback when inserting and erasing nodes. C files implementing augmented rbtree manipulation must include - instead of . Note that + instead of . Note that linux/rbtree_augmented.h exposes some rbtree implementations details you are not expected to rely on; please stick to the documented APIs there and do not include from header files diff --git a/Documentation/scsi/st.txt b/Documentation/scsi/st.txt index f29fa5506..b3211af63 100644 --- a/Documentation/scsi/st.txt +++ b/Documentation/scsi/st.txt @@ -569,7 +569,9 @@ Debugging code is now compiled in by default but debugging is turned off with the kernel module parameter debug_flag defaulting to 0. Debugging can still be switched on and off with an ioctl. To enable debug at module load time add debug_flag=1 to the module load options, the -debugging output is not voluminous. +debugging output is not voluminous. Debugging can also be enabled +and disabled by writing a '0' (disable) or '1' (enable) to the sysfs +file /sys/bus/scsi/drivers/st/debug_flag. If the tape seems to hang, I would be very interested to hear where the driver is waiting. With the command 'ps -l' you can see the state diff --git a/Documentation/security/Smack.txt b/Documentation/security/Smack.txt index 5e6d07fbe..945cc633d 100644 --- a/Documentation/security/Smack.txt +++ b/Documentation/security/Smack.txt @@ -255,6 +255,16 @@ unconfined the access permitted if it wouldn't be otherwise. Note that this is dangerous and can ruin the proper labeling of your system. It should never be used in production. +relabel-self + This interface contains a list of labels to which the process can + transition to, by writing to /proc/self/attr/current. + Normally a process can change its own label to any legal value, but only + if it has CAP_MAC_ADMIN. This interface allows a process without + CAP_MAC_ADMIN to relabel itself to one of labels from predefined list. + A process without CAP_MAC_ADMIN can change its label only once. When it + does, this list will be cleared. + The values are set by writing the desired labels, separated + by spaces, to the file or cleared by writing "-" to the file. If you are using the smackload utility you can add access rules in /etc/smack/accesses. They take the form: diff --git a/Documentation/security/keys.txt b/Documentation/security/keys.txt index c9e7f4f22..8c183873b 100644 --- a/Documentation/security/keys.txt +++ b/Documentation/security/keys.txt @@ -1049,12 +1049,12 @@ search a specific keyring, so using keyrings in this way is of limited utility. NOTES ON ACCESSING PAYLOAD CONTENTS =================================== -The simplest payload is just a number in key->payload.value. In this case, -there's no need to indulge in RCU or locking when accessing the payload. +The simplest payload is just data stored in key->payload directly. In this +case, there's no need to indulge in RCU or locking when accessing the payload. -More complex payload contents must be allocated and a pointer to them set in -key->payload.data. One of the following ways must be selected to access the -data: +More complex payload contents must be allocated and pointers to them set in the +key->payload.data[] array. One of the following ways must be selected to +access the data: (1) Unmodifiable key type. @@ -1092,6 +1092,13 @@ data: the payload. key->datalen cannot be relied upon to be consistent with the payload just dereferenced if the key's semaphore is not held. + Note that key->payload.data[0] has a shadow that is marked for __rcu + usage. This is called key->payload.rcu_data0. The following accessors + wrap the RCU calls to this element: + + rcu_assign_keypointer(struct key *key, void *data); + void *rcu_dereference_key(struct key *key); + =================== DEFINING A KEY TYPE @@ -1143,8 +1150,7 @@ The structure has a number of fields, some of which are mandatory: struct key_preparsed_payload { char *description; - void *type_data[2]; - void *payload; + union key_payload payload; const void *data; size_t datalen; size_t quotalen; @@ -1160,10 +1166,9 @@ The structure has a number of fields, some of which are mandatory: attached as a string to the description field. This will be used for the key description if the caller of add_key() passes NULL or "". - The method can attach anything it likes to type_data[] and payload. These - are merely passed along to the instantiate() or update() operations. If - set, the expiry time will be applied to the key if it is instantiated from - this data. + The method can attach anything it likes to payload. This is merely passed + along to the instantiate() or update() operations. If set, the expiry + time will be applied to the key if it is instantiated from this data. The method should return 0 if successful or a negative error code otherwise. @@ -1172,11 +1177,10 @@ The structure has a number of fields, some of which are mandatory: (*) void (*free_preparse)(struct key_preparsed_payload *prep); This method is only required if the preparse() method is provided, - otherwise it is unused. It cleans up anything attached to the - description, type_data and payload fields of the key_preparsed_payload - struct as filled in by the preparse() method. It will always be called - after preparse() returns successfully, even if instantiate() or update() - succeed. + otherwise it is unused. It cleans up anything attached to the description + and payload fields of the key_preparsed_payload struct as filled in by the + preparse() method. It will always be called after preparse() returns + successfully, even if instantiate() or update() succeed. (*) int (*instantiate)(struct key *key, struct key_preparsed_payload *prep); @@ -1197,6 +1201,11 @@ The structure has a number of fields, some of which are mandatory: It is safe to sleep in this method. + generic_key_instantiate() is provided to simply copy the data from + prep->payload.data[] to key->payload.data[], with RCU-safe assignment on + the first element. It will then clear prep->payload.data[] so that the + free_preparse method doesn't release the data. + (*) int (*update)(struct key *key, const void *data, size_t datalen); diff --git a/Documentation/serial/driver b/Documentation/serial/driver index c415b0ef4..379468e12 100644 --- a/Documentation/serial/driver +++ b/Documentation/serial/driver @@ -439,11 +439,13 @@ Modem control lines via GPIO Some helpers are provided in order to set/get modem control lines via GPIO. -mctrl_gpio_init(dev, idx): +mctrl_gpio_init(port, idx): This will get the {cts,rts,...}-gpios from device tree if they are present and request them, set direction etc, and return an allocated structure. devm_* functions are used, so there's no need to call mctrl_gpio_free(). + As this sets up the irq handling make sure to not handle changes to the + gpio input lines in your driver, too. mctrl_gpio_free(dev, gpios): This will free the requested gpios in mctrl_gpio_init(). @@ -458,3 +460,9 @@ mctrl_gpio_set(gpios, mctrl): mctrl_gpio_get(gpios, mctrl): This will update mctrl with the gpios values. + +mctrl_gpio_enable_ms(gpios): + Enables irqs and handling of changes to the ms lines. + +mctrl_gpio_disable_ms(gpios): + Disables irqs and handling of changes to the ms lines. diff --git a/Documentation/serial/tty.txt b/Documentation/serial/tty.txt index 973c8ad3f..bc3842dc3 100644 --- a/Documentation/serial/tty.txt +++ b/Documentation/serial/tty.txt @@ -39,8 +39,13 @@ TTY side interfaces: open() - Called when the line discipline is attached to the terminal. No other call into the line discipline for this tty will occur until it - completes successfully. Returning an error will - prevent the ldisc from being attached. Can sleep. + completes successfully. Should initialize any + state needed by the ldisc, and set receive_room + in the tty_struct to the maximum amount of data + the line discipline is willing to accept from the + driver with a single call to receive_buf(). + Returning an error will prevent the ldisc from + being attached. Can sleep. close() - This is called on a terminal when the line discipline is being unplugged. At the point of @@ -52,9 +57,16 @@ hangup() - Called when the tty line is hung up. No further calls into the ldisc code will occur. The return value is ignored. Can sleep. -write() - A process is writing data through the line - discipline. Multiple write calls are serialized - by the tty layer for the ldisc. May sleep. +read() - (optional) A process requests reading data from + the line. Multiple read calls may occur in parallel + and the ldisc must deal with serialization issues. + If not defined, the process will receive an EIO + error. May sleep. + +write() - (optional) A process requests writing data to the + line. Multiple write calls are serialized by the + tty layer for the ldisc. If not defined, the + process will receive an EIO error. May sleep. flush_buffer() - (optional) May be called at any point between open and close, and instructs the line discipline @@ -69,27 +81,33 @@ set_termios() - (optional) Called on termios structure changes. termios semaphore so allowed to sleep. Serialized against itself only. -read() - Move data from the line discipline to the user. - Multiple read calls may occur in parallel and the - ldisc must deal with serialization issues. May - sleep. - -poll() - Check the status for the poll/select calls. Multiple - poll calls may occur in parallel. May sleep. +poll() - (optional) Check the status for the poll/select + calls. Multiple poll calls may occur in parallel. + May sleep. -ioctl() - Called when an ioctl is handed to the tty layer - that might be for the ldisc. Multiple ioctl calls - may occur in parallel. May sleep. +ioctl() - (optional) Called when an ioctl is handed to the + tty layer that might be for the ldisc. Multiple + ioctl calls may occur in parallel. May sleep. -compat_ioctl() - Called when a 32 bit ioctl is handed to the tty layer - that might be for the ldisc. Multiple ioctl calls - may occur in parallel. May sleep. +compat_ioctl() - (optional) Called when a 32 bit ioctl is handed + to the tty layer that might be for the ldisc. + Multiple ioctl calls may occur in parallel. + May sleep. Driver Side Interfaces: -receive_buf() - Hand buffers of bytes from the driver to the ldisc - for processing. Semantics currently rather - mysterious 8( +receive_buf() - (optional) Called by the low-level driver to hand + a buffer of received bytes to the ldisc for + processing. The number of bytes is guaranteed not + to exceed the current value of tty->receive_room. + All bytes must be processed. + +receive_buf2() - (optional) Called by the low-level driver to hand + a buffer of received bytes to the ldisc for + processing. Returns the number of bytes processed. + + If both receive_buf() and receive_buf2() are + defined, receive_buf2() should be preferred. write_wakeup() - May be called at any point between open and close. The TTY_DO_WRITE_WAKEUP flag indicates if a call diff --git a/Documentation/sound/alsa/hda_codec.txt b/Documentation/sound/alsa/hda_codec.txt deleted file mode 100644 index de8efbc7e..000000000 --- a/Documentation/sound/alsa/hda_codec.txt +++ /dev/null @@ -1,322 +0,0 @@ -Notes on Universal Interface for Intel High Definition Audio Codec ------------------------------------------------------------------- - -Takashi Iwai - - -[Still a draft version] - - -General -======= - -The snd-hda-codec module supports the generic access function for the -High Definition (HD) audio codecs. It's designed to be independent -from the controller code like ac97 codec module. The real accessors -from/to the controller must be implemented in the lowlevel driver. - -The structure of this module is similar with ac97_codec module. -Each codec chip belongs to a bus class which communicates with the -controller. - - -Initialization of Bus Instance -============================== - -The card driver has to create struct hda_bus at first. The template -struct should be filled and passed to the constructor: - -struct hda_bus_template { - void *private_data; - struct pci_dev *pci; - const char *modelname; - struct hda_bus_ops ops; -}; - -The card driver can set and use the private_data field to retrieve its -own data in callback functions. The pci field is used when the patch -needs to check the PCI subsystem IDs, so on. For non-PCI system, it -doesn't have to be set, of course. -The modelname field specifies the board's specific configuration. The -string is passed to the codec parser, and it depends on the parser how -the string is used. -These fields, private_data, pci and modelname are all optional. - -The ops field contains the callback functions as the following: - -struct hda_bus_ops { - int (*command)(struct hda_codec *codec, hda_nid_t nid, int direct, - unsigned int verb, unsigned int parm); - unsigned int (*get_response)(struct hda_codec *codec); - void (*private_free)(struct hda_bus *); -#ifdef CONFIG_SND_HDA_POWER_SAVE - void (*pm_notify)(struct hda_codec *codec); -#endif -}; - -The command callback is called when the codec module needs to send a -VERB to the controller. It's always a single command. -The get_response callback is called when the codec requires the answer -for the last command. These two callbacks are mandatory and have to -be given. -The third, private_free callback, is optional. It's called in the -destructor to release any necessary data in the lowlevel driver. - -The pm_notify callback is available only with -CONFIG_SND_HDA_POWER_SAVE kconfig. It's called when the codec needs -to power up or may power down. The controller should check the all -belonging codecs on the bus whether they are actually powered off -(check codec->power_on), and optionally the driver may power down the -controller side, too. - -The bus instance is created via snd_hda_bus_new(). You need to pass -the card instance, the template, and the pointer to store the -resultant bus instance. - -int snd_hda_bus_new(struct snd_card *card, const struct hda_bus_template *temp, - struct hda_bus **busp); - -It returns zero if successful. A negative return value means any -error during creation. - - -Creation of Codec Instance -========================== - -Each codec chip on the board is then created on the BUS instance. -To create a codec instance, call snd_hda_codec_new(). - -int snd_hda_codec_new(struct hda_bus *bus, unsigned int codec_addr, - struct hda_codec **codecp); - -The first argument is the BUS instance, the second argument is the -address of the codec, and the last one is the pointer to store the -resultant codec instance (can be NULL if not needed). - -The codec is stored in a linked list of bus instance. You can follow -the codec list like: - - struct hda_codec *codec; - list_for_each_entry(codec, &bus->codec_list, list) { - ... - } - -The codec isn't initialized at this stage properly. The -initialization sequence is called when the controls are built later. - - -Codec Access -============ - -To access codec, use snd_hda_codec_read() and snd_hda_codec_write(). -snd_hda_param_read() is for reading parameters. -For writing a sequence of verbs, use snd_hda_sequence_write(). - -There are variants of cached read/write, snd_hda_codec_write_cache(), -snd_hda_sequence_write_cache(). These are used for recording the -register states for the power-management resume. When no PM is needed, -these are equivalent with non-cached version. - -To retrieve the number of sub nodes connected to the given node, use -snd_hda_get_sub_nodes(). The connection list can be obtained via -snd_hda_get_connections() call. - -When an unsolicited event happens, pass the event via -snd_hda_queue_unsol_event() so that the codec routines will process it -later. - - -(Mixer) Controls -================ - -To create mixer controls of all codecs, call -snd_hda_build_controls(). It then builds the mixers and does -initialization stuff on each codec. - - -PCM Stuff -========= - -snd_hda_build_pcms() gives the necessary information to create PCM -streams. When it's called, each codec belonging to the bus stores -codec->num_pcms and codec->pcm_info fields. The num_pcms indicates -the number of elements in pcm_info array. The card driver is supposed -to traverse the codec linked list, read the pcm information in -pcm_info array, and build pcm instances according to them. - -The pcm_info array contains the following record: - -/* PCM information for each substream */ -struct hda_pcm_stream { - unsigned int substreams; /* number of substreams, 0 = not exist */ - unsigned int channels_min; /* min. number of channels */ - unsigned int channels_max; /* max. number of channels */ - hda_nid_t nid; /* default NID to query rates/formats/bps, or set up */ - u32 rates; /* supported rates */ - u64 formats; /* supported formats (SNDRV_PCM_FMTBIT_) */ - unsigned int maxbps; /* supported max. bit per sample */ - struct hda_pcm_ops ops; -}; - -/* for PCM creation */ -struct hda_pcm { - char *name; - struct hda_pcm_stream stream[2]; -}; - -The name can be passed to snd_pcm_new(). The stream field contains -the information for playback (SNDRV_PCM_STREAM_PLAYBACK = 0) and -capture (SNDRV_PCM_STREAM_CAPTURE = 1) directions. The card driver -should pass substreams to snd_pcm_new() for the number of substreams -to create. - -The channels_min, channels_max, rates and formats should be copied to -runtime->hw record. They and maxbps fields are used also to compute -the format value for the HDA codec and controller. Call -snd_hda_calc_stream_format() to get the format value. - -The ops field contains the following callback functions: - -struct hda_pcm_ops { - int (*open)(struct hda_pcm_stream *info, struct hda_codec *codec, - struct snd_pcm_substream *substream); - int (*close)(struct hda_pcm_stream *info, struct hda_codec *codec, - struct snd_pcm_substream *substream); - int (*prepare)(struct hda_pcm_stream *info, struct hda_codec *codec, - unsigned int stream_tag, unsigned int format, - struct snd_pcm_substream *substream); - int (*cleanup)(struct hda_pcm_stream *info, struct hda_codec *codec, - struct snd_pcm_substream *substream); -}; - -All are non-NULL, so you can call them safely without NULL check. - -The open callback should be called in PCM open after runtime->hw is -set up. It may override some setting and constraints additionally. -Similarly, the close callback should be called in the PCM close. - -The prepare callback should be called in PCM prepare. This will set -up the codec chip properly for the operation. The cleanup should be -called in hw_free to clean up the configuration. - -The caller should check the return value, at least for open and -prepare callbacks. When a negative value is returned, some error -occurred. - - -Proc Files -========== - -Each codec dumps the widget node information in -/proc/asound/card*/codec#* file. This information would be really -helpful for debugging. Please provide its contents together with the -bug report. - - -Power Management -================ - -It's simple: -Call snd_hda_suspend() in the PM suspend callback. -Call snd_hda_resume() in the PM resume callback. - - -Codec Preset (Patch) -==================== - -To set up and handle the codec functionality fully, each codec may -have a codec preset (patch). It's defined in struct hda_codec_preset: - - struct hda_codec_preset { - unsigned int id; - unsigned int mask; - unsigned int subs; - unsigned int subs_mask; - unsigned int rev; - const char *name; - int (*patch)(struct hda_codec *codec); - }; - -When the codec id and codec subsystem id match with the given id and -subs fields bitwise (with bitmask mask and subs_mask), the callback -patch is called. The patch callback should initialize the codec and -set the codec->patch_ops field. This is defined as below: - - struct hda_codec_ops { - int (*build_controls)(struct hda_codec *codec); - int (*build_pcms)(struct hda_codec *codec); - int (*init)(struct hda_codec *codec); - void (*free)(struct hda_codec *codec); - void (*unsol_event)(struct hda_codec *codec, unsigned int res); - #ifdef CONFIG_PM - int (*suspend)(struct hda_codec *codec, pm_message_t state); - int (*resume)(struct hda_codec *codec); - #endif - #ifdef CONFIG_SND_HDA_POWER_SAVE - int (*check_power_status)(struct hda_codec *codec, - hda_nid_t nid); - #endif - }; - -The build_controls callback is called from snd_hda_build_controls(). -Similarly, the build_pcms callback is called from -snd_hda_build_pcms(). The init callback is called after -build_controls to initialize the hardware. -The free callback is called as a destructor. - -The unsol_event callback is called when an unsolicited event is -received. - -The suspend and resume callbacks are for power management. -They can be NULL if no special sequence is required. When the resume -callback is NULL, the driver calls the init callback and resumes the -registers from the cache. If other handling is needed, you'd need to -write your own resume callback. There, the amp values can be resumed -via - void snd_hda_codec_resume_amp(struct hda_codec *codec); -and the other codec registers via - void snd_hda_codec_resume_cache(struct hda_codec *codec); - -The check_power_status callback is called when the amp value of the -given widget NID is changed. The codec code can turn on/off the power -appropriately from this information. - -Each entry can be NULL if not necessary to be called. - - -Generic Parser -============== - -When the device doesn't match with any given presets, the widgets are -parsed via th generic parser (hda_generic.c). Its support is -limited: no multi-channel support, for example. - - -Digital I/O -=========== - -Call snd_hda_create_spdif_out_ctls() from the patch to create controls -related with SPDIF out. - - -Helper Functions -================ - -snd_hda_get_codec_name() stores the codec name on the given string. - -snd_hda_check_board_config() can be used to obtain the configuration -information matching with the device. Define the model string table -and the table with struct snd_pci_quirk entries (zero-terminated), -and pass it to the function. The function checks the modelname given -as a module parameter, and PCI subsystem IDs. If the matching entry -is found, it returns the config field value. - -snd_hda_add_new_ctls() can be used to create and add control entries. -Pass the zero-terminated array of struct snd_kcontrol_new - -Macros HDA_CODEC_VOLUME(), HDA_CODEC_MUTE() and their variables can be -used for the entry of struct snd_kcontrol_new. - -The input MUX helper callbacks for such a control are provided, too: -snd_hda_input_mux_info() and snd_hda_input_mux_put(). See -patch_realtek.c for example. diff --git a/Documentation/spi/pxa2xx b/Documentation/spi/pxa2xx index 3352f9743..13a0b7fb1 100644 --- a/Documentation/spi/pxa2xx +++ b/Documentation/spi/pxa2xx @@ -22,15 +22,10 @@ Typically a SPI master is defined in the arch/.../mach-*/board-*.c as a found in include/linux/spi/pxa2xx_spi.h: struct pxa2xx_spi_master { - u32 clock_enable; u16 num_chipselect; u8 enable_dma; }; -The "pxa2xx_spi_master.clock_enable" field is used to enable/disable the -corresponding SSP peripheral block in the "Clock Enable Register (CKEN"). See -the "PXA2xx Developer Manual" section "Clocks and Power Management". - The "pxa2xx_spi_master.num_chipselect" field is used to determine the number of slave device (chips) attached to this SPI master. @@ -57,7 +52,6 @@ static struct resource pxa_spi_nssp_resources[] = { }; static struct pxa2xx_spi_master pxa_nssp_master_info = { - .clock_enable = CKEN_NSSP, /* NSSP Peripheral clock */ .num_chipselect = 1, /* Matches the number of chips attached to NSSP */ .enable_dma = 1, /* Enables NSSP DMA */ }; diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index f1a8333dd..e52acdfb1 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt @@ -33,6 +33,7 @@ show up in /proc/sys/kernel: - domainname - hostname - hotplug +- hardlockup_all_cpu_backtrace - hung_task_panic - hung_task_check_count - hung_task_timeout_secs @@ -294,6 +295,17 @@ Information Service) or YP (Yellow Pages) domainname. These two domain names are in general different. For a detailed discussion see the hostname(1) man page. +============================================================== +hardlockup_all_cpu_backtrace: + +This value controls the hard lockup detector behavior when a hard +lockup condition is detected as to whether or not to gather further +debug information. If enabled, arch-specific all-CPU stack dumping +will be initiated. + +0: do nothing. This is the default behavior. + +1: on detection capture more debug information. ============================================================== hotplug: diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt index a4482fcea..f72370b44 100644 --- a/Documentation/sysctl/vm.txt +++ b/Documentation/sysctl/vm.txt @@ -639,7 +639,7 @@ and don't use much of it. The default value is 0. See Documentation/vm/overcommit-accounting and -security/commoncap.c::cap_vm_enough_memory() for more information. +mm/mmap.c::__vm_enough_memory() for more information. ============================================================== diff --git a/Documentation/target/tcm_mod_builder.py b/Documentation/target/tcm_mod_builder.py index cda56df9b..7d370c9b1 100755 --- a/Documentation/target/tcm_mod_builder.py +++ b/Documentation/target/tcm_mod_builder.py @@ -203,8 +203,6 @@ def tcm_mod_build_configfs(proto_ident, fabric_mod_dir_var, fabric_mod_name): buf += "#include \n\n" buf += "#include \n" buf += "#include \n" - buf += "#include \n" - buf += "#include \n\n" buf += "#include \"" + fabric_mod_name + "_base.h\"\n" buf += "#include \"" + fabric_mod_name + "_fabric.h\"\n\n" @@ -283,19 +281,6 @@ def tcm_mod_build_configfs(proto_ident, fabric_mod_dir_var, fabric_mod_name): buf += " struct " + fabric_mod_name + "_" + fabric_mod_port + ", " + fabric_mod_port + "_wwn);\n" buf += " kfree(" + fabric_mod_port + ");\n" buf += "}\n\n" - buf += "static ssize_t " + fabric_mod_name + "_wwn_show_attr_version(\n" - buf += " struct target_fabric_configfs *tf,\n" - buf += " char *page)\n" - buf += "{\n" - buf += " return sprintf(page, \"" + fabric_mod_name.upper() + " fabric module %s on %s/%s\"\n" - buf += " \"on \"UTS_RELEASE\"\\n\", " + fabric_mod_name.upper() + "_VERSION, utsname()->sysname,\n" - buf += " utsname()->machine);\n" - buf += "}\n\n" - buf += "TF_WWN_ATTR_RO(" + fabric_mod_name + ", version);\n\n" - buf += "static struct configfs_attribute *" + fabric_mod_name + "_wwn_attrs[] = {\n" - buf += " &" + fabric_mod_name + "_wwn_version.attr,\n" - buf += " NULL,\n" - buf += "};\n\n" buf += "static const struct target_core_fabric_ops " + fabric_mod_name + "_ops = {\n" buf += " .module = THIS_MODULE,\n" @@ -328,8 +313,6 @@ def tcm_mod_build_configfs(proto_ident, fabric_mod_dir_var, fabric_mod_name): buf += " .fabric_drop_wwn = " + fabric_mod_name + "_drop_" + fabric_mod_port + ",\n" buf += " .fabric_make_tpg = " + fabric_mod_name + "_make_tpg,\n" buf += " .fabric_drop_tpg = " + fabric_mod_name + "_drop_tpg,\n" - buf += "\n" - buf += " .tfc_wwn_attrs = " + fabric_mod_name + "_wwn_attrs,\n" buf += "};\n\n" buf += "static int __init " + fabric_mod_name + "_init(void)\n" diff --git a/Documentation/trace/events.txt b/Documentation/trace/events.txt index 75d25a1d6..c010be8c8 100644 --- a/Documentation/trace/events.txt +++ b/Documentation/trace/events.txt @@ -288,6 +288,24 @@ prev_pid == 0 # cat sched_wakeup/filter common_pid == 0 +5.4 PID filtering +----------------- + +The set_event_pid file in the same directory as the top events directory +exists, will filter all events from tracing any task that does not have the +PID listed in the set_event_pid file. + +# cd /sys/kernel/debug/tracing +# echo $$ > set_event_pid +# echo 1 > events/enabled + +Will only trace events for the current task. + +To add more PIDs without losing the PIDs already included, use '>>'. + +# echo 123 244 1 >> set_event_pid + + 6. Event triggers ================= diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt index ef621d34b..f52f297cb 100644 --- a/Documentation/trace/ftrace.txt +++ b/Documentation/trace/ftrace.txt @@ -204,6 +204,12 @@ of ftrace. Here is a list of some of the key files: Have the function tracer only trace a single thread. + set_event_pid: + + Have the events only trace a task with a PID listed in this file. + Note, sched_switch and sched_wake_up will also trace events + listed in this file. + set_graph_function: Set a "trigger" function where tracing should start @@ -2437,6 +2443,23 @@ The following commands are supported: echo '!writeback*:mod:ext3' >> set_ftrace_filter + Mod command supports module globbing. Disable tracing for all + functions except a specific module: + + echo '!*:mod:!ext3' >> set_ftrace_filter + + Disable tracing for all modules, but still trace kernel: + + echo '!*:mod:*' >> set_ftrace_filter + + Enable filter only for kernel: + + echo '*write*:mod:!*' >> set_ftrace_filter + + Enable filter for module globbing: + + echo '*write*:mod:*snd*' >> set_ftrace_filter + - traceon/traceoff These commands turn tracing on and off when the specified functions are hit. The parameter determines how many times the diff --git a/Documentation/trace/intel_th.txt b/Documentation/trace/intel_th.txt new file mode 100644 index 000000000..f7fc5ba5d --- /dev/null +++ b/Documentation/trace/intel_th.txt @@ -0,0 +1,99 @@ +Intel(R) Trace Hub (TH) +======================= + +Overview +-------- + +Intel(R) Trace Hub (TH) is a set of hardware blocks that produce, +switch and output trace data from multiple hardware and software +sources over several types of trace output ports encoded in System +Trace Protocol (MIPI STPv2) and is intended to perform full system +debugging. For more information on the hardware, see Intel(R) Trace +Hub developer's manual [1]. + +It consists of trace sources, trace destinations (outputs) and a +switch (Global Trace Hub, GTH). These devices are placed on a bus of +their own ("intel_th"), where they can be discovered and configured +via sysfs attributes. + +Currently, the following Intel TH subdevices (blocks) are supported: + - Software Trace Hub (STH), trace source, which is a System Trace + Module (STM) device, + - Memory Storage Unit (MSU), trace output, which allows storing + trace hub output in system memory, + - Parallel Trace Interface output (PTI), trace output to an external + debug host via a PTI port, + - Global Trace Hub (GTH), which is a switch and a central component + of Intel(R) Trace Hub architecture. + +Common attributes for output devices are described in +Documentation/ABI/testing/sysfs-bus-intel_th-output-devices, the most +notable of them is "active", which enables or disables trace output +into that particular output device. + +GTH allows directing different STP masters into different output ports +via its "masters" attribute group. More detailed GTH interface +description is at Documentation/ABI/testing/sysfs-bus-intel_th-devices-gth. + +STH registers an stm class device, through which it provides interface +to userspace and kernelspace software trace sources. See +Documentation/tracing/stm.txt for more information on that. + +MSU can be configured to collect trace data into a system memory +buffer, which can later on be read from its device nodes via read() or +mmap() interface. + +On the whole, Intel(R) Trace Hub does not require any special +userspace software to function; everything can be configured, started +and collected via sysfs attributes, and device nodes. + +[1] https://software.intel.com/sites/default/files/managed/d3/3c/intel-th-developer-manual.pdf + +Bus and Subdevices +------------------ + +For each Intel TH device in the system a bus of its own is +created and assigned an id number that reflects the order in which TH +devices were emumerated. All TH subdevices (devices on intel_th bus) +begin with this id: 0-gth, 0-msc0, 0-msc1, 0-pti, 0-sth, which is +followed by device's name and an optional index. + +Output devices also get a device node in /dev/intel_thN, where N is +the Intel TH device id. For example, MSU's memory buffers, when +allocated, are accessible via /dev/intel_th0/msc{0,1}. + +Quick example +------------- + +# figure out which GTH port is the first memory controller: + +$ cat /sys/bus/intel_th/devices/0-msc0/port +0 + +# looks like it's port 0, configure master 33 to send data to port 0: + +$ echo 0 > /sys/bus/intel_th/devices/0-gth/masters/33 + +# allocate a 2-windowed multiblock buffer on the first memory +# controller, each with 64 pages: + +$ echo multi > /sys/bus/intel_th/devices/0-msc0/mode +$ echo 64,64 > /sys/bus/intel_th/devices/0-msc0/nr_pages + +# enable wrapping for this controller, too: + +$ echo 1 > /sys/bus/intel_th/devices/0-msc0/wrap + +# and enable tracing into this port: + +$ echo 1 > /sys/bus/intel_th/devices/0-msc0/active + +# .. send data to master 33, see stm.txt for more details .. +# .. wait for traces to pile up .. +# .. and stop the trace: + +$ echo 0 > /sys/bus/intel_th/devices/0-msc0/active + +# and now you can collect the trace from the device node: + +$ cat /dev/intel_th0/msc0 > my_stp_trace diff --git a/Documentation/trace/stm.txt b/Documentation/trace/stm.txt new file mode 100644 index 000000000..ea035f9db --- /dev/null +++ b/Documentation/trace/stm.txt @@ -0,0 +1,80 @@ +System Trace Module +=================== + +System Trace Module (STM) is a device described in MIPI STP specs as +STP trace stream generator. STP (System Trace Protocol) is a trace +protocol multiplexing data from multiple trace sources, each one of +which is assigned a unique pair of master and channel. While some of +these masters and channels are statically allocated to certain +hardware trace sources, others are available to software. Software +trace sources are usually free to pick for themselves any +master/channel combination from this pool. + +On the receiving end of this STP stream (the decoder side), trace +sources can only be identified by master/channel combination, so in +order for the decoder to be able to make sense of the trace that +involves multiple trace sources, it needs to be able to map those +master/channel pairs to the trace sources that it understands. + +For instance, it is helpful to know that syslog messages come on +master 7 channel 15, while arbitrary user applications can use masters +48 to 63 and channels 0 to 127. + +To solve this mapping problem, stm class provides a policy management +mechanism via configfs, that allows defining rules that map string +identifiers to ranges of masters and channels. If these rules (policy) +are consistent with what decoder expects, it will be able to properly +process the trace data. + +This policy is a tree structure containing rules (policy_node) that +have a name (string identifier) and a range of masters and channels +associated with it, located in "stp-policy" subsystem directory in +configfs. The topmost directory's name (the policy) is formatted as +the STM device name to which this policy applies and and arbitrary +string identifier separated by a stop. From the examle above, a rule +may look like this: + +$ ls /config/stp-policy/dummy_stm.my-policy/user +channels masters +$ cat /config/stp-policy/dummy_stm.my-policy/user/masters +48 63 +$ cat /config/stp-policy/dummy_stm.my-policy/user/channels +0 127 + +which means that the master allocation pool for this rule consists of +masters 48 through 63 and channel allocation pool has channels 0 +through 127 in it. Now, any producer (trace source) identifying itself +with "user" identification string will be allocated a master and +channel from within these ranges. + +These rules can be nested, for example, one can define a rule "dummy" +under "user" directory from the example above and this new rule will +be used for trace sources with the id string of "user/dummy". + +Trace sources have to open the stm class device's node and write their +trace data into its file descriptor. In order to identify themselves +to the policy, they need to do a STP_POLICY_ID_SET ioctl on this file +descriptor providing their id string. Otherwise, they will be +automatically allocated a master/channel pair upon first write to this +file descriptor according to the "default" rule of the policy, if such +exists. + +Some STM devices may allow direct mapping of the channel mmio regions +to userspace for zero-copy writing. One mappable page (in terms of +mmu) will usually contain multiple channels' mmios, so the user will +need to allocate that many channels to themselves (via the +aforementioned ioctl() call) to be able to do this. That is, if your +stm device's channel mmio region is 64 bytes and hardware page size is +4096 bytes, after a successful STP_POLICY_ID_SET ioctl() call with +width==64, you should be able to mmap() one page on this file +descriptor and obtain direct access to an mmio region for 64 channels. + +For kernel-based trace sources, there is "stm_source" device +class. Devices of this class can be connected and disconnected to/from +stm devices at runtime via a sysfs attribute. + +Examples of STM devices are Intel(R) Trace Hub [1] and Coresight STM +[2]. + +[1] https://software.intel.com/sites/default/files/managed/d3/3c/intel-th-developer-manual.pdf +[2] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0444b/index.html diff --git a/Documentation/usb/authorization.txt b/Documentation/usb/authorization.txt index c069b6884..c7e985f05 100644 --- a/Documentation/usb/authorization.txt +++ b/Documentation/usb/authorization.txt @@ -90,3 +90,34 @@ etc, but you get the idea. Anybody with access to a device gadget kit can fake descriptors and device info. Don't trust that. You are welcome. + +Interface authorization +----------------------- +There is a similar approach to allow or deny specific USB interfaces. +That allows to block only a subset of an USB device. + +Authorize an interface: +$ echo 1 > /sys/bus/usb/devices/INTERFACE/authorized + +Deauthorize an interface: +$ echo 0 > /sys/bus/usb/devices/INTERFACE/authorized + +The default value for new interfaces +on a particular USB bus can be changed, too. + +Allow interfaces per default: +$ echo 1 > /sys/bus/usb/devices/usbX/interface_authorized_default + +Deny interfaces per default: +$ echo 0 > /sys/bus/usb/devices/usbX/interface_authorized_default + +Per default the interface_authorized_default bit is 1. +So all interfaces would authorized per default. + +Note: +If a deauthorized interface will be authorized so the driver probing must +be triggered manually by writing INTERFACE to /sys/bus/usb/drivers_probe + +For drivers that need multiple interfaces all needed interfaces should be +authroized first. After that the drivers should be probed. +This avoids side effects. diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134 index f4b395bdc..282102014 100644 --- a/Documentation/video4linux/CARDLIST.saa7134 +++ b/Documentation/video4linux/CARDLIST.saa7134 @@ -193,3 +193,4 @@ 192 -> AverMedia AverTV Satellite Hybrid+FM A706 [1461:2055] 193 -> WIS Voyager or compatible [1905:7007] 194 -> AverMedia AverTV/505 [1461:a10a] +195 -> Leadtek Winfast TV2100 FM [107d:6f3a] diff --git a/Documentation/video4linux/v4l2-pci-skeleton.c b/Documentation/video4linux/v4l2-pci-skeleton.c index 9c80c090e..95ae82860 100644 --- a/Documentation/video4linux/v4l2-pci-skeleton.c +++ b/Documentation/video4linux/v4l2-pci-skeleton.c @@ -37,6 +37,7 @@ #include #include #include +#include #include MODULE_DESCRIPTION("V4L2 PCI Skeleton Driver"); @@ -162,10 +163,11 @@ static irqreturn_t skeleton_irq(int irq, void *dev_id) * minimum number: many DMA engines need a minimum of 2 buffers in the * queue and you need to have another available for userspace processing. */ -static int queue_setup(struct vb2_queue *vq, const struct v4l2_format *fmt, +static int queue_setup(struct vb2_queue *vq, const void *parg, unsigned int *nbuffers, unsigned int *nplanes, unsigned int sizes[], void *alloc_ctxs[]) { + const struct v4l2_format *fmt = parg; struct skeleton *skel = vb2_get_drv_priv(vq); skel->field = skel->format.field; diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index d9ecceea5..092ee9fba 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -401,10 +401,9 @@ Capability: basic Architectures: x86, ppc, mips Type: vcpu ioctl Parameters: struct kvm_interrupt (in) -Returns: 0 on success, -1 on error +Returns: 0 on success, negative on failure. -Queues a hardware interrupt vector to be injected. This is only -useful if in-kernel local APIC or equivalent is not used. +Queues a hardware interrupt vector to be injected. /* for KVM_INTERRUPT */ struct kvm_interrupt { @@ -414,7 +413,14 @@ struct kvm_interrupt { X86: -Note 'irq' is an interrupt vector, not an interrupt pin or line. +Returns: 0 on success, + -EEXIST if an interrupt is already enqueued + -EINVAL the the irq number is invalid + -ENXIO if the PIC is in the kernel + -EFAULT if the pointer is invalid + +Note 'irq' is an interrupt vector, not an interrupt pin or line. This +ioctl is useful if the in-kernel PIC is not used. PPC: @@ -1598,7 +1604,7 @@ provided event instead of triggering an exit. struct kvm_ioeventfd { __u64 datamatch; __u64 addr; /* legal pio/mmio address */ - __u32 len; /* 1, 2, 4, or 8 bytes */ + __u32 len; /* 0, 1, 2, 4, or 8 bytes */ __s32 fd; __u32 flags; __u8 pad[36]; @@ -1621,6 +1627,10 @@ to the registered address is equal to datamatch in struct kvm_ioeventfd. For virtio-ccw devices, addr contains the subchannel id and datamatch the virtqueue index. +With KVM_CAP_IOEVENTFD_ANY_LENGTH, a zero length ioeventfd is allowed, and +the kernel will ignore the length of guest write and may get a faster vmexit. +The speedup may only apply to specific architectures, but the ioeventfd will +work anyway. 4.60 KVM_DIRTY_TLB @@ -1774,7 +1784,7 @@ has been called, this interface is completely emulated within the kernel. To use this to emulate the LINT1 input with KVM_CREATE_IRQCHIP, use the following algorithm: - - pause the vpcu + - pause the vcpu - read the local APIC's state (KVM_GET_LAPIC) - check whether changing LINT1 will queue an NMI (see the LVT entry for LINT1) - if so, issue KVM_NMI @@ -2798,7 +2808,7 @@ Returns: = 0 on success, < 0 on generic error (e.g. -EFAULT or -ENOMEM), > 0 if an exception occurred while walking the page tables -Read or write data from/to the logical (virtual) memory of a VPCU. +Read or write data from/to the logical (virtual) memory of a VCPU. Parameters are specified via the following structure: @@ -3309,6 +3319,18 @@ Valid values for 'type' are: to ignore the request, or to gather VM memory core dump and/or reset/shutdown of the VM. + /* KVM_EXIT_IOAPIC_EOI */ + struct { + __u8 vector; + } eoi; + +Indicates that the VCPU's in-kernel local APIC received an EOI for a +level-triggered IOAPIC interrupt. This exit only triggers when the +IOAPIC is implemented in userspace (i.e. KVM_CAP_SPLIT_IRQCHIP is enabled); +the userspace IOAPIC should process the EOI and retrigger the interrupt if +it is still asserted. Vector is the LAPIC interrupt vector for which the +EOI was received. + /* Fix the size of the union. */ char padding[256]; }; @@ -3627,6 +3649,26 @@ struct { KVM handlers should exit to userspace with rc = -EREMOTE. +7.5 KVM_CAP_SPLIT_IRQCHIP + +Architectures: x86 +Parameters: args[0] - number of routes reserved for userspace IOAPICs +Returns: 0 on success, -1 on error + +Create a local apic for each processor in the kernel. This can be used +instead of KVM_CREATE_IRQCHIP if the userspace VMM wishes to emulate the +IOAPIC and PIC (and also the PIT, even though this has to be enabled +separately). + +This capability also enables in kernel routing of interrupt requests; +when KVM_CAP_SPLIT_IRQCHIP only routes of KVM_IRQ_ROUTING_MSI type are +used in the IRQ routing table. The first args[0] MSI routes are reserved +for the IOAPIC pins. Whenever the LAPIC receives an EOI for these routes, +a KVM_EXIT_IOAPIC_EOI vmexit will be reported to userspace. + +Fails if VCPU has already been created, or if the irqchip is already in the +kernel (i.e. KVM_CREATE_IRQCHIP has already been called). + 8. Other capabilities. ---------------------- diff --git a/Documentation/virtual/kvm/arm/vgic-mapped-irqs.txt b/Documentation/virtual/kvm/arm/vgic-mapped-irqs.txt new file mode 100644 index 000000000..38bca2835 --- /dev/null +++ b/Documentation/virtual/kvm/arm/vgic-mapped-irqs.txt @@ -0,0 +1,187 @@ +KVM/ARM VGIC Forwarded Physical Interrupts +========================================== + +The KVM/ARM code implements software support for the ARM Generic +Interrupt Controller's (GIC's) hardware support for virtualization by +allowing software to inject virtual interrupts to a VM, which the guest +OS sees as regular interrupts. The code is famously known as the VGIC. + +Some of these virtual interrupts, however, correspond to physical +interrupts from real physical devices. One example could be the +architected timer, which itself supports virtualization, and therefore +lets a guest OS program the hardware device directly to raise an +interrupt at some point in time. When such an interrupt is raised, the +host OS initially handles the interrupt and must somehow signal this +event as a virtual interrupt to the guest. Another example could be a +passthrough device, where the physical interrupts are initially handled +by the host, but the device driver for the device lives in the guest OS +and KVM must therefore somehow inject a virtual interrupt on behalf of +the physical one to the guest OS. + +These virtual interrupts corresponding to a physical interrupt on the +host are called forwarded physical interrupts, but are also sometimes +referred to as 'virtualized physical interrupts' and 'mapped interrupts'. + +Forwarded physical interrupts are handled slightly differently compared +to virtual interrupts generated purely by a software emulated device. + + +The HW bit +---------- +Virtual interrupts are signalled to the guest by programming the List +Registers (LRs) on the GIC before running a VCPU. The LR is programmed +with the virtual IRQ number and the state of the interrupt (Pending, +Active, or Pending+Active). When the guest ACKs and EOIs a virtual +interrupt, the LR state moves from Pending to Active, and finally to +inactive. + +The LRs include an extra bit, called the HW bit. When this bit is set, +KVM must also program an additional field in the LR, the physical IRQ +number, to link the virtual with the physical IRQ. + +When the HW bit is set, KVM must EITHER set the Pending OR the Active +bit, never both at the same time. + +Setting the HW bit causes the hardware to deactivate the physical +interrupt on the physical distributor when the guest deactivates the +corresponding virtual interrupt. + + +Forwarded Physical Interrupts Life Cycle +---------------------------------------- + +The state of forwarded physical interrupts is managed in the following way: + + - The physical interrupt is acked by the host, and becomes active on + the physical distributor (*). + - KVM sets the LR.Pending bit, because this is the only way the GICV + interface is going to present it to the guest. + - LR.Pending will stay set as long as the guest has not acked the interrupt. + - LR.Pending transitions to LR.Active on the guest read of the IAR, as + expected. + - On guest EOI, the *physical distributor* active bit gets cleared, + but the LR.Active is left untouched (set). + - KVM clears the LR on VM exits when the physical distributor + active state has been cleared. + +(*): The host handling is slightly more complicated. For some forwarded +interrupts (shared), KVM directly sets the active state on the physical +distributor before entering the guest, because the interrupt is never actually +handled on the host (see details on the timer as an example below). For other +forwarded interrupts (non-shared) the host does not deactivate the interrupt +when the host ISR completes, but leaves the interrupt active until the guest +deactivates it. Leaving the interrupt active is allowed, because Linux +configures the physical GIC with EOIMode=1, which causes EOI operations to +perform a priority drop allowing the GIC to receive other interrupts of the +default priority. + + +Forwarded Edge and Level Triggered PPIs and SPIs +------------------------------------------------ +Forwarded physical interrupts injected should always be active on the +physical distributor when injected to a guest. + +Level-triggered interrupts will keep the interrupt line to the GIC +asserted, typically until the guest programs the device to deassert the +line. This means that the interrupt will remain pending on the physical +distributor until the guest has reprogrammed the device. Since we +always run the VM with interrupts enabled on the CPU, a pending +interrupt will exit the guest as soon as we switch into the guest, +preventing the guest from ever making progress as the process repeats +over and over. Therefore, the active state on the physical distributor +must be set when entering the guest, preventing the GIC from forwarding +the pending interrupt to the CPU. As soon as the guest deactivates the +interrupt, the physical line is sampled by the hardware again and the host +takes a new interrupt if and only if the physical line is still asserted. + +Edge-triggered interrupts do not exhibit the same problem with +preventing guest execution that level-triggered interrupts do. One +option is to not use HW bit at all, and inject edge-triggered interrupts +from a physical device as pure virtual interrupts. But that would +potentially slow down handling of the interrupt in the guest, because a +physical interrupt occurring in the middle of the guest ISR would +preempt the guest for the host to handle the interrupt. Additionally, +if you configure the system to handle interrupts on a separate physical +core from that running your VCPU, you still have to interrupt the VCPU +to queue the pending state onto the LR, even though the guest won't use +this information until the guest ISR completes. Therefore, the HW +bit should always be set for forwarded edge-triggered interrupts. With +the HW bit set, the virtual interrupt is injected and additional +physical interrupts occurring before the guest deactivates the interrupt +simply mark the state on the physical distributor as Pending+Active. As +soon as the guest deactivates the interrupt, the host takes another +interrupt if and only if there was a physical interrupt between injecting +the forwarded interrupt to the guest and the guest deactivating the +interrupt. + +Consequently, whenever we schedule a VCPU with one or more LRs with the +HW bit set, the interrupt must also be active on the physical +distributor. + + +Forwarded LPIs +-------------- +LPIs, introduced in GICv3, are always edge-triggered and do not have an +active state. They become pending when a device signal them, and as +soon as they are acked by the CPU, they are inactive again. + +It therefore doesn't make sense, and is not supported, to set the HW bit +for physical LPIs that are forwarded to a VM as virtual interrupts, +typically virtual SPIs. + +For LPIs, there is no other choice than to preempt the VCPU thread if +necessary, and queue the pending state onto the LR. + + +Putting It Together: The Architected Timer +------------------------------------------ +The architected timer is a device that signals interrupts with level +triggered semantics. The timer hardware is directly accessed by VCPUs +which program the timer to fire at some point in time. Each VCPU on a +system programs the timer to fire at different times, and therefore the +hardware is multiplexed between multiple VCPUs. This is implemented by +context-switching the timer state along with each VCPU thread. + +However, this means that a scenario like the following is entirely +possible, and in fact, typical: + +1. KVM runs the VCPU +2. The guest programs the time to fire in T+100 +3. The guest is idle and calls WFI (wait-for-interrupts) +4. The hardware traps to the host +5. KVM stores the timer state to memory and disables the hardware timer +6. KVM schedules a soft timer to fire in T+(100 - time since step 2) +7. KVM puts the VCPU thread to sleep (on a waitqueue) +8. The soft timer fires, waking up the VCPU thread +9. KVM reprograms the timer hardware with the VCPU's values +10. KVM marks the timer interrupt as active on the physical distributor +11. KVM injects a forwarded physical interrupt to the guest +12. KVM runs the VCPU + +Notice that KVM injects a forwarded physical interrupt in step 11 without +the corresponding interrupt having actually fired on the host. That is +exactly why we mark the timer interrupt as active in step 10, because +the active state on the physical distributor is part of the state +belonging to the timer hardware, which is context-switched along with +the VCPU thread. + +If the guest does not idle because it is busy, the flow looks like this +instead: + +1. KVM runs the VCPU +2. The guest programs the time to fire in T+100 +4. At T+100 the timer fires and a physical IRQ causes the VM to exit + (note that this initially only traps to EL2 and does not run the host ISR + until KVM has returned to the host). +5. With interrupts still disabled on the CPU coming back from the guest, KVM + stores the virtual timer state to memory and disables the virtual hw timer. +6. KVM looks at the timer state (in memory) and injects a forwarded physical + interrupt because it concludes the timer has expired. +7. KVM marks the timer interrupt as active on the physical distributor +7. KVM enables the timer, enables interrupts, and runs the VCPU + +Notice that again the forwarded physical interrupt is injected to the +guest without having actually been handled on the host. In this case it +is because the physical interrupt is never actually seen by the host because the +timer is disabled upon guest return, and the virtual forwarded interrupt is +injected on the KVM guest entry path. diff --git a/Documentation/virtual/kvm/devices/arm-vgic.txt b/Documentation/virtual/kvm/devices/arm-vgic.txt index 3fb905429..59541d49e 100644 --- a/Documentation/virtual/kvm/devices/arm-vgic.txt +++ b/Documentation/virtual/kvm/devices/arm-vgic.txt @@ -44,28 +44,29 @@ Groups: Attributes: The attr field of kvm_device_attr encodes two values: bits: | 63 .... 40 | 39 .. 32 | 31 .... 0 | - values: | reserved | cpu id | offset | + values: | reserved | vcpu_index | offset | All distributor regs are (rw, 32-bit) The offset is relative to the "Distributor base address" as defined in the GICv2 specs. Getting or setting such a register has the same effect as - reading or writing the register on the actual hardware from the cpu - specified with cpu id field. Note that most distributor fields are not - banked, but return the same value regardless of the cpu id used to access - the register. + reading or writing the register on the actual hardware from the cpu whose + index is specified with the vcpu_index field. Note that most distributor + fields are not banked, but return the same value regardless of the + vcpu_index used to access the register. Limitations: - Priorities are not implemented, and registers are RAZ/WI - Currently only implemented for KVM_DEV_TYPE_ARM_VGIC_V2. Errors: - -ENODEV: Getting or setting this register is not yet supported + -ENXIO: Getting or setting this register is not yet supported -EBUSY: One or more VCPUs are running + -EINVAL: Invalid vcpu_index supplied KVM_DEV_ARM_VGIC_GRP_CPU_REGS Attributes: The attr field of kvm_device_attr encodes two values: bits: | 63 .... 40 | 39 .. 32 | 31 .... 0 | - values: | reserved | cpu id | offset | + values: | reserved | vcpu_index | offset | All CPU interface regs are (rw, 32-bit) @@ -91,8 +92,9 @@ Groups: - Priorities are not implemented, and registers are RAZ/WI - Currently only implemented for KVM_DEV_TYPE_ARM_VGIC_V2. Errors: - -ENODEV: Getting or setting this register is not yet supported + -ENXIO: Getting or setting this register is not yet supported -EBUSY: One or more VCPUs are running + -EINVAL: Invalid vcpu_index supplied KVM_DEV_ARM_VGIC_GRP_NR_IRQS Attributes: diff --git a/Documentation/virtual/kvm/devices/vm.txt b/Documentation/virtual/kvm/devices/vm.txt index 5542c4641..2d09d1ed8 100644 --- a/Documentation/virtual/kvm/devices/vm.txt +++ b/Documentation/virtual/kvm/devices/vm.txt @@ -74,7 +74,7 @@ struct kvm_s390_vm_cpu_processor { KVM does not enforce or limit the cpu model data in any form. Take the information retrieved by means of KVM_S390_VM_CPU_MACHINE as hint for reasonable configuration -setups. Instruction interceptions triggered by additionally set facilitiy bits that +setups. Instruction interceptions triggered by additionally set facility bits that are not handled by KVM need to by imlemented in the VM driver code. Parameters: address of buffer to store/set the processor related cpu diff --git a/Documentation/virtual/kvm/locking.txt b/Documentation/virtual/kvm/locking.txt index d68af4dc3..19f94a6b9 100644 --- a/Documentation/virtual/kvm/locking.txt +++ b/Documentation/virtual/kvm/locking.txt @@ -166,3 +166,15 @@ Comment: The srcu read lock must be held while accessing memslots (e.g. MMIO/PIO address->device structure mapping (kvm->buses). The srcu index can be stored in kvm_vcpu->srcu_idx per vcpu if it is needed by multiple functions. + +Name: blocked_vcpu_on_cpu_lock +Type: spinlock_t +Arch: x86 +Protects: blocked_vcpu_on_cpu +Comment: This is a per-CPU lock and it is used for VT-d posted-interrupts. + When VT-d posted-interrupts is supported and the VM has assigned + devices, we put the blocked vCPU on the list blocked_vcpu_on_cpu + protected by blocked_vcpu_on_cpu_lock, when VT-d hardware issues + wakeup notification event since external interrupts from the + assigned devices happens, we will find the vCPU on the list to + wakeup. diff --git a/Documentation/virtual/kvm/ppc-pv.txt b/Documentation/virtual/kvm/ppc-pv.txt index 319560646..e26115ce4 100644 --- a/Documentation/virtual/kvm/ppc-pv.txt +++ b/Documentation/virtual/kvm/ppc-pv.txt @@ -110,7 +110,7 @@ Flags are passed to the host in the low 12 bits of the Effective Address. The following flags are currently available for a guest to expose: - MAGIC_PAGE_FLAG_NOT_MAPPED_NX Guest handles NX bits correclty wrt magic page + MAGIC_PAGE_FLAG_NOT_MAPPED_NX Guest handles NX bits correctly wrt magic page MSR bits ======== diff --git a/Documentation/vm/balance b/Documentation/vm/balance index c46e68cf9..964595481 100644 --- a/Documentation/vm/balance +++ b/Documentation/vm/balance @@ -1,12 +1,14 @@ Started Jan 2000 by Kanoj Sarcar -Memory balancing is needed for non __GFP_WAIT as well as for non -__GFP_IO allocations. +Memory balancing is needed for !__GFP_ATOMIC and !__GFP_KSWAPD_RECLAIM as +well as for non __GFP_IO allocations. -There are two reasons to be requesting non __GFP_WAIT allocations: -the caller can not sleep (typically intr context), or does not want -to incur cost overheads of page stealing and possible swap io for -whatever reasons. +The first reason why a caller may avoid reclaim is that the caller can not +sleep due to holding a spinlock or is in interrupt context. The second may +be that the caller is willing to fail the allocation without incurring the +overhead of page reclaim. This may happen for opportunistic high-order +allocation requests that have order-0 fallback options. In such cases, +the caller may also wish to avoid waking kswapd. __GFP_IO allocation requests are made to prevent file system deadlocks. diff --git a/Documentation/vm/page_migration b/Documentation/vm/page_migration index 6513fe2d9..fea5c0864 100644 --- a/Documentation/vm/page_migration +++ b/Documentation/vm/page_migration @@ -92,29 +92,26 @@ Steps: 2. Insure that writeback is complete. -3. Prep the new page that we want to move to. It is locked - and set to not being uptodate so that all accesses to the new - page immediately lock while the move is in progress. +3. Lock the new page that we want to move to. It is locked so that accesses to + this (not yet uptodate) page immediately lock while the move is in progress. -4. The new page is prepped with some settings from the old page so that - accesses to the new page will discover a page with the correct settings. - -5. All the page table references to the page are converted - to migration entries or dropped (nonlinear vmas). - This decrease the mapcount of a page. If the resulting - mapcount is not zero then we do not migrate the page. - All user space processes that attempt to access the page - will now wait on the page lock. +4. All the page table references to the page are converted to migration + entries. This decreases the mapcount of a page. If the resulting + mapcount is not zero then we do not migrate the page. All user space + processes that attempt to access the page will now wait on the page lock. -6. The radix tree lock is taken. This will cause all processes trying +5. The radix tree lock is taken. This will cause all processes trying to access the page via the mapping to block on the radix tree spinlock. -7. The refcount of the page is examined and we back out if references remain +6. The refcount of the page is examined and we back out if references remain otherwise we know that we are the only one referencing this page. -8. The radix tree is checked and if it does not contain the pointer to this +7. The radix tree is checked and if it does not contain the pointer to this page then we back out because someone else modified the radix tree. +8. The new page is prepped with some settings from the old page so that + accesses to the new page will discover a page with the correct settings. + 9. The radix tree is changed to point to the new page. 10. The reference count of the old page is dropped because the radix tree diff --git a/Documentation/vm/slub.txt b/Documentation/vm/slub.txt index b0c6d1bbb..699d8ea5c 100644 --- a/Documentation/vm/slub.txt +++ b/Documentation/vm/slub.txt @@ -280,4 +280,63 @@ of other objects. slub_debug=FZ,dentry +Extended slabinfo mode and plotting +----------------------------------- + +The slabinfo tool has a special 'extended' ('-X') mode that includes: + - Slabcache Totals + - Slabs sorted by size (up to -N slabs, default 1) + - Slabs sorted by loss (up to -N slabs, default 1) + +Additionally, in this mode slabinfo does not dynamically scale sizes (G/M/K) +and reports everything in bytes (this functionality is also available to +other slabinfo modes via '-B' option) which makes reporting more precise and +accurate. Moreover, in some sense the `-X' mode also simplifies the analysis +of slabs' behaviour, because its output can be plotted using the +slabinfo-gnuplot.sh script. So it pushes the analysis from looking through +the numbers (tons of numbers) to something easier -- visual analysis. + +To generate plots: +a) collect slabinfo extended records, for example: + + while [ 1 ]; do slabinfo -X >> FOO_STATS; sleep 1; done + +b) pass stats file(-s) to slabinfo-gnuplot.sh script: + slabinfo-gnuplot.sh FOO_STATS [FOO_STATS2 .. FOO_STATSN] + +The slabinfo-gnuplot.sh script will pre-processes the collected records +and generates 3 png files (and 3 pre-processing cache files) per STATS +file: + - Slabcache Totals: FOO_STATS-totals.png + - Slabs sorted by size: FOO_STATS-slabs-by-size.png + - Slabs sorted by loss: FOO_STATS-slabs-by-loss.png + +Another use case, when slabinfo-gnuplot can be useful, is when you need +to compare slabs' behaviour "prior to" and "after" some code modification. +To help you out there, slabinfo-gnuplot.sh script can 'merge' the +`Slabcache Totals` sections from different measurements. To visually +compare N plots: + +a) Collect as many STATS1, STATS2, .. STATSN files as you need + while [ 1 ]; do slabinfo -X >> STATS; sleep 1; done + +b) Pre-process those STATS files + slabinfo-gnuplot.sh STATS1 STATS2 .. STATSN + +c) Execute slabinfo-gnuplot.sh in '-t' mode, passing all of the +generated pre-processed *-totals + slabinfo-gnuplot.sh -t STATS1-totals STATS2-totals .. STATSN-totals + +This will produce a single plot (png file). + +Plots, expectedly, can be large so some fluctuations or small spikes +can go unnoticed. To deal with that, `slabinfo-gnuplot.sh' has two +options to 'zoom-in'/'zoom-out': + a) -s %d,%d overwrites the default image width and heigh + b) -r %d,%d specifies a range of samples to use (for example, + in `slabinfo -X >> FOO_STATS; sleep 1;' case, using + a "-r 40,60" range will plot only samples collected + between 40th and 60th seconds). + Christoph Lameter, May 30, 2007 +Sergey Senozhatsky, October 23, 2015 diff --git a/Documentation/vm/split_page_table_lock b/Documentation/vm/split_page_table_lock index 6dea4fd5c..62842a857 100644 --- a/Documentation/vm/split_page_table_lock +++ b/Documentation/vm/split_page_table_lock @@ -54,8 +54,8 @@ everything required is done by pgtable_page_ctor() and pgtable_page_dtor(), which must be called on PTE table allocation / freeing. Make sure the architecture doesn't use slab allocator for page table -allocation: slab uses page->slab_cache and page->first_page for its pages. -These fields share storage with page->ptl. +allocation: slab uses page->slab_cache for its pages. +This field shares storage with page->ptl. PMD split lock only makes sense if you have more than two page table levels. diff --git a/Documentation/vm/transhuge.txt b/Documentation/vm/transhuge.txt index 8143b9e83..8a282687e 100644 --- a/Documentation/vm/transhuge.txt +++ b/Documentation/vm/transhuge.txt @@ -170,6 +170,16 @@ A lower value leads to gain less thp performance. Value of max_ptes_none can waste cpu time very little, you can ignore it. +max_ptes_swap specifies how many pages can be brought in from +swap when collapsing a group of pages into a transparent huge page. + +/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_swap + +A higher value can cause excessive swap IO and waste +memory. A lower value can prevent THPs from being +collapsed, resulting fewer pages being collapsed into +THPs, and lower memory access performance. + == Boot parameter == You can change the sysfs boot time defaults of Transparent Hugepage diff --git a/Documentation/vm/unevictable-lru.txt b/Documentation/vm/unevictable-lru.txt index 32ee3a67d..fa3b52708 100644 --- a/Documentation/vm/unevictable-lru.txt +++ b/Documentation/vm/unevictable-lru.txt @@ -531,83 +531,20 @@ map. try_to_unmap() is always called, by either vmscan for reclaim or for page migration, with the argument page locked and isolated from the LRU. Separate -functions handle anonymous and mapped file pages, as these types of pages have -different reverse map mechanisms. - - (*) try_to_unmap_anon() - - To unmap anonymous pages, each VMA in the list anchored in the anon_vma - must be visited - at least until a VM_LOCKED VMA is encountered. If the - page is being unmapped for migration, VM_LOCKED VMAs do not stop the - process because mlocked pages are migratable. However, for reclaim, if - the page is mapped into a VM_LOCKED VMA, the scan stops. - - try_to_unmap_anon() attempts to acquire in read mode the mmap semaphore of - the mm_struct to which the VMA belongs. If this is successful, it will - mlock the page via mlock_vma_page() - we wouldn't have gotten to - try_to_unmap_anon() if the page were already mlocked - and will return - SWAP_MLOCK, indicating that the page is unevictable. - - If the mmap semaphore cannot be acquired, we are not sure whether the page - is really unevictable or not. In this case, try_to_unmap_anon() will - return SWAP_AGAIN. - - (*) try_to_unmap_file() - linear mappings - - Unmapping of a mapped file page works the same as for anonymous mappings, - except that the scan visits all VMAs that map the page's index/page offset - in the page's mapping's reverse map priority search tree. It also visits - each VMA in the page's mapping's non-linear list, if the list is - non-empty. - - As for anonymous pages, on encountering a VM_LOCKED VMA for a mapped file - page, try_to_unmap_file() will attempt to acquire the associated - mm_struct's mmap semaphore to mlock the page, returning SWAP_MLOCK if this - is successful, and SWAP_AGAIN, if not. - - (*) try_to_unmap_file() - non-linear mappings - - If a page's mapping contains a non-empty non-linear mapping VMA list, then - try_to_un{map|lock}() must also visit each VMA in that list to determine - whether the page is mapped in a VM_LOCKED VMA. Again, the scan must visit - all VMAs in the non-linear list to ensure that the pages is not/should not - be mlocked. - - If a VM_LOCKED VMA is found in the list, the scan could terminate. - However, there is no easy way to determine whether the page is actually - mapped in a given VMA - either for unmapping or testing whether the - VM_LOCKED VMA actually pins the page. - - try_to_unmap_file() handles non-linear mappings by scanning a certain - number of pages - a "cluster" - in each non-linear VMA associated with the - page's mapping, for each file mapped page that vmscan tries to unmap. If - this happens to unmap the page we're trying to unmap, try_to_unmap() will - notice this on return (page_mapcount(page) will be 0) and return - SWAP_SUCCESS. Otherwise, it will return SWAP_AGAIN, causing vmscan to - recirculate this page. We take advantage of the cluster scan in - try_to_unmap_cluster() as follows: - - For each non-linear VMA, try_to_unmap_cluster() attempts to acquire the - mmap semaphore of the associated mm_struct for read without blocking. - - If this attempt is successful and the VMA is VM_LOCKED, - try_to_unmap_cluster() will retain the mmap semaphore for the scan; - otherwise it drops it here. - - Then, for each page in the cluster, if we're holding the mmap semaphore - for a locked VMA, try_to_unmap_cluster() calls mlock_vma_page() to - mlock the page. This call is a no-op if the page is already locked, - but will mlock any pages in the non-linear mapping that happen to be - unlocked. - - If one of the pages so mlocked is the page passed in to try_to_unmap(), - try_to_unmap_cluster() will return SWAP_MLOCK, rather than the default - SWAP_AGAIN. This will allow vmscan to cull the page, rather than - recirculating it on the inactive list. - - Again, if try_to_unmap_cluster() cannot acquire the VMA's mmap sem, it - returns SWAP_AGAIN, indicating that the page is mapped by a VM_LOCKED - VMA, but couldn't be mlocked. +functions handle anonymous and mapped file and KSM pages, as these types of +pages have different reverse map lookup mechanisms, with different locking. +In each case, whether rmap_walk_anon() or rmap_walk_file() or rmap_walk_ksm(), +it will call try_to_unmap_one() for every VMA which might contain the page. + +When trying to reclaim, if try_to_unmap_one() finds the page in a VM_LOCKED +VMA, it will then mlock the page via mlock_vma_page() instead of unmapping it, +and return SWAP_MLOCK to indicate that the page is unevictable: and the scan +stops there. + +mlock_vma_page() is called while holding the page table's lock (in addition +to the page lock, and the rmap lock): to serialize against concurrent mlock or +munlock or munmap system calls, mm teardown (munlock_vma_pages_all), reclaim, +holepunching, and truncation of file pages and their anonymous COWed pages. try_to_munlock() REVERSE MAP SCAN @@ -623,29 +560,15 @@ all PTEs from the page. For this purpose, the unevictable/mlock infrastructure introduced a variant of try_to_unmap() called try_to_munlock(). try_to_munlock() calls the same functions as try_to_unmap() for anonymous and -mapped file pages with an additional argument specifying unlock versus unmap +mapped file and KSM pages with a flag argument specifying unlock versus unmap processing. Again, these functions walk the respective reverse maps looking -for VM_LOCKED VMAs. When such a VMA is found for anonymous pages and file -pages mapped in linear VMAs, as in the try_to_unmap() case, the functions -attempt to acquire the associated mmap semaphore, mlock the page via -mlock_vma_page() and return SWAP_MLOCK. This effectively undoes the -pre-clearing of the page's PG_mlocked done by munlock_vma_page. - -If try_to_unmap() is unable to acquire a VM_LOCKED VMA's associated mmap -semaphore, it will return SWAP_AGAIN. This will allow shrink_page_list() to -recycle the page on the inactive list and hope that it has better luck with the -page next time. - -For file pages mapped into non-linear VMAs, the try_to_munlock() logic works -slightly differently. On encountering a VM_LOCKED non-linear VMA that might -map the page, try_to_munlock() returns SWAP_AGAIN without actually mlocking the -page. munlock_vma_page() will just leave the page unlocked and let vmscan deal -with it - the usual fallback position. +for VM_LOCKED VMAs. When such a VMA is found, as in the try_to_unmap() case, +the functions mlock the page via mlock_vma_page() and return SWAP_MLOCK. This +undoes the pre-clearing of the page's PG_mlocked done by munlock_vma_page. Note that try_to_munlock()'s reverse map walk must visit every VMA in a page's reverse map to determine that a page is NOT mapped into any VM_LOCKED VMA. -However, the scan can terminate when it encounters a VM_LOCKED VMA and can -successfully acquire the VMA's mmap semaphore for read and mlock the page. +However, the scan can terminate when it encounters a VM_LOCKED VMA. Although try_to_munlock() might be called a great many times when munlocking a large region or tearing down a large address space that has been mlocked via mlockall(), overall this is a fairly rare event. @@ -673,11 +596,6 @@ Some examples of these unevictable pages on the LRU lists are: (3) mlocked pages that could not be isolated from the LRU and moved to the unevictable list in mlock_vma_page(). - (4) Pages mapped into multiple VM_LOCKED VMAs, but try_to_munlock() couldn't - acquire the VMA's mmap semaphore to test the flags and set PageMlocked. - munlock_vma_page() was forced to let the page back on to the normal LRU - list for vmscan to handle. - shrink_inactive_list() also diverts any unevictable pages that it finds on the inactive lists to the appropriate zone's unevictable list. diff --git a/Documentation/w1/masters/omap-hdq b/Documentation/w1/masters/omap-hdq index 884dc284b..234522709 100644 --- a/Documentation/w1/masters/omap-hdq +++ b/Documentation/w1/masters/omap-hdq @@ -44,3 +44,9 @@ e.g: insmod omap_hdq.ko W1_ID=2 inamod w1_bq27000.ko F_ID=2 +The driver also supports 1-wire mode. In this mode, there is no need to +pass slave ID as parameter. The driver will auto-detect slaves connected +to the bus using SEARCH_ROM procedure. 1-wire mode can be selected by +setting "ti,mode" property to "1w" in DT (see +Documentation/devicetree/bindings/w1/omap-hdq.txt for more details). +By default driver is in HDQ mode. diff --git a/Documentation/zh_CN/filesystems/sysfs.txt b/Documentation/zh_CN/filesystems/sysfs.txt index e230eaa33..7d3b05edb 100644 --- a/Documentation/zh_CN/filesystems/sysfs.txt +++ b/Documentation/zh_CN/filesystems/sysfs.txt @@ -61,7 +61,7 @@ Documentation/kobject.txt 文档以获得更多关于 kobject 接口的 内核的对象层次到用户空间。sysfs 中的顶层目录代表着内核对象层次的 共同祖先；例如：某些对象属于某个子系统。 -Sysfs 在与其目录关联的 sysfs_dirent 对象中内部保存一个指向实现 +Sysfs 在与其目录关联的 kernfs_node 对象中内部保存一个指向实现 目录的 kobject 的指针。以前，这个 kobject 指针被 sysfs 直接用于 kobject 文件打开和关闭的引用计数。而现在的 sysfs 实现中，kobject 引用计数只能通过 sysfs_schedule_callback() 函数直接修改。 -- cgit v1.2.3-54-g00ecf