* [PATCH v2 2/7] dt-bindings: hsi: nokia-modem: convert to YAML
From: Sebastian Reichel @ 2024-03-27 19:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sebastian Reichel
Cc: Tony Lindgren, devicetree, linux-omap, linux-kernel,
Sebastian Reichel
In-Reply-To: <20240327-hsi-dt-binding-v2-0-110fab4c32ae@collabora.com>
Convert the legacy txt binding to modern YAML.
No semantic change.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
.../devicetree/bindings/hsi/nokia,modem.yaml | 106 +++++++++++++++++++++
.../devicetree/bindings/hsi/nokia-modem.txt | 59 ------------
2 files changed, 106 insertions(+), 59 deletions(-)
diff --git a/Documentation/devicetree/bindings/hsi/nokia,modem.yaml b/Documentation/devicetree/bindings/hsi/nokia,modem.yaml
new file mode 100644
index 000000000000..f6d5e2c14329
--- /dev/null
+++ b/Documentation/devicetree/bindings/hsi/nokia,modem.yaml
@@ -0,0 +1,106 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hsi/nokia,modem.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Nokia modem
+
+maintainers:
+ - Sebastian Reichel <sre@kernel.org>
+
+properties:
+ compatible:
+ enum:
+ - nokia,n900-modem
+ - nokia,n950-modem
+ - nokia,n9-modem
+
+ hsi-channel-ids:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 4
+ maxItems: 4
+
+ hsi-channel-names:
+ items:
+ - const: mcsaab-control
+ - const: speech-control
+ - const: speech-data
+ - const: mcsaab-data
+
+ interrupts:
+ items:
+ - description: modem reset indication
+
+ gpios:
+ minItems: 3
+ maxItems: 5
+
+ gpio-names:
+ items:
+ - const: cmt_apeslpx
+ - const: cmt_rst_rq
+ - const: cmt_en
+ - const: cmt_rst
+ - const: cmt_bsi
+ minItems: 3
+
+required:
+ - gpios
+ - gpio-names
+ - interrupts
+
+allOf:
+ - $ref: hsi-client.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - nokia,n950-modem
+ - nokia,n9-modem
+ then:
+ properties:
+ gpios:
+ maxItems: 3
+ gpio-names:
+ maxItems: 3
+ else:
+ properties:
+ gpios:
+ minItems: 5
+ gpio-names:
+ minItems: 5
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+ modem {
+ compatible = "nokia,n900-modem";
+
+ hsi-channel-ids = <0>, <1>, <2>, <3>;
+ hsi-channel-names = "mcsaab-control",
+ "speech-control",
+ "speech-data",
+ "mcsaab-data";
+ hsi-speed-kbps = <55000>;
+ hsi-mode = "frame";
+ hsi-flow = "synchronized";
+ hsi-arb-mode = "round-robin";
+
+ interrupts-extended = <&gpio3 8 IRQ_TYPE_EDGE_FALLING>;
+
+ gpios = <&gpio3 6 GPIO_ACTIVE_HIGH>,
+ <&gpio3 9 GPIO_ACTIVE_HIGH>,
+ <&gpio3 10 GPIO_ACTIVE_HIGH>,
+ <&gpio3 11 GPIO_ACTIVE_HIGH>,
+ <&gpio5 29 GPIO_ACTIVE_HIGH>;
+ gpio-names = "cmt_apeslpx",
+ "cmt_rst_rq",
+ "cmt_en",
+ "cmt_rst",
+ "cmt_bsi";
+ };
diff --git a/Documentation/devicetree/bindings/hsi/nokia-modem.txt b/Documentation/devicetree/bindings/hsi/nokia-modem.txt
deleted file mode 100644
index 53de1d9d0b95..000000000000
--- a/Documentation/devicetree/bindings/hsi/nokia-modem.txt
+++ /dev/null
@@ -1,59 +0,0 @@
-Nokia modem client bindings
-
-The Nokia modem HSI client follows the common HSI client binding
-and inherits all required properties. The following additional
-properties are needed by the Nokia modem HSI client:
-
-Required properties:
-- compatible: Should be one of
- "nokia,n900-modem"
- "nokia,n950-modem"
- "nokia,n9-modem"
-- hsi-channel-names: Should contain the following strings
- "mcsaab-control"
- "speech-control"
- "speech-data"
- "mcsaab-data"
-- gpios: Should provide a GPIO handler for each GPIO listed in
- gpio-names
-- gpio-names: Should contain the following strings
- "cmt_apeslpx" (for n900, n950, n9)
- "cmt_rst_rq" (for n900, n950, n9)
- "cmt_en" (for n900, n950, n9)
- "cmt_rst" (for n900)
- "cmt_bsi" (for n900)
-- interrupts: Should be IRQ handle for modem's reset indication
-
-Example:
-
-&ssi_port {
- modem: hsi-client {
- compatible = "nokia,n900-modem";
-
- pinctrl-names = "default";
- pinctrl-0 = <&modem_pins>;
-
- hsi-channel-ids = <0>, <1>, <2>, <3>;
- hsi-channel-names = "mcsaab-control",
- "speech-control",
- "speech-data",
- "mcsaab-data";
- hsi-speed-kbps = <55000>;
- hsi-mode = "frame";
- hsi-flow = "synchronized";
- hsi-arb-mode = "round-robin";
-
- interrupts-extended = <&gpio3 8 IRQ_TYPE_EDGE_FALLING>; /* 72 */
-
- gpios = <&gpio3 6 GPIO_ACTIVE_HIGH>, /* 70 */
- <&gpio3 9 GPIO_ACTIVE_HIGH>, /* 73 */
- <&gpio3 10 GPIO_ACTIVE_HIGH>, /* 74 */
- <&gpio3 11 GPIO_ACTIVE_HIGH>, /* 75 */
- <&gpio5 29 GPIO_ACTIVE_HIGH>; /* 157 */
- gpio-names = "cmt_apeslpx",
- "cmt_rst_rq",
- "cmt_en",
- "cmt_rst",
- "cmt_bsi";
- };
-};
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/7] Convert MIPI HSI DT bindings to YAML
From: Sebastian Reichel @ 2024-03-27 19:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sebastian Reichel
Cc: Tony Lindgren, devicetree, linux-omap, linux-kernel,
Sebastian Reichel
Hi,
This converts all MIPI HSI subystem DT bindings to YAML.
I ran the following tests:
1. Check binding files
make -j$(nproc) dt_binding_check DT_SCHEMA_FILES=/hsi/
2. Check OMAP3 and nokia-modem DT
make -j$(nproc) CHECK_DTBS=y ti/omap/omap3-n900.dtb ti/omap/omap3-n950.dtb ti/omap/omap3-n9.dtb
3. Check OMAP4 DT (OMAP4 HSI is not used upstream, so one is enough)
make -j$(nproc) CHECK_DTBS=y ti/omap/omap4-droid4-xt894.dtb
FWIW I noticed a lots of warnings for OMAP3 & OMAP4, but
none related to HSI/SSI.
Greetings,
-- Sebastian
---
Changes in v2:
- Link to v1: https://lore.kernel.org/r/20240325-hsi-dt-binding-v1-0-88e8e97c3aae@collabora.com
- fixed, that "hsi-client" is not a generic node name
- hsi-client.yaml needs to use oneOf instead of anyOf for the hsi-mode requirement
- change nokia-modem.yaml to nokia,modem.yaml
- add hsi-channel-ids constraints to nokia modem binding; I had to also add
$ref: /schemas/types.yaml#/definitions/uint32-array again, because otherwise
the tooling complained about the example DT having not enough IDs for
[[0], [1], [2], [3]]. It does properly inherit the hsi-client.yaml, though.
If I drop the constraints from the modem binding and change the generic binding
to require 5 IDs, the tooling does complain. So I think this is a bug in the DT
checking tool. For now readding the ref again seems to be a good enough workaround.
- changed node name to "modem" for the nokia modem
- renamed ti,ssi-cawake-gpio to ti,ssi-cawake-gpios
- changed ssi-port@ & hsi-port@ to just port@
- dropped blank line in omap-ssi binding
- moved additionalProperties before the examples in omap-ssi binding
- fixed indentation for the omaps-ssi example in the binding
- added patches fixing up OMAP3 & OMAP4 DT files according to the latest changes
---
Sebastian Reichel (7):
dt-bindings: hsi: hsi-client: convert to YAML
dt-bindings: hsi: nokia-modem: convert to YAML
dt-bindings: hsi: omap-ssi: convert to YAML
ARM: dts: omap4: fix hsi-port node name
ARM: dts: omap3: fix ssi-port node name
ARM: dts: omap3: fix ti,ssi-cawake-gpio property name
ARM: dts: omap3: use generic node name for hsi clients
.../devicetree/bindings/hsi/client-devices.txt | 44 -----
.../devicetree/bindings/hsi/hsi-client.yaml | 81 ++++++++++
.../devicetree/bindings/hsi/nokia,modem.yaml | 106 ++++++++++++
.../devicetree/bindings/hsi/nokia-modem.txt | 59 -------
Documentation/devicetree/bindings/hsi/omap-ssi.txt | 102 ------------
.../devicetree/bindings/hsi/ti,omap-ssi.yaml | 177 +++++++++++++++++++++
arch/arm/boot/dts/ti/omap/omap3-n900.dts | 4 +-
arch/arm/boot/dts/ti/omap/omap3-n950-n9.dtsi | 4 +-
arch/arm/boot/dts/ti/omap/omap3.dtsi | 4 +-
arch/arm/boot/dts/ti/omap/omap4-l4.dtsi | 4 +-
10 files changed, 372 insertions(+), 213 deletions(-)
---
base-commit: 4cece764965020c22cff7665b18a012006359095
change-id: 20240325-hsi-dt-binding-a5d662e3d601
Best regards,
--
Sebastian Reichel <sebastian.reichel@collabora.com>
^ permalink raw reply
* [PATCH v2 3/7] dt-bindings: hsi: omap-ssi: convert to YAML
From: Sebastian Reichel @ 2024-03-27 19:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sebastian Reichel
Cc: Tony Lindgren, devicetree, linux-omap, linux-kernel,
Sebastian Reichel
In-Reply-To: <20240327-hsi-dt-binding-v2-0-110fab4c32ae@collabora.com>
Convert the legacy txt binding to modern YAML.
There are a couple of semantic changes:
- hsi-port@<addr> and ssi-port@<addr> node name
changed to port@<addr>
- ti,hwmods was marked as deprecated. This is supposed to go away
once OMAP3 gets the same treatment as OMAP4.
- changed ti,cawake-gpio to ti,cawake-gpios
- describe peripheral requirements for the port node
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
Documentation/devicetree/bindings/hsi/omap-ssi.txt | 102 ------------
.../devicetree/bindings/hsi/ti,omap-ssi.yaml | 177 +++++++++++++++++++++
2 files changed, 177 insertions(+), 102 deletions(-)
diff --git a/Documentation/devicetree/bindings/hsi/omap-ssi.txt b/Documentation/devicetree/bindings/hsi/omap-ssi.txt
deleted file mode 100644
index 77a0c3c3036e..000000000000
--- a/Documentation/devicetree/bindings/hsi/omap-ssi.txt
+++ /dev/null
@@ -1,102 +0,0 @@
-OMAP SSI controller bindings
-
-OMAP3's Synchronous Serial Interface (SSI) controller implements a
-legacy variant of MIPI's High Speed Synchronous Serial Interface (HSI),
-while the controller found inside OMAP4 is supposed to be fully compliant
-with the HSI standard.
-
-Required properties:
-- compatible: Should include "ti,omap3-ssi" or "ti,omap4-hsi"
-- reg-names: Contains the values "sys" and "gdd" (in this order).
-- reg: Contains a matching register specifier for each entry
- in reg-names.
-- interrupt-names: Contains the value "gdd_mpu".
-- interrupts: Contains matching interrupt information for each entry
- in interrupt-names.
-- ranges: Represents the bus address mapping between the main
- controller node and the child nodes below.
-- clock-names: Must include the following entries:
- "ssi_ssr_fck": The OMAP clock of that name
- "ssi_sst_fck": The OMAP clock of that name
- "ssi_ick": The OMAP clock of that name
-- clocks: Contains a matching clock specifier for each entry in
- clock-names.
-- #address-cells: Should be set to <1>
-- #size-cells: Should be set to <1>
-
-Each port is represented as a sub-node of the ti,omap3-ssi device.
-
-Required Port sub-node properties:
-- compatible: Should be set to the following value
- ti,omap3-ssi-port (applicable to OMAP34xx devices)
- ti,omap4-hsi-port (applicable to OMAP44xx devices)
-- reg-names: Contains the values "tx" and "rx" (in this order).
-- reg: Contains a matching register specifier for each entry
- in reg-names.
-- interrupts: Should contain interrupt specifiers for mpu interrupts
- 0 and 1 (in this order).
-- ti,ssi-cawake-gpio: Defines which GPIO pin is used to signify CAWAKE
- events for the port. This is an optional board-specific
- property. If it's missing the port will not be
- enabled.
-
-Optional properties:
-- ti,hwmods: Shall contain TI interconnect module name if needed
- by the SoC
-
-Example for Nokia N900:
-
-ssi-controller@48058000 {
- compatible = "ti,omap3-ssi";
-
- /* needed until hwmod is updated to use the compatible string */
- ti,hwmods = "ssi";
-
- reg = <0x48058000 0x1000>,
- <0x48059000 0x1000>;
- reg-names = "sys",
- "gdd";
-
- interrupts = <55>;
- interrupt-names = "gdd_mpu";
-
- clocks = <&ssi_ssr_fck>,
- <&ssi_sst_fck>,
- <&ssi_ick>;
- clock-names = "ssi_ssr_fck",
- "ssi_sst_fck",
- "ssi_ick";
-
- #address-cells = <1>;
- #size-cells = <1>;
- ranges;
-
- ssi-port@4805a000 {
- compatible = "ti,omap3-ssi-port";
-
- reg = <0x4805a000 0x800>,
- <0x4805a800 0x800>;
- reg-names = "tx",
- "rx";
-
- interrupt-parent = <&intc>;
- interrupts = <67>,
- <68>;
-
- ti,ssi-cawake-gpio = <&gpio5 23 GPIO_ACTIVE_HIGH>; /* 151 */
- }
-
- ssi-port@4805a000 {
- compatible = "ti,omap3-ssi-port";
-
- reg = <0x4805b000 0x800>,
- <0x4805b800 0x800>;
- reg-names = "tx",
- "rx";
-
- interrupt-parent = <&intc>;
- interrupts = <69>,
- <70>;
-
- }
-}
diff --git a/Documentation/devicetree/bindings/hsi/ti,omap-ssi.yaml b/Documentation/devicetree/bindings/hsi/ti,omap-ssi.yaml
new file mode 100644
index 000000000000..433e2b2c36ea
--- /dev/null
+++ b/Documentation/devicetree/bindings/hsi/ti,omap-ssi.yaml
@@ -0,0 +1,177 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hsi/ti,omap-ssi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SSI Controller on OMAP SoCs
+
+description:
+ OMAP3's Synchronous Serial Interface (SSI) controller implements a
+ legacy variant of MIPI's High Speed Synchronous Serial Interface (HSI),
+ while the controller found inside OMAP4 is supposed to be fully compliant
+ with the HSI standard.
+
+maintainers:
+ - Sebastian Reichel <sre@kernel.org>
+
+properties:
+ compatible:
+ enum:
+ - ti,omap3-ssi
+ - ti,omap4-hsi
+
+ reg:
+ items:
+ - description: registers for sys
+ - description: registers for gdd
+
+ reg-names:
+ items:
+ - const: sys
+ - const: gdd
+
+ ranges: true
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 1
+
+ clocks:
+ minItems: 1
+ maxItems: 3
+
+ clock-names:
+ minItems: 1
+ maxItems: 3
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-names:
+ const: gdd_mpu
+
+ ti,hwmods:
+ const: ssi
+ deprecated: true
+
+patternProperties:
+ "port@[0-9a-f]+":
+ type: object
+ additionalProperties: false
+
+ properties:
+ compatible:
+ enum:
+ - ti,omap3-ssi-port
+ - ti,omap4-hsi-port
+
+ reg:
+ items:
+ - description: TX registers
+ - description: RX registers
+
+ reg-names:
+ items:
+ - const: tx
+ - const: rx
+
+ interrupts:
+ items:
+ - description: MPU interrupt 0
+ - description: MPU interrupt 1
+ minItems: 1
+
+ ti,ssi-cawake-gpios:
+ description: GPIO signifying CAWAKE events
+ maxItems: 1
+
+ patternProperties:
+ "^(modem|mcu)$":
+ type: object
+ $ref: /schemas/hsi/hsi-client.yaml#
+
+ required:
+ - compatible
+ - reg
+ - reg-names
+ - interrupts
+
+required:
+ - compatible
+ - reg
+ - reg-names
+ - ranges
+ - "#address-cells"
+ - "#size-cells"
+ - clocks
+ - clock-names
+ - interrupts
+ - interrupt-names
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,omap3-ssi
+ then:
+ properties:
+ clocks:
+ minItems: 3
+ clock-names:
+ items:
+ - const: ssi_ssr_fck
+ - const: ssi_sst_fck
+ - const: ssi_ick
+ else:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names:
+ items:
+ - const: hsi_fck
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ ssi-controller@48058000 {
+ compatible = "ti,omap3-ssi";
+ reg = <0x48058000 0x1000>,
+ <0x48059000 0x1000>;
+ reg-names = "sys", "gdd";
+ ranges;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ clocks = <&ssi_ssr_fck>,
+ <&ssi_sst_fck>,
+ <&ssi_ick>;
+ clock-names = "ssi_ssr_fck",
+ "ssi_sst_fck",
+ "ssi_ick";
+ interrupts = <55>;
+ interrupt-names = "gdd_mpu";
+
+ port@4805a000 {
+ compatible = "ti,omap3-ssi-port";
+ reg = <0x4805a000 0x800>,
+ <0x4805a800 0x800>;
+ reg-names = "tx", "rx";
+ interrupt-parent = <&intc>;
+ interrupts = <67>, <68>;
+ ti,ssi-cawake-gpios = <&gpio5 23 GPIO_ACTIVE_HIGH>;
+ };
+
+ port@4805b000 {
+ compatible = "ti,omap3-ssi-port";
+ reg = <0x4805b000 0x800>,
+ <0x4805b800 0x800>;
+ reg-names = "tx", "rx";
+ interrupt-parent = <&intc>;
+ interrupts = <69>, <70>;
+ };
+ };
--
2.43.0
^ permalink raw reply related
* [PATCH v2 4/7] ARM: dts: omap4: fix hsi-port node name
From: Sebastian Reichel @ 2024-03-27 19:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sebastian Reichel
Cc: Tony Lindgren, devicetree, linux-omap, linux-kernel,
Sebastian Reichel
In-Reply-To: <20240327-hsi-dt-binding-v2-0-110fab4c32ae@collabora.com>
The DT binding specifies, that the node names for the HSI ports should
be just 'port@<address>' instead of 'hsi-port@<address>'.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
arch/arm/boot/dts/ti/omap/omap4-l4.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi b/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi
index 3fcef3080eae..8963c966cac7 100644
--- a/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi
+++ b/arch/arm/boot/dts/ti/omap/omap4-l4.dtsi
@@ -214,7 +214,7 @@ hsi: hsi@0 {
#size-cells = <1>;
ranges = <0 0 0x4000>;
- hsi_port1: hsi-port@2000 {
+ hsi_port1: port@2000 {
compatible = "ti,omap4-hsi-port";
reg = <0x2000 0x800>,
<0x2800 0x800>;
@@ -222,7 +222,7 @@ hsi_port1: hsi-port@2000 {
interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>;
};
- hsi_port2: hsi-port@3000 {
+ hsi_port2: port@3000 {
compatible = "ti,omap4-hsi-port";
reg = <0x3000 0x800>,
<0x3800 0x800>;
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/7] dt-bindings: hsi: hsi-client: convert to YAML
From: Sebastian Reichel @ 2024-03-27 19:11 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sebastian Reichel
Cc: Tony Lindgren, devicetree, linux-omap, linux-kernel,
Sebastian Reichel
In-Reply-To: <20240327-hsi-dt-binding-v2-0-110fab4c32ae@collabora.com>
Convert the legacy txt binding to modern YAML and rename from
client-devices to hsi-client. Also the example got dropped,
since this is a shared schema. No semantic change in the binding
itself.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
.../devicetree/bindings/hsi/client-devices.txt | 44 ------------
.../devicetree/bindings/hsi/hsi-client.yaml | 81 ++++++++++++++++++++++
2 files changed, 81 insertions(+), 44 deletions(-)
diff --git a/Documentation/devicetree/bindings/hsi/client-devices.txt b/Documentation/devicetree/bindings/hsi/client-devices.txt
deleted file mode 100644
index 104c9a3e57a4..000000000000
--- a/Documentation/devicetree/bindings/hsi/client-devices.txt
+++ /dev/null
@@ -1,44 +0,0 @@
-Each HSI port is supposed to have one child node, which
-symbols the remote device connected to the HSI port. The
-following properties are standardized for HSI clients:
-
-Required HSI configuration properties:
-
-- hsi-channel-ids: A list of channel ids
-
-- hsi-rx-mode: Receiver Bit transmission mode ("stream" or "frame")
-- hsi-tx-mode: Transmitter Bit transmission mode ("stream" or "frame")
-- hsi-mode: May be used instead hsi-rx-mode and hsi-tx-mode if
- the transmission mode is the same for receiver and
- transmitter
-- hsi-speed-kbps: Max bit transmission speed in kbit/s
-- hsi-flow: RX flow type ("synchronized" or "pipeline")
-- hsi-arb-mode: Arbitration mode for TX frame ("round-robin", "priority")
-
-Optional HSI configuration properties:
-
-- hsi-channel-names: A list with one name per channel specified in the
- hsi-channel-ids property
-
-
-Device Tree node example for an HSI client:
-
-hsi-controller {
- hsi-port {
- modem: hsi-client {
- compatible = "nokia,n900-modem";
-
- hsi-channel-ids = <0>, <1>, <2>, <3>;
- hsi-channel-names = "mcsaab-control",
- "speech-control",
- "speech-data",
- "mcsaab-data";
- hsi-speed-kbps = <55000>;
- hsi-mode = "frame";
- hsi-flow = "synchronized";
- hsi-arb-mode = "round-robin";
-
- /* more client specific properties */
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/hsi/hsi-client.yaml b/Documentation/devicetree/bindings/hsi/hsi-client.yaml
new file mode 100644
index 000000000000..9c8d6887e840
--- /dev/null
+++ b/Documentation/devicetree/bindings/hsi/hsi-client.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hsi/hsi-client.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: HSI bus peripheral
+
+description:
+ Each HSI port is supposed to have one child node, which
+ symbols the remote device connected to the HSI port.
+
+maintainers:
+ - Sebastian Reichel <sre@kernel.org>
+
+properties:
+ hsi-channel-ids:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 8
+
+ hsi-channel-names:
+ minItems: 1
+ maxItems: 8
+
+ hsi-rx-mode:
+ enum: [stream, frame]
+ description: Receiver Bit transmission mode
+
+ hsi-tx-mode:
+ enum: [stream, frame]
+ description: Transmitter Bit transmission mode
+
+ hsi-mode:
+ enum: [stream, frame]
+ description:
+ May be used instead hsi-rx-mode and hsi-tx-mode if the
+ transmission mode is the same for receiver and transmitter.
+
+ hsi-speed-kbps:
+ description: Max bit transmission speed in kbit/s
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ hsi-flow:
+ enum: [synchronized, pipeline]
+ description: RX flow type
+
+ hsi-arb-mode:
+ enum: [round-robin, priority]
+ description: Arbitration mode for TX frame
+
+additionalProperties: true
+
+required:
+ - compatible
+ - hsi-channel-ids
+ - hsi-speed-kbps
+ - hsi-flow
+ - hsi-arb-mode
+
+oneOf:
+ - required:
+ - hsi-mode
+ - required:
+ - hsi-rx-mode
+ - hsi-tx-mode
+
+allOf:
+ - if:
+ required:
+ - hsi-mode
+ then:
+ properties:
+ hsi-rx-mode: false
+ hsi-tx-mode: false
+ - if:
+ required:
+ - hsi-rx-mode
+ then:
+ properties:
+ hsi-mode: false
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v4 3/3] arm64: dts: qcom: apq8016: Add Schneider HMIBSC board DTS
From: Stephan Gerhold @ 2024-03-27 19:10 UTC (permalink / raw)
To: Sumit Garg
Cc: linux-arm-msm, devicetree, andersson, konrad.dybcio, robh+dt,
krzysztof.kozlowski+dt, conor+dt, caleb.connolly, neil.armstrong,
dmitry.baryshkov, laetitia.mariottini, pascal.eberhard,
abdou.saker, jimmy.lalande, benjamin.missey, daniel.thompson,
linux-kernel, Jagdish Gediya
In-Reply-To: <20240327063734.3236117-4-sumit.garg@linaro.org>
On Wed, Mar 27, 2024 at 12:07:34PM +0530, Sumit Garg wrote:
> Add Schneider Electric HMIBSC board DTS. The HMIBSC board is an IIoT Edge
> Box Core board based on the Qualcomm APQ8016E SoC.
>
> Support for Schneider Electric HMIBSC. Features:
> - Qualcomm Snapdragon 410C SoC - APQ8016 (4xCortex A53, Adreno 306)
> - 1GiB RAM
> - 8GiB eMMC, SD slot
> - WiFi and Bluetooth
> - 2x Host, 1x Device USB port
> - HDMI
> - Discrete TPM2 chip over SPI
> - USB ethernet adaptors (soldered)
>
> Co-developed-by: Jagdish Gediya <jagdish.gediya@linaro.org>
> Signed-off-by: Jagdish Gediya <jagdish.gediya@linaro.org>
> Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
This looks good to me now. Thanks for making all the changes!
Reviewed-by: Stephan Gerhold <stephan@gerhold.net>
Please drop the tag again in case you send another version with any
larger changes. I'm happy to look at the patch again then. Not sure if
Caleb's R-b is still valid now after all the changes you made.
I found one more nitpick below, but it also exists in apq8016-sbc.dts.
Feel free to leave it as-is, I can fix it up for both sometime later.
Thanks,
Stephan
> ---
> arch/arm64/boot/dts/qcom/Makefile | 1 +
> .../dts/qcom/apq8016-schneider-hmibsc.dts | 490 ++++++++++++++++++
> 2 files changed, 491 insertions(+)
> create mode 100644 arch/arm64/boot/dts/qcom/apq8016-schneider-hmibsc.dts
>
> diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> index 39889d5f8e12..ad55e52e950b 100644
> --- a/arch/arm64/boot/dts/qcom/Makefile
> +++ b/arch/arm64/boot/dts/qcom/Makefile
> @@ -5,6 +5,7 @@ apq8016-sbc-usb-host-dtbs := apq8016-sbc.dtb apq8016-sbc-usb-host.dtbo
>
> dtb-$(CONFIG_ARCH_QCOM) += apq8016-sbc-usb-host.dtb
> dtb-$(CONFIG_ARCH_QCOM) += apq8016-sbc-d3-camera-mezzanine.dtb
> +dtb-$(CONFIG_ARCH_QCOM) += apq8016-schneider-hmibsc.dtb
> dtb-$(CONFIG_ARCH_QCOM) += apq8039-t2.dtb
> dtb-$(CONFIG_ARCH_QCOM) += apq8094-sony-xperia-kitakami-karin_windy.dtb
> dtb-$(CONFIG_ARCH_QCOM) += apq8096-db820c.dtb
> diff --git a/arch/arm64/boot/dts/qcom/apq8016-schneider-hmibsc.dts b/arch/arm64/boot/dts/qcom/apq8016-schneider-hmibsc.dts
> new file mode 100644
> index 000000000000..62ce862ff5c0
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/apq8016-schneider-hmibsc.dts
> @@ -0,0 +1,490 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2015, The Linux Foundation. All rights reserved.
> + * Copyright (c) 2024, Linaro Ltd.
> + */
> +
> +/dts-v1/;
> +
> +#include "msm8916-pm8916.dtsi"
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/leds/common.h>
> +#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
> +#include <dt-bindings/pinctrl/qcom,pmic-mpp.h>
> +#include <dt-bindings/sound/apq8016-lpass.h>
> +
> +/ {
> + model = "Schneider Electric HMIBSC Board";
> + compatible = "schneider,apq8016-hmibsc", "qcom,apq8016";
> +
> + aliases {
> + i2c1 = &blsp_i2c6;
> + i2c3 = &blsp_i2c4;
> + i2c4 = &blsp_i2c3;
> + mmc0 = &sdhc_1; /* eMMC */
> + mmc1 = &sdhc_2; /* SD card */
> + serial0 = &blsp_uart1;
> + serial1 = &blsp_uart2;
> + spi0 = &blsp_spi5;
> + usid0 = &pm8916_0;
> + };
> +
> + chosen {
> + stdout-path = "serial0";
> + };
> +
> + hdmi-out {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_con: endpoint {
> + remote-endpoint = <&adv7533_out>;
> + };
> + };
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + autorepeat;
> + pinctrl-0 = <&msm_key_volp_n_default>;
> + pinctrl-names = "default";
> +
> + button {
> + label = "Volume Up";
> + linux,code = <KEY_VOLUMEUP>;
> + gpios = <&tlmm 107 GPIO_ACTIVE_LOW>;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-0 = <&pm8916_mpps_leds>;
> + pinctrl-names = "default";
> +
> + led-1 {
> + function = LED_FUNCTION_WLAN;
> + color = <LED_COLOR_ID_YELLOW>;
> + gpios = <&pm8916_mpps 2 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "phy0tx";
> + default-state = "off";
> + };
> +
> + led-2 {
> + function = LED_FUNCTION_BLUETOOTH;
> + color = <LED_COLOR_ID_BLUE>;
> + gpios = <&pm8916_mpps 3 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "bluetooth-power";
> + default-state = "off";
> + };
> + };
> +
> + memory@80000000 {
> + reg = <0 0x80000000 0 0x40000000>;
> + };
> +
> + reserved-memory {
> + ramoops@bff00000 {
> + compatible = "ramoops";
> + reg = <0x0 0xbff00000 0x0 0x100000>;
> + record-size = <0x20000>;
> + console-size = <0x20000>;
> + ftrace-size = <0x20000>;
> + ecc-size = <16>;
> + };
> + };
> +
> + usb-hub {
> + compatible = "smsc,usb3503";
> + reset-gpios = <&pm8916_gpios 1 GPIO_ACTIVE_LOW>;
> + initial-mode = <1>;
> + };
> +
> + usb_id: usb-id {
> + compatible = "linux,extcon-usb-gpio";
> + id-gpios = <&tlmm 110 GPIO_ACTIVE_HIGH>;
> + pinctrl-0 = <&usb_id_default>;
> + pinctrl-names = "default";
> + };
> +};
> +
> +&blsp_i2c3 {
> + status = "okay";
> +
> + eeprom@50 {
> + compatible = "atmel,24c32";
> + reg = <0x50>;
> + };
> +};
> +
> +&blsp_i2c4 {
> + status = "okay";
> +
> + adv_bridge: bridge@39 {
> + compatible = "adi,adv7533";
> + reg = <0x39>;
> + interrupts-extended = <&tlmm 31 IRQ_TYPE_EDGE_FALLING>;
> +
> + adi,dsi-lanes = <4>;
> + clocks = <&rpmcc RPM_SMD_BB_CLK2>;
> + clock-names = "cec";
> + pd-gpios = <&tlmm 32 GPIO_ACTIVE_HIGH>;
> +
> + avdd-supply = <&pm8916_l6>;
> + a2vdd-supply = <&pm8916_l6>;
> + dvdd-supply = <&pm8916_l6>;
> + pvdd-supply = <&pm8916_l6>;
> + v1p2-supply = <&pm8916_l6>;
> + v3p3-supply = <&pm8916_l17>;
> +
> + pinctrl-0 = <&adv7533_int_active &adv7533_switch_active>;
> + pinctrl-1 = <&adv7533_int_suspend &adv7533_switch_suspend>;
> + pinctrl-names = "default","sleep";
> + #sound-dai-cells = <0>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + adv7533_in: endpoint {
> + remote-endpoint = <&mdss_dsi0_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + adv7533_out: endpoint {
> + remote-endpoint = <&hdmi_con>;
> + };
> + };
> + };
> + };
> +};
> +
> +&blsp_i2c6 {
> + status = "okay";
> +
> + rtc@30 {
> + compatible = "sii,s35390a";
> + reg = <0x30>;
> + };
> +
> + eeprom@50 {
> + compatible = "atmel,24c256";
> + reg = <0x50>;
> + };
> +};
> +
> +&blsp_spi5 {
> + cs-gpios = <&tlmm 18 GPIO_ACTIVE_LOW>;
> + status = "okay";
> +
> + tpm@0 {
> + compatible = "infineon,slb9670", "tcg,tpm_tis-spi";
> + reg = <0>;
> + spi-max-frequency = <500000>;
> + };
> +};
> +
> +&blsp_uart1 {
> + label = "UART0";
> + status = "okay";
> +};
> +
> +&blsp_uart2 {
> + label = "UART1";
> + status = "okay";
> +};
> +
> +&lpass {
> + status = "okay";
> +};
> +
> +&mdss {
> + status = "okay";
> +};
> +
> +&mdss_dsi0_out {
> + data-lanes = <0 1 2 3>;
> + remote-endpoint = <&adv7533_in>;
> +};
> +
> +&pm8916_codec {
> + qcom,mbhc-vthreshold-low = <75 150 237 450 500>;
> + qcom,mbhc-vthreshold-high = <75 150 237 450 500>;
> + status = "okay";
> +};
> +
> +&pm8916_gpios {
> + gpio-line-names =
> + "USB_HUB_RESET_N_PM",
> + "USB_SW_SEL_PM",
> + "NC",
> + "NC";
> +
> + usb_hub_reset_pm: usb-hub-reset-pm-state {
> + pins = "gpio1";
> + function = PMIC_GPIO_FUNC_NORMAL;
> + input-disable;
> + output-high;
> + };
> +
> + usb_hub_reset_pm_device: usb-hub-reset-pm-device-state {
> + pins = "gpio1";
> + function = PMIC_GPIO_FUNC_NORMAL;
> + output-low;
> + };
> +
Nitpick: &usb_hub_reset_pm has input-disable (and the two others below),
but this one doesn't.
> + usb_sw_sel_pm: usb-sw-sel-pm-state {
> + pins = "gpio2";
> + function = PMIC_GPIO_FUNC_NORMAL;
> + power-source = <PM8916_GPIO_VPH>;
> + input-disable;
> + output-high;
> + };
> +
> + usb_sw_sel_pm_device: usb-sw-sel-pm-device-state {
> + pins = "gpio2";
> + function = PMIC_GPIO_FUNC_NORMAL;
> + power-source = <PM8916_GPIO_VPH>;
> + input-disable;
> + output-low;
> + };
> +};
> +
> +&pm8916_mpps {
> + gpio-line-names =
> + "NC",
> + "WLAN_LED_CTRL",
> + "BT_LED_CTRL",
> + "NC";
> +
> + pm8916_mpps_leds: pm8916-mpps-state {
> + pins = "mpp2", "mpp3";
> + function = "digital";
> + output-low;
> + };
> +};
> +
> +&pm8916_resin {
> + linux,code = <KEY_POWER>;
> + status = "okay";
> +};
> +
> +&pm8916_rpm_regulators {
> + pm8916_l17: l17 {
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +};
> +
> +&sdhc_1 {
> + status = "okay";
> +};
> +
> +&sdhc_2 {
> + pinctrl-0 = <&sdc2_default &sdc2_cd_default>;
> + pinctrl-1 = <&sdc2_sleep &sdc2_cd_default>;
> + pinctrl-names = "default", "sleep";
> + cd-gpios = <&tlmm 38 GPIO_ACTIVE_LOW>;
> + status = "okay";
> +};
> +
> +&sound {
> + pinctrl-0 = <&cdc_pdm_default &sec_mi2s_default>;
> + pinctrl-1 = <&cdc_pdm_sleep &sec_mi2s_sleep>;
> + pinctrl-names = "default", "sleep";
> + model = "HMIBSC";
> + audio-routing =
> + "AMIC2", "MIC BIAS Internal2",
> + "AMIC3", "MIC BIAS External1";
> + status = "okay";
> +
> + quaternary-dai-link {
> + link-name = "ADV7533";
> + cpu {
> + sound-dai = <&lpass MI2S_QUATERNARY>;
> + };
> + codec {
> + sound-dai = <&adv_bridge 0>;
> + };
> + };
> +
> + primary-dai-link {
> + link-name = "WCD";
> + cpu {
> + sound-dai = <&lpass MI2S_PRIMARY>;
> + };
> + codec {
> + sound-dai = <&lpass_codec 0>, <&pm8916_codec 0>;
> + };
> + };
> +
> + tertiary-dai-link {
> + link-name = "WCD-Capture";
> + cpu {
> + sound-dai = <&lpass MI2S_TERTIARY>;
> + };
> + codec {
> + sound-dai = <&lpass_codec 1>, <&pm8916_codec 1>;
> + };
> + };
> +};
> +
> +&tlmm {
> + pinctrl-0 = <&uart1_mux0_rs232_high &uart1_mux1_rs232_low>;
> + pinctrl-names = "default";
> +
> + adv7533_int_active: adv533-int-active-state {
> + pins = "gpio31";
> + function = "gpio";
> + drive-strength = <16>;
> + bias-disable;
> + };
> +
> + adv7533_int_suspend: adv7533-int-suspend-state {
> + pins = "gpio31";
> + function = "gpio";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> + adv7533_switch_active: adv7533-switch-active-state {
> + pins = "gpio32";
> + function = "gpio";
> + drive-strength = <16>;
> + bias-disable;
> + };
> +
> + adv7533_switch_suspend: adv7533-switch-suspend-state {
> + pins = "gpio32";
> + function = "gpio";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> + msm_key_volp_n_default: msm-key-volp-n-default-state {
> + pins = "gpio107";
> + function = "gpio";
> + drive-strength = <8>;
> + bias-pull-up;
> + };
> +
> + sdc2_cd_default: sdc2-cd-default-state {
> + pins = "gpio38";
> + function = "gpio";
> + drive-strength = <2>;
> + bias-disable;
> + };
> +
> + /*
> + * UART1 being the debug console supports various modes of
> + * operation (RS-232/485/422) controlled via GPIOs configured
> + * mux as follows:
> + *
> + * gpio100 gpio99 UART mode
> + * 0 0 loopback
> + * 0 1 RS-232
> + * 1 0 RS-485
> + * 1 1 RS-422
> + *
> + * The default mode configured here is RS-232 mode.
> + */
> + uart1_mux0_rs232_high: uart1-mux0-rs232-state {
> + bootph-all;
> + pins = "gpio99";
> + function = "gpio";
> + drive-strength = <16>;
> + bias-disable;
> + output-high;
> + };
> +
> + uart1_mux1_rs232_low: uart1-mux1-rs232-state {
> + bootph-all;
> + pins = "gpio100";
> + function = "gpio";
> + drive-strength = <16>;
> + bias-disable;
> + output-low;
> + };
> +
> + usb_id_default: usb-id-default-state {
> + pins = "gpio110";
> + function = "gpio";
> + drive-strength = <8>;
> + bias-pull-up;
> + };
> +};
> +
> +&usb {
> + extcon = <&usb_id>, <&usb_id>;
> + pinctrl-0 = <&usb_sw_sel_pm &usb_hub_reset_pm>;
> + pinctrl-1 = <&usb_sw_sel_pm_device &usb_hub_reset_pm_device>;
> + pinctrl-names = "default", "device";
> + status = "okay";
> +};
> +
> +&usb_hs_phy {
> + extcon = <&usb_id>;
> +};
> +
> +&wcnss {
> + firmware-name = "qcom/apq8016/wcnss.mbn";
> + status = "okay";
> +};
> +
> +&wcnss_ctrl {
> + firmware-name = "qcom/apq8016/WCNSS_qcom_wlan_nv_sbc.bin";
> +};
> +
> +&wcnss_iris {
> + compatible = "qcom,wcn3620";
> +};
> +
> +&wcnss_mem {
> + status = "okay";
> +};
> +
> +/* PINCTRL - additions to nodes defined in msm8916.dtsi */
> +
> +/*
> + * 2mA drive strength is not enough when connecting multiple
> + * I2C devices with different pull up resistors.
> + */
> +&blsp_i2c4_default {
> + drive-strength = <16>;
> +};
> +
> +&blsp_i2c6_default {
> + drive-strength = <16>;
> +};
> +
> +&blsp_uart1_default {
> + bootph-all;
> +};
> +
> +/* Enable CoreSight */
> +&cti0 { status = "okay"; };
> +&cti1 { status = "okay"; };
> +&cti12 { status = "okay"; };
> +&cti13 { status = "okay"; };
> +&cti14 { status = "okay"; };
> +&cti15 { status = "okay"; };
> +&debug0 { status = "okay"; };
> +&debug1 { status = "okay"; };
> +&debug2 { status = "okay"; };
> +&debug3 { status = "okay"; };
> +&etf { status = "okay"; };
> +&etm0 { status = "okay"; };
> +&etm1 { status = "okay"; };
> +&etm2 { status = "okay"; };
> +&etm3 { status = "okay"; };
> +&etr { status = "okay"; };
> +&funnel0 { status = "okay"; };
> +&funnel1 { status = "okay"; };
> +&replicator { status = "okay"; };
> +&stm { status = "okay"; };
> +&tpiu { status = "okay"; };
> --
> 2.34.1
>
^ permalink raw reply
* Re: [RFC PATCH 02/13] dt-bindings: pinctrl: renesas: Document RZ/V2H(P) SoC
From: Lad, Prabhakar @ 2024-03-27 18:58 UTC (permalink / raw)
To: Rob Herring
Cc: Geert Uytterhoeven, Linus Walleij, Krzysztof Kozlowski,
Conor Dooley, Magnus Damm, linux-renesas-soc, linux-gpio,
devicetree, linux-kernel, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20240327172439.GA3664500-robh@kernel.org>
Hi Rob,
Thank you for the review.
On Wed, Mar 27, 2024 at 5:24 PM Rob Herring <robh@kernel.org> wrote:
>
> On Tue, Mar 26, 2024 at 10:28:33PM +0000, Prabhakar wrote:
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> >
> > Add documentation for the pin controller found on the Renesas RZ/V2H(P)
> > (R9A09G057) SoC. Compared to RZ/G2L family of SoCs there are slight
> > differences on the RZ/V2H(P) SoC for pinmuxing.
> >
> > Also add 'renesas-rzv2h,output-impedance' property. Drive strength
> > setting on RZ/V2H(P) depends on the different power rails which are
> > coming out from the PMIC (connected via i2c). These power rails
> > (required for drive strength) can be 1.2/1.8/3.3V.
> >
> > Pin are grouped into 4 groups,
> >
> > Group1: Impedance
> > - 150/75/38/25 ohms (at 3.3 V)
> > - 130/65/33/22 ohms (at 1.8 V)
> >
> > Group2: Impedance
> > - 50/40/33/25 ohms (at 1.8 V)
> >
> > Group3: Impedance
> > - 150/75/37.5/25 ohms (at 3.3 V)
> > - 130/65/33/22 ohms (at 1.8 V)
> >
> > Group4: Impedance
> > - 110/55/30/20 ohms (at 1.8 V)
> > - 150/75/38/25 ohms (at 1.2 V)
> >
> > 'renesas-rzv2h,output-impedance' property as documented which can be
> > [1, 2, 4, 6] indicates x Value strength.
>
> Looks like the values are x1, x1.5, x3ish, x6...
>
> >
> > As the power rail information cannot be available very early in the
> > boot process as 'renesas-rzv2h,output-impedance' property is added
> > instead of reusing output-impedance-ohms property.
> >
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > ---
> > .../pinctrl/renesas,rzg2l-pinctrl.yaml | 22 +++++++++++++++----
> > 1 file changed, 18 insertions(+), 4 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml
> > index 881e992adca3..77f4fc7f4a21 100644
> > --- a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml
> > +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml
> > @@ -26,6 +26,7 @@ properties:
> > - renesas,r9a07g043-pinctrl # RZ/G2UL{Type-1,Type-2} and RZ/Five
> > - renesas,r9a07g044-pinctrl # RZ/G2{L,LC}
> > - renesas,r9a08g045-pinctrl # RZ/G3S
> > + - renesas,r9a09g057-pinctrl # RZ/V2H(P)
> >
> > - items:
> > - enum:
> > @@ -66,10 +67,14 @@ properties:
> > maxItems: 1
> >
> > resets:
> > - items:
> > - - description: GPIO_RSTN signal
> > - - description: GPIO_PORT_RESETN signal
> > - - description: GPIO_SPARE_RESETN signal
> > + oneOf:
> > + - items:
> > + - description: GPIO_RSTN signal
> > + - description: GPIO_PORT_RESETN signal
> > + - description: GPIO_SPARE_RESETN signal
> > + - items:
> > + - description: PFC main reset
> > + - description: Reset for the control register related to WDTUDFCA and WDTUDFFCM pins
> >
> > additionalProperties:
> > anyOf:
> > @@ -111,6 +116,15 @@ additionalProperties:
> > output-high: true
> > output-low: true
> > line-name: true
> > + renesas-rzv2h,output-impedance:
>
> 'renesas-rzv2h' is not a vendor.
>
I will update this to "renesas,output-impedance".
> That should give you a warning if you actually used this somewhere.
>
I did run dtbs_check with this property in the DTS and haven't seen
any warning. Also now I included this property in the example node in
the binding doc and seen no warnings reported by dt_binding_check too.
> > + description: |
> > + Output impedance for pins on RZ/V2H(P) SoC.
> > + x1: Corresponds to 0 in IOLH register.
> > + x2: Corresponds to 1 in IOLH register.
> > + x4: Corresponds to 2 in IOLH register.
> > + x6: Corresponds to 3 in IOLH register.
>
> Why not just use 0-3 for the values?
>
Fine by me. I'll update this in the next version.
Cheers,
Prabhakar
^ permalink raw reply
* Re: [PATCH v6 02/16] regulator: dt-bindings: describe the PMU module of the WCN7850 package
From: Bartosz Golaszewski @ 2024-03-27 18:56 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Marcel Holtmann, Luiz Augusto von Dentz, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kalle Valo, Bjorn Andersson,
Konrad Dybcio, Liam Girdwood, Mark Brown, Catalin Marinas,
Will Deacon, Bjorn Helgaas, Saravana Kannan, Geert Uytterhoeven,
Arnd Bergmann, Neil Armstrong, Marek Szyprowski, Alex Elder,
Srini Kandagatla, Greg Kroah-Hartman, Abel Vesa,
Manivannan Sadhasivam, Lukas Wunner, Dmitry Baryshkov,
linux-bluetooth, netdev, devicetree, linux-kernel, linux-wireless,
linux-arm-msm, linux-arm-kernel, linux-pci, linux-pm,
Bartosz Golaszewski
In-Reply-To: <1614af1c-330d-49ee-aa22-a19de866862e@linaro.org>
On Wed, Mar 27, 2024 at 7:19 PM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 25/03/2024 14:16, Bartosz Golaszewski wrote:
> > + then:
> > + required:
> > + - vdd-supply
> > + - vddio-supply
> > + - vddaon-supply
> > + - vdddig-supply
> > + - vddrfa1p2-supply
> > + - vddrfa1p8-supply
>
> I assume vddio1p2 is not required on purpose.
>
Correct.
Bart
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v6 01/16] regulator: dt-bindings: describe the PMU module of the QCA6390 package
From: Bartosz Golaszewski @ 2024-03-27 18:55 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Marcel Holtmann, Luiz Augusto von Dentz, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kalle Valo, Bjorn Andersson,
Konrad Dybcio, Liam Girdwood, Mark Brown, Catalin Marinas,
Will Deacon, Bjorn Helgaas, Saravana Kannan, Geert Uytterhoeven,
Arnd Bergmann, Neil Armstrong, Marek Szyprowski, Alex Elder,
Srini Kandagatla, Greg Kroah-Hartman, Abel Vesa,
Manivannan Sadhasivam, Lukas Wunner, Dmitry Baryshkov,
linux-bluetooth, netdev, devicetree, linux-kernel, linux-wireless,
linux-arm-msm, linux-arm-kernel, linux-pci, linux-pm,
Bartosz Golaszewski
In-Reply-To: <af9def4e-c6d6-49d9-a457-68c40492587a@linaro.org>
On Wed, Mar 27, 2024 at 7:17 PM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 25/03/2024 14:16, Bartosz Golaszewski wrote:
> > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> >
> > The QCA6390 package contains discreet modules for WLAN and Bluetooth. They
> > are powered by the Power Management Unit (PMU) that takes inputs from the
> > host and provides LDO outputs. This document describes this module.
> >
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> Can you start using b4?
>
> This is a friendly reminder during the review process.
>
> It looks like you received a tag and forgot to add it.
>
> If you do not know the process, here is a short explanation:
> Please add Acked-by/Reviewed-by/Tested-by tags when posting new
> versions, under or above your Signed-off-by tag. Tag is "received", when
> provided in a message replied to you on the mailing list. Tools like b4
> can help here. However, there's no need to repost patches *only* to add
> the tags. The upstream maintainer will do that for tags received on the
> version they apply.
>
> https://elixir.bootlin.com/linux/v6.5-rc3/source/Documentation/process/submitting-patches.rst#L577
>
> If a tag was not added on purpose, please state why and what changed.
>
As per the first sentence of the cover letter: I dropped review tags
from the patches that changed significantly while keeping them for
those that didn't. If there's a way to let your automation know about
this, please let me know/point me in the right direction because I
don't know about it.
Bart
^ permalink raw reply
* Re: [PATCH RESEND v6 1/5] dt-bindings: spmi: Add X1E80100 SPMI PMIC ARB schema
From: Krzysztof Kozlowski @ 2024-03-27 18:40 UTC (permalink / raw)
To: Abel Vesa, Stephen Boyd, Matthias Brugger, Bjorn Andersson,
Konrad Dybcio, Dmitry Baryshkov, Neil Armstrong,
AngeloGioacchino Del Regno, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Srini Kandagatla, Johan Hovold, linux-kernel, linux-arm-kernel,
linux-arm-msm, linux-mediatek, devicetree
In-Reply-To: <20240326-spmi-multi-master-support-v6-1-1c87d8306c5b@linaro.org>
On 26/03/2024 17:28, Abel Vesa wrote:
> + qcom,channel:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 5
> + description: >
> + which of the PMIC Arb provided channels to use for accesses
> +
> +patternProperties:
> + "spmi@[a-f0-9]+$":
Missing '^' in the pattern. I did not notice it earlier because only
since ~2 weeks I have lei filter for ABI based on node names. And your
driver created ABI based on node names, so this must be fixed. Sorry. :(
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 1/2] of: create of_root if no dtb provided
From: Rob Herring @ 2024-03-27 18:38 UTC (permalink / raw)
To: Guenter Roeck
Cc: Stephen Boyd, Frank Rowand, Clément Léger, devicetree,
linux-kernel, Lizhi Hou, Allan Nielsen, Horatiu Vultur,
Steen Hegelund, Thomas Petazzoni
In-Reply-To: <407867d2-2e32-4df4-96ac-f9ae84b44375@roeck-us.net>
On Wed, Mar 27, 2024 at 9:40 AM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On 3/27/24 06:11, Rob Herring wrote:
> > On Wed, Mar 20, 2024 at 3:06 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >>
> >> On 3/20/24 12:14, Rob Herring wrote:
> >>> On Mon, Mar 18, 2024 at 4:31 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >>>>
> >>>> On 3/18/24 12:26, Rob Herring wrote:
> >>>>> +Stephen
> >>>>>
> >>>>> On Mon, Mar 18, 2024 at 12:09 PM Guenter Roeck <linux@roeck-us.net> wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> On Fri, Mar 17, 2023 at 12:34:14AM -0500, Frank Rowand wrote:
> >>>>>>> When enabling CONFIG_OF on a platform where of_root is not populated by
> >>>>>>> firmware, we end up without a root node. In order to apply overlays and
> >>>>>>> create subnodes of the root node, we need one. Create this root node
> >>>>>>> by unflattening an empty builtin dtb.
> >>>>>>>
> >>>>>>> If firmware provides a flattened device tree (FDT) then the FDT is
> >>>>>>> unflattened via setup_arch(). Otherwise setup_of(), which is called
> >>>>>>> immediately after setup_arch(), will create the default root node
> >>>>>>> if it does not exist.
> >>>>>>>
> >>>>>>> Signed-off-by: Frank Rowand <frowand.list@gmail.com>
> >>>>>>
> >>>>>> This patch results in a crash on nios2.
> >>>>>
> >>>>> This patch was never applied. I assume you meant a later version of it
> >>>>> that did get applied.
> >>>>>
> >>>>>>
> >>>>>> Building nios2:10m50-ghrd:10m50_defconfig:10m50_devboard.dts ... running ...R failed (crashed)
> >>>>>
> >>>>> Booting with DT?
> >>>>>
> >>>>>> ------------
> >>>>>> qemu log:
> >>>>>> earlycon: uart8250 at MMIO32 0x18001600 (options '')
> >>>>>> printk: legacy bootconsole [uart8250] enabled
> >>>>>> Linux version 6.8.0-11409-gf6cef5f8c37f (groeck@desktop) (nios2-linux-gcc (GCC) 11.4.0, GNU ld (GNU Binutils) 2.40) #1 Sun Mar 17 23:38:59 PDT 2024
> >>>>>> Kernel panic - not syncing: early_init_dt_alloc_memory_arch: Failed to allocate 72 bytes align=0x40
> >>>>>> ---[ end Kernel panic - not syncing: early_init_dt_alloc_memory_arch: Failed to allocate 72 bytes align=0x40 ]---
> >>>>>
> >>>>> nios2 looks utterly broken to me. This change should be a nop unless
> >>>>> initial_boot_params is NULL. It looks like it is possible for r6 (dtb
> >>>>> address) to be 0 depending on kconfig options, but that would have
> >>>>> skipped copying and unflattening which would then panic in
> >>>>> setup_cpuinfo(). If initial_boot_params is not NULL, then the same
> >>>>> early_init_dt_alloc_memory_arch() calls should fail when copying the
> >>>>> DT. So I don't see how nios2 booting with DT ever worked.
> >>>>>
> >>>>
> >>>> For nios2, in early_init_devtree():
> >>>>
> >>>> void __init early_init_devtree(void *params)
> >>>> {
> >>>> __be32 *dtb = (u32 *)__dtb_start;
> >>>> ...
> >>>> if (be32_to_cpu((__be32) *dtb) == OF_DT_HEADER)
> >>>> params = (void *)__dtb_start;
> >>>>
> >>>> That worked fine until this patch. Starting with this patch, __dtb_start
> >>>> always points to a valid empty devicetree blob, which overrides the
> >>>> devicetree blob passed to early_init_devtree(). This causes the problem.
> >>>
> >>> With an external DTB, it doesn't boot with or without this patch. It
> >>> just dies in different spots. Before it just skipped any memory
> >>
> >> No, that is incorrect.
> >
> > Well, I can tell you it doesn't boot for me. So I must be doing
> > something different from your setup.
> >
>
> Maybe you have OF_UNITTEST enabled and it indeed results in the
> problem you mention below. I don't have it enabled because it produces
> various backtraces which would hide real problems.
I thought of that, but I don't think I did. What I suspect is the
external dtb is at address 0.
> >> Up to this patch it booted just fine with an
> >> external dtb using the "-initrd" command line argument, and I explained
> >> to you above why this is the case.
> >
> > What does -initrd have to do with anything? Does that shift where the
> > external dtb is placed or something?
> >
>
> Nothing. I meant to say -dtb.
>
> > I think I see the issue. __dtb_start points to the start of *all*
> > built-in DTBs, not a specific one. In this case, arc, csky, loongarch,
> > mips, openrisc, riscv, sh, and xtensa may all be broken too (if one
> > picks the magic combination of booting modes and kconfig options). I
>
> No.
>
> - arc only picks the internal dtb if use_embedded_dtb is true. This flag
> is only set if there is no external dtb, or if the external dtb does
> not provide a valid machine description.
Right, but when it does pick the internal dtb, it is expecting its dtb
at __dtb_start. What I'm saying is that's never been a good or safe
assumption. We just happened to add another case to trigger it. The
only reliable way to get a built-in DTB is if foo.dtb is built-in,
then use __dtb_foo_begin to get its address. That's what some MIPS
platforms with multiple DTBs do.
> - openrisc only picks the internal dtb if no external dtb is provided.
> - riscv only picks the internal dtb if CONFIG_BUILTIN_DTB is enabled.
> - sh only used the internal dtb if CONFIG_USE_BUILTIN_DTB is enabled.
> - xtensa only picks the internal dtb if there is no external dtb.
>
> However, nios2 picks the internal dtb _even if_ an external dtb
> is provided if there is an internal dtb. In other words, it prefers
> the internal dtb over the external dtb. All other architectures
> prefer the external dtb over the internal dtb.
Thanks for the analysis. I had started and abandoned common support
(mostly Kconfig options) for built-in dtbs years ago. I decided
against it because it is not something we want to encourage (as the
boot dtb). In the meantime, we've gained new architectures that have
added it. Sigh. So now I'm reconsidering something common (though not
for v6.9).
>
> > would expect all these cases have been broken forever if the DT
> > unittest is enabled as it too adds a built-in dtb. But I would also
>
> Even if that is correct for nios2, that hardly seems to be an argument
> to break nios2 boot with external dtb unconditionally.
That wasn't an argument for breaking it. Using an external dtb should
really be the default and strongly preferred though.
I'm still not sure how to fix this easily for 6.9. Something like what
microblaze does which puts the boot dtb under a consistent symbol
name. Or perhaps we could iterate thru the built-in dtbs and skip ones
without top-level compatible.
Rob
^ permalink raw reply
* [PATCH v1 2/2] arm64: dts: ti: k3-am625-verdin: add PCIe reset gpio hog
From: Francesco Dolcini @ 2024-03-27 18:28 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Francesco Dolcini, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20240327182801.5997-1-francesco@dolcini.it>
From: Francesco Dolcini <francesco.dolcini@toradex.com>
Add a GPIO hog to release PCIe reset on the carrier board, this is
required to use M.2 or mPCIe cards.
Verdin AM62 does not have any PCIe interface, however the Verdin family
has PCIe and normally an M.2 or mPCIe slot is available in the carrier
board that can be used with cards that use only the USB interface toward
the host CPU, for example cellular network modem.
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
arch/arm64/boot/dts/ti/k3-am62-verdin-dahlia.dtsi | 8 +++++++-
arch/arm64/boot/dts/ti/k3-am62-verdin-dev.dtsi | 8 +++++++-
arch/arm64/boot/dts/ti/k3-am62-verdin-mallow.dtsi | 8 +++++++-
arch/arm64/boot/dts/ti/k3-am62-verdin-yavia.dtsi | 8 +++++++-
arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi | 9 +++++++++
5 files changed, 37 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62-verdin-dahlia.dtsi b/arch/arm64/boot/dts/ti/k3-am62-verdin-dahlia.dtsi
index 6c4cec8728e4..e51fda1127ef 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-verdin-dahlia.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-verdin-dahlia.dtsi
@@ -160,7 +160,8 @@ &mcu_gpio0 {
pinctrl-0 = <&pinctrl_gpio_1>,
<&pinctrl_gpio_2>,
<&pinctrl_gpio_3>,
- <&pinctrl_gpio_4>;
+ <&pinctrl_gpio_4>,
+ <&pinctrl_pcie_1_reset>;
};
/* Verdin I2C_3_HDMI */
@@ -211,6 +212,11 @@ &verdin_gpio_keys {
status = "okay";
};
+/* Verdin PCIE_1_RESET# */
+&verdin_pcie_1_reset_hog {
+ status = "okay";
+};
+
/* Verdin UART_2 */
&wkup_uart0 {
status = "okay";
diff --git a/arch/arm64/boot/dts/ti/k3-am62-verdin-dev.dtsi b/arch/arm64/boot/dts/ti/k3-am62-verdin-dev.dtsi
index be62648e7818..74eec1a1abca 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-verdin-dev.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-verdin-dev.dtsi
@@ -181,7 +181,8 @@ &mcu_gpio0 {
pinctrl-0 = <&pinctrl_gpio_1>,
<&pinctrl_gpio_2>,
<&pinctrl_gpio_3>,
- <&pinctrl_gpio_4>;
+ <&pinctrl_gpio_4>,
+ <&pinctrl_pcie_1_reset>;
};
/* Verdin I2C_3_HDMI */
@@ -232,6 +233,11 @@ &verdin_gpio_keys {
status = "okay";
};
+/* Verdin PCIE_1_RESET# */
+&verdin_pcie_1_reset_hog {
+ status = "okay";
+};
+
/* Verdin UART_2 */
&wkup_uart0 {
status = "okay";
diff --git a/arch/arm64/boot/dts/ti/k3-am62-verdin-mallow.dtsi b/arch/arm64/boot/dts/ti/k3-am62-verdin-mallow.dtsi
index cd81a606c435..754216d8ac14 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-verdin-mallow.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-verdin-mallow.dtsi
@@ -154,7 +154,8 @@ &mcu_gpio0 {
pinctrl-0 = <&pinctrl_gpio_1>,
<&pinctrl_gpio_2>,
<&pinctrl_gpio_3>,
- <&pinctrl_gpio_4>;
+ <&pinctrl_gpio_4>,
+ <&pinctrl_pcie_1_reset>;
};
/* Verdin I2C_3_HDMI */
@@ -200,6 +201,11 @@ &verdin_gpio_keys {
status = "okay";
};
+/* Verdin PCIE_1_RESET# */
+&verdin_pcie_1_reset_hog {
+ status = "okay";
+};
+
/* Verdin UART_2 */
&wkup_uart0 {
status = "okay";
diff --git a/arch/arm64/boot/dts/ti/k3-am62-verdin-yavia.dtsi b/arch/arm64/boot/dts/ti/k3-am62-verdin-yavia.dtsi
index 997dfafd27eb..7372d392ec8a 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-verdin-yavia.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-verdin-yavia.dtsi
@@ -159,7 +159,8 @@ &mcu_gpio0 {
pinctrl-0 = <&pinctrl_gpio_1>,
<&pinctrl_gpio_2>,
<&pinctrl_gpio_3>,
- <&pinctrl_gpio_4>;
+ <&pinctrl_gpio_4>,
+ <&pinctrl_pcie_1_reset>;
};
/* Verdin I2C_3_HDMI */
@@ -205,6 +206,11 @@ &verdin_gpio_keys {
status = "okay";
};
+/* Verdin PCIE_1_RESET# */
+&verdin_pcie_1_reset_hog {
+ status = "okay";
+};
+
/* Verdin UART_2 */
&wkup_uart0 {
status = "okay";
diff --git a/arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi b/arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi
index e8d8857ad51f..e6c10d23d038 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi
@@ -1407,6 +1407,15 @@ &mcu_gpio0 {
"",
"",
"";
+
+ verdin_pcie_1_reset_hog: pcie-1-reset-hog {
+ gpio-hog;
+ /* Verdin PCIE_1_RESET# (SODIMM 244) */
+ gpios = <0 GPIO_ACTIVE_LOW>;
+ line-name = "PCIE_1_RESET#";
+ output-low;
+ status = "disabled";
+ };
};
/* Verdin CAN_2 */
--
2.39.2
^ permalink raw reply related
* [PATCH v1 1/2] arm64: dts: ti: verdin-am62: mallow: fix GPIOs pinctrl
From: Francesco Dolcini @ 2024-03-27 18:28 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Francesco Dolcini, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20240327182801.5997-1-francesco@dolcini.it>
From: Francesco Dolcini <francesco.dolcini@toradex.com>
Generic GPIOs pinctrl nodes are not correct, gpio[1-4] are into the MCU
domain and should be into &mcu_gpio0, gpio[5-8] were missing and are added
in this commit.
Fixes: 7698622fbcf4 ("arm64: dts: ti: Add verdin am62 mallow board")
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
---
.../arm64/boot/dts/ti/k3-am62-verdin-mallow.dtsi | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am62-verdin-mallow.dtsi b/arch/arm64/boot/dts/ti/k3-am62-verdin-mallow.dtsi
index 77b1beb638ad..cd81a606c435 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-verdin-mallow.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-verdin-mallow.dtsi
@@ -81,10 +81,10 @@ &epwm1 {
&main_gpio0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ctrl_sleep_moci>,
- <&pinctrl_gpio_1>,
- <&pinctrl_gpio_2>,
- <&pinctrl_gpio_3>,
- <&pinctrl_gpio_4>;
+ <&pinctrl_gpio_5>,
+ <&pinctrl_gpio_6>,
+ <&pinctrl_gpio_7>,
+ <&pinctrl_gpio_8>;
};
/* Verdin I2C_1 */
@@ -149,6 +149,14 @@ &main_uart1 {
status = "okay";
};
+&mcu_gpio0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_1>,
+ <&pinctrl_gpio_2>,
+ <&pinctrl_gpio_3>,
+ <&pinctrl_gpio_4>;
+};
+
/* Verdin I2C_3_HDMI */
&mcu_i2c0 {
status = "okay";
--
2.39.2
^ permalink raw reply related
* [PATCH v1 0/2] arm64: dts: ti: k3-am625-verdin: fix GPIOs pinctrl
From: Francesco Dolcini @ 2024-03-27 18:27 UTC (permalink / raw)
To: Nishanth Menon, Vignesh Raghavendra, Tero Kristo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Francesco Dolcini, linux-arm-kernel, devicetree, linux-kernel
From: Francesco Dolcini <francesco.dolcini@toradex.com>
Fix a couple of issues on the Verdin AM62 pinctrl affecting multiple
carrier boards.
The first patch fixes a mistake on the pinctrl of the verdin-am62 mallow
carrier board.
The second patch allows using the mPCIe/M.2 slot available on multiple
carrier boards with cards that use only the USB interface toward the host,
this is achieved with a GPIO hog, given that no PCIe interface exists.
Francesco Dolcini (2):
arm64: dts: ti: verdin-am62: mallow: fix GPIOs pinctrl
arm64: dts: ti: k3-am625-verdin: add PCIe reset gpio hog
.../boot/dts/ti/k3-am62-verdin-dahlia.dtsi | 8 ++++++-
.../arm64/boot/dts/ti/k3-am62-verdin-dev.dtsi | 8 ++++++-
.../boot/dts/ti/k3-am62-verdin-mallow.dtsi | 22 +++++++++++++++----
.../boot/dts/ti/k3-am62-verdin-yavia.dtsi | 8 ++++++-
arch/arm64/boot/dts/ti/k3-am62-verdin.dtsi | 9 ++++++++
5 files changed, 48 insertions(+), 7 deletions(-)
--
2.39.2
^ permalink raw reply
* Re: [PATCH v6 05/16] dt-bindings: net: wireless: describe the ath12k PCI module
From: Krzysztof Kozlowski @ 2024-03-27 18:21 UTC (permalink / raw)
To: Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Kalle Valo,
Bjorn Andersson, Konrad Dybcio, Liam Girdwood, Mark Brown,
Catalin Marinas, Will Deacon, Bjorn Helgaas, Saravana Kannan,
Geert Uytterhoeven, Arnd Bergmann, Neil Armstrong,
Marek Szyprowski, Alex Elder, Srini Kandagatla,
Greg Kroah-Hartman, Abel Vesa, Manivannan Sadhasivam,
Lukas Wunner, Dmitry Baryshkov
Cc: linux-bluetooth, netdev, devicetree, linux-kernel, linux-wireless,
linux-arm-msm, linux-arm-kernel, linux-pci, linux-pm,
Bartosz Golaszewski
In-Reply-To: <20240325131624.26023-6-brgl@bgdev.pl>
On 25/03/2024 14:16, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> Add device-tree bindings for the ATH12K module found in the WCN7850
> package.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> ---
> .../bindings/net/wireless/qcom,ath12k.yaml | 100 ++++++++++++++++++
> 1 file changed, 100 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/wireless/qcom,ath12k.yaml
>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 02/16] regulator: dt-bindings: describe the PMU module of the WCN7850 package
From: Krzysztof Kozlowski @ 2024-03-27 18:19 UTC (permalink / raw)
To: Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Kalle Valo,
Bjorn Andersson, Konrad Dybcio, Liam Girdwood, Mark Brown,
Catalin Marinas, Will Deacon, Bjorn Helgaas, Saravana Kannan,
Geert Uytterhoeven, Arnd Bergmann, Neil Armstrong,
Marek Szyprowski, Alex Elder, Srini Kandagatla,
Greg Kroah-Hartman, Abel Vesa, Manivannan Sadhasivam,
Lukas Wunner, Dmitry Baryshkov
Cc: linux-bluetooth, netdev, devicetree, linux-kernel, linux-wireless,
linux-arm-msm, linux-arm-kernel, linux-pci, linux-pm,
Bartosz Golaszewski
In-Reply-To: <20240325131624.26023-3-brgl@bgdev.pl>
On 25/03/2024 14:16, Bartosz Golaszewski wrote:
> + then:
> + required:
> + - vdd-supply
> + - vddio-supply
> + - vddaon-supply
> + - vdddig-supply
> + - vddrfa1p2-supply
> + - vddrfa1p8-supply
I assume vddio1p2 is not required on purpose.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 01/16] regulator: dt-bindings: describe the PMU module of the QCA6390 package
From: Krzysztof Kozlowski @ 2024-03-27 18:17 UTC (permalink / raw)
To: Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Kalle Valo,
Bjorn Andersson, Konrad Dybcio, Liam Girdwood, Mark Brown,
Catalin Marinas, Will Deacon, Bjorn Helgaas, Saravana Kannan,
Geert Uytterhoeven, Arnd Bergmann, Neil Armstrong,
Marek Szyprowski, Alex Elder, Srini Kandagatla,
Greg Kroah-Hartman, Abel Vesa, Manivannan Sadhasivam,
Lukas Wunner, Dmitry Baryshkov
Cc: linux-bluetooth, netdev, devicetree, linux-kernel, linux-wireless,
linux-arm-msm, linux-arm-kernel, linux-pci, linux-pm,
Bartosz Golaszewski
In-Reply-To: <20240325131624.26023-2-brgl@bgdev.pl>
On 25/03/2024 14:16, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> The QCA6390 package contains discreet modules for WLAN and Bluetooth. They
> are powered by the Power Management Unit (PMU) that takes inputs from the
> host and provides LDO outputs. This document describes this module.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Can you start using b4?
This is a friendly reminder during the review process.
It looks like you received a tag and forgot to add it.
If you do not know the process, here is a short explanation:
Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions, under or above your Signed-off-by tag. Tag is "received", when
provided in a message replied to you on the mailing list. Tools like b4
can help here. However, there's no need to repost patches *only* to add
the tags. The upstream maintainer will do that for tags received on the
version they apply.
https://elixir.bootlin.com/linux/v6.5-rc3/source/Documentation/process/submitting-patches.rst#L577
If a tag was not added on purpose, please state why and what changed.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 5/6] PCI: dwc: rcar-gen4: Add support for other R-Car Gen4 PCIe controller
From: Bjorn Helgaas @ 2024-03-27 18:14 UTC (permalink / raw)
To: Yoshihiro Shimoda
Cc: lpieralisi@kernel.org, kw@linux.com, robh@kernel.org,
bhelgaas@google.com, krzysztof.kozlowski+dt@linaro.org,
conor+dt@kernel.org, jingoohan1@gmail.com,
gustavo.pimentel@synopsys.com, mani@kernel.org,
marek.vasut+renesas@gmail.com, linux-pci@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org
In-Reply-To: <TYCPR01MB110402EB3E15B3471C7F526C7D8342@TYCPR01MB11040.jpnprd01.prod.outlook.com>
On Wed, Mar 27, 2024 at 05:32:57AM +0000, Yoshihiro Shimoda wrote:
> > From: Bjorn Helgaas, Sent: Wednesday, March 27, 2024 5:49 AM
> > > static int rcar_gen4_pcie_get_resources(struct rcar_gen4_pcie *rcar)
> > > {
> > > + rcar->phy_base = devm_platform_ioremap_resource_byname(rcar->pdev, "phy");
> > > + if (IS_ERR(rcar->phy_base))
> > > + return PTR_ERR(rcar->base);
> >
> > I don't get it. This imposes a new requirement (presence of "phy"
> > resource) on the existing SoCs. That doesn't sound right.
>
> According to the dt-binding doc, the existing SoCs are also required
> for the "phy". That's why I didn't add any condition to simplify
> the code.
Is there anything that enforces that? Is it possible that DTs exist
in the field without it? We don't want to break any existing setup.
^ permalink raw reply
* [PATCH 2/2] phy: qcom-qmp-ufs: Add SM8475 support
From: Danila Tikhonov @ 2024-03-27 18:06 UTC (permalink / raw)
To: andersson, konrad.dybcio, vkoul, kishon, robh,
krzysztof.kozlowski+dt, conor+dt
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Danila Tikhonov
In-Reply-To: <20240327180642.20146-1-danila@jiaxyga.com>
Add the tables and constants for init sequences for UFS QMP phy found in
SM8475 SoC.
Signed-off-by: Danila Tikhonov <danila@jiaxyga.com>
---
drivers/phy/qualcomm/phy-qcom-qmp-ufs.c | 71 +++++++++++++++++++++++++
1 file changed, 71 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
index 590432d581f9..ddc0def0ae61 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-ufs.c
@@ -722,6 +722,38 @@ static const struct qmp_phy_init_tbl sm8350_ufsphy_g4_pcs[] = {
QMP_PHY_INIT_CFG(QPHY_V5_PCS_UFS_BIST_FIXED_PAT_CTRL, 0x0a),
};
+static const struct qmp_phy_init_tbl sm8475_ufsphy_serdes[] = {
+ QMP_PHY_INIT_CFG(QSERDES_V6_COM_SYSCLK_EN_SEL, 0xd9),
+ QMP_PHY_INIT_CFG(QSERDES_V6_COM_CMN_CONFIG_1, 0x16),
+ QMP_PHY_INIT_CFG(QSERDES_V6_COM_HSCLK_SEL_1, 0x11),
+ QMP_PHY_INIT_CFG(QSERDES_V6_COM_HSCLK_HS_SWITCH_SEL_1, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP_EN, 0x01),
+ QMP_PHY_INIT_CFG(QSERDES_V6_COM_VCO_TUNE_INITVAL2, 0x00),
+ QMP_PHY_INIT_CFG(QSERDES_V6_COM_DEC_START_MODE0, 0x82),
+ QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_RCTRL_MODE0, 0x18),
+ QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_CCTRL_MODE0, 0x18),
+ QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP1_MODE0, 0xff),
+ QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP2_MODE0, 0x0c),
+};
+
+static const struct qmp_phy_init_tbl sm8475_ufsphy_g4_serdes[] = {
+ QMP_PHY_INIT_CFG(QSERDES_V6_COM_VCO_TUNE_MAP, 0x04),
+ QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_IVCO, 0x0f),
+ QMP_PHY_INIT_CFG(QSERDES_V6_COM_CP_CTRL_MODE0, 0x14),
+ QMP_PHY_INIT_CFG(QSERDES_V6_COM_DEC_START_MODE1, 0x98),
+ QMP_PHY_INIT_CFG(QSERDES_V6_COM_CP_CTRL_MODE1, 0x14),
+ QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_RCTRL_MODE1, 0x18),
+ QMP_PHY_INIT_CFG(QSERDES_V6_COM_PLL_CCTRL_MODE1, 0x18),
+ QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP1_MODE1, 0x32),
+ QMP_PHY_INIT_CFG(QSERDES_V6_COM_LOCK_CMP2_MODE1, 0x0f),
+};
+
+static const struct qmp_phy_init_tbl sm8475_ufsphy_g4_pcs[] = {
+ QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_PLL_CNTL, 0x0b),
+ QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_TX_HSGEAR_CAPABILITY, 0x04),
+ QMP_PHY_INIT_CFG(QPHY_V6_PCS_UFS_RX_HSGEAR_CAPABILITY, 0x04),
+};
+
static const struct qmp_phy_init_tbl sm8550_ufsphy_serdes[] = {
QMP_PHY_INIT_CFG(QSERDES_V6_COM_SYSCLK_EN_SEL, 0xd9),
QMP_PHY_INIT_CFG(QSERDES_V6_COM_CMN_CONFIG_1, 0x16),
@@ -1346,6 +1378,42 @@ static const struct qmp_phy_cfg sm8450_ufsphy_cfg = {
.regs = ufsphy_v5_regs_layout,
};
+static const struct qmp_phy_cfg sm8475_ufsphy_cfg = {
+ .lanes = 2,
+
+ .offsets = &qmp_ufs_offsets_v6,
+ .max_supported_gear = UFS_HS_G4,
+
+ .tbls = {
+ .serdes = sm8475_ufsphy_serdes,
+ .serdes_num = ARRAY_SIZE(sm8475_ufsphy_serdes),
+ .tx = sm8550_ufsphy_tx,
+ .tx_num = ARRAY_SIZE(sm8550_ufsphy_tx),
+ .rx = sm8550_ufsphy_rx,
+ .rx_num = ARRAY_SIZE(sm8550_ufsphy_rx),
+ .pcs = sm8550_ufsphy_pcs,
+ .pcs_num = ARRAY_SIZE(sm8550_ufsphy_pcs),
+ },
+ .tbls_hs_b = {
+ .serdes = sm8550_ufsphy_hs_b_serdes,
+ .serdes_num = ARRAY_SIZE(sm8550_ufsphy_hs_b_serdes),
+ },
+ .tbls_hs_overlay[0] = {
+ .serdes = sm8475_ufsphy_g4_serdes,
+ .serdes_num = ARRAY_SIZE(sm8475_ufsphy_g4_serdes),
+ .tx = sm8550_ufsphy_g4_tx,
+ .tx_num = ARRAY_SIZE(sm8550_ufsphy_g4_tx),
+ .rx = sm8550_ufsphy_g4_rx,
+ .rx_num = ARRAY_SIZE(sm8550_ufsphy_g4_rx),
+ .pcs = sm8475_ufsphy_g4_pcs,
+ .pcs_num = ARRAY_SIZE(sm8475_ufsphy_g4_pcs),
+ .max_gear = UFS_HS_G4,
+ },
+ .vreg_list = qmp_phy_vreg_l,
+ .num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
+ .regs = ufsphy_v6_regs_layout,
+};
+
static const struct qmp_phy_cfg sm8550_ufsphy_cfg = {
.lanes = 2,
@@ -1941,6 +2009,9 @@ static const struct of_device_id qmp_ufs_of_match_table[] = {
}, {
.compatible = "qcom,sm8450-qmp-ufs-phy",
.data = &sm8450_ufsphy_cfg,
+ }, {
+ .compatible = "qcom,sm8475-qmp-ufs-phy",
+ .data = &sm8475_ufsphy_cfg,
}, {
.compatible = "qcom,sm8550-qmp-ufs-phy",
.data = &sm8550_ufsphy_cfg,
--
2.44.0
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: phy: Add QMP UFS PHY comptible for SM8475
From: Danila Tikhonov @ 2024-03-27 18:06 UTC (permalink / raw)
To: andersson, konrad.dybcio, vkoul, kishon, robh,
krzysztof.kozlowski+dt, conor+dt
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Danila Tikhonov
In-Reply-To: <20240327180642.20146-1-danila@jiaxyga.com>
Document the QMP UFS PHY compatible for SM8475.
Signed-off-by: Danila Tikhonov <danila@jiaxyga.com>
---
.../devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
index 91a6cc38ff7f..1e8c3abb09a4 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-ufs-phy.yaml
@@ -32,6 +32,7 @@ properties:
- qcom,sm8250-qmp-ufs-phy
- qcom,sm8350-qmp-ufs-phy
- qcom,sm8450-qmp-ufs-phy
+ - qcom,sm8475-qmp-ufs-phy
- qcom,sm8550-qmp-ufs-phy
- qcom,sm8650-qmp-ufs-phy
@@ -98,6 +99,7 @@ allOf:
- qcom,sm8250-qmp-ufs-phy
- qcom,sm8350-qmp-ufs-phy
- qcom,sm8450-qmp-ufs-phy
+ - qcom,sm8475-qmp-ufs-phy
- qcom,sm8550-qmp-ufs-phy
- qcom,sm8650-qmp-ufs-phy
then:
--
2.44.0
^ permalink raw reply related
* [PATCH 0/2] phy: qcom-qmp-ufs: Add support for SM8475
From: Danila Tikhonov @ 2024-03-27 18:06 UTC (permalink / raw)
To: andersson, konrad.dybcio, vkoul, kishon, robh,
krzysztof.kozlowski+dt, conor+dt
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel,
Danila Tikhonov
This series adds UFS QMP support for Qualcomm SM8475 SoC.
To: Bjorn Andersson <andersson@kernel.org>
To: Konrad Dybcio <konrad.dybcio@linaro.org>
To: Vinod Koul <vkoul@kernel.org>
To: Kishon Vijay Abraham I <kishon@kernel.org>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
To: Conor Dooley <conor+dt@kernel.org>
Cc: linux-arm-msm@vger.kernel.org
Cc: linux-phy@lists.infradead.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Danila Tikhonov <danila@jiaxyga.com>
Danila Tikhonov (2):
dt-bindings: phy: Add QMP UFS PHY comptible for SM8475
phy: qcom-qmp-ufs: Add SM8475 support
.../phy/qcom,sc8280xp-qmp-ufs-phy.yaml | 2 +
drivers/phy/qualcomm/phy-qcom-qmp-ufs.c | 71 +++++++++++++++++++
2 files changed, 73 insertions(+)
--
2.44.0
^ permalink raw reply
* Re: [PATCH v3 6/6] riscv: dts: starfive: add Milkv Mars board device tree
From: Conor Dooley @ 2024-03-27 18:06 UTC (permalink / raw)
To: Jisheng Zhang
Cc: Rob Herring, Krzysztof Kozlowski, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Emil Renner Berthing, linux-riscv, devicetree,
linux-kernel
In-Reply-To: <20240206-magma-deem-2c88e45a545a@spud>
[-- Attachment #1: Type: text/plain, Size: 1615 bytes --]
Yo,
On Tue, Feb 06, 2024 at 07:13:48PM +0000, Conor Dooley wrote:
> On Wed, Jan 31, 2024 at 09:26:00PM +0800, Jisheng Zhang wrote:
> > The Milkv Mars is a development board based on the Starfive JH7110 SoC.
> > The board features:
> >
> > - JH7110 SoC
> > - 1/2/4/8 GiB LPDDR4 DRAM
> > - AXP15060 PMIC
> > - 40 pin GPIO header
> > - 3x USB 3.0 host port
> > - 1x USB 2.0 host port
> > - 1x M.2 E-Key
> > - 1x eMMC slot
> > - 1x MicroSD slot
> > - 1x QSPI Flash
> > - 1x 1Gbps Ethernet port
> > - 1x HDMI port
> > - 1x 2-lane DSI and 1x 4-lane DSI
> > - 1x 2-lane CSI
> >
> > Add the devicetree file describing the currently supported features,
> > namely PMIC, UART, I2C, GPIO, SD card, QSPI Flash, eMMC and Ethernet.
> >
> > Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
>
> Got a dtbs_check issue in the patchwork CI:
>
> +arch/riscv/boot/dts/starfive/jh7110-milkv-mars.dtb: gmac1-rgmii-rxin-clock: 'clock-frequency' is a required property
> + from schema $id: http://devicetree.org/schemas/clock/fixed-clock.yaml#
> +arch/riscv/boot/dts/starfive/jh7110-milkv-mars.dtb: gmac1-rmii-refin-clock: 'clock-frequency' is a required property
> + from schema $id: http://devicetree.org/schemas/clock/fixed-clock.yaml#
>
> Can you fix that please? Also, I applied some patches the other day that
> seem to conflict quite a bit with the common board dts patch. Would you
> please do a rebase on top of that please?
Been going through stuff on my todo list now that the merge window is
closed. Could you please resend this with the rebase done?
Thanks,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: 回复: 回复: [PATCH v1 1/2] dt-bindings: media: starfive: Match driver and yaml property names
From: Conor Dooley @ 2024-03-27 18:03 UTC (permalink / raw)
To: Changhuang Liang
Cc: Conor Dooley, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Emil Renner Berthing,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Jack Zhu,
linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-riscv@lists.infradead.org, devicetree@vger.kernel.org
In-Reply-To: <20240122-uncivil-almost-631137081fd9@spud>
[-- Attachment #1: Type: text/plain, Size: 1691 bytes --]
On Mon, Jan 22, 2024 at 08:24:51AM +0000, Conor Dooley wrote:
> On Mon, Jan 22, 2024 at 01:33:56AM +0000, Changhuang Liang wrote:
> >
> > > On Fri, Jan 19, 2024 at 12:57:22PM +0000, Changhuang Liang wrote:
> > > > EXTERNAL EMAIL: Do not click links or open attachments unless you know
> > > > the content is safe
> > > >
> > > > Hi , Conor
> > > >
> > > > > 主题: Re: [PATCH v1 1/2] dt-bindings: media: starfive: Match driver
> > > > > and yaml property names
> > > > >
> > > > > On Fri, Jan 19, 2024 at 02:06:38AM -0800, Changhuang Liang wrote:
> > > > > > Drop some unused properties for clocks, resets and interrupts for
> > > > > > StarFive JH7110 camera subsystem.
> > > > >
> > > > > What do you mean "unused"?
> > > > >
> > > > > Do these clocks etc exist but are not used by the driver?
> > > > >
> > > > > Or do they not exist at all?
> > > > >
> > > > > The two are very different!
> > >
> > > > These clocks etc exist but are not used by the driver.
> > >
> > > That's not an acceptable reason for removing them from the binding. If they
> > > exist, they should be documented, regardless of whether the driver makes use
> > > of them. NAK.
> >
> > If so, how to avoid the warning of dtbs_check.
>
> By also adding the clocks, resets and interrupts to the dts.
Going through patchwork stuff now that the merge window is done. I'm
gonna mark the dts patch as changes requeted. The binding (and dts)
should describe all of the clocks the hardware has, whether or not you
choose to use them all in software does not matter. Can you please
resend the dts patch, with all of the clocks, resets and interrupts
present?
Thanks,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v1 4/5] dt-bindings: PCI: microchip: increase number of items in ranges property
From: Rob Herring @ 2024-03-27 17:57 UTC (permalink / raw)
To: Conor Dooley
Cc: linux-riscv, Lorenzo Pieralisi, devicetree, linux-kernel,
Linus Walleij, Conor Dooley, Bjorn Helgaas,
Krzysztof Wilczyński, Jamie Gibbons, linux-pci,
Daire McNamara, linux-gpio, Krzysztof Kozlowski,
Bartosz Golaszewski, Valentina Fernandez
In-Reply-To: <20240327-debunk-perky-f5514ca332be@spud>
On Wed, 27 Mar 2024 12:24:39 +0000, Conor Dooley wrote:
> From: Valentina Fernandez <valentina.fernandezalanis@microchip.com>
>
> Increase the number of items in the ranges property to allow up to 3
> ranges. For example a prefetchable range, a non-prefetchable range
> and an IO range, depending on configuration.
>
> Signed-off-by: Valentina Fernandez <valentina.fernandezalanis@microchip.com>
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> ---
> Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v1 3/5] dt-bindings: gpio: mpfs: allow gpio-line-names
From: Rob Herring @ 2024-03-27 17:57 UTC (permalink / raw)
To: Conor Dooley
Cc: Lorenzo Pieralisi, Valentina Fernandez, Bjorn Helgaas,
Linus Walleij, Bartosz Golaszewski, Daire McNamara, linux-riscv,
linux-kernel, linux-pci, devicetree, Conor Dooley,
Krzysztof Kozlowski, linux-gpio, Jamie Gibbons,
Krzysztof Wilczyński
In-Reply-To: <20240327-overrate-overuse-1e32abccd001@spud>
On Wed, 27 Mar 2024 12:24:38 +0000, Conor Dooley wrote:
> From: Jamie Gibbons <jamie.gibbons@microchip.com>
>
> The BeagleV Fire devicetree will make use of gpio-line-names, allow it
> in the binding.
>
> Signed-off-by: Jamie Gibbons <jamie.gibbons@microchip.com>
> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
> ---
> Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox