From 7c1f6281549bda39ab32f65eb93bfcf2aa75fe94 Mon Sep 17 00:00:00 2001 From: Joel Stanley Date: Mon, 21 Sep 2020 18:46:42 +0930 Subject: dt-bindings: aspeed: Add silicon id node to SCU Different ASPEED families have various unique hardware silicon identifiers within the SoC. Reviewed-by: Andrew Jeffery Link: https://lore.kernel.org/r/20200921091644.133107-2-joel@jms.id.au Signed-off-by: Joel Stanley --- .../devicetree/bindings/mfd/aspeed-scu.txt | 26 ++++++++++++++++++++++ 1 file changed, 26 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/aspeed-scu.txt b/Documentation/devicetree/bindings/mfd/aspeed-scu.txt index 4d92c0bb6687..857ee33f7329 100644 --- a/Documentation/devicetree/bindings/mfd/aspeed-scu.txt +++ b/Documentation/devicetree/bindings/mfd/aspeed-scu.txt @@ -20,3 +20,29 @@ syscon: syscon@1e6e2000 { #clock-cells = <1>; #reset-cells = <1>; }; + +Silicon ID +----------------- + +Families have unique hardware silicon identifiers within the SoC. + +Required properties: + + - compatible: "aspeed,silicon-id" or: + "aspeed,ast2400-silicon-id" or + "aspeed,ast2500-silicon-id" or + "aspeed,ast2600-silicon-id" + + - reg: offset and length of the silicon id information + optionally, a second offset and length describes the unique chip id + + The reg should be the unique silicon id register, and + not backwards compatible one in eg. the 2600. + +Example: + + +silicon-id@7c { + compatible = "aspeed,ast2500-silicon-id", "aspeed,silicon-id"; + reg = <0x7c 0x4 0x150 0x8>; +}; -- cgit v1.2.3 From e8589796a6d1255f0f6cbbe9706f1f70362ba0c8 Mon Sep 17 00:00:00 2001 From: Brad Bishop Date: Wed, 25 Sep 2019 08:56:01 -0400 Subject: dt-bindings: aspeed-lpc: Add AST2600 compatible strings The AST2600 datasheet indicates the same register set behind the LPC controller address space. Signed-off-by: Brad Bishop Reviewed-by: Andrew Jeffery Link: https://lore.kernel.org/r/20190925125610.12096-2-bradleyb@fuzziesquirrel.com Signed-off-by: Joel Stanley --- Documentation/devicetree/bindings/mfd/aspeed-lpc.txt | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt index a92acf1dd491..d0a38ba8b9ce 100644 --- a/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt +++ b/Documentation/devicetree/bindings/mfd/aspeed-lpc.txt @@ -46,6 +46,7 @@ Required properties - compatible: One of: "aspeed,ast2400-lpc", "simple-mfd" "aspeed,ast2500-lpc", "simple-mfd" + "aspeed,ast2600-lpc", "simple-mfd" - reg: contains the physical address and length values of the Aspeed LPC memory region. @@ -64,6 +65,7 @@ BMC Node - compatible: One of: "aspeed,ast2400-lpc-bmc" "aspeed,ast2500-lpc-bmc" + "aspeed,ast2600-lpc-bmc" - reg: contains the physical address and length values of the H8S/2168-compatible LPC controller memory region @@ -74,6 +76,7 @@ Host Node - compatible: One of: "aspeed,ast2400-lpc-host", "simple-mfd", "syscon" "aspeed,ast2500-lpc-host", "simple-mfd", "syscon" + "aspeed,ast2600-lpc-host", "simple-mfd", "syscon" - reg: contains the address and length values of the host-related register space for the Aspeed LPC controller @@ -128,6 +131,7 @@ Required properties: - compatible: One of: "aspeed,ast2400-lpc-ctrl"; "aspeed,ast2500-lpc-ctrl"; + "aspeed,ast2600-lpc-ctrl"; - reg: contains offset/length values of the host interface controller memory regions @@ -168,6 +172,7 @@ Required properties: - compatible: One of: "aspeed,ast2400-lhc"; "aspeed,ast2500-lhc"; + "aspeed,ast2600-lhc"; - reg: contains offset/length values of the LHC memory regions. In the AST2400 and AST2500 there are two regions. @@ -187,7 +192,8 @@ state of the LPC bus. Some systems may chose to modify this configuration. Required properties: - - compatible: "aspeed,ast2500-lpc-reset" or + - compatible: "aspeed,ast2600-lpc-reset" or + "aspeed,ast2500-lpc-reset" "aspeed,ast2400-lpc-reset" - reg: offset and length of the IP in the LHC memory region - #reset-controller indicates the number of reset cells expected -- cgit v1.2.3 From d693def4fd1c23f1ca5aed1afb9993b3a2069ad2 Mon Sep 17 00:00:00 2001 From: Thomas Zimmermann Date: Wed, 23 Sep 2020 12:21:59 +0200 Subject: drm: Remove obsolete GEM and PRIME callbacks from struct drm_driver MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Several GEM and PRIME callbacks have been deprecated in favor of per-instance GEM object functions. Remove the callbacks as they are now unused. The only exception is .gem_prime_mmap, which is still in use by several drivers. What is also gone is gem_vm_ops in struct drm_driver. All drivers now use struct drm_gem_object_funcs.vm_ops instead. While at it, the patch also improves error handling around calls to .free and .get_sg_table callbacks. v3: * restore default call to drm_gem_prime_export() in drm_gem_prime_handle_to_fd() * return -ENOSYS if get_sg_table is not set * drop all checks for obj->funcs * clean up TODO list and documentation v2: * update related TODO item (Sam) Signed-off-by: Thomas Zimmermann Acked-by: Daniel Vetter Acked-by: Christian König Link: https://patchwork.freedesktop.org/patch/msgid/20200923102159.24084-23-tzimmermann@suse.de --- Documentation/gpu/drm-mm.rst | 4 ++-- Documentation/gpu/todo.rst | 9 +++------ 2 files changed, 5 insertions(+), 8 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index 9abee1589c1e..21be6deadc12 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -182,11 +182,11 @@ acquired and release by calling drm_gem_object_get() and drm_gem_object_put() respectively. When the last reference to a GEM object is released the GEM core calls -the :c:type:`struct drm_driver ` gem_free_object_unlocked +the :c:type:`struct drm_gem_object_funcs ` free operation. That operation is mandatory for GEM-enabled drivers and must free the GEM object and all associated resources. -void (\*gem_free_object) (struct drm_gem_object \*obj); Drivers are +void (\*free) (struct drm_gem_object \*obj); Drivers are responsible for freeing all GEM object resources. This includes the resources created by the GEM core, which need to be released with drm_gem_object_release(). diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index b0ea17da8ff6..3751ac976c3e 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -149,7 +149,7 @@ have to keep track of that lock and either call ``unreference`` or ``unreference_locked`` depending upon context. Core GEM doesn't have a need for ``struct_mutex`` any more since kernel 4.8, -and there's a ``gem_free_object_unlocked`` callback for any drivers which are +and there's a GEM object ``free`` callback for any drivers which are entirely ``struct_mutex`` free. For drivers that need ``struct_mutex`` it should be replaced with a driver- @@ -289,11 +289,8 @@ struct drm_gem_object_funcs --------------------------- GEM objects can now have a function table instead of having the callbacks on the -DRM driver struct. This is now the preferred way and drivers can be moved over. - -We also need a 2nd version of the CMA define that doesn't require the -vmapping to be present (different hook for prime importing). Plus this needs to -be rolled out to all drivers using their own implementations, too. +DRM driver struct. This is now the preferred way. Callbacks in drivers have been +converted, except for struct drm_driver.gem_prime_mmap. Level: Intermediate -- cgit v1.2.3 From 6914c9685e0a2376c128a3519b5b5e0619bb5f2d Mon Sep 17 00:00:00 2001 From: Karthik B S Date: Mon, 21 Sep 2020 16:32:09 +0530 Subject: Documentation/gpu: Add asynchronous flip documentation for i915 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Add the details of the implementation of asynchronous flips for i915. v7: -Rebased. v8: -Rebased. v9: -Rebased. v10: Move all documentation changes to this patch. (Ville) Signed-off-by: Karthik B S Signed-off-by: Vandita Kulkarni Reviewed-by: Ville Syrjälä Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20200921110210.21182-8-karthik.b.s@intel.com --- Documentation/gpu/i915.rst | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 33cc6ddf8f64..84ead508f7ad 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -118,6 +118,12 @@ Atomic Plane Helpers .. kernel-doc:: drivers/gpu/drm/i915/display/intel_atomic_plane.c :internal: +Asynchronous Page Flip +---------------------- + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_display.c + :doc: asynchronous flip implementation + Output Probing -------------- -- cgit v1.2.3 From ccc22d41bd9acec58cdc7c3b012e1887aba40af4 Mon Sep 17 00:00:00 2001 From: Thomas Zimmermann Date: Fri, 25 Sep 2020 13:56:01 +0200 Subject: dma-buf: Document struct dma_buf_map MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This patch adds struct dma_buf_map and its helpers to the documentation. A short tutorial is included. v3: * update documentation in a separate patch * expand docs (Daniel) * carry-over acks from patch 1 Signed-off-by: Thomas Zimmermann Reviewed-by: Christian König Reviewed-by: Daniel Vetter Acked-by: Sumit Semwal Link: https://patchwork.freedesktop.org/patch/msgid/20200925115601.23955-5-tzimmermann@suse.de --- Documentation/driver-api/dma-buf.rst | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 13ea0cc0a3fa..6dbcc4714b0b 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -115,6 +115,15 @@ Kernel Functions and Structures Reference .. kernel-doc:: include/linux/dma-buf.h :internal: +Buffer Mapping Helpers +~~~~~~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: include/linux/dma-buf-map.h + :doc: overview + +.. kernel-doc:: include/linux/dma-buf-map.h + :internal: + Reservation Objects ------------------- -- cgit v1.2.3 From cbdbdd8ab22b4bf2571f313ea627cfc3a04cb02f Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Tue, 29 Sep 2020 17:03:33 +0200 Subject: drm: update todo.rst - debugfs cleanup has moved forward thanks to the cleanup Wambui has done Acked-by: Melissa Wen Reviewed-by: Greg Kroah-Hartman Cc: Wambui Karuga Cc: Greg Kroah-Hartman Cc: Melissa Wen Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20200929150333.3441576-1-daniel.vetter@ffwll.ch --- Documentation/gpu/todo.rst | 3 --- 1 file changed, 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 3751ac976c3e..700637e25ecd 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -515,9 +515,6 @@ There's a bunch of issues with it: this (together with the drm_minor->drm_device move) would allow us to remove debugfs_init. -- Drop the return code and error checking from all debugfs functions. Greg KH is - working on this already. - Contact: Daniel Vetter Level: Intermediate -- cgit v1.2.3 From 6468f234d32d1f2bafc42c3b655108683089b1f8 Mon Sep 17 00:00:00 2001 From: Tomi Valkeinen Date: Wed, 16 Sep 2020 16:10:08 +0300 Subject: dt-bindings: display: ti,am65x-dss: add missing properties to dt-schema Add assigned-clocks, assigned-clock-parents and dma-coherent optional properties. Signed-off-by: Tomi Valkeinen Reviewed-by: Rob Herring Link: https://patchwork.freedesktop.org/patch/msgid/20200916131009.221252-2-tomi.valkeinen@ti.com --- .../devicetree/bindings/display/ti/ti,am65x-dss.yaml | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml index 4f9185462ed3..4dc30738ee57 100644 --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml @@ -55,6 +55,14 @@ properties: - const: vp1 - const: vp2 + assigned-clocks: + minItems: 1 + maxItems: 3 + + assigned-clock-parents: + minItems: 1 + maxItems: 3 + interrupts: maxItems: 1 @@ -62,6 +70,9 @@ properties: maxItems: 1 description: phandle to the associated power domain + dma-coherent: + type: boolean + ports: type: object description: -- cgit v1.2.3 From a10563c89a721a39cd30dac2d283679ef46e4cad Mon Sep 17 00:00:00 2001 From: Tomi Valkeinen Date: Wed, 16 Sep 2020 16:10:09 +0300 Subject: dt-bindings: display: ti,j721e-dss: add missing properties to dt-schema Add assigned-clocks, assigned-clock-parents and dma-coherent optional properties. Signed-off-by: Tomi Valkeinen Reviewed-by: Rob Herring Link: https://patchwork.freedesktop.org/patch/msgid/20200916131009.221252-3-tomi.valkeinen@ti.com --- .../devicetree/bindings/display/ti/ti,j721e-dss.yaml | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml index 173730d56334..c9a947d55fa4 100644 --- a/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml +++ b/Documentation/devicetree/bindings/display/ti/ti,j721e-dss.yaml @@ -77,6 +77,14 @@ properties: - const: vp3 - const: vp4 + assigned-clocks: + minItems: 1 + maxItems: 5 + + assigned-clock-parents: + minItems: 1 + maxItems: 5 + interrupts: items: - description: common_m DSS Master common @@ -95,6 +103,9 @@ properties: maxItems: 1 description: phandle to the associated power domain + dma-coherent: + type: boolean + ports: type: object description: -- cgit v1.2.3 From 5a3884320a5753395e7167a74f4be257d490a578 Mon Sep 17 00:00:00 2001 From: Melissa Wen Date: Tue, 6 Oct 2020 19:30:06 -0300 Subject: drm/vkms: update todo Drop issues already resolved in vkms: - CRC API Improvements to [1] add igt test to check extreme alpha values and [2] alpha blending; - [3] prime buffer sharing; - [4] writeback support; On the other hand, we also found or thought about other improvements since the last update of this document: - better support for IGT tests - improvements to writeback support - syzbot report Finally, we reorder items by the assumed complexity. [1] https://patchwork.freedesktop.org/series/55944/ [2] https://patchwork.freedesktop.org/series/80823/ [3] https://patchwork.freedesktop.org/series/63212/ [4] https://patchwork.freedesktop.org/series/81177/ v2: - Link to syzbot dashboard Cc: Daniel Vetter Cc: Rodrigo Siqueira Cc: Haneen Mohammed Signed-off-by: Melissa Wen Acked-by: Daniel Vetter Reviewed-by: Rodrigo Siqueira Link: https://patchwork.freedesktop.org/patch/msgid/20201006223006.gu55pjtuaigkh6il@smtp.gmail.com --- Documentation/gpu/vkms.rst | 99 +++++++++++++++++++++++++--------------------- 1 file changed, 53 insertions(+), 46 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst index 61586fc861bb..13bab1d93bb3 100644 --- a/Documentation/gpu/vkms.rst +++ b/Documentation/gpu/vkms.rst @@ -10,36 +10,24 @@ TODO ==== -CRC API Improvements --------------------- - -- Optimize CRC computation ``compute_crc()`` and plane blending ``blend()`` - -- Use the alpha value to blend vaddr_src with vaddr_dst instead of - overwriting it in ``blend()``. - -- Add igt test to check cleared alpha value for XRGB plane format. - -- Add igt test to check extreme alpha values i.e. fully opaque and fully - transparent (intermediate values are affected by hw-specific rounding modes). - -Runtime Configuration ---------------------- - -We want to be able to reconfigure vkms instance without having to reload the -module. Use/Test-cases: - -- Hotplug/hotremove connectors on the fly (to be able to test DP MST handling of - compositors). +If you want to do any of the items listed below, please share your interest +with VKMS maintainers. -- Configure planes/crtcs/connectors (we'd need some code to have more than 1 of - them first). +IGT better support +------------------ -- Change output configuration: Plug/unplug screens, change EDID, allow changing - the refresh rate. +- Investigate: (1) test cases on kms_plane that are failing due to timeout on + capturing CRC; (2) when running kms_flip test cases in sequence, some + successful individual test cases are failing randomly. -The currently proposed solution is to expose vkms configuration through -configfs. All existing module options should be supported through configfs too. +- VKMS already has support for vblanks simulated via hrtimers, which can be + tested with kms_flip test; in some way, we can say that VKMS already mimics + the real hardware vblank. However, we also have virtual hardware that does + not support vblank interrupt and completes page_flip events right away; in + this case, compositor developers may end up creating a busy loop on virtual + hardware. It would be useful to support Virtual Hardware behavior in VKMS + because this can help compositor developers to test their features in + multiple scenarios. Add Plane Features ------------------ @@ -55,34 +43,50 @@ There's lots of plane features we could add support for: - Additional buffer formats, especially YUV formats for video like NV12. Low/high bpp RGB formats would also be interesting. -- Async updates (currently only possible on cursor plane using the legacy cursor - api). +- Async updates (currently only possible on cursor plane using the legacy + cursor api). + +For all of these, we also want to review the igt test coverage and make sure +all relevant igt testcases work on vkms. + +Prime Buffer Sharing +-------------------- -For all of these, we also want to review the igt test coverage and make sure all -relevant igt testcases work on vkms. +- Syzbot report - WARNING in vkms_gem_free_object: + https://syzkaller.appspot.com/bug?extid=e7ad70d406e74d8fc9d0 + +Runtime Configuration +--------------------- + +We want to be able to reconfigure vkms instance without having to reload the +module. Use/Test-cases: + +- Hotplug/hotremove connectors on the fly (to be able to test DP MST handling + of compositors). + +- Configure planes/crtcs/connectors (we'd need some code to have more than 1 of + them first). + +- Change output configuration: Plug/unplug screens, change EDID, allow changing + the refresh rate. + +The currently proposed solution is to expose vkms configuration through +configfs. All existing module options should be supported through configfs +too. Writeback support ----------------- -Currently vkms only computes a CRC for each frame. Once we have additional plane -features, we could write back the entire composited frame, and expose it as: +- The writeback and CRC capture operations share the use of composer_enabled + boolean to ensure vblanks. Probably, when these operations work together, + composer_enabled needs to refcounting the composer state to proper work. -- Writeback connector. This is useful for testing compositors if you don't have - hardware with writeback support. +- Add support for cloned writeback outputs and related test cases using a + cloned output in the IGT kms_writeback. - As a v4l device. This is useful for debugging compositors on special vkms configurations, so that developers see what's really going on. -Prime Buffer Sharing --------------------- - -We already have vgem, which is a gem driver for testing rendering, similar to -how vkms is for testing the modeset side. Adding buffer sharing support to vkms -allows us to test them together, to test synchronization and lots of other -features. Also, this allows compositors to test whether they work correctly on -SoC chips, where the display and rendering is very often split between 2 -drivers. - Output Features --------------- @@ -93,7 +97,10 @@ Output Features - Add support for link status, so that compositors can validate their runtime fallbacks when e.g. a Display Port link goes bad. -- All the hotplug handling describe under "Runtime Configuration". +CRC API Improvements +-------------------- + +- Optimize CRC computation ``compute_crc()`` and plane blending ``blend()`` Atomic Check using eBPF ----------------------- -- cgit v1.2.3 From d93dd060809f3db32ef3198121989e26e3049e00 Mon Sep 17 00:00:00 2001 From: Michael Auchter Date: Thu, 24 Sep 2020 14:52:14 -0500 Subject: dt-bindings: iio: dac: ad5686: add binding Add a binding for AD5686 Signed-off-by: Michael Auchter Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20200924195215.49443-3-michael.auchter@ni.com Signed-off-by: Jonathan Cameron --- .../devicetree/bindings/iio/dac/adi,ad5686.yaml | 57 ++++++++++++++++++++++ 1 file changed, 57 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml new file mode 100644 index 000000000000..8065228e5df8 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5686.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ad5686.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD5686 and similar multi-channel DACs + +maintainers: + - Michael Auchter + +description: | + Binding for Analog Devices AD5686 and similar multi-channel DACs + +properties: + compatible: + enum: + - adi,ad5311r + - adi,ad5338r + - adi,ad5671r + - adi,ad5675r + - adi,ad5691r + - adi,ad5692r + - adi,ad5693 + - adi,ad5693r + - adi,ad5694 + - adi,ad5694r + - adi,ad5695r + - adi,ad5696 + - adi,ad5696r + + reg: + maxItems: 1 + + vcc-supply: + description: | + The regulator supply for DAC reference voltage. + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + ad5686: dac@0 { + compatible = "adi,ad5686"; + reg = <0>; + vcc-supply = <&dac_vref>; + }; + }; +... -- cgit v1.2.3 From 324b9f2987441d6e53d314e64500de9fc65b0c12 Mon Sep 17 00:00:00 2001 From: Lorenzo Bianconi Date: Tue, 6 Oct 2020 14:07:42 +0200 Subject: dt-bindings: iio: imu: st_lsm6dsx: add lsm6dst device bindings Signed-off-by: Lorenzo Bianconi Acked-by: Rob Herring Link: https://lore.kernel.org/r/05e4273f2544230049b2cd82c6bf1be788a8e483.1601985763.git.lorenzo@kernel.org Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/imu/st_lsm6dsx.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/imu/st_lsm6dsx.txt b/Documentation/devicetree/bindings/iio/imu/st_lsm6dsx.txt index cef4bc16fce1..7c6742d3e992 100644 --- a/Documentation/devicetree/bindings/iio/imu/st_lsm6dsx.txt +++ b/Documentation/devicetree/bindings/iio/imu/st_lsm6dsx.txt @@ -16,6 +16,7 @@ Required properties: "st,lsm9ds1-imu" "st,lsm6ds0" "st,lsm6dsrx" + "st,lsm6dst" - reg: i2c address of the sensor / spi cs line Optional properties: -- cgit v1.2.3 From e94b3c608a2a886758da87dc5bb383e5eddce666 Mon Sep 17 00:00:00 2001 From: Stephen Boyd Date: Tue, 6 Oct 2020 18:17:34 -0700 Subject: dt-bindings: iio: sx9310: Add various settings as DT properties We need to set various bits in the hardware registers for this device to operate properly depending on how it is installed. Add a handful of DT properties to configure these things. Signed-off-by: Stephen Boyd Reviewed-by: Rob Herring Cc: Daniel Campello Cc: Lars-Peter Clausen Cc: Peter Meerwald-Stadler Cc: Cc: Douglas Anderson Cc: Gwendal Grignou Cc: Evan Green Link: https://lore.kernel.org/r/20201007011735.1346994-6-swboyd@chromium.org Signed-off-by: Jonathan Cameron --- .../bindings/iio/proximity/semtech,sx9310.yaml | 63 ++++++++++++++++++++++ 1 file changed, 63 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9310.yaml b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9310.yaml index 5739074d3592..ccfb163f3d34 100644 --- a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9310.yaml +++ b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9310.yaml @@ -40,6 +40,63 @@ properties: "#io-channel-cells": const: 1 + semtech,cs0-ground: + description: Indicates the CS0 sensor is connected to ground. + type: boolean + + semtech,combined-sensors: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: | + List of which sensors are combined and represented by CS3. + Possible values are - + 3 - CS3 (internal) + 0 1 - CS0 + CS1 + 1 2 - CS1 + CS2 (default) + 0 1 2 3 - CS0 + CS1 + CS2 + CS3 + items: + enum: [ 0, 1, 2, 3 ] + minItems: 1 + maxItems: 4 + + semtech,resolution: + description: + Capacitance measure resolution. Refer to datasheet for more details. + enum: + - coarsest + - very-coarse + - coarse + - medium-coarse + - medium + - fine + - very-fine + - finest + + semtech,startup-sensor: + $ref: /schemas/types.yaml#definitions/uint32 + enum: [0, 1, 2, 3] + default: 0 + description: + Sensor used for start-up proximity detection. The combined + sensor is represented by the value 3. This is used for initial + compensation. + + semtech,proxraw-strength: + $ref: /schemas/types.yaml#definitions/uint32 + enum: [0, 2, 4, 8] + default: 2 + description: + PROXRAW filter strength. A value of 0 represents off, and other values + represent 1-1/N. + + semtech,avg-pos-strength: + $ref: /schemas/types.yaml#definitions/uint32 + enum: [0, 16, 64, 128, 256, 512, 1024, 4294967295] + default: 16 + description: + Average positive filter strength. A value of 0 represents off and + UINT_MAX (4294967295) represents infinite. Other values + represent 1-1/N. + required: - compatible - reg @@ -61,5 +118,11 @@ examples: vdd-supply = <&pp3300_a>; svdd-supply = <&pp1800_prox>; #io-channel-cells = <1>; + semtech,cs0-ground; + semtech,combined-sensors = <1 2 3>; + semtech,resolution = "fine"; + semtech,startup-sensor = <1>; + semtech,proxraw-strength = <2>; + semtech,avg-pos-strength = <64>; }; }; -- cgit v1.2.3 From 9528a02430dfd4e8931578cee572203fc262c63b Mon Sep 17 00:00:00 2001 From: Sumit Semwal Date: Wed, 2 Sep 2020 12:14:06 +0530 Subject: dt-bindings: display: panel: Add bindings for Novatek nt36672a Novatek nt36672a is a display driver IC that can drive DSI panel. It is also present in the Tianma video mode panel, which is a FHD+ panel with a resolution of 1080x2246 and 6.18 inches size. It is found in some of the Poco F1 phones. This patch adds the display driver for the IC, with support added for this tianma fhd video mode panel. Signed-off-by: Sumit Semwal Reviewed-by: Rob Herring Reviewed-by: Bjorn Andersson Reviewed-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20200902064407.30712-2-sumit.semwal@linaro.org --- .../bindings/display/panel/novatek,nt36672a.yaml | 87 ++++++++++++++++++++++ 1 file changed, 87 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml new file mode 100644 index 000000000000..d2170de6b723 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/novatek,nt36672a.yaml @@ -0,0 +1,87 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/novatek,nt36672a.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Novatek NT36672A based DSI display Panels + +maintainers: + - Sumit Semwal + +description: | + The nt36672a IC from Novatek is a generic DSI Panel IC used to drive dsi + panels. + Right now, support is added only for a Tianma FHD+ LCD display panel with a + resolution of 1080x2246. It is a video mode DSI panel. + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + items: + - enum: + - tianma,fhd-video + - const: novatek,nt36672a + description: This indicates the panel manufacturer of the panel that is + in turn using the NT36672A panel driver. This compatible string + determines how the NT36672A panel driver is configured for the indicated + panel. The novatek,nt36672a compatible shall always be provided as a fallback. + + reset-gpios: + description: phandle of gpio for reset line - This should be 8mA, gpio + can be configured using mux, pinctrl, pinctrl-names (active high) + + vddio-supply: + description: phandle of the regulator that provides the supply voltage + Power IC supply + + vddpos-supply: + description: phandle of the positive boost supply regulator + + vddneg-supply: + description: phandle of the negative boost supply regulator + + reg: true + port: true + +required: + - compatible + - reg + - vddi0-supply + - vddpos-supply + - vddneg-supply + - reset-gpios + - port + +unevaluatedProperties: false + +examples: + - |+ + #include + + dsi0 { + #address-cells = <1>; + #size-cells = <0>; + + panel@0 { + compatible = "tianma,fhd-video", "novatek,nt36672a"; + reg = <0>; + vddi0-supply = <&vreg_l14a_1p88>; + vddpos-supply = <&lab>; + vddneg-supply = <&ibb>; + + reset-gpios = <&tlmm 6 GPIO_ACTIVE_HIGH>; + + #address-cells = <1>; + #size-cells = <0>; + port { + tianma_nt36672a_in_0: endpoint { + remote-endpoint = <&dsi0_out>; + }; + }; + }; + }; + +... -- cgit v1.2.3 From 1c902de389ff7cd6495e6a51e04b49ab00fca7d3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Guido=20G=C3=BCnther?= Date: Tue, 13 Oct 2020 12:32:48 +0200 Subject: dt-binding: display: Require two resets on mantix panel MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit We need to reset both for the panel to show an image. Signed-off-by: Guido Günther Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/15d3dc7eb4e031f380be1298ed3ac9085626f26b.1602584953.git.agx@sigxcpu.org --- .../devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml index 937323cc9aaa..51f423297ec8 100644 --- a/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml +++ b/Documentation/devicetree/bindings/display/panel/mantix,mlaf057we51-x.yaml @@ -37,6 +37,9 @@ properties: reset-gpios: true + 'mantix,tp-rstn-gpios': + description: second reset line that triggers DSI config load + backlight: true required: @@ -63,6 +66,7 @@ examples: avee-supply = <®_avee>; vddi-supply = <®_1v8_p>; reset-gpios = <&gpio1 29 GPIO_ACTIVE_LOW>; + mantix,tp-rstn-gpios = <&gpio1 24 GPIO_ACTIVE_LOW>; backlight = <&backlight>; }; }; -- cgit v1.2.3 From 9aab66010e5722fbfa2bb1f5d97b9409ec04cdf3 Mon Sep 17 00:00:00 2001 From: Xin Ji Date: Fri, 18 Sep 2020 18:22:57 +0800 Subject: dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter DT schema anx7625: MIPI to DP transmitter DT schema Signed-off-by: Xin Ji Reviewed-by: Rob Herring Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/bafa02aa50c5c29b3336ca6930c406150a3c60d2.1600423932.git.xji@analogixsemi.com --- .../bindings/display/bridge/analogix,anx7625.yaml | 95 ++++++++++++++++++++++ 1 file changed, 95 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml new file mode 100644 index 000000000000..60585a4fc22b --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml @@ -0,0 +1,95 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2019 Analogix Semiconductor, Inc. +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/display/bridge/analogix,anx7625.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Analogix ANX7625 SlimPort (4K Mobile HD Transmitter) + +maintainers: + - Xin Ji + +description: | + The ANX7625 is an ultra-low power 4K Mobile HD Transmitter + designed for portable devices. + +properties: + compatible: + items: + - const: analogix,anx7625 + + reg: + maxItems: 1 + + interrupts: + description: used for interrupt pin B8. + maxItems: 1 + + enable-gpios: + description: used for power on chip control, POWER_EN pin D2. + maxItems: 1 + + reset-gpios: + description: used for reset chip control, RESET_N pin B7. + maxItems: 1 + + ports: + type: object + + properties: + port@0: + type: object + description: + Video port for MIPI DSI input. + + port@1: + type: object + description: + Video port for panel or connector. + + required: + - port@0 + - port@1 + +required: + - compatible + - reg + - ports + +additionalProperties: false + +examples: + - | + #include + + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + + encoder@58 { + compatible = "analogix,anx7625"; + reg = <0x58>; + enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>; + reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + mipi2dp_bridge_in: port@0 { + reg = <0>; + anx7625_in: endpoint { + remote-endpoint = <&mipi_dsi>; + }; + }; + + mipi2dp_bridge_out: port@1 { + reg = <1>; + anx7625_out: endpoint { + remote-endpoint = <&panel_in>; + }; + }; + }; + }; + }; -- cgit v1.2.3 From 7924bcdbcb127b3f7d3b1eea94a8ef8ea035ca2e Mon Sep 17 00:00:00 2001 From: Jagan Teki Date: Fri, 4 Sep 2020 23:38:19 +0530 Subject: dt-bindings: vendor-prefixes: Add Yes Optoelectronics Add vendor dt-bindings for Yes Optoelectronics Co.,Ltd. Signed-off-by: Jagan Teki Acked-by: Rob Herring Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20200904180821.302194-1-jagan@amarulasolutions.com --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 8f27994d4497..e1ac4fb65689 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1190,6 +1190,8 @@ patternProperties: description: Shenzhen Xunlong Software CO.,Limited "^xylon,.*": description: Xylon + "^yes-optoelectronics,.*": + description: Yes Optoelectronics Co.,Ltd. "^ylm,.*": description: Shenzhen Yangliming Electronic Technology Co., Ltd. "^yna,.*": -- cgit v1.2.3 From b73946a2efeab26325259a07a1f3fde9cce6958f Mon Sep 17 00:00:00 2001 From: Jagan Teki Date: Fri, 4 Sep 2020 23:38:20 +0530 Subject: dt-bindings: display: simple: Add YTC700TLAG-05-201C Add dt-bindings for YTC700TLAG-05-201C 7" TFT LCD panel from Yes Optoelectronics Co.,Ltd. Signed-off-by: Jagan Teki Acked-by: Rob Herring Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20200904180821.302194-2-jagan@amarulasolutions.com --- Documentation/devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index edb53ab0d9eb..f9750b0b6708 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -282,6 +282,8 @@ properties: - vxt,vl050-8048nt-c01 # Winstar Display Corporation 3.5" QVGA (320x240) TFT LCD panel - winstar,wf35ltiacd + # Yes Optoelectronics YTC700TLAG-05-201C 7" TFT LCD panel + - yes-optoelectronics,ytc700tlag-05-201c backlight: true enable-gpios: true -- cgit v1.2.3 From b4ae07cde9b31bf94f38ef5c6f0750642f325c2f Mon Sep 17 00:00:00 2001 From: Fabien Parent Date: Mon, 12 Oct 2020 22:52:17 +0200 Subject: dt-bindings: iio: adc: auxadc: add doc for MT8516 SoC Add documentation for the auxadc binding for MT8516 SoC. Signed-off-by: Fabien Parent Reviewed-by: Matthias Brugger Acked-by: Rob Herring Link: https://lore.kernel.org/r/20201012205218.3010868-1-fparent@baylibre.com Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt b/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt index 78c06e05c8e5..1b7ff9e5615a 100644 --- a/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt +++ b/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt @@ -17,6 +17,7 @@ Required properties: - "mediatek,mt7622-auxadc": For MT7622 family of SoCs - "mediatek,mt8173-auxadc": For MT8173 family of SoCs - "mediatek,mt8183-auxadc", "mediatek,mt8173-auxadc": For MT8183 family of SoCs + - "mediatek,mt8516-auxadc", "mediatek,mt8173-auxadc": For MT8516 family of SoCs - reg: Address range of the AUXADC unit. - clocks: Should contain a clock specifier for each entry in clock-names - clock-names: Should contain "main". -- cgit v1.2.3 From 0d51d44e2a1f7619bcf21901deb40141b3f8f992 Mon Sep 17 00:00:00 2001 From: Neil Armstrong Date: Tue, 15 Sep 2020 14:19:09 +0200 Subject: dt-bindings: vendor-prefixes: Add Shanghai Top Display Optolelectronics vendor prefix Shanghai Top Display Optolelectronics Co., Ltd is a display manufacturer from Shanghai. Web site of the company: http://www.shtdo.com/ Signed-off-by: Neil Armstrong Reviewed-by: Sam Ravnborg Acked-by: Rob Herring Link: https://patchwork.freedesktop.org/patch/msgid/20200915121912.4347-2-narmstrong@baylibre.com --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index e1ac4fb65689..0e384959e870 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1037,6 +1037,8 @@ patternProperties: description: Trusted Computing Group "^tcl,.*": description: Toby Churchill Ltd. + "^tdo,.*": + description: Shangai Top Display Optoelectronics Co., Ltd "^technexion,.*": description: TechNexion "^technologic,.*": -- cgit v1.2.3 From ab793f5458278c7c620937ba906ab7a2b960e41c Mon Sep 17 00:00:00 2001 From: Neil Armstrong Date: Tue, 15 Sep 2020 14:19:10 +0200 Subject: dt-bindings: display: panel-simple-dsi: add optional reset gpio Simple DSI panels can also have a reset GPIO signal in addition/instead of an enable GPIO signal. This adds an optional reset-gpios property. Signed-off-by: Neil Armstrong Reviewed-by: Sam Ravnborg Acked-by: Rob Herring Link: https://patchwork.freedesktop.org/patch/msgid/20200915121912.4347-3-narmstrong@baylibre.com --- Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml index c0dd9fa29f1d..4d08e746cb21 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml @@ -54,6 +54,7 @@ properties: backlight: true enable-gpios: true + reset-gpios: true port: true power-supply: true -- cgit v1.2.3 From 6e3a8664322564fc50f9c2b882e1a72b55bae2f1 Mon Sep 17 00:00:00 2001 From: Neil Armstrong Date: Tue, 15 Sep 2020 14:19:11 +0200 Subject: dt-bindings: display: panel-simple-dsi: add TDO TL070WSH30 DSI panel bindings This add the bindings for the 1024x600 TFT LCD TL070WSH30 DSI panel to panel-simple-dsi. Signed-off-by: Neil Armstrong Reviewed-by: Sam Ravnborg Acked-by: Rob Herring Link: https://patchwork.freedesktop.org/patch/msgid/20200915121912.4347-4-narmstrong@baylibre.com --- Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml index 4d08e746cb21..a29ab65507f0 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml @@ -47,6 +47,8 @@ properties: - panasonic,vvx10f004b00 # Panasonic 10" WUXGA TFT LCD panel - panasonic,vvx10f034n00 + # Shangai Top Display Optoelectronics 7" TL070WSH30 1024x600 TFT LCD panel + - tdo,tl070wsh30 reg: maxItems: 1 -- cgit v1.2.3 From 302f0dad8c97a11abcf145ff3c7036f8f80e1a1e Mon Sep 17 00:00:00 2001 From: Sandeep Singh Date: Sat, 10 Oct 2020 01:31:35 +0530 Subject: SFH: Add maintainers and documentation for AMD SFH based on HID framework Add Maintainers for AMD SFH(SENSOR FUSION HUB) Solution and work flow document. Co-developed-by: Nehal Shah Signed-off-by: Nehal Shah Signed-off-by: Sandeep Singh Signed-off-by: Jiri Kosina --- Documentation/hid/index.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/hid/index.rst b/Documentation/hid/index.rst index 737d66dc16a1..e50f513c579c 100644 --- a/Documentation/hid/index.rst +++ b/Documentation/hid/index.rst @@ -16,3 +16,4 @@ Human Interface Devices (HID) hid-alps intel-ish-hid + amd-sfh-hid -- cgit v1.2.3 From 02f5bea93cdc4f1c7e37a2347ee18053c1af8cf2 Mon Sep 17 00:00:00 2001 From: Dong Aisheng Date: Wed, 29 Jul 2020 16:00:08 +0800 Subject: dt-bindings: firmware: imx-scu: new binding to parse clocks from device tree There's a few limitations on the original one cell clock binding (#clock-cells = <1>) that we have to define some SW clock IDs for device tree to reference. This may cause troubles if we want to use common clock IDs for multi platforms support when the clock of those platforms are mostly the same. e.g. Current clock IDs name are defined with SS prefix. However the device may reside in different SS across CPUs, that means the SS prefix may not valid anymore for a new SoC. Furthermore, the device availability of those clocks may also vary a bit. For such situation, we want to eliminate the using of SW Clock IDs and change to use a more close to HW one instead. For SCU clocks usage, only two params required: Resource id + Clock Type. Both parameters are platform independent. So we could use two cells binding to pass those parameters, Cc: Sascha Hauer Cc: Michael Turquette Cc: devicetree@vger.kernel.org Acked-by: Shawn Guo Reviewed-by: Rob Herring Reviewed-by: Stephen Boyd Signed-off-by: Dong Aisheng Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt index 6064d98b1031..395359dc94fd 100644 --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt @@ -89,7 +89,10 @@ Required properties: "fsl,imx8qm-clock" "fsl,imx8qxp-clock" followed by "fsl,scu-clk" -- #clock-cells: Should be 1. Contains the Clock ID value. +- #clock-cells: Should be either + 2: Contains the Resource and Clock ID value. + or + 1: Contains the Clock ID value. (DEPRECATED) - clocks: List of clock specifiers, must contain an entry for each required entry in clock-names - clock-names: Should include entries "xtal_32KHz", "xtal_24MHz" @@ -208,7 +211,7 @@ firmware { clk: clk { compatible = "fsl,imx8qxp-clk", "fsl,scu-clk"; - #clock-cells = <1>; + #clock-cells = <2>; }; iomuxc { @@ -263,8 +266,7 @@ serial@5a060000 { ... pinctrl-names = "default"; pinctrl-0 = <&pinctrl_lpuart0>; - clocks = <&clk IMX8QXP_UART0_CLK>, - <&clk IMX8QXP_UART0_IPG_CLK>; - clock-names = "per", "ipg"; + clocks = <&uart0_clk IMX_SC_R_UART_0 IMX_SC_PM_CLK_PER>; + clock-names = "ipg"; power-domains = <&pd IMX_SC_R_UART_0>; }; -- cgit v1.2.3 From 5f1a9066fcb2cc1d41104c74884f6c6cf010124b Mon Sep 17 00:00:00 2001 From: Chanwoo Choi Date: Fri, 3 Jul 2020 17:20:27 +0900 Subject: PM / devfreq: Add governor attribute flag for specifc sysfs nodes DEVFREQ supports the default governors like performance, simple_ondemand and also allows the devfreq driver to add their own governor like tegra30-devfreq.c according to their requirement. In result, some sysfs attributes are useful or not useful. Prior to that the user can access all sysfs attributes regardless of the available attributes. So, clarify the access permission of sysfs attributes according to governor. When adding the devfreq governor, can specify the available attribute information by using DEVFREQ_GOV_ATTR_* constant variable. The user can read or write the sysfs attributes in accordance to the specified attributes. When adding the governor, can add the following attributes according to the governor feature. [Definition for speific sysfs attributes] - DEVFREQ_GOV_ATTR_POLLING_INTERVAL to update polling interval for timer. : /sys/class/devfreq/[devfreq dev name]/polling_interval - DEVFREQ_GOV_ATTR_TIMER to change the type of timer on either deferrable or dealyed timer. : /sys/class/devfreq/[devfreq dev name]/timer And all devfreq governors have to support the following common attributes. The common attributes are added to devfreq class by default. - governor - available_governors - available_frequencies - cur_freq - target_freq - min_freq - max_freq - trans_stat [Table of governor attribute flags for devfreq governors] ------------------------------------------------------------------------------ | simple | perfor | power | user | passive | tegra30 | ondemand | mance | save | space| | ------------------------------------------------------------------------------ governor | O | O | O | O | O | O available_governors | O | O | O | O | O | O available_frequencies | O | O | O | O | O | O cur_freq | O | O | O | O | O | O target_freq | O | O | O | O | O | O min_freq | O | O | O | O | O | O max_freq | O | O | O | O | O | O trans_stat | O | O | O | O | O | O -------------------------------------------------------- polling_interval | O | X | X | X | X | O timer | O | X | X | X | X | X ------------------------------------------------------------------------------ Reviewed-by: Dmitry Osipenko Tested-by: Dmitry Osipenko Signed-off-by: Chanwoo Choi --- Documentation/ABI/testing/sysfs-class-devfreq | 54 ++++++++++++++++----------- 1 file changed, 32 insertions(+), 22 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-class-devfreq b/Documentation/ABI/testing/sysfs-class-devfreq index deefffb3bbe4..67af3f31e17c 100644 --- a/Documentation/ABI/testing/sysfs-class-devfreq +++ b/Documentation/ABI/testing/sysfs-class-devfreq @@ -37,20 +37,6 @@ Description: The /sys/class/devfreq/.../target_freq shows the next governor predicted target frequency of the corresponding devfreq object. -What: /sys/class/devfreq/.../polling_interval -Date: September 2011 -Contact: MyungJoo Ham -Description: - The /sys/class/devfreq/.../polling_interval shows and sets - the requested polling interval of the corresponding devfreq - object. The values are represented in ms. If the value is - less than 1 jiffy, it is considered to be 0, which means - no polling. This value is meaningless if the governor is - not polling; thus. If the governor is not using - devfreq-provided central polling - (/sys/class/devfreq/.../central_polling is 0), this value - may be useless. - What: /sys/class/devfreq/.../trans_stat Date: October 2012 Contact: MyungJoo Ham @@ -65,14 +51,6 @@ Description: as following: echo 0 > /sys/class/devfreq/.../trans_stat -What: /sys/class/devfreq/.../userspace/set_freq -Date: September 2011 -Contact: MyungJoo Ham -Description: - The /sys/class/devfreq/.../userspace/set_freq shows and - sets the requested frequency for the devfreq object if - userspace governor is in effect. - What: /sys/class/devfreq/.../available_frequencies Date: October 2012 Contact: Nishanth Menon @@ -109,6 +87,35 @@ Description: The max_freq overrides min_freq because max_freq may be used to throttle devices to avoid overheating. +What: /sys/class/devfreq/.../polling_interval +Date: September 2011 +Contact: MyungJoo Ham +Description: + The /sys/class/devfreq/.../polling_interval shows and sets + the requested polling interval of the corresponding devfreq + object. The values are represented in ms. If the value is + less than 1 jiffy, it is considered to be 0, which means + no polling. This value is meaningless if the governor is + not polling; thus. If the governor is not using + devfreq-provided central polling + (/sys/class/devfreq/.../central_polling is 0), this value + may be useless. + + A list of governors that support the node: + - simple_ondmenad + - tegra_actmon + +What: /sys/class/devfreq/.../userspace/set_freq +Date: September 2011 +Contact: MyungJoo Ham +Description: + The /sys/class/devfreq/.../userspace/set_freq shows and + sets the requested frequency for the devfreq object if + userspace governor is in effect. + + A list of governors that support the node: + - userspace + What: /sys/class/devfreq/.../timer Date: July 2020 Contact: Chanwoo Choi @@ -120,3 +127,6 @@ Description: as following: echo deferrable > /sys/class/devfreq/.../timer echo delayed > /sys/class/devfreq/.../timer + + A list of governors that support the node: + - simple_ondemand -- cgit v1.2.3 From 540742fb109fa4a65f116db9edc28ab1bd2c872d Mon Sep 17 00:00:00 2001 From: Dong Aisheng Date: Wed, 29 Jul 2020 16:00:09 +0800 Subject: dt-bindings: clock: imx-lpcg: add support to parse clocks from device tree MX8QM and MX8QXP LPCG Clocks are mostly the same except they may reside in different subsystems across CPUs and also vary a bit on the availability. Same as SCU clock, we want to move the clock definition into device tree which can fully decouple the dependency of Clock ID definition from device tree and make us be able to write a fully generic lpcg clock driver. And we can also use the existence of clock nodes in device tree to address the device and clock availability differences across different SoCs. Cc: Sascha Hauer Cc: Michael Turquette Cc: devicetree@vger.kernel.org Cc: Shawn Guo Cc: Rob Herring Cc: Stephen Boyd Signed-off-by: Dong Aisheng Reviewed-by: Rob Herring Reviewed-by: Stephen Boyd Signed-off-by: Shawn Guo --- .../devicetree/bindings/clock/imx8qxp-lpcg.yaml | 79 ++++++++++++++++------ 1 file changed, 60 insertions(+), 19 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml index 33f3010f48c3..e709e530e17a 100644 --- a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml +++ b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml @@ -21,27 +21,58 @@ description: | The clock consumer should specify the desired clock by having the clock ID in its "clocks" phandle cell. See the full list of clock IDs from: - include/dt-bindings/clock/imx8-clock.h + include/dt-bindings/clock/imx8-lpcg.h properties: compatible: - enum: - - fsl,imx8qxp-lpcg-adma - - fsl,imx8qxp-lpcg-conn - - fsl,imx8qxp-lpcg-dc - - fsl,imx8qxp-lpcg-dsp - - fsl,imx8qxp-lpcg-gpu - - fsl,imx8qxp-lpcg-hsio - - fsl,imx8qxp-lpcg-img - - fsl,imx8qxp-lpcg-lsio - - fsl,imx8qxp-lpcg-vpu - + oneOf: + - const: fsl,imx8qxp-lpcg + - items: + - enum: + - fsl,imx8qm-lpcg + - const: fsl,imx8qxp-lpcg + - enum: + - fsl,imx8qxp-lpcg-adma + - fsl,imx8qxp-lpcg-conn + - fsl,imx8qxp-lpcg-dc + - fsl,imx8qxp-lpcg-dsp + - fsl,imx8qxp-lpcg-gpu + - fsl,imx8qxp-lpcg-hsio + - fsl,imx8qxp-lpcg-img + - fsl,imx8qxp-lpcg-lsio + - fsl,imx8qxp-lpcg-vpu + deprecated: true reg: maxItems: 1 '#clock-cells': const: 1 + clocks: + description: | + Input parent clocks phandle array for each clock + minItems: 1 + maxItems: 8 + + clock-indices: + description: | + An integer array indicating the bit offset for each clock. + Refer to for the + supported LPCG clock indices. + minItems: 1 + maxItems: 8 + + clock-output-names: + description: | + Shall be the corresponding names of the outputs. + NOTE this property must be specified in the same order + as the clock-indices property. + minItems: 1 + maxItems: 8 + + power-domains: + maxItems: 1 + required: - compatible - reg @@ -51,23 +82,33 @@ additionalProperties: false examples: - | - #include + #include #include #include - clock-controller@5b200000 { - compatible = "fsl,imx8qxp-lpcg-conn"; - reg = <0x5b200000 0xb0000>; + sdhc0_lpcg: clock-controller@5b200000 { + compatible = "fsl,imx8qxp-lpcg"; + reg = <0x5b200000 0x10000>; #clock-cells = <1>; + clocks = <&sdhc0_clk IMX_SC_PM_CLK_PER>, + <&conn_ipg_clk>, + <&conn_axi_clk>; + clock-indices = , + , + ; + clock-output-names = "sdhc0_lpcg_per_clk", + "sdhc0_lpcg_ipg_clk", + "sdhc0_lpcg_ahb_clk"; + power-domains = <&pd IMX_SC_R_SDHC_0>; }; mmc@5b010000 { compatible = "fsl,imx8qxp-usdhc", "fsl,imx7d-usdhc"; interrupts = ; reg = <0x5b010000 0x10000>; - clocks = <&conn_lpcg IMX_CONN_LPCG_SDHC0_IPG_CLK>, - <&conn_lpcg IMX_CONN_LPCG_SDHC0_PER_CLK>, - <&conn_lpcg IMX_CONN_LPCG_SDHC0_HCLK>; + clocks = <&sdhc0_lpcg IMX_LPCG_CLK_4>, + <&sdhc0_lpcg IMX_LPCG_CLK_0>, + <&sdhc0_lpcg IMX_LPCG_CLK_5>; clock-names = "ipg", "per", "ahb"; power-domains = <&pd IMX_SC_R_SDHC_0>; }; -- cgit v1.2.3 From 12ec7e56ce95d7b6fd4cd74e634c1181e2b424e1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marek=20Beh=C3=BAn?= Date: Mon, 19 Oct 2020 13:08:08 +0200 Subject: Documentation: leds: remove invalidated information MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The contents of the Future Development section of leds-class Documentation was invalidated when support for LED-private triggers was merged. Remove this section. Signed-off-by: Marek Behún Fixes: 93690cdf3060 ("leds: trigger: add support for LED-private device...") Signed-off-by: Pavel Machek --- Documentation/leds/leds-class.rst | 10 ---------- 1 file changed, 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/leds/leds-class.rst b/Documentation/leds/leds-class.rst index a0708d3f3d0b..cd155ead8703 100644 --- a/Documentation/leds/leds-class.rst +++ b/Documentation/leds/leds-class.rst @@ -177,13 +177,3 @@ The LED Trigger core cannot be a module as the simple trigger functions would cause nightmare dependency issues. I see this as a minor issue compared to the benefits the simple trigger functionality brings. The rest of the LED subsystem can be modular. - - -Future Development -================== - -At the moment, a trigger can't be created specifically for a single LED. -There are a number of cases where a trigger might only be mappable to a -particular LED (ACPI?). The addition of triggers provided by the LED driver -should cover this option and be possible to add without breaking the -current interface. -- cgit v1.2.3 From 54e9f3633ed1bc22033de27dec733415bd750eda Mon Sep 17 00:00:00 2001 From: Fabien Parent Date: Mon, 12 Oct 2020 22:52:17 +0200 Subject: dt-bindings: iio: adc: auxadc: add doc for MT8516 SoC Add documentation for the auxadc binding for MT8516 SoC. Signed-off-by: Fabien Parent Reviewed-by: Matthias Brugger Acked-by: Rob Herring Link: https://lore.kernel.org/r/20201012205218.3010868-1-fparent@baylibre.com Signed-off-by: Matthias Brugger --- Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt b/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt index 78c06e05c8e5..1b7ff9e5615a 100644 --- a/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt +++ b/Documentation/devicetree/bindings/iio/adc/mt6577_auxadc.txt @@ -17,6 +17,7 @@ Required properties: - "mediatek,mt7622-auxadc": For MT7622 family of SoCs - "mediatek,mt8173-auxadc": For MT8173 family of SoCs - "mediatek,mt8183-auxadc", "mediatek,mt8173-auxadc": For MT8183 family of SoCs + - "mediatek,mt8516-auxadc", "mediatek,mt8173-auxadc": For MT8516 family of SoCs - reg: Address range of the AUXADC unit. - clocks: Should contain a clock specifier for each entry in clock-names - clock-names: Should contain "main". -- cgit v1.2.3 From ee84049c1391d45c6e3ecccf45b5f679e4914253 Mon Sep 17 00:00:00 2001 From: Konrad Dybcio Date: Sun, 18 Oct 2020 14:26:20 +0200 Subject: dt-bindings: power: rpmpd: Add SDM660 power-domains bindings Add the new bindings for SDM660 rpmpd power domains. Signed-off-by: Konrad Dybcio Signed-off-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20201018122620.9735-2-kholk11@gmail.com Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/power/qcom,rpmpd.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml index 8058955fb3b9..45ec2439ff51 100644 --- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml +++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml @@ -20,6 +20,7 @@ properties: - qcom,msm8996-rpmpd - qcom,msm8998-rpmpd - qcom,qcs404-rpmpd + - qcom,sdm660-rpmpd - qcom,sc7180-rpmhpd - qcom,sdm845-rpmhpd - qcom,sm8150-rpmhpd -- cgit v1.2.3 From 1dd50f17d6ce36b7d92765dc58a9f4abf78f29b9 Mon Sep 17 00:00:00 2001 From: Jun Nie Date: Wed, 30 Sep 2020 18:01:44 +0800 Subject: dt-bindings: power: rpmpd: Add MSM8939 RPM power domains MSM8939 has three RPM power domains: VDDCX and VDDMX and VDDMDCX. Add the device tree bindings to manage them through rpmpd. Reviewed-by: Stephan Gerhold Acked-by: Rob Herring Signed-off-by: Jun Nie Link: https://lore.kernel.org/r/20200930100145.9457-2-jun.nie@linaro.org Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/power/qcom,rpmpd.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml index 45ec2439ff51..bd628da9318f 100644 --- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml +++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml @@ -16,6 +16,7 @@ description: properties: compatible: enum: + - qcom,msm8939-rpmpd - qcom,msm8976-rpmpd - qcom,msm8996-rpmpd - qcom,msm8998-rpmpd -- cgit v1.2.3 From 819f7d91ad97d0660a4915e4ff4241c786fa613a Mon Sep 17 00:00:00 2001 From: Stephan Gerhold Date: Wed, 16 Sep 2020 12:41:27 +0200 Subject: dt-bindings: power: rpmpd: Add MSM8916 RPM power domains MSM8916 has two RPM power domains: VDDCX and VDDMX. Add the device tree bindings to manage them through rpmpd. Reviewed-by: Rob Herring Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20200916104135.25085-3-stephan@gerhold.net Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/power/qcom,rpmpd.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml index bd628da9318f..e07453417f45 100644 --- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml +++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml @@ -16,6 +16,7 @@ description: properties: compatible: enum: + - qcom,msm8916-rpmpd - qcom,msm8939-rpmpd - qcom,msm8976-rpmpd - qcom,msm8996-rpmpd -- cgit v1.2.3 From 0711ae454b2da902d6bb661e722ab69b6b02cf17 Mon Sep 17 00:00:00 2001 From: Stephan Gerhold Date: Wed, 16 Sep 2020 12:41:30 +0200 Subject: dt-bindings: remoteproc: qcom: Deprecate regulators for Q6V5 PDs Newer platforms vote for necessary power domains through the power domain subsystem. For historical reasons older platforms like MSM8916 or MSM8974 still control these as regulators. Managing them as power domains is preferred since that allows us to vote for corners instead of raw voltages. Document that those should be specified as power domains and deprecate using them through the regulator interface. Reviewed-by: Rob Herring Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20200916104135.25085-6-stephan@gerhold.net Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt index 1f9a62e13ebe..7ccd5534b0ae 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt +++ b/Documentation/devicetree/bindings/remoteproc/qcom,q6v5.txt @@ -113,8 +113,8 @@ should be referenced as follows: For the compatible strings below the following supplies are required: "qcom,q6v5-pil" "qcom,msm8916-mss-pil", -- cx-supply: -- mx-supply: +- cx-supply: (deprecated, use power domain instead) +- mx-supply: (deprecated, use power domain instead) - pll-supply: Usage: required Value type: @@ -123,9 +123,9 @@ For the compatible strings below the following supplies are required: For the compatible string below the following supplies are required: "qcom,msm8974-mss-pil" -- cx-supply: +- cx-supply: (deprecated, use power domain instead) - mss-supply: -- mx-supply: +- mx-supply: (deprecated, use power domain instead) - pll-supply: Usage: required Value type: @@ -149,11 +149,11 @@ For the compatible string below the following supplies are required: Usage: required Value type: Definition: The power-domains needed depend on the compatible string: - qcom,q6v5-pil: qcom,ipq8074-wcss-pil: + no power-domain names required + qcom,q6v5-pil: qcom,msm8916-mss-pil: qcom,msm8974-mss-pil: - no power-domain names required qcom,msm8996-mss-pil: qcom,msm8998-mss-pil: must be "cx", "mx" -- cgit v1.2.3 From 20a2269c1983aff7894f432b86434ef1738e6d52 Mon Sep 17 00:00:00 2001 From: Stephan Gerhold Date: Wed, 16 Sep 2020 12:41:32 +0200 Subject: dt-bindings: remoteproc: qcom,wcnss: Deprecate regulators for PDs So far we have been doing all proxy votes by voting for raw voltages/load through the regulator interface. But actually VDDCX and VDDMX represent power domains that should be preferably managed using corner votes through the power domain interface. Document that those should be specified as power domains for qcom,pronto-v1/2-pil and deprecate using them through the regulator interface. Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20200916104135.25085-8-stephan@gerhold.net Signed-off-by: Bjorn Andersson --- .../bindings/remoteproc/qcom,wcnss-pil.txt | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt index d420f84ddfb0..cc0b7fc1c29b 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt +++ b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt @@ -34,14 +34,25 @@ on the Qualcomm WCNSS core. Definition: should be "wdog", "fatal", optionally followed by "ready", "handover", "stop-ack" -- vddmx-supply: -- vddcx-supply: +- vddmx-supply: (deprecated for qcom,pronto-v1/2-pil) +- vddcx-supply: (deprecated for qcom,pronto-v1/2-pil) - vddpx-supply: Usage: required Value type: Definition: reference to the regulators to be held on behalf of the booting of the WCNSS core +- power-domains: + Usage: required (for qcom,pronto-v1/2-pil) + Value type: + Definition: reference to the power domains to be held on behalf of the + booting of the WCNSS core + +- power-domain-names: + Usage: required (for qcom,pronto-v1/2-pil) + Value type: + Definition: must be "cx", "mx" + - qcom,smem-states: Usage: optional Value type: @@ -111,8 +122,9 @@ pronto@fb204000 { <&wcnss_smp2p_slave 3 0>; interrupt-names = "wdog", "fatal", "ready", "handover", "stop-ack"; - vddmx-supply = <&pm8841_s1>; - vddcx-supply = <&pm8841_s2>; + power-domains = <&rpmpd MSM8974_VDDCX>, <&rpmpd MSM8974_VDDMX>; + power-domain-names = "cx", "mx"; + vddpx-supply = <&pm8941_s3>; qcom,smem-states = <&wcnss_smp2p_out 0>; -- cgit v1.2.3 From 0afb88d5a602488f877380ad1ec37cc20c927c68 Mon Sep 17 00:00:00 2001 From: Viorel Suman Date: Tue, 13 Oct 2020 15:17:33 +0300 Subject: ASoC: dt-bindings: fsl_xcvr: Add document for XCVR XCVR (Audio Transceiver) is a new IP module found on i.MX8MP. Signed-off-by: Viorel Suman Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20201013121733.83684-3-viorel.suman@oss.nxp.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/fsl,xcvr.yaml | 104 +++++++++++++++++++++ 1 file changed, 104 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/fsl,xcvr.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml b/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml new file mode 100644 index 000000000000..223b8ea693dc --- /dev/null +++ b/Documentation/devicetree/bindings/sound/fsl,xcvr.yaml @@ -0,0 +1,104 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/fsl,xcvr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP Audio Transceiver (XCVR) Controller + +maintainers: + - Viorel Suman + +description: | + NXP XCVR (Audio Transceiver) is a on-chip functional module + that allows CPU to receive and transmit digital audio via + HDMI2.1 eARC, HDMI1.4 ARC and SPDIF. + +properties: + $nodename: + pattern: "^xcvr@.*" + + compatible: + enum: + - fsl,imx8mp-xcvr + + reg: + items: + - description: 20K RAM for code and data + - description: registers space + - description: RX FIFO address + - description: TX FIFO address + + reg-names: + items: + - const: ram + - const: regs + - const: rxfifo + - const: txfifo + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Peripheral clock + - description: PHY clock + - description: SPBA clock + - description: PLL clock + + clock-names: + items: + - const: ipg + - const: phy + - const: spba + - const: pll_ipg + + dmas: + items: + - description: DMA controller phandle and request line for RX + - description: DMA controller phandle and request line for TX + + dma-names: + items: + - const: rx + - const: tx + + resets: + maxItems: 1 + +required: + - compatible + - reg + - reg-names + - interrupts + - clocks + - clock-names + - dmas + - dma-names + - resets + +additionalProperties: false + +examples: + - | + #include + #include + #include + + xcvr: xcvr@30cc0000 { + compatible = "fsl,imx8mp-xcvr"; + reg = <0x30cc0000 0x800>, + <0x30cc0800 0x400>, + <0x30cc0c00 0x080>, + <0x30cc0e00 0x080>; + reg-names = "ram", "regs", "rxfifo", "txfifo"; + interrupts = <0x0 128 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&audiomix_clk IMX8MP_CLK_AUDIOMIX_EARC_IPG>, + <&audiomix_clk IMX8MP_CLK_AUDIOMIX_EARC_PHY>, + <&audiomix_clk IMX8MP_CLK_AUDIOMIX_SPBA2_ROOT>, + <&audiomix_clk IMX8MP_CLK_AUDIOMIX_AUDPLL_ROOT>; + clock-names = "ipg", "phy", "spba", "pll_ipg"; + dmas = <&sdma2 30 2 0>, <&sdma2 31 2 0>; + dma-names = "rx", "tx"; + resets = <&audiomix_reset 0>; + }; -- cgit v1.2.3 From d5123d2c71916dac01f76f9cdf517fde6936d5fa Mon Sep 17 00:00:00 2001 From: Arnaud Pouliquen Date: Wed, 14 Oct 2020 14:54:38 +0200 Subject: dt-bindings: arm: stm32: Add compatible for syscon tamp node Since commit ad440432d1f9 ("dt-bindings: mfd: Ensure 'syscon' has a more specific compatible") It is required to provide at least 2 compatibles string for syscon node. This patch documents the new compatible for stm32 SoC to support TAMP registers access. Signed-off-by: Arnaud Pouliquen Acked-by: Rob Herring Link: https://lore.kernel.org/r/20201014125441.2457-2-arnaud.pouliquen@st.com Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml b/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml index 6f1cd0103c74..6634b3e0853e 100644 --- a/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/st,stm32-syscon.yaml @@ -19,6 +19,7 @@ properties: - st,stm32mp151-pwr-mcu - st,stm32-syscfg - st,stm32-power-config + - st,stm32-tamp - const: syscon reg: -- cgit v1.2.3 From e67bae44c708b734e852077428f97b26610bccac Mon Sep 17 00:00:00 2001 From: Arnaud Pouliquen Date: Wed, 14 Oct 2020 14:54:39 +0200 Subject: dt-bindings: remoteproc: stm32_rproc: update for firmware synchronization Add new properties description used to attach to a pre-loaded firmware according to the commit 9276536f455b3 ("remoteproc: stm32: Parse syscon that will manage M4 synchronisation") which updates the driver part. Reviewed-by: Rob Herring Signed-off-by: Arnaud Pouliquen Link: https://lore.kernel.org/r/20201014125441.2457-3-arnaud.pouliquen@st.com Signed-off-by: Bjorn Andersson --- .../devicetree/bindings/remoteproc/st,stm32-rproc.yaml | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml index 4ffa25268fcc..3207942d51bf 100644 --- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml @@ -96,6 +96,19 @@ properties: 3rd cell: register bitmask for the deep sleep bit maxItems: 1 + st,syscfg-m4-state: + $ref: "/schemas/types.yaml#/definitions/phandle-array" + description: | + Reference to the tamp register which exposes the Cortex-M4 state. + maxItems: 1 + + st,syscfg-rsc-tbl: + $ref: "/schemas/types.yaml#/definitions/phandle-array" + description: | + Reference to the tamp register which references the Cortex-M4 + resource table address. + maxItems: 1 + st,auto-boot: $ref: /schemas/types.yaml#/definitions/flag description: @@ -122,6 +135,8 @@ examples: resets = <&rcc MCU_R>; st,syscfg-holdboot = <&rcc 0x10C 0x1>; st,syscfg-tz = <&rcc 0x000 0x1>; + st,syscfg-rsc-tbl = <&tamp 0x144 0xFFFFFFFF>; + st,syscfg-m4-state = <&tamp 0x148 0xFFFFFFFF>; }; ... -- cgit v1.2.3 From 2b0ced1203c2da02ee9fe9f1f8becf834a6bff8b Mon Sep 17 00:00:00 2001 From: Arnaud Pouliquen Date: Wed, 14 Oct 2020 14:54:40 +0200 Subject: dt-bindings: remoteproc: stm32_rproc: update syscon descriptions Align other syscon descriptions with st,syscfg-m4-state and st,syscfg-rsc-tbl descriptions by suppressing the cells description. Acked-by: Rob Herring Signed-off-by: Arnaud Pouliquen Link: https://lore.kernel.org/r/20201014125441.2457-4-arnaud.pouliquen@st.com Signed-off-by: Bjorn Andersson --- Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml | 6 ------ 1 file changed, 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml index 3207942d51bf..a1171dfba024 100644 --- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml @@ -38,9 +38,6 @@ properties: st,syscfg-tz: description: Reference to the system configuration which holds the RCC trust zone mode - - Phandle of syscon block. - - The offset of the RCC trust zone mode register. - - The field mask of the RCC trust zone mode. $ref: "/schemas/types.yaml#/definitions/phandle-array" maxItems: 1 @@ -91,9 +88,6 @@ properties: $ref: "/schemas/types.yaml#/definitions/phandle-array" description: | Reference to the system configuration which holds the remote - 1st cell: phandle to syscon block - 2nd cell: register offset containing the deep sleep setting - 3rd cell: register bitmask for the deep sleep bit maxItems: 1 st,syscfg-m4-state: -- cgit v1.2.3 From f24fd10bea5961629f22e1da0f56e8c918bdb2da Mon Sep 17 00:00:00 2001 From: Olivier Moysan Date: Tue, 20 Oct 2020 17:57:08 +0200 Subject: dt-bindings: stm32: dfsdm: update audio properties - Add missing compatible property in audio node. - Remove obsolete "st,stm32-dfsdm-pdm" compatible. - Remove useless comment in adc io-channels description. Signed-off-by: Olivier Moysan Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20201020155709.2621-2-olivier.moysan@st.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml index d61bc011e820..6f2398cdc82d 100644 --- a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml @@ -199,8 +199,6 @@ patternProperties: description: From common IIO binding. Used to pipe external sigma delta modulator or internal ADC output to DFSDM channel. - This is not required for "st,stm32-dfsdm-pdm" compatibility as - PDM microphone is binded in Audio DT node. required: - io-channels @@ -235,6 +233,10 @@ patternProperties: description: child node properties: + compatible: + enum: + - st,stm32h7-dfsdm-dai + "#sound-dai-cells": const: 0 @@ -244,6 +246,7 @@ patternProperties: modulator or internal ADC output to DFSDM channel. required: + - compatible - "#sound-dai-cells" - io-channels -- cgit v1.2.3 From ea8650730332ee3c707883a2de37756ea9122981 Mon Sep 17 00:00:00 2001 From: Olivier Moysan Date: Tue, 20 Oct 2020 17:57:09 +0200 Subject: ASoC: dt-bindings: stm32: dfsdm: remove stm32-adfsdm.txt binding Device tree audio configuration for STM32 DFSDM is already covered in the following binding: Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml Remove stm32-adfsdm.txt obsolete binding. Signed-off-by: Olivier Moysan Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20201020155709.2621-3-olivier.moysan@st.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/st,stm32-adfsdm.txt | 63 ---------------------- 1 file changed, 63 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/st,stm32-adfsdm.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/st,stm32-adfsdm.txt b/Documentation/devicetree/bindings/sound/st,stm32-adfsdm.txt deleted file mode 100644 index 864f5b00b031..000000000000 --- a/Documentation/devicetree/bindings/sound/st,stm32-adfsdm.txt +++ /dev/null @@ -1,63 +0,0 @@ -STMicroelectronics Audio Digital Filter Sigma Delta modulators(DFSDM) - -The DFSDM allows PDM microphones capture through SPI interface. The Audio -interface is seems as a sub block of the DFSDM device. -For details on DFSDM bindings refer to ../iio/adc/st,stm32-dfsdm-adc.txt - -Required properties: - - compatible: "st,stm32h7-dfsdm-dai". - - - #sound-dai-cells : Must be equal to 0 - - - io-channels : phandle to iio dfsdm instance node. - -Example of a sound card using audio DFSDM node. - - sound_card { - compatible = "audio-graph-card"; - - dais = <&cpu_port>; - }; - - dfsdm: dfsdm@40017000 { - compatible = "st,stm32h7-dfsdm"; - reg = <0x40017000 0x400>; - clocks = <&rcc DFSDM1_CK>; - clock-names = "dfsdm"; - #interrupt-cells = <1>; - #address-cells = <1>; - #size-cells = <0>; - - dfsdm_adc0: filter@0 { - compatible = "st,stm32-dfsdm-dmic"; - reg = <0>; - interrupts = <110>; - dmas = <&dmamux1 101 0x400 0x00>; - dma-names = "rx"; - st,adc-channels = <1>; - st,adc-channel-names = "dmic0"; - st,adc-channel-types = "SPI_R"; - st,adc-channel-clk-src = "CLKOUT"; - st,filter-order = <5>; - - dfsdm_dai0: dfsdm-dai { - compatible = "st,stm32h7-dfsdm-dai"; - #sound-dai-cells = <0>; - io-channels = <&dfsdm_adc0 0>; - cpu_port: port { - dfsdm_endpoint: endpoint { - remote-endpoint = <&dmic0_endpoint>; - }; - }; - }; - }; - - dmic0: dmic@0 { - compatible = "dmic-codec"; - #sound-dai-cells = <0>; - port { - dmic0_endpoint: endpoint { - remote-endpoint = <&dfsdm_endpoint>; - }; - }; - }; -- cgit v1.2.3 From 765c37598494cdb6c8f833e8e46f494af5c7d39e Mon Sep 17 00:00:00 2001 From: Srinivas Kandagatla Date: Mon, 26 Oct 2020 17:09:46 +0000 Subject: ASoC: qcom: dt-bindings: Add SM8250 sound card bindings This patch adds bindings required for SM8250 based soundcards for example Qualcomm Robotics RB5 Development Kit which makes use of ADSP and Internal LPASS codec. Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20201026170947.10567-2-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/qcom,sm8250.yaml | 161 +++++++++++++++++++++ 1 file changed, 161 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/qcom,sm8250.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml new file mode 100644 index 000000000000..b8f97fe6e92c --- /dev/null +++ b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml @@ -0,0 +1,161 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/qcom,sm8250.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies Inc. SM8250 ASoC sound card driver + +maintainers: + - Srinivas Kandagatla + +description: + This bindings describes SC8250 SoC based sound cards + which uses LPASS internal codec for audio. + +properties: + compatible: + oneOf: + - const: qcom,qrb5165-rb5 + - items: + - const: qcom,sm8250 + - const: qcom,qrb5165-rb5 + + audio-routing: + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + description: + A list of the connections between audio components. Each entry is a + pair of strings, the first being the connection's sink, the second + being the connection's source. Valid names could be power supplies, + MicBias of codec and the jacks on the board. + + model: + $ref: /schemas/types.yaml#/definitions/string + description: User visible long sound card name + +patternProperties: + ".*-dai-link$": + description: + Each subnode represents a dai link. Subnodes of each dai links would be + cpu/codec dais. + + type: object + + properties: + link-name: + description: Indicates dai-link name and PCM stream name. + $ref: /schemas/types.yaml#/definitions/string + maxItems: 1 + + cpu: + description: Holds subnode which indicates cpu dai. + type: object + properties: + sound-dai: true + + platform: + description: Holds subnode which indicates platform dai. + type: object + properties: + sound-dai: true + + codec: + description: Holds subnode which indicates codec dai. + type: object + properties: + sound-dai: true + + required: + - link-name + - cpu + + additionalProperties: false + +required: + - compatible + - model + +additionalProperties: false + +examples: + + - | + #include + #include + sound { + compatible = "qcom,qrb5165-rb5"; + model = "Qualcomm-qrb5165-RB5-WSA8815-Speakers-DMIC0"; + audio-routing = "SpkrLeft IN", "WSA_SPK1 OUT", + "SpkrRight IN", "WSA_SPK2 OUT", + "VA DMIC0", "vdd-micb", + "VA DMIC1", "vdd-micb", + "MM_DL1", "MultiMedia1 Playback", + "MM_DL2", "MultiMedia2 Playback", + "MultiMedia3 Capture", "MM_UL3"; + + mm1-dai-link { + link-name = "MultiMedia0"; + cpu { + sound-dai = <&q6asmdai MSM_FRONTEND_DAI_MULTIMEDIA1>; + }; + }; + + mm2-dai-link { + link-name = "MultiMedia2"; + cpu { + sound-dai = <&q6asmdai MSM_FRONTEND_DAI_MULTIMEDIA2>; + }; + }; + + mm3-dai-link { + link-name = "MultiMedia3"; + cpu { + sound-dai = <&q6asmdai MSM_FRONTEND_DAI_MULTIMEDIA3>; + }; + }; + + hdmi-dai-link { + link-name = "HDMI Playback"; + cpu { + sound-dai = <&q6afedai TERTIARY_MI2S_RX>; + }; + + platform { + sound-dai = <&q6routing>; + }; + + codec { + sound-dai = <<9611_codec 0>; + }; + }; + + wsa-dai-link { + link-name = "WSA Playback"; + cpu { + sound-dai = <&q6afedai WSA_CODEC_DMA_RX_0>; + }; + + platform { + sound-dai = <&q6routing>; + }; + + codec { + sound-dai = <&left_spkr>, <&right_spkr>, <&swr0 0>, <&wsamacro>; + }; + }; + + va-dai-link { + link-name = "VA Capture"; + cpu { + sound-dai = <&q6afedai VA_CODEC_DMA_TX_0>; + }; + + platform { + sound-dai = <&q6routing>; + }; + + codec { + sound-dai = <&vamacro 0>; + }; + }; + }; -- cgit v1.2.3 From 49491418c1dceb11ccb2ab841e4e5590e844378c Mon Sep 17 00:00:00 2001 From: Olivier Moysan Date: Fri, 9 Oct 2020 16:10:51 +0200 Subject: ASoC: dt-bindings: stm32: convert sai to json-schema Convert the STM32 SAI bindings to DT schema format using json-schema. Signed-off-by: Olivier Moysan Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20201009141051.27365-1-olivier.moysan@st.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/st,stm32-sai.txt | 107 ----------- .../devicetree/bindings/sound/st,stm32-sai.yaml | 200 +++++++++++++++++++++ 2 files changed, 200 insertions(+), 107 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/st,stm32-sai.txt create mode 100644 Documentation/devicetree/bindings/sound/st,stm32-sai.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/st,stm32-sai.txt b/Documentation/devicetree/bindings/sound/st,stm32-sai.txt deleted file mode 100644 index c42b91e525fa..000000000000 --- a/Documentation/devicetree/bindings/sound/st,stm32-sai.txt +++ /dev/null @@ -1,107 +0,0 @@ -STMicroelectronics STM32 Serial Audio Interface (SAI). - -The SAI interface (Serial Audio Interface) offers a wide set of audio protocols -as I2S standards, LSB or MSB-justified, PCM/DSP, TDM, and AC'97. -The SAI contains two independent audio sub-blocks. Each sub-block has -its own clock generator and I/O lines controller. - -Required properties: - - compatible: Should be "st,stm32f4-sai" or "st,stm32h7-sai" - - reg: Base address and size of SAI common register set. - - clocks: Must contain phandle and clock specifier pairs for each entry - in clock-names. - - clock-names: Must contain "pclk" "x8k" and "x11k" - "pclk": Clock which feeds the peripheral bus interface. - Mandatory for "st,stm32h7-sai" compatible. - Not used for "st,stm32f4-sai" compatible. - "x8k": SAI parent clock for sampling rates multiple of 8kHz. - "x11k": SAI parent clock for sampling rates multiple of 11.025kHz. - - interrupts: cpu DAI interrupt line shared by SAI sub-blocks - -Optional properties: - - resets: Reference to a reset controller asserting the SAI - -SAI subnodes: -Two subnodes corresponding to SAI sub-block instances A et B can be defined. -Subnode can be omitted for unsused sub-block. - -SAI subnodes required properties: - - compatible: Should be "st,stm32-sai-sub-a" or "st,stm32-sai-sub-b" - for SAI sub-block A or B respectively. - - reg: Base address and size of SAI sub-block register set. - - clocks: Must contain one phandle and clock specifier pair - for sai_ck which feeds the internal clock generator. - If the SAI shares a master clock, with another SAI set as MCLK - clock provider, SAI provider phandle must be specified here. - - clock-names: Must contain "sai_ck". - Must also contain "MCLK", if SAI shares a master clock, - with a SAI set as MCLK clock provider. - - dmas: see Documentation/devicetree/bindings/dma/st,stm32-dma.yaml - - dma-names: identifier string for each DMA request line - "tx": if sai sub-block is configured as playback DAI - "rx": if sai sub-block is configured as capture DAI - - pinctrl-names: should contain only value "default" - - pinctrl-0: see Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml - -SAI subnodes Optional properties: - - st,sync: specify synchronization mode. - By default SAI sub-block is in asynchronous mode. - This property sets SAI sub-block as slave of another SAI sub-block. - Must contain the phandle and index of the sai sub-block providing - the synchronization. - - st,iec60958: support S/PDIF IEC6958 protocol for playback - IEC60958 protocol is not available for capture. - By default, custom protocol is assumed, meaning that protocol is - configured according to protocol defined in related DAI link node, - such as i2s, left justified, right justified, dsp and pdm protocols. - Note: ac97 protocol is not supported by SAI driver - - #clock-cells: should be 0. This property must be present if the SAI device - is a master clock provider, according to clocks bindings, described in - Documentation/devicetree/bindings/clock/clock-bindings.txt. - -The device node should contain one 'port' child node with one child 'endpoint' -node, according to the bindings defined in Documentation/devicetree/bindings/ -graph.txt. - -Example: -sound_card { - compatible = "audio-graph-card"; - dais = <&sai1b_port>; -}; - -sai1: sai1@40015800 { - compatible = "st,stm32h7-sai"; - #address-cells = <1>; - #size-cells = <1>; - ranges = <0 0x40015800 0x400>; - reg = <0x40015800 0x4>; - clocks = <&rcc SAI1_CK>, <&rcc PLL1_Q>, <&rcc PLL2_P>; - clock-names = "pclk", "x8k", "x11k"; - interrupts = <87>; - - sai1a: audio-controller@40015804 { - compatible = "st,stm32-sai-sub-a"; - reg = <0x4 0x1C>; - clocks = <&rcc SAI1_CK>; - clock-names = "sai_ck"; - dmas = <&dmamux1 1 87 0x400 0x0>; - dma-names = "tx"; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_sai1a>; - - sai1b_port: port { - cpu_endpoint: endpoint { - remote-endpoint = <&codec_endpoint>; - format = "i2s"; - }; - }; - }; -}; - -audio-codec { - codec_port: port { - codec_endpoint: endpoint { - remote-endpoint = <&cpu_endpoint>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml new file mode 100644 index 000000000000..6ad48c7681c1 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml @@ -0,0 +1,200 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/st,stm32-sai.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: STMicroelectronics STM32 Serial Audio Interface (SAI) + +maintainers: + - Olivier Moysan + +description: + The SAI interface (Serial Audio Interface) offers a wide set of audio + protocols as I2S standards, LSB or MSB-justified, PCM/DSP, TDM, and AC'97. + The SAI contains two independent audio sub-blocks. Each sub-block has + its own clock generator and I/O lines controller. + +properties: + compatible: + enum: + - st,stm32f4-sai + - st,stm32h7-sai + + reg: + items: + - description: Base address and size of SAI common register set. + - description: Base address and size of SAI identification register set. + minItems: 1 + maxItems: 2 + + ranges: + maxItems: 1 + + interrupts: + maxItems: 1 + + resets: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + clocks: + maxItems: 3 + + clock-names: + maxItems: 3 + +required: + - compatible + - reg + - ranges + - "#address-cells" + - "#size-cells" + - clocks + - clock-names + +patternProperties: + "^audio-controller@[0-9a-f]+$": + type: object + description: + Two subnodes corresponding to SAI sub-block instances A et B + can be defined. Subnode can be omitted for unsused sub-block. + + properties: + compatible: + description: Compatible for SAI sub-block A or B. + pattern: "st,stm32-sai-sub-[ab]" + + "#sound-dai-cells": + const: 0 + + reg: + maxItems: 1 + + clocks: + items: + - description: sai_ck clock feeding the internal clock generator. + - description: MCLK clock from a SAI set as master clock provider. + minItems: 1 + maxItems: 2 + + clock-names: + items: + - const: sai_ck + - const: MCLK + minItems: 1 + maxItems: 2 + + dmas: + maxItems: 1 + + dma-names: + description: | + rx: SAI sub-block is configured as a capture DAI. + tx: SAI sub-block is configured as a playback DAI. + enum: [ rx, tx ] + + st,sync: + description: + Configure the SAI sub-block as slave of another SAI sub-block. + By default SAI sub-block is in asynchronous mode. + Must contain the phandle and index of the SAI sub-block providing + the synchronization. + allOf: + - $ref: /schemas/types.yaml#definitions/phandle-array + - maxItems: 1 + + st,iec60958: + description: + If set, support S/PDIF IEC6958 protocol for playback. + IEC60958 protocol is not available for capture. + By default, custom protocol is assumed, meaning that protocol is + configured according to protocol defined in related DAI link node, + such as i2s, left justified, right justified, dsp and pdm protocols. + allOf: + - $ref: /schemas/types.yaml#definitions/flag + + "#clock-cells": + description: Configure the SAI device as master clock provider. + const: 0 + + required: + - compatible + - "#sound-dai-cells" + - reg + - clocks + - clock-names + - dmas + - dma-names + +allOf: + - if: + properties: + compatible: + contains: + const: st,stm32f4-sai + + - then: + properties: + clocks: + items: + - description: x8k, SAI parent clock for sampling rates multiple of 8kHz. + - description: x11k, SAI parent clock for sampling rates multiple of 11.025kHz. + + clock-names: + items: + - const: x8k + - const: x11k + + - else: + properties: + clocks: + items: + - description: pclk feeds the peripheral bus interface. + - description: x8k, SAI parent clock for sampling rates multiple of 8kHz. + - description: x11k, SAI parent clock for sampling rates multiple of 11.025kHz. + + clock-names: + items: + - const: pclk + - const: x8k + - const: x11k + +additionalProperties: false + +examples: + - | + #include + #include + #include + sai2: sai@4400b000 { + compatible = "st,stm32h7-sai"; + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x4400b000 0x400>; + reg = <0x4400b000 0x4>, <0x4400b3f0 0x10>; + clocks = <&rcc SAI2>, <&rcc PLL3_Q>, <&rcc PLL3_R>; + clock-names = "pclk", "x8k", "x11k"; + pinctrl-names = "default", "sleep"; + pinctrl-0 = <&sai2a_pins_a>, <&sai2b_pins_b>; + pinctrl-1 = <&sai2a_sleep_pins_a>, <&sai2b_sleep_pins_b>; + status = "okay"; + + sai2a: audio-controller@4400b004 { + #sound-dai-cells = <0>; + compatible = "st,stm32-sai-sub-a"; + reg = <0x4 0x1c>; + dmas = <&dmamux1 89 0x400 0x01>; + dma-names = "tx"; + clocks = <&rcc SAI2_K>; + clock-names = "sai_ck"; + status = "okay"; + }; + }; + +... -- cgit v1.2.3 From 87b2fc1139a13cf81d0a95fb2cbaba7daeee8908 Mon Sep 17 00:00:00 2001 From: Shengjiu Wang Date: Thu, 15 Oct 2020 13:28:47 +0800 Subject: ASoC: dt-bindings: fsl_spdif: Add new compatible string for i.MX8QM Add new compatible string "fsl,imx8qm-spdif" for supporting spdif module on i.MX8QM. Signed-off-by: Shengjiu Wang Acked-by: Rob Herring Link: https://lore.kernel.org/r/1602739728-4433-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/fsl,spdif.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/fsl,spdif.yaml b/Documentation/devicetree/bindings/sound/fsl,spdif.yaml index 2ac671f5cb9b..50449b6d1048 100644 --- a/Documentation/devicetree/bindings/sound/fsl,spdif.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,spdif.yaml @@ -20,6 +20,7 @@ properties: - fsl,imx35-spdif - fsl,vf610-spdif - fsl,imx6sx-spdif + - fsl,imx8qm-spdif reg: maxItems: 1 -- cgit v1.2.3 From f0b62039bf7f998fb3f1369ac70dbe571c74f9d8 Mon Sep 17 00:00:00 2001 From: SeongJae Park Date: Wed, 21 Oct 2020 21:25:18 +0200 Subject: Documentation: kunit: Update Kconfig parts for KUNIT's module support If 'CONFIG_KUNIT=m', letting kunit tests that do not support loadable module build depends on 'KUNIT' instead of 'KUNIT=y' result in compile errors. This commit updates the document for this. Fixes: 9fe124bf1b77 ("kunit: allow kunit to be loaded as a module") Signed-off-by: SeongJae Park Reviewed-by: David Gow Reviewed-by: Brendan Higgins Signed-off-by: Shuah Khan --- Documentation/dev-tools/kunit/start.rst | 2 +- Documentation/dev-tools/kunit/usage.rst | 5 +++++ 2 files changed, 6 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/kunit/start.rst b/Documentation/dev-tools/kunit/start.rst index d23385e3e159..454f307813ea 100644 --- a/Documentation/dev-tools/kunit/start.rst +++ b/Documentation/dev-tools/kunit/start.rst @@ -197,7 +197,7 @@ Now add the following to ``drivers/misc/Kconfig``: config MISC_EXAMPLE_TEST bool "Test for my example" - depends on MISC_EXAMPLE && KUNIT + depends on MISC_EXAMPLE && KUNIT=y and the following to ``drivers/misc/Makefile``: diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst index 961d3ea3ca19..62142a47488c 100644 --- a/Documentation/dev-tools/kunit/usage.rst +++ b/Documentation/dev-tools/kunit/usage.rst @@ -561,6 +561,11 @@ Once the kernel is built and installed, a simple ...will run the tests. +.. note:: + Note that you should make sure your test depends on ``KUNIT=y`` in Kconfig + if the test does not support module build. Otherwise, it will trigger + compile errors if ``CONFIG_KUNIT`` is ``m``. + Writing new tests for other architectures ----------------------------------------- -- cgit v1.2.3 From 434ee425195097865acc42744cfd0d73f5395cef Mon Sep 17 00:00:00 2001 From: Shyam Sundar Date: Wed, 21 Oct 2020 02:27:15 -0700 Subject: scsi: fc: Update documentation of sysfs nodes for FPIN stats Update documentation for sysfs nodes within: /sys/class/fc_host /sys/class/fc_remote_ports Link: https://lore.kernel.org/r/20201021092715.22669-6-njavali@marvell.com Reviewed-by: James Smart Reviewed-by: Himanshu Madhani Signed-off-by: Shyam Sundar Signed-off-by: Nilesh Javali Signed-off-by: Martin K. Petersen --- Documentation/ABI/testing/sysfs-class-fc_host | 23 ++++++++++++++++++++++ .../ABI/testing/sysfs-class-fc_remote_ports | 23 ++++++++++++++++++++++ 2 files changed, 46 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-fc_host create mode 100644 Documentation/ABI/testing/sysfs-class-fc_remote_ports (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-class-fc_host b/Documentation/ABI/testing/sysfs-class-fc_host new file mode 100644 index 000000000000..0a696cbd8232 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-fc_host @@ -0,0 +1,23 @@ +What: /sys/class/fc_host/hostX/statistics/fpin_cn_yyy +Date: July 2020 +Contact: Shyam Sundar +Description: + These files contain the number of congestion notification + events recorded by the F_Port, reported using fabric + performance impact notification (FPIN) event. + +What: /sys/class/fc_host/hostX/statistics/fpin_li_yyy +Date: July 2020 +Contact: Shyam Sundar +Description: + These files contain the number of link integrity error + events recorded by the F_Port/Nx_Port, reported using fabric + performance impact notification (FPIN) event. + +What: /sys/class/fc_host/hostX/statistics/fpin_dn_yyy +Date: July 2020 +Contact: Shyam Sundar +Description: + These files contain the number of delivery related errors + recorded by the F_Port/Nx_Port, reported using fabric + performance impact notification (FPIN) event. diff --git a/Documentation/ABI/testing/sysfs-class-fc_remote_ports b/Documentation/ABI/testing/sysfs-class-fc_remote_ports new file mode 100644 index 000000000000..55a951529e03 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-fc_remote_ports @@ -0,0 +1,23 @@ +What: /sys/class/fc_remote_ports/rport-X:Y-Z/statistics/fpin_cn_yyy +Date: July 2020 +Contact: Shyam Sundar +Description: + These files contain the number of congestion notification + events recorded by the F_Port/Nx_Port, reported using fabric + performance impact notification (FPIN) event. + +What: /sys/class/fc_remote_ports/rport-X:Y-Z/statistics/fpin_li_yyy +Date: July 2020 +Contact: Shyam Sundar +Description: + These files contain the number of link integrity error + events recorded by the F_Port/Nx_Port, reported using fabric + performance impact notification (FPIN) event. + +What: /sys/class/fc_remote_ports/rport-X:Y-Z/statistics/fpin_dn_yyy +Date: July 2020 +Contact: Shyam Sundar +Description: + These files contain the number of delivery related errors + recorded by the F_Port/Nx_Port, reported using fabric + performance impact notification (FPIN) event. -- cgit v1.2.3 From 11b3de087a1cae288f2cf345457bc7a7f97c7aa3 Mon Sep 17 00:00:00 2001 From: Mike Looijmans Date: Mon, 26 Oct 2020 17:32:43 +0100 Subject: dt-bindings: gpio: pca953x: Add support for the NXP PCAL9554B/C The NXP PCAL9554B is a variant of the PCA953x GPIO expander, with 8 GPIOs, latched interrupts and some advanced configuration options. The "C" version only differs in I2C address. This adds the entry to the devicetree bindings. Signed-off-by: Mike Looijmans Acked-by: Rob Herring Reviewed-by: Linus Walleij Signed-off-by: Bartosz Golaszewski --- Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml b/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml index 183ec23eda39..f5ee23c2df60 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml +++ b/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml @@ -48,6 +48,7 @@ properties: - nxp,pcal6416 - nxp,pcal6524 - nxp,pcal9535 + - nxp,pcal9554b - nxp,pcal9555a - onnn,cat9554 - onnn,pca9654 -- cgit v1.2.3 From 7d18e2f3f29763e0714733f0e0689f14de4faa03 Mon Sep 17 00:00:00 2001 From: Daniel Vetter Date: Fri, 23 Oct 2020 14:39:25 +0200 Subject: drm/doc: Document legacy_cursor_update better It's the horror and shouldn't be used. Realized we're not clear on this in a discussion with Rob about what msm is doing to better support async commits. v2: Refine existing todo item to include this (Thomas) Cc: Sean Paul Cc: Rob Clark Acked-by: Rob Clark Signed-off-by: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20201023123925.2374863-3-daniel.vetter@ffwll.ch --- Documentation/gpu/todo.rst | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 700637e25ecd..6b224ef14455 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -105,6 +105,10 @@ converted over to the new infrastructure. One issue with the helpers is that they require that drivers handle completion events for atomic commits correctly. But fixing these bugs is good anyway. +Somewhat related is the legacy_cursor_update hack, which should be replaced with +the new atomic_async_check/commit functionality in the helpers in drivers that +still look at that flag. + Contact: Daniel Vetter, respective driver maintainers Level: Advanced -- cgit v1.2.3 From 07df39d03c34bd7baf4c26e41a5dd92ec56e9081 Mon Sep 17 00:00:00 2001 From: Fabien Parent Date: Wed, 21 Oct 2020 18:42:29 +0200 Subject: dt-bindings: thermal: mediatek: make resets property optional MT8516 Thermal IP does not support reset. Make the resets property optional in order to be able to support MT8516 SoC. Signed-off-by: Fabien Parent Acked-by: Rob Herring Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20201021164231.3029956-1-fparent@baylibre.com --- Documentation/devicetree/bindings/thermal/mediatek-thermal.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt index 1e249c42fae0..2d20f6b0dca0 100644 --- a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt @@ -20,12 +20,12 @@ Required properties: clocks are: "therm": Main clock needed for register access "auxadc": The AUXADC clock -- resets: Reference to the reset controller controlling the thermal controller. - mediatek,auxadc: A phandle to the AUXADC which the thermal controller uses - mediatek,apmixedsys: A phandle to the APMIXEDSYS controller. - #thermal-sensor-cells : Should be 0. See Documentation/devicetree/bindings/thermal/thermal-sensor.yaml for a description. Optional properties: +- resets: Reference to the reset controller controlling the thermal controller. - nvmem-cells: A phandle to the calibration data provided by a nvmem device. If unspecified default values shall be used. - nvmem-cell-names: Should be "calibration-data" -- cgit v1.2.3 From c707f973df1706020f4a4669b5f1932e90c0f29c Mon Sep 17 00:00:00 2001 From: Fabien Parent Date: Wed, 21 Oct 2020 18:42:30 +0200 Subject: dt-bindings: thermal: mediatek: add documentation for MT8516 SoC Add binding documentation for the MediaTek MT8516 SoC. The SoC thermal IP is similar to MT2701. Signed-off-by: Fabien Parent Acked-by: Rob Herring Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20201021164231.3029956-2-fparent@baylibre.com --- Documentation/devicetree/bindings/thermal/mediatek-thermal.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt index 2d20f6b0dca0..5c7e7bdd029a 100644 --- a/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt +++ b/Documentation/devicetree/bindings/thermal/mediatek-thermal.txt @@ -14,6 +14,7 @@ Required properties: - "mediatek,mt2712-thermal" : For MT2712 family of SoCs - "mediatek,mt7622-thermal" : For MT7622 SoC - "mediatek,mt8183-thermal" : For MT8183 family of SoCs + - "mediatek,mt8516-thermal", "mediatek,mt2701-thermal : For MT8516 family of SoCs - reg: Address range of the thermal controller - interrupts: IRQ for the thermal controller - clocks, clock-names: Clocks needed for the thermal controller. required -- cgit v1.2.3 From 673a8c4f8517ea624cd838f7f2246b6990190770 Mon Sep 17 00:00:00 2001 From: Tiezhu Yang Date: Tue, 13 Oct 2020 13:55:02 +0800 Subject: Documentation: ABI: Add /sys/firmware/lefi/boardinfo description for Loongson64 Add a description for /sys/firmware/lefi/boardinfo on the Loongson platform. Signed-off-by: Tiezhu Yang Signed-off-by: Thomas Bogendoerfer --- .../ABI/testing/sysfs-firmware-lefi-boardinfo | 35 ++++++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-firmware-lefi-boardinfo (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-firmware-lefi-boardinfo b/Documentation/ABI/testing/sysfs-firmware-lefi-boardinfo new file mode 100644 index 000000000000..5e3f6148c52e --- /dev/null +++ b/Documentation/ABI/testing/sysfs-firmware-lefi-boardinfo @@ -0,0 +1,35 @@ +What: /sys/firmware/lefi/boardinfo +Date: October 2020 +Contact: Tiezhu Yang +Description: + Get mainboard and BIOS info easily on the Loongson platform, + this is useful to point out the current used mainboard type + and BIOS version when there exists problems related with + hardware or firmware. + + The related structures are already defined in the interface + specification about firmware and kernel which are common + requirement and specific for Loongson64, so only add a new + boardinfo.c file in arch/mips/loongson64. + + For example: + + [loongson@linux ~]$ cat /sys/firmware/lefi/boardinfo + Board Info + Manufacturer : LEMOTE + Board Name : LEMOTE-LS3A4000-7A1000-1w-V01-pc + Family : LOONGSON3 + + BIOS Info + Vendor : Kunlun + Version : Kunlun-A1901-V4.1.3-20200414093938 + ROM Size : 4 KB + Release Date : 2020-04-14 + + By the way, using dmidecode command can get the similar info if there + exists SMBIOS in firmware, but the fact is that there is no SMBIOS on + some machines, we can see nothing when execute dmidecode, like this: + + [root@linux loongson]# dmidecode + # dmidecode 2.12 + # No SMBIOS nor DMI entry point found, sorry. -- cgit v1.2.3 From 7a1be318f5795cb66fa0dc86b3ace427fe68057f Mon Sep 17 00:00:00 2001 From: Ard Biesheuvel Date: Sun, 11 Oct 2020 10:21:37 +0100 Subject: ARM: 9012/1: move device tree mapping out of linear region On ARM, setting up the linear region is tricky, given the constraints around placement and alignment of the memblocks, and how the kernel itself as well as the DT are placed in physical memory. Let's simplify matters a bit, by moving the device tree mapping to the top of the address space, right between the end of the vmalloc region and the start of the the fixmap region, and create a read-only mapping for it that is independent of the size of the linear region, and how it is organized. Since this region was formerly used as a guard region, which will now be populated fully on LPAE builds by this read-only mapping (which will still be able to function as a guard region for stray writes), bump the start of the [underutilized] fixmap region by 512 KB as well, to ensure that there is always a proper guard region here. Doing so still leaves ample room for the fixmap space, even with NR_CPUS set to its maximum value of 32. Tested-by: Linus Walleij Reviewed-by: Linus Walleij Reviewed-by: Nicolas Pitre Signed-off-by: Ard Biesheuvel Signed-off-by: Russell King --- Documentation/arm/memory.rst | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/arm/memory.rst b/Documentation/arm/memory.rst index 0521b4ce5c96..34bb23c44a71 100644 --- a/Documentation/arm/memory.rst +++ b/Documentation/arm/memory.rst @@ -45,9 +45,14 @@ fffe8000 fffeffff DTCM mapping area for platforms with fffe0000 fffe7fff ITCM mapping area for platforms with ITCM mounted inside the CPU. -ffc00000 ffefffff Fixmap mapping region. Addresses provided +ffc80000 ffefffff Fixmap mapping region. Addresses provided by fix_to_virt() will be located here. +ffc00000 ffc7ffff Guard region + +ff800000 ffbfffff Permanent, fixed read-only mapping of the + firmware provided DT blob + fee00000 feffffff Mapping of PCI I/O space. This is a static mapping within the vmalloc space. -- cgit v1.2.3 From c12366ba441da2f6f2b915410aca2b5b39c16514 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Sun, 25 Oct 2020 23:53:46 +0100 Subject: ARM: 9015/2: Define the virtual space of KASan's shadow region Define KASAN_SHADOW_OFFSET,KASAN_SHADOW_START and KASAN_SHADOW_END for the Arm kernel address sanitizer. We are "stealing" lowmem (the 4GB addressable by a 32bit architecture) out of the virtual address space to use as shadow memory for KASan as follows: +----+ 0xffffffff | | | | |-> Static kernel image (vmlinux) BSS and page table | |/ +----+ PAGE_OFFSET | | | | |-> Loadable kernel modules virtual address space area | |/ +----+ MODULES_VADDR = KASAN_SHADOW_END | | | | |-> The shadow area of kernel virtual address. | |/ +----+-> TASK_SIZE (start of kernel space) = KASAN_SHADOW_START the | | shadow address of MODULES_VADDR | | | | | | | | |-> The user space area in lowmem. The kernel address | | | sanitizer do not use this space, nor does it map it. | | | | | | | | | | | | | |/ ------ 0 0 .. TASK_SIZE is the memory that can be used by shared userspace/kernelspace. It us used for userspace processes and for passing parameters and memory buffers in system calls etc. We do not need to shadow this area. KASAN_SHADOW_START: This value begins with the MODULE_VADDR's shadow address. It is the start of kernel virtual space. Since we have modules to load, we need to cover also that area with shadow memory so we can find memory bugs in modules. KASAN_SHADOW_END This value is the 0x100000000's shadow address: the mapping that would be after the end of the kernel memory at 0xffffffff. It is the end of kernel address sanitizer shadow area. It is also the start of the module area. KASAN_SHADOW_OFFSET: This value is used to map an address to the corresponding shadow address by the following formula: shadow_addr = (address >> 3) + KASAN_SHADOW_OFFSET; As you would expect, >> 3 is equal to dividing by 8, meaning each byte in the shadow memory covers 8 bytes of kernel memory, so one bit shadow memory per byte of kernel memory is used. The KASAN_SHADOW_OFFSET is provided in a Kconfig option depending on the VMSPLIT layout of the system: the kernel and userspace can split up lowmem in different ways according to needs, so we calculate the shadow offset depending on this. When kasan is enabled, the definition of TASK_SIZE is not an 8-bit rotated constant, so we need to modify the TASK_SIZE access code in the *.s file. The kernel and modules may use different amounts of memory, according to the VMSPLIT configuration, which in turn determines the PAGE_OFFSET. We use the following KASAN_SHADOW_OFFSETs depending on how the virtual memory is split up: - 0x1f000000 if we have 1G userspace / 3G kernelspace split: - The kernel address space is 3G (0xc0000000) - PAGE_OFFSET is then set to 0x40000000 so the kernel static image (vmlinux) uses addresses 0x40000000 .. 0xffffffff - On top of that we have the MODULES_VADDR which under the worst case (using ARM instructions) is PAGE_OFFSET - 16M (0x01000000) = 0x3f000000 so the modules use addresses 0x3f000000 .. 0x3fffffff - So the addresses 0x3f000000 .. 0xffffffff need to be covered with shadow memory. That is 0xc1000000 bytes of memory. - 1/8 of that is needed for its shadow memory, so 0x18200000 bytes of shadow memory is needed. We "steal" that from the remaining lowmem. - The KASAN_SHADOW_START becomes 0x26e00000, to KASAN_SHADOW_END at 0x3effffff. - Now we can calculate the KASAN_SHADOW_OFFSET for any kernel address as 0x3f000000 needs to map to the first byte of shadow memory and 0xffffffff needs to map to the last byte of shadow memory. Since: SHADOW_ADDR = (address >> 3) + KASAN_SHADOW_OFFSET 0x26e00000 = (0x3f000000 >> 3) + KASAN_SHADOW_OFFSET KASAN_SHADOW_OFFSET = 0x26e00000 - (0x3f000000 >> 3) KASAN_SHADOW_OFFSET = 0x26e00000 - 0x07e00000 KASAN_SHADOW_OFFSET = 0x1f000000 - 0x5f000000 if we have 2G userspace / 2G kernelspace split: - The kernel space is 2G (0x80000000) - PAGE_OFFSET is set to 0x80000000 so the kernel static image uses 0x80000000 .. 0xffffffff. - On top of that we have the MODULES_VADDR which under the worst case (using ARM instructions) is PAGE_OFFSET - 16M (0x01000000) = 0x7f000000 so the modules use addresses 0x7f000000 .. 0x7fffffff - So the addresses 0x7f000000 .. 0xffffffff need to be covered with shadow memory. That is 0x81000000 bytes of memory. - 1/8 of that is needed for its shadow memory, so 0x10200000 bytes of shadow memory is needed. We "steal" that from the remaining lowmem. - The KASAN_SHADOW_START becomes 0x6ee00000, to KASAN_SHADOW_END at 0x7effffff. - Now we can calculate the KASAN_SHADOW_OFFSET for any kernel address as 0x7f000000 needs to map to the first byte of shadow memory and 0xffffffff needs to map to the last byte of shadow memory. Since: SHADOW_ADDR = (address >> 3) + KASAN_SHADOW_OFFSET 0x6ee00000 = (0x7f000000 >> 3) + KASAN_SHADOW_OFFSET KASAN_SHADOW_OFFSET = 0x6ee00000 - (0x7f000000 >> 3) KASAN_SHADOW_OFFSET = 0x6ee00000 - 0x0fe00000 KASAN_SHADOW_OFFSET = 0x5f000000 - 0x9f000000 if we have 3G userspace / 1G kernelspace split, and this is the default split for ARM: - The kernel address space is 1GB (0x40000000) - PAGE_OFFSET is set to 0xc0000000 so the kernel static image uses 0xc0000000 .. 0xffffffff. - On top of that we have the MODULES_VADDR which under the worst case (using ARM instructions) is PAGE_OFFSET - 16M (0x01000000) = 0xbf000000 so the modules use addresses 0xbf000000 .. 0xbfffffff - So the addresses 0xbf000000 .. 0xffffffff need to be covered with shadow memory. That is 0x41000000 bytes of memory. - 1/8 of that is needed for its shadow memory, so 0x08200000 bytes of shadow memory is needed. We "steal" that from the remaining lowmem. - The KASAN_SHADOW_START becomes 0xb6e00000, to KASAN_SHADOW_END at 0xbfffffff. - Now we can calculate the KASAN_SHADOW_OFFSET for any kernel address as 0xbf000000 needs to map to the first byte of shadow memory and 0xffffffff needs to map to the last byte of shadow memory. Since: SHADOW_ADDR = (address >> 3) + KASAN_SHADOW_OFFSET 0xb6e00000 = (0xbf000000 >> 3) + KASAN_SHADOW_OFFSET KASAN_SHADOW_OFFSET = 0xb6e00000 - (0xbf000000 >> 3) KASAN_SHADOW_OFFSET = 0xb6e00000 - 0x17e00000 KASAN_SHADOW_OFFSET = 0x9f000000 - 0x8f000000 if we have 3G userspace / 1G kernelspace with full 1 GB low memory (VMSPLIT_3G_OPT): - The kernel address space is 1GB (0x40000000) - PAGE_OFFSET is set to 0xb0000000 so the kernel static image uses 0xb0000000 .. 0xffffffff. - On top of that we have the MODULES_VADDR which under the worst case (using ARM instructions) is PAGE_OFFSET - 16M (0x01000000) = 0xaf000000 so the modules use addresses 0xaf000000 .. 0xaffffff - So the addresses 0xaf000000 .. 0xffffffff need to be covered with shadow memory. That is 0x51000000 bytes of memory. - 1/8 of that is needed for its shadow memory, so 0x0a200000 bytes of shadow memory is needed. We "steal" that from the remaining lowmem. - The KASAN_SHADOW_START becomes 0xa4e00000, to KASAN_SHADOW_END at 0xaeffffff. - Now we can calculate the KASAN_SHADOW_OFFSET for any kernel address as 0xaf000000 needs to map to the first byte of shadow memory and 0xffffffff needs to map to the last byte of shadow memory. Since: SHADOW_ADDR = (address >> 3) + KASAN_SHADOW_OFFSET 0xa4e00000 = (0xaf000000 >> 3) + KASAN_SHADOW_OFFSET KASAN_SHADOW_OFFSET = 0xa4e00000 - (0xaf000000 >> 3) KASAN_SHADOW_OFFSET = 0xa4e00000 - 0x15e00000 KASAN_SHADOW_OFFSET = 0x8f000000 - The default value of 0xffffffff for KASAN_SHADOW_OFFSET is an error value. We should always match one of the above shadow offsets. When we do this, TASK_SIZE will sometimes get a bit odd values that will not fit into immediate mov assembly instructions. To account for this, we need to rewrite some assembly using TASK_SIZE like this: - mov r1, #TASK_SIZE + ldr r1, =TASK_SIZE or - cmp r4, #TASK_SIZE + ldr r0, =TASK_SIZE + cmp r4, r0 this is done to avoid the immediate #TASK_SIZE that need to fit into a limited number of bits. Cc: Andrey Ryabinin Cc: Alexander Potapenko Cc: Dmitry Vyukov Cc: kasan-dev@googlegroups.com Cc: Mike Rapoport Reviewed-by: Ard Biesheuvel Tested-by: Ard Biesheuvel # QEMU/KVM/mach-virt/LPAE/8G Tested-by: Florian Fainelli # Brahma SoCs Tested-by: Ahmad Fatoum # i.MX6Q Reported-by: Ard Biesheuvel Signed-off-by: Abbott Liu Signed-off-by: Florian Fainelli Signed-off-by: Linus Walleij Signed-off-by: Russell King --- Documentation/arm/memory.rst | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/arm/memory.rst b/Documentation/arm/memory.rst index 34bb23c44a71..0cb1e2938823 100644 --- a/Documentation/arm/memory.rst +++ b/Documentation/arm/memory.rst @@ -77,6 +77,11 @@ MODULES_VADDR MODULES_END-1 Kernel module space Kernel modules inserted via insmod are placed here using dynamic mappings. +TASK_SIZE MODULES_VADDR-1 KASAn shadow memory when KASan is in use. + The range from MODULES_VADDR to the top + of the memory is shadowed here with 1 bit + per byte of memory. + 00001000 TASK_SIZE-1 User space mappings Per-thread mappings are placed here via the mmap() system call. -- cgit v1.2.3 From 421015713b306e47af95d4d61cdfbd96d462e4cb Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Sun, 25 Oct 2020 23:56:18 +0100 Subject: ARM: 9017/2: Enable KASan for ARM This patch enables the kernel address sanitizer for ARM. XIP_KERNEL has not been tested and is therefore not allowed for now. Cc: Andrey Ryabinin Cc: Alexander Potapenko Cc: Dmitry Vyukov Cc: kasan-dev@googlegroups.com Acked-by: Dmitry Vyukov Reviewed-by: Ard Biesheuvel Tested-by: Ard Biesheuvel # QEMU/KVM/mach-virt/LPAE/8G Tested-by: Florian Fainelli # Brahma SoCs Tested-by: Ahmad Fatoum # i.MX6Q Signed-off-by: Abbott Liu Signed-off-by: Florian Fainelli Signed-off-by: Linus Walleij Signed-off-by: Russell King --- Documentation/dev-tools/kasan.rst | 4 ++-- Documentation/features/debug/KASAN/arch-support.txt | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst index c09c9ca2ff1c..3edd3946d4c7 100644 --- a/Documentation/dev-tools/kasan.rst +++ b/Documentation/dev-tools/kasan.rst @@ -18,8 +18,8 @@ out-of-bounds accesses for global variables is only supported since Clang 11. Tag-based KASAN is only supported in Clang. -Currently generic KASAN is supported for the x86_64, arm64, xtensa, s390 and -riscv architectures, and tag-based KASAN is supported only for arm64. +Currently generic KASAN is supported for the x86_64, arm, arm64, xtensa, s390 +and riscv architectures, and tag-based KASAN is supported only for arm64. Usage ----- diff --git a/Documentation/features/debug/KASAN/arch-support.txt b/Documentation/features/debug/KASAN/arch-support.txt index c3fe9b266e7b..b2288dc14b72 100644 --- a/Documentation/features/debug/KASAN/arch-support.txt +++ b/Documentation/features/debug/KASAN/arch-support.txt @@ -8,7 +8,7 @@ ----------------------- | alpha: | TODO | | arc: | TODO | - | arm: | TODO | + | arm: | ok | | arm64: | ok | | c6x: | TODO | | csky: | TODO | -- cgit v1.2.3 From e158d2d83cab59ec7f4661548627ac171c797c9d Mon Sep 17 00:00:00 2001 From: Cheng-Yi Chiang Date: Tue, 27 Oct 2020 11:22:33 +0800 Subject: ASoC: google: dt-bindings: Add sc7180-trogdor machine bindings Add devicetree bindings documentation file for sc7180 sound card. Signed-off-by: Cheng-Yi Chiang Reviewed-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20201027032234.1705835-2-cychiang@chromium.org Signed-off-by: Mark Brown --- .../bindings/sound/google,sc7180-trogdor.yaml | 130 +++++++++++++++++++++ 1 file changed, 130 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml b/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml new file mode 100644 index 000000000000..efc34689d6b5 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml @@ -0,0 +1,130 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/google,sc7180-trogdor.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Google SC7180-Trogdor ASoC sound card driver + +maintainers: + - Rohit kumar + - Cheng-Yi Chiang + +description: + This binding describes the SC7180 sound card which uses LPASS for audio. + +properties: + compatible: + const: google,sc7180-trogdor + + audio-routing: + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + description: + A list of the connections between audio components. Each entry is a + pair of strings, the first being the connection's sink, the second + being the connection's source. + + model: + $ref: /schemas/types.yaml#/definitions/string + description: User specified audio sound card name + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "^dai-link(@[0-9])?$": + description: + Each subnode represents a dai link. Subnodes of each dai links would be + cpu/codec dais. + + type: object + + properties: + link-name: + description: Indicates dai-link name and PCM stream name. + $ref: /schemas/types.yaml#/definitions/string + maxItems: 1 + + reg: + description: dai link address. + + cpu: + description: Holds subnode which indicates cpu dai. + type: object + properties: + sound-dai: true + + codec: + description: Holds subnode which indicates codec dai. + type: object + properties: + sound-dai: true + + required: + - link-name + - cpu + - codec + + additionalProperties: false + +required: + - compatible + - model + - "#address-cells" + - "#size-cells" + +additionalProperties: false + +examples: + + - | + sound { + compatible = "google,sc7180-trogdor"; + model = "sc7180-rt5682-max98357a-1mic"; + + audio-routing = + "Headphone Jack", "HPOL", + "Headphone Jack", "HPOR"; + + #address-cells = <1>; + #size-cells = <0>; + + dai-link@0 { + link-name = "MultiMedia0"; + reg = <0>; + cpu { + sound-dai = <&lpass_cpu 0>; + }; + + codec { + sound-dai = <&alc5682 0>; + }; + }; + + dai-link@1 { + link-name = "MultiMedia1"; + reg = <1>; + cpu { + sound-dai = <&lpass_cpu 1>; + }; + + codec { + sound-dai = <&max98357a>; + }; + }; + + dai-link@2 { + link-name = "MultiMedia2"; + reg = <2>; + cpu { + sound-dai = <&lpass_hdmi 0>; + }; + + codec { + sound-dai = <&msm_dp>; + }; + }; + }; -- cgit v1.2.3 From fa769f29f12419db48f4e447e2da9719cc83f3e8 Mon Sep 17 00:00:00 2001 From: Yu-Tung Chang Date: Mon, 26 Oct 2020 15:35:36 +0800 Subject: ARM: dts: sun8i: add FriendlyArm ZeroPi support The ZeroPi is another fun board developed by FriendlyELEC for makers, hobbyists and fans. ZeroPi key features - Allwinner H3, Quad-core Cortex-A7@1.2GHz - 256MB/512MB DDR3 RAM - microsd slot - 10/100/1000Mbps Ethernet - Debug Serial Port - DC 5V/2A power-supply Signed-off-by: Yu-Tung Chang Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20201026073536.13617-2-mtwget@gmail.com --- Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index afa00268c7db..0f23133672a3 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -251,6 +251,11 @@ properties: - const: friendlyarm,nanopi-neo-plus2 - const: allwinner,sun50i-h5 + - description: FriendlyARM ZeroPi + items: + - const: friendlyarm,zeropi + - const: allwinner,sun8i-h3 + - description: Gemei G9 Tablet items: - const: gemei,g9 -- cgit v1.2.3 From d1b22e36e3188f47dbf8aaef54d9e79df8e91f4c Mon Sep 17 00:00:00 2001 From: Fenghua Yu Date: Wed, 14 Oct 2020 00:49:26 +0000 Subject: Documentation/x86: Rename resctrl_ui.rst and add two errata to the file Intel Memory Bandwidth Monitoring (MBM) counters may report system memory bandwidth incorrectly on some Intel processors. This is reported in documented in erratum SKX99, erratum BDF102 and in the RDT reference manual, see Documentation/x86/index.rst. To work around the errata, MBM total and local readings are corrected using a correction factor table. Since the correction factor table is not publicly documented anywhere, document the table and the errata in Documentation/x86/resctrl.rst for future reference. [ bp: Move web links to the doc, massage. ] Suggested-by: Borislav Petkov Signed-off-by: Fenghua Yu Signed-off-by: Borislav Petkov Reviewed-by: Tony Luck Link: https://lkml.kernel.org/r/20201014004927.1839452-2-fenghua.yu@intel.com --- Documentation/x86/index.rst | 2 +- Documentation/x86/resctrl.rst | 1304 ++++++++++++++++++++++++++++++++++++++ Documentation/x86/resctrl_ui.rst | 1211 ----------------------------------- 3 files changed, 1305 insertions(+), 1212 deletions(-) create mode 100644 Documentation/x86/resctrl.rst delete mode 100644 Documentation/x86/resctrl_ui.rst (limited to 'Documentation') diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst index b224d12c880b..9c6ebf355f81 100644 --- a/Documentation/x86/index.rst +++ b/Documentation/x86/index.rst @@ -27,7 +27,7 @@ x86-specific Documentation pti mds microcode - resctrl_ui + resctrl tsx_async_abort usb-legacy-support i386/index diff --git a/Documentation/x86/resctrl.rst b/Documentation/x86/resctrl.rst new file mode 100644 index 000000000000..71a531061e4e --- /dev/null +++ b/Documentation/x86/resctrl.rst @@ -0,0 +1,1304 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: + +=========================================== +User Interface for Resource Control feature +=========================================== + +:Copyright: |copy| 2016 Intel Corporation +:Authors: - Fenghua Yu + - Tony Luck + - Vikas Shivappa + + +Intel refers to this feature as Intel Resource Director Technology(Intel(R) RDT). +AMD refers to this feature as AMD Platform Quality of Service(AMD QoS). + +This feature is enabled by the CONFIG_X86_CPU_RESCTRL and the x86 /proc/cpuinfo +flag bits: + +============================================= ================================ +RDT (Resource Director Technology) Allocation "rdt_a" +CAT (Cache Allocation Technology) "cat_l3", "cat_l2" +CDP (Code and Data Prioritization) "cdp_l3", "cdp_l2" +CQM (Cache QoS Monitoring) "cqm_llc", "cqm_occup_llc" +MBM (Memory Bandwidth Monitoring) "cqm_mbm_total", "cqm_mbm_local" +MBA (Memory Bandwidth Allocation) "mba" +============================================= ================================ + +To use the feature mount the file system:: + + # mount -t resctrl resctrl [-o cdp[,cdpl2][,mba_MBps]] /sys/fs/resctrl + +mount options are: + +"cdp": + Enable code/data prioritization in L3 cache allocations. +"cdpl2": + Enable code/data prioritization in L2 cache allocations. +"mba_MBps": + Enable the MBA Software Controller(mba_sc) to specify MBA + bandwidth in MBps + +L2 and L3 CDP are controlled separately. + +RDT features are orthogonal. A particular system may support only +monitoring, only control, or both monitoring and control. Cache +pseudo-locking is a unique way of using cache control to "pin" or +"lock" data in the cache. Details can be found in +"Cache Pseudo-Locking". + + +The mount succeeds if either of allocation or monitoring is present, but +only those files and directories supported by the system will be created. +For more details on the behavior of the interface during monitoring +and allocation, see the "Resource alloc and monitor groups" section. + +Info directory +============== + +The 'info' directory contains information about the enabled +resources. Each resource has its own subdirectory. The subdirectory +names reflect the resource names. + +Each subdirectory contains the following files with respect to +allocation: + +Cache resource(L3/L2) subdirectory contains the following files +related to allocation: + +"num_closids": + The number of CLOSIDs which are valid for this + resource. The kernel uses the smallest number of + CLOSIDs of all enabled resources as limit. +"cbm_mask": + The bitmask which is valid for this resource. + This mask is equivalent to 100%. +"min_cbm_bits": + The minimum number of consecutive bits which + must be set when writing a mask. + +"shareable_bits": + Bitmask of shareable resource with other executing + entities (e.g. I/O). User can use this when + setting up exclusive cache partitions. Note that + some platforms support devices that have their + own settings for cache use which can over-ride + these bits. +"bit_usage": + Annotated capacity bitmasks showing how all + instances of the resource are used. The legend is: + + "0": + Corresponding region is unused. When the system's + resources have been allocated and a "0" is found + in "bit_usage" it is a sign that resources are + wasted. + + "H": + Corresponding region is used by hardware only + but available for software use. If a resource + has bits set in "shareable_bits" but not all + of these bits appear in the resource groups' + schematas then the bits appearing in + "shareable_bits" but no resource group will + be marked as "H". + "X": + Corresponding region is available for sharing and + used by hardware and software. These are the + bits that appear in "shareable_bits" as + well as a resource group's allocation. + "S": + Corresponding region is used by software + and available for sharing. + "E": + Corresponding region is used exclusively by + one resource group. No sharing allowed. + "P": + Corresponding region is pseudo-locked. No + sharing allowed. + +Memory bandwidth(MB) subdirectory contains the following files +with respect to allocation: + +"min_bandwidth": + The minimum memory bandwidth percentage which + user can request. + +"bandwidth_gran": + The granularity in which the memory bandwidth + percentage is allocated. The allocated + b/w percentage is rounded off to the next + control step available on the hardware. The + available bandwidth control steps are: + min_bandwidth + N * bandwidth_gran. + +"delay_linear": + Indicates if the delay scale is linear or + non-linear. This field is purely informational + only. + +"thread_throttle_mode": + Indicator on Intel systems of how tasks running on threads + of a physical core are throttled in cases where they + request different memory bandwidth percentages: + + "max": + the smallest percentage is applied + to all threads + "per-thread": + bandwidth percentages are directly applied to + the threads running on the core + +If RDT monitoring is available there will be an "L3_MON" directory +with the following files: + +"num_rmids": + The number of RMIDs available. This is the + upper bound for how many "CTRL_MON" + "MON" + groups can be created. + +"mon_features": + Lists the monitoring events if + monitoring is enabled for the resource. + +"max_threshold_occupancy": + Read/write file provides the largest value (in + bytes) at which a previously used LLC_occupancy + counter can be considered for re-use. + +Finally, in the top level of the "info" directory there is a file +named "last_cmd_status". This is reset with every "command" issued +via the file system (making new directories or writing to any of the +control files). If the command was successful, it will read as "ok". +If the command failed, it will provide more information that can be +conveyed in the error returns from file operations. E.g. +:: + + # echo L3:0=f7 > schemata + bash: echo: write error: Invalid argument + # cat info/last_cmd_status + mask f7 has non-consecutive 1-bits + +Resource alloc and monitor groups +================================= + +Resource groups are represented as directories in the resctrl file +system. The default group is the root directory which, immediately +after mounting, owns all the tasks and cpus in the system and can make +full use of all resources. + +On a system with RDT control features additional directories can be +created in the root directory that specify different amounts of each +resource (see "schemata" below). The root and these additional top level +directories are referred to as "CTRL_MON" groups below. + +On a system with RDT monitoring the root directory and other top level +directories contain a directory named "mon_groups" in which additional +directories can be created to monitor subsets of tasks in the CTRL_MON +group that is their ancestor. These are called "MON" groups in the rest +of this document. + +Removing a directory will move all tasks and cpus owned by the group it +represents to the parent. Removing one of the created CTRL_MON groups +will automatically remove all MON groups below it. + +All groups contain the following files: + +"tasks": + Reading this file shows the list of all tasks that belong to + this group. Writing a task id to the file will add a task to the + group. If the group is a CTRL_MON group the task is removed from + whichever previous CTRL_MON group owned the task and also from + any MON group that owned the task. If the group is a MON group, + then the task must already belong to the CTRL_MON parent of this + group. The task is removed from any previous MON group. + + +"cpus": + Reading this file shows a bitmask of the logical CPUs owned by + this group. Writing a mask to this file will add and remove + CPUs to/from this group. As with the tasks file a hierarchy is + maintained where MON groups may only include CPUs owned by the + parent CTRL_MON group. + When the resource group is in pseudo-locked mode this file will + only be readable, reflecting the CPUs associated with the + pseudo-locked region. + + +"cpus_list": + Just like "cpus", only using ranges of CPUs instead of bitmasks. + + +When control is enabled all CTRL_MON groups will also contain: + +"schemata": + A list of all the resources available to this group. + Each resource has its own line and format - see below for details. + +"size": + Mirrors the display of the "schemata" file to display the size in + bytes of each allocation instead of the bits representing the + allocation. + +"mode": + The "mode" of the resource group dictates the sharing of its + allocations. A "shareable" resource group allows sharing of its + allocations while an "exclusive" resource group does not. A + cache pseudo-locked region is created by first writing + "pseudo-locksetup" to the "mode" file before writing the cache + pseudo-locked region's schemata to the resource group's "schemata" + file. On successful pseudo-locked region creation the mode will + automatically change to "pseudo-locked". + +When monitoring is enabled all MON groups will also contain: + +"mon_data": + This contains a set of files organized by L3 domain and by + RDT event. E.g. on a system with two L3 domains there will + be subdirectories "mon_L3_00" and "mon_L3_01". Each of these + directories have one file per event (e.g. "llc_occupancy", + "mbm_total_bytes", and "mbm_local_bytes"). In a MON group these + files provide a read out of the current value of the event for + all tasks in the group. In CTRL_MON groups these files provide + the sum for all tasks in the CTRL_MON group and all tasks in + MON groups. Please see example section for more details on usage. + +Resource allocation rules +------------------------- + +When a task is running the following rules define which resources are +available to it: + +1) If the task is a member of a non-default group, then the schemata + for that group is used. + +2) Else if the task belongs to the default group, but is running on a + CPU that is assigned to some specific group, then the schemata for the + CPU's group is used. + +3) Otherwise the schemata for the default group is used. + +Resource monitoring rules +------------------------- +1) If a task is a member of a MON group, or non-default CTRL_MON group + then RDT events for the task will be reported in that group. + +2) If a task is a member of the default CTRL_MON group, but is running + on a CPU that is assigned to some specific group, then the RDT events + for the task will be reported in that group. + +3) Otherwise RDT events for the task will be reported in the root level + "mon_data" group. + + +Notes on cache occupancy monitoring and control +=============================================== +When moving a task from one group to another you should remember that +this only affects *new* cache allocations by the task. E.g. you may have +a task in a monitor group showing 3 MB of cache occupancy. If you move +to a new group and immediately check the occupancy of the old and new +groups you will likely see that the old group is still showing 3 MB and +the new group zero. When the task accesses locations still in cache from +before the move, the h/w does not update any counters. On a busy system +you will likely see the occupancy in the old group go down as cache lines +are evicted and re-used while the occupancy in the new group rises as +the task accesses memory and loads into the cache are counted based on +membership in the new group. + +The same applies to cache allocation control. Moving a task to a group +with a smaller cache partition will not evict any cache lines. The +process may continue to use them from the old partition. + +Hardware uses CLOSid(Class of service ID) and an RMID(Resource monitoring ID) +to identify a control group and a monitoring group respectively. Each of +the resource groups are mapped to these IDs based on the kind of group. The +number of CLOSid and RMID are limited by the hardware and hence the creation of +a "CTRL_MON" directory may fail if we run out of either CLOSID or RMID +and creation of "MON" group may fail if we run out of RMIDs. + +max_threshold_occupancy - generic concepts +------------------------------------------ + +Note that an RMID once freed may not be immediately available for use as +the RMID is still tagged the cache lines of the previous user of RMID. +Hence such RMIDs are placed on limbo list and checked back if the cache +occupancy has gone down. If there is a time when system has a lot of +limbo RMIDs but which are not ready to be used, user may see an -EBUSY +during mkdir. + +max_threshold_occupancy is a user configurable value to determine the +occupancy at which an RMID can be freed. + +Schemata files - general concepts +--------------------------------- +Each line in the file describes one resource. The line starts with +the name of the resource, followed by specific values to be applied +in each of the instances of that resource on the system. + +Cache IDs +--------- +On current generation systems there is one L3 cache per socket and L2 +caches are generally just shared by the hyperthreads on a core, but this +isn't an architectural requirement. We could have multiple separate L3 +caches on a socket, multiple cores could share an L2 cache. So instead +of using "socket" or "core" to define the set of logical cpus sharing +a resource we use a "Cache ID". At a given cache level this will be a +unique number across the whole system (but it isn't guaranteed to be a +contiguous sequence, there may be gaps). To find the ID for each logical +CPU look in /sys/devices/system/cpu/cpu*/cache/index*/id + +Cache Bit Masks (CBM) +--------------------- +For cache resources we describe the portion of the cache that is available +for allocation using a bitmask. The maximum value of the mask is defined +by each cpu model (and may be different for different cache levels). It +is found using CPUID, but is also provided in the "info" directory of +the resctrl file system in "info/{resource}/cbm_mask". Intel hardware +requires that these masks have all the '1' bits in a contiguous block. So +0x3, 0x6 and 0xC are legal 4-bit masks with two bits set, but 0x5, 0x9 +and 0xA are not. On a system with a 20-bit mask each bit represents 5% +of the capacity of the cache. You could partition the cache into four +equal parts with masks: 0x1f, 0x3e0, 0x7c00, 0xf8000. + +Memory bandwidth Allocation and monitoring +========================================== + +For Memory bandwidth resource, by default the user controls the resource +by indicating the percentage of total memory bandwidth. + +The minimum bandwidth percentage value for each cpu model is predefined +and can be looked up through "info/MB/min_bandwidth". The bandwidth +granularity that is allocated is also dependent on the cpu model and can +be looked up at "info/MB/bandwidth_gran". The available bandwidth +control steps are: min_bw + N * bw_gran. Intermediate values are rounded +to the next control step available on the hardware. + +The bandwidth throttling is a core specific mechanism on some of Intel +SKUs. Using a high bandwidth and a low bandwidth setting on two threads +sharing a core may result in both threads being throttled to use the +low bandwidth (see "thread_throttle_mode"). + +The fact that Memory bandwidth allocation(MBA) may be a core +specific mechanism where as memory bandwidth monitoring(MBM) is done at +the package level may lead to confusion when users try to apply control +via the MBA and then monitor the bandwidth to see if the controls are +effective. Below are such scenarios: + +1. User may *not* see increase in actual bandwidth when percentage + values are increased: + +This can occur when aggregate L2 external bandwidth is more than L3 +external bandwidth. Consider an SKL SKU with 24 cores on a package and +where L2 external is 10GBps (hence aggregate L2 external bandwidth is +240GBps) and L3 external bandwidth is 100GBps. Now a workload with '20 +threads, having 50% bandwidth, each consuming 5GBps' consumes the max L3 +bandwidth of 100GBps although the percentage value specified is only 50% +<< 100%. Hence increasing the bandwidth percentage will not yield any +more bandwidth. This is because although the L2 external bandwidth still +has capacity, the L3 external bandwidth is fully used. Also note that +this would be dependent on number of cores the benchmark is run on. + +2. Same bandwidth percentage may mean different actual bandwidth + depending on # of threads: + +For the same SKU in #1, a 'single thread, with 10% bandwidth' and '4 +thread, with 10% bandwidth' can consume upto 10GBps and 40GBps although +they have same percentage bandwidth of 10%. This is simply because as +threads start using more cores in an rdtgroup, the actual bandwidth may +increase or vary although user specified bandwidth percentage is same. + +In order to mitigate this and make the interface more user friendly, +resctrl added support for specifying the bandwidth in MBps as well. The +kernel underneath would use a software feedback mechanism or a "Software +Controller(mba_sc)" which reads the actual bandwidth using MBM counters +and adjust the memory bandwidth percentages to ensure:: + + "actual bandwidth < user specified bandwidth". + +By default, the schemata would take the bandwidth percentage values +where as user can switch to the "MBA software controller" mode using +a mount option 'mba_MBps'. The schemata format is specified in the below +sections. + +L3 schemata file details (code and data prioritization disabled) +---------------------------------------------------------------- +With CDP disabled the L3 schemata format is:: + + L3:=;=;... + +L3 schemata file details (CDP enabled via mount option to resctrl) +------------------------------------------------------------------ +When CDP is enabled L3 control is split into two separate resources +so you can specify independent masks for code and data like this:: + + L3DATA:=;=;... + L3CODE:=;=;... + +L2 schemata file details +------------------------ +CDP is supported at L2 using the 'cdpl2' mount option. The schemata +format is either:: + + L2:=;=;... + +or + + L2DATA:=;=;... + L2CODE:=;=;... + + +Memory bandwidth Allocation (default mode) +------------------------------------------ + +Memory b/w domain is L3 cache. +:: + + MB:=bandwidth0;=bandwidth1;... + +Memory bandwidth Allocation specified in MBps +--------------------------------------------- + +Memory bandwidth domain is L3 cache. +:: + + MB:=bw_MBps0;=bw_MBps1;... + +Reading/writing the schemata file +--------------------------------- +Reading the schemata file will show the state of all resources +on all domains. When writing you only need to specify those values +which you wish to change. E.g. +:: + + # cat schemata + L3DATA:0=fffff;1=fffff;2=fffff;3=fffff + L3CODE:0=fffff;1=fffff;2=fffff;3=fffff + # echo "L3DATA:2=3c0;" > schemata + # cat schemata + L3DATA:0=fffff;1=fffff;2=3c0;3=fffff + L3CODE:0=fffff;1=fffff;2=fffff;3=fffff + +Cache Pseudo-Locking +==================== +CAT enables a user to specify the amount of cache space that an +application can fill. Cache pseudo-locking builds on the fact that a +CPU can still read and write data pre-allocated outside its current +allocated area on a cache hit. With cache pseudo-locking, data can be +preloaded into a reserved portion of cache that no application can +fill, and from that point on will only serve cache hits. The cache +pseudo-locked memory is made accessible to user space where an +application can map it into its virtual address space and thus have +a region of memory with reduced average read latency. + +The creation of a cache pseudo-locked region is triggered by a request +from the user to do so that is accompanied by a schemata of the region +to be pseudo-locked. The cache pseudo-locked region is created as follows: + +- Create a CAT allocation CLOSNEW with a CBM matching the schemata + from the user of the cache region that will contain the pseudo-locked + memory. This region must not overlap with any current CAT allocation/CLOS + on the system and no future overlap with this cache region is allowed + while the pseudo-locked region exists. +- Create a contiguous region of memory of the same size as the cache + region. +- Flush the cache, disable hardware prefetchers, disable preemption. +- Make CLOSNEW the active CLOS and touch the allocated memory to load + it into the cache. +- Set the previous CLOS as active. +- At this point the closid CLOSNEW can be released - the cache + pseudo-locked region is protected as long as its CBM does not appear in + any CAT allocation. Even though the cache pseudo-locked region will from + this point on not appear in any CBM of any CLOS an application running with + any CLOS will be able to access the memory in the pseudo-locked region since + the region continues to serve cache hits. +- The contiguous region of memory loaded into the cache is exposed to + user-space as a character device. + +Cache pseudo-locking increases the probability that data will remain +in the cache via carefully configuring the CAT feature and controlling +application behavior. There is no guarantee that data is placed in +cache. Instructions like INVD, WBINVD, CLFLUSH, etc. can still evict +“locked” data from cache. Power management C-states may shrink or +power off cache. Deeper C-states will automatically be restricted on +pseudo-locked region creation. + +It is required that an application using a pseudo-locked region runs +with affinity to the cores (or a subset of the cores) associated +with the cache on which the pseudo-locked region resides. A sanity check +within the code will not allow an application to map pseudo-locked memory +unless it runs with affinity to cores associated with the cache on which the +pseudo-locked region resides. The sanity check is only done during the +initial mmap() handling, there is no enforcement afterwards and the +application self needs to ensure it remains affine to the correct cores. + +Pseudo-locking is accomplished in two stages: + +1) During the first stage the system administrator allocates a portion + of cache that should be dedicated to pseudo-locking. At this time an + equivalent portion of memory is allocated, loaded into allocated + cache portion, and exposed as a character device. +2) During the second stage a user-space application maps (mmap()) the + pseudo-locked memory into its address space. + +Cache Pseudo-Locking Interface +------------------------------ +A pseudo-locked region is created using the resctrl interface as follows: + +1) Create a new resource group by creating a new directory in /sys/fs/resctrl. +2) Change the new resource group's mode to "pseudo-locksetup" by writing + "pseudo-locksetup" to the "mode" file. +3) Write the schemata of the pseudo-locked region to the "schemata" file. All + bits within the schemata should be "unused" according to the "bit_usage" + file. + +On successful pseudo-locked region creation the "mode" file will contain +"pseudo-locked" and a new character device with the same name as the resource +group will exist in /dev/pseudo_lock. This character device can be mmap()'ed +by user space in order to obtain access to the pseudo-locked memory region. + +An example of cache pseudo-locked region creation and usage can be found below. + +Cache Pseudo-Locking Debugging Interface +---------------------------------------- +The pseudo-locking debugging interface is enabled by default (if +CONFIG_DEBUG_FS is enabled) and can be found in /sys/kernel/debug/resctrl. + +There is no explicit way for the kernel to test if a provided memory +location is present in the cache. The pseudo-locking debugging interface uses +the tracing infrastructure to provide two ways to measure cache residency of +the pseudo-locked region: + +1) Memory access latency using the pseudo_lock_mem_latency tracepoint. Data + from these measurements are best visualized using a hist trigger (see + example below). In this test the pseudo-locked region is traversed at + a stride of 32 bytes while hardware prefetchers and preemption + are disabled. This also provides a substitute visualization of cache + hits and misses. +2) Cache hit and miss measurements using model specific precision counters if + available. Depending on the levels of cache on the system the pseudo_lock_l2 + and pseudo_lock_l3 tracepoints are available. + +When a pseudo-locked region is created a new debugfs directory is created for +it in debugfs as /sys/kernel/debug/resctrl/. A single +write-only file, pseudo_lock_measure, is present in this directory. The +measurement of the pseudo-locked region depends on the number written to this +debugfs file: + +1: + writing "1" to the pseudo_lock_measure file will trigger the latency + measurement captured in the pseudo_lock_mem_latency tracepoint. See + example below. +2: + writing "2" to the pseudo_lock_measure file will trigger the L2 cache + residency (cache hits and misses) measurement captured in the + pseudo_lock_l2 tracepoint. See example below. +3: + writing "3" to the pseudo_lock_measure file will trigger the L3 cache + residency (cache hits and misses) measurement captured in the + pseudo_lock_l3 tracepoint. + +All measurements are recorded with the tracing infrastructure. This requires +the relevant tracepoints to be enabled before the measurement is triggered. + +Example of latency debugging interface +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +In this example a pseudo-locked region named "newlock" was created. Here is +how we can measure the latency in cycles of reading from this region and +visualize this data with a histogram that is available if CONFIG_HIST_TRIGGERS +is set:: + + # :> /sys/kernel/debug/tracing/trace + # echo 'hist:keys=latency' > /sys/kernel/debug/tracing/events/resctrl/pseudo_lock_mem_latency/trigger + # echo 1 > /sys/kernel/debug/tracing/events/resctrl/pseudo_lock_mem_latency/enable + # echo 1 > /sys/kernel/debug/resctrl/newlock/pseudo_lock_measure + # echo 0 > /sys/kernel/debug/tracing/events/resctrl/pseudo_lock_mem_latency/enable + # cat /sys/kernel/debug/tracing/events/resctrl/pseudo_lock_mem_latency/hist + + # event histogram + # + # trigger info: hist:keys=latency:vals=hitcount:sort=hitcount:size=2048 [active] + # + + { latency: 456 } hitcount: 1 + { latency: 50 } hitcount: 83 + { latency: 36 } hitcount: 96 + { latency: 44 } hitcount: 174 + { latency: 48 } hitcount: 195 + { latency: 46 } hitcount: 262 + { latency: 42 } hitcount: 693 + { latency: 40 } hitcount: 3204 + { latency: 38 } hitcount: 3484 + + Totals: + Hits: 8192 + Entries: 9 + Dropped: 0 + +Example of cache hits/misses debugging +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +In this example a pseudo-locked region named "newlock" was created on the L2 +cache of a platform. Here is how we can obtain details of the cache hits +and misses using the platform's precision counters. +:: + + # :> /sys/kernel/debug/tracing/trace + # echo 1 > /sys/kernel/debug/tracing/events/resctrl/pseudo_lock_l2/enable + # echo 2 > /sys/kernel/debug/resctrl/newlock/pseudo_lock_measure + # echo 0 > /sys/kernel/debug/tracing/events/resctrl/pseudo_lock_l2/enable + # cat /sys/kernel/debug/tracing/trace + + # tracer: nop + # + # _-----=> irqs-off + # / _----=> need-resched + # | / _---=> hardirq/softirq + # || / _--=> preempt-depth + # ||| / delay + # TASK-PID CPU# |||| TIMESTAMP FUNCTION + # | | | |||| | | + pseudo_lock_mea-1672 [002] .... 3132.860500: pseudo_lock_l2: hits=4097 miss=0 + + +Examples for RDT allocation usage +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +1) Example 1 + +On a two socket machine (one L3 cache per socket) with just four bits +for cache bit masks, minimum b/w of 10% with a memory bandwidth +granularity of 10%. +:: + + # mount -t resctrl resctrl /sys/fs/resctrl + # cd /sys/fs/resctrl + # mkdir p0 p1 + # echo "L3:0=3;1=c\nMB:0=50;1=50" > /sys/fs/resctrl/p0/schemata + # echo "L3:0=3;1=3\nMB:0=50;1=50" > /sys/fs/resctrl/p1/schemata + +The default resource group is unmodified, so we have access to all parts +of all caches (its schemata file reads "L3:0=f;1=f"). + +Tasks that are under the control of group "p0" may only allocate from the +"lower" 50% on cache ID 0, and the "upper" 50% of cache ID 1. +Tasks in group "p1" use the "lower" 50% of cache on both sockets. + +Similarly, tasks that are under the control of group "p0" may use a +maximum memory b/w of 50% on socket0 and 50% on socket 1. +Tasks in group "p1" may also use 50% memory b/w on both sockets. +Note that unlike cache masks, memory b/w cannot specify whether these +allocations can overlap or not. The allocations specifies the maximum +b/w that the group may be able to use and the system admin can configure +the b/w accordingly. + +If resctrl is using the software controller (mba_sc) then user can enter the +max b/w in MB rather than the percentage values. +:: + + # echo "L3:0=3;1=c\nMB:0=1024;1=500" > /sys/fs/resctrl/p0/schemata + # echo "L3:0=3;1=3\nMB:0=1024;1=500" > /sys/fs/resctrl/p1/schemata + +In the above example the tasks in "p1" and "p0" on socket 0 would use a max b/w +of 1024MB where as on socket 1 they would use 500MB. + +2) Example 2 + +Again two sockets, but this time with a more realistic 20-bit mask. + +Two real time tasks pid=1234 running on processor 0 and pid=5678 running on +processor 1 on socket 0 on a 2-socket and dual core machine. To avoid noisy +neighbors, each of the two real-time tasks exclusively occupies one quarter +of L3 cache on socket 0. +:: + + # mount -t resctrl resctrl /sys/fs/resctrl + # cd /sys/fs/resctrl + +First we reset the schemata for the default group so that the "upper" +50% of the L3 cache on socket 0 and 50% of memory b/w cannot be used by +ordinary tasks:: + + # echo "L3:0=3ff;1=fffff\nMB:0=50;1=100" > schemata + +Next we make a resource group for our first real time task and give +it access to the "top" 25% of the cache on socket 0. +:: + + # mkdir p0 + # echo "L3:0=f8000;1=fffff" > p0/schemata + +Finally we move our first real time task into this resource group. We +also use taskset(1) to ensure the task always runs on a dedicated CPU +on socket 0. Most uses of resource groups will also constrain which +processors tasks run on. +:: + + # echo 1234 > p0/tasks + # taskset -cp 1 1234 + +Ditto for the second real time task (with the remaining 25% of cache):: + + # mkdir p1 + # echo "L3:0=7c00;1=fffff" > p1/schemata + # echo 5678 > p1/tasks + # taskset -cp 2 5678 + +For the same 2 socket system with memory b/w resource and CAT L3 the +schemata would look like(Assume min_bandwidth 10 and bandwidth_gran is +10): + +For our first real time task this would request 20% memory b/w on socket 0. +:: + + # echo -e "L3:0=f8000;1=fffff\nMB:0=20;1=100" > p0/schemata + +For our second real time task this would request an other 20% memory b/w +on socket 0. +:: + + # echo -e "L3:0=f8000;1=fffff\nMB:0=20;1=100" > p0/schemata + +3) Example 3 + +A single socket system which has real-time tasks running on core 4-7 and +non real-time workload assigned to core 0-3. The real-time tasks share text +and data, so a per task association is not required and due to interaction +with the kernel it's desired that the kernel on these cores shares L3 with +the tasks. +:: + + # mount -t resctrl resctrl /sys/fs/resctrl + # cd /sys/fs/resctrl + +First we reset the schemata for the default group so that the "upper" +50% of the L3 cache on socket 0, and 50% of memory bandwidth on socket 0 +cannot be used by ordinary tasks:: + + # echo "L3:0=3ff\nMB:0=50" > schemata + +Next we make a resource group for our real time cores and give it access +to the "top" 50% of the cache on socket 0 and 50% of memory bandwidth on +socket 0. +:: + + # mkdir p0 + # echo "L3:0=ffc00\nMB:0=50" > p0/schemata + +Finally we move core 4-7 over to the new group and make sure that the +kernel and the tasks running there get 50% of the cache. They should +also get 50% of memory bandwidth assuming that the cores 4-7 are SMT +siblings and only the real time threads are scheduled on the cores 4-7. +:: + + # echo F0 > p0/cpus + +4) Example 4 + +The resource groups in previous examples were all in the default "shareable" +mode allowing sharing of their cache allocations. If one resource group +configures a cache allocation then nothing prevents another resource group +to overlap with that allocation. + +In this example a new exclusive resource group will be created on a L2 CAT +system with two L2 cache instances that can be configured with an 8-bit +capacity bitmask. The new exclusive resource group will be configured to use +25% of each cache instance. +:: + + # mount -t resctrl resctrl /sys/fs/resctrl/ + # cd /sys/fs/resctrl + +First, we observe that the default group is configured to allocate to all L2 +cache:: + + # cat schemata + L2:0=ff;1=ff + +We could attempt to create the new resource group at this point, but it will +fail because of the overlap with the schemata of the default group:: + + # mkdir p0 + # echo 'L2:0=0x3;1=0x3' > p0/schemata + # cat p0/mode + shareable + # echo exclusive > p0/mode + -sh: echo: write error: Invalid argument + # cat info/last_cmd_status + schemata overlaps + +To ensure that there is no overlap with another resource group the default +resource group's schemata has to change, making it possible for the new +resource group to become exclusive. +:: + + # echo 'L2:0=0xfc;1=0xfc' > schemata + # echo exclusive > p0/mode + # grep . p0/* + p0/cpus:0 + p0/mode:exclusive + p0/schemata:L2:0=03;1=03 + p0/size:L2:0=262144;1=262144 + +A new resource group will on creation not overlap with an exclusive resource +group:: + + # mkdir p1 + # grep . p1/* + p1/cpus:0 + p1/mode:shareable + p1/schemata:L2:0=fc;1=fc + p1/size:L2:0=786432;1=786432 + +The bit_usage will reflect how the cache is used:: + + # cat info/L2/bit_usage + 0=SSSSSSEE;1=SSSSSSEE + +A resource group cannot be forced to overlap with an exclusive resource group:: + + # echo 'L2:0=0x1;1=0x1' > p1/schemata + -sh: echo: write error: Invalid argument + # cat info/last_cmd_status + overlaps with exclusive group + +Example of Cache Pseudo-Locking +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Lock portion of L2 cache from cache id 1 using CBM 0x3. Pseudo-locked +region is exposed at /dev/pseudo_lock/newlock that can be provided to +application for argument to mmap(). +:: + + # mount -t resctrl resctrl /sys/fs/resctrl/ + # cd /sys/fs/resctrl + +Ensure that there are bits available that can be pseudo-locked, since only +unused bits can be pseudo-locked the bits to be pseudo-locked needs to be +removed from the default resource group's schemata:: + + # cat info/L2/bit_usage + 0=SSSSSSSS;1=SSSSSSSS + # echo 'L2:1=0xfc' > schemata + # cat info/L2/bit_usage + 0=SSSSSSSS;1=SSSSSS00 + +Create a new resource group that will be associated with the pseudo-locked +region, indicate that it will be used for a pseudo-locked region, and +configure the requested pseudo-locked region capacity bitmask:: + + # mkdir newlock + # echo pseudo-locksetup > newlock/mode + # echo 'L2:1=0x3' > newlock/schemata + +On success the resource group's mode will change to pseudo-locked, the +bit_usage will reflect the pseudo-locked region, and the character device +exposing the pseudo-locked region will exist:: + + # cat newlock/mode + pseudo-locked + # cat info/L2/bit_usage + 0=SSSSSSSS;1=SSSSSSPP + # ls -l /dev/pseudo_lock/newlock + crw------- 1 root root 243, 0 Apr 3 05:01 /dev/pseudo_lock/newlock + +:: + + /* + * Example code to access one page of pseudo-locked cache region + * from user space. + */ + #define _GNU_SOURCE + #include + #include + #include + #include + #include + #include + + /* + * It is required that the application runs with affinity to only + * cores associated with the pseudo-locked region. Here the cpu + * is hardcoded for convenience of example. + */ + static int cpuid = 2; + + int main(int argc, char *argv[]) + { + cpu_set_t cpuset; + long page_size; + void *mapping; + int dev_fd; + int ret; + + page_size = sysconf(_SC_PAGESIZE); + + CPU_ZERO(&cpuset); + CPU_SET(cpuid, &cpuset); + ret = sched_setaffinity(0, sizeof(cpuset), &cpuset); + if (ret < 0) { + perror("sched_setaffinity"); + exit(EXIT_FAILURE); + } + + dev_fd = open("/dev/pseudo_lock/newlock", O_RDWR); + if (dev_fd < 0) { + perror("open"); + exit(EXIT_FAILURE); + } + + mapping = mmap(0, page_size, PROT_READ | PROT_WRITE, MAP_SHARED, + dev_fd, 0); + if (mapping == MAP_FAILED) { + perror("mmap"); + close(dev_fd); + exit(EXIT_FAILURE); + } + + /* Application interacts with pseudo-locked memory @mapping */ + + ret = munmap(mapping, page_size); + if (ret < 0) { + perror("munmap"); + close(dev_fd); + exit(EXIT_FAILURE); + } + + close(dev_fd); + exit(EXIT_SUCCESS); + } + +Locking between applications +---------------------------- + +Certain operations on the resctrl filesystem, composed of read/writes +to/from multiple files, must be atomic. + +As an example, the allocation of an exclusive reservation of L3 cache +involves: + + 1. Read the cbmmasks from each directory or the per-resource "bit_usage" + 2. Find a contiguous set of bits in the global CBM bitmask that is clear + in any of the directory cbmmasks + 3. Create a new directory + 4. Set the bits found in step 2 to the new directory "schemata" file + +If two applications attempt to allocate space concurrently then they can +end up allocating the same bits so the reservations are shared instead of +exclusive. + +To coordinate atomic operations on the resctrlfs and to avoid the problem +above, the following locking procedure is recommended: + +Locking is based on flock, which is available in libc and also as a shell +script command + +Write lock: + + A) Take flock(LOCK_EX) on /sys/fs/resctrl + B) Read/write the directory structure. + C) funlock + +Read lock: + + A) Take flock(LOCK_SH) on /sys/fs/resctrl + B) If success read the directory structure. + C) funlock + +Example with bash:: + + # Atomically read directory structure + $ flock -s /sys/fs/resctrl/ find /sys/fs/resctrl + + # Read directory contents and create new subdirectory + + $ cat create-dir.sh + find /sys/fs/resctrl/ > output.txt + mask = function-of(output.txt) + mkdir /sys/fs/resctrl/newres/ + echo mask > /sys/fs/resctrl/newres/schemata + + $ flock /sys/fs/resctrl/ ./create-dir.sh + +Example with C:: + + /* + * Example code do take advisory locks + * before accessing resctrl filesystem + */ + #include + #include + + void resctrl_take_shared_lock(int fd) + { + int ret; + + /* take shared lock on resctrl filesystem */ + ret = flock(fd, LOCK_SH); + if (ret) { + perror("flock"); + exit(-1); + } + } + + void resctrl_take_exclusive_lock(int fd) + { + int ret; + + /* release lock on resctrl filesystem */ + ret = flock(fd, LOCK_EX); + if (ret) { + perror("flock"); + exit(-1); + } + } + + void resctrl_release_lock(int fd) + { + int ret; + + /* take shared lock on resctrl filesystem */ + ret = flock(fd, LOCK_UN); + if (ret) { + perror("flock"); + exit(-1); + } + } + + void main(void) + { + int fd, ret; + + fd = open("/sys/fs/resctrl", O_DIRECTORY); + if (fd == -1) { + perror("open"); + exit(-1); + } + resctrl_take_shared_lock(fd); + /* code to read directory contents */ + resctrl_release_lock(fd); + + resctrl_take_exclusive_lock(fd); + /* code to read and write directory contents */ + resctrl_release_lock(fd); + } + +Examples for RDT Monitoring along with allocation usage +======================================================= +Reading monitored data +---------------------- +Reading an event file (for ex: mon_data/mon_L3_00/llc_occupancy) would +show the current snapshot of LLC occupancy of the corresponding MON +group or CTRL_MON group. + + +Example 1 (Monitor CTRL_MON group and subset of tasks in CTRL_MON group) +------------------------------------------------------------------------ +On a two socket machine (one L3 cache per socket) with just four bits +for cache bit masks:: + + # mount -t resctrl resctrl /sys/fs/resctrl + # cd /sys/fs/resctrl + # mkdir p0 p1 + # echo "L3:0=3;1=c" > /sys/fs/resctrl/p0/schemata + # echo "L3:0=3;1=3" > /sys/fs/resctrl/p1/schemata + # echo 5678 > p1/tasks + # echo 5679 > p1/tasks + +The default resource group is unmodified, so we have access to all parts +of all caches (its schemata file reads "L3:0=f;1=f"). + +Tasks that are under the control of group "p0" may only allocate from the +"lower" 50% on cache ID 0, and the "upper" 50% of cache ID 1. +Tasks in group "p1" use the "lower" 50% of cache on both sockets. + +Create monitor groups and assign a subset of tasks to each monitor group. +:: + + # cd /sys/fs/resctrl/p1/mon_groups + # mkdir m11 m12 + # echo 5678 > m11/tasks + # echo 5679 > m12/tasks + +fetch data (data shown in bytes) +:: + + # cat m11/mon_data/mon_L3_00/llc_occupancy + 16234000 + # cat m11/mon_data/mon_L3_01/llc_occupancy + 14789000 + # cat m12/mon_data/mon_L3_00/llc_occupancy + 16789000 + +The parent ctrl_mon group shows the aggregated data. +:: + + # cat /sys/fs/resctrl/p1/mon_data/mon_l3_00/llc_occupancy + 31234000 + +Example 2 (Monitor a task from its creation) +-------------------------------------------- +On a two socket machine (one L3 cache per socket):: + + # mount -t resctrl resctrl /sys/fs/resctrl + # cd /sys/fs/resctrl + # mkdir p0 p1 + +An RMID is allocated to the group once its created and hence the +below is monitored from its creation. +:: + + # echo $$ > /sys/fs/resctrl/p1/tasks + # + +Fetch the data:: + + # cat /sys/fs/resctrl/p1/mon_data/mon_l3_00/llc_occupancy + 31789000 + +Example 3 (Monitor without CAT support or before creating CAT groups) +--------------------------------------------------------------------- + +Assume a system like HSW has only CQM and no CAT support. In this case +the resctrl will still mount but cannot create CTRL_MON directories. +But user can create different MON groups within the root group thereby +able to monitor all tasks including kernel threads. + +This can also be used to profile jobs cache size footprint before being +able to allocate them to different allocation groups. +:: + + # mount -t resctrl resctrl /sys/fs/resctrl + # cd /sys/fs/resctrl + # mkdir mon_groups/m01 + # mkdir mon_groups/m02 + + # echo 3478 > /sys/fs/resctrl/mon_groups/m01/tasks + # echo 2467 > /sys/fs/resctrl/mon_groups/m02/tasks + +Monitor the groups separately and also get per domain data. From the +below its apparent that the tasks are mostly doing work on +domain(socket) 0. +:: + + # cat /sys/fs/resctrl/mon_groups/m01/mon_L3_00/llc_occupancy + 31234000 + # cat /sys/fs/resctrl/mon_groups/m01/mon_L3_01/llc_occupancy + 34555 + # cat /sys/fs/resctrl/mon_groups/m02/mon_L3_00/llc_occupancy + 31234000 + # cat /sys/fs/resctrl/mon_groups/m02/mon_L3_01/llc_occupancy + 32789 + + +Example 4 (Monitor real time tasks) +----------------------------------- + +A single socket system which has real time tasks running on cores 4-7 +and non real time tasks on other cpus. We want to monitor the cache +occupancy of the real time threads on these cores. +:: + + # mount -t resctrl resctrl /sys/fs/resctrl + # cd /sys/fs/resctrl + # mkdir p1 + +Move the cpus 4-7 over to p1:: + + # echo f0 > p1/cpus + +View the llc occupancy snapshot:: + + # cat /sys/fs/resctrl/p1/mon_data/mon_L3_00/llc_occupancy + 11234000 + +Intel RDT Errata +================ + +Intel MBM Counters May Report System Memory Bandwidth Incorrectly +----------------------------------------------------------------- + +Errata SKX99 for Skylake server and BDF102 for Broadwell server. + +Problem: Intel Memory Bandwidth Monitoring (MBM) counters track metrics +according to the assigned Resource Monitor ID (RMID) for that logical +core. The IA32_QM_CTR register (MSR 0xC8E), used to report these +metrics, may report incorrect system bandwidth for certain RMID values. + +Implication: Due to the errata, system memory bandwidth may not match +what is reported. + +Workaround: MBM total and local readings are corrected according to the +following correction factor table: + ++---------------+---------------+---------------+-----------------+ +|core count |rmid count |rmid threshold |correction factor| ++---------------+---------------+---------------+-----------------+ +|1 |8 |0 |1.000000 | ++---------------+---------------+---------------+-----------------+ +|2 |16 |0 |1.000000 | ++---------------+---------------+---------------+-----------------+ +|3 |24 |15 |0.969650 | ++---------------+---------------+---------------+-----------------+ +|4 |32 |0 |1.000000 | ++---------------+---------------+---------------+-----------------+ +|6 |48 |31 |0.969650 | ++---------------+---------------+---------------+-----------------+ +|7 |56 |47 |1.142857 | ++---------------+---------------+---------------+-----------------+ +|8 |64 |0 |1.000000 | ++---------------+---------------+---------------+-----------------+ +|9 |72 |63 |1.185115 | ++---------------+---------------+---------------+-----------------+ +|10 |80 |63 |1.066553 | ++---------------+---------------+---------------+-----------------+ +|11 |88 |79 |1.454545 | ++---------------+---------------+---------------+-----------------+ +|12 |96 |0 |1.000000 | ++---------------+---------------+---------------+-----------------+ +|13 |104 |95 |1.230769 | ++---------------+---------------+---------------+-----------------+ +|14 |112 |95 |1.142857 | ++---------------+---------------+---------------+-----------------+ +|15 |120 |95 |1.066667 | ++---------------+---------------+---------------+-----------------+ +|16 |128 |0 |1.000000 | ++---------------+---------------+---------------+-----------------+ +|17 |136 |127 |1.254863 | ++---------------+---------------+---------------+-----------------+ +|18 |144 |127 |1.185255 | ++---------------+---------------+---------------+-----------------+ +|19 |152 |0 |1.000000 | ++---------------+---------------+---------------+-----------------+ +|20 |160 |127 |1.066667 | ++---------------+---------------+---------------+-----------------+ +|21 |168 |0 |1.000000 | ++---------------+---------------+---------------+-----------------+ +|22 |176 |159 |1.454334 | ++---------------+---------------+---------------+-----------------+ +|23 |184 |0 |1.000000 | ++---------------+---------------+---------------+-----------------+ +|24 |192 |127 |0.969744 | ++---------------+---------------+---------------+-----------------+ +|25 |200 |191 |1.280246 | ++---------------+---------------+---------------+-----------------+ +|26 |208 |191 |1.230921 | ++---------------+---------------+---------------+-----------------+ +|27 |216 |0 |1.000000 | ++---------------+---------------+---------------+-----------------+ +|28 |224 |191 |1.143118 | ++---------------+---------------+---------------+-----------------+ + +If rmid > rmid threshold, MBM total and local values should be multiplied +by the correction factor. + +See: + +1. Erratum SKX99 in Intel Xeon Processor Scalable Family Specification Update: +http://web.archive.org/web/20200716124958/https://www.intel.com/content/www/us/en/processors/xeon/scalable/xeon-scalable-spec-update.html + +2. Erratum BDF102 in Intel Xeon E5-2600 v4 Processor Product Family Specification Update: +http://web.archive.org/web/20191125200531/https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-e5-v4-spec-update.pdf + +3. The errata in Intel Resource Director Technology (Intel RDT) on 2nd Generation Intel Xeon Scalable Processors Reference Manual: +https://software.intel.com/content/www/us/en/develop/articles/intel-resource-director-technology-rdt-reference-manual.html + +for further information. diff --git a/Documentation/x86/resctrl_ui.rst b/Documentation/x86/resctrl_ui.rst deleted file mode 100644 index e59b7b93a9b4..000000000000 --- a/Documentation/x86/resctrl_ui.rst +++ /dev/null @@ -1,1211 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 -.. include:: - -=========================================== -User Interface for Resource Control feature -=========================================== - -:Copyright: |copy| 2016 Intel Corporation -:Authors: - Fenghua Yu - - Tony Luck - - Vikas Shivappa - - -Intel refers to this feature as Intel Resource Director Technology(Intel(R) RDT). -AMD refers to this feature as AMD Platform Quality of Service(AMD QoS). - -This feature is enabled by the CONFIG_X86_CPU_RESCTRL and the x86 /proc/cpuinfo -flag bits: - -============================================= ================================ -RDT (Resource Director Technology) Allocation "rdt_a" -CAT (Cache Allocation Technology) "cat_l3", "cat_l2" -CDP (Code and Data Prioritization) "cdp_l3", "cdp_l2" -CQM (Cache QoS Monitoring) "cqm_llc", "cqm_occup_llc" -MBM (Memory Bandwidth Monitoring) "cqm_mbm_total", "cqm_mbm_local" -MBA (Memory Bandwidth Allocation) "mba" -============================================= ================================ - -To use the feature mount the file system:: - - # mount -t resctrl resctrl [-o cdp[,cdpl2][,mba_MBps]] /sys/fs/resctrl - -mount options are: - -"cdp": - Enable code/data prioritization in L3 cache allocations. -"cdpl2": - Enable code/data prioritization in L2 cache allocations. -"mba_MBps": - Enable the MBA Software Controller(mba_sc) to specify MBA - bandwidth in MBps - -L2 and L3 CDP are controlled separately. - -RDT features are orthogonal. A particular system may support only -monitoring, only control, or both monitoring and control. Cache -pseudo-locking is a unique way of using cache control to "pin" or -"lock" data in the cache. Details can be found in -"Cache Pseudo-Locking". - - -The mount succeeds if either of allocation or monitoring is present, but -only those files and directories supported by the system will be created. -For more details on the behavior of the interface during monitoring -and allocation, see the "Resource alloc and monitor groups" section. - -Info directory -============== - -The 'info' directory contains information about the enabled -resources. Each resource has its own subdirectory. The subdirectory -names reflect the resource names. - -Each subdirectory contains the following files with respect to -allocation: - -Cache resource(L3/L2) subdirectory contains the following files -related to allocation: - -"num_closids": - The number of CLOSIDs which are valid for this - resource. The kernel uses the smallest number of - CLOSIDs of all enabled resources as limit. -"cbm_mask": - The bitmask which is valid for this resource. - This mask is equivalent to 100%. -"min_cbm_bits": - The minimum number of consecutive bits which - must be set when writing a mask. - -"shareable_bits": - Bitmask of shareable resource with other executing - entities (e.g. I/O). User can use this when - setting up exclusive cache partitions. Note that - some platforms support devices that have their - own settings for cache use which can over-ride - these bits. -"bit_usage": - Annotated capacity bitmasks showing how all - instances of the resource are used. The legend is: - - "0": - Corresponding region is unused. When the system's - resources have been allocated and a "0" is found - in "bit_usage" it is a sign that resources are - wasted. - - "H": - Corresponding region is used by hardware only - but available for software use. If a resource - has bits set in "shareable_bits" but not all - of these bits appear in the resource groups' - schematas then the bits appearing in - "shareable_bits" but no resource group will - be marked as "H". - "X": - Corresponding region is available for sharing and - used by hardware and software. These are the - bits that appear in "shareable_bits" as - well as a resource group's allocation. - "S": - Corresponding region is used by software - and available for sharing. - "E": - Corresponding region is used exclusively by - one resource group. No sharing allowed. - "P": - Corresponding region is pseudo-locked. No - sharing allowed. - -Memory bandwidth(MB) subdirectory contains the following files -with respect to allocation: - -"min_bandwidth": - The minimum memory bandwidth percentage which - user can request. - -"bandwidth_gran": - The granularity in which the memory bandwidth - percentage is allocated. The allocated - b/w percentage is rounded off to the next - control step available on the hardware. The - available bandwidth control steps are: - min_bandwidth + N * bandwidth_gran. - -"delay_linear": - Indicates if the delay scale is linear or - non-linear. This field is purely informational - only. - -"thread_throttle_mode": - Indicator on Intel systems of how tasks running on threads - of a physical core are throttled in cases where they - request different memory bandwidth percentages: - - "max": - the smallest percentage is applied - to all threads - "per-thread": - bandwidth percentages are directly applied to - the threads running on the core - -If RDT monitoring is available there will be an "L3_MON" directory -with the following files: - -"num_rmids": - The number of RMIDs available. This is the - upper bound for how many "CTRL_MON" + "MON" - groups can be created. - -"mon_features": - Lists the monitoring events if - monitoring is enabled for the resource. - -"max_threshold_occupancy": - Read/write file provides the largest value (in - bytes) at which a previously used LLC_occupancy - counter can be considered for re-use. - -Finally, in the top level of the "info" directory there is a file -named "last_cmd_status". This is reset with every "command" issued -via the file system (making new directories or writing to any of the -control files). If the command was successful, it will read as "ok". -If the command failed, it will provide more information that can be -conveyed in the error returns from file operations. E.g. -:: - - # echo L3:0=f7 > schemata - bash: echo: write error: Invalid argument - # cat info/last_cmd_status - mask f7 has non-consecutive 1-bits - -Resource alloc and monitor groups -================================= - -Resource groups are represented as directories in the resctrl file -system. The default group is the root directory which, immediately -after mounting, owns all the tasks and cpus in the system and can make -full use of all resources. - -On a system with RDT control features additional directories can be -created in the root directory that specify different amounts of each -resource (see "schemata" below). The root and these additional top level -directories are referred to as "CTRL_MON" groups below. - -On a system with RDT monitoring the root directory and other top level -directories contain a directory named "mon_groups" in which additional -directories can be created to monitor subsets of tasks in the CTRL_MON -group that is their ancestor. These are called "MON" groups in the rest -of this document. - -Removing a directory will move all tasks and cpus owned by the group it -represents to the parent. Removing one of the created CTRL_MON groups -will automatically remove all MON groups below it. - -All groups contain the following files: - -"tasks": - Reading this file shows the list of all tasks that belong to - this group. Writing a task id to the file will add a task to the - group. If the group is a CTRL_MON group the task is removed from - whichever previous CTRL_MON group owned the task and also from - any MON group that owned the task. If the group is a MON group, - then the task must already belong to the CTRL_MON parent of this - group. The task is removed from any previous MON group. - - -"cpus": - Reading this file shows a bitmask of the logical CPUs owned by - this group. Writing a mask to this file will add and remove - CPUs to/from this group. As with the tasks file a hierarchy is - maintained where MON groups may only include CPUs owned by the - parent CTRL_MON group. - When the resource group is in pseudo-locked mode this file will - only be readable, reflecting the CPUs associated with the - pseudo-locked region. - - -"cpus_list": - Just like "cpus", only using ranges of CPUs instead of bitmasks. - - -When control is enabled all CTRL_MON groups will also contain: - -"schemata": - A list of all the resources available to this group. - Each resource has its own line and format - see below for details. - -"size": - Mirrors the display of the "schemata" file to display the size in - bytes of each allocation instead of the bits representing the - allocation. - -"mode": - The "mode" of the resource group dictates the sharing of its - allocations. A "shareable" resource group allows sharing of its - allocations while an "exclusive" resource group does not. A - cache pseudo-locked region is created by first writing - "pseudo-locksetup" to the "mode" file before writing the cache - pseudo-locked region's schemata to the resource group's "schemata" - file. On successful pseudo-locked region creation the mode will - automatically change to "pseudo-locked". - -When monitoring is enabled all MON groups will also contain: - -"mon_data": - This contains a set of files organized by L3 domain and by - RDT event. E.g. on a system with two L3 domains there will - be subdirectories "mon_L3_00" and "mon_L3_01". Each of these - directories have one file per event (e.g. "llc_occupancy", - "mbm_total_bytes", and "mbm_local_bytes"). In a MON group these - files provide a read out of the current value of the event for - all tasks in the group. In CTRL_MON groups these files provide - the sum for all tasks in the CTRL_MON group and all tasks in - MON groups. Please see example section for more details on usage. - -Resource allocation rules -------------------------- - -When a task is running the following rules define which resources are -available to it: - -1) If the task is a member of a non-default group, then the schemata - for that group is used. - -2) Else if the task belongs to the default group, but is running on a - CPU that is assigned to some specific group, then the schemata for the - CPU's group is used. - -3) Otherwise the schemata for the default group is used. - -Resource monitoring rules -------------------------- -1) If a task is a member of a MON group, or non-default CTRL_MON group - then RDT events for the task will be reported in that group. - -2) If a task is a member of the default CTRL_MON group, but is running - on a CPU that is assigned to some specific group, then the RDT events - for the task will be reported in that group. - -3) Otherwise RDT events for the task will be reported in the root level - "mon_data" group. - - -Notes on cache occupancy monitoring and control -=============================================== -When moving a task from one group to another you should remember that -this only affects *new* cache allocations by the task. E.g. you may have -a task in a monitor group showing 3 MB of cache occupancy. If you move -to a new group and immediately check the occupancy of the old and new -groups you will likely see that the old group is still showing 3 MB and -the new group zero. When the task accesses locations still in cache from -before the move, the h/w does not update any counters. On a busy system -you will likely see the occupancy in the old group go down as cache lines -are evicted and re-used while the occupancy in the new group rises as -the task accesses memory and loads into the cache are counted based on -membership in the new group. - -The same applies to cache allocation control. Moving a task to a group -with a smaller cache partition will not evict any cache lines. The -process may continue to use them from the old partition. - -Hardware uses CLOSid(Class of service ID) and an RMID(Resource monitoring ID) -to identify a control group and a monitoring group respectively. Each of -the resource groups are mapped to these IDs based on the kind of group. The -number of CLOSid and RMID are limited by the hardware and hence the creation of -a "CTRL_MON" directory may fail if we run out of either CLOSID or RMID -and creation of "MON" group may fail if we run out of RMIDs. - -max_threshold_occupancy - generic concepts ------------------------------------------- - -Note that an RMID once freed may not be immediately available for use as -the RMID is still tagged the cache lines of the previous user of RMID. -Hence such RMIDs are placed on limbo list and checked back if the cache -occupancy has gone down. If there is a time when system has a lot of -limbo RMIDs but which are not ready to be used, user may see an -EBUSY -during mkdir. - -max_threshold_occupancy is a user configurable value to determine the -occupancy at which an RMID can be freed. - -Schemata files - general concepts ---------------------------------- -Each line in the file describes one resource. The line starts with -the name of the resource, followed by specific values to be applied -in each of the instances of that resource on the system. - -Cache IDs ---------- -On current generation systems there is one L3 cache per socket and L2 -caches are generally just shared by the hyperthreads on a core, but this -isn't an architectural requirement. We could have multiple separate L3 -caches on a socket, multiple cores could share an L2 cache. So instead -of using "socket" or "core" to define the set of logical cpus sharing -a resource we use a "Cache ID". At a given cache level this will be a -unique number across the whole system (but it isn't guaranteed to be a -contiguous sequence, there may be gaps). To find the ID for each logical -CPU look in /sys/devices/system/cpu/cpu*/cache/index*/id - -Cache Bit Masks (CBM) ---------------------- -For cache resources we describe the portion of the cache that is available -for allocation using a bitmask. The maximum value of the mask is defined -by each cpu model (and may be different for different cache levels). It -is found using CPUID, but is also provided in the "info" directory of -the resctrl file system in "info/{resource}/cbm_mask". Intel hardware -requires that these masks have all the '1' bits in a contiguous block. So -0x3, 0x6 and 0xC are legal 4-bit masks with two bits set, but 0x5, 0x9 -and 0xA are not. On a system with a 20-bit mask each bit represents 5% -of the capacity of the cache. You could partition the cache into four -equal parts with masks: 0x1f, 0x3e0, 0x7c00, 0xf8000. - -Memory bandwidth Allocation and monitoring -========================================== - -For Memory bandwidth resource, by default the user controls the resource -by indicating the percentage of total memory bandwidth. - -The minimum bandwidth percentage value for each cpu model is predefined -and can be looked up through "info/MB/min_bandwidth". The bandwidth -granularity that is allocated is also dependent on the cpu model and can -be looked up at "info/MB/bandwidth_gran". The available bandwidth -control steps are: min_bw + N * bw_gran. Intermediate values are rounded -to the next control step available on the hardware. - -The bandwidth throttling is a core specific mechanism on some of Intel -SKUs. Using a high bandwidth and a low bandwidth setting on two threads -sharing a core may result in both threads being throttled to use the -low bandwidth (see "thread_throttle_mode"). - -The fact that Memory bandwidth allocation(MBA) may be a core -specific mechanism where as memory bandwidth monitoring(MBM) is done at -the package level may lead to confusion when users try to apply control -via the MBA and then monitor the bandwidth to see if the controls are -effective. Below are such scenarios: - -1. User may *not* see increase in actual bandwidth when percentage - values are increased: - -This can occur when aggregate L2 external bandwidth is more than L3 -external bandwidth. Consider an SKL SKU with 24 cores on a package and -where L2 external is 10GBps (hence aggregate L2 external bandwidth is -240GBps) and L3 external bandwidth is 100GBps. Now a workload with '20 -threads, having 50% bandwidth, each consuming 5GBps' consumes the max L3 -bandwidth of 100GBps although the percentage value specified is only 50% -<< 100%. Hence increasing the bandwidth percentage will not yield any -more bandwidth. This is because although the L2 external bandwidth still -has capacity, the L3 external bandwidth is fully used. Also note that -this would be dependent on number of cores the benchmark is run on. - -2. Same bandwidth percentage may mean different actual bandwidth - depending on # of threads: - -For the same SKU in #1, a 'single thread, with 10% bandwidth' and '4 -thread, with 10% bandwidth' can consume upto 10GBps and 40GBps although -they have same percentage bandwidth of 10%. This is simply because as -threads start using more cores in an rdtgroup, the actual bandwidth may -increase or vary although user specified bandwidth percentage is same. - -In order to mitigate this and make the interface more user friendly, -resctrl added support for specifying the bandwidth in MBps as well. The -kernel underneath would use a software feedback mechanism or a "Software -Controller(mba_sc)" which reads the actual bandwidth using MBM counters -and adjust the memory bandwidth percentages to ensure:: - - "actual bandwidth < user specified bandwidth". - -By default, the schemata would take the bandwidth percentage values -where as user can switch to the "MBA software controller" mode using -a mount option 'mba_MBps'. The schemata format is specified in the below -sections. - -L3 schemata file details (code and data prioritization disabled) ----------------------------------------------------------------- -With CDP disabled the L3 schemata format is:: - - L3:=;=;... - -L3 schemata file details (CDP enabled via mount option to resctrl) ------------------------------------------------------------------- -When CDP is enabled L3 control is split into two separate resources -so you can specify independent masks for code and data like this:: - - L3DATA:=;=;... - L3CODE:=;=;... - -L2 schemata file details ------------------------- -CDP is supported at L2 using the 'cdpl2' mount option. The schemata -format is either:: - - L2:=;=;... - -or - - L2DATA:=;=;... - L2CODE:=;=;... - - -Memory bandwidth Allocation (default mode) ------------------------------------------- - -Memory b/w domain is L3 cache. -:: - - MB:=bandwidth0;=bandwidth1;... - -Memory bandwidth Allocation specified in MBps ---------------------------------------------- - -Memory bandwidth domain is L3 cache. -:: - - MB:=bw_MBps0;=bw_MBps1;... - -Reading/writing the schemata file ---------------------------------- -Reading the schemata file will show the state of all resources -on all domains. When writing you only need to specify those values -which you wish to change. E.g. -:: - - # cat schemata - L3DATA:0=fffff;1=fffff;2=fffff;3=fffff - L3CODE:0=fffff;1=fffff;2=fffff;3=fffff - # echo "L3DATA:2=3c0;" > schemata - # cat schemata - L3DATA:0=fffff;1=fffff;2=3c0;3=fffff - L3CODE:0=fffff;1=fffff;2=fffff;3=fffff - -Cache Pseudo-Locking -==================== -CAT enables a user to specify the amount of cache space that an -application can fill. Cache pseudo-locking builds on the fact that a -CPU can still read and write data pre-allocated outside its current -allocated area on a cache hit. With cache pseudo-locking, data can be -preloaded into a reserved portion of cache that no application can -fill, and from that point on will only serve cache hits. The cache -pseudo-locked memory is made accessible to user space where an -application can map it into its virtual address space and thus have -a region of memory with reduced average read latency. - -The creation of a cache pseudo-locked region is triggered by a request -from the user to do so that is accompanied by a schemata of the region -to be pseudo-locked. The cache pseudo-locked region is created as follows: - -- Create a CAT allocation CLOSNEW with a CBM matching the schemata - from the user of the cache region that will contain the pseudo-locked - memory. This region must not overlap with any current CAT allocation/CLOS - on the system and no future overlap with this cache region is allowed - while the pseudo-locked region exists. -- Create a contiguous region of memory of the same size as the cache - region. -- Flush the cache, disable hardware prefetchers, disable preemption. -- Make CLOSNEW the active CLOS and touch the allocated memory to load - it into the cache. -- Set the previous CLOS as active. -- At this point the closid CLOSNEW can be released - the cache - pseudo-locked region is protected as long as its CBM does not appear in - any CAT allocation. Even though the cache pseudo-locked region will from - this point on not appear in any CBM of any CLOS an application running with - any CLOS will be able to access the memory in the pseudo-locked region since - the region continues to serve cache hits. -- The contiguous region of memory loaded into the cache is exposed to - user-space as a character device. - -Cache pseudo-locking increases the probability that data will remain -in the cache via carefully configuring the CAT feature and controlling -application behavior. There is no guarantee that data is placed in -cache. Instructions like INVD, WBINVD, CLFLUSH, etc. can still evict -“locked” data from cache. Power management C-states may shrink or -power off cache. Deeper C-states will automatically be restricted on -pseudo-locked region creation. - -It is required that an application using a pseudo-locked region runs -with affinity to the cores (or a subset of the cores) associated -with the cache on which the pseudo-locked region resides. A sanity check -within the code will not allow an application to map pseudo-locked memory -unless it runs with affinity to cores associated with the cache on which the -pseudo-locked region resides. The sanity check is only done during the -initial mmap() handling, there is no enforcement afterwards and the -application self needs to ensure it remains affine to the correct cores. - -Pseudo-locking is accomplished in two stages: - -1) During the first stage the system administrator allocates a portion - of cache that should be dedicated to pseudo-locking. At this time an - equivalent portion of memory is allocated, loaded into allocated - cache portion, and exposed as a character device. -2) During the second stage a user-space application maps (mmap()) the - pseudo-locked memory into its address space. - -Cache Pseudo-Locking Interface ------------------------------- -A pseudo-locked region is created using the resctrl interface as follows: - -1) Create a new resource group by creating a new directory in /sys/fs/resctrl. -2) Change the new resource group's mode to "pseudo-locksetup" by writing - "pseudo-locksetup" to the "mode" file. -3) Write the schemata of the pseudo-locked region to the "schemata" file. All - bits within the schemata should be "unused" according to the "bit_usage" - file. - -On successful pseudo-locked region creation the "mode" file will contain -"pseudo-locked" and a new character device with the same name as the resource -group will exist in /dev/pseudo_lock. This character device can be mmap()'ed -by user space in order to obtain access to the pseudo-locked memory region. - -An example of cache pseudo-locked region creation and usage can be found below. - -Cache Pseudo-Locking Debugging Interface ----------------------------------------- -The pseudo-locking debugging interface is enabled by default (if -CONFIG_DEBUG_FS is enabled) and can be found in /sys/kernel/debug/resctrl. - -There is no explicit way for the kernel to test if a provided memory -location is present in the cache. The pseudo-locking debugging interface uses -the tracing infrastructure to provide two ways to measure cache residency of -the pseudo-locked region: - -1) Memory access latency using the pseudo_lock_mem_latency tracepoint. Data - from these measurements are best visualized using a hist trigger (see - example below). In this test the pseudo-locked region is traversed at - a stride of 32 bytes while hardware prefetchers and preemption - are disabled. This also provides a substitute visualization of cache - hits and misses. -2) Cache hit and miss measurements using model specific precision counters if - available. Depending on the levels of cache on the system the pseudo_lock_l2 - and pseudo_lock_l3 tracepoints are available. - -When a pseudo-locked region is created a new debugfs directory is created for -it in debugfs as /sys/kernel/debug/resctrl/. A single -write-only file, pseudo_lock_measure, is present in this directory. The -measurement of the pseudo-locked region depends on the number written to this -debugfs file: - -1: - writing "1" to the pseudo_lock_measure file will trigger the latency - measurement captured in the pseudo_lock_mem_latency tracepoint. See - example below. -2: - writing "2" to the pseudo_lock_measure file will trigger the L2 cache - residency (cache hits and misses) measurement captured in the - pseudo_lock_l2 tracepoint. See example below. -3: - writing "3" to the pseudo_lock_measure file will trigger the L3 cache - residency (cache hits and misses) measurement captured in the - pseudo_lock_l3 tracepoint. - -All measurements are recorded with the tracing infrastructure. This requires -the relevant tracepoints to be enabled before the measurement is triggered. - -Example of latency debugging interface -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -In this example a pseudo-locked region named "newlock" was created. Here is -how we can measure the latency in cycles of reading from this region and -visualize this data with a histogram that is available if CONFIG_HIST_TRIGGERS -is set:: - - # :> /sys/kernel/debug/tracing/trace - # echo 'hist:keys=latency' > /sys/kernel/debug/tracing/events/resctrl/pseudo_lock_mem_latency/trigger - # echo 1 > /sys/kernel/debug/tracing/events/resctrl/pseudo_lock_mem_latency/enable - # echo 1 > /sys/kernel/debug/resctrl/newlock/pseudo_lock_measure - # echo 0 > /sys/kernel/debug/tracing/events/resctrl/pseudo_lock_mem_latency/enable - # cat /sys/kernel/debug/tracing/events/resctrl/pseudo_lock_mem_latency/hist - - # event histogram - # - # trigger info: hist:keys=latency:vals=hitcount:sort=hitcount:size=2048 [active] - # - - { latency: 456 } hitcount: 1 - { latency: 50 } hitcount: 83 - { latency: 36 } hitcount: 96 - { latency: 44 } hitcount: 174 - { latency: 48 } hitcount: 195 - { latency: 46 } hitcount: 262 - { latency: 42 } hitcount: 693 - { latency: 40 } hitcount: 3204 - { latency: 38 } hitcount: 3484 - - Totals: - Hits: 8192 - Entries: 9 - Dropped: 0 - -Example of cache hits/misses debugging -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -In this example a pseudo-locked region named "newlock" was created on the L2 -cache of a platform. Here is how we can obtain details of the cache hits -and misses using the platform's precision counters. -:: - - # :> /sys/kernel/debug/tracing/trace - # echo 1 > /sys/kernel/debug/tracing/events/resctrl/pseudo_lock_l2/enable - # echo 2 > /sys/kernel/debug/resctrl/newlock/pseudo_lock_measure - # echo 0 > /sys/kernel/debug/tracing/events/resctrl/pseudo_lock_l2/enable - # cat /sys/kernel/debug/tracing/trace - - # tracer: nop - # - # _-----=> irqs-off - # / _----=> need-resched - # | / _---=> hardirq/softirq - # || / _--=> preempt-depth - # ||| / delay - # TASK-PID CPU# |||| TIMESTAMP FUNCTION - # | | | |||| | | - pseudo_lock_mea-1672 [002] .... 3132.860500: pseudo_lock_l2: hits=4097 miss=0 - - -Examples for RDT allocation usage -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - -1) Example 1 - -On a two socket machine (one L3 cache per socket) with just four bits -for cache bit masks, minimum b/w of 10% with a memory bandwidth -granularity of 10%. -:: - - # mount -t resctrl resctrl /sys/fs/resctrl - # cd /sys/fs/resctrl - # mkdir p0 p1 - # echo "L3:0=3;1=c\nMB:0=50;1=50" > /sys/fs/resctrl/p0/schemata - # echo "L3:0=3;1=3\nMB:0=50;1=50" > /sys/fs/resctrl/p1/schemata - -The default resource group is unmodified, so we have access to all parts -of all caches (its schemata file reads "L3:0=f;1=f"). - -Tasks that are under the control of group "p0" may only allocate from the -"lower" 50% on cache ID 0, and the "upper" 50% of cache ID 1. -Tasks in group "p1" use the "lower" 50% of cache on both sockets. - -Similarly, tasks that are under the control of group "p0" may use a -maximum memory b/w of 50% on socket0 and 50% on socket 1. -Tasks in group "p1" may also use 50% memory b/w on both sockets. -Note that unlike cache masks, memory b/w cannot specify whether these -allocations can overlap or not. The allocations specifies the maximum -b/w that the group may be able to use and the system admin can configure -the b/w accordingly. - -If resctrl is using the software controller (mba_sc) then user can enter the -max b/w in MB rather than the percentage values. -:: - - # echo "L3:0=3;1=c\nMB:0=1024;1=500" > /sys/fs/resctrl/p0/schemata - # echo "L3:0=3;1=3\nMB:0=1024;1=500" > /sys/fs/resctrl/p1/schemata - -In the above example the tasks in "p1" and "p0" on socket 0 would use a max b/w -of 1024MB where as on socket 1 they would use 500MB. - -2) Example 2 - -Again two sockets, but this time with a more realistic 20-bit mask. - -Two real time tasks pid=1234 running on processor 0 and pid=5678 running on -processor 1 on socket 0 on a 2-socket and dual core machine. To avoid noisy -neighbors, each of the two real-time tasks exclusively occupies one quarter -of L3 cache on socket 0. -:: - - # mount -t resctrl resctrl /sys/fs/resctrl - # cd /sys/fs/resctrl - -First we reset the schemata for the default group so that the "upper" -50% of the L3 cache on socket 0 and 50% of memory b/w cannot be used by -ordinary tasks:: - - # echo "L3:0=3ff;1=fffff\nMB:0=50;1=100" > schemata - -Next we make a resource group for our first real time task and give -it access to the "top" 25% of the cache on socket 0. -:: - - # mkdir p0 - # echo "L3:0=f8000;1=fffff" > p0/schemata - -Finally we move our first real time task into this resource group. We -also use taskset(1) to ensure the task always runs on a dedicated CPU -on socket 0. Most uses of resource groups will also constrain which -processors tasks run on. -:: - - # echo 1234 > p0/tasks - # taskset -cp 1 1234 - -Ditto for the second real time task (with the remaining 25% of cache):: - - # mkdir p1 - # echo "L3:0=7c00;1=fffff" > p1/schemata - # echo 5678 > p1/tasks - # taskset -cp 2 5678 - -For the same 2 socket system with memory b/w resource and CAT L3 the -schemata would look like(Assume min_bandwidth 10 and bandwidth_gran is -10): - -For our first real time task this would request 20% memory b/w on socket 0. -:: - - # echo -e "L3:0=f8000;1=fffff\nMB:0=20;1=100" > p0/schemata - -For our second real time task this would request an other 20% memory b/w -on socket 0. -:: - - # echo -e "L3:0=f8000;1=fffff\nMB:0=20;1=100" > p0/schemata - -3) Example 3 - -A single socket system which has real-time tasks running on core 4-7 and -non real-time workload assigned to core 0-3. The real-time tasks share text -and data, so a per task association is not required and due to interaction -with the kernel it's desired that the kernel on these cores shares L3 with -the tasks. -:: - - # mount -t resctrl resctrl /sys/fs/resctrl - # cd /sys/fs/resctrl - -First we reset the schemata for the default group so that the "upper" -50% of the L3 cache on socket 0, and 50% of memory bandwidth on socket 0 -cannot be used by ordinary tasks:: - - # echo "L3:0=3ff\nMB:0=50" > schemata - -Next we make a resource group for our real time cores and give it access -to the "top" 50% of the cache on socket 0 and 50% of memory bandwidth on -socket 0. -:: - - # mkdir p0 - # echo "L3:0=ffc00\nMB:0=50" > p0/schemata - -Finally we move core 4-7 over to the new group and make sure that the -kernel and the tasks running there get 50% of the cache. They should -also get 50% of memory bandwidth assuming that the cores 4-7 are SMT -siblings and only the real time threads are scheduled on the cores 4-7. -:: - - # echo F0 > p0/cpus - -4) Example 4 - -The resource groups in previous examples were all in the default "shareable" -mode allowing sharing of their cache allocations. If one resource group -configures a cache allocation then nothing prevents another resource group -to overlap with that allocation. - -In this example a new exclusive resource group will be created on a L2 CAT -system with two L2 cache instances that can be configured with an 8-bit -capacity bitmask. The new exclusive resource group will be configured to use -25% of each cache instance. -:: - - # mount -t resctrl resctrl /sys/fs/resctrl/ - # cd /sys/fs/resctrl - -First, we observe that the default group is configured to allocate to all L2 -cache:: - - # cat schemata - L2:0=ff;1=ff - -We could attempt to create the new resource group at this point, but it will -fail because of the overlap with the schemata of the default group:: - - # mkdir p0 - # echo 'L2:0=0x3;1=0x3' > p0/schemata - # cat p0/mode - shareable - # echo exclusive > p0/mode - -sh: echo: write error: Invalid argument - # cat info/last_cmd_status - schemata overlaps - -To ensure that there is no overlap with another resource group the default -resource group's schemata has to change, making it possible for the new -resource group to become exclusive. -:: - - # echo 'L2:0=0xfc;1=0xfc' > schemata - # echo exclusive > p0/mode - # grep . p0/* - p0/cpus:0 - p0/mode:exclusive - p0/schemata:L2:0=03;1=03 - p0/size:L2:0=262144;1=262144 - -A new resource group will on creation not overlap with an exclusive resource -group:: - - # mkdir p1 - # grep . p1/* - p1/cpus:0 - p1/mode:shareable - p1/schemata:L2:0=fc;1=fc - p1/size:L2:0=786432;1=786432 - -The bit_usage will reflect how the cache is used:: - - # cat info/L2/bit_usage - 0=SSSSSSEE;1=SSSSSSEE - -A resource group cannot be forced to overlap with an exclusive resource group:: - - # echo 'L2:0=0x1;1=0x1' > p1/schemata - -sh: echo: write error: Invalid argument - # cat info/last_cmd_status - overlaps with exclusive group - -Example of Cache Pseudo-Locking -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Lock portion of L2 cache from cache id 1 using CBM 0x3. Pseudo-locked -region is exposed at /dev/pseudo_lock/newlock that can be provided to -application for argument to mmap(). -:: - - # mount -t resctrl resctrl /sys/fs/resctrl/ - # cd /sys/fs/resctrl - -Ensure that there are bits available that can be pseudo-locked, since only -unused bits can be pseudo-locked the bits to be pseudo-locked needs to be -removed from the default resource group's schemata:: - - # cat info/L2/bit_usage - 0=SSSSSSSS;1=SSSSSSSS - # echo 'L2:1=0xfc' > schemata - # cat info/L2/bit_usage - 0=SSSSSSSS;1=SSSSSS00 - -Create a new resource group that will be associated with the pseudo-locked -region, indicate that it will be used for a pseudo-locked region, and -configure the requested pseudo-locked region capacity bitmask:: - - # mkdir newlock - # echo pseudo-locksetup > newlock/mode - # echo 'L2:1=0x3' > newlock/schemata - -On success the resource group's mode will change to pseudo-locked, the -bit_usage will reflect the pseudo-locked region, and the character device -exposing the pseudo-locked region will exist:: - - # cat newlock/mode - pseudo-locked - # cat info/L2/bit_usage - 0=SSSSSSSS;1=SSSSSSPP - # ls -l /dev/pseudo_lock/newlock - crw------- 1 root root 243, 0 Apr 3 05:01 /dev/pseudo_lock/newlock - -:: - - /* - * Example code to access one page of pseudo-locked cache region - * from user space. - */ - #define _GNU_SOURCE - #include - #include - #include - #include - #include - #include - - /* - * It is required that the application runs with affinity to only - * cores associated with the pseudo-locked region. Here the cpu - * is hardcoded for convenience of example. - */ - static int cpuid = 2; - - int main(int argc, char *argv[]) - { - cpu_set_t cpuset; - long page_size; - void *mapping; - int dev_fd; - int ret; - - page_size = sysconf(_SC_PAGESIZE); - - CPU_ZERO(&cpuset); - CPU_SET(cpuid, &cpuset); - ret = sched_setaffinity(0, sizeof(cpuset), &cpuset); - if (ret < 0) { - perror("sched_setaffinity"); - exit(EXIT_FAILURE); - } - - dev_fd = open("/dev/pseudo_lock/newlock", O_RDWR); - if (dev_fd < 0) { - perror("open"); - exit(EXIT_FAILURE); - } - - mapping = mmap(0, page_size, PROT_READ | PROT_WRITE, MAP_SHARED, - dev_fd, 0); - if (mapping == MAP_FAILED) { - perror("mmap"); - close(dev_fd); - exit(EXIT_FAILURE); - } - - /* Application interacts with pseudo-locked memory @mapping */ - - ret = munmap(mapping, page_size); - if (ret < 0) { - perror("munmap"); - close(dev_fd); - exit(EXIT_FAILURE); - } - - close(dev_fd); - exit(EXIT_SUCCESS); - } - -Locking between applications ----------------------------- - -Certain operations on the resctrl filesystem, composed of read/writes -to/from multiple files, must be atomic. - -As an example, the allocation of an exclusive reservation of L3 cache -involves: - - 1. Read the cbmmasks from each directory or the per-resource "bit_usage" - 2. Find a contiguous set of bits in the global CBM bitmask that is clear - in any of the directory cbmmasks - 3. Create a new directory - 4. Set the bits found in step 2 to the new directory "schemata" file - -If two applications attempt to allocate space concurrently then they can -end up allocating the same bits so the reservations are shared instead of -exclusive. - -To coordinate atomic operations on the resctrlfs and to avoid the problem -above, the following locking procedure is recommended: - -Locking is based on flock, which is available in libc and also as a shell -script command - -Write lock: - - A) Take flock(LOCK_EX) on /sys/fs/resctrl - B) Read/write the directory structure. - C) funlock - -Read lock: - - A) Take flock(LOCK_SH) on /sys/fs/resctrl - B) If success read the directory structure. - C) funlock - -Example with bash:: - - # Atomically read directory structure - $ flock -s /sys/fs/resctrl/ find /sys/fs/resctrl - - # Read directory contents and create new subdirectory - - $ cat create-dir.sh - find /sys/fs/resctrl/ > output.txt - mask = function-of(output.txt) - mkdir /sys/fs/resctrl/newres/ - echo mask > /sys/fs/resctrl/newres/schemata - - $ flock /sys/fs/resctrl/ ./create-dir.sh - -Example with C:: - - /* - * Example code do take advisory locks - * before accessing resctrl filesystem - */ - #include - #include - - void resctrl_take_shared_lock(int fd) - { - int ret; - - /* take shared lock on resctrl filesystem */ - ret = flock(fd, LOCK_SH); - if (ret) { - perror("flock"); - exit(-1); - } - } - - void resctrl_take_exclusive_lock(int fd) - { - int ret; - - /* release lock on resctrl filesystem */ - ret = flock(fd, LOCK_EX); - if (ret) { - perror("flock"); - exit(-1); - } - } - - void resctrl_release_lock(int fd) - { - int ret; - - /* take shared lock on resctrl filesystem */ - ret = flock(fd, LOCK_UN); - if (ret) { - perror("flock"); - exit(-1); - } - } - - void main(void) - { - int fd, ret; - - fd = open("/sys/fs/resctrl", O_DIRECTORY); - if (fd == -1) { - perror("open"); - exit(-1); - } - resctrl_take_shared_lock(fd); - /* code to read directory contents */ - resctrl_release_lock(fd); - - resctrl_take_exclusive_lock(fd); - /* code to read and write directory contents */ - resctrl_release_lock(fd); - } - -Examples for RDT Monitoring along with allocation usage -======================================================= -Reading monitored data ----------------------- -Reading an event file (for ex: mon_data/mon_L3_00/llc_occupancy) would -show the current snapshot of LLC occupancy of the corresponding MON -group or CTRL_MON group. - - -Example 1 (Monitor CTRL_MON group and subset of tasks in CTRL_MON group) ------------------------------------------------------------------------- -On a two socket machine (one L3 cache per socket) with just four bits -for cache bit masks:: - - # mount -t resctrl resctrl /sys/fs/resctrl - # cd /sys/fs/resctrl - # mkdir p0 p1 - # echo "L3:0=3;1=c" > /sys/fs/resctrl/p0/schemata - # echo "L3:0=3;1=3" > /sys/fs/resctrl/p1/schemata - # echo 5678 > p1/tasks - # echo 5679 > p1/tasks - -The default resource group is unmodified, so we have access to all parts -of all caches (its schemata file reads "L3:0=f;1=f"). - -Tasks that are under the control of group "p0" may only allocate from the -"lower" 50% on cache ID 0, and the "upper" 50% of cache ID 1. -Tasks in group "p1" use the "lower" 50% of cache on both sockets. - -Create monitor groups and assign a subset of tasks to each monitor group. -:: - - # cd /sys/fs/resctrl/p1/mon_groups - # mkdir m11 m12 - # echo 5678 > m11/tasks - # echo 5679 > m12/tasks - -fetch data (data shown in bytes) -:: - - # cat m11/mon_data/mon_L3_00/llc_occupancy - 16234000 - # cat m11/mon_data/mon_L3_01/llc_occupancy - 14789000 - # cat m12/mon_data/mon_L3_00/llc_occupancy - 16789000 - -The parent ctrl_mon group shows the aggregated data. -:: - - # cat /sys/fs/resctrl/p1/mon_data/mon_l3_00/llc_occupancy - 31234000 - -Example 2 (Monitor a task from its creation) --------------------------------------------- -On a two socket machine (one L3 cache per socket):: - - # mount -t resctrl resctrl /sys/fs/resctrl - # cd /sys/fs/resctrl - # mkdir p0 p1 - -An RMID is allocated to the group once its created and hence the -below is monitored from its creation. -:: - - # echo $$ > /sys/fs/resctrl/p1/tasks - # - -Fetch the data:: - - # cat /sys/fs/resctrl/p1/mon_data/mon_l3_00/llc_occupancy - 31789000 - -Example 3 (Monitor without CAT support or before creating CAT groups) ---------------------------------------------------------------------- - -Assume a system like HSW has only CQM and no CAT support. In this case -the resctrl will still mount but cannot create CTRL_MON directories. -But user can create different MON groups within the root group thereby -able to monitor all tasks including kernel threads. - -This can also be used to profile jobs cache size footprint before being -able to allocate them to different allocation groups. -:: - - # mount -t resctrl resctrl /sys/fs/resctrl - # cd /sys/fs/resctrl - # mkdir mon_groups/m01 - # mkdir mon_groups/m02 - - # echo 3478 > /sys/fs/resctrl/mon_groups/m01/tasks - # echo 2467 > /sys/fs/resctrl/mon_groups/m02/tasks - -Monitor the groups separately and also get per domain data. From the -below its apparent that the tasks are mostly doing work on -domain(socket) 0. -:: - - # cat /sys/fs/resctrl/mon_groups/m01/mon_L3_00/llc_occupancy - 31234000 - # cat /sys/fs/resctrl/mon_groups/m01/mon_L3_01/llc_occupancy - 34555 - # cat /sys/fs/resctrl/mon_groups/m02/mon_L3_00/llc_occupancy - 31234000 - # cat /sys/fs/resctrl/mon_groups/m02/mon_L3_01/llc_occupancy - 32789 - - -Example 4 (Monitor real time tasks) ------------------------------------ - -A single socket system which has real time tasks running on cores 4-7 -and non real time tasks on other cpus. We want to monitor the cache -occupancy of the real time threads on these cores. -:: - - # mount -t resctrl resctrl /sys/fs/resctrl - # cd /sys/fs/resctrl - # mkdir p1 - -Move the cpus 4-7 over to p1:: - - # echo f0 > p1/cpus - -View the llc occupancy snapshot:: - - # cat /sys/fs/resctrl/p1/mon_data/mon_L3_00/llc_occupancy - 11234000 -- cgit v1.2.3 From 7ead9dbb6ff475ec616adbb97dedcb26400fbb0c Mon Sep 17 00:00:00 2001 From: Matthias Schiffer Date: Fri, 18 Sep 2020 13:29:30 +0200 Subject: dt-bindings: arm: fsl: update TQ-Systems SoMs and boards based on i.MX7 Introduce compatible strings for the TQMa7x SoMs. Signed-off-by: Matthias Schiffer Reviewed-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 1ca9dfa8ce9a..b0db3c90914b 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -354,7 +354,12 @@ properties: - toradex,colibri-imx7s # Colibri iMX7 Solo Module - toradex,colibri-imx7s-aster # Colibri iMX7 Solo Module on Aster Carrier Board - toradex,colibri-imx7s-eval-v3 # Colibri iMX7 Solo Module on Colibri Evaluation Board V3 - - tq,imx7s-mba7 # i.MX7S TQ MBa7 with TQMa7S SoM + - const: fsl,imx7s + + - description: TQ-Systems TQMa7S SoM on MBa7x board + items: + - const: tq,imx7s-mba7 + - const: tq,imx7s-tqma7 - const: fsl,imx7s - description: i.MX7D based Boards @@ -376,11 +381,16 @@ properties: # Colibri Evaluation Board V3 - toradex,colibri-imx7d-eval-v3 # Colibri iMX7 Dual Module on # Colibri Evaluation Board V3 - - tq,imx7d-mba7 # i.MX7D TQ MBa7 with TQMa7D SoM - zii,imx7d-rmu2 # ZII RMU2 Board - zii,imx7d-rpu2 # ZII RPU2 Board - const: fsl,imx7d + - description: TQ-Systems TQMa7D SoM on MBa7x board + items: + - const: tq,imx7d-mba7 + - const: tq,imx7d-tqma7 + - const: fsl,imx7d + - description: Compulab SBC-iMX7 is a single board computer based on the Freescale i.MX7 system-on-chip. SBC-iMX7 is implemented with -- cgit v1.2.3 From e8a60aa7404bfef37705da5607c97737073ac38d Mon Sep 17 00:00:00 2001 From: Divya Bharathi Date: Tue, 27 Oct 2020 19:19:44 +0530 Subject: platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems The Dell WMI Systems Management Driver provides a sysfs interface for systems management to enable BIOS configuration capability on certain Dell Systems. This driver allows user to configure Dell systems with a uniform common interface. To facilitate this, the patch introduces a generic way for driver to be able to create configurable BIOS Attributes available in Setup (F2) screen. Cc: Hans de Goede Cc: Andy Shevchenko Cc: mark gross Co-developed-by: Mario Limonciello Signed-off-by: Mario Limonciello Co-developed-by: Prasanth KSR Signed-off-by: Prasanth KSR Signed-off-by: Divya Bharathi Link: https://lore.kernel.org/r/20201027134944.316730-1-divya.bharathi@dell.com Reviewed-by: Hans de Goede Signed-off-by: Hans de Goede --- .../ABI/testing/sysfs-class-firmware-attributes | 224 +++++++++++++++++++++ 1 file changed, 224 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-firmware-attributes (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-class-firmware-attributes b/Documentation/ABI/testing/sysfs-class-firmware-attributes new file mode 100644 index 000000000000..04a15c72e883 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-firmware-attributes @@ -0,0 +1,224 @@ +What: /sys/class/firmware-attributes/*/attributes/*/ +Date: February 2021 +KernelVersion: 5.11 +Contact: Divya Bharathi , + Mario Limonciello , + Prasanth KSR +Description: + A sysfs interface for systems management software to enable + configuration capability on supported systems. This directory + exposes interfaces for interacting with configuration options. + + Unless otherwise specified in an attribute description all attributes are optional + and will accept UTF-8 input. + + type: A file that can be read to obtain the type of attribute. This attribute is + mandatory. + + The following are known types: + - enumeration: a set of pre-defined valid values + - integer: a range of numerical values + - string + + All attribute types support the following values: + + current_value: A file that can be read to obtain the current + value of the . + + This file can also be written to in order to update the value of a + + + This attribute is mandatory. + + default_value: A file that can be read to obtain the default + value of the + + display_name: A file that can be read to obtain a user friendly + description of the at + + display_name_language_code: A file that can be read to obtain + the IETF language tag corresponding to the + "display_name" of the + + "enumeration"-type specific properties: + + possible_values: A file that can be read to obtain the possible + values of the . Values are separated using + semi-colon (``;``). + + "integer"-type specific properties: + + min_value: A file that can be read to obtain the lower + bound value of the + + max_value: A file that can be read to obtain the upper + bound value of the + + scalar_increment: A file that can be read to obtain the scalar value used for + increments of current_value this attribute accepts. + + "string"-type specific properties: + + max_length: A file that can be read to obtain the maximum + length value of the + + min_length: A file that can be read to obtain the minimum + length value of the + + Dell specific class extensions + -------------------------- + + On Dell systems the following additional attributes are available: + + dell_modifier: A file that can be read to obtain attribute-level + dependency rule. It says an attribute X will become read-only or + suppressed, if/if-not attribute Y is configured. + + modifier rules can be in following format: + [ReadOnlyIf:=] + [ReadOnlyIfNot:=] + [SuppressIf:=] + [SuppressIfNot:=] + + For example: + AutoOnFri/dell_modifier has value, + [SuppressIfNot:AutoOn=SelectDays] + + This means AutoOnFri will be suppressed in BIOS setup if AutoOn + attribute is not "SelectDays" and its value will not be effective + through sysfs until this rule is met. + + Enumeration attributes also support the following: + + dell_value_modifier: A file that can be read to obtain value-level dependency. + This file is similar to dell_modifier but here, an + attribute's current value will be forcefully changed based + dependent attributes value. + + dell_value_modifier rules can be in following format: + [ForceIf:=] + [ForceIfNot:=] + + For example, + LegacyOrom/dell_value_modifier has value: + Disabled[ForceIf:SecureBoot=Enabled] + This means LegacyOrom's current value will be forced to + "Disabled" in BIOS setup if SecureBoot is Enabled and its + value will not be effective through sysfs until this rule is + met. + +What: /sys/class/firmware-attributes/*/authentication/ +Date: February 2021 +KernelVersion: 5.11 +Contact: Divya Bharathi , + Mario Limonciello , + Prasanth KSR + + Devices support various authentication mechanisms which can be exposed + as a separate configuration object. + + For example a "BIOS Admin" password and "System" Password can be set, + reset or cleared using these attributes. + - An "Admin" password is used for preventing modification to the BIOS + settings. + - A "System" password is required to boot a machine. + + Change in any of these two authentication methods will also generate an + uevent KOBJ_CHANGE. + + is_enabled: A file that can be read to obtain a 0/1 flag to see if + authentication is enabled. + This attribute is mandatory. + + role: The type of authentication used. + This attribute is mandatory. + Known types: + bios-admin: Representing BIOS administrator password + power-on: Representing a password required to use + the system + + mechanism: The means of authentication. This attribute is mandatory. + Only supported type currently is "password". + + max_password_length: A file that can be read to obtain the + maximum length of the Password + + min_password_length: A file that can be read to obtain the + minimum length of the Password + + current_password: A write only value used for privileged access such as + setting attributes when a system or admin password is set + or resetting to a new password + + This attribute is mandatory when mechanism == "password". + + new_password: A write only value that when used in tandem with + current_password will reset a system or admin password. + + Note, password management is session specific. If Admin password is set, + same password must be written into current_password file (required for + password-validation) and must be cleared once the session is over. + For example: + echo "password" > current_password + echo "disabled" > TouchScreen/current_value + echo "" > current_password + + Drivers may emit a CHANGE uevent when a password is set or unset + userspace may check it again. + + On Dell systems, if Admin password is set, then all BIOS attributes + require password validation. + +What: /sys/class/firmware-attributes/*/attributes/pending_reboot +Date: February 2021 +KernelVersion: 5.11 +Contact: Divya Bharathi , + Mario Limonciello , + Prasanth KSR +Description: + A read-only attribute reads 1 if a reboot is necessary to apply + pending BIOS attribute changes. Also, an uevent_KOBJ_CHANGE is + generated when it changes to 1. + + 0: All BIOS attributes setting are current + 1: A reboot is necessary to get pending BIOS attribute changes + applied + + Note, userspace applications need to follow below steps for efficient + BIOS management, + 1. Check if admin password is set. If yes, follow session method for + password management as briefed under authentication section above. + 2. Before setting any attribute, check if it has any modifiers + or value_modifiers. If yes, incorporate them and then modify + attribute. + + Drivers may emit a CHANGE uevent when this value changes and userspace + may check it again. + +What: /sys/class/firmware-attributes/*/attributes/reset_bios +Date: February 2021 +KernelVersion: 5.11 +Contact: Divya Bharathi , + Mario Limonciello , + Prasanth KSR +Description: + This attribute can be used to reset the BIOS Configuration. + Specifically, it tells which type of reset BIOS configuration is being + requested on the host. + + Reading from it returns a list of supported options encoded as: + + 'builtinsafe' (Built in safe configuration profile) + 'lastknowngood' (Last known good saved configuration profile) + 'factory' (Default factory settings configuration profile) + 'custom' (Custom saved configuration profile) + + The currently selected option is printed in square brackets as + shown below: + + # echo "factory" > /sys/class/firmware-attributes/*/device/attributes/reset_bios + # cat /sys/class/firmware-attributes/*/device/attributes/reset_bios + # builtinsafe lastknowngood [factory] custom + + Note that any changes to this attribute requires a reboot + for changes to take effect. -- cgit v1.2.3 From 9df556d774fda1eb9214c7ab3f1e5d0ec1265bce Mon Sep 17 00:00:00 2001 From: Al Cooper Date: Mon, 12 Oct 2020 16:00:06 -0400 Subject: dt-bindings: Add support for Broadcom USB pin map driver Add DT bindings for the Broadcom USB pin map driver. This driver allows some USB input and output signals to be mapped to any GPIO instead of the normal dedicated pins to/from the XHCI controller. Reviewed-by: Rob Herring Signed-off-by: Al Cooper Link: https://lore.kernel.org/r/20201012200007.8862-2-alcooperx@gmail.com Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/usb/brcm,usb-pinmap.yaml | 70 ++++++++++++++++++++++ 1 file changed, 70 insertions(+) create mode 100644 Documentation/devicetree/bindings/usb/brcm,usb-pinmap.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/usb/brcm,usb-pinmap.yaml b/Documentation/devicetree/bindings/usb/brcm,usb-pinmap.yaml new file mode 100644 index 000000000000..ffa148b9eaa8 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/brcm,usb-pinmap.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/brcm,usb-pinmap.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom USB pin map Controller Device Tree Bindings + +maintainers: + - Al Cooper + +properties: + compatible: + items: + - const: brcm,usb-pinmap + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + description: Interrupt for signals mirrored to out-gpios. + + in-gpios: + description: Array of one or two GPIO pins used for input signals. + + brcm,in-functions: + $ref: /schemas/types.yaml#/definitions/string-array + description: Array of input signal names, one per gpio in in-gpios. + + brcm,in-masks: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: Array of enable and mask pairs, one per gpio in-gpios. + + out-gpios: + description: Array of one GPIO pin used for output signals. + + brcm,out-functions: + $ref: /schemas/types.yaml#/definitions/string-array + description: Array of output signal names, one per gpio in out-gpios. + + brcm,out-masks: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: Array of enable, value, changed and clear masks, one + per gpio in out-gpios. + +required: + - compatible + - reg + +additionalProperties: false + +dependencies: + in-gpios: [ interrupts ] + +examples: + - | + usb_pinmap: usb-pinmap@22000d0 { + compatible = "brcm,usb-pinmap"; + reg = <0x22000d0 0x4>; + in-gpios = <&gpio 18 0>, <&gpio 19 0>; + brcm,in-functions = "VBUS", "PWRFLT"; + brcm,in-masks = <0x8000 0x40000 0x10000 0x80000>; + out-gpios = <&gpio 20 0>; + brcm,out-functions = "PWRON"; + brcm,out-masks = <0x20000 0x800000 0x400000 0x200000>; + interrupts = <0x0 0xb2 0x4>; + }; + +... -- cgit v1.2.3 From 5ed132db5ad4f58156ae9d28219396b6f764a9cb Mon Sep 17 00:00:00 2001 From: Badhri Jagan Sridharan Date: Tue, 20 Oct 2020 02:36:18 -0700 Subject: dt-bindings: connector: Add property to set initial current cap for FRS This change adds frs-typec-current which allows setting the initial current capability of the new source when vSafe5V is applied during PD3.0 sink Fast Role Swap. Signed-off-by: Badhri Jagan Sridharan Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20201020093627.256885-2-badhri@google.com Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/connector/usb-connector.yaml | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml index 728f82db073d..62781518aefc 100644 --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml @@ -147,6 +147,25 @@ properties: required: - port@0 + new-source-frs-typec-current: + description: Initial current capability of the new source when vSafe5V + is applied during PD3.0 Fast Role Swap. "Table 6-14 Fixed Supply PDO - Sink" + of "USB Power Delivery Specification Revision 3.0, Version 1.2" provides the + different power levels and "6.4.1.3.1.6 Fast Role Swap USB Type-C Current" + provides a detailed description of the field. The sink PDO from current source + reflects the current source's(i.e. transmitter of the FRS signal) power + requirement during fr swap. The current sink (i.e. receiver of the FRS signal), + a.k.a new source, should check if it will be able to satisfy the current source's, + new sink's, requirement during frswap before enabling the frs signal reception. + This property refers to maximum current capability that the current sink can + satisfy. During FRS, VBUS voltage is at 5V, as the partners are in implicit + contract, hence, the power level is only a function of the current capability. + "1" refers to default USB power level as described by "Table 6-14 Fixed Supply PDO - Sink". + "2" refers to 1.5A@5V. + "3" refers to 3.0A@5V. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 2, 3] + required: - compatible -- cgit v1.2.3 From f1f37abbe6fc2b1242f78157db76e48dbf9518ee Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Mon, 19 Oct 2020 15:40:46 +0200 Subject: gpio: Retire the explicit gpio irqchip code Now that all gpiolib irqchip users have been over to use the irqchip template, we can finally retire the old code path and leave just one way in to the irqchip: set up the template when registering the gpio_chip. For a while we had two code paths for this which was a bit confusing. This brings this work to a conclusion, there is now one way of doing this. Signed-off-by: Linus Walleij Reviewed-by: Andy Shevchenko Cc: Thierry Reding Link: https://lore.kernel.org/r/20201019134046.65101-1-linus.walleij@linaro.org --- Documentation/driver-api/gpio/driver.rst | 63 +++++++++++++++++++++----------- 1 file changed, 42 insertions(+), 21 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/gpio/driver.rst b/Documentation/driver-api/gpio/driver.rst index 072a7455044e..65d708093b71 100644 --- a/Documentation/driver-api/gpio/driver.rst +++ b/Documentation/driver-api/gpio/driver.rst @@ -416,7 +416,8 @@ The preferred way to set up the helpers is to fill in the struct gpio_irq_chip inside struct gpio_chip before adding the gpio_chip. If you do this, the additional irq_chip will be set up by gpiolib at the same time as setting up the rest of the GPIO functionality. The following -is a typical example of a cascaded interrupt handler using gpio_irq_chip: +is a typical example of a chained cascaded interrupt handler using +the gpio_irq_chip: .. code-block:: c @@ -452,7 +453,46 @@ is a typical example of a cascaded interrupt handler using gpio_irq_chip: return devm_gpiochip_add_data(dev, &g->gc, g); -The helper support using hierarchical interrupt controllers as well. +The helper supports using threaded interrupts as well. Then you just request +the interrupt separately and go with it: + +.. code-block:: c + + /* Typical state container with dynamic irqchip */ + struct my_gpio { + struct gpio_chip gc; + struct irq_chip irq; + }; + + int irq; /* from platform etc */ + struct my_gpio *g; + struct gpio_irq_chip *girq; + + /* Set up the irqchip dynamically */ + g->irq.name = "my_gpio_irq"; + g->irq.irq_ack = my_gpio_ack_irq; + g->irq.irq_mask = my_gpio_mask_irq; + g->irq.irq_unmask = my_gpio_unmask_irq; + g->irq.irq_set_type = my_gpio_set_irq_type; + + ret = devm_request_threaded_irq(dev, irq, NULL, + irq_thread_fn, IRQF_ONESHOT, "my-chip", g); + if (ret < 0) + return ret; + + /* Get a pointer to the gpio_irq_chip */ + girq = &g->gc.irq; + girq->chip = &g->irq; + /* This will let us handle the parent IRQ in the driver */ + girq->parent_handler = NULL; + girq->num_parents = 0; + girq->parents = NULL; + girq->default_type = IRQ_TYPE_NONE; + girq->handler = handle_bad_irq; + + return devm_gpiochip_add_data(dev, &g->gc, g); + +The helper supports using hierarchical interrupt controllers as well. In this case the typical set-up will look like this: .. code-block:: c @@ -493,25 +533,6 @@ the parent hardware irq from a child (i.e. this gpio chip) hardware irq. As always it is good to look at examples in the kernel tree for advice on how to find the required pieces. -The old way of adding irqchips to gpiochips after registration is also still -available but we try to move away from this: - -- DEPRECATED: gpiochip_irqchip_add(): adds a chained cascaded irqchip to a - gpiochip. It will pass the struct gpio_chip* for the chip to all IRQ - callbacks, so the callbacks need to embed the gpio_chip in its state - container and obtain a pointer to the container using container_of(). - (See Documentation/driver-api/driver-model/design-patterns.rst) - -- gpiochip_irqchip_add_nested(): adds a nested cascaded irqchip to a gpiochip, - as discussed above regarding different types of cascaded irqchips. The - cascaded irq has to be handled by a threaded interrupt handler. - Apart from that it works exactly like the chained irqchip. - -- gpiochip_set_nested_irqchip(): sets up a nested cascaded irq handler for a - gpio_chip from a parent IRQ. As the parent IRQ has usually been - explicitly requested by the driver, this does very little more than - mark all the child IRQs as having the other IRQ as parent. - If there is a need to exclude certain GPIO lines from the IRQ domain handled by these helpers, we can set .irq.need_valid_mask of the gpiochip before devm_gpiochip_add_data() or gpiochip_add_data() is called. This allocates an -- cgit v1.2.3 From 8aa16335050663357281fb1f1b0483ab91b4d8de Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Mon, 19 Oct 2020 15:44:29 +0200 Subject: gpio: stmpe: Fix forgotten refactoring We actually handle the gpio_irq_chip set-up properly now despite what the comment says. Also assign this pointer along with the rest of the gpio_irq_chip setup code. Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20201019134429.65563-1-linus.walleij@linaro.org --- Documentation/driver-api/gpio/driver.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/gpio/driver.rst b/Documentation/driver-api/gpio/driver.rst index 65d708093b71..0fb57e298b41 100644 --- a/Documentation/driver-api/gpio/driver.rst +++ b/Documentation/driver-api/gpio/driver.rst @@ -538,8 +538,8 @@ these helpers, we can set .irq.need_valid_mask of the gpiochip before devm_gpiochip_add_data() or gpiochip_add_data() is called. This allocates an .irq.valid_mask with as many bits set as there are GPIO lines in the chip, each bit representing line 0..n-1. Drivers can exclude GPIO lines by clearing bits -from this mask. The mask must be filled in before gpiochip_irqchip_add() or -gpiochip_irqchip_add_nested() is called. +from this mask. The mask can be filled in the init_valid_mask() callback +that is part of the struct gpio_irq_chip. To use the helpers please keep the following in mind: -- cgit v1.2.3 From d94df02c476cbc207651d19cfd104690b079bdb4 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 27 Oct 2020 11:56:15 +0100 Subject: docs: Makefile: honor V=0 for docs building Reduce the number of displayed mesages when building the docs with V=0. Suggested-by: Stephen Rothwell Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/478c114a2399b68a18de94ee5f98649304f3903b.1603796153.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/Makefile | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/Makefile b/Documentation/Makefile index 6b12dd82f712..4e47dff8b315 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -21,6 +21,10 @@ BUILDDIR = $(obj)/output PDFLATEX = xelatex LATEXOPTS = -interaction=batchmode +ifeq ($(KBUILD_VERBOSE),0) +SPHINXOPTS += "-q" +endif + # User-friendly check for sphinx-build HAVE_SPHINX := $(shell if which $(SPHINXBUILD) >/dev/null 2>&1; then echo 1; else echo 0; fi) -- cgit v1.2.3 From e051955977b7e26124aa8c8398278145f85f94e8 Mon Sep 17 00:00:00 2001 From: Wilken Gottwalt Date: Tue, 27 Oct 2020 07:24:08 +0100 Subject: documentation: arm: sunxi: add Allwinner H6 documents Add the current Allwinner H6 datasheet and user manual. Signed-off-by: Wilken Gottwalt Link: https://lore.kernel.org/r/20201027062408.GA6761@monster.powergraphx.local Signed-off-by: Jonathan Corbet --- Documentation/arm/sunxi.rst | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/arm/sunxi.rst b/Documentation/arm/sunxi.rst index 62b533d0ba94..0c536ae1d7c2 100644 --- a/Documentation/arm/sunxi.rst +++ b/Documentation/arm/sunxi.rst @@ -148,3 +148,13 @@ SunXi family * User Manual http://dl.linux-sunxi.org/A64/Allwinner%20A64%20User%20Manual%20v1.0.pdf + + - Allwinner H6 + + * Datasheet + + https://linux-sunxi.org/images/5/5c/Allwinner_H6_V200_Datasheet_V1.1.pdf + + * User Manual + + https://linux-sunxi.org/images/4/46/Allwinner_H6_V200_User_Manual_V1.1.pdf -- cgit v1.2.3 From d29f34c098aa1b7e237ce9979eeb5cef9e5f162f Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 27 Oct 2020 10:51:06 +0100 Subject: sphinx: conf.py: properly handle Sphinx 4.0 One of the checks for Sphinx 3+ is broken, causing some C warnings to return back with Sphinx 4.0.x. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/d5abc30056dafeec0778a46263a45401bdc7f11e.1603791716.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/conf.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/conf.py b/Documentation/conf.py index 376dd0ddf39c..7ee05fd4cb17 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py @@ -50,7 +50,7 @@ if major >= 3: support for Sphinx v3.0 and above is brand new. Be prepared for possible issues in the generated output. ''') - if minor > 0 or patch >= 2: + if (major > 3) or (minor > 0 or patch >= 2): # Sphinx c function parser is more pedantic with regards to type # checking. Due to that, having macros at c:function cause problems. # Those needed to be scaped by using c_id_attributes[] array -- cgit v1.2.3 From 6cc6f5ad9bfb430289a356a95fc5c74fe412d5cd Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 27 Oct 2020 10:51:07 +0100 Subject: docs: hwmon: adm1266.rst: fix a broken reference The reference was missing the extension, causing the check script to complain. Signed-off-by: Mauro Carvalho Chehab Acked-by: Guenter Roeck Link: https://lore.kernel.org/r/3d64372dabcdcea144cdc9972c245812ea2a84cb.1603791716.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/hwmon/adm1266.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/adm1266.rst b/Documentation/hwmon/adm1266.rst index 9257f8a48650..2b877011cfdf 100644 --- a/Documentation/hwmon/adm1266.rst +++ b/Documentation/hwmon/adm1266.rst @@ -20,7 +20,7 @@ ADM1266 is a sequencer that features voltage readback from 17 channels via an integrated 12 bit SAR ADC, accessed using a PMBus interface. The driver is a client driver to the core PMBus driver. Please see -Documentation/hwmon/pmbus for details on PMBus client drivers. +Documentation/hwmon/pmbus.rst for details on PMBus client drivers. Sysfs entries -- cgit v1.2.3 From 2644ccef6f289c0bd545f5b79a4bfc6eb67318fe Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 27 Oct 2020 10:51:08 +0100 Subject: docs: admin-guide: net.rst: add a missing blank line There's a missing blank line after a literal block, which causes this warning: Documentation/admin-guide/sysctl/net.rst:303: WARNING: Literal block ends without a blank line; unexpected unindent. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/b2545be4a4c71269d10278b5990c3e06c4b65f84.1603791716.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/sysctl/net.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/sysctl/net.rst b/Documentation/admin-guide/sysctl/net.rst index 57fd6ce68fe0..f2ab8a5b6a4b 100644 --- a/Documentation/admin-guide/sysctl/net.rst +++ b/Documentation/admin-guide/sysctl/net.rst @@ -300,6 +300,7 @@ Note: 0: 0 1 2 3 4 5 6 7 RSS hash key: 84:50:f4:00:a8:15:d1:a7:e9:7f:1d:60:35:c7:47:25:42:97:74:ca:56:bb:b6:a1:d8:43:e3:c9:0c:fd:17:55:c2:3a:4d:69:ed:f1:42:89 + netdev_tstamp_prequeue ---------------------- -- cgit v1.2.3 From 32519c0326862d95186d018876a07980acf11089 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 27 Oct 2020 10:51:09 +0100 Subject: docs: kasan.rst: add two missing blank lines literal blocks should start and end with a blank line, as otherwise the parser complains and may do the wrong thing, as warned by Sphinx: Documentation/dev-tools/kasan.rst:298: WARNING: Literal block ends without a blank line; unexpected unindent. Documentation/dev-tools/kasan.rst:303: WARNING: Literal block ends without a blank line; unexpected unindent. Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Andrey Konovalov Link: https://lore.kernel.org/r/cd6c4280fe26b07f2c5e5ed2918e17e88bb03419.1603791716.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/dev-tools/kasan.rst | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst index c09c9ca2ff1c..2b68addaadcd 100644 --- a/Documentation/dev-tools/kasan.rst +++ b/Documentation/dev-tools/kasan.rst @@ -295,11 +295,13 @@ print the number of the test and the status of the test: pass:: ok 28 - kmalloc_double_kzfree + or, if kmalloc failed:: # kmalloc_large_oob_right: ASSERTION FAILED at lib/test_kasan.c:163 Expected ptr is not null, but is not ok 4 - kmalloc_large_oob_right + or, if a KASAN report was expected, but not found:: # kmalloc_double_kzfree: EXPECTATION FAILED at lib/test_kasan.c:629 -- cgit v1.2.3 From 97e44c4f0cb69ec4f896451454e7b54b3fe06345 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 27 Oct 2020 10:51:10 +0100 Subject: docs: net: statistics.rst: remove a duplicated kernel-doc include/linux/ethtool.h is included twice with kernel-doc, both to document ethtool_pause_stats(). The first one is at statistics.rst, and the second one at ethtool-netlink.rst. Replace one of the references to use the name of the function. The automarkup.py extension should create the cross-references. Solves this warning: ../Documentation/networking/ethtool-netlink.rst: WARNING: Duplicate C declaration, also defined in 'networking/statistics'. Declaration is 'ethtool_pause_stats'. Signed-off-by: Mauro Carvalho Chehab Acked-by: David S. Miller Link: https://lore.kernel.org/r/fdbf853bbdaf3bc1d38f32744b739d175c5c31f5.1603791716.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/networking/statistics.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/statistics.rst b/Documentation/networking/statistics.rst index 8e15bc98830b..234abedc29b2 100644 --- a/Documentation/networking/statistics.rst +++ b/Documentation/networking/statistics.rst @@ -175,5 +175,4 @@ The following structures are internal to the kernel, their members are translated to netlink attributes when dumped. Drivers must not overwrite the statistics they don't report with 0. -.. kernel-doc:: include/linux/ethtool.h - :identifiers: ethtool_pause_stats +- ethtool_pause_stats() -- cgit v1.2.3 From 9d8c4f0c0170a8e63256ba257b57975f04b813ab Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 27 Oct 2020 10:51:11 +0100 Subject: docs: hwmon: mp2975.rst: address some html build warnings .../Documentation/hwmon/mp2975.rst:25: WARNING: Unexpected indentation. .../Documentation/hwmon/mp2975.rst:27: WARNING: Block quote ends without a blank line; unexpected unindent. .../Documentation/hwmon/mp2975.rst:69: WARNING: Unexpected indentation. .../Documentation/hwmon/mp2975.rst:70: WARNING: Block quote ends without a blank line; unexpected unindent. .../Documentation/hwmon/mp2975.rst:72: WARNING: Bullet list ends without a blank line; unexpected unindent. .../Documentation/hwmon/mp2975.rst: WARNING: document isn't included in any toctree List blocks should have blank lines before and after them, in order to be properly parsed. Fixes: 4beb7a028e9f ("hwmon: (pmbus) Add support for MPS Multi-phase mp2975 controller") Signed-off-by: Mauro Carvalho Chehab Acked-by: Guenter Roeck Link: https://lore.kernel.org/r/b02f98d886ab1f5af233f8999c7a15529fc52cdc.1603791716.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/hwmon/index.rst | 1 + Documentation/hwmon/mp2975.rst | 14 +++++++++++++- 2 files changed, 14 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst index e6b91ab12978..b797db738225 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -132,6 +132,7 @@ Hardware Monitoring Kernel Drivers mcp3021 menf21bmc mlxreg-fan + mp2975 nct6683 nct6775 nct7802 diff --git a/Documentation/hwmon/mp2975.rst b/Documentation/hwmon/mp2975.rst index 5b0609c62f48..81d816b71490 100644 --- a/Documentation/hwmon/mp2975.rst +++ b/Documentation/hwmon/mp2975.rst @@ -20,6 +20,7 @@ This driver implements support for Monolithic Power Systems, Inc. (MPS) vendor dual-loop, digital, multi-phase controller MP2975. This device: + - Supports up to two power rail. - Provides 8 pulse-width modulations (PWMs), and can be configured up to 8-phase operation for rail 1 and up to 4-phase operation for rail @@ -32,10 +33,12 @@ This device: 10-mV DAC, IMVP9 mode with 5-mV DAC. Device supports: + - SVID interface. - AVSBus interface. Device complaint with: + - PMBus rev 1.3 interface. Device supports direct format for reading output current, output voltage, @@ -45,11 +48,14 @@ Device supports VID and direct formats for reading output voltage. The below VID modes are supported: VR12, VR13, IMVP9. The driver provides the next attributes for the current: + - for current in: input, maximum alarm; - for current out input, maximum alarm and highest values; - for phase current: input and label. -attributes. + attributes. + The driver exports the following attributes via the 'sysfs' files, where + - 'n' is number of telemetry pages (from 1 to 2); - 'k' is number of configured phases (from 1 to 8); - indexes 1, 1*n for "iin"; @@ -65,11 +71,14 @@ The driver exports the following attributes via the 'sysfs' files, where **curr[1-{2n+k}]_label** The driver provides the next attributes for the voltage: + - for voltage in: input, high critical threshold, high critical alarm, all only from page 0; - for voltage out: input, low and high critical thresholds, low and high critical alarms, from pages 0 and 1; + The driver exports the following attributes via the 'sysfs' files, where + - 'n' is number of telemetry pages (from 1 to 2); - indexes 1 for "iin"; - indexes n+1, n+2 for "vout"; @@ -87,9 +96,12 @@ The driver exports the following attributes via the 'sysfs' files, where **in[2-{n+1}1_lcrit_alarm** The driver provides the next attributes for the power: + - for power in alarm and input. - for power out: highest and input. + The driver exports the following attributes via the 'sysfs' files, where + - 'n' is number of telemetry pages (from 1 to 2); - indexes 1 for "pin"; - indexes n+1, n+2 for "pout"; -- cgit v1.2.3 From de39012afa7fd119fd6387c11a6ce33590717866 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 27 Oct 2020 10:51:12 +0100 Subject: docs: userspace-api: add iommu.rst to the index file There's a new uAPI doc for IOMMU. Add it to the index file. Should address this warning: .../Documentation/userspace-api/iommu.rst: WARNING: document isn't included in any toctree Fixes: d0023e3ee28d ("docs: IOMMU user API") Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/cc55219a551e29848e2282cd8939a4115067234c.1603791716.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/userspace-api/index.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/userspace-api/index.rst b/Documentation/userspace-api/index.rst index 69fc5167e648..acd2cc2a538d 100644 --- a/Documentation/userspace-api/index.rst +++ b/Documentation/userspace-api/index.rst @@ -22,6 +22,7 @@ place where this information is gathered. spec_ctrl accelerators/ocxl ioctl/index + iommu media/index .. only:: subproject and html -- cgit v1.2.3 From 4b7560c5e4bda24fcbd54337c87056833819c73b Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 27 Oct 2020 10:51:20 +0100 Subject: ice: docs fix a devlink info that broke a table Changeset 410d06879c01 ("ice: add the DDP Track ID to devlink info") added description for a new devlink field, but forgot to add one of its columns, causing it to break: .../Documentation/networking/devlink/ice.rst:15: WARNING: Error parsing content block for the "list-table" directive: uniform two-level bullet list expected, but row 11 does not contain the same number of items as row 1 (3 vs 4). .. list-table:: devlink info versions implemented :widths: 5 5 5 90 ... * - ``fw.app.bundle_id`` - 0xc0000001 - Unique identifier for the DDP package loaded in the device. Also referred to as the DDP Track ID. Can be used to uniquely identify the specific DDP package. Add the type field to the ``fw.app.bundle_id`` row. Fixes: 410d06879c01 ("ice: add the DDP Track ID to devlink info") Signed-off-by: Mauro Carvalho Chehab Reviewed-by: Jacob Keller Link: https://lore.kernel.org/r/84ae28bda1987284033966b7b56a4b27ae40713b.1603791716.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/networking/devlink/ice.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/networking/devlink/ice.rst b/Documentation/networking/devlink/ice.rst index b165181d5d4d..a432dc419fa4 100644 --- a/Documentation/networking/devlink/ice.rst +++ b/Documentation/networking/devlink/ice.rst @@ -70,6 +70,7 @@ The ``ice`` driver reports the following versions that both the name (as reported by ``fw.app.name``) and version are required to uniquely identify the package. * - ``fw.app.bundle_id`` + - running - 0xc0000001 - Unique identifier for the DDP package loaded in the device. Also referred to as the DDP Track ID. Can be used to uniquely identify -- cgit v1.2.3 From ef900cccb864d72292b6f5564850d157036905ea Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 27 Oct 2020 10:51:21 +0100 Subject: MAINTAINERS: fix broken doc refs due to yaml conversion Several *.txt files got converted to yaml. Update their references at MAINTAINERS file accordingly. Signed-off-by: Mauro Carvalho Chehab Acked-by: Stephen Boyd Link: https://lore.kernel.org/r/3b58afec5195d4ea505ea9b3f74d53f7abed4e6f.1603791716.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/devicetree/bindings/clock/hi6220-clock.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/hi6220-clock.txt b/Documentation/devicetree/bindings/clock/hi6220-clock.txt index ef3deb7b86ea..17ac4a3dd26a 100644 --- a/Documentation/devicetree/bindings/clock/hi6220-clock.txt +++ b/Documentation/devicetree/bindings/clock/hi6220-clock.txt @@ -4,7 +4,7 @@ Clock control registers reside in different Hi6220 system controllers, please refer the following document to know more about the binding rules for these system controllers: -Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt +Documentation/devicetree/bindings/arm/hisilicon/hisilicon.yaml Required Properties: -- cgit v1.2.3 From e3e7439dbc27d99cee40674f243ec616458ddce2 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 27 Oct 2020 10:51:22 +0100 Subject: docs: lockdep-design: fix some warning issues There are several warnings caused by a recent change 224ec489d3cd ("lockdep/Documention: Recursive read lock detection reasoning") Those are reported by htmldocs build: Documentation/locking/lockdep-design.rst:429: WARNING: Definition list ends without a blank line; unexpected unindent. Documentation/locking/lockdep-design.rst:452: WARNING: Block quote ends without a blank line; unexpected unindent. Documentation/locking/lockdep-design.rst:453: WARNING: Unexpected indentation. Documentation/locking/lockdep-design.rst:453: WARNING: Blank line required after table. Documentation/locking/lockdep-design.rst:454: WARNING: Block quote ends without a blank line; unexpected unindent. Documentation/locking/lockdep-design.rst:455: WARNING: Unexpected indentation. Documentation/locking/lockdep-design.rst:455: WARNING: Blank line required after table. Documentation/locking/lockdep-design.rst:456: WARNING: Block quote ends without a blank line; unexpected unindent. Documentation/locking/lockdep-design.rst:457: WARNING: Unexpected indentation. Documentation/locking/lockdep-design.rst:457: WARNING: Blank line required after table. Besides the reported issues, there are some missing blank lines that ended producing wrong html output, and some literals are not properly identified. Also, the symbols used at the irq enabled/disable table are not displayed as expected, as they're not literals. Also, on another table they're using a different notation. Fixes: 224ec489d3cd ("lockdep/Documention: Recursive read lock detection reasoning") Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/3b9431ac5c01e38111cd59928a93e7259ab7db0f.1603791716.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/locking/lockdep-design.rst | 51 +++++++++++++++++++------------- 1 file changed, 31 insertions(+), 20 deletions(-) (limited to 'Documentation') diff --git a/Documentation/locking/lockdep-design.rst b/Documentation/locking/lockdep-design.rst index cec03bd1294a..9f3cfca9f8a4 100644 --- a/Documentation/locking/lockdep-design.rst +++ b/Documentation/locking/lockdep-design.rst @@ -42,6 +42,7 @@ The validator tracks lock-class usage history and divides the usage into (4 usages * n STATEs + 1) categories: where the 4 usages can be: + - 'ever held in STATE context' - 'ever held as readlock in STATE context' - 'ever held with STATE enabled' @@ -49,10 +50,12 @@ where the 4 usages can be: where the n STATEs are coded in kernel/locking/lockdep_states.h and as of now they include: + - hardirq - softirq where the last 1 category is: + - 'ever used' [ == !unused ] When locking rules are violated, these usage bits are presented in the @@ -96,9 +99,9 @@ exact case is for the lock as of the reporting time. +--------------+-------------+--------------+ | | irq enabled | irq disabled | +--------------+-------------+--------------+ - | ever in irq | ? | - | + | ever in irq | '?' | '-' | +--------------+-------------+--------------+ - | never in irq | + | . | + | never in irq | '+' | '.' | +--------------+-------------+--------------+ The character '-' suggests irq is disabled because if otherwise the @@ -216,7 +219,7 @@ looks like this:: BD_MUTEX_PARTITION }; -mutex_lock_nested(&bdev->bd_contains->bd_mutex, BD_MUTEX_PARTITION); + mutex_lock_nested(&bdev->bd_contains->bd_mutex, BD_MUTEX_PARTITION); In this case the locking is done on a bdev object that is known to be a partition. @@ -334,7 +337,7 @@ Troubleshooting: ---------------- The validator tracks a maximum of MAX_LOCKDEP_KEYS number of lock classes. -Exceeding this number will trigger the following lockdep warning: +Exceeding this number will trigger the following lockdep warning:: (DEBUG_LOCKS_WARN_ON(id >= MAX_LOCKDEP_KEYS)) @@ -420,7 +423,8 @@ the critical section of another reader of the same lock instance. The difference between recursive readers and non-recursive readers is because: recursive readers get blocked only by a write lock *holder*, while non-recursive -readers could get blocked by a write lock *waiter*. Considering the follow example: +readers could get blocked by a write lock *waiter*. Considering the follow +example:: TASK A: TASK B: @@ -448,20 +452,22 @@ There are simply four block conditions: Block condition matrix, Y means the row blocks the column, and N means otherwise. - | E | r | R | +---+---+---+---+ - E | Y | Y | Y | + | | E | r | R | + +---+---+---+---+ + | E | Y | Y | Y | + +---+---+---+---+ + | r | Y | Y | N | +---+---+---+---+ - r | Y | Y | N | + | R | Y | Y | N | +---+---+---+---+ - R | Y | Y | N | (W: writers, r: non-recursive readers, R: recursive readers) acquired recursively. Unlike non-recursive read locks, recursive read locks only get blocked by current write lock *holders* other than write lock -*waiters*, for example: +*waiters*, for example:: TASK A: TASK B: @@ -491,7 +497,7 @@ Recursive locks don't block each other, while non-recursive locks do (this is even true for two non-recursive read locks). A non-recursive lock can block the corresponding recursive lock, and vice versa. -A deadlock case with recursive locks involved is as follow: +A deadlock case with recursive locks involved is as follow:: TASK A: TASK B: @@ -510,7 +516,7 @@ because there are 3 types for lockers, there are, in theory, 9 types of lock dependencies, but we can show that 4 types of lock dependencies are enough for deadlock detection. -For each lock dependency: +For each lock dependency:: L1 -> L2 @@ -525,20 +531,25 @@ same types). With the above combination for simplification, there are 4 types of dependency edges in the lockdep graph: -1) -(ER)->: exclusive writer to recursive reader dependency, "X -(ER)-> Y" means +1) -(ER)->: + exclusive writer to recursive reader dependency, "X -(ER)-> Y" means X -> Y and X is a writer and Y is a recursive reader. -2) -(EN)->: exclusive writer to non-recursive locker dependency, "X -(EN)-> Y" means +2) -(EN)->: + exclusive writer to non-recursive locker dependency, "X -(EN)-> Y" means X -> Y and X is a writer and Y is either a writer or non-recursive reader. -3) -(SR)->: shared reader to recursive reader dependency, "X -(SR)-> Y" means +3) -(SR)->: + shared reader to recursive reader dependency, "X -(SR)-> Y" means X -> Y and X is a reader (recursive or not) and Y is a recursive reader. -4) -(SN)->: shared reader to non-recursive locker dependency, "X -(SN)-> Y" means +4) -(SN)->: + shared reader to non-recursive locker dependency, "X -(SN)-> Y" means X -> Y and X is a reader (recursive or not) and Y is either a writer or non-recursive reader. -Note that given two locks, they may have multiple dependencies between them, for example: +Note that given two locks, they may have multiple dependencies between them, +for example:: TASK A: @@ -592,11 +603,11 @@ circles that won't cause deadlocks. Proof for sufficiency (Lemma 1): -Let's say we have a strong circle: +Let's say we have a strong circle:: L1 -> L2 ... -> Ln -> L1 -, which means we have dependencies: +, which means we have dependencies:: L1 -> L2 L2 -> L3 @@ -633,7 +644,7 @@ a lock held by P2, and P2 is waiting for a lock held by P3, ... and Pn is waitin for a lock held by P1. Let's name the lock Px is waiting as Lx, so since P1 is waiting for L1 and holding Ln, so we will have Ln -> L1 in the dependency graph. Similarly, we have L1 -> L2, L2 -> L3, ..., Ln-1 -> Ln in the dependency graph, which means we -have a circle: +have a circle:: Ln -> L1 -> L2 -> ... -> Ln -- cgit v1.2.3 From 7c128a249c7e7697b5bd4b0ca27c1f4fe5c64f6a Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 27 Oct 2020 10:51:25 +0100 Subject: docs: fs: api-summary.rst: get rid of kernel-doc include The direct-io.c file used to have just two exported symbols: - dio_end_io() - __blockdev_direct_IO() The first one was removed by changeset c33fe275b530 ("fs: remove no longer used dio_end_io()") And the last one is used on most places indirectly, via the inline macro blockdev_direct_IO() provided by fs.h. Yet, neither the macro or the function have kernel-doc markups. So, drop the inclusion of fs/direct-io.c at the docs. Fixes: c33fe275b530 ("fs: remove no longer used dio_end_io()") Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/d0a9fffedca102633c168adaf157f34288a4ea67.1603791716.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/filesystems/api-summary.rst | 3 --- 1 file changed, 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/api-summary.rst b/Documentation/filesystems/api-summary.rst index bbb0c1c0e5cf..a94f17d9b836 100644 --- a/Documentation/filesystems/api-summary.rst +++ b/Documentation/filesystems/api-summary.rst @@ -86,9 +86,6 @@ Other Functions .. kernel-doc:: fs/dax.c :export: -.. kernel-doc:: fs/direct-io.c - :export: - .. kernel-doc:: fs/libfs.c :export: -- cgit v1.2.3 From cc507c435b05b23f62ae32c092de2da972a98d8e Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 27 Oct 2020 10:51:30 +0100 Subject: gpu: docs: amdgpu.rst: get rid of wrong kernel-doc markups As reported by kernel-doc: ./drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c:1: warning: no structured comments found ./drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c:1: warning: no structured comments found Those files only contain /** * DOC: */ markups, but they're included twice there: one to parse such markup, and another one to parse internal functions. In the case of amdgpu_xgmi.c, as it has just one such markup, we can simply include the file once, and let it parse the entire file without passing arguments to kernel-doc. This should place everything altogether. For amdgpu_ras.c, however, we need to remove the kernel-doc with just internal. This should be re-introduced if this file ever gets new non-DOC markups. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/bd070923591ae54f9587e7407b6291ac116952b2.1603791716.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/gpu/amdgpu.rst | 7 ------- 1 file changed, 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/amdgpu.rst b/Documentation/gpu/amdgpu.rst index 1f9ea8221f80..2062a6023678 100644 --- a/Documentation/gpu/amdgpu.rst +++ b/Documentation/gpu/amdgpu.rst @@ -83,10 +83,6 @@ AMDGPU XGMI Support =================== .. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c - :doc: AMDGPU XGMI Support - -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c - :internal: AMDGPU RAS Support ================== @@ -124,9 +120,6 @@ RAS VRAM Bad Pages sysfs Interface .. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c :doc: AMDGPU RAS sysfs gpu_vram_bad_pages Interface -.. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_ras.c - :internal: - Sample Code ----------- Sample code for testing error injection can be found here: -- cgit v1.2.3 From afc74ce7b484da5c5698d8eb2472a58c547cbc2b Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 27 Oct 2020 10:51:36 +0100 Subject: docs: SafeSetID: fix a warning As reported by Sphinx 2.4.4: docs/Documentation/admin-guide/LSM/SafeSetID.rst:110: WARNING: Title underline too short. Note on GID policies and setgroups() ================== Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/4afa281c170daabd1ce522653d5d5d5078ebd92c.1603791716.git.mchehab+huawei@kernel.org Signed-off-by: Jonathan Corbet --- Documentation/admin-guide/LSM/SafeSetID.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/LSM/SafeSetID.rst b/Documentation/admin-guide/LSM/SafeSetID.rst index 17996c9070e2..0ec34863c674 100644 --- a/Documentation/admin-guide/LSM/SafeSetID.rst +++ b/Documentation/admin-guide/LSM/SafeSetID.rst @@ -107,7 +107,7 @@ for a UID/GID will prevent that UID/GID from obtaining auxiliary setid privileges, such as allowing a user to set up user namespace UID/GID mappings. Note on GID policies and setgroups() -================== +==================================== In v5.9 we are adding support for limiting CAP_SETGID privileges as was done previously for CAP_SETUID. However, for compatibility with common sandboxing related code conventions in userspace, we currently allow arbitrary -- cgit v1.2.3 From 1a002325d1642f6d206563870434dc027546e06e Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sat, 26 Sep 2020 18:28:03 +0200 Subject: dt-bindings: arm: fsl: document i.MX25 and i.MX27 boards Document and adjust the compatibles for i.MX25 and i.MX27 based boards to fix dtbs_check warnings like: arch/arm/boot/dts/imx27-apf27dev.dt.yaml: /: compatible: ['armadeus,imx27-apf27dev', 'armadeus,imx27-apf27', 'fsl,imx27'] is not valid under any of the given schemas Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 45 ++++++++++++++++++++++++-- 1 file changed, 43 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index b0db3c90914b..76e1628dbdbb 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -33,16 +33,57 @@ properties: items: - enum: - fsl,imx25-pdk + - karo,imx25-tx25 - const: fsl,imx25 - - description: i.MX27 Product Development Kit + - description: i.MX25 Eukrea CPUIMX25 Boards + items: + - enum: + - eukrea,mbimxsd25-baseboard # Eukrea MBIMXSD25 + - const: eukrea,cpuimx25 + - const: fsl,imx25 + + - description: i.MX25 Eukrea MBIMXSD25 Boards + items: + - enum: + - eukrea,mbimxsd25-baseboard-cmo-qvga + - eukrea,mbimxsd25-baseboard-dvi-svga + - eukrea,mbimxsd25-baseboard-dvi-vga + - const: eukrea,mbimxsd25-baseboard + - const: eukrea,cpuimx25 + - const: fsl,imx25 + + - description: i.MX27 based Boards items: - enum: - armadeus,imx27-apf27 # APF27 SoM - - armadeus,imx27-apf27dev # APF27 SoM on APF27Dev board - fsl,imx27-pdk - const: fsl,imx27 + - description: i.MX27 APF27 SoM Board + items: + - const: armadeus,imx27-apf27dev + - const: armadeus,imx27-apf27 + - const: fsl,imx27 + + - description: i.MX27 Eukrea CPUIMX27 SoM Board + items: + - const: eukrea,mbimxsd27-baseboard + - const: eukrea,cpuimx27 + - const: fsl,imx27 + + - description: i.MX27 Phytec pca100 Board + items: + - const: phytec,imx27-pca100-rdk + - const: phytec,imx27-pca100 + - const: fsl,imx27 + + - description: i.MX27 Phytec pcm970 Board + items: + - const: phytec,imx27-pcm970 + - const: phytec,imx27-pcm038 + - const: fsl,imx27 + - description: i.MX28 based Boards items: - enum: -- cgit v1.2.3 From a889583a19206636082c44625141b26392e46a62 Mon Sep 17 00:00:00 2001 From: Srinivas Kandagatla Date: Thu, 29 Oct 2020 10:15:49 +0000 Subject: ASoC: qcom: dt-bindings: sm8250: update compatibles Update compatible string as board compatible and device compatible should not be same!. New compatible is now suffixed with -sndcard to be inline with other Qualcomm Sound cards. This also fixes the warnings/error reported by dt_binding_check. Fixes: 765c37598494 ("ASoC: qcom: dt-bindings: Add SM8250 sound card bindings") Reported-by: Rob Herring Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20201029101550.31695-1-srinivas.kandagatla@linaro.org Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/qcom,sm8250.yaml | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml index b8f97fe6e92c..72ad9ab91832 100644 --- a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml @@ -16,10 +16,8 @@ description: properties: compatible: oneOf: - - const: qcom,qrb5165-rb5 - - items: - - const: qcom,sm8250 - - const: qcom,qrb5165-rb5 + - const: qcom,sm8250-sndcard + - const: qcom,qrb5165-rb5-sndcard audio-routing: $ref: /schemas/types.yaml#/definitions/non-unique-string-array @@ -83,7 +81,7 @@ examples: #include #include sound { - compatible = "qcom,qrb5165-rb5"; + compatible = "qcom,qrb5165-rb5-sndcard"; model = "Qualcomm-qrb5165-RB5-WSA8815-Speakers-DMIC0"; audio-routing = "SpkrLeft IN", "WSA_SPK1 OUT", "SpkrRight IN", "WSA_SPK2 OUT", -- cgit v1.2.3 From f54ec58fee837ec847cb8b50593e81bfaa46107f Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Tue, 27 Oct 2020 21:12:12 +0100 Subject: wimax: move out to staging There are no known users of this driver as of October 2020, and it will be removed unless someone turns out to still need it in future releases. According to https://en.wikipedia.org/wiki/List_of_WiMAX_networks, there have been many public wimax networks, but it appears that many of these have migrated to LTE or discontinued their service altogether. As most PCs and phones lack WiMAX hardware support, the remaining networks tend to use standalone routers. These almost certainly run Linux, but not a modern kernel or the mainline wimax driver stack. NetworkManager appears to have dropped userspace support in 2015 https://bugzilla.gnome.org/show_bug.cgi?id=747846, the www.linuxwimax.org site had already shut down earlier. WiMax is apparently still being deployed on airport campus networks ("AeroMACS"), but in a frequency band that was not supported by the old Intel 2400m (used in Sandy Bridge laptops and earlier), which is the only driver using the kernel's wimax stack. Move all files into drivers/staging/wimax, including the uapi header files and documentation, to make it easier to remove it when it gets to that. Only minimal changes are made to the source files, in order to make it possible to port patches across the move. Also remove the MAINTAINERS entry that refers to a broken mailing list and website. Acked-by: Jakub Kicinski Acked-by: Greg Kroah-Hartman Acked-By: Inaky Perez-Gonzalez Acked-by: Johannes Berg Suggested-by: Inaky Perez-Gonzalez Signed-off-by: Arnd Bergmann --- Documentation/admin-guide/index.rst | 1 - Documentation/admin-guide/wimax/i2400m.rst | 283 --------------------- Documentation/admin-guide/wimax/index.rst | 19 -- Documentation/admin-guide/wimax/wimax.rst | 89 ------- Documentation/networking/kapi.rst | 21 -- .../translations/zh_CN/admin-guide/index.rst | 1 - 6 files changed, 414 deletions(-) delete mode 100644 Documentation/admin-guide/wimax/i2400m.rst delete mode 100644 Documentation/admin-guide/wimax/index.rst delete mode 100644 Documentation/admin-guide/wimax/wimax.rst (limited to 'Documentation') diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst index ed1cf94ea50c..d53986a424c4 100644 --- a/Documentation/admin-guide/index.rst +++ b/Documentation/admin-guide/index.rst @@ -115,7 +115,6 @@ configure specific aspects of kernel behavior to your liking. unicode vga-softcursor video-output - wimax/index xfs .. only:: subproject and html diff --git a/Documentation/admin-guide/wimax/i2400m.rst b/Documentation/admin-guide/wimax/i2400m.rst deleted file mode 100644 index 194388c0c351..000000000000 --- a/Documentation/admin-guide/wimax/i2400m.rst +++ /dev/null @@ -1,283 +0,0 @@ -.. include:: - -==================================================== -Driver for the Intel Wireless Wimax Connection 2400m -==================================================== - -:Copyright: |copy| 2008 Intel Corporation < linux-wimax@intel.com > - - This provides a driver for the Intel Wireless WiMAX Connection 2400m - and a basic Linux kernel WiMAX stack. - -1. Requirements -=============== - - * Linux installation with Linux kernel 2.6.22 or newer (if building - from a separate tree) - * Intel i2400m Echo Peak or Baxter Peak; this includes the Intel - Wireless WiMAX/WiFi Link 5x50 series. - * build tools: - - + Linux kernel development package for the target kernel; to - build against your currently running kernel, you need to have - the kernel development package corresponding to the running - image installed (usually if your kernel is named - linux-VERSION, the development package is called - linux-dev-VERSION or linux-headers-VERSION). - + GNU C Compiler, make - -2. Compilation and installation -=============================== - -2.1. Compilation of the drivers included in the kernel ------------------------------------------------------- - - Configure the kernel; to enable the WiMAX drivers select Drivers > - Networking Drivers > WiMAX device support. Enable all of them as - modules (easier). - - If USB or SDIO are not enabled in the kernel configuration, the options - to build the i2400m USB or SDIO drivers will not show. Enable said - subsystems and go back to the WiMAX menu to enable the drivers. - - Compile and install your kernel as usual. - -2.2. Compilation of the drivers distributed as an standalone module -------------------------------------------------------------------- - - To compile:: - - $ cd source/directory - $ make - - Once built you can load and unload using the provided load.sh script; - load.sh will load the modules, load.sh u will unload them. - - To install in the default kernel directories (and enable auto loading - when the device is plugged):: - - $ make install - $ depmod -a - - If your kernel development files are located in a non standard - directory or if you want to build for a kernel that is not the - currently running one, set KDIR to the right location:: - - $ make KDIR=/path/to/kernel/dev/tree - - For more information, please contact linux-wimax@intel.com. - -3. Installing the firmware --------------------------- - - The firmware can be obtained from http://linuxwimax.org or might have - been supplied with your hardware. - - It has to be installed in the target system:: - - $ cp FIRMWAREFILE.sbcf /lib/firmware/i2400m-fw-BUSTYPE-1.3.sbcf - - * NOTE: if your firmware came in an .rpm or .deb file, just install - it as normal, with the rpm (rpm -i FIRMWARE.rpm) or dpkg - (dpkg -i FIRMWARE.deb) commands. No further action is needed. - * BUSTYPE will be usb or sdio, depending on the hardware you have. - Each hardware type comes with its own firmware and will not work - with other types. - -4. Design -========= - - This package contains two major parts: a WiMAX kernel stack and a - driver for the Intel i2400m. - - The WiMAX stack is designed to provide for common WiMAX control - services to current and future WiMAX devices from any vendor; please - see README.wimax for details. - - The i2400m kernel driver is broken up in two main parts: the bus - generic driver and the bus-specific drivers. The bus generic driver - forms the drivercore and contain no knowledge of the actual method we - use to connect to the device. The bus specific drivers are just the - glue to connect the bus-generic driver and the device. Currently only - USB and SDIO are supported. See drivers/net/wimax/i2400m/i2400m.h for - more information. - - The bus generic driver is logically broken up in two parts: OS-glue and - hardware-glue. The OS-glue interfaces with Linux. The hardware-glue - interfaces with the device on using an interface provided by the - bus-specific driver. The reason for this breakup is to be able to - easily reuse the hardware-glue to write drivers for other OSes; note - the hardware glue part is written as a native Linux driver; no - abstraction layers are used, so to port to another OS, the Linux kernel - API calls should be replaced with the target OS's. - -5. Usage -======== - - To load the driver, follow the instructions in the install section; - once the driver is loaded, plug in the device (unless it is permanently - plugged in). The driver will enumerate the device, upload the firmware - and output messages in the kernel log (dmesg, /var/log/messages or - /var/log/kern.log) such as:: - - ... - i2400m_usb 5-4:1.0: firmware interface version 8.0.0 - i2400m_usb 5-4:1.0: WiMAX interface wmx0 (00:1d:e1:01:94:2c) ready - - At this point the device is ready to work. - - Current versions require the Intel WiMAX Network Service in userspace - to make things work. See the network service's README for instructions - on how to scan, connect and disconnect. - -5.1. Module parameters ----------------------- - - Module parameters can be set at kernel or module load time or by - echoing values:: - - $ echo VALUE > /sys/module/MODULENAME/parameters/PARAMETERNAME - - To make changes permanent, for example, for the i2400m module, you can - also create a file named /etc/modprobe.d/i2400m containing:: - - options i2400m idle_mode_disabled=1 - - To find which parameters are supported by a module, run:: - - $ modinfo path/to/module.ko - - During kernel bootup (if the driver is linked in the kernel), specify - the following to the kernel command line:: - - i2400m.PARAMETER=VALUE - -5.1.1. i2400m: idle_mode_disabled -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - The i2400m module supports a parameter to disable idle mode. This - parameter, once set, will take effect only when the device is - reinitialized by the driver (eg: following a reset or a reconnect). - -5.2. Debug operations: debugfs entries --------------------------------------- - - The driver will register debugfs entries that allow the user to tweak - debug settings. There are three main container directories where - entries are placed, which correspond to the three blocks a i2400m WiMAX - driver has: - - * /sys/kernel/debug/wimax:DEVNAME/ for the generic WiMAX stack - controls - * /sys/kernel/debug/wimax:DEVNAME/i2400m for the i2400m generic - driver controls - * /sys/kernel/debug/wimax:DEVNAME/i2400m-usb (or -sdio) for the - bus-specific i2400m-usb or i2400m-sdio controls). - - Of course, if debugfs is mounted in a directory other than - /sys/kernel/debug, those paths will change. - -5.2.1. Increasing debug output -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - The files named *dl_* indicate knobs for controlling the debug output - of different submodules:: - - # find /sys/kernel/debug/wimax\:wmx0 -name \*dl_\* - /sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_tx - /sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_rx - /sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_notif - /sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_fw - /sys/kernel/debug/wimax:wmx0/i2400m-usb/dl_usb - /sys/kernel/debug/wimax:wmx0/i2400m/dl_tx - /sys/kernel/debug/wimax:wmx0/i2400m/dl_rx - /sys/kernel/debug/wimax:wmx0/i2400m/dl_rfkill - /sys/kernel/debug/wimax:wmx0/i2400m/dl_netdev - /sys/kernel/debug/wimax:wmx0/i2400m/dl_fw - /sys/kernel/debug/wimax:wmx0/i2400m/dl_debugfs - /sys/kernel/debug/wimax:wmx0/i2400m/dl_driver - /sys/kernel/debug/wimax:wmx0/i2400m/dl_control - /sys/kernel/debug/wimax:wmx0/wimax_dl_stack - /sys/kernel/debug/wimax:wmx0/wimax_dl_op_rfkill - /sys/kernel/debug/wimax:wmx0/wimax_dl_op_reset - /sys/kernel/debug/wimax:wmx0/wimax_dl_op_msg - /sys/kernel/debug/wimax:wmx0/wimax_dl_id_table - /sys/kernel/debug/wimax:wmx0/wimax_dl_debugfs - - By reading the file you can obtain the current value of said debug - level; by writing to it, you can set it. - - To increase the debug level of, for example, the i2400m's generic TX - engine, just write:: - - $ echo 3 > /sys/kernel/debug/wimax:wmx0/i2400m/dl_tx - - Increasing numbers yield increasing debug information; for details of - what is printed and the available levels, check the source. The code - uses 0 for disabled and increasing values until 8. - -5.2.2. RX and TX statistics -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - The i2400m/rx_stats and i2400m/tx_stats provide statistics about the - data reception/delivery from the device:: - - $ cat /sys/kernel/debug/wimax:wmx0/i2400m/rx_stats - 45 1 3 34 3104 48 480 - - The numbers reported are: - - * packets/RX-buffer: total, min, max - * RX-buffers: total RX buffers received, accumulated RX buffer size - in bytes, min size received, max size received - - Thus, to find the average buffer size received, divide accumulated - RX-buffer / total RX-buffers. - - To clear the statistics back to 0, write anything to the rx_stats file:: - - $ echo 1 > /sys/kernel/debug/wimax:wmx0/i2400m_rx_stats - - Likewise for TX. - - Note the packets this debug file refers to are not network packet, but - packets in the sense of the device-specific protocol for communication - to the host. See drivers/net/wimax/i2400m/tx.c. - -5.2.3. Tracing messages received from user space -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - To echo messages received from user space into the trace pipe that the - i2400m driver creates, set the debug file i2400m/trace_msg_from_user to - 1:: - - $ echo 1 > /sys/kernel/debug/wimax:wmx0/i2400m/trace_msg_from_user - -5.2.4. Performing a device reset -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - By writing a 0, a 1 or a 2 to the file - /sys/kernel/debug/wimax:wmx0/reset, the driver performs a warm (without - disconnecting from the bus), cold (disconnecting from the bus) or bus - (bus specific) reset on the device. - -5.2.5. Asking the device to enter power saving mode -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - By writing any value to the /sys/kernel/debug/wimax:wmx0 file, the - device will attempt to enter power saving mode. - -6. Troubleshooting -================== - -6.1. Driver complains about ``i2400m-fw-usb-1.2.sbcf: request failed`` ----------------------------------------------------------------------- - - If upon connecting the device, the following is output in the kernel - log:: - - i2400m_usb 5-4:1.0: fw i2400m-fw-usb-1.3.sbcf: request failed: -2 - - This means that the driver cannot locate the firmware file named - /lib/firmware/i2400m-fw-usb-1.2.sbcf. Check that the file is present in - the right location. diff --git a/Documentation/admin-guide/wimax/index.rst b/Documentation/admin-guide/wimax/index.rst deleted file mode 100644 index fdf7c1f99ff5..000000000000 --- a/Documentation/admin-guide/wimax/index.rst +++ /dev/null @@ -1,19 +0,0 @@ -.. SPDX-License-Identifier: GPL-2.0 - -=============== -WiMAX subsystem -=============== - -.. toctree:: - :maxdepth: 2 - - wimax - - i2400m - -.. only:: subproject and html - - Indices - ======= - - * :ref:`genindex` diff --git a/Documentation/admin-guide/wimax/wimax.rst b/Documentation/admin-guide/wimax/wimax.rst deleted file mode 100644 index 817ee8ba2732..000000000000 --- a/Documentation/admin-guide/wimax/wimax.rst +++ /dev/null @@ -1,89 +0,0 @@ -.. include:: - -======================== -Linux kernel WiMAX stack -======================== - -:Copyright: |copy| 2008 Intel Corporation < linux-wimax@intel.com > - - This provides a basic Linux kernel WiMAX stack to provide a common - control API for WiMAX devices, usable from kernel and user space. - -1. Design -========= - - The WiMAX stack is designed to provide for common WiMAX control - services to current and future WiMAX devices from any vendor. - - Because currently there is only one and we don't know what would be the - common services, the APIs it currently provides are very minimal. - However, it is done in such a way that it is easily extensible to - accommodate future requirements. - - The stack works by embedding a struct wimax_dev in your device's - control structures. This provides a set of callbacks that the WiMAX - stack will call in order to implement control operations requested by - the user. As well, the stack provides API functions that the driver - calls to notify about changes of state in the device. - - The stack exports the API calls needed to control the device to user - space using generic netlink as a marshalling mechanism. You can access - them using your own code or use the wrappers provided for your - convenience in libwimax (in the wimax-tools package). - - For detailed information on the stack, please see - include/linux/wimax.h. - -2. Usage -======== - - For usage in a driver (registration, API, etc) please refer to the - instructions in the header file include/linux/wimax.h. - - When a device is registered with the WiMAX stack, a set of debugfs - files will appear in /sys/kernel/debug/wimax:wmxX can tweak for - control. - -2.1. Obtaining debug information: debugfs entries -------------------------------------------------- - - The WiMAX stack is compiled, by default, with debug messages that can - be used to diagnose issues. By default, said messages are disabled. - - The drivers will register debugfs entries that allow the user to tweak - debug settings. - - Each driver, when registering with the stack, will cause a debugfs - directory named wimax:DEVICENAME to be created; optionally, it might - create more subentries below it. - -2.1.1. Increasing debug output ------------------------------- - - The files named *dl_* indicate knobs for controlling the debug output - of different submodules of the WiMAX stack:: - - # find /sys/kernel/debug/wimax\:wmx0 -name \*dl_\* - /sys/kernel/debug/wimax:wmx0/wimax_dl_stack - /sys/kernel/debug/wimax:wmx0/wimax_dl_op_rfkill - /sys/kernel/debug/wimax:wmx0/wimax_dl_op_reset - /sys/kernel/debug/wimax:wmx0/wimax_dl_op_msg - /sys/kernel/debug/wimax:wmx0/wimax_dl_id_table - /sys/kernel/debug/wimax:wmx0/wimax_dl_debugfs - /sys/kernel/debug/wimax:wmx0/.... # other driver specific files - - NOTE: - Of course, if debugfs is mounted in a directory other than - /sys/kernel/debug, those paths will change. - - By reading the file you can obtain the current value of said debug - level; by writing to it, you can set it. - - To increase the debug level of, for example, the id-table submodule, - just write: - - $ echo 3 > /sys/kernel/debug/wimax:wmx0/wimax_dl_id_table - - Increasing numbers yield increasing debug information; for details of - what is printed and the available levels, check the source. The code - uses 0 for disabled and increasing values until 8. diff --git a/Documentation/networking/kapi.rst b/Documentation/networking/kapi.rst index d198fa5eaacd..ea55f462cefa 100644 --- a/Documentation/networking/kapi.rst +++ b/Documentation/networking/kapi.rst @@ -83,27 +83,6 @@ SUN RPC subsystem .. kernel-doc:: net/sunrpc/clnt.c :export: -WiMAX ------ - -.. kernel-doc:: net/wimax/op-msg.c - :export: - -.. kernel-doc:: net/wimax/op-reset.c - :export: - -.. kernel-doc:: net/wimax/op-rfkill.c - :export: - -.. kernel-doc:: net/wimax/stack.c - :export: - -.. kernel-doc:: include/net/wimax.h - :internal: - -.. kernel-doc:: include/uapi/linux/wimax.h - :internal: - Network device support ====================== diff --git a/Documentation/translations/zh_CN/admin-guide/index.rst b/Documentation/translations/zh_CN/admin-guide/index.rst index ed5ab7e37f38..48bbd3ebad48 100644 --- a/Documentation/translations/zh_CN/admin-guide/index.rst +++ b/Documentation/translations/zh_CN/admin-guide/index.rst @@ -114,7 +114,6 @@ Todolist: unicode vga-softcursor video-output - wimax/index xfs .. only:: subproject and html -- cgit v1.2.3 From d9395d72003365dd2221922ba73a184603848124 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Thu, 29 Oct 2020 17:21:32 +0100 Subject: dt-bindings: watchdog: fsl-imx: document NXP compatibles Document all ARMv5, ARMv6, ARMv7 and ARMv8 NXP (i.MX, Layerscape) compatibles used in DTSes (even though driver binds only to fsl,imx21-wdt) to fix dtbs_check warnings like: arch/arm/boot/dts/imx53-qsb.dt.yaml: gpio@53fe0000: compatible: ['fsl,imx53-gpio', 'fsl,imx35-gpio'] is not valid under any of the given schemas Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Shawn Guo --- .../devicetree/bindings/watchdog/fsl-imx-wdt.yaml | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml index 991b4e33486e..fb7695515be1 100644 --- a/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.yaml @@ -18,10 +18,26 @@ properties: - const: fsl,imx21-wdt - items: - enum: + - fsl,imx25-wdt + - fsl,imx27-wdt + - fsl,imx31-wdt + - fsl,imx35-wdt + - fsl,imx50-wdt + - fsl,imx51-wdt + - fsl,imx53-wdt + - fsl,imx6q-wdt + - fsl,imx6sl-wdt + - fsl,imx6sll-wdt + - fsl,imx6sx-wdt + - fsl,imx6ul-wdt + - fsl,imx7d-wdt - fsl,imx8mm-wdt - fsl,imx8mn-wdt - fsl,imx8mp-wdt - fsl,imx8mq-wdt + - fsl,ls1012a-wdt + - fsl,ls1043a-wdt + - fsl,vf610-wdt - const: fsl,imx21-wdt reg: -- cgit v1.2.3 From b01222b9193e40557b5a3bdf833898812ef36dcb Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Wed, 30 Sep 2020 21:01:32 +0200 Subject: dt-bindings: vendor-prefixes: add MicroSys Document vendor prefix for MicroSys Electronics GmbH. Signed-off-by: Krzysztof Kozlowski Acked-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 2735be1a8470..8e477373211a 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -669,6 +669,8 @@ patternProperties: description: Micron Technology Inc. "^microsoft,.*": description: Microsoft Corporation + "^microsys,.*": + description: MicroSys Electronics GmbH "^mikroe,.*": description: MikroElektronika d.o.o. "^mikrotik,.*": -- cgit v1.2.3 From 1acb40298366b8350d34db47dd9aae72ff18691e Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Wed, 30 Sep 2020 21:01:33 +0200 Subject: dt-bindings: vendor-prefixes: add Revotics Document vendor prefix for Revotics (Revolution Robotics, Inc.). Signed-off-by: Krzysztof Kozlowski Acked-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 8e477373211a..39f0d7c074fe 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -896,6 +896,8 @@ patternProperties: description: iMX6 Rex Project "^rervision,.*": description: Shenzhen Rervision Technology Co., Ltd. + "^revotics,.*": + description: Revolution Robotics, Inc. (Revotics) "^richtek,.*": description: Richtek Technology Corporation "^ricoh,.*": -- cgit v1.2.3 From 5427f287976c4dd1c1ffb4c0cb94d50d3cd14244 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Wed, 30 Sep 2020 21:01:35 +0200 Subject: dt-bindings: arm: fsl: document i.MX51 boards Document and adjust the compatibles for i.MX51 based boards. Signed-off-by: Krzysztof Kozlowski Acked-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 26 +++++++++++++++++++++++--- 1 file changed, 23 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 76e1628dbdbb..c381863116aa 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -129,13 +129,33 @@ properties: - kobo,aura - const: fsl,imx50 - - description: i.MX51 Babbage Board + - description: i.MX51 based Boards items: - enum: - - armadeus,imx51-apf51 # APF51 SoM - - armadeus,imx51-apf51dev # APF51 SoM on APF51Dev board + - armadeus,imx51-apf51 # Armadeus Systems APF51 module - fsl,imx51-babbage - technologic,imx51-ts4800 + - zii,imx51-scu3-esb + - zii,imx51-scu2-mezz + - zii,imx51-rdu1 + - const: fsl,imx51 + + - description: i.MX51 based Armadeus Systems APF51Dev Board + items: + - const: armadeus,imx51-apf51dev + - const: armadeus,imx51-apf51 + - const: fsl,imx51 + + - description: i.MX51 based Digi ConnectCore CC(W)-MX51 JSK Board + items: + - const: digi,connectcore-ccxmx51-jsk + - const: digi,connectcore-ccxmx51-som + - const: fsl,imx51 + + - description: i.MX51 based Eukrea CPUIMX51 Board + items: + - const: eukrea,mbimxsd51 + - const: eukrea,cpuimx51 - const: fsl,imx51 - description: i.MX53 based Boards -- cgit v1.2.3 From be03d03b5cf806548547edff1a9b82ae91f679c6 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Wed, 30 Sep 2020 21:01:36 +0200 Subject: dt-bindings: arm: fsl: document i.MX53 boards Document and adjust the compatibles for i.MX53 based boards. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index c381863116aa..b049d3c3cc3a 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -165,8 +165,27 @@ properties: - fsl,imx53-ard - fsl,imx53-evk - fsl,imx53-qsb + - fsl,imx53-qsrb # Freescale i.MX53 Quick Start-R Board - fsl,imx53-smd + - ge,imx53-cpuvo # General Electric CS ONE + - inversepath,imx53-usbarmory # Inverse Path USB armory + - karo,tx53 # Ka-Ro electronics TX53 module + - kiebackpeter,imx53-ddc # K+P imx53 DDC + - kiebackpeter,imx53-hsc # K+P imx53 HSC - menlo,m53menlo + - voipac,imx53-dmm-668 # Voipac i.MX53 X53-DMM-668 + - const: fsl,imx53 + + - description: i.MX53 based Aries/DENX M53EVK Board + items: + - const: aries,imx53-m53evk + - const: denx,imx53-m53evk + - const: fsl,imx53 + + - description: i.MX53 based TQ MBa53 Board + items: + - const: tq,mba53 + - const: tq,tqma53 - const: fsl,imx53 - description: i.MX6Q based Boards -- cgit v1.2.3 From 9d808cbfa5e721e8e400a7d7678b9f9c28ff9512 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Wed, 30 Sep 2020 21:01:37 +0200 Subject: dt-bindings: arm: fsl: document VF boards Document and adjust the compatibles for VF500 and VF600 based boards. The Toradex Colibri Evaluation Boards use multiple compatibles. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index b049d3c3cc3a..d7bbcb1f59b6 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -581,10 +581,26 @@ properties: - fsl,vf600 - fsl,vf610 - fsl,vf610m4 - - toradex,vf500-colibri_vf50 # Colibri VF50 Module - - toradex,vf500-colibri_vf50-on-eval # Colibri VF50 Module on Colibri Evaluation Board - - toradex,vf610-colibri_vf61 # Colibri VF61 Module - - toradex,vf610-colibri_vf61-on-eval # Colibri VF61 Module on Colibri Evaluation Board + + - description: Toradex Colibri VF50 Module on Colibri Evaluation Board + items: + - const: toradex,vf500-colibri_vf50-on-eval + - const: toradex,vf500-colibri_vf50 + - const: fsl,vf500 + + - description: VF610 based Boards + items: + - enum: + - lwn,bk4 # Liebherr BK4 controller + - phytec,vf610-cosmic # PHYTEC Cosmic/Cosmic+ Board + - fsl,vf610-twr # VF610 Tower Board + - const: fsl,vf610 + + - description: Toradex Colibri VF61 Module on Colibri Evaluation Board + items: + - const: toradex,vf610-colibri_vf61-on-eval + - const: toradex,vf610-colibri_vf61 + - const: fsl,vf610 - description: ZII's VF610 based Boards items: -- cgit v1.2.3 From c470ce79fe46aa35a6c7922b00ce2be5ba15b2f4 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Wed, 30 Sep 2020 21:01:38 +0200 Subject: dt-bindings: arm: fsl: document i.MX6DL boards Document and adjust the compatibles for i.MX6DL based boards. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 49 ++++++++++++++++++++++---- 1 file changed, 43 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index d7bbcb1f59b6..f45e243916d8 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -269,32 +269,53 @@ properties: - description: i.MX6DL based Boards items: - enum: - - armadeus,imx6dl-apf6 # APF6 (Solo) SoM - - armadeus,imx6dl-apf6dev # APF6 (Solo) SoM on APF6Dev board + - boundary,imx6dl-nit6xlite # Boundary Devices Nitrogen6 Lite + - boundary,imx6dl-nitrogen6x # Boundary Devices Nitrogen6x + - bticino,imx6dl-mamoj # BTicino i.MX6DL Mamoj - eckelmann,imx6dl-ci4x10 - emtrion,emcon-mx6 # emCON-MX6S or emCON-MX6DL SoM - emtrion,emcon-mx6-avari # emCON-MX6S or emCON-MX6DL SoM on Avari Base + - engicam,imx6-icore # Engicam i.CoreM6 Starter Kit + - engicam,imx6-icore-rqs # Engicam i.CoreM6 RQS Starter Kit - fsl,imx6dl-sabreauto # i.MX6 DualLite/Solo SABRE Automotive Board + - fsl,imx6dl-sabrelite # i.MX6 DualLite SABRE Lite Board - fsl,imx6dl-sabresd # i.MX6 DualLite SABRE Smart Device Board + - karo,imx6dl-tx6dl # Ka-Ro electronics TX6U Modules - kontron,imx6dl-samx6i # Kontron i.MX6 Solo SMARC Module + - poslab,imx6dl-savageboard # Poslab SavageBoard Dual - prt,prtrvt # Protonic RVT board - prt,prtvt7 # Protonic VT7 board + - rex,imx6dl-rex-basic # Rex Basic i.MX6 Dual Lite Board + - riot,imx6s-riotboard # RIoTboard i.MX6S + - solidrun,cubox-i/dl # SolidRun Cubox-i Solo/DualLite + - solidrun,hummingboard/dl + - solidrun,hummingboard2/dl # SolidRun HummingBoard2 Solo/DualLite - technexion,imx6dl-pico-dwarf # TechNexion i.MX6DL Pico-Dwarf - technexion,imx6dl-pico-hobbit # TechNexion i.MX6DL Pico-Hobbit - technexion,imx6dl-pico-nymph # TechNexion i.MX6DL Pico-Nymph - technexion,imx6dl-pico-pi # TechNexion i.MX6DL Pico-Pi - technologic,imx6dl-ts4900 - technologic,imx6dl-ts7970 - - toradex,colibri_imx6dl # Colibri iMX6 Module - - toradex,colibri_imx6dl-v1_1 # Colibri iMX6 Module V1.1 - - toradex,colibri_imx6dl-eval-v3 # Colibri iMX6 Module on Colibri Evaluation Board V3 - - toradex,colibri_imx6dl-v1_1-eval-v3 # Colibri iMX6 Module V1.1 on Colibri Evaluation Board V3 + - udoo,imx6dl-udoo # Udoo i.MX6 Dual-lite Board + - wand,imx6dl-wandboard # Wandboard i.MX6 Dual Lite Board - ysoft,imx6dl-yapp4-draco # i.MX6 DualLite Y Soft IOTA Draco board - ysoft,imx6dl-yapp4-hydra # i.MX6 DualLite Y Soft IOTA Hydra board - ysoft,imx6dl-yapp4-orion # i.MX6 DualLite Y Soft IOTA Orion board - ysoft,imx6dl-yapp4-ursa # i.MX6 Solo Y Soft IOTA Ursa board - const: fsl,imx6dl + - description: i.MX6DL based Armadeus AFP6 Board + items: + - const: armadeus,imx6dl-apf6dev + - const: armadeus,imx6dl-apf6 # APF6 (Solo) SoM + - const: fsl,imx6dl + + - description: i.MX6DL based DFI FS700-M60-6DL Board + items: + - const: dfi,fs700-m60-6dl + - const: dfi,fs700e-m60 + - const: fsl,imx6dl + - description: i.MX6DL Gateworks Ventana Boards items: - enum: @@ -330,6 +351,22 @@ properties: - const: phytec,imx6dl-pfla02 # PHYTEC phyFLEX-i.MX6 Quad - const: fsl,imx6dl + - description: i.MX6DL Toradex Colibri iMX6 Module on Colibri + Evaluation Board V3 + items: + - const: toradex,colibri_imx6dl-eval-v3 + - const: toradex,colibri_imx6dl # Colibri iMX6 Module + - const: fsl,imx6dl + + - description: i.MX6DL Toradex Colibri iMX6 Module V1.1 on Colibri + Evaluation Board V3 + items: + - const: toradex,colibri_imx6dl-v1_1-eval-v3 + - const: toradex,colibri_imx6dl-v1_1 # Colibri iMX6 Module V1.1 + - const: toradex,colibri_imx6dl-eval-v3 + - const: toradex,colibri_imx6dl # Colibri iMX6 Module + - const: fsl,imx6dl + - description: i.MX6SL based Boards items: - enum: -- cgit v1.2.3 From 5c32a75e2ed169c01e8af1e7f153e962c08763d8 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Wed, 30 Sep 2020 21:01:40 +0200 Subject: dt-bindings: vendor-prefixes: add ABB Document binding for ABB. Cc: Heiko Schocher Signed-off-by: Krzysztof Kozlowski Reviewed-by: Heiko Schocher Acked-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 39f0d7c074fe..5b0ec640cf49 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -25,6 +25,8 @@ patternProperties: # Keep list in alphabetical order. "^70mai,.*": description: 70mai Co., Ltd. + "^abb,.*": + description: ABB "^abilis,.*": description: Abilis Systems "^abracon,.*": -- cgit v1.2.3 From 676884326eeac5d6affbe3e13bb90d0de8f49cd2 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Wed, 30 Sep 2020 21:01:41 +0200 Subject: dt-bindings: arm: fsl: document i.MX6DL Aristainetos boards Document and adjust the compatibles for i.MX6DL based Aristainetos boards from ABB. Cc: Heiko Schocher Signed-off-by: Krzysztof Kozlowski Reviewed-by: Heiko Schocher Acked-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index f45e243916d8..05fe39fcdf5f 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -269,6 +269,10 @@ properties: - description: i.MX6DL based Boards items: - enum: + - abb,aristainetos-imx6dl-4 # aristainetos i.MX6 Dual Lite Board 4 + - abb,aristainetos-imx6dl-7 # aristainetos i.MX6 Dual Lite Board 7 + - abb,aristainetos2-imx6dl-4 # aristainetos2 i.MX6 Dual Lite Board 4 + - abb,aristainetos2-imx6dl-7 # aristainetos2 i.MX6 Dual Lite Board 7 - boundary,imx6dl-nit6xlite # Boundary Devices Nitrogen6 Lite - boundary,imx6dl-nitrogen6x # Boundary Devices Nitrogen6x - bticino,imx6dl-mamoj # BTicino i.MX6DL Mamoj -- cgit v1.2.3 From a687b55e10e9aaed1b1c9637771938db995cba52 Mon Sep 17 00:00:00 2001 From: Frieder Schrempf Date: Thu, 1 Oct 2020 17:13:38 +0200 Subject: dt-bindings: arm: fsl: Add Kontron i.MX8M Mini SoMs and boards Add entries for the SoMs and boards based on i.MX8MM from Kontron Electronics GmbH. Signed-off-by: Frieder Schrempf Reviewed-by: Rob Herring Reviewed-by: Krzysztof Kozlowski Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 05fe39fcdf5f..25b3f43e3fd1 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -536,9 +536,16 @@ properties: - beacon,imx8mm-beacon-kit # i.MX8MM Beacon Development Kit - fsl,imx8mm-ddr4-evk # i.MX8MM DDR4 EVK Board - fsl,imx8mm-evk # i.MX8MM EVK Board + - kontron,imx8mm-n801x-som # i.MX8MM Kontron SL (N801X) SOM - variscite,var-som-mx8mm # i.MX8MM Variscite VAR-SOM-MX8MM module - const: fsl,imx8mm + - description: Kontron BL i.MX8MM (N801X S) Board + items: + - const: kontron,imx8mm-n801x-s + - const: kontron,imx8mm-n801x-som + - const: fsl,imx8mm + - description: Variscite VAR-SOM-MX8MM based boards items: - const: variscite,var-som-mx8mm-symphony -- cgit v1.2.3 From ea75e63105be661afc2e7fbe7f0af07d216af4cd Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Thu, 1 Oct 2020 19:07:48 +0200 Subject: dt-bindings: vendor-prefixes: add Element14 Document the binding for the Element14, a Premier Farnell company. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 5b0ec640cf49..6f138271f003 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -317,6 +317,8 @@ patternProperties: description: Einfochips "^elan,.*": description: Elan Microelectronic Corp. + "^element14,.*": + description: Element14 (A Premier Farnell Company) "^elgin,.*": description: Elgin S/A. "^elida,.*": -- cgit v1.2.3 From bec0a8cbe303e41f07303d213ae6b70ed6aaa93c Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Thu, 1 Oct 2020 19:07:49 +0200 Subject: dt-bindings: arm: fsl: document i.MX6Q boards Document and adjust the compatibles for i.MX6Q based boards. The Toradex and the Armadeus boards use multiple compatibles. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 83 ++++++++++++++++++++++++-- 1 file changed, 77 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 25b3f43e3fd1..3f0236263b55 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -191,29 +191,85 @@ properties: - description: i.MX6Q based Boards items: - enum: - - armadeus,imx6q-apf6 # APF6 (Quad/Dual) SoM - - armadeus,imx6q-apf6dev # APF6 (Quad/Dual) SoM on APF6Dev board + - auvidea,h100 # Auvidea H100 + - boundary,imx6q-nitrogen6_max + - boundary,imx6q-nitrogen6_som2 + - boundary,imx6q-nitrogen6x + - compulab,cm-fx6 # CompuLab CM-FX6 + - dmo,imx6q-edmqmx6 # Data Modul eDM-QMX6 Board + - embest,imx6q-marsboard # Embest MarS Board i.MX6Dual - emtrion,emcon-mx6 # emCON-MX6D or emCON-MX6Q SoM - emtrion,emcon-mx6-avari # emCON-MX6D or emCON-MX6Q SoM on Avari Base + - engicam,imx6-icore # Engicam i.CoreM6 Starter Kit + - engicam,imx6-icore-rqs # Engicam i.CoreM6 RQS Starter Kit - fsl,imx6q-arm2 - fsl,imx6q-sabreauto - fsl,imx6q-sabrelite - fsl,imx6q-sabresd + - karo,imx6q-tx6q # Ka-Ro electronics TX6Q Modules + - kiebackpeter,imx6q-tpc # K+P i.MX6 Quad TPC Board - kontron,imx6q-samx6i # Kontron i.MX6 Dual/Quad SMARC Module + - kosagi,imx6q-novena # Kosagi Novena Dual/Quad - logicpd,imx6q-logicpd + - lwn,display5 # Liebherr Display5 i.MX6 Quad Board + - lwn,mccmon6 # Liebherr Monitor6 i.MX6 Quad Board + - nutsboard,imx6q-pistachio # NutsBoard i.MX6 Quad Pistachio + - microsys,sbc6x # MicroSys sbc6x board + - poslab,imx6q-savageboard # Poslab SavageBoard Quad - prt,prti6q # Protonic PRTI6Q board - prt,prtwd2 # Protonic WD2 board + - rex,imx6q-rex-pro # Rex Pro i.MX6 Quad Board + - solidrun,cubox-i/q # SolidRun Cubox-i Dual/Quad + - solidrun,hummingboard/q + - solidrun,hummingboard2/q + - tbs,imx6q-tbs2910 # TBS2910 Matrix ARM mini PC - technexion,imx6q-pico-dwarf # TechNexion i.MX6Q Pico-Dwarf - technexion,imx6q-pico-hobbit # TechNexion i.MX6Q Pico-Hobbit - technexion,imx6q-pico-nymph # TechNexion i.MX6Q Pico-Nymph - technexion,imx6q-pico-pi # TechNexion i.MX6Q Pico-Pi - technologic,imx6q-ts4900 - technologic,imx6q-ts7970 - - toradex,apalis_imx6q # Apalis iMX6 Module - - toradex,apalis_imx6q-eval # Apalis iMX6 Module on Apalis Evaluation Board - - toradex,apalis_imx6q-ixora # Apalis iMX6 Module on Ixora - - toradex,apalis_imx6q-ixora-v1.1 # Apalis iMX6 Module on Ixora V1.1 + - toradex,apalis_imx6q # Apalis iMX6 Module + - udoo,imx6q-udoo # Udoo i.MX6 Quad Board + - uniwest,imx6q-evi # Uniwest Evi - variscite,dt6customboard + - wand,imx6q-wandboard # Wandboard i.MX6 Quad Board + - zealz,imx6q-gk802 # Zealz GK802 + - zii,imx6q-zii-rdu2 # ZII RDU2 Board + - const: fsl,imx6q + + - description: i.MX6Q Advantech DMS-BA16 Boards + items: + - enum: + - advantech,imx6q-dms-ba16 # Advantech DMS-BA16 + - ge,imx6q-b450v3 # General Electric B450v3 + - ge,imx6q-b650v3 # General Electric B650v3 + - ge,imx6q-b850v3 # General Electric B850v3 + - const: advantech,imx6q-ba16 + - const: fsl,imx6q + + - description: i.MX6Q Armadeus APF6 Boards + items: + - const: armadeus,imx6q-apf6dev + - const: armadeus,imx6q-apf6 + - const: fsl,imx6q + + - description: i.MX6Q CompuLab Utilite Pro Board + items: + - const: compulab,utilite-pro + - const: compulab,cm-fx6 + - const: fsl,imx6q + + - description: i.MX6Q DFI FS700-M60-6QD Board + items: + - const: dfi,fs700-m60-6qd + - const: dfi,fs700e-m60 + - const: fsl,imx6q + + - description: i.MX6Q DHCOM Premium Developer Kit Board + items: + - const: dh,imx6q-dhcom-pdk2 + - const: dh,imx6q-dhcom-som - const: fsl,imx6q - description: i.MX6Q Gateworks Ventana Boards @@ -252,6 +308,21 @@ properties: - const: phytec,imx6q-pfla02 # PHYTEC phyFLEX-i.MX6 Quad - const: fsl,imx6q + - description: i.MX6Q Boards with Toradex Apalis iMX6Q/D Module + items: + - enum: + - toradex,apalis_imx6q-ixora # Apalis iMX6Q/D Module on Ixora Carrier Board + - toradex,apalis_imx6q-eval # Apalis iMX6Q/D Module on Apalis Evaluation Board + - const: toradex,apalis_imx6q + - const: fsl,imx6q + + - description: i.MX6Q Toradex Apalis iMX6Q/D Module on Ixora Carrier Board V1.1 + items: + - const: toradex,apalis_imx6q-ixora-v1.1 + - const: toradex,apalis_imx6q-ixora + - const: toradex,apalis_imx6q + - const: fsl,imx6q + - description: i.MX6QP based Boards items: - enum: -- cgit v1.2.3 From 691dab655c32e70d1b6d62488d1273a0b196e783 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Thu, 1 Oct 2020 19:07:50 +0200 Subject: dt-bindings: arm: fsl: document i.MX6QP boards Document and adjust the compatibles for i.MX6QP based boards. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 3f0236263b55..0bcc3be4b7c5 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -326,8 +326,13 @@ properties: - description: i.MX6QP based Boards items: - enum: + - boundary,imx6qp-nitrogen6_max + - boundary,imx6qp-nitrogen6_som2 - fsl,imx6qp-sabreauto # i.MX6 Quad Plus SABRE Automotive Board - fsl,imx6qp-sabresd # i.MX6 Quad Plus SABRE Smart Device Board + - karo,imx6qp-tx6qp # Ka-Ro electronics TX6QP-8037 Module + - wand,imx6qp-wandboard # Wandboard i.MX6 QuadPlus Board + - zii,imx6qp-zii-rdu2 # ZII RDU2+ Board - const: fsl,imx6qp - description: i.MX6QP PHYTEC phyBOARD-Mira -- cgit v1.2.3 From 9fa659393ab139705669e14f615cfe665113eb5f Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Thu, 1 Oct 2020 19:07:51 +0200 Subject: dt-bindings: arm: fsl: document i.MX6SL boards Document and adjust the compatibles for i.MX6SL based boards. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 0bcc3be4b7c5..92a72edeb022 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -453,6 +453,7 @@ properties: - fsl,imx6sl-evk # i.MX6 SoloLite EVK Board - kobo,tolino-shine2hd - kobo,tolino-shine3 + - revotics,imx6sl-warp # Revotics WaRP Board - const: fsl,imx6sl - description: i.MX6SLL based Boards -- cgit v1.2.3 From d59dca0dff43a69874e0b4a8c0eb84f136928daf Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Thu, 1 Oct 2020 19:07:52 +0200 Subject: dt-bindings: arm: fsl: document i.MX6SX boards Document and adjust the compatibles for i.MX6SX based boards. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 92a72edeb022..20bbe19aa6a9 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -466,9 +466,14 @@ properties: - description: i.MX6SX based Boards items: - enum: + - boundary,imx6sx-nitrogen6sx - fsl,imx6sx-sabreauto # i.MX6 SoloX Sabre Auto Board - fsl,imx6sx-sdb # i.MX6 SoloX SDB Board - fsl,imx6sx-sdb-reva # i.MX6 SoloX SDB Rev-A Board + - samtec,imx6sx-vining-2000 # Softing VIN|ING 2000 Board + - udoo,neobasic # UDOO Neo Basic Board + - udoo,neoextended # UDOO Neo Extended + - udoo,neofull # UDOO Neo Full - const: fsl,imx6sx - description: i.MX6UL based Boards -- cgit v1.2.3 From f7c7c45d1e0eb7f44c1661e1c80c87e001aaeb60 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Thu, 1 Oct 2020 19:07:53 +0200 Subject: dt-bindings: arm: fsl: document i.MX6UL boards Document and adjust the compatibles for i.MX6UL based boards. The Armadeus boards use multiple compatibles. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 25 +++++++++++++++++++++++-- 1 file changed, 23 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 20bbe19aa6a9..fcd9c150a715 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -479,9 +479,10 @@ properties: - description: i.MX6UL based Boards items: - enum: - - armadeus,imx6ul-opos6ul # OPOS6UL (i.MX6UL) SoM - - armadeus,imx6ul-opos6uldev # OPOS6UL (i.MX6UL) SoM on OPOS6ULDev board + - engicam,imx6ul-geam # Engicam GEAM6UL Starter Kit + - engicam,imx6ul-isiot # Engicam Is.IoT MX6UL eMMC/NAND Starter kit - fsl,imx6ul-14x14-evk # i.MX6 UltraLite 14x14 EVK Board + - karo,imx6ul-tx6ul # Ka-Ro electronics TXUL-0010 Module - kontron,imx6ul-n6310-som # Kontron N6310 SOM - kontron,imx6ul-n6311-som # Kontron N6311 SOM - technexion,imx6ul-pico-dwarf # TechNexion i.MX6UL Pico-Dwarf @@ -489,6 +490,26 @@ properties: - technexion,imx6ul-pico-pi # TechNexion i.MX6UL Pico-Pi - const: fsl,imx6ul + - description: i.MX6UL Armadeus Systems OPOS6UL SoM Board + items: + - const: armadeus,imx6ul-opos6uldev # OPOS6UL (i.MX6UL) SoM on OPOS6ULDev board + - const: armadeus,imx6ul-opos6ul # OPOS6UL (i.MX6UL) SoM + - const: fsl,imx6ul + + - description: i.MX6UL Digi International ConnectCore 6UL Boards + items: + - enum: + - digi,ccimx6ulsbcexpress # Digi International ConnectCore 6UL SBC Express + - digi,ccimx6ulsbcpro # Digi International ConnectCore 6UL SBC Pro + - const: digi,ccimx6ulsom + - const: fsl,imx6ul + + - description: i.MX6UL Grinn liteBoard + items: + - const: grinn,imx6ul-liteboard + - const: grinn,imx6ul-litesom + - const: fsl,imx6ul + - description: i.MX6UL PHYTEC phyBOARD-Segin items: - enum: -- cgit v1.2.3 From 156b4a654019134c16343dbaaf10e585b42c15ce Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Thu, 1 Oct 2020 19:07:54 +0200 Subject: dt-bindings: arm: fsl: document i.MX6ULL boards Document and adjust the compatibles for i.MX6ULL based boards. The Armadeus boards use multiple compatibles. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index fcd9c150a715..53e389417738 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -541,8 +541,6 @@ properties: - description: i.MX6ULL based Boards items: - enum: - - armadeus,imx6ull-opos6ul # OPOS6UL (i.MX6ULL) SoM - - armadeus,imx6ull-opos6uldev # OPOS6UL (i.MX6ULL) SoM on OPOS6ULDev board - fsl,imx6ull-14x14-evk # i.MX6 UltraLiteLite 14x14 EVK Board - kontron,imx6ull-n6411-som # Kontron N6411 SOM - myir,imx6ull-mys-6ulx-eval # MYiR Tech iMX6ULL Evaluation Board @@ -550,6 +548,12 @@ properties: - toradex,colibri-imx6ull-wifi-eval # Colibri iMX6ULL Wi-Fi / BT Module on Colibri Eval Board - const: fsl,imx6ull + - description: i.MX6ULL Armadeus Systems OPOS6ULDev Board + items: + - const: armadeus,imx6ull-opos6uldev # OPOS6UL (i.MX6ULL) SoM on OPOS6ULDev board + - const: armadeus,imx6ull-opos6ul # OPOS6UL (i.MX6ULL) SoM + - const: fsl,imx6ull + - description: i.MX6ULL PHYTEC phyBOARD-Segin items: - enum: -- cgit v1.2.3 From da2a602c03cd6bb8d0417fb35ae7c26ed04028ea Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Thu, 1 Oct 2020 19:07:56 +0200 Subject: dt-bindings: arm: fsl: document i.MX7D boards Document and adjust the compatibles for i.MX7D based boards. Signed-off-by: Krzysztof Kozlowski Reviewed-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 53e389417738..417b5634d3f1 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -593,6 +593,8 @@ properties: - description: i.MX7D based Boards items: - enum: + - boundary,imx7d-nitrogen7 + - compulab,cl-som-imx7 # CompuLab CL-SOM-iMX7 - fsl,imx7d-sdb # i.MX7 SabreSD Board - fsl,imx7d-sdb-reva # i.MX7 SabreSD Rev-A Board - novtech,imx7d-meerkat96 # i.MX7 Meerkat96 Board @@ -630,6 +632,22 @@ properties: - const: compulab,cl-som-imx7 - const: fsl,imx7d + - description: i.MX7D Boards with Toradex Colibri i.MX7D Module + items: + - enum: + - toradex,colibri-imx7d-aster # Module on Aster Carrier Board + - toradex,colibri-imx7d-eval-v3 # Module on Colibri Evaluation Board V3 + - const: toradex,colibri-imx7d + - const: fsl,imx7d + + - description: i.MX7D Boards with Toradex Colibri i.MX7D eMMC Module + items: + - enum: + - toradex,colibri-imx7d-emmc-aster # Module on Aster Carrier Board + - toradex,colibri-imx7d-emmc-eval-v3 # Module on Colibri Evaluation Board V3 + - const: toradex,colibri-imx7d-emmc + - const: fsl,imx7d + - description: i.MX7ULP based Boards items: - enum: -- cgit v1.2.3 From cb0362b6ec537619b842b54e794ae8a87a5122bb Mon Sep 17 00:00:00 2001 From: Eugen Hristev Date: Fri, 16 Oct 2020 11:17:51 +0300 Subject: dt-bindings: dmaengine: at_xdmac: add compatible with microchip,sama7g5 Add compatible to sama7g5 SoC. Signed-off-by: Eugen Hristev Acked-by: Rob Herring Link: https://lore.kernel.org/r/20201016081754.288488-1-eugen.hristev@microchip.com Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/dma/atmel-xdma.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/dma/atmel-xdma.txt b/Documentation/devicetree/bindings/dma/atmel-xdma.txt index 4dc398e1a371..510b7f25ba24 100644 --- a/Documentation/devicetree/bindings/dma/atmel-xdma.txt +++ b/Documentation/devicetree/bindings/dma/atmel-xdma.txt @@ -2,7 +2,8 @@ * XDMA Controller Required properties: -- compatible: Should be "atmel,sama5d4-dma" or "microchip,sam9x60-dma". +- compatible: Should be "atmel,sama5d4-dma", "microchip,sam9x60-dma" or + "microchip,sama7g5-dma". - reg: Should contain DMA registers location and length. - interrupts: Should contain DMA interrupt. - #dma-cells: Must be <1>, used to represent the number of integer cells in -- cgit v1.2.3 From 4749f51ddd8aee5c7aa11e6593a54f96374a77ad Mon Sep 17 00:00:00 2001 From: Dave Jiang Date: Tue, 27 Oct 2020 10:34:46 -0700 Subject: dmaengine: idxd: Add ABI documentation for shared wq Add the sysfs attribute bits in ABI/stable for shared wq support. Signed-off-by: Jing Lin Signed-off-by: Dave Jiang Reviewed-by: Tony Luck Reviewed-by: Dan Williams Link: https://lore.kernel.org/r/160382008649.3911367.10851752182908509837.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul --- Documentation/ABI/stable/sysfs-driver-dma-idxd | 14 ++++++++++++++ 1 file changed, 14 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/stable/sysfs-driver-dma-idxd b/Documentation/ABI/stable/sysfs-driver-dma-idxd index b44183880935..5ea81ffd3c1a 100644 --- a/Documentation/ABI/stable/sysfs-driver-dma-idxd +++ b/Documentation/ABI/stable/sysfs-driver-dma-idxd @@ -77,6 +77,13 @@ Contact: dmaengine@vger.kernel.org Description: The operation capability bit mask specify the operation types supported by the this device. +What: /sys/bus/dsa/devices/dsa/pasid_enabled +Date: Oct 27, 2020 +KernelVersion: 5.11.0 +Contact: dmaengine@vger.kernel.org +Description: To indicate if PASID (process address space identifier) is + enabled or not for this device. + What: /sys/bus/dsa/devices/dsa/state Date: Oct 25, 2019 KernelVersion: 5.6.0 @@ -122,6 +129,13 @@ KernelVersion: 5.10.0 Contact: dmaengine@vger.kernel.org Description: The last executed device administrative command's status/error. +What: /sys/bus/dsa/devices/wq./block_on_fault +Date: Oct 27, 2020 +KernelVersion: 5.11.0 +Contact: dmaengine@vger.kernel.org +Description: To indicate block on fault is allowed or not for the work queue + to support on demand paging. + What: /sys/bus/dsa/devices/wq./group_id Date: Oct 25, 2019 KernelVersion: 5.6.0 -- cgit v1.2.3 From e84f44ba4604e55a51e7caf01464f220d0eabef4 Mon Sep 17 00:00:00 2001 From: Jernej Skrabec Date: Fri, 30 Oct 2020 15:46:43 +0100 Subject: ASoC: sun4i-i2s: Add H6 compatible MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit H6 I2S is very similar to H3, except that it supports up to 16 channels and thus few registers have fields on different position. Signed-off-by: Jernej Skrabec Signed-off-by: Marcus Cooper Acked-by: Maxime Ripard Acked-by: Rob Herring Acked-by: Chen-Yu Tsai Signed-off-by: Clément Péron Link: https://lore.kernel.org/r/20201030144648.397824-11-peron.clem@gmail.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml index 112ae00d63c1..606ad2d884a8 100644 --- a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml +++ b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml @@ -24,6 +24,7 @@ properties: - items: - const: allwinner,sun50i-a64-i2s - const: allwinner,sun8i-h3-i2s + - const: allwinner,sun50i-h6-i2s reg: maxItems: 1 @@ -59,6 +60,7 @@ allOf: - allwinner,sun8i-a83t-i2s - allwinner,sun8i-h3-i2s - allwinner,sun50i-a64-codec-i2s + - allwinner,sun50i-h6-i2s then: required: -- cgit v1.2.3 From 0bc1bf241de551842535c3d0b080e0f38c11aed1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Cl=C3=A9ment=20P=C3=A9ron?= Date: Fri, 30 Oct 2020 15:46:47 +0100 Subject: ASoC: sun4i-i2s: Document H3 with missing RX channel possibility MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Like A83T the Allwinner H3 doesn't have the DMA reception available for some audio interfaces. As it's already documented for A83T convert this to an enum and add the H3 interface. Acked-by: Rob Herring Signed-off-by: Clément Péron Link: https://lore.kernel.org/r/20201030144648.397824-15-peron.clem@gmail.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml index 606ad2d884a8..a16e37b01e1d 100644 --- a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml +++ b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml @@ -70,7 +70,9 @@ allOf: properties: compatible: contains: - const: allwinner,sun8i-a83t-i2s + enum: + - allwinner,sun8i-a83t-i2s + - allwinner,sun8i-h3-i2s then: properties: -- cgit v1.2.3 From 77f6c0b87479c4578ac0798fc249637092ac45a3 Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Thu, 24 Sep 2020 12:30:50 +0200 Subject: timekeeping: remove arch_gettimeoffset With Arm EBSA110 gone, nothing uses it any more, so the corresponding code and the Kconfig option can be removed. Acked-by: Thomas Gleixner Reviewed-by: Linus Walleij Signed-off-by: Arnd Bergmann --- .../time/modern-timekeeping/arch-support.txt | 33 ---------------------- 1 file changed, 33 deletions(-) delete mode 100644 Documentation/features/time/modern-timekeeping/arch-support.txt (limited to 'Documentation') diff --git a/Documentation/features/time/modern-timekeeping/arch-support.txt b/Documentation/features/time/modern-timekeeping/arch-support.txt deleted file mode 100644 index a84c3b9d9a94..000000000000 --- a/Documentation/features/time/modern-timekeeping/arch-support.txt +++ /dev/null @@ -1,33 +0,0 @@ -# -# Feature name: modern-timekeeping -# Kconfig: !ARCH_USES_GETTIMEOFFSET -# description: arch does not use arch_gettimeoffset() anymore -# - ----------------------- - | arch |status| - ----------------------- - | alpha: | ok | - | arc: | ok | - | arm: | TODO | - | arm64: | ok | - | c6x: | ok | - | csky: | ok | - | h8300: | ok | - | hexagon: | ok | - | ia64: | ok | - | m68k: | ok | - | microblaze: | ok | - | mips: | ok | - | nds32: | ok | - | nios2: | ok | - | openrisc: | ok | - | parisc: | ok | - | powerpc: | ok | - | riscv: | ok | - | s390: | ok | - | sh: | ok | - | sparc: | ok | - | um: | ok | - | x86: | ok | - | xtensa: | ok | - ----------------------- -- cgit v1.2.3 From 686092e7daaa9f43396c57ea0044799e47f0d9da Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Thu, 24 Sep 2020 15:30:34 +0200 Subject: parisc: use legacy_timer_tick parisc has selected CONFIG_GENERIC_CLOCKEVENTS since commit 43b1f6abd590 ("parisc: Switch to generic sched_clock implementation"), but does not appear to actually be using it, and instead calls the low-level timekeeping functions directly. Remove the GENERIC_CLOCKEVENTS select again, and instead convert to the newly added legacy_timer_tick() helper. Reviewed-by: Linus Walleij Signed-off-by: Arnd Bergmann --- Documentation/features/time/clockevents/arch-support.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/features/time/clockevents/arch-support.txt b/Documentation/features/time/clockevents/arch-support.txt index 8287b6aa522e..61a5c9d68c15 100644 --- a/Documentation/features/time/clockevents/arch-support.txt +++ b/Documentation/features/time/clockevents/arch-support.txt @@ -21,7 +21,7 @@ | nds32: | ok | | nios2: | ok | | openrisc: | ok | - | parisc: | ok | + | parisc: | TODO | | powerpc: | ok | | riscv: | ok | | s390: | ok | -- cgit v1.2.3 From 0774a6ed294b963dc76df2d8342ab86d030759ec Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Thu, 24 Sep 2020 11:32:40 +0200 Subject: timekeeping: default GENERIC_CLOCKEVENTS to enabled Almost all machines use GENERIC_CLOCKEVENTS, so it feels wrong to require each one to select that symbol manually. Instead, enable it whenever CONFIG_LEGACY_TIMER_TICK is disabled as a simplification. It should be possible to select both GENERIC_CLOCKEVENTS and LEGACY_TIMER_TICK from an architecture now and decide at runtime between the two. For the clockevents arch-support.txt file, this means that additional architectures are marked as TODO when they have at least one machine that still uses LEGACY_TIMER_TICK, rather than being marked 'ok' when at least one machine has been converted. This means that both m68k and arm (for riscpc) revert to TODO. At this point, we could just always enable CONFIG_GENERIC_CLOCKEVENTS rather than leaving it off when not needed. I built an m68k defconfig kernel (using gcc-10.1.0) and found that this would add around 5.5KB in kernel image size: text data bss dec hex filename 3861936 1092236 196656 5150828 4e986c obj-m68k/vmlinux-no-clockevent 3866201 1093832 196184 5156217 4ead79 obj-m68k/vmlinux-clockevent On Arm (MACH_RPC), that difference appears to be twice as large, around 11KB on top of an 6MB vmlinux. Reviewed-by: Geert Uytterhoeven Acked-by: Geert Uytterhoeven Tested-by: Geert Uytterhoeven Reviewed-by: Linus Walleij Signed-off-by: Arnd Bergmann --- Documentation/features/time/clockevents/arch-support.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/features/time/clockevents/arch-support.txt b/Documentation/features/time/clockevents/arch-support.txt index 61a5c9d68c15..6863a3fbddad 100644 --- a/Documentation/features/time/clockevents/arch-support.txt +++ b/Documentation/features/time/clockevents/arch-support.txt @@ -1,6 +1,6 @@ # # Feature name: clockevents -# Kconfig: GENERIC_CLOCKEVENTS +# Kconfig: !LEGACY_TIMER_TICK # description: arch support generic clock events # ----------------------- @@ -8,14 +8,14 @@ ----------------------- | alpha: | ok | | arc: | ok | - | arm: | ok | + | arm: | TODO | | arm64: | ok | | c6x: | ok | | csky: | ok | | h8300: | ok | | hexagon: | ok | | ia64: | TODO | - | m68k: | ok | + | m68k: | TODO | | microblaze: | ok | | mips: | ok | | nds32: | ok | -- cgit v1.2.3 From e8a3001c2120c760017da81a307308572a3cdbbc Mon Sep 17 00:00:00 2001 From: Xin Long Date: Thu, 29 Oct 2020 15:05:01 +0800 Subject: sctp: add encap_port for netns sock asoc and transport encap_port is added as per netns/sock/assoc/transport, and the latter one's encap_port inherits the former one's by default. The transport's encap_port value would mostly decide if one packet should go out with udp encapsulated or not. This patch also allows users to set netns' encap_port by sysctl. v1->v2: - Change to define encap_port as __be16 for sctp_sock, asoc and transport. v2->v3: - No change. v3->v4: - Add 'encap_port' entry in ip-sysctl.rst. v4->v5: - Improve the description of encap_port in ip-sysctl.rst. Signed-off-by: Xin Long Acked-by: Marcelo Ricardo Leitner Signed-off-by: Jakub Kicinski --- Documentation/networking/ip-sysctl.rst | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index 25e6673a085a..dad3ba952989 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -2642,6 +2642,22 @@ addr_scope_policy - INTEGER Default: 1 +encap_port - INTEGER + The default remote UDP encapsulation port. + + This value is used to set the dest port of the UDP header for the + outgoing UDP-encapsulated SCTP packets by default. Users can also + change the value for each sock/asoc/transport by using setsockopt. + For further information, please refer to RFC6951. + + Note that when connecting to a remote server, the client should set + this to the port that the UDP tunneling sock on the peer server is + listening to and the local UDP tunneling sock on the client also + must be started. On the server, it would get the encap_port from + the incoming packet's source port. + + Default: 0 + ``/proc/sys/net/core/*`` ======================== -- cgit v1.2.3 From 046c052b475e7119b6a30e3483e2888fc606a2f8 Mon Sep 17 00:00:00 2001 From: Xin Long Date: Thu, 29 Oct 2020 15:05:10 +0800 Subject: sctp: enable udp tunneling socks This patch is to enable udp tunneling socks by calling sctp_udp_sock_start() in sctp_ctrlsock_init(), and sctp_udp_sock_stop() in sctp_ctrlsock_exit(). Also add sysctl udp_port to allow changing the listening sock's port by users. Wit this patch, the whole sctp over udp feature can be enabled and used. v1->v2: - Also update ctl_sock udp_port in proc_sctp_do_udp_port() where netns udp_port gets changed. v2->v3: - Call htons() when setting sk udp_port from netns udp_port. v3->v4: - Not call sctp_udp_sock_start() when new_value is 0. - Add udp_port entry in ip-sysctl.rst. v4->v5: - Not call sctp_udp_sock_start/stop() in sctp_ctrlsock_init/exit(). - Improve the description of udp_port in ip-sysctl.rst. Signed-off-by: Xin Long Acked-by: Marcelo Ricardo Leitner Signed-off-by: Jakub Kicinski --- Documentation/networking/ip-sysctl.rst | 15 +++++++++++++++ 1 file changed, 15 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index dad3ba952989..2aaf40b2d2cd 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -2642,6 +2642,21 @@ addr_scope_policy - INTEGER Default: 1 +udp_port - INTEGER + The listening port for the local UDP tunneling sock. Normally it's + using the IANA-assigned UDP port number 9899 (sctp-tunneling). + + This UDP sock is used for processing the incoming UDP-encapsulated + SCTP packets (from RFC6951), and shared by all applications in the + same net namespace. This UDP sock will be closed when the value is + set to 0. + + The value will also be used to set the src port of the UDP header + for the outgoing UDP-encapsulated SCTP packets. For the dest port, + please refer to 'encap_port' below. + + Default: 0 + encap_port - INTEGER The default remote UDP encapsulation port. -- cgit v1.2.3 From 0f12999e27e087cd4c832760b59efd58c9642bb2 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Fri, 11 Sep 2020 16:33:41 +0200 Subject: Documentation: Update paths of Samsung S3C machine files Documentation references Samsung S3C24xx and S3C64xx machine files in multiple places but the files were traveling around the kernel multiple times. Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20200911143343.498-1-krzk@kernel.org --- Documentation/admin-guide/kernel-parameters.txt | 2 +- Documentation/arm/samsung-s3c24xx/gpio.rst | 4 ++-- Documentation/arm/samsung-s3c24xx/overview.rst | 22 +++++++--------------- Documentation/arm/samsung-s3c24xx/usb-host.rst | 6 +++--- Documentation/arm/samsung/gpio.rst | 3 +-- .../device_drivers/ethernet/davicom/dm9000.rst | 2 +- 6 files changed, 15 insertions(+), 24 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 526d65d8573a..bd512b70286d 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -2951,7 +2951,7 @@ mtdset= [ARM] ARM/S3C2412 JIVE boot control - See arch/arm/mach-s3c2412/mach-jive.c + See arch/arm/mach-s3c/mach-jive.c mtouchusb.raw_coordinates= [HW] Make the MicroTouch USB driver use raw coordinates diff --git a/Documentation/arm/samsung-s3c24xx/gpio.rst b/Documentation/arm/samsung-s3c24xx/gpio.rst index f7c3d7d011a2..f4a8c800a457 100644 --- a/Documentation/arm/samsung-s3c24xx/gpio.rst +++ b/Documentation/arm/samsung-s3c24xx/gpio.rst @@ -29,7 +29,7 @@ GPIOLIB The following functions now either have a `s3c_` specific variant or are merged into gpiolib. See the definitions in - arch/arm/plat-samsung/include/plat/gpio-cfg.h: + arch/arm/mach-s3c/gpio-cfg.h: - s3c2410_gpio_setpin() gpio_set_value() or gpio_direction_output() - s3c2410_gpio_getpin() gpio_get_value() or gpio_direction_input() @@ -86,7 +86,7 @@ between the calls. Headers ------- - See arch/arm/mach-s3c24xx/include/mach/regs-gpio.h for the list + See arch/arm/mach-s3c/regs-gpio-s3c24xx.h for the list of GPIO pins, and the configuration values for them. This is included by using #include diff --git a/Documentation/arm/samsung-s3c24xx/overview.rst b/Documentation/arm/samsung-s3c24xx/overview.rst index e9a1dc7276b5..14535e5cffb7 100644 --- a/Documentation/arm/samsung-s3c24xx/overview.rst +++ b/Documentation/arm/samsung-s3c24xx/overview.rst @@ -18,7 +18,7 @@ Introduction versions. The S3C2416 and S3C2450 devices are very similar and S3C2450 support is - included under the arch/arm/mach-s3c2416 directory. Note, while core + included under the arch/arm/mach-s3c directory. Note, while core support for these SoCs is in, work on some of the extra peripherals and extra interrupts is still ongoing. @@ -37,19 +37,11 @@ Configuration Layout ------ - The core support files are located in the platform code contained in - arch/arm/plat-s3c24xx with headers in include/asm-arm/plat-s3c24xx. - This directory should be kept to items shared between the platform - code (arch/arm/plat-s3c24xx) and the arch/arm/mach-s3c24* code. + The core support files, register, kernel and paltform data are located in the + platform code contained in arch/arm/mach-s3c with headers in + arch/arm/mach-s3c/include - Each cpu has a directory with the support files for it, and the - machines that carry the device. For example S3C2410 is contained - in arch/arm/mach-s3c2410 and S3C2440 in arch/arm/mach-s3c2440 - - Register, kernel and platform data definitions are held in the - arch/arm/mach-s3c2410 directory./include/mach - -arch/arm/plat-s3c24xx: +arch/arm/mach-s3c: Files in here are either common to all the s3c24xx family, or are common to only some of them with names to indicate this @@ -134,7 +126,7 @@ Adding New Machines should keep this in mind before altering items outside of their own machine files. - Machine definitions should be kept in linux/arch/arm/mach-s3c2410, + Machine definitions should be kept in arch/arm/mach-s3c, and there are a number of examples that can be looked at. Read the kernel patch submission policies as well as the @@ -293,7 +285,7 @@ Platform Data } Note, since the code is marked as __init, it should not be - exported outside arch/arm/mach-s3c2410/, or exported to + exported outside arch/arm/mach-s3c/, or exported to modules via EXPORT_SYMBOL() and related functions. diff --git a/Documentation/arm/samsung-s3c24xx/usb-host.rst b/Documentation/arm/samsung-s3c24xx/usb-host.rst index c84268bd1884..7aaffac89e04 100644 --- a/Documentation/arm/samsung-s3c24xx/usb-host.rst +++ b/Documentation/arm/samsung-s3c24xx/usb-host.rst @@ -36,7 +36,7 @@ Board Support ------------- The driver attaches to a platform device, which will need to be - added by the board specific support file in linux/arch/arm/mach-s3c2410, + added by the board specific support file in arch/arm/mach-s3c, such as mach-bast.c or mach-smdk2410.c The platform device's platform_data field is only needed if the @@ -51,9 +51,9 @@ Board Support Platform Data ------------- - See arch/arm/mach-s3c2410/include/mach/usb-control.h for the + See include/linux/platform_data/usb-ohci-s3c2410.h for the descriptions of the platform device data. An implementation - can be found in linux/arch/arm/mach-s3c2410/usb-simtec.c . + can be found in arch/arm/mach-s3c/simtec-usb.c . The `struct s3c2410_hcd_info` contains a pair of functions that get called to enable over-current detection, and to diff --git a/Documentation/arm/samsung/gpio.rst b/Documentation/arm/samsung/gpio.rst index 5f7cadd7159e..f6e27b07c993 100644 --- a/Documentation/arm/samsung/gpio.rst +++ b/Documentation/arm/samsung/gpio.rst @@ -37,5 +37,4 @@ implementation to configure pins as necessary. The s3c_gpio_cfgpin() and s3c_gpio_setpull() provide the means for a driver or machine to change gpio configuration. -See arch/arm/plat-samsung/include/plat/gpio-cfg.h for more information -on these functions. +See arch/arm/mach-s3c/gpio-cfg.h for more information on these functions. diff --git a/Documentation/networking/device_drivers/ethernet/davicom/dm9000.rst b/Documentation/networking/device_drivers/ethernet/davicom/dm9000.rst index d5458da01083..14eb0a4d4e4e 100644 --- a/Documentation/networking/device_drivers/ethernet/davicom/dm9000.rst +++ b/Documentation/networking/device_drivers/ethernet/davicom/dm9000.rst @@ -34,7 +34,7 @@ These resources should be specified in that order, as the ordering of the two address regions is important (the driver expects these to be address and then data). -An example from arch/arm/mach-s3c2410/mach-bast.c is:: +An example from arch/arm/mach-s3c/mach-bast.c is:: static struct resource bast_dm9k_resource[] = { [0] = { -- cgit v1.2.3 From c95003d895bde422e0daedab868d487dc40f84d4 Mon Sep 17 00:00:00 2001 From: Rui Miguel Silva Date: Wed, 14 Oct 2020 11:49:26 +0100 Subject: dt-bindings: fxas21002c: convert bindings to yaml Convert fxas21002c gyroscope sensor bindings documentation to yaml schema, remove the textual bindings document and update MAINTAINERS entry. Signed-off-by: Rui Miguel Silva Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20201014104926.688666-1-rmfrfs@gmail.com Signed-off-by: Jonathan Cameron --- .../bindings/iio/gyroscope/nxp,fxas21002c.txt | 31 ------- .../bindings/iio/gyroscope/nxp,fxas21002c.yaml | 95 ++++++++++++++++++++++ 2 files changed, 95 insertions(+), 31 deletions(-) delete mode 100644 Documentation/devicetree/bindings/iio/gyroscope/nxp,fxas21002c.txt create mode 100644 Documentation/devicetree/bindings/iio/gyroscope/nxp,fxas21002c.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/gyroscope/nxp,fxas21002c.txt b/Documentation/devicetree/bindings/iio/gyroscope/nxp,fxas21002c.txt deleted file mode 100644 index 465e104bbf14..000000000000 --- a/Documentation/devicetree/bindings/iio/gyroscope/nxp,fxas21002c.txt +++ /dev/null @@ -1,31 +0,0 @@ -* NXP FXAS21002C Gyroscope device tree bindings - -http://www.nxp.com/products/sensors/gyroscopes/3-axis-digital-gyroscope:FXAS21002C - -Required properties: - - compatible : should be "nxp,fxas21002c" - - reg : the I2C address of the sensor or SPI chip select number for the - device. - - vdd-supply: phandle to the regulator that provides power to the sensor. - - vddio-supply: phandle to the regulator that provides power to the bus. - -Optional properties: - - reset-gpios : gpio used to reset the device, see gpio/gpio.txt - - interrupts : device support 2 interrupts, INT1 and INT2, - the interrupts can be triggered on rising or falling edges. - See interrupt-controller/interrupts.txt - - interrupt-names: should contain "INT1" or "INT2", the gyroscope interrupt - line in use. - - drive-open-drain: the interrupt/data ready line will be configured - as open drain, which is useful if several sensors share - the same interrupt line. This is a boolean property. - (This binding is taken from pinctrl/pinctrl-bindings.txt) - -Example: - -gyroscope@20 { - compatible = "nxp,fxas21002c"; - reg = <0x20>; - vdd-supply = <®_peri_3p15v>; - vddio-supply = <®_peri_3p15v>; -}; diff --git a/Documentation/devicetree/bindings/iio/gyroscope/nxp,fxas21002c.yaml b/Documentation/devicetree/bindings/iio/gyroscope/nxp,fxas21002c.yaml new file mode 100644 index 000000000000..d97ee774d6a6 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/gyroscope/nxp,fxas21002c.yaml @@ -0,0 +1,95 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/gyroscope/nxp,fxas21002c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP FXAS21002C Gyroscope + +maintainers: + - Rui Miguel Silva + +description: | + 3 axis digital gyroscope device with an I2C and SPI interface. + http://www.nxp.com/products/sensors/gyroscopes/3-axis-digital-gyroscope:FXAS21002C + +properties: + compatible: + const: nxp,fxas21002c + + reg: + maxItems: 1 + + vdd-supply: + description: Regulator that provides power to the sensor + + vddio-supply: + description: Regulator that provides power to the bus + + reset-gpios: + maxItems: 1 + description: GPIO connected to reset + + interrupts: + minItems: 1 + maxItems: 2 + description: Either interrupt may be triggered on rising or falling edges. + + interrupt-names: + minItems: 1 + maxItems: 2 + items: + enum: + - INT1 + - INT2 + + drive-open-drain: + type: boolean + description: the interrupt/data ready line will be configured as open drain, + which is useful if several sensors share the same interrupt + line. + + spi-max-frequency: + maximum: 2000000 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include + + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + + gyroscope@20 { + compatible = "nxp,fxas21002c"; + reg = <0x20>; + + vdd-supply = <®_peri_3p15v>; + vddio-supply = <®_peri_3p15v>; + + interrupt-parent = <&gpio1>; + interrupts = <7 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "INT1"; + }; + }; + spi0 { + #address-cells = <1>; + #size-cells = <0>; + + gyroscope@0 { + compatible = "nxp,fxas2102c"; + reg = <0x0>; + + spi-max-frequency = <2000000>; + + interrupt-parent = <&gpio2>; + interrupts = <7 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "INT2"; + }; + }; -- cgit v1.2.3 From 675cb4ad1b9e431800bf2ffc49547ca048670257 Mon Sep 17 00:00:00 2001 From: Jonathan Cameron Date: Sun, 9 Aug 2020 12:17:47 +0100 Subject: dt-bindings: iio: adc: ti,adc084s021 yaml conversion MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Simple conversion. Added the #io-channel-cells optional property to allow for consumer bindings if appropriate on a given board. Signed-off-by: Jonathan Cameron Reviewed-by: Rob Herring Cc: Mårten Lindahl Link: https://lore.kernel.org/r/20200809111753.156236-8-jic23@kernel.org --- .../devicetree/bindings/iio/adc/ti,adc084s021.yaml | 58 ++++++++++++++++++++++ .../devicetree/bindings/iio/adc/ti-adc084s021.txt | 19 ------- 2 files changed, 58 insertions(+), 19 deletions(-) create mode 100644 Documentation/devicetree/bindings/iio/adc/ti,adc084s021.yaml delete mode 100644 Documentation/devicetree/bindings/iio/adc/ti-adc084s021.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/adc/ti,adc084s021.yaml b/Documentation/devicetree/bindings/iio/adc/ti,adc084s021.yaml new file mode 100644 index 000000000000..1a113b30a414 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/ti,adc084s021.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/adc/ti,adc084s021.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments ADC084S021 ADC + +maintainers: + - Mårten Lindahl + +description: | + 8 bit ADC with 4 channels + +properties: + compatible: + const: ti,adc084s021 + + reg: + maxItems: 1 + + spi-max-frequency: true + + vref-supply: + description: External reference, needed to establish input scaling + + spi-cpol: true + spi-cpha: true + + "#io-channel-cells": + const: 1 + +required: + - compatible + - reg + - vref-supply + - spi-cpol + - spi-cpha + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + adc@0 { + compatible = "ti,adc084s021"; + reg = <0>; + vref-supply = <&adc_vref>; + spi-cpol; + spi-cpha; + spi-max-frequency = <16000000>; + #io-channel-cells = <1>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/adc/ti-adc084s021.txt b/Documentation/devicetree/bindings/iio/adc/ti-adc084s021.txt deleted file mode 100644 index 4259e50620bc..000000000000 --- a/Documentation/devicetree/bindings/iio/adc/ti-adc084s021.txt +++ /dev/null @@ -1,19 +0,0 @@ -* Texas Instruments' ADC084S021 - -Required properties: - - compatible : Must be "ti,adc084s021" - - reg : SPI chip select number for the device - - vref-supply : The regulator supply for ADC reference voltage - - spi-cpol : Per spi-bus bindings - - spi-cpha : Per spi-bus bindings - - spi-max-frequency : Per spi-bus bindings - -Example: -adc@0 { - compatible = "ti,adc084s021"; - reg = <0>; - vref-supply = <&adc_vref>; - spi-cpol; - spi-cpha; - spi-max-frequency = <16000000>; -}; -- cgit v1.2.3 From 7c685a0f809b0ccbc9201ff4395a716db4e43797 Mon Sep 17 00:00:00 2001 From: Oleksij Rempel Date: Thu, 22 Oct 2020 12:27:31 +0200 Subject: dt-bindings: vendor-prefixes: Add an entry for Van der Laan b.v. Add "vdl" entry for Van der Laan b.v.: https://www.teamvdl.nl/ Signed-off-by: Oleksij Rempel Acked-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 6f138271f003..31897f127b47 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -1148,6 +1148,8 @@ patternProperties: description: Vamrs Ltd. "^variscite,.*": description: Variscite Ltd. + "^vdl,.*": + description: Van der Laan b.v. "^via,.*": description: VIA Technologies, Inc. "^videostrong,.*": -- cgit v1.2.3 From bb2bd7c7f3d0946acc2104db31df228d10f7b598 Mon Sep 17 00:00:00 2001 From: Peter Ujfalusi Date: Tue, 20 Oct 2020 10:32:42 +0300 Subject: dt-bindings: irqchip: ti, sci-inta: Update for unmapped event handling The new DMA architecture introduced with AM64 introduced new event types: unampped events. These events are mapped within INTA in contrast to other K3 devices where the events with similar function was originating from the UDMAP or ringacc. The ti,unmapped-event-sources should contain phandle array to the devices in the system (typically DMA controllers) from where the unmapped events originate. Signed-off-by: Peter Ujfalusi Signed-off-by: Marc Zyngier Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20201020073243.19255-2-peter.ujfalusi@ti.com --- .../devicetree/bindings/interrupt-controller/ti,sci-inta.yaml | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml index c7cd05656a3e..cc795498488f 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml @@ -32,6 +32,11 @@ description: | | | vint | bit | | 0 |.....|63| vintx | | +--------------+ +------------+ | | | + | Unmap | + | +--------------+ | + Unmapped events ----->| | umapidx |-------------------------> Globalevents + | +--------------+ | + | | +-----------------------------------------+ Configuration of these Intmap registers that maps global events to vint is @@ -70,6 +75,11 @@ properties: - description: | "limit" specifies the limit for translation + ti,unmapped-event-sources: + $ref: /schemas/types.yaml#definitions/phandle-array + description: + Array of phandles to DMA controllers where the unmapped events originate. + required: - compatible - reg -- cgit v1.2.3 From d9b5665fb3c822730857ba9119ead8b5e5ff967d Mon Sep 17 00:00:00 2001 From: Vasily Gorbik Date: Fri, 23 Oct 2020 13:57:32 +0200 Subject: kbuild: remove unused OBJSIZE The "size" tool has been solely used by s390 to enforce .bss section usage restrictions in early startup code. Since commit 980d5f9ab36b ("s390/boot: enable .bss section for compressed kernel") and commit 2e83e0eb85ca ("s390: clean .bss before running uncompressed kernel") these restrictions have been lifted for the decompressor and uncompressed kernel and the size tool is now unused. Signed-off-by: Vasily Gorbik Reviewed-by: Nathan Chancellor Signed-off-by: Masahiro Yamada --- Documentation/kbuild/llvm.rst | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kbuild/llvm.rst b/Documentation/kbuild/llvm.rst index cf3ca236d2cc..21c847890d03 100644 --- a/Documentation/kbuild/llvm.rst +++ b/Documentation/kbuild/llvm.rst @@ -57,9 +57,8 @@ to enable them. :: They can be enabled individually. The full list of the parameters: :: make CC=clang LD=ld.lld AR=llvm-ar NM=llvm-nm STRIP=llvm-strip \ - OBJCOPY=llvm-objcopy OBJDUMP=llvm-objdump OBJSIZE=llvm-size \ - READELF=llvm-readelf HOSTCC=clang HOSTCXX=clang++ HOSTAR=llvm-ar \ - HOSTLD=ld.lld + OBJCOPY=llvm-objcopy OBJDUMP=llvm-objdump READELF=llvm-readelf \ + HOSTCC=clang HOSTCXX=clang++ HOSTAR=llvm-ar HOSTLD=ld.lld Currently, the integrated assembler is disabled by default. You can pass ``LLVM_IAS=1`` to enable it. -- cgit v1.2.3 From 5649789d9706e864b9a2af2c057da5b1706ff3a0 Mon Sep 17 00:00:00 2001 From: Eugeniu Rosca Date: Fri, 30 Oct 2020 09:30:51 +0100 Subject: dt-bindings: arm: renesas: Add R-Car M3-W+ ULCB with Kingfisher Document the use of the Kingfisher expansion board with the R-Car Starter Kit Pro equipped with an R-Car M3-W+ (aka M3-ES3.0) SoC. Inspired from v5.5 commit 24169f0a453754 ("dt-bindings: arm: renesas: Add R-Car M3-N ULCB with Kingfisher"). Suggested-by: Geert Uytterhoeven Signed-off-by: Eugeniu Rosca Link: https://lore.kernel.org/r/20201030083051.18752-4-erosca@de.adit-jv.com Signed-off-by: Geert Uytterhoeven --- Documentation/devicetree/bindings/arm/renesas.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/renesas.yaml b/Documentation/devicetree/bindings/arm/renesas.yaml index 01a6d0c571ad..1dd165bece72 100644 --- a/Documentation/devicetree/bindings/arm/renesas.yaml +++ b/Documentation/devicetree/bindings/arm/renesas.yaml @@ -245,6 +245,7 @@ properties: - enum: - renesas,r8a7795 - renesas,r8a7796 + - renesas,r8a77961 - renesas,r8a77965 - description: R-Car M3-N (R8A77965) -- cgit v1.2.3 From ddc36a2da5c88579e58361a222064264efd64f02 Mon Sep 17 00:00:00 2001 From: Matteo Scordino Date: Fri, 30 Oct 2020 23:43:20 +0000 Subject: dt-bindings: vendors: add Elimo Engineering vendor prefix Add elimo as vendor prefix for dt bindings, since we are adding a dtsi for a SoM and a dts for an SBC Signed-off-by: Matteo Scordino Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20201030234325.5865-2-matteo.scordino@gmail.com --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 2735be1a8470..b877a3516277 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -319,6 +319,8 @@ patternProperties: description: Elgin S/A. "^elida,.*": description: Shenzhen Elida Technology Co., Ltd. + "^elimo,.*": + description: Elimo Engineering Ltd. "^embest,.*": description: Shenzhen Embest Technology Co., Ltd. "^emlid,.*": -- cgit v1.2.3 From 92ca318e11d76562bb9448295a4fd96b6580954f Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 2 Nov 2020 11:32:12 +0100 Subject: docs: ABI: sysfs-driver-dma-ioatdma: what starts with /sys This is the only file where the /sys doesn't start with a /. So, rename them to: sys -> /sys Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/f4c53fff9696a61ff0e144fee237a9527982626d.1604312590.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/stable/sysfs-driver-dma-ioatdma | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/stable/sysfs-driver-dma-ioatdma b/Documentation/ABI/stable/sysfs-driver-dma-ioatdma index 420c1d09e42f..3a4e2cd0ddcc 100644 --- a/Documentation/ABI/stable/sysfs-driver-dma-ioatdma +++ b/Documentation/ABI/stable/sysfs-driver-dma-ioatdma @@ -1,29 +1,29 @@ -What: sys/devices/pciXXXX:XX/0000:XX:XX.X/dma/dmachan/quickdata/cap +What: /sys/devices/pciXXXX:XX/0000:XX:XX.X/dma/dmachan/quickdata/cap Date: December 3, 2009 KernelVersion: 2.6.32 Contact: dmaengine@vger.kernel.org Description: Capabilities the DMA supports.Currently there are DMA_PQ, DMA_PQ_VAL, DMA_XOR,DMA_XOR_VAL,DMA_INTERRUPT. -What: sys/devices/pciXXXX:XX/0000:XX:XX.X/dma/dmachan/quickdata/ring_active +What: /sys/devices/pciXXXX:XX/0000:XX:XX.X/dma/dmachan/quickdata/ring_active Date: December 3, 2009 KernelVersion: 2.6.32 Contact: dmaengine@vger.kernel.org Description: The number of descriptors active in the ring. -What: sys/devices/pciXXXX:XX/0000:XX:XX.X/dma/dmachan/quickdata/ring_size +What: /sys/devices/pciXXXX:XX/0000:XX:XX.X/dma/dmachan/quickdata/ring_size Date: December 3, 2009 KernelVersion: 2.6.32 Contact: dmaengine@vger.kernel.org Description: Descriptor ring size, total number of descriptors available. -What: sys/devices/pciXXXX:XX/0000:XX:XX.X/dma/dmachan/quickdata/version +What: /sys/devices/pciXXXX:XX/0000:XX:XX.X/dma/dmachan/quickdata/version Date: December 3, 2009 KernelVersion: 2.6.32 Contact: dmaengine@vger.kernel.org Description: Version of ioatdma device. -What: sys/devices/pciXXXX:XX/0000:XX:XX.X/dma/dmachan/quickdata/intr_coalesce +What: /sys/devices/pciXXXX:XX/0000:XX:XX.X/dma/dmachan/quickdata/intr_coalesce Date: August 8, 2017 KernelVersion: 4.14 Contact: dmaengine@vger.kernel.org -- cgit v1.2.3 From 1088ee2230ac5e1c889d5ba020f37c09000ee3af Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 2 Nov 2020 11:32:13 +0100 Subject: docs: ABI: sysfs-class-net: fix a typo clas->class Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/4bba2a1592df5a9435c8d4757a9abf20246e2a99.1604312590.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-class-net | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-class-net b/Documentation/ABI/testing/sysfs-class-net index 7670012ae9b6..1f2002df5ba2 100644 --- a/Documentation/ABI/testing/sysfs-class-net +++ b/Documentation/ABI/testing/sysfs-class-net @@ -152,7 +152,7 @@ Description: When an interface is under test, it cannot be expected to pass packets as normal. -What: /sys/clas/net//duplex +What: /sys/class/net//duplex Date: October 2009 KernelVersion: 2.6.33 Contact: netdev@vger.kernel.org -- cgit v1.2.3 From e186d80e2b85ab3e69de941d069ab9e11018ddf4 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 2 Nov 2020 11:32:14 +0100 Subject: docs: leds: index.rst: add a missing file Changeset 26a07553041e ("docs: ABI: sysfs-class-led-trigger-pattern: remove hw_pattern duplication") didn't include the needed changes at index.rst. Fixes: 26a07553041e ("docs: ABI: sysfs-class-led-trigger-pattern: remove hw_pattern duplication") Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/36a6e3aef6e57ea349f1b47c7731d4cd1e03ca77.1604312590.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman --- Documentation/leds/index.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/leds/index.rst b/Documentation/leds/index.rst index 53e6090454af..e5d63b940045 100644 --- a/Documentation/leds/index.rst +++ b/Documentation/leds/index.rst @@ -25,3 +25,4 @@ LEDs leds-lp5562 leds-lp55xx leds-mlxcpld + leds-sc27xx -- cgit v1.2.3 From ee19f644c4594d1b8382f1538c19396f92c3c171 Mon Sep 17 00:00:00 2001 From: Lubomir Rintel Date: Sat, 26 Sep 2020 01:58:27 +0200 Subject: dt-bindings: phy: Drop reset-gpios from marvell,mmp3-hsic-phy This has been added in error -- the PHY block doesn't have a reset pin. Signed-off-by: Lubomir Rintel Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20200925235828.228626-2-lkundrak@v3.sk Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml | 7 ------- 1 file changed, 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml b/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml index 00609ace677c..30e290c57930 100644 --- a/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml +++ b/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml @@ -18,27 +18,20 @@ properties: maxItems: 1 description: base address of the device - reset-gpios: - maxItems: 1 - description: GPIO connected to reset - "#phy-cells": const: 0 required: - compatible - reg - - reset-gpios - "#phy-cells" additionalProperties: false examples: - | - #include hsic-phy@f0001800 { compatible = "marvell,mmp3-hsic-phy"; reg = <0xf0001800 0x40>; - reset-gpios = <&gpio 63 GPIO_ACTIVE_HIGH>; #phy-cells = <0>; }; -- cgit v1.2.3 From a1b87f1aac4dba2bac0e0019a9c05f7efa36c37d Mon Sep 17 00:00:00 2001 From: Lubomir Rintel Date: Sat, 26 Sep 2020 01:58:28 +0200 Subject: dt-bindings: phy: Allow BSD licensing of marvell,mmp3-hsic-phy.yaml I wrote this binding and I'm fine with it being GPL + BSD dual-licensed, as is recommended for new DT bindings. Signed-off-by: Lubomir Rintel Acked-by: Rob Herring Link: https://lore.kernel.org/r/20200925235828.228626-3-lkundrak@v3.sk Signed-off-by: Vinod Koul --- Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml b/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml index 30e290c57930..ff255aa4cc10 100644 --- a/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml +++ b/Documentation/devicetree/bindings/phy/marvell,mmp3-hsic-phy.yaml @@ -1,4 +1,4 @@ -# SPDX-License-Identifier: GPL-2.0-or-later +# SPDX-License-Identifier: (GPL-2.0-or-later OR BSD-2-Clause) # Copyright 2019 Lubomir Rintel %YAML 1.2 --- -- cgit v1.2.3 From fa67f2817ff2c9bb07472d30e58d904922f1a538 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= Date: Wed, 14 Oct 2020 22:00:29 +0200 Subject: dt-bindings: vendor-prefixes: Add kobol prefix MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The prefix is already used in arm/armada-388-helios4.dts. Signed-off-by: Uwe Kleine-König Acked-by: Rob Herring Link: https://lore.kernel.org/r/20201014200030.845759-2-uwe@kleine-koenig.org Signed-off-by: Heiko Stuebner --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 2735be1a8470..259faf1b382c 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -553,6 +553,8 @@ patternProperties: description: Kionix, Inc. "^kobo,.*": description: Rakuten Kobo Inc. + "^kobol,.*": + description: Kobol Innovations Pte. Ltd. "^koe,.*": description: Kaohsiung Opto-Electronics Inc. "^kontron,.*": -- cgit v1.2.3 From 6841ca15fe13038b9d27f8e7168700e1427b7a72 Mon Sep 17 00:00:00 2001 From: Julia Lawall Date: Sat, 31 Oct 2020 10:39:28 +0100 Subject: Documentation: PM: cpuidle: correct typo cerainly -> certainly Signed-off-by: Julia Lawall Signed-off-by: Rafael J. Wysocki --- Documentation/admin-guide/pm/cpuidle.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/pm/cpuidle.rst b/Documentation/admin-guide/pm/cpuidle.rst index 37940a0584ec..a26a94bc0071 100644 --- a/Documentation/admin-guide/pm/cpuidle.rst +++ b/Documentation/admin-guide/pm/cpuidle.rst @@ -494,7 +494,7 @@ object corresponding to it, as follows: residency. ``below`` - Total number of times this idle state had been asked for, but cerainly + Total number of times this idle state had been asked for, but certainly a deeper idle state would have been a better match for the observed idle duration. -- cgit v1.2.3 From 23d18dcfc5275fbd53a515a4a1cf946b22fe7463 Mon Sep 17 00:00:00 2001 From: Julia Lawall Date: Sat, 31 Oct 2020 10:39:39 +0100 Subject: Documentation: PM: cpuidle: correct path name cpu/ is needed before cpu/ Signed-off-by: Julia Lawall Signed-off-by: Rafael J. Wysocki --- Documentation/admin-guide/pm/cpuidle.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/pm/cpuidle.rst b/Documentation/admin-guide/pm/cpuidle.rst index a26a94bc0071..10fde58d0869 100644 --- a/Documentation/admin-guide/pm/cpuidle.rst +++ b/Documentation/admin-guide/pm/cpuidle.rst @@ -478,7 +478,7 @@ order to ask the hardware to enter that state. Also, for each statistics of the given idle state. That information is exposed by the kernel via ``sysfs``. -For each CPU in the system, there is a :file:`/sys/devices/system/cpu/cpuidle/` +For each CPU in the system, there is a :file:`/sys/devices/system/cpu/cpu/cpuidle/` directory in ``sysfs``, where the number ```` is assigned to the given CPU at the initialization time. That directory contains a set of subdirectories called :file:`state0`, :file:`state1` and so on, up to the number of idle state -- cgit v1.2.3 From 9ce86dc474168020a2097cc806fc5f9454859ab8 Mon Sep 17 00:00:00 2001 From: Ivan Mikhaylov Date: Fri, 30 Oct 2020 16:37:07 +0300 Subject: dt-bindings: net: ftgmac100: describe phy-handle and MDIO Add the phy-handle and MDIO description and add the example with PHY and MDIO nodes. Signed-off-by: Ivan Mikhaylov Reviewed-by: Andrew Lunn Signed-off-by: Jakub Kicinski --- .../devicetree/bindings/net/ftgmac100.txt | 25 ++++++++++++++++++++++ 1 file changed, 25 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/ftgmac100.txt b/Documentation/devicetree/bindings/net/ftgmac100.txt index f878c1103463..29234021f601 100644 --- a/Documentation/devicetree/bindings/net/ftgmac100.txt +++ b/Documentation/devicetree/bindings/net/ftgmac100.txt @@ -15,6 +15,7 @@ Required properties: - interrupts: Should contain ethernet controller interrupt Optional properties: +- phy-handle: See ethernet.txt file in the same directory. - phy-mode: See ethernet.txt file in the same directory. If the property is absent, "rgmii" is assumed. Supported values are "rgmii*" and "rmii" for aspeed parts. Other (unknown) parts will accept any value. @@ -32,6 +33,9 @@ Optional properties: - "MACCLK": The MAC IP clock - "RCLK": Clock gate for the RMII RCLK +Optional subnodes: +- mdio: See mdio.txt file in the same directory. + Example: mac0: ethernet@1e660000 { @@ -40,3 +44,24 @@ Example: interrupts = <2>; use-ncsi; }; + +Example with phy-handle: + + mac1: ethernet@1e680000 { + compatible = "aspeed,ast2500-mac", "faraday,ftgmac100"; + reg = <0x1e680000 0x180>; + interrupts = <2>; + + phy-handle = <&phy>; + phy-mode = "rgmii"; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + phy: ethernet-phy@1 { + compatible = "ethernet-phy-ieee802.3-c22"; + reg = <1>; + }; + }; + }; -- cgit v1.2.3 From fa43c3de5c37f315271662bbc8cd6e110280abee Mon Sep 17 00:00:00 2001 From: Meenakshi Aggarwal Date: Mon, 2 Nov 2020 11:29:40 +0530 Subject: dt-bindings: fsl: add compatible for LX2162A QDS Board Add support for LX2162A, LX2162A is LX2160A based SoC. Signed-off-by: Meenakshi Aggarwal Acked-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 417b5634d3f1..85fb24da4a02 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -892,6 +892,7 @@ properties: - enum: - fsl,lx2160a-qds - fsl,lx2160a-rdb + - fsl,lx2162a-qds - const: fsl,lx2160a - description: S32V234 based Boards -- cgit v1.2.3 From 0dbcd49917191c599e33725268892f9a4f006154 Mon Sep 17 00:00:00 2001 From: Ioana Ciornei Date: Fri, 30 Oct 2020 13:35:45 +0200 Subject: dt-bindings: net: add the DPAA2 MAC DTS definition Add a documentation entry for the DTS bindings needed and supported by the dpaa2-mac driver. Signed-off-by: Ioana Ciornei Reviewed-by: Rob Herring Signed-off-by: Shawn Guo --- .../bindings/net/fsl,qoriq-mc-dpmac.yaml | 60 ++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/fsl,qoriq-mc-dpmac.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/fsl,qoriq-mc-dpmac.yaml b/Documentation/devicetree/bindings/net/fsl,qoriq-mc-dpmac.yaml new file mode 100644 index 000000000000..2159b7d1f537 --- /dev/null +++ b/Documentation/devicetree/bindings/net/fsl,qoriq-mc-dpmac.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/fsl,qoriq-mc-dpmac.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: DPAA2 MAC bindings + +maintainers: + - Ioana Ciornei + +description: + This binding represents the DPAA2 MAC objects found on the fsl-mc bus and + located under the 'dpmacs' node for the fsl-mc bus DTS node. + +allOf: + - $ref: "ethernet-controller.yaml#" + +properties: + compatible: + const: fsl,qoriq-mc-dpmac + + reg: + maxItems: 1 + description: The DPMAC number + + phy-handle: true + + phy-connection-type: true + + phy-mode: true + + pcs-handle: + $ref: /schemas/types.yaml#definitions/phandle + description: + A reference to a node representing a PCS PHY device found on + the internal MDIO bus. + + managed: true + +required: + - reg + +additionalProperties: false + +examples: + - | + dpmacs { + #address-cells = <1>; + #size-cells = <0>; + + ethernet@4 { + compatible = "fsl,qoriq-mc-dpmac"; + reg = <0x4>; + phy-handle = <&mdio1_phy6>; + phy-connection-type = "qsgmii"; + managed = "in-band-status"; + pcs-handle = <&pcs3_1>; + }; + }; -- cgit v1.2.3 From 39d3f3ffe79eb2ee2a93353113923eb837d92458 Mon Sep 17 00:00:00 2001 From: Ioana Ciornei Date: Fri, 30 Oct 2020 13:35:46 +0200 Subject: dt-bindings: net: add the 10gbase-r connection type Add 10gbase-r to the list of accepted PHY connection types between an Ethernet device and a physical PHY. This is available as a valid connection type since commit c114574ebfdf ("net: phy: add PHY_INTERFACE_MODE_10GBASER") Signed-off-by: Ioana Ciornei Acked-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/net/ethernet-controller.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml index fdf709817218..cc93063a8f39 100644 --- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml @@ -95,6 +95,7 @@ properties: # 10GBASE-KR, XFI, SFI - 10gbase-kr - usxgmii + - 10gbase-r phy-mode: $ref: "#/properties/phy-connection-type" -- cgit v1.2.3 From 86b5a7381b12b1d1d5558d8087e5bbd04b7cf702 Mon Sep 17 00:00:00 2001 From: "Paul E. McKenney" Date: Thu, 24 Sep 2020 20:53:25 -0700 Subject: doc: Present the role of READ_ONCE() This commit adds an explanation of the special cases where READ_ONCE() may be used in place of a member of the rcu_dereference() family. Signed-off-by: Paul E. McKenney --- Documentation/RCU/checklist.rst | 7 +++++++ Documentation/RCU/rcu_dereference.rst | 6 ++++++ 2 files changed, 13 insertions(+) (limited to 'Documentation') diff --git a/Documentation/RCU/checklist.rst b/Documentation/RCU/checklist.rst index 2efed9926c3f..bb7128eb322e 100644 --- a/Documentation/RCU/checklist.rst +++ b/Documentation/RCU/checklist.rst @@ -314,6 +314,13 @@ over a rather long period of time, but improvements are always welcome! shared between readers and updaters. Additional primitives are provided for this case, as discussed in lockdep.txt. + One exception to this rule is when data is only ever added to + the linked data structure, and is never removed during any + time that readers might be accessing that structure. In such + cases, READ_ONCE() may be used in place of rcu_dereference() + and the read-side markers (rcu_read_lock() and rcu_read_unlock(), + for example) may be omitted. + 10. Conversely, if you are in an RCU read-side critical section, and you don't hold the appropriate update-side lock, you -must- use the "_rcu()" variants of the list macros. Failing to do so diff --git a/Documentation/RCU/rcu_dereference.rst b/Documentation/RCU/rcu_dereference.rst index c9667eb0d444..f3e587acb4de 100644 --- a/Documentation/RCU/rcu_dereference.rst +++ b/Documentation/RCU/rcu_dereference.rst @@ -28,6 +28,12 @@ Follow these rules to keep your RCU code working properly: for an example where the compiler can in fact deduce the exact value of the pointer, and thus cause misordering. +- In the special case where data is added but is never removed + while readers are accessing the structure, READ_ONCE() may be used + instead of rcu_dereference(). In this case, use of READ_ONCE() + takes on the role of the lockless_dereference() primitive that + was removed in v4.15. + - You are only permitted to use rcu_dereference on pointer values. The compiler simply knows too much about integral values to trust it to carry dependencies through integer operations. -- cgit v1.2.3 From 5b09081f4c5c7159cb3789f35bb82bd9d32061c9 Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Thu, 29 Oct 2020 10:31:23 +0100 Subject: docs: ABI: sysfs-class-firmware-attributes: solve some warnings The Description: tag is missing on some places, causing scripts/get_abi.pl warnings: Warning: file Documentation/ABI/testing/sysfs-class-firmware-attributes#172: What '/sys/class/firmware-attributes/*/authentication/' doesn't have a description Also, some warnings are produced when generating html documentation: .../Documentation/ABI/testing/sysfs-class-firmware-attributes:2: WARNING: Title underline too short. Dell specific class extensions -------------------------- .../Documentation/ABI/testing/sysfs-class-firmware-attributes:2: WARNING: Unexpected indentation. .../Documentation/ABI/testing/sysfs-class-firmware-attributes:2: WARNING: Unexpected indentation. .../Documentation/ABI/testing/sysfs-class-firmware-attributes:2: WARNING: Block quote ends without a blank line; unexpected unindent. .../Documentation/ABI/testing/sysfs-class-firmware-attributes:173: WARNING: Unexpected indentation. .../Documentation/ABI/testing/sysfs-class-firmware-attributes:173: WARNING: Unexpected indentation. .../Documentation/ABI/testing/sysfs-class-firmware-attributes:173: WARNING: Block quote ends without a blank line; unexpected unindent. .../Documentation/ABI/testing/sysfs-class-firmware-attributes:111: WARNING: Inline emphasis start-string without end-string. Address the warnings, making it to produce the expected output for the documentation ABI. Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/44b4181b4f772fcc5ec676e72b295c10df35121b.1603963862.git.mchehab+huawei@kernel.org Signed-off-by: Hans de Goede --- .../ABI/testing/sysfs-class-firmware-attributes | 140 +++++++++++++-------- 1 file changed, 87 insertions(+), 53 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-class-firmware-attributes b/Documentation/ABI/testing/sysfs-class-firmware-attributes index 04a15c72e883..8ea59fea4709 100644 --- a/Documentation/ABI/testing/sysfs-class-firmware-attributes +++ b/Documentation/ABI/testing/sysfs-class-firmware-attributes @@ -12,17 +12,20 @@ Description: Unless otherwise specified in an attribute description all attributes are optional and will accept UTF-8 input. - type: A file that can be read to obtain the type of attribute. This attribute is - mandatory. + type: + A file that can be read to obtain the type of attribute. + This attribute is mandatory. The following are known types: + - enumeration: a set of pre-defined valid values - integer: a range of numerical values - string All attribute types support the following values: - current_value: A file that can be read to obtain the current + current_value: + A file that can be read to obtain the current value of the . This file can also be written to in order to update the value of a @@ -30,59 +33,71 @@ Description: This attribute is mandatory. - default_value: A file that can be read to obtain the default + default_value: + A file that can be read to obtain the default value of the - display_name: A file that can be read to obtain a user friendly + display_name: + A file that can be read to obtain a user friendly description of the at - display_name_language_code: A file that can be read to obtain + display_name_language_code: + A file that can be read to obtain the IETF language tag corresponding to the "display_name" of the "enumeration"-type specific properties: - possible_values: A file that can be read to obtain the possible + possible_values: + A file that can be read to obtain the possible values of the . Values are separated using semi-colon (``;``). "integer"-type specific properties: - min_value: A file that can be read to obtain the lower + min_value: + A file that can be read to obtain the lower bound value of the - max_value: A file that can be read to obtain the upper + max_value: + A file that can be read to obtain the upper bound value of the - scalar_increment: A file that can be read to obtain the scalar value used for + scalar_increment: + A file that can be read to obtain the scalar value used for increments of current_value this attribute accepts. "string"-type specific properties: - max_length: A file that can be read to obtain the maximum + max_length: + A file that can be read to obtain the maximum length value of the - min_length: A file that can be read to obtain the minimum + min_length: + A file that can be read to obtain the minimum length value of the Dell specific class extensions - -------------------------- + ------------------------------ On Dell systems the following additional attributes are available: - dell_modifier: A file that can be read to obtain attribute-level + dell_modifier: + A file that can be read to obtain attribute-level dependency rule. It says an attribute X will become read-only or suppressed, if/if-not attribute Y is configured. - modifier rules can be in following format: - [ReadOnlyIf:=] - [ReadOnlyIfNot:=] - [SuppressIf:=] - [SuppressIfNot:=] + modifier rules can be in following format:: + + [ReadOnlyIf:=] + [ReadOnlyIfNot:=] + [SuppressIf:=] + [SuppressIfNot:=] - For example: - AutoOnFri/dell_modifier has value, - [SuppressIfNot:AutoOn=SelectDays] + For example:: + + AutoOnFri/dell_modifier has value, + [SuppressIfNot:AutoOn=SelectDays] This means AutoOnFri will be suppressed in BIOS setup if AutoOn attribute is not "SelectDays" and its value will not be effective @@ -90,18 +105,22 @@ Description: Enumeration attributes also support the following: - dell_value_modifier: A file that can be read to obtain value-level dependency. + dell_value_modifier: + A file that can be read to obtain value-level dependency. This file is similar to dell_modifier but here, an attribute's current value will be forcefully changed based dependent attributes value. - dell_value_modifier rules can be in following format: - [ForceIf:=] - [ForceIfNot:=] + dell_value_modifier rules can be in following format:: + + [ForceIf:=] + [ForceIfNot:=] + + For example: + + LegacyOrom/dell_value_modifier has value: + Disabled[ForceIf:SecureBoot=Enabled] - For example, - LegacyOrom/dell_value_modifier has value: - Disabled[ForceIf:SecureBoot=Enabled] This means LegacyOrom's current value will be forced to "Disabled" in BIOS setup if SecureBoot is Enabled and its value will not be effective through sysfs until this rule is @@ -113,12 +132,13 @@ KernelVersion: 5.11 Contact: Divya Bharathi , Mario Limonciello , Prasanth KSR - +Description: Devices support various authentication mechanisms which can be exposed as a separate configuration object. For example a "BIOS Admin" password and "System" Password can be set, reset or cleared using these attributes. + - An "Admin" password is used for preventing modification to the BIOS settings. - A "System" password is required to boot a machine. @@ -126,39 +146,50 @@ Contact: Divya Bharathi , Change in any of these two authentication methods will also generate an uevent KOBJ_CHANGE. - is_enabled: A file that can be read to obtain a 0/1 flag to see if + is_enabled: + A file that can be read to obtain a 0/1 flag to see if authentication is enabled. This attribute is mandatory. - role: The type of authentication used. + role: + The type of authentication used. This attribute is mandatory. - Known types: - bios-admin: Representing BIOS administrator password - power-on: Representing a password required to use - the system - mechanism: The means of authentication. This attribute is mandatory. + Known types: + bios-admin: + Representing BIOS administrator password + power-on: + Representing a password required to use + the system + + mechanism: + The means of authentication. This attribute is mandatory. Only supported type currently is "password". - max_password_length: A file that can be read to obtain the + max_password_length: + A file that can be read to obtain the maximum length of the Password - min_password_length: A file that can be read to obtain the + min_password_length: + A file that can be read to obtain the minimum length of the Password - current_password: A write only value used for privileged access such as + current_password: + A write only value used for privileged access such as setting attributes when a system or admin password is set or resetting to a new password This attribute is mandatory when mechanism == "password". - new_password: A write only value that when used in tandem with + new_password: + A write only value that when used in tandem with current_password will reset a system or admin password. Note, password management is session specific. If Admin password is set, same password must be written into current_password file (required for password-validation) and must be cleared once the session is over. - For example: + For example:: + echo "password" > current_password echo "disabled" > TouchScreen/current_value echo "" > current_password @@ -180,12 +211,15 @@ Description: pending BIOS attribute changes. Also, an uevent_KOBJ_CHANGE is generated when it changes to 1. - 0: All BIOS attributes setting are current - 1: A reboot is necessary to get pending BIOS attribute changes - applied + == ========================================= + 0 All BIOS attributes setting are current + 1 A reboot is necessary to get pending BIOS + attribute changes applied + == ========================================= Note, userspace applications need to follow below steps for efficient BIOS management, + 1. Check if admin password is set. If yes, follow session method for password management as briefed under authentication section above. 2. Before setting any attribute, check if it has any modifiers @@ -208,17 +242,17 @@ Description: Reading from it returns a list of supported options encoded as: - 'builtinsafe' (Built in safe configuration profile) - 'lastknowngood' (Last known good saved configuration profile) - 'factory' (Default factory settings configuration profile) - 'custom' (Custom saved configuration profile) + - 'builtinsafe' (Built in safe configuration profile) + - 'lastknowngood' (Last known good saved configuration profile) + - 'factory' (Default factory settings configuration profile) + - 'custom' (Custom saved configuration profile) The currently selected option is printed in square brackets as - shown below: + shown below:: - # echo "factory" > /sys/class/firmware-attributes/*/device/attributes/reset_bios - # cat /sys/class/firmware-attributes/*/device/attributes/reset_bios - # builtinsafe lastknowngood [factory] custom + # echo "factory" > /sys/class/firmware-attributes/*/device/attributes/reset_bios + # cat /sys/class/firmware-attributes/*/device/attributes/reset_bios + # builtinsafe lastknowngood [factory] custom Note that any changes to this attribute requires a reboot for changes to take effect. -- cgit v1.2.3 From 907286d1420d28bead47da37b9a081377c070322 Mon Sep 17 00:00:00 2001 From: Jiri Kosina Date: Tue, 3 Nov 2020 11:30:49 +0100 Subject: HID: SFH: Add documentation Add Documentation/hid/amd-sfh-hid.rst file which was by mistake dropped by me when applying the series. Fixes: 302f0dad8c97a11ab ("SFH: Add maintainers and documentation for AMD SFH based on HID framework") Reported-by: Lukas Bulwahn Originally-by: Sandeep Singh Signed-off-by: Jiri Kosina --- Documentation/hid/amd-sfh-hid.rst | 145 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 145 insertions(+) create mode 100644 Documentation/hid/amd-sfh-hid.rst (limited to 'Documentation') diff --git a/Documentation/hid/amd-sfh-hid.rst b/Documentation/hid/amd-sfh-hid.rst new file mode 100644 index 000000000000..1f2fe29ccd4f --- /dev/null +++ b/Documentation/hid/amd-sfh-hid.rst @@ -0,0 +1,145 @@ +.. SPDX-License-Identifier: GPL-2.0 + + +AMD Sensor Fusion Hub +===================== +AMD Sensor Fusion Hub (SFH) is part of an SOC starting from Ryzen based platforms. +The solution is working well on several OEM products. AMD SFH uses HID over PCIe bus. +In terms of architecture it resembles ISH, however the major difference is all +the HID reports are generated as part of the kernel driver. + +1. Block Diagram +================ + +:: + + --------------------------------- + | HID User Space Applications | + - ------------------------------- + + --------------------------------------------- + --------------------------------- + | HID Core | + --------------------------------- + + --------------------------------- + | AMD HID Transport | + --------------------------------- + + -------------------------------- + | AMD HID Client | + | with HID Report Generator| + -------------------------------- + + -------------------------------- + | AMD MP2 PCIe Driver | + -------------------------------- + OS + --------------------------------------------- + Hardware + Firmware + -------------------------------- + | SFH MP2 Processor | + -------------------------------- + + +AMD HID Transport Layer +----------------------- +AMD SFH transport is also implemented as a bus. Each client application executing in the AMD MP2 is +registered as a device on this bus. Here: MP2 which is an ARM core connected to x86 for processing +sensor data. The layer, which binds each device (AMD SFH HID driver) identifies the device type and +registers with the hid core. Transport layer attach a constant "struct hid_ll_driver" object with +each device. Once a device is registered with HID core, the callbacks provided via this struct are +used by HID core to communicate with the device. AMD HID Transport layer implements the synchronous calls. + +AMD HID Client Layer +-------------------- +This layer is responsible to implement HID request and descriptors. As firmware is OS agnostic, HID +client layer fills the HID request structure and descriptors. HID client layer is complex as it is +interface between MP2 PCIe layer and HID. HID client layer initialized the MP2 PCIe layer and holds +the instance of MP2 layer. It identifies the number of sensors connected using MP2-PCIe layer. Base +on that allocates the DRAM address for each and every sensor and pass it to MP2-PCIe driver.On +enumeration of each the sensor, client layer fills the HID Descriptor structure and HID input repor +structure. HID Feature report structure is optional. The report descriptor structure varies from +sensor to sensor. + +AMD MP2 PCIe layer +------------------ +MP2 PCIe Layer is responsible for making all transactions with the firmware over PCIe. +The connection establishment between firmware and PCIe happens here. + +The communication between X86 and MP2 is split into three parts. +1. Command transfer via the C2P mailbox registers. +2. Data transfer via DRAM. +3. Supported sensor info via P2C registers. + +Commands are sent to MP2 using C2P Mailbox registers. Writing into C2P Message registers generate +interrupt to MP2. The client layer allocates the physical memory and the same is sent to MP2 via +the PCI layer. MP2 firmware writes the command output to the access DRAM memory which the client +layer has allocated. Firmware always writes minimum of 32 bytes into DRAM. So as a protocol driver +shall allocate minimum of 32 bytes DRAM space. + +Enumeration and Probing flow +---------------------------- +:: + + HID AMD AMD AMD -PCIe MP2 + Core Transport Client layer layer FW + | | | | | + | | | on Boot Driver Loaded | + | | | | | + | | | MP2-PCIe Int | + | | | | | + | | |---Get Number of sensors-> | | + | | | Read P2C | + | | | Register | + | | | | | + | | | Loop(for No of Sensors) | | + | | |----------------------| | | + | | | Create HID Descriptor| | | + | | | Create Input report | | | + | | | Descriptor Map | | | + | | | the MP2 FW Index to | | | + | | | HID Index | | | + | | | Allocate the DRAM | Enable | + | | | address | Sensors | + | | |----------------------| | | + | | HID transport| | Enable | + | |<--Probe------| |---Sensor CMD--> | + | | Create the | | | + | | HID device | | | + | | (MFD) | | | + | | by Populating| | | + | | the HID | | | + | | ll_driver | | | + | HID | | | | + | add | | | | + |Device | | | | + |<------------- | | | | + + +Data Flow from Application to the AMD SFH Driver +------------------------------------------------ + +:: + + | | | | | + | | | | | + | | | | | + | | | | | + | | | | | + |HID_req | | | | + |get_report | | | | + |------------->| | | | + | | HID_get_input| | | + | | report | | | + | |------------->|------------------------| | | + | | | Read the DRAM data for| | | + | | | requested sensor and | | | + | | | create the HID input | | | + | | | report | | | + | | |------------------------| | | + | |Data received | | | + | | in HID report| | | + To |<-------------|<-------------| | | + Applications| | | | | + <-------| | | | | -- cgit v1.2.3 From 4f3e69060dc9cc8f14ad9e172ada7120dc76445b Mon Sep 17 00:00:00 2001 From: Jonathan Corbet Date: Fri, 30 Oct 2020 09:35:39 -0600 Subject: docs: fix automarkup regression on Python 2 It turns out that the Python 2 re module lacks the ASCII flag, so don't try to use it there. Fixes: f66e47f98c1e ("docs: automarkup.py: Fix regexes to solve sphinx 3 warnings") Reported-by: Dafna Hirschfeld Signed-off-by: Jonathan Corbet --- Documentation/sphinx/automarkup.py | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sphinx/automarkup.py b/Documentation/sphinx/automarkup.py index 409dbc4100de..3e81ebab26ed 100644 --- a/Documentation/sphinx/automarkup.py +++ b/Documentation/sphinx/automarkup.py @@ -15,6 +15,14 @@ else: import re from itertools import chain +# +# Python 2 lacks re.ASCII... +# +try: + ascii_p3 = re.ASCII +except AttributeError: + ascii_p3 = 0 + # # Regex nastiness. Of course. # Try to identify "function()" that's not already marked up some @@ -22,22 +30,22 @@ from itertools import chain # :c:func: block (i.e. ":c:func:`mmap()`s" flakes out), so the last # bit tries to restrict matches to things that won't create trouble. # -RE_function = re.compile(r'\b(([a-zA-Z_]\w+)\(\))', flags=re.ASCII) +RE_function = re.compile(r'\b(([a-zA-Z_]\w+)\(\))', flags=ascii_p3) # # Sphinx 2 uses the same :c:type role for struct, union, enum and typedef # RE_generic_type = re.compile(r'\b(struct|union|enum|typedef)\s+([a-zA-Z_]\w+)', - flags=re.ASCII) + flags=ascii_p3) # # Sphinx 3 uses a different C role for each one of struct, union, enum and # typedef # -RE_struct = re.compile(r'\b(struct)\s+([a-zA-Z_]\w+)', flags=re.ASCII) -RE_union = re.compile(r'\b(union)\s+([a-zA-Z_]\w+)', flags=re.ASCII) -RE_enum = re.compile(r'\b(enum)\s+([a-zA-Z_]\w+)', flags=re.ASCII) -RE_typedef = re.compile(r'\b(typedef)\s+([a-zA-Z_]\w+)', flags=re.ASCII) +RE_struct = re.compile(r'\b(struct)\s+([a-zA-Z_]\w+)', flags=ascii_p3) +RE_union = re.compile(r'\b(union)\s+([a-zA-Z_]\w+)', flags=ascii_p3) +RE_enum = re.compile(r'\b(enum)\s+([a-zA-Z_]\w+)', flags=ascii_p3) +RE_typedef = re.compile(r'\b(typedef)\s+([a-zA-Z_]\w+)', flags=ascii_p3) # # Detects a reference to a documentation page of the form Documentation/... with -- cgit v1.2.3 From 82768a86c64659c7181571ebfbc41ec9f2e52dde Mon Sep 17 00:00:00 2001 From: Peter Ujfalusi Date: Tue, 3 Nov 2020 15:50:04 +0200 Subject: dt-bindings: irqchip: ti, sci-inta: Fix diagram indentation for unmapped events One space has been missing by the diagram update. Fixes: bb2bd7c7f3d0 ("dt-bindings: irqchip: ti, sci-inta: Update for unmapped event handling") Reported-by: Rob Herring Signed-off-by: Peter Ujfalusi Signed-off-by: Thomas Gleixner Acked-by: Rob Herring Cc: Marc Zyngier Link: https://lore.kernel.org/r/20201103135004.2363-1-peter.ujfalusi@ti.com --- Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml index cc795498488f..8d90bc593c6e 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml @@ -34,7 +34,7 @@ description: | | | | Unmap | | +--------------+ | - Unmapped events ----->| | umapidx |-------------------------> Globalevents + Unmapped events ---->| | umapidx |-------------------------> Globalevents | +--------------+ | | | +-----------------------------------------+ -- cgit v1.2.3 From 1f9234401ce0aa7a05857db43c5aef290d5177e2 Mon Sep 17 00:00:00 2001 From: Oleksij Rempel Date: Thu, 22 Oct 2020 09:52:17 +0200 Subject: dt-bindings: can: add can-controller.yaml For now we have only node name as common rule for all CAN controllers Signed-off-by: Oleksij Rempel Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20201022075218.11880-2-o.rempel@pengutronix.de Signed-off-by: Marc Kleine-Budde --- .../devicetree/bindings/net/can/can-controller.yaml | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/can/can-controller.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/can/can-controller.yaml b/Documentation/devicetree/bindings/net/can/can-controller.yaml new file mode 100644 index 000000000000..9cf2ae097156 --- /dev/null +++ b/Documentation/devicetree/bindings/net/can/can-controller.yaml @@ -0,0 +1,18 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/can/can-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: CAN Controller Generic Binding + +maintainers: + - Marc Kleine-Budde + +properties: + $nodename: + pattern: "^can(@.*)?$" + +additionalProperties: true + +... -- cgit v1.2.3 From e5ab9aa7e49b39c34d110d6303b917c14a277200 Mon Sep 17 00:00:00 2001 From: Oleksij Rempel Date: Thu, 22 Oct 2020 09:52:18 +0200 Subject: dt-bindings: can: flexcan: convert fsl,*flexcan bindings to yaml In order to automate the verification of DT nodes convert fsl-flexcan.txt to fsl,flexcan.yaml Signed-off-by: Oleksij Rempel Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20201022075218.11880-3-o.rempel@pengutronix.de Signed-off-by: Marc Kleine-Budde --- .../devicetree/bindings/net/can/fsl,flexcan.yaml | 135 +++++++++++++++++++++ .../devicetree/bindings/net/can/fsl-flexcan.txt | 57 --------- 2 files changed, 135 insertions(+), 57 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml delete mode 100644 Documentation/devicetree/bindings/net/can/fsl-flexcan.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml b/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml new file mode 100644 index 000000000000..43df15ba8fa4 --- /dev/null +++ b/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml @@ -0,0 +1,135 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/can/fsl,flexcan.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: + Flexcan CAN controller on Freescale's ARM and PowerPC system-on-a-chip (SOC). + +maintainers: + - Marc Kleine-Budde + +allOf: + - $ref: can-controller.yaml# + +properties: + compatible: + oneOf: + - enum: + - fsl,imx8qm-flexcan + - fsl,imx8mp-flexcan + - fsl,imx6q-flexcan + - fsl,imx53-flexcan + - fsl,imx35-flexcan + - fsl,imx28-flexcan + - fsl,imx25-flexcan + - fsl,p1010-flexcan + - fsl,vf610-flexcan + - fsl,ls1021ar2-flexcan + - fsl,lx2160ar1-flexcan + - items: + - enum: + - fsl,imx7d-flexcan + - fsl,imx6ul-flexcan + - fsl,imx6sx-flexcan + - const: fsl,imx6q-flexcan + - items: + - enum: + - fsl,ls1028ar1-flexcan + - const: fsl,lx2160ar1-flexcan + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 2 + + clock-names: + items: + - const: ipg + - const: per + + clock-frequency: + description: | + The oscillator frequency driving the flexcan device, filled in by the + boot loader. This property should only be used the used operating system + doesn't support the clocks and clock-names property. + + xceiver-supply: + description: Regulator that powers the CAN transceiver. + + big-endian: + $ref: /schemas/types.yaml#/definitions/flag + description: | + This means the registers of FlexCAN controller are big endian. This is + optional property.i.e. if this property is not present in device tree + node then controller is assumed to be little endian. If this property is + present then controller is assumed to be big endian. + + fsl,stop-mode: + description: | + Register bits of stop mode control. + + The format should be as follows: + + gpr is the phandle to general purpose register node. + req_gpr is the gpr register offset of CAN stop request. + req_bit is the bit offset of CAN stop request. + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - description: The 'gpr' is the phandle to general purpose register node. + - description: The 'req_gpr' is the gpr register offset of CAN stop request. + maximum: 0xff + - description: The 'req_bit' is the bit offset of CAN stop request. + maximum: 0x1f + + fsl,clk-source: + description: | + Select the clock source to the CAN Protocol Engine (PE). It's SoC + implementation dependent. Refer to RM for detailed definition. If this + property is not set in device tree node then driver selects clock source 1 + by default. + 0: clock source 0 (oscillator clock) + 1: clock source 1 (peripheral clock) + $ref: /schemas/types.yaml#/definitions/uint32 + default: 1 + minimum: 0 + maximum: 1 + + wakeup-source: + $ref: /schemas/types.yaml#/definitions/flag + description: + Enable CAN remote wakeup. + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + can@1c000 { + compatible = "fsl,p1010-flexcan"; + reg = <0x1c000 0x1000>; + interrupts = <48 0x2>; + interrupt-parent = <&mpic>; + clock-frequency = <200000000>; + fsl,clk-source = <0>; + }; + - | + #include + + can@2090000 { + compatible = "fsl,imx6q-flexcan"; + reg = <0x02090000 0x4000>; + interrupts = <0 110 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clks 1>, <&clks 2>; + clock-names = "ipg", "per"; + fsl,stop-mode = <&gpr 0x34 28>; + }; diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt deleted file mode 100644 index e10b6eb955e1..000000000000 --- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt +++ /dev/null @@ -1,57 +0,0 @@ -Flexcan CAN controller on Freescale's ARM and PowerPC system-on-a-chip (SOC). - -Required properties: - -- compatible : Should be "fsl,-flexcan" - - where is imx8qm, imx6q, imx28, imx53, imx35, imx25, p1010, - vf610, ls1021ar2, lx2160ar1, ls1028ar1. - - The ls1028ar1 must be followed by lx2160ar1, e.g. - - "fsl,ls1028ar1-flexcan", "fsl,lx2160ar1-flexcan" - - An implementation should also claim any of the following compatibles - that it is fully backwards compatible with: - - - fsl,p1010-flexcan - -- reg : Offset and length of the register set for this device -- interrupts : Interrupt tuple for this device - -Optional properties: - -- clock-frequency : The oscillator frequency driving the flexcan device - -- xceiver-supply: Regulator that powers the CAN transceiver - -- big-endian: This means the registers of FlexCAN controller are big endian. - This is optional property.i.e. if this property is not present in - device tree node then controller is assumed to be little endian. - if this property is present then controller is assumed to be big - endian. - -- fsl,stop-mode: register bits of stop mode control, the format is - <&gpr req_gpr req_bit>. - gpr is the phandle to general purpose register node. - req_gpr is the gpr register offset of CAN stop request. - req_bit is the bit offset of CAN stop request. - -- fsl,clk-source: Select the clock source to the CAN Protocol Engine (PE). - It's SoC Implementation dependent. Refer to RM for detailed - definition. If this property is not set in device tree node - then driver selects clock source 1 by default. - 0: clock source 0 (oscillator clock) - 1: clock source 1 (peripheral clock) - -- wakeup-source: enable CAN remote wakeup - -Example: - - can@1c000 { - compatible = "fsl,p1010-flexcan"; - reg = <0x1c000 0x1000>; - interrupts = <48 0x2>; - interrupt-parent = <&mpic>; - clock-frequency = <200000000>; // filled in by bootloader - fsl,clk-source = <0>; // select clock source 0 for PE - }; -- cgit v1.2.3 From 429efa6e148635c8b4fdc8db8ab6a8dae896ac17 Mon Sep 17 00:00:00 2001 From: Yegor Yefremov Date: Tue, 20 Oct 2020 10:11:34 +0200 Subject: can: j1939: rename jacd tool Due to naming conflicts, jacd was renamed to j1939acd in: https://github.com/linux-can/can-utils/pull/199 Signed-off-by: Yegor Yefremov Link: https://lore.kernel.org/r/20201020081134.3597-1-yegorslists@googlemail.com Link: https://github.com/linux-can/can-utils/pull/199 Signed-off-by: Marc Kleine-Budde --- Documentation/networking/j1939.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/networking/j1939.rst b/Documentation/networking/j1939.rst index f5be243d250a..081dfc2e0452 100644 --- a/Documentation/networking/j1939.rst +++ b/Documentation/networking/j1939.rst @@ -376,7 +376,7 @@ only j1939.addr changed to the new SA, and must then send a valid address claim packet. This restarts the state machine in the kernel (and any other participant on the bus) for this NAME. -can-utils also include the jacd tool, so it can be used as code example or as +can-utils also include the j1939acd tool, so it can be used as code example or as default Address Claiming daemon. Send Examples -- cgit v1.2.3 From 864a2756d369861af15327b6ff62bb6fe984dbc8 Mon Sep 17 00:00:00 2001 From: Yegor Yefremov Date: Tue, 20 Oct 2020 12:10:43 +0200 Subject: can: j1939: fix syntax and spelling This patches fixes the syntax an spelling of the j1939 documentation. Signed-off-by: Yegor Yefremov Link: https://lore.kernel.org/r/20201020101043.6369-1-yegorslists@googlemail.com Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Signed-off-by: Marc Kleine-Budde --- Documentation/networking/j1939.rst | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/j1939.rst b/Documentation/networking/j1939.rst index 081dfc2e0452..be59fcece3bf 100644 --- a/Documentation/networking/j1939.rst +++ b/Documentation/networking/j1939.rst @@ -10,9 +10,9 @@ Overview / What Is J1939 SAE J1939 defines a higher layer protocol on CAN. It implements a more sophisticated addressing scheme and extends the maximum packet size above 8 bytes. Several derived specifications exist, which differ from the original -J1939 on the application level, like MilCAN A, NMEA2000 and especially +J1939 on the application level, like MilCAN A, NMEA2000, and especially ISO-11783 (ISOBUS). This last one specifies the so-called ETP (Extended -Transport Protocol) which is has been included in this implementation. This +Transport Protocol), which has been included in this implementation. This results in a maximum packet size of ((2 ^ 24) - 1) * 7 bytes == 111 MiB. Specifications used @@ -32,15 +32,15 @@ sockets, we found some reasons to justify a kernel implementation for the addressing and transport methods used by J1939. * **Addressing:** when a process on an ECU communicates via J1939, it should - not necessarily know its source address. Although at least one process per + not necessarily know its source address. Although, at least one process per ECU should know the source address. Other processes should be able to reuse that address. This way, address parameters for different processes cooperating for the same ECU, are not duplicated. This way of working is - closely related to the UNIX concept where programs do just one thing, and do + closely related to the UNIX concept, where programs do just one thing and do it well. * **Dynamic addressing:** Address Claiming in J1939 is time critical. - Furthermore data transport should be handled properly during the address + Furthermore, data transport should be handled properly during the address negotiation. Putting this functionality in the kernel eliminates it as a requirement for _every_ user space process that communicates via J1939. This results in a consistent J1939 bus with proper addressing. @@ -58,7 +58,7 @@ Therefore, these parts are left to user space. The J1939 sockets operate on CAN network devices (see SocketCAN). Any J1939 user space library operating on CAN raw sockets will still operate properly. -Since such library does not communicate with the in-kernel implementation, care +Since such a library does not communicate with the in-kernel implementation, care must be taken that these two do not interfere. In practice, this means they cannot share ECU addresses. A single ECU (or virtual ECU) address is used by the library exclusively, or by the in-kernel system exclusively. @@ -77,13 +77,13 @@ is composed as follows: 8 bits : PS (PDU Specific) In J1939-21 distinction is made between PDU1 format (where PF < 240) and PDU2 -format (where PF >= 240). Furthermore, when using PDU2 format, the PS-field +format (where PF >= 240). Furthermore, when using the PDU2 format, the PS-field contains a so-called Group Extension, which is part of the PGN. When using PDU2 format, the Group Extension is set in the PS-field. On the other hand, when using PDU1 format, the PS-field contains a so-called Destination Address, which is _not_ part of the PGN. When communicating a PGN -from user space to kernel (or visa versa) and PDU2 format is used, the PS-field +from user space to kernel (or vice versa) and PDU2 format is used, the PS-field of the PGN shall be set to zero. The Destination Address shall be set elsewhere. @@ -96,15 +96,15 @@ Addressing Both static and dynamic addressing methods can be used. -For static addresses, no extra checks are made by the kernel, and provided +For static addresses, no extra checks are made by the kernel and provided addresses are considered right. This responsibility is for the OEM or system integrator. For dynamic addressing, so-called Address Claiming, extra support is foreseen -in the kernel. In J1939 any ECU is known by it's 64-bit NAME. At the moment of +in the kernel. In J1939 any ECU is known by its 64-bit NAME. At the moment of a successful address claim, the kernel keeps track of both NAME and source address being claimed. This serves as a base for filter schemes. By default, -packets with a destination that is not locally, will be rejected. +packets with a destination that is not locally will be rejected. Mixed mode packets (from a static to a dynamic address or vice versa) are allowed. The BSD sockets define separate API calls for getting/setting the @@ -153,8 +153,8 @@ described below. In order to send data, a bind(2) must have been successful. bind(2) assigns a local address to a socket. -Different from CAN is that the payload data is just the data that get send, -without it's header info. The header info is derived from the sockaddr supplied +Different from CAN is that the payload data is just the data that get sends, +without its header info. The header info is derived from the sockaddr supplied to bind(2), connect(2), sendto(2) and recvfrom(2). A write(2) with size 4 will result in a packet with 4 bytes. @@ -191,7 +191,7 @@ can_addr.j1939.addr contains the address. The bind(2) system call assigns the local address, i.e. the source address when sending packages. If a PGN during bind(2) is set, it's used as a RX filter. -I.e. only packets with a matching PGN are received. If an ADDR or NAME is set +I.e. only packets with a matching PGN are received. If an ADDR or NAME is set it is used as a receive filter, too. It will match the destination NAME or ADDR of the incoming packet. The NAME filter will work only if appropriate Address Claiming for this name was done on the CAN bus and registered/cached by the -- cgit v1.2.3 From ea780d39b1888ed5afc243c29b23d9bdb3828c7a Mon Sep 17 00:00:00 2001 From: Yegor Yefremov Date: Thu, 22 Oct 2020 10:37:08 +0200 Subject: can: j1939: swap addr and pgn in the send example The address was wrongly assigned to the PGN field and vice versa. Signed-off-by: Yegor Yefremov Link: https://lore.kernel.org/r/20201022083708.8755-1-yegorslists@googlemail.com Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Signed-off-by: Marc Kleine-Budde --- Documentation/networking/j1939.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/j1939.rst b/Documentation/networking/j1939.rst index be59fcece3bf..faf2eb5c5052 100644 --- a/Documentation/networking/j1939.rst +++ b/Documentation/networking/j1939.rst @@ -414,8 +414,8 @@ Send: .can_family = AF_CAN, .can_addr.j1939 = { .name = J1939_NO_NAME; - .pgn = 0x30, - .addr = 0x12300, + .addr = 0x30, + .pgn = 0x12300, }, }; -- cgit v1.2.3 From a39372c2c597d8ab0b53d953d9c4fc9ba2ed7dd6 Mon Sep 17 00:00:00 2001 From: Yegor Yefremov Date: Mon, 26 Oct 2020 10:44:42 +0100 Subject: can: j1939: use backquotes for code samples This patch adds backquotes for code samples. Signed-off-by: Yegor Yefremov Link: https://lore.kernel.org/r/20201026094442.16587-1-yegorslists@googlemail.com Signed-off-by: Marc Kleine-Budde --- Documentation/networking/j1939.rst | 88 +++++++++++++++++++------------------- 1 file changed, 44 insertions(+), 44 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/j1939.rst b/Documentation/networking/j1939.rst index faf2eb5c5052..0a4b73b03b99 100644 --- a/Documentation/networking/j1939.rst +++ b/Documentation/networking/j1939.rst @@ -131,31 +131,31 @@ API Calls --------- On CAN, you first need to open a socket for communicating over a CAN network. -To use J1939, #include . From there, will be +To use J1939, ``#include ``. From there, ```` will be included too. To open a socket, use: .. code-block:: C s = socket(PF_CAN, SOCK_DGRAM, CAN_J1939); -J1939 does use SOCK_DGRAM sockets. In the J1939 specification, connections are +J1939 does use ``SOCK_DGRAM`` sockets. In the J1939 specification, connections are mentioned in the context of transport protocol sessions. These still deliver -packets to the other end (using several CAN packets). SOCK_STREAM is not +packets to the other end (using several CAN packets). ``SOCK_STREAM`` is not supported. -After the successful creation of the socket, you would normally use the bind(2) -and/or connect(2) system call to bind the socket to a CAN interface. After -binding and/or connecting the socket, you can read(2) and write(2) from/to the -socket or use send(2), sendto(2), sendmsg(2) and the recv*() counterpart +After the successful creation of the socket, you would normally use the ``bind(2)`` +and/or ``connect(2)`` system call to bind the socket to a CAN interface. After +binding and/or connecting the socket, you can ``read(2)`` and ``write(2)`` from/to the +socket or use ``send(2)``, ``sendto(2)``, ``sendmsg(2)`` and the ``recv*()`` counterpart operations on the socket as usual. There are also J1939 specific socket options described below. -In order to send data, a bind(2) must have been successful. bind(2) assigns a +In order to send data, a ``bind(2)`` must have been successful. ``bind(2)`` assigns a local address to a socket. Different from CAN is that the payload data is just the data that get sends, without its header info. The header info is derived from the sockaddr supplied -to bind(2), connect(2), sendto(2) and recvfrom(2). A write(2) with size 4 will +to ``bind(2)``, ``connect(2)``, ``sendto(2)`` and ``recvfrom(2)``. A ``write(2)`` with size 4 will result in a packet with 4 bytes. The sockaddr structure has extensions for use with J1939 as specified below: @@ -180,47 +180,47 @@ The sockaddr structure has extensions for use with J1939 as specified below: } can_addr; } -can_family & can_ifindex serve the same purpose as for other SocketCAN sockets. +``can_family`` & ``can_ifindex`` serve the same purpose as for other SocketCAN sockets. -can_addr.j1939.pgn specifies the PGN (max 0x3ffff). Individual bits are +``can_addr.j1939.pgn`` specifies the PGN (max 0x3ffff). Individual bits are specified above. -can_addr.j1939.name contains the 64-bit J1939 NAME. +``can_addr.j1939.name`` contains the 64-bit J1939 NAME. -can_addr.j1939.addr contains the address. +``can_addr.j1939.addr`` contains the address. -The bind(2) system call assigns the local address, i.e. the source address when -sending packages. If a PGN during bind(2) is set, it's used as a RX filter. +The ``bind(2)`` system call assigns the local address, i.e. the source address when +sending packages. If a PGN during ``bind(2)`` is set, it's used as a RX filter. I.e. only packets with a matching PGN are received. If an ADDR or NAME is set it is used as a receive filter, too. It will match the destination NAME or ADDR of the incoming packet. The NAME filter will work only if appropriate Address Claiming for this name was done on the CAN bus and registered/cached by the kernel. -On the other hand connect(2) assigns the remote address, i.e. the destination -address. The PGN from connect(2) is used as the default PGN when sending +On the other hand ``connect(2)`` assigns the remote address, i.e. the destination +address. The PGN from ``connect(2)`` is used as the default PGN when sending packets. If ADDR or NAME is set it will be used as the default destination ADDR -or NAME. Further a set ADDR or NAME during connect(2) is used as a receive +or NAME. Further a set ADDR or NAME during ``connect(2)`` is used as a receive filter. It will match the source NAME or ADDR of the incoming packet. -Both write(2) and send(2) will send a packet with local address from bind(2) and -the remote address from connect(2). Use sendto(2) to overwrite the destination +Both ``write(2)`` and ``send(2)`` will send a packet with local address from ``bind(2)`` and the +remote address from ``connect(2)``. Use ``sendto(2)`` to overwrite the destination address. -If can_addr.j1939.name is set (!= 0) the NAME is looked up by the kernel and -the corresponding ADDR is used. If can_addr.j1939.name is not set (== 0), -can_addr.j1939.addr is used. +If ``can_addr.j1939.name`` is set (!= 0) the NAME is looked up by the kernel and +the corresponding ADDR is used. If ``can_addr.j1939.name`` is not set (== 0), +``can_addr.j1939.addr`` is used. When creating a socket, reasonable defaults are set. Some options can be -modified with setsockopt(2) & getsockopt(2). +modified with ``setsockopt(2)`` & ``getsockopt(2)``. RX path related options: -- SO_J1939_FILTER - configure array of filters -- SO_J1939_PROMISC - disable filters set by bind(2) and connect(2) +- ``SO_J1939_FILTER`` - configure array of filters +- ``SO_J1939_PROMISC`` - disable filters set by ``bind(2)`` and ``connect(2)`` By default no broadcast packets can be send or received. To enable sending or -receiving broadcast packets use the socket option SO_BROADCAST: +receiving broadcast packets use the socket option ``SO_BROADCAST``: .. code-block:: C @@ -261,26 +261,26 @@ The following diagram illustrates the RX path: +---------------------------+ TX path related options: -SO_J1939_SEND_PRIO - change default send priority for the socket +``SO_J1939_SEND_PRIO`` - change default send priority for the socket Message Flags during send() and Related System Calls ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -send(2), sendto(2) and sendmsg(2) take a 'flags' argument. Currently +``send(2)``, ``sendto(2)`` and ``sendmsg(2)`` take a 'flags' argument. Currently supported flags are: -* MSG_DONTWAIT, i.e. non-blocking operation. +* ``MSG_DONTWAIT``, i.e. non-blocking operation. recvmsg(2) ^^^^^^^^^^ -In most cases recvmsg(2) is needed if you want to extract more information than -recvfrom(2) can provide. For example package priority and timestamp. The +In most cases ``recvmsg(2)`` is needed if you want to extract more information than +``recvfrom(2)`` can provide. For example package priority and timestamp. The Destination Address, name and packet priority (if applicable) are attached to -the msghdr in the recvmsg(2) call. They can be extracted using cmsg(3) macros, -with cmsg_level == SOL_J1939 && cmsg_type == SCM_J1939_DEST_ADDR, -SCM_J1939_DEST_NAME or SCM_J1939_PRIO. The returned data is a uint8_t for -priority and dst_addr, and uint64_t for dst_name. +the msghdr in the ``recvmsg(2)`` call. They can be extracted using ``cmsg(3)`` macros, +with ``cmsg_level == SOL_J1939 && cmsg_type == SCM_J1939_DEST_ADDR``, +``SCM_J1939_DEST_NAME`` or ``SCM_J1939_PRIO``. The returned data is a ``uint8_t`` for +``priority`` and ``dst_addr``, and ``uint64_t`` for ``dst_name``. .. code-block:: C @@ -305,12 +305,12 @@ Dynamic Addressing Distinction has to be made between using the claimed address and doing an address claim. To use an already claimed address, one has to fill in the -j1939.name member and provide it to bind(2). If the name had claimed an address +``j1939.name`` member and provide it to ``bind(2)``. If the name had claimed an address earlier, all further messages being sent will use that address. And the -j1939.addr member will be ignored. +``j1939.addr`` member will be ignored. An exception on this is PGN 0x0ee00. This is the "Address Claim/Cannot Claim -Address" message and the kernel will use the j1939.addr member for that PGN if +Address" message and the kernel will use the ``j1939.addr`` member for that PGN if necessary. To claim an address following code example can be used: @@ -371,12 +371,12 @@ NAME can send packets. If another ECU claims the address, the kernel will mark the NAME-SA expired. No socket bound to the NAME can send packets (other than address claims). To -claim another address, some socket bound to NAME, must bind(2) again, but with -only j1939.addr changed to the new SA, and must then send a valid address claim +claim another address, some socket bound to NAME, must ``bind(2)`` again, but with +only ``j1939.addr`` changed to the new SA, and must then send a valid address claim packet. This restarts the state machine in the kernel (and any other participant on the bus) for this NAME. -can-utils also include the j1939acd tool, so it can be used as code example or as +``can-utils`` also include the ``j1939acd`` tool, so it can be used as code example or as default Address Claiming daemon. Send Examples @@ -403,8 +403,8 @@ Bind: bind(sock, (struct sockaddr *)&baddr, sizeof(baddr)); -Now, the socket 'sock' is bound to the SA 0x20. Since no connect(2) was called, -at this point we can use only sendto(2) or sendmsg(2). +Now, the socket 'sock' is bound to the SA 0x20. Since no ``connect(2)`` was called, +at this point we can use only ``sendto(2)`` or ``sendmsg(2)``. Send: -- cgit v1.2.3 From 1741b014bd5556219fc9312a9401cad7aa364385 Mon Sep 17 00:00:00 2001 From: Lars Poeschel Date: Tue, 3 Nov 2020 10:58:27 +0100 Subject: auxdisplay: lcd2s DT binding doc Add a binding doc for the modtronix lcd2s auxdisplay driver. It also adds modtronix to the list of known vendor-prefixes. Reviewed-by: Willy Tarreau Reviewed-by: Rob Herring Signed-off-by: Lars Poeschel Signed-off-by: Miguel Ojeda --- .../bindings/auxdisplay/modtronix,lcd2s.yaml | 58 ++++++++++++++++++++++ .../devicetree/bindings/vendor-prefixes.yaml | 2 + 2 files changed, 60 insertions(+) create mode 100644 Documentation/devicetree/bindings/auxdisplay/modtronix,lcd2s.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/auxdisplay/modtronix,lcd2s.yaml b/Documentation/devicetree/bindings/auxdisplay/modtronix,lcd2s.yaml new file mode 100644 index 000000000000..a1d55a2634a5 --- /dev/null +++ b/Documentation/devicetree/bindings/auxdisplay/modtronix,lcd2s.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/auxdisplay/modtronix,lcd2s.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Modtronix engineering LCD2S Character LCD Display + +maintainers: + - Lars Poeschel + +description: + The LCD2S is a Character LCD Display manufactured by Modtronix Engineering. + The display supports a serial I2C and SPI interface. The driver currently + only supports the I2C interface. + +properties: + compatible: + const: modtronix,lcd2s + + reg: + maxItems: 1 + description: + I2C bus address of the display. + + display-height-chars: + description: Height of the display, in character cells. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 4 + + display-width-chars: + description: Width of the display, in character cells. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 16 + maximum: 20 + +required: + - compatible + - reg + - display-height-chars + - display-width-chars + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + lcd2s: auxdisplay@28 { + compatible = "modtronix,lcd2s"; + reg = <0x28>; + display-height-chars = <4>; + display-width-chars = <20>; + }; + }; diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 2735be1a8470..65f40ab5a87f 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -681,6 +681,8 @@ patternProperties: description: MiraMEMS Sensing Technology Co., Ltd. "^mitsubishi,.*": description: Mitsubishi Electric Corporation + "^modtronix,.*": + description: Modtronix Engineering "^mosaixtech,.*": description: Mosaix Technologies, Inc. "^motorola,.*": -- cgit v1.2.3 From d181bfe36715a1834958cf2d62253b624adfae51 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Tue, 3 Nov 2020 09:34:08 +0100 Subject: Documentation: remove mic/index from misc-devices/index.rst With the recent removal of the misc/mic/ directory, the documentation build now warns because we forgot about this index file. Fix that up so that there are no more warnings here. Reported-by: Stephen Rothwell Cc: Sudeep Dutt Link: https://lore.kernel.org/r/20201103083408.GA2511903@kroah.com Signed-off-by: Greg Kroah-Hartman --- Documentation/misc-devices/index.rst | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/misc-devices/index.rst b/Documentation/misc-devices/index.rst index 46072ce3d7ef..64420b3314fe 100644 --- a/Documentation/misc-devices/index.rst +++ b/Documentation/misc-devices/index.rst @@ -24,7 +24,6 @@ fit into other categories. isl29003 lis3lv02d max6875 - mic/index pci-endpoint-test spear-pcie-gadget uacce -- cgit v1.2.3 From e2729113ce66d8d21f729b41bc3ed3feaf1acf69 Mon Sep 17 00:00:00 2001 From: Alexander Duyck Date: Wed, 28 Oct 2020 18:55:34 -0700 Subject: platform/x86: Intel PMT class driver Intel Platform Monitoring Technology is meant to provide a common way to access telemetry and system metrics. Register mappings are not provided by the driver. Instead, a GUID is read from a header for each endpoint. The GUID identifies the device and is to be used with an XML, provided by the vendor, to discover the available set of metrics and their register mapping. This allows firmware updates to modify the register space without needing to update the driver every time with new mappings. Firmware writes a new GUID in this case to specify the new mapping. Software tools with access to the associated XML file can then interpret the changes. The module manages access to all Intel PMT endpoints on a system, independent of the device exporting them. It creates an intel_pmt class to manage the devices. For each telemetry endpoint, sysfs files provide GUID and size information as well as a pointer to the parent device the telemetry came from. Software may discover the association between endpoints and devices by iterating through the list in sysfs, or by looking for the existence of the class folder under the device of interest. A binary sysfs attribute of the same name allows software to then read or map the telemetry space for direct access. Signed-off-by: Alexander Duyck Signed-off-by: David E. Box Reviewed-by: Hans de Goede Signed-off-by: Lee Jones --- Documentation/ABI/testing/sysfs-class-intel_pmt | 54 +++++++++++++++++++++++++ 1 file changed, 54 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-class-intel_pmt (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-class-intel_pmt b/Documentation/ABI/testing/sysfs-class-intel_pmt new file mode 100644 index 000000000000..926b5cf95fd1 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-intel_pmt @@ -0,0 +1,54 @@ +What: /sys/class/intel_pmt/ +Date: October 2020 +KernelVersion: 5.10 +Contact: David Box +Description: + The intel_pmt/ class directory contains information for + devices that expose hardware telemetry using Intel Platform + Monitoring Technology (PMT) + +What: /sys/class/intel_pmt/telem +Date: October 2020 +KernelVersion: 5.10 +Contact: David Box +Description: + The telem directory contains files describing an instance of + a PMT telemetry device that exposes hardware telemetry. Each + telem directory has an associated telem file. This file + may be opened and mapped or read to access the telemetry space + of the device. The register layout of the telemetry space is + determined from an XML file that matches the PCI device id and + GUID for the device. + +What: /sys/class/intel_pmt/telem/telem +Date: October 2020 +KernelVersion: 5.10 +Contact: David Box +Description: + (RO) The telemetry data for this telemetry device. This file + may be mapped or read to obtain the data. + +What: /sys/class/intel_pmt/telem/guid +Date: October 2020 +KernelVersion: 5.10 +Contact: David Box +Description: + (RO) The GUID for this telemetry device. The GUID identifies + the version of the XML file for the parent device that is to + be used to get the register layout. + +What: /sys/class/intel_pmt/telem/size +Date: October 2020 +KernelVersion: 5.10 +Contact: David Box +Description: + (RO) The size of telemetry region in bytes that corresponds to + the mapping size for the telem file. + +What: /sys/class/intel_pmt/telem/offset +Date: October 2020 +KernelVersion: 5.10 +Contact: David Box +Description: + (RO) The offset of telemetry region in bytes that corresponds to + the mapping for the telem file. -- cgit v1.2.3 From 5ef9998c96b0c99c49c202054586967e609286d2 Mon Sep 17 00:00:00 2001 From: Alexander Duyck Date: Wed, 28 Oct 2020 18:55:36 -0700 Subject: platform/x86: Intel PMT Crashlog capability driver Add support for the Intel Platform Monitoring Technology crashlog interface. This interface provides a few sysfs values to allow for controlling the crashlog telemetry interface as well as a character driver to allow for mapping the crashlog memory region so that it can be accessed after a crashlog has been recorded. This driver is meant to only support the server version of the crashlog which is identified as crash_type 1 with a version of zero. Currently no other types are supported. Signed-off-by: Alexander Duyck Signed-off-by: David E. Box Reviewed-by: Hans de Goede Signed-off-by: Lee Jones --- Documentation/ABI/testing/sysfs-class-intel_pmt | 65 +++++++++++++++++++++++++ 1 file changed, 65 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-class-intel_pmt b/Documentation/ABI/testing/sysfs-class-intel_pmt index 926b5cf95fd1..ed4c886a21b1 100644 --- a/Documentation/ABI/testing/sysfs-class-intel_pmt +++ b/Documentation/ABI/testing/sysfs-class-intel_pmt @@ -52,3 +52,68 @@ Contact: David Box Description: (RO) The offset of telemetry region in bytes that corresponds to the mapping for the telem file. + +What: /sys/class/intel_pmt/crashlog +Date: October 2020 +KernelVersion: 5.10 +Contact: Alexander Duyck +Description: + The crashlog directory contains files for configuring an + instance of a PMT crashlog device that can perform crash data + recording. Each crashlog device has an associated crashlog + file. This file can be opened and mapped or read to access the + resulting crashlog buffer. The register layout for the buffer + can be determined from an XML file of specified GUID for the + parent device. + +What: /sys/class/intel_pmt/crashlog/crashlog +Date: October 2020 +KernelVersion: 5.10 +Contact: David Box +Description: + (RO) The crashlog buffer for this crashlog device. This file + may be mapped or read to obtain the data. + +What: /sys/class/intel_pmt/crashlog/guid +Date: October 2020 +KernelVersion: 5.10 +Contact: Alexander Duyck +Description: + (RO) The GUID for this crashlog device. The GUID identifies the + version of the XML file for the parent device that should be + used to determine the register layout. + +What: /sys/class/intel_pmt/crashlog/size +Date: October 2020 +KernelVersion: 5.10 +Contact: Alexander Duyck +Description: + (RO) The length of the result buffer in bytes that corresponds + to the size for the crashlog buffer. + +What: /sys/class/intel_pmt/crashlog/offset +Date: October 2020 +KernelVersion: 5.10 +Contact: Alexander Duyck +Description: + (RO) The offset of the buffer in bytes that corresponds + to the mapping for the crashlog device. + +What: /sys/class/intel_pmt/crashlog/enable +Date: October 2020 +KernelVersion: 5.10 +Contact: Alexander Duyck +Description: + (RW) Boolean value controlling if the crashlog functionality + is enabled for the crashlog device. + +What: /sys/class/intel_pmt/crashlog/trigger +Date: October 2020 +KernelVersion: 5.10 +Contact: Alexander Duyck +Description: + (RW) Boolean value controlling the triggering of the crashlog + device node. When read it provides data on if the crashlog has + been triggered. When written to it can be used to either clear + the current trigger by writing false, or to trigger a new + event if the trigger is not currently set. -- cgit v1.2.3 From 4cb3fb1cd96f9e9a2c5095db42c2d7adbd5c5af9 Mon Sep 17 00:00:00 2001 From: Alexey Budankov Date: Mon, 19 Oct 2020 20:16:49 +0300 Subject: doc/admin-guide: Note credentials consolidation under CAP_PERFMON Add note that starting from Linux v5.9 CAP_PERFMON Linux capability is enough to conduct performance monitoring and observability using perf_events API. Signed-off-by: Alexey Budankov Cc: Alexander Shishkin Cc: Andi Kleen Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Cc: linux-doc@vger.kernel.org Cc: linux-man@vger.kernel.org Cc: linux-security-module@vger.kernel.org Link: http://lore.kernel.org/lkml/2b1a92a1-84ce-5c70-837d-8ffe96849588@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo --- Documentation/admin-guide/perf-security.rst | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/perf-security.rst b/Documentation/admin-guide/perf-security.rst index 1307b5274a0f..57a65e27eeb9 100644 --- a/Documentation/admin-guide/perf-security.rst +++ b/Documentation/admin-guide/perf-security.rst @@ -84,11 +84,14 @@ capabilities then providing the process with CAP_PERFMON capability singly is recommended as the preferred secure approach to resolve double access denial logging related to usage of performance monitoring and observability. -Unprivileged processes using perf_events system call are also subject -for PTRACE_MODE_READ_REALCREDS ptrace access mode check [7]_ , whose -outcome determines whether monitoring is permitted. So unprivileged -processes provided with CAP_SYS_PTRACE capability are effectively -permitted to pass the check. +Prior Linux v5.9 unprivileged processes using perf_events system call +are also subject for PTRACE_MODE_READ_REALCREDS ptrace access mode check +[7]_ , whose outcome determines whether monitoring is permitted. +So unprivileged processes provided with CAP_SYS_PTRACE capability are +effectively permitted to pass the check. Starting from Linux v5.9 +CAP_SYS_PTRACE capability is not required and CAP_PERFMON is enough to +be provided for processes to make performance monitoring and observability +operations. Other capabilities being granted to unprivileged processes can effectively enable capturing of additional data required for later -- cgit v1.2.3 From 1dd88c195d59b79f0a974618cdf723f74c192b52 Mon Sep 17 00:00:00 2001 From: Alexey Budankov Date: Mon, 19 Oct 2020 20:18:12 +0300 Subject: doc/admin-guide: Document creation of CAP_PERFMON privileged shell Document steps to create CAP_PERFMON privileged shell to unblock Perf tool usage in cases when capabilities can't be assigned to an executable due to limitations of used file system. Suggested-by: Andi Kleen Signed-off-by: Alexey Budankov Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Cc: linux-doc@vger.kernel.org Cc: linux-man@vger.kernel.org Cc: linux-security-module@vger.kernel.org Link: http://lore.kernel.org/lkml/0abda956-de6c-95b1-61e8-49e146501079@linux.intel.com Signed-off-by: Arnaldo Carvalho de Melo --- Documentation/admin-guide/perf-security.rst | 68 ++++++++++++++++++++++++++--- 1 file changed, 62 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/admin-guide/perf-security.rst b/Documentation/admin-guide/perf-security.rst index 57a65e27eeb9..904e4eb37f99 100644 --- a/Documentation/admin-guide/perf-security.rst +++ b/Documentation/admin-guide/perf-security.rst @@ -102,11 +102,11 @@ CAP_SYSLOG capability permits reading kernel space memory addresses from Privileged Perf users groups --------------------------------- -Mechanisms of capabilities, privileged capability-dumb files [6]_ and -file system ACLs [10]_ can be used to create dedicated groups of -privileged Perf users who are permitted to execute performance monitoring -and observability without scope limits. The following steps can be -taken to create such groups of privileged Perf users. +Mechanisms of capabilities, privileged capability-dumb files [6]_, +file system ACLs [10]_ and sudo [15]_ utility can be used to create +dedicated groups of privileged Perf users who are permitted to execute +performance monitoring and observability without limits. The following +steps can be taken to create such groups of privileged Perf users. 1. Create perf_users group of privileged Perf users, assign perf_users group to Perf tool executable and limit access to the executable for @@ -136,7 +136,7 @@ taken to create such groups of privileged Perf users. # getcap perf perf = cap_sys_ptrace,cap_syslog,cap_perfmon+ep -If the libcap installed doesn't yet support "cap_perfmon", use "38" instead, +If the libcap [16]_ installed doesn't yet support "cap_perfmon", use "38" instead, i.e.: :: @@ -162,6 +162,60 @@ performance monitoring and observability by using functionality of the configured Perf tool executable that, when executes, passes perf_events subsystem scope checks. +In case Perf tool executable can't be assigned required capabilities (e.g. +file system is mounted with nosuid option or extended attributes are +not supported by the file system) then creation of the capabilities +privileged environment, naturally shell, is possible. The shell provides +inherent processes with CAP_PERFMON and other required capabilities so that +performance monitoring and observability operations are available in the +environment without limits. Access to the environment can be open via sudo +utility for members of perf_users group only. In order to create such +environment: + +1. Create shell script that uses capsh utility [16]_ to assign CAP_PERFMON + and other required capabilities into ambient capability set of the shell + process, lock the process security bits after enabling SECBIT_NO_SETUID_FIXUP, + SECBIT_NOROOT and SECBIT_NO_CAP_AMBIENT_RAISE bits and then change + the process identity to sudo caller of the script who should essentially + be a member of perf_users group: + +:: + + # ls -alh /usr/local/bin/perf.shell + -rwxr-xr-x. 1 root root 83 Oct 13 23:57 /usr/local/bin/perf.shell + # cat /usr/local/bin/perf.shell + exec /usr/sbin/capsh --iab=^cap_perfmon --secbits=239 --user=$SUDO_USER -- -l + +2. Extend sudo policy at /etc/sudoers file with a rule for perf_users group: + +:: + + # grep perf_users /etc/sudoers + %perf_users ALL=/usr/local/bin/perf.shell + +3. Check that members of perf_users group have access to the privileged + shell and have CAP_PERFMON and other required capabilities enabled + in permitted, effective and ambient capability sets of an inherent process: + +:: + + $ id + uid=1003(capsh_test) gid=1004(capsh_test) groups=1004(capsh_test),1000(perf_users) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 + $ sudo perf.shell + [sudo] password for capsh_test: + $ grep Cap /proc/self/status + CapInh: 0000004000000000 + CapPrm: 0000004000000000 + CapEff: 0000004000000000 + CapBnd: 000000ffffffffff + CapAmb: 0000004000000000 + $ capsh --decode=0000004000000000 + 0x0000004000000000=cap_perfmon + +As a result, members of perf_users group have access to the privileged +environment where they can use tools employing performance monitoring APIs +governed by CAP_PERFMON Linux capability. + This specific access control management is only available to superuser or root running processes with CAP_SETPCAP, CAP_SETFCAP [6]_ capabilities. @@ -267,3 +321,5 @@ Bibliography .. [12] ``_ .. [13] ``_ .. [14] ``_ +.. [15] ``_ +.. [16] ``_ -- cgit v1.2.3 From 1afc60e00de3abbb6c559da409c5c1bb8c1d98ec Mon Sep 17 00:00:00 2001 From: Jiaxin Yu Date: Tue, 3 Nov 2020 15:59:36 +0800 Subject: dt-bindings: mediatek: mt8192: add audio afe document This patch adds mt8192 audio afe document. Signed-off-by: Jiaxin Yu Link: https://lore.kernel.org/r/1604390378-23993-8-git-send-email-jiaxin.yu@mediatek.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/mt8192-afe-pcm.yaml | 100 +++++++++++++++++++++ 1 file changed, 100 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/mt8192-afe-pcm.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/mt8192-afe-pcm.yaml b/Documentation/devicetree/bindings/sound/mt8192-afe-pcm.yaml new file mode 100644 index 000000000000..0170c93802d2 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/mt8192-afe-pcm.yaml @@ -0,0 +1,100 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/mt8192-afe-pcm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek AFE PCM controller for mt8192 + +maintainers: + - Jiaxin Yu + - Shane Chien + +properties: + compatible: + const: mediatek,mt8192-audio + + interrupts: + maxItems: 1 + + resets: + maxItems: 1 + + reset-names: + const: audiosys + + mediatek,apmixedsys: + $ref: "/schemas/types.yaml#/definitions/phandle" + description: The phandle of the mediatek apmixedsys controller + + mediatek,infracfg: + $ref: "/schemas/types.yaml#/definitions/phandle" + description: The phandle of the mediatek infracfg controller + + mediatek,topckgen: + $ref: "/schemas/types.yaml#/definitions/phandle" + description: The phandle of the mediatek topckgen controller + + power-domains: + maxItems: 1 + + clocks: + items: + - description: AFE clock + - description: ADDA DAC clock + - description: ADDA DAC pre-distortion clock + - description: audio infra sys clock + - description: audio infra 26M clock + + clock-names: + items: + - const: aud_afe_clk + - const: aud_dac_clk + - const: aud_dac_predis_clk + - const: aud_infra_clk + - const: aud_infra_26m_clk + +required: + - compatible + - interrupts + - resets + - reset-names + - mediatek,apmixedsys + - mediatek,infracfg + - mediatek,topckgen + - power-domains + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include + #include + #include + #include + #include + + afe: mt8192-afe-pcm { + compatible = "mediatek,mt8192-audio"; + interrupts = ; + resets = <&watchdog MT8192_TOPRGU_AUDIO_SW_RST>; + reset-names = "audiosys"; + mediatek,apmixedsys = <&apmixedsys>; + mediatek,infracfg = <&infracfg>; + mediatek,topckgen = <&topckgen>; + power-domains = <&scpsys MT8192_POWER_DOMAIN_AUDIO>; + clocks = <&audsys CLK_AUD_AFE>, + <&audsys CLK_AUD_DAC>, + <&audsys CLK_AUD_DAC_PREDIS>, + <&infracfg CLK_INFRA_AUDIO>, + <&infracfg CLK_INFRA_AUDIO_26M_B>; + clock-names = "aud_afe_clk", + "aud_dac_clk", + "aud_dac_predis_clk", + "aud_infra_clk", + "aud_infra_26m_clk"; + }; + +... -- cgit v1.2.3 From 4a232122124bcbc241b8099c2f98a62c79699324 Mon Sep 17 00:00:00 2001 From: Jiaxin Yu Date: Tue, 3 Nov 2020 15:59:38 +0800 Subject: dt-bindings: mediatek: mt8192: add mt8192-mt6358-rt1015-rt5682 document This patch adds document for the machine board with mt6358, rt1015 and rt5682. Signed-off-by: Jiaxin Yu Link: https://lore.kernel.org/r/1604390378-23993-10-git-send-email-jiaxin.yu@mediatek.com Signed-off-by: Mark Brown --- .../sound/mt8192-mt6359-rt1015-rt5682.yaml | 42 ++++++++++++++++++++++ 1 file changed, 42 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml b/Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml new file mode 100644 index 000000000000..342232a61cfb --- /dev/null +++ b/Documentation/devicetree/bindings/sound/mt8192-mt6359-rt1015-rt5682.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/mt8192-mt6359-rt1015-rt5682.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek MT8192 with MT6359, RT1015 and RT5682 ASoC sound card driver + +maintainers: + - Jiaxin Yu + - Shane Chien + +description: + This binding describes the MT8192 sound card. + +properties: + compatible: + const: mediatek,mt8192_mt6359_rt1015_rt5682 + + mediatek,platform: + $ref: "/schemas/types.yaml#/definitions/phandle" + description: The phandle of MT8192 ASoC platform. + +additionalProperties: false + +required: + - compatible + - mediatek,platform + +examples: + - | + + sound: mt8192-sound { + compatible = "mediatek,mt8192-mt6359-rt1015-rt5682"; + mediatek,platform = <&afe>; + pinctrl-names = "aud_clk_mosi_off", + "aud_clk_mosi_on"; + pinctrl-0 = <&aud_clk_mosi_off>; + pinctrl-1 = <&aud_clk_mosi_on>; + }; + +... -- cgit v1.2.3 From 9ce7deff92e89b1807d0968c0b319d26361a72a6 Mon Sep 17 00:00:00 2001 From: Mat Martineau Date: Tue, 3 Nov 2020 11:05:08 -0800 Subject: docs: networking: mptcp: Add MPTCP sysctl entries Describe the two MPTCP sysctls, what the values mean, and the default settings. Acked-by: Geliang Tang Signed-off-by: Mat Martineau Reviewed-by: Matthieu Baerts Signed-off-by: Jakub Kicinski --- Documentation/networking/index.rst | 1 + Documentation/networking/mptcp-sysctl.rst | 26 ++++++++++++++++++++++++++ 2 files changed, 27 insertions(+) create mode 100644 Documentation/networking/mptcp-sysctl.rst (limited to 'Documentation') diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst index 63ef386afd0a..70c71c9206e2 100644 --- a/Documentation/networking/index.rst +++ b/Documentation/networking/index.rst @@ -70,6 +70,7 @@ Contents: lapb-module mac80211-injection mpls-sysctl + mptcp-sysctl multiqueue netconsole netdev-features diff --git a/Documentation/networking/mptcp-sysctl.rst b/Documentation/networking/mptcp-sysctl.rst new file mode 100644 index 000000000000..6af0196c4297 --- /dev/null +++ b/Documentation/networking/mptcp-sysctl.rst @@ -0,0 +1,26 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================== +MPTCP Sysfs variables +===================== + +/proc/sys/net/mptcp/* Variables +=============================== + +enabled - INTEGER + Control whether MPTCP sockets can be created. + + MPTCP sockets can be created if the value is nonzero. This is + a per-namespace sysctl. + + Default: 1 + +add_addr_timeout - INTEGER (seconds) + Set the timeout after which an ADD_ADDR control message will be + resent to an MPTCP peer that has not acknowledged a previous + ADD_ADDR message. + + The default value matches TCP_RTO_MAX. This is a per-namespace + sysctl. + + Default: 120 -- cgit v1.2.3 From 57b971907eb07fbc8917f9f7a2df37da6304a296 Mon Sep 17 00:00:00 2001 From: Taniya Das Date: Sat, 17 Oct 2020 00:13:34 +0530 Subject: dt-bindings: clock: Add YAML schemas for the QCOM Camera clock bindings. The Camera Subsystem clock provider have a bunch of generic properties that are needed in a device tree. Add a YAML schemas for those. Add clock ids for camera clocks which are required to bring the camera subsystem out of reset. Signed-off-by: Taniya Das Link: https://lore.kernel.org/r/1602873815-1677-4-git-send-email-tdas@codeaurora.org Reviewed-by: Rob Herring Signed-off-by: Stephen Boyd --- .../bindings/clock/qcom,sc7180-camcc.yaml | 73 ++++++++++++++++++++++ 1 file changed, 73 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/qcom,sc7180-camcc.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,sc7180-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sc7180-camcc.yaml new file mode 100644 index 000000000000..f49027edfc44 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,sc7180-camcc.yaml @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,sc7180-camcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Camera Clock & Reset Controller Binding for SC7180 + +maintainers: + - Taniya Das + +description: | + Qualcomm camera clock control module which supports the clocks, resets and + power domains on SC7180. + + See also: + - dt-bindings/clock/qcom,camcc-sc7180.h + +properties: + compatible: + const: qcom,sc7180-camcc + + clocks: + items: + - description: Board XO source + - description: Camera_ahb clock from GCC + - description: Camera XO clock from GCC + + clock-names: + items: + - const: bi_tcxo + - const: iface + - const: xo + + '#clock-cells': + const: 1 + + '#reset-cells': + const: 1 + + '#power-domain-cells': + const: 1 + + reg: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + - '#reset-cells' + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + #include + #include + clock-controller@ad00000 { + compatible = "qcom,sc7180-camcc"; + reg = <0x0ad00000 0x10000>; + clocks = <&rpmhcc RPMH_CXO_CLK>, + <&gcc GCC_CAMERA_AHB_CLK>, + <&gcc GCC_CAMERA_XO_CLK>; + clock-names = "bi_tcxo", "iface", "xo"; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; +... -- cgit v1.2.3 From a6dee2fe778b9f79f75bfc203945ace79172623e Mon Sep 17 00:00:00 2001 From: Srinivas Kandagatla Date: Mon, 26 Oct 2020 12:02:18 +0000 Subject: dt-bindings: clock: Add support for LPASS Audio Clock Controller Audio Clock controller is a block inside LPASS which controls 2 Glitch free muxes to LPASS codec Macros. Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20201026120221.18984-2-srinivas.kandagatla@linaro.org Reviewed-by: Rob Herring Signed-off-by: Stephen Boyd --- .../bindings/clock/qcom,audiocc-sm8250.yaml | 58 ++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/qcom,audiocc-sm8250.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,audiocc-sm8250.yaml b/Documentation/devicetree/bindings/clock/qcom,audiocc-sm8250.yaml new file mode 100644 index 000000000000..915d76206ad0 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,audiocc-sm8250.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,audiocc-sm8250.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Clock bindings for LPASS Audio Clock Controller on SM8250 SoCs + +maintainers: + - Srinivas Kandagatla + +description: | + The clock consumer should specify the desired clock by having the clock + ID in its "clocks" phandle cell. + See include/dt-bindings/clock/qcom,sm8250-lpass-audiocc.h for the full list + of Audio Clock controller clock IDs. + +properties: + compatible: + const: qcom,sm8250-lpass-audiocc + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + + clocks: + items: + - description: LPASS Core voting clock + - description: Glitch Free Mux register clock + + clock-names: + items: + - const: core + - const: bus + +required: + - compatible + - reg + - '#clock-cells' + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include + #include + clock-controller@3300000 { + #clock-cells = <1>; + compatible = "qcom,sm8250-lpass-audiocc"; + reg = <0x03300000 0x30000>; + clocks = <&q6afecc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>, + <&q6afecc LPASS_CLK_ID_TX_CORE_MCLK LPASS_CLK_ATTRIBUTE_COUPLE_NO>; + clock-names = "core", "bus"; + }; -- cgit v1.2.3 From 7dbe5a7a3f990d642a3166b5d161db429d9f7271 Mon Sep 17 00:00:00 2001 From: Srinivas Kandagatla Date: Mon, 26 Oct 2020 12:02:19 +0000 Subject: dt-bindings: clock: Add support for LPASS Always ON Controller Always ON Clock controller is a block inside LPASS which controls 1 Glitch free muxes to LPASS codec Macros. Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20201026120221.18984-3-srinivas.kandagatla@linaro.org Reviewed-by: Rob Herring Signed-off-by: Stephen Boyd --- .../bindings/clock/qcom,aoncc-sm8250.yaml | 58 ++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 Documentation/devicetree/bindings/clock/qcom,aoncc-sm8250.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/clock/qcom,aoncc-sm8250.yaml b/Documentation/devicetree/bindings/clock/qcom,aoncc-sm8250.yaml new file mode 100644 index 000000000000..c40a74b5d672 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,aoncc-sm8250.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,aoncc-sm8250.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Clock bindings for LPASS Always ON Clock Controller on SM8250 SoCs + +maintainers: + - Srinivas Kandagatla + +description: | + The clock consumer should specify the desired clock by having the clock + ID in its "clocks" phandle cell. + See include/dt-bindings/clock/qcom,sm8250-lpass-aoncc.h for the full list + of Audio Clock controller clock IDs. + +properties: + compatible: + const: qcom,sm8250-lpass-aon + + reg: + maxItems: 1 + + '#clock-cells': + const: 1 + + clocks: + items: + - description: LPASS Core voting clock + - description: Glitch Free Mux register clock + + clock-names: + items: + - const: core + - const: bus + +required: + - compatible + - reg + - '#clock-cells' + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include + #include + clock-controller@3800000 { + #clock-cells = <1>; + compatible = "qcom,sm8250-lpass-aon"; + reg = <0x03380000 0x40000>; + clocks = <&q6afecc LPASS_HW_MACRO_VOTE LPASS_CLK_ATTRIBUTE_COUPLE_NO>, + <&q6afecc LPASS_CLK_ID_TX_CORE_MCLK LPASS_CLK_ATTRIBUTE_COUPLE_NO>; + clock-names = "core", "bus"; + }; -- cgit v1.2.3 From 06d65ba3db67618c0afd70a72df516dace49e7e7 Mon Sep 17 00:00:00 2001 From: Akhil P Oommen Date: Fri, 30 Oct 2020 16:17:12 +0530 Subject: dt-bindings: drm/msm/gpu: Add cooling device support Add cooling device support to gpu. A cooling device is bound to a thermal zone to allow thermal mitigation. Signed-off-by: Akhil P Oommen Reviewed-by: Matthias Kaehlcke Acked-by: Rob Herring Signed-off-by: Rob Clark --- Documentation/devicetree/bindings/display/msm/gpu.txt | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt b/Documentation/devicetree/bindings/display/msm/gpu.txt index 1af0ff102b50..090dcb3fc34d 100644 --- a/Documentation/devicetree/bindings/display/msm/gpu.txt +++ b/Documentation/devicetree/bindings/display/msm/gpu.txt @@ -39,6 +39,10 @@ Required properties: a4xx Snapdragon SoCs. See Documentation/devicetree/bindings/sram/qcom,ocmem.yaml. +Optional properties: +- #cooling-cells: The value must be 2. For details, please refer + Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml. + Example 3xx/4xx: / { @@ -61,6 +65,7 @@ Example 3xx/4xx: power-domains = <&mmcc OXILICX_GDSC>; operating-points-v2 = <&gpu_opp_table>; iommus = <&gpu_iommu 0>; + #cooling-cells = <2>; }; gpu_sram: ocmem@fdd00000 { @@ -98,6 +103,8 @@ Example a6xx (with GMU): reg = <0x5000000 0x40000>, <0x509e000 0x10>; reg-names = "kgsl_3d0_reg_memory", "cx_mem"; + #cooling-cells = <2>; + /* * Look ma, no clocks! The GPU clocks and power are * controlled entirely by the GMU -- cgit v1.2.3 From 40f4c56d08f2a95f4f3b036987f171dde69ddd36 Mon Sep 17 00:00:00 2001 From: Shengjiu Wang Date: Mon, 2 Nov 2020 09:52:26 +0800 Subject: ASoC: dt-bindings: fsl_aud2htx: Add binding doc for aud2htx module AUD2HTX (Audio Subsystem TO HDMI TX Subsystem) is a new IP module found on i.MX8MP. Signed-off-by: Shengjiu Wang Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/1604281947-26874-1-git-send-email-shengjiu.wang@nxp.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/fsl,aud2htx.yaml | 66 ++++++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/fsl,aud2htx.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/fsl,aud2htx.yaml b/Documentation/devicetree/bindings/sound/fsl,aud2htx.yaml new file mode 100644 index 000000000000..aa4be7170717 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/fsl,aud2htx.yaml @@ -0,0 +1,66 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/fsl,aud2htx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP Audio Subsystem to HDMI RTX Subsystem Controller + +maintainers: + - Shengjiu Wang + +properties: + compatible: + const: fsl,imx8mp-aud2htx + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Peripheral clock + + clock-names: + items: + - const: bus + + dmas: + items: + - description: DMA controller phandle and request line for TX + + dma-names: + items: + - const: tx + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - dmas + - dma-names + +additionalProperties: false + +examples: + - | + #include + #include + + aud2htx: aud2htx@30cb0000 { + compatible = "fsl,imx8mp-aud2htx"; + reg = <0x30cb0000 0x10000>; + interrupts = ; + clocks = <&audiomix_clk IMX8MP_CLK_AUDIOMIX_AUD2HTX_IPG>; + clock-names = "bus"; + dmas = <&sdma2 26 2 0>; + dma-names = "tx"; + power-domains = <&audiomix_pd>; + }; -- cgit v1.2.3 From 93bd813c17763177cf87e96c2313bd4dd747d234 Mon Sep 17 00:00:00 2001 From: Jack Yu Date: Thu, 5 Nov 2020 11:08:04 +0800 Subject: ASoC: rt1015: add delay to fix pop noise from speaker Add delay to fix pop noise from speaker. Signed-off-by: Jack Yu Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20201105030804.31115-1-jack.yu@realtek.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/rt1015.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/rt1015.txt b/Documentation/devicetree/bindings/sound/rt1015.txt index fcfd02d8d32f..e498966d436f 100644 --- a/Documentation/devicetree/bindings/sound/rt1015.txt +++ b/Documentation/devicetree/bindings/sound/rt1015.txt @@ -8,10 +8,16 @@ Required properties: - reg : The I2C address of the device. +Optional properties: + +- realtek,power-up-delay-ms + Set a delay time for flush work to be completed, + this value is adjustable depending on platform. Example: rt1015: codec@28 { compatible = "realtek,rt1015"; reg = <0x28>; + realtek,power-up-delay-ms = <50>; }; -- cgit v1.2.3 From 5a76b1ed73b9e7d1a31fd996fb5626edeebc0d29 Mon Sep 17 00:00:00 2001 From: Anitha Chrisanthus Date: Wed, 4 Nov 2020 17:15:25 -0800 Subject: dt-bindings: display: Add support for Intel KeemBay Display This patch adds bindings for Intel KeemBay Display v2: review changes from Rob Herring v3: review changes from Sam Ravnborg (removed mipi dsi entries, and encoder entry, connect port to dsi) MSSCAM is part of the display submodule and its used to reset LCD and MIPI DSI clocks, so its best to be on this device tree. v4: review changes from Neil Armstrong and Sam - removed msscam entries Signed-off-by: Anitha Chrisanthus Reviewed-by: Sam Ravnborg Cc: Sam Ravnborg Cc: Neil Armstrong Cc: Thomas Zimmermann Cc: Daniel Vetter Cc: Rob Herring Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/1604538931-26726-2-git-send-email-anitha.chrisanthus@intel.com --- .../bindings/display/intel,keembay-display.yaml | 72 ++++++++++++++++++++++ 1 file changed, 72 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/intel,keembay-display.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/intel,keembay-display.yaml b/Documentation/devicetree/bindings/display/intel,keembay-display.yaml new file mode 100644 index 000000000000..0a697d45c2ad --- /dev/null +++ b/Documentation/devicetree/bindings/display/intel,keembay-display.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/intel,keembay-display.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Devicetree bindings for Intel Keem Bay display controller + +maintainers: + - Anitha Chrisanthus + - Edmond J Dea + +properties: + compatible: + const: intel,keembay-display + + reg: + items: + - description: LCD registers range + + reg-names: + items: + - const: lcd + + clocks: + items: + - description: LCD controller clock + - description: pll0 clock + + clock-names: + items: + - const: clk_lcd + - const: clk_pll0 + + interrupts: + maxItems: 1 + + port: + type: object + description: Display output node to DSI. + +required: + - compatible + - reg + - reg-names + - clocks + - clock-names + - interrupts + - port + +additionalProperties: false + +examples: + - | + #include + #include + + display@20930000 { + compatible = "intel,keembay-display"; + reg = <0x20930000 0x3000>; + reg-names = "lcd"; + interrupts = ; + clocks = <&scmi_clk 0x83>, + <&scmi_clk 0x0>; + clock-names = "clk_lcd", "clk_pll0"; + + port { + disp_out: endpoint { + remote-endpoint = <&dsi_in>; + }; + }; + }; -- cgit v1.2.3 From 24c81b9e8e0b5d4652656d98bbf5d802c43e04ba Mon Sep 17 00:00:00 2001 From: Anitha Chrisanthus Date: Wed, 4 Nov 2020 17:15:26 -0800 Subject: dt-bindings: display: Intel KeemBay MSSCAM This patch add bindings for Intel KeemBay MSSCAM syscon v2: fixed compatible (Sam R.) Signed-off-by: Anitha Chrisanthus Cc: Sam Ravnborg Cc: Neil Armstrong Cc: Rob Herring Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/1604538931-26726-3-git-send-email-anitha.chrisanthus@intel.com --- .../bindings/display/intel,keembay-msscam.yaml | 43 ++++++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml b/Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml new file mode 100644 index 000000000000..40caa6118809 --- /dev/null +++ b/Documentation/devicetree/bindings/display/intel,keembay-msscam.yaml @@ -0,0 +1,43 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/intel,keembay-msscam.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Devicetree bindings for Intel Keem Bay MSSCAM + +maintainers: + - Anitha Chrisanthus + - Edmond J Dea + +description: | + MSSCAM controls local clocks in the display subsystem namely LCD clocks and + MIPI DSI clocks. It also configures the interconnect between LCD and + MIPI DSI. + +properties: + compatible: + items: + - const: intel,keembay-msscam + - const: syscon + + reg: + maxItems: 1 + + reg-io-width: + const: 4 + +required: + - compatible + - reg + - reg-io-width + +additionalProperties: false + +examples: + - | + msscam:msscam@20910000 { + compatible = "intel,keembay-msscam", "syscon"; + reg = <0x20910000 0x30>; + reg-io-width = <4>; + }; -- cgit v1.2.3 From d7e0798925ea9272f8c8e66ceb1f7c51823e50ab Mon Sep 17 00:00:00 2001 From: Anitha Chrisanthus Date: Wed, 4 Nov 2020 17:15:27 -0800 Subject: dt-bindings: display: bridge: Intel KeemBay DSI This patch adds bindings for Intel KeemBay MIPI DSI v2: corrected description for port Signed-off-by: Anitha Chrisanthus Reviewed-by: Sam Ravnborg Reviewed-by: Neil Armstrong Cc: Sam Ravnborg Cc: Thomas Zimmermann Cc: Daniel Vetter Cc: Rob Herring Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/1604538931-26726-4-git-send-email-anitha.chrisanthus@intel.com --- .../bindings/display/bridge/intel,keembay-dsi.yaml | 101 +++++++++++++++++++++ 1 file changed, 101 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml b/Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml new file mode 100644 index 000000000000..ab5be2625224 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/intel,keembay-dsi.yaml @@ -0,0 +1,101 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/intel,keembay-dsi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Devicetree bindings for Intel Keem Bay mipi dsi controller + +maintainers: + - Anitha Chrisanthus + - Edmond J Dea + +properties: + compatible: + const: intel,keembay-dsi + + reg: + items: + - description: MIPI registers range + + reg-names: + items: + - const: mipi + + clocks: + items: + - description: MIPI DSI clock + - description: MIPI DSI econfig clock + - description: MIPI DSI config clock + + clock-names: + items: + - const: clk_mipi + - const: clk_mipi_ecfg + - const: clk_mipi_cfg + + ports: + type: object + + properties: + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + port@0: + type: object + description: MIPI DSI input port. + + port@1: + type: object + description: DSI output port. + + required: + - port@0 + - port@1 + + additionalProperties: false + +required: + - compatible + - reg + - reg-names + - clocks + - clock-names + - ports + +additionalProperties: false + +examples: + - | + mipi-dsi@20900000 { + compatible = "intel,keembay-dsi"; + reg = <0x20900000 0x4000>; + reg-names = "mipi"; + clocks = <&scmi_clk 0x86>, + <&scmi_clk 0x88>, + <&scmi_clk 0x89>; + clock-names = "clk_mipi", "clk_mipi_ecfg", + "clk_mipi_cfg"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dsi_in: endpoint { + remote-endpoint = <&disp_out>; + }; + }; + + port@1 { + reg = <1>; + dsi_out: endpoint { + remote-endpoint = <&adv7535_input>; + }; + }; + }; + }; -- cgit v1.2.3 From 27bb0e42855abe22248800531beefe08e9d69eff Mon Sep 17 00:00:00 2001 From: Yong Wu Date: Tue, 3 Nov 2020 13:41:58 +0800 Subject: dt-bindings: memory: mediatek: Convert SMI to DT schema Convert MediaTek SMI to DT schema. Signed-off-by: Yong Wu Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20201103054200.21386-2-yong.wu@mediatek.com Signed-off-by: Krzysztof Kozlowski --- .../memory-controllers/mediatek,smi-common.txt | 50 -------- .../memory-controllers/mediatek,smi-common.yaml | 140 +++++++++++++++++++++ .../memory-controllers/mediatek,smi-larb.txt | 50 -------- .../memory-controllers/mediatek,smi-larb.yaml | 130 +++++++++++++++++++ 4 files changed, 270 insertions(+), 100 deletions(-) delete mode 100644 Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt create mode 100644 Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml delete mode 100644 Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt create mode 100644 Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt deleted file mode 100644 index dbafffe3f41e..000000000000 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.txt +++ /dev/null @@ -1,50 +0,0 @@ -SMI (Smart Multimedia Interface) Common - -The hardware block diagram please check bindings/iommu/mediatek,iommu.txt - -Mediatek SMI have two generations of HW architecture, here is the list -which generation the SoCs use: -generation 1: mt2701 and mt7623. -generation 2: mt2712, mt6779, mt8167, mt8173 and mt8183. - -There's slight differences between the two SMI, for generation 2, the -register which control the iommu port is at each larb's register base. But -for generation 1, the register is at smi ao base(smi always on register -base). Besides that, the smi async clock should be prepared and enabled for -SMI generation 1 to transform the smi clock into emi clock domain, but that is -not needed for SMI generation 2. - -Required properties: -- compatible : must be one of : - "mediatek,mt2701-smi-common" - "mediatek,mt2712-smi-common" - "mediatek,mt6779-smi-common" - "mediatek,mt7623-smi-common", "mediatek,mt2701-smi-common" - "mediatek,mt8167-smi-common" - "mediatek,mt8173-smi-common" - "mediatek,mt8183-smi-common" -- reg : the register and size of the SMI block. -- power-domains : a phandle to the power domain of this local arbiter. -- clocks : Must contain an entry for each entry in clock-names. -- clock-names : must contain 3 entries for generation 1 smi HW and 2 entries - for generation 2 smi HW as follows: - - "apb" : Advanced Peripheral Bus clock, It's the clock for setting - the register. - - "smi" : It's the clock for transfer data and command. - They may be the same if both source clocks are the same. - - "async" : asynchronous clock, it help transform the smi clock into the emi - clock domain, this clock is only needed by generation 1 smi HW. - and these 2 option clocks for generation 2 smi HW: - - "gals0": the path0 clock of GALS(Global Async Local Sync). - - "gals1": the path1 clock of GALS(Global Async Local Sync). - Here is the list which has this GALS: mt6779 and mt8183. - -Example: - smi_common: smi@14022000 { - compatible = "mediatek,mt8173-smi-common"; - reg = <0 0x14022000 0 0x1000>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_SMI_COMMON>, - <&mmsys CLK_MM_SMI_COMMON>; - clock-names = "apb", "smi"; - }; diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml new file mode 100644 index 000000000000..56c78317f9b7 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml @@ -0,0 +1,140 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (c) 2020 MediaTek Inc. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/mediatek,smi-common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SMI (Smart Multimedia Interface) Common + +maintainers: + - Yong Wu + +description: | + The hardware block diagram please check bindings/iommu/mediatek,iommu.yaml + + MediaTek SMI have two generations of HW architecture, here is the list + which generation the SoCs use: + generation 1: mt2701 and mt7623. + generation 2: mt2712, mt6779, mt8167, mt8173 and mt8183. + + There's slight differences between the two SMI, for generation 2, the + register which control the iommu port is at each larb's register base. But + for generation 1, the register is at smi ao base(smi always on register + base). Besides that, the smi async clock should be prepared and enabled for + SMI generation 1 to transform the smi clock into emi clock domain, but that is + not needed for SMI generation 2. + +properties: + compatible: + oneOf: + - enum: + - mediatek,mt2701-smi-common + - mediatek,mt2712-smi-common + - mediatek,mt6779-smi-common + - mediatek,mt8167-smi-common + - mediatek,mt8173-smi-common + - mediatek,mt8183-smi-common + + - description: for mt7623 + items: + - const: mediatek,mt7623-smi-common + - const: mediatek,mt2701-smi-common + + reg: + maxItems: 1 + + power-domains: + maxItems: 1 + + clocks: + description: | + apb and smi are mandatory. the async is only for generation 1 smi HW. + gals(global async local sync) also is optional, see below. + minItems: 2 + maxItems: 4 + items: + - description: apb is Advanced Peripheral Bus clock, It's the clock for + setting the register. + - description: smi is the clock for transfer data and command. + - description: async is asynchronous clock, it help transform the smi + clock into the emi clock domain. + - description: gals0 is the path0 clock of gals. + - description: gals1 is the path1 clock of gals. + + clock-names: + minItems: 2 + maxItems: 4 + +required: + - compatible + - reg + - power-domains + - clocks + - clock-names + +allOf: + - if: # only for gen1 HW + properties: + compatible: + contains: + enum: + - mediatek,mt2701-smi-common + then: + properties: + clock: + items: + minItems: 3 + maxItems: 3 + clock-names: + items: + - const: apb + - const: smi + - const: async + + - if: # for gen2 HW that have gals + properties: + compatible: + enum: + - mediatek,mt6779-smi-common + - mediatek,mt8183-smi-common + + then: + properties: + clock: + items: + minItems: 4 + maxItems: 4 + clock-names: + items: + - const: apb + - const: smi + - const: gals0 + - const: gals1 + + else: # for gen2 HW that don't have gals + properties: + clock: + items: + minItems: 2 + maxItems: 2 + clock-names: + items: + - const: apb + - const: smi + +additionalProperties: false + +examples: + - |+ + #include + #include + + smi_common: smi@14022000 { + compatible = "mediatek,mt8173-smi-common"; + reg = <0x14022000 0x1000>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_SMI_COMMON>, + <&mmsys CLK_MM_SMI_COMMON>; + clock-names = "apb", "smi"; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt deleted file mode 100644 index 0c5de12b5496..000000000000 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt +++ /dev/null @@ -1,50 +0,0 @@ -SMI (Smart Multimedia Interface) Local Arbiter - -The hardware block diagram please check bindings/iommu/mediatek,iommu.txt - -Required properties: -- compatible : must be one of : - "mediatek,mt2701-smi-larb" - "mediatek,mt2712-smi-larb" - "mediatek,mt6779-smi-larb" - "mediatek,mt7623-smi-larb", "mediatek,mt2701-smi-larb" - "mediatek,mt8167-smi-larb" - "mediatek,mt8173-smi-larb" - "mediatek,mt8183-smi-larb" -- reg : the register and size of this local arbiter. -- mediatek,smi : a phandle to the smi_common node. -- power-domains : a phandle to the power domain of this local arbiter. -- clocks : Must contain an entry for each entry in clock-names. -- clock-names: must contain 2 entries, as follows: - - "apb" : Advanced Peripheral Bus clock, It's the clock for setting - the register. - - "smi" : It's the clock for transfer data and command. - and this optional clock name: - - "gals": the clock for GALS(Global Async Local Sync). - Here is the list which has this GALS: mt8183. - -Required property for mt2701, mt2712, mt6779, mt7623 and mt8167: -- mediatek,larb-id :the hardware id of this larb. - -Example: - larb1: larb@16010000 { - compatible = "mediatek,mt8173-smi-larb"; - reg = <0 0x16010000 0 0x1000>; - mediatek,smi = <&smi_common>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_VDEC>; - clocks = <&vdecsys CLK_VDEC_CKEN>, - <&vdecsys CLK_VDEC_LARB_CKEN>; - clock-names = "apb", "smi"; - }; - -Example for mt2701: - larb0: larb@14010000 { - compatible = "mediatek,mt2701-smi-larb"; - reg = <0 0x14010000 0 0x1000>; - mediatek,smi = <&smi_common>; - mediatek,larb-id = <0>; - clocks = <&mmsys CLK_MM_SMI_LARB0>, - <&mmsys CLK_MM_SMI_LARB0>; - clock-names = "apb", "smi"; - power-domains = <&scpsys MT2701_POWER_DOMAIN_DISP>; - }; diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml new file mode 100644 index 000000000000..06b623b34f48 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml @@ -0,0 +1,130 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (c) 2020 MediaTek Inc. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/mediatek,smi-larb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SMI (Smart Multimedia Interface) Local Arbiter + +maintainers: + - Yong Wu + +description: | + The hardware block diagram please check bindings/iommu/mediatek,iommu.yaml + +properties: + compatible: + oneOf: + - enum: + - mediatek,mt2701-smi-larb + - mediatek,mt2712-smi-larb + - mediatek,mt6779-smi-larb + - mediatek,mt8167-smi-larb + - mediatek,mt8173-smi-larb + - mediatek,mt8183-smi-larb + + - description: for mt7623 + items: + - const: mediatek,mt7623-smi-larb + - const: mediatek,mt2701-smi-larb + + reg: + maxItems: 1 + + clocks: + description: | + apb and smi are mandatory. gals(global async local sync) is optional. + minItems: 2 + maxItems: 3 + items: + - description: apb is Advanced Peripheral Bus clock, It's the clock for + setting the register. + - description: smi is the clock for transfer data and command. + - description: the clock for gals. + + clock-names: + minItems: 2 + maxItems: 3 + + power-domains: + maxItems: 1 + + mediatek,smi: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: a phandle to the smi_common node. + + mediatek,larb-id: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 31 + description: the hardware id of this larb. It's only required when this + hardward id is not consecutive from its M4U point of view. + +required: + - compatible + - reg + - clocks + - clock-names + - power-domains + +allOf: + - if: # HW has gals + properties: + compatible: + enum: + - mediatek,mt8183-smi-larb + + then: + properties: + clock: + items: + minItems: 3 + maxItems: 3 + clock-names: + items: + - const: apb + - const: smi + - const: gals + + else: + properties: + clock: + items: + minItems: 2 + maxItems: 2 + clock-names: + items: + - const: apb + - const: smi + + - if: + properties: + compatible: + contains: + enum: + - mediatek,mt2701-smi-larb + - mediatek,mt2712-smi-larb + - mediatek,mt6779-smi-larb + - mediatek,mt8167-smi-larb + + then: + required: + - mediatek,larb-id + +additionalProperties: false + +examples: + - |+ + #include + #include + + larb1: larb@16010000 { + compatible = "mediatek,mt8173-smi-larb"; + reg = <0x16010000 0x1000>; + mediatek,smi = <&smi_common>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_VDEC>; + clocks = <&vdecsys CLK_VDEC_CKEN>, + <&vdecsys CLK_VDEC_LARB_CKEN>; + clock-names = "apb", "smi"; + }; -- cgit v1.2.3 From 31fc9f87fede778965e8ac5f902ae9106304f449 Mon Sep 17 00:00:00 2001 From: Yong Wu Date: Tue, 3 Nov 2020 13:41:59 +0800 Subject: dt-bindings: memory: mediatek: Add mt8192 support Add mt8192 smi support in the bindings. Signed-off-by: Yong Wu Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20201103054200.21386-3-yong.wu@mediatek.com Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/memory-controllers/mediatek,smi-common.yaml | 4 +++- .../devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml | 2 ++ 2 files changed, 5 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml index 56c78317f9b7..a08a32340987 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml @@ -16,7 +16,7 @@ description: | MediaTek SMI have two generations of HW architecture, here is the list which generation the SoCs use: generation 1: mt2701 and mt7623. - generation 2: mt2712, mt6779, mt8167, mt8173 and mt8183. + generation 2: mt2712, mt6779, mt8167, mt8173, mt8183 and mt8192. There's slight differences between the two SMI, for generation 2, the register which control the iommu port is at each larb's register base. But @@ -35,6 +35,7 @@ properties: - mediatek,mt8167-smi-common - mediatek,mt8173-smi-common - mediatek,mt8183-smi-common + - mediatek,mt8192-smi-common - description: for mt7623 items: @@ -98,6 +99,7 @@ allOf: enum: - mediatek,mt6779-smi-common - mediatek,mt8183-smi-common + - mediatek,mt8192-smi-common then: properties: diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml index 06b623b34f48..7ed7839ff0a7 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml @@ -23,6 +23,7 @@ properties: - mediatek,mt8167-smi-larb - mediatek,mt8173-smi-larb - mediatek,mt8183-smi-larb + - mediatek,mt8192-smi-larb - description: for mt7623 items: @@ -107,6 +108,7 @@ allOf: - mediatek,mt2712-smi-larb - mediatek,mt6779-smi-larb - mediatek,mt8167-smi-larb + - mediatek,mt8192-smi-larb then: required: -- cgit v1.2.3 From 97198614f6c3b019299b1189106478ffb58481c9 Mon Sep 17 00:00:00 2001 From: Kuninori Morimoto Date: Thu, 5 Nov 2020 15:04:57 +0900 Subject: ASoC: audio-graph-card: switch to yaml base Documentation This patch switches from .txt base to .yaml base Document. Signed-off-by: Kuninori Morimoto Acked-by: Sameer Pujar Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/87d00sbawh.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/audio-graph-card.txt | 337 --------------------- .../bindings/sound/audio-graph-card.yaml | 153 ++++++++++ 2 files changed, 153 insertions(+), 337 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/audio-graph-card.txt create mode 100644 Documentation/devicetree/bindings/sound/audio-graph-card.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/audio-graph-card.txt b/Documentation/devicetree/bindings/sound/audio-graph-card.txt deleted file mode 100644 index d5f6919a2d69..000000000000 --- a/Documentation/devicetree/bindings/sound/audio-graph-card.txt +++ /dev/null @@ -1,337 +0,0 @@ -Audio Graph Card: - -Audio Graph Card specifies audio DAI connections of SoC <-> codec. -It is based on common bindings for device graphs. -see ${LINUX}/Documentation/devicetree/bindings/graph.txt - -Basically, Audio Graph Card property is same as Simple Card. -see ${LINUX}/Documentation/devicetree/bindings/sound/simple-card.yaml - -Below are same as Simple-Card. - -- label -- widgets -- routing -- dai-format -- frame-master -- bitclock-master -- bitclock-inversion -- frame-inversion -- mclk-fs -- hp-det-gpio -- mic-det-gpio -- dai-tdm-slot-num -- dai-tdm-slot-width -- clocks / system-clock-frequency - -Required properties: - -- compatible : "audio-graph-card"; -- dais : list of CPU DAI port{s} - -Optional properties: -- pa-gpios: GPIO used to control external amplifier. - ------------------------ -Example: Single DAI case ------------------------ - - sound_card { - compatible = "audio-graph-card"; - - dais = <&cpu_port>; - }; - - dai-controller { - ... - cpu_port: port { - cpu_endpoint: endpoint { - remote-endpoint = <&codec_endpoint>; - - dai-format = "left_j"; - ... - }; - }; - }; - - audio-codec { - ... - port { - codec_endpoint: endpoint { - remote-endpoint = <&cpu_endpoint>; - }; - }; - }; - ------------------------ -Example: Multi DAI case ------------------------ - - sound-card { - compatible = "audio-graph-card"; - - label = "sound-card"; - - dais = <&cpu_port0 - &cpu_port1 - &cpu_port2>; - }; - - audio-codec@0 { - ... - port { - codec0_endpoint: endpoint { - remote-endpoint = <&cpu_endpoint0>; - }; - }; - }; - - audio-codec@1 { - ... - port { - codec1_endpoint: endpoint { - remote-endpoint = <&cpu_endpoint1>; - }; - }; - }; - - audio-codec@2 { - ... - port { - codec2_endpoint: endpoint { - remote-endpoint = <&cpu_endpoint2>; - }; - }; - }; - - dai-controller { - ... - ports { - cpu_port0: port@0 { - cpu_endpoint0: endpoint { - remote-endpoint = <&codec0_endpoint>; - - dai-format = "left_j"; - ... - }; - }; - cpu_port1: port@1 { - cpu_endpoint1: endpoint { - remote-endpoint = <&codec1_endpoint>; - - dai-format = "i2s"; - ... - }; - }; - cpu_port2: port@2 { - cpu_endpoint2: endpoint { - remote-endpoint = <&codec2_endpoint>; - - dai-format = "i2s"; - ... - }; - }; - }; - }; - - ------------------------ -Example: Sampling Rate Conversion ------------------------ - - sound_card { - compatible = "audio-graph-card"; - - label = "sound-card"; - prefix = "codec"; - routing = "codec Playback", "DAI0 Playback", - "DAI0 Capture", "codec Capture"; - convert-rate = <48000>; - - dais = <&cpu_port>; - }; - - audio-codec { - ... - port { - codec_endpoint: endpoint { - remote-endpoint = <&cpu_endpoint>; - }; - }; - }; - - dai-controller { - ... - cpu_port: port { - cpu_endpoint: endpoint { - remote-endpoint = <&codec_endpoint>; - - dai-format = "left_j"; - ... - }; - }; - }; - ------------------------ -Example: 2 CPU 1 Codec (Mixing) ------------------------ - - sound_card { - compatible = "audio-graph-card"; - - label = "sound-card"; - routing = "codec Playback", "DAI0 Playback", - "codec Playback", "DAI1 Playback", - "DAI0 Capture", "codec Capture"; - - dais = <&cpu_port>; - }; - - audio-codec { - ... - - audio-graph-card,prefix = "codec"; - audio-graph-card,convert-rate = <48000>; - port { - reg = <0>; - codec_endpoint0: endpoint@0 { - remote-endpoint = <&cpu_endpoint0>; - }; - codec_endpoint1: endpoint@1 { - remote-endpoint = <&cpu_endpoint1>; - }; - }; - }; - - dai-controller { - ... - cpu_port: port { - cpu_endpoint0: endpoint@0 { - remote-endpoint = <&codec_endpoint0>; - - dai-format = "left_j"; - ... - }; - cpu_endpoint1: endpoint@1 { - remote-endpoint = <&codec_endpoint1>; - - dai-format = "left_j"; - ... - }; - }; - }; - ------------------------ -Example: Multi DAI with DPCM ------------------------ - - CPU0 ------ ak4613 - CPU1 ------ HDMI - CPU2 ------ PCM3168A-p /* DPCM 1ch/2ch */ - CPU3 --/ /* DPCM 3ch/4ch */ - CPU4 --/ /* DPCM 5ch/6ch */ - CPU5 --/ /* DPCM 7ch/8ch */ - CPU6 ------ PCM3168A-c - - sound_card: sound { - compatible = "audio-graph-card"; - - label = "sound-card"; - - routing = "pcm3168a Playback", "DAI2 Playback", - "pcm3168a Playback", "DAI3 Playback", - "pcm3168a Playback", "DAI4 Playback", - "pcm3168a Playback", "DAI5 Playback"; - - dais = <&snd_port0 /* ak4613 */ - &snd_port1 /* HDMI0 */ - &snd_port2 /* pcm3168a playback */ - &snd_port3 /* pcm3168a capture */ - >; - }; - - ak4613: codec@10 { - ... - port { - ak4613_endpoint: endpoint { - remote-endpoint = <&rsnd_endpoint0>; - }; - }; - }; - - pcm3168a: audio-codec@44 { - ... - audio-graph-card,prefix = "pcm3168a"; - audio-graph-card,convert-channels = <8>; /* TDM Split */ - ports { - port@0 { - reg = <0>; - pcm3168a_endpoint_p1: endpoint@1 { - remote-endpoint = <&rsnd_endpoint2>; - ... - }; - pcm3168a_endpoint_p2: endpoint@2 { - remote-endpoint = <&rsnd_endpoint3>; - ... - }; - pcm3168a_endpoint_p3: endpoint@3 { - remote-endpoint = <&rsnd_endpoint4>; - ... - }; - pcm3168a_endpoint_p4: endpoint@4 { - remote-endpoint = <&rsnd_endpoint5>; - ... - }; - }; - port@1 { - reg = <1>; - pcm3168a_endpoint_c: endpoint { - remote-endpoint = <&rsnd_endpoint6>; - ... - }; - }; - }; - }; - - &sound { - ports { - snd_port0: port@0 { - rsnd_endpoint0: endpoint { - remote-endpoint = <&ak4613_endpoint>; - ... - }; - }; - snd_port1: port@1 { - rsnd_endpoint1: endpoint { - remote-endpoint = <&dw_hdmi0_snd_in>; - ... - }; - }; - snd_port2: port@2 { - #address-cells = <1>; - #size-cells = <0>; - rsnd_endpoint2: endpoint@2 { - remote-endpoint = <&pcm3168a_endpoint_p1>; - ... - }; - rsnd_endpoint3: endpoint@3 { - remote-endpoint = <&pcm3168a_endpoint_p2>; - ... - }; - rsnd_endpoint4: endpoint@4 { - remote-endpoint = <&pcm3168a_endpoint_p3>; - ... - }; - rsnd_endpoint5: endpoint@5 { - remote-endpoint = <&pcm3168a_endpoint_p4>; - ... - }; - }; - snd_port3: port@6 { - rsnd_endpoint6: endpoint { - remote-endpoint = <&pcm3168a_endpoint_c>; - ... - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/sound/audio-graph-card.yaml b/Documentation/devicetree/bindings/sound/audio-graph-card.yaml new file mode 100644 index 000000000000..2329aeb91db7 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/audio-graph-card.yaml @@ -0,0 +1,153 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/audio-graph-card.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Audio Graph Card Driver Device Tree Bindings + +maintainers: + - Kuninori Morimoto + +properties: + compatible: + enum: + - audio-graph-card + - audio-graph-scu-card + + dais: + $ref: /schemas/types.yaml#/definitions/phandle-array + label: + maxItems: 1 + prefix: + description: "device name prefix" + $ref: /schemas/types.yaml#/definitions/string + routing: + description: | + A list of the connections between audio components. + Each entry is a pair of strings, the first being the + connection's sink, the second being the connection's source. + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + widgets: + description: User specified audio sound widgets. + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + convert-rate: + description: CPU to Codec rate convert. + $ref: /schemas/types.yaml#/definitions/uint32 + convert-channels: + description: CPU to Codec rate channels. + $ref: /schemas/types.yaml#/definitions/uint32 + pa-gpios: + maxItems: 1 + hp-det-gpio: + maxItems: 1 + mic-det-gpio: + maxItems: 1 + + port: + description: single OF-Graph subnode + type: object + properties: + reg: + maxItems: 1 + prefix: + description: "device name prefix" + $ref: /schemas/types.yaml#/definitions/string + convert-rate: + description: CPU to Codec rate convert. + $ref: /schemas/types.yaml#/definitions/uint32 + convert-channels: + description: CPU to Codec rate channels. + $ref: /schemas/types.yaml#/definitions/uint32 + patternProperties: + "^endpoint(@[0-9a-f]+)?": + type: object + properties: + remote-endpoint: + maxItems: 1 + mclk-fs: + description: | + Multiplication factor between stream rate and codec mclk. + When defined, mclk-fs property defined in dai-link sub nodes are ignored. + $ref: /schemas/types.yaml#/definitions/uint32 + frame-inversion: + description: dai-link uses frame clock inversion + $ref: /schemas/types.yaml#/definitions/flag + bitclock-inversion: + description: dai-link uses bit clock inversion + $ref: /schemas/types.yaml#/definitions/flag + frame-master: + description: Indicates dai-link frame master. + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + bitclock-master: + description: Indicates dai-link bit clock master + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + dai-format: + description: audio format. + items: + enum: + - i2s + - right_j + - left_j + - dsp_a + - dsp_b + - ac97 + - pdm + - msb + - lsb + convert-rate: + description: CPU to Codec rate convert. + $ref: /schemas/types.yaml#/definitions/uint32 + convert-channels: + description: CPU to Codec rate channels. + $ref: /schemas/types.yaml#/definitions/uint32 + required: + - remote-endpoint + + ports: + description: multi OF-Graph subnode + type: object + patternProperties: + "^port(@[0-9a-f]+)?": + $ref: "#/properties/port" + +required: + - compatible + - dais + +additionalProperties: false + +examples: + - | + sound { + compatible = "audio-graph-card"; + + dais = <&cpu_port_a>; + }; + + cpu { + /* + * dai-controller own settings + */ + + port { + cpu_endpoint: endpoint { + remote-endpoint = <&codec_endpoint>; + dai-format = "left_j"; + }; + }; + }; + + codec { + /* + * codec own settings + */ + + port { + codec_endpoint: endpoint { + remote-endpoint = <&cpu_endpoint>; + }; + }; + }; -- cgit v1.2.3 From 2d8fc973646c8ae87b668e30730becc8b1a57a06 Mon Sep 17 00:00:00 2001 From: Kuninori Morimoto Date: Thu, 5 Nov 2020 15:05:10 +0900 Subject: ASoC: renesas, rsnd: switch to yaml base Documentation This patch switches from .txt base to .yaml base Document. It is still keeping detail explanations at .txt Signed-off-by: Kuninori Morimoto Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/87blgcbaw4.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/renesas,rsnd.txt | 520 --------------------- .../devicetree/bindings/sound/renesas,rsnd.yaml | 450 ++++++++++++++++++ 2 files changed, 450 insertions(+), 520 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/renesas,rsnd.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt index b39743d3f7c4..b731f16aea84 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt @@ -253,523 +253,3 @@ This is example of TDM 6ch. Driver can automatically switches TDM <-> stereo mode in this case. see "Example: simple sound card for TDM" - -============================================= -Required properties: -============================================= - -- compatible : "renesas,rcar_sound-", fallbacks - "renesas,rcar_sound-gen1" if generation1, and - "renesas,rcar_sound-gen2" if generation2 (or RZ/G1) - "renesas,rcar_sound-gen3" if generation3 (or RZ/G2) - Examples with soctypes are: - - "renesas,rcar_sound-r8a7742" (RZ/G1H) - - "renesas,rcar_sound-r8a7743" (RZ/G1M) - - "renesas,rcar_sound-r8a7744" (RZ/G1N) - - "renesas,rcar_sound-r8a7745" (RZ/G1E) - - "renesas,rcar_sound-r8a77470" (RZ/G1C) - - "renesas,rcar_sound-r8a774a1" (RZ/G2M) - - "renesas,rcar_sound-r8a774b1" (RZ/G2N) - - "renesas,rcar_sound-r8a774c0" (RZ/G2E) - - "renesas,rcar_sound-r8a774e1" (RZ/G2H) - - "renesas,rcar_sound-r8a7778" (R-Car M1A) - - "renesas,rcar_sound-r8a7779" (R-Car H1) - - "renesas,rcar_sound-r8a7790" (R-Car H2) - - "renesas,rcar_sound-r8a7791" (R-Car M2-W) - - "renesas,rcar_sound-r8a7793" (R-Car M2-N) - - "renesas,rcar_sound-r8a7794" (R-Car E2) - - "renesas,rcar_sound-r8a7795" (R-Car H3) - - "renesas,rcar_sound-r8a7796" (R-Car M3-W) - - "renesas,rcar_sound-r8a77965" (R-Car M3-N) - - "renesas,rcar_sound-r8a77990" (R-Car E3) - - "renesas,rcar_sound-r8a77995" (R-Car D3) -- reg : Should contain the register physical address. - required register is - SRU/ADG/SSI if generation1 - SRU/ADG/SSIU/SSI/AUDIO-DMAC-periperi if generation2/generation3 - Select extended AUDIO-DMAC-periperi address if SoC has it, - otherwise select normal AUDIO-DMAC-periperi address. -- reg-names : Should contain the register names. - scu/adg/ssi if generation1 - scu/adg/ssiu/ssi/audmapp if generation2/generation3 -- rcar_sound,ssi : Should contain SSI feature. - The number of SSI subnode should be same as HW. - see below for detail. -- rcar_sound,ssiu : Should contain SSIU feature. - The number of SSIU subnode should be same as HW. - see below for detail. -- rcar_sound,src : Should contain SRC feature. - The number of SRC subnode should be same as HW. - see below for detail. -- rcar_sound,ctu : Should contain CTU feature. - The number of CTU subnode should be same as HW. - see below for detail. -- rcar_sound,mix : Should contain MIX feature. - The number of MIX subnode should be same as HW. - see below for detail. -- rcar_sound,dvc : Should contain DVC feature. - The number of DVC subnode should be same as HW. - see below for detail. -- rcar_sound,dai : DAI contents. - The number of DAI subnode should be same as HW. - see below for detail. -- #sound-dai-cells : it must be 0 if your system is using single DAI - it must be 1 if your system is using multi DAI -- clocks : References to SSI/SRC/MIX/CTU/DVC/AUDIO_CLK clocks. -- clock-names : List of necessary clock names. - "ssi-all", "ssi.X", "src.X", "mix.X", "ctu.X", - "dvc.X", "clk_a", "clk_b", "clk_c", "clk_i" - -Optional properties: -- #clock-cells : it must be 0 if your system has audio_clkout - it must be 1 if your system has audio_clkout0/1/2/3 -- clock-frequency : for all audio_clkout0/1/2/3 -- clkout-lr-asynchronous : boolean property. it indicates that audio_clkoutn - is asynchronizes with lr-clock. -- resets : References to SSI resets. -- reset-names : List of valid reset names. - "ssi-all", "ssi.X" - -SSI subnode properties: -- interrupts : Should contain SSI interrupt for PIO transfer -- shared-pin : if shared clock pin -- pio-transfer : use PIO transfer mode -- no-busif : BUSIF is not ussed when [mem -> SSI] via DMA case -- dma : Should contain Audio DMAC entry -- dma-names : SSI case "rx" (=playback), "tx" (=capture) - Deprecated: see SSIU subnode properties - SSIU case "rxu" (=playback), "txu" (=capture) - -SSIU subnode properties: -- dma : Should contain Audio DMAC entry -- dma-names : "rx" (=playback), "tx" (=capture) - -SRC subnode properties: -- dma : Should contain Audio DMAC entry -- dma-names : "rx" (=playback), "tx" (=capture) - -DVC subnode properties: -- dma : Should contain Audio DMAC entry -- dma-names : "tx" (=playback/capture) - -DAI subnode properties: -- playback : list of playback modules -- capture : list of capture modules - - -============================================= -Example: -============================================= - -rcar_sound: sound@ec500000 { - #sound-dai-cells = <1>; - compatible = "renesas,rcar_sound-r8a7791", "renesas,rcar_sound-gen2"; - reg = <0 0xec500000 0 0x1000>, /* SCU */ - <0 0xec5a0000 0 0x100>, /* ADG */ - <0 0xec540000 0 0x1000>, /* SSIU */ - <0 0xec541000 0 0x1280>, /* SSI */ - <0 0xec740000 0 0x200>; /* Audio DMAC peri peri*/ - reg-names = "scu", "adg", "ssiu", "ssi", "audmapp"; - - clocks = <&mstp10_clks R8A7790_CLK_SSI_ALL>, - <&mstp10_clks R8A7790_CLK_SSI9>, <&mstp10_clks R8A7790_CLK_SSI8>, - <&mstp10_clks R8A7790_CLK_SSI7>, <&mstp10_clks R8A7790_CLK_SSI6>, - <&mstp10_clks R8A7790_CLK_SSI5>, <&mstp10_clks R8A7790_CLK_SSI4>, - <&mstp10_clks R8A7790_CLK_SSI3>, <&mstp10_clks R8A7790_CLK_SSI2>, - <&mstp10_clks R8A7790_CLK_SSI1>, <&mstp10_clks R8A7790_CLK_SSI0>, - <&mstp10_clks R8A7790_CLK_SCU_SRC9>, <&mstp10_clks R8A7790_CLK_SCU_SRC8>, - <&mstp10_clks R8A7790_CLK_SCU_SRC7>, <&mstp10_clks R8A7790_CLK_SCU_SRC6>, - <&mstp10_clks R8A7790_CLK_SCU_SRC5>, <&mstp10_clks R8A7790_CLK_SCU_SRC4>, - <&mstp10_clks R8A7790_CLK_SCU_SRC3>, <&mstp10_clks R8A7790_CLK_SCU_SRC2>, - <&mstp10_clks R8A7790_CLK_SCU_SRC1>, <&mstp10_clks R8A7790_CLK_SCU_SRC0>, - <&mstp10_clks R8A7790_CLK_SCU_DVC0>, <&mstp10_clks R8A7790_CLK_SCU_DVC1>, - <&audio_clk_a>, <&audio_clk_b>, <&audio_clk_c>, <&m2_clk>; - clock-names = "ssi-all", - "ssi.9", "ssi.8", "ssi.7", "ssi.6", "ssi.5", - "ssi.4", "ssi.3", "ssi.2", "ssi.1", "ssi.0", - "src.9", "src.8", "src.7", "src.6", "src.5", - "src.4", "src.3", "src.2", "src.1", "src.0", - "dvc.0", "dvc.1", - "clk_a", "clk_b", "clk_c", "clk_i"; - - rcar_sound,dvc { - dvc0: dvc-0 { - dmas = <&audma0 0xbc>; - dma-names = "tx"; - }; - dvc1: dvc-1 { - dmas = <&audma0 0xbe>; - dma-names = "tx"; - }; - }; - - rcar_sound,mix { - mix0: mix-0 { }; - mix1: mix-1 { }; - }; - - rcar_sound,ctu { - ctu00: ctu-0 { }; - ctu01: ctu-1 { }; - ctu02: ctu-2 { }; - ctu03: ctu-3 { }; - ctu10: ctu-4 { }; - ctu11: ctu-5 { }; - ctu12: ctu-6 { }; - ctu13: ctu-7 { }; - }; - - rcar_sound,src { - src0: src-0 { - interrupts = <0 352 IRQ_TYPE_LEVEL_HIGH>; - dmas = <&audma0 0x85>, <&audma1 0x9a>; - dma-names = "rx", "tx"; - }; - src1: src-1 { - interrupts = <0 353 IRQ_TYPE_LEVEL_HIGH>; - dmas = <&audma0 0x87>, <&audma1 0x9c>; - dma-names = "rx", "tx"; - }; - src2: src-2 { - interrupts = <0 354 IRQ_TYPE_LEVEL_HIGH>; - dmas = <&audma0 0x89>, <&audma1 0x9e>; - dma-names = "rx", "tx"; - }; - src3: src-3 { - interrupts = <0 355 IRQ_TYPE_LEVEL_HIGH>; - dmas = <&audma0 0x8b>, <&audma1 0xa0>; - dma-names = "rx", "tx"; - }; - src4: src-4 { - interrupts = <0 356 IRQ_TYPE_LEVEL_HIGH>; - dmas = <&audma0 0x8d>, <&audma1 0xb0>; - dma-names = "rx", "tx"; - }; - src5: src-5 { - interrupts = <0 357 IRQ_TYPE_LEVEL_HIGH>; - dmas = <&audma0 0x8f>, <&audma1 0xb2>; - dma-names = "rx", "tx"; - }; - src6: src-6 { - interrupts = <0 358 IRQ_TYPE_LEVEL_HIGH>; - dmas = <&audma0 0x91>, <&audma1 0xb4>; - dma-names = "rx", "tx"; - }; - src7: src-7 { - interrupts = <0 359 IRQ_TYPE_LEVEL_HIGH>; - dmas = <&audma0 0x93>, <&audma1 0xb6>; - dma-names = "rx", "tx"; - }; - src8: src-8 { - interrupts = <0 360 IRQ_TYPE_LEVEL_HIGH>; - dmas = <&audma0 0x95>, <&audma1 0xb8>; - dma-names = "rx", "tx"; - }; - src9: src-9 { - interrupts = <0 361 IRQ_TYPE_LEVEL_HIGH>; - dmas = <&audma0 0x97>, <&audma1 0xba>; - dma-names = "rx", "tx"; - }; - }; - - rcar_sound,ssiu { - ssiu00: ssiu-0 { - dmas = <&audma0 0x15>, <&audma1 0x16>; - dma-names = "rx", "tx"; - }; - ssiu01: ssiu-1 { - dmas = <&audma0 0x35>, <&audma1 0x36>; - dma-names = "rx", "tx"; - }; - - ... - - ssiu95: ssiu-49 { - dmas = <&audma0 0xA5>, <&audma1 0xA6>; - dma-names = "rx", "tx"; - }; - ssiu96: ssiu-50 { - dmas = <&audma0 0xA7>, <&audma1 0xA8>; - dma-names = "rx", "tx"; - }; - ssiu97: ssiu-51 { - dmas = <&audma0 0xA9>, <&audma1 0xAA>; - dma-names = "rx", "tx"; - }; - }; - - rcar_sound,ssi { - ssi0: ssi-0 { - interrupts = <0 370 IRQ_TYPE_LEVEL_HIGH>; - dmas = <&audma0 0x01>, <&audma1 0x02>; - dma-names = "rx", "tx"; - }; - ssi1: ssi-1 { - interrupts = <0 371 IRQ_TYPE_LEVEL_HIGH>; - dmas = <&audma0 0x03>, <&audma1 0x04>; - dma-names = "rx", "tx"; - }; - - ... - - ssi8: ssi-8 { - interrupts = <0 378 IRQ_TYPE_LEVEL_HIGH>; - dmas = <&audma0 0x11>, <&audma1 0x12>; - dma-names = "rx", "tx"; - }; - ssi9: ssi-9 { - interrupts = <0 379 IRQ_TYPE_LEVEL_HIGH>; - dmas = <&audma0 0x13>, <&audma1 0x14>; - dma-names = "rx", "tx"; - }; - }; - - rcar_sound,dai { - dai0 { - playback = <&ssi5 &src5>; - capture = <&ssi6>; - }; - dai1 { - playback = <&ssi3>; - }; - dai2 { - capture = <&ssi4>; - }; - dai3 { - playback = <&ssi7>; - }; - dai4 { - capture = <&ssi8>; - }; - }; -}; - -============================================= -Example: simple sound card -============================================= - - rsnd_ak4643: sound { - compatible = "simple-audio-card"; - - simple-audio-card,format = "left_j"; - simple-audio-card,bitclock-master = <&sndcodec>; - simple-audio-card,frame-master = <&sndcodec>; - - sndcpu: simple-audio-card,cpu { - sound-dai = <&rcar_sound>; - }; - - sndcodec: simple-audio-card,codec { - sound-dai = <&ak4643>; - clocks = <&audio_clock>; - }; - }; - -&rcar_sound { - pinctrl-0 = <&sound_pins &sound_clk_pins>; - pinctrl-names = "default"; - - /* Single DAI */ - #sound-dai-cells = <0>; - - - rcar_sound,dai { - dai0 { - playback = <&ssi0 &src2 &dvc0>; - capture = <&ssi1 &src3 &dvc1>; - }; - }; -}; - -&ssi1 { - shared-pin; -}; - -============================================= -Example: simple sound card for Asynchronous mode -============================================= - -sound { - compatible = "simple-scu-audio-card"; - ... - /* - * SRC Asynchronous mode setting - * Playback: - * All input data will be converted to 48kHz - * Capture: - * Inputed 48kHz data will be converted to - * system specified Hz - */ - simple-audio-card,convert-rate = <48000>; - ... - simple-audio-card,cpu { - sound-dai = <&rcar_sound>; - }; - simple-audio-card,codec { - ... - }; -}; - -============================================= -Example: simple sound card for channel convert -============================================= - -sound { - compatible = "simple-scu-audio-card"; - ... - /* - * CTU setting - * All input data will be converted to 2ch - * as output data - */ - simple-audio-card,convert-channels = <2>; - ... - simple-audio-card,cpu { - sound-dai = <&rcar_sound>; - }; - simple-audio-card,codec { - ... - }; -}; - -============================================= -Example: simple sound card for MIXer -============================================= - -sound { - compatible = "simple-scu-audio-card"; - ... - simple-audio-card,cpu@0 { - sound-dai = <&rcar_sound 0>; - }; - simple-audio-card,cpu@1 { - sound-dai = <&rcar_sound 1>; - }; - simple-audio-card,codec { - ... - }; -}; - -&rcar_sound { - ... - rcar_sound,dai { - dai0 { - playback = <&src1 &ctu02 &mix0 &dvc0 &ssi0>; - }; - dai1 { - playback = <&src2 &ctu03 &mix0 &dvc0 &ssi0>; - }; - }; -}; - -============================================= -Example: simple sound card for TDM -============================================= - -rsnd_tdm: sound { - compatible = "simple-audio-card"; - - simple-audio-card,format = "left_j"; - simple-audio-card,bitclock-master = <&sndcodec>; - simple-audio-card,frame-master = <&sndcodec>; - - sndcpu: simple-audio-card,cpu { - sound-dai = <&rcar_sound>; - dai-tdm-slot-num = <6>; - }; - - sndcodec: simple-audio-card,codec { - sound-dai = <&xxx>; - }; -}; - -============================================= -Example: simple sound card for TDM Split -============================================= - -sound_card: sound { - compatible = "audio-graph-scu-card"; - prefix = "xxxx"; - routing = "xxxx Playback", "DAI0 Playback", - "xxxx Playback", "DAI1 Playback", - "xxxx Playback", "DAI2 Playback", - "xxxx Playback", "DAI3 Playback"; - convert-channels = <8>; /* TDM Split */ - - dais = <&rsnd_port0 /* playback ch1/ch2 */ - &rsnd_port1 /* playback ch3/ch4 */ - &rsnd_port2 /* playback ch5/ch6 */ - &rsnd_port3 /* playback ch7/ch8 */ - >; -}; - -audio-codec { - ... - port { - codec_0: endpoint@1 { - remote-endpoint = <&rsnd_ep0>; - }; - codec_1: endpoint@2 { - remote-endpoint = <&rsnd_ep1>; - }; - codec_2: endpoint@3 { - remote-endpoint = <&rsnd_ep2>; - }; - codec_3: endpoint@4 { - remote-endpoint = <&rsnd_ep3>; - }; - }; -}; - -&rcar_sound { - ... - ports { - rsnd_port0: port@0 { - rsnd_ep0: endpoint { - remote-endpoint = <&codec_0>; - ... - playback = <&ssiu30 &ssi3>; - }; - }; - rsnd_port1: port@1 { - rsnd_ep1: endpoint { - remote-endpoint = <&codec_1>; - ... - playback = <&ssiu31 &ssi3>; - }; - }; - rsnd_port2: port@2 { - rsnd_ep2: endpoint { - remote-endpoint = <&codec_2>; - ... - playback = <&ssiu32 &ssi3>; - }; - }; - rsnd_port3: port@3 { - rsnd_ep3: endpoint { - remote-endpoint = <&codec_3>; - ... - playback = <&ssiu33 &ssi3>; - }; - }; - }; -}; - -============================================= -Example: simple sound card for Multi channel -============================================= - -&rcar_sound { - pinctrl-0 = <&sound_pins &sound_clk_pins>; - pinctrl-names = "default"; - - /* Single DAI */ - #sound-dai-cells = <0>; - - - rcar_sound,dai { - dai0 { - playback = <&ssi0 &ssi1 &ssi2 &src0 &dvc0>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml new file mode 100644 index 000000000000..ae41370f952c --- /dev/null +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml @@ -0,0 +1,450 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/renesas,rsnd.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Car Sound Driver Device Tree Bindings + +maintainers: + - Kuninori Morimoto + +properties: + + compatible: + oneOf: + # for Gen1 SoC + - items: + - enum: + - renesas,rcar_sound-r8a7778 # R-Car M1A + - renesas,rcar_sound-r8a7779 # R-Car H1 + - enum: + - renesas,rcar_sound-gen1 + # for Gen2 SoC + - items: + - enum: + - renesas,rcar_sound-r8a7742 # RZ/G1H + - renesas,rcar_sound-r8a7743 # RZ/G1M + - renesas,rcar_sound-r8a7744 # RZ/G1N + - renesas,rcar_sound-r8a7745 # RZ/G1E + - renesas,rcar_sound-r8a77470 # RZ/G1C + - renesas,rcar_sound-r8a7790 # R-Car H2 + - renesas,rcar_sound-r8a7791 # R-Car M2-W + - renesas,rcar_sound-r8a7793 # R-Car M2-N + - renesas,rcar_sound-r8a7794 # R-Car E2 + - enum: + - renesas,rcar_sound-gen2 + # for Gen3 SoC + - items: + - enum: + - renesas,rcar_sound-r8a774a1 # RZ/G2M + - renesas,rcar_sound-r8a774b1 # RZ/G2N + - renesas,rcar_sound-r8a774c0 # RZ/G2E + - renesas,rcar_sound-r8a774e1 # RZ/G2H + - renesas,rcar_sound-r8a7795 # R-Car H3 + - renesas,rcar_sound-r8a7796 # R-Car M3-W + - renesas,rcar_sound-r8a77965 # R-Car M3-N + - renesas,rcar_sound-r8a77990 # R-Car E3 + - renesas,rcar_sound-r8a77995 # R-Car D3 + - enum: + - renesas,rcar_sound-gen3 + # for Generic + - items: + - enum: + - renesas,rcar_sound-gen1 + - renesas,rcar_sound-gen2 + - renesas,rcar_sound-gen3 + + reg: + minItems: 1 + maxItems: 5 + + reg-names: + minItems: 1 + maxItems: 5 + + "#sound-dai-cells": + description: | + it must be 0 if your system is using single DAI + it must be 1 if your system is using multi DAIs + enum: [0, 1] + + "#clock-cells": + description: | + it must be 0 if your system has audio_clkout + it must be 1 if your system has audio_clkout0/1/2/3 + enum: [0, 1] + + clock-frequency: + description: for audio_clkout0/1/2/3 + $ref: /schemas/types.yaml#/definitions/uint32-array + + clkout-lr-asynchronous: + description: audio_clkoutn is asynchronizes with lr-clock. + $ref: /schemas/types.yaml#/definitions/flag + + power-domains: true + + resets: + maxItems: 11 + + reset-names: + maxItems: 11 + + clocks: + description: References to SSI/SRC/MIX/CTU/DVC/AUDIO_CLK clocks. + minItems: 1 + maxItems: 31 + + clock-names: + description: List of necessary clock names. + minItems: 1 + maxItems: 31 + items: + oneOf: + - const: ssi-all + - pattern: '^ssi\.[0-9]$' + - pattern: '^src\.[0-9]$' + - pattern: '^mix\.[0-1]$' + - pattern: '^ctu\.[0-1]$' + - pattern: '^dvc\.[0-1]$' + - pattern: '^clk_(a|b|c|i)$' + + port: + description: OF-Graph subnode + $ref: "audio-graph-card.yaml#/properties/port" + + ports: + description: multi OF-Graph subnode + $ref: "audio-graph-card.yaml#/properties/ports" + +# use patternProperties to avoid naming "xxx,yyy" issue +patternProperties: + "^rcar_sound,dvc$": + description: DVC subnode. + type: object + patternProperties: + "^dvc-[0-1]$": + type: object + properties: + dmas: + maxItems: 1 + dma-names: + const: "tx" + required: + - dmas + - dma-names + additionalProperties: false + + "^rcar_sound,mix$": + description: MIX subnode. + type: object + patternProperties: + "^mix-[0-1]$": + type: object + # no properties + additionalProperties: false + + "^rcar_sound,ctu$": + description: CTU subnode. + type: object + patternProperties: + "^ctu-[0-7]$": + type: object + # no properties + additionalProperties: false + + "^rcar_sound,src$": + description: SRC subnode. + type: object + patternProperties: + "^src-[0-9]$": + type: object + properties: + interrupts: + maxItems: 1 + dmas: + maxItems: 2 + dma-names: + allOf: + - items: + enum: + - tx + - rx + required: + - interrupts + - dmas + - dma-names + additionalProperties: false + + "^rcar_sound,ssiu$": + description: SSIU subnode. + type: object + patternProperties: + "^ssiu-[0-9]+$": + type: object + properties: + dmas: + maxItems: 2 + dma-names: + allOf: + - items: + enum: + - tx + - rx + required: + - dmas + - dma-names + additionalProperties: false + + "^rcar_sound,ssi$": + description: SSI subnode. + type: object + patternProperties: + "^ssi-[0-9]$": + type: object + properties: + interrupts: + maxItems: 1 + dmas: + minItems: 2 + maxItems: 4 + dma-names: + allOf: + - items: + enum: + - tx + - rx + - txu # if no ssiu node + - rxu # if no ssiu node + + shared-pin: + description: shared clock pin + $ref: /schemas/types.yaml#/definitions/flag + pio-transfer: + description: PIO transfer mode + $ref: /schemas/types.yaml#/definitions/flag + no-busif: + description: BUSIF is not used when [mem -> SSI] via DMA case + $ref: /schemas/types.yaml#/definitions/flag + required: + - interrupts + - dmas + - dma-names + additionalProperties: false + + # For DAI base + "^rcar_sound,dai$": + description: DAI subnode. + type: object + patternProperties: + "^dai([0-9]+)?$": + type: object + properties: + playback: + $ref: /schemas/types.yaml#/definitions/phandle-array + capture: + $ref: /schemas/types.yaml#/definitions/phandle-array + anyOf: + - required: + - playback + - required: + - capture + additionalProperties: false + +required: + - compatible + - reg + - reg-names + - clocks + - clock-names + - "#sound-dai-cells" + +allOf: + - if: + properties: + compatible: + contains: + const: renesas,rcar_sound-gen1 + then: + properties: + reg: + maxItems: 3 + reg-names: + maxItems: 3 + items: + enum: + - scu + - ssi + - adg + else: + properties: + reg: + maxItems: 5 + reg-names: + maxItems: 5 + items: + enum: + - scu + - adg + - ssiu + - ssi + - audmapp + +additionalProperties: false + +examples: + - | + rcar_sound: sound@ec500000 { + #sound-dai-cells = <1>; + compatible = "renesas,rcar_sound-r8a7790", "renesas,rcar_sound-gen2"; + reg = <0xec500000 0x1000>, /* SCU */ + <0xec5a0000 0x100>, /* ADG */ + <0xec540000 0x1000>, /* SSIU */ + <0xec541000 0x1280>, /* SSI */ + <0xec740000 0x200>; /* Audio DMAC peri peri*/ + reg-names = "scu", "adg", "ssiu", "ssi", "audmapp"; + + clocks = <&mstp10_clks 1005>, /* SSI-ALL */ + <&mstp10_clks 1006>, <&mstp10_clks 1007>, /* SSI9, SSI8 */ + <&mstp10_clks 1008>, <&mstp10_clks 1009>, /* SSI7, SSI6 */ + <&mstp10_clks 1010>, <&mstp10_clks 1011>, /* SSI5, SSI4 */ + <&mstp10_clks 1012>, <&mstp10_clks 1013>, /* SSI3, SSI2 */ + <&mstp10_clks 1014>, <&mstp10_clks 1015>, /* SSI1, SSI0 */ + <&mstp10_clks 1022>, <&mstp10_clks 1023>, /* SRC9, SRC8 */ + <&mstp10_clks 1024>, <&mstp10_clks 1025>, /* SRC7, SRC6 */ + <&mstp10_clks 1026>, <&mstp10_clks 1027>, /* SRC5, SRC4 */ + <&mstp10_clks 1028>, <&mstp10_clks 1029>, /* SRC3, SRC2 */ + <&mstp10_clks 1030>, <&mstp10_clks 1031>, /* SRC1, SRC0 */ + <&mstp10_clks 1020>, <&mstp10_clks 1021>, /* MIX1, MIX0 */ + <&mstp10_clks 1020>, <&mstp10_clks 1021>, /* CTU1, CTU0 */ + <&mstp10_clks 1019>, <&mstp10_clks 1018>, /* DVC0, DVC1 */ + <&audio_clk_a>, <&audio_clk_b>, /* CLKA, CLKB */ + <&audio_clk_c>, <&audio_clk_i>; /* CLKC, CLKI */ + + clock-names = "ssi-all", + "ssi.9", "ssi.8", + "ssi.7", "ssi.6", + "ssi.5", "ssi.4", + "ssi.3", "ssi.2", + "ssi.1", "ssi.0", + "src.9", "src.8", + "src.7", "src.6", + "src.5", "src.4", + "src.3", "src.2", + "src.1", "src.0", + "mix.1", "mix.0", + "ctu.1", "ctu.0", + "dvc.0", "dvc.1", + "clk_a", "clk_b", + "clk_c", "clk_i"; + + rcar_sound,dvc { + dvc0: dvc-0 { + dmas = <&audma0 0xbc>; + dma-names = "tx"; + }; + dvc1: dvc-1 { + dmas = <&audma0 0xbe>; + dma-names = "tx"; + }; + }; + + rcar_sound,mix { + mix0: mix-0 { }; + mix1: mix-1 { }; + }; + + rcar_sound,ctu { + ctu00: ctu-0 { }; + ctu01: ctu-1 { }; + ctu02: ctu-2 { }; + ctu03: ctu-3 { }; + ctu10: ctu-4 { }; + ctu11: ctu-5 { }; + ctu12: ctu-6 { }; + ctu13: ctu-7 { }; + }; + + rcar_sound,src { + src0: src-0 { + status = "disabled"; + }; + src1: src-1 { + interrupts = <0 353 0>; + dmas = <&audma0 0x87>, <&audma1 0x9c>; + dma-names = "rx", "tx"; + }; + /* skip after src-2 */ + }; + + rcar_sound,ssiu { + ssiu00: ssiu-0 { + dmas = <&audma0 0x15>, <&audma1 0x16>; + dma-names = "rx", "tx"; + }; + ssiu01: ssiu-1 { + dmas = <&audma0 0x35>, <&audma1 0x36>; + dma-names = "rx", "tx"; + }; + /* skip after ssiu-2 */ + }; + + rcar_sound,ssi { + ssi0: ssi-0 { + interrupts = <0 370 1>; + dmas = <&audma0 0x01>, <&audma1 0x02>; + dma-names = "rx", "tx"; + }; + ssi1: ssi-1 { + interrupts = <0 371 1>; + dmas = <&audma0 0x03>, <&audma1 0x04>; + dma-names = "rx", "tx"; + }; + /* skip other ssi-2 */ + }; + + /* DAI base */ + rcar_sound,dai { + dai0 { + playback = <&ssi5 &src5>; + capture = <&ssi6>; + }; + dai1 { + playback = <&ssi3>; + }; + dai2 { + capture = <&ssi4>; + }; + dai3 { + playback = <&ssi7>; + }; + dai4 { + capture = <&ssi8>; + }; + }; + + /* assume audio-graph */ + port { + rsnd_endpoint: endpoint { + remote-endpoint = <&codec_endpoint>; + + dai-format = "left_j"; + bitclock-master = <&rsnd_endpoint0>; + frame-master = <&rsnd_endpoint0>; + + playback = <&ssi0 &src0 &dvc0>; + capture = <&ssi1 &src1 &dvc1>; + }; + }; + }; + + + /* assume audio-graph */ + codec { + port { + codec_endpoint: endpoint { + remote-endpoint = <&rsnd_endpoint>; + }; + }; + }; -- cgit v1.2.3 From 8d96ec9ba9e7bd606d5d0fead9f91f0c5a3366a0 Mon Sep 17 00:00:00 2001 From: Kuninori Morimoto Date: Thu, 5 Nov 2020 15:05:23 +0900 Subject: ASoC: renesas,rsnd: Add r8a77961 support Document R-Car M3-W+ (R8A77961) SoC bindings. Signed-off-by: Kuninori Morimoto Acked-by: Rob Herring Link: https://lore.kernel.org/r/87a6vwbavq.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/renesas,rsnd.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml index ae41370f952c..51f4dcaa970d 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml @@ -43,6 +43,7 @@ properties: - renesas,rcar_sound-r8a774e1 # RZ/G2H - renesas,rcar_sound-r8a7795 # R-Car H3 - renesas,rcar_sound-r8a7796 # R-Car M3-W + - renesas,rcar_sound-r8a77961 # R-Car M3-W+ - renesas,rcar_sound-r8a77965 # R-Car M3-N - renesas,rcar_sound-r8a77990 # R-Car E3 - renesas,rcar_sound-r8a77995 # R-Car D3 -- cgit v1.2.3 From 21d3cdd0391bb01b348a47ec117eff3b9615d3a9 Mon Sep 17 00:00:00 2001 From: Dmitry Osipenko Date: Wed, 4 Nov 2020 19:48:40 +0300 Subject: dt-bindings: memory: tegra20: emc: Correct registers range in example There is superfluous zero in the registers base address and registers size should be twice bigger. Signed-off-by: Dmitry Osipenko Acked-by: Rob Herring Acked-by: Thierry Reding Link: https://lore.kernel.org/r/20201104164923.21238-5-digetx@gmail.com Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt index add95367640b..567cffd37f3f 100644 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt @@ -21,7 +21,7 @@ Example: #address-cells = < 1 >; #size-cells = < 0 >; compatible = "nvidia,tegra20-emc"; - reg = <0x7000f4000 0x200>; + reg = <0x7000f400 0x400>; interrupts = <0 78 0x04>; clocks = <&tegra_car TEGRA20_CLK_EMC>; } -- cgit v1.2.3 From dcfb1a75ba29f46c28cb4838a898b9c75ef86dd7 Mon Sep 17 00:00:00 2001 From: Kurt Kanzenbach Date: Tue, 3 Nov 2020 08:11:00 +0100 Subject: dt-bindings: Add vendor prefix for Hirschmann Hirschmann is building devices for automation and networking. Add them to the vendor prefixes. Signed-off-by: Kurt Kanzenbach Reviewed-by: Florian Fainelli Acked-by: Rob Herring Signed-off-by: Jakub Kicinski --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 2735be1a8470..bc8347c6cf56 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -441,6 +441,8 @@ patternProperties: description: HiDeep Inc. "^himax,.*": description: Himax Technologies, Inc. + "^hirschmann,.*": + description: Hirschmann Automation and Control GmbH "^hisilicon,.*": description: Hisilicon Limited. "^hit,.*": -- cgit v1.2.3 From d5d29d527a27d1376a2d3773b055cb035c8e0b4f Mon Sep 17 00:00:00 2001 From: Kurt Kanzenbach Date: Tue, 3 Nov 2020 08:11:01 +0100 Subject: dt-bindings: net: dsa: Add documentation for Hellcreek switches Add basic documentation and example. Signed-off-by: Kurt Kanzenbach Reviewed-by: Rob Herring Reviewed-by: Florian Fainelli Signed-off-by: Jakub Kicinski --- .../bindings/net/dsa/hirschmann,hellcreek.yaml | 127 +++++++++++++++++++++ 1 file changed, 127 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/dsa/hirschmann,hellcreek.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/dsa/hirschmann,hellcreek.yaml b/Documentation/devicetree/bindings/net/dsa/hirschmann,hellcreek.yaml new file mode 100644 index 000000000000..5592f58fa6f0 --- /dev/null +++ b/Documentation/devicetree/bindings/net/dsa/hirschmann,hellcreek.yaml @@ -0,0 +1,127 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/dsa/hirschmann,hellcreek.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Hirschmann Hellcreek TSN Switch Device Tree Bindings + +allOf: + - $ref: dsa.yaml# + +maintainers: + - Andrew Lunn + - Florian Fainelli + - Vivien Didelot + - Kurt Kanzenbach + +description: + The Hellcreek TSN Switch IP is a 802.1Q Ethernet compliant switch. It supports + the Precision Time Protocol, Hardware Timestamping as well the Time Aware + Shaper. + +properties: + compatible: + items: + - const: hirschmann,hellcreek-de1soc-r1 + + reg: + description: + The physical base address and size of TSN and PTP memory base + minItems: 2 + maxItems: 2 + + reg-names: + items: + - const: tsn + - const: ptp + + leds: + type: object + properties: + '#address-cells': + const: 1 + '#size-cells': + const: 0 + + patternProperties: + "^led@[01]$": + type: object + description: Hellcreek leds + $ref: ../../leds/common.yaml# + + properties: + reg: + items: + - enum: [0, 1] + description: Led number + + label: true + + default-state: true + + required: + - reg + + additionalProperties: false + + additionalProperties: false + +required: + - compatible + - reg + - reg-names + - ethernet-ports + - leds + +unevaluatedProperties: false + +examples: + - | + switch0: switch@ff240000 { + compatible = "hirschmann,hellcreek-de1soc-r1"; + reg = <0xff240000 0x1000>, + <0xff250000 0x1000>; + reg-names = "tsn", "ptp"; + dsa,member = <0 0>; + + ethernet-ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + label = "cpu"; + ethernet = <&gmac0>; + }; + + port@2 { + reg = <2>; + label = "lan0"; + phy-handle = <&phy1>; + }; + + port@3 { + reg = <3>; + label = "lan1"; + phy-handle = <&phy2>; + }; + }; + + leds { + #address-cells = <1>; + #size-cells = <0>; + + led@0 { + reg = <0>; + label = "sync_good"; + default-state = "on"; + }; + + led@1 { + reg = <1>; + label = "is_gm"; + default-state = "off"; + }; + }; + }; -- cgit v1.2.3 From c1c5bafd4481b40dfe4a4703702cb95930703426 Mon Sep 17 00:00:00 2001 From: Matteo Scordino Date: Thu, 5 Nov 2020 18:32:30 +0000 Subject: dt-bindings: arm: sunxi: add Elimo bindings Document board compatible names for Elimo Engineering Impetus and Initium Signed-off-by: Matteo Scordino Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20201105183231.12952-3-matteo.scordino@gmail.com --- Documentation/devicetree/bindings/arm/sunxi.yaml | 13 +++++++++++++ 1 file changed, 13 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index 0f23133672a3..ef2ce3bd2bed 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -201,6 +201,19 @@ properties: - const: dserve,dsrv9703c - const: allwinner,sun4i-a10 + - description: Elimo Engineering Impetus SoM + items: + - const: elimo,impetus + - const: sochip,s3 + - const: allwinner,sun8i-v3 + + - description: Elimo Engineering Initium + items: + - const: elimo,initium + - const: elimo,impetus + - const: sochip,s3 + - const: allwinner,sun8i-v3 + - description: Empire Electronix D709 Tablet items: - const: empire-electronix,d709 -- cgit v1.2.3 From 9340c293ebf0687d53a52c710a8e6fe80bfd6b6b Mon Sep 17 00:00:00 2001 From: Yu-Tung Chang Date: Mon, 2 Nov 2020 18:01:57 +0800 Subject: ARM: dts: sun8i: h3: Add initial NanoPi R1 support The NanoPi R1 is a complete open source board developed by FriendlyElec for makers, hobbyists, fans and etc. NanoPi R1 key features - Allwinner H3, Quad-core Cortex-A7@1.2GHz - 512MB/1GB DDR3 RAM - 8GB eMMC - microSD slot - 10/100/1000M Ethernet x 1 - 10/100 Ethernet x 1 - Wifi 802.11b/g/n - Bluetooth 4.0 - Serial Debug Port - 5V 2A DC power-supply Signed-off-by: Yu-Tung Chang Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20201102100157.85801-2-mtwget@gmail.com --- Documentation/devicetree/bindings/arm/sunxi.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index ef2ce3bd2bed..93e608aecae2 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -264,6 +264,11 @@ properties: - const: friendlyarm,nanopi-neo-plus2 - const: allwinner,sun50i-h5 + - description: FriendlyARM NanoPi R1 + items: + - const: friendlyarm,nanopi-r1 + - const: allwinner,sun8i-h3 + - description: FriendlyARM ZeroPi items: - const: friendlyarm,zeropi -- cgit v1.2.3 From a25d036d939a30623ff73ecad9c8b9116b02e823 Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (VMware)" Date: Thu, 5 Nov 2020 21:32:45 -0500 Subject: ftrace: Reverse what the RECURSION flag means in the ftrace_ops Now that all callbacks are recursion safe, reverse the meaning of the RECURSION flag and rename it from RECURSION_SAFE to simply RECURSION. Now only callbacks that request to have recursion protecting it will have the added trampoline to do so. Also remove the outdated comment about "PER_CPU" when determining to use the ftrace_ops_assist_func. Link: https://lkml.kernel.org/r/20201028115613.742454631@goodmis.org Link: https://lkml.kernel.org/r/20201106023547.904270143@goodmis.org Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Josh Poimboeuf Cc: Jiri Kosina Cc: Masami Hiramatsu Cc: Andrew Morton Cc: Jonathan Corbet Cc: Sebastian Andrzej Siewior Cc: Miroslav Benes Cc: Kamalesh Babulal Cc: Petr Mladek Cc: linux-doc@vger.kernel.org Signed-off-by: Steven Rostedt (VMware) --- Documentation/trace/ftrace-uses.rst | 82 +++++++++++++++++++++++++++---------- 1 file changed, 60 insertions(+), 22 deletions(-) (limited to 'Documentation') diff --git a/Documentation/trace/ftrace-uses.rst b/Documentation/trace/ftrace-uses.rst index a4955f7e3d19..86cd14b8e126 100644 --- a/Documentation/trace/ftrace-uses.rst +++ b/Documentation/trace/ftrace-uses.rst @@ -30,8 +30,8 @@ The ftrace context This requires extra care to what can be done inside a callback. A callback can be called outside the protective scope of RCU. -The ftrace infrastructure has some protections against recursions and RCU -but one must still be very careful how they use the callbacks. +There are helper functions to help against recursion, and making sure +RCU is watching. These are explained below. The ftrace_ops structure @@ -108,6 +108,50 @@ The prototype of the callback function is as follows (as of v4.14): at the start of the function where ftrace was tracing. Otherwise it either contains garbage, or NULL. +Protect your callback +===================== + +As functions can be called from anywhere, and it is possible that a function +called by a callback may also be traced, and call that same callback, +recursion protection must be used. There are two helper functions that +can help in this regard. If you start your code with: + + int bit; + + bit = ftrace_test_recursion_trylock(); + if (bit < 0) + return; + +and end it with: + + ftrace_test_recursion_unlock(bit); + +The code in between will be safe to use, even if it ends up calling a +function that the callback is tracing. Note, on success, +ftrace_test_recursion_trylock() will disable preemption, and the +ftrace_test_recursion_unlock() will enable it again (if it was previously +enabled). + +Alternatively, if the FTRACE_OPS_FL_RECURSION flag is set on the ftrace_ops +(as explained below), then a helper trampoline will be used to test +for recursion for the callback and no recursion test needs to be done. +But this is at the expense of a slightly more overhead from an extra +function call. + +If your callback accesses any data or critical section that requires RCU +protection, it is best to make sure that RCU is "watching", otherwise +that data or critical section will not be protected as expected. In this +case add: + + if (!rcu_is_watching()) + return; + +Alternatively, if the FTRACE_OPS_FL_RCU flag is set on the ftrace_ops +(as explained below), then a helper trampoline will be used to test +for rcu_is_watching for the callback and no other test needs to be done. +But this is at the expense of a slightly more overhead from an extra +function call. + The ftrace FLAGS ================ @@ -128,26 +172,20 @@ FTRACE_OPS_FL_SAVE_REGS_IF_SUPPORTED will not fail with this flag set. But the callback must check if regs is NULL or not to determine if the architecture supports it. -FTRACE_OPS_FL_RECURSION_SAFE - By default, a wrapper is added around the callback to - make sure that recursion of the function does not occur. That is, - if a function that is called as a result of the callback's execution - is also traced, ftrace will prevent the callback from being called - again. But this wrapper adds some overhead, and if the callback is - safe from recursion, it can set this flag to disable the ftrace - protection. - - Note, if this flag is set, and recursion does occur, it could cause - the system to crash, and possibly reboot via a triple fault. - - It is OK if another callback traces a function that is called by a - callback that is marked recursion safe. Recursion safe callbacks - must never trace any function that are called by the callback - itself or any nested functions that those functions call. - - If this flag is set, it is possible that the callback will also - be called with preemption enabled (when CONFIG_PREEMPTION is set), - but this is not guaranteed. +FTRACE_OPS_FL_RECURSION + By default, it is expected that the callback can handle recursion. + But if the callback is not that worried about overehead, then + setting this bit will add the recursion protection around the + callback by calling a helper function that will do the recursion + protection and only call the callback if it did not recurse. + + Note, if this flag is not set, and recursion does occur, it could + cause the system to crash, and possibly reboot via a triple fault. + + Not, if this flag is set, then the callback will always be called + with preemption disabled. If it is not set, then it is possible + (but not guaranteed) that the callback will be called in + preemptable context. FTRACE_OPS_FL_IPMODIFY Requires FTRACE_OPS_FL_SAVE_REGS set. If the callback is to "hijack" -- cgit v1.2.3 From 773c16705058e9be7b0f4ce124e89cd231c120a2 Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (VMware)" Date: Thu, 5 Nov 2020 21:32:46 -0500 Subject: ftrace: Add recording of functions that caused recursion This adds CONFIG_FTRACE_RECORD_RECURSION that will record to a file "recursed_functions" all the functions that caused recursion while a callback to the function tracer was running. Link: https://lkml.kernel.org/r/20201106023548.102375687@goodmis.org Cc: Masami Hiramatsu Cc: Andrew Morton Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Jonathan Corbet Cc: Guo Ren Cc: "James E.J. Bottomley" Cc: Helge Deller Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Paul Mackerras Cc: Heiko Carstens Cc: Vasily Gorbik Cc: Christian Borntraeger Cc: Thomas Gleixner Cc: Borislav Petkov Cc: x86@kernel.org Cc: "H. Peter Anvin" Cc: Kees Cook Cc: Anton Vorontsov Cc: Colin Cross Cc: Tony Luck Cc: Josh Poimboeuf Cc: Jiri Kosina Cc: Miroslav Benes Cc: Petr Mladek Cc: Joe Lawrence Cc: Kamalesh Babulal Cc: Mauro Carvalho Chehab Cc: Sebastian Andrzej Siewior Cc: linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-csky@vger.kernel.org Cc: linux-parisc@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-s390@vger.kernel.org Cc: live-patching@vger.kernel.org Signed-off-by: Steven Rostedt (VMware) --- Documentation/trace/ftrace-uses.rst | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/trace/ftrace-uses.rst b/Documentation/trace/ftrace-uses.rst index 86cd14b8e126..5981d5691745 100644 --- a/Documentation/trace/ftrace-uses.rst +++ b/Documentation/trace/ftrace-uses.rst @@ -118,7 +118,7 @@ can help in this regard. If you start your code with: int bit; - bit = ftrace_test_recursion_trylock(); + bit = ftrace_test_recursion_trylock(ip, parent_ip); if (bit < 0) return; @@ -130,7 +130,9 @@ The code in between will be safe to use, even if it ends up calling a function that the callback is tracing. Note, on success, ftrace_test_recursion_trylock() will disable preemption, and the ftrace_test_recursion_unlock() will enable it again (if it was previously -enabled). +enabled). The instruction pointer (ip) and its parent (parent_ip) is passed to +ftrace_test_recursion_trylock() to record where the recursion happened +(if CONFIG_FTRACE_RECORD_RECURSION is set). Alternatively, if the FTRACE_OPS_FL_RECURSION flag is set on the ftrace_ops (as explained below), then a helper trampoline will be used to test -- cgit v1.2.3 From 441494ec2a302830357d0aa59f3b907e319a8b26 Mon Sep 17 00:00:00 2001 From: Vignesh Raghavendra Date: Thu, 29 Oct 2020 12:23:18 +0530 Subject: dt-bindings: serial: 8250_omap: Add compatible for UART controller on AM64 SoC AM64 uses a UART controller that is compatible with AM654 UART. Introduce a specific compatible to help handle the differences if necessary. Reviewed-by: Nishanth Menon Acked-by: Rob Herring Signed-off-by: Vignesh Raghavendra Link: https://lore.kernel.org/r/20201029065318.2437-1-vigneshr@ti.com Signed-off-by: Greg Kroah-Hartman --- Documentation/devicetree/bindings/serial/omap_serial.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt index dcba86b0a0d0..c2db8cabf2ab 100644 --- a/Documentation/devicetree/bindings/serial/omap_serial.txt +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt @@ -1,6 +1,7 @@ OMAP UART controller Required properties: +- compatible : should be "ti,am64-uart", "ti,am654-uart" for AM64 controllers - compatible : should be "ti,j721e-uart", "ti,am654-uart" for J721E controllers - compatible : should be "ti,am654-uart" for AM654 controllers - compatible : should be "ti,omap2-uart" for OMAP2 controllers -- cgit v1.2.3 From e51a59f079c546b8b5c31604ad98e86b06ec93e9 Mon Sep 17 00:00:00 2001 From: Dmitry Osipenko Date: Wed, 4 Nov 2020 19:48:41 +0300 Subject: dt-bindings: memory: tegra20: emc: Document nvidia, memory-controller property Tegra20 External Memory Controller talks to DRAM chips and it needs to be reprogrammed when memory frequency changes. Tegra Memory Controller sits behind EMC and these controllers are tightly coupled. This patch adds the new phandle property which allows to properly express connection of EMC and MC hardware in a device-tree, it also put the Tegra20 EMC binding on par with Tegra30+ EMC bindings, which is handy to have. Signed-off-by: Dmitry Osipenko Acked-by: Rob Herring Link: https://lore.kernel.org/r/20201104164923.21238-6-digetx@gmail.com Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt index 567cffd37f3f..1b0d4417aad8 100644 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt @@ -12,6 +12,7 @@ Properties: irrespective of ram-code configuration. - interrupts : Should contain EMC General interrupt. - clocks : Should contain EMC clock. +- nvidia,memory-controller : Phandle of the Memory Controller node. Child device nodes describe the memory settings for different configurations and clock rates. @@ -24,6 +25,7 @@ Example: reg = <0x7000f400 0x400>; interrupts = <0 78 0x04>; clocks = <&tegra_car TEGRA20_CLK_EMC>; + nvidia,memory-controller = <&mc>; } -- cgit v1.2.3 From 3ee81e021f2bd44b70312692b719995d398a84ee Mon Sep 17 00:00:00 2001 From: Dmitry Osipenko Date: Wed, 4 Nov 2020 19:48:42 +0300 Subject: dt-bindings: memory: tegra20: mc: Document new interconnect property Memory controller is interconnected with memory clients and with the External Memory Controller. Document new interconnect property which turns memory controller into interconnect provider. Signed-off-by: Dmitry Osipenko Acked-by: Rob Herring Link: https://lore.kernel.org/r/20201104164923.21238-7-digetx@gmail.com Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/memory-controllers/nvidia,tegra20-mc.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-mc.txt b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-mc.txt index e55328237df4..739b7c6f2e26 100644 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-mc.txt +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-mc.txt @@ -16,6 +16,8 @@ Required properties: IOMMU specifier needed to encode an address. GART supports only a single address space that is shared by all devices, therefore no additional information needed for the address encoding. +- #interconnect-cells : Should be 1. This cell represents memory client. + The assignments may be found in header file . Example: mc: memory-controller@7000f000 { @@ -27,6 +29,7 @@ Example: interrupts = ; #reset-cells = <1>; #iommu-cells = <0>; + #interconnect-cells = <1>; }; video-codec@6001a000 { -- cgit v1.2.3 From 5e768b1fe46e6644cdbbbfa8c879c6cccb5639ba Mon Sep 17 00:00:00 2001 From: Dmitry Osipenko Date: Wed, 4 Nov 2020 19:48:43 +0300 Subject: dt-bindings: memory: tegra20: emc: Document new interconnect property External Memory Controller is interconnected with memory controller and with external memory. Document new interconnect property which turns EMC into interconnect provider. Signed-off-by: Dmitry Osipenko Acked-by: Rob Herring Link: https://lore.kernel.org/r/20201104164923.21238-8-digetx@gmail.com Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt index 1b0d4417aad8..82bc5b2ae7e5 100644 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt @@ -13,6 +13,7 @@ Properties: - interrupts : Should contain EMC General interrupt. - clocks : Should contain EMC clock. - nvidia,memory-controller : Phandle of the Memory Controller node. +- #interconnect-cells : Should be 0. Child device nodes describe the memory settings for different configurations and clock rates. @@ -21,6 +22,7 @@ Example: memory-controller@7000f400 { #address-cells = < 1 >; #size-cells = < 0 >; + #interconnect-cells = <0>; compatible = "nvidia,tegra20-emc"; reg = <0x7000f400 0x400>; interrupts = <0 78 0x04>; -- cgit v1.2.3 From 95e638e8b0b4bd0d51262bb7d01693039fc5ae48 Mon Sep 17 00:00:00 2001 From: Dmitry Osipenko Date: Wed, 4 Nov 2020 19:48:44 +0300 Subject: dt-bindings: memory: tegra20: emc: Document OPP table and voltage regulator The SoC core voltage can't be changed without taking into account the clock rate of External Memory Controller. Document OPP table that will be used for dynamic voltage frequency scaling, taking into account EMC voltage requirement. Document optional core voltage regulator, which is optional because some boards may have a fixed core regulator and still frequency scaling may be desired to have. Signed-off-by: Dmitry Osipenko Acked-by: Rob Herring Link: https://lore.kernel.org/r/20201104164923.21238-9-digetx@gmail.com Signed-off-by: Krzysztof Kozlowski --- .../bindings/memory-controllers/nvidia,tegra20-emc.txt | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt index 82bc5b2ae7e5..67ac8d1297da 100644 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt @@ -14,11 +14,25 @@ Properties: - clocks : Should contain EMC clock. - nvidia,memory-controller : Phandle of the Memory Controller node. - #interconnect-cells : Should be 0. +- operating-points-v2: See ../bindings/opp/opp.txt for details. + +Optional properties: +- core-supply: Phandle of voltage regulator of the SoC "core" power domain. Child device nodes describe the memory settings for different configurations and clock rates. Example: + opp_table: opp-table { + compatible = "operating-points-v2"; + + opp@36000000 { + opp-microvolt = <950000 950000 1300000>; + opp-hz = /bits/ 64 <36000000>; + }; + ... + }; + memory-controller@7000f400 { #address-cells = < 1 >; #size-cells = < 0 >; @@ -28,6 +42,8 @@ Example: interrupts = <0 78 0x04>; clocks = <&tegra_car TEGRA20_CLK_EMC>; nvidia,memory-controller = <&mc>; + core-supply = <&core_vdd_reg>; + operating-points-v2 = <&opp_table>; } -- cgit v1.2.3 From ed7f6f2eaae850ee836bee05feb1df722c13efad Mon Sep 17 00:00:00 2001 From: Dmitry Osipenko Date: Wed, 4 Nov 2020 19:48:45 +0300 Subject: dt-bindings: memory: tegra30: mc: Document new interconnect property Memory controller is interconnected with memory clients and with the External Memory Controller. Document new interconnect property which turns memory controller into interconnect provider. Signed-off-by: Dmitry Osipenko Acked-by: Rob Herring Link: https://lore.kernel.org/r/20201104164923.21238-10-digetx@gmail.com Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/memory-controllers/nvidia,tegra30-mc.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-mc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-mc.yaml index 84fd57bcf0dc..5436e6d420bc 100644 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-mc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-mc.yaml @@ -57,6 +57,9 @@ properties: "#iommu-cells": const: 1 + "#interconnect-cells": + const: 1 + patternProperties: "^emc-timings-[0-9]+$": type: object @@ -120,6 +123,7 @@ required: - clock-names - "#reset-cells" - "#iommu-cells" + - "#interconnect-cells" additionalProperties: false @@ -135,6 +139,7 @@ examples: #iommu-cells = <1>; #reset-cells = <1>; + #interconnect-cells = <1>; emc-timings-1 { nvidia,ram-code = <1>; -- cgit v1.2.3 From 6ec85c032aee0cde82b2c63a3e521132c97c4660 Mon Sep 17 00:00:00 2001 From: Dmitry Osipenko Date: Wed, 4 Nov 2020 19:48:46 +0300 Subject: dt-bindings: memory: tegra30: emc: Document new interconnect property External memory controller is interconnected with memory controller and with external memory. Document new interconnect property which turns External Memory Controller into interconnect provider. Signed-off-by: Dmitry Osipenko Acked-by: Rob Herring Link: https://lore.kernel.org/r/20201104164923.21238-11-digetx@gmail.com Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml index 112bae2fcbbd..c243986db420 100644 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml @@ -31,6 +31,9 @@ properties: interrupts: maxItems: 1 + "#interconnect-cells": + const: 0 + nvidia,memory-controller: $ref: /schemas/types.yaml#/definitions/phandle description: @@ -214,6 +217,7 @@ required: - interrupts - clocks - nvidia,memory-controller + - "#interconnect-cells" additionalProperties: false @@ -227,6 +231,8 @@ examples: nvidia,memory-controller = <&mc>; + #interconnect-cells = <0>; + emc-timings-1 { nvidia,ram-code = <1>; -- cgit v1.2.3 From 48126d7884ab56c2352ae328d5fd42c7d2d7b125 Mon Sep 17 00:00:00 2001 From: Dmitry Osipenko Date: Wed, 4 Nov 2020 19:48:47 +0300 Subject: dt-bindings: memory: tegra30: emc: Document OPP table and voltage regulator Document new OPP table and voltage regulator properties which are needed for supporting dynamic voltage-frequency scaling of the memory controller. Some boards may have a fixed core voltage regulator, hence it's optional because frequency scaling still may be desired. Signed-off-by: Dmitry Osipenko Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20201104164923.21238-12-digetx@gmail.com Signed-off-by: Krzysztof Kozlowski --- .../bindings/memory-controllers/nvidia,tegra30-emc.yaml | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml index c243986db420..0a2e2c0d0fdd 100644 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-emc.yaml @@ -39,6 +39,15 @@ properties: description: Phandle of the Memory Controller node. + core-supply: + description: + Phandle of voltage regulator of the SoC "core" power domain. + + operating-points-v2: + description: + Should contain freqs and voltages and opp-supported-hw property, which + is a bitfield indicating SoC speedo ID mask. + patternProperties: "^emc-timings-[0-9]+$": type: object @@ -218,6 +227,7 @@ required: - clocks - nvidia,memory-controller - "#interconnect-cells" + - operating-points-v2 additionalProperties: false @@ -230,6 +240,8 @@ examples: clocks = <&tegra_car 57>; nvidia,memory-controller = <&mc>; + operating-points-v2 = <&dvfs_opp_table>; + core-supply = <&vdd_core>; #interconnect-cells = <0>; -- cgit v1.2.3 From cac2a3552c9ef3ee2ff9ec72794e1ab0a1f64012 Mon Sep 17 00:00:00 2001 From: Dmitry Osipenko Date: Wed, 4 Nov 2020 19:48:48 +0300 Subject: dt-bindings: memory: tegra124: mc: Document new interconnect property Memory controller is interconnected with memory clients and with the External Memory Controller. Document new interconnect property which turns memory controller into interconnect provider. Signed-off-by: Dmitry Osipenko Acked-by: Rob Herring Link: https://lore.kernel.org/r/20201104164923.21238-13-digetx@gmail.com Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml | 1 + .../devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml | 5 +++++ 2 files changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml index 278549f9e051..8ae3dae42d6e 100644 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml @@ -345,6 +345,7 @@ examples: #iommu-cells = <1>; #reset-cells = <1>; + #interconnect-cells = <1>; }; external-memory-controller@7001b000 { diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml index 84d0339505b1..7b18b4d11e0a 100644 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-mc.yaml @@ -40,6 +40,9 @@ properties: "#iommu-cells": const: 1 + "#interconnect-cells": + const: 1 + patternProperties: "^emc-timings-[0-9]+$": type: object @@ -104,6 +107,7 @@ required: - clock-names - "#reset-cells" - "#iommu-cells" + - "#interconnect-cells" additionalProperties: false @@ -119,6 +123,7 @@ examples: #iommu-cells = <1>; #reset-cells = <1>; + #interconnect-cells = <1>; emc-timings-3 { nvidia,ram-code = <3>; -- cgit v1.2.3 From cf3b2deb459df1d1f3cdbd4d24b35e9f3506d92f Mon Sep 17 00:00:00 2001 From: Dmitry Osipenko Date: Wed, 4 Nov 2020 19:48:49 +0300 Subject: dt-bindings: memory: tegra124: emc: Document new interconnect property External memory controller is interconnected with memory controller and with external memory. Document new interconnect property which turns External Memory Controller into interconnect provider. Signed-off-by: Dmitry Osipenko Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20201104164923.21238-14-digetx@gmail.com Signed-off-by: Krzysztof Kozlowski --- .../devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml index 8ae3dae42d6e..ac00832ceac1 100644 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml @@ -29,6 +29,9 @@ properties: items: - const: emc + "#interconnect-cells": + const: 0 + nvidia,memory-controller: $ref: /schemas/types.yaml#/definitions/phandle description: @@ -327,6 +330,7 @@ required: - clocks - clock-names - nvidia,memory-controller + - "#interconnect-cells" additionalProperties: false @@ -356,6 +360,8 @@ examples: nvidia,memory-controller = <&mc>; + #interconnect-cells = <0>; + emc-timings-0 { nvidia,ram-code = <3>; -- cgit v1.2.3 From 881f68ed9d4e2d9f6e4247f2f01d9c457921e6c6 Mon Sep 17 00:00:00 2001 From: Dmitry Osipenko Date: Wed, 4 Nov 2020 19:48:50 +0300 Subject: dt-bindings: memory: tegra124: emc: Document OPP table and voltage regulator Document new OPP table and voltage regulator properties which are needed for supporting dynamic voltage-frequency scaling of the memory controller. Some boards may have a fixed core voltage regulator, hence it's optional because frequency scaling still may be desired. Signed-off-by: Dmitry Osipenko Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20201104164923.21238-15-digetx@gmail.com Signed-off-by: Krzysztof Kozlowski --- .../bindings/memory-controllers/nvidia,tegra124-emc.yaml | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml index ac00832ceac1..09bde65e1955 100644 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra124-emc.yaml @@ -37,6 +37,15 @@ properties: description: phandle of the memory controller node + core-supply: + description: + Phandle of voltage regulator of the SoC "core" power domain. + + operating-points-v2: + description: + Should contain freqs and voltages and opp-supported-hw property, which + is a bitfield indicating SoC speedo ID mask. + patternProperties: "^emc-timings-[0-9]+$": type: object @@ -331,6 +340,7 @@ required: - clock-names - nvidia,memory-controller - "#interconnect-cells" + - operating-points-v2 additionalProperties: false @@ -359,6 +369,8 @@ examples: clock-names = "emc"; nvidia,memory-controller = <&mc>; + operating-points-v2 = <&dvfs_opp_table>; + core-supply = <&vdd_core>; #interconnect-cells = <0>; -- cgit v1.2.3 From 254a42ac93900f92307a280daf4ccbd118c72255 Mon Sep 17 00:00:00 2001 From: Dmitry Osipenko Date: Wed, 4 Nov 2020 19:48:51 +0300 Subject: dt-bindings: tegra30-actmon: Document OPP and interconnect properties Document EMC DFS OPP table and interconnect paths that will be used for scaling of system's memory bandwidth based on memory utilization statistics. Previously ACTMON was supposed to drive EMC clock rate directly, but now it should do it using interconnect framework in order to support shared voltage scaling in addition to the frequency scaling. Signed-off-by: Dmitry Osipenko Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20201104164923.21238-16-digetx@gmail.com Signed-off-by: Krzysztof Kozlowski --- .../bindings/arm/tegra/nvidia,tegra30-actmon.txt | 25 ++++++++++++++++++++++ 1 file changed, 25 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-actmon.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-actmon.txt index ea670a5d7ee3..897eedfa2bc8 100644 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-actmon.txt +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra30-actmon.txt @@ -18,8 +18,30 @@ clock-names. See ../../clock/clock-bindings.txt for details. ../../reset/reset.txt for details. - reset-names: Must include the following entries: - actmon +- operating-points-v2: See ../bindings/opp/opp.txt for details. +- interconnects: Should contain entries for memory clients sitting on + MC->EMC memory interconnect path. +- interconnect-names: Should include name of the interconnect path for each + interconnect entry. Consult TRM documentation for + information about available memory clients, see MEMORY + CONTROLLER section. + +For each opp entry in 'operating-points-v2' table: +- opp-supported-hw: bitfield indicating SoC speedo ID mask +- opp-peak-kBps: peak bandwidth of the memory channel Example: + dfs_opp_table: opp-table { + compatible = "operating-points-v2"; + + opp@12750000 { + opp-hz = /bits/ 64 <12750000>; + opp-supported-hw = <0x000F>; + opp-peak-kBps = <51000>; + }; + ... + }; + actmon@6000c800 { compatible = "nvidia,tegra124-actmon"; reg = <0x0 0x6000c800 0x0 0x400>; @@ -29,4 +51,7 @@ Example: clock-names = "actmon", "emc"; resets = <&tegra_car 119>; reset-names = "actmon"; + operating-points-v2 = <&dfs_opp_table>; + interconnects = <&mc TEGRA124_MC_MPCORER &emc>; + interconnect-names = "cpu"; }; -- cgit v1.2.3 From c553bb54a486eab2b0d3671db4b985c8d1ba51e9 Mon Sep 17 00:00:00 2001 From: Dmitry Osipenko Date: Wed, 4 Nov 2020 19:48:52 +0300 Subject: dt-bindings: host1x: Document new interconnect properties Most of Host1x devices have at least one memory client. These clients are directly connected to the memory controller. The new interconnect properties represent the memory client's connection to the memory controller. Signed-off-by: Dmitry Osipenko Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20201104164923.21238-17-digetx@gmail.com Signed-off-by: Krzysztof Kozlowski --- .../display/tegra/nvidia,tegra20-host1x.txt | 68 ++++++++++++++++++++++ 1 file changed, 68 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt index ac63ae4a3861..34d993338453 100644 --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt @@ -20,6 +20,10 @@ Required properties: - reset-names: Must include the following entries: - host1x +Each host1x client module having to perform DMA through the Memory Controller +should have the interconnect endpoints set to the Memory Client and External +Memory respectively. + The host1x top-level node defines a number of children, each representing one of the following host1x client modules: @@ -36,6 +40,12 @@ of the following host1x client modules: - reset-names: Must include the following entries: - mpe + Optional properties: + - interconnects: Must contain entry for the MPE memory clients. + - interconnect-names: Must include name of the interconnect path for each + interconnect entry. Consult TRM documentation for information about + available memory clients, see MEMORY CONTROLLER section. + - vi: video input Required properties: @@ -113,6 +123,12 @@ of the following host1x client modules: Required properties: - remote-endpoint: phandle to vi port 'endpoint' node. + Optional properties: + - interconnects: Must contain entry for the VI memory clients. + - interconnect-names: Must include name of the interconnect path for each + interconnect entry. Consult TRM documentation for information about + available memory clients, see MEMORY CONTROLLER section. + - epp: encoder pre-processor Required properties: @@ -126,6 +142,12 @@ of the following host1x client modules: - reset-names: Must include the following entries: - epp + Optional properties: + - interconnects: Must contain entry for the EPP memory clients. + - interconnect-names: Must include name of the interconnect path for each + interconnect entry. Consult TRM documentation for information about + available memory clients, see MEMORY CONTROLLER section. + - isp: image signal processor Required properties: @@ -139,6 +161,12 @@ of the following host1x client modules: - reset-names: Must include the following entries: - isp + Optional properties: + - interconnects: Must contain entry for the ISP memory clients. + - interconnect-names: Must include name of the interconnect path for each + interconnect entry. Consult TRM documentation for information about + available memory clients, see MEMORY CONTROLLER section. + - gr2d: 2D graphics engine Required properties: @@ -152,6 +180,12 @@ of the following host1x client modules: - reset-names: Must include the following entries: - 2d + Optional properties: + - interconnects: Must contain entry for the GR2D memory clients. + - interconnect-names: Must include name of the interconnect path for each + interconnect entry. Consult TRM documentation for information about + available memory clients, see MEMORY CONTROLLER section. + - gr3d: 3D graphics engine Required properties: @@ -170,6 +204,12 @@ of the following host1x client modules: - 3d - 3d2 (Only required on SoCs with two 3D clocks) + Optional properties: + - interconnects: Must contain entry for the GR3D memory clients. + - interconnect-names: Must include name of the interconnect path for each + interconnect entry. Consult TRM documentation for information about + available memory clients, see MEMORY CONTROLLER section. + - dc: display controller Required properties: @@ -197,6 +237,10 @@ of the following host1x client modules: - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection - nvidia,edid: supplies a binary EDID blob - nvidia,panel: phandle of a display panel + - interconnects: Must contain entry for the DC memory clients. + - interconnect-names: Must include name of the interconnect path for each + interconnect entry. Consult TRM documentation for information about + available memory clients, see MEMORY CONTROLLER section. - hdmi: High Definition Multimedia Interface @@ -345,6 +389,12 @@ of the following host1x client modules: - reset-names: Must include the following entries: - vic + Optional properties: + - interconnects: Must contain entry for the VIC memory clients. + - interconnect-names: Must include name of the interconnect path for each + interconnect entry. Consult TRM documentation for information about + available memory clients, see MEMORY CONTROLLER section. + Example: / { @@ -498,6 +548,15 @@ Example: resets = <&tegra_car 27>; reset-names = "dc"; + interconnects = <&mc TEGRA20_MC_DISPLAY0A &emc>, + <&mc TEGRA20_MC_DISPLAY0B &emc>, + <&mc TEGRA20_MC_DISPLAY0C &emc>, + <&mc TEGRA20_MC_DISPLAYHC &emc>; + interconnect-names = "wina", + "winb", + "winc", + "cursor"; + rgb { status = "disabled"; }; @@ -513,6 +572,15 @@ Example: resets = <&tegra_car 26>; reset-names = "dc"; + interconnects = <&mc TEGRA20_MC_DISPLAY0AB &emc>, + <&mc TEGRA20_MC_DISPLAY0BB &emc>, + <&mc TEGRA20_MC_DISPLAY0CB &emc>, + <&mc TEGRA20_MC_DISPLAYHCB &emc>; + interconnect-names = "wina", + "winb", + "winc", + "cursor"; + rgb { status = "disabled"; }; -- cgit v1.2.3 From 35266255d61c777abd69c2faaa44c92b5a0483c2 Mon Sep 17 00:00:00 2001 From: Ido Schimmel Date: Wed, 4 Nov 2020 15:30:37 +0200 Subject: netdevsim: Add devlink resource for nexthops The Spectrum ASIC has a dedicated table where nexthops (i.e., adjacency entries) are populated. The size of this table can be controlled via devlink-resource. Add such a resource to netdevsim so that its occupancy will reflect the number of nexthop objects currently programmed to the device. By limiting the size of the resource, error paths could be exercised and tested. Example output: # devlink resource show netdevsim/netdevsim10 netdevsim/netdevsim10: name IPv4 size unlimited unit entry size_min 0 size_max unlimited size_gran 1 dpipe_tables none resources: name fib size unlimited occ 4 unit entry size_min 0 size_max unlimited size_gran 1 dpipe_tables none name fib-rules size unlimited occ 3 unit entry size_min 0 size_max unlimited size_gran 1 dpipe_tables none name IPv6 size unlimited unit entry size_min 0 size_max unlimited size_gran 1 dpipe_tables none resources: name fib size unlimited occ 1 unit entry size_min 0 size_max unlimited size_gran 1 dpipe_tables none name fib-rules size unlimited occ 2 unit entry size_min 0 size_max unlimited size_gran 1 dpipe_tables none name nexthops size unlimited occ 0 unit entry size_min 0 size_max unlimited size_gran 1 dpipe_tables none Signed-off-by: Ido Schimmel Signed-off-by: Jakub Kicinski --- Documentation/networking/devlink/netdevsim.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/networking/devlink/netdevsim.rst b/Documentation/networking/devlink/netdevsim.rst index 2a266b7e7b38..02c2d20dc673 100644 --- a/Documentation/networking/devlink/netdevsim.rst +++ b/Documentation/networking/devlink/netdevsim.rst @@ -46,7 +46,7 @@ Resources ========= The ``netdevsim`` driver exposes resources to control the number of FIB -entries and FIB rule entries that the driver will allow. +entries, FIB rule entries and nexthops that the driver will allow. .. code:: shell @@ -54,6 +54,7 @@ entries and FIB rule entries that the driver will allow. $ devlink resource set netdevsim/netdevsim0 path /IPv4/fib-rules size 16 $ devlink resource set netdevsim/netdevsim0 path /IPv6/fib size 64 $ devlink resource set netdevsim/netdevsim0 path /IPv6/fib-rules size 16 + $ devlink resource set netdevsim/netdevsim0 path /nexthops size 16 $ devlink dev reload netdevsim/netdevsim0 Driver-specific Traps -- cgit v1.2.3 From 9bf6f7bab3bad4b30f108fca25aa5297dff0973f Mon Sep 17 00:00:00 2001 From: Thomas Gleixner Date: Tue, 3 Nov 2020 10:27:33 +0100 Subject: Documentation/io-mapping: Remove outdated blurb The implementation details in the documentation are outdated and not really helpful. Remove them. Signed-off-by: Thomas Gleixner Cc: Christoph Hellwig Cc: Andrew Morton Link: https://lore.kernel.org/r/20201103095858.734064977@linutronix.de --- Documentation/driver-api/io-mapping.rst | 22 ---------------------- 1 file changed, 22 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/io-mapping.rst b/Documentation/driver-api/io-mapping.rst index a966239f04e4..e33b88268554 100644 --- a/Documentation/driver-api/io-mapping.rst +++ b/Documentation/driver-api/io-mapping.rst @@ -73,25 +73,3 @@ for pages mapped with io_mapping_map_wc. At driver close time, the io_mapping object must be freed:: void io_mapping_free(struct io_mapping *mapping) - -Current Implementation -====================== - -The initial implementation of these functions uses existing mapping -mechanisms and so provides only an abstraction layer and no new -functionality. - -On 64-bit processors, io_mapping_create_wc calls ioremap_wc for the whole -range, creating a permanent kernel-visible mapping to the resource. The -map_atomic and map functions add the requested offset to the base of the -virtual address returned by ioremap_wc. - -On 32-bit processors with HIGHMEM defined, io_mapping_map_atomic_wc uses -kmap_atomic_pfn to map the specified page in an atomic fashion; -kmap_atomic_pfn isn't really supposed to be used with device pages, but it -provides an efficient mapping for this usage. - -On 32-bit processors without HIGHMEM defined, io_mapping_map_atomic_wc and -io_mapping_map_wc both use ioremap_wc, a terribly inefficient function which -performs an IPI to inform all processors about the new mapping. This results -in a significant performance penalty. -- cgit v1.2.3 From a043260740d5d6ec5be59c3fb595c719890a0b0b Mon Sep 17 00:00:00 2001 From: "Joel Fernandes (Google)" Date: Tue, 29 Sep 2020 15:29:28 -0400 Subject: docs: Update RCU's hotplug requirements with a bit about design The rcu_barrier() section of the "Hotplug CPU" section discusses deadlocks, however the description of deadlocks other than those involving rcu_barrier() is rather incomplete. This commit therefore continues the section by describing how RCU's design handles CPU hotplug in a deadlock-free way. Signed-off-by: Joel Fernandes (Google) Signed-off-by: Paul E. McKenney --- .../RCU/Design/Requirements/Requirements.rst | 49 +++++++++++++++++----- 1 file changed, 39 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst index 1ae79a10a8de..8807985a9c35 100644 --- a/Documentation/RCU/Design/Requirements/Requirements.rst +++ b/Documentation/RCU/Design/Requirements/Requirements.rst @@ -1929,16 +1929,45 @@ The Linux-kernel CPU-hotplug implementation has notifiers that are used to allow the various kernel subsystems (including RCU) to respond appropriately to a given CPU-hotplug operation. Most RCU operations may be invoked from CPU-hotplug notifiers, including even synchronous -grace-period operations such as ``synchronize_rcu()`` and -``synchronize_rcu_expedited()``. - -However, all-callback-wait operations such as ``rcu_barrier()`` are also -not supported, due to the fact that there are phases of CPU-hotplug -operations where the outgoing CPU's callbacks will not be invoked until -after the CPU-hotplug operation ends, which could also result in -deadlock. Furthermore, ``rcu_barrier()`` blocks CPU-hotplug operations -during its execution, which results in another type of deadlock when -invoked from a CPU-hotplug notifier. +grace-period operations such as (``synchronize_rcu()`` and +``synchronize_rcu_expedited()``). However, these synchronous operations +do block and therefore cannot be invoked from notifiers that execute via +``stop_machine()``, specifically those between the ``CPUHP_AP_OFFLINE`` +and ``CPUHP_AP_ONLINE`` states. + +In addition, all-callback-wait operations such as ``rcu_barrier()`` may +not be invoked from any CPU-hotplug notifier. This restriction is due +to the fact that there are phases of CPU-hotplug operations where the +outgoing CPU's callbacks will not be invoked until after the CPU-hotplug +operation ends, which could also result in deadlock. Furthermore, +``rcu_barrier()`` blocks CPU-hotplug operations during its execution, +which results in another type of deadlock when invoked from a CPU-hotplug +notifier. + +Finally, RCU must avoid deadlocks due to interaction between hotplug, +timers and grace period processing. It does so by maintaining its own set +of books that duplicate the centrally maintained ``cpu_online_mask``, +and also by reporting quiescent states explicitly when a CPU goes +offline. This explicit reporting of quiescent states avoids any need +for the force-quiescent-state loop (FQS) to report quiescent states for +offline CPUs. However, as a debugging measure, the FQS loop does splat +if offline CPUs block an RCU grace period for too long. + +An offline CPU's quiescent state will be reported either: +1. As the CPU goes offline using RCU's hotplug notifier (``rcu_report_dead()``). +2. When grace period initialization (``rcu_gp_init()``) detects a + race either with CPU offlining or with a task unblocking on a leaf + ``rcu_node`` structure whose CPUs are all offline. + +The CPU-online path (``rcu_cpu_starting()``) should never need to report +a quiescent state for an offline CPU. However, as a debugging measure, +it does emit a warning if a quiescent state was not already reported +for that CPU. + +During the checking/modification of RCU's hotplug bookkeeping, the +corresponding CPU's leaf node lock is held. This avoids race conditions +between RCU's hotplug notifier hooks, the grace period initialization +code, and the FQS loop, all of which refer to or modify this bookkeeping. Scheduler and RCU ~~~~~~~~~~~~~~~~~ -- cgit v1.2.3 From a1b9dbb72b7f39eeaa2fb5bd5cc619679985876e Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Tue, 6 Oct 2020 15:21:32 +0200 Subject: docs: RCU: Requirements.rst: Fix a list block As warned by Sphinx: .../Documentation/RCU/Design/Requirements/Requirements.rst:1959: WARNING: Unexpected indentation. The list block is missing a space before it, making Sphinx to get it wrong. This commit therefore adds the missing space characters. Fixes: 2a721e5f0b2c ("docs: Update RCU's hotplug requirements with a bit about design") Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Paul E. McKenney --- Documentation/RCU/Design/Requirements/Requirements.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst index 8807985a9c35..e8c84fcc0507 100644 --- a/Documentation/RCU/Design/Requirements/Requirements.rst +++ b/Documentation/RCU/Design/Requirements/Requirements.rst @@ -1954,6 +1954,7 @@ offline CPUs. However, as a debugging measure, the FQS loop does splat if offline CPUs block an RCU grace period for too long. An offline CPU's quiescent state will be reported either: + 1. As the CPU goes offline using RCU's hotplug notifier (``rcu_report_dead()``). 2. When grace period initialization (``rcu_gp_init()``) detects a race either with CPU offlining or with a task unblocking on a leaf -- cgit v1.2.3 From c386e29d43728778ddd642fa73cc582bee684171 Mon Sep 17 00:00:00 2001 From: Hui Su Date: Thu, 15 Oct 2020 22:13:34 +0800 Subject: docs/rcu: Update the call_rcu() API This commit updates the documented API of call_rcu() to use the rcu_callback_t typedef instead of the open-coded function definition. Signed-off-by: Hui Su Signed-off-by: Paul E. McKenney --- Documentation/RCU/whatisRCU.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/RCU/whatisRCU.rst b/Documentation/RCU/whatisRCU.rst index fb3ff76c3e73..1a4723f48bd9 100644 --- a/Documentation/RCU/whatisRCU.rst +++ b/Documentation/RCU/whatisRCU.rst @@ -497,8 +497,7 @@ long -- there might be other high-priority work to be done. In such cases, one uses call_rcu() rather than synchronize_rcu(). The call_rcu() API is as follows:: - void call_rcu(struct rcu_head * head, - void (*func)(struct rcu_head *head)); + void call_rcu(struct rcu_head *head, rcu_callback_t func); This function invokes func(head) after a grace period has elapsed. This invocation might happen from either softirq or process context, -- cgit v1.2.3 From d8566f15da9b1e51fd35f24321ec133095e02d06 Mon Sep 17 00:00:00 2001 From: Fox Chen Date: Wed, 9 Sep 2020 14:53:40 +0800 Subject: docs/memory-barriers.txt: Fix a typo in CPU MEMORY BARRIERS section Commit 39323c6 ("smp_mb__{before,after}_atomic(): update Documentation") has a typo in CPU MEORY BARRIERS section: "RMW functions that do not imply are memory barrier are ..." should be "RMW functions that do not imply a memory barrier are ...". This patch fixes this typo. Signed-off-by: Fox Chen Acked-by: Will Deacon Signed-off-by: Paul E. McKenney --- Documentation/memory-barriers.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 17c8e0c2deb4..7367ada13208 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -1870,7 +1870,7 @@ There are some more advanced barrier functions: These are for use with atomic RMW functions that do not imply memory barriers, but where the code needs a memory barrier. Examples for atomic - RMW functions that do not imply are memory barrier are e.g. add, + RMW functions that do not imply a memory barrier are e.g. add, subtract, (failed) conditional operations, _relaxed functions, but not atomic_read or atomic_set. A common example where a memory barrier may be required is when atomic ops are used for reference -- cgit v1.2.3 From a44ad6835da52fdf4df2e482f45a167336555121 Mon Sep 17 00:00:00 2001 From: Harshad Shirwadkar Date: Thu, 5 Nov 2020 19:58:50 -0800 Subject: ext4: describe fast_commit feature flags Fast commit feature has flags in the file system as well in JBD2. The meaning of fast commit feature flags can get confusing. Update docs and code to add more documentation about it. Suggested-by: Jan Kara Signed-off-by: Harshad Shirwadkar Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20201106035911.1942128-2-harshadshirwadkar@gmail.com Signed-off-by: Theodore Ts'o --- Documentation/filesystems/ext4/journal.rst | 6 ++++++ Documentation/filesystems/ext4/super.rst | 7 +++++++ 2 files changed, 13 insertions(+) (limited to 'Documentation') diff --git a/Documentation/filesystems/ext4/journal.rst b/Documentation/filesystems/ext4/journal.rst index 805a1e9ea3a5..849d5b119eb8 100644 --- a/Documentation/filesystems/ext4/journal.rst +++ b/Documentation/filesystems/ext4/journal.rst @@ -256,6 +256,10 @@ which is 1024 bytes long: - s\_padding2 - * - 0x54 + - \_\_be32 + - s\_num\_fc\_blocks + - Number of fast commit blocks in the journal. + * - 0x58 - \_\_u32 - s\_padding[42] - @@ -310,6 +314,8 @@ The journal incompat features are any combination of the following: - This journal uses v3 of the checksum on-disk format. This is the same as v2, but the journal block tag size is fixed regardless of the size of block numbers. (JBD2\_FEATURE\_INCOMPAT\_CSUM\_V3) + * - 0x20 + - Journal has fast commit blocks. (JBD2\_FEATURE\_INCOMPAT\_FAST\_COMMIT) .. _jbd2_checksum_type: diff --git a/Documentation/filesystems/ext4/super.rst b/Documentation/filesystems/ext4/super.rst index 93e55d7c1d40..2eb1ab20498d 100644 --- a/Documentation/filesystems/ext4/super.rst +++ b/Documentation/filesystems/ext4/super.rst @@ -596,6 +596,13 @@ following: - Sparse Super Block, v2. If this flag is set, the SB field s\_backup\_bgs points to the two block groups that contain backup superblocks (COMPAT\_SPARSE\_SUPER2). + * - 0x400 + - Fast commits supported. Although fast commits blocks are + backward incompatible, fast commit blocks are not always + present in the journal. If fast commit blocks are present in + the journal, JBD2 incompat feature + (JBD2\_FEATURE\_INCOMPAT\_FAST\_COMMIT) gets + set (COMPAT\_FAST\_COMMIT). .. _super_incompat: -- cgit v1.2.3 From 37e0a30e94f1aa25f16b403dfabb64e0b806de0b Mon Sep 17 00:00:00 2001 From: Harshad Shirwadkar Date: Thu, 5 Nov 2020 19:58:56 -0800 Subject: jbd2: drop jbd2_fc_init documentation Now that jbd2_fc_init is dropped, drop its docs too. Signed-off-by: Harshad Shirwadkar Link: https://lore.kernel.org/r/20201106035911.1942128-8-harshadshirwadkar@gmail.com Signed-off-by: Theodore Ts'o --- Documentation/filesystems/journalling.rst | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/journalling.rst b/Documentation/filesystems/journalling.rst index 5a5f70b4063e..e18f90ffc6fd 100644 --- a/Documentation/filesystems/journalling.rst +++ b/Documentation/filesystems/journalling.rst @@ -136,10 +136,8 @@ Fast commits ~~~~~~~~~~~~ JBD2 to also allows you to perform file-system specific delta commits known as -fast commits. In order to use fast commits, you first need to call -:c:func:`jbd2_fc_init` and tell how many blocks at the end of journal -area should be reserved for fast commits. Along with that, you will also need -to set following callbacks that perform correspodning work: +fast commits. In order to use fast commits, you will need to set following +callbacks that perform correspodning work: `journal->j_fc_cleanup_cb`: Cleanup function called after every full commit and fast commit. -- cgit v1.2.3 From 77581df8639faf28ae52fea170e48cdf9870468a Mon Sep 17 00:00:00 2001 From: Sven Eckelmann Date: Thu, 15 Oct 2020 15:15:00 +0200 Subject: dt: bindings: add new dt entry for ath11k calibration variant The bus + qmi-chip-id + qmi-board-id is not enough to identify the correct board data file on IPQ6018 based devices. Multiple different boards share the same values. Only the original reference designs can currently be identified and loaded from the board-2.bin. But these will not result in the correct calibration data when combined with the pre-calibration data from the device. An additional "variant" information has to be provided to select the correct board data for a design which was modified by an ODM. This follows the same approach as ath10k. Signed-off-by: Sven Eckelmann Reviewed-by: Rob Herring Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20201015131501.1939685-1-sven@narfation.org --- Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml index 4b365c9d9378..6af999191559 100644 --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml @@ -144,6 +144,12 @@ properties: * reg * reg-names + qcom,ath11k-calibration-variant: + $ref: /schemas/types.yaml#/definitions/string + description: + string to uniquely identify variant of the calibration data in the + board-2.bin for designs with colliding bus and device specific ids + required: - compatible - reg -- cgit v1.2.3 From b6e95788fde8c9bc9da729102085dd36a5a0cda6 Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Fri, 30 Oct 2020 18:59:18 +0200 Subject: irqdomain: Introduce irq_domain_create_legacy() API Introduce irq_domain_create_legacy() API which is functional equivalent to the existing irq_domain_add_legacy(), but takes a pointer to the struct fwnode_handle as a parameter. This is useful for non OF systems. Signed-off-by: Andy Shevchenko Signed-off-by: Thomas Gleixner Reviewed-by: Rafael J. Wysocki Link: https://lore.kernel.org/r/20201030165919.86234-5-andriy.shevchenko@linux.intel.com --- Documentation/core-api/irq/irq-domain.rst | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/core-api/irq/irq-domain.rst b/Documentation/core-api/irq/irq-domain.rst index 096db12f32d5..a77c24c27f7b 100644 --- a/Documentation/core-api/irq/irq-domain.rst +++ b/Documentation/core-api/irq/irq-domain.rst @@ -147,6 +147,7 @@ Legacy irq_domain_add_simple() irq_domain_add_legacy() irq_domain_add_legacy_isa() + irq_domain_create_legacy() The Legacy mapping is a special case for drivers that already have a range of irq_descs allocated for the hwirqs. It is used when the @@ -185,6 +186,11 @@ that the driver using the simple domain call irq_create_mapping() before any irq_find_mapping() since the latter will actually work for the static IRQ assignment case. +irq_domain_add_legacy() and irq_domain_create_legacy() are functionally +equivalent, except for the first argument is different - the former +accepts an Open Firmware specific 'struct device_node', while the latter +accepts a more general abstraction 'struct fwnode_handle'. + Hierarchy IRQ domain -------------------- -- cgit v1.2.3 From 25d7361ff96abfbcca6e3233cc39f5a80c92543d Mon Sep 17 00:00:00 2001 From: Dmitry Baryshkov Date: Mon, 2 Nov 2020 04:14:34 +0300 Subject: dt-bindings: display: bridge: Add documentation for LT9611UXC Lontium LT9611UXC is a DSI to HDMI bridge which supports 2 DSI ports and I2S port as input and one HDMI port as output. The LT9611UXC chip is handled by a separate driver, but the bindings used are fully compatible with the LT9611 chip, so let's reuse the lt9611.yaml schema. Signed-off-by: Dmitry Baryshkov Acked-by: Vinod Koul Acked-by: Sam Ravnborg Acked-by: Rob Herring Reviewed-by: Bjorn Andersson Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20201102011435.1100930-2-dmitry.baryshkov@linaro.org --- Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml index d60208359234..7a1c89b995e2 100644 --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml @@ -4,18 +4,19 @@ $id: http://devicetree.org/schemas/display/bridge/lontium,lt9611.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Lontium LT9611 2 Port MIPI to HDMI Bridge +title: Lontium LT9611(UXC) 2 Port MIPI to HDMI Bridge maintainers: - Vinod Koul description: | - The LT9611 is a bridge device which converts DSI to HDMI + The LT9611 and LT9611UXC are bridge devices which convert DSI to HDMI properties: compatible: enum: - lontium,lt9611 + - lontium,lt9611uxc reg: maxItems: 1 -- cgit v1.2.3 From ca3407a1caa1c7e6a499b133f8b456ed637760ce Mon Sep 17 00:00:00 2001 From: Fabien Parent Date: Fri, 23 Oct 2020 15:31:26 +0200 Subject: dt-bindings: display: mediatek: disp: add documentation for MT8167 SoC Add binding documentation for the MT8167 SoC Signed-off-by: Fabien Parent Acked-by: Rob Herring Signed-off-by: Chun-Kuang Hu --- Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt index 121220745d46..33977e15bebd 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt @@ -43,7 +43,7 @@ Required properties (all function blocks): "mediatek,-dpi" - DPI controller, see mediatek,dpi.txt "mediatek,-disp-mutex" - display mutex "mediatek,-disp-od" - overdrive - the supported chips are mt2701, mt7623, mt2712 and mt8173. + the supported chips are mt2701, mt7623, mt2712, mt8167 and mt8173. - reg: Physical base address and length of the function block register space - interrupts: The interrupt signal from the function block (required, except for merge and split function blocks). @@ -59,7 +59,7 @@ Required properties (DMA function blocks): "mediatek,-disp-ovl" "mediatek,-disp-rdma" "mediatek,-disp-wdma" - the supported chips are mt2701 and mt8173. + the supported chips are mt2701, mt8167 and mt8173. - larb: Should contain a phandle pointing to the local arbiter device as defined in Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.txt - iommus: Should point to the respective IOMMU block with master port as -- cgit v1.2.3 From f8ae7bbec726f4d09ca19ecea45ea147b8801e10 Mon Sep 17 00:00:00 2001 From: Xie He Date: Wed, 4 Nov 2020 23:34:34 -0800 Subject: net: x25_asy: Delete the x25_asy driver This driver transports LAPB (X.25 link layer) frames over TTY links. I can safely say that this driver has no actual user because it was not working at all until: commit 8fdcabeac398 ("drivers/net/wan/x25_asy: Fix to make it work") The code in its current state still has problems: 1. The uses of "struct x25_asy" in x25_asy_unesc (when receiving) and in x25_asy_write_wakeup (when sending) are not protected by locks against x25_asy_change_mtu's changing of the transmitting/receiving buffers. Also, all "netif_running" checks in this driver are not protected by locks against the ndo_stop function. 2. The driver stops all TTY read/write when the netif is down. I think this is not right because this may cause the last outgoing frame before the netif goes down to be incompletely transmitted, and the first incoming frame after the netif goes up to be incompletely received. And there may also be other problems. I was planning to fix these problems but after recent discussions about deleting other old networking code, I think we may just delete this driver, too. Signed-off-by: Xie He Acked-by: Martin Schiller Link: https://lore.kernel.org/r/20201105073434.429307-1-xie.he.0141@gmail.com Signed-off-by: Jakub Kicinski --- Documentation/process/magic-number.rst | 1 - Documentation/translations/it_IT/process/magic-number.rst | 1 - Documentation/translations/zh_CN/process/magic-number.rst | 1 - 3 files changed, 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/process/magic-number.rst b/Documentation/process/magic-number.rst index eee9b44553b3..e02ff5ffb653 100644 --- a/Documentation/process/magic-number.rst +++ b/Documentation/process/magic-number.rst @@ -84,7 +84,6 @@ PPP_MAGIC 0x5002 ppp ``include/linux/ SSTATE_MAGIC 0x5302 serial_state ``include/linux/serial.h`` SLIP_MAGIC 0x5302 slip ``drivers/net/slip.h`` STRIP_MAGIC 0x5303 strip ``drivers/net/strip.c`` -X25_ASY_MAGIC 0x5303 x25_asy ``drivers/net/x25_asy.h`` SIXPACK_MAGIC 0x5304 sixpack ``drivers/net/hamradio/6pack.h`` AX25_MAGIC 0x5316 ax_disp ``drivers/net/mkiss.h`` TTY_MAGIC 0x5401 tty_struct ``include/linux/tty.h`` diff --git a/Documentation/translations/it_IT/process/magic-number.rst b/Documentation/translations/it_IT/process/magic-number.rst index 783e0de314a0..0243d32a0b59 100644 --- a/Documentation/translations/it_IT/process/magic-number.rst +++ b/Documentation/translations/it_IT/process/magic-number.rst @@ -90,7 +90,6 @@ PPP_MAGIC 0x5002 ppp ``include/linux/ SSTATE_MAGIC 0x5302 serial_state ``include/linux/serial.h`` SLIP_MAGIC 0x5302 slip ``drivers/net/slip.h`` STRIP_MAGIC 0x5303 strip ``drivers/net/strip.c`` -X25_ASY_MAGIC 0x5303 x25_asy ``drivers/net/x25_asy.h`` SIXPACK_MAGIC 0x5304 sixpack ``drivers/net/hamradio/6pack.h`` AX25_MAGIC 0x5316 ax_disp ``drivers/net/mkiss.h`` TTY_MAGIC 0x5401 tty_struct ``include/linux/tty.h`` diff --git a/Documentation/translations/zh_CN/process/magic-number.rst b/Documentation/translations/zh_CN/process/magic-number.rst index e4c225996af0..de182bf4191c 100644 --- a/Documentation/translations/zh_CN/process/magic-number.rst +++ b/Documentation/translations/zh_CN/process/magic-number.rst @@ -73,7 +73,6 @@ PPP_MAGIC 0x5002 ppp ``include/linux/ SSTATE_MAGIC 0x5302 serial_state ``include/linux/serial.h`` SLIP_MAGIC 0x5302 slip ``drivers/net/slip.h`` STRIP_MAGIC 0x5303 strip ``drivers/net/strip.c`` -X25_ASY_MAGIC 0x5303 x25_asy ``drivers/net/x25_asy.h`` SIXPACK_MAGIC 0x5304 sixpack ``drivers/net/hamradio/6pack.h`` AX25_MAGIC 0x5316 ax_disp ``drivers/net/mkiss.h`` TTY_MAGIC 0x5401 tty_struct ``include/linux/tty.h`` -- cgit v1.2.3 From 62dbf80fc581a8eed7288ed7aca24446054eb616 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= Date: Mon, 2 Nov 2020 16:06:58 +0100 Subject: dt-bindings: arm: rockchip: Add Kobol Helios64 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Document the new board by Kobol introduced recently in rockchip/rk3399-kobol-helios64.dts. Signed-off-by: Uwe Kleine-König Acked-by: Rob Herring Link: https://lore.kernel.org/r/20201102150658.167161-1-uwe@kleine-koenig.org Signed-off-by: Heiko Stuebner --- Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 65b4cc2c63f7..70fa4d98db56 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -381,6 +381,11 @@ properties: - khadas,edge-v - const: rockchip,rk3399 + - description: Kobol Helios64 + items: + - const: kobol,helios64 + - const: rockchip,rk3399 + - description: Mecer Xtreme Mini S6 items: - const: mecer,xms6 -- cgit v1.2.3 From 9273cf7d3942eaaf8b6cb6e614adbd475dc6e9b2 Mon Sep 17 00:00:00 2001 From: Jitao Shi Date: Thu, 17 Sep 2020 15:33:05 +0800 Subject: dt-bindings: display: mediatek: convert the dpi bindings to yaml Convert display/mediatek/mediatek,dpi.txt to display/mediatek/mediatek,dpi.yaml and remove the old text bindings. Signed-off-by: Jitao Shi Reviewed-by: Rob Herring Signed-off-by: Chun-Kuang Hu --- .../bindings/display/mediatek/mediatek,dpi.txt | 42 ---------- .../bindings/display/mediatek/mediatek,dpi.yaml | 98 ++++++++++++++++++++++ 2 files changed, 98 insertions(+), 42 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt deleted file mode 100644 index dc1ebd13cc88..000000000000 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt +++ /dev/null @@ -1,42 +0,0 @@ -Mediatek DPI Device -=================== - -The Mediatek DPI function block is a sink of the display subsystem and -provides 8-bit RGB/YUV444 or 8/10/10-bit YUV422 pixel data on a parallel -output bus. - -Required properties: -- compatible: "mediatek,-dpi" - the supported chips are mt2701, mt7623, mt8173 and mt8183. -- reg: Physical base address and length of the controller's registers -- interrupts: The interrupt signal from the function block. -- clocks: device clocks - See Documentation/devicetree/bindings/clock/clock-bindings.txt for details. -- clock-names: must contain "pixel", "engine", and "pll" -- port: Output port node with endpoint definitions as described in - Documentation/devicetree/bindings/graph.txt. This port should be connected - to the input port of an attached HDMI or LVDS encoder chip. - -Optional properties: -- pinctrl-names: Contain "default" and "sleep". - -Example: - -dpi0: dpi@1401d000 { - compatible = "mediatek,mt8173-dpi"; - reg = <0 0x1401d000 0 0x1000>; - interrupts = ; - clocks = <&mmsys CLK_MM_DPI_PIXEL>, - <&mmsys CLK_MM_DPI_ENGINE>, - <&apmixedsys CLK_APMIXED_TVDPLL>; - clock-names = "pixel", "engine", "pll"; - pinctrl-names = "default", "sleep"; - pinctrl-0 = <&dpi_pin_func>; - pinctrl-1 = <&dpi_pin_idle>; - - port { - dpi0_out: endpoint { - remote-endpoint = <&hdmi0_in>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml new file mode 100644 index 000000000000..6cdb734c91a9 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml @@ -0,0 +1,98 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,dpi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: mediatek DPI Controller Device Tree Bindings + +maintainers: + - CK Hu + - Jitao shi + +description: | + The Mediatek DPI function block is a sink of the display subsystem and + provides 8-bit RGB/YUV444 or 8/10/10-bit YUV422 pixel data on a parallel + output bus. + +properties: + compatible: + enum: + - mediatek,mt2701-dpi + - mediatek,mt7623-dpi + - mediatek,mt8173-dpi + - mediatek,mt8183-dpi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Pixel Clock + - description: Engine Clock + - description: DPI PLL + + clock-names: + items: + - const: pixel + - const: engine + - const: pll + + pinctrl-0: true + pinctrl-1: true + + pinctrl-names: + items: + - const: default + - const: sleep + + port: + type: object + description: + Output port node with endpoint definitions as described in + Documentation/devicetree/bindings/graph.txt. This port should be connected + to the input port of an attached HDMI or LVDS encoder chip. + + properties: + endpoint: + type: object + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - port + +additionalProperties: false + +examples: + - | + #include + #include + #include + #include + dpi0: dpi@1401d000 { + compatible = "mediatek,mt8173-dpi"; + reg = <0x1401d000 0x1000>; + interrupts = ; + clocks = <&mmsys CLK_MM_DPI_PIXEL>, + <&mmsys CLK_MM_DPI_ENGINE>, + <&apmixedsys CLK_APMIXED_TVDPLL>; + clock-names = "pixel", "engine", "pll"; + pinctrl-names = "default", "sleep"; + pinctrl-0 = <&dpi_pin_func>; + pinctrl-1 = <&dpi_pin_idle>; + + port { + dpi0_out: endpoint { + remote-endpoint = <&hdmi0_in>; + }; + }; + }; + +... -- cgit v1.2.3 From 3d20267abc789e6753fce60019bb5945fe8a74f3 Mon Sep 17 00:00:00 2001 From: Peter Xu Date: Wed, 30 Sep 2020 21:20:31 -0400 Subject: KVM: Documentation: Update entry for KVM_X86_SET_MSR_FILTER It should be an accident when rebase, since we've already have section 8.25 (which is KVM_CAP_S390_DIAG318). Fix the number. Signed-off-by: Peter Xu Message-Id: <20201001012044.5151-2-peterx@redhat.com> Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/api.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 36d5f1f3c6dd..e53e3bd99b2c 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -6367,7 +6367,7 @@ accesses that would usually trigger a #GP by KVM into the guest will instead get bounced to user space through the KVM_EXIT_X86_RDMSR and KVM_EXIT_X86_WRMSR exit notifications. -8.25 KVM_X86_SET_MSR_FILTER +8.27 KVM_X86_SET_MSR_FILTER --------------------------- :Architectures: x86 -- cgit v1.2.3 From 177158e5b1a558a28b9ce6b27a14bea588a6f2fb Mon Sep 17 00:00:00 2001 From: Peter Xu Date: Fri, 23 Oct 2020 14:33:46 -0400 Subject: KVM: Documentation: Update entry for KVM_CAP_ENFORCE_PV_CPUID Should be squashed into 66570e966dd9cb4f. Signed-off-by: Peter Xu Message-Id: <20201023183358.50607-3-peterx@redhat.com> Signed-off-by: Paolo Bonzini --- Documentation/virt/kvm/api.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index e53e3bd99b2c..e00a66d72372 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -6381,8 +6381,7 @@ In combination with KVM_CAP_X86_USER_SPACE_MSR, this allows user space to trap and emulate MSRs that are outside of the scope of KVM as well as limit the attack surface on KVM's MSR emulation code. - -8.26 KVM_CAP_ENFORCE_PV_CPUID +8.28 KVM_CAP_ENFORCE_PV_CPUID ----------------------------- Architectures: x86 -- cgit v1.2.3 From 4c1e054322da99cbfd293a5fddf283f2fdb3e2d0 Mon Sep 17 00:00:00 2001 From: Alexandru Gagniuc Date: Tue, 20 Oct 2020 17:14:59 -0500 Subject: dt-bindings: display: sii902x: Add supply bindings The sii902x chip family requires IO and core voltages to reach the correct voltage before chip initialization. Add binding for describing the two supplies. Signed-off-by: Alexandru Gagniuc Acked-by: Rob Herring Signed-off-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20201020221501.260025-3-mr.nuke.me@gmail.com --- Documentation/devicetree/bindings/display/bridge/sii902x.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/display/bridge/sii902x.txt b/Documentation/devicetree/bindings/display/bridge/sii902x.txt index 0d1db3f9da84..02c21b584741 100644 --- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt +++ b/Documentation/devicetree/bindings/display/bridge/sii902x.txt @@ -8,6 +8,8 @@ Optional properties: - interrupts: describe the interrupt line used to inform the host about hotplug events. - reset-gpios: OF device-tree gpio specification for RST_N pin. + - iovcc-supply: I/O Supply Voltage (1.8V or 3.3V) + - cvcc12-supply: Digital Core Supply Voltage (1.2V) HDMI audio properties: - #sound-dai-cells: <0> or <1>. <0> if only i2s or spdif pin @@ -54,6 +56,8 @@ Example: compatible = "sil,sii9022"; reg = <0x39>; reset-gpios = <&pioA 1 0>; + iovcc-supply = <&v3v3_hdmi>; + cvcc12-supply = <&v1v2_hdmi>; #sound-dai-cells = <0>; sil,i2s-data-lanes = < 0 1 2 >; -- cgit v1.2.3 From 3079188f821cfbdbb0b12f668335931a87eb14c6 Mon Sep 17 00:00:00 2001 From: Cristian Pop Date: Mon, 28 Sep 2020 12:09:56 +0300 Subject: iio:Documentation: Add documentation for label channel attribute If a label is defined for this channel add that to the channel specific attributes. This is useful for userspace to be able to identify an individual channel. Signed-off-by: Cristian Pop Link: https://lore.kernel.org/r/20200928090959.88842-2-cristian.pop@analog.com Signed-off-by: Jonathan Cameron --- Documentation/ABI/testing/sysfs-bus-iio | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index a9d51810a3ba..4a72ee43dee8 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -1715,6 +1715,16 @@ Description: Raw counter device counters direction for channel Y. +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_label +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_label +KernelVersion: 5.8 +Contact: linux-iio@vger.kernel.org +Description: + Optional symbolic label to a device channel. + If a label is defined for this channel add that to the channel + specific attributes. This is useful for userspace to be able to + better identify an individual channel. + What: /sys/bus/iio/devices/iio:deviceX/in_phaseY_raw KernelVersion: 4.18 Contact: linux-iio@vger.kernel.org -- cgit v1.2.3 From 7d4156ddf1b838b100a037d02d4bf15ccb3ccd26 Mon Sep 17 00:00:00 2001 From: Cristian Pop Date: Mon, 28 Sep 2020 12:09:58 +0300 Subject: dt-bindings:iio:adc:adi,ad7768-1: Add documentation for channel label Optional attribute for better identification of the channels. Signed-off-by: Cristian Pop Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20200928090959.88842-4-cristian.pop@analog.com Signed-off-by: Jonathan Cameron --- .../devicetree/bindings/iio/adc/adi,ad7768-1.yaml | 32 ++++++++++++++++++++++ 1 file changed, 32 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml index d3733ad8785a..6be43bf5c1e0 100644 --- a/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7768-1.yaml @@ -29,6 +29,12 @@ properties: interrupts: maxItems: 1 + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + vref-supply: description: ADC reference voltage supply @@ -61,6 +67,24 @@ required: - spi-cpha - adi,sync-in-gpios +patternProperties: + "^channel@([0-9]|1[0-5])$": + type: object + description: | + Represents the external channels which are connected to the device. + + properties: + reg: + description: | + The channel number. + + label: + description: | + Unique name to identify which channel this is. + required: + - reg + additionalProperties: false + additionalProperties: false examples: @@ -84,6 +108,14 @@ examples: reset-gpios = <&gpio 27 GPIO_ACTIVE_LOW>; clocks = <&ad7768_mclk>; clock-names = "mclk"; + + #address-cells = <1>; + #size-cells = <0>; + + channel@0 { + reg = <0>; + label = "channel_0"; + }; }; }; ... -- cgit v1.2.3 From 7f79711533a96b02e1e24e2e36a29b08734e36e2 Mon Sep 17 00:00:00 2001 From: Cristian Pop Date: Mon, 28 Sep 2020 12:09:59 +0300 Subject: dt-bindings:iio:adc:adc.txt: Add documentation for channel label attribute Optional attribute for better identification of the channels. Signed-off-by: Cristian Pop Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20200928090959.88842-5-cristian.pop@analog.com Signed-off-by: Jonathan Cameron --- Documentation/devicetree/bindings/iio/adc/adc.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/adc/adc.txt b/Documentation/devicetree/bindings/iio/adc/adc.txt index 5bbaa330a250..4b37575bbddc 100644 --- a/Documentation/devicetree/bindings/iio/adc/adc.txt +++ b/Documentation/devicetree/bindings/iio/adc/adc.txt @@ -5,18 +5,24 @@ Optional properties for child nodes: - diff-channels : Differential channels muxed for this ADC. The first value specifies the positive input pin, the second value the negative input pin. +- reg: The channel number. +- label: Unique name to identify which channel this is. Example: adc@0 { compatible = "some,adc"; ... channel@0 { + reg = <0>; + label = "channel_0_name"; bipolar; diff-channels = <0 1>; ... }; channel@1 { + reg = <1>; + label = "channel_1_name"; diff-channels = <2 3>; ... }; -- cgit v1.2.3 From 396cd5092caf8daaa72139c81f16d4aa1ecd560d Mon Sep 17 00:00:00 2001 From: Gene Chen Date: Tue, 20 Oct 2020 16:07:45 +0800 Subject: dt-bindings: iio: adc: add bindings doc for MT6360 ADC This change adds the binding doc for the MT6360 ADC. Signed-off-by: Gene Chen Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/1603181267-15610-2-git-send-email-gene.chen.richtek@gmail.com Signed-off-by: Jonathan Cameron --- .../bindings/iio/adc/mediatek,mt6360-adc.yaml | 31 ++++++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 Documentation/devicetree/bindings/iio/adc/mediatek,mt6360-adc.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iio/adc/mediatek,mt6360-adc.yaml b/Documentation/devicetree/bindings/iio/adc/mediatek,mt6360-adc.yaml new file mode 100644 index 000000000000..db4e3613c104 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/mediatek,mt6360-adc.yaml @@ -0,0 +1,31 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/adc/mediatek,mt6360-adc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek MT6360 and similar ADCs + +maintainers: + - Gene Chen + +properties: + compatible: + const: mediatek,mt6360-adc + + "#io-channel-cells": + const: 1 + +required: + - compatible + - "#io-channel-cells" + +additionalProperties: false + +examples: + - | + adc { + compatible = "mediatek,mt6360-adc"; + #io-channel-cells = <1>; + }; +... -- cgit v1.2.3 From d4686c52a20b51f539d8a5d09807441af490602b Mon Sep 17 00:00:00 2001 From: Gene Chen Date: Tue, 20 Oct 2020 16:07:46 +0800 Subject: Documentation: ABI: testing: mt6360: Add ADC sysfs guideline Add ABI documentation for mt6360 ADC sysfs interfaces. Signed-off-by: Gene Chen Link: https://lore.kernel.org/r/1603181267-15610-3-git-send-email-gene.chen.richtek@gmail.com Signed-off-by: Jonathan Cameron --- Documentation/ABI/testing/sysfs-bus-iio-adc-mt6360 | 78 ++++++++++++++++++++++ 1 file changed, 78 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-adc-mt6360 (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-mt6360 b/Documentation/ABI/testing/sysfs-bus-iio-adc-mt6360 new file mode 100644 index 000000000000..e5a7b1c7cca3 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-mt6360 @@ -0,0 +1,78 @@ +What: /sys/bus/iio/devices/iio:deviceX/in_voltage0_raw +KernelVersion: 5.8.0 +Contact: gene_chen@richtek.com +Description: + Indicated MT6360 USBID ADC which connected to connector ID pin. + Calculating with scale and offset returns voltage in uV + +What: /sys/bus/iio/devices/iio:deviceX/in_voltage1_raw +KernelVersion: 5.8.0 +Contact: gene_chen@richtek.com +Description: + Indicated MT6360 VBUS ADC with lower accuracy(+-75mA) + higher measure range(1~22mV) + Calculating with scale and offset returns voltage in uV + +What: /sys/bus/iio/devices/iio:deviceX/in_voltage2_raw +KernelVersion: 5.8.0 +Contact: gene_chen@richtek.com +Description: + Indicated MT6360 VBUS ADC with higher accuracy(+-30mA) + lower measure range(1~9.76V) + Calculating with scale and offset returns voltage in uV + +What: /sys/bus/iio/devices/iio:deviceX/in_voltage3_raw +KernelVersion: 5.8.0 +Contact: gene_chen@richtek.com +Description: + Indicated MT6360 VSYS ADC + Calculating with scale and offset returns voltage in uV + +What: /sys/bus/iio/devices/iio:deviceX/in_voltage4_raw +KernelVersion: 5.8.0 +Contact: gene_chen@richtek.com +Description: + Indicated MT6360 VBAT ADC + Calculating with scale and offset returns voltage in uV + +What: /sys/bus/iio/devices/iio:deviceX/in_current5_raw +KernelVersion: 5.8.0 +Contact: gene_chen@richtek.com +Description: + Indicated MT6360 IBUS ADC + Calculating with scale and offset returns voltage in uA + +What: /sys/bus/iio/devices/iio:deviceX/in_current6_raw +KernelVersion: 5.8.0 +Contact: gene_chen@richtek.com +Description: + Indicated MT6360 IBAT ADC + Calculating with scale and offset returns voltage in uA + +What: /sys/bus/iio/devices/iio:deviceX/in_current7_raw +KernelVersion: 5.8.0 +Contact: gene_chen@richtek.com +Description: + Indicated MT6360 CHG_VDDP ADC + Calculating with scale and offset returns voltage in uV + +What: /sys/bus/iio/devices/iio:deviceX/in_temp8_raw +KernelVersion: 5.8.0 +Contact: gene_chen@richtek.com +Description: + Indicated MT6360 IC junction temperature + Calculating with scale and offset returns temperature in degree + +What: /sys/bus/iio/devices/iio:deviceX/in_voltage9_raw +KernelVersion: 5.8.0 +Contact: gene_chen@richtek.com +Description: + Indicated MT6360 VREF_TS ADC + Calculating with scale and offset returns voltage in uV + +What: /sys/bus/iio/devices/iio:deviceX/in_voltage10_raw +KernelVersion: 5.8.0 +Contact: gene_chen@richtek.com +Description: + Indicated MT6360 TS ADC + Calculating with scale and offset returns voltage in uV -- cgit v1.2.3 From f36296e4ddfc003932c435cb16ca26fc87e43001 Mon Sep 17 00:00:00 2001 From: Jagan Teki Date: Tue, 29 Sep 2020 14:02:11 +0530 Subject: dt-bindings: arm: rockchip: Add Engicam PX30.Core EDIMM2.2 Starter Kit PX30.Core is an EDIMM SOM based on Rockchip PX30 from Engicam. EDIMM2.2 Starter Kit is an EDIMM 2.2 Form Factor Capacitive Evaluation Board from Engicam. PX30.Core needs to mount on top of this Evaluation board for creating complete PX30.Core EDIMM2.2 Starter Kit. Add bindings for it. Signed-off-by: Jagan Teki Acked-by: Rob Herring Link: https://lore.kernel.org/r/20200929083217.25406-2-jagan@amarulasolutions.com Signed-off-by: Heiko Stuebner --- Documentation/devicetree/bindings/arm/rockchip.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 70fa4d98db56..9c5f09147d36 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -70,6 +70,12 @@ properties: - const: elgin,rv1108-r1 - const: rockchip,rv1108 + - description: Engicam PX30.Core EDIMM2.2 Starter Kit + items: + - const: engicam,px30-core-edimm2.2 + - const: engicam,px30-core + - const: rockchip,px30 + - description: Firefly Firefly-RK3288 items: - enum: -- cgit v1.2.3 From 5fccec0cf423aaf90c9c0125ef5af56c9455ba64 Mon Sep 17 00:00:00 2001 From: Jagan Teki Date: Tue, 29 Sep 2020 14:02:15 +0530 Subject: dt-bindings: arm: rockchip: Add Engicam PX30.Core C.TOUCH 2.0 PX30.Core is an EDIMM SOM based on Rockchip PX30 from Engicam. C.TOUCH 2.0 is a general purpose carrier board with capacitive touch interface support. PX30.Core needs to mount on top of this Carrier board for creating complete PX30.Core C.TOUCH 2.0 board. Add bindings for it. Signed-off-by: Jagan Teki Acked-by: Rob Herring Link: https://lore.kernel.org/r/20200929083217.25406-6-jagan@amarulasolutions.com Signed-off-by: Heiko Stuebner --- Documentation/devicetree/bindings/arm/rockchip.yaml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 9c5f09147d36..798d83d04392 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -70,6 +70,12 @@ properties: - const: elgin,rv1108-r1 - const: rockchip,rv1108 + - description: Engicam PX30.Core C.TOUCH 2.0 + items: + - const: engicam,px30-core-ctouch2 + - const: engicam,px30-core + - const: rockchip,px30 + - description: Engicam PX30.Core EDIMM2.2 Starter Kit items: - const: engicam,px30-core-edimm2.2 -- cgit v1.2.3 From cdab490e50e7ce4533b95ca24c90bee3ed1a8e99 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonathan=20Neusch=C3=A4fer?= Date: Sun, 8 Nov 2020 18:29:55 -0800 Subject: dt-bindings: input: ektf2127: Add elan,ektf2132 compatible string MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The eKTF2132 is a touchscreen controller found, for example, in the Kobo Aura ebook reader. It is similar to the ektf2127, but it uses a different packet type to report touch events. Signed-off-by: Jonathan Neuschäfer Link: https://lore.kernel.org/r/20201106112412.390724-2-j.neuschaefer@gmx.net Signed-off-by: Dmitry Torokhov --- Documentation/devicetree/bindings/input/touchscreen/ektf2127.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/input/touchscreen/ektf2127.txt b/Documentation/devicetree/bindings/input/touchscreen/ektf2127.txt index 94c4fc644940..5eef5e7d6aae 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/ektf2127.txt +++ b/Documentation/devicetree/bindings/input/touchscreen/ektf2127.txt @@ -1,7 +1,7 @@ * Elan eKTF2127 I2C touchscreen controller Required properties: - - compatible : "elan,ektf2127" + - compatible : "elan,ektf2127" or "elan,ektf2132" - reg : I2C slave address of the chip (0x40) - interrupts : interrupt specification for the ektf2127 interrupt - power-gpios : GPIO specification for the pin connected to the -- cgit v1.2.3 From 49a3f51dfeeecb52c5aa28c5cb9592fe5e39bf95 Mon Sep 17 00:00:00 2001 From: Thomas Zimmermann Date: Tue, 3 Nov 2020 10:30:11 +0100 Subject: drm/gem: Use struct dma_buf_map in GEM vmap ops and convert GEM backends MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This patch replaces the vmap/vunmap's use of raw pointers in GEM object functions with instances of struct dma_buf_map. GEM backends are converted as well. For most of them, this simply changes the returned type. TTM-based drivers now return information about the location of the memory, either system or I/O memory. GEM VRAM helpers and qxl now use ttm_bo_vmap() et al. Amdgpu, nouveau and radeon use drm_gem_ttm_vmap() et al instead of implementing their own vmap callbacks. v7: * init QXL cursor to mapped BO buffer (kernel test robot) v5: * update vkms after switch to shmem v4: * use ttm_bo_vmap(), drm_gem_ttm_vmap(), et al. (Daniel, Christian) * fix a trailing { in drm_gem_vmap() * remove several empty functions instead of converting them (Daniel) * comment uses of raw pointers with a TODO (Daniel) * TODO list: convert more helpers to use struct dma_buf_map Signed-off-by: Thomas Zimmermann Acked-by: Christian König Tested-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20201103093015.1063-7-tzimmermann@suse.de --- Documentation/gpu/todo.rst | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 6b224ef14455..59f63f1d7680 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -450,6 +450,24 @@ Contact: Ville Syrjälä, Daniel Vetter Level: Intermediate +Use struct dma_buf_map throughout codebase +------------------------------------------ + +Pointers to shared device memory are stored in struct dma_buf_map. Each +instance knows whether it refers to system or I/O memory. Most of the DRM-wide +interface have been converted to use struct dma_buf_map, but implementations +often still use raw pointers. + +The task is to use struct dma_buf_map where it makes sense. + +* Memory managers should use struct dma_buf_map for dma-buf-imported buffers. +* TTM might benefit from using struct dma_buf_map internally. +* Framebuffer copying and blitting helpers should operate on struct dma_buf_map. + +Contact: Thomas Zimmermann , Christian König, Daniel Vetter + +Level: Intermediate + Core refactorings ================= -- cgit v1.2.3 From 222ec45f4c69dfa8cd02c72928147ac06dffffa2 Mon Sep 17 00:00:00 2001 From: Thomas Zimmermann Date: Tue, 3 Nov 2020 10:30:15 +0100 Subject: drm/fb_helper: Support framebuffers in I/O memory At least sparc64 requires I/O-specific access to framebuffers. This patch updates the fbdev console accordingly. For drivers with direct access to the framebuffer memory, the callback functions in struct fb_ops test for the type of memory and call the rsp fb_sys_ of fb_cfb_ functions. Read and write operations are implemented internally by DRM's fbdev helper. For drivers that employ a shadow buffer, fbdev's blit function retrieves the framebuffer address as struct dma_buf_map, and uses dma_buf_map interfaces to access the buffer. The bochs driver on sparc64 uses a workaround to flag the framebuffer as I/O memory and avoid a HW exception. With the introduction of struct dma_buf_map, this is not required any longer. The patch removes the rsp code from both, bochs and fbdev. v7: * use min_t(size_t,) (kernel test robot) * return the number of bytes read/written, if any (fbdev testcase) v5: * implement fb_read/fb_write internally (Daniel, Sam) v4: * move dma_buf_map changes into separate patch (Daniel) * TODO list: comment on fbdev updates (Daniel) Signed-off-by: Thomas Zimmermann Reviewed-by: Daniel Vetter Reviewed-by: Sam Ravnborg Tested-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20201103093015.1063-11-tzimmermann@suse.de --- Documentation/gpu/todo.rst | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 59f63f1d7680..acca232b025b 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -201,13 +201,28 @@ Convert drivers to use drm_fbdev_generic_setup() ------------------------------------------------ Most drivers can use drm_fbdev_generic_setup(). Driver have to implement -atomic modesetting and GEM vmap support. Current generic fbdev emulation -expects the framebuffer in system memory (or system-like memory). +atomic modesetting and GEM vmap support. Historically, generic fbdev emulation +expected the framebuffer in system memory or system-like memory. By employing +struct dma_buf_map, drivers with frambuffers in I/O memory can be supported +as well. Contact: Maintainer of the driver you plan to convert Level: Intermediate +Reimplement functions in drm_fbdev_fb_ops without fbdev +------------------------------------------------------- + +A number of callback functions in drm_fbdev_fb_ops could benefit from +being rewritten without dependencies on the fbdev module. Some of the +helpers could further benefit from using struct dma_buf_map instead of +raw pointers. + +Contact: Thomas Zimmermann , Daniel Vetter + +Level: Advanced + + drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup ----------------------------------------------------------------- -- cgit v1.2.3 From 4bf9cf0b92dfc1039ccdfac218866ec44127d72a Mon Sep 17 00:00:00 2001 From: Filip Kokosinski Date: Tue, 13 Oct 2020 16:45:24 +0200 Subject: dt-bindings: vendor: add vendor prefix for LiteX Add vendor prefix for LiteX SoC builder. Signed-off-by: Filip Kokosinski Signed-off-by: Mateusz Holenko Acked-by: Rob Herring Signed-off-by: Stafford Horne --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 2735be1a8470..5debb143cd45 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -601,6 +601,8 @@ patternProperties: description: Linux-specific binding "^linx,.*": description: Linx Technologies + "^litex,.*": + description: LiteX SoC builder "^lltc,.*": description: Linear Technology Corporation "^logicpd,.*": -- cgit v1.2.3 From 3399bac5efd62e031e62b042d25ed4984db8b8bf Mon Sep 17 00:00:00 2001 From: Pawel Czarnecki Date: Tue, 13 Oct 2020 16:45:40 +0200 Subject: dt-bindings: soc: document LiteX SoC Controller bindings Add documentation for LiteX SoC Controller bindings. Signed-off-by: Pawel Czarnecki Signed-off-by: Mateusz Holenko Reviewed-by: Rob Herring Signed-off-by: Stafford Horne --- .../bindings/soc/litex/litex,soc-controller.yaml | 39 ++++++++++++++++++++++ 1 file changed, 39 insertions(+) create mode 100644 Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml b/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml new file mode 100644 index 000000000000..e2b788796e79 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/litex/litex,soc-controller.yaml @@ -0,0 +1,39 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +# Copyright 2020 Antmicro +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/soc/litex/litex,soc-controller.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: LiteX SoC Controller driver + +description: | + This is the SoC Controller driver for the LiteX SoC Builder. + Its purpose is to verify LiteX CSR (Control&Status Register) access + operations and provide functions for other drivers to read/write CSRs + and to check if those accessors are ready to be used. + +maintainers: + - Karol Gugala + - Mateusz Holenko + +properties: + compatible: + const: litex,soc-controller + + reg: + maxItems: 1 + +required: + - compatible + - reg + +examples: + - | + soc_ctrl0: soc-controller@f0000000 { + compatible = "litex,soc-controller"; + reg = <0xf0000000 0xc>; + status = "okay"; + }; + +... -- cgit v1.2.3 From 79c5ef07d91eee6832bebd98f775a06ed7dd2151 Mon Sep 17 00:00:00 2001 From: Filip Kokosinski Date: Tue, 13 Oct 2020 16:46:05 +0200 Subject: dt-bindings: serial: document LiteUART bindings Add documentation for LiteUART devicetree bindings. Signed-off-by: Filip Kokosinski Signed-off-by: Mateusz Holenko Reviewed-by: Rob Herring Signed-off-by: Stafford Horne --- .../devicetree/bindings/serial/litex,liteuart.yaml | 38 ++++++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 Documentation/devicetree/bindings/serial/litex,liteuart.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/serial/litex,liteuart.yaml b/Documentation/devicetree/bindings/serial/litex,liteuart.yaml new file mode 100644 index 000000000000..bc79b3cca542 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/litex,liteuart.yaml @@ -0,0 +1,38 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause + +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/serial/litex,liteuart.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LiteUART serial controller + +maintainers: + - Karol Gugala + - Mateusz Holenko + +description: | + LiteUART serial controller is a part of the LiteX FPGA SoC builder. It supports + multiple CPU architectures, currently including e.g. OpenRISC and RISC-V. + +properties: + compatible: + const: litex,liteuart + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + +examples: + - | + uart0: serial@e0001800 { + compatible = "litex,liteuart"; + reg = <0xe0001800 0x100>; + interrupts = <2>; + }; -- cgit v1.2.3 From 2356eb80ca42deba0bf2523c62530d4c79dad08f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonathan=20Neusch=C3=A4fer?= Date: Sun, 8 Nov 2020 01:40:45 +0100 Subject: docs: filesystems: Reduce ext2.rst to one top-level heading MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This prevents the other headings like "Options" and "Specification" from leaking out and being listed separately in the table of contents. Link: https://lore.kernel.org/r/20201108004045.1378676-1-j.neuschaefer@gmx.net Signed-off-by: Jonathan Neuschäfer Signed-off-by: Jan Kara --- Documentation/filesystems/ext2.rst | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/filesystems/ext2.rst b/Documentation/filesystems/ext2.rst index d83dbbb162e2..c2fce22cfd03 100644 --- a/Documentation/filesystems/ext2.rst +++ b/Documentation/filesystems/ext2.rst @@ -1,6 +1,7 @@ .. SPDX-License-Identifier: GPL-2.0 +============================== The Second Extended Filesystem ============================== -- cgit v1.2.3 From f4693c2716b35d0846fd45a4ad7db78bfb25efc8 Mon Sep 17 00:00:00 2001 From: Ard Biesheuvel Date: Thu, 8 Oct 2020 17:36:00 +0200 Subject: arm64: mm: extend linear region for 52-bit VA configurations For historical reasons, the arm64 kernel VA space is configured as two equally sized halves, i.e., on a 48-bit VA build, the VA space is split into a 47-bit vmalloc region and a 47-bit linear region. When support for 52-bit virtual addressing was added, this equal split was kept, resulting in a substantial waste of virtual address space in the linear region: 48-bit VA 52-bit VA 0xffff_ffff_ffff_ffff +-------------+ +-------------+ | vmalloc | | vmalloc | 0xffff_8000_0000_0000 +-------------+ _PAGE_END(48) +-------------+ | linear | : : 0xffff_0000_0000_0000 +-------------+ : : : : : : : : : : : : : : : : : currently : : unusable : : : : : : unused : : by : : : : : : : : hardware : : : : : : : 0xfff8_0000_0000_0000 : : _PAGE_END(52) +-------------+ : : | | : : | | : : | | : : | | : : | | : unusable : | | : : | linear | : by : | | : : | region | : hardware : | | : : | | : : | | : : | | : : | | : : | | : : | | 0xfff0_0000_0000_0000 +-------------+ PAGE_OFFSET +-------------+ As illustrated above, the 52-bit VA kernel uses 47 bits for the vmalloc space (as before), to ensure that a single 64k granule kernel image can support any 64k granule capable system, regardless of whether it supports the 52-bit virtual addressing extension. However, due to the fact that the VA space is still split in equal halves, the linear region is only 2^51 bytes in size, wasting almost half of the 52-bit VA space. Let's fix this, by abandoning the equal split, and simply assigning all VA space outside of the vmalloc region to the linear region. The KASAN shadow region is reconfigured so that it ends at the start of the vmalloc region, and grows downwards. That way, the arrangement of the vmalloc space (which contains kernel mappings, modules, BPF region, the vmemmap array etc) is identical between non-KASAN and KASAN builds, which aids debugging. Signed-off-by: Ard Biesheuvel Reviewed-by: Steve Capper Link: https://lore.kernel.org/r/20201008153602.9467-3-ardb@kernel.org Signed-off-by: Catalin Marinas --- Documentation/arm64/kasan-offsets.sh | 3 +-- Documentation/arm64/memory.rst | 19 +++++++++---------- 2 files changed, 10 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/arm64/kasan-offsets.sh b/Documentation/arm64/kasan-offsets.sh index 2b7a021db363..2dc5f9e18039 100644 --- a/Documentation/arm64/kasan-offsets.sh +++ b/Documentation/arm64/kasan-offsets.sh @@ -1,12 +1,11 @@ #!/bin/sh # Print out the KASAN_SHADOW_OFFSETS required to place the KASAN SHADOW -# start address at the mid-point of the kernel VA space +# start address at the top of the linear region print_kasan_offset () { printf "%02d\t" $1 printf "0x%08x00000000\n" $(( (0xffffffff & (-1 << ($1 - 1 - 32))) \ - + (1 << ($1 - 32 - $2)) \ - (1 << (64 - 32 - $2)) )) } diff --git a/Documentation/arm64/memory.rst b/Documentation/arm64/memory.rst index cf03b3290800..ee51eb66a578 100644 --- a/Documentation/arm64/memory.rst +++ b/Documentation/arm64/memory.rst @@ -32,10 +32,10 @@ AArch64 Linux memory layout with 4KB pages + 4 levels (48-bit):: ----------------------------------------------------------------------- 0000000000000000 0000ffffffffffff 256TB user ffff000000000000 ffff7fffffffffff 128TB kernel logical memory map - ffff800000000000 ffff9fffffffffff 32TB kasan shadow region - ffffa00000000000 ffffa00007ffffff 128MB bpf jit region - ffffa00008000000 ffffa0000fffffff 128MB modules - ffffa00010000000 fffffdffbffeffff ~93TB vmalloc +[ ffff600000000000 ffff7fffffffffff ] 32TB [ kasan shadow region ] + ffff800000000000 ffff800007ffffff 128MB bpf jit region + ffff800008000000 ffff80000fffffff 128MB modules + ffff800010000000 fffffdffbffeffff 125TB vmalloc fffffdffbfff0000 fffffdfffe5f8fff ~998MB [guard region] fffffdfffe5f9000 fffffdfffe9fffff 4124KB fixed mappings fffffdfffea00000 fffffdfffebfffff 2MB [guard region] @@ -50,12 +50,11 @@ AArch64 Linux memory layout with 64KB pages + 3 levels (52-bit with HW support): Start End Size Use ----------------------------------------------------------------------- 0000000000000000 000fffffffffffff 4PB user - fff0000000000000 fff7ffffffffffff 2PB kernel logical memory map - fff8000000000000 fffd9fffffffffff 1440TB [gap] - fffda00000000000 ffff9fffffffffff 512TB kasan shadow region - ffffa00000000000 ffffa00007ffffff 128MB bpf jit region - ffffa00008000000 ffffa0000fffffff 128MB modules - ffffa00010000000 fffff81ffffeffff ~88TB vmalloc + fff0000000000000 ffff7fffffffffff ~4PB kernel logical memory map +[ fffd800000000000 ffff7fffffffffff ] 512TB [ kasan shadow region ] + ffff800000000000 ffff800007ffffff 128MB bpf jit region + ffff800008000000 ffff80000fffffff 128MB modules + ffff800010000000 fffff81ffffeffff 120TB vmalloc fffff81fffff0000 fffffc1ffe58ffff ~3TB [guard region] fffffc1ffe590000 fffffc1ffe9fffff 4544KB fixed mappings fffffc1ffea00000 fffffc1ffebfffff 2MB [guard region] -- cgit v1.2.3 From 8c96400d6a39be763130a5c493647c57726f7013 Mon Sep 17 00:00:00 2001 From: Ard Biesheuvel Date: Thu, 8 Oct 2020 17:36:01 +0200 Subject: arm64: mm: make vmemmap region a projection of the linear region Now that we have reverted the introduction of the vmemmap struct page pointer and the separate physvirt_offset, we can simplify things further, and place the vmemmap region in the VA space in such a way that virtual to page translations and vice versa can be implemented using a single arithmetic shift. One happy coincidence resulting from this is that the 48-bit/4k and 52-bit/64k configurations (which are assumed to be the two most prevalent) end up with the same placement of the vmemmap region. In a subsequent patch, we will take advantage of this, and unify the memory maps even more. Signed-off-by: Ard Biesheuvel Reviewed-by: Steve Capper Link: https://lore.kernel.org/r/20201008153602.9467-4-ardb@kernel.org Signed-off-by: Catalin Marinas --- Documentation/arm64/memory.rst | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) (limited to 'Documentation') diff --git a/Documentation/arm64/memory.rst b/Documentation/arm64/memory.rst index ee51eb66a578..476edb6015b2 100644 --- a/Documentation/arm64/memory.rst +++ b/Documentation/arm64/memory.rst @@ -35,14 +35,14 @@ AArch64 Linux memory layout with 4KB pages + 4 levels (48-bit):: [ ffff600000000000 ffff7fffffffffff ] 32TB [ kasan shadow region ] ffff800000000000 ffff800007ffffff 128MB bpf jit region ffff800008000000 ffff80000fffffff 128MB modules - ffff800010000000 fffffdffbffeffff 125TB vmalloc - fffffdffbfff0000 fffffdfffe5f8fff ~998MB [guard region] - fffffdfffe5f9000 fffffdfffe9fffff 4124KB fixed mappings - fffffdfffea00000 fffffdfffebfffff 2MB [guard region] - fffffdfffec00000 fffffdffffbfffff 16MB PCI I/O space - fffffdffffc00000 fffffdffffdfffff 2MB [guard region] - fffffdffffe00000 ffffffffffdfffff 2TB vmemmap - ffffffffffe00000 ffffffffffffffff 2MB [guard region] + ffff800010000000 fffffbffbffeffff 123TB vmalloc + fffffbffbfff0000 fffffbfffe7f8fff ~998MB [guard region] + fffffbfffe7f9000 fffffbfffebfffff 4124KB fixed mappings + fffffbfffec00000 fffffbfffedfffff 2MB [guard region] + fffffbfffee00000 fffffbffffdfffff 16MB PCI I/O space + fffffbffffe00000 fffffbffffffffff 2MB [guard region] + fffffc0000000000 fffffdffffffffff 2TB vmemmap + fffffe0000000000 ffffffffffffffff 2TB [guard region] AArch64 Linux memory layout with 64KB pages + 3 levels (52-bit with HW support):: @@ -55,13 +55,13 @@ AArch64 Linux memory layout with 64KB pages + 3 levels (52-bit with HW support): ffff800000000000 ffff800007ffffff 128MB bpf jit region ffff800008000000 ffff80000fffffff 128MB modules ffff800010000000 fffff81ffffeffff 120TB vmalloc - fffff81fffff0000 fffffc1ffe58ffff ~3TB [guard region] - fffffc1ffe590000 fffffc1ffe9fffff 4544KB fixed mappings - fffffc1ffea00000 fffffc1ffebfffff 2MB [guard region] - fffffc1ffec00000 fffffc1fffbfffff 16MB PCI I/O space - fffffc1fffc00000 fffffc1fffdfffff 2MB [guard region] - fffffc1fffe00000 ffffffffffdfffff 3968GB vmemmap - ffffffffffe00000 ffffffffffffffff 2MB [guard region] + fffff81fffff0000 fffffbfffe38ffff ~3TB [guard region] + fffffbfffe390000 fffffbfffebfffff 4544KB fixed mappings + fffffbfffec00000 fffffbfffedfffff 2MB [guard region] + fffffbfffee00000 fffffbffffdfffff 16MB PCI I/O space + fffffbffffe00000 fffffbffffffffff 2MB [guard region] + fffffc0000000000 ffffffdfffffffff ~4TB vmemmap + ffffffe000000000 ffffffffffffffff 128GB [guard region] Translation table lookup with 4KB pages:: -- cgit v1.2.3 From 9ad7c6d5e75b160c9ce5775db610d964af45b83f Mon Sep 17 00:00:00 2001 From: Ard Biesheuvel Date: Thu, 8 Oct 2020 17:36:02 +0200 Subject: arm64: mm: tidy up top of kernel VA space Tidy up the way the top of the kernel VA space is organized, by mirroring the 256 MB region we have below the vmalloc space, and populating it top down with the PCI I/O space, some guard regions, and the fixmap region. The latter region is itself populated top down, and today only covers about 4 MB, and so 224 MB is ample, and no guard region is therefore required. The resulting layout is identical between 48-bit/4k and 52-bit/64k configurations. Signed-off-by: Ard Biesheuvel Reviewed-by: Steve Capper Link: https://lore.kernel.org/r/20201008153602.9467-5-ardb@kernel.org Signed-off-by: Catalin Marinas --- Documentation/arm64/memory.rst | 22 ++++++++++------------ 1 file changed, 10 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/arm64/memory.rst b/Documentation/arm64/memory.rst index 476edb6015b2..3d62604fa7bd 100644 --- a/Documentation/arm64/memory.rst +++ b/Documentation/arm64/memory.rst @@ -35,12 +35,11 @@ AArch64 Linux memory layout with 4KB pages + 4 levels (48-bit):: [ ffff600000000000 ffff7fffffffffff ] 32TB [ kasan shadow region ] ffff800000000000 ffff800007ffffff 128MB bpf jit region ffff800008000000 ffff80000fffffff 128MB modules - ffff800010000000 fffffbffbffeffff 123TB vmalloc - fffffbffbfff0000 fffffbfffe7f8fff ~998MB [guard region] - fffffbfffe7f9000 fffffbfffebfffff 4124KB fixed mappings - fffffbfffec00000 fffffbfffedfffff 2MB [guard region] - fffffbfffee00000 fffffbffffdfffff 16MB PCI I/O space - fffffbffffe00000 fffffbffffffffff 2MB [guard region] + ffff800010000000 fffffbffefffffff 124TB vmalloc + fffffbfff0000000 fffffbfffdffffff 224MB fixed mappings (top down) + fffffbfffe000000 fffffbfffe7fffff 8MB [guard region] + fffffbfffe800000 fffffbffff7fffff 16MB PCI I/O space + fffffbffff800000 fffffbffffffffff 8MB [guard region] fffffc0000000000 fffffdffffffffff 2TB vmemmap fffffe0000000000 ffffffffffffffff 2TB [guard region] @@ -54,12 +53,11 @@ AArch64 Linux memory layout with 64KB pages + 3 levels (52-bit with HW support): [ fffd800000000000 ffff7fffffffffff ] 512TB [ kasan shadow region ] ffff800000000000 ffff800007ffffff 128MB bpf jit region ffff800008000000 ffff80000fffffff 128MB modules - ffff800010000000 fffff81ffffeffff 120TB vmalloc - fffff81fffff0000 fffffbfffe38ffff ~3TB [guard region] - fffffbfffe390000 fffffbfffebfffff 4544KB fixed mappings - fffffbfffec00000 fffffbfffedfffff 2MB [guard region] - fffffbfffee00000 fffffbffffdfffff 16MB PCI I/O space - fffffbffffe00000 fffffbffffffffff 2MB [guard region] + ffff800010000000 fffffbffefffffff 124TB vmalloc + fffffbfff0000000 fffffbfffdffffff 224MB fixed mappings (top down) + fffffbfffe000000 fffffbfffe7fffff 8MB [guard region] + fffffbfffe800000 fffffbffff7fffff 16MB PCI I/O space + fffffbffff800000 fffffbffffffffff 8MB [guard region] fffffc0000000000 ffffffdfffffffff ~4TB vmemmap ffffffe000000000 ffffffffffffffff 128GB [guard region] -- cgit v1.2.3 From f96a15c7698ede0e60bf5b4b9b5d0c7d0a0b505f Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Sun, 8 Nov 2020 19:18:24 +0100 Subject: speakup: Document read_all_doc shortcut This was implemented a long time ago, but never actually added to the documentation. Signed-off-by: Samuel Thibault Link: https://lore.kernel.org/r/20201108181824.bso5exam72b4p4tk@function Signed-off-by: Greg Kroah-Hartman --- Documentation/admin-guide/spkguide.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/admin-guide/spkguide.txt b/Documentation/admin-guide/spkguide.txt index 3782f6a09e97..5ff6a0fe87d1 100644 --- a/Documentation/admin-guide/spkguide.txt +++ b/Documentation/admin-guide/spkguide.txt @@ -344,6 +344,7 @@ spk key_slash = say_attributes spk key_8 = speakup_paste shift spk key_m = say_first_char ctrl spk key_semicolon = say_last_char +spk key_r = read_all_doc 5. The Speakup Sys System -- cgit v1.2.3 From 1bd3387979bff49cb3115c497895d78ffd5092e3 Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Thu, 29 Oct 2020 21:32:41 +0200 Subject: Documentation: firmware-guide: gpio-properties: Fix factual mistakes Fix factual mistakes and style issues in GPIO properties document. This converts IoRestriction from InputOnly to OutputOnly as pins in the example are used as outputs. Signed-off-by: Andy Shevchenko Signed-off-by: Rafael J. Wysocki --- .../firmware-guide/acpi/gpio-properties.rst | 29 +++++++++++----------- 1 file changed, 15 insertions(+), 14 deletions(-) (limited to 'Documentation') diff --git a/Documentation/firmware-guide/acpi/gpio-properties.rst b/Documentation/firmware-guide/acpi/gpio-properties.rst index bb6d74f23ee0..e6e65ceb2ca1 100644 --- a/Documentation/firmware-guide/acpi/gpio-properties.rst +++ b/Documentation/firmware-guide/acpi/gpio-properties.rst @@ -20,9 +20,9 @@ index, like the ASL example below shows:: Name (_CRS, ResourceTemplate () { - GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly, + GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly, "\\_SB.GPO0", 0, ResourceConsumer) {15} - GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionInputOnly, + GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly, "\\_SB.GPO0", 0, ResourceConsumer) {27, 31} }) @@ -49,7 +49,7 @@ index pin Pin in the GpioIo()/GpioInt() resource. Typically this is zero. active_low - If 1 the GPIO is marked as active_low. + If 1, the GPIO is marked as active_low. Since ACPI GpioIo() resource does not have a field saying whether it is active low or high, the "active_low" argument can be used here. Setting @@ -112,8 +112,8 @@ Example:: Package () { "gpio-line-names", Package () { - "SPI0_CS_N", "EXP2_INT", "MUX6_IO", "UART0_RXD", "MUX7_IO", - "LVL_C_A1", "MUX0_IO", "SPI1_MISO" + "SPI0_CS_N", "EXP2_INT", "MUX6_IO", "UART0_RXD", + "MUX7_IO", "LVL_C_A1", "MUX0_IO", "SPI1_MISO", } } @@ -137,7 +137,7 @@ to the GPIO lines it is going to use and provide the GPIO subsystem with a mapping between those names and the ACPI GPIO resources corresponding to them. To do that, the driver needs to define a mapping table as a NULL-terminated -array of struct acpi_gpio_mapping objects that each contain a name, a pointer +array of struct acpi_gpio_mapping objects that each contains a name, a pointer to an array of line data (struct acpi_gpio_params) objects and the size of that array. Each struct acpi_gpio_params object consists of three fields, crs_entry_index, line_index, active_low, representing the index of the target @@ -154,13 +154,14 @@ question would look like this:: static const struct acpi_gpio_mapping bluetooth_acpi_gpios[] = { { "reset-gpios", &reset_gpio, 1 }, { "shutdown-gpios", &shutdown_gpio, 1 }, - { }, + { } }; Next, the mapping table needs to be passed as the second argument to -acpi_dev_add_driver_gpios() that will register it with the ACPI device object -pointed to by its first argument. That should be done in the driver's .probe() -routine. On removal, the driver should unregister its GPIO mapping table by +acpi_dev_add_driver_gpios() or its managed analogue that will +register it with the ACPI device object pointed to by its first +argument. That should be done in the driver's .probe() routine. +On removal, the driver should unregister its GPIO mapping table by calling acpi_dev_remove_driver_gpios() on the ACPI device object where that table was previously registered. @@ -191,12 +192,12 @@ The driver might expect to get the right GPIO when it does:: but since there is no way to know the mapping between "reset" and the GpioIo() in _CRS desc will hold ERR_PTR(-ENOENT). -The driver author can solve this by passing the mapping explictly -(the recommended way and documented in the above chapter). +The driver author can solve this by passing the mapping explicitly +(this is the recommended way and it's documented in the above chapter). The ACPI GPIO mapping tables should not contaminate drivers that are not knowing about which exact device they are servicing on. It implies that -the ACPI GPIO mapping tables are hardly linked to ACPI ID and certain +the ACPI GPIO mapping tables are hardly linked to an ACPI ID and certain objects, as listed in the above chapter, of the device in question. Getting GPIO descriptor @@ -229,5 +230,5 @@ Case 2 explicitly tells GPIO core to look for resources in _CRS. Be aware that gpiod_get_index() in cases 1 and 2, assuming that there are two versions of ACPI device description provided and no mapping is present in the driver, will return different resources. That's why a -certain driver has to handle them carefully as explained in previous +certain driver has to handle them carefully as explained in the previous chapter. -- cgit v1.2.3 From 0d6c41cf801fd56b92f4359374667061d27a6472 Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Thu, 29 Oct 2020 21:32:42 +0200 Subject: Documentation: firmware-guide: gpio-properties: active_low only for GpioIo() It appears that people may misinterpret active_low field in _DSD for GpioInt() resource. Add a paragraph to clarify this. Reported-by: Ricardo Ribalda Signed-off-by: Andy Shevchenko Reviewed-by: Mika Westerberg Reviewed-by: Ricardo Ribalda Signed-off-by: Rafael J. Wysocki --- Documentation/firmware-guide/acpi/gpio-properties.rst | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/firmware-guide/acpi/gpio-properties.rst b/Documentation/firmware-guide/acpi/gpio-properties.rst index e6e65ceb2ca1..370fe46c6af9 100644 --- a/Documentation/firmware-guide/acpi/gpio-properties.rst +++ b/Documentation/firmware-guide/acpi/gpio-properties.rst @@ -55,6 +55,9 @@ Since ACPI GpioIo() resource does not have a field saying whether it is active low or high, the "active_low" argument can be used here. Setting it to 1 marks the GPIO as active low. +Note, active_low in _DSD does not make sense for GpioInt() resource and +must be 0. GpioInt() resource has its own means of defining it. + In our Bluetooth example the "reset-gpios" refers to the second GpioIo() resource, second pin in that resource with the GPIO number of 31. -- cgit v1.2.3 From 8b31e972f9872e5a6a3348506b5b84353fecef58 Mon Sep 17 00:00:00 2001 From: Andy Shevchenko Date: Thu, 29 Oct 2020 21:32:43 +0200 Subject: Documentation: firmware-guide: gpio-properties: Clarify initial output state GpioIo() doesn't provide an explicit state for an output pin. Linux tries to be smart and uses a common sense based on other parameters. Document how it looks like in the code. Signed-off-by: Andy Shevchenko Reviewed-by: Mika Westerberg Signed-off-by: Rafael J. Wysocki --- .../firmware-guide/acpi/gpio-properties.rst | 23 ++++++++++++++++++++++ 1 file changed, 23 insertions(+) (limited to 'Documentation') diff --git a/Documentation/firmware-guide/acpi/gpio-properties.rst b/Documentation/firmware-guide/acpi/gpio-properties.rst index 370fe46c6af9..59aad6138b6e 100644 --- a/Documentation/firmware-guide/acpi/gpio-properties.rst +++ b/Documentation/firmware-guide/acpi/gpio-properties.rst @@ -61,6 +61,29 @@ must be 0. GpioInt() resource has its own means of defining it. In our Bluetooth example the "reset-gpios" refers to the second GpioIo() resource, second pin in that resource with the GPIO number of 31. +The GpioIo() resource unfortunately doesn't explicitly provide an initial +state of the output pin which driver should use during its initialization. + +Linux tries to use common sense here and derives the state from the bias +and polarity settings. The table below shows the expectations: + +========= ============= ============== +Pull Bias Polarity Requested... +========= ============= ============== +Implicit x AS IS (assumed firmware configured for us) +Explicit x (no _DSD) as Pull Bias (Up == High, Down == Low), + assuming non-active (Polarity = !Pull Bias) +Down Low as low, assuming active +Down High as low, assuming non-active +Up Low as high, assuming non-active +Up High as high, assuming active +========= ============= ============== + +That said, for our above example the both GPIOs, since the bias setting +is explicit and _DSD is present, will be treated as active with a high +polarity and Linux will configure the pins in this state until a driver +reprograms them differently. + It is possible to leave holes in the array of GPIOs. This is useful in cases like with SPI host controllers where some chip selects may be implemented as GPIOs and some as native signals. For example a SPI host -- cgit v1.2.3 From 616fde2dd60f9f956dc77ed7e284129de6dc97d2 Mon Sep 17 00:00:00 2001 From: Ionut-robert Aron Date: Mon, 9 Nov 2020 12:46:34 +0200 Subject: dt-bindings: misc: convert fsl,dpaa2-console from txt to YAML Convert fsl,dpaa2-console to YAML in order to automate the verification process of dts files. Signed-off-by: Ionut-robert Aron Signed-off-by: Laurentiu Tudor Link: https://lore.kernel.org/r/20201109104635.21116-1-laurentiu.tudor@nxp.com Signed-off-by: Rob Herring --- .../devicetree/bindings/misc/fsl,dpaa2-console.txt | 11 ---------- .../bindings/misc/fsl,dpaa2-console.yaml | 25 ++++++++++++++++++++++ 2 files changed, 25 insertions(+), 11 deletions(-) delete mode 100644 Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt create mode 100644 Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt b/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt deleted file mode 100644 index 1442ba5d2d98..000000000000 --- a/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.txt +++ /dev/null @@ -1,11 +0,0 @@ -DPAA2 console support - -Required properties: - - - compatible - Value type: - Definition: Must be "fsl,dpaa2-console". - - reg - Value type: - Definition: A standard property. Specifies the region where the MCFBA - (MC firmware base address) register can be found. diff --git a/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml b/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml new file mode 100644 index 000000000000..271a3eafc054 --- /dev/null +++ b/Documentation/devicetree/bindings/misc/fsl,dpaa2-console.yaml @@ -0,0 +1,25 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2020 NXP +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/misc/fsl,dpaa2-console.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: DPAA2 console support + +maintainers: + - Laurentiu Tudor + +properties: + compatible: + const: "fsl,dpaa2-console" + + reg: + description: A standard property. Specifies the region where the MCFBA + (MC firmware base address) register can be found. + +required: + - compatible + - reg + +additionalProperties: false -- cgit v1.2.3 From 7fc6622c1a8d0f69be0783245fe38fed17ad8d18 Mon Sep 17 00:00:00 2001 From: Oleksij Rempel Date: Fri, 30 Oct 2020 15:00:27 +0100 Subject: dt-bindings: vendor-prefixes: Add an entry for Altus-Escon-Company Add "alt" entry for Altus-Escon-Company BV: https://www.altus-escon.com/ Signed-off-by: Oleksij Rempel Acked-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 31897f127b47..8db0ab3b2012 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -67,6 +67,8 @@ patternProperties: description: AlphaScale Integrated Circuits Systems, Inc. "^alps,.*": description: Alps Electric Co., Ltd. + "^alt,.*": + description: Altus-Escon-Company BV "^altr,.*": description: Altera Corp. "^amarula,.*": -- cgit v1.2.3 From cd49dccbde912ae7e6ee4d4f94f71740c690b520 Mon Sep 17 00:00:00 2001 From: Oleksij Rempel Date: Fri, 30 Oct 2020 15:00:28 +0100 Subject: dt-bindings: arm: fsl: add Altesco I6P board Add Altus-Escon-Company BV I6P iMX6dl based board Signed-off-by: Oleksij Rempel Acked-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 85fb24da4a02..4986ffcceab6 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -349,6 +349,7 @@ properties: - abb,aristainetos-imx6dl-7 # aristainetos i.MX6 Dual Lite Board 7 - abb,aristainetos2-imx6dl-4 # aristainetos2 i.MX6 Dual Lite Board 4 - abb,aristainetos2-imx6dl-7 # aristainetos2 i.MX6 Dual Lite Board 7 + - alt,alti6p # Altesco I6P Board - boundary,imx6dl-nit6xlite # Boundary Devices Nitrogen6 Lite - boundary,imx6dl-nitrogen6x # Boundary Devices Nitrogen6x - bticino,imx6dl-mamoj # BTicino i.MX6DL Mamoj -- cgit v1.2.3 From 236d454b27c7c17152663426613be274effc19fc Mon Sep 17 00:00:00 2001 From: Oleksij Rempel Date: Mon, 2 Nov 2020 10:02:11 +0100 Subject: dt-bindings: arm: fsl: add Van der Laan LANMCU board Add Van der Laan LANMCU iMX6dl based board Signed-off-by: Oleksij Rempel Reviewed-by: Krzysztof Kozlowski Acked-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 4986ffcceab6..c5b8e34a8991 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -378,6 +378,7 @@ properties: - technologic,imx6dl-ts4900 - technologic,imx6dl-ts7970 - udoo,imx6dl-udoo # Udoo i.MX6 Dual-lite Board + - vdl,lanmcu # Van der Laan LANMCU board - wand,imx6dl-wandboard # Wandboard i.MX6 Dual Lite Board - ysoft,imx6dl-yapp4-draco # i.MX6 DualLite Y Soft IOTA Draco board - ysoft,imx6dl-yapp4-hydra # i.MX6 DualLite Y Soft IOTA Hydra board -- cgit v1.2.3 From 16eb0eb835c77c5e8824b8aa90b11b00ddc5c122 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonathan=20Neusch=C3=A4fer?= Date: Sat, 7 Nov 2020 23:08:21 +0100 Subject: docs: networking: phy: s/2.5 times faster/2.5 times as fast/ MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 2.5 times faster would be 3.5 Gbps (4.375 Gbaud after 8b/10b encoding). Signed-off-by: Jonathan Neuschäfer Link: https://lore.kernel.org/r/20201107220822.1291215-1-j.neuschaefer@gmx.net Signed-off-by: Jakub Kicinski --- Documentation/networking/phy.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/phy.rst b/Documentation/networking/phy.rst index 256106054c8c..b2f7ec794bc8 100644 --- a/Documentation/networking/phy.rst +++ b/Documentation/networking/phy.rst @@ -247,8 +247,8 @@ Some of the interface modes are described below: speeds (see below.) ``PHY_INTERFACE_MODE_2500BASEX`` - This defines a variant of 1000BASE-X which is clocked 2.5 times faster, - than the 802.3 standard giving a fixed bit rate of 3.125Gbaud. + This defines a variant of 1000BASE-X which is clocked 2.5 times as fast + as the 802.3 standard, giving a fixed bit rate of 3.125Gbaud. ``PHY_INTERFACE_MODE_SGMII`` This is used for Cisco SGMII, which is a modification of 1000BASE-X -- cgit v1.2.3 From 5fc865f8bfd2cd3b12f5fef3a57f73fcb67e1544 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Thu, 5 Nov 2020 19:48:07 +0100 Subject: dt-bindings: arm: fsl: document LS1012A FRWY board Document the compatible for LS1012A FRWY board. Signed-off-by: Krzysztof Kozlowski Acked-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index c5b8e34a8991..e0bbfa59bfda 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -796,6 +796,7 @@ properties: - ebs-systart,oxalis - fsl,ls1012a-rdb - fsl,ls1012a-frdm + - fsl,ls1012a-frwy - fsl,ls1012a-qds - const: fsl,ls1012a -- cgit v1.2.3 From 608f000f8a32e598ce3d7487889a499c5b5582cb Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Thu, 5 Nov 2020 19:48:08 +0100 Subject: dt-bindings: arm: fsl: document SolidRun LX2160A boards Document the compatible for SolidRun LX2160A based boards. Signed-off-by: Krzysztof Kozlowski Acked-by: Rob Herring Signed-off-by: Shawn Guo --- Documentation/devicetree/bindings/arm/fsl.yaml | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index e0bbfa59bfda..f793f90fe2e6 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -898,6 +898,14 @@ properties: - fsl,lx2162a-qds - const: fsl,lx2160a + - description: SolidRun LX2160A based Boards + items: + - enum: + - solidrun,clearfog-cx + - solidrun,honeycomb + - const: solidrun,lx2160a-cex7 + - const: fsl,lx2160a + - description: S32V234 based Boards items: - enum: -- cgit v1.2.3 From a29bbb0861f487a5e144dc997a9f71a36c7a2404 Mon Sep 17 00:00:00 2001 From: Jordan Crouse Date: Mon, 9 Nov 2020 11:47:27 -0700 Subject: dt-bindings: arm-smmu: Add compatible string for Adreno GPU SMMU Every Qcom Adreno GPU has an embedded SMMU for its own use. These devices depend on unique features such as split pagetables, different stall/halt requirements and other settings. Identify them with a compatible string so that they can be identified in the arm-smmu implementation specific code. Signed-off-by: Jordan Crouse Signed-off-by: Rob Clark Reviewed-by: Rob Herring Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/20201109184728.2463097-4-jcrouse@codeaurora.org Signed-off-by: Will Deacon --- Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml index 503160a7b9a0..3b63f2ae24db 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml @@ -28,8 +28,6 @@ properties: - enum: - qcom,msm8996-smmu-v2 - qcom,msm8998-smmu-v2 - - qcom,sc7180-smmu-v2 - - qcom,sdm845-smmu-v2 - const: qcom,smmu-v2 - description: Qcom SoCs implementing "arm,mmu-500" @@ -40,6 +38,13 @@ properties: - qcom,sm8150-smmu-500 - qcom,sm8250-smmu-500 - const: arm,mmu-500 + - description: Qcom Adreno GPUs implementing "arm,smmu-v2" + items: + - enum: + - qcom,sc7180-smmu-v2 + - qcom,sdm845-smmu-v2 + - const: qcom,adreno-smmu + - const: qcom,smmu-v2 - description: Marvell SoCs implementing "arm,mmu-500" items: - const: marvell,ap806-smmu-500 -- cgit v1.2.3 From 3d417196e2447811f9c73b0efe7ba02f5cb20fff Mon Sep 17 00:00:00 2001 From: Vladimir Lypak Date: Wed, 7 Oct 2020 19:06:12 +0300 Subject: dt-bindings: pinctrl: qcom: add msm8953 pinctrl bindings Add device tree bindings documentation for Qualcomm MSM8953 pinctrl driver. Signed-off-by: Vladimir Lypak Reviewed-by: Bjorn Andersson Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20201007160611.942754-2-junak.pub@gmail.com Signed-off-by: Linus Walleij --- .../bindings/pinctrl/qcom,msm8953-pinctrl.yaml | 167 +++++++++++++++++++++ 1 file changed, 167 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml new file mode 100644 index 000000000000..abe9f4c9b1e3 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml @@ -0,0 +1,167 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,msm8953-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. MSM8953 TLMM block + +maintainers: + - Bjorn Andersson + +description: | + This binding describes the Top Level Mode Multiplexer block found in the + MSM8953 platform. + +properties: + compatible: + const: qcom,msm8953-pinctrl + + reg: + maxItems: 1 + + interrupts: + description: Specifies the TLMM summary IRQ + maxItems: 1 + + interrupt-controller: true + + '#interrupt-cells': + description: + Specifies the PIN numbers and Flags, as defined in defined in + include/dt-bindings/interrupt-controller/irq.h + const: 2 + + gpio-controller: true + + '#gpio-cells': + description: Specifying the pin number and flags, as defined in + include/dt-bindings/gpio/gpio.h + const: 2 + + gpio-ranges: + maxItems: 1 + +#PIN CONFIGURATION NODES +patternProperties: + '-pins$': + type: object + description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. + $ref: "/schemas/pinctrl/pincfg-node.yaml" + + properties: + pins: + description: + List of gpio pins affected by the properties specified in this + subnode. + items: + oneOf: + - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-7][0-9])$" + - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc1_rclk, sdc2_clk, + sdc2_cmd, sdc2_data, qdsd_clk, qdsd_cmd, qdsd_data0, + qdsd_data1, qdsd_data2, qdsd_data3 ] + minItems: 1 + maxItems: 16 + + function: + description: + Specify the alternative function to be configured for the specified + pins. + + enum: [ accel_int, adsp_ext, alsp_int, atest_bbrx0, atest_bbrx1, + atest_char, atest_char0, atest_char1, atest_char2, atest_char3, + atest_gpsadc_dtest0_native, atest_gpsadc_dtest1_native, atest_tsens, + atest_wlan0, atest_wlan1, bimc_dte0, bimc_dte1, blsp1_spi, + blsp3_spi, blsp6_spi, blsp7_spi, blsp_i2c1, blsp_i2c2, blsp_i2c3, + blsp_i2c4, blsp_i2c5, blsp_i2c6, blsp_i2c7, blsp_i2c8, blsp_spi1, + blsp_spi2, blsp_spi3, blsp_spi4, blsp_spi5, blsp_spi6, blsp_spi7, + blsp_spi8, blsp_uart2, blsp_uart4, blsp_uart5, blsp_uart6, cam0_ldo, + cam1_ldo, cam1_rst, cam1_standby, cam2_rst, cam2_standby, cam3_rst, + cam3_standby, cam_irq, cam_mclk, cap_int, cci_async, cci_i2c, + cci_timer0, cci_timer1, cci_timer2, cci_timer3, cci_timer4, + cdc_pdm0, codec_int1, codec_int2, codec_reset, cri_trng, cri_trng0, + cri_trng1, dac_calib0, dac_calib1, dac_calib10, dac_calib11, + dac_calib12, dac_calib13, dac_calib14, dac_calib15, dac_calib16, + dac_calib17, dac_calib18, dac_calib19, dac_calib2, dac_calib20, + dac_calib21, dac_calib22, dac_calib23, dac_calib24, dac_calib25, + dac_calib3, dac_calib4, dac_calib5, dac_calib6, dac_calib7, + dac_calib8, dac_calib9, dbg_out, ddr_bist, dmic0_clk, dmic0_data, + ebi_cdc, ebi_ch0, ext_lpass, flash_strobe, fp_int, gcc_gp1_clk_a, + gcc_gp1_clk_b, gcc_gp2_clk_a, gcc_gp2_clk_b, gcc_gp3_clk_a, + gcc_gp3_clk_b, gcc_plltest, gcc_tlmm, gpio, gsm0_tx, gsm1_tx, + gyro_int, hall_int, hdmi_int, key_focus, key_home, key_snapshot, + key_volp, ldo_en, ldo_update, lpass_slimbus, lpass_slimbus0, + lpass_slimbus1, m_voc, mag_int, mdp_vsync, mipi_dsi0, modem_tsync, + mss_lte, nav_pps, nav_pps_in_a, nav_pps_in_b, nav_tsync, + nfc_disable, nfc_dwl, nfc_irq, ois_sync, pa_indicator, pbs0, pbs1, + pbs2, pressure_int, pri_mi2s, pri_mi2s_mclk_a, pri_mi2s_mclk_b, + pri_mi2s_ws, prng_rosc, pwr_crypto_enabled_a, pwr_crypto_enabled_b, + pwr_down, pwr_modem_enabled_a, pwr_modem_enabled_b, + pwr_nav_enabled_a, pwr_nav_enabled_b, qdss_cti_trig_in_a0, + qdss_cti_trig_in_a1, qdss_cti_trig_in_b0, qdss_cti_trig_in_b1, + qdss_cti_trig_out_a0, qdss_cti_trig_out_a1, qdss_cti_trig_out_b0, + qdss_cti_trig_out_b1, qdss_traceclk_a, qdss_traceclk_b, + qdss_tracectl_a, qdss_tracectl_b, qdss_tracedata_a, + qdss_tracedata_b, sd_write, sdcard_det, sec_mi2s, sec_mi2s_mclk_a, + sec_mi2s_mclk_b, smb_int, ss_switch, ssbi_wtr1, ts_resout, + ts_sample, ts_xvdd, tsens_max, uim1_clk, uim1_data, uim1_present, + uim1_reset, uim2_clk, uim2_data, uim2_present, uim2_reset, + uim_batt, us_emitter, us_euro, wcss_bt, wcss_fm, wcss_wlan, + wcss_wlan0, wcss_wlan1, wcss_wlan2, wsa_en, wsa_io, wsa_irq ] + + drive-strength: + enum: [2, 4, 6, 8, 10, 12, 14, 16] + default: 2 + description: + Selects the drive strength for the specified pins, in mA. + + bias-pull-down: true + + bias-pull-up: true + + bias-disable: true + + output-high: true + + output-low: true + + required: + - pins + - function + + additionalProperties: false + +required: + - compatible + - reg + - interrupts + - interrupt-controller + - '#interrupt-cells' + - gpio-controller + - '#gpio-cells' + - gpio-ranges + +additionalProperties: false + +examples: + - | + #include + tlmm: pinctrl@1000000 { + compatible = "qcom,msm8953-pinctrl"; + reg = <0x01000000 0x300000>; + interrupts = ; + interrupt-controller; + #interrupt-cells = <2>; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&tlmm 0 0 142>; + + serial_default: serial-pins { + pins = "gpio4", "gpio5"; + function = "blsp_uart2"; + drive-strength = <2>; + bias-disable; + }; + }; -- cgit v1.2.3 From ad3b508c90ad20c63ac4fcd076e22b9f0294124d Mon Sep 17 00:00:00 2001 From: Gregory CLEMENT Date: Fri, 6 Nov 2020 10:31:15 +0100 Subject: dt-bindings: pinctrl: ocelot: Add Luton SoC support Add the documentation for the Microsemi Luton pinmuxing and gpio controller. Signed-off-by: Gregory CLEMENT Link: https://lore.kernel.org/r/20201106093118.965152-2-gregory.clement@bootlin.com Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt index 00912449237b..58ea2ae57713 100644 --- a/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt @@ -3,7 +3,8 @@ Microsemi Ocelot pin controller Device Tree Bindings Required properties: - compatible : Should be "mscc,ocelot-pinctrl", - "mscc,jaguar2-pinctrl" or "microchip,sparx5-pinctrl" + "mscc,jaguar2-pinctrl", "microchip,sparx5-pinctrl" + or "mscc,luton-pinctrl" - reg : Address and length of the register set for the device - gpio-controller : Indicates this device is a GPIO controller - #gpio-cells : Must be 2. -- cgit v1.2.3 From e1822384d6d680a31724872b3134ce03eb6a27bc Mon Sep 17 00:00:00 2001 From: Gregory CLEMENT Date: Fri, 6 Nov 2020 10:31:16 +0100 Subject: dt-bindings: pinctrl: ocelot: Add Serval SoC support Add the documentation for the Microsemi Serval pinmuxing and gpio controller. Signed-off-by: Gregory CLEMENT Link: https://lore.kernel.org/r/20201106093118.965152-3-gregory.clement@bootlin.com Signed-off-by: Linus Walleij --- Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt index 58ea2ae57713..db99bd95d423 100644 --- a/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt @@ -3,8 +3,8 @@ Microsemi Ocelot pin controller Device Tree Bindings Required properties: - compatible : Should be "mscc,ocelot-pinctrl", - "mscc,jaguar2-pinctrl", "microchip,sparx5-pinctrl" - or "mscc,luton-pinctrl" + "mscc,jaguar2-pinctrl", "microchip,sparx5-pinctrl", + "mscc,luton-pinctrl" or "mscc,serval-pinctrl" - reg : Address and length of the register set for the device - gpio-controller : Indicates this device is a GPIO controller - #gpio-cells : Must be 2. -- cgit v1.2.3 From 08651373808e16b01d3b12207f52504c17b6774c Mon Sep 17 00:00:00 2001 From: "Shane.Chien" Date: Tue, 10 Nov 2020 10:31:32 +0800 Subject: dt-bindings: mediatek: mt6359: Add new property for mt6359 This patch add "LDO_VAUD18-supply" property to control vaud18 regulator. It is labeled as required due to mt6359 audio path always need to enable vaud18. Signed-off-by: Shane.Chien Link: https://lore.kernel.org/r/1604975492-6142-3-git-send-email-shane.chien@mediatek.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/mt6359.yaml | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/mt6359.yaml b/Documentation/devicetree/bindings/sound/mt6359.yaml index a54f466f769d..ef027c79032f 100644 --- a/Documentation/devicetree/bindings/sound/mt6359.yaml +++ b/Documentation/devicetree/bindings/sound/mt6359.yaml @@ -17,6 +17,11 @@ description: | Must be a child node of PMIC wrapper. properties: + LDO_VAUD18-supply: + $ref: /schemas/types.yaml#/definitions/phandle + description: | + Regulator of LDO VAUD18 at 1.8V. + mediatek,dmic-mode: $ref: /schemas/types.yaml#/definitions/uint32 description: | @@ -49,11 +54,15 @@ properties: description: | Specifies the type of mic type connected to adc2 +required: + - LDO_VAUD18-supply + additionalProperties: false examples: - | mt6359codec: mt6359codec { + LDO_VAUD18-supply = <&mt6359p_vaud18_reg>; mediatek,dmic-mode = <0>; mediatek,mic-type-0 = <2>; }; -- cgit v1.2.3 From 0e38d93493c7b11bc250113dd5b7b9d17ba8c54d Mon Sep 17 00:00:00 2001 From: Ajye Huang Date: Fri, 6 Nov 2020 14:14:32 +0800 Subject: ASoC: google: dt-bindings: modify machine bindings for two MICs case Add a property "dmic-gpios" for switching between two MICs. Signed-off-by: Ajye Huang Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20201106061433.1483129-2-ajye_huang@compal.corp-partner.google.com Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/google,sc7180-trogdor.yaml | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml b/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml index efc34689d6b5..ce050a9dec94 100644 --- a/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml +++ b/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml @@ -34,6 +34,10 @@ properties: "#size-cells": const: 0 + dmic-gpios: + maxItems: 1 + description: GPIO for switching between DMICs + patternProperties: "^dai-link(@[0-9])?$": description: @@ -83,7 +87,7 @@ examples: - | sound { compatible = "google,sc7180-trogdor"; - model = "sc7180-rt5682-max98357a-1mic"; + model = "sc7180-rt5682-max98357a-2mic"; audio-routing = "Headphone Jack", "HPOL", @@ -92,6 +96,8 @@ examples: #address-cells = <1>; #size-cells = <0>; + dmic-gpios = <&tlmm 86 0>; + dai-link@0 { link-name = "MultiMedia0"; reg = <0>; -- cgit v1.2.3 From 4d1a9952dda649284413e6ff12b81db3a2bc4115 Mon Sep 17 00:00:00 2001 From: David Lin Date: Mon, 2 Nov 2020 10:32:13 +0800 Subject: ASoC: nau8315: add codec driver Add codec driver for Nuvoton NAU8315. Signed-off-by: David Lin Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20201102023212.594137-1-CTLIN0@nuvoton.com Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/nau8315.txt | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/nau8315.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/nau8315.txt b/Documentation/devicetree/bindings/sound/nau8315.txt new file mode 100644 index 000000000000..6eaec46f384c --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nau8315.txt @@ -0,0 +1,18 @@ +Nuvoton NAU8315 Mono Class-D Amplifier + +Required properties: +- compatible : "nuvoton,nau8315" + +Optional properties: +- enable-gpios : GPIO specifier for the chip's device enable input(EN) pin. + If this option is not specified then driver does not manage + the pin state (e.g. chip is always on). + +Example: + +#include + +nau8315 { + compatible = "nuvoton,nau8315"; + enable-gpios = <&gpio1 5 GPIO_ACTIVE_HIGH>; +}; -- cgit v1.2.3 From 68af6d2483dbd0385317bc87a338b155be75eeb6 Mon Sep 17 00:00:00 2001 From: Ard Biesheuvel Date: Tue, 10 Nov 2020 14:08:51 +0100 Subject: Documentation/arm64: fix RST layout of memory.rst Stephen reports that commit f4693c2716b3 ("arm64: mm: extend linear region for 52-bit VA configurations") triggers the following warnings when building the htmldocs make target of today's linux-next: Documentation/arm64/memory.rst:35: WARNING: Literal block ends without a blank line; unexpected unindent. Documentation/arm64/memory.rst:53: WARNING: Literal block ends without a blank line; unexpected unindent. Let's tweak the memory layout table to work around this. Reported-by: Stephen Rothwell Signed-off-by: Ard Biesheuvel Fixes: f4693c2716b3 ("arm64: mm: extend linear region for 52-bit VA configurations") Link: https://lore.kernel.org/r/20201110130851.15751-1-ardb@kernel.org Signed-off-by: Catalin Marinas --- Documentation/arm64/memory.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/arm64/memory.rst b/Documentation/arm64/memory.rst index 3d62604fa7bd..e7522e5c8322 100644 --- a/Documentation/arm64/memory.rst +++ b/Documentation/arm64/memory.rst @@ -32,7 +32,7 @@ AArch64 Linux memory layout with 4KB pages + 4 levels (48-bit):: ----------------------------------------------------------------------- 0000000000000000 0000ffffffffffff 256TB user ffff000000000000 ffff7fffffffffff 128TB kernel logical memory map -[ ffff600000000000 ffff7fffffffffff ] 32TB [ kasan shadow region ] + [ffff600000000000 ffff7fffffffffff] 32TB [kasan shadow region] ffff800000000000 ffff800007ffffff 128MB bpf jit region ffff800008000000 ffff80000fffffff 128MB modules ffff800010000000 fffffbffefffffff 124TB vmalloc @@ -50,7 +50,7 @@ AArch64 Linux memory layout with 64KB pages + 3 levels (52-bit with HW support): ----------------------------------------------------------------------- 0000000000000000 000fffffffffffff 4PB user fff0000000000000 ffff7fffffffffff ~4PB kernel logical memory map -[ fffd800000000000 ffff7fffffffffff ] 512TB [ kasan shadow region ] + [fffd800000000000 ffff7fffffffffff] 512TB [kasan shadow region] ffff800000000000 ffff800007ffffff 128MB bpf jit region ffff800008000000 ffff80000fffffff 128MB modules ffff800010000000 fffffbffefffffff 124TB vmalloc -- cgit v1.2.3 From c82d4776a1ddf8cb16b7683ad1fe6844bf396ac8 Mon Sep 17 00:00:00 2001 From: Vinod Koul Date: Mon, 9 Nov 2020 11:56:19 +0530 Subject: dt-bindings: pinctrl: qcom: Add SDX55 pinctrl bindings Add device tree binding Documentation details for Qualcomm SDX55 pinctrl driver. Signed-off-by: Vinod Koul Reviewed-by: Bjorn Andersson Reviewed-by: Rob Herring Link: https://lore.kernel.org/r/20201109062620.14566-2-vkoul@kernel.org Signed-off-by: Linus Walleij --- .../bindings/pinctrl/qcom,sdx55-pinctrl.yaml | 154 +++++++++++++++++++++ 1 file changed, 154 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,sdx55-pinctrl.yaml (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdx55-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sdx55-pinctrl.yaml new file mode 100644 index 000000000000..112dd59ce7ed --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdx55-pinctrl.yaml @@ -0,0 +1,154 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,sdx55-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. SDX55 TLMM block + +maintainers: + - Vinod Koul + +description: | + This binding describes the Top Level Mode Multiplexer block found in the + SDX55 platform. + +properties: + compatible: + const: qcom,sdx55-pinctrl + + reg: + description: Specifies the base address and size of the TLMM register space + maxItems: 1 + + interrupts: + description: Specifies the TLMM summary IRQ + maxItems: 1 + + interrupt-controller: true + + '#interrupt-cells': + description: Specifies the PIN numbers and Flags, as defined in + include/dt-bindings/interrupt-controller/irq.h + const: 2 + + gpio-controller: true + + '#gpio-cells': + description: Specifying the pin number and flags, as defined in + include/dt-bindings/gpio/gpio.h + const: 2 + + gpio-ranges: + maxItems: 1 + + gpio-reserved-ranges: + maxItems: 1 + +#PIN CONFIGURATION NODES +patternProperties: + '-pins$': + type: object + description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. + $ref: "/schemas/pinctrl/pincfg-node.yaml" + + properties: + pins: + description: + List of gpio pins affected by the properties specified in this subnode. + items: + oneOf: + - pattern: "^gpio([0-9]|[1-9][0-9]|1[0-1][0-6])$" + - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, sdc2_data ] + minItems: 1 + maxItems: 36 + + function: + description: + Specify the alternative function to be configured for the specified + pins. Functions are only valid for gpio pins. + enum: [ adsp_ext, atest, audio_ref, bimc_dte0, bimc_dte1, blsp_i2c1, + blsp_i2c2, blsp_i2c3, blsp_i2c4, blsp_spi1, blsp_spi2, + blsp_spi3, blsp_spi4, blsp_uart1, blsp_uart2, blsp_uart3, + blsp_uart4, char_exec, coex_uart, coex_uart2, cri_trng, + cri_trng0, cri_trng1, dbg_out, ddr_bist, ddr_pxi0, + ebi0_wrcdc, ebi2_a, ebi2_lcd, emac_gcc0, emac_gcc1, + emac_pps0, emac_pps1, ext_dbg, gcc_gp1, gcc_gp2, gcc_gp3, + gcc_plltest, gpio, i2s_mclk, jitter_bist, ldo_en, ldo_update, + mgpi_clk, m_voc, native_char, native_char0, native_char1, + native_char2, native_char3, native_tsens, native_tsense, + nav_gpio, pa_indicator, pcie_clkreq, pci_e, pll_bist, pll_ref, + pll_test, pri_mi2s, prng_rosc, qdss_cti, qdss_gpio, + qdss_gpio0, qdss_gpio1, qdss_gpio2, qdss_gpio3, qdss_gpio4, + qdss_gpio5, qdss_gpio6, qdss_gpio7, qdss_gpio8, qdss_gpio9, + qdss_gpio10, qdss_gpio11, qdss_gpio12, qdss_gpio13, + qdss_gpio14, qdss_gpio15, qdss_stm0, qdss_stm1, qdss_stm2, + qdss_stm3, qdss_stm4, qdss_stm5, qdss_stm6, qdss_stm7, + qdss_stm8, qdss_stm9, qdss_stm10, qdss_stm11, qdss_stm12, + qdss_stm13, qdss_stm14, qdss_stm15, qdss_stm16, qdss_stm17, + qdss_stm18, qdss_stm19, qdss_stm20, qdss_stm21, qdss_stm22, + qdss_stm23, qdss_stm24, qdss_stm25, qdss_stm26, qdss_stm27, + qdss_stm28, qdss_stm29, qdss_stm30, qdss_stm31, qlink0_en, + qlink0_req, qlink0_wmss, qlink1_en, qlink1_req, qlink1_wmss, + spmi_coex, sec_mi2s, spmi_vgi, tgu_ch0, uim1_clk, uim1_data, + uim1_present, uim1_reset, uim2_clk, uim2_data, uim2_present, + uim2_reset, usb2phy_ac, vsense_trigger ] + + drive-strength: + enum: [2, 4, 6, 8, 10, 12, 14, 16] + default: 2 + description: + Selects the drive strength for the specified pins, in mA. + + bias-pull-down: true + + bias-pull-up: true + + bias-disable: true + + output-high: true + + output-low: true + + required: + - pins + - function + + additionalProperties: false + +required: + - compatible + - reg + - interrupts + - interrupt-controller + - '#interrupt-cells' + - gpio-controller + - '#gpio-cells' + - gpio-ranges + +additionalProperties: false + +examples: + - | + #include + tlmm: pinctrl@1f00000 { + compatible = "qcom,sdx55-pinctrl"; + reg = <0x0f100000 0x300000>; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&tlmm 0 0 108>; + interrupt-controller; + #interrupt-cells = <2>; + interrupts = ; + + serial-pins { + pins = "gpio8", "gpio9"; + function = "blsp_uart3"; + drive-strength = <8>; + bias-disable; + }; + }; + +... -- cgit v1.2.3 From 8d936bb13ce788c616084ab1a5754da3490a9f0c Mon Sep 17 00:00:00 2001 From: Flavio Suligoi Date: Tue, 10 Nov 2020 14:03:38 +0100 Subject: Documentation: ACPI: fix spelling mistakes Signed-off-by: Flavio Suligoi Signed-off-by: Rafael J. Wysocki --- Documentation/firmware-guide/acpi/acpi-lid.rst | 8 ++++---- Documentation/firmware-guide/acpi/method-tracing.rst | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/firmware-guide/acpi/acpi-lid.rst b/Documentation/firmware-guide/acpi/acpi-lid.rst index 874ce0ed340d..71b9af13a048 100644 --- a/Documentation/firmware-guide/acpi/acpi-lid.rst +++ b/Documentation/firmware-guide/acpi/acpi-lid.rst @@ -19,9 +19,9 @@ report the "current" state of the lid as either "opened" or "closed". For most platforms, both the _LID method and the lid notifications are reliable. However, there are exceptions. In order to work with these -exceptional buggy platforms, special restrictions and expections should be +exceptional buggy platforms, special restrictions and exceptions should be taken into account. This document describes the restrictions and the -expections of the Linux ACPI lid device driver. +exceptions of the Linux ACPI lid device driver. Restrictions of the returning value of the _LID control method @@ -46,7 +46,7 @@ state is changed to "closed". The "closed" notification is normally used to trigger some system power saving operations on Windows. Since it is fully tested, it is reliable from all AML tables. -Expections for the userspace users of the ACPI lid device driver +Exceptions for the userspace users of the ACPI lid device driver ================================================================ The ACPI button driver exports the lid state to the userspace via the @@ -100,7 +100,7 @@ use the following kernel parameter: C. button.lid_init_state=ignore: When this option is specified, the ACPI button driver never reports the initial lid state and there is a compensation mechanism implemented to - ensure that the reliable "closed" notifications can always be delievered + ensure that the reliable "closed" notifications can always be delivered to the userspace by always pairing "closed" input events with complement "opened" input events. But there is still no guarantee that the "opened" notifications can be delivered to the userspace when the lid is actually diff --git a/Documentation/firmware-guide/acpi/method-tracing.rst b/Documentation/firmware-guide/acpi/method-tracing.rst index 0aa7e2c5d32a..6ab6c0964042 100644 --- a/Documentation/firmware-guide/acpi/method-tracing.rst +++ b/Documentation/firmware-guide/acpi/method-tracing.rst @@ -98,7 +98,7 @@ subject to change:: [ 0.188903] exdebug-0398 ex_trace_point : Method End [0xf58394d8:\_SB.PCI0.LPCB.ECOK] execution. Developers can utilize these special log entries to track the AML -interpretion, thus can aid issue debugging and performance tuning. Note +interpretation, thus can aid issue debugging and performance tuning. Note that, as the "AML tracer" logs are implemented via ACPI_DEBUG_PRINT() macro, CONFIG_ACPI_DEBUG is also required to be enabled for enabling "AML tracer" logs. -- cgit v1.2.3 From 5a64f775691647c242aa40d34f3512e7b179a921 Mon Sep 17 00:00:00 2001 From: Lukasz Luba Date: Tue, 3 Nov 2020 09:05:58 +0000 Subject: PM: EM: Clarify abstract scale usage for power values in Energy Model The Energy Model (EM) can store power values in milli-Watts or in abstract scale. This might cause issues in the subsystems which use the EM for estimating the device power, such as: - mixing of different scales in a subsystem which uses multiple (cooling) devices (e.g. thermal Intelligent Power Allocation (IPA)) - assuming that energy [milli-Joules] can be derived from the EM power values which might not be possible since the power scale doesn't have to be in milli-Watts To avoid misconfiguration add the requisite documentation to the EM and related subsystems: EAS and IPA. Signed-off-by: Lukasz Luba Signed-off-by: Rafael J. Wysocki --- Documentation/driver-api/thermal/power_allocator.rst | 12 +++++++++++- Documentation/power/energy-model.rst | 13 +++++++++++++ Documentation/scheduler/sched-energy.rst | 5 +++++ 3 files changed, 29 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/thermal/power_allocator.rst b/Documentation/driver-api/thermal/power_allocator.rst index 67b6a3297238..aa5f66552d6f 100644 --- a/Documentation/driver-api/thermal/power_allocator.rst +++ b/Documentation/driver-api/thermal/power_allocator.rst @@ -71,7 +71,9 @@ to the speed-grade of the silicon. `sustainable_power` is therefore simply an estimate, and may be tuned to affect the aggressiveness of the thermal ramp. For reference, the sustainable power of a 4" phone is typically 2000mW, while on a 10" tablet is around 4500mW (may vary -depending on screen size). +depending on screen size). It is possible to have the power value +expressed in an abstract scale. The sustained power should be aligned +to the scale used by the related cooling devices. If you are using device tree, do add it as a property of the thermal-zone. For example:: @@ -269,3 +271,11 @@ won't be very good. Note that this is not particular to this governor, step-wise will also misbehave if you call its throttle() faster than the normal thermal framework tick (due to interrupts for example) as it will overreact. + +Energy Model requirements +========================= + +Another important thing is the consistent scale of the power values +provided by the cooling devices. All of the cooling devices in a single +thermal zone should have power values reported either in milli-Watts +or scaled to the same 'abstract scale'. diff --git a/Documentation/power/energy-model.rst b/Documentation/power/energy-model.rst index a6fb986abe3c..ba7aa581b307 100644 --- a/Documentation/power/energy-model.rst +++ b/Documentation/power/energy-model.rst @@ -20,6 +20,19 @@ possible source of information on its own, the EM framework intervenes as an abstraction layer which standardizes the format of power cost tables in the kernel, hence enabling to avoid redundant work. +The power values might be expressed in milli-Watts or in an 'abstract scale'. +Multiple subsystems might use the EM and it is up to the system integrator to +check that the requirements for the power value scale types are met. An example +can be found in the Energy-Aware Scheduler documentation +Documentation/scheduler/sched-energy.rst. For some subsystems like thermal or +powercap power values expressed in an 'abstract scale' might cause issues. +These subsystems are more interested in estimation of power used in the past, +thus the real milli-Watts might be needed. An example of these requirements can +be found in the Intelligent Power Allocation in +Documentation/driver-api/thermal/power_allocator.rst. +Important thing to keep in mind is that when the power values are expressed in +an 'abstract scale' deriving real energy in milli-Joules would not be possible. + The figure below depicts an example of drivers (Arm-specific here, but the approach is applicable to any architecture) providing power costs to the EM framework, and interested clients reading the data from it:: diff --git a/Documentation/scheduler/sched-energy.rst b/Documentation/scheduler/sched-energy.rst index 001e09c95e1d..afe02d394402 100644 --- a/Documentation/scheduler/sched-energy.rst +++ b/Documentation/scheduler/sched-energy.rst @@ -350,6 +350,11 @@ independent EM framework in Documentation/power/energy-model.rst. Please also note that the scheduling domains need to be re-built after the EM has been registered in order to start EAS. +EAS uses the EM to make a forecasting decision on energy usage and thus it is +more focused on the difference when checking possible options for task +placement. For EAS it doesn't matter whether the EM power values are expressed +in milli-Watts or in an 'abstract scale'. + 6.3 - Energy Model complexity ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -- cgit v1.2.3 From b56a352c0d3ca4640c3c6364e592be360ac0d6d4 Mon Sep 17 00:00:00 2001 From: Lukasz Luba Date: Tue, 3 Nov 2020 09:06:00 +0000 Subject: PM: EM: Update Energy Model with new flag indicating power scale Update description and meaning of a new flag, which indicates the type of power scale used for a registered Energy Model (EM) device. Reviewed-by: Quentin Perret Signed-off-by: Lukasz Luba Signed-off-by: Rafael J. Wysocki --- Documentation/power/energy-model.rst | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/power/energy-model.rst b/Documentation/power/energy-model.rst index ba7aa581b307..60ac091d3b0d 100644 --- a/Documentation/power/energy-model.rst +++ b/Documentation/power/energy-model.rst @@ -30,6 +30,8 @@ These subsystems are more interested in estimation of power used in the past, thus the real milli-Watts might be needed. An example of these requirements can be found in the Intelligent Power Allocation in Documentation/driver-api/thermal/power_allocator.rst. +Kernel subsystems might implement automatic detection to check whether EM +registered devices have inconsistent scale (based on EM internal flag). Important thing to keep in mind is that when the power values are expressed in an 'abstract scale' deriving real energy in milli-Joules would not be possible. @@ -86,7 +88,7 @@ Drivers are expected to register performance domains into the EM framework by calling the following API:: int em_dev_register_perf_domain(struct device *dev, unsigned int nr_states, - struct em_data_callback *cb, cpumask_t *cpus); + struct em_data_callback *cb, cpumask_t *cpus, bool milliwatts); Drivers must provide a callback function returning tuples for each performance state. The callback function provided by the driver is free @@ -94,6 +96,10 @@ to fetch data from any relevant location (DT, firmware, ...), and by any mean deemed necessary. Only for CPU devices, drivers must specify the CPUs of the performance domains using cpumask. For other devices than CPUs the last argument must be set to NULL. +The last argument 'milliwatts' is important to set with correct value. Kernel +subsystems which use EM might rely on this flag to check if all EM devices use +the same scale. If there are different scales, these subsystems might decide +to: return warning/error, stop working or panic. See Section 3. for an example of driver implementing this callback, and kernel/power/energy_model.c for further documentation on this API. @@ -169,7 +175,8 @@ EM framework:: 37 nr_opp = foo_get_nr_opp(policy); 38 39 /* And register the new performance domain */ - 40 em_dev_register_perf_domain(cpu_dev, nr_opp, &em_cb, policy->cpus); - 41 - 42 return 0; - 43 } + 40 em_dev_register_perf_domain(cpu_dev, nr_opp, &em_cb, policy->cpus, + 41 true); + 42 + 43 return 0; + 44 } -- cgit v1.2.3 From f7766424cf15fd6e03e8230fb17d5612c5b76dbe Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Tue, 27 Oct 2020 11:48:53 -0700 Subject: KUnit: Docs: fix a wording typo Fix a wording typo (keyboard glitch). Signed-off-by: Randy Dunlap Cc: David Gow Cc: linux-kselftest@vger.kernel.org Cc: kunit-dev@googlegroups.com Cc: Shuah Khan Cc: Shuah Khan Cc: Brendan Higgins Reviewed-by: David Gow Signed-off-by: Shuah Khan --- Documentation/dev-tools/kunit/faq.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/kunit/faq.rst b/Documentation/dev-tools/kunit/faq.rst index 1628862e7024..8d5029ad210a 100644 --- a/Documentation/dev-tools/kunit/faq.rst +++ b/Documentation/dev-tools/kunit/faq.rst @@ -90,7 +90,7 @@ things to try. re-run kunit_tool. 5. Try to run ``make ARCH=um defconfig`` before running ``kunit.py run``. This may help clean up any residual config items which could be causing problems. -6. Finally, try running KUnit outside UML. KUnit and KUnit tests can run be +6. Finally, try running KUnit outside UML. KUnit and KUnit tests can be built into any kernel, or can be built as a module and loaded at runtime. Doing so should allow you to determine if UML is causing the issue you're seeing. When tests are built-in, they will execute when the kernel boots, and -- cgit v1.2.3 From 1f4dde57125b3d91b900e82ac33a196312be5c8e Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Wed, 28 Oct 2020 10:42:18 -0700 Subject: KUnit: Docs: style: fix some Kconfig example issues Fix the Kconfig example to be closer to Kconfig coding style. Also add punctuation and a trailing slash ('/') to a sub-directory name -- this is how the text mostly appears in other Kconfig files. Signed-off-by: Randy Dunlap Cc: David Gow Cc: linux-kselftest@vger.kernel.org Cc: kunit-dev@googlegroups.com Cc: Shuah Khan Cc: Shuah Khan Cc: Brendan Higgins Reviewed-by: David Gow Signed-off-by: Shuah Khan --- Documentation/dev-tools/kunit/style.rst | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/kunit/style.rst b/Documentation/dev-tools/kunit/style.rst index da1d6f0ed6bc..8dbcdc552606 100644 --- a/Documentation/dev-tools/kunit/style.rst +++ b/Documentation/dev-tools/kunit/style.rst @@ -175,17 +175,17 @@ An example Kconfig entry: .. code-block:: none - config FOO_KUNIT_TEST - tristate "KUnit test for foo" if !KUNIT_ALL_TESTS - depends on KUNIT - default KUNIT_ALL_TESTS - help - This builds unit tests for foo. + config FOO_KUNIT_TEST + tristate "KUnit test for foo" if !KUNIT_ALL_TESTS + depends on KUNIT + default KUNIT_ALL_TESTS + help + This builds unit tests for foo. - For more information on KUnit and unit tests in general, please refer - to the KUnit documentation in Documentation/dev-tools/kunit + For more information on KUnit and unit tests in general, please refer + to the KUnit documentation in Documentation/dev-tools/kunit/. - If unsure, say N + If unsure, say N. Test File and Module Names -- cgit v1.2.3 From 873ddeb881e055fb0c4e371cc3a006bfd9388f00 Mon Sep 17 00:00:00 2001 From: Randy Dunlap Date: Wed, 28 Oct 2020 10:43:19 -0700 Subject: KUnit: Docs: usage: wording fixes Fix minor grammar and punctutation glitches. Hyphenate "architecture-specific" instances. Signed-off-by: Randy Dunlap Cc: David Gow Cc: linux-kselftest@vger.kernel.org Cc: kunit-dev@googlegroups.com Cc: Shuah Khan Cc: Shuah Khan Cc: Brendan Higgins Reviewed-by: David Gow Signed-off-by: Shuah Khan --- Documentation/dev-tools/kunit/usage.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst index 62142a47488c..9c28c518e6a3 100644 --- a/Documentation/dev-tools/kunit/usage.rst +++ b/Documentation/dev-tools/kunit/usage.rst @@ -92,7 +92,7 @@ behavior of a function called ``add``; the first parameter is always of type the second parameter, in this case, is what the value is expected to be; the last value is what the value actually is. If ``add`` passes all of these expectations, the test case, ``add_test_basic`` will pass; if any one of these -expectations fail, the test case will fail. +expectations fails, the test case will fail. It is important to understand that a test case *fails* when any expectation is violated; however, the test will continue running, potentially trying other @@ -202,7 +202,7 @@ Example: kunit_test_suite(example_test_suite); In the above example the test suite, ``example_test_suite``, would run the test -cases ``example_test_foo``, ``example_test_bar``, and ``example_test_baz``, +cases ``example_test_foo``, ``example_test_bar``, and ``example_test_baz``; each would have ``example_test_init`` called immediately before it and would have ``example_test_exit`` called immediately after it. ``kunit_test_suite(example_test_suite)`` registers the test suite with the @@ -229,7 +229,7 @@ through some sort of indirection where a function is exposed as part of an API such that the definition of that function can be changed without affecting the rest of the code base. In the kernel this primarily comes from two constructs, classes, structs that contain function pointers that are provided by the -implementer, and architecture specific functions which have definitions selected +implementer, and architecture-specific functions which have definitions selected at compile time. Classes @@ -459,7 +459,7 @@ KUnit on non-UML architectures By default KUnit uses UML as a way to provide dependencies for code under test. Under most circumstances KUnit's usage of UML should be treated as an implementation detail of how KUnit works under the hood. Nevertheless, there -are instances where being able to run architecture specific code or test +are instances where being able to run architecture-specific code or test against real hardware is desirable. For these reasons KUnit supports running on other architectures. @@ -599,7 +599,7 @@ writing normal KUnit tests. One special caveat is that you have to reset hardware state in between test cases; if this is not possible, you may only be able to run one test case per invocation. -.. TODO(brendanhiggins@google.com): Add an actual example of an architecture +.. TODO(brendanhiggins@google.com): Add an actual example of an architecture- dependent KUnit test. KUnit debugfs representation -- cgit v1.2.3 From 36e68442d1afd4f720704ee1ea8486331507e834 Mon Sep 17 00:00:00 2001 From: Andrii Nakryiko Date: Mon, 9 Nov 2020 17:19:31 -0800 Subject: bpf: Load and verify kernel module BTFs Add kernel module listener that will load/validate and unload module BTF. Module BTFs gets ID generated for them, which makes it possible to iterate them with existing BTF iteration API. They are given their respective module's names, which will get reported through GET_OBJ_INFO API. They are also marked as in-kernel BTFs for tooling to distinguish them from user-provided BTFs. Also, similarly to vmlinux BTF, kernel module BTFs are exposed through sysfs as /sys/kernel/btf/. This is convenient for user-space tools to inspect module BTF contents and dump their types with existing tools: [vmuser@archvm bpf]$ ls -la /sys/kernel/btf total 0 drwxr-xr-x 2 root root 0 Nov 4 19:46 . drwxr-xr-x 13 root root 0 Nov 4 19:46 .. ... -r--r--r-- 1 root root 888 Nov 4 19:46 irqbypass -r--r--r-- 1 root root 100225 Nov 4 19:46 kvm -r--r--r-- 1 root root 35401 Nov 4 19:46 kvm_intel -r--r--r-- 1 root root 120 Nov 4 19:46 pcspkr -r--r--r-- 1 root root 399 Nov 4 19:46 serio_raw -r--r--r-- 1 root root 4094095 Nov 4 19:46 vmlinux Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Reviewed-by: Greg Kroah-Hartman Link: https://lore.kernel.org/bpf/20201110011932.3201430-5-andrii@kernel.org --- Documentation/ABI/testing/sysfs-kernel-btf | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-kernel-btf b/Documentation/ABI/testing/sysfs-kernel-btf index 2c9744b2cd59..fe96efdc9b6c 100644 --- a/Documentation/ABI/testing/sysfs-kernel-btf +++ b/Documentation/ABI/testing/sysfs-kernel-btf @@ -15,3 +15,11 @@ Description: information with description of all internal kernel types. See Documentation/bpf/btf.rst for detailed description of format itself. + +What: /sys/kernel/btf/ +Date: Nov 2020 +KernelVersion: 5.11 +Contact: bpf@vger.kernel.org +Description: + Read-only binary attribute exposing kernel module's BTF type + information as an add-on to the kernel's BTF (/sys/kernel/btf/vmlinux). -- cgit v1.2.3 From 4210d50f0b3e423e10a7a254b2a67f5c5318868e Mon Sep 17 00:00:00 2001 From: Isaac Hazan Date: Thu, 24 Sep 2020 11:43:58 +0300 Subject: thunderbolt: Add link_speed and link_width to XDomain Link speed and link width are needed for checking expected values in case of using a loopback service. Signed-off-by: Isaac Hazan Signed-off-by: Mika Westerberg Acked-by: Yehezkel Bernat Reviewed-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-bus-thunderbolt | 28 +++++++++++++++++++++++++ 1 file changed, 28 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-thunderbolt b/Documentation/ABI/testing/sysfs-bus-thunderbolt index 0b4ab9e4b8f4..a91b4b24496e 100644 --- a/Documentation/ABI/testing/sysfs-bus-thunderbolt +++ b/Documentation/ABI/testing/sysfs-bus-thunderbolt @@ -1,3 +1,31 @@ +What: /sys/bus/thunderbolt/devices//rx_speed +Date: Feb 2021 +KernelVersion: 5.11 +Contact: Isaac Hazan +Description: This attribute reports the XDomain RX speed per lane. + All RX lanes run at the same speed. + +What: /sys/bus/thunderbolt/devices//rx_lanes +Date: Feb 2021 +KernelVersion: 5.11 +Contact: Isaac Hazan +Description: This attribute reports the number of RX lanes the XDomain + is using simultaneously through its upstream port. + +What: /sys/bus/thunderbolt/devices//tx_speed +Date: Feb 2021 +KernelVersion: 5.11 +Contact: Isaac Hazan +Description: This attribute reports the XDomain TX speed per lane. + All TX lanes run at the same speed. + +What: /sys/bus/thunderbolt/devices//tx_lanes +Date: Feb 2021 +KernelVersion: 5.11 +Contact: Isaac Hazan +Description: This attribute reports number of TX lanes the XDomain + is using simultaneously through its upstream port. + What: /sys/bus/thunderbolt/devices/.../domainX/boot_acl Date: Jun 2018 KernelVersion: 4.17 -- cgit v1.2.3 From 49c3e714ff4391144d8bb3fa99d0b460f8dbfd86 Mon Sep 17 00:00:00 2001 From: Marc Kleine-Budde Date: Wed, 11 Nov 2020 14:05:07 +0100 Subject: dt-bindings: can: fsl,flexcan.yaml: fix fsl,stop-mode The fsl,stop-mode property is a phandle-array and should consist of one phandle and two 32 bit integers, e.g.: fsl,stop-mode = <&gpr 0x34 28>; This patch fixes the following errors, which shows up during a dtbs_check: arch/arm/boot/dts/imx6dl-apf6dev.dt.yaml: can@2090000: fsl,stop-mode: [[1, 52, 28]] is too short From schema: Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml Fixes: e5ab9aa7e49b ("dt-bindings: can: flexcan: convert fsl,*flexcan bindings to yaml") Reported-by: Rob Herring Cc: Oleksij Rempel Signed-off-by: Marc Kleine-Budde Link: https://lore.kernel.org/r/20201111130507.1560881-5-mkl@pengutronix.de Signed-off-by: Rob Herring --- Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml b/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml index 43df15ba8fa4..3093c22e761c 100644 --- a/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml +++ b/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml @@ -81,11 +81,12 @@ properties: req_bit is the bit offset of CAN stop request. $ref: /schemas/types.yaml#/definitions/phandle-array items: - - description: The 'gpr' is the phandle to general purpose register node. - - description: The 'req_gpr' is the gpr register offset of CAN stop request. - maximum: 0xff - - description: The 'req_bit' is the bit offset of CAN stop request. - maximum: 0x1f + items: + - description: The 'gpr' is the phandle to general purpose register node. + - description: The 'req_gpr' is the gpr register offset of CAN stop request. + maximum: 0xff + - description: The 'req_bit' is the bit offset of CAN stop request. + maximum: 0x1f fsl,clk-source: description: | -- cgit v1.2.3 From c0c5a60f0f1311bcf08bbe735122096d6326fb5b Mon Sep 17 00:00:00 2001 From: Vincent Bernat Date: Sat, 7 Nov 2020 20:35:13 +0100 Subject: net: evaluate net.ipvX.conf.all.ignore_routes_with_linkdown Introduced in 0eeb075fad73, the "ignore_routes_with_linkdown" sysctl ignores a route whose interface is down. It is provided as a per-interface sysctl. However, while a "all" variant is exposed, it was a noop since it was never evaluated. We use the usual "or" logic for this kind of sysctls. Tested with: ip link add type veth # veth0 + veth1 ip link add type veth # veth1 + veth2 ip link set up dev veth0 ip link set up dev veth1 # link-status paired with veth0 ip link set up dev veth2 ip link set up dev veth3 # link-status paired with veth2 # First available path ip -4 addr add 203.0.113.${uts#H}/24 dev veth0 ip -6 addr add 2001:db8:1::${uts#H}/64 dev veth0 # Second available path ip -4 addr add 192.0.2.${uts#H}/24 dev veth2 ip -6 addr add 2001:db8:2::${uts#H}/64 dev veth2 # More specific route through first path ip -4 route add 198.51.100.0/25 via 203.0.113.254 # via veth0 ip -6 route add 2001:db8:3::/56 via 2001:db8:1::ff # via veth0 # Less specific route through second path ip -4 route add 198.51.100.0/24 via 192.0.2.254 # via veth2 ip -6 route add 2001:db8:3::/48 via 2001:db8:2::ff # via veth2 # H1: enable on "all" # H2: enable on "veth0" for v in ipv4 ipv6; do case $uts in H1) sysctl -qw net.${v}.conf.all.ignore_routes_with_linkdown=1 ;; H2) sysctl -qw net.${v}.conf.veth0.ignore_routes_with_linkdown=1 ;; esac done set -xe # When veth0 is up, best route is through veth0 ip -o route get 198.51.100.1 | grep -Fw veth0 ip -o route get 2001:db8:3::1 | grep -Fw veth0 # When veth0 is down, best route should be through veth2 on H1/H2, # but on veth0 on H2 ip link set down dev veth1 # down veth0 ip route show [ $uts != H3 ] || ip -o route get 198.51.100.1 | grep -Fw veth0 [ $uts != H3 ] || ip -o route get 2001:db8:3::1 | grep -Fw veth0 [ $uts = H3 ] || ip -o route get 198.51.100.1 | grep -Fw veth2 [ $uts = H3 ] || ip -o route get 2001:db8:3::1 | grep -Fw veth2 Without this patch, the two last lines would fail on H1 (the one using the "all" sysctl). With the patch, everything succeeds as expected. Also document the sysctl in `ip-sysctl.rst`. Fixes: 0eeb075fad73 ("net: ipv4 sysctl option to ignore routes when nexthop link is down") Signed-off-by: Vincent Bernat Signed-off-by: Jakub Kicinski --- Documentation/networking/ip-sysctl.rst | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index 2aaf40b2d2cd..dd2b12a32b73 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -1554,6 +1554,9 @@ igmpv3_unsolicited_report_interval - INTEGER Default: 1000 (1 seconds) +ignore_routes_with_linkdown - BOOLEAN + Ignore routes whose link is down when performing a FIB lookup. + promote_secondaries - BOOLEAN When a primary IP address is removed from this interface promote a corresponding secondary IP address instead of -- cgit v1.2.3 From 460cd17e9f7d60eaa22028baa6a056c478fa7dc6 Mon Sep 17 00:00:00 2001 From: Jakub Kicinski Date: Mon, 9 Nov 2020 19:51:20 -0800 Subject: net: switch to the kernel.org patchwork instance Move to the kernel.org patchwork instance, it has significantly lower latency for accessing from Europe and the US. Other quirks include the reply bot. Link: https://lore.kernel.org/r/20201110035120.642746-1-kuba@kernel.org Signed-off-by: Jakub Kicinski --- Documentation/networking/netdev-FAQ.rst | 4 ++-- Documentation/process/stable-kernel-rules.rst | 2 +- Documentation/translations/it_IT/process/stable-kernel-rules.rst | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/netdev-FAQ.rst b/Documentation/networking/netdev-FAQ.rst index d5c9320901c3..21537766be4d 100644 --- a/Documentation/networking/netdev-FAQ.rst +++ b/Documentation/networking/netdev-FAQ.rst @@ -110,7 +110,7 @@ Q: I sent a patch and I'm wondering what happened to it? Q: How can I tell whether it got merged? A: Start by looking at the main patchworks queue for netdev: - http://patchwork.ozlabs.org/project/netdev/list/ + https://patchwork.kernel.org/project/netdevbpf/list/ The "State" field will tell you exactly where things are at with your patch. @@ -152,7 +152,7 @@ networking subsystem, and then hands them off to Greg. There is a patchworks queue that you can see here: - http://patchwork.ozlabs.org/bundle/davem/stable/?state=* + https://patchwork.kernel.org/bundle/netdev/stable/?state=* It contains the patches which Dave has selected, but not yet handed off to Greg. If Greg already has the patch, then it will be here: diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst index 06f743b612c4..3973556250e1 100644 --- a/Documentation/process/stable-kernel-rules.rst +++ b/Documentation/process/stable-kernel-rules.rst @@ -39,7 +39,7 @@ Procedure for submitting patches to the -stable tree submission guidelines as described in :ref:`Documentation/networking/netdev-FAQ.rst ` after first checking the stable networking queue at - https://patchwork.ozlabs.org/bundle/davem/stable/?series=&submitter=&state=*&q=&archive= + https://patchwork.kernel.org/bundle/netdev/stable/?state=* to ensure the requested patch is not already queued up. - Security patches should not be handled (solely) by the -stable review process but should follow the procedures in diff --git a/Documentation/translations/it_IT/process/stable-kernel-rules.rst b/Documentation/translations/it_IT/process/stable-kernel-rules.rst index 4f206cee31a7..283d62541c4f 100644 --- a/Documentation/translations/it_IT/process/stable-kernel-rules.rst +++ b/Documentation/translations/it_IT/process/stable-kernel-rules.rst @@ -46,7 +46,7 @@ Procedura per sottomettere patch per i sorgenti -stable :ref:`Documentation/translations/it_IT/networking/netdev-FAQ.rst `; ma solo dopo aver verificato al seguente indirizzo che la patch non sia già in coda: - https://patchwork.ozlabs.org/bundle/davem/stable/?series=&submitter=&state=*&q=&archive= + https://patchwork.kernel.org/bundle/netdev/stable/?state=* - Una patch di sicurezza non dovrebbero essere gestite (solamente) dal processo di revisione -stable, ma dovrebbe seguire le procedure descritte in :ref:`Documentation/translations/it_IT/admin-guide/security-bugs.rst `. -- cgit v1.2.3 From 439e8f6f1e5d1ca973da278499078e213dad63bb Mon Sep 17 00:00:00 2001 From: Ivan Zaentsev Date: Thu, 12 Nov 2020 09:49:31 +0300 Subject: w1: w1_therm: Rename conflicting sysfs attribute 'eeprom' to 'eeprom_cmd' Duplicate attribute 'eeprom' is defined in: 1) Documentation/ABI/testing/sysfs-driver-w1_therm 2) Documentation/ABI/stable/sysfs-driver-w1_ds28e04 Both drivers define an attribute: /sys/bus/w1/devices/.../eeprom with conflicting behavior. Fix by renaming the newer one in w1_therm.c to 'eeprom_cmd'. Reported-by: Mauro Carvalho Chehab Suggested-by: Greg Kroah-Hartman Link: https://lore.kernel.org/lkml/20201029152845.6bbb39ce@coco.lan/ Signed-off-by: Ivan Zaentsev Link: https://lore.kernel.org/r/20201112064931.8471-1-ivan.zaentsev@wirenboard.ru Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-driver-w1_therm | 2 +- Documentation/w1/slaves/w1_therm.rst | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-driver-w1_therm b/Documentation/ABI/testing/sysfs-driver-w1_therm index 6a37dc33ffdb..74642c73d29c 100644 --- a/Documentation/ABI/testing/sysfs-driver-w1_therm +++ b/Documentation/ABI/testing/sysfs-driver-w1_therm @@ -14,7 +14,7 @@ Users: any user space application which wants to communicate with w1_term device -What: /sys/bus/w1/devices/.../eeprom +What: /sys/bus/w1/devices/.../eeprom_cmd Date: May 2020 Contact: Akira Shimahara Description: diff --git a/Documentation/w1/slaves/w1_therm.rst b/Documentation/w1/slaves/w1_therm.rst index e39202e2b000..c3c9ed7a356c 100644 --- a/Documentation/w1/slaves/w1_therm.rst +++ b/Documentation/w1/slaves/w1_therm.rst @@ -82,7 +82,7 @@ resolution is read back from the chip and verified. Note: Changing the resolution reverts the conversion time to default. -The write-only sysfs entry ``eeprom`` is an alternative for EEPROM operations. +The write-only sysfs entry ``eeprom_cmd`` is an alternative for EEPROM operations. Write ``save`` to save device RAM to EEPROM. Write ``restore`` to restore EEPROM data in device RAM. -- cgit v1.2.3 From 5830fb6b54f7167cc7c9d43612eb01c24312c7ca Mon Sep 17 00:00:00 2001 From: Pavel Tikhomirov Date: Tue, 13 Oct 2020 17:59:54 +0300 Subject: ovl: introduce new "uuid=off" option for inodes index feature This replaces uuid with null in overlayfs file handles and thus relaxes uuid checks for overlay index feature. It is only possible in case there is only one filesystem for all the work/upper/lower directories and bare file handles from this backing filesystem are unique. In other case when we have multiple filesystems lets just fallback to "uuid=on" which is and equivalent of how it worked before with all uuid checks. This is needed when overlayfs is/was mounted in a container with index enabled (e.g.: to be able to resolve inotify watch file handles on it to paths in CRIU), and this container is copied and started alongside with the original one. This way the "copy" container can't have the same uuid on the superblock and mounting the overlayfs from it later would fail. That is an example of the problem on top of loop+ext4: dd if=/dev/zero of=loopbackfile.img bs=100M count=10 losetup -fP loopbackfile.img losetup -a #/dev/loop0: [64768]:35 (/loop-test/loopbackfile.img) mkfs.ext4 loopbackfile.img mkdir loop-mp mount -o loop /dev/loop0 loop-mp mkdir loop-mp/{lower,upper,work,merged} mount -t overlay overlay -oindex=on,lowerdir=loop-mp/lower,\ upperdir=loop-mp/upper,workdir=loop-mp/work loop-mp/merged umount loop-mp/merged umount loop-mp e2fsck -f /dev/loop0 tune2fs -U random /dev/loop0 mount -o loop /dev/loop0 loop-mp mount -t overlay overlay -oindex=on,lowerdir=loop-mp/lower,\ upperdir=loop-mp/upper,workdir=loop-mp/work loop-mp/merged #mount: /loop-test/loop-mp/merged: #mount(2) system call failed: Stale file handle. If you just change the uuid of the backing filesystem, overlay is not mounting any more. In Virtuozzo we copy container disks (ploops) when create the copy of container and we require fs uuid to be unique for a new container. Signed-off-by: Pavel Tikhomirov Reviewed-by: Amir Goldstein Signed-off-by: Miklos Szeredi --- Documentation/filesystems/overlayfs.rst | 5 +++++ 1 file changed, 5 insertions(+) (limited to 'Documentation') diff --git a/Documentation/filesystems/overlayfs.rst b/Documentation/filesystems/overlayfs.rst index 580ab9a0fe31..a3e588dc8437 100644 --- a/Documentation/filesystems/overlayfs.rst +++ b/Documentation/filesystems/overlayfs.rst @@ -563,6 +563,11 @@ This verification may cause significant overhead in some cases. Note: the mount options index=off,nfs_export=on are conflicting for a read-write mount and will result in an error. +Note: the mount option uuid=off can be used to replace UUID of the underlying +filesystem in file handles with null, and effectively disable UUID checks. This +can be useful in case the underlying disk is copied and the UUID of this copy +is changed. This is only applicable if all lower/upper/work directories are on +the same filesystem, otherwise it will fallback to normal behaviour. Volatile mount -------------- -- cgit v1.2.3 From 58afaf5d605f091abf7491774e34fa29d4a1994c Mon Sep 17 00:00:00 2001 From: Miklos Szeredi Date: Thu, 12 Nov 2020 11:31:55 +0100 Subject: ovl: doc clarification Documentation says "The lower filesystem can be any filesystem supported by Linux". However, this is not the case, as Linux supports vfat and vfat doesn't work as a lower filesystem Reported-by: nerdopolis Signed-off-by: Miklos Szeredi --- Documentation/filesystems/overlayfs.rst | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/overlayfs.rst b/Documentation/filesystems/overlayfs.rst index a3e588dc8437..1ef4ef38b542 100644 --- a/Documentation/filesystems/overlayfs.rst +++ b/Documentation/filesystems/overlayfs.rst @@ -97,11 +97,13 @@ directory trees to be in the same filesystem and there is no requirement that the root of a filesystem be given for either upper or lower. -The lower filesystem can be any filesystem supported by Linux and does -not need to be writable. The lower filesystem can even be another -overlayfs. The upper filesystem will normally be writable and if it -is it must support the creation of trusted.* extended attributes, and -must provide valid d_type in readdir responses, so NFS is not suitable. +A wide range of filesystems supported by Linux can be the lower filesystem, +but not all filesystems that are mountable by Linux have the features +needed for OverlayFS to work. The lower filesystem does not need to be +writable. The lower filesystem can even be another overlayfs. The upper +filesystem will normally be writable and if it is it must support the +creation of trusted.* extended attributes, and must provide valid d_type in +readdir responses, so NFS is not suitable. A read-only overlay of two read-only filesystems may use any filesystem type. -- cgit v1.2.3 From 13c6ad0f45fd0382e77829a6c738f3e18739c15b Mon Sep 17 00:00:00 2001 From: Kevin Locke Date: Sat, 22 Aug 2020 20:22:57 -0600 Subject: ovl: document lower modification caveats Some overlayfs optional features are incompatible with offline changes to the lower tree and may result in -EXDEV, -EIO, or other errors. Such modification is not supported and the error behavior is intentionally not specified. Update the "Changes to underlying filesystems" section to note this restriction. Move the paragraph describing the offline behavior below the online behavior so it is adjacent to the following 3 paragraphs describing the NFS export offline modification behavior. Link: https://lore.kernel.org/linux-unionfs/20200708142353.GA103536@redhat.com/ Link: https://lore.kernel.org/linux-unionfs/CAOQ4uxi23Zsmfb4rCed1n=On0NNA5KZD74jjjeyz+et32sk-gg@mail.gmail.com/ Link: https://lore.kernel.org/linux-unionfs/20200817135651.GA637139@redhat.com/ Link: https://lore.kernel.org/linux-unionfs/20200709153616.GE150543@redhat.com/ Link: https://lore.kernel.org/linux-unionfs/20200812135529.GA122370@kevinolos/ Signed-off-by: Kevin Locke Signed-off-by: Miklos Szeredi --- Documentation/filesystems/overlayfs.rst | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/overlayfs.rst b/Documentation/filesystems/overlayfs.rst index 1ef4ef38b542..b86be7c6a952 100644 --- a/Documentation/filesystems/overlayfs.rst +++ b/Documentation/filesystems/overlayfs.rst @@ -469,14 +469,18 @@ summarized in the `Inode properties`_ table above. Changes to underlying filesystems --------------------------------- -Offline changes, when the overlay is not mounted, are allowed to either -the upper or the lower trees. - Changes to the underlying filesystems while part of a mounted overlay filesystem are not allowed. If the underlying filesystem is changed, the behavior of the overlay is undefined, though it will not result in a crash or deadlock. +Offline changes, when the overlay is not mounted, are allowed to the +upper tree. Offline changes to the lower tree are only allowed if the +"metadata only copy up", "inode index", and "redirect_dir" features +have not been used. If the lower tree is modified and any of these +features has been used, the behavior of the overlay is undefined, +though it will not result in a crash or deadlock. + When the overlay NFS export feature is enabled, overlay filesystems behavior on offline changes of the underlying lower layer is different than the behavior when NFS export is disabled. -- cgit v1.2.3 From 7cfa9770f485c03c877db4a66bbfda96df367b98 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Wed, 28 Oct 2020 16:35:41 +0100 Subject: dt-bindings: thermal: rcar-thermal: Improve schema validation MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Factor out common required properties, - "interrupts", "clocks", and "power-domains" are required on R-Mobile APE6, too, - Invert logic to simplify descriptions. Signed-off-by: Geert Uytterhoeven Reviewed-by: Niklas Söderlund Reviewed-by: Amit Kucheria Reviewed-by: Rob Herring Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20201028153541.1736279-1-geert+renesas@glider.be --- .../devicetree/bindings/thermal/rcar-thermal.yaml | 48 +++++++++++++--------- 1 file changed, 29 insertions(+), 19 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/thermal/rcar-thermal.yaml b/Documentation/devicetree/bindings/thermal/rcar-thermal.yaml index 7e9557ac0e4a..927de79ab4b5 100644 --- a/Documentation/devicetree/bindings/thermal/rcar-thermal.yaml +++ b/Documentation/devicetree/bindings/thermal/rcar-thermal.yaml @@ -62,25 +62,35 @@ properties: "#thermal-sensor-cells": const: 0 -if: - properties: - compatible: - contains: - enum: - - renesas,thermal-r8a73a4 # R-Mobile APE6 - - renesas,thermal-r8a7779 # R-Car H1 -then: - required: - - compatible - - reg -else: - required: - - compatible - - reg - - interrupts - - clocks - - power-domains - - resets +required: + - compatible + - reg + +allOf: + - if: + not: + properties: + compatible: + contains: + enum: + - renesas,thermal-r8a73a4 # R-Mobile APE6 + - renesas,thermal-r8a7779 # R-Car H1 + then: + required: + - resets + - '#thermal-sensor-cells' + + - if: + not: + properties: + compatible: + contains: + const: renesas,thermal-r8a7779 # R-Car H1 + then: + required: + - interrupts + - clocks + - power-domains additionalProperties: false -- cgit v1.2.3 From ce7c01557465e920f5bccc5878b8dec165eeb80b Mon Sep 17 00:00:00 2001 From: Viresh Kumar Date: Tue, 10 Nov 2020 16:13:37 +0530 Subject: docs: thermal: time_in_state is displayed in msec and not usertime The sysfs stats for cooling devices shows the time_in_state in msec, remove the unwanted usertime comment. Signed-off-by: Viresh Kumar Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/d5461bdf9ab6b6fee7f28f538582edbb426aa077.1605004905.git.viresh.kumar@linaro.org --- Documentation/driver-api/thermal/sysfs-api.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/driver-api/thermal/sysfs-api.rst b/Documentation/driver-api/thermal/sysfs-api.rst index b40b1f839148..e7520cb439ac 100644 --- a/Documentation/driver-api/thermal/sysfs-api.rst +++ b/Documentation/driver-api/thermal/sysfs-api.rst @@ -654,8 +654,7 @@ stats/time_in_state_ms: The amount of time spent by the cooling device in various cooling states. The output will have "