diff options
| author | Linus Torvalds <torvalds@linux-foundation.org> | 2021-09-01 08:35:06 -0700 |
|---|---|---|
| committer | Linus Torvalds <torvalds@linux-foundation.org> | 2021-09-01 08:35:06 -0700 |
| commit | ba1dc7f273c73b93e0e1dd9707b239ed69eebd70 (patch) | |
| tree | f79ee28c2b88fde1a901619f9b4c72dffeaa2337 /Documentation | |
| parent | 9e9fb7655ed585da8f468e29221f0ba194a5f613 (diff) | |
| parent | 0dc3ad3f859d3a65b335c861ec342d31d91e8bc8 (diff) | |
| download | linux-ba1dc7f273c73b93e0e1dd9707b239ed69eebd70.tar.gz linux-ba1dc7f273c73b93e0e1dd9707b239ed69eebd70.tar.bz2 linux-ba1dc7f273c73b93e0e1dd9707b239ed69eebd70.zip | |
Merge tag 'char-misc-5.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char / misc driver updates from Greg KH:
"Here is the big set of char/misc driver changes for 5.15-rc1.
Lots of different driver subsystems are being updated in here,
notably:
- mhi subsystem update
- fpga subsystem update
- coresight/hwtracing subsystem update
- interconnect subsystem update
- nvmem subsystem update
- parport drivers update
- phy subsystem update
- soundwire subsystem update
and there are some other char/misc drivers being updated as well:
- binder driver additions
- new misc drivers
- lkdtm driver updates
- mei driver updates
- sram driver updates
- other minor driver updates.
Note, there are no habanalabs driver updates in this pull request,
that will probably come later before -rc1 is out in a different
request.
All of these have been in linux-next for a while with no reported
problems"
* tag 'char-misc-5.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (169 commits)
Revert "bus: mhi: Add inbound buffers allocation flag"
misc/pvpanic: fix set driver data
VMCI: fix NULL pointer dereference when unmapping queue pair
char: mware: fix returnvar.cocci warnings
parport: remove non-zero check on count
soundwire: cadence: do not extend reset delay
soundwire: intel: conditionally exit clock stop mode on system suspend
soundwire: intel: skip suspend/resume/wake when link was not started
soundwire: intel: fix potential race condition during power down
phy: qcom-qmp: Add support for SM6115 UFS phy
dt-bindings: phy: qcom,qmp: Add SM6115 UFS PHY bindings
phy: qmp: Provide unique clock names for DP clocks
lkdtm: remove IDE_CORE_CP crashpoint
lkdtm: replace SCSI_DISPATCH_CMD with SCSI_QUEUE_RQ
coresight: Replace deprecated CPU-hotplug functions.
Documentation: coresight: Add documentation for CoreSight config
coresight: syscfg: Add initial configfs support
coresight: config: Add preloaded configurations
coresight: etm4x: Add complex configuration handlers to etmv4
coresight: etm-perf: Update to activate selected configuration
...
Diffstat (limited to 'Documentation')
29 files changed, 764 insertions, 207 deletions
diff --git a/Documentation/ABI/testing/sysfs-driver-ge-achc b/Documentation/ABI/testing/sysfs-driver-ge-achc new file mode 100644 index 000000000000..a9e7a079190c --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-ge-achc @@ -0,0 +1,15 @@ +What: /sys/bus/spi/<dev>/update_firmware +Date: Jul 2021 +Contact: sebastian.reichel@collabora.com +Description: Write 1 to this file to update the ACHC microcontroller + firmware via the EzPort interface. For this the kernel + will load "achc.bin" via the firmware API (so usually + from /lib/firmware). The write will block until the FW + has either been flashed successfully or an error occured. + +What: /sys/bus/spi/<dev>/reset +Date: Jul 2021 +Contact: sebastian.reichel@collabora.com +Description: This file represents the microcontroller's reset line. + 1 means the reset line is asserted, 0 means it's not + asserted. The file is read and writable. diff --git a/Documentation/admin-guide/binderfs.rst b/Documentation/admin-guide/binderfs.rst index 199d84314a14..41a4db00df8d 100644 --- a/Documentation/admin-guide/binderfs.rst +++ b/Documentation/admin-guide/binderfs.rst @@ -72,3 +72,16 @@ that the `rm() <rm_>`_ tool can be used to delete them. Note that the ``binder-control`` device cannot be deleted since this would make the binderfs instance unusable. The ``binder-control`` device will be deleted when the binderfs instance is unmounted and all references to it have been dropped. + +Binder features +--------------- + +Assuming an instance of binderfs has been mounted at ``/dev/binderfs``, the +features supported by the binder driver can be located under +``/dev/binderfs/features/``. The presence of individual files can be tested +to determine whether a particular feature is supported by the driver. + +Example:: + + cat /dev/binderfs/features/oneway_spam_detection + 1 diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt deleted file mode 100644 index 18c3aea90df2..000000000000 --- a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.txt +++ /dev/null @@ -1,44 +0,0 @@ ------------------------------------------------------------------ -Device Tree Bindings for the Xilinx Zynq MPSoC Firmware Interface ------------------------------------------------------------------ - -The zynqmp-firmware node describes the interface to platform firmware. -ZynqMP has an interface to communicate with secure firmware. Firmware -driver provides an interface to firmware APIs. Interface APIs can be -used by any driver to communicate to PMUFW(Platform Management Unit). -These requests include clock management, pin control, device control, -power management service, FPGA service and other platform management -services. - -Required properties: - - compatible: Must contain any of below: - "xlnx,zynqmp-firmware" for Zynq Ultrascale+ MPSoC - "xlnx,versal-firmware" for Versal - - method: The method of calling the PM-API firmware layer. - Permitted values are: - - "smc" : SMC #0, following the SMCCC - - "hvc" : HVC #0, following the SMCCC - -------- -Example -------- - -Zynq Ultrascale+ MPSoC ----------------------- -firmware { - zynqmp_firmware: zynqmp-firmware { - compatible = "xlnx,zynqmp-firmware"; - method = "smc"; - ... - }; -}; - -Versal ------- -firmware { - versal_firmware: versal-firmware { - compatible = "xlnx,versal-firmware"; - method = "smc"; - ... - }; -}; diff --git a/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml new file mode 100644 index 000000000000..f14f7b454f07 --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/xilinx/xlnx,zynqmp-firmware.yaml @@ -0,0 +1,89 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/firmware/xilinx/xlnx,zynqmp-firmware.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx firmware driver + +maintainers: + - Nava kishore Manne <nava.manne@xilinx.com> + +description: The zynqmp-firmware node describes the interface to platform + firmware. ZynqMP has an interface to communicate with secure firmware. + Firmware driver provides an interface to firmware APIs. Interface APIs + can be used by any driver to communicate to PMUFW(Platform Management Unit). + These requests include clock management, pin control, device control, + power management service, FPGA service and other platform management + services. + +properties: + compatible: + oneOf: + - description: For implementations complying for Zynq Ultrascale+ MPSoC. + const: xlnx,zynqmp-firmware + + - description: For implementations complying for Versal. + const: xlnx,versal-firmware + + method: + description: | + The method of calling the PM-API firmware layer. + Permitted values are. + - "smc" : SMC #0, following the SMCCC + - "hvc" : HVC #0, following the SMCCC + + $ref: /schemas/types.yaml#/definitions/string-array + enum: + - smc + - hvc + + versal_fpga: + $ref: /schemas/fpga/xlnx,versal-fpga.yaml# + description: Compatible of the FPGA device. + type: object + + zynqmp-aes: + $ref: /schemas/crypto/xlnx,zynqmp-aes.yaml# + description: The ZynqMP AES-GCM hardened cryptographic accelerator is + used to encrypt or decrypt the data with provided key and initialization + vector. + type: object + + clock-controller: + $ref: /schemas/clock/xlnx,versal-clk.yaml# + description: The clock controller is a hardware block of Xilinx versal + clock tree. It reads required input clock frequencies from the devicetree + and acts as clock provider for all clock consumers of PS clocks.list of + clock specifiers which are external input clocks to the given clock + controller. + type: object + +required: + - compatible + +additionalProperties: false + +examples: + - | + versal-firmware { + compatible = "xlnx,versal-firmware"; + method = "smc"; + + versal_fpga: versal_fpga { + compatible = "xlnx,versal-fpga"; + }; + + xlnx_aes: zynqmp-aes { + compatible = "xlnx,zynqmp-aes"; + }; + + versal_clk: clock-controller { + #clock-cells = <1>; + compatible = "xlnx,versal-clk"; + clocks = <&ref>, <&alt_ref>, <&pl_alt_ref>; + clock-names = "ref", "alt_ref", "pl_alt_ref"; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml b/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml new file mode 100644 index 000000000000..ac6a207278d5 --- /dev/null +++ b/Documentation/devicetree/bindings/fpga/xlnx,versal-fpga.yaml @@ -0,0 +1,33 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/fpga/xlnx,versal-fpga.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx Versal FPGA driver. + +maintainers: + - Nava kishore Manne <nava.manne@xilinx.com> + +description: | + Device Tree Versal FPGA bindings for the Versal SoC, controlled + using firmware interface. + +properties: + compatible: + items: + - enum: + - xlnx,versal-fpga + +required: + - compatible + +additionalProperties: false + +examples: + - | + versal_fpga: versal_fpga { + compatible = "xlnx,versal-fpga"; + }; + +... diff --git a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml index d6a95c3cb26f..e701524ee811 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,osm-l3.yaml @@ -18,6 +18,7 @@ properties: compatible: enum: - qcom,sc7180-osm-l3 + - qcom,sc8180x-osm-l3 - qcom,sdm845-osm-l3 - qcom,sm8150-osm-l3 - qcom,sm8250-epss-l3 diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml index 5accc0d113be..3fd1a134162d 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml @@ -49,6 +49,17 @@ properties: - qcom,sc7280-mmss-noc - qcom,sc7280-nsp-noc - qcom,sc7280-system-noc + - qcom,sc8180x-aggre1-noc + - qcom,sc8180x-aggre2-noc + - qcom,sc8180x-camnoc-virt + - qcom,sc8180x-compute-noc + - qcom,sc8180x-config-noc + - qcom,sc8180x-dc-noc + - qcom,sc8180x-gem-noc + - qcom,sc8180x-ipa-virt + - qcom,sc8180x-mc-virt + - qcom,sc8180x-mmss-noc + - qcom,sc8180x-system-noc - qcom,sdm845-aggre1-noc - qcom,sdm845-aggre2-noc - qcom,sdm845-config-noc diff --git a/Documentation/devicetree/bindings/misc/ge-achc.txt b/Documentation/devicetree/bindings/misc/ge-achc.txt deleted file mode 100644 index 77df94d7a32f..000000000000 --- a/Documentation/devicetree/bindings/misc/ge-achc.txt +++ /dev/null @@ -1,26 +0,0 @@ -* GE Healthcare USB Management Controller - -A device which handles data aquisition from compatible USB based peripherals. -SPI is used for device management. - -Note: This device does not expose the peripherals as USB devices. - -Required properties: - -- compatible : Should be "ge,achc" - -Required SPI properties: - -- reg : Should be address of the device chip select within - the controller. - -- spi-max-frequency : Maximum SPI clocking speed of device in Hz, should be - 1MHz for the GE ACHC. - -Example: - -spidev0: spi@0 { - compatible = "ge,achc"; - reg = <0>; - spi-max-frequency = <1000000>; -}; diff --git a/Documentation/devicetree/bindings/misc/ge-achc.yaml b/Documentation/devicetree/bindings/misc/ge-achc.yaml new file mode 100644 index 000000000000..ff07aa62ed57 --- /dev/null +++ b/Documentation/devicetree/bindings/misc/ge-achc.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: GPL-2.0 OR BSD-2-Clause +# Copyright (C) 2021 GE Inc. +# Copyright (C) 2021 Collabora Ltd. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/misc/ge-achc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: GE Healthcare USB Management Controller + +description: | + A device which handles data acquisition from compatible USB based peripherals. + SPI is used for device management. + + Note: This device does not expose the peripherals as USB devices. + +maintainers: + - Sebastian Reichel <sre@kernel.org> + +properties: + compatible: + items: + - const: ge,achc + - const: nxp,kinetis-k20 + + clocks: + maxItems: 1 + + vdd-supply: + description: Digital power supply regulator on VDD pin + + vdda-supply: + description: Analog power supply regulator on VDDA pin + + reg: + items: + - description: Control interface + - description: Firmware programming interface + + reset-gpios: + description: GPIO used for hardware reset. + maxItems: 1 + +required: + - compatible + - clocks + - reg + - reset-gpios + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + spi { + #address-cells = <1>; + #size-cells = <0>; + + spi@1 { + compatible = "ge,achc", "nxp,kinetis-k20"; + reg = <1>, <0>; + clocks = <&achc_24M>; + reset-gpios = <&gpio3 6 GPIO_ACTIVE_LOW>; + }; + }; diff --git a/Documentation/devicetree/bindings/nvmem/nintendo-otp.yaml b/Documentation/devicetree/bindings/nvmem/nintendo-otp.yaml new file mode 100644 index 000000000000..dbe4ffdd644c --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/nintendo-otp.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/nvmem/nintendo-otp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Nintendo Wii and Wii U OTP Device Tree Bindings + +description: | + This binding represents the OTP memory as found on a Nintendo Wii or Wii U, + which contains common and per-console keys, signatures and related data + required to access peripherals. + + See https://wiiubrew.org/wiki/Hardware/OTP + +maintainers: + - Emmanuel Gil Peyrot <linkmauve@linkmauve.fr> + +allOf: + - $ref: "nvmem.yaml#" + +properties: + compatible: + enum: + - nintendo,hollywood-otp + - nintendo,latte-otp + + reg: + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + otp@d8001ec { + compatible = "nintendo,latte-otp"; + reg = <0x0d8001ec 0x8>; + }; + +... diff --git a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml index 861b205016b1..dede8892ee01 100644 --- a/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml +++ b/Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml @@ -51,6 +51,9 @@ properties: vcc-supply: description: Our power supply. + power-domains: + maxItems: 1 + # Needed if any child nodes are present. "#address-cells": const: 1 diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.txt b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.txt deleted file mode 100644 index 7c70f2ad9942..000000000000 --- a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.txt +++ /dev/null @@ -1,20 +0,0 @@ -* Freescale i.MX8MQ USB3 PHY binding - -Required properties: -- compatible: Should be "fsl,imx8mq-usb-phy" or "fsl,imx8mp-usb-phy" -- #phys-cells: must be 0 (see phy-bindings.txt in this directory) -- reg: The base address and length of the registers -- clocks: phandles to the clocks for each clock listed in clock-names -- clock-names: must contain "phy" - -Optional properties: -- vbus-supply: A phandle to the regulator for USB VBUS. - -Example: - usb3_phy0: phy@381f0040 { - compatible = "fsl,imx8mq-usb-phy"; - reg = <0x381f0040 0x40>; - clocks = <&clk IMX8MQ_CLK_USB1_PHY_ROOT>; - clock-names = "phy"; - #phy-cells = <0>; - }; diff --git a/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml new file mode 100644 index 000000000000..2936f3510a6a --- /dev/null +++ b/Documentation/devicetree/bindings/phy/fsl,imx8mq-usb-phy.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/fsl,imx8mq-usb-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale i.MX8MQ USB3 PHY binding + +maintainers: + - Li Jun <jun.li@nxp.com> + +properties: + compatible: + enum: + - fsl,imx8mq-usb-phy + - fsl,imx8mp-usb-phy + + reg: + maxItems: 1 + + "#phy-cells": + const: 0 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: phy + + vbus-supply: + description: + A phandle to the regulator for USB VBUS. + +required: + - compatible + - reg + - "#phy-cells" + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx8mq-clock.h> + usb3_phy0: phy@381f0040 { + compatible = "fsl,imx8mq-usb-phy"; + reg = <0x381f0040 0x40>; + clocks = <&clk IMX8MQ_CLK_USB1_PHY_ROOT>; + clock-names = "phy"; + #phy-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/phy/intel,phy-keembay-usb.yaml b/Documentation/devicetree/bindings/phy/intel,keembay-phy-usb.yaml index a217bb8ac5bc..52815b6c2b88 100644 --- a/Documentation/devicetree/bindings/phy/intel,phy-keembay-usb.yaml +++ b/Documentation/devicetree/bindings/phy/intel,keembay-phy-usb.yaml @@ -1,7 +1,7 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: http://devicetree.org/schemas/phy/intel,phy-keembay-usb.yaml# +$id: http://devicetree.org/schemas/phy/intel,keembay-phy-usb.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: Intel Keem Bay USB PHY bindings diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml index ef9d9d4e6875..9e6c0f43f1c6 100644 --- a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml +++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml @@ -15,7 +15,7 @@ description: | controllers on MediaTek SoCs, includes USB2.0, USB3.0, PCIe and SATA. Layout differences of banks between T-PHY V1 (mt8173/mt2701) and - T-PHY V2 (mt2712) when works on USB mode: + T-PHY V2 (mt2712) / V3 (mt8195) when works on USB mode: ----------------------------------- Version 1: port offset bank @@ -34,7 +34,7 @@ description: | u2 port2 0x1800 U2PHY_COM ... - Version 2: + Version 2/3: port offset bank u2 port0 0x0000 MISC 0x0100 FMREG @@ -59,7 +59,8 @@ description: | SPLLC shared by u3 ports and FMREG shared by u2 ports on V1 are put back into each port; a new bank MISC for u2 ports and CHIP for u3 ports are - added on V2. + added on V2; the FMREG bank for slew rate calibration is not used anymore + and reserved on V3; properties: $nodename: @@ -79,8 +80,11 @@ properties: - mediatek,mt2712-tphy - mediatek,mt7629-tphy - mediatek,mt8183-tphy - - mediatek,mt8195-tphy - const: mediatek,generic-tphy-v2 + - items: + - enum: + - mediatek,mt8195-tphy + - const: mediatek,generic-tphy-v3 - const: mediatek,mt2701-u3phy deprecated: true - const: mediatek,mt2712-u3phy @@ -91,7 +95,7 @@ properties: description: Register shared by multiple ports, exclude port's private register. It is needed for T-PHY V1, such as mt2701 and mt8173, but not for - T-PHY V2, such as mt2712. + T-PHY V2/V3, such as mt2712. maxItems: 1 "#address-cells": @@ -197,6 +201,22 @@ patternProperties: Specify the flag to enable BC1.2 if support it type: boolean + mediatek,syscon-type: + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + description: + A phandle to syscon used to access the register of type switch, + the field should always be 3 cells long. + items: + items: + - description: + The first cell represents a phandle to syscon + - description: + The second cell represents the register offset + - description: + The third cell represents the index of config segment + enum: [0, 1, 2, 3] + required: - reg - "#phy-cells" diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml index f0497b8623ad..75be5650a198 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml @@ -18,6 +18,7 @@ properties: compatible: enum: - qcom,ipq6018-qmp-pcie-phy + - qcom,ipq6018-qmp-usb3-phy - qcom,ipq8074-qmp-pcie-phy - qcom,ipq8074-qmp-usb3-phy - qcom,msm8996-qmp-pcie-phy @@ -27,6 +28,7 @@ properties: - qcom,msm8998-qmp-ufs-phy - qcom,msm8998-qmp-usb3-phy - qcom,sc7180-qmp-usb3-phy + - qcom,sc8180x-qmp-pcie-phy - qcom,sc8180x-qmp-ufs-phy - qcom,sc8180x-qmp-usb3-phy - qcom,sdm845-qhp-pcie-phy @@ -34,6 +36,7 @@ properties: - qcom,sdm845-qmp-ufs-phy - qcom,sdm845-qmp-usb3-phy - qcom,sdm845-qmp-usb3-uni-phy + - qcom,sm6115-qmp-ufs-phy - qcom,sm8150-qmp-ufs-phy - qcom,sm8150-qmp-usb3-phy - qcom,sm8150-qmp-usb3-uni-phy @@ -326,6 +329,7 @@ allOf: compatible: contains: enum: + - qcom,sc8180x-qmp-pcie-phy - qcom,sdm845-qhp-pcie-phy - qcom,sdm845-qmp-pcie-phy - qcom,sdx55-qmp-pcie-phy diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml index 217aa6c91893..1d49cc3d4eae 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-usb3-dp-phy.yaml @@ -14,6 +14,7 @@ properties: compatible: enum: - qcom,sc7180-qmp-usb3-dp-phy + - qcom,sc8180x-qmp-usb3-dp-phy - qcom,sdm845-qmp-usb3-dp-phy - qcom,sm8250-qmp-usb3-dp-phy reg: diff --git a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml index d5dc5a3cdceb..3a6e1165419c 100644 --- a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml @@ -30,6 +30,11 @@ properties: - renesas,usb2-phy-r8a77995 # R-Car D3 - const: renesas,rcar-gen3-usb2-phy + - items: + - enum: + - renesas,usb2-phy-r9a07g044 # RZ/G2{L,LC} + - const: renesas,rzg2l-usb2-phy # RZ/G2L family + reg: maxItems: 1 @@ -91,6 +96,16 @@ required: - clocks - '#phy-cells' +allOf: + - if: + properties: + compatible: + contains: + const: renesas,rzg2l-usb2-phy + then: + required: + - resets + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml index 636cc501b54f..f6ed1a005e7a 100644 --- a/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml +++ b/Documentation/devicetree/bindings/phy/samsung,ufs-phy.yaml @@ -16,6 +16,7 @@ properties: compatible: enum: - samsung,exynos7-ufs-phy + - samsung,exynosautov9-ufs-phy reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.txt b/Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.txt deleted file mode 100644 index 64b286d2d398..000000000000 --- a/Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.txt +++ /dev/null @@ -1,82 +0,0 @@ -TI AM654 SERDES - -Required properties: - - compatible: Should be "ti,phy-am654-serdes" - - reg : Address and length of the register set for the device. - - #phy-cells: determine the number of cells that should be given in the - phandle while referencing this phy. Should be "2". The 1st cell - corresponds to the phy type (should be one of the types specified in - include/dt-bindings/phy/phy.h) and the 2nd cell should be the serdes - lane function. - If SERDES0 is referenced 2nd cell should be: - 0 - USB3 - 1 - PCIe0 Lane0 - 2 - ICSS2 SGMII Lane0 - If SERDES1 is referenced 2nd cell should be: - 0 - PCIe1 Lane0 - 1 - PCIe0 Lane1 - 2 - ICSS2 SGMII Lane1 - - power-domains: As documented by the generic PM domain bindings in - Documentation/devicetree/bindings/power/power_domain.txt. - - clocks: List of clock-specifiers representing the input to the SERDES. - Should have 3 items representing the left input clock, external - reference clock and right input clock in that order. - - clock-output-names: List of clock names for each of the clock outputs of - SERDES. Should have 3 items for CMU reference clock, - left output clock and right output clock in that order. - - assigned-clocks: As defined in - Documentation/devicetree/bindings/clock/clock-bindings.txt - - assigned-clock-parents: As defined in - Documentation/devicetree/bindings/clock/clock-bindings.txt - - #clock-cells: Should be <1> to choose between the 3 output clocks. - Defined in Documentation/devicetree/bindings/clock/clock-bindings.txt - - The following macros are defined in dt-bindings/phy/phy-am654-serdes.h - for selecting the correct reference clock. This can be used while - specifying the clocks created by SERDES. - => AM654_SERDES_CMU_REFCLK - => AM654_SERDES_LO_REFCLK - => AM654_SERDES_RO_REFCLK - - - mux-controls: Phandle to the multiplexer that is used to select the lane - function. See #phy-cells above to see the multiplex values. - -Example: - -Example for SERDES0 is given below. It has 3 clock inputs; -left input reference clock as indicated by <&k3_clks 153 4>, external -reference clock as indicated by <&k3_clks 153 1> and right input -reference clock as indicated by <&serdes1 AM654_SERDES_LO_REFCLK>. (The -right input of SERDES0 is connected to the left output of SERDES1). - -SERDES0 registers 3 clock outputs as indicated in clock-output-names. The -first refers to the CMU reference clock, second refers to the left output -reference clock and the third refers to the right output reference clock. - -The assigned-clocks and assigned-clock-parents is used here to set the -parent of left input reference clock to MAINHSDIV_CLKOUT4 and parent of -CMU reference clock to left input reference clock. - -serdes0: serdes@900000 { - compatible = "ti,phy-am654-serdes"; - reg = <0x0 0x900000 0x0 0x2000>; - reg-names = "serdes"; - #phy-cells = <2>; - power-domains = <&k3_pds 153>; - clocks = <&k3_clks 153 4>, <&k3_clks 153 1>, - <&serdes1 AM654_SERDES_LO_REFCLK>; - clock-output-names = "serdes0_cmu_refclk", "serdes0_lo_refclk", - "serdes0_ro_refclk"; - assigned-clocks = <&k3_clks 153 4>, <&serdes0 AM654_SERDES_CMU_REFCLK>; - assigned-clock-parents = <&k3_clks 153 8>, <&k3_clks 153 4>; - ti,serdes-clk = <&serdes0_clk>; - mux-controls = <&serdes_mux 0>; - #clock-cells = <1>; -}; - -Example for PCIe consumer node using the SERDES PHY specifier is given below. -&pcie0_rc { - num-lanes = <2>; - phys = <&serdes0 PHY_TYPE_PCIE 1>, <&serdes1 PHY_TYPE_PCIE 1>; - phy-names = "pcie-phy0", "pcie-phy1"; -}; diff --git a/Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.yaml b/Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.yaml new file mode 100644 index 000000000000..62dcb84c08aa --- /dev/null +++ b/Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.yaml @@ -0,0 +1,103 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/ti,phy-am654-serdes.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI AM654 SERDES binding + +description: + This binding describes the TI AM654 SERDES. AM654 SERDES can be configured + to be used with either PCIe or USB or SGMII. + +maintainers: + - Kishon Vijay Abraham I <kishon@ti.com> + +properties: + compatible: + enum: + - ti,phy-am654-serdes + + reg: + maxItems: 1 + + reg-names: + items: + - const: serdes + + power-domains: + maxItems: 1 + + clocks: + maxItems: 3 + description: + Three input clocks referring to left input reference clock, refclk and right input reference + clock. + + assigned-clocks: + $ref: "/schemas/types.yaml#/definitions/phandle-array" + assigned-clock-parents: + $ref: "/schemas/types.yaml#/definitions/phandle-array" + + '#phy-cells': + const: 2 + description: + The 1st cell corresponds to the phy type (should be one of the types specified in + include/dt-bindings/phy/phy.h) and the 2nd cell should be the serdes lane function. + + ti,serdes-clk: + description: Phandle to the SYSCON entry required for configuring SERDES clock selection. + $ref: /schemas/types.yaml#/definitions/phandle + + '#clock-cells': + const: 1 + + mux-controls: + maxItems: 1 + description: Phandle to the SYSCON entry required for configuring SERDES lane function. + + clock-output-names: + oneOf: + - description: Clock output names for SERDES 0 + items: + - const: serdes0_cmu_refclk + - const: serdes0_lo_refclk + - const: serdes0_ro_refclk + - description: Clock output names for SERDES 1 + items: + - const: serdes1_cmu_refclk + - const: serdes1_lo_refclk + - const: serdes1_ro_refclk + +required: + - compatible + - reg + - power-domains + - clocks + - assigned-clocks + - assigned-clock-parents + - ti,serdes-clk + - mux-controls + - clock-output-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/phy/phy-am654-serdes.h> + + serdes0: serdes@900000 { + compatible = "ti,phy-am654-serdes"; + reg = <0x900000 0x2000>; + reg-names = "serdes"; + #phy-cells = <2>; + power-domains = <&k3_pds 153>; + clocks = <&k3_clks 153 4>, <&k3_clks 153 1>, + <&serdes1 AM654_SERDES_LO_REFCLK>; + clock-output-names = "serdes0_cmu_refclk", "serdes0_lo_refclk", "serdes0_ro_refclk"; + assigned-clocks = <&k3_clks 153 4>, <&serdes0 AM654_SERDES_CMU_REFCLK>; + assigned-clock-parents = <&k3_clks 153 8>, <&k3_clks 153 4>; + ti,serdes-clk = <&serdes0_clk>; + mux-controls = <&serdes_mux 0>; + #clock-cells = <1>; + }; diff --git a/Documentation/driver-api/fpga/fpga-bridge.rst b/Documentation/driver-api/fpga/fpga-bridge.rst index 198aadafd3e7..8d650b4e2ce6 100644 --- a/Documentation/driver-api/fpga/fpga-bridge.rst +++ b/Documentation/driver-api/fpga/fpga-bridge.rst @@ -4,11 +4,11 @@ FPGA Bridge API to implement a new FPGA bridge ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -* struct fpga_bridge — The FPGA Bridge structure -* struct fpga_bridge_ops — Low level Bridge driver ops -* devm_fpga_bridge_create() — Allocate and init a bridge struct -* fpga_bridge_register() — Register a bridge -* fpga_bridge_unregister() — Unregister a bridge +* struct fpga_bridge - The FPGA Bridge structure +* struct fpga_bridge_ops - Low level Bridge driver ops +* devm_fpga_bridge_create() - Allocate and init a bridge struct +* fpga_bridge_register() - Register a bridge +* fpga_bridge_unregister() - Unregister a bridge .. kernel-doc:: include/linux/fpga/fpga-bridge.h :functions: fpga_bridge diff --git a/Documentation/driver-api/fpga/fpga-mgr.rst b/Documentation/driver-api/fpga/fpga-mgr.rst index 917ee22db429..4d926b452cb3 100644 --- a/Documentation/driver-api/fpga/fpga-mgr.rst +++ b/Documentation/driver-api/fpga/fpga-mgr.rst @@ -101,12 +101,12 @@ in state. API for implementing a new FPGA Manager driver ---------------------------------------------- -* ``fpga_mgr_states`` — Values for :c:expr:`fpga_manager->state`. -* struct fpga_manager — the FPGA manager struct -* struct fpga_manager_ops — Low level FPGA manager driver ops -* devm_fpga_mgr_create() — Allocate and init a manager struct -* fpga_mgr_register() — Register an FPGA manager -* fpga_mgr_unregister() — Unregister an FPGA manager +* ``fpga_mgr_states`` - Values for :c:expr:`fpga_manager->state`. +* struct fpga_manager - the FPGA manager struct +* struct fpga_manager_ops - Low level FPGA manager driver ops +* devm_fpga_mgr_create() - Allocate and init a manager struct +* fpga_mgr_register() - Register an FPGA manager +* fpga_mgr_unregister() - Unregister an FPGA manager .. kernel-doc:: include/linux/fpga/fpga-mgr.h :functions: fpga_mgr_states diff --git a/Documentation/driver-api/fpga/fpga-programming.rst b/Documentation/driver-api/fpga/fpga-programming.rst index 002392dab04f..fb4da4240e96 100644 --- a/Documentation/driver-api/fpga/fpga-programming.rst +++ b/Documentation/driver-api/fpga/fpga-programming.rst @@ -84,10 +84,10 @@ will generate that list. Here's some sample code of what to do next:: API for programming an FPGA --------------------------- -* fpga_region_program_fpga() — Program an FPGA -* fpga_image_info() — Specifies what FPGA image to program -* fpga_image_info_alloc() — Allocate an FPGA image info struct -* fpga_image_info_free() — Free an FPGA image info struct +* fpga_region_program_fpga() - Program an FPGA +* fpga_image_info() - Specifies what FPGA image to program +* fpga_image_info_alloc() - Allocate an FPGA image info struct +* fpga_image_info_free() - Free an FPGA image info struct .. kernel-doc:: drivers/fpga/fpga-region.c :functions: fpga_region_program_fpga diff --git a/Documentation/driver-api/fpga/fpga-region.rst b/Documentation/driver-api/fpga/fpga-region.rst index 363a8171ab0a..2636a27c11b2 100644 --- a/Documentation/driver-api/fpga/fpga-region.rst +++ b/Documentation/driver-api/fpga/fpga-region.rst @@ -45,19 +45,19 @@ An example of usage can be seen in the probe function of [#f2]_. API to add a new FPGA region ---------------------------- -* struct fpga_region — The FPGA region struct -* devm_fpga_region_create() — Allocate and init a region struct -* fpga_region_register() — Register an FPGA region -* fpga_region_unregister() — Unregister an FPGA region +* struct fpga_region - The FPGA region struct +* devm_fpga_region_create() - Allocate and init a region struct +* fpga_region_register() - Register an FPGA region +* fpga_region_unregister() - Unregister an FPGA region The FPGA region's probe function will need to get a reference to the FPGA Manager it will be using to do the programming. This usually would happen during the region's probe function. -* fpga_mgr_get() — Get a reference to an FPGA manager, raise ref count -* of_fpga_mgr_get() — Get a reference to an FPGA manager, raise ref count, +* fpga_mgr_get() - Get a reference to an FPGA manager, raise ref count +* of_fpga_mgr_get() - Get a reference to an FPGA manager, raise ref count, given a device node. -* fpga_mgr_put() — Put an FPGA manager +* fpga_mgr_put() - Put an FPGA manager The FPGA region will need to specify which bridges to control while programming the FPGA. The region driver can build a list of bridges during probe time @@ -66,11 +66,11 @@ the list of bridges to program just before programming (:c:expr:`fpga_region->get_bridges`). The FPGA bridge framework supplies the following APIs to handle building or tearing down that list. -* fpga_bridge_get_to_list() — Get a ref of an FPGA bridge, add it to a +* fpga_bridge_get_to_list() - Get a ref of an FPGA bridge, add it to a list -* of_fpga_bridge_get_to_list() — Get a ref of an FPGA bridge, add it to a +* of_fpga_bridge_get_to_list() - Get a ref of an FPGA bridge, add it to a list, given a device node -* fpga_bridges_put() — Given a list of bridges, put them +* fpga_bridges_put() - Given a list of bridges, put them .. kernel-doc:: include/linux/fpga/fpga-region.h :functions: fpga_region diff --git a/Documentation/fault-injection/provoke-crashes.rst b/Documentation/fault-injection/provoke-crashes.rst index a20ba5d93932..3abe84225613 100644 --- a/Documentation/fault-injection/provoke-crashes.rst +++ b/Documentation/fault-injection/provoke-crashes.rst @@ -29,8 +29,7 @@ recur_count cpoint_name Where in the kernel to trigger the action. It can be one of INT_HARDWARE_ENTRY, INT_HW_IRQ_EN, INT_TASKLET_ENTRY, - FS_DEVRW, MEM_SWAPOUT, TIMERADD, SCSI_DISPATCH_CMD, - IDE_CORE_CP, or DIRECT + FS_DEVRW, MEM_SWAPOUT, TIMERADD, SCSI_QUEUE_RQ, or DIRECT. cpoint_type Indicates the action to be taken on hitting the crash point. diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst index 75df90d1e54c..ef9eec71f6f3 100644 --- a/Documentation/fpga/dfl.rst +++ b/Documentation/fpga/dfl.rst @@ -10,7 +10,7 @@ Authors: - Xu Yilun <yilun.xu@intel.com> The Device Feature List (DFL) FPGA framework (and drivers according to -this framework) hides the very details of low layer hardwares and provides +this framework) hides the very details of low layer hardware and provides unified interfaces to userspace. Applications could use these interfaces to configure, enumerate, open and access FPGA accelerators on platforms which implement the DFL in the device memory. Besides this, the DFL framework @@ -205,7 +205,7 @@ given Device Feature Lists and create platform devices for feature devices also abstracts operations for the private features and exposes common ops to feature device drivers. -The FPGA DFL Device could be different hardwares, e.g. PCIe device, platform +The FPGA DFL Device could be different hardware, e.g. PCIe device, platform device and etc. Its driver module is always loaded first once the device is created by the system. This driver plays an infrastructural role in the driver architecture. It locates the DFLs in the device memory, handles them diff --git a/Documentation/trace/coresight/coresight-config.rst b/Documentation/trace/coresight/coresight-config.rst new file mode 100644 index 000000000000..a4e3ef295240 --- /dev/null +++ b/Documentation/trace/coresight/coresight-config.rst @@ -0,0 +1,244 @@ +.. SPDX-License-Identifier: GPL-2.0 + +====================================== +CoreSight System Configuration Manager +====================================== + + :Author: Mike Leach <mike.leach@linaro.org> + :Date: October 2020 + +Introduction +============ + +The CoreSight System Configuration manager is an API that allows the +programming of the CoreSight system with pre-defined configurations that +can then be easily enabled from sysfs or perf. + +Many CoreSight components can be programmed in complex ways - especially ETMs. +In addition, components can interact across the CoreSight system, often via +the cross trigger components such as CTI and CTM. These system settings can +be defined and enabled as named configurations. + + +Basic Concepts +============== + +This section introduces the basic concepts of a CoreSight system configuration. + + +Features +-------- + +A feature is a named set of programming for a CoreSight device. The programming +is device dependent, and can be defined in terms of absolute register values, +resource usage and parameter values. + +The feature is defined using a descriptor. This descriptor is used to load onto +a matching device, either when the feature is loaded into the system, or when the +CoreSight device is registered with the configuration manager. + +The load process involves interpreting the descriptor into a set of register +accesses in the driver - the resource usage and parameter descriptions +translated into appropriate register accesses. This interpretation makes it easy +and efficient for the feature to be programmed onto the device when required. + +The feature will not be active on the device until the feature is enabled, and +the device itself is enabled. When the device is enabled then enabled features +will be programmed into the device hardware. + +A feature is enabled as part of a configuration being enabled on the system. + + +Parameter Value +~~~~~~~~~~~~~~~ + +A parameter value is a named value that may be set by the user prior to the +feature being enabled that can adjust the behaviour of the operation programmed +by the feature. + +For example, this could be a count value in a programmed operation that repeats +at a given rate. When the feature is enabled then the current value of the +parameter is used in programming the device. + +The feature descriptor defines a default value for a parameter, which is used +if the user does not supply a new value. + +Users can update parameter values using the configfs API for the CoreSight +system - which is described below. + +The current value of the parameter is loaded into the device when the feature +is enabled on that device. + + +Configurations +-------------- + +A configuration defines a set of features that are to be used in a trace +session where the configuration is selected. For any trace session only one +configuration may be selected. + +The features defined may be on any type of device that is registered +to support system configuration. A configuration may select features to be +enabled on a class of devices - i.e. any ETMv4, or specific devices, e.g. a +specific CTI on the system. + +As with the feature, a descriptor is used to define the configuration. +This will define the features that must be enabled as part of the configuration +as well as any preset values that can be used to override default parameter +values. + + +Preset Values +~~~~~~~~~~~~~ + +Preset values are easily selectable sets of parameter values for the features +that the configuration uses. The number of values in a single preset set, equals +the sum of parameter values in the features used by the configuration. + +e.g. a configuration consists of 3 features, one has 2 parameters, one has +a single parameter, and another has no parameters. A single preset set will +therefore have 3 values. + +Presets are optionally defined by the configuration, up to 15 can be defined. +If no preset is selected, then the parameter values defined in the feature +are used as normal. + + +Operation +~~~~~~~~~ + +The following steps take place in the operation of a configuration. + +1) In this example, the configuration is 'autofdo', which has an + associated feature 'strobing' that works on ETMv4 CoreSight Devices. + +2) The configuration is enabled. For example 'perf' may select the + configuration as part of its command line:: + + perf record -e cs_etm/autofdo/ myapp + + which will enable the 'autofdo' configuration. + +3) perf starts tracing on the system. As each ETMv4 that perf uses for + trace is enabled, the configuration manager will check if the ETMv4 + has a feature that relates to the currently active configuration. + In this case 'strobing' is enabled & programmed into the ETMv4. + +4) When the ETMv4 is disabled, any registers marked as needing to be + saved will be read back. + +5) At the end of the perf session, the configuration will be disabled. + + +Viewing Configurations and Features +=================================== + +The set of configurations and features that are currently loaded into the +system can be viewed using the configfs API. + +Mount configfs as normal and the 'cs-syscfg' subsystem will appear:: + + $ ls /config + cs-syscfg stp-policy + +This has two sub-directories:: + + $ cd cs-syscfg/ + $ ls + configurations features + +The system has the configuration 'autofdo' built in. It may be examined as +follows:: + + $ cd configurations/ + $ ls + autofdo + $ cd autofdo/ + $ ls + description preset1 preset3 preset5 preset7 preset9 + feature_refs preset2 preset4 preset6 preset8 + $ cat description + Setup ETMs with strobing for autofdo + $ cat feature_refs + strobing + +Each preset declared has a preset<n> subdirectory declared. The values for +the preset can be examined:: + + $ cat preset1/values + strobing.window = 0x1388 strobing.period = 0x2 + $ cat preset2/values + strobing.window = 0x1388 strobing.period = 0x4 + +The features referenced by the configuration can be examined in the features +directory:: + + $ cd ../../features/strobing/ + $ ls + description matches nr_params params + $ cat description + Generate periodic trace capture windows. + parameter 'window': a number of CPU cycles (W) + parameter 'period': trace enabled for W cycles every period x W cycles + $ cat matches + SRC_ETMV4 + $ cat nr_params + 2 + +Move to the params directory to examine and adjust parameters:: + + cd params + $ ls + period window + $ cd period + $ ls + value + $ cat value + 0x2710 + # echo 15000 > value + # cat value + 0x3a98 + +Parameters adjusted in this way are reflected in all device instances that have +loaded the feature. + + +Using Configurations in perf +============================ + +The configurations loaded into the CoreSight configuration management are +also declared in the perf 'cs_etm' event infrastructure so that they can +be selected when running trace under perf:: + + $ ls /sys/devices/cs_etm + configurations format perf_event_mux_interval_ms sinks type + events nr_addr_filters power + +Key directories here are 'configurations' - which lists the loaded +configurations, and 'events' - a generic perf directory which allows +selection on the perf command line.:: + + $ ls configurations/ + autofdo + $ cat configurations/autofdo + 0xa7c3dddd + +As with the sinks entries, this provides a hash of the configuration name. +The entry in the 'events' directory uses perfs built in syntax generator +to substitute the syntax for the name when evaluating the command:: + + $ ls events/ + autofdo + $ cat events/autofdo + configid=0xa7c3dddd + +The 'autofdo' configuration may be selected on the perf command line:: + + $ perf record -e cs_etm/autofdo/u --per-thread <application> + +A preset to override the current parameter values can also be selected:: + + $ perf record -e cs_etm/autofdo,preset=1/u --per-thread <application> + +When configurations are selected in this way, then the trace sink used is +automatically selected. diff --git a/Documentation/trace/coresight/coresight.rst b/Documentation/trace/coresight/coresight.rst index 1ec8dc35b1d8..a15571d96cc8 100644 --- a/Documentation/trace/coresight/coresight.rst +++ b/Documentation/trace/coresight/coresight.rst @@ -620,6 +620,19 @@ channels on the CTM (Cross Trigger Matrix). A separate documentation file is provided to explain the use of these devices. (Documentation/trace/coresight/coresight-ect.rst) [#fourth]_. +CoreSight System Configuration +------------------------------ + +CoreSight components can be complex devices with many programming options. +Furthermore, components can be programmed to interact with each other across the +complete system. + +A CoreSight System Configuration manager is provided to allow these complex programming +configurations to be selected and used easily from perf and sysfs. + +See the separate document for further information. +(Documentation/trace/coresight/coresight-config.rst) [#fifth]_. + .. [#first] Documentation/ABI/testing/sysfs-bus-coresight-devices-stm @@ -628,3 +641,5 @@ A separate documentation file is provided to explain the use of these devices. .. [#third] https://github.com/Linaro/perf-opencsd .. [#fourth] Documentation/trace/coresight/coresight-ect.rst + +.. [#fifth] Documentation/trace/coresight/coresight-config.rst |