From ae5c961da6483b413dcb36d8bf6a881ffd2fb33f Mon Sep 17 00:00:00 2001 From: Rajan Vaja Date: Fri, 24 Apr 2020 13:58:04 -0700 Subject: firmware: xilinx: Add sysfs interface Add firmware-ggs sysfs interface which provides read/write interface to global storage registers. Signed-off-by: Rajan Vaja Signed-off-by: Michal Simek Signed-off-by: Tejas Patel Signed-off-by: Jolly Shah Link: https://lore.kernel.org/r/1587761887-4279-23-git-send-email-jolly.shah@xilinx.com Signed-off-by: Greg Kroah-Hartman --- .../ABI/stable/sysfs-driver-firmware-zynqmp | 50 ++++++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 Documentation/ABI/stable/sysfs-driver-firmware-zynqmp (limited to 'Documentation') diff --git a/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp b/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp new file mode 100644 index 000000000000..2e3aebd01d16 --- /dev/null +++ b/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp @@ -0,0 +1,50 @@ +What: /sys/devices/platform/firmware\:zynqmp-firmware/ggs* +Date: March 2020 +KernelVersion: 5.6 +Contact: "Jolly Shah" +Description: + Read/Write PMU global general storage register value, + GLOBAL_GEN_STORAGE{0:3}. + Global general storage register that can be used + by system to pass information between masters. + + The register is reset during system or power-on + resets. Three registers are used by the FSBL and + other Xilinx software products: GLOBAL_GEN_STORAGE{4:6}. + + Usage: + # cat /sys/devices/platform/firmware\:zynqmp-firmware/ggs0 + # echo > /sys/devices/platform/firmware\:zynqmp-firmware/ggs0 + + Example: + # cat /sys/devices/platform/firmware\:zynqmp-firmware/ggs0 + # echo 0x1234ABCD > /sys/devices/platform/firmware\:zynqmp-firmware/ggs0 + +Users: Xilinx + +What: /sys/devices/platform/firmware\:zynqmp-firmware/pggs* +Date: March 2020 +KernelVersion: 5.6 +Contact: "Jolly Shah" +Description: + Read/Write PMU persistent global general storage register + value, PERS_GLOB_GEN_STORAGE{0:3}. + Persistent global general storage register that + can be used by system to pass information between + masters. + + This register is only reset by the power-on reset + and maintains its value through a system reset. + Four registers are used by the FSBL and other Xilinx + software products: PERS_GLOB_GEN_STORAGE{4:7}. + Register is reset only by a POR reset. + + Usage: + # cat /sys/devices/platform/firmware\:zynqmp-firmware/pggs0 + # echo > /sys/devices/platform/firmware\:zynqmp-firmware/pggs0 + + Example: + # cat /sys/devices/platform/firmware\:zynqmp-firmware/pggs0 + # echo 0x1234ABCD > /sys/devices/platform/firmware\:zynqmp-firmware/pggs0 + +Users: Xilinx -- cgit From b3ae24c44848c6403fb2333d7cbe494565058352 Mon Sep 17 00:00:00 2001 From: Rajan Vaja Date: Fri, 24 Apr 2020 13:58:06 -0700 Subject: firmware: xilinx: Add sysfs to set shutdown scope The Linux shutdown functionality implemented via PSCI system_off does not include an option to set a scope, i.e. which parts of the system to shut down. This patch creates sysfs that allows to set the shutdown scope for the next shutdown request. When the next shutdown is performed, the platform specific portion of PSCI-system_off can use the chosen shutdown scope. Signed-off-by: Rajan Vaja Signed-off-by: Stefan Krsmanovic Signed-off-by: Michal Simek Signed-off-by: Tejas Patel Signed-off-by: Jolly Shah Link: https://lore.kernel.org/r/1587761887-4279-25-git-send-email-jolly.shah@xilinx.com Signed-off-by: Greg Kroah-Hartman --- .../ABI/stable/sysfs-driver-firmware-zynqmp | 32 ++++++++++++++++++++++ 1 file changed, 32 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp b/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp index 2e3aebd01d16..554f30c3b398 100644 --- a/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp +++ b/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp @@ -48,3 +48,35 @@ Description: # echo 0x1234ABCD > /sys/devices/platform/firmware\:zynqmp-firmware/pggs0 Users: Xilinx + +What: /sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope +Date: March 2020 +KernelVersion: 5.6 +Contact: "Jolly Shah" +Description: + This sysfs interface allows to set the shutdown scope for the + next shutdown request. When the next shutdown is performed, the + platform specific portion of PSCI-system_off can use the chosen + shutdown scope. + + Following are available shutdown scopes(subtypes): + + subsystem: Only the APU along with all of its peripherals + not used by other processing units will be + shut down. This may result in the FPD power + domain being shut down provided that no other + processing unit uses FPD peripherals or DRAM. + ps_only: The complete PS will be shut down, including the + RPU, PMU, etc. Only the PL domain (FPGA) + remains untouched. + system: The complete system/device is shut down. + + Usage: + # cat /sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope + # echo > /sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope + + Example: + # cat /sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope + # echo "subsystem" > /sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope + +Users: Xilinx -- cgit From a2cc220a9a9227b2c5c9b39f57340bce64f040fd Mon Sep 17 00:00:00 2001 From: Rajan Vaja Date: Fri, 24 Apr 2020 13:58:07 -0700 Subject: firmware: xilinx: Add sysfs and API to set boot health status Add sysfs interface to set boot health status from user space. Add API used by this interface to communicate with firmware. If PMUFW is compiled with CHECK_HEALTHY_BOOT, it will check the healthy bit on FPD WDT expiration. If healthy bit is set by a user application running in Linux, PMUFW will do APU only restart. If healthy bit is not set during FPD WDT expiration, PMUFW will do system restart. Signed-off-by: Rajan Vaja Signed-off-by: Michal Simek Signed-off-by: Tejas Patel Signed-off-by: Jolly Shah Link: https://lore.kernel.org/r/1587761887-4279-26-git-send-email-jolly.shah@xilinx.com Signed-off-by: Greg Kroah-Hartman --- .../ABI/stable/sysfs-driver-firmware-zynqmp | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp b/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp index 554f30c3b398..00fa04c76ff3 100644 --- a/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp +++ b/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp @@ -80,3 +80,24 @@ Description: # echo "subsystem" > /sys/devices/platform/firmware\:zynqmp-firmware/shutdown_scope Users: Xilinx + +What: /sys/devices/platform/firmware\:zynqmp-firmware/health_status +Date: March 2020 +KernelVersion: 5.6 +Contact: "Jolly Shah" +Description: + This sysfs interface allows to set the health status. If PMUFW + is compiled with CHECK_HEALTHY_BOOT, it will check the healthy + bit on FPD WDT expiration. If healthy bit is set by a user + application running in Linux, PMUFW will do APU only restart. If + healthy bit is not set during FPD WDT expiration, PMUFW will do + system restart. + + Usage: + Set healthy bit + # echo 1 > /sys/devices/platform/firmware\:zynqmp-firmware/health_status + + Unset healthy bit + # echo 0 > /sys/devices/platform/firmware\:zynqmp-firmware/health_status + +Users: Xilinx -- cgit From 1f03ac9460cf0c4886fc8a72fb3d0cd479b59bca Mon Sep 17 00:00:00 2001 From: Xu Yilun Date: Mon, 27 Apr 2020 09:06:22 +0800 Subject: Documentation: fpga: dfl: add description for performance reporting support This patch adds description for performance reporting support for Device Feature List (DFL) based FPGA. Signed-off-by: Xu Yilun Signed-off-by: Wu Hao Link: https://lore.kernel.org/r/1587949583-12058-2-git-send-email-hao.wu@intel.com Signed-off-by: Greg Kroah-Hartman --- Documentation/fpga/dfl.rst | 84 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 84 insertions(+) (limited to 'Documentation') diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst index 094fc8aacd8e..978c4af416a4 100644 --- a/Documentation/fpga/dfl.rst +++ b/Documentation/fpga/dfl.rst @@ -118,6 +118,11 @@ More functions are exposed through sysfs management information (current temperature, thresholds, threshold status, etc.). + Performance reporting + performance counters are exposed through perf PMU APIs. Standard perf tool + can be used to monitor all available perf events. Please see performance + counter section below for more detailed information. + FIU - PORT ========== @@ -378,6 +383,85 @@ The device nodes used for ioctl() or mmap() can be referenced through:: /sys/class/fpga_region///dev +Performance Counters +==================== +Performance reporting is one private feature implemented in FME. It could +supports several independent, system-wide, device counter sets in hardware to +monitor and count for performance events, including "basic", "cache", "fabric", +"vtd" and "vtd_sip" counters. Users could use standard perf tool to monitor +FPGA cache hit/miss rate, transaction number, interface clock counter of AFU +and other FPGA performance events. + +Different FPGA devices may have different counter sets, depending on hardware +implementation. E.g., some discrete FPGA cards don't have any cache. User could +use "perf list" to check which perf events are supported by target hardware. + +In order to allow user to use standard perf API to access these performance +counters, driver creates a perf PMU, and related sysfs interfaces in +/sys/bus/event_source/devices/dfl_fme* to describe available perf events and +configuration options. + +The "format" directory describes the format of the config field of struct +perf_event_attr. There are 3 bitfields for config: "evtype" defines which type +the perf event belongs to; "event" is the identity of the event within its +category; "portid" is introduced to decide counters set to monitor on FPGA +overall data or a specific port. + +The "events" directory describes the configuration templates for all available +events which can be used with perf tool directly. For example, fab_mmio_read +has the configuration "event=0x06,evtype=0x02,portid=0xff", which shows this +event belongs to fabric type (0x02), the local event id is 0x06 and it is for +overall monitoring (portid=0xff). + +Example usage of perf:: + + $# perf list |grep dfl_fme + + dfl_fme0/fab_mmio_read/ [Kernel PMU event] + <...> + dfl_fme0/fab_port_mmio_read,portid=?/ [Kernel PMU event] + <...> + + $# perf stat -a -e dfl_fme0/fab_mmio_read/ + or + $# perf stat -a -e dfl_fme0/event=0x06,evtype=0x02,portid=0xff/ + or + $# perf stat -a -e dfl_fme0/config=0xff2006/ + +Another example, fab_port_mmio_read monitors mmio read of a specific port. So +its configuration template is "event=0x06,evtype=0x01,portid=?". The portid +should be explicitly set. + +Its usage of perf:: + + $# perf stat -a -e dfl_fme0/fab_port_mmio_read,portid=0x0/ + or + $# perf stat -a -e dfl_fme0/event=0x06,evtype=0x02,portid=0x0/ + or + $# perf stat -a -e dfl_fme0/config=0x2006/ + +Please note for fabric counters, overall perf events (fab_*) and port perf +events (fab_port_*) actually share one set of counters in hardware, so it can't +monitor both at the same time. If this set of counters is configured to monitor +overall data, then per port perf data is not supported. See below example:: + + $# perf stat -e dfl_fme0/fab_mmio_read/,dfl_fme0/fab_port_mmio_write,\ + portid=0/ sleep 1 + + Performance counter stats for 'system wide': + + 3 dfl_fme0/fab_mmio_read/ + dfl_fme0/fab_port_mmio_write,portid=0x0/ + + 1.001750904 seconds time elapsed + +The driver also provides a "cpumask" sysfs attribute, which contains only one +CPU id used to access these perf events. Counting on multiple CPU is not allowed +since they are system-wide counters on FPGA device. + +The current driver does not support sampling. So "perf record" is unsupported. + + Add new FIUs support ==================== It's possible that developers made some new function blocks (FIUs) under this -- cgit From 724142f8c42a7b01dbf9738eb00d7addbad6f862 Mon Sep 17 00:00:00 2001 From: Wu Hao Date: Mon, 27 Apr 2020 09:06:23 +0800 Subject: fpga: dfl: fme: add performance reporting support This patch adds support for performance reporting private feature for FPGA Management Engine (FME). Now it supports several different performance counters, including 'basic', 'cache', 'fabric', 'vtd' and 'vtd_sip'. It allows user to use standard linux tools to access these performance counters. e.g. List all events by "perf list" perf list | grep fme dfl_fme0/cache_read_hit/ [Kernel PMU event] dfl_fme0/cache_read_miss/ [Kernel PMU event] ... dfl_fme0/fab_mmio_read/ [Kernel PMU event] dfl_fme0/fab_mmio_write/ [Kernel PMU event] ... dfl_fme0/fab_port_mmio_read,portid=?/ [Kernel PMU event] dfl_fme0/fab_port_mmio_write,portid=?/ [Kernel PMU event] ... dfl_fme0/vtd_port_devtlb_1g_fill,portid=?/ [Kernel PMU event] dfl_fme0/vtd_port_devtlb_2m_fill,portid=?/ [Kernel PMU event] ... dfl_fme0/vtd_sip_iotlb_1g_hit/ [Kernel PMU event] dfl_fme0/vtd_sip_iotlb_1g_miss/ [Kernel PMU event] ... dfl_fme0/clock [Kernel PMU event] ... e.g. check increased counter value after run one application using "perf stat" command. perf stat -e dfl_fme0/fab_mmio_read/,dfl_fme0/fab_mmio_write/ ./test Performance counter stats for './test': 1 dfl_fme0/fab_mmio_read/ 2 dfl_fme0/fab_mmio_write/ 1.009496520 seconds time elapsed Please note that fabric counters support both fab_* and fab_port_*, but actually they are sharing one set of performance counters in hardware. If user wants to monitor overall data events on fab_* then fab_port_* can't be supported at the same time, see example below: perf stat -e dfl_fme0/fab_mmio_read/,dfl_fme0/fab_port_mmio_write,portid=0/ Performance counter stats for 'system wide': 0 dfl_fme0/fab_mmio_read/ dfl_fme0/fab_port_mmio_write,portid=0/ 2.141064085 seconds time elapsed Signed-off-by: Luwei Kang Signed-off-by: Xu Yilun Signed-off-by: Wu Hao Link: https://lore.kernel.org/r/1587949583-12058-3-git-send-email-hao.wu@intel.com Signed-off-by: Greg Kroah-Hartman --- .../testing/sysfs-bus-event_source-devices-dfl_fme | 104 +++++++++++++++++++++ 1 file changed, 104 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-event_source-devices-dfl_fme (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-dfl_fme b/Documentation/ABI/testing/sysfs-bus-event_source-devices-dfl_fme new file mode 100644 index 000000000000..c9278a3b3df1 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-dfl_fme @@ -0,0 +1,104 @@ +What: /sys/bus/event_source/devices/dfl_fmeX/format +Date: April 2020 +KernelVersion: 5.8 +Contact: Wu Hao +Description: Read-only. Attribute group to describe the magic bits + that go into perf_event_attr.config for a particular pmu. + (See ABI/testing/sysfs-bus-event_source-devices-format). + + Each attribute under this group defines a bit range of the + perf_event_attr.config. All supported attributes are listed + below. + + event = "config:0-11" - event ID + evtype = "config:12-15" - event type + portid = "config:16-23" - event source + + For example, + + fab_mmio_read = "event=0x06,evtype=0x02,portid=0xff" + + It shows this fab_mmio_read is a fabric type (0x02) event with + 0x06 local event id for overall monitoring (portid=0xff). + +What: /sys/bus/event_source/devices/dfl_fmeX/cpumask +Date: April 2020 +KernelVersion: 5.8 +Contact: Wu Hao +Description: Read-only. This file always returns cpu which the PMU is bound + for access to all fme pmu performance monitoring events. + +What: /sys/bus/event_source/devices/dfl_fmeX/events +Date: April 2020 +KernelVersion: 5.8 +Contact: Wu Hao +Description: Read-only. Attribute group to describe performance monitoring + events specific to fme. Each attribute in this group describes + a single performance monitoring event supported by this fme pmu. + The name of the file is the name of the event. + (See ABI/testing/sysfs-bus-event_source-devices-events). + + All supported performance monitoring events are listed below. + + Basic events (evtype=0x00) + + clock = "event=0x00,evtype=0x00,portid=0xff" + + Cache events (evtype=0x01) + + cache_read_hit = "event=0x00,evtype=0x01,portid=0xff" + cache_read_miss = "event=0x01,evtype=0x01,portid=0xff" + cache_write_hit = "event=0x02,evtype=0x01,portid=0xff" + cache_write_miss = "event=0x03,evtype=0x01,portid=0xff" + cache_hold_request = "event=0x05,evtype=0x01,portid=0xff" + cache_data_write_port_contention = + "event=0x06,evtype=0x01,portid=0xff" + cache_tag_write_port_contention = + "event=0x07,evtype=0x01,portid=0xff" + cache_tx_req_stall = "event=0x08,evtype=0x01,portid=0xff" + cache_rx_req_stall = "event=0x09,evtype=0x01,portid=0xff" + cache_eviction = "event=0x0a,evtype=0x01,portid=0xff" + + Fabric events (evtype=0x02) + + fab_pcie0_read = "event=0x00,evtype=0x02,portid=0xff" + fab_pcie0_write = "event=0x01,evtype=0x02,portid=0xff" + fab_pcie1_read = "event=0x02,evtype=0x02,portid=0xff" + fab_pcie1_write = "event=0x03,evtype=0x02,portid=0xff" + fab_upi_read = "event=0x04,evtype=0x02,portid=0xff" + fab_upi_write = "event=0x05,evtype=0x02,portid=0xff" + fab_mmio_read = "event=0x06,evtype=0x02,portid=0xff" + fab_mmio_write = "event=0x07,evtype=0x02,portid=0xff" + fab_port_pcie0_read = "event=0x00,evtype=0x02,portid=?" + fab_port_pcie0_write = "event=0x01,evtype=0x02,portid=?" + fab_port_pcie1_read = "event=0x02,evtype=0x02,portid=?" + fab_port_pcie1_write = "event=0x03,evtype=0x02,portid=?" + fab_port_upi_read = "event=0x04,evtype=0x02,portid=?" + fab_port_upi_write = "event=0x05,evtype=0x02,portid=?" + fab_port_mmio_read = "event=0x06,evtype=0x02,portid=?" + fab_port_mmio_write = "event=0x07,evtype=0x02,portid=?" + + VTD events (evtype=0x03) + + vtd_port_read_transaction = "event=0x00,evtype=0x03,portid=?" + vtd_port_write_transaction = "event=0x01,evtype=0x03,portid=?" + vtd_port_devtlb_read_hit = "event=0x02,evtype=0x03,portid=?" + vtd_port_devtlb_write_hit = "event=0x03,evtype=0x03,portid=?" + vtd_port_devtlb_4k_fill = "event=0x04,evtype=0x03,portid=?" + vtd_port_devtlb_2m_fill = "event=0x05,evtype=0x03,portid=?" + vtd_port_devtlb_1g_fill = "event=0x06,evtype=0x03,portid=?" + + VTD SIP events (evtype=0x04) + + vtd_sip_iotlb_4k_hit = "event=0x00,evtype=0x04,portid=0xff" + vtd_sip_iotlb_2m_hit = "event=0x01,evtype=0x04,portid=0xff" + vtd_sip_iotlb_1g_hit = "event=0x02,evtype=0x04,portid=0xff" + vtd_sip_slpwc_l3_hit = "event=0x03,evtype=0x04,portid=0xff" + vtd_sip_slpwc_l4_hit = "event=0x04,evtype=0x04,portid=0xff" + vtd_sip_rcc_hit = "event=0x05,evtype=0x04,portid=0xff" + vtd_sip_iotlb_4k_miss = "event=0x06,evtype=0x04,portid=0xff" + vtd_sip_iotlb_2m_miss = "event=0x07,evtype=0x04,portid=0xff" + vtd_sip_iotlb_1g_miss = "event=0x08,evtype=0x04,portid=0xff" + vtd_sip_slpwc_l3_miss = "event=0x09,evtype=0x04,portid=0xff" + vtd_sip_slpwc_l4_miss = "event=0x0a,evtype=0x04,portid=0xff" + vtd_sip_rcc_miss = "event=0x0b,evtype=0x04,portid=0xff" -- cgit From 146eee039d7ab236f71edd56b975f4ff49635db9 Mon Sep 17 00:00:00 2001 From: Leonard Crestez Date: Mon, 6 Apr 2020 15:03:06 +0300 Subject: dt-bindings: interconnect: Add bindings for imx8m noc Add initial dt bindings for the interconnects inside i.MX chips. Multiple external IPs are involved but SOC integration means the software controllable interfaces are very similar. Main NOC node acts as interconnect provider if #interconnect-cells is present. Currently there is a single imx interconnect provider for the whole SOC. Other pieces of scalable interconnects can be present, each with their own OPP table. Signed-off-by: Leonard Crestez Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/8b341d91e9aee679ae69feb22a2c842b2aeb2137.1586174566.git.leonard.crestez@nxp.com Signed-off-by: Georgi Djakov --- .../bindings/interconnect/fsl,imx8m-noc.yaml | 101 +++++++++++++++++++++ 1 file changed, 101 insertions(+) create mode 100644 Documentation/devicetree/bindings/interconnect/fsl,imx8m-noc.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interconnect/fsl,imx8m-noc.yaml b/Documentation/devicetree/bindings/interconnect/fsl,imx8m-noc.yaml new file mode 100644 index 000000000000..ff09550ad959 --- /dev/null +++ b/Documentation/devicetree/bindings/interconnect/fsl,imx8m-noc.yaml @@ -0,0 +1,101 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interconnect/fsl,imx8m-noc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Generic i.MX bus frequency device + +maintainers: + - Leonard Crestez + +description: | + The i.MX SoC family has multiple buses for which clock frequency (and + sometimes voltage) can be adjusted. + + Some of those buses expose register areas mentioned in the memory maps as GPV + ("Global Programmers View") but not all. Access to this area might be denied + for normal (non-secure) world. + + The buses are based on externally licensed IPs such as ARM NIC-301 and + Arteris FlexNOC but DT bindings are specific to the integration of these bus + interconnect IPs into imx SOCs. + +properties: + compatible: + oneOf: + - items: + - enum: + - fsl,imx8mn-nic + - fsl,imx8mm-nic + - fsl,imx8mq-nic + - const: fsl,imx8m-nic + - items: + - enum: + - fsl,imx8mn-noc + - fsl,imx8mm-noc + - fsl,imx8mq-noc + - const: fsl,imx8m-noc + - const: fsl,imx8m-nic + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + operating-points-v2: true + opp-table: true + + fsl,ddrc: + $ref: "/schemas/types.yaml#/definitions/phandle" + description: + Phandle to DDR Controller. + + '#interconnect-cells': + description: + If specified then also act as an interconnect provider. Should only be + set once per soc on the main noc. + const: 1 + +required: + - compatible + - clocks + +additionalProperties: false + +examples: + - | + #include + #include + #include + + noc: interconnect@32700000 { + compatible = "fsl,imx8mm-noc", "fsl,imx8m-noc"; + reg = <0x32700000 0x100000>; + clocks = <&clk IMX8MM_CLK_NOC>; + #interconnect-cells = <1>; + fsl,ddrc = <&ddrc>; + + operating-points-v2 = <&noc_opp_table>; + noc_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp-133M { + opp-hz = /bits/ 64 <133333333>; + }; + opp-800M { + opp-hz = /bits/ 64 <800000000>; + }; + }; + }; + + ddrc: memory-controller@3d400000 { + compatible = "fsl,imx8mm-ddrc", "fsl,imx8m-ddrc"; + reg = <0x3d400000 0x400000>; + clock-names = "core", "pll", "alt", "apb"; + clocks = <&clk IMX8MM_CLK_DRAM_CORE>, + <&clk IMX8MM_DRAM_PLL>, + <&clk IMX8MM_CLK_DRAM_ALT>, + <&clk IMX8MM_CLK_DRAM_APB>; + }; -- cgit From 2e00dd1bd6567148c331469c60ded9715ac749c7 Mon Sep 17 00:00:00 2001 From: Richard Gong Date: Fri, 14 Feb 2020 10:00:46 -0600 Subject: dt-bindings: fpga: add compatible value to Stratix10 SoC FPGA manager binding Add a compatible property value to Stratix10 SoC FPGA manager binding file Signed-off-by: Richard Gong Acked-by: Rob Herring Signed-off-by: Moritz Fischer --- .../devicetree/bindings/fpga/intel-stratix10-soc-fpga-mgr.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/fpga/intel-stratix10-soc-fpga-mgr.txt b/Documentation/devicetree/bindings/fpga/intel-stratix10-soc-fpga-mgr.txt index 6e03f79287fb..0f874137ca46 100644 --- a/Documentation/devicetree/bindings/fpga/intel-stratix10-soc-fpga-mgr.txt +++ b/Documentation/devicetree/bindings/fpga/intel-stratix10-soc-fpga-mgr.txt @@ -4,7 +4,8 @@ Required properties: The fpga_mgr node has the following mandatory property, must be located under firmware/svc node. -- compatible : should contain "intel,stratix10-soc-fpga-mgr" +- compatible : should contain "intel,stratix10-soc-fpga-mgr" or + "intel,agilex-soc-fpga-mgr" Example: -- cgit From fba965a79b925b35bee69472c7caa5ff8d6a8672 Mon Sep 17 00:00:00 2001 From: Richard Gong Date: Fri, 14 Feb 2020 10:00:49 -0600 Subject: dt-bindings, firmware: add compatible value Intel Stratix10 service layer binding A a compatible property value to Intel Stratix10 service layer binding Signed-off-by: Richard Gong Acked-by: Rob Herring Signed-off-by: Moritz Fischer --- Documentation/devicetree/bindings/firmware/intel,stratix10-svc.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.txt b/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.txt index 1fa66065acc6..6eff1afd8daf 100644 --- a/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.txt +++ b/Documentation/devicetree/bindings/firmware/intel,stratix10-svc.txt @@ -23,7 +23,7 @@ Required properties: The svc node has the following mandatory properties, must be located under the firmware node. -- compatible: "intel,stratix10-svc" +- compatible: "intel,stratix10-svc" or "intel,agilex-svc" - method: smc or hvc smc - Secure Monitor Call hvc - Hypervisor Call -- cgit From 01de995075b20f58a77f408cdf49034682487429 Mon Sep 17 00:00:00 2001 From: Pierre-Louis Bossart Date: Mon, 20 Apr 2020 02:51:14 +0800 Subject: Documentation: SoundWire: clarify TDM mode support The current description of stream topologies does not explicitly mention 'mirror' topologies used for audio amplifiers, where all amplifiers see the same data and generate a different output based on configuration or dynamic information. Add examples and notes to explain how channels can be transmitted and mapped. Signed-off-by: Pierre-Louis Bossart Signed-off-by: Bard Liao Link: https://lore.kernel.org/r/20200419185117.4233-1-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul --- Documentation/driver-api/soundwire/stream.rst | 89 ++++++++++++++++++++++++++- 1 file changed, 86 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/soundwire/stream.rst b/Documentation/driver-api/soundwire/stream.rst index 8bceece51554..1b386076402c 100644 --- a/Documentation/driver-api/soundwire/stream.rst +++ b/Documentation/driver-api/soundwire/stream.rst @@ -75,8 +75,33 @@ Slaves are using single port. :: | (Data) | +---------------+ +Example 4: Stereo Stream with L and R channels is rendered by +Master. Both of the L and R channels are received by two different +Slaves. Master and both Slaves are using single port handling +L+R. Each Slave device processes the L + R data locally, typically +based on static configuration or dynamic orientation, and may drive +one or more speakers. :: -Example 4: Stereo Stream with L and R channel is rendered by two different + +---------------+ Clock Signal +---------------+ + | Master +---------+------------------------+ Slave | + | Interface | | | Interface | + | | | | 1 | + | | | Data Signal | | + | L + R +---+------------------------------+ L + R | + | (Data) | | | Data Direction | (Data) | + +---------------+ | | +-------------> +---------------+ + | | + | | + | | +---------------+ + | +----------------------> | Slave | + | | Interface | + | | 2 | + | | | + +----------------------------> | L + R | + | (Data) | + +---------------+ + +Example 5: Stereo Stream with L and R channel is rendered by two different Ports of the Master and is received by only single Port of the Slave interface. :: @@ -101,7 +126,7 @@ interface. :: +--------------------+ | | +----------------+ -Example 5: Stereo Stream with L and R channel is rendered by 2 Masters, each +Example 6: Stereo Stream with L and R channel is rendered by 2 Masters, each rendering one channel, and is received by two different Slaves, each receiving one channel. Both Masters and both Slaves are using single port. :: @@ -123,12 +148,70 @@ receiving one channel. Both Masters and both Slaves are using single port. :: | (Data) | Data Direction | (Data) | +---------------+ +-----------------------> +---------------+ -Note: In multi-link cases like above, to lock, one would acquire a global +Example 7: Stereo Stream with L and R channel is rendered by 2 +Masters, each rendering both channels. Each Slave receives L + R. This +is the same application as Example 4 but with Slaves placed on +separate links. :: + + +---------------+ Clock Signal +---------------+ + | Master +----------------------------------+ Slave | + | Interface | | Interface | + | 1 | | 1 | + | | Data Signal | | + | L + R +----------------------------------+ L + R | + | (Data) | Data Direction | (Data) | + +---------------+ +-----------------------> +---------------+ + + +---------------+ Clock Signal +---------------+ + | Master +----------------------------------+ Slave | + | Interface | | Interface | + | 2 | | 2 | + | | Data Signal | | + | L + R +----------------------------------+ L + R | + | (Data) | Data Direction | (Data) | + +---------------+ +-----------------------> +---------------+ + +Example 8: 4-channel Stream is rendered by 2 Masters, each rendering a +2 channels. Each Slave receives 2 channels. :: + + +---------------+ Clock Signal +---------------+ + | Master +----------------------------------+ Slave | + | Interface | | Interface | + | 1 | | 1 | + | | Data Signal | | + | L1 + R1 +----------------------------------+ L1 + R1 | + | (Data) | Data Direction | (Data) | + +---------------+ +-----------------------> +---------------+ + + +---------------+ Clock Signal +---------------+ + | Master +----------------------------------+ Slave | + | Interface | | Interface | + | 2 | | 2 | + | | Data Signal | | + | L2 + R2 +----------------------------------+ L2 + R2 | + | (Data) | Data Direction | (Data) | + +---------------+ +-----------------------> +---------------+ + +Note1: In multi-link cases like above, to lock, one would acquire a global lock and then go on locking bus instances. But, in this case the caller framework(ASoC DPCM) guarantees that stream operations on a card are always serialized. So, there is no race condition and hence no need for global lock. +Note2: A Slave device may be configured to receive all channels +transmitted on a link for a given Stream (Example 4) or just a subset +of the data (Example 3). The configuration of the Slave device is not +handled by a SoundWire subsystem API, but instead by the +snd_soc_dai_set_tdm_slot() API. The platform or machine driver will +typically configure which of the slots are used. For Example 4, the +same slots would be used by all Devices, while for Example 3 the Slave +Device1 would use e.g. Slot 0 and Slave device2 slot 1. + +Note3: Multiple Sink ports can extract the same information for the +same bitSlots in the SoundWire frame, however multiple Source ports +shall be configured with different bitSlot configurations. This is the +same limitation as with I2S/PCM TDM usages. + SoundWire Stream Management flow ================================ -- cgit From daa3cfeb1971fd07b9c00ce452b3e3ff3298fa13 Mon Sep 17 00:00:00 2001 From: Akira Shimahara Date: Mon, 11 May 2020 22:36:31 +0200 Subject: w1_therm: adding sysfs-driver-w1_therm doc Adding a sysfs-driver-w1_therm documentation file in Documentation/ABI/testing. It describe the onlys sysfs entry of w1_therm module, based on Documentation/w1/slaves/w1_therm.rst Signed-off-by: Akira Shimahara Link: https://lore.kernel.org/r/20200511203631.410227-1-akira215corp@gmail.com Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-driver-w1_therm | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-w1_therm (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-w1_therm b/Documentation/ABI/testing/sysfs-driver-w1_therm new file mode 100644 index 000000000000..4a856631aaf9 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-w1_therm @@ -0,0 +1,17 @@ +What: /sys/bus/w1/devices/.../w1_slave +Date: May 2020 +Contact: Akira Shimahara +Description: + (RW) return the temperature in 1/1000 degC. + *read*: return 2 lines with the hexa output data sent on the + bus, return the CRC check and temperature in 1/1000 degC + *write* : + * '0' : save the 2 or 3 bytes to the device EEPROM + (i.e. TH, TL and config register) + * '9..12' : set the device resolution in RAM + (if supported) + * Anything else: do nothing + refer to Documentation/w1/slaves/w1_therm.rst for detailed + information. +Users: any user space application which wants to communicate with + w1_term device \ No newline at end of file -- cgit From b7bb6ca17a90f47c2fe2848531b5bbaf27a65ba7 Mon Sep 17 00:00:00 2001 From: Akira Shimahara Date: Mon, 11 May 2020 22:36:50 +0200 Subject: w1_therm: adding ext_power sysfs entry Adding ext_power sysfs entry (RO). Return the power status of the device: - 0: device parasite powered - 1: device externally powered - xx: xx is kernel error The power status of each device is check when the device is discover by the bus master, in 'w1_therm_add_slave(struct w1_slave *)'. The status is stored in the device structure w1_therm_family_data so that the driver always knows the power state of each device, which could be used later to determine the required strong pull up to apply on the line. The power status is re evaluate each time the sysfs ext_power read by a user. The hardware function 'read_powermode(struct w1_slave *sl)' act just as per device specifications, sending W1_READ_PSUPPLY command on the bus, and issue a read time slot, reading only one bit. A helper function 'bool bus_mutex_lock(struct mutex *lock)' is introduced. It try to aquire the bus mutex several times (W1_THERM_MAX_TRY), waiting W1_THERM_RETRY_DELAY between two attempt. Updating Documentation/ABI/testing/sysfs-driver-w1_therm accordingly. Signed-off-by: Akira Shimahara Link: https://lore.kernel.org/r/20200511203650.410439-1-akira215corp@gmail.com Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-driver-w1_therm | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-w1_therm b/Documentation/ABI/testing/sysfs-driver-w1_therm index 4a856631aaf9..99d73eeee3db 100644 --- a/Documentation/ABI/testing/sysfs-driver-w1_therm +++ b/Documentation/ABI/testing/sysfs-driver-w1_therm @@ -1,3 +1,15 @@ +What: /sys/bus/w1/devices/.../ext_power +Date: May 2020 +Contact: Akira Shimahara +Description: + (RO) return the power status by asking the device + * '0': device parasite powered + * '1': device externally powered + * '-xx': xx is kernel error when reading power status +Users: any user space application which wants to communicate with + w1_term device + + What: /sys/bus/w1/devices/.../w1_slave Date: May 2020 Contact: Akira Shimahara -- cgit From 308bdb94de0c1abe7eac5193f58638b8aeaddf4b Mon Sep 17 00:00:00 2001 From: Akira Shimahara Date: Mon, 11 May 2020 22:37:08 +0200 Subject: w1_therm: adding resolution sysfs entry Adding resolution sysfs entry (RW) to get or set the device resolution Write values are managed as follow: * '9..12': resolution to set in bit * Anything else: do nothing Read values are : * '9..12': device resolution in bit * '-xx': xx is kernel error when reading the resolution Only supported devices will show the sysfs entry. A new family has been created for DS18S20 devices as they do not implement resolution feature. The resolution of each device is check when the device is discover by the bus master, in 'w1_therm_add_slave(struct w1_slave *)'. The status is stored in the device structure w1_therm_family_data so that the driver always knows the resolution of each device, which could be used later to determine the required conversion duration (resolution dependent). The resolution is re evaluate each time a user read or write the sysfs entry. To avoid looping through the w1_therm_families at run time, the pointer 'specific_functions' is set up to the correct 'w1_therm_family_converter' when the slave is added (which mean when it is discovered by the master). This initialization is done by a helper function 'device_family(struct w1_slave *sl)', and a dedicated macro 'SLAVE_SPECIFIC_FUNC(sl)' allow the access to the specific function of the slave device. 'read_scratchpad' and 'write_scratchpad' are the hardware functions to access the device RAM, as per protocol specification. It cancel the former 'precision' functions, which was only set and never read (so not stored in the device struct). Updating Documentation/ABI/testing/sysfs-driver-w1_therm accordingly. Signed-off-by: Akira Shimahara Link: https://lore.kernel.org/r/20200511203708.410649-1-akira215corp@gmail.com Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-driver-w1_therm | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-w1_therm b/Documentation/ABI/testing/sysfs-driver-w1_therm index 99d73eeee3db..7ed95e9e0b64 100644 --- a/Documentation/ABI/testing/sysfs-driver-w1_therm +++ b/Documentation/ABI/testing/sysfs-driver-w1_therm @@ -10,6 +10,23 @@ Users: any user space application which wants to communicate with w1_term device +What: /sys/bus/w1/devices/.../resolution +Date: May 2020 +Contact: Akira Shimahara +Description: + (RW) get or set the device resolution (on supported devices, + if not, this entry is not present). Note that the resolution + will be changed only in device RAM, so it will be cleared when + power is lost. Trigger a 'save' to EEPROM command to keep + values after power-on. Read or write are : + * '9..12': device resolution in bit + or resolution to set in bit + * '-xx': xx is kernel error when reading the resolution + * Anything else: do nothing +Users: any user space application which wants to communicate with + w1_term device + + What: /sys/bus/w1/devices/.../w1_slave Date: May 2020 Contact: Akira Shimahara -- cgit From 45d457a4cf24455eefd076a01a3d86414fc2ff1e Mon Sep 17 00:00:00 2001 From: Akira Shimahara Date: Mon, 11 May 2020 22:37:25 +0200 Subject: w1_therm: adding eeprom sysfs entry The driver implement 2 hardware functions to access device RAM: * copy_scratchpad * recall_scratchpad They act according to device specifications. As EEPROM operations are not device dependent (all w1_therm can perform EEPROM read/write operation following the same protocol), it is removed from device families structures. Updating Documentation/ABI/testing/sysfs-driver-w1_therm accordingly. Signed-off-by: Akira Shimahara Link: https://lore.kernel.org/r/20200511203725.410844-1-akira215corp@gmail.com Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-driver-w1_therm | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-w1_therm b/Documentation/ABI/testing/sysfs-driver-w1_therm index 7ed95e9e0b64..8b7ee89ac6ce 100644 --- a/Documentation/ABI/testing/sysfs-driver-w1_therm +++ b/Documentation/ABI/testing/sysfs-driver-w1_therm @@ -1,3 +1,17 @@ +What: /sys/bus/w1/devices/.../eeprom +Date: May 2020 +Contact: Akira Shimahara +Description: + (WO) writing that file will either trigger a save of the + device data to its embedded EEPROM, either restore data + embedded in device EEPROM. Be aware that devices support + limited EEPROM writing cycles (typical 50k) + * 'save': save device RAM to EEPROM + * 'restore': restore EEPROM data in device RAM +Users: any user space application which wants to communicate with + w1_term device + + What: /sys/bus/w1/devices/.../ext_power Date: May 2020 Contact: Akira Shimahara -- cgit From 67b392f7b8edfa6f427fecd98722acab34c1c99f Mon Sep 17 00:00:00 2001 From: Akira Shimahara Date: Mon, 11 May 2020 22:37:42 +0200 Subject: w1_therm: optimizing temperature read timings Optimizing temperature reading by reducing waiting conversion time according to device resolution settings, as per device specification. This is device dependent as not all the devices supports resolution setting, so it has been added in device family structures. The process to read the temperature on the device has been adapted in a new function 'convert_t()', which replace the former 'read_therm()', is introduce to deal with this timing. Strong pull up is also applied during the required time, according to device power status needs and 'strong_pullup' module parameter. 'temperature_from_RAM()' function is introduced to get the correct temperature computation (device dependent) from device RAM data. An new sysfs entry has been added to ouptut only temperature. The old entry w1_slave has been kept for compatibility, without changing its output format. Updating Documentation/ABI/testing/sysfs-driver-w1_therm accordingly. Signed-off-by: Akira Shimahara Link: https://lore.kernel.org/r/20200511203742.411039-1-akira215corp@gmail.com Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-driver-w1_therm | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-w1_therm b/Documentation/ABI/testing/sysfs-driver-w1_therm index 8b7ee89ac6ce..6ffd3e3286a7 100644 --- a/Documentation/ABI/testing/sysfs-driver-w1_therm +++ b/Documentation/ABI/testing/sysfs-driver-w1_therm @@ -41,6 +41,18 @@ Users: any user space application which wants to communicate with w1_term device +What: /sys/bus/w1/devices/.../temperature +Date: May 2020 +Contact: Akira Shimahara +Description: + (RO) return the temperature in 1/1000 degC. + Note that the conversion duration depend on the resolution (if + device support this feature). It takes 94ms in 9bits + resolution, 750ms for 12bits. +Users: any user space application which wants to communicate with + w1_term device + + What: /sys/bus/w1/devices/.../w1_slave Date: May 2020 Contact: Akira Shimahara -- cgit From e2c94d6f572079511945e64537eb1218643f2e68 Mon Sep 17 00:00:00 2001 From: Akira Shimahara Date: Mon, 11 May 2020 22:38:01 +0200 Subject: w1_therm: adding alarm sysfs entry Adding device alarms settings by a dedicated sysfs entry alarms (RW): read or write TH and TL in the device RAM. Checking devices in alarm state could be performed using the master search command. As alarms temperature level are store in a 8 bit register on the device and are signed values, a safe cast shall be performed using the min and max temperature that device are able to measure. This is done by int_to_short inline function. A 'write_data' field is added in the device structure, to bind the correct writing function, as some devices may have 2 or 3 bytes RAM. Updating Documentation/ABI/testing/sysfs-driver-w1_therm accordingly. Signed-off-by: Akira Shimahara Link: https://lore.kernel.org/r/20200511203801.411253-1-akira215corp@gmail.com Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-driver-w1_therm | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-w1_therm b/Documentation/ABI/testing/sysfs-driver-w1_therm index 6ffd3e3286a7..f2895205a515 100644 --- a/Documentation/ABI/testing/sysfs-driver-w1_therm +++ b/Documentation/ABI/testing/sysfs-driver-w1_therm @@ -1,3 +1,19 @@ +What: /sys/bus/w1/devices/.../alarms +Date: May 2020 +Contact: Akira Shimahara +Description: + (RW) read or write TH and TL (Temperature High an Low) alarms. + Values shall be space separated and in the device range + (typical -55 degC to 125 degC), if not values will be trimmed + to device min/max capabilities. Values are integer as they are + stored in a 8bit register in the device. Lowest value is + automatically put to TL. Once set, alarms could be search at + master level, refer to Documentation/w1/w1_generic.rst for + detailed information +Users: any user space application which wants to communicate with + w1_term device + + What: /sys/bus/w1/devices/.../eeprom Date: May 2020 Contact: Akira Shimahara -- cgit From 57c76221d5af648c8355a55c09b050c5d8d38189 Mon Sep 17 00:00:00 2001 From: Akira Shimahara Date: Mon, 11 May 2020 22:38:20 +0200 Subject: w1_therm: adding bulk read support to trigger multiple conversion on bus Adding bulk read support: Sending a 'trigger' command in the dedicated sysfs entry of bus master device send a conversion command for all the slaves on the bus. The sysfs entry is added as soon as at least one device supporting this feature is detected on the bus. The behavior of the sysfs reading temperature on the device is as follow: * If no bulk read pending, trigger a conversion on the device, wait for the conversion to be done, read the temperature in device RAM * If a bulk read has been trigger, access directly the device RAM This behavior is the same on the 2 sysfs entries ('temperature' and 'w1_slave'). Reading the therm_bulk_read sysfs give the status of bulk operations: * '-1': conversion in progress on at least 1 sensor * '1': conversion complete but at least one sensor has not been read yet * '0': no bulk operation. Reading temperature on ecah device will trigger a conversion As not all devices support bulk read feature, it has been added in device family structure. The attribute is set at master level as soon as a supporting device is discover. It is removed when the last supported device leave the bus. The count of supported device is kept with the static counter bulk_read_device_counter. A strong pull up is apply on the line if at least one device required it. The duration of the pull up is the max time required by a device on the line, which depends on the resolution settings of each device. The strong pull up could be adjust with the a module parameter. Updating documentation in Documentation/ABI/testing/sysfs-driver-w1_therm and Documentation/w1/slaves/w1_therm.rst accordingly. Signed-off-by: Akira Shimahara Link: https://lore.kernel.org/r/20200511203820.411483-1-akira215corp@gmail.com Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-driver-w1_therm | 36 ++++++++++++++++-- Documentation/w1/slaves/w1_therm.rst | 50 ++++++++++++++++++++----- 2 files changed, 73 insertions(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-w1_therm b/Documentation/ABI/testing/sysfs-driver-w1_therm index f2895205a515..076659d506f2 100644 --- a/Documentation/ABI/testing/sysfs-driver-w1_therm +++ b/Documentation/ABI/testing/sysfs-driver-w1_therm @@ -62,9 +62,16 @@ Date: May 2020 Contact: Akira Shimahara Description: (RO) return the temperature in 1/1000 degC. - Note that the conversion duration depend on the resolution (if - device support this feature). It takes 94ms in 9bits - resolution, 750ms for 12bits. + * If a bulk read has been triggered, it will directly + return the temperature computed when the bulk read + occurred, if available. If not yet available, nothing + is returned (a debug kernel message is sent), you + should retry later on. + * If no bulk read has been triggered, it will trigger + a conversion and send the result. Note that the + conversion duration depend on the resolution (if + device support this feature). It takes 94ms in 9bits + resolution, 750ms for 12bits. Users: any user space application which wants to communicate with w1_term device @@ -85,4 +92,25 @@ Description: refer to Documentation/w1/slaves/w1_therm.rst for detailed information. Users: any user space application which wants to communicate with - w1_term device \ No newline at end of file + w1_term device + + +What: /sys/bus/w1/devices/w1_bus_masterXX/therm_bulk_read +Date: May 2020 +Contact: Akira Shimahara +Description: + (RW) trigger a bulk read conversion. read the status + *read*: + * '-1': conversion in progress on at least 1 sensor + * '1' : conversion complete but at least one sensor + value has not been read yet + * '0' : no bulk operation. Reading temperature will + trigger a conversion on each device + *write*: 'trigger': trigger a bulk read on all supporting + devices on the bus + Note that if a bulk read is sent but one sensor is not read + immediately, the next access to temperature on this device + will return the temperature measured at the time of issue + of the bulk read command (not the current temperature). +Users: any user space application which wants to communicate with + w1_term device diff --git a/Documentation/w1/slaves/w1_therm.rst b/Documentation/w1/slaves/w1_therm.rst index 90531c340a07..cc4edae17751 100644 --- a/Documentation/w1/slaves/w1_therm.rst +++ b/Documentation/w1/slaves/w1_therm.rst @@ -26,20 +26,31 @@ W1_THERM_DS1825 0x3B W1_THERM_DS28EA00 0x42 ==================== ==== -Support is provided through the sysfs w1_slave file. Each open and +Support is provided through the sysfs w1_slave file. Each open and read sequence will initiate a temperature conversion then provide two -lines of ASCII output. The first line contains the nine hex bytes +lines of ASCII output. The first line contains the nine hex bytes read along with a calculated crc value and YES or NO if it matched. -If the crc matched the returned values are retained. The second line +If the crc matched the returned values are retained. The second line displays the retained values along with a temperature in millidegrees Centigrade after t=. -Parasite powered devices are limited to one slave performing a -temperature conversion at a time. If none of the devices are parasite -powered it would be possible to convert all the devices at the same -time and then go back to read individual sensors. That isn't -currently supported. The driver also doesn't support reduced -precision (which would also reduce the conversion time) when reading values. +Alternatively, temperature can be read using temperature sysfs, it +return only temperature in millidegrees Centigrade. + +A bulk read of all devices on the bus could be done writing 'trigger' +in the therm_bulk_read sysfs entry at w1_bus_master level. This will +sent the convert command on all devices on the bus, and if parasite +powered devices are detected on the bus (and strong pullup is enable +in the module), it will drive the line high during the longer conversion +time required by parasited powered device on the line. Reading +therm_bulk_read will return 0 if no bulk conversion pending, +-1 if at least one sensor still in conversion, 1 if conversion is complete +but at least one sensor value has not been read yet. Result temperature is +then accessed by reading the temperature sysfs entry of each device, which +may return empty if conversion is still in progress. Note that if a bulk +read is sent but one sensor is not read immediately, the next access to +temperature on this device will return the temperature measured at the +time of issue of the bulk read command (not the current temperature). Writing a value between 9 and 12 to the sysfs w1_slave file will change the precision of the sensor for the next readings. This value is in (volatile) @@ -49,6 +60,27 @@ To store the current precision configuration into EEPROM, the value 0 has to be written to the sysfs w1_slave file. Since the EEPROM has a limited amount of writes (>50k), this command should be used wisely. +Alternatively, resolution can be set or read (value from 9 to 12) using the +dedicated resolution sysfs entry on each device. This sysfs entry is not +present for devices not supporting this feature. Driver will adjust the +correct conversion time for each device regarding to its resolution setting. +In particular, strong pullup will be applied if required during the conversion +duration. + +The write-only sysfs entry eeprom is an alternative for EEPROM operations: + * 'save': will save device RAM to EEPROM + * 'restore': will restore EEPROM data in device RAM. + +ext_power syfs entry allow tho check the power status of each device. + * '0': device parasite powered + * '1': device externally powered + +sysfs alarms allow read or write TH and TL (Temperature High an Low) alarms. +Values shall be space separated and in the device range (typical -55 degC +to 125 degC). Values are integer as they are store in a 8bit register in +the device. Lowest value is automatically put to TL.Once set, alarms could +be search at master level. + The module parameter strong_pullup can be set to 0 to disable the strong pullup, 1 to enable autodetection or 2 to force strong pullup. In case of autodetection, the driver will use the "READ POWER SUPPLY" -- cgit From 76cedc739d7aac461ae303ca0e8b3a81e6ae00aa Mon Sep 17 00:00:00 2001 From: Omer Shpigelman Date: Sun, 22 Mar 2020 21:12:51 +0200 Subject: habanalabs: remove stop-on-error flag from DMA Stop-on-error mode in DMA is useful as it stops the transaction immediately upon error e.g. page fault. But it may cause the next command submission to fail as is leaves the DMA in unstable state. Therefore we remove the stop-on-error configuration from the DMA. Stop-on-err is still available for debug. Signed-off-by: Omer Shpigelman Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay --- Documentation/ABI/testing/debugfs-driver-habanalabs | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/debugfs-driver-habanalabs b/Documentation/ABI/testing/debugfs-driver-habanalabs index a73601c5121e..67e04f2d7e1d 100644 --- a/Documentation/ABI/testing/debugfs-driver-habanalabs +++ b/Documentation/ABI/testing/debugfs-driver-habanalabs @@ -150,3 +150,10 @@ KernelVersion: 5.1 Contact: oded.gabbay@gmail.com Description: Displays a list with information about all the active virtual address mappings per ASID + +What: /sys/kernel/debug/habanalabs/hl/stop_on_err +Date: Mar 2020 +KernelVersion: 5.6 +Contact: oded.gabbay@gmail.com +Description: Sets the stop-on_error option for the device engines. Value of + "0" is for disable, otherwise enable. -- cgit From 5cab3ff2489ede5abffa6ad730708e087dc45a4d Mon Sep 17 00:00:00 2001 From: Pierre-Louis Bossart Date: Tue, 19 May 2020 01:43:18 +0800 Subject: soundwire: bus: rename sdw_bus_master_add/delete, add arguments In preparation for future extensions, rename functions to use sdw_bus_master prefix and add a parent and fwnode argument to sdw_bus_master_add to help with device registration in follow-up patches. No functionality change, just renames and additional arguments. The Intel code is currently unused, the two additional arguments are only needed for compilation. Signed-off-by: Pierre-Louis Bossart Signed-off-by: Bard Liao Acked-by: Jaroslav Kysela Link: https://lore.kernel.org/r/20200518174322.31561-2-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul --- Documentation/driver-api/soundwire/summary.rst | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/soundwire/summary.rst b/Documentation/driver-api/soundwire/summary.rst index 8193125a2bfb..01dcb954f6d7 100644 --- a/Documentation/driver-api/soundwire/summary.rst +++ b/Documentation/driver-api/soundwire/summary.rst @@ -101,10 +101,11 @@ Following is the Bus API to register the SoundWire Bus: .. code-block:: c - int sdw_add_bus_master(struct sdw_bus *bus) + int sdw_bus_master_add(struct sdw_bus *bus, + struct device *parent, + struct fwnode_handle) { - if (!bus->dev) - return -ENODEV; + sdw_master_device_add(bus, parent, fwnode); mutex_init(&bus->lock); INIT_LIST_HEAD(&bus->slaves); -- cgit From ca62433f53d1ff48a4f77ef96332122558f90ad3 Mon Sep 17 00:00:00 2001 From: Oded Gabbay Date: Sat, 9 May 2020 12:17:21 +0300 Subject: habanalabs: support clock gating enable/disable In Gaudi there is a feature of clock gating certain engines. Therefore, add this property to the device structure. In addition, due to a limitation of this feature, the driver needs to dynamically enable or disable this feature during run-time. Therefore, add ASIC interface functions to enable/disable this function from the common code. Moreover, this feature must be turned off when the user wishes to debug the ASIC by reading/writing registers and/or memory through the driver's debugfs. Therefore, add an option to enable/disable clock gating via the debugfs interface. Signed-off-by: Oded Gabbay --- Documentation/ABI/testing/debugfs-driver-habanalabs | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/debugfs-driver-habanalabs b/Documentation/ABI/testing/debugfs-driver-habanalabs index 67e04f2d7e1d..f6d9c2a8d528 100644 --- a/Documentation/ABI/testing/debugfs-driver-habanalabs +++ b/Documentation/ABI/testing/debugfs-driver-habanalabs @@ -8,6 +8,16 @@ Description: Sets the device address to be used for read or write through only when the IOMMU is disabled. The acceptable value is a string that starts with "0x" +What: /sys/kernel/debug/habanalabs/hl/clk_gate +Date: May 2020 +KernelVersion: 5.8 +Contact: oded.gabbay@gmail.com +Description: Allow the root user to disable/enable in runtime the clock + gating mechanism in Gaudi. Due to how Gaudi is built, the + clock gating needs to be disabled in order to access the + registers of the TPC and MME engines. This is sometimes needed + during debug by the user and hence the user needs this option + What: /sys/kernel/debug/habanalabs/hl/command_buffers Date: Jan 2019 KernelVersion: 5.1 -- cgit From bcaf415204e231be000d76c07f6dde22edabea6a Mon Sep 17 00:00:00 2001 From: Oded Gabbay Date: Mon, 11 May 2020 10:41:37 +0300 Subject: habanalabs: add hwmgr module for gaudi The hwmgr module is responsible for messages sent to GAUDI F/W that are not common to all habanalabs ASICs. In GAUDI, we provide the user a simplified mode of controlling the ASIC clock frequency. Instead of three different clocks, we present a single clock property that the user can configure via sysfs. Signed-off-by: Oded Gabbay --- Documentation/ABI/testing/sysfs-driver-habanalabs | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-habanalabs b/Documentation/ABI/testing/sysfs-driver-habanalabs index 782df74042ed..1a14bf9b22ba 100644 --- a/Documentation/ABI/testing/sysfs-driver-habanalabs +++ b/Documentation/ABI/testing/sysfs-driver-habanalabs @@ -10,6 +10,23 @@ KernelVersion: 5.1 Contact: oded.gabbay@gmail.com Description: Version of the application running on the device's CPU +What: /sys/class/habanalabs/hl/clk_max_freq_mhz +Date: Jun 2019 +KernelVersion: not yet upstreamed +Contact: oded.gabbay@gmail.com +Description: Allows the user to set the maximum clock frequency, in MHz. + The device clock might be set to lower value than the maximum. + The user should read the clk_cur_freq_mhz to see the actual + frequency value of the device clock. This property is valid + only for the Gaudi ASIC family + +What: /sys/class/habanalabs/hl/clk_cur_freq_mhz +Date: Jun 2019 +KernelVersion: not yet upstreamed +Contact: oded.gabbay@gmail.com +Description: Displays the current frequency, in MHz, of the device clock. + This property is valid only for the Gaudi ASIC family + What: /sys/class/habanalabs/hl/cpld_ver Date: Jan 2019 KernelVersion: 5.1 -- cgit From 5153e57bf8b371d75c35fe37928bbd88a1b4bbe8 Mon Sep 17 00:00:00 2001 From: Mike Leach Date: Mon, 18 May 2020 12:02:25 -0600 Subject: coresight: docs: Add information about the topology representations Update the CoreSight documents to describe the new connections directory and the links between CoreSight devices in this directory. Signed-off-by: Mike Leach Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200518180242.7916-7-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman --- Documentation/trace/coresight/coresight-ect.rst | 5 +- Documentation/trace/coresight/coresight.rst | 85 +++++++++++++++++++++++++ 2 files changed, 89 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/trace/coresight/coresight-ect.rst b/Documentation/trace/coresight/coresight-ect.rst index ecc1e57012ef..50a5623d5d4f 100644 --- a/Documentation/trace/coresight/coresight-ect.rst +++ b/Documentation/trace/coresight/coresight-ect.rst @@ -72,7 +72,7 @@ capable of generating or using trigger signals.:: >$ ls /sys/bus/coresight/devices/etm0/cti_cpu0 channels ctmid enable nr_trigger_cons mgmt power powered regs - subsystem triggers0 triggers1 uevent + connections subsystem triggers0 triggers1 uevent *Key file items are:-* * ``enable``: enables/disables the CTI. Read to determine current state. @@ -88,6 +88,9 @@ capable of generating or using trigger signals.:: * ``channels``: Contains the channel API - CTI main programming interface. * ``regs``: Gives access to the raw programmable CTI regs. * ``mgmt``: the standard CoreSight management registers. + * ``connections``: Links to connected *CoreSight* devices. The number of + links can be 0 to ``nr_trigger_cons``. Actual number given by ``nr_links`` + in this directory. triggers directories diff --git a/Documentation/trace/coresight/coresight.rst b/Documentation/trace/coresight/coresight.rst index 108600ee1e12..0b73acb44efa 100644 --- a/Documentation/trace/coresight/coresight.rst +++ b/Documentation/trace/coresight/coresight.rst @@ -241,6 +241,91 @@ to the newer scheme, to give a confirmation that what you see on your system is not unexpected. One must use the "names" as they appear on the system under specified locations. +Topology Representation +----------------------- + +Each CoreSight component has a ``connections`` directory which will contain +links to other CoreSight components. This allows the user to explore the trace +topology and for larger systems, determine the most appropriate sink for a +given source. The connection information can also be used to establish +which CTI devices are connected to a given component. This directory contains a +``nr_links`` attribute detailing the number of links in the directory. + +For an ETM source, in this case ``etm0`` on a Juno platform, a typical +arrangement will be:: + + linaro-developer:~# ls - l /sys/bus/coresight/devices/etm0/connections + cti_cpu0 -> ../../../23020000.cti/cti_cpu0 + nr_links + out:0 -> ../../../230c0000.funnel/funnel2 + +Following the out port to ``funnel2``:: + + linaro-developer:~# ls -l /sys/bus/coresight/devices/funnel2/connections + in:0 -> ../../../23040000.etm/etm0 + in:1 -> ../../../23140000.etm/etm3 + in:2 -> ../../../23240000.etm/etm4 + in:3 -> ../../../23340000.etm/etm5 + nr_links + out:0 -> ../../../20040000.funnel/funnel0 + +And again to ``funnel0``:: + + linaro-developer:~# ls -l /sys/bus/coresight/devices/funnel0/connections + in:0 -> ../../../220c0000.funnel/funnel1 + in:1 -> ../../../230c0000.funnel/funnel2 + nr_links + out:0 -> ../../../20010000.etf/tmc_etf0 + +Finding the first sink ``tmc_etf0``. This can be used to collect data +as a sink, or as a link to propagate further along the chain:: + + linaro-developer:~# ls -l /sys/bus/coresight/devices/tmc_etf0/connections + cti_sys0 -> ../../../20020000.cti/cti_sys0 + in:0 -> ../../../20040000.funnel/funnel0 + nr_links + out:0 -> ../../../20150000.funnel/funnel4 + +via ``funnel4``:: + + linaro-developer:~# ls -l /sys/bus/coresight/devices/funnel4/connections + in:0 -> ../../../20010000.etf/tmc_etf0 + in:1 -> ../../../20140000.etf/tmc_etf1 + nr_links + out:0 -> ../../../20120000.replicator/replicator0 + +and a ``replicator0``:: + + linaro-developer:~# ls -l /sys/bus/coresight/devices/replicator0/connections + in:0 -> ../../../20150000.funnel/funnel4 + nr_links + out:0 -> ../../../20030000.tpiu/tpiu0 + out:1 -> ../../../20070000.etr/tmc_etr0 + +Arriving at the final sink in the chain, ``tmc_etr0``:: + + linaro-developer:~# ls -l /sys/bus/coresight/devices/tmc_etr0/connections + cti_sys0 -> ../../../20020000.cti/cti_sys0 + in:0 -> ../../../20120000.replicator/replicator0 + nr_links + +As described below, when using sysfs it is sufficient to enable a sink and +a source for successful trace. The framework will correctly enable all +intermediate links as required. + +Note: ``cti_sys0`` appears in two of the connections lists above. +CTIs can connect to multiple devices and are arranged in a star topology +via the CTM. See (:doc:`coresight-ect`) [#fourth]_ for further details. +Looking at this device we see 4 connections:: + + linaro-developer:~# ls -l /sys/bus/coresight/devices/cti_sys0/connections + nr_links + stm0 -> ../../../20100000.stm/stm0 + tmc_etf0 -> ../../../20010000.etf/tmc_etf0 + tmc_etr0 -> ../../../20070000.etr/tmc_etr0 + tpiu0 -> ../../../20030000.tpiu/tpiu0 + + How to use the tracer modules ----------------------------- -- cgit From 7f06a1c989e565eaa80c0a2082d274e8bd7de570 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 18 May 2020 12:02:26 -0600 Subject: docs: trace: coresight-ect.rst: Fix a build warning Sphinx wants a line after "..", as otherwise it complains with: Documentation/trace/coresight/coresight-ect.rst:2: WARNING: Explicit markup ends without a blank line; unexpected unindent. Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200518180242.7916-8-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman --- Documentation/trace/coresight/coresight-ect.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/trace/coresight/coresight-ect.rst b/Documentation/trace/coresight/coresight-ect.rst index 50a5623d5d4f..a68732c5c6d6 100644 --- a/Documentation/trace/coresight/coresight-ect.rst +++ b/Documentation/trace/coresight/coresight-ect.rst @@ -1,4 +1,5 @@ .. SPDX-License-Identifier: GPL-2.0 + ============================================= CoreSight Embedded Cross Trigger (CTI & CTM). ============================================= -- cgit From c5778ca49a19420c67dbeff0744a3b3b75ef4e1a Mon Sep 17 00:00:00 2001 From: Pierre-Louis Bossart Date: Tue, 19 May 2020 04:35:50 +0800 Subject: soundwire: master: add sysfs support Add the master properties as attributes. The description is directly derived from the MIPI DisCo specification. Credits: this patch is based on an earlier internal contribution by Vinod Koul, Sanyog Kale, Shreyas Nc and Hardik Shah. Signed-off-by: Pierre-Louis Bossart Signed-off-by: Bard Liao Link: https://lore.kernel.org/r/20200518203551.2053-3-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul --- .../ABI/testing/sysfs-bus-soundwire-master | 23 ++++++++++++++++++++++ 1 file changed, 23 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-soundwire-master (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-soundwire-master b/Documentation/ABI/testing/sysfs-bus-soundwire-master new file mode 100644 index 000000000000..46ef038d8722 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-soundwire-master @@ -0,0 +1,23 @@ +What: /sys/bus/soundwire/devices/sdw-master-N/revision + /sys/bus/soundwire/devices/sdw-master-N/clk_stop_modes + /sys/bus/soundwire/devices/sdw-master-N/clk_freq + /sys/bus/soundwire/devices/sdw-master-N/clk_gears + /sys/bus/soundwire/devices/sdw-master-N/default_col + /sys/bus/soundwire/devices/sdw-master-N/default_frame_rate + /sys/bus/soundwire/devices/sdw-master-N/default_row + /sys/bus/soundwire/devices/sdw-master-N/dynamic_shape + /sys/bus/soundwire/devices/sdw-master-N/err_threshold + /sys/bus/soundwire/devices/sdw-master-N/max_clk_freq + +Date: April 2020 + +Contact: Pierre-Louis Bossart + Bard Liao + Vinod Koul + +Description: SoundWire Master-N DisCo properties. + These properties are defined by MIPI DisCo Specification + for SoundWire. They define various properties of the Master + and are used by the bus to configure the Master. clk_stop_modes + is a bitmask for simplifications and combines the + clock-stop-mode0 and clock-stop-mode1 properties. -- cgit From bcac59029955ae57d3c660a0a1d6d4c7ae78fb49 Mon Sep 17 00:00:00 2001 From: Pierre-Louis Bossart Date: Tue, 19 May 2020 04:35:51 +0800 Subject: soundwire: add Slave sysfs support Expose MIPI DisCo Slave properties in sysfs. For Slave properties and Data Port 0, the attributes are managed with simple devm_ support. A Slave Device may have more than one Data Port (DPN), and each Data Port can be sink or source. The attributes are created dynamically using pre-canned macros, but still use devm_ with a name attribute group to avoid creating kobjects - as requested by GregKH. In the _show function, we use container_of() to retrieve port number and direction required to extract the information. Audio modes are not supported for now. Depending on the discussions the SoundWire Device Class, we may add it later as is or follow the new specification. Signed-off-by: Pierre-Louis Bossart Signed-off-by: Bard Liao Reviewed-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20200518203551.2053-4-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul --- .../ABI/testing/sysfs-bus-soundwire-slave | 91 ++++++++++++++++++++++ 1 file changed, 91 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-soundwire-slave (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-soundwire-slave b/Documentation/ABI/testing/sysfs-bus-soundwire-slave new file mode 100644 index 000000000000..db4c9511d1aa --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-soundwire-slave @@ -0,0 +1,91 @@ +What: /sys/bus/soundwire/devices/sdw:.../dev-properties/mipi_revision + /sys/bus/soundwire/devices/sdw:.../dev-properties/wake_capable + /sys/bus/soundwire/devices/sdw:.../dev-properties/test_mode_capable + /sys/bus/soundwire/devices/sdw:.../dev-properties/clk_stop_mode1 + /sys/bus/soundwire/devices/sdw:.../dev-properties/simple_clk_stop_capable + /sys/bus/soundwire/devices/sdw:.../dev-properties/clk_stop_timeout + /sys/bus/soundwire/devices/sdw:.../dev-properties/ch_prep_timeout + /sys/bus/soundwire/devices/sdw:.../dev-properties/reset_behave + /sys/bus/soundwire/devices/sdw:.../dev-properties/high_PHY_capable + /sys/bus/soundwire/devices/sdw:.../dev-properties/paging_support + /sys/bus/soundwire/devices/sdw:.../dev-properties/bank_delay_support + /sys/bus/soundwire/devices/sdw:.../dev-properties/p15_behave + /sys/bus/soundwire/devices/sdw:.../dev-properties/master_count + /sys/bus/soundwire/devices/sdw:.../dev-properties/source_ports + /sys/bus/soundwire/devices/sdw:.../dev-properties/sink_ports + +Date: May 2020 + +Contact: Pierre-Louis Bossart + Bard Liao + Vinod Koul + +Description: SoundWire Slave DisCo properties. + These properties are defined by MIPI DisCo Specification + for SoundWire. They define various properties of the + SoundWire Slave and are used by the bus to configure + the Slave + + +What: /sys/bus/soundwire/devices/sdw:.../dp0/max_word + /sys/bus/soundwire/devices/sdw:.../dp0/min_word + /sys/bus/soundwire/devices/sdw:.../dp0/words + /sys/bus/soundwire/devices/sdw:.../dp0/BRA_flow_controlled + /sys/bus/soundwire/devices/sdw:.../dp0/simple_ch_prep_sm + /sys/bus/soundwire/devices/sdw:.../dp0/imp_def_interrupts + +Date: May 2020 + +Contact: Pierre-Louis Bossart + Bard Liao + Vinod Koul + +Description: SoundWire Slave Data Port-0 DisCo properties. + These properties are defined by MIPI DisCo Specification + for the SoundWire. They define various properties of the + Data port 0 are used by the bus to configure the Data Port 0. + + +What: /sys/bus/soundwire/devices/sdw:.../dpN_src/max_word + /sys/bus/soundwire/devices/sdw:.../dpN_src/min_word + /sys/bus/soundwire/devices/sdw:.../dpN_src/words + /sys/bus/soundwire/devices/sdw:.../dpN_src/type + /sys/bus/soundwire/devices/sdw:.../dpN_src/max_grouping + /sys/bus/soundwire/devices/sdw:.../dpN_src/simple_ch_prep_sm + /sys/bus/soundwire/devices/sdw:.../dpN_src/ch_prep_timeout + /sys/bus/soundwire/devices/sdw:.../dpN_src/imp_def_interrupts + /sys/bus/soundwire/devices/sdw:.../dpN_src/min_ch + /sys/bus/soundwire/devices/sdw:.../dpN_src/max_ch + /sys/bus/soundwire/devices/sdw:.../dpN_src/channels + /sys/bus/soundwire/devices/sdw:.../dpN_src/ch_combinations + /sys/bus/soundwire/devices/sdw:.../dpN_src/max_async_buffer + /sys/bus/soundwire/devices/sdw:.../dpN_src/block_pack_mode + /sys/bus/soundwire/devices/sdw:.../dpN_src/port_encoding + + /sys/bus/soundwire/devices/sdw:.../dpN_sink/max_word + /sys/bus/soundwire/devices/sdw:.../dpN_sink/min_word + /sys/bus/soundwire/devices/sdw:.../dpN_sink/words + /sys/bus/soundwire/devices/sdw:.../dpN_sink/type + /sys/bus/soundwire/devices/sdw:.../dpN_sink/max_grouping + /sys/bus/soundwire/devices/sdw:.../dpN_sink/simple_ch_prep_sm + /sys/bus/soundwire/devices/sdw:.../dpN_sink/ch_prep_timeout + /sys/bus/soundwire/devices/sdw:.../dpN_sink/imp_def_interrupts + /sys/bus/soundwire/devices/sdw:.../dpN_sink/min_ch + /sys/bus/soundwire/devices/sdw:.../dpN_sink/max_ch + /sys/bus/soundwire/devices/sdw:.../dpN_sink/channels + /sys/bus/soundwire/devices/sdw:.../dpN_sink/ch_combinations + /sys/bus/soundwire/devices/sdw:.../dpN_sink/max_async_buffer + /sys/bus/soundwire/devices/sdw:.../dpN_sink/block_pack_mode + /sys/bus/soundwire/devices/sdw:.../dpN_sink/port_encoding + +Date: May 2020 + +Contact: Pierre-Louis Bossart + Bard Liao + Vinod Koul + +Description: SoundWire Slave Data Source/Sink Port-N DisCo properties. + These properties are defined by MIPI DisCo Specification + for SoundWire. They define various properties of the + Source/Sink Data port N and are used by the bus to configure + the Data Port N. -- cgit