From b4a2c0055a4fb7bf34d0490284c966bea17f7117 Mon Sep 17 00:00:00 2001 From: Fabio Estevam Date: Mon, 18 Feb 2019 21:27:04 -0300 Subject: dt-bindings: Add vendor prefix for VXT Ltd VXT Ltd is a manufacturer of projected capacitive touch panel and display solutions: http://www.vxt.com.tw/ Reviewed-by: Otavio Salvador Reviewed-by: Rob Herring Signed-off-by: Fabio Estevam Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/20190219002706.20077-1-festevam@gmail.com --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 9506140167d6..433e03fbe078 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -442,6 +442,7 @@ vivante Vivante Corporation vocore VoCore Studio voipac Voipac Technologies s.r.o. vot Vision Optical Technology Co., Ltd. +vxt VXT Ltd wd Western Digital Corp. wetek WeTek Electronics, limited. wexler Wexler -- cgit v1.2.3-59-g8ed1b From 68c2edaca65165114e04daeb5f0af0e3e447c4a9 Mon Sep 17 00:00:00 2001 From: Fabio Estevam Date: Mon, 18 Feb 2019 21:27:05 -0300 Subject: dt-bindings: Add VXT VL050-8048NT-C01 panel bindings The VXT VL050-8048NT-C01 is a TFT LCD panel with a 800x480 resolution connected via 24 width parallel interface. Reviewed-by: Otavio Salvador Reviewed-by: Rob Herring Signed-off-by: Fabio Estevam Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/20190219002706.20077-2-festevam@gmail.com --- .../devicetree/bindings/display/panel/vl050_8048nt_c01.txt | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/vl050_8048nt_c01.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/vl050_8048nt_c01.txt b/Documentation/devicetree/bindings/display/panel/vl050_8048nt_c01.txt new file mode 100644 index 000000000000..b42bf06bbd99 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/vl050_8048nt_c01.txt @@ -0,0 +1,12 @@ +VXT 800x480 color TFT LCD panel + +Required properties: +- compatible: should be "vxt,vl050-8048nt-c01" +- power-supply: as specified in the base binding + +Optional properties: +- backlight: as specified in the base binding +- enable-gpios: as specified in the base binding + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. -- cgit v1.2.3-59-g8ed1b From 7a4f4c31c5bcd214707ec217a6cf067185f15cf3 Mon Sep 17 00:00:00 2001 From: Jonathan Bakker Date: Fri, 22 Feb 2019 18:51:52 +0100 Subject: dt-bindings: panel: Add Samsung S6E63M0 panel documentation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This commit adds documentation for Samsung S6E63M0 AMOLED LCD panel driver. Signed-off-by: Jonathan Bakker Signed-off-by: Paweł Chmiel Reviewed-by: Rob Herring Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/20190222175153.20567-1-pawel.mikolaj.chmiel@gmail.com --- .../bindings/display/panel/samsung,s6e63m0.txt | 33 ++++++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.txt b/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.txt new file mode 100644 index 000000000000..9fb9ebeef8e4 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e63m0.txt @@ -0,0 +1,33 @@ +Samsung s6e63m0 AMOLED LCD panel + +Required properties: + - compatible: "samsung,s6e63m0" + - reset-gpios: GPIO spec for reset pin + - vdd3-supply: VDD regulator + - vci-supply: VCI regulator + +The panel must obey rules for SPI slave device specified in document [1]. + +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/spi/spi-bus.txt +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt + +Example: + + s6e63m0: display@0 { + compatible = "samsung,s6e63m0"; + reg = <0>; + reset-gpio = <&mp05 5 1>; + vdd3-supply = <&ldo12_reg>; + vci-supply = <&ldo11_reg>; + spi-max-frequency = <1200000>; + + port { + lcd_ep: endpoint { + remote-endpoint = <&fimd_ep>; + }; + }; + }; -- cgit v1.2.3-59-g8ed1b From cc483ec1015a7926047281c497e5c7fac4b5df97 Mon Sep 17 00:00:00 2001 From: Peter Ujfalusi Date: Tue, 26 Feb 2019 09:55:20 +0200 Subject: dt-bindings: display: Add bindings for OSD101T2045-53TS This adds the device-tree bindings for the OSD101T2045-53TS 10.1" 1920x1200 panel from One Stop Displays. Signed-off-by: Peter Ujfalusi Reviewed-by: Rob Herring Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/20190226075523.28997-2-peter.ujfalusi@ti.com --- .../bindings/display/panel/osddisplays,osd101t2045-53ts.txt | 11 +++++++++++ 1 file changed, 11 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/osddisplays,osd101t2045-53ts.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/osddisplays,osd101t2045-53ts.txt b/Documentation/devicetree/bindings/display/panel/osddisplays,osd101t2045-53ts.txt new file mode 100644 index 000000000000..85c0b2cacfda --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/osddisplays,osd101t2045-53ts.txt @@ -0,0 +1,11 @@ +One Stop Displays OSD101T2045-53TS 10.1" 1920x1200 panel + +Required properties: +- compatible: should be "osddisplays,osd101t2045-53ts" +- power-supply: as specified in the base binding + +Optional properties: +- backlight: as specified in the base binding + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. -- cgit v1.2.3-59-g8ed1b From 2de67cf78e7a62fb938396f82682b7396a90be89 Mon Sep 17 00:00:00 2001 From: Peter Ujfalusi Date: Tue, 26 Feb 2019 09:55:22 +0200 Subject: dt-bindings: display: Add bindings for OSD101T2587-53TS panel This adds the device-tree bindings for the OSD101T2587-53TS 10.1" 1920x1200 panel from One Stop Displays. Note: the panel is similar to OSD101T2045-53TS, but it needs additional MIPI_DSI_TURN_ON_PERIPHERAL message from the host. Signed-off-by: Peter Ujfalusi Reviewed-by: Rob Herring Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/20190226075523.28997-4-peter.ujfalusi@ti.com --- .../display/panel/osddisplays,osd101t2587-53ts.txt | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/osddisplays,osd101t2587-53ts.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/osddisplays,osd101t2587-53ts.txt b/Documentation/devicetree/bindings/display/panel/osddisplays,osd101t2587-53ts.txt new file mode 100644 index 000000000000..9d88e96003fc --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/osddisplays,osd101t2587-53ts.txt @@ -0,0 +1,14 @@ +One Stop Displays OSD101T2587-53TS 10.1" 1920x1200 panel + +The panel is similar to OSD101T2045-53TS, but it needs additional +MIPI_DSI_TURN_ON_PERIPHERAL message from the host. + +Required properties: +- compatible: should be "osddisplays,osd101t2587-53ts" +- power-supply: as specified in the base binding + +Optional properties: +- backlight: as specified in the base binding + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. -- cgit v1.2.3-59-g8ed1b From fae186c8d63cadb5d1dc67735e8b3ed4e355b55c Mon Sep 17 00:00:00 2001 From: Marek Vasut Date: Tue, 19 Feb 2019 15:04:37 +0100 Subject: dt-bindings: display: Add ETM0430G0DH6 bindings Document the Emerging Display Technology Corp. (EDT) ETM0430G0DH6 display, which is a 480x272 4.3" TFT display. Signed-off-by: Marek Vasut Cc: Rob Herring Cc: Jan Tuerk Cc: Thierry Reding Cc: devicetree@vger.kernel.org Reviewed-by: Rob Herring Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/20190219140438.17063-1-marex@denx.de --- Documentation/devicetree/bindings/display/panel/edt,et-series.txt | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/edt,et-series.txt b/Documentation/devicetree/bindings/display/panel/edt,et-series.txt index f56b99ebd9be..d9f21d62422e 100644 --- a/Documentation/devicetree/bindings/display/panel/edt,et-series.txt +++ b/Documentation/devicetree/bindings/display/panel/edt,et-series.txt @@ -6,6 +6,14 @@ Display bindings for EDT Display Technology Corp. Displays which are compatible with the simple-panel binding, which is specified in simple-panel.txt +4,3" WVGA TFT Panels +-------------------- + ++-----------------+---------------------+-------------------------------------+ +| Identifier | compatbile | description | ++=================+=====================+=====================================+ +| ETM0430G0DH6 | edt,etm0430g0dh6 | 480x272 TFT Display | ++-----------------+---------------------+-------------------------------------+ 5,7" WVGA TFT Panels -------------------- -- cgit v1.2.3-59-g8ed1b From b1b0d36bdb157e46a049920aa2b607fd17489f4e Mon Sep 17 00:00:00 2001 From: Jyri Sarha Date: Fri, 22 Mar 2019 10:33:35 +0200 Subject: dt-bindings: drm/panel: simple: Add binding for TFC S9700RTWV43TR-01B Add bindign for TFC S9700RTWV43TR-01B 7" Three Five Corp 800x480 LCD panel with resistive touch. The panel is found on TI AM335x-evm. Signed-off-by: Jyri Sarha Reviewed-by: Rob Herring Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/24fea39438decd1e17a9c9afa320d49aca03f60d.1553243203.git.jsarha@ti.com --- .../bindings/display/panel/tfc,s9700rtwv43tr-01b.txt | 15 +++++++++++++++ Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 2 files changed, 16 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/tfc,s9700rtwv43tr-01b.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/tfc,s9700rtwv43tr-01b.txt b/Documentation/devicetree/bindings/display/panel/tfc,s9700rtwv43tr-01b.txt new file mode 100644 index 000000000000..dfb572f085eb --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/tfc,s9700rtwv43tr-01b.txt @@ -0,0 +1,15 @@ +TFC S9700RTWV43TR-01B 7" Three Five Corp 800x480 LCD panel with +resistive touch + +The panel is found on TI AM335x-evm. + +Required properties: +- compatible: should be "tfc,s9700rtwv43tr-01b" +- power-supply: See panel-common.txt + +Optional properties: +- enable-gpios: GPIO pin to enable or disable the panel, if there is one +- backlight: phandle of the backlight device attached to the panel + +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/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 433e03fbe078..b46a2752eb88 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -406,6 +406,7 @@ technologic Technologic Systems tempo Tempo Semiconductor techstar Shenzhen Techstar Electronics Co., Ltd. terasic Terasic Inc. +tfc Three Five Corp thine THine Electronics, Inc. ti Texas Instruments tianma Tianma Micro-electronics Co., Ltd. -- cgit v1.2.3-59-g8ed1b From c9219ae4bd5db34a3b14e1e01bed2c7ef2ad9a16 Mon Sep 17 00:00:00 2001 From: Marco Felsch Date: Tue, 16 Apr 2019 12:16:29 +0200 Subject: dt-bindings: display: add EDT ET035012DM6 display description Add support for the ET035012DM6 3.5" QVGA TFT LCD panel. The datasheet can be retrieved online: https://www.glynshop.com/erp/owweb/Daten/DSS/EDT/Products/ \ Specifications/Active%20Displays/ET035012DM6.pdf Signed-off-by: Marco Felsch Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/20190416101630.3482-1-m.felsch@pengutronix.de --- Documentation/devicetree/bindings/display/panel/edt,et-series.txt | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/edt,et-series.txt b/Documentation/devicetree/bindings/display/panel/edt,et-series.txt index d9f21d62422e..be8684327ee4 100644 --- a/Documentation/devicetree/bindings/display/panel/edt,et-series.txt +++ b/Documentation/devicetree/bindings/display/panel/edt,et-series.txt @@ -6,6 +6,14 @@ Display bindings for EDT Display Technology Corp. Displays which are compatible with the simple-panel binding, which is specified in simple-panel.txt +3,5" QVGA TFT Panels +-------------------- ++-----------------+---------------------+-------------------------------------+ +| Identifier | compatbile | description | ++=================+=====================+=====================================+ +| ET035012DM6 | edt,et035012dm6 | 3.5" QVGA TFT LCD panel | ++-----------------+---------------------+-------------------------------------+ + 4,3" WVGA TFT Panels -------------------- -- cgit v1.2.3-59-g8ed1b From fbd8b69ab61669cd9d11dbccfb0f0ee42862af67 Mon Sep 17 00:00:00 2001 From: Marco Felsch Date: Tue, 16 Apr 2019 12:06:43 +0200 Subject: dt-bindings: Add vendor prefix for Evervision Electronics Evervision Electronics is a panel manufacturer from Taipei. http://www.evervisionlcd.com/index.php?lang=en Signed-off-by: Marco Felsch Reviewed-by: Rob Herring Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/20190416100645.21689-2-m.felsch@pengutronix.de --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index b46a2752eb88..873dbafa6698 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -132,6 +132,7 @@ ettus NI Ettus Research eukrea Eukréa Electromatique everest Everest Semiconductor Co. Ltd. everspin Everspin Technologies, Inc. +evervision Evervision Electronics Co. Ltd. exar Exar Corporation excito Excito ezchip EZchip Semiconductor -- cgit v1.2.3-59-g8ed1b From 81c2d54ad97765e837733172f81415fe5006d5fb Mon Sep 17 00:00:00 2001 From: Marco Felsch Date: Tue, 16 Apr 2019 12:06:44 +0200 Subject: dt-bindings: Add Evervision VGG804821 panel Add device tree bindings for the Evervision VG804821 800x480 5.0" LCD TFT parallel panel. Signed-off-by: Marco Felsch Reviewed-by: Rob Herring Signed-off-by: Thierry Reding Link: https://patchwork.freedesktop.org/patch/msgid/20190416100645.21689-3-m.felsch@pengutronix.de --- .../bindings/display/panel/evervision,vgg804821.txt | 12 ++++++++++++ 1 file changed, 12 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/evervision,vgg804821.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/evervision,vgg804821.txt b/Documentation/devicetree/bindings/display/panel/evervision,vgg804821.txt new file mode 100644 index 000000000000..82d22e191ac3 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/evervision,vgg804821.txt @@ -0,0 +1,12 @@ +Evervision Electronics Co. Ltd. VGG804821 5.0" WVGA TFT LCD Panel + +Required properties: +- compatible: should be "evervision,vgg804821" +- power-supply: See simple-panel.txt + +Optional properties: +- backlight: See simple-panel.txt +- enable-gpios: See simple-panel.txt + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. -- cgit v1.2.3-59-g8ed1b From 40e64432ce98f4ee5671d39fbf909ef3f3592366 Mon Sep 17 00:00:00 2001 From: Brian Masney Date: Thu, 25 Apr 2019 19:03:14 -0400 Subject: dt-bindings: iio: tsl2583: convert bindings to YAML format Convert the tsl2583 device tree bindings to the new YAML format. Signed-off-by: Brian Masney Reviewed-by: Rob Herring Signed-off-by: Jonathan Cameron --- .../devicetree/bindings/iio/light/tsl2583.txt | 25 ------------ .../devicetree/bindings/iio/light/tsl2583.yaml | 46 ++++++++++++++++++++++ 2 files changed, 46 insertions(+), 25 deletions(-) delete mode 100644 Documentation/devicetree/bindings/iio/light/tsl2583.txt create mode 100644 Documentation/devicetree/bindings/iio/light/tsl2583.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/light/tsl2583.txt b/Documentation/devicetree/bindings/iio/light/tsl2583.txt deleted file mode 100644 index 059dffa1829a..000000000000 --- a/Documentation/devicetree/bindings/iio/light/tsl2583.txt +++ /dev/null @@ -1,25 +0,0 @@ -* TAOS TSL 2580/2581/2583 ALS sensor - -Required properties: - - - compatible: Should be one of - "amstaos,tsl2580" - "amstaos,tsl2581" - "amstaos,tsl2583" - - reg: the I2C address of the device - -Optional properties: - - - interrupts: the sole interrupt generated by the device - - Refer to interrupt-controller/interrupts.txt for generic interrupt client - node bindings. - - - vcc-supply: phandle to the regulator that provides power to the sensor. - -Example: - -tsl2581@29 { - compatible = "amstaos,tsl2581"; - reg = <0x29>; -}; diff --git a/Documentation/devicetree/bindings/iio/light/tsl2583.yaml b/Documentation/devicetree/bindings/iio/light/tsl2583.yaml new file mode 100644 index 000000000000..e86ef64ecf03 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/light/tsl2583.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/light/tsl2583.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: AMS/TAOS Ambient Light Sensor (ALS) + +maintainers: + - Brian Masney + +description: | + Ambient light sensing with an i2c interface. + +properties: + compatible: + enum: + - amstaos,tsl2580 + - amstaos,tsl2581 + - amstaos,tsl2583 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + vcc-supply: + description: Regulator that provides power to the sensor + +required: + - compatible + - reg + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + light-sensor@29 { + compatible = "amstaos,tsl2581"; + reg = <0x29>; + }; + }; +... -- cgit v1.2.3-59-g8ed1b From 17b62779cbe40773e10a83af000e51c29b764575 Mon Sep 17 00:00:00 2001 From: Brian Masney Date: Thu, 25 Apr 2019 19:03:13 -0400 Subject: dt-bindings: iio: tsl2772: convert bindings to YAML format Convert the tsl2772 device tree bindings to the new YAML format. Signed-off-by: Brian Masney Reviewed-by: Rob Herring Signed-off-by: Jonathan Cameron --- .../devicetree/bindings/iio/light/tsl2772.txt | 42 ----------- .../devicetree/bindings/iio/light/tsl2772.yaml | 83 ++++++++++++++++++++++ 2 files changed, 83 insertions(+), 42 deletions(-) delete mode 100644 Documentation/devicetree/bindings/iio/light/tsl2772.txt create mode 100644 Documentation/devicetree/bindings/iio/light/tsl2772.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/light/tsl2772.txt b/Documentation/devicetree/bindings/iio/light/tsl2772.txt deleted file mode 100644 index 1c5e6f17a1df..000000000000 --- a/Documentation/devicetree/bindings/iio/light/tsl2772.txt +++ /dev/null @@ -1,42 +0,0 @@ -* AMS/TAOS ALS and proximity sensor - -Required properties: - - - compatible: Should be one of - "amstaos,tsl2571" - "amstaos,tsl2671" - "amstaos,tmd2671" - "amstaos,tsl2771" - "amstaos,tmd2771" - "amstaos,tsl2572" - "amstaos,tsl2672" - "amstaos,tmd2672" - "amstaos,tsl2772" - "amstaos,tmd2772" - "avago,apds9930" - - reg: the I2C address of the device - -Optional properties: - - - amstaos,proximity-diodes - proximity diodes to enable. <0>, <1>, or <0 1> - are the only valid values. - - led-max-microamp - current for the proximity LED. Must be 100000, 50000, - 25000, or 13000. - - vdd-supply: phandle to the regulator that provides power to the sensor. - - vddio-supply: phandle to the regulator that provides power to the bus. - - interrupts: the sole interrupt generated by the device - - Refer to interrupt-controller/interrupts.txt for generic interrupt client - node bindings. - -Example: - -tsl2772@39 { - compatible = "amstaos,tsl2772"; - reg = <0x39>; - interrupts-extended = <&msmgpio 61 IRQ_TYPE_EDGE_FALLING>; - vdd-supply = <&pm8941_l17>; - vddio-supply = <&pm8941_lvs1>; - amstaos,proximity-diodes = <0>; - led-max-microamp = <100000>; -}; diff --git a/Documentation/devicetree/bindings/iio/light/tsl2772.yaml b/Documentation/devicetree/bindings/iio/light/tsl2772.yaml new file mode 100644 index 000000000000..ed2c3d5eadf5 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/light/tsl2772.yaml @@ -0,0 +1,83 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/light/tsl2772.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: AMS/TAOS Ambient Light Sensor (ALS) and Proximity Detector + +maintainers: + - Brian Masney + +description: | + Ambient light sensing and proximity detection with an i2c interface. + https://ams.com/documents/20143/36005/TSL2772_DS000181_2-00.pdf + +properties: + compatible: + enum: + - amstaos,tsl2571 + - amstaos,tsl2671 + - amstaos,tmd2671 + - amstaos,tsl2771 + - amstaos,tmd2771 + - amstaos,tsl2572 + - amstaos,tsl2672 + - amstaos,tmd2672 + - amstaos,tsl2772 + - amstaos,tmd2772 + - avago,apds9930 + + reg: + maxItems: 1 + + amstaos,proximity-diodes: + description: Proximity diodes to enable + allOf: + - $ref: /schemas/types.yaml#/definitions/uint32-array + - minItems: 1 + maxItems: 2 + items: + minimum: 0 + maximum: 1 + + interrupts: + maxItems: 1 + + led-max-microamp: + description: Current for the proximity LED + enum: + - 13000 + - 25000 + - 50000 + - 100000 + + vdd-supply: + description: Regulator that provides power to the sensor + + vddio-supply: + description: Regulator that provides power to the bus + +required: + - compatible + - reg + +examples: + - | + #include + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + sensor@39 { + compatible = "amstaos,tsl2772"; + reg = <0x39>; + interrupts-extended = <&msmgpio 61 IRQ_TYPE_EDGE_FALLING>; + vdd-supply = <&pm8941_l17>; + vddio-supply = <&pm8941_lvs1>; + amstaos,proximity-diodes = <0>; + led-max-microamp = <100000>; + }; + }; +... -- cgit v1.2.3-59-g8ed1b From 8b7a6a35746292e140304107e60f9a980416abf7 Mon Sep 17 00:00:00 2001 From: Gwendal Grignou Date: Fri, 26 Apr 2019 13:39:16 +0200 Subject: iio: cros_ec: add 'id' sysfs entry This new sysfs entry is used to interpret ring buffer information, mainly by Android sensor HAL. It expand to all sensors, the documentation about 'id' we can found in Documentation/ABI/testing/sysfs-bus-iio-cros-ec. Also fix typo in docs, I replace 'Septembre' by 'September'. Signed-off-by: Gwendal Grignou Signed-off-by: Fabien Lahoudere Signed-off-by: Jonathan Cameron --- Documentation/ABI/testing/sysfs-bus-iio-cros-ec | 10 +++++----- drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c | 14 ++++++++++++++ 2 files changed, 19 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-iio-cros-ec b/Documentation/ABI/testing/sysfs-bus-iio-cros-ec index 0e95c2ca105c..6158f831c761 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio-cros-ec +++ b/Documentation/ABI/testing/sysfs-bus-iio-cros-ec @@ -18,11 +18,11 @@ Description: values are 'base' and 'lid'. What: /sys/bus/iio/devices/iio:deviceX/id -Date: Septembre 2017 +Date: September 2017 KernelVersion: 4.14 Contact: linux-iio@vger.kernel.org Description: - This attribute is exposed by the CrOS EC legacy accelerometer - driver and represents the sensor ID as exposed by the EC. This - ID is used by the Android sensor service hardware abstraction - layer (sensor HAL) through the Android container on ChromeOS. + This attribute is exposed by the CrOS EC sensors driver and + represents the sensor ID as exposed by the EC. This ID is used + by the Android sensor service hardware abstraction layer (sensor + HAL) through the Android container on ChromeOS. diff --git a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c index 719a0df5aeeb..130362ca421b 100644 --- a/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c +++ b/drivers/iio/common/cros_ec_sensors/cros_ec_sensors_core.c @@ -125,6 +125,15 @@ static ssize_t cros_ec_sensors_calibrate(struct iio_dev *indio_dev, return ret ? ret : len; } +static ssize_t cros_ec_sensors_id(struct iio_dev *indio_dev, + uintptr_t private, + const struct iio_chan_spec *chan, char *buf) +{ + struct cros_ec_sensors_core_state *st = iio_priv(indio_dev); + + return snprintf(buf, PAGE_SIZE, "%d\n", st->param.info.sensor_num); +} + static ssize_t cros_ec_sensors_loc(struct iio_dev *indio_dev, uintptr_t private, const struct iio_chan_spec *chan, char *buf) @@ -140,6 +149,11 @@ const struct iio_chan_spec_ext_info cros_ec_sensors_ext_info[] = { .shared = IIO_SHARED_BY_ALL, .write = cros_ec_sensors_calibrate }, + { + .name = "id", + .shared = IIO_SHARED_BY_ALL, + .read = cros_ec_sensors_id + }, { .name = "location", .shared = IIO_SHARED_BY_ALL, -- cgit v1.2.3-59-g8ed1b From 788033a92a4def4c966296be0276100954841ab2 Mon Sep 17 00:00:00 2001 From: Sam Ravnborg Date: Sat, 26 Jan 2019 20:27:32 +0100 Subject: drm: drop drm_bus from todo David Herrmann removed the last bits of drm_bus in: commit c5786fe5f1c5 ("drm: Goody bye, drm_bus!") Remove the todo item. Signed-off-by: Sam Ravnborg Reviewed-by: David Herrmann [I miss drm_bus!] Cc: David Airlie Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20190126192732.15263-1-sam@ravnborg.org Link: https://patchwork.freedesktop.org/patch/msgid/20190126192732.15263-1-sam@ravnborg.org --- Documentation/gpu/todo.rst | 19 ------------------- 1 file changed, 19 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 1528ad2d598b..06ccff9165d5 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -10,25 +10,6 @@ graphics subsystem useful as newbie projects. Or for slow rainy days. Subsystem-wide refactorings =========================== -De-midlayer drivers -------------------- - -With the recent ``drm_bus`` cleanup patches for 3.17 it is no longer required -to have a ``drm_bus`` structure set up. Drivers can directly set up the -``drm_device`` structure instead of relying on bus methods in ``drm_usb.c`` -and ``drm_pci.c``. The goal is to get rid of the driver's ``->load`` / -``->unload`` callbacks and open-code the load/unload sequence properly, using -the new two-stage ``drm_device`` setup/teardown. - -Once all existing drivers are converted we can also remove those bus support -files for USB and platform devices. - -All you need is a GPU for a non-converted driver (currently almost all of -them, but also all the virtual ones used by KVM, so everyone qualifies). - -Contact: Daniel Vetter, Thierry Reding, respective driver maintainers - - Remove custom dumb_map_offset implementations --------------------------------------------- -- cgit v1.2.3-59-g8ed1b From 7e527e11d672e90f1a3dc8de84e0bfaccda15bba Mon Sep 17 00:00:00 2001 From: Tomas Winkler Date: Mon, 3 Jun 2019 12:14:00 +0300 Subject: mei: docs: move documentation under driver-api Move mei driver documentation under Documentation/driver-api/ Perform some minimal formating changes to produce correct sphinx rendering and add index.rst Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman --- Documentation/driver-api/index.rst | 1 + Documentation/driver-api/mei/index.rst | 22 ++ Documentation/driver-api/mei/mei-client-bus.rst | 152 +++++++++++++ Documentation/driver-api/mei/mei.rst | 250 ++++++++++++++++++++ Documentation/misc-devices/mei/mei-client-bus.txt | 141 ------------ Documentation/misc-devices/mei/mei.txt | 266 ---------------------- MAINTAINERS | 2 +- 7 files changed, 426 insertions(+), 408 deletions(-) create mode 100644 Documentation/driver-api/mei/index.rst create mode 100644 Documentation/driver-api/mei/mei-client-bus.rst create mode 100644 Documentation/driver-api/mei/mei.rst delete mode 100644 Documentation/misc-devices/mei/mei-client-bus.txt delete mode 100644 Documentation/misc-devices/mei/mei.txt (limited to 'Documentation') diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst index d26308af6036..0dbaa987aa11 100644 --- a/Documentation/driver-api/index.rst +++ b/Documentation/driver-api/index.rst @@ -42,6 +42,7 @@ available subsections can be seen below. target mtdnand miscellaneous + mei/index w1 rapidio s390-drivers diff --git a/Documentation/driver-api/mei/index.rst b/Documentation/driver-api/mei/index.rst new file mode 100644 index 000000000000..35c1117d8366 --- /dev/null +++ b/Documentation/driver-api/mei/index.rst @@ -0,0 +1,22 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. include:: + +=================================================== +Intel(R) Management Engine Interface (Intel(R) MEI) +=================================================== + +**Copyright** |copy| 2019 Intel Corporation + + +.. only:: html + + .. class:: toc-title + + Table of Contents + +.. toctree:: + :maxdepth: 2 + + mei + mei-client-bus diff --git a/Documentation/driver-api/mei/mei-client-bus.rst b/Documentation/driver-api/mei/mei-client-bus.rst new file mode 100644 index 000000000000..a26a85453bdf --- /dev/null +++ b/Documentation/driver-api/mei/mei-client-bus.rst @@ -0,0 +1,152 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================================== +Intel(R) Management Engine (ME) Client bus API +============================================== + + +Rationale +========= + +MEI misc character device is useful for dedicated applications to send and receive +data to the many FW appliance found in Intel's ME from the user space. +However for some of the ME functionalities it make sense to leverage existing software +stack and expose them through existing kernel subsystems. + +In order to plug seamlessly into the kernel device driver model we add kernel virtual +bus abstraction on top of the MEI driver. This allows implementing linux kernel drivers +for the various MEI features as a stand alone entities found in their respective subsystem. +Existing device drivers can even potentially be re-used by adding an MEI CL bus layer to +the existing code. + + +MEI CL bus API +============== + +A driver implementation for an MEI Client is very similar to existing bus +based device drivers. The driver registers itself as an MEI CL bus driver through +the ``struct mei_cl_driver`` structure: + +.. code-block:: C + + struct mei_cl_driver { + struct device_driver driver; + const char *name; + + const struct mei_cl_device_id *id_table; + + int (*probe)(struct mei_cl_device *dev, const struct mei_cl_id *id); + int (*remove)(struct mei_cl_device *dev); + }; + + struct mei_cl_id { + char name[MEI_NAME_SIZE]; + kernel_ulong_t driver_info; + }; + +The mei_cl_id structure allows the driver to bind itself against a device name. + +To actually register a driver on the ME Client bus one must call the mei_cl_add_driver() +API. This is typically called at module init time. + +Once registered on the ME Client bus, a driver will typically try to do some I/O on +this bus and this should be done through the mei_cl_send() and mei_cl_recv() +routines. The latter is synchronous (blocks and sleeps until data shows up). +In order for drivers to be notified of pending events waiting for them (e.g. +an Rx event) they can register an event handler through the +mei_cl_register_event_cb() routine. Currently only the MEI_EVENT_RX event +will trigger an event handler call and the driver implementation is supposed +to call mei_recv() from the event handler in order to fetch the pending +received buffers. + + +Example +======= + +As a theoretical example let's pretend the ME comes with a "contact" NFC IP. +The driver init and exit routines for this device would look like: + +.. code-block:: C + + #define CONTACT_DRIVER_NAME "contact" + + static struct mei_cl_device_id contact_mei_cl_tbl[] = { + { CONTACT_DRIVER_NAME, }, + + /* required last entry */ + { } + }; + MODULE_DEVICE_TABLE(mei_cl, contact_mei_cl_tbl); + + static struct mei_cl_driver contact_driver = { + .id_table = contact_mei_tbl, + .name = CONTACT_DRIVER_NAME, + + .probe = contact_probe, + .remove = contact_remove, + }; + + static int contact_init(void) + { + int r; + + r = mei_cl_driver_register(&contact_driver); + if (r) { + pr_err(CONTACT_DRIVER_NAME ": driver registration failed\n"); + return r; + } + + return 0; + } + + static void __exit contact_exit(void) + { + mei_cl_driver_unregister(&contact_driver); + } + + module_init(contact_init); + module_exit(contact_exit); + +And the driver's simplified probe routine would look like that: + +.. code-block:: C + + int contact_probe(struct mei_cl_device *dev, struct mei_cl_device_id *id) + { + struct contact_driver *contact; + + [...] + mei_cl_enable_device(dev); + + mei_cl_register_event_cb(dev, contact_event_cb, contact); + + return 0; + } + +In the probe routine the driver first enable the MEI device and then registers +an ME bus event handler which is as close as it can get to registering a +threaded IRQ handler. +The handler implementation will typically call some I/O routine depending on +the pending events: + +#define MAX_NFC_PAYLOAD 128 + +.. code-block:: C + + static void contact_event_cb(struct mei_cl_device *dev, u32 events, + void *context) + { + struct contact_driver *contact = context; + + if (events & BIT(MEI_EVENT_RX)) { + u8 payload[MAX_NFC_PAYLOAD]; + int payload_size; + + payload_size = mei_recv(dev, payload, MAX_NFC_PAYLOAD); + if (payload_size <= 0) + return; + + /* Hook to the NFC subsystem */ + nfc_hci_recv_frame(contact->hdev, payload, payload_size); + } + } diff --git a/Documentation/driver-api/mei/mei.rst b/Documentation/driver-api/mei/mei.rst new file mode 100644 index 000000000000..5aa3a5e6496a --- /dev/null +++ b/Documentation/driver-api/mei/mei.rst @@ -0,0 +1,250 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Introduction +============ + +The Intel Management Engine (Intel ME) is an isolated and protected computing +resource (Co-processor) residing inside certain Intel chipsets. The Intel ME +provides support for computer/IT management features. The feature set +depends on the Intel chipset SKU. + +The Intel Management Engine Interface (Intel MEI, previously known as HECI) +is the interface between the Host and Intel ME. This interface is exposed +to the host as a PCI device. The Intel MEI Driver is in charge of the +communication channel between a host application and the Intel ME feature. + +Each Intel ME feature (Intel ME Client) is addressed by a GUID/UUID and +each client has its own protocol. The protocol is message-based with a +header and payload up to 512 bytes. + +Prominent usage of the Intel ME Interface is to communicate with Intel(R) +Active Management Technology (Intel AMT) implemented in firmware running on +the Intel ME. + +Intel AMT provides the ability to manage a host remotely out-of-band (OOB) +even when the operating system running on the host processor has crashed or +is in a sleep state. + +Some examples of Intel AMT usage are: + - Monitoring hardware state and platform components + - Remote power off/on (useful for green computing or overnight IT + maintenance) + - OS updates + - Storage of useful platform information such as software assets + - Built-in hardware KVM + - Selective network isolation of Ethernet and IP protocol flows based + on policies set by a remote management console + - IDE device redirection from remote management console + +Intel AMT (OOB) communication is based on SOAP (deprecated +starting with Release 6.0) over HTTP/S or WS-Management protocol over +HTTP/S that are received from a remote management console application. + +For more information about Intel AMT: +http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide + + +Intel MEI Driver +================ + +The driver exposes a misc device called /dev/mei. + +An application maintains communication with an Intel ME feature while +/dev/mei is open. The binding to a specific feature is performed by calling +MEI_CONNECT_CLIENT_IOCTL, which passes the desired UUID. +The number of instances of an Intel ME feature that can be opened +at the same time depends on the Intel ME feature, but most of the +features allow only a single instance. + +The Intel AMT Host Interface (Intel AMTHI) feature supports multiple +simultaneous user connected applications. The Intel MEI driver +handles this internally by maintaining request queues for the applications. + +The driver is transparent to data that are passed between firmware feature +and host application. + +Because some of the Intel ME features can change the system +configuration, the driver by default allows only a privileged +user to access it. + +A code snippet for an application communicating with Intel AMTHI client: + +.. code-block:: C + + struct mei_connect_client_data data; + fd = open(MEI_DEVICE); + + data.d.in_client_uuid = AMTHI_UUID; + + ioctl(fd, IOCTL_MEI_CONNECT_CLIENT, &data); + + printf("Ver=%d, MaxLen=%ld\n", + data.d.in_client_uuid.protocol_version, + data.d.in_client_uuid.max_msg_length); + + [...] + + write(fd, amthi_req_data, amthi_req_data_len); + + [...] + + read(fd, &amthi_res_data, amthi_res_data_len); + + [...] + close(fd); + + +IOCTLs +====== + +The Intel MEI Driver supports the following IOCTL commands: + IOCTL_MEI_CONNECT_CLIENT Connect to firmware Feature (client). + + usage: + struct mei_connect_client_data clientData; + ioctl(fd, IOCTL_MEI_CONNECT_CLIENT, &clientData); + + inputs: + mei_connect_client_data struct contain the following + input field: + + in_client_uuid - UUID of the FW Feature that needs + to connect to. + outputs: + out_client_properties - Client Properties: MTU and Protocol Version. + + error returns: + EINVAL Wrong IOCTL Number + ENODEV Device or Connection is not initialized or ready. (e.g. Wrong UUID) + ENOMEM Unable to allocate memory to client internal data. + EFAULT Fatal Error (e.g. Unable to access user input data) + EBUSY Connection Already Open + + Notes: + max_msg_length (MTU) in client properties describes the maximum + data that can be sent or received. (e.g. if MTU=2K, can send + requests up to bytes 2k and received responses up to 2k bytes). + + IOCTL_MEI_NOTIFY_SET: enable or disable event notifications + + Usage: + uint32_t enable; + ioctl(fd, IOCTL_MEI_NOTIFY_SET, &enable); + + Inputs: + uint32_t enable = 1; + or + uint32_t enable[disable] = 0; + + Error returns: + EINVAL Wrong IOCTL Number + ENODEV Device is not initialized or the client not connected + ENOMEM Unable to allocate memory to client internal data. + EFAULT Fatal Error (e.g. Unable to access user input data) + EOPNOTSUPP if the device doesn't support the feature + + Notes: + The client must be connected in order to enable notification events + + + IOCTL_MEI_NOTIFY_GET : retrieve event + + Usage: + uint32_t event; + ioctl(fd, IOCTL_MEI_NOTIFY_GET, &event); + + Outputs: + 1 - if an event is pending + 0 - if there is no even pending + + Error returns: + EINVAL Wrong IOCTL Number + ENODEV Device is not initialized or the client not connected + ENOMEM Unable to allocate memory to client internal data. + EFAULT Fatal Error (e.g. Unable to access user input data) + EOPNOTSUPP if the device doesn't support the feature + + Notes: + The client must be connected and event notification has to be enabled + in order to receive an event + + +Intel ME Applications +===================== + + 1) Intel Local Management Service (Intel LMS) + + Applications running locally on the platform communicate with Intel AMT Release + 2.0 and later releases in the same way that network applications do via SOAP + over HTTP (deprecated starting with Release 6.0) or with WS-Management over + SOAP over HTTP. This means that some Intel AMT features can be accessed from a + local application using the same network interface as a remote application + communicating with Intel AMT over the network. + + When a local application sends a message addressed to the local Intel AMT host + name, the Intel LMS, which listens for traffic directed to the host name, + intercepts the message and routes it to the Intel MEI. + For more information: + http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide + Under "About Intel AMT" => "Local Access" + + For downloading Intel LMS: + http://software.intel.com/en-us/articles/download-the-latest-intel-amt-open-source-drivers/ + + The Intel LMS opens a connection using the Intel MEI driver to the Intel LMS + firmware feature using a defined UUID and then communicates with the feature + using a protocol called Intel AMT Port Forwarding Protocol (Intel APF protocol). + The protocol is used to maintain multiple sessions with Intel AMT from a + single application. + + See the protocol specification in the Intel AMT Software Development Kit (SDK) + http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide + Under "SDK Resources" => "Intel(R) vPro(TM) Gateway (MPS)" + => "Information for Intel(R) vPro(TM) Gateway Developers" + => "Description of the Intel AMT Port Forwarding (APF) Protocol" + + 2) Intel AMT Remote configuration using a Local Agent + + A Local Agent enables IT personnel to configure Intel AMT out-of-the-box + without requiring installing additional data to enable setup. The remote + configuration process may involve an ISV-developed remote configuration + agent that runs on the host. + For more information: + http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide + Under "Setup and Configuration of Intel AMT" => + "SDK Tools Supporting Setup and Configuration" => + "Using the Local Agent Sample" + + An open source Intel AMT configuration utility, implementing a local agent + that accesses the Intel MEI driver, can be found here: + http://software.intel.com/en-us/articles/download-the-latest-intel-amt-open-source-drivers/ + + +Intel AMT OS Health Watchdog +============================ + +The Intel AMT Watchdog is an OS Health (Hang/Crash) watchdog. +Whenever the OS hangs or crashes, Intel AMT will send an event +to any subscriber to this event. This mechanism means that +IT knows when a platform crashes even when there is a hard failure on the host. + +The Intel AMT Watchdog is composed of two parts: + 1) Firmware feature - receives the heartbeats + and sends an event when the heartbeats stop. + 2) Intel MEI iAMT watchdog driver - connects to the watchdog feature, + configures the watchdog and sends the heartbeats. + +The Intel iAMT watchdog MEI driver uses the kernel watchdog API to configure +the Intel AMT Watchdog and to send heartbeats to it. The default timeout of the +watchdog is 120 seconds. + +If the Intel AMT is not enabled in the firmware then the watchdog client won't enumerate +on the me client bus and watchdog devices won't be exposed. + +Supported Chipsets +================== +82X38/X48 Express and newer + + +--- +linux-mei@linux.intel.com diff --git a/Documentation/misc-devices/mei/mei-client-bus.txt b/Documentation/misc-devices/mei/mei-client-bus.txt deleted file mode 100644 index 743be4ec8989..000000000000 --- a/Documentation/misc-devices/mei/mei-client-bus.txt +++ /dev/null @@ -1,141 +0,0 @@ -Intel(R) Management Engine (ME) Client bus API -============================================== - - -Rationale -========= - -MEI misc character device is useful for dedicated applications to send and receive -data to the many FW appliance found in Intel's ME from the user space. -However for some of the ME functionalities it make sense to leverage existing software -stack and expose them through existing kernel subsystems. - -In order to plug seamlessly into the kernel device driver model we add kernel virtual -bus abstraction on top of the MEI driver. This allows implementing linux kernel drivers -for the various MEI features as a stand alone entities found in their respective subsystem. -Existing device drivers can even potentially be re-used by adding an MEI CL bus layer to -the existing code. - - -MEI CL bus API -============== - -A driver implementation for an MEI Client is very similar to existing bus -based device drivers. The driver registers itself as an MEI CL bus driver through -the mei_cl_driver structure: - -struct mei_cl_driver { - struct device_driver driver; - const char *name; - - const struct mei_cl_device_id *id_table; - - int (*probe)(struct mei_cl_device *dev, const struct mei_cl_id *id); - int (*remove)(struct mei_cl_device *dev); -}; - -struct mei_cl_id { - char name[MEI_NAME_SIZE]; - kernel_ulong_t driver_info; -}; - -The mei_cl_id structure allows the driver to bind itself against a device name. - -To actually register a driver on the ME Client bus one must call the mei_cl_add_driver() -API. This is typically called at module init time. - -Once registered on the ME Client bus, a driver will typically try to do some I/O on -this bus and this should be done through the mei_cl_send() and mei_cl_recv() -routines. The latter is synchronous (blocks and sleeps until data shows up). -In order for drivers to be notified of pending events waiting for them (e.g. -an Rx event) they can register an event handler through the -mei_cl_register_event_cb() routine. Currently only the MEI_EVENT_RX event -will trigger an event handler call and the driver implementation is supposed -to call mei_recv() from the event handler in order to fetch the pending -received buffers. - - -Example -======= - -As a theoretical example let's pretend the ME comes with a "contact" NFC IP. -The driver init and exit routines for this device would look like: - -#define CONTACT_DRIVER_NAME "contact" - -static struct mei_cl_device_id contact_mei_cl_tbl[] = { - { CONTACT_DRIVER_NAME, }, - - /* required last entry */ - { } -}; -MODULE_DEVICE_TABLE(mei_cl, contact_mei_cl_tbl); - -static struct mei_cl_driver contact_driver = { - .id_table = contact_mei_tbl, - .name = CONTACT_DRIVER_NAME, - - .probe = contact_probe, - .remove = contact_remove, -}; - -static int contact_init(void) -{ - int r; - - r = mei_cl_driver_register(&contact_driver); - if (r) { - pr_err(CONTACT_DRIVER_NAME ": driver registration failed\n"); - return r; - } - - return 0; -} - -static void __exit contact_exit(void) -{ - mei_cl_driver_unregister(&contact_driver); -} - -module_init(contact_init); -module_exit(contact_exit); - -And the driver's simplified probe routine would look like that: - -int contact_probe(struct mei_cl_device *dev, struct mei_cl_device_id *id) -{ - struct contact_driver *contact; - - [...] - mei_cl_enable_device(dev); - - mei_cl_register_event_cb(dev, contact_event_cb, contact); - - return 0; -} - -In the probe routine the driver first enable the MEI device and then registers -an ME bus event handler which is as close as it can get to registering a -threaded IRQ handler. -The handler implementation will typically call some I/O routine depending on -the pending events: - -#define MAX_NFC_PAYLOAD 128 - -static void contact_event_cb(struct mei_cl_device *dev, u32 events, - void *context) -{ - struct contact_driver *contact = context; - - if (events & BIT(MEI_EVENT_RX)) { - u8 payload[MAX_NFC_PAYLOAD]; - int payload_size; - - payload_size = mei_recv(dev, payload, MAX_NFC_PAYLOAD); - if (payload_size <= 0) - return; - - /* Hook to the NFC subsystem */ - nfc_hci_recv_frame(contact->hdev, payload, payload_size); - } -} diff --git a/Documentation/misc-devices/mei/mei.txt b/Documentation/misc-devices/mei/mei.txt deleted file mode 100644 index 2b80a0cd621f..000000000000 --- a/Documentation/misc-devices/mei/mei.txt +++ /dev/null @@ -1,266 +0,0 @@ -Intel(R) Management Engine Interface (Intel(R) MEI) -=================================================== - -Introduction -============ - -The Intel Management Engine (Intel ME) is an isolated and protected computing -resource (Co-processor) residing inside certain Intel chipsets. The Intel ME -provides support for computer/IT management features. The feature set -depends on the Intel chipset SKU. - -The Intel Management Engine Interface (Intel MEI, previously known as HECI) -is the interface between the Host and Intel ME. This interface is exposed -to the host as a PCI device. The Intel MEI Driver is in charge of the -communication channel between a host application and the Intel ME feature. - -Each Intel ME feature (Intel ME Client) is addressed by a GUID/UUID and -each client has its own protocol. The protocol is message-based with a -header and payload up to 512 bytes. - -Prominent usage of the Intel ME Interface is to communicate with Intel(R) -Active Management Technology (Intel AMT) implemented in firmware running on -the Intel ME. - -Intel AMT provides the ability to manage a host remotely out-of-band (OOB) -even when the operating system running on the host processor has crashed or -is in a sleep state. - -Some examples of Intel AMT usage are: - - Monitoring hardware state and platform components - - Remote power off/on (useful for green computing or overnight IT - maintenance) - - OS updates - - Storage of useful platform information such as software assets - - Built-in hardware KVM - - Selective network isolation of Ethernet and IP protocol flows based - on policies set by a remote management console - - IDE device redirection from remote management console - -Intel AMT (OOB) communication is based on SOAP (deprecated -starting with Release 6.0) over HTTP/S or WS-Management protocol over -HTTP/S that are received from a remote management console application. - -For more information about Intel AMT: -http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide - - -Intel MEI Driver -================ - -The driver exposes a misc device called /dev/mei. - -An application maintains communication with an Intel ME feature while -/dev/mei is open. The binding to a specific feature is performed by calling -MEI_CONNECT_CLIENT_IOCTL, which passes the desired UUID. -The number of instances of an Intel ME feature that can be opened -at the same time depends on the Intel ME feature, but most of the -features allow only a single instance. - -The Intel AMT Host Interface (Intel AMTHI) feature supports multiple -simultaneous user connected applications. The Intel MEI driver -handles this internally by maintaining request queues for the applications. - -The driver is transparent to data that are passed between firmware feature -and host application. - -Because some of the Intel ME features can change the system -configuration, the driver by default allows only a privileged -user to access it. - -A code snippet for an application communicating with Intel AMTHI client: - - struct mei_connect_client_data data; - fd = open(MEI_DEVICE); - - data.d.in_client_uuid = AMTHI_UUID; - - ioctl(fd, IOCTL_MEI_CONNECT_CLIENT, &data); - - printf("Ver=%d, MaxLen=%ld\n", - data.d.in_client_uuid.protocol_version, - data.d.in_client_uuid.max_msg_length); - - [...] - - write(fd, amthi_req_data, amthi_req_data_len); - - [...] - - read(fd, &amthi_res_data, amthi_res_data_len); - - [...] - close(fd); - - -IOCTL -===== - -The Intel MEI Driver supports the following IOCTL commands: - IOCTL_MEI_CONNECT_CLIENT Connect to firmware Feature (client). - - usage: - struct mei_connect_client_data clientData; - ioctl(fd, IOCTL_MEI_CONNECT_CLIENT, &clientData); - - inputs: - mei_connect_client_data struct contain the following - input field: - - in_client_uuid - UUID of the FW Feature that needs - to connect to. - outputs: - out_client_properties - Client Properties: MTU and Protocol Version. - - error returns: - EINVAL Wrong IOCTL Number - ENODEV Device or Connection is not initialized or ready. - (e.g. Wrong UUID) - ENOMEM Unable to allocate memory to client internal data. - EFAULT Fatal Error (e.g. Unable to access user input data) - EBUSY Connection Already Open - - Notes: - max_msg_length (MTU) in client properties describes the maximum - data that can be sent or received. (e.g. if MTU=2K, can send - requests up to bytes 2k and received responses up to 2k bytes). - - IOCTL_MEI_NOTIFY_SET: enable or disable event notifications - - Usage: - uint32_t enable; - ioctl(fd, IOCTL_MEI_NOTIFY_SET, &enable); - - Inputs: - uint32_t enable = 1; - or - uint32_t enable[disable] = 0; - - Error returns: - EINVAL Wrong IOCTL Number - ENODEV Device is not initialized or the client not connected - ENOMEM Unable to allocate memory to client internal data. - EFAULT Fatal Error (e.g. Unable to access user input data) - EOPNOTSUPP if the device doesn't support the feature - - Notes: - The client must be connected in order to enable notification events - - - IOCTL_MEI_NOTIFY_GET : retrieve event - - Usage: - uint32_t event; - ioctl(fd, IOCTL_MEI_NOTIFY_GET, &event); - - Outputs: - 1 - if an event is pending - 0 - if there is no even pending - - Error returns: - EINVAL Wrong IOCTL Number - ENODEV Device is not initialized or the client not connected - ENOMEM Unable to allocate memory to client internal data. - EFAULT Fatal Error (e.g. Unable to access user input data) - EOPNOTSUPP if the device doesn't support the feature - - Notes: - The client must be connected and event notification has to be enabled - in order to receive an event - - -Intel ME Applications -===================== - - 1) Intel Local Management Service (Intel LMS) - - Applications running locally on the platform communicate with Intel AMT Release - 2.0 and later releases in the same way that network applications do via SOAP - over HTTP (deprecated starting with Release 6.0) or with WS-Management over - SOAP over HTTP. This means that some Intel AMT features can be accessed from a - local application using the same network interface as a remote application - communicating with Intel AMT over the network. - - When a local application sends a message addressed to the local Intel AMT host - name, the Intel LMS, which listens for traffic directed to the host name, - intercepts the message and routes it to the Intel MEI. - For more information: - http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide - Under "About Intel AMT" => "Local Access" - - For downloading Intel LMS: - http://software.intel.com/en-us/articles/download-the-latest-intel-amt-open-source-drivers/ - - The Intel LMS opens a connection using the Intel MEI driver to the Intel LMS - firmware feature using a defined UUID and then communicates with the feature - using a protocol called Intel AMT Port Forwarding Protocol (Intel APF protocol). - The protocol is used to maintain multiple sessions with Intel AMT from a - single application. - - See the protocol specification in the Intel AMT Software Development Kit (SDK) - http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide - Under "SDK Resources" => "Intel(R) vPro(TM) Gateway (MPS)" - => "Information for Intel(R) vPro(TM) Gateway Developers" - => "Description of the Intel AMT Port Forwarding (APF) Protocol" - - 2) Intel AMT Remote configuration using a Local Agent - - A Local Agent enables IT personnel to configure Intel AMT out-of-the-box - without requiring installing additional data to enable setup. The remote - configuration process may involve an ISV-developed remote configuration - agent that runs on the host. - For more information: - http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide - Under "Setup and Configuration of Intel AMT" => - "SDK Tools Supporting Setup and Configuration" => - "Using the Local Agent Sample" - - An open source Intel AMT configuration utility, implementing a local agent - that accesses the Intel MEI driver, can be found here: - http://software.intel.com/en-us/articles/download-the-latest-intel-amt-open-source-drivers/ - - -Intel AMT OS Health Watchdog -============================ - -The Intel AMT Watchdog is an OS Health (Hang/Crash) watchdog. -Whenever the OS hangs or crashes, Intel AMT will send an event -to any subscriber to this event. This mechanism means that -IT knows when a platform crashes even when there is a hard failure on the host. - -The Intel AMT Watchdog is composed of two parts: - 1) Firmware feature - receives the heartbeats - and sends an event when the heartbeats stop. - 2) Intel MEI iAMT watchdog driver - connects to the watchdog feature, - configures the watchdog and sends the heartbeats. - -The Intel iAMT watchdog MEI driver uses the kernel watchdog API to configure -the Intel AMT Watchdog and to send heartbeats to it. The default timeout of the -watchdog is 120 seconds. - -If the Intel AMT is not enabled in the firmware then the watchdog client won't enumerate -on the me client bus and watchdog devices won't be exposed. - - -Supported Chipsets -================== - -7 Series Chipset Family -6 Series Chipset Family -5 Series Chipset Family -4 Series Chipset Family -Mobile 4 Series Chipset Family -ICH9 -82946GZ/GL -82G35 Express -82Q963/Q965 -82P965/G965 -Mobile PM965/GM965 -Mobile GME965/GLE960 -82Q35 Express -82G33/G31/P35/P31 Express -82Q33 Express -82X38/X48 Express - ---- -linux-mei@linux.intel.com diff --git a/MAINTAINERS b/MAINTAINERS index 5cfbea4ce575..bfe48cbea84c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8021,7 +8021,7 @@ F: include/uapi/linux/mei.h F: include/linux/mei_cl_bus.h F: drivers/misc/mei/* F: drivers/watchdog/mei_wdt.c -F: Documentation/misc-devices/mei/* +F: Documentation/driver-api/mei/* F: samples/mei/* INTEL MENLOW THERMAL DRIVER -- cgit v1.2.3-59-g8ed1b From 815d0f26c104873eb829e24510383d4d098417dd Mon Sep 17 00:00:00 2001 From: Tomas Winkler Date: Mon, 3 Jun 2019 12:14:01 +0300 Subject: mei: docs: move iamt docs to a iamt.rst file Move intel amt documentation to a seprate file. Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman --- Documentation/driver-api/mei/iamt.rst | 106 +++++++++++++++++++++++++++++++++ Documentation/driver-api/mei/index.rst | 1 + Documentation/driver-api/mei/mei.rst | 100 ------------------------------- 3 files changed, 107 insertions(+), 100 deletions(-) create mode 100644 Documentation/driver-api/mei/iamt.rst (limited to 'Documentation') diff --git a/Documentation/driver-api/mei/iamt.rst b/Documentation/driver-api/mei/iamt.rst new file mode 100644 index 000000000000..6dcf5b16e958 --- /dev/null +++ b/Documentation/driver-api/mei/iamt.rst @@ -0,0 +1,106 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Intel(R) Active Management Technology (Intel AMT) +================================================= + +Prominent usage of the Intel ME Interface is to communicate with Intel(R) +Active Management Technology (Intel AMT) implemented in firmware running on +the Intel ME. + +Intel AMT provides the ability to manage a host remotely out-of-band (OOB) +even when the operating system running on the host processor has crashed or +is in a sleep state. + +Some examples of Intel AMT usage are: + - Monitoring hardware state and platform components + - Remote power off/on (useful for green computing or overnight IT + maintenance) + - OS updates + - Storage of useful platform information such as software assets + - Built-in hardware KVM + - Selective network isolation of Ethernet and IP protocol flows based + on policies set by a remote management console + - IDE device redirection from remote management console + +Intel AMT (OOB) communication is based on SOAP (deprecated +starting with Release 6.0) over HTTP/S or WS-Management protocol over +HTTP/S that are received from a remote management console application. + +For more information about Intel AMT: +http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide + + +Intel AMT Applications +====================== + + 1) Intel Local Management Service (Intel LMS) + + Applications running locally on the platform communicate with Intel AMT Release + 2.0 and later releases in the same way that network applications do via SOAP + over HTTP (deprecated starting with Release 6.0) or with WS-Management over + SOAP over HTTP. This means that some Intel AMT features can be accessed from a + local application using the same network interface as a remote application + communicating with Intel AMT over the network. + + When a local application sends a message addressed to the local Intel AMT host + name, the Intel LMS, which listens for traffic directed to the host name, + intercepts the message and routes it to the Intel MEI. + For more information: + http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide + Under "About Intel AMT" => "Local Access" + + For downloading Intel LMS: + http://software.intel.com/en-us/articles/download-the-latest-intel-amt-open-source-drivers/ + + The Intel LMS opens a connection using the Intel MEI driver to the Intel LMS + firmware feature using a defined UUID and then communicates with the feature + using a protocol called Intel AMT Port Forwarding Protocol (Intel APF protocol). + The protocol is used to maintain multiple sessions with Intel AMT from a + single application. + + See the protocol specification in the Intel AMT Software Development Kit (SDK) + http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide + Under "SDK Resources" => "Intel(R) vPro(TM) Gateway (MPS)" + => "Information for Intel(R) vPro(TM) Gateway Developers" + => "Description of the Intel AMT Port Forwarding (APF) Protocol" + + 2) Intel AMT Remote configuration using a Local Agent + + A Local Agent enables IT personnel to configure Intel AMT out-of-the-box + without requiring installing additional data to enable setup. The remote + configuration process may involve an ISV-developed remote configuration + agent that runs on the host. + For more information: + http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide + Under "Setup and Configuration of Intel AMT" => + "SDK Tools Supporting Setup and Configuration" => + "Using the Local Agent Sample" + + An open source Intel AMT configuration utility, implementing a local agent + that accesses the Intel MEI driver, can be found here: + http://software.intel.com/en-us/articles/download-the-latest-intel-amt-open-source-drivers/ + + +Intel AMT OS Health Watchdog +============================ + +The Intel AMT Watchdog is an OS Health (Hang/Crash) watchdog. +Whenever the OS hangs or crashes, Intel AMT will send an event +to any subscriber to this event. This mechanism means that +IT knows when a platform crashes even when there is a hard failure on the host. + +The Intel AMT Watchdog is composed of two parts: + 1) Firmware feature - receives the heartbeats + and sends an event when the heartbeats stop. + 2) Intel MEI iAMT watchdog driver - connects to the watchdog feature, + configures the watchdog and sends the heartbeats. + +The Intel iAMT watchdog MEI driver uses the kernel watchdog API to configure +the Intel AMT Watchdog and to send heartbeats to it. The default timeout of the +watchdog is 120 seconds. + +If the Intel AMT is not enabled in the firmware then the watchdog client won't enumerate +on the me client bus and watchdog devices won't be exposed. + +--- +linux-mei@linux.intel.com diff --git a/Documentation/driver-api/mei/index.rst b/Documentation/driver-api/mei/index.rst index 35c1117d8366..d261afac6852 100644 --- a/Documentation/driver-api/mei/index.rst +++ b/Documentation/driver-api/mei/index.rst @@ -20,3 +20,4 @@ Intel(R) Management Engine Interface (Intel(R) MEI) mei mei-client-bus + iamt diff --git a/Documentation/driver-api/mei/mei.rst b/Documentation/driver-api/mei/mei.rst index 5aa3a5e6496a..c7f10a4b46ff 100644 --- a/Documentation/driver-api/mei/mei.rst +++ b/Documentation/driver-api/mei/mei.rst @@ -17,33 +17,6 @@ Each Intel ME feature (Intel ME Client) is addressed by a GUID/UUID and each client has its own protocol. The protocol is message-based with a header and payload up to 512 bytes. -Prominent usage of the Intel ME Interface is to communicate with Intel(R) -Active Management Technology (Intel AMT) implemented in firmware running on -the Intel ME. - -Intel AMT provides the ability to manage a host remotely out-of-band (OOB) -even when the operating system running on the host processor has crashed or -is in a sleep state. - -Some examples of Intel AMT usage are: - - Monitoring hardware state and platform components - - Remote power off/on (useful for green computing or overnight IT - maintenance) - - OS updates - - Storage of useful platform information such as software assets - - Built-in hardware KVM - - Selective network isolation of Ethernet and IP protocol flows based - on policies set by a remote management console - - IDE device redirection from remote management console - -Intel AMT (OOB) communication is based on SOAP (deprecated -starting with Release 6.0) over HTTP/S or WS-Management protocol over -HTTP/S that are received from a remote management console application. - -For more information about Intel AMT: -http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide - - Intel MEI Driver ================ @@ -169,82 +142,9 @@ The Intel MEI Driver supports the following IOCTL commands: in order to receive an event -Intel ME Applications -===================== - - 1) Intel Local Management Service (Intel LMS) - - Applications running locally on the platform communicate with Intel AMT Release - 2.0 and later releases in the same way that network applications do via SOAP - over HTTP (deprecated starting with Release 6.0) or with WS-Management over - SOAP over HTTP. This means that some Intel AMT features can be accessed from a - local application using the same network interface as a remote application - communicating with Intel AMT over the network. - - When a local application sends a message addressed to the local Intel AMT host - name, the Intel LMS, which listens for traffic directed to the host name, - intercepts the message and routes it to the Intel MEI. - For more information: - http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide - Under "About Intel AMT" => "Local Access" - - For downloading Intel LMS: - http://software.intel.com/en-us/articles/download-the-latest-intel-amt-open-source-drivers/ - - The Intel LMS opens a connection using the Intel MEI driver to the Intel LMS - firmware feature using a defined UUID and then communicates with the feature - using a protocol called Intel AMT Port Forwarding Protocol (Intel APF protocol). - The protocol is used to maintain multiple sessions with Intel AMT from a - single application. - - See the protocol specification in the Intel AMT Software Development Kit (SDK) - http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide - Under "SDK Resources" => "Intel(R) vPro(TM) Gateway (MPS)" - => "Information for Intel(R) vPro(TM) Gateway Developers" - => "Description of the Intel AMT Port Forwarding (APF) Protocol" - - 2) Intel AMT Remote configuration using a Local Agent - - A Local Agent enables IT personnel to configure Intel AMT out-of-the-box - without requiring installing additional data to enable setup. The remote - configuration process may involve an ISV-developed remote configuration - agent that runs on the host. - For more information: - http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide - Under "Setup and Configuration of Intel AMT" => - "SDK Tools Supporting Setup and Configuration" => - "Using the Local Agent Sample" - - An open source Intel AMT configuration utility, implementing a local agent - that accesses the Intel MEI driver, can be found here: - http://software.intel.com/en-us/articles/download-the-latest-intel-amt-open-source-drivers/ - - -Intel AMT OS Health Watchdog -============================ - -The Intel AMT Watchdog is an OS Health (Hang/Crash) watchdog. -Whenever the OS hangs or crashes, Intel AMT will send an event -to any subscriber to this event. This mechanism means that -IT knows when a platform crashes even when there is a hard failure on the host. - -The Intel AMT Watchdog is composed of two parts: - 1) Firmware feature - receives the heartbeats - and sends an event when the heartbeats stop. - 2) Intel MEI iAMT watchdog driver - connects to the watchdog feature, - configures the watchdog and sends the heartbeats. - -The Intel iAMT watchdog MEI driver uses the kernel watchdog API to configure -the Intel AMT Watchdog and to send heartbeats to it. The default timeout of the -watchdog is 120 seconds. - -If the Intel AMT is not enabled in the firmware then the watchdog client won't enumerate -on the me client bus and watchdog devices won't be exposed. Supported Chipsets ================== 82X38/X48 Express and newer - ---- linux-mei@linux.intel.com -- cgit v1.2.3-59-g8ed1b From 6080e0cff2bf7108d3f2855a7177b1f7f1830035 Mon Sep 17 00:00:00 2001 From: Tomas Winkler Date: Mon, 3 Jun 2019 12:14:03 +0300 Subject: mei: docs: update mei client bus documentation. The mei client bus API has changed significantly from time it was documented, and had required update. Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman --- Documentation/driver-api/mei/mei-client-bus.rst | 162 +++++++++++++----------- 1 file changed, 85 insertions(+), 77 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/mei/mei-client-bus.rst b/Documentation/driver-api/mei/mei-client-bus.rst index a26a85453bdf..7310dd45c484 100644 --- a/Documentation/driver-api/mei/mei-client-bus.rst +++ b/Documentation/driver-api/mei/mei-client-bus.rst @@ -8,13 +8,13 @@ Intel(R) Management Engine (ME) Client bus API Rationale ========= -MEI misc character device is useful for dedicated applications to send and receive +The MEI character device is useful for dedicated applications to send and receive data to the many FW appliance found in Intel's ME from the user space. -However for some of the ME functionalities it make sense to leverage existing software +However, for some of the ME functionalities it makes sense to leverage existing software stack and expose them through existing kernel subsystems. In order to plug seamlessly into the kernel device driver model we add kernel virtual -bus abstraction on top of the MEI driver. This allows implementing linux kernel drivers +bus abstraction on top of the MEI driver. This allows implementing Linux kernel drivers for the various MEI features as a stand alone entities found in their respective subsystem. Existing device drivers can even potentially be re-used by adding an MEI CL bus layer to the existing code. @@ -23,9 +23,9 @@ the existing code. MEI CL bus API ============== -A driver implementation for an MEI Client is very similar to existing bus +A driver implementation for an MEI Client is very similar to any other existing bus based device drivers. The driver registers itself as an MEI CL bus driver through -the ``struct mei_cl_driver`` structure: +the ``struct mei_cl_driver`` structure defined in :file:`include/linux/mei_cl_bus.c` .. code-block:: C @@ -39,25 +39,38 @@ the ``struct mei_cl_driver`` structure: int (*remove)(struct mei_cl_device *dev); }; - struct mei_cl_id { - char name[MEI_NAME_SIZE]; + + +The mei_cl_device_id structure defined in :file:`include/linux/mod_devicetable.h` allows a +driver to bind itself against a device name. + +.. code-block:: C + + struct mei_cl_device_id { + char name[MEI_CL_NAME_SIZE]; + uuid_le uuid; + __u8 version; kernel_ulong_t driver_info; }; -The mei_cl_id structure allows the driver to bind itself against a device name. +To actually register a driver on the ME Client bus one must call the :c:func:`mei_cl_add_driver` +API. This is typically called at module initialization time. + +Once the driver is registered and bound to the device, a driver will typically +try to do some I/O on this bus and this should be done through the :c:func:`mei_cl_send` +and :c:func:`mei_cl_recv` functions. More detailed information is in :ref:`api` section. + +In order for a driver to be notified about pending traffic or event, the driver +should register a callback via :c:func:`mei_cl_devev_register_rx_cb` and +:c:func:`mei_cldev_register_notify_cb` function respectively. -To actually register a driver on the ME Client bus one must call the mei_cl_add_driver() -API. This is typically called at module init time. +.. _api: + +API: +---- +.. kernel-doc:: drivers/misc/mei/bus.c + :export: drivers/misc/mei/bus.c -Once registered on the ME Client bus, a driver will typically try to do some I/O on -this bus and this should be done through the mei_cl_send() and mei_cl_recv() -routines. The latter is synchronous (blocks and sleeps until data shows up). -In order for drivers to be notified of pending events waiting for them (e.g. -an Rx event) they can register an event handler through the -mei_cl_register_event_cb() routine. Currently only the MEI_EVENT_RX event -will trigger an event handler call and the driver implementation is supposed -to call mei_recv() from the event handler in order to fetch the pending -received buffers. Example @@ -68,85 +81,80 @@ The driver init and exit routines for this device would look like: .. code-block:: C - #define CONTACT_DRIVER_NAME "contact" + #define CONTACT_DRIVER_NAME "contact" - static struct mei_cl_device_id contact_mei_cl_tbl[] = { - { CONTACT_DRIVER_NAME, }, + static struct mei_cl_device_id contact_mei_cl_tbl[] = { + { CONTACT_DRIVER_NAME, }, - /* required last entry */ - { } - }; - MODULE_DEVICE_TABLE(mei_cl, contact_mei_cl_tbl); + /* required last entry */ + { } + }; + MODULE_DEVICE_TABLE(mei_cl, contact_mei_cl_tbl); - static struct mei_cl_driver contact_driver = { - .id_table = contact_mei_tbl, - .name = CONTACT_DRIVER_NAME, + static struct mei_cl_driver contact_driver = { + .id_table = contact_mei_tbl, + .name = CONTACT_DRIVER_NAME, - .probe = contact_probe, - .remove = contact_remove, - }; + .probe = contact_probe, + .remove = contact_remove, + }; - static int contact_init(void) - { - int r; + static int contact_init(void) + { + int r; - r = mei_cl_driver_register(&contact_driver); - if (r) { - pr_err(CONTACT_DRIVER_NAME ": driver registration failed\n"); - return r; - } + r = mei_cl_driver_register(&contact_driver); + if (r) { + pr_err(CONTACT_DRIVER_NAME ": driver registration failed\n"); + return r; + } - return 0; - } + return 0; + } - static void __exit contact_exit(void) - { - mei_cl_driver_unregister(&contact_driver); - } + static void __exit contact_exit(void) + { + mei_cl_driver_unregister(&contact_driver); + } - module_init(contact_init); - module_exit(contact_exit); + module_init(contact_init); + module_exit(contact_exit); And the driver's simplified probe routine would look like that: .. code-block:: C - int contact_probe(struct mei_cl_device *dev, struct mei_cl_device_id *id) - { - struct contact_driver *contact; + int contact_probe(struct mei_cl_device *dev, struct mei_cl_device_id *id) + { + [...] + mei_cldev_enable(dev); - [...] - mei_cl_enable_device(dev); + mei_cldev_register_rx_cb(dev, contact_rx_cb); - mei_cl_register_event_cb(dev, contact_event_cb, contact); - - return 0; - } + return 0; + } In the probe routine the driver first enable the MEI device and then registers -an ME bus event handler which is as close as it can get to registering a -threaded IRQ handler. -The handler implementation will typically call some I/O routine depending on -the pending events: - -#define MAX_NFC_PAYLOAD 128 +an rx handler which is as close as it can get to registering a threaded IRQ handler. +The handler implementation will typically call :c:func:`mei_cldev_recv` and then +process received data. .. code-block:: C - static void contact_event_cb(struct mei_cl_device *dev, u32 events, - void *context) - { - struct contact_driver *contact = context; + #define MAX_PAYLOAD 128 + #define HDR_SIZE 4 + static void conntact_rx_cb(struct mei_cl_device *cldev) + { + struct contact *c = mei_cldev_get_drvdata(cldev); + unsigned char payload[MAX_PAYLOAD]; + ssize_t payload_sz; + + payload_sz = mei_cldev_recv(cldev, payload, MAX_PAYLOAD) + if (reply_size < HDR_SIZE) { + return; + } - if (events & BIT(MEI_EVENT_RX)) { - u8 payload[MAX_NFC_PAYLOAD]; - int payload_size; + c->process_rx(payload); - payload_size = mei_recv(dev, payload, MAX_NFC_PAYLOAD); - if (payload_size <= 0) - return; + } - /* Hook to the NFC subsystem */ - nfc_hci_recv_frame(contact->hdev, payload, payload_size); - } - } -- cgit v1.2.3-59-g8ed1b From 4e3d3b784ae7cd86ace2776c01be99ddfd378801 Mon Sep 17 00:00:00 2001 From: Tomas Winkler Date: Mon, 3 Jun 2019 12:14:04 +0300 Subject: mei: docs: add a short description for nfc behind mei Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman --- Documentation/driver-api/mei/index.rst | 2 +- Documentation/driver-api/mei/mei-client-bus.rst | 7 +++++++ Documentation/driver-api/mei/nfc.rst | 28 +++++++++++++++++++++++++ 3 files changed, 36 insertions(+), 1 deletion(-) create mode 100644 Documentation/driver-api/mei/nfc.rst (limited to 'Documentation') diff --git a/Documentation/driver-api/mei/index.rst b/Documentation/driver-api/mei/index.rst index d261afac6852..3a22b522ee78 100644 --- a/Documentation/driver-api/mei/index.rst +++ b/Documentation/driver-api/mei/index.rst @@ -16,7 +16,7 @@ Intel(R) Management Engine Interface (Intel(R) MEI) Table of Contents .. toctree:: - :maxdepth: 2 + :maxdepth: 3 mei mei-client-bus diff --git a/Documentation/driver-api/mei/mei-client-bus.rst b/Documentation/driver-api/mei/mei-client-bus.rst index 7310dd45c484..bfe28ebc3ca8 100644 --- a/Documentation/driver-api/mei/mei-client-bus.rst +++ b/Documentation/driver-api/mei/mei-client-bus.rst @@ -158,3 +158,10 @@ process received data. } +MEI Client Bus Drivers +====================== + +.. toctree:: + :maxdepth: 2 + + nfc diff --git a/Documentation/driver-api/mei/nfc.rst b/Documentation/driver-api/mei/nfc.rst new file mode 100644 index 000000000000..b5b6fc96f85e --- /dev/null +++ b/Documentation/driver-api/mei/nfc.rst @@ -0,0 +1,28 @@ +.. SPDX-License-Identifier: GPL-2.0 + +MEI NFC +------- + +Some Intel 8 and 9 Serieses chipsets supports NFC devices connected behind +the Intel Management Engine controller. +MEI client bus exposes the NFC chips as NFC phy devices and enables +binding with Microread and NXP PN544 NFC device driver from the Linux NFC +subsystem. + +.. kernel-render:: DOT + :alt: MEI NFC digraph + :caption: **MEI NFC** Stack + + digraph NFC { + cl_nfc -> me_cl_nfc; + "drivers/nfc/mei_phy" -> cl_nfc [lhead=bus]; + "drivers/nfc/microread/mei" -> cl_nfc; + "drivers/nfc/microread/mei" -> "drivers/nfc/mei_phy"; + "drivers/nfc/pn544/mei" -> cl_nfc; + "drivers/nfc/pn544/mei" -> "drivers/nfc/mei_phy"; + "net/nfc" -> "drivers/nfc/microread/mei"; + "net/nfc" -> "drivers/nfc/pn544/mei"; + "neard" -> "net/nfc"; + cl_nfc [label="mei/bus(nfc)"]; + me_cl_nfc [label="me fw (nfc)"]; + } -- cgit v1.2.3-59-g8ed1b From 0475afd2a5dee99defdb7b030c09ba202ea3c64a Mon Sep 17 00:00:00 2001 From: Tomas Winkler Date: Mon, 3 Jun 2019 12:14:05 +0300 Subject: mei: docs: add hdcp documentation 1. Add a short ducumentation for MEI HDCP driver, and fix DOC comments in drivers/misc/mei/hdcp/mei_hdcp.c Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman --- Documentation/driver-api/mei/hdcp.rst | 32 +++++++++++++++++++++++++ Documentation/driver-api/mei/mei-client-bus.rst | 1 + drivers/misc/mei/hdcp/mei_hdcp.c | 11 ++++----- 3 files changed, 37 insertions(+), 7 deletions(-) create mode 100644 Documentation/driver-api/mei/hdcp.rst (limited to 'Documentation') diff --git a/Documentation/driver-api/mei/hdcp.rst b/Documentation/driver-api/mei/hdcp.rst new file mode 100644 index 000000000000..e85a065b1cdc --- /dev/null +++ b/Documentation/driver-api/mei/hdcp.rst @@ -0,0 +1,32 @@ +.. SPDX-License-Identifier: GPL-2.0 + +HDCP: +===== + +ME FW as a security engine provides the capability for setting up +HDCP2.2 protocol negotiation between the Intel graphics device and +an HDC2.2 sink. + +ME FW prepares HDCP2.2 negotiation parameters, signs and encrypts them +according the HDCP 2.2 spec. The Intel graphics sends the created blob +to the HDCP2.2 sink. + +Similarly, the HDCP2.2 sink's response is transferred to ME FW +for decryption and verification. + +Once all the steps of HDCP2.2 negotiation are completed, +upon request ME FW will configure the port as authenticated and supply +the HDCP encryption keys to Intel graphics hardware. + + +mei_hdcp driver +--------------- +.. kernel-doc:: drivers/misc/mei/hdcp/mei_hdcp.c + :doc: MEI_HDCP Client Driver + +mei_hdcp api +------------ + +.. kernel-doc:: drivers/misc/mei/hdcp/mei_hdcp.c + :functions: + diff --git a/Documentation/driver-api/mei/mei-client-bus.rst b/Documentation/driver-api/mei/mei-client-bus.rst index bfe28ebc3ca8..f242b3f8d6aa 100644 --- a/Documentation/driver-api/mei/mei-client-bus.rst +++ b/Documentation/driver-api/mei/mei-client-bus.rst @@ -164,4 +164,5 @@ MEI Client Bus Drivers .. toctree:: :maxdepth: 2 + hdcp nfc diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c index b07000202d4a..ed816939fb32 100644 --- a/drivers/misc/mei/hdcp/mei_hdcp.c +++ b/drivers/misc/mei/hdcp/mei_hdcp.c @@ -2,7 +2,7 @@ /* * Copyright © 2019 Intel Corporation * - * Mei_hdcp.c: HDCP client driver for mei bus + * mei_hdcp.c: HDCP client driver for mei bus * * Author: * Ramalingam C @@ -11,12 +11,9 @@ /** * DOC: MEI_HDCP Client Driver * - * This is a client driver to the mei_bus to make the HDCP2.2 services of - * ME FW available for the interested consumers like I915. - * - * This module will act as a translation layer between HDCP protocol - * implementor(I915) and ME FW by translating HDCP2.2 authentication - * messages to ME FW command payloads and vice versa. + * The mei_hdcp driver acts as a translation layer between HDCP 2.2 + * protocol implementer (I915) and ME FW by translating HDCP2.2 + * negotiation messages to ME FW command payloads and vice versa. */ #include -- cgit v1.2.3-59-g8ed1b From 7e706da35a458f4b0d4c565c7b71023d8bfe279b Mon Sep 17 00:00:00 2001 From: Tomas Winkler Date: Mon, 3 Jun 2019 12:14:06 +0300 Subject: mei: docs: fix broken links in iamt documentation. The iAMT documentation moved from http:// https://, and LMS is moved to github.com Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman --- Documentation/driver-api/mei/iamt.rst | 105 ++++++++++++++++------------------ 1 file changed, 50 insertions(+), 55 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/mei/iamt.rst b/Documentation/driver-api/mei/iamt.rst index 6dcf5b16e958..6ef3e613684b 100644 --- a/Documentation/driver-api/mei/iamt.rst +++ b/Documentation/driver-api/mei/iamt.rst @@ -27,62 +27,57 @@ starting with Release 6.0) over HTTP/S or WS-Management protocol over HTTP/S that are received from a remote management console application. For more information about Intel AMT: -http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide +https://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide/default.htm Intel AMT Applications -====================== - - 1) Intel Local Management Service (Intel LMS) - - Applications running locally on the platform communicate with Intel AMT Release - 2.0 and later releases in the same way that network applications do via SOAP - over HTTP (deprecated starting with Release 6.0) or with WS-Management over - SOAP over HTTP. This means that some Intel AMT features can be accessed from a - local application using the same network interface as a remote application - communicating with Intel AMT over the network. - - When a local application sends a message addressed to the local Intel AMT host - name, the Intel LMS, which listens for traffic directed to the host name, - intercepts the message and routes it to the Intel MEI. - For more information: - http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide - Under "About Intel AMT" => "Local Access" - - For downloading Intel LMS: - http://software.intel.com/en-us/articles/download-the-latest-intel-amt-open-source-drivers/ - - The Intel LMS opens a connection using the Intel MEI driver to the Intel LMS - firmware feature using a defined UUID and then communicates with the feature - using a protocol called Intel AMT Port Forwarding Protocol (Intel APF protocol). - The protocol is used to maintain multiple sessions with Intel AMT from a - single application. - - See the protocol specification in the Intel AMT Software Development Kit (SDK) - http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide - Under "SDK Resources" => "Intel(R) vPro(TM) Gateway (MPS)" - => "Information for Intel(R) vPro(TM) Gateway Developers" - => "Description of the Intel AMT Port Forwarding (APF) Protocol" - - 2) Intel AMT Remote configuration using a Local Agent - - A Local Agent enables IT personnel to configure Intel AMT out-of-the-box - without requiring installing additional data to enable setup. The remote - configuration process may involve an ISV-developed remote configuration - agent that runs on the host. - For more information: - http://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide - Under "Setup and Configuration of Intel AMT" => - "SDK Tools Supporting Setup and Configuration" => - "Using the Local Agent Sample" - - An open source Intel AMT configuration utility, implementing a local agent - that accesses the Intel MEI driver, can be found here: - http://software.intel.com/en-us/articles/download-the-latest-intel-amt-open-source-drivers/ - +---------------------- + + 1) Intel Local Management Service (Intel LMS) + + Applications running locally on the platform communicate with Intel AMT Release + 2.0 and later releases in the same way that network applications do via SOAP + over HTTP (deprecated starting with Release 6.0) or with WS-Management over + SOAP over HTTP. This means that some Intel AMT features can be accessed from a + local application using the same network interface as a remote application + communicating with Intel AMT over the network. + + When a local application sends a message addressed to the local Intel AMT host + name, the Intel LMS, which listens for traffic directed to the host name, + intercepts the message and routes it to the Intel MEI. + For more information: + https://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide/default.htm + Under "About Intel AMT" => "Local Access" + + For downloading Intel LMS: + https://github.com/intel/lms + + The Intel LMS opens a connection using the Intel MEI driver to the Intel LMS + firmware feature using a defined GUID and then communicates with the feature + using a protocol called Intel AMT Port Forwarding Protocol (Intel APF protocol). + The protocol is used to maintain multiple sessions with Intel AMT from a + single application. + + See the protocol specification in the Intel AMT Software Development Kit (SDK) + https://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide/default.htm + Under "SDK Resources" => "Intel(R) vPro(TM) Gateway (MPS)" + => "Information for Intel(R) vPro(TM) Gateway Developers" + => "Description of the Intel AMT Port Forwarding (APF) Protocol" + + 2) Intel AMT Remote configuration using a Local Agent + + A Local Agent enables IT personnel to configure Intel AMT out-of-the-box + without requiring installing additional data to enable setup. The remote + configuration process may involve an ISV-developed remote configuration + agent that runs on the host. + For more information: + https://software.intel.com/sites/manageability/AMT_Implementation_and_Reference_Guide/default.htm + Under "Setup and Configuration of Intel AMT" => + "SDK Tools Supporting Setup and Configuration" => + "Using the Local Agent Sample" Intel AMT OS Health Watchdog -============================ +---------------------------- The Intel AMT Watchdog is an OS Health (Hang/Crash) watchdog. Whenever the OS hangs or crashes, Intel AMT will send an event @@ -90,10 +85,10 @@ to any subscriber to this event. This mechanism means that IT knows when a platform crashes even when there is a hard failure on the host. The Intel AMT Watchdog is composed of two parts: - 1) Firmware feature - receives the heartbeats - and sends an event when the heartbeats stop. - 2) Intel MEI iAMT watchdog driver - connects to the watchdog feature, - configures the watchdog and sends the heartbeats. + 1) Firmware feature - receives the heartbeats + and sends an event when the heartbeats stop. + 2) Intel MEI iAMT watchdog driver - connects to the watchdog feature, + configures the watchdog and sends the heartbeats. The Intel iAMT watchdog MEI driver uses the kernel watchdog API to configure the Intel AMT Watchdog and to send heartbeats to it. The default timeout of the -- cgit v1.2.3-59-g8ed1b From d0a178095c5fbbd25454c20e49bc3a7d70ecb769 Mon Sep 17 00:00:00 2001 From: Tomas Winkler Date: Thu, 6 Jun 2019 16:31:08 +0300 Subject: mei: docs: update mei documentation The mei driver went via multiple changes, update the documentation and fix formatting. Signed-off-by: Tomas Winkler Signed-off-by: Greg Kroah-Hartman --- Documentation/driver-api/mei/mei.rst | 96 +++++++++++++++++++++++------------- 1 file changed, 61 insertions(+), 35 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/mei/mei.rst b/Documentation/driver-api/mei/mei.rst index c7f10a4b46ff..c800d8e5f422 100644 --- a/Documentation/driver-api/mei/mei.rst +++ b/Documentation/driver-api/mei/mei.rst @@ -5,34 +5,32 @@ Introduction The Intel Management Engine (Intel ME) is an isolated and protected computing resource (Co-processor) residing inside certain Intel chipsets. The Intel ME -provides support for computer/IT management features. The feature set -depends on the Intel chipset SKU. +provides support for computer/IT management and security features. +The actual feature set depends on the Intel chipset SKU. The Intel Management Engine Interface (Intel MEI, previously known as HECI) is the interface between the Host and Intel ME. This interface is exposed -to the host as a PCI device. The Intel MEI Driver is in charge of the -communication channel between a host application and the Intel ME feature. +to the host as a PCI device, actually multiple PCI devices might be exposed. +The Intel MEI Driver is in charge of the communication channel between +a host application and the Intel ME features. -Each Intel ME feature (Intel ME Client) is addressed by a GUID/UUID and +Each Intel ME feature, or Intel ME Client is addressed by a unique GUID and each client has its own protocol. The protocol is message-based with a -header and payload up to 512 bytes. +header and payload up to maximal number of bytes advertised by the client, +upon connection. Intel MEI Driver ================ -The driver exposes a misc device called /dev/mei. +The driver exposes a character device with device nodes /dev/meiX. An application maintains communication with an Intel ME feature while -/dev/mei is open. The binding to a specific feature is performed by calling -MEI_CONNECT_CLIENT_IOCTL, which passes the desired UUID. +/dev/meiX is open. The binding to a specific feature is performed by calling +:c:macro:`MEI_CONNECT_CLIENT_IOCTL`, which passes the desired GUID. The number of instances of an Intel ME feature that can be opened at the same time depends on the Intel ME feature, but most of the features allow only a single instance. -The Intel AMT Host Interface (Intel AMTHI) feature supports multiple -simultaneous user connected applications. The Intel MEI driver -handles this internally by maintaining request queues for the applications. - The driver is transparent to data that are passed between firmware feature and host application. @@ -40,6 +38,8 @@ Because some of the Intel ME features can change the system configuration, the driver by default allows only a privileged user to access it. +The session is terminated calling :c:func:`close(int fd)`. + A code snippet for an application communicating with Intel AMTHI client: .. code-block:: C @@ -47,13 +47,13 @@ A code snippet for an application communicating with Intel AMTHI client: struct mei_connect_client_data data; fd = open(MEI_DEVICE); - data.d.in_client_uuid = AMTHI_UUID; + data.d.in_client_uuid = AMTHI_GUID; ioctl(fd, IOCTL_MEI_CONNECT_CLIENT, &data); printf("Ver=%d, MaxLen=%ld\n", - data.d.in_client_uuid.protocol_version, - data.d.in_client_uuid.max_msg_length); + data.d.in_client_uuid.protocol_version, + data.d.in_client_uuid.max_msg_length); [...] @@ -67,60 +67,86 @@ A code snippet for an application communicating with Intel AMTHI client: close(fd); -IOCTLs -====== +User space API + +IOCTLs: +======= The Intel MEI Driver supports the following IOCTL commands: - IOCTL_MEI_CONNECT_CLIENT Connect to firmware Feature (client). - usage: - struct mei_connect_client_data clientData; - ioctl(fd, IOCTL_MEI_CONNECT_CLIENT, &clientData); +IOCTL_MEI_CONNECT_CLIENT +------------------------- +Connect to firmware Feature/Client. + +.. code-block:: none + + Usage: - inputs: - mei_connect_client_data struct contain the following - input field: + struct mei_connect_client_data client_data; - in_client_uuid - UUID of the FW Feature that needs + ioctl(fd, IOCTL_MEI_CONNECT_CLIENT, &client_data); + + Inputs: + + struct mei_connect_client_data - contain the following + Input field: + + in_client_uuid - GUID of the FW Feature that needs to connect to. - outputs: + Outputs: out_client_properties - Client Properties: MTU and Protocol Version. - error returns: + Error returns: + + ENOTTY No such client (i.e. wrong GUID) or connection is not allowed. EINVAL Wrong IOCTL Number - ENODEV Device or Connection is not initialized or ready. (e.g. Wrong UUID) + ENODEV Device or Connection is not initialized or ready. ENOMEM Unable to allocate memory to client internal data. EFAULT Fatal Error (e.g. Unable to access user input data) EBUSY Connection Already Open - Notes: +:Note: max_msg_length (MTU) in client properties describes the maximum data that can be sent or received. (e.g. if MTU=2K, can send requests up to bytes 2k and received responses up to 2k bytes). - IOCTL_MEI_NOTIFY_SET: enable or disable event notifications + +IOCTL_MEI_NOTIFY_SET +--------------------- +Enable or disable event notifications. + + +.. code-block:: none Usage: + uint32_t enable; + ioctl(fd, IOCTL_MEI_NOTIFY_SET, &enable); - Inputs: + uint32_t enable = 1; or uint32_t enable[disable] = 0; Error returns: + + EINVAL Wrong IOCTL Number ENODEV Device is not initialized or the client not connected ENOMEM Unable to allocate memory to client internal data. EFAULT Fatal Error (e.g. Unable to access user input data) EOPNOTSUPP if the device doesn't support the feature - Notes: +:Note: The client must be connected in order to enable notification events - IOCTL_MEI_NOTIFY_GET : retrieve event +IOCTL_MEI_NOTIFY_GET +-------------------- +Retrieve event + +.. code-block:: none Usage: uint32_t event; @@ -137,7 +163,7 @@ The Intel MEI Driver supports the following IOCTL commands: EFAULT Fatal Error (e.g. Unable to access user input data) EOPNOTSUPP if the device doesn't support the feature - Notes: +:Note: The client must be connected and event notification has to be enabled in order to receive an event -- cgit v1.2.3-59-g8ed1b From c2a6ea23a40152a03d6c605d6f0ea239b11605b8 Mon Sep 17 00:00:00 2001 From: Peng Fan Date: Fri, 14 Jun 2019 15:32:18 +0100 Subject: dt-bindings: fsl: scu: add ocotp binding NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as system controller(SCU), the ocotp controller is being controlled by the SCU, so Linux need use RPC to SCU for ocotp handling. This patch adds binding doc for i.MX8 SCU OCOTP driver. Cc: Mark Rutland Cc: Shawn Guo Cc: Ulf Hansson Cc: Stephen Boyd Cc: Anson Huang Cc: devicetree@vger.kernel.org Reviewed-by: Rob Herring Reviewed-by: Dong Aisheng Signed-off-by: Peng Fan Signed-off-by: Srinivas Kandagatla Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/arm/freescale/fsl,scu.txt | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt index 5d7dbabbb784..f378922906f6 100644 --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt @@ -133,6 +133,18 @@ RTC bindings based on SCU Message Protocol Required properties: - compatible: should be "fsl,imx8qxp-sc-rtc"; +OCOTP bindings based on SCU Message Protocol +------------------------------------------------------------ +Required properties: +- compatible: Should be "fsl,imx8qxp-scu-ocotp" +- #address-cells: Must be 1. Contains byte index +- #size-cells: Must be 1. Contains byte length + +Optional Child nodes: + +- Data cells of ocotp: + Detailed bindings are described in bindings/nvmem/nvmem.txt + Example (imx8qxp): ------------- aliases { @@ -177,6 +189,16 @@ firmware { ... }; + ocotp: imx8qx-ocotp { + compatible = "fsl,imx8qxp-scu-ocotp"; + #address-cells = <1>; + #size-cells = <1>; + + fec_mac0: mac@2c4 { + reg = <0x2c4 8>; + }; + }; + pd: imx8qx-pd { compatible = "fsl,imx8qxp-scu-pd", "fsl,scu-pd"; #power-domain-cells = <1>; -- cgit v1.2.3-59-g8ed1b From 42c3dcedc6b76b1383e1b63be82b84c058b5a8ad Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Fri, 14 Jun 2019 15:32:21 +0100 Subject: dt-bindings: nvmem: Convert Allwinner SID to a schema The Allwinner SoCs have an efuse supported in Linux, with a matching Device Tree binding. Now that we have the DT validation in place, let's convert the device tree bindings for that controller over to a YAML schemas. Signed-off-by: Maxime Ripard Reviewed-by: Rob Herring Signed-off-by: Srinivas Kandagatla Signed-off-by: Greg Kroah-Hartman --- .../bindings/nvmem/allwinner,sun4i-a10-sid.yaml | 51 ++++++++++++++++++++++ .../bindings/nvmem/allwinner,sunxi-sid.txt | 29 ------------ 2 files changed, 51 insertions(+), 29 deletions(-) create mode 100644 Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml delete mode 100644 Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml b/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml new file mode 100644 index 000000000000..c9efd6e2c134 --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/nvmem/allwinner,sun4i-a10-sid.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner A10 Security ID Device Tree Bindings + +maintainers: + - Chen-Yu Tsai + - Maxime Ripard + +allOf: + - $ref: "nvmem.yaml#" + +properties: + compatible: + enum: + - allwinner,sun4i-a10-sid + - allwinner,sun7i-a20-sid + - allwinner,sun8i-a83t-sid + - allwinner,sun8i-h3-sid + - allwinner,sun50i-a64-sid + - allwinner,sun50i-h5-sid + - allwinner,sun50i-h6-sid + + reg: + maxItems: 1 + +required: + - compatible + - reg + +# FIXME: We should set it, but it would report all the generic +# properties as additional properties. +# additionalProperties: false + +examples: + - | + sid@1c23800 { + compatible = "allwinner,sun4i-a10-sid"; + reg = <0x01c23800 0x10>; + }; + + - | + sid@1c23800 { + compatible = "allwinner,sun7i-a20-sid"; + reg = <0x01c23800 0x200>; + }; + +... diff --git a/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt b/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt deleted file mode 100644 index cfb18b4ef8f7..000000000000 --- a/Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt +++ /dev/null @@ -1,29 +0,0 @@ -Allwinner sunxi-sid - -Required properties: -- compatible: Should be one of the following: - "allwinner,sun4i-a10-sid" - "allwinner,sun7i-a20-sid" - "allwinner,sun8i-a83t-sid" - "allwinner,sun8i-h3-sid" - "allwinner,sun50i-a64-sid" - "allwinner,sun50i-h5-sid" - "allwinner,sun50i-h6-sid" - -- reg: Should contain registers location and length - -= Data cells = -Are child nodes of sunxi-sid, bindings of which as described in -bindings/nvmem/nvmem.txt - -Example for sun4i: - sid@1c23800 { - compatible = "allwinner,sun4i-a10-sid"; - reg = <0x01c23800 0x10> - }; - -Example for sun7i: - sid@1c23800 { - compatible = "allwinner,sun7i-a20-sid"; - reg = <0x01c23800 0x200> - }; -- cgit v1.2.3-59-g8ed1b From ae1c6b9aa34be021555e1234a271d56108caa82e Mon Sep 17 00:00:00 2001 From: Pankaj Bansal Date: Wed, 12 Jun 2019 08:52:56 +0000 Subject: dt-bindings: add register based devices' mux controller DT bindings This adds device tree binding documentation for generic register based multiplexer controlled by a bitfields in a parent device's register range. since MMIO mux is a special case of generic register based mux, the MMIO mux bindings have been subsumed in these bindings. Signed-off-by: Pankaj Bansal Signed-off-by: Peter Rosin Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/mux/mmio-mux.txt | 60 ---------- Documentation/devicetree/bindings/mux/reg-mux.txt | 129 +++++++++++++++++++++ 2 files changed, 129 insertions(+), 60 deletions(-) delete mode 100644 Documentation/devicetree/bindings/mux/mmio-mux.txt create mode 100644 Documentation/devicetree/bindings/mux/reg-mux.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mux/mmio-mux.txt b/Documentation/devicetree/bindings/mux/mmio-mux.txt deleted file mode 100644 index a9bfb4d8b6ac..000000000000 --- a/Documentation/devicetree/bindings/mux/mmio-mux.txt +++ /dev/null @@ -1,60 +0,0 @@ -MMIO register bitfield-based multiplexer controller bindings - -Define register bitfields to be used to control multiplexers. The parent -device tree node must be a syscon node to provide register access. - -Required properties: -- compatible : "mmio-mux" -- #mux-control-cells : <1> -- mux-reg-masks : an array of register offset and pre-shifted bitfield mask - pairs, each describing a single mux control. -* Standard mux-controller bindings as decribed in mux-controller.txt - -Optional properties: -- idle-states : if present, the state the muxes will have when idle. The - special state MUX_IDLE_AS_IS is the default. - -The multiplexer state of each multiplexer is defined as the value of the -bitfield described by the corresponding register offset and bitfield mask pair -in the mux-reg-masks array, accessed through the parent syscon. - -Example: - - syscon { - compatible = "syscon"; - - mux: mux-controller { - compatible = "mmio-mux"; - #mux-control-cells = <1>; - - mux-reg-masks = <0x3 0x30>, /* 0: reg 0x3, bits 5:4 */ - <0x3 0x40>, /* 1: reg 0x3, bit 6 */ - idle-states = , <0>; - }; - }; - - video-mux { - compatible = "video-mux"; - mux-controls = <&mux 0>; - - ports { - /* inputs 0..3 */ - port@0 { - reg = <0>; - }; - port@1 { - reg = <1>; - }; - port@2 { - reg = <2>; - }; - port@3 { - reg = <3>; - }; - - /* output */ - port@4 { - reg = <4>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/mux/reg-mux.txt b/Documentation/devicetree/bindings/mux/reg-mux.txt new file mode 100644 index 000000000000..4afd7ba73d60 --- /dev/null +++ b/Documentation/devicetree/bindings/mux/reg-mux.txt @@ -0,0 +1,129 @@ +Generic register bitfield-based multiplexer controller bindings + +Define register bitfields to be used to control multiplexers. The parent +device tree node must be a device node to provide register r/w access. + +Required properties: +- compatible : should be one of + "reg-mux" : if parent device of mux controller is not syscon device + "mmio-mux" : if parent device of mux controller is syscon device +- #mux-control-cells : <1> +- mux-reg-masks : an array of register offset and pre-shifted bitfield mask + pairs, each describing a single mux control. +* Standard mux-controller bindings as decribed in mux-controller.txt + +Optional properties: +- idle-states : if present, the state the muxes will have when idle. The + special state MUX_IDLE_AS_IS is the default. + +The multiplexer state of each multiplexer is defined as the value of the +bitfield described by the corresponding register offset and bitfield mask +pair in the mux-reg-masks array. + +Example 1: +The parent device of mux controller is not a syscon device. + +&i2c0 { + fpga@66 { // fpga connected to i2c + compatible = "fsl,lx2160aqds-fpga", "fsl,fpga-qixis-i2c", + "simple-mfd"; + reg = <0x66>; + + mux: mux-controller { + compatible = "reg-mux"; + #mux-control-cells = <1>; + mux-reg-masks = <0x54 0xf8>, /* 0: reg 0x54, bits 7:3 */ + <0x54 0x07>; /* 1: reg 0x54, bits 2:0 */ + }; + }; +}; + +mdio-mux-1 { + compatible = "mdio-mux-multiplexer"; + mux-controls = <&mux 0>; + mdio-parent-bus = <&emdio1>; + #address-cells = <1>; + #size-cells = <0>; + + mdio@0 { + reg = <0x0>; + #address-cells = <1>; + #size-cells = <0>; + }; + + mdio@8 { + reg = <0x8>; + #address-cells = <1>; + #size-cells = <0>; + }; + + .. + .. +}; + +mdio-mux-2 { + compatible = "mdio-mux-multiplexer"; + mux-controls = <&mux 1>; + mdio-parent-bus = <&emdio2>; + #address-cells = <1>; + #size-cells = <0>; + + mdio@0 { + reg = <0x0>; + #address-cells = <1>; + #size-cells = <0>; + }; + + mdio@1 { + reg = <0x1>; + #address-cells = <1>; + #size-cells = <0>; + }; + + .. + .. +}; + +Example 2: +The parent device of mux controller is syscon device. + +syscon { + compatible = "syscon"; + + mux: mux-controller { + compatible = "mmio-mux"; + #mux-control-cells = <1>; + + mux-reg-masks = <0x3 0x30>, /* 0: reg 0x3, bits 5:4 */ + <0x3 0x40>, /* 1: reg 0x3, bit 6 */ + idle-states = , <0>; + }; +}; + +video-mux { + compatible = "video-mux"; + mux-controls = <&mux 0>; + #address-cells = <1>; + #size-cells = <0>; + + ports { + /* inputs 0..3 */ + port@0 { + reg = <0>; + }; + port@1 { + reg = <1>; + }; + port@2 { + reg = <2>; + }; + port@3 { + reg = <3>; + }; + + /* output */ + port@4 { + reg = <4>; + }; + }; +}; -- cgit v1.2.3-59-g8ed1b From 7a82a01e5c850986d4b53dab52ac71294285586f Mon Sep 17 00:00:00 2001 From: Dragan Cvetic Date: Tue, 11 Jun 2019 18:29:35 +0100 Subject: dt-bindings: xilinx-sdfec: Add SDFEC binding Add the Soft Decision Forward Error Correction (SDFEC) Engine bindings which is available for the Zynq UltraScale+ RFSoC FPGA's. Signed-off-by: Dragan Cvetic Signed-off-by: Derek Kiernan Reviewed-by: Rob Herring .../devicetree/bindings/misc/xlnx,sd-fec.txt | 58 ++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 Documentation/devicetree/bindings/misc/xlnx,sd-fec.txt Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/misc/xlnx,sd-fec.txt | 58 ++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 Documentation/devicetree/bindings/misc/xlnx,sd-fec.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/misc/xlnx,sd-fec.txt b/Documentation/devicetree/bindings/misc/xlnx,sd-fec.txt new file mode 100644 index 000000000000..e3289634fa30 --- /dev/null +++ b/Documentation/devicetree/bindings/misc/xlnx,sd-fec.txt @@ -0,0 +1,58 @@ +* Xilinx SDFEC(16nm) IP * + +The Soft Decision Forward Error Correction (SDFEC) Engine is a Hard IP block +which provides high-throughput LDPC and Turbo Code implementations. +The LDPC decode & encode functionality is capable of covering a range of +customer specified Quasi-cyclic (QC) codes. The Turbo decode functionality +principally covers codes used by LTE. The FEC Engine offers significant +power and area savings versus implementations done in the FPGA fabric. + + +Required properties: +- compatible: Must be "xlnx,sd-fec-1.1" +- clock-names : List of input clock names from the following: + - "core_clk", Main processing clock for processing core (required) + - "s_axi_aclk", AXI4-Lite memory-mapped slave interface clock (required) + - "s_axis_din_aclk", DIN AXI4-Stream Slave interface clock (optional) + - "s_axis_din_words-aclk", DIN_WORDS AXI4-Stream Slave interface clock (optional) + - "s_axis_ctrl_aclk", Control input AXI4-Stream Slave interface clock (optional) + - "m_axis_dout_aclk", DOUT AXI4-Stream Master interface clock (optional) + - "m_axis_dout_words_aclk", DOUT_WORDS AXI4-Stream Master interface clock (optional) + - "m_axis_status_aclk", Status output AXI4-Stream Master interface clock (optional) +- clocks : Clock phandles (see clock_bindings.txt for details). +- reg: Should contain Xilinx SDFEC 16nm Hardened IP block registers + location and length. +- xlnx,sdfec-code : Should contain "ldpc" or "turbo" to describe the codes + being used. +- xlnx,sdfec-din-words : A value 0 indicates that the DIN_WORDS interface is + driven with a fixed value and is not present on the device, a value of 1 + configures the DIN_WORDS to be block based, while a value of 2 configures the + DIN_WORDS input to be supplied for each AXI transaction. +- xlnx,sdfec-din-width : Configures the DIN AXI stream where a value of 1 + configures a width of "1x128b", 2 a width of "2x128b" and 4 configures a width + of "4x128b". +- xlnx,sdfec-dout-words : A value 0 indicates that the DOUT_WORDS interface is + driven with a fixed value and is not present on the device, a value of 1 + configures the DOUT_WORDS to be block based, while a value of 2 configures the + DOUT_WORDS input to be supplied for each AXI transaction. +- xlnx,sdfec-dout-width : Configures the DOUT AXI stream where a value of 1 + configures a width of "1x128b", 2 a width of "2x128b" and 4 configures a width + of "4x128b". +Optional properties: +- interrupts: should contain SDFEC interrupt number + +Example +--------------------------------------- + sd_fec_0: sd-fec@a0040000 { + compatible = "xlnx,sd-fec-1.1"; + clock-names = "core_clk","s_axi_aclk","s_axis_ctrl_aclk","s_axis_din_aclk","m_axis_status_aclk","m_axis_dout_aclk"; + clocks = <&misc_clk_2>,<&misc_clk_0>,<&misc_clk_1>,<&misc_clk_1>,<&misc_clk_1>, <&misc_clk_1>; + reg = <0x0 0xa0040000 0x0 0x40000>; + interrupt-parent = <&axi_intc>; + interrupts = <1 0>; + xlnx,sdfec-code = "ldpc"; + xlnx,sdfec-din-words = <0>; + xlnx,sdfec-din-width = <2>; + xlnx,sdfec-dout-words = <0>; + xlnx,sdfec-dout-width = <1>; + }; -- cgit v1.2.3-59-g8ed1b From 22d137e283e63a62414464744302e01f28196ffc Mon Sep 17 00:00:00 2001 From: Paul Cercueil Date: Tue, 4 Jun 2019 16:30:15 +0200 Subject: dt-bindings: memory: jz4780: Add compatible string for JZ4740 SoC Add a compatible string to support the memory controller built into the JZ4740 SoC from Ingenic. Signed-off-by: Paul Cercueil Reviewed-by: Boris Brezillon Reviewed-by: Rob Herring Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/memory-controllers/ingenic,jz4780-nemc.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/ingenic,jz4780-nemc.txt b/Documentation/devicetree/bindings/memory-controllers/ingenic,jz4780-nemc.txt index f936b5589b19..59b8dcc118ee 100644 --- a/Documentation/devicetree/bindings/memory-controllers/ingenic,jz4780-nemc.txt +++ b/Documentation/devicetree/bindings/memory-controllers/ingenic,jz4780-nemc.txt @@ -5,6 +5,7 @@ controller in Ingenic JZ4780 Required properties: - compatible: Should be set to one of: + "ingenic,jz4740-nemc" (JZ4740) "ingenic,jz4780-nemc" (JZ4780) - reg: Should specify the NEMC controller registers location and length. - clocks: Clock for the NEMC controller. -- cgit v1.2.3-59-g8ed1b From fd757dbac5f6c42f45b1a29a354255045a655a27 Mon Sep 17 00:00:00 2001 From: Tomasz Figa Date: Fri, 21 Jun 2019 13:13:51 +0200 Subject: dt-bindings: extcon: Add support for fsa9480 switch MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This patch adds documentation for binding of extcont Fairchild Semiconductor FSA9480 microusb switch. This usb port accessory detector and switch, can be found for example in some Samsung s5pv210 based phones. Signed-off-by: Tomasz Figa Signed-off-by: Paweł Chmiel Acked-by: Chanwoo Choi Signed-off-by: Chanwoo Choi --- .../devicetree/bindings/extcon/extcon-fsa9480.txt | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt b/Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt new file mode 100644 index 000000000000..d592c21245f2 --- /dev/null +++ b/Documentation/devicetree/bindings/extcon/extcon-fsa9480.txt @@ -0,0 +1,19 @@ +FAIRCHILD SEMICONDUCTOR FSA9480 MICROUSB SWITCH + +The FSA9480 is a USB port accessory detector and switch. The FSA9480 is fully +controlled using I2C and enables USB data, stereo and mono audio, video, +microphone, and UART data to use a common connector port. + +Required properties: + - compatible : Must be "fcs,fsa9480" + - reg : Specifies i2c slave address. Must be 0x25. + - interrupts : Should contain one entry specifying interrupt signal of + interrupt parent to which interrupt pin of the chip is connected. + + Example: + musb@25 { + compatible = "fcs,fsa9480"; + reg = <0x25>; + interrupt-parent = <&gph2>; + interrupts = <7 0>; + }; -- cgit v1.2.3-59-g8ed1b From 25c7eabed5b219e975c8aee527ae202604d10911 Mon Sep 17 00:00:00 2001 From: Bryan O'Donoghue Date: Wed, 26 Jun 2019 11:27:32 +0100 Subject: dt-bindings: imx-ocotp: Add i.MX8MM compatible Add compatible for i.MX8MM as per arch/arm64/boot/dts/freescale/imx8mm.dtsi Signed-off-by: Bryan O'Donoghue Cc: Rob Herring Reviewed-by: Leonard Crestez Signed-off-by: Srinivas Kandagatla Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/nvmem/imx-ocotp.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt index 68f7d6fdd140..96ffd06d2ca8 100644 --- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.txt @@ -15,6 +15,7 @@ Required properties: "fsl,imx6sll-ocotp" (i.MX6SLL), "fsl,imx7ulp-ocotp" (i.MX7ULP), "fsl,imx8mq-ocotp" (i.MX8MQ), + "fsl,imx8mm-ocotp" (i.MX8MM), followed by "syscon". - #address-cells : Should be 1 - #size-cells : Should be 1 -- cgit v1.2.3-59-g8ed1b From 9b5db89ea4bfdbb23d4f85f3a7fbf2cd36d20146 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Fri, 28 Jun 2019 18:23:13 -0300 Subject: docs: misc-devices: convert files without extension to ReST Those files are also text files. Convert them to ReST and add to the misc-files index.rst. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/b7dc829809673bd8cffe0e7bbe9c9308681c6fe2.1561756511.git.mchehab+samsung@kernel.org Signed-off-by: Greg Kroah-Hartman --- Documentation/misc-devices/eeprom | 96 --------------------- Documentation/misc-devices/eeprom.rst | 107 +++++++++++++++++++++++ Documentation/misc-devices/ics932s401 | 31 ------- Documentation/misc-devices/ics932s401.rst | 36 ++++++++ Documentation/misc-devices/index.rst | 5 ++ Documentation/misc-devices/isl29003 | 62 -------------- Documentation/misc-devices/isl29003.rst | 75 ++++++++++++++++ Documentation/misc-devices/lis3lv02d | 93 -------------------- Documentation/misc-devices/lis3lv02d.rst | 99 ++++++++++++++++++++++ Documentation/misc-devices/max6875 | 110 ------------------------ Documentation/misc-devices/max6875.rst | 136 ++++++++++++++++++++++++++++++ MAINTAINERS | 4 +- drivers/misc/isl29003.c | 2 +- drivers/platform/x86/Kconfig | 2 +- 14 files changed, 462 insertions(+), 396 deletions(-) delete mode 100644 Documentation/misc-devices/eeprom create mode 100644 Documentation/misc-devices/eeprom.rst delete mode 100644 Documentation/misc-devices/ics932s401 create mode 100644 Documentation/misc-devices/ics932s401.rst delete mode 100644 Documentation/misc-devices/isl29003 create mode 100644 Documentation/misc-devices/isl29003.rst delete mode 100644 Documentation/misc-devices/lis3lv02d create mode 100644 Documentation/misc-devices/lis3lv02d.rst delete mode 100644 Documentation/misc-devices/max6875 create mode 100644 Documentation/misc-devices/max6875.rst (limited to 'Documentation') diff --git a/Documentation/misc-devices/eeprom b/Documentation/misc-devices/eeprom deleted file mode 100644 index ba692011f221..000000000000 --- a/Documentation/misc-devices/eeprom +++ /dev/null @@ -1,96 +0,0 @@ -Kernel driver eeprom -==================== - -Supported chips: - * Any EEPROM chip in the designated address range - Prefix: 'eeprom' - Addresses scanned: I2C 0x50 - 0x57 - Datasheets: Publicly available from: - Atmel (www.atmel.com), - Catalyst (www.catsemi.com), - Fairchild (www.fairchildsemi.com), - Microchip (www.microchip.com), - Philips (www.semiconductor.philips.com), - Rohm (www.rohm.com), - ST (www.st.com), - Xicor (www.xicor.com), - and others. - - Chip Size (bits) Address - 24C01 1K 0x50 (shadows at 0x51 - 0x57) - 24C01A 1K 0x50 - 0x57 (Typical device on DIMMs) - 24C02 2K 0x50 - 0x57 - 24C04 4K 0x50, 0x52, 0x54, 0x56 - (additional data at 0x51, 0x53, 0x55, 0x57) - 24C08 8K 0x50, 0x54 (additional data at 0x51, 0x52, - 0x53, 0x55, 0x56, 0x57) - 24C16 16K 0x50 (additional data at 0x51 - 0x57) - Sony 2K 0x57 - - Atmel 34C02B 2K 0x50 - 0x57, SW write protect at 0x30-37 - Catalyst 34FC02 2K 0x50 - 0x57, SW write protect at 0x30-37 - Catalyst 34RC02 2K 0x50 - 0x57, SW write protect at 0x30-37 - Fairchild 34W02 2K 0x50 - 0x57, SW write protect at 0x30-37 - Microchip 24AA52 2K 0x50 - 0x57, SW write protect at 0x30-37 - ST M34C02 2K 0x50 - 0x57, SW write protect at 0x30-37 - - -Authors: - Frodo Looijaard , - Philip Edelbrock , - Jean Delvare , - Greg Kroah-Hartman , - IBM Corp. - -Description ------------ - -This is a simple EEPROM module meant to enable reading the first 256 bytes -of an EEPROM (on a SDRAM DIMM for example). However, it will access serial -EEPROMs on any I2C adapter. The supported devices are generically called -24Cxx, and are listed above; however the numbering for these -industry-standard devices may vary by manufacturer. - -This module was a programming exercise to get used to the new project -organization laid out by Frodo, but it should be at least completely -effective for decoding the contents of EEPROMs on DIMMs. - -DIMMS will typically contain a 24C01A or 24C02, or the 34C02 variants. -The other devices will not be found on a DIMM because they respond to more -than one address. - -DDC Monitors may contain any device. Often a 24C01, which responds to all 8 -addresses, is found. - -Recent Sony Vaio laptops have an EEPROM at 0x57. We couldn't get the -specification, so it is guess work and far from being complete. - -The Microchip 24AA52/24LCS52, ST M34C02, and others support an additional -software write protect register at 0x30 - 0x37 (0x20 less than the memory -location). The chip responds to "write quick" detection at this address but -does not respond to byte reads. If this register is present, the lower 128 -bytes of the memory array are not write protected. Any byte data write to -this address will write protect the memory array permanently, and the -device will no longer respond at the 0x30-37 address. The eeprom driver -does not support this register. - -Lacking functionality: - -* Full support for larger devices (24C04, 24C08, 24C16). These are not -typically found on a PC. These devices will appear as separate devices at -multiple addresses. - -* Support for really large devices (24C32, 24C64, 24C128, 24C256, 24C512). -These devices require two-byte address fields and are not supported. - -* Enable Writing. Again, no technical reason why not, but making it easy -to change the contents of the EEPROMs (on DIMMs anyway) also makes it easy -to disable the DIMMs (potentially preventing the computer from booting) -until the values are restored somehow. - -Use: - -After inserting the module (and any other required SMBus/i2c modules), you -should have some EEPROM directories in /sys/bus/i2c/devices/* of names such -as "0-0050". Inside each of these is a series of files, the eeprom file -contains the binary data from EEPROM. diff --git a/Documentation/misc-devices/eeprom.rst b/Documentation/misc-devices/eeprom.rst new file mode 100644 index 000000000000..008249675ccc --- /dev/null +++ b/Documentation/misc-devices/eeprom.rst @@ -0,0 +1,107 @@ +==================== +Kernel driver eeprom +==================== + +Supported chips: + + * Any EEPROM chip in the designated address range + + Prefix: 'eeprom' + + Addresses scanned: I2C 0x50 - 0x57 + + Datasheets: Publicly available from: + + Atmel (www.atmel.com), + Catalyst (www.catsemi.com), + Fairchild (www.fairchildsemi.com), + Microchip (www.microchip.com), + Philips (www.semiconductor.philips.com), + Rohm (www.rohm.com), + ST (www.st.com), + Xicor (www.xicor.com), + and others. + + ========= ============= ============================================ + Chip Size (bits) Address + ========= ============= ============================================ + 24C01 1K 0x50 (shadows at 0x51 - 0x57) + 24C01A 1K 0x50 - 0x57 (Typical device on DIMMs) + 24C02 2K 0x50 - 0x57 + 24C04 4K 0x50, 0x52, 0x54, 0x56 + (additional data at 0x51, 0x53, 0x55, 0x57) + 24C08 8K 0x50, 0x54 (additional data at 0x51, 0x52, + 0x53, 0x55, 0x56, 0x57) + 24C16 16K 0x50 (additional data at 0x51 - 0x57) + Sony 2K 0x57 + + Atmel 34C02B 2K 0x50 - 0x57, SW write protect at 0x30-37 + Catalyst 34FC02 2K 0x50 - 0x57, SW write protect at 0x30-37 + Catalyst 34RC02 2K 0x50 - 0x57, SW write protect at 0x30-37 + Fairchild 34W02 2K 0x50 - 0x57, SW write protect at 0x30-37 + Microchip 24AA52 2K 0x50 - 0x57, SW write protect at 0x30-37 + ST M34C02 2K 0x50 - 0x57, SW write protect at 0x30-37 + ========= ============= ============================================ + + +Authors: + - Frodo Looijaard , + - Philip Edelbrock , + - Jean Delvare , + - Greg Kroah-Hartman , + - IBM Corp. + +Description +----------- + +This is a simple EEPROM module meant to enable reading the first 256 bytes +of an EEPROM (on a SDRAM DIMM for example). However, it will access serial +EEPROMs on any I2C adapter. The supported devices are generically called +24Cxx, and are listed above; however the numbering for these +industry-standard devices may vary by manufacturer. + +This module was a programming exercise to get used to the new project +organization laid out by Frodo, but it should be at least completely +effective for decoding the contents of EEPROMs on DIMMs. + +DIMMS will typically contain a 24C01A or 24C02, or the 34C02 variants. +The other devices will not be found on a DIMM because they respond to more +than one address. + +DDC Monitors may contain any device. Often a 24C01, which responds to all 8 +addresses, is found. + +Recent Sony Vaio laptops have an EEPROM at 0x57. We couldn't get the +specification, so it is guess work and far from being complete. + +The Microchip 24AA52/24LCS52, ST M34C02, and others support an additional +software write protect register at 0x30 - 0x37 (0x20 less than the memory +location). The chip responds to "write quick" detection at this address but +does not respond to byte reads. If this register is present, the lower 128 +bytes of the memory array are not write protected. Any byte data write to +this address will write protect the memory array permanently, and the +device will no longer respond at the 0x30-37 address. The eeprom driver +does not support this register. + +Lacking functionality +--------------------- + +* Full support for larger devices (24C04, 24C08, 24C16). These are not + typically found on a PC. These devices will appear as separate devices at + multiple addresses. + +* Support for really large devices (24C32, 24C64, 24C128, 24C256, 24C512). + These devices require two-byte address fields and are not supported. + +* Enable Writing. Again, no technical reason why not, but making it easy + to change the contents of the EEPROMs (on DIMMs anyway) also makes it easy + to disable the DIMMs (potentially preventing the computer from booting) + until the values are restored somehow. + +Use +--- + +After inserting the module (and any other required SMBus/i2c modules), you +should have some EEPROM directories in ``/sys/bus/i2c/devices/*`` of names such +as "0-0050". Inside each of these is a series of files, the eeprom file +contains the binary data from EEPROM. diff --git a/Documentation/misc-devices/ics932s401 b/Documentation/misc-devices/ics932s401 deleted file mode 100644 index bdac67ff6e3f..000000000000 --- a/Documentation/misc-devices/ics932s401 +++ /dev/null @@ -1,31 +0,0 @@ -Kernel driver ics932s401 -====================== - -Supported chips: - * IDT ICS932S401 - Prefix: 'ics932s401' - Addresses scanned: I2C 0x69 - Datasheet: Publicly available at the IDT website - -Author: Darrick J. Wong - -Description ------------ - -This driver implements support for the IDT ICS932S401 chip family. - -This chip has 4 clock outputs--a base clock for the CPU (which is likely -multiplied to get the real CPU clock), a system clock, a PCI clock, a USB -clock, and a reference clock. The driver reports selected and actual -frequency. If spread spectrum mode is enabled, the driver also reports by what -percent the clock signal is being spread, which should be between 0 and -0.5%. -All frequencies are reported in KHz. - -The ICS932S401 monitors all inputs continuously. The driver will not read -the registers more often than once every other second. - -Special Features ----------------- - -The clocks could be reprogrammed to increase system speed. I will not help you -do this, as you risk damaging your system! diff --git a/Documentation/misc-devices/ics932s401.rst b/Documentation/misc-devices/ics932s401.rst new file mode 100644 index 000000000000..613ee54a9c21 --- /dev/null +++ b/Documentation/misc-devices/ics932s401.rst @@ -0,0 +1,36 @@ +======================== +Kernel driver ics932s401 +======================== + +Supported chips: + + * IDT ICS932S401 + + Prefix: 'ics932s401' + + Addresses scanned: I2C 0x69 + + Datasheet: Publicly available at the IDT website + +Author: Darrick J. Wong + +Description +----------- + +This driver implements support for the IDT ICS932S401 chip family. + +This chip has 4 clock outputs--a base clock for the CPU (which is likely +multiplied to get the real CPU clock), a system clock, a PCI clock, a USB +clock, and a reference clock. The driver reports selected and actual +frequency. If spread spectrum mode is enabled, the driver also reports by what +percent the clock signal is being spread, which should be between 0 and -0.5%. +All frequencies are reported in KHz. + +The ICS932S401 monitors all inputs continuously. The driver will not read +the registers more often than once every other second. + +Special Features +---------------- + +The clocks could be reprogrammed to increase system speed. I will not help you +do this, as you risk damaging your system! diff --git a/Documentation/misc-devices/index.rst b/Documentation/misc-devices/index.rst index dfd1f45a3127..a57f92dfe49a 100644 --- a/Documentation/misc-devices/index.rst +++ b/Documentation/misc-devices/index.rst @@ -14,4 +14,9 @@ fit into other categories. .. toctree:: :maxdepth: 2 + eeprom ibmvmc + ics932s401 + isl29003 + lis3lv02d + max6875 diff --git a/Documentation/misc-devices/isl29003 b/Documentation/misc-devices/isl29003 deleted file mode 100644 index 80b952fd32ff..000000000000 --- a/Documentation/misc-devices/isl29003 +++ /dev/null @@ -1,62 +0,0 @@ -Kernel driver isl29003 -===================== - -Supported chips: -* Intersil ISL29003 -Prefix: 'isl29003' -Addresses scanned: none -Datasheet: -http://www.intersil.com/data/fn/fn7464.pdf - -Author: Daniel Mack - - -Description ------------ -The ISL29003 is an integrated light sensor with a 16-bit integrating type -ADC, I2C user programmable lux range select for optimized counts/lux, and -I2C multi-function control and monitoring capabilities. The internal ADC -provides 16-bit resolution while rejecting 50Hz and 60Hz flicker caused by -artificial light sources. - -The driver allows to set the lux range, the bit resolution, the operational -mode (see below) and the power state of device and can read the current lux -value, of course. - - -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 -address and consider the device to be present as soon as it ACKs the -transfer. - - -Sysfs entries -------------- - -range: - 0: 0 lux to 1000 lux (default) - 1: 0 lux to 4000 lux - 2: 0 lux to 16,000 lux - 3: 0 lux to 64,000 lux - -resolution: - 0: 2^16 cycles (default) - 1: 2^12 cycles - 2: 2^8 cycles - 3: 2^4 cycles - -mode: - 0: diode1's current (unsigned 16bit) (default) - 1: diode1's current (unsigned 16bit) - 2: difference between diodes (l1 - l2, signed 15bit) - -power_state: - 0: device is disabled (default) - 1: device is enabled - -lux (read only): - returns the value from the last sensor reading - diff --git a/Documentation/misc-devices/isl29003.rst b/Documentation/misc-devices/isl29003.rst new file mode 100644 index 000000000000..0cc38aed6c00 --- /dev/null +++ b/Documentation/misc-devices/isl29003.rst @@ -0,0 +1,75 @@ +====================== +Kernel driver isl29003 +====================== + +Supported chips: + +* Intersil ISL29003 + +Prefix: 'isl29003' + +Addresses scanned: none + +Datasheet: +http://www.intersil.com/data/fn/fn7464.pdf + +Author: Daniel Mack + + +Description +----------- +The ISL29003 is an integrated light sensor with a 16-bit integrating type +ADC, I2C user programmable lux range select for optimized counts/lux, and +I2C multi-function control and monitoring capabilities. The internal ADC +provides 16-bit resolution while rejecting 50Hz and 60Hz flicker caused by +artificial light sources. + +The driver allows to set the lux range, the bit resolution, the operational +mode (see below) and the power state of device and can read the current lux +value, of course. + + +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 +address and consider the device to be present as soon as it ACKs the +transfer. + + +Sysfs entries +------------- + +range: + == =========================== + 0: 0 lux to 1000 lux (default) + 1: 0 lux to 4000 lux + 2: 0 lux to 16,000 lux + 3: 0 lux to 64,000 lux + == =========================== + +resolution: + == ===================== + 0: 2^16 cycles (default) + 1: 2^12 cycles + 2: 2^8 cycles + 3: 2^4 cycles + == ===================== + +mode: + == ================================================= + 0: diode1's current (unsigned 16bit) (default) + 1: diode1's current (unsigned 16bit) + 2: difference between diodes (l1 - l2, signed 15bit) + == ================================================= + +power_state: + == ================================================= + 0: device is disabled (default) + 1: device is enabled + == ================================================= + +lux (read only): + returns the value from the last sensor reading + diff --git a/Documentation/misc-devices/lis3lv02d b/Documentation/misc-devices/lis3lv02d deleted file mode 100644 index f89960a0ff95..000000000000 --- a/Documentation/misc-devices/lis3lv02d +++ /dev/null @@ -1,93 +0,0 @@ -Kernel driver lis3lv02d -======================= - -Supported chips: - - * STMicroelectronics LIS3LV02DL, LIS3LV02DQ (12 bits precision) - * STMicroelectronics LIS302DL, LIS3L02DQ, LIS331DL (8 bits) and - LIS331DLH (16 bits) - -Authors: - Yan Burman - Eric Piel - - -Description ------------ - -This driver provides support for the accelerometer found in various HP laptops -sporting the feature officially called "HP Mobile Data Protection System 3D" or -"HP 3D DriveGuard". It detects automatically laptops with this sensor. Known -models (full list can be found in drivers/platform/x86/hp_accel.c) will have -their axis automatically oriented on standard way (eg: you can directly play -neverball). The accelerometer data is readable via -/sys/devices/platform/lis3lv02d. Reported values are scaled -to mg values (1/1000th of earth gravity). - -Sysfs attributes under /sys/devices/platform/lis3lv02d/: -position - 3D position that the accelerometer reports. Format: "(x,y,z)" -rate - read reports the sampling rate of the accelerometer device in HZ. - write changes sampling rate of the accelerometer device. - Only values which are supported by HW are accepted. -selftest - performs selftest for the chip as specified by chip manufacturer. - -This driver also provides an absolute input class device, allowing -the laptop to act as a pinball machine-esque joystick. Joystick device can be -calibrated. Joystick device can be in two different modes. -By default output values are scaled between -32768 .. 32767. In joystick raw -mode, joystick and sysfs position entry have the same scale. There can be -small difference due to input system fuzziness feature. -Events are also available as input event device. - -Selftest is meant only for hardware diagnostic purposes. It is not meant to be -used during normal operations. Position data is not corrupted during selftest -but interrupt behaviour is not guaranteed to work reliably. In test mode, the -sensing element is internally moved little bit. Selftest measures difference -between normal mode and test mode. Chip specifications tell the acceptance -limit for each type of the chip. Limits are provided via platform data -to allow adjustment of the limits without a change to the actual driver. -Seltest returns either "OK x y z" or "FAIL x y z" where x, y and z are -measured difference between modes. Axes are not remapped in selftest mode. -Measurement values are provided to help HW diagnostic applications to make -final decision. - -On HP laptops, if the led infrastructure is activated, support for a led -indicating disk protection will be provided as /sys/class/leds/hp::hddprotect. - -Another feature of the driver is misc device called "freefall" that -acts similar to /dev/rtc and reacts on free-fall interrupts received -from the device. It supports blocking operations, poll/select and -fasync operation modes. You must read 1 bytes from the device. The -result is number of free-fall interrupts since the last successful -read (or 255 if number of interrupts would not fit). See the freefall.c -file for an example on using the device. - - -Axes orientation ----------------- - -For better compatibility between the various laptops. The values reported by -the accelerometer are converted into a "standard" organisation of the axes -(aka "can play neverball out of the box"): - * When the laptop is horizontal the position reported is about 0 for X and Y - and a positive value for Z - * If the left side is elevated, X increases (becomes positive) - * If the front side (where the touchpad is) is elevated, Y decreases - (becomes negative) - * If the laptop is put upside-down, Z becomes negative - -If your laptop model is not recognized (cf "dmesg"), you can send an -email to the maintainer to add it to the database. When reporting a new -laptop, please include the output of "dmidecode" plus the value of -/sys/devices/platform/lis3lv02d/position in these four cases. - -Q&A ---- - -Q: How do I safely simulate freefall? I have an HP "portable -workstation" which has about 3.5kg and a plastic case, so letting it -fall to the ground is out of question... - -A: The sensor is pretty sensitive, so your hands can do it. Lift it -into free space, follow the fall with your hands for like 10 -centimeters. That should be enough to trigger the detection. diff --git a/Documentation/misc-devices/lis3lv02d.rst b/Documentation/misc-devices/lis3lv02d.rst new file mode 100644 index 000000000000..959bd2b822cf --- /dev/null +++ b/Documentation/misc-devices/lis3lv02d.rst @@ -0,0 +1,99 @@ +======================= +Kernel driver lis3lv02d +======================= + +Supported chips: + + * STMicroelectronics LIS3LV02DL, LIS3LV02DQ (12 bits precision) + * STMicroelectronics LIS302DL, LIS3L02DQ, LIS331DL (8 bits) and + LIS331DLH (16 bits) + +Authors: + - Yan Burman + - Eric Piel + + +Description +----------- + +This driver provides support for the accelerometer found in various HP laptops +sporting the feature officially called "HP Mobile Data Protection System 3D" or +"HP 3D DriveGuard". It detects automatically laptops with this sensor. Known +models (full list can be found in drivers/platform/x86/hp_accel.c) will have +their axis automatically oriented on standard way (eg: you can directly play +neverball). The accelerometer data is readable via +/sys/devices/platform/lis3lv02d. Reported values are scaled +to mg values (1/1000th of earth gravity). + +Sysfs attributes under /sys/devices/platform/lis3lv02d/: + +position + - 3D position that the accelerometer reports. Format: "(x,y,z)" +rate + - read reports the sampling rate of the accelerometer device in HZ. + write changes sampling rate of the accelerometer device. + Only values which are supported by HW are accepted. +selftest + - performs selftest for the chip as specified by chip manufacturer. + +This driver also provides an absolute input class device, allowing +the laptop to act as a pinball machine-esque joystick. Joystick device can be +calibrated. Joystick device can be in two different modes. +By default output values are scaled between -32768 .. 32767. In joystick raw +mode, joystick and sysfs position entry have the same scale. There can be +small difference due to input system fuzziness feature. +Events are also available as input event device. + +Selftest is meant only for hardware diagnostic purposes. It is not meant to be +used during normal operations. Position data is not corrupted during selftest +but interrupt behaviour is not guaranteed to work reliably. In test mode, the +sensing element is internally moved little bit. Selftest measures difference +between normal mode and test mode. Chip specifications tell the acceptance +limit for each type of the chip. Limits are provided via platform data +to allow adjustment of the limits without a change to the actual driver. +Seltest returns either "OK x y z" or "FAIL x y z" where x, y and z are +measured difference between modes. Axes are not remapped in selftest mode. +Measurement values are provided to help HW diagnostic applications to make +final decision. + +On HP laptops, if the led infrastructure is activated, support for a led +indicating disk protection will be provided as /sys/class/leds/hp::hddprotect. + +Another feature of the driver is misc device called "freefall" that +acts similar to /dev/rtc and reacts on free-fall interrupts received +from the device. It supports blocking operations, poll/select and +fasync operation modes. You must read 1 bytes from the device. The +result is number of free-fall interrupts since the last successful +read (or 255 if number of interrupts would not fit). See the freefall.c +file for an example on using the device. + + +Axes orientation +---------------- + +For better compatibility between the various laptops. The values reported by +the accelerometer are converted into a "standard" organisation of the axes +(aka "can play neverball out of the box"): + + * When the laptop is horizontal the position reported is about 0 for X and Y + and a positive value for Z + * If the left side is elevated, X increases (becomes positive) + * If the front side (where the touchpad is) is elevated, Y decreases + (becomes negative) + * If the laptop is put upside-down, Z becomes negative + +If your laptop model is not recognized (cf "dmesg"), you can send an +email to the maintainer to add it to the database. When reporting a new +laptop, please include the output of "dmidecode" plus the value of +/sys/devices/platform/lis3lv02d/position in these four cases. + +Q&A +--- + +Q: How do I safely simulate freefall? I have an HP "portable +workstation" which has about 3.5kg and a plastic case, so letting it +fall to the ground is out of question... + +A: The sensor is pretty sensitive, so your hands can do it. Lift it +into free space, follow the fall with your hands for like 10 +centimeters. That should be enough to trigger the detection. diff --git a/Documentation/misc-devices/max6875 b/Documentation/misc-devices/max6875 deleted file mode 100644 index 2f2bd0b17b5d..000000000000 --- a/Documentation/misc-devices/max6875 +++ /dev/null @@ -1,110 +0,0 @@ -Kernel driver max6875 -===================== - -Supported chips: - * Maxim MAX6874, MAX6875 - Prefix: 'max6875' - Addresses scanned: None (see below) - Datasheet: - http://pdfserv.maxim-ic.com/en/ds/MAX6874-MAX6875.pdf - -Author: Ben Gardner - - -Description ------------ - -The Maxim MAX6875 is an EEPROM-programmable power-supply sequencer/supervisor. -It provides timed outputs that can be used as a watchdog, if properly wired. -It also provides 512 bytes of user EEPROM. - -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 inputs -and outputs: - vin gpi vout -MAX6874 6 4 8 -MAX6875 4 3 5 - -See the datasheet for more information. - - -Sysfs entries -------------- - -eeprom - 512 bytes of user-defined EEPROM space. - - -General Remarks ---------------- - -Valid addresses for the MAX6875 are 0x50 and 0x52. -Valid addresses for the MAX6874 are 0x50, 0x52, 0x54 and 0x56. -The driver does not probe any address, so you explicitly instantiate the -devices. - -Example: -$ modprobe max6875 -$ echo max6875 0x50 > /sys/bus/i2c/devices/i2c-0/new_device - -The MAX6874/MAX6875 ignores address bit 0, so this driver attaches to multiple -addresses. For example, for address 0x50, it also reserves 0x51. -The even-address instance is called 'max6875', the odd one is 'dummy'. - - -Programming the chip using i2c-dev ----------------------------------- - -Use the i2c-dev interface to access and program the chips. -Reads and writes are performed differently depending on the address range. - -The configuration registers are at addresses 0x00 - 0x45. -Use i2c_smbus_write_byte_data() to write a register and -i2c_smbus_read_byte_data() to read a register. -The command is the register number. - -Examples: -To write a 1 to register 0x45: - i2c_smbus_write_byte_data(fd, 0x45, 1); - -To read register 0x45: - value = i2c_smbus_read_byte_data(fd, 0x45); - - -The configuration EEPROM is at addresses 0x8000 - 0x8045. -The user EEPROM is at addresses 0x8100 - 0x82ff. - -Use i2c_smbus_write_word_data() to write a byte to EEPROM. - -The command is the upper byte of the address: 0x80, 0x81, or 0x82. -The data word is the lower part of the address or'd with data << 8. - cmd = address >> 8; - val = (address & 0xff) | (data << 8); - -Example: -To write 0x5a to address 0x8003: - i2c_smbus_write_word_data(fd, 0x80, 0x5a03); - - -Reading data from the EEPROM is a little more complicated. -Use i2c_smbus_write_byte_data() to set the read address and then -i2c_smbus_read_byte() or i2c_smbus_read_i2c_block_data() to read the data. - -Example: -To read data starting at offset 0x8100, first set the address: - i2c_smbus_write_byte_data(fd, 0x81, 0x00); - -And then read the data - value = i2c_smbus_read_byte(fd); - - or - - count = i2c_smbus_read_i2c_block_data(fd, 0x84, 16, buffer); - -The block read should read 16 bytes. -0x84 is the block read command. - -See the datasheet for more details. - diff --git a/Documentation/misc-devices/max6875.rst b/Documentation/misc-devices/max6875.rst new file mode 100644 index 000000000000..ad419ac22a5b --- /dev/null +++ b/Documentation/misc-devices/max6875.rst @@ -0,0 +1,136 @@ +===================== +Kernel driver max6875 +===================== + +Supported chips: + + * Maxim MAX6874, MAX6875 + + Prefix: 'max6875' + + Addresses scanned: None (see below) + + Datasheet: http://pdfserv.maxim-ic.com/en/ds/MAX6874-MAX6875.pdf + +Author: Ben Gardner + + +Description +----------- + +The Maxim MAX6875 is an EEPROM-programmable power-supply sequencer/supervisor. +It provides timed outputs that can be used as a watchdog, if properly wired. +It also provides 512 bytes of user EEPROM. + +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 inputs +and outputs: + +=========== === === ==== +- vin gpi vout +=========== === === ==== +MAX6874 6 4 8 +MAX6875 4 3 5 +=========== === === ==== + +See the datasheet for more information. + + +Sysfs entries +------------- + +eeprom - 512 bytes of user-defined EEPROM space. + + +General Remarks +--------------- + +Valid addresses for the MAX6875 are 0x50 and 0x52. + +Valid addresses for the MAX6874 are 0x50, 0x52, 0x54 and 0x56. + +The driver does not probe any address, so you explicitly instantiate the +devices. + +Example:: + + $ modprobe max6875 + $ echo max6875 0x50 > /sys/bus/i2c/devices/i2c-0/new_device + +The MAX6874/MAX6875 ignores address bit 0, so this driver attaches to multiple +addresses. For example, for address 0x50, it also reserves 0x51. +The even-address instance is called 'max6875', the odd one is 'dummy'. + + +Programming the chip using i2c-dev +---------------------------------- + +Use the i2c-dev interface to access and program the chips. + +Reads and writes are performed differently depending on the address range. + +The configuration registers are at addresses 0x00 - 0x45. + +Use i2c_smbus_write_byte_data() to write a register and +i2c_smbus_read_byte_data() to read a register. + +The command is the register number. + +Examples: + +To write a 1 to register 0x45:: + + i2c_smbus_write_byte_data(fd, 0x45, 1); + +To read register 0x45:: + + value = i2c_smbus_read_byte_data(fd, 0x45); + + +The configuration EEPROM is at addresses 0x8000 - 0x8045. + +The user EEPROM is at addresses 0x8100 - 0x82ff. + +Use i2c_smbus_write_word_data() to write a byte to EEPROM. + +The command is the upper byte of the address: 0x80, 0x81, or 0x82. +The data word is the lower part of the address or'd with data << 8:: + + cmd = address >> 8; + val = (address & 0xff) | (data << 8); + +Example: + +To write 0x5a to address 0x8003:: + + i2c_smbus_write_word_data(fd, 0x80, 0x5a03); + + +Reading data from the EEPROM is a little more complicated. + +Use i2c_smbus_write_byte_data() to set the read address and then +i2c_smbus_read_byte() or i2c_smbus_read_i2c_block_data() to read the data. + +Example: + +To read data starting at offset 0x8100, first set the address:: + + i2c_smbus_write_byte_data(fd, 0x81, 0x00); + +And then read the data:: + + value = i2c_smbus_read_byte(fd); + +or:: + + count = i2c_smbus_read_i2c_block_data(fd, 0x84, 16, buffer); + +The block read should read 16 bytes. + +0x84 is the block read command. + +See the datasheet for more details. + diff --git a/MAINTAINERS b/MAINTAINERS index 59e6670c9576..1fc7bafe1d75 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -8871,7 +8871,7 @@ F: include/linux/leds.h LEGACY EEPROM DRIVER M: Jean Delvare S: Maintained -F: Documentation/misc-devices/eeprom +F: Documentation/misc-devices/eeprom.rst F: drivers/misc/eeprom/eeprom.c LEGO MINDSTORMS EV3 @@ -9157,7 +9157,7 @@ F: Documentation/memory-barriers.txt LIS3LV02D ACCELEROMETER DRIVER M: Eric Piel S: Maintained -F: Documentation/misc-devices/lis3lv02d +F: Documentation/misc-devices/lis3lv02d.rst F: drivers/misc/lis3lv02d/ F: drivers/platform/x86/hp_accel.c diff --git a/drivers/misc/isl29003.c b/drivers/misc/isl29003.c index 5d0d0c3bad85..c12406f610d5 100644 --- a/drivers/misc/isl29003.c +++ b/drivers/misc/isl29003.c @@ -3,7 +3,7 @@ * isl29003.c - Linux kernel module for * Intersil ISL29003 ambient light sensor * - * See file:Documentation/misc-devices/isl29003 + * See file:Documentation/misc-devices/isl29003.rst * * Copyright (c) 2009 Daniel Mack * diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig index 5d5cc6111081..efa2ad6635dd 100644 --- a/drivers/platform/x86/Kconfig +++ b/drivers/platform/x86/Kconfig @@ -341,7 +341,7 @@ config HP_ACCEL Support for a led indicating disk protection will be provided as hp::hddprotect. For more information on the feature, refer to - Documentation/misc-devices/lis3lv02d. + Documentation/misc-devices/lis3lv02d.rst. To compile this driver as a module, choose M here: the module will be called hp_accel. -- cgit v1.2.3-59-g8ed1b From 7fc1148cfde1c0d53930c7a5ac62b5bffe7b0e0b Mon Sep 17 00:00:00 2001 From: Zhiyong Tao Date: Wed, 24 Apr 2019 09:11:11 +0800 Subject: dt-bindings: adc: mt8183: add binding document The commit adds mt8183 compatible node in binding document. Signed-off-by: Zhiyong Tao Reviewed-by: Rob Herring Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt b/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt index 0df9befdaecc..936a0b4666da 100644 --- a/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt +++ b/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt @@ -15,6 +15,7 @@ Required properties: - "mediatek,mt2712-auxadc": For MT2712 family of SoCs - "mediatek,mt7622-auxadc": For MT7622 family of SoCs - "mediatek,mt8173-auxadc": For MT8173 family of SoCs + - "mediatek,mt8183-auxadc", "mediatek,mt8173-auxadc": For MT8183 family of SoCs - reg: Address range of the AUXADC unit. - clocks: Should contain a clock specifier for each entry in clock-names - clock-names: Should contain "main". -- cgit v1.2.3-59-g8ed1b From cf54f4dd07a652d9a0630ec4e82c5ff082d2a14e Mon Sep 17 00:00:00 2001 From: Brian Masney Date: Sat, 27 Apr 2019 14:23:59 -0400 Subject: dt-bindings: iio: isl29018: convert bindings to YAML format Convert the isl29018 device tree bindings to the new YAML format. Signed-off-by: Brian Masney Reviewed-by: Rob Herring Signed-off-by: Jonathan Cameron --- .../devicetree/bindings/iio/light/isl29018.txt | 27 ----------- .../devicetree/bindings/iio/light/isl29018.yaml | 56 ++++++++++++++++++++++ 2 files changed, 56 insertions(+), 27 deletions(-) delete mode 100644 Documentation/devicetree/bindings/iio/light/isl29018.txt create mode 100644 Documentation/devicetree/bindings/iio/light/isl29018.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/light/isl29018.txt b/Documentation/devicetree/bindings/iio/light/isl29018.txt deleted file mode 100644 index b9bbde3e13ed..000000000000 --- a/Documentation/devicetree/bindings/iio/light/isl29018.txt +++ /dev/null @@ -1,27 +0,0 @@ -* ISL 29018/29023/29035 I2C ALS, Proximity, and Infrared sensor - -Required properties: - - - compatible: Should be one of - "isil,isl29018" - "isil,isl29023" - "isil,isl29035" - - reg: the I2C address of the device - -Optional properties: - - - interrupts: the sole interrupt generated by the device - - Refer to interrupt-controller/interrupts.txt for generic interrupt client - node bindings. - - - vcc-supply: phandle to the regulator that provides power to the sensor. - -Example: - -isl29018@44 { - compatible = "isil,isl29018"; - reg = <0x44>; - interrupt-parent = <&gpio>; - interrupts = ; -}; diff --git a/Documentation/devicetree/bindings/iio/light/isl29018.yaml b/Documentation/devicetree/bindings/iio/light/isl29018.yaml new file mode 100644 index 000000000000..cbb00be8f359 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/light/isl29018.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/light/isl29018.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: | + Intersil 29018/29023/29035 Ambient Light, Infrared Light, and Proximity Sensor + +maintainers: + - Brian Masney + +description: | + Ambient and infrared light sensing with proximity detection over an i2c + interface. + + https://www.renesas.com/us/en/www/doc/datasheet/isl29018.pdf + https://www.renesas.com/us/en/www/doc/datasheet/isl29023.pdf + https://www.renesas.com/us/en/www/doc/datasheet/isl29035.pdf + +properties: + compatible: + enum: + - isil,isl29018 + - isil,isl29023 + - isil,isl29035 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + vcc-supply: + description: Regulator that provides power to the sensor + +required: + - compatible + - reg + +examples: + - | + #include + + i2c { + + #address-cells = <1>; + #size-cells = <0>; + + sensor@44 { + compatible = "isil,isl29018"; + reg = <0x44>; + interrupts-extended = <&msmgpio 61 IRQ_TYPE_LEVEL_HIGH>; + }; + }; +... -- cgit v1.2.3-59-g8ed1b From 19b44b5257663fec1fea5cf62f4385a442b7a640 Mon Sep 17 00:00:00 2001 From: Jagan Teki Date: Tue, 7 May 2019 18:37:06 +0530 Subject: dt-bindings: display: Document FriendlyELEC HD702E LCD panel HD702E lcd is FriendlyELEC developed eDP LCD panel with 800x1280 resolution. It has built in Goodix, GT9271 captive touchscreen with backlight adjustable via PWM. Add dt-bindings documentation for it. Signed-off-by: Jagan Teki Reviewed-by: Rob Herring Cc: Thierry Reding Cc: David Airlie Cc: Daniel Vetter Cc: dri-devel@lists.freedesktop.org Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20190507130708.11255-1-jagan@amarulasolutions.com --- .../bindings/display/panel/friendlyarm,hd702e.txt | 32 ++++++++++++++++++++++ 1 file changed, 32 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/friendlyarm,hd702e.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/friendlyarm,hd702e.txt b/Documentation/devicetree/bindings/display/panel/friendlyarm,hd702e.txt new file mode 100644 index 000000000000..6c9156fc3478 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/friendlyarm,hd702e.txt @@ -0,0 +1,32 @@ +FriendlyELEC HD702E 800x1280 LCD panel + +HD702E lcd is FriendlyELEC developed eDP LCD panel with 800x1280 +resolution. It has built in Goodix, GT9271 captive touchscreen +with backlight adjustable via PWM. + +Required properties: +- compatible: should be "friendlyarm,hd702e" +- power-supply: regulator to provide the supply voltage + +Optional properties: +- backlight: phandle of the backlight device attached to the panel + +Optional nodes: +- Video port for LCD panel input. + +This binding is compatible with the simple-panel binding, which is specified +in simple-panel.txt in this directory. + +Example: + + panel { + compatible ="friendlyarm,hd702e", "simple-panel"; + backlight = <&backlight>; + power-supply = <&vcc3v3_sys>; + + port { + panel_in_edp: endpoint { + remote-endpoint = <&edp_out_panel>; + }; + }; + }; -- cgit v1.2.3-59-g8ed1b From f7b99e5948e6be8b850eecbb2de1986d26a76b36 Mon Sep 17 00:00:00 2001 From: Radu Pirea Date: Sun, 5 May 2019 21:06:45 +0300 Subject: dt-bindings: mfd: atmel-usart: add DMA bindings for USART in SPI mode The bindings for DMA are now common for both drivers of the USART IP. The node given as an example for USART in SPI mode has been updated in order to include DMA bindings. Signed-off-by: Radu Pirea Signed-off-by: Mark Brown --- .../devicetree/bindings/mfd/atmel-usart.txt | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/atmel-usart.txt b/Documentation/devicetree/bindings/mfd/atmel-usart.txt index 7f0cd72f47d2..699fd3c9ace8 100644 --- a/Documentation/devicetree/bindings/mfd/atmel-usart.txt +++ b/Documentation/devicetree/bindings/mfd/atmel-usart.txt @@ -17,17 +17,24 @@ Required properties for USART in SPI mode: - cs-gpios: chipselects (internal cs not supported) - atmel,usart-mode : Must be (found in dt-bindings/mfd/at91-usart.h) +Optional properties in serial and SPI mode: +- dma bindings for dma transfer: + - dmas: DMA specifier, consisting of a phandle to DMA controller node, + memory peripheral interface and USART DMA channel ID, FIFO configuration. + The order of DMA channels is fixed. The first DMA channel must be TX + associated channel and the second one must be RX associated channel. + Refer to dma.txt and atmel-dma.txt for details. + - dma-names: "tx" for TX channel. + "rx" for RX channel. + The order of dma-names is also fixed. The first name must be "tx" + and the second one must be "rx" as in the examples below. + Optional properties in serial mode: - atmel,use-dma-rx: use of PDC or DMA for receiving data - atmel,use-dma-tx: use of PDC or DMA for transmitting data - {rts,cts,dtr,dsr,rng,dcd}-gpios: specify a GPIO for RTS/CTS/DTR/DSR/RI/DCD line respectively. It will use specified PIO instead of the peripheral function pin for the USART feature. If unsure, don't specify this property. -- add dma bindings for dma transfer: - - dmas: DMA specifier, consisting of a phandle to DMA controller node, - memory peripheral interface and USART DMA channel ID, FIFO configuration. - Refer to dma.txt and atmel-dma.txt for details. - - dma-names: "rx" for RX channel, "tx" for TX channel. - atmel,fifo-size: maximum number of data the RX and TX FIFOs can store for FIFO capable USARTs. - rs485-rts-delay, rs485-rx-during-tx, linux,rs485-enabled-at-boot-time: see rs485.txt @@ -81,5 +88,8 @@ Example: interrupts = <12 IRQ_TYPE_LEVEL_HIGH 5>; clocks = <&usart0_clk>; clock-names = "usart"; + dmas = <&dma0 2 AT91_DMA_CFG_PER_ID(3)>, + <&dma0 2 (AT91_DMA_CFG_PER_ID(4) | AT91_DMA_CFG_FIFOCFG_ASAP)>; + dma-names = "tx", "rx"; cs-gpios = <&pioB 3 0>; }; -- cgit v1.2.3-59-g8ed1b From 6498bf5800a302ef69e7f4914e727893f278bb2f Mon Sep 17 00:00:00 2001 From: Ramalingam C Date: Tue, 7 May 2019 21:57:38 +0530 Subject: drm: revocation check at drm subsystem On every hdcp revocation check request SRM is read from fw file /lib/firmware/display_hdcp_srm.bin SRM table is parsed and stored at drm_hdcp.c, with functions exported for the services for revocation check from drivers (which implements the HDCP authentication) This patch handles the HDCP1.4 and 2.2 versions of SRM table. v2: moved the uAPI to request_firmware_direct() [Daniel] v3: kdoc added. [Daniel] srm_header unified and bit field definitions are removed. [Daniel] locking improved. [Daniel] vrl length violation is fixed. [Daniel] v4: s/__swab16/be16_to_cpu [Daniel] be24_to_cpu is done through a global func [Daniel] Unused variables are removed. [Daniel] unchecked return values are dropped from static funcs [Daniel] Signed-off-by: Ramalingam C Acked-by: Satyeshwar Singh Reviewed-by: Daniel Vetter Acked-by: Dave Airlie Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190507162745.25600-5-ramalingam.c@intel.com --- Documentation/gpu/drm-kms-helpers.rst | 6 + drivers/gpu/drm/Makefile | 2 +- drivers/gpu/drm/drm_hdcp.c | 333 ++++++++++++++++++++++++++++++++++ drivers/gpu/drm/drm_internal.h | 4 + drivers/gpu/drm/drm_sysfs.c | 2 + include/drm/drm_hdcp.h | 24 +++ 6 files changed, 370 insertions(+), 1 deletion(-) create mode 100644 drivers/gpu/drm/drm_hdcp.c (limited to 'Documentation') diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index 14102ae035dc..0fe726a6ee67 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -181,6 +181,12 @@ Panel Helper Reference .. kernel-doc:: drivers/gpu/drm/drm_panel_orientation_quirks.c :export: +HDCP Helper Functions Reference +=============================== + +.. kernel-doc:: drivers/gpu/drm/drm_hdcp.c + :export: + Display Port Helper Functions Reference ======================================= diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 72f5036d9bfa..dd02e9dec810 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -17,7 +17,7 @@ drm-y := drm_auth.o drm_cache.o \ drm_plane.o drm_color_mgmt.o drm_print.o \ drm_dumb_buffers.o drm_mode_config.o drm_vblank.o \ drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \ - drm_atomic_uapi.o + drm_atomic_uapi.o drm_hdcp.o drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o drm_context.o drm_dma.o drm_scatter.o drm_lock.o drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o diff --git a/drivers/gpu/drm/drm_hdcp.c b/drivers/gpu/drm/drm_hdcp.c new file mode 100644 index 000000000000..5e5409505c31 --- /dev/null +++ b/drivers/gpu/drm/drm_hdcp.c @@ -0,0 +1,333 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2019 Intel Corporation. + * + * Authors: + * Ramalingam C + */ + +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +struct hdcp_srm { + u32 revoked_ksv_cnt; + u8 *revoked_ksv_list; + + /* Mutex to protect above struct member */ + struct mutex mutex; +} *srm_data; + +static inline void drm_hdcp_print_ksv(const u8 *ksv) +{ + DRM_DEBUG("\t%#02x, %#02x, %#02x, %#02x, %#02x\n", + ksv[0], ksv[1], ksv[2], ksv[3], ksv[4]); +} + +static u32 drm_hdcp_get_revoked_ksv_count(const u8 *buf, u32 vrls_length) +{ + u32 parsed_bytes = 0, ksv_count = 0, vrl_ksv_cnt, vrl_sz; + + while (parsed_bytes < vrls_length) { + vrl_ksv_cnt = *buf; + ksv_count += vrl_ksv_cnt; + + vrl_sz = (vrl_ksv_cnt * DRM_HDCP_KSV_LEN) + 1; + buf += vrl_sz; + parsed_bytes += vrl_sz; + } + + /* + * When vrls are not valid, ksvs are not considered. + * Hence SRM will be discarded. + */ + if (parsed_bytes != vrls_length) + ksv_count = 0; + + return ksv_count; +} + +static u32 drm_hdcp_get_revoked_ksvs(const u8 *buf, u8 *revoked_ksv_list, + u32 vrls_length) +{ + u32 parsed_bytes = 0, ksv_count = 0; + u32 vrl_ksv_cnt, vrl_ksv_sz, vrl_idx = 0; + + do { + vrl_ksv_cnt = *buf; + vrl_ksv_sz = vrl_ksv_cnt * DRM_HDCP_KSV_LEN; + + buf++; + + DRM_DEBUG("vrl: %d, Revoked KSVs: %d\n", vrl_idx++, + vrl_ksv_cnt); + memcpy(revoked_ksv_list, buf, vrl_ksv_sz); + + ksv_count += vrl_ksv_cnt; + revoked_ksv_list += vrl_ksv_sz; + buf += vrl_ksv_sz; + + parsed_bytes += (vrl_ksv_sz + 1); + } while (parsed_bytes < vrls_length); + + return ksv_count; +} + +static inline u32 get_vrl_length(const u8 *buf) +{ + return drm_hdcp_be24_to_cpu(buf); +} + +static int drm_hdcp_parse_hdcp1_srm(const u8 *buf, size_t count) +{ + struct hdcp_srm_header *header; + u32 vrl_length, ksv_count; + + if (count < (sizeof(struct hdcp_srm_header) + + DRM_HDCP_1_4_VRL_LENGTH_SIZE + DRM_HDCP_1_4_DCP_SIG_SIZE)) { + DRM_ERROR("Invalid blob length\n"); + return -EINVAL; + } + + header = (struct hdcp_srm_header *)buf; + DRM_DEBUG("SRM ID: 0x%x, SRM Ver: 0x%x, SRM Gen No: 0x%x\n", + header->srm_id, + be16_to_cpu(header->srm_version), header->srm_gen_no); + + WARN_ON(header->reserved); + + buf = buf + sizeof(*header); + vrl_length = get_vrl_length(buf); + if (count < (sizeof(struct hdcp_srm_header) + vrl_length) || + vrl_length < (DRM_HDCP_1_4_VRL_LENGTH_SIZE + + DRM_HDCP_1_4_DCP_SIG_SIZE)) { + DRM_ERROR("Invalid blob length or vrl length\n"); + return -EINVAL; + } + + /* Length of the all vrls combined */ + vrl_length -= (DRM_HDCP_1_4_VRL_LENGTH_SIZE + + DRM_HDCP_1_4_DCP_SIG_SIZE); + + if (!vrl_length) { + DRM_ERROR("No vrl found\n"); + return -EINVAL; + } + + buf += DRM_HDCP_1_4_VRL_LENGTH_SIZE; + ksv_count = drm_hdcp_get_revoked_ksv_count(buf, vrl_length); + if (!ksv_count) { + DRM_DEBUG("Revoked KSV count is 0\n"); + return count; + } + + kfree(srm_data->revoked_ksv_list); + srm_data->revoked_ksv_list = kcalloc(ksv_count, DRM_HDCP_KSV_LEN, + GFP_KERNEL); + if (!srm_data->revoked_ksv_list) { + DRM_ERROR("Out of Memory\n"); + return -ENOMEM; + } + + if (drm_hdcp_get_revoked_ksvs(buf, srm_data->revoked_ksv_list, + vrl_length) != ksv_count) { + srm_data->revoked_ksv_cnt = 0; + kfree(srm_data->revoked_ksv_list); + return -EINVAL; + } + + srm_data->revoked_ksv_cnt = ksv_count; + return count; +} + +static int drm_hdcp_parse_hdcp2_srm(const u8 *buf, size_t count) +{ + struct hdcp_srm_header *header; + u32 vrl_length, ksv_count, ksv_sz; + + if (count < (sizeof(struct hdcp_srm_header) + + DRM_HDCP_2_VRL_LENGTH_SIZE + DRM_HDCP_2_DCP_SIG_SIZE)) { + DRM_ERROR("Invalid blob length\n"); + return -EINVAL; + } + + header = (struct hdcp_srm_header *)buf; + DRM_DEBUG("SRM ID: 0x%x, SRM Ver: 0x%x, SRM Gen No: 0x%x\n", + header->srm_id & DRM_HDCP_SRM_ID_MASK, + be16_to_cpu(header->srm_version), header->srm_gen_no); + + if (header->reserved) + return -EINVAL; + + buf = buf + sizeof(*header); + vrl_length = get_vrl_length(buf); + + if (count < (sizeof(struct hdcp_srm_header) + vrl_length) || + vrl_length < (DRM_HDCP_2_VRL_LENGTH_SIZE + + DRM_HDCP_2_DCP_SIG_SIZE)) { + DRM_ERROR("Invalid blob length or vrl length\n"); + return -EINVAL; + } + + /* Length of the all vrls combined */ + vrl_length -= (DRM_HDCP_2_VRL_LENGTH_SIZE + + DRM_HDCP_2_DCP_SIG_SIZE); + + if (!vrl_length) { + DRM_ERROR("No vrl found\n"); + return -EINVAL; + } + + buf += DRM_HDCP_2_VRL_LENGTH_SIZE; + ksv_count = (*buf << 2) | DRM_HDCP_2_KSV_COUNT_2_LSBITS(*(buf + 1)); + if (!ksv_count) { + DRM_DEBUG("Revoked KSV count is 0\n"); + return count; + } + + kfree(srm_data->revoked_ksv_list); + srm_data->revoked_ksv_list = kcalloc(ksv_count, DRM_HDCP_KSV_LEN, + GFP_KERNEL); + if (!srm_data->revoked_ksv_list) { + DRM_ERROR("Out of Memory\n"); + return -ENOMEM; + } + + ksv_sz = ksv_count * DRM_HDCP_KSV_LEN; + buf += DRM_HDCP_2_NO_OF_DEV_PLUS_RESERVED_SZ; + + DRM_DEBUG("Revoked KSVs: %d\n", ksv_count); + memcpy(srm_data->revoked_ksv_list, buf, ksv_sz); + + srm_data->revoked_ksv_cnt = ksv_count; + return count; +} + +static inline bool is_srm_version_hdcp1(const u8 *buf) +{ + return *buf == (u8)(DRM_HDCP_1_4_SRM_ID << 4); +} + +static inline bool is_srm_version_hdcp2(const u8 *buf) +{ + return *buf == (u8)(DRM_HDCP_2_SRM_ID << 4 | DRM_HDCP_2_INDICATOR); +} + +static void drm_hdcp_srm_update(const u8 *buf, size_t count) +{ + if (count < sizeof(struct hdcp_srm_header)) + return; + + if (is_srm_version_hdcp1(buf)) + drm_hdcp_parse_hdcp1_srm(buf, count); + else if (is_srm_version_hdcp2(buf)) + drm_hdcp_parse_hdcp2_srm(buf, count); +} + +void drm_hdcp_request_srm(struct drm_device *drm_dev) +{ + char fw_name[36] = "display_hdcp_srm.bin"; + const struct firmware *fw; + + int ret; + + ret = request_firmware_direct(&fw, (const char *)fw_name, + drm_dev->dev); + if (ret < 0) + goto exit; + + if (fw->size && fw->data) + drm_hdcp_srm_update(fw->data, fw->size); + +exit: + release_firmware(fw); +} + +/** + * drm_hdcp_check_ksvs_revoked - Check the revoked status of the IDs + * + * @drm_dev: drm_device for which HDCP revocation check is requested + * @ksvs: List of KSVs (HDCP receiver IDs) + * @ksv_count: KSV count passed in through @ksvs + * + * This function reads the HDCP System renewability Message(SRM Table) + * from userspace as a firmware and parses it for the revoked HDCP + * KSVs(Receiver IDs) detected by DCP LLC. Once the revoked KSVs are known, + * revoked state of the KSVs in the list passed in by display drivers are + * decided and response is sent. + * + * SRM should be presented in the name of "display_hdcp_srm.bin". + * + * Returns: + * TRUE on any of the KSV is revoked, else FALSE. + */ +bool drm_hdcp_check_ksvs_revoked(struct drm_device *drm_dev, u8 *ksvs, + u32 ksv_count) +{ + u32 rev_ksv_cnt, cnt, i, j; + u8 *rev_ksv_list; + + if (!srm_data) + return false; + + mutex_lock(&srm_data->mutex); + drm_hdcp_request_srm(drm_dev); + + rev_ksv_cnt = srm_data->revoked_ksv_cnt; + rev_ksv_list = srm_data->revoked_ksv_list; + + /* If the Revoked ksv list is empty */ + if (!rev_ksv_cnt || !rev_ksv_list) { + mutex_unlock(&srm_data->mutex); + return false; + } + + for (cnt = 0; cnt < ksv_count; cnt++) { + rev_ksv_list = srm_data->revoked_ksv_list; + for (i = 0; i < rev_ksv_cnt; i++) { + for (j = 0; j < DRM_HDCP_KSV_LEN; j++) + if (ksvs[j] != rev_ksv_list[j]) { + break; + } else if (j == (DRM_HDCP_KSV_LEN - 1)) { + DRM_DEBUG("Revoked KSV is "); + drm_hdcp_print_ksv(ksvs); + mutex_unlock(&srm_data->mutex); + return true; + } + /* Move the offset to next KSV in the revoked list */ + rev_ksv_list += DRM_HDCP_KSV_LEN; + } + + /* Iterate to next ksv_offset */ + ksvs += DRM_HDCP_KSV_LEN; + } + mutex_unlock(&srm_data->mutex); + return false; +} +EXPORT_SYMBOL_GPL(drm_hdcp_check_ksvs_revoked); + +int drm_setup_hdcp_srm(struct class *drm_class) +{ + srm_data = kzalloc(sizeof(*srm_data), GFP_KERNEL); + if (!srm_data) + return -ENOMEM; + mutex_init(&srm_data->mutex); + + return 0; +} + +void drm_teardown_hdcp_srm(struct class *drm_class) +{ + if (srm_data) { + kfree(srm_data->revoked_ksv_list); + kfree(srm_data); + } +} diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h index e19ac7ca602d..476a422414f6 100644 --- a/drivers/gpu/drm/drm_internal.h +++ b/drivers/gpu/drm/drm_internal.h @@ -201,3 +201,7 @@ int drm_syncobj_query_ioctl(struct drm_device *dev, void *data, void drm_framebuffer_print_info(struct drm_printer *p, unsigned int indent, const struct drm_framebuffer *fb); int drm_framebuffer_debugfs_init(struct drm_minor *minor); + +/* drm_hdcp.c */ +int drm_setup_hdcp_srm(struct class *drm_class); +void drm_teardown_hdcp_srm(struct class *drm_class); diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c index ecb7b33002bb..18b1ac442997 100644 --- a/drivers/gpu/drm/drm_sysfs.c +++ b/drivers/gpu/drm/drm_sysfs.c @@ -78,6 +78,7 @@ int drm_sysfs_init(void) } drm_class->devnode = drm_devnode; + drm_setup_hdcp_srm(drm_class); return 0; } @@ -90,6 +91,7 @@ void drm_sysfs_destroy(void) { if (IS_ERR_OR_NULL(drm_class)) return; + drm_teardown_hdcp_srm(drm_class); class_remove_file(drm_class, &class_attr_version.attr); class_destroy(drm_class); drm_class = NULL; diff --git a/include/drm/drm_hdcp.h b/include/drm/drm_hdcp.h index 1cc66df05a43..2f0335d0a50f 100644 --- a/include/drm/drm_hdcp.h +++ b/include/drm/drm_hdcp.h @@ -265,4 +265,28 @@ void drm_hdcp_cpu_to_be24(u8 seq_num[HDCP_2_2_SEQ_NUM_LEN], u32 val) seq_num[2] = val; } +#define DRM_HDCP_SRM_GEN1_MAX_BYTES (5 * 1024) +#define DRM_HDCP_1_4_SRM_ID 0x8 +#define DRM_HDCP_SRM_ID_MASK (0xF << 4) +#define DRM_HDCP_1_4_VRL_LENGTH_SIZE 3 +#define DRM_HDCP_1_4_DCP_SIG_SIZE 40 +#define DRM_HDCP_2_SRM_ID 0x9 +#define DRM_HDCP_2_INDICATOR 0x1 +#define DRM_HDCP_2_INDICATOR_MASK 0xF +#define DRM_HDCP_2_VRL_LENGTH_SIZE 3 +#define DRM_HDCP_2_DCP_SIG_SIZE 384 +#define DRM_HDCP_2_NO_OF_DEV_PLUS_RESERVED_SZ 4 +#define DRM_HDCP_2_KSV_COUNT_2_LSBITS(byte) (((byte) & 0xC) >> 6) + +struct hdcp_srm_header { + u8 srm_id; + u8 reserved; + __be16 srm_version; + u8 srm_gen_no; +} __packed; + +struct drm_device; + +bool drm_hdcp_check_ksvs_revoked(struct drm_device *dev, + u8 *ksvs, u32 ksv_count); #endif -- cgit v1.2.3-59-g8ed1b From 977bfde5d4cbb9d2eb1969eb2eb671cdb9b9fcbf Mon Sep 17 00:00:00 2001 From: Eric Jeong Date: Thu, 18 Apr 2019 15:09:44 +0900 Subject: dt-bindings: regulator: add document bindings for slg51000 Add device tree binding information for slg51000 regulator driver. Example bindings for SLG51000 are added. Signed-off-by: Eric Jeong Signed-off-by: Mark Brown --- .../devicetree/bindings/regulator/slg51000.txt | 88 ++++++++++++++++++++++ 1 file changed, 88 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/slg51000.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/slg51000.txt b/Documentation/devicetree/bindings/regulator/slg51000.txt new file mode 100644 index 000000000000..aa0733e49b90 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/slg51000.txt @@ -0,0 +1,88 @@ +* Dialog Semiconductor SLG51000 Voltage Regulator + +Required properties: +- compatible : Should be "dlg,slg51000" for SLG51000 +- reg : Specifies the I2C slave address. +- xxx-supply: Input voltage supply regulator for ldo3 to ldo7. + These entries are required if regulators are enabled for a device. + An absence of these properties can cause the regulator registration to fail. + If some of input supply is powered through battery or always-on supply then + also it is required to have these parameters with proper node handle of always + on power supply. + vin3-supply: Input supply for ldo3 + vin4-supply: Input supply for ldo4 + vin5-supply: Input supply for ldo5 + vin6-supply: Input supply for ldo6 + vin7-supply: Input supply for ldo7 + +Optional properties: +- interrupt-parent : Specifies the reference to the interrupt controller. +- interrupts : IRQ line information. +- dlg,cs-gpios : Specify a valid GPIO for chip select + +Sub-nodes: +- regulators : This node defines the settings for the regulators. + The content of the sub-node is defined by the standard binding + for regulators; see regulator.txt. + + The SLG51000 regulators are bound using their names listed below: + ldo1 + ldo2 + ldo3 + ldo4 + ldo5 + ldo6 + ldo7 + +Optional properties for regulators: +- enable-gpios : Specify a valid GPIO for platform control of the regulator. + +Example: + pmic: slg51000@75 { + compatible = "dlg,slg51000"; + reg = <0x75>; + + regulators { + ldo1 { + regulator-name = "ldo1"; + regulator-min-microvolt = <2400000>; + regulator-max-microvolt = <3300000>; + }; + + ldo2 { + regulator-name = "ldo2"; + regulator-min-microvolt = <2400000>; + regulator-max-microvolt = <3300000>; + }; + + ldo3 { + regulator-name = "ldo3"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <3750000>; + }; + + ldo4 { + regulator-name = "ldo4"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <3750000>; + }; + + ldo5 { + regulator-name = "ldo5"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <1200000>; + }; + + ldo6 { + regulator-name = "ldo6"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <1200000>; + }; + + ldo7 { + regulator-name = "ldo7"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <3750000>; + }; + }; + }; -- cgit v1.2.3-59-g8ed1b From 03a9606e7feef902979bbc0601d6d93e764f251d Mon Sep 17 00:00:00 2001 From: Noralf Trønnes Date: Mon, 6 May 2019 20:01:30 +0200 Subject: drm/fb-helper: Avoid race with DRM userspace MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit drm_fb_helper_is_bound() is used to check if DRM userspace is in control. This is done by looking at the fb on the primary plane. By the time fb-helper gets around to committing, it's possible that the facts have changed. Avoid this race by holding the drm_device->master_mutex lock while committing. When DRM userspace does its first open, it will now wait until fb-helper is done. The helper will stay away if there's a master. Two igt tests fail with the new 'bail out if master' rule. Work around this by relaxing this rule for drm_fb_helper_restore_fbdev_mode_unlocked() until the tests have been fixed. Add todo entry for this. Locking rule: Always take the fb-helper lock first. v5: drm_fb_helper_restore_fbdev_mode_unlocked(): Use restore_fbdev_mode_force() v2: - Remove drm_fb_helper_is_bound() (Daniel Vetter) - No need to check fb_helper->dev->master in drm_fb_helper_single_fb_probe(), restore_fbdev_mode() has the check. Suggested-by: Daniel Vetter Signed-off-by: Noralf Trønnes Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190506180139.6913-3-noralf@tronnes.org --- Documentation/gpu/todo.rst | 8 ++++ drivers/gpu/drm/drm_auth.c | 20 ++++++++ drivers/gpu/drm/drm_fb_helper.c | 102 ++++++++++++++++++++++------------------ drivers/gpu/drm/drm_internal.h | 2 + 4 files changed, 86 insertions(+), 46 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 06ccff9165d5..66f05f4e469f 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -281,6 +281,14 @@ it to use drm_mode_hsync() instead. Contact: Sean Paul +drm_fb_helper tasks +------------------- + +- drm_fb_helper_restore_fbdev_mode_unlocked() should call restore_fbdev_mode() + not the _force variant so it can bail out if there is a master. But first + these igt tests need to be fixed: kms_fbcon_fbt@psr and + kms_fbcon_fbt@psr-suspend. + Core refactorings ================= diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c index 22c7a104b802..bf98402f3210 100644 --- a/drivers/gpu/drm/drm_auth.c +++ b/drivers/gpu/drm/drm_auth.c @@ -351,3 +351,23 @@ void drm_master_put(struct drm_master **master) *master = NULL; } EXPORT_SYMBOL(drm_master_put); + +/* Used by drm_client and drm_fb_helper */ +bool drm_master_internal_acquire(struct drm_device *dev) +{ + mutex_lock(&dev->master_mutex); + if (dev->master) { + mutex_unlock(&dev->master_mutex); + return false; + } + + return true; +} +EXPORT_SYMBOL(drm_master_internal_acquire); + +/* Used by drm_client and drm_fb_helper */ +void drm_master_internal_release(struct drm_device *dev) +{ + mutex_unlock(&dev->master_mutex); +} +EXPORT_SYMBOL(drm_master_internal_release); diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 498f95c3e81d..c521e7490380 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -44,6 +44,7 @@ #include "drm_crtc_internal.h" #include "drm_crtc_helper_internal.h" +#include "drm_internal.h" static bool drm_fbdev_emulation = true; module_param_named(fbdev_emulation, drm_fbdev_emulation, bool, 0600); @@ -509,7 +510,7 @@ out: return ret; } -static int restore_fbdev_mode(struct drm_fb_helper *fb_helper) +static int restore_fbdev_mode_force(struct drm_fb_helper *fb_helper) { struct drm_device *dev = fb_helper->dev; @@ -519,6 +520,21 @@ static int restore_fbdev_mode(struct drm_fb_helper *fb_helper) return restore_fbdev_mode_legacy(fb_helper); } +static int restore_fbdev_mode(struct drm_fb_helper *fb_helper) +{ + struct drm_device *dev = fb_helper->dev; + int ret; + + if (!drm_master_internal_acquire(dev)) + return -EBUSY; + + ret = restore_fbdev_mode_force(fb_helper); + + drm_master_internal_release(dev); + + return ret; +} + /** * drm_fb_helper_restore_fbdev_mode_unlocked - restore fbdev configuration * @fb_helper: driver-allocated fbdev helper, can be NULL @@ -542,7 +558,17 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper *fb_helper) return 0; mutex_lock(&fb_helper->lock); - ret = restore_fbdev_mode(fb_helper); + /* + * TODO: + * We should bail out here if there is a master by dropping _force. + * Currently these igt tests fail if we do that: + * - kms_fbcon_fbt@psr + * - kms_fbcon_fbt@psr-suspend + * + * So first these tests need to be fixed so they drop master or don't + * have an fd open. + */ + ret = restore_fbdev_mode_force(fb_helper); do_delayed = fb_helper->delayed_hotplug; if (do_delayed) @@ -556,34 +582,6 @@ int drm_fb_helper_restore_fbdev_mode_unlocked(struct drm_fb_helper *fb_helper) } EXPORT_SYMBOL(drm_fb_helper_restore_fbdev_mode_unlocked); -static bool drm_fb_helper_is_bound(struct drm_fb_helper *fb_helper) -{ - struct drm_device *dev = fb_helper->dev; - struct drm_crtc *crtc; - int bound = 0, crtcs_bound = 0; - - /* - * Sometimes user space wants everything disabled, so don't steal the - * display if there's a master. - */ - if (READ_ONCE(dev->master)) - return false; - - drm_for_each_crtc(crtc, dev) { - drm_modeset_lock(&crtc->mutex, NULL); - if (crtc->primary->fb) - crtcs_bound++; - if (crtc->primary->fb == fb_helper->fb) - bound++; - drm_modeset_unlock(&crtc->mutex); - } - - if (bound < crtcs_bound) - return false; - - return true; -} - #ifdef CONFIG_MAGIC_SYSRQ /* * restore fbcon display for all kms driver's using this helper, used for sysrq @@ -604,7 +602,7 @@ static bool drm_fb_helper_force_kernel_mode(void) continue; mutex_lock(&helper->lock); - ret = restore_fbdev_mode(helper); + ret = restore_fbdev_mode_force(helper); if (ret) error = true; mutex_unlock(&helper->lock); @@ -663,20 +661,22 @@ static void dpms_legacy(struct drm_fb_helper *fb_helper, int dpms_mode) static void drm_fb_helper_dpms(struct fb_info *info, int dpms_mode) { struct drm_fb_helper *fb_helper = info->par; + struct drm_device *dev = fb_helper->dev; /* * For each CRTC in this fb, turn the connectors on/off. */ mutex_lock(&fb_helper->lock); - if (!drm_fb_helper_is_bound(fb_helper)) { - mutex_unlock(&fb_helper->lock); - return; - } + if (!drm_master_internal_acquire(dev)) + goto unlock; - if (drm_drv_uses_atomic_modeset(fb_helper->dev)) + if (drm_drv_uses_atomic_modeset(dev)) restore_fbdev_mode_atomic(fb_helper, dpms_mode == DRM_MODE_DPMS_ON); else dpms_legacy(fb_helper, dpms_mode); + + drm_master_internal_release(dev); +unlock: mutex_unlock(&fb_helper->lock); } @@ -1509,6 +1509,7 @@ backoff: int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info) { struct drm_fb_helper *fb_helper = info->par; + struct drm_device *dev = fb_helper->dev; int ret; if (oops_in_progress) @@ -1516,9 +1517,9 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info) mutex_lock(&fb_helper->lock); - if (!drm_fb_helper_is_bound(fb_helper)) { + if (!drm_master_internal_acquire(dev)) { ret = -EBUSY; - goto out; + goto unlock; } if (info->fix.visual == FB_VISUAL_TRUECOLOR) @@ -1528,7 +1529,8 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct fb_info *info) else ret = setcmap_legacy(cmap, info); -out: + drm_master_internal_release(dev); +unlock: mutex_unlock(&fb_helper->lock); return ret; @@ -1548,12 +1550,13 @@ int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned long arg) { struct drm_fb_helper *fb_helper = info->par; + struct drm_device *dev = fb_helper->dev; struct drm_mode_set *mode_set; struct drm_crtc *crtc; int ret = 0; mutex_lock(&fb_helper->lock); - if (!drm_fb_helper_is_bound(fb_helper)) { + if (!drm_master_internal_acquire(dev)) { ret = -EBUSY; goto unlock; } @@ -1591,11 +1594,12 @@ int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, } ret = 0; - goto unlock; + break; default: ret = -ENOTTY; } + drm_master_internal_release(dev); unlock: mutex_unlock(&fb_helper->lock); return ret; @@ -1847,15 +1851,18 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo *var, return -EBUSY; mutex_lock(&fb_helper->lock); - if (!drm_fb_helper_is_bound(fb_helper)) { - mutex_unlock(&fb_helper->lock); - return -EBUSY; + if (!drm_master_internal_acquire(dev)) { + ret = -EBUSY; + goto unlock; } if (drm_drv_uses_atomic_modeset(dev)) ret = pan_display_atomic(var, info); else ret = pan_display_legacy(var, info); + + drm_master_internal_release(dev); +unlock: mutex_unlock(&fb_helper->lock); return ret; @@ -2014,7 +2021,7 @@ static int drm_fb_helper_single_fb_probe(struct drm_fb_helper *fb_helper, DRM_INFO("Cannot find any crtc or sizes\n"); /* First time: disable all crtc's.. */ - if (!fb_helper->deferred_setup && !READ_ONCE(fb_helper->dev->master)) + if (!fb_helper->deferred_setup) restore_fbdev_mode(fb_helper); return -EAGAIN; } @@ -3029,6 +3036,7 @@ EXPORT_SYMBOL(drm_fb_helper_initial_config); */ int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper) { + struct drm_device *dev = fb_helper->dev; int err = 0; if (!drm_fbdev_emulation || !fb_helper) @@ -3041,12 +3049,14 @@ int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper) return err; } - if (!fb_helper->fb || !drm_fb_helper_is_bound(fb_helper)) { + if (!fb_helper->fb || !drm_master_internal_acquire(dev)) { fb_helper->delayed_hotplug = true; mutex_unlock(&fb_helper->lock); return err; } + drm_master_internal_release(dev); + DRM_DEBUG_KMS("\n"); drm_setup_crtcs(fb_helper, fb_helper->fb->width, fb_helper->fb->height); diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h index e19ac7ca602d..e6281d9f9c87 100644 --- a/drivers/gpu/drm/drm_internal.h +++ b/drivers/gpu/drm/drm_internal.h @@ -93,6 +93,8 @@ int drm_dropmaster_ioctl(struct drm_device *dev, void *data, struct drm_file *file_priv); int drm_master_open(struct drm_file *file_priv); void drm_master_release(struct drm_file *file_priv); +bool drm_master_internal_acquire(struct drm_device *dev); +void drm_master_internal_release(struct drm_device *dev); /* drm_sysfs.c */ extern struct class *drm_class; -- cgit v1.2.3-59-g8ed1b From 85438a8ddf031f416758ecf8c080ff92075acb01 Mon Sep 17 00:00:00 2001 From: Thomas Zimmermann Date: Wed, 8 May 2019 10:26:11 +0200 Subject: drm: Add |struct drm_gem_vram_object| and helpers The type |struct drm_gem_vram_object| implements a GEM object for simple framebuffer devices with dedicated video memory. The BO is either located in VRAM or system memory. The implementation has been created from the respective code in ast, bochs and mgag200. These drivers copy their implementation from each other; except for the names of several data types. The helpers are currently build with TTM, but this is considered an implementation detail and may change in future updates. v5: * do WARN_ON_ONCE for pin-count mismatches * allocate only 2 entries in placements array v4: * cleanups from checkpatch.pl * removed several fixed-size types from interfaces * DRM_VRAM_HELPER now selects DRM_TTM * remove separate config option for GEM VRAM v2: * rename to |struct drm_gem_vram_object| * move drm_is_gem_ttm() to a later patch in the series * add drm_gem_vram_kmap_at() * return is_iomem from kmap functions * redefine TTM placement flags for public interface * documentation fixes Signed-off-by: Thomas Zimmermann Link: http://patchwork.freedesktop.org/patch/msgid/20190508082630.15116-2-tzimmermann@suse.de Signed-off-by: Gerd Hoffmann --- Documentation/gpu/drm-mm.rst | 15 ++ drivers/gpu/drm/Kconfig | 7 + drivers/gpu/drm/Makefile | 4 + drivers/gpu/drm/drm_gem_vram_helper.c | 412 +++++++++++++++++++++++++++++++ drivers/gpu/drm/drm_vram_helper_common.c | 6 + include/drm/drm_gem_vram_helper.h | 92 +++++++ 6 files changed, 536 insertions(+) create mode 100644 drivers/gpu/drm/drm_gem_vram_helper.c create mode 100644 drivers/gpu/drm/drm_vram_helper_common.c create mode 100644 include/drm/drm_gem_vram_helper.h (limited to 'Documentation') diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index 54a696d961a7..a3b685089512 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -380,6 +380,21 @@ GEM CMA Helper Functions Reference .. kernel-doc:: drivers/gpu/drm/drm_gem_cma_helper.c :export: +VRAM Helper Function Reference +============================== + +GEM VRAM Helper Functions Reference +----------------------------------- + +.. kernel-doc:: drivers/gpu/drm/drm_gem_vram_helper.c + :doc: overview + +.. kernel-doc:: include/drm/drm_gem_vram_helper.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/drm_gem_vram_helper.c + :export: + VMA Offset Manager ================== diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 2267e84d5cb4..13d7b321db0d 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -160,6 +160,13 @@ config DRM_TTM GPU memory types. Will be enabled automatically if a device driver uses it. +config DRM_VRAM_HELPER + tristate + depends on DRM + select DRM_TTM + help + Helpers for VRAM memory management + config DRM_GEM_CMA_HELPER bool depends on DRM diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 72f5036d9bfa..ed49b2480766 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -32,6 +32,10 @@ drm-$(CONFIG_AGP) += drm_agpsupport.o drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o +drm_vram_helper-y := drm_gem_vram_helper.o \ + drm_vram_helper_common.o +obj-$(CONFIG_DRM_VRAM_HELPER) += drm_vram_helper.o + drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_dsc.o drm_probe_helper.o \ drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \ drm_kms_helper_common.o drm_dp_dual_mode_helper.o \ diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c b/drivers/gpu/drm/drm_gem_vram_helper.c new file mode 100644 index 000000000000..761a546412f8 --- /dev/null +++ b/drivers/gpu/drm/drm_gem_vram_helper.c @@ -0,0 +1,412 @@ +// SPDX-License-Identifier: GPL-2.0-or-later + +#include +#include + +/** + * DOC: overview + * + * This library provides a GEM buffer object that is backed by video RAM + * (VRAM). It can be used for framebuffer devices with dedicated memory. + */ + +/* + * Buffer-objects helpers + */ + +static void drm_gem_vram_cleanup(struct drm_gem_vram_object *gbo) +{ + /* We got here via ttm_bo_put(), which means that the + * TTM buffer object in 'bo' has already been cleaned + * up; only release the GEM object. + */ + drm_gem_object_release(&gbo->gem); +} + +static void drm_gem_vram_destroy(struct drm_gem_vram_object *gbo) +{ + drm_gem_vram_cleanup(gbo); + kfree(gbo); +} + +static void ttm_buffer_object_destroy(struct ttm_buffer_object *bo) +{ + struct drm_gem_vram_object *gbo = drm_gem_vram_of_bo(bo); + + drm_gem_vram_destroy(gbo); +} + +static void drm_gem_vram_placement(struct drm_gem_vram_object *gbo, + unsigned long pl_flag) +{ + unsigned int i; + unsigned int c = 0; + + gbo->placement.placement = gbo->placements; + gbo->placement.busy_placement = gbo->placements; + + if (pl_flag & TTM_PL_FLAG_VRAM) + gbo->placements[c++].flags = TTM_PL_FLAG_WC | + TTM_PL_FLAG_UNCACHED | + TTM_PL_FLAG_VRAM; + + if (pl_flag & TTM_PL_FLAG_SYSTEM) + gbo->placements[c++].flags = TTM_PL_MASK_CACHING | + TTM_PL_FLAG_SYSTEM; + + if (!c) + gbo->placements[c++].flags = TTM_PL_MASK_CACHING | + TTM_PL_FLAG_SYSTEM; + + gbo->placement.num_placement = c; + gbo->placement.num_busy_placement = c; + + for (i = 0; i < c; ++i) { + gbo->placements[i].fpfn = 0; + gbo->placements[i].lpfn = 0; + } +} + +static int drm_gem_vram_init(struct drm_device *dev, + struct ttm_bo_device *bdev, + struct drm_gem_vram_object *gbo, + size_t size, unsigned long pg_align, + bool interruptible) +{ + int ret; + size_t acc_size; + + ret = drm_gem_object_init(dev, &gbo->gem, size); + if (ret) + return ret; + + acc_size = ttm_bo_dma_acc_size(bdev, size, sizeof(*gbo)); + + gbo->bo.bdev = bdev; + drm_gem_vram_placement(gbo, TTM_PL_FLAG_VRAM | TTM_PL_FLAG_SYSTEM); + + ret = ttm_bo_init(bdev, &gbo->bo, size, ttm_bo_type_device, + &gbo->placement, pg_align, interruptible, acc_size, + NULL, NULL, ttm_buffer_object_destroy); + if (ret) + goto err_drm_gem_object_release; + + return 0; + +err_drm_gem_object_release: + drm_gem_object_release(&gbo->gem); + return ret; +} + +/** + * drm_gem_vram_create() - Creates a VRAM-backed GEM object + * @dev: the DRM device + * @bdev: the TTM BO device backing the object + * @size: the buffer size in bytes + * @pg_align: the buffer's alignment in multiples of the page size + * @interruptible: sleep interruptible if waiting for memory + * + * Returns: + * A new instance of &struct drm_gem_vram_object on success, or + * an ERR_PTR()-encoded error code otherwise. + */ +struct drm_gem_vram_object *drm_gem_vram_create(struct drm_device *dev, + struct ttm_bo_device *bdev, + size_t size, + unsigned long pg_align, + bool interruptible) +{ + struct drm_gem_vram_object *gbo; + int ret; + + gbo = kzalloc(sizeof(*gbo), GFP_KERNEL); + if (!gbo) + return ERR_PTR(-ENOMEM); + + ret = drm_gem_vram_init(dev, bdev, gbo, size, pg_align, interruptible); + if (ret < 0) + goto err_kfree; + + return gbo; + +err_kfree: + kfree(gbo); + return ERR_PTR(ret); +} +EXPORT_SYMBOL(drm_gem_vram_create); + +/** + * drm_gem_vram_put() - Releases a reference to a VRAM-backed GEM object + * @gbo: the GEM VRAM object + * + * See ttm_bo_put() for more information. + */ +void drm_gem_vram_put(struct drm_gem_vram_object *gbo) +{ + ttm_bo_put(&gbo->bo); +} +EXPORT_SYMBOL(drm_gem_vram_put); + +/** + * drm_gem_vram_reserve() - Reserves a VRAM-backed GEM object + * @gbo: the GEM VRAM object + * @no_wait: don't wait for buffer object to become available + * + * See ttm_bo_reserve() for more information. + * + * Returns: + * 0 on success, or + * a negative error code otherwise + */ +int drm_gem_vram_reserve(struct drm_gem_vram_object *gbo, bool no_wait) +{ + return ttm_bo_reserve(&gbo->bo, true, no_wait, NULL); +} +EXPORT_SYMBOL(drm_gem_vram_reserve); + +/** + * drm_gem_vram_unreserve() - \ + Release a reservation acquired by drm_gem_vram_reserve() + * @gbo: the GEM VRAM object + * + * See ttm_bo_unreserve() for more information. + */ +void drm_gem_vram_unreserve(struct drm_gem_vram_object *gbo) +{ + ttm_bo_unreserve(&gbo->bo); +} +EXPORT_SYMBOL(drm_gem_vram_unreserve); + +/** + * drm_gem_vram_mmap_offset() - Returns a GEM VRAM object's mmap offset + * @gbo: the GEM VRAM object + * + * See drm_vma_node_offset_addr() for more information. + * + * Returns: + * The buffer object's offset for userspace mappings on success, or + * 0 if no offset is allocated. + */ +u64 drm_gem_vram_mmap_offset(struct drm_gem_vram_object *gbo) +{ + return drm_vma_node_offset_addr(&gbo->bo.vma_node); +} +EXPORT_SYMBOL(drm_gem_vram_mmap_offset); + +/** + * drm_gem_vram_offset() - \ + Returns a GEM VRAM object's offset in video memory + * @gbo: the GEM VRAM object + * + * This function returns the buffer object's offset in the device's video + * memory. The buffer object has to be pinned to %TTM_PL_VRAM. + * + * Returns: + * The buffer object's offset in video memory on success, or + * a negative errno code otherwise. + */ +s64 drm_gem_vram_offset(struct drm_gem_vram_object *gbo) +{ + if (WARN_ON_ONCE(!gbo->pin_count)) + return (s64)-ENODEV; + return gbo->bo.offset; +} +EXPORT_SYMBOL(drm_gem_vram_offset); + +/** + * drm_gem_vram_pin() - Pins a GEM VRAM object in a region. + * @gbo: the GEM VRAM object + * @pl_flag: a bitmask of possible memory regions + * + * Pinning a buffer object ensures that it is not evicted from + * a memory region. A pinned buffer object has to be unpinned before + * it can be pinned to another region. + * + * Returns: + * 0 on success, or + * a negative error code otherwise. + */ +int drm_gem_vram_pin(struct drm_gem_vram_object *gbo, unsigned long pl_flag) +{ + int i, ret; + struct ttm_operation_ctx ctx = { false, false }; + + if (gbo->pin_count) { + ++gbo->pin_count; + return 0; + } + + drm_gem_vram_placement(gbo, pl_flag); + for (i = 0; i < gbo->placement.num_placement; ++i) + gbo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT; + + ret = ttm_bo_validate(&gbo->bo, &gbo->placement, &ctx); + if (ret < 0) + return ret; + + gbo->pin_count = 1; + + return 0; +} +EXPORT_SYMBOL(drm_gem_vram_pin); + +/** + * drm_gem_vram_unpin() - Unpins a GEM VRAM object + * @gbo: the GEM VRAM object + * + * Returns: + * 0 on success, or + * a negative error code otherwise. + */ +int drm_gem_vram_unpin(struct drm_gem_vram_object *gbo) +{ + int i, ret; + struct ttm_operation_ctx ctx = { false, false }; + + if (WARN_ON_ONCE(!gbo->pin_count)) + return 0; + + --gbo->pin_count; + if (gbo->pin_count) + return 0; + + for (i = 0; i < gbo->placement.num_placement ; ++i) + gbo->placements[i].flags &= ~TTM_PL_FLAG_NO_EVICT; + + ret = ttm_bo_validate(&gbo->bo, &gbo->placement, &ctx); + if (ret < 0) + return ret; + + return 0; +} +EXPORT_SYMBOL(drm_gem_vram_unpin); + +/** + * drm_gem_vram_push_to_system() - \ + Unpins a GEM VRAM object and moves it to system memory + * @gbo: the GEM VRAM object + * + * This operation only works if the caller holds the final pin on the + * buffer object. + * + * Returns: + * 0 on success, or + * a negative error code otherwise. + */ +int drm_gem_vram_push_to_system(struct drm_gem_vram_object *gbo) +{ + int i, ret; + struct ttm_operation_ctx ctx = { false, false }; + + if (WARN_ON_ONCE(!gbo->pin_count)) + return 0; + + --gbo->pin_count; + if (gbo->pin_count) + return 0; + + if (gbo->kmap.virtual) + ttm_bo_kunmap(&gbo->kmap); + + drm_gem_vram_placement(gbo, TTM_PL_FLAG_SYSTEM); + for (i = 0; i < gbo->placement.num_placement ; ++i) + gbo->placements[i].flags |= TTM_PL_FLAG_NO_EVICT; + + ret = ttm_bo_validate(&gbo->bo, &gbo->placement, &ctx); + if (ret) + return ret; + + return 0; +} +EXPORT_SYMBOL(drm_gem_vram_push_to_system); + +/** + * drm_gem_vram_kmap_at() - Maps a GEM VRAM object into kernel address space + * @gbo: the GEM VRAM object + * @map: establish a mapping if necessary + * @is_iomem: returns true if the mapped memory is I/O memory, or false \ + otherwise; can be NULL + * @kmap: the mapping's kmap object + * + * This function maps the buffer object into the kernel's address space + * or returns the current mapping. If the parameter map is false, the + * function only queries the current mapping, but does not establish a + * new one. + * + * Returns: + * The buffers virtual address if mapped, or + * NULL if not mapped, or + * an ERR_PTR()-encoded error code otherwise. + */ +void *drm_gem_vram_kmap_at(struct drm_gem_vram_object *gbo, bool map, + bool *is_iomem, struct ttm_bo_kmap_obj *kmap) +{ + int ret; + + if (kmap->virtual || !map) + goto out; + + ret = ttm_bo_kmap(&gbo->bo, 0, gbo->bo.num_pages, kmap); + if (ret) + return ERR_PTR(ret); + +out: + if (!is_iomem) + return kmap->virtual; + if (!kmap->virtual) { + *is_iomem = false; + return NULL; + } + return ttm_kmap_obj_virtual(kmap, is_iomem); +} +EXPORT_SYMBOL(drm_gem_vram_kmap_at); + +/** + * drm_gem_vram_kmap() - Maps a GEM VRAM object into kernel address space + * @gbo: the GEM VRAM object + * @map: establish a mapping if necessary + * @is_iomem: returns true if the mapped memory is I/O memory, or false \ + otherwise; can be NULL + * + * This function maps the buffer object into the kernel's address space + * or returns the current mapping. If the parameter map is false, the + * function only queries the current mapping, but does not establish a + * new one. + * + * Returns: + * The buffers virtual address if mapped, or + * NULL if not mapped, or + * an ERR_PTR()-encoded error code otherwise. + */ +void *drm_gem_vram_kmap(struct drm_gem_vram_object *gbo, bool map, + bool *is_iomem) +{ + return drm_gem_vram_kmap_at(gbo, map, is_iomem, &gbo->kmap); +} +EXPORT_SYMBOL(drm_gem_vram_kmap); + +/** + * drm_gem_vram_kunmap_at() - Unmaps a GEM VRAM object + * @gbo: the GEM VRAM object + * @kmap: the mapping's kmap object + */ +void drm_gem_vram_kunmap_at(struct drm_gem_vram_object *gbo, + struct ttm_bo_kmap_obj *kmap) +{ + if (!kmap->virtual) + return; + + ttm_bo_kunmap(kmap); + kmap->virtual = NULL; +} +EXPORT_SYMBOL(drm_gem_vram_kunmap_at); + +/** + * drm_gem_vram_kunmap() - Unmaps a GEM VRAM object + * @gbo: the GEM VRAM object + */ +void drm_gem_vram_kunmap(struct drm_gem_vram_object *gbo) +{ + drm_gem_vram_kunmap_at(gbo, &gbo->kmap); +} +EXPORT_SYMBOL(drm_gem_vram_kunmap); diff --git a/drivers/gpu/drm/drm_vram_helper_common.c b/drivers/gpu/drm/drm_vram_helper_common.c new file mode 100644 index 000000000000..7c25daca18d0 --- /dev/null +++ b/drivers/gpu/drm/drm_vram_helper_common.c @@ -0,0 +1,6 @@ +// SPDX-License-Identifier: GPL-2.0-or-later + +#include + +MODULE_DESCRIPTION("DRM VRAM memory-management helpers"); +MODULE_LICENSE("GPL"); diff --git a/include/drm/drm_gem_vram_helper.h b/include/drm/drm_gem_vram_helper.h new file mode 100644 index 000000000000..5802dd694939 --- /dev/null +++ b/include/drm/drm_gem_vram_helper.h @@ -0,0 +1,92 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ + +#ifndef DRM_GEM_VRAM_HELPER_H +#define DRM_GEM_VRAM_HELPER_H + +#include +#include +#include +#include /* for container_of() */ + +struct filp; + +#define DRM_GEM_VRAM_PL_FLAG_VRAM TTM_PL_FLAG_VRAM +#define DRM_GEM_VRAM_PL_FLAG_SYSTEM TTM_PL_FLAG_SYSTEM + +/* + * Buffer-object helpers + */ + +/** + * struct drm_gem_vram_object - GEM object backed by VRAM + * @gem: GEM object + * @bo: TTM buffer object + * @kmap: Mapping information for @bo + * @placement: TTM placement information. Supported placements are \ + %TTM_PL_VRAM and %TTM_PL_SYSTEM + * @placements: TTM placement information. + * @pin_count: Pin counter + * + * The type struct drm_gem_vram_object represents a GEM object that is + * backed by VRAM. It can be used for simple framebuffer devices with + * dedicated memory. The buffer object can be evicted to system memory if + * video memory becomes scarce. + */ +struct drm_gem_vram_object { + struct drm_gem_object gem; + struct ttm_buffer_object bo; + struct ttm_bo_kmap_obj kmap; + + /* Supported placements are %TTM_PL_VRAM and %TTM_PL_SYSTEM */ + struct ttm_placement placement; + struct ttm_place placements[2]; + + int pin_count; +}; + +/** + * Returns the container of type &struct drm_gem_vram_object + * for field bo. + * @bo: the VRAM buffer object + * Returns: The containing GEM VRAM object + */ +static inline struct drm_gem_vram_object *drm_gem_vram_of_bo( + struct ttm_buffer_object *bo) +{ + return container_of(bo, struct drm_gem_vram_object, bo); +} + +/** + * Returns the container of type &struct drm_gem_vram_object + * for field gem. + * @gem: the GEM object + * Returns: The containing GEM VRAM object + */ +static inline struct drm_gem_vram_object *drm_gem_vram_of_gem( + struct drm_gem_object *gem) +{ + return container_of(gem, struct drm_gem_vram_object, gem); +} + +struct drm_gem_vram_object *drm_gem_vram_create(struct drm_device *dev, + struct ttm_bo_device *bdev, + size_t size, + unsigned long pg_align, + bool interruptible); +void drm_gem_vram_put(struct drm_gem_vram_object *gbo); +int drm_gem_vram_reserve(struct drm_gem_vram_object *gbo, bool no_wait); +void drm_gem_vram_unreserve(struct drm_gem_vram_object *gbo); +u64 drm_gem_vram_mmap_offset(struct drm_gem_vram_object *gbo); +s64 drm_gem_vram_offset(struct drm_gem_vram_object *gbo); +int drm_gem_vram_pin(struct drm_gem_vram_object *gbo, unsigned long pl_flag); +int drm_gem_vram_unpin(struct drm_gem_vram_object *gbo); +int drm_gem_vram_push_to_system(struct drm_gem_vram_object *gbo); +void *drm_gem_vram_kmap_at(struct drm_gem_vram_object *gbo, bool map, + bool *is_iomem, struct ttm_bo_kmap_obj *kmap); +void *drm_gem_vram_kmap(struct drm_gem_vram_object *gbo, bool map, + bool *is_iomem); +void drm_gem_vram_kunmap_at(struct drm_gem_vram_object *gbo, + struct ttm_bo_kmap_obj *kmap); +void drm_gem_vram_kunmap(struct drm_gem_vram_object *gbo); + +#endif -- cgit v1.2.3-59-g8ed1b From 96352eca5c7c36c3e0eb97a6d68fb170ce643ea5 Mon Sep 17 00:00:00 2001 From: Thomas Zimmermann Date: Wed, 8 May 2019 10:26:16 +0200 Subject: drm: Add VRAM MM, a simple memory manager for dedicated VRAM The VRAM MM memory manager is a helper library that manages dedicated video memory of simple framebuffer devices. It is supported to be used with struct drm_gem_vram_object, but does not depend on it. The implementation is based on the respective code from ast, bochs, and mgag200. These drivers share the exact same implementation except for type names. The helpers are currently build with TTM. This may change in future revisions. v4: * cleanups from checkpatch.pl v2: * renamed to struct drm_vram_mm * add drm_vram_mm_mmap() helper * documentation fixes Signed-off-by: Thomas Zimmermann Link: http://patchwork.freedesktop.org/patch/msgid/20190508082630.15116-7-tzimmermann@suse.de Signed-off-by: Gerd Hoffmann --- Documentation/gpu/drm-mm.rst | 13 ++- drivers/gpu/drm/Makefile | 3 +- drivers/gpu/drm/drm_vram_mm_helper.c | 210 +++++++++++++++++++++++++++++++++++ include/drm/drm_vram_mm_helper.h | 69 ++++++++++++ 4 files changed, 293 insertions(+), 2 deletions(-) create mode 100644 drivers/gpu/drm/drm_vram_mm_helper.c create mode 100644 include/drm/drm_vram_mm_helper.h (limited to 'Documentation') diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index a3b685089512..eba50afbda42 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -79,7 +79,6 @@ count for the TTM, which will call your initialization function. See the radeon_ttm.c file for an example of usage. - The Graphics Execution Manager (GEM) ==================================== @@ -395,6 +394,18 @@ GEM VRAM Helper Functions Reference .. kernel-doc:: drivers/gpu/drm/drm_gem_vram_helper.c :export: +VRAM MM Helper Functions Reference +---------------------------------- + +.. kernel-doc:: drivers/gpu/drm/drm_vram_mm_helper.c + :doc: overview + +.. kernel-doc:: include/drm/drm_vram_mm_helper.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/drm_vram_mm_helper.c + :export: + VMA Offset Manager ================== diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index ed49b2480766..4c3dc4268b65 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -33,7 +33,8 @@ drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o drm-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o drm_vram_helper-y := drm_gem_vram_helper.o \ - drm_vram_helper_common.o + drm_vram_helper_common.o \ + drm_vram_mm_helper.o obj-$(CONFIG_DRM_VRAM_HELPER) += drm_vram_helper.o drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_dsc.o drm_probe_helper.o \ diff --git a/drivers/gpu/drm/drm_vram_mm_helper.c b/drivers/gpu/drm/drm_vram_mm_helper.c new file mode 100644 index 000000000000..d17c5169b018 --- /dev/null +++ b/drivers/gpu/drm/drm_vram_mm_helper.c @@ -0,0 +1,210 @@ +// SPDX-License-Identifier: GPL-2.0-or-later + +#include +#include +#include + +/** + * DOC: overview + * + * The data structure &struct drm_vram_mm and its helpers implement a memory + * manager for simple framebuffer devices with dedicated video memory. Buffer + * objects are either placed in video RAM or evicted to system memory. These + * helper functions work well with &struct drm_gem_vram_object. + */ + +/* + * TTM TT + */ + +static void backend_func_destroy(struct ttm_tt *tt) +{ + ttm_tt_fini(tt); + kfree(tt); +} + +static struct ttm_backend_func backend_func = { + .destroy = backend_func_destroy +}; + +/* + * TTM BO device + */ + +static struct ttm_tt *bo_driver_ttm_tt_create(struct ttm_buffer_object *bo, + uint32_t page_flags) +{ + struct ttm_tt *tt; + int ret; + + tt = kzalloc(sizeof(*tt), GFP_KERNEL); + if (!tt) + return NULL; + + tt->func = &backend_func; + + ret = ttm_tt_init(tt, bo, page_flags); + if (ret < 0) + goto err_ttm_tt_init; + + return tt; + +err_ttm_tt_init: + kfree(tt); + return NULL; +} + +static int bo_driver_init_mem_type(struct ttm_bo_device *bdev, uint32_t type, + struct ttm_mem_type_manager *man) +{ + switch (type) { + case TTM_PL_SYSTEM: + man->flags = TTM_MEMTYPE_FLAG_MAPPABLE; + man->available_caching = TTM_PL_MASK_CACHING; + man->default_caching = TTM_PL_FLAG_CACHED; + break; + case TTM_PL_VRAM: + man->func = &ttm_bo_manager_func; + man->flags = TTM_MEMTYPE_FLAG_FIXED | + TTM_MEMTYPE_FLAG_MAPPABLE; + man->available_caching = TTM_PL_FLAG_UNCACHED | + TTM_PL_FLAG_WC; + man->default_caching = TTM_PL_FLAG_WC; + break; + default: + return -EINVAL; + } + return 0; +} + +static void bo_driver_evict_flags(struct ttm_buffer_object *bo, + struct ttm_placement *placement) +{ + struct drm_vram_mm *vmm = drm_vram_mm_of_bdev(bo->bdev); + + if (vmm->funcs && vmm->funcs->evict_flags) + vmm->funcs->evict_flags(bo, placement); +} + +static int bo_driver_verify_access(struct ttm_buffer_object *bo, + struct file *filp) +{ + struct drm_vram_mm *vmm = drm_vram_mm_of_bdev(bo->bdev); + + if (!vmm->funcs || !vmm->funcs->verify_access) + return 0; + return vmm->funcs->verify_access(bo, filp); +} + +static int bo_driver_io_mem_reserve(struct ttm_bo_device *bdev, + struct ttm_mem_reg *mem) +{ + struct ttm_mem_type_manager *man = bdev->man + mem->mem_type; + struct drm_vram_mm *vmm = drm_vram_mm_of_bdev(bdev); + + if (!(man->flags & TTM_MEMTYPE_FLAG_MAPPABLE)) + return -EINVAL; + + mem->bus.addr = NULL; + mem->bus.size = mem->num_pages << PAGE_SHIFT; + + switch (mem->mem_type) { + case TTM_PL_SYSTEM: /* nothing to do */ + mem->bus.offset = 0; + mem->bus.base = 0; + mem->bus.is_iomem = false; + break; + case TTM_PL_VRAM: + mem->bus.offset = mem->start << PAGE_SHIFT; + mem->bus.base = vmm->vram_base; + mem->bus.is_iomem = true; + break; + default: + return -EINVAL; + } + + return 0; +} + +static void bo_driver_io_mem_free(struct ttm_bo_device *bdev, + struct ttm_mem_reg *mem) +{ } + +static struct ttm_bo_driver bo_driver = { + .ttm_tt_create = bo_driver_ttm_tt_create, + .ttm_tt_populate = ttm_pool_populate, + .ttm_tt_unpopulate = ttm_pool_unpopulate, + .init_mem_type = bo_driver_init_mem_type, + .eviction_valuable = ttm_bo_eviction_valuable, + .evict_flags = bo_driver_evict_flags, + .verify_access = bo_driver_verify_access, + .io_mem_reserve = bo_driver_io_mem_reserve, + .io_mem_free = bo_driver_io_mem_free, +}; + +/* + * struct drm_vram_mm + */ + +/** + * drm_vram_mm_init() - Initialize an instance of VRAM MM. + * @vmm: the VRAM MM instance to initialize + * @dev: the DRM device + * @vram_base: the base address of the video memory + * @vram_size: the size of the video memory in bytes + * @funcs: callback functions for buffer objects + * + * Returns: + * 0 on success, or + * a negative error code otherwise. + */ +int drm_vram_mm_init(struct drm_vram_mm *vmm, struct drm_device *dev, + uint64_t vram_base, size_t vram_size, + const struct drm_vram_mm_funcs *funcs) +{ + int ret; + + vmm->vram_base = vram_base; + vmm->vram_size = vram_size; + vmm->funcs = funcs; + + ret = ttm_bo_device_init(&vmm->bdev, &bo_driver, + dev->anon_inode->i_mapping, + true); + if (ret) + return ret; + + ret = ttm_bo_init_mm(&vmm->bdev, TTM_PL_VRAM, vram_size >> PAGE_SHIFT); + if (ret) + return ret; + + return 0; +} +EXPORT_SYMBOL(drm_vram_mm_init); + +/** + * drm_vram_mm_cleanup() - Cleans up an initialized instance of VRAM MM. + * @vmm: the VRAM MM instance to clean up + */ +void drm_vram_mm_cleanup(struct drm_vram_mm *vmm) +{ + ttm_bo_device_release(&vmm->bdev); +} +EXPORT_SYMBOL(drm_vram_mm_cleanup); + +/** + * drm_vram_mm_mmap() - Helper for implementing &struct file_operations.mmap() + * @filp: the mapping's file structure + * @vma: the mapping's memory area + * @vmm: the VRAM MM instance + * + * Returns: + * 0 on success, or + * a negative error code otherwise. + */ +int drm_vram_mm_mmap(struct file *filp, struct vm_area_struct *vma, + struct drm_vram_mm *vmm) +{ + return ttm_bo_mmap(filp, vma, &vmm->bdev); +} +EXPORT_SYMBOL(drm_vram_mm_mmap); diff --git a/include/drm/drm_vram_mm_helper.h b/include/drm/drm_vram_mm_helper.h new file mode 100644 index 000000000000..5d45c6447fa4 --- /dev/null +++ b/include/drm/drm_vram_mm_helper.h @@ -0,0 +1,69 @@ +/* SPDX-License-Identifier: GPL-2.0-or-later */ + +#ifndef DRM_VRAM_MM_HELPER_H +#define DRM_VRAM_MM_HELPER_H + +#include + +struct drm_device; + +/** + * struct drm_vram_mm_funcs - Callback functions for &struct drm_vram_mm + * @evict_flags: Provides an implementation for struct \ + &ttm_bo_driver.evict_flags + * @verify_access: Provides an implementation for \ + struct &ttm_bo_driver.verify_access + * + * These callback function integrate VRAM MM with TTM buffer objects. New + * functions can be added if necessary. + */ +struct drm_vram_mm_funcs { + void (*evict_flags)(struct ttm_buffer_object *bo, + struct ttm_placement *placement); + int (*verify_access)(struct ttm_buffer_object *bo, struct file *filp); +}; + +/** + * struct drm_vram_mm - An instance of VRAM MM + * @vram_base: Base address of the managed video memory + * @vram_size: Size of the managed video memory in bytes + * @bdev: The TTM BO device. + * @funcs: TTM BO functions + * + * The fields &struct drm_vram_mm.vram_base and + * &struct drm_vram_mm.vrm_size are managed by VRAM MM, but are + * available for public read access. Use the field + * &struct drm_vram_mm.bdev to access the TTM BO device. + */ +struct drm_vram_mm { + uint64_t vram_base; + size_t vram_size; + + struct ttm_bo_device bdev; + + const struct drm_vram_mm_funcs *funcs; +}; + +/** + * drm_vram_mm_of_bdev() - \ + Returns the container of type &struct ttm_bo_device for field bdev. + * @bdev: the TTM BO device + * + * Returns: + * The containing instance of &struct drm_vram_mm + */ +static inline struct drm_vram_mm *drm_vram_mm_of_bdev( + struct ttm_bo_device *bdev) +{ + return container_of(bdev, struct drm_vram_mm, bdev); +} + +int drm_vram_mm_init(struct drm_vram_mm *vmm, struct drm_device *dev, + uint64_t vram_base, size_t vram_size, + const struct drm_vram_mm_funcs *funcs); +void drm_vram_mm_cleanup(struct drm_vram_mm *vmm); + +int drm_vram_mm_mmap(struct file *filp, struct vm_area_struct *vma, + struct drm_vram_mm *vmm); + +#endif -- cgit v1.2.3-59-g8ed1b From 59f5989ad42b6edd089b47895986ef15259822dc Mon Sep 17 00:00:00 2001 From: Thomas Zimmermann Date: Wed, 8 May 2019 10:26:18 +0200 Subject: drm: Integrate VRAM MM into struct drm_device There's now a pointer to struct drm_vram_mm stored in struct drm_device. DRM drivers that use VRAM MM should use this field to refer to their instance of the data structure. Appropriate helpers are now provided as well. Adding struct drm_vram_mm to struct drm_device further avoids wrappers and boilerplate code in drivers. This patch implements default functions for callbacks in struct drm_driver and struct file_operations that use the struct drm_vram_mm stored in struct drm_device. Drivers that need to provide their own implementations can still do so. The patch also adds documentation for the VRAM helper library in general. v5: * set .llseek to no_llseek() from DRM_VRAM_MM_FILE_OPERATIONS v4: * cleanups from checkpatch.pl * document VRAM helper library Signed-off-by: Thomas Zimmermann Link: http://patchwork.freedesktop.org/patch/msgid/20190508082630.15116-9-tzimmermann@suse.de Signed-off-by: Gerd Hoffmann --- Documentation/gpu/drm-mm.rst | 6 +++ drivers/gpu/drm/drm_gem_vram_helper.c | 28 ++++++++++ drivers/gpu/drm/drm_vram_helper_common.c | 92 ++++++++++++++++++++++++++++++++ drivers/gpu/drm/drm_vram_mm_helper.c | 85 +++++++++++++++++++++++++++++ include/drm/drm_device.h | 4 ++ include/drm/drm_gem_vram_helper.h | 19 ++++++- include/drm/drm_vram_mm_helper.h | 33 ++++++++++++ 7 files changed, 266 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index eba50afbda42..c8ebd4f66a6a 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -382,6 +382,12 @@ GEM CMA Helper Functions Reference VRAM Helper Function Reference ============================== +.. kernel-doc:: drivers/gpu/drm/drm_vram_helper_common.c + :doc: overview + +.. kernel-doc:: include/drm/drm_gem_vram_helper.h + :internal: + GEM VRAM Helper Functions Reference ----------------------------------- diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c b/drivers/gpu/drm/drm_gem_vram_helper.c index c21b1f920e0a..8f142b810eb4 100644 --- a/drivers/gpu/drm/drm_gem_vram_helper.c +++ b/drivers/gpu/drm/drm_gem_vram_helper.c @@ -1,6 +1,7 @@ // SPDX-License-Identifier: GPL-2.0-or-later #include +#include #include #include #include @@ -555,6 +556,33 @@ void drm_gem_vram_driver_gem_free_object_unlocked(struct drm_gem_object *gem) } EXPORT_SYMBOL(drm_gem_vram_driver_gem_free_object_unlocked); +/** + * drm_gem_vram_driver_create_dumb() - \ + Implements &struct drm_driver.dumb_create + * @file: the DRM file + * @dev: the DRM device + * @args: the arguments as provided to \ + &struct drm_driver.dumb_create + * + * This function requires the driver to use @drm_device.vram_mm for its + * instance of VRAM MM. + * + * Returns: + * 0 on success, or + * a negative error code otherwise. + */ +int drm_gem_vram_driver_dumb_create(struct drm_file *file, + struct drm_device *dev, + struct drm_mode_create_dumb *args) +{ + if (WARN_ONCE(!dev->vram_mm, "VRAM MM not initialized")) + return -EINVAL; + + return drm_gem_vram_fill_create_dumb(file, dev, &dev->vram_mm->bdev, 0, + false, args); +} +EXPORT_SYMBOL(drm_gem_vram_driver_dumb_create); + /** * drm_gem_vram_driver_dumb_mmap_offset() - \ Implements &struct drm_driver.dumb_mmap_offset diff --git a/drivers/gpu/drm/drm_vram_helper_common.c b/drivers/gpu/drm/drm_vram_helper_common.c index 7c25daca18d0..3b47f7002115 100644 --- a/drivers/gpu/drm/drm_vram_helper_common.c +++ b/drivers/gpu/drm/drm_vram_helper_common.c @@ -2,5 +2,97 @@ #include +/** + * DOC: overview + * + * This library provides &struct drm_gem_vram_object (GEM VRAM), a GEM + * buffer object that is backed by video RAM. It can be used for + * framebuffer devices with dedicated memory. The video RAM can be + * managed with &struct drm_vram_mm (VRAM MM). Both data structures are + * supposed to be used together, but can also be used individually. + * + * With the GEM interface userspace applications create, manage and destroy + * graphics buffers, such as an on-screen framebuffer. GEM does not provide + * an implementation of these interfaces. It's up to the DRM driver to + * provide an implementation that suits the hardware. If the hardware device + * contains dedicated video memory, the DRM driver can use the VRAM helper + * library. Each active buffer object is stored in video RAM. Active + * buffer are used for drawing the current frame, typically something like + * the frame's scanout buffer or the cursor image. If there's no more space + * left in VRAM, inactive GEM objects can be moved to system memory. + * + * The easiest way to use the VRAM helper library is to call + * drm_vram_helper_alloc_mm(). The function allocates and initializes an + * instance of &struct drm_vram_mm in &struct drm_device.vram_mm . Use + * &DRM_GEM_VRAM_DRIVER to initialize &struct drm_driver and + * &DRM_VRAM_MM_FILE_OPERATIONS to initialize &struct file_operations; + * as illustrated below. + * + * .. code-block:: c + * + * struct file_operations fops ={ + * .owner = THIS_MODULE, + * DRM_VRAM_MM_FILE_OPERATION + * }; + * struct drm_driver drv = { + * .driver_feature = DRM_ ... , + * .fops = &fops, + * DRM_GEM_VRAM_DRIVER + * }; + * + * int init_drm_driver() + * { + * struct drm_device *dev; + * uint64_t vram_base; + * unsigned long vram_size; + * int ret; + * + * // setup device, vram base and size + * // ... + * + * ret = drm_vram_helper_alloc_mm(dev, vram_base, vram_size, + * &drm_gem_vram_mm_funcs); + * if (ret) + * return ret; + * return 0; + * } + * + * This creates an instance of &struct drm_vram_mm, exports DRM userspace + * interfaces for GEM buffer management and initializes file operations to + * allow for accessing created GEM buffers. With this setup, the DRM driver + * manages an area of video RAM with VRAM MM and provides GEM VRAM objects + * to userspace. + * + * To clean up the VRAM memory management, call drm_vram_helper_release_mm() + * in the driver's clean-up code. + * + * .. code-block:: c + * + * void fini_drm_driver() + * { + * struct drm_device *dev = ...; + * + * drm_vram_helper_release_mm(dev); + * } + * + * For drawing or scanout operations, buffer object have to be pinned in video + * RAM. Call drm_gem_vram_pin() with &DRM_GEM_VRAM_PL_FLAG_VRAM or + * &DRM_GEM_VRAM_PL_FLAG_SYSTEM to pin a buffer object in video RAM or system + * memory. Call drm_gem_vram_unpin() to release the pinned object afterwards. + * If you have to evict a buffer object from video RAM (e.g., for freeing up + * memory), unpin the buffer and call drm_gem_vram_push_to_system(). + * + * A buffer object that is pinned in video RAM has a fixed address within that + * memory region. Call drm_gem_vram_offset() to retrieve this value. Typically + * it's used to program the hardware's scanout engine for framebuffers, set + * the cursor overlay's image for a mouse cursor, or use it as input to the + * hardware's draing engine. + * + * To access a buffer object's memory from the DRM driver, call + * drm_gem_vram_kmap(). It (optionally) maps the buffer into kernel address + * space and returns the memory address. Use drm_gem_vram_kunmap() to + * release the mapping. + */ + MODULE_DESCRIPTION("DRM VRAM memory-management helpers"); MODULE_LICENSE("GPL"); diff --git a/drivers/gpu/drm/drm_vram_mm_helper.c b/drivers/gpu/drm/drm_vram_mm_helper.c index d17c5169b018..c94a6dc5ade7 100644 --- a/drivers/gpu/drm/drm_vram_mm_helper.c +++ b/drivers/gpu/drm/drm_vram_mm_helper.c @@ -208,3 +208,88 @@ int drm_vram_mm_mmap(struct file *filp, struct vm_area_struct *vma, return ttm_bo_mmap(filp, vma, &vmm->bdev); } EXPORT_SYMBOL(drm_vram_mm_mmap); + +/* + * Helpers for integration with struct drm_device + */ + +/** + * drm_vram_helper_alloc_mm - Allocates a device's instance of \ + &struct drm_vram_mm + * @dev: the DRM device + * @vram_base: the base address of the video memory + * @vram_size: the size of the video memory in bytes + * @funcs: callback functions for buffer objects + * + * Returns: + * The new instance of &struct drm_vram_mm on success, or + * an ERR_PTR()-encoded errno code otherwise. + */ +struct drm_vram_mm *drm_vram_helper_alloc_mm( + struct drm_device *dev, uint64_t vram_base, size_t vram_size, + const struct drm_vram_mm_funcs *funcs) +{ + int ret; + + if (WARN_ON(dev->vram_mm)) + return dev->vram_mm; + + dev->vram_mm = kzalloc(sizeof(*dev->vram_mm), GFP_KERNEL); + if (!dev->vram_mm) + return ERR_PTR(-ENOMEM); + + ret = drm_vram_mm_init(dev->vram_mm, dev, vram_base, vram_size, funcs); + if (ret) + goto err_kfree; + + return dev->vram_mm; + +err_kfree: + kfree(dev->vram_mm); + dev->vram_mm = NULL; + return ERR_PTR(ret); +} +EXPORT_SYMBOL(drm_vram_helper_alloc_mm); + +/** + * drm_vram_helper_release_mm - Releases a device's instance of \ + &struct drm_vram_mm + * @dev: the DRM device + */ +void drm_vram_helper_release_mm(struct drm_device *dev) +{ + if (!dev->vram_mm) + return; + + drm_vram_mm_cleanup(dev->vram_mm); + kfree(dev->vram_mm); + dev->vram_mm = NULL; +} +EXPORT_SYMBOL(drm_vram_helper_release_mm); + +/* + * Helpers for &struct file_operations + */ + +/** + * drm_vram_mm_file_operations_mmap() - \ + Implements &struct file_operations.mmap() + * @filp: the mapping's file structure + * @vma: the mapping's memory area + * + * Returns: + * 0 on success, or + * a negative error code otherwise. + */ +int drm_vram_mm_file_operations_mmap( + struct file *filp, struct vm_area_struct *vma) +{ + struct drm_file *file_priv = filp->private_data; + struct drm_device *dev = file_priv->minor->dev; + + if (WARN_ONCE(!dev->vram_mm, "VRAM MM not initialized")) + return -EINVAL; + + return drm_vram_mm_mmap(filp, vma, dev->vram_mm); +} +EXPORT_SYMBOL(drm_vram_mm_file_operations_mmap); diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h index 7f9ef709b2b6..1acfc3bbd3fb 100644 --- a/include/drm/drm_device.h +++ b/include/drm/drm_device.h @@ -17,6 +17,7 @@ struct drm_vblank_crtc; struct drm_sg_mem; struct drm_local_map; struct drm_vma_offset_manager; +struct drm_vram_mm; struct drm_fb_helper; struct inode; @@ -286,6 +287,9 @@ struct drm_device { /** @vma_offset_manager: GEM information */ struct drm_vma_offset_manager *vma_offset_manager; + /** @vram_mm: VRAM MM memory manager */ + struct drm_vram_mm *vram_mm; + /** * @switch_power_state: * diff --git a/include/drm/drm_gem_vram_helper.h b/include/drm/drm_gem_vram_helper.h index 7971656afe87..b056f189ba62 100644 --- a/include/drm/drm_gem_vram_helper.h +++ b/include/drm/drm_gem_vram_helper.h @@ -11,6 +11,7 @@ struct drm_mode_create_dumb; struct drm_vram_mm_funcs; struct filp; +struct vm_area_struct; #define DRM_GEM_VRAM_PL_FLAG_VRAM TTM_PL_FLAG_VRAM #define DRM_GEM_VRAM_PL_FLAG_SYSTEM TTM_PL_FLAG_SYSTEM @@ -115,10 +116,26 @@ extern const struct drm_vram_mm_funcs drm_gem_vram_mm_funcs; */ void drm_gem_vram_driver_gem_free_object_unlocked(struct drm_gem_object *gem); - +int drm_gem_vram_driver_dumb_create(struct drm_file *file, + struct drm_device *dev, + struct drm_mode_create_dumb *args); int drm_gem_vram_driver_dumb_mmap_offset(struct drm_file *file, struct drm_device *dev, uint32_t handle, uint64_t *offset); + +/** + * define DRM_GEM_VRAM_DRIVER - default callback functions for \ + &struct drm_driver + * + * Drivers that use VRAM MM and GEM VRAM can use this macro to initialize + * &struct drm_driver with default functions. + */ +#define DRM_GEM_VRAM_DRIVER \ + .gem_free_object_unlocked = \ + drm_gem_vram_driver_gem_free_object_unlocked, \ + .dumb_create = drm_gem_vram_driver_dumb_create, \ + .dumb_map_offset = drm_gem_vram_driver_dumb_mmap_offset + /* * PRIME helpers for struct drm_driver */ diff --git a/include/drm/drm_vram_mm_helper.h b/include/drm/drm_vram_mm_helper.h index 5d45c6447fa4..a8ffd8599b08 100644 --- a/include/drm/drm_vram_mm_helper.h +++ b/include/drm/drm_vram_mm_helper.h @@ -66,4 +66,37 @@ void drm_vram_mm_cleanup(struct drm_vram_mm *vmm); int drm_vram_mm_mmap(struct file *filp, struct vm_area_struct *vma, struct drm_vram_mm *vmm); +/* + * Helpers for integration with struct drm_device + */ + +struct drm_vram_mm *drm_vram_helper_alloc_mm( + struct drm_device *dev, uint64_t vram_base, size_t vram_size, + const struct drm_vram_mm_funcs *funcs); +void drm_vram_helper_release_mm(struct drm_device *dev); + +/* + * Helpers for &struct file_operations + */ + +int drm_vram_mm_file_operations_mmap( + struct file *filp, struct vm_area_struct *vma); + +/** + * define DRM_VRAM_MM_FILE_OPERATIONS - default callback functions for \ + &struct file_operations + * + * Drivers that use VRAM MM can use this macro to initialize + * &struct file_operations with default functions. + */ +#define DRM_VRAM_MM_FILE_OPERATIONS \ + .llseek = no_llseek, \ + .read = drm_read, \ + .poll = drm_poll, \ + .unlocked_ioctl = drm_ioctl, \ + .compat_ioctl = drm_compat_ioctl, \ + .mmap = drm_vram_mm_file_operations_mmap, \ + .open = drm_open, \ + .release = drm_release \ + #endif -- cgit v1.2.3-59-g8ed1b From e35f5ad6a965de5d301ca5957a1c48c53fe366fb Mon Sep 17 00:00:00 2001 From: Jerome Brunet Date: Wed, 15 May 2019 15:18:56 +0200 Subject: ASoC: meson: add tohdmitx DT bindings Add the bindings and the related documentation for the audio hdmitx control glue of the Amlogic g12a SoC family Signed-off-by: Jerome Brunet Tested-by: Neil Armstrong Tested-by: Kevin Hilman Signed-off-by: Mark Brown --- .../bindings/sound/amlogic,g12a-tohdmitx.txt | 55 ++++++++++++++++++++++ include/dt-bindings/sound/meson-g12a-tohdmitx.h | 13 +++++ 2 files changed, 68 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/amlogic,g12a-tohdmitx.txt create mode 100644 include/dt-bindings/sound/meson-g12a-tohdmitx.h (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/amlogic,g12a-tohdmitx.txt b/Documentation/devicetree/bindings/sound/amlogic,g12a-tohdmitx.txt new file mode 100644 index 000000000000..aa6c35570d31 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/amlogic,g12a-tohdmitx.txt @@ -0,0 +1,55 @@ +* Amlogic HDMI Tx control glue + +Required properties: +- compatible: "amlogic,g12a-tohdmitx" +- reg: physical base address of the controller and length of memory + mapped region. +- #sound-dai-cells: should be 1. + +Example on the S905X2 SoC: + +tohdmitx: audio-controller@744 { + compatible = "amlogic,g12a-tohdmitx"; + reg = <0x0 0x744 0x0 0x4>; + #sound-dai-cells = <1>; +}; + +Example of an 'amlogic,axg-sound-card': + +sound { + compatible = "amlogic,axg-sound-card"; + +[...] + + dai-link-x { + sound-dai = <&tdmif_a>; + dai-format = "i2s"; + dai-tdm-slot-tx-mask-0 = <1 1>; + + codec-0 { + sound-dai = <&tohdmitx TOHDMITX_I2S_IN_A>; + }; + + codec-1 { + sound-dai = <&external_dac>; + }; + }; + + dai-link-y { + sound-dai = <&tdmif_c>; + dai-format = "i2s"; + dai-tdm-slot-tx-mask-0 = <1 1>; + + codec { + sound-dai = <&tohdmitx TOHDMITX_I2S_IN_C>; + }; + }; + + dai-link-z { + sound-dai = <&tohdmitx TOHDMITX_I2S_OUT>; + + codec { + sound-dai = <&hdmi_tx>; + }; + }; +}; diff --git a/include/dt-bindings/sound/meson-g12a-tohdmitx.h b/include/dt-bindings/sound/meson-g12a-tohdmitx.h new file mode 100644 index 000000000000..c5e1f48d30d0 --- /dev/null +++ b/include/dt-bindings/sound/meson-g12a-tohdmitx.h @@ -0,0 +1,13 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef __DT_MESON_G12A_TOHDMITX_H +#define __DT_MESON_G12A_TOHDMITX_H + +#define TOHDMITX_I2S_IN_A 0 +#define TOHDMITX_I2S_IN_B 1 +#define TOHDMITX_I2S_IN_C 2 +#define TOHDMITX_I2S_OUT 3 +#define TOHDMITX_SPDIF_IN_A 4 +#define TOHDMITX_SPDIF_IN_B 5 +#define TOHDMITX_SPDIF_OUT 6 + +#endif /* __DT_MESON_G12A_TOHDMITX_H */ -- cgit v1.2.3-59-g8ed1b From 3d42fca00891774c50585c1b2f83357a0904c8bc Mon Sep 17 00:00:00 2001 From: Eric Anholt Date: Wed, 24 Apr 2019 15:06:38 -0700 Subject: drm/doc: Allow new UAPI to be used once it's in drm-next/drm-misc-next. I was trying to figure out if it was permissible to merge the Mesa side of V3D's CSD support yet while it's in drm-misc-next but not drm-next, and developers on #dri-devel IRC had differing opinions of what the requirement was. v2: Restrict to just drm-next or drm-misc-next on airlied's request. Signed-off-by: Eric Anholt Link: https://patchwork.freedesktop.org/patch/msgid/20190424220638.16222-1-eric@anholt.net Reviewed-by: Daniel Vetter --- Documentation/gpu/drm-uapi.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index c9fd23efd957..b7a96dc02d21 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -92,9 +92,9 @@ leads to a few additional requirements: requirements by doing a quick fork. - The kernel patch can only be merged after all the above requirements are met, - but it **must** be merged **before** the userspace patches land. uAPI always flows - from the kernel, doing things the other way round risks divergence of the uAPI - definitions and header files. + but it **must** be merged to either drm-next or drm-misc-next **before** the + userspace patches land. uAPI always flows from the kernel, doing things the + other way round risks divergence of the uAPI definitions and header files. These are fairly steep requirements, but have grown out from years of shared pain and experience with uAPI added hastily, and almost always regretted about -- cgit v1.2.3-59-g8ed1b From ba6e798ecf320716780bb6a6088a8d17dcba1d49 Mon Sep 17 00:00:00 2001 From: Eric Anholt Date: Wed, 24 Apr 2019 11:56:17 -0700 Subject: drm/doc: Document expectation that userspace review looks at kernel uAPI. The point of this review process is that userspace using the new uAPI can actually live with the uAPI being provided, and it's hard to know that without having actually looked into a kernel patch yourself. Signed-off-by: Eric Anholt Suggested-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20190424185617.16865-2-eric@anholt.net Reviewed-by: Daniel Vetter --- Documentation/gpu/drm-uapi.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index b7a96dc02d21..05874d09820c 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -85,7 +85,9 @@ leads to a few additional requirements: - The userspace side must be fully reviewed and tested to the standards of that userspace project. For e.g. mesa this means piglit testcases and review on the mailing list. This is again to ensure that the new interface actually gets the - job done. + job done. The userspace-side reviewer should also provide at least an + Acked-by on the kernel uAPI patch indicating that they've looked at how the + kernel side is implementing the new feature being used. - The userspace patches must be against the canonical upstream, not some vendor fork. This is to make sure that no one cheats on the review and testing -- cgit v1.2.3-59-g8ed1b From 506c7f9b0612c46732aa74317f59a28d9477905b Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Thu, 16 May 2019 09:59:25 +0200 Subject: dt-bindings: sound: Convert Allwinner SPDIF binding to YAML The Allwinner SoCs feature an SPDIF controller across multiple SoC generations. However, earlier generations were a bit simpler than the subsequent ones, and for example would always have RX and TX capabilities, and no reset lines. In order to express this, let's create two YAML schemas instead of the free form text we had before. Signed-off-by: Maxime Ripard Reviewed-by: Rob Herring Signed-off-by: Mark Brown --- .../bindings/sound/allwinner,sun4i-a10-spdif.yaml | 101 +++++++++++++++++++++ .../bindings/sound/sunxi,sun4i-spdif.txt | 42 --------- 2 files changed, 101 insertions(+), 42 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-spdif.yaml delete mode 100644 Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-spdif.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-spdif.yaml new file mode 100644 index 000000000000..5d72d48e923e --- /dev/null +++ b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-spdif.yaml @@ -0,0 +1,101 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/allwinner,sun4i-a10-spdif.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner A10 S/PDIF Controller Device Tree Bindings + +maintainers: + - Chen-Yu Tsai + - Liam Girdwood + - Mark Brown + - Maxime Ripard + +properties: + "#sound-dai-cells": + const: 0 + + compatible: + oneOf: + - const: allwinner,sun4i-a10-spdif + - const: allwinner,sun6i-a31-spdif + - const: allwinner,sun8i-h3-spdif + - items: + - const: allwinner,sun8i-a83t-spdif + - const: allwinner,sun8i-h3-spdif + - items: + - const: allwinner,sun50i-a64-spdif + - const: allwinner,sun8i-h3-spdif + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Bus Clock + - description: Module Clock + + clock-names: + items: + - const: apb + - const: spdif + + dmas: + items: + - description: RX DMA Channel + - description: TX DMA Channel + + dma-names: + items: + - const: rx + - const: tx + + # Even though it only applies to subschemas under the conditionals, + # not listing them here will trigger a warning because of the + # additionalsProperties set to false. + resets: + maxItems: 1 + +allOf: + - if: + properties: + compatible: + contains: + enum: + - allwinner,sun6i-a31-spdif + - allwinner,sun8i-h3-spdif + + then: + required: + - resets + +required: + - "#sound-dai-cells" + - compatible + - reg + - interrupts + - clocks + - clock-names + - dmas + - dma-names + +additionalProperties: false + +examples: + - | + spdif: spdif@1c21000 { + #sound-dai-cells = <0>; + compatible = "allwinner,sun4i-a10-spdif"; + reg = <0x01c21000 0x40>; + interrupts = <13>; + clocks = <&apb0_gates 1>, <&spdif_clk>; + clock-names = "apb", "spdif"; + dmas = <&dma 0 2>, <&dma 0 2>; + dma-names = "rx", "tx"; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt b/Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt deleted file mode 100644 index 0c64a209c2e9..000000000000 --- a/Documentation/devicetree/bindings/sound/sunxi,sun4i-spdif.txt +++ /dev/null @@ -1,42 +0,0 @@ -Allwinner Sony/Philips Digital Interface Format (S/PDIF) Controller - -The Allwinner S/PDIF audio block is a transceiver that allows the -processor to receive and transmit digital audio via an coaxial cable or -a fibre cable. -For now only playback is supported. - -Required properties: - - - compatible : should be one of the following: - - "allwinner,sun4i-a10-spdif": for the Allwinner A10 SoC - - "allwinner,sun6i-a31-spdif": for the Allwinner A31 SoC - - "allwinner,sun8i-h3-spdif": for the Allwinner H3 SoC - - - reg : Offset and length of the register set for the device. - - - interrupts : Contains the spdif interrupt. - - - dmas : Generic dma devicetree binding as described in - Documentation/devicetree/bindings/dma/dma.txt. - - - dma-names : Two dmas have to be defined, "tx" and "rx". - - - clocks : Contains an entry for each entry in clock-names. - - - clock-names : Includes the following entries: - "apb" clock for the spdif bus. - "spdif" clock for spdif controller. - - - resets : reset specifier for the ahb reset (A31 and newer only) - -Example: - -spdif: spdif@1c21000 { - compatible = "allwinner,sun4i-a10-spdif"; - reg = <0x01c21000 0x40>; - interrupts = <13>; - clocks = <&apb0_gates 1>, <&spdif_clk>; - clock-names = "apb", "spdif"; - dmas = <&dma 0 2>, <&dma 0 2>; - dma-names = "rx", "tx"; -}; -- cgit v1.2.3-59-g8ed1b From b1f35dfd7c2f509b0736f1ff02c314130b6b773e Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Thu, 16 May 2019 09:59:26 +0200 Subject: dt-bindings: sound: sun4i-spdif: Document that the RX channel can be missing The H3 and compatibles controllers don't have any reception capabilities, even though it was never documented as such in the binding before. Therefore, on those controllers, we don't have the option to set an RX DMA channel. This was already done in the DTSI, but the binding itself was never updated. Let's add a special case in the schemas. Signed-off-by: Maxime Ripard Reviewed-by: Rob Herring Signed-off-by: Mark Brown --- .../bindings/sound/allwinner,sun4i-a10-spdif.yaml | 38 ++++++++++++++++------ 1 file changed, 28 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-spdif.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-spdif.yaml index 5d72d48e923e..a49ef2294a74 100644 --- a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-spdif.yaml +++ b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-spdif.yaml @@ -44,19 +44,11 @@ properties: - const: apb - const: spdif - dmas: - items: - - description: RX DMA Channel - - description: TX DMA Channel - - dma-names: - items: - - const: rx - - const: tx - # Even though it only applies to subschemas under the conditionals, # not listing them here will trigger a warning because of the # additionalsProperties set to false. + dmas: true + dma-names: true resets: maxItems: 1 @@ -73,6 +65,32 @@ allOf: required: - resets + - if: + properties: + compatible: + contains: + const: allwinner,sun8i-h3-spdif + + then: + properties: + dmas: + description: TX DMA Channel + + dma-names: + const: tx + + else: + properties: + dmas: + items: + - description: RX DMA Channel + - description: TX DMA Channel + + dma-names: + items: + - const: rx + - const: tx + required: - "#sound-dai-cells" - compatible -- cgit v1.2.3-59-g8ed1b From 79c5ecafe95f9fae41693bb0b89a4c3be7851a6d Mon Sep 17 00:00:00 2001 From: Yannick Fertré Date: Tue, 14 May 2019 11:35:55 +0200 Subject: dt-bindings: display: stm32: add supply property to DSI controller MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This patch adds documentation of a new property phy-dsi-supply to the STM32 DSI controller. Signed-off-by: Yannick Fertré Reviewed-by: Rob Herring Reviewed-by: Philippe Cornu Signed-off-by: Benjamin Gaignard Link: https://patchwork.freedesktop.org/patch/msgid/1557826556-10079-2-git-send-email-yannick.fertre@st.com --- Documentation/devicetree/bindings/display/st,stm32-ltdc.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt index 3eb1b48b47dd..60c54da4e526 100644 --- a/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt +++ b/Documentation/devicetree/bindings/display/st,stm32-ltdc.txt @@ -40,6 +40,8 @@ Mandatory nodes specific to STM32 DSI: - panel or bridge node: A node containing the panel or bridge description as documented in [6]. - port: panel or bridge port node, connected to the DSI output port (port@1). +Optional properties: +- phy-dsi-supply: phandle of the regulator that provides the supply voltage. Note: You can find more documentation in the following references [1] Documentation/devicetree/bindings/clock/clock-bindings.txt @@ -101,6 +103,7 @@ Example 2: DSI panel clock-names = "pclk", "ref"; resets = <&rcc STM32F4_APB2_RESET(DSI)>; reset-names = "apb"; + phy-dsi-supply = <®18>; ports { #address-cells = <1>; -- cgit v1.2.3-59-g8ed1b From e359a29225dde53fade5fa4bc3d957599fb5f9a5 Mon Sep 17 00:00:00 2001 From: Alexandru Ardelean Date: Fri, 17 May 2019 18:44:41 +0300 Subject: dt-bindings: iio: accel: adxl345: switch to YAML bindings The ADX345 supports both I2C & SPI bindings. This change switches from old text bindings, to YAML bindings, and also tries to make use of the recent multiple-examples support. Signed-off-by: Alexandru Ardelean Reviewed-by: Rob Herring Signed-off-by: Jonathan Cameron --- .../devicetree/bindings/iio/accel/adi,adxl345.yaml | 72 ++++++++++++++++++++++ .../devicetree/bindings/iio/accel/adxl345.txt | 39 ------------ MAINTAINERS | 1 + 3 files changed, 73 insertions(+), 39 deletions(-) create mode 100644 Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml delete mode 100644 Documentation/devicetree/bindings/iio/accel/adxl345.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml new file mode 100644 index 000000000000..7ba167e2e1ea --- /dev/null +++ b/Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/accelerometers/adi,adxl345.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices ADXL345/ADXL375 3-Axis Digital Accelerometers + +maintainers: + - Michael Hennerich + +description: | + Analog Devices ADXL345/ADXL375 3-Axis Digital Accelerometers that supports + both I2C & SPI interfaces. + http://www.analog.com/en/products/mems/accelerometers/adxl345.html + http://www.analog.com/en/products/sensors-mems/accelerometers/adxl375.html + +properties: + compatible: + enum: + - adi,adxl345 + - adi,adxl375 + + reg: + maxItems: 1 + + spi-cpha: true + + spi-cpol: true + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +examples: + - | + #include + #include + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + + /* Example for a I2C device node */ + accelerometer@2a { + compatible = "adi,adxl345"; + reg = <0x53>; + interrupt-parent = <&gpio0>; + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; + }; + }; + - | + #include + #include + spi0 { + #address-cells = <1>; + #size-cells = <0>; + + /* Example for a SPI device node */ + accelerometer@0 { + compatible = "adi,adxl345"; + reg = <0>; + spi-max-frequency = <5000000>; + spi-cpol; + spi-cpha; + interrupt-parent = <&gpio0>; + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; + }; + }; diff --git a/Documentation/devicetree/bindings/iio/accel/adxl345.txt b/Documentation/devicetree/bindings/iio/accel/adxl345.txt deleted file mode 100644 index f9525f6e3d43..000000000000 --- a/Documentation/devicetree/bindings/iio/accel/adxl345.txt +++ /dev/null @@ -1,39 +0,0 @@ -Analog Devices ADXL345/ADXL375 3-Axis Digital Accelerometers - -http://www.analog.com/en/products/mems/accelerometers/adxl345.html -http://www.analog.com/en/products/sensors-mems/accelerometers/adxl375.html - -Required properties: - - compatible : should be one of - "adi,adxl345" - "adi,adxl375" - - reg : the I2C address or SPI chip select number of the sensor - -Required properties for SPI bus usage: - - spi-max-frequency : set maximum clock frequency, must be 5000000 - - spi-cpol and spi-cpha : must be defined for adxl345 to enable SPI mode 3 - -Optional properties: - - interrupts: interrupt mapping for IRQ as documented in - Documentation/devicetree/bindings/interrupt-controller/interrupts.txt - -Example for a I2C device node: - - accelerometer@2a { - compatible = "adi,adxl345"; - reg = <0x53>; - interrupt-parent = <&gpio1>; - interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; - }; - -Example for a SPI device node: - - accelerometer@0 { - compatible = "adi,adxl345"; - reg = <0>; - spi-max-frequency = <5000000>; - spi-cpol; - spi-cpha; - interrupt-parent = <&gpio1>; - interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; - }; diff --git a/MAINTAINERS b/MAINTAINERS index 43a9cebb2c19..54c8e14fae98 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -551,6 +551,7 @@ W: http://wiki.analog.com/ADXL345 W: http://ez.analog.com/community/linux-device-drivers S: Supported F: drivers/input/misc/adxl34x.c +F: Documentation/devicetree/bindings/iio/accel/adi,adxl345.yaml ADXL372 THREE-AXIS DIGITAL ACCELEROMETER DRIVER M: Stefan Popa -- cgit v1.2.3-59-g8ed1b From 73e1ccdab3c34b8f9be6e55600d40a1478049121 Mon Sep 17 00:00:00 2001 From: Chun-Hung Wu Date: Thu, 16 May 2019 16:10:44 +0800 Subject: dt-bindings: iio: adc: mediatek: Add document for mt6765 Add compatible node for mt6765 auxadc Signed-off-by: Chun-Hung Wu Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt b/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt index 936a0b4666da..78c06e05c8e5 100644 --- a/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt +++ b/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt @@ -13,6 +13,7 @@ Required properties: - compatible: Should be one of: - "mediatek,mt2701-auxadc": For MT2701 family of SoCs - "mediatek,mt2712-auxadc": For MT2712 family of SoCs + - "mediatek,mt6765-auxadc": For MT6765 family of SoCs - "mediatek,mt7622-auxadc": For MT7622 family of SoCs - "mediatek,mt8173-auxadc": For MT8173 family of SoCs - "mediatek,mt8183-auxadc", "mediatek,mt8173-auxadc": For MT8183 family of SoCs -- cgit v1.2.3-59-g8ed1b From a02177a39344b643dccfa3b18fa5c1fc4984e1e5 Mon Sep 17 00:00:00 2001 From: Leonard Crestez Date: Mon, 13 May 2019 11:01:39 +0000 Subject: dt-bindings: imx-cpufreq-dt: Document opp-supported-hw usage The interpretation of opp-supported-hw bits for imx-cpufreq-dt driver is not very obvious so attempt to explain it. There is no OF compat string associated. Reviewed-by: Rob Herring Signed-off-by: Leonard Crestez Signed-off-by: Viresh Kumar --- .../devicetree/bindings/cpufreq/imx-cpufreq-dt.txt | 37 ++++++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 Documentation/devicetree/bindings/cpufreq/imx-cpufreq-dt.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/cpufreq/imx-cpufreq-dt.txt b/Documentation/devicetree/bindings/cpufreq/imx-cpufreq-dt.txt new file mode 100644 index 000000000000..87bff5add3f9 --- /dev/null +++ b/Documentation/devicetree/bindings/cpufreq/imx-cpufreq-dt.txt @@ -0,0 +1,37 @@ +i.MX CPUFreq-DT OPP bindings +================================ + +Certain i.MX SoCs support different OPPs depending on the "market segment" and +"speed grading" value which are written in fuses. These bits are combined with +the opp-supported-hw values for each OPP to check if the OPP is allowed. + +Required properties: +-------------------- + +For each opp entry in 'operating-points-v2' table: +- opp-supported-hw: Two bitmaps indicating: + - Supported speed grade mask + - Supported market segment mask + 0: Consumer + 1: Extended Consumer + 2: Industrial + 3: Automotive + +Example: +-------- + +opp_table { + compatible = "operating-points-v2"; + opp-1000000000 { + opp-hz = /bits/ 64 <1000000000>; + /* grade >= 0, consumer only */ + opp-supported-hw = <0xf>, <0x3>; + }; + + opp-1300000000 { + opp-hz = /bits/ 64 <1300000000>; + opp-microvolt = <1000000>; + /* grade >= 1, all segments */ + opp-supported-hw = <0xe>, <0x7>; + }; +} -- cgit v1.2.3-59-g8ed1b From a28d1b67cf4f330fb532c8e515025b360d10691a Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Tue, 7 May 2019 21:38:48 +0200 Subject: dt-bindings: bus: Convert Allwinner RSB to a schema The newer Allwinner SoCs feature a bus designed for the PMIC, similar to I2C called RSB. Let's convert the device tree bindings for that bus over to a YAML schemas. Signed-off-by: Maxime Ripard --- .../bindings/bus/allwinner,sun8i-a23-rsb.yaml | 79 ++++++++++++++++++++++ .../devicetree/bindings/bus/sunxi-rsb.txt | 47 ------------- 2 files changed, 79 insertions(+), 47 deletions(-) create mode 100644 Documentation/devicetree/bindings/bus/allwinner,sun8i-a23-rsb.yaml delete mode 100644 Documentation/devicetree/bindings/bus/sunxi-rsb.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/bus/allwinner,sun8i-a23-rsb.yaml b/Documentation/devicetree/bindings/bus/allwinner,sun8i-a23-rsb.yaml new file mode 100644 index 000000000000..fc2f63860cc8 --- /dev/null +++ b/Documentation/devicetree/bindings/bus/allwinner,sun8i-a23-rsb.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/bus/allwinner,sun8i-a23-rsb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner A23 RSB Device Tree Bindings + +maintainers: + - Chen-Yu Tsai + - Maxime Ripard + +properties: + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + compatible: + oneOf: + - const: allwinner,sun8i-a23-rsb + - items: + - const: allwinner,sun8i-a83t-rsb + - const: allwinner,sun8i-a23-rsb + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + + clock-frequency: + minimum: 1 + maximum: 20000000 + +patternProperties: + "^.*@[0-9a-fA-F]+$": + properties: + reg: + maxItems: 1 + + required: + - reg + +required: + - compatible + - reg + - interrupts + - clocks + - resets + +examples: + - | + rsb@1f03400 { + 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>; + + /* ... */ + }; + }; + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/bus/sunxi-rsb.txt b/Documentation/devicetree/bindings/bus/sunxi-rsb.txt deleted file mode 100644 index eb3ed628c6f1..000000000000 --- a/Documentation/devicetree/bindings/bus/sunxi-rsb.txt +++ /dev/null @@ -1,47 +0,0 @@ -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@1f03400 { - 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>; - - /* ... */ - }; - }; -- cgit v1.2.3-59-g8ed1b From 4c1ca625c622b7a9f04c2949fd1ffdc6effa86de Mon Sep 17 00:00:00 2001 From: Nick Crews Date: Tue, 16 Apr 2019 19:20:47 -0600 Subject: platform/chrome: wilco_ec: Add Boot on AC support Boot on AC is a policy which makes the device boot from S5 when AC power is connected. This is useful for users who want to run their device headless or with a dock. Signed-off-by: Nick Crews Signed-off-by: Enric Balletbo i Serra --- Documentation/ABI/testing/sysfs-platform-wilco-ec | 9 +++ drivers/platform/chrome/wilco_ec/Makefile | 2 +- drivers/platform/chrome/wilco_ec/core.c | 9 +++ drivers/platform/chrome/wilco_ec/sysfs.c | 77 +++++++++++++++++++++++ include/linux/platform_data/wilco-ec.h | 12 ++++ 5 files changed, 108 insertions(+), 1 deletion(-) create mode 100644 Documentation/ABI/testing/sysfs-platform-wilco-ec create mode 100644 drivers/platform/chrome/wilco_ec/sysfs.c (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-platform-wilco-ec b/Documentation/ABI/testing/sysfs-platform-wilco-ec new file mode 100644 index 000000000000..8e5d6eee44db --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform-wilco-ec @@ -0,0 +1,9 @@ +What: /sys/bus/platform/devices/GOOG000C\:00/boot_on_ac +Date: April 2019 +KernelVersion: 5.3 +Description: + Boot on AC is a policy which makes the device boot from S5 + when AC power is connected. This is useful for users who + want to run their device headless or with a dock. + + Input should be parseable by kstrtou8() to 0 or 1. diff --git a/drivers/platform/chrome/wilco_ec/Makefile b/drivers/platform/chrome/wilco_ec/Makefile index 29b734137786..72df9b5e1983 100644 --- a/drivers/platform/chrome/wilco_ec/Makefile +++ b/drivers/platform/chrome/wilco_ec/Makefile @@ -1,6 +1,6 @@ # SPDX-License-Identifier: GPL-2.0 -wilco_ec-objs := core.o mailbox.o properties.o +wilco_ec-objs := core.o mailbox.o properties.o sysfs.o obj-$(CONFIG_WILCO_EC) += wilco_ec.o wilco_ec_debugfs-objs := debugfs.o obj-$(CONFIG_WILCO_EC_DEBUGFS) += wilco_ec_debugfs.o diff --git a/drivers/platform/chrome/wilco_ec/core.c b/drivers/platform/chrome/wilco_ec/core.c index 05e1e2be1c91..abd15d04e57b 100644 --- a/drivers/platform/chrome/wilco_ec/core.c +++ b/drivers/platform/chrome/wilco_ec/core.c @@ -89,8 +89,16 @@ static int wilco_ec_probe(struct platform_device *pdev) goto unregister_debugfs; } + ret = wilco_ec_add_sysfs(ec); + if (ret < 0) { + dev_err(dev, "Failed to create sysfs entries: %d", ret); + goto unregister_rtc; + } + return 0; +unregister_rtc: + platform_device_unregister(ec->rtc_pdev); unregister_debugfs: if (ec->debugfs_pdev) platform_device_unregister(ec->debugfs_pdev); @@ -102,6 +110,7 @@ static int wilco_ec_remove(struct platform_device *pdev) { struct wilco_ec_device *ec = platform_get_drvdata(pdev); + wilco_ec_remove_sysfs(ec); platform_device_unregister(ec->rtc_pdev); if (ec->debugfs_pdev) platform_device_unregister(ec->debugfs_pdev); diff --git a/drivers/platform/chrome/wilco_ec/sysfs.c b/drivers/platform/chrome/wilco_ec/sysfs.c new file mode 100644 index 000000000000..f84f0480460a --- /dev/null +++ b/drivers/platform/chrome/wilco_ec/sysfs.c @@ -0,0 +1,77 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright 2019 Google LLC + * + * Sysfs properties to view and modify EC-controlled features on Wilco devices. + * The entries will appear under /sys/bus/platform/devices/GOOG000C:00/ + * + * See Documentation/ABI/testing/sysfs-platform-wilco-ec for more information. + */ + +#include +#include + +#define CMD_KB_CMOS 0x7C +#define SUB_CMD_KB_CMOS_AUTO_ON 0x03 + +struct boot_on_ac_request { + u8 cmd; /* Always CMD_KB_CMOS */ + u8 reserved1; + u8 sub_cmd; /* Always SUB_CMD_KB_CMOS_AUTO_ON */ + u8 reserved3to5[3]; + u8 val; /* Either 0 or 1 */ + u8 reserved7; +} __packed; + +static ssize_t boot_on_ac_store(struct device *dev, + struct device_attribute *attr, + const char *buf, size_t count) +{ + struct wilco_ec_device *ec = dev_get_drvdata(dev); + struct boot_on_ac_request rq; + struct wilco_ec_message msg; + int ret; + u8 val; + + ret = kstrtou8(buf, 10, &val); + if (ret < 0) + return ret; + if (val > 1) + return -EINVAL; + + memset(&rq, 0, sizeof(rq)); + rq.cmd = CMD_KB_CMOS; + rq.sub_cmd = SUB_CMD_KB_CMOS_AUTO_ON; + rq.val = val; + + memset(&msg, 0, sizeof(msg)); + msg.type = WILCO_EC_MSG_LEGACY; + msg.request_data = &rq; + msg.request_size = sizeof(rq); + ret = wilco_ec_mailbox(ec, &msg); + if (ret < 0) + return ret; + + return count; +} + +static DEVICE_ATTR_WO(boot_on_ac); + +static struct attribute *wilco_dev_attrs[] = { + &dev_attr_boot_on_ac.attr, + NULL, +}; + +static struct attribute_group wilco_dev_attr_group = { + .attrs = wilco_dev_attrs, +}; + +int wilco_ec_add_sysfs(struct wilco_ec_device *ec) +{ + return sysfs_create_group(&ec->dev->kobj, &wilco_dev_attr_group); +} + +void wilco_ec_remove_sysfs(struct wilco_ec_device *ec) +{ + sysfs_remove_group(&ec->dev->kobj, &wilco_dev_attr_group); +} diff --git a/include/linux/platform_data/wilco-ec.h b/include/linux/platform_data/wilco-ec.h index 50a21bd5fd44..af68fc0563cc 100644 --- a/include/linux/platform_data/wilco-ec.h +++ b/include/linux/platform_data/wilco-ec.h @@ -194,4 +194,16 @@ int wilco_ec_get_byte_property(struct wilco_ec_device *ec, u32 property_id, int wilco_ec_set_byte_property(struct wilco_ec_device *ec, u32 property_id, u8 val); +/** + * wilco_ec_add_sysfs() - Create sysfs entries + * @ec: Wilco EC device + * + * wilco_ec_remove_sysfs() needs to be called afterwards + * to perform the necessary cleanup. + * + * Return: 0 on success or negative error code on failure. + */ +int wilco_ec_add_sysfs(struct wilco_ec_device *ec); +void wilco_ec_remove_sysfs(struct wilco_ec_device *ec); + #endif /* WILCO_EC_H */ -- cgit v1.2.3-59-g8ed1b From 2ad1f7a91449de48d4bd5d1ec361ba7bb9026505 Mon Sep 17 00:00:00 2001 From: Nick Crews Date: Wed, 8 May 2019 15:38:09 -0600 Subject: platform/chrome: wilco_ec: Remove 256 byte transfers The 0xF6 command, intended to send and receive 256 byte payloads to and from the EC, is not needed. The 0xF5 command for 32 byte payloads is sufficient. This patch removes support for the 0xF6 command and 256 byte payloads. Signed-off-by: Nick Crews Signed-off-by: Enric Balletbo i Serra --- Documentation/ABI/testing/debugfs-wilco-ec | 16 +++++++--------- drivers/platform/chrome/wilco_ec/core.c | 4 +--- drivers/platform/chrome/wilco_ec/debugfs.c | 10 ++-------- drivers/platform/chrome/wilco_ec/mailbox.c | 21 +++++---------------- include/linux/platform_data/wilco-ec.h | 9 ++------- 5 files changed, 17 insertions(+), 43 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/debugfs-wilco-ec b/Documentation/ABI/testing/debugfs-wilco-ec index 73a5a66ddca6..9d8d9d2def5b 100644 --- a/Documentation/ABI/testing/debugfs-wilco-ec +++ b/Documentation/ABI/testing/debugfs-wilco-ec @@ -23,11 +23,9 @@ Description: For writing, bytes 0-1 indicate the message type, one of enum wilco_ec_msg_type. Byte 2+ consist of the data passed in the - request, starting at MBOX[0] - - At least three bytes are required for writing, two for the type - and at least a single byte of data. Only the first - EC_MAILBOX_DATA_SIZE bytes of MBOX will be used. + request, starting at MBOX[0]. At least three bytes are required + for writing, two for the type and at least a single byte of + data. Example: // Request EC info type 3 (EC firmware build date) @@ -40,7 +38,7 @@ Description: $ cat /sys/kernel/debug/wilco_ec/raw 00 00 31 32 2f 32 31 2f 31 38 00 38 00 01 00 2f 00 ..12/21/18.8... - Note that the first 32 bytes of the received MBOX[] will be - printed, even if some of the data is junk. It is up to you to - know how many of the first bytes of data are the actual - response. + Note that the first 16 bytes of the received MBOX[] will be + printed, even if some of the data is junk, and skipping bytes + 17 to 32. It is up to you to know how many of the first bytes of + data are the actual response. diff --git a/drivers/platform/chrome/wilco_ec/core.c b/drivers/platform/chrome/wilco_ec/core.c index abd15d04e57b..45cf3a5ed062 100644 --- a/drivers/platform/chrome/wilco_ec/core.c +++ b/drivers/platform/chrome/wilco_ec/core.c @@ -52,9 +52,7 @@ static int wilco_ec_probe(struct platform_device *pdev) ec->dev = dev; mutex_init(&ec->mailbox_lock); - /* Largest data buffer size requirement is extended data response */ - ec->data_size = sizeof(struct wilco_ec_response) + - EC_MAILBOX_DATA_SIZE_EXTENDED; + ec->data_size = sizeof(struct wilco_ec_response) + EC_MAILBOX_DATA_SIZE; ec->data_buffer = devm_kzalloc(dev, ec->data_size, GFP_KERNEL); if (!ec->data_buffer) return -ENOMEM; diff --git a/drivers/platform/chrome/wilco_ec/debugfs.c b/drivers/platform/chrome/wilco_ec/debugfs.c index f163476d080d..281ec595e8e0 100644 --- a/drivers/platform/chrome/wilco_ec/debugfs.c +++ b/drivers/platform/chrome/wilco_ec/debugfs.c @@ -17,13 +17,13 @@ #define DRV_NAME "wilco-ec-debugfs" /* The 256 raw bytes will take up more space when represented as a hex string */ -#define FORMATTED_BUFFER_SIZE (EC_MAILBOX_DATA_SIZE_EXTENDED * 4) +#define FORMATTED_BUFFER_SIZE (EC_MAILBOX_DATA_SIZE * 4) struct wilco_ec_debugfs { struct wilco_ec_device *ec; struct dentry *dir; size_t response_size; - u8 raw_data[EC_MAILBOX_DATA_SIZE_EXTENDED]; + u8 raw_data[EC_MAILBOX_DATA_SIZE]; u8 formatted_data[FORMATTED_BUFFER_SIZE]; }; static struct wilco_ec_debugfs *debug_info; @@ -124,12 +124,6 @@ static ssize_t raw_write(struct file *file, const char __user *user_buf, msg.response_data = debug_info->raw_data; msg.response_size = EC_MAILBOX_DATA_SIZE; - /* Telemetry commands use extended response data */ - if (msg.type == WILCO_EC_MSG_TELEMETRY_LONG) { - msg.flags |= WILCO_EC_FLAG_EXTENDED_DATA; - msg.response_size = EC_MAILBOX_DATA_SIZE_EXTENDED; - } - ret = wilco_ec_mailbox(debug_info->ec, &msg); if (ret < 0) return ret; diff --git a/drivers/platform/chrome/wilco_ec/mailbox.c b/drivers/platform/chrome/wilco_ec/mailbox.c index 7fb58b487963..ced1f9f3dcee 100644 --- a/drivers/platform/chrome/wilco_ec/mailbox.c +++ b/drivers/platform/chrome/wilco_ec/mailbox.c @@ -119,7 +119,6 @@ static int wilco_ec_transfer(struct wilco_ec_device *ec, struct wilco_ec_response *rs; u8 checksum; u8 flag; - size_t size; /* Write request header, then data */ cros_ec_lpc_io_bytes_mec(MEC_IO_WRITE, 0, sizeof(*rq), (u8 *)rq); @@ -148,21 +147,11 @@ static int wilco_ec_transfer(struct wilco_ec_device *ec, return -EIO; } - /* - * The EC always returns either EC_MAILBOX_DATA_SIZE or - * EC_MAILBOX_DATA_SIZE_EXTENDED bytes of data, so we need to - * calculate the checksum on **all** of this data, even if we - * won't use all of it. - */ - if (msg->flags & WILCO_EC_FLAG_EXTENDED_DATA) - size = EC_MAILBOX_DATA_SIZE_EXTENDED; - else - size = EC_MAILBOX_DATA_SIZE; - /* Read back response */ rs = ec->data_buffer; checksum = cros_ec_lpc_io_bytes_mec(MEC_IO_READ, 0, - sizeof(*rs) + size, (u8 *)rs); + sizeof(*rs) + EC_MAILBOX_DATA_SIZE, + (u8 *)rs); if (checksum) { dev_dbg(ec->dev, "bad packet checksum 0x%02x\n", rs->checksum); return -EBADMSG; @@ -173,9 +162,9 @@ static int wilco_ec_transfer(struct wilco_ec_device *ec, return -EBADMSG; } - if (rs->data_size != size) { - dev_dbg(ec->dev, "unexpected packet size (%u != %zu)", - rs->data_size, size); + if (rs->data_size != EC_MAILBOX_DATA_SIZE) { + dev_dbg(ec->dev, "unexpected packet size (%u != %u)", + rs->data_size, EC_MAILBOX_DATA_SIZE); return -EMSGSIZE; } diff --git a/include/linux/platform_data/wilco-ec.h b/include/linux/platform_data/wilco-ec.h index af68fc0563cc..e3ce9ce49b11 100644 --- a/include/linux/platform_data/wilco-ec.h +++ b/include/linux/platform_data/wilco-ec.h @@ -13,12 +13,9 @@ /* Message flags for using the mailbox() interface */ #define WILCO_EC_FLAG_NO_RESPONSE BIT(0) /* EC does not respond */ -#define WILCO_EC_FLAG_EXTENDED_DATA BIT(1) /* EC returns 256 data bytes */ /* Normal commands have a maximum 32 bytes of data */ #define EC_MAILBOX_DATA_SIZE 32 -/* Extended commands have 256 bytes of response data */ -#define EC_MAILBOX_DATA_SIZE_EXTENDED 256 /** * struct wilco_ec_device - Wilco Embedded Controller handle. @@ -85,14 +82,12 @@ struct wilco_ec_response { * enum wilco_ec_msg_type - Message type to select a set of command codes. * @WILCO_EC_MSG_LEGACY: Legacy EC messages for standard EC behavior. * @WILCO_EC_MSG_PROPERTY: Get/Set/Sync EC controlled NVRAM property. - * @WILCO_EC_MSG_TELEMETRY_SHORT: 32 bytes of telemetry data provided by the EC. - * @WILCO_EC_MSG_TELEMETRY_LONG: 256 bytes of telemetry data provided by the EC. + * @WILCO_EC_MSG_TELEMETRY: Request telemetry data from the EC. */ enum wilco_ec_msg_type { WILCO_EC_MSG_LEGACY = 0x00f0, WILCO_EC_MSG_PROPERTY = 0x00f2, - WILCO_EC_MSG_TELEMETRY_SHORT = 0x00f5, - WILCO_EC_MSG_TELEMETRY_LONG = 0x00f6, + WILCO_EC_MSG_TELEMETRY = 0x00f5, }; /** -- cgit v1.2.3-59-g8ed1b From e15d92bee8184048e7419193263e62a0830cf365 Mon Sep 17 00:00:00 2001 From: Chengguang Xu Date: Mon, 20 May 2019 14:21:16 +0800 Subject: doc: ext2: update description of quota options for ext2 ext2 support user/group disk quota by specifying usrquota/grpquota option on mount, so fix the description in the doc properly. Signed-off-by: Chengguang Xu Signed-off-by: Jan Kara --- Documentation/filesystems/ext2.txt | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/ext2.txt b/Documentation/filesystems/ext2.txt index a19973a4dd1e..94c2cf0292f5 100644 --- a/Documentation/filesystems/ext2.txt +++ b/Documentation/filesystems/ext2.txt @@ -57,7 +57,13 @@ noacl Don't support POSIX ACLs. nobh Do not attach buffer_heads to file pagecache. -grpquota,noquota,quota,usrquota Quota options are silently ignored by ext2. +quota, usrquota Enable user disk quota support + (requires CONFIG_QUOTA). + +grpquota Enable group disk quota support + (requires CONFIG_QUOTA). + +noquota option ls silently ignored by ext2. Specification -- cgit v1.2.3-59-g8ed1b From 70ac79f5d1ef95e61b174e95192b3555a4caef2f Mon Sep 17 00:00:00 2001 From: Fabrizio Castro Date: Fri, 17 May 2019 10:26:29 +0100 Subject: dt-bindings: arm: renesas: Add HopeRun RZ/G2[M] boards This patch adds board HiHope RZ/G2M (the main board, powered by the R8A774A1) and board HiHope RZ/G2 EX (the expansion board that sits on top of the HiHope RZ/G2M). Both boards are made by Jiangsu HopeRun Software Co., Ltd. (a.k.a. HopeRun). Useful links: http://hihope.org/product/detail/rzg2 https://item.taobao.com/item.htm?spm=a2oq0.12575281.0.0.6bcf1debQpzkRS&ft=t&id=592177498472 http://www.hoperun.com/Cn/news/id/379 We already know that the HiHope RZ/G2 EX will also sit on the HiHope RZ/G2N, even though the HiHope RZ/G2N doesn't exist just yet. Signed-off-by: Fabrizio Castro Reviewed-by: Chris Paterson Reviewed-by: Rob Herring Signed-off-by: Simon Horman --- Documentation/devicetree/bindings/arm/renesas.yaml | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/renesas.yaml b/Documentation/devicetree/bindings/arm/renesas.yaml index 19f379863d50..08c923f8c257 100644 --- a/Documentation/devicetree/bindings/arm/renesas.yaml +++ b/Documentation/devicetree/bindings/arm/renesas.yaml @@ -106,6 +106,14 @@ properties: - description: RZ/G2M (R8A774A1) items: + - enum: + - hoperun,hihope-rzg2m # HopeRun HiHope RZ/G2M platform + - const: renesas,r8a774a1 + + - items: + - enum: + - hoperun,hihope-rzg2-ex # HopeRun expansion board for HiHope RZ/G2 platforms + - const: hoperun,hihope-rzg2m - const: renesas,r8a774a1 - description: RZ/G2E (R8A774C0) -- cgit v1.2.3-59-g8ed1b From 90fdbe8ab27047f7b9da57d1975c14a8d8f39370 Mon Sep 17 00:00:00 2001 From: "S.j. Wang" Date: Thu, 16 May 2019 11:40:56 +0000 Subject: ASoC: cs42xx8: add reset-gpios in binding document Add reset-gpios property, which is optional. Signed-off-by: Shengjiu Wang Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/cs42xx8.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/cs42xx8.txt b/Documentation/devicetree/bindings/sound/cs42xx8.txt index 8619a156d038..bbfe39347c20 100644 --- a/Documentation/devicetree/bindings/sound/cs42xx8.txt +++ b/Documentation/devicetree/bindings/sound/cs42xx8.txt @@ -14,6 +14,11 @@ Required properties: - VA-supply, VD-supply, VLS-supply, VLC-supply: power supplies for the device, as covered in Documentation/devicetree/bindings/regulator/regulator.txt +Optional properties: + + - reset-gpios : a GPIO spec to define which pin is connected to the chip's + !RESET pin + Example: cs42888: codec@48 { @@ -25,4 +30,5 @@ cs42888: codec@48 { VD-supply = <®_audio>; VLS-supply = <®_audio>; VLC-supply = <®_audio>; + reset-gpios = <&pca9557_b 1 GPIO_ACTIVE_LOW>; }; -- cgit v1.2.3-59-g8ed1b From f22558d701755f2f9cfdbd4a0862a58ef5fb1dbb Mon Sep 17 00:00:00 2001 From: Lubomir Rintel Date: Mon, 13 May 2019 09:56:32 +0200 Subject: dt-bindings: olpc,xo1.75-ec: Add OLPC XO-1.75 EC bindings The OLPC XO-1.75 Embedded Controller is a SPI master that uses extra signals for handshaking. It needs to know when is the slave (Linux) side's TX FIFO ready for transfer (the ready-gpio signal on the SPI controller node) and when does it wish to respond with a command (the cmd-gpio property). Signed-off-by: Lubomir Rintel Acked-by: Pavel Machek Reviewed-by: Rob Herring Signed-off-by: Andy Shevchenko --- .../devicetree/bindings/misc/olpc,xo1.75-ec.txt | 23 ++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.txt b/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.txt new file mode 100644 index 000000000000..8c4d649cdd8f --- /dev/null +++ b/Documentation/devicetree/bindings/misc/olpc,xo1.75-ec.txt @@ -0,0 +1,23 @@ +OLPC XO-1.75 Embedded Controller + +Required properties: +- compatible: Should be "olpc,xo1.75-ec". +- cmd-gpios: gpio specifier of the CMD pin + +The embedded controller requires the SPI controller driver to signal readiness +to receive a transfer (that is, when TX FIFO contains the response data) by +strobing the ACK pin with the ready signal. See the "ready-gpios" property of the +SSP binding as documented in: +. + +Example: + &ssp3 { + spi-slave; + ready-gpios = <&gpio 125 GPIO_ACTIVE_HIGH>; + + slave { + compatible = "olpc,xo1.75-ec"; + spi-cpha; + cmd-gpios = <&gpio 155 GPIO_ACTIVE_HIGH>; + }; + }; -- cgit v1.2.3-59-g8ed1b From 2f230f300497f695bec65439b20df3293eabf889 Mon Sep 17 00:00:00 2001 From: Dan Murphy Date: Mon, 6 May 2019 14:16:09 -0500 Subject: dt-bindings: mfd: LMU: Add the ramp up/down property Document the ramp-up and ramp-down property in the binding. Removing the "sec" from the property definition as seconds is implied. Signed-off-by: Dan Murphy Reviewed-by: Rob Herring Acked-by: Lee Jones Signed-off-by: Jacek Anaszewski --- Documentation/devicetree/bindings/mfd/ti-lmu.txt | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/ti-lmu.txt b/Documentation/devicetree/bindings/mfd/ti-lmu.txt index 86ca786d54fc..160eb0a5e21a 100644 --- a/Documentation/devicetree/bindings/mfd/ti-lmu.txt +++ b/Documentation/devicetree/bindings/mfd/ti-lmu.txt @@ -23,8 +23,14 @@ Required properties: 0x36 for LM3633, LM3697 0x63 for LM3695 -Optional property: +Optional properties: - enable-gpios: A GPIO specifier for hardware enable pin. + - ramp-up-us: Current ramping from one brightness level to + the a higher brightness level. + Range from 2048 us - 117.44 s + - ramp-down-us: Current ramping from one brightness level to + the a lower brightness level. + Range from 2048 us - 117.44 s Required node: - backlight: All LMU devices have backlight child nodes. @@ -90,7 +96,7 @@ lm3631@29 { lcd_bl { led-sources = <0 1>; - ramp-up-msec = <300>; + ramp-up-us = <300000>; }; }; }; @@ -152,15 +158,15 @@ lm3633@36 { main { label = "main_lcd"; led-sources = <1 2>; - ramp-up-msec = <500>; - ramp-down-msec = <500>; + ramp-up-us = <500000>; + ramp-down-us = <500000>; }; front { label = "front_lcd"; led-sources = <0>; - ramp-up-msec = <1000>; - ramp-down-msec = <0>; + ramp-up-us = <1000000>; + ramp-down-us = <0>; }; }; @@ -212,8 +218,8 @@ lm3697@36 { lcd { led-sources = <0 1 2>; - ramp-up-msec = <200>; - ramp-down-msec = <200>; + ramp-up-us = <200000>; + ramp-down-us = <200000>; }; }; -- cgit v1.2.3-59-g8ed1b From d0147554d004e7cc427f6cfecf871916e34e8b67 Mon Sep 17 00:00:00 2001 From: Dan Murphy Date: Mon, 6 May 2019 14:16:10 -0500 Subject: dt-bindings: mfd: LMU: Add ti,brightness-resolution Add ti,brightness-resolution to the TI LMU binding to define whether the device uses 8-bit brightness or 11-bit brightness. Signed-off-by: Dan Murphy Reviewed-by: Rob Herring Signed-off-by: Jacek Anaszewski --- Documentation/devicetree/bindings/mfd/ti-lmu.txt | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/ti-lmu.txt b/Documentation/devicetree/bindings/mfd/ti-lmu.txt index 160eb0a5e21a..e3efefb194c5 100644 --- a/Documentation/devicetree/bindings/mfd/ti-lmu.txt +++ b/Documentation/devicetree/bindings/mfd/ti-lmu.txt @@ -31,6 +31,16 @@ Optional properties: - ramp-down-us: Current ramping from one brightness level to the a lower brightness level. Range from 2048 us - 117.44 s + - ti,brightness-resolution - This determines whether to use 8 bit brightness + mode or 11 bit brightness mode. If this value is + not set the device is defaulted to the preferred + 8bit brightness mode per 7.3.4.1 of the data + sheet. This setting can either be in the parent + node or as part of the LED child nodes. This + is determined by the part itself if the strings + have a common brightness register or individual + brightness registers. + The values are 255 (8bit) or 2047 (11bit). Required node: - backlight: All LMU devices have backlight child nodes. @@ -217,6 +227,7 @@ lm3697@36 { compatible = "ti,lm3697-backlight"; lcd { + ti,brightness-resolution = <255>; led-sources = <0 1 2>; ramp-up-us = <200000>; ramp-down-us = <200000>; -- cgit v1.2.3-59-g8ed1b From bbc9be3ac8ab022061e7cfcc050ae02240144ba1 Mon Sep 17 00:00:00 2001 From: Ioana Ciornei Date: Tue, 26 Mar 2019 19:23:31 +0000 Subject: Documentation: DT: Add entry for DPAA2 console This patch adds a devicetree binding documentation for FSL's DPAA2 console. Signed-off-by: Ioana Ciornei Reviewed-by: Rob Herring Signed-off-by: Li Yang --- Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt | 11 +++++++++++ MAINTAINERS | 1 + 2 files changed, 12 insertions(+) create mode 100644 Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt b/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt new file mode 100644 index 000000000000..1442ba5d2d98 --- /dev/null +++ b/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt @@ -0,0 +1,11 @@ +DPAA2 console support + +Required properties: + + - compatible + Value type: + Definition: Must be "fsl,dpaa2-console". + - reg + Value type: + Definition: A standard property. Specifies the region where the MCFBA + (MC firmware base address) register can be found. diff --git a/MAINTAINERS b/MAINTAINERS index 5cfbea4ce575..5465fd8305eb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6404,6 +6404,7 @@ M: Li Yang L: linuxppc-dev@lists.ozlabs.org L: linux-arm-kernel@lists.infradead.org S: Maintained +F: Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt F: Documentation/devicetree/bindings/soc/fsl/ F: drivers/soc/fsl/ F: include/linux/fsl/ -- cgit v1.2.3-59-g8ed1b From 804898e8bc43080c9194ae7e1807bf0e995bad73 Mon Sep 17 00:00:00 2001 From: Chris Brandt Date: Wed, 15 May 2019 10:20:39 -0500 Subject: dt-bindings: rcar-gen3-phy-usb2: Document dr_mode Document the optional dr_mode property Signed-off-by: Chris Brandt Reviewed-by: Rob Herring Reviewed-by: Yoshihiro Shimoda Reviewed-by: Simon Horman Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt index d46188f450bf..64afd086e606 100644 --- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt +++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt @@ -46,6 +46,9 @@ channel as USB OTG: regulator will be managed during the PHY power on/off sequence. - renesas,no-otg-pins: boolean, specify when a board does not provide proper otg pins. +- dr_mode: string, indicates the working mode for the PHY. Can be "host", + "peripheral", or "otg". Should be set if otg controller is not used. + Example (R-Car H3): -- cgit v1.2.3-59-g8ed1b From b051c93746543385f398b6b8002a51e9d43143a6 Mon Sep 17 00:00:00 2001 From: Chris Brandt Date: Wed, 15 May 2019 10:20:40 -0500 Subject: dt-bindings: rcar-gen3-phy-usb2: Add r7s9210 support Document RZ/A2 (R7S9210) SoC bindings. Signed-off-by: Chris Brandt Reviewed-by: Rob Herring Reviewed-by: Yoshihiro Shimoda Reviewed-by: Simon Horman Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt index 64afd086e606..503a8cfb3184 100644 --- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt +++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt @@ -1,10 +1,12 @@ * Renesas R-Car generation 3 USB 2.0 PHY This file provides information on what the device node for the R-Car generation -3, RZ/G1C and RZ/G2 USB 2.0 PHY contain. +3, RZ/G1C, RZ/G2 and RZ/A2 USB 2.0 PHY contain. Required properties: -- compatible: "renesas,usb2-phy-r8a77470" if the device is a part of an R8A77470 +- compatible: "renesas,usb2-phy-r7s9210" if the device is a part of an R7S9210 + SoC. + "renesas,usb2-phy-r8a77470" if the device is a part of an R8A77470 SoC. "renesas,usb2-phy-r8a774a1" if the device is a part of an R8A774A1 SoC. @@ -20,8 +22,8 @@ Required properties: R8A77990 SoC. "renesas,usb2-phy-r8a77995" if the device is a part of an R8A77995 SoC. - "renesas,rcar-gen3-usb2-phy" for a generic R-Car Gen3 or RZ/G2 - compatible device. + "renesas,rcar-gen3-usb2-phy" for a generic R-Car Gen3, RZ/G2 or + RZ/A2 compatible device. When compatible with the generic version, nodes must list the SoC-specific version corresponding to the platform first -- cgit v1.2.3-59-g8ed1b From 6e9aed4ed4ca129510fcb1af495391d4717246d6 Mon Sep 17 00:00:00 2001 From: Chris Brandt Date: Wed, 15 May 2019 10:20:45 -0500 Subject: dt-bindings: usb: renesas_usbhs: Add support for r7s9210 Add support for r7s9210 (RZ/A2M) SoC Signed-off-by: Chris Brandt Reviewed-by: Rob Herring Reviewed-by: Yoshihiro Shimoda Reviewed-by: Simon Horman Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/usb/renesas_usbhs.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt index b8acc2a994a8..e39255ea6e4f 100644 --- a/Documentation/devicetree/bindings/usb/renesas_usbhs.txt +++ b/Documentation/devicetree/bindings/usb/renesas_usbhs.txt @@ -20,9 +20,11 @@ Required properties: - "renesas,usbhs-r8a77990" for r8a77990 (R-Car E3) compatible device - "renesas,usbhs-r8a77995" for r8a77995 (R-Car D3) compatible device - "renesas,usbhs-r7s72100" for r7s72100 (RZ/A1) compatible device + - "renesas,usbhs-r7s9210" for r7s9210 (RZ/A2) compatible device - "renesas,rcar-gen2-usbhs" for R-Car Gen2 or RZ/G1 compatible devices - "renesas,rcar-gen3-usbhs" for R-Car Gen3 or RZ/G2 compatible devices - "renesas,rza1-usbhs" for RZ/A1 compatible device + - "renesas,rza2-usbhs" for RZ/A2 compatible device When compatible with the generic version, nodes must list the SoC-specific version corresponding to the platform first followed -- cgit v1.2.3-59-g8ed1b From 221fb7268d67c0867a93f23586bd53c3c3969eee Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Mon, 20 May 2019 14:22:25 -0700 Subject: Documentation/networking: fix af_xdp.rst Sphinx warnings MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fix Sphinx warnings in Documentation/networking/af_xdp.rst by adding indentation: Documentation/networking/af_xdp.rst:319: WARNING: Literal block expected; none found. Documentation/networking/af_xdp.rst:326: WARNING: Literal block expected; none found. Fixes: 0f4a9b7d4ecb ("xsk: add FAQ to facilitate for first time users") Signed-off-by: Randy Dunlap Cc: Magnus Karlsson Cc: Daniel Borkmann Acked-by: Björn Töpel Signed-off-by: Daniel Borkmann --- Documentation/networking/af_xdp.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/af_xdp.rst b/Documentation/networking/af_xdp.rst index e14d7d40fc75..50bccbf68308 100644 --- a/Documentation/networking/af_xdp.rst +++ b/Documentation/networking/af_xdp.rst @@ -316,16 +316,16 @@ A: When a netdev of a physical NIC is initialized, Linux usually all the traffic, you can force the netdev to only have 1 queue, queue id 0, and then bind to queue 0. You can use ethtool to do this:: - sudo ethtool -L combined 1 + sudo ethtool -L combined 1 If you want to only see part of the traffic, you can program the NIC through ethtool to filter out your traffic to a single queue id that you can bind your XDP socket to. Here is one example in which UDP traffic to and from port 4242 are sent to queue 2:: - sudo ethtool -N rx-flow-hash udp4 fn - sudo ethtool -N flow-type udp4 src-port 4242 dst-port \ - 4242 action 2 + sudo ethtool -N rx-flow-hash udp4 fn + sudo ethtool -N flow-type udp4 src-port 4242 dst-port \ + 4242 action 2 A number of other ways are possible all up to the capabilitites of the NIC you have. -- cgit v1.2.3-59-g8ed1b From 0f202f69a16b9a687911202083c37636ad73c77e Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Fri, 17 May 2019 10:27:22 -0500 Subject: dt-bindings: arm: amlogic: Move 'amlogic, meson-gx-ao-secure' binding to its own file It is best practice to have 1 binding per file, so board level bindings should be separate for various misc SoC bindings. Cc: Mark Rutland Cc: Carlo Caione Cc: Kevin Hilman Cc: devicetree@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-amlogic@lists.infradead.org Signed-off-by: Rob Herring Acked-by: Neil Armstrong Acked-by: Kevin Hilman Signed-off-by: Kevin Hilman --- Documentation/devicetree/bindings/arm/amlogic.txt | 29 ---------------------- .../arm/amlogic/amlogic,meson-gx-ao-secure.txt | 28 +++++++++++++++++++++ 2 files changed, 28 insertions(+), 29 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt index 061f7b98a07f..5f650248b18e 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.txt +++ b/Documentation/devicetree/bindings/arm/amlogic.txt @@ -111,32 +111,3 @@ Board compatible values (alphabetically, grouped by SoC): - "amlogic,u200" (Meson g12a s905d2) - "amediatech,x96-max" (Meson g12a s905x2) - "seirobotics,sei510" (Meson g12a s905x2) - -Amlogic Meson Firmware registers Interface ------------------------------------------- - -The Meson SoCs have a register bank with status and data shared with the -secure firmware. - -Required properties: - - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-ao-secure", "syscon" - -Properties should indentify components of this register interface : - -Meson GX SoC Information ------------------------- -A firmware register encodes the SoC type, package and revision information on -the Meson GX SoCs. -If present, the following property should be added : - -Optional properties: - - amlogic,has-chip-id: If present, the interface gives the current SoC version. - -Example -------- - -ao-secure@140 { - compatible = "amlogic,meson-gx-ao-secure", "syscon"; - reg = <0x0 0x140 0x0 0x140>; - amlogic,has-chip-id; -}; diff --git a/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt new file mode 100644 index 000000000000..c67d9f48fb91 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/amlogic/amlogic,meson-gx-ao-secure.txt @@ -0,0 +1,28 @@ +Amlogic Meson Firmware registers Interface +------------------------------------------ + +The Meson SoCs have a register bank with status and data shared with the +secure firmware. + +Required properties: + - compatible: For Meson GX SoCs, must be "amlogic,meson-gx-ao-secure", "syscon" + +Properties should indentify components of this register interface : + +Meson GX SoC Information +------------------------ +A firmware register encodes the SoC type, package and revision information on +the Meson GX SoCs. +If present, the following property should be added : + +Optional properties: + - amlogic,has-chip-id: If present, the interface gives the current SoC version. + +Example +------- + +ao-secure@140 { + compatible = "amlogic,meson-gx-ao-secure", "syscon"; + reg = <0x0 0x140 0x0 0x140>; + amlogic,has-chip-id; +}; -- cgit v1.2.3-59-g8ed1b From c0c752d8c6b3dd78b3e7951453bc43be880dcd08 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Fri, 17 May 2019 10:27:23 -0500 Subject: dt-bindings: arm: Convert Amlogic board/soc bindings to json-schema Convert Amlogic SoC bindings to DT schema format using json-schema. Cc: Carlo Caione Cc: Kevin Hilman Cc: Mark Rutland Cc: devicetree@vger.kernel.org Signed-off-by: Rob Herring Reviewed-by: Neil Armstrong [khilman: updated maninainers] Signed-off-by: Kevin Hilman --- Documentation/devicetree/bindings/arm/amlogic.txt | 113 ----------------- Documentation/devicetree/bindings/arm/amlogic.yaml | 138 +++++++++++++++++++++ 2 files changed, 138 insertions(+), 113 deletions(-) delete mode 100644 Documentation/devicetree/bindings/arm/amlogic.txt create mode 100644 Documentation/devicetree/bindings/arm/amlogic.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt b/Documentation/devicetree/bindings/arm/amlogic.txt deleted file mode 100644 index 5f650248b18e..000000000000 --- a/Documentation/devicetree/bindings/arm/amlogic.txt +++ /dev/null @@ -1,113 +0,0 @@ -Amlogic MesonX device tree bindings -------------------------------------------- - -Work in progress statement: - -Device tree files and bindings applying to Amlogic SoCs and boards are -considered "unstable". Any Amlogic device tree binding may change at -any time. Be sure to use a device tree binary and a kernel image -generated from the same source tree. - -Please refer to Documentation/devicetree/bindings/ABI.txt for a definition of a -stable binding/ABI. - ---------------------------------------------------------------- - -Boards with the Amlogic Meson6 SoC shall have the following properties: - Required root node property: - compatible: "amlogic,meson6" - -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"; - -Boards with the Amlogic Meson8m2 SoC shall have the following properties: - Required root node property: - compatible: "amlogic,meson8m2"; - -Boards with the Amlogic Meson GXBaby SoC shall have the following properties: - Required root node property: - compatible: "amlogic,meson-gxbb"; - -Boards with the Amlogic Meson GXL S905X SoC shall have the following properties: - Required root node property: - compatible: "amlogic,s905x", "amlogic,meson-gxl"; - -Boards with the Amlogic Meson GXL S905D SoC shall have the following properties: - Required root node property: - compatible: "amlogic,s905d", "amlogic,meson-gxl"; - -Boards with the Amlogic Meson GXL S805X SoC shall have the following properties: - Required root node property: - compatible: "amlogic,s805x", "amlogic,meson-gxl"; - -Boards with the Amlogic Meson GXL S905W SoC shall have the following properties: - Required root node property: - compatible: "amlogic,s905w", "amlogic,meson-gxl"; - -Boards with the Amlogic Meson GXM S912 SoC shall have the following properties: - Required root node property: - compatible: "amlogic,s912", "amlogic,meson-gxm"; - -Boards with the Amlogic Meson AXG A113D SoC shall have the following properties: - Required root node property: - compatible: "amlogic,a113d", "amlogic,meson-axg"; - -Boards with the Amlogic Meson G12A S905D2 SoC shall have the following properties: - Required root node property: - compatible: "amlogic,g12a"; - -Board compatible values (alphabetically, grouped by SoC): - - - "geniatech,atv1200" (Meson6) - - - "minix,neo-x8" (Meson8) - - - "endless,ec100" (Meson8b) - - "hardkernel,odroid-c1" (Meson8b) - - "tronfy,mxq" (Meson8b) - - - "tronsmart,mxiii-plus" (Meson8m2) - - - "amlogic,p200" (Meson gxbb) - - "amlogic,p201" (Meson gxbb) - - "friendlyarm,nanopi-k2" (Meson gxbb) - - "hardkernel,odroid-c2" (Meson gxbb) - - "nexbox,a95x" (Meson gxbb or Meson gxl s905x) - - "tronsmart,vega-s95-pro", "tronsmart,vega-s95" (Meson gxbb) - - "tronsmart,vega-s95-meta", "tronsmart,vega-s95" (Meson gxbb) - - "tronsmart,vega-s95-telos", "tronsmart,vega-s95" (Meson gxbb) - - "wetek,hub" (Meson gxbb) - - "wetek,play2" (Meson gxbb) - - - "amlogic,p212" (Meson gxl s905x) - - "hwacom,amazetv" (Meson gxl s905x) - - "khadas,vim" (Meson gxl s905x) - - "libretech,cc" (Meson gxl s905x) - - - "amlogic,p230" (Meson gxl s905d) - - "amlogic,p231" (Meson gxl s905d) - - "phicomm,n1" (Meson gxl s905d) - - - "amlogic,p241" (Meson gxl s805x) - - "libretech,aml-s805x-ac" (Meson gxl s805x) - - - "amlogic,p281" (Meson gxl s905w) - - "oranth,tx3-mini" (Meson gxl s905w) - - - "amlogic,q200" (Meson gxm s912) - - "amlogic,q201" (Meson gxm s912) - - "khadas,vim2" (Meson gxm s912) - - "kingnovel,r-box-pro" (Meson gxm S912) - - "nexbox,a1" (Meson gxm s912) - - "tronsmart,vega-s96" (Meson gxm s912) - - - "amlogic,s400" (Meson axg a113d) - - - "amlogic,u200" (Meson g12a s905d2) - - "amediatech,x96-max" (Meson g12a s905x2) - - "seirobotics,sei510" (Meson g12a s905x2) diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml new file mode 100644 index 000000000000..a0dd12be4de4 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml @@ -0,0 +1,138 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/amlogic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Amlogic MesonX device tree bindings + +maintainers: + - Kevin Hilman + +description: |+ + Work in progress statement: + + Device tree files and bindings applying to Amlogic SoCs and boards are + considered "unstable". Any Amlogic device tree binding may change at + any time. Be sure to use a device tree binary and a kernel image + generated from the same source tree. + + Please refer to Documentation/devicetree/bindings/ABI.txt for a definition of a + stable binding/ABI. + +properties: + $nodename: + const: '/' + compatible: + oneOf: + - description: Boards with the Amlogic Meson6 SoC + items: + - enum: + - geniatech,atv1200 + - const: amlogic,meson6 + + - description: Boards with the Amlogic Meson8 SoC + items: + - enum: + - minix,neo-x8 + - const: amlogic,meson8 + + - description: Boards with the Amlogic Meson8m2 SoC + items: + - enum: + - tronsmart,mxiii-plus + - const: amlogic,meson8m2 + + - description: Boards with the Amlogic Meson8b SoC + items: + - enum: + - endless,ec100 + - hardkernel,odroid-c1 + - tronfy,mxq + - const: amlogic,meson8b + + - description: Boards with the Amlogic Meson GXBaby SoC + items: + - enum: + - amlogic,p200 + - amlogic,p201 + - friendlyarm,nanopi-k2 + - hardkernel,odroid-c2 + - nexbox,a95x + - wetek,hub + - wetek,play2 + - const: amlogic,meson-gxbb + + - description: Tronsmart Vega S95 devices + items: + - enum: + - tronsmart,vega-s95-pro + - tronsmart,vega-s95-meta + - tronsmart,vega-s95-telos + - const: tronsmart,vega-s95 + - const: amlogic,meson-gxbb + + - description: Boards with the Amlogic Meson GXL S805X SoC + items: + - enum: + - amlogic,p241 + - libretech,aml-s805x-ac + - const: amlogic,s805x + - const: amlogic,meson-gxl + + - description: Boards with the Amlogic Meson GXL S905W SoC + items: + - enum: + - amlogic,p281 + - oranth,tx3-mini + - const: amlogic,s905w + - const: amlogic,meson-gxl + + - description: Boards with the Amlogic Meson GXL S905X SoC + items: + - enum: + - amediatech,x96-max + - amlogic,p212 + - hwacom,amazetv + - khadas,vim + - libretech,cc + - nexbox,a95x + - seirobotics,sei510 + - const: amlogic,s905x + - const: amlogic,meson-gxl + + - description: Boards with the Amlogic Meson GXL S905D SoC + items: + - enum: + - amlogic,p230 + - amlogic,p231 + - phicomm,n1 + - const: amlogic,s905d + - const: amlogic,meson-gxl + + - description: Boards with the Amlogic Meson GXM S912 SoC + items: + - enum: + - amlogic,q200 + - amlogic,q201 + - khadas,vim2 + - kingnovel,r-box-pro + - nexbox,a1 + - tronsmart,vega-s96 + - const: amlogic,s912 + - const: amlogic,meson-gxm + + - description: Boards with the Amlogic Meson AXG A113D SoC + items: + - enum: + - amlogic,s400 + - const: amlogic,a113d + - const: amlogic,meson-axg + + - description: Boards with the Amlogic Meson G12A S905D2 SoC + items: + - enum: + - amlogic,u200 + - const: amlogic,g12a + +... -- cgit v1.2.3-59-g8ed1b From 46f4050a6587ea3e59e6f47f06513c00689b9d40 Mon Sep 17 00:00:00 2001 From: Charles Keepax Date: Tue, 21 May 2019 11:04:37 +0100 Subject: regulator: arizona: Update device tree binding to support Madera CODECs The Arizona regulator drivers are now also used by the Cirrus Logic Madera audio CODECs, update the binding document to link to the primary binding document for these as well as the existing Arizona document. Signed-off-by: Charles Keepax Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/regulator/arizona-regulator.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/arizona-regulator.txt b/Documentation/devicetree/bindings/regulator/arizona-regulator.txt index 443564d7784f..69bf41949b01 100644 --- a/Documentation/devicetree/bindings/regulator/arizona-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/arizona-regulator.txt @@ -5,7 +5,8 @@ of analogue I/O. This document lists regulator specific bindings, see the primary binding document: - ../mfd/arizona.txt + For Wolfson Microelectronic Arizona codecs: ../mfd/arizona.txt + For Cirrus Logic Madera codecs: ../mfd/madera.txt Optional properties: - wlf,ldoena : GPIO specifier for the GPIO controlling LDOENA -- cgit v1.2.3-59-g8ed1b From 0a1b929356830257568f9547e173f0e7498060ea Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Mon, 20 May 2019 16:50:33 +0200 Subject: spi: Add YAML schemas for the generic SPI options The SPI controllers have a bunch of generic options that are needed in a device tree. Add a YAML schemas for those. Signed-off-by: Maxime Ripard Reviewed-by: Rob Herring Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/spi-bus.txt | 112 +------------- .../devicetree/bindings/spi/spi-controller.yaml | 161 +++++++++++++++++++++ 2 files changed, 162 insertions(+), 111 deletions(-) create mode 100644 Documentation/devicetree/bindings/spi/spi-controller.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/spi-bus.txt b/Documentation/devicetree/bindings/spi/spi-bus.txt index 1f6e86f787ef..e07783505498 100644 --- a/Documentation/devicetree/bindings/spi/spi-bus.txt +++ b/Documentation/devicetree/bindings/spi/spi-bus.txt @@ -1,111 +1 @@ -SPI (Serial Peripheral Interface) busses - -SPI busses can be described with a node for the SPI controller device -and a set of child nodes for each SPI slave on the bus. The system's SPI -controller may be described for use in SPI master mode or in SPI slave mode, -but not for both at the same time. - -The SPI controller node requires the following properties: -- compatible - Name of SPI bus controller following generic names - recommended practice. - -In master mode, the SPI controller node requires the following additional -properties: -- #address-cells - number of cells required to define a chip select - address on the SPI bus. -- #size-cells - should be zero. - -In slave mode, the SPI controller node requires one additional property: -- spi-slave - Empty property. - -No other properties are required in the SPI bus node. It is assumed -that a driver for an SPI bus device will understand that it is an SPI bus. -However, the binding does not attempt to define the specific method for -assigning chip select numbers. Since SPI chip select configuration is -flexible and non-standardized, it is left out of this binding with the -assumption that board specific platform code will be used to manage -chip selects. Individual drivers can define additional properties to -support describing the chip select layout. - -Optional properties (master mode only): -- cs-gpios - gpios chip select. -- num-cs - total number of chipselects. - -If cs-gpios is used the number of chip selects will be increased automatically -with max(cs-gpios > hw cs). - -So if for example the controller has 2 CS lines, and the cs-gpios -property looks like this: - -cs-gpios = <&gpio1 0 0>, <0>, <&gpio1 1 0>, <&gpio1 2 0>; - -Then it should be configured so that num_chipselect = 4 with the -following mapping: - -cs0 : &gpio1 0 0 -cs1 : native -cs2 : &gpio1 1 0 -cs3 : &gpio1 2 0 - - -SPI slave nodes must be children of the SPI controller node. - -In master mode, one or more slave nodes (up to the number of chip selects) can -be present. Required properties are: -- compatible - Name of SPI device following generic names recommended - practice. -- reg - Chip select address of device. -- spi-max-frequency - Maximum SPI clocking speed of device in Hz. - -In slave mode, the (single) slave node is optional. -If present, it must be called "slave". Required properties are: -- compatible - Name of SPI device following generic names recommended - practice. - -All slave nodes can contain the following optional properties: -- spi-cpol - Empty property indicating device requires inverse clock - polarity (CPOL) mode. -- spi-cpha - Empty property indicating device requires shifted clock - phase (CPHA) mode. -- spi-cs-high - Empty property indicating device requires chip select - active high. -- spi-3wire - Empty property indicating device requires 3-wire mode. -- spi-lsb-first - Empty property indicating device requires LSB first mode. -- spi-tx-bus-width - The bus width (number of data wires) that is used for MOSI. - Defaults to 1 if not present. -- spi-rx-bus-width - The bus width (number of data wires) that is used for MISO. - Defaults to 1 if not present. -- spi-rx-delay-us - Microsecond delay after a read transfer. -- spi-tx-delay-us - Microsecond delay after a write transfer. - -Some SPI controllers and devices support Dual and Quad SPI transfer mode. -It allows data in the SPI system to be transferred using 2 wires (DUAL) or 4 -wires (QUAD). -Now the value that spi-tx-bus-width and spi-rx-bus-width can receive is -only 1 (SINGLE), 2 (DUAL) and 4 (QUAD). -Dual/Quad mode is not allowed when 3-wire mode is used. - -If a gpio chipselect is used for the SPI slave the gpio number will be passed -via the SPI master node cs-gpios property. - -SPI example for an MPC5200 SPI bus: - spi@f00 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi"; - reg = <0xf00 0x20>; - interrupts = <2 13 0 2 14 0>; - interrupt-parent = <&mpc5200_pic>; - - ethernet-switch@0 { - compatible = "micrel,ks8995m"; - spi-max-frequency = <1000000>; - reg = <0>; - }; - - codec@1 { - compatible = "ti,tlv320aic26"; - spi-max-frequency = <100000>; - reg = <1>; - }; - }; +This file has moved to spi-controller.yaml. diff --git a/Documentation/devicetree/bindings/spi/spi-controller.yaml b/Documentation/devicetree/bindings/spi/spi-controller.yaml new file mode 100644 index 000000000000..876c0623f322 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml @@ -0,0 +1,161 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/spi-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SPI Controller Generic Binding + +maintainers: + - Mark Brown + +description: | + SPI busses can be described with a node for the SPI controller device + and a set of child nodes for each SPI slave on the bus. The system SPI + controller may be described for use in SPI master mode or in SPI slave mode, + but not for both at the same time. + +properties: + $nodename: + pattern: "^spi(@.*|-[0-9a-f])*$" + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + cs-gpios: + description: | + GPIOs used as chip selects. + If that property is used, the number of chip selects will be + increased automatically with max(cs-gpios, hardware chip selects). + + So if, for example, the controller has 2 CS lines, and the + cs-gpios looks like this + cs-gpios = <&gpio1 0 0>, <0>, <&gpio1 1 0>, <&gpio1 2 0>; + + Then it should be configured so that num_chipselect = 4, with + the following mapping + cs0 : &gpio1 0 0 + cs1 : native + cs2 : &gpio1 1 0 + cs3 : &gpio1 2 0 + + num-cs: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Total number of chip selects. + + spi-slave: + $ref: /schemas/types.yaml#/definitions/flag + description: + The SPI controller acts as a slave, instead of a master. + +patternProperties: + "^slave$": + type: object + + properties: + compatible: + description: + Compatible of the SPI device. + + required: + - compatible + + "^.*@[0-9a-f]+$": + type: object + + properties: + compatible: + description: + Compatible of the SPI device. + + reg: + maxItems: 1 + minimum: 0 + maximum: 256 + description: + Chip select used by the device. + + spi-3wire: + $ref: /schemas/types.yaml#/definitions/flag + description: + The device requires 3-wire mode. + + spi-cpha: + $ref: /schemas/types.yaml#/definitions/flag + description: + The device requires shifted clock phase (CPHA) mode. + + spi-cpol: + $ref: /schemas/types.yaml#/definitions/flag + description: + The device requires inverse clock polarity (CPOL) mode. + + spi-cs-high: + $ref: /schemas/types.yaml#/definitions/flag + description: + The device requires the chip select active high. + + spi-lsb-first: + $ref: /schemas/types.yaml#/definitions/flag + description: + The device requires the LSB first mode. + + spi-max-frequency: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Maximum SPI clocking speed of the device in Hz. + + spi-rx-bus-width: + allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 + - enum: [ 1, 2, 4 ] + - default: 1 + description: + Bus width to the SPI bus used for MISO. + + spi-rx-delay-us: + description: + Delay, in microseconds, after a read transfer. + + spi-tx-bus-width: + allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 + - enum: [ 1, 2, 4 ] + - default: 1 + description: + Bus width to the SPI bus used for MOSI. + + spi-tx-delay-us: + description: + Delay, in microseconds, after a write transfer. + + required: + - compatible + - reg + +examples: + - | + spi@f00 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "fsl,mpc5200b-spi","fsl,mpc5200-spi"; + reg = <0xf00 0x20>; + interrupts = <2 13 0 2 14 0>; + interrupt-parent = <&mpc5200_pic>; + + ethernet-switch@0 { + compatible = "micrel,ks8995m"; + spi-max-frequency = <1000000>; + reg = <0>; + }; + + codec@1 { + compatible = "ti,tlv320aic26"; + spi-max-frequency = <100000>; + reg = <1>; + }; + }; -- cgit v1.2.3-59-g8ed1b From 3133f5c24305c31ef2805a7eb05fc18a664836d3 Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Mon, 20 May 2019 16:50:34 +0200 Subject: spi: sun4i: Add YAML schemas Switch the DT binding to a YAML schema to enable the DT validation. Signed-off-by: Maxime Ripard Reviewed-by: Rob Herring Signed-off-by: Mark Brown --- .../bindings/spi/allwinner,sun4i-a10-spi.yaml | 86 ++++++++++++++++++++++ .../devicetree/bindings/spi/spi-sun4i.txt | 23 ------ 2 files changed, 86 insertions(+), 23 deletions(-) create mode 100644 Documentation/devicetree/bindings/spi/allwinner,sun4i-a10-spi.yaml delete mode 100644 Documentation/devicetree/bindings/spi/spi-sun4i.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/allwinner,sun4i-a10-spi.yaml b/Documentation/devicetree/bindings/spi/allwinner,sun4i-a10-spi.yaml new file mode 100644 index 000000000000..c374fd4923a6 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/allwinner,sun4i-a10-spi.yaml @@ -0,0 +1,86 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/allwinner,sun4i-a10-spi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner A10 SPI Controller Device Tree Bindings + +allOf: + - $ref: "spi-controller.yaml" + +maintainers: + - Chen-Yu Tsai + - Maxime Ripard + +properties: + "#address-cells": true + "#size-cells": true + + compatible: + const: allwinner,sun4i-a10-spi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Bus Clock + - description: Module Clock + + clock-names: + items: + - const: ahb + - const: mod + + dmas: + items: + - description: RX DMA Channel + - description: TX DMA Channel + + dma-names: + items: + - const: rx + - const: tx + + num-cs: true + +patternProperties: + "^.*@[0-9a-f]+": + properties: + reg: + items: + minimum: 0 + maximum: 4 + + spi-rx-bus-width: + const: 1 + + spi-tx-bus-width: + const: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + spi1: spi@1c06000 { + compatible = "allwinner,sun4i-a10-spi"; + reg = <0x01c06000 0x1000>; + interrupts = <11>; + clocks = <&ahb_gates 21>, <&spi1_clk>; + clock-names = "ahb", "mod"; + #address-cells = <1>; + #size-cells = <0>; + }; + +... diff --git a/Documentation/devicetree/bindings/spi/spi-sun4i.txt b/Documentation/devicetree/bindings/spi/spi-sun4i.txt deleted file mode 100644 index c75d604a8290..000000000000 --- a/Documentation/devicetree/bindings/spi/spi-sun4i.txt +++ /dev/null @@ -1,23 +0,0 @@ -Allwinner A10 SPI controller - -Required properties: -- compatible: Should be "allwinner,sun4-a10-spi". -- reg: Should contain register location and length. -- interrupts: Should contain interrupt. -- clocks: phandle to the clocks feeding the SPI controller. Two are - needed: - - "ahb": the gated AHB parent clock - - "mod": the parent module clock -- clock-names: Must contain the clock names described just above - -Example: - -spi1: spi@1c06000 { - compatible = "allwinner,sun4i-a10-spi"; - reg = <0x01c06000 0x1000>; - interrupts = <11>; - clocks = <&ahb_gates 21>, <&spi1_clk>; - clock-names = "ahb", "mod"; - #address-cells = <1>; - #size-cells = <0>; -}; -- cgit v1.2.3-59-g8ed1b From 101e6fce89b4707429185527e15d97c7e8f62ec5 Mon Sep 17 00:00:00 2001 From: Maxime Ripard Date: Mon, 20 May 2019 16:50:35 +0200 Subject: spi: sun6i: Add YAML schemas Switch the DT binding to a YAML schema to enable the DT validation. Signed-off-by: Maxime Ripard Reviewed-by: Rob Herring Signed-off-by: Mark Brown --- .../bindings/spi/allwinner,sun6i-a31-spi.yaml | 106 +++++++++++++++++++++ .../devicetree/bindings/spi/spi-sun6i.txt | 44 --------- 2 files changed, 106 insertions(+), 44 deletions(-) create mode 100644 Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml delete mode 100644 Documentation/devicetree/bindings/spi/spi-sun6i.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml b/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml new file mode 100644 index 000000000000..bda7a5befd8b --- /dev/null +++ b/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml @@ -0,0 +1,106 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/allwinner,sun6i-a31-spi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Allwinner A31 SPI Controller Device Tree Bindings + +allOf: + - $ref: "spi-controller.yaml" + +maintainers: + - Chen-Yu Tsai + - Maxime Ripard + +properties: + "#address-cells": true + "#size-cells": true + + compatible: + enum: + - allwinner,sun6i-a31-spi + - allwinner,sun8i-h3-spi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Bus Clock + - description: Module Clock + + clock-names: + items: + - const: ahb + - const: mod + + resets: + maxItems: 1 + + dmas: + items: + - description: RX DMA Channel + - description: TX DMA Channel + + dma-names: + items: + - const: rx + - const: tx + + num-cs: true + +patternProperties: + "^.*@[0-9a-f]+": + properties: + reg: + items: + minimum: 0 + maximum: 4 + + spi-rx-bus-width: + const: 1 + + spi-tx-bus-width: + const: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + spi1: spi@1c69000 { + compatible = "allwinner,sun6i-a31-spi"; + reg = <0x01c69000 0x1000>; + interrupts = <0 66 4>; + clocks = <&ahb1_gates 21>, <&spi1_clk>; + clock-names = "ahb", "mod"; + resets = <&ahb1_rst 21>; + #address-cells = <1>; + #size-cells = <0>; + }; + + - | + spi0: spi@1c68000 { + compatible = "allwinner,sun8i-h3-spi"; + reg = <0x01c68000 0x1000>; + interrupts = <0 65 4>; + clocks = <&ccu 30>, <&ccu 82>; + clock-names = "ahb", "mod"; + dmas = <&dma 23>, <&dma 23>; + dma-names = "rx", "tx"; + resets = <&ccu 15>; + #address-cells = <1>; + #size-cells = <0>; + }; + +... diff --git a/Documentation/devicetree/bindings/spi/spi-sun6i.txt b/Documentation/devicetree/bindings/spi/spi-sun6i.txt deleted file mode 100644 index 435a8e0731ac..000000000000 --- a/Documentation/devicetree/bindings/spi/spi-sun6i.txt +++ /dev/null @@ -1,44 +0,0 @@ -Allwinner A31/H3 SPI controller - -Required properties: -- compatible: Should be "allwinner,sun6i-a31-spi" or "allwinner,sun8i-h3-spi". -- reg: Should contain register location and length. -- interrupts: Should contain interrupt. -- clocks: phandle to the clocks feeding the SPI controller. Two are - needed: - - "ahb": the gated AHB parent clock - - "mod": the parent module clock -- clock-names: Must contain the clock names described just above -- resets: phandle to the reset controller asserting this device in - reset - -Optional properties: -- dmas: DMA specifiers for rx and tx dma. See the DMA client binding, - Documentation/devicetree/bindings/dma/dma.txt -- dma-names: DMA request names should include "rx" and "tx" if present. - -Example: - -spi1: spi@1c69000 { - compatible = "allwinner,sun6i-a31-spi"; - reg = <0x01c69000 0x1000>; - interrupts = <0 66 4>; - clocks = <&ahb1_gates 21>, <&spi1_clk>; - clock-names = "ahb", "mod"; - resets = <&ahb1_rst 21>; -}; - -spi0: spi@1c68000 { - compatible = "allwinner,sun8i-h3-spi"; - reg = <0x01c68000 0x1000>; - interrupts = ; - clocks = <&ccu CLK_BUS_SPI0>, <&ccu CLK_SPI0>; - clock-names = "ahb", "mod"; - dmas = <&dma 23>, <&dma 23>; - dma-names = "rx", "tx"; - pinctrl-names = "default"; - pinctrl-0 = <&spi0_pins>; - resets = <&ccu RST_BUS_SPI0>; - #address-cells = <1>; - #size-cells = <0>; -}; -- cgit v1.2.3-59-g8ed1b From 7ef5f7dd2a07f7460ce900818cc4cd8222daeebe Mon Sep 17 00:00:00 2001 From: Bjorn Andersson Date: Thu, 9 May 2019 21:34:14 -0700 Subject: dt-bindings: remoteproc: Rename and amend Hexagon v56 binding The SDM845 Audio DSP peripheral image loader binding describes the properties needed to load and boot firmware on a Hexagon v56. Rename the file and add the Compute DSP (CDSP) found in QCS404 to the binding. Reviewed-by: Rob Herring Reviewed-by: Vinod Koul Signed-off-by: Bjorn Andersson --- .../bindings/remoteproc/qcom,adsp-pil.txt | 125 ------------------ .../bindings/remoteproc/qcom,hexagon-v56.txt | 140 +++++++++++++++++++++ 2 files changed, 140 insertions(+), 125 deletions(-) delete mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,adsp-pil.txt create mode 100644 Documentation/devicetree/bindings/remoteproc/qcom,hexagon-v56.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp-pil.txt b/Documentation/devicetree/bindings/remoteproc/qcom,adsp-pil.txt deleted file mode 100644 index 66af2c30944f..000000000000 --- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp-pil.txt +++ /dev/null @@ -1,125 +0,0 @@ -Qualcomm Technology Inc. ADSP Peripheral Image Loader - -This document defines the binding for a component that loads and boots firmware -on the Qualcomm Technology Inc. ADSP Hexagon core. - -- compatible: - Usage: required - Value type: - Definition: must be one of: - "qcom,sdm845-adsp-pil" - -- reg: - Usage: required - Value type: - Definition: must specify the base address and size of the qdsp6ss register - -- interrupts-extended: - Usage: required - Value type: - Definition: must list the watchdog, fatal IRQs ready, handover and - stop-ack IRQs - -- interrupt-names: - Usage: required - Value type: - Definition: must be "wdog", "fatal", "ready", "handover", "stop-ack" - -- clocks: - Usage: required - Value type: - Definition: List of 8 phandle and clock specifier pairs for the adsp. - -- clock-names: - Usage: required - Value type: - Definition: List of clock input name strings sorted in the same - order as the clocks property. Definition must have - "xo", "sway_cbcr", "lpass_ahbs_aon_cbcr", - "lpass_ahbm_aon_cbcr", "qdsp6ss_xo", "qdsp6ss_sleep" - and "qdsp6ss_core". - -- power-domains: - Usage: required - Value type: - Definition: reference to cx power domain node. - -- resets: - Usage: required - Value type: - Definition: reference to the list of 2 reset-controller for the adsp. - -- reset-names: - Usage: required - Value type: - Definition: must be "pdc_sync" and "cc_lpass" - -- qcom,halt-regs: - Usage: required - Value type: - Definition: a phandle reference to a syscon representing TCSR followed - by the offset within syscon for lpass halt register. - -- memory-region: - Usage: required - Value type: - Definition: reference to the reserved-memory for the ADSP - -- qcom,smem-states: - Usage: required - Value type: - Definition: reference to the smem state for requesting the ADSP to - shut down - -- qcom,smem-state-names: - Usage: required - Value type: - Definition: must be "stop" - - -= SUBNODES -The adsp node may have an subnode named "glink-edge" that describes the -communication edge, channels and devices related to the ADSP. -See ../soc/qcom/qcom,glink.txt for details on how to describe these. - -= EXAMPLE -The following example describes the resources needed to boot control the -ADSP, as it is found on SDM845 boards. - - remoteproc@17300000 { - compatible = "qcom,sdm845-adsp-pil"; - reg = <0x17300000 0x40c>; - - interrupts-extended = <&intc GIC_SPI 162 IRQ_TYPE_EDGE_RISING>, - <&adsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, - <&adsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, - <&adsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, - <&adsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>; - interrupt-names = "wdog", "fatal", "ready", - "handover", "stop-ack"; - - clocks = <&rpmhcc RPMH_CXO_CLK>, - <&gcc GCC_LPASS_SWAY_CLK>, - <&lpasscc LPASS_Q6SS_AHBS_AON_CLK>, - <&lpasscc LPASS_Q6SS_AHBM_AON_CLK>, - <&lpasscc LPASS_QDSP6SS_XO_CLK>, - <&lpasscc LPASS_QDSP6SS_SLEEP_CLK>, - <&lpasscc LPASS_QDSP6SS_CORE_CLK>; - clock-names = "xo", "sway_cbcr", - "lpass_ahbs_aon_cbcr", - "lpass_ahbm_aon_cbcr", "qdsp6ss_xo", - "qdsp6ss_sleep", "qdsp6ss_core"; - - power-domains = <&rpmhpd SDM845_CX>; - - resets = <&pdc_reset PDC_AUDIO_SYNC_RESET>, - <&aoss_reset AOSS_CC_LPASS_RESTART>; - reset-names = "pdc_sync", "cc_lpass"; - - qcom,halt-regs = <&tcsr_mutex_regs 0x22000>; - - memory-region = <&pil_adsp_mem>; - - qcom,smem-states = <&adsp_smp2p_out 0>; - qcom,smem-state-names = "stop"; - }; diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,hexagon-v56.txt b/Documentation/devicetree/bindings/remoteproc/qcom,hexagon-v56.txt new file mode 100644 index 000000000000..1337a3d93d35 --- /dev/null +++ b/Documentation/devicetree/bindings/remoteproc/qcom,hexagon-v56.txt @@ -0,0 +1,140 @@ +Qualcomm Technology Inc. Hexagon v56 Peripheral Image Loader + +This document defines the binding for a component that loads and boots firmware +on the Qualcomm Technology Inc. Hexagon v56 core. + +- compatible: + Usage: required + Value type: + Definition: must be one of: + "qcom,qcs404-cdsp-pil", + "qcom,sdm845-adsp-pil" + +- reg: + Usage: required + Value type: + Definition: must specify the base address and size of the qdsp6ss register + +- interrupts-extended: + Usage: required + Value type: + Definition: must list the watchdog, fatal IRQs ready, handover and + stop-ack IRQs + +- interrupt-names: + Usage: required + Value type: + Definition: must be "wdog", "fatal", "ready", "handover", "stop-ack" + +- clocks: + Usage: required + Value type: + Definition: List of phandles and clock specifier pairs for the Hexagon, + per clock-names below. + +- clock-names: + Usage: required for SDM845 ADSP + Value type: + Definition: List of clock input name strings sorted in the same + order as the clocks property. Definition must have + "xo", "sway_cbcr", "lpass_ahbs_aon_cbcr", + "lpass_ahbm_aon_cbcr", "qdsp6ss_xo", "qdsp6ss_sleep" + and "qdsp6ss_core". + +- clock-names: + Usage: required for QCS404 CDSP + Value type: + Definition: List of clock input name strings sorted in the same + order as the clocks property. Definition must have + "xo", "sway", "tbu", "bimc", "ahb_aon", "q6ss_slave", + "q6ss_master", "q6_axim". + +- power-domains: + Usage: required + Value type: + Definition: reference to cx power domain node. + +- resets: + Usage: required + Value type: + Definition: reference to the list of resets for the Hexagon. + +- reset-names: + Usage: required for SDM845 ADSP + Value type: + Definition: must be "pdc_sync" and "cc_lpass" + +- reset-names: + Usage: required for QCS404 CDSP + Value type: + Definition: must be "restart" + +- qcom,halt-regs: + Usage: required + Value type: + Definition: a phandle reference to a syscon representing TCSR followed + by the offset within syscon for Hexagon halt register. + +- memory-region: + Usage: required + Value type: + Definition: reference to the reserved-memory for the firmware + +- qcom,smem-states: + Usage: required + Value type: + Definition: reference to the smem state for requesting the Hexagon to + shut down + +- qcom,smem-state-names: + Usage: required + Value type: + Definition: must be "stop" + + += SUBNODES +The adsp node may have an subnode named "glink-edge" that describes the +communication edge, channels and devices related to the Hexagon. +See ../soc/qcom/qcom,glink.txt for details on how to describe these. + += EXAMPLE +The following example describes the resources needed to boot control the +ADSP, as it is found on SDM845 boards. + + remoteproc@17300000 { + compatible = "qcom,sdm845-adsp-pil"; + reg = <0x17300000 0x40c>; + + interrupts-extended = <&intc GIC_SPI 162 IRQ_TYPE_EDGE_RISING>, + <&adsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, + <&adsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, + <&adsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, + <&adsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "wdog", "fatal", "ready", + "handover", "stop-ack"; + + clocks = <&rpmhcc RPMH_CXO_CLK>, + <&gcc GCC_LPASS_SWAY_CLK>, + <&lpasscc LPASS_Q6SS_AHBS_AON_CLK>, + <&lpasscc LPASS_Q6SS_AHBM_AON_CLK>, + <&lpasscc LPASS_QDSP6SS_XO_CLK>, + <&lpasscc LPASS_QDSP6SS_SLEEP_CLK>, + <&lpasscc LPASS_QDSP6SS_CORE_CLK>; + clock-names = "xo", "sway_cbcr", + "lpass_ahbs_aon_cbcr", + "lpass_ahbm_aon_cbcr", "qdsp6ss_xo", + "qdsp6ss_sleep", "qdsp6ss_core"; + + power-domains = <&rpmhpd SDM845_CX>; + + resets = <&pdc_reset PDC_AUDIO_SYNC_RESET>, + <&aoss_reset AOSS_CC_LPASS_RESTART>; + reset-names = "pdc_sync", "cc_lpass"; + + qcom,halt-regs = <&tcsr_mutex_regs 0x22000>; + + memory-region = <&pil_adsp_mem>; + + qcom,smem-states = <&adsp_smp2p_out 0>; + qcom,smem-state-names = "stop"; + }; -- cgit v1.2.3-59-g8ed1b From b270ea40b3c6e5d269ae6e1c74db401f7b1dcef0 Mon Sep 17 00:00:00 2001 From: Sibi Sankar Date: Sat, 29 Dec 2018 00:23:00 +0530 Subject: dt-bindings: soc: qcom: Add remote-pid binding for GLINK SMEM Add missing qcom,remote-pid dt binding required for GLINK SMEM which specifies the remote endpoint of the GLINK edge. Fixes: 2b41d6c8e696 ("dt-bindings: soc: qcom: Extend GLINK to cover SMEM") Reviewed-by: Doug Anderson Reviewed-by: Rob Herring Signed-off-by: Sibi Sankar Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt index cf759e5f9b10..1214192847ac 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,glink.txt @@ -21,6 +21,11 @@ edge. Definition: should specify the IRQ used by the remote processor to signal this processor about communication related events +- qcom,remote-pid: + Usage: required for glink-smem + Value type: + Definition: specifies the identifier of the remote endpoint of this edge + - qcom,rpm-msg-ram: Usage: required for glink-rpm Value type: -- cgit v1.2.3-59-g8ed1b From 982c0500fd1a8012c31d3c9dd8de285129904656 Mon Sep 17 00:00:00 2001 From: Matthias Kaehlcke Date: Thu, 16 May 2019 10:25:08 -0700 Subject: dt-bindings: gpu: add #cooling-cells property to the ARM Mali Midgard GPU binding The GPU can be used as a thermal cooling device, add an optional '#cooling-cells' property. Signed-off-by: Matthias Kaehlcke Reviewed-by: Douglas Anderson Signed-off-by: Heiko Stuebner Link: https://patchwork.freedesktop.org/patch/msgid/20190516172510.181473-1-mka@chromium.org --- Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt index 18a2cde2e5f3..61fd41a20f99 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt @@ -37,6 +37,8 @@ Optional properties: - operating-points-v2 : Refer to Documentation/devicetree/bindings/opp/opp.txt for details. +- #cooling-cells: Refer to Documentation/devicetree/bindings/thermal/thermal.txt + for details. Example for a Mali-T760: @@ -51,6 +53,7 @@ gpu@ffa30000 { mali-supply = <&vdd_gpu>; operating-points-v2 = <&gpu_opp_table>; power-domains = <&power RK3288_PD_GPU>; + #cooling-cells = <2>; }; gpu_opp_table: opp_table0 { -- cgit v1.2.3-59-g8ed1b From 97266c4d05345f9b500d10c3caa1070249e895e7 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Tue, 21 May 2019 16:23:25 -0500 Subject: spi: dt-bindings: Convert spi-gpio binding to json-schema Convert the spi-gpio binding to DT schema format. Cc: Mark Brown Cc: Linus Walleij Cc: linux-spi@vger.kernel.org Signed-off-by: Rob Herring Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/spi/spi-gpio.txt | 43 ------------- .../devicetree/bindings/spi/spi-gpio.yaml | 72 ++++++++++++++++++++++ 2 files changed, 72 insertions(+), 43 deletions(-) delete mode 100644 Documentation/devicetree/bindings/spi/spi-gpio.txt create mode 100644 Documentation/devicetree/bindings/spi/spi-gpio.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/spi-gpio.txt b/Documentation/devicetree/bindings/spi/spi-gpio.txt deleted file mode 100644 index 52db562f17a4..000000000000 --- a/Documentation/devicetree/bindings/spi/spi-gpio.txt +++ /dev/null @@ -1,43 +0,0 @@ -SPI-GPIO devicetree bindings - -This represents a group of 3-n GPIO lines used for bit-banged SPI on dedicated -GPIO lines. - -Required properties: - - - compatible: should be set to "spi-gpio" - - #address-cells: should be set to <0x1> - - ranges - - sck-gpios: GPIO spec for the SCK line to use - - miso-gpios: GPIO spec for the MISO line to use - - mosi-gpios: GPIO spec for the MOSI line to use - - cs-gpios: GPIOs to use for chipselect lines. - Not needed if num-chipselects = <0>. - - num-chipselects: Number of chipselect lines. Should be <0> if a single device - with no chip select is connected. - -Deprecated bindings: - -These legacy GPIO line bindings can alternatively be used to define the -GPIO lines used, they should not be used in new device trees. - - - gpio-sck: GPIO spec for the SCK line to use - - gpio-miso: GPIO spec for the MISO line to use - - gpio-mosi: GPIO spec for the MOSI line to use - -Example: - - spi { - compatible = "spi-gpio"; - #address-cells = <0x1>; - ranges; - - sck-gpios = <&gpio 95 0>; - miso-gpios = <&gpio 98 0>; - mosi-gpios = <&gpio 97 0>; - cs-gpios = <&gpio 125 0>; - num-chipselects = <1>; - - /* clients */ - }; - diff --git a/Documentation/devicetree/bindings/spi/spi-gpio.yaml b/Documentation/devicetree/bindings/spi/spi-gpio.yaml new file mode 100644 index 000000000000..55c4f1705f07 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-gpio.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/spi-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SPI-GPIO devicetree bindings + +maintainers: + - Rob Herring + +description: + This represents a group of 3-n GPIO lines used for bit-banged SPI on + dedicated GPIO lines. + +allOf: + - $ref: "/schemas/spi/spi-controller.yaml#" + +properties: + compatible: + const: spi-gpio + + sck-gpios: + description: GPIO spec for the SCK line to use + maxItems: 1 + + miso-gpios: + description: GPIO spec for the MISO line to use + maxItems: 1 + + mosi-gpios: + description: GPIO spec for the MOSI line to use + maxItems: 1 + + cs-gpios: + description: GPIOs to use for chipselect lines. + Not needed if num-chipselects = <0>. + minItems: 1 + maxItems: 1024 + + num-chipselects: + description: Number of chipselect lines. Should be <0> if a single device + with no chip select is connected. + $ref: "/schemas/types.yaml#/definitions/uint32" + + # Deprecated properties + gpio-sck: false + gpio-miso: false + gpio-mosi: false + +required: + - compatible + - num-chipselects + - sck-gpios + +examples: + - | + spi { + compatible = "spi-gpio"; + #address-cells = <0x1>; + #size-cells = <0x0>; + + sck-gpios = <&gpio 95 0>; + miso-gpios = <&gpio 98 0>; + mosi-gpios = <&gpio 97 0>; + cs-gpios = <&gpio 125 0>; + num-chipselects = <1>; + + /* clients */ + }; + +... -- cgit v1.2.3-59-g8ed1b From 1914a996436b09186489da73b807e1df71259f67 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Tue, 21 May 2019 16:20:29 -0500 Subject: regulator: Convert regulator binding to json-schema Convert the common regulator binding to DT schema format. Note that all the properties with standard unit suffixes have type checks already, so only a description is necessary. As fixed-regulator has already been converted, update the references in it. Otherwise, keep regulator.txt with a reference to the schema to avoid a bunch of treewide updates. regulator.txt can be removed when all the regulator bindings are converted. Signed-off-by: Rob Herring Signed-off-by: Mark Brown --- .../bindings/regulator/fixed-regulator.yaml | 5 +- .../devicetree/bindings/regulator/regulator.txt | 140 +-------------- .../devicetree/bindings/regulator/regulator.yaml | 200 +++++++++++++++++++++ 3 files changed, 205 insertions(+), 140 deletions(-) create mode 100644 Documentation/devicetree/bindings/regulator/regulator.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml b/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml index d289c2f7455a..a650b457085d 100644 --- a/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml @@ -12,10 +12,13 @@ maintainers: description: Any property defined as part of the core regulator binding, defined in - regulator.txt, can also be used. However a fixed voltage regulator is + regulator.yaml, can also be used. However a fixed voltage regulator is expected to have the regulator-min-microvolt and regulator-max-microvolt to be the same. +allOf: + - $ref: "regulator.yaml#" + properties: compatible: const: regulator-fixed diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt index 0a3f087d5844..487ccd8370b3 100644 --- a/Documentation/devicetree/bindings/regulator/regulator.txt +++ b/Documentation/devicetree/bindings/regulator/regulator.txt @@ -1,139 +1 @@ -Voltage/Current Regulators - -Optional properties: -- regulator-name: A string used as a descriptive name for regulator outputs -- regulator-min-microvolt: smallest voltage consumers may set -- regulator-max-microvolt: largest voltage consumers may set -- regulator-microvolt-offset: Offset applied to voltages to compensate for voltage drops -- regulator-min-microamp: smallest current consumers may set -- regulator-max-microamp: largest current consumers may set -- regulator-input-current-limit-microamp: maximum input current regulator allows -- 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 - initialised to zero (regulator-ramp-delay = <0>) for disabling ramp delay. -- regulator-enable-ramp-delay: The time taken, in microseconds, for the supply - rail to reach the target voltage, plus/minus whatever tolerance the board - design requires. This property describes the total system ramp time - required due to the combination of internal ramping of the regulator itself, - and board design issues such as trace capacitance and load on the supply. -- regulator-settling-time-us: Settling time, in microseconds, for voltage - change if regulator have the constant time for any level voltage change. - This is useful when regulator have exponential voltage change. -- regulator-settling-time-up-us: Settling time, in microseconds, for voltage - increase if the regulator needs a constant time to settle after voltage - increases of any level. This is useful for regulators with exponential - voltage changes. -- regulator-settling-time-down-us: Settling time, in microseconds, for voltage - decrease if the regulator needs a constant time to settle after voltage - decreases of any level. This is useful for regulators with exponential - voltage changes. -- regulator-soft-start: Enable soft start so that voltage ramps slowly -- regulator-state-standby sub-root node for Standby mode - : equivalent with standby Linux sleep state, which provides energy savings - with a relatively quick transition back time. -- regulator-state-mem sub-root node for Suspend-to-RAM mode - : suspend to memory, the device goes to sleep, but all data stored in memory, - only some external interrupt can wake the device. -- regulator-state-disk sub-root node for Suspend-to-DISK mode - : suspend to disk, this state operates similarly to Suspend-to-RAM, - but includes a final step of writing memory contents to disk. -- regulator-state-[mem/disk/standby] node has following common properties: - - regulator-on-in-suspend: regulator should be on in suspend state. - - regulator-off-in-suspend: regulator should be off in suspend state. - - regulator-suspend-min-microvolt: minimum voltage may be set in - suspend state. - - regulator-suspend-max-microvolt: maximum voltage may be set in - suspend state. - - regulator-suspend-microvolt: the default voltage which regulator - would be set in suspend. This property is now deprecated, instead - setting voltage for suspend mode via the API which regulator - driver provides is recommended. - - regulator-changeable-in-suspend: whether the default voltage and - the regulator on/off in suspend can be changed in runtime. - - regulator-mode: operating mode in the given suspend state. - The set of possible operating modes depends on the capabilities of - every hardware so the valid modes are documented on each regulator - device tree binding document. -- regulator-initial-mode: initial operating mode. The set of possible operating - modes depends on the capabilities of every hardware so each device binding - documentation explains which values the regulator supports. -- regulator-allowed-modes: list of operating modes that software is allowed to - configure for the regulator at run-time. Elements may be specified in any - order. The set of possible operating modes depends on the capabilities of - every hardware so each device binding document explains which values the - regulator supports. -- regulator-system-load: Load in uA present on regulator that is not captured by - any consumer request. -- regulator-pull-down: Enable pull down resistor when the regulator is disabled. -- regulator-over-current-protection: Enable over current protection. -- regulator-active-discharge: tristate, enable/disable active discharge of - regulators. The values are: - 0: Disable active discharge. - 1: Enable active discharge. - Absence of this property will leave configuration to default. -- regulator-coupled-with: Regulators with which the regulator - is coupled. The linkage is 2-way - all coupled regulators should be linked - with each other. A regulator should not be coupled with its supplier. -- regulator-coupled-max-spread: Array of maximum spread between voltages of - coupled regulators in microvolts, each value in the array relates to the - corresponding couple specified by the regulator-coupled-with property. -- regulator-max-step-microvolt: Maximum difference between current and target - voltages that can be changed safely in a single step. - -Deprecated properties: -- regulator-compatible: If a regulator chip contains multiple - regulators, and if the chip's binding contains a child node that - describes each regulator, then this property indicates which regulator - this child node is intended to configure. If this property is missing, - the node's name will be used instead. - -Example: - - xyzreg: regulator@0 { - regulator-min-microvolt = <1000000>; - regulator-max-microvolt = <2500000>; - regulator-always-on; - vin-supply = <&vin>; - - regulator-state-mem { - regulator-on-in-suspend; - }; - }; - -Regulator Consumers: -Consumer nodes can reference one or more of its supplies/ -regulators using the below bindings. - -- -supply: phandle to the regulator node - -These are the same bindings that a regulator in the above -example used to reference its own supply, in which case -its just seen as a special case of a regulator being a -consumer itself. - -Example of a consumer device node (mmc) referencing two -regulators (twl_reg1 and twl_reg2), - - twl_reg1: regulator@0 { - ... - ... - ... - }; - - twl_reg2: regulator@1 { - ... - ... - ... - }; - - mmc: mmc@0 { - ... - ... - vmmc-supply = <&twl_reg1>; - vmmcaux-supply = <&twl_reg2>; - }; +This file has moved to regulator.yaml. diff --git a/Documentation/devicetree/bindings/regulator/regulator.yaml b/Documentation/devicetree/bindings/regulator/regulator.yaml new file mode 100644 index 000000000000..02c3043ce419 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/regulator.yaml @@ -0,0 +1,200 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Voltage/Current Regulators + +maintainers: + - Liam Girdwood + - Mark Brown + +properties: + regulator-name: + description: A string used as a descriptive name for regulator outputs + $ref: "/schemas/types.yaml#/definitions/string" + + regulator-min-microvolt: + description: smallest voltage consumers may set + + regulator-max-microvolt: + description: largest voltage consumers may set + + regulator-microvolt-offset: + description: Offset applied to voltages to compensate for voltage drops + + regulator-min-microamp: + description: smallest current consumers may set + + regulator-max-microamp: + description: largest current consumers may set + + regulator-input-current-limit-microamp: + description: maximum input current regulator allows + + regulator-always-on: + description: boolean, regulator should never be disabled + type: boolean + + regulator-boot-on: + description: bootloader/firmware enabled regulator + type: boolean + + regulator-allow-bypass: + description: allow the regulator to go into bypass mode + type: boolean + + regulator-allow-set-load: + description: allow the regulator performance level to be configured + type: boolean + + regulator-ramp-delay: + description: ramp delay for regulator(in uV/us) For hardware which supports + disabling ramp rate, it should be explicitly initialised to zero (regulator-ramp-delay + = <0>) for disabling ramp delay. + $ref: "/schemas/types.yaml#/definitions/uint32" + + regulator-enable-ramp-delay: + description: The time taken, in microseconds, for the supply rail to + reach the target voltage, plus/minus whatever tolerance the board + design requires. This property describes the total system ramp time + required due to the combination of internal ramping of the regulator + itself, and board design issues such as trace capacitance and load + on the supply. + $ref: "/schemas/types.yaml#/definitions/uint32" + + regulator-settling-time-us: + description: Settling time, in microseconds, for voltage change if regulator + have the constant time for any level voltage change. This is useful + when regulator have exponential voltage change. + + regulator-settling-time-up-us: + description: Settling time, in microseconds, for voltage increase if + the regulator needs a constant time to settle after voltage increases + of any level. This is useful for regulators with exponential voltage + changes. + + regulator-settling-time-down-us: + description: Settling time, in microseconds, for voltage decrease if + the regulator needs a constant time to settle after voltage decreases + of any level. This is useful for regulators with exponential voltage + changes. + + regulator-soft-start: + description: Enable soft start so that voltage ramps slowly + type: boolean + + regulator-initial-mode: + description: initial operating mode. The set of possible operating modes + depends on the capabilities of every hardware so each device binding + documentation explains which values the regulator supports. + $ref: "/schemas/types.yaml#/definitions/uint32" + + regulator-allowed-modes: + description: list of operating modes that software is allowed to configure + for the regulator at run-time. Elements may be specified in any order. + The set of possible operating modes depends on the capabilities of + every hardware so each device binding document explains which values + the regulator supports. + $ref: "/schemas/types.yaml#/definitions/uint32-array" + + regulator-system-load: + description: Load in uA present on regulator that is not captured by + any consumer request. + $ref: "/schemas/types.yaml#/definitions/uint32" + + regulator-pull-down: + description: Enable pull down resistor when the regulator is disabled. + type: boolean + + regulator-over-current-protection: + description: Enable over current protection. + type: boolean + + regulator-active-discharge: + description: | + tristate, enable/disable active discharge of regulators. The values are: + 0: Disable active discharge. + 1: Enable active discharge. + Absence of this property will leave configuration to default. + allOf: + - $ref: "/schemas/types.yaml#/definitions/uint32" + - enum: [ 0, 1 ] + + regulator-coupled-with: + description: Regulators with which the regulator is coupled. The linkage + is 2-way - all coupled regulators should be linked with each other. + A regulator should not be coupled with its supplier. + $ref: "/schemas/types.yaml#/definitions/phandle-array" + + regulator-coupled-max-spread: + description: Array of maximum spread between voltages of coupled regulators + in microvolts, each value in the array relates to the corresponding + couple specified by the regulator-coupled-with property. + $ref: "/schemas/types.yaml#/definitions/uint32" + + regulator-max-step-microvolt: + description: Maximum difference between current and target voltages + that can be changed safely in a single step. + +patternProperties: + ".*-supply$": + description: Input supply phandle(s) for this node + + regulator-state-(standby|mem|disk): + type: object + description: + sub-nodes for regulator state in Standby, Suspend-to-RAM, and + Suspend-to-DISK modes. Equivalent with standby, mem, and disk Linux + sleep states. + + properties: + regulator-on-in-suspend: + description: regulator should be on in suspend state. + type: boolean + + regulator-off-in-suspend: + description: regulator should be off in suspend state. + type: boolean + + regulator-suspend-min-microvolt: + description: minimum voltage may be set in suspend state. + + regulator-suspend-max-microvolt: + description: maximum voltage may be set in suspend state. + + regulator-suspend-microvolt: + description: the default voltage which regulator would be set in + suspend. This property is now deprecated, instead setting voltage + for suspend mode via the API which regulator driver provides is + recommended. + + regulator-changeable-in-suspend: + description: whether the default voltage and the regulator on/off + in suspend can be changed in runtime. + type: boolean + + regulator-mode: + description: operating mode in the given suspend state. The set + of possible operating modes depends on the capabilities of every + hardware so the valid modes are documented on each regulator device + tree binding document. + $ref: "/schemas/types.yaml#/definitions/uint32" + + additionalProperties: false + +examples: + - | + xyzreg: regulator@0 { + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <2500000>; + regulator-always-on; + vin-supply = <&vin>; + + regulator-state-mem { + regulator-on-in-suspend; + }; + }; + +... -- cgit v1.2.3-59-g8ed1b From 673e401effe9dfd655f2d16588248f4c043361ce Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Tue, 21 May 2019 16:20:30 -0500 Subject: regulator: Convert gpio-regulator to json-schema Convert the gpio-regulator binding to DT schema format using json-schema. Signed-off-by: Rob Herring Signed-off-by: Mark Brown --- .../bindings/regulator/gpio-regulator.txt | 57 ---------- .../bindings/regulator/gpio-regulator.yaml | 118 +++++++++++++++++++++ 2 files changed, 118 insertions(+), 57 deletions(-) delete mode 100644 Documentation/devicetree/bindings/regulator/gpio-regulator.txt create mode 100644 Documentation/devicetree/bindings/regulator/gpio-regulator.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/gpio-regulator.txt b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt deleted file mode 100644 index dd25e73b5d79..000000000000 --- a/Documentation/devicetree/bindings/regulator/gpio-regulator.txt +++ /dev/null @@ -1,57 +0,0 @@ -GPIO controlled regulators - -Required properties: -- compatible : Must be "regulator-gpio". -- regulator-name : Defined in regulator.txt as optional, but required - here. -- gpios : Array of one or more GPIO pins used to select the - regulator voltage/current listed in "states". -- states : Selection of available voltages/currents provided by - this regulator and matching GPIO configurations to - achieve them. If there are no states in the "states" - array, use a fixed regulator instead. - -Optional properties: -- enable-gpios : GPIO used to enable/disable the regulator. - Warning, the GPIO phandle flags are ignored and the - GPIO polarity is controlled solely by the presence - of "enable-active-high" DT property. This is due to - compatibility with old DTs. -- enable-active-high : Polarity of "enable-gpio" GPIO is active HIGH. - Default is active LOW. -- gpios-states : On operating systems, that don't support reading back - gpio values in output mode (most notably linux), this - array provides the state of GPIO pins set when - requesting them from the gpio controller. Systems, - that are capable of preserving state when requesting - the lines, are free to ignore this property. - 0: LOW, 1: HIGH. Default is LOW if nothing else - is specified. -- startup-delay-us : Startup time in microseconds. -- regulator-type : Specifies what is being regulated, must be either - "voltage" or "current", defaults to voltage. - -Any property defined as part of the core regulator binding defined in -regulator.txt can also be used. - -Example: - - mmciv: gpio-regulator { - compatible = "regulator-gpio"; - - regulator-name = "mmci-gpio-supply"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <2600000>; - regulator-boot-on; - - enable-gpios = <&gpio0 23 0x4>; - gpios = <&gpio0 24 0x4 - &gpio0 25 0x4>; - states = <1800000 0x3 - 2200000 0x2 - 2600000 0x1 - 2900000 0x0>; - - startup-delay-us = <100000>; - enable-active-high; - }; diff --git a/Documentation/devicetree/bindings/regulator/gpio-regulator.yaml b/Documentation/devicetree/bindings/regulator/gpio-regulator.yaml new file mode 100644 index 000000000000..9d3b28417fb6 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/gpio-regulator.yaml @@ -0,0 +1,118 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/gpio-regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: GPIO controlled regulators + +maintainers: + - Liam Girdwood + - Mark Brown + +description: + Any property defined as part of the core regulator binding, defined in + regulator.txt, can also be used. + +allOf: + - $ref: "regulator.yaml#" + +properties: + compatible: + const: regulator-gpio + + regulator-name: true + + enable-gpios: + description: GPIO to use to enable/disable the regulator. + Warning, the GPIO phandle flags are ignored and the GPIO polarity is + controlled solely by the presence of "enable-active-high" DT property. + This is due to compatibility with old DTs. + maxItems: 1 + + gpios: + description: Array of one or more GPIO pins used to select the regulator + voltage/current listed in "states". + minItems: 1 + maxItems: 8 # Should be enough... + + gpios-states: + description: | + On operating systems, that don't support reading back gpio values in + output mode (most notably linux), this array provides the state of GPIO + pins set when requesting them from the gpio controller. Systems, that are + capable of preserving state when requesting the lines, are free to ignore + this property. + 0: LOW + 1: HIGH + Default is LOW if nothing else is specified. + allOf: + - $ref: /schemas/types.yaml#/definitions/uint32-array + - maxItems: 8 + items: + enum: [ 0, 1 ] + default: 0 + + states: + description: Selection of available voltages/currents provided by this + regulator and matching GPIO configurations to achieve them. If there are + no states in the "states" array, use a fixed regulator instead. + allOf: + - $ref: /schemas/types.yaml#/definitions/uint32-matrix + - maxItems: 8 + items: + items: + - description: Voltage in microvolts + - description: GPIO group state value + + startup-delay-us: + description: startup time in microseconds + + enable-active-high: + description: Polarity of "enable-gpio" GPIO is active HIGH. Default is + active LOW. + type: boolean + + gpio-open-drain: + description: + GPIO is open drain type. If this property is missing then default + assumption is false. + type: boolean + + regulator-type: + description: Specifies what is being regulated. + allOf: + - $ref: /schemas/types.yaml#/definitions/string + - enum: + - voltage + - current + default: voltage + +required: + - compatible + - regulator-name + - gpios + - states + +examples: + - | + gpio-regulator { + compatible = "regulator-gpio"; + + regulator-name = "mmci-gpio-supply"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <2600000>; + regulator-boot-on; + + enable-gpios = <&gpio0 23 0x4>; + gpios = <&gpio0 24 0x4 + &gpio0 25 0x4>; + states = <1800000 0x3>, + <2200000 0x2>, + <2600000 0x1>, + <2900000 0x0>; + + startup-delay-us = <100000>; + enable-active-high; + }; +... -- cgit v1.2.3-59-g8ed1b From 27b1b58fcfe72fd6b53a83b0dccb678e6b6faab8 Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Tue, 21 May 2019 16:20:31 -0500 Subject: regulator: Convert max8660 binding to json-schema Convert the max8660 binding to DT schema format using json-schema. Signed-off-by: Rob Herring Signed-off-by: Mark Brown --- .../devicetree/bindings/regulator/max8660.txt | 47 ------------- .../devicetree/bindings/regulator/max8660.yaml | 77 ++++++++++++++++++++++ 2 files changed, 77 insertions(+), 47 deletions(-) delete mode 100644 Documentation/devicetree/bindings/regulator/max8660.txt create mode 100644 Documentation/devicetree/bindings/regulator/max8660.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/max8660.txt b/Documentation/devicetree/bindings/regulator/max8660.txt deleted file mode 100644 index 8ba994d8a142..000000000000 --- a/Documentation/devicetree/bindings/regulator/max8660.txt +++ /dev/null @@ -1,47 +0,0 @@ -Maxim MAX8660 voltage regulator - -Required properties: -- compatible: must be one of "maxim,max8660", "maxim,max8661" -- reg: I2C slave address, usually 0x34 -- any required generic properties defined in regulator.txt - -Example: - - i2c_master { - max8660@34 { - compatible = "maxim,max8660"; - reg = <0x34>; - - regulators { - regulator@0 { - regulator-compatible= "V3(DCDC)"; - regulator-min-microvolt = <725000>; - regulator-max-microvolt = <1800000>; - }; - - regulator@1 { - regulator-compatible= "V4(DCDC)"; - regulator-min-microvolt = <725000>; - regulator-max-microvolt = <1800000>; - }; - - regulator@2 { - regulator-compatible= "V5(LDO)"; - regulator-min-microvolt = <1700000>; - regulator-max-microvolt = <2000000>; - }; - - regulator@3 { - regulator-compatible= "V6(LDO)"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <3300000>; - }; - - regulator@4 { - regulator-compatible= "V7(LDO)"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <3300000>; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/regulator/max8660.yaml b/Documentation/devicetree/bindings/regulator/max8660.yaml new file mode 100644 index 000000000000..9c038698f880 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/max8660.yaml @@ -0,0 +1,77 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/max8660.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX8660 voltage regulator + +maintainers: + - Daniel Mack + +properties: + $nodename: + pattern: "pmic@[0-9a-f]{1,2}" + compatible: + enum: + - maxim,max8660 + - maxim,max8661 + + reg: + maxItems: 1 + + regulators: + type: object + + patternProperties: + "regulator-.+": + $ref: "regulator.yaml#" + + additionalProperties: false + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@34 { + compatible = "maxim,max8660"; + reg = <0x34>; + + regulators { + regulator-V3 { + regulator-compatible= "V3(DCDC)"; + regulator-min-microvolt = <725000>; + regulator-max-microvolt = <1800000>; + }; + + regulator-V4 { + regulator-compatible= "V4(DCDC)"; + regulator-min-microvolt = <725000>; + regulator-max-microvolt = <1800000>; + }; + + regulator-V5 { + regulator-compatible= "V5(LDO)"; + regulator-min-microvolt = <1700000>; + regulator-max-microvolt = <2000000>; + }; + + regulator-V6 { + regulator-compatible= "V6(LDO)"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + }; + + regulator-V7 { + regulator-compatible= "V7(LDO)"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + }; + }; + }; + }; +... -- cgit v1.2.3-59-g8ed1b From d4db6c089099d38166752c93d9d165fb7526f1e5 Mon Sep 17 00:00:00 2001 From: Icenowy Zheng Date: Tue, 21 May 2019 18:10:59 +0200 Subject: dt-bindings: gpu: add bus clock for Mali Midgard GPUs MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Some SoCs adds a bus clock gate to the Mali Midgard GPU. Add the binding for the bus clock. Signed-off-by: Icenowy Zheng Signed-off-by: Clément Péron Reviewed-by: Rob Herring Signed-off-by: Rob Herring Link: https://patchwork.freedesktop.org/patch/msgid/20190521161102.29620-4-peron.clem@gmail.com --- Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt index 61fd41a20f99..abaca05b6267 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt @@ -31,6 +31,12 @@ Optional properties: - clocks : Phandle to clock for the Mali Midgard device. +- clock-names : Specify the names of the clocks specified in clocks + when multiple clocks are present. + * core: clock driving the GPU itself (When only one clock is present, + assume it's this clock.) + * bus: bus clock for the GPU + - mali-supply : Phandle to regulator for the Mali device. Refer to Documentation/devicetree/bindings/regulator/regulator.txt for details. -- cgit v1.2.3-59-g8ed1b From 3b1d715dc2edda1efa590fdf7cf9731501d4a44f Mon Sep 17 00:00:00 2001 From: Clément Péron Date: Tue, 21 May 2019 18:11:00 +0200 Subject: dt-bindings: gpu: mali-midgard: Add H6 mali gpu compatible MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This add the H6 mali compatible in the dt-bindings to later support specific implementation. Signed-off-by: Clément Péron Reviewed-by: Rob Herring Signed-off-by: Rob Herring Link: https://patchwork.freedesktop.org/patch/msgid/20190521161102.29620-5-peron.clem@gmail.com --- Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt index 2658b8ec1d83..e5ad3b2afe17 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt +++ b/Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt @@ -15,6 +15,7 @@ Required properties: + "arm,mali-t860" + "arm,mali-t880" * which must be preceded by one of the following vendor specifics: + + "allwinner,sun50i-h6-mali" + "amlogic,meson-gxm-mali" + "rockchip,rk3288-mali" + "rockchip,rk3399-mali" @@ -52,9 +53,15 @@ Vendor-specific bindings ------------------------ The Mali GPU is integrated very differently from one SoC to -another. In order to accomodate those differences, you have the option +another. In order to accommodate those differences, you have the option to specify one more vendor-specific compatible, among: +- "allwinner,sun50i-h6-mali" + Required properties: + - clocks : phandles to core and bus clocks + - clock-names : must contain "core" and "bus" + - resets: phandle to GPU reset line + - "amlogic,meson-gxm-mali" Required properties: - resets : Should contain phandles of : -- cgit v1.2.3-59-g8ed1b From 9c3f3410f5ace868c7c82fe4479fd36bed5eee64 Mon Sep 17 00:00:00 2001 From: Trent Piepho Date: Wed, 22 May 2019 18:43:19 +0000 Subject: dt-bindings: phy: dp83867: Describe how driver behaves w.r.t rgmii delay Add a note to make it more clear how the driver behaves when "rgmii" vs "rgmii-id", "rgmii-idrx", or "rgmii-idtx" interface modes are selected. Cc: Rob Herring Cc: Mark Rutland Signed-off-by: Trent Piepho Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/ti,dp83867.txt | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt b/Documentation/devicetree/bindings/net/ti,dp83867.txt index 9ef9338aaee1..99b8681bde49 100644 --- a/Documentation/devicetree/bindings/net/ti,dp83867.txt +++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt @@ -11,6 +11,14 @@ Required properties: - ti,fifo-depth - Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h for applicable values +Note: If the interface type is PHY_INTERFACE_MODE_RGMII the TX/RX clock delays + will be left at their default values, as set by the PHY's pin strapping. + The default strapping will use a delay of 2.00 ns. Thus + PHY_INTERFACE_MODE_RGMII, by default, does not behave as RGMII with no + internal delay, but as PHY_INTERFACE_MODE_RGMII_ID. The device tree + should use "rgmii-id" if internal delays are desired as this may be + changed in future to cause "rgmii" mode to disable delays. + Optional property: - ti,min-output-impedance - MAC Interface Impedance control to set the programmable output impedance to -- cgit v1.2.3-59-g8ed1b From 980066e6d9642fa5854bed8e592b1a30ea885b76 Mon Sep 17 00:00:00 2001 From: Trent Piepho Date: Wed, 22 May 2019 18:43:21 +0000 Subject: dt-bindings: phy: dp83867: Add documentation for disabling clock output The clock output is generally only used for testing and development and not used to daisy-chain PHYs. It's just a source of RF noise afterward. Add a mux value for "off". I've added it as another enumeration to the output property. In the actual PHY, the mux and the output enable are independently controllable. However, it doesn't seem useful to be able to describe the mux setting when the output is disabled. Document that PHY's default setting will be left as is if the property is omitted. Cc: Rob Herring Cc: Mark Rutland Signed-off-by: Trent Piepho Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/ti,dp83867.txt | 6 ++++-- include/dt-bindings/net/ti-dp83867.h | 2 ++ 2 files changed, 6 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.txt b/Documentation/devicetree/bindings/net/ti,dp83867.txt index 99b8681bde49..db6aa3f2215b 100644 --- a/Documentation/devicetree/bindings/net/ti,dp83867.txt +++ b/Documentation/devicetree/bindings/net/ti,dp83867.txt @@ -33,8 +33,10 @@ Optional property: software needs to take when this pin is strapped in these modes. See data manual for details. - - ti,clk-output-sel - Muxing option for CLK_OUT pin - see dt-bindings/net/ti-dp83867.h - for applicable values. + - ti,clk-output-sel - Muxing option for CLK_OUT pin. See dt-bindings/net/ti-dp83867.h + for applicable values. The CLK_OUT pin can also + be disabled by this property. When omitted, the + PHY's default will be left as is. Note: ti,min-output-impedance and ti,max-output-impedance are mutually exclusive. When both properties are present ti,max-output-impedance diff --git a/include/dt-bindings/net/ti-dp83867.h b/include/dt-bindings/net/ti-dp83867.h index 7b1656427cbe..192b79439eb7 100644 --- a/include/dt-bindings/net/ti-dp83867.h +++ b/include/dt-bindings/net/ti-dp83867.h @@ -56,4 +56,6 @@ #define DP83867_CLK_O_SEL_CHN_C_TCLK 0xA #define DP83867_CLK_O_SEL_CHN_D_TCLK 0xB #define DP83867_CLK_O_SEL_REF_CLK 0xC +/* Special flag to indicate clock should be off */ +#define DP83867_CLK_O_SEL_OFF 0xFFFFFFFF #endif -- cgit v1.2.3-59-g8ed1b From a0b2ff531582c510af11b6d548732eb2fd7772ff Mon Sep 17 00:00:00 2001 From: Martin Blumenstingl Date: Mon, 20 May 2019 21:43:49 +0200 Subject: dt-bindings: soc: amlogic: canvas: document support for Meson8/8b/8m2 The canvas IP on Meson8, Meson8b and Meson8m2 is similar to the one found on GXBB and newer. The only known difference is that the older SoCs cannot configure the "endianness". Add a compatible string for each of the older SoCs to make sure we won't be using unsupported features on these SoCs. Signed-off-by: Martin Blumenstingl Acked-by: Maxime Jourdan Signed-off-by: Kevin Hilman --- .../devicetree/bindings/soc/amlogic/amlogic,canvas.txt | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/amlogic/amlogic,canvas.txt b/Documentation/devicetree/bindings/soc/amlogic/amlogic,canvas.txt index 436d2106e80d..e876f3ce54f6 100644 --- a/Documentation/devicetree/bindings/soc/amlogic/amlogic,canvas.txt +++ b/Documentation/devicetree/bindings/soc/amlogic/amlogic,canvas.txt @@ -2,8 +2,8 @@ Amlogic Canvas ================================ A canvas is a collection of metadata that describes a pixel buffer. -Those metadata include: width, height, phyaddr, wrapping, block mode -and endianness. +Those metadata include: width, height, phyaddr, wrapping and block mode. +Starting with GXBB the endianness can also be described. Many IPs within Amlogic SoCs rely on canvas indexes to read/write pixel data rather than use the phy addresses directly. For instance, this is the case for @@ -18,7 +18,11 @@ Video Lookup Table -------------------------- Required properties: -- compatible: "amlogic,canvas" +- compatible: has to be one of: + - "amlogic,meson8-canvas", "amlogic,canvas" on Meson8 + - "amlogic,meson8b-canvas", "amlogic,canvas" on Meson8b + - "amlogic,meson8m2-canvas", "amlogic,canvas" on Meson8m2 + - "amlogic,canvas" on GXBB and newer - reg: Base physical address and size of the canvas registers. Example: -- cgit v1.2.3-59-g8ed1b From 3e75b76f0f17194e0e65694ade6e69fc11593190 Mon Sep 17 00:00:00 2001 From: Guillaume La Roque Date: Tue, 14 May 2019 10:26:47 +0200 Subject: dt-bindings: pinctrl: add a 'drive-strength-microamp' property This property allow drive-strength parameter in uA instead of mA. Signed-off-by: Guillaume La Roque Acked-by: Martin Blumenstingl Reviewed-by: Martin Blumenstingl Reviewed-by: Rob Herring Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt index cef2b5855d60..fcd37e93ed4d 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt @@ -258,6 +258,7 @@ drive-push-pull - drive actively high and low drive-open-drain - drive with open drain drive-open-source - drive with open source drive-strength - sink or source at most X mA +drive-strength-microamp - sink or source at most X uA input-enable - enable input on pin (no effect on output, such as enabling an input buffer) input-disable - disable input on pin (no effect on output, such as @@ -326,6 +327,8 @@ arguments are described below. - drive-strength takes as argument the target strength in mA. +- drive-strength-microamp takes as argument the target strength in uA. + - input-debounce takes the debounce time in usec as argument or 0 to disable debouncing -- cgit v1.2.3-59-g8ed1b From 013786c043298710887e983ac8d59aaff1f554f3 Mon Sep 17 00:00:00 2001 From: Guillaume La Roque Date: Tue, 14 May 2019 10:26:49 +0200 Subject: dt-bindings: pinctrl: meson: Add drive-strength-microamp property Add optional drive-strength-microamp property Signed-off-by: Guillaume La Roque Reviewed-by: Martin Blumenstingl Reviewed-by: Rob Herring Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt index a47dd990a8d3..a7618605bf1e 100644 --- a/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt @@ -51,6 +51,10 @@ Configuration nodes support the generic properties "bias-disable", "bias-pull-up" and "bias-pull-down", described in file pinctrl-bindings.txt +Optional properties : + - drive-strength-microamp: Drive strength for the specified pins in uA. + This property is only valid for G12A and newer. + === Example === pinctrl: pinctrl@c1109880 { -- cgit v1.2.3-59-g8ed1b From f3fbedabb7be0d19b2da862fa6c01d82ac39c716 Mon Sep 17 00:00:00 2001 From: Florian Fainelli Date: Thu, 9 May 2019 13:59:53 -0700 Subject: dt-bindings: pinctrl: bcm2835-gpio: Document BCM7211 compatible BCM7211 has a slightly different block layout and some additional GPIO registers that were added, document the compatible string. Signed-off-by: Florian Fainelli Reviewed-by: Eric Anholt Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt index 3fac0a061bcc..ac6d614d74e0 100644 --- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt +++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm2835-gpio.txt @@ -5,6 +5,9 @@ controller, and pinmux/control device. Required properties: - compatible: "brcm,bcm2835-gpio" +- compatible: should be one of: + "brcm,bcm2835-gpio" - BCM2835 compatible pinctrl + "brcm,bcm7211-gpio" - BCM7211 compatible pinctrl - reg: Should contain the physical address of the GPIO module's registers. - gpio-controller: Marks the device node as a GPIO controller. - #gpio-cells : Should be two. The first cell is the pin number and the -- cgit v1.2.3-59-g8ed1b From 7745f03eb39587dd15a1fb26e6223678b8e906d2 Mon Sep 17 00:00:00 2001 From: Len Brown Date: Mon, 13 May 2019 13:58:45 -0400 Subject: x86/topology: Add CPUID.1F multi-die/package support Some new systems have multiple software-visible die within each package. Update Linux parsing of the Intel CPUID "Extended Topology Leaf" to handle either CPUID.B, or the new CPUID.1F. Add cpuinfo_x86.die_id and cpuinfo_x86.max_dies to store the result. die_id will be non-zero only for multi-die/package systems. Signed-off-by: Len Brown Signed-off-by: Thomas Gleixner Reviewed-by: Ingo Molnar Acked-by: Peter Zijlstra (Intel) Cc: linux-doc@vger.kernel.org Link: https://lkml.kernel.org/r/7b23d2d26d717b8e14ba137c94b70943f1ae4b5c.1557769318.git.len.brown@intel.com --- Documentation/x86/topology.rst | 4 ++ arch/x86/include/asm/processor.h | 4 +- arch/x86/kernel/cpu/topology.c | 85 +++++++++++++++++++++++++++++++--------- arch/x86/kernel/smpboot.c | 2 + 4 files changed, 75 insertions(+), 20 deletions(-) (limited to 'Documentation') diff --git a/Documentation/x86/topology.rst b/Documentation/x86/topology.rst index 6e28dbe818ab..8e9704f61017 100644 --- a/Documentation/x86/topology.rst +++ b/Documentation/x86/topology.rst @@ -49,6 +49,10 @@ Package-related topology information in the kernel: The number of cores in a package. This information is retrieved via CPUID. + - cpuinfo_x86.x86_max_dies: + + The number of dies in a package. This information is retrieved via CPUID. + - cpuinfo_x86.phys_proc_id: The physical ID of the package. This information is retrieved via CPUID diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h index c34a35c78618..ef0a44fccaec 100644 --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h @@ -105,7 +105,8 @@ struct cpuinfo_x86 { int x86_power; unsigned long loops_per_jiffy; /* cpuid returned max cores value: */ - u16 x86_max_cores; + u16 x86_max_cores; + u16 x86_max_dies; u16 apicid; u16 initial_apicid; u16 x86_clflush_size; @@ -117,6 +118,7 @@ struct cpuinfo_x86 { u16 logical_proc_id; /* Core id: */ u16 cpu_core_id; + u16 cpu_die_id; /* Index into per_cpu list: */ u16 cpu_index; u32 microcode; diff --git a/arch/x86/kernel/cpu/topology.c b/arch/x86/kernel/cpu/topology.c index 8f6c784141d1..4d17e699657d 100644 --- a/arch/x86/kernel/cpu/topology.c +++ b/arch/x86/kernel/cpu/topology.c @@ -15,33 +15,63 @@ /* leaf 0xb SMT level */ #define SMT_LEVEL 0 -/* leaf 0xb sub-leaf types */ +/* extended topology sub-leaf types */ #define INVALID_TYPE 0 #define SMT_TYPE 1 #define CORE_TYPE 2 +#define DIE_TYPE 5 #define LEAFB_SUBTYPE(ecx) (((ecx) >> 8) & 0xff) #define BITS_SHIFT_NEXT_LEVEL(eax) ((eax) & 0x1f) #define LEVEL_MAX_SIBLINGS(ebx) ((ebx) & 0xffff) -int detect_extended_topology_early(struct cpuinfo_x86 *c) -{ #ifdef CONFIG_SMP +/* + * Check if given CPUID extended toplogy "leaf" is implemented + */ +static int check_extended_topology_leaf(int leaf) +{ unsigned int eax, ebx, ecx, edx; - if (c->cpuid_level < 0xb) + cpuid_count(leaf, SMT_LEVEL, &eax, &ebx, &ecx, &edx); + + if (ebx == 0 || (LEAFB_SUBTYPE(ecx) != SMT_TYPE)) return -1; - cpuid_count(0xb, SMT_LEVEL, &eax, &ebx, &ecx, &edx); + return 0; +} +/* + * Return best CPUID Extended Toplogy Leaf supported + */ +static int detect_extended_topology_leaf(struct cpuinfo_x86 *c) +{ + if (c->cpuid_level >= 0x1f) { + if (check_extended_topology_leaf(0x1f) == 0) + return 0x1f; + } - /* - * check if the cpuid leaf 0xb is actually implemented. - */ - if (ebx == 0 || (LEAFB_SUBTYPE(ecx) != SMT_TYPE)) + if (c->cpuid_level >= 0xb) { + if (check_extended_topology_leaf(0xb) == 0) + return 0xb; + } + + return -1; +} +#endif + +int detect_extended_topology_early(struct cpuinfo_x86 *c) +{ +#ifdef CONFIG_SMP + unsigned int eax, ebx, ecx, edx; + int leaf; + + leaf = detect_extended_topology_leaf(c); + if (leaf < 0) return -1; set_cpu_cap(c, X86_FEATURE_XTOPOLOGY); + cpuid_count(leaf, SMT_LEVEL, &eax, &ebx, &ecx, &edx); /* * initial apic id, which also represents 32-bit extended x2apic id. */ @@ -52,7 +82,7 @@ int detect_extended_topology_early(struct cpuinfo_x86 *c) } /* - * Check for extended topology enumeration cpuid leaf 0xb and if it + * Check for extended topology enumeration cpuid leaf, and if it * exists, use it for populating initial_apicid and cpu topology * detection. */ @@ -60,22 +90,28 @@ int detect_extended_topology(struct cpuinfo_x86 *c) { #ifdef CONFIG_SMP unsigned int eax, ebx, ecx, edx, sub_index; - unsigned int ht_mask_width, core_plus_mask_width; + unsigned int ht_mask_width, core_plus_mask_width, die_plus_mask_width; unsigned int core_select_mask, core_level_siblings; + unsigned int die_select_mask, die_level_siblings; + int leaf; - if (detect_extended_topology_early(c) < 0) + leaf = detect_extended_topology_leaf(c); + if (leaf < 0) return -1; /* * Populate HT related information from sub-leaf level 0. */ - cpuid_count(0xb, SMT_LEVEL, &eax, &ebx, &ecx, &edx); + cpuid_count(leaf, SMT_LEVEL, &eax, &ebx, &ecx, &edx); + c->initial_apicid = edx; core_level_siblings = smp_num_siblings = LEVEL_MAX_SIBLINGS(ebx); core_plus_mask_width = ht_mask_width = BITS_SHIFT_NEXT_LEVEL(eax); + die_level_siblings = LEVEL_MAX_SIBLINGS(ebx); + die_plus_mask_width = BITS_SHIFT_NEXT_LEVEL(eax); sub_index = 1; do { - cpuid_count(0xb, sub_index, &eax, &ebx, &ecx, &edx); + cpuid_count(leaf, sub_index, &eax, &ebx, &ecx, &edx); /* * Check for the Core type in the implemented sub leaves. @@ -83,23 +119,34 @@ int detect_extended_topology(struct cpuinfo_x86 *c) if (LEAFB_SUBTYPE(ecx) == CORE_TYPE) { core_level_siblings = LEVEL_MAX_SIBLINGS(ebx); core_plus_mask_width = BITS_SHIFT_NEXT_LEVEL(eax); - break; + die_level_siblings = core_level_siblings; + die_plus_mask_width = BITS_SHIFT_NEXT_LEVEL(eax); + } + if (LEAFB_SUBTYPE(ecx) == DIE_TYPE) { + die_level_siblings = LEVEL_MAX_SIBLINGS(ebx); + die_plus_mask_width = BITS_SHIFT_NEXT_LEVEL(eax); } sub_index++; } while (LEAFB_SUBTYPE(ecx) != INVALID_TYPE); core_select_mask = (~(-1 << core_plus_mask_width)) >> ht_mask_width; - - c->cpu_core_id = apic->phys_pkg_id(c->initial_apicid, ht_mask_width) - & core_select_mask; - c->phys_proc_id = apic->phys_pkg_id(c->initial_apicid, core_plus_mask_width); + die_select_mask = (~(-1 << die_plus_mask_width)) >> + core_plus_mask_width; + + c->cpu_core_id = apic->phys_pkg_id(c->initial_apicid, + ht_mask_width) & core_select_mask; + c->cpu_die_id = apic->phys_pkg_id(c->initial_apicid, + core_plus_mask_width) & die_select_mask; + c->phys_proc_id = apic->phys_pkg_id(c->initial_apicid, + die_plus_mask_width); /* * Reinit the apicid, now that we have extended initial_apicid. */ c->apicid = apic->phys_pkg_id(c->initial_apicid, 0); c->x86_max_cores = (core_level_siblings / smp_num_siblings); + c->x86_max_dies = (die_level_siblings / core_level_siblings); #endif return 0; } diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c index 73e69aaaa117..40ffe23249c0 100644 --- a/arch/x86/kernel/smpboot.c +++ b/arch/x86/kernel/smpboot.c @@ -389,6 +389,7 @@ static bool match_smt(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o) int cpu1 = c->cpu_index, cpu2 = o->cpu_index; if (c->phys_proc_id == o->phys_proc_id && + c->cpu_die_id == o->cpu_die_id && per_cpu(cpu_llc_id, cpu1) == per_cpu(cpu_llc_id, cpu2)) { if (c->cpu_core_id == o->cpu_core_id) return topology_sane(c, o, "smt"); @@ -400,6 +401,7 @@ static bool match_smt(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o) } } else if (c->phys_proc_id == o->phys_proc_id && + c->cpu_die_id == o->cpu_die_id && c->cpu_core_id == o->cpu_core_id) { return topology_sane(c, o, "smt"); } -- cgit v1.2.3-59-g8ed1b From 0e344d8c709fe01d882fc0fb5452bedfe5eba67a Mon Sep 17 00:00:00 2001 From: Len Brown Date: Mon, 13 May 2019 13:58:47 -0400 Subject: cpu/topology: Export die_id Export die_id in cpu topology, for the benefit of hardware that has multiple-die/package. Signed-off-by: Len Brown Signed-off-by: Thomas Gleixner Reviewed-by: Ingo Molnar Acked-by: Peter Zijlstra (Intel) Cc: linux-doc@vger.kernel.org Link: https://lkml.kernel.org/r/e7d1caaf4fbd24ee40db6d557ab28d7d83298900.1557769318.git.len.brown@intel.com --- Documentation/cputopology.txt | 15 ++++++++++++--- drivers/base/topology.c | 4 ++++ include/linux/topology.h | 3 +++ 3 files changed, 19 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cputopology.txt b/Documentation/cputopology.txt index cb61277e2308..2ff8a1e9a2db 100644 --- a/Documentation/cputopology.txt +++ b/Documentation/cputopology.txt @@ -12,6 +12,12 @@ physical_package_id: socket number, but the actual value is architecture and platform dependent. +die_id: + + the CPU die ID of cpuX. Typically it is the hardware platform's + identifier (rather than the kernel's). The actual value is + architecture and platform dependent. + core_id: the CPU core ID of cpuX. Typically it is the hardware platform's @@ -81,6 +87,7 @@ For an architecture to support this feature, it must define some of these macros in include/asm-XXX/topology.h:: #define topology_physical_package_id(cpu) + #define topology_die_id(cpu) #define topology_core_id(cpu) #define topology_book_id(cpu) #define topology_drawer_id(cpu) @@ -99,9 +106,11 @@ provides default definitions for any of the above macros that are not defined by include/asm-XXX/topology.h: 1) topology_physical_package_id: -1 -2) topology_core_id: 0 -3) topology_sibling_cpumask: just the given CPU -4) topology_core_cpumask: just the given CPU +2) topology_die_id: -1 +3) topology_core_id: 0 +4) topology_sibling_cpumask: just the given CPU +5) topology_core_cpumask: just the given CPU +6) topology_die_cpumask: just the given CPU For architectures that don't support books (CONFIG_SCHED_BOOK) there are no default definitions for topology_book_id() and topology_book_cpumask(). diff --git a/drivers/base/topology.c b/drivers/base/topology.c index 5fd9f167ecc1..50352cf96f85 100644 --- a/drivers/base/topology.c +++ b/drivers/base/topology.c @@ -43,6 +43,9 @@ static ssize_t name##_list_show(struct device *dev, \ define_id_show_func(physical_package_id); static DEVICE_ATTR_RO(physical_package_id); +define_id_show_func(die_id); +static DEVICE_ATTR_RO(die_id); + define_id_show_func(core_id); static DEVICE_ATTR_RO(core_id); @@ -72,6 +75,7 @@ static DEVICE_ATTR_RO(drawer_siblings_list); static struct attribute *default_attrs[] = { &dev_attr_physical_package_id.attr, + &dev_attr_die_id.attr, &dev_attr_core_id.attr, &dev_attr_thread_siblings.attr, &dev_attr_thread_siblings_list.attr, diff --git a/include/linux/topology.h b/include/linux/topology.h index cb0775e1ee4b..5cc8595dd0e4 100644 --- a/include/linux/topology.h +++ b/include/linux/topology.h @@ -184,6 +184,9 @@ static inline int cpu_to_mem(int cpu) #ifndef topology_physical_package_id #define topology_physical_package_id(cpu) ((void)(cpu), -1) #endif +#ifndef topology_die_id +#define topology_die_id(cpu) ((void)(cpu), -1) +#endif #ifndef topology_core_id #define topology_core_id(cpu) ((void)(cpu), 0) #endif -- cgit v1.2.3-59-g8ed1b From b73ed8dc0597c11ec5064d06b9bbd4e541b6d4e7 Mon Sep 17 00:00:00 2001 From: Len Brown Date: Mon, 13 May 2019 13:58:55 -0400 Subject: topology: Create package_cpus sysfs attribute The existing sysfs cpu/topology/core_siblings (and core_siblings_list) attributes are documented, implemented, and used by programs to represent set of logical CPUs sharing the same package. This makes sense if the next topology level above a core is always a package. But on systems where there is a die topology level between a core and a package, the name and its definition become inconsistent. So without changing its function, add a name for this map that describes what it actually is -- package CPUs -- the set of CPUs that share the same package. This new name will be immune to changes in topology, since it describes threads at the current level, not siblings at a contained level. Suggested-by: Brice Goglin Signed-off-by: Len Brown Signed-off-by: Thomas Gleixner Reviewed-by: Ingo Molnar Acked-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/d9d3228b82fb5665e6f93a0ccd033fe022558521.1557769318.git.len.brown@intel.com --- Documentation/cputopology.txt | 12 ++++++------ drivers/base/topology.c | 6 ++++++ 2 files changed, 12 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cputopology.txt b/Documentation/cputopology.txt index 2ff8a1e9a2db..48af5c290e20 100644 --- a/Documentation/cputopology.txt +++ b/Documentation/cputopology.txt @@ -46,15 +46,15 @@ thread_siblings_list: human-readable list of cpuX's hardware threads within the same core as cpuX. -core_siblings: +package_cpus: - internal kernel map of cpuX's hardware threads within the same - physical_package_id. + internal kernel map of the CPUs sharing the same physical_package_id. + (deprecated name: "core_siblings") -core_siblings_list: +package_cpus_list: - human-readable list of cpuX's hardware threads within the same - physical_package_id. + human-readable list of CPUs sharing the same physical_package_id. + (deprecated name: "core_siblings_list") book_siblings: diff --git a/drivers/base/topology.c b/drivers/base/topology.c index 50352cf96f85..dc3c19b482f3 100644 --- a/drivers/base/topology.c +++ b/drivers/base/topology.c @@ -57,6 +57,10 @@ define_siblings_show_func(core_siblings, core_cpumask); static DEVICE_ATTR_RO(core_siblings); static DEVICE_ATTR_RO(core_siblings_list); +define_siblings_show_func(package_cpus, core_cpumask); +static DEVICE_ATTR_RO(package_cpus); +static DEVICE_ATTR_RO(package_cpus_list); + #ifdef CONFIG_SCHED_BOOK define_id_show_func(book_id); static DEVICE_ATTR_RO(book_id); @@ -81,6 +85,8 @@ static struct attribute *default_attrs[] = { &dev_attr_thread_siblings_list.attr, &dev_attr_core_siblings.attr, &dev_attr_core_siblings_list.attr, + &dev_attr_package_cpus.attr, + &dev_attr_package_cpus_list.attr, #ifdef CONFIG_SCHED_BOOK &dev_attr_book_id.attr, &dev_attr_book_siblings.attr, -- cgit v1.2.3-59-g8ed1b From 2e4c54dac7b360c3820399bdf06cde9134a4495b Mon Sep 17 00:00:00 2001 From: Len Brown Date: Mon, 13 May 2019 13:58:56 -0400 Subject: topology: Create core_cpus and die_cpus sysfs attributes Create CPU topology sysfs attributes: "core_cpus" and "core_cpus_list" These attributes represent all of the logical CPUs that share the same core. These attriutes is synonymous with the existing "thread_siblings" and "thread_siblings_list" attribute, which will be deprecated. Create CPU topology sysfs attributes: "die_cpus" and "die_cpus_list". These attributes represent all of the logical CPUs that share the same die. Suggested-by: Brice Goglin Signed-off-by: Len Brown Signed-off-by: Thomas Gleixner Reviewed-by: Ingo Molnar Acked-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/071c23a298cd27ede6ed0b6460cae190d193364f.1557769318.git.len.brown@intel.com --- Documentation/cputopology.txt | 21 +++++++++++++++------ arch/x86/include/asm/smp.h | 1 + arch/x86/include/asm/topology.h | 1 + arch/x86/kernel/smpboot.c | 22 ++++++++++++++++++++++ arch/x86/xen/smp_pv.c | 1 + drivers/base/topology.c | 12 ++++++++++++ include/linux/topology.h | 3 +++ 7 files changed, 55 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cputopology.txt b/Documentation/cputopology.txt index 48af5c290e20..b90dafcc8237 100644 --- a/Documentation/cputopology.txt +++ b/Documentation/cputopology.txt @@ -36,15 +36,15 @@ drawer_id: identifier (rather than the kernel's). The actual value is architecture and platform dependent. -thread_siblings: +core_cpus: - internal kernel map of cpuX's hardware threads within the same - core as cpuX. + internal kernel map of CPUs within the same core. + (deprecated name: "thread_siblings") -thread_siblings_list: +core_cpus_list: - human-readable list of cpuX's hardware threads within the same - core as cpuX. + human-readable list of CPUs within the same core. + (deprecated name: "thread_siblings_list"); package_cpus: @@ -56,6 +56,14 @@ package_cpus_list: human-readable list of CPUs sharing the same physical_package_id. (deprecated name: "core_siblings_list") +die_cpus: + + internal kernel map of CPUs within the same die. + +die_cpus_list: + + human-readable list of CPUs within the same die. + book_siblings: internal kernel map of cpuX's hardware threads within the same @@ -93,6 +101,7 @@ these macros in include/asm-XXX/topology.h:: #define topology_drawer_id(cpu) #define topology_sibling_cpumask(cpu) #define topology_core_cpumask(cpu) + #define topology_die_cpumask(cpu) #define topology_book_cpumask(cpu) #define topology_drawer_cpumask(cpu) diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h index da545df207b2..b673a226ad6c 100644 --- a/arch/x86/include/asm/smp.h +++ b/arch/x86/include/asm/smp.h @@ -23,6 +23,7 @@ extern unsigned int num_processors; DECLARE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_sibling_map); DECLARE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_core_map); +DECLARE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_die_map); /* cpus sharing the last level cache: */ DECLARE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_llc_shared_map); DECLARE_PER_CPU_READ_MOSTLY(u16, cpu_llc_id); diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.h index 9de16b4f6023..4b14d2318251 100644 --- a/arch/x86/include/asm/topology.h +++ b/arch/x86/include/asm/topology.h @@ -111,6 +111,7 @@ extern const struct cpumask *cpu_coregroup_mask(int cpu); #define topology_core_id(cpu) (cpu_data(cpu).cpu_core_id) #ifdef CONFIG_SMP +#define topology_die_cpumask(cpu) (per_cpu(cpu_die_map, cpu)) #define topology_core_cpumask(cpu) (per_cpu(cpu_core_map, cpu)) #define topology_sibling_cpumask(cpu) (per_cpu(cpu_sibling_map, cpu)) diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c index a6e01b6c2709..1a19a5171949 100644 --- a/arch/x86/kernel/smpboot.c +++ b/arch/x86/kernel/smpboot.c @@ -91,6 +91,10 @@ EXPORT_PER_CPU_SYMBOL(cpu_sibling_map); DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_core_map); EXPORT_PER_CPU_SYMBOL(cpu_core_map); +/* representing HT, core, and die siblings of each logical CPU */ +DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_die_map); +EXPORT_PER_CPU_SYMBOL(cpu_die_map); + DEFINE_PER_CPU_READ_MOSTLY(cpumask_var_t, cpu_llc_shared_map); /* Per CPU bogomips and other parameters */ @@ -509,6 +513,15 @@ static bool match_pkg(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o) return false; } +static bool match_die(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o) +{ + if ((c->phys_proc_id == o->phys_proc_id) && + (c->cpu_die_id == o->cpu_die_id)) + return true; + return false; +} + + #if defined(CONFIG_SCHED_SMT) || defined(CONFIG_SCHED_MC) static inline int x86_sched_itmt_flags(void) { @@ -571,6 +584,7 @@ void set_cpu_sibling_map(int cpu) cpumask_set_cpu(cpu, topology_sibling_cpumask(cpu)); cpumask_set_cpu(cpu, cpu_llc_shared_mask(cpu)); cpumask_set_cpu(cpu, topology_core_cpumask(cpu)); + cpumask_set_cpu(cpu, topology_die_cpumask(cpu)); c->booted_cores = 1; return; } @@ -619,6 +633,9 @@ void set_cpu_sibling_map(int cpu) } if (match_pkg(c, o) && !topology_same_node(c, o)) x86_has_numa_in_package = true; + + if ((i == cpu) || (has_mp && match_die(c, o))) + link_mask(topology_die_cpumask, cpu, i); } threads = cpumask_weight(topology_sibling_cpumask(cpu)); @@ -1223,6 +1240,7 @@ static __init void disable_smp(void) physid_set_mask_of_physid(0, &phys_cpu_present_map); cpumask_set_cpu(0, topology_sibling_cpumask(0)); cpumask_set_cpu(0, topology_core_cpumask(0)); + cpumask_set_cpu(0, topology_die_cpumask(0)); } /* @@ -1318,6 +1336,7 @@ void __init native_smp_prepare_cpus(unsigned int max_cpus) for_each_possible_cpu(i) { zalloc_cpumask_var(&per_cpu(cpu_sibling_map, i), GFP_KERNEL); zalloc_cpumask_var(&per_cpu(cpu_core_map, i), GFP_KERNEL); + zalloc_cpumask_var(&per_cpu(cpu_die_map, i), GFP_KERNEL); zalloc_cpumask_var(&per_cpu(cpu_llc_shared_map, i), GFP_KERNEL); } @@ -1538,6 +1557,8 @@ static void remove_siblinginfo(int cpu) cpu_data(sibling).booted_cores--; } + for_each_cpu(sibling, topology_die_cpumask(cpu)) + cpumask_clear_cpu(cpu, topology_die_cpumask(sibling)); for_each_cpu(sibling, topology_sibling_cpumask(cpu)) cpumask_clear_cpu(cpu, topology_sibling_cpumask(sibling)); for_each_cpu(sibling, cpu_llc_shared_mask(cpu)) @@ -1545,6 +1566,7 @@ static void remove_siblinginfo(int cpu) cpumask_clear(cpu_llc_shared_mask(cpu)); cpumask_clear(topology_sibling_cpumask(cpu)); cpumask_clear(topology_core_cpumask(cpu)); + cpumask_clear(topology_die_cpumask(cpu)); c->cpu_core_id = 0; c->booted_cores = 0; cpumask_clear_cpu(cpu, cpu_sibling_setup_mask); diff --git a/arch/x86/xen/smp_pv.c b/arch/x86/xen/smp_pv.c index 590fcf863006..77d81c1a63e9 100644 --- a/arch/x86/xen/smp_pv.c +++ b/arch/x86/xen/smp_pv.c @@ -251,6 +251,7 @@ static void __init xen_pv_smp_prepare_cpus(unsigned int max_cpus) for_each_possible_cpu(i) { zalloc_cpumask_var(&per_cpu(cpu_sibling_map, i), GFP_KERNEL); zalloc_cpumask_var(&per_cpu(cpu_core_map, i), GFP_KERNEL); + zalloc_cpumask_var(&per_cpu(cpu_die_map, i), GFP_KERNEL); zalloc_cpumask_var(&per_cpu(cpu_llc_shared_map, i), GFP_KERNEL); } set_cpu_sibling_map(0); diff --git a/drivers/base/topology.c b/drivers/base/topology.c index dc3c19b482f3..4e033d4cc0dc 100644 --- a/drivers/base/topology.c +++ b/drivers/base/topology.c @@ -53,10 +53,18 @@ define_siblings_show_func(thread_siblings, sibling_cpumask); static DEVICE_ATTR_RO(thread_siblings); static DEVICE_ATTR_RO(thread_siblings_list); +define_siblings_show_func(core_cpus, sibling_cpumask); +static DEVICE_ATTR_RO(core_cpus); +static DEVICE_ATTR_RO(core_cpus_list); + define_siblings_show_func(core_siblings, core_cpumask); static DEVICE_ATTR_RO(core_siblings); static DEVICE_ATTR_RO(core_siblings_list); +define_siblings_show_func(die_cpus, die_cpumask); +static DEVICE_ATTR_RO(die_cpus); +static DEVICE_ATTR_RO(die_cpus_list); + define_siblings_show_func(package_cpus, core_cpumask); static DEVICE_ATTR_RO(package_cpus); static DEVICE_ATTR_RO(package_cpus_list); @@ -83,8 +91,12 @@ static struct attribute *default_attrs[] = { &dev_attr_core_id.attr, &dev_attr_thread_siblings.attr, &dev_attr_thread_siblings_list.attr, + &dev_attr_core_cpus.attr, + &dev_attr_core_cpus_list.attr, &dev_attr_core_siblings.attr, &dev_attr_core_siblings_list.attr, + &dev_attr_die_cpus.attr, + &dev_attr_die_cpus_list.attr, &dev_attr_package_cpus.attr, &dev_attr_package_cpus_list.attr, #ifdef CONFIG_SCHED_BOOK diff --git a/include/linux/topology.h b/include/linux/topology.h index 5cc8595dd0e4..47a3e3c08036 100644 --- a/include/linux/topology.h +++ b/include/linux/topology.h @@ -196,6 +196,9 @@ static inline int cpu_to_mem(int cpu) #ifndef topology_core_cpumask #define topology_core_cpumask(cpu) cpumask_of(cpu) #endif +#ifndef topology_die_cpumask +#define topology_die_cpumask(cpu) cpumask_of(cpu) +#endif #ifdef CONFIG_SCHED_SMT static inline const struct cpumask *cpu_smt_mask(int cpu) -- cgit v1.2.3-59-g8ed1b From eabe3bc2689ad0993c57469eb7efb1291443cc74 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Wed, 15 May 2019 03:50:41 -0400 Subject: media: cec-ioc-receive.rst: document CEC_MSG_FL_RAW Document this new cec_msg flag. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/uapi/cec/cec-ioc-receive.rst | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/media/uapi/cec/cec-ioc-receive.rst b/Documentation/media/uapi/cec/cec-ioc-receive.rst index c3a685ff05cb..4137903d672e 100644 --- a/Documentation/media/uapi/cec/cec-ioc-receive.rst +++ b/Documentation/media/uapi/cec/cec-ioc-receive.rst @@ -223,6 +223,18 @@ View On' messages from initiator 0xf ('Unregistered') to destination 0 ('TV'). result of the :ref:`ioctl CEC_TRANSMIT `, and once via :ref:`ioctl CEC_RECEIVE `. + * .. _`CEC-MSG-FL-RAW`: + + - ``CEC_MSG_FL_RAW`` + - 2 + - Normally CEC messages are validated before transmitting them. If this + flag is set when :ref:`ioctl CEC_TRANSMIT ` is called, + then no validation takes place and the message is transmitted as-is. + This is useful when debugging CEC issues. + This flag is only allowed if the process has the ``CAP_SYS_RAWIO`` + capability. If that is not set, then the ``EPERM`` error code is + returned. + .. tabularcolumns:: |p{5.6cm}|p{0.9cm}|p{11.0cm}| @@ -358,7 +370,8 @@ ENOTTY EPERM The CEC adapter is not configured, i.e. :ref:`ioctl CEC_ADAP_S_LOG_ADDRS ` - has never been called. + has never been called, or ``CEC_MSG_FL_RAW`` was used from a process that + did not have the ``CAP_SYS_RAWIO`` capability. ENONET The CEC adapter is not configured, i.e. :ref:`ioctl CEC_ADAP_S_LOG_ADDRS ` -- cgit v1.2.3-59-g8ed1b From 428d3c867df6f2f87721fe7384ea09ad3130f839 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Wed, 22 May 2019 05:22:20 -0400 Subject: media: cec-ioc-g-mode.rst: be more specific when EPERM is returned Document which capability is required, rather than just saying that "root permissions" are required. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/media/uapi/cec/cec-ioc-g-mode.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/media/uapi/cec/cec-ioc-g-mode.rst b/Documentation/media/uapi/cec/cec-ioc-g-mode.rst index c53bb5f73f0d..d0902f356d65 100644 --- a/Documentation/media/uapi/cec/cec-ioc-g-mode.rst +++ b/Documentation/media/uapi/cec/cec-ioc-g-mode.rst @@ -294,7 +294,8 @@ EINVAL The requested mode is invalid. EPERM - Monitor mode is requested without having root permissions + Monitor mode is requested, but the process does have the ``CAP_NET_ADMIN`` + capability. EBUSY Someone else is already an exclusive follower or initiator. -- cgit v1.2.3-59-g8ed1b From cc0f6e96c4fd01fe1f935014c8c87ac6e994324c Mon Sep 17 00:00:00 2001 From: Rob Herring Date: Tue, 21 May 2019 16:23:24 -0500 Subject: spi: dt-bindings: Convert Arm pl022 to json-schema Convert the Arm pl022 binding to DT schema format. The clock binding was missing, so it is added to the schema. It really should be required as well, but there are some platforms (spear) not yet using DT clock binding. Cc: Mark Brown Cc: Linus Walleij Cc: linux-spi@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Rob Herring Signed-off-by: Mark Brown --- .../devicetree/bindings/spi/spi-pl022.yaml | 165 +++++++++++++++++++++ .../devicetree/bindings/spi/spi_pl022.txt | 70 --------- 2 files changed, 165 insertions(+), 70 deletions(-) create mode 100644 Documentation/devicetree/bindings/spi/spi-pl022.yaml delete mode 100644 Documentation/devicetree/bindings/spi/spi_pl022.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/spi-pl022.yaml b/Documentation/devicetree/bindings/spi/spi-pl022.yaml new file mode 100644 index 000000000000..dfb697c69341 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-pl022.yaml @@ -0,0 +1,165 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/spi-pl022.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM PL022 SPI controller + +maintainers: + - Linus Walleij + +allOf: + - $ref: "spi-controller.yaml#" + +# We need a select here so we don't match all nodes with 'arm,primecell' +select: + properties: + compatible: + contains: + const: arm,pl022 + required: + - compatible + +properties: + compatible: + items: + - const: arm,pl022 + - const: arm,primecell + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 2 + + clock-names: + items: + - enum: + - SSPCLK + - sspclk + - const: apb_pclk + + pl022,autosuspend-delay: + description: delay in ms following transfer completion before the + runtime power management system suspends the device. A setting of 0 + indicates no delay and the device will be suspended immediately. + $ref: "/schemas/types.yaml#/definitions/uint32" + + pl022,rt: + description: indicates the controller should run the message pump with realtime + priority to minimise the transfer latency on the bus (boolean) + type: boolean + + dmas: + description: + Two or more DMA channel specifiers following the convention outlined + in bindings/dma/dma.txt + minItems: 2 + maxItems: 32 + + dma-names: + description: + There must be at least one channel named "tx" for transmit and named "rx" + for receive. + minItems: 2 + maxItems: 32 + additionalItems: true + items: + - const: rx + - const: tx + +patternProperties: + "^[a-zA-Z][a-zA-Z0-9,+\\-._]{0,63}@[0-9a-f]+$": + type: object + # SPI slave nodes must be children of the SPI master node and can + # contain the following properties. + properties: + pl022,interface: + description: SPI interface type + allOf: + - $ref: "/schemas/types.yaml#/definitions/uint32" + - enum: + - 0 # SPI + - 1 # Texas Instruments Synchronous Serial Frame Format + - 2 # Microwire (Half Duplex) + + pl022,com-mode: + description: Specifies the transfer mode + allOf: + - $ref: "/schemas/types.yaml#/definitions/uint32" + - enum: + - 0 # interrupt mode + - 1 # polling mode + - 2 # DMA mode + default: 1 + + pl022,rx-level-trig: + description: Rx FIFO watermark level + allOf: + - $ref: "/schemas/types.yaml#/definitions/uint32" + - minimum: 0 + maximum: 4 + + pl022,tx-level-trig: + description: Tx FIFO watermark level + allOf: + - $ref: "/schemas/types.yaml#/definitions/uint32" + - minimum: 0 + maximum: 4 + + pl022,ctrl-len: + description: Microwire interface - Control length + allOf: + - $ref: "/schemas/types.yaml#/definitions/uint32" + - minimum: 0x03 + maximum: 0x1f + + pl022,wait-state: + description: Microwire interface - Wait state + allOf: + - $ref: "/schemas/types.yaml#/definitions/uint32" + - enum: [ 0, 1 ] + + pl022,duplex: + description: Microwire interface - Full/Half duplex + allOf: + - $ref: "/schemas/types.yaml#/definitions/uint32" + - enum: [ 0, 1 ] + +required: + - compatible + - reg + - interrupts + +examples: + - | + spi@e0100000 { + compatible = "arm,pl022", "arm,primecell"; + reg = <0xe0100000 0x1000>; + #address-cells = <1>; + #size-cells = <0>; + interrupts = <0 31 0x4>; + dmas = <&dma_controller 23 1>, + <&dma_controller 24 0>; + dma-names = "rx", "tx"; + + m25p80@1 { + compatible = "st,m25p80"; + reg = <1>; + spi-max-frequency = <12000000>; + spi-cpol; + spi-cpha; + pl022,interface = <0>; + pl022,com-mode = <0x2>; + pl022,rx-level-trig = <0>; + pl022,tx-level-trig = <0>; + pl022,ctrl-len = <0x11>; + pl022,wait-state = <0>; + pl022,duplex = <0>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/spi/spi_pl022.txt b/Documentation/devicetree/bindings/spi/spi_pl022.txt deleted file mode 100644 index 7638b4968ddb..000000000000 --- a/Documentation/devicetree/bindings/spi/spi_pl022.txt +++ /dev/null @@ -1,70 +0,0 @@ -ARM PL022 SPI controller - -Required properties: -- compatible : "arm,pl022", "arm,primecell" -- reg : Offset and length of the register set for the device -- interrupts : Should contain SPI controller interrupt -- num-cs : total number of chipselects - -Optional properties: -- cs-gpios : should specify GPIOs used for chipselects. - The gpios will be referred to as reg = in the SPI child nodes. - If unspecified, a single SPI device without a chip select can be used. -- pl022,autosuspend-delay : delay in ms following transfer completion before - the runtime power management system suspends the - device. A setting of 0 indicates no delay and the - device will be suspended immediately -- pl022,rt : indicates the controller should run the message pump with realtime - priority to minimise the transfer latency on the bus (boolean) -- dmas : Two or more DMA channel specifiers following the convention outlined - in bindings/dma/dma.txt -- dma-names: Names for the dma channels, if present. There must be at - least one channel named "tx" for transmit and named "rx" for - receive. - - -SPI slave nodes must be children of the SPI master node and can -contain the following properties. - -- pl022,interface : interface type: - 0: SPI - 1: Texas Instruments Synchronous Serial Frame Format - 2: Microwire (Half Duplex) -- pl022,com-mode : specifies the transfer mode: - 0: interrupt mode - 1: polling mode (default mode if property not present) - 2: DMA mode -- pl022,rx-level-trig : Rx FIFO watermark level -- pl022,tx-level-trig : Tx FIFO watermark level -- pl022,ctrl-len : Microwire interface: Control length -- pl022,wait-state : Microwire interface: Wait state -- pl022,duplex : Microwire interface: Full/Half duplex - - -Example: - - spi@e0100000 { - compatible = "arm,pl022", "arm,primecell"; - reg = <0xe0100000 0x1000>; - #address-cells = <1>; - #size-cells = <0>; - interrupts = <0 31 0x4>; - dmas = <&dma-controller 23 1>, - <&dma-controller 24 0>; - dma-names = "rx", "tx"; - - m25p80@1 { - compatible = "st,m25p80"; - reg = <1>; - spi-max-frequency = <12000000>; - spi-cpol; - spi-cpha; - pl022,interface = <0>; - pl022,com-mode = <0x2>; - pl022,rx-level-trig = <0>; - pl022,tx-level-trig = <0>; - pl022,ctrl-len = <0x11>; - pl022,wait-state = <0>; - pl022,duplex = <0>; - }; - }; -- cgit v1.2.3-59-g8ed1b From 1305d97b7c7847b12872818326f0cb4da0439311 Mon Sep 17 00:00:00 2001 From: Lubomir Rintel Date: Sun, 5 May 2019 10:00:22 -0400 Subject: media: dt-bindings: marvell,mmp2-ccic: Add Marvell MMP2 camera Add Marvell MMP2 camera host interface. Signed-off-by: Lubomir Rintel Reviewed-by: Rob Herring Signed-off-by: Sakari Ailus Signed-off-by: Mauro Carvalho Chehab --- .../bindings/media/marvell,mmp2-ccic.txt | 50 ++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/marvell,mmp2-ccic.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.txt b/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.txt new file mode 100644 index 000000000000..7ec2c8c8a3b9 --- /dev/null +++ b/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.txt @@ -0,0 +1,50 @@ +Marvell MMP2 camera host interface + +Required properties: + - compatible: Should be "marvell,mmp2-ccic". + - reg: Register base and size. + - interrupts: The interrupt number. + - #clock-cells: Must be 0. + +Optional properties: + - clocks: Reference to the input clock as specified by + Documentation/devicetree/bindings/clock/clock-bindings.txt. + - clock-names: Names of the clocks used; "axi" for the AXI bus interface, + "func" for the peripheral clock and "phy" for the parallel + video bus interface. + - clock-output-names: Optional clock source for sensors. Shall be "mclk". + +Required subnodes: + - port: The parallel bus interface port with a single endpoint linked to + the sensor's endpoint as described in + Documentation/devicetree/bindings/media/video-interfaces.txt. + +Required endpoint properties: + - bus-type: data bus type, <5> or <6> for Parallel or Bt.656 respectively + - pclk-sample: pixel clock polarity + - hsync-active: horizontal synchronization polarity (only required for + parallel bus) + - vsync-active: vertical synchronization polarity (only required for + parallel bus) + +Example: + + camera0: camera@d420a000 { + compatible = "marvell,mmp2-ccic"; + reg = <0xd420a000 0x800>; + interrupts = <42>; + clocks = <&soc_clocks MMP2_CLK_CCIC0>; + clock-names = "axi"; + #clock-cells = <0>; + clock-output-names = "mclk"; + + port { + camera0_0: endpoint { + remote-endpoint = <&ov7670_0>; + bus-type = <5>; /* Parallel */ + hsync-active = <1>; /* Active high */ + vsync-active = <1>; /* Active high */ + pclk-sample = <0>; /* Falling */ + }; + }; + }; -- cgit v1.2.3-59-g8ed1b From 9db9b76767f133d0e1ce19f01117c83221641899 Mon Sep 17 00:00:00 2001 From: Ira Weiny Date: Mon, 20 May 2019 13:52:53 -0700 Subject: Documentation/x86: Fix path to entry_32.S Signed-off-by: Ira Weiny Cc: Jonathan Corbet Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-doc@vger.kernel.org Link: http://lkml.kernel.org/r/20190520205253.23762-1-ira.weiny@intel.com [ Adjusted the patch to the RST conversion. ] Signed-off-by: Ingo Molnar --- Documentation/x86/exception-tables.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/x86/exception-tables.rst b/Documentation/x86/exception-tables.rst index 24596c8210b5..ed6d4b0cf62c 100644 --- a/Documentation/x86/exception-tables.rst +++ b/Documentation/x86/exception-tables.rst @@ -35,7 +35,7 @@ page fault handler:: void do_page_fault(struct pt_regs *regs, unsigned long error_code) in arch/x86/mm/fault.c. The parameters on the stack are set up by -the low level assembly glue in arch/x86/kernel/entry_32.S. The parameter +the low level assembly glue in arch/x86/entry/entry_32.S. The parameter regs is a pointer to the saved registers on the stack, error_code contains a reason code for the exception. -- cgit v1.2.3-59-g8ed1b From 909fa3321d348ef69366aad9e84e1dd9ee0bd060 Mon Sep 17 00:00:00 2001 From: Stephen Rothwell Date: Thu, 23 May 2019 13:21:51 +0200 Subject: dt-bindings: fix up for vendor prefixes file conversion Link: Link: http://patchwork.freedesktop.org/patch/msgid/20190521105151.51ffa942@canb.auug.org.au Fixes: 374ed5429346 ("Merge drm/drm-next into drm-misc-next") Signed-off-by: Stephen Rothwell Signed-off-by: Maxime Ripard --- .../devicetree/bindings/vendor-prefixes.txt | 468 --------------------- .../devicetree/bindings/vendor-prefixes.yaml | 6 + 2 files changed, 6 insertions(+), 468 deletions(-) delete mode 100644 Documentation/devicetree/bindings/vendor-prefixes.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt deleted file mode 100644 index 873dbafa6698..000000000000 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ /dev/null @@ -1,468 +0,0 @@ -Device tree binding vendor prefix registry. Keep list in alphabetical order. - -This isn't an exhaustive list, but you should add new prefixes to it before -using them to avoid name-space collisions. - -abilis Abilis Systems -abracon Abracon Corporation -actions Actions Semiconductor Co., Ltd. -active-semi Active-Semi International Inc -ad Avionic Design GmbH -adafruit Adafruit Industries, LLC -adapteva Adapteva, Inc. -adaptrum Adaptrum, Inc. -adh AD Holdings Plc. -adi Analog Devices, Inc. -advantech Advantech Corporation -aeroflexgaisler Aeroflex Gaisler AB -al Annapurna Labs -allo Allo.com -allwinner Allwinner Technology Co., Ltd. -alphascale AlphaScale Integrated Circuits Systems, Inc. -altr Altera Corp. -amarula Amarula Solutions -amazon Amazon.com, Inc. -amcc Applied Micro Circuits Corporation (APM, formally AMCC) -amd Advanced Micro Devices (AMD), Inc. -amediatech Shenzhen Amediatech Technology Co., Ltd -amlogic Amlogic, Inc. -ampire Ampire Co., Ltd. -ams AMS AG -amstaos AMS-Taos Inc. -analogix Analogix Semiconductor, Inc. -andestech Andes Technology Corporation -apm Applied Micro Circuits Corporation (APM) -aptina Aptina Imaging -arasan Arasan Chip Systems -archermind ArcherMind Technology (Nanjing) Co., Ltd. -arctic Arctic Sand -aries Aries Embedded GmbH -arm ARM Ltd. -armadeus ARMadeus Systems SARL -arrow Arrow Electronics -artesyn Artesyn Embedded Technologies Inc. -asahi-kasei Asahi Kasei Corp. -aspeed ASPEED Technology Inc. -asus AsusTek Computer Inc. -atlas Atlas Scientific LLC -atmel Atmel Corporation -auo AU Optronics Corporation -auvidea Auvidea GmbH -avago Avago Technologies -avia avia semiconductor -avic Shanghai AVIC Optoelectronics Co., Ltd. -avnet Avnet, Inc. -axentia Axentia Technologies AB -axis Axis Communications AB -bananapi BIPAI KEJI LIMITED -bhf Beckhoff Automation GmbH & Co. KG -bitmain Bitmain Technologies -boe BOE Technology Group Co., Ltd. -bosch Bosch Sensortec GmbH -boundary Boundary Devices Inc. -brcm Broadcom Corporation -buffalo Buffalo, Inc. -bticino Bticino International -calxeda Calxeda -capella Capella Microsystems, Inc -cascoda Cascoda, Ltd. -catalyst Catalyst Semiconductor, Inc. -cavium Cavium, Inc. -cdns Cadence Design Systems Inc. -cdtech CDTech(H.K.) Electronics Limited -ceva Ceva, Inc. -chipidea Chipidea, Inc -chipone ChipOne -chipspark ChipSPARK -chrp Common Hardware Reference Platform -chunghwa Chunghwa Picture Tubes Ltd. -ciaa Computadora Industrial Abierta Argentina -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 -crane Crane Connectivity Solutions -creative Creative Technology Ltd -crystalfontz Crystalfontz America, Inc. -csky Hangzhou C-SKY Microsystems Co., Ltd -cubietech Cubietech, Ltd. -cypress Cypress Semiconductor Corporation -cznic CZ.NIC, z.s.p.o. -dallas Maxim Integrated Products (formerly Dallas Semiconductor) -dataimage DataImage, Inc. -davicom DAVICOM Semiconductor, Inc. -delta Delta Electronics, Inc. -denx Denx Software Engineering -devantech Devantech, Ltd. -dh DH electronics GmbH -digi Digi International Inc. -digilent Diglent, Inc. -dioo Dioo Microcircuit Co., Ltd -dlc DLC Display Co., Ltd. -dlg Dialog Semiconductor -dlink D-Link Corporation -dmo Data Modul AG -domintech Domintech Co., Ltd. -dongwoon Dongwoon Anatech -dptechnics DPTechnics -dragino Dragino Technology Co., Limited -ea Embedded Artists AB -ebs-systart EBS-SYSTART GmbH -ebv EBV Elektronik -eckelmann Eckelmann AG -edt Emerging Display Technologies -eeti eGalax_eMPIA Technology Inc -elan Elan Microelectronic Corp. -elgin Elgin S/A. -embest Shenzhen Embest Technology Co., Ltd. -emlid Emlid, Ltd. -emmicro EM Microelectronic -emtrion emtrion GmbH -endless Endless Mobile, Inc. -energymicro Silicon Laboratories (formerly Energy Micro AS) -engicam Engicam S.r.l. -epcos EPCOS AG -epfl Ecole Polytechnique Fédérale de Lausanne -epson Seiko Epson Corp. -est ESTeem Wireless Modems -ettus NI Ettus Research -eukrea Eukréa Electromatique -everest Everest Semiconductor Co. Ltd. -everspin Everspin Technologies, Inc. -evervision Evervision Electronics Co. Ltd. -exar Exar Corporation -excito Excito -ezchip EZchip Semiconductor -facebook Facebook -fairphone Fairphone B.V. -faraday Faraday Technology Corporation -fastrax Fastrax Oy -fcs Fairchild Semiconductor -feiyang Shenzhen Fly Young Technology Co.,LTD. -firefly Firefly -focaltech FocalTech Systems Co.,Ltd -friendlyarm Guangzhou FriendlyARM Computer Tech Co., Ltd -fsl Freescale Semiconductor -fujitsu Fujitsu Ltd. -gateworks Gateworks Corporation -gcw Game Consoles Worldwide -ge General Electric Company -geekbuying GeekBuying -gef GE Fanuc Intelligent Platforms Embedded Systems, Inc. -GEFanuc GE Fanuc Intelligent Platforms Embedded Systems, Inc. -geniatech Geniatech, Inc. -giantec Giantec Semiconductor, Inc. -giantplus Giantplus Technology Co., Ltd. -globalscale Globalscale Technologies, Inc. -globaltop GlobalTop Technology, Inc. -gmt Global Mixed-mode Technology, Inc. -goodix Shenzhen Huiding Technology Co., Ltd. -google Google, Inc. -grinn Grinn -grmn Garmin Limited -gumstix Gumstix, Inc. -gw Gateworks Corporation -hannstar HannStar Display Corporation -haoyu Haoyu Microelectronic Co. Ltd. -hardkernel Hardkernel Co., Ltd -hideep HiDeep Inc. -himax Himax Technologies, Inc. -hisilicon Hisilicon Limited. -hit Hitachi Ltd. -hitex Hitex Development Tools -holt Holt Integrated Circuits, Inc. -honeywell Honeywell -hp Hewlett Packard -holtek Holtek Semiconductor, Inc. -hwacom HwaCom Systems Inc. -i2se I2SE GmbH -ibm International Business Machines (IBM) -icplus IC Plus Corp. -idt Integrated Device Technologies, Inc. -ifi Ingenieurburo Fur Ic-Technologie (I/F/I) -ilitek ILI Technology Corporation (ILITEK) -img Imagination Technologies Ltd. -infineon Infineon Technologies -inforce Inforce Computing -ingenic Ingenic Semiconductor -innolux Innolux Corporation -inside-secure INSIDE Secure -intel Intel Corporation -intercontrol Inter Control Group -invensense InvenSense Inc. -inversepath Inverse Path -iom Iomega Corporation -isee ISEE 2007 S.L. -isil Intersil -issi Integrated Silicon Solutions Inc. -itead ITEAD Intelligent Systems Co.Ltd -iwave iWave Systems Technologies Pvt. Ltd. -jdi Japan Display Inc. -jedec JEDEC Solid State Technology Association -jianda Jiandangjing Technology Co., Ltd. -karo Ka-Ro electronics GmbH -keithkoep Keith & Koep GmbH -keymile Keymile GmbH -khadas Khadas -kiebackpeter Kieback & Peter GmbH -kinetic Kinetic Technologies -kingdisplay King & Display Technology Co., Ltd. -kingnovel Kingnovel Technology Co., Ltd. -koe Kaohsiung Opto-Electronics Inc. -kosagi Sutajio Ko-Usagi PTE Ltd. -kyo Kyocera Corporation -lacie LaCie -laird Laird PLC -lantiq Lantiq Semiconductor -lattice Lattice Semiconductor -lego LEGO Systems A/S -lemaker Shenzhen LeMaker Technology Co., Ltd. -lenovo Lenovo Group Ltd. -lg LG Corporation -libretech Shenzhen Libre Technology Co., Ltd -licheepi Lichee Pi -linaro Linaro Limited -linksys Belkin International, Inc. (Linksys) -linux Linux-specific binding -linx Linx Technologies -lltc Linear Technology Corporation -logicpd Logic PD, Inc. -lsi LSI Corp. (LSI Logic) -lwn Liebherr-Werk Nenzing GmbH -macnica Macnica Americas -marvell Marvell Technology Group Ltd. -maxim Maxim Integrated Products -mbvl Mobiveil Inc. -mcube mCube -meas Measurement Specialties -mediatek MediaTek Inc. -megachips MegaChips -mele Shenzhen MeLE Digital Technology Ltd. -melexis Melexis N.V. -melfas MELFAS Inc. -mellanox Mellanox Technologies -memsic MEMSIC Inc. -merrii Merrii Technology Co., Ltd. -micrel Micrel Inc. -microchip Microchip Technology Inc. -microcrystal Micro Crystal AG -micron Micron Technology Inc. -mikroe MikroElektronika d.o.o. -minix MINIX Technology Ltd. -miramems MiraMEMS Sensing Technology Co., Ltd. -mitsubishi Mitsubishi Electric Corporation -mosaixtech Mosaix Technologies, Inc. -motorola Motorola, Inc. -moxa Moxa Inc. -mpl MPL AG -mqmaker mqmaker Inc. -mscc Microsemi Corporation -msi Micro-Star International Co. Ltd. -mti Imagination Technologies Ltd. (formerly MIPS Technologies Inc.) -multi-inno Multi-Inno Technology Co.,Ltd -mundoreader Mundo Reader S.L. -murata Murata Manufacturing Co., Ltd. -mxicy Macronix International Co., Ltd. -myir MYIR Tech Limited -national National Semiconductor -nec NEC LCD Technologies, Ltd. -neonode Neonode Inc. -netgear NETGEAR -netlogic Broadcom Corporation (formerly NetLogic Microsystems) -netron-dy Netron DY -netxeon Shenzhen Netxeon Technology CO., LTD -nexbox Nexbox -nextthing Next Thing Co. -newhaven Newhaven Display International -ni National Instruments -nintendo Nintendo -nlt NLT Technologies, Ltd. -nokia Nokia -nordic Nordic Semiconductor -novtech NovTech, Inc. -nutsboard NutsBoard -nuvoton Nuvoton Technology Corporation -nvd New Vision Display -nvidia NVIDIA -nxp NXP Semiconductors -okaya Okaya Electric America, Inc. -oki Oki Electric Industry Co., Ltd. -olimex OLIMEX Ltd. -olpc One Laptop Per Child -onion Onion Corporation -onnn ON Semiconductor Corp. -ontat On Tat Industrial Company -opalkelly Opal Kelly Incorporated -opencores OpenCores.org -openrisc OpenRISC.io -option Option NV -oranth Shenzhen Oranth Technology Co., Ltd. -ORCL Oracle Corporation -orisetech Orise Technology -ortustech Ortus Technology Co., Ltd. -osddisplays OSD Displays -ovti OmniVision Technologies -oxsemi Oxford Semiconductor, Ltd. -panasonic Panasonic Corporation -parade Parade Technologies Inc. -pda Precision Design Associates, Inc. -pericom Pericom Technology Inc. -pervasive Pervasive Displays, Inc. -phicomm PHICOMM Co., Ltd. -phytec PHYTEC Messtechnik GmbH -picochip Picochip Ltd -pine64 Pine64 -pixcir PIXCIR MICROELECTRONICS Co., Ltd -plantower Plantower Co., Ltd -plathome Plat'Home Co., Ltd. -plda PLDA -plx Broadcom Corporation (formerly PLX Technology) -pni PNI Sensor Corporation -portwell Portwell Inc. -poslab Poslab Technology Co., Ltd. -powervr PowerVR (deprecated, use img) -probox2 PROBOX2 (by W2COMP Co., Ltd.) -pulsedlight PulsedLight, Inc -qca Qualcomm Atheros, Inc. -qcom Qualcomm Technologies, Inc -qemu QEMU, a generic and open source machine emulator and virtualizer -qi Qi Hardware -qiaodian QiaoDian XianShi Corporation -qnap QNAP Systems, Inc. -radxa Radxa -raidsonic RaidSonic Technology GmbH -ralink Mediatek/Ralink Technology Corp. -ramtron Ramtron International -raspberrypi Raspberry Pi Foundation -raydium Raydium Semiconductor Corp. -rda Unisoc Communications, Inc. -realtek Realtek Semiconductor Corp. -renesas Renesas Electronics Corporation -richtek Richtek Technology Corporation -ricoh Ricoh Co. Ltd. -rikomagic Rikomagic Tech Corp. Ltd -riscv RISC-V Foundation -rockchip Fuzhou Rockchip Electronics Co., Ltd -rocktech ROCKTECH DISPLAYS LIMITED -rohm ROHM Semiconductor Co., Ltd -ronbo Ronbo Electronics -roofull Shenzhen Roofull Technology Co, Ltd -samsung Samsung Semiconductor -samtec Samtec/Softing company -sancloud Sancloud Ltd -sandisk Sandisk Corporation -sbs Smart Battery System -schindler Schindler -seagate Seagate Technology PLC -semtech Semtech Corporation -sensirion Sensirion AG -sff Small Form Factor Committee -sgd Solomon Goldentek Display Corporation -sgx SGX Sensortech -sharp Sharp Corporation -shimafuji Shimafuji Electric, Inc. -si-en Si-En Technology Ltd. -sifive SiFive, Inc. -sigma Sigma Designs, Inc. -sii Seiko Instruments, Inc. -sil Silicon Image -silabs Silicon Laboratories -silead Silead Inc. -silergy Silergy Corp. -siliconmitus Silicon Mitus, Inc. -simtek -sirf SiRF Technology, Inc. -sis Silicon Integrated Systems Corp. -sitronix Sitronix Technology Corporation -skyworks Skyworks Solutions, Inc. -smsc Standard Microsystems Corporation -snps Synopsys, Inc. -socionext Socionext Inc. -solidrun SolidRun -solomon Solomon Systech Limited -sony Sony Corporation -spansion Spansion Inc. -sprd Spreadtrum Communications Inc. -sst Silicon Storage Technology, Inc. -st STMicroelectronics -starry Starry Electronic Technology (ShenZhen) Co., LTD -startek Startek -ste ST-Ericsson -stericsson ST-Ericsson -summit Summit microelectronics -sunchip Shenzhen Sunchip Technology Co., Ltd -SUNW Sun Microsystems, Inc -swir Sierra Wireless -syna Synaptics Inc. -synology Synology, Inc. -tbs TBS Technologies -tbs-biometrics Touchless Biometric Systems AG -tcg Trusted Computing Group -tcl Toby Churchill Ltd. -technexion TechNexion -technologic Technologic Systems -tempo Tempo Semiconductor -techstar Shenzhen Techstar Electronics Co., Ltd. -terasic Terasic Inc. -tfc Three Five Corp -thine THine Electronics, Inc. -ti Texas Instruments -tianma Tianma Micro-electronics Co., Ltd. -tlm Trusted Logic Mobility -tmt Tecon Microprocessor Technologies, LLC. -topeet Topeet -toradex Toradex AG -toshiba Toshiba Corporation -toumaz Toumaz -tpk TPK U.S.A. LLC -tplink TP-LINK Technologies Co., Ltd. -tpo TPO -tronfy Tronfy -tronsmart Tronsmart -truly Truly Semiconductors Limited -tsd Theobroma Systems Design und Consulting GmbH -tyan Tyan Computer Corporation -u-blox u-blox -ucrobotics uCRobotics -ubnt Ubiquiti Networks -udoo Udoo -uniwest United Western Technologies Corp (UniWest) -upisemi uPI Semiconductor Corp. -urt United Radiant Technology Corporation -usi Universal Scientific Industrial Co., Ltd. -v3 V3 Semiconductor -vamrs Vamrs Ltd. -variscite Variscite Ltd. -via VIA Technologies, Inc. -virtio Virtual I/O Device Specification, developed by the OASIS consortium -vishay Vishay Intertechnology, Inc -vitesse Vitesse Semiconductor Corporation -vivante Vivante Corporation -vocore VoCore Studio -voipac Voipac Technologies s.r.o. -vot Vision Optical Technology Co., Ltd. -vxt VXT Ltd -wd Western Digital Corp. -wetek WeTek Electronics, limited. -wexler Wexler -whwave Shenzhen whwave Electronics, Inc. -wi2wi Wi2Wi, Inc. -winbond Winbond Electronics corp. -winstar Winstar Display Corp. -wlf Wolfson Microelectronics -wm Wondermedia Technologies, Inc. -x-powers X-Powers -xes Extreme Engineering Solutions (X-ES) -xillybus Xillybus Ltd. -xlnx Xilinx -xunlong Shenzhen Xunlong Software CO.,Limited -ysoft Y Soft Corporation a.s. -zarlink Zarlink Semiconductor -zeitec ZEITEC Semiconductor Co., LTD. -zidoo Shenzhen Zidoo Technology Co., Ltd. -zii Zodiac Inflight Innovations -zte ZTE Corp. -zyxel ZyXEL Communications Corp. diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 33a65a45e319..f0bcff033ecc 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -287,6 +287,8 @@ patternProperties: description: Everest Semiconductor Co. Ltd. "^everspin,.*": description: Everspin Technologies, Inc. + "^evervision,.*": + description: Evervision Electronics Co. Ltd. "^exar,.*": description: Exar Corporation "^excito,.*": @@ -849,6 +851,8 @@ patternProperties: description: Shenzhen Techstar Electronics Co., Ltd. "^terasic,.*": description: Terasic Inc. + "^tfc,.*": + description: Three Five Corp "^thine,.*": description: THine Electronics, Inc. "^ti,.*": @@ -923,6 +927,8 @@ patternProperties: description: Voipac Technologies s.r.o. "^vot,.*": description: Vision Optical Technology Co., Ltd. + "^vxt,.*": + description: VXT Ltd "^wd,.*": description: Western Digital Corp. "^wetek,.*": -- cgit v1.2.3-59-g8ed1b From 2c9239c125f0c657d2955780f364168d4c15aa8b Mon Sep 17 00:00:00 2001 From: Alexandre Torgue Date: Fri, 10 May 2019 17:45:26 +0200 Subject: dt-bindings: pinctrl: Convert stm32 pinctrl bindings to json-schema Convert the STM32 pinctrl binding to DT schema format using json-schema. Signed-off-by: Alexandre Torgue Reviewed-by: Rob Herring Signed-off-by: Linus Walleij --- .../bindings/pinctrl/st,stm32-pinctrl.txt | 208 ---------------- .../bindings/pinctrl/st,stm32-pinctrl.yaml | 264 +++++++++++++++++++++ 2 files changed, 264 insertions(+), 208 deletions(-) delete mode 100644 Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt create mode 100644 Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt deleted file mode 100644 index 00169255e48c..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.txt +++ /dev/null @@ -1,208 +0,0 @@ -* STM32 GPIO and Pin Mux/Config controller - -STMicroelectronics's STM32 MCUs intregrate a GPIO and Pin mux/config hardware -controller. It controls the input/output settings on the available pins and -also provides ability to multiplex and configure the output of various on-chip -controllers onto these pads. - -Pin controller node: -Required properies: - - compatible: value should be one of the following: - "st,stm32f429-pinctrl" - "st,stm32f469-pinctrl" - "st,stm32f746-pinctrl" - "st,stm32f769-pinctrl" - "st,stm32h743-pinctrl" - "st,stm32mp157-pinctrl" - "st,stm32mp157-z-pinctrl" - - #address-cells: The value of this property must be 1 - - #size-cells : The value of this property must be 1 - - ranges : defines mapping between pin controller node (parent) to - gpio-bank node (children). - - pins-are-numbered: Specify the subnodes are using numbered pinmux to - specify pins. - -GPIO controller/bank node: -Required properties: - - gpio-controller : Indicates this device is a GPIO controller - - #gpio-cells : Should be two. - The first cell is the pin number - The second one is the polarity: - - 0 for active high - - 1 for active low - - reg : The gpio address range, relative to the pinctrl range - - clocks : clock that drives this bank - - st,bank-name : Should be a name string for this bank as specified in - the datasheet - -Optional properties: - - reset: : Reference to the reset controller - - st,syscfg: Should be phandle/offset/mask. - -The phandle to the syscon node which includes IRQ mux selection register. - -The offset of the IRQ mux selection register - -The field mask of IRQ mux, needed if different of 0xf. - - gpio-ranges: Define a dedicated mapping between a pin-controller and - a gpio controller. Format is <&phandle a b c> with: - -(phandle): phandle of pin-controller. - -(a): gpio base offset in range. - -(b): pin base offset in range. - -(c): gpio count in range - This entry has to be used either if there are holes inside a bank: - GPIOB0/B1/B2/B14/B15 (see example 2) - or if banks are not contiguous: - GPIOA/B/C/E... - NOTE: If "gpio-ranges" is used for a gpio controller, all gpio-controller - have to use a "gpio-ranges" entry. - More details in Documentation/devicetree/bindings/gpio/gpio.txt. - - st,bank-ioport: should correspond to the EXTI IOport selection (EXTI line - used to select GPIOs as interrupts). - - hwlocks: reference to a phandle of a hardware spinlock provider node. - - st,package: Indicates the SOC package used. - More details in include/dt-bindings/pinctrl/stm32-pinfunc.h - -Example 1: -#include -... - - pin-controller { - #address-cells = <1>; - #size-cells = <1>; - compatible = "st,stm32f429-pinctrl"; - ranges = <0 0x40020000 0x3000>; - pins-are-numbered; - - gpioa: gpio@40020000 { - gpio-controller; - #gpio-cells = <2>; - reg = <0x0 0x400>; - resets = <&reset_ahb1 0>; - st,bank-name = "GPIOA"; - }; - ... - pin-functions nodes follow... - }; - -Example 2: -#include -... - - pinctrl: pin-controller { - #address-cells = <1>; - #size-cells = <1>; - compatible = "st,stm32f429-pinctrl"; - ranges = <0 0x40020000 0x3000>; - pins-are-numbered; - - gpioa: gpio@40020000 { - gpio-controller; - #gpio-cells = <2>; - reg = <0x0 0x400>; - resets = <&reset_ahb1 0>; - st,bank-name = "GPIOA"; - gpio-ranges = <&pinctrl 0 0 16>; - }; - - gpiob: gpio@40020400 { - gpio-controller; - #gpio-cells = <2>; - reg = <0x0 0x400>; - resets = <&reset_ahb1 0>; - st,bank-name = "GPIOB"; - ngpios = 4; - gpio-ranges = <&pinctrl 0 16 3>, - <&pinctrl 14 30 2>; - }; - - - ... - pin-functions nodes follow... - }; - - -Contents of function subnode node: ----------------------------------- -Subnode format -A pinctrl node should contain at least one subnode representing the -pinctrl group available on the machine. Each subnode will list the -pins it needs, and how they should be configured, with regard to muxer -configuration, pullups, drive, output high/low and output speed. - - node { - pinmux = ; - GENERIC_PINCONFIG; - }; - -Required properties: -- pinmux: integer array, represents gpio pin number and mux setting. - Supported pin number and mux varies for different SoCs, and are defined in - dt-bindings/pinctrl/-pinfunc.h directly. - These defines are calculated as: - ((port * 16 + line) << 8) | function - With: - - port: The gpio port index (PA = 0, PB = 1, ..., PK = 11) - - line: The line offset within the port (PA0 = 0, PA1 = 1, ..., PA15 = 15) - - function: The function number, can be: - * 0 : GPIO - * 1 : Alternate Function 0 - * 2 : Alternate Function 1 - * 3 : Alternate Function 2 - * ... - * 16 : Alternate Function 15 - * 17 : Analog - - To simplify the usage, macro is available to generate "pinmux" field. - This macro is available here: - - include/dt-bindings/pinctrl/stm32-pinfunc.h - - Some examples of using macro: - /* GPIO A9 set as alernate function 2 */ - ... { - pinmux = ; - }; - /* GPIO A9 set as GPIO */ - ... { - pinmux = ; - }; - /* GPIO A9 set as analog */ - ... { - pinmux = ; - }; - -Optional properties: -- GENERIC_PINCONFIG: is the generic pinconfig options to use. - Available options are: - - bias-disable, - - bias-pull-down, - - bias-pull-up, - - drive-push-pull, - - drive-open-drain, - - output-low - - output-high - - slew-rate = , with x being: - < 0 > : Low speed - < 1 > : Medium speed - < 2 > : Fast speed - < 3 > : High speed - -Example: - -pin-controller { -... - usart1_pins_a: usart1@0 { - pins1 { - pinmux = ; - bias-disable; - drive-push-pull; - slew-rate = <0>; - }; - pins2 { - pinmux = ; - bias-disable; - }; - }; -}; - -&usart1 { - pinctrl-0 = <&usart1_pins_a>; - pinctrl-names = "default"; -}; diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml new file mode 100644 index 000000000000..06c4b66c3ee6 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml @@ -0,0 +1,264 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright (C) STMicroelectronics 2019. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/st,stm32-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STM32 GPIO and Pin Mux/Config controller + +maintainers: + - Alexandre TORGUE + +description: | + STMicroelectronics's STM32 MCUs intregrate a GPIO and Pin mux/config hardware + controller. It controls the input/output settings on the available pins and + also provides ability to multiplex and configure the output of various + on-chip controllers onto these pads. + +properties: + compatible: + enum: + - st,stm32f429-pinctrl + - st,stm32f469-pinctrl + - st,stm32f746-pinctrl + - st,stm32f769-pinctrl + - st,stm32h743-pinctrl + - st,stm32mp157-pinctrl + - st,stm32mp157-z-pinctrl + + '#address-cells': + const: 1 + '#size-cells': + const: 1 + + ranges: true + pins-are-numbered: true + hwlocks: true + + st,syscfg: + $ref: "/schemas/types.yaml#/definitions/phandle-array" + description: Should be phandle/offset/mask + items: + - description: Phandle to the syscon node which includes IRQ mux selection. + - description: The offset of the IRQ mux selection register. + - description: The field mask of IRQ mux, needed if different of 0xf. + + st,package: + allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 + - enum: [1, 2, 4, 8] + description: + Indicates the SOC package used. + More details in include/dt-bindings/pinctrl/stm32-pinfunc.h + + +patternProperties: + '^gpio@[0-9a-f]*$': + properties: + gpio-controller: true + '#gpio-cells': + const: 2 + + reg: + maxItems: 1 + clocks: + maxItems: 1 + reset: + minItems: 1 + maxItems: 1 + gpio-ranges: + minItems: 1 + maxItems: 16 + ngpios: + description: + Number of available gpios in a bank. + minimum: 1 + maximum: 16 + + st,bank-name: + allOf: + - $ref: "/schemas/types.yaml#/definitions/string" + - enum: + - GPIOA + - GPIOB + - GPIOC + - GPIOD + - GPIOE + - GPIOF + - GPIOG + - GPIOH + - GPIOI + - GPIOJ + - GPIOK + - GPIOZ + description: + Should be a name string for this bank as specified in the datasheet. + + st,bank-ioport: + allOf: + - $ref: "/schemas/types.yaml#/definitions/uint32" + - minimum: 0 + - maximum: 11 + + description: + Should correspond to the EXTI IOport selection (EXTI line used + to select GPIOs as interrupts). + + required: + - gpio-controller + - '#gpio-cells' + - reg + - clocks + - st,bank-name + + '-[0-9]*$': + patternProperties: + '^pins': + description: | + A pinctrl node should contain at least one subnode representing the + pinctrl group available on the machine. Each subnode will list the + pins it needs, and how they should be configured, with regard to muxer + configuration, pullups, drive, output high/low and output speed. + properties: + pinmux: + allOf: + - $ref: "/schemas/types.yaml#/definitions/uint32-array" + description: | + Integer array, represents gpio pin number and mux setting. + Supported pin number and mux varies for different SoCs, and are + defined in dt-bindings/pinctrl/-pinfunc.h directly. + These defines are calculated as: ((port * 16 + line) << 8) | function + With: + - port: The gpio port index (PA = 0, PB = 1, ..., PK = 11) + - line: The line offset within the port (PA0 = 0, PA1 = 1, ..., PA15 = 15) + - function: The function number, can be: + * 0 : GPIO + * 1 : Alternate Function 0 + * 2 : Alternate Function 1 + * 3 : Alternate Function 2 + * ... + * 16 : Alternate Function 15 + * 17 : Analog + To simplify the usage, macro is available to generate "pinmux" field. + This macro is available here: + - include/dt-bindings/pinctrl/stm32-pinfunc.h + Some examples of using macro: + /* GPIO A9 set as alernate function 2 */ + ... { + pinmux = ; + }; + /* GPIO A9 set as GPIO */ + ... { + pinmux = ; + }; + /* GPIO A9 set as analog */ + ... { + pinmux = ; + }; + + bias-disable: + type: boolean + bias-pull-down: + type: boolean + bias-pull-up: + type: boolean + drive-push-pull: + type: boolean + drive-open-drain: + type: boolean + output-low: + type: boolean + output-high: + type: boolean + slew-rate: + description: | + 0: Low speed + 1: Medium speed + 2: Fast speed + 3: High speed + allOf: + - $ref: /schemas/types.yaml#/definitions/uint32 + - enum: [0, 1, 2, 3] + + required: + - pinmux + +required: + - compatible + - '#address-cells' + - '#size-cells' + - ranges + - pins-are-numbered + +examples: + - | + #include + //Example 1 + pinctrl@40020000 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "st,stm32f429-pinctrl"; + ranges = <0 0x40020000 0x3000>; + pins-are-numbered; + + gpioa: gpio@0 { + gpio-controller; + #gpio-cells = <2>; + reg = <0x0 0x400>; + resets = <&reset_ahb1 0>; + st,bank-name = "GPIOA"; + }; + }; + + //Example 2 (using gpio-ranges) + pinctrl@50020000 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "st,stm32f429-pinctrl"; + ranges = <0 0x50020000 0x3000>; + pins-are-numbered; + + gpiob: gpio@1000 { + gpio-controller; + #gpio-cells = <2>; + reg = <0x1000 0x400>; + resets = <&reset_ahb1 0>; + st,bank-name = "GPIOB"; + gpio-ranges = <&pinctrl 0 0 16>; + }; + + gpioc: gpio@2000 { + gpio-controller; + #gpio-cells = <2>; + reg = <0x2000 0x400>; + resets = <&reset_ahb1 0>; + st,bank-name = "GPIOC"; + ngpios = <5>; + gpio-ranges = <&pinctrl 0 16 3>, + <&pinctrl 14 30 2>; + }; + }; + + //Example 3 pin groups + pinctrl@60020000 { + usart1_pins_a: usart1-0 { + pins1 { + pinmux = ; + bias-disable; + drive-push-pull; + slew-rate = <0>; + }; + pins2 { + pinmux = ; + bias-disable; + }; + }; + }; + + usart1 { + pinctrl-0 = <&usart1_pins_a>; + pinctrl-names = "default"; + }; + +... -- cgit v1.2.3-59-g8ed1b From 1254db248fce4e2cf05a01c1c8df3b79745424c0 Mon Sep 17 00:00:00 2001 From: Jerome Brunet Date: Thu, 16 May 2019 17:13:38 +0200 Subject: dt-bindings: pinctrl: meson: add output support in pinconf add support for the pinconf DT property output-enable, output-disable, output-low and output-high in the meson pinctrl driver. Signed-off-by: Jerome Brunet Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt index a7618605bf1e..10dc4f7176ca 100644 --- a/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt @@ -47,9 +47,15 @@ Required properties for pinmux nodes are: Required properties for configuration nodes: - pins: a list of pin names -Configuration nodes support the generic properties "bias-disable", -"bias-pull-up" and "bias-pull-down", described in file -pinctrl-bindings.txt +Configuration nodes support the following generic properties, as +described in file pinctrl-bindings.txt: + - "bias-disable" + - "bias-pull-up" + - "bias-pull-down" + - "output-enable" + - "output-disable" + - "output-low" + - "output-high" Optional properties : - drive-strength-microamp: Drive strength for the specified pins in uA. -- cgit v1.2.3-59-g8ed1b From 13531e5d359e30d9e3d1cabd246a24cf6fdf084a Mon Sep 17 00:00:00 2001 From: Manivannan Sadhasivam Date: Mon, 20 May 2019 14:00:57 +0530 Subject: dt-bindings: pinctrl: Modify pinctrl memory map Earlier, the PWM registers were included as part of the pinctrl memory map, but this turned to be useless as the muxing is being handled by the SoC pin controller itself. So, lets modify the pinctrl memory map to reflect the same. Fixes: 07b734fbdea2 ("dt-bindings: pinctrl: Add BM1880 pinctrl binding") Signed-off-by: Manivannan Sadhasivam Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/bitmain,bm1880-pinctrl.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/bitmain,bm1880-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/bitmain,bm1880-pinctrl.txt index ed34bb1ee81c..cc9a89aa4170 100644 --- a/Documentation/devicetree/bindings/pinctrl/bitmain,bm1880-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/bitmain,bm1880-pinctrl.txt @@ -85,9 +85,9 @@ Required Properties: spi0 Example: - pinctrl: pinctrl@50 { + pinctrl: pinctrl@400 { compatible = "bitmain,bm1880-pinctrl"; - reg = <0x50 0x4B0>; + reg = <0x400 0x120>; pinctrl_uart0_default: uart0-default { pinmux { -- cgit v1.2.3-59-g8ed1b From 752a74038dbd999c108f1c7474908f7501e246bb Mon Sep 17 00:00:00 2001 From: Manivannan Sadhasivam Date: Mon, 20 May 2019 14:01:00 +0530 Subject: dt-bindings: pinctrl: Document pinconf bindings for BM1880 SoC Document pinconf bindings for Bitmain BM1880 SoC. Signed-off-by: Manivannan Sadhasivam Signed-off-by: Linus Walleij --- .../bindings/pinctrl/bitmain,bm1880-pinctrl.txt | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/bitmain,bm1880-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/bitmain,bm1880-pinctrl.txt index cc9a89aa4170..4eb089bcb5f3 100644 --- a/Documentation/devicetree/bindings/pinctrl/bitmain,bm1880-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/bitmain,bm1880-pinctrl.txt @@ -14,7 +14,8 @@ phrase "pin configuration node". The pin configuration nodes act as a container for an arbitrary number of subnodes. Each of these subnodes represents some desired configuration for a pin, a group, or a list of pins or groups. This configuration for BM1880 SoC -includes only pinmux as there is no pinconf support available in SoC. +includes pinmux and various pin configuration parameters, such as pull-up, +slew rate etc... Each configuration node can consist of multiple nodes describing the pinmux options. The name of each subnode is not important; all subnodes should be @@ -84,6 +85,22 @@ Required Properties: gpio66, gpio67, eth1, i2s0, i2s0_mclkin, i2s1, i2s1_mclkin, spi0 +Optional Properties: + +- bias-disable: No arguments. Disable pin bias. +- bias-pull-down: No arguments. The specified pins should be configured as + pull down. +- bias-pull-up: No arguments. The specified pins should be configured as + pull up. +- input-schmitt-enable: No arguments: Enable schmitt trigger for the specified + pins +- input-schmitt-disable: No arguments: Disable schmitt trigger for the specified + pins +- slew-rate: Integer. Sets slew rate for the specified pins. + Valid values are: + <0> - Slow + <1> - Fast + Example: pinctrl: pinctrl@400 { compatible = "bitmain,bm1880-pinctrl"; -- cgit v1.2.3-59-g8ed1b From e0917169e5cc068a0c791726329746d1f4752b7a Mon Sep 17 00:00:00 2001 From: Clément Péron Date: Thu, 23 May 2019 17:10:47 +0200 Subject: dt-bindings: watchdog: add Allwinner H6 watchdog MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Allwinner H6 has a similar watchdog as the A64 which is already a compatible of the A31. This commit add the H6 compatible. Signed-off-by: Clément Péron Signed-off-by: Maxime Ripard --- Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt b/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt index 46055254e8dd..e65198d82a2b 100644 --- a/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt @@ -6,6 +6,7 @@ Required properties: "allwinner,sun4i-a10-wdt" "allwinner,sun6i-a31-wdt" "allwinner,sun50i-a64-wdt","allwinner,sun6i-a31-wdt" + "allwinner,sun50i-h6-wdt","allwinner,sun6i-a31-wdt" "allwinner,suniv-f1c100s-wdt", "allwinner,sun4i-a10-wdt" - reg : Specifies base physical address and size of the registers. -- cgit v1.2.3-59-g8ed1b From ef98682a4e1257ff45405bb1372939e8dfe774bb Mon Sep 17 00:00:00 2001 From: Manivannan Sadhasivam Date: Sat, 11 May 2019 00:15:22 +0530 Subject: dt-bindings: reset: Add devicetree binding for BM1880 reset controller Add devicetree binding for Bitmain BM1880 SoC reset controller. Signed-off-by: Manivannan Sadhasivam Reviewed-by: Rob Herring Signed-off-by: Philipp Zabel --- .../bindings/reset/bitmain,bm1880-reset.txt | 18 ++++++++ include/dt-bindings/reset/bitmain,bm1880-reset.h | 51 ++++++++++++++++++++++ 2 files changed, 69 insertions(+) create mode 100644 Documentation/devicetree/bindings/reset/bitmain,bm1880-reset.txt create mode 100644 include/dt-bindings/reset/bitmain,bm1880-reset.h (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/reset/bitmain,bm1880-reset.txt b/Documentation/devicetree/bindings/reset/bitmain,bm1880-reset.txt new file mode 100644 index 000000000000..a6f8455ae6c4 --- /dev/null +++ b/Documentation/devicetree/bindings/reset/bitmain,bm1880-reset.txt @@ -0,0 +1,18 @@ +Bitmain BM1880 SoC Reset Controller +=================================== + +Please also refer to reset.txt in this directory for common reset +controller binding usage. + +Required properties: +- compatible: Should be "bitmain,bm1880-reset" +- reg: Offset and length of reset controller space in SCTRL. +- #reset-cells: Must be 1. + +Example: + + rst: reset-controller@c00 { + compatible = "bitmain,bm1880-reset"; + reg = <0xc00 0x8>; + #reset-cells = <1>; + }; diff --git a/include/dt-bindings/reset/bitmain,bm1880-reset.h b/include/dt-bindings/reset/bitmain,bm1880-reset.h new file mode 100644 index 000000000000..4c0de5223773 --- /dev/null +++ b/include/dt-bindings/reset/bitmain,bm1880-reset.h @@ -0,0 +1,51 @@ +/* SPDX-License-Identifier: GPL-2.0+ */ +/* + * Copyright (c) 2018 Bitmain Ltd. + * Copyright (c) 2019 Linaro Ltd. + */ + +#ifndef _DT_BINDINGS_BM1880_RESET_H +#define _DT_BINDINGS_BM1880_RESET_H + +#define BM1880_RST_MAIN_AP 0 +#define BM1880_RST_SECOND_AP 1 +#define BM1880_RST_DDR 2 +#define BM1880_RST_VIDEO 3 +#define BM1880_RST_JPEG 4 +#define BM1880_RST_VPP 5 +#define BM1880_RST_GDMA 6 +#define BM1880_RST_AXI_SRAM 7 +#define BM1880_RST_TPU 8 +#define BM1880_RST_USB 9 +#define BM1880_RST_ETH0 10 +#define BM1880_RST_ETH1 11 +#define BM1880_RST_NAND 12 +#define BM1880_RST_EMMC 13 +#define BM1880_RST_SD 14 +#define BM1880_RST_SDMA 15 +#define BM1880_RST_I2S0 16 +#define BM1880_RST_I2S1 17 +#define BM1880_RST_UART0_1_CLK 18 +#define BM1880_RST_UART0_1_ACLK 19 +#define BM1880_RST_UART2_3_CLK 20 +#define BM1880_RST_UART2_3_ACLK 21 +#define BM1880_RST_MINER 22 +#define BM1880_RST_I2C0 23 +#define BM1880_RST_I2C1 24 +#define BM1880_RST_I2C2 25 +#define BM1880_RST_I2C3 26 +#define BM1880_RST_I2C4 27 +#define BM1880_RST_PWM0 28 +#define BM1880_RST_PWM1 29 +#define BM1880_RST_PWM2 30 +#define BM1880_RST_PWM3 31 +#define BM1880_RST_SPI 32 +#define BM1880_RST_GPIO0 33 +#define BM1880_RST_GPIO1 34 +#define BM1880_RST_GPIO2 35 +#define BM1880_RST_EFUSE 36 +#define BM1880_RST_WDT 37 +#define BM1880_RST_AHB_ROM 38 +#define BM1880_RST_SPIC 39 + +#endif /* _DT_BINDINGS_BM1880_RESET_H */ -- cgit v1.2.3-59-g8ed1b From 5fc537bfd00033a3f813330175f7f12c25957ebf Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Fri, 24 May 2019 11:20:19 +0200 Subject: drm/mcde: Add new driver for ST-Ericsson MCDE This adds a new DRM driver for the ST-Ericsson Multi Channel Display Engine, MCDE display controller. This hardware has three independent DSI hosts and can composit and display several memory buffers onto an LCD display. It was developed for several years inside of ST-Ericsson and shipped with a few million mobile phones from Sony and Samsung, as well as with the Snowball community development board. The driver is currently pretty rudimentary but supports a simple framebuffer so we can get penguins and graphics when using these SoCs. Acked-by: Daniel Vetter Signed-off-by: Linus Walleij Link: https://patchwork.freedesktop.org/patch/msgid/20190524092019.19355-1-linus.walleij@linaro.org --- Documentation/gpu/drivers.rst | 1 + Documentation/gpu/mcde.rst | 8 + MAINTAINERS | 7 + drivers/gpu/drm/Kconfig | 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/mcde/Kconfig | 18 + drivers/gpu/drm/mcde/Makefile | 3 + drivers/gpu/drm/mcde/mcde_display.c | 1142 ++++++++++++++++++++++++++++++ drivers/gpu/drm/mcde/mcde_display_regs.h | 518 ++++++++++++++ drivers/gpu/drm/mcde/mcde_drm.h | 44 ++ drivers/gpu/drm/mcde/mcde_drv.c | 572 +++++++++++++++ drivers/gpu/drm/mcde/mcde_dsi.c | 1044 +++++++++++++++++++++++++++ drivers/gpu/drm/mcde/mcde_dsi_regs.h | 385 ++++++++++ 13 files changed, 3745 insertions(+) create mode 100644 Documentation/gpu/mcde.rst create mode 100644 drivers/gpu/drm/mcde/Kconfig create mode 100644 drivers/gpu/drm/mcde/Makefile create mode 100644 drivers/gpu/drm/mcde/mcde_display.c create mode 100644 drivers/gpu/drm/mcde/mcde_display_regs.h create mode 100644 drivers/gpu/drm/mcde/mcde_drm.h create mode 100644 drivers/gpu/drm/mcde/mcde_drv.c create mode 100644 drivers/gpu/drm/mcde/mcde_dsi.c create mode 100644 drivers/gpu/drm/mcde/mcde_dsi_regs.h (limited to 'Documentation') diff --git a/Documentation/gpu/drivers.rst b/Documentation/gpu/drivers.rst index 044a7025477c..4bfb7068e9f7 100644 --- a/Documentation/gpu/drivers.rst +++ b/Documentation/gpu/drivers.rst @@ -7,6 +7,7 @@ GPU Driver Documentation amdgpu amdgpu-dc i915 + mcde meson pl111 tegra diff --git a/Documentation/gpu/mcde.rst b/Documentation/gpu/mcde.rst new file mode 100644 index 000000000000..c69e977defda --- /dev/null +++ b/Documentation/gpu/mcde.rst @@ -0,0 +1,8 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================================================= + drm/mcde ST-Ericsson MCDE Multi-channel display engine +======================================================= + +.. kernel-doc:: drivers/gpu/drm/mcde/mcde_drv.c + :doc: ST-Ericsson MCDE DRM Driver diff --git a/MAINTAINERS b/MAINTAINERS index 63da5ff1355c..dd1523b90c3e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5128,6 +5128,13 @@ S: Maintained F: drivers/gpu/drm/tinydrm/st7735r.c F: Documentation/devicetree/bindings/display/sitronix,st7735r.txt +DRM DRIVER FOR ST-ERICSSON MCDE +M: Linus Walleij +T: git git://anongit.freedesktop.org/drm/drm-misc +S: Maintained +F: drivers/gpu/drm/mcde/ +F: Documentation/devicetree/bindings/display/ste,mcde.txt + DRM DRIVER FOR TDFX VIDEO CARDS S: Orphan / Obsolete F: drivers/gpu/drm/tdfx/ diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index a461f078a0dd..edcfb05b2db8 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -349,6 +349,8 @@ source "drivers/gpu/drm/panfrost/Kconfig" source "drivers/gpu/drm/aspeed/Kconfig" +source "drivers/gpu/drm/mcde/Kconfig" + # Keep legacy drivers last menuconfig DRM_LEGACY diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 4c3dc4268b65..5fcc9bc9c97a 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -118,3 +118,4 @@ obj-$(CONFIG_DRM_VBOXVIDEO) += vboxvideo/ obj-$(CONFIG_DRM_LIMA) += lima/ obj-$(CONFIG_DRM_PANFROST) += panfrost/ obj-$(CONFIG_DRM_ASPEED_GFX) += aspeed/ +obj-$(CONFIG_DRM_MCDE) += mcde/ diff --git a/drivers/gpu/drm/mcde/Kconfig b/drivers/gpu/drm/mcde/Kconfig new file mode 100644 index 000000000000..b3990126562c --- /dev/null +++ b/drivers/gpu/drm/mcde/Kconfig @@ -0,0 +1,18 @@ +config DRM_MCDE + tristate "DRM Support for ST-Ericsson MCDE (Multichannel Display Engine)" + depends on DRM + depends on CMA + depends on ARM || COMPILE_TEST + depends on OF + select MFD_SYSCON + select DRM_MIPI_DSI + select DRM_BRIDGE + select DRM_PANEL_BRIDGE + select DRM_KMS_HELPER + select DRM_KMS_CMA_HELPER + select DRM_GEM_CMA_HELPER + select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE + help + Choose this option for DRM support for the ST-Ericsson MCDE + Multi-Channel Display Engine. + If M is selected the module will be called mcde_drm. diff --git a/drivers/gpu/drm/mcde/Makefile b/drivers/gpu/drm/mcde/Makefile new file mode 100644 index 000000000000..fe28f4e0fe46 --- /dev/null +++ b/drivers/gpu/drm/mcde/Makefile @@ -0,0 +1,3 @@ +mcde_drm-y += mcde_drv.o mcde_dsi.o mcde_display.o + +obj-$(CONFIG_DRM_MCDE) += mcde_drm.o diff --git a/drivers/gpu/drm/mcde/mcde_display.c b/drivers/gpu/drm/mcde/mcde_display.c new file mode 100644 index 000000000000..17dc46d554b0 --- /dev/null +++ b/drivers/gpu/drm/mcde/mcde_display.c @@ -0,0 +1,1142 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2018 Linus Walleij + * Parts of this file were based on the MCDE driver by Marcus Lorentzon + * (C) ST-Ericsson SA 2013 + */ +#include +#include +#include + +#include +#include +#include +#include +#include +#include +#include +#include +#include