From: Maxime Ripard <hidden> Date: 2021-07-21 14:04:38
Even though we had the wm8978 driver for some time and a number of
boards using it already, we never had a binding for it. Let's add it
based on what the driver expects and the boards are providing.
Cc: alsa-devel@alsa-project.org
Cc: devicetree@vger.kernel.org
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Maxime Ripard <redacted>
---
.../devicetree/bindings/sound/wlf,wm8978.yaml | 58 +++++++++++++++++++
1 file changed, 58 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/wlf,wm8978.yaml
From: Rob Herring <robh@kernel.org> Date: 2021-07-23 21:32:55
On Wed, Jul 21, 2021 at 04:03:31PM +0200, Maxime Ripard wrote:
quoted hunk
Even though we had the wm8978 driver for some time and a number of
boards using it already, we never had a binding for it. Let's add it
based on what the driver expects and the boards are providing.
Cc: alsa-devel@alsa-project.org
Cc: devicetree@vger.kernel.org
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Maxime Ripard <redacted>
---
.../devicetree/bindings/sound/wlf,wm8978.yaml | 58 +++++++++++++++++++
1 file changed, 58 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/wlf,wm8978.yaml
@@ -0,0 +1,58 @@+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)+%YAML1.2+---+$id:http://devicetree.org/schemas/sound/wlf,wm8978.yaml#+$schema:http://devicetree.org/meta-schemas/core.yaml#++title:Wolfson WM8978 Codec Device Tree Bindings++maintainers:+-Mark Brown <broonie@kernel.org>
No one from Wolfson cares about this device?
Otherwise,
Reviewed-by: Rob Herring <robh@kernel.org>
From: Mark Brown <broonie@kernel.org> Date: 2021-07-26 00:17:38
On Fri, Jul 23, 2021 at 03:32:51PM -0600, Rob Herring wrote:
On Wed, Jul 21, 2021 at 04:03:31PM +0200, Maxime Ripard wrote:
quoted
Even though we had the wm8978 driver for some time and a number of
boards using it already, we never had a binding for it. Let's add it
based on what the driver expects and the boards are providing.
quoted
+maintainers:
+ - Mark Brown [off-list ref]
No one from Wolfson cares about this device?
Otherwise,
Reviewed-by: Rob Herring <robh@kernel.org>
Well, Wolfson no longer exists since it was bought by Cirrus but copying
in the Cirrus people to see if they want to be listed there.
From: Richard Fitzgerald <rf@opensource.cirrus.com> Date: 2021-07-27 12:37:19
On 26/07/2021 01:17, Mark Brown wrote:
On Fri, Jul 23, 2021 at 03:32:51PM -0600, Rob Herring wrote:
quoted
On Wed, Jul 21, 2021 at 04:03:31PM +0200, Maxime Ripard wrote:
quoted
quoted
Even though we had the wm8978 driver for some time and a number of
boards using it already, we never had a binding for it. Let's add it
based on what the driver expects and the boards are providing.
quoted
quoted
+maintainers:
+ - Mark Brown [off-list ref]
quoted
No one from Wolfson cares about this device?
quoted
Otherwise,
quoted
Reviewed-by: Rob Herring <robh@kernel.org>
Well, Wolfson no longer exists since it was bought by Cirrus but copying
in the Cirrus people to see if they want to be listed there.
People, ownership, and email addresses can change. It's always best to
check MAINTAINERS to see the current support status. In this case it has
a section to pick up those Wolfson drivers, with the correct email
address. The list email will be monitored by multiple people.
WOLFSON MICROELECTRONICS DRIVERS
L: patches@opensource.cirrus.com
S: Supported
<SNIP>
F: include/sound/wm????.h
<SNIP>
F: sound/soc/codecs/wm*
From: Mark Brown <broonie@kernel.org> Date: 2021-07-27 12:58:48
On Tue, Jul 27, 2021 at 01:21:52PM +0100, Richard Fitzgerald wrote:
On 26/07/2021 01:17, Mark Brown wrote:
quoted
On Fri, Jul 23, 2021 at 03:32:51PM -0600, Rob Herring wrote:
quoted
On Wed, Jul 21, 2021 at 04:03:31PM +0200, Maxime Ripard wrote:
quoted
quoted
quoted
Even though we had the wm8978 driver for some time and a number of
boards using it already, we never had a binding for it. Let's add it
based on what the driver expects and the boards are providing.
quoted
quoted
quoted
+maintainers:
+ - Mark Brown [off-list ref]
quoted
quoted
No one from Wolfson cares about this device?
quoted
quoted
Otherwise,
quoted
quoted
Reviewed-by: Rob Herring <robh@kernel.org>
quoted
Well, Wolfson no longer exists since it was bought by Cirrus but copying
in the Cirrus people to see if they want to be listed there.
People, ownership, and email addresses can change. It's always best to
check MAINTAINERS to see the current support status. In this case it has
a section to pick up those Wolfson drivers, with the correct email
address. The list email will be monitored by multiple people.
WOLFSON MICROELECTRONICS DRIVERS
L: patches@opensource.cirrus.com
S: Supported
<SNIP>
F: include/sound/wm????.h
<SNIP>
F: sound/soc/codecs/wm*
Might be worth updating that to cover the DT bindings too (Arizona is
the only sound driver for some reason, wm8974 already exists but is not
covered).
From: Maxime Ripard <hidden> Date: 2021-07-21 14:04:39
The SPDIF Transmitter binding is used by Linux with a matching Device
Tree binding.
Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.
Cc: alsa-devel@alsa-project.org
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Maxime Ripard <redacted>
---
.../bindings/sound/linux,spdif-dit.yaml | 32 +++++++++++++++++++
.../bindings/sound/spdif-transmitter.txt | 10 ------
2 files changed, 32 insertions(+), 10 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/linux,spdif-dit.yaml
delete mode 100644 Documentation/devicetree/bindings/sound/spdif-transmitter.txt
From: Rob Herring <robh@kernel.org> Date: 2021-07-23 21:35:16
On Wed, 21 Jul 2021 16:03:33 +0200, Maxime Ripard wrote:
The SPDIF Transmitter binding is used by Linux with a matching Device
Tree binding.
Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.
Cc: alsa-devel@alsa-project.org
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Maxime Ripard <redacted>
---
.../bindings/sound/linux,spdif-dit.yaml | 32 +++++++++++++++++++
.../bindings/sound/spdif-transmitter.txt | 10 ------
2 files changed, 32 insertions(+), 10 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/linux,spdif-dit.yaml
delete mode 100644 Documentation/devicetree/bindings/sound/spdif-transmitter.txt
From: Maxime Ripard <hidden> Date: 2021-07-21 14:04:39
Bluetooth SCO Link are supported by Linux with a matching device tree
binding.
Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.
The value expected for #sound-dai-cells wasn't documented though, and
the users were inconsistent. The example didn't list it, and across the
4 users we have in tree:
- 1 had a cells value of 1, but using only 0 as argument
- 1 had a cells value of 0,
- 2 didn't have this property at all, behaving as if it was 0,
It seems like the consensus seems to be that it should be 0, so let's
enforce it.
Cc: alsa-devel@alsa-project.org
Cc: devicetree@vger.kernel.org
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Samuel Holland <samuel@sholland.org>
Signed-off-by: Maxime Ripard <redacted>
---
.../devicetree/bindings/sound/bt-sco.txt | 13 -------
.../bindings/sound/linux,bt-sco.yaml | 34 +++++++++++++++++++
2 files changed, 34 insertions(+), 13 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/sound/bt-sco.txt
create mode 100644 Documentation/devicetree/bindings/sound/linux,bt-sco.yaml
From: Samuel Holland <samuel@sholland.org> Date: 2021-07-22 05:35:54
On 7/21/21 9:03 AM, Maxime Ripard wrote:
Bluetooth SCO Link are supported by Linux with a matching device tree
binding.
Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.
The value expected for #sound-dai-cells wasn't documented though, and
the users were inconsistent. The example didn't list it, and across the
4 users we have in tree:
- 1 had a cells value of 1, but using only 0 as argument
- 1 had a cells value of 0,
- 2 didn't have this property at all, behaving as if it was 0,
It seems like the consensus seems to be that it should be 0, so let's
enforce it.
The driver has two DAIs: "bt-sco-pcm" and "bt-sco-pcm-wb". If
#sound-dai-cells is 0, only the first DAI can be referenced from a
device tree. So to declare support for wideband PCM, or explicitly
declare a lack of support for it, #sound-dai-cells must be 1.
Regards,
Samuel
quoted hunk
Cc: alsa-devel@alsa-project.org
Cc: devicetree@vger.kernel.org
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Samuel Holland <samuel@sholland.org>
Signed-off-by: Maxime Ripard <redacted>
---
.../devicetree/bindings/sound/bt-sco.txt | 13 -------
.../bindings/sound/linux,bt-sco.yaml | 34 +++++++++++++++++++
2 files changed, 34 insertions(+), 13 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/sound/bt-sco.txt
create mode 100644 Documentation/devicetree/bindings/sound/linux,bt-sco.yaml
From: Maxime Ripard <hidden> Date: 2021-07-22 07:58:11
Hi Samuel,
On Thu, Jul 22, 2021 at 12:35:33AM -0500, Samuel Holland wrote:
On 7/21/21 9:03 AM, Maxime Ripard wrote:
quoted
Bluetooth SCO Link are supported by Linux with a matching device tree
binding.
Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.
The value expected for #sound-dai-cells wasn't documented though, and
the users were inconsistent. The example didn't list it, and across the
4 users we have in tree:
- 1 had a cells value of 1, but using only 0 as argument
- 1 had a cells value of 0,
- 2 didn't have this property at all, behaving as if it was 0,
It seems like the consensus seems to be that it should be 0, so let's
enforce it.
The driver has two DAIs: "bt-sco-pcm" and "bt-sco-pcm-wb". If
#sound-dai-cells is 0, only the first DAI can be referenced from a
device tree. So to declare support for wideband PCM, or explicitly
declare a lack of support for it, #sound-dai-cells must be 1.
Yeah, I knew there was something else to it :)
I'll fix it for the next iteration.
Thanks!
Maxime
From: Maxime Ripard <hidden> Date: 2021-07-21 14:04:41
Simple audio amplifiers are supported by Linux with a matching device
tree binding.
Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.
Cc: alsa-devel@alsa-project.org
Cc: Jerome Brunet <jbrunet@baylibre.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Maxime Ripard <redacted>
---
.../bindings/sound/simple-amplifier.txt | 17 -------
.../sound/simple-audio-amplifier.yaml | 45 +++++++++++++++++++
2 files changed, 45 insertions(+), 17 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/sound/simple-amplifier.txt
create mode 100644 Documentation/devicetree/bindings/sound/simple-audio-amplifier.yaml
@@ -1,17 +0,0 @@-Simple Amplifier Audio Driver--Required properties:-- compatible : "dioo,dio2125" or "simple-audio-amplifier"--Optional properties:-- enable-gpios : the gpio connected to the enable pin of the simple amplifier-- VCC-supply : power supply for the device, as covered- in Documentation/devicetree/bindings/regulator/regulator.txt--Example:--amp: analog-amplifier {- compatible = "simple-audio-amplifier";- VCC-supply = <®ulator>;- enable-gpios = <&gpio GPIOH_3 0>;-};
From: Rob Herring <robh@kernel.org> Date: 2021-07-23 21:36:49
On Wed, 21 Jul 2021 16:03:34 +0200, Maxime Ripard wrote:
Simple audio amplifiers are supported by Linux with a matching device
tree binding.
Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.
Cc: alsa-devel@alsa-project.org
Cc: Jerome Brunet <jbrunet@baylibre.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Maxime Ripard <redacted>
---
.../bindings/sound/simple-amplifier.txt | 17 -------
.../sound/simple-audio-amplifier.yaml | 45 +++++++++++++++++++
2 files changed, 45 insertions(+), 17 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/sound/simple-amplifier.txt
create mode 100644 Documentation/devicetree/bindings/sound/simple-audio-amplifier.yaml
From: Maxime Ripard <hidden> Date: 2021-07-21 14:04:41
The Reserved Memory mechanism is supported by Linux thanks to its device
tree binding.
Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.
Cc: Mailing List <redacted>
Signed-off-by: Maxime Ripard <redacted>
---
.../reserved-memory/reserved-memory.txt | 141 ---------------
.../reserved-memory/reserved-memory.yaml | 167 ++++++++++++++++++
2 files changed, 167 insertions(+), 141 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
create mode 100644 Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml
@@ -1,141 +0,0 @@-*** Reserved memory regions ***--Reserved memory is specified as a node under the /reserved-memory node.-The operating system shall exclude reserved memory from normal usage-one can create child nodes describing particular reserved (excluded from-normal use) memory regions. Such memory regions are usually designed for-the special usage by various device drivers.--Parameters for each memory region can be encoded into the device tree-with the following nodes:--/reserved-memory node-----------------------#address-cells, #size-cells (required) - standard definition- - Should use the same values as the root node-ranges (required) - standard definition- - Should be empty--/reserved-memory/ child nodes-------------------------------Each child of the reserved-memory node specifies one or more regions of-reserved memory. Each child node may either use a 'reg' property to-specify a specific range of reserved memory, or a 'size' property with-optional constraints to request a dynamically allocated block of memory.--Following the generic-names recommended practice, node names should-reflect the purpose of the node (ie. "framebuffer" or "dma-pool"). Unit-address (@<address>) should be appended to the name if the node is a-static allocation.--Properties:-Requires either a) or b) below.-a) static allocation- reg (required) - standard definition-b) dynamic allocation- size (required) - length based on parent's #size-cells- - Size in bytes of memory to reserve.- alignment (optional) - length based on parent's #size-cells- - Address boundary for alignment of allocation.- alloc-ranges (optional) - prop-encoded-array (address, length pairs).- - Specifies regions of memory that are- acceptable to allocate from.--If both reg and size are present, then the reg property takes precedence-and size is ignored.--Additional properties:-compatible (optional) - standard definition- - may contain the following strings:- - shared-dma-pool: This indicates a region of memory meant to be- used as a shared pool of DMA buffers for a set of devices. It can- be used by an operating system to instantiate the necessary pool- management subsystem if necessary.- - vendor specific string in the form <vendor>,[<device>-]<usage>-no-map (optional) - empty property- - Indicates the operating system must not create a virtual mapping- of the region as part of its standard mapping of system memory,- nor permit speculative access to it under any circumstances other- than under the control of the device driver using the region.-reusable (optional) - empty property- - The operating system can use the memory in this region with the- limitation that the device driver(s) owning the region need to be- able to reclaim it back. Typically that means that the operating- system can use that region to store volatile or cached data that- can be otherwise regenerated or migrated elsewhere.--A node must not carry both the no-map and the reusable property as these are-logically contradictory.--Linux implementation note:-- If a "linux,cma-default" property is present, then Linux will use the- region for the default pool of the contiguous memory allocator.--- If a "linux,dma-default" property is present, then Linux will use the- region for the default pool of the consistent DMA allocator.--Device node references to reserved memory-------------------------------------------Regions in the /reserved-memory node may be referenced by other device-nodes by adding a memory-region property to the device node.--memory-region (optional) - phandle, specifier pairs to children of /reserved-memory-memory-region-names (optional) - a list of names, one for each corresponding- entry in the memory-region property--Example---------This example defines 3 contiguous regions are defined for Linux kernel:-one default of all device drivers (named linux,cma@72000000 and 64MiB in size),-one dedicated to the framebuffer device (named framebuffer@78000000, 8MiB), and-one for multimedia processing (named multimedia-memory@77000000, 64MiB).--/ {- #address-cells = <1>;- #size-cells = <1>;-- memory {- reg = <0x40000000 0x40000000>;- };-- reserved-memory {- #address-cells = <1>;- #size-cells = <1>;- ranges;-- /* global autoconfigured region for contiguous allocations */- linux,cma {- compatible = "shared-dma-pool";- reusable;- size = <0x4000000>;- alignment = <0x2000>;- linux,cma-default;- };-- display_reserved: framebuffer@78000000 {- reg = <0x78000000 0x800000>;- };-- multimedia_reserved: multimedia@77000000 {- compatible = "acme,multimedia-memory";- reg = <0x77000000 0x4000000>;- };- };-- /* ... */-- fb0: video@12300000 {- memory-region = <&display_reserved>;- /* ... */- };-- scaler: scaler@12500000 {- memory-region = <&multimedia_reserved>;- /* ... */- };-- codec: codec@12600000 {- memory-region = <&multimedia_reserved>;- /* ... */- };-};
@@ -0,0 +1,167 @@+# SPDX-License-Identifier: GPL-2.0+%YAML1.2+---+$id:http://devicetree.org/schemas/reserved-memory/reserved-memory.yaml#+$schema:http://devicetree.org/meta-schemas/core.yaml#++title:/reserved-memory Node++maintainers:+-Devicetree Specification Mailing List <devicetree-spec@vger.kernel.org>++description:>+Reserved memory is specified as a node under the /reserved-memory node. The+operating system shall exclude reserved memory from normal usage one can+create child nodes describing particular reserved (excluded from normal use)+memory regions. Such memory regions are usually designed for the special+usage by various device drivers.++properties:+$nodename:+const:reserved-memory++"#address-cells":true+"#size-cells":true+ranges:true++patternProperties:+"^(?!(ranges))[a-z,-]*(@[0-9]+)?$":+type:object++description:>+Each child of the reserved-memory node specifies one or more regions of+reserved memory. Each child node may either use a 'reg' property to+specify a specific range of reserved memory, or a 'size' property with+optional constraints to request a dynamically allocated block of memory.++Following the generic-names recommended practice, node names should+reflect the purpose of the node (ie. "framebuffer" or "dma-pool"). Unit+address (@<address>) should be appended to the name if the node is a+static allocation.++properties:+reg:true++size:+$ref:/schemas/types.yaml#/definitions/uint32-array+description:>+Length based on parent's \#size-cells. Size in bytes of memory to+reserve.++alignment:+$ref:/schemas/types.yaml#/definitions/uint32-array+description:>+Length based on parent's \#size-cells. Address boundary for+alignment of allocation.++alloc-ranges:+$ref:/schemas/types.yaml#/definitions/uint32-array+description:>+Address and Length pairs. Specifies regions of memory that are+acceptable to allocate from.++compatible:+oneOf:+-const:shared-dma-pool+description:>+This indicates a region of memory meant to be used as a shared+pool of DMA buffers for a set of devices. It can be used by an+operating system to instantiate the necessary pool management+subsystem if necessary.++# Vendor-specific compatibles in the form <vendor>,[<device>-]<usage>+-const:mediatek,trustzone-bootinfo++no-map:+type:boolean+description:>+Indicates the operating system must not create a virtual mapping of+the region as part of its standard mapping of system memory, nor+permit speculative access to it under any circumstances other than+under the control of the device driver using the region.++reusable:+type:boolean+description:>+The operating system can use the memory in this region with the+limitation that the device driver(s) owning the region need to be+able to reclaim it back. Typically that means that the operating+system can use that region to store volatile or cached data that+can be otherwise regenerated or migrated elsewhere.++linux,cma-default:+type:boolean+description:>+If this property is present, then Linux will use the region for the+default pool of the contiguous memory allocator.++linux,dma-default:+type:boolean+description:>+If this property is present, then Linux will use the region for the+default pool of the consistent DMA allocator.++allOf:+-if:+required:+-no-map++then:+not:+required:+-reusable++-if:+required:+-reusable++then:+not:+required:+-no-map++oneOf:+-required:+-reg++-required:+-size++additionalProperties:true++additionalProperties:true++examples:+-|+/ {+#address-cells = <1>;+#size-cells = <1>;+model = "MediaTek MT2701 evaluation board";+compatible = "mediatek,mt2701-evb", "mediatek,mt2701";++reserved-memory {+#address-cells = <1>;+#size-cells = <1>;+ranges;++/* global autoconfigured region for contiguous allocations */+linux,cma {+compatible = "shared-dma-pool";+reusable;+size = <0x4000000>;+alignment = <0x2000>;+linux,cma-default;+};++display_reserved:framebuffer@78000000 {+reg = <0x78000000 0x800000>;+};++trustzone-bootinfo@80002000 {+compatible = "mediatek,trustzone-bootinfo";+reg = <0x80002000 0x1000>;+};+};+};++...
From: Rob Herring <robh+dt@kernel.org> Date: 2021-07-21 14:30:58
On Wed, Jul 21, 2021 at 8:04 AM Maxime Ripard [off-list ref] wrote:
The Reserved Memory mechanism is supported by Linux thanks to its device
tree binding.
Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.
I think this is okay to dual license. Grant (Linaro) is the original
author and there's only a few lines from other authors.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reserved-memory/reserved-memory.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: /reserved-memory Node
+
+maintainers:
+ - Devicetree Specification Mailing List [off-list ref]
+
+description: >
+ Reserved memory is specified as a node under the /reserved-memory node. The
+ operating system shall exclude reserved memory from normal usage one can
+ create child nodes describing particular reserved (excluded from normal use)
+ memory regions. Such memory regions are usually designed for the special
+ usage by various device drivers.
+
+properties:
+ $nodename:
+ const: reserved-memory
+
+ "#address-cells": true
+ "#size-cells": true
+ ranges: true
+
+patternProperties:
+ "^(?!(ranges))[a-z,-]*(@[0-9]+)?$":
Note that you could drop this and put under 'additionalProperties'.
You would lose some node name checking, but there's really little
standard on these nodes.
+ type: object
+
+ description: >
+ Each child of the reserved-memory node specifies one or more regions of
+ reserved memory. Each child node may either use a 'reg' property to
+ specify a specific range of reserved memory, or a 'size' property with
+ optional constraints to request a dynamically allocated block of memory.
+
+ Following the generic-names recommended practice, node names should
+ reflect the purpose of the node (ie. "framebuffer" or "dma-pool"). Unit
+ address (@<address>) should be appended to the name if the node is a
+ static allocation.
+
+ properties:
+ reg: true
+
+ size:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: >
+ Length based on parent's \#size-cells. Size in bytes of memory to
+ reserve.
+
+ alignment:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: >
+ Length based on parent's \#size-cells. Address boundary for
+ alignment of allocation.
+
+ alloc-ranges:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: >
+ Address and Length pairs. Specifies regions of memory that are
+ acceptable to allocate from.
+
+ compatible:
+ oneOf:
+ - const: shared-dma-pool
+ description: >
+ This indicates a region of memory meant to be used as a shared
+ pool of DMA buffers for a set of devices. It can be used by an
+ operating system to instantiate the necessary pool management
+ subsystem if necessary.
+
+ # Vendor-specific compatibles in the form <vendor>,[<device>-]<usage>
+ - const: mediatek,trustzone-bootinfo
I think these should be separate schema files. At least, we're going
to need to support separate files because I don't think we want ones
adding custom properties here. This would fail unless we add every
compatible here. We could also be a bit more exact as to which
properties below apply (e.g. linux,.*-default is only valid for
shared-dma-pool).
+
+ no-map:
+ type: boolean
+ description: >
+ Indicates the operating system must not create a virtual mapping of
+ the region as part of its standard mapping of system memory, nor
+ permit speculative access to it under any circumstances other than
+ under the control of the device driver using the region.
+
+ reusable:
+ type: boolean
+ description: >
+ The operating system can use the memory in this region with the
+ limitation that the device driver(s) owning the region need to be
+ able to reclaim it back. Typically that means that the operating
+ system can use that region to store volatile or cached data that
+ can be otherwise regenerated or migrated elsewhere.
+
+ linux,cma-default:
+ type: boolean
+ description: >
+ If this property is present, then Linux will use the region for the
+ default pool of the contiguous memory allocator.
+
+ linux,dma-default:
+ type: boolean
+ description: >
+ If this property is present, then Linux will use the region for the
+ default pool of the consistent DMA allocator.
+
+ allOf:
+ - if:
+ required:
+ - no-map
+
+ then:
+ not:
+ required:
+ - reusable
+
+ - if:
+ required:
+ - reusable
+
+ then:
+ not:
+ required:
+ - no-map
+
+ oneOf:
+ - required:
+ - reg
+
+ - required:
+ - size
+
+ additionalProperties: true
+
+additionalProperties: true
From: Maxime Ripard <hidden> Date: 2021-08-18 10:00:32
Hi Rob,
On Wed, Jul 21, 2021 at 08:30:43AM -0600, Rob Herring wrote:
quoted
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reserved-memory/reserved-memory.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: /reserved-memory Node
+
+maintainers:
+ - Devicetree Specification Mailing List [off-list ref]
+
+description: >
+ Reserved memory is specified as a node under the /reserved-memory node. The
+ operating system shall exclude reserved memory from normal usage one can
+ create child nodes describing particular reserved (excluded from normal use)
+ memory regions. Such memory regions are usually designed for the special
+ usage by various device drivers.
+
+properties:
+ $nodename:
+ const: reserved-memory
+
+ "#address-cells": true
+ "#size-cells": true
+ ranges: true
+
+patternProperties:
+ "^(?!(ranges))[a-z,-]*(@[0-9]+)?$":
Note that you could drop this and put under 'additionalProperties'.
You would lose some node name checking, but there's really little
standard on these nodes.
I didn't realise it could be used that way too, I'll change it.
quoted
+ type: object
+
+ description: >
+ Each child of the reserved-memory node specifies one or more regions of
+ reserved memory. Each child node may either use a 'reg' property to
+ specify a specific range of reserved memory, or a 'size' property with
+ optional constraints to request a dynamically allocated block of memory.
+
+ Following the generic-names recommended practice, node names should
+ reflect the purpose of the node (ie. "framebuffer" or "dma-pool"). Unit
+ address (@<address>) should be appended to the name if the node is a
+ static allocation.
+
+ properties:
+ reg: true
+
+ size:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: >
+ Length based on parent's \#size-cells. Size in bytes of memory to
+ reserve.
+
+ alignment:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: >
+ Length based on parent's \#size-cells. Address boundary for
+ alignment of allocation.
+
+ alloc-ranges:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: >
+ Address and Length pairs. Specifies regions of memory that are
+ acceptable to allocate from.
+
+ compatible:
+ oneOf:
+ - const: shared-dma-pool
+ description: >
+ This indicates a region of memory meant to be used as a shared
+ pool of DMA buffers for a set of devices. It can be used by an
+ operating system to instantiate the necessary pool management
+ subsystem if necessary.
+
+ # Vendor-specific compatibles in the form <vendor>,[<device>-]<usage>
+ - const: mediatek,trustzone-bootinfo
I think these should be separate schema files. At least, we're going
to need to support separate files because I don't think we want ones
adding custom properties here. This would fail unless we add every
compatible here. We could also be a bit more exact as to which
properties below apply (e.g. linux,.*-default is only valid for
shared-dma-pool).
I'm not entirely sure how we can just ignore the vendor compatibles
without raising a warning. Do you have any suggestion?
Thanks!
Maxime
From: Rob Herring <robh+dt@kernel.org> Date: 2021-08-18 12:55:15
On Wed, Aug 18, 2021 at 5:00 AM Maxime Ripard [off-list ref] wrote:
Hi Rob,
On Wed, Jul 21, 2021 at 08:30:43AM -0600, Rob Herring wrote:
quoted
quoted
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/reserved-memory/reserved-memory.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: /reserved-memory Node
+
+maintainers:
+ - Devicetree Specification Mailing List [off-list ref]
+
+description: >
+ Reserved memory is specified as a node under the /reserved-memory node. The
+ operating system shall exclude reserved memory from normal usage one can
+ create child nodes describing particular reserved (excluded from normal use)
+ memory regions. Such memory regions are usually designed for the special
+ usage by various device drivers.
+
+properties:
+ $nodename:
+ const: reserved-memory
+
+ "#address-cells": true
+ "#size-cells": true
+ ranges: true
+
+patternProperties:
+ "^(?!(ranges))[a-z,-]*(@[0-9]+)?$":
Note that you could drop this and put under 'additionalProperties'.
You would lose some node name checking, but there's really little
standard on these nodes.
I didn't realise it could be used that way too, I'll change it.
quoted
quoted
+ type: object
+
+ description: >
+ Each child of the reserved-memory node specifies one or more regions of
+ reserved memory. Each child node may either use a 'reg' property to
+ specify a specific range of reserved memory, or a 'size' property with
+ optional constraints to request a dynamically allocated block of memory.
+
+ Following the generic-names recommended practice, node names should
+ reflect the purpose of the node (ie. "framebuffer" or "dma-pool"). Unit
+ address (@<address>) should be appended to the name if the node is a
+ static allocation.
+
+ properties:
+ reg: true
+
+ size:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: >
+ Length based on parent's \#size-cells. Size in bytes of memory to
+ reserve.
+
+ alignment:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: >
+ Length based on parent's \#size-cells. Address boundary for
+ alignment of allocation.
+
+ alloc-ranges:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: >
+ Address and Length pairs. Specifies regions of memory that are
+ acceptable to allocate from.
+
+ compatible:
+ oneOf:
+ - const: shared-dma-pool
+ description: >
+ This indicates a region of memory meant to be used as a shared
+ pool of DMA buffers for a set of devices. It can be used by an
+ operating system to instantiate the necessary pool management
+ subsystem if necessary.
+
+ # Vendor-specific compatibles in the form <vendor>,[<device>-]<usage>
+ - const: mediatek,trustzone-bootinfo
I think these should be separate schema files. At least, we're going
to need to support separate files because I don't think we want ones
adding custom properties here. This would fail unless we add every
compatible here. We could also be a bit more exact as to which
properties below apply (e.g. linux,.*-default is only valid for
shared-dma-pool).
I'm not entirely sure how we can just ignore the vendor compatibles
without raising a warning. Do you have any suggestion?
You need 1 schema file with all the common (child) properties and then
1 schema file for each compatible (maybe some can be grouped) that
references the common schema.
You'd lose checking that the child nodes are actually children of
/reserved-memory, but I'm not too worried about that.
Rob
From: Rob Herring <robh@kernel.org> Date: 2021-07-22 02:10:12
On Wed, 21 Jul 2021 16:03:35 +0200, Maxime Ripard wrote:
The Reserved Memory mechanism is supported by Linux thanks to its device
tree binding.
Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.
Cc: Mailing List <redacted>
Signed-off-by: Maxime Ripard <redacted>
---
.../reserved-memory/reserved-memory.txt | 141 ---------------
.../reserved-memory/reserved-memory.yaml | 167 ++++++++++++++++++
2 files changed, 167 insertions(+), 141 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
create mode 100644 Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/nvmem/rmem.example.dt.yaml: reserved-memory: nvram@10000000:compatible: 'oneOf' conditional failed, one must be fixed:
['raspberrypi,bootloader-config', 'nvmem-rmem'] is too long
Additional items are not allowed ('nvmem-rmem' was unexpected)
'shared-dma-pool' was expected
'mediatek,trustzone-bootinfo' was expected
From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra210-emc.example.dt.yaml: reserved-memory: emc-table@83400000:compatible: 'oneOf' conditional failed, one must be fixed:
'shared-dma-pool' was expected
'mediatek,trustzone-bootinfo' was expected
From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml
\ndoc reference errors (make refcheckdocs):
Documentation/devicetree/bindings/display/arm,hdlcd.txt: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
Documentation/devicetree/bindings/display/arm,komeda.txt: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
Documentation/devicetree/bindings/display/arm,malidp.txt: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
Documentation/devicetree/bindings/display/arm,pl11x.txt: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
Documentation/devicetree/bindings/firmware/intel,stratix10-svc.txt: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
Documentation/devicetree/bindings/gpu/aspeed-gfx.txt: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
Documentation/devicetree/bindings/media/aspeed-video.txt: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
Documentation/devicetree/bindings/media/mediatek-vpu.txt: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
Documentation/devicetree/bindings/remoteproc/ti,davinci-rproc.txt: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
Documentation/devicetree/bindings/remoteproc/ti,keystone-rproc.txt: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
arch/arm/mm/dma-mapping-nommu.c: Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
See https://patchwork.ozlabs.org/patch/1508249
This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit.
From: Maxime Ripard <hidden> Date: 2021-07-21 14:04:43
The ARM CCI-400 Interconnect is supported by Linux thanks to its device
tree binding.
Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.
Cc: Lorenzo Pieralisi <redacted>
Signed-off-by: Maxime Ripard <redacted>
---
.../devicetree/bindings/arm/arm,cci-400.yaml | 216 +++++++++++++++++
.../bindings/arm/cci-control-port.yaml | 38 +++
Documentation/devicetree/bindings/arm/cci.txt | 224 ------------------
3 files changed, 254 insertions(+), 224 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/arm,cci-400.yaml
create mode 100644 Documentation/devicetree/bindings/arm/cci-control-port.yaml
delete mode 100644 Documentation/devicetree/bindings/arm/cci.txt
@@ -0,0 +1,216 @@+# SPDX-License-Identifier: GPL-2.0+%YAML1.2+---+$id:http://devicetree.org/schemas/arm/arm,cci-400.yaml#+$schema:http://devicetree.org/meta-schemas/core.yaml#++title:ARM CCI Cache Coherent Interconnect Device Tree Binding++maintainers:+-Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>++description:>+ARM multi-cluster systems maintain intra-cluster coherency through a cache+coherent interconnect (CCI) that is capable of monitoring bus transactions+and manage coherency, TLB invalidations and memory barriers.++It allows snooping and distributed virtual memory message broadcast across+clusters, through memory mapped interface, with a global control register+space and multiple sets of interface control registers, one per slave+interface.++properties:+$nodename:+pattern:"^cci(@[0-9a-f]+)?$"++compatible:+enum:+-arm,cci-400+-arm,cci-500+-arm,cci-550++reg:+maxItems:1+description:>+Specifies base physical address of CCI control registers common to all+interfaces.++"#address-cells":true+"#size-cells":true+ranges:true++patternProperties:+"^slave-if@[0-9a-f]+$":+type:object++properties:+compatible:+const:arm,cci-400-ctrl-if++interface-type:+enum:+-ace+-ace-lite++reg:+maxItems:1++required:+-compatible+-interface-type+-reg++additionalProperties:false++"^pmu@[0-9a-f]+$":+type:object++properties:+compatible:+oneOf:+-const:arm,cci-400-pmu,r0+-const:arm,cci-400-pmu,r1+-const:arm,cci-400-pmu+deprecated:true+description:>+Permitted only where OS has secure access to CCI registers+-const:arm,cci-500-pmu,r0+-const:arm,cci-550-pmu,r0++interrupts:+minItems:1+maxItems:255+description:>+List of counter overflow interrupts, one per counter. The interrupts+must be specified starting with the cycle counter overflow interrupt,+followed by counter0 overflow interrupt, counter1 overflow+interrupt,... ,counterN overflow interrupt.++The CCI PMU has an interrupt signal for each counter. The number of+interrupts must be equal to the number of counters.++reg:+maxItems:1++required:+-compatible+-interrupts+-reg++additionalProperties:false++required:+-"#address-cells"+-"#size-cells"+-compatible+-ranges+-reg++additionalProperties:false++examples:+-|+/ {+#address-cells = <2>;+#size-cells = <2>;++compatible = "arm,vexpress,v2p-ca15_a7", "arm,vexpress";+model = "V2P-CA15_CA7";+arm,hbi = <0x249>;+interrupt-parent = <&gic>;++/*+*This CCI node corresponds to a CCI component whose control+*registers sits at address 0x000000002c090000.+*+*CCI slave interface @0x000000002c091000 is connected to dma+*controller dma0.+*+*CCI slave interface @0x000000002c094000 is connected to CPUs+*{CPU0,CPU1};+*+*CCI slave interface @0x000000002c095000 is connected to CPUs+*{CPU2,CPU3};+*/++cpus {+#size-cells = <0>;+#address-cells = <1>;++CPU0:cpu@0 {+device_type = "cpu";+compatible = "arm,cortex-a15";+cci-control-port = <&cci_control1>;+reg = <0x0>;+};++CPU1:cpu@1 {+device_type = "cpu";+compatible = "arm,cortex-a15";+cci-control-port = <&cci_control1>;+reg = <0x1>;+};++CPU2:cpu@100 {+device_type = "cpu";+compatible = "arm,cortex-a7";+cci-control-port = <&cci_control2>;+reg = <0x100>;+};++CPU3:cpu@101 {+device_type = "cpu";+compatible = "arm,cortex-a7";+cci-control-port = <&cci_control2>;+reg = <0x101>;+};+};++dma0:dma@3000000 {+compatible = "arm,pl330", "arm,primecell";+cci-control-port = <&cci_control0>;+reg = <0x0 0x3000000 0x0 0x1000>;+interrupts = <10>;+#dma-cells = <1>;+#dma-channels = <8>;+#dma-requests = <32>;+};++cci@2c090000 {+compatible = "arm,cci-400";+#address-cells = <1>;+#size-cells = <1>;+reg = <0x0 0x2c090000 0 0x1000>;+ranges = <0x0 0x0 0x2c090000 0x10000>;++cci_control0:slave-if@1000 {+compatible = "arm,cci-400-ctrl-if";+interface-type = "ace-lite";+reg = <0x1000 0x1000>;+};++cci_control1:slave-if@4000 {+compatible = "arm,cci-400-ctrl-if";+interface-type = "ace";+reg = <0x4000 0x1000>;+};++cci_control2:slave-if@5000 {+compatible = "arm,cci-400-ctrl-if";+interface-type = "ace";+reg = <0x5000 0x1000>;+};++pmu@9000 {+compatible = "arm,cci-400-pmu";+reg = <0x9000 0x5000>;+interrupts = <0 101 4>,+<0 102 4>,+<0 103 4>,+<0 104 4>,+<0 105 4>;+};+};+};++...
@@ -0,0 +1,38 @@+# SPDX-License-Identifier: GPL-2.0+%YAML1.2+---+$id:http://devicetree.org/schemas/arm/cci-control-port.yaml#+$schema:http://devicetree.org/meta-schemas/core.yaml#++title:CCI Interconnect Bus Masters binding++maintainers:+-Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>++description:|+Masters in the device tree connected to a CCI port (inclusive of CPUs+and their cpu nodes).++select:true++properties:+cci-control-port:+$ref:/schemas/types.yaml#/definitions/phandle++additionalProperties:true++examples:+-|+cpus {+#address-cells = <1>;+#size-cells = <0>;++cpu@0 {+compatible = "arm,cortex-a15";+device_type = "cpu";+cci-control-port = <&cci_control1>;+reg = <0>;+};+};++...
@@ -1,224 +0,0 @@-=======================================================-ARM CCI cache coherent interconnect binding description-=======================================================--ARM multi-cluster systems maintain intra-cluster coherency through a-cache coherent interconnect (CCI) that is capable of monitoring bus-transactions and manage coherency, TLB invalidations and memory barriers.--It allows snooping and distributed virtual memory message broadcast across-clusters, through memory mapped interface, with a global control register-space and multiple sets of interface control registers, one per slave-interface.--* CCI interconnect node-- Description: Describes a CCI cache coherent Interconnect component-- Node name must be "cci".- Node's parent must be the root node /, and the address space visible- through the CCI interconnect is the same as the one seen from the- root node (ie from CPUs perspective as per DT standard).- Every CCI node has to define the following properties:-- - compatible- Usage: required- Value type: <string>- Definition: must contain one of the following:- "arm,cci-400"- "arm,cci-500"- "arm,cci-550"-- - reg- Usage: required- Value type: Integer cells. A register entry, expressed as a pair- of cells, containing base and size.- Definition: A standard property. Specifies base physical- address of CCI control registers common to all- interfaces.-- - ranges:- Usage: required- Value type: Integer cells. An array of range entries, expressed- as a tuple of cells, containing child address,- parent address and the size of the region in the- child address space.- Definition: A standard property. Follow rules in the Devicetree- Specification for hierarchical bus addressing. CCI- interfaces addresses refer to the parent node- addressing scheme to declare their register bases.-- CCI interconnect node can define the following child nodes:-- - CCI control interface nodes-- Node name must be "slave-if".- Parent node must be CCI interconnect node.-- A CCI control interface node must contain the following- properties:-- - compatible- Usage: required- Value type: <string>- Definition: must be set to- "arm,cci-400-ctrl-if"-- - interface-type:- Usage: required- Value type: <string>- Definition: must be set to one of {"ace", "ace-lite"}- depending on the interface type the node- represents.-- - reg:- Usage: required- Value type: Integer cells. A register entry, expressed- as a pair of cells, containing base and- size.- Definition: the base address and size of the- corresponding interface programming- registers.-- - CCI PMU node-- Parent node must be CCI interconnect node.-- A CCI pmu node must contain the following properties:-- - compatible- Usage: required- Value type: <string>- Definition: Must contain one of:- "arm,cci-400-pmu,r0"- "arm,cci-400-pmu,r1"- "arm,cci-400-pmu" - DEPRECATED, permitted only where OS has- secure access to CCI registers- "arm,cci-500-pmu,r0"- "arm,cci-550-pmu,r0"- - reg:- Usage: required- Value type: Integer cells. A register entry, expressed- as a pair of cells, containing base and- size.- Definition: the base address and size of the- corresponding interface programming- registers.-- - interrupts:- Usage: required- Value type: Integer cells. Array of interrupt specifier- entries, as defined in- ../interrupt-controller/interrupts.txt.- Definition: list of counter overflow interrupts, one per- counter. The interrupts must be specified- starting with the cycle counter overflow- interrupt, followed by counter0 overflow- interrupt, counter1 overflow interrupt,...- ,counterN overflow interrupt.-- The CCI PMU has an interrupt signal for each- counter. The number of interrupts must be- equal to the number of counters.--* CCI interconnect bus masters-- Description: masters in the device tree connected to a CCI port- (inclusive of CPUs and their cpu nodes).-- A CCI interconnect bus master node must contain the following- properties:-- - cci-control-port:- Usage: required- Value type: <phandle>- Definition: a phandle containing the CCI control interface node- the master is connected to.--Example:-- cpus {- #size-cells = <0>;- #address-cells = <1>;-- CPU0: cpu@0 {- device_type = "cpu";- compatible = "arm,cortex-a15";- cci-control-port = <&cci_control1>;- reg = <0x0>;- };-- CPU1: cpu@1 {- device_type = "cpu";- compatible = "arm,cortex-a15";- cci-control-port = <&cci_control1>;- reg = <0x1>;- };-- CPU2: cpu@100 {- device_type = "cpu";- compatible = "arm,cortex-a7";- cci-control-port = <&cci_control2>;- reg = <0x100>;- };-- CPU3: cpu@101 {- device_type = "cpu";- compatible = "arm,cortex-a7";- cci-control-port = <&cci_control2>;- reg = <0x101>;- };-- };-- dma0: dma@3000000 {- compatible = "arm,pl330", "arm,primecell";- cci-control-port = <&cci_control0>;- reg = <0x0 0x3000000 0x0 0x1000>;- interrupts = <10>;- #dma-cells = <1>;- #dma-channels = <8>;- #dma-requests = <32>;- };-- cci@2c090000 {- compatible = "arm,cci-400";- #address-cells = <1>;- #size-cells = <1>;- reg = <0x0 0x2c090000 0 0x1000>;- ranges = <0x0 0x0 0x2c090000 0x10000>;-- cci_control0: slave-if@1000 {- compatible = "arm,cci-400-ctrl-if";- interface-type = "ace-lite";- reg = <0x1000 0x1000>;- };-- cci_control1: slave-if@4000 {- compatible = "arm,cci-400-ctrl-if";- interface-type = "ace";- reg = <0x4000 0x1000>;- };-- cci_control2: slave-if@5000 {- compatible = "arm,cci-400-ctrl-if";- interface-type = "ace";- reg = <0x5000 0x1000>;- };-- pmu@9000 {- compatible = "arm,cci-400-pmu";- reg = <0x9000 0x5000>;- interrupts = <0 101 4>,- <0 102 4>,- <0 103 4>,- <0 104 4>,- <0 105 4>;- };- };--This CCI node corresponds to a CCI component whose control registers sits-at address 0x000000002c090000.-CCI slave interface @0x000000002c091000 is connected to dma controller dma0.-CCI slave interface @0x000000002c094000 is connected to CPUs {CPU0, CPU1};-CCI slave interface @0x000000002c095000 is connected to CPUs {CPU2, CPU3};
From: Rob Herring <robh@kernel.org> Date: 2021-07-22 02:10:22
On Wed, 21 Jul 2021 16:03:36 +0200, Maxime Ripard wrote:
The ARM CCI-400 Interconnect is supported by Linux thanks to its device
tree binding.
Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.
Cc: Lorenzo Pieralisi <redacted>
Signed-off-by: Maxime Ripard <redacted>
---
.../devicetree/bindings/arm/arm,cci-400.yaml | 216 +++++++++++++++++
.../bindings/arm/cci-control-port.yaml | 38 +++
Documentation/devicetree/bindings/arm/cci.txt | 224 ------------------
3 files changed, 254 insertions(+), 224 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/arm,cci-400.yaml
create mode 100644 Documentation/devicetree/bindings/arm/cci-control-port.yaml
delete mode 100644 Documentation/devicetree/bindings/arm/cci.txt
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/arm/arm,cci-400.example.dt.yaml:0:0: /dma@3000000: failed to match any schema with compatible: ['arm,pl330', 'arm,primecell']
\ndoc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/patch/1508250
This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit.
From: Rob Herring <robh@kernel.org> Date: 2021-07-22 02:26:49
On Wed, Jul 21, 2021 at 04:03:36PM +0200, Maxime Ripard wrote:
quoted hunk
The ARM CCI-400 Interconnect is supported by Linux thanks to its device
tree binding.
Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.
Cc: Lorenzo Pieralisi <redacted>
Signed-off-by: Maxime Ripard <redacted>
---
.../devicetree/bindings/arm/arm,cci-400.yaml | 216 +++++++++++++++++
.../bindings/arm/cci-control-port.yaml | 38 +++
Documentation/devicetree/bindings/arm/cci.txt | 224 ------------------
3 files changed, 254 insertions(+), 224 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/arm,cci-400.yaml
create mode 100644 Documentation/devicetree/bindings/arm/cci-control-port.yaml
delete mode 100644 Documentation/devicetree/bindings/arm/cci.txt
@@ -0,0 +1,216 @@+# SPDX-License-Identifier: GPL-2.0+%YAML1.2+---+$id:http://devicetree.org/schemas/arm/arm,cci-400.yaml#+$schema:http://devicetree.org/meta-schemas/core.yaml#++title:ARM CCI Cache Coherent Interconnect Device Tree Binding++maintainers:+-Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>++description:>+ARM multi-cluster systems maintain intra-cluster coherency through a cache+coherent interconnect (CCI) that is capable of monitoring bus transactions+and manage coherency, TLB invalidations and memory barriers.++It allows snooping and distributed virtual memory message broadcast across+clusters, through memory mapped interface, with a global control register+space and multiple sets of interface control registers, one per slave+interface.++properties:+$nodename:+pattern:"^cci(@[0-9a-f]+)?$"++compatible:+enum:+-arm,cci-400+-arm,cci-500+-arm,cci-550++reg:+maxItems:1+description:>+Specifies base physical address of CCI control registers common to all+interfaces.++"#address-cells":true+"#size-cells":true+ranges:true++patternProperties:+"^slave-if@[0-9a-f]+$":+type:object++properties:+compatible:+const:arm,cci-400-ctrl-if++interface-type:+enum:+-ace+-ace-lite++reg:+maxItems:1++required:+-compatible+-interface-type+-reg++additionalProperties:false++"^pmu@[0-9a-f]+$":+type:object++properties:+compatible:+oneOf:+-const:arm,cci-400-pmu,r0+-const:arm,cci-400-pmu,r1+-const:arm,cci-400-pmu+deprecated:true+description:>+Permitted only where OS has secure access to CCI registers+-const:arm,cci-500-pmu,r0+-const:arm,cci-550-pmu,r0++interrupts:+minItems:1+maxItems:255
There's only 8 counters in cci-550. I doubt this schema will be
extended.
+ description: >
+ List of counter overflow interrupts, one per counter. The interrupts
+ must be specified starting with the cycle counter overflow interrupt,
+ followed by counter0 overflow interrupt, counter1 overflow
+ interrupt,... ,counterN overflow interrupt.
+
+ The CCI PMU has an interrupt signal for each counter. The number of
+ interrupts must be equal to the number of counters.
+
+ reg:
+ maxItems: 1
+
+ required:
+ - compatible
+ - interrupts
+ - reg
+
+ additionalProperties: false
+
+required:
+ - "#address-cells"
+ - "#size-cells"
+ - compatible
+ - ranges
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ / {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ compatible = "arm,vexpress,v2p-ca15_a7", "arm,vexpress";
+ model = "V2P-CA15_CA7";
+ arm,hbi = <0x249>;
+ interrupt-parent = <&gic>;
+
+ /*
+ * This CCI node corresponds to a CCI component whose control
+ * registers sits at address 0x000000002c090000.
+ *
+ * CCI slave interface @0x000000002c091000 is connected to dma
+ * controller dma0.
+ *
+ * CCI slave interface @0x000000002c094000 is connected to CPUs
+ * {CPU0, CPU1};
+ *
+ * CCI slave interface @0x000000002c095000 is connected to CPUs
+ * {CPU2, CPU3};
+ */
+
+ cpus {
+ #size-cells = <0>;
+ #address-cells = <1>;
+
+ CPU0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a15";
+ cci-control-port = <&cci_control1>;
Needs to be added to the cpu schema unless I missed you did that.
@@ -0,0 +1,38 @@+# SPDX-License-Identifier: GPL-2.0+%YAML1.2+---+$id:http://devicetree.org/schemas/arm/cci-control-port.yaml#+$schema:http://devicetree.org/meta-schemas/core.yaml#++title:CCI Interconnect Bus Masters binding++maintainers:+-Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>++description:|+Masters in the device tree connected to a CCI port (inclusive of CPUs+and their cpu nodes).++select:true++properties:+cci-control-port:+$ref:/schemas/types.yaml#/definitions/phandle++additionalProperties:true++examples:+-|+cpus {+#address-cells = <1>;+#size-cells = <0>;++cpu@0 {+compatible = "arm,cortex-a15";+device_type = "cpu";+cci-control-port = <&cci_control1>;+reg = <0>;+};+};++...
@@ -1,224 +0,0 @@-=======================================================-ARM CCI cache coherent interconnect binding description-=======================================================--ARM multi-cluster systems maintain intra-cluster coherency through a-cache coherent interconnect (CCI) that is capable of monitoring bus-transactions and manage coherency, TLB invalidations and memory barriers.--It allows snooping and distributed virtual memory message broadcast across-clusters, through memory mapped interface, with a global control register-space and multiple sets of interface control registers, one per slave-interface.--* CCI interconnect node-- Description: Describes a CCI cache coherent Interconnect component-- Node name must be "cci".- Node's parent must be the root node /, and the address space visible- through the CCI interconnect is the same as the one seen from the- root node (ie from CPUs perspective as per DT standard).- Every CCI node has to define the following properties:-- - compatible- Usage: required- Value type: <string>- Definition: must contain one of the following:- "arm,cci-400"- "arm,cci-500"- "arm,cci-550"-- - reg- Usage: required- Value type: Integer cells. A register entry, expressed as a pair- of cells, containing base and size.- Definition: A standard property. Specifies base physical- address of CCI control registers common to all- interfaces.-- - ranges:- Usage: required- Value type: Integer cells. An array of range entries, expressed- as a tuple of cells, containing child address,- parent address and the size of the region in the- child address space.- Definition: A standard property. Follow rules in the Devicetree- Specification for hierarchical bus addressing. CCI- interfaces addresses refer to the parent node- addressing scheme to declare their register bases.-- CCI interconnect node can define the following child nodes:-- - CCI control interface nodes-- Node name must be "slave-if".- Parent node must be CCI interconnect node.-- A CCI control interface node must contain the following- properties:-- - compatible- Usage: required- Value type: <string>- Definition: must be set to- "arm,cci-400-ctrl-if"-- - interface-type:- Usage: required- Value type: <string>- Definition: must be set to one of {"ace", "ace-lite"}- depending on the interface type the node- represents.-- - reg:- Usage: required- Value type: Integer cells. A register entry, expressed- as a pair of cells, containing base and- size.- Definition: the base address and size of the- corresponding interface programming- registers.-- - CCI PMU node-- Parent node must be CCI interconnect node.-- A CCI pmu node must contain the following properties:-- - compatible- Usage: required- Value type: <string>- Definition: Must contain one of:- "arm,cci-400-pmu,r0"- "arm,cci-400-pmu,r1"- "arm,cci-400-pmu" - DEPRECATED, permitted only where OS has- secure access to CCI registers- "arm,cci-500-pmu,r0"- "arm,cci-550-pmu,r0"- - reg:- Usage: required- Value type: Integer cells. A register entry, expressed- as a pair of cells, containing base and- size.- Definition: the base address and size of the- corresponding interface programming- registers.-- - interrupts:- Usage: required- Value type: Integer cells. Array of interrupt specifier- entries, as defined in- ../interrupt-controller/interrupts.txt.- Definition: list of counter overflow interrupts, one per- counter. The interrupts must be specified- starting with the cycle counter overflow- interrupt, followed by counter0 overflow- interrupt, counter1 overflow interrupt,...- ,counterN overflow interrupt.-- The CCI PMU has an interrupt signal for each- counter. The number of interrupts must be- equal to the number of counters.--* CCI interconnect bus masters-- Description: masters in the device tree connected to a CCI port- (inclusive of CPUs and their cpu nodes).-- A CCI interconnect bus master node must contain the following- properties:-- - cci-control-port:- Usage: required- Value type: <phandle>- Definition: a phandle containing the CCI control interface node- the master is connected to.--Example:-- cpus {- #size-cells = <0>;- #address-cells = <1>;-- CPU0: cpu@0 {- device_type = "cpu";- compatible = "arm,cortex-a15";- cci-control-port = <&cci_control1>;- reg = <0x0>;- };-- CPU1: cpu@1 {- device_type = "cpu";- compatible = "arm,cortex-a15";- cci-control-port = <&cci_control1>;- reg = <0x1>;- };-- CPU2: cpu@100 {- device_type = "cpu";- compatible = "arm,cortex-a7";- cci-control-port = <&cci_control2>;- reg = <0x100>;- };-- CPU3: cpu@101 {- device_type = "cpu";- compatible = "arm,cortex-a7";- cci-control-port = <&cci_control2>;- reg = <0x101>;- };-- };-- dma0: dma@3000000 {- compatible = "arm,pl330", "arm,primecell";- cci-control-port = <&cci_control0>;- reg = <0x0 0x3000000 0x0 0x1000>;- interrupts = <10>;- #dma-cells = <1>;- #dma-channels = <8>;- #dma-requests = <32>;- };-- cci@2c090000 {- compatible = "arm,cci-400";- #address-cells = <1>;- #size-cells = <1>;- reg = <0x0 0x2c090000 0 0x1000>;- ranges = <0x0 0x0 0x2c090000 0x10000>;-- cci_control0: slave-if@1000 {- compatible = "arm,cci-400-ctrl-if";- interface-type = "ace-lite";- reg = <0x1000 0x1000>;- };-- cci_control1: slave-if@4000 {- compatible = "arm,cci-400-ctrl-if";- interface-type = "ace";- reg = <0x4000 0x1000>;- };-- cci_control2: slave-if@5000 {- compatible = "arm,cci-400-ctrl-if";- interface-type = "ace";- reg = <0x5000 0x1000>;- };-- pmu@9000 {- compatible = "arm,cci-400-pmu";- reg = <0x9000 0x5000>;- interrupts = <0 101 4>,- <0 102 4>,- <0 103 4>,- <0 104 4>,- <0 105 4>;- };- };--This CCI node corresponds to a CCI component whose control registers sits-at address 0x000000002c090000.-CCI slave interface @0x000000002c091000 is connected to dma controller dma0.-CCI slave interface @0x000000002c094000 is connected to CPUs {CPU0, CPU1};-CCI slave interface @0x000000002c095000 is connected to CPUs {CPU2, CPU3};
From: Maxime Ripard <hidden> Date: 2021-07-21 14:04:45
The original binding was mentioning that valid values for the clocks and
clock-names property were one or two clocks from extclk, txco and lpo,
with extclk being deprecated in favor of txco.
However, the current binding lists a valid array as extclk, txco and
lpo, with either one or two items.
While this looks similar, it actually enforces that all the device trees
use either ["extclk"], or ["extclk", "txco"]. That doesn't make much
sense, since the two clocks are said to be equivalent, with one
superseeding the other.
lpo is also not a valid clock anymore, and would be as the third clock
of the list, while we could have only this clock in the previous binding
(and in DTs).
Let's rework the clock clause to allow to have either:
- extclk, and mark it a deprecated
- txco alone
- lpo alone
- txco, lpo
While ["extclk", "lpo"] wouldn't be valid, it wasn't found in any device
tree so it's not an issue in practice.
Similarly, ["lpo", "txco"] is still considered invalid, but it's
generally considered as a best practice to fix the order of clocks.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Linus Walleij <redacted>
Cc: netdev@vger.kernel.org
Signed-off-by: Maxime Ripard <redacted>
---
.../bindings/net/broadcom-bluetooth.yaml | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
@@ -50,16 +50,29 @@ properties:by interrupts and "host-wakeup" interrupt-namesclocks:+minItems:1maxItems:2description:1 or 2 clocks as defined in clock-names below,in that orderclock-names:description:Names of the 1 to 2 supplied clocks-items:+oneOf:+-const:extclk+deprecated:true+description:Deprecated in favor of txco+-const:txco+description:>+external reference clock (not a standalone crystal)+-const:lpo--const:extclk+description:>+external low power 32.768 kHz clock++-items:+-const:txco+-const:lpovbat-supply:description:phandle to regulator supply for VBAT
From: Rob Herring <robh@kernel.org> Date: 2021-07-23 21:38:49
On Wed, 21 Jul 2021 16:03:37 +0200, Maxime Ripard wrote:
The original binding was mentioning that valid values for the clocks and
clock-names property were one or two clocks from extclk, txco and lpo,
with extclk being deprecated in favor of txco.
However, the current binding lists a valid array as extclk, txco and
lpo, with either one or two items.
While this looks similar, it actually enforces that all the device trees
use either ["extclk"], or ["extclk", "txco"]. That doesn't make much
sense, since the two clocks are said to be equivalent, with one
superseeding the other.
lpo is also not a valid clock anymore, and would be as the third clock
of the list, while we could have only this clock in the previous binding
(and in DTs).
Let's rework the clock clause to allow to have either:
- extclk, and mark it a deprecated
- txco alone
- lpo alone
- txco, lpo
While ["extclk", "lpo"] wouldn't be valid, it wasn't found in any device
tree so it's not an issue in practice.
Similarly, ["lpo", "txco"] is still considered invalid, but it's
generally considered as a best practice to fix the order of clocks.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Linus Walleij <redacted>
Cc: netdev@vger.kernel.org
Signed-off-by: Maxime Ripard <redacted>
---
.../bindings/net/broadcom-bluetooth.yaml | 17 +++++++++++++++--
1 file changed, 15 insertions(+), 2 deletions(-)
From: Maxime Ripard <hidden> Date: 2021-07-21 14:04:47
additionalProperties prevent any property not explicitly defined in the
binding to be used. Yet, some serial properties like max-speed are valid
and validated through the serial/serial.yaml binding.
Even though the ideal solution would be to use unevaluatedProperties
instead, it's not pratical due to the way the bus bindings have been
described. Let's add max-speed to remove the warning.
Cc: Alistair Francis <redacted>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: netdev@vger.kernel.org
Cc: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Maxime Ripard <redacted>
---
Documentation/devicetree/bindings/net/realtek-bluetooth.yaml | 2 ++
1 file changed, 2 insertions(+)
From: Rob Herring <robh@kernel.org> Date: 2021-07-23 21:39:14
On Wed, 21 Jul 2021 16:03:38 +0200, Maxime Ripard wrote:
additionalProperties prevent any property not explicitly defined in the
binding to be used. Yet, some serial properties like max-speed are valid
and validated through the serial/serial.yaml binding.
Even though the ideal solution would be to use unevaluatedProperties
instead, it's not pratical due to the way the bus bindings have been
described. Let's add max-speed to remove the warning.
Cc: Alistair Francis <redacted>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: netdev@vger.kernel.org
Cc: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Maxime Ripard <redacted>
---
Documentation/devicetree/bindings/net/realtek-bluetooth.yaml | 2 ++
1 file changed, 2 insertions(+)
On Thu, Jul 22, 2021, at 12:03 AM, Maxime Ripard wrote:
additionalProperties prevent any property not explicitly defined in the
binding to be used. Yet, some serial properties like max-speed are valid
and validated through the serial/serial.yaml binding.
Even though the ideal solution would be to use unevaluatedProperties
instead, it's not pratical due to the way the bus bindings have been
described. Let's add max-speed to remove the warning.
Cc: Alistair Francis <redacted>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: netdev@vger.kernel.org
Cc: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Maxime Ripard <redacted>
From: Maxime Ripard <hidden> Date: 2021-07-21 14:04:49
Even though both the driver and the device trees all use the
allwinner,sun50i-h6-de3-clk, we documented the compatible as
allwinner,sun50i-h6-de2-clk in the binding. Let's fix this.
Signed-off-by: Maxime Ripard <redacted>
---
.../devicetree/bindings/clock/allwinner,sun8i-a83t-de2-clk.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Rob Herring <robh@kernel.org> Date: 2021-07-23 21:39:41
On Wed, 21 Jul 2021 16:03:39 +0200, Maxime Ripard wrote:
Even though both the driver and the device trees all use the
allwinner,sun50i-h6-de3-clk, we documented the compatible as
allwinner,sun50i-h6-de2-clk in the binding. Let's fix this.
Signed-off-by: Maxime Ripard <redacted>
---
.../devicetree/bindings/clock/allwinner,sun8i-a83t-de2-clk.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Maxime Ripard <hidden> Date: 2021-07-21 14:04:51
The binding mentions that all the drivers using that driver must use a
vendor-specific compatible but never enforces it, nor documents the
vendor-specific compatibles.
Let's make we document all of them, and that the binding will create an
error if we add one that isn't.
Cc: dri-devel@lists.freedesktop.org
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Sam Ravnborg <redacted>
Cc: Thierry Reding <redacted>
Signed-off-by: Maxime Ripard <redacted>
---
.../bindings/display/panel/lvds.yaml | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
@@ -31,12 +31,18 @@ allOf:properties:compatible:-contains:-const:panel-lvds-description:-Shall contain "panel-lvds" in addition to a mandatory panel-specific-compatible string defined in individual panel bindings. The "panel-lvds"-value shall never be used on its own.+items:+-enum:+-advantech,idk-1110wr+-advantech,idk-2121wr+-auo,b101ew05+-innolux,ee101ia-01d+-mitsubishi,aa104xd12+-mitsubishi,aa121td01+-sgd,gktw70sdae4se+-sharp,lq150x1lg11+-tbs,a711-panel+-const:panel-lvdsdata-mapping:enum:
From: Rob Herring <robh@kernel.org> Date: 2021-07-22 02:10:05
On Wed, 21 Jul 2021 16:03:40 +0200, Maxime Ripard wrote:
The binding mentions that all the drivers using that driver must use a
vendor-specific compatible but never enforces it, nor documents the
vendor-specific compatibles.
Let's make we document all of them, and that the binding will create an
error if we add one that isn't.
Cc: dri-devel@lists.freedesktop.org
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Sam Ravnborg <redacted>
Cc: Thierry Reding <redacted>
Signed-off-by: Maxime Ripard <redacted>
---
.../bindings/display/panel/lvds.yaml | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.example.dt.yaml: panel: compatible: ['sharp,lq150x1lg11'] is too short
From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/panel/lvds.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.example.dt.yaml: panel: 'data-mapping' is a required property
From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/panel/lvds.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.example.dt.yaml: panel: 'width-mm' is a required property
From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/panel/lvds.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.example.dt.yaml: panel: 'height-mm' is a required property
From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/panel/lvds.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.example.dt.yaml: panel: 'panel-timing' is a required property
From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/panel/lvds.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/panel/sharp,lq150x1lg11.example.dt.yaml: panel: 'oneOf' conditional failed, one must be fixed:
'port' is a required property
'ports' is a required property
From schema: /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/panel/lvds.yaml
\ndoc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/patch/1508254
This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit.
From: Rob Herring <robh@kernel.org> Date: 2021-07-22 02:29:52
On Wed, Jul 21, 2021 at 04:03:40PM +0200, Maxime Ripard wrote:
quoted hunk
The binding mentions that all the drivers using that driver must use a
vendor-specific compatible but never enforces it, nor documents the
vendor-specific compatibles.
Let's make we document all of them, and that the binding will create an
error if we add one that isn't.
Cc: dri-devel@lists.freedesktop.org
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Sam Ravnborg <redacted>
Cc: Thierry Reding <redacted>
Signed-off-by: Maxime Ripard <redacted>
---
.../bindings/display/panel/lvds.yaml | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
@@ -31,12 +31,18 @@ allOf:properties:compatible:-contains:-const:panel-lvds-description:-Shall contain "panel-lvds" in addition to a mandatory panel-specific-compatible string defined in individual panel bindings. The "panel-lvds"-value shall never be used on its own.+items:+-enum:+-advantech,idk-1110wr
At least this one is documented elsewhere. You can add 'minItems: 2' if
you want to just enforce having 2 compatibles. Or do:
items:
- {}
- const: panel-lvds
Which also enforces the order.
From: Maxime Ripard <hidden> Date: 2021-08-18 12:43:15
Hi Rob, Sam,
On Wed, Jul 21, 2021 at 08:29:47PM -0600, Rob Herring wrote:
On Wed, Jul 21, 2021 at 04:03:40PM +0200, Maxime Ripard wrote:
quoted
The binding mentions that all the drivers using that driver must use a
vendor-specific compatible but never enforces it, nor documents the
vendor-specific compatibles.
Let's make we document all of them, and that the binding will create an
error if we add one that isn't.
Cc: dri-devel@lists.freedesktop.org
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Sam Ravnborg <redacted>
Cc: Thierry Reding <redacted>
Signed-off-by: Maxime Ripard <redacted>
---
.../bindings/display/panel/lvds.yaml | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
@@ -31,12 +31,18 @@ allOf:properties:compatible:-contains:-const:panel-lvds-description:-Shall contain "panel-lvds" in addition to a mandatory panel-specific-compatible string defined in individual panel bindings. The "panel-lvds"-value shall never be used on its own.+items:+-enum:+-advantech,idk-1110wr
At least this one is documented elsewhere.
Indeed, I missed it.
You can add 'minItems: 2' if you want to just enforce having 2 compatibles. Or do:
items:
- {}
- const: panel-lvds
Which also enforces the order.
It's not just about the order since a missing compatible will also raise
a warning.
Some of those panels have a binding of their own, but some probably
won't (and I can't find anything specific about the one I'm most
interested in: tbs,a711-panel)
Can we have something like:
compatible:
oneOf:
- items:
- enum:
- tbs,a711-panel
- const: panel-lvds
- items:
- {}
- const: panel-lvds
That would work for both cases I guess?
Maxime
From: Rob Herring <robh@kernel.org> Date: 2021-08-18 13:49:14
On Wed, Aug 18, 2021 at 7:43 AM Maxime Ripard [off-list ref] wrote:
Hi Rob, Sam,
On Wed, Jul 21, 2021 at 08:29:47PM -0600, Rob Herring wrote:
quoted
On Wed, Jul 21, 2021 at 04:03:40PM +0200, Maxime Ripard wrote:
quoted
The binding mentions that all the drivers using that driver must use a
vendor-specific compatible but never enforces it, nor documents the
vendor-specific compatibles.
Let's make we document all of them, and that the binding will create an
error if we add one that isn't.
Cc: dri-devel@lists.freedesktop.org
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Sam Ravnborg <redacted>
Cc: Thierry Reding <redacted>
Signed-off-by: Maxime Ripard <redacted>
---
.../bindings/display/panel/lvds.yaml | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
@@ -31,12 +31,18 @@ allOf:properties:compatible:-contains:-const:panel-lvds-description:-Shall contain "panel-lvds" in addition to a mandatory panel-specific-compatible string defined in individual panel bindings. The "panel-lvds"-value shall never be used on its own.+items:+-enum:+-advantech,idk-1110wr
At least this one is documented elsewhere.
Indeed, I missed it.
quoted
You can add 'minItems: 2' if you want to just enforce having 2 compatibles. Or do:
items:
- {}
- const: panel-lvds
Which also enforces the order.
It's not just about the order since a missing compatible will also raise
a warning.
Some of those panels have a binding of their own, but some probably
won't (and I can't find anything specific about the one I'm most
interested in: tbs,a711-panel)
Can we have something like:
compatible:
oneOf:
- items:
- enum:
- tbs,a711-panel
- const: panel-lvds
- items:
- {}
- const: panel-lvds
That would work for both cases I guess?
No, both conditions will be true. If you use 'anyOf', then we're never
really checking the specific compatible.
I think the problem here is trying to mix a common binding (aka an
incomplete collection of properties) and a specific binding. The
former is characterized with 'additionalProperties: true' as we have
here. You need to create a 'panel-simple-lvds.yaml' schema file that
references this one, defines all the 'simple' compatibles, and sets
'unevaluatedProperties: false'.
Rob
From: Maxime Ripard <hidden> Date: 2021-08-23 16:31:21
Hi,
On Wed, Aug 18, 2021 at 08:48:46AM -0500, Rob Herring wrote:
On Wed, Aug 18, 2021 at 7:43 AM Maxime Ripard [off-list ref] wrote:
quoted
Hi Rob, Sam,
On Wed, Jul 21, 2021 at 08:29:47PM -0600, Rob Herring wrote:
quoted
On Wed, Jul 21, 2021 at 04:03:40PM +0200, Maxime Ripard wrote:
quoted
The binding mentions that all the drivers using that driver must use a
vendor-specific compatible but never enforces it, nor documents the
vendor-specific compatibles.
Let's make we document all of them, and that the binding will create an
error if we add one that isn't.
Cc: dri-devel@lists.freedesktop.org
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Sam Ravnborg <redacted>
Cc: Thierry Reding <redacted>
Signed-off-by: Maxime Ripard <redacted>
---
.../bindings/display/panel/lvds.yaml | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
@@ -31,12 +31,18 @@ allOf:properties:compatible:-contains:-const:panel-lvds-description:-Shall contain "panel-lvds" in addition to a mandatory panel-specific-compatible string defined in individual panel bindings. The "panel-lvds"-value shall never be used on its own.+items:+-enum:+-advantech,idk-1110wr
At least this one is documented elsewhere.
Indeed, I missed it.
quoted
You can add 'minItems: 2' if you want to just enforce having 2 compatibles. Or do:
items:
- {}
- const: panel-lvds
Which also enforces the order.
It's not just about the order since a missing compatible will also raise
a warning.
Some of those panels have a binding of their own, but some probably
won't (and I can't find anything specific about the one I'm most
interested in: tbs,a711-panel)
Can we have something like:
compatible:
oneOf:
- items:
- enum:
- tbs,a711-panel
- const: panel-lvds
- items:
- {}
- const: panel-lvds
That would work for both cases I guess?
No, both conditions will be true. If you use 'anyOf', then we're never
really checking the specific compatible.
I think the problem here is trying to mix a common binding (aka an
incomplete collection of properties) and a specific binding.
I'm not entirely sure why we have specific bindings for this in the
first place.
We currently have 6 specific bindings, and for 5 of them the only
specific thing in there are the data-mapping value to force and their
dimension.
I'd argue that the dimension shouldn't even be set in stone: you could
very well imagine a screen with exactly the same timings but a different
size. We would consider it compatible.
And the data-mapping can be dealt with with an if clause fairly easily.
And for the last one, the specific thing about it is that it's using a
dual-link output, which is a generic binding and could thus be described
in panel-lvds too.
Maxime
From: Maxime Ripard <hidden> Date: 2021-07-21 14:04:54
The corpro,gm7123 was in use in a DT but was never properly documented,
let's add it.
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Maxime Ripard <redacted>
---
Changes from v1:
- Removed the dumb-vga-dac compatible from the list
---
.../devicetree/bindings/display/bridge/simple-bridge.yaml | 3 +++
1 file changed, 3 insertions(+)
From: Maxime Ripard <hidden> Date: 2021-07-21 14:04:56
The UBlox Neo 6M is supported by Linux thanks to its device tree
binding.
Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.
Cc: Johan Hovold <johan@kernel.org>
Signed-off-by: Maxime Ripard <redacted>
---
.../bindings/gnss/u-blox,neo-6m.yaml | 62 +++++++++++++++++++
.../devicetree/bindings/gnss/u-blox.txt | 45 --------------
2 files changed, 62 insertions(+), 45 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gnss/u-blox,neo-6m.yaml
delete mode 100644 Documentation/devicetree/bindings/gnss/u-blox.txt
@@ -0,0 +1,62 @@+# SPDX-License-Identifier: GPL-2.0+%YAML1.2+---+$id:http://devicetree.org/schemas/gnss/u-blox,neo-6m.yaml#+$schema:http://devicetree.org/meta-schemas/core.yaml#++title:U-blox GNSS Receiver Device Tree Bindings++maintainers:+-Johan Hovold <johan@kernel.org>++description:>+The U-blox GNSS receivers can use UART, DDC (I2C), SPI and USB interfaces.++properties:+compatible:+enum:+-u-blox,neo-6m+-u-blox,neo-8+-u-blox,neo-m8++reg:+description:>+The DDC Slave Address, SPI chip select address, the number of the USB hub+port or the USB host-controller port to wich this device is attached,+depending on the bus used. Required for the DDC, SPI or USB busses.++vcc-supply:+description:>+Main voltage regulator++timepulse-gpios:+maxItems:1+description:>+Time pulse GPIO++u-blox,extint-gpios:+maxItems:1+description:>+GPIO connected to the "external interrupt" input pin++v-bckp-supply:+description:>+Backup voltage regulator++current-speed:true++required:+-compatible+-vcc-supply++additionalProperties:false++examples:+-|+uart {+gnss {+compatible = "u-blox,neo-8";+v-bckp-supply = <&gnss_v_bckp_reg>;+vcc-supply = <&gnss_vcc_reg>;+};+};
@@ -1,45 +0,0 @@-u-blox GNSS Receiver DT binding--The u-blox GNSS receivers can use UART, DDC (I2C), SPI and USB interfaces.--Please see Documentation/devicetree/bindings/gnss/gnss.txt for generic-properties.--Required properties:--- compatible : Must be one of-- "u-blox,neo-6m"- "u-blox,neo-8"- "u-blox,neo-m8"--- vcc-supply : Main voltage regulator--Required properties (DDC):-- reg : DDC (I2C) slave address--Required properties (SPI):-- reg : SPI chip select address--Required properties (USB):-- reg : Number of the USB hub port or the USB host-controller port- to which this device is attached--Optional properties:--- timepulse-gpios : Time pulse GPIO-- u-blox,extint-gpios : GPIO connected to the "external interrupt" input pin-- v-bckp-supply : Backup voltage regulator--Example:--serial@1234 {- compatible = "ns16550a";-- gnss {- compatible = "u-blox,neo-8";-- v-bckp-supply = <&gnss_v_bckp_reg>;- vcc-supply = <&gnss_vcc_reg>;- };-};
From: Rob Herring <robh@kernel.org> Date: 2021-07-23 21:42:41
On Wed, Jul 21, 2021 at 04:03:42PM +0200, Maxime Ripard wrote:
quoted hunk
The UBlox Neo 6M is supported by Linux thanks to its device tree
binding.
Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.
Cc: Johan Hovold <johan@kernel.org>
Signed-off-by: Maxime Ripard <redacted>
---
.../bindings/gnss/u-blox,neo-6m.yaml | 62 +++++++++++++++++++
.../devicetree/bindings/gnss/u-blox.txt | 45 --------------
2 files changed, 62 insertions(+), 45 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gnss/u-blox,neo-6m.yaml
delete mode 100644 Documentation/devicetree/bindings/gnss/u-blox.txt
@@ -0,0 +1,62 @@+# SPDX-License-Identifier: GPL-2.0+%YAML1.2+---+$id:http://devicetree.org/schemas/gnss/u-blox,neo-6m.yaml#+$schema:http://devicetree.org/meta-schemas/core.yaml#++title:U-blox GNSS Receiver Device Tree Bindings++maintainers:+-Johan Hovold <johan@kernel.org>++description:>+The U-blox GNSS receivers can use UART, DDC (I2C), SPI and USB interfaces.++properties:+compatible:+enum:+-u-blox,neo-6m+-u-blox,neo-8+-u-blox,neo-m8++reg:+description:>+The DDC Slave Address, SPI chip select address, the number of the USB hub+port or the USB host-controller port to wich this device is attached,
s/wich/which/
+ depending on the bus used. Required for the DDC, SPI or USB busses.
+
+ vcc-supply:
+ description: >
+ Main voltage regulator
+
+ timepulse-gpios:
+ maxItems: 1
+ description: >
+ Time pulse GPIO
+
+ u-blox,extint-gpios:
+ maxItems: 1
+ description: >
+ GPIO connected to the "external interrupt" input pin
+
+ v-bckp-supply:
+ description: >
+ Backup voltage regulator
+
+ current-speed: true
+
+required:
+ - compatible
+ - vcc-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ uart {
@@ -1,45 +0,0 @@-u-blox GNSS Receiver DT binding--The u-blox GNSS receivers can use UART, DDC (I2C), SPI and USB interfaces.--Please see Documentation/devicetree/bindings/gnss/gnss.txt for generic-properties.--Required properties:--- compatible : Must be one of-- "u-blox,neo-6m"- "u-blox,neo-8"- "u-blox,neo-m8"--- vcc-supply : Main voltage regulator--Required properties (DDC):-- reg : DDC (I2C) slave address--Required properties (SPI):-- reg : SPI chip select address--Required properties (USB):-- reg : Number of the USB hub port or the USB host-controller port- to which this device is attached--Optional properties:--- timepulse-gpios : Time pulse GPIO-- u-blox,extint-gpios : GPIO connected to the "external interrupt" input pin-- v-bckp-supply : Backup voltage regulator--Example:--serial@1234 {- compatible = "ns16550a";-- gnss {- compatible = "u-blox,neo-8";-- v-bckp-supply = <&gnss_v_bckp_reg>;- vcc-supply = <&gnss_vcc_reg>;- };-};
From: Maxime Ripard <hidden> Date: 2021-07-21 14:04:58
The X-Powers AXP PMICs feature a GPIO Controller supported by Linux
thanks to its device tree binding.
Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.
Cc: Bartosz Golaszewski <redacted>
Cc: Chen-Yu Tsai <redacted>
Cc: Linus Walleij <redacted>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Maxime Ripard <redacted>
---
.../devicetree/bindings/gpio/gpio-axp209.txt | 75 -----------------
.../bindings/gpio/x-powers,axp209-gpio.yaml | 84 +++++++++++++++++++
2 files changed, 84 insertions(+), 75 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-axp209.txt
create mode 100644 Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml
@@ -1,75 +0,0 @@-AXP209 GPIO & pinctrl controller--This driver follows the usual GPIO bindings found in-Documentation/devicetree/bindings/gpio/gpio.txt--This driver follows the usual pinctrl bindings found in-Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt--This driver employs the per-pin muxing pattern.--Required properties:-- compatible: Should be one of:- - "x-powers,axp209-gpio"- - "x-powers,axp813-gpio"-- #gpio-cells: Should be two. The first cell is the pin number and the- second is the GPIO flags.-- gpio-controller: Marks the device node as a GPIO controller.--This node must be a subnode of the axp20x PMIC, documented in-Documentation/devicetree/bindings/mfd/axp20x.txt--Example:--axp209: pmic@34 {- compatible = "x-powers,axp209";- reg = <0x34>;- interrupt-parent = <&nmi_intc>;- interrupts = <0 IRQ_TYPE_LEVEL_LOW>;- interrupt-controller;- #interrupt-cells = <1>;-- axp_gpio: gpio {- compatible = "x-powers,axp209-gpio";- gpio-controller;- #gpio-cells = <2>;- };-};--The GPIOs can be muxed to other functions and therefore, must be a subnode of-axp_gpio.--Example:--&axp_gpio {- gpio0_adc: gpio0-adc {- pins = "GPIO0";- function = "adc";- };-};--&example_node {- pinctrl-names = "default";- pinctrl-0 = <&gpio0_adc>;-};--GPIOs and their functions----------------------------Each GPIO is independent from the other (i.e. GPIO0 in gpio_in function does-not force GPIO1 and GPIO2 to be in gpio_in function as well).--axp209--------GPIO | Functions--------------------------GPIO0 | gpio_in, gpio_out, ldo, adc-GPIO1 | gpio_in, gpio_out, ldo, adc-GPIO2 | gpio_in, gpio_out--axp813--------GPIO | Functions--------------------------GPIO0 | gpio_in, gpio_out, ldo, adc-GPIO1 | gpio_in, gpio_out, ldo
From: Rob Herring <robh@kernel.org> Date: 2021-07-22 02:10:16
On Wed, 21 Jul 2021 16:03:43 +0200, Maxime Ripard wrote:
The X-Powers AXP PMICs feature a GPIO Controller supported by Linux
thanks to its device tree binding.
Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.
Cc: Bartosz Golaszewski <redacted>
Cc: Chen-Yu Tsai <redacted>
Cc: Linus Walleij <redacted>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Maxime Ripard <redacted>
---
.../devicetree/bindings/gpio/gpio-axp209.txt | 75 -----------------
.../bindings/gpio/x-powers,axp209-gpio.yaml | 84 +++++++++++++++++++
2 files changed, 84 insertions(+), 75 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-axp209.txt
create mode 100644 Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.example.dt.yaml:0:0: /example-0/i2c/pmic@34: failed to match any schema with compatible: ['x-powers,axp209']
\ndoc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/patch/1508257
This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit.
From: Rob Herring <robh+dt@kernel.org> Date: 2021-07-22 02:13:33
On Wed, Jul 21, 2021 at 8:10 PM Rob Herring [off-list ref] wrote:
On Wed, 21 Jul 2021 16:03:43 +0200, Maxime Ripard wrote:
quoted
The X-Powers AXP PMICs feature a GPIO Controller supported by Linux
thanks to its device tree binding.
Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.
Cc: Bartosz Golaszewski <redacted>
Cc: Chen-Yu Tsai <redacted>
Cc: Linus Walleij <redacted>
Cc: linux-gpio@vger.kernel.org
Signed-off-by: Maxime Ripard <redacted>
---
.../devicetree/bindings/gpio/gpio-axp209.txt | 75 -----------------
.../bindings/gpio/x-powers,axp209-gpio.yaml | 84 +++++++++++++++++++
2 files changed, 84 insertions(+), 75 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/gpio/gpio-axp209.txt
create mode 100644 Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.yaml
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/gpio/x-powers,axp209-gpio.example.dt.yaml:0:0: /example-0/i2c/pmic@34: failed to match any schema with compatible: ['x-powers,axp209']
Please make the mfd schema example complete if not already and drop
the example here.
Rob
From: Maxime Ripard <hidden> Date: 2021-07-21 14:05:00
Even though we had the iio-hwmon driver for some time and a number of
boards using it already, we never had a binding for it. Let's add it
based on what the driver expects and the boards are providing.
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Jean Delvare <jdelvare@suse.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: linux-hwmon@vger.kernel.org
Signed-off-by: Maxime Ripard <redacted>
---
.../devicetree/bindings/hwmon/iio-hwmon.yaml | 37 +++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml
@@ -0,0 +1,37 @@+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)+%YAML1.2+---+$id:"http://devicetree.org/schemas/hwmon/iio-hwmon.yaml#"+$schema:"http://devicetree.org/meta-schemas/core.yaml#"++title:ADC-attached Hardware Sensor Device Tree Bindings++maintainers:+-Jonathan Cameron <jic23@kernel.org>++description:>+Bindings for hardware monitoring devices connected to ADC controllers+supporting the Industrial I/O bindings.++properties:+compatible:+const:iio-hwmon++io-channels:+minItems:1+maxItems:1024+description:>+List of phandles to ADC channels to read the monitoring values++required:+-compatible+-io-channels++additionalProperties:false++examples:+-|+iio-hwmon {+compatible = "iio-hwmon";+io-channels = <&adc 1>, <&adc 2>;+};
From: Jonathan Cameron <Jonathan.Cameron@Huawei.com> Date: 2021-07-22 09:20:56
On Wed, 21 Jul 2021 16:03:44 +0200
Maxime Ripard [off-list ref] wrote:
quoted hunk
Even though we had the iio-hwmon driver for some time and a number of
boards using it already, we never had a binding for it. Let's add it
based on what the driver expects and the boards are providing.
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Jean Delvare <jdelvare@suse.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: linux-hwmon@vger.kernel.org
Signed-off-by: Maxime Ripard <redacted>
---
.../devicetree/bindings/hwmon/iio-hwmon.yaml | 37 +++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml
From: Maxime Ripard <hidden> Date: 2021-07-22 09:35:00
Hi Jonathan,
On Thu, Jul 22, 2021 at 10:20:27AM +0100, Jonathan Cameron wrote:
On Wed, 21 Jul 2021 16:03:44 +0200
Maxime Ripard [off-list ref] wrote:
quoted
Even though we had the iio-hwmon driver for some time and a number of
boards using it already, we never had a binding for it. Let's add it
based on what the driver expects and the boards are providing.
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Jean Delvare <jdelvare@suse.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: linux-hwmon@vger.kernel.org
Signed-off-by: Maxime Ripard <redacted>
---
.../devicetree/bindings/hwmon/iio-hwmon.yaml | 37 +++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml
Ought to be enough for anyone :)
We have to set a maximum and I couldn't find any actual maximum
documented, if you prefer another value let me know
Maxime
From: Rob Herring <robh@kernel.org> Date: 2021-07-23 21:44:11
On Thu, Jul 22, 2021 at 11:34:53AM +0200, Maxime Ripard wrote:
Hi Jonathan,
On Thu, Jul 22, 2021 at 10:20:27AM +0100, Jonathan Cameron wrote:
quoted
On Wed, 21 Jul 2021 16:03:44 +0200
Maxime Ripard [off-list ref] wrote:
quoted
Even though we had the iio-hwmon driver for some time and a number of
boards using it already, we never had a binding for it. Let's add it
based on what the driver expects and the boards are providing.
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Jean Delvare <jdelvare@suse.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: linux-hwmon@vger.kernel.org
Signed-off-by: Maxime Ripard <redacted>
---
.../devicetree/bindings/hwmon/iio-hwmon.yaml | 37 +++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/iio-hwmon.yaml
From: Maxime Ripard <hidden> Date: 2021-07-21 14:05:02
The original bindings was listing the length of the interrupts as either
1 or 2, depending on the setup. This is also what is enforced by the top
level schema.
However, that is further constrained with an if clause that require
exactly two interrupts, even though it might not make sense on those
devices or in some setups.
Let's remove the clause entirely.
Cc: Denis Ciocca <redacted>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Linus Walleij <redacted>
Cc: linux-iio@vger.kernel.org
Signed-off-by: Maxime Ripard <redacted>
---
.../bindings/iio/st,st-sensors.yaml | 41 -------------------
1 file changed, 41 deletions(-)
From: Rob Herring <robh@kernel.org> Date: 2021-07-23 21:47:58
On Wed, 21 Jul 2021 16:03:45 +0200, Maxime Ripard wrote:
The original bindings was listing the length of the interrupts as either
1 or 2, depending on the setup. This is also what is enforced by the top
level schema.
However, that is further constrained with an if clause that require
exactly two interrupts, even though it might not make sense on those
devices or in some setups.
Let's remove the clause entirely.
Cc: Denis Ciocca <redacted>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Linus Walleij <redacted>
Cc: linux-iio@vger.kernel.org
Signed-off-by: Maxime Ripard <redacted>
---
.../bindings/iio/st,st-sensors.yaml | 41 -------------------
1 file changed, 41 deletions(-)
On Wed, Jul 21, 2021 at 4:05 PM Maxime Ripard [off-list ref] wrote:
The original bindings was listing the length of the interrupts as either
1 or 2, depending on the setup. This is also what is enforced by the top
level schema.
However, that is further constrained with an if clause that require
exactly two interrupts, even though it might not make sense on those
devices or in some setups.
Let's remove the clause entirely.
Cc: Denis Ciocca <redacted>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: Lars-Peter Clausen <lars@metafoo.de>
Cc: Linus Walleij <redacted>
Cc: linux-iio@vger.kernel.org
Signed-off-by: Maxime Ripard <redacted>
Oops this was too ambitious. Sorry about that.
Reviewed-by: Linus Walleij <redacted>
Yours,
Linus Walleij
From: Maxime Ripard <hidden> Date: 2021-07-21 14:05:04
The ChipOne ICN8318 Touchscreen Controller is supported by Linux thanks
to its device tree binding.
Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Hans de Goede <redacted>
Cc: linux-input@vger.kernel.org
Signed-off-by: Maxime Ripard <redacted>
---
.../input/touchscreen/chipone,icn8318.yaml | 62 +++++++++++++++++++
.../input/touchscreen/chipone_icn8318.txt | 44 -------------
2 files changed, 62 insertions(+), 44 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/chipone,icn8318.yaml
delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/chipone_icn8318.txt
From: Rob Herring <robh@kernel.org> Date: 2021-07-23 21:49:01
On Wed, 21 Jul 2021 16:03:46 +0200, Maxime Ripard wrote:
The ChipOne ICN8318 Touchscreen Controller is supported by Linux thanks
to its device tree binding.
Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Hans de Goede <redacted>
Cc: linux-input@vger.kernel.org
Signed-off-by: Maxime Ripard <redacted>
---
.../input/touchscreen/chipone,icn8318.yaml | 62 +++++++++++++++++++
.../input/touchscreen/chipone_icn8318.txt | 44 -------------
2 files changed, 62 insertions(+), 44 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/chipone,icn8318.yaml
delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/chipone_icn8318.txt
From: Maxime Ripard <hidden> Date: 2021-07-21 14:05:08
The Pixcir Touchscreen Controller is supported by Linux thanks to
its device tree binding.
Now that we have the DT validation in place, let's convert the device
tree bindings for that driver over to a YAML schema.
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org
Signed-off-by: Maxime Ripard <redacted>
---
.../input/touchscreen/pixcir,pixcir_ts.yaml | 68 +++++++++++++++++++
.../input/touchscreen/pixcir_i2c_ts.txt | 31 ---------
2 files changed, 68 insertions(+), 31 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/pixcir,pixcir_ts.yaml
delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/pixcir_i2c_ts.txt
@@ -1,31 +0,0 @@-* Pixcir I2C touchscreen controllers--Required properties:-- compatible: must be "pixcir,pixcir_ts" or "pixcir,pixcir_tangoc"-- reg: I2C address of the chip-- interrupts: interrupt to which the chip is connected-- attb-gpio: GPIO connected to the ATTB line of the chip-- touchscreen-size-x: horizontal resolution of touchscreen (in pixels)-- touchscreen-size-y: vertical resolution of touchscreen (in pixels)--Optional properties:-- reset-gpios: GPIO connected to the RESET line of the chip-- enable-gpios: GPIO connected to the ENABLE line of the chip-- wake-gpios: GPIO connected to the WAKE line of the chip--Example:-- i2c@00000000 {- /* ... */-- pixcir_ts@5c {- compatible = "pixcir,pixcir_ts";- reg = <0x5c>;- interrupts = <2 0>;- attb-gpio = <&gpf 2 0 2>;- touchscreen-size-x = <800>;- touchscreen-size-y = <600>;- };-- /* ... */- };